./0002755000764400076440000000000013761035607010361 5ustar iustyiusty./draft-ietf-core-stateless-08.txt0000644000764400076440000014461613754655746016357 0ustar iustyiusty CoRE Working Group K. Hartke Internet-Draft Ericsson Updates: 7252, 8323 (if approved) M. Richardson Intended status: Standards Track Sandelman Expires: May 20, 2021 November 16, 2020 Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) draft-ietf-core-stateless-08 Abstract This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323 with an extended definition of the TKL field in the CoAP message header. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 20, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Hartke & Richardson Expires May 20, 2021 [Page 1] Internet-Draft Extended Tokens in CoAP November 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Extended Token Length (TKL) Field . . . . . . . . . . . . 4 2.2. Discovering Support . . . . . . . . . . . . . . . . . . . 5 2.2.1. Extended-Token-Length Capability Option . . . . . . . 5 2.2.2. Trial-and-Error . . . . . . . . . . . . . . . . . . . 6 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . 8 3. Stateless Clients . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Serializing Client State . . . . . . . . . . . . . . . . 9 3.2. Using Extended Tokens . . . . . . . . . . . . . . . . . . 10 3.3. Transmitting Messages . . . . . . . . . . . . . . . . . . 12 4. Stateless Intermediaries . . . . . . . . . . . . . . . . . . 12 4.1. Observing Resources . . . . . . . . . . . . . . . . . . . 13 4.2. Block-Wise Transfers . . . . . . . . . . . . . . . . . . 13 4.3. Gateway Timeouts . . . . . . . . . . . . . . . . . . . . 14 4.4. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 14 5.2. Stateless Clients and Intermediaries . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. CoAP Signaling Option Number . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Updated Message Formats . . . . . . . . . . . . . . 18 A.1. CoAP over UDP . . . . . . . . . . . . . . . . . . . . . . 18 A.2. CoAP over TCP/TLS . . . . . . . . . . . . . . . . . . . . 20 A.3. CoAP over WebSockets . . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful application-layer protocol for constrained environments [RFC7228]. In CoAP, clients (or intermediaries in the client role) make requests to servers (or intermediaries in the server role), which satisfy the requests by returning responses. Hartke & Richardson Expires May 20, 2021 [Page 2] Internet-Draft Extended Tokens in CoAP November 2020 While a request is ongoing, a client typically needs to keep some state that it requires for processing the response when that arrives. Identification of this state is done in CoAP by means of a token, an opaque sequence of bytes chosen by the client and included in the CoAP request, and that is returned by the server verbatim in any resulting CoAP response (Figure 1). +-----------------+ request with +------------+ | | | state identifier | | | | | as token | | | .-<-+->------|--------------------->|------. | | _|_ | | | | | / \ stored | | | | | \___/ state | | | | | | | | | | | '->-+-<------|<---------------------|------' | | | | response with | | | v | token echoed back | | +-----------------+ +------------+ Client Server Figure 1: Token as an Identifier for Request State In some scenarios, it can be beneficial to reduce the amount of state that is stored at the client at the cost of increased message sizes. A client can opt into this by serializing (parts of) its state into the token itself and then recovering this state from the token in the response (Figure 2). +-----------------+ request with +------------+ | | | serialized state | | | | | as token | | | +--------|=====================>|------. | | | | | | | look ma, | | | | | no state! | | | | | | | | | | +--------|<=====================|------' | | | | response with | | | v | token echoed back | | +-----------------+ +------------+ Client Server Figure 2: Token as Serialization of Request State Section 3 of this document provides considerations for clients becoming "stateless" in this way. (The term "stateless" is in quotes here, because it's a bit oversimplified. Such clients still need to Hartke & Richardson Expires May 20, 2021 [Page 3] Internet-Draft Extended Tokens in CoAP November 2020 maintain per-server state and other kinds of state. So it would be more accurate to just say that the clients are avoiding per-request state.) Section 4 of this document extends the considerations for clients to intermediaries, which may not only want to avoid keeping state for the requests they send to servers but also for the requests they receive from clients. The serialization of state into tokens is limited by the fact that both CoAP over UDP [RFC7252] and CoAP over reliable transports [RFC8323] restrict the maximum token length to 8 bytes. To overcome this limitation, Section 2 of this document first introduces a CoAP protocol extension for extended token lengths. While the use case (avoiding per-request state) and the mechanism (extended token lengths) presented in this document are closely related, both can be used independently of each other: Some implementations may be able to fit their state in just 8 bytes; some implementations may have other use cases for extended token lengths. 1.1. Terminology In this document, the term "stateless" refers to an implementation strategy for a client (or intermediary in the client role) that does not require it to keep state for the individual requests it sends to a server (or intermediary in the server role). The client still needs to keep state for each server it communicates with (e.g., for token generation, message retransmission, and congestion control). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Extended Tokens This document updates the message formats defined for CoAP over UDP [RFC7252] and CoAP over TCP, TLS, and WebSockets [RFC8323] with a new definition of the TKL field. 2.1. Extended Token Length (TKL) Field The definition of the TKL field is updated as follows: Token Length (TKL): 4-bit unsigned integer. A value between 0 and 12 inclusive indicates the length of the variable-length Token Hartke & Richardson Expires May 20, 2021 [Page 4] Internet-Draft Extended Tokens in CoAP November 2020 field in bytes. The other three values are reserved for special constructs: 13: An 8-bit unsigned integer directly precedes the Token field and indicates the length of the Token field minus 13. 14: A 16-bit unsigned integer in network byte order directly precedes the Token field and indicates the length of the Token field minus 269. 15: Reserved. This value MUST NOT be sent and MUST be processed as a message format error. All other fields retain their definitions. The updated message formats are illustrated in Appendix A. The new definition of the TKL field increases the maximum token length that can be represented in a message to 65804 bytes. However, the maximum token length that sender and recipient implementations support may be shorter. For example, a constrained node of Class 1 [RFC7228] might support extended token lengths only up to 32 bytes. In CoAP over UDP, it is often beneficial to keep CoAP messages small enough to avoid IP fragmentation. The maximum practical token length may therefore also be influenced by the Path MTU. See Section 4.6 of RFC 7252 for details. 2.2. Discovering Support Extended token lengths require support from server implementations. Support can be discovered by a client implementation in one of two ways: o Where Capabilities and Settings Messages (CSMs) are available, such as in CoAP over TCP, support can be discovered using the Extended-Token-Length Capability Option defined in Section 2.2.1. o Otherwise, such as in CoAP over UDP, support can only be discovered by trial-and-error, as described in Section 2.2.2. 2.2.1. Extended-Token-Length Capability Option A server can use the elective Extended-Token-Length Capability Option to indicate the maximum token length it can accept in requests. Hartke & Richardson Expires May 20, 2021 [Page 5] Internet-Draft Extended Tokens in CoAP November 2020 +----+---+---+--------+--------------------+-------+--------+-------+ | # | C | R | Applie | Name | Forma | Length | Base | | | | | s to | | t | | Value | +----+---+---+--------+--------------------+-------+--------+-------+ | TB | | | CSM | Extended-Token- | uint | 0-3 | 8 | | D | | | | Length | | | | +----+---+---+--------+--------------------+-------+--------+-------+ C=Critical, R=Repeatable Table 1: The Extended-Token-Length Capability Option As per Section 3 of RFC 7252, the base value (and the value used when this option is not implemented) is 8. The active value of the Extended-Token-Length Option is replaced each time the option is sent with a modified value. Its starting value is its base value. The option value MUST NOT be less than 8 or greater than 65804. If an option value less than 8 is received, the option MUST be ignored. If an option value greater than 65804 is received, the option value MUST be set to 65804. Any option value greater than 8 implies support for the new definition of the TKL field specified in Section 2.1. Indication of support by a server does not oblige a client to actually make use of token lengths greater than 8. If a server receives a request with a token of a length greater than what it indicated in its Extended-Token-Length Option, it MUST handle the request as a message format error. If a server receives a request with a token of a length less than or equal to what it indicated in its Extended-Token-Length Option but is unwilling or unable to handle the token at that time, it MUST NOT handle the request as a message format error. Instead, it SHOULD return a 5.03 (Service Unavailable) response. The Extended-Token-Length Capability Option does not apply to responses. The sender of a request is simply expected not to use a token of a length greater than it is willing to accept in a response. 2.2.2. Trial-and-Error A server implementation that does not support the updated definition of the TKL field specified in Section 2.1 will consider a request with a TKL field value outside the range 0 to 8 a message format Hartke & Richardson Expires May 20, 2021 [Page 6] Internet-Draft Extended Tokens in CoAP November 2020 error and reject it (Section 3 of RFC 7252). A client can therefore determine support by sending a request with an extended token length and checking whether it is rejected by the server or not. In CoAP over UDP, the way a request message is rejected depends on the message type. A Confirmable message with a message format error is rejected with a Reset message (Section 4.2 of RFC 7252). A Non- confirmable message with a message format error is either rejected with a Reset message or just silently ignored (Section 4.3 of RFC 7252). To reliably get a Reset message, it is therefore REQUIRED that clients use a Confirmable message for determining support. As per RFC 7252, Reset messages are empty and do not contain a token; they only return the Message ID (Figure 3). They also do not contain any indication of what caused a message format error. To avoid any ambiguity, it is therefore RECOMMENDED that clients use a request that has no potential message format error other than the extended token length. +-----------------+ request message +------------+ | | | with extended | | | | | token length | | | .-<-+->------|--------------------->|------. | | _|_ | | | | | / \ stored | | | | | \___/ state | | | | | | | | | | | '->-+-<------|<---------------------|------' | | | | reset message | | | v | with only message | | +-----------------+ ID echoed back +------------+ Client Server Figure 3: A Confirmable Request With an Extended Token is Rejected With a Reset Message if the Server Does Not Have Support An example of a suitable request is a GET request in a Confirmable message that includes only an If-None-Match option and a token of the greatest length that the client intends to use. Any response with the same token echoed back indicates that tokens up to that length are supported by the server. Since network addresses may change, a client SHOULD NOT assume that extended token lengths are supported by a server for an unlimited duration. Unless additional information is available, the client should assume that addresses (and therefore extended token lengths) are valid for a minimum of 1800 s, and for a maximum of 86400 s (1 day). A client may use additional forms of input into this Hartke & Richardson Expires May 20, 2021 [Page 7] Internet-Draft Extended Tokens in CoAP November 2020 determination. For instance a client may assume a server which is in the same subnet as the client has a similar address lifetime as the client. The client may use DHCP lease times or Router Advertisements to set the limits. For servers that are not local, if the server was looked up using DNS, then the DNS resource record will have a Time To Live, and the extended token length should be kept for only that amount of time. If a server supports extended token lengths but receives a request with a token of a length it is unwilling or unable to handle, it MUST NOT reject the message, as that would imply that extended token lengths are not supported at all. Instead, if the server cannot handle the request at the time, it SHOULD return a 5.03 (Service Unavailable) response; if the server will never be able to handle the request (e.g., because the token is too large), it SHOULD return a 4.00 (Bad Request) response. Design Note: The requirement to return an error response when a token cannot be handled might seem somewhat contradictory, as returning the error response requires the server also to return the token it cannot handle. However, processing a request usually involves a number of steps from receiving the message to passing it to application logic. The idea is that a server implementing this extension supports large tokens at least in its first few processing steps, enough to return an error response rather than a Reset message. Design Note: To make the trial-and-error-based discovery not too complicated, no effort is made to indicate the maximum supported token length. A client implementation would probably already choose the shortest token possible for the task (like being stateless as described in Section 3), so it would probably not be able to reduce the length any further anyway should a server indicate a lower limit. 2.3. Intermediaries Tokens are a hop-by-hop feature: If there are one or more intermediaries between a client and a server, every token is scoped to the exchange between a node in the client role and the node in the server role that it is immediately interacting with. When an intermediary receives a request, the only requirement is that it echoes the token back in any resulting response. There is no requirement or expectation that an intermediary passes a client's token on to a server or that an intermediary uses extended token lengths itself in its request to satisfy a request with an extended Hartke & Richardson Expires May 20, 2021 [Page 8] Internet-Draft Extended Tokens in CoAP November 2020 token length. Discovery needs to be performed for each hop where extended token lengths are to be used. 3. Stateless Clients A client can be alleviated of keeping per-request state as follows: 1. The client serializes (parts of) its per-request state into a sequence of bytes and sends those bytes as the token of its request to the server. 2. The server returns the token verbatim in the response to the client, which allows the client to recover the state and process the response as if it had kept the state locally. As servers are just expected to return any token verbatim to the client, this implementation strategy for clients does not impact the interoperability of client and server implementations. However, there are a number of significant, non-obvious implications (e.g., related to security and other CoAP protocol features) that client implementations need take into consideration. The following subsections discuss some of these considerations. 3.1. Serializing Client State The format of the serialized state is generally an implementation detail of the client and opaque to the server. However, serialized state information is an attractive target for both unwanted nodes (e.g., on-path attackers) and wanted nodes (e.g., any configured forward proxy) on the path. The serialization format therefore needs to include security measures such as the following: o A client SHOULD protect the integrity of the state information serialized in a token. o Even when the integrity of the serialized state is protected, an attacker may still replay a response, making the client believe it sent the same request twice. For this reason, the client SHOULD implement replay protection (e.g., by using sequence numbers and a replay window). For replay protection, integrity protection is REQUIRED. o If processing a response without keeping request state is sensitive to the time elapsed since sending the request, then the client SHOULD include freshness information (e.g., a timestamp) in the serialized state and reject any response where the freshness information is insufficiently fresh. Hartke & Richardson Expires May 20, 2021 [Page 9] Internet-Draft Extended Tokens in CoAP November 2020 o Information in the serialized state may be privacy sensitive. A client SHOULD encrypt the serialized state if it contains privacy sensitive information that an attacker would not get otherwise. o When a client changes the format of the serialized state, it SHOULD prevent false interoperability with the previous format (e.g., by changing the key used for integrity protection or changing a field in the serialized state). 3.2. Using Extended Tokens A client that depends on support for extended token lengths (Section 2) from the server to avoid keeping request state needs to perform a discovery of support (Section 2.2) before it can be stateless. This discovery MUST be performed in a stateful way, i.e., keeping state for the request (Figure 4): If the client was stateless from the start and the server does not support extended tokens, then any error message could not be processed since the state would neither be present at the client nor returned in the Reset message (Figure 5). Hartke & Richardson Expires May 20, 2021 [Page 10] Internet-Draft Extended Tokens in CoAP November 2020 +-----------------+ dummy request +------------+ | | | with extended | | | | | token | | | .-<-+->------|=====================>|------. | | _|_ | | | | | / \ stored | | | | | \___/ state | | | | | | | | | | | '->-+-<------|<=====================|------' | | | | response with | | | | | extended token | | | | | echoed back | | | | | | | | | | | | | | | request with | | | | | serialized state | | | | | as token | | | +--------|=====================>|------. | | | | | | | look ma, | | | | | no state! | | | | | | | | | | +--------|<=====================|------' | | | | response with | | | v | token echoed back | | +-----------------+ +------------+ Client Server Figure 4: Depending on Extended Tokens for Being Stateless First Requires a Successful Stateful Discovery of Support +-----------------+ dummy request +------------+ | | | with extended | | | | | token | | | +--------|=====================>|------. | | | | | | | | | | | | | | | | | | | | | | ???|<---------------------|------' | | | reset message | | | | with only message | | +-----------------+ ID echoed back +------------+ Client Server Figure 5: Stateless Discovery of Support Does Not Work Hartke & Richardson Expires May 20, 2021 [Page 11] Internet-Draft Extended Tokens in CoAP November 2020 In environments where support can be reliably discovered through some other means, the discovery of support is OPTIONAL. An example for this is the Constrained Join Protocol (CoJP) in a 6TiSCH network [I-D.ietf-6tisch-minimal-security], where support for extended tokens is required from all relevant parties. 3.3. Transmitting Messages In CoAP over UDP [RFC7252], a client has the choice between Confirmable and Non-confirmable messages for requests. When using Non-confirmable messages, a client does not have to keep any message exchange state, which can help in the goal of avoiding state. When using Confirmable messages, a client needs to keep message exchange state for performing retransmissions and handling Acknowledgement and Reset messages, however. Non-confirmable messages are therefore better suited for avoiding state. In any case, a client still needs to keep congestion control state, i.e., maintain state for each node it communicates with and enforce limits like NSTART. As per Section 5.2 of RFC 7252, a client must be prepared to receive a response as a piggybacked response, a separate response, or Non- confirmable response, regardless of the message type used for the request. A stateless client MUST handle these response types as follows: o If a piggybacked response passes the checks for token integrity and freshness (Section 3.1), the client processes the message as specified in RFC 7252; otherwise, it processes the acknowledgement portion of the message as specified in RFC 7252 and silently discards the response portion. o If a separate response passes the checks for token integrity and freshness, the client processes the message as specified in RFC 7252; otherwise, it rejects the message as specified in Section 4.2 of RFC 7252. o If a Non-confirmable response passes the checks for token integrity and freshness, the client processes the message as specified in RFC 7252; otherwise, it rejects the message as specified in Section 4.3 of RFC 7252. 4. Stateless Intermediaries Tokens are a hop-by-hop feature: If a client makes a request to an intermediary, that intermediary needs to store the client's token (along with the client's transport address) while it makes its own request towards the origin server and waits for the response. When the intermediary receives the response, it looks up the client's Hartke & Richardson Expires May 20, 2021 [Page 12] Internet-Draft Extended Tokens in CoAP November 2020 token and transport address for the received request and sends an appropriate response to the client. An intermediary might want to be "stateless" not only in its role as a client but also in its role as a server, i.e., be alleviated of storing the client information for the requests it receives. Such an intermediary can be implemented by serializing the client information along with the request state into the token towards the origin server. When the intermediary receives the response, it can recover the client information from the token and use it to satisfy the client's request and therefore doesn't need to store it itself. The following subsections discuss some considerations for this approach. 4.1. Observing Resources One drawback of the approach is that an intermediary, without keeping request state, is unable to aggregate multiple requests for the same target resource, which can significantly reduce efficiency. In particular, when clients observe [RFC7641] the same resource, aggregating requests is REQUIRED (Section 3.1 of RFC 7641). This requirement cannot be satisfied without keeping request state. Furthermore, an intermediary that does not keep track of the clients observing a resource is not able to determine whether these clients are still interested in receiving further notifications (Section 3.5 of RFC 7641) or want to cancel an observation (Section 3.6 of RFC 7641). Therefore, an intermediary MUST NOT include an Observe Option in requests it sends without keeping both the request state for the requests it sends and the client information for the requests it receives. 4.2. Block-Wise Transfers When using block-wise transfers [RFC7959], a server might not be able to distinguish blocks originating from different clients once they have been forwarded by an intermediary. Intermediaries need to ensure that this does not lead to inconsistent resource state by keeping distinct block-wise request operations on the same resource apart, e.g., utilizing the Request-Tag Option [I-D.ietf-core-echo-request-tag]. Hartke & Richardson Expires May 20, 2021 [Page 13] Internet-Draft Extended Tokens in CoAP November 2020 4.3. Gateway Timeouts As per Section 5.7.1 of RFC 7252, an intermediary is REQUIRED to return a 5.04 (Gateway Timeout) response if it cannot obtain a response within a timeout. However, if an intermediary does not keep the client information for the requests it receives, it cannot return such a response. Therefore, in this case, the gateway cannot return such a response and as such cannot implement such a timeout. 4.4. Extended Tokens A client may make use of extended token lengths in a request to an intermediary that wants to be "stateless". This means that such an intermediary may have to serialize potentially very large client information into its token towards the origin server. The tokens can grow even further when it progresses along a chain of intermediaries that all want to be "stateless". Intermediaries SHOULD limit the size of client information they are serializing into their own tokens. An intermediary can do this, for example, by limiting the extended token lengths it accepts from its clients (see Section 2.2) or by keeping the client information locally when the client information exceeds the limit (i.e., not being "stateless"). 5. Security Considerations 5.1. Extended Tokens Tokens significantly larger than the 8 bytes specified in RFC 7252 have implications in particular for nodes with constrained memory size that need to be mitigated. A node in the server role supporting extended token lengths may be vulnerable to a denial-of-service when an attacker (either on-path or a malicious client) sends large tokens to fill up the memory of the node. Implementations need to be prepared to handle such messages. 5.2. Stateless Clients and Intermediaries Transporting the state needed by a client to process a response as serialized state information in the token has several significant and non-obvious security and privacy implications that need to be mitigated; see Section 3.1 for recommendations. In addition to the format requirements outlined there, implementations need to ensure that they are not vulnerable to maliciously crafted, delayed, or replayed tokens. Hartke & Richardson Expires May 20, 2021 [Page 14] Internet-Draft Extended Tokens in CoAP November 2020 It is generally expected that the use of encryption, integrity protection, and replay protection for serialized state is appropriate. In the absence of integrity and replay protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client. It is for this reason that at least the use of integrity protection on the token is always recommended. It maybe that in some very specific case, as a result of a careful and detailed analysis of any potential attacks, that there may be cases where such cryptographic protections do not add value. The authors of this document have not found such a use case as yet, but this is a local decision. It should further be emphasized that the encrypted state is created by the sending node, and decrypted by the same node when receiving a response. The key is not shared with any other system. Therefore the choice of encryption scheme and the generation of the key for this system is purely a local matter. When encryption is used, the use of AES-CCM [RFC3610] with a 64-bit tag is recommended, combined with a sequence number and a replay window. This choice is informed by available hardware acceleration of on many constrained systems. If a different algorithm is available accelerated on the sender, with similar or stronger strength, then it SHOULD be preferred. Where privacy of the state is not required, and encryption is not needed, HMAC-SHA-256 [RFC6234], combined with a sequence number and a replay window, may be used. This size of the replay window depends upon the number of requests that need to be outstanding. This can be determined from the rate at which new ones are made, and the expected duration in which responses are expected. For instance, given a CoAP MAX_TRANSMIT_WAIT of 93 s (Section 4.8.2 of [RFC7252], any request that is not answered within 93 s will be considered to have failed. At a request rate of one request per 10 s, at most 10 (ceil(9.3)) requests can be outstanding at a time, and any convenient replay window larger than 20 will work. As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient. For use cases where requests are being relayed from another node, the request rate may be estimated by the total link capacity allocated Hartke & Richardson Expires May 20, 2021 [Page 15] Internet-Draft Extended Tokens in CoAP November 2020 for that kind of traffic. An alternate view would consider how many IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate for this use. When using an encryption mode that depends on a nonce, such as AES- CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically. If a nonce is ever used for more than one encryption operation with the same key, then the same key stream gets used to encrypt both plaintexts and the confidentiality guarantees are voided. Devices with low-quality entropy sources -- as is typical with constrained devices, which incidentally happen to be a natural candidate for the stateless mechanism described in this document -- need to carefully pick a nonce generation mechanism that provides the above uniqueness guarantee. [RFC8613] appendix B.1.1 ("Sender Sequence Number") provides a model for how to maintain non-repeating nonces without causing excessive wear of flash memory. 6. IANA Considerations 6.1. CoAP Signaling Option Number The following entries are added to the "CoAP Signaling Option Numbers" registry within the "CoRE Parameters" registry. +------------+--------+-----------------------+-------------------+ | Applies to | Number | Name | Reference | +------------+--------+-----------------------+-------------------+ | 7.01 | TBD | Extended-Token-Length | [[this document]] | +------------+--------+-----------------------+-------------------+ [[NOTE TO RFC EDITOR: Please replace "TBD" in this section and in Table 1 with the code point assigned by IANA.]] 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, . Hartke & Richardson Expires May 20, 2021 [Page 16] Internet-Draft Extended Tokens in CoAP November 2020 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, . 7.2. Informative References [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 6tisch-minimal-security-15 (work in progress), December 2019. [I-D.ietf-core-echo-request-tag] Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", draft-ietf-core-echo- request-tag-11 (work in progress), November 2020. [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . Hartke & Richardson Expires May 20, 2021 [Page 17] Internet-Draft Extended Tokens in CoAP November 2020 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . Appendix A. Updated Message Formats In Section 2, this document updates the CoAP message formats by specifying a new definition of the TKL field in the message header. As an alternative presentation of this update, this appendix shows the CoAP message formats for CoAP over UDP [RFC7252] and CoAP over TCP, TLS, and WebSockets [RFC8323] with the new definition applied. A.1. CoAP over UDP Hartke & Richardson Expires May 20, 2021 [Page 18] Internet-Draft Extended Tokens in CoAP November 2020 0 1 2 3 4 5 6 7 +-------+-------+---------------+ | | | | | Ver | T | TKL | 1 byte | | | | +-------+-------+---------------+ | | | Code | 1 byte | | +-------------------------------+ | | | | | | +- Message ID -+ 2 bytes | | | | | | +-------------------------------+ \ \ / TKL / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / Token / 0-65804 bytes \ \ +-------------------------------+ \ \ / / \ \ / Options / 0 or more bytes \ \ / / \ \ +---------------+---------------+ | | | | 15 | 15 | 1 byte (if payload) | | | +---------------+---------------+ \ \ / / \ \ / Payload / 0 or more bytes \ \ / / \ \ +-------------------------------+ Hartke & Richardson Expires May 20, 2021 [Page 19] Internet-Draft Extended Tokens in CoAP November 2020 A.2. CoAP over TCP/TLS 0 1 2 3 4 5 6 7 +---------------+---------------+ | | | | Len | TKL | 1 byte | | | +---------------+---------------+ \ \ / Len / 0-4 bytes \ (extended) \ +-------------------------------+ | | | Code | 1 byte | | +-------------------------------+ \ \ / TKL / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / Token / 0-65804 bytes \ \ +-------------------------------+ \ \ / / \ \ / Options / 0 or more bytes \ \ / / \ \ +---------------+---------------+ | | | | 15 | 15 | 1 byte (if payload) | | | +---------------+---------------+ \ \ / / \ \ / Payload / 0 or more bytes \ \ / / \ \ +-------------------------------+ Hartke & Richardson Expires May 20, 2021 [Page 20] Internet-Draft Extended Tokens in CoAP November 2020 A.3. CoAP over WebSockets 0 1 2 3 4 5 6 7 +---------------+---------------+ | | | | 0 | TKL | 1 byte | | | +---------------+---------------+ | | | Code | 1 byte | | +-------------------------------+ \ \ / TKL / 0-2 bytes \ (extended) \ +-------------------------------+ \ \ / Token / 0-65804 bytes \ \ +-------------------------------+ \ \ / / \ \ / Options / 0 or more bytes \ \ / / \ \ +---------------+---------------+ | | | | 15 | 15 | 1 byte (if payload) | | | +---------------+---------------+ \ \ / / \ \ / Payload / 0 or more bytes \ \ / / \ \ +-------------------------------+ Acknowledgements This document is based on the requirements of and work on the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security] by Malisa Vucinic, Jonathan Simon, Kris Pister, and Michael Richardson. Hartke & Richardson Expires May 20, 2021 [Page 21] Internet-Draft Extended Tokens in CoAP November 2020 Thanks to Christian Amsuss, Carsten Bormann, Roman Danyliw, Christer Holmberg, Benjamin Kaduk, Ari Keranen, Erik Kline, Murray Kucherawy, Warren Kumari, Barry Leiba, David Mandelberg, Dan Romascanu, Jim Schaad, Goran Selander, Malisa Vucinic, Eric Vyncke, and Robert Wilton for helpful comments and discussions that have shaped the document. Special thanks to John Mattsson for his contributions to the security considerations of the document, and to Thomas Fossati for his in- depth review, copious comments, and suggested text. Authors' Addresses Klaus Hartke Ericsson Torshamnsgatan 23 Stockholm SE-16483 Sweden Email: klaus.hartke@ericsson.com Michael C. Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/ Hartke & Richardson Expires May 20, 2021 [Page 22] ./draft-hardie-dispatch-rfc3405-update-04.txt0000644000764400076440000001356213742114274020040 0ustar iustyiusty DISPATCH T. Hardie Internet-Draft 15 October 2020 Updates: 3405 (if approved) Intended status: Best Current Practice Expires: 18 April 2021 Updated registration rules for URI.ARPA draft-hardie-dispatch-rfc3405-update-04 Abstract This document updates RFC 3405 by removing references to the IETF tree from the procedures for requesting that a URI scheme be inserted into the uri.arpa zone. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 April 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Hardie Expires 18 April 2021 [Page 1] Internet-Draft RFC 3405 Update October 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Updated Requirements . . . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 4. Security Considerations . . . . . . . . . . . . . . . . . . . 2 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 2 5.1. Normative References . . . . . . . . . . . . . . . . . . 3 5.2. Informative References . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405 [RFC3405], describes the registration procedures for assignments in URI.ARPA. The document requires that registrations be in the "IETF tree" of URI registrations. The use of URI scheme name trees was defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395] and its successors. Since the use of trees was discontinued, there is no way in the current process set out in BCP 35 [RFC7595] to meet the requirement to register within that tree. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Updated Requirements This document removes the normative requirement from RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree. All registrations in URI.ARPA MUST now be for schemes which are permanent registrations, as they are described in BCP 35. 3. IANA Considerations This entire document is updated instructions to IANA. 4. Security Considerations This update does not change the Security Considerations in RFC 3405 5. References Hardie Expires 18 April 2021 [Page 2] Internet-Draft RFC 3405 Update October 2020 5.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, . [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, DOI 10.17487/RFC3405, October 2002, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 5.2. Informative References [RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, DOI 10.17487/RFC2717, November 1999, . [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, DOI 10.17487/RFC4395, February 2006, . Author's Address Ted Hardie Email: ted.ietf@gmail.com Hardie Expires 18 April 2021 [Page 3] ./draft-ietf-detnet-ip-over-mpls-09.txt0000644000764400076440000006560313740765407017223 0ustar iustyiusty DetNet B. Varga, Ed. Internet-Draft Ericsson Intended status: Standards Track L. Berger Expires: April 14, 2021 D. Fedyk LabN Consulting, L.L.C. S. Bryant Futurewei Technologies J. Korhonen October 11, 2020 DetNet Data Plane: IP over MPLS draft-ietf-detnet-ip-over-mpls-09 Abstract This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet switched network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 14, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Varga, et al. Expires April 14, 2021 [Page 1] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 2 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 4. IP over DetNet MPLS . . . . . . . . . . . . . . . . . . . . . 5 4.1. IP Over DetNet MPLS Data Plane Scenarios . . . . . . . . 5 4.2. DetNet IP over DetNet MPLS Encapsulation . . . . . . . . 6 5. IP over DetNet MPLS Procedures . . . . . . . . . . . . . . . 8 5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures . . . . . . . . . . . . . . . 8 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures . 9 6. Management and Control Information Summary . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative references . . . . . . . . . . . . . . . . . . 11 11.2. Informative references . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. General background and concepts of DetNet can be found in the DetNet Architecture [RFC8655]. This document specifies use of the IP DetNet encapsulation over an MPLS network. It maps the IP data plane encapsulation described in [I-D.ietf-detnet-ip] to the DetNet MPLS data plane defined in [I-D.ietf-detnet-mpls]. 2. Terminology 2.1. Terms Used In This Document This document uses the terminology and concepts established in the DetNet architecture [RFC8655] and Varga, et al. Expires April 14, 2021 [Page 2] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 [I-D.ietf-detnet-data-plane-framework], the reader is assumed to be familiar with these documents and their terminology. 2.2. Abbreviations This document uses the abbreviations defined in the DetNet architecture [RFC8655] and [I-D.ietf-detnet-data-plane-framework]. This document uses the following abbreviations: CE Customer Edge equipment. d-CW DetNet Control Word. DetNet Deterministic Networking. DF DetNet Flow. DN DetNet. L2 Layer-2. LSP Label-switched path. MPLS Multiprotocol Label Switching. PEF Packet Elimination Function. PRF Packet Replication Function. PREOF Packet Replication, Elimination and Ordering Functions. POF Packet Ordering Function. PW Pseudowire. S-Label DetNet "service" label. S-PE Switching Provider Edge. T-PE Terminating Provider Edge. TE Traffic Engineering. TSN Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. Varga, et al. Expires April 14, 2021 [Page 3] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 2.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. DetNet IP Data Plane Overview Figure 1 illustrates an IP DetNet, with an MPLS based DetNet network as a sub-network between the relay nodes. An IP flow is mapped to one or more PWs and MPLS (TE) LSPs. The end systems still originate IP encapsulated traffic, identified as DetNet flows. The relay nodes follow procedures defined in Section 4 to map each DetNet flow to MPLS LSPs. While not shown, relay nodes can provide service sub- layer functions such as PREOF using DetNet over MPLS, and this is indicated by the solid line for the MPLS facing portion of the Service component. Note that the Transit node is MPLS (TE) LSP aware and performs switching based on MPLS labels, and need not have any specific knowledge of the DetNet service or the corresponding DetNet flow identification. See Section 4 for details on the mapping of IP flows to MPLS, and [I-D.ietf-detnet-mpls] for general support of DetNet services using MPLS. DetNet IP Relay Transit Relay DetNet IP End System Node Node Node End System +----------+ +----------+ | Appl. |<------------- End to End Service ---------->| Appl. | +----------+ .....-----+ +-----..... +----------+ | Service |<--: Service |--DetNet flow ---| Service :-->| Service | | | : |<-DN MPLS flow ->| : | | +----------+ +---------+ +----------+ +---------+ +----------+ |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ : Link : / ,-----. \ : Link : / ,-----. \ +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ [Network] [Network] `-----' `-----' |<---- DetNet MPLS ---->| |<--------------------- DetNet IP ------------------>| Figure 1: Architecture: DetNet IP Over DetNet MPLS Network Varga, et al. Expires April 14, 2021 [Page 4] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 4. IP over DetNet MPLS This section defines how IP encapsulated flows are carried over a DetNet MPLS data plane as defined in [I-D.ietf-detnet-mpls]. Since both Non-DetNet and DetNet IP packet are identical on the wire, this section is applicable to any node that supports IP over DetNet MPLS, and this section refers to both cases as DetNet IP over DetNet MPLS. 4.1. IP Over DetNet MPLS Data Plane Scenarios An example use of DetNet IP over DetNet MPLS is presented here. Figure 1 illustrates IP DetNet enabled End Systems (hosts) connected to DetNet (DN) enabled IP networks, operating over a DetNet aware MPLS network. In this Figure we have a case where the Relay nodes act as T-PEs and sit at the boundary of the MPLS domain since the non-MPLS domain is DetNet aware. This case is very similar to the DetNet MPLS Network Figure 2 in [I-D.ietf-detnet-mpls]. However, in [I-D.ietf-detnet-mpls] Figure 2, the T-PEs are located at the end system and MPLS spans the whole DetNet service. The primary difference in this document is that the Relay nodes are at the edges of the MPLS domain and therefore function as T-PEs, and that MPLS service sub-layer functions are not provided over the DetNet IP network. The transit node functions shown above are identical to those described in [I-D.ietf-detnet-mpls]. Figure 2 illustrates how relay nodes can provide service protection over an MPLS domain. In this case, CE1 and CE2 are IP DetNet end systems which are interconnected via a MPLS domain such as described in [I-D.ietf-detnet-mpls]. Note that R1 and R3 sit at the edges of an MPLS domain and therefore are similar to T-PEs, while R2 sits in the middle of the domain and is therefore similar to an S-PE. Varga, et al. Expires April 14, 2021 [Page 5] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 DetNet DetNet IP Service Transit Transit Service IP DetNet |<-Tnl->| |<-Tnl->| DetNet End | V 1 V V 2 V | End System | +--------+ +--------+ +--------+ | System +---+ | | R1 |=======| R2 |=======| R3 | | +---+ | |-------|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|-------| | |CE1| | | \ | | X | | / | | |CE2| | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | +---+ | |=======| |=======| | +---+ ^ +--------+ +--------+ +--------+ ^ | Relay Node Relay Node Relay Node | | (T-PE) (S-PE) (T-PE) | | | |<-DN IP-> <-------- DetNet MPLS ---------------> <-DN IP->| | | |<-------------- End to End DetNet Service --------------->| -------------------------- Data Flow -------------------------> X = Service protection (PRF, PREOF, PEF/POF) DFx = DetNet member flow x over a TE LSP Figure 2: Service Protection Over DetNet MPLS Network for DetNet IP Figure 1 illustrates DetNet enabled End Systems connected to DetNet (DN) enabled MPLS network. A similar situation occurs when end systems are not DetNet aware. In this case, edge nodes sit at the boundary of the MPLS domain since it is also a DetNet domain boundary. The edge nodes provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows. While the node types differ, there is essentially no difference in data plane processing between relay and edges. There are likely to be differences in controller plane operation, particularly when distributed control plane protocols are used. It is still possible to provide DetNet service protection for non- DetNet aware end systems. This case is basically the same as Figure 2, with the exception that CE1 and CE2 are non-DetNet aware end systems and R1 and R3 become edge nodes. 4.2. DetNet IP over DetNet MPLS Encapsulation The basic encapsulation approach is to treat a DetNet IP flow as an app-flow from the DetNet MPLS perspective. The corresponding example DetNet Sub-Network format is shown in Figure 3. Varga, et al. Expires April 14, 2021 [Page 6] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 /-> +------+ +------+ +------+ ^ ^ | | X | | X | | X |<- App-Flow : : | +------+ +------+ +------+ : : App-Flow <-+ |NProto| |NProto| |NProto| : :(1) for MPLS | +------+ +------+ +------+ : : | | IP | | IP | | IP | : v \-> +---+======+--+======+--+======+-----+ : DetNet-MPLS | d-CW | | d-CW | | d-CW | : +------+ +------+ +------+ :(2) |Labels| |Labels| |Labels| v +---+======+--+======+--+======+-----+ Link/Sub-Network | L2 | | TSN | | UDP | +------+ +------+ +------+ | IP | +------+ | L2 | +------+ (1) DetNet IP Flow (or simply IP flow) (2) DetNet MPLS Flow Figure 3: Example DetNet IP over MPLS Sub-Network Formats In Figure 3 "App-Flow" indicates the payload carried by the DetNet IP data plane. "IP" and "NProto" indicate the fields described in Section 5.1.1. (IP Header Information) and Section 5.1.2. (Other Protocol Header Information) of [I-D.ietf-detnet-ip], respectively. "App-Flow for MPLS" indicates that an individual DetNet IP flow is the payload from the perspective of the DetNet MPLS data plane defined in [I-D.ietf-detnet-mpls]. Per Section 5.1 of [I-D.ietf-detnet-mpls], the DetNet MPLS data plane uses a single S-Label to support a single app flow. DetNet IP Flow Identification Procedures in Section 4.4 of [I-D.ietf-detnet-ip] states that a single DetNet flow is identified based on IP, and next level protocol, header information. Section 4.4. (Aggregation Considerations) of [I-D.ietf-detnet-ip] defines the ways in which aggregation is supported through the use of prefixes, wildcards, lists, and port ranges. Collectively, this results in the fairly straightforward procedures defined in the next section. As shown in Figure 2, DetNet relay nodes are responsible for the mapping of a DetNet flow, at the service sub-layer, from the IP to MPLS DetNet data planes and back again. Their related DetNet IP over DetNet MPLS data plane operation is comprised of two sets of procedures: the mapping of flow identifiers, and ensuring proper traffic treatment. Varga, et al. Expires April 14, 2021 [Page 7] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 Mapping of IP to DetNet MPLS is similar for DetNet IP flows and IP flows. The six-tuple of IP is mapped to the S-Label in both cases. The various fields may be mapped or ignored when going from IP to MPLS. 5. IP over DetNet MPLS Procedures The main differences of mapping IP to DetNet MPLS (compared to plain MPLS) are that (1) there is a mandatory flow identification to make the forwarding decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet Control Word) is mandatory for the MPLS encapsulation and (3) during forwarding over the DetNet MPLS network DetNet flow specific treatment is needed. 5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a DetNet MPLS network MUST map a DetNet IP flow, as identified in [I-D.ietf-detnet-ip] into a single MPLS DetNet flow and MUST process it in accordance to the procedures defined in [I-D.ietf-detnet-mpls]. PRF MAY be supported at the MPLS level for DetNet IP flows sent over an DetNet MPLS network. Aggregation MAY be supported as defined in [I-D.ietf-detnet-mpls] Section 4.4. Aggregation considerations in [I-D.ietf-detnet-ip] MAY be used to identify an individual DetNet IP flow. The provisioning of the mapping of DetNet IP flows to DetNet MPLS flows MUST be supported via configuration, e.g., via the controller plane. A DetNet relay node (egress T-PE) MAY be provisioned to handle packets received via the DetNet MPLS data plane as DetNet IP flows. A single incoming DetNet MPLS flow MAY be treated as a single DetNet IP flow, without examination of IP headers. Alternatively, packets received via the DetNet MPLS data plane MAY follow the normal DetNet IP flow identification procedures defined in [I-D.ietf-detnet-ip] Section 5.1. An implementation MUST support the provisioning for handling any packet flows received via DetNet MPLS data plane as DetNet IP flows via configuration. Note that such configuration MAY include support from PREOF on the incoming DetNet MPLS flow. Note: using Layer-4 (L4) transport protocols e.g., for multipath are out of scope of this document both for a single flow and aggregate flows. Varga, et al. Expires April 14, 2021 [Page 8] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 5.2. DetNet IP over DetNet MPLS Traffic Treatment Procedures The traffic treatment required for a particular DetNet IP flow is provisioned via configuration or the controller plane. When a DetNet IP flow is sent over DetNet MPLS, a DetNet relay node MUST ensure that the provisioned DetNet IP traffic treatment is provided at the forwarding sub-layer as described in [I-D.ietf-detnet-mpls] Section 5.2. Note that the PRF function MAY be utilized when sending IP over MPLS. Traffic treatment for DetNet IP flows received over the DetNet MPLS data plane MUST follow Section 5.3 DetNet IP Traffic Treatment Procedures in [I-D.ietf-detnet-ip]. 6. Management and Control Information Summary The following summarizes the set of information that is needed to support DetNet IP over DetNet MPLS at the MPLS ingress node: o Each MPLS App-Flow is identified using the IP flow identification information as defined in [I-D.ietf-detnet-ip]. The information is summarized in Section 5.1 of that document, and includes all wildcards, port ranges and the ability to ignore specific IP fields. o The DetNet MPLS service that is to be used to send the matching IP traffic. This matching information is provided in [I-D.ietf-detnet-mpls] Section 5.1, and includes both service and traffic delivery information. The following summarizes the set of information that is needed to support DetNet IP over DetNet MPLS at the MPLS egress node: o S-Label values that are carrying MPLS over IP encapsulated traffic. o For each S-Label, how the received traffic is to be handled. The traffic may be processed according as any other DetNet IP traffic as defined in this document or in [I-D.ietf-detnet-ip], or the traffic may be directly treated as an MPLS App-flow for additional processing according to [I-D.ietf-detnet-mpls]. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow-specific resources needed to provide the traffic treatment to meet each flow's service requirements. This applies for aggregated and individual flows. Varga, et al. Expires April 14, 2021 [Page 9] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 7. Security Considerations General security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. DetNet MPLS and DetNet IP security considerations equally apply to this document and are described in [I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. Security aspects which are unique to DetNet are those whose aim is to protect the support of specific quality of service aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The primary considerations for the data plane are to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means is provided by the underlying technology. For example, encryption may be used, such as that provided by IPSec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. From a data plane perspective this document does not add or modify any header information. At the management and control level DetNet flows are identified on a per-flow basis, which may provide controller plane attackers with additional information about the data flows (when compared to controller planes that do not include per-flow identification). This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet service, provisions can be made against DOS attacks and delay attacks. To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices can be prevented or mitigated, for example through the use of existing mechanism such as policing and shaping applied at the input of a DetNet domain. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of Man-In-The- Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. 8. IANA Considerations This document makes no IANA requests. Varga, et al. Expires April 14, 2021 [Page 10] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 9. Acknowledgements The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their various contributions to this work. 10. Contributors RFC7322 limits the number of authors listed on the front page of a draft to a maximum of 5. The editor wishes to thank and acknowledge the follow authors for contributing text to this draft. Janos Farkas Ericsson Email: janos.farkas@ericsson.com Andrew G. Malis Malis Consulting Email: agmalis@gmail.com Janos Farkas contributed substantially to the content of this document. 11. References 11.1. Normative references [I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- data-plane-framework-06 (work in progress), May 2020. [I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 (work in progress), July 2020. [I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- detnet-mpls-12 (work in progress), September 2020. [I-D.ietf-detnet-security] Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", draft-ietf- detnet-security-12 (work in progress), October 2020. Varga, et al. Expires April 14, 2021 [Page 11] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 11.2. Informative references [IEEE802.1AE-2018] IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC Security (MACsec)", 2018, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Authors' Addresses Balazs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Don Fedyk LabN Consulting, L.L.C. Email: dfedyk@labn.net Varga, et al. Expires April 14, 2021 [Page 12] Internet-Draft DetNet IP over DetNet MPLS Data Plane October 2020 Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Jouni Korhonen Email: jouni.nospam@gmail.com Varga, et al. Expires April 14, 2021 [Page 13] ./draft-huitema-rfc-eval-project-07.txt0000644000764400076440000033643113745404013017242 0ustar iustyiusty Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Informational October 25, 2020 Expires: April 28, 2021 Evaluation of a Sample of RFC Produced in 2018 draft-huitema-rfc-eval-project-07 Abstract This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. We analyze a set of randomly chosen RFC approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFC published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the Working Group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH-48 phase. We also measure the number of citations of the chosen RFC using Semantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that. The RFCs selected for this survey were chosen at random and represent a small sample of all RFCs produced, and only approximately 10% of the RFCs produced in each of 1998, 2008, and 2018. It is possible that different samples would produce different results. Furthermore, the conclusions drawn from the observations made in this document represent the author's opinions and do not have consensus of the IETF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Huitema Expires April 28, 2021 [Page 1] Internet-Draft RFC-Eval-2018 October 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 28, 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Defining the Important Milestones . . . . . . . . . . . . 5 2.2. Selecting a Random Sample of RFCs . . . . . . . . . . . . 6 3. Analysis of 20 Selected RFCs . . . . . . . . . . . . . . . . 6 3.1. 8411 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. 8456 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. 8446 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. 8355 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. 8441 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. 8324 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. 8377 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. 8498 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. 8479 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.10. 8453 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.11. 8429 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.12. 8312 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.13. 8492 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.14. 8378 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.15. 8361 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.16. 8472 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.17. 8471 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.18. 8466 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.19. 8362 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Huitema Expires April 28, 2021 [Page 2] Internet-Draft RFC-Eval-2018 October 2020 3.20. 8468 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Analysis of Process and Delays . . . . . . . . . . . . . . . 19 4.1. First Draft to RFC Delays . . . . . . . . . . . . . . . . 20 4.2. Working Group Processing Time . . . . . . . . . . . . . . 25 4.3. Preparation and Publication Delays . . . . . . . . . . . 28 4.4. Copy Editing . . . . . . . . . . . . . . . . . . . . . . 31 4.5. Independent Stream . . . . . . . . . . . . . . . . . . . 34 5. Citation Counts . . . . . . . . . . . . . . . . . . . . . . . 34 5.1. Citation Numbers . . . . . . . . . . . . . . . . . . . . 35 5.2. Comparison to 1998 and 2008 . . . . . . . . . . . . . . . 37 5.3. Citations Versus Deployments . . . . . . . . . . . . . . 40 5.4. Citations Versus Web References . . . . . . . . . . . . . 42 6. Observations and Next Steps . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 10. Informative References . . . . . . . . . . . . . . . . . . . 46 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction As stated on the organization's web site, "The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet." The specifications produced by the IETF are published in the RFC series, along with independent submissions, research papers and IAB documents. In this memo, the author attempts to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. This is an individual effort, and the author's conclusions presented here are personal. There was no attempt to seek IETF consensus. The IETF keeps records of documents and process actions in the IETF datatracker [TRKR]. The IETF datatracker provides information about RFCs and drafts, from which we can infer statistics about the production system. We can measure how long it takes to drive a proposition from initial draft to final publication, and how these delays can be split between Working Group discussions, IETF reviews, IESG assessment, RFC Editor delays and final reviews by the authors - or, for Independent Stream RFCs, draft production, reviews by the Independent Stream Editor, conflict reviews, RFC Editor delays and final reviews. Tracker data is available for all RFCs, not just IETF stream RFCs. Just measuring production delays may be misleading. If the IETF or the editors of the other series simply rubber-stamped draft proposals and published them, the delays would be short but the quality and Huitema Expires April 28, 2021 [Page 3] Internet-Draft RFC-Eval-2018 October 2020 impact might suffer. We hope that most of the RFC that are published are useful, but we need a way to measure that usefulness. We try to do that by measuring the number of references of the published RFCs in Semantic Scholar [SSCH], and also by asking the authors of each RFC in the sample whether the protocols and technologies defined in the RFCs were implemented and used on the Internet. The citations measured by the Semantic Scholar include citations in other RFCs and in Internet drafts. We also measure the number of references on the web, which provides some results but would be hard to automate. In order to limit the resource required for this study, we selected at random 20 RFCs published in 2018, as explained in Section 2.2. The statistical sampling picked both IETF stream and Independent Stream documents. For comparison purposes, we also selected at random 20 RFC published in 1998 and 20 published in 2008. Limiting the sample to 20 out of 209 RFCs published in 2018 allows for in depth analysis of each RFC, but readers should be reminded that the this is a small sample. The sample is too small to apply general statistical techniques and quantify specific ratios, and discussions of correlation techniques would be inappropriate. Instead, the purpose is to identify trends, spot issues and document future work. The information gathered for every RFC in the sample is presented in Section 3. In Section 4 we analyze the production process and the sources of delays, comparing the 2018 sample to the selected samples for 1998 and 2018. In Section 5.1 we present citation counts for the RFCs in the samples, and analyze whether citation counts could be used to evaluate the quality of RFCs. The measurement of delays could be automated by processing dates and events recorded in the datatracker. The measurement of published RFCs could be complemented by statistics on abandoned drafts, which would measure the efficiency of the IETF triaging process. More instrumentation would help understanding how large delays happen during Working Group processes. These potential next steps are developed in Section 6. 2. Methodology The study reported here started with a simple idea: take a sample of RFCs, and perform an in-depth analysis of the path from the first presentation of the idea to its publication, while also trying to access the success of the resulting specification. This requires defining the key milestones that we want to track, and drawing a random sample using an unbiased process. Huitema Expires April 28, 2021 [Page 4] Internet-Draft RFC-Eval-2018 October 2020 2.1. Defining the Important Milestones The IETF datatracker records a list of events for each document processed by IETF Working Groups. This has a high granularity, and also a high variability. Most documents start life as an individual draft, are adopted by a Working Group, undergo a Working Group last call, are submitted to the IESG, undergo an IETF last call and an IESG review, get eventually approved by the IESG, and are processed for publication by the RFC Editor, but there are exceptions. Some documents are first submitted to one Working Group and then moved to another. Some documents are published through the Independent Stream, and are submitted to the Independent Stream Editor instead of the IESG. In order to simplify tabulation, we break the delay from between the submission of the first draft and the publication of the RFC in three big components: o The Working Group processing time, from the first draft to the start of the IETF last call; o The IETF processing time, which lasts from the beginning of the IETF last call to the approval by the IESG, including the reviews by various directorates; o The RFC production, from approval by the IESG to publication, including the AUTH-48 reviews. For submissions to the Independent Stream, we don't have a Working Group. We consider instead the progression of the individual draft until the adoption by the ISE as the equivalent of the "Working Group" period, and the delay from adoption by the ISE until submission to the RFC Editor as the equivalent of the IETF delay. We measure the staring point of the process using the date of submission of the first draft listed on that RFC page in the IETF datatracker. In most case, this first draft is an individual draft that then resubmitted as a Working Group draft, or maybe resubmitted with a new name as the draft was searching for a home in an IETF Working Group, or before deciding for submission on the Independent Stream. The IETF datatracker entries for RFCs and drafts do not list Working Group events like Working Group Last Call. The only intermediate event that we list between the first draft and the submission to the IESG is the Working Group Adoption. For that, we use the date of submission of the version 00 of the draft eventually published as Huitema Expires April 28, 2021 [Page 5] Internet-Draft RFC-Eval-2018 October 2020 RFC. We use the same definition for drafts submitted to the Independent Stream. 2.2. Selecting a Random Sample of RFCs Basic production mechanisms could be evaluated by processing data from the IETF datatracker, but subjective data requires manual assessment of results, which can be time consuming. Since our resources are limited, we will only perform this analysis for a small sample of RFCs, selected at random from the list of RFCs approved in 2018. Specifically, we will pick 20 RFC numbers at random between: o RFC 8307, published in January 2018, and o RFC 8511, published December 2018. The list of 20 selected RFCs is: RFC 8411, RFC 8456, RFC 8446, RFC 8355, RFC 8441, RFC 8324, RFC 8377, RFC 8498, RFC 8479, RFC 8453, RFC 8429, RFC 8312, RFC 8492 , RFC 8378, RFC 8361, RFC 8472, RFC 8471, RFC 8466, RFC 8362, and RFC 8468. When evaluating delays and impact, we will compare the year 2018 to 2008 and 1998, 10 and 20 years ago. To drive this comparison, we pick 20 RFCs at random among those published in 2008, and another 20 among those published in 1998. The list of the 20 randomly selected RFCs from 2008 is: RFC 5227, RFC 5174, RFC 5172, RFC 5354, RFC 5195, RFC 5236, RFC 5348, RFC 5281, RFC 5186, RFC 5326, RFC 5277, RFC 5373, RFC 5404, RFC 5329, RFC 5283, RFC 5358, RFC 5142, RFC 5271, RFC 5349, and RFC 5301. The list of the 20 randomly selected RFCs from 2008 is: RFC 2431, RFC 2381, RFC 2387, RFC 2348, RFC 2391, RFC 2267, RFC 2312, RFC 2448, RFC 2374, RFC 2398, RFC 2283, RFC 2382, RFC 2289, RFC 2282, RFC 2404, RFC 2449, RFC 2317, RFC 2394, RFC 2297, and RFC 2323. 3. Analysis of 20 Selected RFCs We review each of the RFCs listed in Section 2.2 for the year 2018, trying both to answer the known questions and to gather insight for further analyzes. In many cases, the analysis of the data is complemented by direct feedback from the RFC authors. 3.1. 8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range [RFC8411]: Huitema Expires April 28, 2021 [Page 6] Internet-Draft RFC-Eval-2018 October 2020 Informational, 5 pages 4 drafts (personal), first 2017-05-08. Last call announced 2017-10-09 IESG evaluation starts 2017-12-28 Approved 2018-02-26, draft 03 AUTH-48 2018-04-20 AUTH-48 complete 2018-07-17 Published 2018-08-06 IANA action: create table This RFC was published from the individual draft, which was not resubmitted as a Working Group draft. The draft underwent minor copy edit before publication. Some but not all of the long delay in AUTH-48 is due to clustering with [RFC8410]. MISSREF was cleared on 2018-05-09 and the document re-entered AUTH-48 at once. AUTH-48 lasted over two months after that. The time after AUTH-48 and before publication (3 weeks) partly overlaps with travel for IETF-102 and is partly due to coordinating the cluster. 3.2. 8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance [RFC8456]: Informational, 64 pages 2 personal drafts, 9 WG drafts, first 2015-03-23 WG adoption on 2015-10-18 Last call announced 2018-01-19 IESG evaluation starts 2018-02-27 IESG approved 2018-05-25 AUTH-48 2018-08-31 AUTH-48 complete 2018-10-16 Published 2018-10-30 The draft underwent very extensive copy editing, covering use of articles, turn of phrases, choice of vocabulary. The changes are enough to cause pagination differences. The "diff" tool marks pretty much every page as changed. Some diagrams see change in protocol elements like message names. According to the author, the experience of producing this draft mirrors a typical one in the Benchmarking Methodologies Working Group (BMWG). There were multiple authors in multiple time zones, which Huitema Expires April 28, 2021 [Page 7] Internet-Draft RFC-Eval-2018 October 2020 slowed down the AUTH-48 process somewhat, although the AUTH-48 delay of 46 days is only a bit longer than the average draft. The RFC was part of cluster with [RFC8455]. BMWG publishes informational RFCs centered around benchmarking, and the methodologies in RFC 8456 have been implemented in benchmarking products. 3.3. 8446 The Transport Layer Security (TLS) Protocol Version 1.3 [RFC8446], as the title indicates, defines the new version of the TLS protocol. From the IETF datatracker, we extract the following: Proposed standard 160 pages 29 WG drafts first 2014-04-17. Last call announced 2018-02-15 IESG evaluation starts 2018-03-02 Approved 2018-03-21, draft 28 AUTH-48 2018-06-14 AUTH-48 complete 2018-08-10 Published 2018-08-10 This draft started as a WG effort. The RFC was a major effort in the IETF. Working Group members developed and tested several implementations. Researchers analyzed the specifications and performed formal verifications. Deployment tests outlined issues that caused extra work when the specification was almost ready. These complexity largely explains the time spent in the Working Group. Comparing the final draft to the published version, we find relatively light copy editing. It includes explaining acronyms on first use, clarifying some definitions standardizing punctiation and capitalization, and spelling out some numbers in text. This generally fall in the category of "style", although some of the clarifications go into message definitions. However, that simple analysis does not explain why the AUTH-48 phase took almost two months. This document's AUTH-48 process was part of the "Github experiment", which tried to use github pull requests to track the AUTH-48 changes and review comments. The RPC staff had to learn using Github for that process, and this required more work than the usual RFC. Author and AD thoroughly reviewed each proposed edit, accepting some and Huitema Expires April 28, 2021 [Page 8] Internet-Draft RFC-Eval-2018 October 2020 rejecting some. The concern there was that any change in a complex specification might affect a protocol that was extensively reviewed in the Working Group, but of course these reviews added time to the AUTH-48 delays. There are 21 implementations listed in the Wiki of the TLS 1.3 project [TLS13IMP]. It has been deployed on major browsers, and is already used in a large fraction of TLS connections. 3.4. 8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks [RFC8355] is an informational RFC. It originated from a use case informational draft that was mostly used for the BOF creating the WG, and then to drive initial work/evolutions from the WG. Informational, 13 pages. 2 personal drafts (personal), first 2014-01-31. 13 WG drafts. WG adoption on 2014-05-13 Last call announced 2017-04-20 IESG evaluation starts 2017-05-04, draft 09 Approved 2017-12-19, draft 12 AUTH-48 2018-03-12 AUTH-48 complete 2018-03-27 Published 2018-03-28 Minor set of copy edits, mostly for style. No implementation of the RFC itself, but the technology behind it such as Segment Routing (architecture RFC 8402, TI-LFA draft-ietf- rtgwg-segment-routing-ti-lfa) is widely implemented and deployment is ongoing. According to participants in the discussion, the process of adoption of the source packet routing standards was very contentious. The establishment of consensus at both the Working Group level and the IETF level was difficult and time consuming. 3.5. 8441 Bootstrapping WebSockets with HTTP/2 [RFC8441] Huitema Expires April 28, 2021 [Page 9] Internet-Draft RFC-Eval-2018 October 2020 Proposed standard, 8 pages. Updates RFC 6455. 3 personal drafts (personal), first 2017-10-15. 8 WG drafts. WG adoption on 2017-12-19 Last call announced 2018-05-07, draft 05 IESG evaluation starts 2018-05-29, draft 06 Approved 2018-06-07, draft 07 AUTH-48 2018-08-13 AUTH-48 complete 2018-09-15 Published 2018-09-21 IANA Action: table entries This RFC defines the support of WebSockets in HTTP/2, which is different from the mechanism defined for HTTP/1.1 in [RFC6455]. The process was relatively straightforward, involving the usual type of discussions, some on details and some on important points. Comparing final draft and published RFC shows a minor set of copy edit, mostly for style. However, the author recalls a painful process. The RFC includes many charts and graphs that were very difficult to format correctly in the author's production process that involve conversions from markdown to XML, and then from XML to text. The author had to get substantial help from the RFC editor. There are several implementations, including Firefox and Chrome, making RFC 8441 a very successful specification. 3.6. 8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? [RFC8324]. This is an opinion piece on DNS development, published on the Independent Stream. Informational, 29 pages. Independent Stream. 5 personal drafts (personal), first 2017-06-02. ISE review started 2017-07-10, draft 03 IETF conflict review and IESG review started 2017-10-29 Approved 2017-12-18, draft 04 AUTH-48 2018-01-29, draft 05 AUTH-48 complete 2018-02-26 Published 2018-02-27 This RFC took only 9 months from first draft to publication, which is the shortest in the 2018 sample set. In part, this is because the text was privately circulated and reviewed by ISE designated experts before the first draft was published. The nature of the document is another reason for the short delay. It is an opinion piece, and does Huitema Expires April 28, 2021 [Page 10] Internet-Draft RFC-Eval-2018 October 2020 not require the same type of consensus building and reviews than a protocol specification. Comparing the final draft and the published version shows only minor copy edit, mostly for style. According to the author, because this is because he knows how to write in RFC Style with the result that his documents often need a minimum of editing. He also makes sure that the document on which the Production Center starts working already has changes discussed and approved during Last Call and IESG review incorporated rather than expecting the Production Center to operate off of notes about changed to be made. 3.7. 8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology [RFC8377] Proposed standard, 20 pages. Updates RFC 6325, 7177. 3 personal drafts (personal), first 2013-09-03. 7 WG drafts. WG adoption on 2015-09-01 Last call announced 2018-02-19, draft 05 IESG evaluation starts 2018-03-02, draft 06 Approved 2018-03-12, draft 05 AUTH-48 2018-04-20, draft 06 AUTH-48 complete 2018-07-31 Published 2018-07-31 IANA Table, table entries Minor set of copy edits, mostly for style, also clarity. 3.8. 8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) [RFC8498]. Informational, 15 pages. 5 personal drafts (personal), first 2016-03-21. 9 WG drafts. WG adoption on 2017-05-15 Last call announced 2018-10-12, draft 05 IESG evaluation starts 2018-11-28, draft 07 Approved 2018-12-10, draft 08 AUTH-48 2019-01-28 AUTH-48 complete 2019-02-13 Published 2019-02-15 IANA Action, table rows added. Copy edit for style, but also clarification of ambiguous sentences. Huitema Expires April 28, 2021 [Page 11] Internet-Draft RFC-Eval-2018 October 2020 3.9. 8479 Storing Validation Parameters in PKCS#8 [RFC8479] Informational, 8 pages. Independent Stream. 5 personal drafts (personal), first 2017-08-08. ISE review started 2018-12-10, draft 00 IETF conflict review and IESG review started 2018-03-29 Approved 2018-08-20, draft 03 AUTH-48 2018-09-20, draft 04 AUTH-48 complete 2018-09-25 Published 2018-09-26 The goal of the draft was to document what the gnutls implementation was using for storing provably generated RSA keys. This is a short RFC that was published relatively quickly, although discussion between the author, the Independent Series Editor and the IESG lasted several months. In the initial conflict review, The IESG asked the ISE to not publish this document before IETF Working Groups had an opportunity to pick up the work. The author met that requirement by a presentation to the SECDISPATCH WG in IETF 102. Since no WG was interested in pickup the work, the document progressed on the Independent Stream. Very minor set of copy edit, moving some references from normative to informative. The author is not aware of other implementations than gnutls relying on this RFC. 3.10. 8453 Framework for Abstraction and Control of TE Networks (ACTN) [RFC8453] Informational, 42 pages. 3 personal drafts, first 2015-06-15. 16 WG drafts. WG adoption on 2016-07-15 Out of WG 2018-01-26, draft 11 Expert review requested, 2018-02-13 Last call announced 2018-04-16, draft 13 IESG evaluation starts 2018-05-16, draft 14 Approved 2018-06-01, draft 15 AUTH-48 2018-08-13 AUTH-48 complete 2018-08-20 Published 2018-08-20 IANA Action, table rows added. Minor copy editing. Huitema Expires April 28, 2021 [Page 12] Internet-Draft RFC-Eval-2018 October 2020 3.11. 8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos [RFC8429] BCP, 10 pages. 6 WG drafts, first 2017-05-01. Last call announced 2017-07-16, draft 03 IESG evaluation starts 2017-08-18, draft 04 Approved 2018-05-25, draft 05 AUTH-48 2018-07-24 AUTH-48 complete 2018-10-31 Published 2018-10-31 IANA Action, table rows added. This draft started as a Working Group effort. This RFC recommends to deprecate two encryption algorithms that are now considered obsolete and possibly broken. The document was sent back to the WG after the first last call, edited, and then there was a second last call. The delay from first draft to Working Group last call was relatively short, but the number may be misleading. The initial draft was a replacement of a similar draft in the KITTEN Working Group, which stagnated for some time before the CURDLE Working Group took up the work. The deprecation of RC4 was somewhat contentious, but the WG had already debated this prior to the production of this draft, and the draft was not delayed by this debate. Most of the 280 days between IETF LC and IESG approval was because the IESG had to talk about whether this document should obsolete or move to historic RFC 4757, and no one was really actively pushing that discussion for a while. The 99 days in AUTH-48 are mostly because one of the authors was a sitting AD, and those duties ended up taking precedence over reviewing this document. Minor copy editing, for style. The implementation of the draft would be the actual removal of support for 3DES and RC4 in major implementations. This is happening, but very slowly. 3.12. 8312 CUBIC for Fast Long-Distance Networks [RFC8312] Huitema Expires April 28, 2021 [Page 13] Internet-Draft RFC-Eval-2018 October 2020 Informational, 18 pages. 2 personal drafts, first 2014-09-01. 8 WG drafts WG adoption on 2015-06-08 Last call announced 2017-09-18, draft 06 IESG evaluation starts 2017-11-14 Approved 2017-10-04, draft 07 AUTH-48 2018-01-08 AUTH-48 complete 2018-02-07 Published 2018-02-07 IANA Action, table rows added. Minor copy editing, for style. The TCP congestion control algorithm Cubic was defined first in 2005, was implemented in Linux soon after, and was implemented in major OSes after that. After some debates from 2015 to 2015, the TCPM Working Group adopted the draft, with a goal of documenting Cubic in the RFc series. According to the authors, this was not a high priority effort, as Cubic was already implemented in multiple OSes and documented in research papers. At some point, only one of the authors was actively working on the draft. Ths may explain why another two years was spent progressing the draft after adoption by the WG. The RFC publication may or may not have triggered further implementations. On the other hand, several OSes picked up bug fixes from the draft and the RFC. 3.13. 8492 Secure Password Ciphersuites for Transport Layer Security (TLS) [RFC8492] Informational, 40 pages. (Independent Stream) 10 personal drafts, first 2012-09-07. 8 WG drafts Targeted to ISE stream 2016-08-05 ISE review started 2017-05-10, draft 01 IETF conflict review and IESG review started 2017-09-04 Approved 2017-10-29, draft 04 AUTH-48 2018-10-19, draft 05 AUTH-48 complete 2019-02-19 Published 2019-02-21 IANA Action, table rows added. This RFC has a complex history. The first individual draft was submitted to the TLS Working Group on September 7, 2012. It progressed there, and was adopted by the WG after 3 revisions. There were then 8 revisions in the TLS WG, until the WG decided to not Huitema Expires April 28, 2021 [Page 14] Internet-Draft RFC-Eval-2018 October 2020 progress it. The draft was parked in 2013 by the WG chairs after failing to get consensus in WG last call. The AD finally pulled the plug in 2016, and the draft was then resubmitted to the ISE. At that point, the author was busy and was treating this RFC with a low priority because, in his words, it would not be a "real RFC". There were problems with the draft that only came up late. In particular, it had to wait for a change in registry policy that only came about with the publication of TLS 1.3, which caused the draft to only be published after RFC 8446, and also required adding references to TLS 1.3. The author also got a very late comment while in AUTH-48 that caused some rewrite. Finally, there was some IANA issue with the extension registry where a similar extension was added by someone else. The draft was changed to just use it. Changes in AUTH-48 include added reference to TLS 1.3, copy-editing for style, some added requirements, added paragraphs, and changes in algorithms specification. 3.14. 8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast [RFC8378] is an experimental RFC, defining how to implement Multicast in the LISP architecture. Experimental, 21 pages. 5 personal drafts, first 2014-02-28. 10 WG drafts WG adoption on 2015-12-21 Last call announced 2018-02-13, draft 07 IESG evaluation starts 2018-02-28, draft 08 Approved 2018-03-12, draft 09 AUTH-48 2018-04-23 AUTH-48 complete 2018-05-02 Published 2018-05-02 Preparing the RFC took more than 4 years. According to the authors, they were not aggressive pushing it and just let the Working Group process decide to pace it. They also did implementations during that time. Minor copy editing, for style. The RFC was implemented by lispers.net and cisco, and was used in doing IPv6 multicast over IPv4 unicast/multicast at the Olympics in PyeungChang. The plan is to work on a proposedstandard once the experiment concludes. Huitema Expires April 28, 2021 [Page 15] Internet-Draft RFC-Eval-2018 October 2020 3.15. 8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic [RFC8361] Proposed Standard, 17 pages. 3 personal drafts, first 2013-11-12. 14 WG drafts WG adoption on 2014-12-16 Last call announced 2017-11-28, draft 10 IESG evaluation starts 2017-12-18, draft 11 Approved 2018-01-29, draft 13 AUTH-48 2018-03-09 AUTH-48 complete 2018-04-09 Published 2018-04-12 According to the authors, the long delays in producing this RFC was due to a slow uptake of the technology in the industry. Minor copy editing, for style. There was at least 1 partial implementation. 3.16. 8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation [RFC8472] Proposed Standard, 8 pages. 1 personal drafts, 2015-05-29. 15 WG drafts WG adoption on 2015-09-11 Last call announced 2017-11-13, draft 10 IESG evaluation starts 2018-03-19 Approved 2018-07-20, draft 14 AUTH-48 2018-09-17 AUTH-48 complete 2018-09-25 Published 2018-10-08 This is a pretty simple document, but it took over 3 years from individual draft to RFC. According to the authors,the biggest setbacks occurred at the start: it took a while to find a home for this draft. It was presented in the TLS WG (because it's a TLS extension) and UTA WG (because it has to do with applications using TLS). Then the ADs determined that a new WG was needed, so the authors had to work through the WG creation process, including running a BOF. Huitema Expires April 28, 2021 [Page 16] Internet-Draft RFC-Eval-2018 October 2020 Minor copy editing, for style, with the addition of a reference to TLS 1.3. Perhaps partially due to the delays, some of the implementers lost interest in supporting this RFC. 3.17. 8471 The Token Binding Protocol Version 1.0 [RFC8471] Proposed Standard, 18 pages. 1 personal drafts, 2014-10-13. 19 WG drafts WG adoption on 2015-03-15 Last call announced 2017-11-13, draft 16 IESG evaluation starts 2018-03-19 Approved 2018-07-20, draft 19 AUTH-48 2018-09-17 AUTH-48 complete 2018-09-25 Published 2018-10-08 Presentation of a Token Binding Protocol for TLS. We can notice a delay of 5 months before adoption of the draft by the WG. That explains in part the overall delay of almost 4 years from first draft to publication. Minor copy editing, for style. The web references indicates adoption in multiple development projects. 3.18. 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery [RFC8466] Proposed Standard, 158 pages. 5 personal drafts, first 2016-09-01. 11 WG drafts WG adoption on 2017-02-26 Last call announced 2018-02-21, draft 07 IESG evaluation starts 2018-03-14, draft 08 Approved 2018-06-25, draft 10 AUTH-48 2018-09-17 AUTH-48 complete 2018-10-09 Published 2018-10-12 Copy editing for style and clarity, with also corrections to the yang model. Huitema Expires April 28, 2021 [Page 17] Internet-Draft RFC-Eval-2018 October 2020 3.19. 8362 OSPFv3 Link State Advertisement (LSA) Extensibility [RFC8362] is a major extension to the OSPF protocol. It makes OSPFv3 fully extensible. Proposed Standard, 33 pages. 4 personal drafts, first 2013-02-17. 24 WG drafts WG adoption on 2013-10-15 Last call announced 2017-12-19, draft 19 IESG evaluation starts 2018-01-18, draft 20 Approved 2018-01-29, draft 23 AUTH-48 2018-03-19 AUTH-48 complete 2018-03-30 Published 2018-04-03 The specification was first submitted as a personal draft in the IPv6 WG, then moved to the OSPF WG. The long delay of producing this RFC is due to the complexity of the problem, and the need to wait for implementations. It is a very important change to OSPF that makes OSPFv3 fully extensible. Since it was a non-backward compatible change, the developers started out with some very complex migration scenarios but ended up with either legacy or extended OSPFv3 LSAs within an OSPFv3 routing domain. The initial attempts to have a hybrid mode of operation with both legacy and extended LSAs also delayed implementation due to the complexity. Copy editing for style and clarity. This specification either was or will be implemented by all the router vendors. 3.20. 8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework [RFC8468]. Informational, 15 pages. 3 personal drafts, first 2015-08-06. 7 WG drafts WG adoption on 2016-07-04 Last call announced 2018-04-11, draft 04 IESG evaluation starts 2018-05-24, draft 05 Approved 2018-07-10, draft 06 AUTH-48 2018-09-13 AUTH-48 complete 2018-11-05 Published 2018-11-14 Huitema Expires April 28, 2021 [Page 18] Internet-Draft RFC-Eval-2018 October 2020 RFC8468 was somehow special in that there was not a technical reason/ interest that triggered it, but rather a formal requirement. While writing RFC7312 the IP Performance Metrics Working Group (IPPM) realized that RFC 2330, the IP Performance Metrics Framework supported IPv4 only and explicitly excluded support for IPv6. Nevertheless, people used the metrics that were defined on top of RFC 2330 (and, therefore, IPv4 only) for IPv6, too. Although the IPPM WG agreed that the work was needed, the interest of IPPM attendees in progressing (and reading/reviewing) the IPv6 draft was limited. Resolving the IPv6 technical part was straight-forward, but subsequently some people asked for a broader scope (topics like header compression, 6lo, etc.) and it took some time to figure out and later on convince people that these topics are out of scope. The group also had to resolve contentious topics, for example how to measure the processing of IPv6 extension headers, which is sometimes non-standard. The AUTH-48 delay for this draft was longer than average. According to the authors, the main reasons include: o Work-load and travel caused by busy-work-periods of all co-authors o Time zone difference between co-authors and editor (at least US, Europe, India, not considering travel) o Editor proposing and committing some unacceptable modifications that needed to be reverted o Lengthy discussions on a new document title (required high effort and took a long time, in particular reaching consensus between co- authors and editor was time-consuming and involved the AD) o Editor correctly identifying some nits (obsoleted personal websites of co-authors) and co-authors attempting to fix them. The differences between the final draft and the publish RFC show copy editing for style and clarity, but do not account for the back and forth between authors and editors mentioned by the authors. 4. Analysis of Process and Delays We examine the 20 RFCs in the sample, measuring various characteristics such as delay and citation counts, in an attempt to identify patterns in the IETF processes. Huitema Expires April 28, 2021 [Page 19] Internet-Draft RFC-Eval-2018 October 2020 4.1. First Draft to RFC Delays We look at the distribution of delays between the submission of the first draft and the publication of the RFC, using the three big milestones defined in Section 2.1: processing time in the Working Group, IETF processing time, and publication delay. The following table shows the delays for the 20 RFCs in the sample: Huitema Expires April 28, 2021 [Page 20] Internet-Draft RFC-Eval-2018 October 2020 +------+------------------+-------+---------+------+------+------+ | RFC | Status | Pages | Overall | WG | IETF | Edit | +------+------------------+-------+---------+------+------+------+ | 8411 | Info | 5 | 455 | 154 | 140 | 161 | | | | | | | | | | 8456 | Info | 64 | 1317 | 1033 | 126 | 158 | | | | | | | | | | 8446 | PS | 160 | 1576 | 1400 | 34 | 142 | | | | | | | | | | 8355 | Info | 13 | 1517 | 1175 | 243 | 99 | | | | | | | | | | 8441 | PS | 8 | 341 | 204 | 31 | 106 | | | | | | | | | | 8324 | ISE | 29 | 270 | 38 | 161 | 71 | | | | | | | | | | 8377 | PS | 8 | 1792 | 1630 | 21 | 141 | | | | | | | | | | 8498 | Info | 15 | 1061 | 935 | 59 | 67 | | | | | | | | | | 8479 | ISE | 8 | 414 | 233 | 144 | 37 | | | | | | | | | | 8453 | Info | 42 | 1162 | 1036 | 46 | 80 | | | | | | | | | | 8429 | BCP | 10 | 548 | 76 | 313 | 159 | | | | | | | | | | 8312 | Info | 18 | 1255 | 1113 | 16 | 126 | | | | | | | | | | 8492 | ISE | 40 | 2358 | 1706 | 172 | 480 | | | | | | | | | | 8378 | Exp | 21 | 1524 | 1446 | 27 | 51 | | | | | | | | | | 8361 | PS | 17 | 1612 | 1477 | 62 | 73 | | | | | | | | | | 8472 | PS | 8 | 1228 | 899 | 249 | 80 | | | | | | | | | | 8471 | PS | 18 | 1228 | 899 | 249 | 80 | | | | | | | | | | 8466 | PS | 158 | 771 | 538 | 124 | 109 | | | | | | | | | | 8362 | PS | 33 | 1871 | 1766 | 41 | 64 | | | | | | | | | | 8468 | Info | 15 | 1196 | 979 | 90 | 127 | | | | | | | | | | | average | 35 | 1186 | 948 | 117 | 121 | | | | | | | | | | | average(not ISE) | 36 | 1217 | 999 | 110 | 107 | +------+------------------+-------+---------+------+------+------+ Huitema Expires April 28, 2021 [Page 21] Internet-Draft RFC-Eval-2018 October 2020 The average delay from first draft to publication is about 3 years and 3 months, but this varies widely. Excluding the Independent Stream submissions, the average delay from start to finish is 3 years and 4 months, of which on average 2 years and 9 months are spent getting consensus in the Working Group, and 3 to 4 months each for IETF consensus and for RFC production. The longest delay is found for [RFC8492], 6.5 years from start to finish. This is however a very special case, a draft that was prepared for the TLS Working Group and failed to reach consensus. After that, it was resubmitted to the ISE, and incurred atypical production delays. On average, we see that 80% of the delay is incurred in WG processing, 10% in IETF review, and 10% for edition and publication. For IETF stream RFCs, it appears that the delays for informational documents are slightly shorter than those for protocol specifications, maybe six months shorter on average. However, there are lots of differences between individual documents. The delays range from less than a year to more than 5 years for protocol specifications, and from a year and 3 months to a bit more than 4 years for informational documents. We can compare the delays in the 2018 samples to those observed 10 years ago and 20 years before: Huitema Expires April 28, 2021 [Page 22] Internet-Draft RFC-Eval-2018 October 2020 +------------+--------+-------+-------+ | RFC (2008) | Status | Pages | Delay | +------------+--------+-------+-------+ | 5326 | Exp | 54 | 1584 | | | | | | | 5348 | PS | 58 | 823 | | | | | | | 5281 | Info | 51 | 1308 | | | | | | | 5354 | Exp | 23 | 2315 | | | | | | | 5227 | PS | 21 | 2434 | | | | | | | 5329 | PS | 12 | 1980 | | | | | | | 5277 | PS | 35 | 912 | | | | | | | 5236 | ISE | 26 | 1947 | | | | | | | 5358 | BCP | 7 | 884 | | | | | | | 5271 | Info | 22 | 1066 | | | | | | | 5195 | PS | 10 | 974 | | | | | | | 5283 | PS | 12 | 1096 | | | | | | | 5186 | Info | 6 | 2253 | | | | | | | 5142 | PS | 13 | 1005 | | | | | | | 5373 | PS | 24 | 1249 | | | | | | | 5404 | PS | 27 | 214 | | | | | | | 5172 | PS | 7 | 305 | | | | | | | 5349 | Info | 10 | 1096 | | | | | | | 5301 | PS | 6 | 396 | | | | | | | 5174 | Info | 8 | 427 | +------------+--------+-------+-------+ Huitema Expires April 28, 2021 [Page 23] Internet-Draft RFC-Eval-2018 October 2020 +------------+--------+-------+---------+ | RFC (1998) | Status | Pages | Delay | +------------+--------+-------+---------+ | 2289 | PS | 25 | 396 | | | | | | | 2267 | Info | 10 | unknown | | | | | | | 2317 | BCP | 10 | 485 | | | | | | | 2404 | PS | 7 | 488 | | | | | | | 2374 | PS | 12 | 289 | | | | | | | 2449 | PS | 19 | 273 | | | | | | | 2283 | PS | 9 | 153 | | | | | | | 2394 | Info | 6 | 365 | | | | | | | 2348 | DS | 5 | 699 | | | | | | | 2382 | Info | 30 | 396 | | | | | | | 2297 | ISE | 109 | 28 | | | | | | | 2381 | PS | 43 | 699 | | | | | | | 2312 | Info | 20 | 365 | | | | | | | 2387 | PS | 10 | 122 | | | | | | | 2398 | Info | 15 | 396 | | | | | | | 2391 | PS | 10 | 122 | | | | | | | 2431 | PS | 10 | 457 | | | | | | | 2282 | Info | 14 | 215 | | | | | | | 2323 | ISE | 5 | unknown | | | | | | | 2448 | ISE | 7 | 92 | +------------+--------+-------+---------+ We can compare the median delay, and the delays observed by the fastest and slowest quartiles in the three years: Huitema Expires April 28, 2021 [Page 24] Internet-Draft RFC-Eval-2018 October 2020 +------+-------------+--------+-------------+ | Year | Fastest 25% | Median | Slowest 25% | +------+-------------+--------+-------------+ | 2018 | 604 | 1179 | 1522 | | | | | | | 2008 | 869 | 1081 | 1675 | | | | | | | 1998 | 169 | 365 | 442 | +------+-------------+--------+-------------+ The IETF takes three to four times more times to produce an RFC in 2018 than it did in 1998, but about the same time as it did in 2008. We can get a rough estimate of how this translates in term of "level of attention" per RFC by comparing the number of participants in the IETF meetings of 2018, 2008 and 1998 [IETFCOUNT] to the number of RFC published these years [RFCYEAR]. +------+------+---------+---------+------+----------+---------------+ | Year | Nb | Spring | Summer | Fall | Average | Attendees/RFC | | | RFC | P. | P. | | P. | | +------+------+---------+---------+------+----------+---------------+ | 2018 | 208 | 1235 | 1078 | 879 | 1064 | 5.1 | | | | | | | | | | 2008 | 290 | 1128 | 1181 | 962 | 1090 | 3.8 | | | | | | | | | | 1998 | 234 | 1775 | 2106 | 1705 | 1862 | 9.0 | +------+------+---------+---------+------+----------+---------------+ The last column in the table provides the ratio of average number of participants by number of RFC produced. If the IETF was a centralized organization, if all participants and documents were equivalent, this ratio would be the number of participants dedicated to produce an RFC on a given year. This is of course a completely abstract figure because none of the hypotheses above is true, but it still gives a vague indication of the "level of attention" applied to documents. We see that this ratio has increased from 2008 to 2018, as the number of participants was about the same for these two years but the number of published RFCs decreased. However, that ratio was much higher in 1998. The IETF had many more participants, and there were probably many more eyes available to review any given draft. If we applied the ratios of 1998, the IETF would be producing 119 documents in 2018 instead of 208. 4.2. Working Group Processing Time The largest part of the delays is spent in the Working Groups, before the draft is submitted to the IESG for IETF review. As mentioned in Section 2.1, the only intermediate milestone that we can extract from Huitema Expires April 28, 2021 [Page 25] Internet-Draft RFC-Eval-2018 October 2020 the IETF datatracker is the date at which the document was adopted by the Working Group, or targeted for independent submission. The breakdown of the delays for the documents in our sample is: Huitema Expires April 28, 2021 [Page 26] Internet-Draft RFC-Eval-2018 October 2020 +------+---------+------+----------------+----------------+ | RFC | Status | WG | Until adoption | After adoption | +------+---------+------+----------------+----------------+ | 8411 | Info | 154 | 0 | 154 | | | | | | | | 8456 | Info | 1033 | 209 | 824 | | | | | | | | 8446 | PS | 1400 | 0 | 1400 | | | | | | | | 8355 | Info | 1175 | 102 | 1073 | | | | | | | | 8441 | PS | 204 | 65 | 139 | | | | | | | | 8324 | ISE | 38 | 0 | 38 | | | | | | | | 8377 | PS | 1630 | 728 | 902 | | | | | | | | 8498 | Info | 935 | 420 | 515 | | | | | | | | 8479 | ISE | 233 | 0 | 233 | | | | | | | | 8453 | Info | 1036 | 396 | 640 | | | | | | | | 8429 | BCP | 76 | 0 | 76 | | | | | | | | 8312 | Info | 1113 | 280 | 833 | | | | | | | | 8492 | ISE | 1706 | 1428 | 278 | | | | | | | | 8378 | Exp | 1446 | 661 | 785 | | | | | | | | 8361 | PS | 1477 | 399 | 1078 | | | | | | | | 8472 | PS | 899 | 105 | 794 | | | | | | | | 8471 | PS | 1127 | 153 | 794 | | | | | | | | 8466 | PS | 538 | 178 | 360 | | | | | | | | 8362 | PS | 1766 | 240 | 1526 | | | | | | | | 8468 | Info | 979 | 333 | 646 | | | | | | | | | Average | 948 | 285 | 663 | +------+---------+------+----------------+----------------+ The time before Working Group adoption average to a bit more than 9 months, compared to 1 years and almost 10 months for processing time Huitema Expires April 28, 2021 [Page 27] Internet-Draft RFC-Eval-2018 October 2020 after adoption. We see that RFC 8492 stands out, with long delays spent attempting publication through a Working Group before submission to the Independent Stream Editor. If we removed RFC 8492 from the list, the average time until adoption drops to just over 7 months, and becomes just 25% of the total processing time in the WG. There are a few documents that started immediately as Working Group efforts, or were immediately targeted for publication in the Independent Stream. Those documents tend to see short processing times, with the exception of RFC 8446 on which the TLS Working Group spent a long time working. 4.3. Preparation and Publication Delays The preparation and publication delays include three components: o the delay from submission to the RFC Editor to beginning of AUTH- 48, during which the document is prepared; o the AUTH-48 delay, during which authors review and eventually approve the changes proposed by the editors; o the publication delay, from final agreement by authors and editors to actual publication. The breakdown of the publication delays for each RFC is shown in the following table. Huitema Expires April 28, 2021 [Page 28] Internet-Draft RFC-Eval-2018 October 2020 +-------+---------+-------+--------+---------+--------+-------------+ | RFC | Status | Pages | RFC | AUTH-48 | RFC | Edit(total) | | | | | edit | | Pub | | +-------+---------+-------+--------+---------+--------+-------------+ | 8411 | Info | 5 | 53 | 88 | 20 | 161 | | | | | | | | | | 8456 | Info | 64 | 98 | 46 | 14 | 158 | | | | | | | | | | 8446 | PS | 160 | 85 | 57 | 0 | 142 | | | | | | | | | | 8355 | Info | 13 | 83 | 15 | 1 | 99 | | | | | | | | | | 8441 | PS | 8 | 67 | 33 | 6 | 106 | | | | | | | | | | 8324 | ISE | 29 | 42 | 28 | 1 | 71 | | | | | | | | | | 8377 | PS | 8 | 39 | 102 | 0 | 141 | | | | | | | | | | 8498 | Info | 15 | 49 | 16 | 2 | 67 | | | | | | | | | | 8479 | ISE | 8 | 31 | 5 | 1 | 37 | | | | | | | | | | 8453 | Info | 42 | 73 | 7 | 0 | 80 | | | | | | | | | | 8429 | BCP | 10 | 60 | 99 | 0 | 159 | | | | | | | | | | 8312 | Info | 18 | 96 | 30 | 0 | 126 | | | | | | | | | | 8492 | ISE | 40 | 355 | 123 | 2 | 480 | | | | | | | | | | 8378 | Exp | 21 | 42 | 9 | 0 | 51 | | | | | | | | | | 8361 | PS | 17 | 39 | 31 | 3 | 73 | | | | | | | | | | 8472 | PS | 8 | 59 | 8 | 13 | 80 | | | | | | | | | | 8471 | PS | 18 | 59 | 8 | 13 | 80 | | | | | | | | | | 8466 | PS | 158 | 84 | 22 | 3 | 109 | | | | | | | | | | 8362 | PS | 33 | 49 | 11 | 4 | 64 | | | | | | | | | | 8468 | Info | 15 | 65 | 53 | 9 | 127 | | | | | | | | | | | Average | | 76 | 40 | 5 | 121 | | | | | | | | | | -8492 | Average | | 62 | 35 | 5 | 102 | +-------+---------+-------+--------+---------+--------+-------------+ Huitema Expires April 28, 2021 [Page 29] Internet-Draft RFC-Eval-2018 October 2020 On average, the total delay appears to be about four months, but the average is skewed by the extreme values encountered for [RFC8492]. If we exclude that RFC from the computations, the average delay drops to a just a bit more than 3 months: about 2 months for the preparation, a bit more than one month for the AUTH-48 phase, and 5 days for the publishing. Of course, these delays vary from RFC to RFC. To try explain the causes of the delay, we compute the correlation factor between the observed delays and several plausible explanation factors: o The number of pages in the document, o The amount of copy edit, as discussed in Section 4.4, o Whether or not an IANA action was required, o The number of authors, o The number of drafts revisions, o The Working Group delay. We find the following values: +-------------+----------+---------+-------------+ | Correlation | RFC edit | AUTH-48 | Edit(total) | +-------------+----------+---------+-------------+ | Nb pages | 0.50 | -0.04 | 0.21 | | | | | | | Copy-Edit | 0.42 | 0.24 | 0.45 | | | | | | | IANA | -0.14 | -0.21 | 0.12 | | | | | | | Nb Authors | 0.39 | -0.07 | 0.18 | | | | | | | Nb drafts | 0.18 | -0.33 | -0.19 | | | | | | | WG delay | 0.03 | -0.16 | -0.15 | +-------------+----------+---------+-------------+ We see some plausible explanations for the production delay. It will be somewhat longer for longer documents, or for documents that require a lot of copy editing (see Section 4.4). Somewhat surprisingly, it also tend to increase with the number of authors. It does not appear significantly correlated with the presence or absence of IANA action. Huitema Expires April 28, 2021 [Page 30] Internet-Draft RFC-Eval-2018 October 2020 The analysis of RFC 8324 in Section 3.6 explains its short editing delays by the experience of the author. This makes sense: if a document needs less editing, the editing delays would be shorter. This is partially confirmed by the relation between the amount of copy editing and the publication delay. We see fewer plausible explanations for the AUTH48 delays. These delays vary much more than the preparation delay, with a standard deviation of 20 days for AUTH-48 versus 10 days for the preparation delay. In theory, AUTH-48 is just a final verification: the authors receive the document prepared by the RFC production center, and just have to give their approval, or maybe request a last minute correction. The name indicates that this is expected to last just two days, but in average it lasts more than a month. We often hypothesize that the number of authors influences the AUTH-48 delay, or that authors who have spent a long time working on the document in the Working Group somehow get demotivated and spend even longer to answer questions during AUTH-48. This may happen sometimes, but our statistics don't show that - if anything, the numerical results point in the opposite direction. After asking the authors of the RFCs in the sample why the AUTH-48 phase took a long time, we got three explanations: 1- Some RFCs have multiple authors in multiple time zones. This slows down the coordination required for approving changes. 2- Some authors found some of the proposed changes unnecessary or undesirable, and asked that they be reversed. This required long exchanges between authors and editors. 3- Some authors were not giving high priority to AUTH-48 responses. As mentioned above, we were not able to verify these hypotheses by looking at the data. The author's experience with this document suggests another potential delay for the Independent Stream RFC: processing delay by the Independent Stream Editor, discussed in Section 4.5. 4.4. Copy Editing We can assess the amount of copy editing applied to each published RFC by comparing the text of the draft approved for publication and the text of the RFC. We do expect differences in the "boilerplate" and in the IANA section, but we will also see differences due to copy editing. Assessing the amount of copy editing is subjective, and we do it using a scale of 1 to 4: Huitema Expires April 28, 2021 [Page 31] Internet-Draft RFC-Eval-2018 October 2020 1- Minor editing 2- Editing for style, such as capitalization, hyphens, that versus which, and expending all acronyms at least one. 3- Editing for clarity in addition to style, such as rewriting ambiguous sentences and clarifying use of internal references. For Yang models, that may include model corrections suggested by the verifier. 4- Extensive editing. The following table shows that about half of the RFCs required editing for style, and the other half at least some editing for clarity. Huitema Expires April 28, 2021 [Page 32] Internet-Draft RFC-Eval-2018 October 2020 +------+--------+-----------+ | RFC | Status | Copy Edit | +------+--------+-----------+ | 8411 | Info | 2 | | | | | | 8456 | Info | 4 | | | | | | 8446 | PS | 3 | | | | | | 8355 | Info | 2 | | | | | | 8441 | PS | 2 | | | | | | 8324 | ISE | 2 | | | | | | 8377 | PS | 3 | | | | | | 8498 | Info | 3 | | | | | | 8479 | ISE | 1 | | | | | | 8453 | Info | 2 | | | | | | 8429 | BCP | 2 | | | | | | 8312 | Info | 2 | | | | | | 8492 | ISE | 3 | | | | | | 8378 | Exp | 2 | | | | | | 8361 | PS | 2 | | | | | | 8472 | PS | 2 | | | | | | 8471 | PS | 2 | | | | | | 8466 | PS | 3 | | | | | | 8362 | PS | 3 | | | | | | 8468 | Info | 3 | +------+--------+-----------+ This method of assessment does not take into account the number of changes proposed by the editors and eventually rejected by the authors, since these changes are not present in either the final Huitema Expires April 28, 2021 [Page 33] Internet-Draft RFC-Eval-2018 October 2020 draft or the published RFC. It might be possible to get an evaluation of these "phantom changes" from the RFC Production Center. 4.5. Independent Stream Out of 20 randomly selected RFCs, 3 were published through the Independent Stream. One is an independent opinion, another a description of a non-IETF protocol format, and the third was [RFC8492], which is a special case. Apart from this special case, the publication delays were significantly shorter for the Independent Stream than for the IETF stream. The authors of these 3 RFCs are regular IETF contributors. This observation motivated a secondary analysis of all the RFCs published in the Independent Stream in 2018. There are 14 such RFCs: 8507, 8494, 8493, 8492, 8483, 8479, 8433, 8409, 8374, 8369, 8367, 8351, 8328 and 8324. (RFC 8367 and 8369 were published on 1 April 2018.) The majority of the documents were published by regular IETF participants, but two of them were not. One describes "The BagIt File Packaging Format (V1.0)" [RFC8493], and the other the "Yeti DNS Testbed" [RFC8483]. They document a data format and a system developed outside the IETF, and illustrate the outreach function of the Independent Stream. In both cases, the authors include one experienced IETF participant, who presumably helped outsiders navigate the publication process. Th present document experienced some publication delays due to the Independent Stream Editor. The ISE is a bottleneck and is a volunteer resource. Although the ISE as a lone person operating as a volunteer is still roughly adequate resource for the job, the delivery will necessarily be best effort with delays caused by spikes in ISE load, work commitments, and other life events. These delays may not be fundamentally critical to RFC delivery, but they are capable of introducing a significant percentage delay into what might otherwise be a smooth process. 5. Citation Counts In this exploration, we want to assess whether citation counts provide a meaningful assessment of the popularity of RFCs. We obtain the citation counts through the Semantic Scholar API, using queries of the form: http://api.semanticscholar.org/ v1/paper/10.17487/rfc8446?include_unknown_references=true In these queries, the RFC is uniquely identified by its DOI reference, which is composed of the RFC Series prefix 10.17487 and Huitema Expires April 28, 2021 [Page 34] Internet-Draft RFC-Eval-2018 October 2020 the RFC identifier. The queries return a series of properties, including a list of citations for the RFC. Based on that list of citations, we compute three numbers: o The total number of citations o The number of citations in the year of publication and the year after that o For the RFC published in 1998 or 2008 that we use for comparison, the number of citations in the years 2018 and 2019. All the numbers were retrieved on October 6, 2019. 5.1. Citation Numbers As measured on October 6, 2019, the citation counts for the RFC in our sample set were: Huitema Expires April 28, 2021 [Page 35] Internet-Draft RFC-Eval-2018 October 2020 +-----------+--------+-------+-----------+ | RFC(2018) | Status | Total | 2018-2019 | +-----------+--------+-------+-----------+ | 8411 | Info | 1 | 0 | | | | | | | 8456 | Info | 1 | 1 | | | | | | | 8446 | PS | 418 | 204 | | | | | | | 8355 | Info | 3 | 3 | | | | | | | 8441 | PS | 1 | 1 | | | | | | | 8324 | ISE | 0 | 0 | | | | | | | 8377 | PS | 0 | 0 | | | | | | | 8498 | Info | 0 | 0 | | | | | | | 8479 | ISE | 0 | 0 | | | | | | | 8453 | Info | 3 | 3 | | | | | | | 8429 | BCP | 0 | 0 | | | | | | | 8312 | Info | 25 | 16 | | | | | | | 8492 | ISE | 4 | 4 | | | | | | | 8378 | Exp | 1 | 1 | | | | | | | 8361 | PS | 0 | 0 | | | | | | | 8472 | PS | 1 | 1 | | | | | | | 8471 | PS | 1 | 1 | | | | | | | 8466 | PS | 0 | 0 | | | | | | | 8362 | PS | 1 | 1 | | | | | | | 8468 | Info | 1 | 1 | +-----------+--------+-------+-----------+ The results indicate that [RFC8446] is by far the most cited of the 20 RFC in our sample. This is not surprising, since TLS is a key Internet Protocol. The TLS 1.3 protocol was also the subject of extensive studies by researchers, and thus was mentioned in a number Huitema Expires April 28, 2021 [Page 36] Internet-Draft RFC-Eval-2018 October 2020 of published papers. Surprisingly, the Semantic Scholar mentions a number of citations that predate the publication date. These are probably citations of the various draft versions of the protocol. The next most cited RFC in the sample is [RFC8312] which describes the Cubic congestion control algorithm for TCP. That protocol was also the target of a large number of academic publications.The other RFC in the sample only have a small number of citations. There is probably a small bias when measuring citations at a fixed date. An RFC published in January 2018 would have more time to accrue citations than one published in December. That may be true to some extent, as the second most cited RFC in the set was published in January. However, the effect has to be limited. The most cited RFC was published in August, and the second most cited was published in 2019. (That RFC got an RFC number in 2018, but publication was slowed by long AUTH-48 delays.) 5.2. Comparison to 1998 and 2008 In order to get a baseline, we can look at the number of references for the RFCs published in 2008 and 1998. However, we need totake time into account. Documents published a long time ago are expected to have accrued more references. We try to address this by looking at three counts for each document: the overall number of references over the document's lifetime, the number of references obtained in the year following publication, and the number of references observed since 2018: Huitema Expires April 28, 2021 [Page 37] Internet-Draft RFC-Eval-2018 October 2020 +-----------+--------+-------+-----------+-----------+ | RFC(2008) | Status | Total | 2008-2009 | 2018-2019 | +-----------+--------+-------+-----------+-----------+ | 5326 | Exp | 138 | 14 | 15 | | | | | | | | 5348 | PS | 14 | 3 | 0 | | | | | | | | 5281 | Info | 69 | 15 | 7 | | | | | | | | 5354 | Exp | 17 | 13 | 0 | | | | | | | | 5227 | PS | 19 | 1 | 2 | | | | | | | | 5329 | PS | 24 | 6 | 1 | | | | | | | | 5277 | PS | 32 | 3 | 2 | | | | | | | | 5236 | ISE | 25 | 5 | 4 | | | | | | | | 5358 | BCP | 21 | 2 | 0 | | | | | | | | 5271 | Info | 7 | 2 | 0 | | | | | | | | 5195 | PS | 7 | 4 | 2 | | | | | | | | 5283 | PS | 8 | 1 | 0 | | | | | | | | 5186 | Info | 14 | 4 | 2 | | | | | | | | 5142 | PS | 8 | 4 | 0 | | | | | | | | 5373 | PS | 5 | 2 | 0 | | | | | | | | 5404 | PS | 1 | 1 | 0 | | | | | | | | 5172 | PS | 2 | 0 | 0 | | | | | | | | 5349 | Info | 8 | 0 | 2 | | | | | | | | 5301 | PS | 5 | 1 | 0 | | | | | | | | 5174 | Info | 0 | 0 | 0 | +-----------+--------+-------+-----------+-----------+ Huitema Expires April 28, 2021 [Page 38] Internet-Draft RFC-Eval-2018 October 2020 +-----------+--------+-------+-----------+-----------+ | RFC(1998) | Status | Total | 1998-1999 | 2018-2019 | +-----------+--------+-------+-----------+-----------+ | 2289 | PS | 2 | 0 | 1 | | | | | | | | 2267 | Info | 982 | 5 | 61 | | | | | | | | 2317 | BCP | 9 | 1 | 2 | | | | | | | | 2404 | PS | 137 | 6 | 1 | | | | | | | | 2374 | PS | 42 | 4 | 0 | | | | | | | | 2449 | PS | 7 | 2 | 0 | | | | | | | | 2283 | PS | 17 | 3 | 2 | | | | | | | | 2394 | Info | 13 | 2 | 1 | | | | | | | | 2348 | DS | 5 | 0 | 0 | | | | | | | | 2382 | Info | 17 | 12 | 0 | | | | | | | | 2297 | ISE | 36 | 11 | 0 | | | | | | | | 2381 | PS | 39 | 12 | 0 | | | | | | | | 2312 | Info | 14 | 3 | 0 | | | | | | | | 2387 | PS | 4 | 1 | 0 | | | | | | | | 2398 | Info | 17 | 0 | 1 | | | | | | | | 2391 | PS | 31 | 3 | 0 | | | | | | | | 2431 | PS | 3 | 0 | 0 | | | | | | | | 2282 | Info | 8 | 0 | 0 | | | | | | | | 2323 | ISE | 1 | 0 | 0 | | | | | | | | 2448 | ISE | 0 | 0 | 0 | +-----------+--------+-------+-----------+-----------+ We can compare the median number of citations and the numbers of citations for the least and most popular quartiles in the three years: Huitema Expires April 28, 2021 [Page 39] Internet-Draft RFC-Eval-2018 October 2020 +----------------------------+-----------+--------+------------+ | References | Lower 25% | Median | Higher 25% | +----------------------------+-----------+--------+------------+ | RFC (2018) | 0 | 1 | 3 | | | | | | | RFC (2008) | 6.5 | 11 | 21.75 | | | | | | | RFC (2008), until 2009 | 1 | 2.5 | 4.5 | | | | | | | RFC (2008), 2018 and after | 0 | 0 | 2 | | | | | | | RFC (1998) | 4.75 | 13.5 | 32.25 | | | | | | | RFC (1998), until 1999 | 0 | 2 | 4.25 | | | | | | | RFC (1998), 2018 and after | 0 | 0 | 1 | +----------------------------+-----------+--------+------------+ The total numbers show new documents with fewer citations than the older ones. This can be explained to some degree by the passage of time. If we restrict the analysis to the number of citations accrued in the year of publishing and the year after that, we still see about the same distribution for the three samples. We also see that the number of references to RFC fades over time. Only the most popular of the RFC produced in 1998 are still cited in 2019. 5.3. Citations Versus Deployments The following table shows side by side the number of citations as measured in Section 5.1 and the estimation of deployment as indicated in Section 3. Huitema Expires April 28, 2021 [Page 40] Internet-Draft RFC-Eval-2018 October 2020 +-----------+--------+-----------+------------+ | RFC(2018) | Status | Citations | Deployment | +-----------+--------+-----------+------------+ | 8411 | Info | 1 | medium | | | | | | | 8456 | Info | 1 | medium | | | | | | | 8446 | PS | 418 | high | | | | | | | 8355 | Info | 3 | medium | | | | | | | 8441 | PS | 1 | high | | | | | | | 8324 | ISE | 0 | N/A | | | | | | | 8377 | PS | 0 | unknown | | | | | | | 8498 | Info | 0 | unknown | | | | | | | 8479 | ISE | 0 | one | | | | | | | 8453 | Info | 3 | unknown | | | | | | | 8429 | BCP | 0 | some | | | | | | | 8312 | Info | 25 | high | | | | | | | 8492 | ISE | 4 | one | | | | | | | 8378 | Exp | 1 | some | | | | | | | 8361 | PS | 0 | one | | | | | | | 8472 | PS | 1 | medium | | | | | | | 8471 | PS | 1 | medium | | | | | | | 8466 | PS | 0 | unknown | | | | | | | 8362 | PS | 1 | medium | | | | | | | 8468 | Info | 1 | some | +-----------+--------+-----------+------------+ From looking at these results, it is fairly obvious that citation counts cannot be used as proxies for the "value" of an RFC. In our sample, the two RFCs that have high citation counts were both widely deployed, and can certainly be described as successful, but we also Huitema Expires April 28, 2021 [Page 41] Internet-Draft RFC-Eval-2018 October 2020 see many RFCs that saw significant deployment without garnering a high level of citations. Citation counts are driven by academic interest, but are only loosely correlated with actual deployment. We saw that [RFC8446] was widely cited in part because the standardization process involved many researchers, and that the high citation count of [RFC8312] is largely due to the academic interest in evaluating congestion control protocols. If we look at previous years, the most cited RFC in the 2008 sample is [RFC5326], an experimental RFC defining security extensions to an experimental delay tolerant transport protocol. This protocol does not carry a significant proportion of Internet traffic, but has been the object of a fair number of academic studies. The citation process tends to privilege the first expression of a concept. We see that with the most cited RFC in the 1998 set is [RFC2267], an informational RFC defining Network Ingress Filtering that was obsoleted in May 2000 by [RFC2827]. It is still cited frequently in 2018 and 2019, regardless of its formal status in the RFC series. We see the same effect at work with [RFC8441], which garners very few citations although it obsoletes [RFC6455] that has a large number of citations. The same goes for [RFC8468], which is sparsely cited while the [RFC2330] is widely cited. Just counting citations will not indicate whether developers still use an old specification or have adopted the revised RFC. 5.4. Citations Versus Web References Web references might be another indicator of the popularity of an RFC. In order to evaluate these references, we list here the number of results returned by searches on Google and Bing, looking for the search term "RFCnnnn" (e.g., RFC8411), and copying the number of results returned by the search engines. The table below presents the results of these searches, performed on April 4, 2020. Huitema Expires April 28, 2021 [Page 42] Internet-Draft RFC-Eval-2018 October 2020 +-----------+--------+-----------+--------+-------+ | RFC(2018) | Status | Citations | Google | Bing | +-----------+--------+-----------+--------+-------+ | 8411 | Info | 1 | 301 | 94 | | | | | | | | 8456 | Info | 1 | 266 | 8456 | | | | | | | | 8446 | PS | 418 | 25900 | 47800 | | | | | | | | 8355 | Info | 3 | 521 | 114 | | | | | | | | 8441 | PS | 1 | 2430 | 59500 | | | | | | | | 8324 | ISE | 0 | 393 | 138 | | | | | | | | 8377 | PS | 0 | 264 | 10900 | | | | | | | | 8498 | Info | 0 | 335 | 10100 | | | | | | | | 8479 | ISE | 0 | 564 | 11000 | | | | | | | | 8453 | Info | 3 | 817 | 11400 | | | | | | | | 8429 | BCP | 0 | 391 | 41600 | | | | | | | | 8312 | Info | 25 | 1620 | 2820 | | | | | | | | 8492 | ISE | 4 | 323 | 9400 | | | | | | | | 8378 | Exp | 1 | 418 | 11600 | | | | | | | | 8361 | PS | 0 | 499 | 92 | | | | | | | | 8472 | PS | 1 | 496 | 169 | | | | | | | | 8471 | PS | 1 | 1510 | 11600 | | | | | | | | 8466 | PS | 0 | 766 | 173 | | | | | | | | 8362 | PS | 1 | 67 | 147 | | | | | | | | 8468 | Info | 1 | 453 | 127 | +-----------+--------+-----------+--------+-------+ The results counts from Bing are sometimes surprising. Why would RFC 8441 gather 59,500 web references? Looking at the results in detail, we find a mix of data. Some of them are logs of development projects implementing Web Sockets, which is exactly what we are looking for, Huitema Expires April 28, 2021 [Page 43] Internet-Draft RFC-Eval-2018 October 2020 but others appear spurious. For example, a shop selling rugby jerseys is listed because its phone number ends with "8441". Other pages were listed because street numbers or product numbers matched the RFC number. The same type of collision may explain the large reference counts on Bing for RFC 8377, 8498, 8479, 8453, 8429, 8378, and 8471. The result counts on Bing do not appear to provide a good metric. On Google, all RFC garner at least a 250 references, largely because the whole RFC catalog is replicated on a large number of web servers. Deviations from that base line are largely correlated with the number of citations in the Semantic Scholar, with a couple of exception: RFC 8441, and 8471 garner more references than the low citation counts would predict. Looking at the results, we find many references in development databases explaining how these protocols are implemented in various code bases and open source projects. This means that counting Google results would give some indication about an RFC's popularity, complementing the citation counts. There are some practical problems in using the counts of Google results. Google searches are personalized, the results depend on the source of the queries, and the counts may vary as well. The search result depend on the search algorithm, and there is no guarantee that counts will not change when the algorithm changes. On the other hand, the results do indicate that some of the RFC in our sample are beeing used by developers or in deployments. 6. Observations and Next Steps The author's goal was to get a personal understanding of the "chain of production" of the RFCs, and in particular to look at the various causes of delays in the process. As shown in Section 4, the average RFC was produced in 3 years and 4 months, which is similar to what was found in the 2008 sample, but more than three times larger than the delays for the 1998 sample. The Working Group process appears to be the main source of delays. Efforts to diminish delays should probably focus there, instead of on the IETF and IESG reviews of the RFC production. For the RFC production phase, most of the variability originates in the AUTH-48 process, which is influenced by a variety of factors such as number of authors or level of engagement of these authors. Most of the delay is spent in the Working Group, but the IETF datatracker does not hold much information about what happens inside the Working Groups. For example, events like Working Group Last Calls were not recorded in the history of the selected drafts available in the datatracker. Such information would have been Huitema Expires April 28, 2021 [Page 44] Internet-Draft RFC-Eval-2018 October 2020 interesting. Of course, requiring that information would create an administrative burden, so there is clearly a trade-off between requiring more work from working group chairs and providing better data for process analysis. (It appears that this information can be available in the datatracker for more recent drafts, if the WG chairs use the datatracker properly.) The Independent Stream operates as expected. The majority of the authors of the Independent Stream RFCs appear to be in IETF insiders, but there is significant amount of engagement by outside parties. The analysis of citations in Section 5.1 shows that citation numbers are a very poor indication of the "value" of an RFC. Citation numbers measure the engagement of academic researchers with specific topics, but have little correlation with the level of adoption and deployment of a specific RFC. The result counts of Google searches do capture references outside academia, such as logs of development projects. This might be informative, but it is not clear that the counts would not change over time due to algorithm changes or personaliztion. This document analyses a small sample of RFCs "in depth". This allowed gathering of detailed feedback on the process and the deployments. On the other hand, much of the data on delays is available from the IETF datatracker. It may be worth considering adding an automated reporting of delay metrics in the IETF datatracker. This document only considers the RFCs that were published in a given year. This approach can be criticized as introducing a form of "survivor bias". There are many drafts proposed to the IETF, and only a fraction of them end up being published as RFCs. On one hand this is expected, because part of the process is to triage between ideas that can gather consensus and those that don't. On the other hand, we don't know whether that triage is too drastic and discouraged progress on good ideas. One way to evaluate the triage process would be to look at publication attempts that were abandoned, for example drafts that expired without progressing or being replaced. The sampling methodology could also be used for that purpose. Pick maybe 20 drafts at random, among those abandoned in a target year, and investigate why they were abandoned. Was it because better solutions emerged in the Working Group? Or maybe because the authors discovered a flaw in their proposal? Or was it because some factional struggle blocked a good idea? Was the idea pursued in a different venue? Hopefully, someone will try this kind of investigation. Huitema Expires April 28, 2021 [Page 45] Internet-Draft RFC-Eval-2018 October 2020 7. Security Considerations This draft does not specify any protocol. We might want to analyze whether security issues were discovered after publication of specific standards. 8. IANA Considerations This draft does not require any IANA action. Peliminary analysis does not indicate that IANA is causing any particular delay in the RFC publication process. 9. Acknowledgements Many thanks to the authors of the selected RFCs who were willing to provide feedback on the process: Michael Ackermann, Zafar Ali, Sarah Banks, Bruno Decraene, Lars Eggert, Nalini Elkins, Joachim Fabini, Dino Farinacci, Clarence Filsfils, Sujay Gupta, Dan Harkins, Vinayak Hegde, Benjamin Kaduk, John Klensin, Acee Lindem, Nikos Mavrogiannopoulos, Patrick McManus, Victor Moreno, Al Morton, Andrei Popov, Eric Rescorla, Michiko Short, Bhuvaneswaran Vengainathan, Lao Weiguo, and Li Yizhou. Many thanks to Adrian Farrel for his useful advice, to Stephen Farrell and Colin Perkins for their guidance on the use of citations, and to Dave Crocker for a comprehensive review. 10. Informative References [IETFCOUNT] IETF, "Past IETF Meetings", 2020, . [RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, DOI 10.17487/RFC2267, January 1998, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . Huitema Expires April 28, 2021 [Page 46] Internet-Draft RFC-Eval-2018 October 2020 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, DOI 10.17487/RFC5326, September 2008, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", RFC 8312, DOI 10.17487/RFC8312, February 2018, . [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, . [RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, . [RFC8361] Hao, W., Li, Y., Durrani, M., Gupta, S., and A. Qu, "Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic", RFC 8361, DOI 10.17487/RFC8361, April 2018, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8377] Eastlake 3rd, D., Zhang, M., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Multi-Topology", RFC 8377, DOI 10.17487/RFC8377, July 2018, . [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018, . Huitema Expires April 28, 2021 [Page 47] Internet-Draft RFC-Eval-2018 October 2020 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, . [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10.17487/RFC8411, August 2018, . [RFC8429] Kaduk, B. and M. Short, "Deprecate Triple-DES (3DES) and RC4 in Kerberos", BCP 218, RFC 8429, DOI 10.17487/RFC8429, October 2018, . [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", RFC 8441, DOI 10.17487/RFC8441, September 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, . [RFC8455] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Terminology for Benchmarking Software- Defined Networking (SDN) Controller Performance", RFC 8455, DOI 10.17487/RFC8455, October 2018, . [RFC8456] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Benchmarking Methodology for Software- Defined Networking (SDN) Controller Performance", RFC 8456, DOI 10.17487/RFC8456, October 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . Huitema Expires April 28, 2021 [Page 48] Internet-Draft RFC-Eval-2018 October 2020 [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, . [RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, "The Token Binding Protocol Version 1.0", RFC 8471, DOI 10.17487/RFC8471, October 2018, . [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 2018, . [RFC8479] Mavrogiannopoulos, N., "Storing Validation Parameters in PKCS#8", RFC 8479, DOI 10.17487/RFC8479, September 2018, . [RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, October 2018, . [RFC8492] Harkins, D., Ed., "Secure Password Ciphersuites for Transport Layer Security (TLS)", RFC 8492, DOI 10.17487/RFC8492, February 2019, . [RFC8493] Kunze, J., Littman, J., Madden, E., Scancella, J., and C. Adams, "The BagIt File Packaging Format (V1.0)", RFC 8493, DOI 10.17487/RFC8493, October 2018, . [RFC8498] Mohali, M., "A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)", RFC 8498, DOI 10.17487/RFC8498, February 2019, . [RFCYEAR] RFC Editor, "Number of RFC Published per YEAR", 2020, . [SSCH] Allen Institute for AI, "Semantic Scholar", 2020, . Huitema Expires April 28, 2021 [Page 49] Internet-Draft RFC-Eval-2018 October 2020 [TLS13IMP] TLS WG, "TLS 1.3 Implementations", 2020, . [TRKR] IETF, "IETF Data Tracker", 2020, . Author's Address Christian Huitema Private Octopus Inc. 427 Golfcourse Rd Friday Harbor WA 98250 U.S.A Email: huitema@huitema.net Huitema Expires April 28, 2021 [Page 50] ./draft-ietf-hip-native-nat-traversal-33.txt0000644000764400076440000053737513712050475020233 0ustar iustyiusty HIP Working Group A. Keranen Internet-Draft J. Melen Intended status: Experimental M. Komu, Ed. Expires: February 4, 2021 Ericsson August 3, 2020 Native NAT Traversal Mode for the Host Identity Protocol draft-ietf-hip-native-nat-traversal-33 Abstract This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 4, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Keranen, et al. Expires February 4, 2021 [Page 1] Internet-Draft HIP Native NAT Traversal Mode August 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 4.1. Relay Registration . . . . . . . . . . . . . . . . . . . 10 4.2. Transport Address Candidate Gathering at the Relay Client 13 4.3. NAT Traversal Mode Negotiation . . . . . . . . . . . . . 16 4.4. Connectivity Check Pacing Negotiation . . . . . . . . . . 17 4.5. Base Exchange via Control Relay Server . . . . . . . . . 17 4.6. Connectivity Checks . . . . . . . . . . . . . . . . . . . 20 4.6.1. Connectivity Check Procedure . . . . . . . . . . . . 21 4.6.2. Rules for Connectivity Checks . . . . . . . . . . . . 24 4.6.3. Rules for Concluding Connectivity Checks . . . . . . 26 4.7. NAT Traversal Optimizations . . . . . . . . . . . . . . . 27 4.7.1. Minimal NAT Traversal Support . . . . . . . . . . . . 27 4.7.2. Base Exchange without Connectivity Checks . . . . . . 27 4.7.3. Initiating a Base Exchange both with and without UDP Encapsulation . . . . . . . . . . . . . . . . . . . . 29 4.8. Sending Control Packets after the Base Exchange . . . . . 29 4.9. Mobility Handover Procedure . . . . . . . . . . . . . . . 30 4.10. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . 34 4.11. Closing Procedure . . . . . . . . . . . . . . . . . . . . 35 4.12. Relaying Considerations . . . . . . . . . . . . . . . . . 35 4.12.1. Forwarding Rules and Permissions . . . . . . . . . . 35 4.12.2. HIP Data Relay and Relaying of Control Packets . . . 36 4.12.3. Handling Conflicting SPI Values . . . . . . . . . . 37 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 38 5.1. HIP Control Packets . . . . . . . . . . . . . . . . . . . 38 5.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 40 5.3. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 40 5.4. NAT Traversal Mode Parameter . . . . . . . . . . . . . . 40 5.5. Connectivity Check Transaction Pacing Parameter . . . . . 41 5.6. Relay and Registration Parameters . . . . . . . . . . . . 42 5.7. LOCATOR_SET Parameter . . . . . . . . . . . . . . . . . . 43 5.8. RELAY_HMAC Parameter . . . . . . . . . . . . . . . . . . 45 5.9. Registration Types . . . . . . . . . . . . . . . . . . . 45 5.10. Notify Packet Types . . . . . . . . . . . . . . . . . . . 45 5.11. ESP Data Packets . . . . . . . . . . . . . . . . . . . . 46 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters . . . . . . 46 5.13. PEER_PERMISSION Parameter . . . . . . . . . . . . . . . . 47 5.14. HIP Connectivity Check Packets . . . . . . . . . . . . . 48 5.15. NOMINATE parameter . . . . . . . . . . . . . . . . . . . 49 Keranen, et al. Expires February 4, 2021 [Page 2] Internet-Draft HIP Native NAT Traversal Mode August 2020 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . 50 6.2. Opportunistic Mode . . . . . . . . . . . . . . . . . . . 50 6.3. Base Exchange Replay Protection for Control Relay Server 50 6.4. Demultiplexing Different HIP Associations . . . . . . . . 51 6.5. Reuse of Ports at the Data Relay Server . . . . . . . . . 51 6.6. Amplification attacks . . . . . . . . . . . . . . . . . . 51 6.7. Attacks against Connectivity Checks and Candidate Gathering . . . . . . . . . . . . . . . . . . . . . . . . 52 6.8. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 10.1. Normative References . . . . . . . . . . . . . . . . . . 55 10.2. Informative References . . . . . . . . . . . . . . . . . 57 Appendix A. Selecting a Value for Check Pacing . . . . . . . . . 59 Appendix B. Differences with respect to ICE . . . . . . . . . . 59 Appendix C. Differences to Base Exchange and UPDATE procedures . 62 Appendix D. Multihoming Considerations . . . . . . . . . . . . . 64 Appendix E. DNS Considerations . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 1. Introduction The Host Identity Protocol (HIP) [RFC7401] is specified to run directly on top of IPv4 or IPv6. However, many middleboxes found in the Internet, such as NATs and firewalls, often allow only UDP or TCP traffic to pass [RFC5207]. Also, NATs usually require the host behind a NAT to create a forwarding state in the NAT before other hosts outside of the NAT can contact the host behind the NAT. To overcome this problem, different methods, commonly referred to as NAT traversal techniques, have been developed. As one solution, the HIP experiment report [RFC6538] mentions Teredo- based NAT traversal for HIP and related ESP traffic (with double tunneling overhead). Another solution is specified in [RFC5770], which will be referred to as "Legacy ICE-HIP" in this document. The experimental Legacy ICE-HIP specification combines Interactive Connectivity Establishment (ICE) protocol [RFC5245] with HIP, so that basically ICE is responsible for NAT traversal and connectivity testing, while HIP is responsible for end-host authentication and IPsec key management. The resulting protocol uses HIP, STUN and ESP messages tunneled over a single UDP flow. The benefit of using ICE and its STUN/TURN messaging formats is that one can re-use the NAT traversal infrastructure already available in the Internet, such as STUN and TURN servers. Also, some middleboxes may be STUN-aware and Keranen, et al. Expires February 4, 2021 [Page 3] Internet-Draft HIP Native NAT Traversal Mode August 2020 may be able to do something "smart" when they see STUN being used for NAT traversal. HIP poses a unique challenge to using standard ICE, due not only to kernel-space dependencies of HIP, but also due to its close integration with kernel-space IPSec; and, that while [RFC5770] provides a technically workable path, it incurs unacceptable performance drawbacks for kernel-space implementations. Also, implementing and integrating a full ICE/STUN/TURN protocol stack as specified in Legacy ICE-HIP results in a considerable amount of effort and code which could be avoided by re-using and extending HIP messages and state machines for the same purpose. Thus, this document specifies an alternative NAT traversal mode referred as "Native ICE-HIP" that employs HIP messaging format instead of STUN or TURN for the connectivity checks, keepalives and data relaying. Native ICE-HIP also specifies how mobility management works in the context of NAT traversal, which is missing from the Legacy ICE-HIP specification. The native specification is also based on HIPv2, whereas legacy specification is based on HIPv1. The differences to the Legacy ICE-HIP are further elaborated in Appendix B. Similarly as Legacy ICE-HIP, also this specification builds on the HIP registration extensions [RFC8003] and the base exchange procedure [RFC7401] and its closing procedures, so the reader is recommended to get familiar with the relevant specifications. In a nutshell, the registration extensions allow a HIP Initiator (usually a "client" host) to ask for specific services from a HIP Responder (usually a "server" host). The registration parameters are included in a base exchange, which is essentially a four-way Diffie-Hellman key exchange authenticated using the public keys of the end-hosts. When the hosts negotiate support for ESP [RFC7402] during the base exchange, they can deliver ESP protected application payload to each other. When either of the hosts moves and changes its IP address, the two hosts re-establish connectivity using the mobility extensions [RFC8046]. The reader is also recommended to get familiar with the mobility extensions, but basically it is a three-way procedure, where the mobile host first announces its new location to the peer, and then the peer tests for connectivity (so called return routability check), for which the mobile hosts must respond in order to activate its new location. This specification builds on the mobility procedures, but modifies it to be compatible with ICE. The differences to the mobility extensions specified in Appendix C. It is worth noting that multihoming support as specified in [RFC8047] is left for further study. This specification builds heavily on the ICE methodology, so it is recommended that the reader is familiar with the ICE specification [RFC8445] (especially the overview). However, native ICE-HIP does Keranen, et al. Expires February 4, 2021 [Page 4] Internet-Draft HIP Native NAT Traversal Mode August 2020 not implement all the features in ICE, and, hence, the different features of ICE are cross referenced using [RFC2119] terminology for clarity. Appendix B explains the differences to ICE, and it is recommended that the reader would read also this section in addition to the ICE specification. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document borrows terminology from [RFC5770], [RFC7401], [RFC8046], [I-D.ietf-hip-rfc4423-bis], [RFC8445], and [RFC5389]. The following terms recur in the text: ICE: Interactive Connectivity Establishment (ICE) protocol as specified in [RFC8445] Legacy ICE-HIP: Refers to the "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators" as specified in [RFC5770]. The protocol specified in this document offers an alternative to Legacy ICE-HIP. Native ICE-HIP: The protocol specified in this document (Native NAT Traversal Mode for HIP). Initiator: The Initiator is the host that initiates the base exchange using I1 message [RFC7401]. Responder: The Responder is the host that receives the I1 packet from the Initiator [RFC7401]. Control Relay Server A registrar host that forwards any kind of HIP control plane packets between the Initiator and the Responder. This host is critical because it relays the locators between the Initiator and the Responder, so that they can try to establish a direct communication path with each other. This host is used to replace HIP rendezvous servers [RFC8004] for hosts operating in private Keranen, et al. Expires February 4, 2021 [Page 5] Internet-Draft HIP Native NAT Traversal Mode August 2020 address realms. In the Legacy ICE-HIP specification [RFC5770], this host is denoted as "HIP Relay Server". Control Relay Client: A requester host that registers to a Control Relay Server requesting it to forward control-plane traffic (i.e. HIP control messages). In the Legacy ICE-HIP specification [RFC5770], this is denoted as "HIP Relay Client". Data Relay Server: A new entity introduced in this document; a registrar host that forwards HIP related data plane packets, such as Encapsulating Security Payload (ESP) [RFC7402], between two hosts. This host implements similar functionality as TURN servers. Data Relay Client: A requester host that registers to a Data Relay Server requesting it to forward data-plane traffic (e.g. ESP traffic). This functionality is a new and introduced in this document. Locator: As defined in [RFC8046]: "A name that controls how the packet is routed through the network and demultiplexed by the end-host. It may include a concatenation of traditional network addresses such as an IPv6 address and end-to-end identifiers such as an ESP Security Parameter Index (SPI). It may also include transport port numbers or IPv6 Flow Labels as demultiplexing context, or it may simply be a network address." LOCATOR_SET (written in capital letters): Denotes a HIP control packet parameter that bundles multiple locators together [RFC8046]. HIP offer: Before two end-hosts can establish a communication channel using the NAT traversal procedures defined in this document, they need exchange their locators (i.e. candidates) with each other. In ICE, this procedure is called Candidate Exchange and it does not specify how the candidates are exchanged but Session Description Protocol (SDP) "offer/answer" is mentioned as an example. In contrast, the Candidate Exchange in HIP is the base exchange itself or a subsequent UPDATE prodecure occurring after a handover. Following [RFC5770] and SDP related naming conventions [RFC3264], "HIP offer" is the the Initiator's LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet. Keranen, et al. Expires February 4, 2021 [Page 6] Internet-Draft HIP Native NAT Traversal Mode August 2020 HIP answer: The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE control packet. Corresponds to the SDP answer parameter [RFC3264], but is HIP specific. Please refer also to the longer description of the "HIP offer" term above. HIP connectivity checks: In order to obtain a direct end-to-end communication path (without employing a Data Relay Server), two communicating HIP hosts try to "punch holes" through their NAT boxes using this mechanism. It is similar to the ICE connectivity checks, but implemented using HIP return routability checks. Controlling host: The controlling host [RFC8445] is always the Initiator in the context of this specification. It nominates the candidate pair to be used with the controlled host. Controlled host: The controlled host [RFC8445] is always the Responder in the context of this specification. It waits for the controlling to nominate an address candidate pair. Checklist: A list of address candidate pairs that need to be tested for connectivity (same as in [RFC8445]). Transport address: Transport layer port and the corresponding IPv4/v6 address (same as in [RFC8445]). Candidate: A transport address that is a potential point of contact for receiving data (same as in [RFC8445]). Host candidate: A candidate obtained by binding to a specific port from an IP address on the host (same as in [RFC8445]). Server reflexive candidate: A translated transport address of a host as observed by a Control or Data Relay Server (same as in [RFC8445]). Peer reflexive candidate: A translated transport address of a host as observed by its peer (same as in [RFC8445]). Relayed candidate: Keranen, et al. Expires February 4, 2021 [Page 7] Internet-Draft HIP Native NAT Traversal Mode August 2020 A transport address that exists on a Data Relay Server. Packets that arrive at this address are relayed towards the Data Relay Client. The concept is the same as in [RFC8445], but a Data Relay Server is used instead of a TURN server. Permission: In the context of Data Relay Server, permission refers to a concept similar to TURN's ([RFC5766]) channels. Before a host can use a relayed candidate to forward traffic through a Data Relay Server, the host must activate the relayed candidate with a specific peer host. Base: Similarly as in [RFC8445], the base of a candidate is the local source address a host uses to send packets for the associated candidate. For example, the base of a server reflexive address is the local address the host used for registering itself to the associated Control or Data Relay Server. The base of a host candidate is equal to the host candidate itself. 3. Overview of Operation +--------------+ | Control | +--------+ | Relay Server | +--------+ | Data | +----+-----+---+ | Data | | Relay | / \ | Relay | | Server | / \ | Server | +--------+ / \ +--------+ / \ / \ / \ / <- Signaling -> \ / \ +-------+ +-------+ | NAT | | NAT | +-------+ +-------+ / \ / \ +-------+ +-------+ | Init- | | Resp- | | iator | | onder | +-------+ +-------+ Figure 1: Example Network Configuration In the example configuration depicted in Figure 1, both Initiator and Responder are behind one or more NATs, and both private networks are Keranen, et al. Expires February 4, 2021 [Page 8] Internet-Draft HIP Native NAT Traversal Mode August 2020 connected to the public Internet. To be contacted from behind a NAT, at least the Responder must be registered with a Control Relay Server reachable on the public Internet. The Responder may have also registered to a Data Relay Server that can forward the data plane in case NAT traversal fails. While, strictly speaking, the Initiator does not need a Data Relay Server, it may act in the other role with other hosts, and connectivity with the Data Relay Server of the Responder may fail, so the Initiator may also need to register to a Cotrol and/or Data Relay Server. It is worth noting that a Control and Data Relay does not forge the source address of a passing packet, but always translates the source address and source port of a packet to be forwarded (to its own). We assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the address(es) of the Responder's Control Relay Server(s) (how the Initiator learns of the Responder's Control Relay Server is outside of the scope of this document, but may be through DNS or another name service). The first steps are for both the Initiator and Responder to register with a Control Relay Server (need not be the same one) and gather a set of address candidates. The hosts use either Control Relay Servers or Data Relay Servers for gathering the candidates. Next, the HIP base exchange is carried out by encapsulating the HIP control packets in UDP datagrams and sending them through the Responder's Control Relay Server. As part of the base exchange, each HIP host learns of the peer's candidate addresses through the HIP offer/answer procedure embedded in the base exchange. Once the base exchange is completed, two HIP hosts have established a working communication session (for signaling) via a Control Relay Server, but the hosts still have to find a better path, preferably without a Data Relay Server, for the ESP data flow. For this, connectivity checks are carried out until a working pair of addresses is discovered. At the end of the procedure, if successful, the hosts will have established a UDP-based tunnel that traverses both NATs, with the data flowing directly from NAT to NAT or via a Data Relay Server. At this point, also the HIP signaling can be sent over the same address/port pair, and is demultiplexed (or, in other words, separated) from IPsec as described in the UDP encapsulation standard for IPsec [RFC3948]. Finally, the two hosts send NAT keepalives as needed in order keep their UDP-tunnel state active in the associated NAT boxes. If either one of the hosts knows that it is not behind a NAT, hosts can negotiate during the base exchange a different mode of NAT traversal that does not use HIP connectivity checks, but only UDP encapsulation of HIP and ESP. Also, it is possible for the Initiator to simultaneously try a base exchange with and without UDP Keranen, et al. Expires February 4, 2021 [Page 9] Internet-Draft HIP Native NAT Traversal Mode August 2020 encapsulation. If a base exchange without UDP encapsulation succeeds, no HIP connectivity checks or UDP encapsulation of ESP are needed. 4. Protocol Description This section describes the normative behavior of the "Native ICE-HIP" protocol extension. Most of the procedures are similar to what is defined in [RFC5770] but with different, or additional, parameter types and values. In addition, a new type of relaying server, Data Relay Server, is specified. Also, it should be noted that HIP version 2 [RFC7401] MUST be used instead of HIPv1 with this NAT traversal mode. 4.1. Relay Registration In order for two hosts to communicate over NATted environments, they need a reliable way to exchange information. To achieve this, "HIP Relay Server" is defined in [RFC5770]. It supports relaying of HIP control plane traffic over UDP in NATted environments, and forwards HIP control packets between the Initiator and the Responder. In this document, the HIP Relay Server is denoted as "Control Relay Server" for better alignment with the rest of the terminology. The registration to the Control Relay Server can be achieved using RELAY_UDP_HIP parameter as explained later in this section. To guarantee also data plane delivery over varying types of NAT devices, a host MAY also register for UDP encapsulated ESP relaying using Registration Type RELAY_UDP_ESP (value [TBD by IANA: 3]). This service may be coupled with the Control Relay Server or offered separately on another server. If the server supports relaying of UDP encapsulated ESP, the host is allowed to register for a data relaying service using the registration extensions in Section 3.3 of [RFC8003]). If the server has sufficient relaying resources (free port numbers, bandwidth, etc.) available, it opens a UDP port on one of its addresses and signals the address and port to the registering host using the RELAYED_ADDRESS parameter (as defined in Section 5.12 in this document). If the Data Relay Server would accept the data relaying request but does not currently have enough resources to provide data relaying service, it MUST reject the request with Failure Type "Insufficient resources" [RFC8003]. The registration process follows the generic registration extensions defined in [RFC8003]. The HIP control plane relaying registration follows [RFC5770], but the data plane registration is different. It is worth noting that if the HIP control and data plane relay services reside on different hosts, the client has to register separately to each of them. In the example shown in Figure 2, the two services are Keranen, et al. Expires February 4, 2021 [Page 10] Internet-Draft HIP Native NAT Traversal Mode August 2020 coupled on a single host. The text uses "Relay Client" and "Relay Server" as a shorthand when the procedures apply both to control and data cases. Control/Data Control/Data Relay Client (Initiator) Relay Server (Responder) | 1. UDP(I1) | +---------------------------------------------------------------->| | | | 2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP]))) | |<----------------------------------------------------------------+ | | | 3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP])) | +---------------------------------------------------------------->| | | | 4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM, | | [RELAYED_ADDRESS])) | |<----------------------------------------------------------------+ | | Figure 2: Example Registration with a HIP Relay In step 1, the Relay Client (Initiator) starts the registration procedure by sending an I1 packet over UDP to the Relay Server. It is RECOMMENDED that the Relay Client select a random source port number from the ephemeral port range 49152-65535 for initiating a base exchange. Alternatively, a host MAY also use a single fixed port for initiating all outgoing connections. However, the allocated port MUST be maintained until all of the corresponding HIP Associations are closed. It is RECOMMENDED that the Relay Server listen to incoming connections at UDP port 10500. If some other port number is used, it needs to be known by potential Relay Clients. In step 2, the Relay Server (Responder) lists the services that it supports in the R1 packet. The support for HIP control plane over UDP relaying is denoted by the Registration Type value RELAY_UDP_HIP (see Section 5.9). If the server supports also relaying of ESP traffic over UDP, it includes also Registration type value RELAY_UDP_ESP. In step 3, the Relay Client selects the services for which it registers and lists them in the REG_REQ parameter. The Relay Client registers for the Control Relay service by listing the RELAY_UDP_HIP value in the request parameter. If the Relay Client requires also ESP relaying over UDP, it lists also RELAY_UDP_ESP. Keranen, et al. Expires February 4, 2021 [Page 11] Internet-Draft HIP Native NAT Traversal Mode August 2020 In step 4, the Relay Server concludes the registration procedure with an R2 packet and acknowledges the registered services in the REG_RES parameter. The Relay Server denotes unsuccessful registrations (if any) in the REG_FAILED parameter of R2. The Relay Server also includes a REG_FROM parameter that contains the transport address of the Relay Client as observed by the Relay Server (Server Reflexive candidate). If the Relay Client registered to ESP relaying service, the Relay Server includes RELAYED_ADDRESS parameter that describes the UDP port allocated to the Relay Client for ESP relaying. It is worth noting that the Data Relay Client must first activate this UDP port by sending an UPDATE message to the Data Relay Server that includes a PEER_PERMISSION parameter as described in Section 4.12.1 both after base exchange and handover procedures. Also, the Data Relay Server should follow the port allocation recommendations in Section 6.5. After the registration, the Relay Client sends periodically NAT keepalives to the Relay Server in order to keep the NAT bindings between the Relay Client and the relay alive. The keepalive extensions are described in Section 4.10. The Data Relay Client MUST maintain an active HIP association with the Data Relay Server as long as it requires the data relaying service. When the HIP association is closed (or times out), or the registration lifetime passes without the Data Relay Client refreshing the registration, the Data Relay Server MUST stop relaying packets for that host and close the corresponding UDP port (unless other Data Relay Clients are still using it). The Data Relay Server SHOULD offer a different relayed address and port for each Data Relay Client because not doing so can cause problems with stateful firewalls (see Section 6.5). When a Control Relay Client sends an UPDATE (e.g., due to host movement or to renew service registration), the Control Relay Server MUST follow the general guidelines defined in [RFC8003], with the difference that all UPDATE messages are delivered on top of UDP. In addition to this, the Control Relay Server MUST include the REG_FROM parameter in all UPDATE responses sent to the Control Relay Client. This applies to both renewals of service registration and to host movement. It is especially important for the case of host movement, as this is the mechanism that allows the Control Relay Client to learn its new server reflexive address candidate. A Data Relay Client can request multiple relayed candidates from the Data Relay Server (e.g., for the reasons described in Section 4.12.3). After the base exchange with registration, the Data Relay Client can request additional relayed candidates similarly as Keranen, et al. Expires February 4, 2021 [Page 12] Internet-Draft HIP Native NAT Traversal Mode August 2020 during the base exchange. The Data Relay Client sends an UPDATE message REG_REQ parameter requesting for the RELAY_UDP_ESP service. The UPDATE message MUST also include a SEQ and a ECHO_REQUEST_SIGNED parameter. The Data Relay Server MUST respond with an UPDATE message that includes the corresponding response parameters: REG_RES, ACK and ECHO_REQUEST_SIGNED . In case the Data Relay Server allocated a new relayed UDP port for the Data Relay Client, the REG_RES parameter MUST list RELAY_UDP_ESP as a service and the UPDATE message MUST also include a RELAYED_ADDRESS parameter describing the relayed UDP port. The Data Relay Server MUST also include the Server Reflexive candidate in a REG_FROM parameter. It is worth mentioning that Data Relay Client MUST activate the UDP port as described in Section 4.12.1 before it can be used for any ESP relaying. A Data Relay Client may unregister a relayed candidate in two ways. It can wait for its lifetime to expire or it can explicitly request it with zero lifetime using the UPDATE mechanism. The Data Relay Client can send an REG_REQ parameter with zero lifetime to the Data Relay Server in order to expire all relayed candidates. To expire a specific relayed candidate, the Data Relay Client MUST also include RELAYED_ADDRESS parameter as sent by the server in the UPDATE message. Upon closing the HIP association (CLOSE-CLOSE-ACK procedure initiated by either party), the Data Relay Server MUST also expire all relayed candidates. Please also refer to Section 6.8 for protection against cross- protocol attacks for both Control Relay Client and Server. 4.2. Transport Address Candidate Gathering at the Relay Client An Initiator needs to gather a set of address candidates before contacting a (non-relay) Responder. The candidates are needed for connectivity checks that allow two hosts to discover a direct, non- relayed path for communicating with each other. One server reflexive candidate can be discovered during the registration with the Control Relay Server from the REG_FROM parameter (and another from Data Relay Server if one is employed). The candidate gathering can be done at any time, but it needs to be done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP mode is to be used for the connectivity checks. It is RECOMMENDED that all three types of candidates (host, server reflexive, and relayed) are gathered to maximize the probability of successful NAT traversal. However, if no Data Relay Server is used, and the host has only a single local IP address to use, the host MAY use the local address as the only host candidate and the address from the REG_FROM parameter discovered during the Control Relay Server registration as Keranen, et al. Expires February 4, 2021 [Page 13] Internet-Draft HIP Native NAT Traversal Mode August 2020 a server reflexive candidate. In this case, no further candidate gathering is needed. A Data Relay Client MAY register only a single relayed candidate that it uses with multiple other peers. However, it is RECOMMENDED that a Data Relay Client registers a new server relayed candidate for each of its peer for the reasons described in Section 4.12.3. The procedures for registering multiple relayed candidates are described in Section 4.1. If a Relay Client has more than one network interface, it can discover additional server reflexive candidates by sending UPDATE messages from each of its interfaces to the Relay Server. Each such UPDATE message MUST include the following parameters: registration request (REG_REQ) parameter with Registration Type CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) and ECHO_REQUEST_SIGNED parameter. When a Control Relay Server receives an UPDATE message with registration request containing a CANDIDATE_DISCOVERY type, it MUST include a REG_FROM parameter, containing the same information as if this were a Control Relay Server registration, to the response (in addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request type SHOULD NOT create any state at the Control Relay Server. The rules in section 5.1.1 in [RFC8445] for candidate gathering are followed here. A number of host candidates (loopback, anycast and others) should be excluded as described in section 5.1.1.1 of the ICE specification [RFC8445]. Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal, and implementations SHOULD support this functionality even if it will not be used in deployments in order to enable it by software configuration update if needed at some point. Similarly as explained in section 5.1.1.2 of the ICE specification [RFC8445], if an IPv6-only host is in a network that utilizes NAT64 [RFC6146] and DNS64 [RFC6147] technologies, it may also gather IPv4 server- reflexive and/or relayed candidates from IPv4-only Control or Data Relay Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and generate server-reflexive candidates for each IPv6-only interface, accordingly. The NAT64 server-reflexive candidates are prioritized like IPv4 server-reflexive candidates. HIP based connectivity can be utilized by IPv4 applications using Local Scope Identifiers (LSIs) and by IPv6 based applications using HITs. The LSIs and HITs of the local virtual interfaces MUST be excluded in the candidate gathering phase as well to avoid creating unnecessary loopback connectivity tests. Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be Keranen, et al. Expires February 4, 2021 [Page 14] Internet-Draft HIP Native NAT Traversal Mode August 2020 gathered as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no STUN or Data Relay Server are available. Each local address candidate MUST be assigned a priority. The following recommended formula (as described in [RFC8445]) SHOULD be used: priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) In the formula, the type preference follows the ICE specification (as defined in section 5.1.2.1 in [RFC8445]): the RECOMMENDED values are 126 for host candidates, 100 for server reflexive candidates, 110 for peer reflexive candidates, and 0 for relayed candidates. The highest value is 126 (the most preferred) and lowest is 0 (last resort). For all candidates of the same type, the preference type value MUST be identical, and, correspondingly, the value MUST be different for different types. For peer reflexive values, the type preference value MUST be higher than for server reflexive types. It should be noted that peer reflexive values are learned later during connectivity checks, so a host cannot employ it during candidate gathering stage yet. Following the ICE specification, the local preference MUST be an integer from 0 (lowest preference) to 65535 (highest preference) inclusive. In the case the host has only a single address candidate, the value SHOULD be 65535. In the case of multiple candidates, each local preference value MUST be unique. Dual-stack considerations for IPv6 apply also here as defined in [RFC8445] in section 5.1.2.2. Unlike with SDP used in conjunction with ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists. Hence, the component ID value MUST always be set to 1. As defined in section 14.3 in [RFC8445], the retransmission timeout (RTO) for address gathering from a Control/Data Relay Server SHOULD be calculated as follows: RTO = MAX (1000ms, Ta * (Num-Of-Cands)) where Ta is the value used for the connectivity check pacing and Num- Of-Cands is the number of server-reflexive and relay candidates. A smaller value than 1000 ms for the RTO MUST NOT be used. Keranen, et al. Expires February 4, 2021 [Page 15] Internet-Draft HIP Native NAT Traversal Mode August 2020 4.3. NAT Traversal Mode Negotiation This section describes the usage of a non-critical parameter type called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP base exchange means that the end-host supports NAT traversal extensions described in this document. As the parameter is non- critical (as defined in Section 5.2.1 of [RFC7401]), it can be ignored by a end-host, which means that the host is not required to support it or may decline to use it. With registration with a Control/Data Relay Server, it is usually sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since the Relay Server is assumed to be in public address space. Thus, the Relay Server SHOULD propose the UDP-ENCAPSULATION mode as the preferred or only mode. The NAT traversal mode negotiation in a HIP base exchange is illustrated in Figure 3. It is worth noting that the Relay Server could be located between the hosts, but is omitted here for simplicity. Initiator Responder | 1. UDP(I1) | +----------------------------------------------------------------->| | | | 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..)) | |<-----------------------------------------------------------------+ | | | 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))| +----------------------------------------------------------------->| | | | 4. UDP(R2(.., ENC(LOC_SET), ..)) | |<-----------------------------------------------------------------+ | | Figure 3: Negotiation of NAT Traversal Mode In step 1, the Initiator sends an I1 to the Responder. In step 2, the Responder responds with an R1. As specified in [RFC5770], the NAT_TRAVERSAL_MODE parameter in R1 contains a list of NAT traversal modes the Responder supports. The mode specified in this document is ICE-HIP-UDP (value [TBD by IANA: 3]). In step 3, the Initiator sends an I2 that includes a NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the Initiator from the list of modes offered by the Responder. If ICE- HIP-UDP mode was selected, the I2 also includes the "Transport address" locators (as defined in Section 5.7) of the Initiator in a Keranen, et al. Expires February 4, 2021 [Page 16] Internet-Draft HIP Native NAT Traversal Mode August 2020 LOCATOR_SET parameter (denoted here with LOC_SET). With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated within an ENCRYPTED parameter (denoted here with ENC) according to the procedures in sections 5.2.18 and 6.5 in [RFC7401]. The locators in I2 are the "HIP offer". In step 4, the Responder concludes the base exchange with an R2 packet. If the Initiator chose ICE-HIP-UDP traversal mode, the Responder includes a LOCATOR_SET parameter in the R2 packet. With ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST be encapsulated within an ENCRYPTED parameter according to the procedures in sections 5.2.18 and 6.5 in [RFC7401]. The locators in R2, encoded like the locators in I2, are the "ICE answer". If the NAT traversal mode selected by the Initiator is not supported by the Responder, the Responder SHOULD reply with a NOTIFY packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange. 4.4. Connectivity Check Pacing Negotiation As explained in Legacy ICE-HIP [RFC5770], when a NAT traversal mode with connectivity checks is used, new transactions should not be started too fast to avoid congestion and overwhelming the NATs. For this purpose, during the base exchange, hosts can negotiate a transaction pacing value, Ta, using a TRANSACTION_PACING parameter in R1 and I2 packets. The parameter contains the minimum time (expressed in milliseconds) the host would wait between two NAT traversal transactions, such as starting a new connectivity check or retrying a previous check. The value that is used by both of the hosts is the higher of the two offered values. The minimum Ta value SHOULD be configurable, and if no value is configured, a value of 50 ms MUST be used. Guidelines for selecting a Ta value are given in Appendix A. Hosts MUST NOT use values smaller than 5 ms for the minimum Ta, since such values may not work well with some NATs (as explained in [RFC8445]). The Initiator MUST NOT propose a smaller value than what the Responder offered. If a host does not include the TRANSACTION_PACING parameter in the base exchange, a Ta value of 50 ms MUST be used as that host's minimum value. 4.5. Base Exchange via Control Relay Server This section describes how the Initiator and Responder perform a base exchange through a Control Relay Server. Connectivity pacing (denoted as TA_P here) was described in Section 4.4 and is not repeated here. Similarly, the NAT traversal mode negotiation process (denoted as NAT_TM in the example) was described in Section 4.3 and is also not repeated here. If a Control Relay Server receives an R1 Keranen, et al. Expires February 4, 2021 [Page 17] Internet-Draft HIP Native NAT Traversal Mode August 2020 or I2 packet without the NAT traversal mode parameter, it MUST drop it and SHOULD send a NOTIFY error packet with type NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2. It is RECOMMENDED that the Initiator send an I1 packet encapsulated in UDP when it is destined to an IP address of the Responder. Respectively, the Responder MUST respond to such an I1 packet with a UDP-encapsulated R1 packet, and also the rest of the communication related to the HIP association MUST also use UDP encapsulation. Figure 4 illustrates a base exchange via a Control Relay Server. We assume that the Responder (i.e. a Control Relay Client) has already registered to the Control Relay Server. The Initiator may have also registered to another (or the same Control Relay Server), but the base exchange will traverse always through the Control Relay Server of the Responder. Initiator Control Relay Server Responder | 1. UDP(I1) | | +--------------------------------->| 2. UDP(I1(RELAY_FROM)) | | +------------------------------->| | | | | | 3. UDP(R1(RELAY_TO, NAT_TM, | | | TA_P)) | | 4. UDP(R1(RELAY_TO, NAT_TM, |<-------------------------------+ | TA_P)) | | |<---------------------------------+ | | | | | 5. UDP(I2(ENC(LOC_SET)), | | | NAT_TM, TA_P)) | | +--------------------------------->| 6. UDP(I2(ENC(LOC_SET), | | | RELAY_FROM, NAT_TM, TA_P))| | +------------------------------->| | | | | | 7. UDP(R2(ENC(LOC_SET), | | 8. UDP(R2(ENC(LOC_SET), | RELAY_TO)) | | RELAY_TO)) |<-------------------------------+ |<---------------------------------+ | | | | Figure 4: Base Exchange via a HIP Relay Server In step 1 of Figure 4, the Initiator sends an I1 packet over UDP via the Control Relay Server to the Responder. In the HIP header, the source HIT belongs to the Initiator and the destination HIT to the Responder. The initiator sends the I1 packet from its IP address to the IP address of the Control Relay Server over UDP. Keranen, et al. Expires February 4, 2021 [Page 18] Internet-Draft HIP Native NAT Traversal Mode August 2020 In step 2, the Control Relay Server receives the I1 packet. If the destination HIT belongs to a successfully registered Control Relay Client (i.e., the host marked "Responder" in Figure 4), the Control Relay Server processes the packet. Otherwise, the Control Relay Server MUST drop the packet silently. The Control Relay Server appends a RELAY_FROM parameter to the I1 packet, which contains the transport source address and port of the I1 as observed by the Control Relay Server. The Control Relay Server protects the I1 packet with RELAY_HMAC, except that the parameter type is different as described in Section 5.8. The Control Relay Server changes the source and destination ports and IP addresses of the packet to match the values the Responder used when registering to the Control Relay Server, i.e., the reverse of the R2 used in the registration. The Control Relay Server MUST recalculate the transport checksum and forward the packet to the Responder. In step 3, the Responder receives the I1 packet. The Responder processes it according to the rules in [RFC7401]. In addition, the Responder validates the RELAY_HMAC according to Section 5.8 and silently drops the packet if the validation fails. The Responder replies with an R1 packet to which it includes RELAY_TO and NAT traversal mode parameters. The responder MUST include ICE-HIP-UDP in the NAT traversal modes. The RELAY_TO parameter MUST contain the same information as the RELAY_FROM parameter, i.e., the Initiator's transport address, but the type of the parameter is different. The RELAY_TO parameter is not integrity protected by the signature of the R1 to allow pre-created R1 packets at the Responder. In step 4, the Control Relay Server receives the R1 packet. The Control Relay Server drops the packet silently if the source HIT belongs to a Control Relay Client that has not successfully registered. The Control Relay Server MAY verify the signature of the R1 packet and drop it if the signature is invalid. Otherwise, the Control Relay Server rewrites the source address and port, and changes the destination address and port to match RELAY_TO information. Finally, the Control Relay Server recalculates the transport checksum and forwards the packet. In step 5, the Initiator receives the R1 packet and processes it according to [RFC7401]. The Initiator MAY use the address in the RELAY_TO parameter as a local peer-reflexive candidate for this HIP association if it is different from all known local candidates. The Initiator replies with an I2 packet that uses the destination transport address of R1 as the source address and port. The I2 packet contains a LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all the HIP candidates (HIP offer) of the Initiator. The candidates are encoded using the format defined in Section 5.7. The I2 packet MUST also contain a NAT traversal mode parameter that Keranen, et al. Expires February 4, 2021 [Page 19] Internet-Draft HIP Native NAT Traversal Mode August 2020 includes ICE-HIP-UDP mode. The ENCRYPTED parameter along with its key material generation are described in detail in sections 5.2.18 and 6.5 in [RFC7401]. In step 6, the Control Relay Server receives the I2 packet. The Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2 packet similarly as explained in step 2, and forwards the packet to the Responder. In step 7, the Responder receives the I2 packet and processes it according to [RFC7401]. The Responder validates the RELAY_HMAC according to Section 5.8 and silently drops the packet if the validation fails. It replies with an R2 packet and includes a RELAY_TO parameter as explained in step 3. The R2 packet includes a LOCATOR_SET parameter inside an ENCRYPTED parameter that lists all the HIP candidates (ICE answer) of the Responder. The RELAY_TO parameter is protected by the HMAC. The ENCRYPTED parameter along with its key material generation are described in detail in sections 5.2.18 and 6.5 in [RFC7401]. In step 8, the Control Relay Server processes the R2 as described in step 4. The Control Relay Server forwards the packet to the Initiator. After the Initiator has received the R2 and processed it successfully, the base exchange is completed. Hosts MUST include the address of one or more Control Relay Servers (including the one that is being used for the initial signaling) in the LOCATOR_SET parameter in I2 and R2 messages if they intend to use such servers for relaying HIP signaling immediately after the base exchange completes. The traffic type of these addresses MUST be "HIP signaling" (see Section 5.7) and they MUST NOT be used for the connectivity tests described in Section 4.6. If the Control Relay Server locator used for relaying the base exchange is not included in I2 or R2 LOCATOR_SET parameters, it SHOULD NOT be used after the base exchange. Instead, further HIP signaling SHOULD use the same path as the data traffic. It is RECOMMENDED to use the same Control Relay Server throughout the lifetime of the host association that was used for forwarding the base exchange if the Responder includes it in the locator parameter of the R2 message. 4.6. Connectivity Checks When the Initiator and Responder complete the base exchange through the Control Relay Server, both of them employ the IP address of the Control Relay Server as the destination address for the packets. The address of the Control Relay Server MUST NOT be used as a destination for data plane traffic unless the server supports also Data Relay Server functionality, and the Client has successfully registered to Keranen, et al. Expires February 4, 2021 [Page 20] Internet-Draft HIP Native NAT Traversal Mode August 2020 use it. When NAT traversal mode with ICE-HIP-UDP was successfully negotiated and selected, the Initiator and Responder MUST start the connectivity checks in order to attempt to obtain direct end-to-end connectivity through NAT devices. It is worth noting that the connectivity checks MUST be completed even though no ESP_TRANSFORM would be negotiated and selected. The connectivity checks follow the ICE methodology [I-D.rosenberg-mmusic-ice-nonsip], but UDP encapsulated HIP control messages are used instead of ICE messages. As stated in the ICE specification, the basic procedure for connectivity checks has three phases: sorting the candidate pairs according their priority, sending checks in the prioritized order and acknowledging the checks from the peer host. The Initiator MUST take the role of controlling host and the Responder acts as the controlled host. The roles MUST persist throughout the HIP associate lifetime (to be reused in the possibly mobility UPDATE procedures). In the case both communicating nodes are initiating the communications to each other using an I1 packet, the conflict is resolved as defined in section 6.7 in [RFC7401]: the host with the "larger" HIT changes to its Role to Responder. In such a case, the host changing its role to Responder MUST also switch to controlled role. The protocol follows standard HIP UPDATE sending and processing rules as defined in section 6.11 and 6.12 in [RFC7401], but some new parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS and NOMINATE). 4.6.1. Connectivity Check Procedure Figure 5 illustrates connectivity checks in a simplified scenario, where the Initiator and Responder have only a single candidate pair to check. Typically, NATs drop messages until both sides have sent messages using the same port pair. In this scenario, the Responder sends a connectivity check first but the NAT of the Initiator drops it. However, the connectivity check from the Initiator reaches the Responder because it uses the same port pair as the first message. It is worth noting that the message flow in this section is idealistic, and, in practice, more messages would be dropped, especially in the beginning. For instance, connectivity tests always start with the candidates with the highest priority, which would be host candidates (which would not reach the recipient in this scenario). Keranen, et al. Expires February 4, 2021 [Page 21] Internet-Draft HIP Native NAT Traversal Mode August 2020 Initiator NAT1 NAT2 Responder | | 1. UDP(UPDATE(SEQ, CAND_PRIO, | | | | ECHO_REQ_SIGN)) | | | X<-----------------------------------+----------------+ | | | | | 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | +-------------+------------------------------------+--------------->| | | | | | 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | |<------------+------------------------------------+----------------+ | | | | | 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO)) | | |<------------+------------------------------------+----------------+ | | | | | 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) | | +-------------+------------------------------------+--------------->| | | | | | 6. Other connectivity checks using UPDATE over UDP | |<------------+------------------------------------+----------------> | | | | | 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE)) | +-------------+------------------------------------+--------------->| | | | | | 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN, | | NOMINATE)) | | |<------------+------------------------------------+----------------+ | | | | | 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN)) | | +-------------+------------------------------------+--------------->+ | | | | | 10. ESP data traffic over UDP | | +<------------+------------------------------------+--------------->+ | | | | Figure 5: Connectivity Checks In step 1, the Responder sends a connectivity check to the Initiator that the NAT of the Initiator drops. The message includes a number of parameters. As specified in [RFC7401]), the SEQ parameter includes a running sequence identifier for the connectivity check. The candidate priority (denoted "CAND_PRIO" in the figure) describes the priority of the address candidate being tested. The ECHO_REQUEST_SIGNED (denoted ECHO_REQ_SIGN in the figure) includes a nonce that the recipient must sign and echo back as it is. In step 2, the Initiator sends a connectivity check, using the same address pair candidate as in the previous step, and the message Keranen, et al. Expires February 4, 2021 [Page 22] Internet-Draft HIP Native NAT Traversal Mode August 2020 traverses successfully the NAT boxes. The message includes the same parameters as in the previous step. It should be noted that the sequence identifier is locally assigned by the Initiator, so it can be different than in the previous step. In step 3, the Responder has successfully received the previous connectivity check from the Initiator and starts to build a response message. Since the message from the Initiator included a SEQ, the Responder must acknowledge it using an ACK parameter. Also, the nonce contained in the echo request must be echoed back in an ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The Responder includes also a MAPPED_ADDRESS parameter (denoted MAPPED_ADDR in the figure) that contains the transport address of the Initiator as observed by the Responder (i.e. peer reflexive candidate). This message is successfully delivered to the Initiator, and upon reception the Initiator marks the candidate pair as valid. In step 4, the Responder retransmits the connectivity check sent in the first step, since it was not acknowledged yet. In step 5, the Initiator responds to the previous connectivity check message from the Responder. The Initiator acknowledges the SEQ parameter from the previous message using ACK parameter and the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED. In addition, it includes MAPPED_ADDR parameter that includes the peer reflexive candidate. This response message is successfully delivered to the Responder, and upon reception the Initiator marks the candidate pair as valid. In step 6, despite the two hosts now having valid address candidates, the hosts still test the remaining address candidates in a similar way as in the previous steps. It should be noted that each connectivity check has a unique sequence number in the SEQ parameter. In step 7, the Initiator has completed testing all address candidates and nominates one address candidate to be used. It sends an UPDATE message using the selected address candidates that includes a number of parameters: SEQ, ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY and the NOMINATE parameter. In step 8, the Responder receives the message with NOMINATE parameter from the Initiator. It sends a response that includes the NOMINATE parameter in addition to a number of other parameters. The ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and ECHO_REQUEST_SIGNED parameters from previous message from the Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED parameters in order to receive an acknowledgment from the Responder. Keranen, et al. Expires February 4, 2021 [Page 23] Internet-Draft HIP Native NAT Traversal Mode August 2020 In step 9, the Initiator completes the candidate nomination process by confirming the message reception to the Responder. In the confirmation message, the ACK and ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and ECHO_REQUEST_SIGNED parameters in the message sent by the Responder in the previous step. In step 10, the Initiator and Responder can start sending application payload over the successfully nominated address candidates. It is worth noting that if either host has registered a relayed address candidate from a Data Relay Server, the host MUST activate the address before connectivity checks by sending an UPDATE message containing PEER_PERMISSION parameter as described in Section 4.12.1. Otherwise, the Data Relay Server drops ESP packets using the relayed address. It should be noted that in the case both Initiator and Responder both advertising their own relayed address candidates, it is possible that the two hosts choose the two relayed addresses as a result of the ICE nomination algorithm. While this is possible (and even could be desirable for privacy reasons), it can be unlikely due to low priority assigned for the relayed address candidates. In such a event, the nominated address pair is always symmetric; the nomination algorithm prevents asymmetric address pairs (i.e. each side choosing different pair), such as a Data Relay Client using its own Data Relay Server to send data directly to its peer while receiving data from the Data Relay Server of its peer. 4.6.2. Rules for Connectivity Checks The HITs of the two communicating hosts MUST be used as credentials in this protocol (in contrast to ICE which employs username-password fragments). A HIT pair uniquely identifies the corresponding HIT association, and a SEQ number in an UPDATE message identifies a particular connectivity check. All of the connectivity check messages MUST be protected with HIP_HMAC and signatures (even though the illustrations in this specification omit them for simplicity) according to [RFC7401]. Each connectivity check sent by a host MUST include a SEQ parameter and ECHO_REQUEST_SIGNED parameter, and correspondingly the peer MUST respond to these using ACK and ECHO_RESPONSE_SIGNED according to the rules specified in [RFC7401]. The host sending a connectivity check MUST validate that the response uses the same pair of UDP ports, and drop the packet if this is not the case. Keranen, et al. Expires February 4, 2021 [Page 24] Internet-Draft HIP Native NAT Traversal Mode August 2020 A host may receive a connectivity check before it has received the candidates from its peer. In such a case, the host MUST immediately queue a response by placing it in the triggered-check queue, and then continue waiting for the candidates. A host MUST NOT select a candidate pair until it has verified the pair using a connectivity check as defined in Section 4.6.1. [RFC7401] section 5.3.5 states that UPDATE packets have to include either a SEQ or ACK parameter (but can include both). In the connectivity check procedure specified in Section 4.6.1, each SEQ parameter should be acknowledged separately. In the context of NATs, this means that some of the SEQ parameters sent in connectivity checks will be lost or arrive out of order. From the viewpoint of the recipient, this is not a problem since the recipient will just "blindly" acknowledge the SEQ. However, the sender needs to be prepared for lost sequence identifiers and ACKs parameters that arrive out of order. As specified in [RFC7401], an ACK parameter may acknowledge multiple sequence identifiers. While the examples in the previous sections do not illustrate such functionality, it is also permitted when employing ICE-HIP-UDP mode. In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD be sent with the same sequence identifier in the SEQ parameter. Some tested address candidates will never produce a working address pair, and thus may cause retransmissions. Upon successful nomination of an address pair, a host SHOULD immediately stop sending such retransmissions. Full ICE procedures for prioritizing candidates, eliminating redundant candidates, forming check lists (including pruning) and triggered check-queues MUST be followed as specified in section 6.1 [RFC8445], with the exception of that the foundation, frozen candidates and default candidates are not used. From viewpoint of the ICE specification [RFC8445], the protocol specified in this document operates using Component ID of 1 on all candidates, and the foundation of all candidates is unique. This specification defines only "full ICE" mode, and the "lite ICE" is not supported. The reasoning behind the missing features is described in Appendix B. The connectivity check messages MUST be paced by the Ta value negotiated during the base exchange as described in Section 4.4. If neither one of the hosts announced a minimum pacing value, a value of 50 ms MUST be used. Both hosts MUST form a priority ordered checklist and begin to check transactions every Ta milliseconds as long as the checks are running Keranen, et al. Expires February 4, 2021 [Page 25] Internet-Draft HIP Native NAT Traversal Mode August 2020 and there are candidate pairs whose tests have not started. The retransmission timeout (RTO) for the connectivity check UPDATE packets SHOULD be calculated as follows: RTO = MAX (1000ms, Ta * (Num-Waiting + Num-In-Progress)) In the RTO formula, Ta is the value used for the connectivity check pacing, Num-Waiting is the number of pairs in the checklist in the "Waiting" state, and Num-In-Progress is the number of pairs in the "In-Progress" state. This is identical to the formula in [RFC8445] when there is only one checklist. A smaller value than 1000 ms for the RTO MUST NOT be used. Each connectivity check request packet MUST contain a CANDIDATE_PRIORITY parameter (see Section 5.14) with the priority value that would be assigned to a peer reflexive candidate if one was learned from the corresponding check. An UPDATE packet that acknowledges a connectivity check request MUST be sent from the same address that received the check and delivered to the same address where the check was received from. Each acknowledgment UPDATE packet MUST contain a MAPPED_ADDRESS parameter with the port, protocol, and IP address of the address where the connectivity check request was received from. Following the ICE guidelines [RFC8445], it is RECOMMENDED to restrict the total number of connectivity checks to 100 for each host association. This can be achieved by limiting the connectivity checks to the 100 candidate pairs with the highest priority. 4.6.3. Rules for Concluding Connectivity Checks The controlling agent may find multiple working candidate pairs. To conclude the connectivity checks, it SHOULD nominate the pair with the highest priority. The controlling agent MUST nominate a candidate pair essentially by repeating a connectivity check using an UPDATE message that contains a SEQ parameter (with new sequence number), a ECHO_REQUEST_SIGNED parameter, the priority of the candidate in a CANDIDATE_PRIORITY parameter and NOMINATE parameter to signify conclusion of the connectivity checks. Since the nominated address pair has already been tested for reachability, the controlled host should be able to receive the message. Upon reception, the controlled host SHOULD select the nominated address pair. The response message MUST include a SEQ parameter with a new sequence id, acknowledgment of the sequence from the controlling host in an ACK parameter, a new ECHO_REQUEST_SIGNED parameter, ECHO_RESPONSE_SIGNED parameter corresponding to the ECHO_REQUEST_SIGNED parameter from the controlling host and the NOMINATE parameter. After sending this packet, the controlled host can create IPsec security associations Keranen, et al. Expires February 4, 2021 [Page 26] Internet-Draft HIP Native NAT Traversal Mode August 2020 using the nominated address candidate for delivering application payload to the controlling host. Since the message from the controlled host included a new sequence id and echo request for signature, the controlling host MUST acknowledge this with a new UPDATE message that includes an ACK and ECHO_RESPONSE_SIGNED parameters. After this final concluding message, the controlling host also can create IPsec security associations for delivering application payload to the controlled host. It is possible that packets are delayed by the network. Both hosts MUST continue to respond to any connectivity checks despite an address pair having been nominated. If all the connectivity checks have failed, the hosts MUST NOT send ESP traffic to each other but MAY continue communicating using HIP packets and the locators used for the base exchange. Also, the hosts SHOULD notify each other about the failure with a CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see Section 5.10). 4.7. NAT Traversal Optimizations 4.7.1. Minimal NAT Traversal Support If the Responder has a fixed and publicly reachable IPv4 address and does not employ a Control Relay Server, the explicit NAT traversal mode negotiation MAY be omitted, and thus even the UDP-ENCAPSULATION mode does not have to be negotiated. In such a scenario, the Initiator sends an I1 message over UDP and the Responder responds with an R1 message over UDP without including any NAT traversal mode parameter. The rest of the base exchange follows the procedures defined in [RFC7401], except that the control and data plane use UDP encapsulation. Here, the use of UDP for NAT traversal is agreed implicitly. This way of operation is still subject to NAT timeouts, and the hosts MUST employ NAT keepalives as defined in Section 4.10. When UDP-ENCAPSULATION mode is chosen either explicitly or implicitly, the connectivity checks as defined in this document MUST NOT be used. When hosts lose connectivity, they MUST instead utilize [RFC8046] or [RFC8047] procedures, but with the difference being that UDP-based tunneling MUST be employed for the entire lifetime of the corresponding Host Association. 4.7.2. Base Exchange without Connectivity Checks It is possible to run a base exchange without any connectivity checks as defined in Legacy ICE-HIP section 4.8 [RFC5770]. The procedure is applicable also in the context of this specification, so it is repeated here for completeness. Keranen, et al. Expires February 4, 2021 [Page 27] Internet-Draft HIP Native NAT Traversal Mode August 2020 In certain network environments, the connectivity checks can be omitted to reduce initial connection set-up latency because a base exchange acts as an implicit connectivity test itself. For this to work, the Initiator MUST be able to reach the Responder by simply UDP encapsulating HIP and ESP packets sent to the Responder's address. Detecting and configuring this particular scenario is prone to failure unless carefully planned. In such a scenario, the Responder MAY include UDP-ENCAPSULATION NAT traversal mode as one of the supported modes in the R1 packet. If the Responder has registered to a Control Relay Server in order to discover its address candidates, it MUST also include a LOCATOR_SET parameter encapsulated inside an ENCRYPTED parameter in R1 message that contains a preferred address where the Responder is able to receive UDP-encapsulated ESP and HIP packets. This locator MUST be of type "Transport address", its Traffic type MUST be "both", and it MUST have the "Preferred bit" set (see Table 1). If there is no such locator in R1, the Initiator MUST use the source address of the R1 as the Responder's preferred address. The Initiator MAY choose the UDP-ENCAPSULATION mode if the Responder listed it in the supported modes and the Initiator does not wish to use the connectivity checks defined in this document for searching for a more optimal path. In this case, the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT traversal mode parameter directly to the Responder's preferred address (i.e., to the preferred locator in R1 or to the address where R1 was received from if there was no preferred locator in R1). The Initiator MAY include locators in I2 but they MUST NOT be taken as address candidates, since connectivity checks defined in this document will not be used for connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if R2 and I2 are received and processed successfully, a security association can be created and UDP-encapsulated ESP can be exchanged between the hosts after the base exchange completes according to the rules in Section 4.4 in [RFC7401]. The Control Relay Server can be used for discovering address candidates but it is not intended to be used for relaying end-host packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT be sent via a Control Relay Server, the Responder SHOULD reject such I2 packets and reply with a NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see Section 5.10). If there is no answer for the I2 packet sent directly to the Responder's preferred address, the Initiator MAY send another I2 via the Control Relay Server, but it MUST NOT choose UDP-ENCAPSULATION NAT traversal mode for that I2. Keranen, et al. Expires February 4, 2021 [Page 28] Internet-Draft HIP Native NAT Traversal Mode August 2020 4.7.3. Initiating a Base Exchange both with and without UDP Encapsulation It is possible to run a base exchange in parallel both with and without UDP encapsulation as defined in Legacy ICE-HIP section 4.9 in [RFC5770]. The procedure is applicable also in the context of this specification, so it is repeated here for completeness. The Initiator MAY also try to simultaneously perform a base exchange with the Responder without UDP encapsulation. In such a case, the Initiator sends two I1 packets, one without and one with UDP encapsulation, to the Responder. The Initiator MAY wait for a while before sending the other I1. How long to wait and in which order to send the I1 packets can be decided based on local policy. For retransmissions, the procedure is repeated. The I1 packet without UDP encapsulation may arrive directly, without passing any a Control Relay Server, at the Responder. When this happens, the procedures in [RFC7401] are followed for the rest of the base exchange. The Initiator may receive multiple R1 packets, with and without UDP encapsulation, from the Responder. However, after receiving a valid R1 and answering it with an I2, further R1 packets that are not retransmissions of the R1 message received first MUST be ignored. The I1 packet without UDP encapsulation may also arrive at a HIP- capable middlebox. When the middlebox is a HIP rendezvous server and the Responder has successfully registered with the rendezvous service, the middlebox follows rendezvous procedures in [RFC8004]. If the Initiator receives a NAT traversal mode parameter in R1 without UDP encapsulation, the Initiator MAY ignore this parameter and send an I2 without UDP encapsulation and without any selected NAT traversal mode. When the Responder receives the I2 without UDP encapsulation and without NAT traversal mode, it will assume that no NAT traversal mechanism is needed. The packet processing will be done as described in [RFC7401]. The Initiator MAY store the NAT traversal modes for future use, e.g., in case of a mobility or multihoming event that causes NAT traversal to be used during the lifetime of the HIP association. 4.8. Sending Control Packets after the Base Exchange The same considerations of sending control packets after the base exchange described in legacy ICE-HIP section 5.10 in [RFC5770] apply also here, so they are repeated here for completeness. Keranen, et al. Expires February 4, 2021 [Page 29] Internet-Draft HIP Native NAT Traversal Mode August 2020 After the base exchange, the two end-hosts MAY send HIP control packets directly to each other using the transport address pair established for a data channel without sending the control packets through any Control Relay Servers . When a host does not receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a timeout based on local policies, a host SHOULD resend the packet through the associated Data Relay Server of the peer (if the peer listed it in its LOCATOR_SET parameter in the base exchange according the rules specified in section 4.4.2 in [RFC7401]. If Control Relay Client sends a packet through a Control Relay Server, the Control Relay Client MUST always utilize the RELAY_TO parameter. The Control Relay Server SHOULD forward HIP control packets originating from a Control Relay Client to the address denoted in the RELAY_TO parameter. In the other direction, the Control Relay Server SHOULD forward HIP control packets to the Control Relay Clients, and MUST add a RELAY_FROM parameter to the control packets it relays to the Control Relay Clients. If the Control Relay Server is not willing or able to relay a HIP packet, it MAY notify the sender of the packet with MESSAGE_NOT_RELAYED error notification (see Section 5.10). 4.9. Mobility Handover Procedure A host may move after base exchange and connectivity checks. Mobility extensions for HIP [RFC8046] define handover procedures without NATs. In this section, we define how two hosts interact with handover procedures in scenarios involving NATs. The specified extensions define only simple mobility using a pair of security associations, and multihoming extensions are left to be defined in later specifications. The procedures in this section offer the same functionality as "ICE restart" specified in [RFC8445]. The example described in this section shows only a Control Relay Server for the peer host for the sake of simplicity, but the mobile host may also have a Control Relay Server. The assumption here is that the two hosts have successfully negotiated and chosen the ICE-HIP-UDP mode during the base exchange as defined in Section 4.3. The Initiator of the base exchange MUST store information that it was the controlling host during the base exchange. Similarly, the Responder MUST store information that it was the controlled host during the base exchange. Prior to starting the handover procedures with all peer hosts, the mobile host SHOULD first send its locators in UPDATE messages to its Control and Data Relay Servers if it has registered to such. It SHOULD wait for all of them to respond for a configurable time, by Keranen, et al. Expires February 4, 2021 [Page 30] Internet-Draft HIP Native NAT Traversal Mode August 2020 default two minutes, and then continue with the handover procedure without information from the Relay Server that did not respond. As defined in Section 4.1, a response message from a Control Relay Server includes a REG_FROM parameter that describes the server reflexive candidate of the mobile host to be used in the candidate exchange during the handover. Similarly, an UPDATE to a Data Relay Server is necessary to make sure the Data Relay Server can forward data to the correct IP address after a handoff. The mobility extensions for NAT traversal are illustrated in Figure 6. The mobile host is the host that has changed its locators, and the peer host is the host it has a host association with. The mobile host may have multiple peers and it repeats the process with all of its peers. In the figure, the Control Relay Server belongs to the peer host, i.e., the peer host is a Control Relay Client for the Control Relay Server. Note that the figure corresponds to figure 3 in [RFC8046], but the difference is that the main UPDATE procedure is carried over the relay and the connectivity is tested separately. Next, we describe the procedure in the figure in detail. Keranen, et al. Expires February 4, 2021 [Page 31] Internet-Draft HIP Native NAT Traversal Mode August 2020 Mobile Host Control Relay Server Peer Host | 1. UDP(UPDATE(ESP_INFO, | | | ENC(LOC_SET), SEQ)) | | +--------------------------------->| 2. UDP(UPDATE(ESP_INFO, | | | ENC(LOC_SET), SEQ, | | | RELAY_FROM)) | | +------------------------------->| | | | | | 3. UDP(UPDATE(ESP_INFO, SEQ, | | | ACK, ECHO_REQ_SIGN, | | | RELAY_TO)) | | 4. UDP(UPDATE(ESP_INFO, SEQ, |<-------------------------------+ | ACK, ECHO_REQ_SIGN, | | | RELAY_TO)) | | |<---------------------------------+ | | | | | 5. UDP(UPDATE(ACK, | | | ECHO_RESP_SIGNED)) | | +--------------------------------->| 6. UDP(UPDATE(ACK, | | | ECHO_RESP_SIGNED, | | | RELAY_FROM)) | | +------------------------------->| | | | | 7. connectivity checks over UDP | +<----------------------------------------------------------------->+ | | | | 8. ESP data over UDP | +<----------------------------------------------------------------->+ | | | Figure 6: HIP UPDATE procedure In step 1, the mobile host has changed location and sends a location update to its peer through the Control Relay Server of the peer. It sends an UPDATE packet with source HIT belonging to itself and destination HIT belonging to the peer host. In the packet, the source IP address belongs to the mobile host and the destination to the Control Relay Server. The packet contains an ESP_INFO parameter, where, in this case, the OLD SPI and NEW SPI parameters both contain the pre-existing incoming SPI. The packet also contains the locators of the mobile host in a LOCATOR_SET parameter, encapsulated inside an ENCRYPTED parameter (see sections 5.2.18 and 6.5 in [RFC7401] for details on the ENCRYPTED parameter). The packet contains also a SEQ number to be acknowledged by the peer. As specified in [RFC8046], the packet may also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN parameter for rekeying. Keranen, et al. Expires February 4, 2021 [Page 32] Internet-Draft HIP Native NAT Traversal Mode August 2020 In step 2, the Control Relay Server receives the UPDATE packet and forwards it to the peer host (i.e. Control Relay Client). The Control Relay Server rewrites the destination IP address and appends a RELAY_FROM parameter to the message. In step 3, the peer host receives the UPDATE packet, processes it and responds with another UPDATE message. The message is destined to the HIT of mobile host and to the IP address of the Control Relay Server. The message includes an ESP_INFO parameter where, in this case, the OLD SPI and NEW SPI parameters both contain the pre-existing incoming SPI. The peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters to be acknowledged by the mobile host. The message acknowledges the SEQ parameter of the earlier message with an ACK parameter. The RELAY_TO parameter specifies the address of the mobile host where the Control Relay Server should forward the message. In step 4, the Control Relay Server receives the message, rewrites the destination IP address and UDP port according to the RELAY_TO parameter, and then forwards the modified message to the mobile host. In step 5, the mobile host receives the UPDATE packet and processes it. The mobile host concludes the handover procedure by acknowledging the received SEQ parameter with an ACK parameter and the ECHO_REQUEST_SIGNED parameter with ECHO_RESPONSE_SIGNED parameter. The mobile host delivers the packet to the HIT of the peer and to the address of the HIP relay. The mobile host can start connectivity checks after this packet. In step 6, HIP relay receives the UPDATE packet and forwards it to the peer host (i.e. Relay Client). The HIP relay rewrites the destination IP address and port, and then appends a RELAY_FROM parameter to the message. When the peer host receives this concluding UPDATE packet, it can initiate the connectivity checks. In step 7, the two hosts test for connectivity across NATs according to procedures described in Section 4.6. The original Initiator of the communications is the controlling and the original Responder is the controlled host. In step 8, the connectivity checks are successfully completed and the controlling host has nominated one address pair to be used. The hosts set up security associations to deliver the application payload. It is worth noting that the Control and Data Relay Client do not have to re-register for the related services after a handoff. However, if a Data Relay Client has registered a relayed address candidate from a Data Relay Server, the Data Relay Client MUST reactivate the address Keranen, et al. Expires February 4, 2021 [Page 33] Internet-Draft HIP Native NAT Traversal Mode August 2020 before the connectivity checks by sending an UPDATE message containing PEER_PERMISSION parameter as described in Section 4.12.1. Otherwise, the Data Relay Server drops ESP packets sent to the relayed address. In so called "double jump" or simultaneous mobility scenario both peers change their location simultaneously. In such a case, both peers trigger the procedure described earlier in this section at the same time. In other words, both of the communicating hosts send an UPDATE packet carrying locators at the same time or with some delay. When the locators are exchanged almost simultaneously (reliably via Control Relay Servers), the two hosts can continue with connectivity checks after both have completed separately the steps in Figure 6. The problematic case occurs when one of the hosts (referred here as host "M") moves later during the connectivity checks. In such a case, host M sends a locator to the peer which is in the middle of connectivity checks. Upon receiving the UPDATE message, the peer responds with an UPDATE with ECHO_REQ_SIGN as described in step 3 in Figure 6. Upon receiving the valid response from host M as described in step 6, the peer host MUST restart the connectivity checks with host M. This way, both hosts start the connectivity checks roughly in a synchronized way. It is also important that peer host does not restart the connectivity checks until the step 6 is successfully completed because the UPDATE message carrying locators in step 1 could be replayed by an attacker. 4.10. NAT Keepalives To prevent NAT states from expiring, communicating hosts MUST send periodic keepalives to other hosts with which they have established a Host Association every 15 seconds (the so called Tr value in ICE). Other values MAY be used, but a Tr value smaller than 15 seconds MUST NOT be used. Both a Control/Data Relay Client and Control/Data Relay Server, as well as two peers employing UDP-ENCAPSULATION or ICE-HIP- UDP mode, SHOULD send HIP NOTIFY packets unless they have exchanged some other traffic over the used UDP ports. However, the Data Relay Client and Data Relay Server MUST employ only HIP NOTIFY packets in order to keep the server reflexive candidates alive. The keepalive message encoding format is defined in Section 5.3. If the base exchange or mobility handover procedure occurs during an extremely slow path, a host (with a Host Association with the peer) MAY also send HIP NOTIFY packets every 15 seconds to keep the path active with the recipient. Keranen, et al. Expires February 4, 2021 [Page 34] Internet-Draft HIP Native NAT Traversal Mode August 2020 4.11. Closing Procedure The two-way procedure for closing a HIP association and the related security associations is defined in [RFC7401]. One host initiates the procedure by sending a CLOSE message and the recipient confirms it with CLOSE_ACK. All packets are protected using HMACs and signatures, and the CLOSE messages includes a ECHO_REQUEST_SIGNED parameter to protect against replay attacks. The same procedure for closing HIP associations applies also here, but the messaging occurs using the UDP encapsulated tunnel that the two hosts employ. A host sending the CLOSE message SHOULD first send the message over a direct link. After a number of retransmissions, it MUST send over a Control Relay Server of the recipient if one exists. The host receiving the CLOSE message directly without a Control Relay Server SHOULD respond directly. If CLOSE message came via a Control Relay Server, the host SHOULD respond using the same Control Relay Server. 4.12. Relaying Considerations 4.12.1. Forwarding Rules and Permissions The Data Relay Server uses a similar permission model as a TURN server: before the Data Relay Server forwards any ESP data packets from a peer to a Data Relay Client (or the other direction), the client MUST set a permission for the peer's address. The permissions also install a forwarding rule for each direction, similar to TURN's channels, based on the Security Parameter Index (SPI) values in the ESP packets. Permissions are not required for HIP control packets. However, if a relayed address (as conveyed in the RELAYED_ADDRESS parameter from the Data Relay Server) is selected to be used for data, the Control Relay Client MUST send an UPDATE message to the Data Relay Server containing a PEER_PERMISSION parameter (see Section 5.13) with the following information: the UDP port and address for the server reflexive address, the UDP port and address of the peer, and the inbound and outbound SPIs used for ESP. The packet MUST be sent to the same UDP tunnel the Client employed in the base exchange to contact the Server (i.e., not to the port occupied by the server reflexive candidate). To avoid packet dropping of ESP packets, the Control Relay Client SHOULD send the PEER_PERMISSION parameter before connectivity checks both in the case of base exchange and a mobility handover. It is worth noting that the UPDATE message includes a SEQ parameter (as specified in [RFC7401]) that the Data Relay Server must acknowledge, so that the Control Relay Client can resend the message with PEER_PERMISSION parameter if it gets lost. Keranen, et al. Expires February 4, 2021 [Page 35] Internet-Draft HIP Native NAT Traversal Mode August 2020 When a Data Relay Server receives an UPDATE with a PEER_PERMISSION parameter, it MUST check if the sender of the UPDATE is registered for data relaying service, and drop the UPDATE if the host was not registered. If the host was registered, the Data Relay Server checks if there is a permission with matching information (protocol, addresses, ports and SPI values). If there is no such permission, a new permission MUST be created and its lifetime MUST be set to 5 minutes. If an identical permission already existed, it MUST be refreshed by setting the lifetime to 5 minutes. A Data Relay Client SHOULD refresh permissions 1 minute before the expiration when the permission is still needed. When a Data Relay Server receives an UPDATE from a registered client but without a PEER_PERMISSION parameter and with a new locator set, the Data Relay Server can assume that the mobile host has changed its location and, thus, is not reachable in its previous location. In such an event, the Data Relay Server SHOULD deactivate the permission and stop relaying data plane traffic to the client. The relayed address MUST be activated with the PEER_PERMISSION parameter both after a base exchange and after a handover procedure with another ICE-HIP-UDP capable host. Unless activated, the Data Relay Server MUST drop all ESP packets. It is worth noting that a Data Relay Client does not have to renew its registration upon a change of location UPDATE, but only when the lifetime of the registration is close to end. 4.12.2. HIP Data Relay and Relaying of Control Packets When a Data Relay Server accepts to relay UDP encapsulated ESP between a Data Relay Client and its peer, the Data Relay Server opens a UDP port (relayed address) for this purpose as described in Section 4.1. This port can be used for delivering also control packets because connectivity checks also cover the path through the Data Relay Server. If the Data Relay Server receives a UDP encapsulated HIP control packet on that port, it MUST forward the packet to the Data Relay Client and add a RELAY_FROM parameter to the packet as if the Data Relay Server were acting as a Control Relay Server. When the Data Relay Client replies to a control packet with a RELAY_FROM parameter via its Data Relay Server, the Data Relay Client MUST add a RELAY_TO parameter containing the peer's address and use the address of its Data Relay Server as the destination address. Further, the Data Relay Server MUST send this packet to the peer's address from the relayed address. If the Data Relay Server receives a UDP packet that is not a HIP control packet to the relayed address, it MUST check if it has a permission set for the peer the packet is arriving from (i.e., the Keranen, et al. Expires February 4, 2021 [Page 36] Internet-Draft HIP Native NAT Traversal Mode August 2020 sender's address and SPI value matches to an installed permission). If permissions are set, the Data Relay Server MUST forward the packet to the Data Relay Client that created the permission. The Data Relay Server MUST also implement the similar checks for the reverse direction (i.e. ESP packets from the Data Relay Client to the peer). Packets without a permission MUST be dropped silently. 4.12.3. Handling Conflicting SPI Values From the viewpoint of a host, its remote peers can have overlapping inbound SPI numbers because the IPsec uses also the destination IP address to index the remote peer host. However, a Data Relay Server can represent multiple remote peers, thus masquerading the actual destination. Since a Data Relay Server may have to deal with a multitude of Relay Clients and their peers, a Data Relay Server may experience collisions in the SPI namespace, thus being unable forward datagrams to the correct destination. Since the SPI space is 32 bits and the SPI values should be random, the probability for a conflicting SPI value is fairly small, but could occur on a busy Data Relay Server. The two problematic cases are described in this section. In the first scenario, the SPI collision problems occurs if two hosts have registered to the same Data Relay Server and a third host initiates base exchange with both of them. Here, the two Responders (i.e. Data Relay Clients) claim the same inbound SPI number with the same Initiator (peer). However, in this case, the Data Relay Server has allocated separate UDP ports for the two Data Relay Clients acting now as Responders (as recommended in Section 6.5). When the third host sends an ESP packet, the Data Relay Server is able to forward the packet to the correct Data Relay Client because the destination UDP port is different for each of the clients. In the second scenario, an SPI collision may occur when two Initiators run a base exchange to the same Responder (i.e. Data Relay Client), and both of the Initiators claim the same inbound SPI at the Data Relay Server using PEER_PERMISSION Parameter. In this case, the Data Relay Server cannot disambiguate the correct destination of an ESP packet originating from the Data Relay Client because the SPI could belong to either of the peers (and destination IP and UDP port belonging to the Data Relay Server are not unique either). The recommended way and a contingency plan to solve this issue are described below. The recommend way to mitigate the problem is as follows. For each new Host Association, A Data Relay Client acting as a Responder SHOULD register a new server reflexive candidate as described in Section 4.2. Similarly, the Data Relay Server SHOULD NOT re-use the Keranen, et al. Expires February 4, 2021 [Page 37] Internet-Draft HIP Native NAT Traversal Mode August 2020 port numbers as described in Section 6.5. This way, each server reflexive candidate for the Data Relay Client has a separate UDP port that the Data Relay Server can use to disambiguate packet destinations in case of SPI collisions. When the Data Relay Client is not registering or failed to register a new relay candidate for a new peer, the Data Relay Client MUST follow a contingency plan as follows. Upon receiving an I2 with a colliding SPI, the Data Relay client acting as the Responder MUST NOT include the relayed address candidate in the R2 message because the Data Relay Server would not be able demultiplex the related ESP packet to the correct Initiator. The same applies also the handover procedures; the Data Relay Client MUST NOT include the relayed address candidate when sending its new locator set in an UPDATE to its peer if it would cause a SPI conflict with another peer. 5. Packet Formats The following subsections define the parameter and packet encodings for the HIP and ESP packets. All values MUST be in network byte order. It is worth noting that all of the parameters are shown for the sake of completeness even though they are specified already in Legacy ICE- HIP [RFC5770]. New parameters are explicitly described as new. 5.1. HIP Control Packets Figure 7 illustrates the packet format for UDP-encapsulated HIP. The format is identical to Legacy ICE-HIP [RFC5770]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32 bits of zeroes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ HIP Header and Parameters ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Format of UDP-Encapsulated HIP Control Packets Keranen, et al. Expires February 4, 2021 [Page 38] Internet-Draft HIP Native NAT Traversal Mode August 2020 HIP control packets are encapsulated in UDP packets as defined in Section 2.2 of [RFC3948], "IKE Header Format for Port 4500", except that a different port number is used. Figure 7 illustrates the encapsulation. The UDP header is followed by 32 zero bits that can be used to differentiate HIP control packets from ESP packets. The HIP header and parameters follow the conventions of [RFC7401] with the exception that the HIP header checksum MUST be zero. The HIP header checksum is zero for two reasons. First, the UDP header already contains a checksum. Second, the checksum definition in [RFC7401] includes the IP addresses in the checksum calculation. The NATs that are unaware of HIP cannot recompute the HIP checksum after changing IP addresses. A Control/Data Relay Server or a non-relay Responder SHOULD listen at UDP port 10500 for incoming UDP-encapsulated HIP control packets. If some other port number is used, it needs to be known by potential Initiators. UDP encapsulation of HIP packets reduces the Maximum Transfer Unit (MTU) size of the control plane by 12 bytes (8-byte UDP header plus 4-byte zero SPI marker), and the data plane by 8 bytes. Additional HIP relay parameters, such as RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further increase the size of certain HIP packets. In regard to MTU, the following aspects need to be considered in an implementation: o A HIP host SHOULD implement ICMP message handling to support path MTU discovery (PMTUD) discovery as described in [RFC1063] [RFC8201] o Reliance on IP fragmentation is unlikely to be a viable strategy through NATs. If ICMP MTU discovery is not working, MTU related path black holes may occur. o A mitigation strategy is to constrain the MTU, especially for virtual interfaces, to expected safe MTU values, e.g., 1400 bytes for the underlying interfaces that support 1500 bytes MTU. o Further extensions to this specification may define a HIP-based mechanism to find a working path MTU without unnecessary constraining that size using Packetization Layer Path MTU Discovery for Datagram Transports [I-D.ietf-tsvwg-datagram-plpmtud]. For instance, such mechanism could be implemented between a HIP Relay Client and HIP Relay Server. Keranen, et al. Expires February 4, 2021 [Page 39] Internet-Draft HIP Native NAT Traversal Mode August 2020 o It is worth noting that further HIP extensions can trim off 8 bytes in the ESP header by negotiating implicit IV support in the ESP_TRANSFORM parameter as described in [RFC8750]. 5.2. Connectivity Checks HIP connectivity checks are HIP UPDATE packets. The format is specified in [RFC7401]. 5.3. Keepalives The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets as specified in [RFC7401] with Notify message type field set to NAT_KEEPALIVE [TBD by IANA: 16385] and with an empty Notification data field. It is worth noting that sending of such a HIP NOTIFY message SHOULD be omitted if the host is actively (or passively) sending some other traffic (HIP or ESP) to the peer host over the related UDP tunnel during the Tr period. For instance, the host MAY actively send ICMPv6 requests (or respond with an ICMPv6 response) inside the ESP tunnel to test the health of the associated IPsec security association. Alternatively, the host MAY use UPDATE packets as a substitute. A minimal UPDATE packet would consist of a SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve rekeying procedures as specified in section 6.8 in [RFC7402]. It is worth noting that a host actively sending periodic UPDATE packets to a busy server may increase the computational load of the server since it has to verify HMACs and signatures in UPDATE messages. 5.4. NAT Traversal Mode Parameter The format of NAT traversal mode parameter is defined in Legacy ICE- HIP [RFC5770] but repeated here for completeness. The format of the NAT_TRAVERSAL_MODE parameter is similar to the format of the ESP_TRANSFORM parameter in [RFC7402] and is shown in Figure 8. The Native ICE-HIP extension specified in this document defines the new NAT traversal mode identifier for ICE-HIP-UDP and reuses the UDP- ENCAPSULATION mode from Legacy ICE-HIP [RFC5770]. The identifier named RESERVED is reserved for future use. Future specifications may define more traversal modes. Keranen, et al. Expires February 4, 2021 [Page 40] Internet-Draft HIP Native NAT Traversal Mode August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Mode ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode ID #2 | Mode ID #3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode ID #n | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 608 Length length in octets, excluding Type, Length, and padding Reserved zero when sent, ignored when received Mode ID defines the proposed or selected NAT traversal mode(s) The following NAT traversal mode IDs are defined: ID name Value RESERVED 0 UDP-ENCAPSULATION 1 ICE-STUN-UDP 2 ICE-HIP-UDP 3 Figure 8: Format of the NAT_TRAVERSAL_MODE Parameter The sender of a NAT_TRAVERSAL_MODE parameter MUST make sure that there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE parameter. Conversely, a recipient MUST be prepared to handle received NAT traversal mode parameters that contain more than six Mode IDs by accepting the first six Mode IDs and dropping the rest. The limited number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE parameter. The modes MUST be in preference order, most preferred mode(s) first. Implementations conforming to this specification MUST implement UDP- ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes. 5.5. Connectivity Check Transaction Pacing Parameter The TRANSACTION_PACING is defined in [RFC5770], but repeated in Figure 9 for completeness. It contains only the connectivity check pacing value, expressed in milliseconds, as a 32-bit unsigned integer. Keranen, et al. Expires February 4, 2021 [Page 41] Internet-Draft HIP Native NAT Traversal Mode August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min Ta | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 610 Length 4 Min Ta the minimum connectivity check transaction pacing value the host would use (in milliseconds) Figure 9: Format of the TRANSACTION_PACING Parameter 5.6. Relay and Registration Parameters The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is shown in Figure 10. All parameters are identical except for the type. Of the three, only REG_FROM is covered by the signature. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type REG_FROM: 950 RELAY_FROM: 63998 RELAY_TO: 64002 Length 20 Port transport port number; zero when plain IP is used Protocol IANA assigned, Internet Protocol number. 17 for UDP, 0 for plain IP Reserved reserved for future use; zero when sent, ignored when received Address an IPv6 address or an IPv4 address in "IPv4-Mapped IPv6 address" format Figure 10: Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters Keranen, et al. Expires February 4, 2021 [Page 42] Internet-Draft HIP Native NAT Traversal Mode August 2020 REG_FROM contains the transport address and protocol from which the Control Relay Server sees the registration coming. RELAY_FROM contains the address from which the relayed packet was received by the Control Relay Server and the protocol that was used. RELAY_TO contains the same information about the address to which a packet should be forwarded. 5.7. LOCATOR_SET Parameter This specification reuses the format for UDP-based locators as specified in Legacy ICE-HIP [RFC5770] to be used for communicating the address candidates between two hosts. The generic and NAT- traversal-specific locator parameters are illustrated in Figure 11. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Locator Type | Locator Length| Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Type | Loc Type = 2 | Locator Length| Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Port | Transp. Proto| Kind | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: LOCATOR_SET Parameter Keranen, et al. Expires February 4, 2021 [Page 43] Internet-Draft HIP Native NAT Traversal Mode August 2020 The individual fields in the LOCATOR_SET parameter are described in Table 1. +-----------+----------+--------------------------------------------+ | Field | Value(s) | Purpose | +-----------+----------+--------------------------------------------+ | Type | 193 | Parameter type | | Length | Variable | Length in octets, excluding Type and | | | | Length fields and padding | | Traffic | 0-2 | Is the locator for HIP signaling (1), for | | Type | | ESP (2), or for both (0) | | Locator | 2 | "Transport address" locator type | | Type | | | | Locator | 7 | Length of the fields after Locator | | Length | | Lifetime in 4-octet units | | Reserved | 0 | Reserved for future extensions | | Preferred | 0 or 1 | Set to 1 for a Locator in R1 if the | | (P) bit | | Responder can use it for the rest of the | | | | base exchange, otherwise set to zero | | Locator | Variable | Locator lifetime in seconds, see Section 4 | | Lifetime | | in [RFC8046] | | Transport | Variable | Transport layer port number | | Port | | | | Transport | Variable | IANA assigned, transport layer Internet | | Protocol | | Protocol number. Currently only UDP (17) | | | | is supported. | | Kind | Variable | 0 for host, 1 for server reflexive, 2 for | | | | peer reflexive (currently unused) or 3 for | | | | relayed address | | Priority | Variable | Locator's priority as described in | | | | [RFC8445]. It is worth noting that while | | | | the priority of a single locator candidate | | | | is 32-bits, but an implementation should | | | | use a 64-bit integer to calculate the | | | | priority of a candidate pair for the ICE | | | | priority algorithm. | | SPI | Variable | Security Parameter Index (SPI) value that | | | | the host expects to see in incoming ESP | | | | packets that use this locator | | Address | Variable | IPv6 address or an "IPv4-Mapped IPv6 | | | | address" format IPv4 address [RFC4291] | +-----------+----------+--------------------------------------------+ Table 1: Fields of the LOCATOR_SET Parameter The LOCATOR parameter MUST be encapsulated inside an ENCRYPTED parameter. Keranen, et al. Expires February 4, 2021 [Page 44] Internet-Draft HIP Native NAT Traversal Mode August 2020 5.8. RELAY_HMAC Parameter As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC parameter value has the TLV type 65520. It has the same semantics as RVS_HMAC as specified in section 4.2.1 in [RFC8004]. Similarly as with RVS_HMAC, also RELAY_HMAC is keyed with the HIP integrity key (HIP-lg or HIP-gl as specified in section 6.5 in [RFC7401]), established during the relay registration procedure as described in Section 4.1. 5.9. Registration Types The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain Registration Type [RFC8003] values for Control Relay Server registration. The value for RELAY_UDP_HIP is 2 as specified in Legacy ICE-HIP [RFC5770]. The value for RELAY_UDP_ESP is (value [TBD by IANA: 3]). 5.10. Notify Packet Types A Control/Data Relay Server and end-hosts can use NOTIFY packets to signal different error conditions. The NOTIFY packet types are the same as in Legacy ICE-HIP [RFC5770] except for the two last ones, which are new. The Notify Packet Types [RFC7401] are shown below. The Notification Data field for the error notifications SHOULD contain the HIP header of the rejected packet and SHOULD be empty for the CONNECTIVITY_CHECKS_FAILED type. NOTIFICATION PARAMETER - ERROR TYPES Value ------------------------------------ ----- NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER 60 If a Control Relay Server does not forward a base exchange packet due to missing NAT traversal mode parameter, or the Initiator selects a NAT traversal mode that the (non-relay) Responder did not expect, the Control Relay Server or the Responder may send back a NOTIFY error packet with this type. CONNECTIVITY_CHECKS_FAILED 61 Used by the end-hosts to signal that NAT traversal connectivity checks failed and did not produce a working path. MESSAGE_NOT_RELAYED 62 Keranen, et al. Expires February 4, 2021 [Page 45] Internet-Draft HIP Native NAT Traversal Mode August 2020 Used by a Control Relay Server to signal that is was not able or willing to relay a HIP packet. SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63 Used by a Data Relay Server to signal that is was not able or willing to allocate a new server reflexive candidate for the Data Relay Client RVS_HMAC_PROHIBITED_WITH_RELAY 64 In the unintended event that a Control Relay Server sends any HIP message with a RVS_HMAC parameter, the Control Relay Client drops the received HIP message and sends a notify message back to the Control Relay Server using this notify type 5.11. ESP Data Packets The format for ESP data packets is identical to Legacy ICE-HIP [RFC5770]. [RFC3948] describes the UDP encapsulation of the IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets do not differ from the transport mode ESP, and thus the encapsulation of the HIP ESP packets is same as the UDP encapsulation transport mode ESP. However, the (semantic) difference to Bound End-to-End Tunnel (BEET) mode ESP packets used by HIP is that IP header is not used in BEET integrity protection calculation. During the HIP base exchange, the two peers exchange parameters that enable them to define a pair of IPsec ESP security associations (SAs) as described in [RFC7402]. When two peers perform a UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs that produces UDP-encapsulated ESP data traffic. The management of encryption/authentication protocols and SPIs is defined in [RFC7402]. The UDP encapsulation format and processing of HIP ESP traffic is described in Section 6.1 of [RFC7402]. 5.12. RELAYED_ADDRESS and MAPPED_ADDRESS Parameters While the type values are new, the format of the RELAYED_ADDRESS and MAPPED_ADDRESS parameters (Figure 12) is identical to REG_FROM, RELAY_FROM and RELAY_TO parameters. This document specifies only the use of UDP relaying, and, thus, only protocol 17 is allowed. However, future documents may specify support for other protocols. Keranen, et al. Expires February 4, 2021 [Page 46] Internet-Draft HIP Native NAT Traversal Mode August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD by IANA; RELAYED_ADDRESS: 4650 MAPPED_ADDRESS: 4660] Length 20 Port the UDP port number Protocol IANA assigned, Internet Protocol number (17 for UDP) Reserved reserved for future use; zero when sent, ignored when received Address an IPv6 address or an IPv4 address in "IPv4-Mapped IPv6 address" format Figure 12: Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters 5.13. PEER_PERMISSION Parameter The format of the new PEER_PERMISSION parameter is shown in Figure 13. The parameter is used for setting up and refreshing forwarding rules and the permissions for data packets at the Data Relay Server. The parameter contains one or more sets of Port, Protocol, Address, Outbound SPI (OSPI), and Inbound SPI (ISPI) values. One set defines a rule for one peer address. Keranen, et al. Expires February 4, 2021 [Page 47] Internet-Draft HIP Native NAT Traversal Mode August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPort | PPort | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | RAddress | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PAddress | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ISPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD by IANA; 4680] Length 48 RPort the transport layer (UDP) port at the Data Relay Server (i.e. the port of the server reflexive candidate) PPort the transport layer (UDP) port number of the peer Protocol IANA assigned, Internet Protocol number (17 for UDP) Reserved reserved for future use; zero when sent, ignored when received RAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped IPv6 address" format, of the server reflexive candidate PAddress an IPv6 address, or an IPv4 address in "IPv4-Mapped IPv6 address" format, of the peer OSPI the outbound SPI value the Data Relay Client is using for the peer ISPI the inbound SPI value the Data Relay Client is using for the peer Figure 13: Format of the PEER_PERMISSION Parameter 5.14. HIP Connectivity Check Packets The connectivity request messages are HIP UPDATE packets containing a new CANDIDATE_PRIORITY parameter (Figure 14). Response UPDATE packets contain a MAPPED_ADDRESS parameter (Figure 12). Keranen, et al. Expires February 4, 2021 [Page 48] Internet-Draft HIP Native NAT Traversal Mode August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD by IANA; 4700] Length 4 Priority the priority of a (potential) peer reflexive candidate Figure 14: Format of the CANDIDATE_PRIORITY Parameter 5.15. NOMINATE parameter Figure 15 shows the NOMINATE parameter that is used to conclude the candidate nomination process. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD by IANA; 4710] Length 4 Reserved Reserved for future extension purposes Figure 15: Format of the NOMINATE Parameter 6. Security Considerations Since the control plane protocol and Control Relay Server are essentially the same (with some minor differences) in this document as in Legacy ICE-HIP [RFC5770], the same security considerations (in Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still valid, but are repeated here for the sake of completeness. New security considerations related to the new Data Relay Server are discussed in Section 6.5, and considerations related to the new connectivity check protocol are discussed in Section 6.6 and Section 6.7. Keranen, et al. Expires February 4, 2021 [Page 49] Internet-Draft HIP Native NAT Traversal Mode August 2020 6.1. Privacy Considerations It is also possible that end-users may not want to reveal all locators to each other. For example, tracking the physical location of a multihoming end-host may become easier if it reveals all locators to its peer during a base exchange. Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments. For these two local policy reasons, it might be tempting exclude certain host addresses from the LOCATOR_SET parameter of an end-host but this is NOT RECOMMENDED. For instance, such behavior creates non-optimal paths when the hosts are located behind the same NAT. Especially, this could be problematic with a legacy NAT that does not support routing from the private address realm back to itself through the outer address of the NAT. This scenario is referred to as the hairpin problem [RFC5128]. With such a legacy NAT, the only option left would be to use a relayed transport address from an Data Relay Server. The use of Control and Data Relay Servers can be also useful for privacy purposes. For example, a privacy concerned Responder may reveal only its Control Relay Server and Relayed candidates to Initiators. This partially protects the Responder against Denial-of- Service (DoS) attacks by allowing the Responder to initiate new connections even if its relays would be unavailable due to a DoS attack. 6.2. Opportunistic Mode In opportunistic HIP mode (cf. Section 4.1.8 in [RFC7401]), an Initiator sends an I1 with without setting the destination HIT of the Responder (i.e. the Control Relay Client). A Control Relay Server SHOULD have a unique IP address per Control Relay Client when the Control Relay Server is serving more than one Control Relay Client and supports opportunistic mode. Otherwise, the Control Relay Server cannot guarantee to deliver the I1 packet to the intended recipient. Future extensions of this document may allow opportunistic mode to be used with non-unique IP addresses to be utilized either as a HIP- level anycast or multicast mechanism. Both of the mentioned cases would require a separate registration parameters that the Control Relay Server proposes and the Control Client Server accepts during registration. 6.3. Base Exchange Replay Protection for Control Relay Server In certain scenarios, it is possible that an attacker, or two attackers, can replay an earlier base exchange through a Control Relay Server by masquerading as the original Initiator and Responder. The attack does not require the attacker(s) to compromise the private Keranen, et al. Expires February 4, 2021 [Page 50] Internet-Draft HIP Native NAT Traversal Mode August 2020 key(s) of the attacked host(s). However, for this attack to succeed, the legitimate Responder has to be disconnected from the Control Relay Server. The Control Relay Server can protect itself against replay attacks by becoming involved in the base exchange by introducing nonces that the end-hosts (Initiator and Responder) are required to sign. One way to do this is to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described in [I-D.heer-hip-middle-auth] and drop the I2 or R2 packets if the corresponding ECHO_RESPONSE_M parameters are not present. 6.4. Demultiplexing Different HIP Associations Section 5.1 of [RFC3948] describes a security issue for the UDP encapsulation in the standard IP tunnel mode when two hosts behind different NATs have the same private IP address and initiate communication to the same Responder in the public Internet. The Responder cannot distinguish between two hosts, because security associations are based on the same inner IP addresses. This issue does not exist with the UDP encapsulation of HIP ESP transport format because the Responder uses HITs to distinguish between different Initiators. 6.5. Reuse of Ports at the Data Relay Server If the Data Relay Server uses the same relayed address and port (as conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay Clients, it appears to all the peers, and their firewalls, that all the Data Relay Clients are at the same address. Thus, a stateful firewall may allow packets pass from hosts that would not normally be able to send packets to a peer behind the firewall. Therefore, a Data Relay Server SHOULD NOT re-use the port numbers. If port numbers need to be re-used, the Data Relay Server SHOULD have a sufficiently large pool of port numbers and select ports from the pool randomly to decrease the chances of a Data Relay Client obtaining the same address that a another host behind the same firewall is using. 6.6. Amplification attacks A malicious host may send an invalid list of candidates to its peer that are used for targeting a victim host by flooding it with connectivity checks. To mitigate the attack, this protocol adopts the ICE mechanism to cap the total amount of connectivity checks as defined in Section 4.7. Keranen, et al. Expires February 4, 2021 [Page 51] Internet-Draft HIP Native NAT Traversal Mode August 2020 6.7. Attacks against Connectivity Checks and Candidate Gathering Section 19.2 in [RFC8445] describes attacks against ICE connectivity checks. HIP bases its control plane security on Diffie-Hellman key exchange, public keys and Hashed Message Authentication codes, meaning that the mentioned security concerns do not apply to HIP either. The mentioned section discusses also of man-in-the-middle replay attacks that are difficult to prevent. The connectivity checks in this protocol are effectively immune against replay attacks because a connectivity request includes a random nonce that the recipient must sign and send back as a response. Section 19.3 in [RFC8445] describes attacks on server reflexive address gathering. Similarly here, if the DNS, a Control Relay Server or a Data Relay Server has been compromised, not much can be done. However, the case where attacker can inject fake messages (located on a shared network segment like Wifi) does not apply here. HIP messages are integrity and replay protected, so it is not possible inject fake server reflexive address candidates. Section 19.4 in [RFC8445] describes attacks on relayed candidate gathering. Similarly to ICE TURN servers, Data Relay Server require an authenticated base exchange that protects relayed address gathering against fake requests and responses. Further, replay attacks are not possible because the HIP base exchange (and also UPDATE procedure) is protected against replay attacks. 6.8. Cross-Protocol Attacks Section 4.1 explains how a Control Relay Client registers for the RELAY_UDP_HIP service from a Control Relay Server. However, the same server may offer also Rendezvous functionality, and, thus, a client can register both to a RELAY_UDP_HIP and a RENDEZVOUS (see [RFC8004]) service from the same server. Potentially, this introduces a cross- protocol attack (or actually a "cross-message" attack) because the key material is the same for the Control Relay Service and Rendezvous HMACs. While the problem could be avoided by deriving different keys for the Control Relay Service, a more simple measure was chosen because the exact attack scenario was unclear. Consequently, this section defines a mandatory mitigation mechanism against the cross- protocol attack that works by preventing the simultanous use of Rendezvous and Control Relay Service in the context of a single HIP Association. The registration involves three parameters typically delivered sequentally in R1 (REG_INFO parameter), I2 (REG_REQUEST) and R2 (REG_RESPONSE) messages but can also be delivered in UPDATE messages Keranen, et al. Expires February 4, 2021 [Page 52] Internet-Draft HIP Native NAT Traversal Mode August 2020 as described in [RFC8003]. The parameters and the modifications to their processing are described below: 1. REG_INFO: the Control Relay Server advertizes its available services using this parameter. RELAY_UDP_HIP and RENDEZVOUS services MAY be included in the first advertizement for the HIP association but subsequent ones MUST include only one of them as agreed in earlier registrations (see steps 2 and 3). 2. REG_REQUEST: the Control Relay Client chooses the services it requires using this parameter. If the Control Relay Server offered both RENDEZVOUS or RELAY_UDP_HIP, the Control Relay Client MUST choose only one of them in the REG_REQUEST parameter. Upon choosing one of of the two, it persists throughout the lifetime of the HIP association, and the Control Relay Client MUST NOT register the other remaining one in a subsequent UPDATE message. 3. REG_RESPONSE: the Control Relay Server verifies the services requested by the Control Relay Client using this parameter. If the Control Relay Server offered both RENDEZVOUS and RELAY_UDP_HIP service, and the Control Relay Client requested for both of them, the Control Relay Client MUST offer only RELAY_UDP_HIP service in the REG_RESPONSE parameter and include a REG_FAILED parameter in the same message, with RENDEZVOUS as the Registration Type and [TBD by IANA: 9] as the Failure Type. As a further measure against cross-protocol attacks, Control Relay Client MUST drop any HIP message that includes an RVS_HMAC parameter when it originates from successfully registered Control Relay Server. Upon such an (unintended) event, the Control Relay Client MUST send a NOTIFY message with RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify Message Type to the Control Relay Server. 7. IANA Considerations This section is to be interpreted according to [RFC8126]. This document reuses the same default UDP port number 10500 as specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control plane and data plane traffic. The port was was registered separately for RFC5770 to co-author Ari Keranen but should now be re-assigned for IESG control. With the permission of Ari Keranen, the new assignee is IESG and contact "chair@ietf.org". In addition, IANA is requested to add a reference to this document in the entry for UDP port 10500 in the Transport Protocol Port Number Registry. The selection between Legacy ICE-HIP and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE parameter during the base Keranen, et al. Expires February 4, 2021 [Page 53] Internet-Draft HIP Native NAT Traversal Mode August 2020 exchange. By default, hosts listen this port for incoming UDP datagrams and can use it also for sending UDP datagrams. Other emphemeral port numbers are negotiated and utilized dynamically. This document updates the IANA Registry for HIP Parameter Types [RFC7401] by assigning new HIP Parameter Type values for the new HIP Parameters: RELAYED_ADDRESS (length 20), MAPPED_ADDRESS (length 20, defined in Section 5.12), PEER_PERMISSION (length 48, defined in Section 5.13), CANDIDATE_PRIORITY (length 4, defined in Section 5.14) and NOMINATE (length 4, defined in Section 5.15). This document updates the IANA Registry for HIP NAT traversal modes specified in Legacy ICE-HIP [RFC5770] by assigning value for the NAT traversal mode ICE-HIP-UDP (defined in Section 5.4). This document updates the IANA Registry for HIP Notify Message Types: type field NAT_KEEPALIVE in Section 5.3, a new error type SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED and RVS_HMAC_PROHIBITED_WITH_RELAY in Section 5.10. . This document defines additional registration types for the HIP Registration Extension [RFC8003] that allow registering with a Data Relay Server for ESP relaying service: RELAY_UDP_ESP (defined in Section 5.9, and performing server reflexive candidate discovery: CANDIDATE_DISCOVERY (defined in Section 4.2). This document defines an additional Registration Failure Type as defined in Section 6.8. The value is [TBD by IANA: 9] and the Registration Failure Type is "Simultaneous Rendezvous and Control Relay Service usage prohibited". ICE specification [RFC8445] discusses "Unilateral Self-Address Fixing" in section 18. This protocol is based on ICE, and thus the same considerations apply also here. 8. Contributors Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have contributed to [RFC5770]. This document leans heavily on the work in the RFC. 9. Acknowledgments Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the MMUSIC WG folks for the excellent work on ICE. The authors would like to thank also Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien Schmitt, and Abhinav Pathak for their contributions and Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey Keranen, et al. Expires February 4, 2021 [Page 54] Internet-Draft HIP Native NAT Traversal Mode August 2020 M. Ahrenholz, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani Hautakorpi, Tero Kauppinen and Timo Simanainen for their comments to [RFC5770] and this document. Thanks for Eric Vyncke, Alvaro Retana, Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuhlewind, Spencer Dawkins, Derek Fawcus, Tianran Zhou, Amanda Barber, Colin Perkins, Roni Even, Alissa Cooper, Carl Wallace, Martin Duke and Benjamin Kaduk for reviewing this document. This work has been partially funded by CyberTrust programme by Digile/Tekes in Finland. 10. References 10.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, . [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Multihoming with the Host Identity Protocol", RFC 8047, DOI 10.17487/RFC8047, February 2017, . Keranen, et al. Expires February 4, 2021 [Page 55] Internet-Draft HIP Native NAT Traversal Mode August 2020 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, . [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, . [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, July 1988, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . Keranen, et al. Expires February 4, 2021 [Page 56] Internet-Draft HIP Native NAT Traversal Mode August 2020 [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, Ed., "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, DOI 10.17487/RFC5770, April 2010, . [I-D.ietf-tcpm-rto-consider] Allman, M., "Requirements for Time-Based Loss Detection", draft-ietf-tcpm-rto-consider-16 (work in progress), June 2020. 10.2. Informative References [I-D.ietf-hip-rfc4423-bis] Moskowitz, R. and M. Komu, "Host Identity Protocol Architecture", draft-ietf-hip-rfc4423-bis-20 (work in progress), February 2019. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, DOI 10.17487/RFC5207, April 2008, . [I-D.rosenberg-mmusic-ice-nonsip] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- nonsip-01 (work in progress), July 2008. [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, March 2012, . [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, . [I-D.heer-hip-middle-auth] Heer, T., Hummen, R., and M. Komu, "End-Host Authentication for HIP Middleboxes", draft-heer-hip- middle-auth-04 (work in progress), October 2011. Keranen, et al. Expires February 4, 2021 [Page 57] Internet-Draft HIP Native NAT Traversal Mode August 2020 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)", RFC 8750, DOI 10.17487/RFC8750, March 2020, . [I-D.ietf-tsvwg-datagram-plpmtud] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and T. Voelker, "Packetization Layer Path MTU Discovery for Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-22 (work in progress), June 2020. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, . Keranen, et al. Expires February 4, 2021 [Page 58] Internet-Draft HIP Native NAT Traversal Mode August 2020 Appendix A. Selecting a Value for Check Pacing Selecting a suitable value for the connectivity check transaction pacing is essential for the performance of connectivity check-based NAT traversal. The value should not be so small that the checks cause network congestion or overwhelm the NATs. On the other hand, a pacing value that is too high makes the checks last for a long time, thus increasing the connection setup delay. The Ta value may be configured by the user in environments where the network characteristics are known beforehand. However, if the characteristics are not known, it is recommended that the value is adjusted dynamically. In this case, it is recommended that the hosts estimate the round-trip time (RTT) between them and SHOULD set the minimum Ta value so that at most a single connectivity check message is sent on every RTT. One way to estimate the RTT is to use the time that it takes for the Control Relay Server registration exchange to complete; this would give an estimate on the registering host's access link's RTT. Also, the I1/R1 exchange could be used for estimating the RTT, but since the R1 can be cached in the network, or the relaying service can increase the delay notably, this is not recommended. In general, estimating RTT can be difficult and error prone, thus the guidelines for choosing a Ta value in Section 4.4 MUST be followed. Appendix B. Differences with respect to ICE Legacy ICE-HIP reuses ICE/STUN/TURN protocol stack as it is. The benefits of such as an approach include the reuse of STUN/TURN infrastructure and possibly the reuse of existing software libraries, but there are also drawbacks with the approach. For example, ICE is meant for application-layer protocols, whereas HIP operates at layer 3.5 between transport and network layers. This is particularly problematic because the implementations employ kernelspace IPsec ESP as their data plane: demultiplexing of incoming ESP, HIP and TURN messages required capturing of all UDP packets destined to port 10500 to the userspace (due to different, incompatible markers in ESP and STUN), thus causing additional software complexity and an unnecessary latency/throughput bottleneck for the dataplane performance. It is also worth noting that demultiplexing of STUN packets in the kernel would incur an also a performance impact (albeit smaller than with userspace demultiplexing), and secure verification of STUN messages would require communication between the kernelspace STUN detector and HIP daemon typically residing in the userspace (thus, again increasing the performance overhead). Keranen, et al. Expires February 4, 2021 [Page 59] Internet-Draft HIP Native NAT Traversal Mode August 2020 Legacy ICE-HIP involves also some other complexities when compared to the approach taken in this document. Relaying of ESP packets via TURN relays was not considered that simple because TURN relays require adding and removing extra TURN framing for the relayed packets. Finally, the developers of the two Legacy ICE-HIP implementations concluded that "effort needed for integrating an ICE library into a HIP implementation turned out to be quite a bit higher that initially estimated. Also, the amount of extra code (some 10 kLoC) needed for all the new parsers, state machines, etc., is quite high and by re-using the HIP code one should be able to do with much less. This should result in smaller binary size, less bugs, and easier debugging.". Consequently, the HIP working group decided to follow ICE methodology but reuse HIP messaging format to achieve the same functionality as ICE, and consequently the result is this document that specifies the Native ICE-HIP protocol. The Native ICE-HIP protocol specified in this document follows the semantics of ICE as close as possible, and most of the differences are syntactical due to the use of a different protocol. In this section, we describe the differences to the ICE protocol. o ICE operates at the application layer, whereas this protocol operates between transport and network layers, thus hiding the protocol details from the application. o The STUN protocol is not employed. Instead, native ICE-HIP reuses the HIP control plane format in order simplify demultiplexing of different protocols. For example, the STUN binding response is replaced with a HIP UPDATE message containing an ECHO_REQUEST_SIGNED parameter and the STUN binding response with a HIP UPDATE message containing an ECHO_RESPONSE_SIGNED parameter as defined in Section 4.6. It is worth noting that a drawback of not employing STUN is that discovery of the address candidates requires creating (using HIP base exchange) and maintaining (using HIP UPDATE procedures) state at the Control Relay Client and Control Relay Server. Future extensions to this document may define a stateless, HIP-specific mechanism for an end-host to discover its address candidates. o The TURN protocol is not utilized. Instead, native ICE-HIP reuses Control Relay Servers for the same purpose. o ICMP errors may be used in ICE to signal failure. In Native ICE- HIP protocol, HIP NOTIFY messages are used instead. o Instead of the ICE username fragment and password mechanism for credentials, native ICE-HIP uses the HIT, derived from a public key, for the same purpose. The username fragments are "transient Keranen, et al. Expires February 4, 2021 [Page 60] Internet-Draft HIP Native NAT Traversal Mode August 2020 host identifiers, bound to a particular session established as part of the candidate exchange" [RFC8445]. Generally in HIP, a local public key and the derived HIT are considered long-term identifiers, and invariant across different host associations and different transport-layer flows. o In ICE, the conflict when two communicating end-points take the same controlling role is solved using random values (so called tie-breaker value). In Native ICE-HIP protocol, the conflict is solved by the standard HIP base exchange procedure, where the host with the "larger" HIT switches to Responder role, thus changing also to controlled role. o The ICE-CONTROLLED and ICE-CONTROLLING attributes are not included in the connectivity checks. o The foundation concept is unnecessary in native ICE-HIP because only a single UDP flow for the IPsec tunnel will be negotiated. o Frozen candidates are omitted for the same reason as foundation concept is excluded. o Components are omitted for the same reason as foundation concept is excluded. o Native ICE-HIP supports only "full ICE" where the two communicating hosts participate actively to the connectivity checks, and the "lite" mode is not supported. This design decision follows the guidelines of ICE which recommends full ICE implementations. However, it should be noted that a publicly reachable Responder may refuse to negotiate the ICE mode as described in Section 4.7.2. This would result in a [RFC7401] based HIP base exchange tunneled over UDP followed ESP traffic over the same tunnel, without the connectivity check procedures defined in this document (in some sense, this mode corresponds to the case where two ICE lite implementations connect since no connectivity checks are sent). o As the "ICE lite" is not adopted here and both sides are capable of ICE-HIP-UDP mode (negotiated during the base exchange), default candidates are not employed in Native ICE-HIP. o If the agent is using Diffserv Codepoint markings [RFC2475] in its media packets, it SHOULD apply those same markings to its connectivity checks. o Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP protocol but rather encrypted to avoid middlebox tampering. Keranen, et al. Expires February 4, 2021 [Page 61] Internet-Draft HIP Native NAT Traversal Mode August 2020 o Native ICE-HIP protocol does not employ the ICE related address and related port attributes (that are used for diagnostic or SIP purposes). o Minimum RTO is 500 ms in ICE but 1000 ms in Native ICE-HIP protocol in favor of [I-D.ietf-tcpm-rto-consider] Appendix C. Differences to Base Exchange and UPDATE procedures This section gives some design guidance for implementers how the extensions in this protocol extend and differ from [RFC7401] and [RFC8046]. o Both control and data plane are operated on top of UDP, not directly on IP. o A minimal implementation would conform only to Section 4.7.1 or Section 4.7.2, thus merely tunneling HIP control and data traffic over UDP. The drawback here is that it works only in the limited cases where the Responder has a public address. o It is worth noting that while a rendezvous server [RFC8004] has not been designed to be used in NATted scenarios because it just relays the first I1 packet and does not employ UDP encapsulation, the Control Relay Server forwards all control traffic and, hence, is more suitable in NATted environments. Further, the Data Relay Server guarantees forwarding of data plane traffic also in the cases when the NAT traversal procedures fail. o Registration procedures with a Control/Data Relay Server are similar as with rendezvous server. However, a Control/Data Relay Server has different registration parameters than rendezvous because it offers a different service. Also, the Control/Data Relay Server includes also a REG_FROM parameter that informs the Control/Data Relay Client about its server reflexive address. A Data Relay Server includes also a RELAYED_ADDRESS containing the relayed address for the Data Relay Client. o In [RFC7401], the Initiator and Responder can start to exchange application payload immediately after the base exchange. While exchanging data immediately after a base exchange via a Data Control Relay would be possible also here, we follow the ICE methodology to establish a direct path between two hosts using connectivity checks. This means that there will be some additional delay after the base exchange before application payload can be transmitted. The same applies for the UPDATE procedure as the connectivity checks introduce some additional delay. Keranen, et al. Expires February 4, 2021 [Page 62] Internet-Draft HIP Native NAT Traversal Mode August 2020 o In HIP without any NAT traversal support, the base exchange acts as an implicit connectivity check, and the mobility and multihoming extensions support explicit connectivity checks. After a base exchange or UPDATE based connectivity checks, a host can use the associated address pair for transmitting application payload. In this Native ICE-HIP extension, we follow the ICE methodology, where one end-point acting in the controlled role chooses the used address pair also on behalf of the other end- point acting in controlled role, which is different from HIP without NAT traversal support. Another difference is that the process of choosing an address pair is explicitly signaled using the nomination packets. The nomination process in this protocol supports only single address pair, and multihoming extensions are left for further study. o The UPDATE procedure resembles the mobility extensions defined in [RFC8046]. The first UPDATE message from the mobile host is exactly the same as in the mobility extensions. The second UPDATE message from the peer host and third from the mobile host are different in the sense that they merely acknowledge and conclude the reception of the candidates through the Control Relay Server. In other words, they do not yet test for connectivity (besides reachability through the Control Relay Server) unlike in the mobility extensions. The idea is that connectivity check procedure follows the ICE specification, which is somewhat different from the HIP mobility extensions. o The connectivity checks as defined in the mobility extensions [RFC8046] are triggered only by the peer of the mobile host. Since successful NAT traversal requires that both end-points test connectivity, both the mobile host and its peer host have to test for connectivity. In addition, this protocol validates also the UDP ports; the ports in the connectivity check must match with the response, as required by ICE. o In HIP mobility extensions [RFC8046], an outbound locator has some associated state: UNVERIFIED mean that the locator has not been tested for reachability, ACTIVE means that the address has been verified for reachability and is being used actively, and DEPRECATED means that the locator lifetime has expired. In the subset of ICE specifications used by this protocol, an individual address candidate has only two properties: type and priority. Instead, the actual state in ICE is associated with candidate pairs rather than individual addresses. The subset of ICE specifications utilized by this protocol require the following attributes for a candidate pair: valid bit, nominated bit, base and the state of connectivity check. The connectivity checks have the following states: Waiting, In-progress, Succeeded and Failed. Keranen, et al. Expires February 4, 2021 [Page 63] Internet-Draft HIP Native NAT Traversal Mode August 2020 Handling of this state attribute requires some additional logic when compared to the mobility extensions since the state is associated with a local-remote address pair rather just a remote address, and, thus, the mobility and ICE states do not have an unambiguous one-to-one mapping. o Credit-based authorization as defined in [RFC8046] could be used before candidate nomination has been concluded upon discovering working candidate pairs. However, this may result in the use of asymmetric paths for a short time period in the beginning of communications. Thus, support of credit-based authorization is left for further study. Appendix D. Multihoming Considerations This document allows a host to collect address candidates from multiple interfaces, but does not support activation and the simultaneous use of multiple address candidates. While multihoming extensions to support [RFC8047] like functionality are left for further study and experimentation, we envision here some potential compatibility improvements to support multihoming: o Data Relay Registration: a Data Relay Client acting as an Initiator with another peer host should register a new server reflexive candidate for each local transport address candidate. A Data Relay Client acting as an Responder should register a new server reflexive candidate for each { local transport address candidate, new peer host} pair for the reasons described in Section 4.12.3. In both cases, the Data Relay Client should request the additional server reflexive candidates by sending UPDATE messages originating from each of the local address candidates as described in Section 4.1. As the UPDATE messages are originating from an unknown location from the viewpoint of the Data Relay Server, it must include also a ECHO_REQUEST_SIGNED in the response in order to test for return routability. o Data Relay unregistration: this follows the procedure in Section 4 but the Data Relay Client should unregister using the particular transport address to be unregistered. All transport address pair registrations can be unregistered when no RELAYED_ADDRESS parameter is included. o PEER_PERMISSION parameter: this needs to be extended or an additional parameter is needed to declare the specific local candidate of the Data Relay Client. Alternatively, the use of the PEER_PERMISSION could be used as a wild card to open permissions for a specific peer to all of the candidates of the Data Relay Client. Keranen, et al. Expires February 4, 2021 [Page 64] Internet-Draft HIP Native NAT Traversal Mode August 2020 o Connectivity checks: the controlling host should be able to nominate multiple candidates (by repeating step 7 in Figure 5 in Section 4.6 using the additional candidate pairs). o Keepalives should be sent for all the nominated candidate pairs. Similarly, the Control/Data Relay Client should send keepalives from its local candidates to its Control/Data Relay Server transport addresses. Appendix E. DNS Considerations This section updates [RFC5770] Appendix B which will be replaced with the mechanism described in this section. [RFC5770] did not specify how an end-host can look up another end- host via DNS and initiate an UDP-based HIP base exchange with it, so this section makes an attempt to fill this gap. [RFC8005] specifies how a HIP end-host and its Rendezvous server is registered to DNS. Essentially, the public key of the end-host is stored as HI record and its Rendezvous Server as A or AAAA record. This way, the Rendezvous Server can act as an intermediary for the end-host and forward packets to it based on the DNS configuration. Control Relay Server offers similar functionality as Rendezvous Server, with the difference that the Control Relay Server forwards all control messages, not just the first I1 message. Prior to this document, the A and AAAA records in the DNS refer either to the HIP end-host itself or a Rendezvous Server [RFC8005], and control and data plane communication with the associated host has been assumed to occur directly over IPv4 or IPv6. However, this specification extends the records to be used for UDP-based communications. Let us consider the case of a HIP Initiator with the default policy to employ UDP encapsulation and the extensions defined in this document. The Initiator looks up the FQDN of a Responder, and retrieves its HI, A and AAAA records. Since the default policy is to use UDP encapsulation, the Initiator MUST send the I1 message over UDP to destination port 10500 (either over IPv4 in the case of a A record or over IPv6 in the case of a AAAA record). It MAY send an I1 message both with and without UDP encapsulation in parallel. In the case the Initiator receives R1 messages both with and without UDP encapsulation from the Responder, the Initiator SHOULD ignore the R1 messages without UDP encapsulation. The UDP encapsulated I1 packet could be received by three different types of hosts: Keranen, et al. Expires February 4, 2021 [Page 65] Internet-Draft HIP Native NAT Traversal Mode August 2020 1. HIP Control Relay Server: in this case the A/AAAA records refers to a Control Relay Server, and it will forward the packet to the corresponding Control Relay Client based on the destination HIT in the I1 packet. 2. HIP Responder supporting UDP encapsulation: in this case, the A/ AAAA records refers to the end-host. Assuming the destination HIT belongs to the Responder, it receives and processes it according to the negotiated NAT traversal mechanism. The support for the protocol defined in this document vs [RFC5770] is dynamically negotiated during the base exchange. The details are specified in Section 4.3. 3. HIP Rendezvous Server: this entity is not listening to UDP port 10500, so it will drop the I1 message. 4. HIP Responder not supporting UDP encapsulation: the targeted end- host is not listening to UDP port 10500, so it will drop the I1 message. The A/AAAA-record MUST NOT be configured to refer to a Data Relay Server unless the host in question supports also Control Relay Server functionality. It also worth noting that SRV records are not employed in this specification. While they could be used for more flexible UDP port selection, they are not suitable for end-host discovery but rather would be more suitable for the discovery of HIP-specific infrastructure. Further extensions to this document may define SRV records for Control and Data Relay Server discovery within a DNS domain. Authors' Addresses Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland Email: ari.keranen@ericsson.com Keranen, et al. Expires February 4, 2021 [Page 66] Internet-Draft HIP Native NAT Traversal Mode August 2020 Jan Melen Ericsson Hirsalantie 11 02420 Jorvas Finland Email: jan.melen@ericsson.com Miika Komu (editor) Ericsson Hirsalantie 11 02420 Jorvas Finland Email: miika.komu@ericsson.com Keranen, et al. Expires February 4, 2021 [Page 67] ./draft-ietf-6lo-deadline-time-05.txt0000644000764400076440000013503313510745742016571 0ustar iustyiusty 6lo Lijo Thomas Internet-Draft C-DAC Intended status: Standards Track S. Anamalamudi Expires: January 9, 2020 SRM University-AP S.V.R.Anand Malati Hegde Indian Institute of Science C. Perkins Futurewei July 8, 2019 Packet Delivery Deadline time in 6LoWPAN Routing Header draft-ietf-6lo-deadline-time-05 Abstract This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time critical IoT machine to machine (M2M) applications that operate within time-synchronized networks that agree on the meaning of the time representations used for the deadline time values. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Lijo Thomas, et al. Expires January 9, 2020 [Page 1] Internet-Draft 6lo Delivery Deadline Time July 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 8 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 9 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Changes from revision 04 to revision 05 . . . . . . 18 Appendix B. Changes from revision 03 to revision 04 . . . . . . 18 Appendix C. Changes from revision 02 to revision 03 . . . . . . 19 Appendix D. Changes from revision 01 to revision 02 . . . . . . 19 Appendix E. Changes between earlier versions . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Low Power and Lossy Networks (LLNs) are likely to be deployed for real time industrial applications requiring end-to-end delay guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network ("detnet") typically requires some data packets to reach their receivers within strict time bounds. Intermediate nodes use the deadline information to make appropriate packet forwarding and scheduling decisions to meet the time bounds. Lijo Thomas, et al. Expires January 9, 2020 [Page 2] Internet-Draft 6lo Delivery Deadline Time July 2019 This document specifies a new type for the Elective 6LoWPAN Routing Header (6LoRHE), so that the deadline time (i.e., the time of latest acceptable delivery) of data packets can be included within the 6LoWPAN routing header. [RFC8138] specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL routing (source routing) operation [RFC6554], header compression of RPL Packet Information [RFC6553], and IP-in-IP encapsulation. This document also specifies handling of the deadline time when packets traverse between time- synchronized networks operating in different timezones or distinct reference clocks. Time synchronization techniques are outside the scope of this document. There are a number of standards available for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. The Deadline-6LoRHE can be used in any time synchronized 6Lo network. A 6TiSCH network is used to describe the implementation of the Deadline-6LoRHE, but this does not preclude its use in scenarios other than 6TiSCH. For instance, there is a growing interest in using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in industrial IoT [dotBLEMesh]. BLE mesh time synchronization is being explored by the Bluetooth community. There are also cases under consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174]. This document uses the terminology defined in [RFC6550] and [I-D.ietf-6tisch-terminology]. 3. 6LoRHE Generic Format Note: this section is not normative and is included for convenience. The generic header format of the 6LoRHE is specified in [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE generic format. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |1|0|1| Length | Type | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ <--- length ---> Figure 1: 6LoRHE format Lijo Thomas, et al. Expires January 9, 2020 [Page 3] Internet-Draft 6lo Delivery Deadline Time July 2019 o Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE if the Type is not recognized/supported. o Type (variable length): Type of the 6LoRHE (see Section 7) 4. Deadline-6LoRHE The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 datagram in a compressed form. Along with the deadline, the header can include the packet Origination Time Delta (OTD), the time at which the packet is enqueued for transmission (expressed as a value to be subtracted from DT); this enables a close estimate of the total delay incurred by a packet. The OTD field is initialized by the sender based on the current time at the outgoing network interface through which the packet is forwarded. Since the OTD is a delta, the length of the OTD field (i.e., OTL) will require fewer bits than the length of the DT field (i.e., DTL). The deadline field contains the value of the deadline time for the packet -- in other words, the time by which the application expects the packet to be delivered to the Receiver. packet_deadline_time = packet_origination_time + max_delay In order to support delay-sensitive deterministic applications, all nodes within the network should process the Deadline-6LoRHE. The packet deadline time (DT) and origination time (OTD) are represented in time units determined by a scaling parameter in the routing header. The Network ASN (Absolute Slot Number) can be used as a time unit in a time slotted synchronized network (for instance a 6TiSCH network, where global time is maintained in the units of slot lengths of a certain resolution). The delay experienced by packets in the network is a useful metric for network diagnostics and performance monitoring. Whenever a packet crosses into a network using a different reference clock, the Destination Time field is updated to represent the same Destination Time, but expressed using the reference clock of the interface into the new network. Then the origination time is the same as the current time when the packet is transmitted into the new network, minus the delay already experienced by the packet, say 'current_dly'. In this way, within the newly entered network, the packet will appear to have originated 'current_dly' time units earlier with respect to the reference clock of the new network. new_network_origin_time = time_now_in_new_network - current_dly Lijo Thomas, et al. Expires January 9, 2020 [Page 4] Internet-Draft 6lo Delivery Deadline Time July 2019 The following example illustrates these calculations when a packet travels between three networks, each in a different time zone. 'x' can be 1, 2 or 3. Suppose that the deadline time as measured in timezone 1 is 1050 and the origination time is 50. Suppose that the difference between TZ2 and TZ1 is 900, and the difference between TZ3 and TZ3 is 3600. In the figure, OT is the origination time as measured in the current timezone, and is equal to DT - OTD, that is, DT - 1000. Figure 2 uses the following abbreviations: TxA : Time of arrival of packet in the network 'x' TxD : Departure time of packet from the network 'x' dlyx : Delay experienced by the packet in the previous network(s) TZx : The time zone of network 'x' TZ1 TZ2 TZ3 T1A=50| | | |---- dly1=50 | | | \ | | | \ | | | \ T1D=100 |T2A=1000 | | -------->|----- dly2=450 | | | \ | | | \ | | | \ T2D=1400 | T3A=5000 | | ------------------->|----------> | | | v v v dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2 = 100-50 = 1400 - 950 = 50 = 450 OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2 = 50 = 1000-50 = 5000 - 450 = 950 = 4550 Figure 2: Destination Time Update example There are multiple ways that a packet can be delayed, including queuing delay, MAC layer contention delay, serialization delay, and propagation delays. Sometimes there are processing delays as well. For the purpose of determining whether or not the deadline has already passed, these various delays are not distinguished. Lijo Thomas, et al. Expires January 9, 2020 [Page 5] Internet-Draft 6lo Delivery Deadline Time July 2019 5. Deadline-6LoRHE Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|1| Length | 6LoRH Type |D| TU| DTL | OTL | BinaryPt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DT (variable length) | OTD(variable length)(optional)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Deadline-6LoRHE format o Length (5 bits): Length represents the total length of the Deadline-6LoRHE type measured in octets. o 6LoRH Type: TBD (see Section 7) o D flag (1 bit): The 'D' flag, set by the Sender, qualifies the action to be taken when a 6LR detects that the deadline time has elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed. If 'D' bit is 0, the packet MAY be forwarded on an exception basis, if the forwarding node is NOT in a situation of constrained resource, and if there are reasons to suspect that downstream nodes might find it useful (delay measurements, interpolations, etc.). o TU (2 bits) : Indicates the time units for DT and OTD fields. The encodings for the DT and OTD fields use the same time units and precision. * 00 : Time represented in seconds and fractional seconds * 01 : Reserved * 10 : Network ASN * 11 : Reserved o DTL (4 bits): Length of DT field as an unsigned 4-bit integer, encoding the length of the field in hex digits, minus one. o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, encoding the length of the field in hex digits. If OTL == 0, the OTD field is not present. The value of OTL MUST NOT exceed the value of DTL plus one. * For example, DTL = 0b0000 means the deadline time in the 6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the origination time is 7 hex digits (28 bits) long. o Binary Pt (6 bits) : If zero, the number of bits of the integer part the DT is equal to the number of bits of the fractional part of the DT. if nonzero, the Binary Pt is a signed integer determining the position of the binary point within the value for the DT. Lijo Thomas, et al. Expires January 9, 2020 [Page 6] Internet-Draft 6lo Delivery Deadline Time July 2019 * If BinaryPt value is positive, then the number of bits for the integer part of the DT is increased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly reduced. This increases the range of DT. * If BinaryPt value is negative, then the number of bits for the integer part of the DT is decreased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly increased. This increases the precision of the fractional seconds part of DT. o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits giving the Deadline Time value o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits giving the Origination Time as a negative offset from the DT value Whenever a sender initiates the IP datagram, it includes the Deadline-6LoRHE along with other 6LoRH information. For information about the time synchronization requirements between sender and receiver see Section 8. For the chosen time unit, a compressed time representation is available as follows. First, the application on the originating node has to determine how many time bits are needed to represent the difference between the time at which the packet is launched and the deadline time, including the representation of fractional time units. That number of bits (say, N_bits) determines DTL (the length of the Deadline Time (DT)) as follows: DTL = (N_bits mod 4) The number of bits determined by DTL allows counting any number of fractional time units in the range of interest determined by DT and the origination time OT. Denote this number of fractional time units to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL). Epoch_Range(DTL) = (2^(4*(DTL+1)) Each point of time between OT and DT is represented by a time unit and a fractional time unit; in this section, this combined representation is called a rational time unit (RTU). 1 RTU measures the smallest fractional time that can be represented between two points of time in the epoch (i.e., within the range of interest). DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The values that can be represented in the current epoch are in the range [0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL, Lijo Thomas, et al. Expires January 9, 2020 [Page 7] Internet-Draft 6lo Delivery Deadline Time July 2019 wraparound is allowed but works naturally with the arithmetic modulo Epoch_Range. By default, DTL determines t_0 in the chosen RTUs as follows: t_0 = [current_time - (current_time mod Epoch_Range (DTL))]. Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current epoch. The last possible origination time representable in the current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)). In the RTUs chosen, the current epoch resides at the underlying time interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then wraparound within the Epoch_Range occurs naturally. In all cases, OT is represented by the value (OT mod Epoch_Range) and DT is represented by the value (DT mod Epoch_Range). All arithmetic is to be performed modulo (Epoch_Range(DTL)), yielding only positive values for DT - OT. Example: Consider a 6TiSCH network with time-slot length of 10ms. Let the time units be ASNs (TU == (binary)0b10). Let the current ASN when the packet is originated be 54400, and the maximum allowable delay (max_delay) for the packet delivery be 1 second from the packet origination, then: deadline_time = packet_origination_time + max_delay = 0xD480 + 0x64 (Network ASNs) = 0xD4E4 (Network ASNs) Then, the Deadline-6LoRHE encoding with nonzero OTL is: DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD = 0x64 6. Deadline-6LoRHE in Three Network Scenarios In this section, Deadline-6LoRHE operation is described for 3 network scenarios. Figure 4 depicts a constrained time-synchronized LLN that has two subnets N1 and N2, connected through LBRs [I-D.ietf-6lo-backbone-router] with different reference clock times T1 and T2. Lijo Thomas, et al. Expires January 9, 2020 [Page 8] Internet-Draft 6lo Delivery Deadline Time July 2019 +-------------------+ | Time Synchronized | | Network | +---------+---------+ | | | +--------------+--------------+ | | +-----+ +-----+ | | Backbone | | Backbone o | | router | | router +-----+ +-----+ o o o o o o o o o o o o o LLN o o LLN o o o o o o o o o o o 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) Figure 4: Intra-network Timezone Scenario 6.1. Scenario 1: Endpoints in the same DODAG (N1) In scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram to be routed to a Receiver 'R' within the same DODAG. For the route segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by encoding the deadline time contained in the packet. Subsequently, each 6LR will perform hop-by-hop routing to forward the packet towards the 6LBR. Once 6LBR receives the IP datagram, it sends the packet downstream towards 'R'. In case of a network running RPL non-storing mode, the 6LBR generates a IPv6-in-IPv6 encapsulated packet when sending the packet downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the Deadline-6LoRHE from the Sender originated IP header to the outer IP header. The Deadline-6LoRHE contained in the inner IP header is removed. Lijo Thomas, et al. Expires January 9, 2020 [Page 9] Internet-Draft 6lo Delivery Deadline Time July 2019 +-------+ ^ | 6LBR | | | | | | | +-------+ | Upward | / /| \ | Downward routing | (F) / | \ | routing | / \ (C) | (D) | | / \ | | / |\ | | (A) (B) : (E) : R | | /|\ | \ / \ | | S : : : : : : v Figure 5: End points within same DODAG (subnet N1) At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is copied back from the outer header to inner header, and the inner IP packet is delivered to 'R'. 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. In scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG 1) has IP datagram to be routed to a Receiver 'R' over a time- synchronized IPv6 network. For the route segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform hop-by-hop routing to forward the packet towards the 6LBR. Once the Deadline Time information reaches the border router, the packet will be encoded according to the mechanism prescribed in the other time- synchronized network depicted as "Time Synchronized Network" in the figure 6. The specific data encapsulation mechanisms followed in the new network are beyond the scope of this document. Lijo Thomas, et al. Expires January 9, 2020 [Page 10] Internet-Draft 6lo Delivery Deadline Time July 2019 +----------------+ | Time | | Synchronized |------R | Network | +----------------+ | | ----------+----------- ^ | | +---+---+ | | 6LBR | Upward | | | routing | +------++ | (F)/ /| \ | / \ / | \ | / \ (C) | (D) | (A) (B) | | / |\ | /|\ |\ : (E) : : | S : : : : / \ : : Figure 6: Packet transmission in Dissimilar L2 Technologies or Internet For instance, the IP datagram could be routed to another time synchronized deterministic network using the mechanism specified in the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time would be updated according to the measurement of the current time in the new network. 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). Consider the scenario depicted in Figure 7, in which the Sender 'S' (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' belonging to another DODAG (DODAG 2). The operation of this scenario can be decomposed into combination of case 1 and case 2 scenarios. For the route segment from 'S' to 6LBR1, 'S' includes the Deadline- 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR1. Once the IP datagram reaches 6LBR1 of DODAG1, it applies the same rule as described in Case 2 while routing the packet to 6LBR2 over a (likely) time synchronized wired backhaul. The wired side of 6LBR2 can be mapped to receiver of Case 2. Once the packet reaches 6LBR2, it updates the Deadline- 6LoRHE by adding or subtracting the difference of time of DODAG2 and sends the packet downstream towards 'R'. Lijo Thomas, et al. Expires January 9, 2020 [Page 11] Internet-Draft 6lo Delivery Deadline Time July 2019 Time Synchronized Network -+---------------------------+- | | DODAG1 +---+---+ +---+---+ DODAG2 | 6LBR1 | | 6LBR2 | | | | | +-------+ +-------+ (F)/ /| \ (F)/ /| \ / \ / | \ / \ / | \ / \ (C) | (D) / \ (C) | (D) (A) (B) | | / |\ (A) (B) | | |\ /|\ |\ : (E) : : /|\ |\ : (E) : : S : : : : / \ : : : : : / \ : : : R Network N1, time zone T1 Network N2, time zone T2 Figure 7: Packet transmission in different DODAGs(N1 to N2) Consider an example of a 6TiSCH network in which S in DODAG1 generates the packet at ASN 20000 to R in DODAG2. Let the maximum allowable delay be 1 second. The time-slot length in DODAG1 and DODAG2 is assumed to be 10ms. Once the deadline time is encoded in Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose the packet reaches 6LBR of DODAG1 at ASN 20030. current_time = ASN at LBR * slot_length_value remaining_time = deadline_time - current_time = ((packet_origination_time + max_delay) - current time) = (20000 + 100) - 20030 = 30 (in Network ASNs) = 30 * 10^3 milliseconds. Once the Deadline Time information reaches the border router, the packet will be encoded according to the mechanism prescribed in the other time-synchronized network. 7. IANA Considerations This document defines a new Elective 6LoWPAN Routing Header Type, and IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch Page1 number space for this purpose. Lijo Thomas, et al. Expires January 9, 2020 [Page 12] Internet-Draft 6lo Delivery Deadline Time July 2019 Elective 6LoRH Type Value +----------------------+--------+ | Deadline-6LoRHE | TBD | +----------------------+--------+ Figure 8: Deadline-6LoRHE type 8. Synchronization Aspects The document supports time representation of the deadline and origination times carried in the packets traversing through networks of different time zones having different time synchronization mechanisms. For instance, in a 6TiSCH network where the time is maintained as ASN time slots, the time synchronization is achieved through beaconing among the nodes as described in [RFC7554]. There could be 6lo networks that employ NTP where the nodes are synchronized with an external reference clock from an NTP server. The specification of the time synchronization method that need to be followed by a network is beyond the scope of the document. The number of hex digits chosen to represent DT, and the portion of that field allocated to represent integer number of seconds, determines the meaning of t_0, i.e., the meaning of DT == 0 in the chosen representation. If DTL == 0, then there are only 4 bits that can be used to count the time units, so that DT == 0 can never be more than 16 time units (or fractional time units) in the past. This then requires that the time synchronization between sender and receiver has to be tighter than 16 units. If the binary point were moved so that all the bits were used for fractional time units (e.g., fractional seconds or fractional ASNs), the time synchronization requirement would be correspondingly tighter. A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. That is enough to represent the NTP [RFC5905] 64-bit timestamp format, which is more than enough for the purposes of establishing deadline times. Unless the binary point is moved, this is enough to represent time since year 1900. For example, suppose that DTL = 0b0000 and the DT bits are split evenly; then we can count up to 3.75 seconds by quarter-seconds. If DTL = 3 and the DT bits are again split evenly, then we can count up to 256 seconds (in steps of 1/256 of a second). In all cases, t_0 is defined as specified in Section 5 t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] Lijo Thomas, et al. Expires January 9, 2020 [Page 13] Internet-Draft 6lo Delivery Deadline Time July 2019 regardless of the choice of TU. For TU = 0b00, the time units are seconds. With DTL == 15, and Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00 UTC. The resolution is then (2 ^ (- 32)) seconds, which is the maximum possible. This time format wraps around every 2^32 seconds, which is roughly 136 years. For TU = 0b10, the time units are ASNs. The start time is relative, and updated by a mechanism out of scope for this document. With 10 ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for the ASN to wrap around. Typically, the number of hex digits allocated for TU = 0b10 would be less than 15. 9. Security Considerations The security considerations of [RFC4944], [RFC6282] and [RFC6553] apply. Using a compressed format as opposed to the full in-line format is logically equivalent and does not create an opening for a new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. The protocol elements specified in this document are designed to work in controlled operational environments (e.g., industrial process control and automation). In order to avoid misuse of the deadline information that could potentially result in a Denial of Service (DoS) attack, proper functioning of this deadline time mechanism requires the provisioning and management of network resources for supporting traffic flows with deadlines, performance monitoring, and admission control policy enforcement. The network provisioning can be done either centrally or in a distributed fashion. For example, tracks in a 6tisch network could be established by a centralized PCE, as described in the 6tisch architecture [I-D.ietf-6tisch-architecture]. The Security Considerations of Detnet architecture [I-D.ietf-detnet-architecture] mostly apply to this document as well, as follows. To secure the request and control of resources allocated for tracks, authentication and authorization can be used for each device, and network controller devices. In the case of distributed control protocols, security is expected to be provided by the security properties of the protocols in use. When deadline bearing flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows, when compared to networks that do not include per-flow identification. The security implications of disclosing that additional information deserve consideration when implementing this deadline specification. Lijo Thomas, et al. Expires January 9, 2020 [Page 14] Internet-Draft 6lo Delivery Deadline Time July 2019 Because of the requirement of precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in [RFC7384]. 10. Acknowledgements The authors thank Pascal Thubert for suggesting the idea and encouraging the work. Thanks to Shwetha Bhandari's suggestions which were instrumental in extending the timing information to heterogeneous networks. The authors acknowledge the 6TiSCH WG members for their inputs on the mailing list. Special thanks to Jerry Daniel, Dan Frost (Routing Directorate) Charlie Kaufman (Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for their support and valuable feedback. 11. References 11.1. Normative References [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-10 (work in progress), March 2018. [I-D.ietf-detnet-architecture] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", draft-ietf- detnet-architecture-13 (work in progress), May 2019. [I-D.ietf-roll-routing-dispatch] Thubert, P., Bormann, C., Toutain, L., and R. Cragie, "6LoWPAN Routing Header", draft-ietf-roll-routing- dispatch-05 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . Lijo Thomas, et al. Expires January 9, 2020 [Page 15] Internet-Draft 6lo Delivery Deadline Time July 2019 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, . [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, . [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, . [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Lijo Thomas, et al. Expires January 9, 2020 [Page 16] Internet-Draft 6lo Delivery Deadline Time July 2019 11.2. Informative References [dot15-tsch] "IEEE 802 Wireless", "IEEE Standard for Low-Rate Wireless Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016. [dot1AS-2011] "IEEE Standards", "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", March 2011. [dotBLEMesh] Leonardi, L., Pattim, G., and L. Lo Bello, "Multi-Hop Real-Time Communications Over Bluetooth Low Energy Industrial Wireless Mesh Networks", IEEE Access Vol 6, 26505-26519, May 2018. [dotWi-SUN] Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN Communication Systems", IEICE Transactions on Communications volume E100.B, Jan 2017. [I-D.ietf-6lo-backbone-router] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Backbone Router", draft-ietf-6lo-backbone-router-11 (work in progress), February 2019. [I-D.ietf-6lo-blemesh] Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", draft-ietf-6lo-blemesh-05 (work in progress), March 2019. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work in progress), July 2019. [I-D.ietf-detnet-use-cases] Grossman, E., "Deterministic Networking Use Cases", draft- ietf-detnet-use-cases-20 (work in progress), December 2018. Lijo Thomas, et al. Expires January 9, 2020 [Page 17] Internet-Draft 6lo Delivery Deadline Time July 2019 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- data-06 (work in progress), July 2019. [I-D.ietf-roll-useofrplinfo] Robles, I., Richardson, M., and P. Thubert, "Using RPL Option Type, Routing Header for Source Routes and IPv6-in- IPv6 encapsulation in the RPL Data Plane", draft-ietf- roll-useofrplinfo-31 (work in progress), July 2019. [ieee-1588] "IEEE Standards", "IEEE Std 1588-2008 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", July 2008. [Wi-SUN_PHY] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 2016. Appendix A. Changes from revision 04 to revision 05 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-04.txt and ...-05.txt. o Included additional relevant material in Security Considerations regarding expected deployment scenarios and the effect of disclosing additional information during the travel of a packet. o Reworked the specification for using time ranges shorter than the maximum allowed by the choice of TU, so that fewer bits are needed to represent DT and OT. o Revised the figures and examples to use new parameters o Reordered the field definitions for the Deadline-6LoRHE. o Responded to numerous reviewer comments to improve terminology and editorial consistency. Appendix B. Changes from revision 03 to revision 04 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-03.txt and ...-04.txt. Lijo Thomas, et al. Expires January 9, 2020 [Page 18] Internet-Draft 6lo Delivery Deadline Time July 2019 o Replaced OT (Origination Time) field by OTD (Origination Time Delta), allowing a more compressed representation that needs less processing during transitions between networks. o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in favor of BinaryPt. o Revised the figures and examples to use new parameters o Added new section on Synchronization Aspects to supply pertinent information about how nodes agree on the meaning of t=0. o Responded to numerous reviewer comments to improve editorial consistency and improve terminology. Appendix C. Changes from revision 02 to revision 03 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-02.txt and ...-03.txt. o Added non-normative 6LoRHE description, citing RFC 8138. o Specified that the Origination Time (OT) is the time that packet is enqueued for transmission. o Mentioned more sources of packet delay. o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. o Clarified that DT, OT, DTL and OTL are unsigned integers. o Updated bibliographic citations, including BLEmesh and Wi-SUN. Appendix D. Changes from revision 01 to revision 02 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-01.txt and ...-02.txt. o Replaced 6LoRHE description by reference to RFC 8138. o Added figure to illustrate change to Origination Time when a packet crosses timezone boundaries. o Clarified that use of 6tisch networks is descriptive, not normative. o Clarified that In-Band OAM is used as an example and is not normative. Lijo Thomas, et al. Expires January 9, 2020 [Page 19] Internet-Draft 6lo Delivery Deadline Time July 2019 o Updated bibliographic citations. o Alphabetized contributor names. Appendix E. Changes between earlier versions This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-00.txt and ...-01.txt. o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is passed (see Section 5). o Added explanatory text about how packet delays might arise. (see Section 4). o Mentioned availability of time-synchronization protocols (see Section 1). o Updated bibliographic citations. o Alphabetized contributor names. o Added this section. Authors' Addresses Lijo Thomas C-DAC Centre for Development of Advanced Computing (C-DAC), Vellayambalam Trivandrum 695033 India Email: lijo@cdac.in Satish Anamalamudi SRM University-AP Amaravati Campus Amaravati, Andhra Pradesh 522 502 India Email: satishnaidu80@gmail.com Lijo Thomas, et al. Expires January 9, 2020 [Page 20] Internet-Draft 6lo Delivery Deadline Time July 2019 S.V.R Anand Indian Institute of Science Bangalore 560012 India Email: anand@ece.iisc.ernet.in Malati Hegde Indian Institute of Science Bangalore 560012 India Email: malati@ece.iisc.ernet.in Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara 95050 Unites States Email: charliep@computer.org Lijo Thomas, et al. Expires January 9, 2020 [Page 21] ./draft-ietf-cbor-7049bis-16.txt0000644000764400076440000060327413735134017015423 0ustar iustyiusty Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Obsoletes: 7049 (if approved) P. Hoffman Intended status: Standards Track ICANN Expires: 3 April 2021 30 September 2020 Concise Binary Object Representation (CBOR) draft-ietf-cbor-7049bis-16 Abstract The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 April 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Bormann & Hoffman Expires 3 April 2021 [Page 1] Internet-Draft CBOR September 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. CBOR Data Models . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Extended Generic Data Models . . . . . . . . . . . . . . 9 2.2. Specific Data Models . . . . . . . . . . . . . . . . . . 9 3. Specification of the CBOR Encoding . . . . . . . . . . . . . 10 3.1. Major Types . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Indefinite Lengths for Some Major Types . . . . . . . . . 14 3.2.1. The "break" Stop Code . . . . . . . . . . . . . . . . 14 3.2.2. Indefinite-Length Arrays and Maps . . . . . . . . . . 14 3.2.3. Indefinite-Length Byte Strings and Text Strings . . . 16 3.2.4. Summary of indefinite-length use of major types . . . 17 3.3. Floating-Point Numbers and Values with No Content . . . . 18 3.4. Tagging of Items . . . . . . . . . . . . . . . . . . . . 20 3.4.1. Standard Date/Time String . . . . . . . . . . . . . . 23 3.4.2. Epoch-based Date/Time . . . . . . . . . . . . . . . . 23 3.4.3. Bignums . . . . . . . . . . . . . . . . . . . . . . . 24 3.4.4. Decimal Fractions and Bigfloats . . . . . . . . . . . 25 3.4.5. Content Hints . . . . . . . . . . . . . . . . . . . . 26 3.4.5.1. Encoded CBOR Data Item . . . . . . . . . . . . . 27 3.4.5.2. Expected Later Encoding for CBOR-to-JSON Converters . . . . . . . . . . . . . . . . . . . . 27 3.4.5.3. Encoded Text . . . . . . . . . . . . . . . . . . 28 3.4.6. Self-Described CBOR . . . . . . . . . . . . . . . . . 29 4. Serialization Considerations . . . . . . . . . . . . . . . . 29 4.1. Preferred Serialization . . . . . . . . . . . . . . . . . 29 4.2. Deterministically Encoded CBOR . . . . . . . . . . . . . 31 4.2.1. Core Deterministic Encoding Requirements . . . . . . 31 4.2.2. Additional Deterministic Encoding Considerations . . 32 4.2.3. Length-first Map Key Ordering . . . . . . . . . . . . 34 5. Creating CBOR-Based Protocols . . . . . . . . . . . . . . . . 35 5.1. CBOR in Streaming Applications . . . . . . . . . . . . . 35 5.2. Generic Encoders and Decoders . . . . . . . . . . . . . . 36 5.3. Validity of Items . . . . . . . . . . . . . . . . . . . . 37 5.3.1. Basic validity . . . . . . . . . . . . . . . . . . . 37 5.3.2. Tag validity . . . . . . . . . . . . . . . . . . . . 37 Bormann & Hoffman Expires 3 April 2021 [Page 2] Internet-Draft CBOR September 2020 5.4. Validity and Evolution . . . . . . . . . . . . . . . . . 38 5.5. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.6. Specifying Keys for Maps . . . . . . . . . . . . . . . . 40 5.6.1. Equivalence of Keys . . . . . . . . . . . . . . . . . 42 5.7. Undefined Values . . . . . . . . . . . . . . . . . . . . 43 6. Converting Data between CBOR and JSON . . . . . . . . . . . . 43 6.1. Converting from CBOR to JSON . . . . . . . . . . . . . . 43 6.2. Converting from JSON to CBOR . . . . . . . . . . . . . . 44 7. Future Evolution of CBOR . . . . . . . . . . . . . . . . . . 46 7.1. Extension Points . . . . . . . . . . . . . . . . . . . . 46 7.2. Curating the Additional Information Space . . . . . . . . 47 8. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 47 8.1. Encoding Indicators . . . . . . . . . . . . . . . . . . . 49 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 9.1. Simple Values Registry . . . . . . . . . . . . . . . . . 50 9.2. Tags Registry . . . . . . . . . . . . . . . . . . . . . . 50 9.3. Media Type ("MIME Type") . . . . . . . . . . . . . . . . 51 9.4. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 51 9.5. The +cbor Structured Syntax Suffix Registration . . . . . 52 10. Security Considerations . . . . . . . . . . . . . . . . . . . 53 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 11.1. Normative References . . . . . . . . . . . . . . . . . . 55 11.2. Informative References . . . . . . . . . . . . . . . . . 57 Appendix A. Examples of Encoded CBOR Data Items . . . . . . . . 59 Appendix B. Jump Table for Initial Byte . . . . . . . . . . . . 63 Appendix C. Pseudocode . . . . . . . . . . . . . . . . . . . . . 66 Appendix D. Half-Precision . . . . . . . . . . . . . . . . . . . 69 Appendix E. Comparison of Other Binary Formats to CBOR's Design Objectives . . . . . . . . . . . . . . . . . . . . . . . 70 E.1. ASN.1 DER, BER, and PER . . . . . . . . . . . . . . . . . 71 E.2. MessagePack . . . . . . . . . . . . . . . . . . . . . . . 71 E.3. BSON . . . . . . . . . . . . . . . . . . . . . . . . . . 72 E.4. MSDTP: RFC 713 . . . . . . . . . . . . . . . . . . . . . 72 E.5. Conciseness on the Wire . . . . . . . . . . . . . . . . . 72 Appendix F. Well-formedness errors and examples . . . . . . . . 73 F.1. Examples for CBOR data items that are not well-formed . . 74 Appendix G. Changes from RFC 7049 . . . . . . . . . . . . . . . 76 G.1. Errata processing, clerical changes . . . . . . . . . . . 76 G.2. Changes in IANA considerations . . . . . . . . . . . . . 77 G.3. Changes in suggestions and other informational components . . . . . . . . . . . . . . . . . . . . . . . 77 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 Bormann & Hoffman Expires 3 April 2021 [Page 3] Internet-Draft CBOR September 2020 1. Introduction There are hundreds of standardized formats for binary representation of structured data (also known as binary serialization formats). Of those, some are for specific domains of information, while others are generalized for arbitrary data. In the IETF, probably the best-known formats in the latter category are ASN.1's BER and DER [ASN.1]. The format defined here follows some specific design goals that are not well met by current formats. The underlying data model is an extended version of the JSON data model [RFC8259]. It is important to note that this is not a proposal that the grammar in RFC 8259 be extended in general, since doing so would cause a significant backwards incompatibility with already deployed JSON documents. Instead, this document simply defines its own data model that starts from JSON. Appendix E lists some existing binary formats and discusses how well they do or do not fit the design objectives of the Concise Binary Object Representation (CBOR). This document is a revised edition of [RFC7049], with editorial improvements, added detail, and fixed errata. This revision formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. It does not create a new version of the format. 1.1. Objectives The objectives of CBOR, roughly in decreasing order of importance, are: 1. The representation must be able to unambiguously encode most common data formats used in Internet standards. * It must represent a reasonable set of basic data types and structures using binary encoding. "Reasonable" here is largely influenced by the capabilities of JSON, with the major addition of binary byte strings. The structures supported are limited to arrays and trees; loops and lattice-style graphs are not supported. * There is no requirement that all data formats be uniquely encoded; that is, it is acceptable that the number "7" might be encoded in multiple different ways. Bormann & Hoffman Expires 3 April 2021 [Page 4] Internet-Draft CBOR September 2020 2. The code for an encoder or decoder must be able to be compact in order to support systems with very limited memory, processor power, and instruction sets. * An encoder and a decoder need to be implementable in a very small amount of code (for example, in class 1 constrained nodes as defined in [RFC7228]). * The format should use contemporary machine representations of data (for example, not requiring binary-to-decimal conversion). 3. Data must be able to be decoded without a schema description. * Similar to JSON, encoded data should be self-describing so that a generic decoder can be written. 4. The serialization must be reasonably compact, but data compactness is secondary to code compactness for the encoder and decoder. * "Reasonable" here is bounded by JSON as an upper bound in size, and by the implementation complexity limiting how much effort can go into achieving that compactness. Using either general compression schemes or extensive bit-fiddling violates the complexity goals. 5. The format must be applicable to both constrained nodes and high- volume applications. * This means it must be reasonably frugal in CPU usage for both encoding and decoding. This is relevant both for constrained nodes and for potential usage in applications with a very high volume of data. 6. The format must support all JSON data types for conversion to and from JSON. * It must support a reasonable level of conversion as long as the data represented is within the capabilities of JSON. It must be possible to define a unidirectional mapping towards JSON for all types of data. 7. The format must be extensible, and the extended data must be decodable by earlier decoders. * The format is designed for decades of use. Bormann & Hoffman Expires 3 April 2021 [Page 5] Internet-Draft CBOR September 2020 * The format must support a form of extensibility that allows fallback so that a decoder that does not understand an extension can still decode the message. * The format must be able to be extended in the future by later IETF standards. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now-customary sense as a synonym for "octet". All multi-byte values are encoded in network byte order (that is, most significant byte first, also known as "big-endian"). This specification makes use of the following terminology: Data item: A single piece of CBOR data. The structure of a data item may contain zero, one, or more nested data items. The term is used both for the data item in representation format and for the abstract idea that can be derived from that by a decoder; the former can be addressed specifically by using "encoded data item". Decoder: A process that decodes a well-formed encoded CBOR data item and makes it available to an application. Formally speaking, a decoder contains a parser to break up the input using the syntax rules of CBOR, as well as a semantic processor to prepare the data in a form suitable to the application. Encoder: A process that generates the (well-formed) representation format of a CBOR data item from application information. Data Stream: A sequence of zero or more data items, not further assembled into a larger containing data item (see [RFC8742] for one application). The independent data items that make up a data stream are sometimes also referred to as "top-level data items". Well-formed: A data item that follows the syntactic structure of CBOR. A well-formed data item uses the initial bytes and the byte strings and/or data items that are implied by their values as defined in CBOR and does not include following extraneous data. CBOR decoders by definition only return contents from well-formed data items. Bormann & Hoffman Expires 3 April 2021 [Page 6] Internet-Draft CBOR September 2020 Valid: A data item that is well-formed and also follows the semantic restrictions that apply to CBOR data items (Section 5.3). Expected: Besides its normal English meaning, the term "expected" is used to describe requirements beyond CBOR validity that an application has on its input data. Well-formed (processable at all), valid (checked by a validity-checking generic decoder), and expected (checked by the application) form a hierarchy of layers of acceptability. Stream decoder: A process that decodes a data stream and makes each of the data items in the sequence available to an application as they are received. Terms and concepts for floating-point values such as Infinity, NaN (not a number), negative zero, and subnormal are defined in [IEEE754]. Where bit arithmetic or data types are explained, this document uses the notation familiar from the programming language C [C], except that "**" denotes exponentiation and ".." denotes a range that includes both ends given. Examples and pseudocode assume that signed integers use two's complement representation and that right shifts of signed integers perform sign extension; these assumptions are also specified in Sections 6.8.2 and 7.6.7 of the 2020 version of C++, successor of [Cplusplus17]. Similar to the "0x" notation for hexadecimal numbers, numbers in binary notation are prefixed with "0b". Underscores can be added to a number solely for readability, so 0b00100001 (0x21) might be written 0b001_00001 to emphasize the desired interpretation of the bits in the byte; in this case, it is split into three bits and five bits. Encoded CBOR data items are sometimes given in the "0x" or "0b" notation; these values are first interpreted as numbers as in C and are then interpreted as byte strings in network byte order, including any leading zero bytes expressed in the notation. Words may be _italicized_ for emphasis; in the plain text form of this specification this is indicated by surrounding words with underscore characters. Verbatim text (e.g., names from a programming language) may be set in "monospace" type; in plain text this is approximated somewhat ambiguously by surrounding the text in double quotes (which also retain their usual meaning). Bormann & Hoffman Expires 3 April 2021 [Page 7] Internet-Draft CBOR September 2020 2. CBOR Data Models CBOR is explicit about its generic data model, which defines the set of all data items that can be represented in CBOR. Its basic generic data model is extensible by the registration of "simple values" and tags. Applications can then subset the resulting extended generic data model to build their specific data models. Within environments that can represent the data items in the generic data model, generic CBOR encoders and decoders can be implemented (which usually involves defining additional implementation data types for those data items that do not already have a natural representation in the environment). The ability to provide generic encoders and decoders is an explicit design goal of CBOR; however many applications will provide their own application-specific encoders and/or decoders. In the basic (un-extended) generic data model defined in Section 3, a data item is one of: * an integer in the range -2**64..2**64-1 inclusive * a simple value, identified by a number between 0 and 255, but distinct from that number itself * a floating-point value, distinct from an integer, out of the set representable by IEEE 754 binary64 (including non-finites) [IEEE754] * a sequence of zero or more bytes ("byte string") * a sequence of zero or more Unicode code points ("text string") * a sequence of zero or more data items ("array") * a mapping (mathematical function) from zero or more data items ("keys") each to a data item ("values"), ("map") * a tagged data item ("tag"), comprising a tag number (an integer in the range 0..2**64-1) and the tag content (a data item) Note that integer and floating-point values are distinct in this model, even if they have the same numeric value. Bormann & Hoffman Expires 3 April 2021 [Page 8] Internet-Draft CBOR September 2020 Also note that serialization variants are not visible at the generic data model level, including the number of bytes of the encoded floating-point value or the choice of one of the ways in which an integer, the length of a text or byte string, the number of elements in an array or pairs in a map, or a tag number, (collectively "the argument", see Section 3) can be encoded. 2.1. Extended Generic Data Models This basic generic data model comes pre-extended by the registration of a number of simple values and tag numbers right in this document, such as: * "false", "true", "null", and "undefined" (simple values identified by 20..23) * integer and floating-point values with a larger range and precision than the above (tag numbers 2 to 5) * application data types such as a point in time or an RFC 3339 date/time string (tag numbers 1, 0) Further elements of the extended generic data model can be (and have been) defined via the IANA registries created for CBOR. Even if such an extension is unknown to a generic encoder or decoder, data items using that extension can be passed to or from the application by representing them at the interface to the application within the basic generic data model, i.e., as generic simple values or generic tags. In other words, the basic generic data model is stable as defined in this document, while the extended generic data model expands by the registration of new simple values or tag numbers, but never shrinks. While there is a strong expectation that generic encoders and decoders can represent "false", "true", and "null" ("undefined" is intentionally omitted) in the form appropriate for their programming environment, implementation of the data model extensions created by tags is truly optional and a matter of implementation quality. 2.2. Specific Data Models The specific data model for a CBOR-based protocol usually subsets the extended generic data model and assigns application semantics to the data items within this subset and its components. When documenting such specific data models, where it is desired to specify the types of data items, it is preferred to identify the types by the names they have in the generic data model ("negative integer", "array") Bormann & Hoffman Expires 3 April 2021 [Page 9] Internet-Draft CBOR September 2020 instead of by referring to aspects of their CBOR representation ("major type 1", "major type 4"). Specific data models can also specify what values (including values of different types) are equivalent for the purposes of map keys and encoder freedom. For example, in the generic data model, a valid map MAY have both "0" and "0.0" as keys, and an encoder MUST NOT encode "0.0" as an integer (major type 0, Section 3.1). However, if a specific data model declares that floating-point and integer representations of integral values are equivalent, using both map keys "0" and "0.0" in a single map would be considered duplicates, even while encoded as different major types, and so invalid; and an encoder could encode integral-valued floats as integers or vice versa, perhaps to save encoded bytes. 3. Specification of the CBOR Encoding A CBOR data item (Section 2) is encoded to or decoded from a byte string carrying a well-formed encoded data item as described in this section. The encoding is summarized in Table 7 in Appendix B, indexed by the initial byte. An encoder MUST produce only well- formed encoded data items. A decoder MUST NOT return a decoded data item when it encounters input that is not a well-formed encoded CBOR data item (this does not detract from the usefulness of diagnostic and recovery tools that might make available some information from a damaged encoded CBOR data item). The initial byte of each encoded data item contains both information about the major type (the high-order 3 bits, described in Section 3.1) and additional information (the low-order 5 bits). With a few exceptions, the additional information's value describes how to load an unsigned integer "argument": Less than 24: The argument's value is the value of the additional information. 24, 25, 26, or 27: The argument's value is held in the following 1, 2, 4, or 8 bytes, respectively, in network byte order. For major type 7 and additional information value 25, 26, 27, these bytes are not used as an integer argument, but as a floating-point value (see Section 3.3). 28, 29, 30: These values are reserved for future additions to the CBOR format. In the present version of CBOR, the encoded item is not well-formed. 31: No argument value is derived. If the major type is 0, 1, or 6, Bormann & Hoffman Expires 3 April 2021 [Page 10] Internet-Draft CBOR September 2020 the encoded item is not well-formed. For major types 2 to 5, the item's length is indefinite, and for major type 7, the byte does not constitute a data item at all but terminates an indefinite length item; all are described in Section 3.2. The initial byte and any additional bytes consumed to construct the argument are collectively referred to as the "head" of the data item. The meaning of this argument depends on the major type. For example, in major type 0, the argument is the value of the data item itself (and in major type 1 the value of the data item is computed from the argument); in major type 2 and 3 it gives the length of the string data in bytes that follows; and in major types 4 and 5 it is used to determine the number of data items enclosed. If the encoded sequence of bytes ends before the end of a data item, that item is not well-formed. If the encoded sequence of bytes still has bytes remaining after the outermost encoded item is decoded, that encoding is not a single well-formed CBOR item; depending on the application, the decoder may either treat the encoding as not well- formed or just identify the start of the remaining bytes to the application. A CBOR decoder implementation can be based on a jump table with all 256 defined values for the initial byte (Table 7). A decoder in a constrained implementation can instead use the structure of the initial byte and following bytes for more compact code (see Appendix C for a rough impression of how this could look). 3.1. Major Types The following lists the major types and the additional information and other bytes associated with the type. Major type 0: an unsigned integer in the range 0..2**64-1 inclusive. The value of the encoded item is the argument itself. For example, the integer 10 is denoted as the one byte 0b000_01010 (major type 0, additional information 10). The integer 500 would be 0b000_11001 (major type 0, additional information 25) followed by the two bytes 0x01f4, which is 500 in decimal. Major type 1: a negative integer in the range -2**64..-1 inclusive. The value of the item is -1 minus the argument. For example, the integer -500 would be 0b001_11001 (major type 1, additional information 25) followed by the two bytes 0x01f3, which is 499 in decimal. Major type 2: a byte string. The number of bytes in the string is Bormann & Hoffman Expires 3 April 2021 [Page 11] Internet-Draft CBOR September 2020 equal to the argument. For example, a byte string whose length is 5 would have an initial byte of 0b010_00101 (major type 2, additional information 5 for the length), followed by 5 bytes of binary content. A byte string whose length is 500 would have 3 initial bytes of 0b010_11001 (major type 2, additional information 25 to indicate a two-byte length) followed by the two bytes 0x01f4 for a length of 500, followed by 500 bytes of binary content. Major type 3: a text string (Section 2), encoded as UTF-8 ([RFC3629]). The number of bytes in the string is equal to the argument. A string containing an invalid UTF-8 sequence is well- formed but invalid (Section 1.2). This type is provided for systems that need to interpret or display human-readable text, and allows the differentiation between unstructured bytes and text that has a specified repertoire (that of Unicode) and encoding (UTF-8). In contrast to formats such as JSON, the Unicode characters in this type are never escaped. Thus, a newline character (U+000A) is always represented in a string as the byte 0x0a, and never as the bytes 0x5c6e (the characters "\" and "n") nor as 0x5c7530303061 (the characters "\", "u", "0", "0", "0", and "a"). Major type 4: an array of data items. In other formats, arrays are also called lists, sequences, or tuples (a "CBOR sequence" is something slightly different, though [RFC8742]). The argument is the number of data items in the array. Items in an array do not need to all be of the same type. For example, an array that contains 10 items of any type would have an initial byte of 0b100_01010 (major type 4, additional information 10 for the length) followed by the 10 remaining items. Major type 5: a map of pairs of data items. Maps are also called tables, dictionaries, hashes, or objects (in JSON). A map is comprised of pairs of data items, each pair consisting of a key that is immediately followed by a value. The argument is the number of _pairs_ of data items in the map. For example, a map that contains 9 pairs would have an initial byte of 0b101_01001 (major type 5, additional information 9 for the number of pairs) followed by the 18 remaining items. The first item is the first key, the second item is the first value, the third item is the second key, and so on. Because items in a map come in pairs, their total number is always even: A map that contains an odd number of items (no value data present after the last key data item) is not well-formed. A map that has duplicate keys may be well-formed, but it is not valid, and thus it causes indeterminate decoding; see also Section 5.6. Major type 6: a tagged data item ("tag") whose tag number, an Bormann & Hoffman Expires 3 April 2021 [Page 12] Internet-Draft CBOR September 2020 integer in the range 0..2**64-1 inclusive, is the argument and whose enclosed data item ("tag content") is the single encoded data item that follows the head. See Section 3.4. Major type 7: floating-point numbers and simple values, as well as the "break" stop code. See Section 3.3. These eight major types lead to a simple table showing which of the 256 possible values for the initial byte of a data item are used (Table 7). In major types 6 and 7, many of the possible values are reserved for future specification. See Section 9 for more information on these values. Table 1 summarizes the major types defined by CBOR, ignoring the next section for now. The number N in this table stands for the argument, mt for the major type. +====+=======================+=================================+ | mt | Meaning | Content | +====+=======================+=================================+ | 0 | unsigned integer N | - | +----+-----------------------+---------------------------------+ | 1 | negative integer -1-N | - | +----+-----------------------+---------------------------------+ | 2 | byte string | N bytes | +----+-----------------------+---------------------------------+ | 3 | text string | N bytes (UTF-8 text) | +----+-----------------------+---------------------------------+ | 4 | array | N data items (elements) | +----+-----------------------+---------------------------------+ | 5 | map | 2N data items (key/value pairs) | +----+-----------------------+---------------------------------+ | 6 | tag of number N | 1 data item | +----+-----------------------+---------------------------------+ | 7 | simple/float | - | +----+-----------------------+---------------------------------+ Table 1: Overview over the definite-length use of CBOR major types (mt = major type, N = argument) Bormann & Hoffman Expires 3 April 2021 [Page 13] Internet-Draft CBOR September 2020 3.2. Indefinite Lengths for Some Major Types Four CBOR items (arrays, maps, byte strings, and text strings) can be encoded with an indefinite length using additional information value 31. This is useful if the encoding of the item needs to begin before the number of items inside the array or map, or the total length of the string, is known. (The ability to start sending a data item before all of it is known is often referred to as "streaming" within that data item.) Indefinite-length arrays and maps are dealt with differently than indefinite-length strings (byte strings and text strings). 3.2.1. The "break" Stop Code The "break" stop code is encoded with major type 7 and additional information value 31 (0b111_11111). It is not itself a data item: it is just a syntactic feature to close an indefinite-length item. If the "break" stop code appears anywhere where a data item is expected, other than directly inside an indefinite-length string, array, or map -- for example directly inside a definite-length array or map -- the enclosing item is not well-formed. 3.2.2. Indefinite-Length Arrays and Maps Indefinite-length arrays and maps are represented using their major type with the additional information value of 31, followed by an arbitrary-length sequence of zero or more items for an array or key/ value pairs for a map, followed by the "break" stop code (Section 3.2.1). In other words, indefinite-length arrays and maps look identical to other arrays and maps except for beginning with the additional information value of 31 and ending with the "break" stop code. If the "break" stop code appears after a key in a map, in place of that key's value, the map is not well-formed. There is no restriction against nesting indefinite-length array or map items. A "break" only terminates a single item, so nested indefinite-length items need exactly as many "break" stop codes as there are type bytes starting an indefinite-length item. For example, assume an encoder wants to represent the abstract array [1, [2, 3], [4, 5]]. The definite-length encoding would be 0x8301820203820405: Bormann & Hoffman Expires 3 April 2021 [Page 14] Internet-Draft CBOR September 2020 83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5 Indefinite-length encoding could be applied independently to each of the three arrays encoded in this data item, as required, leading to representations such as: 0x9f018202039f0405ffff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break" (inner array) FF -- "break" (outer array) 0x9f01820203820405ff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5 FF -- "break" 0x83018202039f0405ff 83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break" Bormann & Hoffman Expires 3 April 2021 [Page 15] Internet-Draft CBOR September 2020 0x83019f0203ff820405 83 -- Array of length 3 01 -- 1 9F -- Start indefinite-length array 02 -- 2 03 -- 3 FF -- "break" 82 -- Array of length 2 04 -- 4 05 -- 5 An example of an indefinite-length map (that happens to have two key/ value pairs) might be: 0xbf6346756ef563416d7421ff BF -- Start indefinite-length map 63 -- First key, UTF-8 string length 3 46756e -- "Fun" F5 -- First value, true 63 -- Second key, UTF-8 string length 3 416d74 -- "Amt" 21 -- Second value, -2 FF -- "break" 3.2.3. Indefinite-Length Byte Strings and Text Strings Indefinite-length strings are represented by a byte containing the major type for byte string or text string with an additional information value of 31, followed by a series of zero or more strings of the specified type ("chunks") that have definite lengths, and finished by the "break" stop code (Section 3.2.1). The data item represented by the indefinite-length string is the concatenation of the chunks. If no chunks are present, the data item is an empty string of the specified type. Zero-length chunks, while not particularly useful, are permitted. If any item between the indefinite-length string indicator (0b010_11111 or 0b011_11111) and the "break" stop code is not a definite-length string item of the same major type, the string is not well-formed. The design does not allow nesting indefinite-length strings as chunks into indefinite-length strings. If it were allowed, it would require decoder implementations to keep a stack, or at least a count, of nesting levels. It is unnecessary on the encoder side because the inner indefinite-length string would consist of chunks, and these could instead be put directly into the outer indefinite-length string. Bormann & Hoffman Expires 3 April 2021 [Page 16] Internet-Draft CBOR September 2020 If any definite-length text string inside an indefinite-length text string is invalid, the indefinite-length text string is invalid. Note that this implies that the UTF-8 bytes of a single Unicode code point (scalar value) cannot be spread between chunks: a new chunk of a text string can only be started at a code point boundary. For example, assume an encoded data item consisting of the bytes: 0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111 5F -- Start indefinite-length byte string 44 -- Byte string of length 4 aabbccdd -- Bytes content 43 -- Byte string of length 3 eeff99 -- Bytes content FF -- "break" After decoding, this results in a single byte string with seven bytes: 0xaabbccddeeff99. 3.2.4. Summary of indefinite-length use of major types Table 2 summarizes the major types defined by CBOR as used for indefinite length encoding (with additional information set to 31). mt stands for the major type. Bormann & Hoffman Expires 3 April 2021 [Page 17] Internet-Draft CBOR September 2020 +====+===================+==================================+ | mt | Meaning | enclosed up to "break" stop code | +====+===================+==================================+ | 0 | (not well-formed) | - | +----+-------------------+----------------------------------+ | 1 | (not well-formed) | - | +----+-------------------+----------------------------------+ | 2 | byte string | definite-length byte strings | +----+-------------------+----------------------------------+ | 3 | text string | definite-length text strings | +----+-------------------+----------------------------------+ | 4 | array | data items (elements) | +----+-------------------+----------------------------------+ | 5 | map | data items (key/value pairs) | +----+-------------------+----------------------------------+ | 6 | (not well-formed) | - | +----+-------------------+----------------------------------+ | 7 | "break" stop code | - | +----+-------------------+----------------------------------+ Table 2: Overview over the indefinite-length use of CBOR major types (mt = major type, additional information = 31) 3.3. Floating-Point Numbers and Values with No Content Major type 7 is for two types of data: floating-point numbers and "simple values" that do not need any content. Each value of the 5-bit additional information in the initial byte has its own separate meaning, as defined in Table 3. Like the major types for integers, items of this major type do not carry content data; all the information is in the initial bytes (the head). Bormann & Hoffman Expires 3 April 2021 [Page 18] Internet-Draft CBOR September 2020 +=============+===================================================+ | 5-Bit Value | Semantics | +=============+===================================================+ | 0..23 | Simple value (value 0..23) | +-------------+---------------------------------------------------+ | 24 | Simple value (value 32..255 in following byte) | +-------------+---------------------------------------------------+ | 25 | IEEE 754 Half-Precision Float (16 bits follow) | +-------------+---------------------------------------------------+ | 26 | IEEE 754 Single-Precision Float (32 bits follow) | +-------------+---------------------------------------------------+ | 27 | IEEE 754 Double-Precision Float (64 bits follow) | +-------------+---------------------------------------------------+ | 28-30 | Reserved, not well-formed in the present document | +-------------+---------------------------------------------------+ | 31 | "break" stop code for indefinite-length items | | | (Section 3.2.1) | +-------------+---------------------------------------------------+ Table 3: Values for Additional Information in Major Type 7 As with all other major types, the 5-bit value 24 signifies a single- byte extension: it is followed by an additional byte to represent the simple value. (To minimize confusion, only the values 32 to 255 are used.) This maintains the structure of the initial bytes: as for the other major types, the length of these always depends on the additional information in the first byte. Table 4 lists the numeric values assigned and available for simple values. +=========+==============+ | Value | Semantics | +=========+==============+ | 0..19 | (Unassigned) | +---------+--------------+ | 20 | False | +---------+--------------+ | 21 | True | +---------+--------------+ | 22 | Null | +---------+--------------+ | 23 | Undefined | +---------+--------------+ | 24..31 | (Reserved) | +---------+--------------+ | 32..255 | (Unassigned) | +---------+--------------+ Table 4: Simple Values Bormann & Hoffman Expires 3 April 2021 [Page 19] Internet-Draft CBOR September 2020 An encoder MUST NOT issue two-byte sequences that start with 0xf8 (major type 7, additional information 24) and continue with a byte less than 0x20 (32 decimal). Such sequences are not well-formed. (This implies that an encoder cannot encode false, true, null, or undefined in two-byte sequences, and that only the one-byte variants of these are well-formed; more generally speaking, each simple value only has a single representation variant). The 5-bit values of 25, 26, and 27 are for 16-bit, 32-bit, and 64-bit IEEE 754 binary floating-point values [IEEE754]. These floating- point values are encoded in the additional bytes of the appropriate size. (See Appendix D for some information about 16-bit floating- point numbers.) 3.4. Tagging of Items In CBOR, a data item can be enclosed by a tag to give it some additional semantics, as uniquely identified by a "tag number". The tag is major type 6, its argument (Section 3) indicates the tag number, and it contains a single enclosed data item, the "tag content". (If a tag requires further structure to its content, this structure is provided by the enclosed data item.) We use the term "tag" for the entire data item consisting of both a tag number and the tag content: the tag content is the data item that is being tagged. For example, assume that a byte string of length 12 is marked with a tag of number 2 to indicate it is a positive "bignum" (Section 3.4.3). The encoded data item would start with a byte 0b110_00010 (major type 6, additional information 2 for the tag number) followed by the encoded tag content: 0b010_01100 (major type 2, additional information of 12 for the length) followed by the 12 bytes of the bignum. The definition of a tag number describes the additional semantics conveyed for tags with this tag number in the extended generic data model. These semantics may include equivalence of some tagged data items with other data items, including some that can already be represented in the basic generic data model. For instance, 0xc24101, a bignum the tag content of which is the byte string with the single byte 0x01, is equivalent to an integer 1, which could also be encoded for instance as 0x01, 0x1801, or 0x190001. The tag definition may include the definition of a preferred serialization (Section 4.1) that is recommended for generic encoders; this may prefer basic generic data model representations over ones that employ a tag. Bormann & Hoffman Expires 3 April 2021 [Page 20] Internet-Draft CBOR September 2020 The tag definition usually restricts what kinds of nested data item or items are valid for such tags. Tag definitions may restrict their content to a very specific syntactic structure, as the tags defined in this document do, or they may aim at a more semantically defined definition of their content, as for instance tags 40 and 1040 do [RFC8746]: These accept a number of different ways of representing arrays. As a matter of convention, many tags do not accept null or undefined values as tag content; instead, the expectation is that a null or undefined value can be used in place of the entire tag; Section 3.4.2 provides some further considerations for one specific tag about the handling of this convention in application protocols and in mapping to platform types. Decoders do not need to understand tags of every tag number, and tags may be of little value in applications where the implementation creating a particular CBOR data item and the implementation decoding that stream know the semantic meaning of each item in the data flow. Their primary purpose in this specification is to define common data types such as dates. A secondary purpose is to provide conversion hints when it is foreseen that the CBOR data item needs to be translated into a different format, requiring hints about the content of items. Understanding the semantics of tags is optional for a decoder; it can simply present both the tag number and the tag content to the application, without interpreting the additional semantics of the tag. A tag applies semantics to the data item it encloses. Tags can nest: If tag A encloses tag B, which encloses data item C, tag A applies to the result of applying tag B on data item C. IANA maintains a registry of tag numbers as described in Section 9.2. Table 5 provides a list of tag numbers that were defined in [RFC7049], with definitions in the rest of this section. (Tag number 35 was also defined in [RFC7049]; a discussion of this tag number follows in Section 3.4.5.3.) Note that many other tag numbers have been defined since the publication of [RFC7049]; see the registry described at Section 9.2 for the complete list. Bormann & Hoffman Expires 3 April 2021 [Page 21] Internet-Draft CBOR September 2020 +============+=============+==================================+ | Tag Number | Data Item | Tag Content Semantics | +============+=============+==================================+ | 0 | text string | Standard date/time string; see | | | | Section 3.4.1 | +------------+-------------+----------------------------------+ | 1 | integer or | Epoch-based date/time; see | | | float | Section 3.4.2 | +------------+-------------+----------------------------------+ | 2 | byte string | Positive bignum; see | | | | Section 3.4.3 | +------------+-------------+----------------------------------+ | 3 | byte string | Negative bignum; see | | | | Section 3.4.3 | +------------+-------------+----------------------------------+ | 4 | array | Decimal fraction; see | | | | Section 3.4.4 | +------------+-------------+----------------------------------+ | 5 | array | Bigfloat; see Section 3.4.4 | +------------+-------------+----------------------------------+ | 21 | (any) | Expected conversion to base64url | | | | encoding; see Section 3.4.5.2 | +------------+-------------+----------------------------------+ | 22 | (any) | Expected conversion to base64 | | | | encoding; see Section 3.4.5.2 | +------------+-------------+----------------------------------+ | 23 | (any) | Expected conversion to base16 | | | | encoding; see Section 3.4.5.2 | +------------+-------------+----------------------------------+ | 24 | byte string | Encoded CBOR data item; see | | | | Section 3.4.5.1 | +------------+-------------+----------------------------------+ | 32 | text string | URI; see Section 3.4.5.3 | +------------+-------------+----------------------------------+ | 33 | text string | base64url; see Section 3.4.5.3 | +------------+-------------+----------------------------------+ | 34 | text string | base64; see Section 3.4.5.3 | +------------+-------------+----------------------------------+ | 36 | text string | MIME message; see | | | | Section 3.4.5.3 | +------------+-------------+----------------------------------+ | 55799 | (any) | Self-described CBOR; see | | | | Section 3.4.6 | +------------+-------------+----------------------------------+ Table 5: Tag numbers defined in RFC 7049 Bormann & Hoffman Expires 3 April 2021 [Page 22] Internet-Draft CBOR September 2020 Conceptually, tags are interpreted in the generic data model, not at (de-)serialization time. A small number of tags (at this time, tag number 25 and tag number 29 [IANA.cbor-tags]) have been registered with semantics that may require processing at (de-)serialization time: The decoder needs to be aware and the encoder needs to be in control of the exact sequence in which data items are encoded into the CBOR data item. This means these tags cannot be implemented on top of an arbitrary generic CBOR encoder/decoder (which might not reflect the serialization order for entries in a map at the data model level and vice versa); their implementation therefore typically needs to be integrated into the generic encoder/decoder. The definition of new tags with this property is NOT RECOMMENDED. IANA allocated tag numbers 65535, 4294967295, and 18446744073709551615 (binary all-ones in 16-bit, 32-bit, and 64-bit). These can be used as a convenience for implementers that want a single integer data structure to indicate either that a specific tag is present, or the absence of a tag. That allocation is described in Section 10 of [I-D.bormann-cbor-notable-tags]. These tags are not intended to occur in actual CBOR data items; implementations MAY flag such an occurrence as an error. Protocols using tag numbers 0 and 1 extend the generic data model (Section 2) with data items representing points in time; tag numbers 2 and 3, with arbitrarily sized integers; and tag numbers 4 and 5, with floating-point values of arbitrary size and precision. 3.4.1. Standard Date/Time String Tag number 0 contains a text string in the standard format described by the "date-time" production in [RFC3339], as refined by Section 3.3 of [RFC4287], representing the point in time described there. A nested item of another type or a text string that doesn't match the [RFC4287] format is invalid. 3.4.2. Epoch-based Date/Time Tag number 1 contains a numerical value counting the number of seconds from 1970-01-01T00:00Z in UTC time to the represented point in civil time. The tag content MUST be an unsigned or negative integer (major types 0 and 1), or a floating-point number (major type 7 with additional information 25, 26, or 27). Other contained types are invalid. Non-negative values (major type 0 and non-negative floating-point numbers) stand for time values on or after 1970-01-01T00:00Z UTC and are interpreted according to POSIX [TIME_T]. (POSIX time is also Bormann & Hoffman Expires 3 April 2021 [Page 23] Internet-Draft CBOR September 2020 known as "UNIX Epoch time".) Leap seconds are handled specially by POSIX time and this results in a 1 second discontinuity several times per decade. Note that applications that require the expression of times beyond early 2106 cannot leave out support of 64-bit integers for the tag content. Negative values (major type 1 and negative floating-point numbers) are interpreted as determined by the application requirements as there is no universal standard for UTC count-of-seconds time before 1970-01-01T00:00Z (this is particularly true for points in time that precede discontinuities in national calendars). The same applies to non-finite values. To indicate fractional seconds, floating-point values can be used within tag number 1 instead of integer values. Note that this generally requires binary64 support, as binary16 and binary32 provide non-zero fractions of seconds only for a short period of time around early 1970. An application that requires tag number 1 support may restrict the tag content to be an integer (or a floating-point value) only. Note that platform types for date/time may include null or undefined values, which may also be desirable at an application protocol level. While emitting tag number 1 values with non-finite tag content values (e.g., with NaN for undefined date/time values or with Infinite for an expiry date that is not set) may seem an obvious way to handle this, using untagged null or undefined avoids the use of non-finites and results in a shorter encoding. Application protocol designers are encouraged to consider these cases and include clear guidelines for handling them. 3.4.3. Bignums Protocols using tag numbers 2 and 3 extend the generic data model (Section 2) with "bignums" representing arbitrarily sized integers. In the basic generic data model, bignum values are not equal to integers from the same model, but the extended generic data model created by this tag definition defines equivalence based on numeric value, and preferred serialization (Section 4.1) never makes use of bignums that also can be expressed as basic integers (see below). Bignums are encoded as a byte string data item, which is interpreted as an unsigned integer n in network byte order. Contained items of other types are invalid. For tag number 2, the value of the bignum is n. For tag number 3, the value of the bignum is -1 - n. The preferred serialization of the byte string is to leave out any leading zeroes (note that this means the preferred serialization for n = 0 is the empty byte string, but see below). Decoders that Bormann & Hoffman Expires 3 April 2021 [Page 24] Internet-Draft CBOR September 2020 understand these tags MUST be able to decode bignums that do have leading zeroes. The preferred serialization of an integer that can be represented using major type 0 or 1 is to encode it this way instead of as a bignum (which means that the empty string never occurs in a bignum when using preferred serialization). Note that this means the non-preferred choice of a bignum representation instead of a basic integer for encoding a number is not intended to have application semantics (just as the choice of a longer basic integer representation than needed, such as 0x1800 for 0x00 does not). For example, the number 18446744073709551616 (2**64) is represented as 0b110_00010 (major type 6, tag number 2), followed by 0b010_01001 (major type 2, length 9), followed by 0x010000000000000000 (one byte 0x01 and eight bytes 0x00). In hexadecimal: C2 -- Tag 2 49 -- Byte string of length 9 010000000000000000 -- Bytes content 3.4.4. Decimal Fractions and Bigfloats Protocols using tag number 4 extend the generic data model with data items representing arbitrary-length decimal fractions of the form m*(10**e). Protocols using tag number 5 extend the generic data model with data items representing arbitrary-length binary fractions of the form m*(2**e). As with bignums, values of different types are not equal in the generic data model. Decimal fractions combine an integer mantissa with a base-10 scaling factor. They are most useful if an application needs the exact representation of a decimal fraction such as 1.1 because there is no exact representation for many decimal fractions in binary floating- point representations. "Bigfloats" combine an integer mantissa with a base-2 scaling factor. They are binary floating-point values that can exceed the range or the precision of the three IEEE 754 formats supported by CBOR (Section 3.3). Bigfloats may also be used by constrained applications that need some basic binary floating-point capability without the need for supporting IEEE 754. Bormann & Hoffman Expires 3 April 2021 [Page 25] Internet-Draft CBOR September 2020 A decimal fraction or a bigfloat is represented as a tagged array that contains exactly two integer numbers: an exponent e and a mantissa m. Decimal fractions (tag number 4) use base-10 exponents; the value of a decimal fraction data item is m*(10**e). Bigfloats (tag number 5) use base-2 exponents; the value of a bigfloat data item is m*(2**e). The exponent e MUST be represented in an integer of major type 0 or 1, while the mantissa can also be a bignum (Section 3.4.3). Contained items with other structures are invalid. An example of a decimal fraction is that the number 273.15 could be represented as 0b110_00100 (major type 6 for tag, additional information 4 for the tag number), followed by 0b100_00010 (major type 4 for the array, additional information 2 for the length of the array), followed by 0b001_00001 (major type 1 for the first integer, additional information 1 for the value of -2), followed by 0b000_11001 (major type 0 for the second integer, additional information 25 for a two-byte value), followed by 0b0110101010110011 (27315 in two bytes). In hexadecimal: C4 -- Tag 4 82 -- Array of length 2 21 -- -2 19 6ab3 -- 27315 An example of a bigfloat is that the number 1.5 could be represented as 0b110_00101 (major type 6 for tag, additional information 5 for the tag number), followed by 0b100_00010 (major type 4 for the array, additional information 2 for the length of the array), followed by 0b001_00000 (major type 1 for the first integer, additional information 0 for the value of -1), followed by 0b000_00011 (major type 0 for the second integer, additional information 3 for the value of 3). In hexadecimal: C5 -- Tag 5 82 -- Array of length 2 20 -- -1 03 -- 3 Decimal fractions and bigfloats provide no representation of Infinity, -Infinity, or NaN; if these are needed in place of a decimal fraction or bigfloat, the IEEE 754 half-precision representations from Section 3.3 can be used. 3.4.5. Content Hints The tags in this section are for content hints that might be used by generic CBOR processors. These content hints do not extend the generic data model. Bormann & Hoffman Expires 3 April 2021 [Page 26] Internet-Draft CBOR September 2020 3.4.5.1. Encoded CBOR Data Item Sometimes it is beneficial to carry an embedded CBOR data item that is not meant to be decoded immediately at the time the enclosing data item is being decoded. Tag number 24 (CBOR data item) can be used to tag the embedded byte string as a single data item encoded in CBOR format. Contained items that aren't byte strings are invalid. A contained byte string is valid if it encodes a well-formed CBOR data item; validity checking of the decoded CBOR item is not required for tag validity (but could be offered by a generic decoder as a special option). 3.4.5.2. Expected Later Encoding for CBOR-to-JSON Converters Tag numbers 21 to 23 indicate that a byte string might require a specific encoding when interoperating with a text-based representation. These tags are useful when an encoder knows that the byte string data it is writing is likely to be later converted to a particular JSON-based usage. That usage specifies that some strings are encoded as base64, base64url, and so on. The encoder uses byte strings instead of doing the encoding itself to reduce the message size, to reduce the code size of the encoder, or both. The encoder does not know whether or not the converter will be generic, and therefore wants to say what it believes is the proper way to convert binary strings to JSON. The data item tagged can be a byte string or any other data item. In the latter case, the tag applies to all of the byte string data items contained in the data item, except for those contained in a nested data item tagged with an expected conversion. These three tag numbers suggest conversions to three of the base data encodings defined in [RFC4648]. Tag number 21 suggests conversion to base64url encoding (Section 5 of RFC 4648), where padding is not used (see Section 3.2 of RFC 4648); that is, all trailing equals signs ("=") are removed from the encoded string. Tag number 22 suggests conversion to classical base64 encoding (Section 4 of RFC 4648), with padding as defined in RFC 4648. For both base64url and base64, padding bits are set to zero (see Section 3.5 of RFC 4648), and the conversion to alternate encoding is performed on the contents of the byte string (that is, without adding any line breaks, whitespace, or other additional characters). Tag number 23 suggests conversion to base16 (hex) encoding, with uppercase alphabetics (see Section 8 of RFC 4648). Note that, for all three tag numbers, the encoding of the empty byte string is the empty text string. Bormann & Hoffman Expires 3 April 2021 [Page 27] Internet-Draft CBOR September 2020 3.4.5.3. Encoded Text Some text strings hold data that have formats widely used on the Internet, and sometimes those formats can be validated and presented to the application in appropriate form by the decoder. There are tags for some of these formats. * Tag number 32 is for URIs, as defined in [RFC3986]. If the text string doesn't match the "URI-reference" production, the string is invalid. * Tag numbers 33 and 34 are for base64url- and base64-encoded text strings, respectively, as defined in [RFC4648]. If any of: - the encoded text string contains non-alphabet characters or only 1 alphabet character in the last block of 4 (where alphabet is defined by Section 5 of [RFC4648] for tag number 33 and Section 4 of [RFC4648] for tag number 34), or - the padding bits in a 2- or 3-character block are not 0, or - the base64 encoding has the wrong number of padding characters, or - the base64url encoding has padding characters, the string is invalid. * Tag number 36 is for MIME messages (including all headers), as defined in [RFC2045]. A text string that isn't a valid MIME message is invalid. (For this tag, validity checking may be particularly onerous for a generic decoder and might therefore not be offered. Note that many MIME messages are general binary data and can therefore not be represented in a text string; [IANA.cbor-tags] lists a registration for tag number 257 that is similar to tag number 36 but uses a byte string as its tag content.) Note that tag numbers 33 and 34 differ from 21 and 22 in that the data is transported in base-encoded form for the former and in raw byte string form for the latter. [RFC7049] also defined a tag number 35, for regular expressions that are in Perl Compatible Regular Expressions (PCRE/PCRE2) form [PCRE] or in JavaScript regular expression syntax [ECMA262]. The state of the art in these regular expression specifications has since advanced and is continually advancing, so the present specification does not attempt to update the references to a snapshot that is current at the Bormann & Hoffman Expires 3 April 2021 [Page 28] Internet-Draft CBOR September 2020 time of writing. Instead, this tag remains available (as registered in [RFC7049]) for applications that specify the particular regular expression variant they use out-of-band (possibly by limiting the usage to a defined common subset of both PCRE and ECMA262). As the present specification clarifies tag validity beyond [RFC7049], we note that due to the open way the tag was defined in [RFC7049], any contained string value needs to be valid at the CBOR tag level (but may then not be "expected" at the application level). 3.4.6. Self-Described CBOR In many applications, it will be clear from the context that CBOR is being employed for encoding a data item. For instance, a specific protocol might specify the use of CBOR, or a media type is indicated that specifies its use. However, there may be applications where such context information is not available, such as when CBOR data is stored in a file that does not have disambiguating metadata. Here, it may help to have some distinguishing characteristics for the data itself. Tag number 55799 is defined for this purpose, specifically for use at the start of a stored encoded CBOR data item as specified by an application. It does not impart any special semantics on the data item that it encloses; that is, the semantics of the tag content enclosed in tag number 55799 is exactly identical to the semantics of the tag content itself. The serialization of this tag's head is 0xd9d9f7, which does not appear to be in use as a distinguishing mark for any frequently used file types. In particular, 0xd9d9f7 is not a valid start of a Unicode text in any Unicode encoding if it is followed by a valid CBOR data item. For instance, a decoder might be able to decode both CBOR and JSON. Such a decoder would need to mechanically distinguish the two formats. An easy way for an encoder to help the decoder would be to tag the entire CBOR item with tag number 55799, the serialization of which will never be found at the beginning of a JSON text. 4. Serialization Considerations 4.1. Preferred Serialization For some values at the data model level, CBOR provides multiple serializations. For many applications, it is desirable that an encoder always chooses a preferred serialization (preferred encoding); however, the present specification does not put the burden of enforcing this preference on either encoder or decoder. Bormann & Hoffman Expires 3 April 2021 [Page 29] Internet-Draft CBOR September 2020 Some constrained decoders may be limited in their ability to decode non-preferred serializations: For example, if only integers below 1_000_000_000 (one billion) are expected in an application, the decoder may leave out the code that would be needed to decode 64-bit arguments in integers. An encoder that always uses preferred serialization ("preferred encoder") interoperates with this decoder for the numbers that can occur in this application. More generally speaking, it therefore can be said that a preferred encoder is more universally interoperable (and also less wasteful) than one that, say, always uses 64-bit integers. Similarly, a constrained encoder may be limited in the variety of representation variants it supports in such a way that it does not emit preferred serializations ("variant encoder"): Say, it could be designed to always use the 32-bit variant for an integer that it encodes even if a short representation is available (again, assuming that there is no application need for integers that can only be represented with the 64-bit variant). A decoder that does not rely on only ever receiving preferred serializations ("variation-tolerant decoder") can therefore be said to be more universally interoperable (it might very well optimize for the case of receiving preferred serializations, though). Full implementations of CBOR decoders are by definition variation-tolerant; the distinction is only relevant if a constrained implementation of a CBOR decoder meets a variant encoder. The preferred serialization always uses the shortest form of representing the argument (Section 3); it also uses the shortest floating-point encoding that preserves the value being encoded. The preferred serialization for a floating-point value is the shortest floating-point encoding that preserves its value, e.g., 0xf94580 for the number 5.5, and 0xfa45ad9c00 for the number 5555.5. For NaN values, a shorter encoding is preferred if zero-padding the shorter significand towards the right reconstitutes the original NaN value (for many applications, the single NaN encoding 0xf97e00 will suffice). Definite length encoding is preferred whenever the length is known at the time the serialization of the item starts. Bormann & Hoffman Expires 3 April 2021 [Page 30] Internet-Draft CBOR September 2020 4.2. Deterministically Encoded CBOR Some protocols may want encoders to only emit CBOR in a particular deterministic format; those protocols might also have the decoders check that their input is in that deterministic format. Those protocols are free to define what they mean by a "deterministic format" and what encoders and decoders are expected to do. This section defines a set of restrictions that can serve as the base of such a deterministic format. 4.2.1. Core Deterministic Encoding Requirements A CBOR encoding satisfies the "core deterministic encoding requirements" if it satisfies the following restrictions: * Preferred serialization MUST be used. In particular, this means that arguments (see Section 3) for integers, lengths in major types 2 through 5, and tags MUST be as short as possible, for instance: - 0 to 23 and -1 to -24 MUST be expressed in the same byte as the major type; - 24 to 255 and -25 to -256 MUST be expressed only with an additional uint8_t; - 256 to 65535 and -257 to -65536 MUST be expressed only with an additional uint16_t; - 65536 to 4294967295 and -65537 to -4294967296 MUST be expressed only with an additional uint32_t. Floating-point values also MUST use the shortest form that preserves the value, e.g. 1.5 is encoded as 0xf93e00 (binary16) and 1000000.5 as 0xfa49742408 (binary32). (One implementation of this is to have all floats start as a 64-bit float, then do a test conversion to a 32-bit float; if the result is the same numeric value, use the shorter form and repeat the process with a test conversion to a 16-bit float. This also works to select 16-bit float for positive and negative Infinity as well.) * Indefinite-length items MUST NOT appear. They can be encoded as definite-length items instead. * The keys in every map MUST be sorted in the bytewise lexicographic order of their deterministic encodings. For example, the following keys are sorted correctly: Bormann & Hoffman Expires 3 April 2021 [Page 31] Internet-Draft CBOR September 2020 1. 10, encoded as 0x0a. 2. 100, encoded as 0x1864. 3. -1, encoded as 0x20. 4. "z", encoded as 0x617a. 5. "aa", encoded as 0x626161. 6. [100], encoded as 0x811864. 7. [-1], encoded as 0x8120. 8. false, encoded as 0xf4. (Implementation note: the self-delimiting nature of the CBOR encoding means that there are no two well-formed CBOR encoded data items where one is a prefix of the other. The bytewise lexicographic comparison of deterministic encodings of different map keys therefore always ends in a position where the byte differs between the keys, before the end of a key is reached.) 4.2.2. Additional Deterministic Encoding Considerations CBOR tags present additional considerations for deterministic encoding. If a CBOR-based protocol were to provide the same semantics for the presence and absence of a specific tag (e.g., by allowing both tag 1 data items and raw numbers in a date/time position, treating the latter as if they were tagged), the deterministic format would not allow the presence of the tag, based on the "shortest form" principle. For example, a protocol might give encoders the choice of representing a URL as either a text string or, using Section 3.4.5.3, tag number 32 containing a text string. This protocol's deterministic encoding needs to either require that the tag is present or require that it is absent, not allow either one. In a protocol that does require tags in certain places to obtain specific semantics, the tag needs to appear in the deterministic format as well. Deterministic encoding considerations also apply to the content of tags. If a protocol includes a field that can express integers with an absolute value of 2^64 or larger using tag numbers 2 or 3 (Section 3.4.3), the protocol's deterministic encoding needs to specify whether smaller integers are also expressed using these tags or using major types 0 and 1. Preferred serialization uses the latter choice, which is therefore recommended. Bormann & Hoffman Expires 3 April 2021 [Page 32] Internet-Draft CBOR September 2020 Protocols that include floating-point values, whether represented using basic floating-point values (Section 3.3) or using tags (or both), may need to define extra requirements on their deterministic encodings, such as: * Although IEEE floating-point values can represent both positive and negative zero as distinct values, the application might not distinguish these and might decide to represent all zero values with a positive sign, disallowing negative zero. (The application may also want to restrict the precision of floating-point values in such a way that there is never a need to represent 64-bit -- or even 32-bit -- floating-point values.) * If a protocol includes a field that can express floating-point values, with a specific data model that declares integer and floating-point values to be interchangeable, the protocol's deterministic encoding needs to specify whether (for example) the integer 1.0 is encoded as 0x01 (unsigned integer), 0xf93c00 (binary16), 0xfa3f800000 (binary32), or 0xfb3ff0000000000000 (binary64). Example rules for this are: 1. Encode integral values that fit in 64 bits as values from major types 0 and 1, and other values as the preferred (smallest of 16-, 32-, or 64-bit) floating-point representation that accurately represents the value, 2. Encode all values as the preferred floating-point representation that accurately represents the value, even for integral values, or 3. Encode all values as 64-bit floating-point representations. Rule 1 straddles the boundaries between integers and floating- point values, and Rule 3 does not use preferred serialization, so Rule 2 may be a good choice in many cases. * If NaN is an allowed value and there is no intent to support NaN payloads or signaling NaNs, the protocol needs to pick a single representation, typically 0xf97e00. If that simple choice is not possible, specific attention will be needed for NaN handling. * Subnormal numbers (nonzero numbers with the lowest possible exponent of a given IEEE 754 number format) may be flushed to zero outputs or be treated as zero inputs in some floating-point implementations. A protocol's deterministic encoding may want to specifically accommodate such implementations while creating an onus on other implementations, by excluding subnormal numbers from interchange, interchanging zero instead. Bormann & Hoffman Expires 3 April 2021 [Page 33] Internet-Draft CBOR September 2020 * The same number can be represented by different decimal fractions, by different bigfloats, and by different forms under other tags that may be defined to express numeric values. Depending on the implementation, it may not always be practical to determine whether any of these forms (or forms in the basic generic data model) are equivalent. An application protocol that presents choices of this kind for the representation format of numbers needs to be explicit in how the formats are to be chosen for deterministic encoding. 4.2.3. Length-first Map Key Ordering The core deterministic encoding requirements (Section 4.2.1) sort map keys in a different order from the one suggested by Section 3.9 of [RFC7049] (called "Canonical CBOR" there). Protocols that need to be compatible with [RFC7049]'s order can instead be specified in terms of this specification's "length-first core deterministic encoding requirements": A CBOR encoding satisfies the "length-first core deterministic encoding requirements" if it satisfies the core deterministic encoding requirements except that the keys in every map MUST be sorted such that: 1. If two keys have different lengths, the shorter one sorts earlier; 2. If two keys have the same length, the one with the lower value in (byte-wise) lexical order sorts earlier. For example, under the length-first core deterministic encoding requirements, the following keys are sorted correctly: 1. 10, encoded as 0x0a. 2. -1, encoded as 0x20. 3. false, encoded as 0xf4. 4. 100, encoded as 0x1864. 5. "z", encoded as 0x617a. 6. [-1], encoded as 0x8120. 7. "aa", encoded as 0x626161. 8. [100], encoded as 0x811864. Bormann & Hoffman Expires 3 April 2021 [Page 34] Internet-Draft CBOR September 2020 (Although [RFC7049] used the term "Canonical CBOR" for its form of requirements on deterministic encoding, this document avoids this term because "canonicalization" is often associated with specific uses of deterministic encoding only. The terms are essentially interchangeable, however, and the set of core requirements in this document could also be called "Canonical CBOR", while the length- first-ordered version of that could be called "Old Canonical CBOR".) 5. Creating CBOR-Based Protocols Data formats such as CBOR are often used in environments where there is no format negotiation. A specific design goal of CBOR is to not need any included or assumed schema: a decoder can take a CBOR item and decode it with no other knowledge. Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array whose first value is a UTF-8 string, second value is an integer, and subsequent values are zero or more floating-point numbers" or "the item is a map that has byte strings for keys and contains a pair whose key is 0xab01". CBOR-based protocols MUST specify how their decoders handle invalid and other unexpected data. CBOR-based protocols MAY specify that they treat arbitrary valid data as unexpected. Encoders for CBOR- based protocols MUST produce only valid items, that is, the protocol cannot be designed to make use of invalid items. An encoder can be capable of encoding as many or as few types of values as is required by the protocol in which it is used; a decoder can be capable of understanding as many or as few types of values as is required by the protocols in which it is used. This lack of restrictions allows CBOR to be used in extremely constrained environments. The rest of this section discusses some considerations in creating CBOR-based protocols. With few exceptions, it is advisory only and explicitly excludes any language from BCP 14 other than words that could be interpreted as "MAY" in the sense of BCP 14. The exceptions aim at facilitating interoperability of CBOR-based protocols while making use of a wide variety of both generic and application-specific encoders and decoders. 5.1. CBOR in Streaming Applications In a streaming application, a data stream may be composed of a sequence of CBOR data items concatenated back-to-back. In such an environment, the decoder immediately begins decoding a new data item if data is found after the end of a previous data item. Bormann & Hoffman Expires 3 April 2021 [Page 35] Internet-Draft CBOR September 2020 Not all of the bytes making up a data item may be immediately available to the decoder; some decoders will buffer additional data until a complete data item can be presented to the application. Other decoders can present partial information about a top-level data item to an application, such as the nested data items that could already be decoded, or even parts of a byte string that hasn't completely arrived yet. Such an application also MUST have a matching streaming security mechanism, where the desired protection is available for incremental data presented to the application. Note that some applications and protocols will not want to use indefinite-length encoding. Using indefinite-length encoding allows an encoder to not need to marshal all the data for counting, but it requires a decoder to allocate increasing amounts of memory while waiting for the end of the item. This might be fine for some applications but not others. 5.2. Generic Encoders and Decoders A generic CBOR decoder can decode all well-formed encoded CBOR data items and present the data items to an application. See Appendix C. (The diagnostic notation, Section 8, may be used to present well- formed CBOR values to humans.) Generic CBOR encoders provide an application interface that allows the application to specify any well-formed value to be encoded as a CBOR data item, including simple values and tags unknown to the encoder. Even though CBOR attempts to minimize these cases, not all well- formed CBOR data is valid: for example, the encoded text string "0x62c0ae" does not contain valid UTF-8 (because [RFC3629] requires always using the shortest form) and so is not a valid CBOR item. Also, specific tags may make semantic constraints that may be violated, for instance by a bignum tag enclosing another tag, or by an instance of tag number 0 containing a byte string, or containing a text string with contents that do not match [RFC3339]'s "date-time" production. There is no requirement that generic encoders and decoders make unnatural choices for their application interface to enable the processing of invalid data. Generic encoders and decoders are expected to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written (Section 5.4). Bormann & Hoffman Expires 3 April 2021 [Page 36] Internet-Draft CBOR September 2020 5.3. Validity of Items A well-formed but invalid CBOR data item (Section 1.2) presents a problem with interpreting the data encoded in it in the CBOR data model. A CBOR-based protocol could be specified in several layers, in which the lower layers don't process the semantics of some of the CBOR data they forward. These layers can't notice any validity errors in data they don't process and MUST forward that data as-is. The first layer that does process the semantics of an invalid CBOR item MUST take one of two choices: 1. Replace the problematic item with an error marker and continue with the next item, or 2. Issue an error and stop processing altogether. A CBOR-based protocol MUST specify which of these options its decoders take, for each kind of invalid item they might encounter. Such problems might occur at the basic validity level of CBOR or in the context of tags (tag validity). 5.3.1. Basic validity Two kinds of validity errors can occur in the basic generic data model: Duplicate keys in a map: Generic decoders (Section 5.2) make data available to applications using the native CBOR data model. That data model includes maps (key-value mappings with unique keys), not multimaps (key-value mappings where multiple entries can have the same key). Thus, a generic decoder that gets a CBOR map item that has duplicate keys will decode to a map with only one instance of that key, or it might stop processing altogether. On the other hand, a "streaming decoder" may not even be able to notice. See Section 5.6 for more discussion of keys in maps. Invalid UTF-8 string: A decoder might or might not want to verify that the sequence of bytes in a UTF-8 string (major type 3) is actually valid UTF-8 and react appropriately. 5.3.2. Tag validity Two additional kinds of validity errors are introduced by adding tags to the basic generic data model: Inadmissible type for tag content: Tag numbers (Section 3.4) specify Bormann & Hoffman Expires 3 April 2021 [Page 37] Internet-Draft CBOR September 2020 what type of data item is supposed to be used as their tag content; for example, the tag numbers for positive or negative bignums are supposed to be put on byte strings. A decoder that decodes the tagged data item into a native representation (a native big integer in this example) is expected to check the type of the data item being tagged. Even decoders that don't have such native representations available in their environment may perform the check on those tags known to them and react appropriately. Inadmissible value for tag content: The type of data item may be admissible for a tag's content, but the specific value may not be; e.g., a value of "yesterday" is not acceptable for the content of tag 0, even though it properly is a text string. A decoder that normally ingests such tags into equivalent platform types might present this tag to the application in a similar way to how it would present a tag with an unknown tag number (Section 5.4). 5.4. Validity and Evolution A decoder with validity checking will expend the effort to reliably detect data items with validity errors. For example, such a decoder needs to have an API that reports an error (and does not return data) for a CBOR data item that contains any of the validity errors listed in the previous subsection. The set of tags defined in the tag registry (Section 9.2), as well as the set of simple values defined in the simple values registry (Section 9.1), can grow at any time beyond the set understood by a generic decoder. A validity-checking decoder can do one of two things when it encounters such a case that it does not recognize: * It can report an error (and not return data). Note that treating this case as an error can cause ossification, and is thus not encouraged. This error is not a validity error per se. This kind of error is more likely to be raised by a decoder that would be performing validity checking if this were a known case. * It can emit the unknown item (type, value, and, for tags, the decoded tagged data item) to the application calling the decoder, with an indication that the decoder did not recognize that tag number or simple value. Bormann & Hoffman Expires 3 April 2021 [Page 38] Internet-Draft CBOR September 2020 The latter approach, which is also appropriate for decoders that do not support validity checking, provides forward compatibility with newly registered tags and simple values without the requirement to update the encoder at the same time as the calling application. (For this, the API for the decoder needs to have a way to mark unknown items so that the calling application can handle them in a manner appropriate for the program.) Since some of the processing needed for validity checking may have an appreciable cost (in particular with duplicate detection for maps), support of validity checking is not a requirement placed on all CBOR decoders. Some encoders will rely on their applications to provide input data in such a way that valid CBOR results from the encoder. A generic encoder may also want to provide a validity-checking mode where it reliably limits its output to valid CBOR, independent of whether or not its application is indeed providing API-conformant data. 5.5. Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the basic JavaScript number system treats all numbers as floating-point values, which may result in silent loss of precision in decoding integers with more than 53 significant bits. Another example is that, since CBOR keeps the sign bit for its integer representation in the major type, it has one bit more for signed numbers of a certain length (e.g., -2**64..2**64-1 for 1+8-byte integers) than the typical platform signed integer representation of the same length (-2**63..2**63-1 for 8-byte int64_t). A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. A CBOR-based protocol that includes floating-point numbers can restrict which of the three formats (half-precision, single- precision, and double-precision) are to be supported. For an integer-only application, a protocol may want to completely exclude the use of floating-point values. A CBOR-based protocol designed for compactness may want to exclude specific integer encodings that are longer than necessary for the application, such as to save the need to implement 64-bit integers. There is an expectation that encoders will use the most compact integer representation that can represent a given value. However, a compact application that does not require deterministic encoding should accept values that use a longer-than-needed encoding (such as Bormann & Hoffman Expires 3 April 2021 [Page 39] Internet-Draft CBOR September 2020 encoding "0" as 0b000_11001 followed by two bytes of 0x00) as long as the application can decode an integer of the given size. Similar considerations apply to floating-point values; decoding both preferred serializations and longer-than-needed ones is recommended. CBOR-based protocols for constrained applications that provide a choice between representing a specific number as an integer and as a decimal fraction or bigfloat (such as when the exponent is small and non-negative), might express a quality-of-implementation expectation that the integer representation is used directly. 5.6. Specifying Keys for Maps The encoding and decoding applications need to agree on what types of keys are going to be used in maps. In applications that need to interwork with JSON-based applications, conversion is simplified by limiting keys to text strings only; otherwise, there has to be a specified mapping from the other CBOR types to text strings, and this often leads to implementation errors. In applications where keys are numeric in nature and numeric ordering of keys is important to the application, directly using the numbers for the keys is useful. If multiple types of keys are to be used, consideration should be given to how these types would be represented in the specific programming environments that are to be used. For example, in JavaScript Maps [ECMA262], a key of integer 1 cannot be distinguished from a key of floating-point 1.0. This means that, if integer keys are used, the protocol needs to avoid use of floating-point keys the values of which happen to be integer numbers in the same map. Decoders that deliver data items nested within a CBOR data item immediately on decoding them ("streaming decoders") often do not keep the state that is necessary to ascertain uniqueness of a key in a map. Similarly, an encoder that can start encoding data items before the enclosing data item is completely available ("streaming encoder") may want to reduce its overhead significantly by relying on its data source to maintain uniqueness. A CBOR-based protocol MUST define what to do when a receiving application does see multiple identical keys in a map. The resulting rule in the protocol MUST respect the CBOR data model: it cannot prescribe a specific handling of the entries with the identical keys, except that it might have a rule that having identical keys in a map indicates a malformed map and that the decoder has to stop with an error. When processing maps that exhibit entries with duplicate keys, a generic decoder might do one of the following: Bormann & Hoffman Expires 3 April 2021 [Page 40] Internet-Draft CBOR September 2020 * Not accept maps with duplicate keys (that is, enforce validity for maps, see also Section 5.4). These generic decoders are universally useful. An application may still need to do perform its own duplicate checking based on application rules (for instance if the application equates integers and floating-point values in map key positions for specific maps). * Pass all map entries to the application, including ones with duplicate keys. This requires the application to handle (check against) duplicate keys, even if the application rules are identical to the generic data model rules. * Lose some entries with duplicate keys, e.g. by only delivering the final (or first) entry out of the entries with the same key. With such a generic decoder, applications may get different results for a specific key on different runs and with different generic decoders as which value is returned is based on generic decoder implementation and the actual order of keys in the map. In particular, applications cannot validate key uniqueness on their own as they do not necessarily see all entries; they may not be able to use such a generic decoder if they do need to validate key uniqueness. These generic decoders can only be used in situations where the data source and transfer can be relied upon to always provide valid maps; this is not possible if the data source and transfer can be attacked. Generic decoders need to document which of these three approaches they implement. The CBOR data model for maps does not allow ascribing semantics to the order of the key/value pairs in the map representation. Thus, a CBOR-based protocol MUST NOT specify that changing the key/value pair order in a map would change the semantics, except to specify that some orders are disallowed, for example where they would not meet the requirements of a deterministic encoding (Section 4.2). (Any secondary effects of map ordering such as on timing, cache usage, and other potential side channels are not considered part of the semantics but may be enough reason on their own for a protocol to require a deterministic encoding format.) Applications for constrained devices that have maps where a small number of frequently used keys can be identified should consider using small integers as keys; for instance, a set of 24 or fewer frequent keys can be encoded in a single byte as unsigned integers, up to 48 if negative integers are also used. Less frequently occurring keys can then use integers with longer encodings. Bormann & Hoffman Expires 3 April 2021 [Page 41] Internet-Draft CBOR September 2020 5.6.1. Equivalence of Keys The specific data model applying to a CBOR data item is used to determine whether keys occurring in maps are duplicates or distinct. At the generic data model level, numerically equivalent integer and floating-point values are distinct from each other, as they are from the various big numbers (Tags 2 to 5). Similarly, text strings are distinct from byte strings, even if composed of the same bytes. A tagged value is distinct from an untagged value or from a value tagged with a different tag number. Within each of these groups, numeric values are distinct unless they are numerically equal (specifically, -0.0 is equal to 0.0); for the purpose of map key equivalence, NaN (not a number) values are equivalent if they have the same significand after zero-extending both significands at the right to 64 bits. (Byte and text) strings are compared byte by byte, arrays element by element, and are equal if they have the same number of bytes/elements and the same values at the same positions. Two maps are equal if they have the same set of pairs regardless of their order; pairs are equal if both the key and value are equal. Tagged values are equal if both the tag number and the tag content are equal. (Note that a generic decoder that provides processing for a specific tag may not be able to distinguish some semantically equivalent values, e.g. if leading zeroes occur in the content of tag 2/3 (Section 3.4.3).) Simple values are equal if they simply have the same value. Nothing else is equal in the generic data model; a simple value 2 is not equivalent to an integer 2 and an array is never equivalent to a map. As discussed in Section 2.2, specific data models can make values equivalent for the purpose of comparing map keys that are distinct in the generic data model. Note that this implies that a generic decoder may deliver a decoded map to an application that needs to be checked for duplicate map keys by that application (alternatively, the decoder may provide a programming interface to perform this service for the application). Specific data models are not able to distinguish values for map keys that are equal for this purpose at the generic data model level. Bormann & Hoffman Expires 3 April 2021 [Page 42] Internet-Draft CBOR September 2020 5.7. Undefined Values In some CBOR-based protocols, the simple value (Section 3.3) of Undefined might be used by an encoder as a substitute for a data item with an encoding problem, in order to allow the rest of the enclosing data items to be encoded without harm. 6. Converting Data between CBOR and JSON This section gives non-normative advice about converting between CBOR and JSON. Implementations of converters MAY use whichever advice here they want. It is worth noting that a JSON text is a sequence of characters, not an encoded sequence of bytes, while a CBOR data item consists of bytes, not characters. 6.1. Converting from CBOR to JSON Most of the types in CBOR have direct analogs in JSON. However, some do not, and someone implementing a CBOR-to-JSON converter has to consider what to do in those cases. The following non-normative advice deals with these by converting them to a single substitute value, such as a JSON null. * An integer (major type 0 or 1) becomes a JSON number. * A byte string (major type 2) that is not embedded in a tag that specifies a proposed encoding is encoded in base64url without padding and becomes a JSON string. * A UTF-8 string (major type 3) becomes a JSON string. Note that JSON requires escaping certain characters ([RFC8259], Section 7): quotation mark (U+0022), reverse solidus (U+005C), and the "C0 control characters" (U+0000 through U+001F). All other characters are copied unchanged into the JSON UTF-8 string. * An array (major type 4) becomes a JSON array. * A map (major type 5) becomes a JSON object. This is possible directly only if all keys are UTF-8 strings. A converter might also convert other keys into UTF-8 strings (such as by converting integers into strings containing their decimal representation); however, doing so introduces a danger of key collision. Note also that, if tags on UTF-8 strings are ignored as proposed below, this will cause a key collision if the tags are different but the strings are the same. Bormann & Hoffman Expires 3 April 2021 [Page 43] Internet-Draft CBOR September 2020 * False (major type 7, additional information 20) becomes a JSON false. * True (major type 7, additional information 21) becomes a JSON true. * Null (major type 7, additional information 22) becomes a JSON null. * A floating-point value (major type 7, additional information 25 through 27) becomes a JSON number if it is finite (that is, it can be represented in a JSON number); if the value is non-finite (NaN, or positive or negative Infinity), it is represented by the substitute value. * Any other simple value (major type 7, any additional information value not yet discussed) is represented by the substitute value. * A bignum (major type 6, tag number 2 or 3) is represented by encoding its byte string in base64url without padding and becomes a JSON string. For tag number 3 (negative bignum), a "~" (ASCII tilde) is inserted before the base-encoded value. (The conversion to a binary blob instead of a number is to prevent a likely numeric overflow for the JSON decoder.) * A byte string with an encoding hint (major type 6, tag number 21 through 23) is encoded as described by the hint and becomes a JSON string. * For all other tags (major type 6, any other tag number), the tag content is represented as a JSON value; the tag number is ignored. * Indefinite-length items are made definite before conversion. A CBOR-to-JSON converter may want to keep to the JSON profile I-JSON [RFC7493], to maximize interoperability and increase confidence that the JSON output can be processed with predictable results. For example, this has implications on the range of integers that can be represented reliably, as well as on the top-level items that may be supported by older JSON implementations. 6.2. Converting from JSON to CBOR All JSON values, once decoded, directly map into one or more CBOR values. As with any kind of CBOR generation, decisions have to be made with respect to number representation. In a suggested conversion: Bormann & Hoffman Expires 3 April 2021 [Page 44] Internet-Draft CBOR September 2020 * JSON numbers without fractional parts (integer numbers) are represented as integers (major types 0 and 1, possibly major type 6 tag number 2 and 3), choosing the shortest form; integers longer than an implementation-defined threshold may instead be represented as floating-point values. The default range that is represented as integer is -2**53+1..2**53-1 (fully exploiting the range for exact integers in the binary64 representation often used for decoding JSON [RFC7493]). A CBOR-based protocol, or a generic converter implementation, may choose -2**32..2**32-1 or -2**64..2**64-1 (fully using the integer ranges available in CBOR with uint32_t or uint64_t, respectively) or even -2**31..2**31-1 or -2**63..2**63-1 (using popular ranges for two's complement signed integers). (If the JSON was generated from a JavaScript implementation, its precision is already limited to 53 bits maximum.) * Numbers with fractional parts are represented as floating-point values, performing the decimal-to-binary conversion based on the precision provided by IEEE 754 binary64. The mathematical value of the JSON number is converted to binary64 using the roundTiesToEven procedure in Section 4.3.1 of [IEEE754]. Then, when encoding in CBOR, the preferred serialization uses the shortest floating-point representation exactly representing this conversion result; for instance, 1.5 is represented in a 16-bit floating-point value (not all implementations will be capable of efficiently finding the minimum form, though). Instead of using the default binary64 precision, there may be an implementation- defined limit to the precision of the conversion that will affect the precision of the represented values. Decimal representation should only be used on the CBOR side if that is specified in a protocol. CBOR has been designed to generally provide a more compact encoding than JSON. One implementation strategy that might come to mind is to perform a JSON-to-CBOR encoding in place in a single buffer. This strategy would need to carefully consider a number of pathological cases, such as that some strings represented with no or very few escapes and longer (or much longer) than 255 bytes may expand when encoded as UTF-8 strings in CBOR. Similarly, a few of the binary floating-point representations might cause expansion from some short decimal representations (1.1, 1e9) in JSON. This may be hard to get right, and any ensuing vulnerabilities may be exploited by an attacker. Bormann & Hoffman Expires 3 April 2021 [Page 45] Internet-Draft CBOR September 2020 7. Future Evolution of CBOR Successful protocols evolve over time. New ideas appear, implementation platforms improve, related protocols are developed and evolve, and new requirements from applications and protocols are added. Facilitating protocol evolution is therefore an important design consideration for any protocol development. For protocols that will use CBOR, CBOR provides some useful mechanisms to facilitate their evolution. Best practices for this are well known, particularly from JSON format development of JSON- based protocols. Therefore, such best practices are outside the scope of this specification. However, facilitating the evolution of CBOR itself is very well within its scope. CBOR is designed to both provide a stable basis for development of CBOR-based protocols and to be able to evolve. Since a successful protocol may live for decades, CBOR needs to be designed for decades of use and evolution. This section provides some guidance for the evolution of CBOR. It is necessarily more subjective than other parts of this document. It is also necessarily incomplete, lest it turn into a textbook on protocol development. 7.1. Extension Points In a protocol design, opportunities for evolution are often included in the form of extension points. For example, there may be a codepoint space that is not fully allocated from the outset, and the protocol is designed to tolerate and embrace implementations that start using more codepoints than initially allocated. Sizing the codepoint space may be difficult because the range required may be hard to predict. Protocol designs should attempt to make the codepoint space large enough so that it can slowly be filled over the intended lifetime of the protocol. CBOR has three major extension points: * the "simple" space (values in major type 7). Of the 24 efficient (and 224 slightly less efficient) values, only a small number have been allocated. Implementations receiving an unknown simple data item may easily be able to process it as such, given that the structure of the value is indeed simple. The IANA registry in Section 9.1 is the appropriate way to address the extensibility of this codepoint space. Bormann & Hoffman Expires 3 April 2021 [Page 46] Internet-Draft CBOR September 2020 * the "tag" space (values in major type 6). The total codepoint space is abundant; only a tiny part of it has been allocated. However, not all of these codepoints are equally efficient: the first 24 only consume a single ("1+0") byte, and half of them have already been allocated. The next 232 values only consume two ("1+1") bytes, with nearly a quarter already allocated. These subspaces need some curation to last for a few more decades. Implementations receiving an unknown tag number can choose to process just the enclosed tag content or, preferably, to process the tag as an unknown tag number wrapping the tag content. The IANA registry in Section 9.2 is the appropriate way to address the extensibility of this codepoint space. * the "additional information" space. An implementation receiving an unknown additional information value has no way to continue decoding, so allocating codepoints in this space is a major step beyond just exercising an extension point. There are also very few codepoints left. See also Section 7.2. 7.2. Curating the Additional Information Space The human mind is sometimes drawn to filling in little perceived gaps to make something neat. We expect the remaining gaps in the codepoint space for the additional information values to be an attractor for new ideas, just because they are there. The present specification does not manage the additional information codepoint space by an IANA registry. Instead, allocations out of this space can only be done by updating this specification. For an additional information value of n >= 24, the size of the additional data typically is 2**(n-24) bytes. Therefore, additional information values 28 and 29 should be viewed as candidates for 128-bit and 256-bit quantities, in case a need arises to add them to the protocol. Additional information value 30 is then the only additional information value available for general allocation, and there should be a very good reason for allocating it before assigning it through an update of the present specification. 8. Diagnostic Notation CBOR is a binary interchange format. To facilitate documentation and debugging, and in particular to facilitate communication between entities cooperating in debugging, this section defines a simple human-readable diagnostic notation. All actual interchange always happens in the binary format. Bormann & Hoffman Expires 3 April 2021 [Page 47] Internet-Draft CBOR September 2020 Note that this truly is a diagnostic format; it is not meant to be parsed. Therefore, no formal definition (as in ABNF) is given in this document. (Implementers looking for a text-based format for representing CBOR data items in configuration files may also want to consider YAML [YAML].) The diagnostic notation is loosely based on JSON as it is defined in RFC 8259, extending it where needed. The notation borrows the JSON syntax for numbers (integer and floating-point), True (>true<), False (>false<), Null (>null<), UTF-8 strings, arrays, and maps (maps are called objects in JSON; the diagnostic notation extends JSON here by allowing any data item in the key position). Undefined is written >undefined< as in JavaScript. The non-finite floating-point numbers Infinity, -Infinity, and NaN are written exactly as in this sentence (this is also a way they can be written in JavaScript, although JSON does not allow them). A tag is written as an integer number for the tag number, followed by the tag content in parentheses; for instance, an RFC 3339 (ISO 8601) date could be notated as: 0("2013-03-21T20:04:00Z") or the equivalent relative time as 1(1363896240) Byte strings are notated in one of the base encodings, without padding, enclosed in single quotes, prefixed by >h< for base16, >b32< for base32, >h32< for base32hex, >b64< for base64 or base64url (the actual encodings do not overlap, so the string remains unambiguous). For example, the byte string 0x12345678 could be written h'12345678', b32'CI2FM6A', or b64'EjRWeA'. Unassigned simple values are given as "simple()" with the appropriate integer in the parentheses. For example, "simple(42)" indicates major type 7, value 42. A number of useful extensions to the diagnostic notation defined here are provided in Appendix G of [RFC8610], "Extended Diagnostic Notation" (EDN). Similarly, an extension of this notation could be provided in a separate document to provide for the documentation of NaN payloads, which are not covered in the present document. Bormann & Hoffman Expires 3 April 2021 [Page 48] Internet-Draft CBOR September 2020 8.1. Encoding Indicators Sometimes it is useful to indicate in the diagnostic notation which of several alternative representations were actually used; for example, a data item written >1.5< by a diagnostic decoder might have been encoded as a half-, single-, or double-precision float. The convention for encoding indicators is that anything starting with an underscore and all following characters that are alphanumeric or underscore, is an encoding indicator, and can be ignored by anyone not interested in this information. For example, "_" or "_3". Encoding indicators are always optional. A single underscore can be written after the opening brace of a map or the opening bracket of an array to indicate that the data item was represented in indefinite-length format. For example, [_ 1, 2] contains an indicator that an indefinite-length representation was used to represent the data item [1, 2]. An underscore followed by a decimal digit n indicates that the preceding item (or, for arrays and maps, the item starting with the preceding bracket or brace) was encoded with an additional information value of 24+n. For example, 1.5_1 is a half-precision floating-point number, while 1.5_3 is encoded as double precision. This encoding indicator is not shown in Appendix A. (Note that the encoding indicator "_" is thus an abbreviation of the full form "_7", which is not used.) The detailed chunk structure of byte and text strings of indefinite length can be notated in the form (_ h'0123', h'4567') and (_ "foo", "bar"). However, for an indefinite length string with no chunks inside, (_ ) would be ambiguous whether a byte string (0x5fff) or a text string (0x7fff) is meant and is therefore not used. The basic forms ''_ and ""_ can be used instead and are reserved for the case with no chunks only -- not as short forms for the (permitted, but not really useful) encodings with only empty chunks, which to preserve the chunk structure need to be notated as (_ ''), (_ ""), etc. 9. IANA Considerations IANA has created two registries for new CBOR values. The registries are separate, that is, not under an umbrella registry, and follow the rules in [RFC8126]. IANA has also assigned a new MIME media type and an associated Constrained Application Protocol (CoAP) Content-Format entry. Bormann & Hoffman Expires 3 April 2021 [Page 49] Internet-Draft CBOR September 2020 9.1. Simple Values Registry IANA has created the "Concise Binary Object Representation (CBOR) Simple Values" registry at [IANA.cbor-simple-values]. The initial values are shown in Table 4. New entries in the range 0 to 19 are assigned by Standards Action. It is suggested that these Standards Actions allocate values starting with the number 16 in order to reserve the lower numbers for contiguous blocks (if any). New entries in the range 32 to 255 are assigned by Specification Required. 9.2. Tags Registry IANA has created the "Concise Binary Object Representation (CBOR) Tags" registry at [IANA.cbor-tags]. The tags that were defined in [RFC7049] are described in detail in Section 3.4, and other tags have already been defined since then. New entries in the range 0 to 23 ("1+0") are assigned by Standards Action. New entries in the ranges 24 to 255 ("1+1") and 256 to 32767 (lower half of "1+2") are assigned by Specification Required. New entries in the range 32768 to 18446744073709551615 (upper half of "1+2", "1+4", and "1+8") are assigned by First Come First Served. The template for registration requests is: * Data item * Semantics (short form) In addition, First Come First Served requests should include: * Point of contact * Description of semantics (URL) -- This description is optional; the URL can point to something like an Internet-Draft or a web page. Applicants exercising the First Come First Served range and making a suggestion for a tag number that is not representable in 32 bits (i.e., larger than 4294967295) should be aware that this could reduce interoperability with implementations that do not support 64-bit numbers. Bormann & Hoffman Expires 3 April 2021 [Page 50] Internet-Draft CBOR September 2020 9.3. Media Type ("MIME Type") The Internet media type [RFC6838] for a single encoded CBOR data item is application/cbor, as defined in [IANA.media-types]: Type name: application Subtype name: cbor Required parameters: n/a Optional parameters: n/a Encoding considerations: Binary Security considerations: See Section 10 of this document Interoperability considerations: n/a Published specification: This document Applications that use this media type: Many Additional information: * Magic number(s): n/a * File extension(s): .cbor * Macintosh file type code(s): n/a Person & email address to contact for further information: IETF CBOR Working Group cbor@ietf.org (mailto:cbor@ietf.org) or IETF Applications and Real-Time Area art@ietf.org (mailto:art@ietf.org) Intended usage: COMMON Restrictions on usage: none Author: IETF CBOR Working Group cbor@ietf.org (mailto:cbor@ietf.org) Change controller: The IESG iesg@ietf.org (mailto:iesg@ietf.org) 9.4. CoAP Content-Format The CoAP Content-Format for CBOR is registered in [IANA.core-parameters]: Media Type: application/cbor Bormann & Hoffman Expires 3 April 2021 [Page 51] Internet-Draft CBOR September 2020 Encoding: - Id: 60 Reference: [RFCthis] 9.5. The +cbor Structured Syntax Suffix Registration The Structured Syntax Suffix [RFC6838] for media types based on a single encoded CBOR data item is +cbor, as defined in [IANA.media-type-structured-suffix]: Name: Concise Binary Object Representation (CBOR) +suffix: +cbor References: [RFCthis] Encoding Considerations: CBOR is a binary format. Interoperability Considerations: n/a Fragment Identifier Considerations: The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for "application/ cbor".) The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor" SHOULD be processed as follows: * For cases defined in +cbor, where the fragment identifier resolves per the +cbor rules, then process as specified in +cbor. * For cases defined in +cbor, where the fragment identifier does not resolve per the +cbor rules, then process as specified in "xxx/yyy+cbor". * For cases not defined in +cbor, then process as specified in "xxx/yyy+cbor". Security Considerations: See Section 10 of this document Contact: IETF CBOR Working Group cbor@ietf.org (mailto:cbor@ietf.org) or IETF Applications and Real-Time Area art@ietf.org (mailto:art@ietf.org) Bormann & Hoffman Expires 3 April 2021 [Page 52] Internet-Draft CBOR September 2020 Author/Change Controller: The IESG iesg@ietf.org (mailto:iesg@ietf.org) 10. Security Considerations A network-facing application can exhibit vulnerabilities in its processing logic for incoming data. Complex parsers are well known as a likely source of such vulnerabilities, such as the ability to remotely crash a node, or even remotely execute arbitrary code on it. CBOR attempts to narrow the opportunities for introducing such vulnerabilities by reducing parser complexity, by giving the entire range of encodable values a meaning where possible. Because CBOR decoders are often used as a first step in processing unvalidated input, they need to be fully prepared for all types of hostile input that may be designed to corrupt, overrun, or achieve control of the system decoding the CBOR data item. A CBOR decoder needs to assume that all input may be hostile even if it has been checked by a firewall, has come over a secure channel such as TLS, is encrypted or signed, or has come from some other source that is presumed trusted. Section 4.1 gives examples of limitations in interoperability when using a constrained CBOR decoder with input from a CBOR encoder that uses a non-preferred serialization. When a single data item is consumed both by such a constrained decoder and a full decoder, it can lead to security issues that can be exploited by an attacker who can inject or manipulate content. As discussed throughout this document, there are many values that can be considered "equivalent" in some circumstances and "not equivalent" in others. As just one example, the numeric value for the number "one" might be expressed as an integer or a bignum. A system interpreting CBOR input might accept either form for the number "one", or might reject one (or both) forms. Such acceptance or rejection can have security implications in the program that is using the interpreted input. Hostile input may be constructed to overrun buffers, overflow or underflow integer arithmetic, or cause other decoding disruption. CBOR data items might have lengths or sizes that are intentionally extremely large or too short. Resource exhaustion attacks might attempt to lure a decoder into allocating very big data items (strings, arrays, maps, or even arbitrary precision numbers) or exhaust the stack depth by setting up deeply nested items. Decoders need to have appropriate resource management to mitigate these attacks. (Items for which very large sizes are given can also attempt to exploit integer overflow vulnerabilities.) Bormann & Hoffman Expires 3 April 2021 [Page 53] Internet-Draft CBOR September 2020 A CBOR decoder, by definition, only accepts well-formed CBOR; this is the first step to its robustness. Input that is not well-formed CBOR causes no further processing from the point where the lack of well- formedness was detected. If possible, any data decoded up to this point should have no impact on the application using the CBOR decoder. In addition to ascertaining well-formedness, a CBOR decoder might also perform validity checks on the CBOR data. Alternatively, it can leave those checks to the application using the decoder. This choice needs to be clearly documented in the decoder. Beyond the validity at the CBOR level, an application also needs to ascertain that the input is in alignment with the application protocol that is serialized in CBOR. The input check itself may consume resources. This is usually linear in the size of the input, which means that an attacker has to spend resources that are commensurate to the resources spent by the defender on input validation. However, an attacker might be able to craft inputs that will take longer for a target decoder to process than for the attacker to produce. Processing for arbitrary-precision numbers may exceed linear effort. Also, some hash-table implementations that are used by decoders to build in-memory representations of maps can be attacked to spend quadratic effort, unless a secret key (see Section 7 of [SIPHASH_LNCS], also [SIPHASH_OPEN]) or some other mitigation is employed. Such superlinear efforts can be exploited by an attacker to exhaust resources at or before the input validator; they therefore need to be avoided in a CBOR decoder implementation. Note that tag number definitions and their implementations can add security considerations of this kind; this should then be discussed in the security considerations of the tag number definition. CBOR encoders do not receive input directly from the network and are thus not directly attackable in the same way as CBOR decoders. However, CBOR encoders often have an API that takes input from another level in the implementation and can be attacked through that API. The design and implementation of that API should assume the behavior of its caller may be based on hostile input or on coding mistakes. It should check inputs for buffer overruns, overflow and underflow of integer arithmetic, and other such errors that are aimed to disrupt the encoder. Protocols should be defined in such a way that potential multiple interpretations are reliably reduced to a single interpretation. For example, an attacker could make use of invalid input such as duplicate keys in maps, or exploit different precision in processing numbers to make one application base its decisions on a different Bormann & Hoffman Expires 3 April 2021 [Page 54] Internet-Draft CBOR September 2020 interpretation than the one that will be used by a second application. To facilitate consistent interpretation, encoder and decoder implementations should provide a validity checking mode of operation (Section 5.4). Note, however, that a generic decoder cannot know about all requirements that an application poses on its input data; it is therefore not relieving the application from performing its own input checking. Also, since the set of defined tag numbers evolves, the application may employ a tag number that is not yet supported for validity checking by the generic decoder it uses. Generic decoders therefore need to provide documentation which tag numbers they support and what validity checking they can provide for each of them as well as for basic CBOR validity (UTF-8 checking, duplicate map key checking). Section 3.4.3 notes that using the non-preferred choice of a bignum representation instead of a basic integer for encoding a number is not intended to have application semantics, but it can have such semantics if an application receiving CBOR data is using a decoder in the basic generic data model. This disparity causes a security issue if the two sets of semantics differ. Thus, applications using CBOR need to specify the data model that they are using for each use of CBOR data. It is common to convert CBOR data to other formats. In many cases, CBOR has more expressive types than other formats; this is particularly true for the common conversion to JSON. The loss of type information can cause security issues for the systems that are processing the less-expressive data. Section 6.2 describes a possibly-common usage scenario of converting between CBOR and JSON that could allow an attack if the attcker knows that the application is performing the conversion. Security considerations for the use of base16 and base64 from [RFC4648], and the use of UTF-8 from [RFC3629], are relevant to CBOR as well. 11. References 11.1. Normative References [C] International Organization for Standardization, "Information technology — Programming languages — C", ISO/ IEC 9899:2018, Fourth Edition, June 2018. Bormann & Hoffman Expires 3 April 2021 [Page 55] Internet-Draft CBOR September 2020 [Cplusplus17] International Organization for Standardization, "Programming languages — C++", ISO/IEC 14882:2017, Fifth Edition, December 2017. [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Bormann & Hoffman Expires 3 April 2021 [Page 56] Internet-Draft CBOR September 2020 [TIME_T] The Open Group Base Specifications, "Open Group Standard: Vol. 1: Base Definitions, Issue 7", Section 4.16 'Seconds Since the Epoch', IEEE Std 1003.1, 2018 Edition, 2018, . 11.2. Informative References [ASN.1] International Telecommunication Union, "Information Technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. [BSON] Various, "BSON - Binary JSON", 2013, . [ECMA262] Ecma International, "ECMAScript 2018 Language Specification", ECMA Standard ECMA-262, 9th Edition, June 2018, . [I-D.bormann-cbor-notable-tags] Bormann, C., "Notable CBOR Tags", Work in Progress, Internet-Draft, draft-bormann-cbor-notable-tags-02, 25 June 2020, . [IANA.cbor-simple-values] IANA, "Concise Binary Object Representation (CBOR) Simple Values", . [IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", . [IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", . [IANA.media-type-structured-suffix] IANA, "Structured Syntax Suffix Registry", . Bormann & Hoffman Expires 3 April 2021 [Page 57] Internet-Draft CBOR September 2020 [IANA.media-types] IANA, "Media Types", . [MessagePack] Furuhashi, S., "MessagePack", 2013, . [PCRE] Ho, A., "PCRE - Perl Compatible Regular Expressions", 2018, . [RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission Protocol", RFC 713, DOI 10.17487/RFC0713, April 1976, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . Bormann & Hoffman Expires 3 April 2021 [Page 58] Internet-Draft CBOR September 2020 [RFC8618] Dickinson, J., Hague, J., Dickinson, S., Manderson, T., and J. Bond, "Compacted-DNS (C-DNS): A Format for DNS Packet Capture", RFC 8618, DOI 10.17487/RFC8618, September 2019, . [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, . [RFC8746] Bormann, C., Ed., "Concise Binary Object Representation (CBOR) Tags for Typed Arrays", RFC 8746, DOI 10.17487/RFC8746, February 2020, . [SIPHASH_LNCS] Aumasson, J. and D. Bernstein, "SipHash: A Fast Short- Input PRF", Lecture Notes in Computer Science pp. 489-508, DOI 10.1007/978-3-642-34931-7_28, 2012, . [SIPHASH_OPEN] Aumasson, J. and D.J. Bernstein, "SipHash: a fast short- input PRF", . [YAML] Ben-Kiki, O., Evans, C., and I.d. Net, "YAML Ain't Markup Language (YAML[TM]) Version 1.2", 3rd Edition, October 2009, . Appendix A. Examples of Encoded CBOR Data Items The following table provides some CBOR-encoded values in hexadecimal (right column), together with diagnostic notation for these values (left column). Note that the string "\u00fc" is one form of diagnostic notation for a UTF-8 string containing the single Unicode character U+00FC, LATIN SMALL LETTER U WITH DIAERESIS (u umlaut). Similarly, "\u6c34" is a UTF-8 string in diagnostic notation with a single character U+6C34 (CJK UNIFIED IDEOGRAPH-6C34, often representing "water"), and "\ud800\udd51" is a UTF-8 string in diagnostic notation with a single character U+10151 (GREEK ACROPHONIC ATTIC FIFTY STATERS). (Note that all these single-character strings could also be represented in native UTF-8 in diagnostic notation, just not in an ASCII-only specification.) In the diagnostic notation provided for bignums, their intended numeric value is shown as a decimal number (such as 18446744073709551616) instead of showing a tagged byte string (such as 2(h'010000000000000000')). Bormann & Hoffman Expires 3 April 2021 [Page 59] Internet-Draft CBOR September 2020 +==============================+====================================+ |Diagnostic | Encoded | +==============================+====================================+ |0 | 0x00 | +------------------------------+------------------------------------+ |1 | 0x01 | +------------------------------+------------------------------------+ |10 | 0x0a | +------------------------------+------------------------------------+ |23 | 0x17 | +------------------------------+------------------------------------+ |24 | 0x1818 | +------------------------------+------------------------------------+ |25 | 0x1819 | +------------------------------+------------------------------------+ |100 | 0x1864 | +------------------------------+------------------------------------+ |1000 | 0x1903e8 | +------------------------------+------------------------------------+ |1000000 | 0x1a000f4240 | +------------------------------+------------------------------------+ |1000000000000 | 0x1b000000e8d4a51000 | +------------------------------+------------------------------------+ |18446744073709551615 | 0x1bffffffffffffffff | +------------------------------+------------------------------------+ |18446744073709551616 | 0xc249010000000000000000 | +------------------------------+------------------------------------+ |-18446744073709551616 | 0x3bffffffffffffffff | +------------------------------+------------------------------------+ |-18446744073709551617 | 0xc349010000000000000000 | +------------------------------+------------------------------------+ |-1 | 0x20 | +------------------------------+------------------------------------+ |-10 | 0x29 | +------------------------------+------------------------------------+ |-100 | 0x3863 | +------------------------------+------------------------------------+ |-1000 | 0x3903e7 | +------------------------------+------------------------------------+ |0.0 | 0xf90000 | +------------------------------+------------------------------------+ |-0.0 | 0xf98000 | +------------------------------+------------------------------------+ |1.0 | 0xf93c00 | +------------------------------+------------------------------------+ |1.1 | 0xfb3ff199999999999a | +------------------------------+------------------------------------+ |1.5 | 0xf93e00 | Bormann & Hoffman Expires 3 April 2021 [Page 60] Internet-Draft CBOR September 2020 +------------------------------+------------------------------------+ |65504.0 | 0xf97bff | +------------------------------+------------------------------------+ |100000.0 | 0xfa47c35000 | +------------------------------+------------------------------------+ |3.4028234663852886e+38 | 0xfa7f7fffff | +------------------------------+------------------------------------+ |1.0e+300 | 0xfb7e37e43c8800759c | +------------------------------+------------------------------------+ |5.960464477539063e-8 | 0xf90001 | +------------------------------+------------------------------------+ |0.00006103515625 | 0xf90400 | +------------------------------+------------------------------------+ |-4.0 | 0xf9c400 | +------------------------------+------------------------------------+ |-4.1 | 0xfbc010666666666666 | +------------------------------+------------------------------------+ |Infinity | 0xf97c00 | +------------------------------+------------------------------------+ |NaN | 0xf97e00 | +------------------------------+------------------------------------+ |-Infinity | 0xf9fc00 | +------------------------------+------------------------------------+ |Infinity | 0xfa7f800000 | +------------------------------+------------------------------------+ |NaN | 0xfa7fc00000 | +------------------------------+------------------------------------+ |-Infinity | 0xfaff800000 | +------------------------------+------------------------------------+ |Infinity | 0xfb7ff0000000000000 | +------------------------------+------------------------------------+ |NaN | 0xfb7ff8000000000000 | +------------------------------+------------------------------------+ |-Infinity | 0xfbfff0000000000000 | +------------------------------+------------------------------------+ |false | 0xf4 | +------------------------------+------------------------------------+ |true | 0xf5 | +------------------------------+------------------------------------+ |null | 0xf6 | +------------------------------+------------------------------------+ |undefined | 0xf7 | +------------------------------+------------------------------------+ |simple(16) | 0xf0 | +------------------------------+------------------------------------+ |simple(255) | 0xf8ff | +------------------------------+------------------------------------+ |0("2013-03-21T20:04:00Z") | 0xc074323031332d30332d32315432303a | Bormann & Hoffman Expires 3 April 2021 [Page 61] Internet-Draft CBOR September 2020 | | 30343a30305a | +------------------------------+------------------------------------+ |1(1363896240) | 0xc11a514b67b0 | +------------------------------+------------------------------------+ |1(1363896240.5) | 0xc1fb41d452d9ec200000 | +------------------------------+------------------------------------+ |23(h'01020304') | 0xd74401020304 | +------------------------------+------------------------------------+ |24(h'6449455446') | 0xd818456449455446 | +------------------------------+------------------------------------+ |32("http://www.example.com") | 0xd82076687474703a2f2f7777772e6578 | | | 616d706c652e636f6d | +------------------------------+------------------------------------+ |h'' | 0x40 | +------------------------------+------------------------------------+ |h'01020304' | 0x4401020304 | +------------------------------+------------------------------------+ |"" | 0x60 | +------------------------------+------------------------------------+ |"a" | 0x6161 | +------------------------------+------------------------------------+ |"IETF" | 0x6449455446 | +------------------------------+------------------------------------+ |"\"\\" | 0x62225c | +------------------------------+------------------------------------+ |"\u00fc" | 0x62c3bc | +------------------------------+------------------------------------+ |"\u6c34" | 0x63e6b0b4 | +------------------------------+------------------------------------+ |"\ud800\udd51" | 0x64f0908591 | +------------------------------+------------------------------------+ |[] | 0x80 | +------------------------------+------------------------------------+ |[1, 2, 3] | 0x83010203 | +------------------------------+------------------------------------+ |[1, [2, 3], [4, 5]] | 0x8301820203820405 | +------------------------------+------------------------------------+ |[1, 2, 3, 4, 5, 6, 7, 8, 9, | 0x98190102030405060708090a0b0c0d0e | |10, 11, 12, 13, 14, 15, 16, | 0f101112131415161718181819 | |17, 18, 19, 20, 21, 22, 23, | | |24, 25] | | +------------------------------+------------------------------------+ |{} | 0xa0 | +------------------------------+------------------------------------+ |{1: 2, 3: 4} | 0xa201020304 | +------------------------------+------------------------------------+ |{"a": 1, "b": [2, 3]} | 0xa26161016162820203 | +------------------------------+------------------------------------+ Bormann & Hoffman Expires 3 April 2021 [Page 62] Internet-Draft CBOR September 2020 |["a", {"b": "c"}] | 0x826161a161626163 | +------------------------------+------------------------------------+ |{"a": "A", "b": "B", "c": "C",| 0xa5616161416162614261636143616461 | |"d": "D", "e": "E"} | 4461656145 | +------------------------------+------------------------------------+ |(_ h'0102', h'030405') | 0x5f42010243030405ff | +------------------------------+------------------------------------+ |(_ "strea", "ming") | 0x7f657374726561646d696e67ff | +------------------------------+------------------------------------+ |[_ ] | 0x9fff | +------------------------------+------------------------------------+ |[_ 1, [2, 3], [_ 4, 5]] | 0x9f018202039f0405ffff | +------------------------------+------------------------------------+ |[_ 1, [2, 3], [4, 5]] | 0x9f01820203820405ff | +------------------------------+------------------------------------+ |[1, [2, 3], [_ 4, 5]] | 0x83018202039f0405ff | +------------------------------+------------------------------------+ |[1, [_ 2, 3], [4, 5]] | 0x83019f0203ff820405 | +------------------------------+------------------------------------+ |[_ 1, 2, 3, 4, 5, 6, 7, 8, 9, | 0x9f0102030405060708090a0b0c0d0e0f | |10, 11, 12, 13, 14, 15, 16, | 101112131415161718181819ff | |17, 18, 19, 20, 21, 22, 23, | | |24, 25] | | +------------------------------+------------------------------------+ |{_ "a": 1, "b": [_ 2, 3]} | 0xbf61610161629f0203ffff | +------------------------------+------------------------------------+ |["a", {_ "b": "c"}] | 0x826161bf61626163ff | +------------------------------+------------------------------------+ |{_ "Fun": true, "Amt": -2} | 0xbf6346756ef563416d7421ff | +------------------------------+------------------------------------+ Table 6: Examples of Encoded CBOR Data Items Appendix B. Jump Table for Initial Byte For brevity, this jump table does not show initial bytes that are reserved for future extension. It also only shows a selection of the initial bytes that can be used for optional features. (All unsigned integers are in network byte order.) +============+================================================+ | Byte | Structure/Semantics | +============+================================================+ | 0x00..0x17 | Unsigned integer 0x00..0x17 (0..23) | +------------+------------------------------------------------+ | 0x18 | Unsigned integer (one-byte uint8_t follows) | +------------+------------------------------------------------+ | 0x19 | Unsigned integer (two-byte uint16_t follows) | Bormann & Hoffman Expires 3 April 2021 [Page 63] Internet-Draft CBOR September 2020 +------------+------------------------------------------------+ | 0x1a | Unsigned integer (four-byte uint32_t follows) | +------------+------------------------------------------------+ | 0x1b | Unsigned integer (eight-byte uint64_t follows) | +------------+------------------------------------------------+ | 0x20..0x37 | Negative integer -1-0x00..-1-0x17 (-1..-24) | +------------+------------------------------------------------+ | 0x38 | Negative integer -1-n (one-byte uint8_t for n | | | follows) | +------------+------------------------------------------------+ | 0x39 | Negative integer -1-n (two-byte uint16_t for n | | | follows) | +------------+------------------------------------------------+ | 0x3a | Negative integer -1-n (four-byte uint32_t for | | | n follows) | +------------+------------------------------------------------+ | 0x3b | Negative integer -1-n (eight-byte uint64_t for | | | n follows) | +------------+------------------------------------------------+ | 0x40..0x57 | byte string (0x00..0x17 bytes follow) | +------------+------------------------------------------------+ | 0x58 | byte string (one-byte uint8_t for n, and then | | | n bytes follow) | +------------+------------------------------------------------+ | 0x59 | byte string (two-byte uint16_t for n, and then | | | n bytes follow) | +------------+------------------------------------------------+ | 0x5a | byte string (four-byte uint32_t for n, and | | | then n bytes follow) | +------------+------------------------------------------------+ | 0x5b | byte string (eight-byte uint64_t for n, and | | | then n bytes follow) | +------------+------------------------------------------------+ | 0x5f | byte string, byte strings follow, terminated | | | by "break" | +------------+------------------------------------------------+ | 0x60..0x77 | UTF-8 string (0x00..0x17 bytes follow) | +------------+------------------------------------------------+ | 0x78 | UTF-8 string (one-byte uint8_t for n, and then | | | n bytes follow) | +------------+------------------------------------------------+ | 0x79 | UTF-8 string (two-byte uint16_t for n, and | | | then n bytes follow) | +------------+------------------------------------------------+ | 0x7a | UTF-8 string (four-byte uint32_t for n, and | | | then n bytes follow) | +------------+------------------------------------------------+ | 0x7b | UTF-8 string (eight-byte uint64_t for n, and | Bormann & Hoffman Expires 3 April 2021 [Page 64] Internet-Draft CBOR September 2020 | | then n bytes follow) | +------------+------------------------------------------------+ | 0x7f | UTF-8 string, UTF-8 strings follow, terminated | | | by "break" | +------------+------------------------------------------------+ | 0x80..0x97 | array (0x00..0x17 data items follow) | +------------+------------------------------------------------+ | 0x98 | array (one-byte uint8_t for n, and then n data | | | items follow) | +------------+------------------------------------------------+ | 0x99 | array (two-byte uint16_t for n, and then n | | | data items follow) | +------------+------------------------------------------------+ | 0x9a | array (four-byte uint32_t for n, and then n | | | data items follow) | +------------+------------------------------------------------+ | 0x9b | array (eight-byte uint64_t for n, and then n | | | data items follow) | +------------+------------------------------------------------+ | 0x9f | array, data items follow, terminated by | | | "break" | +------------+------------------------------------------------+ | 0xa0..0xb7 | map (0x00..0x17 pairs of data items follow) | +------------+------------------------------------------------+ | 0xb8 | map (one-byte uint8_t for n, and then n pairs | | | of data items follow) | +------------+------------------------------------------------+ | 0xb9 | map (two-byte uint16_t for n, and then n pairs | | | of data items follow) | +------------+------------------------------------------------+ | 0xba | map (four-byte uint32_t for n, and then n | | | pairs of data items follow) | +------------+------------------------------------------------+ | 0xbb | map (eight-byte uint64_t for n, and then n | | | pairs of data items follow) | +------------+------------------------------------------------+ | 0xbf | map, pairs of data items follow, terminated by | | | "break" | +------------+------------------------------------------------+ | 0xc0 | Text-based date/time (data item follows; see | | | Section 3.4.1) | +------------+------------------------------------------------+ | 0xc1 | Epoch-based date/time (data item follows; see | | | Section 3.4.2) | +------------+------------------------------------------------+ | 0xc2 | Positive bignum (data item "byte string" | | | follows) | +------------+------------------------------------------------+ Bormann & Hoffman Expires 3 April 2021 [Page 65] Internet-Draft CBOR September 2020 | 0xc3 | Negative bignum (data item "byte string" | | | follows) | +------------+------------------------------------------------+ | 0xc4 | Decimal Fraction (data item "array" follows; | | | see Section 3.4.4) | +------------+------------------------------------------------+ | 0xc5 | Bigfloat (data item "array" follows; see | | | Section 3.4.4) | +------------+------------------------------------------------+ | 0xc6..0xd4 | (tag) | +------------+------------------------------------------------+ | 0xd5..0xd7 | Expected Conversion (data item follows; see | | | Section 3.4.5.2) | +------------+------------------------------------------------+ | 0xd8..0xdb | (more tags; 1/2/4/8 bytes of tag number and | | | then a data item follow) | +------------+------------------------------------------------+ | 0xe0..0xf3 | (simple value) | +------------+------------------------------------------------+ | 0xf4 | False | +------------+------------------------------------------------+ | 0xf5 | True | +------------+------------------------------------------------+ | 0xf6 | Null | +------------+------------------------------------------------+ | 0xf7 | Undefined | +------------+------------------------------------------------+ | 0xf8 | (simple value, one byte follows) | +------------+------------------------------------------------+ | 0xf9 | Half-Precision Float (two-byte IEEE 754) | +------------+------------------------------------------------+ | 0xfa | Single-Precision Float (four-byte IEEE 754) | +------------+------------------------------------------------+ | 0xfb | Double-Precision Float (eight-byte IEEE 754) | +------------+------------------------------------------------+ | 0xff | "break" stop code | +------------+------------------------------------------------+ Table 7: Jump Table for Initial Byte Appendix C. Pseudocode The well-formedness of a CBOR item can be checked by the pseudocode in Figure 1. The data is well-formed if and only if: * the pseudocode does not "fail"; Bormann & Hoffman Expires 3 April 2021 [Page 66] Internet-Draft CBOR September 2020 * after execution of the pseudocode, no bytes are left in the input (except in streaming applications) The pseudocode has the following prerequisites: * take(n) reads n bytes from the input data and returns them as a byte string. If n bytes are no longer available, take(n) fails. * uint() converts a byte string into an unsigned integer by interpreting the byte string in network byte order. * Arithmetic works as in C. * All variables are unsigned integers of sufficient range. Note that "well_formed" returns the major type for well-formed definite length items, but 99 for an indefinite length item (or -1 for a "break" stop code, only if "breakable" is set). This is used in "well_formed_indefinite" to ascertain that indefinite length strings only contain definite length strings as chunks. Bormann & Hoffman Expires 3 April 2021 [Page 67] Internet-Draft CBOR September 2020 well_formed(breakable = false) { // process initial bytes ib = uint(take(1)); mt = ib >> 5; val = ai = ib & 0x1f; switch (ai) { case 24: val = uint(take(1)); break; case 25: val = uint(take(2)); break; case 26: val = uint(take(4)); break; case 27: val = uint(take(8)); break; case 28: case 29: case 30: fail(); case 31: return well_formed_indefinite(mt, breakable); } // process content switch (mt) { // case 0, 1, 7 do not have content; just use val case 2: case 3: take(val); break; // bytes/UTF-8 case 4: for (i = 0; i < val; i++) well_formed(); break; case 5: for (i = 0; i < val*2; i++) well_formed(); break; case 6: well_formed(); break; // 1 embedded data item case 7: if (ai == 24 && val < 32) fail(); // bad simple } return mt; // definite-length data item } well_formed_indefinite(mt, breakable) { switch (mt) { case 2: case 3: while ((it = well_formed(true)) != -1) if (it != mt) // need definite-length chunk fail(); // of same type break; case 4: while (well_formed(true) != -1); break; case 5: while (well_formed(true) != -1) well_formed(); break; case 7: if (breakable) return -1; // signal break out else fail(); // no enclosing indefinite default: fail(); // wrong mt } return 99; // indefinite-length data item } Figure 1: Pseudocode for Well-Formedness Check Bormann & Hoffman Expires 3 April 2021 [Page 68] Internet-Draft CBOR September 2020 Note that the remaining complexity of a complete CBOR decoder is about presenting data that has been decoded to the application in an appropriate form. Major types 0 and 1 are designed in such a way that they can be encoded in C from a signed integer without actually doing an if-then- else for positive/negative (Figure 2). This uses the fact that (-1-n), the transformation for major type 1, is the same as ~n (bitwise complement) in C unsigned arithmetic; ~n can then be expressed as (-1)^n for the negative case, while 0^n leaves n unchanged for non-negative. The sign of a number can be converted to -1 for negative and 0 for non-negative (0 or positive) by arithmetic- shifting the number by one bit less than the bit length of the number (for example, by 63 for 64-bit numbers). void encode_sint(int64_t n) { uint64t ui = n >> 63; // extend sign to whole length unsigned mt = ui & 0x20; // extract (shifted) major type ui ^= n; // complement negatives if (ui < 24) *p++ = mt + ui; else if (ui < 256) { *p++ = mt + 24; *p++ = ui; } else ... Figure 2: Pseudocode for Encoding a Signed Integer See Section 1.2 for some specific assumptions about the profile of the C language used in these pieces of code. Appendix D. Half-Precision As half-precision floating-point numbers were only added to IEEE 754 in 2008 [IEEE754], today's programming platforms often still only have limited support for them. It is very easy to include at least decoding support for them even without such support. An example of a small decoder for half-precision floating-point numbers in the C language is shown in Figure 3. A similar program for Python is in Figure 4; this code assumes that the 2-byte value has already been decoded as an (unsigned short) integer in network byte order (as would be done by the pseudocode in Appendix C). Bormann & Hoffman Expires 3 April 2021 [Page 69] Internet-Draft CBOR September 2020 #include double decode_half(unsigned char *halfp) { unsigned half = (halfp[0] << 8) + halfp[1]; unsigned exp = (half >> 10) & 0x1f; unsigned mant = half & 0x3ff; double val; if (exp == 0) val = ldexp(mant, -24); else if (exp != 31) val = ldexp(mant + 1024, exp - 25); else val = mant == 0 ? INFINITY : NAN; return half & 0x8000 ? -val : val; } Figure 3: C Code for a Half-Precision Decoder import struct from math import ldexp def decode_single(single): return struct.unpack("!f", struct.pack("!I", single))[0] def decode_half(half): valu = (half & 0x7fff) << 13 | (half & 0x8000) << 16 if ((half & 0x7c00) != 0x7c00): return ldexp(decode_single(valu), 112) return decode_single(valu | 0x7f800000) Figure 4: Python Code for a Half-Precision Decoder Appendix E. Comparison of Other Binary Formats to CBOR's Design Objectives The proposal for CBOR follows a history of binary formats that is as long as the history of computers themselves. Different formats have had different objectives. In most cases, the objectives of the format were never stated, although they can sometimes be implied by the context where the format was first used. Some formats were meant to be universally usable, although history has proven that no binary format meets the needs of all protocols and applications. CBOR differs from many of these formats due to it starting with a set of objectives and attempting to meet just those. This section compares a few of the dozens of formats with CBOR's objectives in order to help the reader decide if they want to use CBOR or a different format for a particular protocol or application. Bormann & Hoffman Expires 3 April 2021 [Page 70] Internet-Draft CBOR September 2020 Note that the discussion here is not meant to be a criticism of any format: to the best of our knowledge, no format before CBOR was meant to cover CBOR's objectives in the priority we have assigned them. A brief recap of the objectives from Section 1.1 is: 1. unambiguous encoding of most common data formats from Internet standards 2. code compactness for encoder or decoder 3. no schema description needed 4. reasonably compact serialization 5. applicability to constrained and unconstrained applications 6. good JSON conversion 7. extensibility A discussion of CBOR and other formats with respect to a different set of design objectives is provided in Section 5 and Appendix C of [RFC8618]. E.1. ASN.1 DER, BER, and PER [ASN.1] has many serializations. In the IETF, DER and BER are the most common. The serialized output is not particularly compact for many items, and the code needed to decode numeric items can be complex on a constrained device. Few (if any) IETF protocols have adopted one of the several variants of Packed Encoding Rules (PER). There could be many reasons for this, but one that is commonly stated is that PER makes use of the schema even for parsing the surface structure of the data item, requiring significant tool support. There are different versions of the ASN.1 schema language in use, which has also hampered adoption. E.2. MessagePack [MessagePack] is a concise, widely implemented counted binary serialization format, similar in many properties to CBOR, although somewhat less regular. While the data model can be used to represent JSON data, MessagePack has also been used in many remote procedure call (RPC) applications and for long-term storage of data. Bormann & Hoffman Expires 3 April 2021 [Page 71] Internet-Draft CBOR September 2020 MessagePack has been essentially stable since it was first published around 2011; it has not yet had a transition. The evolution of MessagePack is impeded by an imperative to maintain complete backwards compatibility with existing stored data, while only few bytecodes are still available for extension. Repeated requests over the years from the MessagePack user community to separate out binary and text strings in the encoding recently have led to an extension proposal that would leave MessagePack's "raw" data ambiguous between its usages for binary and text data. The extension mechanism for MessagePack remains unclear. E.3. BSON [BSON] is a data format that was developed for the storage of JSON- like maps (JSON objects) in the MongoDB database. Its major distinguishing feature is the capability for in-place update, which prevents a compact representation. BSON uses a counted representation except for map keys, which are null-byte terminated. While BSON can be used for the representation of JSON-like objects on the wire, its specification is dominated by the requirements of the database application and has become somewhat baroque. The status of how BSON extensions will be implemented remains unclear. E.4. MSDTP: RFC 713 Message Services Data Transmission (MSDTP) is a very early example of a compact message format; it is described in [RFC0713], written in 1976. It is included here for its historical value, not because it was ever widely used. E.5. Conciseness on the Wire While CBOR's design objective of code compactness for encoders and decoders is a higher priority than its objective of conciseness on the wire, many people focus on the wire size. Table 8 shows some encoding examples for the simple nested array [1, [2, 3]]; where some form of indefinite-length encoding is supported by the encoding, [_ 1, [2, 3]] (indefinite length on the outer array) is also shown. Bormann & Hoffman Expires 3 April 2021 [Page 72] Internet-Draft CBOR September 2020 +=============+============================+================+ | Format | [1, [2, 3]] | [_ 1, [2, 3]] | +=============+============================+================+ | RFC 713 | c2 05 81 c2 02 82 83 | | +-------------+----------------------------+----------------+ | ASN.1 BER | 30 0b 02 01 01 30 06 02 01 | 30 80 02 01 01 | | | 02 02 01 03 | 30 06 02 01 02 | | | | 02 01 03 00 00 | +-------------+----------------------------+----------------+ | MessagePack | 92 01 92 02 03 | | +-------------+----------------------------+----------------+ | BSON | 22 00 00 00 10 30 00 01 00 | | | | 00 00 04 31 00 13 00 00 00 | | | | 10 30 00 02 00 00 00 10 31 | | | | 00 03 00 00 00 00 00 | | +-------------+----------------------------+----------------+ | CBOR | 82 01 82 02 03 | 9f 01 82 02 03 | | | | ff | +-------------+----------------------------+----------------+ Table 8: Examples for Different Levels of Conciseness Appendix F. Well-formedness errors and examples There are three basic kinds of well-formedness errors that can occur in decoding a CBOR data item: * Too much data: There are input bytes left that were not consumed. This is only an error if the application assumed that the input bytes would span exactly one data item. Where the application uses the self-delimiting nature of CBOR encoding to permit additional data after the data item, as is for example done in CBOR sequences [RFC8742], the CBOR decoder can simply indicate what part of the input has not been consumed. * Too little data: The input data available would need additional bytes added at their end for a complete CBOR data item. This may indicate the input is truncated; it is also a common error when trying to decode random data as CBOR. For some applications, however, this may not actually be an error, as the application may not be certain it has all the data yet and can obtain or wait for additional input bytes. Some of these applications may have an upper limit for how much additional data can show up; here the decoder may be able to indicate that the encoded CBOR data item cannot be completed within this limit. Bormann & Hoffman Expires 3 April 2021 [Page 73] Internet-Draft CBOR September 2020 * Syntax error: The input data are not consistent with the requirements of the CBOR encoding, and this cannot be remedied by adding (or removing) data at the end. In Appendix C, errors of the first kind are addressed in the first paragraph/bullet list (requiring "no bytes are left"), and errors of the second kind are addressed in the second paragraph/bullet list (failing "if n bytes are no longer available"). Errors of the third kind are identified in the pseudocode by specific instances of calling fail(), in order: * a reserved value is used for additional information (28, 29, 30) * major type 7, additional information 24, value < 32 (incorrect) * incorrect substructure of indefinite length byte/text string (may only contain definite length strings of the same major type) * "break" stop code (mt=7, ai=31) occurs in a value position of a map or except at a position directly in an indefinite length item where also another enclosed data item could occur * additional information 31 used with major type 0, 1, or 6 F.1. Examples for CBOR data items that are not well-formed This subsection shows a few examples for CBOR data items that are not well-formed. Each example is a sequence of bytes each shown in hexadecimal; multiple examples in a list are separated by commas. Examples for well-formedness error kind 1 (too much data) can easily be formed by adding data to a well-formed encoded CBOR data item. Similarly, examples for well-formedness error kind 2 (too little data) can be formed by truncating a well-formed encoded CBOR data item. In test suites, it may be beneficial to specifically test with incomplete data items that would require large amounts of addition to be completed (for instance by starting the encoding of a string of a very large size). A premature end of the input can occur in a head or within the enclosed data, which may be bare strings or enclosed data items that are either counted or should have been ended by a "break" stop code. * End of input in a head: 18, 19, 1a, 1b, 19 01, 1a 01 02, 1b 01 02 03 04 05 06 07, 38, 58, 78, 98, 9a 01 ff 00, b8, d8, f8, f9 00, fa 00 00, fb 00 00 00 Bormann & Hoffman Expires 3 April 2021 [Page 74] Internet-Draft CBOR September 2020 * Definite length strings with short data: 41, 61, 5a ff ff ff ff 00, 5b ff ff ff ff ff ff ff ff 01 02 03, 7a ff ff ff ff 00, 7b 7f ff ff ff ff ff ff ff 01 02 03 * Definite length maps and arrays not closed with enough items: 81, 81 81 81 81 81 81 81 81 81, 82 00, a1, a2 01 02, a1 00, a2 00 00 00 * Tag number not followed by tag content: c0 * Indefinite length strings not closed by a "break" stop code: 5f 41 00, 7f 61 00 * Indefinite length maps and arrays not closed by a "break" stop code: 9f, 9f 01 02, bf, bf 01 02 01 02, 81 9f, 9f 80 00, 9f 9f 9f 9f 9f ff ff ff ff, 9f 81 9f 81 9f 9f ff ff ff A few examples for the five subkinds of well-formedness error kind 3 (syntax error) are shown below. Subkind 1: * Reserved additional information values: 1c, 1d, 1e, 3c, 3d, 3e, 5c, 5d, 5e, 7c, 7d, 7e, 9c, 9d, 9e, bc, bd, be, dc, dd, de, fc, fd, fe, Subkind 2: * Reserved two-byte encodings of simple values: f8 00, f8 01, f8 18, f8 1f Subkind 3: * Indefinite length string chunks not of the correct type: 5f 00 ff, 5f 21 ff, 5f 61 00 ff, 5f 80 ff, 5f a0 ff, 5f c0 00 ff, 5f e0 ff, 7f 41 00 ff * Indefinite length string chunks not definite length: 5f 5f 41 00 ff ff, 7f 7f 61 00 ff ff Subkind 4: * Break occurring on its own outside of an indefinite length item: ff * Break occurring in a definite length array or map or a tag: 81 ff, 82 00 ff, a1 ff, a1 ff 00, a1 00 ff, a2 00 00 ff, 9f 81 ff, 9f 82 9f 81 9f 9f ff ff ff ff Bormann & Hoffman Expires 3 April 2021 [Page 75] Internet-Draft CBOR September 2020 * Break in indefinite length map would lead to odd number of items (break in a value position): bf 00 ff, bf 00 00 00 ff Subkind 5: * Major type 0, 1, 6 with additional information 31: 1f, 3f, df Appendix G. Changes from RFC 7049 As discussed in the introduction, this document is a revised edition of RFC 7049, with editorial improvements, added detail, and fixed errata. This document formally obsoletes RFC 7049, while keeping full compatibility of the interchange format from RFC 7049. This document does not create a new version of the format. G.1. Errata processing, clerical changes The two verified errata on RFC 7049, EID 3764 and EID 3770, concerned two encoding examples in the text that have been corrected (Section 3.4.3: "29" -> "49", Section 5.5: "0b000_11101" -> "0b000_11001"). Also, RFC 7049 contained an example using the numeric value 24 for a simple value (EID 5917), which is not well- formed; this example has been removed. Errata report 5763 pointed to an accident in the wording of the definition of tags; this was resolved during a re-write of Section 3.4. Errata report 5434 pointed out that the UBJSON example in Appendix E no longer complied with the version of UBJSON current at the time of submitting the report. It turned out that the UBJSON specification had completely changed since 2013; this example therefore also was removed. Further errata reports (4409, 4963, 4964) complained that the map key sorting rules for canonical encoding were onerous; these led to a reconsideration of the canonical encoding suggestions and replacement by the deterministic encoding suggestions (described below). An editorial suggestion in errata report 4294 was also implemented (improved symmetry by adding "Second value" to a comment to the last example in Section 3.2.2). Other more clerical changes include: * use of new RFCXML functionality [RFC7991]; * explain some more of the notation used; * updated references, e.g. for RFC4627 to [RFC8259] in many places, for CNN-TERMS to [RFC7228]; added missing reference to [IEEE754] (importing required definitions) and updated to [ECMA262]; added a reference to [RFC8618] that further illustrates the discussion in Appendix E; Bormann & Hoffman Expires 3 April 2021 [Page 76] Internet-Draft CBOR September 2020 * the discussion of diagnostic notation mentions the "Extended Diagnostic Notation" (EDN) defined in [RFC8610] as well as the gap diagnostic notation has in representing NaN payloads; an explanation was added on how to represent indefinite length strings with no chunks; * the addition of this appendix. G.2. Changes in IANA considerations The IANA considerations were generally updated (clerical changes, e.g., now pointing to the CBOR working group as the author of the specification). References to the respective IANA registries have been added to the informative references. Tags in the space from 256 to 32767 (lower half of "1+2") are no longer assigned by First Come First Served; this range is now Specification Required. G.3. Changes in suggestions and other informational components In revising the document, beyond processing errata reports, the WG could use nearly seven years of experience with the use of CBOR in a diverse set of applications. This led to a number of editorial changes, including adding tables for illustration, but also to emphasizing some aspects and de-emphasizing others. A significant addition in this revision is Section 2, which discusses the CBOR data model and its small variations involved in the processing of CBOR. Introducing terms for those (basic generic, extended generic, specific) enables more concise language in other places of the document, but also helps in clarifying expectations on implementations and on the extensibility features of the format. RFC 7049, as a format derived from the JSON ecosystem, was influenced by the JSON number system that was in turn inherited from JavaScript at the time. JSON does not provide distinct integers and floating- point values (and the latter are decimal in the format). CBOR provides binary representations of numbers, which do differ between integers and floating-point values. Experience from implementation and use now suggested that the separation between these two number domains should be more clearly drawn in the document; language that suggested an integer could seamlessly stand in for a floating-point value was removed. Also, a suggestion (based on I-JSON [RFC7493]) was added for handling these types when converting JSON to CBOR, and the use of a specific rounding mechanism has been recommended. Bormann & Hoffman Expires 3 April 2021 [Page 77] Internet-Draft CBOR September 2020 For a single value in the data model, CBOR often provides multiple encoding options. The revision adds a new section Section 4, which first introduces the term "preferred serialization" (Section 4.1) and defines it for various kinds of data items. On the basis of this terminology, the section goes on to discuss how a CBOR-based protocol can define "deterministic encoding" (Section 4.2), which now avoids the RFC 7049 terms "canonical" and "canonicalization". The suggestion of "Core Deterministic Encoding Requirements" Section 4.2.1 enables generic support for such protocol-defined encoding requirements. The present revision further eases the implementation of deterministic encoding by simplifying the map ordering suggested in RFC 7049 to simple lexicographic ordering of encoded keys. A description of the older suggestion is kept as an alternative, now termed "length-first map key ordering" (Section 4.2.3). The terminology for well-formed and valid data was sharpened and more stringently used, avoiding less well-defined alternative terms such as "syntax error", "decoding error" and "strict mode" outside examples. Also, a third level of requirements beyond CBOR-level validity that an application has on its input data is now explicitly called out. Well-formed (processable at all), valid (checked by a validity-checking generic decoder), and expected input (as checked by the application) are treated as a hierarchy of layers of acceptability. The handling of non-well-formed simple values was clarified in text and pseudocode. Appendix F was added to discuss well-formedness errors and provide examples for them. The pseudocode was updated to be more portable and some portability considerations were added. The discussion of validity has been sharpened in two areas. Map validity (handling of duplicate keys) was clarified and the domain of applicability of certain implementation choices explained. Also, while streamlining the terminology for tags, tag numbers, and tag content, discussion was added on tag validity, and the restrictions were clarified on tag content, in general and specifically for tag 1. An implementation note (and note for future tag definitions) was added to Section 3.4 about defining tags with semantics that depend on serialization order. Tag 35 is no longer defined in this updated document; the registration based on the definition in RFC 7049 remains in place. Terminology was introduced in Section 3 for "argument" and "head", simplifying further discussion. Bormann & Hoffman Expires 3 April 2021 [Page 78] Internet-Draft CBOR September 2020 The security considerations were mostly rewritten and significantly expanded; in multiple other places, the document is now more explicit that a decoder cannot simply condone well-formedness errors. Acknowledgements CBOR was inspired by MessagePack. MessagePack was developed and promoted by Sadayuki Furuhashi ("frsyuki"). This reference to MessagePack is solely for attribution; CBOR is not intended as a version of or replacement for MessagePack, as it has different design goals and requirements. The need for functionality beyond the original MessagePack Specification became obvious to many people at about the same time around the year 2012. BinaryPack is a minor derivation of MessagePack that was developed by Eric Zhang for the binaryjs project. A similar, but different, extension was made by Tim Caswell for his msgpack-js and msgpack-js-browser projects. Many people have contributed to the discussion about extending MessagePack to separate text string representation from byte string representation. The encoding of the additional information in CBOR was inspired by the encoding of length information designed by Klaus Hartke for CoAP. This document also incorporates suggestions made by many people, notably Dan Frost, James Manger, Jeffrey Yasskin, Joe Hildebrand, Keith Moore, Laurence Lundblade, Matthew Lepinski, Michael Richardson, Nico Williams, Peter Occil, Phillip Hallam-Baker, Ray Polk, Stuart Cheshire, Tim Bray, Tony Finch, Tony Hansen, and Yaron Sheffer. Benjamin Kaduk provided an extensive review during IESG processing. Éric Vyncke, Erik Kline, Robert Wilton, and Roman Danyliw provided further IESG comments, which included an IoT directorate review by Eve Schooler. Authors' Addresses Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Bormann & Hoffman Expires 3 April 2021 [Page 79] Internet-Draft CBOR September 2020 Paul Hoffman ICANN Email: paul.hoffman@icann.org Bormann & Hoffman Expires 3 April 2021 [Page 80] ./draft-ietf-6tisch-enrollment-enhanced-beacon-14.txt0000644000764400076440000006627013624036454021744 0ustar iustyiusty 6tisch Working Group D. Dujovne Internet-Draft Universidad Diego Portales Intended status: Standards Track M. Richardson Expires: 24 August 2020 Sandelman Software Works 21 February 2020 IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information draft-ietf-6tisch-enrollment-enhanced-beacon-14 Abstract In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a Time- Slotted Channel Hopping (TSCH) network transmit Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon in order to conserve use of broadcast opportunities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 August 2020. Copyright Notice Copyright (c) 2020 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 (https://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 Dujovne & Richardson Expires 24 August 2020 [Page 1] Internet-Draft IE for ICMPv6 February 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Use of BCP 14 Terminology . . . . . . . . . . . . . . . . 2 1.2. Layer-2 Synchronization . . . . . . . . . . . . . . . . . 3 1.3. Layer-3 synchronization: IPv6 Router Solicitations and Advertisements . . . . . . . . . . . . . . . . . . . . . 3 1.4. Layer-2 Selection . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction [RFC7554] describes the use of the Time-Slotted Channel Hopping (TSCH) mode of [ieee802154]. In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a Time- Slotted Channel Hopping (TSCH) network transmit Enhanced Beacon (EB) frames during broadcast slots in order to announce the time and channel schedule. This document defines a new IETF Information Element (IE) subtype to place into the Enhanced Beacon (EB) to provide join and enrollment information to prospective pledges in a more efficient way. The following sub-sections explain the problem being solved, which justify carrying the join and enrollement information in the EB. 1.1. Use of BCP 14 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Dujovne & Richardson Expires 24 August 2020 [Page 2] Internet-Draft IE for ICMPv6 February 2020 Other terminology can be found in [I-D.ietf-6tisch-architecture] in section 2.1. 1.2. Layer-2 Synchronization As explained in section 6 of [RFC8180], the Enhanced Beacon (EB) has a number of purposes: synchronization of the Absolute Slot Number (ASN) and Join Metric, carrying the timeslot template identifier, carrying the channel hopping sequence identifier, and indicating the TSCH SlotFrame. An EB announces the existence of a TSCH network, and of the nodes already joined to that network. Receiving an EB allows a Joining Node (pledge) to learn about the network and synchronize to it. The EB may also be used as a means for a node already part of the network to re-synchronize [RFC7554]. There are a limited number of timeslots designated as broadcast slots by each router in the network. Considering 10ms slots and a slot- frame length of 100, these slots are rare and could result in only 1 slot per second for broadcasts, which needs to be used for the beacon. Additional broadcasts for Router Advertisements (RA), or Neighbor Discovery (ND) could even more scarce. 1.3. Layer-3 synchronization: IPv6 Router Solicitations and Advertisements At layer 3, [RFC4861] defines a mechanism by which nodes learn about routers by receiving multicast Router Advertisements (RA). If no RA is received within a set time, then a Router Solicitation (RS) may be transmitted as a multicast, to which an RA will be received, usually unicast. Although [RFC6775] reduces the amount of multicast necessary to do address resolution via Neighbor Solicitation (NS) messages, it still requires multicast of either RAs or RSes. This is an expensive operation for two reasons: there are few multicast timeslots for unsolicited RAs; and if a pledge node does not receive an RA, and decides to transmit an RS, a broadcast aloha slot (see [RFC7554] section A.5) is consumed with unencrypted traffic. [RFC6775] already allows for a unicast reply to such an RS. This is a particularly acute issue for the join process for the following reasons: 1. Use of a multicast slot by even a non-malicious unauthenticated node for a Router Solicitation (RS) may overwhelm that time slot. Dujovne & Richardson Expires 24 August 2020 [Page 3] Internet-Draft IE for ICMPv6 February 2020 2. It may require many seconds of on-time before a new pledge receives a Router Advertisement (RA) that it can use. 3. A new pledge may have to receive many Enhanced Beacons (EB) before it can pick an appropriate network and/or closest Join Assistant to attach to. If it must remain in the receive state for an RA as well as find the Enhanced Beacon (EB), then the process may take dozens of seconds, even minutes for each enrollment attempt that it needs to make. 1.4. Layer-2 Selection In a complex Low-power and Lossy Networks (LLN), multiple LLNs may be connected together by backbone routers ( technology such as [I-D.ietf-6lo-backbone-router]), resulting in an area that is serviced by multiple distinct Layer-2 instances. These are called Personal Area Networks (PAN). Each instance will have a separate Layer-2 security profile, and will be distinguished by a different PANID. The PANID is part of the [ieee802154] layer-2 header: it is a 16-bit value which is chosen to be unique, and it contributes context to the layer-2 security mechanisms. The PANID provides a context similar to the ESSID does in 802.11 networking, and can be conceived of in a similar fashion as the 802.3 ethernet VLAN tag in that it provides context for all layer-2 addresses. A device which is already enrolled in a network may find after a long sleep that it needs to resynchronize to the Layer 2 network. The enrollment keys that it has will be specific to a PANID, but it may have more than one set of keys. Such a device may wish to connect to a PAN that is experiencing less congestion, or which has a shalower ([RFC6550]) Routing Protocol for LLNs (RPL) tree. It may even observe PANs for which it does not have keys, but which is believes it may have credentials that would allow it to join. In order to identify which PANs are part of the same backbone network, the network ID is introduced in this extension. PANs that are part of the same backbone will be configured to use the same network ID. For [RFC6550] RPL networks, configuration of the network ID can be done with an configuration option, which is the subject of future work. In order to provide some input to the choice of which PAN to use, the PAN priority field has been added. This lists the relative priority for the PAN among different PANs. Every Enhanced Beacon from a given PAN will likely have the same PAN priority. Determination of the the PAN priority is the subject of future work; but it is expected that it will be calculated by an algorithm in the 6LBR, possibly involving communication between 6LBRs over the backbone network. Dujovne & Richardson Expires 24 August 2020 [Page 4] Internet-Draft IE for ICMPv6 February 2020 The [RFC6550] parent selection process can only operate within a single PAN, because it depends upon receiving RPL DIO messages from all available parents. As part of the PAN selection process, the device may wish to know how deep in the LLN mesh it will be if it joins a particular PAN, and the rank priority field provides an estimation of what the rank of each announcer is. Once the device synchronizes to a particular PAN's TSCH schedule then it may receive DIOs that are richer in their diversity than this value. How this value will be used in practice is the subject of future research, and the interpretation of this value of the structure is considered experimental. 2. Protocol Definition [RFC8137] creates a registry for new IETF IE subtypes. This document allocates a new subtype. The new IE subtype structure is as follows. As explained in [RFC8137] the length of the Sub-Type Content can be calculated from the container, so no length information is necessary. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD-XXX |R|P| res | proxy prio | rank priority | +-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+ | pan priority | | +---------------+ + | Join Proxy Interface-ID | + (present if P=1) + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ + | network ID | + variable length, up to 16 bytes + ~ ~ + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ Figure 1: IE subtype structure res: reserved bits MUST be ignored upon receipt, and SHOULD be set to 0 when sending. Dujovne & Richardson Expires 24 August 2020 [Page 5] Internet-Draft IE for ICMPv6 February 2020 R: The Router Advertisement R-flag is set if the sending node will act as a Router for host-only nodes relying on stateless address auto-configuration (SLAAC) to get their global IPv6 address. Those hosts MUST send a unicast Router Solicitation message in order to receive a RA with the Prefix Information Option. In most cases, every node sending a beacon will set this flag, and in a typical mesh, this will be every single node. When this bit is not set, it might indicate that this node may be under provisioned, or may have no additional slots for additional nodes. This could make this node more interesting to an attacker. P: If the Proxy Address P-flag is set, then the Join Proxy Interface ID bit field is present. Otherwise, it is not provided. This bit only indicates if another part of the structure is present, and has little security or privacy impact. proxy priority (proxy prio): This field indicates the willingness of the sender to act as join proxy. Lower value indicates greater willingness to act as a Join Proxy as described in [I-D.ietf-6tisch-minimal-security]. Values range from 0x00 (most willing) to 0x7e (least willing). A priority of 0x7f indicates that the announcer should never be considered as a viable enrollment proxy. Only unenrolled pledges look at this value. Lower values in this field indicate that the transmitter may have more capacity to handle unencrypted traffic. A higher value may indicate that the transmitter is low on neighbor cache entries, or other resources. Ongoing work such as [I-D.ietf-roll-enrollment-priority] documents one way to set this field. rank priority: The rank "priority" is set by the IPv6 LLN Router (6LR) which sent the beacon and is an indication of how willing this 6LR is to serve as an RPL [RFC6550] parent within a particular network ID. Lower values indicate more willingness, and higher values indicate less willingness. This value is calculated by each 6LR according to algorithms specific to the routing metrics used by the RPL ([RFC6550]). The exact process is a subject of significant research work. It will typically be calculated from the RPL rank, and it may include some modifications based upon current number of children, or number of neighbor cache entries available. Pledges MUST ignore this value. It helps enrolled devices only to compare connection points. An attacker can use this value to determine which nodes are potentially more interesting. Nodes which are less willingness to Dujovne & Richardson Expires 24 August 2020 [Page 6] Internet-Draft IE for ICMPv6 February 2020 be parents likely have more traffic, and an attacker could use this information to determine which nodes would be more interesting to attack or disrupt. pan priority: The pan priority is a value set by the Destination- Oriented Directed Acyclic Graph (DODAG) root (see [RFC6550], typically, the 6LBR) to indicate the relative priority of this LLN compared to those with different PANIDs that the operator might control. This value may be used as part of the enrollment priority, but typically is used by devices which have already enrolled, and need to determine which PAN to pick when resuming from a long sleep. Unenrolled pledges MAY consider this value when selecting a PAN to join. Enrolled devices MAY consider this value when looking for an eligible parent device. Lower values indicate a higher willingness to accept new nodes. An attacker can use this value, along with the observed PANID in the Beacon to determine which PANIDs have more network resources, and may have more interesting traffic. Join Proxy Interface ID: If the P bit is set, then 64 bits (8 bytes) of address are present. This field provides the Interface ID (IID) of the Link-Local address of the Join Proxy. The associated prefix is well-known as fe80::/64. If this field is not present, then IID is derived from the layer-2 address of the sender as per SLAAC ([RFC4662]). This field communicates the Interface ID bits that should be used for this node's layer-3 address, if it should not be derived from the layer-2 address. Communication with the Join Proxy occurs in the clear. This field avoids the need for an additional service- discovery process for the case where the L3 address is not derived from the L2 address. An attacker will see both L2 and L3 addresses, so this field provides no new information. network ID: This is a variable length field, up to 16-bytes in size that uniquely identifies this network, potentially among many networks that are operating in the same frequencies in overlapping physical space. The length of this field can be calculated as being whatever is left in the Information Element. In a 6tisch network, where RPL [RFC6550] is used as the mesh routing protocol, the network ID can be constructed from a truncated SHA256 hash of the prefix (/64) of the network. This will be done by the RPL DODAG root and communicated by the RPL Configuration Option payloads, so it is not calculated more than once. This is just a suggestion for a default algorithm: it may be set in any convenience way that results in a non-identifing Dujovne & Richardson Expires 24 August 2020 [Page 7] Internet-Draft IE for ICMPv6 February 2020 value. In some LLNs where multiple PANIDs may lead to the same management device (the Join Registrar/Coordinator - JRC), then a common value that is the same across all the PANs MUST be configured. Pledges that see the same networkID will not waste time attempting to enroll multiple times with the same network that when the network has multiple attachment points. If the network ID is derived as suggested, then it will be an opaque, seemingly random value, and will not directly reveal any information about the network. An attacker can match this value across many transmissions to map the extent of a network beyond what the PANID might already provide. 3. Security Considerations All of the contents of this Information Element are transmitted in the clear. The content of the Enhanced Beacon is not encrypted. This is a restriction in the cryptographic architecture of the 802.15.4 mechanism. In order to decrypt or do integrity checking of layer-2 frames in TSCH, the TSCH Absolute Slot Number (ASN) is needed. The Enhanced Beacon provides the ASN to new (and long- sleeping) nodes. The sensitivity of each field is described within the description of each field. The Enhanced Beacon is authenticated at the layer-2 level using 802.15.4 mechanisms using the network-wide keying material. Nodes which are enrolled will have the network-wide keying material and can validate the beacon. Pledges which have not yet enrolled are unable to authenticate the beacons, and will be forced to temporarily take the contents on faith. After enrollment, a newly enrolled node will be able to return to the beacon and validate it. In addition to the enrollment and join information described in this document, the Enhanced Beacon contains a description of the TSCH schedule to be used by the transmitter of this packet. The schedule can provide an attacker with a list of channels and frequencies on which communication will occur. Knowledge of this can help an attacker to more efficiently jam communications, although there is future work being considered to make some of the schedule less visible. Encrypting the schedule does not prevent an attacker from jamming, but rather increases the energy cost of doing that jamming. Dujovne & Richardson Expires 24 August 2020 [Page 8] Internet-Draft IE for ICMPv6 February 2020 4. Privacy Considerations The use of a network ID may reveal information about the network. The use of a SHA256 hash of the DODAGID (see [RFC6550]), rather than using the DODAGID itself directly provides some privacy for the the addresses used within the network, as the DODAGID is usually the IPv6 address of the root of the RPL mesh. An interloper with a radio sniffer would be able to use the network ID to map out the extent of the mesh network. 5. IANA Considerations IANA is asked to assign a new number TBD-XXX from Registry "IEEE Std 802.15.4 IETF IE Subtype IDs" as defined by [RFC8137]. This entry should be called 6tisch-Join-Info, and should refer to this document. Value Subtype-ID Reference ---- ---------- ----------- TBD-XXX 6tisch-Join-Inbfo [this document] 6. Acknowledgements Thomas Watteyne provided extensive editorial comments on the document. Carles Gomez Montenegro generated a detailed review of the document at WGLC. Tim Evens provided a number of useful editorial suggestions. 7. References 7.1. Normative References [BCP14] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", Work in Progress, Internet-Draft, draft-ietf-6tisch-minimal- security-15, 10 December 2019, . [ieee802154] IEEE standard for Information Technology, ., "IEEE Std. Dujovne & Richardson Expires 24 August 2020 [Page 9] Internet-Draft IE for ICMPv6 February 2020 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks", 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.ietf-6lo-backbone-router] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Backbone Router", Work in Progress, Internet-Draft, draft- ietf-6lo-backbone-router-17, 20 February 2020, . [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, Internet-Draft, draft-ietf-6tisch-architecture-28, 29 October 2019, . [I-D.ietf-roll-enrollment-priority] Richardson, M., "Enabling secure network enrollment in RPL Dujovne & Richardson Expires 24 August 2020 [Page 10] Internet-Draft IE for ICMPv6 February 2020 networks", Work in Progress, Internet-Draft, draft-ietf- roll-enrollment-priority-00, 16 September 2019, . [RFC4662] Roach, A. B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, DOI 10.17487/RFC4662, August 2006, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, . Authors' Addresses Diego Dujovne (editor) Universidad Diego Portales Escuela de Informatica y Telecomunicaciones, Av. Ejercito 441 Santiago, Region Metropolitana Chile Phone: +56 (2) 676-8121 Email: diego.dujovne@mail.udp.cl Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Dujovne & Richardson Expires 24 August 2020 [Page 11] ./draft-ietf-detnet-mpls-13.txt0000644000764400076440000022522313740765071015630 0ustar iustyiusty DetNet B. Varga, Ed. Internet-Draft J. Farkas Intended status: Standards Track Ericsson Expires: April 14, 2021 L. Berger LabN Consulting, L.L.C. A. Malis Malis Consulting S. Bryant Futurewei Technologies J. Korhonen October 11, 2020 DetNet Data Plane: MPLS draft-ietf-detnet-mpls-13 Abstract This document specifies the Deterministic Networking data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering encapsulations and mechanisms. This document builds on the DetNet Architecture and Data Plane Framework. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 14, 2021. Copyright Notice Copyright (c) 2020 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 Varga, et al. Expires April 14, 2021 [Page 1] Internet-Draft DetNet MPLS October 2020 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. DetNet MPLS Data Plane Overview . . . . . . . . . . . . . . . 5 3.1. Layers of DetNet Data Plane . . . . . . . . . . . . . . . 5 3.2. DetNet MPLS Data Plane Scenarios . . . . . . . . . . . . 6 4. MPLS-Based DetNet Data Plane Solution . . . . . . . . . . . . 8 4.1. DetNet Over MPLS Encapsulation Components . . . . . . . . 8 4.2. MPLS Data Plane Encapsulation . . . . . . . . . . . . . . 9 4.2.1. DetNet Control Word and the DetNet Sequence Number . 10 4.2.2. S-Labels . . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. F-Labels . . . . . . . . . . . . . . . . . . . . . . 15 4.3. OAM Indication . . . . . . . . . . . . . . . . . . . . . 17 4.4. Flow Aggregation . . . . . . . . . . . . . . . . . . . . 18 4.4.1. Aggregation Via LSP Hierarchy . . . . . . . . . . . . 18 4.4.2. Aggregating DetNet Flows as a new DetNet flow . . . . 19 4.5. Service Sub-Layer Considerations . . . . . . . . . . . . 20 4.5.1. Edge Node Processing . . . . . . . . . . . . . . . . 20 4.5.2. Relay Node Processing . . . . . . . . . . . . . . . . 20 4.6. Forwarding Sub-Layer Considerations . . . . . . . . . . . 21 4.6.1. Class of Service . . . . . . . . . . . . . . . . . . 21 4.6.2. Quality of Service . . . . . . . . . . . . . . . . . 21 5. Management and Control Information Summary . . . . . . . . . 22 5.1. Service Sub-Layer Information Summary . . . . . . . . . . 23 5.1.1. Service Aggregation Information Summary . . . . . . . 24 5.2. Forwarding Sub-Layer Information Summary . . . . . . . . 24 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Varga, et al. Expires April 14, 2021 [Page 2] Internet-Draft DetNet MPLS October 2020 1. Introduction Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. General background and concepts of DetNet can be found in the DetNet Architecture [RFC8655]. The purpose of this document is to describe the use of the MPLS data plane to establish and support DetNet flows. The DetNet Architecture models the DetNet related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service functions such as protection and reordering. At the DetNet data plane a new set of functions (PREOF) provide the service sub-layer specific tasks. The forwarding sub-layer is used to provide forwarding assurance (low loss, assured latency, and limited out-of-order delivery). The use of the functionalities of the DetNet service sub-layer and the DetNet forwarding sub-layer require careful design and control by the controller plane in addition to the DetNet specific use of MPLS encapsulation as specified by this document. This document specifies the DetNet data plane operation and the on- wire encapsulation of DetNet flows over an MPLS-based Packet Switched Network (PSN) using the service reference model. MPLS encapsulation already provides a solid foundation of building blocks to enable the DetNet service and forwarding sub-layer functions. MPLS encapsulated DetNet can be carried over a variety of different network technologies that can provide the DetNet required level of service. However, the specific details of how DetNet MPLS is carried over different network technologies are out of scope of this document. MPLS encapsulated DetNet flows can carry different types of traffic. The details of the types of traffic that are carried in DetNet are also out of scope of this document. An example of IP using DetNet MPLS sub-networks can be found in [I-D.ietf-detnet-ip]. DetNet MPLS may use an associated controller and Operations, Administration, and Maintenance (OAM) functions that are defined outside of this document. Background information common to all data planes for DetNet can be found in the DetNet Data Plane Framework [I-D.ietf-detnet-data-plane-framework]. Varga, et al. Expires April 14, 2021 [Page 3] Internet-Draft DetNet MPLS October 2020 2. Terminology 2.1. Terms Used in This Document This document uses the terminology established in the DetNet architecture [RFC8655] and the DetNet Data Plane Framework [I-D.ietf-detnet-data-plane-framework]. The reader is assumed to be familiar with these documents, any terminology defined therein and basic MPLS related terminologies in [RFC3031]. The following terminology is introduced in this document: F-Label A Detnet "forwarding" label that identifies the LSP used to forward a DetNet flow across an MPLS PSN, i.e., a hop-by-hop label used between label switching routers (LSR). S-Label A DetNet "service" label that is used between DetNet nodes that implement the DetNet service sub-layer functions. An S-Label is used to identify a DetNet flow at DetNet service sub-layer at a receiving DetNet node. A-Label A special case of an S-Label, whose aggregation properties are known only at the aggregation and deaggregation end-points. d-CW A DetNet Control Word (d-CW) is used for sequencing information of a DetNet flow at the DetNet service sub- layer. 2.2. Abbreviations The following abbreviations are used in this document: CoS Class of Service. CW Control Word. DetNet Deterministic Networking. LSR Label Switching Router. MPLS Multiprotocol Label Switching. MPLS-TE Multiprotocol Label Switching - Traffic Engineering. MPLS-TP Multiprotocol Label Switching - Transport Profile. Varga, et al. Expires April 14, 2021 [Page 4] Internet-Draft DetNet MPLS October 2020 OAM Operations, Administration, and Maintenance. PE Provider Edge. PEF Packet Elimination Function. PRF Packet Replication Function. PREOF Packet Replication, Elimination and Ordering Functions. POF Packet Ordering Function. PSN Packet Switched Network. PW PseudoWire. QoS Quality of Service. S-PE Switching Provider Edge. T-PE Terminating Provider Edge. TSN Time-Sensitive Network. 2.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. DetNet MPLS Data Plane Overview 3.1. Layers of DetNet Data Plane MPLS provides a wide range of capabilities that can be utilised by DetNet. A straight forward approach utilizing MPLS for a DetNet service sub-layer is based on the existing pseudowire (PW) encapsulations and by utilizing existing MPLS Traffic Engineering encapsulations and mechanisms. Background on PWs can be found in [RFC3985] and [RFC3031]. Background on MPLS Traffic Engineering can be found in [RFC3272] and [RFC3209]. Varga, et al. Expires April 14, 2021 [Page 5] Internet-Draft DetNet MPLS October 2020 DetNet MPLS . Bottom of Stack . (inner label) +------------+ | Service | d-CW, S-Label (A-Label) +------------+ | Forwarding | F-Label(s) +------------+ Top of Stack . (outer label) . Figure 1: DetNet Adaptation to MPLS Data Plane The DetNet MPLS data plane representation is illustrated in Figure 1. The service sub-layer includes a DetNet control word (d-CW) and an identifying service label (S-Label). The DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in [RFC4385]. An aggregation label (A-Label) is a special case of S-Label used for aggregation. A node operating on a received DetNet flow at the Detnet service sub- layer uses the local context associated with a received S-Label, i.e., a received F-Label, to determine which local DetNet operation(s) are applied to that packet. An S-Label may be taken from the platform label space [RFC3031], making it unique, enabling DetNet flow identification regardless of which input interface or LSP the packet arrives on. It is important to note that S-Label values are driven by the receiver, not the sender. The DetNet forwarding sub-layer is supported by zero or more forwarding labels (F-Labels). MPLS Traffic Engineering encapsulations and mechanisms can be utilized to provide a forwarding sub-layer that is responsible for providing resource allocation and explicit routes. 3.2. DetNet MPLS Data Plane Scenarios Varga, et al. Expires April 14, 2021 [Page 6] Internet-Draft DetNet MPLS October 2020 DetNet MPLS Relay Transit Relay DetNet MPLS End System Node Node Node End System (T-PE) (S-PE) (LSR) (S-PE) (T-PE) +----------+ +----------+ | Appl. |<------------ End to End Service ----------->| Appl. | +----------+ +---------+ +---------+ +----------+ | Service |<--| Service |-- DetNet flow --| Service |-->| Service | +----------+ +---------+ +----------+ +---------+ +----------+ |Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding| +-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+ : Link : / ,-----. \ : Link : / ,-----. \ +........+ +-[ Sub ]-+ +......+ +-[ Sub ]-+ [Network] [Network] `-----' `-----' |<- LSP -->| |<-------- LSP -----------| |<--- LSP -->| |<----------------- DetNet MPLS --------------------->| Figure 2: A DetNet MPLS Network Figure 2 illustrates a hypothetical DetNet MPLS-only network composed of DetNet aware MPLS enabled end systems, operating over a DetNet aware MPLS network. In this figure, the relay nodes are PE devices that define the MPLS LSP boundaries and the transit nodes are LSRs. DetNet end systems and relay nodes understand the particular needs of DetNet flows and provide both DetNet service and forwarding sub-layer functions. In the case of MPLS, DetNet service-aware nodes add, remove and process d-CWs, S-Labels and F-labels as needed. DetNet MPLS nodes provide functionality analogous to T-PEs when they sit at the edge of an MPLS domain, and S-PEs when they are in the middle of an MPLS domain, see [RFC6073]. In a DetNet MPLS network, transit nodes may be DetNet service aware or may be DetNet unaware MPLS Label Switching Routers (LSRs). In this latter case, such LSRs would be unaware of the special requirements of the DetNet service sub-layer, but would still provide traffic engineering functions and the QoS capabilities needed to ensure that the (TE) LSPs meet the service requirements of the carried DetNet flows. The application of DetNet using MPLS supports a number of control plane/management plane types. These types support certain MPLS data plane deployments. For example RSVP-TE, MPLS-TP, or MPLS Segment Routing (when extended to support resource allocation) are all valid MPLS deployment cases. Varga, et al. Expires April 14, 2021 [Page 7] Internet-Draft DetNet MPLS October 2020 Figure 3 illustrates how an end-to-end MPLS-based DetNet service is provided in a more detail. In this figure, the customer end systems, CE1 and CE2, are able to send and receive MPLS encapsulated DetNet flows, and R1, R2 and R3 are relay nodes in the middle of a DetNet network. The 'X' in the end systems, and relay nodes represents potential DetNet compound flow packet replication and elimination points. In this example, service protection is supported utilizing at least two DetNet member flows and TE LSPs. For a unidirectional flow, R1 supports PRF and R3 supports PEF and POF. Note that the relay nodes may change the underlying forwarding sub-layer, for example tunneling MPLS over IEEE 802.1 TSN [I-D.ietf-detnet-mpls-over-tsn], or simply over interconnect network links. DetNet DetNet DetNet Service Transit Transit Service DetNet MPLS | |<-Tnl->| |<-Tnl->| | MPLS End | V 1 V V 2 V | End System | +--------+ +--------+ +--------+ | System +---+ | | R1 |=======| R2 |=======| R3 | | +---+ | X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X | |CE1|========| \ | | X | | / |======|CE2| | | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | | +---+ | |=======| |=======| | +---+ ^ +--------+ +--------+ +--------+ ^ | Relay Node Relay Node Relay Node | | (S-PE) (S-PE) (S-PE) | | | |<---------------------- DetNet MPLS --------------------->| | | |<--------------- End to End DetNet Service -------------->| -------------------------- Data Flow -------------------------> X = Optional service protection (none, PRF, PREOF, PEF/POF) DFx = DetNet member flow x over a TE LSP Figure 3: MPLS-Based Native DetNet 4. MPLS-Based DetNet Data Plane Solution 4.1. DetNet Over MPLS Encapsulation Components To carry DetNet over MPLS the following is required: 1. A method of identifying the MPLS payload type. Varga, et al. Expires April 14, 2021 [Page 8] Internet-Draft DetNet MPLS October 2020 2. A method of identifying the DetNet flow(s) to the processing element. 3. A method of distinguishing DetNet OAM packets from DetNet data packets. 4. A method of carrying the DetNet sequence number. 5. A suitable LSP to deliver the packet to the egress PE. 6. A method of carrying queuing and forwarding indication. In this design an MPLS service label (the S-Label), is similar to a pseudowire (PW) label [RFC3985], and is used to identify both the DetNet flow identity and the payload MPLS payload type satisfying (1) and (2) in the list above. OAM traffic discrimination happens through the use of the Associated Channel method described in [RFC4385]. The DetNet sequence number is carried in the DetNet Control word which carries the Data/OAM discriminator. To simplify implementation and to maximize interoperability two sequence number sizes are supported: a 16 bit sequence number and a 28 bit sequence number. The 16 bit sequence number is needed to support some types of legacy clients. The 28 bit sequence number is used in situations where it is necessary ensure that in high speed networks the sequence number space does not wrap whilst packets are in flight. The LSP used to forward the DetNet packet is not restricted regarding any method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE, MPLS-TP [RFC5921], MPLS-SR [RFC8660], etc.). The LSP (F-Label) label(s) and/or the S-Label may be used to indicate the required queue processing as well as the forwarding parameters. Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. 4.2. MPLS Data Plane Encapsulation Figure 4 illustrates a DetNet data plane MPLS encapsulation. The MPLS-based encapsulation of the DetNet flows is well suited for the scenarios described in [I-D.ietf-detnet-data-plane-framework]. Furthermore, an end-to-end DetNet service i.e., native DetNet deployment (see Section 3.2) is also possible if DetNet end systems are capable of initiating and termination MPLS encapsulated packets. The MPLS-based DetNet data plane encapsulation consists of: Varga, et al. Expires April 14, 2021 [Page 9] Internet-Draft DetNet MPLS October 2020 o DetNet control word (d-CW) containing sequencing information for packet replication and duplicate elimination purposes, and the OAM indicator. o DetNet service Label (S-Label) that identifies a DetNet flow at the receiving DetNet service sub-layer processing node. o Zero or more Detnet MPLS Forwarding label(s) (F-Label) used to direct the packet along the label switched path (LSP) to the next DetNet service sub-layer processing node along the path. When Penultimate Hop Popping is in use there may be no label F-Label in the protocol stack on the final hop. o The necessary data-link encapsulation is then applied prior to transmission over the physical media. DetNet MPLS-based encapsulation +---------------------------------+ | | | DetNet App-Flow | | Payload Packet | | | +---------------------------------+ <--\ | DetNet Control Word | | +---------------------------------+ +--> DetNet data plane | S-Label | | MPLS encapsulation +---------------------------------+ | | [ F-Label(s) ] | | +---------------------------------+ <--/ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+ Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN 4.2.1. DetNet Control Word and the DetNet Sequence Number A DetNet control word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in Figure 5 MUST be present in all DetNet packets containing app-flow data. This format of the d-CW was created in order (1) to allow larger sequence number space to avoid sequence number rollover frequency in some applications and (2) to allow sequence numbering systems that include the value zero as a valid sequence number, which simplifies implementation. Varga, et al. Expires April 14, 2021 [Page 10] Internet-Draft DetNet MPLS October 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DetNet Control Word (bits 0 to 3) Per [RFC4385], MUST be set to zero (0). Sequence Number (bits 4 to 31) An unsigned value implementing the DetNet sequence number. The sequence number space is a circular one with no restriction on initial value. A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet app-flow, i.e., DetNet service. The following sequence number field lengths MUST be supported: 0 bits 16 bits 28 bits The sequence number length MUST be provisioned on a per Detnet service basis via configuration, i.e., via the controller plane described in [I-D.ietf-detnet-data-plane-framework]. A 0 bit sequence number field length indicates that there is no DetNet sequence number used for the flow. When the length is zero, the sequence number field MUST be set to zero (0) on all packets sent for the flow. When the sequence number field length is 16 or 28 bits for a flow, the sequence number MUST be incremented by one for each new app-flow packet sent. When the field length is 16 bits, d-CW bits 4 to 15 MUST be set to zero (0). The values carried in this field can wrap and it is important to note that zero (0) is a valid field value. For example, where the sequence number size is 16 bits, the sequence will contain: 65535, 0, 1, where zero (0) is an ordinary sequence number. Varga, et al. Expires April 14, 2021 [Page 11] Internet-Draft DetNet MPLS October 2020 It is important to note that this document differs from [RFC4448] where a sequence number of zero (0) is used to indicate that the sequence number check algorithm is not used. The sequence number is optionally used during receive processing as described below in Section 4.2.2.2 and Section 4.2.2.3. 4.2.2. S-Labels A DetNet flow at the DetNet service sub-layer is identified by an S-Label. MPLS-aware DetNet end systems and edge nodes, which are by definition MPLS ingress and egress nodes, MUST add (push) and remove (pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY swap S-Label values when processing a DetNet flow, i.e., incoming and outgoing S-Labels of a DetNet flow can be different. S-Label values MUST be provisioned per DetNet service via configuration, i.e., via the controller plane described in [I-D.ietf-detnet-data-plane-framework]. Note that S-Labels provide identification at the downstream DetNet service sub-layer receiver, not the sender. As such, S-Labels MUST be allocated by the entity that controls the service sub-layer receiving node's label space, and MAY be allocated from the platform label space [RFC3031]. Because S-Labels are local to each node rather than being a global identifier within a domain, they must be advertised to their upstream DetNet service-aware peer nodes (i.e., a DetNet MPLS End System or a DetNet Relay or Edge Node) and interpreted in the context of their received F-Label(s). In some PREOF topologies, the node performing replication will be sending to multiple nodes performing PEF or POF, and may need to send different S-Label values for the different member flows for the same DetNet service. An S-Label will normally be at the bottom of the label stack once the last F-Label is removed, immediately preceding the d-CW. To support service sub-layer level OAM, an OAM Associated Channel Header (ACH) [RFC4385] together with a Generic Associated Channel Label (GAL) [RFC5586] MAY be used in place of a d-CW. Similarly, an Entropy Label Indicator/Entropy Label (ELI/EL) [RFC6790] MAY be carried below the S-Label in the label stack in networks where DetNet flows would otherwise receive ECMP treatment. When ELs are used, the same EL value SHOULD be used for all of the packets sent using a specific S-Label to force the flow to follow the same path. However, as outlined in [I-D.ietf-detnet-data-plane-framework] the use of ECMP for DetNet flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows within a DetNet domain. Varga, et al. Expires April 14, 2021 [Page 12] Internet-Draft DetNet MPLS October 2020 When receiving a DetNet MPLS packet, an implementation MUST identify the DetNet service associated with the incoming packet based on the S-Label. When a node is using platform labels for S-Labels, no additional information is needed as the S-label uniquely identifies the DetNet service. In the case where platform labels are not used, zero or more F-Labels proceeding the S-Label MUST be used together with the S-Label to uniquely identify the DetNet service associated with a received packet. The incoming interface MAY also be used together with any present F-Label(s) and the S-Label to uniquely identify an incoming DetNet service, for example, in the case where PHP is used. Note that choice to use platform label space for S-Label or S-Label plus one or more F-Labels to identify DetNet services is a local implementation choice, with one caveat. When one or more F-labels, or incoming interface, is needed together with an S-Label to uniquely identify a service, the controller plane must ensure that incoming DetNet MPLS packets arrive with the needed information (F-label(s) and/or incoming interface) and provision the needed information. The provisioned information MUST then be used to identify incoming DetNet service based on the combination of S-Label and F-Label(s) or incoming interface. The use of platform labels for S-Labels matches other pseudowire encapsulations for consistency but there is no hard requirement in this regard. Implementation details of PREOF functions are out of scope for this document. [IEEE802.1CB-2017] defines equivalent replication and elimination specific aspects, which can be applied to PRF and PEF. 4.2.2.1. Packet Replication Function Processing The Packet Replication Function (PRF) function MAY be supported by an implementation for outgoing DetNet flows. The use of the PRF for a particular DetNet service MUST be provisioned via configuration, i.e., via the controller plane described in [I-D.ietf-detnet-data-plane-framework]. When replication is configured, the same app-flow data will be sent over multiple outgoing DetNet member flows using forwarding sub-layer LSPs. An S-Label value MUST be configured per outgoing member flow. The same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet. 4.2.2.2. Packet Elimination Function Processing Implementations MAY support the Packet Elimination Function (PEF) for received DetNet MPLS flows. When supported, use of the PEF for a particular DetNet service MUST be provisioned via configuration, Varga, et al. Expires April 14, 2021 [Page 13] Internet-Draft DetNet MPLS October 2020 i.e., via the controller plane described in [I-D.ietf-detnet-data-plane-framework]. After a DetNet service is identified for a received DetNet MPLS packet, as described above, if PEF is configured for that DetNet service, duplicate (replicated) instances of a particular sequence number MUST be discarded. The specific mechanisms used for an implementation to identify which received packets are duplicates and which are new is an implementation choice. Note that per Section 4.2.1 the sequence number field length may be 16 or 28 bits, and the field value can wrap. PEF MUST NOT be used with DetNet flows configured with a d-CW sequence number field length of 0 bits. An implementation MAY constrain the maximum number of sequence numbers that are tracked on either a platform-wide or per flow basis. Some implementations MAY support the provisioning of the maximum number of sequence numbers that are tracked on either a platform-wide or per flow basis. 4.2.2.3. Packet Ordering Function Processing A function that is related to in-order delivery is the Packet Ordering Function (POF). Implementations MAY support POF. When supported, use of the POF for a particular DetNet service MUST be provisioned via configuration, i.e., via the controller plane described by [I-D.ietf-detnet-data-plane-framework]. Implementations MAY require that PEF and POF be used in combination. There is no requirement related to the order of execution of the Packet Elimination and Ordering Functions in an implementation. After a DetNet service is identified for a received DetNet MPLS packet, as described above, if POF is configured for that DetNet service, packets MUST be processed in the order indicated in the received d-CW sequence number field, which may not be in the order the packets are received. As defined in Section 4.2.1 the sequence number field length may be 16 or 28 bits, is incremented by one (1) for each new MPLS packet sent for a particular DetNet service, and the field value can wrap. The specific mechanisms used for an implementation to identify the order of received packets is an implementation choice. An implementation MAY constrain the maximum number of out of order packets that can be processed, on either a platform-wide or per flow basis. The number of out of order packets that can be processed also impacts the latency of a flow. The latency impact on the system resources needed to support a specific DetNet flow will need to be evaluated by the controller Varga, et al. Expires April 14, 2021 [Page 14] Internet-Draft DetNet MPLS October 2020 plane based on that flow's traffic specification. An example traffic specification that can be used with MPLS with Traffic Engineering (MPLS-TE) can be found in [RFC2212]. DetNet implementations can use flow-specific requirements (e.g., maximum number of out-of-order packets, maximum latency of the flow) for configuration of POF-related buffers. POF implementation details are out-of-scope for this document and POF configuration parameters are implementation specific. The Controller Plane identifies and sets the POF configuration parameters. 4.2.3. F-Labels F-Labels support the DetNet forwarding sub-layer. F-Labels are used to provide LSP-based connectivity between DetNet service sub-layer processing nodes. 4.2.3.1. Service Sub-Layer Related Processing DetNet MPLS end systems, edge nodes and relay nodes may operate at the DetNet service sub-layer with understanding of DetNet services and their requirements. As mentioned earlier, when operating at this layer such nodes can push, pop or swap (pop then push) S-Labels. In all cases, the F-Label(s) used for a DetNet service are always replaced and the following procedures apply. When sending a DetNet flow, zero or more F-Labels MAY be pushed on top of an S-Label by the node pushing an S-Label. The F-Label(s) to be pushed when sending a particular DetNet service MUST be provisioned per outgoing S-Label via configuration, i.e., via the controller plane discussed in [I-D.ietf-detnet-data-plane-framework]. F-Label(s) can also provide context for an S-Label. To allow for the omission of F-Label(s), an implementation SHOULD also allow an outgoing interface to be configured per S-Label. Note, when PRF is supported, the same app-flow data will be sent over multiple outgoing DetNet member flows using forwarding sub-layer LSPs. This means that implementation may be sending different sets of F-Labels per DetNet member flow, each with a different S-Label. When a single set of F-Labels is provisioned for a particular outgoing S-Label, that set of F-labels MUST be pushed after the S-Label is pushed. The outgoing packet is then forwarded as described below in Section 4.2.3.2. When a single outgoing interface is provisioned, the outgoing packet is then forwarded as described below in Section 4.2.3.2. Varga, et al. Expires April 14, 2021 [Page 15] Internet-Draft DetNet MPLS October 2020 When multiple sets of outgoing F-Labels or interfaces are provisioned for a particular DetNet service (i.e., for PRF), a copy of the outgoing packet, including the pushed member flow-specific S-Label, MUST be made per F-label set and outgoing interface. Each set of provisioned F-Labels are then pushed onto a copy of the packet. Each copy is then forwarded as described below in Section 4.2.3.2. As described in the previous section, when receiving a DetNet MPLS flow, an implementation identifies the DetNet service associated with the incoming packet based on the S-Label. When a node is using platform labels for S-Labels, any F-Labels can be popped and the S-label uniquely identifies the DetNet service. In the case where platform labels are not used, incoming F-Label(s) and, optionally, the incoming interface MUST also be provisioned for a DetNet service. 4.2.3.2. Common F-Label Processing All DetNet aware MPLS nodes process F-Labels as needed to meet the service requirements of the DetNet flow or flows carried in the LSPs represented by the F-Labels. This includes normal push, pop and swap operations. Such processing is essentially the same type of processing provided for TE LSPs, although the specific service parameters, or traffic specification, can differ. When the DetNet service parameters of the DetNet flow or flows carried in an LSP represented by an F-Label can be met by an existing TE mechanism, the forwarding sub-layer processing node MAY be a DetNet unaware, i.e., standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service as defined in, but not limited to, [RFC3209], [RFC3270], [RFC3272], [RFC3473], [RFC4875], [RFC5440], and [RFC8306]. More specifically, as mentioned above, the DetNet forwarding sub- layer provides explicit routes and allocated resources, and F-Labels are used to map to each. Explicit routes are supported based on the topmost (outermost) F-Label that is pushed or swapped and the LSP that corresponds to this label. This topmost (outgoing) label MUST be associated with a provisioned outgoing interface and, for non- point-to-point outgoing interfaces, a next hop LSR. Note that this information MUST be provisioned via configuration or the controller plane. In the previously mentioned special case where there are no added F-labels and the outgoing interface is not a point-to-point interface, the outgoing interface MUST also be associated with a next hop LSR. Resources may be allocated in a hierarchical fashion per LSP that is represented by each F-Label. Each LSP MAY be provisioned with a service parameter that dictates the specific traffic treatment to be received by the traffic carried over that LSP. Implementations of this document MUST ensure that traffic carried over each LSP Varga, et al. Expires April 14, 2021 [Page 16] Internet-Draft DetNet MPLS October 2020 represented by one or more F-Labels receives the traffic treatment provisioned for that LSP. Typical mechanisms used to provide different treatment to different flows includes the allocation of system resources (such as queues and buffers) and provisioning of related parameters (such as shaping, and policing) that may be found in implementations of Resource ReSerVation Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. Support can also be provided via an underlying network technology such IEEE802.1 TSN [I-D.ietf-detnet-mpls-over-tsn]. The specific mechanisms selected by a DetNet node to ensure DetNet service delivery requirements are met for supported DetNet flows is outside the scope of this document. Packets that are marked in a way that do not correspond to allocated resources, e.g., lack a provisioned F-Label, can disrupt the QoS offered to properly reserved DetNet flows by using resources allocated to the reserved flows. Therefore, the network nodes of a DetNet network: o MUST defend the DetNet QoS by discarding or remarking (to an allocated DetNet flow or non-competing non-DetNet flow) packets received that are not associated with a completed resource allocation. o MUST NOT use a DetNet allocated resource, e.g. a queue or shaper reserved for DetNet flows, for any packet that does match the corresponding DetNet flow. o MUST ensure a QoS flow does not exceed its allocated resources or provisioned service level, o MUST ensure a CoS flow or service class does not impact the service delivered to other flows. This requirement is similar to the requirement for MPLS LSRs that CoS LSPs do not impact the resources allocated to TE LSPs, e.g., via [RFC3473]. Subsequent sections provide additional considerations related to CoS (Section 4.6.1), QoS (Section 4.6.2) and aggregation (Section 4.4). 4.3. OAM Indication OAM follows the procedures set out in [RFC5085] with the restriction that only Virtual Circuit Connectivity Verification (VCCV) type 1 is supported. As shown in Figure 3 of [RFC5085] when the first nibble of the d-CW is 0x0 the payload following the d-CW is normal user data. However, when the first nibble of the d-CW is 0x1, the payload that follows Varga, et al. Expires April 14, 2021 [Page 17] Internet-Draft DetNet MPLS October 2020 the d-CW is an OAM payload with the OAM type indicated by the value in the d-CW Channel Type field. The reader is referred to [RFC5085] for a more detailed description of the Associated Channel mechanism, and to the DetNet work on OAM for more information DetNet OAM. Additional considerations on DetNet-specific OAM are subjects for further study. 4.4. Flow Aggregation The ability to aggregate individual flows, and their associated resource control, into a larger aggregate is an important technique for improving scaling of control in the data, management and control planes. The DetNet data plane allows for the aggregation of DetNet flows, to improved scaling. There are two methods of supporting flow aggregation covered in this section. The resource control and management aspects of aggregation (including the configuration of queuing, shaping, and policing) are the responsibility of the DetNet controller plane and is out of scope of this documents. It is also the responsibility of the controller plane to ensure that consistent aggregation methods are used. 4.4.1. Aggregation Via LSP Hierarchy DetNet flows forwarded via MPLS can leverage MPLS-TE's existing support for hierarchical LSPs (H-LSPs), see [RFC4206]. H-LSPs are typically used to aggregate control and resources, they may also be used to provide OAM or protection for the aggregated LSPs. Arbitrary levels of aggregation naturally falls out of the definition for hierarchy and the MPLS label stack [RFC3032]. DetNet nodes which support aggregation (LSP hierarchy) map one or more LSPs (labels) into and from an H-LSP. Both carried LSPs and H-LSPs may or may not use the TC field, i.e., L-LSPs or E-LSPs [RFC3270]. Such nodes will need to ensure that individual LSPs and H-LSPs receive the traffic treatment required to ensure the required DetNet service is preserved. Additional details of the traffic control capabilities needed at a DetNet-aware node may be covered in the new service definitions mentioned above or in separate future documents. Controller plane mechanisms will also need to ensure that the service required on the aggregate flow are provided, which may include the discarding or remarking mentioned in the previous sections. Varga, et al. Expires April 14, 2021 [Page 18] Internet-Draft DetNet MPLS October 2020 4.4.2. Aggregating DetNet Flows as a new DetNet flow An aggregate can be built by layering DetNet flows, including both their S-Label and, when present, F-Labels as shown below: +---------------------------------+ | | | DetNet Flow | | Payload Packet | | | +---------------------------------+ <--\ | DetNet Control Word | | +=================================+ | | S-Label | | +---------------------------------+ | | [ F-Label(s) ] | +----DetNet data plane +---------------------------------+ | | DetNet Control Word | | +=================================+ | | A-Label | | +---------------------------------+ | | F-Label(s) | <--/ +---------------------------------+ | Data-Link | +---------------------------------+ | Physical | +---------------------------------+ Figure 6: DetNet Aggregation as a new DetNet Flow Both the aggregation label, which is referred to as an A-Label, and the individual flow's S-Label have their MPLS S bit set indicating bottom of stack, and the d-CW allows the PREOF to work. An A-Label is a special case of an S-Label, whose properties are known only at the aggregation and deaggregation end-points. It is a property of the A-Label that what follows is a d-CW followed by an MPLS label stack. A relay node processing the A-Label would not know the underlying payload type, and the A-Label would be processed as a normal S-Label. This would only be known to a node that was a peer of the node imposing the S-Label. However there is no real need for it to know the payload type during aggregation processing. As in the previous section, nodes supporting this type of aggregation will need to ensure that individual and aggregated flows receive the traffic treatment required to ensure the required DetNet service is preserved. Also, it is the controller plane's responsibility to Varga, et al. Expires April 14, 2021 [Page 19] Internet-Draft DetNet MPLS October 2020 ensure that the service required on the aggregate flow are properly provisioned. 4.5. Service Sub-Layer Considerations The edge and relay node internal procedures related to PREOF are implementation specific. The order of a packet elimination or replication is out of scope in this specification. It is important that the DetNet layer is configured such that a DetNet node never receives its own replicated packets. If it were to receive such packets the replication function would make the loop more destructive of bandwidth than a conventional unicast loop. Ultimately the TTL in the S-Label will cause the packet to die during a transient loop, but given the sensitivity of applications to packet latency the impact on the DetNet application would be severe. To avoid the problem of a transient forwarding loop, changes to an LSP supporting DetNet MUST be loop-free. 4.5.1. Edge Node Processing A DetNet Edge node operates in the DetNet forwarding sub-layer and service sub-layer. An edge node is responsible for matching incoming packets to the service they require and encapsulating them accordingly. An edge node may perform PRF, PEF, and or POF. Details on encapsulation can be found in Section 4.2; details on PRF can be found in Section 4.2.2.1; details on PEF can be found in Section 4.2.2.2; and details on POF can be found in Section 4.2.2.3. 4.5.2. Relay Node Processing A DetNet Relay node operates in the DetNet forwarding sub-layer and service sub-layer. For DetNet using MPLS forwarding related processing is performed on the F-Label. This processing is done within an extended forwarder function. Whether an incoming DetNet flow receives DetNet specific processing depends on how the forwarding is programmed. Some relay nodes may be DetNet service aware for certain DetNet services, while for other DetNet services these nodes may perform as unmodified LSRs that only understand how to switch MPLS-TE LSPs, i.e., as a transit node, see Section 4.4. Again, this is entirely up to how the forwarding has been programmed. During the elimination and replication process the sequence number of an incoming DetNet packet MUST be preserved and carried in the corresponding outgoing DetNet packet. For example, a relay node that performs both PEF and PRF first performs PEF on incoming packets to create a compound flow. It then performs PRF and copies the app-flow data and the d-CW into packets for each outgoing DetNet member flow. Varga, et al. Expires April 14, 2021 [Page 20] Internet-Draft DetNet MPLS October 2020 The internal design of a relay node is out of scope of this document. However the reader's attention is drawn to the need to make any PREOF state available to the packet processor(s) dealing with packets to which the PREOF functions must be applied, and to maintain that state is such a way that it is available to the packet processor operation on the next packet in the DetNet flow (which may be a duplicate, a late packet, or the next packet in sequence). 4.6. Forwarding Sub-Layer Considerations 4.6.1. Class of Service Class and quality of service, i.e., CoS and QoS, are terms that are often used interchangeably and confused with each other. In the context of DetNet, CoS is used to refer to mechanisms that provide traffic forwarding treatment based on aggregate group basis and QoS is used to refer to mechanisms that provide traffic forwarding treatment based on a specific DetNet flow basis. Examples of existing network level CoS mechanisms include DiffServ which is enabled by IP header differentiated services code point (DSCP) field [RFC2474] and MPLS label traffic class field [RFC5462], and at Layer- 2, by IEEE 802.1p priority code point (PCP). CoS for DetNet flows carried in PWs and MPLS is provided using the existing MPLS Differentiated Services (DiffServ) architecture [RFC3270]. Both E-LSP and L-LSP MPLS DiffServ modes MAY be used to support DetNet flows. The Traffic Class field (formerly the EXP field) of an MPLS label follows the definition of [RFC5462] and [RFC3270]. The Uniform, Pipe, and Short Pipe DiffServ tunneling and TTL processing models are described in [RFC3270] and [RFC3443] and MAY be used for MPLS LSPs supporting DetNet flows. MPLS Explicit Congestion Notification (ECN) MAY also be used as defined in ECN [RFC5129] and updated by [RFC5462]. 4.6.2. Quality of Service In addition to explicit routes, and packet replication and elimination, described in Section 4 above, DetNet provides zero congestion loss and bounded latency and jitter. As described in [RFC8655], there are different mechanisms that may be used separately or in combination to deliver a zero congestion loss service. This includes Quality of Service (QoS) mechanisms at the MPLS layer, that may be combined with the mechanisms defined by the underlying network layer such as 802.1TSN. Quality of Service (QoS) mechanisms for flow specific traffic treatment typically includes a guarantee/agreement for the service, and allocation of resources to support the service. Example QoS Varga, et al. Expires April 14, 2021 [Page 21] Internet-Draft DetNet MPLS October 2020 mechanisms include discrete resource allocation, admission control, flow identification and isolation, and sometimes path control, traffic protection, shaping, policing and remarking. Example protocols that support QoS control include Resource ReSerVation Protocol (RSVP) [RFC2205] (RSVP) and RSVP-TE [RFC3209] and [RFC3473]. The existing MPLS mechanisms defined to support CoS [RFC3270] can also be used to reserve resources for specific traffic classes. A baseline set of QoS capabilities for DetNet flows carried in PWs and MPLS can be provided by MPLS with Traffic Engineering (MPLS-TE) [RFC3209] and [RFC3473]. TE LSPs can also support explicit routes (path pinning). Current service definitions for packet TE LSPs can be found in "Specification of the Controlled Load Quality of Service", [RFC2211], "Specification of Guaranteed Quality of Service", [RFC2212], and "Ethernet Traffic Parameters", [RFC6003]. Additional service definitions are expected in future documents to support the full range of DetNet services. In all cases, the existing label-based marking mechanisms defined for TE-LSPs and even E-LSPs are use to support the identification of flows requiring DetNet QoS. 5. Management and Control Information Summary The specific information needed for the processing of each DetNet service depends on the DetNet node type and the functions being provided on the node. This section summarizes based on the DetNet sub-layer and if the DetNet traffic is being sent or received. All DetNet node types are DetNet forwarding sub-layer aware, while all but transit nodes are service sub-layer aware. This is shown in Figure 2. Much like other MPLS labels, there are a number of alternatives available for DetNet S-Label and F-Label advertisement to an upstream peer node. These include distributed signaling protocols such as RSVP-TE, centralized label distribution via a controller that manages both the sender and the receiver using NETCONF/YANG, BGP, PCEP, etc., and hybrid combinations of the two. The details of the controller plane solution required for the label distribution and the management of the label number space are out of scope of this document. There are particular DetNet considerations and requirements that are discussed in [I-D.ietf-detnet-data-plane-framework]. Conformance language is not used in the summary since it applies to future mechanisms such as those that may be provided in signaling and YANG models, e.g., [I-D.ietf-detnet-yang]. Varga, et al. Expires April 14, 2021 [Page 22] Internet-Draft DetNet MPLS October 2020 5.1. Service Sub-Layer Information Summary The following summarizes the information that is needed on service sub-layer aware nodes that transmit DetNet MPLS traffic, on a per service basis: o App-Flow identification information, e.g., IP information as defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information is not needed on DetNet relay nodes. o The sequence number length to be used for the service. Valid values include 0, 16 and 28 bits. 0 bits cannot be used when PEF or POF is configured for the service. o If PRF is to be provided for the service. o The outgoing S-Label for each of the service's outgoing DetNet (member) flows. o The forwarding sub-layer information associated with the output of the service sub-layer. Note that when the PRF function is provisioned, this information is per DetNet member flow. Logically the forwarding sub-layer information is a pointer to further details of transmission of Detnet flows at the forwarding sub-layer. The following summarizes the information that is needed on service sub-layer aware nodes that receive DetNet MPLS traffic, on a per service basis: o The forwarding sub-layer information associated with the input of the service sub-layer. Note that when the PEF function is provisioned, this information is per DetNet member flow. Logically the forwarding sub-layer information is a pointer to further details of the reception of Detnet flows at the forwarding sub-layer or A-Label. o The incoming S-Label for the service. o If PEF or POF is to be provided for the service. o The sequence number length to be used for the service. Valid values included 0, 16 and 28 bits. 0 bits cannot be used when PEF or POF are configured for the service. o App-Flow identification information, e.g., IP information as defined in [I-D.ietf-detnet-ip-over-mpls]. Note, this information is not needed on DetNet relay nodes. Varga, et al. Expires April 14, 2021 [Page 23] Internet-Draft DetNet MPLS October 2020 5.1.1. Service Aggregation Information Summary Nodes performing aggregation using A-Labels, per Section Section 4.4.2, require the additional information summarized in this section. The following summarizes the additional information that is needed on a node that sends aggregated flows using A-Labels: o The S-Labels or F-Labels that are to be carried over each aggregated service. o The A-Label associated with each aggregated service. o The other S-Label information summarized above. On the receiving node, the A-Label provides the forwarding context of an incoming interface or an F-Label and is used in subsequent service or forwarding sub-layer receive processing, as appropriated. The related additional configuration that may be provided is discussed elsewhere in this section. 5.2. Forwarding Sub-Layer Information Summary The following summarizes the information that is needed on forwarding sub-layer aware nodes that send DetNet MPLS traffic, on a per forwarding sub-layer flow basis: o The outgoing F-Label stack to be pushed. The stack may include H-LSP labels. o The traffic parameters associated with a specific label in the stack. Note that there may be multiple sets of traffic parameters associated with specific labels in the stack, e.g., when H-LSPs are used. o Outgoing interface and, for unicast traffic, the next hop information. o Sub-network specific parameters on a technology specific basis. For example, see [I-D.ietf-detnet-mpls-over-tsn]. The following summarizes the information that is needed on forwarding sub-layer aware nodes that receive DetNet MPLS traffic, on a per forwarding sub-layer flow basis: o The incoming interface. For some implementations and deployment scenarios, this information may not be needed. Varga, et al. Expires April 14, 2021 [Page 24] Internet-Draft DetNet MPLS October 2020 o The incoming F-Label stack to be popped. The stack may include H-LSP labels. o How the incoming forwarding sub-layer flow is to be handled, i.e., forwarded as a transit node, or provided to the service sub-layer. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow-specific resources needed to provided the traffic treatment needed to meet each flow's service requirements. This applies for aggregated and individual flows. 6. Security Considerations Detailed security considerations for DetNet are cataloged in [I-D.ietf-detnet-security], and more general security considerations are described in [RFC8655]. This section considers exclusively security considerations which are specific to the DetNet MPLS data plane. The considerations raised related to MPLS networks in general in [RFC5920] are equally applicable to the the DetNet MPLS data plane. Security aspects which are unique to DetNet are those whose aim is to protect the support of specific quality of service aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. Achieving such loss rates and bounded latency may not be possible in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 that can arbitrarily drop or delay any or all traffic. In order to present meaningful security considerations, we consider a somewhat weaker attacker who does not control the physical links of the DetNet domain, but may have the ability to control a network node within the boundary of the DetNet domain. An additional consideration for the DetNet data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means are provided by the underlying technology. For example, encryption may be used, such as that provided by IPsec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. MPLS doesn't provide any native security services to account for confidentiality and integrity. From a data plane perspective this document does not add or modify any application header information. Varga, et al. Expires April 14, 2021 [Page 25] Internet-Draft DetNet MPLS October 2020 At the management and control level DetNet flows are identified on a per-flow basis, which may provide controller plane attackers with additional information about the data flows (when compared to controller planes that do not include per-flow identification). This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet service, provisions can be made against DOS attacks and delay attacks. To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices is prevented or mitigated through the use of existing mechanisms, for example by policing and shaping incoming traffic. To prevent DetNet packets having their delay manipulated by an external entity, precautions need to be taken to ensure that all devices on an LSP are those intended to be there by the network operator and that they are well behaved. In addition to physical security, technical methods such as authentication and authorization of network equipment and the instrumentation and monitoring of the LSP packet delay may be used. If a delay attack is suspected, traffic may be moved to an alternate path, for example through changing the LSP or management of the PREOF configuration. 7. IANA Considerations This document makes no IANA requests. 8. Acknowledgements The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo and Carlos J. Bernardos for their various contributions to this work. 9. Contributors RFC7322 limits the number of authors listed on the front page of a draft to a maximum of 5. The editor wishes to thank and acknowledge the following author for contributing text to this draft. Don Fedyk LabN Consulting, L.L.C. Email: dfedyk@labn.net Varga, et al. Expires April 14, 2021 [Page 26] Internet-Draft DetNet MPLS October 2020 10. References 10.1. Normative References [I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- data-plane-framework-06 (work in progress), May 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, DOI 10.17487/RFC2211, September 1997, . [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, DOI 10.17487/RFC2212, September 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, . [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, . Varga, et al. Expires April 14, 2021 [Page 27] Internet-Draft DetNet MPLS October 2020 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, . [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, . [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, . [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, . [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Varga, et al. Expires April 14, 2021 [Page 28] Internet-Draft DetNet MPLS October 2020 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 10.2. Informative References [I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet-ip-07 (work in progress), July 2020. [I-D.ietf-detnet-ip-over-mpls] Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- detnet-ip-over-mpls-08 (work in progress), September 2020. [I-D.ietf-detnet-mpls-over-tsn] Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over-tsn-03 (work in progress), June 2020. [I-D.ietf-detnet-security] Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", draft-ietf- detnet-security-12 (work in progress), October 2020. [I-D.ietf-detnet-yang] Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Li, Z., and R. Rahman, "Deterministic Networking (DetNet) Configuration YANG Model", draft-ietf-detnet-yang-07 (work in progress), July 2020. [IEEE802.1AE-2018] IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC Security (MACsec)", 2018, . [IEEE802.1CB-2017] IEEE Standards Association, "IEEE Std 802.1CB-2017 Frame Replication and Elimination for Reliability", 2017, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . Varga, et al. Expires April 14, 2021 [Page 29] Internet-Draft DetNet MPLS October 2020 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, . [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, . [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, . Varga, et al. Expires April 14, 2021 [Page 30] Internet-Draft DetNet MPLS October 2020 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010, . [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, . [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . Authors' Addresses Balazs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com Janos Farkas Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: janos.farkas@ericsson.com Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Varga, et al. Expires April 14, 2021 [Page 31] Internet-Draft DetNet MPLS October 2020 Andrew G. Malis Malis Consulting Email: agmalis@gmail.com Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Jouni Korhonen Email: jouni.nospam@gmail.com Varga, et al. Expires April 14, 2021 [Page 32] ./draft-ietf-6tisch-minimal-security-15.txt0000644000764400076440000040171613573663750020077 0ustar iustyiusty 6TiSCH Working Group M. Vucinic, Ed. Internet-Draft Inria Intended status: Standards Track J. Simon Expires: June 12, 2020 Analog Devices K. Pister University of California Berkeley M. Richardson Sandelman Software Works December 10, 2019 Constrained Join Protocol (CoJP) for 6TiSCH draft-ietf-6tisch-minimal-security-15 Abstract This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Vucinic, et al. Expires June 12, 2020 [Page 1] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 This Internet-Draft will expire on June 12, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Provisioning Phase . . . . . . . . . . . . . . . . . . . . . 5 4. Join Process Overview . . . . . . . . . . . . . . . . . . . . 7 4.1. Step 1 - Enhanced Beacon . . . . . . . . . . . . . . . . 8 4.2. Step 2 - Neighbor Discovery . . . . . . . . . . . . . . . 9 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution . . . 9 4.4. The Special Case of the 6LBR Pledge Joining . . . . . . . 10 5. Link-layer Configuration . . . . . . . . . . . . . . . . . . 10 5.1. Distribution of Time . . . . . . . . . . . . . . . . . . 11 6. Network-layer Configuration . . . . . . . . . . . . . . . . . 12 6.1. Identification of Unauthenticated Traffic . . . . . . . . 13 7. Application-level Configuration . . . . . . . . . . . . . . . 14 7.1. Statelessness of the JP . . . . . . . . . . . . . . . . . 15 7.2. Recommended Settings . . . . . . . . . . . . . . . . . . 16 7.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Constrained Join Protocol (CoJP) . . . . . . . . . . . . . . 19 8.1. Join Exchange . . . . . . . . . . . . . . . . . . . . . . 20 8.2. Parameter Update Exchange . . . . . . . . . . . . . . . . 21 8.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 8.4. CoJP Objects . . . . . . . . . . . . . . . . . . . . . . 25 8.5. Recommended Settings . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11.1. CoJP Parameters Registry . . . . . . . . . . . . . . . . 42 11.2. CoJP Key Usage Registry . . . . . . . . . . . . . . . . 43 11.3. CoJP Unsupported Configuration Code Registry . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 Vucinic, et al. Expires June 12, 2020 [Page 2] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . 46 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Lightweight Implementation Option . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction This document defines a "secure join" solution for a new device, called "pledge", to securely join a 6TiSCH network. The term "secure join" refers to network access authentication, authorization and parameter distribution, as defined in [I-D.ietf-6tisch-architecture]. The Constrained Join Protocol (CoJP) defined in this document handles parameter distribution needed for a pledge to become a joined node. Mutual authentication during network access and implicit authorization are achieved through the use of a secure channel, as configured by this document. This document also specifies a configuration of different layers of the 6TiSCH protocol stack that reduces the Denial of Service (DoS) attack surface during the join process. This document presumes a 6TiSCH network as described by [RFC7554] and [RFC8180]. By design, nodes in a 6TiSCH network [RFC7554] have their radio turned off most of the time, to conserve energy. As a consequence, the link used by a new device for joining the network has limited bandwidth [RFC8180]. The secure join solution defined in this document therefore keeps the number of over-the-air exchanges to a minimum. The micro-controllers at the heart of 6TiSCH nodes have a small amount of code memory. It is therefore paramount to reuse existing protocols available as part of the 6TiSCH stack. At the application layer, the 6TiSCH stack already relies on CoAP [RFC7252] for web transfer, and on OSCORE [RFC8613] for its end-to-end security. The secure join solution defined in this document therefore reuses those two protocols as its building blocks. CoJP is a generic protocol that can be used as-is in all modes of IEEE Std 802.15.4 [IEEE802.15.4], including the Time-Slotted Channel Hopping (TSCH) mode 6TiSCH is based on. CoJP may as well be used in other (low-power) networking technologies where efficiency in terms of communication overhead and code footprint is important. In such a case, it may be necessary to define configuration parameters specific to the technology in question, through companion documents. The overall process described in Section 4 and the configuration of the stack is specific to 6TiSCH. Vucinic, et al. Expires June 12, 2020 [Page 3] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 CoJP assumes the presence of a Join Registrar/Coordinator (JRC), a central entity. The configuration defined in this document assumes that the pledge and the JRC share a unique symmetric cryptographic key, called PSK (pre-shared key). The PSK is used to configure OSCORE to provide a secure channel to CoJP. How the PSK is installed is out of scope of this document: this may happen during the provisioning phase or by a key exchange protocol that may precede the execution of CoJP. When the pledge seeks admission to a 6TiSCH network, it first synchronizes to it, by initiating the passive scan defined in [IEEE802.15.4]. The pledge then exchanges CoJP messages with the JRC; for this end-to-end communication to happen, messages are forwarded by nodes already part of the 6TiSCH network, called Join Proxies. The messages exchanged allow the JRC and the pledge to mutually authenticate, based on the properties provided by OSCORE. They also allow the JRC to configure the pledge with link-layer keying material, short identifier and other parameters. After this secure join process successfully completes, the joined node can interact with its neighbors to request additional bandwidth using the 6top Protocol [RFC8480] and start sending application traffic. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The reader is expected to be familiar with the terms and concepts defined in [I-D.ietf-6tisch-architecture], [RFC7252], [RFC8613], and [RFC8152]. The specification also includes a set of informative specifications using the Concise data definition language (CDDL) [I-D.ietf-cbor-cddl]. The following terms defined in [I-D.ietf-6tisch-architecture] are used extensively throughout this document: o pledge o joined node o join proxy (JP) o join registrar/coordinator (JRC) Vucinic, et al. Expires June 12, 2020 [Page 4] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 o enhanced beacon (EB) o join protocol o join process The following terms defined in [RFC8505] are also used throughout this document: o 6LoWPAN Border Router (6LBR) o 6LoWPAN Node (6LN) The term "6LBR" is used interchangeably with the term "DODAG root" defined in [RFC6550], on the assumption that the two entities are co- located, as recommended by [I-D.ietf-6tisch-architecture]. The term "pledge", as used throughout the document, explicitly denotes non-6LBR devices attempting to join the network using their IEEE Std 802.15.4 network interface. The device that attempts to join as the 6LBR of the network and does so over another network interface is explicitly denoted as the "6LBR pledge". When the text equally applies to the pledge and the 6LBR pledge, the "(6LBR) pledge" form is used. In addition, we use generic terms "pledge identifier" and "network identifier". See Section 3. 3. Provisioning Phase The (6LBR) pledge is provisioned with certain parameters before attempting to join the network, and the same parameters are provisioned to the JRC. There are many ways by which this provisioning can be done. Physically, the parameters can be written into the (6LBR) pledge using a number of mechanisms, such as a JTAG interface, a serial (craft) console interface, pushing buttons simultaneously on different devices, over-the-air configuration in a Faraday cage, etc. The provisioning can be done by the vendor, the manufacturer, the integrator, etc. Details of how this provisioning is done is out of scope of this document. What is assumed is that there can be a secure, private conversation between the JRC and the (6LBR) pledge, and that the two devices can exchange the parameters. Parameters that are provisioned to the (6LBR) pledge include: Vucinic, et al. Expires June 12, 2020 [Page 5] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 o pledge identifier. The pledge identifier identifies the (6LBR) pledge. The pledge identifier MUST be unique in the set of all pledge identifiers managed by a JRC. The pledge identifier uniqueness is an important security requirement, as discussed in Section 9. The pledge identifier is typically the globally unique 64-bit Extended Unique Identifier (EUI-64) of the IEEE Std 802.15.4 device, in which case it is provisioned by the hardware manufacturer. The pledge identifier is used to generate the IPv6 addresses of the (6LBR) pledge and to identify it during the execution of the join protocol. Depending on the configuration, the pledge identifier may also be used after the join process to identify the joined node. For privacy reasons (see Section 10), it is possible to use a pledge identifier different from the EUI- 64. For example, a pledge identifier may be a random byte string, but care needs to be taken that such a string meets the uniqueness requirement. o Pre-Shared Key (PSK). A symmetric cryptographic key shared between the (6LBR) pledge and the JRC. To look up the PSK for a given pledge, the JRC additionally needs to store the corresponding pledge identifier. Each (6LBR) pledge MUST be provisioned with a unique PSK. The PSK MUST be a cryptographically strong key, with at least 128 bits of entropy, indistinguishable by feasible computation from a random uniform string of the same length. How the PSK is generated and/or provisioned is out of scope of this specification. This could be done during a provisioning step or companion documents can specify the use of a key agreement protocol. Common pitfalls when generating PSKs are discussed in Section 9. In case of device re- commissioning to a new owner, the PSK MUST be changed. Note that the PSK is different from the link-layer keys K1 and K2 specified in [RFC8180]. The PSK is a long-term secret used to protect the execution of the secure join protocol specified in this document whose one output are link-layer keys. o Optionally, a network identifier. The network identifier identifies the 6TiSCH network. The network identifier MUST be carried within Enhanced Beacon (EB) frames. Typically, the 16-bit Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4] is used as the network identifier. However, PAN ID is not considered a stable network identifier as it may change during network lifetime if a collision with another network is detected. Companion documents can specify the use of a different network identifier for join purposes, but this is out of scope of this specification. Provisioning the network identifier to a pledge is RECOMMENDED. However, due to operational constraints, the network identifier may not be known at the time when the provisioning is done. In case this parameter is not provisioned Vucinic, et al. Expires June 12, 2020 [Page 6] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 to the pledge, the pledge attempts to join one advertised network at a time, which significantly prolongs the join process. This parameter MUST be provisioned to the 6LBR pledge. o Optionally, any non-default algorithms. The default algorithms are specified in Section 7.3.3. When algorithm identifiers are not provisioned, the use of these default algorithms is implied. Additionally, the 6LBR pledge that is not co-located with the JRC needs to be provisioned with: o Global IPv6 address of the JRC. This address is used by the 6LBR pledge to address the JRC during the join process. The 6LBR pledge may also obtain the IPv6 address of the JRC through other available mechanisms, such as DHCPv6 [RFC8415], GRASP [I-D.ietf-anima-grasp], mDNS [RFC6762], the use of which is out of scope of this document. Pledges do not need to be provisioned with this address as they discover it dynamically through CoJP. 4. Join Process Overview This section describes the steps taken by a pledge in a 6TiSCH network. When a pledge seeks admission to a 6TiSCH network, the following exchange occurs: 1. The pledge listens for an Enhanced Beacon (EB) frame [IEEE802.15.4]. This frame provides network synchronization information, and tells the device when it can send a frame to the node sending the beacons, which acts as a Join Proxy (JP) for the pledge, and when it can expect to receive a frame. The Enhanced Beacon provides the link-layer address of the JP and it may also provide its link-local IPv6 address. 2. The pledge configures its link-local IPv6 address and advertises it to the JP using Neighbor Discovery. The advertisement step may be omitted if the link-local address has been derived from a known unique interface identifier, such as an EUI-64 address. 3. The pledge sends a Join Request to the JP in order to securely identify itself to the network. The Join Request is forwarded to the JRC. 4. In case of successful processing of the request, the pledge receives a Join Response from the JRC (via the JP). The Join Response contains configuration parameters necessary for the pledge to join the network. Vucinic, et al. Expires June 12, 2020 [Page 7] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 From the pledge's perspective, joining is a local phenomenon - the pledge only interacts with the JP, and it needs not know how far it is from the 6LBR, or how to route to the JRC. Only after establishing one or more link-layer keys does it need to know about the particulars of a 6TiSCH network. The join process is shown as a transaction diagram in Figure 1: +--------+ +-------+ +--------+ | pledge | | JP | | JRC | | | | | | | +--------+ +-------+ +--------+ | | | |<---Enhanced Beacon (1)---| | | | | |<-Neighbor Discovery (2)->| | | | | |-----Join Request (3a)----|----Join Request (3a)---->| \ | | | | CoJP |<----Join Response (3b)---|----Join Response (3b)----| / | | | Figure 1: Overview of a successful join process. As for other nodes in the network, the 6LBR node may act as the JP. The 6LBR may in addition be co-located with the JRC. The details of each step are described in the following sections. 4.1. Step 1 - Enhanced Beacon The pledge synchronizes to the network by listening for, and receiving, an Enhanced Beacon (EB) sent by a node already in the network. This process is entirely defined by [IEEE802.15.4], and described in [RFC7554]. Once the pledge hears an EB, it synchronizes to the joining schedule using the cells contained in the EB. The pledge can hear multiple EBs; the selection of which EB to use is out of the scope for this document, and is discussed in [RFC7554]. Implementers should make use of information such as: what network identifier the EB contains, the value of the Join Metric field within EBs, whether the source link-layer address of the EB has been tried before, what signal strength the different EBs were received at, etc. In addition, the pledge may be pre-configured to search for EBs with a specific network identifier. Vucinic, et al. Expires June 12, 2020 [Page 8] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 If the pledge is not provisioned with the network identifier, it attempts to join one network at a time, as described in Section 8.1.1. Once the pledge selects the EB, it synchronizes to it and transitions into a low-power mode. It follows the schedule information contained in the EB which indicates the slots that the pledge may use for the join process. During the remainder of the join process, the node that has sent the EB to the pledge acts as the JP. At this point, the pledge may proceed to step 2, or continue to listen for additional EBs. 4.2. Step 2 - Neighbor Discovery The pledge forms its link-local IPv6 address based on the interface identifier, as per [RFC4944]. The pledge MAY perform the Neighbor Solicitation / Neighbor Advertisement exchange with the JP, as per Section 5.6 of [RFC8505]. As per [RFC8505], there is no need to perform duplicate address detection for the link-local address. The pledge and the JP use their link-local IPv6 addresses for all subsequent communication during the join process. Note that Neighbor Discovery exchanges at this point are not protected with link-layer security as the pledge is not in possession of the keys. How the JP accepts these unprotected frames is discussed in Section 5. 4.3. Step 3 - Constrained Join Protocol (CoJP) Execution The pledge triggers the join exchange of the Constrained Join Protocol (CoJP). The join exchange consists of two messages: the Join Request message (Step 3a), and the Join Response message conditioned on the successful security processing of the request (Step 3b). All CoJP messages are exchanged over a secure end-to-end channel that provides confidentiality, data authenticity and replay protection. Frames carrying CoJP messages are not protected with link-layer security when exchanged between the pledge and the JP as the pledge is not in possession of the link-layer keys in use. How JP and pledge accept these unprotected frames is discussed in Section 5. When frames carrying CoJP messages are exchanged between nodes that have already joined the network, the link-layer security is applied according to the security configuration used in the network. Vucinic, et al. Expires June 12, 2020 [Page 9] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 4.3.1. Step 3a - Join Request The Join Request is a message sent from the pledge to the JP, and which the JP forwards to the JRC. The pledge indicates in the Join Request the role it requests to play in the network, as well as the identifier of the network it requests to join. The JP forwards the Join Request to the JRC on the existing links. How exactly this happens is out of scope of this document; some networks may wish to dedicate specific link layer resources for this join traffic. 4.3.2. Step 3b - Join Response The Join Response is sent by the JRC to the pledge, and is forwarded through the JP. The packet containing the Join Response travels from the JRC to the JP using the operating routes in the network. The JP delivers it to the pledge. The JP operates as an application-layer proxy, see Section 7. The Join Response contains different parameters needed by the pledge to become a fully operational network node. These parameters include the link-layer key(s) currently in use in the network, the short address assigned to the pledge, the IPv6 address of the JRC needed by the pledge to operate as the JP, among others. 4.4. The Special Case of the 6LBR Pledge Joining The 6LBR pledge performs Section 4.3 of the join process described above, just as any other pledge, albeit over a different network interface. There is no JP intermediating the communication between the 6LBR pledge and the JRC, as described in Section 6. The other steps of the described join process do not apply to the 6LBR pledge. How the 6LBR pledge obtains an IPv6 address and triggers the execution of the CoJP protocol is out of scope of this document. 5. Link-layer Configuration In an operational 6TiSCH network, all frames use link-layer frame security [RFC8180]. The IEEE Std 802.15.4 security attributes include frame authenticity, and optionally frame confidentiality (i.e. encryption). Any node sending EB frames MUST be prepared to act as a JP for potential pledges. The pledge does not initially do any authenticity check of the EB frames, as it does not possess the link-layer key(s) in use. The pledge is still able to parse the contents of the received EBs and synchronize to the network, as EBs are not encrypted [RFC8180]. Vucinic, et al. Expires June 12, 2020 [Page 10] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames at the link layer. In order for the join process to be possible, the JP must accept these unsecured frames for the duration of the join process. This behavior may be implemented by setting the "secExempt" attribute in the IEEE Std 802.15.4 security configuration tables. It is expected that the lower layer provides an interface to indicate to the upper layer that unsecured frames are being received from a device, and that the upper layer can use that information to make a determination that a join process is in place and the unsecured frames should be processed. How the JP makes such a determination and interacts with the lower layer is out of scope of this specification. The JP can additionally make use of information such as the value of the join rate parameter (Section 8.4.2) set by the JRC, physical button press, etc. When the pledge initially synchronizes to the network, it has no means of verifying the authenticity of EB frames. As an attacker can craft a frame that looks like a legitimate EB frame this opens up a DoS vector, as discussed in Section 9. 5.1. Distribution of Time Nodes in a 6TiSCH network keep a global notion of time known as the absolute slot number. Absolute slot number is used in the construction of the link-layer nonce, as defined in [IEEE802.15.4]. The pledge initially synchronizes to the EB frame sent by the JP, and uses the value of the absolute slot number found in the TSCH Synchronization Information Element. At the time of the synchronization, the EB frame can neither be authenticated nor its freshness verified. During the join process, the pledge sends frames that are unprotected at the link-layer and protected end-to-end instead. The pledge does not obtain the time information as the output of the join process as this information is local to the network and may not be known at the JRC. This enables an attack on the pledge where the attacker replays to the pledge legitimate EB frames obtained from the network and acts as a man-in-the-middle between the pledge and the JP. The EB frames will make the pledge believe that the replayed absolute slot number value is the current notion of time in the network. By forwarding the join traffic to the legitimate JP, the attacker enables the pledge to join the network. Under different conditions relating to the reuse of the pledge's short address by the JRC or its attempt to rejoin the network, this may cause the pledge to reuse the link-layer nonce in the first frame it sends protected after the join process is completed. Vucinic, et al. Expires June 12, 2020 [Page 11] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 For this reason, all frames originated at the JP and destined to the pledge during the join process MUST be authenticated at the link- layer using the key that is normally in use in the network. Link- layer security processing at the pledge for these frames will fail as the pledge is not yet in possession of the key. The pledge acknowledges these frames without link-layer security, and JP accepts the unsecured acknowledgment due to the secExempt attribute set for the pledge. The frames should be passed to the upper layer for processing using the promiscuous mode of [IEEE802.15.4] or another appropriate mechanism. When the upper layer processing on the pledge is completed and the link-layer keys are configured, the upper layer MUST trigger the security processing of the corresponding frame. Once the security processing of the frame carrying the Join Response message is successful, the current absolute slot number kept locally at the pledge SHALL be declared as valid. 6. Network-layer Configuration The pledge and the JP SHOULD keep a separate neighbor cache for untrusted entries and use it to store each other's information during the join process. Mixing neighbor entries belonging to pledges and nodes that are part of the network opens up the JP to a DoS attack, as the attacker may fill JP's neighbor table and prevent the discovery of legitimate neighbors. Once the pledge obtains link-layer keys and becomes a joined node, it is able to securely communicate with its neighbors, obtain the network IPv6 prefix and form its global IPv6 address. The joined node then undergoes an independent process to bootstrap its neighbor cache entries, possibly with a node that formerly acted as a JP, following [RFC8505]. From the point of view of the JP, there is no relationship between the neighbor cache entry belonging to a pledge and the joined node that formerly acted as a pledge. The pledge does not communicate with the JRC at the network layer. This allows the pledge to join without knowing the IPv6 address of the JRC. Instead, the pledge communicates with the JP at the network layer using link-local addressing, and with the JRC at the application layer, as specified in Section 7. The JP communicates with the JRC over global IPv6 addresses. The JP discovers the network IPv6 prefix and configures its global IPv6 address upon successful completion of the join process and the obtention of link-layer keys. The pledge learns the IPv6 address of the JRC from the Join Response, as specified in Section 8.1.2; it uses it once joined in order to operate as a JP. Vucinic, et al. Expires June 12, 2020 [Page 12] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 As a special case, the 6LBR pledge may have an additional network interface that it uses in order to obtain the configuration parameters from the JRC and start advertising the 6TiSCH network. This additional interface needs to be configured with a global IPv6 address, by a mechanism that is out of scope of this document. The 6LBR pledge uses this interface to directly communicate with the JRC using global IPv6 addressing. The JRC can be co-located on the 6LBR. In this special case, the IPv6 address of the JRC can be omitted from the Join Response message for space optimization. The 6LBR then MUST set the DODAGID field in the RPL DIOs [RFC6550] to its IPv6 address. The pledge learns the address of the JRC once joined and upon the reception of the first RPL DIO message, and uses it to operate as a JP. 6.1. Identification of Unauthenticated Traffic The traffic that is proxied by the Join Proxy (JP) comes from unauthenticated pledges, and there may be an arbitrary amount of it. In particular, an attacker may send fraudulent traffic in an attempt to overwhelm the network. When operating as part of a [RFC8180] 6TiSCH minimal network using distributed scheduling algorithms, the traffic from unauthenticated pledges may cause intermediate nodes to request additional bandwidth. An attacker could use this property to cause the network to overcommit bandwidth (and energy) to the join process. The Join Proxy is aware of what traffic originates from unauthenticated pledges, and so can avoid allocating additional bandwidth itself. The Join Proxy implements a data cap on outgoing join traffic by implementing the recommendation of 1 packet per 3 seconds in Section 3.1.3 of [RFC8085]. This can be achieved with the congestion control mechanism specified in Section 4.7 of [RFC7252]. This cap will not protect intermediate nodes as they can not tell join traffic from regular traffic. Despite the data cap implemented separately on each Join Proxy, the aggregate join traffic from many Join Proxies may cause intermediate nodes to decide to allocate additional cells. It is undesirable to do so in response to the traffic originated at unauthenticated pledges. In order to permit the intermediate nodes to avoid this, the traffic needs to be tagged. [RFC2597] defines a set of per-hop behaviors that may be encoded into the Diffserv Code Points (DSCPs). Based on the DSCP, intermediate nodes can decide whether to act on a given packet. Vucinic, et al. Expires June 12, 2020 [Page 13] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 6.1.1. Traffic from JP to JRC The Join Proxy SHOULD set the DSCP of packets that it produces as part of the forwarding process to AF43 code point (See Section 6 of [RFC2597]). A Join Proxy that does not require a specific DSCP value on traffic forwarded should set it to zero so that it is compressed out. A Scheduling Function (SF) running on 6TiSCH nodes SHOULD NOT allocate additional cells as a result of traffic with code point AF43. Companion SF documents SHOULD specify how this recommended behavior is achieved. One example is the 6TiSCH Minimal Scheduling Function [I-D.ietf-6tisch-msf]. 6.1.2. Traffic from JRC to JP The JRC SHOULD set the DSCP of join response packets addressed to the Join Proxy to AF42 code point. AF42 has lower drop probability than AF43, giving this traffic priority in buffers over the traffic going towards the JRC. The 6LBR links are often the most congested within a DODAG, and from that point down there is progressively less (or equal) congestion. If the 6LBR paces itself when sending join response traffic then it ought to never exceed the bandwidth allocated to the best effort traffic cells. If the 6LBR has the capacity (if it is not constrained) then it should provide some buffers in order to satisfy the Assured Forwarding behavior. Companion SF documents SHOULD specify how traffic with code point AF42 is handled with respect to cell allocation. In case the recommended behavior described in this section is not followed, the network may become prone to the attack discussed in Section 6.1. 7. Application-level Configuration The CoJP join exchange in Figure 1 is carried over CoAP [RFC7252] and the secure channel provided by OSCORE [RFC8613]. The (6LBR) pledge acts as a CoAP client; the JRC acts as a CoAP server. The JP implements CoAP forward proxy functionality [RFC7252]. Because the JP can also be a constrained device, it cannot implement a cache. The pledge designates a JP as a proxy by including the Proxy-Scheme option in CoAP requests it sends to the JP. The pledge also includes in the requests the Uri-Host option with its value set to the well- known JRC's alias, as specified in Section 8.1.1. Vucinic, et al. Expires June 12, 2020 [Page 14] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 The JP resolves the alias to the IPv6 address of the JRC that it learned when it acted as a pledge, and joined the network. This allows the JP to reach the JRC at the network layer and forward the requests on behalf of the pledge. 7.1. Statelessness of the JP The CoAP proxy defined in [RFC7252] keeps per-client state information in order to forward the response towards the originator of the request. This state information includes at least the CoAP token, the IPv6 address of the client, and the UDP source port number. Since the JP can be a constrained device that acts as a CoAP proxy, memory limitations make it prone to a Denial-of-Service (DoS) attack. This DoS vector on the JP can be mitigated by making the JP act as a stateless CoAP proxy, where "state" encompasses the information related to individual pledges. The JP can wrap the state it needs to keep for a given pledge throughout the network stack in a "state object" and include it as a CoAP token in the forwarded request to the JRC. The JP may use the CoAP token as defined in [RFC7252], if the size of the serialized state object permits, or use the extended CoAP token defined in [I-D.ietf-core-stateless], to transport the state object. The JRC and any other potential proxy on the JP - JRC path MUST support extended token lengths, as defined in [I-D.ietf-core-stateless]. Since the CoAP token is echoed back in the response, the JP is able to decode the state object and configure the state needed to forward the response to the pledge. The information that the JP needs to encode in the state object to operate in a fully stateless manner with respect to a given pledge is implementation specific. It is RECOMMENDED that the JP operates in a stateless manner and signals the per-pledge state within the CoAP token, for every request it forwards into the network on behalf of unauthenticated pledges. When the JP is operating in a stateless manner, the security considerations from [I-D.ietf-core-stateless] apply and the type of the CoAP message that the JP forwards on behalf of the pledge MUST be non-confirmable (NON), regardless of the message type received from the pledge. The use of a non-confirmable message by the JP alleviates the JP from keeping CoAP message exchange state. The retransmission burden is then entirely shifted to the pledge. A JP that operates in a stateless manner still needs to keep congestion control state with the JRC, see Section 9. Recommended values of CoAP settings for use during the join process, both by the pledge and the JP, are given in Section 7.2. Vucinic, et al. Expires June 12, 2020 [Page 15] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 Note that in some networking stack implementations, a fully (per- pledge) stateless operation of the JP may be challenging from the implementation's point of view. In those cases, the JP may operate as a statefull proxy that stores the per-pledge state until the response is received or timed out, but this comes at a price of a DoS vector. 7.2. Recommended Settings This section gives RECOMMENDED values of CoAP settings during the join process. +-------------------+---------------+ | Name | Default Value | +-------------------+---------------+ | ACK_TIMEOUT | 10 seconds | | | | | ACK_RANDOM_FACTOR | 1.5 | | | | | MAX_RETRANSMIT | 4 | | | | | NSTART | 1 | | | | | DEFAULT_LEISURE | 5 seconds | | | | | PROBING_RATE | 1 byte/second | +-------------------+---------------+ Recommended CoAP settings. These values may be configured to values specific to the deployment. The default values have been chosen to accommodate a wide range of deployments, taking into account dense networks. The PROBING_RATE value at the JP is controlled by the join rate parameter, see Section 8.4.2. Following [RFC7252], the average data rate in sending to the JRC must not exceed PROBING_RATE. For security reasons, the average data rate SHOULD be measured over a rather short window, e.g. ACK_TIMEOUT, see Section 9. 7.3. OSCORE Before the (6LBR) pledge and the JRC start exchanging CoAP messages protected with OSCORE, they need to derive the OSCORE security context from the provisioned parameters, as discussed in Section 3. The OSCORE security context MUST be derived as per Section 3 of [RFC8613]. Vucinic, et al. Expires June 12, 2020 [Page 16] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 o the Master Secret MUST be the PSK. o the Master Salt MUST be the empty byte string. o the ID Context MUST be set to the pledge identifier. o the ID of the pledge MUST be set to the empty byte string. This identifier is used as the OSCORE Sender ID of the pledge in the security context derivation, since the pledge initially acts as a CoAP client. o the ID of the JRC MUST be set to the byte string 0x4a5243 ("JRC" in ASCII). This identifier is used as the OSCORE Recipient ID of the pledge in the security context derivation, as the JRC initially acts as a CoAP server. o the Algorithm MUST be set to the value from [RFC8152], agreed out- of-band by the same mechanism used to provision the PSK. The default is AES-CCM-16-64-128. o the Key Derivation Function MUST be agreed out-of-band by the same mechanism used to provision the PSK. Default is HKDF SHA-256 [RFC5869]. Since the pledge's OSCORE Sender ID is the empty byte string, when constructing the OSCORE option, the pledge sets the k bit in the OSCORE flag byte, but indicates a 0-length kid. The pledge transports its pledge identifier within the kid context field of the OSCORE option. The derivation in [RFC8613] results in OSCORE keys and a common IV for each side of the conversation. Nonces are constructed by XOR'ing the common IV with the current sequence number. For details on nonce and OSCORE option construction, refer to [RFC8613]. Implementations MUST ensure that multiple CoAP requests, including to different JRCs, are properly incrementing the sequence numbers, so that the same sequence number is never reused in distinct requests protected under the same PSK. The pledge typically sends requests to different JRCs if it is not provisioned with the network identifier and attempts to join one network at a time. Failure to comply will break the security guarantees of the Authenticated Encryption with Associated Data (AEAD) algorithm because of nonce reuse. This OSCORE security context is used for initial joining of the (6LBR) pledge, where the (6LBR) pledge acts as a CoAP client, as well as for any later parameter updates, where the JRC acts as a CoAP client and the joined node as a CoAP server, as discussed in Section 8.2. Note that when the (6LBR) pledge and the JRC change Vucinic, et al. Expires June 12, 2020 [Page 17] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 roles between CoAP client and CoAP server, the same OSCORE security context as initially derived remains in use and the derived parameters are unchanged, for example Sender ID when sending and Recipient ID when receiving (see Section 3.1 of [RFC8613]). A (6LBR) pledge is expected to have exactly one OSCORE security context with the JRC. 7.3.1. Replay Window and Persistency Both (6LBR) pledge and the JRC MUST implement a replay protection mechanism. The use of the default OSCORE replay protection mechanism specified in Section 3.2.2 of [RFC8613] is RECOMMENDED. Implementations MUST ensure that mutable OSCORE context parameters (Sender Sequence Number, Replay Window) are stored in persistent memory. A technique detailed in Appendix B.1.1 of [RFC8613] that prevents reuse of sequence numbers MUST be implemented. Each update of the OSCORE Replay Window MUST be written to persistent memory. This is an important security requirement in order to guarantee nonce uniqueness and resistance to replay attacks across reboots and rejoins. Traffic between the (6LBR) pledge and the JRC is rare, making security outweigh the cost of writing to persistent memory. 7.3.2. OSCORE Error Handling Errors raised by OSCORE during the join process MUST be silently dropped, with no error response being signaled. The pledge MUST silently discard any response not protected with OSCORE, including error codes. Such errors may happen for a number of reasons, including failed lookup of an appropriate security context (e.g. the pledge attempting to join a wrong network), failed decryption, positive replay window lookup, formatting errors (possibly due to malicious alterations in transit). Silently dropping OSCORE messages prevents a DoS attack on the pledge where the attacker could send bogus error responses, forcing the pledge to attempt joining one network at a time, until all networks have been tried. 7.3.3. Mandatory to Implement Algorithms The mandatory to implement AEAD algorithm for use with OSCORE is AES- CCM-16-64-128 from [RFC8152]. This is the algorithm used for securing IEEE Std 802.15.4 frames, and hardware acceleration for it is present in virtually all compliant radio chips. With this choice, CoAP messages are protected with an 8-byte CCM authentication tag, and the algorithm uses 13-byte long nonces. Vucinic, et al. Expires June 12, 2020 [Page 18] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 The mandatory to implement hash algorithm is SHA-256 [RFC4231]. The mandatory to implement key derivation function is HKDF [RFC5869], instantiated with a SHA-256 hash. See Appendix B for implementation guidance when code footprint is important. 8. Constrained Join Protocol (CoJP) The Constrained Join Protocol (CoJP) is a lightweight protocol over CoAP [RFC7252] and a secure channel provided by OSCORE [RFC8613]. CoJP allows a (6LBR) pledge to request admission into a network managed by the JRC. It enables the JRC to configure the pledge with the necessary parameters. The JRC may update the parameters at any time, by reaching out to the joined node that formerly acted as a (6LBR) pledge. For example, network-wide rekeying can be implemented by updating the keying material on each node. CoJP relies on the security properties provided by OSCORE. This includes end-to-end confidentiality, data authenticity, replay protection, and a secure binding of responses to requests. +-----------------------------------+ | Constrained Join Protocol (CoJP) | +-----------------------------------+ +-----------------------------------+ \ | Requests / Responses | | |-----------------------------------| | | OSCORE | | CoAP |-----------------------------------| | | Messaging Layer | | +-----------------------------------+ / +-----------------------------------+ | UDP | +-----------------------------------+ Figure 2: Abstract layering of CoJP. When a (6LBR) pledge requests admission to a given network, it undergoes the CoJP join exchange that consists of: o the Join Request message, sent by the (6LBR) pledge to the JRC, potentially proxied by the JP. The Join Request message and its mapping to CoAP is specified in Section 8.1.1. o the Join Response message, sent by the JRC to the (6LBR) pledge, if the JRC successfully processes the Join Request using OSCORE and it determines through a mechanism that is out of scope of this specification that the (6LBR) pledge is authorized to join the network. The Join Response message is potentially proxied by the Vucinic, et al. Expires June 12, 2020 [Page 19] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 JP. The Join Response message and its mapping to CoAP is specified in Section 8.1.2. When the JRC needs to update the parameters of a joined node that formerly acted as a (6LBR) pledge, it executes the CoJP parameter update exchange that consists of: o the Parameter Update message, sent by the JRC to the joined node that formerly acted as a (6LBR) pledge. The Parameter Update message and its mapping to CoAP is specified in Section 8.2.1. The payload of CoJP messages is encoded with CBOR [RFC7049]. The CBOR data structures that may appear as the payload of different CoJP messages are specified in Section 8.4. 8.1. Join Exchange This section specifies the messages exchanged when the (6LBR) pledge requests admission and configuration parameters from the JRC. 8.1.1. Join Request Message The Join Request message that the (6LBR) pledge sends SHALL be mapped to a CoAP request: o The request method is POST. o The type is Confirmable (CON). o The Proxy-Scheme option is set to "coap". o The Uri-Host option is set to "6tisch.arpa". This is an anycast type of identifier of the JRC that is resolved to its IPv6 address by the JP or the 6LBR pledge. o The Uri-Path option is set to "j". o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE security context used is the one derived in Section 7.3. The OSCORE kid context allows the JRC to retrieve the security context for a given pledge. o The payload is a Join_Request CBOR object, as defined in Section 8.4.1. Since the Join Request is a confirmable message, the transmission at (6LBR) pledge will be controlled by CoAP's retransmission mechanism. The JP, when operating in a stateless manner, forwards this Join Vucinic, et al. Expires June 12, 2020 [Page 20] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 Request as a non-confirmable (NON) CoAP message, as specified in Section 7. If the CoAP implementation at (6LBR) pledge declares the message transmission as failure, the (6LBR) pledge SHOULD attempt to join a 6TiSCH network advertised with a different network identifier. See Section 7.2 for recommended values of CoAP settings to use during the join exchange. If all join attempts to advertised networks have failed, the (6LBR) pledge SHOULD signal the presence of an error condition, through some out-of-band mechanism. BCP190 [RFC7320] provides guidelines on URI design and ownership. It recommends that whenever a third party wants to mandate a URL to web authority that it SHOULD go under "/.well-known" (as per [RFC5785]). In the case of CoJP, the Uri-Host option is always set to "6tisch.arpa", and based upon the recommendations in the Introduction of [RFC7320], it is asserted that this document is the owner of the CoJP service. As such, the concerns of [RFC7320] do not apply, and thus the Uri-Path is only "/j". 8.1.2. Join Response Message The Join Response message that the JRC sends SHALL be mapped to a CoAP response: o The response Code is 2.04 (Changed). o The payload is a Configuration CBOR object, as defined in Section 8.4.2. 8.2. Parameter Update Exchange During the network lifetime, parameters returned as part of the Join Response may need to be updated. One typical example is the update of link-layer keying material for the network, a process known as rekeying. This section specifies a generic mechanism when this parameter update is initiated by the JRC. At the time of the join, the (6LBR) pledge acts as a CoAP client and requests the network parameters through a representation of the "/j" resource, exposed by the JRC. In order for the update of these parameters to happen, the JRC needs to asynchronously contact the joined node. The use of the CoAP Observe option for this purpose is not feasible due to the change in the IPv6 address when the pledge becomes the joined node and obtains a global address. Instead, once the (6LBR) pledge receives and successfully validates the Join Response and so becomes a joined node, it becomes a CoAP Vucinic, et al. Expires June 12, 2020 [Page 21] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 server. The joined node creates a CoAP service at the Uri-Host value of "6tisch.arpa", and the joined node exposes the "/j" resource that is used by the JRC to update the parameters. Consequently, the JRC operates as a CoAP client when updating the parameters. The request/ response exchange between the JRC and the (6LBR) pledge happens over the already-established OSCORE secure channel. 8.2.1. Parameter Update Message The Parameter Update message that the JRC sends to the joined node SHALL be mapped to a CoAP request: o The request method is POST. o The type is Confirmable (CON). o The Uri-Host option is set to "6tisch.arpa". o The Uri-Path option is set to "j". o The OSCORE option SHALL be set according to [RFC8613]. The OSCORE security context used is the one derived in Section 7.3. When a joined node receives a request with the Sender ID set to 0x4a5243 (ID of the JRC), it is able to correctly retrieve the security context with the JRC. o The payload is a Configuration CBOR object, as defined in Section 8.4.2. The JRC has implicit knowledge on the global IPv6 address of the joined node, as it knows the pledge identifier that the joined node used when it acted as a pledge, and the IPv6 network prefix. The JRC uses this implicitly derived IPv6 address of the joined node to directly address CoAP messages to it. In case the JRC does not receive a response to a Parameter Update message, it attempts multiple retransmissions, as configured by the underlying CoAP retransmission mechanism triggered for confirmable messages. Finally, if the CoAP implementation declares the transmission as failure, the JRC may consider this as a hint that the joined node is no longer in the network. How the JRC decides when to stop attempting to contact a previously joined node is out of scope of this specification but security considerations on the reuse of assigned resources apply, as discussed in Section 9. Vucinic, et al. Expires June 12, 2020 [Page 22] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 8.3. Error Handling 8.3.1. CoJP CBOR Object Processing CoJP CBOR objects are transported within both CoAP requests and responses. This section describes handling in case certain CoJP CBOR object parameters are not supported by the implementation or their processing fails. See Section 7.3.2 for the handling of errors that may be raised by the underlying OSCORE implementation. When such a parameter is detected in a CoAP request (Join Request message, Parameter Update message), a Diagnostic Response message MUST be returned. A Diagnostic Response message maps to a CoAP response and is specified in Section 8.3.2. When a parameter that cannot be acted upon is encountered while processing a CoJP object in a CoAP response (Join Response message), a (6LBR) pledge SHOULD reattempt to join. In this case, the (6LBR) pledge SHOULD include the Unsupported Configuration CBOR object within the Join Request object in the following Join Request message. The Unsupported Configuration CBOR object is self-contained and enables the (6LBR) pledge to signal any parameters that the implementation of the networking stack may not support. A (6LBR) pledge MUST NOT attempt more than COJP_MAX_JOIN_ATTEMPTS number of attempts to join if the processing of the Join Response message fails each time. If COJP_MAX_JOIN_ATTEMPTS number of attempts is reached without success, the (6LBR) pledge SHOULD signal the presence of an error condition, through some out-of-band mechanism. Note that COJP_MAX_JOIN_ATTEMPTS relates to the application-level handling of the CoAP response and is different from CoAP's MAX_RETRANSMIT setting that drives the retransmission mechanism of the underlying CoAP message. 8.3.2. Diagnostic Response Message The Diagnostic Response message is returned for any CoJP request when the processing of the payload failed. The Diagnostic Response message is protected by OSCORE as any other CoJP protocol message. The Diagnostic Response message SHALL be mapped to a CoAP response: o The response Code is 4.00 (Bad Request). o The payload is an Unsupported Configuration CBOR object, as defined in Section 8.4.5, containing more information about the parameter that triggered the sending of this message. Vucinic, et al. Expires June 12, 2020 [Page 23] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 8.3.3. Failure Handling The Parameter Update exchange may be triggered at any time during the network lifetime, which may span several years. During this period, it may occur that a joined node or the JRC experience unexpected events such as reboots or complete failures. This document mandates that the mutable parameters in the security context are written to persistent memory (see Section 7.3.1) by both the JRC and pledges (joined nodes). As the joined node (pledge) is typically a constrained device that handles the write operations to persistent memory in a predictable manner, the retrieval of mutable security context parameters is feasible across reboots such that there is no risk of AEAD nonce reuse due to reinitialized Sender Sequence numbers, or of a replay attack due to the reinitialized replay window. JRC may be hosted on a generic machine where the write operation to persistent memory may lead to unpredictable delays due to caching. In case of a reboot event at JRC occurring before the cached data is written to persistent memory, the loss of mutable security context parameters is likely which consequently poses the risk of AEAD nonce reuse. In the event of a complete device failure, where the mutable security context parameters cannot be retrieved, it is expected that a failed joined node is replaced with a new physical device, using a new pledge identifier and a PSK. When such a failure event occurs at the JRC, it is possible that the static information on provisioned pledges, like PSKs and pledge identifiers, can be retrieved through available backups. However, it is likely that the information about joined nodes, their assigned short identifiers and mutable security context parameters is lost. If this is the case, during the process of JRC reinitialization, the network administrator MUST force through out-of-band means all the networks managed by the failed JRC to rejoin, through e.g. the reinitialization of the 6LBR nodes and freshly generated dynamic cryptographic keys and other parameters that have influence on the security properties of the network. In order to recover from such a failure event, the reinitialized JRC can trigger the renegotiation of the OSCORE security context through the procedure described in Appendix B.2 of [RFC8613]. Aware of the failure event, the reinitialized JRC responds to the first join request of each pledge it is managing with a 4.01 Unauthorized error and a random nonce. The pledge verifies the error response and then initiates the CoJP join exchange using a new OSCORE security context derived from an ID Context consisting of the concatenation of two nonces, one that it received from the JRC and the other that the pledge generates locally. After verifying the join request with the new ID Context and the derived OSCORE security context, the JRC Vucinic, et al. Expires June 12, 2020 [Page 24] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 should consequently take action in mapping the new ID Context with the previously used pledge identifier. How JRC handles this mapping is out of scope of this document. The described procedure is specified in Appendix B.2 of [RFC8613] and is RECOMMENDED in order to handle the failure events or any other event that may lead to the loss of mutable security context parameters. The length of nonces exchanged using this procedure MUST be at least 8 bytes. The procedure does require both the pledge and the JRC to have good sources of randomness. While this is typically not an issue at the JRC side, the constrained device hosting the pledge may pose limitations in this regard. If the procedure outlined in Appendix B.2 of [RFC8613] is not supported by the pledge, the network administrator MUST take action in reprovisioning the concerned devices with freshly generated parameters, through out-of-band means. 8.4. CoJP Objects This section specifies the structure of CoJP CBOR objects that may be carried as the payload of CoJP messages. Some of these objects may be received both as part of the CoJP join exchange when the device operates as a (CoJP) pledge, or the parameter update exchange, when the device operates as a joined (6LBR) node. 8.4.1. Join Request Object The Join_Request structure is built on a CBOR map object. The set of parameters that can appear in a Join_Request object is summarized below. The labels can be found in the "CoJP Parameters" registry Section 11.1. o role: The identifier of the role that the pledge requests to play in the network once it joins, encoded as an unsigned integer. Possible values are specified in Table 2. This parameter MAY be included. In case the parameter is omitted, the default value of 0, i.e. the role "6TiSCH Node", MUST be assumed. o network identifier: The identifier of the network, as discussed in Section 3, encoded as a CBOR byte string. When present in the Join_Request, it hints to the JRC the network that the pledge is requesting to join, enabling the JRC to manage multiple networks. The pledge obtains the value of the network identifier from the received EB frames. This parameter MUST be included in a Join_Request object regardless of the role parameter value. Vucinic, et al. Expires June 12, 2020 [Page 25] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 o unsupported configuration: The identifier of the parameters that are not supported by the implementation, encoded as an Unsupported_Configuration object described in Section 8.4.5. This parameter MAY be included. If a (6LBR) pledge previously attempted to join and received a valid Join Response message over OSCORE, but failed to act on its payload (Configuration object), it SHOULD include this parameter to facilitate the recovery and debugging. Table 1 summarizes the parameters that may appear in a Join_Request object. +---------------------------+-------+------------------+ | Name | Label | CBOR Type | +---------------------------+-------+------------------+ | role | 1 | unsigned integer | | | | | | network identifier | 5 | byte string | | | | | | unsupported configuration | 8 | array | +---------------------------+-------+------------------+ Table 1: Summary of Join_Request parameters. The CDDL fragment that represents the text above for the Join_Request follows. Join_Request = { ? 1 : uint, ; role 5 : bstr, ; network identifier ? 8 : Unsupported_Configuration ; unsupported configuration } +--------+-------+-------------------------------------+------------+ | Name | Value | Description | Reference | +--------+-------+-------------------------------------+------------+ | 6TiSCH | 0 | The pledge requests to play the | [[this | | Node | | role of a regular 6TiSCH node, i.e. | document]] | | | | non-6LBR node. | | | | | | | | 6LBR | 1 | The pledge requests to play the | [[this | | | | role of 6LoWPAN Border Router | document]] | | | | (6LBR). | | +--------+-------+-------------------------------------+------------+ Table 2: Role values. Vucinic, et al. Expires June 12, 2020 [Page 26] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 8.4.2. Configuration Object The Configuration structure is built on a CBOR map object. The set of parameters that can appear in a Configuration object is summarized below. The labels can be found in "CoJP Parameters" registry Section 11.1. o link-layer key set: An array encompassing a set of cryptographic keys and their identifiers that are currently in use in the network, or that are scheduled to be used in the future. The encoding of individual keys is described in Section 8.4.3. The link-layer key set parameter MAY be included in a Configuration object. When present, the link-layer key set parameter MUST contain at least one key. This parameter is also used to implement rekeying in the network. How the keys are installed and used differs for the 6LBR and other (regular) nodes, and this is explained in Section 8.4.3.1 and Section 8.4.3.2. o short identifier: a compact identifier assigned to the pledge. The short identifier structure is described in Section 8.4.4. The short identifier parameter MAY be included in a Configuration object. o JRC address: the IPv6 address of the JRC, encoded as a byte string, with the length of 16 bytes. If the length of the byte string is different from 16, the parameter MUST be discarded. If the JRC is not co-located with the 6LBR and has a different IPv6 address than the 6LBR, this parameter MUST be included. In the special case where the JRC is co-located with the 6LBR and has the same IPv6 address as the 6LBR, this parameter MAY be included. If the JRC address parameter is not present in the Configuration object, this indicates that the JRC has the same IPv6 address as the 6LBR. The joined node can then discover the IPv6 address of the JRC through network control traffic. See Section 6. o blacklist: An array encompassing a list of pledge identifiers that are blacklisted by the JRC, with each pledge identifier encoded as a byte string. The blacklist parameter MAY be included in a Configuration object. When present, the array MUST contain zero or more byte strings encoding pledge identifiers. The joined node MUST silently drop any link-layer frames originating from the pledge identifiers enclosed in the blacklist parameter. When this parameter is received, its value MUST overwrite any previously set values. This parameter allows the JRC to configure the node acting as a JP to filter out traffic from misconfigured or malicious pledges before their traffic is forwarded into the network. If the JRC decides to remove a given pledge identifier from a blacklist, it omits the pledge identifier in the blacklist Vucinic, et al. Expires June 12, 2020 [Page 27] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 parameter value it sends next. Since the blacklist parameter carries the pledge identifiers, privacy considerations apply. See Section 10. o join rate: Average data rate (in units of bytes/second) of join traffic forwarded into the network that should not be exceeded when a joined node operates as a JP, encoded as an unsigned integer. The join rate parameter MAY be included in a Configuration object. This parameter allows the JRC to configure different nodes in the network to operate as JP, and act in case of an attack by throttling the rate at which JP forwards unauthenticated traffic into the network. When this parameter is present in a Configuration object, the value MUST be used to set the PROBING_RATE of CoAP at the joined node for communication with the JRC. In case this parameter is set to zero, a joined node MUST silently drop any join traffic coming from unauthenticated pledges. In case this parameter is omitted, the value of positive infinity SHOULD be assumed. Node operating as a JP MAY use another mechanism that is out of scope of this specification to configure PROBING_RATE of CoAP in the absence of a join rate parameter from the Configuration object. Table 3 summarizes the parameters that may appear in a Configuration object. +--------------------+-------+------------------+ | Name | Label | CBOR Type | +--------------------+-------+------------------+ | link-layer key set | 2 | array | | | | | | short identifier | 3 | array | | | | | | JRC address | 4 | byte string | | | | | | blacklist | 6 | array | | | | | | join rate | 7 | unsigned integer | +--------------------+-------+------------------+ Table 3: Summary of Configuration parameters. The CDDL fragment that represents the text above for the Configuration follows. Structures Link_Layer_Key and Short_Identifier are specified in Section 8.4.3 and Section 8.4.4. Vucinic, et al. Expires June 12, 2020 [Page 28] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 Configuration = { ? 2 : [ +Link_Layer_Key ], ; link-layer key set ? 3 : Short_Identifier, ; short identifier ? 4 : bstr, ; JRC address ? 6 : [ *bstr ], ; blacklist ? 7 : uint ; join rate } Vucinic, et al. Expires June 12, 2020 [Page 29] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 +---------------+-------+----------+-------------------+------------+ | Name | Label | CBOR | Description | Reference | | | | type | | | +---------------+-------+----------+-------------------+------------+ | role | 1 | unsigned | Identifies the | [[this | | | | integer | role parameter | document]] | | | | | | | | link-layer | 2 | array | Identifies the | [[this | | key set | | | array carrying | document]] | | | | | one or more link- | | | | | | level | | | | | | cryptographic | | | | | | keys | | | | | | | | | short | 3 | array | Identifies the | [[this | | identifier | | | assigned short | document]] | | | | | identifier | | | | | | | | | JRC address | 4 | byte | Identifies the | [[this | | | | string | IPv6 address of | document]] | | | | | the JRC | | | | | | | | | network | 5 | byte | Identifies the | [[this | | identifier | | string | network | document]] | | | | | identifier | | | | | | parameter | | | | | | | | | blacklist | 6 | array | Identifies the | [[this | | | | | blacklist | document]] | | | | | parameter | | | | | | | | | join rate | 7 | unsigned | Identifier the | [[this | | | | integer | join rate | document]] | | | | | parameter | | | | | | | | | unsupported | 8 | array | Identifies the | [[this | | configuration | | | unsupported | document]] | | | | | configuration | | | | | | parameter | | +---------------+-------+----------+-------------------+------------+ Table 4: CoJP parameters map labels. 8.4.3. Link-Layer Key The Link_Layer_Key structure encompasses the parameters needed to configure the link-layer security module: the key identifier; the value of the cryptographic key; the link-layer algorithm identifier Vucinic, et al. Expires June 12, 2020 [Page 30] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 and the security level and the frame types that it should be used with, both for outgoing and incoming security operations; and any additional information that may be needed to configure the key. For encoding compactness, the Link_Layer_Key object is not enclosed in a top-level CBOR object. Rather, it is transported as a sequence of CBOR elements [I-D.ietf-cbor-sequence], some being optional. The set of parameters that can appear in a Link_Layer_Key object is summarized below, in order: o key_id: The identifier of the key, encoded as a CBOR unsigned integer. This parameter MUST be included. If the decoded CBOR unsigned integer value is larger than the maximum link-layer key identifier, the key is considered invalid. In case the key is considered invalid, the key MUST be discarded and the implementation MUST signal the error as specified in Section 8.3.1. o key_usage: The identifier of the link-layer algorithm, security level and link-layer frame types that can be used with the key, encoded as an integer. This parameter MAY be included. Possible values and the corresponding link-layer settings are specified in IANA "CoJP Key Usage" registry (Section 11.2). In case the parameter is omitted, the default value of 0 (6TiSCH-K1K2-ENC- MIC32) from Table 5 MUST be assumed. This default value has been chosen such that it results in byte savings in the most constrained settings but does not imply a recommendation for its general usage. o key_value: The value of the cryptographic key, encoded as a byte string. This parameter MUST be included. If the length of the byte string is different than the corresponding key length for a given algorithm specified by the key_usage parameter, the key MUST be discarded and the implementation MUST signal the error as specified in Section 8.3.1. o key_addinfo: Additional information needed to configure the link- layer key, encoded as a byte string. This parameter MAY be included. The processing of this parameter is dependent on the link-layer technology in use and a particular keying mode. To be able to decode the keys that are present in the link-layer key set, and to identify individual parameters of a single Link_Layer_Key object, the CBOR decoder needs to differentiate between elements based on the CBOR type. For example, a uint that follows a byte string signals to the decoder that a new Link_Layer_Key object is being processed. Vucinic, et al. Expires June 12, 2020 [Page 31] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 The CDDL fragment that represents the text above for the Link_Layer_Key follows. Link_Layer_Key = ( key_id : uint, ? key_usage : int, key_value : bstr, ? key_addinfo : bstr, ) +-----------------+-----+------------------+-------------+----------+ | Name | Val | Algorithm | Description | Referenc | | | ue | | | e | +-----------------+-----+------------------+-------------+----------+ | 6TiSCH-K1K2 | 0 | IEEE802154-AES- | Use MIC-32 | [[this d | | -ENC-MIC32 | | CCM-128 | for EBs, | ocument] | | | | | ENC-MIC-32 | ] | | | | | for DATA | | | | | | and ACKNOWL | | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K1K2 | 1 | IEEE802154-AES- | Use MIC-64 | [[this d | | -ENC-MIC64 | | CCM-128 | for EBs, | ocument] | | | | | ENC-MIC-64 | ] | | | | | for DATA | | | | | | and ACKNOWL | | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K1K2 | 2 | IEEE802154-AES- | Use MIC-128 | [[this d | | -ENC-MIC128 | | CCM-128 | for EBs, | ocument] | | | | | ENC-MIC-128 | ] | | | | | for DATA | | | | | | and ACKNOWL | | | | | | EDGMENT. | | | | | | | | | 6TiSCH- | 3 | IEEE802154-AES- | Use MIC-32 | [[this d | | K1K2-MIC32 | | CCM-128 | for EBs, | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH- | 4 | IEEE802154-AES- | Use MIC-64 | [[this d | | K1K2-MIC64 | | CCM-128 | for EBs, | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH- | 5 | IEEE802154-AES- | Use MIC-128 | [[this d | Vucinic, et al. Expires June 12, 2020 [Page 32] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 | K1K2-MIC128 | | CCM-128 | for EBs, | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K1-MIC32 | 6 | IEEE802154-AES- | Use MIC-32 | [[this d | | | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K1-MIC64 | 7 | IEEE802154-AES- | Use MIC-64 | [[this d | | | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K1-MIC12 | 8 | IEEE802154-AES- | Use MIC-128 | [[this d | | 8 | | CCM-128 | for EBs. | ocument] | | | | | | ] | | | | | | | | 6TiSCH-K2-MIC32 | 9 | IEEE802154-AES- | Use MIC-32 | [[this d | | | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-MIC64 | 10 | IEEE802154-AES- | Use MIC-64 | [[this d | | | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-MIC12 | 11 | IEEE802154-AES- | Use MIC-128 | [[this d | | 8 | | CCM-128 | for DATA | ocument] | | | | | and ACKNOWL | ] | | | | | EDGMENT. | | | | | | | | | 6TiSCH-K2-ENC- | 12 | IEEE802154-AES- | Use ENC- | [[this d | | MIC32 | | CCM-128 | MIC-32 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K2-ENC- | 13 | IEEE802154-AES- | Use ENC- | [[this d | | MIC64 | | CCM-128 | MIC-64 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | | | | | T. | | | | | | | | | 6TiSCH-K2-ENC- | 14 | IEEE802154-AES- | Use ENC- | [[this d | | MIC128 | | CCM-128 | MIC-128 for | ocument] | | | | | DATA and AC | ] | | | | | KNOWLEDGMEN | | Vucinic, et al. Expires June 12, 2020 [Page 33] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 | | | | T. | | +-----------------+-----+------------------+-------------+----------+ Table 5: Key Usage values. 8.4.3.1. Rekeying of (6LoWPAN) Border Routers (6LBR) When the 6LoWPAN Border Router (6LBR) receives the Configuration object containing a link-layer key set, it MUST immediately install and start using the new keys for all outgoing traffic, and remove any old keys it has installed from the previous key set after a delay of COJP_REKEYING_GUARD_TIME has passed. This mechanism is used by the JRC to force the 6LBR to start sending traffic with the new key. The decision is taken by the JRC when it has determined that the new key has been made available to all (or some overwhelming majority) of nodes. Any node that the JRC has not yet reached at that point is either non-functional or in extended sleep such that it will not be reached. To get the key update, such node needs to go through the join process anew. 8.4.3.2. Rekeying of regular (6LoWPAN) Nodes (6LN) When a regular 6LN node receives the Configuration object with a link-layer key set, it MUST install the new keys. The 6LN will use both the old and the new keys to decrypt and authenticate any incoming traffic that arrives based upon the key identifier in the packet. It MUST continue to use the old keys for all outgoing traffic until it has detected that the network has switched to the new key set. The detection of network switch is based upon the receipt of traffic secured with the new keys. Upon reception and successful security processing of a link-layer frame secured with a key from the new key set, a 6LN node MUST then switch to sending outgoing traffic using the keys from the new set for all outgoing traffic. The 6LN node MUST remove any old keys it has installed from the previous key set after a delay of COJP_REKEYING_GUARD_TIME has passed after it starts using the new key set. Sending of traffic with the new keys signals to other downstream nodes to switch to their new key, and the effect is that there is a ripple of key updates around each 6LBR. 8.4.3.3. Use in IEEE Std 802.15.4 When Link_Layer_Key is used in the context of [IEEE802.15.4], the following considerations apply. Vucinic, et al. Expires June 12, 2020 [Page 34] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 Signaling of different keying modes of [IEEE802.15.4] is done based on the parameter values present in a Link_Layer_Key object. For instance, the value of the key_id parameter in combination with key_addinfo denotes which of the four Key ID modes of [IEEE802.15.4] is used and how. o Key ID Mode 0x00 (Implicit, pairwise): key_id parameter MUST be set to 0. key_addinfo parameter MUST be present. key_addinfo parameter MUST be set to the link-layer address(es) of a single peer with whom the key should be used. Depending on the configuration of the network, key_addinfo may carry the peer's long link-layer address (i.e. pledge identifier), short link-layer address, or their concatenation with the long address being encoded first. Which address type(s) is carried is determined from the length of the byte string. o Key ID Mode 0x01 (Key Index): key_id parameter MUST be set to a value different than 0. key_addinfo parameter MUST NOT be present. o Key ID Mode 0x02 (4-byte Explicit Key Source): key_id parameter MUST be set to a value different than 0. key_addinfo parameter MUST be present. key_addinfo parameter MUST be set to a byte string, exactly 4 bytes long. key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4]. o Key ID Mode 0x03 (8-byte Explicit Key Source): key_id parameter MUST be set to a value different than 0. key_addinfo parameter MUST be present. key_addinfo parameter MUST be set to a byte string, exactly 8 bytes long. key_addinfo parameter carries the Key Source parameter used to configure [IEEE802.15.4]. In all cases, key_usage parameter determines how a particular key should be used in respect to incoming and outgoing security policies. For Key ID Modes 0x01 - 0x03, parameter key_id sets the "secKeyIndex" parameter of [IEEE802.15.4] that is signaled in all outgoing frames secured with a given key. The maximum value key_id can have is 254. The value of 255 is reserved in [IEEE802.15.4] and is therefore considered invalid. Key ID Mode 0x00 (Implicit, pairwise) enables the JRC to act as a trusted third party and assign pairwise keys between nodes in the network. How JRC learns about the network topology is out of scope of this specification, but could be done through 6LBR - JRC signaling for example. Pairwise keys could also be derived through a key agreement protocol executed between the peers directly, where the authentication is based on the symmetric cryptographic material Vucinic, et al. Expires June 12, 2020 [Page 35] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 provided to both peers by the JRC. Such a protocol is out of scope of this specification. Implementations MUST use different link-layer keys when using different authentication tag (MIC) lengths, as using the same key with different authentication tag lengths might be unsafe. For example, this prohibits the usage of the same key for both MIC-32 and MIC-64 levels. See Annex B.4.3 of [IEEE802.15.4] for more information. 8.4.4. Short Identifier The Short_Identifier object represents an identifier assigned to the pledge. It is encoded as a CBOR array object, containing, in order: o identifier: The short identifier assigned to the pledge, encoded as a byte string. This parameter MUST be included. The identifier MUST be unique in the set of all identifiers assigned in a network that is managed by a JRC. In case the identifier is invalid, the decoder MUST silently ignore the Short_Identifier object. o lease_time: The validity of the identifier in hours after the reception of the CBOR object, encoded as a CBOR unsigned integer. This parameter MAY be included. The node MUST stop using the assigned short identifier after the expiry of the lease_time interval. It is up to the JRC to renew the lease before the expiry of the previous interval. The JRC updates the lease by executing the Parameter Update exchange with the node and including the Short_Identifier in the Configuration object, as described in Section 8.2. In case the lease expires, the node SHOULD initiate a new join exchange, as described in Section 8.1. In case this parameter is omitted, the value of positive infinity MUST be assumed, meaning that the identifier is valid for as long as the node participates in the network. The CDDL fragment that represents the text above for the Short_Identifier follows. Short_Identifier = [ identifier : bstr, ? lease_time : uint ] Vucinic, et al. Expires June 12, 2020 [Page 36] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 8.4.4.1. Use in IEEE Std 802.15.4 When Short_Identifier is used in the context of [IEEE802.15.4], the following considerations apply. The identifier MUST be used to set the short address of IEEE Std 802.15.4 module. When operating in TSCH mode, the identifier MUST be unique in the set of all identifiers assigned in multiple networks that share link-layer key(s). If the length of the byte string corresponding to the identifier parameter is different than 2, the identifier is considered invalid. The values 0xfffe and 0xffff are reserved by [IEEE802.15.4] and their use is considered invalid. The security properties offered by the [IEEE802.15.4] link-layer in TSCH mode are conditioned on the uniqueness requirement of the short identifier (i.e. short address). The short address is one of the inputs in the construction of the nonce, which is used to protect link-layer frames. If a misconfiguration occurs, and the same short address is assigned twice under the same link-layer key, the loss of security properties is imminent. For this reason, practices where the pledge generates the short identifier locally are not safe and are likely to result in the loss of link-layer security properties. The JRC MUST ensure that at any given time there are never two same short identifiers being used under the same link-layer key. If the lease_time parameter of a given Short_Identifier object is set to positive infinity, care needs to be taken that the corresponding identifier is not assigned to another node until the JRC is certain that it is no longer in use, potentially through out-of-band signaling. If the lease_time parameter expires for any reason, the JRC should take into consideration potential ongoing transmissions by the joined node, which may be hanging in the queues, before assigning the same identifier to another node. Care needs to be taken on how the pledge (joined node) configures the expiration of the lease. Since units of the lease_time parameter are in hours after the reception of the CBOR object, the pledge needs to convert the received time to the corresponding absolute slot number in the network. The joined node (pledge) MUST only use the absolute slot number as the appropriate reference of time to determine whether the assigned short identifier is still valid. 8.4.5. Unsupported Configuration Object The Unsupported_Configuration object is encoded as a CBOR array, containing at least one Unsupported_Parameter object. Each Unsupported_Parameter object is a sequence of CBOR elements without an enclosing top-level CBOR object for compactness. The set of Vucinic, et al. Expires June 12, 2020 [Page 37] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 parameters that appear in an Unsupported_Parameter object is summarized below, in order: o code: Indicates the capability of acting on the parameter signaled by parameter_label, encoded as an integer. This parameter MUST be included. Possible values of this parameter are specified in the IANA "CoJP Unsupported Configuration Code Registry" (Section 11.3). o parameter_label: Indicates the parameter. This parameter MUST be included. Possible values of this parameter are specified in the label column of the IANA "CoJP Parameters" registry (Section 11.1). o parameter_addinfo: Additional information about the parameter that cannot be acted upon. This parameter MUST be included. In case the code is set to "Unsupported", parameter_addinfo gives additional information to the JRC. If the parameter indicated by parameter_label cannot be acted upon regardless of its value, parameter_addinfo MUST be set to null, signaling to the JRC that it SHOULD NOT attempt to configure the parameter again. If the pledge can act on the parameter, but cannot configure the setting indicated by the parameter value, the pledge can hint this to the JRC. In this case, parameter_addinfo MUST be set to the value of the parameter that cannot be acted upon following the normative parameter structure specified in this document. For example, it is possible to include the link-layer key set object, signaling a subset of keys that cannot be acted upon, or the entire key set that was received. In that case, the value of the parameter_addinfo follows the link-layer key set structure defined in Section 8.4.2. In case the code is set to "Malformed", parameter_addinfo MUST be set to null, signaling to the JRC that it SHOULD NOT attempt to configure the parameter again. The CDDL fragment that represents the text above for Unsupported_Configuration and Unsupported_Parameter objects follows. Unsupported_Configuration = [ + parameter : Unsupported_Parameter ] Unsupported_Parameter = ( code : int, parameter_label : int, parameter_addinfo : nil / any ) Vucinic, et al. Expires June 12, 2020 [Page 38] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 +-------------+-------+--------------------------------+------------+ | Name | Value | Description | Reference | +-------------+-------+--------------------------------+------------+ | Unsupported | 0 | The indicated setting is not | [[this | | | | supported by the networking | document]] | | | | stack implementation. | | | | | | | | Malformed | 1 | The indicated parameter value | [[this | | | | is malformed. | document]] | +-------------+-------+--------------------------------+------------+ Table 6: Unsupported Configuration code values. 8.5. Recommended Settings This section gives RECOMMENDED values of CoJP settings. +--------------------------+---------------+ | Name | Default Value | +--------------------------+---------------+ | COJP_MAX_JOIN_ATTEMPTS | 4 | | | | | COJP_REKEYING_GUARD_TIME | 12 seconds | +--------------------------+---------------+ Recommended CoJP settings. The COJP_REKEYING_GUARD_TIME value SHOULD take into account possible retransmissions at the link layer due to imperfect wireless links. 9. Security Considerations Since this document uses the pledge identifier to set the ID Context parameter of OSCORE, an important security requirement is that the pledge identifier is unique in the set of all pledge identifiers managed by a JRC. The uniqueness of the pledge identifier ensures unique (key, nonce) pairs for AEAD algorithm used by OSCORE. It also allows the JRC to retrieve the correct security context, upon the reception of a Join Request message. The management of pledge identifiers is simplified if the globally unique EUI-64 is used, but this comes with privacy risks, as discussed in Section 10. This document further mandates that the (6LBR) pledge and the JRC are provisioned with unique PSKs. While the process of provisioning PSKs to all pledges can result in a substantial operational overhead, it is vital to do so for the security properties of the network. The PSK is used to set the OSCORE Master Secret during security context derivation. This derivation process results in OSCORE keys that are Vucinic, et al. Expires June 12, 2020 [Page 39] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 important for mutual authentication of the (6LBR) pledge and the JRC. The resulting security context shared between the pledge (joined node) and the JRC is used for the purpose of joining and is long- lived in that it can be used throughout the lifetime of a joined node for parameter update exchanges. Should an attacker come to know the PSK, then a man-in-the-middle attack is possible. Note that while OSCORE provides replay protection, it does not provide an indication of freshness in the presence of an attacker that can drop/reorder traffic. Since the join request contains no randomness, and the sequence number is predictable, the JRC could in principle anticipate a join request from a particular pledge and pre- calculate the response. In such a scenario, the JRC does not have to be alive at the time when the request is received. This could be relevant in case the JRC was temporarily compromised and control subsequently regained by the legitimate owner. It is of utmost importance to avoid unsafe practices when generating and provisioning PSKs. The use of a single PSK shared among a group of devices is a common pitfall that results in poor security. In this case, the compromise of a single device is likely to lead to a compromise of the entire batch, with the attacker having the ability to impersonate a legitimate device and join the network, generate bogus data and disturb the network operation. Additionally, some vendors use methods such as scrambling or hashing of device serial numbers or their EUI-64 to generate "unique" PSKs. Without any secret information involved, the effort that the attacker needs to invest into breaking these unsafe derivation methods is quite low, resulting in the possible impersonation of any device from the batch, without even needing to compromise a single device. The use of cryptographically secure random number generators to generate the PSK is RECOMMENDED, see [NIST800-90A] for different mechanisms using deterministic methods. The JP forwards the unauthenticated join traffic into the network. A data cap on the JP prevents it from forwarding more traffic than the network can handle and enables throttling in case of an attack. Note that this traffic can only be directed at the JRC so that the JRC needs to be prepared to handle such unsanitized inputs. The data cap can be configured by the JRC by including a join rate parameter in the Join Response and it is implemented through the CoAP's PROBING_RATE setting. The use of a data cap at a JP forces attackers to use more than one JP if they wish to overwhelm the network. Marking the join traffic packets with a non-zero DSCP allows the network to carry the traffic if it has capacity, but encourages the network to drop the extra traffic rather than add bandwidth due to that traffic. Vucinic, et al. Expires June 12, 2020 [Page 40] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 The shared nature of the "minimal" cell used for the join traffic makes the network prone to a DoS attack by congesting the JP with bogus traffic. Such an attacker is limited by its maximum transmit power. The redundancy in the number of deployed JPs alleviates the issue and also gives the pledge a possibility to use the best available link for joining. How a network node decides to become a JP is out of scope of this specification. At the beginning of the join process, the pledge has no means of verifying the content in the EB, and has to accept it at "face value". In case the pledge tries to join an attacker's network, the Join Response message will either fail the security check or time out. The pledge may implement a temporary blacklist in order to filter out undesired EBs and try to join using the next seemingly valid EB. This blacklist alleviates the issue, but is effectively limited by the node's available memory. Note that this temporary blacklist is different from the one communicated as part of the CoJP Configuration object as it helps pledge fight a DoS attack. The bogus beacons prolong the join time of the pledge, and so the time spent in "minimal" [RFC8180] duty cycle mode. The blacklist communicated as part of the CoJP Configuration object helps JP fight a DoS attack by a malicious pledge. During the network lifetime, the JRC may at any time initiate a Parameter Update exchange with a joined node. The Parameter Update message uses the same OSCORE security context as is used for the join exchange, except that the server/client roles are interchanged. As a consequence, each Parameter Update message carries the well-known OSCORE Sender ID of the JRC. A passive attacker may use the OSCORE Sender ID to identify the Parameter Update traffic in case the link- layer protection does not provide confidentiality. A countermeasure against such traffic analysis attack is to use encryption at the link-layer. Note that the join traffic does not undergo link-layer protection at the first hop, as the pledge is not yet in possession of cryptographic keys. Similarly, enhanced beacon traffic in the network is not encrypted. This makes it easy for a passive attacker to identify these types of traffic. 10. Privacy Considerations The join solution specified in this document relies on the uniqueness of the pledge identifier in the set of all pledge identifiers managed by a JRC. This identifier is transferred in clear as an OSCORE kid context. The use of the globally unique EUI-64 as pledge identifier simplifies the management but comes with certain privacy risks. The implications are thoroughly discussed in [RFC7721] and comprise correlation of activities over time, location tracking, address scanning and device-specific vulnerability exploitation. Since the Vucinic, et al. Expires June 12, 2020 [Page 41] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 join process occurs rarely compared to the network lifetime, long- term threats that arise from using EUI-64 as the pledge identifier are minimal. However, the use of EUI-64 after the join process completes, in the form of a layer-2 or layer-3 address, extends the aforementioned privacy threats to long term. As an optional mitigation technique, the Join Response message may contain a short address which is assigned by the JRC to the (6LBR) pledge. The assigned short address SHOULD be uncorrelated with the long-term pledge identifier. The short address is encrypted in the response. Once the join process completes, the new node may use the short addresses for all further layer-2 (and layer-3) operations. This reduces the privacy threats as the short layer-2 address (visible even when the network is encrypted) does not disclose the manufacturer, as is the case of EUI-64. However, an eavesdropper with access to the radio medium during the join process may be able to correlate the assigned short address with the extended address based on timing information with a non-negligible probability. This probability decreases with an increasing number of pledges joining concurrently. 11. IANA Considerations Note to RFC Editor: Please replace all occurrences of "[[this document]]" with the RFC number of this specification. This document allocates a well-known name under the .arpa name space according to the rules given in [RFC3172]. The name "6tisch.arpa" is requested. No subdomains are expected, and addition of any such subdomains requires the publication of an IETF standards-track RFC. No A, AAAA or PTR record is requested. 11.1. CoJP Parameters Registry This section defines a sub-registry within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Protocol Parameters Registry". The columns of the registry are: Name: This is a descriptive name that enables an easier reference to the item. It is not used in the encoding. Label: The value to be used to identify this parameter. The label is an integer. CBOR type: This field contains the CBOR type for the field. Vucinic, et al. Expires June 12, 2020 [Page 42] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 Description: This field contains a brief description for the field. Reference: This field contains a pointer to the public specification for the field, if one exists. This registry is to be populated with the values in Table 4. The amending formula for this sub-registry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. 11.2. CoJP Key Usage Registry This section defines a sub-registry within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Protocol Key Usage Registry". The columns of this registry are: Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. Value: This is the value used to identify the key usage setting. These values MUST be unique. The value is an integer. Algorithm: This is a descriptive name of the link-layer algorithm in use and uniquely determines the key length. The name is not used in the encoding. Description: This field contains a description of the key usage setting. The field should describe in enough detail how the key is to be used with different frame types, specific for the link-layer technology in question. Reference: This contains a pointer to the public specification for the field, if one exists. This registry is to be populated with the values in Table 5. The amending formula for this sub-registry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are Vucinic, et al. Expires June 12, 2020 [Page 43] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 designated as Expert Review. Integer values less than -65536 are marked as Private Use. 11.3. CoJP Unsupported Configuration Code Registry This section defines a sub-registry within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name "Constrained Join Protocol Unsupported Configuration Code Registry". The columns of this registry are: Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding. Value: This is the value used to identify the diagnostic code. These values MUST be unique. The value is an integer. Description: This is a descriptive human-readable name. The description MUST be unique. It is not used in the encoding. Reference: This contains a pointer to the public specification for the field, if one exists. This registry is to be populated with the values in Table 6. The amending formula for this sub-registry is: Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use. 12. Acknowledgments The work on this document has been partially supported by the European Union's H2020 Programme for research, technological development and demonstration under grant agreements: No 644852, project ARMOUR; No 687884, project F-Interop and open-call project SPOTS; No 732638, project Fed4FIRE+ and open-call project SODA. The following individuals provided input to this document (in alphabetic order): Christian Amsuss, Tengfei Chang, Klaus Hartke, Tero Kivinen, Jim Schaad, Goeran Selander, Yasuyuki Tanaka, Pascal Thubert, William Vignat, Xavier Vilajosana, Thomas Watteyne. Vucinic, et al. Expires June 12, 2020 [Page 44] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 13. References 13.1. Normative References [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", draft-ietf-6tisch-architecture-28 (work in progress), October 2019. [I-D.ietf-core-stateless] Hartke, K., "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", draft-ietf-core- stateless-03 (work in progress), October 2019. [IEEE802.15.4] IEEE standard for Information Technology, ., "IEEE Std 802.15.4 Standard for Low-Rate Wireless Networks", n.d.. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, . [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Vucinic, et al. Expires June 12, 2020 [Page 45] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, . [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, . [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . 13.2. Informative References Vucinic, et al. Expires June 12, 2020 [Page 46] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 [I-D.ietf-6tisch-msf] Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", draft-ietf-6tisch-msf-08 (work in progress), November 2019. [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), July 2017. [I-D.ietf-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures", draft-ietf-cbor- cddl-08 (work in progress), March 2019. [I-D.ietf-cbor-sequence] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", draft-ietf-cbor-sequence-02 (work in progress), September 2019. [NIST800-90A] NIST Special Publication 800-90A, Revision 1, ., Barker, E., and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", 2015. [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . Vucinic, et al. Expires June 12, 2020 [Page 47] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018, . Appendix A. Example Figure 3 illustrates a successful join protocol exchange. The pledge instantiates the OSCORE context and derives the OSCORE keys and nonces from the PSK. It uses the instantiated context to protect the Join Request addressed with a Proxy-Scheme option, the well-known host name of the JRC in the Uri-Host option, and its EUI-64 as pledge identifier and OSCORE kid context. Triggered by the presence of a Proxy-Scheme option, the JP forwards the request to the JRC and sets the CoAP token to the internally needed state. The JP has learned the IPv6 address of the JRC when it acted as a pledge and joined the network. Once the JRC receives the request, it looks up the correct context based on the kid context parameter. The OSCORE data authenticity verification ensures that the request has not been modified in transit. In addition, replay protection is ensured through persistent handling of mutable context parameters. Once the JP receives the Join Response, it authenticates the state within the CoAP token before deciding where to forward. The JP sets its internal state to that found in the token, and forwards the Join Response to the correct pledge. Note that the JP does not possess Vucinic, et al. Expires June 12, 2020 [Page 48] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 the key to decrypt the CoJP object (configuration) present in the payload. The Join Response is matched to the Join Request and verified for replay protection at the pledge using OSCORE processing rules. In this example, the Join Response does not contain the IPv6 address of the JRC, the pledge hence understands the JRC is co- located with the 6LBR. Vucinic, et al. Expires June 12, 2020 [Page 49] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 <---E2E OSCORE--> Client Proxy Server Pledge JP JRC | | | | Join | | Code: 0.02 (POST) | Request | | Token: - +--------->| | Proxy-Scheme: coap | | | Uri-Host: 6tisch.arpa | | | OSCORE: kid: -, | | | kid_context: EUI-64, | | | Partial IV: 1 | | | Payload: { Code: 0.02 (POST), | | | Uri-Path: "j", | | | join_request, } | | | | | Join | Code: 0.02 (POST) | | Request | Token: opaque state | +--------->| OSCORE: kid: -, | | | kid_context: EUI-64, | | | Partial IV: 1 | | | Payload: { Code: 0.02 (POST), | | | Uri-Path: "j", | | | join_request, } | | | | | | | | Join | Code: 2.04 (Changed) | | Response | Token: opaque state | |<---------+ OSCORE: - | | | Payload: { Code: 2.04 (Changed), | | | configuration, } | | | | | | | Join | | Code: 2.04 (Changed) | Response | | Token: - |<---------+ | OSCORE: - | | | Payload: { Code: 2.04 (Changed), | | | configuration, } | | | Figure 3: Example of a successful join protocol exchange. { ... } denotes authenticated encryption, denotes the authentication tag. Where the join_request object is: Vucinic, et al. Expires June 12, 2020 [Page 50] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 join_request: { 5 : h'cafe' / PAN ID of the network pledge is attempting to join / } Since the role parameter is not present, the default role of "6TiSCH Node" is implied. The join_request object encodes to h'a10542cafe' with a size of 5 bytes. And the configuration object is: configuration: { 2 : [ / link-layer key set / 1, / key_id / h'e6bf4287c2d7618d6a9687445ffd33e6' / key_value / ], 3 : [ / short identifier / h'af93' / assigned short address / ] } Since the key_usage parameter is not present in the link-layer key set object, the default value of "6TiSCH-K1K2-ENC-MIC32" is implied. Since key_addinfo parameter is not present and key_id is different than 0, Key ID Mode 0x01 (Key Index) is implied. Similarly, since the lease_time parameter is not present in the short identifier object, the default value of positive infinity is implied. The configuration object encodes to h'a202820150e6bf4287c2d7618d6a9687445ffd33e6038142af93' with a size of 26 bytes. Appendix B. Lightweight Implementation Option In environments where optimizing the implementation footprint is important, it is possible to implement this specification without having the implementations of HKDF [RFC5869] and SHA [RFC4231] on constrained devices. HKDF and SHA are used during the OSCORE security context derivation phase. This derivation can also be done by the JRC or a provisioning device, on behalf of the (6LBR) pledge during the provisioning phase. In that case, the derived OSCORE security context parameters are written directly into the (6LBR) pledge, without requiring the PSK be provisioned to the (6LBR) pledge. Vucinic, et al. Expires June 12, 2020 [Page 51] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 The use of HKDF to derive OSCORE security context parameters ensures that the resulting OSCORE keys have good security properties, and are unique as long as the input for different pledges varies. This specification ensures the uniqueness by mandating unique pledge identifiers and a unique PSK for each (6LBR) pledge. From the AEAD nonce reuse viewpoint, having a unique pledge identifier is a sufficient condition. However, as discussed in Section 9, the use of a single PSK shared among many devices is a common security pitfall. The compromise of this shared PSK on a single device would lead to the compromise of the entire batch. When using the implementation/ deployment scheme outlined above, the PSK does not need to be written to individual pledges. As a consequence, even if a shared PSK is used, the scheme offers a comparable level of security as in the scenario where each pledge is provisioned with a unique PSK. In this case, there is still a latent risk of the shared PSK being compromised from the provisioning device, which would compromise all devices in the batch. Authors' Addresses Malisa Vucinic (editor) Inria 2 Rue Simone Iff Paris 75012 France Email: malisa.vucinic@inria.fr Jonathan Simon Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 USA Email: jonathan.simon@analog.com Kris Pister University of California Berkeley 512 Cory Hall Berkeley, CA 94720 USA Email: pister@eecs.berkeley.edu Vucinic, et al. Expires June 12, 2020 [Page 52] Internet-Draft Constrained Join Protocol (CoJP) for 6TiSCH December 2019 Michael Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z5V7 Canada Email: mcr+ietf@sandelman.ca Vucinic, et al. Expires June 12, 2020 [Page 53] ./draft-ietf-ice-pac-06.txt0000644000764400076440000003725613652324356014705 0ustar iustyiusty ICE Working Group C. Holmberg Internet-Draft Ericsson Updates: 8445 (if approved) J. Uberti Intended status: Standards Track Google Expires: October 31, 2020 April 29, 2020 Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) draft-ietf-ice-pac-06 Abstract During the process of establishing peer-to-peer connectivity, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and updates RFC8445 and RFC XXXX by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check. [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published. Please also indicate that this specification updates RFC XXXX.] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 31, 2020. Holmberg & Uberti Expires October 31, 2020 [Page 1] Internet-Draft ICE PAC April 2020 Copyright Notice Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Relevant Scenarios . . . . . . . . . . . . . . . . . . . . . 3 3.1. No Candidates From Peer . . . . . . . . . . . . . . . . . 3 3.2. All Candidates Discarded . . . . . . . . . . . . . . . . 4 3.3. Immediate Candidate Pair Failure . . . . . . . . . . . . 4 4. Update to RFC 8445 . . . . . . . . . . . . . . . . . . . . . 4 5. Update to RFC XXXX . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [RFC8445] describes a protocol, Interactive Connectivity Establishment (ICE), for Network Address Translator (NAT) traversal for UDP-based communication. When using ICE, endpoints will typically exchange ICE candidates, form a list of candidate pairs, and then test each candidate pair to see if connectivity can be established. If the test for a given pair fails, it is marked accordingly, and if all pairs have failed, the overall ICE process typically is considered to have failed. During the process of connectivity checks, additional candidates may be created as a result of successful inbound checks from the remote peer. Such candidates are referred to as peer-reflexive candidates, and once discovered, will be used to form new candidate pairs which will be tested like any other. However, there is an inherent problem Holmberg & Uberti Expires October 31, 2020 [Page 2] Internet-Draft ICE PAC April 2020 here; if, before learning about any peer-reflexive candidates, an endpoint runs out of candidate pairs to check, either because it has none, or it considers them all to have failed, it will prematurely declare failure and terminate ICE processing. This problem can occur in many common situations. This specification updates [RFC8445], by simply requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs to check, or if all candidate pairs have failed. This delay provides enough time for the discovery of peer-reflexive candidates, which may eventually lead to ICE processing completing successfully. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Relevant Scenarios As noted above, the core problem this specification attempts to address is the situation where even after local gathering and remote candidate signaling has completed, the ICE agent immediately ends up with no valid pairs and no candidate pairs left to check, resulting in a premature ICE failure. This failure is premature because not enough time has elapsed to allow for discovery of peer-reflexive candidates from inbound connectivity checks; if discovered, these candidates are very likely to result in a valid pair. In most ICE scenarios, the lengthy timeouts for connectivity check transactions, typically tens of seconds, will prevent this problem from occurring. However, there are certain specific cases where this problem will frequently occur. 3.1. No Candidates From Peer Per RFC XXXX, an ICE agent can provide zero candidates of its own. If the agent somehow knows that the remote endpoint is directly reachable, gathering local candidates is unnecessary and will only cause delays; the peer agent can discover the appropriate local candidate via connectivity checks. However, following the procedures from [RFC8445] strictly will result in immediate ICE failure, since the checklist at the peer agent will be empty. Holmberg & Uberti Expires October 31, 2020 [Page 3] Internet-Draft ICE PAC April 2020 3.2. All Candidates Discarded Even if the ICE agent provides candidates, they may be discarded by the peer agent if it does not know what to do with them. For example, candidates may use an address family that the peer agent does not support, (e.g., a host candidate with an IPv6 address in a NAT64 scenario), or may not be usable for some other reason. In these scenarios, when the candidates are discarded, the checklist at the peer agent will once again be empty, leading to immediate ICE failure. 3.3. Immediate Candidate Pair Failure Section 7.2.5.2 of [RFC8445] describes several situations in which a candidate pair will be considered to have failed, well before the connectivity check transaction timeout. As a result, even if the ICE agent provides usable candidates, the pairs created by the peer agent may fail immediately when checked, e.g., a check to a non-routable address that receives an immediate ICMP error. In this situation, the checklist at the peer agent may contain only failed pairs, resulting in immediate ICE failure. 4. Update to RFC 8445 In order to avoid the problem raised by this document, the ICE agent needs to wait enough time to allow peer-reflexive candidates to be discovered. Accordingly, when a full ICE implementation begins its ICE processing, as described in [RFC8445], Section 6.1, it MUST set a timer, henceforth known as the PAC timer, to ensure ICE will run for a minimum amount of time before determining failure. Specifically, the ICE agent will start its timer once it believes ICE connectivity checks are starting. This occurs when the agent has sent the values needed to perform connectivity checks (e.g., the Username Fragment and Password denoted in [RFC8445], Section 5.3) and has received some indication that the remote side is ready to start connectivity checks, typically via receipt of the values mentioned above. Note that the agent will start the timer even if it has not sent or received any ICE candidates. The RECOMMENDED duration for the PAC timer is equal to the agent's connectivity check transaction timeout, including all retransmissions. When using default values for RTO and Rc, this amounts to 39.5 seconds, as explained in [RFC5389], Section 7.2.1. Holmberg & Uberti Expires October 31, 2020 [Page 4] Internet-Draft ICE PAC April 2020 This timeout value is chosen to roughly coincide with the maximum possible duration of ICE connectivity checks from the remote peer, which, if successful, could create peer-reflexive candidates. Because the ICE agent doesn't know the exact number of candidate pairs and pacing interval in use by the remote side, this timeout value is simply a guess, albeit an educated one. Regardless, for this particular problem, the desired benefits will be realized as long as the agent waits some reasonable amount of time, and, as usual, the application is in the best position to determine what is reasonable for its scenario. While the timer is still running, the ICE agent MUST NOT update a checklist state from Running to Failed, even if there are no pairs left in the checklist to check. As a result, the ICE agent will not remove any data streams or set the state of the ICE session to Failed as long as the timer is running. When the timer eventually elapses, the ICE agent MUST resume typical ICE processing, including setting the state of any checklists to Failed if they have no pairs left to check, and handling any consequences as indicated in [RFC8445], Section 8.1.2. Naturally, if there are no such checklists, no action is necessary. One consequence of this behavior is that in cases where ICE should fail, e.g., where both sides provide candidates with unsupported address families, ICE will no longer fail immediately, and only fail when the PAC timer expires. However, because most ICE scenarios require an extended period of time to determine failure, the fact that some specific scenarios no longer fail fast should have minimal application impact, if any. Note also that the PAC timer is potentially relevant to the ICE nomination procedure described in [RFC8445], Section 8.1.1. That specification does not define a minimum duration for ICE processing prior to nomination of a candidate pair, but in order to select the best candidate pair, ICE needs to run for enough time in order to allow peer-reflexive candidates to be discovered and checked, as noted above. Accordingly, the controlling ICE agent SHOULD wait a sufficient amount of time before nominating candidate pairs, and it MAY use the PAC timer to do so. As always, the controlling ICE agent retains full discretion, and MAY decide, based on its own criteria, to nominate pairs prior to the PAC timer elapsing. 5. Update to RFC XXXX [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published.] Holmberg & Uberti Expires October 31, 2020 [Page 5] Internet-Draft ICE PAC April 2020 Trickle ICE [I-D.ietf-ice-trickle] considers a similar problem, namely whether an ICE agent should allow a checklist to enter the Failed state if more candidates might still be provided by the remote peer. The solution, specified in [I-D.ietf-ice-trickle], Section 8, is to wait until an end-of-candidates indication has been received before determining ICE failure. However, for the same reasons described above, the ICE agent may discover peer-reflexive candidates after it has received the end-of- candidates indication, and so the solution proposed by this document MUST still be used even when the ICE agent is using Trickle ICE. Note also that sending an end-of-candidates indication is only a SHOULD-strength requirement, which means that ICE agents will need to implement a backup mechanism to decide when all candidates have been received, typically a timer. Accordingly, ICE agents MAY use the PAC timer to also serve as an end-of-candidates fallback. 6. Security Considerations The security considerations for ICE are defined in [RFC8445]. This specification only recommends that ICE agents wait for a certain time of period before they declare ICE failure, and does not introduce new security considerations. 7. IANA considerations This specification makes no requests to IANA. 8. Acknowledgements Roman Shpount, Nils Ohlmeier and Peter Thatcher provided lots of useful input and comments. 9. 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, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . Holmberg & Uberti Expires October 31, 2020 [Page 6] Internet-Draft ICE PAC April 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Justin Uberti Google 747 6th St W Kirkland 98033 USA Email: justin@uberti.name Holmberg & Uberti Expires October 31, 2020 [Page 7] ./draft-ietf-6tisch-msf-18.txt0000644000764400076440000014427213727217353015370 0ustar iustyiusty 6TiSCH T. Chang, Ed. Internet-Draft M. Vucinic Intended status: Standards Track Inria Expires: March 16, 2021 X. Vilajosana Universitat Oberta de Catalunya S. Duquennoy RISE SICS D. Dujovne Universidad Diego Portales September 12, 2020 6TiSCH Minimal Scheduling Function (MSF) draft-ietf-6tisch-msf-18 Abstract This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 16, 2021. Chang, et al. Expires March 16, 2021 [Page 1] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 Copyright Notice Copyright (c) 2020 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 (https://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. Interface to the Minimal 6TiSCH Configuration . . . . . . . . 4 3. Autonomous Cells . . . . . . . . . . . . . . . . . . . . . . 5 4. Node Behavior at Boot . . . . . . . . . . . . . . . . . . . . 6 4.1. Start State . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Step 1 - Choosing Frequency . . . . . . . . . . . . . . . 7 4.3. Step 2 - Receiving EBs . . . . . . . . . . . . . . . . . 7 4.4. Step 3 - Setting up Autonomous Cells for the Join Process . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Step 4 - Acquiring a RPL Rank . . . . . . . . . . . . . . 8 4.6. Step 5 - Setting up first Tx negotiated Cells . . . . . . 8 4.7. Step 6 - Send EBs and DIOs . . . . . . . . . . . . . . . 8 4.8. End State . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Rules for Adding/Deleting Cells . . . . . . . . . . . . . . . 9 5.1. Adapting to Traffic . . . . . . . . . . . . . . . . . . . 9 5.2. Switching Parent . . . . . . . . . . . . . . . . . . . . 11 5.3. Handling Schedule Collisions . . . . . . . . . . . . . . 11 6. 6P SIGNAL command . . . . . . . . . . . . . . . . . . . . . . 13 7. Scheduling Function Identifier . . . . . . . . . . . . . . . 13 8. Rules for CellList . . . . . . . . . . . . . . . . . . . . . 13 9. 6P Timeout Value . . . . . . . . . . . . . . . . . . . . . . 14 10. Rule for Ordering Cells . . . . . . . . . . . . . . . . . . . 14 11. Meaning of the Metadata Field . . . . . . . . . . . . . . . . 14 12. 6P Error Handling . . . . . . . . . . . . . . . . . . . . . . 14 13. Schedule Inconsistency Handling . . . . . . . . . . . . . . . 15 14. MSF Constants . . . . . . . . . . . . . . . . . . . . . . . . 15 15. MSF Statistics . . . . . . . . . . . . . . . . . . . . . . . 16 16. Security Considerations . . . . . . . . . . . . . . . . . . . 16 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 17.1. MSF Scheduling Function Identifiers . . . . . . . . . . 18 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Chang, et al. Expires March 16, 2021 [Page 2] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 19.1. Normative References . . . . . . . . . . . . . . . . . . 18 19.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Example of Implementation of SAX hash function . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The 6TiSCH Minimal Scheduling Function (MSF), defined in this specification, is a 6TiSCH Scheduling Function (SF). The role of an SF is entirely defined in [RFC8480]. This specification complements [RFC8480] by providing the rules of when to add/delete cells in the communication schedule. This specification satisfies all the requirements for an SF listed in Section 4.2 of [RFC8480]. MSF builds on top of the following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. MSF defines both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. When a node running MSF boots up, it joins the network by following the 6 steps described in Section 4. The end state of the join process is that the node is synchronized to the network, has mutually authenticated with the network, has identified a routing parent, and has scheduled one negotiated Tx cell (defined in Section 5.1) to/from its routing parent. After the join process, the node can continuously add/delete/relocate cells, as described in Section 5. It does so for 3 reasons: to match the link-layer resources to the traffic, to handle changing parent and to handle a schedule collision. MSF works closely with the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), specifically the routing parent defined in [RFC6550]. This specification only describes how MSF works with the routing parent; this parent is referred to as the "selected parent". The activity of MSF towards the single routing parent is called a "MSF session". Though the performance of MSF is evaluated only when the "selected parent" represents the node's preferred parent, there should be no restrictions to use multiple MSF sessions, one per parent. The distribution of traffic over multiple parents is a routing decision that is out of scope for MSF. MSF is designed to operate in a wide range of application domains. It is optimized for applications with regular upstream traffic, from the nodes to the Destination-Oriented Directed Acyclic Graph (DODAG [RFC6550]) root. Chang, et al. Expires March 16, 2021 [Page 3] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 This specification follows the recommended structure of an SF specification, given in Appendix A of [RFC8480], with the following adaptations: * We have reordered some sections, in particular to have the section on the node behavior at boot (Section 4) appear early in this specification. * We added sections on the interface to the minimal 6TiSCH configuration (Section 2), the use of the SIGNAL command (Section 6), the MSF constants (Section 14) and the MSF statistics (Section 15). 2. Interface to the Minimal 6TiSCH Configuration In a TSCH network, time is sliced up into time slots. The time slots are grouped as one or multiple slotframes which repeat over time. The TSCH schedule instructs a node what to do at each time slot, such as transmit, receive or sleep [RFC7554]. In case of a slot to transmit or receive, a channel is assigned to the time slot. The tuple (slot, channel) is indicated as a cell of TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule. A node implementing MSF SHOULD implement the Minimal 6TiSCH Configuration [RFC8180], which defines the "minimal cell", a single shared cell providing minimal connectivity between the nodes in the network. The MSF implementation provided in this specification is based on the implementation of the Minimal 6TiSCH Configuration. However, an implementor MAY implement MSF based on other specifications as long as the specification defines a way to advertise the EB/DIO among the network. MSF uses the minimal cell for broadcast frames such as Enhanced Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects (DIOs) [RFC6550]. Cells scheduled by MSF are meant to be used only for unicast frames. To ensure there is enough bandwidth available on the minimal cell, a node implementing MSF SHOULD enforce some rules for limiting the traffic of broadcast frames. For example, the overall broadcast traffic among the node and its neighbors SHOULD NOT exceed 1/3 of the bandwidth of minimal cell. One of the algorithms that fulfills this requirement is the Trickle timer defined in [RFC6206] which is applied on DIO messages [RFC6550]. However, any such algorithm of limiting the broadcast traffic to meet those rules is implementation- specific and is out of the scope of MSF. Chang, et al. Expires March 16, 2021 [Page 4] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 3 slotframes are used in MSF. MSF schedules autonomous cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe 2 (Section 5) ,while Slotframe 0 is used for the bootstrap traffic as defined in the Minimal 6TiSCH Configuration. The same slotframe length for Slotframe 0, 1 and 2 is RECOMMENDED. Thus it is possible to avoid the scheduling collision between the autonomous cells and 6P negotiated cells (Section 3). The default slotframe length (SLOTFRAME_LENGTH) is RECOMMENDED for Slotframe 0, 1 and 2, although any value can be advertised in the EBs. 3. Autonomous Cells MSF nodes initialize Slotframe 1 with a set of default cells for unicast communication with their neighbors. These cells are called 'autonomous cells', because they are maintained autonomously by each node without negotiation through 6P. Cells scheduled by 6P transaction are called 'negotiated cells' which are reserved on Slotframe 2. How to schedule negotiated cells is detailed in Section 5. There are two types of autonomous cells: * Autonomous Rx Cell (AutoRxCell), one cell at a [slotOffset,channelOffset] computed as a hash of the EUI64 of the node itself (detailed next). Its cell options bits are assigned as TX=0, RX=1, SHARED=0. * Autonomous Tx Cell (AutoTxCell), one cell at a [slotOffset,channelOffset] computed as a hash of the layer 2 EUI64 destination address in the unicast frame to be transmitted (detailed in Section 4.4). Its cell options bits are assigned as TX=1, RX=0, SHARED=1. To compute a [slotOffset,channelOffset] from an EUI64 address, nodes MUST use the hash function SAX as defined in Section 2 of [SAX-DASFAA] with consistent input parameters, for example, those defined in Appendix A. The coordinates are computed to distribute the cells across all channel offsets, and all but the first slot offset of Slotframe 1. The first time offset is skipped to avoid colliding with the minimal cell in Slotframe 0. The slot coordinates derived from a given EUI64 address are computed as follows: * slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) * channelOffset(MAC) = hash(EUI64, NUM_CH_OFFSET) The second input parameter defines the maximum return value of the hash function. Other optional parameters defined in SAX determine the performance of SAX hash function. Those parameters could be broadcasted in EB frame or pre-configured. For interoperability purposes, the values of those parameters can be referred from Appendix A. Chang, et al. Expires March 16, 2021 [Page 5] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 AutoTxCell is not permanently installed in the schedule but added/ deleted on demand when there is a frame to be sent. Throughout the network lifetime, nodes maintain the autonomous cells as follows: * Add an AutoTxCell to the layer 2 destination address which is indicated in a frame when there is no 6P negotiated Tx cell in schedule for that frame to transmit. * Remove an AutoTxCell when: - there is no frame to transmit on that cell, or - there is at least one 6P negotiated Tx cell in the schedule for the frames to transmit. The AutoRxCell MUST always remain scheduled after synchronization. 6P CLEAR MUST NOT erase any autonomous cells. Because of hash collisions, there will be cases that the AutoTxCell and AutoRxCell are scheduled at the same slot offset and/or channel offset. In such cases, AutoTxCell always take precedence over AutoRxCell. Notice AutoTxCell is a shared type cell which applies backs-off mechanism. When the AutoTxCell and AutoRxCell collide, AutoTxCell takes precedence if there is a packet to transmit. When in a back-off period, AutoRxCell is used. In case of conflicting with a negotiated cell, autonomous cells take precedence over negotiated cells, which is stated in [IEEE802154]. However, when the Slotframe 0, 1 and 2 use the same length value, it is possible for a negotiated cell to avoid the collision with AutoRxCell. Hence, the same slotframe length for Slotframe 0, 1 and 2 is RECOMMENDED. 4. Node Behavior at Boot This section details the behavior the node SHOULD follow from the moment it is switched on, until it has successfully joined the network. Alternative behaviors may be involved, for example, when alternative security solutions are used for the network. Section 4.1 details the start state; Section 4.8 details the end state. The other sections detail the 6 steps of the joining process. We use the term "pledge" and "joined node", as defined in [I-D.ietf-6tisch-minimal-security]. 4.1. Start State A node implementing MSF SHOULD implement the Constrained Join Protocol (CoJP) for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this means that a pledge, before being switched on, may be pre-configured with the Pre-Shared Key (PSK) for joining, as well as any other configuration detailed in ([I-D.ietf-6tisch-minimal-security]). This is not necessary if the Chang, et al. Expires March 16, 2021 [Page 6] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 node implements a security solution not based on PSKs, such as ([I-D.ietf-6tisch-dtsecurity-zerotouch-join]). 4.2. Step 1 - Choosing Frequency When switched on, the pledge randomly chooses a frequency from the channels that the network cycles amongst, and starts listening for EBs on that frequency. 4.3. Step 2 - Receiving EBs Upon receiving the first EB, the pledge continues listening for additional EBs to learn: 1. the number of neighbors N in its vicinity 2. which neighbor to choose as a Join Proxy (JP) for the joining process After having received the first EB, a node MAY keep listening for at most MAX_EB_DELAY seconds or until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors. This behavior is defined in [RFC8180]. During this step, the pledge only gets synchronized when it received enough EB from the network it wishes to join. How to decide whether an EB originates from a node from the network it wishes to join is implementation-specific, but MAY involve filtering EBs by the PAN ID field it contains, the presence and contents of the IE defined in [I-D.ietf-6tisch-enrollment-enhanced-beacon], or the key used to authenticate it. The decision of which neighbor to use as a JP is implementation- specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 4.4. Step 3 - Setting up Autonomous Cells for the Join Process After having selected a JP, a node generates a Join Request and installs an AutoTxCell to the JP. The Join Request is then sent by the pledge to its selected JP over the AutoTxCell. The AutoTxCell is removed by the pledge when the Join Request is sent out. The JP receives the Join Request through its AutoRxCell. Then it forwards the Join Request to the join registrar/coordinator (JRC), possibly over multiple hops, over the 6P negotiated Tx cells. Similarly, the JRC sends the Join Response to the JP, possibly over multiple hops, over AutoTxCells or the 6P negotiated Tx cells. When the JP received the Join Response from the JRC, it installs an AutoTxCell to the pledge and sends that Join Response to the pledge over AutoTxCell. The AutoTxCell is removed by the JP when the Join Response is sent Chang, et al. Expires March 16, 2021 [Page 7] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 out. The pledge receives the Join Response from its AutoRxCell, thereby learns the keying material used in the network, as well as other configuration settings, and becomes a "joined node". When 6LoWPAN Neighbor Discovery ([RFC8505]) (ND) is implemented, the unicast packets used by ND are sent on the AutoTxCell. The specific process how the ND works during the Join process is detailed in [I-D.ietf-6tisch-architecture]. 4.5. Step 4 - Acquiring a RPL Rank Per [RFC6550], the joined node receives DIOs, computes its own Rank, and selects a routing parent. 4.6. Step 5 - Setting up first Tx negotiated Cells Once it has selected a routing parent, the joined node MUST generate a 6P ADD Request and install an AutoTxCell to that parent. The 6P ADD Request is sent out through the AutoTxCell, containing the following fields: * CellOptions: set to TX=1,RX=0,SHARED=0 * NumCells: set to 1 * CellList: at least 5 cells, chosen according to Section 8 The joined node removes the AutoTxCell to the selected parent when the 6P Request is sent out. That parent receives the 6P ADD Request from its AutoRxCell. Then it generates a 6P ADD Response and installs an AutoTxCell to the joined node. When the parent sends out the 6P ADD Response, it MUST remove that AutoTxCell. The joined node receives the 6P ADD Response from its AutoRxCell and completes the 6P transaction. In case the 6P ADD transaction failed, the node MUST issue another 6P ADD Request and repeat until the Tx cell is installed to the parent. 4.7. Step 6 - Send EBs and DIOs The node starts sending EBs and DIOs on the minimal cell, while following the transmit rules for broadcast frames from Section 2. 4.8. End State For a new node, the end state of the joining process is: * it is synchronized to the network * it is using the link-layer keying material it learned through the secure joining process * it has selected one neighbor as its routing parent Chang, et al. Expires March 16, 2021 [Page 8] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 * it has one AutoRxCell * it has one negotiated Tx cell to the selected parent * it starts to send DIOs, potentially serving as a router for other nodes' traffic * it starts to send EBs, potentially serving as a JP for new pledges 5. Rules for Adding/Deleting Cells Once a node has joined the 6TiSCH network, it adds/deletes/relocates cells with the selected parent for three reasons: * to match the link-layer resources to the traffic between the node and the selected parent (Section 5.1) * to handle switching parent or(Section 5.2) * to handle a schedule collision (Section 5.3) Those cells are called 'negotiated cells' as they are scheduled through 6P, negotiated with the node's parent. Without specific declaration, all cells mentioned in this section are negotiated cells and they are installed at Slotframe 2. 5.1. Adapting to Traffic A node implementing MSF MUST implement the behavior described in this section. The goal of MSF is to manage the communication schedule in the 6TiSCH schedule in a distributed manner. For a node, this translates into monitoring the current usage of the cells it has to one of its neighbors, in most cases to the selected parent. * If the node determines that the number of link-layer frames it is attempting to exchange with the selected parent per unit of time is larger than the capacity offered by the TSCH negotiated cells it has scheduled with it, the node issues a 6P ADD command to that parent to add cells to the TSCH schedule. * If the traffic is lower than the capacity, the node issues a 6P DELETE command to that parent to delete cells from the TSCH schedule. The node MUST maintain two separate pairs of the following counters for the selected parent, one for the negotiated Tx cells to that parent and one for the negotiated Rx cells to that parent. NumCellsElapsed : Counts the number of negotiated cells that have Chang, et al. Expires March 16, 2021 [Page 9] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 elapsed since the counter was initialized. This counter is initialized at 0. When the current cell is declared as a negotiated cell to the selected parent, NumCellsElapsed is incremented by exactly 1, regardless of whether the cell is used to transmit/receive a frame. NumCellsUsed: Counts the number of negotiated cells that have been used. This counter is initialized at 0. NumCellsUsed is incremented by exactly 1 when, during a negotiated cell to the selected parent, either of the following happens: * The node sends a frame to the parent. The counter increments regardless of whether a link-layer acknowledgment was received or not. * The node receives a valid frame from the parent. The counter increments only when the frame is a valid IEEE802.15.4 frame. The cell option of cells listed in CellList in 6P Request frame SHOULD be either (Tx=1, Rx=0) only or (Tx=0, Rx=1) only. Both NumCellsElapsed and NumCellsUsed counters can be used for both type of negotiated cells. As there is no negotiated Rx Cell installed at initial time, the AutoRxCell is taken into account as well for downstream traffic adaptation. In this case: * NumCellsElapsed is incremented by exactly 1 when the current cell is AutoRxCell. * NumCellsUsed is incremented by exactly 1 when the node receives a frame from the selected parent on AutoRxCell. Implementors MAY choose to create the same counters for each neighbor, and add them as additional statistics in the neighbor table. The counters are used as follows: 1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when the node boots. 2. When the value of NumCellsElapsed reaches MAX_NUM_CELLS: * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a single cell to the selected parent * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a single cell to the selected parent * Reset both NumCellsElapsed and NumCellsUsed to 0 and go to step 2. The value of MAX_NUM_CELLS is chosen according to the traffic type of the network. Generally speaking, the larger the value MAX_NUM_CELLS is, the more accurate the cell usage is calculated. The 6P traffic Chang, et al. Expires March 16, 2021 [Page 10] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 overhead using a larger value of MAX_NUM_CELLS could be reduced as well. Meanwhile, the latency won't increase much by using a larger value of MAX_NUM_CELLS for periodic traffic type. For bursty traffic, larger value of MAX_NUM_CELLS indeed introduces higher latency. The latency caused by slight changes of traffic load can be absolved by the additional scheduled cells. In this sense, MSF is a scheduling function trading latency with energy by scheduling more cells than needed. Setting MAX_NUM_CELLS to a value at least 4x of the recent maximum number of cells used in a slot frame is RECOMMENDED. For example, a 2 packets/slotframe traffic load results an average 4 cells scheduled (2 cells are used), using at least the value of double number of scheduled cells (which is 8) as MAX_NUM_CELLS gives a good resolution on cell usage calculation. In case that a node booted or disappeared from the network, the cell reserved at the selected parent may be kept in the schedule forever. A clean-up mechanism MUST be provided to resolve this issue. The clean-up mechanism is implementation-specific. The goal is to confirm those negotiated cells are not used anymore by the associated neighbors and remove them from the schedule. 5.2. Switching Parent A node implementing MSF SHOULD implement the behavior described in this section. Part of its normal operation, the RPL routing protocol can have a node switch parent. The procedure for switching from the old parent to the new parent is: 1. the node counts the number of negotiated cells it has per slotframe to the old parent 2. the node triggers one or more 6P ADD commands to schedule the same number of negotiated cells with same cell options to the new parent 3. when that successfully completes, the node issues a 6P CLEAR command to its old parent For what type of negotiated cell should be installed first, it depends on which traffic has the higher priority, upstream or downstream, which is application-specific and out-of-scope of MSF. 5.3. Handling Schedule Collisions A node implementing MSF SHOULD implement the behavior described in this section. Other schedule collisions handling algorithm can be an alternative of the algorithm proposed in this section. Chang, et al. Expires March 16, 2021 [Page 11] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 Since scheduling is entirely distributed, there is a non-zero probability that two pairs of nearby neighbor nodes schedule a negotiated cell at the same [slotOffset,channelOffset] location in the TSCH schedule. In that case, data exchanged by the two pairs may collide on that cell. We call this case a "schedule collision". The node MUST maintain the following counters for each negotiated Tx cell to the selected parent: NumTx: Counts the number of transmission attempts on that cell. Each time the node attempts to transmit a frame on that cell, NumTx is incremented by exactly 1. NumTxAck: Counts the number of successful transmission attempts on that cell. Each time the node receives an acknowledgment for a transmission attempt, NumTxAck is incremented by exactly 1. Since both NumTx and NumTxAck are initialized to 0, we necessarily have NumTxAck <= NumTx. We call Packet Delivery Ratio (PDR) the ratio NumTxAck/NumTx; and represent it as a percentage. A cell with PDR=50% means that half of the frames transmitted are not acknowledged. Each time the node switches parent (or during the join process when the node selects a parent for the first time), both NumTx and NumTxAck MUST be reset to 0. They increment over time, as the schedule is executed and the node sends frames to that parent. When NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by 2. MAX_NUMTX needs to be a power of two to avoid division error. For example, when MAX_NUMTX is set to 256, from NumTx=255 and NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one frame is sent to the parent with an Acknowledgment received. This operation does not change the value of the PDR, but allows the counters to keep incrementing. The value of MAX_NUMTX is implementation-specific. The key for detecting a schedule collision is that, if a node has several cells to the selected parent, all cells should exhibit the same PDR. A cell which exhibits a PDR significantly lower than the others indicates than there are collisions on that cell. Every HOUSEKEEPINGCOLLISION_PERIOD, the node executes the following steps: 1. It computes, for each negotiated Tx cell with the parent (not for the autonomous cell), that cell's PDR. Chang, et al. Expires March 16, 2021 [Page 12] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 2. Any cell that hasn't yet had NumTx divided by 2 since it was last reset is skipped in steps 3 and 4. This avoids triggering cell relocation when the values of NumTx and NumTxAck are not statistically significant yet. 3. It identifies the cell with the highest PDR. 4. For any other cell, it compares its PDR against that of the cell with the highest PDR. If the subtraction difference between the PDR of the cell and the highest PDR is larger than RELOCATE_PDRTHRES, it triggers the relocation of that cell using a 6P RELOCATE command. The RELOCATION for negotiated Rx cells is not supported by MSF. 6. 6P SIGNAL command The 6P SIGNAL command is not used by MSF. 7. Scheduling Function Identifier The Scheduling Function Identifier (SFID) of MSF is IANA_6TISCH_SFID_MSF. How the value of IANA_6TISCH_SFID_MSF is chosen is described in Section 17. 8. Rules for CellList MSF uses 2-step 6P Transactions exclusively. 6P transactions are only initiated by a node towards its parent. As a result, the cells to put in the CellList of a 6P ADD command, and in the candidate CellList of a RELOCATE command, are chosen by the node initiating the 6P transaction. In both cases, the same rules apply: * The CellList is RECOMMENDED to have 5 or more cells. * Each cell in the CellList MUST have a different slotOffset value. * For each cell in the CellList, the node MUST NOT have any scheduled cell on the same slotOffset. * The slotOffset value of any cell in the CellList MUST NOT be the same as the slotOffset of the minimal cell (slotOffset=0). * The slotOffset of a cell in the CellList SHOULD be randomly and uniformly chosen among all the slotOffset values that satisfy the restrictions above. * The channelOffset of a cell in the CellList SHOULD be randomly and uniformly chosen in [0..numFrequencies], where numFrequencies represents the number of frequencies a node can communicate on. As a consequence of random cell selection, there is a non-zero chance that nodes in the vicinity installed cells with same slotOffset and channelOffset. An implementer MAY implement a strategy to monitor the candidate cells before adding them in CellList to avoid Chang, et al. Expires March 16, 2021 [Page 13] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 collision. For example, a node MAY maintain a candidate cell pool for the CellList. The candidate cells in the pool are pre-configured as Rx cells to promiscuously listen to detect transmissions on those cells. If IEEE802.15.4 transmissions are observed on one cell over multiple iterations of the schedule, that cell is probably used by a TSCH neighbor. It is moved out from the pool and a new cell is selected as a candidate cell. The cells in CellList are picked from the candidate pool directly when required. 9. 6P Timeout Value The timeout value is calculated for the worst case that a 6P response is received, which means the 6P response is sent out successfully at the very latest retransmission. And for each retransmission, it backs-off with largest value. Hence the 6P timeout value is calculated as ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH, where: * MAXBE, defined in IEEE802.15.4, is the maximum backoff exponent used * MAXRETRIES, defined in IEEE802.15.4, is the maximum retransmission times * SLOTFRAME_LENGTH represents the length of slotframe 10. Rule for Ordering Cells Cells are ordered slotOffset first, channelOffset second. The following sequence is correctly ordered (each element represents the [slottOffset,channelOffset] of a cell in the schedule): [1,3],[1,4],[2,0],[5,3],[6,0],[6,3],[7,9] 11. Meaning of the Metadata Field The Metadata field is not used by MSF. 12. 6P Error Handling Section 6.2.4 of [RFC8480] lists the 6P Return Codes. Figure 1 lists the same error codes, and the behavior a node implementing MSF SHOULD follow. Chang, et al. Expires March 16, 2021 [Page 14] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 +-----------------+----------------------+ | Code | RECOMMENDED behavior | +-----------------+----------------------+ | RC_SUCCESS | nothing | | RC_EOL | nothing | | RC_ERR | quarantine | | RC_RESET | quarantine | | RC_ERR_VERSION | quarantine | | RC_ERR_SFID | quarantine | | RC_ERR_SEQNUM | clear | | RC_ERR_CELLLIST | clear | | RC_ERR_BUSY | waitretry | | RC_ERR_LOCKED | waitretry | +-----------------+----------------------+ Figure 1: Recommended behavior for each 6P Error Code. The meaning of each behavior from Figure 1 is: nothing: Indicates that this Return Code is not an error. No error handling behavior is triggered. clear: Abort the 6P Transaction. Issue a 6P CLEAR command to that neighbor (this command may fail at the link layer). Remove all cells scheduled with that neighbor from the local schedule. quarantine: Same behavior as for "clear". In addition, remove the node from the neighbor and routing tables. Place the node's identifier in a quarantine list for QUARANTINE_DURATION. When in quarantine, drop all frames received from that node. waitretry: Abort the 6P Transaction. Wait for a duration randomly and uniformly chosen in [WAIT_DURATION_MIN,WAIT_DURATION_MAX]. Retry the same transaction. 13. Schedule Inconsistency Handling The behavior when schedule inconsistency is detected is explained in Figure 1, for 6P Return Code RC_ERR_SEQNUM. 14. MSF Constants Figure 2 lists MSF Constants and their RECOMMENDED values. Chang, et al. Expires March 16, 2021 [Page 15] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 +------------------------------+-------------------+ | Name | RECOMMENDED value | +------------------------------+-------------------+ | SLOTFRAME_LENGTH | 101 slots | | NUM_CH_OFFSET | 16 | | MAX_NUM_CELLS | 100 | | LIM_NUMCELLSUSED_HIGH | 75 | | LIM_NUMCELLSUSED_LOW | 25 | | MAX_NUMTX | 256 | | HOUSEKEEPINGCOLLISION_PERIOD | 1 min | | RELOCATE_PDRTHRES | 50 % | | QUARANTINE_DURATION | 5 min | | WAIT_DURATION_MIN | 30 s | | WAIT_DURATION_MAX | 60 s | +------------------------------+-------------------+ Figure 2: MSF Constants and their RECOMMENDED values. 15. MSF Statistics Figure 3 lists MSF Statistics and their RECOMMENDED width. +-----------------+-------------------+ | Name | RECOMMENDED width | +-----------------+-------------------+ | NumCellsElapsed | 1 byte | | NumCellsUsed | 1 byte | | NumTx | 1 byte | | NumTxAck | 1 byte | +-----------------+-------------------+ Figure 3: MSF Statistics and their RECOMMENDED width. 16. Security Considerations MSF defines a series of "rules" for the node to follow. It triggers several actions, that are carried out by the protocols defined in the following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation Sublayer Protocol (6P) [RFC8480], and the Constrained Join Protocol (CoJP) for 6TiSCH [I-D.ietf-6tisch-minimal-security]. Confidentiality and authentication of MSF control and data traffic are provided by these specifications whose security considerations continue to apply to MSF. In particular, MSF does not define a new protocol or packet format. Chang, et al. Expires March 16, 2021 [Page 16] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 MSF uses autonomous cells for initial bootstrap and the transport of join traffic. Autonomous cells are computed as a hash of nodes' EUI64 addresses. This makes the coordinates of autonomous cell an easy target for an attacker, as EUI64 addresses are visible on the wire and are not encrypted by the link-layer security mechanism. With the coordinates of autonomous cells available, the attacker can launch a selective jamming attack against any nodes' AutoRxCell. If the attacker targets a node acting as a JP, it can prevent pledges from using that JP to join the network. The pledge detects such a situation through the absence of a link-layer acknowledgment for its Join Request. As it is expected that each pledge will have more than one JP available to join the network, one available countermeasure for the pledge is to pseudo-randomly select a new JP when the link to the previous JP appears bad. Such strategy alleviates the issue of the attacker randomly jamming to disturb the network but does not help in case the attacker is targeting a particular pledge. In that case, the attacker can jam the AutoRxCell of the pledge, in order to prevent it from receiving the join response. This situation should be detected through the absence of a particular node from the network and handled by the network administrator through out-of-band means. MSF adapts to traffic containing packets from the IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2474]) value in its IPv6 header. The decision how to handle that packet belongs to the upper layer and is out of scope of MSF. As long as the decision is made to hand over to MAC layer to transmit, MSF will take that packet into account when adapting to traffic. Note that non-zero DSCP value may imply that the traffic is originated at unauthenticated pledges, referring to [I-D.ietf-6tisch-minimal-security]. The implementation at IPv6 layer SHOULD rate-limit this join traffic before it is passed to 6top sublayer where MSF can observe it. In case there is no rate limit for join traffic, intermediate nodes in the 6TiSCH network may be prone to a resource exhaustion attack, with the attacker injecting unauthenticated traffic from the network edge. The assumption is that the rate limiting function is aware of the available bandwidth in the 6top L3 bundle(s) towards a next hop, not directly from MSF, but from an interaction with the 6top sublayer that manages ultimately the bundles under MSF's guidance. How this rate-limit is implemented is out of scope of MSF. 17. IANA Considerations Chang, et al. Expires March 16, 2021 [Page 17] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 17.1. MSF Scheduling Function Identifiers This document adds the following number to the "6P Scheduling Function Identifiers" sub-registry, part of the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry, as defined by [RFC8480]: +----------------------+-----------------------------+-------------+ | SFID | Name | Reference | +----------------------+-----------------------------+-------------+ | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS | | | (MSF) | | +----------------------+-----------------------------+-------------+ Figure 4: New SFID in 6P Scheduling Function Identifiers subregistry. IANA_6TISCH_SFID_MSF is chosen from range 0-127, which is used for IETF Review or IESG Approval. 18. Contributors * Beshr Al Nahas (Chalmers University, beshr@chalmers.se) * Olaf Landsiedel (Chalmers University, olafl@chalmers.se) * Yasuyuki Tanaka (Inria-Paris, yasuyuki.tanaka@inria.fr) 19. References 19.1. Normative References [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, . [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Protocol (6P)", RFC 8480, DOI 10.17487/RFC8480, November 2018, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . Chang, et al. Expires March 16, 2021 [Page 18] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", Work in Progress, Internet-Draft, draft-ietf-6tisch-minimal- security-15, December 10, 2019, . [I-D.ietf-6tisch-enrollment-enhanced-beacon] Dujovne, D. and M. Richardson, "IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information", Work in Progress, Internet-Draft, draft- ietf-6tisch-enrollment-enhanced-beacon-14, February 21, 2020, . [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, Internet-Draft, draft-ietf-6tisch-architecture-28, October 29, 2019, . [IEEE802154] IEEE standard for Information Technology, "IEEE Std 802.15.4 Standard for Low-Rate Wireless Personal Area Networks (WPANs)", DOI 10.1109/IEEE P802.15.4-REVd/D01, . Chang, et al. Expires March 16, 2021 [Page 19] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 [SAX-DASFAA] Ramakrishna, M.V. and J. Zobel, "Performance in Practice of String Hashing Functions", DASFAA , DOI 10.1142/9789812819536_0023, 1997, . 19.2. Informative References [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, . [I-D.ietf-6tisch-dtsecurity-zerotouch-join] Richardson, M., "6tisch Zero-Touch Secure Join protocol", Work in Progress, Internet-Draft, draft-ietf-6tisch- dtsecurity-zerotouch-join-04, July 8, 2019, . [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, . [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, . Appendix A. Example of Implementation of SAX hash function Considering the interoperability, this section provides an example of implemention SAX hash function [SAX-DASFAA]. The input parameters of the function are: * T, which is the hashing table length * c, which is the characters of string s, to be hashed In MSF, the T is replaced by the length of slotframe 1. String s is replaced by the mote EUI64 address. The characters of the string c0, c1, ..., c7 are the 8 bytes of EUI64 address. The SAX hash function requires shift operation which is defined as follow: * L_shift(v,b), which refers to left shift variable v by b bits Chang, et al. Expires March 16, 2021 [Page 20] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 * R_shift(v,b), which refers to right shift variable v by b bits The steps to calculate the hash value of SAX hash function are: 1. initialize variable h to h0 and variable i to 0, where h is the intermediate hash value and i is the index of the bytes of EUI64 address 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci 3. calculate the result of exclusive or between the sum value in Step 2 and h 4. modulo the result of Step 3 by T 5. assign the result of Step 4 to h 6. increase i by 1 7. repeat Step2 to Step 6 until i reaches to 8 The value of variable h is the hash value of SAX hash function. The values of h0, l_bit and r_bit in Step 1 and 2 are configured as: * h0 = 0 * l_bit = 0 * r_bit = 1 The appropriate values of l_bit and r_bit could vary depending on the the set of motes' EUI64 address. How to find those values is out of the scope of this specification. Authors' Addresses Tengfei Chang (editor) Inria 2 rue Simone Iff 75012 Paris France Email: tengfei.chang@inria.fr Malisa Vucinic Inria 2 rue Simone Iff 75012 Paris France Email: malisa.vucinic@inria.fr Chang, et al. Expires March 16, 2021 [Page 21] Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) September 2020 Xavier Vilajosana Universitat Oberta de Catalunya 156 Rambla Poblenou 08018 Barcelona Catalonia Spain Email: xvilajosana@uoc.edu Simon Duquennoy RISE SICS Isafjordsgatan 22 164 29 Kista Sweden Email: simon.duquennoy@gmail.com Diego Dujovne Universidad Diego Portales Escuela de Informatica y Telecomunicaciones Av. Ejercito 441 Santiago Region Metropolitana Chile Phone: +56 (2) 676-8121 Email: diego.dujovne@mail.udp.cl Chang, et al. Expires March 16, 2021 [Page 22] ./draft-ietf-hip-rfc4423-bis-20.txt0000644000764400076440000040425213431243406016001 0ustar iustyiusty Network Working Group R. Moskowitz, Ed. Internet-Draft HTT Consulting Obsoletes: 4423 (if approved) M. Komu Intended status: Informational Ericsson Expires: August 18, 2019 February 14, 2019 Host Identity Protocol Architecture draft-ietf-hip-rfc4423-bis-20 Abstract This memo describes the Host Identity (HI) namespace, that provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of the HI namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The section on security considerations describe also measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers and trust on first use. This document incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signaling channel. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 18, 2019. Moskowitz & Komu Expires August 18, 2019 [Page 1] Internet-Draft Host Identity Protocol Architecture February 2019 Copyright Notice Copyright (c) 2019 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terms common to other documents . . . . . . . . . . . . . . 4 2.2. Terms specific to this and other HIP documents . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. A desire for a namespace for computing platforms . . . . . 8 4. Host Identity namespace . . . . . . . . . . . . . . . . . . . 9 4.1. Host Identifiers . . . . . . . . . . . . . . . . . . . . . 10 4.2. Host Identity Hash (HIH) . . . . . . . . . . . . . . . . . 11 4.3. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . . 11 4.4. Local Scope Identifier (LSI) . . . . . . . . . . . . . . . 12 4.5. Storing Host Identifiers in directories . . . . . . . . . . 13 5. New stack architecture . . . . . . . . . . . . . . . . . . . 14 5.1. On the multiplicity of identities . . . . . . . . . . . . . 15 6. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Base exchange . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. End-host mobility and multi-homing . . . . . . . . . . . . 17 6.3. Rendezvous mechanism . . . . . . . . . . . . . . . . . . . 18 6.4. Relay mechanism . . . . . . . . . . . . . . . . . . . . . . 18 Moskowitz & Komu Expires August 18, 2019 [Page 2] Internet-Draft Host Identity Protocol Architecture February 2019 6.5. Termination of the control plane . . . . . . . . . . . . . 18 7. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. HIP and NATs . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. HIP and Upper-layer checksums . . . . . . . . . . . . . . . 20 9. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. HIP policies . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Security considerations . . . . . . . . . . . . . . . . . . . 21 11.1. MiTM Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Protection against flooding attacks . . . . . . . . . . . 23 11.3. HITs used in ACLs . . . . . . . . . . . . . . . . . . . . 24 11.4. Alternative HI considerations . . . . . . . . . . . . . . 25 11.5. Trust On First Use . . . . . . . . . . . . . . . . . . . . 25 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 14. Changes from RFC 4423 . . . . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 15.2. Informative references . . . . . . . . . . . . . . . . . . 31 Appendix A. Design considerations . . . . . . . . . . . . . . . 38 A.1. Benefits of HIP . . . . . . . . . . . . . . . . . . . . . . 38 A.2. Drawbacks of HIP . . . . . . . . . . . . . . . . . . . . . 41 A.3. Deployment and adoption considerations . . . . . . . . . . 43 A.3.1. Deployment analysis . . . . . . . . . . . . . . . . . . . 43 A.3.2. HIP in 802.15.4 networks . . . . . . . . . . . . . . . . 44 A.3.3. HIP and Internet of Things . . . . . . . . . . . . . . . 44 A.3.4. Infrastructure Applications . . . . . . . . . . . . . . . 46 A.3.5. Management of Identities in a Commercial Product . . . . 47 A.4. Answers to NSRG questions . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction The Internet has two important global namespaces: Internet Protocol (IP) addresses and Domain Name Service (DNS) names. These two namespaces have a set of features and abstractions that have powered the Internet to what it is today. They also have a number of weaknesses. Basically, since they are all we have, we try to do too much with them. Semantic overloading and functionality extensions have greatly complicated these namespaces. The proposed Host Identity namespace is also a global namespace, and it fills an important gap between the IP and DNS namespaces. A Host Identity conceptually refers to a computing platform, and there may be multiple such Host Identities per computing platform (because the platform may wish to present a different identity to different communicating peers). The Host Identity namespace consists of Host Identifiers (HI). There is exactly one Host Identifier for each Host Identity (although there may be transient periods of time such as key Moskowitz & Komu Expires August 18, 2019 [Page 3] Internet-Draft Host Identity Protocol Architecture February 2019 replacement when more than one identifier may be active). While this text later talks about non-cryptographic Host Identifiers, the architecture focuses on the case in which Host Identifiers are cryptographic in nature. Specifically, the Host Identifier is the public key of an asymmetric key-pair. Each Host Identity uniquely identifies a single host, i.e., no two hosts have the same Host Identity. If two or more computing platforms have the same Host Identifier, then they are instantiating a distributed host. The Host Identifier can either be public (e.g., published in the DNS), or unpublished. Client systems will tend to have both public and unpublished Host Identifiers. There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that is identified. An Identifier, on the other hand, refers to the concrete bit pattern that is used in the identification process. Although the Host Identifiers could be used in many authentication systems, such as IKEv2 [RFC4306], the presented architecture introduces a new protocol, called the Host Identity Protocol (HIP), and a cryptographic exchange, called the HIP base exchange; see also Section 6. HIP provides for limited forms of trust between systems, enhances mobility, multi-homing and dynamic IP renumbering, aids in protocol translation / transition, and reduces certain types of denial-of-service (DoS) attacks. When HIP is used, the actual payload traffic between two HIP hosts is typically, but not necessarily, protected with ESP [RFC7402]. The Host Identities are used to create the needed ESP Security Associations (SAs) and to authenticate the hosts. When ESP is used, the actual payload IP packets do not differ in any way from standard ESP protected IP packets. Much has been learned about HIP [RFC6538] since [RFC4423] was published. This document expands Host Identities beyond use to enable IP connectivity and security to general interhost secure signalling at any protocol layer. The signal may establish a security association between the hosts, or simply pass information within the channel. 2. Terminology 2.1. Terms common to other documents Moskowitz & Komu Expires August 18, 2019 [Page 4] Internet-Draft Host Identity Protocol Architecture February 2019 +---------------+---------------------------------------------------+ | Term | Explanation | +---------------+---------------------------------------------------+ | Public key | The public key of an asymmetric cryptographic key | | | pair. Used as a publicly known identifier for | | | cryptographic identity authentication. Public is | | | a relative term here, ranging from "known to | | | peers only" to "known to the world." | | Private key | The private or secret key of an asymmetric | | | cryptographic key pair. Assumed to be known only | | | to the party identified by the corresponding | | | public key. Used by the identified party to | | | authenticate its identity to other parties. | | Public key | An asymmetric cryptographic key pair consisting | | pair | of public and private keys. For example, Rivest- | | | Shamir-Adleman (RSA), Digital Signature Algorithm | | | (DSA) and Elliptic Curve DSA (ECDSA) key pairs | | | are such key pairs. | | End-point | A communicating entity. For historical reasons, | | | the term 'computing platform' is used in this | | | document as a (rough) synonym for end-point. | +---------------+---------------------------------------------------+ 2.2. Terms specific to this and other HIP documents It should be noted that many of the terms defined herein are tautologous, self-referential or defined through circular reference to other terms. This is due to the succinct nature of the definitions. See the text elsewhere in this document and the base specification [RFC7401] for more elaborate explanations. Moskowitz & Komu Expires August 18, 2019 [Page 5] Internet-Draft Host Identity Protocol Architecture February 2019 +---------------+---------------------------------------------------+ | Term | Explanation | +---------------+---------------------------------------------------+ | Computing | An entity capable of communicating and computing, | | platform | for example, a computer. See the definition of | | | 'End-point', above. | | | | | HIP base | A cryptographic protocol; see also Section 6 | | exchange | | | | | | HIP packet | An IP packet that carries a 'Host Identity | | | Protocol' message. | | | | | Host Identity | An abstract concept assigned to a 'computing | | | platform'. See 'Host Identifier', below. | | | | | Host | A public key used as a name for a Host Identity. | | Identifier | | | | | | Host Identity | A name space formed by all possible Host | | namespace | Identifiers. | | | | | Host Identity | A protocol used to carry and authenticate Host | | Protocol | Identifiers and other information. | | | | | Host Identity | The cryptographic hash used in creating the Host | | Hash | Identity Tag from the Host Identifier. | | | | | Host Identity | A 128-bit datum created by taking a cryptographic | | Tag | hash over a Host Identifier plus bits to identify | | | which hash used. | | | | | Local Scope | A 32-bit datum denoting a Host Identity. | | Identifier | | | | | | Public Host | A published or publicly known Host Identifier | | Identifier | used as a public name for a Host Identity, and | | and Identity | the corresponding Identity. | | | | | Unpublished | A Host Identifier that is not placed in any | | Host | public directory, and the corresponding Host | | Identifier | Identity. Unpublished Host Identities are | | and Identity | typically short lived in nature, being often | | | replaced and possibly used just once. | | | | | Rendezvous | A mechanism used to locate mobile hosts based on | | Mechanism | their HIT. | +---------------+---------------------------------------------------+ Moskowitz & Komu Expires August 18, 2019 [Page 6] Internet-Draft Host Identity Protocol Architecture February 2019 3. Background The Internet is built from three principal components: computing platforms (end-points), packet transport (i.e., internetworking) infrastructure, and services (applications). The Internet exists to service two principal components: people and robotic services (silicon-based people, if you will). All these components need to be named in order to interact in a scalable manner. Here we concentrate on naming computing platforms and packet transport elements. There are two principal namespaces in use in the Internet for these components: IP addresses, and Domain Names. Domain Names provide hierarchically assigned names for some computing platforms and some services. Each hierarchy is delegated from the level above; there is no anonymity in Domain Names. Email, HTTP, and SIP addresses all reference Domain Names. The IP addressing namespace has been overloaded to name both interfaces (at layer-3) and endpoints (for the endpoint-specific part of layer-3, and for layer-4). In their role as interface names, IP addresses are sometimes called "locators" and serve as an endpoint within a routing topology. IP addresses are numbers that name networking interfaces, and typically only when the interface is connected to the network. Originally, IP addresses had long-term significance. Today, the vast number of interfaces use ephemeral and/or non-unique IP addresses. That is, every time an interface is connected to the network, it is assigned an IP address. In the current Internet, the transport layers are coupled to the IP addresses. Neither can evolve separately from the other. IPng deliberations were strongly shaped by the decision that a corresponding TCPng would not be created. There are three critical deficiencies with the current namespaces. Firstly, establishing initial contact and sustaining of data flows between two hosts can be challenging due to private address realms and ephemeral nature of addresses. Secondly, confidentiality is not provided in a consistent, trustable manner. Finally, authentication for systems and datagrams is not provided. All of these deficiencies arise because computing platforms are not well named with the current namespaces. Moskowitz & Komu Expires August 18, 2019 [Page 7] Internet-Draft Host Identity Protocol Architecture February 2019 3.1. A desire for a namespace for computing platforms An independent namespace for computing platforms could be used in end-to-end operations independent of the evolution of the internetworking layer and across the many internetworking layers. This could support rapid readdressing of the internetworking layer because of mobility, rehoming, or renumbering. If the namespace for computing platforms is based on public-key cryptography, it can also provide authentication services. If this namespace is locally created without requiring registration, it can provide anonymity. Such a namespace (for computing platforms) and the names in it should have the following characteristics: o The namespace should be applied to the IP 'kernel' or stack. The IP stack is the 'component' between applications and the packet transport infrastructure. o The namespace should fully decouple the internetworking layer from the higher layers. The names should replace all occurrences of IP addresses within applications (like in the Transport Control Block, TCB). This replacement can be handled transparently for legacy applications as the LSIs and HITs are compatible with IPv4 and IPv6 addresses [RFC5338]. However, HIP-aware applications require some modifications from the developers, who may employ networking API extensions for HIP [RFC6317]. o The introduction of the namespace should not mandate any administrative infrastructure. Deployment must come from the bottom up, in a pairwise deployment. o The names should have a fixed-length representation, for easy inclusion in datagram headers and existing programming interfaces (e.g the TCB). o Using the namespace should be affordable when used in protocols. This is primarily a packet size issue. There is also a computational concern in affordability. o Name collisions should be avoided as much as possible. The mathematics of the birthday paradox can be used to estimate the chance of a collision in a given population and hash space. In general, for a random hash space of size n bits, we would expect to obtain a collision after approximately 1.2*sqrt(2**n) hashes were obtained. For 64 bits, this number is roughly 4 billion. A hash size of 64 bits may be too small to avoid collisions in a Moskowitz & Komu Expires August 18, 2019 [Page 8] Internet-Draft Host Identity Protocol Architecture February 2019 large population; for example, there is a 1% chance of collision in a population of 640M. For 100 bits (or more), we would not expect a collision until approximately 2**50 (1 quadrillion) hashes were generated. With the currently used hash size of 96 bits [RFC7343], the figure is 2**48 (281 trillions). o The names should have a localized abstraction so that they can be used in existing protocols and APIs. o It must be possible to create names locally. When such names are not published, this can provide anonymity at the cost of making resolvability very difficult. o The namespace should provide authentication services. o The names should be long-lived, but replaceable at any time. This impacts access control lists; short lifetimes will tend to result in tedious list maintenance or require a namespace infrastructure for central control of access lists. In this document, the namespace approaching these ideas is called the Host Identity namespace. Using Host Identities requires its own protocol layer, the Host Identity Protocol, between the internetworking and transport layers. The names are based on public- key cryptography to supply authentication services. Properly designed, it can deliver all of the above-stated requirements. 4. Host Identity namespace A name in the Host Identity namespace, a Host Identifier (HI), represents a statistically globally unique name for naming any system with an IP stack. This identity is normally associated with, but not limited to, an IP stack. A system can have multiple identities, some 'well known', some unpublished or 'anonymous'. A system may self- assert its own identity, or may use a third-party authenticator like DNSSEC [RFC2535], PGP, or X.509 to 'notarize' the identity assertion to another namespace. In theory, any name that can claim to be 'statistically globally unique' may serve as a Host Identifier. In the HIP architecture, the public key of a private-public key pair has been chosen as the Host Identifier because it can be self-managed and it is computationally difficult to forge. As specified in the Host Identity Protocol [RFC7401] specification, a public-key-based HI can authenticate the HIP packets and protect them from man-in-the-middle attacks. Since authenticated datagrams are mandatory to provide much of HIP's denial-of-service protection, the Diffie-Hellman exchange in HIP base Moskowitz & Komu Expires August 18, 2019 [Page 9] Internet-Draft Host Identity Protocol Architecture February 2019 exchange has to be authenticated. Thus, only public-key HI and authenticated HIP messages are supported in practice. In this document, some non-cryptographic forms of HI and HIP are referenced, but cryptographic forms SHOULD be preferred because they are more secure than their non-cryptographic counterparts. There has been past research in challenge puzzles to use non-cryptographic HI, for Radio Frequency IDentification (RFID), in an HIP exchange tailored to the workings of such challenges (as described further in [urien-rfid] and [urien-rfid-draft]). 4.1. Host Identifiers Host Identity adds two main features to Internet protocols. The first is a decoupling of the internetworking and transport layers; see Section 5. This decoupling will allow for independent evolution of the two layers. Additionally, it can provide end-to-end services over multiple internetworking realms. The second feature is host authentication. Because the Host Identifier is a public key, this key can be used for authentication in security protocols like ESP. An identity is based on public-private key cryptography in HIP. The Host Identity is referred to by its public component, the public key. Thus, the name representing a Host Identity in the Host Identity namespace, i.e., the Host Identifier, is the public key. In a way, the possession of the private key defines the Identity itself. If the private key is possessed by more than one node, the Identity can be considered to be a distributed one. Architecturally, any other Internet naming convention might form a usable base for Host Identifiers. However, non-cryptographic names should only be used in situations of high trust - low risk. That is any place where host authentication is not needed (no risk of host spoofing) and no use of ESP. However, at least for interconnected networks spanning several operational domains, the set of environments where the risk of host spoofing allowed by non- cryptographic Host Identifiers is acceptable is the null set. Hence, the current HIP documents do not specify how to use any other types of Host Identifiers but public keys. For instance, Back-to-My-Mac [RFC6281] from Apple comes pretty close to the functionality of HIP, but unlike HIP, it is based on non-cryptographic identifiers. The actual Host Identifiers are never directly used at the transport or network layers. The corresponding Host Identifiers (public keys) may be stored in various DNS or other directories as identified elsewhere in this document, and they are passed in the HIP base exchange. A Host Identity Tag (HIT) is used in other protocols to represent the Host Identity. Another representation of the Host Moskowitz & Komu Expires August 18, 2019 [Page 10] Internet-Draft Host Identity Protocol Architecture February 2019 Identities, the Local Scope Identifier (LSI), can also be used in protocols and APIs. 4.2. Host Identity Hash (HIH) The Host Identity Hash (HIH) is the cryptographic hash algorithm used in producing the HIT from the HI. It is also the hash used throughout the HIP protocol for consistency and simplicity. It is possible for the two hosts in the HIP exchange to use different hash algorithms. Multiple HIHs within HIP are needed to address the moving target of creation and eventual compromise of cryptographic hashes. This significantly complicates HIP and offers an attacker an additional downgrade attack that is mitigated in the HIP protocol [RFC7401]. 4.3. Host Identity Tag (HIT) A Host Identity Tag (HIT) is a 128-bit representation for a Host Identity. Due to its size, it is suitable to be used in the existing sockets API in the place of IPv6 addresses (e.g., in sockaddr_in6 structure, sin6_addr member) without modifying applications. It is created from an HIH, an IPv6 prefix [RFC7343] and a hash identifier. There are two advantages of using the HIT over using the Host Identifier in protocols. Firstly, its fixed length makes for easier protocol coding and also better manages the packet size cost of this technology. Secondly, it presents the identity in a consistent format to the protocol independent of the cryptographic algorithms used. In essence, the HIT is a hash over the public key. As such, two algorithms affect the generation of a HIT: the public-key algorithm of the HI and the used HIH. The two algorithms are encoded in the bit presentation of the HIT. As the two communicating parties may support different algorithms, [RFC7401] defines the minimum set for interoperability. For further interoperability, the responder may store its keys in DNS records, and thus the initiator may have to couple destination HITs with appropriate source HITs according to matching HIH. In the HIP packets, the HITs identify the sender and recipient of a packet. Consequently, a HIT should be unique in the whole IP universe as long as it is being used. In the extremely rare case of a single HIT mapping to more than one Host Identity, the Host Identifiers (public keys) will make the final difference. If there is more than one public key for a given node, the HIT acts as a hint for the correct public key to use. Moskowitz & Komu Expires August 18, 2019 [Page 11] Internet-Draft Host Identity Protocol Architecture February 2019 Although it may be rare for an accidental collision to cause a single HIT mapping to more than one Host Identity, it may be the case that an attacker succeeds to find, by brute force or algorithmic weakness, a second Host Identity hashing to the same HIT. This type of attack is known as a preimage attack, and the resistance to finding a second Host Identifier (public key) that hashes to the same HIT is called second preimage resistance. Second preimage resistance in HIP is based on the hash algorithm strength and the length of the hash output used. Through HIPv2 [RFC7401], this resistance is 96 bits (less than the 128 bit width of an IPv6 address field due to the presence of the ORCHID prefix [RFC7343]). 96 bits of resistance was considered acceptable strength during the design of HIP, but may eventually be considered insufficient for the threat model of an envisioned deployment. One possible mitigation would be to augment the use of HITs in the deployment with the HIs themselves (and mechanisms to securely bind the HIs to the HITs), so that the HI becomes the final authority. It also may be possible to increase the difficulty of brute force attack by making the generation of the HI more computationally difficult, such as the hash extension approach of SEND CGAs [RFC3972], although the HIP specifications through HIPv2 do not provide such a mechanism. Finally, deployments that do not use ORCHIDs (such as certain types of overlay networks) might also use the full 128-bit width of an IPv6 address field for the HIT. 4.4. Local Scope Identifier (LSI) An LSI is a 32-bit localized representation for a Host Identity. Due to its size, it is suitable to be used in the existing sockets API in the place of IPv4 addresses (e.g., in sockaddr_in structure, sin_addr member) without modifying applications. The purpose of an LSI is to facilitate using Host Identities in existing APIs for IPv4-based applications. LSIs are never transmitted on the wire; when an application sends data using a pair of LSIs, the HIP layer (or sockets handler) translates the LSIs to the corresponding HITs, and vice versa for receiving of data. Besides facilitating HIP-based connectivity for legacy IPv4 applications, the LSIs are beneficial in two other scenarios [RFC6538]. In the first scenario, two IPv4-only applications are residing on two separate hosts connected by IPv6-only network. With HIP-based connectivity, the two applications are able to communicate despite of the mismatch in the protocol families of the applications and the underlying network. The reason is that the HIP layer translates the LSIs originating from the upper layers into routable IPv6 locators before delivering the packets on the wire. The second scenario is the same as the first one, but with the difference that one of the applications supports only IPv6. Now two Moskowitz & Komu Expires August 18, 2019 [Page 12] Internet-Draft Host Identity Protocol Architecture February 2019 obstacles hinder the communication between the application: the addressing families of the two applications differ, and the application residing at the IPv4-only side is again unable to communicate because of the mismatch between addressing families of the application (IPv4) and network (IPv6). With HIP-based connectivity for applications, this scenario works; the HIP layer can choose whether to translate the locator of an incoming packet into an LSI or HIT. Effectively, LSIs improve IPv6 interoperability at the network layer as described in the first scenario and at the application layer as depicted in the second example. The interoperability mechanism should not be used to avoid transition to IPv6; the authors firmly believe in IPv6 adoption and encourage developers to port existing IPv4-only applications to use IPv6. However, some proprietary, closed-source, IPv4-only applications may never see the daylight of IPv6, and the LSI mechanism is suitable for extending the lifetime of such applications even in IPv6-only networks. The main disadvantage of an LSI is its local scope. Applications may violate layering principles and pass LSIs to each other in application-layer protocols. As the LSIs are valid only in the context of the local host, they may represent an entirely different host when passed to another host. However, it should be emphasized here that the LSI concept is effectively a host-based NAT and does not introduce any more issues than the prevalent middlebox based NATs for IPv4. In other words, the applications violating layering principles are already broken by the NAT boxes that are ubiquitously deployed. 4.5. Storing Host Identifiers in directories The public Host Identifiers should be stored in DNS; the unpublished Host Identifiers should not be stored anywhere (besides the communicating hosts themselves). The (public) HI along with the supported HIHs are stored in a new RR type. This RR type is defined in HIP DNS Extension [RFC8005]. Alternatively, or in addition to storing Host Identifiers in the DNS, they may be stored in various other directories. For instance, a directory based on the Lightweight Directory Access Protocol (LDAP) or a Public Key Infrastructure (PKI) [RFC8002] may be used. Alternatively, Distributed Hash Tables (DHTs) [RFC6537] have successfully been utilized [RFC6538]. Such a practice may allow them to be used for purposes other than pure host identification. Some types of applications may cache and use Host Identifiers directly, while others may indirectly discover them through symbolic Moskowitz & Komu Expires August 18, 2019 [Page 13] Internet-Draft Host Identity Protocol Architecture February 2019 host name (such as FQDN) look up from a directory. Even though Host Identities can have a substantially longer lifetime associated with them than routable IP addresses, directories may be a better approach to manage the lifespan of Host Identities. For example, an LDAP- based directory or DHT can be used for locally published identities whereas DNS can be more suitable for public advertisement. 5. New stack architecture One way to characterize Host Identity is to compare the proposed HI- based architecture with the current one. Using the terminology from the IRTF Name Space Research Group Report [nsrg-report] and, e.g., the unpublished Internet-Draft Endpoints and Endpoint Names [chiappa-endpoints], the IP addresses currently embody the dual role of locators and end-point identifiers. That is, each IP address names a topological location in the Internet, thereby acting as a routing direction vector, or locator. At the same time, the IP address names the physical network interface currently located at the point-of-attachment, thereby acting as a end-point name. In the HIP architecture, the end-point names and locators are separated from each other. IP addresses continue to act as locators. The Host Identifiers take the role of end-point identifiers. It is important to understand that the end-point names based on Host Identities are slightly different from interface names; a Host Identity can be simultaneously reachable through several interfaces. The difference between the bindings of the logical entities are illustrated in Figure 1. The left side illustrates the current TCP/ IP architecture and the right side the HIP-based architecture. Transport ---- Socket Transport ------ Socket association | association | | | | | | | End-point | End-point --- Host Identity \ | | \ | | \ | | \ | | Location --- IP address Location --- IP address Figure 1 Moskowitz & Komu Expires August 18, 2019 [Page 14] Internet-Draft Host Identity Protocol Architecture February 2019 Architecturally, HIP provides for a different binding of transport- layer protocols. That is, the transport-layer associations, i.e., TCP connections and UDP associations, are no longer bound to IP addresses but rather to Host Identities. In practice, the Host Identities are exposed as LSIs and HITs for legacy applications and the transport layer to facilitate backward compatibility with existing networking APIs and stacks. The HIP layer is logically located at layer 3.5, between the transport and network layers, in the networking stack. It acts as shim layer for transport data utilizing LSIs or HITs, but leaves other data intact. The HIP layer translates between the two forms of HIP identifiers originating from the transport layer into routable IPv4/IPv6 addresses for the network layer, and vice versa for the reverse direction. 5.1. On the multiplicity of identities A host may have multiple identities both at the client and server side. This raises some additional concerns that are addressed in this section. For security reasons, it may be a bad idea to duplicate the same Host Identity on multiple hosts because the compromise of a single host taints the identities of the other hosts. Management of machines with identical Host Identities may also present other challenges and, therefore, it is advisable to have a unique identity for each host. At the server side, utilizing DNS is a better alternative than a shared Host Identity to implement load balancing. A single FQDN entry can be configured to refer to multiple Host Identities. Each of the FQDN entries can be associated with the related locators, or a single shared locator in the case the servers are using the same HIP rendezvous server Section 6.3 or HIP relay server Section 6.4. Instead of duplicating identities, HIP opportunistic mode can be employed, where the initiator leaves out the identifier of the responder when initiating the key exchange and learns it upon the completion of the exchange. The tradeoffs are related to lowered security guarantees, but a benefit of the approach is to avoid publishing of Host Identifiers in any directories [komu-leap]. Since many public servers already employ DNS as their directory, opportunistic mode may be more suitable for, e.g, peer-to-peer connectivity. It is also worth noting that opportunistic mode is also required in practice when anycast IP addresses would be utilized as locators. Moskowitz & Komu Expires August 18, 2019 [Page 15] Internet-Draft Host Identity Protocol Architecture February 2019 HIP opportunistic mode could be utilized in association with HIP rendezvous servers or HIP relay servers [komu-diss]. In such a scenario, the Initiator sends an I1 message with a wildcard destination HIT to the locator of a HIP rendezvous/relay server. When the receiving rendezvous/relay server is serving multiple registered Responders, the server can choose the ultimate destination HIT, thus acting as a HIP based load balancer. However, this approach is still experimental and requires further investigation. At the client side, a host may have multiple Host Identities, for instance, for privacy purposes. Another reason can be that the person utilizing the host employs different identities for different administrative domains as an extra security measure. If a HIP-aware middlebox, such as a HIP-based firewall, is on the path between the client and server, the user or the underlying system should carefully choose the correct identity to avoid the firewall to unnecessarily drop HIP-based connectivity [komu-diss]. Similarly, a server may have multiple Host Identities. For instance, a single web server may serve multiple different administrative domains. Typically, the distinction is accomplished based on the DNS name, but also the Host Identity could be used for this purpose. However, a more compelling reason to employ multiple identities are HIP-aware firewalls that are unable see the HTTP traffic inside the encrypted IPsec tunnel. In such a case, each service could be configured with a separate identity, thus allowing the firewall to segregate the different services of the single web server from each other [lindqvist-enterprise]. 6. Control plane HIP decouples control and data plane from each other. Two end-hosts initialize the control plane using a key exchange procedure called the base exchange. The procedure can be assisted by HIP specific infrastructural intermediaries called rendezvous or relay servers. In the event of IP address changes, the end-hosts sustain control plane connectivity with mobility and multihoming extensions. Eventually, the end-hosts terminate the control plane and remove the associated state. 6.1. Base exchange The base exchange is a key exchange procedure that authenticates the initiator and responder to each other using their public keys. Typically, the initiator is the client-side host and the responder is the server-side host. The roles are used by the state machine of a HIP implementation, but discarded upon successful completion. Moskowitz & Komu Expires August 18, 2019 [Page 16] Internet-Draft Host Identity Protocol Architecture February 2019 The exchange consists of four messages during which the hosts also create symmetric keys to protect the control plane with Hash-based message authentication codes (HMACs). The keys can be also used to protect the data plane, and IPsec ESP [RFC7402] is typically used as the data-plane protocol, albeit HIP can also accommodate others. Both the control and data plane are terminated using a closing procedure consisting of two messages. In addition, the base exchange also includes a computational puzzle [RFC7401] that the initiator must solve. The responder chooses the difficulty of the puzzle which permits the responder to delay new incoming initiators according to local policies, for instance, when the responder is under heavy load. The puzzle can offer some resiliency against DoS attacks because the design of the puzzle mechanism allows the responder to remain stateless until the very end of the base exchange [aura-dos]. HIP puzzles have also been studied under steady-state DDoS attacks [beal-dos], on multiple adversary models with varying puzzle difficulties [tritilanunt-dos] and with ephemeral Host Identities [komu-mitigation]. 6.2. End-host mobility and multi-homing HIP decouples the transport from the internetworking layer, and binds the transport associations to the Host Identities (actually through either the HIT or LSI). After the initial key exchange, the HIP layer maintains transport-layer connectivity and data flows using its mobility [RFC8046] and multihoming [RFC8047] extensions. Consequently, HIP can provide for a degree of internetworking mobility and multi-homing at a low infrastructure cost. HIP mobility includes IP address changes (via any method) to either party. Thus, a system is considered mobile if its IP address can change dynamically for any reason like PPP, DHCP, IPv6 prefix reassignments, or a NAT device remapping its translation. Likewise, a system is considered multi-homed if it has more than one globally routable IP address at the same time. HIP links IP addresses together, when multiple IP addresses correspond to the same Host Identity. If one address becomes unusable, or a more preferred address becomes available, existing transport associations can easily be moved to another address. When a mobile node moves while communication is already on-going, address changes are rather straightforward. The mobile node sends a HIP UPDATE packet to inform the peer of the new address(es), and the peer then verifies that the mobile node is reachable through these addresses. This way, the peer can avoid flooding attacks as further discussed in Section 11.2. Moskowitz & Komu Expires August 18, 2019 [Page 17] Internet-Draft Host Identity Protocol Architecture February 2019 6.3. Rendezvous mechanism Establishing a contact to a mobile, moving node is slightly more involved. In order to start the HIP exchange, the initiator node has to know how to reach the mobile node. For instance, the mobile node can employ Dynamic DNS [RFC2136] to update its reachability information in the DNS. To avoid the dependency to DNS, HIP provides its own HIP-specific alternative: the HIP rendezvous mechanism as defined in HIP Rendezvous specifications [RFC8004]. Using the HIP rendezvous extensions, the mobile node keeps the rendezvous infrastructure continuously updated with its current IP address(es). The mobile nodes trusts the rendezvous mechanism in order to properly maintain their HIT and IP address mappings. The rendezvous mechanism is especially useful in scenarios where both of the nodes are expected to change their address at the same time. In such a case, the HIP UPDATE packets will cross each other in the network and never reach the peer node. 6.4. Relay mechanism The HIP relay mechanism [I-D.ietf-hip-native-nat-traversal] is an alternative to the HIP rendezvous mechanism. The HIP relay mechanism is more suitable for IPv4 networks with NATs because a HIP relay can forward all control and data plane communications in order to guarantee successful NAT traversal. 6.5. Termination of the control plane The control plane between two hosts is terminated using a secure two- message exchange as specified in base exchange specification [RFC7401]. The related state (i.e. host associations) should be removed upon successful termination. 7. Data plane The encapsulation format for the data plane used for carrying the application-layer traffic can be dynamically negotiated during the key exchange. For instance, HICCUPS extensions [RFC6078] define one way to transport application-layer datagrams directly over the HIP control plane, protected by asymmetric key cryptography. Also, SRTP has been considered as the data encapsulation protocol [hip-srtp]. However, the most widely implemented method is the Encapsulated Security Payload (ESP) [RFC7402] that is protected by symmetric keys derived during the key exchange. ESP Security Associations (SAs) offer both confidentiality and integrity protection, of which the Moskowitz & Komu Expires August 18, 2019 [Page 18] Internet-Draft Host Identity Protocol Architecture February 2019 former can be disabled during the key exchange. In the future, other ways of transporting application-layer data may be defined. The ESP SAs are established and terminated between the initiator and the responder hosts. Usually, the hosts create at least two SAs, one in each direction (initiator-to-responder SA and responder-to- initiator SA). If the IP addresses of either host changes, the HIP mobility extensions can be used to re-negotiate the corresponding SAs. On the wire, the difference in the use of identifiers between the HIP control and data plane is that the HITs are included in all control packets, but not in the data plane when ESP is employed. Instead, the ESP employs SPI numbers that act as compressed HITs. Any HIP- aware middlebox (for instance, a HIP-aware firewall) interested in the ESP based data plane should keep track between the control and data plane identifiers in order to associate them with each other. Since HIP does not negotiate any SA lifetimes, all lifetimes are subject to local policy. The only lifetimes a HIP implementation must support are sequence number rollover (for replay protection), and SA timeout. An SA times out if no packets are received using that SA. Implementations may support lifetimes for the various ESP transforms and other data-plane protocols. 8. HIP and NATs Passing packets between different IP addressing realms requires changing IP addresses in the packet header. This may occur, for example, when a packet is passed between the public Internet and a private address space, or between IPv4 and IPv6 networks. The address translation is usually implemented as Network Address Translation (NAT) [RFC3022] or NAT Protocol translation (NAT-PT) [RFC2766]. In a network environment where identification is based on the IP addresses, identifying the communicating nodes is difficult when NATs are employed because private address spaces are overlapping. In other words, two hosts cannot be distinguished from each other solely based on their IP address. With HIP, the transport-layer end-points (i.e. applications) are bound to unique Host Identities rather than overlapping private addresses. This allows two end-points to distinguish one other even when they are located in different private address realms. Thus, the IP addresses are used only for routing purposes and can be changed freely by NATs when a packet between two HIP capable hosts traverses through multiple private address realms. Moskowitz & Komu Expires August 18, 2019 [Page 19] Internet-Draft Host Identity Protocol Architecture February 2019 NAT traversal extensions for HIP [I-D.ietf-hip-native-nat-traversal] can be used to realize the actual end-to-end connectivity through NAT devices. To support basic backward compatibility with legacy NATs, the extensions encapsulate both HIP control and data plane in UDP. The extensions define mechanisms for forwarding the two planes through an intermediary host called HIP relay and procedures to establish direct end-to-end connectivity by penetrating NATs. Besides this "native" NAT traversal mode for HIP, other NAT traversal mechanisms have been successfully utilized, such as Teredo [RFC4380] (as described in further detail in [varjonen-split]). Besides legacy NATs, a HIP-aware NAT has been designed and implemented [ylitalo-spinat]. For a HIP-based flow, a HIP-aware NAT or NAT-PT system tracks the mapping of HITs, and the corresponding ESP SPIs, to an IP address. The NAT system has to learn mappings both from HITs and from SPIs to IP addresses. Many HITs (and SPIs) can map to a single IP address on a NAT, simplifying connections on address-poor NAT interfaces. The NAT can gain much of its knowledge from the HIP packets themselves; however, some NAT configuration may be necessary. 8.1. HIP and Upper-layer checksums There is no way for a host to know if any of the IP addresses in an IP header are the addresses used to calculate the TCP checksum. That is, it is not feasible to calculate the TCP checksum using the actual IP addresses in the pseudo header; the addresses received in the incoming packet are not necessarily the same as they were on the sending host. Furthermore, it is not possible to recompute the upper-layer checksums in the NAT/NAT-PT system, since the traffic is ESP protected. Consequently, the TCP and UDP checksums are calculated using the HITs in the place of the IP addresses in the pseudo header. Furthermore, only the IPv6 pseudo header format is used. This provides for IPv4 / IPv6 protocol translation. 9. Multicast A number of studies investigating HIP-based multicast have been published (including [shields-hip], [xueyong-hip], [xueyong-hip], [amir-hip], [kovacshazi-host] and [xueyong-secure]). In particular, so-called Bloom filters, that allow compressing of multiple labels into small data structures, may be a promising way forward [sarela-bloom]. However, the different schemes have not been adopted by the HIP working group (nor the HIP research group in IRTF), so the details are not further elaborated here. Moskowitz & Komu Expires August 18, 2019 [Page 20] Internet-Draft Host Identity Protocol Architecture February 2019 10. HIP policies There are a number of variables that influence the HIP exchange that each host must support. All HIP implementations should support at least 2 HIs, one to publish in DNS or similar directory service and an unpublished one for anonymous usage (that should expect to be rotated frequently in order to disrupt linkability/trackability). Although unpublished HIs will be rarely used as responder HIs, they are likely to be common for initiators. As stated in [RFC7401], "all HIP implementations MUST support more than one simultaneous HI, at least one of which SHOULD be reserved for anonymous usage", and "support for more than two HIs is RECOMMENDED". This provides new challenges for systems or users to decide which type of HI to expose when they start a new session. Opportunistic mode (where the initiator starts a HIP exchange without prior knowledge of the responder's HI) presents a security tradeoff. At the expense of being subject to MITM attacks, the opportunistic mode allows the initiator to learn the identity of the responder during communication rather than from an external directory. Opportunistic mode can be used for registration to HIP-based services [RFC8003] (i.e. utilized by HIP for its own internal purposes) or by the application layer [komu-leap]. For security reasons, especially the latter requires some involvement from the user to accept the identity of the responder similar to how SSH prompts the user when connecting to a server for the first time [pham-leap]. In practice, this can be realized in end-host based firewalls in the case of legacy applications [karvonen-usable] or with native APIs for HIP APIs [RFC6317] in the case of HIP-aware applications. As stated in [RFC7401], "Initiators MAY use a different HI for different Responders to provide basic privacy. Whether such private HIs are used repeatedly with the same Responder, and how long these HIs are used, are decided by local policy and depend on the privacy requirements of the Initiator". According to [RFC7401], "Responders that only respond to selected Initiators require an Access Control List (ACL), representing for which hosts they accept HIP base exchanges, and the preferred transport format and local lifetimes. Wildcarding SHOULD be supported for such ACLs, and also for Responders that offer public or anonymous services". 11. Security considerations This section includes discussion on some issues and solutions related to security in the HIP architecture. Moskowitz & Komu Expires August 18, 2019 [Page 21] Internet-Draft Host Identity Protocol Architecture February 2019 11.1. MiTM Attacks HIP takes advantage of the Host Identity paradigm to provide secure authentication of hosts and to provide a fast key exchange for ESP. HIP also attempts to limit the exposure of the host to various denial-of-service (DoS) and man-in-the-middle (MitM) attacks. In so doing, HIP itself is subject to its own DoS and MitM attacks that potentially could be more damaging to a host's ability to conduct business as usual. Resource exhausting denial-of-service attacks take advantage of the cost of setting up a state for a protocol on the responder compared to the 'cheapness' on the initiator. HIP allows a responder to increase the cost of the start of state on the initiator and makes an effort to reduce the cost to the responder. This is done by having the responder start the authenticated Diffie-Hellman exchange instead of the initiator, making the HIP base exchange 4 packets long. The first packet sent by the responder can be prebuilt to further mitigate the costs. This packet also includes a computational puzzle that can optionally be used to further delay the initiator, for instance, when the responder is overloaded. The details are explained in the base exchange specification [RFC7401]. Man-in-the-middle (MitM) attacks are difficult to defend against, without third-party authentication. A skillful MitM could easily handle all parts of the HIP base exchange, but HIP indirectly provides the following protection from a MitM attack. If the responder's HI is retrieved from a signed DNS zone or securely obtained by some other means, the initiator can use this to authenticate the signed HIP packets. Likewise, if the initiator's HI is in a secure DNS zone, the responder can retrieve it and validate the signed HIP packets. However, since an initiator may choose to use an unpublished HI, it knowingly risks a MitM attack. The responder may choose not to accept a HIP exchange with an initiator using an unknown HI. Other types of MitM attacks against HIP can be mounted using ICMP messages that can be used to signal about problems. As an overall guideline, the ICMP messages should be considered as unreliable "hints" and should be acted upon only after timeouts. The exact attack scenarios and countermeasures are described in full detail the base exchange specification [RFC7401]. A MitM attacker could try to replay older I1 or R1 messages using weaker cryptographic algorithms as described in section 4.1.4 in [RFC7401]. The base exchange has been augmented to deal with such an attack by restarting on detecting the attack. At worst this would only lead to a situation in which the base exchange would never Moskowitz & Komu Expires August 18, 2019 [Page 22] Internet-Draft Host Identity Protocol Architecture February 2019 finish (or would be aborted after some retries). As a drawback, this leads to a 6-way base exchange which may seem bad at first. However, since this only occurs in an attack scenario and since the attack can be handled (so it is not interesting to mount anymore), we assume the subsequent messages do not represent a security threat. Since the MitM cannot be successful with a downgrade attack, these sorts of attacks will only occur as 'nuisance' attacks. So, the base exchange would still be usually just four packets even though implementations must be prepared to protect themselves against the downgrade attack. In HIP, the Security Association for ESP is indexed by the SPI; the source address is always ignored, and the destination address may be ignored as well. Therefore, HIP-enabled Encapsulated Security Payload (ESP) is IP address independent. This might seem to make attacking easier, but ESP with replay protection is already as well protected as possible, and the removal of the IP address as a check should not increase the exposure of ESP to DoS attacks. 11.2. Protection against flooding attacks Although the idea of informing about address changes by simply sending packets with a new source address appears appealing, it is not secure enough. That is, even if HIP does not rely on the source address for anything (once the base exchange has been completed), it appears to be necessary to check a mobile node's reachability at the new address before actually sending any larger amounts of traffic to the new address. Blindly accepting new addresses would potentially lead to flooding Denial-of-Service attacks against third parties [RFC4225]. In a distributed flooding attack an attacker opens high volume HIP connections with a large number of hosts (using unpublished HIs), and then claims to all of these hosts that it has moved to a target node's IP address. If the peer hosts were to simply accept the move, the result would be a packet flood to the target node's address. To prevent this type of attack, HIP mobility extensions include a return routability check procedure where the reachability of a node is separately checked at each address before using the address for larger amounts of traffic. A credit-based authorization approach for host mobility with the Host Identity Protocol [RFC8046] can be used between hosts for sending data prior to completing the address tests. Otherwise, if HIP is used between two hosts that fully trust each other, the hosts may optionally decide to skip the address tests. However, such performance optimization must be restricted to peers that are known to be trustworthy and capable of protecting themselves from malicious software. Moskowitz & Komu Expires August 18, 2019 [Page 23] Internet-Draft Host Identity Protocol Architecture February 2019 11.3. HITs used in ACLs At end-hosts, HITs can be used in IP-based access control lists at the application and network layers. At middleboxes, HIP-aware firewalls [lindqvist-enterprise] can use HITs or public keys to control both ingress and egress access to networks or individual hosts, even in the presence of mobile devices because the HITs and public keys are topology independent. As discussed earlier in Section 7, once a HIP session has been established, the SPI value in an ESP packet may be used as an index, indicating the HITs. In practice, firewalls can inspect HIP packets to learn of the bindings between HITs, SPI values, and IP addresses. They can even explicitly control ESP usage, dynamically opening ESP only for specific SPI values and IP addresses. The signatures in HIP packets allow a capable firewall to ensure that the HIP exchange is indeed occurring between two known hosts. This may increase firewall security. A potential drawback of HITs in ACLs is their 'flatness' means they cannot be aggregated, and this could potentially result in larger table searches in HIP-aware firewalls. A way to optimize this could be to utilize Bloom filters for grouping of HITs [sarela-bloom]. However, it should be noted that it is also easier to exclude individual, misbehaving hosts out when the firewall rules concern individual HITs rather than groups. There has been considerable bad experience with distributed ACLs that contain public key related material, for example, with SSH. If the owner of a key needs to revoke it for any reason, the task of finding all locations where the key is held in an ACL may be impossible. If the reason for the revocation is due to private key theft, this could be a serious issue. A host can keep track of all of its partners that might use its HIT in an ACL by logging all remote HITs. It should only be necessary to log responder hosts. With this information, the host can notify the various hosts about the change to the HIT. There have been attempts to develop a secure method to issue the HIT revocation notice [zhang-revocation]. Some of the HIP-aware middleboxes, such as firewalls [lindqvist-enterprise] or NATs [ylitalo-spinat], may observe the on- path traffic passively. Such middleboxes are transparent by their nature and may not get a notification when a host moves to a different network. Thus, such middleboxes should maintain soft state and timeout when the control and data plane between two HIP end-hosts has been idle too long. Correspondingly, the two end-hosts may send periodically keepalives, such as UPDATE packets or ICMP messages inside the ESP tunnel, to sustain state at the on-path middleboxes. Moskowitz & Komu Expires August 18, 2019 [Page 24] Internet-Draft Host Identity Protocol Architecture February 2019 One general limitation related to end-to-end encryption is that middleboxes may not be able to participate to the protection of data flows. While the issue may affect also other protocols, Heer at al [heer-end-host] have analyzed the problem in the context of HIP. More specifically, when ESP is used as the data-plane protocol for HIP, the association between the control and data plane is weak and can be exploited under certain assumptions. In the scenario, the attacker has already gained access to the target network protected by a HIP-aware firewall, but wants to circumvent the HIP-based firewall. To achieve this, the attacker passively observes a base exchange between two HIP hosts and later replays it. This way, the attacker manages to penetrate the firewall and can use a fake ESP tunnel to transport its own data. This is possible because the firewall cannot distinguish when the ESP tunnel is valid. As a solution, HIP-aware middleboxes may participate to the control plane interaction by adding random nonce parameters to the control traffic, which the end- hosts have to sign to guarantee the freshness of the control traffic [heer-midauth]. As an alternative, extensions for transporting data plane directly over the control plane can be used [RFC6078]. 11.4. Alternative HI considerations The definition of the Host Identifier states that the HI need not be a public key. It implies that the HI could be any value; for example a FQDN. This document does not describe how to support such a non- cryptographic HI, but examples of such protocol variants do exist ([urien-rfid], [urien-rfid-draft]). A non-cryptographic HI would still offer the services of the HIT or LSI for NAT traversal. It would be possible to carry HITs in HIP packets that had neither privacy nor authentication. Such schemes may be employed for resource constrained devices, such as small sensors operating on battery power, but are not further analyzed here. If it is desirable to use HIP in a low security situation where public key computations are considered expensive, HIP can be used with very short Diffie-Hellman and Host Identity keys. Such use makes the participating hosts vulnerable to MitM and connection hijacking attacks. However, it does not cause flooding dangers, since the address check mechanism relies on the routing system and not on cryptographic strength. 11.5. Trust On First Use [RFC7435] highlights four design principles for Leap of Faith, or Trust On First Use (TOFU), protocols that apply also to opportunistic HIP: 1. Coexist with explicit policy Moskowitz & Komu Expires August 18, 2019 [Page 25] Internet-Draft Host Identity Protocol Architecture February 2019 2. Prioritize communication 3. Maximize security peer by peer 4. No misrepresentation of security According to the first TOFU design principle, "opportunistic security never displaces or preempts explicit policy". Some application data may be too sensitive, so the related policy could require authentication (i.e, the public key or certificate) in such a case instead of the unauthenticated opportunistic mode. In practice, this has been realized in HIP implementations as follows [RFC6538]. The OpenHIP implementation allowed an Initiator to use opportunistic mode only with an explicitly configured Responder IP address, when the Responder's HIT is unknown. At the Responder, OpenHIP had an option to allow opportunistic mode with any Initiator -- trust any Initiator. HIP for Linux (HIPL) developers experimented with more fine-grained policies operating at the application level. HIPL implementation utilized so called "LD_PRELOAD" hooking at the application layer that allowed a dynamically linked library to intercept socket-related calls without rebuilding the related application binaries. The library acted as a shim layer between the application and transport layers. The shim layer translated the non-HIP based socket calls from the application into HIP-based socket calls. While the shim library involved some level of complexity as described in more detail in [komu-leap], it achieved the goal of applying opportunistic mode at the granularity of individual applications. The second TOFU principle essentially states that communication should be first class citizen instead of security. So opportunistic mode should be, in general, allowed even if no authentication is present, and even possibly a fallback to non-encrypted communications could be allowed (if policy permits) instead of blocking communications. In practice, this can be realized in three steps. In the first step, a HIP Initiator can look up the HI of a Responder from a directory such as DNS. When the Initiator discovers a HI, it can use the HI for authentication and skip the rest of the following steps. In the second step, the Initiator can, upon failing to find a HI, try opportunistic mode with the Responder. In the third step, the Initiator can fall back to non-HIP based communications upon failing with opportunistic mode if the policy allows it. This three step model has been implemented successfully and described in more detail in [komu-leap]. Moskowitz & Komu Expires August 18, 2019 [Page 26] Internet-Draft Host Identity Protocol Architecture February 2019 The third TOFU principle suggests that security should be maximized, so that at least opportunistic security would be employed. The three step model described earlier prefers authentication when it is available, e.g., via DNS records (and possibly even via DNSSEC when available) and falls back to opportunistic mode when no out-of-band credentials are available. As the last resort, fallback to non-HIP based communications can be used if the policy allows it. Also, since perfect forward security (PFS) is explicitly mentioned in the third design principle, it is worth mentioning that HIP supports it. The fourth TOFU principle states that users and non-interactive applications should be properly informed about the level of security being applied. In practice, non-HIP aware applications would assume no extra security being applied, so misleading at least a non- interactive application should not be possible. In the case of interactive desktop applications, system-level prompts have been utilized in earlier HIP experiments [karvonen-usable], [RFC6538] to guide the user about the underlying HIP-based security. In general, users in those experiments perceived when HIP-based security was being used versus not used. However, the users failed to notice the difference between opportunistic and non-opportunistic HIP. The reason for this was that the opportunistic HIP (i.e. lowered level of security) was not clearly indicated in the prompt. This provided a valuable lesson to further improve the user interface. In the case of HIP-aware applications, native sockets APIs for HIP as specified in [RFC6317] can be used to develop application-specific logic instead of using generic system-level prompting. In such case, the application itself can directly prompt the user or otherwise manage the situation in other ways. In this case, also non- interactive applications can properly log the level of security being employed because the developer can now explicitly program the use of authenticated HIP, opportunistic HIP and plain-text communication. It is worth mentioning a few additional items discussed in [RFC7435]. Related to active attacks, HIP has built-in protection against cipher-suite down-grade attacks as described in detail in [RFC7401]. In addition, pre-deployed certificates could be used to mitigate against active attacks in the case of opportunistic mode as mentioned in [RFC6538]. Detection of peer capabilities is also mentioned in the TOFU context. As discussed in this section, the three-step model can be used to detect peer capabilities. A host can achieve the first step of authentication, i.e., discovery of a public key, via DNS, for instance. If the host found no keys, the host can then try opportunistic mode as the second step. Upon a timeout, the host can then proceed to the third step by falling back to non-HIP based Moskowitz & Komu Expires August 18, 2019 [Page 27] Internet-Draft Host Identity Protocol Architecture February 2019 communications if the policy permits. This last step is based on an implicit timeout rather an explicit (negative) acknowledgment like in the case of DNS, so the user may conclude prematurely that the connectivity has failed. To speed up the detection phase by explicitly detecting if the peer supports opportunistic HIP, researchers have proposed TCP specific extensions [RFC6538], [komu-leap]. In a nutshell, an Initiator sends simultaneously both an opportunistic I1 packet and the related TCP SYN datagram equipped with a special TCP option to a peer. If the peer supports HIP, it drops the SYN packet and responds with an R1. If the peer is HIP incapable, it drops the HIP packet (and the unknown TCP option) and responds with a TCP SYN-ACK. The benefit of the proposed scheme is faster, one round-trip fallback to non-HIP based communications. The drawback is that the approach is tied to TCP (IP-options were also considered, but do not work well with firewalls and NATs). Naturally, the approach does not work against active attacker, but opportunistic mode is not anyway supposed to protect against such an adversary. It is worth noting that while the use of opportunistic mode has some benefits related to incremental deployment, it does not achieve all the benefits of authenticated HIP [komu-diss]. Namely, authenticated HIP supports persistent identifiers in the sense that hosts are identified with the same HI independently of their movement. Opportunistic HIP meets this goal only partially: after the first contact between two hosts, HIP can successfully sustain connectivity with its mobility management extensions, but problems emerge when the hosts close the HIP association and try to re-establish connectivity. As hosts can change their location, it is no longer guaranteed that the same IP address belongs to the same host. The same address can be temporally assigned to different hosts, e.g., due to the reuse of IP addresses (e.g., by a DHCP service), overlapping private address realms (see also the discussion on Internet transparency in Appendix A.1) or due to an attempted attack. 12. IANA considerations This document has no actions for IANA. 13. Acknowledgments For the people historically involved in the early stages of HIP, see the Acknowledgments section in the Host Identity Protocol specification. During the later stages of this document, when the editing baton was transferred to Pekka Nikander, the comments from the early implementers and others, including Jari Arkko, Jeff AhrenHolz, Tom Moskowitz & Komu Expires August 18, 2019 [Page 28] Internet-Draft Host Identity Protocol Architecture February 2019 Henderson, Petri Jokela, Miika Komu, Mika Kousa, Andrew McGregor, Jan Melen, Tim Shepard, Jukka Ylitalo, Sasu Tarkoma, and Jorma Wall, were invaluable. Also, the comments from Lars Eggert, Spencer Dawkins, Dave Crocker and Erik Giesa were also useful. The authors want to express their special thanks to Tom Henderson, who took the burden of editing the document in response to IESG comments at the time when both of the authors were busy doing other things. Without his perseverance original document might have never made it as RFC4423. This main effort to update and move HIP forward within the IETF process owes its impetuous to a number of HIP development teams. The authors are grateful for Boeing, Helsinki Institute for Information Technology (HIIT), NomadicLab of Ericsson, and the three universities: RWTH Aachen, Aalto and University of Helsinki, for their efforts. Without their collective efforts HIP would have withered as on the IETF vine as a nice concept. Thanks also for Suvi Koskinen for her help with proofreading and with the reference jungle. 14. Changes from RFC 4423 In a nutshell, the changes from RFC 4423 [RFC4423] are mostly editorial, including clarifications on topics described in a difficult way and omitting some of the non-architectural (implementation) details that are already described in other documents. A number of missing references to the literature were also added. New topics include the drawbacks of HIP, discussion on 802.15.4 and MAC security, HIP for IoT scenarios, deployment considerations and description of the base exchange. 15. References 15.1. Normative References [I-D.ietf-hip-dex] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", draft-ietf-hip-dex-06 (work in progress), December 2017. [I-D.ietf-hip-native-nat-traversal] Keranen, A., Melen, J., and M. Komu, "Native NAT Traversal Mode for the Host Identity Protocol", draft-ietf-hip- native-nat-traversal-28 (work in progress), March 2018. Moskowitz & Komu Expires August 18, 2019 [Page 29] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, . [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)", RFC 6079, DOI 10.17487/RFC6079, January 2011, . [RFC7086] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", RFC 7086, DOI 10.17487/RFC7086, January 2014, . [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2014, . [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, . [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 7402, DOI 10.17487/RFC7402, April 2015, . [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 8002, DOI 10.17487/RFC8002, October 2016, . [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 8003, DOI 10.17487/RFC8003, October 2016, . [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, October 2016, . [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, October 2016, . Moskowitz & Komu Expires August 18, 2019 [Page 30] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility with the Host Identity Protocol", RFC 8046, DOI 10.17487/RFC8046, February 2017, . [RFC8047] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Multihoming with the Host Identity Protocol", RFC 8047, DOI 10.17487/RFC8047, February 2017, . 15.2. Informative references [amir-hip] Amir, K., Forsgren, H., Grahn, K., Karvi, T., and G. Pulkkis, "Security and Trust of Public Key Cryptography for HIP and HIP Multicast", International Journal of Dependable and Trustworthy Information Systems (IJDTIS), 2(3), 17-35, DOI: 10.4018/jdtis.2011070102, 2013. [aura-dos] Aura, T., Nikander, P., and J. Leiwo, "DOS-resistant Authentication with Client Puzzles", 8th International Workshop on Security Protocols, pages 170-177. Springer, , April 2001. [beal-dos] Beal, J. and T. Shephard, "Deamplification of DoS Attacks via Puzzles", , October 2004. [camarillo-p2psip] Camarillo, G., Maeenpaeae, J., Keraenen, A., and V. Anderson, "Reducing delays related to NAT traversal in P2PSIP session establishments", IEEE Consumer Communications and Networking Conference (CCNC), pp. 549-553 DOI: 10.1109/CCNC.2011.5766540, 2011. [chiappa-endpoints] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. [heer-end-host] Heer, T., Hummen, R., Komu, M., Goetz, S., and K. Wehre, "End-host Authentication and Authorization for Middleboxes based on a Cryptographic Namespace", ICC2009 Communication and Information Systems Security Symposium, , 2009. Moskowitz & Komu Expires August 18, 2019 [Page 31] Internet-Draft Host Identity Protocol Architecture February 2019 [heer-midauth] Heer, T. and M. Komu, "End-Host Authentication for HIP Middleboxes", Working draft draft-heer-hip-middle-auth-02, September 2009. [henderson-vpls] Henderson, T. and D. Mattes, "HIP-based Virtual Private LAN Service (HIPLS)", Working draft draft-henderson-hip- vpls-07, Dec 2013. [hip-lte] Liyanage, M., Kumar, P., Ylianttila, M., and A. Gurtov, "Novel secure VPN architectures for LTE backhaul networks", Security and Communication Networks DOI 10.1002/sec.1411, November 2015. [hip-srtp] Tschofenig, H., Muenz, F., and M. Shanmugam, "Using SRTP transport format with HIP", Working draft draft- tschofenig-hiprg-hip-srtp-01, October 2005. [hummen] Hummen, R., Hiller, J., Henze, M., and K. Wehrle, "Slimfit - A HIP DEX Compression Layer for the IP-based Internet of Things", Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE 9th International Conference on , page 259-266. DOI: 10.1109/WiMOB.2013.6673370, October 2013. [IEEE.802-15-4.2011] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.4, September 2011, . [IEEE.802-15-9] "IEEE Draft Recommended Practice for Transort of Key Management Protocol (KMP) Datagrams", IEEE P802.15.9/D04, May 2015. [karvonen-usable] Karvonen, K., Komu, M., and A. Gurtov, "Usable Security Management with Host Identity Protocol", 7th ACS/IEEE International Conference on Computer Systems and Applications, (AICCSA-2009), 2009. Moskowitz & Komu Expires August 18, 2019 [Page 32] Internet-Draft Host Identity Protocol Architecture February 2019 [komu-cloud] Komu, M., Sethi, M., Mallavarapu, R., Oirola, H., Khan, R., and S. Tarkoma, "Secure Networking for Virtual Machines in the Cloud", International Workshop on Power and QoS Aware Computing (PQoSCom2012), IEEE, ISBN: 978-1-4244-8567-3, September 2012. [komu-diss] Komu, M., "A Consolidated Namespace for Network Applications, Developers, Administrators and Users", Dissertation, Aalto University, Espoo, Finland ISBN: 978-952-60-4904-5 (printed), ISBN: 978-952-60-4905-2 (electronic). , December 2012. [komu-leap] Komu, M. and J. Lindqvist, "Leap-of-Faith Security is Enough for IP Mobility", 6th Annual IEEE Consumer Communications and Networking Conference IEEE CCNC 2009, Las Vegas, Nevada, , January 2009. [komu-mitigation] Komu, M., Tarkoma, S., and A. Lukyanenko, "Mitigation of Unsolicited Traffic Across Domains with Host Identities and Puzzles", 15th Nordic Conference on Secure IT Systems (NordSec 2010), Springer Lecture Notes in Computer Science, Volume 7127, pp. 33-48, ISBN: 978-3-642-27936-2, October 2010. [kovacshazi-host] Kovacshazi, Z. and R. Vida, "Host Identity Specific Multicast", International conference on Networking and Services (ICNS'06), IEEE Computer Society, Los Alamitos, CA, USA, http://doi.ieeecomputersociety.org/10.1109/ ICNS.2007.66, 2007. [leva-barriers] Levae, A., Komu, M., and S. Luukkainen, "Adoption Barriers of Network-layer Protocols: the Case of Host Identity Protocol", The International Journal of Computer and Telecommunications Networking, ISSN: 1389-1286, March 2013. [lindqvist-enterprise] Lindqvist, J., Vehmersalo, E., Manner, J., and M. Komu, "Enterprise Network Packet Filtering for Mobile Cryptographic Identities", International Journal of Handheld Computing Research, 1 (1), 79-94, , January-March 2010. Moskowitz & Komu Expires August 18, 2019 [Page 33] Internet-Draft Host Identity Protocol Architecture February 2019 [Nik2001] Nikander, P., "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", in Proceesings of Security Protocols, 9th International Workshop, Cambridge, UK, April 25-27 2001, LNCS 2467, pp. 12-26, Springer, 2002. [nsrg-report] Lear, E. and R. Droms, "What's In A Name:Thoughts from the NSRG", draft-irtf-nsrg-report-10 (work in progress), September 2003. [paine-hip] Paine, R., "Beyond HIP: The End to Hacking As We Know It", BookSurge Publishing, ISBN: 1439256047, 9781439256046, 2009. [pham-leap] Pham, V. and T. Aura, "Security Analysis of Leap-of-Faith Protocols", Seventh ICST International Conference on Security and Privacy for Communication Networks, , September 2011. [ranjbar-synaptic] Ranjbar, A., Komu, M., Salmela, P., and T. Aura, "SynAPTIC: Secure and Persistent Connectivity for Containers", 2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID), Madrid, 2017, pp. 262-267 doi: 10.1109/CCGRID.2017.62, 2017. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, . [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, DOI 10.17487/RFC2766, February 2000, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . Moskowitz & Komu Expires August 18, 2019 [Page 34] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, DOI 10.17487/RFC3102, October 2001, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, DOI 10.17487/RFC4225, December 2005, . [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, . [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, DOI 10.17487/RFC4423, May 2006, . [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, . [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, DOI 10.17487/RFC5338, September 2008, . [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May 2010, . Moskowitz & Komu Expires August 18, 2019 [Page 35] Internet-Draft Host Identity Protocol Architecture February 2019 [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, January 2011, . [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, . [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, DOI 10.17487/RFC6281, June 2011, . [RFC6317] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for the Host Identity Protocol (HIP)", RFC 6317, DOI 10.17487/RFC6317, July 2011, . [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 2012, . [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol (HIP) Experiment Report", RFC 6538, DOI 10.17487/RFC6538, March 2012, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [sarela-bloom] Saerelae, M., Esteve Rothenberg, C., Zahemszky, A., Nikander, P., and J. Ott, "BloomCasting: Security in Bloom filter based multicast", , Lecture Notes in Computer Science 2012, , pages 1-16, Springer Berlin Heidelberg, 2012. [schuetz-intermittent] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol enhancements for intermittently connected hosts", SIGCOMM Comput. Commun. Rev., 35(3):5-18, , July 2005. Moskowitz & Komu Expires August 18, 2019 [Page 36] Internet-Draft Host Identity Protocol Architecture February 2019 [shields-hip] Shields, C. and J. Garcia-Luna-Aceves, "The HIP protocol for hierarchical multicast routing", Proceedings of the seventeenth annual ACM symposium on Principles of distributed computing, pages 257-266. ACM, New York, NY, USA, ISBN: 0-89791-977-7, DOI: 10.1145/277697.277744, 1998. [tempered-networks] "Identity-Defined Network (IDN) Architecture: Unified, Secure Networking Made Simple", White Paper , 2016. [tritilanunt-dos] Tritilanunt, S., Boyd, C., Foo, E., and J. Nieto, "Examining the DoS Resistance of HIP", OTM Workshops (1), volume 4277 of Lecture Notes in Computer Science, pages 616-625,Springer , 2006. [urien-rfid] Urien, P., Chabanne, H., Bouet, M., de Cunha, D., Guyot, V., Pujolle, G., Paradinas, P., Gressier, E., and J. Susini, "HIP-based RFID Networking Architecture", IFIP International Conference on Wireless and Optical Communications Networks, DOI: 10.1109/WOCN.2007.4284140, July 2007. [urien-rfid-draft] Urien, P., Lee, G., and G. Pujolle, "HIP support for RFIDs", IRTF Working draft draft-irtf-hiprg-rfid-07, April 2013. [varjonen-split] Varjonen, S., Komu, M., and A. Gurtov, "Secure and Efficient IPv4/IPv6 Handovers Using Host-Based Identifier- Location Split", Journal of Communications Software and Systems, 6(1), 2010, ISSN: 18456421, 2010. [xin-hip-lib] Xin, G., "Host Identity Protocol Version 2.5", Master's Thesis, Aalto University, Espoo, Finland, , June 2012. [xueyong-hip] Xueyong, Z., Zhiguo, D., and W. Xinling, "A Multicast Routing Algorithm Applied to HIP-Multicast Model", Proceedings of the 2011 International Conference on Network Computing and Information Security - Volume 01 (NCIS '11), Vol. 1. IEEE Computer Society, Washington, DC, USA, pages 169-174, DOI: 10.1109/NCIS.2011.42, 2011. Moskowitz & Komu Expires August 18, 2019 [Page 37] Internet-Draft Host Identity Protocol Architecture February 2019 [xueyong-secure] Xueyong, Z. and J. Atwood, "A Secure Multicast Model for Peer-to-Peer and Access Networks Using the Host Identity Protocol", Consumer Communications and Networking Conference. CCNC 2007. 4th IEEE, pages 1098,1102, DOI: 10.1109/CCNC.2007.221, January 2007. [ylitalo-diss] Ylitalo, J., "Secure Mobility at Multiple Granularity Levels over Heterogeneous Datacom Networks", Dissertation, Helsinki University of Technology, Espoo, Finland ISBN 978-951-22-9531-9, 2008. [ylitalo-spinat] Ylitalo, J., Salmela, P., and H. Tschofenig, "SPINAT: Integrating IPsec into overlay routing", Proceedings of the First International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2005). Athens, Greece. IEEE Computer Society, pages 315-326, ISBN: 0-7695-2369-2, September 2005. [zhang-revocation] Zhang, D., Kuptsov, D., and S. Shen, "Host Identifier Revocation in HIP", IRTF Working draft draft-irtf-hiprg- revocation-05, Mar 2012. Appendix A. Design considerations A.1. Benefits of HIP In the beginning, the network layer protocol (i.e., IP) had the following four "classic" invariants: 1. Non-mutable: The address sent is the address received. 2. Non-mobile: The address doesn't change during the course of an "association". 3. Reversible: A return header can always be formed by reversing the source and destination addresses. 4. Omniscient: Each host knows what address a partner host can use to send packets to it. Actually, the fourth can be inferred from 1 and 3, but it is worth mentioning explicitly for reasons that will be obvious soon if not already. Moskowitz & Komu Expires August 18, 2019 [Page 38] Internet-Draft Host Identity Protocol Architecture February 2019 In the current "post-classic" world, we are intentionally trying to get rid of the second invariant (both for mobility and for multi- homing), and we have been forced to give up the first and the fourth. Realm Specific IP [RFC3102] is an attempt to reinstate the fourth invariant without the first invariant. IPv6 is attempts to reinstate the first invariant. Few client-side systems on the Internet have DNS names that are meaningful. That is, if they have a Fully Qualified Domain Name (FQDN), that name typically belongs to a NAT device or a dial-up server, and does not really identify the system itself but its current connectivity. FQDNs (and their extensions as email names) are application-layer names; more frequently naming services than particular systems. This is why many systems on the Internet are not registered in the DNS; they do not have services of interest to other Internet hosts. DNS names are references to IP addresses. This only demonstrates the interrelationship of the networking and application layers. DNS, as the Internet's only deployed and distributed database, is also the repository of other namespaces, due in part to DNSSEC and application specific key records. Although each namespace can be stretched (IP with v6, DNS with KEY records), neither can adequately provide for host authentication or act as a separation between internetworking and transport layers. The Host Identity (HI) namespace fills an important gap between the IP and DNS namespaces. An interesting thing about the HI is that it actually allows a host to give up all but the 3rd network-layer invariant. That is to say, as long as the source and destination addresses in the network-layer protocol are reversible, HIP takes care of host identification, and reversibility allows a local host to receive a packet back from a remote host. The address changes occurring during NAT transit (non-mutable) or host movement (non- omniscient or non-mobile) can be managed by the HIP layer. With the exception of High-Performance Computing applications, the Sockets API is the most common way to develop network applications. Applications use the Sockets API either directly or indirectly through some libraries or frameworks. However, the Sockets API is based on the assumption of static IP addresses, and DNS with its lifetime values was invented at later stages during the evolution of the Internet. Hence, the Sockets API does not deal with the lifetime of addresses [RFC6250]. As the majority of the end-user equipment is mobile today, their addresses are effectively ephemeral, but the Sockets API still gives a fallacious illusion of persistent IP addresses to the unwary developer. HIP can be used to solidify this Moskowitz & Komu Expires August 18, 2019 [Page 39] Internet-Draft Host Identity Protocol Architecture February 2019 illusion because HIP provides persistent surrogate addresses to the application layer in the form of LSIs and HITs. The persistent identifiers as provided by HIP are useful in multiple scenarios (see, e.g., [ylitalo-diss] or [komu-diss], for a more elaborate discussion): o When a mobile host moves physically between two different WLAN networks and obtains a new address, an application using the identifiers remains isolated regardless of the topology changes while the underlying HIP layer re-establishes connectivity (i.e. a horizontal handoff). o Similarly, the application utilizing the identifiers remains again unaware of the topological changes when the underlying host equipped with WLAN and cellular network interfaces switches between the two different access technologies (i.e. a vertical handoff). o Even when hosts are located in private address realms, applications can uniquely distinguish different hosts from each other based on their identifiers. In other words, it can be stated that HIP improves Internet transparency for the application layer [komu-diss]. o Site renumbering events for services can occur due to corporate mergers or acquisitions, or by changes in Internet Service Provider. They can involve changing the entire network prefix of an organization, which is problematic due to hard-coded addresses in service configuration files or cached IP addresses at the client side [RFC5887]. Considering such human errors, a site employing location-independent identifiers as promoted by HIP may experience fewer problems while renumbering their network. o More agile IPv6 interoperability can be achieved, as discussed in Section 4.4. IPv6-based applications can communicate using HITs with IPv4-based applications that are using LSIs. Additionally, the underlying network type (IPv4 or IPv6) becomes independent of the addressing family of the application. o HITs (or LSIs) can be used in IP-based access control lists as a more secure replacement for IPv6 addresses. Besides security, HIT based access control has two other benefits. First, the use of HITs can potentially halve the size of access control lists because separate rules for IPv4 are not needed [komu-diss]. Second, HIT-based configuration rules in HIP-aware middleboxes remain static and independent of topology changes, thus simplifying administrative efforts particularly for mobile Moskowitz & Komu Expires August 18, 2019 [Page 40] Internet-Draft Host Identity Protocol Architecture February 2019 environments. For instance, the benefits of HIT-based access control have been harnessed in the case of HIP-aware firewalls, but can be utilized directly at the end-hosts as well [RFC6538]. While some of these benefits could be and have been redundantly implemented by individual applications, providing such generic functionality at the lower layers is useful because it reduces software development effort and networking software bugs (as the layer is tested with multiple applications). It also allows the developer to focus on building the application itself rather than delving into the intricacies of mobile networking, thus facilitating separation of concerns. HIP could also be realized by combining a number of different protocols, but the complexity of the resulting software may become substantially larger, and the interaction between multiple possibly layered protocols may have adverse effects on latency and throughput. It is also worth noting that virtually nothing prevents realizing the HIP architecture, for instance, as an application-layer library, which has been actually implemented in the past [xin-hip-lib]. However, the tradeoff in moving the HIP layer to the application layer is that legacy applications may not be supported. A.2. Drawbacks of HIP In computer science, many problems can be solved with an extra layer of indirection. However, the indirection always involves some costs as there is no such a thing as "free lunch". In the case of HIP, the main costs could be stated as follows: o In general, an additional layer and a namespace always involve some initial effort in terms of implementation, deployment and maintenance. Some education of developers and administrators may also be needed. However, the HIP community at the IETF has spent years in experimenting, exploring, testing, documenting and implementing HIP to ease the adoption costs. o HIP introduces a need to manage HIs and requires a centralized approach to manage HIP-aware endpoints at scale. What were formerly IP address-based ACLs are now trusted HITs, and the HIT to IP address mappings as well as access policies must be managed. HIP-aware endpoints must also be able to operate autonomously to ensure mobility and availability (an endpoint must be able to run without having to have a persistent management connection). The users who want this better security and mobility of HIs instead of IP address based ACLs have to then manage this additional 'identity layer' in a non-persistent fashion. As exemplified in Appendix A.3.5, these challenges have been already solved in an Moskowitz & Komu Expires August 18, 2019 [Page 41] Internet-Draft Host Identity Protocol Architecture February 2019 infrastructure setting to distribute policy and manage the mappings and trust relationships between HIP-aware endpoints. o HIP decouples identifier and locator roles of IP addresses. Consequently, a mapping mechanism is needed to associate them together. A failure to map a HIT to its corresponding locator may result in failed connectivity because a HIT is "flat" by its nature and cannot be looked up from the hierarchically organized DNS. HITs are flat by design due to a security tradeoff. The more bits are allocated for the hash in the HIT, the less likely there will be (malicious) collisions. o From performance viewpoint, HIP control and data plane processing introduces some overhead in terms of throughput and latency as elaborated below. Related to deployment drawbacks, firewalls are commonly used to control access to various services and devices in the current Internet. Since HIP introduces an additional namespace, it is expected that also the HIP namespace would be filtered for unwanted connectivity. While this can be achieved with existing tools directly in the end-hosts, filtering at the middleboxes requires modifications to existing firewall software or additional middleboxes [RFC6538]. The key exchange introduces some extra latency (two round trips) in the initial transport-layer connection establishment between two hosts. With TCP, additional delay occurs if the underlying network stack implementation drops the triggering SYN packet during the key exchange. The same cost may also occur during HIP handoff procedures. However, subsequent TCP sessions using the same HIP association will not bear this cost (within the key lifetime). Both the key exchange and handoff penalties can be minimized by caching TCP packets. The latter case can further be optimized with TCP user timeout extensions [RFC5482] as described in further detail by Schuetz et al [schuetz-intermittent]. The most CPU-intensive operations involve the use of the asymmetric keys and Diffie-Hellman key derivation at the control plane, but this occurs only during the key exchange, its maintenance (handoffs, refreshing of key material) and tear-down procedures of HIP associations. The data plane is typically implemented with ESP because it has a smaller overhead due to symmetric key encryption. Naturally, even ESP involves some overhead in terms of latency (processing costs) and throughput (tunneling) (see, e.g., [ylitalo-diss] for a performance evaluation). Moskowitz & Komu Expires August 18, 2019 [Page 42] Internet-Draft Host Identity Protocol Architecture February 2019 A.3. Deployment and adoption considerations This section describes some deployment and adoption considerations related to HIP from a technical perspective. A.3.1. Deployment analysis HIP has been adapted and deployed in an industrial control network in a production factory, in which HIP's strong network layer identity supports the secure coexistence of the control network with many untrusted network devices operated by third-party vendors [paine-hip]. Similarly, HIP has also been included in a security product to support layer-two Virtual Private Networks [henderson-vpls] to enable security zones in a supervisory control and data acquisition (SCADA) network. However, HIP has not been a "wild success" [RFC5218] in the Internet as argued by Levae et al [leva-barriers]. Here, we briefly highlight some of their findings based on interviews with 19 experts from the industry and academia. From a marketing perspective, the demand for HIP has been low and substitute technologies have been favored. Another identified reason has been that some technical misconceptions related to the early stages of HIP specifications still persist. Two identified misconceptions are that HIP does not support NAT traversal, and that HIP must be implemented in the OS kernel. Both of these claims are untrue; HIP does have NAT traversal extensions [I-D.ietf-hip-native-nat-traversal], and kernel modifications can be avoided with modern operating systems by diverting packets for userspace processing. The analysis by Levae et al clarifies infrastructural requirements for HIP. In a minimal set up, a client and server machine have to run HIP software. However, to avoid manual configurations, usually DNS records for HIP are set up. For instance, the popular DNS server software Bind9 does not require any changes to accommodate DNS records for HIP because they can be supported in binary format in its configuration files [RFC6538]. HIP rendezvous servers and firewalls are optional. No changes are required to network address points, NATs, edge routers or core networks. HIP may require holes in legacy firewalls. The analysis also clarifies the requirements for the host components that consist of three parts. First, a HIP control plane component is required, typically implemented as a userspace daemon. Second, a data plane component is needed. Most HIP implementations utilize the so called BEET mode of ESP that has been available since Linux kernel 2.6.27, but the BEET mode is also included as a userspace component in a few of the implementations. Third, HIP systems usually provide Moskowitz & Komu Expires August 18, 2019 [Page 43] Internet-Draft Host Identity Protocol Architecture February 2019 a DNS proxy for the local host that translates HIP DNS records to LSIs and HITs, and communicates the corresponding locators to HIP userspace daemon. While the third component is not mandatory, it is very useful for avoiding manual configurations. The three components are further described in the HIP experiment report [RFC6538]. Based on the interviews, Levae et al suggest further directions to facilitate HIP deployment. Transitioning a number of HIP specifications to the standards track in IETF has already taken place, but the authors suggest other additional measures based on the interviews. As a more radical measure, the authors suggest to implement HIP as a purely application-layer library [xin-hip-lib] or other kind of middleware. On the other hand, more conservative measures include focusing on private deployments controlled by a single stakeholder. As a more concrete example of such a scenario, HIP could be used by a single service provider to facilitate secure connectivity between its servers [komu-cloud]. A.3.2. HIP in 802.15.4 networks The IEEE 802 standards have been defining MAC layered security. Many of these standards use EAP [RFC3748] as a Key Management System (KMS) transport, but some like IEEE 802.15.4 [IEEE.802-15-4.2011] leave the KMS and its transport as "Out of Scope". HIP is well suited as a KMS in these environments: o HIP is independent of IP addressing and can be directly transported over any network protocol. o Master Keys in 802 protocols are commonly pair-based with group keys transported from the group controller using pair-wise keys. o AdHoc 802 networks can be better served by a peer-to-peer KMS than the EAP client/server model. o Some devices are very memory constrained and a common KMS for both MAC and IP security represents a considerable code savings. A.3.3. HIP and Internet of Things HIP requires certain amount computational resources from a device due to cryptographic processing. HIP scales down to phones and small system-on-chip devices (such as Raspberry Pis, Intel Edison), but small sensors operating with small batteries have remained problematic. Different extensions to the HIP have been developed to scale HIP down to smaller devices, typically with different security tradeoffs. For example, the non-cryptographic identifiers have been Moskowitz & Komu Expires August 18, 2019 [Page 44] Internet-Draft Host Identity Protocol Architecture February 2019 proposed in RFID scenarios. The slimfit approach [hummen] proposes a compression layer for HIP to make it more suitable for constrained networks. The approach is applied to a light-weight version of HIP (i.e. "Diet HIP") in order to scale down to small sensors. The HIP Diet Exchange [I-D.ietf-hip-dex] design aims at reducing the overhead of the employed cryptographic primitives by omitting public- key signatures and hash functions. In doing so, the main goal is to still deliver similar security properties to the Base Exchange (BEX). DEX is primarily designed for computation or memory- constrained sensor/actuator devices. Like BEX, it is expected to be used together with a suitable security protocol such as the Encapsulated Security Payload (ESP) for the protection of upper layer protocol data. In addition, DEX can also be used as a keying mechanism for security primitives at the MAC layer, e.g., for IEEE 802.15.9 networks ([IEEE.802-15-9]. The main differences between HIP BEX and DEX are: 1. Minimum collection of cryptographic primitives to reduce the protocol overhead. * Static Elliptic Curve Diffie-Hellman key pairs for peer authentication and encryption of the session key. * AES-CTR for symmetric encryption and AES-CMAC for MACing function. * A simple fold function for HIT generation. 2. Forfeit of Perfect Forward Secrecy with the dropping of an ephemeral Diffie-Hellman key agreement. 3. Forfeit of digital signatures with the removal of a hash function. Reliance on ECDH derived key used in HIP_MAC to prove ownership of the private key. 4. Diffie-Hellman derived key ONLY used to protect the HIP packets. A separate secret exchange within the HIP packets creates the session key(s). 5. Optional retransmission strategy tailored to handle the potentially extensive processing time of the employed cryptographic operations on computationally constrained devices. Moskowitz & Komu Expires August 18, 2019 [Page 45] Internet-Draft Host Identity Protocol Architecture February 2019 A.3.4. Infrastructure Applications HIP experimentation report [RFC6538] enumerates a number of client and server applications that have been trialed with HIP. Based on the report, this section highlights and complements some potential ways how HIP could be exploited in existing infrastructure such as routers, gateways and proxies. HIP has been successfully used with forward web proxies (i.e., client-side proxies). HIP was used between a client host (web browser) and a forward proxy (Apache server) that terminated the HIP/ ESP-tunnel. The forward web proxy translated HIP-based traffic originating from the client into non-HIP traffic towards any web server in the Internet. Consequently, the HIP-capable client could communicate with HIP-incapable web servers. This way, the client could utilize mobility support as provided by HIP while using the fixed IP address of the web proxy, for instance, to access services that were allowed only from the IP address range of the proxy. HIP has also been experimented with reverse web proxies (i.e. server- side proxies) as described in more detail in [komu-cloud]. In this scenario, a HIP-incapable client accessed a HIP-capable web service via an intermediary load balancer (that was a web based load balancer implementation called HAProxy). The load balancer translated non-HIP traffic originating from the client into HIP-based traffic for the web service (consisting of front-end and back-end servers). Both the load balancer and the web service were located in a datacenter. One of the key benefits for encrypting the web traffic with HIP in this scenario was to support a private-public cloud scenario (i.e. hybrid cloud) where the load balancer, front-end servers and back-end servers can be located in different datacenters and, thus, the traffic needs to protected when it passes through potentially insecure networks between the borders of the private and public clouds. While HIP could be used to secure access to intermediary devices (e.g., access to switches with legacy telnet), it has also been used to secure intermittent connectivity between middlebox infrastructure. For instance, earlier research [komu-mitigation] utilized HIP between Secure Mail Transport Protocol (SMTP) servers in order to exploit the computational puzzles of HIP as a spam mitigation mechanism. A rather obvious practical challenge in this approach was the lack of HIP adoption on existing SMTP servers. To avoid deployment hurdles with existing infrastructure, HIP could be applied in the context of new protocols with little deployment. Namely, HIP has been experimented in the context of a new protocol, peer-to-peer SIP [camarillo-p2psip]. The work has resulted in a Moskowitz & Komu Expires August 18, 2019 [Page 46] Internet-Draft Host Identity Protocol Architecture February 2019 number of related RFCs [RFC6078], [RFC6079], [RFC7086]. The key idea in the research work was to avoid redundant, time consuming ICE procedures by grouping different connections (i.e. SIP and media streams) together using the low-layer HIP which executes NAT traversal procedures only once per host. An interesting aspect in the approach was the use of P2P-SIP infrastructure as rendezvous servers for HIP control plane instead of utilizing the traditional HIP rendezvous services [RFC8004]. Researchers have proposed to use HIP in cellular networks as a mobility, multihoming and security solution. [hip-lte] provides a security analysis and simulation measurements of using HIP in Long Term Evolution (LTE) backhaul networks. HIP has been experimented with securing cloud internal connectivity. First with virtual machines [komu-cloud] and then later also between Linux containers [ranjbar-synaptic]. In both cases, HIP was suggested as a solution NAT traversal that could be utilized both internally by a cloud network and between multi-cloud deployments. Specifically in the former case, HIP was beneficial sustaining connectivity with a virtual machine while it migrates to a new location. In the latter case, Software-Defined Networking (SDN) controller acted as rendezvous server for HIP-capable containers. The controller enforced strong replay protection by adding middlebox nonces [heer-end-host] to the passing HIP base exchange and UPDATE messages. A.3.5. Management of Identities in a Commercial Product Tempered Networks provides HIP-based products. They refer to their platform as Identity-Defined Networking (IDN) [tempered-networks] because of HIP's identity-first networking architecture. Their objective has been to make it simple and non-disruptive to deploy HIP enabled services widely in production environments with the purpose of enabling transparent device authentication and authorization, cloaking, segmentation, and end-to-end networking. The goal is to eliminate much of the circular dependencies, exploits, and layered complexity of traditional "address-defined networking" that prevents mobility and verifiable device access control. The products in the portfolio of Tempered Networks utilize HIP as follows: o HIP Switches / Gateways - these are physical or virtual appliances that serve as the HIP gateway and policy enforcement point for non HIP-aware applications and devices located behind it. No IP or infrastructure changes are required in order to connect, cloak, and protect the non-HIP aware devices. Currently known supported platforms for HIP gateways are: x86 and ARM chipsets, ESXi, Hyper- V, KVM, AWS, Azure, and Google clouds. Moskowitz & Komu Expires August 18, 2019 [Page 47] Internet-Draft Host Identity Protocol Architecture February 2019 o HIP Relays / Rendezvous - are physical or virtual appliances that serve as identity based routers authorizing and bridging HIP endpoints without decrypting the HIP session. A HIP Relay can be deployed as a standalone appliance or in a cluster for horizontal scaling. All HIP aware endpoints and the devices they're connecting and protecting can remain privately addressed, The appliances eliminate IP conflicts, tunnel through NAT and CGNAT, and require no changes to the underlay infrastructure. The only requirement is that a HIP endpoint should have outbound access to the Internet and that a HIP Relay should have a public address. o HIP-Aware Clients and Servers - software that installs in the host's network stack and enforces policy for that host. HIP clients support split tunneling. Both HIP client and HIP server can interface with the local host firewall and HIP Server can be locked down to listen only on the port used for HIP, making the server invisible from unauthorized devices. Currently known supported platforms are Windows, OSX, iOS, Android, Ubuntu, CentOS and other Linux derivatives. o Policy Orchestration Managers - a physical or virtual appliance that serves as the engine to define and distribute network and security policy (HI and IP mappings, overlay networks and whitelist policies etc.) to HIP-aware endpoints. Orchestration does not need to persist to the HIP endpoints and vice versa allowing for autonomous host networking and security. A.4. Answers to NSRG questions The IRTF Name Space Research Group has posed a number of evaluating questions in their report [nsrg-report]. In this section, we provide answers to these questions. 1. How would a stack name improve the overall functionality of the Internet? HIP decouples the internetworking layer from the transport layer, allowing each to evolve separately. The decoupling makes end-host mobility and multi-homing easier, also across IPv4 and IPv6 networks. HIs make network renumbering easier, and they also make process migration and clustered servers easier to implement. Furthermore, being cryptographic in nature, they provide the basis for solving the security problems related to end-host mobility and multi-homing. 2. What does a stack name look like? Moskowitz & Komu Expires August 18, 2019 [Page 48] Internet-Draft Host Identity Protocol Architecture February 2019 A HI is a cryptographic public key. However, instead of using the keys directly, most protocols use a fixed-size hash of the public key. 3. What is its lifetime? HIP provides both stable and temporary Host Identifiers. Stable HIs are typically long-lived, with a lifetime of years or more. The lifetime of temporary HIs depends on how long the upper-layer connections and applications need them, and can range from a few seconds to years. 4. Where does it live in the stack? The HIs live between the transport and internetworking layers. 5. How is it used on the end points? The Host Identifiers may be used directly or indirectly (in the form of HITs or LSIs) by applications when they access network services. Additionally, the Host Identifiers, as public keys, are used in the built-in key agreement protocol, called the HIP base exchange, to authenticate the hosts to each other. 6. What administrative infrastructure is needed to support it? In some environments, it is possible to use HIP opportunistically, without any infrastructure. However, to gain full benefit from HIP, the HIs must be stored in the DNS or a PKI, and the rendezvous mechanism is needed [RFC8005]. 7. If we add an additional layer would it make the address list in SCTP unnecessary? Yes 8. What additional security benefits would a new naming scheme offer? HIP reduces dependency on IP addresses, making the so-called address ownership [Nik2001] problems easier to solve. In practice, HIP provides security for end-host mobility and multi-homing. Furthermore, since HIP Host Identifiers are public keys, standard public key certificate infrastructures can be applied on the top of HIP. Moskowitz & Komu Expires August 18, 2019 [Page 49] Internet-Draft Host Identity Protocol Architecture February 2019 9. What would the resolution mechanisms be, or what characteristics of a resolution mechanisms would be required? For most purposes, an approach where DNS names are resolved simultaneously to HIs and IP addresses is sufficient. However, if it becomes necessary to resolve HIs into IP addresses or back to DNS names, a flat resolution infrastructure is needed. Such an infrastructure could be based on the ideas of Distributed Hash Tables, but would require significant new development and deployment. Authors' Addresses Robert Moskowitz (editor) HTT Consulting Oak Park Michigan USA Email: rgm@labs.htt-consult.com Miika Komu Ericsson Hirsalantie 11 02420 Jorvas Finland Email: miika.komu@ericsson.com Moskowitz & Komu Expires August 18, 2019 [Page 50] ./draft-ietf-ace-coap-est-18.txt0000644000764400076440000032575213604670303015642 0ustar iustyiusty ACE P. van der Stok Internet-Draft Consultant Intended status: Standards Track P. Kampanakis Expires: July 9, 2020 Cisco Systems M. Richardson SSW S. Raza RISE SICS January 6, 2020 EST over secure CoAP (EST-coaps) draft-ietf-ace-coap-est-18 Abstract Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 9, 2020. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of van der Stok, et al. Expires July 9, 2020 [Page 1] Internet-Draft EST-coaps January 2020 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. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 13 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 15 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 24 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 24 9.3. Well-Known URIs Registry . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10.1. EST server considerations . . . . . . . . . . . . . . . 25 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 32 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 35 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 37 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. EST-coaps Block message examples . . . . . . . . . . 40 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 Appendix C. Message content breakdown . . . . . . . . . . . . . 45 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 46 van der Stok, et al. Expires July 9, 2020 [Page 2] Internet-Draft EST-coaps January 2020 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 1. Change Log EDNOTE: Remove this section before publication -18 IESG Reviews fixes. Removed spurious lines introduced in v-17 due to xml2rfc v3. -17 v16 remnants by Ben K. Typos. -16 Updates to address Yaron S.'s Secdir review. Updates to address David S.'s Gen-ART review. -15 Updates to addressed Ben's AD follow up feedback. -14 Updates to complete Ben's AD review feedback and discussions. -13 Updates based on AD's review and discussions Examples redone without password -12 Updated section 5 based on Esko's comments and nits identified. Nits and some clarifications for Esko's new review from 5/21/2019. Nits and some clarifications for Esko's new review from 5/28/2019. -11 van der Stok, et al. Expires July 9, 2020 [Page 3] Internet-Draft EST-coaps January 2020 Updated Server-side keygen to simplify motivation and added paragraphs in Security considerations to point out that random numbers are still needed (feedback from Hannes). -10 Addressed WGLC comments More consistent request format in the examples. Explained root resource difference when there is resource discovery Clarified when the client is supposed to do discovery Fixed nits and minor Option length inaccurracies in the examples. -09 WGLC comments taken into account consensus about discovery of content-format added additional path for content-format selection merged DTLS sections -08 added application/pkix-cert Content-Format TBD287. discovery text clarified Removed text on ct negotiation in connection to multipart-core removed text that duplicates or contradicts RFC7252 (thanks Klaus) Stated that well-known/est is compulsory Use of response codes clarified. removed bugs: Max-Age and Content-Format Options in Request Accept Option explained for est/skg and added in enroll example Added second URI /skc for server-side key gen and a simple cert (not PKCS#7) van der Stok, et al. Expires July 9, 2020 [Page 4] Internet-Draft EST-coaps January 2020 Persistence of DTLS connection clarified. Minor text fixes. -07: redone examples from scratch with openssl Updated authors. Added CoAP RST as a MAY for an equivalent to an HTTP 204 message. Added serialization example of the /skg CBOR response. Added text regarding expired IDevIDs and persistent DTLS connection that will start using the Explicit TA Database in the new DTLS connection. Nits and fixes Removed CBOR envelop for binary data Replaced TBD8 with 62. Added RFC8174 reference and text. Clarified MTI for server-side key generation and Content-Formats. Defined the /skg MTI (PKCS#8) and the cases where CMS encryption will be used. Moved Fragmentation section up because it was referenced in sections above it. -06: clarified discovery section, by specifying that no discovery may be needed for /.well-known/est URI. added resource type values for IANA added list of compulsory to implement and optional functions. Fixed issues pointed out by the idnits tool. Updated CoAP response codes section with more mappings between EST HTTP codes and EST-coaps CoAP codes. Minor updates to the MTI EST Functions section. van der Stok, et al. Expires July 9, 2020 [Page 5] Internet-Draft EST-coaps January 2020 Moved Change Log section higher. -05: repaired again TBD8 = 62 removed from C-F registration, to be done in CT draft. -04: Updated Delayed response section to reflect short and long delay options. -03: Removed observe and simplified long waits Repaired Content-Format specification -02: Added parameter discussion in section 8 Concluded Content-Format specification using multipart-ct draft examples updated -01: Editorials done. Redefinition of proxy to Registrar in Section 6. Explained better the role of https-coaps Registrar, instead of "proxy" Provide "observe" Option examples extended block message example. inserted new server key generation text in Section 5.8 and motivated server key generation. Broke down details for DTLS 1.3 New Media-Type uses CBOR array for multiple Content-Format payloads provided new Content-Format tables van der Stok, et al. Expires July 9, 2020 [Page 6] Internet-Draft EST-coaps January 2020 new media format for IANA -00 copied from vanderstok-ace-coap-04 2. Introduction "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used for authenticated/authorized endpoint certificate enrollment (and optionally key provisioning) through a Certificate Authority (CA) or Registration Authority (RA). EST transports messages over HTTPS. This document defines a new transport for EST based on the Constrained Application Protocol (CoAP) since some Internet of Things (IoT) devices use CoAP instead of HTTP. Therefore, this specification utilizes DTLS [RFC6347] and CoAP [RFC7252] instead of TLS [RFC8446] and HTTP [RFC7230]. EST responses can be relatively large and for this reason this specification also uses CoAP Block-Wise Transfer [RFC7959] to offer a fragmentation mechanism of EST messages at the CoAP layer. This document also profiles the use of EST to only support certificate-based client authentication. HTTP Basic or Digest authentication (as described in Section 3.2.3 of [RFC7030]) are not supported. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Many of the concepts in this document are taken from [RFC7030]. Consequently, much text is directly traceable to [RFC7030]. 4. DTLS and conformance to RFC7925 profiles This section describes how EST-coaps conforms to the profiles of low- resource devices described in [RFC7925]. EST-coaps can transport certificates and private keys. Certificates are responses to (re-)enrollment requests or requests for a trusted certificate list. Private keys can be transported as responses to a server-side key generation request as described in Section 4.4 of [RFC7030] (and subsections) and discussed in Section 5.8 of this document. van der Stok, et al. Expires July 9, 2020 [Page 7] Internet-Draft EST-coaps January 2020 EST-coaps depends on a secure transport mechanism that secures the exchanged CoAP messages. DTLS is one such secure protocol. No other changes are necessary regarding the secure transport of EST messages. +------------------------------------------------+ | EST request/response messages | +------------------------------------------------+ | CoAP for message transfer and signaling | +------------------------------------------------+ | Secure Transport | +------------------------------------------------+ Figure 1: EST-coaps protocol layers In accordance with sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. Curve secp256r1 MUST be supported [RFC8422]; this curve is equivalent to the NIST P-256 curve. After the publication of [RFC7748], support for Curve25519 will likely be required in the future by (D)TLS Profiles for the Internet of Things [RFC7925]. DTLS 1.2 implementations must use the Supported Elliptic Curves and Supported Point Formats Extensions in [RFC8422]. Uncompressed point format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13] implementations differ from DTLS 1.2 because they do not support point format negotiation in favor of a single point format for each curve. Thus, support for DTLS 1.3 does not mandate point format extensions and negotiation. In addition, in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups. CoAP was designed to avoid IP fragmentation. DTLS is used to secure CoAP messages. However, fragmentation is still possible at the DTLS layer during the DTLS handshake when using ECC ciphersuites. If fragmentation is necessary, "DTLS provides a mechanism for fragmenting a handshake message over several records, each of which can be transmitted separately, thus avoiding IP fragmentation" [RFC6347]. The authentication of the EST-coaps server by the EST-coaps client is based on certificate authentication in the DTLS handshake. The EST- coaps client MUST be configured with at least an Implicit TA database which will enable the authentication of the server the first time before updating its trust anchor (Explicit TA) [RFC7030]. The authentication of the EST-coaps client MUST be with a client certificate in the DTLS handshake. This can either be van der Stok, et al. Expires July 9, 2020 [Page 8] Internet-Draft EST-coaps January 2020 o a previously issued client certificate (e.g., an existing certificate issued by the EST CA); this could be a common case for simple re-enrollment of clients. o a previously installed certificate (e.g., manufacturer IDevID [ieee802.1ar] or a certificate issued by some other party). IDevID's are expected to have a very long life, as long as the device, but under some conditions could expire. In that case, the server MAY authenticate a client certificate against its trust store although the certificate is expired (Section 10). EST-coaps supports the certificate types and Trust Anchors (TA) that are specified for EST in Section 3 of [RFC7030]. As described in Section 2.1 of [RFC5272] proof-of-identity refers to a value that can be used to prove that an end-entity or client is in the possession of and can use the private key corresponding to the certified public key. Additionally, channel-binding information can link proof-of-identity with an established connection. Connection- based proof-of-possession is OPTIONAL for EST-coaps clients and servers. When proof-of-possession is desired, a set of actions are required regarding the use of tls-unique, described in Section 3.5 in [RFC7030]. The tls-unique information consists of the contents of the first "Finished" message in the (D)TLS handshake between server and client [RFC5929]. The client adds the "Finished" message as a ChallengePassword in the attributes section of the PKCS#10 Request [RFC5967] to prove that the client is indeed in control of the private key at the time of the (D)TLS session establishment. In the case of handshake message fragmentation, if proof-of- possession is desired, the Finished message added as the ChallengePassword in the CSR is calculated as specified by the DTLS standards. We summarize it here for convenience. For DTLS 1.2, in the event of handshake message fragmentation, the Hash of the handshake messages used in the MAC calculation of the Finished message must be computed on each reassembled message, as if each message had not been fragmented (Section 4.2.6 of [RFC6347]). The Finished message is calculated as shown in Section 7.4.9 of [RFC5246]. Similarly, for DTLS 1.3, the Finished message must be computed as if each handshake message had been sent as a single fragment (Section 5.8 of [I-D.ietf-tls-dtls13]) following the algorithm described in 4.4.4 of [RFC8446]. In a constrained CoAP environment, endpoints can't always afford to establish a DTLS connection for every EST transaction. An EST-coaps DTLS connection MAY remain open for sequential EST transactions, which was not the case with [RFC7030]. For example, if a /crts request is followed by a /sen request, both can use the same van der Stok, et al. Expires July 9, 2020 [Page 9] Internet-Draft EST-coaps January 2020 authenticated DTLS connection. However, when a /crts request is included in the set of sequential EST transactions, some additional security considerations apply regarding the use of the Implicit and Explicit TA database as explained in Section 10.1. Given that after a successful enrollment, it is more likely that a new EST transaction will not take place for a significant amount of time, the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other. These could include a /sen immediatelly following a /crts when a device is getting bootstrapped. In some cases, like NAT rebinding, keeping the state of a connection is not possible when devices sleep for extended periods of time. In such occasions, [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can eliminate the need for new handshake and its additional cost; or DTLS session resumption provides a less costly alternative than re-doing a full DTLS handshake. 5. Protocol Design EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise Transfer [RFC7959] to avoid IP fragmentation. The use of Blocks for the transfer of larger EST messages is specified in Section 5.6. Figure 1 shows the layered EST-coaps architecture. The EST-coaps protocol design follows closely the EST design. The supported message types in EST-coaps are: o CA certificate retrieval needed to receive the complete set of CA certificates. o Simple enroll and re-enroll for a CA to sign client identity public key. o Certificate Signing Request (CSR) attribute messages that informs the client of the fields to include in a CSR. o Server-side key generation messages to provide a client identity private key when the client chooses so. While [RFC7030] permits a number of the EST functions to be used without authentication, this specification requires that the client MUST be authenticated for all functions. 5.1. Discovery and URIs EST-coaps is targeted for low-resource networks with small packets. Two types of installations are possible: (1) rigid ones, where the address and the supported functions of the EST server(s) are known, van der Stok, et al. Expires July 9, 2020 [Page 10] Internet-Draft EST-coaps January 2020 and (2) a flexible one, where the EST server and its supported functions need to be discovered. For both types of installations, saving header space is important and short EST-coaps URIs are specified in this document. These URIs are shorter than the ones in [RFC7030]. Two example EST-coaps resource path names are: coaps://example.com:/.well-known/est/ coaps://example.com:/.well-known/est/ArbitraryLabel/ The short-est strings are defined in Table 1. Arbitrary Labels are usually defined and used by EST CAs in order to route client requests to the appropriate certificate profile. Implementers should consider using short labels to minimize transmission overhead. The EST-coaps server URIs, obtained through discovery of the EST- coaps resource(s) as shown below, are of the form: coaps://example.com:// coaps://example.com://ArbitraryLabel/ Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and corresponding paths which are supported by EST. Table 1 provides the mapping from the EST URI path to the shorter EST-coaps URI path. +-------------------+-------------------------------+ | EST | EST-coaps | +-------------------+-------------------------------+ | /cacerts | /crts | | /simpleenroll | /sen | | /simplereenroll | /sren | | /serverkeygen | /skg (PKCS#7) | | /serverkeygen | /skc (application/pkix-cert) | | /csrattrs | /att | +-------------------+-------------------------------+ Table 1: Short EST-coaps URI path The /skg message is the EST /serverkeygen equivalent where the client requests a certificate in PKCS#7 format and a private key. If the client prefers a single application/pkix-cert certificate instead of PKCS#7, it will make an /skc request. In both cases (i.e., /skg, /skc) a private key MUST be returned. Clients and servers MUST support the short resource EST-coaps URIs. van der Stok, et al. Expires July 9, 2020 [Page 11] Internet-Draft EST-coaps January 2020 In the context of CoAP, the presence and location of (path to) the EST resources are discovered by sending a GET request to "/.well- known/core" including a resource type (RT) parameter with the value "ace.est*" [RFC6690]. The example below shows the discovery over CoAPS of the presence and location of EST-coaps resources. Linefeeds are included only for readability. REQ: GET /.well-known/core?rt=ace.est* RES: 2.05 Content ;rt="ace.est.crts";ct="281 TBD287", ;rt="ace.est.sen";ct="281 TBD287", ;rt="ace.est.sren";ct="281 TBD287", ;rt="ace.est.att";ct=285, ;rt="ace.est.skg";ct=62, ;rt="ace.est.skc";ct=62 The first three lines, describing ace.est.crts, ace.est.sen, and ace.est.sren, of the discovery response above MUST be returned if the server supports resource discovery. The last three lines are only included if the corresponding EST functions are implemented (see Table 2). The Content-Formats in the response allow the client to request one that is supported by the server. These are the values that would be sent in the client request with an Accept option. Discoverable port numbers can be returned in the response payload. An example response payload for non-default CoAPS server port 61617 follows below. Linefeeds are included only for readability. REQ: GET /.well-known/core?rt=ace.est* RES: 2.05 Content ;rt="ace.est.crts"; ct="281 TBD287", ;rt="ace.est.sen"; ct="281 TBD287", ;rt="ace.est.sren"; ct="281 TBD287", ;rt="ace.est.att"; ct=285, ;rt="ace.est.skg"; ct=62, ;rt="ace.est.skc"; ct=62 The server MUST support the default /.well-known/est root resource. The server SHOULD support resource discovery when it supports non- default URIs (like /est or /est/ArbitraryLabel) or ports. The client van der Stok, et al. Expires July 9, 2020 [Page 12] Internet-Draft EST-coaps January 2020 SHOULD use resource discovery when it is unaware of the available EST-coaps resources. Throughout this document the example root resource of /est is used. 5.2. Mandatory/optional EST Functions This specification contains a set of required-to-implement functions, optional functions, and not specified functions. The unspecified functions are deemed too expensive for low-resource devices in payload and calculation times. Table 2 specifies the mandatory-to-implement or optional implementation of the EST-coaps functions. Discovery of the existence of optional functions is described in Section 5.1. +-------------------+--------------------------+ | EST Functions | EST-coaps implementation | +-------------------+--------------------------+ | /cacerts | MUST | | /simpleenroll | MUST | | /simplereenroll | MUST | | /fullcmc | Not specified | | /serverkeygen | OPTIONAL | | /csrattrs | OPTIONAL | +-------------------+--------------------------+ Table 2: List of EST-coaps functions 5.3. Payload formats EST-coaps is designed for low-resource devices and hence does not need to send Base64-encoded data. Simple binary is more efficient (30% smaller payload for DER-encoded ASN.1) and well supported by CoAP. Thus, the payload for a given Media-Type follows the ASN.1 structure of the Media-Type and is transported in binary format. The Content-Format (HTTP Content-Type equivalent) of the CoAP message determines which EST message is transported in the CoAP payload. The Media-Types specified in the HTTP Content-Type header field (Section 3.2.2 of [RFC7030]) are specified by the Content-Format Option (12) of CoAP. The combination of URI-Path and Content-Format in EST-coaps MUST map to an allowed combination of URI and Media-Type in EST. The required Content-Formats for these requests and response messages are defined in Section 9.1. The CoAP response codes are defined in Section 5.5. van der Stok, et al. Expires July 9, 2020 [Page 13] Internet-Draft EST-coaps January 2020 Content-Format TBD287 can be used in place of 281 to carry a single certificate instead of a PKCS#7 container in a /crts, /sen, /sren or /skg response. Content-Format 281 MUST be supported by EST-coaps servers. Servers MAY also support Content-Format TBD287. It is up to the client to support only Content-Format 281, TBD287 or both. The client will use a COAP Accept Option in the request to express the preferred response Content-Format. If an Accept Option is not included in the request, the client is not expressing any preference and the server SHOULD choose format 281. Content-Format 286 is used in /sen, /sren and /skg requests and 285 in /att responses. A representation with Content-Format identifier 62 contains a collection of representations along with their respective Content- Format. The Content-Format identifies the Media-Type application/ multipart-core specified in [I-D.ietf-core-multipart-ct]. For example, a collection, containing two representations in response to a EST-coaps server-side key generation /skg request, could include a private key in PKCS#8 [RFC5958] with Content-Format identifier 284 (0x011C) and a single certificate in a PKCS#7 container with Content- Format identifier 281 (0x0119). Such a collection would look like [284,h'0123456789abcdef', 281,h'fedcba9876543210'] in diagnostic CBOR notation. The serialization of such CBOR content would be 84 # array(4) 19 011C # unsigned(284) 48 # bytes(8) 0123456789ABCDEF # "\x01#Eg\x89\xAB\xCD\xEF" 19 0119 # unsigned(281) 48 # bytes(8) FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10" Multipart /skg response serialization When the client makes an /skc request the certificate returned with the private key is a single X.509 certificate (not a PKCS#7 container) with Content-Format identifier TBD287 (0x011F) instead of 281. In cases where the private key is encrypted with CMS (as explained in Section 5.8) the Content-Format identifier is 280 (0x0118) instead of 284. The content format used in the response is summarized in Table 3. van der Stok, et al. Expires July 9, 2020 [Page 14] Internet-Draft EST-coaps January 2020 +----------+-----------------+-----------------+ | Function | Response part 1 | Response part 2 | +----------+-----------------+-----------------+ | /skg | 284 | 281 | | /skc | 280 | TBD287 | +----------+-----------------+-----------------+ Table 3: response content formats for skg and skc The key and certificate representations are DER-encoded ASN.1, in its native binary form. An example is shown in Appendix A.3. 5.4. Message Bindings The general EST-coaps message characteristics are: o EST-coaps servers sometimes need to provide delayed responses which are preceded by an immediately returned empty ACK or an ACK containing response code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED for implementers to send EST-coaps requests in confirmable CON CoAP messages. o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content- Format, Block1, Block2, and Accept. These CoAP Options are used to communicate the HTTP fields specified in the EST REST messages. The Uri-host and Uri-Port Options can be omitted from the COAP message sent on the wire. When omitted, they are logically assumed to be the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. Other COAP Options should be handled in accordance with [RFC7252]. o EST URLs are HTTPS based (https://), in CoAP these are assumed to be translated to CoAPS (coaps://) Table 1 provides the mapping from the EST URI path to the EST-coaps URI path. Appendix A includes some practical examples of EST messages translated to CoAP. 5.5. CoAP response codes Section 5.9 of [RFC7252] and Section 7 of [RFC8075] specify the mapping of HTTP response codes to CoAP response codes. The success code in response to an EST-coaps GET request (/crts, /att), is 2.05. Similarly, 2.04 is used in successful response to EST-coaps POST requests (/sen, /sren, /skg, /skc). van der Stok, et al. Expires July 9, 2020 [Page 15] Internet-Draft EST-coaps January 2020 EST makes use of HTTP 204 or 404 responses when a resource is not available for the client. In EST-coaps 2.04 is used in response to a POST (/sen, /sren, /skg, /skc). 4.04 is used when the resource is not available for the client. HTTP response code 202 with a Retry-After header field in [RFC7030] has no equivalent in CoAP. HTTP 202 with Retry-After is used in EST for delayed server responses. Section 5.7 specifies how EST-coaps handles delayed messages with 5.03 responses with a Max-Age Option. Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes have their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes in EST-coaps. Table 4 summarizes the EST-coaps response codes. +-----------------+-----------------+-------------------------------+ | operation | EST-coaps | Description | | | response code | | +-----------------+-----------------+-------------------------------+ | /crts, /att | 2.05 | Success. Certs included in | | | | the response payload. | | | 4.xx / 5.xx | Failure. | | /sen, /skg, | 2.04 | Success. Cert included in the | | /sren, /skc | | response payload. | | | 5.03 | Retry in Max-Age Option time. | | | 4.xx / 5.xx | Failure. | +-----------------+-----------------+-------------------------------+ Table 4: EST-coaps response codes 5.6. Message fragmentation DTLS defines fragmentation only for the handshake and not for secure data exchange (DTLS records). [RFC6347] states that to avoid using IP fragmentation, which involves error-prone datagram reconstitution, invokers of the DTLS record layer should size DTLS records so that they fit within any Path MTU estimates obtained from the record layer. In addition, invokers residing on a 6LoWPAN over IEEE 802.15.4 [ieee802.15.4] network are recommended to size CoAP messages such that each DTLS record will fit within one or two IEEE 802.15.4 frames. That is not always possible in EST-coaps. Even though ECC certificates are small in size, they can vary greatly based on signature algorithms, key sizes, and Object Identifier (OID) fields used. For 256-bit curves, common ECDSA cert sizes are 500-1000 bytes which could fluctuate further based on the algorithms, OIDs, Subject Alternative Names (SAN) and cert fields. For 384-bit curves, ECDSA certificates increase in size and can sometimes reach 1.5KB. van der Stok, et al. Expires July 9, 2020 [Page 16] Internet-Draft EST-coaps January 2020 Additionally, there are times when the EST cacerts response from the server can include multiple certificates that amount to large payloads. Section 4.6 of CoAP [RFC7252] describes the possible payload sizes: "if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size". Section 4.6 of [RFC7252] also suggests that IPv4 implementations may want to limit themselves to more conservative IPv4 datagram sizes such as 576 bytes. Even with ECC, EST-coaps messages can still exceed MTU sizes on the Internet or 6LoWPAN [RFC4919] (Section 2 of [RFC7959]). EST-coaps needs to be able to fragment messages into multiple DTLS datagrams. To perform fragmentation in CoAP, [RFC7959] specifies the Block1 Option for fragmentation of the request payload and the Block2 Option for fragmentation of the return payload of a CoAP flow. As explained in Section 1 of [RFC7959], block-wise transfers should be used in Confirmable CoAP messages to avoid the exacerbation of lost blocks. EST-coaps servers MUST implement Block1 and Block2. EST-coaps clients MUST implement Block2. EST-coaps clients MUST implement Block1 only if they are expecting to send EST-coaps requests with a packet size that exceeds the Path MTU. [RFC7959] also defines Size1 and Size2 Options to provide size information about the resource representation in a request and response. EST-client and server MAY support Size1 and Size2 Options. Examples of fragmented EST-coaps messages are shown in Appendix B. 5.7. Delayed Responses Server responses can sometimes be delayed. According to Section 5.2.2 of [RFC7252], a slow server can acknowledge the request and respond later with the requested resource representation. In particular, a slow server can respond to an EST-coaps enrollment request with an empty ACK with code 0.00, before sending the certificate to the client after a short delay. If the certificate response is large, the server will need more than one Block2 block to transfer it. This situation is shown in Figure 2. The client sends an enrollment request that uses N1+1 Block1 blocks. The server uses an empty 0.00 ACK to announce the delayed response which is provided later with 2.04 messages containing N2+1 Block2 Options. The first 2.04 is a confirmable message that is acknowledged by the client. Onwards, the client acknowledges all subsequent Block2 blocks. The notation of Figure 2 is explained in Appendix B.1. van der Stok, et al. Expires July 9, 2020 [Page 17] Internet-Draft EST-coaps January 2020 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> <-- (0.00 empty ACK) | ... Short delay before the certificate is ready ... | <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)} (ACK) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)} . . . POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} Figure 2: EST-COAP enrollment with short wait If the server is very slow (for example, manual intervention is required which would take minutes), it SHOULD respond with an ACK containing response code 5.03 (Service unavailable) and a Max-Age Option to indicate the time the client SHOULD wait before sending another request to obtain the content. After a delay of Max-Age, the client SHOULD resend the identical CSR to the server. As long as the server continues to respond with response code 5.03 (Service Unavailable) with a Max-Age Option, the client will continue to delay for Max-Age and then resend the enrollment request until the server responds with the certificate or the client abandons the request for policy or other reasons. To demonstrate this scenario, Figure 3 shows a client sending an enrollment request that uses N1+1 Block1 blocks to send the CSR to the server. The server needs N2+1 Block2 blocks to respond, but also needs to take a long delay (minutes) to provide the response. Consequently, the server uses a 5.03 ACK response with a Max-Age Option. The client waits for a period of Max-Age as many times as it receives the same 5.03 response and retransmits the enrollment request until it receives a certificate in a fragmented 2.04 response. van der Stok, et al. Expires July 9, 2020 [Page 18] Internet-Draft EST-coaps January 2020 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) | | ... Client tries again after Max-Age with identical payload ... | | POST [2001:db8::2:1]:61616/est/sen(CON)(1:0/1/256){CSR (frag# 1)}--> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> | ... Immediate response when certificate is ready ... | <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)} POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> <-- (ACK) (2:1/1/256) (2.04 Changed) {Cert resp (frag# 2)} . . . POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) --> <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} Figure 3: EST-COAP enrollment with long wait 5.8. Server-side Key Generation Private keys can be generated on the server to support scenarios where serer-side key generation is needed. Such scenarios include those where it is considered more secure to generate the long-lived, random private key that identifies the client at the server, or where the resources spent to generate a random private key at the client are considered scarce, or where the security policy requires that the certificate public and corresponding private keys are centrally generated and controlled. As always, it is necessary to use proper random numbers in various protocols such as (D)TLS (Section 10.1). van der Stok, et al. Expires July 9, 2020 [Page 19] Internet-Draft EST-coaps January 2020 When requesting server-side key generation, the client asks for the server or proxy to generate the private key and the certificate, which are transferred back to the client in the server-side key generation response. In all respects, the server treats the CSR as it would treat any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow re-use of existing codebases for generating and parsing such requests. The client /skg request is for a certificate in a PKCS#7 container and private key in two application/multipart-core elements. Respectively, an /skc request is for a single application/pkix-cert certificate and a private key. The private key Content-Format requested by the client is indicated in the PKCS#10 CSR request. If the request contains SMIMECapabilities and DecryptKeyIdentifier or AsymmetricDecryptKeyIdentifier the client is expecting Content-Format 280 for the private key. Then this private key is encrypted symmetrically or asymmetrically as per [RFC7030]. The symmetric key or the asymmetric keypair establishment method is out of scope of this specification. A /skg or /skc request with a CSR without SMIMECapabilities expects an application/multipart-core with an unencrypted PKCS#8 private key with Content-Format 284. The EST-coaps server-side key generation response is returned with Content-Format application/multipart-core [I-D.ietf-core-multipart-ct] containing a CBOR array with four items (Section 5.3). The two representations (each consisting of two CBOR array items) do not have to be in a particular order since each representation is preceded by its Content-Format ID. Depending on the request, the private key can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or protected inside of CMS SignedData (Content-Format 280). The SignedData, placed in the outermost container, is signed by the party that generated the private key, which may be the EST server or the EST CA. SignedData placed within the Enveloped Data does not need additional signing as explained in Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted key is included in the encryptedKey attribute in a KEKRecipientInfo structure. In the case where the asymmetric encryption key is suitable for transport key operations the generated private key is encrypted with a symmetric key. The symmetric key itself is encrypted by the client-defined (in the CSR) asymmetric public key and is carried in an encryptedKey attribute in a KeyTransRecipientInfo structure. Finally, if the asymmetric encryption key is suitable for key agreement, the generated private key is encrypted with a symmetric key. The symmetric key itself is encrypted by the client defined (in the CSR) asymmetric public key and is carried in an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo. van der Stok, et al. Expires July 9, 2020 [Page 20] Internet-Draft EST-coaps January 2020 [RFC7030] recommends the use of additional encryption of the returned private key. For the context of this specification, clients and servers that choose to support server-side key generation MUST support unprotected (PKCS#8) private keys (Content-Format 284). Symmetric or asymmetric encryption of the private key (CMS EnvelopedData, Content-Format 280) SHOULD be supported for deployments where end-to-end encryption is needed between the client and a server. Such cases could include architectures where an entity between the client and the CA terminates the DTLS connection (Registrar in Figure 4). Although [RFC7030] strongly recommends that clients request the use of CMS encryption on top of the TLS channel's protection, this document does not make such a recommendation; CMS encryption can still be used when mandated by the use-case. 6. HTTPS-CoAPS Registrar In real-world deployments, the EST server will not always reside within the CoAP boundary. The EST server can exist outside the constrained network in which case it will support TLS/HTTP instead of CoAPS. In such environments EST-coaps is used by the client within the CoAP boundary and TLS is used to transport the EST messages outside the CoAP boundary. A Registrar at the edge is required to operate between the CoAP environment and the external HTTP network as shown in Figure 4. Constrained Network .------. .----------------------------. | CA | |.--------------------------.| '------' || || | || || .------. HTTP .-----------------. CoAPS .-----------. || | EST |<------->|EST-coaps-to-HTTPS|<------->| EST Client| || |Server|over TLS | Registrar | '-----------' || '------' '-----------------' || || || |'--------------------------'| '----------------------------' Figure 4: EST-coaps-to-HTTPS Registrar at the CoAP boundary. The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream and initiate EST connections over TLS upstream. The Registrar MUST authenticate and optionally authorize the client requests while it MUST be authenticated by the EST server or CA. The trust relationship between the Registrar and the EST server SHOULD be pre- established for the Registrar to proxy these connections on behalf of various clients. van der Stok, et al. Expires July 9, 2020 [Page 21] Internet-Draft EST-coaps January 2020 When enforcing Proof-of-Possession (PoP) linking, the DTLS tls-unique value of the (D)TLS session is used to prove that the private key corresponding to the public key is in the possession of the client and was used to establish the connection as explained in Section 4. The PoP linking information is lost between the EST-coaps client and the EST server when a Registrar is present. The EST server becomes aware of the presence of a Registrar from its TLS client certificate that includes id-kp-cmcRA [RFC6402] extended key usage extension (EKU). As explained in Section 3.7 of [RFC7030], the "EST server SHOULD apply an authorization policy consistent with a Registrar client. For example, it could be configured to accept PoP linking information that does not match the current TLS session because the authenticated EST client Registrar has verified this information when acting as an EST server". Table 1 contains the URI mappings between EST-coaps and EST that the Registrar MUST adhere to. Section 5.5 of this specification and Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP response codes, that determine how the Registrar MUST translate CoAP response codes from/to HTTP status codes. The mapping from CoAP Content-Format to HTTP Content-Type is defined in Section 9.1. Additionally, a conversion from CBOR major type 2 to Base64 encoding MUST take place at the Registrar. If CMS end-to-end encryption is employed for the private key, the encrypted CMS EnvelopedData blob MUST be converted at the Registrar to binary CBOR type 2 downstream to the client. This is a format conversion that does not require decryption of the CMS EnvelopedData. A deviation from the mappings in Table 1 could take place if clients that leverage server-side key generation preferred for the enrolled keys to be generated by the Registrar in the case the CA does not support server-side key generation. Such a Registrar is responsible for generating a new CSR signed by a new key which will be returned to the client along with the certificate from the CA. In these cases, the Registrar MUST use random number generation with proper entropy. Due to fragmentation of large messages into blocks, an EST-coaps-to- HTTP Registrar MUST reassemble the BLOCKs before translating the binary content to Base64, and consecutively relay the message upstream. The EST-coaps-to-HTTP Registrar MUST support resource discovery according to the rules in Section 5.1. van der Stok, et al. Expires July 9, 2020 [Page 22] Internet-Draft EST-coaps January 2020 7. Parameters This section addresses transmission parameters described in sections 4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on the CoAP parameters in [RFC7252], but the setting of the CoAP parameter values may have consequence for the setting of the EST parameter values. Implementations should follow the default CoAP configuration parameters [RFC7252]. However, depending on the implementation scenario, retransmissions and timeouts can also occur on other networking layers, governed by other configuration parameters. When a change in a server parameter has taken place, the parameter values in the communicating endpoints MUST be adjusted as necessary. Examples of how parameters could be adjusted include higher layer congestion protocols, provisioning agents and configurations included in firmware updates. Some further comments about some specific parameters, mainly from Table 2 in [RFC7252]: o NSTART: A parameter that controls the number of simultaneous outstanding interactions that a client maintains to a given server. An EST-coaps client is expected to control at most one interaction with a given server, which is the default NSTART value defined in [RFC7252]. o DEFAULT_LEISURE: This setting is only relevant in multicast scenarios, outside the scope of EST-coaps. o PROBING_RATE: A parameter which specifies the rate of re-sending non-confirmable messages. In the rare situations that non- confirmable messages are used, the default PROBING_RATE value defined in [RFC7252] applies. Finally, the Table 3 parameters in [RFC7252] are mainly derived from Table 2. Directly changing parameters on one table would affect parameters on the other. 8. Deployment limitations Although EST-coaps paves the way for the utilization of EST by constrained devices in constrained networks, some classes of devices [RFC7228] will not have enough resources to handle the payloads that come with EST-coaps. The specification of EST-coaps is intended to ensure that EST works for networks of constrained devices that choose to limit their communications stack to DTLS/CoAP. It is up to the van der Stok, et al. Expires July 9, 2020 [Page 23] Internet-Draft EST-coaps January 2020 network designer to decide which devices execute the EST protocol and which do not. 9. IANA Considerations 9.1. Content-Format Registry Additions to the sub-registry "CoAP Content-Formats", within the "CoRE Parameters" registry [COREparams] are specified in Table 5. These have been registered provisionally in the IETF Review or IESG Approval range (256-9999). +------------------------------+-------+----------------------------+ | HTTP Content-Type | ID | Reference | +------------------------------+-------+----------------------------+ | application/pkcs7-mime; | 280 | [RFC7030] [I-D.ietf-lamps- | | smime-type=server-generated- | | rfc5751-bis] [ThisRFC] | | key | | | | application/pkcs7-mime; | 281 | [I-D.ietf-lamps-rfc5751-bi | | smime-type=certs-only | | s] [ThisRFC] | | application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- | | | | rfc5751-bis] [ThisRFC] | | application/csrattrs | 285 | [RFC7030] | | application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- | | | | rfc5751-bis] [ThisRFC] | | application/pkix-cert | TBD28 | [RFC2585] [ThisRFC] | | | 7 | | +------------------------------+-------+----------------------------+ Table 5: New CoAP Content-Formats It is suggested that 287 is allocated to TBD287. 9.2. Resource Type registry This memo registers new Resource Type (rt=) Link Target Attributes in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry. o rt="ace.est.crts". This resource depicts the support of EST get cacerts. o rt="ace.est.sen". This resource depicts the support of EST simple enroll. o rt="ace.est.sren". This resource depicts the support of EST simple reenroll. van der Stok, et al. Expires July 9, 2020 [Page 24] Internet-Draft EST-coaps January 2020 o rt="ace.est.att". This resource depicts the support of EST get CSR attributes. o rt="ace.est.skg". This resource depicts the support of EST server-side key generation with the returned certificate in a PKCS#7 container. o rt="ace.est.skc". This resource depicts the support of EST server-side key generation with the returned certificate in application/pkix-cert format. 9.3. Well-Known URIs Registry A new additional reference is requested for the est URI in the Well- Known URIs registry: +------+--------+---------+---------+----------+---------+----------+ | URI | Change | Referen | Status | Related | Date Re | Date | | Suff | Contro | ces | | Informat | gistere | Modified | | ix | ller | | | ion | d | | +------+--------+---------+---------+----------+---------+----------+ | est | IETF | [RFC703 | permane | | 2013-08 | [THIS | | | | 0] | nt | | -16 | RFC's pu | | | | [THIS | | | | blicatio | | | | RFC] | | | | n date] | +------+--------+---------+---------+----------+---------+----------+ 10. Security Considerations 10.1. EST server considerations The security considerations of Section 6 of [RFC7030] are only partially valid for the purposes of this document. As HTTP Basic Authentication is not supported, the considerations expressed for using passwords do not apply. The other portions of the security considerations of [RFC7030] continue to apply. Modern security protocols require random numbers to be available during the protocol run, for example for nonces and ephemeral (EC) Diffie-Hellman key generation. This capability to generate random numbers is also needed when the constrained device generates the private key (that corresponds to the public key enrolled in the CSR). When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925]. Additionally, the transport of keys generated at the server is inherently risky. For those deploying server-side key generation, analysis SHOULD be van der Stok, et al. Expires July 9, 2020 [Page 25] Internet-Draft EST-coaps January 2020 done to establish whether server-side key generation increases or decreases the probability of digital identity theft. It is important to note that, as pointed out in [PsQs], sources contributing to the randomness pool used to generate random numbers on laptops or desktop PCs, such as mouse movement, timing of keystrokes, or air turbulence on the movement of hard drive heads, are not available on many constrained devices. Other sources have to be used or dedicated hardware has to be added. Selecting hardware for an IoT device that is capable of producing high-quality random numbers is therefore important [RSAfact]. As discussed in Section 6 of [RFC7030], it is "RECOMMENDED that the Implicit Trust Anchor database used for EST server authentication is carefully managed to reduce the chance of a third-party CA with poor certification practices jeopardizing authentication. Disabling the Implicit Trust Anchor database after successfuly receiving the Distribution of CA certificates response (Section 4.1.3) limits any risk to the first TLS exchange". Alternatively, in a case where a /sen request immediately follows a /crts, a client MAY choose to keep the connection authenticated by the Implicit TA open for efficiency reasons (Section 4). A client that interleaves EST-coaps /crts request with other requests in the same DTLS connection SHOULD revalidate the server certificate chain against the updated Explicit TA from the /crts response before proceeding with the subsequent requests. If the server certificate chain does not authenticate against the database, the client SHOULD close the connection without completing the rest of the requests. The updated Explicit TA MUST continue to be used in new DTLS connections. In cases where the IDevID used to authenticate the client is expired the server MAY still authenticate the client because IDevIDs are expected to live as long as the device itself (Section 4). In such occasions, checking the certificate revocation status or authorizing the client using another method is important for the server to raise its confidence that the client can be trusted. In accordance with [RFC7030], TLS cipher suites that include "_EXPORT_" and "_DES_" in their names MUST NOT be used. More recommendations for secure use of TLS and DTLS are included in [BCP195]. As described in CMC, Section 6.7 of [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a PoP on that key pair". The inclusion of tls- unique in the certificate request links the proof-of-possession to the TLS proof-of-identity. This implies but does not prove that only the authenticated client currently has access to the private key. van der Stok, et al. Expires July 9, 2020 [Page 26] Internet-Draft EST-coaps January 2020 What's more, CMC PoP linking uses tls-unique as it is defined in [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing a man-in-the-middle to leverage session resumption and renegotiation to inject himself between a client and server even when channel binding is in use. Implementers should use the Extended Master Secret Extension in DTLS [RFC7627] to prevent such attacks. In the context of this specification, an attacker could invalidate the purpose of the PoP linking ChallengePassword in the client request by resuming an EST-coaps connection. Even though the practical risk of such an attack to EST-coaps is not devastating, we would rather use a more secure channel binding mechanism. Such a mechanism could include an updated tls-unique value generation like the tls-unique- prf defined in [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]) value in place of the tls-unique value in the CSR. Such mechanism has not been standardized yet. Adopting a channel binding value generated from an exporter would break backwards compatibility for an RA that proxies through to a classic EST server. Thus, in this specification we still depend on the tls-unique mechanism defined in [RFC5929], especially since a 3SHAKE attack does not expose messages exchanged with EST-coaps. Interpreters of ASN.1 structures should be aware of the use of invalid ASN.1 length fields and should take appropriate measures to guard against buffer overflows, stack overruns in particular, and malicious content in general. 10.2. HTTPS-CoAPS Registrar considerations The Registrar proposed in Section 6 must be deployed with care, and only when direct client-server connections are not possible. When PoP linking is used the Registrar terminating the DTLS connection establishes a new TLS connection with the upstream CA. Thus, it is impossible for PoP linking to be enforced end-to-end for the EST transaction. The EST server could be configured to accept PoP linking information that does not match the current TLS session because the authenticated EST Registrar is assumed to have verified PoP linking downstream to the client. The introduction of an EST-coaps-to-HTTP Registrar assumes the client can authenticate the Registrar using its implicit or explicit TA database. It also assumes the Registrar has a trust relationship with the upstream EST server in order to act on behalf of the clients. When a client uses the Implicit TA database for certificate validation, it SHOULD confirm if the server is acting as an RA by the presence of the id-kp-cmcRA EKU [RFC6402] in the server certificate. van der Stok, et al. Expires July 9, 2020 [Page 27] Internet-Draft EST-coaps January 2020 In a server-side key generation case, if no end-to-end encryption is used, the Registrar may be able see the private key as it acts as a man-in-the-middle. Thus, the client puts its trust on the Registrar not exposing the private key. Clients that leverage server-side key generation without end-to-end encryption of the private key (Section 5.8) have no knowledge if the Registrar will be generating the private key and enrolling the certificates with the CA or if the CA will be responsible for generating the key. In such cases, the existence of a Registrar requires the client to put its trust on the registrar when it is generating the private key. 11. Contributors Martin Furuhed contributed to the EST-coaps specification by providing feedback based on the Nexus EST over CoAPS server implementation that started in 2015. Sandeep Kumar kick-started this specification and was instrumental in drawing attention to the importance of the subject. 12. Acknowledgements The authors are very grateful to Klaus Hartke for his detailed explanations on the use of Block with DTLS and his support for the Content-Format specification. The authors would like to thank Esko Dijk and Michael Verschoor for the valuable discussions that helped in shaping the solution. They would also like to thank Peter Panburana for his feedback on technical details of the solution. Constructive comments were received from Benjamin Kaduk, Eliot Lear, Jim Schaad, Hannes Tschofenig, Julien Vermillard, John Manuel, Oliver Pfaff, Pete Beal and Carsten Bormann. Interop tests were done by Oliver Pfaff, Thomas Werner, Oskar Camezind, Bjorn Elmers and Joel Hoglund. Robert Moskowitz provided code to create the examples. 13. References 13.1. Normative References [I-D.ietf-core-multipart-ct] Fossati, T., Hartke, K., and C. Bormann, "Multipart Content-Format for CoAP", draft-ietf-core-multipart-ct-04 (work in progress), August 2019. van der Stok, et al. Expires July 9, 2020 [Page 28] Internet-Draft EST-coaps January 2020 [I-D.ietf-lamps-rfc5751-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", draft-ietf-lamps-rfc5751-bis-12 (work in progress), September 2018. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-34 (work in progress), November 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, . [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . van der Stok, et al. Expires July 9, 2020 [Page 29] Internet-Draft EST-coaps January 2020 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, . [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, . [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 13.2. Informative References [BCP195] 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, May 2015, . [COREparams] "Constrained RESTful Environments (CoRE) Parameters", . van der Stok, et al. Expires July 9, 2020 [Page 30] Internet-Draft EST-coaps January 2020 [I-D.ietf-tls-dtls-connection-id] Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- id-07 (work in progress), October 2019. [I-D.josefsson-sasl-tls-cb] Josefsson, S., "Channel Bindings for TLS based on the PRF", draft-josefsson-sasl-tls-cb-03 (work in progress), March 2015. [I-D.moskowitz-ecdsa-pki] Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson, "Guide for building an ECC pki", draft-moskowitz-ecdsa- pki-07 (work in progress), August 2019. [ieee802.15.4] "IEEE Standard 802.15.4-2006", 2006. [ieee802.1ar] "IEEE 802.1AR Secure Device Identifier", December 2009. [PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", USENIX Security Symposium 2012 ISBN 978-931971-95-9, August 2012. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, . [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, . [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, . van der Stok, et al. Expires July 9, 2020 [Page 31] Internet-Draft EST-coaps January 2020 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [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, . [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, . [RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, . [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RSAfact] "Factoring RSA keys from certified smart cards: Coppersmith in the wild", Advances in Cryptology - ASIACRYPT 2013, August 2013. [tripleshake] "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", IEEE Security and Privacy ISBN 978-1-4799-4686-0, May 2014. Appendix A. EST messages to EST-coaps This section shows similar examples to the ones presented in Appendix A of [RFC7030]. The payloads in the examples are the hex encoded binary, generated with 'xxd -p', of the PKI certificates created following [I-D.moskowitz-ecdsa-pki]. Hex is used for visualization purposes because a binary representation cannot be rendered well in text. The hexadecimal representations would not be transported in hex, but in binary. The payloads are shown van der Stok, et al. Expires July 9, 2020 [Page 32] Internet-Draft EST-coaps January 2020 unencrypted. In practice the message content would be transferred over an encrypted DTLS channel. The certificate responses included in the examples contain Content- Format 281 (application/pkcs7). If the client had requested Content- Format TBD287 (application/pkix-cert) by querying /est/skc, the server would respond with a single DER binary certificate in the multipart-core container. These examples assume a short resource path of "/est". Even though omitted from the examples for brevity, before making the EST-coaps requests, a client would learn about the server supported EST-coaps resources with a GET request for /.well-known/core?rt=ace.est* as explained in Section 5.1. The corresponding CoAP headers are only shown in Appendix A.1. Creating CoAP headers is assumed to be generally understood. The message content breakdown is presented in Appendix C. A.1. cacerts In EST-coaps, a cacerts message can be: GET example.com:9085/est/crts (Accept: 281) The corresponding CoAP header fields are shown below. The use of block and DTLS are worked out in Appendix B. van der Stok, et al. Expires July 9, 2020 [Page 33] Internet-Draft EST-coaps January 2020 Ver = 1 T = 0 (CON) Code = 0x01 (0.01 is GET) Token = 0x9a (client generated) Options Option (Uri-Host) Option Delta = 0x3 (option# 3) Option Length = 0xB Option Value = "example.com" Option (Uri-Port) Option Delta = 0x4 (option# 3+4=7) Option Length = 0x2 Option Value = 9085 Option (Uri-Path) Option Delta = 0x4 (option# 7+4=11) Option Length = 0x3 Option Value = "est" Option (Uri-Path) Option Delta = 0x0 (option# 11+0=11) Option Length = 0x4 Option Value = "crts" Option (Accept) Option Delta = 0x6 (option# 11+6=17) Option Length = 0x2 Option Value = 281 Payload = [Empty] As specified in Section 5.10.1 of [RFC7252], the Uri-Host and Uri- Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. A 2.05 Content response with a cert in EST-coaps will then be 2.05 Content (Content-Format: 281) {payload with certificate in binary format} with CoAP fields van der Stok, et al. Expires July 9, 2020 [Page 34] Internet-Draft EST-coaps January 2020 Ver = 1 T = 2 (ACK) Code = 0x45 (2.05 Content) Token = 0x9a (copied from request by server) Options Option (Content-Format) Option Delta = 0xC (option# 12) Option Length = 0x2 Option Value = 281 [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] Payload = 3082027a06092a864886f70d010702a082026b308202670201013100300b 06092a864886f70d010701a082024d30820249308201efa0030201020208 0b8bb0fe604f6a1e300a06082a8648ce3d0403023067310b300906035504 0613025553310b300906035504080c024341310b300906035504070c024c 4131143012060355040a0c0b4578616d706c6520496e6331163014060355 040b0c0d63657274696669636174696f6e3110300e06035504030c07526f 6f74204341301e170d3139303133313131323730335a170d333930313236 3131323730335a3067310b3009060355040613025553310b300906035504 080c024341310b300906035504070c024c4131143012060355040a0c0b45 78616d706c6520496e6331163014060355040b0c0d636572746966696361 74696f6e3110300e06035504030c07526f6f742043413059301306072a86 48ce3d020106082a8648ce3d030107034200040c1b1e82ba8cc72680973f 97edb8a0c72ab0d405f05d4fe29b997a14ccce89008313d09666b6ce375c 595fcc8e37f8e4354497011be90e56794bd91ad951ab45a3818430818130 1d0603551d0e041604141df1208944d77b5f1d9dcb51ee244a523f3ef5de 301f0603551d230418301680141df1208944d77b5f1d9dcb51ee244a523f 3ef5de300f0603551d130101ff040530030101ff300e0603551d0f0101ff 040403020106301e0603551d110417301581136365727469667940657861 6d706c652e636f6d300a06082a8648ce3d040302034800304502202b891d d411d07a6d6f621947635ba4c43165296b3f633726f02e51ecf464bd4002 2100b4be8a80d08675f041fbc719acf3b39dedc85dc92b3035868cb2daa8 f05db196a1003100 The breakdown of the payload is shown in Appendix C.1. A.2. enroll / reenroll During the (re-)enroll exchange the EST-coaps client uses a CSR (Content-Format 286) request in the POST request payload. The Accept option tells the server that the client is expecting Content-Format 281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR contains a ChallengePassword which is used for PoP linking (Section 4). van der Stok, et al. Expires July 9, 2020 [Page 35] Internet-Draft EST-coaps January 2020 POST [2001:db8::2:321]:61616/est/sen (Token: 0x45) (Accept: 281) (Content-Format: 286) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 3082018b30820131020100305c310b3009060355040613025553310b3009 06035504080c024341310b300906035504070c024c413114301206035504 0a0c0b6578616d706c6520496e63310c300a060355040b0c03496f54310f 300d060355040513065774313233343059301306072a8648ce3d02010608 2a8648ce3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f 028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75 f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109 0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e 7634332323403d204e787e60303b06092a864886f70d01090e312e302c30 2a0603551d1104233021a01f06082b06010505070804a013301106092b06 010401b43b0a01040401020304300a06082a8648ce3d0403020348003045 02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc 1135a1e84eed754377 After verification of the CSR by the server, a 2.04 Changed response with the issued certificate will be returned to the client. van der Stok, et al. Expires July 9, 2020 [Page 36] Internet-Draft EST-coaps January 2020 2.04 Changed (Token: 0x45) (Content-Format: 281) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 3082026e06092a864886f70d010702a082025f3082025b0201013100300b 06092a864886f70d010701a08202413082023d308201e2a0030201020208 7e7661d7b54e4632300a06082a8648ce3d040302305d310b300906035504 0613025553310b300906035504080c02434131143012060355040a0c0b45 78616d706c6520496e6331163014060355040b0c0d636572746966696361 74696f6e3113301106035504030c0a3830322e3141522043413020170d31 39303133313131323931365a180f39393939313233313233353935395a30 5c310b3009060355040613025553310b300906035504080c024341310b30 0906035504070c024c4131143012060355040a0c0b6578616d706c652049 6e63310c300a060355040b0c03496f54310f300d06035504051306577431 3233343059301306072a8648ce3d020106082a8648ce3d03010703420004 c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50c ff958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b56 38e59fd9a3818a30818730090603551d1304023000301d0603551d0e0416 041496600d8716bf7fd0e752d0ac760777ad665d02a0301f0603551d2304 183016801468d16551f951bfc82a431d0d9f08bc2d205b1160300e060355 1d0f0101ff0404030205a0302a0603551d1104233021a01f06082b060105 05070804a013301106092b06010401b43b0a01040401020304300a06082a 8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94 91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d 832a4d336a08ad67df20f1506421188a0ade6d349236a1003100 The breakdown of the request and response is shown in Appendix C.2. A.3. serverkeygen In a serverkeygen exchange the CoAP POST request looks like van der Stok, et al. Expires July 9, 2020 [Page 37] Internet-Draft EST-coaps January 2020 POST 192.0.2.1:8085/est/skg (Token: 0xa5) (Accept: 62) (Content-Format: 286) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 3081d03078020100301631143012060355040a0c0b736b67206578616d70 6c653059301306072a8648ce3d020106082a8648ce3d03010703420004c8 b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50cff 958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b5638 e59fd9a000300a06082a8648ce3d040302034800304502207c553981b1fe 349249d8a3f50a0346336b7dfaa099cf74e1ec7a37a0a760485902210084 79295398774b2ff8e7e82abb0c17eaef344a5088fa69fd63ee611850c34b 0a The response would follow [I-D.ietf-core-multipart-ct] and could look like van der Stok, et al. Expires July 9, 2020 [Page 38] Internet-Draft EST-coaps January 2020 2.04 Changed (Token: 0xa5) (Content-Format: 62) [ The hexadecimal representations below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 84 # array(4) 19 011C # unsigned(284) 58 8A # bytes(138) 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7 679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc 494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95 cf75f602f9152618f816a2b23b5638e59fd9 19 0119 # unsigned(281) 59 01D3 # bytes(467) 308201cf06092a864886f70d010702a08201c0308201bc0201013100300b 06092a864886f70d010701a08201a23082019e30820144a0030201020209 00b3313e8f3fc9538e300a06082a8648ce3d040302301631143012060355 040a0c0b736b67206578616d706c65301e170d3139303930343037343430 335a170d3339303833303037343430335a301631143012060355040a0c0b 736b67206578616d706c653059301306072a8648ce3d020106082a8648ce 3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351 cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75f602f915 2618f816a2b23b5638e59fd9a37b307930090603551d1304023000302c06 096086480186f842010d041f161d4f70656e53534c2047656e6572617465 64204365727469666963617465301d0603551d0e0416041496600d8716bf 7fd0e752d0ac760777ad665d02a0301f0603551d2304183016801496600d 8716bf7fd0e752d0ac760777ad665d02a0300a06082a8648ce3d04030203 48003045022100e95bfa25a08976652246f2d96143da39fce0dc4c9b26b9 cce1f24164cc2b12b602201351fd8eea65764e3459d324e4345ff5b2a915 38c04976111796b3698bf6379ca1003100 The private key in the response above is without CMS EnvelopedData and has no additional encryption beyond DTLS (Section 5.8). The breakdown of the request and response is shown in Appendix C.3 A.4. csrattrs Below is a csrattrs exchange van der Stok, et al. Expires July 9, 2020 [Page 39] Internet-Draft EST-coaps January 2020 REQ: GET example.com:61616/est/att RES: 2.05 Content (Content-Format: 285) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] 307c06072b06010101011630220603883701311b131950617273652053455 420617320322e3939392e31206461746106092a864886f70d010907302c06 0388370231250603883703060388370413195061727365205345542061732 0322e3939392e32206461746106092b240303020801010b06096086480165 03040202 A 2.05 Content response should contain attributes which are relevant for the authenticated client. This example is copied from Section A.2 in [RFC7030], where the base64 representation is replaced with a hexadecimal representation of the equivalent binary format. The EST-coaps server returns attributes that the client can ignore if they are unknown to him. Appendix B. EST-coaps Block message examples Two examples are presented in this section: 1. a cacerts exchange shows the use of Block2 and the block headers 2. an enroll exchange shows the Block1 and Block2 size negotiation for request and response payloads. The payloads are shown unencrypted. In practice the message contents would be binary formatted and transferred over an encrypted DTLS tunnel. The corresponding CoAP headers are only shown in Appendix B.1. Creating CoAP headers is assumed to be generally known. B.1. cacerts This section provides a detailed example of the messages using DTLS and BLOCK option Block2. The example block length is taken as 64 which gives an SZX value of 2. The following is an example of a cacerts exchange over DTLS. The content length of the cacerts response in appendix A.1 of [RFC7030] contains 639 bytes in binary in this example. The CoAP message adds van der Stok, et al. Expires July 9, 2020 [Page 40] Internet-Draft EST-coaps January 2020 around 10 bytes in this exmple, the DTLS record around 29 bytes. To avoid IP fragmentation, the CoAP Block Option is used and an MTU of 127 is assumed to stay within one IEEE 802.15.4 packet. To stay below the MTU of 127, the payload is split in 9 packets with a payload of 64 bytes each, followed by a last tenth packet of 63 bytes. The client sends an IPv6 packet containing a UDP datagram with DTLS record protection that encapsulates a CoAP request 10 times (one fragment of the request per block). The server returns an IPv6 packet containing a UDP datagram with the DTLS record that encapsulates the CoAP response. The CoAP request-response exchange with block option is shown below. Block Option is shown in a decomposed way (block-option:NUM/M/size) indicating the kind of Block Option (2 in this case) followed by a colon, and then the block number (NUM), the more bit (M = 0 in Block2 response means it is last block), and block size with exponent (2**(SZX+4)) separated by slashes. The Length 64 is used with SZX=2. The CoAP Request is sent confirmable (CON) and the Content-Format of the response, even though not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). The transfer of the 10 blocks with partially filled block NUM=9 is shown below GET example.com:9085/est/crts (2:0/0/64) --> <-- (2:0/1/64) 2.05 Content GET example.com:9085/est/crts (2:1/0/64) --> <-- (2:1/1/64) 2.05 Content | | | GET example.com:9085/est/crts (2:9/0/64) --> <-- (2:9/0/64) 2.05 Content The header of the GET request looks like van der Stok, et al. Expires July 9, 2020 [Page 41] Internet-Draft EST-coaps January 2020 Ver = 1 T = 0 (CON) Code = 0x01 (0.1 GET) Token = 0x9a (client generated) Options Option (Uri-Host) Option Delta = 0x3 (option# 3) Option Length = 0xB Option Value = "example.com" Option (Uri-Port) Option Delta = 0x4 (option# 3+4=7) Option Length = 0x2 Option Value = 9085 Option (Uri-Path) Option Delta = 0x4 (option# 7+4=11) Option Length = 0x3 Option Value = "est" Option (Uri-Path)Uri-Path) Option Delta = 0x0 (option# 11+0=11) Option Length = 0x4 Option Value = "crts" Option (Accept) Option Delta = 0x6 (option# 11+6=17) Option Length = 0x2 Option Value = 281 Payload = [Empty] The Uri-Host and Uri-Port Options can be omitted if they coincide with the transport protocol destination address and port respectively. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers and uses the Options to route the requests accordingly. For further detailing the CoAP headers, the first two and the last blocks are written out below. The header of the first Block2 response looks like van der Stok, et al. Expires July 9, 2020 [Page 42] Internet-Draft EST-coaps January 2020 Ver = 1 T = 2 (ACK) Code = 0x45 (2.05 Content) Token = 0x9a (copied from request by server) Options Option Option Delta = 0xC (option# 12 Content-Format) Option Length = 0x2 Option Value = 281 Option Option Delta = 0xB (option# 12+11=23 Block2) Option Length = 0x1 Option Value = 0x0A (block#=0, M=1, SZX=2) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] Payload = 3082027b06092a864886f70d010702a082026c308202680201013100300b 06092a864886f70d010701a082024e3082024a308201f0a0030201020209 009189bc The second Block2: Ver = 1 T = 2 (means ACK) Code = 0x45 (2.05 Content) Token = 0x9a (copied from request by server) Options Option Option Delta = 0xC (option# 12 Content-Format) Option Length = 0x2 Option Value = 281 Option Option Delta = 0xB (option 12+11=23 Block2) Option Length = 0x1 Option Value = 0x1A (block#=1, M=1, SZX=2) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] Payload = df9c99244b300a06082a8648ce3d0403023067310b300906035504061302 5553310b300906035504080c024341310b300906035504070c024c413114 30120603 van der Stok, et al. Expires July 9, 2020 [Page 43] Internet-Draft EST-coaps January 2020 The 10th and final Block2: Ver = 1 T = 2 (means ACK) Code = 0x45 (2.05 Content) Token = 0x9a (copied from request by server) Options Option Option Delta = 0xC (option# 12 Content-Format) Option Length = 0x2 Option Value = 281 Option Option Delta = 0xB (option# 12+11=23 Block2 ) Option Length = 0x1 Option Value = 0x92 (block#=9, M=0, SZX=2) [ The hexadecimal representation below would NOT be transported in hex, but in binary. Hex is used because a binary representation cannot be rendered well in text. ] Payload = 2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1 003100 B.2. enroll / reenroll In this example, the requested Block2 size of 256 bytes, required by the client, is transferred to the server in the very first request message. The block size 256=(2**(SZX+4)) which gives SZX=4. The notation for block numbering is the same as in Appendix B.1. The header fields and the payload are omitted for brevity. van der Stok, et al. Expires July 9, 2020 [Page 44] Internet-Draft EST-coaps January 2020 POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> <-- (ACK) (1:0/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} --> <-- (ACK) (1:1/1/256) (2.31 Continue) . . . POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR(frag# N1+1)}--> | ...........Immediate response ......... | <-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp (frag# 1)} POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) --> <-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp (frag# 2)} . . . POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) --> <-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)} Figure 5: EST-COAP enrollment with multiple blocks N1+1 blocks have been transferred from client to the server and N2+1 blocks have been transferred from server to client. Appendix C. Message content breakdown This appendix presents the breakdown of the hexadecimal dumps of the binary payloads shown in Appendix A. C.1. cacerts The breakdown of cacerts response containing one root CA certificate is van der Stok, et al. Expires July 9, 2020 [Page 45] Internet-Draft EST-coaps January 2020 Certificate: Data: Version: 3 (0x2) Serial Number: 831953162763987486 (0xb8bb0fe604f6a1e) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, ST=CA, L=LA, O=Example Inc, OU=certification, CN=Root CA Validity Not Before: Jan 31 11:27:03 2019 GMT Not After : Jan 26 11:27:03 2039 GMT Subject: C=US, ST=CA, L=LA, O=Example Inc, OU=certification, CN=Root CA Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:0c:1b:1e:82:ba:8c:c7:26:80:97:3f:97:ed:b8: a0:c7:2a:b0:d4:05:f0:5d:4f:e2:9b:99:7a:14:cc: ce:89:00:83:13:d0:96:66:b6:ce:37:5c:59:5f:cc: 8e:37:f8:e4:35:44:97:01:1b:e9:0e:56:79:4b:d9: 1a:d9:51:ab:45 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: 1D:F1:20:89:44:D7:7B:5F:1D:9D:CB:51:EE:24:4A:52:3F:3E:F5:DE X509v3 Authority Key Identifier: keyid: 1D:F1:20:89:44:D7:7B:5F:1D:9D:CB:51:EE:24:4A:52:3F:3E:F5:DE X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Alternative Name: email:certify@example.com Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:2b:89:1d:d4:11:d0:7a:6d:6f:62:19:47:63:5b: a4:c4:31:65:29:6b:3f:63:37:26:f0:2e:51:ec:f4:64:bd:40: 02:21:00:b4:be:8a:80:d0:86:75:f0:41:fb:c7:19:ac:f3:b3: 9d:ed:c8:5d:c9:2b:30:35:86:8c:b2:da:a8:f0:5d:b1:96 C.2. enroll / reenroll The breakdown of the enrollment request is van der Stok, et al. Expires July 9, 2020 [Page 46] Internet-Draft EST-coaps January 2020 Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=CA, L=LA, O=example Inc, OU=IoT/serialNumber=Wt1234 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 56:38:e5:9f:d9 ASN1 OID: prime256v1 NIST CURVE: P-256 Attributes: challengePassword: <256-bit PoP linking value> Requested Extensions: X509v3 Subject Alternative Name: othername: Signature Algorithm: ecdsa-with-SHA256 30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd: 1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38: 92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b: c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77 The CSR contains a ChallengePassword which is used for PoP linking (Section 4). The CSR also contains an id-on-hardwareModuleName hardware identifier to customize the returned certificate to the requesting device (See [RFC7299] and [I-D.moskowitz-ecdsa-pki]). The breakdown of the issued certificate is van der Stok, et al. Expires July 9, 2020 [Page 47] Internet-Draft EST-coaps January 2020 Certificate: Data: Version: 3 (0x2) Serial Number: 9112578475118446130 (0x7e7661d7b54e4632) Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, ST=CA, O=Example Inc, OU=certification, CN=802.1AR CA Validity Not Before: Jan 31 11:29:16 2019 GMT Not After : Dec 31 23:59:59 9999 GMT Subject: C=US, ST=CA, L=LA, O=example Inc, OU=IoT/serialNumber=Wt1234 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 56:38:e5:9f:d9 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 X509v3 Authority Key Identifier: keyid: 68:D1:65:51:F9:51:BF:C8:2A:43:1D:0D:9F:08:BC:2D:20:5B:11:60 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Subject Alternative Name: othername: Signature Algorithm: ecdsa-with-SHA256 30:46:02:21:00:c0:d8:19:96:d2:50:7d:69:3f:3c:48:ea:a5: ee:94:91:bd:a6:db:21:40:99:d9:81:17:c6:3b:36:13:74:cd: 86:02:21:00:a7:74:98:9f:4c:32:1a:5c:f2:5d:83:2a:4d:33: 6a:08:ad:67:df:20:f1:50:64:21:18:8a:0a:de:6d:34:92:36 C.3. serverkeygen The following is the breakdown of the server-side key generation request. van der Stok, et al. Expires July 9, 2020 [Page 48] Internet-Draft EST-coaps January 2020 Certificate Request: Data: Version: 0 (0x0) Subject: O=skg example Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 56:38:e5:9f:d9 ASN1 OID: prime256v1 NIST CURVE: P-256 Attributes: a0:00 Signature Algorithm: ecdsa-with-SHA256 30:45:02:20:7c:55:39:81:b1:fe:34:92:49:d8:a3:f5:0a:03: 46:33:6b:7d:fa:a0:99:cf:74:e1:ec:7a:37:a0:a7:60:48:59: 02:21:00:84:79:29:53:98:77:4b:2f:f8:e7:e8:2a:bb:0c:17: ea:ef:34:4a:50:88:fa:69:fd:63:ee:61:18:50:c3:4b:0a Following is the breakdown of the private key content of the server- side key generation response. Private-Key: (256 bit) priv: 61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e: 6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f: 0c:37 pub: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 56:38:e5:9f:d9 ASN1 OID: prime256v1 NIST CURVE: P-256 The following is the breakdown of the certificate in the server-side key generation response payload. van der Stok, et al. Expires July 9, 2020 [Page 49] Internet-Draft EST-coaps January 2020 Certificate: Data: Version: 3 (0x2) Serial Number: b3:31:3e:8f:3f:c9:53:8e Signature Algorithm: ecdsa-with-SHA256 Issuer: O=skg example Validity Not Before: Sep 4 07:44:03 2019 GMT Not After : Aug 30 07:44:03 2039 GMT Subject: O=skg example Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: 56:38:e5:9f:d9 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 X509v3 Authority Key Identifier: keyid: 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0 Signature Algorithm: ecdsa-with-SHA256 30:45:02:21:00:e9:5b:fa:25:a0:89:76:65:22:46:f2:d9:61: 43:da:39:fc:e0:dc:4c:9b:26:b9:cc:e1:f2:41:64:cc:2b:12: b6:02:20:13:51:fd:8e:ea:65:76:4e:34:59:d3:24:e4:34:5f: f5:b2:a9:15:38:c0:49:76:11:17:96:b3:69:8b:f6:37:9c Authors' Addresses Peter van der Stok Consultant Email: consultancy@vanderstok.org van der Stok, et al. Expires July 9, 2020 [Page 50] Internet-Draft EST-coaps January 2020 Panos Kampanakis Cisco Systems Email: pkampana@cisco.com Michael C. Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/ Shahid Raza RISE SICS Isafjordsgatan 22 Kista, Stockholm 16440 SE Email: shahid@sics.se van der Stok, et al. Expires July 9, 2020 [Page 51] ./draft-ietf-clue-data-model-schema-17.txt0000644000764400076440000045012312753613400017561 0ustar iustyiusty CLUE Working Group R. Presta Internet-Draft S P. Romano Intended status: Standards Track University of Napoli Expires: February 14, 2017 August 13, 2016 An XML Schema for the CLUE data model draft-ietf-clue-data-model-schema-17 Abstract This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 14, 2017. 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 Presta & Romano Expires February 14, 2017 [Page 1] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. . . . . . . . . . . . . . . . . . . . . . . . 19 6. . . . . . . . . . . . . . . . . . . . . . . . 19 7. . . . . . . . . . . . . . . . . . . . . . . . 19 8. . . . . . . . . . . . . . . . . . . . . . . 19 9. . . . . . . . . . . . . . . . . . . . . . . . . 19 10. . . . . . . . . . . . . . . . . . . . . . . 19 11. . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. captureID attribute . . . . . . . . . . . . . . . . . . . 22 11.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 22 11.3. . . . . . . . . . . . . . . . . . . . 22 11.4. . . . . . . . . . . . . . . . . . . . . . 22 11.5. . . . . . . . . . . . . . . . . . . 23 11.5.1. . . . . . . . . . . . . . . . . . . . 24 11.5.2. . . . . . . . . . . . . . . . . . . . . 25 11.6. . . . . . . . . . . . . . . . . . 26 11.7. . . . . . . . . . . . . . . . . . . . . . . . . 26 11.8. . . . . . . . . . . . . . . . . . . . 26 11.9. . . . . . . . . . . . . . . . . . . . 27 11.10. . . . . . . . . . . . . . . . . . . . . . . . . 27 11.11. . . . . . . . . . . . . . . . . . . . . . . 28 11.12. . . . . . . . . . . . . . . . . . . . . . . 29 11.13. . . . . . . . . . . . . . . . . . . . . . . 29 11.14. . . . . . . . . . . . . . . . . . . . . . . . 29 11.15. . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.16. . . . . . . . . . . . . . . . . . . . . . . . 30 11.17. . . . . . . . . . . . . . . . . . . . . . . . 30 11.18. . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.19. . . . . . . . . . . . . . . . . . . . . . 31 11.20. . . . . . . . . . . . . . . . . . . . . . 31 11.21. . . . . . . . . . . . . . . . . . . . . 32 11.21.1. . . . . . . . . . . . . . . . . . . . . 32 12. Audio captures . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. . . . . . . . . . . . . . . . . . . 33 13. Video captures . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Text captures . . . . . . . . . . . . . . . . . . . . . . . . 34 15. Other capture types . . . . . . . . . . . . . . . . . . . . . 34 16. . . . . . . . . . . . . . . . . . . . . . . . . 35 16.1. . . . . . . . . . . . . . . . . . . . 36 16.2. . . . . . . . . . . . . . . . . . . . . . . 36 Presta & Romano Expires February 14, 2017 [Page 2] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 16.3. sceneID attribute . . . . . . . . . . . . . . . . . . . . 36 16.4. scale attribute . . . . . . . . . . . . . . . . . . . . . 36 17. . . . . . . . . . . . . . . . . . . . . . . . . . 37 17.1. . . . . . . . . . . . . . . . . . . . . 38 17.2. sceneViewID attribute . . . . . . . . . . . . . . . . . . 38 18. . . . . . . . . . . . . . . . . . . . . . . . 38 18.1. . . . . . . . . . . . . . . . . . . . 39 18.2. . . . . . . . . . . . . . . . . . . . . 39 18.3. encodingGroupID attribute . . . . . . . . . . . . . . . . 39 19. . . . . . . . . . . . . . . . . . . . . . . 39 19.1. setID attribute . . . . . . . . . . . . . . . . . . . . . 40 19.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 40 19.3. . . . . . . . . . . . . . . . . . . . 41 19.4. . . . . . . . . . . . . . . . . . . . . 41 19.5. . . . . . . . . . . . . . . . . . . . 41 20. . . . . . . . . . . . . . . . . . . . . . . . . . 41 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 21.1. . . . . . . . . . . . . . . . . . . . . . . . . 42 21.1.1. personID attribute . . . . . . . . . . . . . . . . . 42 21.1.2. . . . . . . . . . . . . . . . . . . . . 42 21.1.3. . . . . . . . . . . . . . . . . . . . . 43 22. . . . . . . . . . . . . . . . . . . . . . . 43 22.1. . . . . . . . . . . . . . . . . . . . . . . . 44 22.2. . . . . . . . . . . . . . . . . . . . . . . 44 22.3. . . . . . . . . . . . . . . . . . . . 44 23. . . . . . . . . . . . . . . . . . . . . . . . . . . 44 24. XML Schema extensibility . . . . . . . . . . . . . . . . . . . 45 24.1. Example of extension . . . . . . . . . . . . . . . . . . 46 25. Security considerations . . . . . . . . . . . . . . . . . . . 48 26. IANA considerations . . . . . . . . . . . . . . . . . . . . . 49 26.1. XML namespace registration . . . . . . . . . . . . . . . 49 26.2. XML Schema registration . . . . . . . . . . . . . . . . . 50 26.3. MIME Media Type Registration for "application/clue_info+xml" . . . . . . . . . . . . . . . 50 26.4. Registry for acceptable values . . . . . . . . . . 51 26.5. Registry for acceptable values . . . . . . 51 26.6. Registry for acceptable values . . 51 26.7. Registry for acceptable values . . . . . . . 52 27. Sample XML file . . . . . . . . . . . . . . . . . . . . . . . 52 28. MCC example . . . . . . . . . . . . . . . . . . . . . . . . . 60 29. Diff with draft-ietf-clue-data-model-schema-16 version . . . . 71 30. Diff with draft-ietf-clue-data-model-schema-15 version . . . . 71 31. Diff with draft-ietf-clue-data-model-schema-14 version . . . . 71 32. Diff with draft-ietf-clue-data-model-schema-13 version . . . . 71 33. Diff with draft-ietf-clue-data-model-schema-12 version . . . . 71 34. Diff with draft-ietf-clue-data-model-schema-11 version . . . . 71 35. Diff with draft-ietf-clue-data-model-schema-10 version . . . . 71 36. Diff with draft-ietf-clue-data-model-schema-09 version . . . . 72 Presta & Romano Expires February 14, 2017 [Page 3] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 37. Diff with draft-ietf-clue-data-model-schema-08 version . . . . 72 38. Diff with draft-ietf-clue-data-model-schema-07 version . . . . 72 39. Diff with draft-ietf-clue-data-model-schema-06 version . . . . 72 40. Diff with draft-ietf-clue-data-model-schema-04 version . . . . 73 41. Diff with draft-ietf-clue-data-model-schema-03 version . . . . 74 42. Diff with draft-ietf-clue-data-model-schema-02 version . . . . 74 43. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74 44. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 44.1. Normative References . . . . . . . . . . . . . . . . . . 74 44.2. Informative References . . . . . . . . . . . . . . . . . 76 Presta & Romano Expires February 14, 2017 [Page 4] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 1. Introduction This document provides an XML schema file for the definition of CLUE data model types. For the benefit of the reader, the term 'CLUE' stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. A thorough definition of the CLUE framework can be found in [I-D.ietf-clue-framework]. The schema is based on information contained in [I-D.ietf-clue-framework]. It encodes information and constraints defined in the aforementioned document in order to provide a formal representation of the concepts therein presented. The document aims at the definition of a coherent structure for information associated with the description of a telepresence scenario. Such information is used within the CLUE protocol messages ([I-D.ietf-clue-protocol]) enabling the dialogue between a Media Provider and a Media Consumer. CLUE protocol messages, indeed, are XML messages allowing (i) a Media Provider to advertise its telepresence capabilities in terms of media captures, capture scenes, and other features envisioned in the CLUE framework, according to the format herein defined and (ii) a Media Consumer to request the desired telepresence options in the form of capture encodings, represented as described in this document. 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]. 3. Definitions This document refers to the same definitions used in [I-D.ietf-clue-framework], except for the "CLUE Participant" definition. We briefly recall herein some of the main terms used in the document. Audio Capture: Media Capture for audio. Denoted as ACn in the examples in this document. Capture: Same as Media Capture. Capture Device: A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder. Presta & Romano Expires February 14, 2017 [Page 5] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Capture Encoding: A specific encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP. Capture Scene: A structure representing a spatial region captured by one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a Capture Scene MAY correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures. Capture Scene View: A list of Media Captures of the same media type that together form one way to represent the entire Capture Scene. CLUE Participant: This term is imported from the CLUE protocol ([I-D.ietf-clue-protocol]) document. Consumer: Short for Media Consumer. Encoding or Individual Encoding: A set of parameters representing a way to encode a Media Capture to become a Capture Encoding. Encoding Group: A set of encoding parameters representing a total media encoding capability to be sub-divided across potentially multiple Individual Encodings. Endpoint A CLUE-capable device which is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices which source and sink media streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. Media Capture: A source of Media, such as from one or more Capture Devices or constructed from other Media streams. Media Consumer: A CLUE-capable device that intends to receive Capture Encodings. Media Provider: A CLUE-capable device that intends to send Capture Encodings. Presta & Romano Expires February 14, 2017 [Page 6] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Multiple Content Capture: A Capture that mixes and/or switches other Captures of a single type (e.g., all audio or all video.) Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as MCCn in the example cases in this document. Multipoint Control Unit (MCU): A CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC7667]. An MCU includes an [RFC4353] like Mixer, without the [RFC4353] requirement to send media to each participant. Plane of Interest: The spatial plane containing the most relevant subject matter. Provider: Same as Media Provider. Render: The process of reproducing the received Streams like, for instance, displaying of the remote video on the Media Consumer's screens, or playing of the remote audio through loudspeakers. Scene: Same as Capture Scene. Simultaneous Transmission Set: A set of Media Captures that can be transmitted simultaneously from a Media Provider. Single Media Capture: A capture which contains media from a single source capture device, e.g., an audio capture from a single microphone, a video capture from a single camera. Spatial Relation: The arrangement in space of two objects, in contrast to relation in time or other relationships. Stream: A Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550]. Stream Characteristics: The union of the features used to describe a Stream in the CLUE environment and in the SIP-SDP environment. Video Capture: A Media Capture for video. 4. XML Schema This section contains the CLUE data model schema definition. The element and attribute definitions are formal representations of the concepts needed to describe the capabilities of a Media Provider and the streams that are requested by a Media Consumer given the Presta & Romano Expires February 14, 2017 [Page 7] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Media Provider's ADVERTISEMENT ([I-D.ietf-clue-protocol]). The main groups of information are: : the list of media captures available (Section 5) : the list of encoding groups (Section 6) : the list of capture scenes (Section 7) : the list of simultaneous transmission sets (Section 8) : the list of global views sets (Section 9) : meta data about the participants represented in the telepresence session (Section 21) : the list of instantiated capture encodings (Section 10) All of the above refers to concepts that have been introduced in [I-D.ietf-clue-framework] and further detailed in this document. Presta & Romano Expires February 14, 2017 [Page 8] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 9] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 10] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <personType> registry", accessible at TBD-IANA. Presta & Romano Expires February 14, 2017 [Page 11] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <view> registry", accessible at TBD-IANA. Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <presentation> registry", accessible at TBD-IANA. Presta & Romano Expires February 14, 2017 [Page 12] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 13] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema <sensitivityPattern> registry", accessible at TBD-IANA. Presta & Romano Expires February 14, 2017 [Page 14] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 15] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 16] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 17] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Following sections describe the XML schema in more detail. As a general remark, please notice that optional elements that don't define what their absence means are intended to be associated with undefined properties. Presta & Romano Expires February 14, 2017 [Page 18] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 5. represents the list of one or more media captures available at the Media Provider's side. Each media capture is represented by a element (Section 11). 6. represents the list of the encoding groups organized on the Media Provider's side. Each encoding group is represented by an element (Section 18). 7. represents the list of the capture scenes organized on the Media Provider's side. Each capture scene is represented by a element. (Section 16). 8. contains the simultaneous sets indicated by the Media Provider. Each simultaneous set is represented by a element. (Section 19). 9. contains a set of alternative representations of all the scenes that are offered by a Media Provider to a Media Consumer. Each alternative is named "global view" and it is represented by a element. (Section 20). 10. is a list of capture encodings. It can represent the list of the desired capture encodings indicated by the Media Consumer or the list of instantiated captures on the provider's side. Each capture encoding is represented by a element. (Section 22). 11. A Media Capture is the fundamental representation of a media flow that is available on the provider's side. Media captures are characterized (i) by a set of features that are independent from the specific type of medium, and (ii) by a set of features that are media-specific. The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type. Media-specific captures, such as video Presta & Romano Expires February 14, 2017 [Page 19] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 captures, audio captures and others, are specializations of that abstract media capture type, as in a typical generalization- specialization hierarchy. The following is the XML Schema definition of the media capture type: Presta & Romano Expires February 14, 2017 [Page 20] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Presta & Romano Expires February 14, 2017 [Page 21] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.1. captureID attribute The "captureID" attribute is a mandatory field containing the identifier of the media capture. Such an identifier serves as the way the capture is referenced from other data model elements (e.g., simultaneous sets, capture encodings, and others via ). 11.2. mediaType attribute The "mediaType" attribute is a mandatory attribute specifying the media type of the capture. Common standard values are "audio", "video", "text", as defined in [RFC6838]. Other values can be provided. It is assumed that implementations agree on the interpretation of those other values. The "mediaType" attribute is as generic as possible. Here is why: (i) the basic media capture type is an abstract one; (ii) "concrete" definitions for the standard ([RFC6838]) audio, video and text capture types have been specified; (iii) a generic "otherCaptureType" type has been defined; (iv) the "mediaType" attribute has been generically defined as a string, with no particular template. From the considerations above, it is clear that if one chooses to rely on a brand new media type and wants to interoperate with others, an application-level agreement is needed on how to interpret such information. 11.3. is a mandatory field containing the value of the identifier of the capture scene the media capture is defined in, i.e., the value of the sceneID (Section 16.3) attribute of that capture scene. Indeed, each media capture MUST be defined within one and only one capture scene. When a media capture is spatially definable, some spatial information is provided along with it in the form of point coordinates (see Section 11.5). Such coordinates refer to the space of coordinates defined for the capture scene containing the capture. 11.4. is an optional field containing the identifier of the encoding group the media capture is associated with, i.e., the value of the encodingGroupID (Section 18.3) attribute of that encoding group. Media captures that are not associated with any encoding group can not be instantiated as media streams. Presta & Romano Expires February 14, 2017 [Page 22] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.5. Media captures are divided into two categories: (i) non spatially definable captures and (ii) spatially definable captures. Captures are spatially definable when at least (i) it is possible to provide the coordinates of the device position within the telepresence room of origin (capture point) together with its capturing direction specified by a second point (point on line of capture), or (ii) it is possible to provide the represented area within the telepresence room, by listing the coordinates of the four co-planar points identifying the plane of interest (area of capture). The coordinates of the above mentioned points MUST be expressed according to the coordinate space of the capture scene the media captures belongs to. Non spatially definable captures cannot be characterized within the physical space of the telepresence room of origin. Captures of this kind are for example those related to recordings, text captures, DVDs, registered presentations, or external streams that are played in the telepresence room and transmitted to remote sites. Spatially definable captures represent a part of the telepresence room. The captured part of the telepresence room is described by means of the element. By comparing the element of different media captures within the same capture scene, a consumer can better determine the spatial relationships between them and render them correctly. Non spatially definable captures do not embed such element in their XML description: they are instead characterized by having the tag set to "true" (see Section 11.6). The definition of the spatial information type is the following: Presta & Romano Expires February 14, 2017 [Page 23] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 The contains the coordinates of the capture device that is taking the capture (i.e., the capture point), as well as, optionally, the pointing direction (i.e., the point on line of capture) (see Section 11.5.1). The is an optional field containing four points defining the captured area covered by the capture (see Section 11.5.2). The scale of the points coordinates is specified in the scale (Section 16.4) attribute of the capture scene the media capture belongs to. Indeed, all the spatially definable media captures referring to the same capture scene share the same coordinate system and express their spatial information according to the same scale. 11.5.1. The element is used to represent the position and optionally the line of capture of a capture device. MUST be included in spatially definable audio captures, while it is optional for spatially definable video captures. The XML Schema definition of the element type is the following: Presta & Romano Expires February 14, 2017 [Page 24] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 The point type contains three spatial coordinates (x,y,z) representing a point in the space associated with a certain capture scene. The element includes a mandatory element and an optional element, both of the type "pointType". specifies the three coordinates identifying the position of the capture device. is another pointType element representing the "point on line of capture", that gives the pointing direction of the capture device. The coordinates of the point on line of capture MUST NOT be identical to the capture point coordinates. For a spatially definable video capture, if the point on line of capture is provided, it MUST belong to the region between the point of capture and the capture area. For a spatially definable audio capture, if the point on line of capture is not provided, the sensitivity pattern should be considered omnidirectional. 11.5.2. is an optional element that can be contained within the spatial information associated with a media capture. It represents the spatial area captured by the media capture. MUST be included in the spatial information of spatially definable video captures, while it MUST NOT be associated with audio captures. The XML representation of that area is provided through a set of four point-type elements, , , , and that MUST be co-planar. The four coplanar points are identified from the perspective of the capture device. The XML schema definition is the following: Presta & Romano Expires February 14, 2017 [Page 25] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.6. When media captures are non spatially definable, they MUST be marked with the boolean element set to "true" and no MUST be provided. Indeed, and are mutually exclusive tags, according to the section within the XML Schema definition of the media capture type. 11.7. A media capture can be (i) an individual media capture or (ii) a multiple content capture (MCC). A multiple content capture is made by different captures that can be arranged spatially (by a composition operation), or temporally (by a switching operation), or that can result from the orchestration of both the techniques. If a media capture is an MCC, then it MAY show in its XML data model representation the element. It is composed by a list of media capture identifiers ("mediaCaptureIDREF") and capture scene view identifiers ("sceneViewIDREF"), where the latter ones are used as shortcuts to refer to multiple capture identifiers. The referenced captures are used to create the MCC according to a certain strategy. If the element does not appear in a MCC, or it has no child elements, then the MCC is assumed to be made of multiple sources but no information regarding those sources is provided. 11.8. is an optional element for multiple content captures that contains a numeric identifier. Multiple content captures marked with the same identifier in the Presta & Romano Expires February 14, 2017 [Page 26] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 contain at all times captures coming from the same sources. It is the Media Provider that determines what the source for the captures is. In this way, the Media Provider can choose how to group together single captures for the purpose of keeping them synchronized according to the element. 11.9. is an optional boolean element for multiple content captures. It indicates whether or not the Provider allows the Consumer to choose a specific subset of the captures referenced by the MCC. If this attribute is true, and the MCC references other captures, then the Consumer MAY specify in a CONFIGURE message a specific subset of those captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other captures, then the Consumer MUST NOT select a subset. If is not shown in the XML description of the MCC, its value is to be considered "false". 11.10. is an optional element that can be used only for multiple content captures. It indicates the criteria applied to build the multiple content capture using the media captures referenced in the list. The value is in the form of a token that indicates the policy and an index representing an instance of the policy, separated by a ":" (e.g., SoundLevel:2, RoundRobin:0, etc.). The XML schema defining the type of the element is the following: At the time of writing, only two switching policies are defined in [I-D.ietf-clue-framework]: SoundLevel: the content of the MCC is determined by a sound level detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC. Index 0 represents the most current instance of the policy, i.e., the currently active speaker, 1 represents the previous instance, Presta & Romano Expires February 14, 2017 [Page 27] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 i.e., the previous active speaker, and so on. RoundRobin: the content of the MCC is determined by a time based algorithm. Other values for the element can be used. In this case, it is assumed that implementations agree on the meaning of those other values and/or those new switching policies are defined in later documents. 11.11. is an optional element that can be used only for multiple content captures (MCC). It provides information about the number of media captures that can be represented in the multiple content capture at a time. If is not provided, all the media captures listed in the element can appear at a time in the capture encoding. The type definition is provided below. When the "exactNumber" attribute is set to "true", it means the element carries the exact number of the media captures appearing at a time. Otherwise, the number of the represented media captures MUST be considered "<=" the value. For instance, an audio MCC having the value set to 1 means that a media stream from the MCC will only contain audio from a single one of its constituent captures at a time. On the other hand, if the value is set to 4 and the exactNumber attribute Presta & Romano Expires February 14, 2017 [Page 28] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 is set to "true", it would mean that the media stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures. 11.12. is a boolean element that MUST be used for single- content captures. Its value is fixed and set to "true". Such element indicates the capture that is being described is not a multiple content capture. Indeed, and the aforementioned tags related to MCC attributes (from Section 11.7 to Section 11.11) are mutually exclusive, according to the section within the XML Schema definition of the media capture type. 11.13. is used to provide human-readable textual information. This element is included in the XML definition of media captures, capture scenes and capture scene views to the aim of providing human- readable description of, respectively, media captures, capture scenes and capture scene views. According to the data model definition of a media capture (Section 11)), zero or more elements can be used, each providing information in a different language. The element definition is the following: As can be seen, is a string element with an attribute ("lang") indicating the language used in the textual description. Such an attribute is compliant with the Language-Tag ABNF production from [RFC5646]. 11.14. is an optional unsigned integer field indicating the importance of a media capture according to the Media Provider's Presta & Romano Expires February 14, 2017 [Page 29] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 perspective. It can be used on the receiver's side to automatically identify the most relevant contribution from the Media Provider. The higher the importance, the lower the contained value. If no priority is assigned, no assumptions regarding relative importance of the media capture can be assumed. 11.15. is an optional element containing the language used in the capture. Zero or more elements can appear in the XML description of a media capture. Each such element has to be compliant with the Language-Tag ABNF production from [RFC5646]. 11.16. is an optional element indicating whether or not the capture device originating the capture may move during the telepresence session. That optional element can assume one of the three following values: static SHOULD NOT change for the duration of the CLUE session, across multiple ADVERTISEMENT messages. dynamic MAY change in each new ADVERTISEMENT message. Can be assumed to remain unchanged until there is a new ADVERTISEMENT message. highly-dynamic MAY change dynamically, even between consecutive ADVERTISEMENT messages. The spatial information provided in an ADVERTISEMENT message is simply a snapshot of the current values at the time when the message is sent. 11.17. The optional element contains the value of the captureID attribute (Section 11.1) of the media capture to which the considered media capture refers. The media capture marked with a element can be for example the translation of the referred media capture in a different language. 11.18. The element is an optional tag describing what is represented in the spatial area covered by a media capture. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Presta & Romano Expires February 14, 2017 [Page 30] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are: "room", "table", "lectern", "individual", and "audience". 11.19. The element is an optional tag used for media captures conveying information about presentations within the telepresence session. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are "slides" and "images". 11.20. The element is a boolean element indicating that there is text embedded in the media capture (e.g., in a video capture). The language used in such embedded textual description is reported in "lang" attribute. The XML Schema definition of the element is: Presta & Romano Expires February 14, 2017 [Page 31] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 11.21. This optional element is used to indicate which telepresence session participants are represented within the media captures. For each participant, a element is provided. 11.21.1. contains the identifier of the represented person, i.e., the value of the related personID attribute (Section 21.1.1). Metadata about the represented participant can be retrieved by accessing the list (Section 21). 12. Audio captures Audio captures inherit all the features of a generic media capture and present further audio-specific characteristics. The XML Schema definition of the audio capture type is reported below: Presta & Romano Expires February 14, 2017 [Page 32] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 An example of audio-specific information that can be included is represented by the element. (Section 12.1). 12.1. The element is an optional field describing the characteristics of the nominal sensitivity pattern of the microphone capturing the audio signal. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are "uni", "shotgun", "omni", "figure8", "cardioid" and "hyper-cardioid". 13. Video captures Video captures, similarly to audio captures, extend the information of a generic media capture with video-specific features. The XML Schema representation of the video capture type is provided in the following: Presta & Romano Expires February 14, 2017 [Page 33] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 14. Text captures Also text captures can be described by extending the generic media capture information, similarly to audio captures and video captures. There are no known properties of a text-based media which aren't already covered by the generic mediaCaptureType. Text captures are hence defined as follows: Text captures MUST be marked as non spatially definable (i.e., they MUST present in their XML description the (Section 11.6) element set to "true"). 15. Other capture types Other media capture types can be described by using the CLUE data model. They can be represented by exploiting the "otherCaptureType" type. This media capture type is conceived to be filled in with elements defined within extensions of the current schema, i.e., with elements defined in other XML schemas (see Section 24 for an example). The otherCaptureType inherits all the features envisioned for the abstract mediaCaptureType. The XML Schema representation of the otherCaptureType is the following: Presta & Romano Expires February 14, 2017 [Page 34] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 When defining new media capture types that are going to be described by means of the element, spatial properties of such new media capture types SHOULD be defined (e.g., whether or not they are spatially definable, whether or not they should be associated with an area of capture, or other properties that may be defined). 16. A Media Provider organizes the available captures in capture scenes in order to help the receiver both in the rendering and in the selection of the group of captures. Capture scenes are made of media captures and capture scene views, that are sets of media captures of the same media type. Each capture scene view is an alternative to represent completely a capture scene for a fixed media type. The XML Schema representation of a element is the following: Presta & Romano Expires February 14, 2017 [Page 35] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Each capture scene is identified by a "sceneID" attribute. The element can contain zero or more textual elements, defined as in Section 11.13. Besides , there is the optional element (Section 16.1), which contains structured information about the scene in the vcard format, and the optional element (Section 16.2), which is the list of the capture scene views. When no is provided, the capture scene is assumed to be made of all the media captures which contain the value of its sceneID attribute in their mandatory captureSceneIDREF attribute. 16.1. The element contains optional information about the capture scene according to the vcard format, as specified in the Xcard RFC [RFC6351]. 16.2. The element is a mandatory field of a capture scene containing the list of scene views. Each scene view is represented by a element (Section 17). 16.3. sceneID attribute The sceneID attribute is a mandatory attribute containing the identifier of the capture scene. 16.4. scale attribute The scale attribute is a mandatory attribute that specifies the scale of the coordinates provided in the spatial information of the media Presta & Romano Expires February 14, 2017 [Page 36] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 capture belonging to the considered capture scene. The scale attribute can assume three different values: "mm" - the scale is in millimeters. Systems which know their physical dimensions (for example professionally installed telepresence room systems) should always provide such real-world measurements. "unknown" - the scale is the same for every media capture in the capture scene but the unity of measure is undefined. Systems which are not aware of specific physical dimensions yet still know relative distances should select "unknown" in the scale attribute of the capture scene to be described. "noscale" - there is no common physical scale among the media captures of the capture scene. That means the scale could be different for each media capture. 17. A element represents a capture scene view, which contains a set of media captures of the same media type describing a capture scene. A element is characterized as follows. Presta & Romano Expires February 14, 2017 [Page 37] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 One or more optional elements provide human-readable information about what the scene view contains. is defined as already seen in Section 11.13. The remaining child elements are described in the following subsections. 17.1. The is the list of the identifiers of the media captures included in the scene view. It is an element of the captureIDListType type, which is defined as a sequence of , each containing the identifier of a media capture listed within the element: 17.2. sceneViewID attribute The sceneViewID attribute is a mandatory attribute containing the identifier of the capture scene view represented by the element. 18. The element represents an encoding group, which is made by a set of one or more individual encodings and some parameters that apply to the group as a whole. Encoding groups contain references to individual encodings that can be applied to media captures. The definition of the element is the following: Presta & Romano Expires February 14, 2017 [Page 38] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 In the following, the contained elements are further described. 18.1. is an optional field containing the maximum bitrate expressed in bits per second that can be shared by the individual encodings included in the encoding group. 18.2. is the list of the individual encodings grouped together in the encoding group. Each individual encoding is represented through its identifier contained within an element. 18.3. encodingGroupID attribute The encodingGroupID attribute contains the identifier of the encoding group. 19. represents a simultaneous transmission set, i.e., a list of captures of the same media type that can be transmitted at the same time by a Media Provider. There are different simultaneous Presta & Romano Expires February 14, 2017 [Page 39] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 transmission sets for each media type. Besides the identifiers of the captures ( elements), also the identifiers of capture scene views and of capture scene can be exploited as shortcuts ( and elements). As an example, let's consider the situation where there are two capture scene views (S1 and S7). S1 contains captures AC11, AC12, AC13. S7 contains captures AC71, AC72. Provided that AC11, AC12, AC13, AC71, AC72 can be simultaneously sent to the media consumer, instead of having 5 elements listed in the simultaneous set (i.e., one for AC11, one for AC12, and so on), there can be just two elements (one for S1 and one for S7). 19.1. setID attribute The "setID" attribute is a mandatory field containing the identifier of the simultaneous set. 19.2. mediaType attribute The "mediaType" attribute is an optional attribute containing the media type of the captures referenced by the simultaneous set. When only capture scene identifiers are listed within a simultaneous set, the media type attribute MUST appear in the XML description in order to determine which media captures can be simultaneously sent together. Presta & Romano Expires February 14, 2017 [Page 40] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 19.3. contains the identifier of the media capture that belongs to the simultaneous set. 19.4. contains the identifier of the scene view containing a group of captures that are able to be sent simultaneously with the other captures of the simultaneous set. 19.5. contains the identifier of the capture scene where all the included captures of a certain media type are able to be sent together with the other captures of the simultaneous set. 20. is a set of captures of the same media type representing a summary of the complete Media Provider's offer. The content of a global view is expressed by leveraging only scene view identifiers, put within elements. Each global view is identified by a unique identifier within the "globalViewID" attribute. 21. Information about the participants that are represented in the media captures is conveyed via the element. As it can be seen from the XML Schema depicted below, for each participant, a element is provided. Presta & Romano Expires February 14, 2017 [Page 41] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 21.1. includes all the metadata related to a person represented within one or more media captures. Such element provides the vcard of the subject (via the element, see Section 21.1.2) and his conference role(s) (via one or more elements, see Section 21.1.3). Furthermore, it has a mandatory "personID" attribute (Section 21.1.1). 21.1.1. personID attribute The "personID" attribute carries the identifier of a represented person. Such an identifier can be used to refer to the participant, as in the element in the media captures representation (Section 11.21). 21.1.2. The element is the XML representation of all the fields composing a vcard as specified in the Xcard RFC [RFC6351]. The vcardType is imported by the Xcard XML Schema provided in Appendix A of [I-D.ietf-ecrit-additional-data]. As such schema specifies, the element within is mandatory. Presta & Romano Expires February 14, 2017 [Page 42] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 21.1.3. The value of the element determines the role of the represented participant within the telepresence session organization. It has been specified as a simple string with an annotation pointing to an ad hoc defined IANA registry: Acceptable values (enumerations) for this type are managed by IANA in the "CLUE Schema registry", accessible at TBD-IANA. The current possible values, as per the CLUE framework document [I-D.ietf-clue-framework], are: "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice- chairman", "observer". A participant can play more than one conference role. In that case, more than one element will appear in his description. 22. A capture encoding is given from the association of a media capture with an individual encoding, to form a capture stream as defined in [I-D.ietf-clue-framework]. Capture encodings are used within CONFIGURE messages from a Media Consumer to a Media Provider for representing the streams desired by the Media Consumer. For each desired stream, the Media Consumer needs to be allowed to specify: (i) the capture identifier of the desired capture that has been advertised by the Media Provider; (ii) the encoding identifier of the encoding to use, among those advertised by the Media Provider; (iii) optionally, in case of multi-content captures, the list of the capture identifiers of the desired captures. All the mentioned identifiers are intended to be included in the ADVERTISEMENT message that the CONFIGURE message refers to. The XML model of is provided in the following. Presta & Romano Expires February 14, 2017 [Page 43] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 22.1. is the mandatory element containing the identifier of the media capture that has been encoded to form the capture encoding. 22.2. is the mandatory element containing the identifier of the applied individual encoding. 22.3. is an optional element to be used in case of configuration of MCC. It contains the list of capture identifiers and capture scene view identifiers the Media Consumer wants within the MCC. That element is structured as the element used to describe the content of an MCC. The total number of media captures listed in the MUST be lower than or equal to the value carried within the attribute of the MCC. 23. The element includes all the information needed to represent the Media Provider's description of its telepresence capabilities according to the CLUE framework. Indeed, it is made by: the list of the available media captures ( (Section 5)) the list of encoding groups ( (Section 6)) Presta & Romano Expires February 14, 2017 [Page 44] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 the list of capture scenes ( (Section 7)) the list of simultaneous transmission sets ( (Section 8)) the list of global views sets ( (Section 9)) meta data about the participants represented in the telepresence session ( (Section 21)) It has been conceived only for data model testing purposes and, though it resembles the body of an ADVERTISEMENT message, it is not actually used in the CLUE protocol message definitions. The telepresence capabilities descriptions compliant to this data model specification that can be found in Section 27 and Section 28 are provided by using the element. 24. XML Schema extensibility The telepresence data model defined in this document is meant to be extensible. Extensions are accomplished by defining elements or attributes qualified by namespaces other than "urn:ietf:params:xml:ns:clue-info" and "urn:ietf:params:xml:ns:vcard-4.0" for use wherever the schema allows such extensions (i.e., where the XML Schema definition specifies "anyAttribute" or "anyElement"). Elements or attributes from unknown namespaces MUST be ignored. Extensibility was purposefully favored as much as possible based on expectations about custom Presta & Romano Expires February 14, 2017 [Page 45] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 implementations. Hence, the schema offers people enough flexibility as to define custom extensions, without losing compliance with the standard. This is achieved by leveraging elements and attributes, which is a common approach with schemas, still matching the UPA (Unique Particle Attribution) constraint. 24.1. Example of extension When extending the CLUE data model, a new schema with a new namespace associated with it needs to be specified. In the following, an example of extension is provided. The extension defines a new audio capture attribute ("newAudioFeature") and an attribute for characterizing the captures belonging to an "otherCaptureType" defined by the user. An XML document compliant with the extension is also included. The XML file results validated against the current CLUE data model schema. Presta & Romano Expires February 14, 2017 [Page 46] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 CS1 true true EG1 newAudioFeatureValue CS1 true EG1 OtherValue 300000 ENC4 ENC5 Presta & Romano Expires February 14, 2017 [Page 47] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 25. Security considerations This document defines an XML Schema data model for telepresence scenarios. The modeled information is identified in the CLUE framework as necessary in order to enable a full-fledged media stream negotiation and rendering. Indeed, the XML elements herein defined are used within CLUE protocol messages to describe both the media streams representing the Media Provider's telepresence offer and the desired selection requested by the Media Consumer. Security concerns described in [I-D.ietf-clue-framework], Section 15, apply to this document. Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints. Indeed, authenticated access is strongly advisable, especially if you convey information about individuals () and/or scenes (). There might be more exceptions, depending on the level of criticality that is associated with the setup and configuration of a specific session. In principle, one might even decide that no protection at all is needed for a particular session; here is why authentication has not been identified as a mandatory requirement. Going deeper into details, some information published by the Media Provider might reveal sensitive data about who and what is represented in the transmitted streams. The vCard included in the elements (Section 21.1) mandatorily contains the identity of the represented person. Optionally vCards can also carry the person's contact addresses, together with his/her photo and other personal data. Similar privacy-critical information can be conveyed by means of elements (Section 16.1) describing the capture scenes. The elements (Section 11.13) also can specify details about the content of media captures, capture scenes and scene views that should be protected. Integrity attacks to the data model information encapsulated in CLUE messages can invalidate the success of the telepresence session's setup by misleading the Media Consumer's and Media Provider's interpretation of the offered and desired media streams. The assurance of the authenticated access and of the integrity of the data model information is up to the involved transport mechanisms, namely the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel]. XML parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the XML Presta & Romano Expires February 14, 2017 [Page 48] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 parser. In an extreme situation, the entire machine could be compromised. 26. IANA considerations This document registers a new XML namespace, a new XML schema, the MIME type for the schema and four new registries associated, respectively, with acceptable , , and values. 26.1. XML namespace registration URI: urn:ietf:params:xml:ns:clue-info Registrant Contact: IETF CLUE Working Group , Roberta Presta XML: BEGIN CLUE Data Model Namespace

Namespace for CLUE Data Model

urn:ietf:params:xml:ns:clue-info

See RFC XXXX.

END Presta & Romano Expires February 14, 2017 [Page 49] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 26.2. XML Schema registration This section registers an XML schema per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:clue-info Registrant Contact: CLUE working group (clue@ietf.org), Roberta Presta (roberta.presta@unina.it). Schema: The XML for this schema can be found as the entirety of Section 4 of this document. 26.3. MIME Media Type Registration for "application/clue_info+xml" This section registers the "application/clue_info+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/clue_info+xml MIME media type name: application MIME subtype name: clue_info+xml Required parameters: (none) Optional parameters: charset Same as the charset parameter of "application/xml" as specified in [RFC7303], Section 3.2. Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC7303], Section 3.2. Security considerations: This content type is designed to carry data related to telepresence information. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section 25 are required to protect the data. This media type does not contain executable content. Interoperability considerations: None. Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications that use this media type: CLUE-capable telepresence systems. Presta & Romano Expires February 14, 2017 [Page 50] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Additional Information: Magic Number(s): (none), File extension(s): .clue, Macintosh File Type Code(s): TEXT. Person & email address to contact for further information: Roberta Presta (roberta.presta@unina.it). Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC7303], and many of the considerations described there also apply to application/clue_info+xml. 26.4. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 11.18. The initial values for this registry are "room", "table", "lectern", "individual", and "audience". New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 11.18, marked as "TBD-IANA". 26.5. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 11.19. The initial values for this registry are "slides" and "images". New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 11.19, marked as "TBD-IANA". 26.6. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 12.1. The initial values for this registry are "uni", "shotgun", "omni", "figure8", "cardioid" and "hyper-cardioid". Presta & Romano Expires February 14, 2017 [Page 51] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 12.1, marked as "TBD-IANA". 26.7. Registry for acceptable values IANA is requested to create a registry of acceptable values for the the tag as defined in Section 21.1.3. The initial values for this registry are "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman", "observer". New values are assigned by Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. IANA is further requested to update this draft with the URL to the new registry in Section 21.1.3, marked as "TBD-IANA". 27. Sample XML file The following XML document represents a schema compliant example of a CLUE telepresence scenario. Taking inspiration from the examples described in the framework draft ([I-D.ietf-clue-framework]), it is provided the XML representation of an endpoint-style Media Provider's ADVERTISEMENT. There are three cameras, where the central one is also capable of capturing a zoomed-out view of the overall telepresence room. Besides the three video captures coming from the cameras, the Media Provider makes available a further multi-content capture of the loudest segment of the room, obtained by switching the video source across the three cameras. For the sake of simplicity, only one audio capture is advertised for the audio of the whole room. The three cameras are placed in front of three participants (Alice, Bob and Ciccio), whose vcard and conference role details are also provided. Media captures are arranged into four capture scene views: 1. (VC0, VC1, VC2) - left, center and right camera video captures 2. (VC3) - video capture associated with loudest room segment Presta & Romano Expires February 14, 2017 [Page 52] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 3. (VC4) - video capture zoomed out view of all people in the room 4. (AC0) - main audio There are two encoding groups: (i) EG0, for video encodings, and (ii) EG1, for audio encodings. As to the simultaneous sets, VC1 and VC4 cannot be transmitted simultaneously since they are captured by the same device, i.e., the central camera (VC4 is a zoomed-out view while VC1 is a focused view of the front participant). On the other hand, VC3 and VC4 cannot be simultaneous either, since VC3, the loudest segment of the room, might be at a certain point in time focusing on the central part of the room, i.e., the same as VC1. The simultaneous sets would then be the following: SS1 made by VC3 and all the captures in the first capture scene view (VC0,VC1,VC2); SS2 made by VC0, VC2, VC4 CS1 0.0 0.0 10.0 0.0 1.0 10.0 true Presta & Romano Expires February 14, 2017 [Page 53] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 EG1 main audio from the room 1 it static room alice bob ciccio CS1 -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 -1.0 20.0 11.0 Presta & Romano Expires February 14, 2017 [Page 54] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true Presta & Romano Expires February 14, 2017 [Page 55] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 Presta & Romano Expires February 14, 2017 [Page 56] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual Presta & Romano Expires February 14, 2017 [Page 57] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed out view of all people in the room 2 it static room alice bob ciccio Presta & Romano Expires February 14, 2017 [Page 58] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 VC0 VC1 VC2 VC3 VC4 AC0 Presta & Romano Expires February 14, 2017 [Page 59] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 VC3 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper 28. MCC example Enhancing the scenario presented in the previous example, the Media Provider is able to advertise a composed capture VC7 made by a big picture representing the current speaker (VC3) and two picture-in- picture boxes representing the previous speakers (the previous one Presta & Romano Expires February 14, 2017 [Page 60] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 -VC5- and the oldest one -VC6). The provider does not want to instantiate and send VC5 and VC6, so it does not associate any encoding group with them. Their XML representations are provided for enabling the description of VC7. A possible description for that scenario could be the following: CS1 0.0 0.0 10.0 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio Presta & Romano Expires February 14, 2017 [Page 61] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 CS1 0.5 1.0 0.5 0.5 0.0 0.5 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 Presta & Romano Expires February 14, 2017 [Page 62] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 Presta & Romano Expires February 14, 2017 [Page 63] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 Presta & Romano Expires February 14, 2017 [Page 64] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 Presta & Romano Expires February 14, 2017 [Page 65] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 true EG0 zoomed out view of all people in the room 2 it static room alice bob ciccio CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 Presta & Romano Expires February 14, 2017 [Page 66] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 SoundLevel:1 penultimate loudest room segment it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:2 last but two loudest room segment it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC3 VC5 VC6 3 EG0 big picture of the current speaker + pips about previous speakers 3 it static individual 600000 ENC1 ENC2 ENC3 Presta & Romano Expires February 14, 2017 [Page 68] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 300000 ENC4 ENC5 participants' individual videos VC0 VC1 VC2 loudest segment of the room VC3 loudest segment of the room + pips VC7 room audio AC0 room video VC4 Presta & Romano Expires February 14, 2017 [Page 69] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 VC3 VC7 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper Presta & Romano Expires February 14, 2017 [Page 70] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 29. Diff with draft-ietf-clue-data-model-schema-16 version As per Alexey Melnikov's and Stefan Winter's comments: replaced wrong references to RFC2119 in section 11.3 and section 11.5. The updated reference is to RFC5646. 30. Diff with draft-ietf-clue-data-model-schema-15 version Applied modifications as per the following reviews: (i) Alexey Melnikov's discuss and comments (abstract amendments, typo corrections, insertion of references, etc.); (ii) Kathleen Moriarty's discuss and comments (amendments to the Security Considerations section); (iii) Stefan Winter's OPS-DIR review (use of enumerated types in the schema). 31. Diff with draft-ietf-clue-data-model-schema-14 version Applied modifications as per the following reviews: (i) Henry S. Thompson's APPS-DIR review; (ii) Stefan Winter's OPS-DIR review; (iii) Francis Dupont's GEN-ART review; (iv) Rich Salz's review (as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.) 32. Diff with draft-ietf-clue-data-model-schema-13 version Applied modifications as per the latest Area Director (Alissa Cooper's) review comments. 33. Diff with draft-ietf-clue-data-model-schema-12 version Removed some typos and inconsistencies. Applied modifications as per Alissa Cooper's review comments. 34. Diff with draft-ietf-clue-data-model-schema-11 version Applied modifications as per Mark Duckworth's review (example corrections and maxCapturesType modification) maxCapturesType has been changed from positiveInteger to unsignedShort excluding value 0. 35. Diff with draft-ietf-clue-data-model-schema-10 version Minor modifications have been applied to address nits at page https:/ /www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/ draft-ietf-clue-data-model-schema-10.txt. Presta & Romano Expires February 14, 2017 [Page 71] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 36. Diff with draft-ietf-clue-data-model-schema-09 version o We have introduced a element containing a mandatory and an optional in the definition of as per Paul's review o A new type definition for switching policies (resembled by element) has been provided in order to have acceptable values in the form of "token:index". o Minor modifications suggested in WGLC reviews have been applied. 37. Diff with draft-ietf-clue-data-model-schema-08 version o Typos correction 38. Diff with draft-ietf-clue-data-model-schema-07 version o IANA Considerations: text added o maxCaptureEncodings removed o personTypeType values aligned with CLUE framework o allowSubsetChoice added for multiple content captures o embeddedText moved from videoCaptureType definition to mediaCaptureType definition o typos removed from section Terminology 39. Diff with draft-ietf-clue-data-model-schema-06 version o Capture Scene Entry/Entries renamed as Capture Scene View/Views in the text, / renamed as / in the XML schema. o Global Scene Entry/Entries renamed as Global View/Views in the text, / renamed as / o Security section added. o Extensibility: a new type is introduced to describe other types of media capture (otherCaptureType), text and example added. o Spatial information section updated: capture point optional, text now is coherent with the framework one. Presta & Romano Expires February 14, 2017 [Page 72] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 o Audio capture description: added, removed, disallowed. o Simultaneous set definition: added to refer to capture scene identifiers as shortcuts and an optional mediaType attribute which is mandatory to use when only capture scene identifiers are listed. o Encoding groups: removed the constraint of the same media type. o Updated text about media captures without (optional in the XML schema). o "mediaType" attribute removed from homogeneous groups of capture (scene views and globlal views) o "mediaType" attribute removed from the global view textual description. o "millimeters" scale value changed in "mm" 40. Diff with draft-ietf-clue-data-model-schema-04 version globalCaptureEntries/Entry renamed as globalSceneEntries/Entry; sceneInformation added; Only capture scene entry identifiers listed within global scene entries (media capture identifiers removed); renamed as in the >clueInfo< template renamed as to synch with the framework terminology renamed as to synch with the framework terminology renamed as in the media capture type definition to remove ambiguity Examples have been updated with the new definitions of and of . Presta & Romano Expires February 14, 2017 [Page 73] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 41. Diff with draft-ietf-clue-data-model-schema-03 version encodings section has been removed global capture entries have been introduced capture scene entry identifiers are used as shortcuts in listing the content of MCC (similarly to simultaneous set and global capture entries) Examples have been updated. A new example with global capture entries has been added. has been made optional. has been renamed into Obsolete comments have been removed. participants information has been added. 42. Diff with draft-ietf-clue-data-model-schema-02 version captureParameters and encodingParameters have been removed from the captureEncodingType data model example has been updated and validated according to the new schema. Further description of the represented scenario has been provided. A multiple content capture example has been added. Obsolete comments and references have been removed. 43. Acknowledgments The authors thank all the CLUErs for their precious feedbacks and support. Thanks also to Alissa Cooper, whose AD reviews helped us improve the quality of the document. 44. References 44.1. Normative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf-clue-datachannel-14 (work in progress), August 2016. Presta & Romano Expires February 14, 2017 [Page 74] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-25 (work in progress), January 2016. [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft-ietf-clue-protocol-08 (work in progress), May 2016. [I-D.ietf-ecrit-additional-data] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", draft-ietf-ecrit-additional-data-38 (work in progress), April 2016. [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>. [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, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, . [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, . 44.2. Informative References [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/ RFC6838, January 2013, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Presta & Romano Expires February 14, 2017 [Page 76] Internet-Draft draft-ietf-clue-data-model-schema-17 August 2016 Authors' Addresses Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: roberta.presta@unina.it Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it Presta & Romano Expires February 14, 2017 [Page 77] ./draft-ietf-anima-autonomic-control-plane-30.txt0000644000764400076440000160431513747056702021234 0ustar iustyiusty ANIMA WG T. Eckert, Ed. Internet-Draft Futurewei USA Intended status: Standards Track M. Behringer, Ed. Expires: 3 May 2021 S. Bjarnason Arbor Networks 30 October 2020 An Autonomic Control Plane (ACP) draft-ietf-anima-autonomic-control-plane-30 Abstract Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 May 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Eckert, et al. Expires 3 May 2021 [Page 1] Internet-Draft An Autonomic Control Plane (ACP) October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 (Informative) . . . . . . . . . . . . . . . . . 6 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 11 3. Use Cases for an Autonomic Control Plane (Informative) . . . 16 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 17 3.2. Secure Bootstrap over a not configured Network . . . . . 17 3.3. Data-Plane Independent Permanent Reachability . . . . . . 17 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 19 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 20 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Requirements for use of Transport Layer Security (TLS) . 22 6.2. ACP Domain, Certificate and Network . . . . . . . . . . . 23 6.2.1. ACP Certificates . . . . . . . . . . . . . . . . . . 24 6.2.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 26 6.2.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 29 6.2.3. ACP domain membership check . . . . . . . . . . . . . 30 6.2.3.1. Realtime clock and Time Validation . . . . . . . 33 6.2.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 33 6.2.5. Certificate and Trust Anchor Maintenance . . . . . . 34 6.2.5.1. GRASP objective for EST server . . . . . . . . . 35 6.2.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 37 6.2.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 37 6.2.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 38 6.2.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 38 6.2.5.6. Failing Certificates . . . . . . . . . . . . . . 40 6.3. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 41 6.4. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 41 6.5. Candidate ACP Neighbor Selection . . . . . . . . . . . . 45 6.6. Channel Selection . . . . . . . . . . . . . . . . . . . . 45 6.7. Candidate ACP Neighbor verification . . . . . . . . . . . 49 6.8. Security Association (Secure Channel) protocols . . . . . 49 6.8.1. General considerations . . . . . . . . . . . . . . . 50 6.8.2. Common requirements . . . . . . . . . . . . . . . . . 51 6.8.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 52 6.8.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 52 6.8.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 53 Eckert, et al. Expires 3 May 2021 [Page 2] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.8.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 54 6.8.3.2. IPsec with GRE encapsulation . . . . . . . . . . 55 6.8.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 56 6.8.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 58 6.9. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 59 6.9.1. GRASP as a core service of the ACP . . . . . . . . . 59 6.9.2. ACP as the Security and Transport substrate for GRASP . . . . . . . . . . . . . . . . . . . . . . . . 59 6.9.2.1. Discussion . . . . . . . . . . . . . . . . . . . 62 6.10. Context Separation . . . . . . . . . . . . . . . . . . . 63 6.11. Addressing inside the ACP . . . . . . . . . . . . . . . . 63 6.11.1. Fundamental Concepts of Autonomic Addressing . . . . 63 6.11.2. The ACP Addressing Base Scheme . . . . . . . . . . . 65 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 67 6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 68 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ ACP-VLong-16 . . . . . . . . . . . . . . . . . . . . 69 6.11.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 70 6.11.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 71 6.11.7.1. Use of BRSKI or other Mechanism/Protocols . . . 71 6.11.7.2. Unique Address/Prefix allocation . . . . . . . . 72 6.11.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 72 6.11.7.4. Address/Prefix Persistence . . . . . . . . . . . 74 6.11.7.5. Further Details . . . . . . . . . . . . . . . . 74 6.12. Routing in the ACP . . . . . . . . . . . . . . . . . . . 74 6.12.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 75 6.12.1.1. Overview . . . . . . . . . . . . . . . . . . . . 75 6.12.1.1.1. Single Instance . . . . . . . . . . . . . . 75 6.12.1.1.2. Reconvergence . . . . . . . . . . . . . . . 76 6.12.1.2. RPL Instances . . . . . . . . . . . . . . . . . 77 6.12.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 77 6.12.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 77 6.12.1.5. Path Metric . . . . . . . . . . . . . . . . . . 77 6.12.1.6. Objective Function . . . . . . . . . . . . . . . 77 6.12.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 77 6.12.1.8. Multicast . . . . . . . . . . . . . . . . . . . 78 6.12.1.9. Security . . . . . . . . . . . . . . . . . . . . 78 6.12.1.10. P2P communications . . . . . . . . . . . . . . . 78 6.12.1.11. IPv6 address configuration . . . . . . . . . . . 78 6.12.1.12. Administrative parameters . . . . . . . . . . . 79 6.12.1.13. RPL Packet Information . . . . . . . . . . . . . 79 6.12.1.14. Unknown Destinations . . . . . . . . . . . . . . 79 6.13. General ACP Considerations . . . . . . . . . . . . . . . 80 6.13.1. Performance . . . . . . . . . . . . . . . . . . . . 80 6.13.2. Addressing of Secure Channels . . . . . . . . . . . 80 6.13.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 81 6.13.4. Multiple links between nodes . . . . . . . . . . . . 81 6.13.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 82 Eckert, et al. Expires 3 May 2021 [Page 3] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.13.5.1. ACP loopback interfaces . . . . . . . . . . . . 82 6.13.5.2. ACP virtual interfaces . . . . . . . . . . . . . 84 6.13.5.2.1. ACP point-to-point virtual interfaces . . . 84 6.13.5.2.2. ACP multi-access virtual interfaces . . . . 84 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 87 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 87 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 88 8. Support for Non-ACP Components (Normative) . . . . . . . . . 89 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 89 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 90 8.1.2. Software Components . . . . . . . . . . . . . . . . . 92 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 93 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 94 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 96 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP neighbors) . . . . . . . . . . . . . . . . . . . . . . . 97 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 97 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 98 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 98 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 99 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 99 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 103 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 104 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 104 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 105 9.2.3. Certificate renewal and limitations . . . . . . . . . 106 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 107 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 107 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 108 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 108 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 109 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 110 9.3.2.2. Fast state propagation and Diagnostics . . . . . 110 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 111 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 112 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 112 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 112 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 114 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 114 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 115 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 116 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 117 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 117 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 118 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 119 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 119 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 121 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 121 Eckert, et al. Expires 3 May 2021 [Page 4] Internet-Draft An Autonomic Control Plane (ACP) October 2020 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 122 10.3. The Administrator View . . . . . . . . . . . . . . . . . 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 124 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 129 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 130 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 130 15. Change log [RFC-Editor: Please remove] . . . . . . . . . . . 131 15.1. Summary of changes since entering IESG review . . . . . 131 15.1.1. Reviews (while in IESG review status) / status . . . 131 15.1.2. BRSKI / ACP registrar related enhancements . . . . . 132 15.1.3. Normative enhancements since start of IESG review . 132 15.1.4. Explanatory enhancements since start of IESG review . . . . . . . . . . . . . . . . . . . . . . . 133 15.2. draft-ietf-anima-autonomic-control-plane-30 . . . . . . 134 15.3. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 136 15.4. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 138 15.5. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 140 15.6. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 140 15.7. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 141 15.8. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 144 15.9. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 145 15.10. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 146 16. Normative References . . . . . . . . . . . . . . . . . . . . 148 17. Informative References . . . . . . . . . . . . . . . . . . . 151 Appendix A. Background and Futures (Informative) . . . . . . . . 160 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 160 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 161 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 162 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 162 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 163 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 163 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 163 A.5. ACP Information Distribution and multicast . . . . . . . 165 A.6. CAs, domains and routing subdomains . . . . . . . . . . . 166 A.7. Intent for the ACP . . . . . . . . . . . . . . . . . . . 167 A.8. Adopting ACP concepts for other environments . . . . . . 168 A.9. Further (future) options . . . . . . . . . . . . . . . . 170 A.9.1. Auto-aggregation of routes . . . . . . . . . . . . . 170 A.9.2. More options for avoiding IPv6 Data-Plane dependencies . . . . . . . . . . . . . . . . . . . . 170 A.9.3. ACP APIs and operational models (YANG) . . . . . . . 171 A.9.4. RPL enhancements . . . . . . . . . . . . . . . . . . 171 A.9.5. Role assignments . . . . . . . . . . . . . . . . . . 172 A.9.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 172 A.9.7. Diagnostics . . . . . . . . . . . . . . . . . . . . . 172 A.9.8. Avoiding and dealing with compromised ACP nodes . . . 173 A.9.9. Detecting ACP secure channel downgrade attacks . . . 174 Eckert, et al. Expires 3 May 2021 [Page 5] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Appendix B. Unfinished considerations (To Be Removed From RFC) . . . . . . . . . . . . . . . . . . . . . . . . . . 175 B.1. Considerations for improving secure channel negotiation . . . . . . . . . . . . . . . . . . . . . . . 175 B.2. ACP address verification . . . . . . . . . . . . . . . . 176 B.3. Public CA considerations . . . . . . . . . . . . . . . . 178 B.4. Hardening DULL GRASP considerations . . . . . . . . . . . 179 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 179 1. Introduction (Informative) Autonomic Networking is a concept of self-management: Autonomic functions self-configure, and negotiate parameters and settings across the network. [RFC7575] defines the fundamental ideas and design goals of Autonomic Networking. A gap analysis of Autonomic Networking is given in [RFC7576]. The reference architecture for Autonomic Networking in the IETF is specified in the document [I-D.ietf-anima-reference-model]. Autonomic functions need an autonomically built communications infrastructure. This infrastructure needs to be secure, resilient and re-usable by all autonomic functions. Section 5 of [RFC7575] introduces that infrastructure and calls it the Autonomic Control Plane (ACP). More descriptively it would be the "Autonomic communications infrastructure for OAM and Control". For naming consistency with that prior document, this document continues to use the name ACP though. Today, the OAM and control plane of IP networks is what is typically called in-band management/signaling: Its management and control protocol traffic depends on the routing and forwarding tables, security, policy, QoS and potentially other configuration that first has to be established through the very same management and control protocols. Misconfigurations including unexpected side effects or mutual dependences can disrupt OAM and control operations and especially disrupt remote management access to the affected node itself and potentially a much larger number of nodes for whom the affected node is on the network path. For an example of inband management failing in the face of operator induced misconfiguration, see [FCC], for example III.B.15 on page 8: "...engineers almost immediately recognized that they had misdiagnosed the problem. However, they were unable to resolve the issue by restoring the link because the network management tools required to do so remotely relied on the same paths they had just disabled". Eckert, et al. Expires 3 May 2021 [Page 6] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Traditionally, physically separate, so-called out-of-band (management) networks have been used to avoid these problems or at least to allow recovery from such problems. Worst case, personnel are sent on site to access devices through out-of-band management ports (also called craft ports, serial console, management ethernet port). However, both options are expensive. In increasingly automated networks either centralized management systems or distributed autonomic service agents in the network require a control plane which is independent of the configuration of the network they manage, to avoid impacting their own operations through the configuration actions they take. This document describes a modular design for a self-forming, self- managing and self-protecting ACP, which is a virtual out-of-band network designed to be as independent as possible of configuration, addressing and routing to avoid the self-dependency problems of current IP networks while still operating in-band on the same physical network that it is controlling and managing. The ACP design is therefore intended to combine as well as possible the resilience of out-of-band management networks with the low-cost of traditional IP in-band network management. The details how this is achieved are described in Section 6. In a fully autonomic network node without legacy control or management functions/protocols, the Data-Plane would be for example just a forwarding plane for "Data" IPv6 packets, aka: packets other than the control and management plane packets that are forwarded by the ACP itself. In such networks/nodes, there would be no non- autonomous control or non-autonomous management plane. Routing protocols for example would be built inside the ACP as so- called autonomous functions via autonomous service agents, leveraging the ACP's functions instead of implementing them separately for each protocol: discovery, automatically established authenticated and encrypted local and distant peer connectivity for control and management traffic, and common control/management protocol session and presentation functions. When ACP functionality is added to nodes that have non-autonomous management plane and/or control plane functions (henceforth called non-autonomous nodes), the ACP instead is best abstracted as a special Virtual Routing and Forwarding (VRF) instance (or virtual router) and the complete pre-existing non-autonomous management and/ or control plane is considered to be part of the Data-Plane to avoid introduction of more complex, new terminology only for this case. Eckert, et al. Expires 3 May 2021 [Page 7] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Like the forwarding plane for "Data" packets, the non-autonomous control and management plane functions can then be managed/used via the ACP. This terminology is consistent with pre-existing documents such as [RFC8368]. In both instances (autonomous and non-autonomous nodes), the ACP is built such that it is operating in the absence of the Data-Plane, and in the case of existing non-autonomous (management, control) components in the Data-Plane also in the presence of any (mis-)configuration thereof. The Autonomic Control Plane serves several purposes at the same time: 1. Autonomic functions communicate over the ACP. The ACP therefore directly supports Autonomic Networking functions, as described in [I-D.ietf-anima-reference-model]. For example, Generic Autonomic Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely inside the ACP and depends on the ACP as its "security and transport substrate". 2. A controller or network management system can use it to securely bootstrap network devices in remote locations, even if the (Data- Plane) network in between is not yet configured; no Data-Plane dependent bootstrap configuration is required. An example of such a secure bootstrap process is described in [I-D.ietf-anima-bootstrapping-keyinfra]. 3. An operator can use it to access remote devices using protocols such as Secure SHell (SSH) or Network Configuration Protocol (NETCONF) running across the ACP, even if the network is misconfigured or not configured. This document describes these purposes as use cases for the ACP in Section 3, it defines the requirements in Section 4. Section 5 gives an overview of how the ACP is constructed. The normative part of this document starts with Section 6, where the ACP is specified. Section 7 explains how to support ACP on L2 switches (normative). Section 8 explains how non-ACP nodes and networks can be integrated (normative). The remaining sections are non-normative: Section 10 reviews benefits of the ACP (after all the details have been defined), Section 9 provides operational recommendations, Appendix A provides additional explanations and describes additional details or future standard or proprietary extensions that were considered not to be appropriate for standardization in this document but were considered important to document. There are no dependencies against Appendix A to build a complete working and interoperable ACP according to this document. Eckert, et al. Expires 3 May 2021 [Page 8] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The ACP provides secure IPv6 connectivity, therefore it can be used not only as the secure connectivity for self-management as required for the ACP in [RFC7575], but it can also be used as the secure connectivity for traditional (centralized) management. The ACP can be implemented and operated without any other components of autonomic networks, except for the GRASP protocol. ACP relies on per-link DULL GRASP (see Section 6.4) to autodiscover ACP neighbors, and includes the ACP GRASP instance to provide service discovery for clients of the ACP (see Section 6.9) including for its own maintenance of ACP certificates. The document "Using Autonomic Control Plane for Stable Connectivity of Network OAM" [RFC8368] describes how the ACP alone can be used to provide secure and stable connectivity for autonomic and non- autonomic OAM applications, specifically for the case of current non- autonomic networks/nodes. That document also explains how existing management solutions can leverage the ACP in parallel with traditional management models, when to use the ACP and how to integrate with potentially IPv4 only OAM backends. Combining ACP with Bootstrapping Remote Secure Key Infrastructures (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the "Autonomic Network Infrastructure" (ANI) as defined in [I-D.ietf-anima-reference-model], which provides autonomic connectivity (from ACP) with secure zero-touch (automated) bootstrap from BRSKI. The ANI itself does not constitute an Autonomic Network, but it allows the building of more or less autonomic networks on top of it - using either centralized, Software Defined Networking- (SDN-)style (see [RFC7426]) automation or distributed automation via Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a mixture of both. See [I-D.ietf-anima-reference-model] for more information. 1.1. Applicability and Scope Please see the following Terminology section (Section 2) for explanations of terms used in this section. The design of the ACP as defined in this document is considered to be applicable to all types of "professionally managed" networks: Service Provider, Local Area Network (LAN), Metro(politan networks), Wide Area Network (WAN), Enterprise Information Technology (IT) and ->"Operational Technology" (OT) networks. The ACP can operate equally on layer 3 equipment and on layer 2 equipment such as bridges (see Section 7). The hop-by-hop authentication, integrity-protection and confidentiality mechanism used by the ACP is defined to be negotiable, therefore it can be extended to environments with different protocol preferences. The minimum implementation Eckert, et al. Expires 3 May 2021 [Page 9] Internet-Draft An Autonomic Control Plane (ACP) October 2020 requirements in this document attempt to achieve maximum interoperability by requiring support for multiple options depending on the type of device: IPsec, see [RFC4301], and Datagram Transport Layer Security (DTLS, see Section 6.8.4). The implementation footprint of the ACP consists of Public Key Infrastructure (PKI) code for the ACP certificate including "Enrollment over Secure Transport (EST, see [RFC7030]), the GRASP protocol, UDP, TCP and Transport Layer Security (TLS, see Section 6.1), for security and reliability of GRASP and for EST, the ACP secure channel protocol used (such as IPsec or DTLS), and an instance of IPv6 packet forwarding and routing via the Routing Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that is separate from routing and forwarding for the Data-Plane (user traffic). The ACP uses only IPv6 to avoid complexity of dual-stack ACP operations (IPv6/IPv4). Nevertheless, it can without any changes be integrated into even otherwise IPv4-only network devices. The Data- Plane itself would not need to change and it could continue to be IPv4 only. For such IPv4-only devices, the IPv6 protocol itself would be additional implementation footprint that is only required for the ACP. The protocol choices of the ACP are primarily based on wide use and support in networks and devices, well understood security properties and required scalability. The ACP design is an attempt to produce the lowest risk combination of existing technologies and protocols to build a widely applicable operational network management solution. RPL was chosen because it requires a smaller routing table footprint in large networks compared to other routing protocols with an autonomically configured single area. The deployment experience of large scale Internet of Things (IoT) networks serves as the basis for wide deployment experience with RPL. The profile chosen for RPL in the ACP does not leverage any RPL specific forwarding plane features (IPv6 extension headers), making its implementation a pure control plane software requirement. GRASP is the only completely novel protocol used in the ACP, and this choice was necessary because there is no existing suitable protocol to provide the necessary functions to the ACP, so GRASP was developed to fill that gap. The ACP design can be applicable to devices constrained with respect to cpu and memory, and to networks constrained with respect to bitrate and reliability, but this document does not attempt to define the most constrained type of devices or networks to which the ACP is Eckert, et al. Expires 3 May 2021 [Page 10] Internet-Draft An Autonomic Control Plane (ACP) October 2020 applicable. RPL and DTLS for ACP secure channels are two protocol choices already making ACP more applicable to constrained environments. Support for constrained devices in this specification is opportunistic, but not complete, because the reliable transport for GRASP (see Section 6.9.2) only specifies TCP/TLS. See Appendix A.8 for discussions about how future standards or proprietary extensions/variations of the ACP could better meet different expectations from those on which the current design is based including supporting constrained devices better. 2. Acronyms and Terminology (Informative) [RFC-Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- editor.org/materials/abbrev.expansion.txt.] [RFC-Editor: What is the recommended way to reference a hanging text, e.g. to a definition in the list of definitions? Up to -28, this document was using XMLv2 and the only option I could find for RFC/XML to point to a hanging text was format="title", which leads to references such as '->"ACP certificate" ()', aka: redundant empty parenthesis. Many reviewers where concerned about this. I created a ticket to ask for an xml2rfc enhancement to avoid this in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. When i changed to XMLv3 in version -29, i could get rid of the unnecessary () by using format="none", but that format is declared to be deprecated in XMLv3. So i am not aware of any working AND "non- deprecated" option.] [RFC-Editor: Question: Is it possible to change the first occurrences of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC format does not seem to offer such a format, but I did not want to duplicate 50 first references - one reference for title mentioning and one for RFC number.] This document serves both as a normative specification for how ACP nodes have to behave as well as describing requirements, benefits, architecture and operational aspects to explain the context. Normative sections are labelled "(Normative)" and use BCP 14 keywords. Other sections are labelled "(Informative)" and do not use those normative keywords. In the rest of the document we will refer to systems using the ACP as "nodes". Typically, such a node is a physical (network equipment) device, but it can equally be some virtualized system. Therefore, we do not refer to them as devices unless the context specifically calls for a physical system. Eckert, et al. Expires 3 May 2021 [Page 11] Internet-Draft An Autonomic Control Plane (ACP) October 2020 This document introduces or uses the following terms (sorted alphabetically). Terms introduced are explained on first use, so this list is for reference only. ACP: "Autonomic Control Plane". The Autonomic Function as defined in this document. It provides secure zero-touch (automated) transitive (network wide) IPv6 connectivity for all nodes in the same ACP domain as well as a GRASP instance running across this ACP IPv6 connectivity. The ACP is primarily meant to be used as a component of the ANI to enable Autonomic Networks but it can equally be used in simple ANI networks (with no other Autonomic Functions) or completely by itself. ACP address: An IPv6 address assigned to the ACP node. It is stored in the acp-node-name of the ->"ACP certificate". ACP address range/set: The ACP address may imply a range or set of addresses that the node can assign for different purposes. This address range/set is derived by the node from the format of the ACP address called the "addressing sub-scheme". ACP connect interface: An interface on an ACP node providing access to the ACP for non ACP capable nodes without using an ACP secure channel. See Section 8.1.1. ACP domain: The ACP domain is the set of nodes with ->"ACP certificates" that allow them to authenticate each other as members of the ACP domain. See also Section 6.2.3. ACP (ANI/AN) certificate: A [RFC5280] certificate (LDevID) carrying the acp-node-name which is used by the ACP to learn its address in the ACP and to derive and cryptographically assert its membership in the ACP domain. ACP acp-node-name field: An information field in the ACP certificate in which the ACP relevant information is encoded: the ACP domain name, the ACP IPv6 address of the node and optional additional role attributes about the node. ACP Loopback interface: The Loopback interface in the ACP Virtual Routing and Forwarding (VRF) that has the ACP address assigned to it. See Section 6.13.5.1. ACP network: The ACP network constitutes all the nodes that have access to the ACP. It is the set of active and transitively connected nodes of an ACP domain plus all nodes that get access to the ACP of that domain via ACP edge nodes. ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the ACP. In the normal/simple case, the ACP has one ULA prefix, see Section 6.11. The ACP routing table may include multiple ULA prefixes if the "rsub" option is used to create addresses from more than one ULA prefix. See Section 6.2.2. The ACP may also include non-ULA prefixes if those are configured on ACP connect interfaces. See Section 8.1.1. ACP secure channel: A channel authenticated via ->"ACP certificates" Eckert, et al. Expires 3 May 2021 [Page 12] Internet-Draft An Autonomic Control Plane (ACP) October 2020 providing integrity protection and confidentiality through encryption. These are established between (normally) adjacent ACP nodes to carry traffic of the ACP VRF securely and isolated from Data-Plane traffic in-band over the same link/path as the Data- Plane. ACP secure channel protocol: The protocol used to build an ACP secure channel, e.g., Internet Key Exchange Protocol version 2 (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). ACP virtual interface: An interface in the ACP VRF mapped to one or more ACP secure channels. See Section 6.13.5. AN "Autonomic Network": A network according to [I-D.ietf-anima-reference-model]. Its main components are ANI, Autonomic Functions and Intent. (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the acp- node-name of the Domain Certificate. See Section 6.2.2. ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is the infrastructure to enable Autonomic Networks. It includes ACP, BRSKI and GRASP. Every Autonomic Network includes the ANI, but not every ANI network needs to include autonomic functions beyond the ANI (nor Intent). An ANI network without further autonomic functions can for example support secure zero-touch (automated) bootstrap and stable connectivity for SDN networks - see [RFC8368]. ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, BRSKI and GRASP are specifications of the IETF ANIMA working group. ASA: "Autonomic Service Agent". Autonomic software modules running on an ANI device. The components making up the ANI (BRSKI, ACP, GRASP) are also described as ASAs. Autonomic Function: A function/service in an Autonomic Network (AN) composed of one or more ASA across one or more ANI nodes. BRSKI: "Bootstrapping Remote Secure Key Infrastructures" ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending EST to enable secure zero-touch bootstrap in conjunction with ACP. ANI nodes use ACP, BRSKI and GRASP. CA: "Certification Authority". An entity that issues digital certificates. A CA uses its private key to sign the certificates it issues. Relying parties use the public key in the CA certificate to validate the signature. CRL: "Certificate Revocation List". A list of revoked certificates. Required to revoke certificates before their lifetime expires. Data-Plane: The counterpoint to the ACP VRF in an ACP node: forwarding of user traffic and in non-autonomous nodes/networks also any non-autonomous control and/or management plane functions. In a fully Autonomic Network node, the Data-Plane is managed autonomically via Autonomic Functions and Intent. See Section 1 for more detailed explanations. device: A physical system, or physical node. Eckert, et al. Expires 3 May 2021 [Page 13] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Enrollment: The process through which a node authenticates itself to a network with an initial identity, which is often called IDevID certificate, and acquires from the network a network specific identity, which is often called LDevID certificate, and certificates of one or more Trust Anchor(s). In the ACP, the LDevID certificate is called the ACP certificate. EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- track protocol for enrollment of a node with an LDevID certificate. BRSKI is based on EST. GRASP: "Generic Autonomic Signaling Protocol". An extensible signaling protocol required by the ACP for ACP neighbor discovery. The ACP also provides the "security and transport substrate" for the "ACP instance of GRASP". This instance of GRASP runs across the ACP secure channels to support BRSKI and other NOC/OAM or Autonomic Functions. See [I-D.ietf-anima-grasp]. IDevID: An "Initial Device IDentity" X.509 certificate installed by the vendor on new equipment. Contains information that establishes the identity of the node in the context of its vendor/ manufacturer such as device model/type and serial number. See [AR8021]. The IDevID certificate cannot be used as a node identifier for the ACP because they are not provisioned by the owner of the network, so they can not directly indicate an ACP domain they belong to. in-band (management/signaling): In-band management traffic and/or control plane signaling uses the same network resources such as routers/switches and network links that it manages/controls. In- band is the standard management and signaling mechanism in IP networks. Compared to ->"out-of-band" it requires no additional physical resources, but introduces potentially circular dependencies for its correct operations. See ->"introduction". Intent: Policy language of an autonomic network according to [I-D.ietf-anima-reference-model]. Loopback interface: See ->"ACP Loopback interface". LDevID: A "Local Device IDentity" is an X.509 certificate installed during "enrollment". The Domain Certificate used by the ACP is an LDevID certificate. See [AR8021]. Management: Used in this document as another word for ->"OAM". MASA (service): "Manufacturer Authorized Signing Authority". A vendor/manufacturer or delegated cloud service on the Internet used as part of the BRSKI protocol. MIC: "Manufacturer Installed Certificate". This is another word to describe an IDevID in referenced materials. This term is not used in this document. native interface: Interfaces existing on a node without configuration of the already running node. On physical nodes these are usually physical interfaces; on virtual nodes their equivalent. NOC: Network Operations Center. Eckert, et al. Expires 3 May 2021 [Page 14] Internet-Draft An Autonomic Control Plane (ACP) October 2020 node: A system supporting the ACP according to this document. Can be virtual or physical. Physical nodes are called devices. Node-ID: The identifier of an ACP node inside that ACP. It is the last 64 (see Section 6.11.3) or 78-bits (see Section 6.11.5) of the ACP address. OAM: Operations, Administration and Management. Includes Network Monitoring. Operational Technology (OT): https://en.wikipedia.org/wiki/ Operational_Technology: "The hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves, pumps, etc.". OT networks are today in most cases well separated from Information Technology (IT) networks. out-of-band (management) network: An out-of-band network is a secondary network used to manage a primary network. The equipment of the primary network is connected to the out-of-band network via dedicated management ports on the primary network equipment. Serial (console) management ports were historically most common, higher end network equipment now also has ethernet ports dedicated only for management. An out-of-band network provides management access to the primary network independent of the configuration state of the primary network. See ->"Introduction" (virtual) out-of-band network: The ACP can be called a virtual out- of-band network for management and control because it attempts to provide the benefits of a (physical) ->"out-of-band network" even though it is physically carried ->"in-band". See ->"introduction". root CA: "root Certification Authority". A ->"CA" for which the root CA Key update procedures of [RFC7030], Section 4.4 can be applied. RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The routing protocol used in the ACP. See [RFC6550]. (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software and/or person) that is orchestrating the enrollment of ACP nodes with the ACP certificate. ANI nodes use BRSKI, so ANI registrars are also called BRSKI registrars. For non-ANI ACP nodes, the registrar mechanisms are undefined by this document. See Section 6.11.7. Renewal and other maintenance (such as revocation) of ACP certificates may be performed by other entities than registrars. EST must be supported for ACP certificate renewal (see Section 6.2.5). BRSKI is an extension of EST, so ANI/BRSKI registrars can easily support ACP domain certificate renewal in addition to initial enrollment. RPI: "RPL Packet Information". Network extension headers for use with the ->"RPL" routing protocols. Not used with RPL in the ACP. See Section 6.12.1.13. RPL: "Routing Protocol for Low-Power and Lossy Networks". The routing protocol used in the ACP. See Section 6.12. Eckert, et al. Expires 3 May 2021 [Page 15] Internet-Draft An Autonomic Control Plane (ACP) October 2020 sUDI: "secured Unique Device Identifier". This is another word to describe an IDevID in referenced material. This term is not used in this document. TA: "Trust Anchor". A Trust Anchor is an entity that is trusted for the purpose of certificate validation. Trust Anchor Information such as self-signed certificate(s) of the Trust Anchor is configured into the ACP node as part of Enrollment. See [RFC5280], Section 6.1.1. UDI: "Unique Device Identifier". In the context of this document unsecured identity information of a node typically consisting of at least device model/type and serial number, often in a vendor specific format. See sUDI and LDevID. ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 address in the block fc00::/7, defined in [RFC4193]. ULA is the IPv6 successor of the IPv4 private address space ([RFC1918]). ULA have important differences over IPv4 private addresses that are beneficial for and exploited by the ACP, such as the Locally Assigned Global ID prefix, which are the first 48-bits of a ULA address [RFC4193], section 3.2.1. In this document this prefix is abbreviated as "ULA prefix". (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing and Forwarding" instance (VRF). This means that it is based on a "virtual router" consisting of a separate IPv6 forwarding table to which the ACP virtual interfaces are attached and an associated IPv6 routing table separate from the Data-Plane. Unlike the VRFs on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF does not have any special "core facing" functionality or routing/ mapping protocols shared across multiple VRFs. In vendor products a VRF such as the ACP-VRF may also be referred to as a so called VRF-lite. (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone field value in their ACP address according to Section 6.11.3. Zones are a mechanism to support structured addressing of ACP addresses within the same /48-bit ULA prefix. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119],[RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Use Cases for an Autonomic Control Plane (Informative) This section summarizes the use cases that are intended to be supported by an ACP. To understand how these are derived from and relate to the larger set of use cases for autonomic networks, please refer to [RFC8316]. Eckert, et al. Expires 3 May 2021 [Page 16] Internet-Draft An Autonomic Control Plane (ACP) October 2020 3.1. An Infrastructure for Autonomic Functions Autonomic Functions need a stable infrastructure to run on, and all autonomic functions should use the same infrastructure to minimize the complexity of the network. In this way, there is only need for a single discovery mechanism, a single security mechanism, and single instances of other processes that distributed functions require. 3.2. Secure Bootstrap over a not configured Network Today, bootstrapping a new node typically requires all nodes between a controlling node such as an SDN controller ("Software Defined Networking", see [RFC7426]) and the new node to be completely and correctly addressed, configured and secured. Bootstrapping and configuration of a network happens in rings around the controller - configuring each ring of devices before the next one can be bootstrapped. Without console access (for example through an out-of- band network) it is not possible today to make devices securely reachable before having configured the entire network leading up to them. With the ACP, secure bootstrap of new devices and whole new networks can happen without requiring any configuration of unconfigured devices along the path: As long as all devices along the path support ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP across a whole network of unconfigured devices can be brought up without operator/provisioning intervention. The ACP also provides additional security for any bootstrap mechanism, because it can provide encrypted discovery (via ACP GRASP) of registrars or other bootstrap servers by bootstrap proxies connecting to nodes that are to be bootstrapped and the ACP encryption hides the identities of the communicating entities (pledge and registrar), making it more difficult to learn which network node might be attackable. The ACP certificate can also be used to end-to-end encrypt the bootstrap communication between such proxies and server. Note that bootstrapping here includes not only the first step that can be provided by BRSKI (secure keys), but also later stages where configuration is bootstrapped. 3.3. Data-Plane Independent Permanent Reachability Today, most critical control plane protocols and OAM protocols are using the Data-Plane of the network. This leads to often undesirable dependencies between control and OAM plane on one side and the Data- Plane on the other: Only if the forwarding and control plane of the Data-Plane are configured correctly, will the Data-Plane and the OAM/ control plane work as expected. Eckert, et al. Expires 3 May 2021 [Page 17] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Data-Plane connectivity can be affected by errors and faults, for example misconfigurations that make AAA (Authentication, Authorization and Accounting) servers unreachable or can lock an administrator out of a device; routing or addressing issues can make a device unreachable; shutting down interfaces over which a current management session is running can lock an admin irreversibly out of the device. Traditionally only out-of-band access can help recover from such issues (such as serial console or ethernet management port). Data-Plane dependencies also affect applications in a Network Operations Center (NOC) such as SDN controller applications: Certain network changes are today hard to implement, because the change itself may affect reachability of the devices. Examples are address or mask changes, routing changes, or security policies. Today such changes require precise hop-by-hop planning. Note that specific control plane functions for the Data-Plane often want to depend on forwarding of their packets via the Data-Plane: Aliveness and routing protocol signaling packets across the Data- Plane to verify reachability across the Data-Plane, using IPv4 signaling packets for IPv4 routing vs. IPv6 signaling packets for IPv6 routing. Assuming appropriate implementation (see Section 6.13.2 for more details), the ACP provides reachability that is independent of the Data-Plane. This allows the control plane and OAM plane to operate more robustly: * For management plane protocols, the ACP provides the functionality of a Virtual out-of-band (VooB) channel, by providing connectivity to all nodes regardless of their Data-Plane configuration, routing and forwarding tables. * For control plane protocols, the ACP allows their operation even when the Data-Plane is temporarily faulty, or during transitional events, such as routing changes, which may affect the control plane at least temporarily. This is specifically important for autonomic service agents, which could affect Data-Plane connectivity. The document "Using Autonomic Control Plane for Stable Connectivity of Network OAM" [RFC8368] explains this use case for the ACP in significantly more detail and explains how the ACP can be used in practical network operations. Eckert, et al. Expires 3 May 2021 [Page 18] Internet-Draft An Autonomic Control Plane (ACP) October 2020 4. Requirements (Informative) The following requirements were identified for the design of the ACP based on the above use-cases (Section 3). These requirements are informative. The ACP as specified in the normative parts of this document is meeting or exceeding these use-case requirements: ACP1: The ACP should provide robust connectivity: As far as possible, it should be independent of configured addressing, configuration and routing. Requirements 2 and 3 build on this requirement, but also have value on their own. ACP2: The ACP must have a separate address space from the Data- Plane. Reason: traceability, debug-ability, separation from Data-Plane, infrastructure security (filtering based on known address space). ACP3: The ACP must use autonomically managed address space. Reason: easy bootstrap and setup ("autonomic"); robustness (admin cannot break network easily). This document uses Unique Local Addresses (ULA) for this purpose, see [RFC4193]. ACP4: The ACP must be generic, that is it must be usable by all the functions and protocols of the ANI. Clients of the ACP must not be tied to a particular application or transport protocol. ACP5: The ACP must provide security: Messages coming through the ACP must be authenticated to be from a trusted node, and it is very strongly > recommended that they be encrypted. Explanation for ACP4: In a fully autonomic network (AN), newly written ASAs could potentially all communicate exclusively via GRASP with each other, and if that was assumed to be the only requirement against the ACP, it would not need to provide IPv6 layer connectivity between nodes, but only GRASP connectivity. Nevertheless, because ACP also intends to support non-AN networks, it is crucial to support IPv6 layer connectivity across the ACP to support any transport and application layer protocols. The ACP operates hop-by-hop, because this interaction can be built on IPv6 link local addressing, which is autonomic, and has no dependency on configuration (requirement 1). It may be necessary to have ACP connectivity across non-ACP nodes, for example to link ACP nodes over the general Internet. This is possible, but introduces a dependency against stable/resilient routing over the non-ACP hops (see Section 8.2). Eckert, et al. Expires 3 May 2021 [Page 19] Internet-Draft An Autonomic Control Plane (ACP) October 2020 5. Overview (Informative) When a node has an ACP certificate (see Section 6.2.1) and is enabled to bring up the ACP (see Section 9.3.5), it will create its ACP without any configuration as follows. For details, see Section 6 and further sections: 1. The node creates a VRF instance, or a similar virtual context for the ACP. 2. The node assigns its ULA IPv6 address (prefix) (see Section 6.11 which is learned from the acp-node-name (see Section 6.2.2) of its ACP certificate (see Section 6.2.1) to an ACP loopback interface (see Section 6.11) and connects this interface into the ACP VRF. 3. The node establishes a list of candidate peer adjacencies and candidate channel types to try for the adjacency. This is automatic for all candidate link-local adjacencies, see Section 6.4 across all native interfaces (see Section 9.3.4). If a candidate peer is discovered via multiple interfaces, this will result in one adjacency per interface. If the ACP node has multiple interfaces connecting to the same subnet across which it is also operating as an L2 switch in the Data-Plane, it employs methods for ACP with L2 switching, see Section 7. 4. For each entry in the candidate adjacency list, the node negotiates a secure tunnel using the candidate channel types. See Section 6.6. 5. The node authenticates the peer node during secure channel setup and authorizes it to become part of the ACP according to Section 6.2.3. 6. Unsuccessful authentication of a candidate peer results in throttled connection retries for as long as the candidate peer is discoverable. See Section 6.7. 7. Each successfully established secure channel is mapped into an ACP virtual interface, which is placed into the ACP VRF. See Section 6.13.5.2. 8. Each node runs a lightweight routing protocol, see Section 6.12, to announce reachability of the ACP loopback address (or prefix) across the ACP. 9. This completes the creation of the ACP with hop-by-hop secure tunnels, auto-addressing and auto-routing. The node is now an ACP node with a running ACP. Note: * None of the above operations (except the following explicit configured ones) are reflected in the configuration of the node. * Non-ACP NMS ("Network Management Systems") or SDN controllers have to be explicitly configured for connection into the ACP. Eckert, et al. Expires 3 May 2021 [Page 20] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * Additional candidate peer adjacencies for ACP connections across non-ACP Layer-3 clouds requires explicit configuration. See Section 8.2. The following figure illustrates the ACP. ACP node 1 ACP node 2 ................... ................... secure . . secure . . secure channel: +-----------+ : channel : +-----------+ : channel ..--------| ACP VRF |---------------------| ACP VRF |---------.. : / \ / \ <--routing--> / \ / \ : : \ / \ / \ / \ / : ..--------| Loopback |---------------------| Loopback |---------.. : | interface | : : | interface | : : +-----------+ : : +-----------+ : : : : : : Data-Plane :...............: Data-Plane : : : link : : :.................: :.................: Figure 1: ACP VRF and secure channels The resulting overlay network is normally based exclusively on hop- by-hop tunnels. This is because addressing used on links is IPv6 link local addressing, which does not require any prior set-up. In this way the ACP can be built even if there is no configuration on the node, or if the Data-Plane has issues such as addressing or routing problems. 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) This section specifies the components and steps to set up an ACP. The ACP is automatically "self-creating", which makes it "indestructible" against most changes to the Data-Plane, including misconfigurations of routing, addressing, NAT, firewall or any other traffic policy filters that inadvertently or otherwise unavoidably would also impact the management plane traffic, such as the actual operator CLI session or controller NETCONF session through which the configuration changes to the Data-Plane are executed. Physical misconfiguration of wiring between ACP nodes will also not break the ACP: As long as there is a transitive physical path between ACP nodes, the ACP should be able to recover given that it automatically operates across all interfaces of the ACP nodes and automatically determines paths between them. Eckert, et al. Expires 3 May 2021 [Page 21] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Attacks against the network via incorrect routing or addressing information for the Data-Plane will not impact the ACP. Even impaired ACP nodes will have a significantly reduced attack surface against malicious misconfiguration because only very limited ACP or interface up/down configuration can affect the ACP, and pending on their specific designs these type of attacks could also be eliminated. See more in Section 9.3 and Section 11. An ACP node can be a router, switch, controller, NMS host, or any other IPv6 capable node. Initially, it MUST have its ACP certificate, as well as an (empty) ACP Adjacency Table (described in Section 6.3). It then can start to discover ACP neighbors and build the ACP. This is described step by step in the following sections: 6.1. Requirements for use of Transport Layer Security (TLS) The following requirements apply to TLS required or used by ACP components. Applicable ACP components include ACP certificate maintenance via EST, see Section 6.2.5, TLS connections for Certificate Revocation List (CRL) Distribution Point (CRLDP) or Online Certificate Status Protocol (OCSP) responder (if used, see Section 6.2.3) and ACP GRASP (see Section 6.9.2). On ANI nodes these requirements also apply to BRSKI. TLS MUST comply with [RFC7525] except that TLS 1.2 ([RFC5246]) is REQUIRED and that older versions of TLS MUST NOT be used. TLS 1.3 ([RFC8446]) SHOULD be supported. The choice for TLS 1.2 as the lowest common denominator for the ACP is based on current expected most likely availability across the wide range of candidate ACP node types, potentially with non-agile operating system TCP/IP stacks. TLS MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options with less than 256-bit symmetric key strength or hash strength of less than 384 bits. When TLS 1.3 is supported, TLS_AES_256_GCM_SHA384 MUST be offered and TLS_CHACHA20_POLY1305_SHA256 MAY be offered. TLS MUST also include the "Supported Elliptic Curves" extension, it MUST support the NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24)) curves [RFC8422]. In addition, TLS 1.2 clients SHOULD send an ec_point_format extension with a single element, "uncompressed". Eckert, et al. Expires 3 May 2021 [Page 22] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.2. ACP Domain, Certificate and Network The ACP relies on group security. An ACP domain is a group of nodes that trust each other to participate in ACP operations such as creating ACP secure channels in an autonomous peer-to-peer fashion between ACP domain members via protocols such as IPsec. To authenticate and authorize another ACP member node with access to the ACP Domain, each ACP member requires keying material: An ACP node MUST have a Local Device IDentity (LDevID) certificate, henceforth called the ACP certificate and information about one or more Trust Anchor (TA) as required for the ACP domain membership check (Section 6.2.3). Manual keying via shared secrets is not usable for an ACP domain because it would require a single shared secret across all current and future ACP domain members to meet the expectation of autonomous, peer-to-peer establishment of ACP secure channels between any ACP domain members. Such a single shared secret would be an inacceptable security weakness. Asymmetric keying material (public keys) without certificates does not provide the mechanisms to authenticate ACP domain membership in an autonomous, peer-to-peer fashion for current and future ACP domain members. The LDevID certificate is called the ACP certificate. The TA is the Certification Authority (CA) root certificate of the ACP domain. The ACP does not mandate specific mechanisms by which this keying material is provisioned into the ACP node. It only requires the certificate to comply with Section 6.2.1, specifically to have the acp-node-name as specified in Section 6.2.2 in its domain certificate as well as those of candidate ACP peers. See Appendix A.2 for more information about enrollment or provisioning options. This document uses the term ACP in many places where the Autonomic Networking reference documents [RFC7575] and [I-D.ietf-anima-reference-model] use the word autonomic. This is done because those reference documents consider (only) fully autonomic networks and nodes, but support of ACP does not require support for other components of autonomic networks except for relying on GRASP and providing security and transport for GRASP. Therefore, the word autonomic might be misleading to operators interested in only the ACP. [RFC7575] defines the term "Autonomic Domain" as a collection of autonomic nodes. ACP nodes do not need to be fully autonomic, but when they are, then the ACP domain is an autonomic domain. Likewise, [I-D.ietf-anima-reference-model] defines the term "Domain Certificate" as the certificate used in an autonomic domain. The ACP Eckert, et al. Expires 3 May 2021 [Page 23] Internet-Draft An Autonomic Control Plane (ACP) October 2020 certificate is that domain certificate when ACP nodes are (fully) autonomic nodes. Finally, this document uses the term ACP network to refer to the network created by active ACP nodes in an ACP domain. The ACP network itself can extend beyond ACP nodes through the mechanisms described in Section 8.1. 6.2.1. ACP Certificates ACP certificates MUST be [RFC5280] compliant X.509 v3 ([X.509]) certificates. ACP nodes MUST support handling ACP certificates, TA certificates and certificate chain certificates (henceforth just called certificates in this section) with RSA public keys and certificates with Elliptic Curve (ECC) public keys. ACP nodes MUST NOT support certificates with RSA public keys of less than 2048-bit modulus or curves with group order of less than 256-bit. They MUST support certificates with RSA public keys with 2048-bit modulus and MAY support longer RSA keys. They MUST support certificates with ECC public keys using NIST P-256 curves and SHOULD support P-384 and P-521 curves. ACP nodes MUST NOT support certificates with RSA public keys whose modulus is less than 2048 bits, or certificates whose ECC public keys are in groups whose order is less than 256-bits. RSA signing certificates with 2048-bit public keys MUST be supported, and such certificates with longer public keys MAY be supported. ECDSA certificates using the NIST P-256 curve MUST be supported, and such certificates using the P-384 and P-521 curves SHOULD be supported. ACP nodes MUST support RSA certificates that are signed by RSA signatures over the SHA-256 digest of the contents, and SHOULD additionally support SHA-384 and SHA-512 digests in such signatures. The same requirements for digest usage in certificate signatures apply to ECDSA certificates, and additionally, ACP nodes MUST support ECDSA signatures on ECDSA certificates. The ACP certificate SHOULD use an RSA key and an RSA signature when the ACP certificate is intended to be used not only for ACP authentication but also for other purposes. The ACP certificate MAY use an ECC key and an ECDSA signature if the ACP certificate is only used for ACP and ANI authentication and authorization. Any secure channel protocols used for the ACP as specified in this document or extensions of this document MUST therefore support authentication (e.g. signing) starting with these type of certificates. See [RFC8422] for more information. Eckert, et al. Expires 3 May 2021 [Page 24] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The reason for these choices are as follows: As of 2020, RSA is still more widely used than ECC, therefore the MUST for RSA. ECC offers equivalent security at (logarithmically) shorter key lengths (see [RFC8422]). This can be beneficial especially in the presence of constrained bandwidth or constrained nodes in an ACP/ANI network. Some ACP functions such as GRASP peer-2-peer across the ACP require end-to-end/any-to-any authentication/authorization, therefore ECC can only reliably be used in the ACP when it MUST be supported on all ACP nodes. RSA signatures are mandatory to be supported also for ECC certificates because CAs themselves may not support ECC yet. The ACP certificate SHOULD be used for any authentication between nodes with ACP domain certificates (ACP nodes and NOC nodes) where a required authorization condition is ACP domain membership, such as ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end security. Section 6.2.3 defines this "ACP domain membership check". The uses of this check that are standardized in this document are for the establishment of hop-by-hop ACP secure channels (Section 6.7) and for ACP GRASP (Section 6.9.2) end-to-end via TLS. The ACP domain membership check requires a minimum amount of elements in a certificate as described in Section 6.2.3. The identity of a node in the ACP is carried via the acp-node-name as defined in Section 6.2.2. To support ECDH directly with the key in the ACP certificate, ACP certificates with ECC keys need to indicate to be Elliptic Curve Diffie-Hellman capable (ECDH): If the X.509v3 keyUsage extension is present, the keyAgreement bit must then be set. Note that this option is not required for any of the required ciphersuites in this document and may not be supported by all CA. Any other fields of the ACP certificate are to be populated as required by [RFC5280]: As long as they are compliant with [RFC5280], any other field of an ACP certificate can be set as desired by the operator of the ACP domain through appropriate ACP registrar/ACP CA procedures. For example, other fields may be required for other purposes that the ACP certificate is intended to be used for (such as elements of a SubjectName). For further certificate details, ACP certificates may follow the recommendations from [CABFORUM]. For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID certificate into the ACP certificate, such as the [X.520], section 6.2.9 "serialNumber" attribute in the subject field distinguished name encoding. Note that this is not the certificate serial number. See Eckert, et al. Expires 3 May 2021 [Page 25] Internet-Draft An Autonomic Control Plane (ACP) October 2020 also [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1. This can be done for example if it would be acceptable for the device's "serialNumber" to be signaled via the Link Layer Discovery Protocol (LLDP, [LLDP]) because like LLDP signaled information, the ACP certificate information can be retrieved by neighboring nodes without further authentication and be used either for beneficial diagnostics or for malicious attacks. Retrieval of the ACP certificate is possible via a (failing) attempt to set up an ACP secure channel, and the "serialNumber" usually contains device type information that may help to faster determine working exploits/attacks against the device. Note that there is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with additional requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. See the additional check against the id-kp-cmcRA [RFC6402] extended key usage attribute (Section 6.2.5) and for possible future extensions, see Appendix A.9.5. 6.2.2. ACP Certificate AcpNodeName acp-node-name = local-part "@" acp-domain-name local-part = [ acp-address ] [ "+" rsub extensions ] acp-address = 32HEXDIG | "0" ; HEXDIG as of RFC5234 section B.1 rsub = [ ] ; as of RFC1034, section 3.5 acp-domain-name = ; ; as of RFC 1034, section 3.5 extensions = *( "+" extension ) extension = 1*etext ; future standard definition. etext = ALPHA / DIGIT / ; Printable US-ASCII "!" / "#" / "$" / "%" / "&" / "'" / "*" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" routing-subdomain = [ rsub "." ] acp-domain-name Example: given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 and an ACP domain-name of acp.example.com and an rsub extenstion of area51.research then this results in: acp-node-name = fd89b714f3db00000200000064000000 +area51.research@acp.example.com acp-domain-name = acp.example.com routing-subdomain = area51.research.acp.example.com Eckert, et al. Expires 3 May 2021 [Page 26] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Figure 2: ACP Node Name ABNF acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of the ACP Node Name. An ACP certificate MUST carry this information. It MUST be encoded as a subjectAltName / otherName / AcpNodeName as described in Section 6.2.2.1. Nodes complying with this specification MUST be able to receive their ACP address through the domain certificate, in which case their own ACP certificate MUST have a 32HEXDIG acp-address field. Acp-address is case insensitive because ABNF HEXDIG is. It is recommended to encode acp-address with lower case letters. Nodes complying with this specification MUST also be able to authenticate nodes as ACP domain members or ACP secure channel peers when they have a 0-value acp-address field and as ACP domain members (but not as ACP secure channel peers) when the acp-address field is omitted from their AcpNodeName. See Section 6.2.3. acp-domain-name is used to indicate the ACP Domain across which ACP nodes authenticate and authorize each other, for example to build ACP secure channels to each other, see Section 6.2.3. acp-domain-name SHOULD be the FQDN of an Internet domain owned by the network administration of the ACP and ideally reserved to only be used for the ACP. In this specification it serves to be a name for the ACP that ideally is globally unique. When acp-domain-name is a globally unique name, collision of ACP addresses across different ACP domains can only happen due to ULA hash collisions (see Section 6.11.2). Using different acp-domain-names, operators can distinguish multiple ACP even when using the same TA. To keep the encoding simple, there is no consideration for internationalized acp-domain-names. The acp-node-name is not intended for end user consumption. There is no protection against an operator to pick any domain name for an ACP whether or not the operator can claim to own the domain name. Instead, the domain name only serves as a hash seed for the ULA and for diagnostics to the operator. Therefore, any operator owning only an internationalized domain name should be able to pick an equivalently unique 7-bit ASCII acp-domain-name string representing the internationalized domain name. "routing-subdomain" is a string that can be constructed from the acp- node-name, and it is used in the hash-creation of the ULA (see below). The presence of the "rsub" component allows a single ACP domain to employ multiple /48 ULA prefixes. See Appendix A.6 for example use-cases. Eckert, et al. Expires 3 May 2021 [Page 27] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The optional "extensions" field is used for future standardized extensions to this specification. It MUST be ignored if present and not understood. The following points explain and justify the encoding choices described: 1. Formatting notes: 1.1 "rsub" needs to be in the "local-part": If the format just had routing-subdomain as the domain part of the acp-node- name, rsub and acp-domain-name could not be separated from each other to determine in the ACP domain membership check which part is the acp-domain-name and which is solely for creating a different ULA prefix. 1.2 If both "acp-address" and "rsub" are omitted from AcpNodeName, the "local-part" will have the format "++extension(s)". The two plus characters are necessary so the node can unambiguously parse that both "acp-address" and "rsub" are omitted. 2. The encoding of the ACP domain name and ACP address as described in this section is used for the following reasons: 2.1 The acp-node-name is the identifier of a node's ACP. It includes the necessary components to identify a node's ACP both from within the ACP as well as from the outside of the ACP. 2.2 For manual and/or automated diagnostics and backend management of devices and ACPs, it is necessary to have an easily human readable and software parsed standard, single string representation of the information in the acp-node- name. For example, inventory or other backend systems can always identify an entity by one unique string field but not by a combination of multiple fields, which would be necessary if there was no single string representation. 2.3 If the encoding was not that of such a string, it would be necessary to define a second standard encoding to provide this format (standard string encoding) for operator consumption. 2.4 Addresses of the form @ have become the preferred format for identifiers of entities in many systems, including the majority of user identification in web or mobile applications such as multi-domain single-sign- on systems. 3. Compatibilities: 3.1 It should be possible to use the ACP certificate as an LDevID certificate on the system for other uses beside the ACP. Therefore, the information element required for the ACP should be encoded so that it minimizes the possibility of creating incompatibilities with such other uses. The Eckert, et al. Expires 3 May 2021 [Page 28] Internet-Draft An Autonomic Control Plane (ACP) October 2020 attributes of the subject field for example are often used in non-ACP applications and should therefore not be occupied by new ACP values. 3.2 The element should not require additional ASN.1 en/decoding, because libraries to access certificate information especially for embedded devices may not support extended ASN.1 decoding beyond predefined, mandatory fields. subjectAltName / otherName is already used with a single string parameter for several otherNames (see [RFC3920], [RFC7585], [RFC4985], [RFC8398]). 3.3 The element required for the ACP should minimize the risk of being misinterpreted by other uses of the LDevID certificate. It also must not be misinterpreted to actually be an email address, hence the use of the otherName / rfc822Name option in the certificate would be inappropriate. See section 4.2.1.6 of [RFC5280] for details on the subjectAltName field. 6.2.2.1. AcpNodeName ASN.1 Module The following ASN.1 module normatively specifies the AcpNodeName structure. This specification uses the ASN.1 definitions from [RFC5912] with the 2002 ASN.1 notation used in that document. [RFC5912] updates normative documents using older ASN.1 notation. Eckert, et al. Expires 3 May 2021 [Page 29] Internet-Draft An Autonomic Control Plane (ACP) October 2020 ANIMA-ACP-2020 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-anima-acpnodename-2020(IANA1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS OTHER-NAME FROM PKIX1Implicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } id-pkix FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; id-on OBJECT IDENTIFIER ::= { id-pkix 8 } AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... } on-AcpNodeName OTHER-NAME ::= { AcpNodeName IDENTIFIED BY id-on-AcpNodeName } id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } AcpNodeName ::= IA5String (SIZE (1..MAX)) -- AcpNodeName as specified in this document carries the -- acp-node-name as specified in the ABNF in Section 6.1.2 END Figure 3 6.2.3. ACP domain membership check The following points constitute the ACP domain membership check of a candidate peer via its certificate: 1: The peer has proved ownership of the private key associated with the certificate's public key. This check is performed by the security association protocol used, for example [RFC7296], section 2.15. Eckert, et al. Expires 3 May 2021 [Page 30] Internet-Draft An Autonomic Control Plane (ACP) October 2020 2: The peer's certificate passes certificate path validation as defined in [RFC5280], section 6 against one of the TA associated with the ACP node's ACP certificate (see Section 6.2.4 below). This includes verification of the validity (lifetime) of the certificates in the path. 3: If the peer's certificate indicates a Certificate Revocation List (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or Online Certificate Status Protocol (OCSP) responder ([RFC5280], section 4.2.2.1), then the peer's certificate MUST be valid according to those mechanisms when they are available: An OCSP check for the peer's certificate across the ACP must succeed or the peer certificate must not be listed in the CRL retrieved from the CRLDP. These mechanisms are not available when the ACP node has no ACP or non-ACP connectivity to retrieve a current CRL or access an OCSP responder and the security association protocol itself has also no way to communicate CRL or OCSP check. Retries to learn revocation via OCSP/CRL SHOULD be made using the same backoff as described in Section 6.7. If and when the ACP node then learns that an ACP peer's certificate is invalid for which rule 3 had to be skipped during ACP secure channel establishment, then the ACP secure channel to that peer MUST be closed even if this peer is the only connectivity to access CRL/ OCSP. This applies (of course) to all ACP secure channels to this peer if there are multiple. The ACP secure channel connection MUST be retried periodically to support the case that the neighbor acquires a new, valid certificate. 4: The peer's certificate has a syntactically valid acp-node-name field and the acp-domain-name in that peer's acp-node-name is the same as in this ACP node's certificate (lowercase normalized). When checking a candidate peer's certificate for the purpose of establishing an ACP secure channel, one additional check is performed: 5: The acp-address field of the candidate peer certificate's AcpNodeName is not omitted but either 32HEXDIG or 0, according to Figure 2. Technically, ACP secure channels can only be built with nodes that have an acp-address. Rule 5 ensures that this is taken into account during ACP domain membership check. Nodes with an omitted acp-address field can only use their ACP domain certificate for non-ACP-secure channel authentication purposes. This includes for example NMS type nodes permitted to communicate into the ACP via ACP connect (Section 8.1) Eckert, et al. Expires 3 May 2021 [Page 31] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The special value 0 in an ACP certificates acp-address field is used for nodes that can and should determine their ACP address through other mechanisms than learning it through the acp-address field in their ACP certificate. These ACP nodes are permitted to establish ACP secure channels. Mechanisms for those nodes to determine their ACP address are outside the scope of this specification, but this option is defined here so that any ACP nodes can build ACP secure channels to them according to Rule 5. The optional rsub field of the AcpNodeName is not relevant to the ACP domain membership check because it only serves to structure routing and addressing within an ACP but not to segment mutual authentication/authorization (hence the name "routing subdomain"). In summary: * Steps 1...4 constitute standard certificate validity verification and private key authentication as defined by [RFC5280] and security association protocols (such as Internet Key Exchange Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. * Steps 1...4 do not include verification of any pre-existing form of non-public-key-only based identity elements of a certificate such as a web servers domain name prefix often encoded in certificate common name. Step 5 is an equivalent step for the AcpNodeName. * Step 4 constitutes standard CRL/OCSP checks refined for the case of missing connectivity and limited functionality security association protocols. * Steps 1...4 authorize to build any secure connection between members of the same ACP domain except for ACP secure channels. * Step 5 is the additional verification of the presence of an ACP address as necessary for ACP secure channels. * Steps 1...5 therefore authorize to build an ACP secure channel. For brevity, the remainder of this document refers to this process only as authentication instead of as authentication and authorization. [RFC-Editor: Please remove the following paragraph]. Note that the ACP domain membership check does not verify the network layer address of the security association. See [ACPDRAFT], Appendix B.2 for explanations. Eckert, et al. Expires 3 May 2021 [Page 32] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.2.3.1. Realtime clock and Time Validation An ACP node with a realtime clock in which it has confidence, MUST check the time stamps when performing ACP domain membership check such as the certificate validity period in step 1. and the respective times in step 4 for revocation information (e.g., signingTimes in CMS signatures). An ACP node without such a realtime clock MAY ignore those time stamp validation steps if it does not know the current time. Such an ACP node SHOULD obtain the current time in a secured fashion, such as via a Network Time Protocol signaled through the ACP. It then ignores time stamp validation only until the current time is known. In the absence of implementing a secured mechanism, such an ACP node MAY use a current time learned in an insecure fashion in the ACP domain membership check. Current time MAY for example be learned unsecured via NTP ([RFC5905]) over the same link-local IPv6 addresses used for the ACP from neighboring ACP nodes. ACP nodes that do provide NTP insecure over their link-local addresses SHOULD primarily run NTP across the ACP and provide NTP time across the ACP only when they have a trusted time source. Details for such NTP procedures are beyond the scope of this specification. Beside ACP domain membership check, the ACP itself has no dependency against knowledge of the current time, but protocols and services using the ACP will likely have the need to know the current time. For example, event logging. 6.2.4. Trust Anchors (TA) ACP nodes need TA information according to [RFC5280], section 6.1.1 (d), typically in the form of one or more certificate of the TA to perform certificate path validation as required by Section 6.2.3, rule 2. TA information MUST be provisioned to an ACP node (together with its ACP domain certificate) by an ACP Registrar during initial enrollment of a candidate ACP node. ACP nodes MUST also support renewal of TA information via EST as described below in Section 6.2.5. The required information about a TA can consist of not only a single, but multiple certificates as required for dealing with CA certificate renewals as explained in Section 4.4 of CMP ([RFC4210]). A certificate path is a chain of certificates starting at the ACP certificate (leaf/end-entity) followed by zero or more intermediate CA certificates and ending with the TA information, which are Eckert, et al. Expires 3 May 2021 [Page 33] Internet-Draft An Autonomic Control Plane (ACP) October 2020 typically one or two the self-signed certificates of the TA. The CA that signs the ACP certificate is called the assigning CA. If there are no intermediate CA, then the assigning CA is the TA. Certificate path validation authenticates that the ACP certificate is permitted by a TA associated with the ACP, directly or indirectly via one or more intermediate CA. Note that different ACP nodes may have different intermediate CA in their certificate path and even different TA. The set of TA for an ACP domain must be consistent across all ACP members so that any ACP node can authenticate any other ACP node. The protocols through which ACP domain membership check rules 1-3 are performed need to support the exchange not only of the ACP nodes certificates, but also exchange of the intermedia TA. ACP nodes MUST support for the ACP domain membership check the certificate path validation with 0 or 1 intermediate CA. They SHOULD support 2 intermediate CA and two TA (to permit migration to from one TA to another TA). Certificates for an ACP MUST only be given to nodes that are allowed to be members of that ACP. When the signing CA relies on an ACP Registrar, the CA MUST only sign certificates with acp-node-name through trusted ACP Registrars. In this setup, any existing CA, unaware of the formatting of acp-node-name, can be used. These requirements can be achieved by using a TA private to the owner of the ACP domain or potentially through appropriate contractual agreements between the involved parties (Registrar and CA). Using public CA is out of scope of this document. [RFC-Editor: please remove the following sentence]. See [ACPDRAFT], Appendix B.3 for further considerations. A single owner can operate multiple independent ACP domains from the same set of TA. Registrars must then know which ACP a node needs to be enrolled into. 6.2.5. Certificate and Trust Anchor Maintenance ACP nodes MUST support renewal of their Certificate and TA information via EST and MAY support other mechanisms. See Section 6.1 for TLS requirements. An ACP network MUST have at least one ACP node supporting EST server functionality across the ACP so that EST renewal is useable. ACP nodes SHOULD be able to remember the IPv6 locator parameters of the O_IPv6_LOCATOR in GRASP of the EST server from which they last renewed their ACP certificate. They SHOULD provide the ability for Eckert, et al. Expires 3 May 2021 [Page 34] Internet-Draft An Autonomic Control Plane (ACP) October 2020 these EST server parameters to also be set by the ACP Registrar (see Section 6.11.7) that initially enrolled the ACP device with its ACP certificate. When BRSKI (see [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of the BRSKI registrar from the BRSKI TLS connection SHOULD be remembered and used for the next renewal via EST if that registrar also announces itself as an EST server via GRASP (see next section) on its ACP address. The EST server MUST present a certificate that is passing ACP domain membership check in its TLS connection setup (Section 6.2.3, rules 1...4, not rule 5 as this is not for an ACP secure channel setup). The EST server certificate MUST also contain the id-kp-cmcRA [RFC6402] extended key usage attribute and the EST client MUST check its presence. The additional check against the id-kp-cmcRA extended key usage extension field ensures that clients do not fall prey to an illicit EST server. While such illicit EST servers should not be able to support certificate signing requests (as they are not able to elicit a signing response from a valid CA), such an illicit EST server would be able to provide faked CA certificates to EST clients that need to renew their CA certificates when they expire. Note that EST servers supporting multiple ACP domains will need to have for each of these ACP domains a separate certificate and respond on a different transport address (IPv6 address and/or TCP port), but this is easily automated on the EST server as long as the CA does not restrict registrars to request certificates with the id-kp-cmcRA extended usage extension for themselves. 6.2.5.1. GRASP objective for EST server ACP nodes that are EST servers MUST announce their service via GRASP in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], section 2.8.11 for the definition of this message type: Example: [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, [["SRV.est", 4, 255 ], [O_IPv6_LOCATOR, h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] ] Figure 4: GRASP SRV.est example Eckert, et al. Expires 3 May 2021 [Page 35] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The formal definition of the objective in Concise data definition language (CDDL) (see [RFC8610]) is as follows: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] ; see example above and explanation ; below for initiator and ttl objective = ["SRV.est", objective-flags, loop-count, objective-value] objective-flags = sync-only ; as in GRASP spec sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 255 ; recommended as there is no mechanism ; to discover network diameter. objective-value = any ; reserved for future extensions Figure 5: GRASP SRV.est definition The objective name "SRV.est" indicates that the objective is an [RFC7030] compliant EST server because "est" is an [RFC6335] registered service name for [RFC7030]. Objective-value MUST be ignored if present. Backward compatible extensions to [RFC7030] MAY be indicated through objective-value. Non [RFC7030] compatible certificate renewal options MUST use a different objective-name. Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored. The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds; the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds. The frequency of sending MUST be such that the aggregate amount of periodic M_FLOODs from all flooding sources cause only negligible traffic across the ACP. The time-to- live (ttl) parameter SHOULD be 3.5 times the period so that up to three consecutive messages can be dropped before considering an announcement expired. In the example above, the ttl is 210000 msec, 3.5 times 60 seconds. When a service announcer using these parameters unexpectedly dies immediately after sending the M_FLOOD, receivers would consider it expired 210 seconds later. When a receiver tries to connect to this dead service before this timeout, it will experience a failing connection and use that as an indication that the service instance is dead and select another instance of the same service instead (from another GRASP announcement). Eckert, et al. Expires 3 May 2021 [Page 36] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The "SRV.est" objective(s) SHOULD only be announced when the ACP node knows that it can successfully communicate with a CA to perform the EST renewal/rekeying operations for the ACP domain. See also Section 11. 6.2.5.2. Renewal When performing renewal, the node SHOULD attempt to connect to the remembered EST server. If that fails, it SHOULD attempt to connect to an EST server learned via GRASP. The server with which certificate renewal succeeds SHOULD be remembered for the next renewal. Remembering the last renewal server and preferring it provides stickiness which can help diagnostics. It also provides some protection against off-path compromised ACP members announcing bogus information into GRASP. Renewal of certificates SHOULD start after less than 50% of the domain certificate lifetime so that network operations has ample time to investigate and resolve any problems that causes a node to not renew its domain certificate in time - and to allow prolonged periods of running parts of a network disconnected from any CA. 6.2.5.3. Certificate Revocation Lists (CRLs) The ACP node SHOULD support revocation through CRL(s) via HTTP from one or more CRL Distribution Points (CRLDP). The CRLDP(s) MUST be indicated in the Domain Certificate when used. If the CRLDP URL uses an IPv6 address (ULA address when using the addressing rules specified in this document), the ACP node will connect to the CRLDP via the ACP. If the CRLDP uses a domain name, the ACP node will connect to the CRLDP via the Data-Plane. It is common to use domain names for CRLDP(s), but there is no requirement for the ACP to support DNS. Any DNS lookup in the Data- Plane is not only a possible security issue, but it would also not indicate whether the resolved address is meant to be reachable across the ACP. Therefore, the use of an IPv6 address versus the use of a DNS name doubles as an indicator whether or not to reach the CRLDP via the ACP. A CRLDP can be reachable across the ACP either by running it on a node with ACP or by connecting its node via an ACP connect interface (see Section 8.1). Eckert, et al. Expires 3 May 2021 [Page 37] Internet-Draft An Autonomic Control Plane (ACP) October 2020 When using a private PKI for ACP certificates, the CRL may be need- to-know, for example to prohibit insight into the operational practices of the domain by tracking the growth of the CRL. In this case, HTTPS may be chosen to provide confidentiality, especially when making the CRL available via the Data-Plane. Authentication and authorization SHOULD use ACP certificates and ACP domain membership check. The CRLDP MAY omit the CRL verification during authentication of the peer to permit retrieval of the CRL by an ACP node with revoked ACP certificate. This can allow for that (ex) ACP node to quickly discover its ACP certificate revocation. This may violate the desired need-to-know requirement though. ACP nodes MAY support CRLDP operations via HTTPS. 6.2.5.4. Lifetimes Certificate lifetime may be set to shorter lifetimes than customary (1 year) because certificate renewal is fully automated via ACP and EST. The primary limiting factor for shorter certificate lifetimes is load on the EST server(s) and CA. It is therefore recommended that ACP certificates are managed via a CA chain where the assigning CA has enough performance to manage short lived certificates. See also Section 9.2.4 for discussion about an example setup achieving this. See also [I-D.ietf-acme-star]. When certificate lifetimes are sufficiently short, such as few hours, certificate revocation may not be necessary, allowing to simplify the overall certificate maintenance infrastructure. See Appendix A.2 for further optimizations of certificate maintenance when BRSKI can be used ("Bootstrapping Remote Secure Key Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). 6.2.5.5. Re-enrollment An ACP node may determine that its ACP certificate has expired, for example because the ACP node was powered down or disconnected longer than its certificate lifetime. In this case, the ACP node SHOULD convert to a role of a re-enrolling candidate ACP node. In this role, the node does maintain the TA and certificate chain associated with its ACP certificate exclusively for the purpose of re-enrollment, and attempts (or waits) to get re-enrolled with a new ACP certificate. The details depend on the mechanisms/protocols used by the ACP Registrars. Eckert, et al. Expires 3 May 2021 [Page 38] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Please refer to Section 6.11.7 and [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP Registrars and vouchers as used in the following text. When ACP is intended to be used without BRSKI, the details about BRSKI and vouchers in the following text can be skipped. When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- enrolling candidate ACP node would attempt to enroll like a candidate ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID certificate, it SHOULD first attempt to use its ACP domain certificate in the BRSKI TLS authentication. The BRSKI registrar MAY honor this certificate beyond its expiration date purely for the purpose of re-enrollment. Using the ACP node's domain certificate allows the BRSKI registrar to learn that node's acp-node-name, so that the BRSKI registrar can re-assign the same ACP address information to the ACP node in the new ACP certificate. If the BRSKI registrar denies the use of the old ACP certificate, the re-enrolling candidate ACP node MUST re-attempt re-enrollment using its IDevID certificate as defined in BRSKI during the TLS connection setup. Both when the BRSKI connection is attempted with the old ACP certificate or the IDevID certificate, the re-enrolling candidate ACP node SHOULD authenticate the BRSKI registrar during TLS connection setup based on its existing TA certificate chain information associated with its old ACP certificate. The re-enrolling candidate ACP node SHOULD only fall back to requesting a voucher from the BRSKI registrar when this authentication fails during TLS connection setup. As a countermeasure against attacks that attempt to force the ACP node to forget its prior (expired) certificate and TA, the ACP node should alternate between attempting to re-enroll using its old keying material and attempting to re-enroll with its IDevID and requesting a voucher. When other mechanisms than BRSKI are used for ACP certificate enrollment, the principles of the re-enrolling candidate ACP node are the same. The re-enrolling candidate ACP node attempts to authenticate any ACP Registrar peers during re-enrollment protocol/ mechanisms via its existing certificate chain/TA information and provides its existing ACP certificate and other identification (such as the IDevID certificate) as necessary to the registrar. Maintaining existing TA information is especially important when enrollment mechanisms are used that unlike BRSKI do not leverage a mechanism (such as the voucher in BRSKI) to authenticate the ACP registrar and where therefore the injection of certificate failures could otherwise make the ACP node easily attackable remotely by Eckert, et al. Expires 3 May 2021 [Page 39] Internet-Draft An Autonomic Control Plane (ACP) October 2020 returning the ACP node to a "duckling" state in which it accepts to be enrolled by any network it connects to. The (expired) ACP certificate and ACP TA SHOULD therefore be maintained and attempted to be used as one possible credential for re-enrollment until new keying material is acquired. When using BRSKI or other protocol/mechanisms supporting vouchers, maintaining existing TA information allows for re-enrollment of expired ACP certificates to be more lightweight, especially in environments where repeated acquisition of vouchers during the lifetime of ACP nodes may be operationally expensive or otherwise undesirable. 6.2.5.6. Failing Certificates An ACP certificate is called failing in this document, if/when the ACP node to which the certificate was issued can determine that it was revoked (or explicitly not renewed), or in the absence of such explicit local diagnostics, when the ACP node fails to connect to other ACP nodes in the same ACP domain using its ACP certificate. For connection failures to determine the ACP certificate as the culprit, the peer should pass the domain membership check (Section 6.2.3) and other reasons for the connection failure can be excluded because of the connection error diagnostics. This type of failure can happen during setup/refresh of a secure ACP channel connections or any other use of the ACP certificate, such as for the TLS connection to an EST server for the renewal of the ACP domain certificate. Example reasons for failing certificates that the ACP node can only discover through connection failure are that the domain certificate or any of its signing certificates could have been revoked or may have expired, but the ACP node cannot self-diagnose this condition directly. Revocation information or clock synchronization may only be available across the ACP, but the ACP node cannot build ACP secure channels because ACP peers reject the ACP node's domain certificate. ACP nodes SHOULD support the option to determines whether its ACP certificate is failing, and when it does, put itself into the role of a re-enrolling candidate ACP node as explained above (Section 6.2.5.5). Eckert, et al. Expires 3 May 2021 [Page 40] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.3. ACP Adjacency Table To know to which nodes to establish an ACP channel, every ACP node maintains an adjacency table. The adjacency table contains information about adjacent ACP nodes, at a minimum: Node-ID (identifier of the node inside the ACP, see Section 6.11.3 and Section 6.11.5), interface on which neighbor was discovered (by GRASP as explained below), link-local IPv6 address of neighbor on that interface, certificate (including acp-node-name). An ACP node MUST maintain this adjacency table. This table is used to determine to which neighbor an ACP connection is established. Where the next ACP node is not directly adjacent (i.e., not on a link connected to this node), the information in the adjacency table can be supplemented by configuration. For example, the Node-ID and IP address could be configured. See Section 8.2. The adjacency table MAY contain information about the validity and trust of the adjacent ACP node's certificate. However, subsequent steps MUST always start with the ACP domain membership check against the peer (see Section 6.2.3). The adjacency table contains information about adjacent ACP nodes in general, independently of their domain and trust status. The next step determines to which of those ACP nodes an ACP connection should be established. 6.4. Neighbor Discovery with DULL GRASP [RFC-Editor: GRASP draft is in RFC editor queue, waiting for dependencies, including ACP. Please ensure that references to I- D.ietf-anima-grasp that include section number references (throughout this document) will be updated in case any last-minute changes in GRASP would make those section references change. Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of GRASP intended to operate across an insecure link-local scope. See section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition. The ACP uses one instance of DULL GRASP for every L2 interface of the ACP node to discover link level adjacent candidate ACP neighbors. Unless modified by policy as noted earlier (Section 5 bullet point 2.), native interfaces (e.g., physical interfaces on physical nodes) SHOULD be initialized automatically to a state in which ACP discovery can be performed and any native interfaces with ACP neighbors can then be brought into the ACP even if the interface is otherwise not configured. Reception of packets on such otherwise not configured interfaces MUST be limited so that at first only IPv6 StateLess Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work Eckert, et al. Expires 3 May 2021 [Page 41] Internet-Draft An Autonomic Control Plane (ACP) October 2020 and then only the following ACP secure channel setup packets - but not any other unnecessary traffic (e.g., no other link-local IPv6 transport stack responders for example). Note that the use of the IPv6 link-local multicast address (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to receive packets for that address. Otherwise DULL GRASP could fail to operate correctly in the presence of MLD snooping ([RFC4541]) switches that are not ACP supporting/enabled - because those switches would stop forwarding DULL GRASP packets. Switches not supporting MLD snooping simply need to operate as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. ACP discovery SHOULD NOT be enabled by default on non-native interfaces. In particular, ACP discovery MUST NOT run inside the ACP across ACP virtual interfaces. See Section 9.3 for further, non- normative suggestions on how to enable/disable ACP at node and interface level. See Section 8.2.2 for more details about tunnels (typical non-native interfaces). See Section 7 for how ACP should be extended on devices operating (also) as L2 bridges. Note: If an ACP node also implements BRSKI to enroll its ACP certificate (see Appendix A.2 for a summary), then the above considerations also apply to GRASP discovery for BRSKI. Each DULL instance of GRASP set up for ACP is then also used for the discovery of a bootstrap proxy via BRSKI when the node does not have a domain certificate. Discovery of ACP neighbors happens only when the node does have the certificate. The node therefore never needs to discover both a bootstrap proxy and ACP neighbor at the same time. An ACP node announces itself to potential ACP peers by use of the "AN_ACP" objective. This is a synchronization objective intended to be flooded on a single link using the GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of the Flood message, a locator consisting of a specific link-local IP address, IP protocol number and port number will be distributed with the flooded objective. An example of the message is informally: [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, [["AN_ACP", 4, 1, "IKEv2" ], [O_IPv6_LOCATOR, h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] [["AN_ACP", 4, 1, "DTLS" ], [O_IPv6_LOCATOR, h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] ] Eckert, et al. Expires 3 May 2021 [Page 42] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Figure 6: GRASP AN_ACP example The formal CDDL definition is: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["AN_ACP", objective-flags, loop-count, objective-value] objective-flags = sync-only ; as in the GRASP specification sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 1 ; limit to link-local operation objective-value = method-name / [ method, *extension ] method = method-name / [ method-name, *method-param ] method-name = "IKEv2" / "DTLS" / id extension = any method-param = any id = text .regexp "[A-Za-z@_$]([-.]*[A-Za-z0-9@_$])*" Figure 7: GRASP AN_ACP definition The objective-flags field is set to indicate synchronization. The loop-count is fixed at 1 since this is a link-local operation. In the above example the RECOMMENDED period of sending of the objective is 60 seconds. The indicated ttl of 210000 msec means that the objective would be cached by ACP nodes even when two out of three messages are dropped in transit. The session-id is a random number used for loop prevention (distinguishing a message from a prior instance of the same message). In DULL this field is irrelevant but has to be set according to the GRASP specification. The originator MUST be the IPv6 link local address of the originating ACP node on the sending interface. The method-name in the 'objective-value' parameter is a string indicating the protocol available at the specified or implied locator. It is a protocol supported by the node to negotiate a secure channel. IKEv2 as shown above is the protocol used to negotiate an IPsec secure channel. Eckert, et al. Expires 3 May 2021 [Page 43] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Method-params allows to carry method specific parameters. This specification does not define any method-param(s) for "IKEv2" or "DTLS". Method-params for these two methods that are not understood by an ACP node MUST be ignored by it. extension(s) allows to define method independent parameters. This specification does not define any extensions. Extensions not understood by an ACP node MUST be ignored by it. The locator-option is optional and only required when the secure channel protocol is not offered at a well-defined port number, or if there is no well-defined port number. IKEv2 is the actual protocol used to negotiate an Internet Protocol security architecture (IPsec) connection. GRASP therefore indicates "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has an IANA assigned port number 500, but in the above example, the candidate ACP neighbor is offering ACP secure channel negotiation via IKEv2 on port 15000 (purely to show through the example that GRASP allows to indicate the port number and it does not have to be the IANA assigned one). There is no default UDP port for DTLS, it is always locally assigned by the node. For further details about the "DTLS" secure channel protocol, see Section 6.8.4. If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 address MUST be the same as the initiator address (these are DULL requirements to minimize third party DoS attacks). The secure channel methods defined in this document use the objective-values of "IKEv2" and "DTLS". There is no distinction between IKEv2 native and GRE-IKEv2 because this is purely negotiated via IKEv2. A node that supports more than one secure channel protocol method needs to flood multiple versions of the "AN_ACP" objective so that each method can be accompanied by its own locator-option. This can use a single GRASP M_FLOOD message as shown in Figure 6. The use of DULL GRASP primarily serves to discover the link-local IPv6 address of candidate ACP peers on subnets. The signaling of the supported secure channel option is primarily for diagnostic purposes, but it is also necessary for discovery when the protocol has no well- known transport address, such as in the case of DTLS. [RFC-Editor: Please remove the following sentence]. See [ACPDRAFT], Appendix B.4. Eckert, et al. Expires 3 May 2021 [Page 44] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Note that a node serving both as an ACP node and BRSKI Join Proxy may choose to distribute the "AN_ACP" objective and the respective BRSKI in the same M_FLOOD message, since GRASP allows multiple objectives in one message. This may be impractical though if ACP and BRSKI operations are implemented via separate software modules / ASAs. The result of the discovery is the IPv6 link-local address of the neighbor as well as its supported secure channel protocols (and non- standard port they are running on). It is stored in the ACP Adjacency Table (see Section 6.3), which then drives the further building of the ACP to that neighbor. Note that the DULL GRASP objective described intentionally does not include the ACP node's ACP certificate even though this would be useful for diagnostics and to simplify the security exchange in ACP secure channel security association protocols (see Section 6.8). The reason is that DULL GRASP messages are periodically multicasted across IPv6 subnets and full certificates could easily lead to fragmented IPv6 DULL GRASP multicast packets due to the size of a certificate. This would be highly undesirable. 6.5. Candidate ACP Neighbor Selection An ACP node determines to which other ACP nodes in the adjacency table it should attempt to build an ACP connection. This is based on the information in the ACP Adjacency table. The ACP is established exclusively between nodes in the same domain. This includes all routing subdomains. Appendix A.6 explains how ACP connections across multiple routing subdomains are special. The result of the candidate ACP neighbor selection process is a list of adjacent or configured autonomic neighbors to which an ACP channel should be established. The next step begins that channel establishment. 6.6. Channel Selection To avoid attacks, initial discovery of candidate ACP peers cannot include any non-protected negotiation. To avoid re-inventing and validating security association mechanisms, the next step after discovering the address of a candidate neighbor can only be to try first to establish a security association with that neighbor using a well-known security association method. From the use-cases it seems clear that not all type of ACP nodes can or need to connect directly to each other or are able to support or prefer all possible mechanisms. For example, code space limited IoT Eckert, et al. Expires 3 May 2021 [Page 45] Internet-Draft An Autonomic Control Plane (ACP) October 2020 devices may only support DTLS because that code exists already on them for end-to-end security, but low-end in-ceiling L2 switches may only want to support Media Access Control Security (MacSec, see 802.1AE ([MACSEC]) because that is also supported in their chips. Only a flexible gateway device may need to support both of these mechanisms and potentially more. Note that MacSec is not required by any profiles of the ACP in this specification. Instead, MacSec is mentioned as a likely next interesting secure channel protocol. Note also that the security model allows and requires for any-to-any authentication and authorization between all ACP nodes because there is also end-to-end and not only hop-by-hop authentication for secure channels. To support extensible secure channel protocol selection without a single common mandatory to implement (MTI) protocol, ACP nodes MUST try all the ACP secure channel protocols it supports and that are feasible because the candidate ACP neighbor also announced them via its AN_ACP GRASP parameters (these are called the "feasible" ACP secure channel protocols). To ensure that the selection of the secure channel protocols always succeeds in a predictable fashion without blocking, the following rules apply: * An ACP node may choose to attempt to initiate the different feasible ACP secure channel protocols it supports according to its local policies sequentially or in parallel, but it MUST support acting as a responder to all of them in parallel. * Once the first ACP secure channel protocol connection to a specific peer IPv6 address passes peer authentication, the two peers know each other's certificate because those ACP certificates are used by all secure channel protocols for mutual authentication. The peer with the higher Node-ID in the AcpNodeName of its ACP certificate takes on the role of the Decider towards the peer. The other peer takes on the role of the Follower. The Decider selects which secure channel protocol to ultimately use. * The Follower becomes passive: it does not attempt to further initiate ACP secure channel protocol connections with the Decider and does not consider it to be an error when the Decider closes secure channels. The Decider becomes the active party, continues to attempt setting up secure channel protocols with the Follower. This process terminates when the Decider arrives at the "best" ACP secure channel connection option that also works with the Follower ("best" from the Deciders point of view). * A peer with a "0" acp-address in its AcpNodeName takes on the role of Follower when peering with a node that has a non-"0" acp- address (note that this specification does not fully define the Eckert, et al. Expires 3 May 2021 [Page 46] Internet-Draft An Autonomic Control Plane (ACP) October 2020 behavior of ACP secure channel negotiation for nodes with a "0" ACP address field, it only defines interoperability with such ACP nodes). In a simple example, ACP peer Node 1 attempts to initiate an IPsec via IKEv2 connection to peer Node 2. The IKEv2 authentication succeeds. Node 1 has the lower ACP address and becomes the Follower. Node 2 becomes the Decider. IKEv2 might not be the preferred ACP secure channel protocol for the Decider Node 2. Node 2 would therefore proceed to attempt secure channel setups with (in its view) more preferred protocol options (e.g., DTLS/UDP). If any such preferred ACP secure channel connection of the Decider succeeds, it would close the IPsec connection. If Node 2 has no preferred protocol option over IPsec, or no such connection attempt from Node 2 to Node 1 succeeds, Node 2 would keep the IPsec connection and use it. The Decider SHOULD NOT send actual payload packets across a secure channel until it has decided to use it. The Follower MAY delay linking the ACP secure channel into the ACP virtual interface until it sees the first payload packet from the Decider up to a maximum of 5 seconds to avoid unnecessarily linking a secure channel that will be terminated as undesired by the Decider shortly afterwards. The following sequence of steps show this example in more detail. Each step is tagged with [{:}]. The connection is included to more easily distinguish which of the two competing connections the step belongs to, one initiated by Node 1, one initiated by Node 2. Eckert, et al. Expires 3 May 2021 [Page 47] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [1] Node 1 sends GRASP AN_ACP message to announce itself [2] Node 2 sends GRASP AN_ACP message to announce itself [3] Node 2 receives [1] from Node 1 [4:C1] Because of [3], Node 2 starts as initiator on its preferred secure channel protocol towards Node 1. Connection C1. [5] Node 1 receives [2] from Node 2 [6:C2] Because of [5], Node 1 starts as initiator on its preferred secure channel protocol towards Node 2. Connection C2. [7:C1] Node1 and Node2 have authenticated each others certificate on connection C1 as valid ACP peers. [8:C1] Node 1 certificate has lower ACP Node-ID than Node2, therefore Node 1 considers itself the Follower and Node 2 the Decider on connection C1. Connection setup C1 is completed. [9] Node 1 refrains from attempting any further secure channel connections to Node 2 (the Decider) as learned from [2] because it knows from [8:C1] that it is the Follower relative to Node 1. [10:C2] Node1 and Node2 have authenticated each others certificate on connection C2 (like [7:C1]). [11:C2] Node 1 certificate has lower ACP Node-ID than Node2, therefore Node 1 considers itself the Follower and Node 2 the Decider on connection C2, but they also identify that C2 is to the same mutual peer as their C1, so this has no further impact: the roles Decider and Follower where already assigned between these two peers by [8:C1]. [12:C2] Node 2 (the Decider) closes C1. Node 1 is fine with this, because of its role as the Follower (from [8:C1]). [13] Node 2 (the Decider) and Node 1 (the Follower) start data transfer across C2, which makes it become a secure channel for the ACP. Figure 8: Secure Channel sequence of steps Eckert, et al. Expires 3 May 2021 [Page 48] Internet-Draft An Autonomic Control Plane (ACP) October 2020 All this negotiation is in the context of an "L2 interface". The Decider and Follower will build ACP connections to each other on every "L2 interface" that they both connect to. An autonomic node MUST NOT assume that neighbors with the same L2 or link-local IPv6 addresses on different L2 interfaces are the same node. This can only be determined after examining the certificate after a successful security association attempt. The Decider SHOULD NOT suppress attempting a particular ACP secure channel protocol connection on one L2 interface because this type of ACP secure channel connection has failed to the peer with the same ACP certificate on another L2 interface: Not only the supported ACP secure channel protocol options may be different on the same ACP peer across different L2 interfaces, but also error conditions may cause inconsistent failures across different L2 interfaces. Avoiding such connection attempt optimizations can therefore help to increase robustness in the case of errors. 6.7. Candidate ACP Neighbor verification Independent of the security association protocol chosen, candidate ACP neighbors need to be authenticated based on their domain certificate. This implies that any secure channel protocol MUST support certificate based authentication that can support the ACP domain membership check as defined in Section 6.2.3. If it fails, the connection attempt is aborted and an error logged. Attempts to reconnect MUST be throttled. The RECOMMENDED default is exponential base 2 backoff with an initial retransmission time (IRT) of 10 seconds and a maximum retransmission time (MRT) of 640 seconds. Failure to authenticate an ACP neighbor when acting in the role of a responder of the security authentication protocol MUST NOT impact the attempts of the ACP node to attempt establishing a connection as an initiator. Only failed connection attempts as an initiator must cause throttling. This rule is meant to increase resilience of secure channel creation. Section 6.6 shows how simultaneous mutual secure channel setup collisions are resolved. 6.8. Security Association (Secure Channel) protocols This section describes how ACP nodes establish secured data connections to automatically discovered or configured peers in the ACP. Section 6.4 above described how IPv6 subnet adjacent peers are discovered automatically. Section 8.2 describes how non IPv6 subnet adjacent peers can be configured. Eckert, et al. Expires 3 May 2021 [Page 49] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Section 6.13.5.2 describes how secure channels are mapped to virtual IPv6 subnet interfaces in the ACP. The simple case is to map every ACP secure channel into a separate ACP point-to-point virtual interface Section 6.13.5.2.1. When a single subnet has multiple ACP peers this results in multiple ACP point-to-point virtual interfaces across that underlying multi-party IPv6 subnet. This can be optimized with ACP multi-access virtual interfaces (Section 6.13.5.2.2) but the benefits of that optimization may not justify the complexity of that option. 6.8.1. General considerations Due to Channel Selection (Section 6.6), ACP can support an evolving set of security association protocols and does not require support for a single network wide MTI. ACP nodes only need to implement those protocols required to interoperate with their candidate peers, not with potentially any node in the ACP domain. See Section 6.8.5 for an example of this. The degree of security required on every hop of an ACP network needs to be consistent across the network so that there is no designated "weakest link" because it is that "weakest link" that would otherwise become the designated point of attack. When the secure channel protection on one link is compromised, it can be used to send/receive packets across the whole ACP network. Therefore, even though the security association protocols can be different, their minimum degree of security should be comparable. Secure channel protocols do not need to always support arbitrary L3 connectivity between peers, but can leverage the fact that the standard use case for ACP secure channels is an L2 adjacency. Hence, L2 dependent mechanisms could be adopted for use as secure channel association protocols: L2 mechanisms such as strong encrypted radio technologies or [MACSEC] may offer equivalent encryption and the ACP security association protocol may only be required to authenticate ACP domain membership of a peer and/or derive a key for the L2 mechanism. Mechanisms to auto-discover and associate ACP peers leveraging such underlying L2 security are possible and desirable to avoid duplication of encryption, but none are specified in this document. Strong physical security of a link may stand in where cryptographic security is infeasible. As there is no secure mechanism to automatically discover strong physical security solely between two peers, it can only be used with explicit configuration and that configuration too could become an attack vector. This document therefore only specifies with ACP connect (Section 8.1) one Eckert, et al. Expires 3 May 2021 [Page 50] Internet-Draft An Autonomic Control Plane (ACP) October 2020 explicitly configured mechanism without any secure channel association protocol - for the case where both the link and the nodes attached to it have strong physical security. 6.8.2. Common requirements The authentication of peers in any security association protocol MUST use the ACP certificate according to Section 6.2.3. Because auto- discovery of candidate ACP neighbors via GRASP (see Section 6.4) as specified in this document does not communicate the neighbors ACP certificate, and ACP nodes may not (yet) have any other network connectivity to retrieve certificates, any security association protocol MUST use a mechanism to communicate the certificate directly instead of relying on a referential mechanism such as communicating only a hash and/or URL for the certificate. A security association protocol MUST use Forward Secrecy (whether inherently or as part of a profile of the security association protocol). Because the ACP payload of legacy protocol payloads inside the ACP and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP secure channel protocol requires confidentiality. Symmetric encryption for the transmission of secure channel data MUST use encryption schemes considered to be security wise equal to or better than 256-bit key strength, such as AES256. There MUST NOT be support for NULL encryption. Security association protocols typically only signal the End Entity certificate (e.g. the ACP certificate) and any possible intermediate CA certificates for successful mutual authentication. The TA has to be mutually known and trusted and therefore its certificate does not need to be signaled for successful mutual authentication. Nevertheless, for use with ACP secure channel setup, there SHOULD be the option to include the TA certificate in the signaling to aid troubleshooting, see Section 9.1.1. Signaling of TA certificates may not be appropriate when the deployment is relying on a security model where the TA certificate content is considered confidential and only its hash is appropriate for signaling. ACP nodes SHOULD have a mechanism to select whether the TA certificate is signaled or not. Assuming that both options are possible with a specific secure channel protocol. An ACP secure channel MUST immediately be terminated when the lifetime of any certificate in the chain used to authenticate the neighbor expires or becomes revoked. This may not be standard behavior in secure channel protocols because the certificate Eckert, et al. Expires 3 May 2021 [Page 51] Internet-Draft An Autonomic Control Plane (ACP) October 2020 authentication may only influence the setup of the secure channel in these protocols, but may not be re-validated during the lifetime of the secure connection in the absence of this requirement. When specifying an additional security association protocol for ACP secure channels beyond those covered in this document, protocol options SHOULD be eliminated that are not necessary to support devices that are expected to be able to support the ACP to minimize implementation complexity. For example, definitions for security protocols often include old/inferior security options required only to interoperate with existing devices that will not be able to update to the currently preferred security options. Such old/inferior security options do not need to be supported when a security association protocol is first specified for the ACP, strengthening the "weakest link" and simplifying ACP implementation overhead. 6.8.3. ACP via IPsec An ACP node announces its ability to support IPsec, negotiated via IKEv2, as the ACP secure channel protocol using the "IKEv2" objective-value in the "AN_ACP" GRASP objective. The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set of options of the current standards-track usage guidance for IPsec [RFC8221] and IKEv2 [RFC8247]. These option result in stringent security properties and can exclude deprecated/legacy algorithms because there is no need for interoperability with legacy equipment for ACP secure channels. Any such backward compatibility would lead only to increased attack surface and implementation complexity, for no benefit. 6.8.3.1. Native IPsec An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41). It MUST use local and peer link-local IPv6 addresses for encapsulation. Manual keying MUST NOT be used, see Section 6.2. Traffic Selectors are: TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) Eckert, et al. Expires 3 May 2021 [Page 52] Internet-Draft An Autonomic Control Plane (ACP) October 2020 IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure channels, and not only its own generated ACP packets. With IPsec transport mode (and no additional encapsulation header in the ESP payload), it would only be possible to send packets originated by the ACP node itself because the IPv6 addresses of the ESP must be the same as that of the outer IPv6 header. 6.8.3.1.1. RFC8221 (IPsec/ESP) ACP IPsec implementations MUST comply with [RFC8221] (and its updates). The requirements from above and this section amend and superseded its requirements. The IP Authentication Header (AH) MUST NOT be used (because it does not provide confidentiality). For the required ESP encryption algorithms in section 5 of [RFC8221] the following guidance applies: * ENCR_NULL AH MUST NOT be used (because it does not provide confidentiality). * ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP via IPsec/ESP (it is already listed as MUST in [RFC8221]). * ENCR_AES_CBC with AUTH_HMAC_SHA2_256_128 (as the ESP authentication algorithm) and ENCR_AES_CCM_8 MAY be supported. If either provides higher performance than ENCR_AES_GCM_16 it SHOULD be supported. * ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher performance than ENCR_AES_GCM_16. If that performance is not feasible, it MAY be supported. IKEv2 indicates an order for the offered algorithms. The algorithms SHOULD be ordered by performance. The first algorithm supported by both sides is generally chosen. Explanations: * There is no requirement to interoperate with legacy equipment in ACP secure channels, so a single MTI encryption algorithm for IPsec in ACP secure channels is sufficient for interoperability and allows for the most lightweight implementations. * ENCR_AES_GCM_16 is an authenticated encryption with associated data (AEAD) cipher mode, so no additional ESP authentication algorithm is needed, simplifying the MTI requirements of IPsec for the ACP. Eckert, et al. Expires 3 May 2021 [Page 53] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * There is no MTI requirement for the support of ENCR_AES_CBC because ENCR_AES_GCM_16 is assumed to be feasible with less cost/ higher performance in modern devices hardware accelerated implementations compared to ENCR-AES_CBC. * ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its target use as a fallback algorithm in case weaknesses in AES are uncovered. Unfortunately, there is currently no way to automatically propagate across an ACP a policy to disallow use of AES based algorithms, so this target benefit of ENCR_CHACHA20_POLY1305 cannot fully be adopted yet for the ACP. Therefore, this algorithm is only recommended. Changing from AES to this algorithm at potentially big drop in performance could also render the ACP inoperable. Therefore, the performance requirement against this algorithm so that it could become an effective security backup to AES for the ACP once a policy to switch over to it or prefer it is available in an ACP framework. [RFC8221] allows for 128-bit or 256-bit AES keys. This document mandates that only 256-bit AES keys MUST be supported. When [RFC8221] is updated, ACP implementations will need to consider legacy interoperability, and the IPsec WG has generally done a very good job of taking that into account in its recommendations. 6.8.3.1.2. RFC8247 (IKEv2) [RFC8247] provides a baseline recommendation for mandatory to implement ciphers, integrity checks, pseudo-random-functions and Diffie-Hellman mechanisms. Those recommendations, and the recommendations of subsequent documents apply well to the ACP. Because IKEv2 for ACP secure channels is sufficient to be implemented in control plane software, rather than in ASIC hardware, and ACP nodes supporting IKEv2 are not assumed to be code-space constrained, and because existing IKEv2 implementations are expected to support [RFC8247] recommendations, this documents makes no attempt to simplify its recommendations for use with the ACP. See [IKEV2IANA] for IANA IKEv2 parameter names used in this text. ACP Nodes supporting IKEv2 MUST comply with [RFC8247] amended by the following requirements which constitute a policy statement as permitted by [RFC8247]. To signal the ACP certificate chain (including TA) as required by Section 6.8.2, "X.509 Certificate - Signature" payload in IKEv2 can be used. It is mandatory according to [RFC7296] section 3.6. Eckert, et al. Expires 3 May 2021 [Page 54] Internet-Draft An Autonomic Control Plane (ACP) October 2020 ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA when acting as an IKEv2 responder on the IPv6 link local address and port number indicated in the AN_ACP DULL GRASP announcements (see Section 6.4). When CERTREQ is received from a peer, and does not indicate any of this ACP nodes TA certificates, the ACP node SHOULD ignore the CERTREQ and continue sending its certificate chain including its TA as subject to the requirements and explanations in Section 6.8.2. This will not result in successful mutual authentication but assists diagnostics. Note that with IKEv2, failing authentication will only result in the responder receiving the certificate chain from the initiator, but not vice versa. Because ACP secure channel setup is symmetric (see Section 6.7), every non-malicious ACP neighbor will attempt to connect as an initiator though, allowing to obtain the diagnostic information about the neighbors certificate. In IKEv2, ACP nodes are identified by their ACP address. The ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST convey the ACP address. If the peer's ACP certificate includes a 32HEXDIG ACP address in the acp-node-name (not "0" or omitted), the address in the IKEv2 identification payload MUST match it. See Section 6.2.3 for more information about "0" or omitted ACP address fields in the acp-node-name. IKEv2 authentication MUST use authentication method 14 ("Digital Signature") for ACP certificates; this authentication method can be used with both RSA and ECDSA certificates, indicated by an ASN.1 object AlgorithmIdentifier. The Digital Signature hash SHA2-512 MUST be supported (in addition to SHA2-256). The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), MUST be supported. Reason: ECC provides a similar security level to finite-field (MODP) key exchange with a shorter key length, so is generally preferred absent other considerations. 6.8.3.2. IPsec with GRE encapsulation In network devices it is often more common to implement high performance virtual interfaces on top of GRE encapsulation than on top of a "native" IPsec association (without any other encapsulation than those defined by IPsec). On those devices it may be beneficial to run the ACP secure channel on top of GRE protected by the IPsec association. Eckert, et al. Expires 3 May 2021 [Page 55] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The requirements for ESP/IPsec/IKEv2 with GRE are the same as for native IPsec (see Section 6.8.3.1) except that IPsec transport mode and next protocol GRE (47) are to be negotiated. Tunnel mode is not required because of GRE. Traffic Selectors are: TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-IPv6-LL- addr) TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- addr) If IKEv2 initiator and responder support IPsec over GRE, it will be preferred over native IPsec because of the way how IKEv2 negotiates transport mode (as used by this IPsec over GRE profile) versus tunnel mode as used by native IPsec (see [RFC7296], section 1.3.1). The ACP IPv6 traffic has to be carried across GRE according to [RFC7676]. 6.8.4. ACP via DTLS This document defines the use of ACP via DTLS, on the assumption that it is likely the first transport encryption supported in some classes of constrained devices: DTLS is commonly used in constrained devices when IPsec is not. Code-space on those devices may be also be too limited to support more than the minimum number of required protocols. An ACP node announces its ability to support DTLS version 1.2 ([RFC6347]) compliant with the requirements defined in this document as an ACP secure channel protocol in GRASP through the "DTLS" objective-value in the "AN_ACP" objective (see Section 6.4). To run ACP via UDP and DTLS, a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors. This port can also be any newer version of DTLS as long as that version can negotiate a DTLS v1.2 connection in the presence of an DTLS v1.2 only peer. All ACP nodes supporting DTLS as a secure channel protocol MUST adhere to the DTLS implementation recommendations and security considerations of BCP 195, BCP 195 [RFC7525] except with respect to the DTLS version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST NOT support older versions of DTLS. Eckert, et al. Expires 3 May 2021 [Page 56] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Unlike for IPsec, no attempts are made to simplify the requirements of the BCP 195 recommendations because the expectation is that DTLS would be using software-only implementations where the ability to reuse of widely adopted implementations is more important than minimizing the complexity of a hardware accelerated implementation which is known to be important for IPsec. DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS v1.2 (see section 1. of DTLS v1.3). A DTLS implementation supporting both DTLS v1.2 and DTLS v1.3 does comply with the above requirements of negotiating to DTLS v1.2 in the presence of a DTLS v1.2 only peer, but using DTLS v1.3 when booth peers support it. Version v1.2 is the MTI version of DTLS in this specification because * There is more experience with DTLS v1.2 across the spectrum of target ACP nodes. * Firmware of lower end, embedded ACP nodes may not support a newer version for a long time. * There are significant changes of DTLS v1.3, such as a different record layer requiring time to gain implementation and deployment experience especially on lower end, code space limited devices. * The existing BCP [RFC7525] for DTLS v1.2 may equally take longer time to be updated with experience from a newer DTLS version. * There are no significant use-case relevant benefits of DTLS v1.3 over DTLS v1.2 in the context of the ACP options for DTLS. For example, signaling performance improvements for session setup in DTLS v1.3 is not important for the ACP given the long-lived nature of ACP secure channel connections and the fact that DTLS connections are mostly link-local (short RTT). Nevertheless, newer versions of DTLS, such as DTLS v1.3 have stricter security requirements and use of the latest standard protocol version is for IETF security standards in general recommended. Therefore, ACP implementations are advised to support all the newer versions of DTLS that can still negotiate down to DTLS v1.2. [RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to be an RFC, then not only would the references to the DTLS v1.3 draft be changed to the RFC number, but that RFC is then going to be put into the normative list of references and the above paragraph is going to be amended to say: Implementations SHOULD support [DTLSv1.3-RFC]. This is not done right now, because there is no benefit in potentially waiting in RFC-editor queue for that RFC given how the text already lays out a non-normative desire to support DTLSv1.3.] Eckert, et al. Expires 3 May 2021 [Page 57] Internet-Draft An Autonomic Control Plane (ACP) October 2020 There is no additional session setup or other security association besides this simple DTLS setup. As soon as the DTLS session is functional, the ACP peers will exchange ACP IPv6 packets as the payload of the DTLS transport connection. oAny DTLS defined security association mechanisms such as re-keying are used as they would be for any transport application relying solely on DTLS. 6.8.5. ACP Secure Channel Profiles As explained in the beginning of Section 6.6, there is no single secure channel mechanism mandated for all ACP nodes. Instead, this section defines two ACP profiles (baseline and constrained) for ACP nodes that do introduce such requirements. An ACP node supporting the "baseline" profile MUST support IPsec natively and MAY support IPsec via GRE. An ACP node supporting the "constrained" profile node that cannot support IPsec MUST support DTLS. An ACP node connecting an area of constrained ACP nodes with an area of baseline ACP nodes needs to support IPsec and DTLS and supports therefore the baseline and constrained profile. Explanation: Not all type of ACP nodes can or need to connect directly to each other or are able to support or prefer all possible secure channel mechanisms. For example, code space limited IoT devices may only support DTLS because that code exists already on them for end-to-end security, but high-end core routers may not want to support DTLS because they can perform IPsec in accelerated hardware but would need to support DTLS in an underpowered CPU forwarding path shared with critical control plane operations. This is not a deployment issue for a single ACP across these type of nodes as long as there are also appropriate gateway ACP nodes that support sufficiently many secure channel mechanisms to allow interconnecting areas of ACP nodes with a more constrained set of secure channel protocols. On the edge between IoT areas and high-end core networks, general-purpose routers that act as those gateways and that can support a variety of secure channel protocols is the norm already. IPsec natively with tunnel mode provides the shortest encapsulation overhead. GRE may be preferred by legacy implementations because the virtual interfaces required by ACP design in conjunction with secure channels have in the past more often been implemented for GRE than purely for native IPsec. ACP nodes need to specify in documentation the set of secure ACP mechanisms they support and should declare which profile they support according to above requirements. Eckert, et al. Expires 3 May 2021 [Page 58] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.9. GRASP in the ACP 6.9.1. GRASP as a core service of the ACP The ACP MUST run an instance of GRASP inside of it. It is a key part of the ACP services. The function in GRASP that makes it fundamental as a service of the ACP is the ability to provide ACP wide service discovery (using objectives in GRASP). ACP provides IP unicast routing via the RPL routing protocol (see Section 6.12). The ACP does not use IP multicast routing nor does it provide generic IP multicast services (the handling of GRASP link-local multicast messages is explained in Section 6.9.2). Instead, the ACP provides service discovery via the objective discovery/announcement and negotiation mechanisms of the ACP GRASP instance (services are a form of objectives). These mechanisms use hop-by-hop reliable flooding of GRASP messages for both service discovery (GRASP M_DISCOVERY messages) and service announcement (GRASP M_FLOOD messages). See Appendix A.5 for discussion about this design choice of the ACP. 6.9.2. ACP as the Security and Transport substrate for GRASP In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the security and transport substrate for the GRASP instance run inside the ACP ("ACP GRASP"). This means that the ACP is responsible for ensuring that this instance of GRASP is only sending messages across the ACP GRASP virtual interfaces. Whenever the ACP adds or deletes such an interface because of new ACP secure channels or loss thereof, the ACP needs to indicate this to the ACP instance of GRASP. The ACP exists also in the absence of any active ACP neighbors. It is created when the node has a domain certificate, and continues to exist even if all of its neighbors cease operation. In this case ASAs using GRASP running on the same node would still need to be able to discover each other's objectives. When the ACP does not exist, ASAs leveraging the ACP instance of GRASP via APIs MUST still be able to operate, and MUST be able to understand that there is no ACP and that therefore the ACP instance of GRASP cannot operate. The following explanation how ACP acts as the security and transport substrate for GRASP is visualized in Figure 9 below. Eckert, et al. Expires 3 May 2021 [Page 59] Internet-Draft An Autonomic Control Plane (ACP) October 2020 GRASP unicast messages inside the ACP always use the ACP address. Link-local addresses from the ACP VRF MUST NOT be used inside objectives. GRASP unicast messages inside the ACP are transported via TLS. See Section 6.1 for TLS requirements. TLS mutual authentication MUST use the ACP domain membership check defined in (Section 6.2.3). GRASP link-local multicast messages are targeted for a specific ACP virtual interface (as defined Section 6.13.5) but are sent by the ACP into an ACP GRASP virtual interface that is constructed from the TCP connection(s) to the IPv6 link-local neighbor address(es) on the underlying ACP virtual interface. If the ACP GRASP virtual interface has two or more neighbors, the GRASP link-local multicast messages are replicated to all neighbor TCP connections. TCP and TLS connections for GRASP in the ACP use the IANA assigned TCP port for GRASP (7107). Effectively the transport stack is expected to be TLS for connections from/to the ACP address (e.g., global scope address(es)) and TCP for connections from/to link-local addresses on the ACP virtual interfaces. The latter ones are only used for flooding of GRASP messages. Eckert, et al. Expires 3 May 2021 [Page 60] Internet-Draft An Autonomic Control Plane (ACP) October 2020 ..............................ACP.............................. . . . /-GRASP-flooding-\ ACP GRASP instance . . / \ A . GRASP GRASP GRASP C . link-local unicast link-local P . multicast messages multicast . . messages | messages . . | | | . ............................................................... . v v v ACP security and transport . . | | | substrate for GRASP . . | | | . . | ACP GRASP | - ACP GRASP A . | Loopback | Loopback interface C . | interface | - ACP-cert auth P . | TLS | . . ACP GRASP | ACP GRASP - ACP GRASP virtual . . subnet1 | subnet2 virtual interfaces . . TCP | TCP . . | | | . ............................................................... . | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ACP interfaces/addressing . . | | | . . | | | A . | ACP-Loopback Interf.| <- ACP Loopback interface C . | ACP-address | - address (global ULA) P . subnet1 | subnet2 <- ACP virtual interfaces . . link-local | link-local - link-local addresses . ............................................................... . | | | ACP VRF . . | RPL-routing | virtual routing and forwarding . . | /IP-Forwarding\ | A . | / \ | C . ACP IPv6 packets ACP IPv6 packets P . |/ \| . . IPsec/DTLS IPsec/DTLS - ACP-cert auth . ............................................................... | | Data-Plane | | | | - ACP secure channel link-local link-local - encapsulation addresses subnet1 subnet2 - Data-Plane interfaces | | ACP-Nbr1 ACP-Nbr2 Figure 9: ACP as security and transport substrate for GRASP Eckert, et al. Expires 3 May 2021 [Page 61] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.9.2.1. Discussion TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local messages is used because these messages are flooded across potentially many hops to all ACP nodes and a single link with even temporary packet loss issues (e.g., WiFi/Powerline link) can reduce the probability for loss free transmission so much that applications would want to increase the frequency with which they send these messages. Such shorter periodic retransmission of datagrams would result in more traffic and processing overhead in the ACP than the hop-by-hop reliable retransmission mechanism by TCP and duplicate elimination by GRASP. TLS is mandated for GRASP non-link-local unicast because the ACP secure channel mandatory authentication and encryption protects only against attacks from the outside but not against attacks from the inside: Compromised ACP members that have (not yet) been detected and removed (e.g., via domain certificate revocation / expiry). If GRASP peer connections were to use just TCP, compromised ACP members could simply eavesdrop passively on GRASP peer connections for whom they are on-path ("man in the middle" - MITM) or intercept and modify them. With TLS, it is not possible to completely eliminate problems with compromised ACP members, but attacks are a lot more complex: Eavesdropping/spoofing by a compromised ACP node is still possible because in the model of the ACP and GRASP, the provider and consumer of an objective have initially no unique information (such as an identity) about the other side which would allow them to distinguish a benevolent from a compromised peer. The compromised ACP node would simply announce the objective as well, potentially filter the original objective in GRASP when it is a MITM and act as an application level proxy. This of course requires that the compromised ACP node understand the semantics of the GRASP negotiation to an extent that allows it to proxy it without being detected, but in an ACP environment this is quite likely public knowledge or even standardized. The GRASP TLS connections are run the same as any other ACP traffic through the ACP secure channels. This leads to double authentication/encryption, which has the following benefits: * Secure channel methods such as IPsec may provide protection against additional attacks, for example reset-attacks. * The secure channel method may leverage hardware acceleration and there may be little or no gain in eliminating it. Eckert, et al. Expires 3 May 2021 [Page 62] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * There is no different security model for ACP GRASP from other ACP traffic. Instead, there is just another layer of protection against certain attacks from the inside which is important due to the role of GRASP in the ACP. 6.10. Context Separation The ACP is in a separate context from the normal Data-Plane of the node. This context includes the ACP channels' IPv6 forwarding and routing as well as any required higher layer ACP functions. In classical network system, a dedicated VRF is one logical implementation option for the ACP. If possible by the systems software architecture, separation options that minimize shared components are preferred, such as a logical container or virtual machine instance. The context for the ACP needs to be established automatically during bootstrap of a node. As much as possible it should be protected from being modified unintentionally by ("Data- Plane") configuration. Context separation improves security, because the ACP is not reachable from the Data-Plane routing or forwarding table(s). Also, configuration errors from the Data-Plane setup do not affect the ACP. 6.11. Addressing inside the ACP The channels explained above typically only establish communication between two adjacent nodes. In order for communication to happen across multiple hops, the autonomic control plane requires ACP network wide valid addresses and routing. Each ACP node creates a Loopback interface with an ACP network wide unique address (prefix) inside the ACP context (as explained in in Section 6.10). This address may be used also in other virtual contexts. With the algorithm introduced here, all ACP nodes in the same routing subdomain have the same /48 ULA prefix. Conversely, ULA global IDs from different domains are unlikely to clash, such that two ACP networks can be merged, as long as the policy allows that merge. See also Section 10.1 for a discussion on merging domains. Links inside the ACP only use link-local IPv6 addressing, such that each node's ACP only requires one routable address prefix. 6.11.1. Fundamental Concepts of Autonomic Addressing * Usage: Autonomic addresses are exclusively used for self- management functions inside a trusted domain. They are not used for user traffic. Communications with entities outside the Eckert, et al. Expires 3 May 2021 [Page 63] Internet-Draft An Autonomic Control Plane (ACP) October 2020 trusted domain use another address space, for example normally managed routable address space (called "Data-Plane" in this document). * Separation: Autonomic address space is used separately from user address space and other address realms. This supports the robustness requirement. * Loopback-only: Only ACP Loopback interfaces (and potentially those configured for "ACP connect", see Section 8.1) carry routable address(es); all other interfaces (called ACP virtual interfaces) only use IPv6 link local addresses. The usage of IPv6 link local addressing is discussed in [RFC7404]. * Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1 (as defined in section 3.1 of [RFC4193]). Note that the random hash for ACP Loopback addresses uses the definition in Section 6.11.2 and not the one of [RFC4193] section 3.2.2. * No external connectivity: They do not provide access to the Internet. If a node requires further reaching connectivity, it should use another, traditionally managed address scheme in parallel. * Addresses in the ACP are permanent, and do not support temporary addresses as defined in [RFC4941]. * Addresses in the ACP are not considered sensitive on privacy grounds because ACP nodes are not expected to be end-user hosts and ACP addresses do therefore not represent end-users or groups of end-users. All ACP nodes are in one (potentially federated) administrative domain. They are assumed to be to be candidate hosts of ACP traffic amongst each other or transit thereof. There are no transit nodes less privileged to know about the identity of other hosts in the ACP. Therefore, ACP addresses do not need to be pseudo-random as discussed in [RFC7721]. Because they are not propagated to untrusted (non ACP) nodes and stay within a domain (of trust), we also consider them not to be subject to scanning attacks. The ACP is based exclusively on IPv6 addressing, for a variety of reasons: * Simplicity, reliability and scale: If other network layer protocols were supported, each would have to have its own set of security associations, routing table and process, etc. * Autonomic functions do not require IPv4: Autonomic functions and autonomic service agents are new concepts. They can be exclusively built on IPv6 from day one. There is no need for backward compatibility. * OAM protocols do not require IPv4: The ACP may carry OAM protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIUS, Diameter, NETCONF ...) are available in IPv6. See also [RFC8368] for how ACP could be made to interoperate with IPv4 only OAM. Eckert, et al. Expires 3 May 2021 [Page 64] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Further explanation about the addressing and routing related reasons for the choice of the autonomous ACP addressing can be found in Section 6.13.5.1. 6.11.2. The ACP Addressing Base Scheme The Base ULA addressing scheme for ACP nodes has the following format: 8 40 2 78 +--+-------------------------+------+------------------------------+ |fd| hash(routing-subdomain) | Type | (sub-scheme) | +--+-------------------------+------+------------------------------+ Figure 10: ACP Addressing Base Scheme The first 48-bits follow the ULA scheme, as defined in [RFC4193], to which a type field is added: * "fd" identifies a locally defined ULA address. * The 40-bits ULA "global ID" (term from [RFC4193]) for ACP addresses carried in the acp-node-name in the ACP certificates are the first 40-bits of the SHA256 hash of the routing subdomain from the same acp-node-name. In the example of Section 6.2.2, the routing subdomain is "area51.research.acp.example.com" and the 40-bits ULA "global ID" 89b714f3db. * When creating a new routing-subdomain for an existing autonomic network, it MUST be ensured, that rsub is selected so the resulting hash of the routing-subdomain does not collide with the hash of any pre-existing routing-subdomains of the autonomic network. This ensures that ACP addresses created by registrars for different routing subdomains do not collide with each other. * To allow for extensibility, the fact that the ULA "global ID" is a hash of the routing subdomain SHOULD NOT be assumed by any ACP node during normal operations. The hash function is only executed during the creation of the certificate. If BRSKI is used, then the BRSKI registrar will create the acp-node-name in response to the EST Certificate Signing Request (CSR) Attribute Request message by the pledge. Eckert, et al. Expires 3 May 2021 [Page 65] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * Establishing connectivity between different ACP (different acp- domain-name) is outside the scope of this specification. If it is being done through future extensions, then the rsub of all routing-subdomains across those autonomic networks need to be selected so the resulting routing-subdomain hashes do not collide. For example, a large cooperation with its own private TA may want to create different autonomic networks that initially should not be able to connect but where the option to do so should be kept open. When taking this future possibility into account, it is easy to always select rsub so that no collisions happen. * Type: This field allows different address sub-schemes. This addresses the "upgradability" requirement. Assignment of types for this field will be maintained by IANA. The sub-scheme may imply a range or set of addresses assigned to the node, this is called the ACP address range/set and explained in each sub-scheme. Please refer to Section 6.11.7 and Appendix A.1 for further explanations why the following Sub-Addressing schemes are used and why multiple are necessary. The following summarizes the addressing Sub-Schemes: +------+-----------------+-----------+-------------------+ | Type | Name |F-bit| Z | V-bits | Prefix | +------+-----------------+-----+-----+----------+--------+ | 0x00 | ACP-Zone | N/A | 0 | 1 bit | /127 | +------+-----------------+-----+-----+----------+--------+ | 0x00 | ACP-Manual | N/A | 1 | N/A | /64 | +------+-----------------+-----+-----+----------+--------+ | 0x01 | ACP-VLong-8 | 0 | N/A | 8 bits | /120 | +------+-----------------+-----+-----+----------+--------+ | 0x01 | ACP-VLong-16 | 1 | N/A | 16 bits | /112 | +------+-----------------+-----+-----+----------+--------+ | 0x10 | Reserved / For future definition/allocation | +------+-----------------+-----+-----+----------+--------+ | 0x11 | Reserved / For future definition/allocation | +------+-----------------+-----+-----+----------+--------+ Figure 11: Addressing Sub-Schemes F-Bit and Z are two encoding fields explained below for the Sub- Schemes that introduce/use them. V-bits is the number of bits of addresses allocated to the ACP node. Prefix is the prefix the ACP node is announcing into the RPL routing protocol. Eckert, et al. Expires 3 May 2021 [Page 66] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) This sub-scheme is used when the Type field of the base scheme is 0x00 and the Z bit is 0x0. 64 64 +-----------------+---+---------++-----------------------------+---+ | (base scheme) | Z | Zone-ID || Node-ID | | | | || Registrar-ID | Node-Number| V | +-----------------+---+---------++--------------+--------------+---+ 50 1 13 48 15 1 Figure 12: ACP Zone Addressing Sub-Scheme The fields are defined as follows: * Type: MUST be 0x0. * Z: MUST be 0x0. * Zone-ID: A value for a network zone. * Node-ID: A unique value for each node. The 64-bit Node-ID must be unique across the ACP domain for each node. It is derived and composed as follows: * Registrar-ID (48-bit): A number unique inside the domain that identifies the ACP registrar which assigned the Node-ID to the node. One or more domain-wide unique identifiers of the ACP registrar can be used for this purpose. See Section 6.11.7.2. * Node-Number: Number to make the Node-ID unique. This can be sequentially assigned by the ACP Registrar owning the Registrar- ID. * V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP node base system); 1: Indicates the optional "host" context on the ACP node (see below). In the ACP Zone Addressing Sub-Scheme, the ACP address in the certificate has V field as all zero bits. The ACP address set of the node includes addresses with any Zone-ID value and any V value. No two nodes in the same ACP can have the same Node-ID, but different Zone-IDs. The Virtual bit in this sub-scheme allows the easy addition of the ACP as a component to existing systems without causing problems in the port number space between the services in the ACP and the existing system. V:0 is the ACP router (autonomic node base system), V:1 is the host with pre-existing transport endpoints on it that Eckert, et al. Expires 3 May 2021 [Page 67] Internet-Draft An Autonomic Control Plane (ACP) October 2020 could collide with the transport endpoints used by the ACP router. The ACP host could for example have a p2p virtual interface with the V:0 address as its router into the ACP. Depending on the software design of ASAs, which is outside the scope of this specification, they may use the V:0 or V:1 address. The location of the V bit(s) at the end of the address allows the announcement of a single prefix for each ACP node. For example, in a network with 20,000 ACP nodes, this avoid 20,000 additional routes in the routing table. It is RECOMMENDED that only Zone-ID 0 is used unless it is meant to be used in conjunction with operational practices for partial/ incremental adoption of the ACP as described in Section 9.4. Note: Zones and Zone-ID as defined here are not related to [RFC4007] zones or zone_id. ACP zone addresses are not scoped (reachable only from within an RFC4007 zone) but reachable across the whole ACP. An RFC4007 zone_id is a zone index that has only local significance on a node, whereas an ACP Zone-ID is an identifier for an ACP zone that is unique across that ACP. 6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) This sub-scheme is used when the Type field of the base scheme is 0x00 and the Z bit is 0x1. 64 64 +---------------------+---+----------++-----------------------------+ | (base scheme) | Z | Subnet-ID|| Interface Identifier | +---------------------+---+----------++-----------------------------+ 50 1 13 Figure 13: ACP Manual Addressing Sub-Scheme The fields are defined as follows: * Type: MUST be 0x0. * Z: MUST be 0x1. * Subnet-ID: Configured subnet identifier. * Interface Identifier. This sub-scheme is meant for "manual" allocation to subnets where the other addressing schemes cannot be used. The primary use case is for assignment to ACP connect subnets (see Section 8.1.1). Eckert, et al. Expires 3 May 2021 [Page 68] Internet-Draft An Autonomic Control Plane (ACP) October 2020 "Manual" means that allocations of the Subnet-ID need to be done today with pre-existing, non-autonomic mechanisms. Every subnet that uses this addressing sub-scheme needs to use a unique Subnet-ID (unless some anycast setup is done). The Z bit field was added to distinguish Zone addressing and manual addressing sub-schemes without requiring one more bit in the base scheme and therefore allowing for the Vlong scheme (described below) to have one more bit available. Manual addressing sub-scheme addresses SHOULD NOT be used in ACP certificates. Any node capable to build ACP secure channels and permitted by Registrar policy to participate in building ACP secure channels SHOULD receive an ACP address (prefix) from one of the other ACP addressing sub-schemes. Nodes not capable (or permitted) to participate in ACP secure channels can connect to the ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), without setting up an ACP secure channel. Their ACP certificate MUST omit the acp-address field to indicate that their ACP certificate is only usable for non- ACP secure channel authentication, such as end-to-end transport connections across the ACP or Data-Plane. Address management of ACP connect subnets is done using traditional assignment methods and existing IPv6 protocols. See Section 8.1.3 for details. Therefore, the notion of V-bit many addresses assigned to the ACP nodes does not apply to this Sub-Scheme. 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 This sub-scheme is used when the Type field of the base scheme is 0x01. 50 78 +---------------------++-----------------------------+----------+ | (base scheme) || Node-ID | | || Registrar-ID |F| Node-Number| V | +---------------------++--------------+--------------+----------+ 50 46 1 23/15 8/16 Figure 14: ACP Vlong Addressing Sub-Scheme This addressing scheme foregoes the Zone-ID field to allow for larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) different virtualized addresses within a node, which could be used to address individual software components in an ACP node. Eckert, et al. Expires 3 May 2021 [Page 69] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The fields are the same as in the Zone-ID sub-scheme with the following refinements: * F: format bit. This bit determines the format of the subsequent bits. * V: Virtualization bit: this is a field that is either 8 or 16 bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits are assigned by the ACP node. In the ACP certificate's ACP address Section 6.2.2, the V-bits are always set to 0. * Registrar-ID: To maximize Node-Number and V, the Registrar-ID is reduced to 46-bits. One or more domain-wide unique identifiers of the ACP registrar can be used for this purpose. See Section 6.11.7.2. * The Node-Number is unique to each ACP node. There are two formats for the Node-Number. When F=0, the node-number is 23 bits, for F=1 it is 15 bits. Each format of node-number is considered to be in a unique number space. The F=0 bit format addresses are intended to be used for "general purpose" ACP nodes that would potentially have a limited number (< 256) of clients (ASA/Autonomic Functions or legacy services) of the ACP that require separate V(irtual) addresses. The F=1 bit Node-Numbers are intended for ACP nodes that are ACP edge nodes (see Section 8.1.1) or that have a large number of clients requiring separate V(irtual) addresses. For example, large SDN controllers with container modular software architecture (see Section 8.1.2). In the Vlong addressing sub-scheme, the ACP address in the certificate has all V field bits as zero. The ACP address set for the node includes any V value. 6.11.6. Other ACP Addressing Sub-Schemes Before further addressing sub-schemes are defined, experience with the schemes defined here should be collected. The schemes defined in this document have been devised to allow hopefully sufficiently flexible setup of ACPs for a variety of situation. These reasons also lead to the fairly liberal use of address space: The Zone Addressing Sub-Scheme is intended to enable optimized routing in large networks by reserving bits for Zone-ID's. The Vlong addressing sub-scheme enables the allocation of 8/16-bit of addresses inside individual ACP nodes. Both address spaces allow distributed, uncoordinated allocation of node addresses by reserving bits for the registrar-ID field in the address. Eckert, et al. Expires 3 May 2021 [Page 70] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.11.7. ACP Registrars ACP registrars are responsible to enroll candidate ACP nodes with ACP certificates and associated trust anchor(s). They are also responsible that an acp-node-name field is included in the ACP certificate carrying the ACP domain name and the ACP nodes ACP address prefix. This address prefix is intended to persist unchanged through the lifetime of the ACP node. Because of the ACP addressing sub-schemes, an ACP domain can have multiple distributed ACP registrars that do not need to coordinate for address assignment. ACP registrars can also be sub-CAs, in which case they can also assign ACP certificates without dependencies against a (shared) TA (except during renewals of their own certificates). ACP registrars are PKI registration authorities (RA) enhanced with the handling of the ACP certificate specific fields. They request certificates for ACP nodes from a Certification Authority through any appropriate mechanism (out of scope in this document, but required to be BRSKI for ANI registrars). Only nodes that are trusted to be compliant with the requirements against registrar described in this section can be given the necessary credentials to perform this RA function, such as credentials for the BRSKI connection to the CA for ANI registrars. 6.11.7.1. Use of BRSKI or other Mechanism/Protocols Any protocols or mechanisms may be used by ACP registrars, as long as the resulting ACP certificate and TA certificate(s) allow to perform the ACP domain membership described in Section 6.2.3 with other ACP domain members, and meet the ACP addressing requirements for its acp- node-name as described further below in this section. An ACP registrar could be a person deciding whether to enroll a candidate ACP node and then orchestrating the enrollment of the ACP certificate and associated TA, using command line or web based commands on the candidate ACP node and TA to generate and sign the ACP certificate and configure certificate and TA onto the node. The only currently defined protocol for ACP registrars is BRSKI ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the ACP nodes are called ANI nodes, and the ACP registrars are called BRSKI or ANI registrars. The BRSKI specification does not define the handling of the acp-node-name field because the rules do not depend on BRSKI but apply equally to any protocols/mechanisms an ACP registrar may use. Eckert, et al. Expires 3 May 2021 [Page 71] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.11.7.2. Unique Address/Prefix allocation ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes via the acp-node-name that would collide with the ACP address prefixes of other ACP nodes in the same ACP domain. This includes both prefixes allocated by the same ACP registrar to different ACP nodes as well as prefixes allocated by other ACP registrars for the same ACP domain. To support such unique address allocation, an ACP registrar MUST have one or more 46-bit identifiers unique across the ACP domain which is called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP registrar can happen through OAM mechanisms in conjunction with some database / allocation orchestration. ACP registrars running on physical devices with known globally unique EUI-48 MAC address(es) can use the lower 46 bits of those address(es) as unique Registrar-IDs without requiring any external signaling/ configuration (the upper two bits, V and U are not uniquely assigned but functional). This approach is attractive for distributed, non- centrally administered, lightweight ACP registrar implementations. There is no mechanism to deduce from a MAC address itself whether it is actually uniquely assigned. Implementations need to consult additional offline information before making this assumption. For example by knowing that a particular physical product/MIC-chip is guaranteed to use globally unique assigned EUI-48 MAC address(es). When the candidate ACP device (called Pledge in BRSKI) is to be enrolled into an ACP domain, the ACP registrar needs to allocate a unique ACP address to the node and ensure that the ACP certificate gets a acp-node-name field (Section 6.2.2) with the appropriate information - ACP domain-name, ACP-address, and so on. If the ACP registrar uses BRSKI, it signals the ACP acp-node-name field to the Pledge via the EST /csrattrs command (see [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR Attributes"). [RFC-Editor: please update reference to section 5.9.2 accordingly with latest BRSKI draft at time of publishing, or RFC] 6.11.7.3. Addressing Sub-Scheme Policies The ACP registrar selects for the candidate ACP node a unique address prefix from an appropriate ACP addressing sub-scheme, either a zone addressing sub-scheme prefix (see Section 6.11.3), or a Vlong addressing sub-scheme prefix (see Section 6.11.5). The assigned ACP address prefix encoded in the acp-node-name field of the ACP certificate indicates to the ACP node its ACP address information. Eckert, et al. Expires 3 May 2021 [Page 72] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The sub-addressing scheme indicates the prefix length: /127 for zone address sub-scheme, /120 or /112 for Vlong address sub-scheme. The first address of the prefix is the ACP address. All other addresses in the prefix are for other uses by the ACP node as described in the zone and Vlong addressing sub scheme sections. The ACP address prefix itself is then signaled by the ACP node into the ACP routing protocol (see Section 6.12) to establish IPv6 reachability across the ACP. The choice of addressing sub-scheme and prefix-length in the Vlong address sub-scheme is subject to ACP registrar policy. It could be an ACP domain wide policy, or a per ACP node or per ACP node type policy. For example, in BRSKI, the ACP registrar is aware of the IDevID certificate of the candidate ACP node, which typically contains a "serialNumber" attribute in the subject field distinguished name encoding that is often indicating the node's vendor and device type and can be used to drive a policy selecting an appropriate addressing sub-scheme for the (class of) node(s). ACP registrars SHOULD default to allocate ACP zone sub-address scheme addresses with Zone-ID 0. ACP registrars that are aware of the IDevID certificate of a candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- address scheme for ACP nodes based on the [X.520] "serialNumber" attribute in the subject field distinguished name encoding of the IDevID certificate, for example by the PID (Product Identifier) part which identifies the product type, or the complete "serialNumber". The PID for example could identify nodes that allow for specialized ASA requiring multiple addresses or non-autonomic VMs for services and those nodes could receive Vlong sub-address scheme ACP addresses. In a simple allocation scheme, an ACP registrar remembers persistently across reboots its currently used Registrar-ID and for each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong with /120), the next Node-Number available for allocation and increases it during successful enrollment to an ACP node. In this simple allocation scheme, the ACP registrar would not recycle ACP address prefixes from no longer used ACP nodes. Eckert, et al. Expires 3 May 2021 [Page 73] Internet-Draft An Autonomic Control Plane (ACP) October 2020 If allocated addresses cannot be remembered by registrars, then it is necessary to either use a new value for the Register-ID field in the ACP addresses, or determine allocated ACP addresses from determining the addresses of reachable ACP nodes, which is not necessarily the set of all ACP nodes. Non-tracked ACP addresses can be reclaimed by revoking or not renewing their certificates and instead handing out new certificate with new addresses (for example with a new Registrar- ID value). Note that such strategies may require coordination amongst registrars. 6.11.7.4. Address/Prefix Persistence When an ACP certificate is renewed or rekeyed via EST or other mechanisms, the ACP address/prefix in the acp-node-name field MUST be maintained unless security issues or violations of the unique address assignment requirements exist or are suspected by the ACP registrar. ACP address information SHOULD be maintained even when the renewing/ rekeying ACP registrar is not the same as the one that enrolled the prior ACP certificate. See Section 9.2.4 for an example. ACP address information SHOULD also be maintained even after an ACP certificate did expire or failed. See Section 6.2.5.5 and Section 6.2.5.6. 6.11.7.5. Further Details Section 9.2 discusses further informative details of ACP registrars: What interactions registrars need, what parameters they require, certificate renewal and limitations, use of sub-CAs on registrars and centralized policy control. 6.12. Routing in the ACP Once ULA address are set up all autonomic entities should run a routing protocol within the autonomic control plane context. This routing protocol distributes the ULA created in the previous section for reachability. The use of the autonomic control plane specific context eliminates the probable clash with Data-Plane routing tables and also secures the ACP from interference from the configuration mismatch or incorrect routing updates. The establishment of the routing plane and its parameters are automatic and strictly within the confines of the autonomic control plane. Therefore, no explicit configuration is required. Eckert, et al. Expires 3 May 2021 [Page 74] Internet-Draft An Autonomic Control Plane (ACP) October 2020 All routing updates are automatically secured in transit as the channels of the ACP are encrypted, and this routing runs only inside the ACP. The routing protocol inside the ACP is RPL ([RFC6550]). See Appendix A.4 for more details on the choice of RPL. RPL adjacencies are set up across all ACP channels in the same domain including all its routing subdomains. See Appendix A.6 for more details. 6.12.1. ACP RPL Profile The following is a description of the RPL profile that ACP nodes need to support by default. The format of this section is derived from [I-D.ietf-roll-applicability-template]. 6.12.1.1. Overview RPL Packet Information (RPI) defined in [RFC6550], section 11.2 defines the data packet artefacts required or beneficial in forwarding of packets routed by RPL. This profile does not use RPI for better compatibility with accelerated hardware forwarding planes which most often does not support the Hop-by-Hop headers used for RPI, but also to avoid the overhead of the RPI header on the wire and cost of adding/removing them. 6.12.1.1.1. Single Instance To avoid the need for RPI, the ACP RPL profile uses a simple destination prefix based routing/forwarding table. To achieve this, the profiles uses only one RPL instanceID. This single instanceID can contain only one Destination Oriented Directed Acyclic Graph (DODAG), and the routing/forwarding table can therefore only calculate a single class of service ("best effort towards the primary NOC/root") and cannot create optimized routing paths to accomplish latency or energy goals between any two nodes. This choice is a compromise. Consider a network that has multiple NOCs in different locations. Only one NOC will become the DODAG root. Traffic to and from other NOCs has to be sent through the DODAG (shortest path tree) rooted in the primary NOC. Depending on topology, this can be an annoyance from a latency point of view or from minimizing network path resources, but this is deemed to be acceptable given how ACP traffic is "only" network management/control traffic. See Appendix A.9.4 for more details. Eckert, et al. Expires 3 May 2021 [Page 75] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Using a single instanceID/DODAG does not introduce a single point of failure, as the DODAG will reconfigure itself when it detects Data- Plane forwarding failures including choosing a different root when the primary one fails. The benefit of this profile, especially compared to other IGPs is that it does not calculate routes for node reachable through the same interface as the DODAG root. This RPL profile can therefore scale to much larger number of ACP nodes in the same amount of compute and memory than other routing protocols. Especially on nodes that are leafs of the topology or those close to those leafs. 6.12.1.1.2. Reconvergence In RPL profiles where RPL Packet Information (RPI, see Section 6.12.1.13) is present, it is also used to trigger reconvergence when misrouted, for example looping, packets are recognized because of their RPI data. This helps to minimize RPL signaling traffic especially in networks without stable topology and slow links. The ACP RPL profile instead relies on quick reconverging the DODAG by recognizing link state change (down/up) and triggering reconvergence signaling as described in Section 6.12.1.7. Since links in the ACP are assumed to be mostly reliable (or have link layer protection against loss) and because there is no stretch according to Section 6.12.1.7, loops caused by loss of RPL routing protocol signaling packets should be exceedingly rare. In addition, there are a variety of mechanisms possible in RPL to further avoid temporary loops RECOMMENDED to be used for the ACPL RPL profile: DODAG Information Objects (DIOs) SHOULD be sent 2 or 3 times to inform children when losing the last parent. The technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2.2.5., (Poisoning) because it allows local connectivity. Nodes SHOULD select more than one parent, at least 3 if possible, and send Destination Advertisement Objects (DAO)s to all of them in parallel. Additionally, failed ACP tunnels can be quickly discovered trough the secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. This can function as a replacement for a Low-power and Lossy Networks' (LLN's) Expected Transmission Count (ETX) feature that is not used in this profile. A failure of an ACP tunnel should immediately signal the RPL control plane to pick a different parent. Eckert, et al. Expires 3 May 2021 [Page 76] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.12.1.2. RPL Instances Single RPL instance. Default RPLInstanceID = 0. 6.12.1.3. Storing vs. Non-Storing Mode RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of Operations with no multicast support". Implementations MAY support mode 3 ("... with multicast support" as that is a superset of mode 2). Note: Root indicates mode in DIO flow. 6.12.1.4. DAO Policy Proactive, aggressive DAO state maintenance: * Use K-flag in unsolicited DAO indicating change from previous information (to require DAO-ACK). * Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) in between. 6.12.1.5. Path Metric Use Hopcount according to [RFC6551]. Note that this is solely for diagnostic purposes as it is not used by the objective function. 6.12.1.6. Objective Function Objective Function (OF): Use OF0 [RFC6552]. No use of metric containers. rank_factor: Derived from link speed: <= 100Mbps: LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) This is a simple rank differentiation between typical "low speed" or "IoT" links that commonly max out at 100 Mbps and typical infrastructure links with speeds of 1 Gbps or higher. Given how the path selection for the ACP focusses only on reachability but not on path cost optimization, no attempts at finer grained path optimization are made. 6.12.1.7. DODAG Repair Global Repair: we assume stable links and ranks (metrics), so there is no need to periodically rebuild the DODAG. The DODAG version is only incremented under catastrophic events (e.g., administrative action). Eckert, et al. Expires 3 May 2021 [Page 77] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Local Repair: As soon as link breakage is detected, the ACP node send No-Path DAO for all the targets that were reachable only via this link. As soon as link repair is detected, the ACP node validates if this link provides a better parent. If so, a new rank is computed by the ACP node and it sends new DIO that advertise the new rank. Then it sends a DAO with a new path sequence about itself. When using ACP multi-access virtual interfaces, local repair can be triggered directly by peer breakage, see Section 6.13.5.2.2. stretch_rank: none provided ("not stretched"). Data Path Validation: Not used. Trickle: Not used. 6.12.1.8. Multicast Not used yet but possible because of the selected mode of operations. 6.12.1.9. Security [RFC6550] security not used, substituted by ACP security. Because the ACP links already include provisions for confidentiality and integrity protection, their usage at the RPL layer would be redundant, and so RPL security is not used. 6.12.1.10. P2P communications Not used. 6.12.1.11. IPv6 address configuration Every ACP node (RPL node) announces an IPv6 prefix covering the addresses assigned to the ACP node via the AcpNodeName. The prefix length depends on the addressing sub-scheme of the acp-address, /127 for Zone Addressing Sub-Scheme and /112 or /120 for Vlong addressing sub-scheme. See Section 6.11 for more details. Eckert, et al. Expires 3 May 2021 [Page 78] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Every ACP node MUST install a black hole (aka null) route if there are unused parts of the ACP address space assigned to the ACP node via its AcpNodeName. This is superseded by longer prefixes assigned to interfaces for the address space actually used by the node. For example, when the node has an ACP-VLong-8 address space, it installs a /120 black hole route. If it then for example only uses the ACP address (first address from the space), it would assign that address via a /128 address prefix to the ACP loopback interface (see Section 6.13.5.1). None of those longer prefixes are announced into RPL. For ACP-Manual address prefixes configured on an ACP node, for example for ACP connect subnets (see Section 8.1.1), the node announces the /64 subnet prefix. 6.12.1.12. Administrative parameters Administrative Preference ([RFC6550], 3.2.6 - to become root): Indicated in DODAGPreference field of DIO message. * Explicit configured "root": 0b100 * ACP registrar (Default): 0b011 * ACP-connect (non-registrar): 0b010 * Default: 0b001. 6.12.1.13. RPL Packet Information RPI is not required in the ACP RPL profile for the following reasons. One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which is not necessary because the ACP RPL profile uses storing mode where each hop has the necessary next-hop forwarding information. The simpler RPL Option header [RFC6553] is also not necessary in this profile, because it uses a single RPL instance and data path validation is also not used. 6.12.1.14. Unknown Destinations Because RPL minimizes the size of the routing and forwarding table, prefixes reachable through the same interface as the RPL root are not known on every ACP node. Therefore, traffic to unknown destination addresses can only be discovered at the RPL root. The RPL root SHOULD have attach safe mechanisms to operationally discover and log such packets. Eckert, et al. Expires 3 May 2021 [Page 79] Internet-Draft An Autonomic Control Plane (ACP) October 2020 As this requirement places additional constraints on the Data-Plane functionality of the RPL root, it does not apply to "normal" nodes that are not configured to have special functionality (i.e., the administrative parameter from Section 6.12.1.12 has value 0b001). If the ACP network is degraded to the point where there are no nodes that could be configured as root, registrar, or ACP-connect nodes, it is possible that the RPL root (and thus the ACP as a whole) would be unable to detect traffic to unknown destinations. However, in the absence of nodes with administrative preference other than 0b001, there is also unlikely to be a way to get diagnostic information out of the ACP, so detection of traffic to unknown destinations would not be actionable anyway. 6.13. General ACP Considerations Since channels are by default established between adjacent neighbors, the resulting overlay network does hop-by-hop encryption. Each node decrypts incoming traffic from the ACP, and encrypts outgoing traffic to its neighbors in the ACP. Routing is discussed in Section 6.12. 6.13.1. Performance There are no performance requirements against ACP implementations defined in this document because the performance requirements depend on the intended use case. It is expected that full autonomic node with a wide range of ASA can require high forwarding plane performance in the ACP, for example for telemetry. Implementations of ACP to solely support traditional/SDN style use cases can benefit from ACP at lower performance, especially if the ACP is used only for critical operations, e.g., when the Data-Plane is not available. The design of the ACP as specified in this document is intended to support a wide range of performance options: It is intended to allow software-only implementations at potentially low performance, but can also support high performance options. See [RFC8368] for more details. 6.13.2. Addressing of Secure Channels In order to be independent of the Data-Plane routing and addressing, the GRASP discovered ACP secure channels use IPv6 link local addresses between adjacent neighbors. Note: Section 8.2 specifies extensions in which secure channels are configured tunnels operating over the Data-Plane, so those secure channels cannot be independent of the Data-Plane. To avoid that Data-Plane configuration can impact the operations of the IPv6 (link-local) interface/address used for ACP channels, appropriate implementation considerations are required. If the IPv6 Eckert, et al. Expires 3 May 2021 [Page 80] Internet-Draft An Autonomic Control Plane (ACP) October 2020 interface/link-local address is shared with the Data-Plane, it needs to be impossible to unconfigure/disable it through configuration. Instead of sharing the IPv6 interface/link-local address, a separate (virtual) interface with a separate IPv6 link-local address can be used. For example, the ACP interface could be run over a separate MAC address of an underlying L2 (Ethernet) interface. For more details and options, see Appendix A.9.2. Note that other (non-ideal) implementation choices may introduce additional undesired dependencies against the Data-Plane. For example, shared code and configuration of the secure channel protocols (IPsec / DTLS). 6.13.3. MTU The MTU for ACP secure channels MUST be derived locally from the underlying link MTU minus the secure channel encapsulation overhead. ACP secure Channel protocols do not need to perform MTU discovery because they are built across L2 adjacencies - the MTU on both sides connecting to the L2 connection are assumed to be consistent. Extensions to ACP where the ACP is for example tunneled need to consider how to guarantee MTU consistency. This is an issue of tunnels, not an issue of running the ACP across a tunnel. Transport stacks running across ACP can perform normal PMTUD (Path MTU Discovery). Because the ACP is meant to prioritize reliability over performance, they MAY opt to only expect IPv6 minimum MTU (1280) to avoid running into PMTUD implementation bugs or underlying link MTU mismatch problems. 6.13.4. Multiple links between nodes If two nodes are connected via several links, the ACP SHOULD be established across every link, but it is possible to establish the ACP only on a sub-set of links. Having an ACP channel on every link has a number of advantages, for example it allows for a faster failover in case of link failure, and it reflects the physical topology more closely. Using a subset of links (for example, a single link), reduces resource consumption on the node, because state needs to be kept per ACP channel. The negotiation scheme explained in Section 6.6 allows the Decider (the node with the higher ACP address) to drop all but the desired ACP channels to the Follower - and the Follower will not re-try to build these secure channels from its side unless the Decider shows up with a previously unknown GRASP announcement (e.g., on a different link or with a different address announced in GRASP). Eckert, et al. Expires 3 May 2021 [Page 81] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.13.5. ACP interfaces The ACP VRF has conceptually two type of interfaces: The "ACP Loopback interface(s)" to which the ACP ULA address(es) are assigned and the "ACP virtual interfaces" that are mapped to the ACP secure channels. 6.13.5.1. ACP loopback interfaces For autonomous operations of the ACP, as described in Section 6 and Section 7, the ACP node uses the first address from the N bit ACP prefix (N = 128 - number of Vbits of the ACP address) assigned to the node. This address is assigned with an address prefix of N or larger to a loopback interface. Other addresses from the prefix can be used by the ACP of the node as desired. The autonomous operations of the ACP does not require additional global scope IPv6 addresses, they are instead intended for ASA or non-autonomous functions. Non fully autonomic components of the ACP such as ACP connect interfaces (see Figure 16) may also introduce additional global scope IPv6 addresses on other types of interfaces into the ACP. [RFC-Editor: please remove this paragraph: Note to reviewers: Please do not complain again about an obsolete RFC number in the following paragraph. The text should make it clear that the reference was chosen to indicate a particular point in time, but not to recommend/ use a particularly obsolete protocol spec.] The use of loopback interfaces for global scope addresses is common operational configuration practice on routers, for example in IBGP connections since BGP4 (see [RFC1654]) or earlier. The ACP adopts and automates this operational practice. A loopback interface for use with the ACP as described above is an interface behaving according to [RFC6724] Section 4., paragraph 2: Packets sent by the host of the node from the loopback interface behave as if they are looped back by the interface so that they look as if they originated from the loopback interface, are then received by the node and forwarded by it towards the destination. The word loopback only indicates this behavior, but not the actual name of the interface type choosen in an actual implementation. A loopback interface for use with the ACP can be a virtual/software construct without any associated hardware, or it can be a hardware interface operating in loopback mode. Eckert, et al. Expires 3 May 2021 [Page 82] Internet-Draft An Autonomic Control Plane (ACP) October 2020 A loopback interface used for the ACP MUST NOT have connectivity to other nodes. The following reviews the reasons for the choice of loopback addresses for ACP addresses is based on the IPv6 address architecture and common challenges: 1. IPv6 addresses are assigned to interfaces, not nodes. IPv6 continues the IPv4 model that a subnet prefix is associated with one link, see [RFC4291], Section 2.1. 2. IPv6 implementations commonly do not allow assignment of the same IPv6 global scope address in the same VRF to more than one interface. 3. Global scope addresses assigned to interfaces that are connecting to other nodes (external interfaces) may not be stable addresses for communications because any such interface could fail due to reasons external to the node. This could render the addresses assigned to that interface unusable. 4. If failure of the subnet does not result in bringing down the interface and making the addresses unusable, it could result in unreachability of the address because the shortest path to the node might go through one of the other nodes on the same subnet which could equally consider the subnet to be operational even though it is not. 5. Many OAM service implementations on routers cannot deal with more than one peer address, often because they do already expect that a single loopback address can be used, especially to provide a stable address under failure of external interfaces or links. 6. Even when an application supports multiple addresses to a peer, it can only use one address for a connection at a time with the most widely deployed transport protocols TCP and UDP. While [RFC6824] solves this problem, it is not widely adopted for router OAM services implementations. 7. To completely autonomously assign global scope addresses to subnets connecting to other nodes, it would be necessary for every node to have an amount of prefix address space in the order of the maximum number of subnets that the node could connect to and then the node would have to negotiate with adjacent nodes across those subnets whose address space to use for each subnet. 8. Using global scope addresses for subnets between nodes is unnecessary if those subnets only connect routers, such as ACP secure channels, because they can communicate to remote nodes via their global scope loopback addresses. Using global scope addresses for those extern subnets is therefore wasteful for the address space and also unnecessarily increasing the size of routing and forwarding tables, which especially for the ACP is highly undesirable because it should attempt to minimize the per- node overhead of the ACP VRF. Eckert, et al. Expires 3 May 2021 [Page 83] Internet-Draft An Autonomic Control Plane (ACP) October 2020 9. For all these reasons, the ACP addressing schemes do not consider ACP addresses for subnets connecting ACP nodes. Note that [RFC8402] introduces the term Node-SID to refer to IGP prefix segments that identify a specific router, for example on a loopback interface. An ACP loopback address prefix may similarly be called an ACP Node Identifier. 6.13.5.2. ACP virtual interfaces Any ACP secure channel to another ACP node is mapped to ACP virtual interfaces in one of the following ways. This is independent of the chosen secure channel protocol (IPsec, DTLS or other future protocol - standards or non-standards). Note that all the considerations described here are assuming point- to-point secure channel associations. Mapping multi-party secure channel associations such as [RFC6407] is out of scope. 6.13.5.2.1. ACP point-to-point virtual interfaces In this option, each ACP secure channel is mapped into a separate point-to-point ACP virtual interface. If a physical subnet has more than two ACP capable nodes (in the same domain), this implementation approach will lead to a full mesh of ACP virtual interfaces between them. When the secure channel protocol determines a peer to be dead, this SHOULD result in indicating link breakage to trigger RPL DODAG repair, see Section 6.12.1.7. 6.13.5.2.2. ACP multi-access virtual interfaces In a more advanced implementation approach, the ACP will construct a single multi-access ACP virtual interface for all ACP secure channels to ACP capable nodes reachable across the same underlying (physical) subnet. IPv6 link-local multicast packets sent into an ACP multi- access virtual interface are replicated to every ACP secure channel mapped into the ACP multicast-access virtual interface. IPv6 unicast packets sent into an ACP multi-access virtual interface are sent to the ACP secure channel that belongs to the ACP neighbor that is the next-hop in the ACP forwarding table entry used to reach the packets destination address. When the secure channel protocol determines a peer to be dead for a secure channel mapped into an ACP multi-access virtual interface, this SHOULD result in signaling breakage of that peer to RPL, so it can trigger RPL DODAG repair, see Section 6.12.1.7. Eckert, et al. Expires 3 May 2021 [Page 84] Internet-Draft An Autonomic Control Plane (ACP) October 2020 There is no requirement for all ACP nodes on the same multi-access subnet to use the same type of ACP virtual interface. This is purely a node local decision. ACP nodes MUST perform standard IPv6 operations across ACP virtual interfaces including SLAAC (Stateless Address Auto-Configuration) - [RFC4862]) to assign their IPv6 link local address on the ACP virtual interface and ND (Neighbor Discovery - [RFC4861]) to discover which IPv6 link-local neighbor address belongs to which ACP secure channel mapped to the ACP virtual interface. This is independent of whether the ACP virtual interface is point-to-point or multi-access. "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] is RECOMMENDED because the likelihood for duplicates between ACP nodes is highly improbable as long as the address can be formed from a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see below). ACP nodes MAY reduce the amount of link-local IPv6 multicast packets from ND by learning the IPv6 link-local neighbor address to ACP secure channel mapping from other messages such as the source address of IPv6 link-local multicast RPL messages - and therefore forego the need to send Neighbor Solicitation messages. The ACP virtual interface IPv6 link local address can be derived from any appropriate local mechanism such as node local EUI-48 or EUI-64 ("EUI" stands for "Extended Unique Identifier"). It MUST NOT depend on something that is attackable from the Data-Plane such as the IPv6 link-local address of the underlying physical interface, which can be attacked by SLAAC, or parameters of the secure channel encapsulation header that may not be protected by the secure channel mechanism. The link-layer address of an ACP virtual interface is the address used for the underlying interface across which the secure tunnels are built, typically Ethernet addresses. Because unicast IPv6 packets sent to an ACP virtual interface are not sent to a link-layer destination address but rather an ACP secure channel, the link-layer address fields SHOULD be ignored on reception and instead the ACP secure channel from which the message was received should be remembered. Multi-access ACP virtual interfaces are preferable implementations when the underlying interface is a (broadcast) multi-access subnet because they do reflect the presence of the underlying multi-access subnet into the virtual interfaces of the ACP. This makes it for example simpler to build services with topology awareness inside the ACP VRF in the same way as they could have been built running natively on the multi-access interfaces. Eckert, et al. Expires 3 May 2021 [Page 85] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Consider also the impact of point-to-point vs. multi-access virtual interface on the efficiency of flooding via link local multicasted messages: Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alice's ACP GRASP wants to send a link-local GRASP multicast message to Bob and Carol. If Alice's ACP emulates the LAN as per-peer, point-to- point virtual interfaces, one to Bob and one to Carol, Alice's ACP GRASP will send two copies of multicast GRASP messages: One to Bob and one to Carol. If Alice's ACP emulates a LAN via a multipoint virtual interface, Alice's ACP GRASP will send one packet to that interface and the ACP multipoint virtual interface will replicate the packet to each secure channel, one to Bob, one to Carol. The result is the same. The difference happens when Bob and Carol receive their packet. If they use ACP point-to-point virtual interfaces, their GRASP instance would forward the packet from Alice to each other as part of the GRASP flooding procedure. These packets are unnecessary and would be discarded by GRASP on receipt as duplicates (by use of the GRASP Session ID). If Bob and Carol's ACP would emulate a multi- access virtual interface, then this would not happen, because GRASPs flooding procedure does not replicate back packets to the interface that they were received from. Note that link-local GRASP multicast messages are not sent directly as IPv6 link-local multicast UDP messages into ACP virtual interfaces, but instead into ACP GRASP virtual interfaces, that are layered on top of ACP virtual interfaces to add TCP reliability to link-local multicast GRASP messages. Nevertheless, these ACP GRASP virtual interfaces perform the same replication of message and, therefore, result in the same impact on flooding. See Section 6.9.2 for more details. RPL does support operations and correct routing table construction across non-broadcast multi-access (NBMA) subnets. This is common when using many radio technologies. When such NBMA subnets are used, they MUST NOT be represented as ACP multi-access virtual interfaces because the replication of IPv6 link-local multicast messages will not reach all NBMA subnet neighbors. In result, GRASP message flooding would fail. Instead, each ACP secure channel across such an interface MUST be represented as a ACP point-to-point virtual interface. See also Appendix A.9.4. Care needs to be taken when creating multi-access ACP virtual interfaces across ACP secure channels between ACP nodes in different domains or routing subdomains. If for example future inter-domain ACP policies are defined as "peer-to-peer" policies, it is easier to create ACP point-to-point virtual interfaces for these inter-domain secure channels. Eckert, et al. Expires 3 May 2021 [Page 86] Internet-Draft An Autonomic Control Plane (ACP) October 2020 7. ACP support on L2 switches/ports (Normative) 7.1. Why (Benefits of ACP on L2 switches) ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 .../ \ \ ... ANrtrM ------ \ ------- ANrtrN ANswitchM ... Figure 15: Topology with L2 ACP switches Consider a large L2 LAN with ANrtr1...ANrtrN connected via some topology of L2 switches. Examples include large enterprise campus networks with an L2 core, IoT networks or broadband aggregation networks which often have even a multi-level L2 switched topology. If the discovery protocol used for the ACP is operating at the subnet level, every ACP router will see all other ACP routers on the LAN as neighbors and a full mesh of ACP channels will be built. If some or all of the AN switches are autonomic with the same discovery protocol, then the full mesh would include those switches as well. A full mesh of ACP connections can create fundamental scale challenges. The number of security associations of the secure channel protocols will likely not scale arbitrarily, especially when they leverage platform accelerated encryption/decryption. Likewise, any other ACP operations (such as routing) needs to scale to the number of direct ACP neighbors. An ACP router with just 4 physical interfaces might be deployed into a LAN with hundreds of neighbors connected via switches. Introducing such a new unpredictable scaling factor requirement makes it harder to support the ACP on arbitrary platforms and in arbitrary deployments. Predictable scaling requirements for ACP neighbors can most easily be achieved if in topologies such as these, ACP capable L2 switches can ensure that discovery messages terminate on them so that neighboring ACP routers and switches will only find the physically connected ACP L2 switches as their candidate ACP neighbors. With such a discovery mechanism in place, the ACP and its security associations will only need to scale to the number of physical interfaces instead of a potentially much larger number of "LAN-connected" neighbors. And the ACP topology will follow directly the physical topology, something which can then also be leveraged in management operations or by ASAs. In the example above, consider ANswitch1 and ANswitchM are ACP capable, and ANswitch2 is not ACP capable. The desired ACP topology is that ANrtr1 and ANrtrM only have an ACP connection to ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP connection Eckert, et al. Expires 3 May 2021 [Page 87] Internet-Draft An Autonomic Control Plane (ACP) October 2020 amongst each other. ANswitch1 also has an ACP connection with ANswitchM and ANswitchM has ACP connections to anything else behind it. 7.2. How (per L2 port DULL GRASP) To support ACP on L2 switches or L2 switched ports of an L3 device, it is necessary to make those L2 ports look like L3 interfaces for the ACP implementation. This primarily involves the creation of a separate DULL GRASP instance/domain on every such L2 port. Because GRASP has a dedicated link-local IPv6 multicast address (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this address are being extracted at the port level and passed to that DULL GRASP instance. Likewise the IPv6 link-local multicast packets sent by that DULL GRASP instance need to be sent only towards the L2 port for this DULL GRASP instance (instead of being flooded across all ports of the VLAN to which the port belongs). When Ports/Interfaces across which the ACP is expected to operate in an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward between these ports. If MLD snooping is used, it MUST be prohibited from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast address. On hybrid L2/L3 switches, multiple L2 ports are assigned to a single L3 VLAN interface. With the aforementioned changes for DULL GRASP, ACP can simply operate on the L3 VLAN interfaces, so no further (hardware) forwarding changes are required to make ACP operate on L2 ports. This is possible because the ACP secure channel protocols only use link-local IPv6 unicast packets, and these packets will be sent to the correct L2 port towards the peer by the VLAN logic of the device. This is sufficient when p2p ACP virtual interfaces are established to every ACP peer. When it is desired to create multi-access ACP virtual interfaces (see Section 6.13.5.2.2), it is REQIURED not to coalesce all the ACP secure channels on the same L3 VLAN interface, but only all those on the same L2 port. If VLAN tagging is used, then all the above described logic only applies to untagged GRASP packets. For the purpose of ACP neighbor discovery via GRASP, no VLAN tagged packets SHOULD be sent or received. In a hybrid L2/L3 switch, each VLAN would therefore only create ACP adjacencies across those ports where the VLAN is carried untagged. Eckert, et al. Expires 3 May 2021 [Page 88] Internet-Draft An Autonomic Control Plane (ACP) October 2020 In result, the simple logic is that ACP secure channels would operate over the same L3 interfaces that present a single flat bridged network across all routers, but because DULL GRASP is separated on a per-port basis, no full mesh of ACP secure channels is created, but only per-port ACP secure channels to per-port L2-adjacent ACP node neighbors. For example, in the above picture, ANswitch1 would run separate DULL GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even though all those three ports may be in the data plane in the same (V)LAN and perform L2 switching between these ports, ANswitch1 would perform ACP L3 routing between them. The description in the previous paragraph was specifically meant to illustrate that on hybrid L3/L2 devices that are common in enterprise, IoT and broadband aggregation, there is only the GRASP packet extraction (by Ethernet address) and GRASP link-local multicast per L2-port packet injection that has to consider L2 ports at the hardware forwarding level. The remaining operations are purely ACP control plane and setup of secure channels across the L3 interface. This hopefully makes support for per-L2 port ACP on those hybrid devices easy. In devices without such a mix of L2 port/interfaces and L3 interfaces (to terminate any transport layer connections), implementation details will differ. Logically most simply every L2 port is considered and used as a separate L3 subnet for all ACP operations. The fact that the ACP only requires IPv6 link-local unicast and multicast should make support for it on any type of L2 devices as simple as possible. A generic issue with ACP in L2 switched networks is the interaction with the Spanning Tree Protocol. Without further L2 enhancements, the ACP would run only across the active STP topology and the ACP would be interrupted and re-converge with STP changes. Ideally, ACP peering SHOULD be built also across ports that are blocked in STP so that the ACP does not depend on STP and can continue to run unaffected across STP topology changes, where re-convergence can be quite slow. The above described simple implementation options are not sufficient to achieve this. 8. Support for Non-ACP Components (Normative) 8.1. ACP Connect Eckert, et al. Expires 3 May 2021 [Page 89] Internet-Draft An Autonomic Control Plane (ACP) October 2020 8.1.1. Non-ACP Controller / NMS system The Autonomic Control Plane can be used by management systems, such as controllers or network management system (NMS) hosts (henceforth called simply "NMS hosts"), to connect to devices (or other type of nodes) through it. For this, an NMS host needs to have access to the ACP. The ACP is a self-protecting overlay network, which allows by default access only to trusted, autonomic systems. Therefore, a traditional, non-ACP NMS system does not have access to the ACP by default, such as any other external node. If the NMS host is not autonomic, i.e., it does not support autonomic negotiation of the ACP, then it can be brought into the ACP by explicit configuration. To support connections to adjacent non-ACP nodes, an ACP node SHOULD support "ACP connect" (sometimes also called "autonomic connect"): "ACP connect" is an interface level configured workaround for connection of trusted non-ACP nodes to the ACP. The ACP node on which ACP connect is configured is called an "ACP edge node". With ACP connect, the ACP is accessible from those non-ACP nodes (such as NOC systems) on such an interface without those non-ACP nodes having to support any ACP discovery or ACP channel setup. This is also called "native" access to the ACP because to those NOC systems the interface looks like a normal network interface without any ACP secure channel that is encapsulating the traffic. Data-Plane "native" (no ACP) . +--------+ +----------------+ . +-------------+ | ACP | |ACP Edge Node | . | | | Node | | | v | | | |-------|...[ACP VRF]....+----------------| |+ | | ^ |. | | NOC Device || | | . | .[Data-Plane]..+----------------| "NMS hosts" || | | . | [ ] | . ^ | || +--------+ . +----------------+ . . +-------------+| . . . +-------------+ . . . Data-Plane "native" . ACP "native" (unencrypted) + ACP auto-negotiated . "ACP connect subnet" and encrypted . ACP connect interface e.g., "VRF ACP native" (config) Figure 16: ACP connect Eckert, et al. Expires 3 May 2021 [Page 90] Internet-Draft An Autonomic Control Plane (ACP) October 2020 ACP connect has security consequences: All systems and processes connected via ACP connect have access to all ACP nodes on the entire ACP, without further authentication. Thus, the ACP connect interface and NOC systems connected to it needs to be physically controlled/ secured. For this reason the mechanisms described here do explicitly not include options to allow for a non-ACP router to be connected across an ACP connect interface and addresses behind such a router routed inside the ACP. Physical controlled/secured means that attackers can gain no access to the physical device hosting the ACP Edge Node, the physical interfaces and links providing the ACP connect link nor the physical devices hosting the NOC Device. In a simple case, ACP Edge node and NOC Device are co-located in an access controlled room, such as a NOC, to which attackers cannot gain physical access. An ACP connect interface provides exclusively access to only the ACP. This is likely insufficient for many NMS hosts. Instead, they would require a second "Data-Plane" interface outside the ACP for connections between the NMS host and administrators, or Internet based services, or for direct access to the Data-Plane. The document "Using Autonomic Control Plane for Stable Connectivity of Network OAM" [RFC8368] explains in more detail how the ACP can be integrated in a mixed NOC environment. An ACP connect interface SHOULD use an IPv6 address/prefix from the ACP Manual Addressing Sub-Scheme (Section 6.11.4), letting the operator configure for example only the Subnet-ID and having the node automatically assign the remaining part of the prefix/address. It SHOULD NOT use a prefix that is also routed outside the ACP so that the addresses clearly indicate whether it is used inside the ACP or not. The prefix of ACP connect subnets MUST be distributed by the ACP edge node into the ACP routing protocol RPL. The NMS hosts MUST connect to prefixes in the ACP routing table via its ACP connect interface. In the simple case where the ACP uses only one ULA prefix and all ACP connect subnets have prefixes covered by that ULA prefix, NMS hosts can rely on [RFC6724] to determine longest match prefix routes towards its different interfaces, ACP and Data-Plane. With RFC6724, The NMS host will select the ACP connect interface for all addresses in the ACP because any ACP destination address is longest matched by the address on the ACP connect interface. If the NMS hosts ACP connect interface uses another prefix or if the ACP uses multiple ULA prefixes, then the NMS hosts require (static) routes towards the ACP interface for these prefixes. Eckert, et al. Expires 3 May 2021 [Page 91] Internet-Draft An Autonomic Control Plane (ACP) October 2020 When an ACP Edge node receives a packet from an ACP connect interface, the ACP Edge node MUST only forward the packet into the ACP if the packet has an IPv6 source address from that interface (this is sometimes called "RPF filtering"). This filtering rule MAY be changed through administrative measures. The more any such administrative action enable reachability of non ACP nodes to the ACP, the more this may cause security issues. To limit the security impact of ACP connect, nodes supporting it SHOULD implement a security mechanism to allow configuration/use of ACP connect interfaces only on nodes explicitly targeted to be deployed with it (those in physically secure locations such as a NOC). For example, the registrar could disable the ability to enable ACP connect on devices during enrollment and that property could only be changed through re-enrollment. See also Appendix A.9.5. ACP Edge nodes SHOULD have a configurable option to prohibit packets with RPI headers (see Section 6.12.1.13 across an ACP connect interface. These headers are outside the scope of the RPL profile in this specification but may be used in future extensions of this specification. 8.1.2. Software Components The previous section assumed that ACP Edge node and NOC devices are separate physical devices and the ACP connect interface is a physical network connection. This section discusses the implication when these components are instead software components running on a single physical device. The ACP connect mechanism cannot only be used to connect physically external systems (NMS hosts) to the ACP but also other applications, containers or virtual machines. In fact, one possible way to eliminate the security issue of the external ACP connect interface is to collocate an ACP edge node and an NMS host by making one a virtual machine or container inside the other; and therefore converting the unprotected external ACP subnet into an internal virtual subnet in a single device. This would ultimately result in a fully ACP enabled NMS host with minimum impact to the NMS hosts software architecture. This approach is not limited to NMS hosts but could equally be applied to devices consisting of one or more VNF (virtual network functions): An internal virtual subnet connecting out-of-band management interfaces of the VNFs to an ACP edge router VNF. Eckert, et al. Expires 3 May 2021 [Page 92] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The core requirement is that the software components need to have a network stack that permits access to the ACP and optionally also the Data-Plane. Like in the physical setup for NMS hosts this can be realized via two internal virtual subnets. One that is connecting to the ACP (which could be a container or virtual machine by itself), and one (or more) connecting into the Data-Plane. This "internal" use of ACP connect approach should not be considered to be a "workaround" because in this case it is possible to build a correct security model: It is not necessary to rely on unprovable external physical security mechanisms as in the case of external NMS hosts. Instead, the orchestration of the ACP, the virtual subnets and the software components can be done by trusted software that could be considered to be part of the ANI (or even an extended ACP). This software component is responsible for ensuring that only trusted software components will get access to that virtual subnet and that only even more trusted software components will get access to both the ACP virtual subnet and the Data-Plane (because those ACP users could leak traffic between ACP and Data-Plane). This trust could be established for example through cryptographic means such as signed software packages. 8.1.3. Auto Configuration ACP edge nodes, NMS hosts and software components that as described in the previous section are meant to be composed via virtual interfaces SHOULD support on the ACP connect subnet StateLess Address Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration according to [RFC4191]. The ACP edge node acts as the router towards the ACP on the ACP connect subnet, providing the (auto-)configured prefix for the ACP connect subnet and (auto-)configured routes into the ACP to NMS hosts and/or software components. The ACP edge node uses the Route Information Option (RIO) of RFC4191 to announce aggregated prefixes for address prefixes used in the ACP (with normal RIO lifetimes. In addition, the ACP edge node also uses a RIO to announce the default route (::/0) with a lifetime of 0. These RIOs allow to connect Type C hosts to the ACP via an ACP connect subnet on one interface and another network (Data Plane / NMS network) on the same or another interface of the Type C host, relying on other routers than the ACP edge node. The RIOs ensure that these hosts will only route the prefixes used in the ACP to the ACP edge node. Eckert, et al. Expires 3 May 2021 [Page 93] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Type A/B host ignore the RIOs and will consider the ACP node to be their default router for all destination. This is sufficient when type A/B hosts only need to connect to the ACP but not to other networks. Attaching Type A/B hosts to both the ACP and other networks, requires either explicit ACP prefix route configuration on the Type A/B hosts or the combined ACP/Data-Plane interface on the ACP edge node, see Section 8.1.4. Aggregated prefix means that the ACP edge node needs to only announce the /48 ULA prefixes used in the ACP but none of the actual /64 (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub- Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual ACP nodes. If ACP interfaces are configured with non ULA prefixes, then those prefixes cannot be aggregated without further configured policy on the ACP edge node. This explains the above recommendation to use ACP ULA prefix covered prefixes for ACP connect interfaces: They allow for a shorter list of prefixes to be signaled via RFC4191 to NMS hosts and software components. The ACP edge nodes that have a Vlong ACP address MAY allocate a subset of their /112 or /120 address prefix to ACP connect interface(s) to eliminate the need to non-autonomically configure/ provision the address prefixes for such ACP connect interfaces. 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) Combined ACP and Data-Plane interface . +--------+ +--------------------+ . +--------------+ | ACP | |ACP Edge No | . | NMS Host(s) | | Node | | | . | / Software | | | | [ACP ]. | . | |+ | | | .[VRF ] .[VRF ] | v | "ACP address"|| | +-------+. .[Select].+--------+ "Date Plane || | | ^ | .[Data ]. | | Address(es)"|| | | . | [Plane] | | || | | . | [ ] | +--------------+| +--------+ . +--------------------+ +--------------+ . Data-Plane "native" and + ACP auto-negotiated/encrypted Figure 17: VRF select Eckert, et al. Expires 3 May 2021 [Page 94] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Using two physical and/or virtual subnets (and therefore interfaces) into NMS Hosts (as per Section 8.1.1) or Software (as per Section 8.1.2) may be seen as additional complexity, for example with legacy NMS Hosts that support only one IP interface, or it may be insufficient to support [RFC4191] Type A or B host (see Section 8.1.3). To provide a single subnet into both ACP and Data-Plane, the ACP Edge node needs to de-multiplex packets from NMS hosts into ACP VRF and Data-Plane. This is sometimes called "VRF select". If the ACP VRF has no overlapping IPv6 addresses with the Data-Plane (it should have no overlapping addresses), then this function can use the IPv6 Destination address. The problem is Source Address Selection on the NMS Host(s) according to RFC6724. Consider the simple case: The ACP uses only one ULA prefix, the ACP IPv6 prefix for the Combined ACP and Data-Plane interface is covered by that ULA prefix. The ACP edge node announces both the ACP IPv6 prefix and one (or more) prefixes for the Data-Plane. Without further policy configurations on the NMS Host(s), it may select its ACP address as a source address for Data-Plane ULA destinations because of Rule 8 of RFC6724. The ACP edge node can pass on the packet to the Data-Plane, but the ACP source address should not be used for Data-Plane traffic, and return traffic may fail. If the ACP carries multiple ULA prefixes or non-ULA ACP connect prefixes, then the correct source address selection becomes even more problematic. With separate ACP connect and Data-Plane subnets and RFC4191 prefix announcements that are to be routed across the ACP connect interface, RFC6724 source address selection Rule 5 (use address of outgoing interface) will be used, so that above problems do not occur, even in more complex cases of multiple ULA and non-ULA prefixes in the ACP routing table. To achieve the same behavior with a Combined ACP and Data-Plane interface, the ACP Edge Node needs to behave as two separate routers on the interface: One link-local IPv6 address/router for its ACP reachability, and one link-local IPv6 address/router for its Data- Plane reachability. The Router Advertisements for both are as described above (Section 8.1.3): For the ACP, the ACP prefix is announced together with RFC4191 option for the prefixes routed across the ACP and lifetime=0 to disqualify this next-hop as a default router. For the Data-Plane, the Data-Plane prefix(es) are announced together with whatever dafault router parameters are used for the Data-Plane. Eckert, et al. Expires 3 May 2021 [Page 95] Internet-Draft An Autonomic Control Plane (ACP) October 2020 In result, RFC6724 source address selection Rule 5.5 may result in the same correct source address selection behavior of NMS hosts without further configuration on it as the separate ACP connect and Data-Plane interfaces. As described in the text for Rule 5.5, this is only a MAY, because IPv6 hosts are not required to track next-hop information. If an NMS Host does not do this, then separate ACP connect and Data-Plane interfaces are the preferable method of attachment. Hosts implementing [RFC8028] should (instead of may) implement [RFC6724] Rule 5.5, so it is preferred for hosts to support [RFC8028]. ACP edge nodes MAY support the Combined ACP and Data-Plane interface. 8.1.5. Use of GRASP GRASP can and should be possible to use across ACP connect interfaces, especially in the architectural correct solution when it is used as a mechanism to connect Software (e.g., ASA or legacy NMS applications) to the ACP. Given how the ACP is the security and transport substrate for GRASP, the requirements for devices connected via ACP connect is that those are equivalently (if not better) secured against attacks than ACP nodes that do not use ACP connect and run only software that is equally (if not better) protected, known (or trusted) not to be malicious and accordingly designed to isolate access to the ACP against external equipment. The difference in security is that cryptographic security of the ACP secure channel is replaced by required physical security/control of the network connection between an ACP edge node and the NMS or other host reachable via the ACP connect interface. See Section 8.1.1. When using "Combined ACP and Data-Plane Interfaces", care has to be taken that only GRASP messages intended for the ACP GRASP domain received from Software or NMS Hosts are forwarded by ACP edge nodes. Currently there is no definition for a GRASP security and transport substrate beside the ACP, so there is no definition how such Software/NMS Host could participate in two separate GRASP Domains across the same subnet (ACP and Data-Plane domains). At current it is assumed that all GRASP packets on a Combined ACP and Data-Plane interface belong to the GRASP ACP Domain. They SHOULD all use the ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and M_FLOOD messages) are also assumed to belong to the ACP address space. Eckert, et al. Expires 3 May 2021 [Page 96] Internet-Draft An Autonomic Control Plane (ACP) October 2020 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP neighbors) Not all nodes in a network may support the ACP. If non-ACP Layer-2 devices are between ACP nodes, the ACP will work across it since it is IP based. However, the autonomic discovery of ACP neighbors via DULL GRASP is only intended to work across L2 connections, so it is not sufficient to autonomically create ACP connections across non-ACP Layer-3 devices. 8.2.1. Configured Remote ACP neighbor On the ACP node, remote ACP neighbors are configured explicitly. The parameters of such a "connection" are described in the following ABNF. connection = [ method , local-addr, remote-addr, ?pmtu ] method = [ "IKEv2", ?port ] method =/ [ "DTLS", port ] local-addr = [ address , ?vrf ] remote-addr = [ address ] address = ("any" | ipv4-address | ipv6-address ) vrf = tstr ; Name of a VRF on this node with local-address Figure 18: Parameters for remote ACP neighbors Explicit configuration of a remote-peer according to this ABNF provides all the information to build a secure channel without requiring a tunnel to that peer and running DULL GRASP inside of it. The configuration includes the parameters otherwise signaled via DULL GRASP: local address, remote (peer) locator and method. The differences over DULL GRASP local neighbor discovery and secure channel creation are as follows: * The local and remote address can be IPv4 or IPv6 and are typically global scope addresses. * The VRF across which the connection is built (and in which local- addr exists) can to be specified. If vrf is not specified, it is the default VRF on the node. In DULL GRASP the VRF is implied by the interface across which DULL GRASP operates. * If local address is "any", the local address used when initiating a secure channel connection is decided by source address selection ([RFC6724] for IPv6). As a responder, the connection listens on all addresses of the node in the selected VRF. * Configuration of port is only required for methods where no defaults exist (e.g., "DTLS"). Eckert, et al. Expires 3 May 2021 [Page 97] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * If remote address is "any", the connection is only a responder. It is a "hub" that can be used by multiple remote peers to connect simultaneously - without having to know or configure their addresses. Example: Hub site for remote "spoke" sites reachable over the Internet. * Pmtu should be configurable to overcome issues/limitations of Path MTU Discovery (PMTUD). * IKEv2/IPsec to remote peers should support the optional NAT Traversal (NAT-T) procedures. 8.2.2. Tunneled Remote ACP Neighbor An IPinIP, GRE or other form of pre-existing tunnel is configured between two remote ACP peers and the virtual interfaces representing the tunnel are configured for "ACP enable". This will enable IPv6 link local addresses and DULL on this tunnel. In result, the tunnel is used for normal "L2 adjacent" candidate ACP neighbor discovery with DULL and secure channel setup procedures described in this document. Tunneled Remote ACP Neighbor requires two encapsulations: the configured tunnel and the secure channel inside of that tunnel. This makes it in general less desirable than Configured Remote ACP Neighbor. Benefits of tunnels are that it may be easier to implement because there is no change to the ACP functionality - just running it over a virtual (tunnel) interface instead of only native interfaces. The tunnel itself may also provide PMTUD while the secure channel method may not. Or the tunnel mechanism is permitted/possible through some firewall while the secure channel method may not. Tunneling using an insecure tunnel encapsulation increases on average the risk of a MITM downgrade attack somewhere along the underlay path that blocks all but the most easily attacked ACP secure channel option. ACP nodes supporting tunneled remote ACP Neighbors SHOULD support configuration on such tunnel interfaces to restrict or explicitly select the available ACP secure channel protocols (if the ACP node supports more than one ACP secure channel protocol in the first place). 8.2.3. Summary Configured/Tunneled Remote ACP neighbors are less "indestructible" than L2 adjacent ACP neighbors based on link local addressing, since they depend on more correct Data-Plane operations, such as routing and global addressing. Eckert, et al. Expires 3 May 2021 [Page 98] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Nevertheless, these options may be crucial to incrementally deploy the ACP, especially if it is meant to connect islands across the Internet. Implementations SHOULD support at least Tunneled Remote ACP Neighbors via GRE tunnels - which is likely the most common router-to-router tunneling protocol in use today. 9. ACP Operations (Informative) The following sections document important operational aspects of the ACP. They are not normative because they do not impact the interoperability between components of the ACP, but they include recommendations/requirements for the internal operational model beneficial or necessary to achieve the desired use-case benefits of the ACP (see Section 3). * Section 9.1 describes recommended operator diagnostics capabilities of ACP nodes. * Section 9.2 describes high level how an ACP registrar needs to work, what its configuration parameters are and specific issues impacting the choices of deployment design due to renewal and revocation issues. It describes a model where ACP Registrars have their own sub-CA to provide the most distributed deployment option for ACP Registrars, and it describes considerations for centralized policy control of ACP Registrar operations. * Section 9.3 describes suggested ACP node behavior and operational interfaces (configuration options) to manage the ACP in so-called greenfield devices (previously unconfigured) and brownfield devices (preconfigured). The recommendations and suggestions of this chapter were derived from operational experience gained with a commercially available pre- standard ACP implementation. 9.1. ACP (and BRSKI) Diagnostics Even though ACP and ANI in general are taking out many manual configuration mistakes through their automation, it is important to provide good diagnostics for them. Basic standardized diagnostics would require support for (yang) models representing the complete (auto-)configuration and operational state of all components: GRASP, ACP and the infrastructure used by them: TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While necessary, this is not sufficient: Eckert, et al. Expires 3 May 2021 [Page 99] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Simply representing the state of components does not allow operators to quickly take action - unless they do understand how to interpret the data, and that can mean a requirement for deep understanding of all components and how they interact in the ACP/ANI. Diagnostic supports should help to quickly answer the questions operators are expected to ask, such as "is the ACP working correctly?", or "why is there no ACP connection to a known neighboring node?" In current network management approaches, the logic to answer these questions is most often built as centralized diagnostics software that leverages the above mentioned data models. While this approach is feasible for components utilizing the ANI, it is not sufficient to diagnose the ANI itself: * Developing the logic to identify common issues requires operational experience with the components of the ANI. Letting each management system define its own analysis is inefficient. * When the ANI is not operating correctly, it may not be possible to run diagnostics from remote because of missing connectivity. The ANI should therefore have diagnostic capabilities available locally on the nodes themselves. * Certain operations are difficult or impossible to monitor in real- time, such as initial bootstrap issues in a network location where no capabilities exist to attach local diagnostics. Therefore, it is important to also define means of capturing (logging) diagnostics locally for later retrieval. Ideally, these captures are also non-volatile so that they can survive extended power-off conditions - for example when a device that fails to be brought up zero-touch is being sent back for diagnostics at a more appropriate location. The simplest form of diagnostics answering questions such as the above is to represent the relevant information sequentially in dependency order, so that the first non-expected/non-operational item is the most likely root cause. Or just log/highlight that item. For example: Q: Is ACP operational to accept neighbor connections: * Check if any potentially necessary configuration to make ACP/ANI operational are correct (see Section 9.3 for a discussion of such commands). * Does the system time look reasonable, or could it be the default system time after clock chip battery failure (certificate checks depend on reasonable notion of time)?. Eckert, et al. Expires 3 May 2021 [Page 100] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * Does the node have keying material - domain certificate, TA certificates, ...> * If no keying material and ANI is supported/enabled, check the state of BRSKI (not detailed in this example). * Check the validity of the domain certificate: - Does the certificate validate against the TA? - Has it been revoked? - Was the last scheduled attempt to retrieve a CRL successful (e.g., do we know that our CRL information is up to date). - Is the certificate valid: validity start time in the past, expiration time in the future? - Does the certificate have a correctly formatted acp-node-name field? * Was the ACP VRF successfully created? * Is ACP enabled on one or more interfaces that are up and running? If all this looks good, the ACP should be running locally "fine" - but we did not check any ACP neighbor relationships. Question: why does the node not create a working ACP connection to a neighbor on an interface? * Is the interface physically up? Does it have an IPv6 link-local address? * Is it enabled for ACP? * Do we successfully send DULL GRASP messages to the interface (link layer errors)? * Do we receive DULL GRASP messages on the interface? If not, some intervening L2 equipment performing bad MLD snooping could have caused problems. Provide e.g., diagnostics of the MLD querier IPv6 and MAC address. * Do we see the ACP objective in any DULL GRASP message from that interface? Diagnose the supported secure channel methods. * Do we know the MAC address of the neighbor with the ACP objective? If not, diagnose SLAAC/ND state. * When did we last attempt to build an ACP secure channel to the neighbor? * If it failed, why: - Did the neighbor close the connection on us or did we close the connection on it because the domain certificate membership failed? - If the neighbor closed the connection on us, provide any error diagnostics from the secure channel protocol. - If we failed the attempt, display our local reason: o There was no common secure channel protocol supported by the two neighbors (this could not happen on nodes supporting this specification because it mandates common support for IPsec). Eckert, et al. Expires 3 May 2021 [Page 101] Internet-Draft An Autonomic Control Plane (ACP) October 2020 o The ACP certificate membership check (Section 6.2.3) fails: + The neighbor's certificate is not signed directly or indirectly by one of the nodes TA. Provide diagnostics which TA it has (can identify whom the device belongs to). + The neighbor's certificate does not have the same domain (or no domain at all). Diagnose domain-name and potentially other cert info. + The neighbor's certificate has been revoked or could not be authenticated by OCSP. + The neighbor's certificate has expired - or is not yet valid. - Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. Question: Is the ACP operating correctly across its secure channels? * Are there one or more active ACP neighbors with secure channels? * Is the RPL routing protocol for the ACP running? * Is there a default route to the root in the ACP routing table? * Is there for each direct ACP neighbor not reachable over the ACP virtual interface to the root a route in the ACP routing table? * Is ACP GRASP running? * Is at least one SRV.est objective cached (to support certificate renewal)? * Is there at least one BRSKI registrar objective cached (in case BRSKI is supported) * Is BRSKI proxy operating normally on all interfaces where ACP is operating? * ... These lists are not necessarily complete, but illustrate the principle and show that there are variety of issues ranging from normal operational causes (a neighbor in another ACP domain) over problems in the credentials management (certificate lifetimes), explicit security actions (revocation) or unexpected connectivity issues (intervening L2 equipment). The items so far are illustrating how the ANI operations can be diagnosed with passive observation of the operational state of its components including historic/cached/counted events. This is not necessary sufficient to provide good enough diagnostics overall: The components of ACP and BRSKI are designed with security in mind but they do not attempt to provide diagnostics for building the network itself. Consider two examples: Eckert, et al. Expires 3 May 2021 [Page 102] Internet-Draft An Autonomic Control Plane (ACP) October 2020 1. BRSKI does not allow for a neighboring device to identify the pledges IDevID certificate. Only the selected BRSKI registrar can do this, but it may be difficult to disseminate information about undesired pledges from those BRSKI registrars to locations/ nodes where information about those pledges is desired. 2. LLDP disseminates information about nodes to their immediate neighbors, such as node model/type/software and interface name/ number of the connection. This information is often helpful or even necessary in network diagnostics. It can equally be considered to be too insecure to make this information available unprotected to all possible neighbors. An "interested adjacent party" can always determine the IDevID certificate of a BRSKI pledge by behaving like a BRSKI proxy/ registrar. Therefore, the IDevID certificate of a BRSKI pledge is not meant to be protected - it just has to be queried and is not signaled unsolicited (as it would be in LLDP) so that other observers on the same subnet can determine who is an "interested adjacent party". 9.1.1. Secure Channel Peer diagnostics When using mutual certificate authentication, the TA certificate is not required to be signaled explicitly because its hash is sufficient for certificate chain validation. In the case of ACP secure channel setup this leads to limited diagnostics when authentication fails because of TA mismatch. For this reason, Section 6.8.2 recommends to also include the TA certificate in the secure channel signaling. This should be possible to do without protocol modifications in the security association protocols used by the ACP. For example, while [RFC7296] does not mention this, it also does not prohibit it. One common deployment use case where the diagnostic through the signaled TA of a candidate peer is very helpful are multi-tenant environments such as office buildings, where different tenants run their own networks and ACPs. Each tenant is given supposedly disjoint L2 connectivity through the building infrastructure. In these environments there are various common errors through which a device may receive L2 connectivity into the wrong tenants network. While the ACP itself is not impact by this, the Data-Plane to be built later may be impacted. Therefore, it is important to be able to diagnose such undesirable connectivity from the ACP so that any autonomic or non-autonomic mechanisms to configure the Data-Plane can accordingly treat such interfaces. The information in the TA of the peer can then ease troubleshooting of such issues. Eckert, et al. Expires 3 May 2021 [Page 103] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Another example case is the intended or accidental re-activation of equipment whose TA certificate has long expired, such as redundant gear taken from storage after years. A third example case is when in a mergers & acquisition case ACP nodes have not been correctly provisioned with the mutual TA of previously disjoint ACP. This is assuming that the ACP domain names where already aligned so that the ACP domain membership check is only failing on the TA. A fourth example case is when multiple registrars where set up for the same ACP but without correctly setting up the same TA. For example, when registrars support to also be CA themselves but are misconfigured to become TA instead of intermediate CA. 9.2. ACP Registrars As described in Section 6.11.7, the ACP addressing mechanism is designed to enable lightweight, distributed and uncoordinated ACP registrars that are providing ACP address prefixes to candidate ACP nodes by enrolling them with an ACP certificate into an ACP domain via any appropriate mechanism/protocol, automated or not. This section discusses informatively more details and options for ACP registrars. 9.2.1. Registrar interactions This section summarizes and discusses the interactions with other entities required by an ACP registrar. In a simple instance of an ACP network, no central NOC component beside a TA is required. Typically, this is a root CA. One or more uncoordinated acting ACP registrar can be set up, performing the following interactions: To orchestrate enrolling a candidate ACP node autonomically, the ACP registrar can rely on the ACP and use Proxies to reach the candidate ACP node, therefore allowing minimum pre-existing (auto-)configured network services on the candidate ACP node. BRSKI defines the BRSKI proxy, a design that can be adopted for various protocols that Pledges/candidate ACP nodes could want to use, for example BRSKI over CoAP (Constrained Application Protocol), or proxying of NETCONF. Eckert, et al. Expires 3 May 2021 [Page 104] Internet-Draft An Autonomic Control Plane (ACP) October 2020 To reach a TA that has no ACP connectivity, the ACP registrar would use the Data-Plane. ACP and Data-Plane in an ACP registrar could (and by default should be) completely isolated from each other at the network level. Only applications such as the ACP registrar would need the ability for their transport stacks to access both. In non-autonomic enrollment options, the Data-Plane between a ACP registrar and the candidate ACP node needs to be configured first. This includes the ACP registrar and the candidate ACP node. Then any appropriate set of protocols can be used between ACP registrar and candidate ACP node to discover the other side, and then connect and enroll (configure) the candidate ACP node with an ACP certificate. NETCONF ZeroTouch ([RFC8572]) is an example protocol that could be used for this. BRSKI using optional discovery mechanisms is equally a possibility for candidate ACP nodes attempting to be enrolled across non-ACP networks, such as the Internet. When candidate ACP nodes have secure bootstrap, such as BRSKI Pledges, they will not trust to be configured/enrolled across the network, unless being presented with a voucher (see [RFC8366]) authorizing the network to take possession of the node. An ACP registrar will then need a method to retrieve such a voucher, either offline, or online from a MASA (Manufacturer Authorized Signing Authority). BRSKI and NETCONF ZeroTouch are two protocols that include capabilities to present the voucher to the candidate ACP node. An ACP registrar could operate EST for ACP certificate renewal and/or act as a CRL Distribution point. A node performing these services does not need to support performing (initial) enrollment, but it does require the same above described connectivity as an ACP registrar: via the ACP to ACP nodes and via the Data-Plane to the TA and other sources of CRL information. 9.2.2. Registrar Parameter The interactions of an ACP registrar outlined Section 6.11.7 and Section 9.2.1 above depend on the following parameters: * A URL to the TA and credentials so that the ACP registrar can let the TA sign candidate ACP node certificates. * The ACP domain-name. * The Registrar-ID to use. This could default to a MAC address of the ACP registrar. Eckert, et al. Expires 3 May 2021 [Page 105] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- addressing scheme, for Vlong /112 and for Vlong /120 sub- addressing scheme. These IDs would only need to be provisioned after recovering from a crash. Some other mechanism would be required to remember these IDs in a backup location or to recover them from the set of currently known ACP nodes. * Policies if candidate ACP nodes should receive a domain certificate or not, for example based on the devices IDevID certificate as in BRSKI. The ACP registrar may have a whitelist or blacklist of devices [X.520] "serialNumbers" attribute in the subject field distinguished name encoding from their IDevID certificate. * Policies what type of address prefix to assign to a candidate ACP devices, based on likely the same information. * For BRSKI or other mechanisms using vouchers: Parameters to determine how to retrieve vouchers for specific type of secure bootstrap candidate ACP nodes (such as MASA URLs), unless this information is automatically learned such as from the IDevID certificate of candidate ACP nodes (as defined in BRSKI). 9.2.3. Certificate renewal and limitations When an ACP node renews/rekeys its certificate, it may end up doing so via a different registrar (e.g., EST server) than the one it originally received its ACP certificate from, for example because that original ACP registrar is gone. The ACP registrar through which the renewal/rekeying is performed would by default trust the acp- node-name from the ACP nodes current ACP certificate and maintain this information so that the ACP node maintains its ACP address prefix. In EST renewal/rekeying, the ACP nodes current ACP certificate is signaled during the TLS handshake. This simple scenario has two limitations: 1. The ACP registrars cannot directly assign certificates to nodes and therefore needs an "online" connection to the TA. 2. Recovery from a compromised ACP registrar is difficult. When an ACP registrar is compromised, it can insert for example a conflicting acp-node-name and create thereby an attack against other ACP nodes through the ACP routing protocol. Even when such a malicious ACP registrar is detected, resolving the problem may be difficult because it would require identifying all the wrong ACP certificates assigned via the ACP registrar after it was compromised. And without additional centralized tracking of assigned certificates there is no way to do this. Eckert, et al. Expires 3 May 2021 [Page 106] Internet-Draft An Autonomic Control Plane (ACP) October 2020 9.2.4. ACP Registrars with sub-CA In situations, where either of the above two limitations are an issue, ACP registrars could also be sub-CAs. This removes the need for connectivity to a TA whenever an ACP node is enrolled, and reduces the need for connectivity of such an ACP registrar to a TA to only those times when it needs to renew its own certificate. The ACP registrar would also now use its own (sub-CA) certificate to enroll and sign the ACP nodes certificates, and therefore it is only necessary to revoke a compromised ACP registrars sub-CA certificate. Alternatively one can let it expire and not renew it, when the certificate of the sub-CA is appropriately short-lived. As the ACP domain membership check verifies a peer ACP node's ACP certificate trust chain, it will also verify the signing certificate which is the compromised/revoked sub-CA certificate. Therefore, ACP domain membership for an ACP node enrolled from a compromised and discovered ACP registrar will fail. ACP nodes enrolled by a compromised ACP registrar would automatically fail to establish ACP channels and ACP domain certificate renewal via EST and therefore revert to their role as a candidate ACP members and attempt to get a new ACP certificate from an ACP registrar - for example, via BRSKI. In result, ACP registrars that have an associated sub-CA makes isolating and resolving issues with compromised registrars easier. Note that ACP registrars with sub-CA functionality also can control the lifetime of ACP certificates easier and therefore also be used as a tool to introduce short lived certificates and not rely on CRL, whereas the certificates for the sub-CAs themselves could be longer lived and subject to CRL. 9.2.5. Centralized Policy Control When using multiple, uncoordinated ACP registrars, several advanced operations are potentially more complex than with a single, resilient policy control backend, for example including but not limited to: * Which candidate ACP node is permitted or not permitted into an ACP domain. This may not be a decision to be taken upfront, so that a policy per "serialNumber" attribute in the subject field distinguished name encoding can be loaded into every ACP registrar. Instead, it may better be decided in real-time including potentially a human decision in a NOC. * Tracking of all enrolled ACP nodes and their certificate information. For example, in support of revoking individual ACP nodes certificates. Eckert, et al. Expires 3 May 2021 [Page 107] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * More flexible policies what type of address prefix or even what specific address prefix to assign to a candidate ACP node. These and other operations could be introduced more easily by introducing a centralized Policy Management System (PMS) and modifying ACP registrar behavior so that it queries the PMS for any policy decision occurring during the candidate ACP node enrollment process and/or the ACP node certificate renewal process. For example, which ACP address prefix to assign. Likewise the ACP registrar would report any relevant state change information to the PMS as well, for example when a certificate was successfully enrolled onto a candidate ACP node. 9.3. Enabling and disabling ACP/ANI Both ACP and BRSKI require interfaces to be operational enough to support sending/receiving their packets. In node types where interfaces are by default (e.g., without operator configuration) enabled, such as most L2 switches, this would be less of a change in behavior than in most L3 devices (e.g. routers), where interfaces are by default disabled. In almost all network devices it is common though for configuration to change interfaces to a physically disabled state and that would break the ACP. In this section, we discuss a suggested operational model to enable/ disable interfaces and nodes for ACP/ANI in a way that minimizes the risk of operator action to break the ACP in this way, and that also minimizes operator surprise when ACP/ANI becomes supported in node software. 9.3.1. Filtering for non-ACP/ANI packets Whenever this document refers to enabling an interface for ACP (or BRSKI), it only requires to permit the interface to send/receive packets necessary to operate ACP (or BRSKI) - but not any other Data- Plane packets. Unless the Data-Plane is explicitly configured/ enabled, all packets not required for ACP/BRSKI should be filtered on input and output: Both BRSKI and ACP require link-local only IPv6 operations on interfaces and DULL GRASP. IPv6 link-local operations means the minimum signaling to auto-assign an IPv6 link-local address and talk to neighbors via their link-local address: SLAAC (Stateless Address Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - [RFC4861]). When the device is a BRSKI pledge, it may also require TCP/TLS connections to BRSKI proxies on the interface. When the device has keying material, and the ACP is running, it requires DULL GRASP packets and packets necessary for the secure-channel mechanism Eckert, et al. Expires 3 May 2021 [Page 108] Internet-Draft An Autonomic Control Plane (ACP) October 2020 it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the IPv6 link-local address of an ACP neighbor on the interface. It also requires TCP/TLS packets for its BRSKI proxy functionality, if it does support BRSKI. 9.3.2. Admin Down State Interfaces on most network equipment have at least two states: "up" and "down". These may have product specific names. "down" for example could be called "shutdown" and "up" could be called "no shutdown". The "down" state disables all interface operations down to the physical level. The "up" state enables the interface enough for all possible L2/L3 services to operate on top of it and it may also auto-enable some subset of them. More commonly, the operations of various L2/L3 services is controlled via additional node-wide or interface level options, but they all become only active when the interface is not "down". Therefore, an easy way to ensure that all L2/L3 operations on an interface are inactive is to put the interface into "down" state. The fact that this also physically shuts down the interface is in many cases just a side effect, but it may be important in other cases (see below, Section 9.3.2.2). One of the common problems of remote management is for the operator or SDN controller to cut its own connectivity to the remote node by a configuration impacting its own management connection into the node. The ACP itself should have no dedicated configuration other than aforementioned enablement of the ACP on brownfield ACP nodes. This leaves configuration that cannot distinguish between ACP and Data- Plane as sources of configuration mistakes as these commands will impact the ACP even though they should only impact the Data-Plane. The one ubiquitous type of commands that do this on many type of routers are interface "down" commands/configurations. When such a command is applied to the interface through which the ACP provides access for remote management it would cut the remote management connection through the ACP because, as outlined above, the "down" commands typically impact the physical layer too and not only the Data-Plane services. To provide ACP/ANI resilience against such operator misconfiguration, this document recommends to separate the "down" state of interfaces into an "admin down" state where the physical layer is kept running and ACP/ANI can use the interface and a "physical down" state. Any existing "down" configurations would map to "admin down". In "admin down", any existing L2/L3 services of the Data-Plane should see no difference to "physical down" state. To ensure that no Data-Plane packets could be sent/received, packet filtering could be established automatically as described above in Section 9.3.1. Eckert, et al. Expires 3 May 2021 [Page 109] Internet-Draft An Autonomic Control Plane (ACP) October 2020 An example of non-ACP but ANI traffic that should be permitted to pass even in "admin-down" state is BRSKI enrollment traffic between BRSKI pledge and a BRSKI proxy. As necessary (see discussion below) new configuration options could be introduced to issue "physical down". The options should be provided with additional checks to minimize the risk of issuing them in a way that breaks the ACP without automatic restoration. For example, they could be denied to be issued from a control connection (NETCONF/SSH) that goes across the interface itself ("do not disconnect yourself"). Or they could be performed only temporary and only be made permanent with additional later reconfirmation. In the following sub-sections important aspects to the introduction of "admin down" state are discussed. 9.3.2.1. Security Interfaces are physically brought down (or left in default down state) as a form of security. "Admin down" state as described above provides also a high level of security because it only permits ACP/ ANI operations which are both well secured. Ultimately, it is subject to security review for the deployment whether "admin down" is a feasible replacement for "physical down". The need to trust the security of ACP/ANI operations needs to be weighed against the operational benefits of permitting this: Consider the typical example of a CPE (customer premises equipment) with no on-site network expert. User ports are in physical down state unless explicitly configured not to be. In a misconfiguration situation, the uplink connection is incorrectly plugged into such as user port. The device is disconnected from the network and therefore no diagnostics from the network side is possible anymore. Alternatively, all ports default to "admin down". The ACP (but not the Data-Plane) would still automatically form. Diagnostics from the network side is possible and operator reaction could include to either make this port the operational uplink port or to instruct re- cabling. Security wise, only ACP/ANI could be attacked, all other functions are filtered on interfaces in "admin down" state. 9.3.2.2. Fast state propagation and Diagnostics "Physical down" state propagates on many interface types (e.g., Ethernet) to the other side. This can trigger fast L2/L3 protocol reaction on the other side and "admin down" would not have the same (fast) result. Eckert, et al. Expires 3 May 2021 [Page 110] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Bringing interfaces to "physical down" state is to the best of our knowledge always a result of operator action, but today, never the result of autonomic L2/L3 services running on the nodes. Therefore, one option is to change the operator action to not rely on link-state propagation anymore. This may not be possible when both sides are under different operator control, but in that case it is unlikely that the ACP is running across the link and actually putting the interface into "physical down" state may still be a good option. Ideally, fast physical state propagation is replaced by fast software driven state propagation. For example, a DULL GRASP "admin-state" objective could be used to auto configure a Bidirectional Forwarding Protocol (BFD, [RFC5880]) session between the two sides of the link that would be used to propagate the "up" vs. admin down state. Triggering physical down state may also be used as a mean of diagnosing cabling in the absence of easier methods. It is more complex than automated neighbor diagnostics because it requires coordinated remote access to both (likely) sides of a link to determine whether up/down toggling will cause the same reaction on the remote side. See Section 9.1 for a discussion about how LLDP and/or diagnostics via GRASP could be used to provide neighbor diagnostics, and therefore hopefully eliminating the need for "physical down" for neighbor diagnostics - as long as both neighbors support ACP/ANI. 9.3.2.3. Low Level Link Diagnostics "Physical down" is performed to diagnose low-level interface behavior when higher layer services (e.g., IPv6) are not working. Especially Ethernet links are subject to a wide variety of possible wrong configuration/cablings if they do not support automatic selection of variable parameters such as speed (10/100/1000 Mbps), crossover (Auto-MDIX) and connector (fiber, copper - when interfaces have multiple but can only enable one at a time). The need for low level link diagnostic can therefore be minimized by using fully auto configuring links. In addition to "Physical down", low level diagnostics of Ethernet or other interfaces also involve the creation of other states on interfaces, such as physical Loopback (internal and/or external) or bringing down all packet transmissions for reflection/cable-length measurements. Any of these options would disrupt ACP as well. In cases where such low-level diagnostics of an operational link is desired but where the link could be a single point of failure for the ACP, ASA on both nodes of the link could perform a negotiated Eckert, et al. Expires 3 May 2021 [Page 111] Internet-Draft An Autonomic Control Plane (ACP) October 2020 diagnostic that automatically terminates in a predetermined manner without dependence on external input ensuring the link will become operational again. 9.3.2.4. Power Consumption Issues Power consumption of "physical down" interfaces, may be significantly lower than those in "admin down" state, for example on long-range fiber interfaces. Bringing up interfaces, for example to probe reachability, may also consume additional power. This can make these type of interfaces inappropriate to operate purely for the ACP when they are not currently needed for the Data-Plane. 9.3.3. Interface level ACP/ANI enable The interface level configuration option "ACP enable" enables ACP operations on an interface, starting with ACP neighbor discovery via DULL GRAP. The interface level configuration option "ANI enable" on nodes supporting BRSKI and ACP starts with BRSKI pledge operations when there is no domain certificate on the node. On ACP/BRSKI nodes, "ACP enable" may not need to be supported, but only "ANI enable". Unless overridden by global configuration options (see later), "ACP/ ANI enable" will result in "down" state on an interface to behave as "admin down". 9.3.4. Which interfaces to auto-enable? (Section 6.4) requires that "ACP enable" is automatically set on native interfaces, but not on non-native interfaces (reminder: a native interface is one that exists without operator configuration action such as physical interfaces in physical devices). Ideally, ACP enable is set automatically on all interfaces that provide access to additional connectivity that allows to reach more nodes of the ACP domain. The best set of interfaces necessary to achieve this is not possible to determine automatically. Native interfaces are the best automatic approximation. Eckert, et al. Expires 3 May 2021 [Page 112] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Consider an ACP domain of ACP nodes transitively connected via native interfaces. A Data-Plane tunnel between two of these nodes that are non-adjacent is created and "ACP enable" is set for that tunnel. ACP RPL sees this tunnel as just as a single hop. Routes in the ACP would use this hop as an attractive path element to connect regions adjacent to the tunnel nodes. In result, the actual hop-by-hop paths used by traffic in the ACP can become worse. In addition, correct forwarding in the ACP now depends on correct Data-Plane forwarding config including QoS, filtering and other security on the Data-Plane path across which this tunnel runs. This is the main issue why "ACP/ ANI enable" should not be set automatically on non-native interfaces. If the tunnel would connect two previously disjoint ACP regions, then it likely would be useful for the ACP. A Data-Plane tunnel could also run across nodes without ACP and provide additional connectivity for an already connected ACP network. The benefit of this additional ACP redundancy has to be weighed against the problems of relying on the Data-Plane. If a tunnel connects two separate ACP regions: how many tunnels should be created to connect these ACP regions reliably enough? Between which nodes? These are all standard tunneled network design questions not specific to the ACP, and there are no generic fully automated answers. Instead of automatically setting "ACP enable" on these type of interfaces, the decision needs to be based on the use purpose of the non-native interface and "ACP enable" needs to be set in conjunction with the mechanism through which the non-native interface is created/ configured. In addition to explicit setting of "ACP/ANI enable", non-native interfaces also need to support configuration of the ACP RPL cost of the link - to avoid the problems of attracting too much traffic to the link as described above. Even native interfaces may not be able to automatically perform BRSKI or ACP because they may require additional operator input to become operational. Example include DSL interfaces requiring PPPoE credentials or mobile interfaces requiring credentials from a SIM card. Whatever mechanism is used to provide the necessary config to the device to enable the interface can also be expanded to decide on whether or not to set "ACP/ANI enable". The goal of automatically setting "ACP/ANI enable" on interfaces (native or not) is to eliminate unnecessary "touches" to the node to make its operation as much as possible "zero-touch" with respect to ACP/ANI. If there are "unavoidable touches" such a creating/ configuring a non-native interface or provisioning credentials for a native interface, then "ACP/ANI enable" should be added as an option Eckert, et al. Expires 3 May 2021 [Page 113] Internet-Draft An Autonomic Control Plane (ACP) October 2020 to that "touch". If a wrong "touch" is easily fixed (not creating another high-cost touch), then the default should be not to enable ANI/ACP, and if it is potentially expensive or slow to fix (e.g., parameters on SIM card shipped to remote location), then the default should be to enable ACP/ANI. 9.3.5. Node Level ACP/ANI enable A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI on the node (ANI = ACP + BRSKI). Without this command set, any interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will operate an interface where "ACP/ANI enable" is set. Setting of interface level "ACP/ANI enable" is either automatic (default) or explicit through operator action as described in the previous section. If the option "up-if-only" is selected, the behavior of "down" interfaces is unchanged, and ACP/ANI will only operate on interfaces where "ACP/ANI enable" is set and that are "up". When it is not set, then "down" state of interfaces with "ACP/ANI enable" is modified to behave as "admin down". 9.3.5.1. Brownfield nodes A "brownfield" node is one that already has a configured Data-Plane. Executing global "ACP/ANI enable [up-if-only]" on each node is the only command necessary to create an ACP across a network of brownfield nodes once all the nodes have a domain certificate. When BRSKI is used ("ANI enable"), provisioning of the certificates only requires set-up of a single BRSKI registrar node which could also implement a CA for the network. This is the simplest way to introduce ACP/ANI into existing (== brownfield) networks. The need to explicitly enable ACP/ANI is especially important in brownfield nodes because otherwise software updates may introduce support for ACP/ANI: Automatic enablement of ACP/ANI in networks where the operator does not only not want ACP/ANI but where the operator likely never even heard of it could be quite irritating to the operator. Especially when "down" behavior is changed to "admin down". Eckert, et al. Expires 3 May 2021 [Page 114] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Automatically setting "ANI enable" on brownfield nodes where the operator is unaware of BRSKI and MASA operations could also be an unlikely but then critical security issue. If an attacker could impersonate the operator and register as the operator at the MASA or otherwise get hold of vouchers and can get enough physical access to the network so pledges would register to an attacking registrar, then the attacker could gain access to the ACP, and through the ACP gain access to the Data-Plane. In networks where the operator explicitly wants to enable the ANI this could not happen, because the operator would create a BRSKI registrar that would discover attack attempts, and the operator would be setting up his registrar with the MASA. Nodes requiring "ownership vouchers" would not be subject to that attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more details. Note that a global "ACP enable" alone is not subject to these type of attacks, because it always depends on some other mechanism first to provision domain certificates into the device. 9.3.5.2. Greenfield nodes An ACP "greenfield" node is one that does not have any prior configuration and that can be bootstrapped into the ACP across the network. To support greenfield nodes, ACP as described in this document needs to be combined with a bootstrap protocol/mechanism that will enroll the node with the ACP keying material - ACP certificate and TA. For ANI nodes, this protocol/mechanism is BRSKI. When such a node is powered on and determines it is in greenfield condition, it enables the bootstrap protocol(s)/mechanism(s), and once the ACP keying material is enrolled, greenfield state ends and the ACP is started. When BRSKI is used, the node's state reflects this by setting "ANI enable" upon determination of greenfield state at power on. ACP greenfield nodes that in the absence of ACP would have their interfaces in "down" state SHOULD set all native interfaces into "admin down" state and only permit Data-Plane traffic required for the bootstrap protocol/mechanisms. ACP greenfield state ends either through successful enrolment of ACP keying material (certificate, TA) or detection of a permitted termination of ACP greenfield operations. ACP nodes supporting greenfield operations MAY want to provide backward compatibility with other forms of configuration/ provisioning, especially when only a subset of nodes are expected to be deployed with ACP. Such an ACP node SHOULD observe attempts to Eckert, et al. Expires 3 May 2021 [Page 115] Internet-Draft An Autonomic Control Plane (ACP) October 2020 provision/configure the node via interfaces/methods that traditionally indicate physical possession of the node, such as a serial or USB console port or a USB memory stick with a bootstrap configuration. When such an operation is observed before enrollment of the ACP keying material has completed, the node SHOULD put itself into the state the node would have been in, if ACP/ANI was disabled at boot (terminate ACP greenfield operations). When an ACP greenfield node enables multiple automated ACP or non-ACP enrollment/bootstrap protocols/mechanisms in parallel, care must be taken not to terminate any protocol/mechanism before another one has succeeded to enroll ACP keying material or has progressed to a point where it is permitted to be a termination reason for ACP greenfield operations. Highly secure ACP greenfield nodes may not permit any reason to terminate ACP greenfield operations, including physical access. Nodes that claim to support ANI greenfield operations SHOULD NOT enable in parallel to BRSKI any enrollment/bootstrap protocol/ mechanism that allows Trust On First Use (TOFU, [RFC7435]) over interfaces other than those traditionally indicating physical possession of the node. Protocols/mechanisms with published default username/password authentication are considered to suffer from TOFU. Securing the bootstrap protocol/mechanism by requiring a voucher ([RFC8366]) can be used to avoid TOFU. In summary, the goal of ACP greenfield support is to allow remote automated enrollment of ACP keying materials, and therefore automated bootstrap into the ACP and to prohibit TOFU during bootstrap with the likely exception (for backward compatibility) of bootstrapping via interfaces traditionally indicating physical possession of the node. 9.3.6. Undoing ANI/ACP enable Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the reliable operations of the ACP if it can be executed by mistake or unauthorized. This behavior could be influenced through some additional (future) property in the certificate (e.g., in the acp- node-name extension field): In an ANI deployment intended for convenience, disabling it could be allowed without further constraints. In an ANI deployment considered to be critical more checks would be required. One very controlled option would be to not permit these commands unless the domain certificate has been revoked or is denied renewal. Configuring this option would be a parameter on the BRSKI registrar(s). As long as the node did not receive a domain certificate, undoing "ANI/ACP enable" should not have any additional constraints. Eckert, et al. Expires 3 May 2021 [Page 116] Internet-Draft An Autonomic Control Plane (ACP) October 2020 9.3.7. Summary Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation of ACP/ANI. This is only auto-enabled on ANI greenfield devices, otherwise it must be configured explicitly. If the option "up-if-only" is not selected, interfaces enabled for ACP/ANI interpret "down" state as "admin down" and not "physical down". In "admin-down" all non-ACP/ANI packets are filtered, but the physical layer is kept running to permit ACP/ANI to operate. (New) commands that result in physical interruption ("physical down", "loopback") of ACP/ANI enabled interfaces should be built to protect continuance or reestablishment of ACP as much as possible. Interface level "ACP/ANI enable" control per-interface operations. It is enabled by default on native interfaces and has to be configured explicitly on other interfaces. Disabling "ACP/ANI enable" global and per-interface should have additional checks to minimize undesired breakage of ACP. The degree of control could be a domain wide parameter in the domain certificates. 9.4. Partial or Incremental adoption The ACP Zone Addressing Sub-Scheme (see Section 6.11.3) allows incremental adoption of the ACP in a network where ACP can be deployed on edge areas, but not across the core that is connecting those edges. In such a setup, each edge network, such as a branch or campus of an enterprise network has a disjoined ACP to which one or more unique Zone-IDs are assigned: ACP nodes registered for a specific ACP zone have to receive ACP Zone Addressing Sub-scheme addresses, for example by virtue of configuring for each such zone one or more ACP Registrars with that Zone-ID. All the Registrars for these ACP Zones need to get ACP certificates from CAs relying on a common set of TA and of course the same ACP domain name. These ACP zones can first be brought up as separate networks without any connection between them and/or they can be connected across a non-ACP enabled core network through various non-autonomic operational practices. For example, each separate ACP Zone can have an edge node that is a layer 3 VPN PE (MPLS or IPv6 layer 3 VPN), where a complete non-autonomic ACP-Core VPN is created by using the ACP VRFs and exchanging the routes from those ACP VRFs across the VPNs non-autonomic routing protocol(s). Eckert, et al. Expires 3 May 2021 [Page 117] Internet-Draft An Autonomic Control Plane (ACP) October 2020 While such a setup is possible with any ACP addressing sub-scheme, the ACP-Zone Addressing sub-scheme makes it easy to configure and scalable for any VPN routing protocols because every ACP zone would only need to indicate one or more /64 ACP Zone Addressing prefix routes into the ACP-Core VPN as opposed to routes for every individual ACP node as required in the other ACP addressing schemes. Note that the non-autonomous ACP-Core VPN would require additional extensions to propagate GRASP messages when GRASP discovery is desired across the zones. For example, one could set up on each Zone edge router a remote ACP tunnel to a GRASP hub. The GRASP hub could be implemented at the application level and could run in the NOC of the network. It would serve to propagate GRASP announcements between ACP Zones and/or generate GRASP announcements for NOC services. Such a partial deployment may prove to be sufficient or could evolve to become more autonomous through future standardized or non- standardized enhancements, for example by allowing GRASP messages to be propagated across the layer 3 VPN, leveraging for example L3VPN Multicast support. Finally, these partial deployments can be merged into a single contiguous complete autonomous ACP (given appropriate ACP support across the core) without changes in the crypto material, because the node's ACP certificates are from a single ACP. 9.5. Configuration and the ACP (summary) There is no desirable configuration for the ACP. Instead, all parameters that need to be configured in support of the ACP are limitations of the solution, but they are only needed in cases where not all components are made autonomic. Wherever this is necessary, it relies on pre-existing mechanisms for configuration such as CLI or YANG ([RFC7950]) data models. The most important examples of such configuration include: * When ACP nodes do not support an autonomic way to receive an ACP certificate, for example BRSKI, then such certificate needs to be configured via some pre-existing mechanisms outside the scope of this specification. Today, router have typically a variety of mechanisms to do this. * Certificate maintenance requires PKI functions. Discovery of these functions across the ACP is automated (see Section 6.2.5), but their configuration is not. Eckert, et al. Expires 3 May 2021 [Page 118] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * When non-ACP capable nodes such as pre-existing NMS need to be physically connected to the ACP, the ACP node to which they attach needs to be configured with ACP-connect according to Section 8.1. It is also possible to use that single physical connection to connect both to ACP and the Data-Plane of the network as explained in Section 8.1.4. * When devices are not autonomically bootstrapped, explicit configuration to enable the ACP needs to be applied. See Section 9.3. * When the ACP needs to be extended across interfaces other than L2, the ACP as defined in this document cannot autodiscover candidate neighbors automatically. Remote neighbors need to be configured, see Section 8.2. Once the ACP is operating, any further configuration for the Data- Plane can be configured more reliably across the ACP itself because the ACP provides addressing and connectivity (routing) independent of the Data-Plane itself. For this, the configuration methods simply need to also allow to operate across the ACP VRF - NETCONF, SSH or any other method. The ACP also provides additional security through its hop-by-hop encryption for any such configuration operations: Some legacy configuration methods (SNMP, TFTP, HTTP) may not use end-to-end encryption, and most of the end-to-end secured configuration methods still allow for easy passive observation along the path about configuration taking place (transport flows, port numbers, IP addresses). The ACP can and should equally be used as the transport to configure any of the aforementioned non-autonomic components of the ACP, but in that case, the same caution needs to be exercised as with Data-Plane configuration without ACP: Misconfiguration may cause the configuring entity to be disconnected from the node it configures - for example when incorrectly unconfiguring a remote ACP neighbor through which the configured ACP node is reached. 10. Summary: Benefits (Informative) 10.1. Self-Healing Properties The ACP is self-healing: * New neighbors will automatically join the ACP after successful validation and will become reachable using their unique ULA address across the ACP. Eckert, et al. Expires 3 May 2021 [Page 119] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * When any changes happen in the topology, the routing protocol used in the ACP will automatically adapt to the changes and will continue to provide reachability to all nodes. * The ACP tracks the validity of peer certificates and tears down ACP secure channels when a peer certificate has expired. When short-lived certificates with lifetimes in the order of OCSP/CRL refresh times are used, then this allows for removal of invalid peers (whose certificate was not renewed) at similar speeds as when using OCSP/CRL. The same benefit can be achieved when using CRL/OCSP, periodically refreshing the revocation information and also tearing down ACP secure channels when the peer's (long-lived) certificate is revoked. There is no requirement against ACP implementations to require this enhancement though to keep the mandatory implementations simpler. The ACP can also sustain network partitions and mergers. Practically all ACP operations are link local, where a network partition has no impact. Nodes authenticate each other using the domain certificates to establish the ACP locally. Addressing inside the ACP remains unchanged, and the routing protocol inside both parts of the ACP will lead to two working (although partitioned) ACPs. There are few central dependencies: A CRL may not be available during a network partition; a suitable policy to not immediately disconnect neighbors when no CRL is available can address this issue. Also, an ACP Registrar or Certification Authority might not be available during a partition. This may delay renewal of certificates that are to expire in the future, and it may prevent the enrollment of new nodes during the partition. Highly resilient ACP designs can be built by using ACP Registrars with embedded sub-CA, as outlined in Section 9.2.4. As long as a partition is left with one or more of such ACP Registrars, it can continue to enroll new candidate ACP nodes as long as the ACP Registrar's sub-CA certificate does not expire. Because the ACP addressing relies on unique Registrar-IDs, a later re-merge of partitions will also not cause problems with ACP addresses assigned during partitioning. After a network partition, a re-merge will just establish the previous status, certificates can be renewed, the CRL is available, and new nodes can be enrolled everywhere. Since all nodes use the same TA, a re-merge will be smooth. Eckert, et al. Expires 3 May 2021 [Page 120] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Merging two networks with different TA requires the ACP nodes to trust the union of TA. As long as the routing-subdomain hashes are different, the addressing will not overlap. Accidentally, overlaps will only happen in the unlikely event of a 40-bit hash collision in SHA256 (see Section 6.11). Note that the complete mechanisms to merge networks is out of scope of this specification. It is also highly desirable for implementation of the ACP to be able to run it over interfaces that are administratively down. If this is not feasible, then it might instead be possible to request explicit operator override upon administrative actions that would administratively bring down an interface across which the ACP is running. Especially if bringing down the ACP is known to disconnect the operator from the node. For example, any such down administrative action could perform a dependency check to see if the transport connection across which this action is performed is affected by the down action (with default RPL routing used, packet forwarding will be symmetric, so this is actually possible to check). 10.2. Self-Protection Properties 10.2.1. From the outside As explained in Section 6, the ACP is based on secure channels built between nodes that have mutually authenticated each other with their domain certificates. The channels themselves are protected using standard encryption technologies such as DTLS or IPsec which provide additional authentication during channel establishment, data integrity and data confidentiality protection of data inside the ACP and in addition, provide replay protection. Attacker will not be able to join the ACP unless they have a valid ACP certificate. On-path attackers without a valid ACP certificate cannot inject packets into the ACP due to ACP secure channels. They can also not decrypt ACP traffic except if they can crack the encryption. They can attempt behavioral traffic analysis on the encrypted ACP traffic. Eckert, et al. Expires 3 May 2021 [Page 121] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The degree to which compromised ACP nodes can impact the ACP depends on the implementation of the ACP nodes and their impairment. When an attacker has only gained administrative privileges to configure ACP nodes remotely, the attacker can disrupt the ACP only through one of the few configuration options to disable it, see Section 9.3, or by configuring of non-autonomic ACP options if those are supported on the impaired ACP nodes, see Section 8. Injecting or extracting traffic into/from an impaired ACP node is only possible when an impaired ACP node supports ACP connect (see Section 8.1) and the attacker can control traffic into/from one of the ACP nodes interfaces, such as by having physical access to the ACP node. The ACP also serves as protection (through authentication and encryption) for protocols relevant to OAM that may not have secured protocol stack options or where implementation or deployment of those options fail on some vendor/product/customer limitations. This includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog ([RFC3164]), RADIUS ([RFC2865]), Diameter ([RFC6733]), TACACS ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a few. Not all of these protocol references are necessarily the latest version of protocols but versions that are still widely deployed. Protection via the ACP secure hop-by-hop channels for these protocols is meant to be only a stopgap though: The ultimate goal is for these and other protocols to use end-to-end encryption utilizing the domain certificate and rely on the ACP secure channels primarily for zero- touch reliable connectivity, but not primarily for security. The remaining attack vector would be to attack the underlying ACP protocols themselves, either via directed attacks or by denial-of- service attacks. However, as the ACP is built using link-local IPv6 addresses, remote attacks from the Data-Plane are impossible as long as the Data-Plane has no facilities to remotely send IPv6 link-local packets. The only exceptions are ACP connected interfaces which require higher physical protection. The ULA addresses are only reachable inside the ACP context, therefore, unreachable from the Data-Plane. Also, the ACP protocols should be implemented to be attack resistant and not consume unnecessary resources even while under attack. 10.2.2. From the inside The security model of the ACP is based on trusting all members of the group of nodes that receive an ACP certificate for the same domain. Attacks from the inside by a compromised group member are therefore the biggest challenge. Eckert, et al. Expires 3 May 2021 [Page 122] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Group members must be protected against attackers so that there is no easy way to compromise them, or use them as a proxy for attacking other devices across the ACP. For example, management plane functions (transport ports) should only be reachable from the ACP but not the Data-Plane. Especially for those management plane functions that have no good protection by themselves because they do not have secure end-to-end transport and to whom ACP not only provides automatic reliable connectivity but also protection against attacks. Protection across all potential attack vectors is typically easier to do in devices whose software is designed from the ground up with ACP in mind than with legacy software based systems where the ACP is added on as another feature. As explained above, traffic across the ACP should still be end-to-end encrypted whenever possible. This includes traffic such as GRASP, EST and BRSKI inside the ACP. This minimizes man in the middle attacks by compromised ACP group members. Such attackers cannot eavesdrop or modify communications, they can just filter them (which is unavoidable by any means). See Appendix A.9.8 for further considerations how to avoid and deal with compromised nodes. 10.3. The Administrator View An ACP is self-forming, self-managing and self-protecting, therefore has minimal dependencies on the administrator of the network. Specifically, since it is (intended to be) independent of configuration, there is only limited scope for configuration errors on the ACP itself. The administrator may have the option to enable or disable the entire approach, but detailed configuration is not possible. This means that the ACP must not be reflected in the running configuration of nodes, except a possible on/off switch (and even that is undesirable). While configuration (except for Section 8 and Section 9.2) is not possible, an administrator must have full visibility of the ACP and all its parameters, to be able to do trouble-shooting. Therefore, an ACP must support all show and debug options, as for any other network function. Specifically, a network management system or controller must be able to discover the ACP, and monitor its health. This visibility of ACP operations must clearly be separated from visibility of Data-Plane so automated systems will never have to deal with ACP aspects unless they explicitly desire to do so. Eckert, et al. Expires 3 May 2021 [Page 123] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Since an ACP is self-protecting, a node not supporting the ACP, or without a valid domain certificate cannot connect to it. This means that by default a traditional controller or network management system cannot connect to an ACP. See Section 8.1.1 for more details on how to connect an NMS host into the ACP. 11. Security Considerations A set of ACP nodes with ACP certificates for the same ACP domain and with ACP functionality enabled is automatically "self-building": The ACP is automatically established between neighboring ACP nodes. It is also "self-protecting": The ACP secure channels are authenticated and encrypted. No configuration is required for this. The self-protecting property does not include workarounds for non- autonomic components as explained in Section 8. See Section 10.2 for details of how the ACP protects itself against attacks from the outside and to a more limited degree from the inside as well. However, the security of the ACP depends on a number of other factors: * The usage of domain certificates depends on a valid supporting PKI infrastructure. If the chain of trust of this PKI infrastructure is compromised, the security of the ACP is also compromised. This is typically under the control of the network administrator. * ACP nodes receive their certificates from ACP registrars. These ACP registrars are security critical dependencies of the ACP: Procedures and protocols for ACP registrars are outside the scope of this specification as explained in Section 6.11.7.1, only requirements against the resulting ACP certificates are specified. * Every ACP registrar (for enrollment of ACP certificates) and ACP EST server (for renewal of ACP certificates) is a security critical entity and its protocols are security critical protocols. Both need to be hardened against attacks, similar to a CA and its protocols. A malicious registrar can enroll malicious nodes to an ACP network (if the CA delegates this policy to the registrar) or break ACP routing for example by assigning duplicate ACP address assignment to ACP nodes via their ACP certificates. * ACP nodes that are ANI nodes rely on BRSKI as the protocol for ACP registrars. For ANI type ACP nodes, the security considerations of BRSKI apply. It enables automated, secure enrollment of ACP certificates. * BRSKI and potentially other ACP registrar protocol options require that nodes have an (X.509v3 based) IDevID. IDevIDs are an option for ACP registrars to securely identify candidate ACP nodes that should be enrolled into an ACP domain. Eckert, et al. Expires 3 May 2021 [Page 124] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * For IDevIDs to securely identify the node to which it IDevID is assigned, the node needs to (1) utilize hardware support such as a Trusted Platform Module (TPM) to protect against extraction/ cloning of the private key of the IDevID and (2) a hardware/ software infrastructure to prohibit execution of non-authenticated software to protect against malicious use of the IDevID. * Like the IDevID, the ACP certificate should equally be protected from extraction or other abuse by the same ACP node infrastructure. This infrastructure for IDevID and ACP certificate is beneficial independent of the ACP registrar protocol used (BRSKI or other). * Renewal of ACP certificates requires support for EST, therefore the security considerations of [RFC7030] related to certificate renewal/rekeying and TP renewal apply to the ACP. EST security considerations when using other than mutual certificate authentication do not apply nor do considerations for initial enrollment via EST apply, except for ANI type ACP nodes because BRSKI leverages EST. * A malicious ACP node could declare itself to be an EST server via GRASP across the ACP if malicious software could be executed on it. CA should therefore authenticate only known trustworthy EST servers, such as nodes with hardware protections against malicious software. When Registrars use their ACP certificate to authenticate towards a CA, the id-kp-cmcRA [RFC6402] extended key usage attribute allows the CA to determine that the ACP node was permitted during enrollment to act as an ACP registrar. Without the ability to talk to the CA, a malicious EST server can still attract ACP nodes attempting to renew their keying material, but they will fail to perform successful renewal of a valid ACP certificate. The ACP node attempting to use the malicious EST server can then continue to use a different EST server, and log a failure against a malicious EST server. * Malicious on-path ACP nodes may filter valid EST server announcements across the ACP, but such malicious ACP nodes could equally filter any ACP traffic such as the EST traffic itself. Either attack requires the ability to execute malicious software on an impaired ACP node though. * In the absence of malicious software injection, an attacker that can misconfigure an ACP node which is supporting EST server functionality could attempt to configure a malicious CA. This would not result in the ability to successfully renew ACP certificates, but it could result in DoS attacks by becoming an EST server and making ACP nodes attempting their ACP certificate renewal via this impaired ACP node. This problem can be avoided when the EST server implementation can verify that the CA configured is indeed providing renewal for certificates of the node's ACP. The ability to do so depends on the EST-Server to CA protocol, which is outside the scope of this document. Eckert, et al. Expires 3 May 2021 [Page 125] Internet-Draft An Autonomic Control Plane (ACP) October 2020 In summary, attacks against the PKI/certificate dependencies of the ACP can be minimized by a variety of hardware/software components including options such as TPM for IDevID/ACP-certificate, prohibitions against execution of non-trusted software and design aspects of the EST Server functionality for the ACP to eliminate configuration level impairment. Because ACP peers select one out of potentially more than one mutually supported ACP secure channel protocols via the approach described in Section 6.6, ACP secure channel setup is subject to downgrade attacks by MITM attackers. This can be discovered after such an attack by additional mechanisms described in Appendix A.9.9. Alternatively, more advanced channel selection mechanisms can be devised. [RFC-Editor: Please remove the following sentence]. See [ACPDRAFT] Appendix B.1. Both options are out of scope of this document. The security model of the ACP as defined in this document is tailored for use with private PKI. The TA of a private PKI provide the security against maliciously created ACP certificates to give access to an ACP. Such attacks can create fake ACP certificates with correct looking AcpNodeNames, but those certificates would not pass the certificate path validation of the ACP domain membership check (see Section 6.2.3, point 2). [RFC-Editor: please remove the following paragraph]. Using public CA is out of scope of this document. See [ACPDRAFT], Appendix B.3 for further considerations. There is no prevention of source-address spoofing inside the ACP. This implies that if an attacker gains access to the ACP, it can spoof all addresses inside the ACP and fake messages from any other node. New protocol/services run across the ACP should therefore use end-to-end authentication inside the ACP. This is already done by GRASP as specified in this document. The ACP is designed to enable automation of current network management and future autonomic peer-to-peer/distributed network automation. Any ACP member can send ACP IPv6 packet to other ACP members and announce via ACP GRASP services to all ACP members without dependency against centralized components. The ACP relies on peer-to-peer authentication and authorization using ACP certificates. This security model is necessary to enable the autonomic ad-hoc any-to-any connectivity between ACP nodes. It provides infrastructure protection through hop by hop authentication and encryption - without relying on third parties. For any services Eckert, et al. Expires 3 May 2021 [Page 126] Internet-Draft An Autonomic Control Plane (ACP) October 2020 where this complete autonomic peer-to-peer group security model is appropriate, the ACP certificate can also be used unchanged. For example, for any type of Data-Plane routing protocol security. This ACP security model is designed primarily to protect against attack from the outside, but not against attacks from the inside. To protect against spoofing attacks from compromised on-path ACP nodes, end-to-end encryption inside the ACP is used by new ACP signaling: GRASP across the ACP using TLS. The same is expected from any non- legacy services/protocols using the ACP. Because no group-keys are used, there is no risk for impacted nodes to access end-to-end encrypted traffic from other ACP nodes. Attacks from impacted ACP nodes against the ACP are more difficult than against the Data-Plane because of the autoconfiguration of the ACP and the absence of configuration options that could be abused that allow to change/break ACP behavior. This is excluding configuration for workaround in support of non-autonomic components. Mitigation against compromised ACP members is possible through standard automated certificate management mechanisms including revocation and non-renewal of short-lived certificates. In this version of the specification, there are no further optimization of these mechanisms defined for the ACP (but see Appendix A.9.8). Higher layer service built using ACP certificates should not solely rely on undifferentiated group security when another model is more appropriate/more secure. For example, central network configuration relies on a security model where only few especially trusted nodes are allowed to configure the Data-Plane of network nodes (CLI, NETCONF). This can be done through ACP certificates by differentiating them and introduce roles. See Appendix A.9.5. Operators and provisioning software developers need to be aware of how the provisioning/configuration of network devices impacts the ability of the operator / provisioning software to remotely access the network nodes. By using the ACP, most of the issues of configuration/provisioning caused loss of connectivity for remote provisioning/configuration will be eliminated, see Section 6. Only few exceptions such as explicit physical interface down configuration will be left Section 9.3.2. Many details of ACP are designed with security in mind and discussed elsewhere in the document: Eckert, et al. Expires 3 May 2021 [Page 127] Internet-Draft An Autonomic Control Plane (ACP) October 2020 IPv6 addresses used by nodes in the ACP are covered as part of the node's domain certificate as described in Section 6.2.2. This allows even verification of ownership of a peer's IPv6 address when using a connection authenticated with the domain certificate. The ACP acts as a security (and transport) substrate for GRASP inside the ACP such that GRASP is not only protected by attacks from the outside, but also by attacks from compromised inside attackers - by relying not only on hop-by-hop security of ACP secure channels, but adding end-to-end security for those GRASP messages. See Section 6.9.2. ACP provides for secure, resilient zero-touch discovery of EST servers for certificate renewal. See Section 6.2.5. ACP provides extensible, auto-configuring hop-by-hop protection of the ACP infrastructure via the negotiation of hop-by-hop secure channel protocols. See Section 6.6. The ACP is designed to minimize attacks from the outside by minimizing its dependency against any non-ACP (Data-Plane) operations/configuration on a node. See also Section 6.13.2. In combination with BRSKI, ACP enables a resilient, fully zero-touch network solution for short-lived certificates that can be renewed or re-enrolled even after unintentional expiry (e.g., because of interrupted connectivity). See Appendix A.2. Because ACP secure channels can be long lived, but certificates used may be short lived, secure channels, for example built via IPsec need to be terminated when peer certificates expire. See Section 6.8.5. Section 7.2 describes how to implement a routed ACP topology operating on what effectively is a large bridge-domain when using L3/ L2 routers that operate at L2 in the Data-Plane. In this case, the ACP is subject to much higher likelihood of attacks by other nodes "stealing" L2 addresses than in the actual routed case. Especially when the bridged network includes non-trusted devices such as hosts. This is a generic issue in L2 LANs. L2/L3 devices often already have some form of "port security" to prohibit this. They rely on NDP or DHCP learning of which port/MAC-address and IPv6 address belong together and block MAC/IPv6 source addresses from wrong ports. This type of function needs to be enabled to prohibit DoS attacks and specifically to protect the ACP. Likewise the GRASP DULL instance needs to ensure that the IPv6 address in the locator-option matches the source IPv6 address of the DULL GRASP packet. Eckert, et al. Expires 3 May 2021 [Page 128] Internet-Draft An Autonomic Control Plane (ACP) October 2020 12. IANA Considerations This document defines the "Autonomic Control Plane". For the ANIMA-ACP-2020 ASN.1 module, IANA is asked to register value IANA1 for "id-mod-anima-acpnodename-2020" in the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry. For the otherName / AcpNodeName, IANA is asked to register a value for IANA2 for id-on-AcpNodeName in the "SMI Security for PKIX Other Name Forms" (1.3.6.1.5.5.7.8) registry. The IANA is requested to register the value "AN_ACP" (without quotes) to the GRASP Objectives Names Table in the GRASP Parameter Registry. The specification for this value is this document, Section 6.4. The IANA is requested to register the value "SRV.est" (without quotes) to the GRASP Objectives Names Table in the GRASP Parameter Registry. The specification for this value is this document, Section 6.2.5. Explanation: This document chooses the initially strange looking format "SRV." because these objective names would be in line with potential future simplification of the GRASP objective registry. Today, every name in the GRASP objective registry needs to be explicitly allocated with IANA. In the future, this type of objective names could be considered to be automatically registered in that registry for the same service for which a is registered according to [RFC6335]. This explanation is solely informational and has no impact on the requested registration. The IANA is requested to create an ACP Parameter Registry with currently one registry table - the "ACP Address Type" table. "ACP Address Type" Table. The value in this table are numeric values 0...3 paired with a name (string). Future values MUST be assigned using the Standards Action policy defined by [RFC8126]. The following initial values are assigned by this document: 0: ACP Zone Addressing Sub-Scheme (ACP RFC Section 6.11.3) 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.11.5) / ACP Manual Addressing Sub-Scheme (ACP RFC Section 6.11.4) Eckert, et al. Expires 3 May 2021 [Page 129] Internet-Draft An Autonomic Control Plane (ACP) October 2020 13. Acknowledgements This work originated from an Autonomic Networking project at Cisco Systems, which started in early 2010. Many people contributed to this project and the idea of the Autonomic Control Plane, amongst which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael Richardson, Ravi Kumar Vadapalli. Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and Sheng Jiang for their thorough reviews. Many thanks Ben Kaduk, Roman Danyliv and Eric Rescorla for their thorough SEC AD reviews, Russ Housley and Erik Kline for their reviews and to Valery Smyslov, Tero Kivinen, Paul Wouters and Yoav Nir for review of IPsec and IKEv2 parameters and helping to understand those and other security protocol details better. Thanks for Carsten Borman for CBOR/CDDL help. Further input, review or suggestions were received from: Rene Struik, Benoit Claise, William Atwood and Yongkang Zhang. 14. Contributors For all things GRASP including validation code, ongoing document text support and technical input. Brian Carpenter School of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com For RPL contributions and all things BRSKI/bootstrap including validation code, ongoing document text support and technical input. Michael C. Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/mcr/ For the RPL technology choices and text. Eckert, et al. Expires 3 May 2021 [Page 130] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Pascal Thubert Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 06254 MOUGINS - Sophia Antipolis France Phone: +33 497 23 26 34 Email: pthubert@cisco.com 15. Change log [RFC-Editor: Please remove] This document was developed on https://github.com/anima-wg/autonomic- control-plane/tree/master/draft-ietf-anima-autonomic-control-plane. That github repository also contains the document review/reply emails. 15.1. Summary of changes since entering IESG review This text replaces the prior changelog with a summary to provide guidance for further IESG review. Please see revision -21 for the individual changelogs of prior versions . 15.1.1. Reviews (while in IESG review status) / status This document entered IESG review with version -13. It has since seen the following reviews: IESG: Original owner/Yes: Terry Manderson (INT). IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), Warren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), Adam Roach (ART). IESG: No Objection, not counted anymore as they have left IESG: Ben Campbell (ART), Spencer Dawkins (TSV). IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorla (SEC, left IESG), Benjamin Kaduk (SEC). Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thubert (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), Yongkang Zhang (WG), William Atwood (WG). Eckert, et al. Expires 3 May 2021 [Page 131] Internet-Draft An Autonomic Control Plane (ACP) October 2020 15.1.2. BRSKI / ACP registrar related enhancements Only after ACP entered IESG review did it become clear that the in- progress BRSKI document would not provide all the explanations needed for ACP registrars as expected earlier by ACP authors. Instead, BRSKI will only specify a subset of required ACP behavior related to certificate handling and registrar. There, it became clear that the ACP draft should specify generic ACP registrar behavior independent of BRSKI so ACP could be implemented with or without BRSKI and any manual/proprietary or future standardized BRSKI alternatives (for example via NETCONF) would understand the requirements for ACP registrars and its certificate handling. This lead to additional text about ACP registrars in the ACP document: 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 6.1.4 (new) Overview of TA required for ACP. 6.1.5.5 Added explanations/requirements for Re-enrollment. 6.10.7 Normative requirements for ACP registrars (BRSKI or not). 10.2 Operational expectations against ACP registrars (BRSKI or not). 15.1.3. Normative enhancements since start of IESG review In addition to above ACP registrar / BRSKI related enhancements there is a range of minor normative (also explanatory) enhancements since the start of IESG review: 6.1.1 Hex digits in ACP domain information field now upper-case (no specific reason except that both options are equally good, but capitalized ones are used in rfc5234). 6.1.5.3 Added explanations about CRLs. 6.1.5.6 Added explanations of behavior under failing certificates. 6.1.2 Allow ACP address '0' in ACP domain information field: presence of address indicates permission to build ACP secure channel to node, 0 indicates that the address of the node is assigned by (future) other means than certificate. Non-autonomic nodes have no address at all (that was in -13), and can only connect via ACP connect interfaces to ACP. Eckert, et al. Expires 3 May 2021 [Page 132] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.1.3 Distinction of real ACP nodes (with address) and those with domain certificate without address added as a new rule to ACP domain membership check. 6.6 Added throttling of secure-channel setup attempts. 6.11.1.14 Removed requirement to handle unknown destination ACP traffic in low-end nodes that would never be RPL roots. 6.12.5 Added recommendation to use IPv6 DAD. 6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional certificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP GRASP TLS protocol parameter requirements to ensure interoperating implementations (from SEC-AD review). 15.1.4. Explanatory enhancements since start of IESG review Beyond the functional enhancements from the previous two sections, the mayority of changes since -13 are additional explanations from review feedback, textual nits and restructuring - with no functional requirement additions/changes. 1.1 Added "applicability and scope" section with summarized explanations. 2.Added in-band vs. out-of-band management definitions. 6.1.2 (was 6.1.1) expanded explanations of reasoning for elements of the ACP domain information field. 6.1.3 refined explanations of ACP domain membership check and justifications for it. 6.5 Elaborated step-by-step secure channel setup. 6.10 Additional explanations for addressing modes, additional table of addressing formats (thanks MichaelR). 6.10.5 introduced 'F' bit position as a better visual representation in the Vlong address space. 6.11.1.1 extensive overhaul to improve readability of use of RPL (from IESG feedback of non-routing/RPL experts). 6.12.2 Added caution about unconfiguring Data-Plane IPv6 addresses and impact to ACP (limitation of current ACP design, and pointint to more details in 10.2). Eckert, et al. Expires 3 May 2021 [Page 133] Internet-Draft An Autonomic Control Plane (ACP) October 2020 10.4 New explanations / summary of configurations for ACP (aka: all config is undesirable and only required for integrating with non- autonomic components, primarily ACP-connect and Registrars). 11. Textually enhanced / better structured security considerations section after IESG security review. A. (new) Moved all explanations and discussions about futures from section 10 into this new appendix. This text should not be removed because it captures a lot of repeated asked questions in WG and during reviews and from users, and also captures ideas for some likely important followup work. But none of this is relevant to implementing (section 6) and operating (section 10) the ACP. 15.2. draft-ietf-anima-autonomic-control-plane-30 -29 did pass all IESG DISCUSS. This version cleans up reamining comments. Planned to be removed section Appendix A.6 was moved into new Appendix B.1 to be amended by further A.2, A.3 containing text felt to be unfit for publication in RFC (see below). Added reference to this last draft, and referencing those sections ([ACPDRAFT]). Final discussion with responsible AD (Eric Vyncke): marked all references to [ACPDRAFT] as to be removed from RFC, as this would be too unconventional. Likewise also [ACPDRAFT] reference itself. Added explanation to appendix B. Comments from Erik Kline: 2. Fine tuned ULA definition. Comments Michael Richardson / Eric Vyncke. 6.2.4. / 11. Removed text arguing ability how to use public CA (or not). Replaced with reference to new [ACPDRAFT] section B.3 (not in RFC) that explains current state of understanding (unfinished). B.3 New text detailling authors understanding of use of public CA (will not be in RFC). Comments/proposals from Ben Kaduk: Various: Replaced RFC4492 with RFC8422 which is superceeding it. 6.1 Text fix for hash strength 384 bits (from SHA384); Text fix for ec_point_format extension. Eckert, et al. Expires 3 May 2021 [Page 134] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.2.1 Text fixup. Removed requirements for ECDH support in certificate, instead merely explaining the dependencies required IF this is desired (educational). 6.2.5.4. Fine tuning 2 sentences. 6.3.2. (ACP domain memebership check) Add reference to ACPDRAFT B.2 explaining why ACP domain membership does not validate ACP address of the connection. 6.4. Downgraded SHOULD to MAY in new -29 suggestion how to deal with DoS attacks with many GRASP announcements. Will also separately ask TSV ADs. 6.4. Fixed extension points in CDDL objective-value definitions (with help from Carsten/Brian). 9.3.5.2. Added explanation when ACP greenfield state ends, and refined text explaining how to deal with this. 11. removed duplicate paragraph (first, kept paragraph was the fixed up, improved correct version). 11. Added references to ACPDRAFT B.1, B.2 as possible future solutions for downgrade attacks. 12. Fixed up text for IANA code point allocation request. A.6 - removed. A.9.9 - added one explanatory intro paragraph to makes it easier to distinguish this option from the B.1 considerations. B.1 - new text suggested from Ben, replacing A.6 (will not be in RFC). B.2 - new text discussing why there is no network layer address verification in ACP domain membership check (will not be in RFC). B.4 - Text discussing DULL GRASP attacks via port sweeps and what do do against it. Other. 1. Added sentence about FCC outage report from June as example for in-band management. Eckert, et al. Expires 3 May 2021 [Page 135] Internet-Draft An Autonomic Control Plane (ACP) October 2020 15. added reference to github where document was developed (removed in RFC, part of changelog). 15.3. draft-ietf-anima-autonomic-control-plane-29 Comments from Robert Wilton: Improved several textual nits. Discuss/Comments from Erik Kline: Editorial suggestions and nits. Thanks!. 6.1.3 Added text about how/why rsub is irrelevant for domain membership check. 6.3 Added extension points to AN_ACP DULL GRASP objective because for example ACP domain certificate could be a nice optional additional parameter and prior syntax would have forced us to encode into separate objective unnecessarily. 6.7 Using RFC8415 terminology for exponential backoff parameters. 6.11.2 Amended ACP Sub-Addressing table with future code points, explanations and prefix announced into RPL. 6.12.1.11. Reworked text to better explain how black hole route works and added expanation for prefix for manual address scheme. 8.1.3. Reworked explanation of RIOs for ACP connect interfaces for Type C vs. Type A/B hosts. 8.1.4. Added explanation how this "VRF select" option is required for auto-attachment of Type A/B hosts to ACP and other networks. Discuss/Comments from Barry Leiba: Various editorial nits - thanks. 6.1 New section pulling in TLS requirements, no need anymore to duplicat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired) OCSP/CRLDP. Added rule to start use secure channel only after negotiation has finished. Added rules not to optimize negotiation across multiple L2 interfaces to the same peer. Eckert, et al. Expires 3 May 2021 [Page 136] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.6 Changed role names in secure channel negotiation process: Alice/ Bob -> Decider/Follower. Explanation enhancements. Added definition for ACP nodes with "0" address. 6.8.3 Improved explanation how IKEv2 forces preference of IPsec over GRE due to ACP IPsec profiles being Tunneled vs. Transport. 6.8.4 Limited mentioning of DTLS version requirements to this section. 6.9.2 Removed TLS requirements, they are now in 6.1. 6.10.6 Removed explanation of IANA allocation requirement. Redundant - already in IANA section, and was seen as confusing. 8.1.1 Clarified that there can be security impacts when weakening directly connected address RPF filtering for ACP connect interfaces. Discuss/Comments from Ben Kaduk: Many good editorial improvements - thanks!. 5. added explanation of what to do upon failed secure channel establishment. 6.1.1. refined/extended cert public cey crypto algo and better distinguished algo for the keys of the cert and the key of the signer. 6.1.1. and following: explicitly defining "serialNumber" to be the X.520 subject name serialNumber, not the certificate serial Number. 6.1.1. emhasize additional authorization step for EST servers (id-kp- cmcRA). 6.1.2 changed AcpNodeName ABNF to again use 32HEXDIG instead of self- defined variation, because authors overlooked that ABNF is case agnostic (which is fine). Added recommendation to encode as lower case. Added full ABNF encoding for extensions (any characters as in "atoms" except the new "+" separator). 6.1.5.3. New text to explain reason for use of HTTPS (instead of HTTP) for CRLDP and when and how to use HTTPS then. 6.1.5.5. added text explaning why/how and when to maintain TA data upon failing cert renewal (one version with BRSKI, one version with other, ess secure bootstrap protocols). Eckert, et al. Expires 3 May 2021 [Page 137] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.3. new text and requirement about the signaling of transport ports in DULL GRASP - benefits (no well-known ports required), and problems (additional DoS attack vector, albeit not worse than pre-existing ones, depending on setup of L2 subnets.). 6.7.3.1.1. Specified AUTH_HMAC_SHA2_256_128 (as the ESP authentication algorithm). 6.8.2. Added recommendations for TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 when supporting TLS 1.3. 8.2.2. Added explanation about downgrade attack across configured ACP tunnels and what to do against it. 9.3.5.2. Rewrote most of section as it originally was too centric on BRSKI. Should now well describe expectations against automated bootstrap. Introduces new requirement not to call node as in support of ANI if is ALSO has TOFU bootstrap. 11. Expanded text about malicious EST servers. Added paragraph about ACP secure channel downgrade attacks. Added paragraphs about private PKI as a core to allow security against fake certificates, added paragraph about considerationsproblems when using public PI. A.10.9 New appendix suggesting how to discover ACP secure channel negotiation downgrade attacks. Discuss from Roman Danyliw: 6.1.5.1 - Added requirement to only announce SRV.est when a working CA connection. 15 - Amended security considerations with text about registrar dependencies, security of IDevID/ACP-certificate, EST-Server and GRASP for EST server discovery. Other: Conversion to XML v3. Solved empty () taxonomy xref problems. Various formatting fixes for v3. Added contributors section. 15.4. draft-ietf-anima-autonomic-control-plane-28 IESG review Roman Danyliw: Eckert, et al. Expires 3 May 2021 [Page 138] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6. Requested additional text elaborating misconfiguration plus attack vectors. 6.1.3.1 Added paragraph about unsecured NTP as basis for time in the absence of other options. 6.7.2 reworded text about additional secure channel protocol reqiurements. 6.7.3.1.2. Added requirement for ACP nodes supporting IKEv2 to support RFC8247 (not sure how that got dropped from prior versions. Replaced minimum crypto requirements definition via specific AES options with more generic "symmetric key/hash strength" requirements. 6.10.7.3. Added example how to derive addressing scheme from IDevID (PID). Added explanation how to deal with non-persistant registrar address database (hint: it sucks or is wasteful, what did you expect). 8.1.1. Added explanation for 'Physical controlled/secured'. 8.1.5. Removed 'Physical controlled/secured' text, refer back to 8.1.1. 8.2.1. Fixed ABNF 'or' syntax line. 9.3.2. Added explanation of remote management problem with interface "down" type commands. 10.2.1. Added explanations for attacks from impaired ACP nodes. 11. Rewrote intro paragraph. Removed text referring to enrollment/ registrars as they are out of scope of ACP (dependencies only). 11. Added note about need for new protocols inside ACP to use end- to-end authentication. 11. Rewrote paragraph about operator mistakes so as to be actionably. Operators must not make mistakes - but ACP minimizes the mistakes they can make. ACP domain certificate -> ACP certificate. Various other cosmetic edits (thanks!) and typo fixes (sorry for not running full spell check for every version. Will definitely do before RFC editor). Eckert, et al. Expires 3 May 2021 [Page 139] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Other: 6.12.5.2.1./6.12.5.2.2. Added text explaining link breakage wrt. RTL (came about re-analyzing behavior after question about hop count). Removed now unnecessary references for earlier rrc822Name otherName choice. 15.5. draft-ietf-anima-autonomic-control-plane-27 Too many revisions with too many fixes. Lets do a one-word change revision for a change now if it helps to accelerate the review process. Added "subjectAltName /" to make it unambiguous that AcpNodeName is indeed a SAN (from Russ). 15.6. draft-ietf-anima-autonomic-control-plane-26 Russ Housley review of -25. 1.1 Explicit reference for TLS 1.2 RFC. 2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) / acp-node-name (ABNF), also through rest of document. 2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/ LDevID certificate to be more unambiguous. 2. Changed definition of root CA to just refer to how its used in RFC7030 CA root key update, because thats the only thing relevant to ACP. 6.1.1 Moved ECDH requirement to end of text as it was not related to the subject of the initial paragraps. Likewise reference to CABFORUM. 6.1.1 Reduced cert key requirements to only be MUST for certs with 2048 RSA public key and P-256 curves. Reduced longer keys to SHOULD. 6.1.2 Changed text for conversion from rfc822Name to otherName / AcpNode, removed all the explanations of benefits coming with rfc822Name *sob* *sob* *sob*. 6.1.2.1 New ASN.1 definition for otherName / AcpNodeName. Eckert, et al. Expires 3 May 2021 [Page 140] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.1.3 Fixed up text. re the handling of missing connectivity for CRLDP / OCSP. 6.1.4 Fixed up text re. inability to use public CA to situation with otherName / AcpNodeName (no more ACME rfc822Name validation for us *sob* *sob* *sob*). 12. Added ASN.1 registration requests to IANA section. Appenices. Minor changes for rfc822Name to otherName change. Various minor verbal fixes/enhancements. 15.7. draft-ietf-anima-autonomic-control-plane-25 Crypto parameter discuss from Valery Smyslov and Paul Wouters and resulting changes. 6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA from IPsec section to this general requirements section and added explanation how this may be inappropriate if TA payload is considered secret by TA owner. 6.7.3.1 Added traffic selectors for native IPsec. Improved text explanation. 6.7.3.1.2 removed misleading text about signaling TA when using intermediate certs. 6.7.3.1.2 Removed requirement for 'PKCS #7 wrapped X.509 certificate' requirement on request of Valery Smyslov as it is not defined in RFC7296 and there are enough options mandated in RFC7296. Replaced with just informative text to educate readers who are not IPsec experts what the mandatory option in RFC7296 is that allows to signal certificates. 6.7.3.1.2 Added SHOULD requirement how to deal with CERTREQ so that 6.7.2 requirement for TA diagnostics will work in IKEv2 (ignoring CERTREQ is permitted by IKEv2). Added explanation how this will result in TA cert diagnostics. 6.7.3.1.2 Added requirement for IKEv2 to operate on link-local addresses for ACP so at to assume ACT cert as the only possible authenticator - to avoid potentialy failing section from multiple available certs on a router. 6.7.3.1.2 fixed PKIX- style OID to ASN.1 object AlgorithmIdentifier (Paul). Eckert, et al. Expires 3 May 2021 [Page 141] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.7.3.2 Added IPsec traffic selectors for IPsec with GRE. 6.7.5 Added notion that IPsec/GRE MAY be preferred over IPsec/native. Luckily IPsec/native uses tunneling, whereas IPsec/GRE uses transport mode, and there is a long discuss whether it is permitted to even build IPsec connectings that only support transports instead of always being able to fall back to tunnel mode. Added explanatory paragraph why ACP nodes may prefer GRE over native (wonder how that was missing..). 9.1.1 Added section to explain need for secure channel peer diagnostics via signaling of TA. Four examples given. Paul Wouters mentioned that ipkcs7 had to be used in some interop cases with windows CA, but that is an issue of ACP Registrar having to convert into PKCS#7 to talk to a windows CA, and this spec is not concerned with that, except to know that it is feasible, so not mentioned in text anywhere, just tracking discussion here in changelog. Michael Richardson: 3.1.3 Added point in support of rfc822address that CA may not support to sign certificates with new attributes (such as new otherName). Michael Richardson/Brian Carpenter fix: 6.1.5.1/6.3 Fixed GRASP examples. Joe Halpern review: 1. Enhanded introduction text for in-band and of out-of-band, explaining how ACP is an in-band network aiming to achieve all possible benefits of an out-of-band network. 1. Comprehensive explanation for term Data-Plane as it is only logically following pre-established terminology on a fully autonomic node, when used for existing nodes augmented with ACP, Data-Plane has more functionality than usually associated with the term. 2. Removed explanatory text for Data-Plane, referring to section 1. 2. Reduced explanation in definition of in-band (management/ signaling), out-of-band-signaling, now pointing to section 1. Eckert, et al. Expires 3 May 2021 [Page 142] Internet-Draft An Autonomic Control Plane (ACP) October 2020 5. Rewrote a lot of the steps (overview) as this text was not reviewed for long time. Added references to normative section for each step to hopefully avoid feedback of not explaining terms used (really not possible to give good summary without using forward references). 2. Separate out-of-band-management definition from virtual out-of- band-management definition (later one for ACP). 2. Added definitions for RPI and RPL. 6.1.1. added note about end-to-end authentication to distinguish channel security from overall ACP security model. 6.5 Fixed bugs in channel selection signaling step description (Alice vs. Bob). 6.7.1 Removed redundant channel selection explanation. 6.10.3 remove locator/identifier terminology from zone addressing scheme description (unnecessary), removed explanations (now in 9.4), simplified text, clarified requirement for Node-ID to be unique, recommend to use primarily zone 0. 6.10.3.1 Removed. Included a lot of insufficient suggestions for future stanards extensions, most of it was wrong or would need to be revisited by WG anyhow. Idea now (just here for comment): Announce via GRASP Zone-ID (e.g. from per-zone edge-node/registrar) into a zone of the ACP so all nodes supporting the scheme can automatically self-allocate the Zone-ID. 6.11.1.1 (RPL overview), eliminated redundant text. 6.11.1.1.1 New subsection to better structure overview. 6.11.1.1.2 New subsection to better group overview, replaced TTL explanation (just the symptom) with hopefully better reconvergence text (intent of the profile) for the ACP RPL profile. 6.11.1.1.6 Added text to explain simple choice for rank_factor. 6.11.1.13 moved explanation for RPI up into 6.11.1.1. 6.12.5.1 rewrote section for ACP Loopback Interface. 9.4 New informative/informational section for partial or incremental adoption of ACP to help understand why there is the Zone interface sub-scheme, and how to use it. Eckert, et al. Expires 3 May 2021 [Page 143] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Unrelated fixes: Ask to RFC editor to add most important abbreviations to RFC editor abbreviation list. 6.10.2 changed names in ACP addressing scheme table to be less suggestive of use. Russ Hously review: 2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root CA". Changed "Certificate Authority" to "Certification Authority" throughout the document (correct term according to X.509). 6.1 Fixed explanation of mutual ACP trust. 6.1.1 s/X509/X509v3/. 6.1.2 created bulleted lists for explanations and justifications for choices of ACP certificate encoding. No semantic changes, just to make it easier to refer to the points in discussions (rfcdiff seems to have a bug showing text differences due to formatting changes). 6.1.3 Moved content of rule #1 into previous rule #2 because certification chain validation does imply validation of lifetime. numbers of all rules reduced by 1, changed hopefully all references to the rule numbers in the document. Rule #3, Hopefully fixed linguistic problem self-contradiction of MUST by lower casing MUST in the explanation part and rewriting the condition when this is not applicable. 6.1.4 Replaced redundant term "Trust Point" (TP) with Trust Anchor (TA"). Replaced throughout document Trust Anchor with abbreviation TA. Enhanced several sentences/rewrote paragraphs to make explanations clearer. 6.6 Added explanation how ACP nodes must throttle their attempts for connection making purely on the result of their own connection attempts, not based on those connections where they are responder. 15.8. draft-ietf-anima-autonomic-control-plane-24 Leftover from -23 review by Eric Vyncke: Eckert, et al. Expires 3 May 2021 [Page 144] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Swapping sections 9 and 10, section 9 was meant to be at end of document and summarize. Its not meant to be misinterpreted as introducing any new information. This did happen because section 10 was added after section 9. 15.9. draft-ietf-anima-autonomic-control-plane-23 Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. Review of IPsec security with Mcr and ipsec mailing list. 6.7.1 - new section: Moved general considerations for secure channel protocols here, refined them. 6.7.2 - new section: Moved common requirements for secure channel protocols here, refined them. 6.7.3.1.1. - improved requirements text related to RFC8221, better explamations re. HW acceleration issues. 6.7.3.1.2. - improved requirements text related to RFC8247, (some requirements still discussed to be redundant, will be finalized in next weeks. Eric Vyncke review of -21: Only noting most important changes, long list of smaller text/ readability enhancements. 2. - New explanation of "normative", "informational" section title tags. alphabetic reordering of terms, refined definitions for CA, CRL. root CA. 6.1.1. - explanation when IDevID parameters may be copied into LDevID. 6.1.2. - Fixed hex digits in ACP domain information to lower case. 6.1.3.1. - New section on Realtime clock and Time Validation. 6.3 - Added explanation that DTLS means >= version 1.2 (not only 1.2). 6.7 - New text in this main section explaing relationship of ACP secure channels and ACP virtual interfaces - with forward references to virtual interface section. Eckert, et al. Expires 3 May 2021 [Page 145] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.8.2 - reordered text and picture, no text change. 6.10.7.2 - describe first how Registrar-ID can be allocted for all type of registrars, then refined text for how to potentially use MAC addresses on physical registrars. 6.11.1.1 - Added text how this profile does not use Data-Plane artefacts (RPI) because hadware forwarding. This was previously hidden only later in the text. 6.11.1.13. - Rewrote RPL Data-Plane artefact text. Provide decoder ring for abbreviations and all relevant RFCs. 6.12.5.2. - Added more explicit text that secure channels are mapped into virtual interfaces, moved different type of interfaces used by ACP into separate subsections to be able to refer to them. 7.2 - Rewrote/refined text for ACP on L2, prior text was confusing and did not well explain why ACP for L2/L3 switches can be implemented without any L2 (HW) changes. Also missing explanation of only running GRASP untagged when VLANs are used. 8.1.1 - Added requirement for ACP Edge nodes to allow configurable filtering of IPv6 RPI headers. 11. - (security section). Moved explanation of address stealing from 7.2 to here. 15.10. draft-ietf-anima-autonomic-control-plane-22 Ben Kaduk review of -21: RFC822 encoding of ACP domain information: 6.1.2 rewrote text for explaining / justifying use of rfc822name as identifier for node CP in certificate (was discussed in thread, but badly written in prior versions). 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is the known primary name to extensions separator in many email systems ("." was wrong in prior versions). 6.1.2 Rewrote/improved explanations for use of rfc822name field to explain better why it is PKIX compliant and the right thing to do. Crypto parameters for IPsec: Eckert, et al. Expires 3 May 2021 [Page 146] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.1 - Added explanation of why manual keying for ACP is not feasible for ACP. Surprisingly, that text did not exist. Referred to by IPsec text (6.7.1), but here is the right place to describe the reasoning. 6.1.2 - Small textual refinement referring to requirements to authenticate peers (for the special cases of empty or '0' ACP address in ACP domain information field. 6.3 - To better justify Bens proposed change of secure channel protocol being IPsec vs. GRASP objective being IKEv2, better explained how protocol indicated in GRASP objective-value is name of protocol used to negotiate secure channel, use example of IKEv2 to negotiate IPsec. 6.7.1 - refinemenet similar to 6.3. - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.1 as it equally applies to GRE encapped IPsec (looks nicer one level up). - created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to clearer distinguish between these two requirements blocks. - Refined the text in these two sections to hopefully be a good answer to Valery's concern of not randomnly mocking with existing requirements docs (rfc8247 / rfc8221). 6.7.1.1.1 - IPsec/ESP requirements section: - MUST support rfc8221 mandatory EXCEPT for the superceeding requirements in this section. Previously, this was not quite clear from the text. - Hopefully persuasive explanations about the requirements levels for ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY1305: Restructured text for why not ENCR_AES_CBC (was in prior version, just not well structured), added new expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130. - In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, ENCR_CHACHACHA are SHOULD when they are implementable with rqual or faster performancce than ENCR_AES_GCM_16. - Removed text about "additional rfc8221" reqiurements MAY be used. Now the logic is that all other requirements apply. Hopefully we have written enough so that we prohibited downgrades. Eckert, et al. Expires 3 May 2021 [Page 147] Internet-Draft An Autonomic Control Plane (ACP) October 2020 6.7.1.1.2 - RFC8247 requirements: - Added mandate to support rfc8247, added explanation that there is no "stripping down" requirement, just additional stronger requirements to mandate correct use of ACP certificartes during authentication. - refined text on identifying ACP by IPv6 address to be clearer: Identifying in the context of IKEv2 and cases for '0' in ACP domain information. - removed last two paragraphs about relationship to rfc8247, as his is now written in first paragraph of the section. End of Ben Kaduk review related fixes. Other: Forgot to update example of ACP domain information to use capitalized hex-digits as required by HEXDIG used. Added reference to RFC8316 (AN use-cases) to beginning of section 3 (ACP use cases). Small Enhanced IPsec parameters description / requirements fixes (from Michael Richardson). 16. Normative References [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, Internet- Draft, draft-ietf-anima-bootstrapping-keyinfra-43, 7 August 2020, . [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", Work in Progress, Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, . [IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", . Eckert, et al. Expires 3 May 2021 [Page 148] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC1034] Mockapetris, P.V., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Eckert, et al. Expires 3 May 2021 [Page 149] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, . [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, . [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . Eckert, et al. Expires 3 May 2021 [Page 150] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [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, . [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, . [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, DOI 10.17487/RFC8247, September 2017, . [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . 17. Informative References Eckert, et al. Expires 3 May 2021 [Page 151] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [ACPDRAFT] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", Work in Progress, Internet-Draft, draft-ietf-anima-autonomic-control-plane-30, . [RFC-Editor: Please remove this complete reference from the RFC] Refer to the IETF working group draft for the few sections removed from this document for various reasons. They capture the state of discussion about unresolved issues that may need to be revisited in future work. [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", December 2009, . [CABFORUM] CA/Browser Forum, "Certificate Contents for Baseline SSL", November 2019, . [FCC] FCC, "FCC STAFF REPORT ON NATIONWIDE T-MOBILE NETWORK OUTAGE ON JUNE 15, 2020 (PS Docket No. 20-183)", 2020, . The FCC's Public Safety and Homeland Security Bureau issues a report on a nationwide T-Mobile outage that occurred on June 15, 2020. Action by: Public Safety and Homeland Security Bureau. [I-D.eckert-anima-noc-autoconfig] Eckert, T., "Autoconfiguration of NOC services in ACP networks via GRASP", Work in Progress, Internet-Draft, draft-eckert-anima-noc-autoconfig-00, 2 July 2018, . [I-D.ietf-acme-star] Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Fossati, "Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)", Work in Progress, Internet-Draft, draft-ietf-acme-star-11, 24 October 2019, . [I-D.ietf-anima-prefix-management] Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Work in Progress, Internet-Draft, draft-ietf-anima-prefix- Eckert, et al. Expires 3 May 2021 [Page 152] Internet-Draft An Autonomic Control Plane (ACP) October 2020 management-07, 18 December 2017, . [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", Work in Progress, Internet-Draft, draft-ietf- anima-reference-model-10, 22 November 2018, . [I-D.ietf-roll-applicability-template] Richardson, M., "ROLL Applicability Statement Template", Work in Progress, Internet-Draft, draft-ietf-roll- applicability-template-09, 3 May 2016, . [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-38, 29 May 2020, . [IEEE-1588-2008] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", December 2008, . [IEEE-802.1X] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", February 2010, . [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and Metropolitan Area Networks: Station and Media Access Control Connectivity Discovery", June 2016, . Eckert, et al. Expires 3 May 2021 [Page 153] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Security", June 2006, . [RFC1112] Deering, S.E., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, . [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, . [RFC1654] Rekhter, Y., Ed. and T. Li, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, DOI 10.17487/RFC1654, July 1994, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, . [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, DOI 10.17487/RFC3164, August 2001, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Eckert, et al. Expires 3 May 2021 [Page 154] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, October 2004, . [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, . [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, . [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, . [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, . Eckert, et al. Expires 3 May 2021 [Page 155] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, . [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, DOI 10.17487/RFC5790, February 2010, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . Eckert, et al. Expires 3 May 2021 [Page 156] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, . [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 2011, . [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . Eckert, et al. Expires 3 May 2021 [Page 157] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, November 2014, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . [RFC7585] Winter, S. and M. McCauley, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 2015, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . Eckert, et al. Expires 3 May 2021 [Page 158] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8316] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez Prieto, "Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations", RFC 8316, DOI 10.17487/RFC8316, February 2018, . [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, . [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)", RFC 8368, DOI 10.17487/RFC8368, May 2018, . [RFC8398] Melnikov, A., Ed. and W. Chuang, Ed., "Internationalized Email Addresses in X.509 Certificates", RFC 8398, DOI 10.17487/RFC8398, May 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . Eckert, et al. Expires 3 May 2021 [Page 159] Internet-Draft An Autonomic Control Plane (ACP) October 2020 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, . [X.509] International Telecommunication Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO/IEC 9594-8, October 2016, . [X.520] International Telecommunication Union, "Information technology - Open Systems Interconnection - The Directory: Selected attribute types", ITU-T Recommendation X.520, ISO/IEC 9594-6, October 2016, . Appendix A. Background and Futures (Informative) The following sections discuss additional background information about aspects of the normative parts of this document or associated mechanisms such as BRSKI (such as why specific choices were made by the ACP) and they provide discussion about possible future variations of the ACP. A.1. ACP Address Space Schemes This document defines the Zone, Vlong and Manual sub address schemes primarily to support address prefix assignment via distributed, potentially uncoordinated ACP registrars as defined in Section 6.11.7. This costs 48/46-bit identifier so that these ACP registrar can assign non-conflicting address prefixes. This design does not leave enough bits to simultaneously support a large number of nodes (Node-ID) plus a large prefix of local addresses for every node plus a large enough set of bits to identify a routing Zone. In result, Zone, Vlong 8/16 attempt to support all features, but via separate prefixes. Eckert, et al. Expires 3 May 2021 [Page 160] Internet-Draft An Autonomic Control Plane (ACP) October 2020 In networks that always expect to rely on a centralized PMS as described above (Section 9.2.5), the 48/46-bits for the Registrar-ID could be saved. Such variations of the ACP addressing mechanisms could be introduced through future work in different ways. If a new otherName was introduced, incompatible ACP variations could be created where every design aspect of the ACP could be changed. Including all addressing choices. If instead a new addressing sub- type would be defined, it could be a backward compatible extension of this ACP specification. Information such as the size of a zone- prefix and the length of the prefix assigned to the ACP node itself could be encoded via the extension field of the acp-node-name. Note that an explicitly defined "Manual" addressing sub-scheme is always beneficial to provide an easy way for ACP nodes to prohibit incorrect manual configuration of any non-"Manual" ACP address spaces and therefore ensure that "Manual" operations will never impact correct routing for any non-"Manual" ACP addresses assigned via ACP certificates. A.2. BRSKI Bootstrap (ANI) BRSKI describes how nodes with an IDevID certificate can securely and zero-touch enroll with an LDevID certificate to support the ACP. BRSKI also leverages the ACP to enable zero-touch bootstrap of new nodes across networks without any configuration requirements across the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This includes otherwise not configured networks as described in Section 3.2. Therefore, BRSKI in conjunction with ACP provides for a secure and zero-touch management solution for complete networks. Nodes supporting such an infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic Networking Infrastructure), see [I-D.ietf-anima-reference-model]. Nodes that do not support an IDevID certificate but only an (insecure) vendor specific Unique Device Identifier (UDI) or nodes whose manufacturer does not support a MASA could use some future security reduced version of BRSKI. When BRSKI is used to provision a domain certificate (which is called enrollment), the BRSKI registrar (acting as an enhanced EST server) must include the otherName / AcpNodeName encoded ACP address and domain name to the enrolling node (called pledge) via its response to the pledges EST CSR Attribute request that is mandatory in BRSKI. The Certification Authority in an ACP network must not change the otherName / AcpNodeName in the certificate. The ACP nodes can therefore find their ACP address and domain using this field in the domain certificate, both for themselves, as well as for other nodes. Eckert, et al. Expires 3 May 2021 [Page 161] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The use of BRSKI in conjunction with the ACP can also help to further simplify maintenance and renewal of domain certificates. Instead of relying on CRL, the lifetime of certificates can be made extremely small, for example in the order of hours. When a node fails to connect to the ACP within its certificate lifetime, it cannot connect to the ACP to renew its certificate across it (using just EST), but it can still renew its certificate as an "enrolled/expired pledge" via the BRSKI bootstrap proxy. This requires only that the BRSKI registrar honors expired domain certificates and that the pledge attempts to perform TLS authentication for BRSKI bootstrap using its expired domain certificate before falling back to attempting to use its IDevID certificate for BRSKI. This mechanism could also render CRLs unnecessary because the BRSKI registrar in conjunction with the CA would not renew revoked certificates - only a "Do-not-renew" list would be necessary on BRSKI registrars/CA. In the absence of BRSKI or less secure variants thereof, provisioning of certificates may involve one or more touches or non-standardized automation. Node vendors usually support provisioning of certificates into nodes via PKCS#7 (see [RFC2315]) and may support this provisioning through vendor specific models via NETCONF ([RFC6241]). If such nodes also support NETCONF Zero-Touch ([RFC8572]) then this can be combined to zero-touch provisioning of domain certificates into nodes. Unless there are equivalent integration of NETCONF connections across the ACP as there is in BRSKI, this combination would not support zero-touch bootstrap across a not configured network though. A.3. ACP Neighbor discovery protocol selection This section discusses why GRASP DULL was chosen as the discovery protocol for L2 adjacent candidate ACP neighbors. The contenders considered where GRASP, mDNS or LLDP. A.3.1. LLDP LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example of L2 discovery protocols that terminate their messages on L2 ports. If those protocols would be chosen for ACP neighbor discovery, ACP neighbor discovery would therefore also terminate on L2 ports. This would prevent ACP construction over non-ACP capable but LLDP or CDP enabled L2 switches. LLDP has extensions using different MAC addresses and this could have been an option for ACP discovery as well, but the additional required IEEE standardization and definition of a profile for such a modified instance of LLDP seemed to be more work than the benefit of "reusing the existing protocol" LLDP for this very simple purpose. Eckert, et al. Expires 3 May 2021 [Page 162] Internet-Draft An Autonomic Control Plane (ACP) October 2020 A.3.2. mDNS and L2 support Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) Resource Records (RRs) as defined in [RFC6763] is a key contender as an ACP discovery protocol. because it relies on link-local IP multicast, it does operates at the subnet level, and is also found in L2 switches. The authors of this document are not aware of mDNS implementation that terminate their mDNS messages on L2 ports instead of the subnet level. If mDNS was used as the ACP discovery mechanism on an ACP capable (L3)/L2 switch as outlined in Section 7, then this would be necessary to implement. It is likely that termination of mDNS messages could only be applied to all mDNS messages from such a port, which would then make it necessary to software forward any non- ACP related mDNS messages to maintain prior non-ACP mDNS functionality. Adding support for ACP into such L2 switches with mDNS could therefore create regression problems for prior mDNS functionality on those nodes. With low performance of software forwarding in many L2 switches, this could also make the ACP risky to support on such L2 switches. A.3.3. Why DULL GRASP LLDP was not considered because of the above mentioned issues. mDNS was not selected because of the above L2 mDNS considerations and because of the following additional points: If mDNS was not already existing in a node, it would be more work to implement than DULL GRASP, and if an existing implementation of mDNS was used, it would likely be more code space than a separate implementation of DULL GRASP or a shared implementation of DULL GRASP and GRASP in the ACP. A.4. Choice of routing protocol (RPL) This section motivates why RPL - "IPv6 Routing Protocol for Low-Power and Lossy Networks ([RFC6550] was chosen as the default (and in this specification only) routing protocol for the ACP. The choice and above explained profile was derived from a pre-standard implementation of ACP that was successfully deployed in operational networks. Requirements for routing in the ACP are: Eckert, et al. Expires 3 May 2021 [Page 163] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * Self-management: The ACP must build automatically, without human intervention. Therefore, routing protocol must also work completely automatically. RPL is a simple, self-managing protocol, which does not require zones or areas; it is also self- configuring, since configuration is carried as part of the protocol (see Section 6.7.6 of [RFC6550]). * Scale: The ACP builds over an entire domain, which could be a large enterprise or service provider network. The routing protocol must therefore support domains of 100,000 nodes or more, ideally without the need for zoning or separation into areas. RPL has this scale property. This is based on extensive use of default routing. * Low resource consumption: The ACP supports traditional network infrastructure, thus runs in addition to traditional protocols. The ACP, and specifically the routing protocol must have low resource consumption both in terms of memory and CPU requirements. Specifically, at edge nodes, where memory and CPU are scarce, consumption should be minimal. RPL builds a DODAG, where the main resource consumption is at the root of the DODAG. The closer to the edge of the network, the less state needs to be maintained. This adapts nicely to the typical network design. Also, all changes below a common parent node are kept below that parent node. * Support for unstructured address space: In the Autonomic Networking Infrastructure, node addresses are identifiers, and may not be assigned in a topological way. Also, nodes may move topologically, without changing their address. Therefore, the routing protocol must support completely unstructured address space. RPL is specifically made for mobile ad-hoc networks, with no assumptions on topologically aligned addressing. * Modularity: To keep the initial implementation small, yet allow later for more complex methods, it is highly desirable that the routing protocol has a simple base functionality, but can import new functional modules if needed. RPL has this property with the concept of "objective function", which is a plugin to modify routing behavior. * Extensibility: Since the Autonomic Networking Infrastructure is a new concept, it is likely that changes in the way of operation will happen over time. RPL allows for new objective functions to be introduced later, which allow changes to the way the routing protocol creates the DAGs. * Multi-topology support: It may become necessary in the future to support more than one DODAG for different purposes, using different objective functions. RPL allow for the creation of several parallel DODAGs, should this be required. This could be used to create different topologies to reach different roots. Eckert, et al. Expires 3 May 2021 [Page 164] Internet-Draft An Autonomic Control Plane (ACP) October 2020 * No need for path optimization: RPL does not necessarily compute the optimal path between any two nodes. However, the ACP does not require this today, since it carries mainly non-delay-sensitive feedback loops. It is possible that different optimization schemes become necessary in the future, but RPL can be expanded (see point "Extensibility" above). A.5. ACP Information Distribution and multicast IP multicast is not used by the ACP because the ANI (Autonomic Networking Infrastructure) itself does not require IP multicast but only service announcement/discovery. Using IP multicast for that would have made it necessary to develop a zero-touch auto configuring solution for ASM (Any Source Multicast - the original form of IP multicast defined in [RFC1112]), which would be quite complex and difficult to justify. One aspect of complexity where no attempt at a solution has been described in IETF documents is the automatic- selection of routers that should be PIM Sparse Mode (PIM-SM) Rendezvous Points (RPs) (see [RFC7761]). The other aspects of complexity are the implementation of MLD ([RFC4604]), PIM-SM and Anycast-RP (see [RFC4610]). If those implementations already exist in a product, then they would be very likely tied to accelerated forwarding which consumes hardware resources, and that in return is difficult to justify as a cost of performing only service discovery. Some future ASA may need high performance in-network data replication. That is the case when the use of IP multicast is justified. Such an ASA can then use service discovery from ACP GRASP, and then they do not need ASM but only SSM (Source Specific Multicast, see [RFC4607]) for the IP multicast replication. SSM itself can simply be enabled in the Data-Plane (or even in an update to the ACP) without any other configuration than just enabling it on all nodes and only requires a simpler version of MLD (see [RFC5790]). LSP (Link State Protocol) based IGP routing protocols typically have a mechanism to flood information, and such a mechanism could be used to flood GRASP objectives by defining them to be information of that IGP. This would be a possible optimization in future variations of the ACP that do use an LSP routing protocol. Note though that such a mechanism would not work easily for GRASP M_DISCOVERY messages which are intelligently (constrained) flooded not across the whole ACP, but only up to a node where a responder is found. We do expect that many future services in ASA will have only few consuming ASA, and for those cases, M_DISCOVERY is the more efficient method than flooding across the whole domain. Eckert, et al. Expires 3 May 2021 [Page 165] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Because the ACP uses RPL, one desirable future extension is to use RPLs existing notion of DODAG, which are loop-free distribution trees, to make GRASP flooding more efficient both for M_FLOOD and M_DISCOVERY. See Section 6.13.5 how this will be specifically beneficial when using NBMA interfaces. This is not currently specified in this document because it is not quite clear yet what exactly the implications are to make GRASP flooding depend on RPL DODAG convergence and how difficult it would be to let GRASP flooding access the DODAG information. A.6. CAs, domains and routing subdomains There is a wide range of setting up different ACP solution by appropriately using CAs and the domain and rsub elements in the acp- node-name in the domain certificate. We summarize these options here as they have been explained in different parts of the document in before and discuss possible and desirable extensions: An ACP domain is the set of all ACP nodes that can authenticate each other as belonging to the same ACP network using the ACP domain membership check (Section 6.2.3). GRASP inside the ACP is run across all transitively connected ACP nodes in a domain. The rsub element in the acp-node-name permits the use of addresses from different ULA prefixes. One use case is to create multiple physical networks that initially may be separated with one ACP domain but different routing subdomains, so that all nodes can mutual trust their ACP certificates (not depending on rsub) and so that they could connect later together into a contiguous ACP network. One instance of such a use case is an ACP for regions interconnected via a non-ACP enabled core, for example due to the absence of product support for ACP on the core nodes. ACP connect configurations as defined in this document can be used to extend and interconnect those ACP islands to the NOC and merge them into a single ACP when later that product support gap is closed. Note that RPL scales very well. It is not necessary to use multiple routing subdomains to scale ACP domains in a way that would be required if other routing protocols where used. They exist only as options for the above mentioned reasons. If different ACP domains are to be created that should not allow to connect to each other by default, these ACP domains simply need to have different domain elements in the acp-node-name. These domain elements can be arbitrary, including subdomains of one another: Domains "example.com" and "research.example.com" are separate domains if both are domain elements in the acp-node-name of certificates. Eckert, et al. Expires 3 May 2021 [Page 166] Internet-Draft An Autonomic Control Plane (ACP) October 2020 It is not necessary to have a separate CA for different ACP domains: an operator can use a single CA to sign certificates for multiple ACP domains that are not allowed to connect to each other because the checks for ACP adjacencies includes comparison of the domain part. If multiple independent networks choose the same domain name but had their own CA, these would not form a single ACP domain because of CA mismatch. Therefore, there is no problem in choosing domain names that are potentially also used by others. Nevertheless it is highly recommended to use domain names that one can have high probability to be unique. It is recommended to use domain names that start with a DNS domain names owned by the assigning organization and unique within it. For example, "acp.example.com" if you own "example.com". A.7. Intent for the ACP Intent is the architecture component of autonomic networks according to [I-D.ietf-anima-reference-model] that allows operators to issue policies to the network. Its applicability for use is quite flexible and freeform, with potential applications including policies flooded across ACP GRASP and interpreted on every ACP node. One concern for future definitions of Intent solutions is the problem of circular dependencies when expressing Intent policies about the ACP itself. For example, Intent could indicate the desire to build an ACP across all domains that have a common parent domain (without relying on the rsub/routing-subdomain solution defined in this document). For example, ACP nodes with domain "example.com", "access.example.com", "core.example.com" and "city.core.example.com" should all establish one single ACP. If each domain has its own source of Intent, then the Intent would simply have to allow adding the peer domains TA and domain names to the parameters for the ACP domain membership check (Section 6.2.3) so that nodes from those other domains are accepted as ACP peers. If this Intent was to be originated only from one domain, it could likely not be made to work because the other domains will not build any ACP connection amongst each other, whether they use the same or different CA due to the ACP domain membership check. Eckert, et al. Expires 3 May 2021 [Page 167] Internet-Draft An Autonomic Control Plane (ACP) October 2020 If the domains use the same CA one could change the ACP setup to permit for the ACP to be established between two ACP nodes with different acp-domain-names, but only for the purpose of disseminating limited information, such as Intent, but not to set up full ACP connectivity, specifically not RPL routing and passing of arbitrary GRASP information. Unless the Intent policies permit this to happen across domain boundaries. This type of approach where the ACP first allows Intent to operate and only then sets up the rest of ACP connectivity based on Intent policy could also be used to enable Intent policies that would limit functionality across the ACP inside a domain, as long as no policy would disturb the distribution of Intent. For example, to limit reachability across the ACP to certain type of nodes or locations of nodes. A.8. Adopting ACP concepts for other environments The ACP as specified in this document is very explicit about the choice of options to allow interoperable implementations. The choices made may not be the best for all environments, but the concepts used by the ACP can be used to build derived solutions: The ACP specifies the use of ULA and deriving its prefix from the domain name so that no address allocation is required to deploy the ACP. The ACP will equally work not using ULA but any other /48 IPv6 prefix. This prefix could simply be a configuration of the ACP registrars (for example when using BRSKI) to enroll the domain certificates - instead of the ACP registrar deriving the /48 ULA prefix from the AN domain name. Some solutions may already have an auto-addressing scheme, for example derived from existing unique device identifiers (e.g., MAC addresses). In those cases it may not be desirable to assign addresses to devices via the ACP address information field in the way described in this document. The certificate may simply serve to identify the ACP domain, and the address field could be omitted. The only fix required in the remaining way the ACP operate is to define another element in the domain certificate for the two peers to decide who is the Decider and who is the Follower during secure channel building. Note though that future work may leverage the acp address to authenticate "ownership" of the address by the device. If the address used by a device is derived from some pre-existing permanent local ID (such as MAC address), then it would be useful to store that address in the certificate using the format of the access address information field or in a similar way. Eckert, et al. Expires 3 May 2021 [Page 168] Internet-Draft An Autonomic Control Plane (ACP) October 2020 The ACP is defined as a separate VRF because it intends to support well managed networks with a wide variety of configurations. Therefore, reliable, configuration-indestructible connectivity cannot be achieved from the Data-Plane itself. In solutions where all transit connectivity impacting functions are fully automated (including security), indestructible and resilient, it would be possible to eliminate the need for the ACP to be a separate VRF. Consider the most simple example system in which there is no separate Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes a fully autonomic network - except that it does not support automatic addressing for user equipment. This gap can then be closed for example by adding a solution derived from [I-D.ietf-anima-prefix-management]. TCP/TLS as the protocols to provide reliability and security to GRASP in the ACP may not be the preferred choice in constrained networks. For example, CoAP/DTLS (Constrained Application Protocol) may be preferred where they are already used, allowing to reduce the additional code space footprint for the ACP on those devices. Hop- by-hop reliability for ACP GRASP messages could be made to support protocols like DTLS by adding the same type of negotiation as defined in this document for ACP secure channel protocol negotiation. End- to-end GRASP connections can be made to select their transport protocol in future extensions of the ACP meant to better support constrained devices by indicating the supported transport protocols (e.g. TLS/DTLS) via GRASP parameters of the GRASP objective through which the transport endpoint is discovered. The routing protocol RPL used for the ACP does explicitly not optimize for shortest paths and fastest convergence. Variations of the ACP may want to use a different routing protocol or introduce more advanced RPL profiles. Variations such as what routing protocol to use, or whether to instantiate an ACP in a VRF or (as suggested above) as the actual Data-Plane, can be automatically chosen in implementations built to support multiple options by deriving them from future parameters in the certificate. Parameters in certificates should be limited to those that would not need to be changed more often than certificates would need to be updated anyhow; Or by ensuring that these parameters can be provisioned before the variation of an ACP is activated in a node. Using BRSKI, this could be done for example as additional follow-up signaling directly after the certificate enrollment, still leveraging the BRSKI TLS connection and therefore not introducing any additional connectivity requirements. Eckert, et al. Expires 3 May 2021 [Page 169] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Last but not least, secure channel protocols including their encapsulations are easily added to ACP solutions. ACP hop-by-hop network layer secure channels could also be replaced by end-to-end security plus other means for infrastructure protection. Any future network OAM should always use end-to-end security anyhow and can leverage the domain certificates and is therefore not dependent on security to be provided for by ACP secure channels. A.9. Further (future) options A.9.1. Auto-aggregation of routes Routing in the ACP according to this specification only leverages the standard RPL mechanism of route optimization, e.g. keeping only routes that are not towards the RPL root. This is known to scale to networks with 20,000 or more nodes. There is no auto-aggregation of routes for /48 ULA prefixes (when using rsub in the acp-node-name) and/or Zone-ID based prefixes. Automatic assignment of Zone-ID and auto-aggregation of routes could be achieved for example by configuring zone-boundaries, announcing via GRASP into the zones the zone parameters (zone-ID and /48 ULA prefix) and auto-aggregating routes on the zone-boundaries. Nodes would assign their Zone-ID and potentially even /48 prefix based on the GRASP announcements. A.9.2. More options for avoiding IPv6 Data-Plane dependencies As described in Section 6.13.2, the ACP depends on the Data-Plane to establish IPv6 link-local addressing on interfaces. Using a separate MAC address for the ACP allows to fully isolate the ACP from the Data-Plane in a way that is compatible with this specification. It is also an ideal option when using Single-root input/output virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- root_input/output_virtualization) in an implementation to isolate the ACP because different SR-IOV interfaces use different MAC addresses. When additional MAC address(es) are not available, separation of the ACP could be done at different demux points. The same subnet interface could have a separate IPv6 interface for the ACP and Data- Plane and therefore separate link-local addresses for both, where the ACP interface is non-configurable on the Data-Plane. This too would be compatible with this specification and not impact interoperability. An option that would require additional specification is to use a different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets for the ACP. This would be a similar approach as used for IP Eckert, et al. Expires 3 May 2021 [Page 170] Internet-Draft An Autonomic Control Plane (ACP) October 2020 authentication packets in [IEEE-802.1X] which use the Extensible Authentication Protocol over Local Area Network (EAPoL) ethertype (0x88A2). Note that in the case of ANI nodes, all the above considerations equally apply to the encapsulation of BRSKI packets including GRASP used for BRSKI. A.9.3. ACP APIs and operational models (YANG) Future work should define YANG ([RFC7950]) data model and/or node internal APIs to monitor and manage the ACP. Support for the ACP Adjacency Table (Section 6.3) and ACP GRASP need to be included into such model/API. A.9.4. RPL enhancements ..... USA ...... ..... Europe ...... NOC1 NOC2 | | | metric 100 | ACP1 --------------------------- ACP2 . | | . WAN | metric 10 metric 20 | . Core | | . ACP3 --------------------------- ACP4 . | metric 100 | | | . | | . Sites ACP10 ACP11 . Figure 19: Dual NOC The profile for RPL specified in this document builds only one spanning-tree path set to a root, typically a registrar in one NOC. In the presence of multiple NOCs, routing toward the non-root NOCs may be suboptimal. Figure 19 shows an extreme example. Assuming that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated DODAG/routes are shortest paths towards the RPL root. Eckert, et al. Expires 3 May 2021 [Page 171] Internet-Draft An Autonomic Control Plane (ACP) October 2020 To overcome these limitations, extensions/modifications to the RPL profile can provide optimality for multiple NOCs. This requires utilizing Data-Plane artifact including IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) routing table entries could be used. Flooding of ACP GRASP messages can be further constrained and therefore optimized by flooding only via links that are part of the RPL DODAG. A.9.5. Role assignments ACP connect is an explicit mechanism to "leak" ACP traffic explicitly (for example in a NOC). It is therefore also a possible security gap when it is easy to enable ACP connect on arbitrary compromised ACP nodes. One simple solution is to define an extension in the ACP certificates ACP information field indicating the permission for ACP connect to be configured on that ACP node. This could similarly be done to decide whether a node is permitted to be a registrar or not. Tying the permitted "roles" of an ACP node to the ACP certificate provides fairly strong protection against misconfiguration, but is still subject to code modifications. Another interesting role to assign to certificates is that of a NOC node. This would allow to limit certain type of connections such as OAM TLS connections to only NOC initiator or responders. A.9.6. Autonomic L3 transit In this specification, the ACP can only establish autonomic connectivity across L2 hops and only explicitly configured options to tunnel across L3. Future work should specify mechanisms to automatically tunnel ACP across L3 networks. A hub&spoke option would allow to tunnel across the Internet to a cloud or central instance of the ACP, a peer-to-peer tunneling mechanism could tunnel ACP islands across an L3VPN infrastructure. A.9.7. Diagnostics Section 9.1 describes diagnostics options that can be done without changing the external, interoperability affecting characteristics of ACP implementations. Even better diagnostics of ACP operations is possible with additional signaling extensions, such as: Eckert, et al. Expires 3 May 2021 [Page 172] Internet-Draft An Autonomic Control Plane (ACP) October 2020 1. Consider if LLDP should be a recommended functionality for ANI devices to improve diagnostics, and if so, which information elements it should signal (noting that such information is conveyed in an insecure manner). Includes potentially new information elements. 2. In alternative to LLDP, A DULL GRASP diagnostics objective could be defined to carry these information elements. 3. The IDevID certificate of BRSKI pledges should be included in the selected insecure diagnostics option. This may be undesirable when exposure of device information is seen as too much of a security issue (ability to deduce possible attack vectors from device model for example). 4. A richer set of diagnostics information should be made available via the secured ACP channels, using either single-hop GRASP or network wide "topology discovery" mechanisms. A.9.8. Avoiding and dealing with compromised ACP nodes Compromised ACP nodes pose the biggest risk to the operations of the network. The most common type of compromise is leakage of credentials to manage/configure the device and the application of malicious configuration including the change of access credentials, but not the change of software. Most of today's networking equipment should have secure boot/software infrastructure anyhow, so attacks that introduce malicious software should be a lot harder. The most important aspect of security design against these type of attacks is to eliminate password based configuration access methods and instead rely on certificate based credentials handed out only to nodes where it is clear that the private keys cannot leak. This limits unexpected propagation of credentials. If password based credentials to configure devices still need to be supported, they must not be locally configurable, but only be remotely provisioned or verified (through protocols like RADIUS or Diameter), and there must be no local configuration permitting to change these authentication mechanisms, but ideally they should be autoconfiguring across the ACP. See [I-D.eckert-anima-noc-autoconfig]. Without physical access to the compromised device, attackers with access to configuration should not be able to break the ACP connectivity, even when they can break or otherwise manipulate (spoof) the Data-Plane connectivity through configuration. To achieve this, it is necessary to avoid providing configuration options for the ACP, such as enabling/disabling it on interfaces. For example, there could be an ACP configuration that locks down the current ACP config unless factory reset is done. Eckert, et al. Expires 3 May 2021 [Page 173] Internet-Draft An Autonomic Control Plane (ACP) October 2020 With such means, the valid administration has the best chances to maintain access to ACP nodes, discover malicious configuration though ongoing configuration tracking from central locations for example, and to react accordingly. The primary reaction is withdrawal/change of credentials, terminate malicious existing management sessions and fixing the configuration. Ensuring that management sessions using invalidated credentials are terminated automatically without recourse will likely require new work. Only when these steps are not feasible would it be necessary to revoke or expire the ACP certificate credentials and consider the node kicked off the network - until the situation can be further rectified, likely requiring direct physical access to the node. Without extensions, compromised ACP nodes can only be removed from the ACP at the speed of CRL/OCSP information refresh or expiry (and non-removal) of short lived certificates. Future extensions to the ACP could for example use GRASP flooding distribution of triggered updates of CRL/OCSP or explicit removal indication of the compromised nodes domain certificate. A.9.9. Detecting ACP secure channel downgrade attacks The following text proposes a mechanism to protect against downgrade attacks without introducing a new specialized UPFRONT GRASP secure channel mechanism. Instead, it relies on running GRASP after establishing a secure channel protocol to verify if the established secure channel option could have been the result of a MITM downgrade attack: MITM attackers can force downgrade attacks for ACP secure channel selection by filtering/modifying DULL GRASP messages and/or actual secure channel data packets. For example, if at some point in time DTLS traffic could be easier decrypted than traffic of IKEv2, the MITM could filter all IKEv2 packets to force ACP nodes to use DTLS (assuming the ACP nodes in question supported both DTLS and IKEv2). For cases where such MITM attacks are not capable to inject malicious traffic (but only to decrypt the traffic), a downgrade attack could be discovered after a secure channel connection is established, for example by use of the following type of mechanism: After the secure channel connection is established, the two ACP peers negotiate via an appropriate (To Be Defined) GRASP negotiation which ACP secure channel protocol should have been selected between them (in the absence of a MITM attacker). This negotiation would have to Eckert, et al. Expires 3 May 2021 [Page 174] Internet-Draft An Autonomic Control Plane (ACP) October 2020 signal the DULL GRASP announced ACP secure channel options by each peer followed by an announcement of the preferred secure channel protocol by the ACP peer that is the Decider in the secure channel setup, e.g. the ACP peer that is deciding which secure channel protocol to pick. If that chosen secure channel protocol is different from the one that actually was chosen, then this mismatch is an indication that there is a MITM attacker or other similar issue (firewall prohibiting the use of specific protocols) that caused a non-preferred secure channel protocol to be chosen. This discovery could then result in mitigation options such as logging and ensuing investigations. Appendix B. Unfinished considerations (To Be Removed From RFC) [RFC-Editor: This whole appendix B. and its subsections to be removed for the RFC. This appendix contains unfinished considerations that are removed from the RFC, they are maintained in this draft as a log of the state of discussion and point of reference. Together with this appendix, also the references pointing to it are marked to be removed from the RFC because no consensus could be reached that a self-reference to a draft version of the RFC is an appropriate breadcrumb to point to unfinished considerations. The authors plan to move these considerations into a new target informational draft, please look for draft-eckert-anima-acp- considerations. B.1. Considerations for improving secure channel negotiation Proposed text from Benjamin Kaduk. It is suggested to replace the text of appendix A.6 in previous versions of this draft (up to version 29). The discovery procedure in this specification for low-level ACP channel support by layer-2 peers involves DULL GRASP and attempting (usually in parallel) to establish all supported channel types, learning the peer ACP address and correspondingly the assignment of Decider and Follower roles, and tearing down all channels other than the one preferred by the Decider. This procedure, in general, becomes resource intensive as the number of possible secure channels grows; even worse, under some threat models, the security of the discovery result is only as strong as the weakest supported secure channel protocol. Furthermore, the unilateral determination of "best" channel type by the Decider does not result in the optimal outcome in all possible scenarios. Eckert, et al. Expires 3 May 2021 [Page 175] Internet-Draft An Autonomic Control Plane (ACP) October 2020 This situation is tolerable at present, with only two secure channels (DTLS and IPsec) defined, but long-term agility in the vein of [BCP201] will require the introduction of an alternate discovery/ negotiation procedure. While IKEv2 is the IETF standard protocol for negotiating security associations, it currently does not have a defined mechanism flexible enough to negotiate the parameters needed for, e.g., an ACP DTLS channel, let alone for allowing ACP peers to indicate their preference metrics for channel selection. Such a mechanism or mechanisms could be defined, but if ACP agility requires introducing a new channel type, for example MacSec, IKEv2 would again need to be extended in order to negotiate an ACP MacSec association. Making ACP channel agility dependent on updates to IKEv2 is likely to result in obstacles due to different timescales of evolution, since IKEv2 implementations help form the core of Internet-scale security infrastructure and must accordingly be robust and thoroughly tested. Accordingly, a dedicated ACP channel negotiation mechanism is appropriate as a way to provide long-term algorithm and secure- channel protocol agility. Such a mechanism is not currently defined, but one possible design is as follows. A new DULL GRASP objective is defined to indicate the GRASP-over-TLS channel, which is by definition preferred to other channel types (including DTLS and IPsec). When both peers advertise support for GRASP-over-TLS, GRASP- over-TLS must run to completion before other channel types are attempted. The GRASP-over-TLS channel performs the necessary negotiation by establishing a TLS connection between the peers and using that connection to secure a dedicated GRASP instance for negotiating supported channel types and preference metrics. This provides a rich language for determining what secure channel protocol to use for the ACP link while taking into account the capabilities and preferences of the ACP peers, all protected by the security of the TLS channel. B.2. ACP address verification The AcpNodeName of most ACP nodes contains in the acp-address field the primary ACP address to be used by the node for end-to-end connections across ACP secure channels. Nevertheless, there is no verification of an ACP peers address specified in this document. This section explains the current understanding as to why this is not done. Not all ACP nodes will have an actual IPv6 address in the acp-address field of their AcpNodeName. Those who do not include nodes that do not support ACP secure channels, such as pre-existing NOC equipment that only connects to the ACP via ACP connect interfaces. Likewise, future ACP node type that may want to have their Node-ID not be defined by an ACP registrar, but differently cannot have the ACP Eckert, et al. Expires 3 May 2021 [Page 176] Internet-Draft An Autonomic Control Plane (ACP) October 2020 address be provided in their ACP certificate where it would be defined by the registrar. In result, any scheme that would rely on verification of the acp-address in the ACP certificate would only apply to a subset of ACP nodes. The transport stack network layer address used for ACP secure channels is not the acp-address. For automatically established ACP secure channels, it is a link-local IPv6 address. For explicitly configured ACP secure channels (to reach across non ACP L3 network segments), the address is any IPv4 or IPv6 address routable to that remote destination. When the acp-address is actually used across the ACP, it can only be verified by a peer when the peer has the certificate of the peer. Unless further higher layer mechanisms are developed on top of the ACP (for example via ASA), the only mechanism to access a peers ACP certificate is for secure connections in which the peers certificates are exchanged and cryptographically verified, e.g. TLS and DTLS. Initially, it is expected that the ACP will carry many legacy network management control connections that unfortunately not end-to-end authenticated but that are solely protected by being carried across the ACP secure channels. ACP address verification therefore cannot be used for such connections without additional higher layer components. For the remaining (TLS/DTLS) connections for which address verification can be used, the main question is: what additional benefit would address verification provide? The main value that transport stack network layer address verification could provide for these type of connections would be the discovery of on-path transport proxies. For example, in case of BRSKI, pledges connect to an ACP registrar via an ASA implementing a TCP proxy because the pledge itself has at that point in time no ACP certificate valid to build ACP secure channels and hence needs to rely on such a proxy. This is one example where such a TCP proxy is required and not a form of attack. In general, on path TCP proxies could be a form of attack, but it stands to reason, that an attacker that manages to enable a malicious TCP proxy could likely equally build a transparent proxy not changing the network layer addresses. Only when the attacker operates off- path would this option not be possible. Such attacks could indeed be possible: An impaired ACP node could announce itself as another service instance for a service whose utilization it wants to attack. It could then attempt to look like a valid server by simply TCP proxying the clients connections to a valid server and then attack the connections passing through it (passive decrypting or passive Eckert, et al. Expires 3 May 2021 [Page 177] Internet-Draft An Autonomic Control Plane (ACP) October 2020 fingerprint analysis). But like the BRSKI proxy, this behavior could be perfectly legitimate and not an attack. For example, TCP has in the past often suffered from performance issues across difficult (high capacity, high loss) paths, and TCP proxies where and are being used simply as a tool for isolating such path segments (such as a WAN), and providing caching and local-retransmit of in-transit packets, reducing the effective path segment capacity. As explained elsewhere in this document already, considerations for these type of attack are therefore outside the scope of the ACP but fundametal to further design of the ASA infrastructure. Beyond distinguishing whether a TCP proxy would be beneficial or malicious, the even more fundamental question is how to determine from a multitude of service announcements which instance is the most trustworthy and functionally best. In the Internet/web, this question is NOT solved inside the network but through off-net human interaction ("trust me, the best search engine is www..com"). B.3. Public CA considerations Public CAs are outside the scope of this document for the following reasons. This appendix describes the current state of understanding for those interested to consider utilizing public CA for the ACP in the future. If public CA where to be used to enroll ACP nodes and act as TA, this would require a model in which the public CA would be able to assert the ownership of the information requested in the certificate, especially the AcpNodeName, for example mitigated by the domain registrar(s). Due to the use of a new, ACP unique encoding of the AcpNodeName, there is no mechanism for public CA to do so. More importantly though, isolation between ACPs of disjoint operated ACPs is achieved in the current ACP design through disjoint TA. A public CA is in general based on a single (set of) TA shared across all certificates signed by the CA. Due to the fact that the ACP domain membership check also validates that a peers domain name in the AcpNodeName matches that of the ACP node itself, it would be possible to use the same TA across disjoint ACP domains, but the security and attack implications of such an approach are beyond the scope of this document. The use of ULA addresses in the AcpNodeName is another novel aspect for certificates from a possible public CA. Typically, ULA addresses are not meant to be signed by a public CA when carried in an address field, because there is no ownership of a particular ULA address in the scope of the Internet, which is what public CA operate on. Eckert, et al. Expires 3 May 2021 [Page 178] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Nevertheless, the ULA addresses used by the ACP are scoped to be valid only within the confines of a specific ACP as defined by the domain name in the AcpNodeName. However, this understanding has not been reviewed or accepted by any bodies responsible for policies of public CA. Because in this specification, ACPs are isolated from each other primarily by their TA, when a public CA would intend to sign ACP certificates and using a single TA to sign TA of ACP certificates from different operators/domain, it could do so by ensuring that the domain name in the AcpNodeName was a globally owned DNS ACP domain name of the organization, and beyond that, it would need to validate that the ACP registrar of that domain who is mitigating the enrollment is authorized to vouch for the ownership of the acp- address within the scope of the ACP domain name. B.4. Hardening DULL GRASP considerations DULL GRASP suffers from similar type of DoS attacks as many link- local multicast discovery protocols, for example mDNS. Attackers on a subnet may be able to inject malicious DULL GRASP messages that are indistinguishable from non-malicious DULL GRASP messages to create Denial-of-Service (DoS) attacks that force ACP nodes to attempt many unsuccessful ACP secure channel connections. When an ACP node sees multiple AN_ACP objectives for the same secure channel protocol on different transport addresses, it could prefer connecting via the well-known transport address if the secure channel method has one, such as UDP port 500 for IKEv2. For protocols such as (ACP secure channel over) DTLS for which there are no well defined port number, this heuristic does not provide benefits though. DoS attack with port numbers can also be eliminated by relying on well known-port numbers implied by the GRASP method-name. For example, a future service name of "DTLSacp" could be defined to be associated only to a newly to be assigned well known UDP port for ACP over DTLS, and the port number in the GRASP transport address information would be ignored. Note that there is already a variety of ports assigned to specific protocols over DTLS by IANA, so especially for DTLS this would not be uncommon. Authors' Addresses Eckert, et al. Expires 3 May 2021 [Page 179] Internet-Draft An Autonomic Control Plane (ACP) October 2020 Toerless Eckert (editor) Futurewei Technologies Inc. USA 2330 Central Expy Santa Clara, 95050 United States of America Email: tte+ietf@cs.fau.de Michael H. Behringer (editor) Email: michael.h.behringer@gmail.com Steinthor Bjarnason Arbor Networks 2727 South State Street, Suite 200 Ann Arbor, MI 48104 United States Email: sbjarnason@arbor.net Eckert, et al. Expires 3 May 2021 [Page 180] ./draft-ietf-clue-datachannel-18.txt0000644000764400076440000007054613460016423016564 0ustar iustyiusty CLUE Working Group C. Holmberg Internet-Draft Ericsson Intended status: Experimental April 24, 2019 Expires: October 26, 2019 CLUE Protocol data channel draft-ietf-clue-datachannel-18 Abstract This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 26, 2019. Copyright Notice Copyright (c) 2019 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. Holmberg Expires October 26, 2019 [Page 1] Internet-Draft CLUE data channel April 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CLUE data channel . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. SCTP Considerations . . . . . . . . . . . . . . . . . . . 4 3.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. SCTP Payload Protocol Identifier (PPID) . . . . . . . 4 3.2.3. Reliability . . . . . . . . . . . . . . . . . . . . . 4 3.2.4. Order . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.5. Stream Reset . . . . . . . . . . . . . . . . . . . . 5 3.2.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 5 3.2.7. Closing the CLUE data channel . . . . . . . . . . . . 5 3.3. SDP Considerations . . . . . . . . . . . . . . . . . . . 5 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.2. SDP dcmap Attribute . . . . . . . . . . . . . . . . . 6 3.3.3. SDP dcsa Attribute . . . . . . . . . . . . . . . . . 7 3.3.4. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. New WebRTC data channel Protocol Value . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This document defines how to use the WebRTC data channel mechanism [I-D.ietf-rtcweb-data-channel] to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol [I-D.ietf-clue-protocol] messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association [RFC8261] used to realize the CLUE data channel using the Session Description Protocol (SDP) [RFC4566], and defines usage of the SDP- based "SCTP over DTLS" data channel negotiation mechanism [I-D.ietf-mmusic-data-channel-sdpneg]. This includes SCTP considerations specific to a CLUE data channel, the SDP Media Description ("m=" line) values, and usage of SDP attributes specific to a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer [RFC3264] procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. Holmberg Expires October 26, 2019 [Page 2] Internet-Draft CLUE data channel April 2019 NOTE: The usage of the Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel is outside the scope of this document. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. SCTPoDTLS association refers to an SCTP association carried over an DTLS connection [RFC8261]. WebRTC data channel refers to a pair of SCTP streams over a SCTPoDTLS association that is used to transport non-media data between two entities, as defined in [I-D.ietf-rtcweb-data-channel]. CLUE data channel refers to a WebRTC data channel [I-D.ietf-rtcweb-data-channel] realization, with a specific set of SCTP characteristics, with the purpose of transporting CLUE protocol [I-D.ietf-clue-protocol] messages between two CLUE entities. CLUE entity refers to a SIP User Agent (UA) [RFC3261] that supports the CLUE data channel and the CLUE protocol. CLUE session refers to a SIP session [RFC3261] between two SIP UAs, where a CLUE data channel, associated with the SIP session, has been established between the SIP UAs. SCTP stream is defined in [RFC4960] as a unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. SCTP identifier is defined in [RFC4960] as an unsigned integer, which identifies an SCTP stream. 3. CLUE data channel 3.1. General This section describes the realization of a CLUE data channel, using the WebRTC data channel mechanism. This includes a set of SCTP characteristics specific to a CLUE data channel, the values of the "m=" line describing the SCTPoDTLS association associated with the WebRTC data channel, and the usage of the SDP-based "SCTP over DTLS" Holmberg Expires October 26, 2019 [Page 3] Internet-Draft CLUE data channel April 2019 data channel negotiation mechanism for creating the CLUE data channel. As described in [I-D.ietf-rtcweb-data-channel], the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data channel. Within a given CLUE session, a CLUE entity MUST use a single CLUE data channel for transport of all CLUE messages towards its peer. 3.2. SCTP Considerations 3.2.1. General As described in [I-D.ietf-rtcweb-data-channel], different SCTP options (e.g., regarding ordered delivery ), can be used for a data channel. This section describes the SCTP options used for a CLUE data channel. Section 3.3 describes how SCTP options are signaled using SDP. NOTE: While SCTP allows SCTP options to be applied per SCTP message, [I-D.ietf-rtcweb-data-channel] mandates that, for a given data channel, the same SCTP options are applied to each SCTP message associated with that data channel. 3.2.2. SCTP Payload Protocol Identifier (PPID) A CLUE entity MUST use the PPID value 51 when sending a CLUE message on a CLUE data channel. NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 51 indicates that the SCTP message contains data encoded in a UTF-8 format. The PPID value 51 does not indicate which application protocol the SCTP message is associated with, only the format in which the data is encoded. 3.2.3. Reliability The usage of SCTP for the CLUE data channel ensures reliable transport of CLUE protocol [I-D.ietf-clue-protocol] messages. [I-D.ietf-rtcweb-data-channel] requires the support of the partial reliability extension defined in [RFC3758] and the limited retransmission policy defined in [RFC7496]. A CLUE entity MUST NOT use these extensions, as messages are required to always be sent Holmberg Expires October 26, 2019 [Page 4] Internet-Draft CLUE data channel April 2019 reliably. A CLUE entity MUST terminate the session if it detects that the peer entity uses any of the extensions. 3.2.4. Order A CLUE entity MUST use the ordered delivery SCTP service, as described in [RFC4960], for the CLUE data channel. 3.2.5. Stream Reset A CLUE entity MUST support the stream reset extension defined in [RFC6525]. As defined in [I-D.ietf-rtcweb-data-channel], the dynamic address reconfiguration extension ('Supported Extensions Parameter' parameter) defined in [RFC5061] must be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used for CLUE data channels. 3.2.6. SCTP Multihoming SCTP multi-homing is not supported for SCTPoDTLS associations, and can therefore not be used for a CLUE data channel. 3.2.7. Closing the CLUE data channel As described in [I-D.ietf-rtcweb-data-channel], to close a data channel, an entity sends an SCTP reset message [RFC6525] on its outgoing SCTP stream associated with the data channel. When the remote peer receives the reset message, it also sends (unless already sent) a reset message on its outgoing SCTP stream associated with the data channel. The SCTPoDTLS association, and other data channels established on the same association, are not affected by the SCTP reset messages. 3.3. SDP Considerations 3.3.1. General This section defines how to construct the SDP Media Description ("m=" line) for describing the SCTPoDTLS association used to realize a CLUE data channel. The section also defines how to use the SDP-based "SCTP over DTLS" data channel negotiation mechanism [I-D.ietf-mmusic-data-channel-sdpneg] for establishing a CLUE data channel on the SCTPoDTLS association. Holmberg Expires October 26, 2019 [Page 5] Internet-Draft CLUE data channel April 2019 NOTE: Other protocols than SDP for negotiating usage of an SCTPoDTLS association for realizing a CLUE data channel are outside the scope of this specification. [I-D.ietf-clue-signaling] describes the SDP Offer/Answer procedures for negotiating a CLUE session, including the CLUE controlled media streams and the CLUE data channel. 3.3.1.1. SDP Media Description Fields [I-D.ietf-mmusic-sctp-sdp] defines how to set the values of an "m=" line describing an SCTPoDTLS association. As defined in [I-D.ietf-mmusic-sctp-sdp], for a CLUE data channel the values are set as following: +---------------+----------+-----------------+----------------------+ | media | port | proto | fmt | +---------------+----------+-----------------+----------------------+ | "application" | UDP port | "UDP/DTLS/SCTP" | "webrtc-datachannel" | | | value | | | | "application" | TCP port | "TCP/DTLS/SCTP" | "webrtc-datachannel" | | | value | | | +---------------+----------+-----------------+----------------------+ Table 1: SDP "proto" field values CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work (for instance, when the Interactive Connectivity Establishment (ICE) mechanism [RFC8445] is used and the ICE procedures determine that TCP transport is required). 3.3.1.2. SDP sctp-port Attribute As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute value is set to the SCTP port of the SCTPoDTLS association. A CLUE entity can choose any valid SCTP port value [I-D.ietf-mmusic-sctp-sdp]. 3.3.2. SDP dcmap Attribute The values of the SDP dcmap attribute [I-D.ietf-mmusic-data-channel-sdpneg], associated with the "m=" line describing the SCTPoDTLS association used to realize the WebRTC data channel, are set as following: Holmberg Expires October 26, 2019 [Page 6] Internet-Draft CLUE data channel April 2019 +----------+------------+------------+--------+----------+----------+ | stream- | sub- | label | ordere | max-retr | max-time | | id | protocol | | d | | | +----------+------------+------------+--------+----------+----------+ | Value of | "CLUE" | Appli- | "true" | N/A | N/A | | the SCTP | | cation | | | | | stream | | specific | | | | | used to | | | | | | | realize | | | | | | | the CLUE | | | | | | | data | | | | | | | channel | | | | | | +----------+------------+------------+--------+----------+----------+ Table 2: SDP dcmap attribute values NOTE: As CLUE entities are required to use ordered SCTP message delivery, with full reliability, according to the procedures in [I-D.ietf-mmusic-data-channel-sdpneg] the max-retr and max-time attribute parameters are not used when negotiating CLUE data channels. 3.3.3. SDP dcsa Attribute The SDP dcsa attribute [I-D.ietf-mmusic-data-channel-sdpneg] is not used when establishing a CLUE data channel. 3.3.4. Example The example in Figure 1 shows an SDP media description for a CLUE data channel. Examples of complete SDP examples can be found in [I-D.ietf-clue-signaling]. m=application 54111 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE";ordered=true Figure 1: SDP Media Description for a CLUE data channel 4. Security Considerations This specification relies on the security properties of the WebRTC data channel described in [I-D.ietf-rtcweb-data-channel], including reliance on DTLS. Since CLUE sessions are established using SIP/SDP, protecting the data channel against message modification and recovery requires the use of SIP authentication and authorization mechanisms Holmberg Expires October 26, 2019 [Page 7] Internet-Draft CLUE data channel April 2019 described in [RFC3261] for session establishment prior to establishing the data channel. 5. IANA Considerations 5.1. New WebRTC data channel Protocol Value [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] This document adds the 'CLUE' value to the "WebSocket Subprotocol Name Registry" as follows: Subprotocl Identifier: CLUE Subprotocol Common Name: CLUE Subprotocol Definition: RFC-XXXX Reference: RFC-XXXX 6. Acknowledgments Thanks to Paul Kyzivat, Christian Groves and Mark Duckworth for comments on the document. 7. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-clue-datachannel-17 o Editorial changes to Tables based on TSV-ART review. Changes from draft-ietf-clue-datachannel-16 o Category changed to Experimental. Changes from draft-ietf-clue-datachannel-15 o Updates based on IESG review by Roman Danyliw. o Make CLUE references Informative, as they are going to be published as Experimental RFCs. Changes from draft-ietf-clue-datachannel-14 o ICE reference update. o Reference draft versions updates. Holmberg Expires October 26, 2019 [Page 8] Internet-Draft CLUE data channel April 2019 Changes from draft-ietf-clue-datachannel-13 o Editorial changes based on Gen-ART review from Brian Carpenter. Changes from draft-ietf-clue-datachannel-12 o Changes based on AD comments from Alissa Cooper (https://www.ietf.org/mail-archive/web/clue/current/ msg04911.html): o - DCEP reference removed from security considerations. o - Editorial fixes. o - NOTE: Comment regarding the Security Considerations is still pending. Changes from draft-ietf-clue-datachannel-11 o Changes based on WGLC comments from Juergen Stoetzer-Bradler and Christian groves: o - Reference updates. o - 'Reference' added to IANA registration data. Changes from draft-ietf-clue-datachannel-10 o Security Considerations modified and enhanced, based on comments provided by Alissa Cooper. Changes from draft-ietf-clue-datachannel-09 o Reference updates: o - draft-ietf-tsvwg-sctp-prpolicies published as RFC 7496 o - Reference update of draft versions Changes from draft-ietf-clue-datachannel-08 o Changes based on WGLC comments from Daniel Burnett: o - Editorial corrections. o Changes based on WGLC comments from Paul Kyzivat: o - Editorial corrections. Changes from draft-ietf-clue-datachannel-07 o Changes based on WGLC comments from Christian Groves: o - IANA considerations for dcmap attribute removed. o - Explicit clarification that the dcmap attribute max-time and max-retr parameters are not used with ordered/reliable transmission of SCTP messages. o - Indication that TCP transport should only be used if ICE is used, and if usage of TCP is required by ICE. Holmberg Expires October 26, 2019 [Page 9] Internet-Draft CLUE data channel April 2019 o - Informative reference to ICE added. o - Editorial corrections. o Changes based on WGLC comments from Mark Duckworth: o - Make it more clear that the rules regarding usage of partial reliability and ordered reliability apply to CLUE data channels. o Changes based on WGLC comments from Paul Kyzivat: o - Clarify that same SCTP options are applied to each SCTP message associated with a given data channel. o - Switched location of sections 3.2 and 3.3. o - PPID table removed. Not needed, since only one value is used. o - Editorial corrections. Changes from draft-ietf-clue-datachannel-06 o Usage of DCEP removed. Changes from draft-ietf-clue-datachannel-05 o "DTLS/SCTP" split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". o Removed note regarding optionality of including the SDP sctp-port attribute. o Added defintion of 'SCTPoDTLS association' to the Conventions. o Reference to RFC 4566 (SDP) added. Changes from draft-ietf-clue-datachannel-04 o Defines DCEP and external SDP negotiation as two separate mechanisms for negotiating a CLUE data channel. o Updates based on technical changes in referenced specifications. o Reference to draft-ietf-mmusic-sctp-sdp added. Changes from draft-ietf-clue-datachannel-03 o IANA considerations added. o Editorial changes based on comments from Christian Groves. Changes from draft-ietf-clue-datachannel-02 o SDP "m=" line example fixed. o OPEN ISSUE #1 closed. o - It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel- sdpneg, as it was adopted as a WG item in MMUSIC. o - Details for draft-ejzak-mmusic-data-channel-sdpneg usage added. o SDP Offer/Answer procedures removed, as they will be defined in the CLUE protocol draft. o References updated. Changes from draft-ietf-clue-datachannel-01 Holmberg Expires October 26, 2019 [Page 10] Internet-Draft CLUE data channel April 2019 o Support of interleaving "MUST"->"SHOULD". o Example updated. o Reference update. Changes from draft-ietf-clue-datachannel-00 o SDP Offer/Answer procedures structures according to RFC 3264. o Reference update. Changes from draft-holmberg-clue-datachannel-04 o Draft submitted as draft-ietf-clue-data-channel-00. o Editorial nits fixed. o Changes based on comments from Paul Kyzivat (http://www.ietf.org/ mail-archive/web/clue/current/msg03559.html). o - Proto value fixed. o - Explicit text that the partial reliability and limited retransmission policies MUST NOT be used. o - Added open issue on whether the DCEP 'protocol' field value for CLUE should contain a version number. o - Removed paragraph saying that an offerer must not insert more than one "m=" line describing an SCTPoDTLS association to be used to realize a CLUE data channel, as the draft already states that only one CLUE data channel per CLUE session shall be opened. o - Added reference to draft-ietf-rtcweb-data-protocol regarding details on reseting SCTP streams. o - Added text saying that the value of the DCEP 'channel type' MUST be DATA_CHANNEL_RELIABLE. o - Clarified that DCEP must be supported, and used in the absence of another mechanism for opening a CLUE data channel. Changes from draft-holmberg-clue-datachannel-03 o Procedures updated, based on WG agreement (IETF#89) to use DCEP for the CLUE data channel. o Procedures updated, based on WG agreement (IETF#89) that offerer is responsible for sending DCEP DATA_CHANNEL_OPEN. o Editorial changes, and alignments caused by changes in referenced specifications. Changes from draft-holmberg-clue-datachannel-02 o PPID value for CLUE messages added o References updated Changes from draft-holmberg-clue-datachannel-01 o More text added Holmberg Expires October 26, 2019 [Page 11] Internet-Draft CLUE data channel April 2019 Changes from draft-holmberg-clue-datachannel-00 o Editorial corrections based on comments from Paul K 8. References 8.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, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, . [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, . [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, . Holmberg Expires October 26, 2019 [Page 12] Internet-Draft CLUE data channel April 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Loreto, S., and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf- mmusic-sctp-sdp-26.txt (work in progress), April 2017. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data channels", draft-ietf-rtcweb-data-channel-13.txt (work in progress), January 2015. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, R., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon, "SDP-based "SCTP over DTLS" data channel negotiation", draft-ietf-mmusic-data-channel-sdpneg-26.txt (work in progress), April 2019. 8.2. Informative References [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC data channel Establishment Protocol", draft-ietf-rtcweb-data-protocol- 09.txt (work in progress), January 2015. [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft-ietf- clue-protocol-17.txt (work in progress), September 2018. Holmberg Expires October 26, 2019 [Page 13] Internet-Draft CLUE data channel April 2019 [I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., and S. Romano, "CLUE Signaling", draft-ietf-clue-signaling-14.txt (work in progress), October 2018. Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires October 26, 2019 [Page 14] ./draft-ietf-anima-bootstrapping-keyinfra-45.txt0000644000764400076440000112027113753021540021151 0ustar iustyiusty ANIMA WG M. Pritikin Internet-Draft Cisco Intended status: Standards Track M. Richardson Expires: 15 May 2021 Sandelman T.T.E. Eckert Futurewei USA M.H. Behringer K.W. Watsen Watsen Networks 11 November 2020 Bootstrapping Remote Secure Key Infrastructures (BRSKI) draft-ietf-anima-bootstrapping-keyinfra-45 Abstract This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Pritikin, et al. Expires 15 May 2021 [Page 1] Internet-Draft BRSKI November 2020 This Internet-Draft will expire on 15 May 2021. Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 11 1.3.1. Support environment . . . . . . . . . . . . . . . . . 11 1.3.2. Constrained environments . . . . . . . . . . . . . . 11 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 1.4. Leveraging the new key infrastructure / next steps . . . 12 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices . . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 2.3.1. Identification of the Pledge . . . . . . . . . . . . 18 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 19 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20 2.5. Architectural Components . . . . . . . . . . . . . . . . 23 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 Pritikin, et al. Expires 15 May 2021 [Page 2] Internet-Draft BRSKI November 2020 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 33 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 34 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 37 4.3. Proxy discovery and communication of Registrar . . . . . 37 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 40 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 41 5.3. Registrar Authorization of Pledge . . . . . . . . . . . . 43 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43 5.4.1. MASA authentication of customer Registrar . . . . . . 44 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 45 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 47 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 48 5.5.3. MASA checking of voucher request signature . . . . . 48 5.5.4. MASA verification of domain registrar . . . . . . . . 49 5.5.5. MASA verification of pledge prior-signed-voucher-request . . . . . . . . . . . . 50 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 50 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 50 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 53 5.6.2. Pledge authentication of provisional TLS connection . . . . . . . . . . . . . . . . . . . . . 54 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 55 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 56 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 58 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 60 5.8.3. Registrar audit log verification . . . . . . . . . . 61 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 62 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 63 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 63 5.9.3. EST Client Certificate Request . . . . . . . . . . . 64 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 64 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 65 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 66 6. Clarification of transfer-encoding . . . . . . . . . . . . . 66 7. Reduced security operational modes . . . . . . . . . . . . . 66 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 66 7.2. Pledge security reductions . . . . . . . . . . . . . . . 67 7.3. Registrar security reductions . . . . . . . . . . . . . . 68 7.4. MASA security reductions . . . . . . . . . . . . . . . . 69 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 69 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 70 7.4.3. Updating or extending voucher trust anchors . . . . . 71 Pritikin, et al. Expires 15 May 2021 [Page 3] Internet-Draft BRSKI November 2020 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 72 8.2. YANG Module Names Registry . . . . . . . . . . . . . . . 72 8.3. BRSKI well-known considerations . . . . . . . . . . . . . 72 8.3.1. BRSKI .well-known registration . . . . . . . . . . . 72 8.3.2. BRSKI .well-known registry . . . . . . . . . . . . . 73 8.4. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 73 8.5. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 73 8.6. DNS Service Names . . . . . . . . . . . . . . . . . . . . 74 8.7. GRASP Objective Names . . . . . . . . . . . . . . . . . . 74 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 74 9.1. Operational Requirements . . . . . . . . . . . . . . . . 76 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 76 9.1.2. Domain Owner Operational Requirements . . . . . . . . 77 9.1.3. Device Operational Requirements . . . . . . . . . . . 77 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 78 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 78 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 78 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 79 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 81 10.5. Manufacturers and Grey market equipment . . . . . . . . 83 10.6. Some mitigations for meddling by manufacturers . . . . . 83 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 85 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 86 11.2. DomainID must be resistant to second-preimage attacks . 86 11.3. Availability of good random numbers . . . . . . . . . . 87 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 87 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 88 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 89 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 91 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 91 11.6.3. Compromise of MASA web service . . . . . . . . . . . 93 11.7. YANG Module Security Considerations . . . . . . . . . . 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 94 13.2. Informative References . . . . . . . . . . . . . . . . . 98 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 102 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 102 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 102 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 102 Appendix C. Example Vouchers . . . . . . . . . . . . . . . . . . 103 C.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 103 C.1.1. Manufacturer Certificate Authority for IDevID signatures . . . . . . . . . . . . . . . . . . . . . 104 C.1.2. MASA key pair for voucher signatures . . . . . . . . 105 C.1.3. Registrar Certificate Authority . . . . . . . . . . . 107 Pritikin, et al. Expires 15 May 2021 [Page 4] Internet-Draft BRSKI November 2020 C.1.4. Registrar key pair . . . . . . . . . . . . . . . . . 108 C.1.5. Pledge key pair . . . . . . . . . . . . . . . . . . . 110 C.2. Example process . . . . . . . . . . . . . . . . . . . . . 111 C.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 111 C.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 115 C.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 121 Appendix D. Additional References . . . . . . . . . . . . . . . 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 1. Introduction The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol provides a solution for secure zero-touch (automated) bootstrap of new (unconfigured) devices that are called pledges in this document. Pledges have an IDevID installed in them at the factory. "BRSKI" is pronounced like "brewski", a colloquial term for beer in Canada and parts of the US-midwest. [brewski] This document primarily provides for the needs of the ISP and Enterprise focused ANIMA Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process satisfies the [RFC7575] requirements of section 3.3 of making all operations secure by default. Other users of the BRSKI protocol will need to provide separate applicability statements that include privacy and security considerations appropriate to that deployment. Section 9 explains the detailed applicability for this the ACP usage. The BRSKI protocol requires a significant amount of communication between manufacturer and owner: in its default modes it provides a cryptographic transfer of control to the initial owner. In its strongest modes, it leverages sales channel information to identify the owner in advance. Resale of devices is possible, provided that the manufacturer is willing to authorize the transfer. Mechanisms to enable transfers of ownership without manufacturer authorization are not included in this version of the protocol, but could be designed into future versions. This document describes how pledges discover (or are discovered by) an element of the network domain to which the pledge belongs that will perform the bootstrap. This element (device) is called the registrar. Before any other operation, pledge and registrar need to establish mutual trust: 1. Registrar authenticating the pledge: "Who is this device? What is its identity?" Pritikin, et al. Expires 15 May 2021 [Page 5] Internet-Draft BRSKI November 2020 2. Registrar authorizing the pledge: "Is it mine? Do I want it? What are the chances it has been compromised?" 3. Pledge authenticating the registrar: "What is this registrar's identity?" 4. Pledge authorizing the registrar: "Should I join this network?" This document details protocols and messages to answer the above questions. It uses a TLS connection and an PKIX-shaped (X.509v3) certificate (an IEEE 802.1AR [IDevID] IDevID) of the pledge to answer points 1 and 2. It uses a new artifact called a "voucher" that the registrar receives from a "Manufacturer Authorized Signing Authority" (MASA) and passes to the pledge to answer points 3 and 4. A proxy provides very limited connectivity between the pledge and the registrar. The syntactic details of vouchers are described in detail in [RFC8366]. This document details automated protocol mechanisms to obtain vouchers, including the definition of a 'voucher-request' message that is a minor extension to the voucher format (see Section 3) defined by [RFC8366]. BRSKI results in the pledge storing an X.509 root certificate sufficient for verifying the registrar identity. In the process a TLS connection is established that can be directly used for Enrollment over Secure Transport (EST). In effect BRSKI provides an automated mechanism for the "Bootstrap Distribution of CA Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge "MUST [...] engage a human user to authorize the CA certificate using out-of-band" information. With BRSKI the pledge now can automate this process using the voucher. Integration with a complete EST enrollment is optional but trivial. BRSKI is agile enough to support bootstrapping alternative key infrastructures, such as a symmetric key solutions, but no such system is described in this document. 1.1. Prior Bootstrapping Approaches To literally "pull yourself up by the bootstraps" is an impossible action. Similarly the secure establishment of a key infrastructure without external help is also an impossibility. Today it is commonly accepted that the initial connections between nodes are insecure, until key distribution is complete, or that domain-specific keying material (often pre-shared keys, including mechanisms like SIM cards) is pre-provisioned on each new device in a costly and non-scalable Pritikin, et al. Expires 15 May 2021 [Page 6] Internet-Draft BRSKI November 2020 manner. Existing automated mechanisms are known as non-secured 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' [Stajano99theresurrecting] or 'pre-staging'. Another prior approach has been to try and minimize user actions during bootstrapping, but not eliminate all user-actions. The original EST protocol [RFC7030] does reduce user actions during bootstrap but does not provide solutions for how the following protocol steps can be made autonomic (not involving user actions): * using the Implicit Trust Anchor [RFC7030] database to authenticate an owner specific service (not an autonomic solution because the URL must be securely distributed), * engaging a human user to authorize the CA certificate using out- of-band data (not an autonomic solution because the human user is involved), * using a configured Explicit TA database (not an autonomic solution because the distribution of an explicit TA database is not autonomic), * and using a Certificate-Less TLS mutual authentication method (not an autonomic solution because the distribution of symmetric key material is not autonomic). These "touch" methods do not meet the requirements for zero-touch. There are "call home" technologies where the pledge first establishes a connection to a well known manufacturer service using a common client-server authentication model. After mutual authentication, appropriate credentials to authenticate the target domain are transferred to the pledge. This creates several problems and limitations: * the pledge requires realtime connectivity to the manufacturer service, * the domain identity is exposed to the manufacturer service (this is a privacy concern), * the manufacturer is responsible for making the authorization decisions (this is a liability concern), BRSKI addresses these issues by defining extensions to the EST protocol for the automated distribution of vouchers. Pritikin, et al. Expires 15 May 2021 [Page 7] Internet-Draft BRSKI November 2020 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are defined for clarity: ANI: The Autonomic Network Infrastructure as defined by [I-D.ietf-anima-reference-model]. Section 9 details specific requirements for pledges, proxies and registrars when they are part of an ANI. Circuit Proxy: A stateful implementation of the join proxy. This is the assumed type of proxy. drop-ship: The physical distribution of equipment containing the "factory default" configuration to a final destination. In zero- touch scenarios there is no staging or pre-configuration during drop-ship. Domain: The set of entities that share a common local trust anchor. This includes the proxy, registrar, Domain Certificate Authority, Management components and any existing entity that is already a member of the domain. domainID: The domain IDentity is a unique value based upon the Registrar CA's certificate. Section 5.8.2 specifies how it is calculated. Domain CA: The domain Certification Authority (CA) provides certification functionalities to the domain. At a minimum it provides certification functionalities to a registrar and manages the private key that defines the domain. Optionally, it certifies all elements. enrollment: The process where a device presents key material to a network and acquires a network-specific identity. For example when a certificate signing request is presented to a certification authority and a certificate is obtained in response. imprint: The process where a device obtains the cryptographic key material to identify and trust future interactions with a network. This term is taken from Konrad Lorenz's work in biology with new ducklings: during a critical period, the duckling would assume that anything that looks like a mother duck is in fact their Pritikin, et al. Expires 15 May 2021 [Page 8] Internet-Draft BRSKI November 2020 mother. An equivalent for a device is to obtain the fingerprint of the network's root certification authority certificate. A device that imprints on an attacker suffers a similar fate to a duckling that imprints on a hungry wolf. Securely imprinting is a primary focus of this document [imprinting]. The analogy to Lorenz's work was first noted in [Stajano99theresurrecting]. IDevID: An Initial Device Identity X.509 certificate installed by the vendor on new equipment. This is a term from 802.1AR [IDevID] IPIP Proxy: A stateless proxy alternative. Join Proxy: A domain entity that helps the pledge join the domain. A join proxy facilitates communication for devices that find themselves in an environment where they are not provided connectivity until after they are validated as members of the domain. For simplicity this document sometimes uses the term of 'proxy' to indicate the join proxy. The pledge is unaware that they are communicating with a proxy rather than directly with a registrar. Join Registrar (and Coordinator): A representative of the domain that is configured, perhaps autonomically, to decide whether a new device is allowed to join the domain. The administrator of the domain interfaces with a "join registrar (and coordinator)" to control this process. Typically a join registrar is "inside" its domain. For simplicity this document often refers to this as just "registrar". Within [I-D.ietf-anima-reference-model] this is referred to as the "join registrar autonomic service agent". Other communities use the abbreviation "JRC". LDevID: A Local Device Identity X.509 certificate installed by the owner of the equipment. This is a term from 802.1AR [IDevID] manufacturer: the term manufacturer is used throughout this document to be the entity that created the device. This is typically the "original equipment manufacturer" or OEM, but in more complex situations it could be a "value added retailer" (VAR), or possibly even a systems integrator. In general, it a goal of BRSKI to eliminate small distinctions between different sales channels. The reason for this is that it permits a single device, with a uniform firmware load, to be shipped directly to all customers. This eliminates costs for the manufacturer. This also reduces the number of products supported in the field increasing the chance that firmware will be more up to date. MASA Audit-Log: An anonymized list of previous owners maintained by Pritikin, et al. Expires 15 May 2021 [Page 9] Internet-Draft BRSKI November 2020 the MASA on a per device (per pledge) basis. Described in Section 5.8.1. MASA Service: A third-party Manufacturer Authorized Signing Authority (MASA) service on the global Internet. The MASA signs vouchers. It also provides a repository for audit-log information of privacy protected bootstrapping events. It does not track ownership. nonced: a voucher (or request) that contains a nonce (the normal case). nonceless: a voucher (or request) that does not contain a nonce, relying upon accurate clocks for expiration, or which does not expire. offline: When an architectural component cannot perform realtime communications with a peer, either due to network connectivity or because the peer is turned off, the operation is said to be occurring offline. Ownership Tracker: An Ownership Tracker service on the global Internet. The Ownership Tracker uses business processes to accurately track ownership of all devices shipped against domains that have purchased them. Although optional, this component allows vendors to provide additional value in cases where their sales and distribution channels allow for accurate tracking of such ownership. Ownership tracking information is indicated in vouchers as described in [RFC8366] Pledge: The prospective (unconfigured) device, which has an identity installed at the factory. (Public) Key Infrastructure: The collection of systems and processes that sustain the activities of a public key system. The registrar acts as an [RFC5280] and [RFC5272] (see section 7) "Registration Authority". TOFU: Trust on First Use. Used similarly to [RFC7435]. This is where a pledge device makes no security decisions but rather simply trusts the first registrar it is contacted by. This is also known as the "resurrecting duckling" model. Voucher: A signed artifact from the MASA that indicates to a pledge the cryptographic identity of the registrar it should trust. There are different types of vouchers depending on how that trust is asserted. Multiple voucher types are defined in [RFC8366] Pritikin, et al. Expires 15 May 2021 [Page 10] Internet-Draft BRSKI November 2020 1.3. Scope of solution 1.3.1. Support environment This solution (BRSKI) can support large router platforms with multi- gigabit inter-connections, mounted in controlled access data centers. But this solution is not exclusive to large equipment: it is intended to scale to thousands of devices located in hostile environments, such as ISP provided CPE devices which are drop-shipped to the end user. The situation where an order is fulfilled from distributed warehouse from a common stock and shipped directly to the target location at the request of a domain owner is explicitly supported. That stock ("SKU") could be provided to a number of potential domain owners, and the eventual domain owner will not know a-priori which device will go to which location. The bootstrapping process can take minutes to complete depending on the network infrastructure and device processing speed. The network communication itself is not optimized for speed; for privacy reasons, the discovery process allows for the pledge to avoid announcing its presence through broadcasting. Nomadic or mobile devices often need to acquire credentials to access the network at the new location. An example of this is mobile phone roaming among network operators, or even between cell towers. This is usually called handoff. BRSKI does not provide a low-latency handoff which is usually a requirement in such situations. For these solutions BRSKI can be used to create a relationship (an LDevID) with the "home" domain owner. The resulting credentials are then used to provide credentials more appropriate for a low-latency handoff. 1.3.2. Constrained environments Questions have been posed as to whether this solution is suitable in general for Internet of Things (IoT) networks. This depends on the capabilities of the devices in question. The terminology of [RFC7228] is best used to describe the boundaries. The solution described in this document is aimed in general at non- constrained (i.e., class 2+ [RFC7228]) devices operating on a non- Challenged network. The entire solution as described here is not intended to be useable as-is by constrained devices operating on challenged networks (such as 802.15.4 Low-power Lossy Networks (LLN)s). Specifically, there are protocol aspects described here that might result in congestion collapse or energy-exhaustion of intermediate battery powered routers in an LLN. Those types of networks should Pritikin, et al. Expires 15 May 2021 [Page 11] Internet-Draft BRSKI November 2020 not use this solution. These limitations are predominately related to the large credential and key sizes required for device authentication. Defining symmetric key techniques that meet the operational requirements is out-of-scope but the underlying protocol operations (TLS handshake and signing structures) have sufficient algorithm agility to support such techniques when defined. The imprint protocol described here could, however, be used by non- energy constrained devices joining a non-constrained network (for instance, smart light bulbs are usually mains powered, and speak 802.11). It could also be used by non-constrained devices across a non-energy constrained, but challenged network (such as 802.15.4). The certificate contents, and the process by which the four questions above are resolved do apply to constrained devices. It is simply the actual on-the-wire imprint protocol that could be inappropriate. 1.3.3. Network Access Controls This document presumes that network access control has either already occurred, is not required, or is integrated by the proxy and registrar in such a way that the device itself does not need to be aware of the details. Although the use of an X.509 Initial Device Identity is consistent with IEEE 802.1AR [IDevID], and allows for alignment with 802.1X network access control methods, its use here is for pledge authentication rather than network access control. Integrating this protocol with network access control, perhaps as an Extensible Authentication Protocol (EAP) method (see [RFC3748]), is out-of-scope. 1.3.4. Bootstrapping is not Booting This document describes "bootstrapping" as the protocol used to obtain a local trust anchor. It is expected that this trust anchor, along with any additional configuration information subsequently installed, is persisted on the device across system restarts ("booting"). Bootstrapping occurs only infrequently such as when a device is transferred to a new owner or has been reset to factory default settings. 1.4. Leveraging the new key infrastructure / next steps As a result of the protocol described herein, the bootstrapped devices have the Domain CA trust anchor in common. An end entity certificate has optionally been issued from the Domain CA. This makes it possible to securely deploy functionalities across the domain, e.g: * Device management. Pritikin, et al. Expires 15 May 2021 [Page 12] Internet-Draft BRSKI November 2020 * Routing authentication. * Service discovery. The major intended benefit is that it possible to use the credentials deployed by this protocol to secure the Autonomic Control Plane (ACP) ([I-D.ietf-anima-autonomic-control-plane]). 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices The BRSKI protocol can be used in a number of environments. Some of the options in this document are the result of requirements that are out of the ANI scope. This section defines the base requirements for ANI devices. For devices that intend to become part of an Autonomic Network Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes an Autonomic Control Plane ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST be implemented. The pledge must perform discovery of the proxy as described in Section 4.1 using Generic Autonomic Signaling Protocol (GRASP)'s DULL [I-D.ietf-anima-grasp] M_FLOOD announcements. Upon successfully validating a voucher artifact, a status telemetry MUST be returned. See Section 5.7. An ANIMA ANI pledge MUST implement the EST automation extensions described in Section 5.9. They supplement the [RFC7030] EST to better support automated devices that do not have an end user. The ANI Join Registrar Autonomic Service Agent (ASA) MUST support all the BRSKI and above listed EST operations. All ANI devices SHOULD support the BRSKI proxy function, using circuit proxies over the ACP. (See Section 4.3) 2. Architectural Overview The logical elements of the bootstrapping framework are described in this section. Figure 1 provides a simplified overview of the components. Pritikin, et al. Expires 15 May 2021 [Page 13] Internet-Draft BRSKI November 2020 +------------------------+ +--------------Drop Ship----------------| Vendor Service | | +------------------------+ | | M anufacturer| | | | A uthorized |Ownership| | | S igning |Tracker | | | A uthority | | | +--------------+---------+ | ^ | | BRSKI- V | MASA +-------+ ............................................|... | | . | . | | . +------------+ +-----------+ | . | | . | | | | | . |Pledge | . | Join | | Domain <-------+ . | | . | Proxy | | Registrar | . | <-------->............<-------> (PKI RA) | . | | | BRSKI-EST | | . | | . | | +-----+-----+ . |IDevID | . +------------+ | e.g. RFC7030 . | | . +-----------------+----------+ . | | . | Key Infrastructure | . | | . | (e.g., PKI Certificate | . +-------+ . | Authority) | . . +----------------------------+ . . . ................................................ "Domain" components Figure 1: Architecture Overview We assume a multi-vendor network. In such an environment there could be a Manufacturer Service for each manufacturer that supports devices following this document's specification, or an integrator could provide a generic service authorized by multiple manufacturers. It is unlikely that an integrator could provide Ownership Tracking services for multiple manufacturers due to the required sales channel integrations necessary to track ownership. The domain is the managed network infrastructure with a Key Infrastructure the pledge is joining. The domain provides initial device connectivity sufficient for bootstrapping through a proxy. The domain registrar authenticates the pledge, makes authorization decisions, and distributes vouchers obtained from the Manufacturer Service. Optionally the registrar also acts as a PKI Certification Authority. Pritikin, et al. Expires 15 May 2021 [Page 14] Internet-Draft BRSKI November 2020 2.1. Behavior of a Pledge The pledge goes through a series of steps, which are outlined here at a high level. ------------ / Factory \ \ default / -----+------ | +------v-------+ | (1) Discover | +------------> | | +------+-------+ | | | +------v-------+ | | (2) Identify | ^------------+ | | rejected +------+-------+ | | | +------v-------+ | | (3) Request | | | Join | | +------+-------+ | | | +------v-------+ | | (4) Imprint | ^------------+ | | Bad MASA +------+-------+ | response | send Voucher Status Telemetry | +------v-------+ | | (5) Enroll |<---+ (non-error HTTP codes ) ^------------+ |\___/ (e.g. 202 'Retry-After') | Enroll +------+-------+ | Failure | | -----v------ | / Enrolled \ ^------------+ | Factory \------------/ reset Figure 2: Pledge State Diagram State descriptions for the pledge are as follows: 1. Discover a communication channel to a registrar. Pritikin, et al. Expires 15 May 2021 [Page 15] Internet-Draft BRSKI November 2020 2. Identify itself. This is done by presenting an X.509 IDevID credential to the discovered registrar (via the proxy) in a TLS handshake. (The registrar credentials are only provisionally accepted at this time). 3. Request to join the discovered registrar. A unique nonce is included ensuring that any responses can be associated with this particular bootstrapping attempt. 4. Imprint on the registrar. This requires verification of the manufacturer-service-provided voucher. A voucher contains sufficient information for the pledge to complete authentication of a registrar. This document details this step in depth. 5. Enroll. After imprint an authenticated TLS (HTTPS) connection exists between pledge and registrar. Enrollment over Secure Transport (EST) [RFC7030] can then be used to obtain a domain certificate from a registrar. The pledge is now a member of, and can be managed by, the domain and will only repeat the discovery aspects of bootstrapping if it is returned to factory default settings. This specification details integration with EST enrollment so that pledges can optionally obtain a locally issued certificate, although any Representational State Transfer (REST) (see [REST]) interface could be integrated in future work. 2.2. Secure Imprinting using Vouchers A voucher is a cryptographically protected artifact (using a digital signature) to the pledge device authorizing a zero-touch imprint on the registrar domain. The format and cryptographic mechanism of vouchers is described in detail in [RFC8366]. Pritikin, et al. Expires 15 May 2021 [Page 16] Internet-Draft BRSKI November 2020 Vouchers provide a flexible mechanism to secure imprinting: the pledge device only imprints when a voucher can be validated. At the lowest security levels the MASA can indiscriminately issue vouchers and log claims of ownership by domains. At the highest security levels issuance of vouchers can be integrated with complex sales channel integrations that are beyond the scope of this document. The sales channel integration would verify actual (legal) ownership of the pledge by the domain. This provides the flexibility for a number of use cases via a single common protocol mechanism on the pledge and registrar devices that are to be widely deployed in the field. The MASA services have the flexibility to leverage either the currently defined claim mechanisms or to experiment with higher or lower security levels. Vouchers provide a signed but non-encrypted communication channel among the pledge, the MASA, and the registrar. The registrar maintains control over the transport and policy decisions, allowing the local security policy of the domain network to be enforced. 2.3. Initial Device Identifier Pledge authentication and pledge voucher-request signing is via a PKIX-shaped certificate installed during the manufacturing process. This is the 802.1AR Initial Device Identifier (IDevID), and it provides a basis for authenticating the pledge during the protocol exchanges described here. There is no requirement for a common root PKI hierarchy. Each device manufacturer can generate its own root certificate. Specifically, the IDevID enables: 1. Uniquely identifying the pledge by the Distinguished Name (DN) and subjectAltName (SAN) parameters in the IDevID. The unique identification of a pledge in the voucher objects are derived from those parameters as described below. Section 10.3 discusses privacy implications of the identifier. 2. Provides a cryptographic authentication of the pledge to the Registrar (see Section 5.3). 3. Secure auto-discovery of the pledge's MASA by the registrar (see Section 2.8). 4. Signing of voucher-request by the pledge's IDevID (see Section 3). 5. Provides a cryptographic authentication of the pledge to the MASA (see Section 5.5.5). Pritikin, et al. Expires 15 May 2021 [Page 17] Internet-Draft BRSKI November 2020 Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of [IDevID] discusses keyUsage and extendedKeyUsage extensions in the IDevID certificate. [IDevID] acknowledges that adding restrictions in the certificate limits applicability of these long-lived certificates. This specification emphasizes this point, and therefore RECOMMENDS that no key usage restrictions be included. This is consistent with [RFC5280] section 4.2.1.3, which does not require key usage restrictions for end entity certificates. 2.3.1. Identification of the Pledge In the context of BRSKI, pledges have a 1:1 relationship with a "serial-number". This serial-number is used both in the "serial- number" field of voucher or voucher-requests (see Section 3) and in local policies on registrar or MASA (see Section 5). There is a (certificate) serialNumber field is defined in [RFC5280] section 4.1.2.2. In the ASN.1, this is referred to as the CertificateSerialNumber. This field is NOT relevant to this specification. Do not confuse this field with the "serial-number" defined by this document, or by [IDevID] and [RFC4519] section 2.31. The device serial number is defined in [RFC5280] section A.1 and A.2 as the X520SerialNumber, with the OID tag id-at-serialNumber. The device serial number field (X520SerialNumber) is used as follows by the pledge to build the "serial-number" that is placed in the voucher-request. In order to build it, the fields need to be converted into a serial-number of "type string". An example of a printable form of the "serialNumber" field is provided in [RFC4519] section 2.31 ("WI-3005"). That section further provides equality and syntax attributes. Due to the reality of existing device identity provisioning processes, some manufacturers have stored serial-numbers in other fields. Registrar's SHOULD be configurable, on a per-manufacturer basis, to look for serial-number equivalents in other fields. As explained in Section 5.5 the Registrar MUST extract the serial- number again itself from the pledge's TLS certificate. It can consult the serial-number in the pledge-request if there are any possible confusion about the source of the serial-number. Pritikin, et al. Expires 15 May 2021 [Page 18] Internet-Draft BRSKI November 2020 2.3.2. MASA URI extension This document defines a new PKIX non-critical certificate extension to carry the MASA URI. This extension is intended to be used in the IDevID certificate. The URI is represented as described in Section 7.4 of [RFC5280]. The URI provides the authority information. The BRSKI "/.well-known" tree ([RFC5785]) is described in Section 5. A complete URI MAY be in this extension, including the 'scheme', 'authority', and 'path', The complete URI will typically be used in diagnostic or experimental situations. Typically, (and in consideration to constrained systems), this SHOULD be reduced to only the 'authority', in which case a scheme of "https://" ([RFC7230] section 2.7.3) and 'path' of "/.well-known/brski" is to be assumed. The registrar can assume that only the 'authority' is present in the extension, if there are no slash ("/") characters in the extension. Section 7.4 of [RFC5280] calls out various schemes that MUST be supported, including LDAP, HTTP and FTP. However, the registrar MUST use HTTPS for the BRSKI-MASA connection. The new extension is identified as follows: Pritikin, et al. Expires 15 May 2021 [Page 19] Internet-Draft BRSKI November 2020 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-MASAURLExtn2016(TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax IDENTIFIED BY id-pe-masa-url } id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } MASAURLSyntax ::= IA5String END Figure 3: MASAURL ASN.1 Module The choice of id-pe is based on guidance found in Section 4.2.2 of [RFC5280], "These extensions may be used to direct applications to on-line information about the issuer or the subject". The MASA URL is precisely that: online information about the particular subject. 2.4. Protocol Flow A representative flow is shown in Figure 4 Pritikin, et al. Expires 15 May 2021 [Page 20] Internet-Draft BRSKI November 2020 +--------+ +---------+ +------------+ +------------+ | Pledge | | Circuit | | Domain | | Vendor | | | | Join | | Registrar | | Service | | | | Proxy | | (JRC) | | (MASA) | +--------+ +---------+ +------------+ +------------+ | | | Internet | [discover] | | | |<-RFC4862 IPv6 addr | | | |<-RFC3927 IPv4 addr | Appendix A | Legend | |-++++++++++++++++++->| | C - circuit | | optional: mDNS query| Appendix B | join proxy | | RFC6763/RFC6762 (+) | | P - provisional | |<-++++++++++++++++++-| | TLS connection | | GRASP M_FLOOD | | | | periodic broadcast| | | [identity] | | | |<------------------->C<----------------->| | | TLS via the Join Proxy | | |<--Registrar TLS server authentication---| | [PROVISIONAL accept of server cert] | | P---X.509 client authentication---------->| | [request join] | | P---Voucher Request(w/nonce for voucher)->| | P /------------------- | | P | [accept device?] | P | [contact Vendor] | P | |--Pledge ID-------->| P | |--Domain ID-------->| P | |--optional:nonce--->| P optional: | [extract DomainID] P can occur in advance | [update audit log] P if nonceleess | | P | |<- voucher ---------| P \------------------- | w/nonce if provided| P<------voucher---------------------------| | [imprint] | | |-------voucher status telemetry--------->| | | |<-device audit log--| | [verify audit log and voucher] | |<--------------------------------------->| | [enroll] | | | Continue with RFC7030 enrollment | | | using now bidirectionally authenticated | | | TLS session. | | [enrolled] | | Figure 4: Protocol Time Sequence Diagram Pritikin, et al. Expires 15 May 2021 [Page 21] Internet-Draft BRSKI November 2020 On initial bootstrap, a new device (the pledge) uses a local service autodiscovery (GRASP or mDNS) to locate a join proxy. The join proxy connects the pledge to a local registrar (the JRC). Having found a candidate registrar, the fledgling pledge sends some information about itself to the registrar, including its serial number in the form of a voucher request and its device identity certificate (IDevID) as part of the TLS session. The registrar can determine whether it expected such a device to appear, and locates a MASA. The location of the MASA is usually found in an extension in the IDevID. Having determined that the MASA is suitable, the entire information from the initial voucher request (including device serial number) is transmitted over the internet in a TLS protected channel to the manufacturer, along with information about the registrar/owner. The manufacturer can then apply policy based on the provided information, as well as other sources of information (such as sales records), to decide whether to approve the claim by the registrar to own the device; if the claim is accepted, a voucher is issued that directs the device to accept its new owner. The voucher is returned to the registrar, but not immediately to the device -- the registrar has an opportunity to examine the voucher, the MASA's audit-logs, and other sources of information to determine whether the device has been tampered with, and whether the bootstrap should be accepted. No filtering of information is possible in the signed voucher, so this is a binary yes-or-no decision. If the registrar accepts the voucher as a proper one for its device, the voucher is returned to the pledge for imprinting. The voucher also includes a trust anchor that the pledge uses as representing the owner. This is used to successfully bootstrap from an environment where only the manufacturer has built-in trust by the device into an environment where the owner now has a PKI footprint on the device. When BRSKI is followed with EST this single footprint is further leveraged into the full owner's PKI and a LDevID for the device. Subsequent reporting steps provide flows of information to indicate success/failure of the process. Pritikin, et al. Expires 15 May 2021 [Page 22] Internet-Draft BRSKI November 2020 2.5. Architectural Components 2.5.1. Pledge The pledge is the device that is attempting to join. The pledge is assumed to talk to the Join Proxy using link-local network connectivity. In most cases, the pledge has no other connectivity until the pledge completes the enrollment process and receives some kind of network credential. 2.5.2. Join Proxy The join proxy provides HTTPS connectivity between the pledge and the registrar. A circuit proxy mechanism is described in Section 4. Additional mechanisms, including a CoAP mechanism and a stateless IPIP mechanism are the subject of future work. 2.5.3. Domain Registrar The domain's registrar operates as the BRSKI-MASA client when requesting vouchers from the MASA (see Section 5.4). The registrar operates as the BRSKI-EST server when pledges request vouchers (see Section 5.1). The registrar operates as the BRSKI-EST server "Registration Authority" if the pledge requests an end entity certificate over the BRSKI-EST connection (see Section 5.9). The registrar uses an Implicit Trust Anchor database for authenticating the BRSKI-MASA connection's MASA TLS Server Certificate. Configuration or distribution of trust anchors is out- of-scope for this specification. The registrar uses a different Implicit Trust Anchor database for authenticating the BRSKI-EST connection's Pledge TLS Client Certificate. Configuration or distribution of the BRSKI-EST client trust anchors is out-of-scope of this specification. Note that the trust anchors in/excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. 2.5.4. Manufacturer Service The Manufacturer Service provides two logically separate functions: the Manufacturer Authorized Signing Authority (MASA) described in Section 5.5 and Section 5.6, and an ownership tracking/auditing function described in Section 5.7 and Section 5.8. Pritikin, et al. Expires 15 May 2021 [Page 23] Internet-Draft BRSKI November 2020 2.5.5. Public Key Infrastructure (PKI) The Public Key Infrastructure (PKI) administers certificates for the domain of concern, providing the trust anchor(s) for it and allowing enrollment of pledges with domain certificates. The voucher provides a method for the distribution of a single PKI trust anchor (as the "pinned-domain-cert"). A distribution of the full set of current trust anchors is possible using the optional EST integration. The domain's registrar acts as an [RFC5272] Registration Authority, requesting certificates for pledges from the Key Infrastructure. The expectations of the PKI are unchanged from EST [RFC7030]. This document does not place any additional architectural requirements on the Public Key Infrastructure. 2.6. Certificate Time Validation 2.6.1. Lack of realtime clock Many devices when bootstrapping do not have knowledge of the current time. Mechanisms such as Network Time Protocols cannot be secured until bootstrapping is complete. Therefore bootstrapping is defined with a framework that does not require knowledge of the current time. A pledge MAY ignore all time stamps in the voucher and in the certificate validity periods if it does not know the current time. The pledge is exposed to dates in the following five places: registrar certificate notBefore, registrar certificate notAfter, voucher created-on, and voucher expires-on. Additionally, CMS signatures contain a signingTime. A pledge with a real time clock in which it has confidence, MUST check the above time fields in all certificates and signatures that it processes. If the voucher contains a nonce then the pledge MUST confirm the nonce matches the original pledge voucher-request. This ensures the voucher is fresh. See Section 5.2. 2.6.2. Infinite Lifetime of IDevID [RFC5280] explains that long lived pledge certificates "SHOULD be assigned the GeneralizedTime value of 99991231235959Z" for the notAfter field. Pritikin, et al. Expires 15 May 2021 [Page 24] Internet-Draft BRSKI November 2020 Some deployed IDevID management systems are not compliant with the 802.1AR requirement for infinite lifetimes, and put in typical <= 3 year certificate lifetimes. Registrars SHOULD be configurable on a per-manufacturer basis to ignore pledge lifetimes when the pledge did not follow the RFC5280 recommendations. 2.7. Cloud Registrar There exist operationally open networks wherein devices gain unauthenticated access to the Internet at large. In these use cases the management domain for the device needs to be discovered within the larger Internet. The case where a device can boot and get access to larger Internet are less likely within the ANIMA ACP scope but may be more important in the future. In the ANIMA ACP scope, new devices will be quarantined behind a Join Proxy. There are additionally some greenfield situations involving an entirely new installation where a device may have some kind of management uplink that it can use (such as via 3G network for instance). In such a future situation, the device might use this management interface to learn that it should configure itself to become the local registrar. In order to support these scenarios, the pledge MAY contact a well known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar. If the pledge uses a well known URI for contacting a cloud registrar a manufacturer-assigned Implicit Trust Anchor database (see [RFC7030]) MUST be used to authenticate that service as described in [RFC6125]. The use of a DNS-ID for validation is appropriate, and it may include wildcard components on the left-mode side. This is consistent with the human user configuration of an EST server URI in [RFC7030] which also depends on RFC6125. 2.8. Determining the MASA to contact The registrar needs to be able to contact a MASA that is trusted by the pledge in order to obtain vouchers. There are three mechanisms described: The device's Initial Device Identifier (IDevID) will normally contain the MASA URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. Pritikin, et al. Expires 15 May 2021 [Page 25] Internet-Draft BRSKI November 2020 It can be operationally difficult to ensure the necessary X.509 extensions are in the pledge's IDevID due to the difficulty of aligning current pledge manufacturing with software releases and development. As a final fallback the registrar MAY be manually configured or distributed with a MASA URL for each manufacturer. Note that the registrar can only select the configured MASA URL based on the trust anchor -- so manufacturers can only leverage this approach if they ensure a single MASA URL works for all pledges associated with each trust anchor. 3. Voucher-Request artifact Voucher-requests are how vouchers are requested. The semantics of the voucher-request are described below, in the YANG model. A pledge forms the "pledge voucher-request", signs it with it's IDevID and submits it to the registrar. The registrar in turn forms the "registrar voucher-request", signs it with it's Registrar keypair and submits it to the MASA. The "proximity-registrar-cert" leaf is used in the pledge voucher- requests. This provides a method for the pledge to assert the registrar's proximity. This network proximity results from the following properties in the ACP context: the pledge is connected to the Join Proxy (Section 4) using a Link-Local IPv6 connection. While the Join Proxy does not participate in any meaningful sense in the cryptography of the TLS connection (such as via a Channel Binding), the Registrar can observe that the connection is via the private ACP (ULA) address of the join proxy, and could not come from outside the ACP. The Pledge must therefore be at most one IPv6 Link-Local hop away from an existing node on the ACP. Other users of BRSKI will need to define other kinds of assertions if the network proximity described above does not match their needs. The "prior-signed-voucher-request" leaf is used in registrar voucher- requests. If present, it is the signed pledge voucher-request artifact. This provides a method for the registrar to forward the pledge's signed request to the MASA. This completes transmission of the signed "proximity-registrar-cert" leaf. Unless otherwise signaled (outside the voucher-request artifact), the signing structure is as defined for vouchers, see [RFC8366]. Pritikin, et al. Expires 15 May 2021 [Page 26] Internet-Draft BRSKI November 2020 3.1. Nonceless Voucher Requests A registrar MAY also retrieve nonceless vouchers by sending nonceless voucher-requests to the MASA in order to obtain vouchers for use when the registrar does not have connectivity to the MASA. No "prior- signed-voucher-request" leaf would be included. The registrar will also need to know the serial number of the pledge. This document does not provide a mechanism for the registrar to learn that in an automated fashion. Typically this will be done via scanning of bar- code or QR-code on packaging, or via some sales channel integration. 3.2. Tree Diagram The following tree diagram illustrates a high-level view of a voucher-request document. The voucher-request builds upon the voucher artifact described in [RFC8366]. The tree diagram is described in [RFC8340]. Each node in the diagram is fully described by the YANG module in Section 3.4. Please review the YANG module for a detailed description of the voucher-request format. module: ietf-voucher-request grouping voucher-request-grouping +-- voucher +-- created-on? yang:date-and-time +-- expires-on? yang:date-and-time +-- assertion? enumeration +-- serial-number string +-- idevid-issuer? binary +-- pinned-domain-cert? binary +-- domain-cert-revocation-checks? boolean +-- nonce? binary +-- last-renewal-date? yang:date-and-time +-- prior-signed-voucher-request? binary +-- proximity-registrar-cert? binary Figure 5: YANG Tree diagram for Voucher-Request 3.3. Examples This section provides voucher-request examples for illustration purposes. These examples show the JSON prior to CMS wrapping. JSON encoding rules specify that any binary content be base64 encoded ([RFC4648] section 4). The contents of the (base64) encoded certificates have been elided to save space. For detailed examples, see Appendix C.2. These examples conform to the encoding rules defined in [RFC7951]. Pritikin, et al. Expires 15 May 2021 [Page 27] Internet-Draft BRSKI November 2020 Example (1) The following example illustrates a pledge voucher- request. The assertion leaf is indicated as 'proximity' and the registrar's TLS server certificate is included in the 'proximity-registrar-cert' leaf. See Section 5.2. { "ietf-voucher-request:voucher": { "assertion": "proximity", "nonce": "62a2e7693d82fcda2624de58fb6722e5", "serial-number" : "JADA123456789", "created-on": "2017-01-01T00:00:00.000Z", "proximity-registrar-cert": "base64encodedvalue==" } } Figure 6: JSON representation of example Voucher-Request Example (2) The following example illustrates a registrar voucher- request. The 'prior-signed-voucher-request' leaf is populated with the pledge's voucher-request (such as the prior example). The pledge's voucher-request is a binary CMS signed object. In the JSON encoding used here it must be base64 encoded. The nonce and assertion have been carried forward from the pledge request to the registrar request. The serial-number is extracted from the pledge's Client Certificate from the TLS connection. See Section 5.5. { "ietf-voucher-request:voucher": { "assertion" : "proximity", "nonce": "62a2e7693d82fcda2624de58fb6722e5", "created-on": "2017-01-01T00:00:02.000Z", "idevid-issuer": "base64encodedvalue==", "serial-number": "JADA123456789", "prior-signed-voucher-request": "base64encodedvalue==" } } Figure 7: JSON representation of example Prior-Signed Voucher-Request Example (3) The following example illustrates a registrar voucher- request. The 'prior-signed-voucher-request' leaf is not populated with the pledge's voucher-request nor is the nonce leaf. This form might be used by a registrar requesting a voucher when the pledge can not communicate with the registrar (such as when it is powered down, or Pritikin, et al. Expires 15 May 2021 [Page 28] Internet-Draft BRSKI November 2020 still in packaging), and therefore could not submit a nonce. This scenario is most useful when the registrar is aware that it will not be able to reach the MASA during deployment. See Section 5.5. { "ietf-voucher-request:voucher": { "created-on": "2017-01-01T00:00:02.000Z", "idevid-issuer": "base64encodedvalue==", "serial-number": "JADA123456789" } } Figure 8: JSON representation of Offline Voucher-Request 3.4. YANG Module Following is a YANG [RFC7950] module formally extending the [RFC8366] voucher into a voucher-request. file "ietf-voucher-request@2018-02-14.yang" module ietf-voucher-request { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; prefix "vcr"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix vch; description "This module defines the format for a voucher, which is produced by a pledge's manufacturer or delegate (MASA) to securely assign a pledge to an 'owner', so that the pledge may establish a secure connection to the owner's network infrastructure"; reference "RFC 8366: Voucher Artifact for Bootstrapping Protocols"; } organization Pritikin, et al. Expires 15 May 2021 [Page 29] Internet-Draft BRSKI November 2020 "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Kent Watsen Author: Michael H. Behringer Author: Toerless Eckert Author: Max Pritikin Author: Michael Richardson "; description "This module defines the format for a voucher request. It is a superset of the voucher itself. It provides content to the MASA for consideration during a voucher request. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision "2018-02-14" { description "Initial version"; reference "RFC XXXX: Bootstrapping Remote Secure Key Infrastructure"; } Pritikin, et al. Expires 15 May 2021 [Page 30] Internet-Draft BRSKI November 2020 // Top-level statement rc:yang-data voucher-request-artifact { uses voucher-request-grouping; } // Grouping defined for future usage grouping voucher-request-grouping { description "Grouping to allow reuse/extensions in future work."; uses vch:voucher-artifact-grouping { refine "voucher/created-on" { mandatory false; } refine "voucher/pinned-domain-cert" { mandatory false; description "A pinned-domain-cert field is not valid in a voucher request, and any occurrence MUST be ignored"; } refine "voucher/last-renewal-date" { description "A last-renewal-date field is not valid in a voucher request, and any occurrence MUST be ignored"; } refine "voucher/domain-cert-revocation-checks" { description "The domain-cert-revocation-checks field is not valid in a voucher request, and any occurrence MUST be ignored"; } refine "voucher/assertion" { mandatory false; description "Any assertion included in registrar voucher requests SHOULD be ignored by the MASA."; } augment "voucher" { description "Adds leaf nodes appropriate for requesting vouchers."; leaf prior-signed-voucher-request { type binary; description "If it is necessary to change a voucher, or re-sign and Pritikin, et al. Expires 15 May 2021 [Page 31] Internet-Draft BRSKI November 2020 forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field. For example, a pledge might sign a voucher request with a proximity-registrar-cert, and the registrar then includes it as the prior-signed-voucher-request field. This is a simple mechanism for a chain of trusted parties to change a voucher request, while maintaining the prior signature information. The Registrar and MASA MAY examine the prior signed voucher information for the purposes of policy decisions. For example this information could be useful to a MASA to determine that both pledge and registrar agree on proximity assertions. The MASA SHOULD remove all prior-signed-voucher-request information when signing a voucher for imprinting so as to minimize the final voucher size."; } leaf proximity-registrar-cert { type binary; description "An X.509 v3 certificate structure as specified by RFC 5280, Section 4 encoded using the ASN.1 distinguished encoding rules (DER), as specified in [ITU.X690.1994]. The first certificate in the Registrar TLS server certificate_list sequence (the end-entity TLS certificate, see [RFC8446]) presented by the Registrar to the Pledge. This MUST be populated in a Pledge's voucher request when a proximity assertion is requested."; } } } } } Figure 9: YANG module for Voucher-Request Pritikin, et al. Expires 15 May 2021 [Page 32] Internet-Draft BRSKI November 2020 4. Proxying details (Pledge - Proxy - Registrar) This section is normative for uses with an ANIMA ACP. The use of the GRASP mechanism is part of the ACP. Other users of BRSKI will need to define an equivalent proxy mechanism, and an equivalent mechanism to configure the proxy. The role of the proxy is to facilitate communications. The proxy forwards packets between the pledge and a registrar that has been provisioned to the proxy via full GRASP ACP discovery. This section defines a stateful proxy mechanism which is referred to as a "circuit" proxy. This is a form of Application Level Gateway ([RFC2663] section 2.9). The proxy does not terminate the TLS handshake: it passes streams of bytes onward without examination. A proxy MUST NOT assume any specific TLS version. Please see [RFC8446] section 9.3 for details on TLS invariants. A Registrar can directly provide the proxy announcements described below, in which case the announced port can point directly to the Registrar itself. In this scenario the pledge is unaware that there is no proxying occurring. This is useful for Registrars which are servicing pledges on directly connected networks. As a result of the proxy Discovery process in Section 4.1.1, the port number exposed by the proxy does not need to be well known, or require an IANA allocation. During the discovery of the Registrar by the Join Proxy, the Join Proxy will also learn which kinds of proxy mechanisms are available. This will allow the Join Proxy to use the lowest impact mechanism which the Join Proxy and Registrar have in common. In order to permit the proxy functionality to be implemented on the maximum variety of devices the chosen mechanism should use the minimum amount of state on the proxy device. While many devices in the ANIMA target space will be rather large routers, the proxy function is likely to be implemented in the control plane CPU of such a device, with available capabilities for the proxy function similar to many class 2 IoT devices. The document [I-D.richardson-anima-state-for-joinrouter] provides a more extensive analysis and background of the alternative proxy methods. Pritikin, et al. Expires 15 May 2021 [Page 33] Internet-Draft BRSKI November 2020 4.1. Pledge discovery of Proxy The result of discovery is a logical communication with a registrar, through a proxy. The proxy is transparent to the pledge. The communication between the pledge and Join Proxy is over IPv6 Link- Local addresses. To discover the proxy the pledge performs the following actions: 1. MUST: Obtains a local address using IPv6 methods as described in [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of [RFC4941] temporary addresses is encouraged. To limit pervasive monitoring ( [RFC7258]), a new temporary address MAY use a short lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). Pledges will generally prefer use of IPv6 Link-Local addresses, and discovery of proxy will be by Link-Local mechanisms. IPv4 methods are described in Appendix A 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) announcements of the objective: "AN_Proxy". See section Section 4.1.1 for the details of the objective. The pledge MAY listen concurrently for other sources of information, see Appendix B. Once a proxy is discovered the pledge communicates with a registrar through the proxy using the bootstrapping protocol defined in Section 5. While the GRASP M_FLOOD mechanism is passive for the pledge, the non- normative other methods (mDNS, and IPv4 methods) described in Appendix B are active. The pledge SHOULD run those methods in parallel with listening to for the M_FLOOD. The active methods SHOULD back-off by doubling to a maximum of one hour to avoid overloading the network with discovery attempts. Detection of change of physical link status (Ethernet carrier for instance) SHOULD reset the back off timers. The pledge could discover more than one proxy on a given physical interface. The pledge can have a multitude of physical interfaces as well: a layer-2/3 Ethernet switch may have hundreds of physical ports. Each possible proxy offer SHOULD be attempted up to the point where a valid voucher is received: while there are many ways in which the attempt may fail, it does not succeed until the voucher has been validated. Pritikin, et al. Expires 15 May 2021 [Page 34] Internet-Draft BRSKI November 2020 The connection attempts via a single proxy SHOULD exponentially back- off to a maximum of one hour to avoid overloading the network infrastructure. The back-off timer for each MUST be independent of other connection attempts. Connection attempts SHOULD be run in parallel to avoid head of queue problems wherein an attacker running a fake proxy or registrar could perform protocol actions intentionally slowly. Connection attempts to different proxies SHOULD be sent with an interval of 3 to 5s. The pledge SHOULD continue to listen to for additional GRASP M_FLOOD messages during the connection attempts. Each connection attempt through a distinct Join Proxy MUST have a unique nonce in the voucher-request. Once a connection to a registrar is established (e.g. establishment of a TLS session key) there are expectations of more timely responses, see Section 5.2. Once all discovered services are attempted (assuming that none succeeded) the device MUST return to listening for GRASP M_FLOOD. It SHOULD periodically retry any manufacturer-specific mechanisms. The pledge MAY prioritize selection order as appropriate for the anticipated environment. 4.1.1. Proxy GRASP announcements A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. This announcement can be within the same message as the ACP announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. The formal Concise Data Definition Language (CDDL) [RFC8610] definition is: Pritikin, et al. Expires 15 May 2021 [Page 35] Internet-Draft BRSKI November 2020 file "proxygrasp.cddl" flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["AN_Proxy", objective-flags, loop-count, objective-value] ttl = 180000 ; 180,000 ms (3 minutes) initiator = ACP address to contact Registrar objective-flags = sync-only ; as in GRASP spec sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 1 ; one hop only objective-value = any ; none locator-option = [ O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number ] ipv6-address = the v6 LL of the Proxy $transport-proto /= IPPROTO_TCP ; note this can be any value from the ; IANA protocol registry, as per ; [GRASP] section 2.9.5.1, note 3. port-number = selected by Proxy Figure 10: CDDL definition of Proxy Discovery message Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port 4443. [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, [["AN_Proxy", 4, 1, ""], [O_IPv6_LOCATOR, h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]]] Figure 11: Example of Proxy Discovery message On a small network the Registrar MAY include the GRASP M_FLOOD announcements to locally connected networks. The $transport-proto above indicates the method that the pledge- proxy-registrar will use. The TCP method described here is mandatory, and other proxy methods, such as CoAP methods not defined in this document are optional. Other methods MUST NOT be enabled unless the Join Registrar ASA indicates support for them in it's own announcement. Pritikin, et al. Expires 15 May 2021 [Page 36] Internet-Draft BRSKI November 2020 4.2. CoAP connection to Registrar The use of CoAP to connect from pledge to registrar is out of scope for this document, and is described in future work. See [I-D.ietf-anima-constrained-voucher]. 4.3. Proxy discovery and communication of Registrar The registrar SHOULD announce itself so that proxies can find it and determine what kind of connections can be terminated. The registrar announces itself using ACP instance of GRASP using M_FLOOD messages, with the "AN_join_registrar" objective. A registrar may announce any convenient port number, including using a stock port 443. ANI proxies MUST support GRASP discovery of registrars. The M_FLOOD is formatted as follows: [M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000, [["AN_join_registrar", 4, 255, "EST-TLS"], [O_IPv6_LOCATOR, h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]]] Figure 12: An example of a Registrar announcement message The formal CDDL definition is: file "jrcgrasp.cddl" flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] objective = ["AN_join_registrar", objective-flags, loop-count, objective-value] initiator = ACP address to contact Registrar objective-flags = sync-only ; as in GRASP spec sync-only = 4 ; M_FLOOD only requires synchronization loop-count = 255 ; mandatory maximum objective-value = text ; name of the (list of) of supported ; protocols: "EST-TLS" for RFC7030. Figure 13: CDDL definition for Registrar announcement message Pritikin, et al. Expires 15 May 2021 [Page 37] Internet-Draft BRSKI November 2020 The M_FLOOD message MUST be sent periodically. The default period SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD NOT be smaller than 60 seconds. The frequency of sending MUST be such that the aggregate amount of periodic M_FLOODs from all flooding sources cause only negligible traffic across the ACP. Here are some examples of locators for illustrative purposes. Only the first one ($transport-protocol = 6, TCP) is defined in this document and is mandatory to implement. locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] A protocol of 6 indicates that TCP proxying on the indicated port is desired. Registrars MUST announce the set of protocols that they support. They MUST support TCP traffic. Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. Registrars MUST support ANI TLS circuit proxy and therefore BRSKI across HTTPS/TLS native across the ACP. In the ANI, the Autonomic Control Plane (ACP) secured instance of GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI registrar ACP addresses and ports by ANI proxies. The TCP leg of the proxy connection between ANI proxy and ANI registrar therefore also runs across the ACP. 5. Protocol Details (Pledge - Registrar - MASA) The pledge MUST initiate BRSKI after boot if it is unconfigured. The pledge MUST NOT automatically initiate BRSKI if it has been configured or is in the process of being configured. BRSKI is described as extensions to EST [RFC7030]. The goal of these extensions is to reduce the number of TLS connections and crypto operations required on the pledge. The registrar implements the BRSKI REST interface within the "/.well-known/brski" URI tree, as well as implementing the existing EST URIs as described in EST [RFC7030] section 3.2.2. The communication channel between the pledge and the registrar is referred to as "BRSKI-EST" (see Figure 1). Pritikin, et al. Expires 15 May 2021 [Page 38] Internet-Draft BRSKI November 2020 The communication channel between the registrar and MASA is a new communication channel, similar to EST, within the newly registred "/.well-known/brski" tree. For clarity this channel is referred to as "BRSKI-MASA". (See Figure 1). The MASA URI is "https://" authority "/.well-known/brski". BRSKI uses existing CMS message formats for existing EST operations. BRSKI uses JSON [RFC8259] for all new operations defined here, and voucher formats. In all places where a binary value must be carried in a JSON string, the use of base64 format ([RFC4648] section 4) is to be used, as per [RFC7951] section 6.6. While EST section 3.2 does not insist upon use of HTTP persistent connections ([RFC7230] section 6.3), BRSKI-EST connections SHOULD use persistent connections. The intention of this guidance is to ensure the provisional TLS state occurs only once, and that the subsequent resolution of the provision state is not subject to a MITM attack during a critical phase. If non-persistent connections are used, then both the pledge and the registrar MUST remember the certificates seen, and also sent for the first connection. They MUST check each subsequent connections for the same certificates, and each end MUST use the same certificates as well. This places a difficult restriction on rolling certificates on the Registrar. Summarized automation extensions for the BRSKI-EST flow are: * The pledge either attempts concurrent connections via each discovered proxy, or it times out quickly and tries connections in series, as explained at the end of Section 5.1. * The pledge provisionally accepts the registrar certificate during the TLS handshake as detailed in Section 5.1. * The pledge requests a voucher using the new REST calls described below. This voucher is then validated. * The pledge completes authentication of the server certificate as detailed in Section 5.6.1. This moves the BRSKI-EST TLS connection out of the provisional state. * Mandatory bootstrap steps conclude with voucher status telemetry (see Section 5.7). The BRSKI-EST TLS connection can now be used for EST enrollment. Pritikin, et al. Expires 15 May 2021 [Page 39] Internet-Draft BRSKI November 2020 The extensions for a registrar (equivalent to EST server) are: * Client authentication is automated using Initial Device Identity (IDevID) as per the EST certificate based client authentication. The subject field's DN encoding MUST include the "serialNumber" attribute with the device's unique serial number as explained in Section 2.3.1 * The registrar requests and validates the voucher from the MASA. * The registrar forwards the voucher to the pledge when requested. * The registrar performs log verifications (described in Section 5.8.3) in addition to local authorization checks before accepting optional pledge device enrollment requests. 5.1. BRSKI-EST TLS establishment details The pledge establishes the TLS connection with the registrar through the circuit proxy (see Section 4) but the TLS handshake is with the registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST registrar is the TLS server. All security associations established are between the pledge and the registrar regardless of proxy operations. Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the Pledge side. TLS 1.3 (or newer) SHOULD be available on the Registrar server interface, and the Registrar client interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS 1.2 MAY be used. Establishment of the BRSKI-EST TLS connection is as specified in EST [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" [RFC7030] wherein the client is authenticated with the IDevID certificate, and the EST server (the registrar) is provisionally authenticated with an unverified server certificate. Configuration or distribution of the trust anchor database used for validating the IDevID certificate is out-of-scope of this specification. Note that the trust anchors in/excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment. The signature in the certificate MUST be validated even if a signing key can not (yet) be validated. The certificate (or chain) MUST be retained for later validation. Pritikin, et al. Expires 15 May 2021 [Page 40] Internet-Draft BRSKI November 2020 A self-signed certificate for the Registrar is acceptable as the voucher can validate it upon successful enrollment. The pledge performs input validation of all data received until a voucher is verified as specified in Section 5.6.1 and the TLS connection leaves the provisional state. Until these operations are complete the pledge could be communicating with an attacker. The pledge code needs to be written with the assumption that all data is being transmitted at this point to an unauthenticated peer, and that received data, while inside a TLS connection, MUST be considered untrusted. This particularly applies to HTTP headers and CMS structures that make up the voucher. A pledge that can connect to multiple Registrars concurrently SHOULD do so. Some devices may be unable to do so for lack of threading, or resource issues. Concurrent connections defeat attempts by a malicious proxy from causing a TCP Slowloris-like attack (see [slowloris]). A pledge that can not maintain as many connections as there are eligible proxies will need to rotate among the various choices, terminating connections that do not appear to be making progress. If no connection is making progress after 5 seconds then the pledge SHOULD drop the oldest connection and go on to a different proxy: the proxy that has been communicated with least recently. If there were no other proxies discovered, the pledge MAY continue to wait, as long as it is concurrently listening for new proxy announcements. 5.2. Pledge Requests Voucher from the Registrar When the pledge bootstraps it makes a request for a voucher from a registrar. This is done with an HTTPS POST using the operation path value of "/.well-known/brski/requestvoucher". The pledge voucher-request Content-Type is: application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON document that has been signed using a CMS structure", and the voucher-request described in Section 3 is created in the same way. The media type is the same as defined in [RFC8366]. This is also used for the pledge voucher-request. The pledge MUST sign the request using the Section 2.3 credential. Registrar implementations SHOULD anticipate future media types but of course will simply fail the request if those types are not yet known. Pritikin, et al. Expires 15 May 2021 [Page 41] Internet-Draft BRSKI November 2020 The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header field indicating the acceptable media type for the voucher response. The "application/voucher-cms+json" media type is defined in [RFC8366] but constrained voucher formats are expected in the future. Registrars and MASA are expected to be flexible in what they accept. The pledge populates the voucher-request fields as follows: created-on: Pledges that have a realtime clock are RECOMMENDED to populate this field with the current date and time in yang:date- and-time format. This provides additional information to the MASA. Pledges that have no real-time clocks MAY omit this field. nonce: The pledge voucher-request MUST contain a cryptographically strong random or pseudo-random number nonce (see [RFC4086] section 6.2). As the nonce is usually generated very early in the boot sequence there is a concern that the same nonce might generated across multiple boots, or after a factory reset. Different nonces MUST be generated for each bootstrapping attempt, whether in series or concurrently. The freshness of this nonce mitigates against the lack of real-time clock as explained in Section 2.6.1. assertion: The pledge indicates support for the mechanism described in this document, by putting the value "proximity" in the voucher- request, MUST include the "proximity-registrar-cert" field (below). proximity-registrar-cert: In a pledge voucher-request this is the first certificate in the TLS server 'certificate_list' sequence (see [RFC5246]) presented by the registrar to the pledge. That is, it is the end-entity certificate. This MUST be populated in a pledge voucher-request. serial-number The serial number of the pledge is included in the voucher-request from the Pledge. This value is included as a sanity check only, but it is not to be forwarded by the Registrar as described in Section 5.5. All other fields MAY be omitted in the pledge voucher-request. An example JSON payload of a pledge voucher-request is in Section 3.3 Example 1. The registrar confirms that the assertion is 'proximity' and that pinned 'proximity-registrar-cert' is the Registrar's certificate. If this validation fails, then there is an On-Path Attacker (MITM), and the connection MUST be closed after the returning an HTTP 401 error code. Pritikin, et al. Expires 15 May 2021 [Page 42] Internet-Draft BRSKI November 2020 5.3. Registrar Authorization of Pledge In a fully automated network all devices must be securely identified and authorized to join the domain. A Registrar accepts or declines a request to join the domain, based on the authenticated identity presented. For different networks, examples of automated acceptance may include: * allow any device of a specific type (as determined by the X.509 IDevID), * allow any device from a specific vendor (as determined by the X.509 IDevID), * allow a specific device from a vendor (as determined by the X.509 IDevID) against a domain white list. (The mechanism for checking a shared white list potentially used by multiple Registrars is out of scope). If validation fails the registrar SHOULD respond with the HTTP 404 error code. If the voucher-request is in an unknown format, then an HTTP 406 error code is more appropriate. A situation that could be resolved with administrative action (such as adding a vendor to a whitelist) MAY be responded with an 403 HTTP error code. If authorization is successful the registrar obtains a voucher from the MASA service (see Section 5.5) and returns that MASA signed voucher to the pledge as described in Section 5.6. 5.4. BRSKI-MASA TLS establishment details The BRSKI-MASA TLS connection is a 'normal' TLS connection appropriate for HTTPS REST interfaces. The registrar initiates the connection and uses the MASA URL obtained as described in Section 2.8. The mechanisms in [RFC6125] SHOULD be used in authentication of the MASA using a DNS-ID that matches that which is found in the IDevID. Registrars MAY include a mechanism to override the MASA URL on a manufacturer-by-manufacturer basis, and within that override it is appropriate to provide alternate anchors. This will typically used by some vendors to establish explicit (or private) trust anchors for validating their MASA that is part of a sales channel integration. Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. TLS 1.3 (or newer) SHOULD be available. Pritikin, et al. Expires 15 May 2021 [Page 43] Internet-Draft BRSKI November 2020 As described in [RFC7030], the MASA and the registrars SHOULD be prepared to support TLS client certificate authentication and/or HTTP Basic, Digest, or SCRAM authentication. This connection MAY also have no client authentication at all. Registrars SHOULD permit trust anchors to be pre-configured on a per- vendor(MASA) basis. Registrars SHOULD include the ability to configure a TLS ClientCertificate on a per-MASA basis, or to use no client certificate. Registrars SHOULD also permit HTTP Basic and Digest authentication to be configured. The authentication of the BRSKI-MASA connection does not change the voucher-request process, as voucher-requests are already signed by the registrar. Instead, this authentication provides access control to the audit-log as described in Section 5.8. Implementors are advised that contacting the MASA is to establish a secured API connection with a web service and that there are a number of authentication models being explored within the industry. Registrars are RECOMMENDED to fail gracefully and generate useful administrative notifications or logs in the advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. 5.4.1. MASA authentication of customer Registrar Providing per-customer options requires that the customer's registrar be uniquely identified. This can be done by any stateless method that HTTPS supports such as with HTTP Basic or Digest authentication (that is using a password), but the use of TLS Client Certificate authentication is RECOMMENDED. Stateful methods involving API tokens, or HTTP Cookies, are not recommended. It is expected that the setup and configuration of per-customer Client Certificates is done as part of a sales ordering process. The use of public PKI (i.e. WebPKI) End-Entity Certificates to identify the Registrar is reasonable, and if done universally this would permit a MASA to identify a customers' Registrar simply by a FQDN. The use of DANE records in DNSSEC signed zones would also permit use of a FQDN to identify customer Registrars. A third (and simplest, but least flexible) mechanism would be for the MASA to simply store the Registrar's certificate pinned in a database. Pritikin, et al. Expires 15 May 2021 [Page 44] Internet-Draft BRSKI November 2020 A MASA without any supply chain integration can simply accept Registrars without any authentication, or can accept them on a blind Trust-on-First-Use basis as described in Section 7.4.2. This document does not make a specific recommendation on how the MASA authenticates the Registrar as there are likely different tradeoffs in different environments and product values. Even within the ANIMA ACP applicability, there is a significant difference between supply chain logistics for $100 CPE devices and $100,000 core routers. 5.5. Registrar Requests Voucher from MASA When a registrar receives a pledge voucher-request it in turn submits a registrar voucher-request to the MASA service via an HTTPS interface ([RFC7231]). This is done with an HTTP POST using the operation path value of "/.well-known/brski/requestvoucher". The voucher media type "application/voucher-cms+json" is defined in [RFC8366] and is also used for the registrar voucher-request. It is a JSON document that has been signed using a CMS structure. The registrar MUST sign the registrar voucher-request. MASA implementations SHOULD anticipate future media ntypes but of course will simply fail the request if those types are not yet known. The voucher-request CMS object includes some number of certificates that are input to the MASA as it populates the 'pinned-domain-cert'. As the [RFC8366] is quite flexible in what may be put into the 'pinned-domain-cert', the MASA needs some signal as to what certificate would be effective to populate the field with: it may range from the End Entity (EE) Certificate that the Registrar uses, to the entire private Enterprise CA certificate. More specific certificates result in a tighter binding of the voucher to the domain, while less specific certificates result in more flexibility in how the domain is represented by certificates. A Registrar which is seeking a nonceless voucher for later offline use benefits from a less specific certificate, as it permits the actual keypair used by a future Registrar to be determined by the pinned certificate authority. Pritikin, et al. Expires 15 May 2021 [Page 45] Internet-Draft BRSKI November 2020 In some cases, a less specific certificate, such a public WebPKI certificate authority, could be too open, and could permit any entity issued a certificate by that authority to assume ownership of a device that has a voucher pinned. Future work may provide a solution to pin both a certificate and a name that would reduce such risk of malicious ownership assertions. The Registrar SHOULD request a voucher with the most specificity consistent with the mode that it is operating in. In order to do this, when the Registrar prepares the CMS structure for the signed voucher-request, it SHOULD include only certificates which are part of the chain that it wishes the MASA to pin. This MAY be as small as only the End-Entity certificate (with id-kp-cmcRA set) that it uses as it's TLS Server Certificate, or it MAY be the entire chain, including the Domain CA. The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" header field indicating the response media types that are acceptable. This list SHOULD be the entire list presented to the Registrar in the Pledge's original request (see Section 5.2) but MAY be a subset. The MASA is expected to be flexible in what it accepts. The registrar populates the voucher-request fields as follows: created-on: The Registrars SHOULD populate this field with the current date and time when the Registrar formed this voucher request. This field provides additional information to the MASA. nonce: This value, if present, is copied from the pledge voucher- request. The registrar voucher-request MAY omit the nonce as per Section 3.1. serial-number: The serial number of the pledge the registrar would like a voucher for. The registrar determines this value by parsing the authenticated pledge IDevID certificate. See Section 2.3. The registrar MUST verify that the serial number field it parsed matches the serial number field the pledge provided in its voucher-request. This provides a sanity check useful for detecting error conditions and logging. The registrar MUST NOT simply copy the serial number field from a pledge voucher request as that field is claimed but not certified. idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure unique interpretation of the serial-number. In the case of nonceless (offline) voucher-request, then an appropriate value needs to be configured from the same out-of-band source as the serial-number. Pritikin, et al. Expires 15 May 2021 [Page 46] Internet-Draft BRSKI November 2020 prior-signed-voucher-request: The signed pledge voucher-request SHOULD be included in the registrar voucher-request. The entire CMS signed structure is to be included, base64 encoded for transport in the JSON structure. A nonceless registrar voucher-request MAY be submitted to the MASA. Doing so allows the registrar to request a voucher when the pledge is offline, or when the registrar anticipates not being able to connect to the MASA while the pledge is being deployed. Some use cases require the registrar to learn the appropriate IDevID SerialNumber field and appropriate 'Accept header field' values from the physical device labeling or from the sales channel (out-of-scope for this document). All other fields MAY be omitted in the registrar voucher-request. The "proximity-registrar-cert" field MUST NOT be present in the registrar voucher-request. Example JSON payloads of registrar voucher-requests are in Section 3.3 Examples 2 through 4. The MASA verifies that the registrar voucher-request is internally consistent but does not necessarily authenticate the registrar certificate since the registrar MAY be unknown to the MASA in advance. The MASA performs the actions and validation checks described in the following sub-sections before issuing a voucher. 5.5.1. MASA renewal of expired vouchers As described in [RFC8366] vouchers are normally short lived to avoid revocation issues. If the request is for a previous (expired) voucher using the same registrar (that is, a Registrar with the same Domain CA) then the request for a renewed voucher SHOULD be automatically authorized. The MASA has sufficient information to determine this by examining the request, the registrar authentication, and the existing audit-log. The issuance of a renewed voucher is logged as detailed in Section 5.6. To inform the MASA that existing vouchers are not to be renewed one can update or revoke the registrar credentials used to authorize the request (see Section 5.5.4 and Section 5.5.3). More flexible methods will likely involve sales channel integration and authorizations (details are out-of-scope of this document). Pritikin, et al. Expires 15 May 2021 [Page 47] Internet-Draft BRSKI November 2020 5.5.2. MASA pinning of registrar A certificate chain is extracted from the Registrar's signed CMS container. This chain may be as short as a single End-Entity Certificate, up to the entire registrar certificate chain, including the Domain CA certificate, as specified in Section 5.5. If the domain's CA is unknown to the MASA, then it is to be considered a temporary trust anchor for the rest of the steps in this section. The intention is not to authenticate the message as having come from a fully validated origin, but to establish the consistency of the domain PKI. The MASA MAY use the certificate farthest in the chain chain that it received from the Registrar from the end-entity, as determined by MASA policy. A MASA MAY have a local policy that it only pins the End-Entity certificate. This is consistent with [RFC8366]. Details of the policy will typically depend upon the degree of Supply Chain Integration, and the mechanism used by the Registrar to authenticate. Such a policy would also determine how the MASA will respond to a request for a nonceless voucher. 5.5.3. MASA checking of voucher request signature As described in Section 5.5.2, the MASA has extracted Registrar's domain CA. This is used to validate the CMS signature ([RFC5652]) on the voucher-request. Normal PKIX revocation checking is assumed during voucher-request signature validation. This CA certificate MAY have Certificate Revocation List distribution points, or Online Certificate Status Protocol (OCSP) information ([RFC6960]). If they are present, the MASA MUST be able to reach the relevant servers belonging to the Registrar's domain CA to perform the revocation checks. The use of OCSP Stapling is preferred. Pritikin, et al. Expires 15 May 2021 [Page 48] Internet-Draft BRSKI November 2020 5.5.4. MASA verification of domain registrar The MASA MUST verify that the registrar voucher-request is signed by a registrar. This is confirmed by verifying that the id-kp-cmcRA extended key usage extension field (as detailed in EST RFC7030 section 3.6.1) exists in the certificate of the entity that signed the registrar voucher-request. This verification is only a consistency check that the unauthenticated domain CA intended the voucher-request signer to be a registrar. Performing this check provides value to the domain PKI by assuring the domain administrator that the MASA service will only respect claims from authorized Registration Authorities of the domain. Even when a domain CA is authenticated to the MASA, and there is strong sales channel integration to understand who the legitimate owner is, the above id-kp-cmcRA check prevents arbitrary End-Entity certificates (such as an LDevID certificate) from having vouchers issued against them. Other cases of inappropriate voucher issuance are detected by examination of the audit log. If a nonceless voucher-request is submitted the MASA MUST authenticate the registrar as described in either EST [RFC7030] section 3.2.3, section 3.3.2, or by validating the registrar's certificate used to sign the registrar voucher-request using a configured trust anchor. Any of these methods reduce the risk of DDoS attacks and provide an authenticated identity as an input to sales channel integration and authorizations (details are out-of- scope of this document). In the nonced case, validation of the Registrar's identity (via TLS Client Certificate or HTTP authentication) MAY be omitted if the device policy is to accept audit-only vouchers. Pritikin, et al. Expires 15 May 2021 [Page 49] Internet-Draft BRSKI November 2020 5.5.5. MASA verification of pledge prior-signed-voucher-request The MASA MAY verify that the registrar voucher-request includes the 'prior-signed-voucher-request' field. If so the prior-signed- voucher-request MUST include a 'proximity-registrar-cert' that is consistent with the certificate used to sign the registrar voucher- request. Additionally the voucher-request serial-number leaf MUST match the pledge serial-number that the MASA extracts from the signing certificate of the prior-signed-voucher-request. The consistency check described above is checking that the 'proximity- registrar-cert' SPKI fingerprint exists within the registrar voucher- request CMS signature's certificate chain. This is substantially the same as the pin validation described in in [RFC7469] section 2.6, paragraph three. If these checks succeed the MASA updates the voucher and audit-log assertion leafs with the "proximity" assertion, as defined by [RFC8366] section 5.3. 5.5.6. MASA nonce handling The MASA does not verify the nonce itself. If the registrar voucher- request contains a nonce, and the prior-signed-voucher-request exists, then the MASA MUST verify that the nonce is consistent. (Recall from above that the voucher-request might not contain a nonce, see Section 5.5 and Section 5.5.4). The MASA populates the audit-log with the nonce that was verified. If a nonceless voucher is issued, then the audit-log is to be populated with the JSON value "null". 5.6. MASA and Registrar Voucher Response The MASA voucher response to the registrar is forwarded without changes to the pledge; therefore this section applies to both the MASA and the registrar. The HTTP signaling described applies to both the MASA and registrar responses. When a voucher request arrives at the registrar, if it has a cached response from the MASA for the corresponding registrar voucher- request, that cached response can be used according to local policy; otherwise the registrar constructs a new registrar voucher-request and sends it to the MASA. Registrar evaluation of the voucher itself is purely for transparency and audit purposes to further inform log verification (see Section 5.8.3) and therefore a registrar could accept future voucher formats that are opaque to the registrar. Pritikin, et al. Expires 15 May 2021 [Page 50] Internet-Draft BRSKI November 2020 If the voucher-request is successful, the server (MASA responding to registrar or registrar responding to pledge) response MUST contain an HTTP 200 response code. The server MUST answer with a suitable 4xx or 5xx HTTP [RFC7230] error code when a problem occurs. In this case, the response data from the MASA MUST be a plaintext human- readable (UTF-8) error message containing explanatory information describing why the request was rejected. The registrar MAY respond with an HTTP 202 ("the request has been accepted for processing, but the processing has not been completed") as described in EST [RFC7030] section 4.2.3 wherein the client "MUST wait at least the specified 'Retry-After' time before repeating the same request". (see [RFC7231] section 6.6.4) The pledge is RECOMMENDED to provide local feedback (blinked LED etc) during this wait cycle if mechanisms for this are available. To prevent an attacker registrar from significantly delaying bootstrapping the pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the pledge would keep track of the appropriate Retry-After header field values for any number of outstanding registrars but this would involve a state table on the pledge. Instead the pledge MAY ignore the exact Retry-After value in favor of a single hard coded value (a registrar that is unable to complete the transaction after the first 60 seconds has another chance a minute later). A pledge SHOULD only maintain a 202 retry-state for up to 4 days, which is longer than a long weekend, after which time the enrollment attempt fails and the pledge returns to discovery state. A pledge that retries a request after receiving a 202 message MUST resend the same voucher-request. It MUST NOT sign a new voucher- request each time, and in particular, it MUST NOT change the nonce value. In order to avoid infinite redirect loops, which a malicious registrar might do in order to keep the pledge from discovering the correct registrar, the pledge MUST NOT follow more than one redirection (3xx code) to another web origin. EST supports redirection but requires user input; this change allows the pledge to follow a single redirection without a user interaction. A 403 (Forbidden) response is appropriate if the voucher-request is not signed correctly, stale, or if the pledge has another outstanding voucher that cannot be overridden. A 404 (Not Found) response is appropriate when the request is for a device that is not known to the MASA. Pritikin, et al. Expires 15 May 2021 [Page 51] Internet-Draft BRSKI November 2020 A 406 (Not Acceptable) response is appropriate if a voucher of the desired type or using the desired algorithms (as indicated by the Accept: header fields, and algorithms used in the signature) cannot be issued such as because the MASA knows the pledge cannot process that type. The registrar SHOULD use this response if it determines the pledge is unacceptable due to inventory control, MASA audit-logs, or any other reason. A 415 (Unsupported Media Type) response is appropriate for a request that has a voucher-request or Accept: value that is not understood. The voucher response format is as indicated in the submitted Accept header fields or based on the MASA's prior understanding of proper format for this Pledge. Only the [RFC8366] "application/voucher- cms+json" media type is defined at this time. The syntactic details of vouchers are described in detail in [RFC8366]. Figure 14 shows a sample of the contents of a voucher. { "ietf-voucher:voucher": { "nonce": "62a2e7693d82fcda2624de58fb6722e5", "assertion": "logged", "pinned-domain-cert": "base64encodedvalue==", "serial-number": "JADA123456789" } } Figure 14: An example voucher The MASA populates the voucher fields as follows: nonce: The nonce from the pledge if available. See Section 5.5.6. assertion: The method used to verify the relationship between pledge and registrar. See Section 5.5.5. pinned-domain-cert: A certificate. See Section 5.5.2. This figure is illustrative, for an example, see Appendix C.2 where an End Entity certificate is used. serial-number: The serial-number as provided in the voucher-request. Also see Section 5.5.5. domain-cert-revocation-checks: Set as appropriate for the pledge's Pritikin, et al. Expires 15 May 2021 [Page 52] Internet-Draft BRSKI November 2020 capabilities and as documented in [RFC8366]. The MASA MAY set this field to 'false' since setting it to 'true' would require that revocation information be available to the pledge and this document does not make normative requirements for [RFC6961] or equivalent integrations. expires-on: This is set for nonceless vouchers. The MASA ensures the voucher lifetime is consistent with any revocation or pinned- domain-cert consistency checks the pledge might perform. See section Section 2.6.1. There are three times to consider: (a) a configured voucher lifetime in the MASA, (b) the expiry time for the registrar's certificate, (c) any certificate revocation information (CRL) lifetime. The expires-on field SHOULD be before the earliest of these three values. Typically (b) will be some significant time in the future, but (c) will typically be short (on the order of a week or less). The RECOMMENDED period for (a) is on the order of 20 minutes, so it will typically determine the lifespan of the resulting voucher. 20 minutes is sufficient time to reach the post-provisional state in the pledge, at which point there is an established trust relationship between pledge and registrar. The subsequent operations can take as long as required from that point onwards. The lifetime of the voucher has no impact on the lifespan of the ownership relationship. Whenever a voucher is issued the MASA MUST update the audit-log sufficiently to generate the response as described in Section 5.8.1. The internal state requirements to maintain the audit-log are out-of- scope. 5.6.1. Pledge voucher verification The pledge MUST verify the voucher signature using the manufacturer- installed trust anchor(s) associated with the manufacturer's MASA (this is likely included in the pledge's firmware). Management of the manufacturer-installed trust anchor(s) is out-of-scope of this document; this protocol does not update these trust anchor(s). The pledge MUST verify the serial-number field of the signed voucher matches the pledge's own serial-number. The pledge MUST verify the nonce information in the voucher. If present, the nonce in the voucher must match the nonce the pledge submitted to the registrar; vouchers with no nonce can also be accepted (according to local policy, see Section 7.2) Pritikin, et al. Expires 15 May 2021 [Page 53] Internet-Draft BRSKI November 2020 The pledge MUST be prepared to parse and fail gracefully from a voucher response that does not contain a 'pinned-domain-cert' field. Such a thing indicates a failure to enroll in this domain, and the pledge MUST attempt joining with other available Join Proxy. The pledge MUST be prepared to ignore additional fields that it does not recognize. 5.6.2. Pledge authentication of provisional TLS connection Following the process described in [RFC8366], the pledge should consider the public key from the pinned-domain-cert as the sole temporary trust anchor. The pledge then evaluates the TLS Server Certificate chain that it received when the TLS connection was formed using this trust anchor. It is possible that the pinned-domain-cert matches the End-Entity Certificate provided in the TLS Server. If a registrar's credentials cannot be verified using the pinned- domain-cert trust anchor from the voucher then the TLS connection is immediately discarded and the pledge abandons attempts to bootstrap with this discovered registrar. The pledge SHOULD send voucher status telemetry (described below) before closing the TLS connection. The pledge MUST attempt to enroll using any other proxies it has found. It SHOULD return to the same proxy again after unsuccessful attempts with other proxies. Attempts should be made repeated at intervals according to the backoff timer described earlier. Attempts SHOULD be repeated as failure may be the result of a temporary inconsistency (an inconsistently rolled registrar key, or some other mis-configuration). The inconsistency could also be the result an active MITM attack on the EST connection. The registrar MUST use a certificate that chains to the pinned- domain-cert as its TLS server certificate. The pledge's PKIX path validation of a registrar certificate's validity period information is as described in Section 2.6.1. Once the PKIX path validation is successful the TLS connection is no longer provisional. The pinned-domain-cert MAY be installed as a trust anchor for future operations such as enrollment (e.g. [RFC7030] as recommended) or trust anchor management or raw protocols that do not need full PKI based key management. It can be used to authenticate any dynamically discovered EST server that contain the id-kp-cmcRA extended key usage extension as detailed in EST RFC7030 section 3.6.1; but to reduce system complexity the pledge SHOULD avoid additional discovery Pritikin, et al. Expires 15 May 2021 [Page 54] Internet-Draft BRSKI November 2020 operations. Instead the pledge SHOULD communicate directly with the registrar as the EST server. The 'pinned-domain-cert' is not a complete distribution of the [RFC7030] section 4.1.3 CA Certificate Response, which is an additional justification for the recommendation to proceed with EST key management operations. Once a full CA Certificate Response is obtained it is more authoritative for the domain than the limited 'pinned-domain-cert' response. 5.7. Pledge BRSKI Status Telemetry The domain is expected to provide indications to the system administrators concerning device lifecycle status. To facilitate this it needs telemetry information concerning the device's status. The pledge MUST indicate its pledge status regarding the voucher. It does this by sending a status message to the Registrar. The posted data media type: application/json The client sends an HTTP POST to the server at the URI ".well- known/brski/voucher_status". The format and semantics described below are for version 1. A version field is included to permit significant changes to this feedback in the future. A Registrar that receives a status message with a version larger than it knows about SHOULD log the contents and alert a human. The Status field indicates if the voucher was acceptable. Boolean values are acceptable, where "true" indicates the voucher was acceptable. If the voucher was not acceptable the Reason string indicates why. In the failure case this message may be sent to an unauthenticated, potentially malicious registrar and therefore the Reason string SHOULD NOT provide information beneficial to an attacker. The operational benefit of this telemetry information is balanced against the operational costs of not recording that an voucher was ignored by a client the registrar expected to continue joining the domain. The reason-context attribute is an arbitrary JSON object (literal value or hash of values) which provides additional information specific to this pledge. The contents of this field are not subject to standardization. Pritikin, et al. Expires 15 May 2021 [Page 55] Internet-Draft BRSKI November 2020 The version and status fields MUST be present. The Reason field SHOULD be present whenever the status field is false. The Reason- Context field is optional. In the case of a SUCCESS the Reason string MAY be omitted. The keys to this JSON object are case-sensitive and MUST be lowercase. Figure 16 shows an example JSON. file "voucherstatus.cddl" voucherstatus-post = { "version": uint, "status": bool, ? "reason": text, ? "reason-context" : { $$arbitrary-map } } } Figure 15: CDDL for voucher status POST { "version": 1, "status":false, "reason":"Informative human readable message", "reason-context": { "additional" : "JSON" } } Figure 16: Example Status Telemetry The server SHOULD respond with an HTTP 200 but MAY simply fail with an HTTP 404 error. The client ignores any response. Within the server logs the server SHOULD capture this telemetry information. Additional standard JSON fields in this POST MAY be added, see Section 8.5. A server that sees unknown fields should log them, but otherwise ignore them. 5.8. Registrar audit-log request After receiving the pledge status telemetry Section 5.7, the registrar SHOULD request the MASA audit-log from the MASA service. This is done with an HTTP POST using the operation path value of "/.well-known/brski/requestauditlog". The registrar SHOULD HTTP POST the same registrar voucher-request as it did when requesting a voucher (using the same Content-Type). It is posted to the /requestauditlog URI instead. The "idevid-issuer" Pritikin, et al. Expires 15 May 2021 [Page 56] Internet-Draft BRSKI November 2020 and "serial-number" informs the MASA which log is requested so the appropriate log can be prepared for the response. Using the same media type and message minimizes cryptographic and message operations although it results in additional network traffic. The relying MASA implementation MAY leverage internal state to associate this request with the original, and by now already validated, voucher-request so as to avoid an extra crypto validation. A registrar MAY request logs at future times. If the registrar generates a new request then the MASA is forced to perform the additional cryptographic operations to verify the new request. A MASA that receives a request for a device that does not exist, or for which the requesting owner was never an owner returns an HTTP 404 ("Not found") code. It is reasonable for a Registrar, that the MASA does not believe to be the current owner, to request the audit-log. There are probably reasons for this which are hard to predict in advance. For instance, such a registrar may not be aware that the device has been resold; it may be that the device has been resold inappropriately, and this is how the original owner will learn of the occurance. It is also possible that the device legitimately spends time in two different networks. Rather than returning the audit-log as a response to the POST (with a return code 200), the MASA MAY instead return a 201 ("Created") response ([RFC7231] sections 6.3.2 and 7.1), with the URL to the prepared (and idempotent, therefore cachable) audit response in the Location: header field. In order to avoid enumeration of device audit-logs, MASA that return URLs SHOULD take care to make the returned URL unguessable. [W3C.WD-capability-urls-20140218] provides very good additional guidance. For instance, rather than returning URLs containing a database number such as https://example.com/auditlog/1234 or the EUI of the device such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD return a randomly generated value (a "slug" in web parlance). The value is used to find the relevant database entry. A MASA that returns a code 200 MAY also include a Location: header for future reference by the registrar. Pritikin, et al. Expires 15 May 2021 [Page 57] Internet-Draft BRSKI November 2020 5.8.1. MASA audit log response A log data file is returned consisting of all log entries associated with the device selected by the IDevID presented in the request. The audit log may be abridged by removal of old or repeated values as explained below. The returned data is in JSON format ([RFC8259]), and the Content-Type SHOULD be "application/json". The following CDDL ([RFC8610]) explains the structure of the JSON format audit-log response: file "auditlog.cddl" audit-log-response = { "version": uint, "events": [ + event ] "truncation": { ? "nonced duplicates": uint, ? "nonceless duplicates": uint, ? "arbitrary": uint, } } event = { "date": text, "domainID": text, "nonce": text / null, "assertion": "verified" / "logged" / "proximity", ? "truncated": uint, } Figure 17: CDDL for audit-log response An example: Pritikin, et al. Expires 15 May 2021 [Page 58] Internet-Draft BRSKI November 2020 { "version":"1", "events":[ { "date":"2019-05-15T17:25:55.644-04:00", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", "nonce":"VOUFT-WwrEv0NuAQEHoV7Q", "assertion":"proximity", "truncated":"0" }, { "date":"2017-05-15T17:25:55.644-04:00", "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", "nonce":"f4G6Vi1t8nKo/FieCVgpBg==", "assertion":"proximity" } ], "truncation": { "nonced duplicates": "0", "nonceless duplicates": "1", "arbitrary": "2" } } Figure 18: Example of audit-log response The domainID is a binary SubjectKeyIdentifier value calculated according to Section 5.8.2. It is encoded once in base64 in order to be transported in this JSON container. The date is in [RFC3339] format, which is consistent with typical JavaScript usage of JSON. The truncation structure MAY be omitted if all values are zero. Any counter missing from the truncation structure is the be assumed to be zero. The nonce is a string, as provided in the voucher-request, and used in the voucher. If no nonce was placed in the resulting voucher, then a value of null SHOULD be used in preference to omitting the entry. While the nonce is often created as a base64 encoded random series of bytes, this should not be assumed. Distribution of a large log is less than ideal. This structure can be optimized as follows: Nonced or Nonceless entries for the same domainID MAY be abridged from the log leaving only the single most recent nonced or nonceless entry for that domainID. In the case of truncation the 'event' truncation value SHOULD contain a count of the Pritikin, et al. Expires 15 May 2021 [Page 59] Internet-Draft BRSKI November 2020 number of events for this domainID that were omitted. The log SHOULD NOT be further reduced but there could exist operational situation where maintaining the full log is not possible. In such situations the log MAY be arbitrarily abridged for length, with the number of removed entries indicated as 'arbitrary'. If the truncation count exceeds 1024 then the MASA MAY use this value without further incrementing it. A log where duplicate entries for the same domain have been omitted ("nonced duplicates" and/or "nonceless duplicates) could still be acceptable for informed decisions. A log that has had "arbitrary" truncations is less acceptable but manufacturer transparency is better than hidden truncations. A registrar that sees a version value greater than 1 indicates an audit log format that has been enhanced with additional information. No information will be removed in future versions; should an incompatible change be desired in the future, then a new HTTP end point will be used. This document specifies a simple log format as provided by the MASA service to the registrar. This format could be improved by distributed consensus technologies that integrate vouchers with technologies such as block-chain or hash trees or optimized logging approaches. Doing so is out of the scope of this document but is an anticipated improvement for future work. As such, the registrar SHOULD anticipate new kinds of responses, and SHOULD provide operator controls to indicate how to process unknown responses. 5.8.2. Calculation of domainID The domainID is a binary value (a BIT STRING) that uniquely identifies a Registrar by the "pinned-domain-cert". If the "pinned-domain-cert" certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs to be calculated by both MASA (to populate the audit-log), and by the Registrar (to recognize itself in the audit log). [RFC5280] section 4.2.1.2 does not mandate that the SubjectKeyIdentifier extension be present in non-CA certificates. It is RECOMMENDED that Registrar certificates (even if self-signed), always include the SubjectKeyIdentifier to be used as a domainID. Pritikin, et al. Expires 15 May 2021 [Page 60] Internet-Draft BRSKI November 2020 The domainID is determined from the certificate chain associated with the pinned-domain-cert and is used to update the audit-log. 5.8.3. Registrar audit log verification Each time the Manufacturer Authorized Signing Authority (MASA) issues a voucher, it appends details of the assignment to an internal audit log for that device. The internal audit log is processed when responding to requests for details as described in Section 5.8. The contents of the audit log can express a variety of trust levels, and this section explains what kind of trust a registrar can derive from the entries. While the audit log provides a list of vouchers that were issued by the MASA, the vouchers are issued in response to voucher-requests, and it is the contents of the voucher-requests which determines how meaningful the audit log entries are. A registrar SHOULD use the log information to make an informed decision regarding the continued bootstrapping of the pledge. The exact policy is out of scope of this document as it depends on the security requirements within the registrar domain. Equipment that is purchased pre-owned can be expected to have an extensive history. The following discussion is provided to help explain the value of each log element: date: The date field provides the registrar an opportunity to divide the log around known events such as the purchase date. Depending on context known to the registrar or administrator events before/ after certain dates can have different levels of importance. For example for equipment that is expected to be new, and thus have no history, it would be a surprise to find prior entries. domainID: If the log includes an unexpected domainID then the pledge could have imprinted on an unexpected domain. The registrar can be expected to use a variety of techniques to define "unexpected" ranging from white lists of prior domains to anomaly detection (e.g. "this device was previously bound to a different domain than any other device deployed"). Log entries can also be compared against local history logs in search of discrepancies (e.g. "this device was re-deployed some number of times internally but the external audit log shows additional re-deployments our internal logs are unaware of"). nonce: Nonceless entries mean the logged domainID could theoretically trigger a reset of the pledge and then take over management by using the existing nonceless voucher. Pritikin, et al. Expires 15 May 2021 [Page 61] Internet-Draft BRSKI November 2020 assertion: The assertion leaf in the voucher and audit log indicates why the MASA issued the voucher. A "verified" entry means that the MASA issued the associated voucher as a result of positive verification of ownership. However, this entry does not indicate whether the pledge was actually deployed in the prior domain, or not. A "logged" assertion informs the registrar that the prior vouchers were issued with minimal verification. A "proximity" assertion assures the registrar that the pledge was truly communicating with the prior domain and thus provides assurance that the prior domain really has deployed the pledge. A relatively simple policy is to white list known (internal or external) domainIDs, and require all vouchers to have a nonce. An alternative is to require that all nonceless vouchers be from a subset (e.g. only internal) of domainIDs. If the policy is violated a simple action is to revoke any locally issued credentials for the pledge in question or to refuse to forward the voucher. The Registrar MUST then refuse any EST actions, and SHOULD inform a human via a log. A registrar MAY be configured to ignore (i.e. override the above policy) the history of the device but it is RECOMMENDED that this only be configured if hardware assisted (i.e. TPM anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported. 5.9. EST Integration for PKI bootstrapping The pledge SHOULD follow the BRSKI operations with EST enrollment operations including "CA Certificates Request", "CSR Attributes" and "Client Certificate Request" or "Server-Side Key Generation", etc. This is a relatively seamless integration since BRSKI API calls provide an automated alternative to the manual bootstrapping method described in [RFC7030]. As noted above, use of HTTP persistent connections simplifies the pledge state machine. Although EST allows clients to obtain multiple certificates by sending multiple Certificate Signing Requests (CSR) requests, BRSKI does not support this mechanism directly. This is because BRSKI pledges MUST use the CSR Attributes request ([RFC7030] section 4.5). The registrar MUST validate the CSR against the expected attributes. This implies that client requests will "look the same" and therefore result in a single logical certificate being issued even if the client were to make multiple requests. Registrars MAY contain more complex logic but doing so is out-of-scope of this specification. BRSKI does not signal any enhancement or restriction to this capability. Pritikin, et al. Expires 15 May 2021 [Page 62] Internet-Draft BRSKI November 2020 5.9.1. EST Distribution of CA Certificates The pledge SHOULD request the full EST Distribution of CA Certificates message. See RFC7030, section 4.1. This ensures that the pledge has the complete set of current CA certificates beyond the pinned-domain-cert (see Section 5.6.2 for a discussion of the limitations inherent in having a single certificate instead of a full CA Certificates response.) Although these limitations are acceptable during initial bootstrapping, they are not appropriate for ongoing PKIX end entity certificate validation. 5.9.2. EST CSR Attributes Automated bootstrapping occurs without local administrative configuration of the pledge. In some deployments it is plausible that the pledge generates a certificate request containing only identity information known to the pledge (essentially the X.509 IDevID information) and ultimately receives a certificate containing domain specific identity information. Conceptually the CA has complete control over all fields issued in the end entity certificate. Realistically this is operationally difficult with the current status of PKI certificate authority deployments, where the CSR is submitted to the CA via a number of non-standard protocols. Even with all standardized protocols used, it could operationally be problematic to expect that service specific certificate fields can be created by a CA that is likely operated by a group that has no insight into different network services/protocols used. For example, the CA could even be outsourced. To alleviate these operational difficulties, the pledge MUST request the EST "CSR Attributes" from the EST server and the EST server needs to be able to reply with the attributes necessary for use of the certificate in its intended protocols/services. This approach allows for minimal CA integrations and instead the local infrastructure (EST server) informs the pledge of the proper fields to include in the generated CSR (such as rfc822Name). This approach is beneficial to automated bootstrapping in the widest number of environments. In networks using the BRSKI enrolled certificate to authenticate the ACP (Autonomic Control Plane), the EST CSR attributes MUST include the ACP Domain Information Fields defined in [I-D.ietf-anima-autonomic-control-plane] section 6.1.1. Pritikin, et al. Expires 15 May 2021 [Page 63] Internet-Draft BRSKI November 2020 The registrar MUST also confirm that the resulting CSR is formatted as indicated before forwarding the request to a CA. If the registrar is communicating with the CA using a protocol such as full CMC, which provides mechanisms to override the CSR attributes, then these mechanisms MAY be used even if the client ignores CSR Attribute guidance. 5.9.3. EST Client Certificate Request The pledge MUST request a new client certificate. See RFC7030, section 4.2. 5.9.4. Enrollment Status Telemetry For automated bootstrapping of devices, the administrative elements providing bootstrapping also provide indications to the system administrators concerning device lifecycle status. This might include information concerning attempted bootstrapping messages seen by the client. The MASA provides logs and status of credential enrollment. [RFC7030] assumes an end user and therefore does not include a final success indication back to the server. This is insufficient for automated use cases. The client MUST send an indicator to the Registrar about its enrollment status. It does this by using an HTTP POST of a JSON dictionary with the of attributes described below to the new EST endpoint at "/.well-known/brski/enrollstatus". (XXX ?) When indicating a successful enrollment the client SHOULD first re- establish the EST TLS session using the newly obtained credentials. TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The client SHOULD therefore always close the existing TLS connection, and start a new one. In the case of a failed enrollment, the client MUST send the telemetry information over the same TLS connection that was used for the enrollment attempt, with a Reason string indicating why the most recent enrollment failed. (For failed attempts, the TLS connection is the most reliable way to correlate server-side information with what the client provides.) The version and status fields MUST be present. The Reason field SHOULD be present whenever the status field is false. In the case of a SUCCESS the Reason string MAY be omitted. Pritikin, et al. Expires 15 May 2021 [Page 64] Internet-Draft BRSKI November 2020 The reason-context attribute is an arbitrary JSON object (literal value or hash of values) which provides additional information specific to the failure to unroll from this pledge. The contents of this field are not subject to standardization. This is represented by the group-socket "$$arbitrary-map" in the CDDL. In the case of a SUCCESS the Reason string is omitted. file "enrollstatus.cddl" enrollstatus-post = { "version": uint, "status": bool, ? "reason": text, ? "reason-context" : { $$arbitrary-map } } } Figure 19: CDDL for enrollment status POST An example status report can be seen below. It is sent with with the media type: application/json { "version": 1, "status":true, "reason":"Informative human readable message", "reason-context": { "additional" : "JSON" } } Figure 20: Example of enrollment status POST The server SHOULD respond with an HTTP 200 but MAY simply fail with an HTTP 404 error. Within the server logs the server MUST capture if this message was received over an TLS session with a matching client certificate. 5.9.5. Multiple certificates Pledges that require multiple certificates could establish direct EST connections to the registrar. Pritikin, et al. Expires 15 May 2021 [Page 65] Internet-Draft BRSKI November 2020 5.9.6. EST over CoAP This document describes extensions to EST for the purposes of bootstrapping of remote key infrastructures. Bootstrapping is relevant for CoAP enrollment discussions as well. The definition of EST and BRSKI over CoAP is not discussed within this document beyond ensuring proxy support for CoAP operations. Instead it is anticipated that a definition of CoAP mappings will occur in subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP mappings for BRSKI will be discussed either there or in future work. 6. Clarification of transfer-encoding [RFC7030] defines its endpoints to include a "Content-Transfer- Encoding" heading, and the payloads to be [RFC4648] Base64 encoded DER. When used within BRSKI, the original RFC7030 EST endpoints remain Base64 encoded, but the new BRSKI end points which send and receive binary artifacts (specifically, "/.well-known/brski/requestvoucher") are binary. That is, no encoding is used. In the BRSKI context, the EST "Content-Transfer-Encoding" header field if present, SHOULD be ignored. This header field does not need to be included. 7. Reduced security operational modes A common requirement of bootstrapping is to support less secure operational modes for support specific use cases. This section suggests a range of mechanisms that would alter the security assurance of BRSKI to accommodate alternative deployment architectures and mitigate lifecycle management issues identified in Section 10. They are presented here as informative (non-normative) design guidance for future standardization activities. Section 9 provides standardization applicability statements for the ANIMA ACP. Other users would be expected that subsets of these mechanisms could be profiled with an accompanying applicability statements similar to the one described in Section 9. This section is considered non-normative in the generality of the protocol. Use of the suggested mechanisms here MUST be detailed in specific profiles of BRSKI, such as in Section 9. 7.1. Trust Model This section explains the trust relationships detailed in Section 2.4: Pritikin, et al. Expires 15 May 2021 [Page 66] Internet-Draft BRSKI November 2020 +--------+ +---------+ +------------+ +------------+ | Pledge | | Join | | Domain | |Manufacturer| | | | Proxy | | Registrar | | Service | | | | | | | | (Internet) | +--------+ +---------+ +------------+ +------------+ Figure 10 Pledge: The pledge could be compromised and providing an attack vector for malware. The entity is trusted to only imprint using secure methods described in this document. Additional endpoint assessment techniques are RECOMMENDED but are out-of-scope of this document. Join Proxy: Provides proxy functionalities but is not involved in security considerations. Registrar: When interacting with a MASA a registrar makes all decisions. For Ownership Audit Vouchers (see [RFC8366]) the registrar is provided an opportunity to accept MASA decisions. Vendor Service, MASA: This form of manufacturer service is trusted to accurately log all claim attempts and to provide authoritative log information to registrars. The MASA does not know which devices are associated with which domains. These claims could be strengthened by using cryptographic log techniques to provide append only, cryptographic assured, publicly auditable logs. Vendor Service, Ownership Validation: This form of manufacturer service is trusted to accurately know which device is owned by which domain. 7.2. Pledge security reductions The following is a list of alternative behaviours that the pledge can be programmed to implement. These behaviours are not mutually exclusive, nor are they dependent upon each other. Some of these methods enable offline and emergency (touch based) deployment use cases. Normative language is used as these behaviours are referenced in later sections in a normative fashion. 1. The pledge MUST accept nonceless vouchers. This allows for a use case where the registrar can not connect to the MASA at the deployment time. Logging and validity periods address the security considerations of supporting these use cases. Pritikin, et al. Expires 15 May 2021 [Page 67] Internet-Draft BRSKI November 2020 2. Many devices already support "trust on first use" for physical interfaces such as console ports. This document does not change that reality. Devices supporting this protocol MUST NOT support "trust on first use" on network interfaces. This is because "trust on first use" over network interfaces would undermine the logging based security protections provided by this specification. 3. The pledge MAY have an operational mode where it skips voucher validation one time. For example if a physical button is depressed during the bootstrapping operation. This can be useful if the manufacturer service is unavailable. This behavior SHOULD be available via local configuration or physical presence methods (such as use of a serial/craft console) to ensure new entities can always be deployed even when autonomic methods fail. This allows for unsecured imprint. 4. A craft/serial console could include a command such as "est- enroll [2001:db8:0:1]:443" that begins the EST process from the point after the voucher is validated. This process SHOULD include server certificate verification using an on-screen fingerprint. It is RECOMMENDED that "trust on first use" or any method of skipping voucher validation (including use of craft serial console) only be available if hardware assisted Network Endpoint Assessment (NEA: [RFC5209]) is supported. This recommendation ensures that domain network monitoring can detect inappropriate use of offline or emergency deployment procedures when voucher-based bootstrapping is not used. 7.3. Registrar security reductions A registrar can choose to accept devices using less secure methods. They MUST NOT be the default behavior. These methods may be acceptable in situations where threat models indicate that low security is adequate. This includes situations where security decisions are being made by the local administrator: 1. A registrar MAY choose to accept all devices, or all devices of a particular type, at the administrator's discretion. This could occur when informing all registrars of unique identifiers of new entities might be operationally difficult. 2. A registrar MAY choose to accept devices that claim a unique identity without the benefit of authenticating that claimed identity. This could occur when the pledge does not include an X.509 IDevID factory installed credential. New Entities without Pritikin, et al. Expires 15 May 2021 [Page 68] Internet-Draft BRSKI November 2020 an X.509 IDevID credential MAY form the Section 5.2 request using the Section 5.5 format to ensure the pledge's serial number information is provided to the registrar (this includes the IDevID AuthorityKeyIdentifier value, which would be statically configured on the pledge.) The pledge MAY refuse to provide a TLS client certificate (as one is not available.) The pledge SHOULD support HTTP-based or certificate-less TLS authentication as described in EST RFC7030 section 3.3.2. A registrar MUST NOT accept unauthenticated New Entities unless it has been configured to do so by an administrator that has verified that only expected new entities can communicate with a registrar (presumably via a physically secured perimeter.) 3. A registrar MAY submit a nonceless voucher-requests to the MASA service (by not including a nonce in the voucher-request.) The resulting vouchers can then be stored by the registrar until they are needed during bootstrapping operations. This is for use cases where the target network is protected by an air gap and therefore cannot contact the MASA service during pledge deployment. 4. A registrar MAY ignore unrecognized nonceless log entries. This could occur when used equipment is purchased with a valid history being deployed in air gap networks that required offline vouchers. 5. A registrar MAY accept voucher formats of future types that can not be parsed by the Registrar. This reduces the Registrar's visibility into the exact voucher contents but does not change the protocol operations. 7.4. MASA security reductions Lower security modes chosen by the MASA service affect all device deployments unless the lower-security behavior is tied to specific device identities. The modes described below can be applied to specific devices via knowledge of what devices were sold. They can also be bound to specific customers (independent of the device identity) by authenticating the customer's Registrar. 7.4.1. Issuing Nonceless vouchers A MASA has the option of not including a nonce in the voucher, and/or not requiring one to be present in the voucher-request. This results in distribution of a voucher that may never expire and in effect makes the specified Domain an always trusted entity to the pledge during any subsequent bootstrapping attempts. That a nonceless voucher was issued is captured in the log information so that the Pritikin, et al. Expires 15 May 2021 [Page 69] Internet-Draft BRSKI November 2020 registrar can make appropriate security decisions when a pledge joins the Domain. Nonceless vouchers are useful to support use cases where registrars might not be online during actual device deployment. While a nonceless voucher may include an expiry date, a typical use for a nonceless voucher is for it to be long-lived. If the device can be trusted to have an accurate clock (the MASA will know), then a nonceless voucher CAN be issued with a limited lifetime. A more typical case for a nonceless voucher is for use with offline onboarding scenarios where it is not possible to pass a fresh voucher-request to the MASA. The use of a long-lived voucher also eliminates concern about the availability of the MASA many years in the future. Thus many nonceless vouchers will have no expiry dates. Thus, the long lived nonceless voucher does not require the proof that the device is online. Issuing such a thing is only accepted when the registrar is authenticated by the MASA and the MASA is authorized to provide this functionality to this customer. The MASA is RECOMMENDED to use this functionality only in concert with an enhanced level of ownership tracking, the details of which are out of scope for this document. If the pledge device is known to have a real-time-clock that is set from the factory, use of a voucher validity period is RECOMMENDED. 7.4.2. Trusting Owners on First Use A MASA has the option of not verifying ownership before responding with a voucher. This is expected to be a common operational model because doing so relieves the manufacturer providing MASA services from having to track ownership during shipping and supply chain and allows for a very low overhead MASA service. A registrar uses the audit log information as a defense in depth strategy to ensure that this does not occur unexpectedly (for example when purchasing new equipment the registrar would throw an error if any audit log information is reported.) The MASA SHOULD verify the 'prior-signed- voucher-request' information for pledges that support that functionality. This provides a proof-of-proximity check that reduces the need for ownership verification. The proof-of-proximity comes from the assumption that the pledge and Join Proxy are on the same link-local connection. Pritikin, et al. Expires 15 May 2021 [Page 70] Internet-Draft BRSKI November 2020 A MASA that practices Trust-on-First-Use (TOFU) for Registrar identity may wish to annotate the origin of the connection by IP address or netblock, and restrict future use of that identity from other locations. A MASA that does this SHOULD take care to not create nuisance situations for itself when a customer has multiple registrars, or uses outgoing IPv4 NAT44 connections that change frequently. 7.4.3. Updating or extending voucher trust anchors This section deals with the problem of a MASA that is no longer available due to a failed business, or the situation where a MASA is uncooperative to a secondary sale. A manufacturer could offer a management mechanism that allows the list of voucher verification trust anchors to be extended. [I-D.ietf-netconf-keystore] is one such interface that could be implemented using YANG. Pretty much any configuration mechanism used today could be extended to provide the needed additional update. A manufacturer could even decide to install the domain CA trust anchors received during the EST "cacerts" step as voucher verification anchors. Some additional signals will be needed to clearly identify which keys have voucher validation authority from among those signed by the domain CA. This is future work. With the above change to the list of anchors, vouchers can be issued by an alternate MASA. This could be the previous owner (the seller), or some other trusted third party who is mediating the sale. If it was a third party, then the seller would need to have taken steps to introduce the third party configuration to the device prior disconnection. The third party (e.g. a wholesaler of used equipment) could however use a mechanism described in Section 7.2 to take control of the device after receiving it physically. This would permit the third party to act as the MASA for future onboarding actions. As the IDevID certificate probably can not be replaced, the new owner's Registrar would have to support an override of the MASA URL. To be useful for resale or other transfers of ownership one of two situations will need to occur. The simplest is that the device is not put through any kind of factory default/reset before going through onboarding again. Some other secure, physical signal would be needed to initiate it. This is most suitable for redeploying a device within the same Enterprise. This would entail having previous configuration in the system until entirely replaced by the new owner, and represents some level of risk. Pritikin, et al. Expires 15 May 2021 [Page 71] Internet-Draft BRSKI November 2020 The second mechanism is that there would need to be two levels of factory reset. One would take the system back entirely to manufacturer state, including removing any added trust anchors, and the second (more commonly used) one would just restore the configuration back to a known default without erasing trust anchors. This weaker factory reset might leave valuable credentials on the device and this may be unacceptable to some owners. As a third option, the manufacturer's trust anchors could be entirely overwritten with local trust anchors. A factory default would never restore those anchors. This option comes with a lot of power, but also a lot of responsibility: if access to the private part of the new anchors are lost the manufacturer may be unable to help. 8. IANA Considerations This document requires the following IANA actions: 8.1. The IETF XML Registry This document registers a URI in the "IETF XML Registry" [RFC3688]. IANA is asked to register the following: URI: urn:ietf:params:xml:ns:yang:ietf-voucher-request Registrant Contact: The ANIMA WG of the IETF. XML: N/A, the requested URI is an XML namespace. 8.2. YANG Module Names Registry This document registers a YANG module in the "YANG Module Names" registry [RFC6020]. IANA is asked to register the following: name: ietf-voucher-request namespace: urn:ietf:params:xml:ns:yang:ietf-voucher-request prefix: vch reference: THIS DOCUMENT 8.3. BRSKI well-known considerations 8.3.1. BRSKI .well-known registration To the Well-Known URIs Registry, at: "https://www.iana.org/assignments/well-known-uris/well-known- uris.xhtml", this document registers the well-known name "brski" with the following filled-in template from [RFC5785]: URI suffix: brski Change Controller: IETF Pritikin, et al. Expires 15 May 2021 [Page 72] Internet-Draft BRSKI November 2020 IANA is asked to change the registration of "est" to now only include RFC7030 and no longer this document. Earlier versions of this document used "/.well-known/est" rather than "/.well-known/brski". 8.3.2. BRSKI .well-known registry IANA is requested to create a new Registry entitled: "BRSKI well- known URIs". The registry shall have at least three columns: URI, description, and reference. New items can be added using the Specification Required process. The initial contents of this registry shall be: URI document description requestvoucher [THISRFC] pledge to registrar, and from registrar to MASA voucher_status [THISRFC] pledge to registrar requestauditlog [THISRFC] registrar to MASA enrollstatus [THISRFC] pledge to registrar 8.4. PKIX Registry IANA is requested to register the following: This document requests a number for id-mod-MASAURLExtn2016(TBD) from the pkix(7) id-mod(0) Registry. This document has received an early allocation from the id-pe registry (SMI Security for PKIX Certificate Extension) for id-pe- masa-url with the value 32, resulting in an OID of 1.3.6.1.5.5.7.1.32. 8.5. Pledge BRSKI Status Telemetry IANA is requested to create a new Registry entitled: "BRSKI Parameters", and within that Registry to create a table called: "Pledge BRSKI Status Telemetry Attributes". New items can be added using the Specification Required process. The following items are to be in the initial registration, with this document (Section 5.7) as the reference: * version * Status * Reason * reason-context Pritikin, et al. Expires 15 May 2021 [Page 73] Internet-Draft BRSKI November 2020 8.6. DNS Service Names IANA is requested to register the following Service Names: Service Name: brski-proxy Transport Protocol(s): tcp Assignee: IESG . Contact: IESG Description: The Bootstrapping Remote Secure Key Infrastructures Proxy Reference: [This document] Service Name: brski-registrar Transport Protocol(s): tcp Assignee: IESG . Contact: IESG Description: The Bootstrapping Remote Secure Key Infrastructures Registrar Reference: [This document] 8.7. GRASP Objective Names IANA is requested to register the following GRASP Objective Names: The IANA is requested to register the value "AN_Proxy" (without quotes) to the GRASP Objectives Names Table in the GRASP Parameter Registry. The specification for this value is this document, Section 4.1.1. The IANA is requested to register the value "AN_join_registrar" (without quotes) to the GRASP Objectives Names Table in the GRASP Parameter Registry. The specification for this value is this document, Section 4.3. 9. Applicability to the Autonomic Control Plane (ACP) This document provides a solution to the requirements for secure bootstrap set out in Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance [RFC8368], A Reference Model for Autonomic Networking [I-D.ietf-anima-reference-model] and specifically the An Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and Network). The protocol described in this document has appeal in a number of other non-ANIMA use cases. Such uses of the protocol will be deploying into other environments with different tradeoffs of Pritikin, et al. Expires 15 May 2021 [Page 74] Internet-Draft BRSKI November 2020 privacy, security, reliability and autonomy from manufacturers. As such those use cases will need to provide their own applicability statements, and will need to address unique privacy and security considerations for the environments in which they are used. The autonomic control plane (ACP) that is bootstrapped by the BRSKI protocol is typically used in medium to large Internet Service Provider organizations. Equivalent enterprises that have significant layer-3 router connectivity also will find significant benefit, particularly if the Enterprise has many sites. (A network consisting of primarily layer-2 is not excluded, but the adjacencies that the ACP will create and maintain will not reflect the topology until all devices participate in the ACP). In the ACP, the Join Proxy is found to be proximal because communication between the pledge and the join proxy is exclusively on IPv6 Link-Local addresses. The proximity of the Join Proxy to the Registrar is validated by the Registrar using ANI ACP IPv6 Unique Local Addresses (ULA). ULAs are not routable over the Internet, so as long as the Join Proxy is operating correctly the proximity asssertion is satisfied. Other uses of BRSKI will need make similar analysis if they use proximity assertions. As specified in the ANIMA charter, this work "..focuses on professionally-managed networks." Such a network has an operator and can do things like install, configure and operate the Registrar function. The operator makes purchasing decisions and is aware of what manufacturers it expects to see on its network. Such an operator is also capable of performing bootstrapping of a device using a serial-console (craft console). The zero-touch mechanism presented in this and the ACP document [I-D.ietf-anima-autonomic-control-plane] represents a significiant efficiency: in particular it reduces the need to put senior experts on airplanes to configure devices in person. There is a recognition as the technology evolves that not every situation may work out, and occasionally a human may still have to visit. In recognition of this, some mechanisms are presented in Section 7.2. The manufacturer MUST provide at least one of the one- touch mechanisms described that permit enrollment to be proceed without availability of any manufacturer server (such as the MASA). The BRSKI protocol is going into environments where there have already been quite a number of vendor proprietary management systems. Those are not expected to go away quickly, but rather to leverage the secure credentials that are provisioned by BRSKI. The connectivity requirements of said management systems are provided by the ACP. Pritikin, et al. Expires 15 May 2021 [Page 75] Internet-Draft BRSKI November 2020 9.1. Operational Requirements This section collects operational requirements based upon the three roles involved in BRSKI: The Manufacturer Authorized Signing Authority (MASA), the (Domain) Owner and the Device. It should be recognized that the manufacturer may be involved in two roles, as it creates the software/firmware for the device, and also may be the operator of the MASA. The requirements in this section are presented using BCP14 ([RFC2119], [RFC8174]) language. These do not represent new normative statements, just a review of a few such things in one place by role. They also apply specifically to the ANIMA ACP use case. Other use cases likely have similar, but MAY have different requirements. 9.1.1. MASA Operational Requirements The manufacturer MUST arrange for an online service to be available called the MASA. It MUST be available at the URL which is encoded in the IDevID certificate extensions described in Section 2.3.2. The online service MUST have access to a private key with which to sign [RFC8366] format voucher artifacts. The public key, certificate, or certificate chain MUST be built in to the device as part of the firmware. It is RECOMMENDED that the manufacturer arrange for this signing key (or keys) to be escrowed according to typical software source code escrow practices [softwareescrow]. The MASA accepts voucher requests from Domain Owners according to an operational practice appropriate for the device. This can range from any domain owner (first-come first-served, on a TOFU-like basis), to full sales channel integration where Domain Owners need to be positively identified by TLS Client Certicate pinned, or HTTP Authentication process. The MASA creates signed voucher artifacts according to its internally defined policies. The MASA MUST operate an audit log for devices that is accessible. The audit log is designed to be easily cacheable and the MASA MAY find it useful to put this content on a CDN. Pritikin, et al. Expires 15 May 2021 [Page 76] Internet-Draft BRSKI November 2020 9.1.2. Domain Owner Operational Requirements The domain owner MUST operate an EST ([RFC7030]) server with the extensions described in this document. This is the JRC or Registrar. This JRC/EST server MUST announce itself using GRASP within the ACP. This EST server will typically reside with the Network Operations Center for the organization. The domain owner MAY operate an internal certificate authority (CA) that is seperate from the EST server, or it MAY combine all activities into a single device. The determination of the architecture depends upon the scale and resiliency requirements of the organization. Multiple JRC instances MAY be announced into the ACP from multiple locations to achieve an appropriate level of redundancy. In order to recognize which devices and which manufacturers are welcome on the domain owner's network, the domain owner SHOULD maintain a white list of manufacturers. This MAY extend to integration with purchasing departments to know the serial numbers of devices. The domain owner SHOULD use the resulting overlay ACP network to manage devices, replacing legacy out-of-band mechanisms. The domain owner SHOULD operate one or more EST servers which can be used to renew the domain certificates (LDevIDs) which are deployed to devices. These servers MAY be the same as the JRC, or MAY be a distinct set of devices, as approriate for resiliency. The organization MUST take appropriate precautions against loss of access to the certificate authority private key. Hardware security modules and/or secret splitting are appropriate. 9.1.3. Device Operational Requirements Devices MUST come with built-in trust anchors that permit the device to validate vouchers from the MASA. Device MUST come with (unique, per-device) IDevID certificates that include their serial numbers, and the MASA URL extension. Devices are expected to find Join Proxies using GRASP, and then connect to the JRC using the protocol described in this document. Pritikin, et al. Expires 15 May 2021 [Page 77] Internet-Draft BRSKI November 2020 Once a domain owner has been validated with the voucher, devices are expected to enroll into the domain using EST. Devices are then expected to form ACPs using IPsec over IPv6 Link-Local addresses as described in [I-D.ietf-anima-autonomic-control-plane]. Once a device has been enrolled it SHOULD listen for the address of the JRC using GRASP, and it SHOULD enable itself as a Join Proxy, and announce itself on all links/interfaces using GRASP DULL. Devices are expected to renew their certificates before they expire. 10. Privacy Considerations 10.1. MASA audit log The MASA audit log includes the domainID for each domain a voucher has been issued to. This information is closely related to the actual domain identity. A MASA may need additional defenses against Denial of Service attacks (Section 11.1), and this may involve collecting additional (unspecified here) information. This could provide sufficient information for the MASA service to build a detailed understanding the devices that have been provisioned within a domain. There are a number of design choices that mitigate this risk. The domain can maintain some privacy since it has not necessarily been authenticated and is not authoritatively bound to the supply chain. Additionally the domainID captures only the unauthenticated subject key identifier of the domain. A privacy sensitive domain could theoretically generate a new domainID for each device being deployed. Similarly a privacy sensitive domain would likely purchase devices that support proximity assertions from a manufacturer that does not require sales channel integrations. This would result in a significant level of privacy while maintaining the security characteristics provided by Registrar based audit log inspection. 10.2. What BRSKI-EST reveals During the provisional phase of the BRSKI-EST connection between the Pledge and the Registrar, each party reveals its certificates to each other. For the Pledge, this includes the serialNumber attribute, the MASA URL, and the identity that signed the IDevID certificate. TLS 1.2 reveals the certificate identities to on-path observers, including the Join Proxy. Pritikin, et al. Expires 15 May 2021 [Page 78] Internet-Draft BRSKI November 2020 TLS 1.3 reveals the certificate identities only to the end parties, but as the connection is provisional, an on-path attacker (MTIM) can see the certificates. This includes not just malicious attackers, but also Registrars that are visible to the Pledge, but which are not part of the intended domain. The certificate of the Registrar is rather arbitrary from the point of view of the BRSKI protocol. As no [RFC6125] validations are expected to be done, the contents could be easily pseudonymized. Any device that can see a join proxy would be able to connect to the Registrar and learn the identity of the network in question. Even if the contents of the certificate are pseudonymized, it would be possible to correlate different connections in different locations belong to the same entity. This is unlikely to present a significant privacy concern to ANIMA ACP uses of BRSKI, but may be a concern to other users of BRSKI. The certificate of the Pledge could be revealed by a malicious Join Proxy that performed a MITM attack on the provisional TLS connection. Such an attacker would be able to reveal the identity of the Pledge to third parties if it chose to so. Research into a mechanism to do multi-step, multi-party authenticated key agreement, incorporating some kind of zero-knowledge proof would be valuable. Such a mechanism would ideally avoid disclosing identities until pledge, registrar and MASA agree to the transaction. Such a mechanism would need to discover the location of the MASA without knowing the identity of the pledge, or the identity of the MASA. This part of the problem may be unsolveable. 10.3. What BRSKI-MASA reveals to the manufacturer With consumer-oriented devices, the "call-home" mechanism in IoT devices raises significant privacy concerns. See [livingwithIoT] and [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP) usage of BRSKI is not targeted at individual usage of IoT devices, but rather at the Enterprise and ISP creation of networks in a zero- touch fashion where the "call-home" represents a different class of privacy and lifecycle management concerns. Pritikin, et al. Expires 15 May 2021 [Page 79] Internet-Draft BRSKI November 2020 It needs to be re-iterated that the BRSKI-MASA mechanism only occurs once during the commissioning of the device. It is well defined, and although encrypted with TLS, it could in theory be made auditable as the contents are well defined. This connection does not occur when the device powers on or is restarted for normal routines. (It is conceivable, but remarkably unusual, that a device could be forced to go through a full factory reset during an exceptional firmware update situation, after which enrollment would have be repeated, and a new connection would occur) The BRSKI call-home mechanism is mediated via the owner's Registrar, and the information that is transmitted is directly auditable by the device owner. This is in stark contrast to many "call-home" protocols where the device autonomously calls home and uses an undocumented protocol. While the contents of the signed part of the pledge voucher request can not be changed, they are not encrypted at the registrar. The ability to audit the messages by the owner of the network is a mechanism to defend against exfiltration of data by a nefarious pledge. Both are, to re-iterate, encrypted by TLS while in transit. The BRSKI-MASA exchange reveals the following information to the manufacturer: * the identity of the device being enrolled. This is revealed by transmission of a signed voucher-request containing the serial- number. The manufacturer can usually link the serial number to a device model. * an identity of the domain owner in the form of the domain trust anchor. However, this is not a global PKI anchored name within the WebPKI, so this identity could be pseudonymous. If there is sales channel integration, then the MASA will have authenticated the domain owner, either via pinned certificate, or perhaps another HTTP authentication method, as per Section 5.5.4. * the time the device is activated, * the IP address of the domain Owner's Registrar. For ISPs and Enterprises, the IP address provides very clear geolocation of the owner. No amount of IP address privacy extensions ([RFC4941]) can do anything about this, as a simple whois lookup likely identifies the ISP or Enterprise from the upper bits anyway. A passive attacker who observes the connection definitely may conclude that the given enterprise/ISP is a customer of the particular equipment vendor. The precise model that is being enrolled will remain private. Pritikin, et al. Expires 15 May 2021 [Page 80] Internet-Draft BRSKI November 2020 Based upon the above information, the manufacturer is able to track a specific device from pseudonymous domain identity to the next pseudonymous domain identity. If there is sales-channel integration, then the identities are not pseudonymous. The manufacturer knows the IP address of the Registrar, but it can not see the IP address of the device itself. The manufacturer can not track the device to a detailed physical or network location, only to the location of the Registrar. That is likely to be at the Enterprise or ISPs headquarters. The above situation is to be distinguished from a residential/ individual person who registers a device from a manufacturer. Individuals do not tend to have multiple offices, and their registrar is likely on the same network as the device. A manufacturer that sells switching/routing products to enterprises should hardly be surprised if additional purchases switching/routing products are made. Deviations from a historical trend or an establish baseline would, however, be notable. The situation is not improved by the enterprise/ISP using anonymization services such as ToR [Dingledine2004], as a TLS 1.2 connection will reveal the ClientCertificate used, clearly identifying the enterprise/ISP involved. TLS 1.3 is better in this regard, but an active attacker can still discover the parties involved by performing a Man-In-The-Middle-Attack on the first attempt (breaking/killing it with a TCP RST), and then letting subsequent connection pass through. A manufacturer could attempt to mix the BRSKI-MASA traffic in with general traffic their site by hosting the MASA behind the same (set) of load balancers that the companies normal marketing site is hosted behind. This makes lots of sense from a straight capacity planning point of view as the same set of services (and the same set of Distributed Denial of Service mitigations) may be used. Unfortunately, as the BRSKI-MASA connections include TLS ClientCertificate exchanges, this may easily be observed in TLS 1.2, and a traffic analysis may reveal it even in TLS 1.3. This does not make such a plan irrelevant. There may be other organizational reasons to keep the marketing site (which is often subject to frequent re-designs, outsourcing, etc.) separate from the MASA, which may need to operate reliably for decades. 10.4. Manufacturers and Used or Stolen Equipment As explained above, the manufacturer receives information each time that a device which is in factory-default mode does a zero-touch bootstrap, and attempts to enroll into a domain owner's registrar. Pritikin, et al. Expires 15 May 2021 [Page 81] Internet-Draft BRSKI November 2020 The manufacturer is therefore in a position to decline to issue a voucher if it detects that the new owner is not the same as the previous owner. 1. This can be seen as a feature if the equipment is believed to have been stolen. If the legitimate owner notifies the manufacturer of the theft, then when the new owner brings the device up, if they use the zero-touch mechanism, the new (illegitimate) owner reveals their location and identity. 2. In the case of Used equipment, the initial owner could inform the manufacturer of the sale, or the manufacturer may just permit resales unless told otherwise. In which case, the transfer of ownership simply occurs. 3. A manufacturer could however decide not to issue a new voucher in response to a transfer of ownership. This is essentially the same as the stolen case, with the manufacturer having decided that the sale was not legitimate. 4. There is a fourth case, if the manufacturer is providing protection against stolen devices. The manufacturer then has a responsibility to protect the legitimate owner against fraudulent claims that the equipment was stolen. In the absence of such manufacturer protection, such a claim would cause the manufacturer to refuse to issue a new voucher. Should the device go through a deep factory reset (for instance, replacement of a damaged main board component, the device would not bootstrap. 5. Finally, there is a fifth case: the manufacturer has decided to end-of-line the device, or the owner has not paid a yearly support amount, and the manufacturer refuses to issue new vouchers at that point. This last case is not new to the industry: many license systems are already deployed that have significantly worse effect. This section has outlined five situations in which a manufacturer could use the voucher system to enforce what are clearly license terms. A manufacturer that attempted to enforce license terms via vouchers would find it rather ineffective as the terms would only be enforced when the device is enrolled, and this is not (to repeat), a daily or even monthly occurrence. Pritikin, et al. Expires 15 May 2021 [Page 82] Internet-Draft BRSKI November 2020 10.5. Manufacturers and Grey market equipment Manufacturers of devices often sell different products into different regional markets. Which product is available in which market can be driven by price differentials, support issues (some markets may require manuals and tech-support to be done in the local language), government export regulation (such as whether strong crypto is permitted to be exported, or permitted to be used in a particular market). When an domain owner obtains a device from a different market (they can be new) and transfers it to a different location, this is called a Grey Market. A manufacturer could decide not to issue a voucher to an enterprise/ ISP based upon their location. There are a number of ways which this could be determined: from the geolocation of the registrar, from sales channel knowledge about the customer, and what products are (un-)available in that market. If the device has a GPS the coordinates of the device could even be placed into an extension of the voucher. The above actions are not illegal, and not new. Many manufacturers have shipped crypto-weak (exportable) versions of firmware as the default on equipment for decades. The first task of an enterprise/ ISP has always been to login to a manufacturer system, show one's "entitlement" (country information, proof that support payments have been made), and receive either a new updated firmware, or a license key that will activate the correct firmware. BRSKI permits the above process to automated (in an autonomic fashion), and therefore perhaps encourages this kind of differentiation by reducing the cost of doing it. An issue that manufacturers will need to deal with in the above automated process is when a device is shipped to one country with one set of rules (or laws or entitlements), but the domain registry is in another one. Which rules apply is something will have to be worked out: the manufacturer could come to believe they are dealing with Grey market equipment, when it is simply dealing with a global enterprise. 10.6. Some mitigations for meddling by manufacturers The most obvious mitigation is not to buy the product. Pick manufacturers that are up-front about their policies, who do not change them gratuitously. Pritikin, et al. Expires 15 May 2021 [Page 83] Internet-Draft BRSKI November 2020 Section 7.4.3 describes some ways in which a manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension. There are a variety of mechanism, and some may take a substantial amount of work to get exactly correct. These mechanisms do not change the flow of the protocol described here, but rather allow the starting trust assumptions to be changed. This is an area for future standardization work. Replacement of the voucher validation anchors (usually pointing to the original manufacturer's MASA) with those of the new owner permits the new owner to issue vouchers to subsequent owners. This would be done by having the selling (old) owner to run a MASA. The BRSKI protocol depends upon a trust anchor on the device and an identity on the device. Management of these entities facilitates a few new operational modes without making any changes to the BRSKI protocol. Those modes include: offline modes where the domain owner operates an internal MASA for all devices, resell modes where the first domain owner becomes the MASA for the next (resold-to) domain owner, and services where an aggregator acquires a large variety of devices, and then acts as a pseudonymized MASA for a variety of devices from a variety of manufacturers. Although replacement of the IDevID is not required for all modes described above, a manufacturers could support such a thing. Some may wish to consider replacement of the IDevID as an indication that the device's warrantee is terminated. For others, the privacy requirements of some deployments might consider this a standard operating practice. As discussed at the end of Section 5.8.1, new work could be done to use a distributed consensus technology for the audit log. This would permit the audit log to continue to be useful, even when there is a chain of MASA due to changes of ownership. 10.7. Death of a manufacturer A common concern has been that a manufacturer could go out of business, leaving owners of devices unable to get new vouchers for existing products. Said products might have been previously deployed, but need to be re-initialized, they might have been purchased used, or they might have kept in a warehouse as long-term spares. The MASA was named the Manufacturer *Authorized* Signing Authority to emphasize that it need not be the manufacturer itself that performs this. It is anticipated that specialist service providers will come Pritikin, et al. Expires 15 May 2021 [Page 84] Internet-Draft BRSKI November 2020 to exist that deal with the creation of vouchers in much the same way that many companies have outsourced email, advertising and janitorial services. Further, it is expected that as part of any service agreement that the manufacturer would arrange to escrow appropriate private keys such that a MASA service could be provided by a third party. This has routinely been done for source code for decades. 11. Security Considerations This document details a protocol for bootstrapping that balances operational concerns against security concerns. As detailed in the introduction, and touched on again in Section 7, the protocol allows for reduced security modes. These attempt to deliver additional control to the local administrator and owner in cases where less security provides operational benefits. This section goes into more detail about a variety of specific considerations. To facilitate logging and administrative oversight, in addition to triggering Registrar verification of MASA logs, the pledge reports on voucher parsing status to the registrar. In the case of a failure, this information is informative to a potentially malicious registrar. This is mandated anyway because of the operational benefits of an informed administrator in cases where the failure is indicative of a problem. The registrar is RECOMMENDED to verify MASA logs if voucher status telemetry is not received. To facilitate truly limited clients EST RFC7030 section 3.3.2 requirements that the client MUST support a client authentication model have been reduced in Section 7 to a statement that the registrar "MAY" choose to accept devices that fail cryptographic authentication. This reflects current (poor) practices in shipping devices without a cryptographic identity that are NOT RECOMMENDED. During the provisional period of the connection the pledge MUST treat all HTTP header and content data as untrusted data. HTTP libraries are regularly exposed to non-secured HTTP traffic: mature libraries should not have any problems. Pledges might chose to engage in protocol operations with multiple discovered registrars in parallel. As noted above they will only do so with distinct nonce values, but the end result could be multiple vouchers issued from the MASA if all registrars attempt to claim the device. This is not a failure and the pledge choses whichever voucher to accept based on internal logic. The registrars verifying log information will see multiple entries and take this into account for their analytics purposes. Pritikin, et al. Expires 15 May 2021 [Page 85] Internet-Draft BRSKI November 2020 11.1. Denial of Service (DoS) against MASA There are uses cases where the MASA could be unavailable or uncooperative to the Registrar. They include active DoS attacks, planned and unplanned network partitions, changes to MASA policy, or other instances where MASA policy rejects a claim. These introduce an operational risk to the Registrar owner in that MASA behavior might limit the ability to bootstrap a pledge device. For example this might be an issue during disaster recovery. This risk can be mitigated by Registrars that request and maintain long term copies of "nonceless" vouchers. In that way they are guaranteed to be able to bootstrap their devices. The issuance of nonceless vouchers themselves creates a security concern. If the Registrar of a previous domain can intercept protocol communications then it can use a previously issued nonceless voucher to establish management control of a pledge device even after having sold it. This risk is mitigated by recording the issuance of such vouchers in the MASA audit log that is verified by the subsequent Registrar and by Pledges only bootstrapping when in a factory default state. This reflects a balance between enabling MASA independence during future bootstrapping and the security of bootstrapping itself. Registrar control over requesting and auditing nonceless vouchers allows device owners to choose an appropriate balance. The MASA is exposed to DoS attacks wherein attackers claim an unbounded number of devices. Ensuring a registrar is representative of a valid manufacturer customer, even without validating ownership of specific pledge devices, helps to mitigate this. Pledge signatures on the pledge voucher-request, as forwarded by the registrar in the prior-signed-voucher-request field of the registrar voucher-request, significantly reduce this risk by ensuring the MASA can confirm proximity between the pledge and the registrar making the request. Supply chain integration ("know your customer") is an additional step that MASA providers and device vendors can explore. 11.2. DomainID must be resistant to second-preimage attacks The domainID is used as the reference in the audit log to the domain. The domainID is expected to be calculated by a hash that is resistant to a second-preimage attack. Such an attack would allow a second registrar to create audit log entries that are fake. Pritikin, et al. Expires 15 May 2021 [Page 86] Internet-Draft BRSKI November 2020 11.3. Availability of good random numbers The nonce used by the Pledge in the voucher-request SHOULD be generated by a Strong Cryptographic Sequence ([RFC4086] section 6.2). TLS has a similar requirement. In particular implementations should pay attention to the advance in [RFC4086] section 3, particularly section 3.4. The random seed used by a device at boot MUST be unique across all devices and all bootstraps. Resetting a device to factory default state does not obviate this requirement. 11.4. Freshness in Voucher-Requests A concern has been raised that the pledge voucher-request should contain some content (a nonce) provided by the registrar and/or MASA in order for those actors to verify that the pledge voucher-request is fresh. There are a number of operational problems with getting a nonce from the MASA to the pledge. It is somewhat easier to collect a random value from the registrar, but as the registrar is not yet vouched for, such a registrar nonce has little value. There are privacy and logistical challenges to addressing these operational issues, so if such a thing were to be considered, it would have to provide some clear value. This section examines the impacts of not having a fresh pledge voucher-request. Because the registrar authenticates the pledge, a full Man-in-the- Middle attack is not possible, despite the provisional TLS authentication by the pledge (see Section 5.) Instead we examine the case of a fake registrar (Rm) that communicates with the pledge in parallel or in close time proximity with the intended registrar. (This scenario is intentionally supported as described in Section 4.1.) The fake registrar (Rm) can obtain a voucher signed by the MASA either directly or through arbitrary intermediaries. Assuming that the MASA accepts the registrar voucher-request (either because Rm is collaborating with a legitimate registrar according to supply chain information, or because the MASA is in audit-log only mode), then a voucher linking the pledge to the registrar Rm is issued. Such a voucher, when passed back to the pledge, would link the pledge to registrar Rm, and would permit the pledge to end the provisional state. It now trusts Rm and, if it has any security vulnerabilities leveragable by an Rm with full administrative control, can be assumed to be a threat against the intended registrar. Pritikin, et al. Expires 15 May 2021 [Page 87] Internet-Draft BRSKI November 2020 This flow is mitigated by the intended registrar verifying the audit logs available from the MASA as described in Section 5.8. Rm might chose to collect a voucher-request but wait until after the intended registrar completes the authorization process before submitting it. This pledge voucher-request would be 'stale' in that it has a nonce that no longer matches the internal state of the pledge. In order to successfully use any resulting voucher the Rm would need to remove the stale nonce or anticipate the pledge's future nonce state. Reducing the possibility of this is why the pledge is mandated to generate a strong random or pseudo-random number nonce. Additionally, in order to successfully use the resulting voucher the Rm would have to attack the pledge and return it to a bootstrapping enabled state. This would require wiping the pledge of current configuration and triggering a re-bootstrapping of the pledge. This is no more likely than simply taking control of the pledge directly but if this is a consideration the target network is RECOMMENDED to take the following steps: * Ongoing network monitoring for unexpected bootstrapping attempts by pledges. * Retrieval and examination of MASA log information upon the occurrence of any such unexpected events. Rm will be listed in the logs along with nonce information for analysis. 11.5. Trusting manufacturers The BRSKI extensions to EST permit a new pledge to be completely configured with domain specific trust anchors. The link from built- in manufacturer-provided trust anchors to domain-specific trust anchors is mediated by the signed voucher artifact. If the manufacturer's IDevID signing key is not properly validated, then there is a risk that the network will accept a pledge that should not be a member of the network. As the address of the manufacturer's MASA is provided in the IDevID using the extension from Section 2.3, the malicious pledge will have no problem collaborating with it's MASA to produce a completely valid voucher. BRSKI does not, however, fundamentally change the trust model from domain owner to manufacturer. Assuming that the pledge used its IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs to trust the manufacturer. Establishing this trust between domain and manufacturer is outside the scope of BRSKI. There are a number of mechanisms that can adopted including: Pritikin, et al. Expires 15 May 2021 [Page 88] Internet-Draft BRSKI November 2020 * Manually configuring each manufacturer's trust anchor. * A Trust-On-First-Use (TOFU) mechanism. A human would be queried upon seeing a manufacturer's trust anchor for the first time, and then the trust anchor would be installed to the trusted store. There are risks with this; even if the key to name mapping is validated using something like the WebPKI, there remains the possibility that the name is a look alike: e.g, dem0.example. vs demO.example. * scanning the trust anchor from a QR code that came with the packaging (this is really a manual TOFU mechanism) * some sales integration process where trust anchors are provided as part of the sales process, probably included in a digital packing "slip", or a sales invoice. * consortium membership, where all manufacturers of a particular device category (e.g, a light bulb, or a cable-modem) are signed by an certificate authority specifically for this. This is done by CableLabs today. It is used for authentication and authorization as part of TR-79: [docsisroot] and [TR069]. The existing WebPKI provides a reasonable anchor between manufacturer name and public key. It authenticates the key. It does not provide a reasonable authorization for the manufacturer, so it is not directly useable on it's own. 11.6. Manufacturer Maintenance of trust anchors BRSKI depends upon the manufacturer building in trust anchors to the pledge device. The voucher artifact which is signed by the MASA will be validated by the pledge using that anchor. This implies that the manufacturer needs to maintain access to a signing key that the pledge can validate. The manufacturer will need to maintain the ability to make signatures that can be validated for the lifetime that the device could be onboarded. Whether this onboarding lifetime is less than the device lifetime depends upon how the device is used. An inventory of devices kept in a warehouse as spares might not be onboarded for many decades. Pritikin, et al. Expires 15 May 2021 [Page 89] Internet-Draft BRSKI November 2020 There are good cryptographic hygiene reasons why a manufacturer would not want to maintain access to a private key for many decades. A manufacturer in that situation can leverage a long-term certificate authority anchor, built-in to the pledge, and then a certificate chain may be incorporated using the normal CMS certificate set. This may increase the size of the voucher artifacts, but that is not a significant issues in non-constrained environments. There are a few other operational variations that manufacturers could consider. For instance, there is no reason that every device need have the same set of trust anchors pre-installed. Devices built in different factories, or on different days, or any other consideration could have different trust anchors built in, and the record of which batch the device is in would be recorded in the asset database. The manufacturer would then know which anchor to sign an artifact against. Aside from the concern about long-term access to private keys, a major limiting factor for the shelf-life of many devices will be the age of the cryptographic algorithms included. A device produced in 2019 will have hardware and software capable of validating algorithms common in 2019, and will have no defense against attacks (both quantum and von-neuman brute force attacks) which have not yet been invented. This concern is orthogonal to the concern about access to private keys, but this concern likely dominates and limits the lifespan of a device in a warehouse. If any update to firmware to support new cryptographic mechanism were possible (while the device was in a warehouse), updates to trust anchors would also be done at the same time. The set of standard operating procedures for maintaining high value private keys is well documented. For instance, the WebPKI provides a number of options for audits at [cabforumaudit], and the DNSSEC root operations are well documented at [dnssecroot]. It is not clear if Manufacturers will take this level of precaution, or how strong the economic incentives are to maintain an appropriate level of security. This next section examines the risk due to a compromised manufacturer IDevID signing key. This is followed by examination of the risk due to a compromised MASA key. The third section sections below examines the situation where MASA web server itself is under attacker control, but that the MASA signing key itself is safe in a not-directly connected hardware module. Pritikin, et al. Expires 15 May 2021 [Page 90] Internet-Draft BRSKI November 2020 11.6.1. Compromise of Manufacturer IDevID signing keys An attacker that has access to the key that the manufacturer uses to sign IDevID certificates can create counterfeit devices. Such devices can claim to be from a particular manufacturer, but be entirely different devices: Trojan horses in effect. As the attacker controls the MASA URL in the certificate, the registrar can be convinced to talk to the attackers' MASA. The Registrar does not need to be in any kind of promiscuous mode to be vulnerable. In addition to creating fake devices, the attacker may also be able to issue revocations for existing certificates if the IDevID certificate process relies upon CRL lists that are distributed. There does not otherwise seem to be any risk from this compromise to devices which are already deployed, or which are sitting locally in boxes waiting for deployment (local spares). The issue is that operators will be unable to trust devices which have been in an uncontrolled warehouse as they do not know if those are real devices. 11.6.2. Compromise of MASA signing keys There are two periods of time in which to consider: when the MASA key has fallen into the hands of an attacker, and after the MASA recognizes that the key has been compromised. 11.6.2.1. Attacker opportunties with compromised MASA key An attacker that has access to the MASA signing key could create vouchers. These vouchers could be for existing deployed devices, or for devices which are still in a warehouse. In order to exploit these vouchers two things need to occur: the device has to go through a factory default boot cycle, and the registrar has to be convinced to contact the attacker's MASA. If the attacker controls a Registrar which is visible to the device, then there is no difficulty in delivery of the false voucher. A possible practical example of an attack like this would be in a data center, at an ISP peering point (whether a public IX, or a private peering point). In such a situation, there are already cables attached to the equipment that lead to other devices (the peers at the IX), and through those links, the false voucher could be delivered. The difficult part would be get the device put through a factory reset. This might be accomplished through social engineering of data center staff. Most locked cages have ventilation holes, and possibly a long "paperclip" could reach through to depress a factory Pritikin, et al. Expires 15 May 2021 [Page 91] Internet-Draft BRSKI November 2020 reset button. Once such a piece of ISP equipment has been compromised, it could be used to compromise equipment that was connected to (through long haul links even), assuming that those pieces of equipment could also be forced through a factory reset. The above scenario seems rather unlikely as it requires some element of physical access; but were there a remote exploit that did not cause a direct breach, but rather a fault that resulted in a factory reset, this could provide a reasonable path. The above deals with ANI uses of BRSKI. For cases where 802.11 or 802.15.4 is involved, the need to connect directly to the device is eliminated, but the need to do a factory reset is not. Physical possession of the device is not required as above, provided that there is some way to force a factory reset. With some consumers devices with low overall implementation quality, the end users might be familiar with needing to reset the device regularly. The authors are unable to come up with an attack scenario where a compromised voucher signature enables an attacker to introduce a compromised pledge into an existing operator's network. This is the case because the operator controls the communication between Registrar and MASA, and there is no opportunity to introduce the fake voucher through that conduit. 11.6.2.2. Risks after key compromise is known Once the operator of the MASA realizes that the voucher signing key has been compromised it has to do a few things. First, it MUST issue a firmware update to all devices that had that key as a trust anchor, such that they will no longer trust vouchers from that key. This will affect devices in the field which are operating, but those devices, being in operation, are not performing onboarding operations, so this is not a critical patch. Devices in boxes (in warehouses) are vulnerable, and remain vulnerable until patched. An operator would be prudent to unbox the devices, onboard them in a safe environment, and then perform firmware updates. This does not have to be done by the end-operator; it could be done by a distributor that stores the spares. A recommended practice for high value devices (which typically have a <4hr service window) may be to validate the device operation on a regular basis anyway. Pritikin, et al. Expires 15 May 2021 [Page 92] Internet-Draft BRSKI November 2020 If the onboarding process includes attestations about firmware versions, then through that process the operator would be advised to upgrade the firmware before going into production. Unfortunately, this does not help against situations where the attacker operates their own Registrar (as listed above). [RFC8366] section 6.1 explains the need for short-lived vouchers. The nonce guarantees freshness, and the short-lived nature of the voucher means that the window to deliver a fake voucher is very short. A nonceless, long-lived voucher would be the only option for the attacker, and devices in the warehouse would be vulnerable to such a thing. A key operational recommendation is for manufacturers to sign nonceless, long-lived vouchers with a different key that they sign short-lived vouchers. That key needs significantly better protection. If both keys come from a common trust-anchor (the manufacturer's CA), then a compromise of the manufacturer's CA would compromise both keys. Such a compromise of the manufacturer's CA likely compromises all keys outlined in this section. 11.6.3. Compromise of MASA web service An attacker that takes over the MASA web service has a number of attacks. The most obvious one is simply to take the database listing customers and devices and to sell this data to other attackers who will now know where to find potentially vulnerable devices. The second most obvious thing that the attacker can do is to kill the service, or make it operate unreliably, making customers frustrated. This could have a serious affect on ability to deploy new services by customers, and would be a significant issue during disaster recovery. While the compromise of the MASA web service may lead to the compromise of the MASA voucher signing key, if the signing occurs offboard (such as in a hardware signing module, HSM), then the key may well be safe, but control over it resides with the attacker. Such an attacker can issue vouchers for any device presently in service. Said device still needs to be convinced to do through a factory reset process before an attack. If the attacker has access to a key that is trusted for long-lived nonceless vouchers, then they could issue vouchers for devices which are not yet in service. This attack may be very hard to verify and as it would involve doing firmware updates on every device in warehouses (a potentially ruinously expensive process), a manufacturer might be reluctant to admit this possibility. Pritikin, et al. Expires 15 May 2021 [Page 93] Internet-Draft BRSKI November 2020 11.7. YANG Module Security Considerations As described in the Security Considerations section of [RFC8366] (section 7.4), the YANG module specified in this document defines the schema for data that is subsequently encapsulated by a CMS signed- data content type, as described in Section 5 of [RFC5652]. As such, all of the YANG modeled data is protected from modification. The use of YANG to define data structures, via the 'yang-data' statement, is relatively new and distinct from the traditional use of YANG to define an API accessed by network management protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason, these guidelines do not follow template described by Section 3.7 of [RFC8407]. 12. Acknowledgements We would like to thank the various reviewers for their input, in particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Tom Petch, Markus Stenberg, Peter van der Stok, and Thomas Werner Significant reviews were done by Jari Arko, Christian Huitema and Russ Housley. Henk Birkholz contributed the CDDL for the audit log response. This document started it's life as a two-page idea from Steinthor Bjarnason. In addition, significant review comments were received by many IESG members, including Adam Roach, Alexey Melnikov, Alissa Cooper, Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. 13. References 13.1. Normative References [I-D.ietf-anima-autonomic-control-plane] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", Work in Progress, Internet-Draft, draft-ietf-anima-autonomic-control-plane-30, 30 October 2020, . [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", Work in Progress, Pritikin, et al. Expires 15 May 2021 [Page 94] Internet-Draft BRSKI November 2020 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, . [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, . [ITU.X690.1994] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. [REST] Fielding, R.F., "Architectural Styles and the Design of Network-based Software Architectures", 2000, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . Pritikin, et al. Expires 15 May 2021 [Page 95] Internet-Draft BRSKI November 2020 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, DOI 10.17487/RFC4519, June 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . Pritikin, et al. Expires 15 May 2021 [Page 96] Internet-Draft BRSKI November 2020 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [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, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Pritikin, et al. Expires 15 May 2021 [Page 97] Internet-Draft BRSKI November 2020 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, . [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)", RFC 8368, DOI 10.17487/RFC8368, May 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . 13.2. Informative References [brewski] "Urban Dictionary: Brewski", October 2019, . [cabforumaudit] "Information for Auditors and Assessors", August 2019, . [Dingledine2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", 2004, . Pritikin, et al. Expires 15 May 2021 [Page 98] Internet-Draft BRSKI November 2020 [dnssecroot] "DNSSEC Practice Statement for the Root Zone ZSK Operator", December 2017, . [docsisroot] "CableLabs Digital Certificate Issuance Service", February 2018, . [I-D.ietf-ace-coap-est] Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST over secure CoAP (EST-coaps)", Work in Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 January 2020, . [I-D.ietf-anima-constrained-voucher] Richardson, M., Stok, P., and P. Kampanakis, "Constrained Voucher Artifacts for Bootstrapping Protocols", Work in Progress, Internet-Draft, draft-ietf-anima-constrained- voucher-09, 2 November 2020, . [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., and J. Nobre, "A Reference Model for Autonomic Networking", Work in Progress, Internet-Draft, draft-ietf- anima-reference-model-10, 22 November 2018, . [I-D.ietf-netconf-keystore] Watsen, K., "A YANG Data Model for a Keystore", Work in Progress, Internet-Draft, draft-ietf-netconf-keystore-20, 20 August 2020, . [I-D.richardson-anima-state-for-joinrouter] Richardson, M., "Considerations for stateful vs stateless join router in ANIMA bootstrap", Work in Progress, Internet-Draft, draft-richardson-anima-state-for- joinrouter-03, 22 September 2020, . Pritikin, et al. Expires 15 May 2021 [Page 99] Internet-Draft BRSKI November 2020 [imprinting] "Wikipedia article: Imprinting", July 2015, . [IoTstrangeThings] "IoT of toys stranger than fiction: Cybersecurity and data privacy update (accessed 2018-12-02)", March 2017, . [livingwithIoT] "What is it actually like to live in a house filled with IoT devices? (accessed 2018-12-02)", February 2018, . [minerva] Richardsdon, M., "Minerva reference implementation for BRSKI", 2020, . [minervagithub] Richardsdon, M., "GITHUB hosting of Minerva reference code", 2020, . [openssl] "OpenSSL X509 utility", September 2019, . [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, . [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . Pritikin, et al. Expires 15 May 2021 [Page 100] Internet-Draft BRSKI November 2020 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [slowloris] "Slowloris (computer security)", February 2019, . [softwareescrow] "Wikipedia article: Software Escrow", October 2019, . [Stajano99theresurrecting] Stajano, F. and R. Anderson, "The resurrecting duckling: security issues for ad-hoc wireless networks", 1999, . [TR069] "TR-69: CPE WAN Management Protocol", February 2018, . Pritikin, et al. Expires 15 May 2021 [Page 101] Internet-Draft BRSKI November 2020 [W3C.WD-capability-urls-20140218] Tennison, J., "Good Practices for Capability URLs", World Wide Web Consortium WD WD-capability-urls-20140218, 18 February 2014, . Appendix A. IPv4 and non-ANI operations The specification of BRSKI in Section 4 intentionally only covers the mechanisms for an IPv6 pledge using Link-Local addresses. This section describes non-normative extensions that can be used in other environments. A.1. IPv4 Link Local addresses Instead of an IPv6 link-local address, an IPv4 address may be generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local Addresses. In the case that an IPv4 Link-Local address is formed, then the bootstrap process would continue as in the IPv6 case by looking for a (circuit) proxy. A.2. Use of DHCPv4 The Pledge MAY obtain an IP address via DHCP [RFC2131]. The DHCP provided parameters for the Domain Name System can be used to perform DNS operations if all local discovery attempts fail. Appendix B. mDNS / DNSSD proxy discovery options Pledge discovery of the proxy (Section 4.1) MAY be performed with DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to discover the proxy at "_brski-proxy._tcp.local.". Proxy discovery of the registrar (Section 4.3) MAY be performed with DNS-based Service Discovery over Multicast DNS to discover registrars by searching for the service "_brski-registrar._tcp.local.". To prevent unaccceptable levels of network traffic, when using mDNS, the congestion avoidance mechanisms specified in [RFC6762] section 7 MUST be followed. The pledge SHOULD listen for an unsolicited broadcast response as described in [RFC6762]. This allows devices to avoid announcing their presence via mDNS broadcasts and instead silently join a network by watching for periodic unsolicited broadcast responses. Pritikin, et al. Expires 15 May 2021 [Page 102] Internet-Draft BRSKI November 2020 Discovery of registrar MAY also be performed with DNS-based service discovery by searching for the service "_brski- registrar._tcp.example.com". In this case the domain "example.com" is discovered as described in [RFC6763] section 11 (Appendix A.2 suggests the use of DHCP parameters). If no local proxy or registrar service is located using the GRASP mechanisms or the above mentioned DNS-based Service Discovery methods, the pledge MAY contact a well known manufacturer provided bootstrapping server by performing a DNS lookup using a well known URI such as "brski-registrar.manufacturer.example.com". The details of the URI are manufacturer specific. Manufacturers that leverage this method on the pledge are responsible for providing the registrar service. Also see Section 2.7. The current DNS services returned during each query are maintained until bootstrapping is completed. If bootstrapping fails and the pledge returns to the Discovery state, it picks up where it left off and continues attempting bootstrapping. For example, if the first Multicast DNS _bootstrapks._tcp.local response doesn't work then the second and third responses are tried. If these fail the pledge moves on to normal DNS-based Service Discovery. Appendix C. Example Vouchers Three entities are involved in a voucher: the MASA issues (signs) it, the registrar's public key is mentioned in the voucher, and the pledge validates it. In order to provide reproduceable examples the public and private keys for an example MASA and registrar are first listed. The keys come from an open source reference implementation of BRSKI, called "Minerva" [minerva]. It is available on github [minervagithub]. The keys presented here are used in the unit and integration tests. The MASA code is called "highway", the Registrar code is called "fountain", and the example client is called "reach". The public key components of each are presented as both base64 certificates, as well as being decoded by openssl's x509 utility so that the extensions can be seen. This was version 1.1.1c of the [openssl] library and utility. C.1. Keys involved The Manufacturer has a Certificate Authority that signs the pledge's IDevID. In addition the Manufacturer's signing authority (the MASA) signs the vouchers, and that certificate must distributed to the devices at manufacturing time so that vouchers can be validated. Pritikin, et al. Expires 15 May 2021 [Page 103] Internet-Draft BRSKI November 2020 C.1.1. Manufacturer Certificate Authority for IDevID signatures This private key is Certificate Authority that signs IDevID certificates: file "vendor.key" -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDCAYkoLW1IEA5SKKhMMdkTK7sJxk5ybKqYq9Yr5aR7tNwqXyLGS7z8G 8S4w/UJ58BqgBwYFK4EEACKhZANiAAQu5/yktJbFLjMC87h7b+yTreFuF8GwewKH L4mS0r0dVAQubqDUQcTrjvpXrXCpTojiLCzgp8fzkcUDkZ9LD/M90LDipiLNIOkP juF8QkoAbT8pMrY83MS8y76wZ7AalNQ= -----END EC PRIVATE KEY----- This public key validates IDevID certificates: file: examples/vendor.key file "vendor.cert" Certificate: Data: Version: 3 (0x2) Serial Number: 519772114 (0x1efb17d2) Signature Algorithm: ecdsa-with-SHA256 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA Validity Not Before: Feb 12 22:22:21 2019 GMT Not After : Feb 11 22:22:21 2021 GMT Subject: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:2e:e7:fc:a4:b4:96:c5:2e:33:02:f3:b8:7b:6f: ec:93:ad:e1:6e:17:c1:b0:7b:02:87:2f:89:92:d2: bd:1d:54:04:2e:6e:a0:d4:41:c4:eb:8e:fa:57:ad: 70:a9:4e:88:e2:2c:2c:e0:a7:c7:f3:91:c5:03:91: 9f:4b:0f:f3:3d:d0:b0:e2:a6:22:cd:20:e9:0f:8e: e1:7c:42:4a:00:6d:3f:29:32:b6:3c:dc:c4:bc:cb: be:b0:67:b0:1a:94:d4 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: Pritikin, et al. Expires 15 May 2021 [Page 104] Internet-Draft BRSKI November 2020 5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76:8C:53:8A:08 X509v3 Authority Key Identifier: keyid:5E:0C:A9:52:5A:8C:DF:A9:0F:03:14:E9:96:F1:80:76:8C:53:8A:08 Signature Algorithm: ecdsa-with-SHA256 30:65:02:30:5f:21:fd:c6:ab:d6:94:a6:cd:ca:37:2c:81:33: 87:fe:7b:e1:b5:1a:e8:6c:05:43:a6:8b:4e:22:b5:55:e9:48: 0c:b5:97:f3:c9:1a:65:d9:97:4b:f0:21:86:0d:cb:26:02:31: 00:e3:2d:0d:08:49:4d:a3:f5:dc:57:1f:a7:13:26:a4:e0:d6: 3a:c2:d5:4a:50:83:62:26:2e:79:2b:d0:a5:ee:66:d5:bf:16: 9a:33:75:b4:d1:8d:ba:d3:50:77:6b:92:df -----BEGIN CERTIFICATE----- MIICTDCCAdKgAwIBAgIEHvsX0jAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjIyMVoX DTIxMDIxMTIyMjIyMVowXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l eGFtcGxlLmNvbSBDQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABC7n/KS0lsUuMwLz uHtv7JOt4W4XwbB7AocviZLSvR1UBC5uoNRBxOuO+letcKlOiOIsLOCnx/ORxQOR n0sP8z3QsOKmIs0g6Q+O4XxCSgBtPykytjzcxLzLvrBnsBqU1KNjMGEwDwYDVR0T AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFF4MqVJajN+pDwMU 6ZbxgHaMU4oIMB8GA1UdIwQYMBaAFF4MqVJajN+pDwMU6ZbxgHaMU4oIMAoGCCqG SM49BAMCA2gAMGUCMF8h/car1pSmzco3LIEzh/574bUa6GwFQ6aLTiK1VelIDLWX 88kaZdmXS/Ahhg3LJgIxAOMtDQhJTaP13FcfpxMmpODWOsLVSlCDYiYueSvQpe5m 1b8WmjN1tNGNutNQd2uS3w== -----END CERTIFICATE----- C.1.2. MASA key pair for voucher signatures The MASA is the Manufacturer Authorized Signing Authority. This keypair signs vouchers. An example TLS certificate Section 5.4 HTTP authentication is not provided as it is a common form. This private key signs the vouchers which are presented below: file "masa.key" -----BEGIN EC PRIVATE KEY----- MHcCAQEEIFhdd0eDdzip67kXx72K+KHGJQYJHNy8pkiLJ6CcvxMGoAoGCCqGSM49 AwEHoUQDQgAEqgQVo0S54kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+ gqi4tMFfSJ0iEwt8kszfWXK4rLgJS2mnpQ== -----END EC PRIVATE KEY----- This public key validates vouchers, and it has been signed by the CA above: file: examples/masa.key Pritikin, et al. Expires 15 May 2021 [Page 105] Internet-Draft BRSKI November 2020 file "masa.cert" Certificate: Data: Version: 3 (0x2) Serial Number: 463036244 (0x1b995f54) Signature Algorithm: ecdsa-with-SHA256 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA Validity Not Before: Feb 12 22:22:41 2019 GMT Not After : Feb 11 22:22:41 2021 GMT Subject: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com MASA Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:aa:04:15:a3:44:b9:e2:44:f8:c9:f9:1b:07:1b: a6:74:73:9c:1e:ba:6c:a9:b3:a9:30:a9:a2:32:59: f7:a0:1d:47:01:6d:b9:30:95:7e:82:a8:b8:b4:c1: 5f:48:9d:22:13:0b:7c:92:cc:df:59:72:b8:ac:b8: 09:4b:69:a7:a5 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: ecdsa-with-SHA256 30:66:02:31:00:bd:55:e5:9b:0e:fb:fc:5e:95:29:e3:81:b3: 15:35:aa:93:18:a2:04:be:44:72:b2:51:7d:4d:6d:eb:d1:d5: c1:10:3a:b2:39:7b:57:3f:c5:cc:b0:a3:0e:e7:99:46:ba:02: 31:00:f6:7f:44:7d:b7:14:fa:d1:67:6a:d4:11:c3:4b:ae:e6: fb:9a:98:56:fa:85:21:2e:5c:48:4c:f0:3f:f2:9b:3f:ae:88: 20:a7:ae:f9:72:ff:5b:f9:78:68:cf:0f:48:c9 -----BEGIN CERTIFICATE----- MIIB3zCCAWSgAwIBAgIEG5lfVDAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMB4XDTE5MDIxMjIyMjI0MVoX DTIxMDIxMTIyMjI0MVowXzEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRh cmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJjAkBgNVBAMMHWhpZ2h3YXktdGVzdC5l eGFtcGxlLmNvbSBNQVNBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqgQVo0S5 4kT4yfkbBxumdHOcHrpsqbOpMKmiMln3oB1HAW25MJV+gqi4tMFfSJ0iEwt8kszf WXK4rLgJS2mnpaMQMA4wDAYDVR0TAQH/BAIwADAKBggqhkjOPQQDAgNpADBmAjEA vVXlmw77/F6VKeOBsxU1qpMYogS+RHKyUX1NbevR1cEQOrI5e1c/xcywow7nmUa6 AjEA9n9EfbcU+tFnatQRw0uu5vuamFb6hSEuXEhM8D/ymz+uiCCnrvly/1v5eGjP D0jJ -----END CERTIFICATE----- Pritikin, et al. Expires 15 May 2021 [Page 106] Internet-Draft BRSKI November 2020 C.1.3. Registrar Certificate Authority This Certificate Authority enrolls the pledge once it is authorized, and it also signs the Registrar's certificate. file "ownerca_secp384r1.key" -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDCHnLI0MSOLf8XndiZqoZdqblcPR5YSoPGhPOuFxWy1gFi9HbWv8b/R EGdRgGEVSjKgBwYFK4EEACKhZANiAAQbf1m6F8MavGaNjGzgw/oxcQ9l9iKRvbdW gAfb37h6pUVNeYpGlxlZljGxj2l9Mr48yD5bY7VG9qjVb5v5wPPTuRQ/ckdRpHbd 0vC/9cqPMAF/+MJf0/UgA0SLi/IHbLQ= -----END EC PRIVATE KEY----- The public key is indicated in a pledge voucher-request to show proximity. file: examples/ownerca_secp384r1.key file "ownerca_secp384r1.cert" Certificate: Data: Version: 3 (0x2) Serial Number: 694879833 (0x296b0659) Signature Algorithm: ecdsa-with-SHA256 Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Fountain Root CA Validity Not Before: Feb 25 21:31:45 2020 GMT Not After : Feb 24 21:31:45 2022 GMT Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Fountain Root CA Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:1b:7f:59:ba:17:c3:1a:bc:66:8d:8c:6c:e0:c3: fa:31:71:0f:65:f6:22:91:bd:b7:56:80:07:db:df: b8:7a:a5:45:4d:79:8a:46:97:19:59:96:31:b1:8f: 69:7d:32:be:3c:c8:3e:5b:63:b5:46:f6:a8:d5:6f: 9b:f9:c0:f3:d3:b9:14:3f:72:47:51:a4:76:dd:d2: f0:bf:f5:ca:8f:30:01:7f:f8:c2:5f:d3:f5:20:03: 44:8b:8b:f2:07:6c:b4 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign Pritikin, et al. Expires 15 May 2021 [Page 107] Internet-Draft BRSKI November 2020 X509v3 Subject Key Identifier: B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC:87:B3:74:26 X509v3 Authority Key Identifier: keyid:B9:A5:F6:CB:11:E1:07:A4:49:2C:A7:08:C6:7C:10:BC:87:B3:74:26 Signature Algorithm: ecdsa-with-SHA256 30:64:02:30:20:83:06:ce:8d:98:a4:54:7a:66:4c:4a:3a:70: c2:52:36:5a:52:8d:59:7d:20:9b:2a:69:14:58:87:38:d8:55: 79:dd:fd:29:38:95:1e:91:93:76:b4:f5:66:29:44:b4:02:30: 6f:38:f9:af:12:ed:30:d5:85:29:7c:b1:16:58:bd:67:91:43: c4:0d:30:f9:d8:1c:ac:2f:06:dd:bc:d5:06:42:2c:84:a2:04: ea:02:a4:5f:17:51:26:fb:d9:2f:d2:5c -----BEGIN CERTIFICATE----- MIICazCCAfKgAwIBAgIEKWsGWTAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50 YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe Fw0yMDAyMjUyMTMxNDVaFw0yMjAyMjQyMTMxNDVaMG0xEjAQBgoJkiaJk/IsZAEZ FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRh aW4tdGVzdC5leGFtcGxlLmNvbSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMHYw EAYHKoZIzj0CAQYFK4EEACIDYgAEG39ZuhfDGrxmjYxs4MP6MXEPZfYikb23VoAH 29+4eqVFTXmKRpcZWZYxsY9pfTK+PMg+W2O1Rvao1W+b+cDz07kUP3JHUaR23dLw v/XKjzABf/jCX9P1IANEi4vyB2y0o2MwYTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud DwEB/wQEAwIBBjAdBgNVHQ4EFgQUuaX2yxHhB6RJLKcIxnwQvIezdCYwHwYDVR0j BBgwFoAUuaX2yxHhB6RJLKcIxnwQvIezdCYwCgYIKoZIzj0EAwIDZwAwZAIwIIMG zo2YpFR6ZkxKOnDCUjZaUo1ZfSCbKmkUWIc42FV53f0pOJUekZN2tPVmKUS0AjBv OPmvEu0w1YUpfLEWWL1nkUPEDTD52BysLwbdvNUGQiyEogTqAqRfF1Em+9kv0lw= -----END CERTIFICATE----- C.1.4. Registrar key pair The Registrar is the representative of the domain owner. This key signs registrar voucher-requests, and terminates the TLS connection from the pledge. file "jrc_prime256v1.key" -----BEGIN EC PRIVATE KEY----- MHcCAQEEIFZodk+PC5Mu24+ra0sbOjKzan+dW5rvDAR7YuJUOC1YoAoGCCqGSM49 AwEHoUQDQgAElmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+E jLIOYdbJiI0VtEIf1/Jqt+TOBfinTNOLOg== -----END EC PRIVATE KEY----- The public key is indicated in a pledge voucher-request to show proximity. Pritikin, et al. Expires 15 May 2021 [Page 108] Internet-Draft BRSKI November 2020 file "jrc_prime256v1.cert" Certificate: Data: Version: 3 (0x2) Serial Number: 1066965842 (0x3f989b52) Signature Algorithm: ecdsa-with-SHA256 Issuer: DC = ca, DC = sandelman, CN = fountain-test.example.com Unstrung Fountain Root CA Validity Not Before: Feb 25 21:31:54 2020 GMT Not After : Feb 24 21:31:54 2022 GMT Subject: DC = ca, DC = sandelman, CN = fountain-test.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:96:65:50:72:34:ba:9f:e5:dd:e6:5f:f6:f0:81: 6f:e9:48:9e:81:0c:12:07:3b:46:8f:97:64:2b:63: 00:8d:02:0f:57:c9:7c:94:7f:84:8c:b2:0e:61:d6: c9:88:8d:15:b4:42:1f:d7:f2:6a:b7:e4:ce:05:f8: a7:4c:d3:8b:3a ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Extended Key Usage: critical CMC Registration Authority X509v3 Key Usage: critical Digital Signature Signature Algorithm: ecdsa-with-SHA256 30:65:02:30:66:4f:60:4c:55:48:1e:96:07:f8:dd:1f:b9:c8: 12:8d:45:36:87:9b:23:c0:bc:bb:f1:cb:3d:26:15:56:6f:5f: 1f:bf:d5:1c:0e:6a:09:af:1b:76:97:99:19:23:fd:7e:02:31: 00:bc:ac:c3:41:b0:ba:0d:af:52:f9:9c:6e:7a:7f:00:1d:23: c8:62:01:61:bc:4b:c5:c0:47:99:35:0a:0c:77:61:44:01:4a: 07:52:70:57:00:75:ff:be:07:0e:98:cb:e5 -----BEGIN CERTIFICATE----- MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDAjBtMRIwEAYKCZImiZPyLGQB GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMMM2ZvdW50 YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTAe Fw0yMDAyMjUyMTMxNTRaFw0yMjAyMjQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZ FgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRh aW4tdGVzdC5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZl UHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRC H9fyarfkzgX4p0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1Ud DwEB/wQEAwIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaH myPAvLvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAd I8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U= -----END CERTIFICATE----- Pritikin, et al. Expires 15 May 2021 [Page 109] Internet-Draft BRSKI November 2020 C.1.5. Pledge key pair The pledge has an IDevID key pair built in at manufacturing time: file "idevid_00-D0-E5-F2-00-02.key" -----BEGIN EC PRIVATE KEY----- MHcCAQEEIBHNh6r8QRevRuo+tEmBJeFjQKf6bpFA/9NGoltv+9sNoAoGCCqGSM49 AwEHoUQDQgAEA6N1Q4ezfMAKmoecrfb0OBMc1AyEH+BATkF58FsTSyBxs0SbSWLx FjDOuwB9gLGn2TsTUJumJ6VPw5Z/TP4hJw== -----END EC PRIVATE KEY----- The certificate is used by the registrar to find the MASA. file "idevid_00-D0-E5-F2-00-02.cert" Certificate: Data: Version: 3 (0x2) Serial Number: 226876461 (0xd85dc2d) Signature Algorithm: ecdsa-with-SHA256 Issuer: C = Canada, ST = Ontario, OU = Sandelman, CN = highway-test.example.com CA Validity Not Before: Feb 3 06:47:20 2020 GMT Not After : Dec 31 00:00:00 2999 GMT Subject: serialNumber = 00-D0-E5-F2-00-02 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:03:a3:75:43:87:b3:7c:c0:0a:9a:87:9c:ad:f6: f4:38:13:1c:d4:0c:84:1f:e0:40:4e:41:79:f0:5b: 13:4b:20:71:b3:44:9b:49:62:f1:16:30:ce:bb:00: 7d:80:b1:a7:d9:3b:13:50:9b:a6:27:a5:4f:c3:96: 7f:4c:fe:21:27 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: 45:88:CC:96:96:00:64:37:B0:BA:23:65:64:64:54:08:06:6C:56:AD X509v3 Basic Constraints: CA:FALSE 1.3.6.1.5.5.7.1.32: ..highway-test.example.com:9443 Signature Algorithm: ecdsa-with-SHA256 30:65:02:30:23:e1:a9:2e:ef:22:12:34:5a:a5:c2:15:d6:28: bd:ed:3d:96:d6:ce:04:95:ef:a7:c8:dc:18:a8:31:c7:b8:04: 34:f2:b7:4d:79:8a:67:22:24:03:4f:c5:cd:d6:06:ba:02:31: 00:b3:8d:5c:0a:d0:fe:04:83:90:d3:4f:6d:72:97:b3:3e:02: Pritikin, et al. Expires 15 May 2021 [Page 110] Internet-Draft BRSKI November 2020 ea:f1:c8:5a:32:72:58:b7:45:02:50:78:bc:04:1d:23:5e:22: 6f:c3:7f:8c:7c:d7:9b:70:20:91:b4:e1:7f -----BEGIN CERTIFICATE----- MIIB5jCCAWygAwIBAgIEDYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5h ZGExEDAOBgNVBAgMB09udGFyaW8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UE AwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoY DzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZ MBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/g QE5BefBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0G A1UdDgQWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUF BwEgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMC A2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TXmKZyIk A0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vAQdI14ib8N/ jHzXm3AgkbThfw== -----END CERTIFICATE----- C.2. Example process The JSON examples below are wrapped at 60 columns. This results in strings that have newlines in them, which makes them invalid JSON as is. The strings would otherwise be too long, so they need to be unwrapped before processing. For readability, the output of the asn1parse has been truncated at 72 columns rather than wrapped. C.2.1. Pledge to Registrar As described in Section 5.2, the pledge will sign a pledge voucher- request containing the registrar's public key in the proximity- registrar-cert field. The base64 has been wrapped at 60 characters for presentation reasons. Pritikin, et al. Expires 15 May 2021 [Page 111] Internet-Draft BRSKI November 2020 file "vr_00-D0-E5-F2-00-02.b64" MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBglghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGg ggN6BIIDdnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLCJzZXJp YWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6ImFNamd1ZUtVVC0yMndWaW1q NnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLWNlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1 aWJVakFLQmdncWhrak9QUVFEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdv SmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MFlXbHVMWFJs YzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm5SaGFXNGdVbTl2ZENCRFFUQWVG dzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNakF5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsv SXNaQUVaRmdKallURVpNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFV RUF3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQnlxR1NNNDlBZ0VH Q0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dkNCYitsSW5vRU1FZ2M3Um8rWFpDdGpB STBDRDFmSmZKUi9oSXl5RG1IV3lZaU5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0Ex VWRKUUVCL3dRTU1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaGtq T1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteVBBdkx2eHl6MG1GVlp2 WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTkJzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhT OFhBUjVrMUNneDNZVVFCU2dkU2NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIE DYXcLTAKBggqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW8xEjAQ BgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0LmV4YW1wbGUuY29tIENBMCAX DTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0w MC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5B efBbE0sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDgQWBBRFiMyW lgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBwEgBB8MHWhpZ2h3YXktdGVzdC5l eGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BAMCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXv p8jcGKgxx7gENPK3TXmKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4 vAQdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYD VQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5l eGFtcGxlLmNvbSBDQQIEDYXcLTALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6IrwstHF 609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIBxwA1UlkIkuQDf/j7kZ /MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bmiEUpefCEhxSv2xLYurGlugv0dfr/E= The ASN1 decoding of the artifact: file: examples/vr_00-D0-E5-F2-00-02.b64 0:d=0 hl=4 l=1759 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 15:d=1 hl=4 l=1744 cons: cont [ 0 ] 19:d=2 hl=4 l=1740 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01 26:d=3 hl=2 l= 13 cons: SET 28:d=4 hl=2 l= 11 cons: SEQUENCE 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 41:d=3 hl=4 l= 905 cons: SEQUENCE 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data Pritikin, et al. Expires 15 May 2021 [Page 112] Internet-Draft BRSKI November 2020 56:d=4 hl=4 l= 890 cons: cont [ 0 ] 60:d=5 hl=4 l= 886 prim: OCTET STRING :{"ietf-voucher-request:v 950:d=3 hl=4 l= 490 cons: cont [ 0 ] 954:d=4 hl=4 l= 486 cons: SEQUENCE 958:d=5 hl=4 l= 364 cons: SEQUENCE 962:d=6 hl=2 l= 3 cons: cont [ 0 ] 964:d=7 hl=2 l= 1 prim: INTEGER :02 967:d=6 hl=2 l= 4 prim: INTEGER :0D85DC2D 973:d=6 hl=2 l= 10 cons: SEQUENCE 975:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 985:d=6 hl=2 l= 93 cons: SEQUENCE 987:d=7 hl=2 l= 15 cons: SET 989:d=8 hl=2 l= 13 cons: SEQUENCE 991:d=9 hl=2 l= 3 prim: OBJECT :countryName 996:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1004:d=7 hl=2 l= 16 cons: SET 1006:d=8 hl=2 l= 14 cons: SEQUENCE 1008:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1013:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1022:d=7 hl=2 l= 18 cons: SET 1024:d=8 hl=2 l= 16 cons: SEQUENCE 1026:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1031:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1042:d=7 hl=2 l= 36 cons: SET 1044:d=8 hl=2 l= 34 cons: SEQUENCE 1046:d=9 hl=2 l= 3 prim: OBJECT :commonName 1051:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 1080:d=6 hl=2 l= 32 cons: SEQUENCE 1082:d=7 hl=2 l= 13 prim: UTCTIME :200203064720Z 1097:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z 1114:d=6 hl=2 l= 28 cons: SEQUENCE 1116:d=7 hl=2 l= 26 cons: SET 1118:d=8 hl=2 l= 24 cons: SEQUENCE 1120:d=9 hl=2 l= 3 prim: OBJECT :serialNumber 1125:d=9 hl=2 l= 17 prim: UTF8STRING :00-D0-E5-F2-00-02 1144:d=6 hl=2 l= 89 cons: SEQUENCE 1146:d=7 hl=2 l= 19 cons: SEQUENCE 1148:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 1157:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 1167:d=7 hl=2 l= 66 prim: BIT STRING 1235:d=6 hl=2 l= 89 cons: cont [ 3 ] 1237:d=7 hl=2 l= 87 cons: SEQUENCE 1239:d=8 hl=2 l= 29 cons: SEQUENCE 1241:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 1246:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04144588CC9696 1270:d=8 hl=2 l= 9 cons: SEQUENCE 1272:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1277:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 Pritikin, et al. Expires 15 May 2021 [Page 113] Internet-Draft BRSKI November 2020 1281:d=8 hl=2 l= 43 cons: SEQUENCE 1283:d=9 hl=2 l= 8 prim: OBJECT :1.3.6.1.5.5.7.1.32 1293:d=9 hl=2 l= 31 prim: OCTET STRING [HEX DUMP]:0C1D6869676877 1326:d=5 hl=2 l= 10 cons: SEQUENCE 1328:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1338:d=5 hl=2 l= 104 prim: BIT STRING 1444:d=3 hl=4 l= 315 cons: SET 1448:d=4 hl=4 l= 311 cons: SEQUENCE 1452:d=5 hl=2 l= 1 prim: INTEGER :01 1455:d=5 hl=2 l= 101 cons: SEQUENCE 1457:d=6 hl=2 l= 93 cons: SEQUENCE 1459:d=7 hl=2 l= 15 cons: SET 1461:d=8 hl=2 l= 13 cons: SEQUENCE 1463:d=9 hl=2 l= 3 prim: OBJECT :countryName 1468:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1476:d=7 hl=2 l= 16 cons: SET 1478:d=8 hl=2 l= 14 cons: SEQUENCE 1480:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1485:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1494:d=7 hl=2 l= 18 cons: SET 1496:d=8 hl=2 l= 16 cons: SEQUENCE 1498:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1503:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1514:d=7 hl=2 l= 36 cons: SET 1516:d=8 hl=2 l= 34 cons: SEQUENCE 1518:d=9 hl=2 l= 3 prim: OBJECT :commonName 1523:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 1552:d=6 hl=2 l= 4 prim: INTEGER :0D85DC2D 1558:d=5 hl=2 l= 11 cons: SEQUENCE 1560:d=6 hl=2 l= 9 prim: OBJECT :sha256 1571:d=5 hl=2 l= 105 cons: cont [ 0 ] 1573:d=6 hl=2 l= 24 cons: SEQUENCE 1575:d=7 hl=2 l= 9 prim: OBJECT :contentType 1586:d=7 hl=2 l= 11 cons: SET 1588:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 1599:d=6 hl=2 l= 28 cons: SEQUENCE 1601:d=7 hl=2 l= 9 prim: OBJECT :signingTime 1612:d=7 hl=2 l= 15 cons: SET 1614:d=8 hl=2 l= 13 prim: UTCTIME :200225230448Z 1629:d=6 hl=2 l= 47 cons: SEQUENCE 1631:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 1642:d=7 hl=2 l= 34 cons: SET 1644:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:B1E88AF0B2D1C5 1678:d=5 hl=2 l= 10 cons: SEQUENCE 1680:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1690:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:304502201C7003 The JSON contained in the voucher request: Pritikin, et al. Expires 15 May 2021 [Page 114] Internet-Draft BRSKI November 2020 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr eated-on":"2020-02-25T18:04:48.652-05:00","serial-number":"0 0-D0-E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","proximit y-registrar-cert":"MIIB/DCCAYKgAwIBAgIEP5ibUjAKBggqhkjOPQQDA jBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZ WxtYW4xPDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zd HJ1bmcgRm91bnRhaW4gUm9vdCBDQTAeFw0yMDAyMjUyMTMxNTRaFw0yMjAyM jQyMTMxNTRaMFMxEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkA RkWCXNhbmRlbG1hbjEiMCAGA1UEAwwZZm91bnRhaW4tdGVzdC5leGFtcGxlL mNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb +lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p 0zTizqjKjAoMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMcMA4GA1UdDwEB/wQEA wIHgDAKBggqhkjOPQQDAgNoADBlAjBmT2BMVUgelgf43R+5yBKNRTaHmyPAv Lvxyz0mFVZvXx+/1RwOagmvG3aXmRkj/X4CMQC8rMNBsLoNr1L5nG56fwAdI 8hiAWG8S8XAR5k1Cgx3YUQBSgdScFcAdf++Bw6Yy+U="}} C.2.2. Registrar to MASA As described in Section 5.5 the registrar will sign a registrar voucher-request, and will include pledge's voucher request in the prior-signed-voucher-request. file "parboiled_vr_00-D0-E5-F2-00-02.b64" MIIP9wYJKoZIhvcNAQcCoIIP6DCCD+QCAQExDTALBglghkgBZQMEAgEwggoMBgkqhkiG9w0BBwGg ggn9BIIJ+XsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94 aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQyMzowNDo0OS4wNTRaIiwic2VyaWFsLW51 bWJlciI6IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdR IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6Ik1JSUczd1lKS29aSWh2Y05BUWNDb0lJ RzBEQ0NCc3dDQVFFeERUQUxCZ2xnaGtnQlpRTUVBZ0V3Z2dPSkJna3Foa2lHOXcwQkJ3R2dnZ042 QklJRGRuc2lhV1YwWmkxMmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVkyaGxjaUk2ZXlKaGMzTmxj blJwYjI0aU9pSndjbTk0YVcxcGRIa2lMQ0pqY21WaGRHVmtMVzl1SWpvaU1qQXlNQzB3TWkweU5W UXhPRG93TkRvME9DNDJOVEl0TURVNk1EQWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0UkRB dFJUVXRSakl0TURBdE1ESWlMQ0p1YjI1alpTSTZJbUZOYW1kMVpVdFZWQzB5TW5kV2FXMXFObm95 TjFFaUxDSndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9pSk5TVWxDTDBSRFEwRlpT MmRCZDBsQ1FXZEpSVkExYVdKVmFrRkxRbWRuY1docmFrOVFVVkZFUVdwQ2RFMVNTWGRGUVZsTFEx cEpiV2xhVUhsTVIxRkNSMUpaUTFreVJYaEhWRUZZUW1kdlNtdHBZVXByTDBseldrRkZXa1puYkhw WlZ6VnJXbGQ0ZEZsWE5IaFFSRUUyUW1kT1ZrSkJUVTFOTWxwMlpGYzFNRmxYYkhWTVdGSnNZek5S ZFZwWWFHaGlXRUp6V2xNMWFtSXlNR2RXVnpWNlpFaEtNV0p0WTJkU2JUa3hZbTVTYUdGWE5HZFZi VGwyWkVOQ1JGRlVRV1ZHZHpCNVRVUkJlVTFxVlhsTlZFMTRUbFJTWVVaM01IbE5ha0Y1VFdwUmVV MVVUWGhPVkZKaFRVWk5lRVZxUVZGQ1oyOUthMmxoU21zdlNYTmFRVVZhUm1kS2FsbFVSVnBOUW1O SFEyZHRVMHB2YlZRNGFYaHJRVkpyVjBOWVRtaGliVkpzWWtjeGFHSnFSV2xOUTBGSFFURlZSVUYz ZDFwYWJUa3hZbTVTYUdGWE5IUmtSMVo2WkVNMWJHVkhSblJqUjNoc1RHMU9kbUpVUWxwTlFrMUhR bmx4UjFOTk5EbEJaMFZIUTBOeFIxTk5ORGxCZDBWSVFUQkpRVUpLV214VlNFa3dkWEF2YkRObFdt WTVka05DWWl0c1NXNXZSVTFGWjJNM1VtOHJXRnBEZEdwQlNUQkRSREZtU21aS1VpOW9TWGw1Ukcx SVYzbFphVTVHWWxKRFNEbG1lV0Z5Wm10NloxZzBjREI2VkdsNmNXcExha0Z2VFVKWlIwRXhWV1JL VVVWQ0wzZFJUVTFCYjBkRFEzTkhRVkZWUmtKM1RXTk5RVFJIUVRGVlpFUjNSVUl2ZDFGRlFYZEpT R2RFUVV0Q1oyZHhhR3RxVDFCUlVVUkJaMDV2UVVSQ2JFRnFRbTFVTWtKTlZsVm5aV3huWmpRelVp czFlVUpMVGxKVVlVaHRlVkJCZGt4MmVIbDZNRzFHVmxwMldIZ3JMekZTZDA5aFoyMTJSek5oV0cx Pritikin, et al. Expires 15 May 2021 [Page 115] Internet-Draft BRSKI November 2020 U2Eyb3ZXRFJEVFZGRE9ISk5Ua0p6VEc5T2NqRk1OVzVITlRabWQwRmtTVGhvYVVGWFJ6aFRPRmhC VWpWck1VTm5lRE5aVlZGQ1UyZGtVMk5HWTBGa1ppc3JRbmMyV1hrclZUMGlmWDJnZ2dIcU1JSUI1 akNDQVd5Z0F3SUJBZ0lFRFlYY0xUQUtCZ2dxaGtqT1BRUURBakJkTVE4d0RRWURWUVFHRXdaRFlX NWhaR0V4RURBT0JnTlZCQWdNQjA5dWRHRnlhVzh4RWpBUUJnTlZCQXNNQ1ZOaGJtUmxiRzFoYmpF a01DSUdBMVVFQXd3YmFHbG5hSGRoZVMxMFpYTjBMbVY0WVcxd2JHVXVZMjl0SUVOQk1DQVhEVEl3 TURJd016QTJORGN5TUZvWUR6STVPVGt4TWpNeE1EQXdNREF3V2pBY01Sb3dHQVlEVlFRRkRCRXdN QzFFTUMxRk5TMUdNaTB3TUMwd01qQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJB T2pkVU9IczN6QUNwcUhuSzMyOURnVEhOUU1oQi9nUUU1QmVmQmJFMHNnY2JORW0wbGk4Ull3enJz QWZZQ3hwOWs3RTFDYnBpZWxUOE9XZjB6K0lTZWpXVEJYTUIwR0ExVWREZ1FXQkJSRmlNeVdsZ0Jr TjdDNkkyVmtaRlFJQm14V3JUQUpCZ05WSFJNRUFqQUFNQ3NHQ0NzR0FRVUZCd0VnQkI4TUhXaHBa MmgzWVhrdGRHVnpkQzVsZUdGdGNHeGxMbU52YlRvNU5EUXpNQW9HQ0NxR1NNNDlCQU1DQTJnQU1H VUNNQ1BocVM3dkloSTBXcVhDRmRZb3ZlMDlsdGJPQkpYdnA4amNHS2d4eDdnRU5QSzNUWG1LWnlJ a0EwL0Z6ZFlHdWdJeEFMT05YQXJRL2dTRGtOTlBiWEtYc3o0QzZ2SElXakp5V0xkRkFsQjR2QVFk STE0aWI4Ti9qSHpYbTNBZ2tiVGhmekdDQVRzd2dnRTNBZ0VCTUdVd1hURVBNQTBHQTFVRUJoTUdR MkZ1WVdSaE1SQXdEZ1lEVlFRSURBZFBiblJoY21sdk1SSXdFQVlEVlFRTERBbFRZVzVrWld4dFlX NHhKREFpQmdOVkJBTU1HMmhwWjJoM1lYa3RkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJTQkRRUUlFRFlY Y0xUQUxCZ2xnaGtnQlpRTUVBZ0dnYVRBWUJna3Foa2lHOXcwQkNRTXhDd1lKS29aSWh2Y05BUWNC TUJ3R0NTcUdTSWIzRFFFSkJURVBGdzB5TURBeU1qVXlNekEwTkRoYU1DOEdDU3FHU0liM0RRRUpC REVpQkNDeDZJcndzdEhGNjA5WTBFcURLNjJRS2J5NGR1eXlJV3VkdnMxNU0xNkJCVEFLQmdncWhr ak9QUVFEQWdSSE1FVUNJQnh3QTFVbGtJa3VRRGYvajdrWi9NVmVmZ3IxNDEraEtCRmdybk5uZ2p3 cEFpRUF5OGFYdDBHU0I5bTFibWlFVXBlZkNFaHhTdjJ4TFl1ckdsdWd2MGRmci9FPSJ9faCCBG8w ggH8MIIBgqADAgECAgQ/mJtSMAoGCCqGSM49BAMCMG0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcG CgmSJomT8ixkARkWCXNhbmRlbG1hbjE8MDoGA1UEAwwzZm91bnRhaW4tdGVzdC5leGFtcGxlLmNv bSBVbnN0cnVuZyBGb3VudGFpbiBSb290IENBMB4XDTIwMDIyNTIxMzE1NFoXDTIyMDIyNDIxMzE1 NFowUzESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMSIwIAYD VQQDDBlmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE lmVQcjS6n+Xd5l/28IFv6UiegQwSBztGj5dkK2MAjQIPV8l8lH+EjLIOYdbJiI0VtEIf1/Jqt+TO BfinTNOLOqMqMCgwFgYDVR0lAQH/BAwwCgYIKwYBBQUHAxwwDgYDVR0PAQH/BAQDAgeAMAoGCCqG SM49BAMCA2gAMGUCMGZPYExVSB6WB/jdH7nIEo1FNoebI8C8u/HLPSYVVm9fH7/VHA5qCa8bdpeZ GSP9fgIxALysw0Gwug2vUvmcbnp/AB0jyGIBYbxLxcBHmTUKDHdhRAFKB1JwVwB1/74HDpjL5TCC AmswggHyoAMCAQICBClrBlkwCgYIKoZIzj0EAwIwbTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK CZImiZPyLGQBGRYJc2FuZGVsbWFuMTwwOgYDVQQDDDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29t IFVuc3RydW5nIEZvdW50YWluIFJvb3QgQ0EwHhcNMjAwMjI1MjEzMTQ1WhcNMjIwMjI0MjEzMTQ1 WjBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNV BAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9vdCBDQTB2 MBAGByqGSM49AgEGBSuBBAAiA2IABBt/WboXwxq8Zo2MbODD+jFxD2X2IpG9t1aAB9vfuHqlRU15 ikaXGVmWMbGPaX0yvjzIPltjtUb2qNVvm/nA89O5FD9yR1Gkdt3S8L/1yo8wAX/4wl/T9SADRIuL 8gdstKNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLml9ssR 4QekSSynCMZ8ELyHs3QmMB8GA1UdIwQYMBaAFLml9ssR4QekSSynCMZ8ELyHs3QmMAoGCCqGSM49 BAMCA2cAMGQCMCCDBs6NmKRUemZMSjpwwlI2WlKNWX0gmyppFFiHONhVed39KTiVHpGTdrT1ZilE tAIwbzj5rxLtMNWFKXyxFli9Z5FDxA0w+dgcrC8G3bzVBkIshKIE6gKkXxdRJvvZL9JcMYIBSzCC AUcCAQEwdTBtMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4x PDA6BgNVBAMMM2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9v dCBDQQIEP5ibUjALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMDAyMjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCA9gYxR1sS0giII3PwvOK/N 5RUBwjSL/cDcrH/Bd+E1ajAKBggqhkjOPQQDAgRHMEUCIFieXZaO7P9eZMpCVn2laB4czw7I0s0P s9+frcJtEBTTAiEAhCcB//qmgqcEA+90mquvVNENmFH9dxCH8Ihhz6SCVDI= Pritikin, et al. Expires 15 May 2021 [Page 116] Internet-Draft BRSKI November 2020 The ASN1 decoding of the artifact: file: examples/parboiled_vr_00_D0-E5-02-00-2D.b64 0:d=0 hl=4 l=4087 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 15:d=1 hl=4 l=4072 cons: cont [ 0 ] 19:d=2 hl=4 l=4068 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01 26:d=3 hl=2 l= 13 cons: SET 28:d=4 hl=2 l= 11 cons: SEQUENCE 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 41:d=3 hl=4 l=2572 cons: SEQUENCE 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 56:d=4 hl=4 l=2557 cons: cont [ 0 ] 60:d=5 hl=4 l=2553 prim: OCTET STRING :{"ietf-voucher-request:v 2617:d=3 hl=4 l=1135 cons: cont [ 0 ] 2621:d=4 hl=4 l= 508 cons: SEQUENCE 2625:d=5 hl=4 l= 386 cons: SEQUENCE 2629:d=6 hl=2 l= 3 cons: cont [ 0 ] 2631:d=7 hl=2 l= 1 prim: INTEGER :02 2634:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 2640:d=6 hl=2 l= 10 cons: SEQUENCE 2642:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 2652:d=6 hl=2 l= 109 cons: SEQUENCE 2654:d=7 hl=2 l= 18 cons: SET 2656:d=8 hl=2 l= 16 cons: SEQUENCE 2658:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2670:d=9 hl=2 l= 2 prim: IA5STRING :ca 2674:d=7 hl=2 l= 25 cons: SET 2676:d=8 hl=2 l= 23 cons: SEQUENCE 2678:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2690:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 2701:d=7 hl=2 l= 60 cons: SET 2703:d=8 hl=2 l= 58 cons: SEQUENCE 2705:d=9 hl=2 l= 3 prim: OBJECT :commonName 2710:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 2763:d=6 hl=2 l= 30 cons: SEQUENCE 2765:d=7 hl=2 l= 13 prim: UTCTIME :200225213154Z 2780:d=7 hl=2 l= 13 prim: UTCTIME :220224213154Z 2795:d=6 hl=2 l= 83 cons: SEQUENCE 2797:d=7 hl=2 l= 18 cons: SET 2799:d=8 hl=2 l= 16 cons: SEQUENCE 2801:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 2813:d=9 hl=2 l= 2 prim: IA5STRING :ca 2817:d=7 hl=2 l= 25 cons: SET 2819:d=8 hl=2 l= 23 cons: SEQUENCE 2821:d=9 hl=2 l= 10 prim: OBJECT :domainComponent Pritikin, et al. Expires 15 May 2021 [Page 117] Internet-Draft BRSKI November 2020 2833:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 2844:d=7 hl=2 l= 34 cons: SET 2846:d=8 hl=2 l= 32 cons: SEQUENCE 2848:d=9 hl=2 l= 3 prim: OBJECT :commonName 2853:d=9 hl=2 l= 25 prim: UTF8STRING :fountain-test.example.co 2880:d=6 hl=2 l= 89 cons: SEQUENCE 2882:d=7 hl=2 l= 19 cons: SEQUENCE 2884:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 2893:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 2903:d=7 hl=2 l= 66 prim: BIT STRING 2971:d=6 hl=2 l= 42 cons: cont [ 3 ] 2973:d=7 hl=2 l= 40 cons: SEQUENCE 2975:d=8 hl=2 l= 22 cons: SEQUENCE 2977:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usag 2982:d=9 hl=2 l= 1 prim: BOOLEAN :255 2985:d=9 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B0601 2999:d=8 hl=2 l= 14 cons: SEQUENCE 3001:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 3006:d=9 hl=2 l= 1 prim: BOOLEAN :255 3009:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020780 3015:d=5 hl=2 l= 10 cons: SEQUENCE 3017:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3027:d=5 hl=2 l= 104 prim: BIT STRING 3133:d=4 hl=4 l= 619 cons: SEQUENCE 3137:d=5 hl=4 l= 498 cons: SEQUENCE 3141:d=6 hl=2 l= 3 cons: cont [ 0 ] 3143:d=7 hl=2 l= 1 prim: INTEGER :02 3146:d=6 hl=2 l= 4 prim: INTEGER :296B0659 3152:d=6 hl=2 l= 10 cons: SEQUENCE 3154:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3164:d=6 hl=2 l= 109 cons: SEQUENCE 3166:d=7 hl=2 l= 18 cons: SET 3168:d=8 hl=2 l= 16 cons: SEQUENCE 3170:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3182:d=9 hl=2 l= 2 prim: IA5STRING :ca 3186:d=7 hl=2 l= 25 cons: SET 3188:d=8 hl=2 l= 23 cons: SEQUENCE 3190:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3202:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3213:d=7 hl=2 l= 60 cons: SET 3215:d=8 hl=2 l= 58 cons: SEQUENCE 3217:d=9 hl=2 l= 3 prim: OBJECT :commonName 3222:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3275:d=6 hl=2 l= 30 cons: SEQUENCE 3277:d=7 hl=2 l= 13 prim: UTCTIME :200225213145Z 3292:d=7 hl=2 l= 13 prim: UTCTIME :220224213145Z 3307:d=6 hl=2 l= 109 cons: SEQUENCE 3309:d=7 hl=2 l= 18 cons: SET Pritikin, et al. Expires 15 May 2021 [Page 118] Internet-Draft BRSKI November 2020 3311:d=8 hl=2 l= 16 cons: SEQUENCE 3313:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3325:d=9 hl=2 l= 2 prim: IA5STRING :ca 3329:d=7 hl=2 l= 25 cons: SET 3331:d=8 hl=2 l= 23 cons: SEQUENCE 3333:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3345:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3356:d=7 hl=2 l= 60 cons: SET 3358:d=8 hl=2 l= 58 cons: SEQUENCE 3360:d=9 hl=2 l= 3 prim: OBJECT :commonName 3365:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3418:d=6 hl=2 l= 118 cons: SEQUENCE 3420:d=7 hl=2 l= 16 cons: SEQUENCE 3422:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 3431:d=8 hl=2 l= 5 prim: OBJECT :secp384r1 3438:d=7 hl=2 l= 98 prim: BIT STRING 3538:d=6 hl=2 l= 99 cons: cont [ 3 ] 3540:d=7 hl=2 l= 97 cons: SEQUENCE 3542:d=8 hl=2 l= 15 cons: SEQUENCE 3544:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 3549:d=9 hl=2 l= 1 prim: BOOLEAN :255 3552:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:30030101FF 3559:d=8 hl=2 l= 14 cons: SEQUENCE 3561:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 3566:d=9 hl=2 l= 1 prim: BOOLEAN :255 3569:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020106 3575:d=8 hl=2 l= 29 cons: SEQUENCE 3577:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 3582:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414B9A5F6CB11 3606:d=8 hl=2 l= 31 cons: SEQUENCE 3608:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Authority Key Ide 3613:d=9 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:30168014B9A5F6 3639:d=5 hl=2 l= 10 cons: SEQUENCE 3641:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3651:d=5 hl=2 l= 103 prim: BIT STRING 3756:d=3 hl=4 l= 331 cons: SET 3760:d=4 hl=4 l= 327 cons: SEQUENCE 3764:d=5 hl=2 l= 1 prim: INTEGER :01 3767:d=5 hl=2 l= 117 cons: SEQUENCE 3769:d=6 hl=2 l= 109 cons: SEQUENCE 3771:d=7 hl=2 l= 18 cons: SET 3773:d=8 hl=2 l= 16 cons: SEQUENCE 3775:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3787:d=9 hl=2 l= 2 prim: IA5STRING :ca 3791:d=7 hl=2 l= 25 cons: SET 3793:d=8 hl=2 l= 23 cons: SEQUENCE 3795:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3807:d=9 hl=2 l= 9 prim: IA5STRING :sandelman Pritikin, et al. Expires 15 May 2021 [Page 119] Internet-Draft BRSKI November 2020 3818:d=7 hl=2 l= 60 cons: SET 3820:d=8 hl=2 l= 58 cons: SEQUENCE 3822:d=9 hl=2 l= 3 prim: OBJECT :commonName 3827:d=9 hl=2 l= 51 prim: UTF8STRING :fountain-test.example.co 3880:d=6 hl=2 l= 4 prim: INTEGER :3F989B52 3886:d=5 hl=2 l= 11 cons: SEQUENCE 3888:d=6 hl=2 l= 9 prim: OBJECT :sha256 3899:d=5 hl=2 l= 105 cons: cont [ 0 ] 3901:d=6 hl=2 l= 24 cons: SEQUENCE 3903:d=7 hl=2 l= 9 prim: OBJECT :contentType 3914:d=7 hl=2 l= 11 cons: SET 3916:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 3927:d=6 hl=2 l= 28 cons: SEQUENCE 3929:d=7 hl=2 l= 9 prim: OBJECT :signingTime 3940:d=7 hl=2 l= 15 cons: SET 3942:d=8 hl=2 l= 13 prim: UTCTIME :200225230449Z 3957:d=6 hl=2 l= 47 cons: SEQUENCE 3959:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 3970:d=7 hl=2 l= 34 cons: SET 3972:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:3D818C51D6C4B4 4006:d=5 hl=2 l= 10 cons: SEQUENCE 4008:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 4018:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220589E5D The JSON contained in the voucher request. Note that the previous voucher request is in the prior-signed-voucher-request attribute. Pritikin, et al. Expires 15 May 2021 [Page 120] Internet-Draft BRSKI November 2020 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr eated-on":"2020-02-25T23:04:49.054Z","serial-number":"00-D0- E5-F2-00-02","nonce":"aMjgueKUT-22wVimj6z27Q","prior-signed- voucher-request":"MIIG3wYJKoZIhvcNAQcCoIIG0DCCBswCAQExDTALBg lghkgBZQMEAgEwggOJBgkqhkiG9w0BBwGgggN6BIIDdnsiaWV0Zi12b3VjaG VyLXJlcXVlc3Q6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLC JjcmVhdGVkLW9uIjoiMjAyMC0wMi0yNVQxODowNDo0OC42NTItMDU6MDAiLC JzZXJpYWwtbnVtYmVyIjoiMDAtRDAtRTUtRjItMDAtMDIiLCJub25jZSI6Im FNamd1ZUtVVC0yMndWaW1qNnoyN1EiLCJwcm94aW1pdHktcmVnaXN0cmFyLW NlcnQiOiJNSUlCL0RDQ0FZS2dBd0lCQWdJRVA1aWJVakFLQmdncWhrak9QUV FEQWpCdE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhHVEFYQmdvSmtpYU prL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhQREE2QmdOVkJBTU1NMlp2ZFc1MF lXbHVMWFJsYzNRdVpYaGhiWEJzWlM1amIyMGdWVzV6ZEhKMWJtY2dSbTkxYm 5SaGFXNGdVbTl2ZENCRFFUQWVGdzB5TURBeU1qVXlNVE14TlRSYUZ3MHlNak F5TWpReU1UTXhOVFJhTUZNeEVqQVFCZ29Ka2lhSmsvSXNaQUVaRmdKallURV pNQmNHQ2dtU0pvbVQ4aXhrQVJrV0NYTmhibVJsYkcxaGJqRWlNQ0FHQTFVRU F3d1pabTkxYm5SaGFXNHRkR1Z6ZEM1bGVHRnRjR3hsTG1OdmJUQlpNQk1HQn lxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJKWmxVSEkwdXAvbDNlWmY5dk NCYitsSW5vRU1FZ2M3Um8rWFpDdGpBSTBDRDFmSmZKUi9oSXl5RG1IV3lZaU 5GYlJDSDlmeWFyZmt6Z1g0cDB6VGl6cWpLakFvTUJZR0ExVWRKUUVCL3dRTU 1Bb0dDQ3NHQVFVRkJ3TWNNQTRHQTFVZER3RUIvd1FFQXdJSGdEQUtCZ2dxaG tqT1BRUURBZ05vQURCbEFqQm1UMkJNVlVnZWxnZjQzUis1eUJLTlJUYUhteV BBdkx2eHl6MG1GVlp2WHgrLzFSd09hZ212RzNhWG1Sa2ovWDRDTVFDOHJNTk JzTG9OcjFMNW5HNTZmd0FkSThoaUFXRzhTOFhBUjVrMUNneDNZVVFCU2dkU2 NGY0FkZisrQnc2WXkrVT0ifX2gggHqMIIB5jCCAWygAwIBAgIEDYXcLTAKBg gqhkjOPQQDAjBdMQ8wDQYDVQQGEwZDYW5hZGExEDAOBgNVBAgMB09udGFyaW 8xEjAQBgNVBAsMCVNhbmRlbG1hbjEkMCIGA1UEAwwbaGlnaHdheS10ZXN0Lm V4YW1wbGUuY29tIENBMCAXDTIwMDIwMzA2NDcyMFoYDzI5OTkxMjMxMDAwMD AwWjAcMRowGAYDVQQFDBEwMC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49Ag EGCCqGSM49AwEHA0IABAOjdUOHs3zACpqHnK329DgTHNQMhB/gQE5BefBbE0 sgcbNEm0li8RYwzrsAfYCxp9k7E1CbpielT8OWf0z+ISejWTBXMB0GA1UdDg QWBBRFiMyWlgBkN7C6I2VkZFQIBmxWrTAJBgNVHRMEAjAAMCsGCCsGAQUFBw EgBB8MHWhpZ2h3YXktdGVzdC5leGFtcGxlLmNvbTo5NDQzMAoGCCqGSM49BA MCA2gAMGUCMCPhqS7vIhI0WqXCFdYove09ltbOBJXvp8jcGKgxx7gENPK3TX mKZyIkA0/FzdYGugIxALONXArQ/gSDkNNPbXKXsz4C6vHIWjJyWLdFAlB4vA QdI14ib8N/jHzXm3AgkbThfzGCATswggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2 FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4xJD AiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEDYXcLTALBg lghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSI b3DQEJBTEPFw0yMDAyMjUyMzA0NDhaMC8GCSqGSIb3DQEJBDEiBCCx6Irwst HF609Y0EqDK62QKby4duyyIWudvs15M16BBTAKBggqhkjOPQQDAgRHMEUCIB xwA1UlkIkuQDf/j7kZ/MVefgr141+hKBFgrnNngjwpAiEAy8aXt0GSB9m1bm iEUpefCEhxSv2xLYurGlugv0dfr/E="}} C.2.3. MASA to Registrar The MASA will return a voucher to the registrar, to be relayed to the pledge. Pritikin, et al. Expires 15 May 2021 [Page 121] Internet-Draft BRSKI November 2020 file "voucher_00-D0-E5-F2-00-02.b64" MIIGxwYJKoZIhvcNAQcCoIIGuDCCBrQCAQExDTALBglghkgBZQMEAgEwggN4BgkqhkiG9w0BBwGg ggNpBIIDZXsiaWV0Zi12b3VjaGVyOnZvdWNoZXIiOnsiYXNzZXJ0aW9uIjoibG9nZ2VkIiwiY3Jl YXRlZC1vbiI6IjIwMjAtMDItMjVUMTg6MDQ6NDkuMzAzLTA1OjAwIiwic2VyaWFsLW51bWJlciI6 IjAwLUQwLUU1LUYyLTAwLTAyIiwibm9uY2UiOiJhTWpndWVLVVQtMjJ3VmltajZ6MjdRIiwicGlu bmVkLWRvbWFpbi1jZXJ0IjoiTUlJQi9EQ0NBWUtnQXdJQkFnSUVQNWliVWpBS0JnZ3Foa2pPUFFR REFqQnRNUkl3RUFZS0NaSW1pWlB5TEdRQkdSWUNZMkV4R1RBWEJnb0praWFKay9Jc1pBRVpGZ2x6 WVc1a1pXeHRZVzR4UERBNkJnTlZCQU1NTTJadmRXNTBZV2x1TFhSbGMzUXVaWGhoYlhCc1pTNWpi MjBnVlc1emRISjFibWNnUm05MWJuUmhhVzRnVW05dmRDQkRRVEFlRncweU1EQXlNalV5TVRNeE5U UmFGdzB5TWpBeU1qUXlNVE14TlRSYU1GTXhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJj R0NnbVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVpTUNBR0ExVUVBd3daWm05MWJuUmhhVzR0 ZEdWemRDNWxlR0Z0Y0d4bExtTnZiVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFC SlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpmSlIvaEl5eURt SFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqS2pBb01CWUdBMVVkSlFFQi93UU1NQW9HQ0Nz R0FRVUZCd01jTUE0R0ExVWREd0VCL3dRRUF3SUhnREFLQmdncWhrak9QUVFEQWdOb0FEQmxBakJt VDJCTVZVZ2VsZ2Y0M1IrNXlCS05SVGFIbXlQQXZMdnh5ejBtRlZadlh4Ky8xUndPYWdtdkczYVht UmtqL1g0Q01RQzhyTU5Cc0xvTnIxTDVuRzU2ZndBZEk4aGlBV0c4UzhYQVI1azFDZ3gzWVVRQlNn ZFNjRmNBZGYrK0J3Nll5K1U9In19oIIB4zCCAd8wggFkoAMCAQICBBuZX1QwCgYIKoZIzj0EAwIw XTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlTYW5kZWxtYW4x JDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQTAeFw0xOTAyMTIyMjIyNDFaFw0y MTAyMTEyMjIyNDFaMF8xDzANBgNVBAYTBkNhbmFkYTEQMA4GA1UECAwHT250YXJpbzESMBAGA1UE CwwJU2FuZGVsbWFuMSYwJAYDVQQDDB1oaWdod2F5LXRlc3QuZXhhbXBsZS5jb20gTUFTQTBZMBMG ByqGSM49AgEGCCqGSM49AwEHA0IABKoEFaNEueJE+Mn5GwcbpnRznB66bKmzqTCpojJZ96AdRwFt uTCVfoKouLTBX0idIhMLfJLM31lyuKy4CUtpp6WjEDAOMAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0E AwIDaQAwZgIxAL1V5ZsO+/xelSnjgbMVNaqTGKIEvkRyslF9TW3r0dXBEDqyOXtXP8XMsKMO55lG ugIxAPZ/RH23FPrRZ2rUEcNLrub7mphW+oUhLlxITPA/8ps/roggp675cv9b+Xhozw9IyTGCATsw ggE3AgEBMGUwXTEPMA0GA1UEBhMGQ2FuYWRhMRAwDgYDVQQIDAdPbnRhcmlvMRIwEAYDVQQLDAlT YW5kZWxtYW4xJDAiBgNVBAMMG2hpZ2h3YXktdGVzdC5leGFtcGxlLmNvbSBDQQIEG5lfVDALBglg hkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAy MjUyMzA0NDlaMC8GCSqGSIb3DQEJBDEiBCCJQso4Z9msdaPk3bsDltTkVckX50DvOPuOR9Svi5M9 RDAKBggqhkjOPQQDAgRHMEUCIQCKESXfM3iV8hpkqcxAKA1veArA6GFpN0jzyns4El8uDgIgSRQi 9/MntuJhAM/tJCZBkfHBoAGX4PFAwwbs5LFZtAw= The ASN1 decoding of the artifact: file: examples/voucher_00-D0-E5-F2-00-02.b64 0:d=0 hl=4 l=1735 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 15:d=1 hl=4 l=1720 cons: cont [ 0 ] 19:d=2 hl=4 l=1716 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01 26:d=3 hl=2 l= 13 cons: SET 28:d=4 hl=2 l= 11 cons: SEQUENCE 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 41:d=3 hl=4 l= 888 cons: SEQUENCE 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data Pritikin, et al. Expires 15 May 2021 [Page 122] Internet-Draft BRSKI November 2020 56:d=4 hl=4 l= 873 cons: cont [ 0 ] 60:d=5 hl=4 l= 869 prim: OCTET STRING :{"ietf-voucher:voucher": 933:d=3 hl=4 l= 483 cons: cont [ 0 ] 937:d=4 hl=4 l= 479 cons: SEQUENCE 941:d=5 hl=4 l= 356 cons: SEQUENCE 945:d=6 hl=2 l= 3 cons: cont [ 0 ] 947:d=7 hl=2 l= 1 prim: INTEGER :02 950:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 956:d=6 hl=2 l= 10 cons: SEQUENCE 958:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 968:d=6 hl=2 l= 93 cons: SEQUENCE 970:d=7 hl=2 l= 15 cons: SET 972:d=8 hl=2 l= 13 cons: SEQUENCE 974:d=9 hl=2 l= 3 prim: OBJECT :countryName 979:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 987:d=7 hl=2 l= 16 cons: SET 989:d=8 hl=2 l= 14 cons: SEQUENCE 991:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 996:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1005:d=7 hl=2 l= 18 cons: SET 1007:d=8 hl=2 l= 16 cons: SEQUENCE 1009:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1014:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1025:d=7 hl=2 l= 36 cons: SET 1027:d=8 hl=2 l= 34 cons: SEQUENCE 1029:d=9 hl=2 l= 3 prim: OBJECT :commonName 1034:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 1063:d=6 hl=2 l= 30 cons: SEQUENCE 1065:d=7 hl=2 l= 13 prim: UTCTIME :190212222241Z 1080:d=7 hl=2 l= 13 prim: UTCTIME :210211222241Z 1095:d=6 hl=2 l= 95 cons: SEQUENCE 1097:d=7 hl=2 l= 15 cons: SET 1099:d=8 hl=2 l= 13 cons: SEQUENCE 1101:d=9 hl=2 l= 3 prim: OBJECT :countryName 1106:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1114:d=7 hl=2 l= 16 cons: SET 1116:d=8 hl=2 l= 14 cons: SEQUENCE 1118:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1123:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1132:d=7 hl=2 l= 18 cons: SET 1134:d=8 hl=2 l= 16 cons: SEQUENCE 1136:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1141:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1152:d=7 hl=2 l= 38 cons: SET 1154:d=8 hl=2 l= 36 cons: SEQUENCE 1156:d=9 hl=2 l= 3 prim: OBJECT :commonName 1161:d=9 hl=2 l= 29 prim: UTF8STRING :highway-test.example.com 1192:d=6 hl=2 l= 89 cons: SEQUENCE Pritikin, et al. Expires 15 May 2021 [Page 123] Internet-Draft BRSKI November 2020 1194:d=7 hl=2 l= 19 cons: SEQUENCE 1196:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 1205:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 1215:d=7 hl=2 l= 66 prim: BIT STRING 1283:d=6 hl=2 l= 16 cons: cont [ 3 ] 1285:d=7 hl=2 l= 14 cons: SEQUENCE 1287:d=8 hl=2 l= 12 cons: SEQUENCE 1289:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 1294:d=9 hl=2 l= 1 prim: BOOLEAN :255 1297:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 1301:d=5 hl=2 l= 10 cons: SEQUENCE 1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1313:d=5 hl=2 l= 105 prim: BIT STRING 1420:d=3 hl=4 l= 315 cons: SET 1424:d=4 hl=4 l= 311 cons: SEQUENCE 1428:d=5 hl=2 l= 1 prim: INTEGER :01 1431:d=5 hl=2 l= 101 cons: SEQUENCE 1433:d=6 hl=2 l= 93 cons: SEQUENCE 1435:d=7 hl=2 l= 15 cons: SET 1437:d=8 hl=2 l= 13 cons: SEQUENCE 1439:d=9 hl=2 l= 3 prim: OBJECT :countryName 1444:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Canada 1452:d=7 hl=2 l= 16 cons: SET 1454:d=8 hl=2 l= 14 cons: SEQUENCE 1456:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName 1461:d=9 hl=2 l= 7 prim: UTF8STRING :Ontario 1470:d=7 hl=2 l= 18 cons: SET 1472:d=8 hl=2 l= 16 cons: SEQUENCE 1474:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName 1479:d=9 hl=2 l= 9 prim: UTF8STRING :Sandelman 1490:d=7 hl=2 l= 36 cons: SET 1492:d=8 hl=2 l= 34 cons: SEQUENCE 1494:d=9 hl=2 l= 3 prim: OBJECT :commonName 1499:d=9 hl=2 l= 27 prim: UTF8STRING :highway-test.example.com 1528:d=6 hl=2 l= 4 prim: INTEGER :1B995F54 1534:d=5 hl=2 l= 11 cons: SEQUENCE 1536:d=6 hl=2 l= 9 prim: OBJECT :sha256 1547:d=5 hl=2 l= 105 cons: cont [ 0 ] 1549:d=6 hl=2 l= 24 cons: SEQUENCE 1551:d=7 hl=2 l= 9 prim: OBJECT :contentType 1562:d=7 hl=2 l= 11 cons: SET 1564:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 1575:d=6 hl=2 l= 28 cons: SEQUENCE 1577:d=7 hl=2 l= 9 prim: OBJECT :signingTime 1588:d=7 hl=2 l= 15 cons: SET 1590:d=8 hl=2 l= 13 prim: UTCTIME :200225230449Z 1605:d=6 hl=2 l= 47 cons: SEQUENCE 1607:d=7 hl=2 l= 9 prim: OBJECT :messageDigest Pritikin, et al. Expires 15 May 2021 [Page 124] Internet-Draft BRSKI November 2020 1618:d=7 hl=2 l= 34 cons: SET 1620:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:8942CA3867D9AC 1654:d=5 hl=2 l= 10 cons: SEQUENCE 1656:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 1666:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450221008A11 Appendix D. Additional References RFC EDITOR Please remove this section before publication. It exists just to include references to the things in the YANG descriptions which are not otherwise referenced in the text so that xml2rfc will not complain. [ITU.X690.1994] Authors' Addresses Max Pritikin Cisco Email: pritikin@cisco.com Michael C. Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca URI: http://www.sandelman.ca/ Toerless Eckert Futurewei Technologies Inc. USA 2330 Central Expy Santa Clara, CA 95050 United States of America Email: tte+ietf@cs.fau.de Michael H. Behringer Email: Michael.H.Behringer@gmail.com Kent Watsen Watsen Networks Email: kent+ietf@watsen.net Pritikin, et al. Expires 15 May 2021 [Page 125] ./draft-ietf-homenet-babel-profile-07.txt0000644000764400076440000004664213323647633017545 0ustar iustyiusty Network Working Group J. Chroboczek Internet-Draft IRIF, University of Paris-Diderot Intended status: Standards Track July 18, 2018 Expires: January 19, 2019 Homenet profile of the Babel routing protocol draft-ietf-homenet-babel-profile-07 Abstract This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of the Homenet protocol suite, as well as the interactions between the Home Networking Control Protocol (HNCP) and Babel. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 19, 2019. Copyright Notice Copyright (c) 2018 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 (https://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. Chroboczek Expires January 19, 2019 [Page 1] Internet-Draft Homenet Babel profile July 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 2 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Homenet profile of Babel . . . . . . . . . . . . . . . . 3 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Optional features . . . . . . . . . . . . . . . . . . . . 5 3. Interactions between HNCP and Babel . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Optional features . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The core of the Homenet protocol suite consists of the Home Networking Control Protocol (HNCP) [RFC7788], a protocol used for flooding configuration information and assigning prefixes to links, combined with the Babel routing protocol [RFC6126bis]. Babel is an extensible, flexible and modular protocol: minimal implementations of Babel have been demonstrated that consist of a few hundred lines of code, while the "large" implementation includes support for a number of extensions and consists of over ten thousand lines of C code. This document consists of two parts. The first specifies the exact subset of the Babel protocol and its extensions that is required by an implementation of the Homenet protocol suite. The second specifies how HNCP interacts with Babel. 1.1. Requirement Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Background The Babel routing protocol and its extensions are defined in a number of documents: Chroboczek Expires January 19, 2019 [Page 2] Internet-Draft Homenet Babel profile July 2018 o RFC 6126bis [RFC6126bis] defines the Babel routing protocol. It allows Babel's control data to be carried either over link-local IPv6 or over IPv4, and in either case allows announcing both IPv4 and IPv6 routes. It leaves link cost estimation, metric computation and route selection to the implementation. Distinct implementations of RFC 6126bis Babel will interoperate, in the sense that they will maintain a set of loop-free forwarding paths. However, if they implement conflicting options, they might not be able to exchange a full set of routes; in the worst case, an implementation that only implements the IPv6 subset of the protocol and an implementation that only implements the IPv4 subset of the protocol will not exchange any routes. In addition, if implementations use conflicting route selection policies, persistent oscillations might occur. o The informative Appendix A of RFC 6126bis suggests a simple and easy to implement algorithm for cost and metric computation that has been found to work satisfactorily in a wide range of topologies. o While RFC 6126bis does not provide an algorithm for route selection, its Section 3.6 suggests selecting the route with smallest metric with some hysteresis applied. An algorithm that has been found to work well in practice is described in Section III.E of [DELAY-BASED]. o Five RFCs and Internet-Drafts define optional extensions to Babel: HMAC-based authentication [RFC7298], source-specific routing [BABEL-SS], delay-based routing [BABEL-RTT] and ToS-specific routing [ToS-SPECIFIC]. All of these extensions interoperate with the core protocol as well as with each other. 2. The Homenet profile of Babel 2.1. Requirements REQ1: a Homenet implementation of Babel MUST encapsulate Babel control traffic in IPv6 packets sent to the IANA-assigned port 6696 and either the IANA-assigned multicast group ff02::1:6 or to a link- local unicast address. Rationale: since Babel is able to carry both IPv4 and IPv6 routes over either IPv4 or IPv6, choosing the protocol used for carrying control traffic is a matter of preference. Since IPv6 has some features that make implementations somewhat simpler and more reliable (notably properly scoped and reasonably stable link-local addresses), we require carrying control data over IPv6. Chroboczek Expires January 19, 2019 [Page 3] Internet-Draft Homenet Babel profile July 2018 REQ2: a Homenet implementation of Babel MUST implement the IPv6 subset of the protocol defined in the body of RFC 6126bis. Rationale: support for IPv6 routing is an essential component of the Homenet architecture. REQ3: a Homenet implementation of Babel SHOULD implement the IPv4 subset of the protocol defined in the body of RFC 6126bis. Use of other techniques for acquiring IPv4 connectivity (such as multiple layers of NAT) is strongly discouraged. Rationale: support for IPv4 will likely remain necessary for years to come, and even in pure IPv6 deployments, including code for supporting IPv4 has very little cost. Since HNCP makes it easy to assign distinct IPv4 prefixes to the links in a network, it is not necessary to resort to multiple layers of NAT, with all of its problems. REQ4: a Homenet implementation of Babel MUST implement source- specific routing for IPv6, as defined in draft-ietf-babel-source- specific [BABEL-SS]. Rationale: source-specific routing is an essential component of the Homenet architecture. Source-specific routing for IPv4 is not required, since HNCP arranges things so that a single non-specific IPv4 default route is announced (Section 6.5 of [RFC7788]). REQ5: a Homenet implementation of Babel must use metrics that are of a similar magnitude to the values suggested in Appendix A of RFC 6126bis. In particular, it SHOULD assign costs that are no less than 256 to wireless links, and SHOULD assign costs between 32 and 196 to lossless wired links. Rationale: if two implementations of Babel choose very different values for link costs, combining routers from different vendors will cause sub-optimal routing. REQ6: a Homenet implementation of Babel SHOULD distinguish between wired and wireless links; if it is unable to determine whether a link is wired or wireless, it SHOULD make the worst-case hypothesis that the link is wireless. It SHOULD dynamically probe the quality of wireless links and derive a suitable metric from its quality estimation. Appendix A of RFC 6126bis gives an example of a suitable algorithm. Rationale: support for wireless transit links is a distinguishing feature of Homenet, and one that is requested by our users. In the absence of dynamically computed metrics, the routing protocol Chroboczek Expires January 19, 2019 [Page 4] Internet-Draft Homenet Babel profile July 2018 attempts to minimise the number of links crossed by a route, and therefore prefers long, lossy links to shorter, lossless ones. In wireless networks, "hop-count routing is worst-path routing". While it would be desirable to perform link-quality probing on some wired link technologies, notably power-line networks, these kinds of links tend to be difficult or impossible to detect automatically, and we are not aware of any published link-quality algorithms for them. Hence, we do not require link-quality estimation for wired links of any kind. 2.2. Optional features OPT1: a Homenet implementation of Babel MAY perform route selection by applying hysteresis to route metrics, as suggested in Section 3.6 of RFC 6126bis and described in detail in Section III.E of [BABEL-RTT]. However, hysteresis is not required, and the implementation may simply pick the route with the smallest metric. Rationale: hysteresis is only useful in congested and highly dynamic networks. In a typical home network, stable and uncongested, the feedback loop that hysteresis compensates for does not occur. OPT2: a Homenet implementation of Babel may include support for other extensions to the protocol, as long as they are known to interoperate with both the core protocol and source-specific routing. Rationale: a number of extensions to the Babel routing protocol have been defined over the years; however, they are useful in fairly specific situations, such as routing over global-scale overlay networks [BABEL-RTT] or multi-hop wireless networks with multiple radio frequencies [BABEL-Z]. Hence, with the exception of source-specific routing, no extensions are required for Homenet. 3. Interactions between HNCP and Babel The Homenet architecture cleanly separates configuration, which is done by HNCP, from routing, which is done by Babel. While the coupling between the two protocols is deliberately kept to a minimum, some interactions are unavoidable. All the interactions between HNCP and Babel consist of HNCP causing Babel to perform an announcement on its behalf (under no circumstances does Babel cause HNCP to perform an action). How this is realised is an implementation detail that is outside the scope of this document; while it could conceivably be done using a private Chroboczek Expires January 19, 2019 [Page 5] Internet-Draft Homenet Babel profile July 2018 communication channel between HNCP and Babel, in existing implementations HNCP installs a route in the operating system's kernel which is later picked up by Babel using the existing redistribution mechanisms. 3.1. Requirements REQ7: if an HNCP node receives a DHCPv6 prefix delegation for prefix P and publishes an External-Connection TLV containing a Delegated- Prefix TLV with prefix P and no Prefix-Policy TLV, then it MUST announce a source-specific default route with source prefix P over Babel. Rationale: source-specific routes are the main tool that Homenet uses to enable optimal routing in the presence of multiple IPv6 prefixes. External connections with non-trivial prefix policies are explicitly excluded from this requirement, since their exact behaviour is application-specific. REQ8: if an HNCP node receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway, then it MUST act as a NAT gateway and MUST announce a (non-specific) IPv4 default route over Babel. Rationale: the Homenet stack does not use source-specific routing for IPv4; instead, HNCP elects a single NAT gateway and publishes a single default route towards that gateway ([RFC7788] Section 6.5). REQ9: if an HNCP node assigns a prefix P to an attached link and announces P in an Assigned-Prefix TLV, then it MUST announce a route towards P over Babel. Rationale: prefixes assigned to links must be routable within the Homenet. 3.2. Optional features OPT3: an HNCP node that receives a DHCPv6 prefix delegation MAY announce a non-specific IPv6 default route over Babel in addition to the source-specific default route mandated by requirement REQ7. Rationale: since the source-specific default route is more specific than the non-specific default route, the former will override the latter if all nodes implement source-specific routing. Announcing an additional non-specific route is allowed, since doing that causes no harm and might simplify operations in Chroboczek Expires January 19, 2019 [Page 6] Internet-Draft Homenet Babel profile July 2018 some circumstances, e.g. when interoperating with a routing protocol that does not support source-specific routing. OPT4: an HNCP node that receives a DHCPv4 lease with an IPv4 address and wins the election for NAT gateway SHOULD NOT announce a source- specific IPv4 default route. Homenet does not require support for IPv4 source-specific routing. Announcing IPv4 source-specific routes will not cause routing pathologies (blackholes or routing loops), but it might cause packets sourced in different parts of the Homenet to follow different paths, with all the confusion that this entails. 4. Security Considerations Both HNCP and Babel carry their control data in IPv6 packets with a link-local source address, and implementations are required to drop packets sent from a global address. Hence, they are only susceptible to attacks from a directly connected link on which the HNCP and Babel implementations are listening. The security of a Homenet network relies on having a set of "Internal", "Ad Hoc" and "Hybrid" interfaces (Section 5.1 of [RFC7788]) that are assumed to be connected to links that are secured at a lower layer. HNCP and Babel packets are only accepted when they originate on these trusted links. "External" and "Guest" interfaces are connected to links that are not trusted, and any HNCP or Babel packets that are received on such interfaces are ignored. ("Leaf" interfaces are a special case, since they are connected to trusted links but HNCP and Babel traffic received on such interfaces is ignored.) This implies that the security of a Homenet network depends on the reliability of the border discovery procedure described in Section 5.3 of [RFC7788]. If untrusted links are used for transit, which is NOT RECOMMENDED, then any HNCP and Babel traffic that is carried over such links MUST be secured using an upper-layer security protocol. While both HNCP and Babel support cryptographic authentication, at the time of writing no protocol for autonomous configuration of HNCP and Babel security has been defined. 5. IANA Considerations This document requires no actions from IANA. Chroboczek Expires January 19, 2019 [Page 7] Internet-Draft Homenet Babel profile July 2018 6. Acknowledgments A number of people have helped with defining the requirements listed in this document. I am especially indebted to Barbara Stark and Markus Stenberg. 7. References 7.1. Normative References [BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", draft-ietf-babel-source-specific-03 (work in progress), August 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC6126bis] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", Internet Draft draft-ietf-babel-rfc6126bis-04, October 2017. [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 7.2. Informative References [BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", draft-jonglez- babel-rtt-extension-01 (work in progress), May 2015. [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", draft-chroboczek-babel-diversity-routing-01 (work in progress), February 2016. [DELAY-BASED] Jonglez, B. and J. Chroboczek, "A delay-based routing metric", March 2014. Available online from http://arxiv.org/abs/1403.3488 Chroboczek Expires January 19, 2019 [Page 8] Internet-Draft Homenet Babel profile July 2018 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, July 2014. [ToS-SPECIFIC] Chouasne, G., "https://tools.ietf.org/id/ draft-chouasne-babel-tos-specific-00.xml", draft-chouasne- babel-tos-specific-00 (work in progress), July 2017. Author's Address Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr Chroboczek Expires January 19, 2019 [Page 9] ./draft-ietf-anima-grasp-15.txt0000644000764400076440000054163513131667336015604 0ustar iustyiusty Network Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track B. Carpenter, Ed. Expires: January 8, 2018 Univ. of Auckland B. Liu, Ed. Huawei Technologies Co., Ltd July 7, 2017 A Generic Autonomic Signaling Protocol (GRASP) draft-ietf-anima-grasp-15 Abstract This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 8, 2018. Copyright Notice Copyright (c) 2017 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 Bormann, et al. Expires January 8, 2018 [Page 1] Internet-Draft GRASP July 2017 (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. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. High Level Deployment Model . . . . . . . . . . . . . . . 7 2.3. High Level Design . . . . . . . . . . . . . . . . . . . . 8 2.4. Quick Operating Overview . . . . . . . . . . . . . . . . 11 2.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 12 2.5.1. Required External Security Mechanism . . . . . . . . 12 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP . . . . 13 2.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 14 2.5.4. Discovery Mechanism and Procedures . . . . . . . . . 15 2.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 19 2.5.6. Synchronization and Flooding Procedures . . . . . . . 21 2.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 23 2.7. Session Identifier (Session ID) . . . . . . . . . . . . . 24 2.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 25 2.8.1. Message Overview . . . . . . . . . . . . . . . . . . 25 2.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 25 2.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 26 2.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 26 2.8.5. Discovery Response Message . . . . . . . . . . . . . 28 2.8.6. Request Messages . . . . . . . . . . . . . . . . . . 29 2.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 30 2.8.8. Negotiation End Message . . . . . . . . . . . . . . . 30 2.8.9. Confirm Waiting Message . . . . . . . . . . . . . 30 2.8.10. Synchronization Message . . . . . . . . . . . . . . . 31 2.8.11. Flood Synchronization Message . . . . . . . . . . . . 31 2.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 32 2.8.13. No Operation Message . . . . . . . . . . . . . . . . 33 2.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 33 2.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 33 2.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 33 2.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 34 2.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 34 2.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 34 2.10. Objective Options . . . . . . . . . . . . . . . . . . . . 36 2.10.1. Format of Objective Options . . . . . . . . . . . . 36 2.10.2. Objective flags . . . . . . . . . . . . . . . . . . 38 Bormann, et al. Expires January 8, 2018 [Page 2] Internet-Draft GRASP July 2017 2.10.3. General Considerations for Objective Options . . . . 38 2.10.4. Organizing of Objective Options . . . . . . . . . . 39 2.10.5. Experimental and Example Objective Options . . . . . 41 3. Implementation Status [RFC Editor: please remove] . . . . . . 41 3.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 41 3.2. Python Implementation . . . . . . . . . . . . . . . . . . 42 4. Security Considerations . . . . . . . . . . . . . . . . . . . 42 5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 49 8.2. Informative References . . . . . . . . . . . . . . . . . 50 Appendix A. Open Issues [RFC Editor: This section should be empty. Please remove] . . . . . . . . . . . . . . . 54 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 54 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 62 Appendix D. Example Message Formats . . . . . . . . . . . . . . 70 D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 71 D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 71 D.3. Synchronization Example . . . . . . . . . . . . . . . . . 71 D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 72 D.5. Complete Negotiation Example . . . . . . . . . . . . . . 72 Appendix E. Requirement Analysis of Discovery, Synchronization and Negotiation . . . . . . . . . . . . . . . . . . 73 E.1. Requirements for Discovery . . . . . . . . . . . . . . . 73 E.2. Requirements for Synchronization and Negotiation Capability . . . . . . . . . . . . . . . . . . . . . . . 75 E.3. Specific Technical Requirements . . . . . . . . . . . . . 77 Appendix F. Capability Analysis of Current Protocols . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 1. Introduction The success of the Internet has made IP-based networks bigger and more complicated. Large-scale ISP and enterprise networks have become more and more problematic for human based management. Also, operational costs are growing quickly. Consequently, there are increased requirements for autonomic behavior in the networks. General aspects of autonomic networks are discussed in [RFC7575] and [RFC7576]. One approach is to largely decentralize the logic of network management by migrating it into network elements. A reference model for autonomic networking on this basis is given in [I-D.ietf-anima-reference-model]. The reader should consult this document to understand how various autonomic components fit together. In order to fulfill autonomy, devices that embody Autonomic Service Bormann, et al. Expires January 8, 2018 [Page 3] Internet-Draft GRASP July 2017 Agents (ASAs, [RFC7575]) have specific signaling requirements. In particular they need to discover each other, to synchronize state with each other, and to negotiate parameters and resources directly with each other. There is no limitation on the types of parameters and resources concerned, which can include very basic information needed for addressing and routing, as well as anything else that might be configured in a conventional non-autonomic network. The atomic unit of discovery, synchronization or negotiation is referred to as a technical objective, i.e, a configurable parameter or set of parameters (defined more precisely in Section 2.1). Negotiation is an iterative process, requiring multiple message exchanges forming a closed loop between the negotiating entities. In fact, these entities are ASAs, normally but not necessarily in different network devices. State synchronization, when needed, can be regarded as a special case of negotiation, without iteration. Both negotiation and synchronization must logically follow discovery. More details of the requirements are found in Appendix E. Section 2.3 describes a behavior model for a protocol intended to support discovery, synchronization and negotiation. The design of GeneRic Autonomic Signaling Protocol (GRASP) in Section 2 of this document is based on this behavior model. The relevant capabilities of various existing protocols are reviewed in Appendix F. The proposed discovery mechanism is oriented towards synchronization and negotiation objectives. It is based on a neighbor discovery process on the local link, but also supports diversion to peers on other links. There is no assumption of any particular form of network topology. When a device starts up with no pre-configuration, it has no knowledge of the topology. The protocol itself is capable of being used in a small and/or flat network structure such as a small office or home network as well as in a large professionally managed network. Therefore, the discovery mechanism needs to be able to allow a device to bootstrap itself without making any prior assumptions about network structure. Because GRASP can be used as part of a decision process among distributed devices or between networks, it must run in a secure and strongly authenticated environment. In realistic deployments, not all devices will support GRASP. Therefore, some autonomic service agents will directly manage a group of non-autonomic nodes, and other non-autonomic nodes will be managed traditionally. Such mixed scenarios are not discussed in this specification. Bormann, et al. Expires January 8, 2018 [Page 4] Internet-Draft GRASP July 2017 2. GRASP Protocol Overview 2.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words. This document uses terminology defined in [RFC7575]. The following additional terms are used throughout this document: o Discovery: a process by which an ASA discovers peers according to a specific discovery objective. The discovery results may be different according to the different discovery objectives. The discovered peers may later be used as negotiation counterparts or as sources of synchronization data. o Negotiation: a process by which two ASAs interact iteratively to agree on parameter settings that best satisfy the objectives of both ASAs. o State Synchronization: a process by which ASAs interact to receive the current state of parameter values stored in other ASAs. This is a special case of negotiation in which information is sent but the ASAs do not request their peers to change parameter settings. All other definitions apply to both negotiation and synchronization. o Technical Objective (usually abbreviated as Objective): A technical objective is a data structure, whose main contents are a name and a value. The value consists of a single configurable parameter or a set of parameters of some kind. The exact format of an objective is defined in Section 2.10.1. An objective occurs in three contexts: Discovery, Negotiation and Synchronization. Normally, a given objective will not occur in negotiation and synchronization contexts simultaneously. * One ASA may support multiple independent objectives. * The parameter(s) in the value of a given objective apply to a specific service or function or action. They may in principle be anything that can be set to a specific logical, numerical or string value, or a more complex data structure, by a network Bormann, et al. Expires January 8, 2018 [Page 5] Internet-Draft GRASP July 2017 node. Each node is expected to contain one or more ASAs which may each manage subsidiary non-autonomic nodes. * Discovery Objective: an objective in the process of discovery. Its value may be undefined. * Synchronization Objective: an objective whose specific technical content needs to be synchronized among two or more ASAs. Thus, each ASA will maintain its own copy of the objective. * Negotiation Objective: an objective whose specific technical content needs to be decided in coordination with another ASA. Again, each ASA will maintain its own copy of the objective. A detailed discussion of objectives, including their format, is found in Section 2.10. o Discovery Initiator: an ASA that starts discovery by sending a discovery message referring to a specific discovery objective. o Discovery Responder: a peer that either contains an ASA supporting the discovery objective indicated by the discovery initiator, or caches the locator(s) of the ASA(s) supporting the objective. It sends a Discovery Response, as described later. o Synchronization Initiator: an ASA that starts synchronization by sending a request message referring to a specific synchronization objective. o Synchronization Responder: a peer ASA which responds with the value of a synchronization objective. o Negotiation Initiator: an ASA that starts negotiation by sending a request message referring to a specific negotiation objective. o Negotiation Counterpart: a peer with which the Negotiation Initiator negotiates a specific negotiation objective. o GRASP Instance: This refers to an instantiation of a GRASP protocol engine, likely including multiple threads or processes as well as dynamic data structures such as a discovery cache, running in a given security environment on a single device. o GRASP Core: This refers to the code and shared data structures of a GRASP instance, which will communicate with individual ASAs via a suitable Application Programming Interface (API). Bormann, et al. Expires January 8, 2018 [Page 6] Internet-Draft GRASP July 2017 o Interface or GRASP Interface: Unless otherwise stated, these refer to a network interface - which might be physical or virtual - that a specific instance of GRASP is currently using. A device might have other interfaces that are not used by GRASP and which are outside the scope of the autonomic network. 2.2. High Level Deployment Model A GRASP implementation will be part of the Autonomic Networking Infrastructure (ANI) in an autonomic node, which must also provide an appropriate security environment. In accordance with [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. As a result, all autonomic nodes in the ACP are able to trust each other. It is expected that GRASP will access the ACP by using a typical socket programming interface and the ACP will make available only network interfaces within the autonomic network. If there is no ACP, the considerations described in Section 2.5.1 apply. There will also be one or more Autonomic Service Agents (ASAs). In the minimal case of a single-purpose device, these components might be fully integrated with GRASP and the ACP. A more common model is expected to be a multi-purpose device capable of containing several ASAs, such as a router or large switch. In this case it is expected that the ACP, GRASP and the ASAs will be implemented as separate processes, which are able to support asynchronous and simultaneous operations, for example by multi-threading. In some scenarios, a limited negotiation model might be deployed based on a limited trust relationship such as that between two administrative domains. ASAs might then exchange limited information and negotiate some particular configurations. GRASP is explicitly designed to operate within a single addressing realm. Its discovery and flooding mechanisms do not support autonomic operations that cross any form of address translator or upper layer proxy. A suitable Application Programming Interface (API) will be needed between GRASP and the ASAs. In some implementations, ASAs would run in user space with a GRASP library providing the API, and this library would in turn communicate via system calls with core GRASP functions. Details of the API are out of scope for the present document. For further details of possible deployment models, see [I-D.ietf-anima-reference-model]. An instance of GRASP must be aware of the network interfaces it will use, and of the appropriate global-scope and link-local addresses. Bormann, et al. Expires January 8, 2018 [Page 7] Internet-Draft GRASP July 2017 In the presence of the ACP, such information will be available from the adjacency table discussed in [I-D.ietf-anima-reference-model]. In other cases, GRASP must determine such information for itself. Details depend on the device and operating system. In the rest of this document, the terms 'interfaces' or 'GRASP interfaces' refers only to the set of network interfaces that a specific instance of GRASP is currently using. Because GRASP needs to work with very high reliability, especially during bootstrapping and during fault conditions, it is essential that every implementation continues to operate in adverse conditions. For example, discovery failures, or any kind of socket exception at any time, must not cause irrecoverable failures in GRASP itself, and must return suitable error codes through the API so that ASAs can also recover. GRASP must not depend upon non-volatile data storage. All run time error conditions, and events such as address renumbering, network interface failures, and CPU sleep/wake cycles, must be handled in such a way that GRASP will still operate correctly and securely (Section 2.5.1) afterwards. An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. Possible exceptions are mentioned below. 2.3. High Level Design This section describes the behavior model and general design of GRASP, supporting discovery, synchronization and negotiation, to act as a platform for different technical objectives. o A generic platform: The protocol design is generic and independent of the synchronization or negotiation contents. The technical contents will vary according to the various technical objectives and the different pairs of counterparts. o Normally, a single main instance of the GRASP protocol engine will exist in an autonomic node, and each ASA will run as an independent asynchronous process. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are possible (Section 2.5.2). In this case, each instance MUST listen independently for GRASP link- local multicasts, and all instances MUST be woken by each such multicast, in order for discovery and flooding to work correctly. Bormann, et al. Expires January 8, 2018 [Page 8] Internet-Draft GRASP July 2017 o Security infrastructure: As noted above, the protocol itself has no built-in security functionality, and relies on a separate secure infrastructure. o Discovery, synchronization and negotiation are designed together: The discovery method and the synchronization and negotiation methods are designed in the same way and can be combined when this is useful, allowing a rapid mode of operation described in Section 2.5.4. These processes can also be performed independently when appropriate. * Thus, for some objectives, especially those concerned with application layer services, another discovery mechanism such as the future DNS Service Discovery [RFC7558] MAY be used. The choice is left to the designers of individual ASAs. o A uniform pattern for technical objectives: The synchronization and negotiation objectives are defined according to a uniform pattern. The values that they contain could be carried either in a simple binary format or in a complex object format. The basic protocol design uses the Concise Binary Object Representation (CBOR) [RFC7049], which is readily extensible for unknown future requirements. o A flexible model for synchronization: GRASP supports synchronization between two nodes, which could be used repeatedly to perform synchronization among a small number of nodes. It also supports an unsolicited flooding mode when large groups of nodes, possibly including all autonomic nodes, need data for the same technical objective. * There may be some network parameters for which a more traditional flooding mechanism such as DNCP [RFC7787] is considered more appropriate. GRASP can coexist with DNCP. o A simple initiator/responder model for negotiation: Multi-party negotiations are very complicated to model and cannot readily be guaranteed to converge. GRASP uses a simple bilateral model and can support multi-party negotiations by indirect steps. Bormann, et al. Expires January 8, 2018 [Page 9] Internet-Draft GRASP July 2017 o Organizing of synchronization or negotiation content: The technical content transmitted by GRASP will be organized according to the relevant function or service. The objectives for different functions or services are kept separate, because they may be negotiated or synchronized with different counterparts or have different response times. Thus a normal arrangement would be a single ASA managing a small set of closely related objectives, with a version of that ASA in each relevant autonomic node. Further discussion of this aspect is out of scope for the current document. o Requests and responses in negotiation procedures: The initiator can negotiate a specific negotiation objective with relevant counterpart ASAs. It can request relevant information from a counterpart so that it can coordinate its local configuration. It can request the counterpart to make a matching configuration. It can request simulation or forecast results by sending some dry run conditions. Beyond the traditional yes/no answer, the responder can reply with a suggested alternative value for the objective concerned. This would start a bi-directional negotiation ending in a compromise between the two ASAs. o Convergence of negotiation procedures: To enable convergence, when a responder suggests a new value or condition in a negotiation step reply, it should be as close as possible to the original request or previous suggestion. The suggested value of later negotiation steps should be chosen between the suggested values from the previous two steps. GRASP provides mechanisms to guarantee convergence (or failure) in a small number of steps, namely a timeout and a maximum number of iterations. o Extensibility: GRASP intentionally does not have a version number, and can be extended by adding new message types and options. The Invalid Message (M_INVALID) will be used to signal that an implementation does not recognize a message or option sent by another Bormann, et al. Expires January 8, 2018 [Page 10] Internet-Draft GRASP July 2017 implementation. In normal use, new semantics will be added by defining new synchronization or negotiation objectives. 2.4. Quick Operating Overview An instance of GRASP is expected to run as a separate core module, providing an API (such as [I-D.liu-anima-grasp-api]) to interface to various ASAs. These ASAs may operate without special privilege, unless they need it for other reasons (such as configuring IP addresses or manipulating routing tables). The GRASP mechanisms used by the ASA are built around GRASP objectives defined as data structures containing administrative information such as the objective's unique name, and its current value. The format and size of the value is not restricted by the protocol, except that it must be possible to serialize it for transmission in CBOR, which is no restriction at all in practice. GRASP provides the following mechanisms: o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA can discover other ASAs supporting a given objective. o A negotiation request mechanism (M_REQ_NEG), by which an ASA can start negotiation of an objective with a counterpart ASA. Once a negotiation has started, the process is symmetrical, and there is a negotiation step message (M_NEGOTIATE) for each ASA to use in turn. Two other functions support negotiating steps (M_WAIT, M_END). o A synchronization mechanism (M_REQ_SYN), by which an ASA can request the current value of an objective from a counterpart ASA. With this, there is a corresponding response function (M_SYNCH) for an ASA that wishes to respond to synchronization requests. o A flood mechanism (M_FLOOD), by which an ASA can cause the current value of an objective to be flooded throughout the autonomic network so that any ASA can receive it. One application of this is to act as an announcement, avoiding the need for discovery of a widely applicable objective. Some example messages and simple message flows are provided in Appendix D. Bormann, et al. Expires January 8, 2018 [Page 11] Internet-Draft GRASP July 2017 2.5. GRASP Protocol Basic Properties and Mechanisms 2.5.1. Required External Security Mechanism GRASP does not specify transport security because it is meant to be adapted to different environments. Every solution adopting GRASP MUST specify a security and transport substrate used by GRASP in that solution. The substrate MUST enforce sending and receiving GRASP messages only between members of a mutually trusted group running GRASP. Each group member is an instance of GRASP. The group members are nodes of a connected graph. The group and graph is created by the security and transport substrate and called the GRASP domain. The substrate must support unicast messages between any group members and (link- local) multicast messages between adjacent group members. It must deny messages between group members and non group members. With this model, security is provided by enforcing group membership, but any member of the trusted group can attack the entire network until revoked. Substrates MUST use cryptographic member authentication and message integrity for GRASP messages. This can be end-to-end or hop-by-hop across the domain. The security and transport substrate MUST provide mechanisms to remove untrusted members from the group. If the substrate does not mandate and enforce GRASP message encryption then any service using GRASP in such a solution MUST provide protection and encryption for message elements whose exposure could constitute an attack vector. The security and transport substrate for GRASP in the ANI is the ACP. Unless otherwise noted, we assume this security and transport substrate in the remainder of this document. The ACP does mandate the use of encryption; therefore GRASP in the ANI can rely on GRASP message being encrypted. The GRASP domain is the ACP: all nodes in an autonomic domain connected by encrypted virtual links formed by the ACP. The ACP uses hop-by-hop security (authentication/ encryption) of messages. Removal of nodes relies on standard PKI certificate revocation or expiry of sufficiently short lived certificates. Refer to [I-D.ietf-anima-autonomic-control-plane] for more details. As mentioned in Section 2.3, some GRASP operations might be performed across an administrative domain boundary by mutual agreement, without the benefit of an ACP. Such operations MUST be confined to a separate instance of GRASP with its own copy of all GRASP data structures running across a separate GRASP domain with a security and Bormann, et al. Expires January 8, 2018 [Page 12] Internet-Draft GRASP July 2017 transport substrate. In the most simple case, each point-to-point interdomain GRASP peering could be a separate domain and the security and transport substrate could be built using transport or network layer security protocols. This is subject to future specifications. An exception to the requirements for the security and transport substrate exists for highly constrained subsets of GRASP meant to support the establishment of a security and transport substrate, described in the following section. 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP Some services may need to use insecure GRASP discovery, response and flood messages without being able to use pre-existing security associations, for example as part of discovery for establishing security associations such as a security substrate for GRASP. Such operations being intrinsically insecure, they need to be confined to link-local use to minimize the risk of malicious actions. Possible examples include discovery of candidate ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps initialization services in networks using GRASP without being fully autonomic (e.g., no ACP). Such usage MUST be limited to link-local operations on a single interface and MUST be confined to a separate insecure instance of GRASP with its own copy of all GRASP data structures. This instance is nicknamed DULL - Discovery Unsolicited Link-Local. The detailed rules for the DULL instance of GRASP are as follows: o An initiator MAY send Discovery or Flood Synchronization link- local multicast messages which MUST have a loop count of 1, to prevent off-link operations. Other unsolicited GRASP message types MUST NOT be sent. o A responder MUST silently discard any message whose loop count is not 1. o A responder MUST silently discard any message referring to a GRASP Objective that is not directly part of a service that requires this insecure mode. o A responder MUST NOT relay any multicast messages. o A Discovery Response MUST indicate a link-local address. o A Discovery Response MUST NOT include a Divert option. Bormann, et al. Expires January 8, 2018 [Page 13] Internet-Draft GRASP July 2017 o A node MUST silently discard any message whose source address is not link-local. To minimize traffic possibly observed by third parties, GRASP traffic SHOULD be minimized by using only Flood Synchronization to announce objectives and their associated locators, rather than by using Discovery and Response. Further details are out of scope for this document 2.5.3. Transport Layer Usage All GRASP messages, after they are serialized as a CBOR byte string, are transmitted as such directly over the transport protocol in use. The transport protocol(s) for a GRASP domain are specified by the security and transport substrate as introduced in Section 2.5.1. GRASP discovery and flooding messages are designed for GRASP domain wide flooding through hop-by-hop link-local multicast forwarding between adjacent GRASP nodes. The GRASP security and transport substrate needs to specify how these link local multicasts are transported. This can be unreliable transport (UDP) but it SHOULD be reliable transport (e.g., TCP). If the substrate specifies an unreliable transport such as UDP for discovery and flooding messages, then it MUST NOT use IP fragmentation because of its loss characteristic, especially in multi-hop flooding. GRASP MUST then enforce at the user API level a limit to the size of discovery and flooding messages, so that no fragmentation can occur. For IPv6 transport this means that those messages must be at most 1280 bytes sized IPv6 packets (unless there is a known larger minimum link MTU across the whole GRASP domain). All other GRASP messages are unicast beteween group members of the GRASP domain. These MUST use a reliable transport protocol because GRASP itself does not provide for error detection, retransmission or flow control. Unless otherwise specified by the security and transport substrate, TCP MUST be used. The security and transport substrate for GRASP in the ANI is the ACP. Unless otherwise noted, we assume this security and transport substrate in the remainder of this document when describing GRASPs message transport. In the ACP, TCP is used for GRASP unicast messages. GRASP discovery and flooding messages also use TCP: These link-local messages are forwarded by replicating them to all adjacent GRASP nodes on the link via TCP connections to those adjacent GRASP nodes. Because of this, GRASP in the ANI has no limitations on the size of discovery and flooding messages with respect to fragmentation Bormann, et al. Expires January 8, 2018 [Page 14] Internet-Draft GRASP July 2017 issues. UDP is used in the ANI with GRASP only with DULL when the ACP is built to discover ACP/GRASP neighbors on links. For link-local UDP multicast, the GRASP protocol listens to the well- known GRASP Listen Port (Section 2.6). Transport connections for Discovery and Flooding on relay nodes must terminate in GRASP instances (eg: GRASP ASAs) so that link-local multicast, hop-by-hop flooding of M_DISCOVERY and M_FLOOD and hop-by-hop forwarding of M_RESPONSE and caching of those responses along the path work correctly. Unicast transport connections used for synchronization and negotiation can terminate directly in ASAs that implement objectives and therefore this traffic does not need to pass through GRASP instances. For this, the ASA listens on its own dynamically assigned ports, which are communicated to its peers during discovery. Alternatively, the GRASP instance can also terminate the unicast transport connections and pass the traffic from/to the ASA if that is preferrable in some implementation (eg: to better decouple ASAs from network connections). 2.5.4. Discovery Mechanism and Procedures 2.5.4.1. Separated discovery and negotiation mechanisms Although discovery and negotiation or synchronization are defined together in GRASP, they are separate mechanisms. The discovery process could run independently from the negotiation or synchronization process. Upon receiving a Discovery (Section 2.8.4) message, the recipient node should return a response message in which it either indicates itself as a discovery responder or diverts the initiator towards another more suitable ASA. However, this response may be delayed if the recipient needs to relay the discovery onwards, as described below. The discovery action (M_DISCOVERY) will normally be followed by a negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The discovery results could be utilized by the negotiation protocol to decide which ASA the initiator will negotiate with. The initiator of a discovery action for a given objective need not be capable of responding to that objective as a Negotiation Counterpart, as a Synchronization Responder or as source for flooding. For example, an ASA might perform discovery even if it only wishes to act a Synchronization Initiator or Negotiation Initiator. Such an ASA does not itself need to respond to discovery messages. Bormann, et al. Expires January 8, 2018 [Page 15] Internet-Draft GRASP July 2017 It is also entirely possible to use GRASP discovery without any subsequent negotiation or synchronization action. In this case, the discovered objective is simply used as a name during the discovery process and any subsequent operations between the peers are outside the scope of GRASP. 2.5.4.2. Discovery Overview A complete discovery process will start with a multicast (of M_DISCOVERY) on the local link. On-link neighbors supporting the discovery objective will respond directly (with M_RESPONSE). A neighbor with multiple interfaces may respond with a cached discovery response. If it has no cached response, it will relay the discovery on its other GRASP interfaces. If a node receiving the relayed discovery supports the discovery objective, it will respond to the relayed discovery. If it has a cached response, it will respond with that. If not, it will repeat the discovery process, which thereby becomes iterative. The loop count and timeout will ensure that the process ends. Further details are given below. A Discovery message MAY be sent unicast to a peer node, which SHOULD then proceed exactly as if the message had been multicast, except that when TCP is used, the response will be on the same socket as the query. However, this mode does not guarantee successful discovery in the general case. 2.5.4.3. Discovery Procedures Discovery starts as an on-link operation. The Divert option can tell the discovery initiator to contact an off-link ASA for that discovery objective. If the security and transport substrate of the GRASP domain (see Section 2.5.3) uses UDP link-local multicast then the discovery initiator sends these to the ALL_GRASP_NEIGHBORS link-local multicast address (Section 2.6) and and all GRASP nodes need to listen to this address to act as discovery responder. Because this port is unique in a device, this is a function of the GRASP instance and not of an individual ASA. As a result, each ASA will need to register the objectives that it supports with the local GRASP instance. If an ASA in a neighbor device supports the requested discovery objective, the device SHOULD respond to the link-local multicast with a unicast Discovery Response message (Section 2.8.5) with locator option(s), unless it is temporarily unavailable. Otherwise, if the neighbor has cached information about an ASA that supports the requested discovery objective (usually because it discovered the same objective before), it SHOULD respond with a Discovery Response message with a Divert option pointing to the appropriate Discovery Bormann, et al. Expires January 8, 2018 [Page 16] Internet-Draft GRASP July 2017 Responder. However, it SHOULD NOT respond with a cached response on an interface if it learnt that information from the same interface, because the peer in question will answer directly if still operational. If a device has no information about the requested discovery objective, and is not acting as a discovery relay (see below) it MUST silently discard the Discovery message. The discovery initiator MUST set a reasonable timeout on the discovery process. A suggested value is 100 milliseconds multiplied by the loop count embedded in the objective. If no discovery response is received within the timeout, the Discovery message MAY be repeated, with a newly generated Session ID (Section 2.7). An exponential backoff SHOULD be used for subsequent repetitions, to limit the load during busy periods. The details of the backoff algorithm will depend on the use case for the objective concerned but MUST be consistent with the recommendations in [RFC8085] for low data-volume multicast. Frequent repetition might be symptomatic of a denial of service attack. After a GRASP device successfully discovers a locator for a Discovery Responder supporting a specific objective, it SHOULD cache this information, including the interface index [RFC3493] via which it was discovered. This cache record MAY be used for future negotiation or synchronization, and the locator SHOULD be passed on when appropriate as a Divert option to another Discovery Initiator. The cache mechanism MUST include a lifetime for each entry. The lifetime is derived from a time-to-live (ttl) parameter in each Discovery Response message. Cached entries MUST be ignored or deleted after their lifetime expires. In some environments, unplanned address renumbering might occur. In such cases, the lifetime SHOULD be short compared to the typical address lifetime. The discovery mechanism needs to track the node's current address to ensure that Discovery Responses always indicate the correct address. If multiple Discovery Responders are found for the same objective, they SHOULD all be cached, unless this creates a resource shortage. The method of choosing between multiple responders is an implementation choice. This choice MUST be available to each ASA but the GRASP implementation SHOULD provide a default choice. Because Discovery Responders will be cached in a finite cache, they might be deleted at any time. In this case, discovery will need to be repeated. If an ASA exits for any reason, its locator might still Bormann, et al. Expires January 8, 2018 [Page 17] Internet-Draft GRASP July 2017 be cached for some time, and attempts to connect to it will fail. ASAs need to be robust in these circumstances. 2.5.4.4. Discovery Relaying A GRASP instance with multiple link-layer interfaces (typically running in a router) MUST support discovery on all GRASP interfaces. We refer to this as a 'relaying instance'. DULL Instances (Section 2.5.2) are always single-interface instances and therefore MUST NOT perform discovery relaying. If a relaying instance receives a Discovery message on a given interface for a specific objective that it does not support and for which it has not previously cached a Discovery Responder, it MUST relay the query by re-issuing a new Discovery message as a link-local multicast on its other GRASP interfaces. The relayed discovery message MUST have the same Session ID and Initiator field as the incoming (see Section 2.8.4). The Initiator IP address field is only used to allow for disambiguation of the Session ID and is never used to address Response packets. Response packets are sent back to the relaying instance, not the original initiator. The M_DISCOVERY message does not encode the transport address of the originator or relay. Response packets must therefore be sent to the transport layer address of the connection on which the M_DISCOVERY message was received. If the M_DISCOVERY was relayed via a reliable hop-by-hop transport connection, the response is simply sent back via the same connection. If the M_DISCOVERY was relayed via link-local (eg: UDP) multicast, the response is sent back via a reliable hop-by-hop transport connection with the same port number as the source port of the link- local multicast. Therefore, if link-local multicast is used and M_RESPONSE messages are required (which is the case in almost all GRASP instances except for the limited use of DULL instances in the ANI), GRASP needs to be able to bind to one port number on UDP from which to originate the link-local multicast M_DISCOVERY messages and the same port number on the reliable hop-by-hop transport (eg: TCP by default) to be able to respond to transport connections from responders that want to send M_RESPONSE messages back. Note that this port does not need to be the GRASP_LISTEN_PORT. The relaying instance MUST decrement the loop count within the objective, and MUST NOT relay the Discovery message if the result is zero. Also, it MUST limit the total rate at which it relays Bormann, et al. Expires January 8, 2018 [Page 18] Internet-Draft GRASP July 2017 discovery messages to a reasonable value, in order to mitigate possible denial of service attacks. For example, the rate limit could be set to a small multiple of the observed rate of discovery messages during normal operation. The relaying instance MUST cache the Session ID value and initiator address of each relayed Discovery message until any Discovery Responses have arrived or the discovery process has timed out. To prevent loops, it MUST NOT relay a Discovery message which carries a given cached Session ID and initiator address more than once. These precautions avoid discovery loops and mitigate potential overload. Since the relay device is unaware of the timeout set by the original initiator it SHOULD set a suitable timeout for the relayed discovery. A suggested value is 100 milliseconds multiplied by the remaining loop count. The discovery results received by the relaying instance MUST in turn be sent as a Discovery Response message to the Discovery message that caused the relay action. 2.5.4.5. Rapid Mode (Discovery with Negotiation or Synchronization ) A Discovery message MAY include an Objective option. This allows a rapid mode of negotiation (Section 2.5.5.1) or synchronization (Section 2.5.6.3). Rapid mode is currently limited to a single objective for simplicity of design and implementation. A possible future extension is to allow multiple objectives in rapid mode for greater efficiency. 2.5.5. Negotiation Procedures A negotiation initiator opens a transport connection to a counterpart ASA using the address, protocol and port obtained during discovery. It then sends a negotiation request (using M_REQ_NEG) to the counterpart, including a specific negotiation objective. It may request the negotiation counterpart to make a specific configuration. Alternatively, it may request a certain simulation or forecast result by sending a dry run configuration. The details, including the distinction between a dry run and a live configuration change, will be defined separately for each type of negotiation objective. Any state associated with a dry run operation, such as temporarily reserving a resource for subsequent use in a live run, is entirely a matter for the designer of the ASA concerned. Each negotiation session as a whole is subject to a timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 2.6), initialised when the request is sent (see Section 2.8.6). If no reply message of any kind is received within the timeout, the negotiation request MAY be Bormann, et al. Expires January 8, 2018 [Page 19] Internet-Draft GRASP July 2017 repeated, with a newly generated Session ID (Section 2.7). An exponential backoff SHOULD be used for subsequent repetitions. The details of the backoff algorithm will depend on the use case for the objective concerned. If the counterpart can immediately apply the requested configuration, it will give an immediate positive (O_ACCEPT) answer (using M_END). This will end the negotiation phase immediately. Otherwise, it will negotiate (using M_NEGOTIATE). It will reply with a proposed alternative configuration that it can apply (typically, a configuration that uses fewer resources than requested by the negotiation initiator). This will start a bi-directional negotiation (using M_NEGOTIATE) to reach a compromise between the two ASAs. The negotiation procedure is ended when one of the negotiation peers sends a Negotiation Ending (M_END) message, which contains an accept (O_ACCEPT) or decline (O_DECLINE) option and does not need a response from the negotiation peer. Negotiation may also end in failure (equivalent to a decline) if a timeout is exceeded or a loop count is exceeded. When the procedure ends for whatever reason, the transport connection SHOULD be closed. A transport session failure is treated as a negotiation failure. A negotiation procedure concerns one objective and one counterpart. Both the initiator and the counterpart may take part in simultaneous negotiations with various other ASAs, or in simultaneous negotiations about different objectives. Thus, GRASP is expected to be used in a multi-threaded mode or its logical equivalent. Certain negotiation objectives may have restrictions on multi-threading, for example to avoid over-allocating resources. Some configuration actions, for example wavelength switching in optical networks, might take considerable time to execute. The ASA concerned needs to allow for this by design, but GRASP does allow for a peer to insert latency in a negotiation process if necessary (Section 2.8.9, M_WAIT). 2.5.5.1. Rapid Mode (Discovery/Negotiation Linkage) A Discovery message MAY include a Negotiation Objective option. In this case it is as if the initiator sent the sequence M_DISCOVERY, immediately followed by M_REQ_NEG. This has implications for the construction of the GRASP core, as it must carefully pass the contents of the Negotiation Objective option to the ASA so that it may evaluate the objective directly. When a Negotiation Objective option is present the ASA replies with an M_NEGOTIATE message (or M_END with O_ACCEPT if it is immediately satisfied with the Bormann, et al. Expires January 8, 2018 [Page 20] Internet-Draft GRASP July 2017 proposal), rather than with an M_RESPONSE. However, if the recipient node does not support rapid mode, discovery will continue normally. It is possible that a Discovery Response will arrive from a responder that does not support rapid mode, before such a Negotiation message arrives. In this case, rapid mode will not occur. This rapid mode could reduce the interactions between nodes so that a higher efficiency could be achieved. However, a network in which some nodes support rapid mode and others do not will have complex timing-dependent behaviors. Therefore, the rapid negotiation function SHOULD be disabled by default. 2.5.6. Synchronization and Flooding Procedures 2.5.6.1. Unicast Synchronization A synchronization initiator opens a transport connection to a counterpart ASA using the address, protocol and port obtained during discovery. It then sends a synchronization request (using M_REQ_SYN) to the counterpart, including a specific synchronization objective. The counterpart responds with a Synchronization message (M_SYNCH, Section 2.8.10) containing the current value of the requested synchronization objective. No further messages are needed and the transport connection SHOULD be closed. A transport session failure is treated as a synchronization failure. If no reply message of any kind is received within a given timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 2.6), the synchronization request MAY be repeated, with a newly generated Session ID (Section 2.7). An exponential backoff SHOULD be used for subsequent repetitions. The details of the backoff algorithm will depend on the use case for the objective concerned. 2.5.6.2. Flooding In the case just described, the message exchange is unicast and concerns only one synchronization objective. For large groups of nodes requiring the same data, synchronization flooding is available. For this, a flooding initiator MAY send an unsolicited Flood Synchronization message containing one or more Synchronization Objective option(s), if and only if the specification of those objectives permits it. This is sent as a multicast message to the ALL_GRASP_NEIGHBORS multicast address (Section 2.6). Receiving flood multicasts is a function of the GRASP core, as in the case of discovery multicasts (Section 2.5.4.3). Bormann, et al. Expires January 8, 2018 [Page 21] Internet-Draft GRASP July 2017 To ensure that flooding does not result in a loop, the originator of the Flood Synchronization message MUST set the loop count in the objectives to a suitable value (the default is GRASP_DEF_LOOPCT). Also, a suitable mechanism is needed to avoid excessive multicast traffic. This mechanism MUST be defined as part of the specification of the synchronization objective(s) concerned. It might be a simple rate limit or a more complex mechanism such as the Trickle algorithm [RFC6206]. A GRASP device with multiple link-layer interfaces (typically a router) MUST support synchronization flooding on all GRASP interfaces. If it receives a multicast Flood Synchronization message on a given interface, it MUST relay it by re-issuing a Flood Synchronization message as a link-local multicast on its other GRASP interfaces. The relayed message MUST have the same Session ID as the incoming message and MUST be tagged with the IP address of its original initiator. Link-layer Flooding is supported by GRASP by setting the loop count to 1, and sending with a link-local source address. Floods with link-local source addresses and a loop count other than 1 are invalid, and such messages MUST be discarded. The relaying device MUST decrement the loop count within the first objective, and MUST NOT relay the Flood Synchronization message if the result is zero. Also, it MUST limit the total rate at which it relays Flood Synchronization messages to a reasonable value, in order to mitigate possible denial of service attacks. For example, the rate limit could be set to a small multiple of the observed rate of flood messages during normal operation. The relaying device MUST cache the Session ID value and initiator address of each relayed Flood Synchronization message for a time not less than twice GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay a Flood Synchronization message which carries a given cached Session ID and initiator address more than once. These precautions avoid synchronization loops and mitigate potential overload. Note that this mechanism is unreliable in the case of sleeping nodes, or new nodes that join the network, or nodes that rejoin the network after a fault. An ASA that initiates a flood SHOULD repeat the flood at a suitable frequency, which MUST be consistent with the recommendations in [RFC8085] for low data-volume multicast. The ASA SHOULD also act as a synchronization responder for the objective(s) concerned. Thus nodes that require an objective subject to flooding can either wait for the next flood or request unicast synchronization for that objective. Bormann, et al. Expires January 8, 2018 [Page 22] Internet-Draft GRASP July 2017 The multicast messages for synchronization flooding are subject to the security rules in Section 2.5.1. In practice this means that they MUST NOT be transmitted and MUST be ignored on receipt unless there is an operational ACP or equivalent strong security in place. However, because of the security weakness of link-local multicast (Section 4), synchronization objectives that are flooded SHOULD NOT contain unencrypted private information and SHOULD be validated by the recipient ASA. 2.5.6.3. Rapid Mode (Discovery/Synchronization Linkage) A Discovery message MAY include a Synchronization Objective option. In this case the Discovery message also acts as a Request Synchronization message to indicate to the Discovery Responder that it could directly reply to the Discovery Initiator with a Synchronization message Section 2.8.10 with synchronization data for rapid processing, if the discovery target supports the corresponding synchronization objective. The design implications are similar to those discussed in Section 2.5.5.1. It is possible that a Discovery Response will arrive from a responder that does not support rapid mode, before such a Synchronization message arrives. In this case, rapid mode will not occur. This rapid mode could reduce the interactions between nodes so that a higher efficiency could be achieved. However, a network in which some nodes support rapid mode and others do not will have complex timing-dependent behaviors. Therefore, the rapid synchronization function SHOULD be configured off by default and MAY be configured on or off by Intent. 2.6. GRASP Constants o ALL_GRASP_NEIGHBORS A link-local scope multicast address used by a GRASP-enabled device to discover GRASP-enabled neighbor (i.e., on-link) devices. All devices that support GRASP are members of this multicast group. * IPv6 multicast address: TBD1 * IPv4 multicast address: TBD2 o GRASP_LISTEN_PORT (TBD3) A well-known UDP user port that every GRASP-enabled network device MUST listen to for link-local multicasts when UDP is used for Bormann, et al. Expires January 8, 2018 [Page 23] Internet-Draft GRASP July 2017 M_DISCOVERY or M_FLOOD messages in the GRASP instance This user port MAY also be used to listen for TCP or UDP unicast messages in a simple implementation of GRASP (Section 2.5.3). o GRASP_DEF_TIMEOUT (60000 milliseconds) The default timeout used to determine that an operation has failed to complete. o GRASP_DEF_LOOPCT (6) The default loop count used to determine that a negotiation has failed to complete, and to avoid looping messages. o GRASP_DEF_MAX_SIZE (2048) The default maximum message size in bytes. 2.7. Session Identifier (Session ID) This is an up to 32-bit opaque value used to distinguish multiple sessions between the same two devices. A new Session ID MUST be generated by the initiator for every new Discovery, Flood Synchronization or Request message. All responses and follow-up messages in the same discovery, synchronization or negotiation procedure MUST carry the same Session ID. The Session ID SHOULD have a very low collision rate locally. It MUST be generated by a pseudo-random number generator (PRNG) using a locally generated seed which is unlikely to be used by any other device in the same network. The PRNG SHOULD be cryptographically strong [RFC4086]. When allocating a new Session ID, GRASP MUST check that the value is not already in use and SHOULD check that it has not been used recently, by consulting a cache of current and recent sessions. In the unlikely event of a clash, GRASP MUST generate a new value. However, there is a finite probability that two nodes might generate the same Session ID value. For that reason, when a Session ID is communicated via GRASP, the receiving node MUST tag it with the initiator's IP address to allow disambiguation. In the highly unlikely event of two peers opening sessions with the same Session ID value, this tag will allow the two sessions to be distinguished. Multicast GRASP messages and their responses, which may be relayed between links, therefore include a field that carries the initiator's global IP address. Bormann, et al. Expires January 8, 2018 [Page 24] Internet-Draft GRASP July 2017 There is a highly unlikely race condition in which two peers start simultaneous negotiation sessions with each other using the same Session ID value. Depending on various implementation choices, this might lead to the two sessions being confused. See Section 2.8.6 for details of how to avoid this. 2.8. GRASP Messages 2.8.1. Message Overview This section defines the GRASP message format and message types. Message types not listed here are reserved for future use. The messages currently defined are: Discovery and Discovery Response (M_DISCOVERY, M_RESPONSE). Request Negotiation, Negotiation, Confirm Waiting and Negotiation End (M_REQ_NEG, M_NEGOTIATE, M_WAIT, M_END). Request Synchronization, Synchronization, and Flood Synchronization (M_REQ_SYN, M_SYNCH, M_FLOOD. No Operation and Invalid (M_NOOP, M_INVALID). 2.8.2. GRASP Message Format GRASP messages share an identical header format and a variable format area for options. GRASP message headers and options are transmitted in Concise Binary Object Representation (CBOR) [RFC7049]. In this specification, they are described using CBOR data definition language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is used to describe each item in this section. A complete and normative CDDL specification of GRASP is given in Section 5, including constants such as message types. Every GRASP message, except the No Operation message, carries a Session ID (Section 2.7). Options are then presented serially in the options field. In fragmentary CDDL, every GRASP message follows the pattern: Bormann, et al. Expires January 8, 2018 [Page 25] Internet-Draft GRASP July 2017 grasp-message = (message .within message-structure) / noop-message message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option] MESSAGE_TYPE = 1..255 session-id = 0..4294967295 ;up to 32 bits grasp-option = any The MESSAGE_TYPE indicates the type of the message and thus defines the expected options. Any options received that are not consistent with the MESSAGE_TYPE SHOULD be silently discarded. The No Operation (noop) message is described in Section 2.8.13. The various MESSAGE_TYPE values are defined in Section 5. All other message elements are described below and formally defined in Section 5. If an unrecognized MESSAGE_TYPE is received in a unicast message, an Invalid message (Section 2.8.12) MAY be returned. Otherwise the message MAY be logged and MUST be discarded. If an unrecognized MESSAGE_TYPE is received in a multicast message, it MAY be logged and MUST be silently discarded. 2.8.3. Message Size GRASP nodes MUST be able to receive unicast messages of at least GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send unicast messages longer than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly allowed for the objective concerned. For example, GRASP negotiation itself could be used to agree on a longer message size. The message parser used by GRASP should be configured to know about the GRASP_DEF_MAX_SIZE, or any larger negotiated message size, so that it may defend against overly long messages. The maximum size of multicast messages (M_DISCOVERY and M_FLOOD) depends on the link layer technology or link adaptation layer in use. 2.8.4. Discovery Message In fragmentary CDDL, a Discovery message follows the pattern: discovery-message = [M_DISCOVERY, session-id, initiator, objective] Bormann, et al. Expires January 8, 2018 [Page 26] Internet-Draft GRASP July 2017 A discovery initiator sends a Discovery message to initiate a discovery process for a particular objective option. The discovery initiator sends all Discovery messages via UDP to port GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS multicast address on each link-layer interface in use by GRASP. It then listens for unicast TCP responses on a given port, and stores the discovery results (including responding discovery objectives and corresponding unicast locators). The listening port used for TCP MUST be the same port as used for sending the Discovery UDP multicast, on a given interface. In an implementation with a single GRASP instance in a node this MAY be GRASP_LISTEN_PORT. To support multiple instances in the same node, the GRASP discovery mechanism in each instance needs to find, for each interface, a dynamic port that it can bind to for both sending UDP link-local multicast and listening for TCP, before initiating any discovery. The 'initiator' field in the message is a globally unique IP address of the initiator, for the sole purpose of disambiguating the Session ID in other nodes. If for some reason the initiator does not have a globally unique IP address, it MUST use a link-local address for this purpose that is highly likely to be unique, for example using [RFC7217]. Determination of a node's globally unique IP address is implementation-dependent. A Discovery message MUST include exactly one of the following: o a discovery objective option (Section 2.10.1). Its loop count MUST be set to a suitable value to prevent discovery loops (default value is GRASP_DEF_LOOPCT). If the discovery initiator requires only on-link responses, the loop count MUST be set to 1. o a negotiation objective option (Section 2.10.1). This is used both for the purpose of discovery and to indicate to the discovery target that it MAY directly reply to the discovery initiatior with a Negotiation message for rapid processing, if it could act as the corresponding negotiation counterpart. The sender of such a Discovery message MUST initialize a negotiation timer and loop count in the same way as a Request Negotiation message (Section 2.8.6). o a synchronization objective option (Section 2.10.1). This is used both for the purpose of discovery and to indicate to the discovery target that it MAY directly reply to the discovery initiator with a Synchronization message for rapid processing, if it could act as the corresponding synchronization counterpart. Its loop count Bormann, et al. Expires January 8, 2018 [Page 27] Internet-Draft GRASP July 2017 MUST be set to a suitable value to prevent discovery loops (default value is GRASP_DEF_LOOPCT). As mentioned in Section 2.5.4.2, a Discovery message MAY be sent unicast to a peer node, which SHOULD then proceed exactly as if the message had been multicast. 2.8.5. Discovery Response Message In fragmentary CDDL, a Discovery Response message follows the pattern: response-message = [M_RESPONSE, session-id, initiator, ttl, (+locator-option // divert-option), ?objective)] ttl = 0..4294967295 ; in milliseconds A node which receives a Discovery message SHOULD send a Discovery Response message if and only if it can respond to the discovery. It MUST contain the same Session ID and initiator as the Discovery message. It MUST contain a time-to-live (ttl) for the validity of the response, given as a positive integer value in milliseconds. Zero implies a value significantly greater than GRASP_DEF_TIMEOUT milliseconds (Section 2.6). A suggested value is ten times that amount. It MAY include a copy of the discovery objective from the Discovery message. It is sent to the sender of the Discovery message via TCP at the port used to send the Discovery message (as explained in Section 2.8.4). In the case of a relayed Discovery message, the Discovery Response is thus sent to the relay, not the original initiator. In all cases, the transport session SHOULD be closed after sending the Discovery Response. A transport session failure is treated as no response. If the responding node supports the discovery objective of the discovery, it MUST include at least one kind of locator option (Section 2.9.5) to indicate its own location. A sequence of multiple kinds of locator options (e.g. IP address option and FQDN option) is also valid. Bormann, et al. Expires January 8, 2018 [Page 28] Internet-Draft GRASP July 2017 If the responding node itself does not support the discovery objective, but it knows the locator of the discovery objective, then it SHOULD respond to the discovery message with a divert option (Section 2.9.2) embedding a locator option or a combination of multiple kinds of locator options which indicate the locator(s) of the discovery objective. More details on the processing of Discovery Responses are given in Section 2.5.4. 2.8.6. Request Messages In fragmentary CDDL, Request Negotiation and Request Synchronization messages follow the patterns: request-negotiation-message = [M_REQ_NEG, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective] A negotiation or synchronization requesting node sends the appropriate Request message to the unicast address of the negotiation or synchronization counterpart, using the appropriate protocol and port numbers (selected from the discovery result). If the discovery result is an FQDN, it will be resolved first. A Request message MUST include the relevant objective option. In the case of Request Negotiation, the objective option MUST include the requested value. When an initiator sends a Request Negotiation message, it MUST initialize a negotiation timer for the new negotiation thread. The default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a Confirm Waiting message (Section 2.8.9), the initiator will consider that the negotiation has failed when the timer expires. Similarly, when an initiator sends a Request Synchronization, it SHOULD initialize a synchronization timer. The default is GRASP_DEF_TIMEOUT milliseconds. The initiator will consider that synchronization has failed if there is no response before the timer expires. When an initiator sends a Request message, it MUST initialize the loop count of the objective option with a value defined in the specification of the option or, if no such value is specified, with GRASP_DEF_LOOPCT. Bormann, et al. Expires January 8, 2018 [Page 29] Internet-Draft GRASP July 2017 If a node receives a Request message for an objective for which no ASA is currently listening, it MUST immediately close the relevant socket to indicate this to the initiator. This is to avoid unnecessary timeouts if, for example, an ASA exits prematurely but the GRASP core is listening on its behalf. To avoid the highly unlikely race condition in which two nodes simultaneously request sessions with each other using the same Session ID (Section 2.7), when a node receives a Request message, it MUST verify that the received Session ID is not already locally active. In case of a clash, it MUST discard the Request message, in which case the initiator will detect a timeout. 2.8.7. Negotiation Message In fragmentary CDDL, a Negotiation message follows the pattern: negotiate-message = [M_NEGOTIATE, session-id, objective] A negotiation counterpart sends a Negotiation message in response to a Request Negotiation message, a Negotiation message, or a Discovery message in Rapid Mode. A negotiation process MAY include multiple steps. The Negotiation message MUST include the relevant Negotiation Objective option, with its value updated according to progress in the negotiation. The sender MUST decrement the loop count by 1. If the loop count becomes zero the message MUST NOT be sent. In this case the negotiation session has failed and will time out. 2.8.8. Negotiation End Message In fragmentary CDDL, a Negotiation End message follows the pattern: end-message = [M_END, session-id, accept-option / decline-option] A negotiation counterpart sends an Negotiation End message to close the negotiation. It MUST contain either an accept or a decline option, defined in Section 2.9.3 and Section 2.9.4. It could be sent either by the requesting node or the responding node. 2.8.9. Confirm Waiting Message In fragmentary CDDL, a Confirm Waiting message follows the pattern: wait-message = [M_WAIT, session-id, waiting-time] waiting-time = 0..4294967295 ; in milliseconds Bormann, et al. Expires January 8, 2018 [Page 30] Internet-Draft GRASP July 2017 A responding node sends a Confirm Waiting message to ask the requesting node to wait for a further negotiation response. It might be that the local process needs more time or that the negotiation depends on another triggered negotiation. This message MUST NOT include any other options. When received, the waiting time value overwrites and restarts the current negotiation timer (Section 2.8.6). The responding node SHOULD send a Negotiation, Negotiation End or another Confirm Waiting message before the negotiation timer expires. If not, when the initiator's timer expires, the initiator MUST treat the negotiation procedure as failed. 2.8.10. Synchronization Message In fragmentary CDDL, a Synchronization message follows the pattern: synch-message = [M_SYNCH, session-id, objective] A node which receives a Request Synchronization, or a Discovery message in Rapid Mode, sends back a unicast Synchronization message with the synchronization data, in the form of a GRASP Option for the specific synchronization objective present in the Request Synchronization. 2.8.11. Flood Synchronization Message In fragmentary CDDL, a Flood Synchronization message follows the pattern: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] ttl = 0..4294967295 ; in milliseconds A node MAY initiate flooding by sending an unsolicited Flood Synchronization Message with synchronization data. This MAY be sent to port GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS multicast address, in accordance with the rules in Section 2.5.6. The initiator address is provided, as described for Discovery messages (Section 2.8.4), only to disambiguate the Session ID. The message MUST contain a time-to-live (ttl) for the validity of the contents, given as a positive integer value in milliseconds. There is no default; zero indicates an indefinite lifetime. Bormann, et al. Expires January 8, 2018 [Page 31] Internet-Draft GRASP July 2017 The synchronization data are in the form of GRASP Option(s) for specific synchronization objective(s). The loop count(s) MUST be set to a suitable value to prevent flood loops (default value is GRASP_DEF_LOOPCT). Each objective option MAY be followed by a locator option associated with the flooded objective. In its absence, an empty option MUST be included to indicate a null locator. A node that receives a Flood Synchronization message MUST cache the received objectives for use by local ASAs. Each cached objective MUST be tagged with the locator option sent with it, or with a null tag if an empty locator option was sent. If a subsequent Flood Synchronization message carrying an objective with same name and the same tag, the corresponding cached copy of the objective MUST be overwritten. If a subsequent Flood Synchronization message carrying an objective with same name arrives with a different tag, a new cached entry MUST be created. Note: the purpose of this mechanism is to allow the recipient of flooded values to distinguish between different senders of the same objective, and if necessary communicate with them using the locator, protocol and port included in the locator option. Many objectives will not need this mechanism, so they will be flooded with a null locator. Cached entries MUST be ignored or deleted after their lifetime expires. 2.8.12. Invalid Message In fragmentary CDDL, an Invalid message follows the pattern: invalid-message = [M_INVALID, session-id, ?any] This message MAY be sent by an implementation in response to an incoming unicast message that it considers invalid. The session-id MUST be copied from the incoming message. The content SHOULD be diagnostic information such as a partial copy of the invalid message up to the maximum message size. An M_INVALID message MAY be silently ignored by a recipient. However, it could be used in support of extensibility, since it indicates that the remote node does not support a new or obsolete message or option. An M_INVALID message MUST NOT be sent in response to an M_INVALID message. Bormann, et al. Expires January 8, 2018 [Page 32] Internet-Draft GRASP July 2017 2.8.13. No Operation Message In fragmentary CDDL, a No Operation message follows the pattern: noop-message = [M_NOOP] This message MAY be sent by an implementation that for practical reasons needs to initialize a socket. It MUST be silently ignored by a recipient. 2.9. GRASP Options This section defines the GRASP options for the negotiation and synchronization protocol signaling. Additional options may be defined in the future. 2.9.1. Format of GRASP Options GRASP options are CBOR objects that MUST start with an unsigned integer identifying the specific option type carried in this option. These option types are formally defined in Section 5. Apart from that the only format requirement is that each option MUST be a well- formed CBOR object. In general a CBOR array format is RECOMMENDED to limit overhead. GRASP options may be defined to include encapsulated GRASP options. 2.9.2. Divert Option The Divert option is used to redirect a GRASP request to another node, which may be more appropriate for the intended negotiation or synchronization. It may redirect to an entity that is known as a specific negotiation or synchronization counterpart (on-link or off- link) or a default gateway. The divert option MUST only be encapsulated in Discovery Response messages. If found elsewhere, it SHOULD be silently ignored. A discovery initiator MAY ignore a Divert option if it only requires direct discovery responses. In fragmentary CDDL, the Divert option follows the pattern: divert-option = [O_DIVERT, +locator-option] The embedded Locator Option(s) (Section 2.9.5) point to diverted destination target(s) in response to a Discovery message. Bormann, et al. Expires January 8, 2018 [Page 33] Internet-Draft GRASP July 2017 2.9.3. Accept Option The accept option is used to indicate to the negotiation counterpart that the proposed negotiation content is accepted. The accept option MUST only be encapsulated in Negotiation End messages. If found elsewhere, it SHOULD be silently ignored. In fragmentary CDDL, the Accept option follows the pattern: accept-option = [O_ACCEPT] 2.9.4. Decline Option The decline option is used to indicate to the negotiation counterpart the proposed negotiation content is declined and end the negotiation process. The decline option MUST only be encapsulated in Negotiation End messages. If found elsewhere, it SHOULD be silently ignored. In fragmentary CDDL, the Decline option follows the pattern: decline-option = [O_DECLINE, ?reason] reason = text ;optional UTF-8 error message Note: there might be scenarios where an ASA wants to decline the proposed value and restart the negotiation process. In this case it is an implementation choice whether to send a Decline option or to continue with a Negotiate message, with an objective option that contains a null value, or one that contains a new value that might achieve convergence. 2.9.5. Locator Options These locator options are used to present reachability information for an ASA, a device or an interface. They are Locator IPv6 Address Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified Domain Name) Option and URI (Uniform Resource Identifier) Option. Since ASAs will normally run as independent user programs, locator options need to indicate the network layer locator plus the transport protocol and port number for reaching the target. For this reason, the Locator Options for IP addresses and FQDNs include this information explicitly. In the case of the URI Option, this information can be encoded in the URI itself. Bormann, et al. Expires January 8, 2018 [Page 34] Internet-Draft GRASP July 2017 Note: It is assumed that all locators used in locator options are in scope throughout the GRASP domain. As stated in Section 2.2, GRASP is not intended to work across disjoint addressing or naming realms. 2.9.5.1. Locator IPv6 address option In fragmentary CDDL, the IPv6 address option follows the pattern: ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] ipv6-address = bytes .size 16 transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 port-number = 0..65535 The content of this option is a binary IPv6 address followed by the protocol number and port number to be used. Note 1: The IPv6 address MUST normally have global scope. However, during initialization, a link-local address MAY be used for specific objectives only (Section 2.5.2). In this case the corresponding Discovery Response message MUST be sent via the interface to which the link-local address applies. Note 2: A link-local IPv6 address MUST NOT be used when this option is included in a Divert option. Note 3: The IPPROTO values are taken from the existing IANA Protocol Numbers registry in order to specify TCP or UDP. If GRASP requires future values that are not in that registry, a new registry for values outside the range 0..255 will be needed. 2.9.5.2. Locator IPv4 address option In fragmentary CDDL, the IPv4 address option follows the pattern: ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number] ipv4-address = bytes .size 4 The content of this option is a binary IPv4 address followed by the protocol number and port number to be used. Note: If an operator has internal network address translation for IPv4, this option MUST NOT be used within the Divert option. Bormann, et al. Expires January 8, 2018 [Page 35] Internet-Draft GRASP July 2017 2.9.5.3. Locator FQDN option In fragmentary CDDL, the FQDN option follows the pattern: fqdn-locator-option = [O_FQDN_LOCATOR, text, transport-proto, port-number] The content of this option is the Fully Qualified Domain Name of the target followed by the protocol number and port number to be used. Note 1: Any FQDN which might not be valid throughout the network in question, such as a Multicast DNS name [RFC6762], MUST NOT be used when this option is used within the Divert option. Note 2: Normal GRASP operations are not expected to use this option. It is intended for special purposes such as discovering external services. 2.9.5.4. Locator URI option In fragmentary CDDL, the URI option follows the pattern: uri-locator = [O_URI_LOCATOR, text, transport-proto / null, port-number / null] The content of this option is the Uniform Resource Identifier of the target followed by the protocol number and port number to be used (or by null values if not required) [RFC3986]. Note 1: Any URI which might not be valid throughout the network in question, such as one based on a Multicast DNS name [RFC6762], MUST NOT be used when this option is used within the Divert option. Note 2: Normal GRASP operations are not expected to use this option. It is intended for special purposes such as discovering external services. Therefore its use is not further described in this specification. 2.10. Objective Options 2.10.1. Format of Objective Options An objective option is used to identify objectives for the purposes of discovery, negotiation or synchronization. All objectives MUST be in the following format, described in fragmentary CDDL: Bormann, et al. Expires January 8, 2018 [Page 36] Internet-Draft GRASP July 2017 objective = [objective-name, objective-flags, loop-count, ?objective-value] objective-name = text objective-value = any loop-count = 0..255 All objectives are identified by a unique name which is a UTF-8 string [RFC3629], to be compared byte by byte. The names of generic objectives MUST NOT include a colon (":") and MUST be registered with IANA (Section 6). The names of privately defined objectives MUST include at least one colon (":"). The string preceding the last colon in the name MUST be globally unique and in some way identify the entity or person defining the objective. The following three methods MAY be used to create such a globally unique string: 1. The unique string is a decimal number representing a registered 32 bit Private Enterprise Number (PEN) [RFC5612] that uniquely identifies the enterprise defining the objective. 2. The unique string is a fully qualified domain name that uniquely identifies the entity or person defining the objective. 3. The unique string is an email address that uniquely identifies the entity or person defining the objective. The GRASP protocol treats the objective name as an opaque string. For example, "EX1", "32473:EX1", "example.com:EX1", "example.org:EX1 and "user@example.org:EX1" would be five different objectives. The 'objective-flags' field is described below. The 'loop-count' field is used for terminating negotiation as described in Section 2.8.7. It is also used for terminating discovery as described in Section 2.5.4, and for terminating flooding as described in Section 2.5.6.2. It is placed in the objective rather than in the GRASP message format because, as far as the ASA is concerned, it is a property of the objective itself. The 'objective-value' field is to express the actual value of a negotiation or synchronization objective. Its format is defined in the specification of the objective and may be a simple value or a data structure of any kind, as long as it can be represented in CBOR. It is optional because it is optional in a Discovery or Discovery Response message. Bormann, et al. Expires January 8, 2018 [Page 37] Internet-Draft GRASP July 2017 2.10.2. Objective flags An objective may be relevant for discovery only, for discovery and negotiation, or for discovery and synchronization. This is expressed in the objective by logical flag bits: objective-flags = uint .bits objective-flag objective-flag = &( F_DISC: 0 ; valid for discovery F_NEG: 1 ; valid for negotiation F_SYNCH: 2 ; valid for synchronization F_NEG_DRY: 3 ; negotiation is dry-run ) These bits are independent and may be combined appropriately, e.g. (F_DISC and F_SYNCH) or (F_DISC and F_NEG) or (F_DISC and F_NEG and F_NEG_DRY). Note that for a given negotiation session, an objective must be either used for negotiation, or for dry-run negotiation. Mixing the two modes in a single negotiation is not possible. 2.10.3. General Considerations for Objective Options As mentioned above, Objective Options MUST be assigned a unique name. As long as privately defined Objective Options obey the rules above, this document does not restrict their choice of name, but the entity or person concerned SHOULD publish the names in use. Names are expressed as UTF-8 strings for convenience in designing Objective Options for localized use. For generic usage, names expressed in the ASCII subset of UTF-8 are RECOMMENDED. Designers planning to use non-ASCII names are strongly advised to consult [RFC7564] or its successor to understand the complexities involved. Since the GRASP protocol compares names byte by byte, all issues of Unicode profiling and canonicalization MUST be specified in the design of the Objective Option. All Objective Options MUST respect the CBOR patterns defined above as "objective" and MUST replace the "any" field with a valid CBOR data definition for the relevant use case and application. An Objective Option that contains no additional fields beyond its "loop-count" can only be a discovery objective and MUST only be used in Discovery and Discovery Response messages. The Negotiation Objective Options contain negotiation objectives, which vary according to different functions/services. They MUST be Bormann, et al. Expires January 8, 2018 [Page 38] Internet-Draft GRASP July 2017 carried by Discovery, Request Negotiation or Negotiation messages only. The negotiation initiator MUST set the initial "loop-count" to a value specified in the specification of the objective or, if no such value is specified, to GRASP_DEF_LOOPCT. For most scenarios, there should be initial values in the negotiation requests. Consequently, the Negotiation Objective options MUST always be completely presented in a Request Negotiation message, or in a Discovery message in rapid mode. If there is no initial value, the value field SHOULD be set to the 'null' value defined by CBOR. Synchronization Objective Options are similar, but MUST be carried by Discovery, Discovery Response, Request Synchronization, or Flood Synchronization messages only. They include value fields only in Synchronization or Flood Synchronization messages. The design of an objective interacts in various ways with the design of the ASAs that will use it. ASA design considerations are discussed in [I-D.carpenter-anima-asa-guidelines]. 2.10.4. Organizing of Objective Options Generic objective options MUST be specified in documents available to the public and SHOULD be designed to use either the negotiation or the synchronization mechanism described above. As noted earlier, one negotiation objective is handled by each GRASP negotiation thread. Therefore, a negotiation objective, which is based on a specific function or action, SHOULD be organized as a single GRASP option. It is NOT RECOMMENDED to organize multiple negotiation objectives into a single option, nor to split a single function or action into multiple negotiation objectives. It is important to understand that GRASP negotiation does not support transactional integrity. If transactional integrity is needed for a specific objective, this must be ensured by the ASA. For example, an ASA might need to ensure that it only participates in one negotiation thread at the same time. Such an ASA would need to stop listening for incoming negotiation requests before generating an outgoing negotiation request. A synchronization objective SHOULD be organized as a single GRASP option. Some objectives will support more than one operational mode. An example is a negotiation objective with both a "dry run" mode (where the negotiation is to find out whether the other end can in fact make the requested change without problems) and a "live" mode, as Bormann, et al. Expires January 8, 2018 [Page 39] Internet-Draft GRASP July 2017 explained in Section 2.5.5. The semantics of such modes will be defined in the specification of the objectives. These objectives SHOULD include flags indicating the applicable mode(s). An issue requiring particular attention is that GRASP itself is not a transactionally safe protocol. Any state associated with a dry run operation, such as temporarily reserving a resource for subsequent use in a live run, is entirely a matter for the designer of the ASA concerned. As indicated in Section 2.1, an objective's value may include multiple parameters. Parameters might be categorized into two classes: the obligatory ones presented as fixed fields; and the optional ones presented in some other form of data structure embedded in CBOR. The format might be inherited from an existing management or configuration protocol, with the objective option acting as a carrier for that format. The data structure might be defined in a formal language, but that is a matter for the specifications of individual objectives. There are many candidates, according to the context, such as ABNF, RBNF, XML Schema, YANG, etc. The GRASP protocol itself is agnostic on these questions. The only restriction is that the format can be mapped into CBOR. It is NOT RECOMMENDED to mix parameters that have significantly different response time characteristics in a single objective. Separate objectives are more suitable for such a scenario. All objectives MUST support GRASP discovery. However, as mentioned in Section 2.3, it is acceptable for an ASA to use an alternative method of discovery. Normally, a GRASP objective will refer to specific technical parameters as explained in Section 2.1. However, it is acceptable to define an abstract objective for the purpose of managing or coordinating ASAs. It is also acceptable to define a special-purpose objective for purposes such as trust bootstrapping or formation of the ACP. To guarantee convergence, a limited number of rounds or a timeout is needed for each negotiation objective. Therefore, the definition of each negotiation objective SHOULD clearly specify this, for example a default loop count and timeout, so that the negotiation can always be terminated properly. If not, the GRASP defaults will apply. There must be a well-defined procedure for concluding that a negotiation cannot succeed, and if so deciding what happens next (e.g., deadlock resolution, tie-breaking, or revert to best-effort Bormann, et al. Expires January 8, 2018 [Page 40] Internet-Draft GRASP July 2017 service). This MUST be specified for individual negotiation objectives. 2.10.5. Experimental and Example Objective Options The names "EX0" through "EX9" have been reserved for experimental options. Multiple names have been assigned because a single experiment may use multiple options simultaneously. These experimental options are highly likely to have different meanings when used for different experiments. Therefore, they SHOULD NOT be used without an explicit human decision and MUST NOT be used in unmanaged networks such as home networks. These names are also RECOMMENDED for use in documentation examples. 3. Implementation Status [RFC Editor: please remove] Two prototype implementations of GRASP have been made. 3.1. BUPT C++ Implementation o Name: BaseNegotiator.cpp, msg.cpp, Client.cpp, Server.cpp o Description: C++ implementation of GRASP core and API o Maturity: Prototype code, interoperable between Ubuntu. o Coverage: Corresponds to draft-carpenter-anima-gdn-protocol-03. Since it was implemented based on the old version draft, the most significant limitations comparing to current protocol design include: * Not support CBOR * Not support Flooding * Not support loop avoidance * only coded for IPv6, any IPv4 is accidental o Licensing: Huawei License. o Experience: https://github.com/liubingpang/IETF-Anima-Signaling- Protocol/blob/master/README.md o Contact: https://github.com/liubingpang/IETF-Anima-Signaling- Protocol Bormann, et al. Expires January 8, 2018 [Page 41] Internet-Draft GRASP July 2017 3.2. Python Implementation o Name: graspy o Description: Python 3 implementation of GRASP core and API. o Maturity: Prototype code, interoperable between Windows 7 and Linux. o Coverage: Corresponds to draft-ietf-anima-grasp-13. Limitations include: * insecure: uses a dummy ACP module * only coded for IPv6, any IPv4 is accidental * FQDN and URI locators incompletely supported * no code for rapid mode * relay code is lazy (no rate control) * all unicast transactions use TCP (no unicast UDP). Experimental code for unicast UDP proved to be complex and brittle. * optional Objective option in Response messages not implemented * workarounds for defects in Python socket module and Windows socket peculiarities o Licensing: Simplified BSD o Experience: Tested on Windows, Linux and MacOS. https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ 4. Security Considerations A successful attack on negotiation-enabled nodes would be extremely harmful, as such nodes might end up with a completely undesirable configuration that would also adversely affect their peers. GRASP nodes and messages therefore require full protection. As explained in Section 2.5.1, GRASP MUST run within a secure environment such as the Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], except for the constrained instances described in Section 2.5.2. Bormann, et al. Expires January 8, 2018 [Page 42] Internet-Draft GRASP July 2017 - Authentication A cryptographically authenticated identity for each device is needed in an autonomic network. It is not safe to assume that a large network is physically secured against interference or that all personnel are trustworthy. Each autonomic node MUST be capable of proving its identity and authenticating its messages. GRASP relies on a separate external certificate-based security mechanism to support authentication, data integrity protection, and anti-replay protection. Since GRASP must be deployed in an existing secure environment, the protocol itself specifies nothing concerning the trust anchor and certification authority. For example, in the Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], all nodes can trust each other and the ASAs installed in them. If GRASP is used temporarily without an external security mechanism, for example during system bootstrap (Section 2.5.1), the Session ID (Section 2.7) will act as a nonce to provide limited protection against third parties injecting responses. A full analysis of the secure bootstrap process is in [I-D.ietf-anima-bootstrapping-keyinfra]. - Authorization and Roles The GRASP protocol is agnostic about the roles and capabilities of individual ASAs and about which objectives a particular ASA is authorized to support. An implementation might support precautions such as allowing only one ASA in a given node to modify a given objective, but this may not be appropriate in all cases. For example, it might be operationally useful to allow an old and a new version of the same ASA to run simultaneously during an overlap period. These questions are out of scope for the present specification. - Privacy and confidentiality GRASP is intended for network management purposes involving network elements, not end hosts. Therefore, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy. Nevertheless, applications that do convey personal information cannot be excluded. Also, traffic flow paths, VPNs, etc. could be negotiated, which could be of interest for traffic analysis. Operators generally want to conceal details of their network topology and traffic density from outsiders. Therefore, since insider attacks cannot be excluded in a large network, the Bormann, et al. Expires January 8, 2018 [Page 43] Internet-Draft GRASP July 2017 security mechanism for the protocol MUST provide message confidentiality. This is why Section 2.5.1 requires either an ACP or an alternative security mechanism. - Link-local multicast security GRASP has no reasonable alternative to using link-local multicast for Discovery or Flood Synchronization messages and these messages are sent in clear and with no authentication. They are only sent on interfaces within the autonomic network (see Section 2.1 and Section 2.5.1). They are however available to on-link eavesdroppers, and could be forged by on-link attackers. In the case of Discovery, the Discovery Responses are unicast and will therefore be protected (Section 2.5.1), and an untrusted forger will not be able to receive responses. In the case of Flood Synchronization, an on-link eavesdropper will be able to receive the flooded objectives but there is no response message to consider. Some precautions for Flood Synchronization messages are suggested in Section 2.5.6.2. - DoS Attack Protection GRASP discovery partly relies on insecure link-local multicast. Since routers participating in GRASP sometimes relay discovery messages from one link to another, this could be a vector for denial of service attacks. Some mitigations are specified in Section 2.5.4. However, malicious code installed inside the Autonomic Control Plane could always launch DoS attacks consisting of spurious discovery messages, or of spurious discovery responses. It is important that firewalls prevent any GRASP messages from entering the domain from an unknown source. - Security during bootstrap and discovery A node cannot trust GRASP traffic from other nodes until the security environment (such as the ACP) has identified the trust anchor and can authenticate traffic by validating certificates for other nodes. Also, until it has succesfully enrolled [I-D.ietf-anima-bootstrapping-keyinfra] a node cannot assume that other nodes are able to authenticate its own traffic. Therefore, GRASP discovery during the bootstrap phase for a new device will inevitably be insecure. Secure synchronization and negotiation will be impossible until enrollment is complete. Further details are given in Section 2.5.2. - Security of discovered locators Bormann, et al. Expires January 8, 2018 [Page 44] Internet-Draft GRASP July 2017 When GRASP discovery returns an IP address, it MUST be that of a node within the secure environment (Section 2.5.1). If it returns an FQDN or a URI, the ASA that receives it MUST NOT assume that the target of the locator is within the secure environment. 5. CDDL Specification of GRASP grasp-message = (message .within message-structure) / noop-message message-structure = [MESSAGE_TYPE, session-id, ?initiator, *grasp-option] MESSAGE_TYPE = 0..255 session-id = 0..4294967295 ;up to 32 bits grasp-option = any message /= discovery-message discovery-message = [M_DISCOVERY, session-id, initiator, objective] message /= response-message ;response to Discovery response-message = [M_RESPONSE, session-id, initiator, ttl, (+locator-option // divert-option), ?objective] message /= synch-message ;response to Synchronization request synch-message = [M_SYNCH, session-id, objective] message /= flood-message flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] message /= request-negotiation-message request-negotiation-message = [M_REQ_NEG, session-id, objective] message /= request-synchronization-message request-synchronization-message = [M_REQ_SYN, session-id, objective] message /= negotiation-message negotiation-message = [M_NEGOTIATE, session-id, objective] message /= end-message end-message = [M_END, session-id, accept-option / decline-option ] message /= wait-message wait-message = [M_WAIT, session-id, waiting-time] message /= invalid-message invalid-message = [M_INVALID, session-id, ?any] Bormann, et al. Expires January 8, 2018 [Page 45] Internet-Draft GRASP July 2017 noop-message = [M_NOOP] divert-option = [O_DIVERT, +locator-option] accept-option = [O_ACCEPT] decline-option = [O_DECLINE, ?reason] reason = text ;optional UTF-8 error message waiting-time = 0..4294967295 ; in milliseconds ttl = 0..4294967295 ; in milliseconds locator-option /= [O_IPv4_LOCATOR, ipv4-address, transport-proto, port-number] ipv4-address = bytes .size 4 locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number] ipv6-address = bytes .size 16 locator-option /= [O_FQDN_LOCATOR, text, transport-proto, port-number] locator-option /= [O_URI_LOCATOR, text, transport-proto / null, port-number / null] transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 port-number = 0..65535 initiator = ipv4-address / ipv6-address objective-flags = uint .bits objective-flag objective-flag = &( F_DISC: 0 ; valid for discovery F_NEG: 1 ; valid for negotiation F_SYNCH: 2 ; valid for synchronization F_NEG_DRY: 3 ; negotiation is dry-run ) objective = [objective-name, objective-flags, loop-count, ?objective-value] objective-name = text ;see section "Format of Objective Options" objective-value = any loop-count = 0..255 Bormann, et al. Expires January 8, 2018 [Page 46] Internet-Draft GRASP July 2017 ; Constants for message types and option types M_NOOP = 0 M_DISCOVERY = 1 M_RESPONSE = 2 M_REQ_NEG = 3 M_REQ_SYN = 4 M_NEGOTIATE = 5 M_END = 6 M_WAIT = 7 M_SYNCH = 8 M_FLOOD = 9 M_INVALID = 99 O_DIVERT = 100 O_ACCEPT = 101 O_DECLINE = 102 O_IPv6_LOCATOR = 103 O_IPv4_LOCATOR = 104 O_FQDN_LOCATOR = 105 O_URI_LOCATOR = 106 6. IANA Considerations This document defines the GeneRic Autonomic Signaling Protocol (GRASP). Section 2.6 explains the following link-local multicast addresses, which IANA is requested to assign for use by GRASP: ALL_GRASP_NEIGHBORS multicast address (IPv6): (TBD1). Assigned in the IPv6 Link-Local Scope Multicast Addresses registry. ALL_GRASP_NEIGHBORS multicast address (IPv4): (TBD2). Assigned in the IPv4 Multicast Local Network Control Block. Section 2.6 explains the following User Port, which IANA is requested to assign for use by GRASP for both UDP and TCP: GRASP_LISTEN_PORT: (TBD3) Service Name: Generic Autonomic Signaling Protocol (GRASP) Transport Protocols: UDP, TCP Assignee: iesg@ietf.org Contact: chair@ietf.org Description: See Section 2.6 Reference: RFC XXXX (this document) Bormann, et al. Expires January 8, 2018 [Page 47] Internet-Draft GRASP July 2017 The IANA is requested to create a GRASP Parameter Registry including two registry tables. These are the GRASP Messages and Options Table and the GRASP Objective Names Table. GRASP Messages and Options Table. The values in this table are names paired with decimal integers. Future values MUST be assigned using the Standards Action policy defined by [RFC8126]. The following initial values are assigned by this document: M_NOOP = 0 M_DISCOVERY = 1 M_RESPONSE = 2 M_REQ_NEG = 3 M_REQ_SYN = 4 M_NEGOTIATE = 5 M_END = 6 M_WAIT = 7 M_SYNCH = 8 M_FLOOD = 9 M_INVALID = 99 O_DIVERT = 100 O_ACCEPT = 101 O_DECLINE = 102 O_IPv6_LOCATOR = 103 O_IPv4_LOCATOR = 104 O_FQDN_LOCATOR = 105 O_URI_LOCATOR = 106 GRASP Objective Names Table. The values in this table are UTF-8 strings which MUST NOT include a colon (":"), according to Section 2.10.1. Future values MUST be assigned using the Specification Required policy defined by [RFC8126]. To assist expert review of a new objective, the specification should include a precise description of the format of the new objective, with sufficient explanation of its semantics to allow independent implementations. See Section 2.10.3 for more details. If the new objective is similar in name or purpose to a previously registered objective, the specification should explain why a new objective is justified. The following initial values are assigned by this document: Bormann, et al. Expires January 8, 2018 [Page 48] Internet-Draft GRASP July 2017 EX0 EX1 EX2 EX3 EX4 EX5 EX6 EX7 EX8 EX9 7. Acknowledgements A major contribution to the original version of this document was made by Sheng Jiang and significant contributions were made by Toerless Eckert. Significant early review inputs were received from Joel Halpern, Barry Leiba, Charles E. Perkins, and Michael Richardson. William Atwood provided important assistance in debugging a prototype implementation. Valuable comments were received from Michael Behringer, Jeferson Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Jaeggli, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg, Martin Stiemerling, Rene Struik, Martin Thomson, Dacheng Zhang, and participants in the NMRG research group, the ANIMA working group, and the IESG. 8. References 8.1. Normative References [I-D.greevenbosch-appsawg-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR data structures", draft-greevenbosch-appsawg- cbor-cddl-11 (work in progress), July 2017. [I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Control Plane", draft-ietf-anima-autonomic-control- plane-07 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Bormann, et al. Expires January 8, 2018 [Page 49] Internet-Draft GRASP July 2017 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . 8.2. Informative References [I-D.carpenter-anima-asa-guidelines] Carpenter, B. and S. Jiang, "Guidelines for Autonomic Service Agents", draft-carpenter-anima-asa-guidelines-02 (work in progress), July 2017. [I-D.chaparadza-intarea-igcp] Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. Mahkonen, "IP based Generic Control Protocol (IGCP)", draft-chaparadza-intarea-igcp-00 (work in progress), July 2011. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-07 (work in progress), July 2017. Bormann, et al. Expires January 8, 2018 [Page 50] Internet-Draft GRASP July 2017 [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Reference Model for Autonomic Networking", draft-ietf- anima-reference-model-04 (work in progress), July 2017. [I-D.ietf-anima-stable-connectivity] Eckert, T. and M. Behringer, "Using Autonomic Control Plane for Stable Connectivity of Network OAM", draft-ietf- anima-stable-connectivity-03 (work in progress), July 2017. [I-D.liu-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", draft-liu-anima-grasp-api-04 (work in progress), June 2017. [I-D.stenberg-anima-adncp] Stenberg, M., "Autonomic Distributed Node Consensus Protocol", draft-stenberg-anima-adncp-00 (work in progress), March 2015. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2334] Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, DOI 10.17487/RFC2334, April 1998, . [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, DOI 10.17487/RFC2608, June 1999, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . Bormann, et al. Expires January 8, 2018 [Page 51] Internet-Draft GRASP July 2017 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002, . [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, . [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, . [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . Bormann, et al. Expires January 8, 2018 [Page 52] Internet-Draft GRASP July 2017 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, . [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015, . [RFC7564] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 7564, DOI 10.17487/RFC7564, May 2015, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . [RFC7787] Stenberg, M. and S. Barth, "Distributed Node Consensus Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Bormann, et al. Expires January 8, 2018 [Page 53] Internet-Draft GRASP July 2017 Appendix A. Open Issues [RFC Editor: This section should be empty. Please remove] o 68. (Placeholder) Appendix B. Closed Issues [RFC Editor: Please remove] o 1. UDP vs TCP: For now, this specification suggests UDP and TCP as message transport mechanisms. This is not clarified yet. UDP is good for short conversations, is necessary for multicast discovery, and generally fits the discovery and divert scenarios well. However, it will cause problems with large messages. TCP is good for stable and long sessions, with a little bit of time consumption during the session establishment stage. If messages exceed a reasonable MTU, a TCP mode will be required in any case. This question may be affected by the security discussion. RESOLVED by specifying UDP for short message and TCP for longer one. o 2. DTLS or TLS vs built-in security mechanism. For now, this specification has chosen a PKI based built-in security mechanism based on asymmetric cryptography. However, (D)TLS might be chosen as security solution to avoid duplication of effort. It also allows essentially similar security for short messages over UDP and longer ones over TCP. The implementation trade-offs are different. The current approach requires expensive asymmetric cryptographic calculations for every message. (D)TLS has startup overheads but cheaper crypto per message. DTLS is less mature than TLS. RESOLVED by specifying external security (ACP or (D)TLS). o The following open issues applied only if the original security model was retained: * 2.1. For replay protection, GRASP currently requires every participant to have an NTP-synchronized clock. Is this OK for low-end devices, and how does it work during device bootstrapping? We could take the Timestamp out of signature option, to become an independent and OPTIONAL (or RECOMMENDED) option. * 2.2. The Signature Option states that this option could be any place in a message. Wouldn't it be better to specify a position (such as the end)? That would be much simpler to implement. Bormann, et al. Expires January 8, 2018 [Page 54] Internet-Draft GRASP July 2017 RESOLVED by changing security model. o 3. DoS Attack Protection needs work. RESOLVED by adding text. o 4. Should we consider preferring a text-based approach to discovery (after the initial discovery needed for bootstrapping)? This could be a complementary mechanism for multicast based discovery, especially for a very large autonomic network. Centralized registration could be automatically deployed incrementally. At the very first stage, the repository could be empty; then it could be filled in by the objectives discovered by different devices (for example using Dynamic DNS Update). The more records are stored in the repository, the less the multicast- based discovery is needed. However, if we adopt such a mechanism, there would be challenges: stateful solution, and security. RESOLVED for now by adding optional use of DNS-SD by ASAs. Subsequently removed by editors as irrelevant to GRASP istelf. o 5. Need to expand description of the minimum requirements for the specification of an individual discovery, synchronization or negotiation objective. RESOLVED for now by extra wording. o 6. Use case and protocol walkthrough. A description of how a node starts up, performs discovery, and conducts negotiation and synchronisation for a sample use case would help readers to understand the applicability of this specification. Maybe it should be an artificial use case or maybe a simple real one, based on a conceptual API. However, the authors have not yet decided whether to have a separate document or have it in the protocol document. RESOLVED: recommend a separate document. o 7. Cross-check against other ANIMA WG documents for consistency and gaps. RESOLVED: Satisfied by WGLC. o 8. Consideration of ADNCP proposal. RESOLVED by adding optional use of DNCP for flooding-type synchronization. Bormann, et al. Expires January 8, 2018 [Page 55] Internet-Draft GRASP July 2017 o 9. Clarify how a GDNP instance knows whether it is running inside the ACP. (Sheng) RESOLVED by improved text. o 10. Clarify how a non-ACP GDNP instance initiates (D)TLS. (Sheng) RESOLVED by improved text and declaring DTLS out of scope for this draft. o 11. Clarify how UDP/TCP choice is made. (Sheng) [Like DNS? - Brian] RESOLVED by improved text. o 12. Justify that IP address within ACP or (D)TLS environment is sufficient to prove AN identity; or explain how Device Identity Option is used. (Sheng) RESOLVED for now: we assume that all ASAs in a device are trusted as soon as the device is trusted, so they share credentials. In that case the Device Identity Option is useless. This needs to be reviewed later. o 13. Emphasise that negotiation/synchronization are independent from discovery, although the rapid discovery mode includes the first step of a negotiation/synchronization. (Sheng) RESOLVED by improved text. o 14. Do we need an unsolicited flooding mechanism for discovery (for discovery results that everyone needs), to reduce scaling impact of flooding discovery messages? (Toerless) RESOLVED: Yes, added to requirements and solution. o 15. Do we need flag bits in Objective Options to distinguish distinguish Synchronization and Negotiation "Request" or rapid mode "Discovery" messages? (Bing) RESOLVED: yes, work on the API showed that these flags are essential. o 16. (Related to issue 14). Should we revive the "unsolicited Response" for flooding synchronisation data? This has to be done carefully due to the well-known issues with flooding, but it could Bormann, et al. Expires January 8, 2018 [Page 56] Internet-Draft GRASP July 2017 be useful, e.g. for Intent distribution, where DNCP doesn't seem applicable. RESOLVED: Yes, see #14. o 17. Ensure that the discovery mechanism is completely proof against loops and protected against duplicate responses. RESOLVED: Added loop count mechanism. o 18. Discuss the handling of multiple valid discovery responses. RESOLVED: Stated that the choice must be available to the ASA but GRASP implementation should pick a default. o 19. Should we use a text-oriented format such as JSON/CBOR instead of native binary TLV format? RESOLVED: Yes, changed to CBOR. o 20. Is the Divert option needed? If a discovery response provides a valid IP address or FQDN, the recipient doesn't gain any extra knowledge from the Divert. On the other hand, the presence of Divert informs the receiver that the target is off- link, which might be useful sometimes. RESOLVED: Decided to keep Divert option. o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling Protocol)? RESOLVED: Yes, name changed. o 22. Does discovery mechanism scale robustly as needed? Need hop limit on relaying? RESOLVED: Added hop limit. o 23. Need more details on TTL for caching discovery responses. RESOLVED: Done. o 24. Do we need "fast withdrawal" of discovery responses? RESOLVED: This doesn't seem necessary. If an ASA exits or stops supporting a given objective, peers will fail to start future sessions and will simply repeat discovery. Bormann, et al. Expires January 8, 2018 [Page 57] Internet-Draft GRASP July 2017 o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? RESOLVED: Decided not to consider this further as a GRASP protocol issue. GRASP objectives could embed DNS-SD formats if needed. o 26. Add a URL type to the locator options (for security bootstrap etc.) RESOLVED: Done, later renamed as URI. o 27. Security of Flood multicasts (Section 2.5.6.2). RESOLVED: added text. o 28. Does ACP support secure link-local multicast? RESOLVED by new text in the Security Considerations. o 29. PEN is used to distinguish vendor options. Would it be better to use a domain name? Anything unique will do. RESOLVED: Simplified this by removing PEN field and changing naming rules for objectives. o 30. Does response to discovery require randomized delays to mitigate amplification attacks? RESOLVED: WG feedback is that it's unnecessary. o 31. We have specified repeats for failed discovery etc. Is that sufficient to deal with sleeping nodes? RESOLVED: WG feedback is that it's unnecessary to say more. o 32. We have one-to-one synchronization and flooding synchronization. Do we also need selective flooding to a subset of nodes? RESOLVED: This will be discussed as a protocol extension in a separate draft (draft-liu-anima-grasp-distribution). o 33. Clarify if/when discovery needs to be repeated. RESOLVED: Done. o 34. Clarify what is mandatory for running in ACP, expand discussion of security boundary when running with no ACP - might rely on the local PKI infrastructure. Bormann, et al. Expires January 8, 2018 [Page 58] Internet-Draft GRASP July 2017 RESOLVED: Done. o 35. State that role-based authorization of ASAs is out of scope for GRASP. GRASP doesn't recognize/handle any "roles". RESOLVED: Done. o 36. Reconsider CBOR definition for PEN syntax. ( objective-name = text / [pen, text] ; pen = uint ) RESOLVED: See issue 29. o 37. Are URI locators really needed? RESOLVED: Yes, e.g. for security bootstrap discovery, but added note that addresses are the normal case (same for FQDN locators). o 38. Is Session ID sufficient to identify relayed responses? Isn't the originator's address needed too? RESOLVED: Yes, this is needed for multicast messages and their responses. o 39. Clarify that a node will contain one GRASP instance supporting multiple ASAs. RESOLVED: Done. o 40. Add a "reason" code to the DECLINE option? RESOLVED: Done. o 41. What happens if an ASA cannot conveniently use one of the GRASP mechanisms? Do we (a) add a message type to GRASP, or (b) simply pass the discovery results to the ASA so that it can open its own socket? RESOLVED: Both would be possible, but (b) is preferred. o 42. Do we need a feature whereby an ASA can bypass the ACP and use the data plane for efficiency/throughput? This would require discovery to return non-ACP addresses and would evade ACP security. RESOLVED: This is considered out of scope for GRASP, but a comment has been added in security considerations. Bormann, et al. Expires January 8, 2018 [Page 59] Internet-Draft GRASP July 2017 o 43. Rapid mode synchronization and negotiation is currently limited to a single objective for simplicity of design and implementation. A future consideration is to allow multiple objectives in rapid mode for greater efficiency. RESOLVED: This is considered out of scope for this version. o 44. In requirement T9, the words that encryption "may not be required in all deployments" were removed. Is that OK?. RESOLVED: No objections. o 45. Device Identity Option is unused. Can we remove it completely?. RESOLVED: No objections. Done. o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD messages is intended to assist in loop prevention. However, we also have the loop count for that. Also, if we create a new Session ID each time a DISCOVER or FLOOD is relayed, that ID can be disambiguated by recipients. It would be simpler to remove the initiator from the messages, making parsing more uniform. Is that OK? RESOLVED: Yes. Done. o 47. REQUEST is a dual purpose message (request negotiation or request synchronization). Would it be better to split this into two different messages (and adjust various message names accordingly)? RESOLVED: Yes. Done. o 48. Should the Appendix "Capability Analysis of Current Protocols" be deleted before RFC publication? RESOLVED: No (per WG meeting at IETF 96). o 49. Section 2.5.1 Should say more about signaling between two autonomic networks/domains. RESOLVED: Description of separate GRASP instance added. o 50. Is Rapid mode limited to on-link only? What happens if first discovery responder does not support Rapid Mode? Section 2.5.5, Section 2.5.6) Bormann, et al. Expires January 8, 2018 [Page 60] Internet-Draft GRASP July 2017 RESOLVED: Not limited to on-link. First responder wins. o 51. Should flooded objectives have a time-to-live before they are deleted from the flood cache? And should they be tagged in the cache with their source locator? RESOLVED: TTL added to Flood (and Discovery Response) messages. Cached flooded objectives must be tagged with their originating ASA locator, and multiple copies must be kept if necessary. o 52. Describe in detail what is allowed and disallowed in an insecure instance of GRASP. RESOLVED: Done. o 53. Tune IANA Considerations to support early assignment request. o 54. Is there a highly unlikely race condition if two peers simultaneously choose the same Session ID and send each other simultaneous M_REQ_NEG messages? RESOLVED: Yes. Enhanced text on Session ID generation, and added precaution when receiving a Request message. o 55. Could discovery be performed over TCP? RESOLVED: Unicast discovery added as an option. o 56. Change Session-ID to 32 bits? RESOLVED: Done. o 57. Add M_INVALID message? RESOLVED: Done. o 58. Maximum message size? RESOLVED by specifying default maximum message size (2048 bytes). o 59. Add F_NEG_DRY flag to specify a "dry run" objective?. RESOLVED: Done. o 60. Change M_FLOOD syntax to associate a locator with each objective? Bormann, et al. Expires January 8, 2018 [Page 61] Internet-Draft GRASP July 2017 RESOLVED: Done. o 61. Is the SONN constrained instance really needed? RESOLVED: Retained but only as an option. o 62. Is it helpful to tag descriptive text with message names (M_DISCOVER etc.)? RESOLVED: Yes, done in various parts of the text. o 63. Should encryption be MUST instead of SHOULD in Section 2.5.1 and Section 2.5.1? RESOLVED: Yes, MUST implement in both cases. o 64. Should more security text be moved from the main text into the Security Considerations? RESOLVED: No, on AD advice. o 65. Do we need to formally restrict Unicode characters allowed in objective names? RESOLVED: No, but need to point to guidance from PRECIS WG. o 66. Split requirements into separate document? RESOLVED: No, on AD advice. o 67. Remove normative dependency on draft-greevenbosch-appsawg- cbor-cddl? RESOLVED: No, on AD advice. In worst case, fix at AUTH48. Appendix C. Change log [RFC Editor: Please remove] draft-ietf-anima-grasp-15, 2017-07-07: Updates following additional IESG comments: Security (Eric Rescorla): missing brittleness of group security concept, attack via compromised member. TSV (Mirja Kuehlewind): clarification on the use of UDP, TCP, mandate use of TCP (or other reliable transport). Clarified that in ACP, UDP is not used at all. Bormann, et al. Expires January 8, 2018 [Page 62] Internet-Draft GRASP July 2017 Clarified that GRASP itself needs TCP listen port (was previously written as if this was optional). draft-ietf-anima-grasp-14, 2017-07-02: Updates following additional IESG comments: Updated 2.5.1 and 2.5.2 based on IESG security feedback (specify dependency against security substrate). Strengthened requirement for reliable transport protocol. draft-ietf-anima-grasp-13, 2017-06-06: Updates following additional IESG comments: Removed all mention of TLS, including SONN, since it was under- specified. Clarified other text about trust and security model. Banned Rapid Mode when multicast is insecure. Explained use of M_INVALID to support extensibility Corrected details on discovery cache TTL and discovery timeout. Improved description of multicast UDP w.r.t. RFC8085. Clarified when transport connections are opened or closed. Noted that IPPROTO values come from the Protocol Numbers registry Protocol change: Added protocol and port numbers to URI locator. Removed inaccurate text about routing protocols Moved Requirements section to an Appendix. Other editorial and technical clarifications. draft-ietf-anima-grasp-12, 2017-05-19: Updates following IESG comments: Clarified that GRASP runs in a single addressing realm Bormann, et al. Expires January 8, 2018 [Page 63] Internet-Draft GRASP July 2017 Improved wording about FQDN resolution, clarified that URI usage is out of scope. Clarified description of negotiation timeout. Noted that 'dry run' semantics are ASA-dependent Made the ACP a normative reference Clarified that LL multicasts are limited to GRASP interfaces Unicast UDP moved out of scope Editorial clarifications draft-ietf-anima-grasp-11, 2017-03-30: Updates following IETF 98 discussion: Encryption changed to a MUST implement. Pointed to guidance on UTF-8 names. draft-ietf-anima-grasp-10, 2017-03-10: Updates following IETF Last call: Protocol change: Specify that an objective with no initial value should have its value field set to CBOR 'null'. Protocol change: Specify behavior on receiving unrecognized message type. Noted that UTF-8 names are matched byte-for-byte. Added brief guidance for Expert Reviewer of new generic objectives. Numerous editorial improvements and clarifications and minor text rearrangements, none intended to change the meaning. draft-ietf-anima-grasp-09, 2016-12-15: Protocol change: Add F_NEG_DRY flag to specify a "dry run" objective. Protocol change: Change M_FLOOD syntax to associate a locator with each objective. Bormann, et al. Expires January 8, 2018 [Page 64] Internet-Draft GRASP July 2017 Concentrated mentions of TLS in one section, with all details out of scope. Clarified text around constrained instances of GRASP. Strengthened text restricting LL addresses in locator options. Clarified description of rapid mode processsing. Specified that cached discovery results should not be returned on the same interface where they were learned. Shortened text in "High Level Design Choices" Dropped the word 'kernel' to avoid confusion with o/s kernel mode. Editorial improvements and clarifications. draft-ietf-anima-grasp-08, 2016-10-30: Protocol change: Added M_INVALID message. Protocol change: Increased Session ID space to 32 bits. Enhanced rules to avoid Session ID clashes. Corrected and completed description of timeouts for Request messages. Improved wording about exponential backoff and DoS. Clarified that discovery relaying is not done by limited security instances. Corrected and expanded explanation of port used for Discovery Response. Noted that Discovery message could be sent unicast in special cases. Added paragraph on extensibility. Specified default maximum message size. Added Appendix for sample messages. Added short protocol overview. Editorial fixes, including minor re-ordering for readability. Bormann, et al. Expires January 8, 2018 [Page 65] Internet-Draft GRASP July 2017 draft-ietf-anima-grasp-07, 2016-09-13: Protocol change: Added TTL field to Flood message (issue 51). Protocol change: Added Locator option to Flood message (issue 51). Protocol change: Added TTL field to Discovery Response message (corrollary to issue 51). Clarified details of rapid mode (issues 43 and 50). Description of inter-domain GRASP instance added (issue 49). Description of limited security GRASP instances added (issue 52). Strengthened advice to use TCP rather than UDP. Updated IANA considerations and text about well-known port usage (issue 53). Amended text about ASA authorization and roles to allow for overlapping ASAs. Added text recommending that Flood should be repeated periodically. Editorial fixes. draft-ietf-anima-grasp-06, 2016-06-27: Added text on discovery cache timeouts. Noted that ASAs that are only initiators do not need to respond to discovery message. Added text on unexpected address changes. Added text on robust implementation. Clarifications and editorial fixes for numerous review comments Added open issues for some review comments. draft-ietf-anima-grasp-05, 2016-05-13: Noted in requirement T1 that it should be possible to implement ASAs independently as user space programs. Bormann, et al. Expires January 8, 2018 [Page 66] Internet-Draft GRASP July 2017 Protocol change: Added protocol number and port to discovery response. Updated protocol description, CDDL and IANA considerations accordingly. Clarified that discovery and flood multicasts are handled by the GRASP core, not directly by ASAs. Clarified that a node may discover an objective without supporting it for synchronization or negotiation. Added Implementation Status section. Added reference to SCSP. Editorial fixes. draft-ietf-anima-grasp-04, 2016-03-11: Protocol change: Restored initiator field in certain messages and adjusted relaying rules to provide complete loop detection. Updated IANA Considerations. draft-ietf-anima-grasp-03, 2016-02-24: Protocol change: Removed initiator field from certain messages and adjusted relaying requirement to simplify loop detection. Also clarified narrative explanation of discovery relaying. Protocol change: Split Request message into two (Request Negotiation and Request Synchronization) and updated other message names for clarity. Protocol change: Dropped unused Device ID option. Further clarified text on transport layer usage. New text about multicast insecurity in Security Considerations. Various other clarifications and editorial fixes, including moving some material to Appendix. draft-ietf-anima-grasp-02, 2016-01-13: Resolved numerous issues according to WG discussions. Renumbered requirements, added D9. Bormann, et al. Expires January 8, 2018 [Page 67] Internet-Draft GRASP July 2017 Protocol change: only allow one objective in rapid mode. Protocol change: added optional error string to DECLINE option. Protocol change: removed statement that seemed to say that a Request not preceded by a Discovery should cause a Discovery response. That made no sense, because there is no way the initiator would know where to send the Request. Protocol change: Removed PEN option from vendor objectives, changed naming rule accordingly. Protocol change: Added FLOOD message to simplify coding. Protocol change: Added SYNCH message to simplify coding. Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD messages. But also allowed the relay process for DISCOVER and FLOOD to regenerate a Session ID. Protocol change: Require that discovered addresses must be global (except during bootstrap). Protocol change: Receiver of REQUEST message must close socket if no ASA is listening for the objective. Protocol change: Simplified Waiting message. Protocol change: Added No Operation message. Renamed URL locator type as URI locator type. Updated CDDL definition. Various other clarifications and editorial fixes. draft-ietf-anima-grasp-01, 2015-10-09: Updated requirements after list discussion. Changed from TLV to CBOR format - many detailed changes, added co- author. Tightened up loop count and timeouts for various cases. Noted that GRASP does not provide transactional integrity. Various other clarifications and editorial fixes. Bormann, et al. Expires January 8, 2018 [Page 68] Internet-Draft GRASP July 2017 draft-ietf-anima-grasp-00, 2015-08-14: File name and protocol name changed following WG adoption. Added URL locator type. draft-carpenter-anima-gdn-protocol-04, 2015-06-21: Tuned wording around hierarchical structure. Changed "device" to "ASA" in many places. Reformulated requirements to be clear that the ASA is the main customer for signaling. Added requirement for flooding unsolicited synch, and added it to protocol spec. Recognized DNCP as alternative for flooding synch data. Requirements clarified, expanded and rearranged following design team discussion. Clarified that GDNP discovery must not be a prerequisite for GDNP negotiation or synchronization (resolved issue 13). Specified flag bits for objective options (resolved issue 15). Clarified usage of ACP vs TLS/DTLS and TCP vs UDP (resolved issues 9,10,11). Updated DNCP description from latest DNCP draft. Editorial improvements. draft-carpenter-anima-gdn-protocol-03, 2015-04-20: Removed intrinsic security, required external security Format changes to allow DNCP co-existence Recognized DNS-SD as alternative discovery method. Editorial improvements draft-carpenter-anima-gdn-protocol-02, 2015-02-19: Tuned requirements to clarify scope, Bormann, et al. Expires January 8, 2018 [Page 69] Internet-Draft GRASP July 2017 Clarified relationship between types of objective, Clarified that objectives may be simple values or complex data structures, Improved description of objective options, Added loop-avoidance mechanisms (loop count and default timeout, limitations on discovery relaying and on unsolicited responses), Allow multiple discovery objectives in one response, Provided for missing or multiple discovery responses, Indicated how modes such as "dry run" should be supported, Minor editorial and technical corrections and clarifications, Reorganized future work list. draft-carpenter-anima-gdn-protocol-01, restructured the logical flow of the document, updated to describe synchronization completely, add unsolicited responses, numerous corrections and clarifications, expanded future work list, 2015-01-06. draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- 02, 2014-10-08. Appendix D. Example Message Formats For readers unfamiliar with CBOR, this appendix shows a number of example GRASP messages conforming to the CDDL syntax given in Section 5. Each message is shown three times in the following formats: 1. CBOR diagnostic notation. 2. Similar, but showing the names of the constants. (Details of the flag bit encoding are omitted.) 3. Hexadecimal version of the CBOR wire format. Long lines are split for display purposes only. Bormann, et al. Expires January 8, 2018 [Page 70] Internet-Draft GRASP July 2017 D.1. Discovery Example The initiator (2001:db8:f000:baaa:28cc:dc4c:9703:6781) multicasts a discovery message looking for objective EX1: [1, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", 5, 2, 0]] [M_DISCOVERY, 13948744, h'20010db8f000baaa28ccdc4c97036781', ["EX1", F_SYNCH_bits, 2, 0]] h'84011a00d4d7485020010db8f000baaa28ccdc4c970367818463455831050200' A peer (2001:0db8:f000:baaa:f000:baaa:f000:baaa) responds with a locator: [2, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, [103, h'20010db8f000baaaf000baaaf000baaa', 6, 49443]] [M_RESPONSE, 13948744, h'20010db8f000baaa28ccdc4c97036781', 60000, [O_IPv6_LOCATOR, h'20010db8f000baaaf000baaaf000baaa', IPPROTO_TCP, 49443]] h'85021a00d4d7485020010db8f000baaa28ccdc4c9703678119ea6084186750 20010db8f000baaaf000baaaf000baaa0619c123' D.2. Flood Example The initiator multicasts a flood message. The single objective has a null locator. There is no response: [9, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, [["EX1", 5, 2, ["Example 1 value=", 100]],[] ] ] [M_FLOOD, 3504974, h'20010db8f000baaa28ccdc4c97036781', 10000, [["EX1", F_SYNCH_bits, 2, ["Example 1 value=", 100]],[] ] ] h'86091a00357b4e5020010db8f000baaa28ccdc4c97036781192710 828463455831050282704578616d706c6520312076616c75653d186480' D.3. Synchronization Example Following successful discovery of objective EX2, the initiator unicasts a request: [4, 4038926, ["EX2", 5, 5, 0]] [M_REQ_SYN, 4038926, ["EX2", F_SYNCH_bits, 5, 0]] h'83041a003da10e8463455832050500' The peer responds with a value: [8, 4038926, ["EX2", 5, 5, ["Example 2 value=", 200]]] [M_SYNCH, 4038926, ["EX2", F_SYNCH_bits, 5, ["Example 2 value=", 200]]] h'83081a003da10e8463455832050582704578616d706c6520322076616c75653d18c8' Bormann, et al. Expires January 8, 2018 [Page 71] Internet-Draft GRASP July 2017 D.4. Simple Negotiation Example Following successful discovery of objective EX3, the initiator unicasts a request: [3, 802813, ["EX3", 3, 6, ["NZD", 47]]] [M_REQ_NEG, 802813, ["EX3", F_NEG_bits, 6, ["NZD", 47]]] h'83031a000c3ffd8463455833030682634e5a44182f' The peer responds with immediate acceptance. Note that no objective is needed, because the initiator's request was accepted without change: [6, 802813, [101]] [M_END , 802813, [O_ACCEPT]] h'83061a000c3ffd811865' D.5. Complete Negotiation Example Again the initiator unicasts a request: [3, 13767778, ["EX3", 3, 6, ["NZD", 410]]] [M_REQ_NEG, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 410]]] h'83031a00d214628463455833030682634e5a4419019a' The responder starts to negotiate (making an offer): [5, 13767778, ["EX3", 3, 6, ["NZD", 80]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 6, ["NZD", 80]]] h'83051a00d214628463455833030682634e5a441850' The initiator continues to negotiate (reducing its request, and note that the loop count is decremented): [5, 13767778, ["EX3", 3, 5, ["NZD", 307]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 5, ["NZD", 307]]] h'83051a00d214628463455833030582634e5a44190133' The responder asks for more time: [7, 13767778, 34965] [M_WAIT, 13767778, 34965] h'83071a00d21462198895' The responder continues to negotiate (increasing its offer): Bormann, et al. Expires January 8, 2018 [Page 72] Internet-Draft GRASP July 2017 [5, 13767778, ["EX3", 3, 4, ["NZD", 120]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 4, ["NZD", 120]]] h'83051a00d214628463455833030482634e5a441878' The initiator continues to negotiate (reducing its request): [5, 13767778, ["EX3", 3, 3, ["NZD", 246]]] [M_NEGOTIATE, 13767778, ["EX3", F_NEG_bits, 3, ["NZD", 246]]] h'83051a00d214628463455833030382634e5a4418f6' The responder refuses to negotiate further: [6, 13767778, [102, "Insufficient funds"]] [M_END , 13767778, [O_DECLINE, "Insufficient funds"]] h'83061a00d2146282186672496e73756666696369656e742066756e6473' This negotiation has failed. If either side had sent [M_END, 13767778, [O_ACCEPT]] it would have succeeded, converging on the objective value in the preceding M_NEGOTIATE. Note that apart from the initial M_REQ_NEG, the process is symmetrical. Appendix E. Requirement Analysis of Discovery, Synchronization and Negotiation This section discusses the requirements for discovery, negotiation and synchronization capabilities. The primary user of the protocol is an autonomic service agent (ASA), so the requirements are mainly expressed as the features needed by an ASA. A single physical device might contain several ASAs, and a single ASA might manage several technical objectives. If a technical objective is managed by several ASAs, any necessary coordination is outside the scope of the GRASP signaling protocol. Furthermore, requirements for ASAs themselves, such as the processing of Intent [RFC7575], are out of scope for the present document. E.1. Requirements for Discovery D1. ASAs may be designed to manage any type of configurable device or software, as required in Appendix E.2. A basic requirement is therefore that the protocol can represent and discover any kind of technical objective (as defined in Section 2.1) among arbitrary subsets of participating nodes. In an autonomic network we must assume that when a device starts up it has no information about any peer devices, the network structure, or what specific role it must play. The ASA(s) inside the device are in the same situation. In some cases, when a new application session starts up within a device, the device or ASA may again lack Bormann, et al. Expires January 8, 2018 [Page 73] Internet-Draft GRASP July 2017 information about relevant peers. For example, it might be necessary to set up resources on multiple other devices, coordinated and matched to each other so that there is no wasted resource. Security settings might also need updating to allow for the new device or user. The relevant peers may be different for different technical objectives. Therefore discovery needs to be repeated as often as necessary to find peers capable of acting as counterparts for each objective that a discovery initiator needs to handle. From this background we derive the next three requirements: D2. When an ASA first starts up, it may have no knowledge of the specific network to which it is attached. Therefore the discovery process must be able to support any network scenario, assuming only that the device concerned is bootstrapped from factory condition. D3. When an ASA starts up, it must require no configured location information about any peers in order to discover them. D4. If an ASA supports multiple technical objectives, relevant peers may be different for different discovery objectives, so discovery needs to be performed separately to find counterparts for each objective. Thus, there must be a mechanism by which an ASA can separately discover peer ASAs for each of the technical objectives that it needs to manage, whenever necessary. D5. Following discovery, an ASA will normally perform negotiation or synchronization for the corresponding objectives. The design should allow for this by conveniently linking discovery to negotiation and synchronization. It may provide an optional mechanism to combine discovery and negotiation/synchronization in a single protocol exchange. D6. Some objectives may only be significant on the local link, but others may be significant across the routed network and require off- link operations. Thus, the relevant peers might be immediate neighbors on the same layer 2 link, or they might be more distant and only accessible via layer 3. The mechanism must therefore provide both on-link and off-link discovery of ASAs supporting specific technical objectives. D7. The discovery process should be flexible enough to allow for special cases, such as the following: o During initialization, a device must be able to establish mutual trust with autonomic nodes elsewhere in the network and participate in an authentication mechanism. Although this will inevitably start with a discovery action, it is a special case precisely because trust is not yet established. This topic is the Bormann, et al. Expires January 8, 2018 [Page 74] Internet-Draft GRASP July 2017 subject of [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once trust has been established for a device, all ASAs within the device inherit the device's credentials and are also trusted. This does not preclude the device having multiple credentials. o Depending on the type of network involved, discovery of other central functions might be needed, such as the Network Operations Center (NOC) [I-D.ietf-anima-stable-connectivity]. The protocol must be capable of supporting such discovery during initialization, as well as discovery during ongoing operation. D8. The discovery process must not generate excessive traffic and must take account of sleeping nodes. D9. There must be a mechanism for handling stale discovery results. E.2. Requirements for Synchronization and Negotiation Capability Autonomic networks need to be able to manage many different types of parameter and consider many dimensions, such as latency, load, unused or limited resources, conflicting resource requests, security settings, power saving, load balancing, etc. Status information and resource metrics need to be shared between nodes for dynamic adjustment of resources and for monitoring purposes. While this might be achieved by existing protocols when they are available, the new protocol needs to be able to support parameter exchange, including mutual synchronization, even when no negotiation as such is required. In general, these parameters do not apply to all participating nodes, but only to a subset. SN1. A basic requirement for the protocol is therefore the ability to represent, discover, synchronize and negotiate almost any kind of network parameter among selected subsets of participating nodes. SN2. Negotiation is an iterative request/response process that must be guaranteed to terminate (with success or failure). While tie- breaking rules must be defined specifically for each use case, the protocol should have some general mechanisms in support of loop and deadlock prevention, such as hop count limits or timeouts. SN3. Synchronization must be possible for groups of nodes ranging from small to very large. SN4. To avoid "reinventing the wheel", the protocol should be able to encapsulate the data formats used by existing configuration protocols (such as NETCONF/YANG) in cases where that is convenient. Bormann, et al. Expires January 8, 2018 [Page 75] Internet-Draft GRASP July 2017 SN5. Human intervention in complex situations is costly and error- prone. Therefore, synchronization or negotiation of parameters without human intervention is desirable whenever the coordination of multiple devices can improve overall network performance. It follows that the protocol's resource requirements must be small enough to fit in any device that would otherwise need human intervention. The issue of running in constrained nodes is discussed in [I-D.ietf-anima-reference-model]. SN6. Human intervention in large networks is often replaced by use of a top-down network management system (NMS). It therefore follows that the protocol, as part of the Autonomic Networking Infrastructure, should be capable of running in any device that would otherwise be managed by an NMS, and that it can co-exist with an NMS, and with protocols such as SNMP and NETCONF. SN7. Specific autonomic features are expected to be implemented by individual ASAs, but the protocol must be general enough to allow them. Some examples follow: o Dependencies and conflicts: In order to decide upon a configuration for a given device, the device may need information from neighbors. This can be established through the negotiation procedure, or through synchronization if that is sufficient. However, a given item in a neighbor may depend on other information from its own neighbors, which may need another negotiation or synchronization procedure to obtain or decide. Therefore, there are potential dependencies and conflicts among negotiation or synchronization procedures. Resolving dependencies and conflicts is a matter for the individual ASAs involved. To allow this, there need to be clear boundaries and convergence mechanisms for negotiations. Also some mechanisms are needed to avoid loop dependencies or uncontrolled growth in a tree of dependencies. It is the ASA designer's responsibility to avoid or detect looping dependencies or excessive growth of dependency trees. The protocol's role is limited to bilateral signaling between ASAs, and the avoidance of loops during bilateral signaling. o Recovery from faults and identification of faulty devices should be as automatic as possible. The protocol's role is limited to discovery, synchronization and negotiation. These processes can occur at any time, and an ASA may need to repeat any of these steps when the ASA detects an event such as a negotiation counterpart failing. o Since a major goal is to minimize human intervention, it is necessary that the network can in effect "think ahead" before Bormann, et al. Expires January 8, 2018 [Page 76] Internet-Draft GRASP July 2017 changing its parameters. One aspect of this is an ASA that relies on a knowledge base to predict network behavior. This is out of scope for the signaling protocol. However, another aspect is forecasting the effect of a change by a "dry run" negotiation before actually installing the change. Signaling a dry run is therefore a desirable feature of the protocol. Note that management logging, monitoring, alerts and tools for intervention are required. However, these can only be features of individual ASAs, not of the protocol itself. Another document [I-D.ietf-anima-stable-connectivity] discusses how such agents may be linked into conventional OAM systems via an Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane]. SN8. The protocol will be able to deal with a wide variety of technical objectives, covering any type of network parameter. Therefore the protocol will need a flexible and easily extensible format for describing objectives. At a later stage it may be desirable to adopt an explicit information model. One consideration is whether to adopt an existing information model or to design a new one. E.3. Specific Technical Requirements T1. It should be convenient for ASA designers to define new technical objectives and for programmers to express them, without excessive impact on run-time efficiency and footprint. In particular, it should be convenient for ASAs to be implemented independently of each other as user space programs rather than as kernel code, where such a programming model is possible. The classes of device in which the protocol might run is discussed in [I-D.ietf-anima-reference-model]. T2. The protocol should be easily extensible in case the initially defined discovery, synchronization and negotiation mechanisms prove to be insufficient. T3. To be a generic platform, the protocol payload format should be independent of the transport protocol or IP version. In particular, it should be able to run over IPv6 or IPv4. However, some functions, such as multicasting on a link, might need to be IP version dependent. By default, IPv6 should be preferred. T4. The protocol must be able to access off-link counterparts via routable addresses, i.e., must not be restricted to link-local operation. Bormann, et al. Expires January 8, 2018 [Page 77] Internet-Draft GRASP July 2017 T5. It must also be possible for an external discovery mechanism to be used, if appropriate for a given technical objective. In other words, GRASP discovery must not be a prerequisite for GRASP negotiation or synchronization. T6. The protocol must be capable of distinguishing multiple simultaneous operations with one or more peers, especially when wait states occur. T7. Intent: Although the distribution of Intent is out of scope for this document, the protocol must not by design exclude its use for Intent distribution. T8. Management monitoring, alerts and intervention: Devices should be able to report to a monitoring system. Some events must be able to generate operator alerts and some provision for emergency intervention must be possible (e.g. to freeze synchronization or negotiation in a mis-behaving device). These features might not use the signaling protocol itself, but its design should not exclude such use. T9. Because this protocol may directly cause changes to device configurations and have significant impacts on a running network, all protocol exchanges need to be fully secured against forged messages and man-in-the middle attacks, and secured as much as reasonably possible against denial of service attacks. There must also be an encryption mechanism to resist unwanted monitoring. However, it is not required that the protocol itself provides these security features; it may depend on an existing secure environment. Appendix F. Capability Analysis of Current Protocols This appendix discusses various existing protocols with properties related to the requirements described in Appendix E. The purpose is to evaluate whether any existing protocol, or a simple combination of existing protocols, can meet those requirements. Numerous protocols include some form of discovery, but these all appear to be very specific in their applicability. Service Location Protocol (SLP) [RFC2608] provides service discovery for managed networks, but requires configuration of its own servers. DNS-SD [RFC6763] combined with mDNS [RFC6762] provides service discovery for small networks with a single link layer. [RFC7558] aims to extend this to larger autonomous networks but this is not yet standardized. However, both SLP and DNS-SD appear to target primarily application layer services, not the layer 2 and 3 objectives relevant to basic network configuration. Both SLP and DNS-SD are text-based protocols. Bormann, et al. Expires January 8, 2018 [Page 78] Internet-Draft GRASP July 2017 Simple Network Management Protocol (SNMP) [RFC3416] uses a command/ response model not well suited for peer negotiation. Network Configuration Protocol (NETCONF) [RFC6241] uses an RPC model that does allow positive or negative responses from the target system, but this is still not adequate for negotiation. There are various existing protocols that have elementary negotiation abilities, such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], Neighbor Discovery (ND) [RFC4861], Port Control Protocol (PCP) [RFC6887], Remote Authentication Dial In User Service (RADIUS) [RFC2865], Diameter [RFC6733], etc. Most of them are configuration or management protocols. However, they either provide only a simple request/response model in a master/slave context or very limited negotiation abilities. There are some signaling protocols with an element of negotiation. For example Resource ReSerVation Protocol (RSVP) [RFC2205] was designed for negotiating quality of service parameters along the path of a unicast or multicast flow. RSVP is a very specialised protocol aimed at end-to-end flows. A more generic design is General Internet Signalling Transport (GIST) [RFC5971], but it is complex, tries to solve many problems, and is also aimed at per-flow signaling across many hops rather than at device-to-device signaling. However, we cannot completely exclude extended RSVP or GIST as a synchronization and negotiation protocol. They do not appear to be directly useable for peer discovery. RESTCONF [RFC8040] is a protocol intended to convey NETCONF information expressed in the YANG language via HTTP, including the ability to transit HTML intermediaries. While this is a powerful approach in the context of centralised configuration of a complex network, it is not well adapted to efficient interactive negotiation between peer devices, especially simple ones that might not include YANG processing already. The Distributed Node Consensus Protocol (DNCP) [RFC7787] is defined as a generic form of state synchronization protocol, with a proposed usage profile being the Home Networking Control Protocol (HNCP) [RFC7788] for configuring Homenet routers. A specific application of DNCP for autonomic networking was proposed in [I-D.stenberg-anima-adncp]. DNCP "is designed to provide a way for each participating node to publish a set of TLV (Type-Length-Value) tuples, and to provide a shared and common view about the data published... DNCP is most suitable for data that changes only infrequently... If constant rapid state changes are needed, the preferable choice is to use an additional point-to-point channel..." Bormann, et al. Expires January 8, 2018 [Page 79] Internet-Draft GRASP July 2017 Specific features of DNCP include: o Every participating node has a unique node identifier. o DNCP messages are encoded as a sequence of TLV objects, sent over unicast UDP or TCP, with or without (D)TLS security. o Multicast is used only for discovery of DNCP neighbors when lower security is acceptable. o Synchronization of state is maintained by a flooding process using the Trickle algorithm. There is no bilateral synchronization or negotiation capability. o The HNCP profile of DNCP is designed to operate between directly connected neighbors on a shared link using UDP and link-local IPv6 addresses. DNCP does not meet the needs of a general negotiation protocol, because it is designed specifically for flooding synchronization. Also, in its HNCP profile it is limited to link-local messages and to IPv6. However, at the minimum it is a very interesting test case for this style of interaction between devices without needing a central authority, and it is a proven method of network-wide state synchronization by flooding. The Server Cache Synchronization Protocol (SCSP) [RFC2334] also describes a method for cache synchronization and cache replication among a group of nodes. A proposal was made some years ago for an IP based Generic Control Protocol (IGCP) [I-D.chaparadza-intarea-igcp]. This was aimed at information exchange and negotiation but not directly at peer discovery. However, it has many points in common with the present work. None of the above solutions appears to completely meet the needs of generic discovery, state synchronization and negotiation in a single solution. Many of the protocols assume that they are working in a traditional top-down or north-south scenario, rather than a fluid peer-to-peer scenario. Most of them are specialized in one way or another. As a result, we have not identified a combination of existing protocols that meets the requirements in Appendix E. Also, we have not identified a path by which one of the existing protocols could be extended to meet the requirements. Bormann, et al. Expires January 8, 2018 [Page 80] Internet-Draft GRASP July 2017 Authors' Addresses Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28359 Bremen Germany Email: cabo@tzi.org Brian Carpenter (editor) Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Bing Liu (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China Email: leo.liubing@huawei.com Bormann, et al. Expires January 8, 2018 [Page 81] ./draft-ietf-dhc-mac-assign-09.txt0000644000764400076440000013637213724173556016170 0ustar iustyiusty Dynamic Host Configuration (DHC) B. Volz Internet-Draft Cisco Intended status: Standards Track T. Mrugalski Expires: March 7, 2021 ISC CJ. Bernardos UC3M September 3, 2020 Link-Layer Addresses Assignment Mechanism for DHCPv6 draft-ietf-dhc-mac-assign-09 Abstract In certain environments, e.g., large scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable. Therefore an allocation mechanism is required. This draft proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or unnecessary. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 7, 2021. Copyright Notice Copyright (c) 2020 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 Volz, et al. Expires March 7, 2021 [Page 1] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Deployment scenarios and mechanism overview . . . . . . . . . 4 4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4 4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5 4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5 5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 6 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 7 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 7 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 9 9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 9 10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 9 10.1. Identity Association for Link-Layer Addresses Option . . 10 10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12 11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 16.1. Normative References . . . . . . . . . . . . . . . . . . 16 16.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. IEEE 802c Summary . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction There are several deployment types that deal with a large number of devices that need to be initialized. One of them is a scenario where virtual machines (VMs) are created on a massive scale. Typically the new VM instances are assigned a link-layer address, but random assignment does not scale well due to the risk of a collision (see Appendix A.1 of [RFC4429]). Another use case is IoT (Internet of Things) devices (see [RFC7228]). The huge number of such devices could strain the IEEE's available OUI (Organizationally Unique Identifier) global address space. While there is typically no need to provide global link-layer address uniqueness for such devices, a Volz, et al. Expires March 7, 2021 [Page 2] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 link-layer assignment mechanism allows for conflicts to be avoided inside an administrative domain. For those reasons, it is desired to have some form of mechanism that would be able to assign locally unique MAC (media access control) addresses. This document proposes a new mechanism that extends DHCPv6 operation to handle link-layer address assignments. Since DHCPv6 ([RFC8415]) is a protocol that can allocate various types of resources (non-temporary addresses, temporary addresses, prefixes, as well as many options) and has the necessary infrastructure to maintain such allocations (numerous server and client implementations, large deployed relay infrastructure, and supportive solutions such as leasequery and failover), it is a good candidate to address the desired functionality. While this document presents a design that should be usable for any link-layer address type, some of the details are specific to IEEE 802 48-bit MAC addresses [IEEEStd802]. Future documents may provide specifics for other link-layer address types. IEEE 802 originally set aside half of the 48-bit MAC address space for local use (where the U/L bit is set to 1). In 2017, IEEE published an amendment [IEEEStd802c] that divides this space into quadrants with differentied address rules. More details are in Appendix A. IEEE is also developing protocols and procedures for assignment of locally unique addresses (IEEE 802.1CQ). This work may serve as an alternative protocol for assignment. For additional background, see [IEEE-P802.1CQ-Project]. 2. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology The DHCP terminology relevant to this specification from [RFC8415] applies here. The following definitions either modify those definitions as to how they are used in this document or define new terminology used herein. Volz, et al. Expires March 7, 2021 [Page 3] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 address Unless specified otherwise, an address means a link- layer (or MAC) address, as specified in [IEEEStd802]. The address is typically six octets long, but some network architectures may use different lengths. address block A number of consecutive link-layer addresses. An address block is expressed as a first address plus a number that designates the number of additional (extra) addresses. A single address can be represented by the address itself and zero extra addresses. client A node that is interested in obtaining link-layer addresses. It implements the basic DHCP mechanisms needed by a DHCP client as described in [RFC8415] and supports the new options (IA_LL and LLADDR, see below) specified in this document. The client may or may not support IPv6 address assignment and prefix delegation as specified in [RFC8415]. IA_LL Identity Association for Link-Layer Address: an identity association (IA) used to request or assign link-layer addresses. See Section 10.1 for details on the IA_LL option. LLADDR Link-layer address option that is used to request or assign a block of link-layer addresses. See Section 10.2 for details on the LLADDR option. server A node that manages link-layer address allocation and is able to respond to client queries. It implements basic DHCP server functionality as described in [RFC8415] and supports the new options (IA_LL and LLADDR) specified in this document. The server may or may not support IPv6 address assignment and prefix delegation as specified in [RFC8415]. 4. Deployment scenarios and mechanism overview This mechanism is designed to be generic and usable in many deployments, but there are two scenarios it attempts to address in particular: (i) proxy client mode, and (ii) direct client mode. 4.1. Proxy client mode scenario This mode is used when an entity acts as a DHCP client and requests available DHCP servers to assign one or more addresses (an address block), to be then assigned for use by the final end-devices. Large- scale virtualization is one application scenario for proxy client Volz, et al. Expires March 7, 2021 [Page 4] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 mode. In such environments this entity is often called a hypervisor and is frequently required to spawn new VMs. The hypervisor needs to assign new addresses to those machines. The hypervisor does not use those addresses for itself, but rather uses them to create new VMs with appropriate addresses. It is worth pointing out the cumulative nature of this scenario. Over time, the hypervisor is likely to increase its address usage. Some obsolete VMs will be deleted and their addresses are potentially eligible for reuse for new VMs. 4.2. Direct client mode scenario This mode can be used when an entity acts as a DHCP client and requests available DHCP servers to assign one or more addresses (an address block) for its use. This usage scenario is related to IoT, as described earlier (see Section 1). Upon first boot, for each interface the device uses a temporary address, as described in [IEEEStd802.11] or to be described in IEEE 802.1CQ [IEEE-P802.1CQ-Project], to send initial DHCP packets to available DHCP servers wherein the device requests a single address for that network interface. Once the server assigns an address, the device abandons its temporary address and uses the assigned (leased) address. Note that a client that operates as above that does not have a globally unique link-layer address on any of its interfaces MUST NOT use a link-layer based DUID (DHCP Unique Identifier). For more details, refer to Section 11 of [RFC8415]. Also, a client that operates as above may run into issues if the switch it is connected to prohibits or restricts link-layer address changes. This may limit where this capability can be used, or may require the administrator to adjust the configuration of the switch(es) to allow a change in address. 4.3. Mechanism Overview In all scenarios the protocol operates in fundamentally the same way. The device requesting an address, acting as a DHCP client, will send a Solicit message with a IA_LL option to all available DHCP servers. That IA_LL option MUST include a LLADDR option specifying the link- layer-type and link-layer-len and may include a specific address or address block as a hint for the server. Each available server responds with either a Reply message with committed address(es) (if Rapid Commit was requested and honored) or an Advertise message with offered address(es). The client selects a server's response as governed by [RFC8415]. If necessary, the client sends a Request message and the target server will then assign the address(es) and Volz, et al. Expires March 7, 2021 [Page 5] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 send a Reply message. Once a Reply is received, the client can start using those address(es). Normal DHCP mechanisms are in use. The client is expected to periodically renew the addresses as governed by T1 and T2 timers and stop using the address once the valid lifetime expires. Renewals can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). An administrator may make the address assignment permanent by specifying use of the "infinity" valid lifetime, as defined in Section 7.7 of [RFC8415]. The client can release addresses when they are no longer needed by sending a Release message (see Section 18.2.7 of [RFC8415]). Figure 9 in [RFC8415] shows a timeline diagram of the messages exchanged between a client and two servers for the typical lifecycle of one or more leases. Confirm and Information-Request messages are not used in link-layer address assignment. Decline should technically never be needed, but see Section 11 for one situation where this message is needed. Clients implementing this mechanism SHOULD use the Rapid Commit option as specified in Section 5.1 and 18.2.1 of [RFC8415] to obtain addresses with a 2-message exchange when possible. Devices supporting this proposal MAY support the reconfigure mechanism, as defined in Section 18.2.11 of [RFC8415]. If supported by both server and client, the reconfigure mechanism allows the administrator to immediately notify clients that the configuration has changed and triggers retrieval of relevant changes immediately, rather than after the T1 timer elapses. Since this mechanism requires implementation of Reconfigure Key Authentication Protocol (See Section 20.4 of [RFC8415]), small-footprint devices may choose to not support it. 5. Design Assumptions One of the essential aspects of this mechanism is its cumulative nature, especially in the hypervisor scenario. The server-client relationship does not look like other DHCP transactions in the hypervisor scenario. In a typical environment, there would be one server and a rather small number of hypervisors, possibly even only one. However, over time the number of addresses requested by the hypervisor(s) will increase as more VMs are spawned. Another aspect crucial for efficient design is the observation that a single client acting as hypervisor will likely use thousands of Volz, et al. Expires March 7, 2021 [Page 6] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 addresses. An approach similar to what is used for IPv6 address or prefix assignment (IA container with all assigned addresses listed, one option for each address) would not work well. Therefore the mechanism should operate on address blocks, rather than single values. A single address can be treated as an address block with just one address. The DHCP mechanisms are reused to large degree, including message and option formats, transmission mechanisms, relay infrastructure and others. However, a device wishing to support only link-layer address assignment is not required to support full DHCP. In other words, the device may support only assignment of link-layer addresses, but not IPv6 addresses or prefixes. 6. Information Encoding A client MUST send a LLADDR option encapsulated in an IA_LL option to specify the link-layer-type and link-layer-len values. For link- layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client sets the link-layer-address field to: 1. All zeroes if the client has no hint as to the starting address of the unicast address block. This address has the IEEE 802 individual/group bit set to 0 (individual). 2. Any other value to request a specific block of address starting with the specified address Encoding information for other link-layer-types may be added in the future by publishing an RFC that specifies those values. A client sets the extra-addresses field to either 0 for a single address or the size of the requested address block minus 1. A client MUST set the valid-lifetime field to 0 (this field MUST be ignored by the server). 7. Requesting Addresses The addresses are assigned in blocks. The smallest block is a single address. To request an assignment, the client sends a Solicit message with an IA_LL option in the message. The IA_LL option MUST contain a LLADDR option as specified in Section 6. The server, upon receiving an IA_LL option, inspects its content and may offer an address or addresses for each LLADDR option according to its policy. The server MAY take into consideration the address block requested by the client in the LLADDR option. However, the server Volz, et al. Expires March 7, 2021 [Page 7] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 MAY choose to ignore some or all parameters of the requested address block. In particular, the server may send a different starting address than requested, or a smaller number of addresses than requested. The server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. If the server is unable to provide any addresses it MUST return the IA_LL option containing a Status Code option (see Section 21.13 of [RFC8415]) with status set to NoAddrsAvail. Note: Servers that do not support the IA_LL option will ignore the option and not return it in Advertise (and Reply) messages. Clients that send IA_LL options MUST treat this as if the server returned the NoAddrsAvail status for these IA_LL option(s). The client waits for available servers to send Advertise responses and picks one server as defined in Section 18.2.9 of [RFC8415]. The client then sends a Request message that includes the IA_LL container option with the LLADDR option copied from the Advertise message sent by the chosen server. The client MUST process the address block(s) returned in the Advertise, rather than what it included in the Solicit, and may consider the offered address block(s) in selecting the Advertise to accept. The server may offer a smaller number of addresses or different addresses from those requested. A client MUST NOT use resources returned in an Advertise message except to select a server and in sending the Request to that server; resources are only useable by a client when returned in a Reply message. Upon reception of a Request message with IA_LL container option, the server assigns the requested addresses. The server allocates a block of addresses according to its configured policy. The server MAY assign a different block or smaller block size than requested in the Request message. The server then generates and sends a Reply message back to the client. Upon receiving a Reply message, the client parses the IA_LL container option and may start using all provided addresses. It MUST restart its T1 and T2 timers using the values specified in the IA_LL option. The client MUST use the address block(s) returned in the Reply message, which may be smaller block(s) or with different address(es) than requested. A client that has included a Rapid Commit option in the Solicit may receive a Reply in response to the Solicit and skip the Advertise and Request steps above (see Section 18.2.1 of [RFC8415]). Volz, et al. Expires March 7, 2021 [Page 8] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 A client that changes its link-layer address on an interface SHOULD follow the recommendations in Section 7.2.6 of [RFC4861] to inform its neighbors of the new link-layer address quickly. 8. Renewing Addresses Address renewals follow the normal DHCP renewals processing described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, the client starts sending Renew messages with the IA_LL option containing a LLADDR option for the address block being renewed. The server responds with a Reply message that contains the renewed address block. The server MUST NOT shrink or expand the address block. Once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change. If the requesting client needs additional addresses -- e.g., in the hypervisor scenario because addresses need to be assigned to new VMs -- it MUST send an IA_LL option with a different IAID to create another "container" for more addresses. If the client is unable to Renew before the T2 timer elapses, it starts sending Rebind messages as described in Section 18.2.5 of [RFC8415]. 9. Releasing Addresses The client may decide to release a leased address block. A client MUST release the whole block in its entirety. A client releases an address block by sending a Release message that includes an IA_LL option containing the LLADDR option for the address block to release. The Release transmission mechanism is described in Section 18.2.7 of [RFC8415]. Note: If the client is releasing the link-layer address it is using, it MUST stop using this address before sending the Release message (as per [RFC8415]). In order to send the Release message, the client MUST use another address (such as the one originally used to initiate DHCPv6 to provide an allocated link-layer address). 10. Option Definitions This mechanism uses an approach similar to the existing mechanisms in DHCP. There is one container option (the IA_LL option) that contains the actual address or addresses, represented by an LLADDR option. Each LLADDR option represents an address block, which is expressed as a first address with a number that specifies how many additional addresses are included. Volz, et al. Expires March 7, 2021 [Page 9] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 10.1. Identity Association for Link-Layer Addresses Option The Identity Association for Link-Layer Addresses option (IA_LL option) is used to carry an IA_LL, the parameters associated with the IA_LL, and the address blocks associated with the IA_LL. The format of the IA_LL option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_IA_LL | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . IA_LL-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: IA_LL Option Format option-code OPTION_IA_LL (tbd1). option-len 12 + length of IA_LL-options field. IAID The unique identifier for this IA_LL; the IAID must be unique among the identifiers for all of this client's IA_LLs. The number space for IA_LL IAIDs is separate from the number space for other IA option types (i.e., IA_NA, IA_TA, and IA_PD). A 4-octet field containing an unsigned integer. T1 The time interval after which the client should contact the server from which the addresses in the IA_LL were obtained to extend the valid lifetime of the addresses assigned to the IA_LL; T1 is a time duration relative to the current time expressed in units of seconds. A 4-octet field containing an unsigned integer. T2 The time interval after which the client should contact any available server to extend the valid lifetime of the addresses assigned to the IA_LL; T2 Volz, et al. Expires March 7, 2021 [Page 10] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 is a time duration relative to the current time expressed in units of seconds. A 4-octet field containing an unsigned integer. IA_LL-options Options associated with this IA_LL. A variable length field (12 octets less than the value in the option-len field). An IA_LL option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_LL options (though each must have a unique IAID). The status of any operations involving this IA_LL is indicated in a Status Code option (see Section 21.13 of [RFC8415]) in the IA_LL- options field. Note that an IA_LL has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the addresses in an IA_LL have expired, the IA_LL can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA_LL. In a message sent by a client to a server, the T1 and T2 fields MUST be set to 0. The server MUST ignore any values in these fields in messages received from a client. In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 times, unless those values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2. As per Section 7.7 of [RFC8415]), the value 0xffffffff is taken to mean "infinity" and should be used carefully. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any address block in the IA_LL before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest valid lifetime of the address blocks in the IA that the server is willing to extend, respectively. If the "shortest" valid lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. If the time at which the addresses in an IA_LL are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. The client MUST follow the rules defined in Section 14.2 in [RFC8415]. If a client receives an IA_LL with T1 greater than T2, and both T1 and T2 are greater than 0, the client discards the IA_LL option and Volz, et al. Expires March 7, 2021 [Page 11] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 processes the remainder of the message as though the server had not included the invalid IA_LL option. The IA_LL-options field typically contains one or more LLADDR options (see Section 10.2). If a client does not include a LLADDR option in a Solicit or Request message, the server MUST treat this as a request for a single address and that the client has no hint as to the address it would like. 10.2. Link-Layer Addresses Option The Link-Layer Addresses option is used to specify an address block associated with an IA_LL. The option must be encapsulated in the IA_LL-options field of an IA_LL option. The LLaddr-options fields encapsulates those options that are specific to this address block. The format of the Link-Layer Addresses option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_LLADDR | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | link-layer-type | link-layer-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . link-layer-address . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extra-addresses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . LLaddr-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: LLADDR Option Format option-code OPTION_LLADDR (tbd2). option-len 12 + link-layer-len field value + length of LLaddr- options field. Assuming a link-layer-address length of 6 and no extra options, the option-len would be 18. Volz, et al. Expires March 7, 2021 [Page 12] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 link-layer-type The link-layer type MUST be a valid hardware type assigned by the IANA, as described in [RFC5494] and in the "Hardware Types" table at https://www.iana.org/assignments/arp-parameters. A 2-octet field containing an unsigned integer. link-layer-len Specifies the length, in octets, of the link-layer- address field (typically 6, for a link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)). This is to accommodate link-layers that may have variable-length addresses. A 2-octet field containing an unsigned integer. link-layer-address Specifies the address of the first link-layer address that is being requested or assigned depending on the message. A client MAY send a special value to request any address. For a link-layer type of 1 and 6, see Section 6 for details on this field. A link- layer-len length octet field containing an address. extra-addresses Specifies the number of additional addresses that follow the address specified in link-layer-address. For a single address, 0 is used. For example: link- layer-address: 02:04:06:08:0a and extra-addresses 3 designates a block of 4 addresses, starting from 02:04:06:08:0a and ending with 02:04:06:08:0d (inclusive). A 4-octet field containing an unsigned integer. valid-lifetime The valid lifetime for the address(es) in the option, expressed in units of seconds. A 4-octet field containing an unsigned integer. LLaddr-options Any encapsulated options that are specific to this particular address block. Currently there are no such options defined, but there may be in the future. In a message sent by a client to a server, the valid lifetime field MUST be set to 0. The server MUST ignore any received value. In a message sent by a server to a client, the client MUST use the value in the valid lifetime field for the valid lifetime for the address block. The value in the valid lifetime field is the number of seconds remaining in the lifetime. As per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is taken to mean "infinity" and should be used carefully. Volz, et al. Expires March 7, 2021 [Page 13] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 More than one LLADDR option can appear in an IA_LL option. 11. Selecting Link-Layer Addresses for Assignment to an IA_LL A server selects link-layer addresses to be assigned to an IA_LL according to the assignment policies determined by the server administrator and the requirements of that address space. Link-layer addresses are typically specific to a link and the server SHOULD follow the steps in Section 13.1 of [RFC8415] to determine the client's link. For IEEE 802 MAC addresses (see [IEEEStd802] as amended by [IEEEStd802c]): 1. Server administrators SHOULD follow the IEEE 802 Specifications with regards to the unicast address pools made available for assignment (see Appendix A and [IEEEStd802c]) -- only address space reserved for local use or with the authorization of the assignee may be used. 2. Servers MUST NOT allow administrators to configure address pools that would cross the 2^42 bit boundary (for 48-bit MAC addresses) to avoid issues with changes in the first octet of the address and the special bits therein (see Appendix A). Clients MUST reject assignments where the assigned block would cross this boundary (they MUST decline the allocation - see Section 18.2.8 of [RFC8415]). 3. A server MAY use options supplied by a relay agent or client to select the quadrant (see Appendix A) from which addresses are to be assigned. This MAY include options, such as those specified in [I-D.ietf-dhc-slap-quadrant]. 12. IANA Considerations IANA is requested to assign the OPTION_IA_LL (tbd1) option code from the DHCPv6 "Option Codes" registry maintained at http://www.iana.org/assignments/dhcpv6-parameters and use the following data when adding the option to the registry: Value: tbd1 Description: OPTION_IA_LL Client ORO: No Singleton Option: No Reference: this document Volz, et al. Expires March 7, 2021 [Page 14] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 IANA is requested to assign the OPTION_LLADDR (tbd2) option code from the DHCPv6 "Option Codes" registry maintained at http://www.iana.org/assignments/dhcpv6-parameters and use the following data when adding the option to the registry: Value: tbd2 Description: OPTION_LLADDR Client ORO: No Singleton Option: No Reference: this document 13. Security Considerations See Section 22 of [RFC8415] and Section 23 of [RFC7227] for the DHCP security considerations. See [RFC8200] for the IPv6 security considerations. As discussed in Section 22 of [RFC8415], "DHCP lacks end-to-end encryption between clients and servers; thus, hijacking, tampering, and eavesdropping attacks are all possible as a result." In some network environments, it is possible to secure them as discussed later in that Section 22. There is a possibility of the same link-layer address being used by more than one device if not all parties on a link use this mechanism to obtain an address from the space assigned to the DHCP server. Note that this issue would exist on these networks even if DHCP were not used to obtain the address. Server implementations SHOULD consider configuration options to limit the maximum number of addresses to allocate (both in a single request and in total) to a client. However, note that this does not prevent a bad client actor from pretending to be many different clients and consuming all available addresses. 14. Privacy Considerations See Section 23 of [RFC8415] for the DHCP privacy considerations. For a client requesting a link-layer address directly from a server, as the address assigned to a client will likely be used by the client to communicate on the link, the address will be exposed to those able to listen in on this communication. For those peers on the link that are able to listen in on the DHCP exchange, they would also be able to correlate the client's identity (based on the DUID used) with the assigned address. Additional mechanisms, such as the ones described Volz, et al. Expires March 7, 2021 [Page 15] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 in [RFC7844] can also be used to improve anonymity by minimizing what is exposed. As discussed in Section 23 of [RFC8415], DHCP servers and hypervisors may need to consider the implications of assigning addresses sequentially. Though in general, this is only of link-local concern unlike for IPv6 address assignment and prefix delegation as these may be used for communication over the Internet. 15. Acknowledgements Thanks to the DHC Working Group participants that reviewed this document, provided comments, and support. With special thanks to Ian Farrer for his thorough reviews and shepherding of this document through the IETF process. Thanks also to area reviewers Samita Chakrabarti, Roni Even and Tianran Zhou, and IESG members Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba, Alvaro Retana, Eric Vyncke, and Robert Wilton for their suggestions. And to Roger Marks, Bob Grow, and Antonio de la Oliva for comments related to IEEE work and references. 16. References 16.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, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . Volz, et al. Expires March 7, 2021 [Page 16] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 16.2. Informative References [I-D.ietf-dhc-slap-quadrant] Bernardos, C. and A. Mourad, "SLAP quadrant selection option for DHCPv6", draft-ietf-dhc-slap-quadrant-10 (work in progress), August 2020. [IEEE-P802.1CQ-Project] "P802.1CQ - Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment", . [IEEEStd802] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802". [IEEEStd802.11] "IEEE Standard for Information technology - Telecommunications and information exchange between systems Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std 802.11". [IEEEStd802c] "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, Amendment 2: Local Medium Access Control (MAC) Address Usage, IEEE Std 802c-2017". [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, . [RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", RFC 5494, DOI 10.17487/RFC5494, April 2009, . [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, . Volz, et al. Expires March 7, 2021 [Page 17] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Appendix A. IEEE 802c Summary This appendix provides a brief summary of IEEE 802c [IEEEStd802c]. The original IEEE 802 specifications assigned half of the 48-bit MAC address space to local use -- these addresses have the U/L bit set to 1 and are locally administered with no imposed structure. In 2017, the IEEE issued the IEEE Std 802c specification which defines a new optional "Structured Local Address Plan (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space." Under this plan, there are 4 SLAP quadrants that use different assignment policies. The first octet of the MAC address Z and Y bits define the quadrant for locally assigned addresses (X-bit is 1). In IEEE representation, these bits are as follows: LSB MSB M X Y Z - - - - | | | | | | | +------------ SLAP Z-bit | | +--------------- SLAP Y-bit | +------------------ X-bit (U/L) = 1 for locally assigned +--------------------- M-bit (I/G) (unicast/group) Figure 3: SLAP Bits The SLAP quadrants are: Volz, et al. Expires March 7, 2021 [Page 18] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 +----------+-------+-------+-----------------------+----------------+ | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | | | | | | Identifier | +----------+-------+-------+-----------------------+----------------+ | 01 | 0 | 1 | Extended Local | ELI | | 11 | 1 | 1 | Standard Assigned | SAI | | 00 | 0 | 0 | Administratively | AAI | | | | | Assigned | | | 10 | 1 | 0 | Reserved | Reserved | +----------+-------+-------+-----------------------+----------------+ SLAP Quadrants Extended Local Identifier (ELI) derived MAC addresses are based on an assigned Company ID (CID), which is 24-bits (including the M, X, Y, and Z bits) for 48-bit MAC addresses. This leaves 24-bits for the locally assigned address for each CID for unicast (M-bit = 0) and also for multicast (M-bit = 1). The CID is assigned by the IEEE RA. Standard Assigned Identifier (SAI) derived MAC addresses are assigned by a protocol specified in an IEEE 802 standard. For 48-bit MAC addresses, 44 bits are available. Multiple protocols for assigning SAIs may be specified in IEEE standards. Coexistence of multiple protocols may be supported by limiting the subspace available for assignment by each protocol. Administratively Assigned Identifier (AAI) derived MAC addresses are assigned locally. Administrators manage the space as needed. Note that multicast IPv6 packets ([RFC2464]) use a destination address starting in 33-33, so AAI addresses in that range should not be assigned. For 48-bit MAC addresses, 44 bits are available. The last quadrant is reserved for future use. While this quadrant may also be used similar to AAI space, administrators should be aware that future specifications may define alternate uses that could be incompatible. Authors' Addresses Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 USA Email: volz@cisco.com Volz, et al. Expires March 7, 2021 [Page 19] Internet-Draft DHCPv6 Link-Layer Address Assignment September 2020 Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA Email: tomasz.mrugalski@gmail.com Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Volz, et al. Expires March 7, 2021 [Page 20] ./draft-ietf-anima-prefix-management-07.txt0000644000764400076440000014651413216066203020063 0ustar iustyiusty ANIMA WG S. Jiang, Ed. Internet-Draft Z. Du Intended status: Informational Huawei Technologies Co., Ltd Expires: June 18, 2018 B. Carpenter Univ. of Auckland Q. Sun China Telecom December 15, 2017 Autonomic IPv6 Edge Prefix Management in Large-scale Networks draft-ietf-anima-prefix-management-07 Abstract This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 18, 2018. Copyright Notice Copyright (c) 2017 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 (https://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 Jiang, et al. Expires June 18, 2018 [Page 1] Internet-Draft Auto IPv6 Prefix Management December 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Intended User and Administrator Experience . . . . . . . 4 3.2. Analysis of Parameters and Information Involved . . . . . 5 3.2.1. Parameters each device can define for itself . . . . 5 3.2.2. Information needed from network operations . . . . . 6 3.2.3. Comparison with current solutions . . . . . . . . . . 6 3.3. Interaction with other devices . . . . . . . . . . . . . 7 3.3.1. Information needed from other devices . . . . . . . . 7 3.3.2. Monitoring, diagnostics and reporting . . . . . . . . 7 4. Autonomic Edge Prefix Management Solution . . . . . . . . . . 8 4.1. Behaviors on prefix requesting device . . . . . . . . . . 8 4.2. Behaviors on prefix providing device . . . . . . . . . . 9 4.3. Behavior after Successful Negotiation . . . . . . . . . . 10 4.4. Prefix logging . . . . . . . . . . . . . . . . . . . . . 10 5. Autonomic Prefix Management Objectives . . . . . . . . . . . 10 5.1. Edge Prefix Objective Option . . . . . . . . . . . . . . 10 5.2. IPv4 extension . . . . . . . . . . . . . . . . . . . . . 11 6. Prefix Management Parameters . . . . . . . . . . . . . . . . 11 6.1. Example of Prefix Management Parameters . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Deployment Overview . . . . . . . . . . . . . . . . 17 A.1. Address & Prefix management with DHCP . . . . . . . . . . 17 A.2. Prefix management with ANI/GRASP . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction The original purpose of this document was to validate the design of the Autonomic Networking Infrastructure (ANI) for a realistic use case. It shows how the ANI can be applied to IP prefix delegation and it outlines approaches to build a system to do this. A fully standardized solution would require more details, so this document is informational in nature. Jiang, et al. Expires June 18, 2018 [Page 2] Internet-Draft Auto IPv6 Prefix Management December 2017 This document defines two autonomic technical objectives for IPv6 prefix management in large-scale networks, with an extension to support IPv4 prefixes. The background to Autonomic Networking (AN) is described in [RFC7575] and [RFC7576]. The GeneRic Autonomic Signaling Protocol (GRASP) is specified by [I-D.ietf-anima-grasp] and can make use of the proposed technical objectives to provide a solution for autonomic prefix management. An important purpose of the present document is to use it for validation of the design of GRASP and other components of the autonomic networking infrastructure described in [I-D.ietf-anima-reference-model]. This document is not a complete functional specification of an autonomic prefix management system and it does not describe all detailed aspects of the GRASP objective parameters and Autonomic Service Agent (ASA) procedures necessary to build a complete system. Instead, it describes the architectural framework utilizing the components of the ANI, outlines the different deployment options and aspects, and defines GRASP objectives for use in building the system. It also provides some basic parameter examples. This document is not intended to solve all cases of IPv6 prefix management. In fact, it assumes that the network's main infrastructure elements already have addresses and prefixes. The document is dedicated to how to make IPv6 prefix management at the edges of large-scale networks as autonomic as possible. It is specifically written for service provider (ISP) networks. Although there are similarities between ISPs and large enterprise networks, the requirements for the two use cases differ. In any case, the scope of the solution is expected to be limited, like any autonomic network, to a single management domain. However, the solution is designed in a general way. Its use for a broader scope than edge prefixes, including some or all infrastructure prefixes, is left for future discussion. A complete solution has many aspects that are not discussed here. Once prefixes have been assigned to routers, they need to be communicated to the routing system as they are brought into use. Similarly, when prefixes are released, they need to be removed from the routing system. Different operators may have different policies about prefix lifetimes, and they may prefer to have centralized or distributed pools of spare prefixes. In an autonomic network, these are properties decided by the design of the relevant ASAs. The GRASP objectives are simply building blocks. A particular risk of distributed prefix allocation in large networks is that over time, it might lead to fragmentation of the address space and an undesirable increase in the interior routing protocol Jiang, et al. Expires June 18, 2018 [Page 3] Internet-Draft Auto IPv6 Prefix Management December 2017 tables. The extent of this risk depends on the algorithms and policies used by the ASAs. Mitigating this risk might even become an autonomic function in itself. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology defined in [RFC7575]. 3. Problem Statement The autonomic networking use case considered here is autonomic IPv6 prefix management at the edge of large-scale ISP networks. Although DHCPv6 Prefix Delegation [RFC3633] supports automated delegation of IPv6 prefixes from one router to another, prefix management still largely depends on human planning. In other words, there is no basic information or policy to support autonomic decisions on the prefix length that each router should request or be delegated, according to its role in the network. Roles could be defined separately for individual devices or could be generic (edge router, interior router, etc.). Furthermore, IPv6 prefix management by humans tends to be rigid and static after initial planning. The problem to be solved by autonomic networking is how to dynamically manage IPv6 address space in large-scale networks, so that IPv6 addresses can be used efficiently. Here, we limit the problem to assignment of prefixes at the edge of the network, close to access routers that support individual fixed-line subscribers, mobile customers, and corporate customers. We assume that the core infrastructure of the network has already been established with appropriately assigned prefixes. The AN approach discussed in this document is based on the assumption that there is a generic discovery and negotiation protocol that enables direct negotiation between intelligent IP routers. GRASP [I-D.ietf-anima-grasp] is intended to be such a protocol. 3.1. Intended User and Administrator Experience The intended experience is, for the administrators of a large-scale network, that the management of IPv6 address space at the edge of the network can be run with minimum effort, as devices at the edge are added and removed and as customers of all kinds join and leave the Jiang, et al. Expires June 18, 2018 [Page 4] Internet-Draft Auto IPv6 Prefix Management December 2017 network. In the ideal scenario, the administrators only have to specify a single IPv6 prefix for the whole network and the initial prefix length for each device role. As far as users are concerned, IPv6 prefix assignment would occur exactly as it does in any other network. The actual prefix usage needs to be logged for potential offline management operations including audit and security incident tracing. 3.2. Analysis of Parameters and Information Involved For specific purposes of address management, a few parameters are involved on each edge device (some of them can be pre-configured before they are connected). They include: o Identity, authentication and authorization of this device. This is expected to use the autonomic networking secure bootstrap process [I-D.ietf-anima-bootstrapping-keyinfra], following which the device could safely take part in autonomic operations. o Role of this device. Some example roles are discussed in Section 6.1. o An IPv6 prefix length for this device. o An IPv6 prefix that is assigned to this device and its downstream devices. A few parameters are involved in the network as a whole. They are: o Identity of a trust anchor, which is a certification authority (CA) maintained by the network administrators, used during the secure bootstrap process. o Total IPv6 address space available for edge devices. It is a pool of one or several IPv6 prefixes. o The initial prefix length for each device role. 3.2.1. Parameters each device can define for itself This section identifies those of the above parameters that do not need external information in order for the devices concerned to set them to a reasonable default value after bootstrap or after a network disruption. There are few of these: o Default role of this device. Jiang, et al. Expires June 18, 2018 [Page 5] Internet-Draft Auto IPv6 Prefix Management December 2017 o Default IPv6 prefix length for this device. o Cryptographic identity of this device, as needed for secure bootstrapping [I-D.ietf-anima-bootstrapping-keyinfra]. The device may be shipped from the manufacturer with pre-configured role and default prefix length, which could be modified by an autonomic mechanism. Its cryptographic identity will be installed by its manufacturer. 3.2.2. Information needed from network operations This section identifies those parameters that might need operational input in order for the devices concerned to set them to a non-default value. o Non-default value for the IPv6 prefix length for this device. This needs to be decided based on the role of this device. o The initial prefix length for each device role. o Whether to allow the device to request more address space. o The policy when to request more address space, for example, if the address usage reaches a certain limit or percentage. 3.2.3. Comparison with current solutions This section briefly compares the above use case with current solutions. Currently, the address management is still largely dependent on human planning. It is rigid and static after initial planning. Address requests will fail if the configured address space is used up. Some autonomic and dynamic address management functions may be achievable by extending the existing protocols, for example, extending DHCPv6-PD (DHCPv6 Prefix Delegation, [RFC3633]) to request IPv6 prefixes according to the device role. However, defining uniform device roles may not be a practical task. Some functions are not suitable to be achieved by any existing protocols. Using a generic autonomic discovery and negotiation protocol instead of specific solutions has the advantage that additional parameters can be included in the autonomic solution without creating new mechanisms. This is the principal argument for a generic approach. Jiang, et al. Expires June 18, 2018 [Page 6] Internet-Draft Auto IPv6 Prefix Management December 2017 3.3. Interaction with other devices 3.3.1. Information needed from other devices This section identifies those of the above parameters that need external information from neighbor devices (including the upstream devices). In many cases, two-way dialogue with neighbor devices is needed to set or optimize them. o Identity of a trust anchor. o The device will need to discover a device, from which it can acquire IPv6 address space. o The initial prefix length for each device role, particularly for its own downstream devices. o The default value of the IPv6 prefix length may be overridden by a non-default value. o The device will need to request and acquire one or more IPv6 prefixes that can be assigned to this device and its downstream devices. o The device may respond to prefix delegation requests from its downstream devices. o The device may require to be assigned more IPv6 address space, if it used up its assigned IPv6 address space. 3.3.2. Monitoring, diagnostics and reporting This section discusses what role devices should play in monitoring, fault diagnosis, and reporting. o The actual address assignments need to be logged for potential offline management operations. o In general, the usage situation of address space should be reported to the network administrators, in an abstract way, for example, statistics or visualized report. o A forecast of address exhaustion should be reported. Jiang, et al. Expires June 18, 2018 [Page 7] Internet-Draft Auto IPv6 Prefix Management December 2017 4. Autonomic Edge Prefix Management Solution This section introduces the building blocks for an autonomic edge prefix management solution. As noted in Section 1, this is not a complete description of a solution, which will depend on the detailed design of the relevant Autonomic Service Agents. It uses the generic discovery and negotiation protocol defined by [I-D.ietf-anima-grasp]. The relevant GRASP objectives are defined in Section 5. The procedures described below are carried out by an Autonomic Service Agent (ASA) in each device that participates in the solution. We will refer to this as the PrefixManager ASA. 4.1. Behaviors on prefix requesting device If the device containing a PrefixManager ASA has used up its address pool, it can request more space according to its requirements. It should decide the length of the requested prefix and request it by the mechanism described in Section 6. Note that although the device's role may define certain default allocation lengths, those defaults might be changed dynamically, and the device might request more, or less, address space due to some local operational heuristic. A PrefixManager ASA that needs additional address space should firstly discover peers that may be able to provide extra address space. The ASA should send out a GRASP Discovery message that contains a PrefixManager Objective option (see Section 5.1) in order to discover peers also supporting that option. Then it should choose one such peer, most likely the first to respond. If the GRASP discovery Response message carries a divert option pointing to an off-link PrefixManager ASA, the requesting ASA may initiate negotiation with that ASA diverted device to find out whether it can provide the requested length prefix. In any case, the requesting ASA will act as a GRASP negotiation initiator by sending a GRASP Request message with a PrefixManager Objective option. The ASA indicates in this option the length of the requested prefix. This starts a GRASP negotiation process. During the subsequent negotiation, the ASA will decide at each step whether to accept the offered prefix. That decision, and the decision to end negotiation, is an implementation choice. The ASA could alternatively initiate rapid mode GRASP discovery with an embedded negotiation request, if it is implemented. Jiang, et al. Expires June 18, 2018 [Page 8] Internet-Draft Auto IPv6 Prefix Management December 2017 4.2. Behaviors on prefix providing device At least one device on the network must be configured with the initial pool of available prefixes mentioned in Section 3.2. Apart from that requirement, any device may act as a prefix providing device. A device that receives a Discovery message with a PrefixManager Objective option should respond with a GRASP Response message if it contains a PrefixManager ASA. Further details of the discovery process are described in [I-D.ietf-anima-grasp]. When this ASA receives a subsequent Request message, it should conduct a GRASP negotiation sequence, using Negotiate, Confirm-waiting, and Negotiation-ending messages as appropriate. The Negotiate messages carry a PrefixManager Objective option, which will indicate the prefix and its length offered to the requesting ASA. As described in [I-D.ietf-anima-grasp], negotiation will continue until either end stops it with a Negotiation-ending message. If the negotiation succeeds, the prefix providing ASA will remove the negotiated prefix from its pool, and the requesting ASA will add it. If the negotiation fails, the party sending the Negotiation-ending message may include an error code string. During the negotiation, the ASA will decide at each step how large a prefix to offer. That decision, and the decision to end negotiation, is an implementation choice. The ASA could alternatively negotiate in response to rapid mode GRASP discovery, if it is implemented. This specification is independent of whether the PrefixManager ASAs are all embedded in routers, but that would be a rather natural scenario. In a hierarchical network topology, a given router typically provide prefixes for routers below it in the hierarchy, and it is also likely to contain the first PrefixManager ASA discovered by those downstream routers. However, the GRASP discovery model, including its Redirect feature, means that this is not an exclusive scenario, and a downstream PrefixManager ASA could negotiate a new prefix with a device other than its upstream router. A resource shortage may cause the gateway router to request more resource in turn from its own upstream device. This would be another independent GRASP discovery and negotiation process. During the processing time, the gateway router should send a Confirm-waiting Message to the initial requesting router, to extend its timeout. When the new resource becomes available, the gateway router responds with a GRASP Negotiate message with a prefix length matching the request. Jiang, et al. Expires June 18, 2018 [Page 9] Internet-Draft Auto IPv6 Prefix Management December 2017 The algorithm to choose which prefixes to assign on the prefix providing devices is an implementation choice. 4.3. Behavior after Successful Negotiation Upon receiving a GRASP Negotiation-ending message that indicates that an acceptable prefix length is available, the requesting device may use the negotiated prefix without further messages. There are use cases where the ANI/GRASP based prefix management approach can work together with DHCPv6-PD [RFC3633] as a complement. For example, the ANI/GRASP based method can be used intra-domain, while the DHCPv6-PD method works inter-domain (i.e., across an administrative boundary). Also, ANI/GRASP can be used inside the domain, and DHCP/DHCPv6-PD be used on the edge of the domain to client (non-ANI devices). Another similar use case would be ANI/ GRASP inside the domain, with RADIUS [RFC2865] providing prefixes to client devices. 4.4. Prefix logging Within the autonomic prefix management, all the prefix assignment is done by devices without human intervention. It may be required to record all the prefix assignment history, for example to detect or trace lost prefixes after outages, or to meet legal requirements. However, the logging and reporting process is out of scope for this document. 5. Autonomic Prefix Management Objectives This section defines the GRASP technical objective options that are used to support autonomic prefix management. 5.1. Edge Prefix Objective Option The PrefixManager Objective option is a GRASP objective option conforming to [I-D.ietf-anima-grasp]. Its name is "PrefixManager" (see Section 8) and it carries the following data items as its value: the prefix length, and the actual prefix bits. Since GRASP is based on CBOR (Concise Binary Object Representation [RFC7049]), the format of the PrefixManager Objective option is described as follows in CBOR data definition language (CDDL) [I-D.ietf-cbor-cddl]: Jiang, et al. Expires June 18, 2018 [Page 10] Internet-Draft Auto IPv6 Prefix Management December 2017 objective = ["PrefixManager", objective-flags, loop-count, [length, ?prefix]] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification length = 0..128 ; requested or offered prefix length prefix = bytes .size 16 ; offered prefix in binary format The use of the 'dry run' mode of GRASP is NOT RECOMMENDED for this objective, because it would require both ASAs to store state about the corresponding negotiation, to no real benefit - the requesting ASA cannot base any decisions on the result of a successful dry run negotiation. 5.2. IPv4 extension This section presents an extended version of the PrefixManager Objective that supports IPv4 by adding an extra flag: objective = ["PrefixManager", objective-flags, loop-count, prefval] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification prefval /= pref6val pref6val = [version6, length, ?prefix] version6 = 6 length = 0..128 ; requested or offered prefix length prefix = bytes .size 16 ; offered prefix in binary format prefval /= pref4val pref4val = [version4, length4, ?prefix4] version4 = 4 length4 = 0..32 ; requested or offered prefix length prefix4 = bytes .size 4 ; offered prefix in binary format Prefix and address management for IPv4 is considerably more difficult than for IPv6, due to the prevalence of NAT, ambiguous addresses [RFC1918], and address sharing [RFC6346]. These complexities might require further extending the objective with additional fields which are not defined by this document. 6. Prefix Management Parameters An implementation of a prefix manager MUST include default settings of all necessary parameters. However, within a single administrative domain, the network operator MAY change default parameters for all devices with a certain role. Thus it would be possible to apply an Jiang, et al. Expires June 18, 2018 [Page 11] Internet-Draft Auto IPv6 Prefix Management December 2017 intended policy for every device in a simple way, without traditional configuration files. As noted in Section 4.1, individual autonomic devices may also change their own behavior dynamically. For example, the network operator could change the default prefix length for each type of role. A prefix management parameters objective, which contains mapping information of device roles and their default prefix lengths, MAY be flooded in the network, through the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The objective is defined in CDDL as follows: objective = ["PrefixManager.Params", objective-flags, any] loop-count = 0..255 ; as in the GRASP specification objective-flags /= ; as in the GRASP specification The 'any' object would be the relevant parameter definitions (such as the example below) transmitted as a CBOR object in an appropriate format. This could be flooded to all nodes, and any PrefixManager ASA that did not receive it for some reason could obtain a copy using GRASP unicast synchronization. Upon receiving the prefix management parameters, every device can decide its default prefix length by matching its own role. 6.1. Example of Prefix Management Parameters The parameters comprise mapping information of device roles and their default prefix lengths in an autonomic domain. For example, suppose an IPRAN (IP Radio Access Network) operator wants to configure the prefix length of Radio Network Controller Site Gateway (RSG) as 34, the prefix length of Aggregation Site Gateway (ASG) as 44, and the prefix length of Cell Site Gateway (CSG) as 56. This could be described in the value of the PrefixManager.Params objective as: [ [["role", "RSG"],["prefix_length", 34]], [["role", "ASG"],["prefix_length", 44]], [["role", "CSG"],["prefix_length", 56]] ] This example is expressed in JSON notation [RFC7159], which is easy to represent in CBOR. Jiang, et al. Expires June 18, 2018 [Page 12] Internet-Draft Auto IPv6 Prefix Management December 2017 An alternative would be to express the parameters in YANG [RFC7950] using the YANG-to-CBOR mapping [I-D.ietf-core-yang-cbor]. For clarity, the background of the example is introduced below, which can also be regarded as a use case of the mechanism proposed in this document. An IPRAN network is used for mobile backhaul, including radio stations, RNC (in 3G) or the packet core (in LTE), and the IP network between them as shown in Figure 1. The eNB (Evolved Node B), RNC (Radio Network Controller), SGW (Service Gateway), and MME (Mobility Management Entity) are mobile network entities defined in 3GPP. The CSG, ASG, and RSG are entities defined in the IPRAN solution. The IPRAN topology shown in Figure 1 includes Ring1 which is the circle following ASG1->RSG1->RSG2->ASG2->ASG1, Ring2 following CSG1->ASG1->ASG2->CSG2->CSG1, and Ring3 following CSG3->ASG1->ASG2->CSG3. In a real deployment of IPRAN, there may be more stations, rings, and routers in the topology, and normally the network is highly dependent on human design and configuration, which is neither flexible nor cost-effective. +------+ +------+ | eNB1 |---| CSG1 |\ +------+ +------+ \ +-------+ +------+ +-------+ | \ | ASG1 |-------| RSG1 |-----------|SGW/MME| | Ring2 +-------+ +------+ \ /+-------+ +------+ +------+ / | | \ / | eNB2 |---| CSG2 | \ / | Ring1 | \/ +------+ +------+ \ Ring3| | /\ / \ | | / \ +------+ +------+ / \ +-------+ +------+/ \+-------+ | eNB3 |---| CSG3 |--------| ASG2 |------| RSG2 |---------| RNC | +------+ +------+ +-------+ +------+ +-------+ Figure 1: IPRAN Topology Example If ANI/GRASP is supported in the IPRAN network, the network nodes should be able to negotiate with each other, and make some autonomic decisions according to their own status and the information collected from the network. The Prefix Management Parameters should be part of the information they communicate. The routers should know the role of their neighbors, the default prefix length for each type of role, etc. An ASG should be able to request prefixes from an RSG, and an CSG should be able to request prefixes from an ASG. In each request, the ASG/CSG should indicate Jiang, et al. Expires June 18, 2018 [Page 13] Internet-Draft Auto IPv6 Prefix Management December 2017 the required prefix length, or its role, which implies what length it needs by default. 7. Security Considerations Relevant security issues are discussed in [I-D.ietf-anima-grasp]. The preferred security model is that devices are trusted following the secure bootstrap procedure [I-D.ietf-anima-bootstrapping-keyinfra] and that a secure Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane] is in place. It is RECOMMENDED that DHCPv6-PD, if used, should be operated using DHCPv6 authentication or Secure DHCPv6. 8. IANA Considerations This document defines two new GRASP Objective Option names, "PrefixManager" and "PrefixManager.Params". The IANA is requested to add these to the GRASP Objective Names Table registry defined by [I-D.ietf-anima-grasp] (if approved). 9. Acknowledgements Valuable comments were received from William Atwood, Fred Baker, Michael Behringer, Ben Campbell, Laurent Ciavaglia, Toerless Eckert, Joel Halpern, Russ Housley, Geoff Huston, Warren Kumari, Dan Romascanu, and Chongfeng Xie. 10. Change log [RFC Editor: Please remove] draft-jiang-anima-prefix-management-00: original version, 2014-10-25. draft-jiang-anima-prefix-management-01: add intent example and coauthor Zongpeng Du, 2015-05-04. draft-jiang-anima-prefix-management-02: update references and the format of the prefix management intent, 2015-10-14. draft-ietf-anima-prefix-management-00: WG adoption, clarify scope and purpose, update text to match latest GRASP spec, 2016-01-11. draft-ietf-anima-prefix-management-01: minor update, 2016-07-08. draft-ietf-anima-prefix-management-02: replaced intent discussion by parameter setting, 2017-01-10. Jiang, et al. Expires June 18, 2018 [Page 14] Internet-Draft Auto IPv6 Prefix Management December 2017 draft-ietf-anima-prefix-management-03: corrected object format, improved parameter setting example, 2017-03-10. draft-ietf-anima-prefix-management-04: add more explanations about the solution, add IPv4 options, removed PD flag, 2017-06-23. draft-ietf-anima-prefix-management-05: selected one IPv4 option, updated references, 2017-08-14. draft-ietf-anima-prefix-management-06: handled IETF Last Call comments, 2017-10-18. draft-ietf-anima-prefix-management-07: handled IESG comments, 2017-12-18. 11. References 11.1. Normative References [I-D.ietf-anima-autonomic-control-plane] Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control- plane-12 (work in progress), October 2017. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-09 (work in progress), October 2017. [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), July 2017. [I-D.ietf-cbor-cddl] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR data structures", draft-ietf-cbor-cddl-00 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Jiang, et al. Expires June 18, 2018 [Page 15] Internet-Draft Auto IPv6 Prefix Management December 2017 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.ietf-anima-reference-model] Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Reference Model for Autonomic Networking", draft-ietf- anima-reference-model-05 (work in progress), October 2017. [I-D.ietf-core-yang-cbor] Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Minaburo, "CBOR Encoding of Data Modeled with YANG", draft-ietf-core-yang-cbor-05 (work in progress), August 2017. [I-D.liu-dhc-dhcp-yang-model] Liu, B., Lou, K., and C. Chen, "Yang Data Model for DHCP Protocol", draft-liu-dhc-dhcp-yang-model-06 (work in progress), March 2017. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . Jiang, et al. Expires June 18, 2018 [Page 16] Internet-Draft Auto IPv6 Prefix Management December 2017 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, . [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, . [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . Appendix A. Deployment Overview This Appendix includes logical deployment models, and explanations of the target deployment models. The purpose is to help in understanding the mechanism of the document. This Appendix includes two sub-sections: A.1 for the two most common DHCP deployment models, and A.2 for the proposed PD deployment model. It should be noted that these are just examples, and there are many more deployment models. A.1. Address & Prefix management with DHCP Edge DHCP server deployment requires every edge router connecting to CPE to be a DHCP server assigning IPv4/IPv6 addresses to CPE - and optionally IPv6 prefixes via DHCPv6-PD for IPv6 capable CPE that are router and have LANs behind them. Jiang, et al. Expires June 18, 2018 [Page 17] Internet-Draft Auto IPv6 Prefix Management December 2017 edge dynamic, "netconf/YANG" interfaces <---------------> +-------------+ +------+ <- telemetry | edge router/|-+ ----- +-----+ |config| .... Domain ... | DHCP server | | ... | CPE |+ LANs |server| +-------------+ | ----- +-----+| (---| ) +------+ +--------------+ DHCP/ +-----+ DHCPv6 / PD Figure 2: DHCP Deployment Model without a Central DHCP Server This requires various coordination functions via some backend system depicted as "config server": The address prefixes on the edge interfaces should be slightly larger than required for the number of CPEs connected so that the overall address space is best used. The config server needs to provision edge interface address prefixes and DHCP parameters for every edge router. If too fine grained prefixes are used, this will result in large routing tables across the "Domain". If too coarse grained prefixes are used, address space is wasted. (This is less of a concern for IPv6, but if the model includes IPv4, it is a very serious concern.) There is no standard describing algorithms for how configuration servers would best perform this ongoing dynamic provisioning to optimize routing table size and address space utilization. There are currently no complete YANG models that a config server could use to perform these actions (including telemetry of assigned addresses from such distributed DHCP servers). For example, a YANG model for controlling DHCP server operations is still in draft [I-D.liu-dhc-dhcp-yang-model]. Due to these and other problems of the above model, the more common DHCP deployment model is as follows: +------+ edge |config| initial, "CLI" interfaces |server| ----------------> +-------------+ +------+ | edge router/|-+ ----- +-----+ | .... Domain ... | DHCP relay | | ... | CPE |+ LANs +------+ +-------------+ | ----- +-----+| (---| ) |DHCP | +--------------+ DHCP/ +-----+ |server| DHCPv6 / PD +------+ Figure 3: DHCP Deployment Model with a Central DHCP Server Jiang, et al. Expires June 18, 2018 [Page 18] Internet-Draft Auto IPv6 Prefix Management December 2017 Dynamic provisioning changes to edge routers are avoided by using a central DHCP server and reducing the edge router from DHCP server to DHCP relay. The "configuration" on the edge routers is static, the DHCP relay function inserts "edge interface" and/or subscriber identifying options into DHCP requests from CPE (e.g., [RFC3046], [RFC6221]), the DHCP server has complete policies for address assignments and prefixes useable on every edge-router/interface/ subscriber-group. When the DHCP relay sees the DHCP reply, it inserts static routes for the assigned address/address-prefix into the routing table of the edge router which are then to be distributed by the IGP (or BGP) inside the domain to make the CPE and LANs reachable across the Domain. There is no comprehensive standardization of these solutions. [RFC3633] section 14, for example, simply refers to "a [non-defined] protocol or other out-of-band communication to add routing information for delegated prefixes into the provider edge router". A.2. Prefix management with ANI/GRASP With the proposed use of ANI and Prefix-management ASAs using GRASP, the deployment model is intended to look as follows: |<............ ANI Domain / ACP............>| (...) ........-> Roles | v "Edge routers" GRASP parameter +----------+ Network wide | PM-ASA | downstream parameters/policies | (DHCP- | interfaces | |functions)| ------ v "central device" +----------+ +------+ ^ +--------+ |PM-ASA| <............GRASP .... .... | CPE |-+ (LANs) +------+ . v |(PM-ASA)| | ---| . +........+ +----------+ +--------+ | +...........+ . PM-ASA . | PM-ASA | ------ +---------+ .DHCP server. +........+ | (DHCP- | SLAAC/ +...........+ "intermediate |functions)| DHCP/DHCP-PD router" +----------+ Figure 4: Proposed Deployment Model using ANI/GRASP The network runs an ANI domain with ACP [I-D.ietf-anima-autonomic-control-plane] between some central device (e.g., router or ANI enabled management device) and the edge routers. ANI/ACP provides a secure, zero-touch communication channel between Jiang, et al. Expires June 18, 2018 [Page 19] Internet-Draft Auto IPv6 Prefix Management December 2017 the devices and enables the use of GRASP[I-D.ietf-anima-grasp] not only for p2p communication, but also for distribution/flooding. The central devices and edge routers run software in the form of "Autonomic Service Agents" (ASA) to support this document's autonomic IPv6 edge prefix management (PM). The ASAs for prefix management are called PM-ASAs below, and together comprise the Autonomic Prefix Management Function. Edge routers can have different roles based on the type and number of CPE attaching to them. Each edge router could be an RSG, ASG, or CSG in mobile aggregation networks (see Section 6.1). Mechanisms outside the scope of this document make routers aware of their roles. Some considerations about the proposed deployment model are listed as follows. 1. In a minimum Prefix Management solution, the central device uses the "PrefixManager.Params" GRASP Objective introduced in this document to disseminate network wide, per-role parameters to edge routers. The PM-ASA uses the parameters applying to its role to locally configure pre-existing addressing functions. Because PM-ASA does not manage the dynamic assignment of actual IPv6 address prefixes in this case, the following options can be considered: 1.a The edge router connects via downstream interfaces to (host) CPE that each requires an address. The PM-ASA sets up for each such interface a DHCP requesting router (according to [RFC3633]) to request an IPv6 prefix for the interface. The router's address on the downstream interface can be another parameter from the GRASP Objective. The CPEs assign addresses in the prefix via RAs from the router or the PM-ASA manages a local DHCPv6 server to assign addresses to the CPEs. A central DHCP server acting as the DHCP delegating router (according to [RFC3633]) is required. Its address can be another parameter from the GRASP Objective. 1.b The edge router also connects via downstream interfaces to (customer managed) CPEs that are routers and act as DHCPv6 requesting routers. The need to support this could be derived from role and/or GRASP parameters and the PM-ASA sets up a DHCP relay function to pass on requests to the central DHCP server as in 1.a. 2. In a solution without a central DHCP server, the PM-ASA on the edge routers not only learn parameters from "PrefixManager.Params" but also utilize GRASP to request/negotiate actual IPv6 prefix delegation via the GRASP "PrefixManager" objective described in more detail below. In the most simple case, these prefixes are delegated via this GRASP objective from the PM-ASA in the central device. This Jiang, et al. Expires June 18, 2018 [Page 20] Internet-Draft Auto IPv6 Prefix Management December 2017 device must be provisioned initially with a large pool of prefixes. The delegated prefixes are then used by the PM-ASA on the edge routers to edge routers to configure prefixes on their downstream interfaces to assign addresses via RA/SLAAC to host CPEs. The PM-ASA may also start local DHCP servers (as in 1.a) to assign addresses via DHCP to CPE from the prefixes it received. This includes both host CPEs requesting IPv6 addresses as well as router CPEs that request IPv6 prefixes. The PM-ASA needs to manage the address pool(s) it has requested via GRASP and allocate sub-address pools to interfaces and the local DHCP servers it starts. It needs to monitor the address utilization and accordingly request more address prefixes if its existing prefixes are exhausted, or return address prefixes when they are unneeded. This solution is quite similar to the initial described IPv6 DHCP deployment model without central DHCP server, and ANI/ACP/GRASP and the PM-ASA do provide the automation to make this approach work more easily than it is possible today. 3. The address pool(s) from which prefixes are allocated does not need to be taken all from one central location. Edge router PM-ASA that received a big (short) prefix from a central PM-ASA could offer smaller sub-prefixes to neighboring edge-router PM-ASA. GRASP could be used in such a way that the PM-ASA would find and select the objective from the closest neighboring PM-ASA, therefore allowing to maximize aggregation: A PM-ASA would only request further (smaller/ shorter) prefixes when it exhausts its own poll (from the central location) and can not get further large prefixes from that central location anymore. Because the overflow prefixes taken from a topological nearby PM-ASA, the number of longer prefixes that have to be injected into the routing tables is limited and the topological proximity increases the chances that aggregation of prefixes in the IGP can most likely limit the geography in which the longer prefixes need to be routed. 4. Instead of peer-to-peer optimization of prefix delegation, a hierarchy of PM-ASA can be built (indicated in the picture via a dotted intermediate router). This would require additional parameters to the "PrefixManager" objective to allow creating a hierarchy of PM-ASA across which the prefixes can be delegated. This is not detailed further below. 5. In cases where CPEs are also part of the ANI Domain (e.g., "Managed CPE"), then GRASP will extend into the actual customer sites and can equally run a PM-ASA. All the options described in points 1 to 4 above would then apply to the CPE as the edge router with the mayor changes being that a) a CPE router will most likley not need to run DHCPv6-PD itself, but only DHCP address assignment, b) The edge Jiang, et al. Expires June 18, 2018 [Page 21] Internet-Draft Auto IPv6 Prefix Management December 2017 routers to which the CPE connect would most likely become ideal places to run a hierarchical instance of PD-ASAs on as outlined in point 1. Authors' Addresses Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: jiangsheng@huawei.com Zongpeng Du Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China Email: duzongpeng@huawei.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Qiong Sun China Telecom No.118, Xizhimennei Street Beijing 100035 P. R. China Email: sunqiong@ctbri.com.cn Jiang, et al. Expires June 18, 2018 [Page 22] ./draft-ietf-dhc-slap-quadrant-12.txt0000644000764400076440000012753513741300556016704 0ustar iustyiusty DHC WG CJ. Bernardos Internet-Draft UC3M Intended status: Standards Track A. Mourad Expires: April 16, 2021 InterDigital October 13, 2020 SLAP quadrant selection option for DHCPv6 draft-ietf-dhc-slap-quadrant-12 Abstract IEEE originally structured the 48-bit MAC address space in such a way that half of it was reserved for local use. In 2017, IEEE published a new standard (IEEE Std 802c) with a new optional "Structured Local Address Plan" (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space. IEEE is developing protocols to assign addresses (IEEE P802.1CQ). There is work also in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments. This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option (QUAD) is defined for this purpose. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 16, 2021. Bernardos & Mourad Expires April 16, 2021 [Page 1] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.1.1. WiFi (IEEE 802.11) devices . . . . . . . . . . . . . 4 1.1.2. Hypervisor: migratable vs non-migratable functions . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. DHCPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Address Assignment from the Preferred SLAP Quadrant Indicated by the Client . . . . . . . . . . . . . . . . . 7 3.2. Address Assignment from the SLAP Quadrant Indicated by the Relay . . . . . . . . . . . . . . . . . . . . . . . . 9 4. DHCPv6 Option Definition . . . . . . . . . . . . . . . . . . 11 4.1. Quad option . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Quadrant Selection Mechanisms examples . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction IEEE structures the 48-bit MAC address space in such a way that half of it was reserved for local use (where the Universal/Local -- U/L -- bit is set to 1). In 2017, IEEE published a new standard (IEEE Std 802c [IEEEStd802c]) which defines a new optional "Structured Local Address Plan" (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space. These four regions, called SLAP quadrants, are briefly described below (see Figure 1 and Figure 2 for details): Bernardos & Mourad Expires April 16, 2021 [Page 2] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 o In SLAP Quadrant 01, "Extended Local Identifier" (ELI) MAC addresses are assigned based on a 24-bit Company ID (CID), assigned by the IEEE Registration Authority (RA). The remaining bits are specified as an extension by the CID assignee or by a protocol designated by the CID assignee. o In SLAP Quadrant 11, "Standard Assigned Identifier" (SAI) MAC addresses are assigned based on a protocol specified in an IEEE 802 standard. For 48-bit MAC addresses, 44 bits are available. Multiple protocols for assigning SAIs may be specified in IEEE standards. Coexistence of multiple protocols may be supported by limiting the subspace available for assignment by each protocol. o In SLAP Quadrant 00, "Administratively Assigned Identifier" (AAI) MAC addresses are assigned locally by an administrator. Multicast IPv6 packets use a destination address starting in 33-33, so AAI addresses in that range should not be assigned. For 48-bit MAC addresses, 44 bits are available. o SLAP Quadrant 10 is "Reserved for future use" where MAC addresses may be assigned using new methods yet to be defined, or until then by an administrator as in the AAI quadrant. For 48-bit MAC addresses, 44 bits would be available. LSB MSB M X Y Z - - - - | | | | | | | +------------ SLAP Z-bit | | +--------------- SLAP Y-bit | +------------------ X-bit (U/L) = 1 for locally assigned +--------------------- M-bit (I/G) (unicast/group) Figure 1: IEEE 48-bit MAC address structure (in IEEE representation) +----------+-------+-------+-----------------------+----------------+ | Quadrant | Y-bit | Z-bit | Local Identifier Type | Local | | | | | | Identifier | +----------+-------+-------+-----------------------+----------------+ | 01 | 0 | 1 | Extended Local | ELI | | 11 | 1 | 1 | Standard Assigned | SAI | | 00 | 0 | 0 | Administratively | AAI | | | | | Assigned | | | 10 | 1 | 0 | Reserved | Reserved | +----------+-------+-------+-----------------------+----------------+ Figure 2: SLAP quadrants Bernardos & Mourad Expires April 16, 2021 [Page 3] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 1.1. Problem statement IEEE is developing mechanisms to assign addresses (IEEE P802.1CQ project) [IEEE-P802.1CQ-Project]. There is also ongoing work in the IETF [I-D.ietf-dhc-mac-assign] specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments. This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server may allocate the MAC addresses in the quadrant requested by the relay or client. In the following, we describe two application scenarios in which a need arises to assign local MAC addresses according to preferred SLAP quadrants. 1.1.1. WiFi (IEEE 802.11) devices Today, most WiFi devices come with interfaces that have a "burned in" MAC address, allocated from the universal address space using a 24-bit Organizationally Unique Identifier (OUI, assigned to IEEE 802 interface vendors). However, recently, the need to assign local (instead of universal) MAC addresses has emerged in particular in the following two scenarios: o IoT (Internet of Things): In general, composed of constrained devices [RFC7228] with constraints such as available power and energy, memory, and processing resources. Examples of this include sensors and actuators for health or home automation applications. Given the increasingly high number of these devices, manufacturers might prefer to equip devices with temporary MAC addresses used only at first boot. These temporary MAC addresses would just be used to send initial DHCP packets to available DHCP servers. IoT devices typically need a single MAC address for each available network interface. Once the server assigns a MAC address, the device would abandon its temporary MAC address. Home automation IoT devices typically do not move (however, note that there is an increase of smart health monitoring devices, which are mobile). For this type of device, in general, any type of SLAP quadrant would be good for assigning addresses, but ELI/SAI quadrants might be more suitable in some scenarios. For example, the device might need to use an address from the CID assigned to the IoT communication device vendor, thus preferring the ELI quadrant. o Privacy: Today, MAC addresses allow the exposure of users' locations making it relatively easy to track users' movements. One of the mechanisms considered to mitigate this problem is the use of local random MAC addresses, changing them every time the Bernardos & Mourad Expires April 16, 2021 [Page 4] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 user connects to a different network. In this scenario, devices are typically mobile. Here, AAI is probably the best SLAP quadrant from which to assign addresses, as it is the best fit for randomization of addresses, and it is not required for the addresses to survive when changing networks. 1.1.2. Hypervisor: migratable vs non-migratable functions In large scale virtualization environments, thousands of virtual machines (VMs) are active. These VMs are typically managed by a hypervisor, in charge of spawning and stopping VMs as needed. The hypervisor is also typically in charge of assigning new MAC addresses to the VMs. If a DHCP solution is in place for that, the hypervisor acts as a DHCP client and requests available DHCP servers to assign one or more MAC addresses (an address block). The hypervisor does not use those addresses for itself, but rather uses them to create new VMs with appropriate MAC addresses. If we assume very large data center environments, such as the ones that are typically used nowadays, it is expected that the data center is divided in different network regions, each one managing its own local address space. In this scenario, there are two possible situations that need to be tackled: o Migratable functions. If a VM (providing a given function) needs to be migrated to another region of the data center (e.g., for maintenance, resilience, end-user mobility, etc.), the VM's networking context needs to migrate with the VM. This includes the VM's MAC address(es). Since the assignments from the ELI/SAP SLAP quadrants are governed by rules per IEEE Std 802c, they are more appropriate for use to ensure MAC address uniqueness globally in the datacenter. o Non-migratable functions. If a VM will not be migrated to another region of the data center, there are no requirements associated with its MAC address. In this case, it is simpler to allocate it from the AAI SLAP quadrant, that does not need to be unique across multiple data centers (i.e., each region can manage its own MAC address assignment, without checking for duplicates globally). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Bernardos & Mourad Expires April 16, 2021 [Page 5] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 Where relevant, the DHCPv6 terminology from the DHCPv6 Protocol [RFC8415] also applies here. Additionally, the following definitions are updated for this document. IA_LL Identity Association for Link-Layer Address: an identity association (IA) used to request or assign link-layer addresses. Section 10.1 of [I-D.ietf-dhc-mac-assign] provides details on the IA_LL option. LLADDR Link-layer address option that is used to request or assign a block of link-layer addresses. Section 10.2 of [I-D.ietf-dhc-mac-assign] provides details on the LLADDR option. client A node that is interested in obtaining link-layer addresses. It implements the basic DHCP mechanisms needed by a DHCP client as described in [RFC8415] and supports the options (IA_LL and LLADDR) specified in [I-D.ietf-dhc-mac-assign], as well as the new option (QUAD) specified in this document. The client may or may not support IPv6 address assignment and prefix delegation as specified in [RFC8415]. server A node that manages link-layer address allocation and is able to respond to client queries. It implements basic DHCP server functionality as described in [RFC8415] and supports the options (IA_LL and LLADDR) specified in [I-D.ietf-dhc-mac-assign], as well as the new option (QUAD) specified in this document. The server may or may not support IPv6 address assignment and prefix delegation as specified in [RFC8415]. relay A node that acts as an intermediary to deliver DHCP messages between clients and servers. A relay, based on local knowledge and policies, may include the preferred SLAP quadrant in a QUAD option sent to the server. The relay implements basic DHCPv6 relay agent functionality as described in [RFC8415]. address Unless specified otherwise, an address means a link- layer (or MAC) address, as specified in IEEE Std 802 [IEEEStd802]. The address is six or eight bytes long. address block A number of consecutive link-layer addresses. An address block is expressed as a first address plus a number that designates the number of additional (extra) Bernardos & Mourad Expires April 16, 2021 [Page 6] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 addresses. A single address can be represented by the address itself and zero extra addresses. 3. DHCPv6 Extensions 3.1. Address Assignment from the Preferred SLAP Quadrant Indicated by the Client Next, we describe the protocol operations for a client to select a preferred SLAP quadrant using the DHCPv6 signaling procedures described in [I-D.ietf-dhc-mac-assign]. The signaling flow is shown in Figure 3. +--------+ +--------+ | DHCPv6 | | DHCPv6 | | client | | server | +--------+ +--------+ | | +----1. Solicit(IA_LL(LLADDR,QUAD))--->| | | |<--2. Advertise(IA_LL(LLADDR,QUAD))---+ | | +---3. Request(IA_LL(LLADDR,QUAD))---->| | | |<------4. Reply(IA_LL(LLADDR))--------+ | | . . . (timer expiring) . . . | | +---5. Renew(IA_LL(LLADDR,QUAD))------>| | | |<-----6. Reply(IA_LL(LLADDR))---------+ | | Figure 3: DHCPv6 signaling flow (client-server) 1. Link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallest block is a single address. To request an assignment, the client sends a Solicit message with an IA_LL option in the message. The IA_LL option MUST contain a LLADDR option. In order to indicate the preferred SLAP quadrant(s), the IA_LL option includes the new OPTION_SLAP_QUAD option in the IA_LL-option field (alongside the LLADDR option). 2. The server, upon receiving an IA_LL option in Solicit, inspects its contents. For each of the entries in OPTION_SLAP_QUAD, in order of the preference field (highest to lowest), the server Bernardos & Mourad Expires April 16, 2021 [Page 7] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 checks if it has a configured MAC address pool matching the requested quadrant identifier, and an available range of addresses of the requested size. If suitable addresses are found, the server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. If the server manages a block of addresses belonging to a requested quadrant, the addresses being offered MUST belong to a requested quadrant. If the server does not have a configured address pool matching the client's request, it SHOULD return the IA_LL option with the addresses being offered belonging to a quadrant managed by the server (following a local policy to select from which of the available quadrants). If the server has a configured address pool of the correct quadrant, but no available addresses, it MUST return the IA_LL option containing a Status Code option with status set to NoAddrsAvail. 3. The client waits for available servers to send Advertise responses and picks one server as defined in Section 18.2.9 of [RFC8415]. The client SHOULD NOT pick a server that does not advertise an address in the requested quadrant(s). The client then sends a Request message that includes the IA_LL container option with the LLADDR option copied from the Advertise message sent by the chosen server. It includes the preferred SLAP quadrant(s) in a new QUAD IA_LL-option. 4. Upon reception of a Request message with IA_LL container option, the server assigns requested addresses. The server MAY alter the allocation at this time (e.g., by reducing the address block). It then generates and sends a Reply message back to the client. Upon receiving a Reply message, the client parses the IA_LL container option and may start using all provided addresses. Note that a client that has included a Rapid Commit option in the Solicit, may receive a Reply in response to the Solicit and skip the Advertise and Request steps above (following standard DHCPv6 procedures). 5. The client is expected to periodically renew the link-layer addresses as governed by T1 and T2 timers. This mechanism can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). The client sends a Renew option after T1. It includes the preferred SLAP quadrant(s) in the new QUAD IA_LL-option, so in case the server is unable to extend the lifetime on the existing address(es), the preferred quadrants are known for the allocation of any "new" (i.e., different) addresses. 6. The server responds with a Reply message, with an IA_LL option that includes an LLADDR option with extended lifetime. Bernardos & Mourad Expires April 16, 2021 [Page 8] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 The client SHOULD check if the received MAC address comes from one of the requested quadrants. It MAY repeat the process selecting a different DHCP server. 3.2. Address Assignment from the SLAP Quadrant Indicated by the Relay Next, we describe the protocol operations for a relay to select a preferred SLAP quadrant using the DHCPv6 signaling procedures described in [I-D.ietf-dhc-mac-assign]. This is useful when a DHCPv6 server is operating over a large infrastructure split in different network regions, where each region might have different requirements. The signaling flow is shown in Figure 4. +--------+ +--------+ +--------+ | DHCPv6 | | DHCPv6 | | DHCPv6 | | client | | relay | | server | +--------+ +--------+ +--------+ | | | +-----1. Solicit(IA_LL)----->| | | +----2. Relay-forward | | | (Solicit(IA_LL),QUAD)------>| | | | | |<---3. Relay-reply | | | (Advertise(IA_LL(LLADDR)))--+ |<4. Advertise(IA_LL(LLADDR))+ | |-5. Request(IA_LL(LLADDR))->| | | +-6. Relay-forward | | | (Request(IA_LL(LLADDR)),QUAD)->| | | | | |<--7. Relay-reply | | | (Reply(IA_LL(LLADDR)))-------+ |<--8. Reply(IA_LL(LLADDR))--+ | | | | . . . . (timer expiring) . . . . | | | +--9. Renew(IA_LL(LLADDR))-->| | | |--10. Relay-forward | | | (Renew(IA_LL(LLADDR)),QUAD)-->| | | | | |<---11. Relay-reply | | | (Reply(IA_LL(LLADDR)))-----+ |<--12. Reply(IA_LL(LLADDR)--+ | | | | Figure 4: DHCPv6 signaling flow (client-relay-server) Bernardos & Mourad Expires April 16, 2021 [Page 9] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 1. Link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallest block is a single address. To request an assignment, the client sends a Solicit message with an IA_LL option in the message. The IA_LL option MUST contain a LLADDR option. 2. The DHCP relay receives the Solicit message and encapsulates it in a Relay-forward message. The relay, based on local knowledge and policies, includes in the Relay-forward message the QUAD option with the preferred quadrant. The relay might know which quadrant to request based on local configuration (e.g., the served network contains IoT devices only, thus requiring ELI/ SAI) or other means. Note that if a client sends multiple instances of the IA_LL option in the same message, the DHCP relay MAY only add a single instance of the QUAD option. 3. Upon receiving a relayed message containing an IA_LL option, the server inspects the contents for instances of OPTION_SLAP_QUAD in both the Relay Forward message and the client's message payload. Depending on the server's policy, the instance of the option to process is selected (see also at the end of this section). For each of the entries in OPTION_SLAP_QUAD, in order of the preference field (highest to lowest), the server checks if it has a configured MAC address pool matching the requested quadrant identifier, and an available range of addresses of the requested size. If suitable addresses are found, the server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. This message is sent to the Relay in a Relay-reply message. If the server supports the semantics of the preferred quadrant included in the QUAD option, and manages a block of addresses belonging to a requested quadrant, then the addresses being offered MUST belong to a requested quadrant. The server SHOULD apply the contents of the relay's supplied QUAD option for all of the client's IA_LLs, unless configured to do otherwise. 4. The relay sends the received Advertise message to the client. 5. The client waits for available servers to send Advertise responses and picks one server as defined in Section 18.2.9 of [RFC8415]. The client then sends a Request message that includes the IA_LL container option with the LLADDR option copied from the Advertise message sent by the chosen server. 6. The relay forwards the received Request in a Relay-forward message. It adds in the Relay-forward a QUAD IA_LL-option with the preferred quadrant. Bernardos & Mourad Expires April 16, 2021 [Page 10] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 7. Upon reception of the forwarded Request message with IA_LL container option, the server assigns requested addresses. The server MAY alter the allocation at this time. It then generates and sends a Reply message, in a Relay-reply back to the relay. 8. Upon receiving a Reply message, the client parses the IA_LL container option and may start using all provided addresses. 9. The client is expected to periodically renew the link-layer addresses as governed by T1 and T2 timers. This mechanism can be administratively disabled by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). The client sends a Renew option after T1. 10. This message is forwarded by the relay in a Relay-forward message, including a QUAD IA_LL-option with the preferred quadrant. 11. The server responds with a Reply message, including an LLADDR option with extended lifetime. This message is sent in a Relay- reply message. 12. The relay sends the Reply message back to the client. The server SHOULD implement a configuration parameter to deal with the case where the client's DHCP message contains an instance of OPTION_SLAP_QUAD, and the relay adds a second instance in its relay- forward message. This parameter configures the server to process either the client's, or the relay's instance of option QUAD. It is RECOMMENDED that the default for such a parameter is to process the client's instance of the option. The client MAY check if the received MAC address belongs to a quadrant it is willing to use/configure, and MAY decide based on that whether to use configure the received address. 4. DHCPv6 Option Definition 4.1. Quad option The QUAD option is used to specify the preferences for the selected quadrants within an IA_LL. The option MUST either be encapsulated in the IA_LL-options field of an IA_LL option or in a Relay-forward message. The format of the QUAD option is: Bernardos & Mourad Expires April 16, 2021 [Page 11] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SLAP_QUAD | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | quadrant-1 | pref-1 | quadrant-2 | pref-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | quadrant-n-1 | pref-n-1 | quadrant-n | pref-n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Quad Option Format option-code OPTION_SLAP_QUAD (IANA-1). option-len 2 * number of included (quadrant, preference). A 2-byte field containing the total length of all (quadrant, preference) pairs included in the option. quadrant-n Identifier of the quadrant (0: AAI, 1: ELI, 2: Reserved by IEEE [IEEEStd802c], 3: SAI). Each quadrant MUST only appear once at most in the option. A 1-byte field. pref-n Preference associated to quadrant-n. A higher value means a more preferred quadrant. A 1-byte field. A quadrant identifier value MUST only appear at most once in the option. If an option includes more than one occurrence of the same quadrant identifier, only the first occurence is processed and the rest MUST be ignored by the server. If the same preference value is used for more than one quadrant, the server MAY select which quadrant should be preferred (if the server can assign addresses from all or some of the quadrants with the same assigned preference). Note that this is not a simple list of quadrants ordered by preference without no preference value but a list of quadrants with explicit preference values. This way it can support the case whereby a client really has no preference between two or three quadrants, leaving the decision to the server. If the client or relay agent provide the OPTION_SLAP_QUAD, the server MUST use the quadrant-n/pref-n values to order the selection of the quadrants. If the server can provide an assignment from one of the specified quadrants, it SHOULD proceed with the assignment. If the server does not have a configured address pool matching any of the Bernardos & Mourad Expires April 16, 2021 [Page 12] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 specified quadrant-n fields, or if the server has a configured address pool of the correct quadrant, but no available addresses, it MUST return the IA_LL option containing a status of NoAddrsAvail. There is no requirement that the client or relay agent order the quadrant/pref values in any specific order; hence servers MUST NOT assume that quadrant-1/pref-1 have the highest preference (except if there is only 1 set of values). For cases where a server may not be configured to have pools for the client or relay quadrant preferences, clients and relays SHOULD specify all quadrants in the QUAD option to assure the client gets an address (or addresses) -- if any are available. Specifying all quadrants also results in a QUAD option supporting server responding like a non-QUAD option supporting server, i.e., an address (or addresses) from any available quadrants can be returned. 5. IANA Considerations IANA is requested to assign the QUAD (IANA-1) option code from the DHCPv6 "Option Codes" registry maintained at http://www.iana.org/assignments/dhcpv6-parameters and use the following data when adding the option to the registry: Value: IANA-1 Description: OPTION_SLAP_QUAD Client ORO: No Singleton Option: No Reference: this document 6. Security Considerations See [RFC8415] and [RFC7227] for the DHCPv6 security and privacy considerations. See [RFC8200] for the IPv6 security considerations. See also [I-D.ietf-dhc-mac-assign] for security considerations regarding link-layer address assignments using DHCP. 7. Acknowledgments The authors would like to thank Bernie Volz for his very valuable comments on this document. We also want to thank Ian Farrer, Tomek Mrugalski, Eric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, Alvaro Retana, Murray Kucherawy and Rob Wilton for their very Bernardos & Mourad Expires April 16, 2021 [Page 13] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 detailed and helpful reviews. And to Roger Marks and Antonio de la Oliva for comments related to IEEE work and references. The work in document draft has been supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). 8. References 8.1. Normative References [I-D.ietf-dhc-mac-assign] Volz, B., Mrugalski, T., and C. Bernardos, "Link-Layer Addresses Assignment Mechanism for DHCPv6", draft-ietf- dhc-mac-assign-09 (work in progress), September 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . 8.2. Informative References [IEEE-P802.1CQ-Project] IEEE, "IEEE P802.1CQ: Multicast and Local Address Assignment". [IEEEStd802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802-2014", June 2014. [IEEEStd802c] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, Amendment 2: Local Medium Access Control (MAC) Address Usage, IEEE Std 802c- 2017", June 2017. Bernardos & Mourad Expires April 16, 2021 [Page 14] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal, "Management of Networks with Constrained Devices: Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . Appendix A. Quadrant Selection Mechanisms examples This appendix describes some examples of how the quadrant preference mechanisms could be used. Let's take first an IoT scenario as an example. An IoT device might decide on its own the SLAP quadrant it wants to use to obtain a local MAC address, using the following information to take the decision: o Type of IoT deployment: e.g., industrial, domestic, rural, etc. For small deployments, such as domestic ones, the IoT device itself can decide to use the AAI quadrant (this might not even involve the use of DHCP, by the device just configuring a random address computed by the device itself). For large deployments, such as industrial or rural ones, where thousands of devices might co-exist, the IoT can decide to use the ELI or SAI quadrants. o Mobility: if the IoT device can move, then it might prefer to select the SAI or AAI quadrants to minimize address collisions when moving to another network. If the device is known to remain fixed, then the ELI is probably the most suitable one to use. o Managed/unmanaged: depending on whether the IoT device is managed during its lifetime or cannot be re-configured [RFC7548], the decision of what quadrant is more appropriate might be different. For example, if the IoT device can be managed (e.g., configured), and network topology changes might occur during its lifetime (e.g., due to changes on the deployment, such as extensions Bernardos & Mourad Expires April 16, 2021 [Page 15] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 involving additional devices), this has an impact on the preferred quadrant (e.g., to avoid potential collisions in the future). o Operation/battery lifetime: depending on the expected lifetime of the device a different quadrant might be preferred (as before, to minimize potential address collisions in the future). The previous parameters are considerations that the device vendor/ administrator may wish to use when defining the IoT device's MAC address request policy (i.e., how to select a given SLAP quadrant). IoT devices are typically very resource constrained, so there may only be a simple decision-making process based on pre- configured preferences. We now take the WiFi device scenario, considering for example that a laptop or smartphone connects to a network using its built in MAC address. Due to privacy/security concerns, the device might want to configure a local MAC address. The device might use different parameters and context information to decide, not only which SLAP quadrant to use for the local MAC address configuration, but also when to perform a change of address (e.g., it might be needed to change address several times). This information includes, but it is not limited to: o Type of network the device is connected: public, work, home. o Trusted network: Yes/No. o First time visited network: Yes/No. o Network geographical location. o Mobility: Yes (the device might change its network attachment point)/No (the device is not going to change its network attachment point). o Operating System (OS) network profile, including security/trust related parameters: most modern OSs keep metadata associated to the networks they can attach to, as for example the level of trust the user or administrator assigns to the network. This information is used to configure how the device behaves in terms of advertising itself on the network, firewall settings, etc. But this information can also be used to decide whether to configure a local MAC address or not, from which SLAP quadrant and how often. o Triggers coming from applications regarding location privacy. An app might request to the OS to maximize location privacy (due to the nature of the application) and this might require that the OS Bernardos & Mourad Expires April 16, 2021 [Page 16] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 forces the use of a local MAC address, or that the local MAC address is changed. This information can be used by the device to select the SLAP quadrant. For example, if the device is moving around (e.g., while connected to a public network in an airport), it is likely that it might change access point several times, and therefore it is best to minimize the chances of address collision, using the SAI or AAI quadrants. If the device is not expected to move and attached to a trusted network (e.g. in some scenarios at work), then it is probably best to select the ELI quadrant. These are just some examples of how to use this information to select the quadrant. Additionally, the information can also be used to trigger subsequent changes of MAC address, to enhance location privacy. Besides, changing the SLAP quadrant might also be used as an additional enhancement to make it harder to track the user location. Last, if we consider the data center scenario, a hypervisor might request local MAC addresses to be assigned to virtual machines. As in the previous scenarios, the hypervisor might select the preferred SLAP quadrant using information provided by the cloud management system or virtualization infrastructure manager running on top of the hypervisor. This information might include, but is not limited to: o Migratable VM. If the function implemented by the VM is subject to be moved to another physical server or not. This has an impact on the preference for the SLAP quadrant, as the ELI and SAI quadrants are better suited for supporting migration in a large data center. o VM connectivity characteristics , e.g., standalone, part of a pool, part of a service graph/chain. If the connectivity characteristics of the VM are known, this can be used by the hypervisor to select the best SLAP quadrant. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Bernardos & Mourad Expires April 16, 2021 [Page 17] Internet-Draft DHCPv6 SLAP quadrant selection October 2020 Alain Mourad InterDigital Europe Email: Alain.Mourad@InterDigital.com URI: http://www.InterDigital.com/ Bernardos & Mourad Expires April 16, 2021 [Page 18] ./draft-ietf-anima-reference-model-10.txt0000644000764400076440000021503613375730226017507 0ustar iustyiusty ANIMA M. Behringer, Ed. Internet-Draft Intended status: Informational B. Carpenter Expires: May 27, 2019 Univ. of Auckland T. Eckert Futurewei Technologies Inc. L. Ciavaglia Nokia J. Nobre University of Vale do Rio dos Sinos November 23, 2018 A Reference Model for Autonomic Networking draft-ietf-anima-reference-model-10 Abstract This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 27, 2019. Copyright Notice Copyright (c) 2018 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 Behringer, et al. Expires May 27, 2019 [Page 1] Internet-Draft AN Reference Model November 2018 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. The Network View . . . . . . . . . . . . . . . . . . . . . . 4 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 5 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The Adjacency Table . . . . . . . . . . . . . . . . . . . 6 3.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. State 1: Factory Default . . . . . . . . . . . . . . 8 3.3.2. State 2: Enrolled . . . . . . . . . . . . . . . . . . 9 3.3.3. State 3: In ACP . . . . . . . . . . . . . . . . . . . 9 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 10 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 12 4.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6. The Autonomic Control Plane . . . . . . . . . . . . . . . 13 4.7. Information Distribution (*) . . . . . . . . . . . . . . 13 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 14 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 14 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 14 5.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 15 5.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 15 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 15 6.1. General Description of an ASA . . . . . . . . . . . . . . 15 6.2. ASA Life-Cycle Management . . . . . . . . . . . . . . . . 17 6.3. Specific ASAs for the Autonomic Network Infrastructure . 18 6.3.1. The enrollment ASAs . . . . . . . . . . . . . . . . . 18 6.3.2. The ACP ASA . . . . . . . . . . . . . . . . . . . . . 19 6.3.3. The Information Distribution ASA (*) . . . . . . . . 19 7. Management and Programmability . . . . . . . . . . . . . . . 19 7.1. Managing a (Partially) Autonomic Network . . . . . . . . 19 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 21 7.4. Feedback Loops to NOC (*) . . . . . . . . . . . . . . . . 21 7.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 22 7.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 22 7.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 23 8. Coordination Between Autonomic Functions (*) . . . . . . . . 24 Behringer, et al. Expires May 27, 2019 [Page 2] Internet-Draft AN Reference Model November 2018 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 24 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.1. Protection Against Outsider Attacks . . . . . . . . . . . 26 9.2. Risk of Insider Attacks . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The document "Autonomic Networking - Definitions and Design Goals" [RFC7575] explains the fundamental concepts behind Autonomic Networking, and defines the relevant terms in this space, as well as a high level reference model. [RFC7576] provides a gap analysis between traditional and autonomic approaches. This document defines this reference model with more detail, to allow for functional and protocol specifications to be developed in an architecturally consistent, non-overlapping manner. As discussed in [RFC7575], the goal of this work is not to focus exclusively on fully autonomic nodes or networks. In reality, most networks will run with some autonomic functions, while the rest of the network is traditionally managed. This reference model allows for this hybrid approach. For example, it is possible in an existing, non-autonomic network to enrol devices in a traditional way, to bring up a trust infrastructure with certificates. This trust infrastructure could then be used to automatically bring up an Autonomic Control Plane (ACP), and run traditional network operations over the secure and self-healing ACP. See [I-D.ietf-anima-stable-connectivity] for a description of this use case. The scope of this model is therefore limited to networks that are to some extent managed by skilled human operators, loosely referred to as "professionally managed" networks. Unmanaged networks raise additional security and trust issues that this model does not cover. This document describes a first, simple, implementable phase of an Autonomic Networking solution. It is expected that the experience from this phase will be used in defining updated and extended specifications over time. Some topics are considered architecturally Behringer, et al. Expires May 27, 2019 [Page 3] Internet-Draft AN Reference Model November 2018 in this document, but are not yet reflected in the implementation specifications. They are marked with an (*). 2. The Network View This section describes the various elements in a network with autonomic functions, and how these entities work together, on a high level. Subsequent sections explain the detailed inside view for each of the autonomic network elements, as well as the network functions (or interfaces) between those elements. Figure 1 shows the high level view of an Autonomic Network. It consists of a number of autonomic nodes, which interact directly with each other. Those autonomic nodes provide a common set of capabilities across the network, called the "Autonomic Networking Infrastructure" (ANI). The ANI provides functions like naming, addressing, negotiation, synchronization, discovery and messaging. Autonomic functions typically span several, possibly all nodes in the network. The atomic entities of an autonomic function are called the "Autonomic Service Agents" (ASA), which are instantiated on nodes. +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + : : Autonomic Function 1 : : : ASA 1 : ASA 1 : ASA 1 : ASA 1 : +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + : : : : +- - - - - - - - - - - - - - + : : : Autonomic Function 2 : : : : ASA 2 : ASA 2 : : : +- - - - - - - - - - - - - - + : : : : +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + : Autonomic Networking Infrastructure : +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +--------+ : +--------+ : +--------+ : +--------+ | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | +--------+ : +--------+ : +--------+ : +--------+ Figure 1: High level view of an Autonomic Network In a horizontal view, autonomic functions span across the network, as well as the Autonomic Networking Infrastructure. In a vertical view, a node always implements the ANI, plus it may have one or several Autonomic Service Agents. ASAs may be standalone, or use other ASAs in a hierarchical way. Behringer, et al. Expires May 27, 2019 [Page 4] Internet-Draft AN Reference Model November 2018 The Autonomic Networking Infrastructure (ANI) therefore is the foundation for autonomic functions. 3. The Autonomic Network Element This section explains the general architecture of an Autonomic Network Element (Section 3.1), how it tracks its surrounding environment in an Adjacency Table (Section 3.2), and the state machine which defines the behaviour of the network element (Section 3.3), based on that adjacency table. 3.1. Architecture This section describes an autonomic network element and its internal architecture. The reference model explained in the document "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows the sources of information that an autonomic service agent can leverage: Self-knowledge, network knowledge (through discovery), Intent (see Section 7.2), and feedback loops. There are two levels inside an autonomic node: the level of Autonomic Service Agents, and the level of the Autonomic Networking Infrastructure, with the former using the services of the latter. Figure 2 illustrates this concept. +------------------------------------------------------------+ | | | +-----------+ +------------+ +------------+ | | | Autonomic | | Autonomic | | Autonomic | | | | Service | | Service | | Service | | | | Agent 1 | | Agent 2 | | Agent 3 | | | +-----------+ +------------+ +------------+ | | ^ ^ ^ | | - - | - - API level - -| - - - - - - - |- - - | | V V V | |------------------------------------------------------------| | Autonomic Networking Infrastructure | | - Data structures (ex: certificates, peer information) | | - Generalized Autonomic Control Plane (GACP) | | - Autonomic Node Addressing and naming | | - Discovery, negotiation and synchronisation functions | | - Distribution of Intent and other information | | - Aggregated reporting and feedback loops | | - Routing | |------------------------------------------------------------| | Basic Operating System Functions | +------------------------------------------------------------+ Figure 2: Model of an autonomic node Behringer, et al. Expires May 27, 2019 [Page 5] Internet-Draft AN Reference Model November 2018 The Autonomic Networking Infrastructure (lower part of Figure 2) contains node specific data structures, for example trust information about itself and its peers, as well as a generic set of functions, independent of a particular usage. This infrastructure should be generic, and support a variety of Autonomic Service Agents (upper part of Figure 2). It contains addressing and naming of autonomic nodes, discovery, negotiation and synchronisation functions, distribution of information, reporting and feedback loops, as well as routing inside the Autonomic Control Plane. The Generalized Autonomic Control Plane (GACP) is the summary of all interactions of the Autonomic Networking Infrastructure with other nodes and services. A specific implementation of the GACP is referred to here as the Autonomic Control Plane (ACP), and described in [I-D.ietf-anima-autonomic-control-plane]. The use cases of "Autonomics" such as self-management, self- optimisation, etc, are implemented as Autonomic Service Agents. They use the services and data structures of the underlying Autonomic Networking Infrastructure, which should be self-managing. The "Basic Operating System Functions" include the "normal OS", including the network stack, security functions, etc. Full AN nodes have the full Autonomic Networking Infrastructure, with the full functionality described in this document. At a later stage ANIMA may define a scope for constrained nodes with a reduced ANI and well-defined minimal functionality. They are currently out of scope. 3.2. The Adjacency Table Autonomic Networking is based on direct interactions between devices of a domain. The Autonomic Control Plane (ACP) is normally constructed on a hop-by-hop basis. Therefore, many interactions in the ANI are based on the ANI adjacency table. There are interactions that provide input into the adjacency table, and other interactions that leverage the information contained in it. The ANI adjacency table contains information about adjacent autonomic nodes, at a minimum: node-ID, IP address in data plane, IP address in ACP, domain, certificate. An autonomic node maintains this adjacency table up to date. The adjacency table only contains information about other nodes that are capable of Autonomic Networking; non- autonomic nodes are normally not tracked here. However, the information is tracked independently of the status of the peer nodes; specifically, it contains information about non-enrolled nodes, nodes of the same and other domains. The adjacency table may contain Behringer, et al. Expires May 27, 2019 [Page 6] Internet-Draft AN Reference Model November 2018 information about the validity and trust level of the adjacent autonomic nodes. The adjacency table is fed by the following inputs: o Link local discovery: This interaction happens in the data plane, using IPv6 link local addressing only, because this addressing type is itself autonomic. This way the nodes learns about all autonomic nodes around itself. The related standards track documents ([I-D.ietf-anima-grasp], [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-autonomic-control-plane]) describe in detail how link local discovery is used. o Vendor re-direct: A new device may receive information on where its home network is through a vendor based Manufacturer Authorized Signing Authority (MASA, see Section 5.3) re-direct; this is typically a routable address. o Non-autonomic input: A node may be configured manually with an autonomic peer; it could learn about autonomic nodes through DHCP options, DNS, and other non-autonomic mechanisms. Generally such non-autonomic mechansims require some administrator intervention. The key purpose is to by-pass a non-autonomic device or network. As this pertains to new devices, it is covered in appendix A and B of [I-D.ietf-anima-bootstrapping-keyinfra]. The adjacency table is defining the behaviour of an autonomic node: o If the node has not bootstrapped into a domain (i.e., doesn't have a domain certificate), it rotates through all nodes in the adjacency table that claim to have a domain, and will attempt bootstrapping through them, one by one. One possible response is a re-direct via a vendor MASA, which will be entered into the adjacency table (see second bullet above). See [I-D.ietf-anima-bootstrapping-keyinfra] for details. o If the adjacent node has the same domain, it will authenticate that adjacent node and, if successful, establish the Autonomic Control Plane (ACP). See [I-D.ietf-anima-autonomic-control-plane]. o Once the node is part of the ACP of a domain, it will use GRASP [I-D.ietf-anima-grasp] to find Registrar(s) of its domain and potentially other services. o If the node is part of an ACP and has discovered at least one Registrar in its domain via GRASP, it will start the "join Behringer, et al. Expires May 27, 2019 [Page 7] Internet-Draft AN Reference Model November 2018 assistant" ASA, and act as a join assistant for neighboring nodes that need to be bootstrapped. See Section 6.3.1.2 for details. o Other behaviours are possible, for example establishing the ACP also with devices of a sub-domain, to other domains, etc. Those will likely be controlled by Intent. They are outside scope for the moment. Note that Intent is distributed through the ACP; therefore, a node can only adapt Intent driven behaviour once it has joined the ACP. At the moment, ANIMA does not consider providing Intent outside the ACP; this can be considered later. Once a node has joined the ACP, it will also learn the ACP addresses of its adjacent nodes, and add them to the adjacency table, to allow for communication inside the ACP. Further autonomic domain interactions will now happen inside the ACP. At this moment, only negotiation / synchronization via GRASP [I-D.ietf-anima-grasp] is being defined. (Note that GRASP runs in the data plane, as an input in building the adjacency table, as well as inside the ACP.) Autonomic Functions consist of Autonomic Service Agents (ASAs). They run logically above the AN Infrastructure, and may use the adjacency table, the ACP, negotiation and synchronization through GRASP in the ACP, Intent and other functions of the ANI. Since the ANI only provides autonomic interactions within a domain, autonomic functions can also use any other context on a node, specifically the global data plane. 3.3. State Machine Autonomic Networking applies during the full life-cycle of a node. This section describes a state machine of an autonomic node, throughout its life. A device is normally expected to store its domain specific identity, the LDevID (see Section 5.2), in persistent storage, to be available after a powercycle event. For device types that cannot store the LDevID in persistent storage, a powercycle event is effectively equivalent to a factory reset. 3.3.1. State 1: Factory Default An autonomic node leaves the factory in this state. In this state, the node has no domain specific configuration, specifically no LDevID, and could be used in any particular target network. It does however have a vendor/manufacturer specific ID, the IDevID [IDevID]. Nodes without IDevID cannot be autonomically and securely enrolled into a domain; they require manual pre-staging, in which case the pre-staging takes them directly to state 2. Behringer, et al. Expires May 27, 2019 [Page 8] Internet-Draft AN Reference Model November 2018 Transitions: o Bootstrap event: The device enrols into a domain; as part of this process it receives a domain identity (LDevID). If enrollment is successful, the next state is state 2. See [I-D.ietf-anima-bootstrapping-keyinfra] Section 3 for details on enrollment. o Powercycle event: The device loses all state tables. It remains in state: 1. 3.3.2. State 2: Enrolled An autonomic node is in the state "enrolled" if it has a domain identity (LDevID), and has currently no ACP channel up. It may have further configuration or state, for example if it had been in state 3 before, but lost all its ACP channels. The LDevID can only be removed from a device through a factory reset, which also removes all other state from the device. This ensures that a device has no stale domain specific state when entering the "enrolled" state from state 1. Transitions: o Joining ACP: The device establishes an ACP channel to an adjacent device. See [I-D.ietf-anima-autonomic-control-plane] for details. Next state: 3. o Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1. o Powercycle event: The device loses all state tables, but not its domain identity (LDevID). it remains in state: 2. 3.3.3. State 3: In ACP In this state, the autonomic node has at least one ACP channel to another device. The node can now participate in further autonomic transactions, such as starting autonomic service agents (e.g., it must now enable the join assistant ASA, to help other devices to join the domain. Other conditions may apply to such interactions, for example to serve as a join assistant, the device must first discover a bootstrap Registrar. Transitions: o Leaving ACP: The device drops the last (or only) ACP channel to an adjacent device. Next state: 2. Behringer, et al. Expires May 27, 2019 [Page 9] Internet-Draft AN Reference Model November 2018 o Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1. o Powercycle event: The device loses all state tables, but not its domain identity (LDevID). Next state: 2. 4. The Autonomic Networking Infrastructure The Autonomic Networking Infrastructure provides a layer of common functionality across an Autonomic Network. It provides the elementary functions and services, as well as extensions. An Autonomic Function, comprising of Autonomic Service Agents on nodes, uses the functions described in this section. 4.1. Naming Inside a domain, each autonomic device should be assigned a unique name. The naming scheme should be consistent within a domain. Names are typically assigned by a Registrar at bootstrap time and persistent over the lifetime of the device. All Registrars in a domain must follow the same naming scheme. In the absence of a domain specific naming scheme, a default naming scheme should use the same logic as the addressing scheme discussed in [I-D.ietf-anima-autonomic-control-plane]. The device name is then composed of a Registrar ID (for example taking a MAC address of the Registrar) and a device number. An example name would then look like this: 0123-4567-89ab-0001 The first three fields are the MAC address, the fourth field is the sequential number for the device. 4.2. Addressing Autonomic Service Agents (ASAs) need to communicate with each other, using the autonomic addressing of the Autonomic Networking Infrastructure of the node they reside on. This section describes the addressing approach of the Autonomic Networking Infrastructure, used by ASAs. Addressing approaches for the data plane of the network are outside the scope of this document. These addressing approaches may be configured and managed in the traditional way, or negotiated as a service of an ASA. One use case for such an autonomic function is described in [I-D.ietf-anima-prefix-management]. Behringer, et al. Expires May 27, 2019 [Page 10] Internet-Draft AN Reference Model November 2018 Autonomic addressing is a function of the Autonomic Networking Infrastructure (lower part of Figure 2), specifically the Autonomic Control Plane. ASAs do not have their own addresses. They may use either API calls, or the autonomic addressing scheme of the Autonomic Networking Infrastructure. An autonomic addressing scheme has the following requirements: o Zero-touch for simple networks: Simple networks should have complete self-management of addressing, and not require any central address management, tools, or address planning. o Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high level guidance only, expressed in Intent. o Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around, for the network to grow, split and merge. o Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context. o Stability: The addressing scheme should be as stable as possible. However, implementations need to be able to recover from unexpected address changes. o Support for virtualization: Autonomic functions can exist either at the level of the physical network and physical devices, or at the level of virtual machines, containers and networks. In particular, Autonomic Nodes may support Autonomic Service Agents in virtual entities. The infrastructure, including the addressing scheme, should be able to support this architecture. o Simplicity: To make engineering simpler, and to give the human administrator an easy way to trouble-shoot autonomic functions. o Scale: The proposed scheme should work in any network of any size. o Upgradability: The scheme must be able to support different addressing concepts in the future. The proposed addressing scheme is described in the document "An Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). Behringer, et al. Expires May 27, 2019 [Page 11] Internet-Draft AN Reference Model November 2018 4.3. Discovery Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should rely on such northbound interfaces minimally or not at all, and therefore it needs to discover peers and other resources in the network. This section describes various discovery functions in an autonomic network. Discovering nodes and their properties and capabilities: A core function to establish an autonomic domain is the mutual discovery of autonomic nodes, primarily adjacent nodes and secondarily off-link peers. This may in principle either leverage existing discovery mechanisms, or use new mechanisms tailored to the autonomic context. An important point is that discovery must work in a network with no predefined topology, ideally no manual configuration of any kind, and with nodes starting up from factory condition or after any form of failure or sudden topology change. Discovering services: Network services such as AAA should also be discovered and not configured. Service discovery is required for such tasks. An autonomic network can either leverage existing service discovery functions, or use a new approach, or a mixture. Thus the discovery mechanism could either be fully integrated with autonomic signaling (next section) or could use an independent discovery mechanism such as DNS Service Discovery or Service Location Protocol. This choice could be made independently for each Autonomic Service Agent, although the infrastructure might require some minimal lowest common denominator (e.g., for discovering the security bootstrap mechanism, or the source of information distribution, Section 4.7). Phase 1 of Autonomic Networking uses GRASP for discovery, described in [I-D.ietf-anima-grasp]. 4.4. Signaling Between Autonomic Nodes Autonomic nodes must communicate with each other, for example to negotiate and/or synchronize technical objectives (i.e., network parameters) of any kind and complexity. This requires some form of signaling between autonomic nodes. Autonomic nodes implementing a specific use case might choose their own signaling protocol, as long as it fits the overall security model. However, in the general case, any pair of autonomic nodes might need to communicate, so there needs to be a generic protocol for this. A prerequisite for this is that autonomic nodes can discover each other without any preconfiguration, as mentioned above. To be generic, discovery and signaling must be Behringer, et al. Expires May 27, 2019 [Page 12] Internet-Draft AN Reference Model November 2018 able to handle any sort of technical objective, including ones that require complex data structures. The document "A Generic Autonomic Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more detailed requirements for discovery, negotiation and synchronization in an autonomic network. It also defines a protocol, GRASP, for this purpose, including an integrated but optional discovery protocol. GRASP is normally expected to run inside the Autonomic Control Plane (ACP; see Section 4.6) and to depend on the ACP for security. It may run insecurely for a short time during bootstrapping. An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are not excluded. 4.5. Routing All autonomic nodes in a domain must be able to communicate with each other, and later phases also with autonomic nodes outside their own domain. Therefore, an Autonomic Control Plane relies on a routing function. For Autonomic Networks to be interoperable, they must all support one common routing protocol. The routing protocol is defined in the ACP document [I-D.ietf-anima-autonomic-control-plane]. 4.6. The Autonomic Control Plane The "Autonomic Control Plane" carries the control protocols in an autonomic network. In the architecture described here, it is implemented as an overlay network. The document "An Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes the implementation details suggested here. This document uses the term "overlay" to mean a set of point-to-point adjacencies congruent with the underlying interconnection topology. The terminology may not be aligned with a common usage of the "overlay" term in routing context. See [I-D.ietf-anima-stable-connectivity] for uses cases for the ACP. 4.7. Information Distribution (*) Certain forms of information require distribution across an autonomic domain. The distribution of information runs inside the Autonomic Control Plane. For example, Intent is distributed across an autonomic domain, as explained in [RFC7575]. Behringer, et al. Expires May 27, 2019 [Page 13] Internet-Draft AN Reference Model November 2018 Intent is the policy language of an Autonomic Network, see also Section 7.2. It is a high level policy, and should change only infrequently (order of days). Therefore, information such as Intent should be simply flooded to all nodes in an autonomic domain, and there is currently no perceived need to have more targeted distribution methods. Intent is also expected to be monolithic, and flooded as a whole. One possible method for distributing Intent, as well as other forms of data, is discussed in [I-D.liu-anima-grasp-distribution]. Intent and information distribution are not part of phase 1 of ANIMA. 5. Security and Trust Infrastructure An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security, with the exception of setting up a PKI infrastructure. Autonomic nodes have direct interactions between themselves, which must be secured. Since an autonomic network does not rely on configuration, it is not an option to configure, for example, pre- shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. In this first phase of autonomic networking, a device is either within the trust domain and fully trusted, or outside the trust domain and fully untrusted. The default method to automatically bring up a trust infrastructure is defined in the document "Bootstrapping Key Infrastructures" [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this enrollment process are described in Section 6.3. An autonomic node must implement the enrollment and join assistant ASAs. The registrar ASA may be implemented only on a sub-set of nodes. 5.1. Public Key Infrastructure An autonomic domain uses a PKI model. The root of trust is a certification authority (CA). A registrar acts as a registration authority (RA). A minimum implementation of an autonomic domain contains one CA, one Registrar, and network elements. 5.2. Domain Certificate Each device in an autonomic domain uses a domain certificate (LDevID) to prove its identity. A new device uses its manufacturer provided certificate (IDevID) during bootstrap, to obtain a domain Behringer, et al. Expires May 27, 2019 [Page 14] Internet-Draft AN Reference Model November 2018 certificate. [I-D.ietf-anima-bootstrapping-keyinfra] describes how a new device receives a domain certificate, and the certificate format. 5.3. The MASA The Manufacturer Authorized Signing Authority (MASA) is a trusted service for bootstrapping devices. The purpose of the MASA is to provide ownership tracking of devices in a domain. The MASA provides audit, authorization, and ownership tokens to the registrar during the bootstrap process to assist in the authentication of devices attempting to join an Autonomic Domain, and to allow a joining device to validate whether it is joining the correct domain. The details for MASA service, security, and usage are defined in [I-D.ietf-anima-bootstrapping-keyinfra]. 5.4. Sub-Domains (*) By default, sub-domains are treated as different domains. This implies no trust between a domain and its sub-domains, and no trust between sub-domains of the same domain. Specifically, no ACP is built, and Intent is valid only for the domain it is defined for explicitly. In phase 2 of ANIMA, alternative trust models should be defined, for example to allow full or limited trust between domain and sub-domain. 5.5. Cross-Domain Functionality (*) By default, different domains do not interoperate, no ACP is built and no trust is implied between them. In the future, models can be established where other domains can be trusted in full or for limited operations between the domains. 6. Autonomic Service Agents (ASA) This section describes how autonomic services run on top of the Autonomic Networking Infrastructure. 6.1. General Description of an ASA An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole." Thus it is a process that makes use of the features provided by the ANI to achieve its own goals, usually including interaction with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts with the specific targets of Behringer, et al. Expires May 27, 2019 [Page 15] Internet-Draft AN Reference Model November 2018 its function, using any suitable mechanism. Unless its function is very simple, the ASA will need to handle overlapping asynchronous operations. It may therefore be a quite complex piece of software in its own right, forming part of the application layer above the ANI. ASA design guidelines are available in [I-D.carpenter-anima-asa-guidelines]. Thus we can distinguish at least three classes of ASAs: o Simple ASAs with a small footprint that could run anywhere. o Complex, possibly multi-threaded ASAs that have a significant resource requirement and will only run on selected nodes. o A few 'infrastructure ASAs' that use basic ANI features in support of the ANI itself, which must run in all autonomic nodes. These are outlined in the following sections. Autonomic nodes, and therefore their ASAs, know their own capabilities and restrictions, derived from hardware, firmware or pre-installed software: They are "self-aware". The role of an autonomic node depends on Intent and on the surrounding network behaviors, which may include forwarding behaviors, aggregation properties, topology location, bandwidth, tunnel or translation properties, etc. For example, a node may decide to act as a backup node for a neighbor, if its capabilities allow it to do so. Following an initial discovery phase, the node properties and those of its neighbors are the foundation of the behavior of a specific node. A node and its ASAs have no pre-configuration for the particular network in which they are installed. Since all ASAs will interact with the ANI, they will depend on appropriate application programming interfaces (APIs). It is desirable that ASAs are portable between operating systems, so these APIs need to be universal. An API for GRASP is described in [I-D.ietf-anima-grasp-api]. ASAs will in general be designed and coded by experts in a particular technology and use case, not by experts in the ANI and its components. Also, they may be coded in a variety of programming languages, in particular including languages that support object constructs as well as traditional variables and structures. The APIs should be designed with these factors in mind. Behringer, et al. Expires May 27, 2019 [Page 16] Internet-Draft AN Reference Model November 2018 It must be possible to run ASAs as non-privileged (user space) processes except for those (such as the infrastructure ASAs) that necessarily require kernel privilege. Also, it is highly desirable that ASAs can be dynamically loaded on a running node. Since autonomic systems must be self-repairing, it is of great importance that ASAs are coded using robust programming techniques. All run-time error conditions must be caught, leading to suitable minimally disruptive recovery actions, also considering a complete restart of the ASA. Conditions such as discovery failures or negotiation failures must be treated as routine, with the ASA retrying the failed operation, preferably with an exponential back- off in the case of persistent errors. When multiple threads are started within an ASA, these threads must be monitored for failures and hangups, and appropriate action taken. Attention must be given to garbage collection, so that ASAs never run out of resources. There is assumed to be no human operator - again, in the worst case, every ASA must be capable of restarting itself. ASAs will automatically benefit from the security provided by the ANI, and specifically by the ACP and by GRASP. However, beyond that, they are responsible for their own security, especially when communicating with the specific targets of their function. Therefore, the design of an ASA must include a security analysis beyond 'use ANI security.' 6.2. ASA Life-Cycle Management ASAs operating on a given ANI may come from different providers and pursue different objectives. Management of ASAs and its interactions with the ANI should follow the same operating principles, hence comply to a generic life-cycle management model. The ASA life-cycle provides standard processes to: o install ASA: copy the ASA code onto the node and start it, o deploy ASA: associate the ASA instance with a (some) managed network device(s) (or network function), o control ASA execution: when and how an ASA executes its control loop. The life-cyle will cover the sequential states below: Installation, Deployment, Operation and the transitional states in-between. This Life-Cycle will also define which interactions ASAs have with the ANI in between the different states. The noticeable interactions are: Behringer, et al. Expires May 27, 2019 [Page 17] Internet-Draft AN Reference Model November 2018 o Self-description of ASA instances at the end of deployment: its format needs to define the information required for the management of ASAs by ANI entities o Control of ASA control-loop during the operation: a signaling has to carry formatted messages to control ASA execution (at least starting and stopping the control loop) 6.3. Specific ASAs for the Autonomic Network Infrastructure The following functions provide essential, required functionality in an autonomic network, and are therefore mandatory to implement on unconstrained autonomic nodes. They are described here as ASAs that include the underlying infrastructure components, but implementation details might vary. The first three together support the trust enrollment process described in Section 5. For details see [I-D.ietf-anima-bootstrapping-keyinfra]. 6.3.1. The enrollment ASAs 6.3.1.1. The Pledge ASA This ASA includes the function of an autonomic node that bootstraps into the domain with the help of an join assitant ASA (see below). Such a node is known as a Pledge during the enrollment process. This ASA must be installed by default on all nodes that require an autonomic zero-touch bootstrap. 6.3.1.2. The Join Assistant ASA This ASA includes the function of an autonomic node that helps a non- enrolled, adjacent devices to enroll into the domain. This ASA must be installed on all nodes, although only one join assistant needs to be active on a given LAN. See also [I-D.ietf-anima-bootstrapping-keyinfra]. 6.3.1.3. The Join Registrar ASA This ASA includes the join registrar function in an autonomic network. This ASA does not need to be installed on all nodes, but only on nodes that implement the Join Registrar function. Behringer, et al. Expires May 27, 2019 [Page 18] Internet-Draft AN Reference Model November 2018 6.3.2. The ACP ASA This ASA includes the ACP function in an autonomic network. In particular it acts to discover other potential ACP nodes, and to support the establishment and teardown of ACP channels. This ASA must be installed on all nodes. For details see Section 4.6 and [I-D.ietf-anima-autonomic-control-plane]. 6.3.3. The Information Distribution ASA (*) This ASA is currently out of scope in ANIMA, and provided here only as background information. This ASA includes the information distribution function in an autonomic network. In particular it acts to announce the availability of Intent and other information to all other autonomic nodes. This ASA does not need to be installed on all nodes, but only on nodes that implement the information distribution function. For details see Section 4.7. Note that information distribution can be implemented as a function in any ASA. See [I-D.liu-anima-grasp-distribution] for more details on how information is suggested to be distributed. 7. Management and Programmability This section describes how an Autonomic Network is managed, and programmed. 7.1. Managing a (Partially) Autonomic Network Autonomic management usually co-exists with traditional management methods in most networks. Thus, autonomic behavior will be defined for individual functions in most environments. Examples for overlap are: o Autonomic functions can use traditional methods and protocols (e.g., SNMP and NETCONF) to perform management tasks, inside and outside the ACP; o Autonomic functions can conflict with behavior enforced by the same traditional methods and protocols; o Traditional functions can use the ACP, for example if reachability on the data plane is not (yet) established. The autonomic Intent is defined at a high level of abstraction. However, since it is necessary to address individual managed Behringer, et al. Expires May 27, 2019 [Page 19] Internet-Draft AN Reference Model November 2018 elements, autonomic management needs to communicate in lower-level interactions (e.g., commands and requests). For example, it is expected that the configuration of such elements be performed using NETCONF and YANG modules as well as the monitoring be executed through SNMP and MIBs. Conflict can occur between autonomic default behavior, autonomic Intent, traditional management methods. Conflict resolution is achieved in autonomic management through prioritization [RFC7575]. The rationale is that manual and node-based management have a higher priority over autonomic management. Thus, the autonomic default behavior has the lowest priority, then comes the autonomic Intent (medium priority), and, finally, the highest priority is taken by node-specific network management methods, such as the use of command line interfaces. 7.2. Intent (*) Intent is not covered in the current implementation specifications. This section discusses a topic for further research. This section gives an overview of Intent, and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., PCIM) and in other SDOs (e.g., DMTF and TMF ZOOM). Intent can be described as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network [RFC7575]. Intent should be limited to high level guidance only, thus it does not directly define a policy for every network element separately. Intent can be refined to lower level policies using different approaches. This is expected in order to adapt the Intent to the capabilities of managed devices. Intent may contain role or function information, which can be translated to specific nodes [RFC7575]. One of the possible refinements of the Intent is using Event- Condition-Action (ECA) rules. Different parameters may be configured for Intent. These parameters are usually provided by the human operator. Some of these parameters can influence the behavior of specific autonomic functions as well as the way the Intent is used to manage the autonomic domain. Intent is discussed in more detail in [I-D.du-anima-an-intent]. Intent as well as other types of information are distributed via GRASP, see [I-D.liu-anima-grasp-distribution]. Behringer, et al. Expires May 27, 2019 [Page 20] Internet-Draft AN Reference Model November 2018 7.3. Aggregated Reporting (*) Aggregated reporting is not covered in the current implementation specifications. This section discusses a topic for further research. An Autonomic Network should minimize the need for human intervention. In terms of how the network should behave, this is done through an autonomic Intent provided by the human administrator. In an analogous manner, the reports which describe the operational status of the network should aggregate the information produced in different network elements in order to present the effectiveness of autonomic Intent enforcement. Therefore, reporting in an autonomic network should happen on a network-wide basis [RFC7575]. Multiple simultaneous events can occur in an autonomic network in the same way they can happen in a traditional network. However, when reporting to a human administrator, such events should be aggregated to avoid notifications about individual managed elements. In this context, algorithms may be used to determine what should be reported (e.g., filtering) and in which way and how different events are related to each other. Besides that, an event in an individual element can be compensated by changes in other elements to maintain a network-wide target which is described in the autonomic Intent. Reporting in an autonomic network may be at the same abstraction level as Intent. In this context, the aggregated view of current operational status of an autonomic network can be used to switch to different management modes. Despite the fact that autonomic management should minimize the need for user intervention, possibly there are some events that need to be addressed by human administrator actions. 7.4. Feedback Loops to NOC (*) Feedback loops are required in an autonomic network to allow the intervention of a human administrator or central control systems, while maintaining a default behaviour. Through a feedback loop an administrator must be prompted with a default action, and has the possibility to acknowledge or override the proposed default action. Uni-directional notifications to the NOC, that do not propose any default action, and do not allow an override as part of the transaction are considered like traditional notification services, such as syslog. They are expected to co-exist with autonomic methods, but are not covered in this draft. Behringer, et al. Expires May 27, 2019 [Page 21] Internet-Draft AN Reference Model November 2018 7.5. Control Loops (*) Control loops are not covered in the current implementation specifications. This section discusses a topic for further research. Control loops are used in autonomic networking to provide a generic mechanism to enable the Autonomic System to adapt (on its own) to various factors that can change the goals that the autonomic network is trying to achieve, or how those goals are achieved. For example, as user needs, business goals, and the ANI itself changes, self- adaptation enables the ANI to change the services and resources it makes available to adapt to these changes. Control loops operate to continuously observe and collect data that enables the autonomic management system to understand changes to the behavior of the system being managed, and then provide actions to move the state of the system being managed toward a common goal. Self-adaptive systems move decision-making from static, pre-defined commands to dynamic processes computed at runtime. Most autonomic systems use a closed control loop with feedback. Such control loops should be able to be dynamically changed at runtime to adapt to changing user needs, business goals, and changes in the ANI. 7.6. APIs (*) APIs are not covered in the current implementation specifications. This section discusses a topic for further research. Most APIs are static, meaning that they are pre-defined and represent an invariant mechanism for operating with data. An Autonomic Network should be able to use dynamic APIs in addition to static APIs. A dynamic API is one that retrieves data using a generic mechanism, and then enables the client to navigate the retrieved data and operate on it. Such APIs typically use introspection and/or reflection. Introspection enables software to examine the type and properties of an object at runtime, while reflection enables a program to manipulate the attributes, methods, and/or metadata of an object. APIs must be able to express and preserve the semantics of data models. For example, software contracts [Meyer97] are based on the principle that a software-intensive system, such as an Autonomic Network, is a set of communicating components whose interaction is based on precisely-defined specifications of the mutual obligations that interacting components must respect. This typically includes specifying: Behringer, et al. Expires May 27, 2019 [Page 22] Internet-Draft AN Reference Model November 2018 o pre-conditions that must be satisfied before the method can start execution o post-conditions that must be satisfied when the method has finished execution o invariant attributes that must not change during the execution of the method 7.7. Data Model (*) Data models are not covered in the current implementation specifications. This section discusses a topic for further research. The following definitions are adapted from [I-D.ietf-supa-generic-policy-data-model]: An information model is a representation of concepts of interest to an environment in a form that is independent of data repository, data definition language, query language, implementation language, and protocol. In contrast, a data model is a representation of concepts of interest to an environment in a form that is dependent on data repository, data definition language, query language, implementation language, and protocol (typically, but not necessarily, all three). The utility of an information model is to define objects and their relationships in a technology-neutral manner. This forms a consensual vocabulary that the ANI and ASAs can use. A data model is then a technology-specific mapping of all or part of the information model to be used by all or part of the system. A system may have multiple data models. Operational Support Systems, for example, typically have multiple types of repositories, such as SQL and NoSQL, to take advantage of the different properties of each. If multiple data models are required by an Autonomic System, then an information model should be used to ensure that the concepts of each data model can be related to each other without technological bias. A data model is essential for certain types of functions, such as a Model-Reference Adaptive Control Loop (MRACL). More generally, a data model can be used to define the objects, attributes, methods, and relationships of a software system (e.g., the ANI, an autonomic node, or an ASA). A data model can be used to help design an API, as well as any language used to interface to the Autonomic Network. Behringer, et al. Expires May 27, 2019 [Page 23] Internet-Draft AN Reference Model November 2018 8. Coordination Between Autonomic Functions (*) Coordination between autonomic functions is not covered in the current implementation specifications. This section discusses a topic for further research. 8.1. The Coordination Problem (*) Different autonomic functions may conflict in setting certain parameters. For example, an energy efficiency function may want to shut down a redundant link, while a load balancing function would not want that to happen. The administrator must be able to understand and resolve such interactions, to steer autonomic network performance to a given (intended) operational point. Several interaction types may exist among autonomic functions, for example: o Cooperation: An autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function. o Dependency: An autonomic function cannot work without another one being present or accessible in the autonomic network. o Conflict: A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions. Solving the coordination problem beyond one-by-one cases can rapidly become intractable for large networks. Specifying a common functional block on coordination is a first step to address the problem in a systemic way. The coordination life-cycle consists in three states: o At build-time, a "static interaction map" can be constructed on the relationship of functions and attributes. This map can be used to (pre-)define policies and priorities on identified conflicts. o At deploy-time, autonomic functions are not yet active/acting on the network. A "dynamic interaction map" is created for each instance of each autonomic functions and on a per resource basis, including the actions performed and their relationships. This map provides the basis to identify conflicts that will happen at run- time, categorize them and plan for the appropriate coordination strategies/mechanisms. Behringer, et al. Expires May 27, 2019 [Page 24] Internet-Draft AN Reference Model November 2018 o At run-time, when conflicts happen, arbitration is driven by the coordination strategies. Also new dependencies can be observed and inferred, resulting in an update of the dynamic interaction map and adaptation of the coordination strategies and mechanisms. Multiple coordination strategies and mechanisms exist and can be devised. The set ranges from basic approaches such as random process or token-based process, to approaches based on time separation and hierarchical optimization, to more complex approaches such as multi- objective optimization, and other control theory approaches and algorithms family. 8.2. A Coordination Functional Block (*) A common coordination functional block is a desirable component of the ANIMA reference model. It provides a means to ensure network properties and predictable performance or behavior such as stability, and convergence, in the presence of several interacting autonomic functions. A common coordination function requires: o A common description of autonomic functions, their attributes and life-cycle. o A common representation of information and knowledge (e.g., interaction maps). o A common "control/command" interface between the coordination "agent" and the autonomic functions. Guidelines, recommendations or BCPs can also be provided for aspects pertaining to the coordination strategies and mechanisms. 9. Security Considerations In this section we distinguish outsider and insider attacks. In an outsider attack all network elements and protocols are securely managed and operating, and an outside attacker can sniff packets in transit, inject and replay packets. In an insider attack, the attacker has access to an autonomic node or other means (e.g. remote code execution in the node by exploiting ACP-independent vulnerabilities in the node platform) to produce arbitrary payloads on the protected ACP channels. If a system has vulnerabilities in the implementation or operation (configuration), an outside attacker can exploit such vulnerabilies to become an insider attacker. Behringer, et al. Expires May 27, 2019 [Page 25] Internet-Draft AN Reference Model November 2018 9.1. Protection Against Outsider Attacks Here, we assume that all systems involved in an autonomic network are secured and operated according to best current practices. These protection methods comprise traditional security implementation and operation methods (such as code security, strong randomization algorithms, strong passwords, etc.) as well as mechanisms specific to an autonomic network (such as a secured MASA service). Traditional security methods for both implementation and operation are outside scope for this document. AN specific protocols and methods must also follow traditional security methods, in that all packets that can be sniffed or injected by an outside attacker are: o protected against modification. o authenticated. o protected against replay attacks. o confidentiality protected (encrypted). o and that the AN protocols are robust against packet drops and man- in-the-middle attacks. How these requirements are met is covered in the AN standards track documents that define the methods used, specifically [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], and [I-D.ietf-anima-autonomic-control-plane]. Most AN messages run inside the cryptographically protected ACP. The unprotected AN messages outside the ACP are limited to a simple discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]: The "Discovery Unsolicited Link-Local (DULL)" message, with detailed rules on its usage. If AN messages can be observed by a third party, they might reveal valuable information about network configuration, security precautions in use, individual users, and their traffic patterns. If encrypted, AN messages might still reveal some information via traffic analysis. Behringer, et al. Expires May 27, 2019 [Page 26] Internet-Draft AN Reference Model November 2018 9.2. Risk of Insider Attacks An autonomic network consists of autonomic devices that form a distributed self-managing system. Devices within a domain have credentials issued from a common trust anchor and can use them to create mutual trust. This means that any device inside a trust domain can by default use all distributed functions in the entire autonomic domain in a malicious way. If an autonomic node or protocol has vulnerabilities or is not securely operated, an outside attacker has the following generic ways to take control of an autonomic network: o Introducing a fake device into the trust domain, by subverting the authentication methods. This depends on the correct specification, implementation and operation of the AN protocols. o Subverting a device which is already part of a trust domain, and modifying its behavior. This threat is not specific to the solution discussed in this document, and applies to all network solutions. o Exploiting potentially yet unknown protocol vulnerabilities in the AN or other protocols. Also this is a generic threat that applies to all network solutions. The above threats are in principle comparable to other solutions: In the presence of design, implementation or operational errors, security is no longer guaranteed. However, the distributed nature of AN, specifically the Autonomic Control Plane, increases the threat surface significantly. For example, a compromised device may have full IP reachability to all other devices inside the ACP, and can use all AN methods and protocols. For the next phase of the ANIMA work it is therefore recommended to introduce a sub-domain security model, to reduce the attack surface and not expose a full domain to a potential intruder. Furthermore, additional security mechanisms on the ASA level should be considered for high-risk autonomic functions. 10. IANA Considerations This document requests no action by IANA. Behringer, et al. Expires May 27, 2019 [Page 27] Internet-Draft AN Reference Model November 2018 11. Acknowledgements Many people have provided feedback and input to this document: Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, Tianran Zhou and Christian Hopps. 12. Contributors Significant contributions to this document have been made by John Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia. 13. References 13.1. Normative References [I-D.ietf-anima-autonomic-control-plane] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Control Plane (ACP)", draft-ietf-anima-autonomic-control- plane-18 (work in progress), August 2018. [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, S., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-17 (work in progress), November 2018. [I-D.ietf-anima-grasp] Bormann, C., Carpenter, B., and B. Liu, "A Generic Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- grasp-15 (work in progress), July 2017. [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", December 2009, . 13.2. Informative References [I-D.carpenter-anima-asa-guidelines] Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre, "Guidelines for Autonomic Service Agents", draft- carpenter-anima-asa-guidelines-05 (work in progress), June 2018. [I-D.du-anima-an-intent] Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. Behringer, "ANIMA Intent Policy and Format", draft-du- anima-an-intent-05 (work in progress), February 2017. Behringer, et al. Expires May 27, 2019 [Page 28] Internet-Draft AN Reference Model November 2018 [I-D.ietf-anima-grasp-api] Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)", draft-ietf-anima-grasp-api-02 (work in progress), June 2018. [I-D.ietf-anima-prefix-management] Jiang, S., Du, Z., and B. Carpenter, "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", draft-ietf- anima-prefix-management-07 (work in progress), December 2017. [I-D.ietf-anima-stable-connectivity] Eckert, T. and M. Behringer, "Using Autonomic Control Plane for Stable Connectivity of Network OAM", draft-ietf- anima-stable-connectivity-10 (work in progress), February 2018. [I-D.ietf-supa-generic-policy-data-model] Halpern, J. and J. Strassner, "Generic Policy Data Model for Simplified Use of Policy Abstractions (SUPA)", draft- ietf-supa-generic-policy-data-model-04 (work in progress), June 2017. [I-D.liu-anima-grasp-distribution] Liu, B., Jiang, S., Xiao, X., Hecker, A., and Z. Despotovic, "Information Distribution in Autonomic Networking", draft-liu-anima-grasp-distribution-09 (work in progress), October 2018. [Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd edition)", Prentice-Hall, ISBN 978-0136291558, 1997. [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, . [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015, . Behringer, et al. Expires May 27, 2019 [Page 29] Internet-Draft AN Reference Model November 2018 Authors' Addresses Michael H. Behringer (editor) Email: Michael.H.Behringer@gmail.com Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand Email: brian.e.carpenter@gmail.com Toerless Eckert Futurewei Technologies Inc. 2330 Central Expy Santa Clara 95050 USA Email: tte@cs.fau.de Laurent Ciavaglia Nokia Villarceaux Nozay 91460 FR Email: laurent.ciavaglia@nokia.com Jeferson Campos Nobre University of Vale do Rio dos Sinos Av. Unisinos, 950 Sao Leopoldo 91501-970 Brazil Email: jcnobre@unisinos.br Behringer, et al. Expires May 27, 2019 [Page 30] ./draft-ietf-clue-framework-25.txt0000644000764400076440000055466312643774145016342 0ustar iustyiustyCLUE WG M. Duckworth, Ed. Internet Draft Polycom Intended status: Standards Track A. Pepperell Expires: July 8, 2016 Acano S. Wenger Vidyo January 8, 2016 Framework for Telepresence Multi-Streams draft-ietf-clue-framework-25.txt Abstract This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Duckworth et. al. Expires July 8, 2016 [Page 1] Internet-Draft CLUE Telepresence Framework January 2016 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....................................................4 3. Definitions....................................................4 4. Overview and Motivation........................................7 5. Description of the Framework/Model............................10 6. Spatial Relationships.........................................15 7. Media Captures and Capture Scenes.............................17 7.1. Media Captures...........................................17 7.1.1. Media Capture Attributes............................18 7.2. Multiple Content Capture.................................24 7.2.1. MCC Attributes......................................25 7.3. Capture Scene............................................30 7.3.1. Capture Scene attributes............................33 7.3.2. Capture Scene View attributes.......................33 7.4. Global View List.........................................34 8. Simultaneous Transmission Set Constraints.....................35 9. Encodings.....................................................37 9.1. Individual Encodings.....................................37 9.2. Encoding Group...........................................38 9.3. Associating Captures with Encoding Groups................39 10. Consumer's Choice of Streams to Receive from the Provider....40 10.1. Local preference........................................43 10.2. Physical simultaneity restrictions......................43 10.3. Encoding and encoding group limits......................43 11. Extensibility................................................44 12. Examples - Using the Framework (Informative).................44 12.1. Provider Behavior.......................................44 12.1.1. Three screen Endpoint Provider.....................44 12.1.2. Encoding Group Example.............................51 12.1.3. The MCU Case.......................................52 Duckworth et. al. Expires July 8, 2016 [Page 2] Internet-Draft CLUE Telepresence Framework January 2016 12.2. Media Consumer Behavior.................................53 12.2.1. One screen Media Consumer..........................53 12.2.2. Two screen Media Consumer configuring the example..54 12.2.3. Three screen Media Consumer configuring the example55 12.3. Multipoint Conference utilizing Multiple Content Captures55 12.3.1. Single Media Captures and MCC in the same Advertisement..............................................55 12.3.2. Several MCCs in the same Advertisement.............59 12.3.3. Heterogeneous conference with switching and composition................................................60 12.3.4. Heterogeneous conference with voice activated switching..................................................67 13. Acknowledgements.............................................70 14. IANA Considerations..........................................70 15. Security Considerations......................................70 16. Changes Since Last Version...................................73 17. Normative References.........................................81 18. Informative References.......................................82 19. Authors' Addresses...........................................83 1. Introduction Current telepresence systems, though based on open standards such as RTP [RFC3550] and SIP [RFC3261], cannot easily interoperate with each other. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of multiple audio and video streams comprising the media flows. This document provides a framework for protocols to enable interoperability by handling multiple streams in a standardized way. The framework is intended to support the use cases described in Use Cases for Telepresence Multistreams [RFC7205] and to meet the requirements in Requirements for Telepresence Multistreams [RFC7262]. This includes cases using multiple media streams that are not necessarily telepresence. This document occasionally refers to the term "CLUE", in capital letters. CLUE is an acronym for "ControLling mUltiple streams for tElepresence", which is the name of the IETF working group in which this document and certain companion documents have been developed. Often, CLUE-something refers to something that has been designed by the CLUE working group; for example, this document may be called the CLUE-framework. Duckworth et. al. Expires July 8, 2016 [Page 3] Internet-Draft CLUE Telepresence Framework January 2016 The basic session setup for the use cases is based on SIP [RFC3261] and SDP offer/answer [RFC3264]. In addition to basic SIP & SDP offer/answer, CLUE specific signaling is required to exchange the information describing the multiple media streams. The motivation for this framework, an overview of the signaling, and information required to be exchanged is described in subsequent sections of this document. Companion documents describe the signaling details [I-D.ietf-clue-signaling] and the data model [I-D.ietf-clue-data- model-schema] and protocol [I-D.ietf-clue-protocol]. 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 RFC 2119 [RFC2119]. 3. Definitions The terms defined below are used throughout this document and companion documents. In order to easily identify the use of a defined term, those terms are capitalized. Advertisement: a CLUE message a Media Provider sends to a Media Consumer describing specific aspects of the content of the media, and any restrictions it has in terms of being able to provide certain Streams simultaneously. Audio Capture: Media Capture for audio. Denoted as ACn in the examples in this document. Capture: Same as Media Capture. Capture Device: A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder. Capture Encoding: A specific encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP. Duckworth et. al. Expires July 8, 2016 [Page 4] Internet-Draft CLUE Telepresence Framework January 2016 Capture Scene: a structure representing a spatial region captured by one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a Capture Scene may correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures. Capture Scene View (CSV): a list of Media Captures of the same media type that together form one way to represent the entire Capture Scene. CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- protocol] and the principles of CLUE negotiation, and seeks CLUE- enabled calls. CLUE-enabled call: A call in which two CLUE-capable devices have successfully negotiated support for a CLUE data channel in SDP [RFC4566]. A CLUE-enabled call is not necessarily immediately able to send CLUE-controlled media; negotiation of the data channel and of the CLUE protocol must complete first. Calls between two CLUE- capable devices which have not yet successfully completed negotiation of support for the CLUE data channel in SDP are not considered CLUE- enabled. Conference: used as defined in [RFC4353], A Framework for Conferencing within the Session Initiation Protocol (SIP). Configure Message: A CLUE message a Media Consumer sends to a Media Provider specifying which content and Media Streams it wants to receive, based on the information in a corresponding Advertisement message. Consumer: short for Media Consumer. Encoding: short for Individual Encoding. Encoding Group: A set of encoding parameters representing a total media encoding capability to be sub-divided across potentially multiple Individual Encodings. Endpoint: A CLUE-capable device which is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices Duckworth et. al. Expires July 8, 2016 [Page 5] Internet-Draft CLUE Telepresence Framework January 2016 which source and sink media streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. Global View: A set of references to one or more Capture Scene Views of the same media type that are defined within Scenes of the same advertisement. A Global View is a suggestion from the Provider to the Consumer for one set of CSVs that provide a useful representation of all the scenes in the advertisement. Global View List: A list of Global Views included in an Advertisement. A Global View List may include Global Views of different media types. Individual Encoding: a set of parameters representing a way to encode a Media Capture to become a Capture Encoding. Multipoint Control Unit (MCU): a CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC5117]. An MCU includes an [RFC4353]-like Mixer, without the [RFC4353] requirement to send media to each participant. Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. Media Capture: a source of Media, such as from one or more Capture Devices or constructed from other Media streams. Media Consumer: a CLUE-capable device that intends to receive Capture Encodings. Media Provider: a CLUE-capable device that intends to send Capture Encodings. Multiple Content Capture (MCC): A Capture that mixes and/or switches other Captures of a single type. (E.g. all audio or all video.) Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as MCCn in the example cases in this document. Plane of Interest: The spatial plane within a scene containing the most relevant subject matter. Duckworth et. al. Expires July 8, 2016 [Page 6] Internet-Draft CLUE Telepresence Framework January 2016 Provider: Same as Media Provider. Render: the process of generating a representation from media, such as displayed motion video or sound emitted from loudspeakers. Scene: Same as Capture Scene Simultaneous Transmission Set: a set of Media Captures that can be transmitted simultaneously from a Media Provider. Single Media Capture: A capture which contains media from a single source capture device, e.g. an audio capture from a single microphone, a video capture from a single camera. Spatial Relation: The arrangement in space of two objects, in contrast to relation in time or other relationships. Stream: a Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550]. Stream Characteristics: the media stream attributes commonly used in non-CLUE SIP/SDP environments (such as: media codec, bit rate, resolution, profile/level etc.) as well as CLUE specific attributes, such as the Capture ID or a spatial location. Video Capture: Media Capture for video. Denoted as VCn in the example cases in this document. Video Composite: A single image that is formed, normally by an RTP mixer inside an MCU, by combining visual elements from separate sources. 4. Overview and Motivation This section provides an overview of the functional elements defined in this document to represent a telepresence or multistream system. The motivations for the framework described in this document are also provided. Two key concepts introduced in this document are the terms "Media Provider" and "Media Consumer". A Media Provider represents the entity that sends the media and a Media Consumer represents the entity that receives the media. A Media Provider provides Media in the form of RTP packets, a Media Consumer consumes those RTP packets. Media Providers and Media Consumers can reside in Duckworth et. al. Expires July 8, 2016 [Page 7] Internet-Draft CLUE Telepresence Framework January 2016 Endpoints or in Multipoint Control Units (MCUs). A Media Provider in an Endpoint is usually associated with the generation of media for Media Captures; these Media Captures are typically sourced from cameras, microphones, and the like. Similarly, the Media Consumer in an Endpoint is usually associated with renderers, such as screens and loudspeakers. In MCUs, Media Providers and Consumers can have the form of outputs and inputs, respectively, of RTP mixers, RTP translators, and similar devices. Typically, telepresence devices such as Endpoints and MCUs would perform as both Media Providers and Media Consumers, the former being concerned with those devices' transmitted media and the latter with those devices' received media. In a few circumstances, a CLUE-capable device includes only Consumer or Provider functionality, such as recorder-type Consumers or webcam-type Providers. The motivations for the framework outlined in this document include the following: (1) Endpoints in telepresence systems typically have multiple Media Capture and Media Render devices, e.g., multiple cameras and screens. While previous system designs were able to set up calls that would capture media using all cameras and display media on all screens, for example, there was no mechanism that could associate these Media Captures with each other in space and time, in a cross- vendor interoperable way. (2) The mere fact that there are multiple capturing and rendering devices, each of which may be configurable in aspects such as zoom, leads to the difficulty that a variable number of such devices can be used to capture different aspects of a region. The Capture Scene concept allows for the description of multiple setups for those multiple capture devices that could represent sensible operation points of the physical capture devices in a room, chosen by the operator. A Consumer can pick and choose from those configurations based on its rendering abilities and inform the Provider about its choices. Details are provided in section 7. (3) In some cases, physical limitations or other reasons disallow the concurrent use of a device in more than one setup. For example, the center camera in a typical three-camera conference room can set its zoom objective either to capture only the middle few seats, or all seats of a room, but not both concurrently. The Simultaneous Transmission Set concept allows a Provider to signal Duckworth et. al. Expires July 8, 2016 [Page 8] Internet-Draft CLUE Telepresence Framework January 2016 such limitations. Simultaneous Transmission Sets are part of the Capture Scene description, and are discussed in section 8. (4) Often, the devices in a room do not have the computational complexity or connectivity to deal with multiple encoding options simultaneously, even if each of these options is sensible in certain scenarios, and even if the simultaneous transmission is also sensible (i.e. in case of multicast media distribution to multiple endpoints). Such constraints can be expressed by the Provider using the Encoding Group concept, described in section 9. (5) Due to the potentially large number of RTP streams required for a Multimedia Conference involving potentially many Endpoints, each of which can have many Media Captures and media renderers, it has become common to multiplex multiple RTP streams onto the same transport address, so to avoid using the port number as a multiplexing point and the associated shortcomings such as NAT/firewall traversal. The large number of possible permutations of sensible options a Media Provider can make available to a Media Consumer makes a mechanism desirable that allows it to narrow down the number of possible options that a SIP offer/answer exchange has to consider. Such information is made available using protocol mechanisms specified in this document and companion documents. The Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages. Also, there are aspects of the control of both Endpoints and MCUs that dynamically change during the progress of a call, such as audio-level based screen switching, layout changes, and so on, which need to be conveyed. Note that these control aspects are complementary to those specified in traditional SIP based conference management such as BFCP. An exemplary call flow can be found in section 5. Finally, all this information needs to be conveyed, and the notion of support for it needs to be established. This is done by the negotiation of a "CLUE channel", a data channel negotiated early during the initiation of a call. An Endpoint or MCU that rejects the establishment of this data channel, by definition, does not support CLUE based mechanisms, whereas an Endpoint or MCU that accepts it is indicating support for CLUE as specified in this document and its companion documents. Duckworth et. al. Expires July 8, 2016 [Page 9] Internet-Draft CLUE Telepresence Framework January 2016 5. Description of the Framework/Model The CLUE framework specifies how multiple media streams are to be handled in a telepresence conference. A Media Provider (transmitting Endpoint or MCU) describes specific aspects of the content of the media and the media stream encodings it can send in an Advertisement; and the Media Consumer responds to the Media Provider by specifying which content and media streams it wants to receive in a Configure message. The Provider then transmits the asked-for content in the specified streams. This Advertisement and Configure typically occur during call initiation, after CLUE has been enabled in a call, but MAY also happen at any time throughout the call, whenever there is a change in what the Consumer wants to receive or (perhaps less common) the Provider can send. An Endpoint or MCU typically act as both Provider and Consumer at the same time, sending Advertisements and sending Configurations in response to receiving Advertisements. (It is possible to be just one or the other.) The data model [I-D.ietf-clue-data-model-schema]is based around two main concepts: a Capture and an Encoding. A Media Capture (MC), such as of type audio or video, has attributes to describe the content a Provider can send. Media Captures are described in terms of CLUE-defined attributes, such as spatial relationships and purpose of the capture. Providers tell Consumers which Media Captures they can provide, described in terms of the Media Capture attributes. A Provider organizes its Media Captures into one or more Capture Scenes, each representing a spatial region, such as a room. A Consumer chooses which Media Captures it wants to receive from the Capture Scenes. In addition, the Provider can send the Consumer a description of the Individual Encodings it can send in terms of identifiers which relate to items in SDP [RFC4566]. The Provider can also specify constraints on its ability to provide Media, and a sensible design choice for a Consumer is to take these into account when choosing the content and Capture Encodings it requests in the later offer/answer exchange. Some constraints are Duckworth et. al. Expires July 8, 2016 [Page 10] Internet-Draft CLUE Telepresence Framework January 2016 due to the physical limitations of devices--for example, a camera may not be able to provide zoom and non-zoom views simultaneously. Other constraints are system based, such as maximum bandwidth. The following diagram illustrates the information contained in an Advertisement. Duckworth et. al. Expires July 8, 2016 [Page 11] Internet-Draft CLUE Telepresence Framework January 2016 ................................................................... . Provider Advertisement +--------------------+ . . | Simultaneous Sets | . . +------------------------+ +--------------------+ . . | Capture Scene N | +--------------------+ . . +-+----------------------+ | | Global View List | . . | Capture Scene 2 | | +--------------------+ . . +-+----------------------+ | | +----------------------+ . . | Capture Scene 1 | | | | Encoding Group N | . . | +---------------+ | | | +-+--------------------+ | . . | | Attributes | | | | | Encoding Group 2 | | . . | +---------------+ | | | +-+--------------------+ | | . . | | | | | Encoding Group 1 | | | . . | +----------------+ | | | | parameters | | | . . | | V i e w s | | | | | bandwidth | | | . . | | +---------+ | | | | | +-------------------+| | | . . | | |Attribute| | | | | | | V i d e o || | | . . | | +---------+ | | | | | | E n c o d i n g s || | | . . | | | | | | | | Encoding 1 || | | . . | | View 1 | | | | | | || | | . . | | (list of MCs) | | |-+ | +-------------------+| | | . . | +----|-|--|------+ |-+ | | | | . . +---------|-|--|---------+ | +-------------------+| | | . . | | | | | A u d i o || | | . . | | | | | E n c o d i n g s || | | . . v | | | | Encoding 1 || | | . . +---------|--|--------+ | | || | | . . | Media Capture N |------>| +-------------------+| | | . . +-+---------v--|------+ | | | | | . . | Media Capture 2 | | | | |-+ . . +-+--------------v----+ |-------->| | | . . | Media Capture 1 | | | | |-+ . . | +----------------+ |---------->| | . . | | Attributes | | |_+ +----------------------+ . . | +----------------+ |_+ . . +---------------------+ . . . ................................................................... Figure 1: Advertisement Structure A very brief outline of the call flow used by a simple system (two Endpoints) in compliance with this document can be described as follows, and as shown in the following figure. Duckworth et. al. Expires July 8, 2016 [Page 12] Internet-Draft CLUE Telepresence Framework January 2016 +-----------+ +-----------+ | Endpoint1 | | Endpoint2 | +----+------+ +-----+-----+ | INVITE (BASIC SDP+CLUECHANNEL) | |--------------------------------->| | 200 0K (BASIC SDP+CLUECHANNEL)| |<---------------------------------| | ACK | |--------------------------------->| | | |<################################>| | BASIC MEDIA SESSION | |<################################>| | | | CONNECT (CLUE CTRL CHANNEL) | |=================================>| | ... | |<================================>| | CLUE CTRL CHANNEL ESTABLISHED | |<================================>| | | | ADVERTISEMENT 1 | |*********************************>| | ADVERTISEMENT 2 | |<*********************************| | | | CONFIGURE 1 | |<*********************************| | CONFIGURE 2 | |*********************************>| | | | REINVITE (UPDATED SDP) | |--------------------------------->| | 200 0K (UPDATED SDP)| |<---------------------------------| | ACK | |--------------------------------->| | | |<################################>| | UPDATED MEDIA SESSION | |<################################>| | | v v Figure 2: Basic Information Flow Duckworth et. al. Expires July 8, 2016 [Page 13] Internet-Draft CLUE Telepresence Framework January 2016 An initial offer/answer exchange establishes a basic media session, for example audio-only, and a CLUE channel between two Endpoints. With the establishment of that channel, the endpoints have consented to use the CLUE protocol mechanisms and, therefore, MUST adhere to the CLUE protocol suite as outlined herein. Over this CLUE channel, the Provider in each Endpoint conveys its characteristics and capabilities by sending an Advertisement as specified herein. The Advertisement is typically not sufficient to set up all media. The Consumer in the Endpoint receives the information provided by the Provider, and can use it for several purposes. It uses it, along with information from an offer/answer exchange, to construct a CLUE Configure message to tell the Provider what the Consumer wishes to receive. Also, the Consumer may use the information provided to tailor the SDP it is going to send during any following SIP offer/answer exchange, and its reaction to SDP it receives in that step. It is often a sensible implementation choice to do so. Spatial relationships associated with the Media can be included in the Advertisement, and it is often sensible for the Media Consumer to take those spatial relationships into account when tailoring the SDP. The Consumer can also limit the number of encodings it must set up resources to receive, and not waste resources on unwanted encodings, because it has the Provider's Advertisement information ahead of time to determine what it really wants to receive. The Consumer can also use the Advertisement information for local rendering decisions. This initial CLUE exchange is followed by an SDP offer/answer exchange that not only establishes those aspects of the media that have not been "negotiated" over CLUE, but has also the effect of setting up the media transmission itself, involving potentially security exchanges, ICE, and whatnot. This step is plain vanilla SIP. During the lifetime of a call, further exchanges MAY occur over the CLUE channel. In some cases, those further exchanges lead to a modified system behavior of Provider or Consumer (or both) without any other protocol activity such as further offer/answer exchanges. For example, a Configure Message requesting the Provider to place a different Capture source into a Capture Encoding, signaled over the CLUE channel, ought not to lead to heavy-handed mechanisms like SIP re-invites. However, in other cases, after the CLUE negotiation an additional offer/answer exchange becomes necessary. For example, Duckworth et. al. Expires July 8, 2016 [Page 14] Internet-Draft CLUE Telepresence Framework January 2016 if both sides decide to upgrade the call from a single screen to a multi-screen call and more bandwidth is required for the additional video channels compared to what was previously negotiated using offer/answer, a new O/A exchange is required. One aspect of the protocol outlined herein and specified in more detail in companion documents is that it makes available, to the Consumer, information regarding the Provider's capabilities to deliver Media, and attributes related to that Media such as their spatial relationship. The operation of the renderer inside the Consumer is unspecified in that it can choose to ignore some information provided by the Provider, and/or not render media streams available from the Provider (although the Consumer follows the CLUE protocol and, therefore, gracefully receives and responds to the Provider's information using a Configure operation). A CLUE-capable device interoperates with a device that does not support CLUE. The CLUE-capable device can determine, by the result of the initial offer/answer exchange, if the other device supports and wishes to use CLUE. The specific mechanism for this is described in [I-D.ietf-clue-signaling]. If the other device does not use CLUE, then the CLUE-capable device falls back to behavior that does not require CLUE. As for the media, Provider and Consumer have an end-to-end communication relationship with respect to (RTP transported) media; and the mechanisms described herein and in companion documents do not change the aspects of setting up those RTP flows and sessions. In other words, the RTP media sessions conform to the negotiated SDP whether or not CLUE is used. 6. Spatial Relationships In order for a Consumer to perform a proper rendering, it is often necessary or at least helpful for the Consumer to have received spatial information about the streams it is receiving. CLUE defines a coordinate system that allows Media Providers to describe the spatial relationships of their Media Captures to enable proper scaling and spatially sensible rendering of their streams. The coordinate system is based on a few principles: o Each Capture Scene has a distinct coordinate system, unrelated to the coordinate systems of other scenes. Duckworth et. al. Expires July 8, 2016 [Page 15] Internet-Draft CLUE Telepresence Framework January 2016 o Simple systems which do not have multiple Media Captures to associate spatially need not use the coordinate model, although it can still be useful to provide an Area of Capture. o Coordinates can be either in real, physical units (millimeters), have an unknown scale or have no physical scale. Systems which know their physical dimensions (for example professionally installed Telepresence room systems) MUST provide those real- world measurements to enable the best user experience for advanced receiving systems that can utilize this information. Systems which don't know specific physical dimensions but still know relative distances MUST use 'unknown scale'. 'No scale' is intended to be used only where Media Captures from different devices (with potentially different scales) will be forwarded alongside one another (e.g. in the case of an MCU). * "Millimeters" means the scale is in millimeters. * "Unknown" means the scale is not necessarily millimeters, but the scale is the same for every Capture in the Capture Scene. * "No Scale" means the scale could be different for each capture- an MCU Provider that advertises two adjacent captures and picks sources (which can change quickly) from different endpoints might use this value; the scale could be different and changing for each capture. But the areas of capture still represent a spatial relation between captures. o The coordinate system is right-handed Cartesian X, Y, Z with the origin at a spatial location of the Provider's choosing. The Provider MUST use the same coordinate system with the same scale and origin for all coordinates within the same Capture Scene. The direction of increasing coordinate values is: X increases from left to right, from the point of view of an observer at the front of the room looking toward the back Y increases from the front of the room to the back of the room Z increases from low to high (i.e. floor to ceiling) Cameras in a scene typically point in the direction of increasing Y, from front to back. But there could be multiple cameras pointing in different directions. If the physical space does not have a well-defined front and back, the provider chooses any direction for X and Y and Z consistent with right-handed coordinates. Duckworth et. al. Expires July 8, 2016 [Page 16] Internet-Draft CLUE Telepresence Framework January 2016 7. Media Captures and Capture Scenes This section describes how Providers can describe the content of media to Consumers. 7.1. Media Captures Media Captures are the fundamental representations of streams that a device can transmit. What a Media Capture actually represents is flexible: o It can represent the immediate output of a physical source (e.g. camera, microphone) or 'synthetic' source (e.g. laptop computer, DVD player) o It can represent the output of an audio mixer or video composer o It can represent a concept such as 'the loudest speaker' o It can represent a conceptual position such as 'the leftmost stream' To identify and distinguish between multiple Capture instances Captures have a unique identity. For instance: VC1, VC2 and AC1, AC2, where VC1 and VC2 refer to two different video captures and AC1 and AC2 refer to two different audio captures. Some key points about Media Captures: . A Media Capture is of a single media type (e.g. audio or video) . A Media Capture is defined in a Capture Scene and is given an Advertisement unique identity. The identity may be referenced outside the Capture Scene that defines it through a Multiple Content Capture (MCC) . A Media Capture may be associated with one or more Capture Scene Views . A Media Capture has exactly one set of spatial information . A Media Capture can be the source of at most one Capture Encoding Each Media Capture can be associated with attributes to describe what it represents. Duckworth et. al. Expires July 8, 2016 [Page 17] Internet-Draft CLUE Telepresence Framework January 2016 7.1.1. Media Capture Attributes Media Capture Attributes describe information about the Captures. A Provider can use the Media Capture Attributes to describe the Captures for the benefit of the Consumer of the Advertisement message. All these attributes are optional. Media Capture Attributes include: . Spatial information, such as point of capture, point on line of capture, and area of capture, all of which, in combination define the capture field of, for example, a camera . Other descriptive information to help the Consumer choose between captures (e.g. description, presentation, view, priority, language, person information and type) The sub-sections below define the Capture attributes. 7.1.1.1. Point of Capture The Point of Capture attribute is a field with a single Cartesian (X, Y, Z) point value which describes the spatial location of the capturing device (such as camera). For an Audio Capture with multiple microphones, the Point of Capture defines the nominal mid- point of the microphones. 7.1.1.2. Point on Line of Capture The Point on Line of Capture attribute is a field with a single Cartesian (X, Y, Z) point value which describes a position in space of a second point on the axis of the capturing device, toward the direction it is pointing; the first point being the Point of Capture (see above). Together, the Point of Capture and Point on Line of Capture define the direction and axis of the capturing device, for example the optical axis of a camera or the axis of a microphone. The Media Consumer can use this information to adjust how it renders the received media if it so chooses. For an Audio Capture, the Media Consumer can use this information along with the Audio Capture Sensitivity Pattern to define a 3- dimensional volume of capture where sounds can be expected to be picked up by the microphone providing this specific audio capture. If the Consumer wants to associate an Audio Capture with a Video Capture, it can compare this volume with the area of capture for Duckworth et. al. Expires July 8, 2016 [Page 18] Internet-Draft CLUE Telepresence Framework January 2016 video media to provide a check on whether the audio capture is indeed spatially associated with the video capture. For example, a video area of capture that fails to intersect at all with the audio volume of capture, or is at such a long radial distance from the microphone point of capture that the audio level would be very low, would be inappropriate. 7.1.1.3. Area of Capture The Area of Capture is a field with a set of four (X, Y, Z) points as a value which describes the spatial location of what is being "captured". This attribute applies only to video captures, not other types of media. By comparing the Area of Capture for different Video Captures within the same Capture Scene a Consumer can determine the spatial relationships between them and render them correctly. The four points MUST be co-planar, forming a quadrilateral, which defines the Plane of Interest for the particular Media Capture. If the Area of Capture is not specified, it means the Video Capture might be spatially related to other Captures in the same Scene, but there is no detailed information on the relationship.For a switched Capture that switches between different sections within a larger area, the area of capture MUST use coordinates for the larger potential area. 7.1.1.4. Mobility of Capture The Mobility of Capture attribute indicates whether or not the point of capture, line on point of capture, and area of capture values stay the same over time, or are expected to change (potentially frequently). Possible values are static, dynamic, and highly dynamic. An example for "dynamic" is a camera mounted on a stand which is occasionally hand-carried and placed at different positions in order to provide the best angle to capture a work task. A camera worn by a person who moves around the room is an example for "highly dynamic". In either case, the effect is that the capture point, capture axis and area of capture change with time. The capture point of a static Capture MUST NOT move for the life of the CLUE session. The capture point of dynamic Captures is categorized by a change in position followed by a reasonable period Duckworth et. al. Expires July 8, 2016 [Page 19] Internet-Draft CLUE Telepresence Framework January 2016 of stability--in the order of magnitude of minutes. Highly dynamic captures are categorized by a capture point that is constantly moving. If the "area of capture", "capture point" and "line of capture" attributes are included with dynamic or highly dynamic Captures they indicate spatial information at the time of the Advertisement. 7.1.1.5. Audio Capture Sensitivity Pattern The Audio Capture Sensitivity Pattern attribute applies only to audio captures. This attribute gives information about the nominal sensitivity pattern of the microphone which is the source of the Capture. Possible values include patterns such as omni, shotgun, cardioid, hyper-cardioid. 7.1.1.6. Description The Description attribute is a human-readable description (which could be in multiple languages) of the Capture. 7.1.1.7. Presentation The Presentation attribute indicates that the capture originates from a presentation device, that is one that provides supplementary information to a conference through slides, video, still images, data etc. Where more information is known about the capture it MAY be expanded hierarchically to indicate the different types of presentation media, e.g. presentation.slides, presentation.image etc. Note: It is expected that a number of keywords will be defined that provide more detail on the type of presentation. Refer to [I- D.ietf-clue-data-model-schema] for how to extend the model. 7.1.1.8. View The View attribute is a field with enumerated values, indicating what type of view the Capture relates to. The Consumer can use this information to help choose which Media Captures it wishes to receive. Possible values are: Room - Captures the entire scene Table - Captures the conference table with seated people Duckworth et. al. Expires July 8, 2016 [Page 20] Internet-Draft CLUE Telepresence Framework January 2016 Individual - Captures an individual person Lectern - Captures the region of the lectern including the presenter, for example in a classroom style conference room Audience - Captures a region showing the audience in a classroom style conference room 7.1.1.9. Language The Language attribute indicates one or more languages used in the content of the Media Capture. Captures MAY be offered in different languages in case of multilingual and/or accessible conferences. A Consumer can use this attribute to differentiate between them and pick the appropriate one. Note that the Language attribute is defined and meaningful both for audio and video captures. In case of audio captures, the meaning is obvious. For a video capture, "Language" could, for example, be sign interpretation or text. The Language attribute is coded per [RFC5646]. 7.1.1.10. Person Information The Person Information attribute allows a Provider to provide specific information regarding the people in a Capture (regardless of whether or not the capture has a Presentation attribute). The Provider may gather the information automatically or manually from a variety of sources however the xCard [RFC6351] format is used to convey the information. This allows various information such as Identification information (section 6.2/[RFC6350]), Communication Information (section 6.4/[RFC6350]) and Organizational information (section 6.6/[RFC6350]) to be communicated. A Consumer may then automatically (i.e. via a policy) or manually select Captures based on information about who is in a Capture. It also allows a Consumer to render information regarding the people participating in the conference or to use it for further processing. The Provider may supply a minimal set of information or a larger set of information. However it MUST be compliant to [RFC6350] and supply a "VERSION" and "FN" property. A Provider may supply multiple xCards per Capture of any KIND (section 6.1.4/[RFC6350]). Duckworth et. al. Expires July 8, 2016 [Page 21] Internet-Draft CLUE Telepresence Framework January 2016 In order to keep CLUE messages compact the Provider SHOULD use a URI to point to any LOGO, PHOTO or SOUND contained in the xCARD rather than transmitting the LOGO, PHOTO or SOUND data in a CLUE message. 7.1.1.11. Person Type The Person Type attribute indicates the type of people contained in the capture with respect to the meeting agenda (regardless of whether or not the capture has a Presentation attribute). As a capture may include multiple people the attribute may contain multiple values. However values MUST NOT be repeated within the attribute. An Advertiser associates the person type with an individual capture when it knows that a particular type is in the capture. If an Advertiser cannot link a particular type with some certainty to a capture then it is not included. A Consumer on reception of a capture with a person type attribute knows with some certainly that the capture contains that person type. The capture may contain other person types but the Advertiser has not been able to determine that this is the case. The types of Captured people include: . Chair - the person responsible for running the meeting according to the agenda. . Vice-Chair - the person responsible for assisting the chair in running the meeting. . Minute Taker - the person responsible for recording the minutes of the meeting. . Attendee - the person has no particular responsibilities with respect to running the meeting. . Observer - an Attendee without the right to influence the discussion. . Presenter - the person is scheduled on the agenda to make a presentation in the meeting. Note: This is not related to any "active speaker" functionality. . Translator - the person is providing some form of translation or commentary in the meeting. . Timekeeper - the person is responsible for maintaining the meeting schedule. Duckworth et. al. Expires July 8, 2016 [Page 22] Internet-Draft CLUE Telepresence Framework January 2016 Furthermore the person type attribute may contain one or more strings allowing the Provider to indicate custom meeting specific types. 7.1.1.12. Priority The Priority attribute indicates a relative priority between different Media Captures. The Provider sets this priority, and the Consumer MAY use the priority to help decide which Captures it wishes to receive. The "priority" attribute is an integer which indicates a relative priority between Captures. For example it is possible to assign a priority between two presentation Captures that would allow a remote Endpoint to determine which presentation is more important. Priority is assigned at the individual Capture level. It represents the Provider's view of the relative priority between Captures with a priority. The same priority number MAY be used across multiple Captures. It indicates they are equally important. If no priority is assigned no assumptions regarding relative importance of the Capture can be assumed. 7.1.1.13. Embedded Text The Embedded Text attribute indicates that a Capture provides embedded textual information. For example the video Capture may contain speech to text information composed with the video image. 7.1.1.14. Related To The Related To attribute indicates the Capture contains additional complementary information related to another Capture. The value indicates the identity of the other Capture to which this Capture is providing additional information. For example, a conference can utilize translators or facilitators that provide an additional audio stream (i.e. a translation or description or commentary of the conference). Where multiple captures are available, it may be advantageous for a Consumer to select a complementary Capture instead of or in addition to a Capture it relates to. Duckworth et. al. Expires July 8, 2016 [Page 23] Internet-Draft CLUE Telepresence Framework January 2016 7.2. Multiple Content Capture The MCC indicates that one or more Single Media Captures are multiplexed (temporally and/or spatially) or mixed in one Media Capture. Only one Capture type (i.e. audio, video, etc.) is allowed in each MCC instance. The MCC may contain a reference to the Single Media Captures (which may have their own attributes) as well as attributes associated with the MCC itself. A MCC may also contain other MCCs. The MCC MAY reference Captures from within the Capture Scene that defines it or from other Capture Scenes. No ordering is implied by the order that Captures appear within a MCC. A MCC MAY contain no references to other Captures to indicate that the MCC contains content from multiple sources but no information regarding those sources is given. MCCs either contain the referenced Captures and no others, or have no referenced captures and therefore may contain any Capture. One or more MCCs may also be specified in a CSV. This allows an Advertiser to indicate that several MCC captures are used to represent a capture scene. Table 14 provides an example of this case. As outlined in section 7.1. each instance of the MCC has its own Capture identity i.e. MCC1. It allows all the individual captures contained in the MCC to be referenced by a single MCC identity. The example below shows the use of a Multiple Content Capture: +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | {MC attributes} | | VC2 | {MC attributes} | | VC3 | {MC attributes} | | MCC1(VC1,VC2,VC3) | {MC and MCC attributes} | | CSV(MCC1) | | +---------------------------------------------------------+ Table 1: Multiple Content Capture concept This indicates that MCC1 is a single capture that contains the Captures VC1, VC2 and VC3 according to any MCC1 attributes. Duckworth et. al. Expires July 8, 2016 [Page 24] Internet-Draft CLUE Telepresence Framework January 2016 7.2.1. MCC Attributes Media Capture Attributes may be associated with the MCC instance and the Single Media Captures that the MCC references. A Provider should avoid providing conflicting attribute values between the MCC and Single Media Captures. Where there is conflict the attributes of the MCC override any that may be present in the individual Captures. A Provider MAY include as much or as little of the original source Capture information as it requires. There are MCC specific attributes that MUST only be used with Multiple Content Captures. These are described in the sections below. The attributes described in section 7.1.1. MAY also be used with MCCs. The spatial related attributes of an MCC indicate its area of capture and point of capture within the scene, just like any other media capture. The spatial information does not imply anything about how other captures are composed within an MCC. For example: A virtual scene could be constructed for the MCC capture with two Video Captures with a "MaxCaptures" attribute set to 2 and an "Area of Capture" attribute provided with an overall area. Each of the individual Captures could then also include an "Area of Capture" attribute with a sub-set of the overall area. The Consumer would then know how each capture is related to others within the scene, but not the relative position of the individual captures within the composed capture. +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | AreaofCapture=(0,0,0)(9,0,0) | | | (0,0,9)(9,0,9) | | VC2 | AreaofCapture=(10,0,0)(19,0,0) | | | (10,0,9)(19,0,9) | | MCC1(VC1,VC2) | MaxCaptures=2 | | | AreaofCapture=(0,0,0)(19,0,0) | | | (0,0,9)(19,0,9) | | CSV(MCC1) | | +---------------------------------------------------------+ Table 2: Example of MCC and Single Media Capture attributes Duckworth et. al. Expires July 8, 2016 [Page 25] Internet-Draft CLUE Telepresence Framework January 2016 The sub-sections below describe the MCC only attributes. 7.2.1.1. Maximum Number of Captures within a MCC The Maximum Number of Captures MCC attribute indicates the maximum number of individual Captures that may appear in a Capture Encoding at a time. The actual number at any given time can be less than or equal to this maximum. It may be used to derive how the Single Media Captures within the MCC are composed / switched with regards to space and time. A Provider can indicate that the number of Captures in a MCC Capture Encoding is equal "=" to the MaxCaptures value or that there may be any number of Captures up to and including "<=" the MaxCaptures value. This allows a Provider to distinguish between a MCC that purely represents a composition of sources versus a MCC that represents switched or switched and composed sources. MaxCaptures may be set to one so that only content related to one of the sources are shown in the MCC Capture Encoding at a time or it may be set to any value up to the total number of Source Media Captures in the MCC. The bullets below describe how the setting of MaxCapture versus the number of Captures in the MCC affects how sources appear in a Capture Encoding: . When MaxCaptures is set to <= 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC this is a switched case. Zero or 1 Captures may be switched into the Capture Encoding. Note: zero is allowed because of the "<=". . When MaxCaptures is set to = 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC this is a switched case. Only one Capture source is contained in a Capture Encoding at a time. . When MaxCaptures is set to <= N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified) this is a switched and composed case. The Capture Encoding may contain purely switched sources (i.e. <=2 allows for 1 source on its own), or may contain composed and switched sources (i.e. a composition of 2 sources switched between the sources). . When MaxCaptures is set to = N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified) this Duckworth et. al. Expires July 8, 2016 [Page 26] Internet-Draft CLUE Telepresence Framework January 2016 is a switched and composed case. The Capture Encoding contains composed and switched sources (i.e. a composition of N sources switched between the sources). It is not possible to have a single source. . When MaxCaptures is set to <= to the number of Captures in the MCC this is a switched and composed case. The Capture Encoding may contain media switched between any number (up to the MaxCaptures) of composed sources. . When MaxCaptures is set to = to the number of Captures in the MCC this is a composed case. All the sources are composed into a single Capture Encoding. If this attribute is not set then as default it is assumed that all source media capture content can appear concurrently in the Capture Encoding associated with the MCC. For example: The use of MaxCaptures equal to 1 on a MCC with three Video Captures VC1, VC2 and VC3 would indicate that the Advertiser in the Capture Encoding would switch between VC1, VC2 or VC3 as there may be only a maximum of one Capture at a time. 7.2.1.2. Policy The Policy MCC Attribute indicates the criteria that the Provider uses to determine when and/or where media content appears in the Capture Encoding related to the MCC. The attribute is in the form of a token that indicates the policy and an index representing an instance of the policy. The same index value can be used for multiple MCCs. The tokens are: SoundLevel - This indicates that the content of the MCC is determined by a sound level detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC. RoundRobin - This indicates that the content of the MCC is determined by a time based algorithm. For example: the Provider provides content from a particular source for a period of time and then provides content from another source and so on. An index is used to represent an instance in the policy setting. An index of 0 represents the most current instance of the policy, i.e. Duckworth et. al. Expires July 8, 2016 [Page 27] Internet-Draft CLUE Telepresence Framework January 2016 the active speaker, 1 represents the previous instance, i.e. the previous active speaker and so on. The following example shows a case where the Provider provides two media streams, one showing the active speaker and a second stream showing the previous speaker. +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | | | VC2 | | | MCC1(VC1,VC2) | Policy=SoundLevel:0 | | | MaxCaptures=1 | | MCC2(VC1,VC2) | Policy=SoundLevel:1 | | | MaxCaptures=1 | | CSV(MCC1,MCC2) | | +---------------------------------------------------------+ Table 3: Example Policy MCC attribute usage 7.2.1.3. Synchronisation Identity The Synchronisation Identity MCC attribute indicates how the individual Captures in multiple MCC Captures are synchronised. To indicate that the Capture Encodings associated with MCCs contain Captures from the same source at the same time a Provider should set the same Synchronisation Identity on each of the concerned MCCs. It is the Provider that determines what the source for the Captures is, so a Provider can choose how to group together Single Media Captures into a combined "source" for the purpose of switching them together to keep them synchronized according to the SynchronisationID attribute. For example when the Provider is in an MCU it may determine that each separate CLUE Endpoint is a remote source of media. The Synchronisation Identity may be used across media types, i.e. to synchronize audio and video related MCCs. Without this attribute it is assumed that multiple MCCs may provide content from different sources at any particular point in time. For example: Duckworth et. al. Expires July 8, 2016 [Page 28] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | VC1 | Description=Left | | VC2 | Description=Centre | | VC3 | Description=Right | | AC1 | Description=Room | | CSV(VC1,VC2,VC3) | | | CSV(AC1) | | +=======================+=================================+ | Capture Scene #2 | | +-----------------------|---------------------------------+ | VC4 | Description=Left | | VC5 | Description=Centre | | VC6 | Description=Right | | AC2 | Description=Room | | CSV(VC4,VC5,VC6) | | | CSV(AC2) | | +=======================+=================================+ | Capture Scene #3 | | +-----------------------|---------------------------------+ | VC7 | | | AC3 | | +=======================+=================================+ | Capture Scene #4 | | +-----------------------|---------------------------------+ | VC8 | | | AC4 | | +=======================+=================================+ | Capture Scene #5 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC4,VC7) | SynchronisationID=1 | | | MaxCaptures=1 | | MCC2(VC2,VC5,VC8) | SynchronisationID=1 | | | MaxCaptures=1 | | MCC3(VC3,VC6) | MaxCaptures=1 | | MCC4(AC1,AC2,AC3,AC4) | SynchronisationID=1 | | | MaxCaptures=1 | | CSV(MCC1,MCC2,MCC3) | | | CSV(MCC4) | | +=======================+=================================+ Table 4: Example Synchronisation Identity MCC attribute usage Duckworth et. al. Expires July 8, 2016 [Page 29] Internet-Draft CLUE Telepresence Framework January 2016 The above Advertisement would indicate that MCC1, MCC2, MCC3 and MCC4 make up a Capture Scene. There would be four Capture Encodings (one for each MCC). Because MCC1 and MCC2 have the same SynchronisationID, each Encoding from MCC1 and MCC2 respectively would together have content from only Capture Scene 1 or only Capture Scene 2 or the combination of VC7 and VC8 at a particular point in time. In this case the Provider has decided the sources to be synchronized are Scene #1, Scene #2, and Scene #3 and #4 together. The Encoding from MCC3 would not be synchronised with MCC1 or MCC2. As MCC4 also has the same Synchronisation Identity as MCC1 and MCC2 the content of the audio Encoding will be synchronised with the video content. 7.2.1.4. Allow Subset Choice The Allow Subset Choice MCC attribute is a boolean value, indicating whether or not the Provider allows the Consumer to choose a specific subset of the Captures referenced by the MCC. If this attribute is true, and the MCC references other Captures, then the Consumer MAY select (in a Configure message) a specific subset of those Captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other Captures, then the Consumer MUST NOT select a subset. 7.3. Capture Scene In order for a Provider's individual Captures to be used effectively by a Consumer, the Provider organizes the Captures into one or more Capture Scenes, with the structure and contents of these Capture Scenes being sent from the Provider to the Consumer in the Advertisement. A Capture Scene is a structure representing a spatial region containing one or more Capture Devices, each capturing media representing a portion of the region. A Capture Scene includes one or more Capture Scene Views (CSV), with each CSV including one or more Media Captures of the same media type. There can also be Media Captures that are not included in a Capture Scene View. A Capture Scene represents, for example, the video image of a group of people seated next to each other, along with the sound of their voices, which could be represented by some number of VCs and ACs in the Capture Scene Views. An MCU can also describe in Capture Scenes what it constructs from media Streams it receives. Duckworth et. al. Expires July 8, 2016 [Page 30] Internet-Draft CLUE Telepresence Framework January 2016 A Provider MAY advertise one or more Capture Scenes. What constitutes an entire Capture Scene is up to the Provider. A simple Provider might typically use one Capture Scene for participant media (live video from the room cameras) and another Capture Scene for a computer generated presentation. In more complex systems, the use of additional Capture Scenes is also sensible. For example, a classroom may advertise two Capture Scenes involving live video, one including only the camera capturing the instructor (and associated audio), the other including camera(s) capturing students (and associated audio). A Capture Scene MAY (and typically will) include more than one type of media. For example, a Capture Scene can include several Capture Scene Views for Video Captures, and several Capture Scene Views for Audio Captures. A particular Capture MAY be included in more than one Capture Scene View. A Provider MAY express spatial relationships between Captures that are included in the same Capture Scene. However, there is no spatial relationship between Media Captures from different Capture Scenes. In other words, Capture Scenes each use their own spatial measurement system as outlined above in section 6. A Provider arranges Captures in a Capture Scene to help the Consumer choose which captures it wants to render. The Capture Scene Views in a Capture Scene are different alternatives the Provider is suggesting for representing the Capture Scene. Each Capture Scene View is given an advertisement unique identity. The order of Capture Scene Views within a Capture Scene has no significance. The Media Consumer can choose to receive all Media Captures from one Capture Scene View for each media type (e.g. audio and video), or it can pick and choose Media Captures regardless of how the Provider arranges them in Capture Scene Views. Different Capture Scene Views of the same media type are not necessarily mutually exclusive alternatives. Also note that the presence of multiple Capture Scene Views (with potentially multiple encoding options in each view) in a given Capture Scene does not necessarily imply that a Provider is able to serve all the associated media simultaneously (although the construction of such an over-rich Capture Scene is probably not sensible in many cases). What a Provider can send simultaneously is determined through the Simultaneous Transmission Set mechanism, described in section 8. Captures within the same Capture Scene View MUST be of the same media type - it is not possible to mix audio and video captures in Duckworth et. al. Expires July 8, 2016 [Page 31] Internet-Draft CLUE Telepresence Framework January 2016 the same Capture Scene View, for instance. The Provider MUST be capable of encoding and sending all Captures (that have an encoding group) in a single Capture Scene View simultaneously. The order of Captures within a Capture Scene View has no significance. A Consumer can decide to receive all the Captures in a single Capture Scene View, but a Consumer could also decide to receive just a subset of those captures. A Consumer can also decide to receive Captures from different Capture Scene Views, all subject to the constraints set by Simultaneous Transmission Sets, as discussed in section 8. When a Provider advertises a Capture Scene with multiple CSVs, it is essentially signaling that there are multiple representations of the same Capture Scene available. In some cases, these multiple views would be used simultaneously (for instance a "video view" and an "audio view"). In some cases the views would conceptually be alternatives (for instance a view consisting of three Video Captures covering the whole room versus a view consisting of just a single Video Capture covering only the center of a room). In this latter example, one sensible choice for a Consumer would be to indicate (through its Configure and possibly through an additional offer/answer exchange) the Captures of that Capture Scene View that most closely matched the Consumer's number of display devices or screen layout. The following is an example of 4 potential Capture Scene Views for an endpoint-style Provider: 1. (VC0, VC1, VC2) - left, center and right camera Video Captures 2. (MCC3) - Video Capture associated with loudest room segment 3. (VC4) - Video Capture zoomed out view of all people in the room 4. (AC0) - main audio The first view in this Capture Scene example is a list of Video Captures which have a spatial relationship to each other. Determination of the order of these captures (VC0, VC1 and VC2) for rendering purposes is accomplished through use of their Area of Capture attributes. The second view (MCC3) and the third view (VC4) are alternative representations of the same room's video, which might be better suited to some Consumers' rendering capabilities. The inclusion of the Audio Capture in the same Capture Scene indicates that AC0 is associated with all of those Duckworth et. al. Expires July 8, 2016 [Page 32] Internet-Draft CLUE Telepresence Framework January 2016 Video Captures, meaning it comes from the same spatial region. Therefore, if audio were to be rendered at all, this audio would be the correct choice irrespective of which Video Captures were chosen. 7.3.1. Capture Scene attributes Capture Scene Attributes can be applied to Capture Scenes as well as to individual media captures. Attributes specified at this level apply to all constituent Captures. Capture Scene attributes include . Human-readable description of the Capture Scene, which could be in multiple languages; . xCard scene information . Scale information (millimeters, unknown, no scale), as described in Section 6. 7.3.1.1. Scene Information The Scene information attribute provides information regarding the Capture Scene rather than individual participants. The Provider may gather the information automatically or manually from a variety of sources. The scene information attribute allows a Provider to indicate information such as: organizational or geographic information allowing a Consumer to determine which Capture Scenes are of interest in order to then perform Capture selection. It also allows a Consumer to render information regarding the Scene or to use it for further processing. As per 7.1.1.10. the xCard format is used to convey this information and the Provider may supply a minimal set of information or a larger set of information. In order to keep CLUE messages compact the Provider SHOULD use a URI to point to any LOGO, PHOTO or SOUND contained in the xCARD rather than transmitting the LOGO, PHOTO or SOUND data in a CLUE message. 7.3.2. Capture Scene View attributes A Capture Scene can include one or more Capture Scene Views in addition to the Capture Scene wide attributes described above. Capture Scene View attributes apply to the Capture Scene View as a Duckworth et. al. Expires July 8, 2016 [Page 33] Internet-Draft CLUE Telepresence Framework January 2016 whole, i.e. to all Captures that are part of the Capture Scene View. Capture Scene View attributes include: . Human-readable description (which could be in multiple languages) of the Capture Scene View 7.4. Global View List An Advertisement can include an optional Global View list. Each item in this list is a Global View. The Provider can include multiple Global Views, to allow a Consumer to choose sets of captures appropriate to its capabilities or application. The choice of how to make these suggestions in the Global View list for what represents all the scenes for which the Provider can send media is up to the Provider. This is very similar to how each CSV represents a particular scene. As an example, suppose an advertisement has three scenes, and each scene has three CSVs, ranging from one to three video captures in each CSV. The Provider is advertising a total of nine video Captures across three scenes. The Provider can use the Global View list to suggest alternatives for Consumers that can't receive all nine video Captures as separate media streams. For accommodating a Consumer that wants to receive three video Captures, a Provider might suggest a Global View containing just a single CSV with three Captures and nothing from the other two scenes. Or a Provider might suggest a Global View containing three different CSVs, one from each scene, with a single video Capture in each. Some additional rules: . The ordering of Global Views in the Global View list is insignificant. . The ordering of CSVs within each Global View is insignificant. . A particular CSV may be used in multiple Global Views. . The Provider must be capable of encoding and sending all Captures within the CSVs of a given Global View simultaneously. The following figure shows an example of the structure of Global Views in a Global View List. Duckworth et. al. Expires July 8, 2016 [Page 34] Internet-Draft CLUE Telepresence Framework January 2016 ........................................................ . Advertisement . . . . +--------------+ +-------------------------+ . . |Scene 1 | |Global View List | . . | | | | . . | CSV1 (v)<----------------- Global View (CSV 1) | . . | <-------. | | . . | | *--------- Global View (CSV 1,5) | . . | CSV2 (v) | | | | . . | | | | | . . | CSV3 (v)<---------*------- Global View (CSV 3,5) | . . | | | | | | . . | CSV4 (a)<----------------- Global View (CSV 4) | . . | <-----------. | | . . +--------------+ | | *----- Global View (CSV 4,6) | . . | | | | | . . +--------------+ | | | +-------------------------+ . . |Scene 2 | | | | . . | | | | | . . | CSV5 (v)<-------' | | . . | <---------' | . . | | | (v) = video . . | CSV6 (a)<-----------' (a) = audio . . | | . . +--------------+ . `......................................................' Figure 3: Global View List Structure 8. Simultaneous Transmission Set Constraints In many practical cases, a Provider has constraints or limitations on its ability to send Captures simultaneously. One type of limitation is caused by the physical limitations of capture mechanisms; these constraints are represented by a Simultaneous Transmission Set. The second type of limitation reflects the encoding resources available, such as bandwidth or video encoding throughput (macroblocks/second). This type of constraint is captured by Individual Encodings and Encoding Groups, discussed below. Some Endpoints or MCUs can send multiple Captures simultaneously; however sometimes there are constraints that limit which Captures can be sent simultaneously with other Captures. A device may not Duckworth et. al. Expires July 8, 2016 [Page 35] Internet-Draft CLUE Telepresence Framework January 2016 be able to be used in different ways at the same time. Provider Advertisements are made so that the Consumer can choose one of several possible mutually exclusive usages of the device. This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement. This is easier to show in an example. Consider the example of a room system where there are three cameras each of which can send a separate Capture covering two persons each- VC0, VC1, VC2. The middle camera can also zoom out (using an optical zoom lens) and show all six persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where two participants sit or the whole six seats, but not both at the same time. As a result, VC1 and VC3 cannot be sent simultaneously. Simultaneous Transmission Sets are expressed as sets of the Media Captures that the Provider could transmit at the same time (though, in some cases, it is not intuitive to do so). If a Multiple Content Capture is included in a Simultaneous Transmission Set it indicates that the Capture Encoding associated with it could be transmitted as the same time as the other Captures within the Simultaneous Transmission Set. It does not imply that the Single Media Captures contained in the Multiple Content Capture could all be transmitted at the same time. In this example the two Simultaneous Transmission Sets are shown in Table 5. If a Provider advertises one or more mutually exclusive Simultaneous Transmission Sets, then for each media type the Consumer MUST ensure that it chooses Media Captures that lie wholly within one of those Simultaneous Transmission Sets. +-------------------+ | Simultaneous Sets | +-------------------+ | {VC0, VC1, VC2} | | {VC0, VC3, VC2} | +-------------------+ Table 5: Two Simultaneous Transmission Sets A Provider OPTIONALLY can include the Simultaneous Transmission Sets in its Advertisement. These constraints apply across all the Duckworth et. al. Expires July 8, 2016 [Page 36] Internet-Draft CLUE Telepresence Framework January 2016 Capture Scenes in the Advertisement. It is a syntax conformance requirement that the Simultaneous Transmission Sets MUST allow all the media Captures in any particular Capture Scene View to be used simultaneously. Similarly, the Simultaneous Transmission Sets MUST reflect the simultaneity expressed by any Global View. For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of Capture Scene Views and Capture Scenes. If a Capture Scene View is included in a Simultaneous Transmission Set, then all Media Captures in the Capture Scene View are included in the Simultaneous Transmission Set. If a Capture Scene is included in a Simultaneous Transmission Set, then all its Capture Scene Views (of the corresponding media type) are included in the Simultaneous Transmission Set. The end result reduces to a set of Media Captures, of a particular media type, in either case. If an Advertisement does not include Simultaneous Transmission Sets, then the Provider MUST be able to simultaneously provide all the Captures from any one CSV of each media type from each Capture Scene. Likewise, if there are no Simultaneous Transmission Sets and there is a Global View list, then the Provider MUST be able to simultaneously provide all the Captures from any particular Global View (of each media type) from the Global View list. If an Advertisement includes multiple Capture Scene Views in a Capture Scene then the Consumer MAY choose one Capture Scene View for each media type, or MAY choose individual Captures based on the Simultaneous Transmission Sets. 9. Encodings Individual encodings and encoding groups are CLUE's mechanisms allowing a Provider to signal its limitations for sending Captures, or combinations of Captures, to a Consumer. Consumers can map the Captures they want to receive onto the Encodings, with the encoding parameters they want. As for the relationship between the CLUE- specified mechanisms based on Encodings and the SIP offer/answer exchange, please refer to section 5. 9.1. Individual Encodings An Individual Encoding represents a way to encode a Media Capture as a Capture Encoding, to be sent as an encoded media stream from the Provider to the Consumer. An Individual Encoding has a set of parameters characterizing how the media is encoded. Duckworth et. al. Expires July 8, 2016 [Page 37] Internet-Draft CLUE Telepresence Framework January 2016 Different media types have different parameters, and different encoding algorithms may have different parameters. An Individual Encoding can be assigned to at most one Capture Encoding at any given time. Individual Encoding parameters are represented in SDP [RFC4566], not in CLUE messages. For example, for a video encoding using H.26x compression technologies, this can include parameters such as: . Maximum bandwidth; . Maximum picture size in pixels; . Maximum number of pixels to be processed per second; The bandwidth parameter is the only one that specifically relates to a CLUE Advertisement, as it can be further constrained by the maximum group bandwidth in an Encoding Group. 9.2. Encoding Group An Encoding Group includes a set of one or more Individual Encodings, and parameters that apply to the group as a whole. By grouping multiple individual Encodings together, an Encoding Group describes additional constraints on bandwidth for the group. A single Encoding Group MAY refer to Encodings for different media types. The Encoding Group data structure contains: . Maximum bitrate for all encodings in the group combined; . A list of identifiers for the Individual Encodings belonging to the group. When the Individual Encodings in a group are instantiated into Capture Encodings, each Capture Encoding has a bitrate that MUST be less than or equal to the max bitrate for the particular Individual Encoding. The "maximum bitrate for all encodings in the group" parameter gives the additional restriction that the sum of all the individual Capture Encoding bitrates MUST be less than or equal to this group value. The following diagram illustrates one example of the structure of a media Provider's Encoding Groups and their contents. Duckworth et. al. Expires July 8, 2016 [Page 38] Internet-Draft CLUE Telepresence Framework January 2016 ,-------------------------------------------------. | Media Provider | | | | ,--------------------------------------. | | | ,--------------------------------------. | | | | ,--------------------------------------. | | | | | Encoding Group | | | | | | ,-----------. | | | | | | | | ,---------. | | | | | | | | | | ,---------.| | | | | | | Encoding1 | |Encoding2| |Encoding3|| | | `.| | | | | | `---------'| | | `.| `-----------' `---------' | | | `--------------------------------------' | `-------------------------------------------------' Figure 4: Encoding Group Structure A Provider advertises one or more Encoding Groups. Each Encoding Group includes one or more Individual Encodings. Each Individual Encoding can represent a different way of encoding media. For example one Individual Encoding may be 1080p60 video, another could be 720p30, with a third being CIF, all in, for example, H.264 format. While a typical three codec/display system might have one Encoding Group per "codec box" (physical codec, connected to one camera and one screen), there are many possibilities for the number of Encoding Groups a Provider may be able to offer and for the encoding values in each Encoding Group. There is no requirement for all Encodings within an Encoding Group to be instantiated at the same time. 9.3. Associating Captures with Encoding Groups Each Media Capture, including MCCs, MAY be associated with one Encoding Group. To be eligible for configuration, a Media Capture MUST be associated with one Encoding Group, which is used to instantiate that Capture into a Capture Encoding. When an MCC is configured all the Media Captures referenced by the MCC will appear in the Capture Encoding according to the attributes of the chosen encoding of the MCC. This allows an Advertiser to specify encoding attributes associated with the Media Captures without the need to provide an individual Capture Encoding for each of the inputs. Duckworth et. al. Expires July 8, 2016 [Page 39] Internet-Draft CLUE Telepresence Framework January 2016 If an Encoding Group is assigned to a Media Capture referenced by the MCC it indicates that this Capture may also have an individual Capture Encoding. For example: +--------------------+------------------------------------+ | Capture Scene #1 | | +--------------------+------------------------------------+ | VC1 | EncodeGroupID=1 | | VC2 | | | MCC1(VC1,VC2) | EncodeGroupID=2 | | CSV(VC1) | | | CSV(MCC1) | | +--------------------+------------------------------------+ Table 6: Example usage of Encoding with MCC and source Captures This would indicate that VC1 may be sent as its own Capture Encoding from EncodeGroupID=1 or that it may be sent as part of a Capture Encoding from EncodeGroupID=2 along with VC2. More than one Capture MAY use the same Encoding Group. The maximum number of Capture Encodings that can result from a particular Encoding Group constraint is equal to the number of individual Encodings in the group. The actual number of Capture Encodings used at any time MAY be less than this maximum. Any of the Captures that use a particular Encoding Group can be encoded according to any of the Individual Encodings in the group. It is a protocol conformance requirement that the Encoding Groups MUST allow all the Captures in a particular Capture Scene View to be used simultaneously. 10. Consumer's Choice of Streams to Receive from the Provider After receiving the Provider's Advertisement message (that includes media captures and associated constraints), the Consumer composes its reply to the Provider in the form of a Configure message. The Consumer is free to use the information in the Advertisement as it chooses, but there are a few obviously sensible design choices, which are outlined below. Duckworth et. al. Expires July 8, 2016 [Page 40] Internet-Draft CLUE Telepresence Framework January 2016 If multiple Providers connect to the same Consumer (i.e. in an MCU- less multiparty call), it is the responsibility of the Consumer to compose Configures for each Provider that both fulfill each Provider's constraints as expressed in the Advertisement, as well as its own capabilities. In an MCU-based multiparty call, the MCU can logically terminate the Advertisement/Configure negotiation in that it can hide the characteristics of the receiving endpoint and rely on its own capabilities (transcoding/transrating/...) to create Media Streams that can be decoded at the Endpoint Consumers. The timing of an MCU's sending of Advertisements (for its outgoing ports) and Configures (for its incoming ports, in response to Advertisements received there) is up to the MCU and implementation dependent. As a general outline, a Consumer can choose, based on the Advertisement it has received, which Captures it wishes to receive, and which Individual Encodings it wants the Provider to use to encode the Captures. On receipt of an Advertisement with an MCC the Consumer treats the MCC as per other non-MCC Captures with the following differences: - The Consumer would understand that the MCC is a Capture that includes the referenced individual Captures (or any Captures, if none are referenced) and that these individual Captures are delivered as part of the MCC's Capture Encoding. - The Consumer may utilise any of the attributes associated with the referenced individual Captures and any Capture Scene attributes from where the individual Captures were defined to choose Captures and for rendering decisions. - If the MCC attribute Allow Subset Choice is true, then the Consumer may or may not choose to receive all the indicated Captures. It can choose to receive a sub-set of Captures indicated by the MCC. For example if the Consumer receives: MCC1(VC1,VC2,VC3){attributes} A Consumer could choose all the Captures within a MCC however if the Consumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2). If it wants all the individual Captures then it Duckworth et. al. Expires July 8, 2016 [Page 41] Internet-Draft CLUE Telepresence Framework January 2016 returns only the MCC identity (i.e. MCC1). If the MCC in the advertisement does not reference any individual captures, or the Allow Subset Choice attribute is false, then the Consumer cannot choose what is included in the MCC, it is up to the Provider to decide. A Configure Message includes a list of Capture Encodings. These are the Capture Encodings the Consumer wishes to receive from the Provider. Each Capture Encoding refers to one Media Capture and one Individual Encoding. For each Capture the Consumer wants to receive, it configures one of the Encodings in that Capture's Encoding Group. The Consumer does this by telling the Provider, in its Configure Message, which Encoding to use for each chosen Capture. Upon receipt of this Configure from the Consumer, common knowledge is established between Provider and Consumer regarding sensible choices for the media streams. The setup of the actual media channels, at least in the simplest case, is left to a following offer/answer exchange. Optimized implementations may speed up the reaction to the offer/answer exchange by reserving the resources at the time of finalization of the CLUE handshake. CLUE advertisements and configure messages don't necessarily require a new SDP offer/answer for every CLUE message exchange. But the resulting encodings sent via RTP must conform to the most recent SDP offer/answer result. In order to meaningfully create and send an initial Configure, the Consumer needs to have received at least one Advertisement, and an SDP offer defining the Individual Encodings, from the Provider. In addition, the Consumer can send a Configure at any time during the call. The Configure MUST be valid according to the most recently received Advertisement. The Consumer can send a Configure either in response to a new Advertisement from the Provider or on its own, for example because of a local change in conditions (people leaving the room, connectivity changes, multipoint related considerations). When choosing which Media Streams to receive from the Provider, and the encoding characteristics of those Media Streams, the Consumer advantageously takes several things into account: its local preference, simultaneity restrictions, and encoding limits. Duckworth et. al. Expires July 8, 2016 [Page 42] Internet-Draft CLUE Telepresence Framework January 2016 10.1. Local preference A variety of local factors influence the Consumer's choice of Media Streams to be received from the Provider: o if the Consumer is an Endpoint, it is likely that it would choose, where possible, to receive video and audio Captures that match the number of display devices and audio system it has o if the Consumer is an MCU, it may choose to receive loudest speaker streams (in order to perform its own media composition) and avoid pre-composed video Captures o user choice (for instance, selection of a new layout) may result in a different set of Captures, or different encoding characteristics, being required by the Consumer 10.2. Physical simultaneity restrictions Often there are physical simultaneity constraints of the Provider that affect the Provider's ability to simultaneously send all of the captures the Consumer would wish to receive. For instance, an MCU, when connected to a multi-camera room system, might prefer to receive both individual video streams of the people present in the room and an overall view of the room from a single camera. Some Endpoint systems might be able to provide both of these sets of streams simultaneously, whereas others might not (if the overall room view were produced by changing the optical zoom level on the center camera, for instance). 10.3. Encoding and encoding group limits Each of the Provider's encoding groups has limits on bandwidth, and the constituent potential encodings have limits on the bandwidth, computational complexity, video frame rate, and resolution that can be provided. When choosing the Captures to be received from a Provider, a Consumer device MUST ensure that the encoding characteristics requested for each individual Capture fits within the capability of the encoding it is being configured to use, as well as ensuring that the combined encoding characteristics for Captures fit within the capabilities of their associated encoding groups. In some cases, this could cause an otherwise "preferred" choice of capture encodings to be passed over in favor of different Capture Encodings--for instance, if a set of three Captures could only be provided at a low resolution Duckworth et. al. Expires July 8, 2016 [Page 43] Internet-Draft CLUE Telepresence Framework January 2016 then a three screen device could switch to favoring a single, higher quality, Capture Encoding. 11. Extensibility One important characteristics of the Framework is its extensibility. The standard for interoperability and handling multiple streams must be future-proof. The framework itself is inherently extensible through expanding the data model types. For example: o Adding more types of media, such as telemetry, can done by defining additional types of Captures in addition to audio and video. o Adding new functionalities, such as 3-D video Captures, say, may require additional attributes describing the Captures. The infrastructure is designed to be extended rather than requiring new infrastructure elements. Extension comes through adding to defined types. 12. Examples - Using the Framework (Informative) This section gives some examples, first from the point of view of the Provider, then the Consumer, then some multipoint scenarios 12.1. Provider Behavior This section shows some examples in more detail of how a Provider can use the framework to represent a typical case for telepresence rooms. First an endpoint is illustrated, then an MCU case is shown. 12.1.1. Three screen Endpoint Provider Consider an Endpoint with the following description: 3 cameras, 3 displays, a 6 person table o Each camera can provide one Capture for each 1/3 section of the table Duckworth et. al. Expires July 8, 2016 [Page 44] Internet-Draft CLUE Telepresence Framework January 2016 o A single Capture representing the active speaker can be provided (voice activity based camera selection to a given encoder input port implemented locally in the Endpoint) o A single Capture representing the active speaker with the other 2 Captures shown picture in picture (PiP) within the stream can be provided (again, implemented inside the endpoint) o A Capture showing a zoomed out view of all 6 seats in the room can be provided The video and audio Captures for this Endpoint can be described as follows. Video Captures: o VC0- (the left camera stream), encoding group=EG0, view=table o VC1- (the center camera stream), encoding group=EG1, view=table o VC2- (the right camera stream), encoding group=EG2, view=table o MCC3- (the loudest panel stream), encoding group=EG1, view=table, MaxCaptures=1, policy=SoundLevel o MCC4- (the loudest panel stream with PiPs), encoding group=EG1, view=room, MaxCaptures=3, policy=SoundLevel o VC5- (the zoomed out view of all people in the room), encoding group=EG1, view=room o VC6- (presentation stream), encoding group=EG1, presentation The following diagram is a top view of the room with 3 cameras, 3 displays, and 6 seats. Each camera captures 2 people. The six seats are not all in a straight line. Duckworth et. al. Expires July 8, 2016 [Page 45] Internet-Draft CLUE Telepresence Framework January 2016 ,-. d ( )`--.__ +---+ `-' / `--.__ | | ,-. | `-.._ |_-+Camera 2 (VC2) ( ).' <--(AC1)-+-''`+-+ `-' |_...---'' | | ,-.c+-..__ +---+ ( )| ``--..__ | | `-' | ``+-..|_-+Camera 1 (VC1) ,-. | <--(AC2)..--'|+-+ ^ ( )| __..--' | | | `-'b|..--' +---+ |X ,-. |``---..___ | | | ( )\ ```--..._|_-+Camera 0 (VC0) | `-' \ <--(AC0) ..-''`-+ | ,-. \ __.--'' | | <----------+ ( ) |..-'' +---+ Y `-' a (0,0,0) origin is under Camera 1 Figure 5: Room Layout Top View Duckworth et. al. Expires July 8, 2016 [Page 46] Internet-Draft CLUE Telepresence Framework January 2016 The two points labeled b and c are intended to be at the midpoint between the seating positions, and where the fields of view of the cameras intersect. The plane of interest for VC0 is a vertical plane that intersects points 'a' and 'b'. The plane of interest for VC1 intersects points 'b' and 'c'. The plane of interest for VC2 intersects points 'c' and 'd'. This example uses an area scale of millimeters. Areas of capture: bottom left bottom right top left top right VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757) VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757) VC2 ( 673,3000,0) (2011,2850,0) ( 673,3000,757) (2011,3000,757) MCC3(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) MCC4(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) VC6 none Points of capture: VC0 (-1678,0,800) VC1 (0,0,800) VC2 (1678,0,800) MCC3 none MCC4 none VC5 (0,0,800) VC6 none In this example, the right edge of the VC0 area lines up with the left edge of the VC1 area. It doesn't have to be this way. There could be a gap or an overlap. One additional thing to note for this example is the distance from a to b is equal to the distance from b to c and the distance from c to d. All these distances are 1346 mm. This is the planar width of each area of capture for VC0, VC1, and VC2. Note the text in parentheses (e.g. "the left camera stream") is not explicitly part of the model, it is just explanatory text for this example, and is not included in the model with the media Duckworth et. al. Expires July 8, 2016 [Page 47] Internet-Draft CLUE Telepresence Framework January 2016 captures and attributes. Also, MCC4 doesn't say anything about how a capture is composed, so the media consumer can't tell based on this capture that MCC4 is composed of a "loudest panel with PiPs". Audio Captures: Three ceiling microphones are located between the cameras and the table, at the same height as the cameras. The microphones point down at an angle toward the seating positions. o AC0 (left), encoding group=EG3 o AC1 (right), encoding group=EG3 o AC2 (center) encoding group=EG3 o AC3 being a simple pre-mixed audio stream from the room (mono), encoding group=EG3 o AC4 audio stream associated with the presentation video (mono) encoding group=EG3, presentation Point of capture: Point on Line of Capture: AC0 (-1342,2000,800) (-1342,2925,379) AC1 ( 1342,2000,800) ( 1342,2925,379) AC2 ( 0,2000,800) ( 0,3000,379) AC3 ( 0,2000,800) ( 0,3000,379) AC4 none The physical simultaneity information is: Simultaneous transmission set #1 {VC0, VC1, VC2, MCC3, MCC4, VC6} Simultaneous transmission set #2 {VC0, VC2, VC5, VC6} This constraint indicates it is not possible to use all the VCs at the same time. VC5 cannot be used at the same time as VC1 or MCC3 or MCC4. Also, using every member in the set simultaneously may not make sense - for example MCC3(loudest) and MCC4 (loudest with PiP). In addition, there are encoding constraints that make choosing all of the VCs in a set impossible. VC1, MCC3, MCC4, VC5, VC6 all use EG1 and EG1 has only 3 ENCs. This constraint Duckworth et. al. Expires July 8, 2016 [Page 48] Internet-Draft CLUE Telepresence Framework January 2016 shows up in the encoding groups, not in the simultaneous transmission sets. In this example there are no restrictions on which Audio Captures can be sent simultaneously. Encoding Groups: This example has three encoding groups associated with the video captures. Each group can have 3 encodings, but with each potential encoding having a progressively lower specification. In this example, 1080p60 transmission is possible (as ENC0 has a maxPps value compatible with that). Significantly, as up to 3 encodings are available per group, it is possible to transmit some video Captures simultaneously that are not in the same view in the Capture Scene. For example VC1 and MCC3 at the same time. The information below about Encodings is a summary of what would be conveyed in SDP, not directly in the CLUE Advertisement. encodeGroupID=EG0, maxGroupBandwidth=6000000 encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 encodeGroupID=EG1 maxGroupBandwidth=6000000 encodeID=ENC3, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC4, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC5, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 encodeGroupID=EG2 maxGroupBandwidth=6000000 encodeID=ENC6, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC7, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC8, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 Figure 6: Example Encoding Groups for Video For audio, there are five potential encodings available, so all five Audio Captures can be encoded at the same time. Duckworth et. al. Expires July 8, 2016 [Page 49] Internet-Draft CLUE Telepresence Framework January 2016 encodeGroupID=EG3, maxGroupBandwidth=320000 encodeID=ENC9, maxBandwidth=64000 encodeID=ENC10, maxBandwidth=64000 encodeID=ENC11, maxBandwidth=64000 encodeID=ENC12, maxBandwidth=64000 encodeID=ENC13, maxBandwidth=64000 Figure 7: Example Encoding Group for Audio Capture Scenes: The following table represents the Capture Scenes for this Provider. Recall that a Capture Scene is composed of alternative Capture Scene Views covering the same spatial region. Capture Scene #1 is for the main people captures, and Capture Scene #2 is for presentation. Each row in the table is a separate Capture Scene View +------------------+ | Capture Scene #1 | +------------------+ | VC0, VC1, VC2 | | MCC3 | | MCC4 | | VC5 | | AC0, AC1, AC2 | | AC3 | +------------------+ +------------------+ | Capture Scene #2 | +------------------+ | VC6 | | AC4 | +------------------+ Table 7: Example Capture Scene Views Different Capture Scenes are distinct from each other, and are non-overlapping. A Consumer can choose a view from each Capture Scene. In this case the three Captures VC0, VC1, and VC2 are one way of representing the video from the Endpoint. These three Captures should appear adjacent next to each other. Alternatively, another way of representing the Capture Scene is Duckworth et. al. Expires July 8, 2016 [Page 50] Internet-Draft CLUE Telepresence Framework January 2016 with the capture MCC3, which automatically shows the person who is talking. Similarly for the MCC4 and VC5 alternatives. As in the video case, the different views of audio in Capture Scene #1 represent the "same thing", in that one way to receive the audio is with the 3 Audio Captures (AC0, AC1, AC2), and another way is with the mixed AC3. The Media Consumer can choose an audio CSV it is capable of receiving. The spatial ordering is understood by the Media Capture attributes Area of Capture, Point of Capture and Point on Line of Capture. A Media Consumer would likely want to choose a Capture Scene View to receive based in part on how many streams it can simultaneously receive. A consumer that can receive three video streams would probably prefer to receive the first view of Capture Scene #1 (VC0, VC1, VC2) and not receive the other views. A consumer that can receive only one video stream would probably choose one of the other views. If the consumer can receive a presentation stream too, it would also choose to receive the only view from Capture Scene #2 (VC6). 12.1.2. Encoding Group Example This is an example of an Encoding Group to illustrate how it can express dependencies between Encodings. The information below about Encodings is a summary of what would be conveyed in SDP, not directly in the CLUE Advertisement. encodeGroupID=EG0 maxGroupBandwidth=6000000 encodeID=VIDENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeID=VIDENC1, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeID=AUDENC0, maxBandwidth=96000 encodeID=AUDENC1, maxBandwidth=96000 encodeID=AUDENC2, maxBandwidth=96000 Here, the Encoding Group is EG0. Although the Encoding Group is capable of transmitting up to 6Mbit/s, no individual video Encoding can exceed 4Mbit/s. This encoding group also allows up to 3 audio encodings, AUDENC<0- 2>. It is not required that audio and video encodings reside Duckworth et. al. Expires July 8, 2016 [Page 51] Internet-Draft CLUE Telepresence Framework January 2016 within the same encoding group, but if so then the group's overall maxBandwidth value is a limit on the sum of all audio and video encodings configured by the consumer. A system that does not wish or need to combine bandwidth limitations in this way should instead use separate encoding groups for audio and video in order for the bandwidth limitations on audio and video to not interact. Audio and video can be expressed in separate encoding groups, as in this illustration. encodeGroupID=EG0 maxGroupBandwidth=6000000 encodeID=VIDENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeID=VIDENC1, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000 encodeGroupID=EG1 maxGroupBandwidth=500000 encodeID=AUDENC0, maxBandwidth=96000 encodeID=AUDENC1, maxBandwidth=96000 encodeID=AUDENC2, maxBandwidth=96000 12.1.3. The MCU Case This section shows how an MCU might express its Capture Scenes, intending to offer different choices for consumers that can handle different numbers of streams. Each MCC is for video. A single Audio Capture is provided for all single and multi-screen configurations that can be associated (e.g. lip-synced) with any combination of Video Captures (the MCCs) at the consumer. +-----------------------+---------------------------------+ | Capture Scene #1 | | +-----------------------|---------------------------------+ | MCC | for a single screen consumer | | MCC1, MCC2 | for a two screen consumer | | MCC3, MCC4, MCC5 | for a three screen consumer | | MCC6, MCC7, MCC8, MCC9| for a four screen consumer | | AC0 | AC representing all participants| | CSV(MCC0) | | | CSV(MCC1,MCC2) | | | CSV(MCC3,MCC4,MCC5) | | | CSV(MCC6,MCC7, | | | MCC8,MCC9) | | | CSV(AC0) | | +-----------------------+---------------------------------+ Duckworth et. al. Expires July 8, 2016 [Page 52] Internet-Draft CLUE Telepresence Framework January 2016 Table 8: MCU main Capture Scenes If / when a presentation stream becomes active within the conference the MCU might re-advertise the available media as: +------------------+--------------------------------------+ | Capture Scene #2 | note | +------------------+--------------------------------------+ | VC10 | video capture for presentation | | AC1 | presentation audio to accompany VC10 | | CSV(VC10) | | | CSV(AC1) | | +------------------+--------------------------------------+ Table 9: MCU presentation Capture Scene 12.2. Media Consumer Behavior This section gives an example of how a Media Consumer might behave when deciding how to request streams from the three screen endpoint described in the previous section. The receive side of a call needs to balance its requirements, based on number of screens and speakers, its decoding capabilities and available bandwidth, and the provider's capabilities in order to optimally configure the provider's streams. Typically it would want to receive and decode media from each Capture Scene advertised by the Provider. A sane, basic, algorithm might be for the consumer to go through each Capture Scene View in turn and find the collection of Video Captures that best matches the number of screens it has (this might include consideration of screens dedicated to presentation video display rather than "people" video) and then decide between alternative views in the video Capture Scenes based either on hard-coded preferences or user choice. Once this choice has been made, the consumer would then decide how to configure the provider's encoding groups in order to make best use of the available network bandwidth and its own decoding capabilities. 12.2.1. One screen Media Consumer MCC3, MCC4 and VC5 are all different views by themselves, not grouped together in a single view, so the receiving device should choose between one of those. The choice would come down to Duckworth et. al. Expires July 8, 2016 [Page 53] Internet-Draft CLUE Telepresence Framework January 2016 whether to see the greatest number of participants simultaneously at roughly equal precedence (VC5), a switched view of just the loudest region (MCC3) or a switched view with PiPs (MCC4). An endpoint device with a small amount of knowledge of these differences could offer a dynamic choice of these options, in- call, to the user. 12.2.2. Two screen Media Consumer configuring the example Mixing systems with an even number of screens, "2n", and those with "2n+1" cameras (and vice versa) is always likely to be the problematic case. In this instance, the behavior is likely to be determined by whether a "2 screen" system is really a "2 decoder" system, i.e., whether only one received stream can be displayed per screen or whether more than 2 streams can be received and spread across the available screen area. To enumerate 3 possible behaviors here for the 2 screen system when it learns that the far end is "ideally" expressed via 3 capture streams: 1. Fall back to receiving just a single stream (MCC3, MCC4 or VC5 as per the 1 screen consumer case above) and either leave one screen blank or use it for presentation if / when a presentation becomes active. 2. Receive 3 streams (VC0, VC1 and VC2) and display across 2 screens (either with each capture being scaled to 2/3 of a screen and the center capture being split across 2 screens) or, as would be necessary if there were large bezels on the screens, with each stream being scaled to 1/2 the screen width and height and there being a 4th "blank" panel. This 4th panel could potentially be used for any presentation that became active during the call. 3. Receive 3 streams, decode all 3, and use control information indicating which was the most active to switch between showing the left and center streams (one per screen) and the center and right streams. For an endpoint capable of all 3 methods of working described above, again it might be appropriate to offer the user the choice of display mode. Duckworth et. al. Expires July 8, 2016 [Page 54] Internet-Draft CLUE Telepresence Framework January 2016 12.2.3. Three screen Media Consumer configuring the example This is the most straightforward case - the Media Consumer would look to identify a set of streams to receive that best matched its available screens and so the VC0 plus VC1 plus VC2 should match optimally. The spatial ordering would give sufficient information for the correct Video Capture to be shown on the correct screen, and the consumer would either need to divide a single encoding group's capability by 3 to determine what resolution and frame rate to configure the provider with or to configure the individual Video Captures' Encoding Groups with what makes most sense (taking into account the receive side decode capabilities, overall call bandwidth, the resolution of the screens plus any user preferences such as motion vs. sharpness). 12.3. Multipoint Conference utilizing Multiple Content Captures The use of MCCs allows the MCU to construct outgoing Advertisements describing complex media switching and composition scenarios. The following sections provide several examples. Note: In the examples the identities of the CLUE elements (e.g. Captures, Capture Scene) in the incoming Advertisements overlap. This is because there is no co-ordination between the endpoints. The MCU is responsible for making these unique in the outgoing advertisement. 12.3.1. Single Media Captures and MCC in the same Advertisement Four endpoints are involved in a Conference where CLUE is used. An MCU acts as a middlebox between the endpoints with a CLUE channel between each endpoint and the MCU. The MCU receives the following Advertisements. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | | EncodeGroupID=1 | | CSV(VC1) | | +---------------------------------------------------------+ Table 10: Advertisement received from Endpoint A Duckworth et. al. Expires July 8, 2016 [Page 55] Internet-Draft CLUE Telepresence Framework January 2016 +-----------------------+---------------------------------+ | Capture Scene #1 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Speaker | | | EncodeGroupID=1 | | VC2 | Description=Audience | | | EncodeGroupID=1 | | CSV(VC1, VC2) | | +---------------------------------------------------------+ Table 11: Advertisement received from Endpoint B +-----------------------+---------------------------------+ | Capture Scene #1 | Description=USAConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | | EncodeGroupID=1 | | CSV(VC1) | | +---------------------------------------------------------+ Table 12: Advertisement received from Endpoint C Note: Endpoint B above indicates that it sends two streams. If the MCU wanted to provide a Multiple Content Capture containing a round robin switched view of the audience from the 3 endpoints and the speaker it could construct the following advertisement: Advertisement sent to Endpoint F Duckworth et. al. Expires July 8, 2016 [Page 56] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | CSV(VC1) | | +=======================+=================================+ | Capture Scene #2 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC2 | Description=Speaker | | VC3 | Description=Audience | | CSV(VC2, VC3) | | +=======================+=================================+ | Capture Scene #3 | Description=USAConfRoom | +-----------------------|---------------------------------+ | VC4 | Description=Audience | | CSV(VC4) | | +=======================+=================================+ | Capture Scene #4 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC2,VC3,VC4) | Policy=RoundRobin:1 | | | MaxCaptures=1 | | | EncodingGroup=1 | | CSV(MCC1) | | +=======================+=================================+ Table 13: Advertisement sent to Endpoint F - One Encoding Alternatively if the MCU wanted to provide the speaker as one media stream and the audiences as another it could assign an encoding group to VC2 in Capture Scene 2 and provide a CSV in Capture Scene #4 as per the example below. Advertisement sent to Endpoint F Duckworth et. al. Expires July 8, 2016 [Page 57] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | Description=Audience | | CSV(VC1) | | +=======================+=================================+ | Capture Scene #2 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC2 | Description=Speaker | | | EncodingGroup=1 | | VC3 | Description=Audience | | CSV(VC2, VC3) | | +=======================+=================================+ | Capture Scene #3 | Description=USAConfRoom | +-----------------------|---------------------------------+ | VC4 | Description=Audience | | CSV(VC4) | | +=======================+=================================+ | Capture Scene #4 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC3,VC4) | Policy=RoundRobin:1 | | | MaxCaptures=1 | | | EncodingGroup=1 | | | AllowSubset=True | | MCC2(VC2) | MaxCaptures=1 | | | EncodingGroup=1 | | CSV2(MCC1,MCC2) | | +=======================+=================================+ Table 14: Advertisement sent to Endpoint F - Two Encodings Therefore a Consumer could choose whether or not to have a separate speaker related stream and could choose which endpoints to see. If it wanted the second stream but not the Australian conference room it could indicate the following captures in the Configure message: +-----------------------+---------------------------------+ | MCC1(VC3,VC4) | Encoding | | VC2 | Encoding | +-----------------------|---------------------------------+ Table 15: MCU case: Consumer Response Duckworth et. al. Expires July 8, 2016 [Page 58] Internet-Draft CLUE Telepresence Framework January 2016 12.3.2. Several MCCs in the same Advertisement Multiple MCCs can be used where multiple streams are used to carry media from multiple endpoints. For example: A conference has three endpoints D, E and F. Each end point has three video captures covering the left, middle and right regions of each conference room. The MCU receives the following advertisements from D and E. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=1 | | VC2 | CaptureArea=Centre | | | EncodingGroup=1 | | VC3 | CaptureArea=Right | | | EncodingGroup=1 | | CSV(VC1,VC2,VC3) | | +---------------------------------------------------------+ Table 16: Advertisement received from Endpoint D +-----------------------+---------------------------------+ | Capture Scene #1 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=1 | | VC2 | CaptureArea=Centre | | | EncodingGroup=1 | | VC3 | CaptureArea=Right | | | EncodingGroup=1 | | CSV(VC1,VC2,VC3) | | +---------------------------------------------------------+ Table 17: Advertisement received from Endpoint E The MCU wants to offer Endpoint F three Capture Encodings. Each Capture Encoding would contain all the Captures from either Endpoint D or Endpoint E depending based on the active speaker. The MCU sends the following Advertisement: Duckworth et. al. Expires July 8, 2016 [Page 59] Internet-Draft CLUE Telepresence Framework January 2016 +=======================+=================================+ | Capture Scene #1 | Description=AustralianConfRoom | +-----------------------|---------------------------------+ | VC1 | | | VC2 | | | VC3 | | | CSV(VC1,VC2,VC3) | | +=======================+=================================+ | Capture Scene #2 | Description=ChinaConfRoom | +-----------------------|---------------------------------+ | VC4 | | | VC5 | | | VC6 | | | CSV(VC4,VC5,VC6) | | +=======================+=================================+ | Capture Scene #3 | | +-----------------------|---------------------------------+ | MCC1(VC1,VC4) | CaptureArea=Left | | | MaxCaptures=1 | | | SynchronisationID=1 | | | EncodingGroup=1 | | MCC2(VC2,VC5) | CaptureArea=Centre | | | MaxCaptures=1 | | | SynchronisationID=1 | | | EncodingGroup=1 | | MCC3(VC3,VC6) | CaptureArea=Right | | | MaxCaptures=1 | | | SynchronisationID=1 | | | EncodingGroup=1 | | CSV(MCC1,MCC2,MCC3) | | +=======================+=================================+ Table 18: Advertisement sent to Endpoint F 12.3.3. Heterogeneous conference with switching and composition Consider a conference between endpoints with the following characteristics: Endpoint A - 4 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 3 screens, 3 cameras Duckworth et. al. Expires July 8, 2016 [Page 60] Internet-Draft CLUE Telepresence Framework January 2016 Endpoint D - 3 screens, 3 cameras Endpoint E - 1 screen, 1 camera Endpoint F - 2 screens, 1 camera Endpoint G - 1 screen, 1 camera This example focuses on what the user in one of the 3-camera multi- screen endpoints sees. Call this person User A, at Endpoint A. There are 4 large display screens at Endpoint A. Whenever somebody at another site is speaking, all the video captures from that endpoint are shown on the large screens. If the talker is at a 3- camera site, then the video from those 3 cameras fills 3 of the screens. If the talker is at a single-camera site, then video from that camera fills one of the screens, while the other screens show video from other single-camera endpoints. User A hears audio from the 4 loudest talkers. User A can also see video from other endpoints, in addition to the current talker, although much smaller in size. Endpoint A has 4 screens, so one of those screens shows up to 9 other Media Captures in a tiled fashion. When video from a 3 camera endpoint appears in the tiled area, video from all 3 cameras appears together across the screen with correct spatial relationship among those 3 images. +---+---+---+ +-------------+ +-------------+ +-------------+ | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ | | | | | | | | | | | | | | | | +---+---+---+ +-------------+ +-------------+ +-------------+ Figure 8: Endpoint A - 4 Screen Display User B at Endpoint B sees a similar arrangement, except there are only 3 screens, so the 9 other Media Captures are spread out across the bottom of the 3 displays, in a picture-in-picture (PiP) format. When video from a 3 camera endpoint appears in the PiP area, video from all 3 cameras appears together across a single screen with correct spatial relationship. Duckworth et. al. Expires July 8, 2016 [Page 61] Internet-Draft CLUE Telepresence Framework January 2016 +-------------+ +-------------+ +-------------+ | | | | | | | | | | | | | | | | | | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ | +-------------+ +-------------+ +-------------+ Figure 9: Endpoint B - 3 Screen Display with PiPs When somebody at a different endpoint becomes the current talker, then User A and User B both see the video from the new talker appear on their large screen area, while the previous talker takes one of the smaller tiled or PiP areas. The person who is the current talker doesn't see themselves; they see the previous talker in their large screen area. One of the points of this example is that endpoints A and B each want to receive 3 capture encodings for their large display areas, and 9 encodings for their smaller areas. A and B are be able to each send the same Configure message to the MCU, and each receive the same conceptual Media Captures from the MCU. The differences are in how they are rendered and are purely a local matter at A and B. The Advertisements for such a scenario are described below. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=Endpoint x | +-----------------------|---------------------------------+ | VC1 | EncodingGroup=1 | | VC2 | EncodingGroup=1 | | VC3 | EncodingGroup=1 | | AC1 | EncodingGroup=2 | | CSV1(VC1, VC2, VC3) | | | CSV2(AC1) | | +---------------------------------------------------------+ Table 19: Advertisement received at the MCU from Endpoints A to D Duckworth et. al. Expires July 8, 2016 [Page 62] Internet-Draft CLUE Telepresence Framework January 2016 +-----------------------+---------------------------------+ | Capture Scene #1 | Description=Endpoint y | +-----------------------|---------------------------------+ | VC1 | EncodingGroup=1 | | AC1 | EncodingGroup=2 | | CSV1(VC1) | | | CSV2(AC1) | | +---------------------------------------------------------+ Table 20: Advertisement received at the MCU from Endpoints E to G Rather than considering what is displayed CLUE concentrates more on what the MCU sends. The MCU doesn't know anything about the number of screens an endpoint has. As Endpoints A to D each advertise that three Captures make up a Capture Scene, the MCU offers these in a "site" switching mode. That is that there are three Multiple Content Captures (and Capture Encodings) each switching between Endpoints. The MCU switches in the applicable media into the stream based on voice activity. Endpoint A will not see a capture from itself. Using the MCC concept the MCU would send the following Advertisement to endpoint A: +=======================+=================================+ | Capture Scene #1 | Description=Endpoint B | +-----------------------|---------------------------------+ | VC4 | CaptureArea=Left | | VC5 | CaptureArea=Center | | VC6 | CaptureArea=Right | | AC1 | | | CSV(VC4,VC5,VC6) | | | CSV(AC1) | | +=======================+=================================+ | Capture Scene #2 | Description=Endpoint C | +-----------------------|---------------------------------+ | VC7 | CaptureArea=Left | | VC8 | CaptureArea=Center | | VC9 | CaptureArea=Right | | AC2 | | | CSV(VC7,VC8,VC9) | | | CSV(AC2) | | +=======================+=================================+ | Capture Scene #3 | Description=Endpoint D | Duckworth et. al. Expires July 8, 2016 [Page 63] Internet-Draft CLUE Telepresence Framework January 2016 +-----------------------|---------------------------------+ | VC10 | CaptureArea=Left | | VC11 | CaptureArea=Center | | VC12 | CaptureArea=Right | | AC3 | | | CSV(VC10,VC11,VC12) | | | CSV(AC3) | | +=======================+=================================+ | Capture Scene #4 | Description=Endpoint E | +-----------------------|---------------------------------+ | VC13 | | | AC4 | | | CSV(VC13) | | | CSV(AC4) | | +=======================+=================================+ | Capture Scene #5 | Description=Endpoint F | +-----------------------|---------------------------------+ | VC14 | | | AC5 | | | CSV(VC14) | | | CSV(AC5) | | +=======================+=================================+ | Capture Scene #6 | Description=Endpoint G | +-----------------------|---------------------------------+ | VC15 | | | AC6 | | | CSV(VC15) | | | CSV(AC6) | | +=======================+=================================+ Table 21: Advertisement sent to endpoint A - Source Part The above part of the Advertisement presents information about the sources to the MCC. The information is effectively the same as the received Advertisements except that there are no Capture Encodings associated with them and the identities have been re-numbered. In addition to the source Capture information the MCU advertises "site" switching of Endpoints B to G in three streams. +=======================+=================================+ | Capture Scene #7 | Description=Output3streammix | +-----------------------|---------------------------------+ | MCC1(VC4,VC7,VC10, | CaptureArea=Left | | VC13) | MaxCaptures=1 | Duckworth et. al. Expires July 8, 2016 [Page 64] Internet-Draft CLUE Telepresence Framework January 2016 | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC2(VC5,VC8,VC11, | CaptureArea=Center | | VC14) | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC3(VC6,VC9,VC12, | CaptureArea=Right | | VC15) | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC4() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=2 | | | | | MCC5() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:1 | | | EncodingGroup=2 | | | | | MCC6() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:2 | | | EncodingGroup=2 | | | | | MCC7() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:3 | | | EncodingGroup=2 | | | | | CSV(MCC1,MCC2,MCC3) | | | CSV(MCC4,MCC5,MCC6, | | | MCC7) | | +=======================+=================================+ Table 22: Advertisement send to endpoint A - switching part The above part describes the switched 3 main streams that relate to site switching. MaxCaptures=1 indicates that only one Capture from Duckworth et. al. Expires July 8, 2016 [Page 65] Internet-Draft CLUE Telepresence Framework January 2016 the MCC is sent at a particular time. SynchronisationID=1 indicates that the source sending is synchronised. The provider can choose to group together VC13, VC14, and VC15 for the purpose of switching according to the SynchronisationID. Therefore when the provider switches one of them into an MCC, it can also switch the others even though they are not part of the same Capture Scene. All the audio for the conference is included in this Scene #7. There isn't necessarily a one to one relation between any audio capture and video capture in this scene. Typically a change in loudest talker will cause the MCU to switch the audio streams more quickly than switching video streams. The MCU can also supply nine media streams showing the active and previous eight speakers. It includes the following in the Advertisement: +=======================+=================================+ | Capture Scene #8 | Description=Output9stream | +-----------------------|---------------------------------+ | MCC8(VC4,VC5,VC6,VC7, | MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:0 | | VC12,VC13,VC14,VC15)| EncodingGroup=1 | | | | | MCC9(VC4,VC5,VC6,VC7, | MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:1 | | VC12,VC13,VC14,VC15)| EncodingGroup=1 | | | | to to | | | | | MCC16(VC4,VC5,VC6,VC7,| MaxCaptures=1 | | VC8,VC9,VC10,VC11, | Policy=SoundLevel:8 | | VC12,VC13,VC14,VC15)| EncodingGroup=1 | | | | | CSV(MCC8,MCC9,MCC10, | | | MCC11,MCC12,MCC13,| | | MCC14,MCC15,MCC16)| | +=======================+=================================+ Table 23: Advertisement sent to endpoint A - 9 switched part The above part indicates that there are 9 capture encodings. Each of the Capture Encodings may contain any captures from any source site with a maximum of one Capture at a time. Which Capture is Duckworth et. al. Expires July 8, 2016 [Page 66] Internet-Draft CLUE Telepresence Framework January 2016 present is determined by the policy. The MCCs in this scene do not have any spatial attributes. Note: The Provider alternatively could provide each of the MCCs above in its own Capture Scene. If the MCU wanted to provide a composed Capture Encoding containing all of the 9 captures it could advertise in addition: +=======================+=================================+ | Capture Scene #9 | Description=NineTiles | +-----------------------|---------------------------------+ | MCC13(MCC8,MCC9,MCC10,| MaxCaptures=9 | | MCC11,MCC12,MCC13,| EncodingGroup=1 | | MCC14,MCC15,MCC16)| | | | | | CSV(MCC13) | | +=======================+=================================+ Table 24: Advertisement sent to endpoint A - 9 composed part As MaxCaptures is 9 it indicates that the capture encoding contains information from 9 sources at a time. The Advertisement to Endpoint B is identical to the above other than the captures from Endpoint A would be added and the captures from Endpoint B would be removed. Whether the Captures are rendered on a four screen display or a three screen display is up to the Consumer to determine. The Consumer wants to place video captures from the same original source endpoint together, in the correct spatial order, but the MCCs do not have spatial attributes. So the Consumer needs to associate incoming media packets with the original individual captures in the advertisement (such as VC4, VC5, and VC6) in order to know the spatial information it needs for correct placement on the screens. The Provider can use the RTCP CaptureId SDES item and associated RTP header extension, as described in [I-D.ietf-clue-rtp-mapping], to convey this information to the Consumer. 12.3.4. Heterogeneous conference with voice activated switching This example illustrates how multipoint "voice activated switching" behavior can be realized, with an endpoint making its own decision about which of its outgoing video streams is considered the "active Duckworth et. al. Expires July 8, 2016 [Page 67] Internet-Draft CLUE Telepresence Framework January 2016 talker" from that endpoint. Then an MCU can decide which is the active talker among the whole conference. Consider a conference between endpoints with the following characteristics: Endpoint A - 3 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 1 screen, 1 camera This example focuses on what the user at endpoint C sees. The user would like to see the video capture of the current talker, without composing it with any other video capture. In this example endpoint C is capable of receiving only a single video stream. The following tables describe advertisements from A and B to the MCU, and from the MCU to C, that can be used to accomplish this. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=Endpoint x | +-----------------------|---------------------------------+ | VC1 | CaptureArea=Left | | | EncodingGroup=1 | | VC2 | CaptureArea=Center | | | EncodingGroup=1 | | VC3 | CaptureArea=Right | | | EncodingGroup=1 | | MCC1(VC1,VC2,VC3) | MaxCaptures=1 | | | CaptureArea=whole scene | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | AC1 | CaptureArea=whole scene | | | EncodingGroup=2 | | CSV1(VC1, VC2, VC3) | | | CSV2(MCC1) | | | CSV3(AC1) | | +---------------------------------------------------------+ Table 25: Advertisement received at the MCU from Endpoints A and B Endpoints A and B are advertising each individual video capture, and also a switched capture MCC1 which switches between the other three based on who is the active talker. These endpoints do not Duckworth et. al. Expires July 8, 2016 [Page 68] Internet-Draft CLUE Telepresence Framework January 2016 advertise distinct audio captures associated with each individual video capture, so it would be impossible for the MCU (as a media consumer) to make its own determination of which video capture is the active talker based just on information in the audio streams. +-----------------------+---------------------------------+ | Capture Scene #1 | Description=conference | +-----------------------|---------------------------------+ | MCC1() | CaptureArea=Left | | | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC2() | CaptureArea=Center | | | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC3() | CaptureArea=Right | | | MaxCaptures=1 | | | SynchronisationID=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC4() | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=1 | | | | | MCC5() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:0 | | | EncodingGroup=2 | | | | | MCC6() (for audio) | CaptureArea=whole scene | | | MaxCaptures=1 | | | Policy=SoundLevel:1 | | | EncodingGroup=2 | | CSV1(MCC1,MCC2,MCC3 | | | CSV2(MCC4) | | | CSV3(MCC5,MCC6) | | +---------------------------------------------------------+ Duckworth et. al. Expires July 8, 2016 [Page 69] Internet-Draft CLUE Telepresence Framework January 2016 Table 26: Advertisement sent from the MCU to C The MCU advertises one scene, with four video MCCs. Three of them in CSV1 give a left, center, right view of the conference, with "site switching". MCC4 provides a single video capture representing a view of the whole conference. The MCU intends for MCC4 to be switched between all the other original source captures. In this example advertisement the MCU is not giving all the information about all the other endpoints' scenes and which of those captures is included in the MCCs. The MCU could include all that information if it wants to give the consumers more information, but it is not necessary for this example scenario. The Provider advertises MCC5 and MCC6 for audio. Both are switched captures, with different SoundLevel policies indicating they are the top two dominant talkers. The Provider advertises CSV3 with both MCCs, suggesting the Consumer should use both if it can. Endpoint C, in its configure message to the MCU, requests to receive MCC4 for video, and MCC5 and MCC6 for audio. In order for the MCU to get the information it needs to construct MCC4, it has to send configure messages to A and B asking to receive MCC1 from each of them, along with their AC1 audio. Now the MCU can use audio energy information from the two incoming audio streams from A and B to determine which of those alternatives is the current talker. Based on that, the MCU uses either MCC1 from A or MCC1 from B as the source of MCC4 to send to C. 13. Acknowledgements Allyn Romanow and Brian Baldino were authors of early versions. Mark Gorzynski also contributed much to the initial approach. Many others also contributed, including Christian Groves, Jonathan Lennox, Paul Kyzivat, Rob Hansen, Roni Even, Christer Holmberg, Stephen Botzko, Mary Barnes, John Leslie, Paul Coverdale. 14. IANA Considerations None. 15. Security Considerations There are several potential attacks related to telepresence, and specifically the protocols used by CLUE, in the case of Duckworth et. al. Expires July 8, 2016 [Page 70] Internet-Draft CLUE Telepresence Framework January 2016 conferencing sessions, due to the natural involvement of multiple endpoints and the many, often user-invoked, capabilities provided by the systems. An MCU involved in a CLUE session can experience many of the same attacks as that of a conferencing system such as that enabled by the XCON framework [RFC5239]. Examples of attacks include the following: an endpoint attempting to listen to sessions in which it is not authorized to participate, an endpoint attempting to disconnect or mute other users, and theft of service by an endpoint in attempting to create telepresence sessions it is not allowed to create. Thus, it is RECOMMENDED that an MCU implementing the protocols necessary to support CLUE, follow the security recommendations specified in the conference control protocol documents. In the case of CLUE, SIP is the conferencing protocol, thus the security considerations in [RFC4579] MUST be followed. Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. The use of xCard with potentially sensitive information provides another reason to implement recommendations of section 11/[RFC5239]. One primary security concern, surrounding the CLUE framework introduced in this document, involves securing the actual protocols and the associated authorization mechanisms. These concerns apply to endpoint to endpoint sessions, as well as sessions involving multiple endpoints and MCUs. Figure 2 in section 5 provides a basic flow of information exchange for CLUE and the protocols involved. As described in section 5, CLUE uses SIP/SDP to establish the session prior to exchanging any CLUE specific information. Thus the security mechanisms recommended for SIP [RFC3261], including user authentication and authorization, MUST be supported. In addition, the media MUST be secured. DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means (see [RFC7201] [RFC7202]). Media security is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue- rtp-mapping]. Note that SIP call setup is done before any CLUE specific information is available so the authentication and authorization are based on the SIP mechanisms. The entity that will be authenticated may use the Endpoint identity or the endpoint user identity; this is an application issue and not a CLUE specific issue. Duckworth et. al. Expires July 8, 2016 [Page 71] Internet-Draft CLUE Telepresence Framework January 2016 A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document. The CLUE data model [I-D.ietf-clue-data-model-schema] defines through an XML schema the syntax to be used. Some of the information which could possibly introduce privacy concerns is the xCard information as described in section 7.1.1.10. The decision about which xCard information to send in the CLUE channel is an application policy for point to point and multipoint calls based on the authenticated identity that can be the endpoint identity or the user of the endpoint. For example the telepresence multipoint application can authenticate a user before starting a CLUE exchange with the telepresence system and have a policy per user. In addition, the (text) description field in the Media Capture attribute (section 7.1.1.6) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) attributes. An implementation SHOULD give users control over what sensitive information is sent in an Advertisement. One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene View attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information MUST NOT be used to make any authorization decisions. While other information in the CLUE protocol messages does not reveal specific identities, it can reveal characteristics and capabilities of the endpoints. That information could possibly uniquely identify specific endpoints. It might also be possible for an attacker to manipulate the information and disrupt the CLUE sessions. It would also be possible to mount a DoS attack on the CLUE endpoints if a malicious agent has access to the data channel. Thus, it MUST be possible for the endpoints to establish a channel which is secure against both message recovery and message modification. Further details on this are provided in the CLUE data channel solution document [I-D.ietf-clue-datachannel]. There are also security issues associated with the authorization to perform actions at the CLUE endpoints to invoke specific capabilities (e.g., re-arranging screens, sharing content, etc.). However, the policies and security associated with these actions Duckworth et. al. Expires July 8, 2016 [Page 72] Internet-Draft CLUE Telepresence Framework January 2016 are outside the scope of this document and the overall CLUE solution. 16. Changes Since Last Version NOTE TO THE RFC-Editor: Please remove this section prior to publication as an RFC. Changes from 24 to 25: Updates from IESG review. 1. A few clarifications in various places. 2. Change references to RFC5239 and RFC5646 from informative to normative. Changes from 23 to 24: 1. Updates to Security Considerations section. 2. Update version number of references to other CLUE documents in progress. Changes from 22 to 23: 1. Updates to Security Considerations section. 2. Update version number of references to other CLUE documents in progress. 3. Change some "MAY" to "may". 4. Fix a few grammatical errors. Changes from 21 to 22: 1. Add missing references. 2. Update version number of referenced working group drafts. 3. Minor updates for idnits issues. Changes from 20 to 21: 1. Clarify CLUE can be useful for multi-stream non-telepresence cases. 2. Remove unnecessary ambiguous sentence about optional use of CLUE protocol. Duckworth et. al. Expires July 8, 2016 [Page 73] Internet-Draft CLUE Telepresence Framework January 2016 3. Clarify meaning if Area of Capture is not specified. 4. Remove use of "conference" where it didn't fit according to the definition. Use "CLUE session" or "meeting" instead. 5. Embedded Text Attribute: Remove restriction it is for video only. 6. Minor cleanup in section 12 examples. 7. Minor editorial corrections suggested by Christian Groves. Changes from 19 to 20: 1. Define term "CLUE" in introduction. 2. Add MCC attribute Allow Subset Choice. 3. Remove phrase about reducing SDP size, replace with potentially saving consumer resources. 4. Change example of a CLUE exchange that does not require SDP exchange. 5. Language attribute uses RFC5646. 6. Change Member person type to Attendee. Add Observer type. 7. Clarify DTLS/SRTP MUST be supported. 8. Change SHOULD NOT to MUST NOT regarding using xCard or description information for authorization decisions. 9. Clarify definition of Global View. 10. Refer to signaling doc regarding interoperating with a device that does not support CLUE. 11. Various minor editorial changes from working group last call feedback. 12. Capitalize defined terms. Changes from 18 to 19: 1. Remove the Max Capture Encodings media capture attribute. 2. Refer to RTP mapping document in the MCC example section. 3. Update references to current versions of drafts in progress. Changes from 17 to 18: Duckworth et. al. Expires July 8, 2016 [Page 74] Internet-Draft CLUE Telepresence Framework January 2016 1. Add separate definition of Global View List. 2. Add diagram for Global View List structure. 3. Tweak definitions of Media Consumer and Provider. Changes from 16 to 17: 1. Ticket #59 - rename Capture Scene Entry (CSE) to Capture Scene View (CSV) 2. Ticket #60 - rename Global CSE List to Global View List 3. Ticket #61 - Proposal for describing the coordinate system. Describe it better, without conflicts if cameras point in different directions. 4. Minor clarifications and improved wording for Synchronisation Identity, MCC, Simultaneous Transmission Set. 5. Add definitions for CLUE-capable device and CLUE-enabled call, taken from the signaling draft. 6. Update definitions of Capture Device, Media Consumer, Media Provider, Endpoint, MCU, MCC. 7. Replace "middle box" with "MCU". 8. Explicitly state there can also be Media Captures that are not included in a Capture Scene View. 9. Explicitly state "A single Encoding Group MAY refer to encodings for different media types." 10. In example 12.1.1 add axes and audio captures to the diagram, and describe placement of microphones. 11. Add references to data model and signaling drafts. 12. Split references into Normative and Informative sections. Add heading number for references section. Changes from 15 to 16: 1. Remove Audio Channel Format attribute Duckworth et. al. Expires July 8, 2016 [Page 75] Internet-Draft CLUE Telepresence Framework January 2016 2. Add Audio Capture Sensitivity Pattern attribute 3. Clarify audio spatial information regarding point of capture and point on line of capture. Area of capture does not apply to audio. 4. Update section 12 example for new treatment of audio spatial information. 5. Clean up wording of some definitions, and various places in sections 5 and 10. 6. Remove individual encoding parameter paragraph from section 9. 7. Update Advertisement diagram. 8. Update Acknowledgements. 9. References to use cases and requirements now refer to RFCs. 10. Minor editorial changes. Changes from 14 to 15: 1. Add "=" and "<=" qualifiers to MaxCaptures attribute, and clarify the meaning regarding switched and composed MCC. 2. Add section 7.3.3 Global Capture Scene Entry List, and a few other sentences elsewhere that refer to global CSE sets. 3. Clarify: The Provider MUST be capable of encoding and sending all Captures (*that have an encoding group*) in a single Capture Scene Entry simultaneously. 4. Add voice activated switching example in section 12. 5. Change name of attributes Participant Info/Type to Person Info/Type. 6. Clarify the Person Info/Type attributes have the same meaning regardless of whether or not the capture has a Presentation attribute. Duckworth et. al. Expires July 8, 2016 [Page 76] Internet-Draft CLUE Telepresence Framework January 2016 7. Update example section 12.1 to be consistent with the rest of the document, regarding MCC and capture attributes. 8. State explicitly each CSE has a unique ID. Changes from 13 to 14: 1. Fill in section for Security Considerations. 2. Replace Role placeholder with Participant Information, Participant Type, and Scene Information attributes. 3. Spatial information implies nothing about how constituent media captures are combined into a composed MCC. 4. Clean up MCC example in Section 12.3.3. Clarify behavior of tiled and PIP display windows. Add audio. Add new open issue about associating incoming packets to original source capture. 5. Remove editor's note and associated statement about RTP multiplexing at end of section 5. 6. Remove editor's note and associated paragraph about overloading media channel with both CLUE and non-CLUE usage, in section 5. 7. In section 10, clarify intent of media encodings conforming to SDP, even with multiple CLUE message exchanges. Remove associated editor's note. Changes from 12 to 13: 1. Added the MCC concept including updates to existing sections to incorporate the MCC concept. New MCC attributes: MaxCaptures, SynchronisationID and Policy. 2. Removed the "composed" and "switched" Capture attributes due to overlap with the MCC concept. 3. Removed the "Scene-switch-policy" CSE attribute, replaced by MCC and SynchronisationID. 4. Editorial enhancements including numbering of the Capture attribute sections, tables, figures etc. Duckworth et. al. Expires July 8, 2016 [Page 77] Internet-Draft CLUE Telepresence Framework January 2016 Changes from 11 to 12: 1. Ticket #44. Remove note questioning about requiring a Consumer to send a Configure after receiving Advertisement. 2. Ticket #43. Remove ability for consumer to choose value of attribute for scene-switch-policy. 3. Ticket #36. Remove computational complexity parameter, MaxGroupPps, from Encoding Groups. 4. Reword the Abstract and parts of sections 1 and 4 (now 5) based on Mary's suggestions as discussed on the list. Move part of the Introduction into a new section Overview & Motivation. 5. Add diagram of an Advertisement, in the Overview of the Framework/Model section. 6. Change Intended Status to Standards Track. 7. Clean up RFC2119 keyword language. Changes from 10 to 11: 1. Add description attribute to Media Capture and Capture Scene Entry. 2. Remove contradiction and change the note about open issue regarding always responding to Advertisement with a Configure message. 3. Update example section, to cleanup formatting and make the media capture attributes and encoding parameters consistent with the rest of the document. Changes from 09 to 10: 1. Several minor clarifications such as about SDP usage, Media Captures, Configure message. 2. Simultaneous Set can be expressed in terms of Capture Scene and Capture Scene Entry. 3. Removed Area of Scene attribute. Duckworth et. al. Expires July 8, 2016 [Page 78] Internet-Draft CLUE Telepresence Framework January 2016 4. Add attributes from draft-groves-clue-capture-attr-01. 5. Move some of the Media Capture attribute descriptions back into this document, but try to leave detailed syntax to the data model. Remove the OUTSOURCE sections, which are already incorporated into the data model document. Changes from 08 to 09: 1. Use "document" instead of "memo". 2. Add basic call flow sequence diagram to introduction. 3. Add definitions for Advertisement and Configure messages. 4. Add definitions for Capture and Provider. 5. Update definition of Capture Scene. 6. Update definition of Individual Encoding. 7. Shorten definition of Media Capture and add key points in the Media Captures section. 8. Reword a bit about capture scenes in overview. 9. Reword about labeling Media Captures. 10. Remove the Consumer Capability message. 11. New example section heading for media provider behavior 12. Clarifications in the Capture Scene section. 13. Clarifications in the Simultaneous Transmission Set section. 14. Capitalize defined terms. 15. Move call flow example from introduction to overview section 16. General editorial cleanup 17. Add some editors' notes requesting input on issues Duckworth et. al. Expires July 8, 2016 [Page 79] Internet-Draft CLUE Telepresence Framework January 2016 18. Summarize some sections, and propose details be outsourced to other documents. Changes from 06 to 07: 1. Ticket #9. Rename Axis of Capture Point attribute to Point on Line of Capture. Clarify the description of this attribute. 2. Ticket #17. Add "capture encoding" definition. Use this new term throughout document as appropriate, replacing some usage of the terms "stream" and "encoding". 3. Ticket #18. Add Max Capture Encodings media capture attribute. 4. Add clarification that different capture scene entries are not necessarily mutually exclusive. Changes from 05 to 06: 1. Capture scene description attribute is a list of text strings, each in a different language, rather than just a single string. 2. Add new Axis of Capture Point attribute. 3. Remove appendices A.1 through A.6. 4. Clarify that the provider must use the same coordinate system with same scale and origin for all coordinates within the same capture scene. Changes from 04 to 05: 1. Clarify limitations of "composed" attribute. 2. Add new section "capture scene entry attributes" and add the attribute "scene-switch-policy". 3. Add capture scene description attribute and description language attribute. 4. Editorial changes to examples section for consistency with the rest of the document. Duckworth et. al. Expires July 8, 2016 [Page 80] Internet-Draft CLUE Telepresence Framework January 2016 Changes from 03 to 04: 1. Remove sentence from overview - "This constitutes a significant change ..." 2. Clarify a consumer can choose a subset of captures from a capture scene entry or a simultaneous set (in section "capture scene" and "consumer's choice..."). 3. Reword first paragraph of Media Capture Attributes section. 4. Clarify a stereo audio capture is different from two mono audio captures (description of audio channel format attribute). 5. Clarify what it means when coordinate information is not specified for area of capture, point of capture, area of scene. 6. Change the term "producer" to "provider" to be consistent (it was just in two places). 7. Change name of "purpose" attribute to "content" and refer to RFC4796 for values. 8. Clarify simultaneous sets are part of a provider advertisement, and apply across all capture scenes in the advertisement. 9. Remove sentence about lip-sync between all media captures in a capture scene. 10. Combine the concepts of "capture scene" and "capture set" into a single concept, using the term "capture scene" to replace the previous term "capture set", and eliminating the original separate capture scene concept. 17. Normative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol Data Channel", draft- ietf-clue-datachannel-11 (work in progress), November 2015. [I-D.ietf-clue-data-model-schema] Presta, R., Romano, S P., "An XML Schema for the CLUE data model", draft-ietf-clue-data-model-schema-11 (work in progress), October 2015. Duckworth et. al. Expires July 8, 2016 [Page 81] Internet-Draft CLUE Telepresence Framework January 2016 [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft- ietf-clue-protocol-06 (work in progress), October 2015. [I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., Hansen, R., "CLUE Signaling", draft-ietf-clue-signaling-06 (work in progress), August 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobsen, V., Perkins, C., "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4579] Johnston, A., Levin, O., "SIP Call Control - Conferencing for User Agents", RFC 4579, August 2006 [RFC5239] Barnes, M., Boulton, C., Levin, O., "A Framework for Centralized Conferencing", RFC 5239, June 2008. [RFC5646] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC 5646, September 2009. [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011. [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, August 2011. Duckworth et. al. Expires July 8, 2016 [Page 82] Internet-Draft CLUE Telepresence Framework January 2016 18. Informative References [I-D.ietf-clue-rtp-mapping] Even, R., Lennox, J., "Mapping RP streams to CLUE media captures", draft-ietf-clue-rtp-mapping-05 (work in progress), October 2015. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. [RFC7201] Westerlund, M., Perkins, C., "Options for Securing RTP Sessions", RFC 7201, April 2014. [RFC7202] Perkins, C., Westerlund, M., "Why RTP Does Not Mandate a Single Media Security Solution ", RFC 7202, April 2014. [RFC7205] Romanow, A., Botzko, S., Duckworth, M., Even, R., "Use Cases for Telepresence Multistreams", RFC 7205, April 2014. [RFC7262] Romanow, A., Botzko, S., Barnes, M., "Requirements for Telepresence Multistreams", RFC 7262, June 2014. 19. Authors' Addresses Mark Duckworth (editor) Polycom Andover, MA 01810 USA Email: mark.duckworth@polycom.com Andrew Pepperell Acano Uxbridge, England UK Duckworth et. al. Expires July 8, 2016 [Page 83] Internet-Draft CLUE Telepresence Framework January 2016 Email: apeppere@gmail.com Stephan Wenger Vidyo, Inc. 433 Hackensack Ave. Hackensack, N.J. 07601 USA Email: stewe@stewe.org Duckworth et. al. Expires July 8, 2016 [Page 84] ./draft-ietf-avtcore-cc-feedback-message-09.txt0000644000764400076440000011556313750064274020576 0ustar iustyiusty IETF RMCAT Working Group Z. Sarker Internet-Draft Ericsson AB Intended status: Standards Track C. Perkins Expires: May 6, 2021 University of Glasgow V. Singh callstats.io M. Ramalho November 2, 2020 RTP Control Protocol (RTCP) Feedback for Congestion Control draft-ietf-avtcore-cc-feedback-message-09 Abstract An effective RTP congestion control algorithm requires more fine- grained feedback on packet loss, timing, and ECN marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 6, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Sarker, et al. Expires May 6, 2021 [Page 1] Internet-Draft Congestion Control Feedback in RTCP November 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction For interactive real-time traffic, such as video conferencing flows, the typical protocol choice is the Real-time Transport Protocol (RTP) [RFC3550] running over the User Datagram Protocol (UDP). RTP does not provide any guarantee of Quality of Service (QoS), reliability, or timely delivery, and expects the underlying transport protocol to do so. UDP alone certainly does not meet that expectation. However, the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by which the receiver of an RTP flow can periodically send transport and media quality metrics to the sender of that RTP flow. This information can be used by the sender to perform congestion control. In the absence of standardized messages for this purpose, designers of congestion control algorithms have developed proprietary RTCP messages that convey only those parameters needed for their respective designs. As a direct result, the different congestion control designs are not interoperable. To enable algorithm evolution as well as interoperability across designs (e.g., different rate Sarker, et al. Expires May 6, 2021 [Page 2] Internet-Draft Congestion Control Feedback in RTCP November 2020 adaptation algorithms), it is highly desirable to have a generic congestion control feedback format. To help achieve interoperability for unicast RTP congestion control, this memo proposes a common RTCP feedback packet format that can be used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and hopefully also by future RTP congestion control algorithms. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. In addition the terminology defined in [RFC3550], [RFC4585], and [RFC5506] applies. 3. RTCP Feedback for Congestion Control Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], the following per-RTP packet congestion control feedback information has been determined to be necessary: o RTP sequence number: The receiver of an RTP flow needs to feed the sequence numbers of the received RTP packets back to the sender, so the sender can determine which packets were received and which were lost. Packet loss is used as an indication of congestion by many congestion control algorithms. o Packet Arrival Time: The receiver of an RTP flow needs to feed the arrival time of each RTP packet back to the sender. Packet delay and/or delay variation (jitter) is used as a congestion signal by some congestion control algorithms. o Packet Explicit Congestion Notification (ECN) Marking: If ECN [RFC3168], [RFC6679] is used, it is necessary to feed back the 2-bit ECN mark in received RTP packets, indicating for each RTP packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. If the path used by the RTP traffic is ECN capable the sender can use Congestion Experienced (ECN-CE) marking information as a congestion control signal. Sarker, et al. Expires May 6, 2021 [Page 3] Internet-Draft Congestion Control Feedback in RTCP November 2020 Every RTP flow is identified by its Synchronization Source (SSRC) identifier. Accordingly, the RTCP feedback format needs to group its reports by SSRC, sending one report block per received SSRC. As a practical matter, we note that host operating system (OS) process interruptions can occur at inopportune times. Accordingly, recording RTP packet send times at the sender, and the corresponding RTP packet arrival times at the receiver, needs to be done with deliberate care. This is because the time duration of host OS interruptions can be significant relative to the precision desired in the one-way delay estimates. Specifically, the send time needs to be recorded at the last opportunity prior to transmitting the RTP packet at the sender, and the arrival time at the receiver needs to be recorded at the earliest available opportunity. 3.1. RTCP Congestion Control Feedback Report Congestion control feedback can be sent as part of a regular scheduled RTCP report, or in an RTP/AVPF early feedback packet. If sent as early feedback, congestion control feedback MAY be sent in a non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF profile [RFC5124] is used. Irrespective of how it is transported, the congestion control feedback is sent as a Transport Layer Feedback Message (RTCP packet type 205). The format of this RTCP packet is shown in Figure 1: Sarker, et al. Expires May 6, 2021 [Page 4] Internet-Draft Congestion Control Feedback in RTCP November 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT=CCFB| PT = 205 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of RTCP packet sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of 1st RTP Stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | num_reports | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|ECN| Arrival time offset | ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of nth RTP Stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | num_reports | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|ECN| Arrival time offset | ... | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Report Timestamp (32bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RTCP Congestion Control Feedback Packet Format The first eight octets comprise a standard RTCP header, with PT=205 and FMT=CCFB indicating that this is a congestion control feedback packet, and with the SSRC set to that of the sender of the RTCP packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the above diagram with the IANA assigned RTCP feedback packet type, and remove this note) Section 6.1 of [RFC4585] requires the RTCP header to be followed by the SSRC of the RTP flow being reported upon. Accordingly, the RTCP header is followed by a report block for each SSRC from which RTP packets have been received, followed by a Report Timestamp. Each report block begins with the SSRC of the received RTP Stream on which it is reporting. Following this, the report block contains a 16-bit packet metric block for each RTP packet with sequence number in the range begin_seq to begin_seq+num_reports inclusive (calculated using arithmetic modulo 65536 to account for possible sequence number wrap-around). If the number of 16-bit packet metric blocks included Sarker, et al. Expires May 6, 2021 [Page 5] Internet-Draft Congestion Control Feedback in RTCP November 2020 in the report block is not a multiple of two, then 16 bits of zero padding MUST be added after the last packet metric block, to align the end of the packet metric blocks with the next 32 bit boundary. The value of num_reports MAY be zero, indicating that there are no packet metric blocks included for that SSRC. Each report block MUST NOT include more than 16384 packet metric blocks (i.e., it MUST NOT report on more than one quarter of the sequence number space in a single report). The contents of each 16-bit packet metric block comprises the R, ECN, and ATO fields as follows: o Received (R, 1 bit): is a boolean to indicate if the packet was received. 0 represents that the packet was not yet received and the subsequent 15-bits (ECN and ATO) in this 16-bit packet metric block are also set to 0 and MUST be ignored. 1 represents that the packet was received and the subsequent bits in the block need to be parsed. o ECN (2 bits): is the echoed ECN mark of the packet. These are set to 00 if not received, or if ECN is not used. o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP packet at the receiver, as an offset before the time represented by the Report Timestamp (RTS) field of this RTCP congestion control feedback report. The ATO field is in units of 1/1024 seconds (this unit is chosen to give exact offsets from the RTS field) so, for example, an ATO value of 512 indicates that the corresponding RTP packet arrived exactly half a second before the time instant represented by the RTS field. If the measured value is greater than 8189/1024 seconds (the value that would be coded as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over- range measurement. If the measurement is unavailable, or if the arrival time of the RTP packet is after the time represented by the RTS field, then an ATO value of 0x1FFF MUST be reported for the packet. The RTCP congestion control feedback report packet concludes with the Report Timestamp field (RTS, 32 bits). This denotes the time instant on which this packet is reporting, and is the instant from which the arrival time offset values are calculated. The value of RTS field is derived from the same clock used to generate the NTP timestamp field in RTCP Sender Report (SR) packets. It is formatted as the middle 32 bits of an NTP format timestamp, as described in Section 4 of [RFC3550]. RTCP congestion control feedback packets SHOULD include a report block for every active SSRC. The sequence number ranges reported on Sarker, et al. Expires May 6, 2021 [Page 6] Internet-Draft Congestion Control Feedback in RTCP November 2020 in consecutive reports for a given SSRC will generally be contiguous, but overlapping reports MAY be sent (and need to be sent in cases where RTP packet reordering occurs across the boundary between consecutive reports). If an RTP packet was reported as received in one report, that packet MUST also be reported as received in any overlapping reports sent later that cover its sequence number range. If reports covering overlapping sequence number ranges are sent, information in later reports updates that sent in previous reports for RTP packets included in both reports. RTCP congestion control feedback packets can be large if they are sent infrequently relative to the number of RTP data packets. If an RTCP congestion control feedback packet is too large to fit within the path MTU, its sender SHOULD split it into multiple feedback packets. The RTCP reporting interval SHOULD be chosen such that feedback packets are sent often enough that they are small enough to fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] discusses how to choose the reporting interval; specifications for RTP congestion control algorithms can also provide guidance). If duplicate copies of a particular RTP packet are received, then the arrival time of the first copy to arrive MUST be reported. If any of the copies of the duplicated packet are ECN-CE marked, then an ECN-CE mark MUST be reported that for packet; otherwise the ECN mark of the first copy to arrive is reported. If no packets are received from an SSRC in a reporting interval, a report block MAY be sent with begin_seq set to the highest sequence number previously received from that SSRC and num_reports set to zero (or, the report can simply to omitted). The corresponding SR/RR packet will have a non-increased extended highest sequence number received field that will inform the sender that no packets have been received, but it can ease processing to have that information available in the congestion control feedback reports too. A report block indicating that certain RTP packets were lost is not to be interpreted as a request to retransmit the lost packets. The receiver of such a report might choose to retransmit such packets, provided a retransmission payload format has been negotiated, but there is no requirement that it do so. 4. Feedback Frequency and Overhead There is a trade-off between speed and accuracy of reporting, and the overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses this trade-off, suggests desirable RTCP feedback rates, and provides guidance on how to configure the RTCP bandwidth fraction, etc., to make appropriate use of the reporting block described in this memo. Sarker, et al. Expires May 6, 2021 [Page 7] Internet-Draft Congestion Control Feedback in RTCP November 2020 Specifications for RTP congestion control algorithms can also provide guidance. It is generally understood that congestion control algorithms work better with more frequent feedback. However, RTCP bandwidth and transmission rules put some upper limits on how frequently the RTCP feedback messages can be sent from an RTP receiver to the RTP sender. In many cases, sending feedback once per frame is an upper bound before the reporting overhead becomes excessive, although this will depend on the media rate and more frequent feedback might be needed with high-rate media flows [I-D.ietf-rmcat-rtp-cc-feedback]. Analysis [feedback-requirements] has also shown that some candidate congestion control algorithms can operate with less frequent feedback, using a feedback interval range of 50-200ms. Applications need to negotiate an appropriate congestion control feedback interval at session setup time, based on the choice of congestion control algorithm, the expected media bit rate, and the acceptable feedback overhead. 5. Response to Loss of Feedback Packets Like all RTCP packets, RTCP congestion control feedback packets might be lost. All RTP congestion control algorithms MUST specify how they respond to the loss of feedback packets. RTCP packets do not contain a sequence number, so loss of feedback packets has to be inferred based on the time since the last feedback packet. If only a single congestion control feedback packet is lost, an appropriate response is to assume that the level of congestion has remained roughly the same as the previous report. However, if multiple consecutive congestion control feedback packets are lost, then the media sender SHOULD rapidly reduce its sending rate as this likely indicates a path failure. The RTP circuit breaker [RFC8083] provides further guidance. 6. SDP Signalling A new "ack" feedback parameter, "ccfb", is defined for use with the "a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion Control feedback packet format defined in Section 3. The ABNF definition of this SDP parameter extension is: rtcp-fb-ack-param = rtcp-fb-ack-param =/ ccfb-par ccfb-par = SP "ccfb" The payload type used with "ccfb" feedback MUST be the wildcard type ("*"). This implies that the congestion control feedback is sent for Sarker, et al. Expires May 6, 2021 [Page 8] Internet-Draft Congestion Control Feedback in RTCP November 2020 all payload types in use in the session, including any FEC and retransmission payload types. An example of the resulting SDP attribute is: a=rtcp-fb:* ack ccfb The offer/answer rules for these SDP feedback parameters are specified in Section 4.2 of the RTP/AVPF profile [RFC4585]. An SDP offer might indicate support for both the congestion control feedback mechanism specified in this memo and one or more alternative congestion control feedback mechanisms that offer substantially the same semantics. In this case, the answering party SHOULD include only one of the offered congestion control feedback mechanisms in its answer. If a re-invite offering the same set of congestion control feedback mechanisms is received, the generated answer SHOULD choose the same congestion control feedback mechanism as in the original answer where possible. When the SDP BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT [I-D.ietf-mmusic-sdp-mux-attributes]. 7. Relation to RFC 6679 Use of Explicit Congestion Notification (ECN) with RTP is described in [RFC6679]. That specifies how to negotiate the use of ECN with RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback reports. It uses an SDP "a=ecn-capable-rtp:" attribute to negotiate use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter "ecn" to negotiate the use of RTCP ECN Feedback Packets. The RTCP ECN Feedback Packet is not useful when ECN is used with the RTP Congestion Control Feedback Packet defined in this memo since it provides duplicate information. When congestion control feedback is to be used with RTP and ECN, the SDP offer generated MUST include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" to indicate that the RTP Congestion Control Feedback Packet can be used. The "a=rtcp-fb:" attribute MAY also include the "nack" parameter "ecn", to indicate that the RTCP ECN Feedback Packet is also supported. If an SDP offer signals support for both RTP Congestion Control Feedback Packets and the RTCP ECN Feedback Packet, the answering party SHOULD signal support for one, but not both, formats in its SDP answer to avoid sending duplicate feedback. Sarker, et al. Expires May 6, 2021 [Page 9] Internet-Draft Congestion Control Feedback in RTCP November 2020 When using ECN with RTP, the guidelines in Section 7.2 of [RFC6679] MUST be followed to initiate the use of ECN in an RTP session. The guidelines in Section 7.3 of [RFC6679] MUST also be followed about ongoing use of ECN within an RTP session, with the exception that feedback is sent using the RTCP Congestion Control Feedback Packets described in this memo rather than using RTP ECN Feedback Packets. Similarly, the guidance in Section 7.4 of [RFC6679] around detecting failures MUST be followed, with the exception that the necessary information is retrieved from the RTCP Congestion Control Feedback Packets rather than from RTP ECN Feedback Packets. 8. Design Rationale The primary function of RTCP SR/RR packets is to report statistics on the reception of RTP packets. The reception report blocks sent in these packets contain information about observed jitter, fractional packet loss, and cumulative packet loss. It was intended that this information could be used to support congestion control algorithms, but experience has shown that it is not sufficient for that purpose. An efficient congestion control algorithm requires more fine-grained information on per-packet reception quality than is provided by SR/RR packets to react effectively. The feedback format defined in this memo provides such fine-grained feedback. Several other RTCP extensions also provide more detailed feedback than SR/RR packets: TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104] include a Temporary Maximum Media Bit Rate (TMMBR) message. This is used to convey a temporary maximum bit rate limitation from a receiver of RTP packets to their sender. Even though it was not designed to replace congestion control, TMMBR has been used as a means to do receiver based congestion control where the session bandwidth is high enough to send frequent TMMBR messages, especially when used with non-compound RTCP packets [RFC5506]. This approach requires the receiver of the RTP packets to monitor their reception, determine the level of congestion, and recommend a maximum bit rate suitable for current available bandwidth on the path; it also assumes that the RTP sender can/will respect that bit rate. This is the opposite of the sender-based congestion control approach suggested in this memo, so TMMBR cannot be used to convey the information needed for a sender-based congestion control. TMMBR could, however, be viewed a complementary mechanism that can inform the sender of the receiver's current view of acceptable maximum bit rate. Mechanisms that convey the receiver's estimate of the maximum available bit-rate provide similar feedback. Sarker, et al. Expires May 6, 2021 [Page 10] Internet-Draft Congestion Control Feedback in RTCP November 2020 RTCP Extended Reports (XR): Numerous RTCP extended report (XR) blocks have been defined to report details of packet loss, arrival times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It is possible to combine several such XR blocks into a compound RTCP packet, to report the detailed loss, arrival time, and ECN marking information needed for effective sender-based congestion control. However, the result has high overhead both in terms of bandwidth and complexity, due to the need to stack multiple reports. Transport-wide Congestion Control: The format defined in this memo provides individual feedback on each SSRC. An alternative is to add a header extension to each RTP packet, containing a single, transport-wide, packet sequence number, then have the receiver send RTCP reports giving feedback on these additional sequence numbers [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an approach adds the per-packet overhead of the header extension (8 octets per packet in the referenced format), but reduces the size of the feedback packets, and can simplify the rate calculation at the sender if it maintains a single rate limit that applies to all RTP packets sent irrespective of their SSRC. Equally, the use of transport-wide feedback makes it more difficult to adapt the sending rate, or respond to lost packets, based on the reception and/or loss patterns observed on a per-SSRC basis (for example, to perform differential rate control and repair for audio and video flows, based on knowledge of what packets from each flow were lost). Transport-wide feedback is also a less natural fit with the wider RTP framework, which makes extensive use of per-SSRC sequence numbers and feedback. Considering these issues, we believe it appropriate to design a new RTCP feedback mechanism to convey information for sender-based congestion control algorithms. The new congestion control feedback RTCP packet described in Section 3 provides such a mechanism. 9. Acknowledgements This document is based on the outcome of a design team discussion in the RTP Media Congestion Avoidance Techniques (RMCAT) working group. The authors would like to thank David Hayes, Stefan Holmer, Randell Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable feedback. 10. IANA Considerations The IANA is requested to register one new RTP/AVPF Transport-Layer Feedback Message in the table for FMT values for RTPFB Payload Types [RFC4585] as defined in Section 3.1: Sarker, et al. Expires May 6, 2021 [Page 11] Internet-Draft Congestion Control Feedback in RTCP November 2020 Name: CCFB Long name: RTP Congestion Control Feedback Value: (to be assigned by IANA) Reference: (RFC number of this document, when published) The IANA is also requested to register one new SDP "rtcp-fb" attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" Attribute Values) registry: Value name: ccfb Long name: Congestion Control Feedback Usable with: ack Mux: IDENTICAL-PER-PT Reference: (RFC number of this document, when published) 11. Security Considerations The security considerations of the RTP specification [RFC3550], the applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), and the RTP congestion control algorithm that is in use (e.g., [RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply. A receiver that intentionally generates inaccurate RTCP congestion control feedback reports might be able trick the sender into sending at a greater rate than the path can support, thereby causing congestion on the path. This will negatively impact the quality of experience of that receiver, and potentially cause denial of service to other traffic sharing the path and excessive resource usage at the media sender. Since RTP is an unreliable transport, a sender can intentionally drop a packet, leaving a gap in the RTP sequence number space without causing serious harm, to check that the receiver is correctly reporting losses (this needs to be done with care and some awareness of the media data being sent, to limit impact on the user experience). An on-path attacker that can modify RTCP congestion control feedback packets can change the reports to trick the sender into sending at either an excessively high or excessively low rate, leading to denial of service. The secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack. An off-patch attacker that can spoof RTCP congestion control feedback packets can similarly trick a sender into sending at an incorrect rate, leading to denial of service. This attack is difficult, since the attacker needs to guess the SSRC and sequence number in addition to the destination transport address. As with on-patch attacks, the secure RTCP profile [RFC3711] can be used to authenticate RTCP packets to protect against this attack. Sarker, et al. Expires May 6, 2021 [Page 12] Internet-Draft Congestion Control Feedback in RTCP November 2020 12. References 12.1. Normative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-19 (work in progress), August 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . Sarker, et al. Expires May 6, 2021 [Page 13] Internet-Draft Congestion Control Feedback in RTCP November 2020 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [feedback-requirements] "RMCAT Feedback Requirements", <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 1.pdf>. [I-D.alvestrand-rmcat-remb] Alvestrand, H., "RTCP message for Receiver Estimated Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in progress), October 2013. [I-D.holmer-rmcat-transport-wide-cc-extensions] Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions for Transport-wide Congestion Control", draft-holmer- rmcat-transport-wide-cc-extensions-01 (work in progress), October 2015. [I-D.ietf-rmcat-gcc] Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real- Time Communication", draft-ietf-rmcat-gcc-02 (work in progress), July 2016. Sarker, et al. Expires May 6, 2021 [Page 14] Internet-Draft Congestion Control Feedback in RTCP November 2020 [I-D.ietf-rmcat-rtp-cc-feedback] Perkins, C., "RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences", draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress), November 2019. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, . [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 2017, . [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, "Shared Bottleneck Detection for Coupled Congestion Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, June 2018, . [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media", RFC 8698, DOI 10.17487/RFC8698, February 2020, . Authors' Addresses Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 21 Stockholm 164 40 Sweden Phone: +46107173743 Email: zaheduzzaman.sarker@ericsson.com Sarker, et al. Expires May 6, 2021 [Page 15] Internet-Draft Congestion Control Feedback in RTCP November 2020 Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Varun Singh CALLSTATS I/O Oy Annankatu 31-33 C 42 Helsinki 00100 Finland Email: varun.singh@iki.fi URI: http://www.callstats.io/ Michael A. Ramalho 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202-5122 USA Phone: +1 732 832 9723 Email: mar42@cornell.edu URI: http://ramalho.webhop.info/ Sarker, et al. Expires May 6, 2021 [Page 16] ./draft-ietf-clue-protocol-19.txt0000644000764400076440000043664013507635103016171 0ustar iustyiusty CLUE Working Group R. Presta Internet-Draft S. P. Romano Intended status: Experimental University of Napoli Expires: January 6, 2020 July 5, 2019 Protocol for Controlling Multiple Streams for Telepresence (CLUE) draft-ietf-clue-protocol-19 Abstract The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Presta & P. Romano Expires January 6, 2020 [Page 1] Internet-Draft draft-ietf-clue-protocol-19 July 2019 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 4 5. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7 5.1. options . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. optionsResponse . . . . . . . . . . . . . . . . . . . . . 11 5.3. advertisement . . . . . . . . . . . . . . . . . . . . . . 12 5.4. ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5. configure . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. configureResponse . . . . . . . . . . . . . . . . . . . . 15 5.7. Response codes and reason strings . . . . . . . . . . . . 16 6. Protocol state machines . . . . . . . . . . . . . . . . . . . 18 6.1. Media Provider's state machine . . . . . . . . . . . . . 21 6.2. Media Consumer's state machine . . . . . . . . . . . . . 22 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Extension example . . . . . . . . . . . . . . . . . . . . 27 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Call flow example . . . . . . . . . . . . . . . . . . . . . . 34 10.1. CLUE message nr. 1: 'options' . . . . . . . . . . . . . 37 10.2. CLUE message nr. 2: 'optionsResponse' . . . . . . . . . 39 10.3. CLUE message nr. 3: 'advertisement' . . . . . . . . . . 39 10.4. CLUE message nr. 4: 'configure + ack' . . . . . . . . . 47 10.5. CLUE message nr. 5: 'confResponse' . . . . . . . . . . . 47 10.6. CLUE message nr. 6: 'advertisement' . . . . . . . . . . 48 10.7. CLUE message nr. 7: 'ack' . . . . . . . . . . . . . . . 58 10.8. CLUE message nr. 8: 'configure' . . . . . . . . . . . . 58 10.9. CLUE message nr. 9: 'confResponse' . . . . . . . . . . . 59 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 61 12.2. XML Schema registration . . . . . . . . . . . . . . . . 62 12.3. MIME Media Type Registration for 'application/clue+xml' 62 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . 63 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 63 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . 64 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 14.1. Normative References . . . . . . . . . . . . . . . . . . 66 Presta & P. Romano Expires January 6, 2020 [Page 2] Internet-Draft draft-ietf-clue-protocol-19 July 2019 14.2. Informative References . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 1. Introduction The CLUE protocol is an application protocol used by two CLUE Participants to enhance the experience of a multimedia telepresence session. The main goals of the CLUE protocol are: 1. enabling a Media Provider (MP) to properly announce its current telepresence capabilities to a Media Consumer (MC) in terms of available media captures, groups of encodings, simultaneity constraints and other information defined in [I-D.ietf-clue-framework]; 2. enabling an MC to request the desired multimedia streams from the offering MP. CLUE-capable endpoints are connected by means of the CLUE data channel, an SCTP over DTLS channel that is opened and established as described in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing over such a channel are detailed in this document, both syntactically and semantically. In Section 4 we provide a general overview of the CLUE protocol. CLUE protocol messages are detailed in Section 5. The CLUE Protocol state machines are introduced in Section 6. Versioning and extensions are discussed in Section 7 and Section 8, respectively. The XML schema defining the CLUE messages is reported in Section 9. 2. Terminology This document refers to the same terminology used in [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein some of the main terms used in the document. The definition of "CLUE Participant" herein proposed is not imported from any of the above documents. Capture Encoding: A specific encoding of a Media Capture, to be sent via RTP [RFC3550]. CLUE Participant (CP): An entity able to use the CLUE protocol within a telepresence session. It can be an endpoint or an MCU (Multipoint Control Unit) able to use the CLUE protocol. Presta & P. Romano Expires January 6, 2020 [Page 3] Internet-Draft draft-ietf-clue-protocol-19 July 2019 CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol and the principles of CLUE negotiation, and seeks CLUE-enabled calls. Endpoint: A CLUE-capable device that is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices that source and sink media streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one [RFC3261] User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. Multipoint Control Unit (MCU): a CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC7667]. An MCU includes an [RFC4353]-like Mixer, without the [RFC4353] requirement to send media to each participant. Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. Media Capture: a source of Media, such as from one or more Capture Devices or constructed from other Media streams. Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an MCU) able to receive Capture Encodings. Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an MCU) able to send Capture Encodings. Stream: a Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Overview of the CLUE protocol The CLUE protocol is conceived to enable CLUE telepresence sessions. It is designed in order to address SDP limitations in terms of the description of some information about the multimedia streams that are involved in a real-time multimedia conference. Indeed, by simply Presta & P. Romano Expires January 6, 2020 [Page 4] Internet-Draft draft-ietf-clue-protocol-19 July 2019 using SDP it is not possible to convey information about the features of the flowing multimedia streams that are needed to enable a "being there" rendering experience. Such information is contained in the CLUE framework document [I-D.ietf-clue-framework] and formally defined and described in the CLUE data model document [I-D.ietf-clue-data-model-schema]. The CLUE protocol represents the mechanism for the exchange of telepresence information between CLUE Participants. It mainly provides the messages to enable a Media Provider to advertise its telepresence capabilities and to enable a Media Consumer to select the desired telepresence options. The CLUE protocol, as defined in the following, is a stateful, client-server, XML-based application protocol. CLUE protocol messages flow on a reliable and ordered SCTP over DTLS transport channel connecting two CLUE Participants. Messages carry information taken from the XML-based CLUE data model ([I-D.ietf-clue-data-model-schema]). Three main communication phases can be identified: 1. Establishment of the CLUE data channel: in this phase, the CLUE data channel setup takes place. If it completes successfully, the CPs are able to communicate and start the initiation phase. 2. Negotiation of the CLUE protocol version and extensions (initiation phase): the CPs connected via the CLUE data channel agree on the version and on the extensions to be used during the telepresence session. Special CLUE messages are used for such a task ('options' and 'optionsResponse'). The version and extensions negotiation can be performed once during the CLUE session and only at this stage. At the end of that basic negotiation, each CP starts its activity as a CLUE MP and/or CLUE MC. 3. CLUE telepresence capabilities description and negotiation: in this phase, the MP-MC dialogues take place on the data channel by means of the CLUE protocol messages. As soon as the channel is ready, the CLUE Participants must agree on the protocol version and extensions to be used within the telepresence session. CLUE protocol version numbers are characterized by a major version number (single digit) and a minor version number (single digit), both unsigned integers, separated by a dot. While minor version numbers denote backward compatible changes in the context of a given major version, different major version numbers generally indicate a lack of interoperability between the protocol implementations. In order to correctly establish a CLUE dialogue, the involved CPs must have in common a major version number (see Section 7 for further details). The subset of the extensions Presta & P. Romano Expires January 6, 2020 [Page 5] Internet-Draft draft-ietf-clue-protocol-19 July 2019 that are allowed within the CLUE session is also determined in the initiation phase. It includes only the extensions that are supported by both parties. A mechanism for the negotiation of the CLUE protocol version and extensions is part of the initiation phase. According to such a solution, the CP that is the CLUE Channel Initiator (CI) issues a proper CLUE message ('options') to the CP that is the Channel Receiver (CR) specifying the supported version and extensions. The CR then answers by selecting the subset of the CI extensions that it is able to support and determines the protocol version to be used. After the negotiation phase is completed, CLUE Participants describe and agree on the media flows to be exchanged. In many cases CPs will seek to both transmit and receive media. Hence in a call between two CPs, A and B, there would be two separate message exchange sequences, as follows: 1. the one needed to describe and set up the media streams sent from A to B, i.e., the dialogue between A's Media Provider side and B's Media Consumer side 2. the one needed to describe and set up the media streams sent from B to A, i.e., the dialogue between B's Media Provider side and A's Media Consumer side CLUE messages for the media session description and negotiation are designed by considering the MP side as the server side of the protocol, since it produces and provides media streams, and the MC side as the client side of the protocol, since it requests and receives media streams. The messages that are exchanged to set up the telepresence media session are described by focusing on a single MP-MC dialogue. The MP first advertises its available media captures and encoding capabilities to the MC, as well as its simultaneity constraints, according to the information model defined in [I-D.ietf-clue-framework]. The CLUE message conveying the MP's multimedia offer is the 'advertisement' message. Such message leverages the XML data model definitions provided in [I-D.ietf-clue-data-model-schema]. The MC selects the desired streams of the MP by using the 'configure' message, which makes reference to the information carried in the previously received 'advertisement'. Besides 'advertisement' and 'configure', other messages have been conceived in order to provide all the needed mechanisms and operations. Such messages are detailed in the following sections. Presta & P. Romano Expires January 6, 2020 [Page 6] Internet-Draft draft-ietf-clue-protocol-19 July 2019 5. Protocol messages CLUE protocol messages are textual, XML-based messages that enable the configuration of the telepresence session. The formal definition of such messages is provided in the XML Schema provided at the end of this document (Section 9). This section includes non-normative excerpts of the schema to aid in describing it. The XML definitions of the CLUE information provided in [I-D.ietf-clue-data-model-schema] are included within some CLUE protocol messages (namely the 'advertisement' and the 'configure' messages), in order to use the concepts defined in [I-D.ietf-clue-framework]. The CLUE protocol messages are the following: o options o optionsResponse o advertisement o ack o configure o configureResponse While the 'options' and 'optionsResponse' messages are exchanged in the initiation phase between the CPs, the other messages are involved in MP-MC dialogues. Please note that the word "dialog" in this document is not related to SIP's usage of the same term. It refers to message exchange sequences between a CLUE Media Provider and a Clue Media Consumer. Each CLUE message inherits a basic structure depicted in the following excerpt (Figure 1): Presta & P. Romano Expires January 6, 2020 [Page 7] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Figure 1: Structure of a CLUE message The information contained in each CLUE message is: o clueId: an optional XML element containing the identifier (in the form of a generic string) of the CP within the telepresence system; o sequenceNr: an XML element containing the local message sequence number. The sender MUST increment the sequence numbers by one for each new message sent, the receiver MUST remember the most recent sequence number received and send back a 402 error if it receives a message with an unexpected sequence number (e.g., sequence number gap, repeated sequence number, sequence number too small). The initial sequence number can be chosen randomly by each party; o protocol: a mandatory attribute set to "CLUE", identifying the procotol the messages refer to; o v: a mandatory attribute carrying the version of the protocol. The content of the "v" attribute is composed by the major version number followed by a dot and then by the minor version number of the CLUE protocol in use. The major number cannot be "0" and, if it is more than one digit, it cannot start with a "0". Allowed values are of this kind are, e.g., "1.3", "2.0", "20.44" etc. This document describes version 1.0. Each CP is responsible for creating and updating up to three independent streams of sequence numbers in messages it sends: (i) one for the messages sent in the initiation phase, (ii) one for the Presta & P. Romano Expires January 6, 2020 [Page 8] Internet-Draft draft-ietf-clue-protocol-19 July 2019 messages sent as MP (if it is acting as a MP), and (iii) one for the messages sent as MC (if it is acting as a MC). In particular, CLUE response messages ('optionsResponse', 'ack', 'configureResponse') derive from a base type, inheriting from the clueMessageType, which is defined as follows (Figure 2): Figure 2: Structure of CLUE response messages The elements and get populated as detailed in Section 5.7 5.1. options The 'options' message is sent by the CLUE Participant that is the Channel Initiator to the CLUE Participant that is the Channel Receiver as soon as the CLUE data channel is ready. Besides the information envisioned in the basic structure, it specifies: o : a mandatory boolean field set to "true" if the CP is able to act as a MP o : a mandatory boolean field set to "true" if the CP is able to act as a MC o : the list of the supported versions o : the list of the supported extensions The XML Schema of such a message is reported below (Figure 3): Presta & P. Romano Expires January 6, 2020 [Page 9] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Presta & P. Romano Expires January 6, 2020 [Page 10] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Figure 3: Structure of CLUE 'options' message contains the list of the versions that are supported by the CI, each one represented in a child element. The content of each element is a string made by the major version number followed by a dot and then by the minor version number (e.g., 1.3 or 2.4). Exactly one element MUST be provided for each major version supported, containing the maximum minor version number of such a version, since all minor versions are backward compatible. If no is carried within the 'options' message, the CI supports only the version declared in the "v" attribute and all the versions having the same major version number and lower minor version number. For example, if the "v" attribute has a value of "3.4" and there is no tag in the 'options' message, it means the CI supports only major version 3 with all the minor versions comprised between 3.0 and 3.4, with version 3.4 included. If a is provided, at least one tag MUST be included. In this case, the "v" attribute SHOULD be set to the largest minor version of the smallest major version advertised in the list. Indeed, the intention behind the "v" attribute is that some implementation that receives a version number in the "v" field with a major number higher than it understands is supposed to close the connection, since it runs a risk of misinterpreting the contents of messages. The minor version is less useful in this context, since minor versions are defined to be both backwards and forwards compatible, but it is more useful to know the highest minor version supported than some random minor version, as it indicates the full feature set that is supported. The reason why it is less useful is that the value can in any case be parsed out of the list. The element specifies the list of extensions supported by the CI. If there is no in the 'options' message, the CI does not support anything other than what is envisioned in the versions it supports. For each extension, an element is provided. An extension is characterized by a name, an XML schema of reference where the extension is defined, and the version of the protocol which the extension refers to. 5.2. optionsResponse The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply to the 'options' message. The 'optionsResponse' contains a mandatory response code and a reason string indicating the processing result of the 'options' message. If the responseCode is between 200 and 299 inclusive, the response MUST also include , , and elements; it MAY Presta & P. Romano Expires January 6, 2020 [Page 11] Internet-Draft draft-ietf-clue-protocol-19 July 2019 include them for any other response code. and elements (which are of a boolean nature) are associated with the supported roles (in terms of, respectively MP and MC), similarly to what the CI does in the 'options' message. The field indicates the highest commonly supported version number. The content of the element MUST be a string made of the major version number followed by a dot and then by the minor version number (e.g., 1.3 or 2.4). Finally, the commonly supported extensions are copied in the field. Figure 4: Structure of CLUE 'optionsResponse' message Upon reception of the 'optionsResponse' the version to be used is the one provided in the tag of the message. The following CLUE messages MUST use such a version number in the "v" attribute. The allowed extensions in the CLUE dialogue are those indicated in the of the 'optionsResponse' message. 5.3. advertisement The 'advertisement' message is used by each MP to advertise the available media captures and related information to the corresponding MC. The MP sends an 'advertisement' to the MC as soon as it is ready after the successful completion of the initiation phase, i.e., as soon as the version and the extensions of the CLUE protocol are agreed between the CPs. During a single CLUE session, an MP may send Presta & P. Romano Expires January 6, 2020 [Page 12] Internet-Draft draft-ietf-clue-protocol-19 July 2019 new 'advertisement' messages to replace the previous advertisement, if, for instance, its CLUE telepresence media capabilities change mid-call. A new 'advertisement' completely replaces the previous 'advertisement'. The 'advertisement' structure is defined in the schema excerpt below (Figure 5). The 'advertisement' contains elements compliant with the CLUE data model that characterize the MP's telepresence offer. Namely, such elements are: the list of the media captures (), of the encoding groups (), of the capture scenes (), of the simultaneous sets (), of the global views (), and of the represented participants (). Each of them is fully described in the CLUE framework document and formally defined in the CLUE data model document. Figure 5: Structure of CLUE 'advertisement' message 5.4. ack The 'ack' message is sent by a MC to a MP to acknowledge an 'advertisement' message. As it can be seen from the message schema provided in the following excerpt (Figure 6), the 'ack' contains a Presta & P. Romano Expires January 6, 2020 [Page 13] Internet-Draft draft-ietf-clue-protocol-19 July 2019 response code and may contain a reason string for describing the processing result of the 'advertisement'. The carries the sequence number of 'advertisement' message the 'ack' refers to. Figure 6: Structure of CLUE 'ack' message 5.5. configure The 'configure' message is sent from a MC to a MP to list the advertised captures the MC wants to receive. The MC MUST send a 'configure' after the reception of an 'advertisement', as well as each time it wants to request other captures that have been previously advertised by the MP. The content of the 'configure' message is shown below (Figure 7). Presta & P. Romano Expires January 6, 2020 [Page 14] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Figure 7: Structure of CLUE 'configure' message The element contains the sequence number of the 'advertisement' message the 'configure' refers to. The optional element, when present, contains a success response code, as defined in Section 5.7. It indicates that the 'configure' message also acknowledges with success the referred advertisement ('configure' + 'ack' message). The element MUST NOT be present if an 'ack' message (associated with the advertisement carrying that specific sequence number) has been already sent back to the MP. The most important content of the 'configure' message is the list of the capture encodings provided in the element (see [I-D.ietf-clue-data-model-schema] for the definition of ). Such an element contains a sequence of capture encodings, representing the streams to be instantiated. 5.6. configureResponse The 'configureResponse' message is sent from the MP to the MC to communicate the processing result of requests carried in the previously received 'configure' message. It contains (Figure 8) a response code (and optionally a reason string) indicating either the success or the failure (along with failure details) of a 'configure' request processing. Following, the field contains the sequence number of the 'configure' message the response refers to. There is no partial execution of commands. As an example, if a Presta & P. Romano Expires January 6, 2020 [Page 15] Internet-Draft draft-ietf-clue-protocol-19 July 2019 MP is able to understand all the selected capture encodings except one, then the whole command fails and nothing is instantiated. Figure 8: Structure of CLUE 'configureResponse' message 5.7. Response codes and reason strings Response codes are defined as a sequence of three digits. A well- defined meaning is associated with the first digit. Response codes beginning with "2" are associated with successful responses. Response codes that do not begin with either "2" or "1" indicate an error response, i.e., that an error occurred while processing a CLUE request. In particular, response codes beginning with "3" indicate problems with the XML content of the message ("Bad syntax", "Invalid value", etc.), while response codes beginning with "4" refer to problems related to CLUE protocol semantics ("Invalid sequencing", "Version not supported", etc.). 200, 300 and 400 codes are the most generic ones in their respective categories. Further response codes can be either defined in future versions of the protocol, or defined by leveraging the extension mechanism. In both cases, the new response codes MUST be registered with IANA. Such new response codes MUST NOT override the ones here defined and they MUST respect the semantics of the first code digit. This document does not define response codes starting with "1", and such response codes are not allowed to appear in major version 1 of the CLUE protocol. The range from 100 to 199 inclusive is reserved for future major versions of the protocol to define response codes for delayed or incomplete operations if necessary. Response codes starting with "5" through "9" are reserved for future major versions of the protocol to define new classes of response, and are not Presta & P. Romano Expires January 6, 2020 [Page 16] Internet-Draft draft-ietf-clue-protocol-19 July 2019 allowed in major version 1 of the CLUE protocol. Response codes starting with "0" are not allowed. The response codes and strings defined for use with version 1 of the CLUE protocol are listed in Figure 9. The "Description" text contained in the table can be sent in the element of a response message. Implementations can (and are encouraged to) include more specific descriptions of the error condition, if possible. +-----------------+----------------------+--------------------------+ | | | | | Response code | Reason string | Description | | | | | +-----------------+----------------------+--------------------------+ | | | | | 200 | Success | The request has been | | | | successfully processed. | | | | | +-----------------+----------------------+--------------------------+ | | | | | 300 | Low-level request | A generic low-level | | | error. | request error has | | | | occurred. | | | | | +-----------------+----------------------+--------------------------+ | | | | | 301 | Bad syntax | The XML syntax of the | | | | message is not correct. | +-----------------+----------------------+--------------------------+ | | | | | 302 | Invalid value | The message | | | | contains an invalid | | | | parameter value. | +-----------------+----------------------+--------------------------+ | | | | | 303 | Conflicting values | The message | | | | contains values that | | | | cannot be used together.| +-----------------+----------------------+--------------------------+ | | | | | 400 | Semantic errors | Semantic errors in the | | | | received CLUE protocol | | | | message. | | | | | +-----------------+----------------------+--------------------------+ Presta & P. Romano Expires January 6, 2020 [Page 17] Internet-Draft draft-ietf-clue-protocol-19 July 2019 | | | | | 401 | Version not supported| The protocol version | | | | used in the message | | | | is not supported. | | | | | +-----------------+----------------------+--------------------------+ | | | | | 402 | Invalid sequencing | Sequence number gap; | | | | repeated sequence number;| | | | sequence number outdated.| +-----------------+----------------------+--------------------------+ | | | | | 403 | Invalid identifier | The clueId used in | | | | the message is | | | | not valid or unknown. | +-----------------+----------------------+--------------------------+ | | | The sequence number of | | 404 | advertisement | the advertisement the | | | Expired | configure refers to is | | | | out of date. | +-----------------+----------------------+--------------------------+ | | | | | 405 | Subset choice not | The subset choice is not | | | allowed | allowed for the specified| | | | Multiple Content Capture | +-----------------+----------------------+--------------------------+ Figure 9: CLUE response codes 6. Protocol state machines The CLUE protocol is an application protocol used between two CPs in order to properly configure a multimedia telepresence session. CLUE protocol messages flow over the CLUE Data Channel, a DTLS/SCTP channel established as depicted in [I-D.ietf-clue-datachannel]. We herein discuss the state machines associated, respectively, with the CLUE Participant (Figure 10), with the MC role (Figure 11) and with the MP role (Figure 12). Endpoints often wish to both send and receive media, i.e., act as both MP and MC. As such there will often be two sets of messages flowing in opposite directions; the state machines of these two flows do not interact with each other. Only the CLUE application logic is considered. The interaction of CLUE protocol and SDP negotiations for the media streams exchanged is treated in [I-D.ietf-clue-signaling]. Presta & P. Romano Expires January 6, 2020 [Page 18] Internet-Draft draft-ietf-clue-protocol-19 July 2019 The main state machines focus on the behavior of the CLUE Participant (CP) acting as a CLUE Channel Initiator/Receiver (CI/CR). The initial state is the IDLE one. When in the IDLE state, the CLUE data channel is not established and no CLUE-controlled media are exchanged between the two considered CLUE-capable devices (if there is an ongoing exchange of media streams, such media streams are not currently CLUE-controlled). When the CLUE data channel sets up ("start channel"), the CP moves from the IDLE state to the CHANNEL SETUP state. If the CLUE data channel is successfully set up ("channel established"), the CP moves from the CHANNEL SETUP state to the OPTIONS state. Otherwise if "channel error", it moves back to the IDLE state. The same transition happens if the CLUE-enabled telepresence session ends ("session ends"), i.e., when an SDP negotiation for removing the CLUE data channel is performed. When in the OPTIONS state, the CP addresses the initiation phase where both parts agree on the version and on the extensions to be used in the subsequent CLUE messages exchange phase. If the CP is the Channel Initiator (CI), it sends an 'options' message and waits for the 'optionsResponse' message. If the CP is the Channel Receiver (CR), it waits for the 'options' message and, as soon as it arrives, replies with the 'optionsResponse' message. If the negotiation is successfully completed ("OPTIONS phase success"), the CP moves from the OPTIONS state to the ACTIVE state. If the initiation phase fails ("OPTIONS phase failure"), the CP moves from the OPTIONS state to the IDLE state. The initiation phase might fail because of one of the following reasons: 1. the CI receives an 'optionsResponse' with an error response code 2. the CI does not receive any 'optionsResponse' and a timeout error is raised 3. the CR does not receive any 'options' and a timeout error is raised When in the ACTIVE state, the CP starts the envisioned sub-state machines (i.e., the MP state machine and the MC state machine) according to the roles it plays in the telepresence sessions. Such roles have been previously declared in the 'options' and 'optionsResponse' messages involved in the initiation phase (see OPTIONS sections Section 5.1 and Section 5.2 for the details). When in the ACTIVE state, the CP delegates the sending and the processing of the CLUE messages to the appropriate MP/MC sub-state machines. If Presta & P. Romano Expires January 6, 2020 [Page 19] Internet-Draft draft-ietf-clue-protocol-19 July 2019 the CP receives a further 'options'/'optionsResponse' message, it MUST ignore the message and stay in the ACTIVE state. +----+ +---------------------->|IDLE|<----------------------------+ | +-+--+ | | | | | | start | | | channel | | v | | channel error/ +--------+ | | session ends | CHANNEL| | +----------------------+ SETUP | | | +--+-----+ | | | | | | channel | | | established | | channel error/ v OPTIONS phase | | session ends +-------+ failure | +-----------------------+OPTIONS+--------------------------+ | +-+-----+ | | | | OPTIONS phase | | success | v | channel error/ +---------+ | session ends | ACTIVE | +----------------------+ | | +----+ +------------------+ | | MP | | send/receive | | +----+ | CLUE messages | | |<-----------------+ | +----+ | | | MC | | | +----+ | | | +---------+ Figure 10: CLUE Participant state machine Presta & P. Romano Expires January 6, 2020 [Page 20] Internet-Draft draft-ietf-clue-protocol-19 July 2019 6.1. Media Provider's state machine As soon as the sub-state machine of the MP (Figure 11) is activated, it is in the ADV state. In the ADV state, the MP prepares the 'advertisement' message reflecting its actual telepresence capabilities. After the 'advertisement' has been sent ("advertisement sent"), the MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack' message with a successful response code arrives ("ack received"), the MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an 'ack' message with an error response code), the MP moves back to the ADV state for preparing a new 'advertisement'. When in the WAIT FOR ACK state, if a 'configure' message with the element set to TRUE arrives ("configure+ack received"), the MP goes directly to the CONF RESPONSE state. 'configure+ack' messages referring to out-of- date (i.e., having a sequence number less than the highest generated so far) advertisements MUST be ignored, i.e., they do not trigger any state transition. If the telepresence settings of the MP change while in the WAIT FOR ACK state ("changed telepresence settings"), the MP switches from the WAIT FOR ACK state to the ADV state to create a new 'advertisement'. When in the WAIT FOR CONF state, the MP listens to the channel for a 'configure' request coming from the MC. When a 'configure' arrives ("configure received"), the MP switches to the CONF RESPONSE state. If the telepresence settings change in the meanwhile ("changed telepresence settings"), the MP moves from the WAIT FOR CONF back to the ADV state to create the new 'advertisement' to be sent to the MC. The MP in the CONF RESPONSE state processes the received 'configure' in order to produce a 'configureResponse' message. If the MP successfully processes the MC's configuration, then it sends a 200 'configureResponse' ("success configureResponse sent") and moves to the ESTABLISHED state. If there are errors in the 'configure' processing, then the MP issues a 'configureResponse' carrying an error response code and it goes back to the WAIT FOR CONF state to wait for a new configuration request. Finally, if there are changes in the MP's telepresence settings ("changed telepresence settings"), the MP switches to the ADV state. The MP in the ESTABLISHED state has successfully negotiated the media streams with the MC by means of the CLUE messages. If there are changes in the MP's telepresence settings ("changed telepresence settings"), the MP moves back to the ADV state. In the ESTABLISHED state, the CLUE-controlled media streams of the session are those described in the last successfully processed 'configure' message. Presta & P. Romano Expires January 6, 2020 [Page 21] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Messages not shown for a state do not cause the state to change. +-----+ +------------>| ADV |<-------------------+ | +-+---+ | | advertisement| NACK received | | sent| | | v | changed| +--------+ | telepresence+-------------+WAIT FOR+-----------------+ settings| +----------+ ACK | | |configure +-+------+ | | + ack | | |received |ack received | | v | | +--------+ +-------------+WAIT FOR| | | | CONF | | | +-+------+<-----------------------------+ | | | | | | |configure received | | | v | | +--------->+---------+ error configureResponse sent| +-------------+CONF |-----------------------------+ | +--------->|RESPONSE + | | +---------+ | | | | | |success | | |configureResponse | | |sent | | | | | | | |configure | | |received v | | +-----------+ | +----------+ESTABLISHED| +-------------+-----------+ Figure 11: Media Provider's state machine 6.2. Media Consumer's state machine As soon as the sub-state machine of the MC (Figure 12) is activated, it is in the WAIT FOR ADV state. An MC in the WAIT FOR ADV state is waiting for an 'advertisement' coming from the MP. If the Presta & P. Romano Expires January 6, 2020 [Page 22] Internet-Draft draft-ietf-clue-protocol-19 July 2019 'advertisement' arrives ("ADV received"), the MC reaches the ADV PROCESSING state. Otherwise, the MC stays in the WAIT FOR ADV state. In the ADV PROCESSING state, the 'advertisement' is parsed by the MC. If the 'advertisement' is successfully processed, there are two possibilities. In the former case, the MC issues a successful 'ack' message to the MP ("ACK sent") and moves to the CONF state. This typically happens when the MC needs some more time to produce the 'configure' message associated with the received 'advertisement'. In the latter case, the MC is able to immediately prepare and send back to the MP a 'configure' message. Such a message will have the field set to "200" ("configure+ack sent") and will allow the MC to move directly to the WAIT FOR CONF RESPONSE state. If the ADV processing is unsuccessful (bad syntax, missing XML elements, etc.), the MC sends a NACK message (i.e., an 'ack' with an error response code) to the MP and optionally further describes the problem via a proper reason phrase. In this way ("NACK sent"), the MC switches back to the WAIT FOR ADV state, waiting for a new 'advertisement'. When in the CONF state, the MC prepares the 'configure' request to be issued to the MP on the basis of the previously ack-ed 'advertisement'. When the 'configure' has been sent ("configure sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new 'advertisement' arrives in the meanwhile ("advertisement received"), the MC goes back to the ADV PROCESSING state. In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's response to the issued 'configure' or 'configure+ack'. If a 200 'configureResponse' message is received ("successful configureResponse received"), it means that the MP and the MC have successfully agreed on the media streams to be shared. Then, the MC can move to the ESTABLISHED state. On the other hand, if an error response is received ("error configureResponse received"), the MC moves back to the CONF state to prepare a new 'configure' request. If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE state, the MC switches to the ADV PROCESSING state. When the MC is in the ESTABLISHED state, the telepresence session configuration has been set up at the CLUE application level according to the MC's preferences. Both the MP and the MC have agreed on (and are aware of) the CLUE-controlled media streams to be exchanged within the call. While in the ESTABLISHED state, it might happen that the MC decides to change something in the call settings. The MC then issues a new 'configure' ("configure sent") and goes to wait for the new 'configureResponse' in the WAIT FOR CONF RESPONSE state. On the other hand, in the ESTABLISHED state, if a new 'advertisement' Presta & P. Romano Expires January 6, 2020 [Page 23] Internet-Draft draft-ietf-clue-protocol-19 July 2019 arrives from the MP ("advertisement received"), it means that something has changed on the MP's side. The MC then moves to the ADV PROCESSING state. Messages not shown for a state do not cause the state to change. +----------+ | WAIT FOR | | ADV | +----+-----+<--------+ | | advertisement| NACK sent| received| | v | +-----------+--------+ | ADV + | PROCESSING|<-----------------------+ +-+-----+---+ | | | | configure+ack | | ack | sent | | sent | | v | | +-----+ | | |CONF | advertisement received | +----------------------->| +-------------------------+ |error | +--+--+ | |configureResponse | | | |received | |configure | | | |sent | | | | | | v v advertisement | +------------------+---------------+ received | +--------->| WAIT FOR +---------------------+ | | CONF RESPONSE+ | | +-------+-------+ | | | | | | | | |successful | | |configureResponse | | |received | |configure v | |sent +-----------+ advertisement received| +------------+ESTABLISHED+-----------------------+ +-----------+ Figure 12: Media Consumer's state machine Presta & P. Romano Expires January 6, 2020 [Page 24] Internet-Draft draft-ietf-clue-protocol-19 July 2019 7. Versioning CLUE protocol messages are XML messages compliant to the CLUE protocol XML schema [I-D.ietf-clue-data-model-schema]. The version of the protocol corresponds to the version of the schema. Both client and server have to test the compliance of the received messages with the XML schema of the CLUE protocol. If the compliance is not verified, the message cannot be processed further. Client and server cannot communicate if they do not share exactly the same XML schema. Such a schema is associated with the CLUE URN "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled devices use that schema there will be no interoperability problems due to schema issues. This document defines XML schema version 1.0. The version usage is similar in philosophy to XMPP ([RFC6120]). A version number has major and minor components, each a non-negative integer. Major version changes denote non-interoperable changes. Minor version changes denote schema changes that are backward compatible by ignoring unknown XML elements, or other backward compatible changes. The minor versions of the XML schema MUST be backward compatible, not only in terms of schema but also semantically and procedurally as well. This means that they should define further features and functionality besides those defined in the previous versions, in an incremental way, without impacting the basic rules defined in the previous version of the schema. In this way, if a MP is able to speak, e.g., version 1.5 of the protocol while the MC only understands version 1.4, the MP should have no problem in reverting the dialogue back to version 1.4 without exploiting 1.5 features and functionality. Version 1.4 is the one to be spoken and has to appear in the "v" attribute of the subsequent CLUE messages. In other words, in this example, the MP MUST use version 1.4. This said, and coherently with the general IETF "protocol robustness principle" stating that "an implementation must be conservative in its sending behavior, and liberal in its receiving behavior" [RFC1122], CLUE Participants MUST ignore unknown elements or attributes that are not envisioned in the negotiated protocol version and related extensions. 8. Extensions Although the standard version of the CLUE protocol XML schema is designed to thoroughly cope with the requirements emerging from the application domain, new needs might arise and extensions can be designed. Extensions specify information and behaviors that are not described in a certain version of the protocol and specified in the related RFC document. Such information and behaviors can be Presta & P. Romano Expires January 6, 2020 [Page 25] Internet-Draft draft-ietf-clue-protocol-19 July 2019 optionally used in a CLUE dialogue and MUST be negotiated in the CLUE initiation phase. They can relate to: 1. new information, to be carried in the existing messages. For example, more fields may be added within an existing message; 2. new messages. This is the case if there is no proper message for a certain task, so a brand new CLUE message needs to be defined. As to the first type of extensions, it is possible to distinguish between protocol-specific and data model information. Indeed, CLUE messages are envelopes carrying both: o (i) XML elements defined within the CLUE protocol XML schema itself (protocol-specific information) o (ii) other XML elements compliant to the CLUE data model schema (data model information) When new protocol-specific information is needed somewhere in the protocol messages, it can be added in place of the elements and elements envisioned by the protocol schema. The policy currently defined in the protocol schema for handling and elements is: o elementFormDefault="qualified" o attributeFormDefault="unqualified" The new information must be qualified by namespaces other than "urn:ietf:params:xml:ns:clue-protocol" (the protocol URN) and "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or attributes from unknown namespaces MUST be ignored. The other matter concerns data model information. Data model information is defined by the XML schema associated with the URN "urn:ietf:params:xml:ns:clue-info". Also for the XML elements defined in such a schema there are extensibility issues. Those issues are overcome by using and placeholders. New information within data model elements can be added in place of and schema elements, as long as they are properly namespace qualified. On the other hand (second type of extensions), "extra" CLUE protocol messages, i.e., messages not envisioned in the latest standard version of the schema, can be needed. In that case, the messages and the associated behavior should be defined in external documents that both communication parties must be aware of. Presta & P. Romano Expires January 6, 2020 [Page 26] Internet-Draft draft-ietf-clue-protocol-19 July 2019 As reported in Figure 13, the fields of the element (either new information or new messages) take the following values: o a name; o an external XML Schema defining the XML information and/or the XML messages representing the extension; o the major standard version of the protocol that the extension refers to. Figure 13: The element The above described element is carried within the 'options' and 'optionsResponse' messages to represent the extensions supported both by the CI and the CR. Extensions MUST be defined in a separate XML schema file and MUST be provided with a companion document describing their semantics and use. 8.1. Extension example An example of extension might be a "new" capture attribute (i.e., a capture attribute that is not envisioned in the current standard defining the CLUE data model in [I-D.ietf-clue-data-model-schema]) needed to further describe a video capture. The CLUE data model document ([I-D.ietf-clue-data-model-schema]) envisions the possibility of adding this kind of "extra" information in the description of a video capture. For the sake of convenience, the XML definition of a video capture taken from [I-D.ietf-clue-data-model-schema] is reported in Figure 14 below. Presta & P. Romano Expires January 6, 2020 [Page 27] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Figure 14: XML definition of a CLUE video capture According to such a definition, a video capture might have, after the set of the generic media capture attributes, a set of new attributes defined elsewhere, i.e., in an XML schema defining an extension. The XML schema defining the extension might look like the following (Figure 15): Presta & P. Romano Expires January 6, 2020 [Page 28] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Figure 15: XML schema defining an extension By using the extension above, a video capture can be further described in the advertisement using the element containing two extra information ( and ) besides using the attributes envisioned for a generic media capture. As stated in this document, both participants must be aware of the extension schema and related semantics to use such an extension and must negotiate it via the 'options' and 'optionsResponse' mechanism. 9. XML Schema NOTE TO THE RFC-Editor: Please replace "data-model-schema-19.xsd" with the right schema location for the CLUE data model schema document (which is still to be defined at the time of this writing) in this section prior to publication as an RFC. Presta & P. Romano Expires January 6, 2020 [Page 29] Internet-Draft draft-ietf-clue-protocol-19 July 2019 In this section, the XML schema defining the CLUE messages is provided (Figure 16). Presta & P. Romano Expires January 6, 2020 [Page 30] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Presta & P. Romano Expires January 6, 2020 [Page 31] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Presta & P. Romano Expires January 6, 2020 [Page 32] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Presta & P. Romano Expires January 6, 2020 [Page 33] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Figure 16: Schema defining CLUE messages 10. Call flow example In this section the CLUE protocol messages exchanged in the following call flow are detailed. Only one direction of media is shown for simplicity, as the other direction is precisely symmetric. Presta & P. Romano Expires January 6, 2020 [Page 34] Internet-Draft draft-ietf-clue-protocol-19 July 2019 +-----+ +-----+ | | | | | CP1 | | CP2 | | | | | +--+--+ +--+--+ | | | 1.options | +----------------->| | | | | |2.optionsResponse | |<-----------------+ | | | | | 3.advertisement | +----------------->| | | | | |4.configure+ack | |<-----------------+ | | | | |5.confResponse | +----------------->| | | | | |6.advertisement | +----------------->| | | | | | 7.ack | |<-----------------+ | | | | | 8.configure | |<-----------------+ | | | | | 9.confResponse | +----------------->| | | | | . . . . . . Presta & P. Romano Expires January 6, 2020 [Page 35] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Two CLUE Participants, CP1 and CP2, have successfully set up the CLUE channel according to document [I-D.ietf-clue-datachannel]. CP1 is the Channel Initiator (CI) and CP2 is the Channel Receiver (CR). The initiation phase starts (negotiation of the CLUE protocol version and extensions). CP1, as the CI, sends to CP2 an 'options' message specifying the supported versions and extensions (Section 10.1). CP1 supports: (i) version 1.4 with extensions E1, E2 and E3, (ii) version 2.7 with extensions E4 and E5. Because of such capabilities, CP1 sends an 'options' message with the 'v' attribute set to 1.4 and specifies explicitly all the supported versions and extensions in the corresponding fields of the 'options' message. In the 'options' message, CP1 specifies also that it intends to act both as a MP and as a MC. CP2 supports version 3.0, version 2.9 and version 1.9 of the CLUE protocol, each version without any extension. Version 2.7 is the best common choice. Given the received 'options' message, CP2 answers with an 'optionsResponse' message in which it specifies only version 2.7 as the agreed version of the CLUE protocol to be used, leaving blank the extensions part of the message to say that no extension will be used in the CLUE session (Section 10.2). In the 'optionsResponse' message, CP2 specifies also that it intends to act both as a MP and as a MC. After the initiation phase is completed, CP1 and CP2 start their activity as MP and as MC. For the sake of simplicity, the following call flow focuses only on the dialogue between MP CP1 and MC CP2. CP1 advertises a telepresence configuration like the one described in [I-D.ietf-clue-data-model-schema], Sec. Sample XML File, where there are (i) three main video streams captured by three cameras, the central one capable of capturing a zoomed-out view of the overall telepresence room, (ii) a multi-content capture of the loudest segment of the room, and (iii) one audio capture for the audio of the whole room (Section 10.3). CP2 receives CP1's 'advertisement' message and, after processing it, sends back to CP1 a 'configure + ack' message where it declares to be interested only in the multi-content capture and in the audio capture (Section 10.4). CP1 answers to CP2's 'configure + ack' message with a 'configureResponse' message including a response code '200 - Success' to accept all CP2's requests (Section 10.5). To reflect the changes in its telepresence offer, CP1 issues a new 'advertisement' message to CP2 (Section 10.6), this time adding also Presta & P. Romano Expires January 6, 2020 [Page 36] Internet-Draft draft-ietf-clue-protocol-19 July 2019 a composed capture made by a big picture representing the current speaker and two picture-in-picture boxes representing the previous speakers (see more details about the telepresence description in [I-D.ietf-clue-data-model-schema], Sec. MCC example). CP2 acknowledges the second 'advertisement' message with an 'ack' message (Section 10.7). In a second moment, CP2 changes the requested media streams from CP1 by sending to CP1 a 'configure' message replacing the previously selected video streams with the new composed media streams advertised by CP1 (Section 10.8). Media from the previous configuration continue to flow during the reconfiguration process. Finally, CP1 accept the last requests of CP2 with a 'confResponse' message (Section 10.9) We also remark that in the depicted flow three distinct sequence number spaces per sender are involved (two of which appear in the snippets since we only show one direction of media). The discontinuity between the sequence number values in Section 10.2 and Section 10.3 is hence correct. 10.1. CLUE message nr. 1: 'options' Presta & P. Romano Expires January 6, 2020 [Page 37] Internet-Draft draft-ietf-clue-protocol-19 July 2019 CP1 51 true true 1.4 2.7 E1 URL_E1 1.4 E2 URL_E2 1.4 E3 URL_E3 1.4 E4 URL_E4 2.7 E5 URL_E5 2.7 Presta & P. Romano Expires January 6, 2020 [Page 38] Internet-Draft draft-ietf-clue-protocol-19 July 2019 10.2. CLUE message nr. 2: 'optionsResponse' CP2 62 200 Success true true 2.7 10.3. CLUE message nr. 3: 'advertisement' CP1 11 CS1 0.0 0.0 10.0 Presta & P. Romano Expires January 6, 2020 [Page 39] Internet-Draft draft-ietf-clue-protocol-19 July 2019 0.0 1.0 10.0 true EG1 main audio from the room 1 it static room alice bob ciccio CS1 -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 Presta & P. Romano Expires January 6, 2020 [Page 40] Internet-Draft draft-ietf-clue-protocol-19 July 2019 -1.0 20.0 11.0 true EG0 left camera video capture 1 it static individual ciccio CS1 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 Presta & P. Romano Expires January 6, 2020 [Page 41] Internet-Draft draft-ietf-clue-protocol-19 July 2019 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 Presta & P. Romano Expires January 6, 2020 [Page 42] Internet-Draft draft-ietf-clue-protocol-19 July 2019 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 Presta & P. Romano Expires January 6, 2020 [Page 43] Internet-Draft draft-ietf-clue-protocol-19 July 2019 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed out view of all people in the room 2 Presta & P. Romano Expires January 6, 2020 [Page 44] Internet-Draft draft-ietf-clue-protocol-19 July 2019 it static room alice bob ciccio 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 VC0 VC1 VC2 VC3 VC4 Presta & P. Romano Expires January 6, 2020 [Page 45] Internet-Draft draft-ietf-clue-protocol-19 July 2019 AC0 VC3 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Ciccio chairman timekeeper Presta & P. Romano Expires January 6, 2020 [Page 46] Internet-Draft draft-ietf-clue-protocol-19 July 2019 10.4. CLUE message nr. 4: 'configure + ack' CP2 22 11 200 AC0 ENC4 VC3 ENC1 SE1 10.5. CLUE message nr. 5: 'confResponse' Presta & P. Romano Expires January 6, 2020 [Page 47] Internet-Draft draft-ietf-clue-protocol-19 July 2019 CP1 12 200 Success 22 10.6. CLUE message nr. 6: 'advertisement' CP1 13 CS1 0.0 0.0 10.0 0.0 1.0 10.0 Presta & P. Romano Expires January 6, 2020 [Page 48] Internet-Draft draft-ietf-clue-protocol-19 July 2019 true EG1 main audio from the room 1 it static room alice bob ciccio CS1 0.5 1.0 0.5 0.5 0.0 0.5 true EG0 left camera video capture 1 it static individual ciccio CS1 Presta & P. Romano Expires January 6, 2020 [Page 49] Internet-Draft draft-ietf-clue-protocol-19 July 2019 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 true EG0 central camera video capture 1 it static individual alice CS1 Presta & P. Romano Expires January 6, 2020 [Page 50] Internet-Draft draft-ietf-clue-protocol-19 July 2019 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 true EG0 right camera video capture 1 it static individual bob CS1 Presta & P. Romano Expires January 6, 2020 [Page 51] Internet-Draft draft-ietf-clue-protocol-19 July 2019 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:0 EG0 loudest room segment 2 it static individual CS1 0.0 0.0 10.0 -3.0 Presta & P. Romano Expires January 6, 2020 [Page 52] Internet-Draft draft-ietf-clue-protocol-19 July 2019 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 true EG0 zoomed out view of all people in the room 2 it static room alice bob ciccio CS1 -3.0 20.0 9.0 3.0 Presta & P. Romano Expires January 6, 2020 [Page 53] Internet-Draft draft-ietf-clue-protocol-19 July 2019 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 SE1 SoundLevel:1 penultimate loudest room segment it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 Presta & P. Romano Expires January 6, 2020 [Page 54] Internet-Draft draft-ietf-clue-protocol-19 July 2019 20.0 11.0 SE1 SoundLevel:2 last but two loudest room segment it static individual CS1 -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC3 VC5 VC6 Presta & P. Romano Expires January 6, 2020 [Page 55] Internet-Draft draft-ietf-clue-protocol-19 July 2019 3 EG0 big picture of the current speaker + pips about previous speakers 3 it static individual 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 participants' individual videos VC0 VC1 VC2 loudest segment of the room VC3 loudest segment of the Presta & P. Romano Expires January 6, 2020 [Page 56] Internet-Draft draft-ietf-clue-protocol-19 July 2019 room + pips VC7 room audio AC0 room video VC4 VC3 VC7 SE1 VC0 VC2 VC4 Bob minute taker Alice presenter Presta & P. Romano Expires January 6, 2020 [Page 57] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Ciccio chairman timekeeper 10.7. CLUE message nr. 7: 'ack' CP2 23 200 Success 13 10.8. CLUE message nr. 8: 'configure' Presta & P. Romano Expires January 6, 2020 [Page 58] Internet-Draft draft-ietf-clue-protocol-19 July 2019 CP2 24 13 AC0 ENC4 VC7 ENC1 SE5 10.9. CLUE message nr. 9: 'confResponse' CP1 14 200 Success 24 Presta & P. Romano Expires January 6, 2020 [Page 59] Internet-Draft draft-ietf-clue-protocol-19 July 2019 11. Security Considerations As a general consideration, we remark that the CLUE framework (and related protocol) has been conceived at the outset by embracing the security-by-design paradigm. This entails that a number of requirements have been identified and properly standardized as mandatory within the entire set of documents associated with the CLUE architecture. Requirements include: (i) the use of cryptography and authentication; (ii) protection of all sensitive fields; (iii) mutual authentication between CLUE endpoints; (iv) the presence of authorization mechanisms; (v) the presence of native defence mechanisms against malicious activities such as eavesdropping, selective modification, deletion, replay (and related combinations thereof). Hence, security of the single components of the CLUE solution cannot be evaluated independently of the integrated view of the final architecture. The CLUE protocol is an application-level protocol allowing a Media Producer and a Media Consumer to negotiate a variegated set of parameters associated with the establishment of a telepresence session. This unavoidably exposes a CLUE-enabled telepresence system to a number of potential threats, most of which are extensively discussed in the framework document [I-D.ietf-clue-framework]. The security considerations section of the mentioned document actually discusses issues associated with the setup and management of a telepresence session both in the basic case involving two CLUE endpoints acting, respectively, as MP and MC, and in the more advanced scenario envisaging the presence of an MCU. The framework document also mentions that the information carried within CLUE protocol messages might contain sensitive data, which SHOULD hence be accessed only by authenticated endpoints. Security issues associated with the CLUE data model schema are discussed in [I-D.ietf-clue-data-model-schema]. There is extra information carried by the CLUE protocol that is not associated with the CLUE data model schema and which exposes information that might be of concern. This information is primarily exchanged during the negotiation phase via the 'options' and 'optionsResponse' messages. In the CLUE Participant state machine OPTIONS state, both parties agree on the version and on the extensions to be used in the subsequent CLUE messages exchange phase. A malicious participant might either try to retrieve a detailed footprint of a specific CLUE protocol implementation during this initial setup phase, or force the communicating party to use a non- up-to-date version of the protocol which they know how to break. Indeed, exposing all of the supported versions and extensions could conceivably leak information about the specific implementation of the Presta & P. Romano Expires January 6, 2020 [Page 60] Internet-Draft draft-ietf-clue-protocol-19 July 2019 protocol. In theory an implementation could choose not to announce all of the versions it supports if it wants to avoid such leakage, though at the expenses of interoperability. With respect to the above considerations, it is noted that the OPTIONS state is only reached after the CLUE data channel has been successfully set up. This ensures that only authenticated parties can exchange 'options' and related 'optionsResponse' messages and hence drastically reduces the attack surface that is exposed to malicious parties. The CLUE framework clearly states the requirement to protect CLUE protocol messages against threats deriving from the presence of a malicious agent capable to gain access to the CLUE data channel. Such a requirement is met by the CLUE data channel solution described in [I-D.ietf-clue-datachannel], which ensures protection from both message recovery and message tampering. With respect to this last point, any implementation of the CLUE protocol compliant with the CLUE specification MUST rely on the exchange of messages that flow on top of a reliable and ordered SCTP over DTLS transport channel connecting two CLUE Participants. 12. IANA Considerations This document registers a new XML namespace, a new XML schema and the MIME type for the schema. This document also registers the "CLUE" Application Service tag and the "CLUE" Application Protocol tag and defines registries for the CLUE messages and response codes. 12.1. URN Sub-Namespace Registration This section registers a new XML namespace, ""urn:ietf:params:xml:ns:clue-protocol"". URI: urn:ietf:params:xml:ns:clue-protocol Registrant Contact: IESG (iesg@ietf.org). XML: Presta & P. Romano Expires January 6, 2020 [Page 61] Internet-Draft draft-ietf-clue-protocol-19 July 2019 BEGIN CLUE Messages

Namespace for CLUE Messages

urn:ietf:params:xml:ns:clue-protocol

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 12.2. XML Schema registration This section registers an XML schema per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:clue-protocol Registrant Contact: IESG (iesg@ietf.org). Schema: The XML for this schema can be found as the entirety of Section 9 of this document. 12.3. MIME Media Type Registration for 'application/clue+xml' This section registers the ""application/clue+xml"" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/clue+xml MIME media type name: application MIME subtype name: clue+xml Required parameters: (none) Optional parameters: charset Same as the charset parameter of "application/xml" as specified in [RFC7303], Section 3.2. Presta & P. Romano Expires January 6, 2020 [Page 62] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC7303], Section 3.2. Security considerations: This content type is designed to carry protocol data related to telepresence session control. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section Security are required to protect the data. This media type does not contain executable content. Interoperability considerations: None. Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications that use this media type: CLUE participants. Additional Information: Magic Number(s): (none), File extension(s): .xml, Macintosh File Type Code(s): TEXT. Person & email address to contact for further information: Simon Pietro Romano (spromano@unina.it). Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC7303], and many of the considerations described there also apply to application/clue+xml. 12.4. CLUE Protocol Registry The document requests that the IANA creates new registries for CLUE messages and response codes. 12.4.1. CLUE Message Types The following summarizes the registry for CLUE messages: Related Registry: CLUE Message Types Registry Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Presta & P. Romano Expires January 6, 2020 [Page 63] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Registration/Assignment Procedures: Following the policies outlined in [RFC8126], the IANA policy for assigning new values for the CLUE message types for the CLUE protocol is Specification Required. Registrant Contact: IESG (iesg@ietf.org). The initial Message table is populated using the CLUE messages described in Section 5 and defined in the XML schema in Section 9. +-------------------+-----------------------------------+-----------+ | Message | Description | Reference | +-------------------+-----------------------------------+-----------+ | options | Sent by the CI to the CR in the | RFCXXXX | | | initiation phase to specify the | | | | roles played by the CI, the | | | | supported versions and the | | | | supported extensions. | | | optionsResponse | Sent by the CI to the CR in reply | RFCXXXX | | | to an 'options' message to | | | | finally estabilsh the version and | | | | the extensions to be used in the | | | | following CLUE messages exchange. | | | advertisement | Sent by the MP to the MC to | RFCXXXX | | | specify the telepresence | | | | capabilities of the MP expressed | | | | according to the CLUE framework. | | | ack | Sent by the MC to the MP to | RFCXXXX | | | acknowledge the reception of an | | | | 'advertisement' message. | | | configure | Sent by the MC to the MP to | RFCXXXX | | | specify the desired media | | | | captures among those specified in | | | | the 'advertisement'. | | | configureResponse | Sent by the MP to the MC in reply | RFCXXXX | | | to a CONFIGURE message to | | | | communicate if the configuration | | | | request has been successfully | | | | processed or not. | | +-------------------+-----------------------------------+-----------+ IANA-CLUE 12.4.2. CLUE Response Codes The following summarizes the requested registry for CLUE response codes: Related Registry: CLUE Response Code Registry Presta & P. Romano Expires January 6, 2020 [Page 64] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Registration/Assignment Procedures: Following the policies outlined in [RFC8126], the IANA policy for assigning new values for the Response codes for CLUE shall be Specification Required. Registrant Contact: IESG (iesg@ietf.org). The initial Response-code table is populated using the Response codes defined in Section 5.7 as follows: +--------+---------------+------------------------------+-----------+ | Number | Default | Description | Reference | | | Response | | | | | String | | | +--------+---------------+------------------------------+-----------+ | 200 | Success | The request has been | RFCXXXX | | | | successfully processed. | | | 300 | Low-level | A generic low-level request | RFCXXXX | | | request | error has occurred. | | | | error. | | | | 301 | Bad syntax | The XML syntax of the | RFCXXXX | | | | message is not correct. | | | 302 | Invalid value | The message contains an | RFCXXXX | | | | invalid parameter value. | | | 303 | Conficting | The message contains values | RFCXXXX | | | values | that cannot be used | | | | | together. | | | 400 | Semantic | Semantic errors in the | RFCXXXX | | | errors | received CLUE protocol | | | | | message. | | | 401 | Version not | The protocol version used in | RFCXXXX | | | supported | the message is not | | | | | supported. | | | 402 | Invalid | Sequence number gap; | RFCXXXX | | | sequencing | repeated sequence number; | | | | | sequence number outdated. | | | 403 | Invalid | The clueId used in the | RFCXXXX | | | identifier | message is not valid or | | | | | unknown. | | | 404 | advertisement | The sequence number of the | RFCXXXX | | | Expired | advertisement the configure | | | | | refers to is out of date. | | | 405 | Subset choice | The subset choice is not | RFCXXXX | | | not allowed | allowed for the specified | | | | | Multiple Content Capture. | | +--------+---------------+------------------------------+-----------+ Presta & P. Romano Expires January 6, 2020 [Page 65] Internet-Draft draft-ietf-clue-protocol-19 July 2019 13. Acknowledgments The authors thank all the CLUErs for their precious feedbacks and support, in particular Paul Kyzivat, Christian Groves and Scarlett Liuyan. 14. References 14.1. Normative References [I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, "An XML Schema for the CLUE data model", draft-ietf-clue-data-model-schema-17 (work in progress), August 2016. [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf- clue-datachannel-18 (work in progress), April 2019. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue- framework-25 (work in progress), January 2016. [I-D.ietf-clue-signaling] Hansen, R., Kyzivat, P., Xiao, L., and C. Groves, "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)", draft-ietf-clue-signaling-14 (work in progress), October 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, . Presta & P. Romano Expires January 6, 2020 [Page 66] Internet-Draft draft-ietf-clue-protocol-19 July 2019 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for Telepresence Multistreams", RFC 7262, DOI 10.17487/RFC7262, June 2014, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Authors' Addresses Presta & P. Romano Expires January 6, 2020 [Page 67] Internet-Draft draft-ietf-clue-protocol-19 July 2019 Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: roberta.presta@unina.it Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it Presta & P. Romano Expires January 6, 2020 [Page 68] ./draft-ietf-avtcore-multi-media-rtp-session-13.txt0000644000764400076440000011400712635025637021524 0ustar iustyiusty AVTCORE WG M. Westerlund Internet-Draft Ericsson Updates: 3550, 3551 (if approved) C. Perkins Intended status: Standards Track University of Glasgow Expires: June 20, 2016 J. Lennox Vidyo December 18, 2015 Sending Multiple Types of Media in a Single RTP Session draft-ietf-avtcore-multi-media-rtp-session-13 Abstract This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 20, 2016. Copyright Notice Copyright (c) 2015 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 Westerlund, et al. Expires June 20, 2016 [Page 1] Internet-Draft Multiple Media Types in an RTP Session December 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background and Motivation . . . . . . . . . . . . . . . . . . 3 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Using Multiple Media Types in a Single RTP Session . . . . . 6 5.1. Allowing Multiple Media Types in an RTP Session . . . . . 6 5.2. Demultiplexing media types within an RTP session . . . . 7 5.3. Per-SSRC Media Type Restrictions . . . . . . . . . . . . 8 5.4. RTCP Considerations . . . . . . . . . . . . . . . . . . . 8 6. Extension Considerations . . . . . . . . . . . . . . . . . . 9 6.1. RTP Retransmission Payload Format . . . . . . . . . . . . 9 6.2. RTP Payload Format for Generic FEC . . . . . . . . . . . 10 6.3. RTP Payload Format for Redundant Audio . . . . . . . . . 11 7. Signalling . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction The Real-time Transport Protocol [RFC3550] was designed to use separate RTP sessions to transport different types of media. This implies that different transport layer flows are used for different RTP streams. For example, a video conferencing application might send audio and video traffic RTP flows on separate UDP ports. With increased use of network address/port translation, firewalls, and other middleboxes it is, however, becoming difficult to establish multiple transport layer flows between endpoints. Hence, there is pressure to reduce the number of concurrent transport flows used by RTP applications. This memo updates [RFC3550] and [RFC3551] to allow multiple media types to be sent in a single RTP session in certain cases, thereby reducing the number of transport layer flows that are needed. It makes no changes to RTP behaviour when using multiple RTP streams containing media of the same type (e.g., multiple audio streams or multiple video streams) in a single RTP session. However Westerlund, et al. Expires June 20, 2016 [Page 2] Internet-Draft Multiple Media Types in an RTP Session December 2015 [I-D.ietf-avtcore-rtp-multi-stream] provides important clarifications to RTP behaviour in that case. This memo is structured as follows. Section 2 defines terminology. Section 3 further describes the background to, and motivation for, this memo and Section 4 describes the scenarios where this memo is applicable. Section 5 discusses issues arising from the base RTP and RTCP specification when using multiple types of media in a single RTP session, while Section 6 considers the impact of RTP extensions. We discuss signalling in Section 7. Finally, security considerations are discussed in Section 8. 2. Terminology The terms Encoded Stream, Endpoint, Media Source, RTP Session, and RTP Stream are used as defined in [RFC7656]. We also define the following terms: Media Type: The general type of media data used by a real-time application. The media type corresponds to the value used in the field of an SDP m= line. The media types defined at the time of this writing are "audio", "video", "text", "image", "application", and "message". [RFC4566] [RFC6466] Quality of Service (QoS): Network mechanisms that are intended to ensure that the packets within a flow or with a specific marking are transported with certain properties. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Background and Motivation RTP was designed to support multimedia sessions, containing multiple types of media sent simultaneously, by using multiple transport layer flows. The existence of network address translators, firewalls, and other middleboxes complicates this, however, since a mechanism is needed to ensure that all the transport layer flows needed by the application can be established. This has three consequences: 1. increased delay to establish a complete session, since each of the transport layer flows needs to be negotiated and established; 2. increased state and resource consumption in the middleboxes that can lead to unexpected behaviour when middlebox resource limits are reached; and Westerlund, et al. Expires June 20, 2016 [Page 3] Internet-Draft Multiple Media Types in an RTP Session December 2015 3. increased risk that a subset of the transport layer flows will fail to be established, thus preventing the application from communicating. Using fewer transport layer flows can hence be seen to reduce the risk of communication failure, and can lead to improved reliability and performance. One of the benefits of using multiple transport layer flows is that it makes it easy to use network layer quality of service (QoS) mechanisms to give differentiated performance for different flows. However, we note that many RTP-using application don't use network QoS features, and don't expect or desire any separation in network treatment of their media packets, independent of whether they are audio, video or text. When an application has no such desire, it doesn't need to provide a transport flow structure that simplifies flow based QoS. Given the above issues, it might seem appropriate for RTP-based applications to send all their RTP streams bundled into one RTP session, running over a single transport layer flow. However, this is prohibited by the RTP specification, because the design of RTP makes certain assumptions that can be incompatible with sending multiple media types in a single RTP session. Specifically, the RTP control protocol (RTCP) timing rules assume that all RTP media flows in a single RTP session have broadly similar RTCP reporting and feedback requirements, which can be problematic when different types of media are multiplexed together. Various RTP extensions also make assumptions about SSRC use and RTCP reporting that are incompatible with sending different media types in a single RTP session. This memo updates [RFC3550] and [RFC3551] to allow RTP sessions to contain more than one media type in certain circumstances, and gives guidance on when it is safe to send multiple media types in a single RTP session. 4. Applicability This specification has limited applicability, and anyone intending to use it needs to ensure that their application and use case meets the following criteria: Equal treatment of media: The use of a single RTP session normally results in similar network treatment for all types of media used within the session. Applications that require significantly different network quality of service (QoS) or RTCP configuration for different RTP streams are better suited by sending those RTP streams in separate RTP session, using separate transport layer Westerlund, et al. Expires June 20, 2016 [Page 4] Internet-Draft Multiple Media Types in an RTP Session December 2015 flows for each, since that gives greater flexibility. Further guidance on how to provide differential treatment for some media is given in [I-D.ietf-avtcore-multiplex-guidelines] and [RFC7657]. Compatible RTCP Behaviour: The RTCP timing rules enforce a single RTCP reporting interval for all participants in an RTP session. Flows with very different media sending rate or RTCP feedback requirements cannot be multiplexed together, since this leads to either excessive or insufficient RTCP for some flows, depending on how the RTCP session bandwidth, and hence reporting interval, is configured. For example, it is likely infeasible to find a single RTCP configuration that simultaneously suits both a low-rate audio flow with no feedback, and a high-quality video flow with sophisticated RTCP-based feedback. Thus, combining these into a single RTP session is difficult and/or inadvisable. Signalled Support: The extensions defined in this memo are not compatible with unmodified [RFC3550]-compatible endpoints. Their use requires signalling and mutual agreement by all participants within an RTP session. This requirement can be a problem for signalling solutions that can't negotiate with all participants. For declarative signalling solutions, mandating that the session is using multiple media types in one RTP session can be a way of attempting to ensure that all participants in the RTP session follow the requirement. However, for signalling solutions that lack methods for enforcing that a receiver supports a specific feature, this can still cause issues. Consistent support for multiparty RTP sessions: If it is desired to send multiple types of media in a multiparty RTP session, then all participants in that session need to support sending multiple type of media in a single RTP session. It is not possible, in the general case, to implement a gateway that can interconnect an endpoint using multiple types of media sent using separate RTP sessions, with one or more endpoints that send multiple types of media in a single RTP session. One reason for this is that the same SSRC value can safely be used for different streams in multiple RTP sessions, but when collapsed to a single RTP session there is an SSRC collision. This would not be an issue, since SSRC collision detection will resolve the conflict, except that some RTP payload formats and extensions use matching SSRCs to identify related flows, and break when a single RTP session is used. A middlebox that remaps SSRC values when combining multiple RTP sessions into one also needs to be aware of all possible RTCP packet types that might be used, so that it can remap the SSRC Westerlund, et al. Expires June 20, 2016 [Page 5] Internet-Draft Multiple Media Types in an RTP Session December 2015 values in those packets. This is impossible to do without restricting the set of RTCP packet types that can be used to those that are known by the middlebox. Such a middlebox might also have difficulty due to differences in configured RTCP bandwidth and other parameters between the RTP sessions. Finally, the use of a middlebox that translates SSRC values can negatively impact the possibility for loop detection, as SSRC/CSRC can't be used to detect the loops; instead some other RTP stream or media source identity name space that is common across all interconnect parts is needed. Ability to operate with limited payload type space: An RTP session has only a single 7-bit payload type space for all its payload type numbers. Some applications might find this space limiting when using different media types and RTP payload formats within a single RTP session. Avoids incompatible Extensions: Some RTP and RTCP extensions rely on the existence of multiple RTP sessions and relate RTP streams between sessions. Others report on particular media types, and cannot be used with other media types. Applications that send multiple types of media into a single RTP session need to avoid such extensions. 5. Using Multiple Media Types in a Single RTP Session This section defines what needs to be done or avoided to make an RTP session with multiple media types function without issues. 5.1. Allowing Multiple Media Types in an RTP Session Section 5.2 of "RTP: A Transport Protocol for Real-Time Applications" [RFC3550] states: For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address. Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. This specification changes both of these sentences. The first sentence is changed to: For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate Westerlund, et al. Expires June 20, 2016 [Page 6] Internet-Draft Multiple Media Types in an RTP Session December 2015 RTP session with its own destination transport address, unless specification [RFCXXXX] is followed and the application meets the applicability constraints. The second sentence is changed to: Separate audio and video media sources SHOULD NOT be carried in a single RTP session, unless the guidelines specified in [RFCXXXX] are followed. Second paragraph of Section 6 in RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] says: The payload types currently defined in this profile are assigned to exactly one of three categories or media types: audio only, video only and those combining audio and video. The media types are marked in Tables 4 and 5 as "A", "V" and "AV", respectively. Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session, but multiple RTP sessions MAY be used in parallel to send multiple media types. An RTP source MAY change payload types within the same media type during a session. See the section "Multiplexing RTP Sessions" of RFC 3550 for additional explanation. This specification's purpose is to override that existing SHALL NOT under certain conditions. Thus this sentence also has to be changed to allow for multiple media type's payload types in the same session. The sentence containing "SHALL NOT" in the above paragraph is changed to: Payload types of different media types SHALL NOT be interleaved or multiplexed within a single RTP session unless [RFCXXXX] is used, and the application conforms to the applicability constraints. Multiple RTP sessions MAY be used in parallel to send multiple media types. RFC-Editor Note: Please replace RFCXXXX with the RFC number of this specification when assigned. 5.2. Demultiplexing media types within an RTP session When receiving packets from a transport layer flow, an endpoint will first separate the RTP and RTCP packets from the non-RTP packets, and pass them to the RTP/RTCP protocol handler. The RTP and RTCP packets are then demultiplexed based on their SSRC into the different RTP streams. For each RTP stream, incoming RTCP packets are processed, and the RTP payload type is used to select the appropriate media Westerlund, et al. Expires June 20, 2016 [Page 7] Internet-Draft Multiple Media Types in an RTP Session December 2015 decoder. This process remains the same irrespective of whether multiple media types are sent in a single RTP session or not. As explained below, it is important to note that the RTP payload type is never used to distinguish RTP streams. The RTP packets are demultiplexed into RTP streams based on their SSRC, then the RTP payload type is used to select the correct media decoding pathway for each RTP stream. 5.3. Per-SSRC Media Type Restrictions An SSRC in an RTP session can change between media formats of the same type, subject to certain restrictions [RFC7160], but MUST NOT change media type during its lifetime. For example, an SSRC can change between different audio formats, but cannot start sending audio then change to sending video. The lifetime of an SSRC ends when an RTCP BYE packet for that SSRC is sent, or when it ceases transmission for long enough that it times out for the other participants in the session. The main motivation is that a given SSRC has its own RTP timestamp and sequence number spaces. The same way that you can't send two encoded streams of audio with the same SSRC, you can't send one encoded audio and one encoded video stream with the same SSRC. Each encoded stream when made into an RTP stream needs to have the sole control over the sequence number and timestamp space. If not, one would not be able to detect packet loss for that particular encoded stream. Nor can one easily determine which clock rate a particular SSRCs timestamp will increase with. For additional arguments why RTP payload type based multiplexing of multiple media sources doesn't work, see [I-D.ietf-avtcore-multiplex-guidelines]. Within an RTP session where multiple media types have been configured for use, an SSRC can only send one type of media during its lifetime (i.e., it can switch between different audio codecs, since those are both the same type of media, but cannot switch between audio and video). Different SSRCs MUST be used for the different media sources, the same way multiple media sources of the same media type already have to do. The payload type will inform a receiver which media type the SSRC is being used for. Thus the payload type MUST be unique across all of the payload configurations independent of media type that is used in the RTP session. 5.4. RTCP Considerations When sending multiple types of media that have different rates in a single RTP session, endpoints MUST follow the guidelines for handling RTCP described in Section 7 of [I-D.ietf-avtcore-rtp-multi-stream]. Westerlund, et al. Expires June 20, 2016 [Page 8] Internet-Draft Multiple Media Types in an RTP Session December 2015 6. Extension Considerations This section outlines known issues and incompatibilities with RTP and RTCP extensions when multiple media types are used in a single RTP sessions. Future extensions to RTP and RTCP need to consider, and document, any potential incompatibility. 6.1. RTP Retransmission Payload Format The RTP Retransmission Payload Format [RFC4588] can operate in either SSRC-multiplexed mode or session-multiplex mode. In SSRC-multiplexed mode, retransmitted RTP packets are sent in the same RTP session as the original packets, but use a different SSRC with the same RTCP SDES CNAME. If each endpoint sends only a single original RTP stream and a single retransmission RTP stream in the session, this is sufficient. If an endpoint sends multiple original and retransmission RTP streams, as would occur when sending multiple media types in a single RTP session, then each original RTP stream and the retransmission RTP stream have to be associated using heuristics. By having retransmission requests outstanding for only one SSRC not yet mapped, a receiver can determine the binding between original and retransmission RTP stream. Another alternative is the use of different RTP payload types, allowing the signalled "apt" (associated payload type) parameter of the RTP retransmission payload format to be used to associate retransmitted and original packets. Session-multiplexed mode sends the retransmission RTP stream in a separate RTP session to the original RTP stream, but using the same SSRC for each, with association being done by matching SSRCs between the two sessions. This is unaffected by the use of multiple media types in a single RTP session, since each media type will be sent using a different SSRC in the original RTP session, and the same SSRCs can be used in the retransmission session, allowing the streams to be associated. This can be signalled using SDP with the BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and FID grouping [RFC5888] extensions. These SDP extensions require each "m=" line to only be included in a single FID group, but the RTP retransmission payload format uses FID groups to indicate the m= lines that form an original and retransmission pair. Accordingly, when using the BUNDLE extension to allow multiple media types to be sent in a single RTP session, each original media source (m= line) that is retransmitted needs a corresponding m= line in the retransmission RTP session. In case there are multiple media lines for retransmission, these media lines will form an independent BUNDLE group from the BUNDLE group with the source streams. Westerlund, et al. Expires June 20, 2016 [Page 9] Internet-Draft Multiple Media Types in an RTP Session December 2015 An example SDP fragment showing the grouping structures is provided in Figure 1. This example is not legal SDP and only the most important attributes have been left in place. Note that this SDP is not an initial BUNDLE offer. As can be seen there are two bundle groups, one for the source RTP session and one for the retransmissions. Then each of the media sources are grouped with its retransmission flow using FID, resulting in three more groupings. a=group:BUNDLE foo bar fiz a=group:BUNDLE zoo kelp glo a=group:FID foo zoo a=group:FID bar kelp a=group:FID fiz glo m=audio 10000 RTP/AVP 0 a=mid:foo a=rtpmap:0 PCMU/8000 m=video 10000 RTP/AVP 31 a=mid:bar a=rtpmap:31 H261/90000 m=video 10000 RTP/AVP 31 a=mid:fiz a=rtpmap:31 H261/90000 m=audio 40000 RTP/AVPF 99 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=0;rtx-time=3000 a=mid:zoo m=video 40000 RTP/AVPF 100 a=rtpmap:100 rtx/90000 a=fmtp:199 apt=31;rtx-time=3000 a=mid:kelp m=video 40000 RTP/AVPF 100 a=rtpmap:100 rtx/90000 a=fmtp:199 apt=31;rtx-time=3000 a=mid:glo Figure 1: SDP example of Session Multiplexed RTP Retransmission 6.2. RTP Payload Format for Generic FEC The RTP Payload Format for Generic Forward Error Correction (FEC) [RFC5109] (and its predecessor [RFC2733]) can either send the FEC stream as a separate RTP stream, or it can send the FEC combined with the original RTP stream as a redundant encoding [RFC2198]. When sending FEC as a separate stream, the RTP Payload Format for generic FEC requires that FEC stream to be sent in a separate RTP session to the original stream, using the same SSRC, with the FEC stream being associated by matching the SSRC between sessions. The Westerlund, et al. Expires June 20, 2016 [Page 10] Internet-Draft Multiple Media Types in an RTP Session December 2015 RTP session used for the original streams can include multiple RTP streams, and those RTP streams can use multiple media types. The repair session only needs one RTP Payload type to indicate FEC data, irrespective of the number of FEC streams sent, since the SSRC is used to associate the FEC streams with the original streams. Hence, it is RECOMMENDED that the FEC stream use the "application/ulpfec" media type for [RFC5109], and the "application/parityfec" media type for [RFC2733]. It is legal, but NOT RECOMMENDED, to send FEC streams using media specific payload format names (e.g., using both the "audio/ulpfec" and "video/ulpfec" payload formats for a single RTP session containing both audio and video flows), since this unnecessarily uses up RTP payload type values, and adds no value for demultiplexing since there might be multiple streams of the same media type). The combination of an original RTP session using multiple media types with an associated generic FEC session can be signalled using SDP with the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation]. In this case, the RTP session carrying the FEC streams will be its own BUNDLE group. The m= line for each original stream and the m= line for the corresponding FEC stream are grouped using the SDP grouping framework using either the FEC-FR [RFC5956] grouping or, for backwards compatibility, the FEC [RFC4756] grouping. This is similar to the situation that arises for RTP retransmission with session multiplexing discussed in Section 6.1. The Source-Specific Media Attributes [RFC5576] specification defines an SDP extension (the "FEC" semantic of the "ssrc-group" attribute) to signal FEC relationships between multiple RTP streams within a single RTP session. This cannot be used with generic FEC, since the FEC repair packets need to have the same SSRC value as the source packets being protected. There was work on an Unequal Layer Protection (ULP) extension to allow it be use FEC RTP streams within the same RTP Session as the source stream [I-D.lennox-payload-ulp-ssrc-mux]. When the FEC is sent as a redundant encoding, the considerations in Section 6.3 apply. 6.3. RTP Payload Format for Redundant Audio The RTP Payload Format for Redundant Audio [RFC2198] can be used to protect audio streams. It can also be used along with the generic FEC payload format to send original and repair data in the same RTP packets. Both are compatible with RTP sessions containing multiple media types. Westerlund, et al. Expires June 20, 2016 [Page 11] Internet-Draft Multiple Media Types in an RTP Session December 2015 This payload format requires each different redundant encoding use a different RTP payload type number. When used with generic FEC in sessions that contain multiple media types, this requires each media type to use a different payload type for the FEC stream. For example, if audio and text are sent in a single RTP session with generic ULP FEC sent as a redundant encoding for each, then payload types need to be assigned for FEC using the audio/ulpfec and text/ ulpfec payload formats. If multiple original payload types are used in the session, different redundant payload types need to be allocated for each one. This has potential to rapidly exhaust the available RTP payload type numbers. 7. Signalling Establishing a single RTP session using multiple media types requires signalling. This signalling has to: 1. ensure that any participant in the RTP session is aware that this is an RTP session with multiple media types; 2. ensure that the payload types in use in the RTP session are using unique values, with no overlap between the media types; 3. ensure RTP session level parameters, for example the RTCP RR and RS bandwidth modifiers, the RTP/AVPF trr-int parameter, transport protocol, RTCP extensions in use, and any security parameters, are consistent across the session; and 4. ensure that RTP and RTCP functions that can be bound to a particular media type are reused where possible, rather than configuring multiple code-points for the same thing. When using SDP signalling, the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to signal RTP sessions containing multiple media types. 8. Security Considerations RTP provides a range of strong security mechanisms that can be used to secure sessions [RFC7201], [RFC7202]. The majority of these are independent of the type of media sent in the RTP session; however it is important to check that the security mechanism chosen is compatible with all types of media sent within the session. Sending multiple media types in a single RTP session will generally require that all use the same security mechanism, whereas media sent using different RTP sessions can be secured in different ways. When different media types have different security requirements, it might Westerlund, et al. Expires June 20, 2016 [Page 12] Internet-Draft Multiple Media Types in an RTP Session December 2015 be necessary to send them using separate RTP sessions to meet those different requirements. This can have significant costs in terms of resource usage, session set-up time, etc. 9. IANA Considerations This memo makes no request of IANA. 10. Acknowledgements The authors would like to thank Christer Holmberg, Gunnar Hellstroem, Charles Eckel, Tolga Asveren, Warren Kumari, and Meral Shirazipour for their feedback on the document. 11. References 11.1. Normative References [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-23 (work in progress), July 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . Westerlund, et al. Expires June 20, 2016 [Page 13] Internet-Draft Multiple Media Types in an RTP Session December 2015 11.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft-ietf-avtcore- multiplex-guidelines-03 (work in progress), October 2014. [I-D.lennox-payload-ulp-ssrc-mux] Lennox, J., "Supporting Source-Multiplexing of the Real- Time Transport Protocol (RTP) Payload for Generic Forward Error Correction", draft-lennox-payload-ulp-ssrc-mux-00 (work in progress), February 2013. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, DOI 10.17487/RFC2733, December 1999, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, DOI 10.17487/RFC4756, November 2006, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . Westerlund, et al. Expires June 20, 2016 [Page 14] Internet-Draft Multiple Media Types in an RTP Session December 2015 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 2011, . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . Authors' Addresses Westerlund, et al. Expires June 20, 2016 [Page 15] Internet-Draft Multiple Media Types in an RTP Session December 2015 Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Westerlund, et al. Expires June 20, 2016 [Page 16] ./draft-ietf-clue-rtp-mapping-14.txt0000644000764400076440000007777313055040163016563 0ustar iustyiusty CLUE WG R. Even Internet-Draft Huawei Technologies Intended status: Standards Track J. Lennox Expires: August 31, 2017 Vidyo February 27, 2017 Mapping RTP streams to CLUE Media Captures draft-ietf-clue-rtp-mapping-14.txt Abstract This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 31, 2017. Copyright Notice Copyright (c) 2017 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 Even & Lennox Expires August 31, 2017 [Page 1] Internet-Draft RTP mapping to CLUE February 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTP topologies for CLUE . . . . . . . . . . . . . . . . . . . 3 4. Mapping CLUE Capture Encodings to RTP streams . . . . . . . . 4 5. MCC Constituent CaptureID definition . . . . . . . . . . . . 5 5.1. RTCP CaptureID SDES Item . . . . . . . . . . . . . . . . 5 5.2. RTP Header Extension . . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Communication Security . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Telepresence systems can send and receive multiple media streams. The CLUE framework [I-D.ietf-clue-framework] defines Media Captures (MC) as a source of Media, from one or more Capture Devices. A Media Capture may also be constructed from other Media streams. A middle box can express conceptual Media Captures that it constructs from Media streams it receives. A Multiple Content Capture (MCC) is a special Media Capture composed of multiple Media Captures. SIP Offer/Answer [RFC3264] uses SDP [RFC4566] to describe the RTP[RFC3550] media streams. Each RTP stream has a unique Synchronization Source (SSRC) within its RTP session. The content of the RTP stream is created by an encoder in the endpoint. This may be an original content from a camera or a content created by an intermediary device like an MCU (Multipoint Control Unit). This document makes recommendations for the CLUE architecture about how RTP and RTCP streams should be encoded and transmitted, and how their relation to CLUE Media Captures should be communicated. The proposed solution supports multiple RTP topologies [RFC7667]. With regards to the media (audio, video and timed text), systems that support CLUE use RTP for the media, SDP for codec and media transport negotiation (CLUE individual encodings) and the CLUE protocol for Media Capture description and selection. In order to associate the Even & Lennox Expires August 31, 2017 [Page 2] Internet-Draft RTP mapping to CLUE February 2017 media in the different protocols there are three mapping that need to be specified: 1. CLUE individual encodings to SDP 2. RTP streams to SDP (this is not a CLUE specific mapping) 3. RTP streams to MC to map the received RTP steam to the current MC in the MCC. 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[RFC2119] and indicate requirement levels for RTP processing in compliant CLUE implementations. The definitions from the CLUE framework document [I-D.ietf-clue-framework] section 3 are used by this document as well. 3. RTP topologies for CLUE The typical RTP topologies used by CLUE Telepresence systems specify different behaviors for RTP and RTCP distribution. A number of RTP topologies are described in [RFC7667]. For CLUE telepresence, the relevant topologies include Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs. In the Point-to-Point topology, one peer communicates directly with a single peer over unicast. There can be one or more RTP sessions, each sent on a separate 5-tuple, and having a separate SSRC space, with each RTP session carrying multiple RTP streams identified by their SSRC. All SSRCs are recognized by the peers based on the information in the RTCP Source description (SDES) report that includes the CNAME and SSRC of the sent RTP streams. There are different Point-to-Point use cases as specified in CLUE use case [RFC7205]. In some cases, a CLUE session which, at a high-level, is point-to-point may nonetheless have an RTP stream which is best described by one of the mixer topologies. For example, a CLUE endpoint can produce composite or switched captures for use by a receiving system with fewer displays than the sender has cameras. The Media Capture may be described using an MCC. For the Media Mixer topology [RFC7667], the peers communicate only with the mixer. The mixer provides mixed or composited media streams, using its own SSRC for the sent streams. If needed by CLUE Even & Lennox Expires August 31, 2017 [Page 3] Internet-Draft RTP mapping to CLUE February 2017 endpoint, the conference roster information including conference participants, endpoints, media and media-id (SSRC) can be determined using the conference event package [RFC4575] element. Media-switching mixers and Selective Forwarding Middleboxes behave as described in [RFC7667] 4. Mapping CLUE Capture Encodings to RTP streams The different topologies described in Section 3 create different SSRC distribution models and RTP stream multiplexing points. Most video conferencing systems today can separate multiple RTP sources by placing them into RTP sessions using the SDP description; the video conferencing application can also have some knowledge about the purpose of each RTP session. For example, video conferencing applications that have a primary video source and a slides video source can send each media source in a separate RTP session with a content attribute [RFC4796] enabling different application behavior for each received RTP media source. Demultiplexing is straightforward because each media capture is sent as a single RTP stream, with each RTP stream being sent in a separate RTP session, on a distinct UDP 5-tuple. This will also be true for mapping the RTP streams to Media Captures Encodings if each Media Capture Encodings uses a separate RTP session, and the consumer can identify it based on the receiving RTP port. In this case, SDP only needs to label the RTP session with an identifier that can be used to identify the Media Capture in the CLUE description. The SDP label attribute serves as this identifier. Each Capture Encoding MUST be sent as a separate RTP stream. CLUE endpoints MUST support sending each such RTP stream in a separate RTP session signalled by an SDP m= line. They MAY also support sending some or all of the RTP streams in a single RTP session, using the mechanism described in [I-D.ietf-mmusic-sdp-bundle-negotiation] to relate RTP streams to SDP m= lines. MCCs bring another mapping issue, in that an MCC represents multiple Media Captures that can be sent as part of this MCC if configured by the consumer. When receiving an RTP stream which is mapped to the MCC, the consumer needs to know which original MC it is in order to get the MC parameters from the advertisement. If a consumer requested a MCC, the original MC does not have a capture encoding, so it cannot be associated with an m-line using a label as described in CLUE signaling [I-D.ietf-clue-signaling]. This is important, for example, to get correct scaling information for the original MC, which may be different for the various MCs that are contributing to the MCC. Even & Lennox Expires August 31, 2017 [Page 4] Internet-Draft RTP mapping to CLUE February 2017 5. MCC Constituent CaptureID definition For a MCC which can represent multiple switched MCs there is a need to know which MC is represented in the current RTP stream at any given time. This requires a mapping from the SSRC of the RTP stream conveying a particular MCC to the constituent MC. In order to address this mapping this document defines an RTP header extension and SDES item that includes the captureID of the original MC, allowing the consumer to use the original source MC's attributes like the spatial information. This mapping temporarily associates the SSRC of the RTP stream conveying a particular MCC with the captureID of the single original MC that is currently switched into the MCC. This mapping cannot be used for the composed case where more than one original MC is composed into the MCC simultaneously. If there is only one MC in the MCC then the media provider MUST send the captureID of the current constituent MC in the RTP Header Extension and as a RTCP CaptureID SDES item. When the media provider switches the MC it sends within an MCC, it MUST send the captureID value for the MC just switched into the MCC in an RTP Header Extension and as a RTCP CaptureID SDES item as specified in [RFC7941] If there is more than one MC composed into the MCC then the media provider MUST NOT send any of the MCs' captureIDs using this mechanism. However, if an MCC is sending contributing source (CSRC) information in the RTP header for a composed capture, it MAY send the captureID values in the RTCP SDES packets giving source information for the SSRC values sent as contributing sources (CSRCs). If the media provider sends the captureID of a single MC switched into an MCC, then later sends one composed stream of multiple MCs in the same MCC, it MUST send the special value "-", a single dash character, as the captureID RTP Header Extension and RTCP CaptureID SDES item. The single dash character indicates there is no applicable value for the MCC constituent CaptureID. The media consumer interprets this as meaning that any previous CaptureID value associated with this SSRC no longer applies. As [I-D.ietf-clue-data-model-schema] defines the captureID syntax as "xs:ID", the single dash character is not a legal captureID value, so there is no possibility of confusing it with an actual captureID. 5.1. RTCP CaptureID SDES Item This document specifies a new RTCP SDES item. Even & Lennox Expires August 31, 2017 [Page 5] Internet-Draft RTP mapping to CLUE February 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CaptId=TBA | length | CaptureID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+ Note to the RFC Editor: Please replace TBA with the value assigned by IANA. This CaptureID is a variable-length UTF-8 string corresponding either to a CaptureID negotiated in the CLUE protocol, or the single character "-". This SDES item MUST be sent in an SDES packet within a compound RTCP packet unless support for Reduced-size RTCP has been negotiated as specified in RFC 5506 [RFC5506], in which case it can be sent as an SDES packet in a non-compound RTCP packet. 5.2. RTP Header Extension The CaptureID is also carried in an RTP header extension [RFC5285], using the mechanism defined in [RFC7941]. Support is negotiated within SDP using the URN "urn:ietf:params:rtp- hdrext:sdes:CaptureID". The CaptureID is sent in a RTP Header Extension because for switched captures, receivers need to know which original MC corresponds to the media being sent for an MCC, in order to correctly apply geometric adjustments to the received media. As discussed in [RFC7941], there is no need to send the CaptId Header Extension with all RTP packets. Senders MAY choose to send it only when a new MC is sent. If such a mode is being used, the header extension SHOULD be sent in the first few RTP packets to reduce the risk of losing it due to packet loss. See [RFC7941] for more discussion of this. 6. Examples In this partial advertisement the Media Provider advertises a composed capture VC7 made of a big picture representing the current speaker (VC3) and two picture-in-picture boxes representing the previous speakers (the previous one -VC5- and the oldest one -VC6). Even & Lennox Expires August 31, 2017 [Page 6] Internet-Draft RTP mapping to CLUE February 2017 CS1 true VC3 VC5 VC6 3 false big picture of the current speaker pips about previous speakers 1 it static individual In this case the media provider will send capture IDs VC3, VC5 or VC6 as an RTP header extension and RTCP SDES message for the RTP stream associated with the MC. Note that this is part of the full advertisement message example from CLUE data model[I-D.ietf-clue-data-model-schema] example and is not a valid xml document. 7. Communication Security CLUE endpoints MUST support RTP/SAVPF profile and SRTP [RFC3711]. CLUE endpoints MUST support DTLS [RFC6347] and DTLS-SRTP [RFC5763] [RFC5764] for SRTP keying. All media channels SHOULD be secure via SRTP and the RTP/SAVPF profile unless the RTP media and its associated RTCP are secure by other means (see [RFC7201] [RFC7202]). All CLUE implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.Encrypted SRTP Header extensions [RFC6904] MUST be supported. Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. Even & Lennox Expires August 31, 2017 [Page 7] Internet-Draft RTP mapping to CLUE February 2017 NULL Protection profiles MUST NOT be used for RTP or RTCP. CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as specified in [RFC7022], and thus can't be used for long term tracking of the users. 8. Acknowledgments The authors would like to thanks Allyn Romanow and Paul Witty for contributing text to this work. Magnus Westerlund helped drafting the security section. 9. IANA Considerations This document defines a new extension URI in the RTP SDES Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:sdes:CaptId Description: CLUE CaptId Contact: ron.even.tlv@gmail.com Reference: RFC XXXX The IANA is requested to register one new RTCP SDES items in the "RTCP SDES Item Types" registry, as follows: Value Abbrev Name Reference TBA CCID CLUE CaptId [RFCXXXX] Note to the RFC Editor: Please replace RFCXXXX with this RFC number. 10. Security Considerations The security considerations of the RTP specification, the RTP/SAVPF profile, and the various RTP/RTCP extensions and RTP payload formats that form the complete protocol suite described in this memo apply. It is not believed there are any new security considerations resulting from the combination of these various protocol extensions. The Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides handling of fundamental issues by offering confidentiality, integrity and partial source authentication. A mandatory to implement and use media security solution is created by combining this secured RTP Even & Lennox Expires August 31, 2017 [Page 8] Internet-Draft RTP mapping to CLUE February 2017 profile and DTLS-SRTP keying [RFC5764] as defined in the communication security section of this memo Section 7 RTCP packets convey a Canonical Name (CNAME) identifier that is used to associate RTP packet streams that need to be synchronised across related RTP sessions. Inappropriate choice of CNAME values can be a privacy concern, since long-term persistent CNAME identifiers can be used to track users across multiple calls. The communication security section of this memo Section 7 mandates generation of short- term persistent RTCP CNAMES, as specified in [RFC7022] so they can't be used for long term tracking of the users. Some potential denial of service attacks exist if the RTCP reporting interval is configured to an inappropriate value. This could be done by configuring the RTCP bandwidth fraction to an excessively large or small value using the SDP "b=RR:" or "b=RS:" lines [RFC3556], or some similar mechanism, or by choosing an excessively large or small value for the RTP/AVPF minimal receiver report interval (if using SDP, this is the "a=rtcp-fb:... trr-int" parameter) [RFC4585] The risks are as follows: 1. the RTCP bandwidth could be configured to make the regular reporting interval so large that effective congestion control cannot be maintained, potentially leading to denial of service due to congestion caused by the media traffic; 2. the RTCP interval could be configured to a very small value, causing endpoints to generate high rate RTCP traffic, potentially leading to denial of service due to the non-congestion controlled RTCP traffic; and 3. RTCP parameters could be configured differently for each endpoint, with some of the endpoints using a large reporting interval and some using a smaller interval, leading to denial of service due to premature participant timeouts due to mismatched timeout periods which are based on the reporting interval (this is a particular concern if endpoints use a small but non-zero value for the RTP/AVPF minimal receiver report interval (trr-int) [RFC4585], as discussed in [I-D.ietf-avtcore-rtp-multi-stream]). Premature participant timeout can be avoided by using the fixed (non- reduced) minimum interval when calculating the participant timeout ([I-D.ietf-avtcore-rtp-multi-stream]). To address the other concerns, endpoints SHOULD ignore parameters that configure the RTCP reporting interval to be significantly longer than the default five second interval specified in [RFC3550] (unless the media data rate is so low that the longer reporting interval roughly corresponds to 5% of the media data rate), or that configure the RTCP reporting Even & Lennox Expires August 31, 2017 [Page 9] Internet-Draft RTP mapping to CLUE February 2017 interval small enough that the RTCP bandwidth would exceed the media bandwidth. The guidelines in [RFC6562] apply when using variable bit rate (VBR) audio codecs such as Opus. The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes performing voice activity based source selection or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. If further evidence are produced to show that information leakage is significant from audio level indications, then use of encryption needs to be mandated at that time. In multi-party communication scenarios using RTP Middleboxes; this middleboxes are REQUIRED, by this protocol, to not weaken the sessions' security. The middlebox SHOULD maintain the confidentiality, integrity and perform source authentication. The middlebox MAY perform checks that prevents any endpoint participating in a conference to impersonate another. Some additional security considerations regarding multi-party topologies can be found in [RFC7667] The CaptureID is created as part of the CLUE protocol. The CaptId SDES item is used to convey the same CaptureID value in the SDES item. When sending the SDES item the security consideration specified in the security section of [RFC7941] and in the communication security section of this memo Section 7 are applicable. Note that since the CaptureID is carried also in CLUE protocol messages it is RECOMMENDED that this SDES item use at least similar protection profiles as the CLUE protocol messages carried in the CLUE data channel. . 11. References 11.1. Normative References [I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, "An XML Schema for the CLUE data model", draft-ietf-clue-data-model-schema-17 (work in progress), August 2016. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue- framework-25 (work in progress), January 2016. Even & Lennox Expires August 31, 2017 [Page 10] Internet-Draft RTP mapping to CLUE February 2017 [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-36 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, . 11.2. Informative References [FIPS186] National Institute of Standards and Technology, "Digital Signature Standard", FIPS PUB 186-4, July 2013. Even & Lennox Expires August 31, 2017 [Page 11] Internet-Draft RTP mapping to CLUE February 2017 [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., and R. Hansen, "CLUE Signaling", draft-ietf-clue-signaling-10 (work in progress), January 2017. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, DOI 10.17487/RFC4796, February 2007, . Even & Lennox Expires August 31, 2017 [Page 12] Internet-Draft RTP mapping to CLUE February 2017 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, . [RFC7205] Romanow, A., Botzko, S., Duckworth, M., and R. Even, Ed., "Use Cases for Telepresence Multistreams", RFC 7205, DOI 10.17487/RFC7205, April 2014, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Authors' Addresses Even & Lennox Expires August 31, 2017 [Page 13] Internet-Draft RTP mapping to CLUE February 2017 Roni Even Huawei Technologies Tel Aviv Israel Email: roni.even@huawei.com Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Even & Lennox Expires August 31, 2017 [Page 14] ./draft-ietf-avtcore-multiplex-guidelines-12.txt0000644000764400076440000032311013672102152021164 0ustar iustyiusty Network Working Group M. Westerlund Internet-Draft B. Burman Intended status: Informational Ericsson Expires: December 18, 2020 C. Perkins University of Glasgow H. Alvestrand Google R. Even June 16, 2020 Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams draft-ietf-avtcore-multiplex-guidelines-12 Abstract The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability, but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 18, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Westerlund, et al. Expires December 18, 2020 [Page 1] Internet-Draft Guidelines for Multiplexing in RTP June 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Subjects Out of Scope . . . . . . . . . . . . . . . . . . 5 3. RTP Multiplexing Overview . . . . . . . . . . . . . . . . . . 5 3.1. Reasons for Multiplexing and Grouping RTP Streams . . . . 5 3.2. RTP Multiplexing Points . . . . . . . . . . . . . . . . . 6 3.2.1. RTP Session . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Synchronisation Source (SSRC) . . . . . . . . . . . . 8 3.2.3. Contributing Source (CSRC) . . . . . . . . . . . . . 10 3.2.4. RTP Payload Type . . . . . . . . . . . . . . . . . . 11 3.3. Issues Related to RTP Topologies . . . . . . . . . . . . 12 3.4. Issues Related to RTP and RTCP Protocol . . . . . . . . . 13 3.4.1. The RTP Specification . . . . . . . . . . . . . . . . 13 3.4.2. Multiple SSRCs in a Session . . . . . . . . . . . . . 15 3.4.3. Binding Related Sources . . . . . . . . . . . . . . . 15 3.4.4. Forward Error Correction . . . . . . . . . . . . . . 17 4. Considerations for RTP Multiplexing . . . . . . . . . . . . . 17 4.1. Interworking Considerations . . . . . . . . . . . . . . . 17 4.1.1. Application Interworking . . . . . . . . . . . . . . 17 4.1.2. RTP Translator Interworking . . . . . . . . . . . . . 18 4.1.3. Gateway Interworking . . . . . . . . . . . . . . . . 19 4.1.4. Multiple SSRC Legacy Considerations . . . . . . . . . 20 4.2. Network Considerations . . . . . . . . . . . . . . . . . 20 4.2.1. Quality of Service . . . . . . . . . . . . . . . . . 20 4.2.2. NAT and Firewall Traversal . . . . . . . . . . . . . 21 4.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Security and Key Management Considerations . . . . . . . 24 4.3.1. Security Context Scope . . . . . . . . . . . . . . . 24 4.3.2. Key Management for Multi-party Sessions . . . . . . . 25 4.3.3. Complexity Implications . . . . . . . . . . . . . . . 26 5. RTP Multiplexing Design Choices . . . . . . . . . . . . . . . 26 5.1. Multiple Media Types in One Session . . . . . . . . . . . 26 5.2. Multiple SSRCs of the Same Media Type . . . . . . . . . . 28 5.3. Multiple Sessions for One Media Type . . . . . . . . . . 29 5.4. Single SSRC per Endpoint . . . . . . . . . . . . . . . . 30 Westerlund, et al. Expires December 18, 2020 [Page 2] Internet-Draft Guidelines for Multiplexing in RTP June 2020 5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 6. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Dismissing Payload Type Multiplexing . . . . . . . . 39 Appendix B. Signalling Considerations . . . . . . . . . . . . . 40 B.1. Session Oriented Properties . . . . . . . . . . . . . . . 41 B.2. SDP Prevents Multiple Media Types . . . . . . . . . . . . 42 B.3. Signalling RTP Stream Usage . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] is a commonly used protocol for real-time media transport. It is a protocol that provides great flexibility and can support a large set of different applications. RTP was from the beginning designed for multiple participants in a communication session. It supports many topology paradigms and usages, as defined in [RFC7667]. RTP has several multiplexing points designed for different purposes. These enable support of multiple RTP streams and switching between different encoding or packetization of the media. By using multiple RTP sessions, sets of RTP streams can be structured for efficient processing or identification. Thus, an RTP application designer needs to understand how to best use the RTP session, the RTP stream identifier (SSRC), and the RTP payload type to meet the application's needs. There have been increased interest in more advanced usage of RTP. For example, multiple RTP streams can be used when a single endpoint has multiple media sources (like multiple cameras or microphones) that need to be sent simultaneously. Consequently, questions are raised regarding the most appropriate RTP usage. The limitations in some implementations, RTP/RTCP extensions, and signalling have also been exposed. This document aims to clarify the usefulness of some functionalities in RTP which will hopefully result in more complete implementations in the future. The purpose of this document is to provide clear information about the possibilities of RTP when it comes to multiplexing. The RTP application designer needs to understand the implications arising from a particular usage of the RTP multiplexing points. The document Westerlund, et al. Expires December 18, 2020 [Page 3] Internet-Draft Guidelines for Multiplexing in RTP June 2020 will provide some guidelines and recommend against some usages as being unsuitable, in general or for particular purposes. The document starts with some definitions and then goes into the existing RTP functionalities around multiplexing. Both the desired behaviour and the implications of a particular behaviour depend on which topologies are used, which requires some consideration. This is followed by a discussion of some choices in multiplexing behaviour and their impacts. Some designs of RTP usage are discussed. Finally, some guidelines and examples are provided. 2. Definitions 2.1. Terminology The definitions in Section 3 of [RFC3550] are referenced normatively. The taxonomy defined in [RFC7656] is referenced normatively. The following terms and abbreviations are used in this document: Multiparty: A communication situation including multiple endpoints. In this document, it will be used to refer to situations where more than two endpoints communicate. Multiplexing: The operation of taking multiple entities as input, aggregating them onto some common resource while keeping the individual entities addressable such that they can later be fully and unambiguously separated (de-multiplexed) again. RTP Receiver: An Endpoint or Middlebox receiving RTP streams and RTCP messages. It uses at least one SSRC to send RTCP messages. An RTP Receiver may also be an RTP Sender. RTP Sender: An Endpoint sending one or more RTP streams, but also sending RTCP messages. RTP Session Group: One or more RTP sessions that are used together to perform some function. Examples are multiple RTP sessions used to carry different layers of a layered encoding. In an RTP Session Group, CNAMEs are assumed to be valid across all RTP sessions, and designate synchronisation contexts that can cross RTP sessions; i.e. SSRCs that map to a common CNAME can be assumed to have RTCP Sender Report (SR) timing information derived from a common clock such that they can be synchronised for playout. Signalling: The process of configuring endpoints to participate in one or more RTP sessions. Westerlund, et al. Expires December 18, 2020 [Page 4] Internet-Draft Guidelines for Multiplexing in RTP June 2020 Note: The above definitions of RTP Receiver and RTP Sender are consistent with the usage in [RFC3550]. 2.2. Subjects Out of Scope This document is focused on issues that affect RTP. Thus, issues that involve signalling protocols, such as whether SIP [RFC3261], Jingle [JINGLE] or some other protocol is in use for session configuration, the particular syntaxes used to define RTP session properties, or the constraints imposed by particular choices in the signalling protocols, are mentioned only as examples in order to describe the RTP issues more precisely. This document assumes the applications will use RTCP. While there are applications that don't send RTCP, they do not conform to the RTP specification, and thus can be regarded as reusing the RTP packet format but not implementing the RTP protocol. 3. RTP Multiplexing Overview 3.1. Reasons for Multiplexing and Grouping RTP Streams There are several reasons why an endpoint might choose to send multiple media streams. In the below discussion, please keep in mind that the reasons for having multiple RTP streams vary and include but are not limited to the following: o Multiple media sources o Multiple RTP streams might be needed to represent one media source for instance: * To carry different layers of an scalable encoding of a media source * Alternative encodings during simulcast, for instance using different codecs for the same audio stream * Alternative formats during simulcast, for instance multiple resolutions of the same video stream o A retransmission stream might repeat some parts of the content of another RTP stream o A Forward Error Correction (FEC) stream might provide material that can be used to repair another RTP stream Westerlund, et al. Expires December 18, 2020 [Page 5] Internet-Draft Guidelines for Multiplexing in RTP June 2020 For each of these reasons, it is necessary to decide if each additional RTP stream is sent within the same RTP session as the other RTP streams, or if it is necessary to use additional RTP sessions to group the RTP streams. The choice suitable for one situation, might not be the choice suitable in another situation or combination of reasons. The clearest understanding is associated with multiplexing multiple media sources of the same media type. However, all reasons warrant discussion and clarification on how to deal with them. As the discussion below will show, in reality we cannot choose a single one of SSRC or RTP session multiplexing solutions for all purposes. To utilise RTP well and as efficiently as possible, both are needed. The real issue is finding the right guidance on when to create additional RTP sessions and when additional RTP streams in the same RTP session is the right choice. 3.2. RTP Multiplexing Points This section describes the multiplexing points present in the RTP protocol that can be used to distinguish RTP streams and groups of RTP streams. Figure 1 outlines the process of demultiplexing incoming RTP streams starting already at the socket representing reception of one or more transport flows, e.g. based on the UDP destination port. It also demultiplexes RTP/RTCP from any other protocols, such as STUN [RFC5389] and DTLS-SRTP [RFC5764] on the same transport as described in [RFC7983]. The Processing and Buffering (PB) step of Figure 1 terminates the RTP/RTCP protocol and prepares the RTP payload for input to the decoder. Westerlund, et al. Expires December 18, 2020 [Page 6] Internet-Draft Guidelines for Multiplexing in RTP June 2020 | | | | | | packets +-- v v v | +------------+ | | Socket(s) | Transport Protocol Demultiplexing | +------------+ | || || RTP | RTP/ || |+-----> DTLS (SRTP Keying, SCTP, etc) Session | RTCP || +------> STUN (multiplexed using same port) +-- || +-- || | ++(split by SSRC)-++---> Identify SSRC collision | || || || || | (associate with signalling by MID/RID) | vv vv vv vv RTP | +--+ +--+ +--+ +--+ Jitter buffer, Streams | |PB| |PB| |PB| |PB| process RTCP, etc. | +--+ +--+ +--+ +--+ +-- | | | | (select decoder based on PT) +-- | / | / | +-----+ | / | / | |/ Payload | v v v Formats | +---+ +---+ +---+ | |Dec| |Dec| |Dec| Decoders | +---+ +---+ +---+ +-- Figure 1: RTP Demultiplexing Process 3.2.1. RTP Session An RTP session is the highest semantic layer in the RTP protocol, and represents an association between a group of communicating endpoints. RTP does not contain a session identifier, yet different RTP sessions must be possible to identify both across a set of different endpoints and from the perspective of a single endpoint. For RTP session separation across endpoints, the set of participants that form an RTP session is defined as those that share a single synchronisation source space [RFC3550]. That is, if a group of participants are each aware of the synchronisation source identifiers belonging to the other participants, then those participants are in a single RTP session. A participant can become aware of a synchronisation source identifier by receiving an RTP packet containing it in the SSRC field or CSRC list, by receiving an RTCP Westerlund, et al. Expires December 18, 2020 [Page 7] Internet-Draft Guidelines for Multiplexing in RTP June 2020 packet mentioning it in an SSRC field, or through signalling (e.g., the Session Description Protocol (SDP) [RFC4566] "a=ssrc:" attribute [RFC5576]). Thus, the scope of an RTP session is determined by the participants' network interconnection topology, in combination with RTP and RTCP forwarding strategies deployed by the endpoints and any middleboxes, and by the signalling. For RTP session separation within a single endpoint RTP relies on the underlying transport layer, and on the signalling to identify RTP sessions in a manner that is meaningful to the application. A single endpoint can have one or more transport flows for the same RTP session, and a single RTP session can span multiple transport layer flows even if all endpoints use a single transport layer flow per endpoint for that RTP session. The signalling layer might give RTP sessions an explicit identifier, or the identification might be implicit based on the addresses and ports used. Accordingly, a single RTP session can have multiple associated identifiers, explicit and implicit, belonging to different contexts. For example, when running RTP on top of UDP/IP, an endpoint can identify and delimit an RTP session from other RTP sessions by their UDP source and destination IP addresses and UDP port numbers. A single RTP session can be using multiple IP/UDP flows for receiving and/or sending RTP packets to other endpoints or middleboxes, even if the endpoint does not have multiple IP addresses. Using multiple IP addresses only makes it more likely to require multiple IP/UDP flows. Another example is SDP media descriptions (the "m=" line and the following associated lines) that signal the transport flow and RTP session configuration for the endpoint's part of the RTP session. The SDP grouping framework [RFC5888] allows labeling of the media descriptions to be used so that RTP Session Groups can be created. Through use of Negotiating Media Multiplexing Using the Session Description Protocol (SDP) [I-D.ietf-mmusic-sdp-bundle-negotiation], multiple media descriptions become part of a common RTP session where each media description represents the RTP streams sent or received for a media source. The RTP protocol makes no normative statements about the relationship between different RTP sessions, however the applications that use more than one RTP session will have some higher layer understanding of the relationship between the sessions they create. 3.2.2. Synchronisation Source (SSRC) A synchronisation source (SSRC) identifies a source of an RTP stream, or an RTP receiver when sending RTCP. Every endpoint has at least one SSRC identifier, even if it does not send RTP packets. RTP endpoints that are only RTP receivers still send RTCP and use their SSRC identifiers in the RTCP packets they send. An endpoint can have Westerlund, et al. Expires December 18, 2020 [Page 8] Internet-Draft Guidelines for Multiplexing in RTP June 2020 multiple SSRC identifiers if it sends multiple RTP streams. Endpoints that are both RTP sender and RTP receiver use the same SSRC(s) in both roles. The SSRC is a 32-bit identifier. It is present in every RTP and RTCP packet header, and in the payload of some RTCP packet types. It can also be present in SDP signalling. Unless pre-signalled, e.g. using the SDP "a=ssrc:" attribute [RFC5576], the SSRC is chosen at random. It is not dependent on the network address of the endpoint, and is intended to be unique within an RTP session. SSRC collisions can occur, and are handled as specified in [RFC3550] and [RFC5576], resulting in the SSRC of the colliding RTP streams or receivers changing. An endpoint that changes its network transport address during a session has to choose a new SSRC identifier to avoid being interpreted as looped source, unless a mechanism providing a virtual transport (such as ICE [RFC8445]) abstracts the changes. SSRC identifiers that belong to the same synchronisation context (i.e., that represent RTP streams that can be synchronised using information in RTCP SR packets) use identical CNAME chunks in corresponding RTCP SDES packets. SDP signalling can also be used to provide explicit SSRC grouping [RFC5576]. In some cases, the same SSRC identifier value is used to relate streams in two different RTP sessions, such as in RTP retransmission [RFC4588]. This is to be avoided since there is no guarantee that SSRC values are unique across RTP sessions. For the RTP retransmission [RFC4588] case it is recommended to use explicit binding of the source RTP stream and the redundancy stream, e.g. using the RepairedRtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. The RepairedRtpStreamId is a rather recent mechanism, so one cannot expect older applications to follow this recommendation. Note that RTP sequence number and RTP timestamp are scoped by the SSRC and thus specific per RTP stream. Different types of entities use an SSRC to identify themselves, as follows: A real media source: Uses the SSRC to identify a "physical" media source. A conceptual media source: Uses the SSRC to identify the result of applying some filtering function in a network node, for example a filtering function in an RTP mixer that provides the most active speaker based on some criteria, or a mix representing a set of other sources. Westerlund, et al. Expires December 18, 2020 [Page 9] Internet-Draft Guidelines for Multiplexing in RTP June 2020 An RTP receiver: Uses the SSRC to identify itself as the source of its RTCP reports. An endpoint that generates more than one media type, e.g. a conference participant sending both audio and video, need not (and, indeed, should not) use the same SSRC value across RTP sessions. RTCP compound packets containing the CNAME SDES item is the designated method to bind an SSRC to a CNAME, effectively cross- correlating SSRCs within and between RTP Sessions as coming from the same endpoint. The main property attributed to SSRCs associated with the same CNAME is that they are from a particular synchronisation context and can be synchronised at playback. An RTP receiver receiving a previously unseen SSRC value will interpret it as a new source. It might in fact be a previously existing source that had to change SSRC number due to an SSRC conflict. Use of the MID extension [I-D.ietf-mmusic-sdp-bundle-negotiation] helps to identify which media source the new SSRC represents and use of the RID extension [I-D.ietf-mmusic-rid] helps to identify what encoding or redundancy stream it represents, even though the SSRC changed. However, the originator of the previous SSRC ought to have ended the conflicting source by sending an RTCP BYE for it prior to starting to send with the new SSRC, making the new SSRC a new source. 3.2.3. Contributing Source (CSRC) The Contributing Source (CSRC) is not a separate identifier. Rather an SSRC identifier is listed as a CSRC in the RTP header of a packet generated by an RTP mixer or video MCU/switch, if the corresponding SSRC was in the header of one of the packets that contributed to the output. It is not possible, in general, to extract media represented by an individual CSRC since it is typically the result of a media merge (e.g. mix) operation on the individual media streams corresponding to the CSRC identifiers. The exception is the case when only a single CSRC is indicated as this represent forwarding of an RTP stream, possibly modified. The RTP header extension for Mixer-to-Client Audio Level Indication [RFC6465] expands on the receiver's information about a packet with a CSRC list. Due to these restrictions, CSRC will not be considered a fully qualified multiplexing point and will be disregarded in the rest of this document. Westerlund, et al. Expires December 18, 2020 [Page 10] Internet-Draft Guidelines for Multiplexing in RTP June 2020 3.2.4. RTP Payload Type Each RTP stream utilises one or more RTP payload formats. An RTP payload format describes how the output of a particular media codec is framed and encoded into RTP packets. The payload format is identified by the payload type (PT) field in the RTP packet header. The combination of SSRC and PT therefore identifies a specific RTP stream in a specific encoding format. The format definition can be taken from [RFC3551] for statically allocated payload types, but ought to be explicitly defined in signalling, such as SDP, both for static and dynamic payload types. The term "format" here includes those aspects described by out-of-band signalling means; in SDP, the term "format" includes media type, RTP timestamp sampling rate, codec, codec configuration, payload format configurations, and various robustness mechanisms such as redundant encodings [RFC2198]. The RTP payload type is scoped by the sending endpoint within an RTP session. PT has the same meaning across all RTP streams in an RTP session. All SSRCs sent from a single endpoint share the same payload type definitions. The RTP payload type is designed such that only a single payload type is valid at any time instant in the RTP stream's timestamp time line, effectively time-multiplexing different payload types if any change occurs. The payload type can change on a per-packet basis for an SSRC, for example a speech codec making use of generic comfort noise [RFC3389]. If there is a true need to send multiple payload types for the same SSRC that are valid for the same instant, then redundant encodings [RFC2198] can be used. Several additional constraints than the ones mentioned above need to be met to enable this use, one of which is that the combined payload sizes of the different payload types ought not exceed the transport MTU. Other aspects of RTP payload format use are described in How to Write an RTP Payload Format [RFC8088]. The payload type is not a multiplexing point at the RTP layer (see Appendix A for a detailed discussion of why using the payload type as an RTP multiplexing point does not work). The RTP payload type is, however, used to determine how to consume and decode an RTP stream. The RTP payload type number is sometimes used to associate an RTP stream with the signalling, which in general requires that unique RTP payload type numbers are used in each context. Use of MID, e.g. when bundling "m=" sections [I-D.ietf-mmusic-sdp-bundle-negotiation], can replace the payload type as signalling association and unique RTP payload types are then no longer required for that purpose. Westerlund, et al. Expires December 18, 2020 [Page 11] Internet-Draft Guidelines for Multiplexing in RTP June 2020 3.3. Issues Related to RTP Topologies The impact of how RTP multiplexing is performed will in general vary with how the RTP session participants are interconnected, described by RTP Topology [RFC7667]. Even the most basic use case, denoted Topo-Point-to-Point in [RFC7667], raises a number of considerations that are discussed in detail in following sections. They range over such aspects as: o Does my communication peer support RTP as defined with multiple SSRCs per RTP session? o Do I need network differentiation in form of QoS (Section 4.2.1)? o Can the application more easily process and handle the media streams if they are in different RTP sessions? o Do I need to use additional RTP streams for RTP retransmission or FEC? For some point to multi-point topologies (e.g. Topo-ASM and Topo-SSM in [RFC7667]), multicast is used to interconnect the session participants. Special considerations (documented in Section 4.2.3) are then needed as multicast is a one-to-many distribution system. Sometimes an RTP communication can end up in a situation when the communicating peers are not compatible for various reasons: o No common media codec for a media type thus requiring transcoding. o Different support for multiple RTP streams and RTP sessions. o Usage of different media transport protocols, i.e., RTP or other. o Usage of different transport protocols, e.g., UDP, DCCP, or TCP. o Different security solutions, e.g., IPsec, TLS, DTLS, or SRTP with different keying mechanisms. In many situations this is resolved by the inclusion of a translator between the two peers, as described by Topo-PtP-Translator in [RFC7667]. The translator's main purpose is to make the peers look compatible to each other. There can also be other reasons than compatibility to insert a translator in the form of a middlebox or gateway, for example a need to monitor the RTP streams. Beware that changing the stream transport characteristics in the translator can Westerlund, et al. Expires December 18, 2020 [Page 12] Internet-Draft Guidelines for Multiplexing in RTP June 2020 require thorough understanding of aspects from congestion control and media adaptation to application-layer semantics. Within the uses enabled by the RTP standard, the point to point topology can contain one or more RTP sessions with one or more media sources per session, each having one or more RTP streams per media source. 3.4. Issues Related to RTP and RTCP Protocol Using multiple RTP streams is a well-supported feature of RTP. However, for most implementers or people writing RTP/RTCP applications or extensions attempting to apply multiple streams, it can be unclear when it is most appropriate to add an additional RTP stream in an existing RTP session and when it is better to use multiple RTP sessions. This section discusses the various considerations needed. 3.4.1. The RTP Specification RFC 3550 contains some recommendations and a bullet list with 5 arguments for different aspects of RTP multiplexing. Please review Section 5.2 of [RFC3550]. Five important aspects are quoted below. 1. If, say, two audio streams shared the same RTP session and the same SSRC value, and one were to change encodings and thus acquire a different RTP payload type, there would be no general way of identifying which stream had changed encodings. The first argument is to use different SSRC for each individual RTP stream, which is fundamental to RTP operation. 2. An SSRC is defined to identify a single timing and sequence number space. Interleaving multiple payload types would require different timing spaces if the media clock rates differ and would require different sequence number spaces to tell which payload type suffered packet loss. The second argument is advocating against demultiplexing RTP streams within a session based only on their RTP payload type numbers, which still stands as can been seen by the extensive list of issues found in Appendix A. 3. The RTCP sender and receiver reports (see Section 6.4) can only describe one timing and sequence number space per SSRC and do not carry a payload type field. Westerlund, et al. Expires December 18, 2020 [Page 13] Internet-Draft Guidelines for Multiplexing in RTP June 2020 The third argument is yet another argument against payload type multiplexing. 4. An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream. The fourth argument is against multiplexing RTP packets that require different handling into the same session. In most cases the RTP mixer must embed application logic to handle streams; the separation of streams according to stream type is just another piece of application logic, which might or might not be appropriate for a particular application. One type of application that can mix different media sources blindly is the audio-only telephone bridge, although the ability to do that comes from the well-defined scenario that is aided by use of a single media type, even though individual streams may use incompatible codec types; most other types of applications need application-specific logic to perform the mix correctly. 5. Carrying multiple media in one RTP session precludes: the use of different network paths or network resource allocations if appropriate; reception of a subset of the media if desired, for example just audio if video would exceed the available bandwidth; and receiver implementations that use separate processes for the different media, whereas using separate RTP sessions permits either single- or multiple-process implementations. The fifth argument discusses network aspects that are described in Section 4.2. It also goes into aspects of implementation, like Split Component Terminal (see Section 3.10 of [RFC7667]) endpoints where different processes or inter-connected devices handle different aspects of the whole multi-media session. A summary of RFC 3550's view on multiplexing is to use unique SSRCs for anything that is its own media/packet stream, and to use different RTP sessions for media streams that don't share a media type. This document supports the first point; it is very valid. The latter needs further discussion, as imposing a single solution on all usages of RTP is inappropriate. "Multiple Media Types in an RTP Session specification" [I-D.ietf-avtcore-multi-media-rtp-session] updates RFC 3550 to allow multiple media types in a RTP session. It also provides a detailed analysis of the potential benefits and issues in having multiple media types in the same RTP session. Thus, that document provides a wider scope for an RTP session and considers multiple media types in one RTP session as a possible choice for the RTP application designer. Westerlund, et al. Expires December 18, 2020 [Page 14] Internet-Draft Guidelines for Multiplexing in RTP June 2020 3.4.2. Multiple SSRCs in a Session Using multiple SSRCs at one endpoint in an RTP session requires resolving some unclear aspects of the RTP specification. These could potentially lead to some interoperability issues as well as some potential significant inefficiencies, as further discussed in "RTP Considerations for Endpoints Sending Multiple Media Streams" [RFC8108]. An RTP application designer should consider these issues and the possible application impact from lack of appropriate RTP handling or optimization in the peer endpoints. Using multiple RTP sessions can potentially mitigate application issues caused by multiple SSRCs in an RTP session. 3.4.3. Binding Related Sources A common problem in a number of various RTP extensions has been how to bind related RTP streams together. This issue is common to both using additional SSRCs and multiple RTP sessions. The solutions can be divided into a few groups: o RTP/RTCP based o Signalling based, e.g. SDP o Grouping related RTP sessions o Grouping SSRCs within an RTP session Most solutions are explicit, but some implicit methods have also been applied to the problem. The SDP-based signalling solutions are: SDP Media Description Grouping: The SDP Grouping Framework [RFC5888] uses various semantics to group any number of media descriptions. This has primarily been grouping RTP sessions, but in combination with [I-D.ietf-mmusic-sdp-bundle-negotiation] it can also group multiple media descriptions within a single RTP session. SDP Media Multiplexing: Negotiating Media Multiplexing Using the Session Description Protocol (SDP) [I-D.ietf-mmusic-sdp-bundle-negotiation] uses both SDP and RTCP information to associate RTP streams to SDP media descriptions. This allows both to group RTP streams belonging to an SDP media description, and to group multiple SDP media descriptions into a single RTP session. Westerlund, et al. Expires December 18, 2020 [Page 15] Internet-Draft Guidelines for Multiplexing in RTP June 2020 SDP SSRC grouping: Source-Specific Media Attributes in SDP [RFC5576] includes a solution for grouping SSRCs the same way as the Grouping framework groups Media Descriptions. The above grouping constructs support many use cases. Those solutions have shortcomings in cases where the session's dynamic properties are such that it is difficult or a drain on resources to keep the list of related SSRCs up to date. An RTP/RTCP-based grouping solution is to use the RTCP SDES CNAME to bind related RTP streams to an endpoint or to a synchronization context. For applications with a single RTP stream per type (media, source or redundancy stream), CNAME is sufficient for that purpose independently of whether one or more RTP sessions are used. However, some applications choose not to use CNAME because of perceived complexity or a desire not to implement RTCP and instead use the same SSRC value to bind related RTP streams across multiple RTP sessions. RTP Retransmission [RFC4588] in multiple RTP session mode and Generic FEC [RFC5109] both use the CNAME method to relate the RTP streams, which may work but might have some downsides in RTP sessions with many participating SSRCs. It is not recommended to use identical SSRC values across RTP sessions to relate RTP streams; When an SSRC collision occurs, this will force change of that SSRC in all RTP sessions and thus resynchronize all of them instead of only the single media stream having the collision. Another method to implicitly bind SSRCs is used by RTP Retransmission [RFC4588] when using the same RTP session as the source RTP stream for retransmissions. The receiver missing a packet issues an RTP retransmission request, and then awaits a new SSRC carrying the RTP retransmission payload and where that SSRC is from the same CNAME. This limits a requester to having only one outstanding retransmission request on any new source SSRCs per endpoint. RTP Payload Format Restrictions [I-D.ietf-mmusic-rid] provides an RTP/RTCP based mechanism to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types. The mapping is done by specifying an "a=rid" value in the SDP offer/answer signalling and having the corresponding RtpStreamId value as an SDES item and an RTP header extension. The RID solution also includes a solution for binding redundancy RTP streams to their original source RTP streams, given that those use RID identifiers. Experience has found that an explicit binding between the RTP streams, agnostic of SSRC values, behaves well. That way, solutions Westerlund, et al. Expires December 18, 2020 [Page 16] Internet-Draft Guidelines for Multiplexing in RTP June 2020 using multiple RTP streams in a single RTP session and in multiple RTP sessions will use the same type of binding. 3.4.4. Forward Error Correction There exist a number of Forward Error Correction (FEC) based schemes for how to mitigate packet loss in the original streams. Most of the FEC schemes protect a single source flow. The protection is achieved by transmitting a certain amount of redundant information that is encoded such that it can repair one or more packet losses over the set of packets the redundant information protects. This sequence of redundant information needs to be transmitted as its own media stream, or in some cases, instead of the original media stream. Thus, many of these schemes create a need for binding related flows as discussed above. Looking at the history of these schemes, there are schemes using multiple SSRCs and schemes using multiple RTP sessions, and some schemes that support both modes of operation. Using multiple RTP sessions supports the case where some set of receivers might not be able to utilise the FEC information. By placing it in a separate RTP session and if separating RTP sessions on transport level, FEC can easily be ignored already on the transport level, without considering any RTP layer information. In usages involving multicast, having the FEC information on its own multicast group allows for similar flexibility. This is especially useful when receivers see heterogeneous packet loss rates. A receiver can decide, based on measurement of experienced packet loss rates, whether to join a multicast group with the suitable FEC data repair capabilities. 4. Considerations for RTP Multiplexing 4.1. Interworking Considerations There are several different kinds of interworking, and this section discusses two; interworking directly between different applications, and interworking of applications through an RTP Translator. The discussion includes the implications of potentially different RTP multiplexing point choices and limitations that have to be considered when working with some legacy applications. 4.1.1. Application Interworking It is not uncommon that applications or services of similar but not identical usage, especially the ones intended for interactive communication, encounter a situation where one want to interconnect two or more of these applications. Westerlund, et al. Expires December 18, 2020 [Page 17] Internet-Draft Guidelines for Multiplexing in RTP June 2020 In these cases, one ends up in a situation where one might use a gateway to interconnect applications. This gateway must then either change the multiplexing structure or adhere to the respective limitations in each application. There are two fundamental approaches to building a gateway: using RTP Translator interworking (RTP bridging), where the gateway acts as an RTP Translator with the two interconnected applications being members of the same RTP session; or using Gateway Interworking with RTP termination, where there are independent RTP sessions between each interconnected application and the gateway. For interworking to be feasible, any security solution in use needs to be compatible and capable of exchanging keys with either the peer or the gateway under the used trust model. Secondly, the applications need to use media streams in a way that makes sense in both applications. 4.1.2. RTP Translator Interworking From an RTP perspective, the RTP Translator approach could work if all the applications are using the same codecs with the same payload types, have made the same multiplexing choices, and have the same capabilities in number of simultaneous RTP streams combined with the same set of RTP/RTCP extensions being supported. Unfortunately, this might not always be true. When a gateway is implemented via an RTP Translator, an important consideration is if the two applications being interconnected need to use the same approach to multiplexing. If one side is using RTP session multiplexing and the other is using SSRC multiplexing with BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], it may be possible for the RTP translator to map the RTP streams between both sides using some method, e.g. based on the number and order of SDP "m=" lines from each side. There are also challenges with SSRC collision handling since, unless SSRC translation is applied on the RTP translator, there may be a collision on the SSRC multiplexing side that the RTP session multiplexing side will not be aware of. Furthermore, if one of the applications is capable of working in several modes (such as being able to use additional RTP streams in one RTP session or multiple RTP sessions at will), and the other one is not, successful interconnection depends on locking the more flexible application into the operating mode where interconnection can be successful, even if none of the participants are using the less flexible application when the RTP sessions are being created. Westerlund, et al. Expires December 18, 2020 [Page 18] Internet-Draft Guidelines for Multiplexing in RTP June 2020 4.1.3. Gateway Interworking When one terminates RTP sessions at the gateway, there are certain tasks that the gateway has to carry out: o Generating appropriate RTCP reports for all RTP streams (possibly based on incoming RTCP reports), originating from SSRCs controlled by the gateway. o Handling SSRC collision resolution in each application's RTP sessions. o Signalling, choosing, and policing appropriate bit-rates for each session. For applications that use any security mechanism, e.g., in the form of SRTP, the gateway needs to be able to decrypt and verify source integrity of the incoming packets, and re-encrypt, integrity protect, and sign the packets as the peer in the other application's security context. This is necessary even if all that's needed is a simple remapping of SSRC numbers. If this is done, the gateway also needs to be a member of the security contexts of both sides, and thus a trusted entity. The gateway might also need to apply transcoding (for incompatible codec types), media-level adaptations that cannot be solved through media negotiation (such as rescaling for incompatible video size requirements), suppression of content that is known not to be handled in the destination application, or the addition or removal of redundancy coding or scalability layers to fit the needs of the destination domain. From the above, we can see that the gateway needs to have an intimate knowledge of the application requirements; a gateway is by its nature application specific, not a commodity product. These gateways might therefore potentially block application evolution by blocking RTP and RTCP extensions that the applications have been extended with but that are unknown to the gateway. If one uses security mechanism, like SRTP, the gateway and the necessary trust in it by the peers is an additional risk to the communication security. The gateway also incur additional complexities in form of the decrypt-encrypt cycles needed for each forwarded packet. SRTP, due to its keying structure, also requires that each RTP session needs different master keys, as use of the same key in two RTP sessions can for some ciphers result in a reuse of a Westerlund, et al. Expires December 18, 2020 [Page 19] Internet-Draft Guidelines for Multiplexing in RTP June 2020 one-time pad that completely breaks the confidentiality of the packets. 4.1.4. Multiple SSRC Legacy Considerations Historically, the most common RTP use cases have been point-to-point Voice over IP (VoIP) or streaming applications, commonly with no more than one media source per endpoint and media type (typically audio or video). Even in conferencing applications, especially voice-only, the conference focus or bridge has provided a single stream to each participant containing a mix of the other participants. It is also common to have individual RTP sessions between each endpoint and the RTP mixer, meaning that the mixer functions as an RTP-terminating gateway. Applications and systems that aren't updated to handle multiple streams following these recommendations can have issues with participating in RTP sessions containing multiple SSRCs within a single session, such as: 1. Need to handle more than one stream simultaneously rather than replacing an already existing stream with a new one. 2. Be capable of decoding multiple streams simultaneously. 3. Be capable of rendering multiple streams simultaneously. This indicates that gateways attempting to interconnect to this class of devices have to make sure that only one RTP stream of each media type gets delivered to the endpoint if it's expecting only one, and that the multiplexing format is what the device expects. It is highly unlikely that RTP translator-based interworking can be made to function successfully in such a context. 4.2. Network Considerations The RTP implementer needs to consider that the RTP multiplexing choice also impacts network level mechanisms. 4.2.1. Quality of Service Quality of Service mechanisms are either flow based or packet marking based. RSVP [RFC2205] is an example of a flow based mechanism, while Diff-Serv [RFC2474] is an example of a packet marking based one. For a flow based scheme, additional SSRC will receive the same QoS as all other RTP streams being part of the same 5-tuple (protocol, Westerlund, et al. Expires December 18, 2020 [Page 20] Internet-Draft Guidelines for Multiplexing in RTP June 2020 source address, destination address, source port, destination port), which is the most common selector for flow based QoS. For a packet marking based scheme, the method of multiplexing will not affect the possibility to use QoS. Different Differentiated Services Code Points (DSCP) can be assigned to different packets within a transport flow (5-Tuple) as well as within an RTP stream, assuming usage of UDP or other transport protocol that do not have issues with packet reordering within the transport flow (5-tuple). To avoid packet reording issues, packets belonging to the same RTP flow should limits its use of DSCP to those whose corresponding Per Hop Behavior (PHB) that do not enable reordering. If the transport protocol used assumes in order delivery of packet, such as TCP and SCTP, then a single DSCP should be used. For more discussion of this see [RFC7657]. The method for assigning marking to packets can impact what number of RTP sessions to choose. If this marking is done using a network ingress function, it can have issues discriminating the different RTP streams. The network API on the endpoint also needs to be capable of setting the marking on a per-packet basis to reach the full functionality. 4.2.2. NAT and Firewall Traversal In today's networks there exist a large number of middleboxes. The ones that normally have most impact on RTP are Network Address Translators (NAT) and Firewalls (FW). Below we analyse and comment on the impact of requiring more underlying transport flows in the presence of NATs and Firewalls: End-Point Port Consumption: A given IP address only has 65536 available local ports per transport protocol for all consumers of ports that exist on the machine. This is normally never an issue for an end-user machine. It can become an issue for servers that handle large number of simultaneous streams. However, if the application uses ICE to authenticate STUN requests, a server can serve multiple endpoints from the same local port, and use the whole 5-tuple (source and destination address, source and destination port, protocol) as identifier of flows after having securely bound them to the remote endpoint address using the STUN request. In theory, the minimum number of media server ports needed are the maximum number of simultaneous RTP sessions a single endpoint can use. In practice, implementation will probably benefit from using more server ports to simplify implementation or avoid performance bottlenecks. Westerlund, et al. Expires December 18, 2020 [Page 21] Internet-Draft Guidelines for Multiplexing in RTP June 2020 NAT State: If an endpoint sits behind a NAT, each flow it generates to an external address will result in a state that has to be kept in the NAT. That state is a limited resource. In home or Small Office/Home Office (SOHO) NATs, memory or processing are usually the most limited resources. For large scale NATs serving many internal endpoints, available external ports are likely the scarce resource. Port limitations is primarily a problem for larger centralised NATs where endpoint independent mapping requires each flow to use one port for the external IP address. This affects the maximum number of internal users per external IP address. However, as a comparison, a real-time video conference session with audio and video likely uses less than 10 UDP flows, compared to certain web applications that can use 100+ TCP flows to various servers from a single browser instance. NAT Traversal Extra Delay: Performing the NAT/FW traversal takes a certain amount of time for each flow. It also takes time in a phase of communication between accepting to communicate and the media path being established, which is fairly critical. The best case scenario for additional NAT/FW traversal time after finding the first valid candidate pair following the specified ICE procedures is 1.5*RTT + Ta*(Additional_Flows-1), where Ta is the pacing timer. That assumes a message in one direction, immediately followed by a check back. The reason it isn't more, is that ICE first finds one candidate pair that works prior to attempting to establish multiple flows. Thus, there is no extra time until one has found a working candidate pair. Based on that working pair, the extra time is needed to in parallel establish the, in most cases 2-3, additional flows. However, packet loss causes extra delays, at least 500 ms, which is the minimal retransmission timer for ICE. NAT Traversal Failure Rate: Due to the need to establish more than a single flow through the NAT, there is some risk that establishing the first flow succeeds but that one or more of the additional flows fail. The risk that this happens is hard to quantify, but ought to be fairly low as one flow from the same interfaces has just been successfully established. Thus only rare events such as NAT resource overload, or selecting particular port numbers that are filtered etc., ought to be reasons for failure. Deep Packet Inspection and Multiple Streams: Firewalls differ in how deeply they inspect packets. Due to all previous issues with firewall and Session Boarder Gateways (SBG) with RTP transport media e.g. in Voice over IP (VoIP) systems, there exists a significant risk that deeply inspecting firewalls will have similar legacy issues with multiple SSRCs as some RTP stack implementations. Westerlund, et al. Expires December 18, 2020 [Page 22] Internet-Draft Guidelines for Multiplexing in RTP June 2020 Using additional RTP streams in the same RTP session and transport flow does not introduce any additional NAT traversal complexities per RTP stream. This can be compared with normally one or two additional transport flows per RTP session when using multiple RTP sessions. Additional lower layer transport flows will be needed, unless an explicit de-multiplexing layer is added between RTP and the transport protocol. At time of writing no such mechanism was defined. 4.2.3. Multicast Multicast groups provides a powerful tool for a number of real-time applications, especially the ones that desire broadcast-like behaviours with one endpoint transmitting to a large number of receivers, like in IPTV. There is also the RTP/RTCP extension to better support Source Specific Multicast (SSM) [RFC5760]. Many-to- many communication, which RTP [RFC3550] was originally built to support, has several limitations in common with multicast. One limitation is that, for any group, sender side adaptation with the intent to suit all receivers would have to adapt to the most limited receiver experiencing the worst conditions among the group participants, which imposes degradation for all participants. For broadcast-type applications with a large number of receivers, this is not acceptable. Instead, various receiver-based solutions are employed to ensure that the receivers achieve best possible performance. By using scalable encoding and placing each scalability layer in a different multicast group, the receiver can control the amount of traffic it receives. To have each scalability layer on a different multicast group, one RTP session per multicast group is used. In addition, the transport flow considerations in multicast are a bit different from unicast; NATs with port translation are not useful in the multicast environment, meaning that the entire port range of each multicast address is available for distinguishing between RTP sessions. Thus, when using broadcast applications it appears easiest and most straightforward to use multiple RTP sessions for sending different media flows used for adapting to network conditions. It is also common that streams improving transport robustness are sent in their own multicast group to allow for interworking with legacy or to support different levels of protection. Many-to-many applications have different needs and the most appropriate multiplexing choice will depend on how the actual application is realized. Multicast applications that are capable of using sender side congestion control can avoid the use of multiple Westerlund, et al. Expires December 18, 2020 [Page 23] Internet-Draft Guidelines for Multiplexing in RTP June 2020 multicast sessions and RTP sessions that result from use of receiver side congestion control. The properties of a broadcast application using RTP multicast: 1. Uses a group of RTP sessions, not just one. Each endpoint will need to be a member of a number of RTP sessions in order to perform well. 2. Within each RTP session, the number of RTP receivers is likely to be much larger than the number of RTP senders. 3. The applications need signalling functions to identify the relationships between RTP sessions. 4. The applications need signalling or RTP/RTCP functions to identify the relationships between SSRCs in different RTP sessions when needs beyond CNAME exist. Both broadcast and many-to-many multicast applications share a signalling requirement; all of the participants need the same RTP and payload type configuration. Otherwise, A could for example be using payload type 97 as the video codec H.264 while B thinks it is MPEG-2. SDP offer/answer [RFC3264] is not appropriate for ensuring this property in broadcast/multicast context. The signalling aspects of broadcast/multicast are not explored further in this memo. Security solutions for this type of group communication are also challenging. First, the key-management and the security protocol need to support group communication. Second, source authentication requires special solutions. For more discussion on this please review Options for Securing RTP Sessions [RFC7201]. 4.3. Security and Key Management Considerations When dealing with point-to-point, 2-member RTP sessions only, there are few security issues that are relevant to the choice of having one RTP session or multiple RTP sessions. However, there are a few aspects of multiparty sessions that might warrant consideration. For general information of possible methods of securing RTP, please review RTP Security Options [RFC7201]. 4.3.1. Security Context Scope When using SRTP [RFC3711], the security context scope is important and can be a necessary differentiation in some applications. As SRTP's crypto suites are (so far) built around symmetric keys, the receiver will need to have the same key as the sender. This results Westerlund, et al. Expires December 18, 2020 [Page 24] Internet-Draft Guidelines for Multiplexing in RTP June 2020 in that no one in a multi-party session can be certain that a received packet really was sent by the claimed sender and not by another party having access to the key. The single SRTP algorithm not having this propery is the TESLA source authentication [RFC4383]. However, TESLA adds delay to achieve source authentication. In most cases, symmetric ciphers provide sufficient security properties but create issues in a few cases. The first case is when someone leaves a multi-party session and one wants to ensure that the party that left can no longer access the RTP streams. This requires that everyone re-keys without disclosing the new keys to the excluded party. A second case is when using security as an enforcing mechanism for stream access differentiation between different receivers. Take for example a scalable layer or a high quality simulcast version that only users paying a premium are allowed to access. The mechanism preventing a receiver from getting the high quality stream can be based on the stream being encrypted with a key that user can't access without paying premium, using the key-management to limit access to the key. SRTP [RFC3711] as specified uses per SSRC unique keys, however the original assumption was a single session master key from which SSRC specific RTP and RTCP keys where derived. However, that assumption was proven incorrect, as the application usage and the developed key- mamangement mechanisms have chosen many different methods for ensuring SSRC unique keys. The key-management functions have different capabilities to establish different sets of keys, normally on a per-endpoint basis. For example, DTLS-SRTP [RFC5764] and Security Descriptions [RFC4568] establish different keys for outgoing and incoming traffic from an endpoint. This key usage has to be written into the cryptographic context, possibly associated with different SSRCs. Thus, limitations do exist depending on chosen key- management method and due to integration of particular implementations of the key-management and SRTP. 4.3.2. Key Management for Multi-party Sessions The capabilities of the key-management combined with the RTP multiplexing choices affects the resulting security properties, control over the secured media, and who have access to it. Multi-party sessions contain at least one RTP stream from each active participant. Depending on the multi-party topology [RFC7667], each participant can both send and receive multiple RTP streams. Transport translator-based sessions (Topo-Trn-Translator) and multicast sessions (Topo-ASM), can neither use Security Description Westerlund, et al. Expires December 18, 2020 [Page 25] Internet-Draft Guidelines for Multiplexing in RTP June 2020 [RFC4568] nor DTLS-SRTP [RFC5764] without an extension as each endpoint provides its set of keys. In centralised conferences, the signalling counterpart is a conference server, and the transport translator is the media plane unicast counterpart (to which DTLS messages would be sent). Thus, an extension like Encrypted Key Transport [I-D.ietf-perc-srtp-ekt-diet] or a MIKEY [RFC3830] based solution that allows for keying all session participants with the same master key is needed. Privacy Enchanced RTP Conferencing (PERC) also enables a different trust model with semi-trusted media switching RTP middleboxes [I-D.ietf-perc-private-media-framework]. 4.3.3. Complexity Implications The usage of security functions can surface complexity implications from the choice of multiplexing and topology. This becomes especially evident in RTP topologies having any type of middlebox that processes or modifies RTP/RTCP packets. While there is very small overhead for an RTP translator or mixer to rewrite an SSRC value in the RTP packet of an unencrypted session, the cost is higher when using cryptographic security functions. For example, if using SRTP [RFC3711], the actual security context and exact crypto key are determined by the SSRC field value. If one changes SSRC, the encryption and authentication must use another key. Thus, changing the SSRC value implies a decryption using the old SSRC and its security context, followed by an encryption using the new one. 5. RTP Multiplexing Design Choices This section discusses how some RTP multiplexing design choices can be used in applications to achieve certain goals, and a summary of the implications of such choices. For each design there is discussion of benefits and downsides. 5.1. Multiple Media Types in One Session This design uses a single RTP session for multiple different media types, like audio and video, and possibly also transport robustness mechanisms like FEC or retransmission. An endpoint can send zero, one or more media sources per media type, resulting in a number of RTP streams of various media types for both source and redundancy streams. The Advantages: 1. Only a single RTP session is used, which implies: Westerlund, et al. Expires December 18, 2020 [Page 26] Internet-Draft Guidelines for Multiplexing in RTP June 2020 * Minimal need to keep NAT/FW state. * Minimal NAT/FW-traversal cost. * Fate-sharing for all media flows. * Minimal overhead for security association establishment. 2. Dynamic allocation of RTP streams can be handled almost entirely at RTP level. How localized this can be kept to RTP level depends on the application's needs for explicit indication of the stream usage and how timely that can be signalled. The Disadvantages: a. It is less suitable for interworking with other applications that use individual RTP sessions per media type or multiple sessions for a single media type, due to the risk of SSRC collision and thus potential need for SSRC translation. b. Negotiation of individual bandwidths for the different media types is currently only possible in SDP when using RID [I-D.ietf-mmusic-rid]. c. It is not suitable for Split Component Terminal (see Section 3.10 of [RFC7667]). d. Flow-based QoS cannot be used to provide separate treatment of RTP streams compared to others in the single RTP session. e. If there is significant asymmetry between the RTP streams' RTCP reporting needs, there are some challenges in configuration and usage to avoid wasting RTCP reporting on the RTP stream that does not need that frequent reporting. f. It is not suitable for applications where some receivers like to receive only a subset of the RTP streams, especially if multicast or transport translator is being used. g. There is some additional concern with legacy implementations that do not support the RTP specification fully when it comes to handling multiple SSRC per endpoint, as multiple simultaneous media types are sent as separate SSRC in the same RTP session. h. If the applications need finer control over which session participants are included in different sets of security associations, most key-management mechanisms will have difficulties establishing such a session. Westerlund, et al. Expires December 18, 2020 [Page 27] Internet-Draft Guidelines for Multiplexing in RTP June 2020 5.2. Multiple SSRCs of the Same Media Type In this design, each RTP session serves only a single media type. The RTP session can contain multiple RTP streams, either from a single endpoint or from multiple endpoints. This commonly creates a low number of RTP sessions, typically only one for audio and one for video, with a corresponding need for two listening ports when using RTP/RTCP multiplexing [RFC5761]. The Advantages 1. It works well with Split Component Terminal (see Section 3.10 of [RFC7667]) where the split is per media type. 2. It enables flow-based QoS with different prioritisation between media types. 3. For applications with dynamic usage of RTP streams, i.e. frequently added and removed, having much of the state associated with the RTP session rather than per individual SSRC can avoid the need for in-session signalling of meta-information about each SSRC. In the simple cases this allows for unsignalled RTP streams where session level information and RTCP SDES item (e.g. CNAME) are suffient. In the more complex cases where more source-specific metadata needs to be signalled the SSRC can be associated with an intermediate identifier, e.g. the MID conveyed as an SDES item as defined in Section 15 of [I-D.ietf-mmusic-sdp-bundle-negotiation]. 4. There is low overhead for security association establishment. The Disadvantages a. There are a slightly higher number of RTP sessions needed compared to Multiple Media Types in one Session Section 5.1. This implies: * More NAT/FW state is needed. * There is increased NAT/FW-traversal cost in both processing and delay. b. There is some potential for concern with legacy implementations that don't support the RTP specification fully when it comes to handling multiple SSRC per endpoint. c. It is not possible to control security association for sets of RTP streams within the same media type with today's key- Westerlund, et al. Expires December 18, 2020 [Page 28] Internet-Draft Guidelines for Multiplexing in RTP June 2020 management mechanisms, unless these are split into different RTP sessions (Section 5.3). For RTP applications where all RTP streams of the same media type share same usage, this structure provides efficiency gains in amount of network state used and provides more fate sharing with other media flows of the same type. At the same time, it is still maintaining almost all functionalities for the negotiation signaling of properties per individual media type, and also enables flow based QoS prioritisation between media types. It handles multi-party sessions well, independently of multicast or centralised transport distribution, as additional sources can dynamically enter and leave the session. 5.3. Multiple Sessions for One Media Type This design goes one step further than above (Section 5.2) by using multiple RTP sessions also for a single media type. The main reason for going in this direction is that the RTP application needs separation of the RTP streams due to their usage, such as e.g. scalability over multicast, simulcast, need for extended QoS prioritisation, or the need for fine-grained signalling using RTP session-focused signalling tools. The Advantages: 1. This is more suitable for multicast usage where receivers can individually select which RTP sessions they want to participate in, assuming each RTP session has its own multicast group. 2. The application can indicate its usage of the RTP streams on RTP session level, when multiple different usages exist. 3. There is less need for SSRC-specific explicit signalling for each media stream and thus reduced need for explicit and timely signalling when RTP streams are added or removed. 4. It enables detailed QoS prioritisation for flow-based mechanisms. 5. It works well with Split Component Terminal (see Section 3.10 of [RFC7667]). 6. The scope for who is included in a security association can be structured around the different RTP sessions, thus enabling such functionality with existing key-management. The Disadvantages: Westerlund, et al. Expires December 18, 2020 [Page 29] Internet-Draft Guidelines for Multiplexing in RTP June 2020 a. There is an increased amount of session configuration state compared to Multiple SSRCs of the Same Media Type, due to the increased amount of RTP sessions. b. For RTP streams that are part of scalability, simulcast or transport robustness, a method to bind sources across multiple RTP sessions is needed. c. There is some potential for concern with legacy implementations that don't support the RTP specification fully when it comes to handling multiple SSRC per endpoint. d. There is higher overhead for security association establishment, due to the increased number of RTP sessions. e. If the applications need more fine-grained control than per RTP session over which participants that are included in different sets of security associations, most of today's key-management will have difficulties establishing such a session. For more complex RTP applications that have several different usages for RTP streams of the same media type, or uses scalability or simulcast, this solution can enable those functions at the cost of increased overhead associated with the additional sessions. This type of structure is suitable for more advanced applications as well as multicast-based applications requiring differentiation to different participants. 5.4. Single SSRC per Endpoint In this design each endpoint in a point-to-point session has only a single SSRC, thus the RTP session contains only two SSRCs, one local and one remote. This session can be used both unidirectional, i.e. only a single RTP stream, or bi-directional, i.e. both endpoints have one RTP stream each. If the application needs additional media flows between the endpoints, it will have to establish additional RTP sessions. The Advantages: 1. This design has great legacy interoperability potential as it will not tax any RTP stack implementations. 2. The signalling has good possibilities to negotiate and describe the exact formats and bitrates for each RTP stream, especially using today's tools in SDP. Westerlund, et al. Expires December 18, 2020 [Page 30] Internet-Draft Guidelines for Multiplexing in RTP June 2020 3. It is possible to control security association per RTP stream with current key-management, since each RTP stream is directly related to an RTP session, and the most used keying mechanisms operates on a per-session basis. The Disadvantages: a. There is a linear growth of the amount of NAT/FW state with number of RTP streams. b. There is increased delay and resource consumption from NAT/FW- traversal. c. There are likely larger signalling message and signalling processing requirements due to the increased amount of session- related information. d. There is higher potential for a single RTP stream to fail during transport between the endpoints, due to the need for separate NAT/FW- traversal for every RTP stream since there is only one stream per session. e. The amount of explicit state for relating RTP streams grows, depending on how the application relates RTP streams. f. The port consumption might become a problem for centralised services, where the central node's port or 5-tuple filter consumption grows rapidly with the number of sessions. g. For applications where the RTP stream usage is highly dynamic, i.e. entering and leaving, the amount of signalling can become high. Issues can also arise from the need for timely establishment of additional RTP sessions. h. If, against the recommendation, the same SSRC value is reused in multiple RTP sessions rather than being randomly chosen, interworking with applications that use a different multiplexing structure will require SSRC translation. RTP applications with a strong need to interwork with legacy RTP applications can potentially benefit from this structure. However, a large number of media descriptions in SDP can also run into issues with existing implementations. For any application needing a larger number of media flows, the overhead can become very significant. This structure is also not suitable for non-mixed multi-party sessions, as any given RTP stream from each participant, although having same usage in the application, needs its own RTP session. In addition, the dynamic behaviour that can arise in multi-party Westerlund, et al. Expires December 18, 2020 [Page 31] Internet-Draft Guidelines for Multiplexing in RTP June 2020 applications can tax the signalling system and make timely media establishment more difficult. 5.5. Summary Both the "Single SSRC per Endpoint" and the "Multiple Media Types in One Session" are cases that require full explicit signalling of the media stream relations. However, they operate on two different levels where the first primarily enables session level binding, and the second needs SSRC level binding. From another perspective, the two solutions are the two extreme points when it comes to number of RTP sessions needed. The two other designs, "Multiple SSRCs of the Same Media Type" and "Multiple Sessions for One Media Type", are two examples that primarily allows for some implicit mapping of the role or usage of the RTP streams based on which RTP session they appear in. It thus potentially allows for less signalling and in particular reduces the need for real-time signalling in sessions with dynamically changing number of RTP streams. They also represent points in-between the first two designs when it comes to amount of RTP sessions established, i.e. representing an attempt to balance the amount of RTP sessions with the functionality the communication session provides both on network level and on signalling level. 6. Guidelines This section contains a number of multi-stream guidelines for implementers, system designers, or specification writers. Do not require use of the same SSRC value across RTP sessions: As discussed in Section 3.4.3 there exist drawbacks in using the same SSRC in multiple RTP sessions as a mechanism to bind related RTP streams together. It is instead recommended to use a mechanism to explicitly signal the relation, either in RTP/RTCP or in the signalling mechanism used to establish the RTP session(s). Use additional RTP streams for additional media sources: In the cases where an RTP endpoint needs to transmit additional RTP streams of the same media type in the application, with the same processing requirements at the network and RTP layers, it is suggested to send them in the same RTP session. For example a telepresence room where there are three cameras, and each camera captures 2 persons sitting at the table, sending each camera as its own RTP stream within a single RTP session is suggested. Use additional RTP sessions for streams with different requirements: Westerlund, et al. Expires December 18, 2020 [Page 32] Internet-Draft Guidelines for Multiplexing in RTP June 2020 When RTP streams have different processing requirements from the network or the RTP layer at the endpoints, it is suggested that the different types of streams are put in different RTP sessions. This includes the case where different participants want different subsets of the set of RTP streams. When using multiple RTP sessions, use grouping: When using multiple RTP session solutions, it is suggested to explicitly group the involved RTP sessions when needed using a signalling mechanism, for example The Session Description Protocol (SDP) Grouping Framework [RFC5888], using some appropriate grouping semantics. RTP/RTCP Extensions Support Multiple RTP Streams as Well as Multiple RTP Sessions: When defining an RTP or RTCP extension, the creator needs to consider if this extension is applicable to use with additional SSRCs and multiple RTP sessions. Any extension intended to be generic must support both. Extensions that are not as generally applicable will have to consider if interoperability is better served by defining a single solution or providing both options. Extensions for Transport Support: When defining new RTP/RTCP extensions intended for transport support, like the retransmission or FEC mechanisms, they must include support for both multiple RTP streams in the same RTP session and multiple RTP sessions, such that application developers can choose freely from the set of mechanisms without concerning themselves with which of the multiplexing choices a particular solution supports. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section can be removed on publication as an RFC. 8. Security Considerations The security considerations of the RTP specification [RFC3550], any applicable RTP profile [RFC3551],[RFC4585],[RFC3711], and the extensions for sending multiple media types in a single RTP session [I-D.ietf-avtcore-multi-media-rtp-session], RID [I-D.ietf-mmusic-rid], BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], [RFC5760], [RFC5761], apply if selected and thus need to be considered in the evaluation. There is discussion of the security implications of choosing multiple SSRC vs multiple RTP sessions in Section 4.3. Westerlund, et al. Expires December 18, 2020 [Page 33] Internet-Draft Guidelines for Multiplexing in RTP June 2020 9. Contributors Hui Zheng (Marvin) contributed to WG draft versions -04 and -05 of the document. 10. Acknowledgments The Authors like to acknowledge and thank Cullen Jennings, Dale R Worley, Huang Yihong (Rachel), Benjamin Kaduk, Mirja Kuehlewind, and Vijay Gurbani for review and comments. 11. References 11.1. Normative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", draft- ietf-avtcore-multi-media-rtp-session-13 (work in progress), December 2015. [I-D.ietf-mmusic-rid] Roach, A., "RTP Payload Format Restrictions", draft-ietf- mmusic-rid-15 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [I-D.ietf-perc-srtp-ekt-diet] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", draft-ietf-perc-srtp-ekt-diet-11 (work in progress), January 2020. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . Westerlund, et al. Expires December 18, 2020 [Page 34] Internet-Draft Guidelines for Multiplexing in RTP June 2020 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . 11.2. Informative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. Westerlund, et al. Expires December 18, 2020 [Page 35] Internet-Draft Guidelines for Multiplexing in RTP June 2020 [I-D.ietf-perc-private-media-framework] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC)", draft-ietf-perc-private-media- framework-12 (work in progress), June 2019. [JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "XEP-0166: Jingle", XMPP.org https://xmpp.org/extensions/xep-0166.html, September 2018. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, . Westerlund, et al. Expires December 18, 2020 [Page 36] Internet-Draft Guidelines for Multiplexing in RTP June 2020 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, . [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, . [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, DOI 10.17487/RFC4383, February 2006, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . Westerlund, et al. Expires December 18, 2020 [Page 37] Internet-Draft Guidelines for Multiplexing in RTP June 2020 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- time Transport Protocol (RTP) Header Extension for Mixer- to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, . [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, . [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", RFC 8088, DOI 10.17487/RFC8088, May 2017, . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . Westerlund, et al. Expires December 18, 2020 [Page 38] Internet-Draft Guidelines for Multiplexing in RTP June 2020 Appendix A. Dismissing Payload Type Multiplexing This section documents a number of reasons why using the payload type as a multiplexing point is unsuitable for most issues related to multiple RTP streams. Attempting to use Payload type multiplexing beyond its defined usage has well known negative effects on RTP discussed below. To use payload type as the single discriminator for multiple streams implies that all the different RTP streams are being sent with the same SSRC, thus using the same timestamp and sequence number space. This has many effects: 1. Putting constraints on RTP timestamp rate for the multiplexed media. For example, RTP streams that use different RTP timestamp rates cannot be combined, as the timestamp values need to be consistent across all multiplexed media frames. Thus streams are forced to use the same RTP timestamp rate. When this is not possible, payload type multiplexing cannot be used. 2. Many RTP payload formats can fragment a media object over multiple RTP packets, like parts of a video frame. These payload formats need to determine the order of the fragments to correctly decode them. Thus, it is important to ensure that all fragments related to a frame or a similar media object are transmitted in sequence and without interruptions within the object. This can relatively simple be solved on the sender side by ensuring that the fragments of each RTP stream are sent in sequence. 3. Some media formats require uninterrupted sequence number space between media parts. These are media formats where any missing RTP sequence number will result in decoding failure or invoking a repair mechanism within a single media context. The text/ T140 payload format [RFC4103] is an example of such a format. These formats will need a sequence numbering abstraction function between RTP and the individual RTP stream before being used with payload type multiplexing. 4. Sending multiple media streams in the same sequence number space makes it impossible to determine which media stream lost a packet. This as the payload type that is used for demultiplex the media stream is not received. Thus, causing the receiver difficulties in determining which stream to apply packet loss concealment or other stream-specific loss mitigation mechanisms. 5. If RTP Retransmission [RFC4588] is used and there is a loss, it is possible to ask for the missing packet(s) by SSRC and sequence number, not by payload type. If only some of the payload type multiplexed streams are of interest, there is no Westerlund, et al. Expires December 18, 2020 [Page 39] Internet-Draft Guidelines for Multiplexing in RTP June 2020 way of telling which missing packet(s) belong to the interesting stream(s) and all lost packets need be requested, wasting bandwidth. 6. The current RTCP feedback mechanisms are built around providing feedback on RTP streams based on stream ID (SSRC), packet (sequence numbers) and time interval (RTP timestamps). There is almost never a field to indicate which payload type is reported, so sending feedback for a specific RTP payload type is difficult without extending existing RTCP reporting. 7. The current RTCP media control messages [RFC5104] specification is oriented around controlling particular media flows, i.e. requests are done addressing a particular SSRC. Such mechanisms would need to be redefined to support payload type multiplexing. 8. The number of payload types are inherently limited. Accordingly, using payload type multiplexing limits the number of streams that can be multiplexed and does not scale. This limitation is exacerbated if one uses solutions like RTP and RTCP multiplexing [RFC5761] where a number of payload types are blocked due to the overlap between RTP and RTCP. 9. At times, there is a need to group multiplexed streams and this is currently possible for RTP sessions and for SSRC, but there is no defined way to group payload types. 10. It is currently not possible to signal bandwidth requirements per RTP stream when using payload type multiplexing. 11. Most existing SDP media level attributes cannot be applied on a per payload type level and would require re-definition in that context. 12. A legacy endpoint that does not understand the indication that different RTP payload types are different RTP streams might be slightly confused by the large amount of possibly overlapping or identically defined RTP payload types. Appendix B. Signalling Considerations Signalling is not an architectural consideration for RTP itself, so this discussion has been moved to an appendix. However, it is extremely important for anyone building complete applications, so it is deserving of discussion. We document salient issues here that need to be addressed by the WGs that use some form of signaling to establish RTP sessions. These Westerlund, et al. Expires December 18, 2020 [Page 40] Internet-Draft Guidelines for Multiplexing in RTP June 2020 issues cannot simply be addressed by tweaking, extending, or profiling RTP, but require a dedicated and indepth look at the signaling primitives that set up the RTP sessions. There exist various signalling solutions for establishing RTP sessions. Many are SDP [RFC4566] based, however SDP functionality is also dependent on the signalling protocols carrying the SDP. RTSP [RFC7826] and SAP [RFC2974] both use SDP in a declarative fashion, while SIP [RFC3261] uses SDP with the additional definition of Offer/ Answer [RFC3264]. The impact on signalling and especially SDP needs to be considered as it can greatly affect how to deploy a certain multiplexing point choice. B.1. Session Oriented Properties One aspect of the existing signalling is that it is focused on RTP sessions, or in the case of SDP, the media description concept. There are a number of things that are signalled on media description level but those are not necessarily strictly bound to an RTP session and could be of interest to signal specifically for a particular RTP stream (SSRC) within the session. The following properties have been identified as being potentially useful to signal not only on RTP session level: o Bitrate/Bandwidth exist today only at aggregate or as a common "any RTP stream" limit, unless either codec-specific bandwidth limiting or RTCP signalling using TMMBR [RFC5104] is used. o Which SSRC that will use which RTP payload type (this will be visible from the first media packet, but is sometimes useful to know before packet arrival). Some of these issues are clearly SDP's problem rather than RTP limitations. However, if the aim is to deploy an solution using additional SSRCs that contains several sets of RTP streams with different properties (encoding/packetization parameter, bit-rate, etc.), putting each set in a different RTP session would directly enable negotiation of the parameters for each set. If insisting on additional SSRC only, a number of signalling extensions are needed to clarify that there are multiple sets of RTP streams with different properties and that they need in fact be kept different, since a single set will not satisfy the application's requirements. For some parameters, such as RTP payload type, resolution and framerate, a SSRC-linked mechanism has been proposed in [I-D.ietf-mmusic-rid] Westerlund, et al. Expires December 18, 2020 [Page 41] Internet-Draft Guidelines for Multiplexing in RTP June 2020 B.2. SDP Prevents Multiple Media Types SDP chose to use the m= line both to delineate an RTP session and to specify the top level of the MIME media type; audio, video, text, image, application. This media type is used as the top-level media type for identifying the actual payload format and is bound to a particular payload type using the rtpmap attribute. This binding has to be loosened in order to use SDP to describe RTP sessions containing multiple MIME top level types. [I-D.ietf-mmusic-sdp-bundle-negotiation] describes how to let multiple SDP media descriptions use a single underlying transport in SDP, which allows to define one RTP session with media types having different MIME top level types. B.3. Signalling RTP Stream Usage RTP streams being transported in RTP have some particular usage in an RTP application. This usage of the RTP stream is in many applications so far implicitly signalled. For example, an application might choose to take all incoming audio RTP streams, mix them and play them out. However, in more advanced applications that use multiple RTP streams there will be more than a single usage or purpose among the set of RTP streams being sent or received. RTP applications will need to signal this usage somehow. The signalling used will have to identify the RTP streams affected by their RTP- level identifiers, which means that they have to be identified either by their session or by their SSRC + session. In some applications, the receiver cannot utilise the RTP stream at all before it has received the signalling message describing the RTP stream and its usage. In other applications, there exists a default handling that is appropriate. If all RTP streams in an RTP session are to be treated in the same way, identifying the session is enough. If SSRCs in a session are to be treated differently, signalling needs to identify both the session and the SSRC. If this signalling affects how any RTP central node, like an RTP mixer or translator that selects, mixes or processes streams, treats the streams, the node will also need to receive the same signalling to know how to treat RTP streams with different usage in the right fashion. Westerlund, et al. Expires December 18, 2020 [Page 42] Internet-Draft Guidelines for Multiplexing in RTP June 2020 Authors' Addresses Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Kista Sweden Email: bo.burman@ericsson.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Harald Tveit Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Roni Even Email: ron.even.tlv@gmail.com Westerlund, et al. Expires December 18, 2020 [Page 43] ./index.html0000644000764400076440000016605213761035604012363 0ustar iustyiusty » RFC Editor

The RFC series

contains technical and organizational documents about the Internet, including the specifications and policy documents produced by four streams: the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), and Independent Submissions.

Browse the RFC Index

HTML (ascending) • HTML (descending) • TXT • XML
Note: These files are large.

Browse RFCs by Status

Internet Standard

Draft Standard • Proposed Standard

Best Current Practice

Informational • Experimental • Historic

Uncategorized (Early RFCs)

• • • • •

Official Internet Protocol Standards

RFC Status Changes


./queue.html0000644000764400076440000023452713761035603012402 0ustar iustyiusty Current Queue » RFC Editor

Publication Queue

[About this page]  [Summary statistics]  [List of all active clusters]

Found 141 records

Current stateWeeks in stateWeeks in queueDraft name (Authors) ClusterPagesSubmitted
EDIT*R
4.0153.7draft-ietf-anima-prefix-management-07
S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun
C325222017-12-19
EDIT*R
4.0105.1draft-ietf-anima-reference-model-10
M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre
C325302018-11-24
EDIT*R
1.633.4draft-ietf-anima-bootstrapping-keyinfra-45
M. Pritikin, M. Richardson, T.T.E. Eckert, M.H. Behringer, K.W. Watsen
C3251222020-04-09
EDIT*R
0.727.4draft-ietf-idr-rfc5575bis-27
C. Loibl, S. Hares, R. Raszuk, D. McPherson, M. Bacher
C349392020-05-21
EDIT*R
2.93.9draft-ietf-anima-autonomic-control-plane-30
T. Eckert, Ed., M. Behringer, Ed., S. Bjarnason
C3251802020-11-02
EDIT
3.02.9draft-huitema-rfc-eval-project-07
C. Huitema
502020-11-09
EDIT
1.62.0draft-ietf-ippm-stamp-option-tlv-10
G. Mirsky, X. Min, H. Nydell, R. Foote, A. Masputra, E. Ruffini
322020-11-15
EDIT
1.41.9draft-ietf-dots-server-discovery-15
M. Boucadair, T. Reddy.K
262020-11-16
EDIT*A
1.71.6draft-ietf-extra-imap-fetch-preview-10
M. Slusarz
132020-11-18
EDIT*R
1.61.6draft-ietf-avtcore-cc-feedback-message-09
Z. Sarker, C. Perkins, V. Singh, M. Ramalho
C238162020-11-18
EDIT
1.41.4draft-ietf-dnsop-dns-zone-digest-14
D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker
392020-11-19
EDIT
1.61.4draft-ietf-core-stateless-08
K. Hartke, M. Richardson
C310222020-11-19
EDIT*A
1.61.4draft-ietf-calext-jscalendar-32
N. Jenkins, R. Stepanek
852020-11-19
EDIT*A*R
0.70.6draft-ietf-idr-flow-spec-v6-21
C. Loibl, Ed., R. Raszuk, Ed., S. Hares, Ed.
C349192020-11-25
RFC-EDITOR
1.94.9draft-ietf-opsawg-model-automation-framework-10
Q. Wu, Ed., M. Boucadair, Ed., D. Lopez, C. Xie, L. Geng
472020-10-26
RFC-EDITOR*R
1.94.7draft-ietf-detnet-mpls-13
B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant, J. Korhonen
C415322020-10-27
RFC-EDITOR
2.14.4draft-ietf-bfd-vxlan-16
S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda
112020-10-29
AUTH
124.9136.4draft-ribose-asciirfc-08
R. Tse, N. Nicholas, J. Lau, P. Brasolin
1712018-04-19
AUTH48*R
3.7307.4draft-ietf-rtcweb-data-channel-13
R. Jesup, S. Loreto, M. Tuexen
C238162015-01-08
AUTH48*R
3.7307.4draft-ietf-rtcweb-data-protocol-09
R. Jesup, S. Loreto, M. Tuexen
C238132015-01-08
AUTH48*R
30.0261.9draft-ietf-bfcpbis-rfc4582bis-16
G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel
C238902015-11-23
AUTH48*R
3.7237.4draft-ietf-rtcweb-alpn-04
M. Thomson
C23872016-05-12
AUTH48*R
3.7213.4draft-ietf-rtcweb-transports-17
H. Alvestrand
C238202016-10-27
AUTH48*R
3.7159.0draft-ietf-rtcweb-overview-19
H. Alvestrand
C238242017-11-12
AUTH48*R
21.0143.4draft-ietf-rtcweb-jsep-26
J. Uberti, C. Jennings, E. Rescorla, Ed.
C2381152018-03-01
AUTH48*R
9.0124.6draft-ietf-ippm-twamp-yang-13
R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed.
C365682018-07-11
AUTH48*R
18.779.7draft-ietf-mmusic-data-channel-sdpneg-28
K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed.
C238402019-05-21
AUTH48*R
22.072.3draft-ietf-rtcweb-security-12
E. Rescorla
C238262019-07-12
AUTH48*R
22.070.9draft-ietf-rtcweb-security-arch-20
E. Rescorla
C238432019-07-22
AUTH48*R
27.467.7draft-ietf-mmusic-sdp-uks-07
M. Thomson, E. Rescorla
C238192019-08-13
AUTH48
17.037.7draft-ietf-stir-oob-07
E. Rescorla, J. Peterson
282020-03-10
AUTH48*R
10.037.3draft-ietf-ippm-initial-registry-16
A. Morton, M. Bagnulo, P. Eardley, K. D'Souza
C365782020-03-13
AUTH48
10.037.3draft-ietf-ippm-metric-registry-24
M. Bagnulo, B. Claise, P. Eardley, A. Morton, A. Akhter
C365382020-03-13
AUTH48
16.636.7draft-ietf-netmod-module-tags-10
C. Hopps, L. Berger, D. Bogdanovic
182020-03-17
AUTH48
11.922.7draft-ietf-perc-srtp-ekt-diet-13
C. Jennings, J. Mattsson, D. McGrew, D. Wing, F. Andreasen
C391252020-06-23
AUTH48
7.021.9draft-ietf-secevent-http-push-14
A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin
C412242020-06-29
AUTH48*R
7.021.9draft-ietf-secevent-http-poll-12
A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin
C412222020-06-29
AUTH48*R
7.020.3draft-ietf-httpbis-client-hints-15
I. Grigorik, Y. Weiss
C414142020-07-10
AUTH48
7.020.3draft-ietf-httpbis-header-structure-19
M. Nottingham, P. Kamp
C414422020-07-10
AUTH48
11.319.9draft-ietf-dots-use-cases-25
R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka
152020-07-13
AUTH48
5.018.3draft-ietf-stir-passport-divert-09
J. Peterson
192020-07-24
AUTH48*R
1.012.4draft-ietf-babel-applicability-10
J. Chroboczek
C368112020-09-03
AUTH48*R
1.012.4draft-ietf-babel-dtls-10
A. Décimo, D. Schinazi, J. Chroboczek
C368102020-09-03
AUTH48*R
1.012.4draft-ietf-babel-rfc6126bis-20
J. Chroboczek, D. Schinazi
C368702020-09-03
AUTH48*R
1.011.7draft-ietf-babel-hmac-12
C. Do, W. Kolodziejak, J. Chroboczek
C368222020-09-08
AUTH48
3.69.4draft-ietf-capport-architecture-10
K. Larose, D. Dolson, H. Liu
C422242020-09-24
AUTH48
3.98.6draft-ietf-cbor-7049bis-16
C. Bormann, P. Hoffman
802020-09-30
AUTH48
2.46.7draft-moriarty-caris2-04
K. Moriarty
172020-10-13
AUTH48
1.66.4draft-hardie-dispatch-rfc3405-update-04
T. Hardie
32020-10-15
AUTH48
1.95.6draft-nottingham-how-did-that-get-into-the-repo-02
M. Nottingham
62020-10-21
AUTH48
1.44.9draft-ietf-mpls-base-yang-17
T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram
C336302020-10-26
AUTH48
2.04.6draft-ietf-mpls-sfl-framework-11
S. Bryant, M. Chen, G. Swallow, S. Sivabalan, G. Mirsky
102020-10-28
AUTH48-DONE*R
3.0311.3draft-ietf-rmcat-cc-requirements-09
R. Jesup, Z. Sarker, Ed.
C238122014-12-12
AUTH48-DONE*R
0.9282.6draft-ietf-rtcweb-rtp-usage-26
C. Perkins, M. Westerlund, J. Ott
C238452015-07-01
AUTH48-DONE*R
8.9256.9draft-ietf-avtcore-multi-media-rtp-session-13
M. Westerlund, C. Perkins, J. Lennox
C238162015-12-28
AUTH48-DONE*R
19.4254.4draft-ietf-clue-framework-25
M. Duckworth, Ed., A. Pepperell, S. Wenger
C238842016-01-14
AUTH48-DONE*R
9.7246.6draft-ietf-avtcore-rtp-multi-stream-optimisation-12
J. Lennox, M. Westerlund, Q. Wu, C. Perkins
C238182016-03-09
AUTH48-DONE*R
10.7228.7draft-ietf-mmusic-msid-17
H. Alvestrand
C238182016-07-12
AUTH48-DONE*R
28.0224.7draft-ietf-mmusic-mux-exclusive-12
C. Holmberg
C238122016-08-09
AUTH48-DONE*R
19.6223.9draft-ietf-clue-data-model-schema-17
R. Presta, S. Pietro Romano
C238772016-08-15
AUTH48-DONE*R
18.4222.9draft-ietf-tsvwg-rtcweb-qos-18
P. Jones, S. Dhesikan, C. Jennings, D. Druta
C238112016-08-22
AUTH48-DONE*R
16.0214.6draft-ietf-avtext-rid-09
A.B. Roach, S. Nandakumar, P. Thatcher
C23892016-10-19
AUTH48-DONE*R
9.9205.7draft-ietf-mmusic-sdp-mux-attributes-19
S. Nandakumar
C238962016-12-20
AUTH48-DONE*R
28.6197.9draft-ietf-bfcpbis-bfcp-websocket-15
V. Pascual, A. Roman, S. Cazeaux, G. Salgueiro, R. Ravindranath
C238142017-02-13
AUTH48-DONE*R
2.0195.9draft-ietf-clue-rtp-mapping-14
R. Even, J. Lennox
C238142017-02-27
AUTH48-DONE*R
7.6192.9draft-ietf-mmusic-sctp-sdp-26
C. Holmberg, R. Shpount, S. Loreto, G. Camarillo
C238262017-03-20
AUTH48-DONE*R
28.7160.4draft-ietf-mmusic-dtls-sdp-32
C. Holmberg, R. Shpount
C238272017-11-02
AUTH48-DONE*R
26.6132.6draft-ietf-mmusic-rid-15
A.B. Roach, Ed.
C238282018-05-16
AUTH48-DONE
26.0131.7draft-ietf-ice-trickle-21
E. Ivov, J. Uberti, P. Saint-Andre
C238332018-05-22
AUTH48-DONE*R
28.0127.9draft-ietf-mmusic-sdp-bundle-negotiation-54
C. Holmberg, H. Alvestrand, C. Jennings
C238692018-06-18
AUTH48-DONE*R
20.0125.9draft-ietf-mmusic-trickle-ice-sip-18
E. Ivov, T. Stach, E. Marocco, C. Holmberg
C238472018-07-02
AUTH48-DONE*R
27.4124.7draft-ietf-mmusic-sdp-simulcast-14
B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty
C238412018-07-10
AUTH48-DONE*R
24.4101.3draft-ietf-bfcpbis-rfc4583bis-27
G. Camarillo, T. Kristensen, C. Holmberg
C238252018-12-21
AUTH48-DONE*R
22.684.6draft-ietf-clue-datachannel-18
C. Holmberg
C238142019-04-17
AUTH48-DONE*R
7.680.7draft-ietf-sipbrandy-rtpsec-08
J. Peterson, R. Barnes, R. Housley
C238142019-05-14
AUTH48-DONE*R
18.678.4draft-ietf-rmcat-eval-test-10
Z. Sarker, V. Singh, X. Zhu, M. Ramalho
C238332019-05-30
AUTH48-DONE*R
4.376.7draft-ietf-perc-private-media-framework-12
P. Jones, D. Benham, C. Groves
C391282019-06-11
AUTH48-DONE*R
16.672.3draft-ietf-rtcweb-ip-handling-12
J. Uberti
C238122019-07-12
AUTH48-DONE
30.471.7draft-ietf-rtcweb-fec-10
J. Uberti
C238132019-07-16
AUTH48-DONE*R
25.967.6draft-ietf-mmusic-ice-sip-sdp-39
M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, R. Shpount
C238432019-08-14
AUTH48-DONE*R
4.766.7draft-ietf-mmusic-rfc4566bis-37
A. Begen, P. Kyzivat, C. Perkins, M. Handley
C238632019-08-20
AUTH48-DONE*R
11.950.6draft-ietf-clue-signaling-15
R. Hanton, P. Kyzivat, L. Xiao, C. Groves
C238432019-12-11
AUTH48-DONE*R
3.650.6draft-ietf-clue-protocol-19
R. Presta, S P. Romano
C238682019-12-11
AUTH48-DONE*R
9.048.9draft-ietf-tls-certificate-compression-10
A. Ghedini, V. Vasiliev
C40682019-12-23
AUTH48-DONE*R
18.037.3draft-ietf-rmcat-wireless-tests-11
Z. Sarker, X. Zhu, J. Fu
C238232020-03-13
AUTH48-DONE*R
13.635.6draft-ietf-rmcat-eval-criteria-14
V. Singh, J. Ott, S. Holmer
C238172020-03-25
AUTH48-DONE*R
10.933.3draft-ietf-mmusic-t140-usage-data-channel-14
C. Holmberg, G. Hellstrom
C238192020-04-10
AUTH48-DONE*R
18.430.9draft-ietf-ice-pac-06
C. Holmberg, J. Uberti
C23872020-04-27
AUTH48-DONE
1.024.4draft-ietf-detnet-data-plane-framework-06
B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant
C415262020-06-11
AUTH48-DONE*R
2.922.9draft-ietf-avtcore-multiplex-guidelines-12
M. Westerlund, B. Burman, C. Perkins, H. Alvestrand, R. Even
C391432020-06-22
AUTH48-DONE
0.720.3draft-ietf-dnsop-rfc2845bis-09
F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O. Gudmundsson, B. Wellington
292020-07-10
AUTH48-DONE*R
1.020.3draft-ietf-detnet-ip-07
B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant
C415252020-07-10
AUTH48-DONE*R
0.714.9draft-ietf-mmusic-msrp-usage-data-channel-24
JM. Recio, Ed., C. Holmberg
C238262020-08-17
AUTH48-DONE*R
0.912.3draft-ietf-dhc-mac-assign-09
B. Volz, T. Mrugalski, C. Bernardos
C424202020-09-04
AUTH48-DONE*R
1.76.7draft-ietf-dhc-slap-quadrant-12
CJ. Bernardos, A. Mourad
C424182020-10-13
MISSREF*R(1G)
292.4292.4draft-ietf-lisp-introduction-13
A. Cabellos-Aparicio, D. Saucez, Ed.
C251272015-04-23
MISSREF*R(1G)
255.9255.9draft-ietf-lwig-cellular-06
J. Arkko, A. Eriksson, A. Keränen
C280162016-01-04
MISSREF*R(1G)
176.9177.3draft-ietf-avtext-lrr-07
J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman
C324152017-07-07
MISSREF*R(1G)
161.6161.7draft-ietf-ospf-encapsulation-cap-09
X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil
C349112017-10-24
MISSREF*R(1G)
143.0142.9draft-ietf-bess-dci-evpn-overlay-10
J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake
C349292018-03-05
MISSREF*R(1G)
141.7141.9draft-ietf-trill-ecn-support-07
D. Eastlake 3rd, B. Briscoe
C350202018-03-12
MISSREF*R(1G)
140.9141.3draft-ietf-netmod-syslog-model-26
C. Wildes, Ed., K. Koushik, Ed.
C336312018-03-16
MISSREF*R(1G)
130.9131.4draft-ietf-bess-evpn-prefix-advertisement-11
J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi
C355362018-05-24
MISSREF*R(1G)
120.4120.9draft-ietf-bfd-yang-17
R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky
C336792018-08-06
MISSREF*R(1G)
115.9115.9draft-ietf-homenet-babel-profile-07
J. Chroboczek
C36892018-09-10
MISSREF*R(1G)
100.0101.3draft-ietf-httpbis-expect-ct-08
E. Stark
C377232018-12-21
MISSREF*R(1G)
96.095.9draft-ietf-lisp-rfc8113bis-03
M. Boucadair, C. Jacquenet
C38162019-01-28
MISSREF*R(1G)
88.088.1draft-ietf-hip-rfc4423-bis-20
R. Moskowitz, Ed., M. Komu
C386502019-03-23
MISSREF*R(1G)
72.773.4draft-ietf-idr-bgp-ls-segment-routing-ext-16
S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen
C340312019-07-04
MISSREF*R(1G)
56.672.4draft-ietf-roll-efficient-npdao-18
R. Jadhav, Ed., P. Thubert, R. Sahoo, Z. Cao
C310232019-07-11
MISSREF*R(1G)
56.656.6draft-ietf-6tisch-architecture-29
P. Thubert
C310692019-10-30
MISSREF*R(1G)
50.049.9draft-ietf-i2nsf-applicability-18
J. Jeong, S. Hyun, T. Ahn, S. Hares, D. Lopez
C405292019-12-16
MISSREF*R(1G)
44.645.4draft-ietf-ace-coap-est-18
P. van der Stok, P. Kampanakis, M. Richardson, S. Raza
C321512020-01-16
MISSREF*R(1G)
35.635.9draft-ietf-mpls-ldp-yang-09
K. Raza, Ed., R. Asati, X. Liu, S. Esale, X. Chen, H. Shah
C410932020-03-23
MISSREF*R(1G)
35.935.7draft-ietf-uta-tls-for-email-05
L. Velvindron, S. Farrell
C41162020-03-24
MISSREF*R(1G)
8.621.9draft-ietf-dots-signal-filter-control-07
K. Nishizuka, M. Boucadair, T. Reddy, T. Nagata
C423262020-06-29
MISSREF*A*R(1G)
17.617.4draft-ietf-cose-rfc8152bis-algs-12
J. Schaad
C416552020-07-30
MISSREF*R(1G)
14.715.7draft-ietf-lisp-gpe-19
F. Maino, Ed., J. Lemon, P. Agarwal, D. Lewis, M. Smith
C417162020-08-11
MISSREF*R(1G)
14.614.4draft-ietf-ippm-route-10
J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib
C418272020-08-20
MISSREF*R(1G)
12.913.7draft-ietf-pim-igmp-mld-snooping-yang-18
H. Zhao, X. Liu, Y. Liu, M. Sivakumar, A. Peter
C419472020-08-25
MISSREF*R(1G)
11.913.4draft-ietf-bess-nsh-bgp-control-plane-18
A. Farrel, J. Drake, E. Rosen, J. Uttaro, L. Jalil
C349712020-08-27
MISSREF*A*R(1G)
11.010.9draft-ietf-cose-hash-algs-09
J. Schaad
C416122020-09-14
MISSREF*R(1G)
4.94.7draft-ietf-detnet-ip-over-mpls-09
B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen
C415132020-10-27
MISSREF*R(1G)
2.73.9draft-ietf-pce-pcep-flowspec-12
D. Dhody, A. Farrel, Z. Li
C349372020-11-02
MISSREF*R(1G)
3.03.7draft-ietf-nfsv4-rpc-tls-11
T. Myklebust, C. Lever, Ed.
C321262020-11-03
MISSREF*R(2G)
120.6132.6draft-ietf-pim-yang-17
X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu
C3361072018-05-16
MISSREF*R(2G)
73.679.9draft-ietf-idr-bgpls-segment-routing-epe-19
S. Previdi, K. Talaulikar, C. Filsfils, K. Patel, S. Ray, J. Dong
C340182019-05-20
MISSREF*R(2G)
65.465.9draft-ietf-ospf-yang-29
D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem
C3361322019-08-26
MISSREF*R(2G)
56.659.4draft-ietf-6lo-deadline-time-05
L. Thomas, S. Anamalamudi, S. Anand, M. Hegde, C. Perkins
C310212019-10-10
MISSREF*R(2G)
57.958.4draft-ietf-isis-yang-isis-cfg-42
S. Litkowski, D. Yeung, A. Lindem, J. Zhang, L. Lhotka
C3361182019-10-17
MISSREF*R(2G)
1.650.6draft-ietf-6tisch-minimal-security-15
M. Vucinic, Ed., J. Simon, K. Pister, M. Richardson
C310532019-12-11
MISSREF*R(2G)
25.025.9draft-ietf-isis-mpls-elc-13
X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci
C34082020-06-01
MISSREF*R(2G)
25.025.9draft-ietf-ospf-mpls-elc-15
X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci
C34092020-06-01
MISSREF*R(2G)
2.116.7draft-ietf-hip-native-nat-traversal-33
A. Keränen, J. Melen, M. Komu, Ed.
C386672020-08-04
MISSREF*R(2G)
10.610.9draft-ietf-6tisch-msf-18
T. Chang, Ed., M. Vucinic, X. Vilajosana, S. Duquennoy, D. Dujovne
C310222020-09-14
MISSREF*R(3G)
73.6153.4draft-ietf-spring-segment-routing-central-epe-10
C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev
C340192017-12-21
MISSREF*R(3G)
1.636.6draft-ietf-6tisch-enrollment-enhanced-beacon-14
D. Dujovne, M. Richardson
C310112020-03-18
REF*R
2.6175.6draft-ietf-anima-grasp-15
C. Bormann, B. Carpenter, Ed., B. Liu, Ed.
C325812017-07-19
IESG
7.631.4draft-kucherawy-rfc8478bis-05
Y. Collet, M. Kucherawy, Ed.
C406532020-04-23
IESG*A
11.614.3draft-ietf-oauth-jwsreq-30
N. Sakimura, J. Bradley, M. Jones
352020-08-21


./rfc-index.txt0000644000764400076440000657622613760650771013033 0ustar iustyiusty ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX ------------- (CREATED ON: 11/29/2020.) This file contains citations for all RFCs in numeric order. RFC citations appear in this format: #### Title of RFC. Author 1, Author 2, Author 3. Issue date. (Format: ASCII) (Obsoletes xxx) (Obsoleted by xxx) (Updates xxx) (Updated by xxx) (Also FYI ####) (Status: ssssss) (DOI: ddd) or #### Not Issued. For example: 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (Also RFC1119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1129) Key to citations: #### is the RFC number. Following the RFC number are the title, the author(s), and the publication date of the RFC. Each of these is terminated by a period. Following the number are the title (terminated with a period), the author, or list of authors (terminated with a period), and the date (terminated with a period). The format follows in parentheses. One or more of the following formats are listed: text (TXT), PostScript (PS), Portable Document Format (PDF), HTML, XML. Obsoletes xxxx refers to other RFCs that this one replaces; Obsoleted by xxxx refers to RFCs that have replaced this one. Updates xxxx refers to other RFCs that this one merely updates but does not replace); Updated by xxxx refers to RFCs that have updated (but not replaced) this one. Generally, only immediately succeeding and/or preceding RFCs are indicated, not the entire history of each related earlier or later RFC in a related series. The (Also FYI ##) or (Also STD ##) or (Also BCP ##) phrase gives the equivalent FYI, STD, or BCP number if the RFC is also in those document sub-series. The Status field gives the document's current status (see RFC 2026). The (DOI ddd) field gives the Digital Object Identifier. RFCs may be obtained in a number of ways, using HTTP, FTP, or email. See the RFC Editor Web page http://www.rfc-editor.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RFC INDEX --------- 0001 Host Software. S. Crocker. April 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0001) 0002 Host software. B. Duvall. April 1969. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0002) 0003 Documentation conventions. S.D. Crocker. April 1969. (Format: TXT, HTML) (Obsoleted by RFC0010) (Status: UNKNOWN) (DOI: 10.17487/RFC0003) 0004 Network timetable. E.B. Shapiro. March 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0004) 0005 Decode Encode Language (DEL). J. Rulifson. June 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0005) 0006 Conversation with Bob Kahn. S.D. Crocker. April 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0006) 0007 Host-IMP interface. G. Deloche. May 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0007) 0008 ARPA Network Functional Specifications. G. Deloche. May 1969. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0008) 0009 Host Software. G. Deloche. May 1969. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0009) 0010 Documentation conventions. S.D. Crocker. July 1969. (Format: TXT, HTML) (Obsoletes RFC0003) (Obsoleted by RFC0016) (Updated by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0010) 0011 Implementation of the Host - Host Software Procedures in GORDO. G. Deloche. August 1969. (Format: TXT, PDF, HTML) (Obsoleted by RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0011) 0012 IMP-Host interface flow diagrams. M. Wingfield. August 1969. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0012) 0013 Zero Text Length EOF Message. V. Cerf. August 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0013) 0014 Not Issued. 0015 Network subsystem for time sharing hosts. C.S. Carr. September 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0015) 0016 M.I.T. S. Crocker. August 1969. (Format: TXT, HTML) (Obsoletes RFC0010) (Obsoleted by RFC0024) (Updated by RFC0024, RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0016) 0017 Some questions re: Host-IMP Protocol. J.E. Kreznar. August 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0017) 0018 IMP-IMP and HOST-HOST Control Links. V. Cerf. September 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0018) 0019 Two protocol suggestions to reduce congestion at swap bound nodes. J.E. Kreznar. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0019) 0020 ASCII format for network interchange. V.G. Cerf. October 1969. (Format: TXT, PDF, HTML) (Also STD0080) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0020) 0021 Network meeting. V.G. Cerf. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0021) 0022 Host-host control message formats. V.G. Cerf. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0022) 0023 Transmission of Multiple Control Messages. G. Gregg. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0023) 0024 Documentation Conventions. S.D. Crocker. November 1969. (Format: TXT, HTML) (Obsoletes RFC0016) (Updates RFC0010, RFC0016) (Updated by RFC0027, RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0024) 0025 No High Link Numbers. S.D. Crocker. October 1969. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0025) 0026 Not Issued. 0027 Documentation Conventions. S.D. Crocker. December 1969. (Format: TXT, HTML) (Updates RFC0010, RFC0016, RFC0024) (Updated by RFC0030) (Status: UNKNOWN) (DOI: 10.17487/RFC0027) 0028 Time Standards. W.K. English. January 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0028) 0029 Response to RFC 28. R.E. Kahn. January 1970. (Format: TXT, HTML) (Also RFC0028) (Status: UNKNOWN) (DOI: 10.17487/RFC0029) 0030 Documentation Conventions. S.D. Crocker. February 1970. (Format: TXT, HTML) (Updates RFC0010, RFC0016, RFC0024, RFC0027) (Status: UNKNOWN) (DOI: 10.17487/RFC0030) 0031 Binary Message Forms in Computer. D. Bobrow, W.R. Sutherland. February 1968. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0031) 0032 Some Thoughts on SRI's Proposed Real Time Clock. J. Cole. February 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0032) 0033 New Host-Host Protocol. S.D. Crocker. February 1970. (Format: TXT, HTML) (Obsoletes RFC0011) (Updated by RFC0036, RFC0047) (Status: UNKNOWN) (DOI: 10.17487/RFC0033) 0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock. W.K. English. February 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0034) 0035 Network Meeting. S.D. Crocker. March 1970. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0035) 0036 Protocol Notes. S.D. Crocker. March 1970. (Format: TXT, HTML) (Updates RFC0033) (Updated by RFC0039, RFC0044) (Status: UNKNOWN) (DOI: 10.17487/RFC0036) 0037 Network Meeting Epilogue, etc. S.D. Crocker. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0037) 0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0038) 0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner. March 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0039) 0040 More Comments on the Forthcoming Protocol. E. Harslem, J.F. Heafner. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0040) 0041 IMP-IMP Teletype Communication. J.T. Melvin. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0041) 0042 Message Data Types. E. Ancona. March 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0042) 0043 Proposed Meeting. A.G. Nemeth. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0043) 0044 Comments on NWG/RFC 33 and 36. A. Shoshani, R. Long, A. Landsberg. April 1970. (Format: TXT, HTML) (Updates RFC0036) (Status: UNKNOWN) (DOI: 10.17487/RFC0044) 0045 New Protocol is Coming. J. Postel, S.D. Crocker. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0045) 0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0046) 0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970. (Format: TXT, HTML) (Updates RFC0033) (Status: UNKNOWN) (DOI: 10.17487/RFC0047) 0048 Possible protocol plateau. J. Postel, S.D. Crocker. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0048) 0049 Conversations with S. Crocker (UCLA). E. Meyer. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0049) 0050 Comments on the Meyer Proposal. E. Harslen, J. Heafner. April 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0050) 0051 Proposal for a Network Interchange Language. M. Elie. May 1970. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0051) 0052 Updated distribution list. J. Postel, S.D. Crocker. July 1970. (Format: TXT, HTML) (Updated by RFC0069) (Status: UNKNOWN) (DOI: 10.17487/RFC0052) 0053 Official protocol mechanism. S.D. Crocker. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0053) 0054 Official Protocol Proffering. S.D. Crocker, J. Postel, J. Newkirk, M. Kraley. June 1970. (Format: TXT, HTML) (Updated by RFC0057) (Status: UNKNOWN) (DOI: 10.17487/RFC0054) 0055 Prototypical implementation of the NCP. J. Newkirk, M. Kraley, J. Postel, S.D. Crocker. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0055) 0056 Third Level Protocol: Logger Protocol. E. Belove, D. Black, R. Flegal, L.G. Farquar. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0056) 0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. June 1970. (Format: TXT, HTML) (Updates RFC0054) (Status: UNKNOWN) (DOI: 10.17487/RFC0057) 0058 Logical Message Synchronization. T.P. Skinner. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0058) 0059 Flow Control - Fixed Versus Demand Allocation. E. Meyer. June 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0059) 0060 A Simplified NCP Protocol. R. Kalin. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0060) 0061 Note on Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. July 1970. (Format: TXT, HTML) (Obsoleted by RFC0062) (Status: UNKNOWN) (DOI: 10.17487/RFC0061) 0062 Systems for Interprocess Communication in a Resource Sharing Computer Network. D.C. Walden. August 1970. (Format: TXT, HTML) (Obsoletes RFC0061) (Status: UNKNOWN) (DOI: 10.17487/RFC0062) 0063 Belated Network Meeting Report. V.G. Cerf. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0063) 0064 Getting rid of marking. M. Elie. July 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0064) 0065 Comments on Host/Host Protocol document #1. D.C. Walden. August 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0065) 0066 NIC - third level ideas and other noise. S.D. Crocker. August 1970. (Format: TXT, HTML) (Obsoleted by RFC0123) (Updated by RFC0080, RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0066) 0067 Proposed Change to Host/IMP Spec to Eliminate Marking. W.R. Crowther. January 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0067) 0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM. M. Elie. August 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0068) 0069 Distribution List Change for MIT. A.K. Bhushan. September 1970. (Format: TXT, HTML) (Updates RFC0052) (Status: UNKNOWN) (DOI: 10.17487/RFC0069) 0070 Note on Padding. S.D. Crocker. October 1970. (Format: TXT, HTML) (Updated by RFC0228) (Status: UNKNOWN) (DOI: 10.17487/RFC0070) 0071 Reallocation in Case of Input Error. T. Schipper. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0071) 0072 Proposed Moratorium on Changes to Network Protocol. R.D. Bressler. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0072) 0073 Response to NWG/RFC 67. S.D. Crocker. September 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0073) 0074 Specifications for Network Use of the UCSB On-Line System. J.E. White. October 1970. (Format: TXT, PDF, HTML) (Updated by RFC0217, RFC0225) (Status: UNKNOWN) (DOI: 10.17487/RFC0074) 0075 Network Meeting. S.D. Crocker. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0075) 0076 Connection by name: User oriented protocol. J. Bouknight, J. Madden, G.R. Grossman. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0076) 0077 Network meeting report. J. Postel. November 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0077) 0078 NCP Status Report: UCSB/Rand. E. Harslem, J.F. Heafner, J.E. White. October 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0078) 0079 Logger Protocol error. E. Meyer. November 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0079) 0080 Protocols and Data Formats. E. Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (Obsoleted by RFC0123) (Updates RFC0066) (Updated by RFC0093) (Status: UNKNOWN) (DOI: 10.17487/RFC0080) 0081 Request for Reference Information. J. Bouknight. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0081) 0082 Network Meeting Notes. E. Meyer. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0082) 0083 Language-machine for data reconfiguration. R.H. Anderson, E. Harslem, J.F. Heafner. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0083) 0084 List of NWG/RFC's 1-80. J.B. North. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0084) 0085 Network Working Group meeting. S.D. Crocker. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0085) 0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display. S.D. Crocker. January 1971. (Format: TXT, HTML) (Updated by RFC0125) (Status: UNKNOWN) (DOI: 10.17487/RFC0086) 0087 Topic for Discussion at the Next Network Working Group Meeting. A. Vezza. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0087) 0088 NETRJS: A third level protocol for Remote Job Entry. R.T. Braden, S.M. Wolfe. January 1971. (Format: TXT, HTML) (Obsoleted by RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0088) 0089 Some historic moments in networking. R.M. Metcalfe. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0089) 0090 CCN as a Network Service Center. R.T. Braden. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0090) 0091 Proposed User-User Protocol. G.H. Mealy. December 1970. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0091) 0092 Not Issued. 0093 Initial Connection Protocol. A.M. McKenzie. January 1971. (Format: TXT, HTML) (Updates RFC0066, RFC0080) (Status: UNKNOWN) (DOI: 10.17487/RFC0093) 0094 Some thoughts on Network Graphics. E. Harslem, J.F. Heafner. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0094) 0095 Distribution of NWG/RFC's through the NIC. S. Crocker. February 1971. (Format: TXT, HTML) (Obsoleted by RFC0155) (Status: UNKNOWN) (DOI: 10.17487/RFC0095) 0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center. R.W. Watson. February 1971. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0096) 0097 First Cut at a Proposed Telnet Protocol. J.T. Melvin, R.W. Watson. February 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0097) 0098 Logger Protocol Proposal. E. Meyer, T. Skinner. February 1971. (Format: TXT, HTML) (Updated by RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0098) 0099 Network Meeting. P.M. Karp. February 1971. (Format: TXT, HTML) (Updated by RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0099) 0100 Categorization and guide to NWG/RFCs. P.M. Karp. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0100) 0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971. R.W. Watson. February 1971. (Format: TXT, HTML) (Updated by RFC0108, RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0101) 0102 Output of the Host-Host Protocol glitch cleaning committee. S.D. Crocker. February 1971. (Format: TXT, HTML) (Updated by RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0102) 0103 Implementation of Interrupt Keys. R.B. Kalin. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0103) 0104 Link 191. J.B. Postel, S.D. Crocker. February 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0104) 0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB. J.E. White. March 1971. (Format: TXT, HTML) (Updated by RFC0217) (Status: UNKNOWN) (DOI: 10.17487/RFC0105) 0106 User/Server Site Protocol Network Host Questionnaire. T.C. O'Sullivan. March 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0106) 0107 Output of the Host-Host Protocol Glitch Cleaning Committee. R.D. Bressler, S.D. Crocker, W.R. Crowther, G.R. Grossman, R.S. Tomlinson, J.E. White. March 1971. (Format: TXT, HTML) (Updates RFC0102) (Updated by RFC0111, RFC0124, RFC0132, RFC0154, RFC0179) (Status: UNKNOWN) (DOI: 10.17487/RFC0107) 0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971. R.W. Watson. March 1971. (Format: TXT, HTML) (Updates RFC0101) (Status: UNKNOWN) (DOI: 10.17487/RFC0108) 0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host. J. Winett. March 1971. (Format: TXT, PDF, HTML) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0109) 0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts. J. Winett. March 1971. (Format: TXT, PDF, HTML) (Updated by RFC0135) (Status: UNKNOWN) (DOI: 10.17487/RFC0110) 0111 Pressure from the Chairman. S.D. Crocker. March 1971. (Format: TXT, HTML) (Updates RFC0107) (Updated by RFC0130) (Status: UNKNOWN) (DOI: 10.17487/RFC0111) 0112 User/Server Site Protocol: Network Host Questionnaire. T.C. O'Sullivan. April 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0112) 0113 Network activity report: UCSB Rand. E. Harslem, J.F. Heafner, J.E. White. April 1971. (Format: TXT, HTML) (Updated by RFC0227) (Status: UNKNOWN) (DOI: 10.17487/RFC0113) 0114 File Transfer Protocol. A.K. Bhushan. April 1971. (Format: TXT, HTML) (Updated by RFC0133, RFC0141, RFC0171, RFC0172) (Status: UNKNOWN) (DOI: 10.17487/RFC0114) 0115 Some Network Information Center policies on handling documents. R.W. Watson, J.B. North. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0115) 0116 Structure of the May NWG Meeting. S.D. Crocker. April 1971. (Format: TXT, HTML) (Updates RFC0099) (Updated by RFC0131, RFC0156) (Status: UNKNOWN) (DOI: 10.17487/RFC0116) 0117 Some comments on the official protocol. J. Wong. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0117) 0118 Recommendations for facility documentation. R.W. Watson. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0118) 0119 Network Fortran Subprograms. M. Krilanovich. April 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0119) 0120 Network PL1 subprograms. M. Krilanovich. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0120) 0121 Network on-line operators. M. Krilanovich. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0121) 0122 Network specifications for UCSB's Simple-Minded File System. J.E. White. April 1971. (Format: TXT, HTML) (Updated by RFC0217, RFC0269, RFC0399, RFC0431) (Status: UNKNOWN) (DOI: 10.17487/RFC0122) 0123 Proffered Official ICP. S.D. Crocker. April 1971. (Format: TXT, HTML) (Obsoletes RFC0066, RFC0080) (Obsoleted by RFC0165) (Updates RFC0098, RFC0101) (Updated by RFC0127, RFC0143, RFC0148) (Status: UNKNOWN) (DOI: 10.17487/RFC0123) 0124 Typographical error in RFC 107. J.T. Melvin. April 1971. (Format: TXT, HTML) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0124) 0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream. J. McConnell. April 1971. (Format: TXT, HTML) (Updates RFC0086) (Updated by RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0125) 0126 Graphics Facilities at Ames Research Center. J. McConnell. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0126) 0127 Comments on RFC 123. J. Postel. April 1971. (Format: TXT, HTML) (Obsoleted by RFC0145) (Updates RFC0123) (Updated by RFC0151) (Status: UNKNOWN) (DOI: 10.17487/RFC0127) 0128 Bytes. J. Postel. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0128) 0129 Request for comments on socket name structure. E. Harslem, J. Heafner, E. Meyer. April 1971. (Format: TXT, HTML) (Updated by RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0129) 0130 Response to RFC 111: Pressure from the chairman. J.F. Heafner. April 1971. (Format: TXT, HTML) (Updates RFC0111) (Status: UNKNOWN) (DOI: 10.17487/RFC0130) 0131 Response to RFC 116: May NWG meeting. E. Harslem, J.F. Heafner. April 1971. (Format: TXT, HTML) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0131) 0132 Typographical Error in RFC 107. J.E. White. April 1971. (Format: TXT, HTML) (Obsoleted by RFC0154) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0132) 0133 File Transfer and Error Recovery. R.L. Sunberg. April 1971. (Format: TXT, HTML) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0133) 0134 Network Graphics meeting. A. Vezza. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0134) 0135 Response to NWG/RFC 110. W. Hathaway. April 1971. (Format: TXT, HTML) (Updates RFC0110) (Status: UNKNOWN) (DOI: 10.17487/RFC0135) 0136 Host accounting and administrative procedures. R.E. Kahn. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0136) 0137 Telnet Protocol - a proposed document. T.C. O'Sullivan. April 1971. (Format: TXT, HTML) (Updated by RFC0139) (Status: UNKNOWN) (DOI: 10.17487/RFC0137) 0138 Status report on proposed Data Reconfiguration Service. R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0138) 0139 Discussion of Telnet Protocol. T.C. O'Sullivan. May 1971. (Format: TXT, HTML) (Updates RFC0137) (Updated by RFC0158) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0139) 0140 Agenda for the May NWG meeting. S.D. Crocker. May 1971. (Format: TXT, HTML) (Updated by RFC0149) (Status: UNKNOWN) (DOI: 10.17487/RFC0140) 0141 Comments on RFC 114: A File Transfer Protocol. E. Harslem, J.F. Heafner. April 1971. (Format: TXT, HTML) (Updates RFC0114) (Status: UNKNOWN) (DOI: 10.17487/RFC0141) 0142 Time-Out Mechanism in the Host-Host Protocol. C. Kline, J. Wong. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0142) 0143 Regarding proffered official ICP. W. Naylor, J. Wong, C. Kline, J. Postel. May 1971. (Format: TXT, HTML) (Obsoleted by RFC0165) (Updates RFC0123, RFC0145) (Status: UNKNOWN) (DOI: 10.17487/RFC0143) 0144 Data sharing on computer networks. A. Shoshani. April 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0144) 0145 Initial Connection Protocol Control Commands. J. Postel. May 1971. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC0127) (Obsoleted by RFC0165) (Updated by RFC0143) (Status: UNKNOWN) (DOI: 10.17487/RFC0145) 0146 Views on issues relevant to data sharing on computer networks. P.M. Karp, D.B. McKay, D.C.M. Wood. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0146) 0147 Definition of a socket. J.M. Winett. May 1971. (Format: TXT, HTML) (Updates RFC0129) (Status: UNKNOWN) (DOI: 10.17487/RFC0147) 0148 Comments on RFC 123. A.K. Bhushan. May 1971. (Format: TXT, HTML) (Updates RFC0123) (Status: UNKNOWN) (DOI: 10.17487/RFC0148) 0149 Best Laid Plans. S.D. Crocker. May 1971. (Format: TXT, HTML) (Updates RFC0140) (Status: UNKNOWN) (DOI: 10.17487/RFC0149) 0150 Use of IPC Facilities: A Working Paper. R.B. Kalin. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0150) 0151 Comments on a proffered official ICP: RFCs 123, 127. A. Shoshani. May 1971. (Format: TXT, HTML) (Updates RFC0127) (Status: UNKNOWN) (DOI: 10.17487/RFC0151) 0152 SRI Artificial Intelligence status report. M. Wilber. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0152) 0153 SRI ARC-NIC status. J.T. Melvin, R.W. Watson. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0153) 0154 Exposition Style. S.D. Crocker. May 1971. (Format: TXT, HTML) (Obsoletes RFC0132) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0154) 0155 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT, HTML) (Obsoletes RFC0095) (Obsoleted by RFC0168) (Status: UNKNOWN) (DOI: 10.17487/RFC0155) 0156 Status of the Illinois site: Response to RFC 116. J. Bouknight. April 1971. (Format: TXT, HTML) (Updates RFC0116) (Status: UNKNOWN) (DOI: 10.17487/RFC0156) 0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems. V.G. Cerf. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0157) 0158 Telnet Protocol: A Proposed Document. T.C. O'Sullivan. May 1971. (Format: TXT, PDF, HTML) (Obsoleted by RFC0495) (Updates RFC0139) (Updated by RFC0318) (Also RFC0393) (Status: UNKNOWN) (DOI: 10.17487/RFC0158) 0159 Not Issued. 0160 RFC brief list. Network Information Center. Stanford Research Institute. May 1971. (Format: TXT, HTML) (Obsoleted by RFC0200, RFC0999) (Updates NIC6716) (Status: UNKNOWN) (DOI: 10.17487/RFC0160) 0161 Solution to the race condition in the ICP. A. Shoshani. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0161) 0162 NETBUGGER3. M. Kampe. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0162) 0163 Data transfer protocols. V.G. Cerf. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0163) 0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71. J.F. Heafner. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0164) 0165 Proffered Official Initial Connection Protocol. J. Postel. May 1971. (Format: TXT, PDF, HTML) (Obsoletes RFC0145, RFC0143, RFC0123) (Updated by NIC7101) (Status: UNKNOWN) (DOI: 10.17487/RFC0165) 0166 Data Reconfiguration Service: An implementation specification. R.H. Anderson, V.G. Cerf, E. Harslem, J.F. Heafner, J. Madden, R.M. Metcalfe, A. Shoshani, J.E. White, D.C.M. Wood. May 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0166) 0167 Socket conventions reconsidered. A.K. Bhushan, R.M. Metcalfe, J.M. Winett. May 1971. (Format: TXT, HTML) (Also RFC0129, RFC0147) (Status: UNKNOWN) (DOI: 10.17487/RFC0167) 0168 ARPA Network mailing lists. J.B. North. May 1971. (Format: TXT, HTML) (Obsoletes RFC0155) (Obsoleted by RFC0211) (Status: UNKNOWN) (DOI: 10.17487/RFC0168) 0169 COMPUTER NETWORKS. S.D. Crocker. May 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0169) 0170 RFC List by Number. Network Information Center. Stanford Research Institute. June 1971. (Format: TXT, HTML) (Obsoleted by RFC0200) (Status: UNKNOWN) (DOI: 10.17487/RFC0170) 0171 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, J. Melvin, B. Sundberg, D. Watson, J. White. June 1971. (Format: TXT, HTML) (Obsoleted by RFC0264) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) (DOI: 10.17487/RFC0171) 0172 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. June 1971. (Format: TXT, HTML) (Obsoleted by RFC0265) (Updates RFC0114) (Updated by RFC0238) (Status: UNKNOWN) (DOI: 10.17487/RFC0172) 0173 Network Data Management Committee Meeting Announcement. P.M. Karp, D.B. McKay. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0173) 0174 UCLA - Computer Science Graphics Overview. J. Postel, V.G. Cerf. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0174) 0175 Comments on "Socket Conventions Reconsidered". E. Harslem, J.F. Heafner. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0175) 0176 Comments on "Byte size for connections". A.K. Bhushan, R. Kanodia, R.M. Metcalfe, J. Postel. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0176) 0177 Device independent graphical display description. J. McConnell. June 1971. (Format: TXT, HTML) (Updates RFC0125) (Updated by RFC0181) (Status: UNKNOWN) (DOI: 10.17487/RFC0177) 0178 Network graphic attention handling. I.W. Cotton. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0178) 0179 Link Number Assignments. A.M. McKenzie. June 1971. (Format: TXT, HTML) (Updates RFC0107) (Status: UNKNOWN) (DOI: 10.17487/RFC0179) 0180 File system questionnaire. A.M. McKenzie. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0180) 0181 Modifications to RFC 177. J. McConnell. July 1971. (Format: TXT, HTML) (Updates RFC0177) (Status: UNKNOWN) (DOI: 10.17487/RFC0181) 0182 Compilation of list of relevant site reports. J.B. North. June 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0182) 0183 EBCDIC Codes and Their Mapping to ASCII. J.M. Winett. July 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0183) 0184 Proposed graphic display modes. K.C. Kelley. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0184) 0185 NIC distribution of manuals and handbooks. J.B. North. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0185) 0186 Network graphics loader. J.C. Michener. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0186) 0187 Network/440 Protocol Concept. D.B. McKay, D.P. Karp. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0187) 0188 Data management meeting announcement. P.M. Karp, D.B. McKay. January 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0188) 0189 Interim NETRJS specifications. R.T. Braden. July 1971. (Format: TXT, HTML) (Obsoletes RFC0088) (Obsoleted by RFC0599) (Updated by RFC0283) (Status: UNKNOWN) (DOI: 10.17487/RFC0189) 0190 DEC PDP-10-IMLAC communications system. L.P. Deutsch. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0190) 0191 Graphics implementation and conceptualization at Augmentation Research Center. C.H. Irby. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0191) 0192 Some factors which a Network Graphics Protocol must consider. R.W. Watson. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0192) 0193 NETWORK CHECKOUT. E. Harslem, J.F. Heafner. July 1971. (Format: TXT, HTML) (Obsoleted by RFC0198) (Updated by RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0193) 0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes. V. Cerf, E. Harslem, J. Heafner, B. Metcalfe, J. White. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0194) 0195 Data computers-data descriptions and access language. G.H. Mealy. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0195) 0196 Mail Box Protocol. R.W. Watson. July 1971. (Format: TXT, HTML) (Obsoleted by RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0196) 0197 Initial Connection Protocol - Reviewed. A. Shoshani, E. Harslem. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0197) 0198 Site Certification - Lincoln Labs 360/67. J.F. Heafner. July 1971. (Format: TXT, HTML) (Obsoletes RFC0193) (Obsoleted by RFC0214) (Updates RFC0193) (Status: UNKNOWN) (DOI: 10.17487/RFC0198) 0199 Suggestions for a Network Data-Tablet Graphics Protocol. T. Williams. July 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0199) 0200 RFC list by number. J.B. North. August 1971. (Format: TXT, HTML) (Obsoletes RFC0170, RFC0160) (Obsoleted by NIC7724) (Status: UNKNOWN) (DOI: 10.17487/RFC0200) 0201 Not Issued. 0202 Possible Deadlock in ICP. S.M. Wolfe, J. Postel. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0202) 0203 Achieving reliable communication. R.B. Kalin. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0203) 0204 Sockets in use. J. Postel. August 1971. (Format: TXT, HTML) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0204) 0205 NETCRT - a character display protocol. R.T. Braden. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0205) 0206 A User TELNET Description of an Initial Implementation. J. White. August 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0206) 0207 September Network Working Group meeting. A. Vezza. August 1971. (Format: TXT, HTML) (Obsoleted by RFC0212) (Status: UNKNOWN) (DOI: 10.17487/RFC0207) 0208 Address tables. A.M. McKenzie. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0208) 0209 Host/IMP interface documentation. B. Cosell. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0209) 0210 Improvement of Flow Control. W. Conrad. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0210) 0211 ARPA Network Mailing Lists. J.B. North. August 1971. (Format: TXT, PDF, HTML) (Obsoletes RFC0168) (Obsoleted by RFC0300) (Status: UNKNOWN) (DOI: 10.17487/RFC0211) 0212 NWG meeting on network usage. Information Sciences Institute University of Southern California. August 1971. (Format: TXT, HTML) (Obsoletes RFC0207) (Updated by RFC0222) (Status: UNKNOWN) (DOI: 10.17487/RFC0212) 0213 IMP System change notification. B. Cosell. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0213) 0214 Network checkpoint. E. Harslem. August 1971. (Format: TXT, HTML) (Obsoletes RFC0198) (Status: UNKNOWN) (DOI: 10.17487/RFC0214) 0215 NCP, ICP, and Telnet: The Terminal IMP implementation. A.M. McKenzie. August 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0215) 0216 Telnet Access to UCSB's On-Line System. J.E. White. September 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0216) 0217 Specifications changes for OLS, RJE/RJOR, and SMFS. J.E. White. September 1971. (Format: TXT, HTML) (Updates RFC0074, RFC0105, RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0217) 0218 Changing the IMP status reporting facility. B. Cosell. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0218) 0219 User's View of the Datacomputer. R. Winter. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0219) 0220 Not Issued. 0221 Mail Box Protocol: Version 2. R.W. Watson. August 1971. (Format: TXT, HTML) (Obsoletes RFC0196) (Obsoleted by RFC0278) (Status: UNKNOWN) (DOI: 10.17487/RFC0221) 0222 Subject: System programmer's workshop. R.M. Metcalfe. September 1971. (Format: TXT, HTML) (Updates RFC0212) (Updated by RFC0234) (Status: UNKNOWN) (DOI: 10.17487/RFC0222) 0223 Network Information Center schedule for network users. J.T. Melvin, R.W. Watson. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0223) 0224 Comments on Mailbox Protocol. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0224) 0225 Rand/UCSB network graphics experiment. E. Harslem, R. Stoughton. September 1971. (Format: TXT, HTML) (Updates RFC0074) (Status: UNKNOWN) (DOI: 10.17487/RFC0225) 0226 Standardization of host mnemonics. P.M. Karp. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0247) (Status: UNKNOWN) (DOI: 10.17487/RFC0226) 0227 Data transfer rates (Rand/UCLA). J.F. Heafner, E. Harslem. September 1971. (Format: TXT, HTML) (Updates RFC0113) (Status: UNKNOWN) (DOI: 10.17487/RFC0227) 0228 Clarification. D.C. Walden. September 1971. (Format: TXT, HTML) (Updates RFC0070) (Status: UNKNOWN) (DOI: 10.17487/RFC0228) 0229 Standard host names. J. Postel. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0229) 0230 Toward reliable operation of minicomputer-based terminals on a TIP. T. Pyke. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0230) 0231 Service center standards for remote usage: A user's view. J.F. Heafner, E. Harslem. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0231) 0232 Postponement of network graphics meeting. A. Vezza. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0232) 0233 Standardization of host call letters. A. Bhushan, R. Metcalfe. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0233) 0234 Network Working Group meeting schedule. A. Vezza. October 1971. (Format: TXT, HTML) (Updates RFC0222, RFC0204) (Status: UNKNOWN) (DOI: 10.17487/RFC0234) 0235 Site status. E. Westheimer. September 1971. (Format: TXT, HTML) (Obsoleted by RFC0240) (Status: UNKNOWN) (DOI: 10.17487/RFC0235) 0236 Standard host names. J. Postel. September 1971. (Format: TXT, HTML) (Obsoletes RFC0229) (Status: UNKNOWN) (DOI: 10.17487/RFC0236) 0237 NIC view of standard host names. R.W. Watson. October 1971. (Format: TXT, HTML) (Obsoleted by RFC0273) (Status: UNKNOWN) (DOI: 10.17487/RFC0237) 0238 Comments on DTP and FTP proposals. R.T. Braden. September 1971. (Format: TXT, HTML) (Updates RFC0171, RFC0172) (Status: UNKNOWN) (DOI: 10.17487/RFC0238) 0239 Host mnemonics proposed in RFC 226 (NIC 7625). R.T. Braden. September 1971. (Format: TXT, HTML) (Also RFC0226, RFC0229, RFC0236) (Status: UNKNOWN) (DOI: 10.17487/RFC0239) 0240 Site Status. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Obsoletes RFC0235) (Obsoleted by RFC0252) (Status: UNKNOWN) (DOI: 10.17487/RFC0240) 0241 Connecting computers to MLC ports. A.M. McKenzie. September 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0241) 0242 Data Descriptive Language for Shared Data. L. Haibt, A.P. Mullery. July 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0242) 0243 Network and data sharing bibliography. A.P. Mullery. October 1971. (Format: TXT, HTML) (Obsoleted by RFC0290) (Status: UNKNOWN) (DOI: 10.17487/RFC0243) 0244 Not Issued. 0245 Reservations for Network Group meeting. C. Falls. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0245) 0246 Network Graphics meeting. A. Vezza. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0246) 0247 Proffered set of standard host names. P.M. Karp. October 1971. (Format: TXT, HTML) (Obsoletes RFC0226) (Status: UNKNOWN) (DOI: 10.17487/RFC0247) 0248 Not Issued. 0249 Coordination of equipment and supplies purchase. R.F. Borelli. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0249) 0250 Some thoughts on file transfer. H. Brodie. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0250) 0251 Weather data. D. Stern. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0251) 0252 Network host status. E. Westheimer. October 1971. (Format: TXT, HTML) (Obsoletes RFC0240) (Obsoleted by RFC0255) (Status: UNKNOWN) (DOI: 10.17487/RFC0252) 0253 Second Network Graphics meeting details. J.A. Moorer. October 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0253) 0254 Scenarios for using ARPANET computers. A. Bhushan. October 1971. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0254) 0255 Status of network hosts. E. Westheimer. October 1971. (Format: TXT, HTML) (Obsoletes RFC0252) (Obsoleted by RFC0266) (Status: UNKNOWN) (DOI: 10.17487/RFC0255) 0256 IMPSYS change notification. B. Cosell. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0256) 0257 Not Issued. 0258 Not Issued. 0259 Not Issued. 0260 Not Issued. 0261 Not Issued. 0262 Not Issued. 0263 "Very Distant" Host interface. A.M. McKenzie. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0263) 0264 The Data Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenize, B. Sundberg, D. Watson, J. White. January 1972. (Format: TXT, HTML) (Obsoletes RFC0171) (Obsoleted by RFC0354) (Updated by RFC0310) (Also RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0264) 0265 The File Transfer Protocol. A. Bhushan, B. Braden, W. Crowther, E. Harslem, J. Heafner, A. McKenzie, J. Melvin, B. Sundberg, D. Watson, J. White. November 1971. (Format: TXT, HTML) (Obsoletes RFC0172) (Obsoleted by RFC0354) (Updated by RFC0281, RFC0294, RFC0310) (Also RFC0264) (Status: UNKNOWN) (DOI: 10.17487/RFC0265) 0266 Network host status. E. Westheimer. November 1971. (Format: TXT, HTML) (Obsoletes RFC0255) (Obsoleted by RFC0267) (Status: UNKNOWN) (DOI: 10.17487/RFC0266) 0267 Network Host Status. E. Westheimer. November 1971. (Format: TXT, HTML) (Obsoletes RFC0266) (Obsoleted by RFC0287) (Status: UNKNOWN) (DOI: 10.17487/RFC0267) 0268 Graphics facilities information. J. Postel. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0268) 0269 Some Experience with File Transfer. H. Brodie. December 1971. (Format: TXT, HTML) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0269) 0270 Correction to BBN Report No. 1822 (NIC NO 7958). A.M. McKenzie. January 1972. (Format: TXT, PDF, HTML) (Updates NIC7959) (Status: UNKNOWN) (DOI: 10.17487/RFC0270) 0271 IMP System change notifications. B. Cosell. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0271) 0272 Not Issued. 0273 More on standard host names. R.W. Watson. October 1971. (Format: TXT, HTML) (Obsoletes RFC0237) (Status: UNKNOWN) (DOI: 10.17487/RFC0273) 0274 Establishing a local guide for network usage. E. Forman. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0274) 0275 Not Issued. 0276 NIC course. R.W. Watson. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0276) 0277 Not Issued. 0278 Revision of the Mail Box Protocol. A.K. Bhushan, R.T. Braden, E. Harslem, J.F. Heafner, A.M. McKenzie, J.T. Melvin, R.L. Sundberg, R.W. Watson, J.E. White. November 1971. (Format: TXT, HTML) (Obsoletes RFC0221) (Status: UNKNOWN) (DOI: 10.17487/RFC0278) 0279 Not Issued. 0280 A Draft of Host Names. R.W. Watson. November 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0280) 0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. December 1971. (Format: TXT, HTML) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0281) 0282 Graphics meeting report. M.A. Padlipsky. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0282) 0283 NETRJT: Remote Job Service Protocol for TIPS. R.T. Braden. December 1971. (Format: TXT, HTML) (Updates RFC0189) (Status: UNKNOWN) (DOI: 10.17487/RFC0283) 0284 Not Issued. 0285 Network graphics. D. Huff. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0285) 0286 Network Library Information System. E. Forman. December 1971. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0286) 0287 Status of Network Hosts. E. Westheimer. December 1971. (Format: TXT, HTML) (Obsoletes RFC0267) (Obsoleted by RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0287) 0288 Network host status. E. Westheimer. January 1972. (Format: TXT, HTML) (Obsoletes RFC0287) (Obsoleted by RFC0293) (Updated by RFC0293) (Status: UNKNOWN) (DOI: 10.17487/RFC0288) 0289 What we hope is an official list of host names. R.W. Watson. December 1971. (Format: TXT, HTML) (Obsoleted by RFC0384) (Status: UNKNOWN) (DOI: 10.17487/RFC0289) 0290 Computer networks and data sharing: A bibliography. A.P. Mullery. January 1972. (Format: TXT, HTML) (Obsoletes RFC0243) (Status: UNKNOWN) (DOI: 10.17487/RFC0290) 0291 Data Management Meeting Announcement. D.B. McKay. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0291) 0292 Graphics Protocol: Level 0 only. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. January 1972. (Format: TXT, HTML) (Obsoleted by RFC0493) (Status: UNKNOWN) (DOI: 10.17487/RFC0292) 0293 Network Host Status. E. Westheimer. January 1972. (Format: TXT, HTML) (Obsoletes RFC0288) (Obsoleted by RFC0298) (Updates RFC0288) (Status: UNKNOWN) (DOI: 10.17487/RFC0293) 0294 The Use of "Set Data Type" Transaction in File Transfer Protocol. A.K. Bhushan. January 1972. (Format: TXT, HTML) (Updates RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0294) 0295 Report of the Protocol Workshop, 12 October 1971. J. Postel. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0295) 0296 DS-1 Display System. D.E. Liddle. January 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0296) 0297 TIP Message Buffers. D.C. Walden. January 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0297) 0298 Network host status. E. Westheimer. February 1972. (Format: TXT, HTML) (Obsoletes RFC0293) (Obsoleted by RFC0306) (Status: UNKNOWN) (DOI: 10.17487/RFC0298) 0299 Information Management System. D. Hopkin. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0299) 0300 ARPA Network mailing lists. J.B. North. January 1972. (Format: TXT, HTML) (Obsoletes RFC0211) (Obsoleted by RFC0303) (Status: UNKNOWN) (DOI: 10.17487/RFC0300) 0301 BBN IMP (#5) and NCC Schedule March 4, 1971. R. Alter. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0301) 0302 Exercising The ARPANET. R.F. Bryan. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0302) 0303 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. March 1972. (Format: TXT, HTML) (Obsoletes RFC0300) (Obsoleted by RFC0329) (Status: UNKNOWN) (DOI: 10.17487/RFC0303) 0304 Data Management System Proposal for the ARPA Network. D.B. McKay. February 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0304) 0305 Unknown Host Numbers. R. Alter. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0305) 0306 Network host status. E. Westheimer. February 1972. (Format: TXT, HTML) (Obsoletes RFC0298) (Obsoleted by RFC0315) (Status: UNKNOWN) (DOI: 10.17487/RFC0306) 0307 Using network Remote Job Entry. E. Harslem. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0307) 0308 ARPANET host availability data. M. Seriff. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0308) 0309 Data and File Transfer Workshop Announcement. A.K. Bhushan. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0309) 0310 Another Look at Data and File Transfer Protocols. A.K. Bhushan. April 1972. (Format: TXT, HTML) (Updates RFC0264, RFC0265) (Status: UNKNOWN) (DOI: 10.17487/RFC0310) 0311 New Console Attachments to the USCB Host. R.F. Bryan. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0311) 0312 Proposed Change in IMP-to-Host Protocol. A.M. McKenzie. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0312) 0313 Computer based instruction. T.C. O'Sullivan. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0313) 0314 Network Graphics Working Group Meeting. I.W. Cotton. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0314) 0315 Network Host Status. E. Westheimer. March 1972. (Format: TXT, HTML) (Obsoletes RFC0306) (Obsoleted by RFC0319) (Status: UNKNOWN) (DOI: 10.17487/RFC0315) 0316 ARPA Network Data Management Working Group. D.B. McKay, A.P. Mullery. February 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0316) 0317 Official Host-Host Protocol Modification: Assigned Link Numbers. J. Postel. March 1972. (Format: TXT, HTML) (Obsoleted by RFC0604) (Status: UNKNOWN) (DOI: 10.17487/RFC0317) 0318 Telnet Protocols. J. Postel. April 1972. (Format: TXT, HTML) (Updates RFC0158) (Updated by RFC0435) (Also RFC0139, RFC0158) (Status: UNKNOWN) (DOI: 10.17487/RFC0318) 0319 Network Host Status. E. Westheimer. March 1972. (Format: TXT, HTML) (Obsoletes RFC0315) (Updated by RFC0326) (Status: UNKNOWN) (DOI: 10.17487/RFC0319) 0320 Workshop on Hard Copy Line Graphics. R. Reddy. March 1972. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0320) 0321 CBI Networking Activity at MITRE. P.M. Karp. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0321) 0322 Well known socket numbers. V. Cerf, J. Postel. March 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0322) 0323 Formation of Network Measurement Group (NMG). V. Cerf. March 1972. (Format: TXT, HTML) (Updated by RFC0388) (Status: UNKNOWN) (DOI: 10.17487/RFC0323) 0324 RJE Protocol meeting. J. Postel. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0324) 0325 Network Remote Job Entry program - NETRJS. G. Hicks. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0325) 0326 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0330) (Updates RFC0319) (Status: UNKNOWN) (DOI: 10.17487/RFC0326) 0327 Data and File Transfer workshop notes. A.K. Bhushan. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0327) 0328 Suggested Telnet Protocol Changes. J. Postel. April 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0328) 0329 ARPA Network Mailing Lists. Network Information Center. Stanford Research Institute. May 1972. (Format: TXT, HTML) (Obsoletes RFC0303) (Obsoleted by RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0329) 0330 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoletes RFC0326) (Updated by RFC0332) (Status: UNKNOWN) (DOI: 10.17487/RFC0330) 0331 IMP System Change Notification. J.M. McQuillan. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0331) 0332 Network Host Status. E. Westheimer. April 1972. (Format: TXT, HTML) (Obsoleted by RFC0342) (Updates RFC0330) (Status: UNKNOWN) (DOI: 10.17487/RFC0332) 0333 Proposed experiment with a Message Switching Protocol. R.D. Bressler, D. Murphy, D.C. Walden. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0333) 0334 Network Use on May 8. A.M. McKenzie. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0334) 0335 New Interface - IMP/360. R.F. Bryan. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0335) 0336 Level 0 Graphic Input Protocol. I.W. Cotton. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0336) 0337 Not Issued. 0338 EBCDIC/ASCII Mapping for Network RJE. R.T. Braden. May 1972. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0338) 0339 MLTNET: A "Multi Telnet" Subsystem for Tenex. R. Thomas. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0339) 0340 Proposed Telnet Changes. T.C. O'Sullivan. May 1972. (Format: TXT, HTML) (Also RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0340) 0341 Not Issued. 0342 Network Host Status. E. Westheimer. May 1972. (Format: TXT, HTML) (Obsoletes RFC0332) (Obsoleted by RFC0344) (Status: UNKNOWN) (DOI: 10.17487/RFC0342) 0343 IMP System change notification. A.M. McKenzie. May 1972. (Format: TXT, HTML) (Obsoletes RFC0331) (Obsoleted by RFC0359) (Status: UNKNOWN) (DOI: 10.17487/RFC0343) 0344 Network Host Status. E. Westheimer. May 1972. (Format: TXT, HTML) (Obsoletes RFC0342) (Obsoleted by RFC0353) (Status: UNKNOWN) (DOI: 10.17487/RFC0344) 0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN). K.C. Kelley. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0345) 0346 Satellite Considerations. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0346) 0347 Echo process. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0347) 0348 Discard Process. J. Postel. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0348) 0349 Proposed Standard Socket Numbers. J. Postel. May 1972. (Format: TXT, HTML) (Obsoleted by RFC0433) (Also RFC0204, RFC0322) (Status: UNKNOWN) (DOI: 10.17487/RFC0349) 0350 User Accounts for UCSB On-Line System. R. Stoughton. May 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0350) 0351 Graphics information form for the ARPANET graphics resources notebook. D. Crocker. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0351) 0352 TIP Site Information Form. D. Crocker. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0352) 0353 Network host status. E. Westheimer. June 1972. (Format: TXT, HTML) (Obsoletes RFC0344) (Obsoleted by RFC0362) (Status: UNKNOWN) (DOI: 10.17487/RFC0353) 0354 File Transfer Protocol. A.K. Bhushan. July 1972. (Format: TXT, HTML) (Obsoletes RFC0264, RFC0265) (Obsoleted by RFC0542) (Updated by RFC0385, RFC0454, RFC0683) (Status: UNKNOWN) (DOI: 10.17487/RFC0354) 0355 Response to NWG/RFC 346. J. Davidson. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0355) 0356 ARPA Network Control Center. R. Alter. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0356) 0357 Echoing strategy for satellite links. J. Davidson. June 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0357) 0358 Not Issued. 0359 Status of the Release of the New IMP System (2600). D.C. Walden. June 1972. (Format: TXT, HTML) (Obsoletes RFC0343) (Status: UNKNOWN) (DOI: 10.17487/RFC0359) 0360 Proposed Remote Job Entry Protocol. C. Holland. June 1972. (Format: TXT, PDF, HTML) (Obsoleted by RFC0407) (Status: UNKNOWN) (DOI: 10.17487/RFC0360) 0361 Deamon Processes on Host 106. R.D. Bressler. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0361) 0362 Network Host Status. E. Westheimer. June 1972. (Format: TXT, HTML) (Obsoletes RFC0353) (Obsoleted by RFC0366) (Status: UNKNOWN) (DOI: 10.17487/RFC0362) 0363 ARPA Network mailing lists. Network Information Center. Stanford Research Institute. August 1972. (Format: TXT, HTML) (Obsoletes RFC0329) (Obsoleted by RFC0402) (Status: UNKNOWN) (DOI: 10.17487/RFC0363) 0364 Serving remote users on the ARPANET. M.D. Abrams. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0364) 0365 Letter to All TIP Users. D.C. Walden. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0365) 0366 Network Host Status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0362) (Obsoleted by RFC0367) (Status: UNKNOWN) (DOI: 10.17487/RFC0366) 0367 Network host status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0366) (Obsoleted by RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0367) 0368 Comments on "Proposed Remote Job Entry Protocol". R.T. Braden. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0368) 0369 Evaluation of ARPANET services January-March, 1972. J.R. Pickens. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0369) 0370 Network Host Status. E. Westheimer. July 1972. (Format: TXT, HTML) (Obsoletes RFC0367) (Updated by RFC0376) (Status: UNKNOWN) (DOI: 10.17487/RFC0370) 0371 Demonstration at International Computer Communications Conference. R.E. Kahn. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0371) 0372 Notes on a Conversation with Bob Kahn on the ICCC. R.W. Watson. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0372) 0373 Arbitrary Character Sets. J. McCarthy. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0373) 0374 IMP System Announcement. A.M. McKenzie. July 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0374) 0375 Not Issued. 0376 Network Host Status. E. Westheimer. August 1972. (Format: TXT, HTML) (Updates RFC0370) (Status: UNKNOWN) (DOI: 10.17487/RFC0376) 0377 Using TSO via ARPA Network Virtual Terminal. R.T. Braden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0377) 0378 Traffic statistics (July 1972). A.M. McKenzie. August 1972. (Format: TXT, HTML) (Obsoleted by RFC0391) (Status: UNKNOWN) (DOI: 10.17487/RFC0378) 0379 Using TSO at CCN. R. Braden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0379) 0380 Not Issued. 0381 Three aids to improved network operation. J.M. McQuillan. July 1972. (Format: TXT, HTML) (Updated by RFC0394) (Status: UNKNOWN) (DOI: 10.17487/RFC0381) 0382 Mathematical Software on the ARPA Network. L. McDaniel. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0382) 0383 Not Issued. 0384 Official site idents for organizations in the ARPA Network. J.B. North. August 1972. (Format: TXT, HTML) (Obsoletes RFC0289) (Status: UNKNOWN) (DOI: 10.17487/RFC0384) 0385 Comments on the File Transfer Protocol. A.K. Bhushan. August 1972. (Format: TXT, HTML) (Updates RFC0354) (Updated by RFC0414) (Status: UNKNOWN) (DOI: 10.17487/RFC0385) 0386 Letter to TIP users-2. B. Cosell, D.C. Walden. August 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0386) 0387 Some experiences in implementing Network Graphics Protocol Level 0. K.C. Kelley, J. Meir. August 1972. (Format: TXT, HTML) (Updated by RFC0401) (Status: UNKNOWN) (DOI: 10.17487/RFC0387) 0388 NCP statistics. V. Cerf. August 1972. (Format: TXT, HTML) (Updates RFC0323) (Status: UNKNOWN) (DOI: 10.17487/RFC0388) 0389 UCLA Campus Computing Network Liaison Staff for ARPA Network. B. Noble. August 1972. (Format: TXT, HTML) (Obsoleted by RFC0423) (Status: UNKNOWN) (DOI: 10.17487/RFC0389) 0390 TSO Scenario. R.T. Braden. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0390) 0391 Traffic statistics (August 1972). A.M. McKenzie. September 1972. (Format: TXT, HTML) (Obsoletes RFC0378) (Status: UNKNOWN) (DOI: 10.17487/RFC0391) 0392 Measurement of host costs for transmitting network data. G. Hicks, B.D. Wessler. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0392) 0393 Comments on Telnet Protocol Changes. J.M. Winett. October 1972. (Format: TXT, HTML) (Also RFC0109, RFC0139, RFC0158, RFC0318, RFC0328) (Status: UNKNOWN) (DOI: 10.17487/RFC0393) 0394 Two Proposed Changes to the IMP-Host Protocol. J.M. McQuillan. September 1972. (Format: TXT, HTML) (Updates RFC0381) (Status: UNKNOWN) (DOI: 10.17487/RFC0394) 0395 Switch Settings on IMPs and TIPs. J.M. McQuillan. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0395) 0396 Network Graphics Working Group Meeting - Second Iteration. S. Bunch. November 1972. (Format: TXT, HTML) (Updated by RFC0474) (Status: UNKNOWN) (DOI: 10.17487/RFC0396) 0397 Not Issued. 0398 UCSB Online Graphics. J.R. Pickens, E. Faeh. September 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0398) 0399 SMFS Login and Logout. M. Krilanovich. September 1972. (Format: TXT, HTML) (Obsoleted by RFC0431) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0399) 0400 Traffic Statistics (September 1972). A.M. McKenzie. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0400) 0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates. J. Hansen. October 1972. (Format: TXT, HTML) (Updates RFC0387) (Status: UNKNOWN) (DOI: 10.17487/RFC0401) 0402 ARPA Network Mailing Lists. J.B. North. October 1972. (Format: TXT, HTML) (Obsoletes RFC0363) (Status: UNKNOWN) (DOI: 10.17487/RFC0402) 0403 Desirability of a Network 1108 Service. G. Hicks. January 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0403) 0404 Host Address Changes Involving Rand and ISI. A.M. McKenzie. October 1972. (Format: TXT, HTML) (Updated by RFC0405) (Status: UNKNOWN) (DOI: 10.17487/RFC0404) 0405 Correction to RFC 404. A.M. McKenzie. October 1972. (Format: TXT, HTML) (Updates RFC0404) (Status: UNKNOWN) (DOI: 10.17487/RFC0405) 0406 Scheduled IMP Software Releases. J.M. McQuillan. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0406) 0407 Remote Job Entry Protocol. R.D. Bressler, R. Guida, A.M. McKenzie. October 1972. (Format: TXT, HTML) (Obsoletes RFC0360) (Status: HISTORIC) (DOI: 10.17487/RFC0407) 0408 NETBANK. A.D. Owen, J. Postel. October 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0408) 0409 Tenex interface to UCSB's Simple-Minded File System. J.E. White. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0409) 0410 Removal of the 30-Second Delay When Hosts Come Up. J.M. McQuillan. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0410) 0411 New MULTICS Network Software Features. M.A. Padlipsky. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0411) 0412 User FTP Documentation. G. Hicks. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0412) 0413 Traffic statistics (October 1972). A.M. McKenzie. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0413) 0414 File Transfer Protocol (FTP) status and further comments. A.K. Bhushan. December 1972. (Format: TXT, HTML) (Updates RFC0385) (Status: UNKNOWN) (DOI: 10.17487/RFC0414) 0415 Tenex bandwidth. H. Murray. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0415) 0416 ARC System Will Be Unavailable for Use During Thanksgiving Week. J.C. Norton. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0416) 0417 Link usage violation. J. Postel, C. Kline. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0417) 0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center. W. Hathaway. November 1972. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0418) 0419 To: Network liaisons and station agents. A. Vezza. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0419) 0420 CCA ICCC weather demo. H. Murray. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0420) 0421 Software Consulting Service for Network Users. A.M. McKenzie. November 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0421) 0422 Traffic statistics (November 1972). A.M. McKenzie. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0422) 0423 UCLA Campus Computing Network Liaison Staff for ARPANET. B. Noble. December 1972. (Format: TXT, HTML) (Obsoletes RFC0389) (Status: UNKNOWN) (DOI: 10.17487/RFC0423) 0424 Not Issued. 0425 "But my NCP costs $500 a day". R.D. Bressler. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0425) 0426 Reconnection Protocol. R. Thomas. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0426) 0427 Not Issued. 0428 Not Issued. 0429 Character Generator Process. J. Postel. December 1972. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0429) 0430 Comments on File Transfer Protocol. R.T. Braden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0430) 0431 Update on SMFS Login and Logout. M. Krilanovich. December 1972. (Format: TXT, HTML) (Obsoletes RFC0399) (Updates RFC0122) (Status: UNKNOWN) (DOI: 10.17487/RFC0431) 0432 Network logical map. N. Neigus. December 1972. (Format: TXT, PDF, PS, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0432) 0433 Socket number list. J. Postel. December 1972. (Format: TXT, HTML) (Obsoletes RFC0349) (Obsoleted by RFC0503) (Status: UNKNOWN) (DOI: 10.17487/RFC0433) 0434 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Obsoleted by RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0434) 0435 Telnet issues. B. Cosell, D.C. Walden. January 1973. (Format: TXT, HTML) (Updates RFC0318) (Status: UNKNOWN) (DOI: 10.17487/RFC0435) 0436 Announcement of RJS at UCSB. M. Krilanovich. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0436) 0437 Data Reconfiguration Service at UCSB. E. Faeh. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0437) 0438 FTP server-server interaction. R. Thomas, R. Clements. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0438) 0439 PARRY encounters the DOCTOR. V. Cerf. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0439) 0440 Scheduled network software maintenance. D.C. Walden. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0440) 0441 Inter-Entity Communication - an experiment. R.D. Bressler, R. Thomas. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0441) 0442 Current flow-control scheme for IMPSYS. V. Cerf. January 1973. (Format: TXT, HTML) (Updated by RFC0449) (Status: UNKNOWN) (DOI: 10.17487/RFC0442) 0443 Traffic statistics (December 1972). A.M. McKenzie. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0443) 0444 Not Issued. 0445 IMP/TIP preventive maintenance schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0445) 0446 Proposal to consider a network program resource notebook. L.P. Deutsch. January 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0446) 0447 IMP/TIP memory retrofit schedule. A.M. McKenzie. January 1973. (Format: TXT, HTML) (Obsoletes RFC0434) (Obsoleted by RFC0476) (Status: UNKNOWN) (DOI: 10.17487/RFC0447) 0448 Print files in FTP. R.T. Braden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0448) 0449 Current flow-control scheme for IMPSYS. D.C. Walden. January 1973. (Format: TXT, HTML) (Updates RFC0442) (Status: UNKNOWN) (DOI: 10.17487/RFC0449) 0450 MULTICS sampling timeout change. M.A. Padlipsky. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0450) 0451 Tentative proposal for a Unified User Level Protocol. M.A. Padlipsky. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0451) 0452 TELNET Command at Host LL. J. Winett. February 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0452) 0453 Meeting announcement to discuss a network mail system. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0453) 0454 File Transfer Protocol - meeting announcement and a new proposed document. A.M. McKenzie. February 1973. (Format: TXT, HTML) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0454) 0455 Traffic statistics (January 1973). A.M. McKenzie. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0455) 0456 Memorandum: Date change of mail meeting. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0456) 0457 TIPUG. D.C. Walden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0457) 0458 Mail retrieval via FTP. R.D. Bressler, R. Thomas. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0458) 0459 Network questionnaires. W. Kantrowitz. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0459) 0460 NCP survey. C. Kline. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0460) 0461 Telnet Protocol meeting announcement. A.M. McKenzie. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0461) 0462 Responding to user needs. J. Iseli, D. Crocker. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0462) 0463 FTP comments and response to RFC 430. A.K. Bhushan. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0463) 0464 Resource notebook framework. M.D. Kudlick. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0464) 0465 Not Issued. 0466 Telnet logger/server for host LL-67. J.M. Winett. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0466) 0467 Proposed change to Host-Host Protocol: Resynchronization of connection status. J.D. Burchfiel, R.S. Tomlinson. February 1973. (Format: TXT, HTML) (Updated by RFC0492) (Status: UNKNOWN) (DOI: 10.17487/RFC0467) 0468 FTP data compression. R.T. Braden. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0468) 0469 Network mail meeting summary. M.D. Kudlick. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0469) 0470 Change in socket for TIP news facility. R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0470) 0471 Workshop on multi-site executive programs. R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0471) 0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925). S. Bunch. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0472) 0473 MIX and MIXAL?. D.C. Walden. February 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0473) 0474 Announcement of NGWG meeting: Call for papers. S. Bunch. March 1973. (Format: TXT, HTML) (Updates RFC0396) (Status: UNKNOWN) (DOI: 10.17487/RFC0474) 0475 FTP and Network Mail System. A.K. Bhushan. March 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0475) 0476 IMP/TIP memory retrofit schedule (rev 2). A.M. McKenzie. March 1973. (Format: TXT, HTML) (Obsoletes RFC0447) (Status: UNKNOWN) (DOI: 10.17487/RFC0476) 0477 Remote Job Service at UCSB. M. Krilanovich. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0477) 0478 FTP server-server interaction - II. R.D. Bressler, R. Thomas. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0478) 0479 Use of FTP by the NIC Journal. J.E. White. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0479) 0480 Host-dependent FTP parameters. J.E. White. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0480) 0481 Not Issued. 0482 Traffic statistics (February 1973). A.M. McKenzie. March 1973. (Format: TXT, HTML) (Updated by RFC0497) (Status: UNKNOWN) (DOI: 10.17487/RFC0482) 0483 Cancellation of the resource notebook framework meeting. M.D. Kudlick. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0483) 0484 Not Issued. 0485 MIX and MIXAL at UCSB. J.R. Pickens. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0485) 0486 Data transfer revisited. R.D. Bressler. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0486) 0487 Free file transfer. R.D. Bressler. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0487) 0488 NLS classes at network sites. M.F. Auerbach. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0488) 0489 Comment on resynchronization of connection status proposal. J. Postel. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0489) 0490 Surrogate RJS for UCLA-CCN. J.R. Pickens. March 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0490) 0491 What is "Free"?. M.A. Padlipsky. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0491) 0492 Response to RFC 467. E. Meyer. April 1973. (Format: TXT, HTML) (Updates RFC0467) (Status: UNKNOWN) (DOI: 10.17487/RFC0492) 0493 GRAPHICS PROTOCOL. J.C. Michener, I.W. Cotton, K.C. Kelley, D.E. Liddle, E. Meyer. April 1973. (Format: TXT, PDF, HTML) (Obsoletes RFC0292) (Status: UNKNOWN) (DOI: 10.17487/RFC0493) 0494 Availability of MIX and MIXAL in the Network. D.C. Walden. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0494) 0495 Telnet Protocol specifications. A.M. McKenzie. May 1973. (Format: TXT, HTML) (Obsoletes RFC0158) (Updated by RFC0562) (Status: UNKNOWN) (DOI: 10.17487/RFC0495) 0496 TNLS quick reference card is available. M.F. Auerbach. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0496) 0497 Traffic Statistics (March 1973). A.M. McKenzie. April 1973. (Format: TXT, PDF, HTML) (Updates RFC0482) (Status: UNKNOWN) (DOI: 10.17487/RFC0497) 0498 On mail service to CCN. R.T. Braden. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0498) 0499 Harvard's network RJE. B.R. Reussow. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0499) 0500 Integration of data management systems on a computer network. A. Shoshani, I. Spiegler. April 1973. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0500) 0501 Un-muddling "free file transfer". K.T. Pogran. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0501) 0502 Not Issued. 0503 Socket number list. N. Neigus, J. Postel. April 1973. (Format: TXT, HTML) (Obsoletes RFC0433) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0503) 0504 Distributed resources workshop announcement. R. Thomas. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0504) 0505 Two solutions to a file transfer access problem. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0505) 0506 FTP command naming problem. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0506) 0507 Not Issued. 0508 Real-time data transmission on the ARPANET. L. Pfeifer, J. McAfee. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0508) 0509 Traffic statistics (April 1973). A.M. McKenzie. April 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0509) 0510 Request for network mailbox addresses. J.E. White. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0510) 0511 Enterprise phone service to NIC from ARPANET sites. J.B. North. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0511) 0512 More on lost message detection. W. Hathaway. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0512) 0513 Comments on the new Telnet specifications. W. Hathaway. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0513) 0514 Network make-work. W. Kantrowitz. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0514) 0515 Specifications for Datalanguage, Version 0/9. R. Winter. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0515) 0516 Lost message detection. J. Postel. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0516) 0517 Not Issued. 0518 ARPANET accounts. N. Vaughan, E.J. Feinler. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0518) 0519 Resource Evaluation. J.R. Pickens. June 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0519) 0520 Memo to FTP group: Proposal for File Access Protocol. J.D. Day. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0520) 0521 Restricted use of IMP DDT. A.M. McKenzie. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0521) 0522 Traffic Statistics (May 1973). A.M. McKenzie. June 1973. (Format: TXT, PDF, HTML) (Updates RFC0509) (Status: UNKNOWN) (DOI: 10.17487/RFC0522) 0523 SURVEY is in operation again. A.K. Bhushan. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0523) 0524 Proposed Mail Protocol. J.E. White. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0524) 0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing. W. Parrish, J.R. Pickens. June 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0525) 0526 Technical meeting: Digital image processing software systems. W.K. Pratt. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0526) 0527 ARPAWOCKY. R. Merryman. May 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0527) 0528 Software checksumming in the IMP and network reliability. J.M. McQuillan. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0528) 0529 Note on protocol synch sequences. A.M. McKenzie, R. Thomas, R.S. Tomlinson, K.T. Pogran. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0529) 0530 Report on the Survey Project. A.K. Bhushan. June 1973. (Format: PDF, HTML) (Updates RFC0308, RFC0523) (Status: UNKNOWN) (DOI: 10.17487/RFC0530) 0531 Feast or famine? A response to two recent RFC's about network information. M.A. Padlipsky. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0531) 0532 UCSD-CC Server-FTP facility. R.G. Merryman. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0532) 0533 Message-ID numbers. D.C. Walden. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0533) 0534 Lost message detection. D.C. Walden. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0534) 0535 Comments on File Access Protocol. R. Thomas. July 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0535) 0536 Not Issued. 0537 Announcement of NGG meeting July 16-17. S. Bunch. June 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0537) 0538 Traffic statistics (June 1973). A.M. McKenzie. July 1973. (Format: TXT, HTML) (Updated by RFC0556) (Status: UNKNOWN) (DOI: 10.17487/RFC0538) 0539 Thoughts on the mail protocol proposed in RFC 524. D. Crocker, J. Postel. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0539) 0540 Not Issued. 0541 Not Issued. 0542 File Transfer Protocol. N. Neigus. August 1973. (Format: TXT, HTML) (Obsoletes RFC0354) (Obsoleted by RFC0765) (Updated by RFC0614, RFC0640) (Also RFC0454, RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0542) 0543 Network journal submission and delivery. N.D. Meyer. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0543) 0544 Locating on-line documentation at SRI-ARC. N.D. Meyer, K. Kelley. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0544) 0545 Of what quality be the UCSB resources evaluators?. J.R. Pickens. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0545) 0546 Tenex load averages for July 1973. R. Thomas. August 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0546) 0547 Change to the Very Distant Host specification. D.C. Walden. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0547) 0548 Hosts using the IMP Going Down message. D.C. Walden. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0548) 0549 Minutes of Network Graphics Group meeting, 15-17 July 1973. J.C. Michener. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0549) 0550 NIC NCP experiment. L.P. Deutsch. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0550) 0551 NYU, ANL, and LBL Joining the Net. Y. Feinroth, R. Fink. August 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0551) 0552 Single access to standard protocols. A.D. Owen. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0552) 0553 Draft design for a text/graphics protocol. C.H. Irby, K. Victor. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0553) 0554 Not Issued. 0555 Responses to critiques of the proposed mail protocol. J.E. White. July 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0555) 0556 Traffic Statistics (July 1973). A.M. McKenzie. August 1973. (Format: TXT, PDF, HTML) (Updates RFC0538) (Status: UNKNOWN) (DOI: 10.17487/RFC0556) 0557 REVELATIONS IN NETWORK HOST MEASUREMENTS. B.D. Wessler. August 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0557) 0558 Not Issued. 0559 Comments on The New Telnet Protocol and its Implementation. A.K. Bushan. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0559) 0560 Remote Controlled Transmission and Echoing Telnet option. D. Crocker, J. Postel. August 1973. (Format: TXT, PDF, HTML) (Updated by RFC0581) (Status: UNKNOWN) (DOI: 10.17487/RFC0560) 0561 Standardizing Network Mail Headers. A.K. Bhushan, K.T. Pogran, R.S. Tomlinson, J.E. White. September 1973. (Format: TXT, HTML) (Updated by RFC0680) (Status: UNKNOWN) (DOI: 10.17487/RFC0561) 0562 Modifications to the TELNET Specification. A.M. McKenzie. August 1973. (Format: TXT, PDF, HTML) (Updates RFC0495) (Status: UNKNOWN) (DOI: 10.17487/RFC0562) 0563 Comments on the RCTE Telnet option. J. Davidson. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0563) 0564 Not Issued. 0565 Storing network survey data at the datacomputer. D. Cantor. August 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0565) 0566 Traffic statistics (August 1973). A.M. McKenzie. September 1973. (Format: TXT, HTML) (Updated by RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0566) 0567 Cross Country Network Bandwidth. L.P. Deutsch. September 1973. (Format: TXT, HTML) (Updated by RFC0568) (Status: UNKNOWN) (DOI: 10.17487/RFC0567) 0568 Response to RFC 567 - cross country network bandwidth. J.M. McQuillan. September 1973. (Format: TXT, HTML) (Updates RFC0567) (Status: UNKNOWN) (DOI: 10.17487/RFC0568) 0569 NETED: A Common Editor for the ARPA Network. M.A. Padlipsky. October 1973. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0569) 0570 Experimental input mapping between NVT ASCII and UCSB On Line System. J.R. Pickens. October 1973. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0570) 0571 TENEX FTP PROBLEM. R. Braden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0571) 0572 Not Issued. 0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS. A. Bhushan. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0573) 0574 Announcement of a Mail Facility at UCSB. M. Krilanovich. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0574) 0575 Not Issued. 0576 Proposal for modifying linking. K. Victor. September 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0576) 0577 Mail priority. D. Crocker. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0577) 0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle. A.K. Bhushan, N.D. Ryan. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0578) 0579 Traffic statistics (September 1973). A.M. McKenzie. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0566) (Updated by RFC0586) (Status: UNKNOWN) (DOI: 10.17487/RFC0579) 0580 Note to Protocol Designers and Implementers. J. Postel. October 1973. (Format: TXT, HTML) (Updated by RFC0582) (Status: UNKNOWN) (DOI: 10.17487/RFC0580) 0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option. D. Crocker, J. Postel. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0560) (Status: UNKNOWN) (DOI: 10.17487/RFC0581) 0582 Comments on RFC 580: Machine readable protocols. R. Clements. November 1973. (Format: TXT, HTML) (Updates RFC0580) (Status: UNKNOWN) (DOI: 10.17487/RFC0582) 0583 Not Issued. 0584 Charter for ARPANET Users Interest Working Group. J. Iseli, D. Crocker, N. Neigus. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0584) 0585 ARPANET users interest working group meeting. D. Crocker, N. Neigus, E.J. Feinler, J. Iseli. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0585) 0586 Traffic statistics (October 1973). A.M. McKenzie. November 1973. (Format: TXT, PDF, HTML) (Updates RFC0579) (Status: UNKNOWN) (DOI: 10.17487/RFC0586) 0587 Announcing New Telnet Options. J. Postel. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0587) 0588 London Node Is Now Up. A. Stokes. October 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0588) 0589 CCN NETRJS server messages to remote user. R.T. Braden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0589) 0590 MULTICS address change. M.A. Padlipsky. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0590) 0591 Addition to the Very Distant Host specifications. D.C. Walden. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0591) 0592 Some thoughts on system design to facilitate resource sharing. R.W. Watson. November 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0592) 0593 Telnet and FTP implementation schedule change. A.M. McKenzie, J. Postel. November 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0593) 0594 Speedup of Host-IMP interface. J.D. Burchfiel. December 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0594) 0595 Second thoughts in defense of the Telnet Go-Ahead. W. Hathaway. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0595) 0596 Second thoughts on Telnet Go-Ahead. E.A. Taft. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0596) 0597 Host status. N. Neigus, E.J. Feinler. December 1973. (Format: TXT, HTML) (Updated by RFC0603) (Status: UNKNOWN) (DOI: 10.17487/RFC0597) 0598 RFC index - December 5, 1973. Network Information Center. Stanford Research Institute. December 1973. (Format: PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0598) 0599 Update on NETRJS. R.T. Braden. December 1973. (Format: TXT, HTML) (Obsoletes RFC0189) (Obsoleted by RFC0740) (Status: UNKNOWN) (DOI: 10.17487/RFC0599) 0600 Interfacing an Illinois plasma terminal to the ARPANET. A. Berggreen. November 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0600) 0601 Traffic statistics (November 1973). A.M. McKenzie. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0601) 0602 "The stockings were hung by the chimney with care". R.M. Metcalfe. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0602) 0603 Response to RFC 597: Host status. J.D. Burchfiel. December 1973. (Format: TXT, HTML) (Updates RFC0597) (Updated by RFC0613) (Status: UNKNOWN) (DOI: 10.17487/RFC0603) 0604 Assigned link numbers. J. Postel. December 1973. (Format: TXT, HTML) (Obsoletes RFC0317) (Obsoleted by RFC0739) (Status: UNKNOWN) (DOI: 10.17487/RFC0604) 0605 Not Issued. 0606 Host names on-line. L.P. Deutsch. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0606) 0607 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg. January 1974. (Format: TXT, HTML) (Obsoleted by RFC0624) (Updated by RFC0614) (Status: UNKNOWN) (DOI: 10.17487/RFC0607) 0608 Host names on-line. M.D. Kudlick. January 1974. (Format: TXT, HTML) (Obsoleted by RFC0810) (Status: UNKNOWN) (DOI: 10.17487/RFC0608) 0609 Statement of upcoming move of NIC/NLS service. B. Ferguson. January 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0609) 0610 Further datalanguage design concepts. R. Winter, J. Hill, W. Greiff. December 1973. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0610) 0611 Two changes to the IMP/Host Protocol to improve user/network communications. D.C. Walden. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0611) 0612 Traffic statistics (December 1973). A.M. McKenzie. January 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0612) 0613 Network connectivity: A response to RFC 603. A.M. McKenzie. January 1974. (Format: TXT, HTML) (Updates RFC0603) (Status: UNKNOWN) (DOI: 10.17487/RFC0613) 0614 Response to RFC 607: "Comments on the File Transfer Protocol". K.T. Pogran, N. Neigus. January 1974. (Format: TXT, HTML) (Updates RFC0542, RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0614) 0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March 1974. (Format: TXT, HTML) (Obsoleted by RFC0645) (Status: UNKNOWN) (DOI: 10.17487/RFC0615) 0616 LATEST NETWORK MAPS. D. Walden. February 1973. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0616) 0617 Note on socket number assignment. E.A. Taft. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0617) 0618 Few observations on NCP statistics. E.A. Taft. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0618) 0619 Mean round-trip times in the ARPANET. W. Naylor, H. Opderbeck. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0619) 0620 Request for monitor host table updates. B. Ferguson. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0620) 0621 NIC user directories at SRI ARC. M.D. Kudlick. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0621) 0622 Scheduling IMP/TIP down time. A.M. McKenzie. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0622) 0623 Comments on on-line host name service. M. Krilanovich. February 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0623) 0624 Comments on the File Transfer Protocol. M. Krilanovich, G. Gregg, W. Hathaway, J.E. White. February 1974. (Format: TXT, HTML) (Obsoletes RFC0607) (Status: UNKNOWN) (DOI: 10.17487/RFC0624) 0625 On-line hostnames service. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0625) 0626 On a possible lockup condition in IMP subnet due to message sequencing. L. Kleinrock, H. Opderbeck. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0626) 0627 ASCII text file of hostnames. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0627) 0628 Status of RFC numbers and a note on pre-assigned journal numbers. M.L. Keeney. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0628) 0629 Scenario for using the Network Journal. J.B. North. March 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0629) 0630 FTP error code usage for more reliable mail service. J. Sussman. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0630) 0631 International meeting on minicomputers and data communication: Call for papers. A. Danthine. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0631) 0632 Throughput degradations for single packet messages. H. Opderbeck. May 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0632) 0633 IMP/TIP preventive maintenance schedule. A.M. McKenzie. March 1974. (Format: TXT, HTML) (Obsoleted by RFC0638) (Status: UNKNOWN) (DOI: 10.17487/RFC0633) 0634 Change in network address for Haskins Lab. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0634) 0635 Assessment of ARPANET protocols. V. Cerf. April 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0635) 0636 TIP/Tenex reliability improvements. J.D. Burchfiel, B. Cosell, R.S. Tomlinson, D.C. Walden. June 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0636) 0637 Change of network address for SU-DSL. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0637) 0638 IMP/TIP preventive maintenance schedule. A.M. McKenzie. April 1974. (Format: TXT, HTML) (Obsoletes RFC0633) (Status: UNKNOWN) (DOI: 10.17487/RFC0638) 0639 Not Issued. 0640 Revised FTP reply codes. J. Postel. June 1974. (Format: TXT, HTML) (Updates RFC0542) (Status: UNKNOWN) (DOI: 10.17487/RFC0640) 0641 Not Issued. 0642 Ready line philosophy and implementation. J.D. Burchfiel. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0642) 0643 Network Debugging Protocol. E. Mader. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0643) 0644 On the problem of signature authentication for network mail. R. Thomas. July 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0644) 0645 Network Standard Data Specification syntax. D. Crocker. June 1974. (Format: TXT, PDF, HTML) (Obsoletes RFC0615) (Status: UNKNOWN) (DOI: 10.17487/RFC0645) 0646 Not Issued. 0647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors. M.A. Padlipsky. November 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0647) 0648 Not Issued. 0649 Not Issued. 0650 Not Issued. 0651 Revised Telnet status option. D. Crocker. October 1974. (Format: TXT, HTML) (Obsoleted by RFC0859) (Status: UNKNOWN) (DOI: 10.17487/RFC0651) 0652 Telnet output carriage-return disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0652) 0653 Telnet output horizontal tabstops option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0653) 0654 Telnet output horizontal tab disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0654) 0655 Telnet output formfeed disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0655) 0656 Telnet output vertical tabstops option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0656) 0657 Telnet output vertical tab disposition option. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0657) 0658 Telnet output linefeed disposition. D. Crocker. October 1974. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0658) 0659 Announcing additional Telnet options. J. Postel. October 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0659) 0660 Some changes to the IMP and the IMP/Host interface. D.C. Walden. October 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0660) 0661 Protocol information. J. Postel. November 1974. (Format: TXT, PDF, HTML) (Updated by RFC0694) (Status: UNKNOWN) (DOI: 10.17487/RFC0661) 0662 Performance improvement in ARPANET file transfers from Multics. R. Kanodia. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0662) 0663 Lost message detection and recovery protocol. R. Kanodia. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0663) 0664 Not Issued. 0665 Not Issued. 0666 Specification of the Unified User-Level Protocol. M.A. Padlipsky. November 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0666) 0667 Host Ports. S.G. Chipman. December 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0667) 0668 Not Issued. 0669 November, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. December 1974. (Format: TXT, PDF, HTML) (Updates RFC0702) (Updated by RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0669) 0670 Not Issued. 0671 Note on Reconnection Protocol. R. Schantz. December 1974. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0671) 0672 Multi-site data collection facility. R. Schantz. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0672) 0673 Not Issued. 0674 Procedure call documents: Version 2. J. Postel, J.E. White. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0674) 0675 Specification of Internet Transmission Control Program. V. Cerf, Y. Dalal, C. Sunshine. December 1974. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0675) 0676 Not Issued. 0677 Maintenance of duplicate databases. P.R. Johnson, R. Thomas. January 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0677) 0678 Standard file formats. J. Postel. December 1974. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0678) 0679 February, 1975, survey of New-Protocol Telnet servers. D.W. Dodds. February 1975. (Format: TXT, PDF, HTML) (Updates RFC0669) (Updated by RFC0703) (Status: UNKNOWN) (DOI: 10.17487/RFC0679) 0680 Message Transmission Protocol. T.H. Myer, D.A. Henderson. April 1975. (Format: TXT, HTML) (Updates RFC0561) (Status: UNKNOWN) (DOI: 10.17487/RFC0680) 0681 Network UNIX. S. Holmgren. March 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0681) 0682 Not Issued. 0683 FTPSRV - Tenex extension for paged files. R. Clements. April 1975. (Format: TXT, HTML) (Updates RFC0354) (Status: UNKNOWN) (DOI: 10.17487/RFC0683) 0684 Commentary on procedure calling as a network protocol. R. Schantz. April 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0684) 0685 Response time in cross network debugging. M. Beeler. April 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0685) 0686 Leaving well enough alone. B. Harvey. May 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0686) 0687 IMP/Host and Host/IMP Protocol changes. D.C. Walden. June 1975. (Format: TXT, HTML) (Obsoleted by RFC0704) (Updated by RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0687) 0688 Tentative schedule for the new Telnet implementation for the TIP. D.C. Walden. June 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0688) 0689 Tenex NCP finite state machine for connections. R. Clements. May 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0689) 0690 Comments on the proposed Host/IMP Protocol changes. J. Postel. June 1975. (Format: TXT, HTML) (Updates RFC0687) (Updated by RFC0692) (Status: UNKNOWN) (DOI: 10.17487/RFC0690) 0691 One more try on the FTP. B. Harvey. June 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0691) 0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690). S.M. Wolfe. June 1975. (Format: TXT, HTML) (Updates RFC0690) (Status: UNKNOWN) (DOI: 10.17487/RFC0692) 0693 Not Issued. 0694 Protocol information. J. Postel. June 1975. (Format: TXT, PDF, HTML) (Updates RFC0661) (Status: UNKNOWN) (DOI: 10.17487/RFC0694) 0695 Official change in Host-Host Protocol. M. Krilanovich. July 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0695) 0696 Comments on the IMP/Host and Host/IMP Protocol changes. V.G. Cerf. July 1975. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0696) 0697 CWD command of FTP. J. Lieb. July 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0697) 0698 Telnet extended ASCII option. T. Mock. July 1975. (Format: TXT, HTML) (Obsoleted by RFC5198) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0698) 0699 Request For Comments summary notes: 600-699. J. Postel, J. Vernon. November 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0699) 0700 Protocol experiment. E. Mader, W.W. Plummer, R.S. Tomlinson. August 1974. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0700) 0701 August, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. August 1974. (Format: TXT, HTML) (Updated by RFC0702) (Status: UNKNOWN) (DOI: 10.17487/RFC0701) 0702 September, 1974, survey of New-Protocol Telnet servers. D.W. Dodds. September 1974. (Format: TXT, HTML) (Updates RFC0701) (Updated by RFC0669) (Status: UNKNOWN) (DOI: 10.17487/RFC0702) 0703 July, 1975, survey of New-Protocol Telnet Servers. D.W. Dodds. July 1975. (Format: TXT, HTML) (Updates RFC0679) (Status: UNKNOWN) (DOI: 10.17487/RFC0703) 0704 IMP/Host and Host/IMP Protocol change. P.J. Santos. September 1975. (Format: TXT, HTML) (Obsoletes RFC0687) (Status: UNKNOWN) (DOI: 10.17487/RFC0704) 0705 Front-end Protocol B6700 version. R.F. Bryan. November 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0705) 0706 On the junk mail problem. J. Postel. November 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0706) 0707 High-level framework for network-based resource sharing. J.E. White. December 1975. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0707) 0708 Elements of a Distributed Programming System. J.E. White. January 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0708) 0709 Not Issued. 0710 Not Issued. 0711 Not Issued. 0712 Distributed Capability Computing System (DCCS). J.E. Donnelley. February 1976. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0712) 0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty. April 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0713) 0714 Host-Host Protocol for an ARPANET-Type Network. A.M. McKenzie. April 1976. (Format: TXT, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0714) 0715 Not Issued. 0716 Interim Revision to Appendix F of BBN 1822. D.C. Walden, J. Levin. May 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0716) 0717 Assigned Network Numbers. J. Postel. July 1976. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0717) 0718 Comments on RCTE from the Tenex Implementation Experience. J. Postel. June 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0718) 0719 Discussion on RCTE. J. Postel. July 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0719) 0720 Address Specification Syntax for Network Mail. D. Crocker. August 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0720) 0721 Out-of-Band Control Signals in a Host-to-Host Protocol. L.L. Garlick. September 1976. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0721) 0722 Thoughts on Interactions in Distributed Services. J. Haverty. September 1976. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0722) 0723 Not Issued. 0724 Proposed official standard for the format of ARPA Network messages. D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson. May 1977. (Format: TXT, HTML) (Obsoleted by RFC0733) (Status: UNKNOWN) (DOI: 10.17487/RFC0724) 0725 RJE protocol for a resource sharing network. J.D. Day, G.R. Grossman. March 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0725) 0726 Remote Controlled Transmission and Echoing Telnet option. J. Postel, D. Crocker. March 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0726) 0727 Telnet logout option. M.R. Crispin. April 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0727) 0728 Minor pitfall in the Telnet Protocol. J.D. Day. April 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0728) 0729 Telnet byte macro option. D. Crocker. May 1977. (Format: TXT, HTML) (Obsoleted by RFC0735) (Status: UNKNOWN) (DOI: 10.17487/RFC0729) 0730 Extensible field addressing. J. Postel. May 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0730) 0731 Telnet Data Entry Terminal option. J.D. Day. June 1977. (Format: TXT, HTML) (Obsoleted by RFC0732) (Status: UNKNOWN) (DOI: 10.17487/RFC0731) 0732 Telnet Data Entry Terminal option. J.D. Day. September 1977. (Format: TXT, HTML) (Obsoletes RFC0731) (Updated by RFC1043) (Status: UNKNOWN) (DOI: 10.17487/RFC0732) 0733 Standard for the format of ARPA network text messages. D. Crocker, J. Vittal, K.T. Pogran, D.A. Henderson. November 1977. (Format: TXT, HTML) (Obsoletes RFC0724) (Obsoleted by RFC0822) (Status: UNKNOWN) (DOI: 10.17487/RFC0733) 0734 SUPDUP Protocol. M.R. Crispin. October 1977. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0734) 0735 Revised Telnet byte macro option. D. Crocker, R.H. Gumpertz. November 1977. (Format: TXT, HTML) (Obsoletes RFC0729) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0735) 0736 Telnet SUPDUP option. M.R. Crispin. October 1977. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0736) 0737 FTP extension: XSEN. K. Harrenstien. October 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0737) 0738 Time server. K. Harrenstien. October 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0738) 0739 Assigned numbers. J. Postel. November 1977. (Format: TXT, HTML) (Obsoletes RFC0604, RFC0503) (Obsoleted by RFC0750) (Status: HISTORIC) (DOI: 10.17487/RFC0739) 0740 NETRJS Protocol. R.T. Braden. November 1977. (Format: TXT, HTML) (Obsoletes RFC0599) (Status: HISTORIC) (DOI: 10.17487/RFC0740) 0741 Specifications for the Network Voice Protocol (NVP). D. Cohen. November 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0741) 0742 NAME/FINGER Protocol. K. Harrenstien. December 1977. (Format: TXT, HTML) (Obsoleted by RFC1288, RFC1196, RFC1194) (Status: UNKNOWN) (DOI: 10.17487/RFC0742) 0743 FTP extension: XRSQ/XRCP. K. Harrenstien. December 1977. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0743) 0744 MARS - a Message Archiving and Retrieval Service. J. Sattley. January 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0744) 0745 JANUS interface specifications. M. Beeler. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0745) 0746 SUPDUP graphics extension. R. Stallman. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0746) 0747 Recent extensions to the SUPDUP Protocol. M.R. Crispin. March 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0747) 0748 Telnet randomly-lose option. M.R. Crispin. 1 April 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0748) 0749 Telnet SUPDUP-Output option. B. Greenberg. September 1978. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0749) 0750 Assigned numbers. J. Postel. September 1978. (Format: TXT, HTML) (Obsoletes RFC0739) (Obsoleted by RFC0755) (Status: HISTORIC) (DOI: 10.17487/RFC0750) 0751 Survey of FTP mail and MLFL. P.D. Lebling. December 1978. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0751) 0752 Universal host table. M.R. Crispin. January 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0752) 0753 Internet Message Protocol. J. Postel. March 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0753) 0754 Out-of-net host addresses for mail. J. Postel. April 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0754) 0755 Assigned numbers. J. Postel. May 1979. (Format: TXT, HTML) (Obsoletes RFC0750) (Obsoleted by RFC0758) (Status: HISTORIC) (DOI: 10.17487/RFC0755) 0756 NIC name server - a datagram-based information utility. J.R. Pickens, E.J. Feinler, J.E. Mathis. July 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0756) 0757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems. D.P. Deutsch. September 1979. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0757) 0758 Assigned numbers. J. Postel. August 1979. (Format: TXT, HTML) (Obsoletes RFC0755) (Obsoleted by RFC0762) (Status: HISTORIC) (DOI: 10.17487/RFC0758) 0759 Internet Message Protocol. J. Postel. August 1980. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0759) 0760 DoD standard Internet Protocol. J. Postel. January 1980. (Format: TXT, HTML) (Obsoletes IEN123) (Obsoleted by RFC0791) (Updated by RFC0777) (Status: UNKNOWN) (DOI: 10.17487/RFC0760) 0761 DoD standard Transmission Control Protocol. J. Postel. January 1980. (Format: TXT, HTML) (Obsoleted by RFC0793, RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0761) 0762 Assigned numbers. J. Postel. January 1980. (Format: TXT, HTML) (Obsoletes RFC0758) (Obsoleted by RFC0770) (Status: HISTORIC) (DOI: 10.17487/RFC0762) 0763 Role mailboxes. M.D. Abrams. May 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0763) 0764 Telnet Protocol specification. J. Postel. June 1980. (Format: TXT, HTML) (Obsoleted by RFC0854) (Status: UNKNOWN) (DOI: 10.17487/RFC0764) 0765 File Transfer Protocol specification. J. Postel. June 1980. (Format: TXT, HTML) (Obsoletes RFC0542) (Obsoleted by RFC0959) (Status: UNKNOWN) (DOI: 10.17487/RFC0765) 0766 Internet Protocol Handbook: Table of contents. J. Postel. July 1980. (Format: TXT, HTML) (Obsoleted by RFC0774) (Status: UNKNOWN) (DOI: 10.17487/RFC0766) 0767 Structured format for transmission of multi-media documents. J. Postel. August 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0767) 0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT, HTML) (Also STD0006) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0768) 0769 Rapicom 450 facsimile file format. J. Postel. September 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0769) 0770 Assigned numbers. J. Postel. September 1980. (Format: TXT, HTML) (Obsoletes RFC0762) (Obsoleted by RFC0776) (Status: HISTORIC) (DOI: 10.17487/RFC0770) 0771 Mail transition plan. V.G. Cerf, J. Postel. September 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0771) 0772 Mail Transfer Protocol. S. Sluizer, J. Postel. September 1980. (Format: TXT, HTML) (Obsoleted by RFC0780) (Status: UNKNOWN) (DOI: 10.17487/RFC0772) 0773 Comments on NCP/TCP mail service transition strategy. V.G. Cerf. October 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0773) 0774 Internet Protocol Handbook: Table of contents. J. Postel. October 1980. (Format: TXT, HTML) (Obsoletes RFC0766) (Status: UNKNOWN) (DOI: 10.17487/RFC0774) 0775 Directory oriented FTP commands. D. Mankins, D. Franklin, A.D. Owen. December 1980. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0775) 0776 Assigned numbers. J. Postel. January 1981. (Format: TXT, HTML) (Obsoletes RFC0770) (Obsoleted by RFC0790) (Status: HISTORIC) (DOI: 10.17487/RFC0776) 0777 Internet Control Message Protocol. J. Postel. April 1981. (Format: TXT, HTML) (Obsoleted by RFC0792) (Updates RFC0760) (Status: UNKNOWN) (DOI: 10.17487/RFC0777) 0778 DCNET Internet Clock Service. D.L. Mills. April 1981. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0778) 0779 Telnet send-location option. E. Killian. April 1981. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0779) 0780 Mail Transfer Protocol. S. Sluizer, J. Postel. May 1981. (Format: TXT, HTML) (Obsoletes RFC0772) (Obsoleted by RFC0788) (Status: UNKNOWN) (DOI: 10.17487/RFC0780) 0781 Specification of the Internet Protocol (IP) timestamp option. Z. Su. May 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0781) 0782 Virtual Terminal management model. J. Nabielsky, A.P. Skelton. January 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0782) 0783 TFTP Protocol (revision 2). K.R. Sollins. June 1981. (Format: TXT, HTML) (Obsoletes IEN133) (Obsoleted by RFC1350) (Status: UNKNOWN) (DOI: 10.17487/RFC0783) 0784 Mail Transfer Protocol: ISI TOPS20 implementation. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0784) 0785 Mail Transfer Protocol: ISI TOPS20 file definitions. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0785) 0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface. S. Sluizer, J. Postel. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0786) 0787 Connectionless data transmission survey/tutorial. A.L. Chapin. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0787) 0788 Simple Mail Transfer Protocol. J. Postel. November 1981. (Format: TXT, HTML) (Obsoletes RFC0780) (Obsoleted by RFC0821) (Status: UNKNOWN) (DOI: 10.17487/RFC0788) 0789 Vulnerabilities of network control protocols: An example. E.C. Rosen. July 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0789) 0790 Assigned numbers. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0776) (Obsoleted by RFC0820) (Status: HISTORIC) (DOI: 10.17487/RFC0790) 0791 Internet Protocol. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0760) (Updated by RFC1349, RFC2474, RFC6864) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0791) 0792 Internet Control Message Protocol. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0777) (Updated by RFC0950, RFC4884, RFC6633, RFC6918) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0792) 0793 Transmission Control Protocol. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes RFC0761) (Updated by RFC1122, RFC3168, RFC6093, RFC6528) (Also STD0007) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0793) 0794 Pre-emption. V.G. Cerf. September 1981. (Format: TXT, HTML) (Updates IEN125) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0794) 0795 Service mappings. J. Postel. September 1981. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0795) 0796 Address mappings. J. Postel. September 1981. (Format: TXT, HTML) (Obsoletes IEN115) (Status: HISTORIC) (DOI: 10.17487/RFC0796) 0797 Format for Bitmap files. A.R. Katz. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0797) 0798 Decoding facsimile data from the Rapicom 450. A.R. Katz. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0798) 0799 Internet name domains. D.L. Mills. September 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0799) 0800 Request For Comments summary notes: 700-799. J. Postel, J. Vernon. November 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0800) 0801 NCP/TCP transition plan. J. Postel. November 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0801) 0802 ARPANET 1822L Host Access Protocol. A.G. Malis. November 1981. (Format: TXT, HTML) (Obsoleted by RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0802) 0803 Dacom 450/500 facsimile data transcoding. A. Agarwal, M.J. O'Connor, D.L. Mills. November 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0803) 0804 CCITT draft recommendation T.4. International Telegraph and Telephone Consultative Committee of the International Telecommunication Union. January 1981. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0804) 0805 Computer mail meeting notes. J. Postel. February 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0805) 0806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems. National Bureau of Standards. September 1981. (Format: TXT, HTML) (Obsoleted by RFC0841) (Status: UNKNOWN) (DOI: 10.17487/RFC0806) 0807 Multimedia mail meeting notes. J. Postel. February 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0807) 0808 Summary of computer mail services meeting held at BBN on 10 January 1979. J. Postel. March 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0808) 0809 UCL facsimile system. T. Chang. February 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0809) 0810 DoD Internet host table specification. E.J. Feinler, K. Harrenstien, Z. Su, V. White. March 1982. (Format: TXT, HTML) (Obsoletes RFC0608) (Obsoleted by RFC0952) (Status: UNKNOWN) (DOI: 10.17487/RFC0810) 0811 Hostnames Server. K. Harrenstien, V. White, E.J. Feinler. March 1982. (Format: TXT, HTML) (Obsoleted by RFC0953) (Status: UNKNOWN) (DOI: 10.17487/RFC0811) 0812 NICNAME/WHOIS. K. Harrenstien, V. White. March 1982. (Format: TXT, HTML) (Obsoleted by RFC0954, RFC3912) (Status: UNKNOWN) (DOI: 10.17487/RFC0812) 0813 Window and Acknowledgement Strategy in TCP. D.D. Clark. July 1982. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0813) 0814 Name, addresses, ports, and routes. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0814) 0815 IP datagram reassembly algorithms. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0815) 0816 Fault isolation and recovery. D.D. Clark. July 1982. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0816) 0817 Modularity and efficiency in protocol implementation. D.D. Clark. July 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0817) 0818 Remote User Telnet service. J. Postel. November 1982. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0818) 0819 The Domain Naming Convention for Internet User Applications. Z. Su, J. Postel. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0819) 0820 Assigned numbers. J. Postel. August 1982. (Format: TXT, HTML) (Obsoletes RFC0790) (Obsoleted by RFC0870) (Status: HISTORIC) (DOI: 10.17487/RFC0820) 0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format: TXT, HTML) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0821) 0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES. D. Crocker. August 1982. (Format: TXT, HTML) (Obsoletes RFC0733) (Obsoleted by RFC2822) (Updated by RFC1123, RFC2156, RFC1327, RFC1138, RFC1148) (Also STD0011) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0822) 0823 DARPA Internet gateway. R.M. Hinden, A. Sheltzer. September 1982. (Format: TXT, HTML) (Updates IEN109, IEN30) (Status: HISTORIC) (DOI: 10.17487/RFC0823) 0824 CRONUS Virtual Local Network. W.I. MacGregor, D.C. Tappan. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0824) 0825 Request for comments on Requests For Comments. J. Postel. November 1982. (Format: TXT, HTML) (Obsoleted by RFC1111, RFC1543, RFC2223) (Status: UNKNOWN) (DOI: 10.17487/RFC0825) 0826 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. D. Plummer. November 1982. (Format: TXT, HTML) (Updated by RFC5227, RFC5494) (Also STD0037) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0826) 0827 Exterior Gateway Protocol (EGP). E.C. Rosen. October 1982. (Format: TXT, HTML) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0827) 0828 Data communications: IFIP's international "network" of experts. K. Owen. August 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0828) 0829 Packet satellite technology reference sources. V.G. Cerf. November 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0829) 0830 Distributed system for Internet name service. Z. Su. October 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0830) 0831 Backup access to the European side of SATNET. R.T. Braden. December 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0831) 0832 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoleted by RFC0833) (Status: UNKNOWN) (DOI: 10.17487/RFC0832) 0833 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0832) (Obsoleted by RFC0834) (Status: UNKNOWN) (DOI: 10.17487/RFC0833) 0834 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0833) (Obsoleted by RFC0835) (Status: UNKNOWN) (DOI: 10.17487/RFC0834) 0835 Who talks TCP?. D. Smallberg. December 1982. (Format: TXT, HTML) (Obsoletes RFC0834) (Obsoleted by RFC0836) (Status: UNKNOWN) (DOI: 10.17487/RFC0835) 0836 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0835) (Obsoleted by RFC0837) (Status: UNKNOWN) (DOI: 10.17487/RFC0836) 0837 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0836) (Obsoleted by RFC0838) (Status: UNKNOWN) (DOI: 10.17487/RFC0837) 0838 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0837) (Obsoleted by RFC0839) (Status: UNKNOWN) (DOI: 10.17487/RFC0838) 0839 Who talks TCP?. D. Smallberg. January 1983. (Format: TXT, HTML) (Obsoletes RFC0838) (Obsoleted by RFC0842) (Status: UNKNOWN) (DOI: 10.17487/RFC0839) 0840 Official protocols. J. Postel. April 1983. (Format: TXT, HTML) (Obsoleted by RFC0880) (Status: HISTORIC) (DOI: 10.17487/RFC0840) 0841 Specification for message format for Computer Based Message Systems. National Bureau of Standards. January 1983. (Format: TXT, HTML) (Obsoletes RFC0806) (Status: UNKNOWN) (DOI: 10.17487/RFC0841) 0842 Who talks TCP? - survey of 1 February 83. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0839) (Obsoleted by RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0842) 0843 Who talks TCP? - survey of 8 February 83. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0842) (Obsoleted by RFC0845) (Updated by RFC0844) (Status: UNKNOWN) (DOI: 10.17487/RFC0843) 0844 Who talks ICMP, too? - Survey of 18 February 1983. R. Clements. February 1983. (Format: TXT, HTML) (Updates RFC0843) (Status: UNKNOWN) (DOI: 10.17487/RFC0844) 0845 Who talks TCP? - survey of 15 February 1983. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0843) (Obsoleted by RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0845) 0846 Who talks TCP? - survey of 22 February 1983. D. Smallberg. February 1983. (Format: TXT, HTML) (Obsoletes RFC0845) (Obsoleted by RFC0847) (Status: UNKNOWN) (DOI: 10.17487/RFC0846) 0847 Summary of Smallberg surveys. A. Westine, D. Smallberg, J. Postel. February 1983. (Format: TXT, HTML) (Obsoletes RFC0846) (Status: UNKNOWN) (DOI: 10.17487/RFC0847) 0848 Who provides the "little" TCP services?. D. Smallberg. March 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0848) 0849 Suggestions for improved host table distribution. M.R. Crispin. May 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0849) 0850 Standard for interchange of USENET messages. M.R. Horton. June 1983. (Format: TXT, HTML) (Obsoleted by RFC1036) (Status: UNKNOWN) (DOI: 10.17487/RFC0850) 0851 ARPANET 1822L Host Access Protocol. A.G. Malis. April 1983. (Format: TXT, HTML) (Obsoletes RFC0802) (Obsoleted by RFC0878) (Status: UNKNOWN) (DOI: 10.17487/RFC0851) 0852 ARPANET short blocking feature. A.G. Malis. April 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0852) 0853 Not Issued. 0854 Telnet Protocol Specification. J. Postel, J.K. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes RFC0764) (Updated by RFC5198) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0854) 0855 Telnet Option Specifications. J. Postel, J.K. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC18640) (Also STD0008) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0855) 0856 Telnet Binary Transmission. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15389) (Also STD0027) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0856) 0857 Telnet Echo Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15390) (Also STD0028) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0857) 0858 Telnet Suppress Go Ahead Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC15392) (Also STD0029) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0858) 0859 Telnet Status Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes RFC0651) (Also STD0030) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0859) 0860 Telnet Timing Mark Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC16238) (Also STD0031) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0860) 0861 Telnet Extended Options: List Option. J. Postel, J. Reynolds. May 1983. (Format: TXT, HTML) (Obsoletes NIC16239) (Also STD0032) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0861) 0862 Echo Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0020) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0862) 0863 Discard Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0021) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0863) 0864 Character Generator Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0022) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0864) 0865 Quote of the Day Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0023) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0865) 0866 Active users. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0024) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0866) 0867 Daytime Protocol. J. Postel. May 1983. (Format: TXT, HTML) (Also STD0025) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0867) 0868 Time Protocol. J. Postel, K. Harrenstien. May 1983. (Format: TXT, HTML) (Also STD0026) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0868) 0869 Host Monitoring Protocol. R. Hinden. December 1983. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0869) 0870 Assigned numbers. J.K. Reynolds, J. Postel. October 1983. (Format: TXT, HTML) (Obsoletes RFC0820) (Obsoleted by RFC0900) (Status: HISTORIC) (DOI: 10.17487/RFC0870) 0871 Perspective on the ARPANET reference model. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0871) 0872 TCP-on-a-LAN. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0872) 0873 Illusion of vendor support. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0873) 0874 Critique of X.25. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0874) 0875 Gateways, architectures, and heffalumps. M.A. Padlipsky. September 1982. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0875) 0876 Survey of SMTP implementations. D. Smallberg. September 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0876) 0877 Standard for the transmission of IP datagrams over public data networks. J.T. Korb. September 1983. (Format: TXT, HTML) (Obsoleted by RFC1356) (Status: UNKNOWN) (DOI: 10.17487/RFC0877) 0878 ARPANET 1822L Host Access Protocol. A.G. Malis. December 1983. (Format: TXT, HTML) (Obsoletes RFC0851) (Status: UNKNOWN) (DOI: 10.17487/RFC0878) 0879 The TCP Maximum Segment Size and Related Topics. J. Postel. November 1983. (Format: TXT, HTML) (Obsoleted by RFC7805) (Updated by RFC6691) (Status: HISTORIC) (DOI: 10.17487/RFC0879) 0880 Official protocols. J.K. Reynolds, J. Postel. October 1983. (Format: TXT, HTML) (Obsoletes RFC0840) (Obsoleted by RFC0901) (Status: HISTORIC) (DOI: 10.17487/RFC0880) 0881 Domain names plan and schedule. J. Postel. November 1983. (Format: TXT, HTML) (Updated by RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0881) 0882 Domain names: Concepts and facilities. P.V. Mockapetris. November 1983. (Format: TXT, HTML) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN) (DOI: 10.17487/RFC0882) 0883 Domain names: Implementation specification. P.V. Mockapetris. November 1983. (Format: TXT, HTML) (Obsoleted by RFC1034, RFC1035) (Updated by RFC0973) (Status: UNKNOWN) (DOI: 10.17487/RFC0883) 0884 Telnet terminal type option. M. Solomon, E. Wimmers. December 1983. (Format: TXT, HTML) (Obsoleted by RFC0930) (Status: UNKNOWN) (DOI: 10.17487/RFC0884) 0885 Telnet end of record option. J. Postel. December 1983. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0885) 0886 Proposed standard for message header munging. M.T. Rose. December 1983. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0886) 0887 Resource Location Protocol. M. Accetta. December 1983. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0887) 0888 "STUB" Exterior Gateway Protocol. L. Seamonson, E.C. Rosen. January 1984. (Format: TXT, HTML) (Updated by RFC0904) (Status: UNKNOWN) (DOI: 10.17487/RFC0888) 0889 Internet Delay Experiments. D.L. Mills. December 1983. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0889) 0890 Exterior Gateway Protocol implementation schedule. J. Postel. February 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0890) 0891 DCN Local-Network Protocols. D.L. Mills. December 1983. (Format: TXT, HTML) (Also STD0044) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0891) 0892 ISO Transport Protocol specification. International Organization for Standardization. December 1983. (Format: TXT, HTML) (Obsoleted by RFC0905) (Status: UNKNOWN) (DOI: 10.17487/RFC0892) 0893 Trailer encapsulations. S. Leffler, M.J. Karels. April 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0893) 0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks. C. Hornig. April 1984. (Format: TXT, HTML) (Also STD0041) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0894) 0895 Standard for the transmission of IP datagrams over experimental Ethernet networks. J. Postel. April 1984. (Format: TXT, HTML) (Also STD0042) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0895) 0896 Congestion Control in IP/TCP Internetworks. J. Nagle. January 1984. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC0896) 0897 Domain name system implementation schedule. J. Postel. February 1984. (Format: TXT, HTML) (Updates RFC0881) (Updated by RFC0921) (Status: UNKNOWN) (DOI: 10.17487/RFC0897) 0898 Gateway special interest group meeting notes. R.M. Hinden, J. Postel, M. Muuss, J.K. Reynolds. April 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0898) 0899 Request For Comments summary notes: 800-899. J. Postel, A. Westine. May 1984. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0899) 0900 Assigned Numbers. J.K. Reynolds, J. Postel. June 1984. (Format: TXT, HTML) (Obsoletes RFC0870) (Obsoleted by RFC0923) (Status: HISTORIC) (DOI: 10.17487/RFC0900) 0901 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. June 1984. (Format: TXT, HTML) (Obsoletes RFC0880) (Obsoleted by RFC0924) (Status: UNKNOWN) (DOI: 10.17487/RFC0901) 0902 ARPA Internet Protocol policy. J.K. Reynolds, J. Postel. July 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0902) 0903 A Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. June 1984. (Format: TXT, HTML) (Also STD0038) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0903) 0904 Exterior Gateway Protocol formal specification. D.L. Mills. April 1984. (Format: TXT, HTML) (Updates RFC0827, RFC0888) (Status: HISTORIC) (DOI: 10.17487/RFC0904) 0905 ISO Transport Protocol specification ISO DP 8073. ISO. April 1984. (Format: TXT, HTML) (Obsoletes RFC0892) (Status: UNKNOWN) (DOI: 10.17487/RFC0905) 0906 Bootstrap loading using TFTP. R. Finlayson. June 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0906) 0907 Host Access Protocol specification. Bolt Beranek, Newman Laboratories. July 1984. (Format: TXT, HTML) (Updated by RFC1221) (Also STD0040) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0907) 0908 Reliable Data Protocol. D. Velten, R.M. Hinden, J. Sax. July 1984. (Format: TXT, HTML) (Updated by RFC1151) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0908) 0909 Loader Debugger Protocol. C. Welles, W. Milliken. July 1984. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0909) 0910 Multimedia mail meeting notes. H.C. Forsdick. August 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0910) 0911 EGP Gateway under Berkeley UNIX 4.2. P. Kirton. August 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0911) 0912 Authentication service. M. St. Johns. September 1984. (Format: TXT, HTML) (Obsoleted by RFC0931) (Status: UNKNOWN) (DOI: 10.17487/RFC0912) 0913 Simple File Transfer Protocol. M. Lottor. September 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0913) 0914 Thinwire protocol for connecting personal computers to the Internet. D.J. Farber, G. Delp, T.M. Conte. September 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0914) 0915 Network mail path service. M.A. Elvy, R. Nedved. December 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0915) 0916 Reliable Asynchronous Transfer Protocol (RATP). G.G. Finn. October 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0916) 0917 Internet subnets. J.C. Mogul. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0917) 0918 Post Office Protocol. J.K. Reynolds. October 1984. (Format: TXT, HTML) (Obsoleted by RFC0937) (Status: UNKNOWN) (DOI: 10.17487/RFC0918) 0919 Broadcasting Internet Datagrams. J.C. Mogul. October 1984. (Format: TXT, HTML) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0919) 0920 Domain requirements. J. Postel, J.K. Reynolds. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0920) 0921 Domain name system implementation schedule - revised. J. Postel. October 1984. (Format: TXT, HTML) (Updates RFC0897) (Status: UNKNOWN) (DOI: 10.17487/RFC0921) 0922 Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. October 1984. (Format: TXT, HTML) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0922) 0923 Assigned numbers. J.K. Reynolds, J. Postel. October 1984. (Format: TXT, HTML) (Obsoletes RFC0900) (Obsoleted by RFC0943) (Status: HISTORIC) (DOI: 10.17487/RFC0923) 0924 Official ARPA-Internet protocols for connecting personal computers to the Internet. J.K. Reynolds, J. Postel. October 1984. (Format: TXT, HTML) (Obsoletes RFC0901) (Obsoleted by RFC0944) (Status: UNKNOWN) (DOI: 10.17487/RFC0924) 0925 Multi-LAN address resolution. J. Postel. October 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0925) 0926 Protocol for providing the connectionless mode network services. International Organization for Standardization. December 1984. (Format: TXT, HTML) (Obsoleted by RFC0994) (Status: UNKNOWN) (DOI: 10.17487/RFC0926) 0927 TACACS user identification Telnet option. B.A. Anderson. December 1984. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0927) 0928 Introduction to proposed DoD standard H-FP. M.A. Padlipsky. December 1984. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0928) 0929 Proposed Host-Front End Protocol. J. Lilienkamp, R. Mandell, M.A. Padlipsky. December 1984. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0929) 0930 Telnet terminal type option. M. Solomon, E. Wimmers. January 1985. (Format: TXT, HTML) (Obsoletes RFC0884) (Obsoleted by RFC1091) (Status: UNKNOWN) (DOI: 10.17487/RFC0930) 0931 Authentication server. M. St. Johns. January 1985. (Format: TXT, HTML) (Obsoletes RFC0912) (Obsoleted by RFC1413) (Status: UNKNOWN) (DOI: 10.17487/RFC0931) 0932 Subnetwork addressing scheme. D.D. Clark. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0932) 0933 Output marking Telnet option. S. Silverman. January 1985. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0933) 0934 Proposed standard for message encapsulation. M.T. Rose, E.A. Stefferud. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0934) 0935 Reliable link layer protocols. J.G. Robinson. January 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0935) 0936 Another Internet subnet addressing scheme. M.J. Karels. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0936) 0937 Post Office Protocol: Version 2. M. Butler, J. Postel, D. Chase, J. Goldberger, J.K. Reynolds. February 1985. (Format: TXT, HTML) (Obsoletes RFC0918) (Status: HISTORIC) (DOI: 10.17487/RFC0937) 0938 Internet Reliable Transaction Protocol functional and interface specification. T. Miller. February 1985. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0938) 0939 Executive summary of the NRC report on transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0939) 0940 Toward an Internet standard scheme for subnetting. Gateway Algorithms and Data Structures Task Force. April 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0940) 0941 Addendum to the network service definition covering network layer addressing. International Organization for Standardization. April 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0941) 0942 Transport protocols for Department of Defense data networks. National Research Council. February 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0942) 0943 Assigned numbers. J.K. Reynolds, J. Postel. April 1985. (Format: TXT, HTML) (Obsoletes RFC0923) (Obsoleted by RFC0960) (Status: HISTORIC) (DOI: 10.17487/RFC0943) 0944 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. April 1985. (Format: TXT, HTML) (Obsoletes RFC0924) (Obsoleted by RFC0961) (Status: UNKNOWN) (DOI: 10.17487/RFC0944) 0945 DoD statement on the NRC report. J. Postel. May 1985. (Format: TXT, HTML) (Obsoleted by RFC1039) (Status: UNKNOWN) (DOI: 10.17487/RFC0945) 0946 Telnet terminal location number option. R. Nedved. May 1985. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0946) 0947 Multi-network broadcasting within the Internet. K. Lebowitz, D. Mankins. June 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0947) 0948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks. I. Winston. June 1985. (Format: TXT, HTML) (Obsoleted by RFC1042) (Status: UNKNOWN) (DOI: 10.17487/RFC0948) 0949 FTP unique-named store command. M.A. Padlipsky. July 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0949) 0950 Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. August 1985. (Format: TXT, HTML) (Updates RFC0792) (Updated by RFC6918) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0950) 0951 Bootstrap Protocol. W.J. Croft, J. Gilmore. September 1985. (Format: TXT, HTML) (Updated by RFC1395, RFC1497, RFC1532, RFC1542, RFC5494) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC0951) 0952 DoD Internet host table specification. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (Obsoletes RFC0810) (Updated by RFC1123) (Status: UNKNOWN) (DOI: 10.17487/RFC0952) 0953 Hostname Server. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (Obsoletes RFC0811) (Status: HISTORIC) (DOI: 10.17487/RFC0953) 0954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. October 1985. (Format: TXT, HTML) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC0954) 0955 Towards a transport service for transaction processing applications. R.T. Braden. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0955) 0956 Algorithms for synchronizing network clocks. D.L. Mills. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0956) 0957 Experiments in network clock synchronization. D.L. Mills. September 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0957) 0958 Network Time Protocol (NTP). D.L. Mills. September 1985. (Format: TXT, HTML) (Obsoleted by RFC1059, RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC0958) 0959 File Transfer Protocol. J. Postel, J. Reynolds. October 1985. (Format: TXT, HTML) (Obsoletes RFC0765) (Updated by RFC2228, RFC2640, RFC2773, RFC3659, RFC5797, RFC7151) (Also STD0009) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC0959) 0960 Assigned numbers. J.K. Reynolds, J. Postel. December 1985. (Format: TXT, HTML) (Obsoletes RFC0943) (Obsoleted by RFC0990) (Status: HISTORIC) (DOI: 10.17487/RFC0960) 0961 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. December 1985. (Format: TXT, HTML) (Obsoletes RFC0944) (Obsoleted by RFC0991) (Status: UNKNOWN) (DOI: 10.17487/RFC0961) 0962 TCP-4 prime. M.A. Padlipsky. November 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0962) 0963 Some problems with the specification of the Military Standard Internet Protocol. D.P. Sidhu. November 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0963) 0964 Some problems with the specification of the Military Standard Transmission Control Protocol. D.P. Sidhu, T. Blumer. November 1985. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC0964) 0965 Format for a graphical communication protocol. L. Aguilar. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0965) 0966 Host groups: A multicast extension to the Internet Protocol. S.E. Deering, D.R. Cheriton. December 1985. (Format: TXT, HTML) (Obsoleted by RFC0988) (Status: UNKNOWN) (DOI: 10.17487/RFC0966) 0967 All victims together. M.A. Padlipsky. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0967) 0968 Twas the night before start-up. V.G. Cerf. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0968) 0969 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, L. Zhang. December 1985. (Format: TXT, HTML) (Obsoleted by RFC0998) (Status: UNKNOWN) (DOI: 10.17487/RFC0969) 0970 On Packet Switches With Infinite Storage. J. Nagle. December 1985. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0970) 0971 Survey of data representation standards. A.L. DeSchon. January 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0971) 0972 Password Generator Protocol. F.J. Wancho. January 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0972) 0973 Domain system changes and observations. P.V. Mockapetris. January 1986. (Format: TXT, HTML) (Obsoleted by RFC1034, RFC1035) (Updates RFC0882, RFC0883) (Status: UNKNOWN) (DOI: 10.17487/RFC0973) 0974 Mail routing and the domain system. C. Partridge. January 1986. (Format: TXT, HTML) (Obsoleted by RFC2821) (Also STD0010) (Status: HISTORIC) (DOI: 10.17487/RFC0974) 0975 Autonomous confederations. D.L. Mills. February 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0975) 0976 UUCP mail interchange format standard. M.R. Horton. February 1986. (Format: TXT, HTML) (Updated by RFC1137) (Status: UNKNOWN) (DOI: 10.17487/RFC0976) 0977 Network News Transfer Protocol. B. Kantor, P. Lapsley. February 1986. (Format: TXT, HTML) (Obsoleted by RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC0977) 0978 Voice File Interchange Protocol (VFIP). J.K. Reynolds, R. Gillman, W.A. Brackenridge, A. Witkowski, J. Postel. February 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0978) 0979 PSN End-to-End functional specification. A.G. Malis. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0979) 0980 Protocol document order information. O.J. Jacobsen, J. Postel. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0980) 0981 Experimental multiple-path routing algorithm. D.L. Mills. March 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0981) 0982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address. H.W. Braun. April 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0982) 0983 ISO transport arrives on top of the TCP. D.E. Cass, M.T. Rose. April 1986. (Format: TXT, HTML) (Obsoleted by RFC1006) (Status: UNKNOWN) (DOI: 10.17487/RFC0983) 0984 PCMAIL: A distributed mail system for personal computers. D.D. Clark, M.L. Lambert. May 1986. (Format: TXT, HTML) (Obsoleted by RFC0993) (Status: UNKNOWN) (DOI: 10.17487/RFC0984) 0985 Requirements for Internet gateways - draft. National Science Foundation, Network Technical Advisory Group. May 1986. (Format: TXT, HTML) (Obsoleted by RFC1009) (Status: UNKNOWN) (DOI: 10.17487/RFC0985) 0986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun. June 1986. (Format: TXT, HTML) (Obsoleted by RFC1069) (Status: UNKNOWN) (DOI: 10.17487/RFC0986) 0987 Mapping between X.400 and RFC 822. S.E. Kille. June 1986. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updated by RFC1026, RFC1138, RFC1148) (Status: UNKNOWN) (DOI: 10.17487/RFC0987) 0988 Host extensions for IP multicasting. S.E. Deering. July 1986. (Format: TXT, HTML) (Obsoletes RFC0966) (Obsoleted by RFC1054, RFC1112) (Status: UNKNOWN) (DOI: 10.17487/RFC0988) 0989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures. J. Linn. February 1987. (Format: TXT, HTML) (Obsoleted by RFC1040, RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC0989) 0990 Assigned numbers. J.K. Reynolds, J. Postel. November 1986. (Format: TXT, HTML) (Obsoletes RFC0960) (Obsoleted by RFC1010) (Updated by RFC0997) (Status: HISTORIC) (DOI: 10.17487/RFC0990) 0991 Official ARPA-Internet protocols. J.K. Reynolds, J. Postel. November 1986. (Format: TXT, HTML) (Obsoletes RFC0961) (Obsoleted by RFC1011) (Status: UNKNOWN) (DOI: 10.17487/RFC0991) 0992 On communication support for fault tolerant process groups. K.P. Birman, T.A. Joseph. November 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0992) 0993 PCMAIL: A distributed mail system for personal computers. D.D. Clark, M.L. Lambert. December 1986. (Format: TXT, HTML) (Obsoletes RFC0984) (Obsoleted by RFC1056) (Status: UNKNOWN) (DOI: 10.17487/RFC0993) 0994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service. International Organization for Standardization. March 1986. (Format: TXT, HTML) (Obsoletes RFC0926) (Status: UNKNOWN) (DOI: 10.17487/RFC0994) 0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473. International Organization for Standardization. April 1986. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC0995) 0996 Statistics server. D.L. Mills. February 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC0996) 0997 Internet numbers. J.K. Reynolds, J. Postel. March 1987. (Format: TXT, HTML) (Obsoleted by RFC1020, RFC1117) (Updates RFC0990) (Status: UNKNOWN) (DOI: 10.17487/RFC0997) 0998 NETBLT: A bulk data transfer protocol. D.D. Clark, M.L. Lambert, L. Zhang. March 1987. (Format: TXT, HTML) (Obsoletes RFC0969) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC0998) 0999 Requests For Comments summary notes: 900-999. A. Westine, J. Postel. April 1987. (Format: TXT, HTML) (Obsoletes RFC0160) (Obsoleted by RFC1000) (Status: UNKNOWN) (DOI: 10.17487/RFC0999) 1000 Request For Comments reference guide. J.K. Reynolds, J. Postel. August 1987. (Format: TXT, HTML) (Obsoletes RFC0999) (Status: UNKNOWN) (DOI: 10.17487/RFC1000) 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. March 1987. (Format: TXT, HTML) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1001) 1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications. NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. March 1987. (Format: TXT, HTML) (Also STD0019) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1002) 1003 Issues in defining an equations representation standard. A.R. Katz. March 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1003) 1004 Distributed-protocol authentication scheme. D.L. Mills. April 1987. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1004) 1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP). A. Khanna, A.G. Malis. May 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1005) 1006 ISO Transport Service on top of the TCP Version: 3. M.T. Rose, D.E. Cass. May 1987. (Format: TXT, HTML) (Obsoletes RFC0983) (Updated by RFC2126) (Also STD0035) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1006) 1007 Military supplement to the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1007) 1008 Implementation guide for the ISO Transport Protocol. W. McCoy. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1008) 1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT, HTML) (Obsoletes RFC0985) (Obsoleted by RFC1812) (Status: HISTORIC) (DOI: 10.17487/RFC1009) 1010 Assigned numbers. J.K. Reynolds, J. Postel. May 1987. (Format: TXT, HTML) (Obsoletes RFC0990) (Obsoleted by RFC1060) (Status: HISTORIC) (DOI: 10.17487/RFC1010) 1011 Official Internet protocols. J.K. Reynolds, J. Postel. May 1987. (Format: TXT, HTML) (Obsoletes RFC0991) (Updated by RFC6093) (Status: UNKNOWN) (DOI: 10.17487/RFC1011) 1012 Bibliography of Request For Comments 1 through 999. J.K. Reynolds, J. Postel. June 1987. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1012) 1013 X Window System Protocol, version 11: Alpha update April 1987. R.W. Scheifler. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1013) 1014 XDR: External Data Representation standard. Sun Microsystems. June 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1014) 1015 Implementation plan for interagency research Internet. B.M. Leiner. July 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1015) 1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID). W. Prue, J. Postel. July 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1016) 1017 Network requirements for scientific research: Internet task force on scientific computing. B.M. Leiner. August 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1017) 1018 Some comments on SQuID. A.M. McKenzie. August 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1018) 1019 Report of the Workshop on Environments for Computational Mathematics. D. Arnon. September 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1019) 1020 Internet numbers. S. Romano, M.K. Stahl. November 1987. (Format: TXT, HTML) (Obsoletes RFC0997) (Obsoleted by RFC1062, RFC1117, RFC1166) (Status: UNKNOWN) (DOI: 10.17487/RFC1020) 1021 High-level Entity Management System (HEMS). C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1021) 1022 High-level Entity Management Protocol (HEMP). C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1022) 1023 HEMS monitoring and control language. G. Trewitt, C. Partridge. October 1987. (Format: TXT, HTML) (Obsoleted by RFC1076) (Status: UNKNOWN) (DOI: 10.17487/RFC1023) 1024 HEMS variable definitions. C. Partridge, G. Trewitt. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1024) 1025 TCP and IP bake off. J. Postel. September 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1025) 1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822). S.E. Kille. September 1987. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updates RFC0987) (Updated by RFC1138, RFC1148) (Status: UNKNOWN) (DOI: 10.17487/RFC1026) 1027 Using ARP to implement transparent subnet gateways. S. Carl-Mitchell, J.S. Quarterman. October 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1027) 1028 Simple Gateway Monitoring Protocol. J. Davin, J.D. Case, M. Fedor, M.L. Schoffstall. November 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1028) 1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets. G. Parr. May 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1029) 1030 On testing the NETBLT Protocol over divers networks. M.L. Lambert. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1030) 1031 MILNET name domain transition. W.D. Lazear. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1031) 1032 Domain administrators guide. M.K. Stahl. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1032) 1033 Domain Administrators Operations Guide. M. Lottor. November 1987. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1033) 1034 Domain names - concepts and facilities. P.V. Mockapetris. November 1987. (Format: TXT, HTML) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936, RFC8020, RFC8482, RFC8767) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1034) 1035 Domain names - implementation and specification. P.V. Mockapetris. November 1987. (Format: TXT, HTML) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2673, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035, RFC4343, RFC5936, RFC5966, RFC6604, RFC7766, RFC8482, RFC8490, RFC8767) (Also STD0013) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1035) 1036 Standard for interchange of USENET messages. M.R. Horton, R. Adams. December 1987. (Format: TXT, HTML) (Obsoletes RFC0850) (Obsoleted by RFC5536, RFC5537) (Status: UNKNOWN) (DOI: 10.17487/RFC1036) 1037 NFILE - a file access protocol. B. Greenberg, S. Keene. December 1987. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1037) 1038 Draft revised IP security option. M. St. Johns. January 1988. (Format: TXT, HTML) (Obsoleted by RFC1108) (Status: UNKNOWN) (DOI: 10.17487/RFC1038) 1039 DoD statement on Open Systems Interconnection protocols. D. Latham. January 1988. (Format: TXT, HTML) (Obsoletes RFC0945) (Status: UNKNOWN) (DOI: 10.17487/RFC1039) 1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures. J. Linn. January 1988. (Format: TXT, HTML) (Obsoletes RFC0989) (Obsoleted by RFC1113) (Status: UNKNOWN) (DOI: 10.17487/RFC1040) 1041 Telnet 3270 regime option. Y. Rekhter. January 1988. (Format: TXT, HTML) (Updated by RFC6270) (Status: HISTORIC) (DOI: 10.17487/RFC1041) 1042 Standard for the transmission of IP datagrams over IEEE 802 networks. J. Postel, J.K. Reynolds. February 1988. (Format: TXT, HTML) (Obsoletes RFC0948) (Also STD0043) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1042) 1043 Telnet Data Entry Terminal option: DODIIS implementation. A. Yasuda, T. Thompson. February 1988. (Format: TXT, HTML) (Updates RFC0732) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1043) 1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification. K. Hardwick, J. Lekashman. February 1988. (Format: TXT, HTML) (Updated by RFC5494) (Also STD0045) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1044) 1045 VMTP: Versatile Message Transaction Protocol: Protocol specification. D.R. Cheriton. February 1988. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1045) 1046 Queuing algorithm to provide type-of-service for IP links. W. Prue, J. Postel. February 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1046) 1047 Duplicate messages and SMTP. C. Partridge. February 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1047) 1048 BOOTP vendor information extensions. P.A. Prindeville. February 1988. (Format: TXT, HTML) (Obsoleted by RFC1084, RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) (DOI: 10.17487/RFC1048) 1049 Content-type header field for Internet messages. M.A. Sirbu. March 1988. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1049) 1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems. April 1988. (Format: TXT, HTML) (Obsoleted by RFC1057) (Status: HISTORIC) (DOI: 10.17487/RFC1050) 1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks. P.A. Prindeville. March 1988. (Format: TXT, HTML) (Obsoleted by RFC1201) (Status: HISTORIC) (DOI: 10.17487/RFC1051) 1052 IAB recommendations for the development of Internet network management standards. V.G. Cerf. April 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1052) 1053 Telnet X.3 PAD option. S. Levy, T. Jacobson. April 1988. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1053) 1054 Host extensions for IP multicasting. S.E. Deering. May 1988. (Format: TXT, HTML) (Obsoletes RFC0988) (Obsoleted by RFC1112) (Status: UNKNOWN) (DOI: 10.17487/RFC1054) 1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP. J.L. Romkey. June 1988. (Format: TXT, HTML) (Also STD0047) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1055) 1056 PCMAIL: A distributed mail system for personal computers. M.L. Lambert. June 1988. (Format: TXT, HTML) (Obsoletes RFC0993) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1056) 1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems. June 1988. (Format: TXT, HTML) (Obsoletes RFC1050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1057) 1058 Routing Information Protocol. C.L. Hedrick. June 1988. (Format: TXT, HTML) (Updated by RFC1388, RFC1723) (Status: HISTORIC) (DOI: 10.17487/RFC1058) 1059 Network Time Protocol (version 1) specification and implementation. D.L. Mills. July 1988. (Format: TXT, HTML) (Obsoletes RFC0958) (Obsoleted by RFC1119, RFC1305) (Status: UNKNOWN) (DOI: 10.17487/RFC1059) 1060 Assigned numbers. J.K. Reynolds, J. Postel. March 1990. (Format: TXT, HTML) (Obsoletes RFC1010) (Obsoleted by RFC1340) (Updated by RFC1349) (Status: HISTORIC) (DOI: 10.17487/RFC1060) 1061 Not Issued. 1062 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1988. (Format: TXT, HTML) (Obsoletes RFC1020) (Obsoleted by RFC1117, RFC1166) (Status: UNKNOWN) (DOI: 10.17487/RFC1062) 1063 IP MTU discovery options. J.C. Mogul, C.A. Kent, C. Partridge, K. McCloghrie. July 1988. (Format: TXT, HTML) (Obsoleted by RFC1191) (Status: UNKNOWN) (DOI: 10.17487/RFC1063) 1064 Interactive Mail Access Protocol: Version 2. M.R. Crispin. July 1988. (Format: TXT, HTML) (Obsoleted by RFC1176, RFC1203) (Status: UNKNOWN) (DOI: 10.17487/RFC1064) 1065 Structure and identification of management information for TCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT, HTML) (Obsoleted by RFC1155) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1065) 1066 Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT, HTML) (Obsoleted by RFC1156) (Status: UNKNOWN) (DOI: 10.17487/RFC1066) 1067 Simple Network Management Protocol. J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. August 1988. (Format: TXT, HTML) (Obsoleted by RFC1098) (Status: UNKNOWN) (DOI: 10.17487/RFC1067) 1068 Background File Transfer Program (BFTP). A.L. DeSchon, R.T. Braden. August 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1068) 1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol. R.W. Callon, H.W. Braun. February 1989. (Format: TXT, HTML) (Obsoletes RFC0986) (Status: UNKNOWN) (DOI: 10.17487/RFC1069) 1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer. R.A. Hagens, N.E. Hall, M.T. Rose. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1070) 1071 Computing the Internet checksum. R.T. Braden, D.A. Borman, C. Partridge. September 1988. (Format: TXT, HTML) (Updated by RFC1141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1071) 1072 TCP extensions for long-delay paths. V. Jacobson, R.T. Braden. October 1988. (Format: TXT, HTML) (Obsoleted by RFC1323, RFC2018, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1072) 1073 Telnet window size option. D. Waitzman. October 1988. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1073) 1074 NSFNET backbone SPF based Interior Gateway Protocol. J. Rekhter. October 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1074) 1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C. Partridge, S.E. Deering. November 1988. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1075) 1076 HEMS monitoring and control language. G. Trewitt, C. Partridge. November 1988. (Format: TXT, HTML) (Obsoletes RFC1023) (Status: UNKNOWN) (DOI: 10.17487/RFC1076) 1077 Critical issues in high bandwidth networking. B.M. Leiner. November 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1077) 1078 TCP port service Multiplexer (TCPMUX). M. Lottor. November 1988. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC1078) 1079 Telnet terminal speed option. C.L. Hedrick. December 1988. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1079) 1080 Telnet remote flow control option. C.L. Hedrick. November 1988. (Format: TXT, HTML) (Obsoleted by RFC1372) (Status: UNKNOWN) (DOI: 10.17487/RFC1080) 1081 Post Office Protocol: Version 3. M.T. Rose. November 1988. (Format: TXT, HTML) (Obsoleted by RFC1225) (Status: UNKNOWN) (DOI: 10.17487/RFC1081) 1082 Post Office Protocol: Version 3: Extended service offerings. M.T. Rose. November 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1082) 1083 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. December 1988. (Format: TXT, HTML) (Obsoleted by RFC1100) (Status: HISTORIC) (DOI: 10.17487/RFC1083) 1084 BOOTP vendor information extensions. J.K. Reynolds. December 1988. (Format: TXT, HTML) (Obsoletes RFC1048) (Obsoleted by RFC1395, RFC1497, RFC1533) (Status: UNKNOWN) (DOI: 10.17487/RFC1084) 1085 ISO presentation services on top of TCP/IP based internets. M.T. Rose. December 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1085) 1086 ISO-TP0 bridge between TCP and X.25. J.P. Onions, M.T. Rose. December 1988. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1086) 1087 Ethics and the Internet. Defense Advanced Research Projects Agency, Internet Activities Board. January 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1087) 1088 Standard for the transmission of IP datagrams over NetBIOS networks. L.J. McLaughlin. February 1989. (Format: TXT, HTML) (Also STD0048) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1088) 1089 SNMP over Ethernet. M. Schoffstall, C. Davin, M. Fedor, J. Case. February 1989. (Format: TXT, HTML) (Obsoleted by RFC4789) (Status: UNKNOWN) (DOI: 10.17487/RFC1089) 1090 SMTP on X.25. R. Ullmann. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1090) 1091 Telnet terminal-type option. J. VanBokkelen. February 1989. (Format: TXT, HTML) (Obsoletes RFC0930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1091) 1092 EGP and policy based routing in the new NSFNET backbone. J. Rekhter. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1092) 1093 NSFNET routing architecture. H.W. Braun. February 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1093) 1094 NFS: Network File System Protocol specification. B. Nowicki. March 1989. (Format: TXT, HTML) (Also RFC1813) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1094) 1095 Common Management Information Services and Protocol over TCP/IP (CMOT). U.S. Warrier, L. Besaw. April 1989. (Format: TXT, HTML) (Obsoleted by RFC1189) (Status: UNKNOWN) (DOI: 10.17487/RFC1095) 1096 Telnet X display location option. G.A. Marcy. March 1989. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1096) 1097 Telnet subliminal-message option. B. Miller. 1 April 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1097) 1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. April 1989. (Format: TXT, HTML) (Obsoletes RFC1067) (Obsoleted by RFC1157) (Status: UNKNOWN) (DOI: 10.17487/RFC1098) 1099 Request for Comments Summary: RFC Numbers 1000-1099. J. Reynolds. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1099) 1100 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1989. (Format: TXT, HTML) (Obsoletes RFC1083) (Obsoleted by RFC1130) (Status: HISTORIC) (DOI: 10.17487/RFC1100) 1101 DNS encoding of network names and other types. P.V. Mockapetris. April 1989. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: UNKNOWN) (DOI: 10.17487/RFC1101) 1102 Policy routing in Internet protocols. D.D. Clark. May 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1102) 1103 Proposed standard for the transmission of IP datagrams over FDDI Networks. D. Katz. June 1989. (Format: TXT, HTML) (Obsoleted by RFC1188) (Status: UNKNOWN) (DOI: 10.17487/RFC1103) 1104 Models of policy based routing. H.W. Braun. June 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1104) 1105 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1989. (Format: TXT, HTML) (Obsoleted by RFC1163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1105) 1106 TCP big window and NAK options. R. Fox. June 1989. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1106) 1107 Plan for Internet directory services. K.R. Sollins. July 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1107) 1108 U.S. Department of Defense Security Options for the Internet Protocol. S. Kent. November 1991. (Format: TXT, HTML) (Obsoletes RFC1038) (Status: HISTORIC) (DOI: 10.17487/RFC1108) 1109 Report of the second Ad Hoc Network Management Review Group. V.G. Cerf. August 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1109) 1110 Problem with the TCP big window option. A.M. McKenzie. August 1989. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1110) 1111 Request for comments on Request for Comments: Instructions to RFC authors. J. Postel. August 1989. (Format: TXT, HTML) (Obsoletes RFC0825) (Obsoleted by RFC1543, RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1111) 1112 Host extensions for IP multicasting. S.E. Deering. August 1989. (Format: TXT, HTML) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1112) 1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures. J. Linn. August 1989. (Format: TXT, HTML) (Obsoletes RFC0989, RFC1040) (Obsoleted by RFC1421) (Status: HISTORIC) (DOI: 10.17487/RFC1113) 1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management. S.T. Kent, J. Linn. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1422) (Status: HISTORIC) (DOI: 10.17487/RFC1114) 1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers. J. Linn. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1423) (Status: HISTORIC) (DOI: 10.17487/RFC1115) 1116 Telnet Linemode option. D.A. Borman. August 1989. (Format: TXT, HTML) (Obsoleted by RFC1184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1116) 1117 Internet numbers. S. Romano, M.K. Stahl, M. Recker. August 1989. (Format: TXT, HTML) (Obsoletes RFC1062, RFC1020, RFC0997) (Obsoleted by RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1117) 1118 Hitchhikers guide to the Internet. E. Krol. September 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1118) 1119 Network Time Protocol (version 2) specification and implementation. D.L. Mills. September 1989. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC0958, RFC1059) (Obsoleted by RFC1305) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1119) 1120 Internet Activities Board. V. Cerf. September 1989. (Format: TXT, HTML) (Obsoleted by RFC1160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1120) 1121 Act one - the poems. J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm. September 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1121) 1122 Requirements for Internet Hosts - Communication Layers. R. Braden, Ed.. October 1989. (Format: TXT, HTML) (Updates RFC0793) (Updated by RFC1349, RFC4379, RFC5884, RFC6093, RFC6298, RFC6633, RFC6864, RFC8029) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1122) 1123 Requirements for Internet Hosts - Application and Support. R. Braden, Ed.. October 1989. (Format: TXT, HTML) (Updates RFC0822, RFC0952) (Updated by RFC1349, RFC2181, RFC5321, RFC5966, RFC7766) (Also STD0003) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1123) 1124 Policy issues in interconnecting networks. B.M. Leiner. September 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1124) 1125 Policy requirements for inter Administrative Domain routing. D. Estrin. November 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1125) 1126 Goals and functional requirements for inter-autonomous system routing. M. Little. October 1989. (Format: TXT, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1126) 1127 Perspective on the Host Requirements RFCs. R.T. Braden. October 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1127) 1128 Measured performance of the Network Time Protocol in the Internet system. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (Status: UNKNOWN) (DOI: 10.17487/RFC1128) 1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. October 1989. (Format: TXT, PS, PDF, HTML) (Also RFC1119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1129) 1130 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. October 1989. (Format: TXT, HTML) (Obsoletes RFC1100) (Obsoleted by RFC1140) (Status: HISTORIC) (DOI: 10.17487/RFC1130) 1131 OSPF specification. J. Moy. October 1989. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1131) 1132 Standard for the transmission of 802.2 packets over IPX networks. L.J. McLaughlin. November 1989. (Format: TXT, HTML) (Also STD0049) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1132) 1133 Routing between the NSFNET and the DDN. J.Y. Yu, H.W. Braun. November 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1133) 1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links. D. Perkins. November 1989. (Format: TXT, HTML) (Obsoleted by RFC1171) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1134) 1135 Helminthiasis of the Internet. J.K. Reynolds. December 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1135) 1136 Administrative Domains and Routing Domains: A model for routing in the Internet. S. Hares, D. Katz. December 1989. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1136) 1137 Mapping between full RFC 822 and RFC 822 with restricted encoding. S. Kille. December 1989. (Format: TXT, HTML) (Updates RFC0976) (Status: HISTORIC) (DOI: 10.17487/RFC1137) 1138 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. December 1989. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC0822) (Updated by RFC1148) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1138) 1139 Echo function for ISO 8473. R.A. Hagens. January 1990. (Format: TXT, HTML) (Obsoleted by RFC1574, RFC1575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1139) 1140 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. May 1990. (Format: TXT, HTML) (Obsoletes RFC1130) (Obsoleted by RFC1200) (Status: HISTORIC) (DOI: 10.17487/RFC1140) 1141 Incremental updating of the Internet checksum. T. Mallory, A. Kullberg. January 1990. (Format: TXT, HTML) (Updates RFC1071) (Updated by RFC1624) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1141) 1142 OSI IS-IS Intra-domain Routing Protocol. D. Oran, Ed.. February 1990. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC7142) (Status: HISTORIC) (DOI: 10.17487/RFC1142) 1143 The Q Method of Implementing TELNET Option Negotiation. D.J. Bernstein. February 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1143) 1144 Compressing TCP/IP Headers for Low-Speed Serial Links. V. Jacobson. February 1990. (Format: TXT, PS, PDF, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1144) 1145 TCP alternate checksum options. J. Zweig, C. Partridge. February 1990. (Format: TXT, HTML) (Obsoleted by RFC1146, RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1145) 1146 TCP alternate checksum options. J. Zweig, C. Partridge. March 1990. (Format: TXT, HTML) (Obsoletes RFC1145) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1146) 1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices. R.H. Stine. April 1990. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1470) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1147) 1148 Mapping between X.400(1988) / ISO 10021 and RFC 822. S.E. Kille. March 1990. (Format: TXT, HTML) (Obsoleted by RFC2156, RFC1327) (Updates RFC1026, RFC0987, RFC1138, RFC0822) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1148) 1149 Standard for the transmission of IP datagrams on avian carriers. D. Waitzman. 1 April 1990. (Format: TXT, HTML) (Updated by RFC2549, RFC6214) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1149) 1150 FYI on FYI: Introduction to the FYI Notes. G.S. Malkin, J.K. Reynolds. March 1990. (Format: TXT, HTML) (Obsoleted by RFC6360) (Status: HISTORIC) (DOI: 10.17487/RFC1150) 1151 Version 2 of the Reliable Data Protocol (RDP). C. Partridge, R.M. Hinden. April 1990. (Format: TXT, HTML) (Updates RFC0908) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1151) 1152 Workshop report: Internet research steering group workshop on very-high-speed networks. C. Partridge. April 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1152) 1153 Digest message format. F.J. Wancho. April 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1153) 1154 Encoding header field for internet messages. D. Robinson, R. Ullmann. April 1990. (Format: TXT, HTML) (Obsoleted by RFC1505) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1154) 1155 Structure and identification of management information for TCP/IP-based internets. M.T. Rose, K. McCloghrie. May 1990. (Format: TXT, HTML) (Obsoletes RFC1065) (Also STD0016) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1155) 1156 Management Information Base for network management of TCP/IP-based internets. K. McCloghrie, M.T. Rose. May 1990. (Format: TXT, HTML) (Obsoletes RFC1066) (Status: HISTORIC) (DOI: 10.17487/RFC1156) 1157 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, J. Davin. May 1990. (Format: TXT, HTML) (Obsoletes RFC1098) (Status: HISTORIC) (DOI: 10.17487/RFC1157) 1158 Management Information Base for network management of TCP/IP-based internets: MIB-II. M.T. Rose. May 1990. (Format: TXT, HTML) (Obsoleted by RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1158) 1159 Message Send Protocol. R. Nelson. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1312) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1159) 1160 Internet Activities Board. V. Cerf. May 1990. (Format: TXT, HTML) (Obsoletes RFC1120) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1160) 1161 SNMP over OSI. M.T. Rose. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1418) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1161) 1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base. G. Satz. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1238) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1162) 1163 Border Gateway Protocol (BGP). K. Lougheed, Y. Rekhter. June 1990. (Format: TXT, HTML) (Obsoletes RFC1105) (Obsoleted by RFC1267) (Status: HISTORIC) (DOI: 10.17487/RFC1163) 1164 Application of the Border Gateway Protocol in the Internet. J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. June 1990. (Format: TXT, HTML) (Obsoleted by RFC1268) (Status: HISTORIC) (DOI: 10.17487/RFC1164) 1165 Network Time Protocol (NTP) over the OSI Remote Operations Service. J. Crowcroft, J.P. Onions. June 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1165) 1166 Internet numbers. S. Kirkpatrick, M.K. Stahl, M. Recker. July 1990. (Format: TXT, HTML) (Obsoletes RFC1117, RFC1062, RFC1020) (Updated by RFC5737) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1166) 1167 Thoughts on the National Research and Education Network. V.G. Cerf. July 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1167) 1168 Intermail and Commercial Mail Relay services. A. Westine, A.L. DeSchon, J. Postel, C.E. Ward. July 1990. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1168) 1169 Explaining the role of GOSIP. V.G. Cerf, K.L. Mills. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1169) 1170 Public key standards and licenses. R.B. Fougner. January 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1170) 1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links. D. Perkins. July 1990. (Format: TXT, HTML) (Obsoletes RFC1134) (Obsoleted by RFC1331) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1171) 1172 Point-to-Point Protocol (PPP) initial configuration options. D. Perkins, R. Hobby. July 1990. (Format: TXT, HTML) (Obsoleted by RFC1331, RFC1332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1172) 1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet. J. VanBokkelen. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1173) 1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status. V.G. Cerf. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1174) 1175 FYI on where to start: A bibliography of internetworking information. K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, M.K. Stahl, A. Yuan. August 1990. (Format: TXT, HTML) (Also FYI0003) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1175) 1176 Interactive Mail Access Protocol: Version 2. M.R. Crispin. August 1990. (Format: TXT, HTML) (Obsoletes RFC1064) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1176) 1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. August 1990. (Format: TXT, HTML) (Obsoleted by RFC1206) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1177) 1178 Choosing a name for your computer. D. Libes. August 1990. (Format: TXT, HTML) (Also FYI0005) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1178) 1179 Line printer daemon protocol. L. McLaughlin. August 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1179) 1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. January 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1180) 1181 RIPE Terms of Reference. R. Blokzijl. September 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1181) 1182 Not Issued. 1183 New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. October 1990. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Updated by RFC5395, RFC5864, RFC6195, RFC6895) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1183) 1184 Telnet Linemode Option. D.A. Borman. October 1990. (Format: TXT, HTML) (Obsoletes RFC1116) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1184) 1185 TCP Extension for High-Speed Paths. V. Jacobson, R.T. Braden, L. Zhang. October 1990. (Format: TXT, HTML) (Obsoleted by RFC1323) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1185) 1186 MD4 Message Digest Algorithm. R.L. Rivest. October 1990. (Format: TXT, HTML) (Obsoleted by RFC1320) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1186) 1187 Bulk Table Retrieval with the SNMP. M.T. Rose, K. McCloghrie, J.R. Davin. October 1990. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1187) 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks. D. Katz. October 1990. (Format: TXT, HTML) (Obsoletes RFC1103) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1188) 1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP). U.S. Warrier, L. Besaw, L. LaBarre, B.D. Handspicker. October 1990. (Format: TXT, HTML) (Obsoletes RFC1095) (Status: HISTORIC) (DOI: 10.17487/RFC1189) 1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C. Topolcic. October 1990. (Format: TXT, HTML) (Obsoletes IEN119) (Obsoleted by RFC1819) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1190) 1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990. (Format: TXT, HTML) (Obsoletes RFC1063) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1191) 1192 Commercialization of the Internet summary report. B. Kahin. November 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1192) 1193 Client requirements for real-time communication services. D. Ferrari. November 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1193) 1194 Finger User Information Protocol. D.P. Zimmerman. November 1990. (Format: TXT, HTML) (Obsoletes RFC0742) (Obsoleted by RFC1196, RFC1288) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1194) 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments. R.W. Callon. December 1990. (Format: TXT, PS, HTML) (Updated by RFC1349, RFC5302, RFC5304) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1195) 1196 Finger User Information Protocol. D.P. Zimmerman. December 1990. (Format: TXT, HTML) (Obsoletes RFC1194, RFC0742) (Obsoleted by RFC1288) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1196) 1197 Using ODA for translating multimedia information. M. Sherman. December 1990. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1197) 1198 FYI on the X window system. R.W. Scheifler. January 1991. (Format: TXT, HTML) (Also FYI0006) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1198) 1199 Request for Comments Summary Notes: 1100-1199. J. Reynolds. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1199) 1200 IAB official protocol standards. Defense Advanced Research Projects Agency, Internet Activities Board. April 1991. (Format: TXT, HTML) (Obsoletes RFC1140) (Obsoleted by RFC1250) (Status: HISTORIC) (DOI: 10.17487/RFC1200) 1201 Transmitting IP traffic over ARCNET networks. D. Provan. February 1991. (Format: TXT, HTML) (Obsoletes RFC1051) (Also STD0046) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1201) 1202 Directory Assistance service. M.T. Rose. February 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1202) 1203 Interactive Mail Access Protocol: Version 3. J. Rice. February 1991. (Format: TXT, HTML) (Obsoletes RFC1064) (Status: HISTORIC) (DOI: 10.17487/RFC1203) 1204 Message Posting Protocol (MPP). S. Yeh, D. Lee. February 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1204) 1205 5250 Telnet interface. P. Chmielewski. February 1991. (Format: TXT, HTML) (Updated by RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1205) 1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions. G.S. Malkin, A.N. Marine. February 1991. (Format: TXT, HTML) (Obsoletes RFC1177) (Obsoleted by RFC1325) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1206) 1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions. G.S. Malkin, A.N. Marine, J.K. Reynolds. February 1991. (Format: TXT, HTML) (Also FYI0007) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1207) 1208 A Glossary of Networking Terms. O.J. Jacobsen, D.C. Lynch. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1208) 1209 The Transmission of IP Datagrams over the SMDS Service. D. Piscitello, J. Lawrence. March 1991. (Format: TXT, HTML) (Also STD0052) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1209) 1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990. V.G. Cerf, P.T. Kirstein, B. Randell. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1210) 1211 Problems with the maintenance of large mailing lists. A. Westine, J. Postel. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1211) 1212 Concise MIB definitions. M.T. Rose, K. McCloghrie. March 1991. (Format: TXT, HTML) (Also STD0016) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1212) 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II. K. McCloghrie, M. Rose. March 1991. (Format: TXT, HTML) (Obsoletes RFC1158) (Updated by RFC2011, RFC2012, RFC2013) (Also STD0017) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1213) 1214 OSI internet management: Management Information Base. L. LaBarre. April 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1214) 1215 Convention for defining traps for use with the SNMP. M.T. Rose. March 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1215) 1216 Gigabit network economics and paradigm shifts. P. Richard, P. Kynikos. 1 April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1216) 1217 Memo from the Consortium for Slow Commotion Research (CSCR). V.G. Cerf. 1 April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1217) 1218 Naming scheme for c=US. North American Directory Forum. April 1991. (Format: TXT, HTML) (Obsoleted by RFC1255, RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1218) 1219 On the assignment of subnet numbers. P.F. Tsuchiya. April 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1219) 1220 Point-to-Point Protocol extensions for bridging. F. Baker. April 1991. (Format: TXT, HTML) (Obsoleted by RFC1638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1220) 1221 Host Access Protocol (HAP) specification: Version 2. W. Edmond. April 1991. (Format: TXT, HTML) (Updates RFC0907) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1221) 1222 Advancing the NSFNET routing architecture. H.W. Braun, Y. Rekhter. May 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1222) 1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel. J.M. Halpern. May 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1223) 1224 Techniques for managing asynchronously generated alerts. L. Steinberg. May 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1224) 1225 Post Office Protocol: Version 3. M.T. Rose. May 1991. (Format: TXT, HTML) (Obsoletes RFC1081) (Obsoleted by RFC1460) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1225) 1226 Internet protocol encapsulation of AX.25 frames. B. Kantor. May 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1226) 1227 SNMP MUX protocol and MIB. M.T. Rose. May 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1227) 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface. G. Carpenter, B. Wijnen. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1592) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1228) 1229 Extensions to the generic-interface MIB. K. McCloghrie. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1573) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1229) 1230 IEEE 802.4 Token Bus MIB. K. McCloghrie, R. Fox. May 1991. (Format: TXT, HTML) (Updated by RFC1239) (Status: HISTORIC) (DOI: 10.17487/RFC1230) 1231 IEEE 802.5 Token Ring MIB. K. McCloghrie, R. Fox, E. Decker. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1743, RFC1748) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1231) 1232 Definitions of managed objects for the DS1 Interface type. F. Baker, C.P. Kolb. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1406) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1232) 1233 Definitions of managed objects for the DS3 Interface type. T.A. Cox, K. Tesink. May 1991. (Format: TXT, HTML) (Obsoleted by RFC1407) (Updated by RFC1239) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1233) 1234 Tunneling IPX traffic through IP networks. D. Provan. June 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1234) 1235 Coherent File Distribution Protocol. J. Ioannidis, G. Maguire. June 1991. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1235) 1236 IP to X.121 address mapping for DDN. L. Morales, P. Hasse. June 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1236) 1237 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, E. Gardner, R. Callon. July 1991. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1237) 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542). G. Satz. June 1991. (Format: TXT, HTML) (Obsoletes RFC1162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1238) 1239 Reassignment of experimental MIBs to standard MIBs. J.K. Reynolds. June 1991. (Format: TXT, HTML) (Updates RFC1229, RFC1230, RFC1231, RFC1232, RFC1233) (Status: HISTORIC) (DOI: 10.17487/RFC1239) 1240 OSI connectionless transport services on top of UDP: Version 1. C. Shue, W. Haggerty, K. Dobbins. June 1991. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1240) 1241 Scheme for an internet encapsulation protocol: Version 1. R.A. Woodburn, D.L. Mills. July 1991. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1241) 1242 Benchmarking Terminology for Network Interconnection Devices. S. Bradner. July 1991. (Format: TXT, HTML) (Updated by RFC6201) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1242) 1243 AppleTalk Management Information Base. S. Waldbusser. July 1991. (Format: TXT, HTML) (Obsoleted by RFC1742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1243) 1244 Site Security Handbook. J.P. Holbrook, J.K. Reynolds. July 1991. (Format: TXT, HTML) (Obsoleted by RFC2196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1244) 1245 OSPF Protocol Analysis. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Also RFC1246, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1245) 1246 Experience with the OSPF Protocol. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Also RFC1245, RFC1247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1246) 1247 OSPF Version 2. J. Moy. July 1991. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1131) (Obsoleted by RFC1583) (Updated by RFC1349) (Also RFC1245, RFC1246) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1247) 1248 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. July 1991. (Format: TXT, HTML) (Obsoleted by RFC1252) (Updated by RFC1349) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1248) 1249 DIXIE Protocol Specification. T. Howes, M. Smith, B. Beecher. August 1991. (Format: TXT, HTML) (Also RFC1202) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1249) 1250 IAB Official Protocol Standards. J. Postel. August 1991. (Format: TXT, HTML) (Obsoletes RFC1200) (Obsoleted by RFC2200, RFC1280) (Status: HISTORIC) (DOI: 10.17487/RFC1250) 1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members. G. Malkin. August 1991. (Format: TXT, HTML) (Obsoleted by RFC1336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1251) 1252 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT, HTML) (Obsoletes RFC1248) (Obsoleted by RFC1253) (Also RFC1245, RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1252) 1253 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. August 1991. (Format: TXT, HTML) (Obsoletes RFC1252) (Obsoleted by RFC1850) (Also RFC1245, RFC1246, RFC1247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1253) 1254 Gateway Congestion Control Survey. A. Mankin, K. Ramakrishnan. August 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1254) 1255 A Naming Scheme for c=US. The North American Directory Forum. September 1991. (Format: TXT, HTML) (Obsoletes RFC1218) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1255) 1256 ICMP Router Discovery Messages. S. Deering, Ed.. September 1991. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1256) 1257 Isochronous applications do not require jitter-controlled networks. C. Partridge. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1257) 1258 BSD Rlogin. B. Kantor. September 1991. (Format: TXT, HTML) (Obsoleted by RFC1282) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1258) 1259 Building the open road: The NREN as test-bed for the national public network. M. Kapor. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1259) 1260 Not Issued. 1261 Transition of Nic Services. S. Williamson, L. Nobile. September 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1261) 1262 Guidelines for Internet Measurement Activities. V.G. Cerf. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1262) 1263 TCP Extensions Considered Harmful. S. O'Malley, L.L. Peterson. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1263) 1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria. R.M. Hinden. October 1991. (Format: TXT, HTML) (Obsoleted by RFC4794) (Status: HISTORIC) (DOI: 10.17487/RFC1264) 1265 BGP Protocol Analysis. Y. Rekhter. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1265) 1266 Experience with the BGP Protocol. Y. Rekhter. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1266) 1267 Border Gateway Protocol 3 (BGP-3). K. Lougheed, Y. Rekhter. October 1991. (Format: TXT, HTML) (Obsoletes RFC1163) (Status: HISTORIC) (DOI: 10.17487/RFC1267) 1268 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. October 1991. (Format: TXT, HTML) (Obsoletes RFC1164) (Obsoleted by RFC1655) (Status: HISTORIC) (DOI: 10.17487/RFC1268) 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3. S. Willis, J.W. Burruss. October 1991. (Format: TXT, HTML) (Obsoleted by RFC4273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1269) 1270 SNMP Communications Services. F. Kastenholz. October 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1270) 1271 Remote Network Monitoring Management Information Base. S. Waldbusser. November 1991. (Format: TXT, HTML) (Obsoleted by RFC1757) (Updated by RFC1513) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1271) 1272 Internet Accounting: Background. C. Mills, D. Hirsh, G.R. Ruth. November 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1272) 1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations. M.F. Schwartz. November 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1273) 1274 The COSINE and Internet X.500 Schema. P. Barker, S. Kille. November 1991. (Format: TXT, HTML) (Obsoleted by RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1274) 1275 Replication Requirements to provide an Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1275) 1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1276) 1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1277) 1278 A string encoding of Presentation Address. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1278) 1279 X.500 and Domains. S.E. Hardcastle-Kille. November 1991. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1279) 1280 IAB Official Protocol Standards. J. Postel. March 1992. (Format: TXT, HTML) (Obsoletes RFC1250) (Obsoleted by RFC1360) (Status: HISTORIC) (DOI: 10.17487/RFC1280) 1281 Guidelines for the Secure Operation of the Internet. R. Pethia, S. Crocker, B. Fraser. November 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1281) 1282 BSD Rlogin. B. Kantor. December 1991. (Format: TXT, HTML) (Obsoletes RFC1258) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1282) 1283 SNMP over OSI. M. Rose. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1418) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1283) 1284 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Cook, Ed.. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1284) 1285 FDDI Management Information Base. J. Case. January 1992. (Format: TXT, HTML) (Updated by RFC1512) (Status: HISTORIC) (DOI: 10.17487/RFC1285) 1286 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1493, RFC1525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1286) 1287 Towards the Future Internet Architecture. D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby. December 1991. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1287) 1288 The Finger User Information Protocol. D. Zimmerman. December 1991. (Format: TXT, HTML) (Obsoletes RFC1196, RFC1194, RFC0742) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1288) 1289 DECnet Phase IV MIB Extensions. J. Saperia. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1559) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1289) 1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. December 1991. (Format: TXT, HTML) (Obsoleted by RFC1402) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1290) 1291 Mid-Level Networks Potential Technical Services. V. Aggarwal. December 1991. (Format: TXT, PS, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1291) 1292 A Catalog of Available X.500 Implementations. R. Lang, R. Wright. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1292) 1293 Inverse Address Resolution Protocol. T. Bradley, C. Brown. January 1992. (Format: TXT, HTML) (Obsoleted by RFC2390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1293) 1294 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1490, RFC2427) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1294) 1295 User Bill of Rights for entries and listings in the Public Directory. The North American Directory Forum. January 1992. (Format: TXT, HTML) (Obsoleted by RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1295) 1296 Internet Growth (1981-1991). M. Lottor. January 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1296) 1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS"). D. Johnson. January 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1297) 1298 SNMP over IPX. R. Wormley, S. Bostock. February 1992. (Format: TXT, HTML) (Obsoleted by RFC1420) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1298) 1299 Summary of 1200-1299. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1299) 1300 Remembrances of Things Past. S. Greenfield. February 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1300) 1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K. Marzullo. February 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1301) 1302 Building a Network Information Services Infrastructure. D. Sitzler, P. Smith, A. Marine. February 1992. (Format: TXT, HTML) (Also FYI0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1302) 1303 A Convention for Describing SNMP-based Agents. K. McCloghrie, M. Rose. February 1992. (Format: TXT, HTML) (Also RFC1155, RFC1157, RFC1212, RFC1213) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1303) 1304 Definitions of Managed Objects for the SIP Interface Type. T. Cox, Ed., K. Tesink, Ed.. February 1992. (Format: TXT, HTML) (Obsoleted by RFC1694) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1304) 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis. D. Mills. March 1992. (Format: TXT, PDF, HTML) (Obsoletes RFC0958, RFC1059, RFC1119) (Obsoleted by RFC5905) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1305) 1306 Experiences Supporting By-Request Circuit-Switched T3 Networks. A. Nicholson, J. Young. March 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1306) 1307 Dynamically Switched Link Control Protocol. J. Young, A. Nicholson. March 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1307) 1308 Executive Introduction to Directory Services Using the X.500 Protocol. C. Weider, J. Reynolds. March 1992. (Format: TXT, HTML) (Also FYI0013) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1308) 1309 Technical Overview of Directory Services Using the X.500 Protocol. C. Weider, J. Reynolds, S. Heker. March 1992. (Format: TXT, HTML) (Also FYI0014) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1309) 1310 The Internet Standards Process. L. Chapin. March 1992. (Format: TXT, HTML) (Obsoleted by RFC1602) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1310) 1311 Introduction to the STD Notes. J. Postel. March 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1311) 1312 Message Send Protocol 2. R. Nelson, G. Arnold. April 1992. (Format: TXT, HTML) (Obsoletes RFC1159) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1312) 1313 Today's Programming for KRFC AM 1313 Internet Talk Radio. C. Partridge. 1 April 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1313) 1314 A File Format for the Exchange of Images in the Internet. A. Katz, D. Cohen. April 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1314) 1315 Management Information Base for Frame Relay DTEs. C. Brown, F. Baker, C. Carvalho. April 1992. (Format: TXT, HTML) (Obsoleted by RFC2115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1315) 1316 Definitions of Managed Objects for Character Stream Devices. B. Stewart. April 1992. (Format: TXT, HTML) (Obsoleted by RFC1658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1316) 1317 Definitions of Managed Objects for RS-232-like Hardware Devices. B. Stewart. April 1992. (Format: TXT, HTML) (Obsoleted by RFC1659) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1317) 1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices. B. Stewart. April 1992. (Format: TXT, HTML) (Obsoleted by RFC1660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1318) 1319 The MD2 Message-Digest Algorithm. B. Kaliski. April 1992. (Format: TXT, HTML) (Obsoleted by RFC6149) (Status: HISTORIC) (DOI: 10.17487/RFC1319) 1320 The MD4 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT, HTML) (Obsoletes RFC1186) (Obsoleted by RFC6150) (Status: HISTORIC) (DOI: 10.17487/RFC1320) 1321 The MD5 Message-Digest Algorithm. R. Rivest. April 1992. (Format: TXT, HTML) (Updated by RFC6151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1321) 1322 A Unified Approach to Inter-Domain Routing. D. Estrin, Y. Rekhter, S. Hotz. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1322) 1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. (Format: TXT, HTML) (Obsoletes RFC1072, RFC1185) (Obsoleted by RFC7323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1323) 1324 A Discussion on Computer Network Conferencing. D. Reed. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1324) 1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions. G. Malkin, A. Marine. May 1992. (Format: TXT, HTML) (Obsoletes RFC1206) (Obsoleted by RFC1594) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1325) 1326 Mutual Encapsulation Considered Dangerous. P. Tsuchiya. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1326) 1327 Mapping between X.400(1988) / ISO 10021 and RFC 822. S. Hardcastle-Kille. May 1992. (Format: TXT, HTML) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148) (Obsoleted by RFC2156) (Updates RFC0822) (Updated by RFC1495) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1327) 1328 X.400 1988 to 1984 downgrading. S. Hardcastle-Kille. May 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1328) 1329 Thoughts on Address Resolution for Dual MAC FDDI Networks. P. Kuehn. May 1992. (Format: TXT, HTML) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1329) 1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community. ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet). May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1330) 1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links. W. Simpson. May 1992. (Format: TXT, HTML) (Obsoletes RFC1171, RFC1172) (Obsoleted by RFC1548) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1331) 1332 The PPP Internet Protocol Control Protocol (IPCP). G. McGregor. May 1992. (Format: TXT, HTML) (Obsoletes RFC1172) (Updated by RFC3241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1332) 1333 PPP Link Quality Monitoring. W. Simpson. May 1992. (Format: TXT, HTML) (Obsoleted by RFC1989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1333) 1334 PPP Authentication Protocols. B. Lloyd, W. Simpson. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1994) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1334) 1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion. Z. Wang, J. Crowcroft. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1335) 1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members. G. Malkin. May 1992. (Format: TXT, HTML) (Obsoletes RFC1251) (Also FYI0009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1336) 1337 TIME-WAIT Assassination Hazards in TCP. R. Braden. May 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1337) 1338 Supernetting: an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. June 1992. (Format: TXT, HTML) (Obsoleted by RFC1519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1338) 1339 Remote Mail Checking Protocol. S. Dorner, P. Resnick. June 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1339) 1340 Assigned Numbers. J. Reynolds, J. Postel. July 1992. (Format: TXT, HTML) (Obsoletes RFC1060) (Obsoleted by RFC1700) (Status: HISTORIC) (DOI: 10.17487/RFC1340) 1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed. June 1992. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1521) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1341) 1342 Representation of Non-ASCII Text in Internet Message Headers. K. Moore. June 1992. (Format: TXT, HTML) (Obsoleted by RFC1522) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1342) 1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information. N. Borenstein. June 1992. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1343) 1344 Implications of MIME for Internet Mail Gateways. N. Borenstein. June 1992. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1344) 1345 Character Mnemonics and Character Sets. K. Simonsen. June 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1345) 1346 Resource Allocation, Control, and Accounting for the Use of Network Resources. P. Jones. June 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1346) 1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing. R. Callon. June 1992. (Format: TXT, PS, PDF, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1347) 1348 DNS NSAP RRs. B. Manning. July 1992. (Format: TXT, HTML) (Obsoleted by RFC1637) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1348) 1349 Type of Service in the Internet Protocol Suite. P. Almquist. July 1992. (Format: TXT, HTML) (Obsoleted by RFC2474) (Updates RFC1248, RFC1247, RFC1195, RFC1123, RFC1122, RFC1060, RFC0791) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1349) 1350 The TFTP Protocol (Revision 2). K. Sollins. July 1992. (Format: TXT, HTML) (Obsoletes RFC0783) (Updated by RFC1782, RFC1783, RFC1784, RFC1785, RFC2347, RFC2348, RFC2349) (Also STD0033) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1350) 1351 SNMP Administrative Model. J. Davin, J. Galvin, K. McCloghrie. July 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1351) 1352 SNMP Security Protocols. J. Galvin, K. McCloghrie, J. Davin. July 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1352) 1353 Definitions of Managed Objects for Administration of SNMP Parties. K. McCloghrie, J. Davin, J. Galvin. July 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1353) 1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT, HTML) (Obsoleted by RFC2096) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1354) 1355 Privacy and Accuracy Issues in Network Information Center Databases. J. Curran, A. Marine. August 1992. (Format: TXT, HTML) (Also FYI0015) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1355) 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. A. Malis, D. Robinson, R. Ullmann. August 1992. (Format: TXT, HTML) (Obsoletes RFC0877) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1356) 1357 A Format for E-mailing Bibliographic Records. D. Cohen. July 1992. (Format: TXT, HTML) (Obsoleted by RFC1807) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1357) 1358 Charter of the Internet Architecture Board (IAB). L. Chapin. August 1992. (Format: TXT, HTML) (Obsoleted by RFC1601) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1358) 1359 Connecting to the Internet - What Connecting Institutions Should Anticipate. ACM SIGUCCS. August 1992. (Format: TXT, HTML) (Also FYI0016) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1359) 1360 IAB Official Protocol Standards. J. Postel. September 1992. (Format: TXT, HTML) (Obsoletes RFC1280) (Obsoleted by RFC1410) (Status: HISTORIC) (DOI: 10.17487/RFC1360) 1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992. (Format: TXT, HTML) (Obsoleted by RFC1769) (Also RFC1305) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1361) 1362 Novell IPX over Various WAN Media (IPXWAN). M. Allen. September 1992. (Format: TXT, HTML) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1362) 1363 A Proposed Flow Specification. C. Partridge. September 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1363) 1364 BGP OSPF Interaction. K. Varadhan. September 1992. (Format: TXT, HTML) (Obsoleted by RFC1403) (Also RFC1247, RFC1267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1364) 1365 An IP Address Extension Proposal. K. Siyan. September 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1365) 1366 Guidelines for Management of IP Address Space. E. Gerich. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1366) 1367 Schedule for IP Address Space Management Guidelines. C. Topolcic. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1467) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1367) 1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. October 1992. (Format: TXT, HTML) (Obsoleted by RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1368) 1369 Implementation Notes and Experience for the Internet Ethernet MIB. F. Kastenholz. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1369) 1370 Applicability Statement for OSPF. Internet Architecture Board, L. Chapin. October 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1370) 1371 Choosing a Common IGP for the IP Internet. P. Gross. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1371) 1372 Telnet Remote Flow Control Option. C. Hedrick, D. Borman. October 1992. (Format: TXT, HTML) (Obsoletes RFC1080) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1372) 1373 Portable DUAs. T. Tignor. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1373) 1374 IP and ARP on HIPPI. J. Renwick, A. Nicholson. October 1992. (Format: TXT, HTML) (Obsoleted by RFC2834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1374) 1375 Suggestion for New Classes of IP Addresses. P. Robinson. October 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1375) 1376 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. November 1992. (Format: TXT, HTML) (Obsoleted by RFC1762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1376) 1377 The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1377) 1378 The PPP AppleTalk Control Protocol (ATCP). B. Parker. November 1992. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1378) 1379 Extending TCP for Transactions -- Concepts. R. Braden. November 1992. (Format: TXT, HTML) (Obsoleted by RFC6247) (Updated by RFC1644) (Status: HISTORIC) (DOI: 10.17487/RFC1379) 1380 IESG Deliberations on Routing and Addressing. P. Gross, P. Almquist. November 1992. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1380) 1381 SNMP MIB Extension for X.25 LAPB. D. Throop, F. Baker. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1381) 1382 SNMP MIB Extension for the X.25 Packet Layer. D. Throop, Ed.. November 1992. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1382) 1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1383) 1384 Naming Guidelines for Directory Pilots. P. Barker, S.E. Hardcastle-Kille. January 1993. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1617, RTR0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1384) 1385 EIP: The Extended Internet Protocol. Z. Wang. November 1992. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1385) 1386 The US Domain. A. Cooper, J. Postel. December 1992. (Format: TXT, HTML) (Obsoleted by RFC1480) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1386) 1387 RIP Version 2 Protocol Analysis. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1721) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1387) 1388 RIP Version 2 Carrying Additional Information. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1723) (Updates RFC1058) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1388) 1389 RIP Version 2 MIB Extensions. G. Malkin, F. Baker. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1389) 1390 Transmission of IP and ARP over FDDI Networks. D. Katz. January 1993. (Format: TXT, HTML) (Also STD0036) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1390) 1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1391) 1392 Internet Users' Glossary. G. Malkin, T. LaQuey Parker. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1392) 1393 Traceroute Using an IP Option. G. Malkin. January 1993. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1393) 1394 Relationship of Telex Answerback Codes to Internet Domains. P. Robinson. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1394) 1395 BOOTP Vendor Information Extensions. J. Reynolds. January 1993. (Format: TXT, HTML) (Obsoletes RFC1084, RFC1048) (Obsoleted by RFC1497, RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1395) 1396 The Process for Organization of Internet Standards Working Group (POISED). S. Crocker. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1396) 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol. D. Haskin. January 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1397) 1398 Definitions of Managed Objects for the Ethernet-Like Interface Types. F. Kastenholz. January 1993. (Format: TXT, HTML) (Obsoletes RFC1284) (Obsoleted by RFC1623) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1398) 1399 Summary of 1300-1399. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1399) 1400 Transition and Modernization of the Internet Registration Service. S. Williamson. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1400) 1401 Correspondence between the IAB and DISA on the use of DNS. Internet Architecture Board. January 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1401) 1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places. J. Martin. January 1993. (Format: TXT, HTML) (Obsoletes RFC1290) (Also FYI0010) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1402) 1403 BGP OSPF Interaction. K. Varadhan. January 1993. (Format: TXT, HTML) (Obsoletes RFC1364) (Status: HISTORIC) (DOI: 10.17487/RFC1403) 1404 A Model for Common Operational Statistics. B. Stockman. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1857) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1404) 1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail). C. Allocchio. January 1993. (Format: TXT, HTML) (Obsoleted by RFC2162) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1405) 1406 Definitions of Managed Objects for the DS1 and E1 Interface Types. F. Baker, Ed., J. Watt, Ed.. January 1993. (Format: TXT, HTML) (Obsoletes RFC1232) (Obsoleted by RFC2495) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1406) 1407 Definitions of Managed Objects for the DS3/E3 Interface Type. T. Cox, K. Tesink. January 1993. (Format: TXT, HTML) (Obsoletes RFC1233) (Obsoleted by RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1407) 1408 Telnet Environment Option. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Updated by RFC1571) (Status: HISTORIC) (DOI: 10.17487/RFC1408) 1409 Telnet Authentication Option. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Obsoleted by RFC1416) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1409) 1410 IAB Official Protocol Standards. J. Postel, Ed.. March 1993. (Format: TXT, HTML) (Obsoletes RFC1360) (Obsoleted by RFC1500) (Status: HISTORIC) (DOI: 10.17487/RFC1410) 1411 Telnet Authentication: Kerberos Version 4. D. Borman, Ed.. January 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1411) 1412 Telnet Authentication: SPX. K. Alagappan. January 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1412) 1413 Identification Protocol. M. St. Johns. February 1993. (Format: TXT, HTML) (Obsoletes RFC0931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1413) 1414 Identification MIB. M. St. Johns, M. Rose. February 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1414) 1415 FTP-FTAM Gateway Specification. J. Mindel, R. Slaski. January 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1415) 1416 Telnet Authentication Option. D. Borman, Ed.. February 1993. (Format: TXT, HTML) (Obsoletes RFC1409) (Obsoleted by RFC2941) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1416) 1417 NADF Standing Documents: A Brief Overview. The North American Directory Forum. February 1993. (Format: TXT, HTML) (Obsoletes RFC1295, RFC1255, RFC1218) (Obsoleted by RFC1758) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1417) 1418 SNMP over OSI. M. Rose. March 1993. (Format: TXT, HTML) (Obsoletes RFC1161, RFC1283) (Status: HISTORIC) (DOI: 10.17487/RFC1418) 1419 SNMP over AppleTalk. G. Minshall, M. Ritter. March 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1419) 1420 SNMP over IPX. S. Bostock. March 1993. (Format: TXT, HTML) (Obsoletes RFC1298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1420) 1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures. J. Linn. February 1993. (Format: TXT, HTML) (Obsoletes RFC1113) (Status: HISTORIC) (DOI: 10.17487/RFC1421) 1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. S. Kent. February 1993. (Format: TXT, HTML) (Obsoletes RFC1114) (Status: HISTORIC) (DOI: 10.17487/RFC1422) 1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. D. Balenson. February 1993. (Format: TXT, HTML) (Obsoletes RFC1115) (Status: HISTORIC) (DOI: 10.17487/RFC1423) 1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services. B. Kaliski. February 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1424) 1425 SMTP Service Extensions. J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT, HTML) (Obsoleted by RFC1651) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1425) 1426 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. February 1993. (Format: TXT, HTML) (Obsoleted by RFC1652) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1426) 1427 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, Ed., K. Moore. February 1993. (Format: TXT, HTML) (Obsoleted by RFC1653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1427) 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. G. Vaudreuil. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1428) 1429 Listserv Distribute Protocol. E. Thomas. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1429) 1430 A Strategic Plan for Deploying an Internet X.500 Directory Service. S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1430) 1431 DUA Metrics (OSI-DS 33 (v2)). P. Barker. February 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1431) 1432 Recent Internet Books. J. Quarterman. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1432) 1433 Directed ARP. J. Garrett, J. Hagan, J. Wong. March 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1433) 1434 Data Link Switching: Switch-to-Switch Protocol. R. Dixon, D. Kushi. March 1993. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC1795) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1434) 1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1435) 1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol). F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Albert. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1436) 1437 The Extension of MIME Content-Types to a New Medium. N. Borenstein, M. Linimon. 1 April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1437) 1438 Internet Engineering Task Force Statements Of Boredom (SOBs). A. Lyman Chapin, C. Huitema. 1 April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1438) 1439 The Uniqueness of Unique Identifiers. C. Finseth. March 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1439) 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer. R. Troth. July 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1440) 1441 Introduction to version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1441) 1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1902) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1442) 1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1903) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1443) 1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1904) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1444) 1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1445) 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2). J. Galvin, K. McCloghrie. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1446) 1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2). K. McCloghrie, J. Galvin. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1447) 1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1448) 1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1906) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1449) 1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1907) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1450) 1451 Manager-to-Manager Management Information Base. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1451) 1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993. (Format: TXT, HTML) (Obsoleted by RFC1908) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1452) 1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers. W. Chimiak. April 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1453) 1454 Comparison of Proposals for Next Version of IP. T. Dixon. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1454) 1455 Physical Link Security Type of Service. D. Eastlake 3rd. May 1993. (Format: TXT, HTML) (Obsoleted by RFC2474) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1455) 1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification. Vietnamese Standardization Working Group. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1456) 1457 Security Label Framework for the Internet. R. Housley. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1457) 1458 Requirements for Multicast Protocols. R. Braudes, S. Zabele. May 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1458) 1459 Internet Relay Chat Protocol. J. Oikarinen, D. Reed. May 1993. (Format: TXT, HTML) (Updated by RFC2810, RFC2811, RFC2812, RFC2813, RFC7194) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1459) 1460 Post Office Protocol - Version 3. M. Rose. June 1993. (Format: TXT, HTML) (Obsoletes RFC1225) (Obsoleted by RFC1725) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1460) 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25. D. Throop. May 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1461) 1462 FYI on "What is the Internet?". E. Krol, E. Hoffman. May 1993. (Format: TXT, HTML) (Also FYI0020) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1462) 1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings. E. Hoffman, L. Jackson. May 1993. (Format: TXT, HTML) (Also FYI0019) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1463) 1464 Using the Domain Name System To Store Arbitrary String Attributes. R. Rosenbaum. May 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1464) 1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing. D. Eppenberger. May 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1465) 1466 Guidelines for Management of IP Address Space. E. Gerich. May 1993. (Format: TXT, HTML) (Obsoletes RFC1366) (Obsoleted by RFC2050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1466) 1467 Status of CIDR Deployment in the Internet. C. Topolcic. August 1993. (Format: TXT, HTML) (Obsoletes RFC1367) (Status: HISTORIC) (DOI: 10.17487/RFC1467) 1468 Japanese Character Encoding for Internet Messages. J. Murai, M. Crispin, E. van der Poel. June 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1468) 1469 IP Multicast over Token-Ring Local Area Networks. T. Pusateri. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1469) 1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices. R. Enger, J. Reynolds. June 1993. (Format: TXT, HTML) (Obsoletes RFC1147) (Also FYI0002) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1470) 1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1471) 1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1472) 1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1473) 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol. F. Kastenholz. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1474) 1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1475) 1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1476) 1477 IDPR as a Proposed Standard. M. Steenstrup. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1477) 1478 An Architecture for Inter-Domain Policy Routing. M. Steenstrup. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1478) 1479 Inter-Domain Policy Routing Protocol Specification: Version 1. M. Steenstrup. July 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1479) 1480 The US Domain. A. Cooper, J. Postel. June 1993. (Format: TXT, HTML) (Obsoletes RFC1386) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1480) 1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling. C. Huitema. July 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1481) 1482 Aggregation Support in the NSFNET Policy-Based Routing Database. M. Knopper, S. Richardson. June 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1482) 1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5. Juha Heinanen. July 1993. (Format: TXT, HTML) (Obsoleted by RFC2684) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1483) 1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)). S. Hardcastle-Kille. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1781, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1484) 1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)). S. Hardcastle-Kille. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1779, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1485) 1486 An Experiment in Remote Printing. M. Rose, C. Malamud. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1528, RFC1529) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1486) 1487 X.500 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1777, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1487) 1488 The X.500 String Representation of Standard Attribute Syntaxes. T. Howes, S. Kille, W. Yeong, C. Robbins. July 1993. (Format: TXT, HTML) (Obsoleted by RFC1778) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1488) 1489 Registration of a Cyrillic Character Set. A. Chernov. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1489) 1490 Multiprotocol Interconnect over Frame Relay. T. Bradley, C. Brown, A. Malis. July 1993. (Format: TXT, HTML) (Obsoletes RFC1294) (Obsoleted by RFC2427) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1490) 1491 A Survey of Advanced Usages of X.500. C. Weider, R. Wright. July 1993. (Format: TXT, HTML) (Also FYI0021) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1491) 1492 An Access Control Protocol, Sometimes Called TACACS. C. Finseth. July 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1492) 1493 Definitions of Managed Objects for Bridges. E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. July 1993. (Format: TXT, HTML) (Obsoletes RFC1286) (Obsoleted by RFC4188) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1493) 1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies. H. Alvestrand, S. Thompson. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1494) 1495 Mapping between X.400 and RFC-822 Message Bodies. H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. August 1993. (Format: TXT, HTML) (Obsoleted by RFC2156) (Updates RFC1327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1495) 1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages. H. Alvestrand, J. Romaguera, K. Jordan. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1496) 1497 BOOTP Vendor Information Extensions. J. Reynolds. August 1993. (Format: TXT, HTML) (Obsoletes RFC1395, RFC1084, RFC1048) (Obsoleted by RFC1533) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1497) 1498 On the Naming and Binding of Network Destinations. J. Saltzer. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1498) 1499 Summary of 1400-1499. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1499) 1500 Internet Official Protocol Standards. J. Postel. August 1993. (Format: TXT, HTML) (Obsoletes RFC1410) (Obsoleted by RFC1540) (Status: HISTORIC) (DOI: 10.17487/RFC1500) 1501 OS/2 User Group. E. Brunsen. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1501) 1502 X.400 Use of Extended Character Sets. H. Alvestrand. August 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1502) 1503 Algorithms for Automating Administration in SNMPv2 Managers. K. McCloghrie, M. Rose. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1503) 1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing. A. Oppenheimer. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1504) 1505 Encoding Header Field for Internet Messages. A. Costanzo, D. Robinson, R. Ullmann. August 1993. (Format: TXT, HTML) (Obsoletes RFC1154) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1505) 1506 A Tutorial on Gatewaying between X.400 and Internet Mail. J. Houttuin. August 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1506) 1507 DASS - Distributed Authentication Security Service. C. Kaufman. September 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1507) 1508 Generic Security Service Application Program Interface. J. Linn. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2078) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1508) 1509 Generic Security Service API : C-bindings. J. Wray. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2744) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1509) 1510 The Kerberos Network Authentication Service (V5). J. Kohl, C. Neuman. September 1993. (Format: TXT, HTML) (Obsoleted by RFC4120, RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC1510) 1511 Common Authentication Technology Overview. J. Linn. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1511) 1512 FDDI Management Information Base. J. Case, A. Rijsinghani. September 1993. (Format: TXT, HTML) (Updates RFC1285) (Status: HISTORIC) (DOI: 10.17487/RFC1512) 1513 Token Ring Extensions to the Remote Network Monitoring MIB. S. Waldbusser. September 1993. (Format: TXT, HTML) (Updates RFC1271) (Status: HISTORIC) (DOI: 10.17487/RFC1513) 1514 Host Resources MIB. P. Grillo, S. Waldbusser. September 1993. (Format: TXT, HTML) (Obsoleted by RFC2790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1514) 1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). D. McMaster, K. McCloghrie, S. Roberts. September 1993. (Format: TXT, HTML) (Obsoleted by RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1515) 1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices. D. McMaster, K. McCloghrie. September 1993. (Format: TXT, HTML) (Obsoletes RFC1368) (Obsoleted by RFC2108) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1516) 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR). Internet Engineering Steering Group, R. Hinden. September 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1517) 1518 An Architecture for IP Address Allocation with CIDR. Y. Rekhter, T. Li. September 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1518) 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. September 1993. (Format: TXT, HTML) (Obsoletes RFC1338) (Obsoleted by RFC4632) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1519) 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment. Y. Rekhter, C. Topolcic. September 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1520) 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed. September 1993. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1341) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updated by RFC1590) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1521) 1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. K. Moore. September 1993. (Format: TXT, HTML) (Obsoletes RFC1342) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1522) 1523 The text/enriched MIME Content-type. N. Borenstein. September 1993. (Format: TXT, HTML) (Obsoleted by RFC1563, RFC1896) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1523) 1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information. N. Borenstein. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1524) 1525 Definitions of Managed Objects for Source Routing Bridges. E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani. September 1993. (Format: TXT, HTML) (Obsoletes RFC1286) (Status: HISTORIC) (DOI: 10.17487/RFC1525) 1526 Assignment of System Identifiers for TUBA/CLNP Hosts. D. Piscitello. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1526) 1527 What Should We Plan Given the Dilemma of the Network?. G. Cook. September 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1527) 1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures. C. Malamud, M. Rose. October 1993. (Format: TXT, HTML) (Obsoletes RFC1486) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1528) 1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies. C. Malamud, M. Rose. October 1993. (Format: TXT, HTML) (Obsoletes RFC1486) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1529) 1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy. C. Malamud, M. Rose. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1530) 1531 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1541) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1531) 1532 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1542) (Updates RFC0951) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1532) 1533 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. October 1993. (Format: TXT, HTML) (Obsoletes RFC1497, RFC1395, RFC1084, RFC1048) (Obsoleted by RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1533) 1534 Interoperation Between DHCP and BOOTP. R. Droms. October 1993. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1534) 1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software. E. Gavron. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1535) 1536 Common DNS Implementation Errors and Suggested Fixes. A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1536) 1537 Common DNS Data File Configuration Errors. P. Beertema. October 1993. (Format: TXT, HTML) (Obsoleted by RFC1912) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1537) 1538 Advanced SNA/IP : A Simple SNA Transport Protocol. W. Behl, B. Sterling, W. Teskey. October 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1538) 1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force. G. Malkin. October 1993. (Format: TXT, HTML) (Obsoletes RFC1391) (Obsoleted by RFC1718) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1539) 1540 Internet Official Protocol Standards. J. Postel. October 1993. (Format: TXT, HTML) (Obsoletes RFC1500) (Obsoleted by RFC1600) (Status: HISTORIC) (DOI: 10.17487/RFC1540) 1541 Dynamic Host Configuration Protocol. R. Droms. October 1993. (Format: TXT, HTML) (Obsoletes RFC1531) (Obsoleted by RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1541) 1542 Clarifications and Extensions for the Bootstrap Protocol. W. Wimer. October 1993. (Format: TXT, HTML) (Obsoletes RFC1532) (Updates RFC0951) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1542) 1543 Instructions to RFC Authors. J. Postel. October 1993. (Format: TXT, HTML) (Obsoletes RFC1111, RFC0825) (Obsoleted by RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1543) 1544 The Content-MD5 Header Field. M. Rose. November 1993. (Format: TXT, HTML) (Obsoleted by RFC1864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1544) 1545 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. November 1993. (Format: TXT, HTML) (Obsoleted by RFC1639) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1545) 1546 Host Anycasting Service. C. Partridge, T. Mendez, W. Milliken. November 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1546) 1547 Requirements for an Internet Standard Point-to-Point Protocol. D. Perkins. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1547) 1548 The Point-to-Point Protocol (PPP). W. Simpson. December 1993. (Format: TXT, HTML) (Obsoletes RFC1331) (Obsoleted by RFC1661) (Updated by RFC1570) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1548) 1549 PPP in HDLC Framing. W. Simpson, Ed.. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1662) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1549) 1550 IP: Next Generation (IPng) White Paper Solicitation. S. Bradner, A. Mankin. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1550) 1551 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1634) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1551) 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP). W. Simpson. December 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1552) 1553 Compressing IPX Headers Over WAN Media (CIPX). S. Mathur, M. Lewis. December 1993. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1553) 1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP. M. Ohta, K. Handa. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1554) 1555 Hebrew Character Encoding for Internet Messages. H. Nussbacher, Y. Bourvine. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1555) 1556 Handling of Bi-directional Texts in MIME. H. Nussbacher. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1556) 1557 Korean Character Encoding for Internet Messages. U. Choi, K. Chon, H. Park. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1557) 1558 A String Representation of LDAP Search Filters. T. Howes. December 1993. (Format: TXT, HTML) (Obsoleted by RFC1960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1558) 1559 DECnet Phase IV MIB Extensions. J. Saperia. December 1993. (Format: TXT, HTML) (Obsoletes RFC1289) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1559) 1560 The MultiProtocol Internet. B. Leiner, Y. Rekhter. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1560) 1561 Use of ISO CLNP in TUBA Environments. D. Piscitello. December 1993. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1561) 1562 Naming Guidelines for the AARNet X.500 Directory Service. G. Michaelson, M. Prior. December 1993. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1562) 1563 The text/enriched MIME Content-type. N. Borenstein. January 1994. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1523) (Obsoleted by RFC1896) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1563) 1564 DSA Metrics (OSI-DS 34 (v3)). P. Barker, R. Hedberg. January 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1564) 1565 Network Services Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1565) 1566 Mail Monitoring MIB. S. Kille, N. Freed. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2249, RFC2789) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1566) 1567 X.500 Directory Monitoring MIB. G. Mansfield, S. Kille. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2605) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1567) 1568 Simple Network Paging Protocol - Version 1(b). A. Gwinn. January 1994. (Format: TXT, HTML) (Obsoleted by RFC1645) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1568) 1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures. M. Rose. January 1994. (Format: TXT, HTML) (Obsoleted by RFC1703) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1569) 1570 PPP LCP Extensions. W. Simpson, Ed.. January 1994. (Format: TXT, HTML) (Updates RFC1548) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1570) 1571 Telnet Environment Option Interoperability Issues. D. Borman. January 1994. (Format: TXT, HTML) (Updates RFC1408) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1571) 1572 Telnet Environment Option. S. Alexander, Ed.. January 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1572) 1573 Evolution of the Interfaces Group of MIB-II. K. McCloghrie, F. Kastenholz. January 1994. (Format: TXT, HTML) (Obsoletes RFC1229) (Obsoleted by RFC2233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1573) 1574 Essential Tools for the OSI Internet. S. Hares, C. Wittbrodt. February 1994. (Format: TXT, HTML) (Obsoletes RFC1139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1574) 1575 An Echo Function for CLNP (ISO 8473). S. Hares, C. Wittbrodt. February 1994. (Format: TXT, HTML) (Obsoletes RFC1139) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1575) 1576 TN3270 Current Practices. J. Penner. January 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1576) 1577 Classical IP and ARP over ATM. M. Laubach. January 1994. (Format: TXT, HTML) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1577) 1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions. J. Sellers. February 1994. (Format: TXT, HTML) (Obsoleted by RFC1941) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1578) 1579 Firewall-Friendly FTP. S. Bellovin. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1579) 1580 Guide to Network Resource Tools. EARN Staff. March 1994. (Format: TXT, HTML) (Also FYI0023) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1580) 1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1581) 1582 Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1582) 1583 OSPF Version 2. J. Moy. March 1994. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1247) (Obsoleted by RFC2178) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1583) 1584 Multicast Extensions to OSPF. J. Moy. March 1994. (Format: TXT, PS, PDF, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1584) 1585 MOSPF: Analysis and Experience. J. Moy. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1585) 1586 Guidelines for Running OSPF Over Frame Relay Networks. O. deSouza, M. Rodrigues. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1586) 1587 The OSPF NSSA Option. R. Coltun, V. Fuller. March 1994. (Format: TXT, HTML) (Obsoleted by RFC3101) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1587) 1588 White Pages Meeting Report. J. Postel, C. Anderson. February 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1588) 1589 A Kernel Model for Precision Timekeeping. D. Mills. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1589) 1590 Media Type Registration Procedure. J. Postel. March 1994. (Format: TXT, HTML) (Obsoleted by RFC2045, RFC2046, RFC2047, RFC2048, RFC2049) (Updates RFC1521) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1590) 1591 Domain Name System Structure and Delegation. J. Postel. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1591) 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0. B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters. March 1994. (Format: TXT, HTML) (Obsoletes RFC1228) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1592) 1593 SNA APPN Node MIB. W. McKenzie, J. Cheng. March 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1593) 1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions. A. Marine, J. Reynolds, G. Malkin. March 1994. (Format: TXT, HTML) (Obsoletes RFC1325) (Obsoleted by RFC2664) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1594) 1595 Definitions of Managed Objects for the SONET/SDH Interface Type. T. Brown, K. Tesink. March 1994. (Format: TXT, HTML) (Obsoleted by RFC2558) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1595) 1596 Definitions of Managed Objects for Frame Relay Service. T. Brown, Ed.. March 1994. (Format: TXT, HTML) (Obsoleted by RFC1604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1596) 1597 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. March 1994. (Format: TXT, HTML) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1597) 1598 PPP in X.25. W. Simpson. March 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1598) 1599 Summary of 1500-1599. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1599) 1600 Internet Official Protocol Standards. J. Postel. March 1994. (Format: TXT, HTML) (Obsoletes RFC1540) (Obsoleted by RFC1610) (Status: HISTORIC) (DOI: 10.17487/RFC1600) 1601 Charter of the Internet Architecture Board (IAB). C. Huitema. March 1994. (Format: TXT, HTML) (Obsoletes RFC1358) (Obsoleted by RFC2850) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1601) 1602 The Internet Standards Process -- Revision 2. Internet Architecture Board, Internet Engineering Steering Group. March 1994. (Format: TXT, HTML) (Obsoletes RFC1310) (Obsoleted by RFC2026) (Updated by RFC1871) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1602) 1603 IETF Working Group Guidelines and Procedures. E. Huizer, D. Crocker. March 1994. (Format: TXT, HTML) (Obsoleted by RFC2418) (Updated by RFC1871) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1603) 1604 Definitions of Managed Objects for Frame Relay Service. T. Brown, Ed.. March 1994. (Format: TXT, HTML) (Obsoletes RFC1596) (Obsoleted by RFC2954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1604) 1605 SONET to Sonnet Translation. W. Shakespeare. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1605) 1606 A Historical Perspective On The Usage Of IP Version 9. J. Onions. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1606) 1607 A VIEW FROM THE 21ST CENTURY. V. Cerf. 1 April 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1607) 1608 Representing IP Information in the X.500 Directory. T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri. March 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1608) 1609 Charting Networks in the X.500 Directory. G. Mansfield, T. Johannsen, M. Knopper. March 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1609) 1610 Internet Official Protocol Standards. J. Postel. July 1994. (Format: TXT, HTML) (Obsoletes RFC1600) (Obsoleted by RFC1720) (Status: HISTORIC) (DOI: 10.17487/RFC1610) 1611 DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1611) 1612 DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1612) 1613 cisco Systems X.25 over TCP (XOT). J. Forster, G. Satz, G. Glick, R. Day. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1613) 1614 Network Access to Multimedia Information. C. Adie. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1614) 1615 Migrating from X.400(84) to X.400(88). J. Houttuin, J. Craigie. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1615) 1616 X.400(1988) for the Academic and Research Community in Europe. RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed.. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1616) 1617 Naming and Structuring Guidelines for X.500 Directory Pilots. P. Barker, S. Kille, T. Lenggenhager. May 1994. (Format: TXT, HTML) (Obsoletes RFC1384) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1617) 1618 PPP over ISDN. W. Simpson. May 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1618) 1619 PPP over SONET/SDH. W. Simpson. May 1994. (Format: TXT, HTML) (Obsoleted by RFC2615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1619) 1620 Internet Architecture Extensions for Shared Media. B. Braden, J. Postel, Y. Rekhter. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1620) 1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1621) 1622 Pip Header Processing. P. Francis. May 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1622) 1623 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. May 1994. (Format: TXT, HTML) (Obsoletes RFC1398) (Obsoleted by RFC1643) (Status: HISTORIC) (DOI: 10.17487/RFC1623) 1624 Computation of the Internet Checksum via Incremental Update. A. Rijsinghani, Ed.. May 1994. (Format: TXT, HTML) (Updates RFC1141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1624) 1625 WAIS over Z39.50-1988. M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1625) 1626 Default IP MTU for use over ATM AAL5. R. Atkinson. May 1994. (Format: TXT, HTML) (Obsoleted by RFC2225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1626) 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified). E. Lear, E. Fair, D. Crocker, T. Kessler. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1918) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1627) 1628 UPS Management Information Base. J. Case, Ed.. May 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1628) 1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, R. Callon, E. Gardner, Y. Rekhter. May 1994. (Format: TXT, HTML) (Obsoletes RFC1237) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1629) 1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web. T. Berners-Lee. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1630) 1631 The IP Network Address Translator (NAT). K. Egevang, P. Francis. May 1994. (Format: TXT, HTML) (Obsoleted by RFC3022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1631) 1632 A Revised Catalog of Available X.500 Implementations. A. Getchell, Ed., S. Sataluri, Ed.. May 1994. (Format: TXT, HTML) (Obsoletes RFC1292) (Obsoleted by RFC2116) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1632) 1633 Integrated Services in the Internet Architecture: an Overview. R. Braden, D. Clark, S. Shenker. June 1994. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1633) 1634 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. May 1994. (Format: TXT, HTML) (Obsoletes RFC1551, RFC1362) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1634) 1635 How to Use Anonymous FTP. P. Deutsch, A. Emtage, A. Marine. May 1994. (Format: TXT, HTML) (Also FYI0024) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1635) 1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994. R. Braden, D. Clark, S. Crocker, C. Huitema. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1636) 1637 DNS NSAP Resource Records. B. Manning, R. Colella. June 1994. (Format: TXT, HTML) (Obsoletes RFC1348) (Obsoleted by RFC1706) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1637) 1638 PPP Bridging Control Protocol (BCP). F. Baker, R. Bowen. June 1994. (Format: TXT, HTML) (Obsoletes RFC1220) (Obsoleted by RFC2878) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1638) 1639 FTP Operation Over Big Address Records (FOOBAR). D. Piscitello. June 1994. (Format: TXT, HTML) (Obsoletes RFC1545) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1639) 1640 The Process for Organization of Internet Standards Working Group (POISED). S. Crocker. June 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1640) 1641 Using Unicode with MIME. D. Goldsmith, M. Davis. July 1994. (Format: TXT, PS, PDF, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1641) 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. July 1994. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC2152) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1642) 1643 Definitions of Managed Objects for the Ethernet-like Interface Types. F. Kastenholz. July 1994. (Format: TXT, HTML) (Obsoletes RFC1623) (Obsoleted by RFC3638) (Status: HISTORIC) (DOI: 10.17487/RFC1643) 1644 T/TCP -- TCP Extensions for Transactions Functional Specification. R. Braden. July 1994. (Format: TXT, HTML) (Obsoleted by RFC6247) (Updates RFC1379) (Status: HISTORIC) (DOI: 10.17487/RFC1644) 1645 Simple Network Paging Protocol - Version 2. A. Gwinn. July 1994. (Format: TXT, HTML) (Obsoletes RFC1568) (Obsoleted by RFC1861) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1645) 1646 TN3270 Extensions for LUname and Printer Selection. C. Graves, T. Butts, M. Angel. July 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1646) 1647 TN3270 Enhancements. B. Kelly. July 1994. (Format: TXT, HTML) (Obsoleted by RFC2355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1647) 1648 Postmaster Convention for X.400 Operations. A. Cargille. July 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1648) 1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community. R. Hagens, A. Hansen. July 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1649) 1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2. F. Kastenholz. August 1994. (Format: TXT, HTML) (Obsoleted by RFC2358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1650) 1651 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT, HTML) (Obsoletes RFC1425) (Obsoleted by RFC1869) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1651) 1652 SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. July 1994. (Format: TXT, HTML) (Obsoletes RFC1426) (Obsoleted by RFC6152) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1652) 1653 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. July 1994. (Format: TXT, HTML) (Obsoletes RFC1427) (Obsoleted by RFC1870) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1653) 1654 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed.. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1654) 1655 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, Ed., P. Gross, Ed.. July 1994. (Format: TXT, HTML) (Obsoletes RFC1268) (Obsoleted by RFC1772) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1655) 1656 BGP-4 Protocol Document Roadmap and Implementation Experience. P. Traina. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1773) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1656) 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2. S. Willis, J. Burruss, J. Chu, Ed.. July 1994. (Format: TXT, HTML) (Obsoleted by RFC4273) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1657) 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2. B. Stewart. July 1994. (Format: TXT, HTML) (Obsoletes RFC1316) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1658) 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2. B. Stewart. July 1994. (Format: TXT, HTML) (Obsoletes RFC1317) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1659) 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2. B. Stewart. July 1994. (Format: TXT, HTML) (Obsoletes RFC1318) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1660) 1661 The Point-to-Point Protocol (PPP). W. Simpson, Ed.. July 1994. (Format: TXT, HTML) (Obsoletes RFC1548) (Updated by RFC2153) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1661) 1662 PPP in HDLC-like Framing. W. Simpson, Ed.. July 1994. (Format: TXT, HTML) (Obsoletes RFC1549) (Also STD0051) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1662) 1663 PPP Reliable Transmission. D. Rand. July 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1663) 1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables. C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. August 1994. (Format: TXT, HTML) (Obsoleted by RFC2163) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1664) 1665 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. July 1994. (Format: TXT, HTML) (Obsoleted by RFC1666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1665) 1666 Definitions of Managed Objects for SNA NAUs using SMIv2. Z. Kielczewski, Ed., D. Kostick, Ed., K. Shih, Ed.. August 1994. (Format: TXT, HTML) (Obsoletes RFC1665) (Status: HISTORIC) (DOI: 10.17487/RFC1666) 1667 Modeling and Simulation Requirements for IPng. S. Symington, D. Wood, M. Pullen. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1667) 1668 Unified Routing Requirements for IPng. D. Estrin, T. Li, Y. Rekhter. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1668) 1669 Market Viability as a IPng Criteria. J. Curran. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1669) 1670 Input to IPng Engineering Considerations. D. Heagerty. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1670) 1671 IPng White Paper on Transition and Other Considerations. B. Carpenter. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1671) 1672 Accounting Requirements for IPng. N. Brownlee. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1672) 1673 Electric Power Research Institute Comments on IPng. R. Skelton. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1673) 1674 A Cellular Industry View of IPng. M. Taylor. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1674) 1675 Security Concerns for IPng. S. Bellovin. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1675) 1676 INFN Requirements for an IPng. A. Ghiselli, D. Salomoni, C. Vistoli. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1676) 1677 Tactical Radio Frequency Communication Requirements for IPng. B. Adamson. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1677) 1678 IPng Requirements of Large Corporate Networks. E. Britton, J. Tavs. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1678) 1679 HPN Working Group Input to the IPng Requirements Solicitation. D. Green, P. Irey, D. Marlow, K. O'Donoghue. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1679) 1680 IPng Support for ATM Services. C. Brazdziunas. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1680) 1681 On Many Addresses per Host. S. Bellovin. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1681) 1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1682) 1683 Multiprotocol Interoperability In IPng. R. Clark, M. Ammar, K. Calvert. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1683) 1684 Introduction to White Pages Services based on X.500. P. Jurg. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1684) 1685 Writing X.400 O/R Names. H. Alvestrand. August 1994. (Format: TXT, HTML) (Also RTR0012) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1685) 1686 IPng Requirements: A Cable Television Industry Viewpoint. M. Vecchi. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1686) 1687 A Large Corporate User's View of IPng. E. Fleischman. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1687) 1688 IPng Mobility Considerations. W. Simpson. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1688) 1689 A Status Report on Networked Information Retrieval: Tools and Groups. J. Foster, Ed.. August 1994. (Format: TXT, HTML) (Also FYI0025) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1689) 1690 Introducing the Internet Engineering and Planning Group (IEPG). G. Huston. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1690) 1691 The Document Architecture for the Cornell Digital Library. W. Turner. August 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1691) 1692 Transport Multiplexing Protocol (TMux). P. Cameron, D. Crocker, D. Cohen, J. Postel. August 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1692) 1693 An Extension to TCP : Partial Order Service. T. Connolly, P. Amer, P. Conrad. November 1994. (Format: TXT, HTML) (Obsoleted by RFC6247) (Status: HISTORIC) (DOI: 10.17487/RFC1693) 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2. T. Brown, Ed., K. Tesink, Ed.. August 1994. (Format: TXT, HTML) (Obsoletes RFC1304) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1694) 1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2. M. Ahmed, Ed., K. Tesink, Ed.. August 1994. (Format: TXT, HTML) (Obsoleted by RFC2515) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1695) 1696 Modem Management Information Base (MIB) using SMIv2. J. Barnes, L. Brown, R. Royston, S. Waldbusser. August 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1696) 1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2. D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith. August 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1697) 1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications. P. Furniss. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1698) 1699 Summary of 1600-1699. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1699) 1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format: TXT, HTML) (Obsoletes RFC1340) (Obsoleted by RFC3232) (Status: HISTORIC) (DOI: 10.17487/RFC1700) 1701 Generic Routing Encapsulation (GRE). S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1701) 1702 Generic Routing Encapsulation over IPv4 networks. S. Hanks, T. Li, D. Farinacci, P. Traina. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1702) 1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures. M. Rose. October 1994. (Format: TXT, HTML) (Obsoletes RFC1569) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1703) 1704 On Internet Authentication. N. Haller, R. Atkinson. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1704) 1705 Six Virtual Inches to the Left: The Problem with IPng. R. Carlson, D. Ficarella. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1705) 1706 DNS NSAP Resource Records. B. Manning, R. Colella. October 1994. (Format: TXT, HTML) (Obsoletes RFC1637) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1706) 1707 CATNIP: Common Architecture for the Internet. M. McGovern, R. Ullmann. October 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1707) 1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3. D. Gowin. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1708) 1709 K-12 Internetworking Guidelines. J. Gargano, D. Wasley. November 1994. (Format: TXT, PS, PDF, HTML) (Also FYI0026) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1709) 1710 Simple Internet Protocol Plus White Paper. R. Hinden. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1710) 1711 Classifications in E-mail Routing. J. Houttuin. October 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1711) 1712 DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner, D. Baldoni. November 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1712) 1713 Tools for DNS debugging. A. Romao. November 1994. (Format: TXT, HTML) (Also FYI0027) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1713) 1714 Referral Whois Protocol (RWhois). S. Williamson, M. Kosters. November 1994. (Format: TXT, PS, PDF, HTML) (Obsoleted by RFC2167) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1714) 1715 The H Ratio for Address Assignment Efficiency. C. Huitema. November 1994. (Format: TXT, HTML) (Updated by RFC3194) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1715) 1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. November 1994. (Format: TXT, HTML) (Obsoleted by RFC1812) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1716) 1717 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr. November 1994. (Format: TXT, HTML) (Obsoleted by RFC1990) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1717) 1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force. IETF Secretariat, G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1539) (Obsoleted by RFC3160) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1718) 1719 A Direction for IPng. P. Gross. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1719) 1720 Internet Official Protocol Standards. J. Postel. November 1994. (Format: TXT, HTML) (Obsoletes RFC1610) (Obsoleted by RFC1780) (Status: HISTORIC) (DOI: 10.17487/RFC1720) 1721 RIP Version 2 Protocol Analysis. G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1387) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1721) 1722 RIP Version 2 Protocol Applicability Statement. G. Malkin. November 1994. (Format: TXT, HTML) (Also STD0057) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1722) 1723 RIP Version 2 - Carrying Additional Information. G. Malkin. November 1994. (Format: TXT, HTML) (Obsoletes RFC1388) (Obsoleted by RFC2453) (Updates RFC1058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1723) 1724 RIP Version 2 MIB Extension. G. Malkin, F. Baker. November 1994. (Format: TXT, HTML) (Obsoletes RFC1389) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1724) 1725 Post Office Protocol - Version 3. J. Myers, M. Rose. November 1994. (Format: TXT, HTML) (Obsoletes RFC1460) (Obsoleted by RFC1939) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1725) 1726 Technical Criteria for Choosing IP The Next Generation (IPng). C. Partridge, F. Kastenholz. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1726) 1727 A Vision of an Integrated Internet Information Service. C. Weider, P. Deutsch. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1727) 1728 Resource Transponders. C. Weider. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1728) 1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1729) 1730 Internet Message Access Protocol - Version 4. M. Crispin. December 1994. (Format: TXT, HTML) (Obsoleted by RFC2060, RFC2061) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1730) 1731 IMAP4 Authentication Mechanisms. J. Myers. December 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1731) 1732 IMAP4 Compatibility with IMAP2 and IMAP2bis. M. Crispin. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1732) 1733 Distributed Electronic Mail Models in IMAP4. M. Crispin. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1733) 1734 POP3 AUTHentication command. J. Myers. December 1994. (Format: TXT, HTML) (Obsoleted by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1734) 1735 NBMA Address Resolution Protocol (NARP). J. Heinanen, R. Govindan. December 1994. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1735) 1736 Functional Recommendations for Internet Resource Locators. J. Kunze. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1736) 1737 Functional Requirements for Uniform Resource Names. K. Sollins, L. Masinter. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1737) 1738 Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McCahill. December 1994. (Format: TXT, HTML) (Obsoleted by RFC4248, RFC4266) (Updated by RFC1808, RFC2368, RFC2396, RFC3986, RFC6196, RFC6270, RFC8089) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1738) 1739 A Primer On Internet and TCP/IP Tools. G. Kessler, S. Shepard. December 1994. (Format: TXT, HTML) (Obsoleted by RFC2151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1739) 1740 MIME Encapsulation of Macintosh Files - MacMIME. P. Faltstrom, D. Crocker, E. Fair. December 1994. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1740) 1741 MIME Content Type for BinHex Encoded Files. P. Faltstrom, D. Crocker, E. Fair. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1741) 1742 AppleTalk Management Information Base II. S. Waldbusser, K. Frisa. January 1995. (Format: TXT, HTML) (Obsoletes RFC1243) (Status: HISTORIC) (DOI: 10.17487/RFC1742) 1743 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT, HTML) (Obsoletes RFC1231) (Obsoleted by RFC1748) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1743) 1744 Observations on the Management of the Internet Address Space. G. Huston. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1744) 1745 BGP4/IDRP for IP---OSPF Interaction. K. Varadhan, S. Hares, Y. Rekhter. December 1994. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1745) 1746 Ways to Define User Expectations. B. Manning, D. Perkins. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1746) 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2. J. Hilgeman, S. Nix, A. Bartky, W. Clark, Ed.. January 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1747) 1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker. December 1994. (Format: TXT, HTML) (Obsoletes RFC1743, RFC1231) (Updated by RFC1749) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1748) 1749 IEEE 802.5 Station Source Routing MIB using SMIv2. K. McCloghrie, F. Baker, E. Decker. December 1994. (Format: TXT, HTML) (Updates RFC1748) (Status: HISTORIC) (DOI: 10.17487/RFC1749) 1750 Randomness Recommendations for Security. D. Eastlake 3rd, S. Crocker, J. Schiller. December 1994. (Format: TXT, HTML) (Obsoleted by RFC4086) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1750) 1751 A Convention for Human-Readable 128-bit Keys. D. McDonald. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1751) 1752 The Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. January 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1752) 1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture. N. Chiappa. December 1994. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1753) 1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1. M. Laubach. January 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1754) 1755 ATM Signaling Support for IP over ATM. M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis. February 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1755) 1756 Remote Write Protocol - Version 1.0. T. Rinne. January 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1756) 1757 Remote Network Monitoring Management Information Base. S. Waldbusser. February 1995. (Format: TXT, HTML) (Obsoletes RFC1271) (Obsoleted by RFC2819) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1757) 1758 NADF Standing Documents: A Brief Overview. The North American Directory Forum. February 1995. (Format: TXT, HTML) (Obsoletes RFC1417) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1758) 1759 Printer MIB. R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. March 1995. (Format: TXT, HTML) (Obsoleted by RFC3805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1759) 1760 The S/KEY One-Time Password System. N. Haller. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1760) 1761 Snoop Version 2 Packet Capture File Format. B. Callaghan, R. Gilligan. February 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1761) 1762 The PPP DECnet Phase IV Control Protocol (DNCP). S. Senum. March 1995. (Format: TXT, HTML) (Obsoletes RFC1376) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1762) 1763 The PPP Banyan Vines Control Protocol (BVCP). S. Senum. March 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1763) 1764 The PPP XNS IDP Control Protocol (XNSCP). S. Senum. March 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1764) 1765 OSPF Database Overflow. J. Moy. March 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1765) 1766 Tags for the Identification of Languages. H. Alvestrand. March 1995. (Format: TXT, HTML) (Obsoleted by RFC3066, RFC3282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1766) 1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1767) 1768 Host Group Extensions for CLNP Multicasting. D. Marlow. March 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1768) 1769 Simple Network Time Protocol (SNTP). D. Mills. March 1995. (Format: TXT, HTML) (Obsoletes RFC1361) (Obsoleted by RFC2030, RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1769) 1770 IPv4 Option for Sender Directed Multi-Destination Delivery. C. Graff. March 1995. (Format: TXT, HTML) (Obsoleted by RFC6814) (Status: HISTORIC) (DOI: 10.17487/RFC1770) 1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. March 1995. (Format: TXT, HTML) (Obsoletes RFC1654) (Obsoleted by RFC4271) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1771) 1772 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. March 1995. (Format: TXT, HTML) (Obsoletes RFC1655) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1772) 1773 Experience with the BGP-4 protocol. P. Traina. March 1995. (Format: TXT, HTML) (Obsoletes RFC1656) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1773) 1774 BGP-4 Protocol Analysis. P. Traina, Ed.. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1774) 1775 To Be "On" the Internet. D. Crocker. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1775) 1776 The Address is the Message. S. Crocker. 1 April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1776) 1777 Lightweight Directory Access Protocol. W. Yeong, T. Howes, S. Kille. March 1995. (Format: TXT, HTML) (Obsoletes RFC1487) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1777) 1778 The String Representation of Standard Attribute Syntaxes. T. Howes, S. Kille, W. Yeong, C. Robbins. March 1995. (Format: TXT, HTML) (Obsoletes RFC1488) (Obsoleted by RFC3494) (Updated by RFC2559) (Status: HISTORIC) (DOI: 10.17487/RFC1778) 1779 A String Representation of Distinguished Names. S. Kille. March 1995. (Format: TXT, HTML) (Obsoletes RFC1485) (Obsoleted by RFC2253, RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1779) 1780 Internet Official Protocol Standards. J. Postel, Ed.. March 1995. (Format: TXT, HTML) (Obsoletes RFC1720) (Obsoleted by RFC1800) (Status: HISTORIC) (DOI: 10.17487/RFC1780) 1781 Using the OSI Directory to Achieve User Friendly Naming. S. Kille. March 1995. (Format: TXT, HTML) (Obsoletes RFC1484) (Obsoleted by RFC3494) (Status: HISTORIC) (DOI: 10.17487/RFC1781) 1782 TFTP Option Extension. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2347) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1782) 1783 TFTP Blocksize Option. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2348) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1783) 1784 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Obsoleted by RFC2349) (Updates RFC1350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1784) 1785 TFTP Option Negotiation Analysis. G. Malkin, A. Harkin. March 1995. (Format: TXT, HTML) (Updates RFC1350) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1785) 1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++). T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu. March 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1786) 1787 Routing in a Multi-provider Internet. Y. Rekhter. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1787) 1788 ICMP Domain Name Messages. W. Simpson. April 1995. (Format: TXT, HTML) (Obsoleted by RFC6918) (Status: HISTORIC) (DOI: 10.17487/RFC1788) 1789 INETPhone: Telephone Services and Servers on Internet. C. Yang. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1789) 1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols. V. Cerf. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1790) 1791 TCP And UDP Over IPX Networks With Fixed Path MTU. T. Sung. April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1791) 1792 TCP/IPX Connection Mib Specification. T. Sung. April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1792) 1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. (Format: TXT, HTML) (Updated by RFC3883) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1793) 1794 DNS Support for Load Balancing. T. Brisco. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1794) 1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1. L. Wells, A. Bartky, Ed.. April 1995. (Format: TXT, HTML) (Obsoletes RFC1434) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1795) 1796 Not All RFCs are Standards. C. Huitema, J. Postel, S. Crocker. April 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1796) 1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA). April 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1797) 1798 Connection-less Lightweight X.500 Directory Access Protocol. A. Young. June 1995. (Format: TXT, HTML) (Obsoleted by RFC3352) (Status: HISTORIC) (DOI: 10.17487/RFC1798) 1799 Request for Comments Summary RFC Numbers 1700-1799. M. Kennedy. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1799) 1800 Internet Official Protocol Standards. J. Postel, Ed.. July 1995. (Format: TXT, HTML) (Obsoletes RFC1780) (Obsoleted by RFC1880) (Status: HISTORIC) (DOI: 10.17487/RFC1800) 1801 MHS use of the X.500 Directory to support MHS Routing. S. Kille. June 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1801) 1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing. H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1802) 1803 Recommendations for an X.500 Production Directory Service. R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1803) 1804 Schema Publishing in X.500 Directory. G. Mansfield, P. Rajeev, S. Raghavan, T. Howes. June 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1804) 1805 Location-Independent Data/Software Integrity Protocol. A. Rubin. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1805) 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header. R. Troost, S. Dorner. June 1995. (Format: TXT, HTML) (Obsoleted by RFC2183) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1806) 1807 A Format for Bibliographic Records. R. Lasher, D. Cohen. June 1995. (Format: TXT, HTML) (Obsoletes RFC1357) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1807) 1808 Relative Uniform Resource Locators. R. Fielding. June 1995. (Format: TXT, HTML) (Obsoleted by RFC3986) (Updates RFC1738) (Updated by RFC2368, RFC2396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1808) 1809 Using the Flow Label Field in IPv6. C. Partridge. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1809) 1810 Report on MD5 Performance. J. Touch. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1810) 1811 U.S. Government Internet Domain Names. Federal Networking Council. June 1995. (Format: TXT, HTML) (Obsoleted by RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1811) 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT, HTML) (Obsoletes RFC1716, RFC1009) (Updated by RFC2644, RFC6633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1812) 1813 NFS Version 3 Protocol Specification. B. Callaghan, B. Pawlowski, P. Staubach. June 1995. (Format: TXT, HTML) (Also RFC1094) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1813) 1814 Unique Addresses are Good. E. Gerich. June 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1814) 1815 Character Sets ISO-10646 and ISO-10646-J-1. M. Ohta. July 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1815) 1816 U.S. Government Internet Domain Names. Federal Networking Council. August 1995. (Format: TXT, HTML) (Obsoletes RFC1811) (Obsoleted by RFC2146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1816) 1817 CIDR and Classful Routing. Y. Rekhter. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1817) 1818 Best Current Practices. J. Postel, T. Li, Y. Rekhter. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1818) 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+. L. Delgrossi, Ed., L. Berger, Ed.. August 1995. (Format: TXT, HTML) (Obsoletes RFC1190, IEN119) (Status: HISTORIC) (DOI: 10.17487/RFC1819) 1820 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT, HTML) (Obsoleted by RFC1844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1820) 1821 Integration of Real-time Services in an IP-ATM Network Architecture. M. Borden, E. Crawley, B. Davie, S. Batsell. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1821) 1822 A Grant of Rights to Use a Specific IBM patent with Photuris. J. Lowe. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1822) 1823 The LDAP Application Program Interface. T. Howes, M. Smith. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1823) 1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4). H. Danisch. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1824) 1825 Security Architecture for the Internet Protocol. R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1825) 1826 IP Authentication Header. R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1826) 1827 IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1827) 1828 IP Authentication using Keyed MD5. P. Metzger, W. Simpson. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1828) 1829 The ESP DES-CBC Transform. P. Karn, P. Metzger, W. Simpson. August 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1829) 1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. August 1995. (Format: TXT, HTML) (Obsoleted by RFC3030) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1830) 1831 RPC: Remote Procedure Call Protocol Specification Version 2. R. Srinivasan. August 1995. (Format: TXT, HTML) (Obsoleted by RFC5531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1831) 1832 XDR: External Data Representation Standard. R. Srinivasan. August 1995. (Format: TXT, HTML) (Obsoleted by RFC4506) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1832) 1833 Binding Protocols for ONC RPC Version 2. R. Srinivasan. August 1995. (Format: TXT, HTML) (Updated by RFC5665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1833) 1834 Whois and Network Information Lookup Service, Whois++. J. Gargano, K. Weiss. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1834) 1835 Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. Faltstrom, C. Weider. August 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1835) 1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2294) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1836) 1837 Representing Tables and Subtrees in the X.500 Directory. S. Kille. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2293) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1837) 1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses. S. Kille. August 1995. (Format: TXT, HTML) (Obsoleted by RFC2164) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1838) 1839 Not Issued. 1840 Not Issued. 1841 PPP Network Control Protocol for LAN Extension. J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett. September 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1841) 1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages. Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1842) 1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters. F. Lee. August 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1843) 1844 Multimedia E-mail (MIME) User Agent Checklist. E. Huizer. August 1995. (Format: TXT, HTML) (Obsoletes RFC1820) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1844) 1845 SMTP Service Extension for Checkpoint/Restart. D. Crocker, N. Freed, A. Cargille. September 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1845) 1846 SMTP 521 Reply Code. A. Durand, F. Dupont. September 1995. (Format: TXT, HTML) (Updated by RFC7504) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1846) 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. J. Galvin, S. Murphy, S. Crocker, N. Freed. October 1995. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1847) 1848 MIME Object Security Services. S. Crocker, N. Freed, J. Galvin, S. Murphy. October 1995. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1848) 1849 "Son of 1036": News Article Format and Transmission. H. Spencer. March 2010. (Format: TXT, HTML) (Obsoleted by RFC5536, RFC5537) (Status: HISTORIC) (DOI: 10.17487/RFC1849) 1850 OSPF Version 2 Management Information Base. F. Baker, R. Coltun. November 1995. (Format: TXT, HTML) (Obsoletes RFC1253) (Obsoleted by RFC4750) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1850) 1851 The ESP Triple DES Transform. P. Karn, P. Metzger, W. Simpson. September 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1851) 1852 IP Authentication using Keyed SHA. P. Metzger, W. Simpson. September 1995. (Format: TXT, HTML) (Obsoleted by RFC2841) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1852) 1853 IP in IP Tunneling. W. Simpson. October 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1853) 1854 SMTP Service Extension for Command Pipelining. N. Freed. October 1995. (Format: TXT, HTML) (Obsoleted by RFC2197) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1854) 1855 Netiquette Guidelines. S. Hambridge. October 1995. (Format: TXT, HTML) (Also FYI0028) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1855) 1856 The Opstat Client-Server Model for Statistics Retrieval. H. Clark. September 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1856) 1857 A Model for Common Operational Statistics. M. Lambert. October 1995. (Format: TXT, HTML) (Obsoletes RFC1404) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1857) 1858 Security Considerations for IP Fragment Filtering. G. Ziemba, D. Reed, P. Traina. October 1995. (Format: TXT, HTML) (Updated by RFC3128) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1858) 1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension. Y. Pouffary. October 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1859) 1860 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. October 1995. (Format: TXT, HTML) (Obsoleted by RFC1878) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1860) 1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced. A. Gwinn. October 1995. (Format: TXT, HTML) (Obsoletes RFC1645) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1861) 1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994. M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider. November 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1862) 1863 A BGP/IDRP Route Server alternative to a full mesh routing. D. Haskin. October 1995. (Format: TXT, HTML) (Obsoleted by RFC4223) (Status: HISTORIC) (DOI: 10.17487/RFC1863) 1864 The Content-MD5 Header Field. J. Myers, M. Rose. October 1995. (Format: TXT, HTML) (Obsoletes RFC1544) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1864) 1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet. W. Houser, J. Griffin, C. Hage. January 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1865) 1866 Hypertext Markup Language - 2.0. T. Berners-Lee, D. Connolly. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1866) 1867 Form-based File Upload in HTML. E. Nebel, L. Masinter. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1867) 1868 ARP Extension - UNARP. G. Malkin. November 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1868) 1869 SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. November 1995. (Format: TXT, HTML) (Obsoletes RFC1651) (Obsoleted by RFC2821) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1869) 1870 SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, K. Moore. November 1995. (Format: TXT, HTML) (Obsoletes RFC1653) (Also STD0010) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1870) 1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November 1995. (Format: TXT, HTML) (Obsoleted by RFC2026) (Updates RFC1602, RFC1603) (Status: HISTORIC) (DOI: 10.17487/RFC1871) 1872 The MIME Multipart/Related Content-type. E. Levinson. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2112) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1872) 1873 Message/External-Body Content-ID Access Type. E. Levinson. December 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1873) 1874 SGML Media Types. E. Levinson. December 1995. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1874) 1875 UNINETT PCA Policy Statements. N. Berge. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1875) 1876 A Means for Expressing Location Information in the Domain Name System. C. Davis, P. Vixie, T. Goodwin, I. Dickinson. January 1996. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1876) 1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses. S. Cobb. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1877) 1878 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning. December 1995. (Format: TXT, HTML) (Obsoletes RFC1860) (Status: HISTORIC) (DOI: 10.17487/RFC1878) 1879 Class A Subnet Experiment Results and Recommendations. B. Manning, Ed.. January 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1879) 1880 Internet Official Protocol Standards. J. Postel, Ed.. November 1995. (Format: TXT, HTML) (Obsoletes RFC1800) (Obsoleted by RFC1920) (Status: HISTORIC) (DOI: 10.17487/RFC1880) 1881 IPv6 Address Allocation Management. IAB, IESG. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1881) 1882 The 12-Days of Technology Before Christmas. B. Hancock. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1882) 1883 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1883) 1884 IP Version 6 Addressing Architecture. R. Hinden, Ed., S. Deering, Ed.. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2373) (Status: HISTORIC) (DOI: 10.17487/RFC1884) 1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6). A. Conta, S. Deering. December 1995. (Format: TXT, HTML) (Obsoleted by RFC2463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1885) 1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema. December 1995. (Format: TXT, HTML) (Obsoleted by RFC3596) (Updated by RFC2874, RFC3152) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1886) 1887 An Architecture for IPv6 Unicast Address Allocation. Y. Rekhter, Ed., T. Li, Ed.. December 1995. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1887) 1888 OSI NSAPs and IPv6. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. August 1996. (Format: TXT, HTML) (Obsoleted by RFC4048) (Updated by RFC4548) (Status: HISTORIC) (DOI: 10.17487/RFC1888) 1889 RTP: A Transport Protocol for Real-Time Applications. Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1889) 1890 RTP Profile for Audio and Video Conferences with Minimal Control. Audio-Video Transport Working Group, H. Schulzrinne. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1890) 1891 SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1891) 1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1892) 1893 Enhanced Mail System Status Codes. G. Vaudreuil. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1893) 1894 An Extensible Message Format for Delivery Status Notifications. K. Moore, G. Vaudreuil. January 1996. (Format: TXT, HTML) (Obsoleted by RFC3464) (Updated by RFC2852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1894) 1895 The Application/CALS-1840 Content-type. E. Levinson. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1895) 1896 The text/enriched MIME Content-type. P. Resnick, A. Walker. February 1996. (Format: TXT, PS, HTML) (Obsoletes RFC1523, RFC1563) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1896) 1897 IPv6 Testing Address Allocation. R. Hinden, J. Postel. January 1996. (Format: TXT, HTML) (Obsoleted by RFC2471) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1897) 1898 CyberCash Credit Card Protocol Version 0.8. D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1898) 1899 Request for Comments Summary RFC Numbers 1800-1899. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1899) 1900 Renumbering Needs Work. B. Carpenter, Y. Rekhter. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1900) 1901 Introduction to Community-based SNMPv2. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1901) 1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1442) (Obsoleted by RFC2578) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1902) 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1443) (Obsoleted by RFC2579) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1903) 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1444) (Obsoleted by RFC2580) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1904) 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1448) (Obsoleted by RFC3416) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1905) 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1449) (Obsoleted by RFC3417) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1906) 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1450) (Obsoleted by RFC3418) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1907) 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT, HTML) (Obsoletes RFC1452) (Obsoleted by RFC2576) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1908) 1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie, Ed.. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1909) 1910 User-based Security Model for SNMPv2. G. Waters, Ed.. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1910) 1911 Voice Profile for Internet Mail. G. Vaudreuil. February 1996. (Format: TXT, HTML) (Obsoleted by RFC2421, RFC2422, RFC2423) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1911) 1912 Common DNS Operational and Configuration Errors. D. Barr. February 1996. (Format: TXT, HTML) (Obsoletes RFC1537) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1912) 1913 Architecture of the Whois++ Index Service. C. Weider, J. Fullton, S. Spero. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1913) 1914 How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz, C. Weider. February 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC1914) 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol. F. Kastenholz. February 1996. (Format: TXT, HTML) (Also BCP0003) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1915) 1916 Enterprise Renumbering: Experience and Information Solicitation. H. Berkowitz, P. Ferguson, W. Leland, P. Nesser. February 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1916) 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA. P. Nesser II. February 1996. (Format: TXT, HTML) (Also BCP0004) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1917) 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT, HTML) (Obsoletes RFC1627, RFC1597) (Updated by RFC6761) (Also BCP0005) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1918) 1919 Classical versus Transparent IP Proxies. M. Chatel. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1919) 1920 Internet Official Protocol Standards. J. Postel. March 1996. (Format: TXT, HTML) (Obsoletes RFC1880) (Obsoleted by RFC2000) (Status: HISTORIC) (DOI: 10.17487/RFC1920) 1921 TNVIP Protocol. J. Dujonc. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1921) 1922 Chinese Character Encoding for Internet Messages. HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1922) 1923 RIPv1 Applicability Statement for Historic Status. J. Halpern, S. Bradner. March 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1923) 1924 A Compact Representation of IPv6 Addresses. R. Elz. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1924) 1925 The Twelve Networking Truths. R. Callon. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1925) 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1926) 1927 Suggested Additional MIME Types for Associating Documents. C. Rogers. 1 April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1927) 1928 SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. March 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1928) 1929 Username/Password Authentication for SOCKS V5. M. Leech. March 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1929) 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS). J. Hawkinson, T. Bates. March 1996. (Format: TXT, HTML) (Updated by RFC6996, RFC7300) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1930) 1931 Dynamic RARP Extensions for Automatic Network Address Acquisition. D. Brownell. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1931) 1932 IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1932) 1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. April 1996. (Format: TXT, HTML) (Obsoleted by RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1933) 1934 Ascend's Multilink Protocol Plus (MP+). K. Smith. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1934) 1935 What is the Internet, Anyway?. J. Quarterman, S. Carl-Mitchell. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1935) 1936 Implementing the Internet Checksum in Hardware. J. Touch, B. Parham. April 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1936) 1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks. Y. Rekhter, D. Kandlur. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1937) 1938 A One-Time Password System. N. Haller, C. Metz. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2289) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1938) 1939 Post Office Protocol - Version 3. J. Myers, M. Rose. May 1996. (Format: TXT, HTML) (Obsoletes RFC1725) (Updated by RFC1957, RFC2449, RFC6186, RFC8314) (Also STD0053) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC1939) 1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1). D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1940) 1941 Frequently Asked Questions for Schools. J. Sellers, J. Robichaux. May 1996. (Format: TXT, HTML) (Obsoletes RFC1578) (Also FYI0022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1941) 1942 HTML Tables. D. Raggett. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1942) 1943 Building an X.500 Directory Service in the US. B. Jennings. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1943) 1944 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. May 1996. (Format: TXT, HTML) (Obsoleted by RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1944) 1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding, H. Frystyk. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1945) 1946 Native ATM Support for ST2+. S. Jackowski. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1946) 1947 Greek Character Encoding for Electronic Mail Messages. D. Spinellis. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1947) 1948 Defending Against Sequence Number Attacks. S. Bellovin. May 1996. (Format: TXT, HTML) (Obsoleted by RFC6528) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1948) 1949 Scalable Multicast Key Distribution. A. Ballardie. May 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1949) 1950 ZLIB Compressed Data Format Specification version 3.3. P. Deutsch, J-L. Gailly. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1950) 1951 DEFLATE Compressed Data Format Specification version 1.3. P. Deutsch. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1951) 1952 GZIP file format specification version 4.3. P. Deutsch. May 1996. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1952) 1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1953) 1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. May 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1954) 1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG. R. Hinden. June 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1955) 1956 Registration in the MIL Domain. D. Engebretson, R. Plzak. June 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1956) 1957 Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June 1996. (Format: TXT, HTML) (Updates RFC1939) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1957) 1958 Architectural Principles of the Internet. B. Carpenter, Ed.. June 1996. (Format: TXT, HTML) (Updated by RFC3439) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1958) 1959 An LDAP URL Format. T. Howes, M. Smith. June 1996. (Format: TXT, HTML) (Obsoleted by RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1959) 1960 A String Representation of LDAP Search Filters. T. Howes. June 1996. (Format: TXT, HTML) (Obsoletes RFC1558) (Obsoleted by RFC2254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1960) 1961 GSS-API Authentication Method for SOCKS Version 5. P. McMahon. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1961) 1962 The PPP Compression Control Protocol (CCP). D. Rand. June 1996. (Format: TXT, HTML) (Updated by RFC2153) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1962) 1963 PPP Serial Data Transport Protocol (SDTP). K. Schneider, S. Venters. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1963) 1964 The Kerberos Version 5 GSS-API Mechanism. J. Linn. June 1996. (Format: TXT, HTML) (Updated by RFC4121, RFC6649) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1964) 1965 Autonomous System Confederations for BGP. P. Traina. June 1996. (Format: TXT, HTML) (Obsoleted by RFC3065) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1965) 1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates, R. Chandra. June 1996. (Format: TXT, HTML) (Obsoleted by RFC4456) (Updated by RFC2796) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1966) 1967 PPP LZS-DCP Compression Protocol (LZS-DCP). K. Schneider, R. Friend. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1967) 1968 The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1968) 1969 The PPP DES Encryption Protocol (DESE). K. Sklower, G. Meyer. June 1996. (Format: TXT, HTML) (Obsoleted by RFC2419) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1969) 1970 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1970) 1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1971) 1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1972) 1973 PPP in Frame Relay. W. Simpson. June 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1973) 1974 PPP Stac LZS Compression Protocol. R. Friend, W. Simpson. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1974) 1975 PPP Magnalink Variable Resource Compression. D. Schremp, J. Black, J. Weiss. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1975) 1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE). K. Schneider, S. Venters. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1976) 1977 PPP BSD Compression Protocol. V. Schryver. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1977) 1978 PPP Predictor Compression Protocol. D. Rand. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1978) 1979 PPP Deflate Protocol. J. Woods. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1979) 1980 A Proposed Extension to HTML : Client-Side Image Maps. J. Seidman. August 1996. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC1980) 1981 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul. August 1996. (Format: TXT, HTML) (Obsoleted by RFC8201) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1981) 1982 Serial Number Arithmetic. R. Elz, R. Bush. August 1996. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1982) 1983 Internet Users' Glossary. G. Malkin, Ed.. August 1996. (Format: TXT, HTML) (Obsoletes RFC1392) (Also FYI0018) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1983) 1984 IAB and IESG Statement on Cryptographic Technology and the Internet. IAB, IESG. August 1996. (Format: TXT, HTML) (Also BCP0200) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC1984) 1985 SMTP Service Extension for Remote Message Queue Starting. J. De Winter. August 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1985) 1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP). W. Polites, W. Wollman, D. Woo, R. Langan. August 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC1986) 1987 Ipsilon's General Switch Management Protocol Specification Version 1.1. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. August 1996. (Format: TXT, HTML) (Updated by RFC2297) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1987) 1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework. G. McAnally, D. Gilbert, J. Flick. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1988) 1989 PPP Link Quality Monitoring. W. Simpson. August 1996. (Format: TXT, HTML) (Obsoletes RFC1333) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1989) 1990 The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti. August 1996. (Format: TXT, HTML) (Obsoletes RFC1717) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1990) 1991 PGP Message Exchange Formats. D. Atkins, W. Stallings, P. Zimmermann. August 1996. (Format: TXT, HTML) (Obsoleted by RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1991) 1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M. Steenstrup. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1992) 1993 PPP Gandalf FZA Compression Protocol. A. Barbir, D. Carr, W. Simpson. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1993) 1994 PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996. (Format: TXT, HTML) (Obsoletes RFC1334) (Updated by RFC2484) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC1994) 1995 Incremental Zone Transfer in DNS. M. Ohta. August 1996. (Format: TXT, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1995) 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996. (Format: TXT, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1996) 1997 BGP Communities Attribute. R. Chandra, P. Traina, T. Li. August 1996. (Format: TXT, HTML) (Updated by RFC7606, RFC8642) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC1997) 1998 An Application of the BGP Community Attribute in Multi-home Routing. E. Chen, T. Bates. August 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1998) 1999 Request for Comments Summary RFC Numbers 1900-1999. J. Elliott. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC1999) 2000 Internet Official Protocol Standards. J. Postel, Ed.. February 1997. (Format: TXT, HTML) (Obsoletes RFC1920) (Obsoleted by RFC2200) (Status: HISTORIC) (DOI: 10.17487/RFC2000) 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2001) 2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT, HTML) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2002) 2003 IP Encapsulation within IP. C. Perkins. October 1996. (Format: TXT, HTML) (Updated by RFC3168, RFC6864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2003) 2004 Minimal Encapsulation within IP. C. Perkins. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2004) 2005 Applicability Statement for IP Mobility Support. J. Solomon. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2005) 2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2. D. Cong, M. Hamlen, C. Perkins. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2006) 2007 Catalogue of Network Training Materials. J. Foster, M. Isaacs, M. Prior. October 1996. (Format: TXT, HTML) (Also FYI0029) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2007) 2008 Implications of Various Address Allocation Policies for Internet Routing. Y. Rekhter, T. Li. October 1996. (Format: TXT, HTML) (Also BCP0007) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2008) 2009 GPS-Based Addressing and Routing. T. Imielinski, J. Navas. November 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2009) 2010 Operational Criteria for Root Name Servers. B. Manning, P. Vixie. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2870) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2010) 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT, HTML) (Obsoleted by RFC4293) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2011) 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT, HTML) (Obsoleted by RFC4022) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2012) 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2. K. McCloghrie, Ed.. November 1996. (Format: TXT, HTML) (Obsoleted by RFC4113) (Updates RFC1213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2013) 2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J. Postel. October 1996. (Format: TXT, HTML) (Also BCP0008) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2014) 2015 MIME Security with Pretty Good Privacy (PGP). M. Elkins. October 1996. (Format: TXT, HTML) (Updated by RFC3156) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2015) 2016 Uniform Resource Agents (URAs). L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan. October 1996. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2016) 2017 Definition of the URL MIME External-Body Access-Type. N. Freed, K. Moore, A. Cargille. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2017) 2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996. (Format: TXT, HTML) (Obsoletes RFC1072) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2018) 2019 Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2019) 2020 IEEE 802.12 Interface MIB. J. Flick. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2020) 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2. S. Waldbusser. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2021) 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks. G. Armitage. November 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2022) 2023 IP Version 6 over PPP. D. Haskin, E. Allen. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2023) 2024 Definitions of Managed Objects for Data Link Switching using SMIv2. D. Chen, Ed., P. Gayek, S. Nix. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2024) 2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2025) 2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. (Format: TXT, HTML) (Obsoletes RFC1602, RFC1871) (Updated by RFC3667, RFC3668, RFC3932, RFC3978, RFC3979, RFC5378, RFC5657, RFC5742, RFC6410, RFC7100, RFC7127, RFC7475, RFC8179, RFC8789) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2026) 2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2282) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2027) 2028 The Organizations Involved in the IETF Standards Process. R. Hovey, S. Bradner. October 1996. (Format: TXT, HTML) (Updated by RFC3668, RFC3979, RFC8717) (Also BCP0011) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2028) 2029 RTP Payload Format of Sun's CellB Video Encoding. M. Speer, D. Hoffman. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2029) 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996. (Format: TXT, HTML) (Obsoletes RFC1769) (Obsoleted by RFC4330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2030) 2031 IETF-ISOC relationship. E. Huizer. October 1996. (Format: TXT, HTML) (Obsoleted by RFC8712) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2031) 2032 RTP Payload Format for H.261 Video Streams. T. Turletti, C. Huitema. October 1996. (Format: TXT, HTML) (Obsoleted by RFC4587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2032) 2033 Local Mail Transfer Protocol. J. Myers. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2033) 2034 SMTP Service Extension for Returning Enhanced Error Codes. N. Freed. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2034) 2035 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, R. Frederick, S. McCanne. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2435) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2035) 2036 Observations on the use of Components of the Class A Address Space within the Internet. G. Huston. October 1996. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2036) 2037 Entity MIB using SMIv2. K. McCloghrie, A. Bierman. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2737) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2037) 2038 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. Fernando, V. Goyal. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2250) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2038) 2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers. C. Kalbfleisch. November 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2039) 2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms. R. Baldwin, R. Rivest. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2040) 2041 Mobile Network Tracing. B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2041) 2042 Registering New BGP Attribute Types. B. Manning. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2042) 2043 The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2043) 2044 UTF-8, a transformation format of Unicode and ISO 10646. F. Yergeau. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2279) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2044) 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231, RFC5335, RFC6532) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2045) 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2646, RFC3798, RFC5147, RFC6657, RFC8098) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2046) 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. K. Moore. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Updated by RFC2184, RFC2231) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2047) 2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin, J. Postel. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Obsoleted by RFC4288, RFC4289) (Updated by RFC3023) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2048) 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996. (Format: TXT, HTML) (Obsoletes RFC1521, RFC1522, RFC1590) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2049) 2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: TXT, HTML) (Obsoletes RFC1466) (Obsoleted by RFC7020) (Status: HISTORIC) (DOI: 10.17487/RFC2050) 2051 Definitions of Managed Objects for APPC using SMIv2. M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore. October 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2051) 2052 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie. October 1996. (Format: TXT, HTML) (Obsoleted by RFC2782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2052) 2053 The AM (Armenia) Domain. E. Der-Danieliantz. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2053) 2054 WebNFS Client Specification. B. Callaghan. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2054) 2055 WebNFS Server Specification. B. Callaghan. October 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2055) 2056 Uniform Resource Locators for Z39.50. R. Denenberg, J. Kunze, D. Lynch. November 1996. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2056) 2057 Source Directed Access Control on the Internet. S. Bradner. November 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2057) 2058 Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2058) 2059 RADIUS Accounting. C. Rigney. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2139) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2059) 2060 Internet Message Access Protocol - Version 4rev1. M. Crispin. December 1996. (Format: TXT, HTML) (Obsoletes RFC1730) (Obsoleted by RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2060) 2061 IMAP4 Compatibility with IMAP2bis. M. Crispin. December 1996. (Format: TXT, HTML) (Obsoletes RFC1730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2061) 2062 Internet Message Access Protocol - Obsolete Syntax. M. Crispin. December 1996. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2062) 2063 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2722) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2063) 2064 Traffic Flow Measurement: Meter MIB. N. Brownlee. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2720) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2064) 2065 Domain Name System Security Extensions. D. Eastlake 3rd, C. Kaufman. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2535) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2065) 2066 TELNET CHARSET Option. R. Gellens. January 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2066) 2067 IP over HIPPI. J. Renwick. January 1997. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2067) 2068 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2068) 2069 An Extension to HTTP : Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2069) 2070 Internationalization of the Hypertext Markup Language. F. Yergeau, G. Nicol, G. Adams, M. Duerst. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2854) (Status: HISTORIC) (DOI: 10.17487/RFC2070) 2071 Network Renumbering Overview: Why would I want it and what is it anyway?. P. Ferguson, H. Berkowitz. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2071) 2072 Router Renumbering Guide. H. Berkowitz. January 1997. (Format: TXT, HTML) (Updated by RFC4192) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2072) 2073 An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2374) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2073) 2074 Remote Network Monitoring MIB Protocol Identifiers. A. Bierman, R. Iddon. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2074) 2075 IP Echo Host Service. C. Partridge. January 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2075) 2076 Common Internet Message Headers. J. Palme. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2076) 2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions. S. Nelson, C. Parks, Mitra. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2077) 2078 Generic Security Service Application Program Interface, Version 2. J. Linn. January 1997. (Format: TXT, HTML) (Obsoletes RFC1508) (Obsoleted by RFC2743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2078) 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2079) 2080 RIPng for IPv6. G. Malkin, R. Minnear. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2080) 2081 RIPng Protocol Applicability Statement. G. Malkin. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2081) 2082 RIP-2 MD5 Authentication. F. Baker, R. Atkinson. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2082) 2083 PNG (Portable Network Graphics) Specification Version 1.0. T. Boutell. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2083) 2084 Considerations for Web Transaction Security. G. Bossert, S. Cooper, W. Drummond. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2084) 2085 HMAC-MD5 IP Authentication with Replay Prevention. M. Oehler, R. Glenn. February 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2085) 2086 IMAP4 ACL extension. J. Myers. January 1997. (Format: TXT, HTML) (Obsoleted by RFC4314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2086) 2087 IMAP4 QUOTA extension. J. Myers. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2087) 2088 IMAP4 non-synchronizing literals. J. Myers. January 1997. (Format: TXT, HTML) (Obsoleted by RFC7888) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2088) 2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent. B. Wijnen, D. Levi. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2576) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2089) 2090 TFTP Multicast Option. A. Emberson. February 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2090) 2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer, S. Sherry. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2091) 2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2092) 2093 Group Key Management Protocol (GKMP) Specification. H. Harney, C. Muckenhirn. July 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2093) 2094 Group Key Management Protocol (GKMP) Architecture. H. Harney, C. Muckenhirn. July 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2094) 2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. January 1997. (Format: TXT, HTML) (Obsoleted by RFC2195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2095) 2096 IP Forwarding Table MIB. F. Baker. January 1997. (Format: TXT, HTML) (Obsoletes RFC1354) (Obsoleted by RFC4292) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2096) 2097 The PPP NetBIOS Frames Control Protocol (NBFCP). G. Pall. January 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2097) 2098 Toshiba's Router Architecture Extensions for ATM : Overview. Y. Katsube, K. Nagami, H. Esaki. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2098) 2099 Request for Comments Summary RFC Numbers 2000-2099. J. Elliott. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2099) 2100 The Naming of Hosts. J. Ashworth. 1 April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2100) 2101 IPv4 Address Behaviour Today. B. Carpenter, J. Crowcroft, Y. Rekhter. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2101) 2102 Multicast Support for Nimrod : Requirements and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2102) 2103 Mobility Support for Nimrod : Challenges and Solution Approaches. R. Ramanathan. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2103) 2104 HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997. (Format: TXT, HTML) (Updated by RFC6151) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2104) 2105 Cisco Systems' Tag Switching Architecture Overview. Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2105) 2106 Data Link Switching Remote Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT, HTML) (Obsoleted by RFC2114) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2106) 2107 Ascend Tunnel Management Protocol - ATMP. K. Hamzeh. February 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2107) 2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. February 1997. (Format: TXT, HTML) (Obsoletes RFC1516) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2108) 2109 HTTP State Management Mechanism. D. Kristol, L. Montulli. February 1997. (Format: TXT, HTML) (Obsoleted by RFC2965) (Status: HISTORIC) (DOI: 10.17487/RFC2109) 2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT, HTML) (Obsoleted by RFC2557) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2110) 2111 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. March 1997. (Format: TXT, HTML) (Obsoleted by RFC2392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2111) 2112 The MIME Multipart/Related Content-type. E. Levinson. March 1997. (Format: TXT, HTML) (Obsoletes RFC1872) (Obsoleted by RFC2387) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2112) 2113 IP Router Alert Option. D. Katz. February 1997. (Format: TXT, HTML) (Updated by RFC5350, RFC6398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2113) 2114 Data Link Switching Client Access Protocol. S. Chiang, J. Lee, H. Yasuda. February 1997. (Format: TXT, HTML) (Obsoletes RFC2106) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2114) 2115 Management Information Base for Frame Relay DTEs Using SMIv2. C. Brown, F. Baker. September 1997. (Format: TXT, HTML) (Obsoletes RFC1315) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2115) 2116 X.500 Implementations Catalog-96. C. Apple, K. Rossen. April 1997. (Format: TXT, HTML) (Obsoletes RFC1632) (Also FYI0011) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2116) 2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1997. (Format: TXT, HTML) (Obsoleted by RFC2362) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2117) 2118 Microsoft Point-To-Point Compression (MPPC) Protocol. G. Pall. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2118) 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. (Format: TXT, HTML) (Updated by RFC8174) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2119) 2120 Managing the X.500 Root Naming Context. D. Chadwick. March 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2120) 2121 Issues affecting MARS Cluster Size. G. Armitage. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2121) 2122 VEMMI URL Specification. D. Mavrakis, H. Layec, K. Kartmann. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2122) 2123 Traffic Flow Measurement: Experiences with NeTraMet. N. Brownlee. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2123) 2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0. P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. March 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2124) 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP). C. Richards, K. Smith. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2125) 2126 ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March 1997. (Format: TXT, HTML) (Updates RFC1006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2126) 2127 ISDN Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2127) 2128 Dial Control Management Information Base using SMIv2. G. Roeck, Ed.. March 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2128) 2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification. K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2129) 2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996. C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. April 1997. (Format: TXT, HTML) (Updated by RFC6055) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2130) 2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. (Format: TXT, HTML) (Obsoletes RFC1541) (Updated by RFC3396, RFC4361, RFC5494, RFC6842) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2131) 2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms. March 1997. (Format: TXT, HTML) (Obsoletes RFC1533) (Updated by RFC3442, RFC3942, RFC4361, RFC4833, RFC5494) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2132) 2133 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997. (Format: TXT, HTML) (Obsoleted by RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2133) 2134 Articles of Incorporation of Internet Society. ISOC Board of Trustees. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2134) 2135 Internet Society By-Laws. ISOC Board of Trustees. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2135) 2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format: TXT, HTML) (Updates RFC1035) (Updated by RFC3007, RFC4035, RFC4033, RFC4034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2136) 2137 Secure Domain Name System Dynamic Update. D. Eastlake 3rd. April 1997. (Format: TXT, HTML) (Obsoleted by RFC3007) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2137) 2138 Remote Authentication Dial In User Service (RADIUS). C. Rigney, A. Rubens, W. Simpson, S. Willens. April 1997. (Format: TXT, HTML) (Obsoletes RFC2058) (Obsoleted by RFC2865) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2138) 2139 RADIUS Accounting. C. Rigney. April 1997. (Format: TXT, HTML) (Obsoletes RFC2059) (Obsoleted by RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2139) 2140 TCP Control Block Interdependence. J. Touch. April 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2140) 2141 URN Syntax. R. Moats. May 1997. (Format: TXT, HTML) (Obsoleted by RFC8141) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2141) 2142 Mailbox Names for Common Services, Roles and Functions. D. Crocker. May 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2142) 2143 Encapsulating IP with the Small Computer System Interface. B. Elliston. May 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2143) 2144 The CAST-128 Encryption Algorithm. C. Adams. May 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2144) 2145 Use and Interpretation of HTTP Version Numbers. J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. May 1997. (Format: TXT, HTML) (Obsoleted by RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2145) 2146 U.S. Government Internet Domain Names. Federal Networking Council. May 1997. (Format: TXT, HTML) (Obsoletes RFC1816) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2146) 2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: TXT, HTML) (Obsoleted by RFC2675) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2147) 2148 Deployment of the Internet White Pages Service. H. Alvestrand, P. Jurg. September 1997. (Format: TXT, HTML) (Also BCP0015) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2148) 2149 Multicast Server Architectures for MARS-based ATM multicasting. R. Talpade, M. Ammar. May 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2149) 2150 Humanities and Arts: Sharing Center Stage on the Internet. J. Max, W. Stickle. October 1997. (Format: TXT, HTML) (Also FYI0031) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2150) 2151 A Primer On Internet and TCP/IP Tools and Utilities. G. Kessler, S. Shepard. June 1997. (Format: TXT, HTML) (Obsoletes RFC1739) (Also FYI0030) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2151) 2152 UTF-7 A Mail-Safe Transformation Format of Unicode. D. Goldsmith, M. Davis. May 1997. (Format: TXT, HTML) (Obsoletes RFC1642) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2152) 2153 PPP Vendor Extensions. W. Simpson. May 1997. (Format: TXT, HTML) (Updates RFC1661, RFC1962) (Updated by RFC5342, RFC7042) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2153) 2154 OSPF with Digital Signatures. S. Murphy, M. Badger, B. Wellington. June 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2154) 2155 Definitions of Managed Objects for APPN using SMIv2. B. Clouston, B. Moore. June 1997. (Format: TXT, HTML) (Obsoleted by RFC2455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2155) 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME. S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC0987, RFC1026, RFC1138, RFC1148, RFC1327, RFC1495) (Updates RFC0822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2156) 2157 Mapping between X.400 and RFC-822/MIME Message Bodies. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2157) 2158 X.400 Image Body Parts. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2158) 2159 A MIME Body Part for FAX. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2159) 2160 Carrying PostScript in X.400 and MIME. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2160) 2161 A MIME Body Part for ODA. H. Alvestrand. January 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2161) 2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail. C. Allocchio. January 1998. (Format: TXT, HTML) (Obsoletes RFC1405) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2162) 2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM). C. Allocchio. January 1998. (Format: TXT, HTML) (Obsoletes RFC1664) (Updated by RFC3597) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2163) 2164 Use of an X.500/LDAP directory to support MIXER address mapping. S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2164) 2165 Service Location Protocol. J. Veizades, E. Guttman, C. Perkins, S. Kaplan. June 1997. (Format: TXT, HTML) (Updated by RFC2608, RFC2609) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2165) 2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements. D. Bryant, P. Brittain. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2166) 2167 Referral Whois (RWhois) Protocol V1.5. S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra. June 1997. (Format: TXT, HTML) (Obsoletes RFC1714) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2167) 2168 Resolution of Uniform Resource Identifiers using the Domain Name System. R. Daniel, M. Mealling. June 1997. (Format: TXT, HTML) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updated by RFC2915) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2168) 2169 A Trivial Convention for using HTTP in URN Resolution. R. Daniel. June 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2169) 2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J. Le Boudec, P. Oechslin. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2170) 2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2171) 2172 MAPOS Version 1 Assigned Numbers. M. Maruyama, K. Murakami. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2172) 2173 A MAPOS version 1 Extension - Node Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2173) 2174 A MAPOS version 1 Extension - Switch-Switch Protocol. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2174) 2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2175) 2176 IPv4 over MAPOS Version 1. K. Murakami, M. Maruyama. June 1997. (Format: TXT, HTML) (Updated by RFC5494) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2176) 2177 IMAP4 IDLE command. B. Leiba. June 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2177) 2178 OSPF Version 2. J. Moy. July 1997. (Format: TXT, HTML) (Obsoletes RFC1583) (Obsoleted by RFC2328) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2178) 2179 Network Security For Trade Shows. A. Gwinn. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2179) 2180 IMAP4 Multi-Accessed Mailbox Practice. M. Gahrns. July 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2180) 2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997. (Format: TXT, HTML) (Updates RFC1034, RFC1035, RFC1123) (Updated by RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452, RFC8767) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2181) 2182 Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July 1997. (Format: TXT, HTML) (Also BCP0016) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2182) 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field. R. Troost, S. Dorner, K. Moore, Ed.. August 1997. (Format: TXT, HTML) (Obsoletes RFC1806) (Updated by RFC2184, RFC2231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2183) 2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. August 1997. (Format: TXT, HTML) (Obsoleted by RFC2231) (Updates RFC2045, RFC2047, RFC2183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2184) 2185 Routing Aspects of IPv6 Transition. R. Callon, D. Haskin. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2185) 2186 Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2186) 2187 Application of Internet Cache Protocol (ICP), version 2. D. Wessels, K. Claffy. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2187) 2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2. M. Banan, M. Taylor, J. Cheng. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2188) 2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --. A. Ballardie. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2189) 2190 RTP Payload Format for H.263 Video Streams. C. Zhu. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2190) 2191 VENUS - Very Extensive Non-Unicast Service. G. Armitage. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2191) 2192 IMAP URL Scheme. C. Newman. September 1997. (Format: TXT, HTML) (Obsoleted by RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2192) 2193 IMAP4 Mailbox Referrals. M. Gahrns. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2193) 2194 Review of Roaming Implementations. B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2194) 2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response. J. Klensin, R. Catoe, P. Krumviede. September 1997. (Format: TXT, HTML) (Obsoletes RFC2095) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2195) 2196 Site Security Handbook. B. Fraser. September 1997. (Format: TXT, HTML) (Obsoletes RFC1244) (Also FYI0008) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2196) 2197 SMTP Service Extension for Command Pipelining. N. Freed. September 1997. (Format: TXT, HTML) (Obsoletes RFC1854) (Obsoleted by RFC2920) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2197) 2198 RTP Payload for Redundant Audio Data. C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. September 1997. (Format: TXT, HTML) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2198) 2199 Request for Comments Summary RFC Numbers 2100-2199. A. Ramos. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2199) 2200 Internet Official Protocol Standards. J. Postel. June 1997. (Format: TXT, HTML) (Obsoletes RFC1250, RFC2000) (Obsoleted by RFC2300) (Status: HISTORIC) (DOI: 10.17487/RFC2200) 2201 Core Based Trees (CBT) Multicast Routing Architecture. A. Ballardie. September 1997. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2201) 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1. P. Cheng, R. Glenn. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2202) 2203 RPCSEC_GSS Protocol Specification. M. Eisler, A. Chiu, L. Ling. September 1997. (Format: TXT, HTML) (Updated by RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2203) 2204 ODETTE File Transfer Protocol. D. Nash. September 1997. (Format: TXT, HTML) (Obsoleted by RFC5024) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2204) 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997. (Format: TXT, HTML) (Updated by RFC2750, RFC3936, RFC4495, RFC5946, RFC6437, RFC6780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2205) 2206 RSVP Management Information Base using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2206) 2207 RSVP Extensions for IPSEC Data Flows. L. Berger, T. O'Malley. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2207) 2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment. A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2208) 2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules. R. Braden, L. Zhang. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2209) 2210 The Use of RSVP with IETF Integrated Services. J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2210) 2211 Specification of the Controlled-Load Network Element Service. J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2211) 2212 Specification of Guaranteed Quality of Service. S. Shenker, C. Partridge, R. Guerin. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2212) 2213 Integrated Services Management Information Base using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2213) 2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2. F. Baker, J. Krawczyk, A. Sastry. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2214) 2215 General Characterization Parameters for Integrated Service Network Elements. S. Shenker, J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2215) 2216 Network Element Service Specification Template. S. Shenker, J. Wroclawski. September 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2216) 2217 Telnet Com Port Control Option. G. Clark. October 1997. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2217) 2218 A Common Schema for the Internet White Pages Service. T. Genovese, B. Jennings. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2218) 2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT, HTML) (Also BCP0017) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2219) 2220 The Application/MARC Content-type. R. Guenther. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2220) 2221 IMAP4 Login Referrals. M. Gahrns. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2221) 2222 Simple Authentication and Security Layer (SASL). J. Myers. October 1997. (Format: TXT, HTML) (Obsoleted by RFC4422, RFC4752) (Updated by RFC2444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2222) 2223 Instructions to RFC Authors. J. Postel, J. Reynolds. October 1997. (Format: TXT, HTML) (Obsoletes RFC1543, RFC1111, RFC0825) (Obsoleted by RFC7322) (Updated by RFC5741, RFC6949) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2223) 2224 NFS URL Scheme. B. Callaghan. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2224) 2225 Classical IP and ARP over ATM. M. Laubach, J. Halpern. April 1998. (Format: TXT, HTML) (Obsoletes RFC1626, RFC1577) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2225) 2226 IP Broadcast over ATM Networks. T. Smith, G. Armitage. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2226) 2227 Simple Hit-Metering and Usage-Limiting for HTTP. J. Mogul, P. Leach. October 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2227) 2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2228) 2229 A Dictionary Server Protocol. R. Faith, B. Martin. October 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2229) 2230 Key Exchange Delegation Record for the DNS. R. Atkinson. November 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2230) 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997. (Format: TXT, HTML) (Obsoletes RFC2184) (Updates RFC2045, RFC2047, RFC2183) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2231) 2232 Definitions of Managed Objects for DLUR using SMIv2. B. Clouston, Ed., B. Moore, Ed.. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2232) 2233 The Interfaces Group MIB using SMIv2. K. McCloghrie, F. Kastenholz. November 1997. (Format: TXT, HTML) (Obsoletes RFC1573) (Obsoleted by RFC2863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2233) 2234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. November 1997. (Format: TXT, HTML) (Obsoleted by RFC4234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2234) 2235 Hobbes' Internet Timeline. R. Zakon. November 1997. (Format: TXT, HTML) (Also FYI0032) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2235) 2236 Internet Group Management Protocol, Version 2. W. Fenner. November 1997. (Format: TXT, HTML) (Updates RFC1112) (Updated by RFC3376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2236) 2237 Japanese Character Encoding for Internet Messages. K. Tamaru. November 1997. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2237) 2238 Definitions of Managed Objects for HPR using SMIv2. B. Clouston, Ed., B. Moore, Ed.. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2238) 2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2. K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. November 1997. (Format: TXT, HTML) (Obsoleted by RFC2668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2239) 2240 A Legal Basis for Domain Name Allocation. O. Vaughan. November 1997. (Format: TXT, HTML) (Obsoleted by RFC2352) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2240) 2241 DHCP Options for Novell Directory Services. D. Provan. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2241) 2242 NetWare/IP Domain Name and Information. R. Droms, K. Fong. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2242) 2243 OTP Extended Responses. C. Metz. November 1997. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2243) 2244 ACAP -- Application Configuration Access Protocol. C. Newman, J. G. Myers. November 1997. (Format: TXT, HTML) (Updated by RFC6075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2244) 2245 Anonymous SASL Mechanism. C. Newman. November 1997. (Format: TXT, HTML) (Obsoleted by RFC4505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2245) 2246 The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999. (Format: TXT, HTML) (Obsoleted by RFC4346) (Updated by RFC3546, RFC5746, RFC6176, RFC7465, RFC7507, RFC7919) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2246) 2247 Using Domains in LDAP/X.500 Distinguished Names. S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998. (Format: TXT, HTML) (Updated by RFC4519, RFC4524) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2247) 2248 Network Services Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1565) (Obsoleted by RFC2788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2248) 2249 Mail Monitoring MIB. N. Freed, S. Kille. January 1998. (Format: TXT, HTML) (Obsoletes RFC1566) (Obsoleted by RFC2789) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2249) 2250 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G. Fernando, V. Goyal, M. Civanlar. January 1998. (Format: TXT, HTML) (Obsoletes RFC2038) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2250) 2251 Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S. Kille. December 1997. (Format: TXT, HTML) (Obsoleted by RFC4510, RFC4511, RFC4513, RFC4512) (Updated by RFC3377, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2251) 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. M. Wahl, A. Coulbeck, T. Howes, S. Kille. December 1997. (Format: TXT, HTML) (Obsoleted by RFC4510, RFC4517, RFC4523, RFC4512) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2252) 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. M. Wahl, S. Kille, T. Howes. December 1997. (Format: TXT, HTML) (Obsoletes RFC1779) (Obsoleted by RFC4510, RFC4514) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2253) 2254 The String Representation of LDAP Search Filters. T. Howes. December 1997. (Format: TXT, HTML) (Obsoletes RFC1960) (Obsoleted by RFC4510, RFC4515) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2254) 2255 The LDAP URL Format. T. Howes, M. Smith. December 1997. (Format: TXT, HTML) (Obsoletes RFC1959) (Obsoleted by RFC4510, RFC4516) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2255) 2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M. Wahl. December 1997. (Format: TXT, HTML) (Obsoleted by RFC4517, RFC4519, RFC4523, RFC4512, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2256) 2257 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, D. Francisco. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2741) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2257) 2258 Internet Nomenclator Project. J. Ordille. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2258) 2259 Simple Nomenclator Query Protocol (SNQP). J. Elliott, J. Ordille. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2259) 2260 Scalable Support for Multi-homed Multi-provider Connectivity. T. Bates, Y. Rekhter. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2260) 2261 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2261) 2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2262) 2263 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2273) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2263) 2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2264) 2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2265) 2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices. J. Flick. January 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2266) 2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2827) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2267) 2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2268) 2269 Using the MARS Model in non-ATM NBMA Networks. G. Armitage. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2269) 2270 Using a Dedicated AS for Sites Homed to a Single Provider. J. Stewart, T. Bates, R. Chandra, E. Chen. January 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2270) 2271 An Architecture for Describing SNMP Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoletes RFC2261) (Obsoleted by RFC2571) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2271) 2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoletes RFC2262) (Obsoleted by RFC2572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2272) 2273 SNMPv3 Applications. D. Levi, P. Meyer, B. Stewart. January 1998. (Format: TXT, HTML) (Obsoletes RFC2263) (Obsoleted by RFC2573) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2273) 2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. January 1998. (Format: TXT, HTML) (Obsoletes RFC2264) (Obsoleted by RFC2574) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2274) 2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. January 1998. (Format: TXT, HTML) (Obsoletes RFC2265) (Obsoleted by RFC2575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2275) 2276 Architectural Principles of Uniform Resource Name Resolution. K. Sollins. January 1998. (Format: TXT, HTML) (Updated by RFC3401) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2276) 2277 IETF Policy on Character Sets and Languages. H. Alvestrand. January 1998. (Format: TXT, HTML) (Also BCP0018) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2277) 2278 IANA Charset Registration Procedures. N. Freed, J. Postel. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2978) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2278) 2279 UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998. (Format: TXT, HTML) (Obsoletes RFC2044) (Obsoleted by RFC3629) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2279) 2280 Routing Policy Specification Language (RPSL). C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. January 1998. (Format: TXT, HTML) (Obsoleted by RFC2622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2280) 2281 Cisco Hot Standby Router Protocol (HSRP). T. Li, B. Cole, P. Morton, D. Li. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2281) 2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. February 1998. (Format: TXT, HTML) (Obsoletes RFC2027) (Obsoleted by RFC2727) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2282) 2283 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y. Rekhter. February 1998. (Format: TXT, HTML) (Obsoleted by RFC2858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2283) 2284 PPP Extensible Authentication Protocol (EAP). L. Blunk, J. Vollbrecht. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3748) (Updated by RFC2484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2284) 2285 Benchmarking Terminology for LAN Switching Devices. R. Mandeville. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2285) 2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. J. Kapp. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2286) 2287 Definitions of System-Level Managed Objects for Applications. C. Krupczak, J. Saperia. February 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2287) 2288 Using Existing Bibliographic Identifiers as Uniform Resource Names. C. Lynch, C. Preston, R. Daniel. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2288) 2289 A One-Time Password System. N. Haller, C. Metz, P. Nesser, M. Straw. February 1998. (Format: TXT, HTML) (Obsoletes RFC1938) (Also STD0061) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2289) 2290 Mobile-IPv4 Configuration Option for PPP IPCP. J. Solomon, S. Glass. February 1998. (Format: TXT, HTML) (Updates RFC2002) (Updated by RFC2794) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2290) 2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web. J. Slein, F. Vitali, E. Whitehead, D. Durand. February 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2291) 2292 Advanced Sockets API for IPv6. W. Stevens, M. Thomas. February 1998. (Format: TXT, HTML) (Obsoleted by RFC3542) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2292) 2293 Representing Tables and Subtrees in the X.500 Directory. S. Kille. March 1998. (Format: TXT, HTML) (Obsoletes RFC1837) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2293) 2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree. S. Kille. March 1998. (Format: TXT, HTML) (Obsoletes RFC1836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2294) 2295 Transparent Content Negotiation in HTTP. K. Holtman, A. Mutz. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2295) 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0. K. Holtman, A. Mutz. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2296) 2297 Ipsilon's General Switch Management Protocol Specification Version 2.0. P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. March 1998. (Format: TXT, HTML) (Updates RFC1987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2297) 2298 An Extensible Message Format for Message Disposition Notifications. R. Fajman. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2298) 2299 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2299) 2300 Internet Official Protocol Standards. J. Postel. May 1998. (Format: TXT, HTML) (Obsoletes RFC2200) (Obsoleted by RFC2400) (Status: HISTORIC) (DOI: 10.17487/RFC2300) 2301 File Format for Internet Fax. L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3949) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2301) 2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration. G. Parsons, J. Rafferty, S. Zilles. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3302) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2302) 2303 Minimal PSTN address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2303) 2304 Minimal FAX address format in Internet Mail. C. Allocchio. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3192) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2304) 2305 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. Ohno, J. Murai, D. Wing. March 1998. (Format: TXT, HTML) (Obsoleted by RFC3965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2305) 2306 Tag Image File Format (TIFF) - F Profile for Facsimile. G. Parsons, J. Rafferty. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2306) 2307 An Approach for Using LDAP as a Network Information Service. L. Howard. March 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2307) 2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Updated by RFC4035, RFC4033, RFC4034, RFC6604, RFC8020, RFC8499) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2308) 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet. B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. April 1998. (Format: TXT, HTML) (Obsoleted by RFC7567) (Updated by RFC7141) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2309) 2310 The Safe Response Header Field. K. Holtman. April 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2310) 2311 S/MIME Version 2 Message Specification. S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka. March 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2311) 2312 S/MIME Version 2 Certificate Handling. S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. March 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2312) 2313 PKCS #1: RSA Encryption Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Obsoleted by RFC2437) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2313) 2314 PKCS #10: Certification Request Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Obsoleted by RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2314) 2315 PKCS #7: Cryptographic Message Syntax Version 1.5. B. Kaliski. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2315) 2316 Report of the IAB Security Architecture Workshop. S. Bellovin. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2316) 2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT, HTML) (Also BCP0020) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2317) 2318 The text/css Media Type. H. Lie, B. Bos, C. Lilley. March 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2318) 2319 Ukrainian Character Set KOI8-U. KOI8-U Working Group. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2319) 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB). M. Greene, J. Luciani, K. White, T. Kuo. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2320) 2321 RITA -- The Reliable Internetwork Troubleshooting Agent. A. Bressen. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2321) 2322 Management of IP numbers by peg-dhcp. K. van den Hout, A. Koopal, R. van Mook. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2322) 2323 IETF Identification and Security Guidelines. A. Ramos. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2323) 2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). L. Masinter. 1 April 1998. (Format: TXT, HTML) (Updated by RFC7168) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2324) 2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2. M. Slavitch. 1 April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2325) 2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R. Lanphier. April 1998. (Format: TXT, HTML) (Obsoleted by RFC7826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2326) 2327 SDP: Session Description Protocol. M. Handley, V. Jacobson. April 1998. (Format: TXT, HTML) (Obsoleted by RFC4566) (Updated by RFC3266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2327) 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT, HTML) (Obsoletes RFC2178) (Updated by RFC5709, RFC6549, RFC6845, RFC6860, RFC7474, RFC8042) (Also STD0054) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2328) 2329 OSPF Standardization Report. J. Moy. April 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2329) 2330 Framework for IP Performance Metrics. V. Paxson, G. Almes, J. Mahdavi, M. Mathis. May 1998. (Format: TXT, HTML) (Updated by RFC7312, RFC8468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2330) 2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update. M. Maher. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2331) 2332 NBMA Next Hop Resolution Protocol (NHRP). J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2332) 2333 NHRP Protocol Applicability Statement. D. Cansever. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2333) 2334 Server Cache Synchronization Protocol (SCSP). J. Luciani, G. Armitage, J. Halpern, N. Doraswamy. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2334) 2335 A Distributed NHRP Service Using SCSP. J. Luciani. April 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2335) 2336 Classical IP and ARP over ATM to NHRP Transition. J. Luciani. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2336) 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM. D. Farinacci, D. Meyer, Y. Rekhter. April 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2337) 2338 Virtual Router Redundancy Protocol. S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. April 1998. (Format: TXT, HTML) (Obsoleted by RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2338) 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2339) 2340 Nortel's Virtual Network Switching (VNS) Overview. B. Jamoussi, D. Jamieson, D. Williston, S. Gabe. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2340) 2341 Cisco Layer Two Forwarding (Protocol) "L2F". A. Valencia, M. Littlewood, T. Kolar. May 1998. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2341) 2342 IMAP4 Namespace. M. Gahrns, C. Newman. May 1998. (Format: TXT, HTML) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2342) 2343 RTP Payload Format for Bundled MPEG. M. Civanlar, G. Cash, B. Haskell. May 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2343) 2344 Reverse Tunneling for Mobile IP. G. Montenegro, Ed.. May 1998. (Format: TXT, HTML) (Obsoleted by RFC3024) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2344) 2345 Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G. Oglesby. May 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2345) 2346 Making Postscript and PDF International. J. Palme. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2346) 2347 TFTP Option Extension. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2347) 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2348) 2349 TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. May 1998. (Format: TXT, HTML) (Obsoletes RFC1784) (Updates RFC1350) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2349) 2350 Expectations for Computer Security Incident Response. N. Brownlee, E. Guttman. June 1998. (Format: TXT, HTML) (Also BCP0021) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2350) 2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP. A. Robert. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2351) 2352 A Convention For Using Legal Names as Domain Names. O. Vaughan. May 1998. (Format: TXT, HTML) (Obsoletes RFC2240) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2352) 2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document. G. Dudley. May 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2353) 2354 Options for Repair of Streaming Media. C. Perkins, O. Hodson. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2354) 2355 TN3270 Enhancements. B. Kelly. June 1998. (Format: TXT, HTML) (Obsoletes RFC1647) (Updated by RFC6270) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2355) 2356 Sun's SKIP Firewall Traversal for Mobile IP. G. Montenegro, V. Gupta. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2356) 2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols. A. Mankin, A. Romanow, S. Bradner, V. Paxson. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2357) 2358 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. June 1998. (Format: TXT, HTML) (Obsoletes RFC1650) (Obsoleted by RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2358) 2359 IMAP4 UIDPLUS extension. J. Myers. June 1998. (Format: TXT, HTML) (Obsoleted by RFC4315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2359) 2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT, HTML) (Also BCP0022) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2360) 2361 WAVE and AVI Codec Registries. E. Fleischman. June 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2361) 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. June 1998. (Format: TXT, HTML) (Obsoletes RFC2117) (Obsoleted by RFC4601, RFC5059) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2362) 2363 PPP Over FUNI. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2363) 2364 PPP Over AAL5. G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2364) 2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT, HTML) (Also BCP0023) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2365) 2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. July 1998. (Format: TXT, HTML) (Obsoleted by RFC2417) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2366) 2367 PF_KEY Key Management API, Version 2. D. McDonald, C. Metz, B. Phan. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2367) 2368 The mailto URL scheme. P. Hoffman, L. Masinter, J. Zawinski. July 1998. (Format: TXT, HTML) (Obsoleted by RFC6068) (Updates RFC1738, RFC1808) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2368) 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. G. Neufeld, J. Baer. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2369) 2370 The OSPF Opaque LSA Option. R. Coltun. July 1998. (Format: TXT, HTML) (Obsoleted by RFC5250) (Updated by RFC3630) (Also RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2370) 2371 Transaction Internet Protocol Version 3.0. J. Lyon, K. Evans, J. Klein. July 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2371) 2372 Transaction Internet Protocol - Requirements and Supplemental Information. K. Evans, J. Klein, J. Lyon. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2372) 2373 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. July 1998. (Format: TXT, HTML) (Obsoletes RFC1884) (Obsoleted by RFC3513) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2373) 2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M. O'Dell, S. Deering. July 1998. (Format: TXT, HTML) (Obsoletes RFC2073) (Obsoleted by RFC3587) (Status: HISTORIC) (DOI: 10.17487/RFC2374) 2375 IPv6 Multicast Address Assignments. R. Hinden, S. Deering. July 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2375) 2376 XML Media Types. E. Whitehead, M. Murata. July 1998. (Format: TXT, HTML) (Obsoleted by RFC3023) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2376) 2377 Naming Plan for Internet Directory-Enabled Applications. A. Grimstad, R. Huber, S. Sataluri, M. Wahl. September 1998. (Format: TXT, HTML) (Updated by RFC4519) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2377) 2378 The CCSO Nameserver (Ph) Architecture. R. Hedberg, P. Pomes. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2378) 2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT, HTML) (Also BCP0024) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2379) 2380 RSVP over ATM Implementation Requirements. L. Berger. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2380) 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM. M. Garrett, M. Borden. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2381) 2382 A Framework for Integrated Services and RSVP over ATM. E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2382) 2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version. M. Suzuki. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2383) 2384 POP URL Scheme. R. Gellens. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2384) 2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A. Heffernan. August 1998. (Format: TXT, HTML) (Obsoleted by RFC5925) (Updated by RFC6691) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2385) 2386 A Framework for QoS-based Routing in the Internet. E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2386) 2387 The MIME Multipart/Related Content-type. E. Levinson. August 1998. (Format: TXT, HTML) (Obsoletes RFC2112) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2387) 2388 Returning Values from Forms: multipart/form-data. L. Masinter. August 1998. (Format: TXT, HTML) (Obsoleted by RFC7578) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2388) 2389 Feature negotiation mechanism for the File Transfer Protocol. P. Hethmon, R. Elz. August 1998. (Format: TXT, HTML) (Also RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2389) 2390 Inverse Address Resolution Protocol. T. Bradley, C. Brown, A. Malis. September 1998. (Format: TXT, HTML) (Obsoletes RFC1293) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2390) 2391 Load Sharing using IP Network Address Translation (LSNAT). P. Srisuresh, D. Gan. August 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2391) 2392 Content-ID and Message-ID Uniform Resource Locators. E. Levinson. August 1998. (Format: TXT, HTML) (Obsoletes RFC2111) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2392) 2393 IP Payload Compression Protocol (IPComp). A. Shacham, R. Monsour, R. Pereira, M. Thomas. December 1998. (Format: TXT, HTML) (Obsoleted by RFC3173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2393) 2394 IP Payload Compression Using DEFLATE. R. Pereira. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2394) 2395 IP Payload Compression Using LZS. R. Friend, R. Monsour. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2395) 2396 Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format: TXT, HTML) (Obsoleted by RFC3986) (Updates RFC1808, RFC1738) (Updated by RFC2732) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2396) 2397 The "data" URL scheme. L. Masinter. August 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2397) 2398 Some Testing Tools for TCP Implementors. S. Parker, C. Schmechel. August 1998. (Format: TXT, HTML) (Also FYI0033) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2398) 2399 Request for Comments Summary. A. Ramos. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2399) 2400 Internet Official Protocol Standards. J. Postel, J. Reynolds. September 1998. (Format: TXT, HTML) (Obsoletes RFC2300) (Obsoleted by RFC2500) (Status: HISTORIC) (DOI: 10.17487/RFC2400) 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (Obsoletes RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2401) 2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (Obsoletes RFC1826) (Obsoleted by RFC4302, RFC4305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2402) 2403 The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2403) 2404 The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2404) 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. Doraswamy. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2405) 2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson. November 1998. (Format: TXT, HTML) (Obsoletes RFC1827) (Obsoleted by RFC4303, RFC4305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2406) 2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2407) 2408 Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2408) 2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4306) (Updated by RFC4109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2409) 2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2410) 2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998. (Format: TXT, HTML) (Obsoleted by RFC6071) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2411) 2412 The OAKLEY Key Determination Protocol. H. Orman. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2412) 2413 Dublin Core Metadata for Resource Discovery. S. Weibel, J. Kunze, C. Lagoze, M. Wolf. September 1998. (Format: TXT, HTML) (Obsoleted by RFC5013) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2413) 2414 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. September 1998. (Format: TXT, HTML) (Obsoleted by RFC3390) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2414) 2415 Simulation Studies of Increased Initial TCP Window Size. K. Poduri, K. Nichols. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2415) 2416 When TCP Starts Up With Four Packets Into Only Three Buffers. T. Shepard, C. Partridge. September 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2416) 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks. C. Chung, M. Greene. September 1998. (Format: TXT, HTML) (Obsoletes RFC2366) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2417) 2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT, HTML) (Obsoletes RFC1603) (Updated by RFC3934, RFC7475, RFC7776, RFC8717) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2418) 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis). K. Sklower, G. Meyer. September 1998. (Format: TXT, HTML) (Obsoletes RFC1969) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2419) 2420 The PPP Triple-DES Encryption Protocol (3DESE). H. Kummert. September 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2420) 2421 Voice Profile for Internet Mail - version 2. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoletes RFC1911) (Obsoleted by RFC3801) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2421) 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoletes RFC1911) (Obsoleted by RFC3802) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2422) 2423 VPIM Voice Message MIME Sub-type Registration. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoletes RFC1911) (Obsoleted by RFC3801) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2423) 2424 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. September 1998. (Format: TXT, HTML) (Obsoleted by RFC3803) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2424) 2425 A MIME Content-Type for Directory Information. T. Howes, M. Smith, F. Dawson. September 1998. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2425) 2426 vCard MIME Directory Profile. F. Dawson, T. Howes. September 1998. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2426) 2427 Multiprotocol Interconnect over Frame Relay. C. Brown, A. Malis. September 1998. (Format: TXT, HTML) (Obsoletes RFC1490, RFC1294) (Also STD0055) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2427) 2428 FTP Extensions for IPv6 and NATs. M. Allman, S. Ostermann, C. Metz. September 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2428) 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998. (Format: TXT, HTML) (Obsoleted by RFC4629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2429) 2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE). T. Li, Y. Rekhter. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2430) 2431 RTP Payload Format for BT.656 Video Encoding. D. Tynan. October 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2431) 2432 Terminology for IP Multicast Benchmarking. K. Dubray. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2432) 2433 Microsoft PPP CHAP Extensions. G. Zorn, S. Cobb. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2433) 2434 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. (Format: TXT, HTML) (Obsoleted by RFC5226) (Updated by RFC3692) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2434) 2435 RTP Payload Format for JPEG-compressed Video. L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart. October 1998. (Format: TXT, HTML) (Obsoletes RFC2035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2435) 2436 Collaboration between ISOC/IETF and ITU-T. R. Brett, S. Bradner, G. Parsons. October 1998. (Format: TXT, HTML) (Obsoleted by RFC3356) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2436) 2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998. (Format: TXT, HTML) (Obsoletes RFC2313) (Obsoleted by RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2437) 2438 Advancement of MIB specifications on the IETF Standards Track. M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: TXT, HTML) (Also BCP0027) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2438) 2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2439) 2440 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, R. Thayer. November 1998. (Format: TXT, HTML) (Obsoleted by RFC4880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2440) 2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998. D. Cohen. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2441) 2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissent, M. Hoy. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2442) 2443 A Distributed MARS Service Using SCSP. J. Luciani, A. Gallo. November 1998. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2443) 2444 The One-Time-Password SASL Mechanism. C. Newman. October 1998. (Format: TXT, HTML) (Updates RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2444) 2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar). F. Dawson, D. Stenerson. November 1998. (Format: TXT, HTML) (Obsoleted by RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2445) 2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries. S. Silverberg, S. Mansour, F. Dawson, R. Hopson. November 1998. (Format: TXT, HTML) (Obsoleted by RFC5546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2446) 2447 iCalendar Message-Based Interoperability Protocol (iMIP). F. Dawson, S. Mansour, S. Silverberg. November 1998. (Format: TXT, HTML) (Obsoleted by RFC6047) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2447) 2448 AT&T's Error Resilient Video Transmission Technique. M. Civanlar, G. Cash, B. Haskell. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2448) 2449 POP3 Extension Mechanism. R. Gellens, C. Newman, L. Lundblade. November 1998. (Format: TXT, HTML) (Updates RFC1939) (Updated by RFC5034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2449) 2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2450) 2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2451) 2452 IP Version 6 Management Information Base for the Transmission Control Protocol. M. Daniele. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4022, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2452) 2453 RIP Version 2. G. Malkin. November 1998. (Format: TXT, HTML) (Obsoletes RFC1723) (Updated by RFC4822) (Also STD0056) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2453) 2454 IP Version 6 Management Information Base for the User Datagram Protocol. M. Daniele. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4113, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2454) 2455 Definitions of Managed Objects for APPN. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (Obsoletes RFC2155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2455) 2456 Definitions of Managed Objects for APPN TRAPS. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2456) 2457 Definitions of Managed Objects for Extended Border Node. B. Clouston, B. Moore. November 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2457) 2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations. H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan. November 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2458) 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2459) 2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. December 1998. (Format: TXT, HTML) (Obsoletes RFC1883) (Obsoleted by RFC8200) (Updated by RFC5095, RFC5722, RFC5871, RFC6437, RFC6564, RFC6935, RFC6946, RFC7045, RFC7112) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2460) 2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT, HTML) (Obsoletes RFC1970) (Obsoleted by RFC4861) (Updated by RFC4311) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2461) 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT, HTML) (Obsoletes RFC1971) (Obsoleted by RFC4862) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2462) 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering. December 1998. (Format: TXT, HTML) (Obsoletes RFC1885) (Obsoleted by RFC4443) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2463) 2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. December 1998. (Format: TXT, HTML) (Obsoletes RFC1972) (Updated by RFC6085, RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2464) 2465 Management Information Base for IP Version 6: Textual Conventions and General Group. D. Haskin, S. Onishi. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4293, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2465) 2466 Management Information Base for IP Version 6: ICMPv6 Group. D. Haskin, S. Onishi. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4293, RFC8096) (Status: HISTORIC) (DOI: 10.17487/RFC2466) 2467 Transmission of IPv6 Packets over FDDI Networks. M. Crawford. December 1998. (Format: TXT, HTML) (Obsoletes RFC2019) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2467) 2468 I REMEMBER IANA. V. Cerf. October 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2468) 2469 A Caution On The Canonical Ordering Of Link-Layer Addresses. T. Narten, C. Burton. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2469) 2470 Transmission of IPv6 Packets over Token Ring Networks. M. Crawford, T. Narten, S. Thomas. December 1998. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2470) 2471 IPv6 Testing Address Allocation. R. Hinden, R. Fink, J. Postel. December 1998. (Format: TXT, HTML) (Obsoletes RFC1897) (Obsoleted by RFC3701) (Status: HISTORIC) (DOI: 10.17487/RFC2471) 2472 IP Version 6 over PPP. D. Haskin, E. Allen. December 1998. (Format: TXT, HTML) (Obsoletes RFC2023) (Obsoleted by RFC5072, RFC5172) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2472) 2473 Generic Packet Tunneling in IPv6 Specification. A. Conta, S. Deering. December 1998. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2473) 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998. (Format: TXT, HTML) (Obsoletes RFC1455, RFC1349) (Updates RFC0791) (Updated by RFC3168, RFC3260, RFC8436) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2474) 2475 An Architecture for Differentiated Services. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. December 1998. (Format: TXT, HTML) (Updated by RFC3260) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2475) 2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2476) 2477 Criteria for Evaluating Roaming Protocols. B. Aboba, G. Zorn. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2477) 2478 The Simple and Protected GSS-API Negotiation Mechanism. E. Baize, D. Pinkas. December 1998. (Format: TXT, HTML) (Obsoleted by RFC4178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2478) 2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API). C. Adams. December 1998. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2479) 2480 Gateways and MIME Security Multiparts. N. Freed. January 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2480) 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3168) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2481) 2482 Language Tagging in Unicode Plain Text. K. Whistler, G. Adams. January 1999. (Format: TXT, HTML) (Obsoleted by RFC6082) (Status: HISTORIC) (DOI: 10.17487/RFC2482) 2483 URI Resolution Services Necessary for URN Resolution. M. Mealling, R. Daniel. January 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2483) 2484 PPP LCP Internationalization Configuration Option. G. Zorn. January 1999. (Format: TXT, HTML) (Updates RFC2284, RFC1994, RFC1570) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2484) 2485 DHCP Option for The Open Group's User Authentication Protocol. S. Drach. January 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2485) 2486 The Network Access Identifier. B. Aboba, M. Beadles. January 1999. (Format: TXT, HTML) (Obsoleted by RFC4282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2486) 2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3207) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2487) 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT, HTML) (Also BCP0028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2488) 2489 Procedure for Defining New DHCP Options. R. Droms. January 1999. (Format: TXT, HTML) (Obsoleted by RFC2939) (Also BCP0029) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2489) 2490 A Simulation Model for IP Multicast with RSVP. M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. January 1999. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2490) 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks. G. Armitage, P. Schulter, M. Jork, G. Harter. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2491) 2492 IPv6 over ATM Networks. G. Armitage, P. Schulter, M. Jork. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2492) 2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. K. Tesink, Ed.. January 1999. (Format: TXT, HTML) (Obsoleted by RFC3593) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2493) 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2494) 2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types. D. Fowler, Ed.. January 1999. (Format: TXT, HTML) (Obsoletes RFC1406) (Obsoleted by RFC3895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2495) 2496 Definitions of Managed Object for the DS3/E3 Interface Type. D. Fowler, Ed.. January 1999. (Format: TXT, HTML) (Obsoletes RFC1407) (Obsoleted by RFC3896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2496) 2497 Transmission of IPv6 Packets over ARCnet Networks. I. Souvatzis. January 1999. (Format: TXT, HTML) (Updated by RFC8064) (Also RFC1201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2497) 2498 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. January 1999. (Format: TXT, HTML) (Obsoleted by RFC2678) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2498) 2499 Request for Comments Summary. A. Ramos. July 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2499) 2500 Internet Official Protocol Standards. J. Reynolds, R. Braden. June 1999. (Format: TXT, HTML) (Obsoletes RFC2400) (Obsoleted by RFC2600) (Status: HISTORIC) (DOI: 10.17487/RFC2500) 2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations. S. Corson, J. Macker. January 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2501) 2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment. M. Pullen, M. Myjak, C. Bouwens. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2502) 2503 MIME Types for Use with the ISO ILL Protocol. R. Moulton, M. Needleman. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2503) 2504 Users' Security Handbook. E. Guttman, L. Leong, G. Malkin. February 1999. (Format: TXT, HTML) (Also FYI0034) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2504) 2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February 1999. (Format: TXT, HTML) (Also BCP0030) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2505) 2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T. Hardie. March 1999. (Format: TXT, HTML) (Also BCP0031) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2506) 2507 IP Header Compression. M. Degermark, B. Nordgren, S. Pink. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2507) 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. S. Casner, V. Jacobson. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2508) 2509 IP Header Compression over PPP. M. Engan, S. Casner, C. Bormann. February 1999. (Format: TXT, HTML) (Obsoleted by RFC3544) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2509) 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols. C. Adams, S. Farrell. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2510) 2511 Internet X.509 Certificate Request Message Format. M. Myers, C. Adams, D. Solo, D. Kemp. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4211) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2511) 2512 Accounting Information for ATM Networks. K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2512) 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks. K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2513) 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management. M. Noto, E. Spiegel, K. Tesink. February 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2514) 2515 Definitions of Managed Objects for ATM Management. K. Tesink, Ed.. February 1999. (Format: TXT, HTML) (Obsoletes RFC1695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2515) 2516 A Method for Transmitting PPP Over Ethernet (PPPoE). L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2516) 2517 Building Directories from DNS: Experiences from WWWSeeker. R. Moats, R. Huber. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2517) 2518 HTTP Extensions for Distributed Authoring -- WEBDAV. Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. February 1999. (Format: TXT, HTML) (Obsoleted by RFC4918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2518) 2519 A Framework for Inter-Domain Route Aggregation. E. Chen, J. Stewart. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2519) 2520 NHRP with Mobile NHCs. J. Luciani, H. Suzuki, N. Doraswamy, D. Horton. February 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2520) 2521 ICMP Security Failures Messages. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2521) 2522 Photuris: Session-Key Management Protocol. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2522) 2523 Photuris: Extended Schemes and Attributes. P. Karn, W. Simpson. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2523) 2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3. M. Banan. February 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2524) 2525 Known TCP Implementation Problems. V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2525) 2526 Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S. Deering. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2526) 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford. March 1999. (Format: TXT, HTML) (Obsoleted by RFC3647) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2527) 2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates. R. Housley, W. Polk. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2528) 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2529) 2530 Indicating Supported Media Features Using Extensions to DSN and MDN. D. Wing. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2530) 2531 Content Feature Schema for Internet Fax. G. Klyne, L. McIntyre. March 1999. (Format: TXT, HTML) (Obsoleted by RFC2879) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2531) 2532 Extended Facsimile Using Internet Mail. L. Masinter, D. Wing. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2532) 2533 A Syntax for Describing Media Feature Sets. G. Klyne. March 1999. (Format: TXT, HTML) (Updated by RFC2738, RFC2938) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2533) 2534 Media Features for Display, Print, and Fax. L. Masinter, D. Wing, A. Mutz, K. Holtman. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2534) 2535 Domain Name System Security Extensions. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoletes RFC2065) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008, RFC3090, RFC3226, RFC3445, RFC3597, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2535) 2536 DSA KEYs and SIGs in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2536) 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoleted by RFC3110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2537) 2538 Storing Certificates in the Domain Name System (DNS). D. Eastlake 3rd, O. Gudmundsson. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2538) 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS). D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2539) 2540 Detached Domain Name System (DNS) Information. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2540) 2541 DNS Security Operational Considerations. D. Eastlake 3rd. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2541) 2542 Terminology and Goals for Internet Fax. L. Masinter. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2542) 2543 SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999. (Format: TXT, HTML) (Obsoleted by RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2543) 2544 Benchmarking Methodology for Network Interconnect Devices. S. Bradner, J. McQuaid. March 1999. (Format: TXT, HTML) (Obsoletes RFC1944) (Updated by RFC6201, RFC6815) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2544) 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont. March 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2545) 2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999. (Format: TXT, HTML) (Obsoleted by RFC2772) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2546) 2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4364) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2547) 2548 Microsoft Vendor-specific RADIUS Attributes. G. Zorn. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2548) 2549 IP over Avian Carriers with Quality of Service. D. Waitzman. 1 April 1999. (Format: TXT, HTML) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2549) 2550 Y10K and Beyond. S. Glassman, M. Manasse, J. Mogul. 1 April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2550) 2551 The Roman Standards Process -- Revision III. S. Bradner. 1 April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2551) 2552 Architecture for the Information Brokerage in the ACTS Project GAIA. M. Blinov, M. Bessonov, C. Clissmann. April 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2552) 2553 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. March 1999. (Format: TXT, HTML) (Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2553) 2554 SMTP Service Extension for Authentication. J. Myers. March 1999. (Format: TXT, HTML) (Obsoleted by RFC4954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2554) 2555 30 Years of RFCs. RFC Editor, et al.. April 1999. (Format: TXT, HTML) (Updated by RFC8700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2555) 2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status. S. Bradner. March 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2556) 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML). J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT, HTML) (Obsoletes RFC2110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2557) 2558 Definitions of Managed Objects for the SONET/SDH Interface Type. K. Tesink. March 1999. (Format: TXT, HTML) (Obsoletes RFC1595) (Obsoleted by RFC3592) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2558) 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2. S. Boeyen, T. Howes, P. Richard. April 1999. (Format: TXT, HTML) (Obsoleted by RFC3494) (Updates RFC1778) (Status: HISTORIC) (DOI: 10.17487/RFC2559) 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 1999. (Format: TXT, HTML) (Obsoleted by RFC6960) (Updated by RFC6277) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2560) 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2. K. White, R. Moore. April 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2561) 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB). K. White, R. Moore. April 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2562) 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients. R. Troll. May 1999. (Format: TXT, HTML) (Updated by RFC8925) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2563) 2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2564) 2565 Internet Printing Protocol/1.0: Encoding and Transport. R. Herriot, Ed., S. Butler, P. Moore, R. Turner. April 1999. (Format: TXT, HTML) (Obsoleted by RFC2910) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2565) 2566 Internet Printing Protocol/1.0: Model and Semantics. R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. April 1999. (Format: TXT, HTML) (Obsoleted by RFC2911) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2566) 2567 Design Goals for an Internet Printing Protocol. F. Wright. April 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2567) 2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol. S. Zilles. April 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2568) 2569 Mapping between LPD and IPP Protocols. R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin. April 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2569) 2570 Introduction to Version 3 of the Internet-standard Network Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. April 1999. (Format: TXT, HTML) (Obsoleted by RFC3410) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2570) 2571 An Architecture for Describing SNMP Management Frameworks. B. Wijnen, D. Harrington, R. Presuhn. April 1999. (Format: TXT, HTML) (Obsoletes RFC2271) (Obsoleted by RFC3411) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2571) 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. April 1999. (Format: TXT, HTML) (Obsoletes RFC2272) (Obsoleted by RFC3412) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2572) 2573 SNMP Applications. D. Levi, P. Meyer, B. Stewart. April 1999. (Format: TXT, HTML) (Obsoletes RFC2273) (Obsoleted by RFC3413) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2573) 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. April 1999. (Format: TXT, HTML) (Obsoletes RFC2274) (Obsoleted by RFC3414) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2574) 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. April 1999. (Format: TXT, HTML) (Obsoletes RFC2275) (Obsoleted by RFC3415) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2575) 2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. March 2000. (Format: TXT, HTML) (Obsoletes RFC1908, RFC2089) (Obsoleted by RFC3584) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2576) 2577 FTP Security Considerations. M. Allman, S. Ostermann. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2577) 2578 Structure of Management Information Version 2 (SMIv2). K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT, HTML) (Obsoletes RFC1902) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2578) 2579 Textual Conventions for SMIv2. K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT, HTML) (Obsoletes RFC1903) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2579) 2580 Conformance Statements for SMIv2. K. McCloghrie, Ed., D. Perkins, Ed., J. Schoenwaelder, Ed.. April 1999. (Format: TXT, HTML) (Obsoletes RFC1904) (Also STD0058) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2580) 2581 TCP Congestion Control. M. Allman, V. Paxson, W. Stevens. April 1999. (Format: TXT, HTML) (Obsoletes RFC2001) (Obsoleted by RFC5681) (Updated by RFC3390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2581) 2582 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson. April 1999. (Format: TXT, HTML) (Obsoleted by RFC3782) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2582) 2583 Guidelines for Next Hop Client (NHC) Developers. R. Carlson, L. Winkler. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2583) 2584 Definitions of Managed Objects for APPN/HPR in IP Networks. B. Clouston, B. Moore. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2584) 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2585) 2586 The Audio/L16 MIME content type. J. Salsman, H. Alvestrand. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2586) 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema. S. Boeyen, T. Howes, P. Richard. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4523) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2587) 2588 IP Multicast and Firewalls. R. Finlayson. May 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2588) 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services. Y. Yaacovi, M. Wahl, T. Genovese. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2589) 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification. A. Conta, A. Malis, M. Mueller. May 1999. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2590) 2591 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2591) 2592 Definitions of Managed Objects for the Delegation of Management Script. D. Levi, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2592) 2593 Script MIB Extensibility Protocol Version 1.0. J. Schoenwaelder, J. Quittek. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3179) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2593) 2594 Definitions of Managed Objects for WWW Services. H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder. May 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2594) 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999. (Format: TXT, HTML) (Updated by RFC4616, RFC7817, RFC8314) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2595) 2596 Use of Language Codes in LDAP. M. Wahl, T. Howes. May 1999. (Format: TXT, HTML) (Obsoleted by RFC3866) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2596) 2597 Assured Forwarding PHB Group. J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. June 1999. (Format: TXT, HTML) (Updated by RFC3260) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2597) 2598 An Expedited Forwarding PHB. V. Jacobson, K. Nichols, K. Poduri. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2598) 2599 Request for Comments Summary RFC Numbers 2500-2599. A. DeLaCruz. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2599) 2600 Internet Official Protocol Standards. J. Reynolds, R. Braden. March 2000. (Format: TXT, HTML) (Obsoletes RFC2500) (Obsoleted by RFC2700) (Status: HISTORIC) (DOI: 10.17487/RFC2600) 2601 ILMI-Based Server Discovery for ATMARP. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2601) 2602 ILMI-Based Server Discovery for MARS. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2602) 2603 ILMI-Based Server Discovery for NHRP. M. Davison. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2603) 2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. June 1999. (Format: TXT, HTML) (Obsoleted by RFC2636) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2604) 2605 Directory Server Monitoring MIB. G. Mansfield, S. Kille. June 1999. (Format: TXT, HTML) (Obsoletes RFC1567) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2605) 2606 Reserved Top Level DNS Names. D. Eastlake 3rd, A. Panitz. June 1999. (Format: TXT, HTML) (Updated by RFC6761) (Also BCP0032) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2606) 2607 Proxy Chaining and Policy Implementation in Roaming. B. Aboba, J. Vollbrecht. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2607) 2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J. Veizades, M. Day. June 1999. (Format: TXT, HTML) (Updates RFC2165) (Updated by RFC3224) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2608) 2609 Service Templates and Service: Schemes. E. Guttman, C. Perkins, J. Kempf. June 1999. (Format: TXT, HTML) (Updates RFC2165) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2609) 2610 DHCP Options for Service Location Protocol. C. Perkins, E. Guttman. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2610) 2611 URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3406) (Also BCP0033) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2611) 2612 The CAST-256 Encryption Algorithm. C. Adams, J. Gilchrist. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2612) 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0. R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. June 1999. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2613) 2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2614) 2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format: TXT, HTML) (Obsoletes RFC1619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2615) 2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC2068) (Obsoleted by RFC7230, RFC7231, RFC7232, RFC7233, RFC7234, RFC7235) (Updated by RFC2817, RFC5785, RFC6266, RFC6585) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2616) 2617 HTTP Authentication: Basic and Digest Access Authentication. J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. June 1999. (Format: TXT, HTML) (Obsoletes RFC2069) (Obsoleted by RFC7235, RFC7615, RFC7616, RFC7617) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2617) 2618 RADIUS Authentication Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4668) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2618) 2619 RADIUS Authentication Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4669) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2619) 2620 RADIUS Accounting Client MIB. B. Aboba, G. Zorn. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4670) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2620) 2621 RADIUS Accounting Server MIB. G. Zorn, B. Aboba. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4671) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2621) 2622 Routing Policy Specification Language (RPSL). C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. June 1999. (Format: TXT, HTML) (Obsoletes RFC2280) (Updated by RFC4012, RFC7909) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2622) 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5. M. Eisler. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2623) 2624 NFS Version 4 Design Considerations. S. Shepler. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2624) 2625 IP and ARP over Fibre Channel. M. Rajagopal, R. Bhagwat, W. Rickard. June 1999. (Format: TXT, HTML) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2625) 2626 The Internet and the Millennium Problem (Year 2000). P. Nesser II. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2626) 2627 Key Management for Multicast: Issues and Architectures. D. Wallner, E. Harder, R. Agee. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2627) 2628 Simple Cryptographic Program Interface (Crypto API). V. Smyslov. June 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2628) 2629 Writing I-Ds and RFCs using XML. M. Rose. June 1999. (Format: TXT, HTML) (Obsoleted by RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2629) 2630 Cryptographic Message Syntax. R. Housley. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2630) 2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2631) 2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2632) 2633 S/MIME Version 3 Message Specification. B. Ramsdell, Ed.. June 1999. (Format: TXT, HTML) (Obsoleted by RFC3851) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2633) 2634 Enhanced Security Services for S/MIME. P. Hoffman, Ed.. June 1999. (Format: TXT, HTML) (Updated by RFC5035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2634) 2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*). S. Hambridge, A. Lunde. June 1999. (Format: TXT, HTML) (Also FYI0035) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2635) 2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP. R. Gellens. July 1999. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC2604) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2636) 2637 Point-to-Point Tunneling Protocol (PPTP). K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. July 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2637) 2638 A Two-bit Differentiated Services Architecture for the Internet. K. Nichols, V. Jacobson, L. Zhang. July 1999. (Format: TXT, PS, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2638) 2639 Internet Printing Protocol/1.0: Implementer's Guide. T. Hastings, C. Manros. July 1999. (Format: TXT, HTML) (Obsoleted by RFC3196) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2639) 2640 Internationalization of the File Transfer Protocol. B. Curtin. July 1999. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2640) 2641 Cabletron's VlanHello Protocol Specification Version 4. D. Hamilton, D. Ruffen. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2641) 2642 Cabletron's VLS Protocol Specification. L. Kane. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2642) 2643 Cabletron's SecureFast VLAN Operational Model. D. Ruffen, T. Len, J. Yanacek. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2643) 2644 Changing the Default for Directed Broadcasts in Routers. D. Senie. August 1999. (Format: TXT, HTML) (Updates RFC1812) (Also BCP0034) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2644) 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R. Gellens. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2645) 2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC3676) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2646) 2647 Benchmarking Terminology for Firewall Performance. D. Newman. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2647) 2648 A URN Namespace for IETF Documents. R. Moats. August 1999. (Format: TXT, HTML) (Updated by RFC6924) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2648) 2649 An LDAP Control and Schema for Holding Operation Signatures. B. Greenblatt, P. Richard. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2649) 2650 Using RPSL in Practice. D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2650) 2651 The Architecture of the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2651) 2652 MIME Object Definitions for the Common Indexing Protocol (CIP). J. Allen, M. Mealling. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2652) 2653 CIP Transport Protocols. J. Allen, P. Leach, R. Hedberg. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2653) 2654 A Tagged Index Object for use in the Common Indexing Protocol. R. Hedberg, B. Greenblatt, R. Moats, M. Wahl. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2654) 2655 CIP Index Object Format for SOIF Objects. T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2655) 2656 Registration Procedures for SOIF Template Types. T. Hardie. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2656) 2657 LDAPv2 Client vs. the Index Mesh. R. Hedberg. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2657) 2658 RTP Payload Format for PureVoice(tm) Audio. K. McKay. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2658) 2659 Security Extensions For HTML. E. Rescorla, A. Schiffman. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2659) 2660 The Secure HyperText Transfer Protocol. E. Rescorla, A. Schiffman. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2660) 2661 Layer Two Tunneling Protocol "L2TP". W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2661) 2662 Definitions of Managed Objects for the ADSL Lines. G. Bathrick, F. Ly. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2662) 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2663) 2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions. R. Plzak, A. Wells, E. Krol. August 1999. (Format: TXT, HTML) (Obsoletes RFC1594) (Also FYI0004) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2664) 2665 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick, J. Johnson. August 1999. (Format: TXT, HTML) (Obsoletes RFC2358) (Obsoleted by RFC3635) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2665) 2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets. J. Flick. August 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2666) 2667 IP Tunnel MIB. D. Thaler. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4087) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2667) 2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. August 1999. (Format: TXT, HTML) (Obsoletes RFC2239) (Obsoleted by RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2668) 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems. M. St. Johns, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4639) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2669) 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces. M. St. Johns, Ed.. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4546) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2670) 2671 Extension Mechanisms for DNS (EDNS0). P. Vixie. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2671) 2672 Non-Terminal DNS Name Redirection. M. Crawford. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6672) (Updated by RFC4592, RFC6604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2672) 2673 Binary Labels in the Domain Name System. M. Crawford. August 1999. (Format: TXT, HTML) (Obsoleted by RFC6891) (Updates RFC1035) (Updated by RFC3363, RFC3364) (Status: HISTORIC) (DOI: 10.17487/RFC2673) 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions. E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. August 1999. (Format: TXT, HTML) (Obsoleted by RFC4363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2674) 2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT, HTML) (Obsoletes RFC2147) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2675) 2676 QoS Routing Mechanisms and OSPF Extensions. G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. Orda, T. Przygienda. August 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2676) 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP). M. Greene, J. Cucchiara, J. Luciani. August 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2677) 2678 IPPM Metrics for Measuring Connectivity. J. Mahdavi, V. Paxson. September 1999. (Format: TXT, HTML) (Obsoletes RFC2498) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2678) 2679 A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT, HTML) (Obsoleted by RFC7679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2679) 2680 A One-way Packet Loss Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT, HTML) (Obsoleted by RFC7680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2680) 2681 A Round-trip Delay Metric for IPPM. G. Almes, S. Kalidindi, M. Zekauskas. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2681) 2682 Performance Issues in VC-Merge Capable ATM LSRs. I. Widjaja, A. Elwalid. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2682) 2683 IMAP4 Implementation Recommendations. B. Leiba. September 1999. (Format: TXT, HTML) (Updated by RFC7162) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2683) 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5. D. Grossman, J. Heinanen. September 1999. (Format: TXT, HTML) (Obsoletes RFC1483) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2684) 2685 Virtual Private Networks Identifier. B. Fox, B. Gleeson. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2685) 2686 The Multi-Class Extension to Multi-Link PPP. C. Bormann. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2686) 2687 PPP in a Real-time Oriented HDLC-like Framing. C. Bormann. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2687) 2688 Integrated Services Mappings for Low Speed Networks. S. Jackowski, D. Putzolu, E. Crawley, B. Davie. September 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2688) 2689 Providing Integrated Services over Low-bitrate Links. C. Bormann. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2689) 2690 A Proposal for an MOU-Based ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2690) 2691 A Memorandum of Understanding for an ICANN Protocol Support Organization. S. Bradner. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2691) 2692 SPKI Requirements. C. Ellison. September 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2692) 2693 SPKI Certificate Theory. C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. September 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2693) 2694 DNS extensions to Network Address Translators (DNS_ALG). P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2694) 2695 Authentication Mechanisms for ONC RPC. A. Chiu. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2695) 2696 LDAP Control Extension for Simple Paged Results Manipulation. C. Weider, A. Herron, A. Anantha, T. Howes. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2696) 2697 A Single Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2697) 2698 A Two Rate Three Color Marker. J. Heinanen, R. Guerin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2698) 2699 Request for Comments Summary RFC Numbers 2600-2699. S. Ginoza. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2699) 2700 Internet Official Protocol Standards. J. Reynolds, R. Braden. August 2000. (Format: TXT, HTML) (Obsoletes RFC2600) (Obsoleted by RFC2800) (Status: HISTORIC) (DOI: 10.17487/RFC2700) 2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol. G. Malkin. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2701) 2702 Requirements for Traffic Engineering Over MPLS. D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2702) 2703 Protocol-independent Content Negotiation Framework. G. Klyne. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2703) 2704 The KeyNote Trust-Management System Version 2. M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. September 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2704) 2705 Media Gateway Control Protocol (MGCP) Version 1.0. M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. October 1999. (Format: TXT, HTML) (Obsoleted by RFC3435) (Updated by RFC3660) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2705) 2706 ECML v1: Field Names for E-Commerce. D. Eastlake 3rd, T. Goldstein. October 1999. (Format: TXT, HTML) (Obsoleted by RFC3106) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2706) 2707 Job Monitoring MIB - V1.0. R. Bergman, T. Hastings, S. Isaacson, H. Lewis. November 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2707) 2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB. R. Bergman. November 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2708) 2709 Security Model with Tunnel-mode IPsec for NAT Domains. P. Srisuresh. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2709) 2710 Multicast Listener Discovery (MLD) for IPv6. S. Deering, W. Fenner, B. Haberman. October 1999. (Format: TXT, HTML) (Updated by RFC3590, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2710) 2711 IPv6 Router Alert Option. C. Partridge, A. Jackson. October 1999. (Format: TXT, HTML) (Updated by RFC6398) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2711) 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2712) 2713 Schema for Representing Java(tm) Objects in an LDAP Directory. V. Ryan, S. Seligman, R. Lee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2713) 2714 Schema for Representing CORBA Object References in an LDAP Directory. V. Ryan, R. Lee, S. Seligman. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2714) 2715 Interoperability Rules for Multicast Routing Protocols. D. Thaler. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2715) 2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October 1999. (Format: TXT, HTML) (Obsoleted by RFC5216) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2716) 2717 Registration Procedures for URL Scheme Names. R. Petke, I. King. November 1999. (Format: TXT, HTML) (Obsoleted by RFC4395) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2717) 2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. November 1999. (Format: TXT, HTML) (Obsoleted by RFC4395) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2718) 2719 Framework Architecture for Signaling Transport. L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2719) 2720 Traffic Flow Measurement: Meter MIB. N. Brownlee. October 1999. (Format: TXT, HTML) (Obsoletes RFC2064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2720) 2721 RTFM: Applicability Statement. N. Brownlee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2721) 2722 Traffic Flow Measurement: Architecture. N. Brownlee, C. Mills, G. Ruth. October 1999. (Format: TXT, HTML) (Obsoletes RFC2063) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2722) 2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups. N. Brownlee. October 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2723) 2724 RTFM: New Attributes for Traffic Flow Measurement. S. Handelman, S. Stibler, N. Brownlee, G. Ruth. October 1999. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2724) 2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. December 1999. (Format: TXT, HTML) (Updated by RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2725) 2726 PGP Authentication for RIPE Database Updates. J. Zsako. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2726) 2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin. February 2000. (Format: TXT, HTML) (Obsoletes RFC2282) (Obsoleted by RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2727) 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal. R. Panabaker, S. Wegerif, D. Zigmond. November 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2728) 2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications. P. Bagnall, R. Briscoe, A. Poppitt. December 1999. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2729) 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP). S. Hanna, B. Patel, M. Shah. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2730) 2731 Encoding Dublin Core Metadata in HTML. J. Kunze. December 1999. (Format: TXT, HTML) (Obsoleted by RFC5791) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2731) 2732 Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999. (Format: TXT, HTML) (Obsoleted by RFC3986) (Updates RFC2396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2732) 2733 An RTP Payload Format for Generic Forward Error Correction. J. Rosenberg, H. Schulzrinne. December 1999. (Format: TXT, HTML) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2733) 2734 IPv4 over IEEE 1394. P. Johansson. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2734) 2735 NHRP Support for Virtual Private Networks. B. Fox, B. Petri. December 1999. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2735) 2736 Guidelines for Writers of RTP Payload Format Specifications. M. Handley, C. Perkins. December 1999. (Format: TXT, HTML) (Updated by RFC8088) (Also BCP0036) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2736) 2737 Entity MIB (Version 2). K. McCloghrie, A. Bierman. December 1999. (Format: TXT, HTML) (Obsoletes RFC2037) (Obsoleted by RFC4133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2737) 2738 Corrections to "A Syntax for Describing Media Feature Sets". G. Klyne. December 1999. (Format: TXT, HTML) (Updates RFC2533) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2738) 2739 Calendar Attributes for vCard and LDAP. T. Small, D. Hennessy, F. Dawson. January 2000. (Format: TXT, HTML) (Updated by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2739) 2740 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy. December 1999. (Format: TXT, HTML) (Obsoleted by RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2740) 2741 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B. Wijnen, M. Ellison, D. Francisco. January 2000. (Format: TXT, HTML) (Obsoletes RFC2257) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2741) 2742 Definitions of Managed Objects for Extensible SNMP Agents. L. Heintz, S. Gudur, M. Ellison. January 2000. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2742) 2743 Generic Security Service Application Program Interface Version 2, Update 1. J. Linn. January 2000. (Format: TXT, HTML) (Obsoletes RFC2078) (Updated by RFC5554, RFC5896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2743) 2744 Generic Security Service API Version 2 : C-bindings. J. Wray. January 2000. (Format: TXT, HTML) (Obsoletes RFC1509) (Updated by RFC5896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2744) 2745 RSVP Diagnostic Messages. A. Terzis, B. Braden, S. Vincent, L. Zhang. January 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2745) 2746 RSVP Operation Over IP Tunnels. A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. January 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2746) 2747 RSVP Cryptographic Authentication. F. Baker, B. Lindell, M. Talwar. January 2000. (Format: TXT, HTML) (Updated by RFC3097) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2747) 2748 The COPS (Common Open Policy Service) Protocol. D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. January 2000. (Format: TXT, HTML) (Updated by RFC4261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2748) 2749 COPS usage for RSVP. S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. January 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2749) 2750 RSVP Extensions for Policy Control. S. Herzog. January 2000. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2750) 2751 Signaled Preemption Priority Policy Element. S. Herzog. January 2000. (Format: TXT, HTML) (Obsoleted by RFC3181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2751) 2752 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. January 2000. (Format: TXT, HTML) (Obsoleted by RFC3182) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2752) 2753 A Framework for Policy-based Admission Control. R. Yavatkar, D. Pendarakis, R. Guerin. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2753) 2754 RPS IANA Issues. C. Alaettinoglu, C. Villamizar, R. Govindan. January 2000. (Format: TXT, HTML) (Obsoleted by RFC6254) (Status: HISTORIC) (DOI: 10.17487/RFC2754) 2755 Security Negotiation for WebNFS. A. Chiu, M. Eisler, B. Callaghan. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2755) 2756 Hyper Text Caching Protocol (HTCP/0.0). P. Vixie, D. Wessels. January 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2756) 2757 Long Thin Networks. G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2757) 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring. K. White. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2758) 2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2759) 2760 Ongoing TCP Research Related to Satellites. M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2760) 2761 Terminology for ATM Benchmarking. J. Dunn, C. Martin. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2761) 2762 Sampling of the Group Membership in RTP. J. Rosenberg, H. Schulzrinne. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2762) 2763 Dynamic Hostname Exchange Mechanism for IS-IS. N. Shen, H. Smit. February 2000. (Format: TXT, HTML) (Obsoleted by RFC5301) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2763) 2764 A Framework for IP Based Virtual Private Networks. B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2764) 2765 Stateless IP/ICMP Translation Algorithm (SIIT). E. Nordmark. February 2000. (Format: TXT, HTML) (Obsoleted by RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2765) 2766 Network Address Translation - Protocol Translation (NAT-PT). G. Tsirtsis, P. Srisuresh. February 2000. (Format: TXT, HTML) (Obsoleted by RFC4966) (Updated by RFC3152) (Status: HISTORIC) (DOI: 10.17487/RFC2766) 2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS). K. Tsuchiya, H. Higuchi, Y. Atarashi. February 2000. (Format: TXT, HTML) (Obsoleted by RFC6535) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2767) 2768 Network Policy and Services: A Report of a Workshop on Middleware. B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2768) 2769 Routing Policy System Replication. C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. February 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2769) 2770 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. February 2000. (Format: TXT, HTML) (Obsoleted by RFC3180) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2770) 2771 An Abstract API for Multicast Address Allocation. R. Finlayson. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2771) 2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February 2000. (Format: TXT, HTML) (Obsoletes RFC2546) (Updated by RFC3152) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2772) 2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace. February 2000. (Format: TXT, HTML) (Updates RFC0959) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2773) 2774 An HTTP Extension Framework. H. Nielsen, P. Leach, S. Lawrence. February 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2774) 2775 Internet Transparency. B. Carpenter. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2775) 2776 Multicast-Scope Zone Announcement Protocol (MZAP). M. Handley, D. Thaler, R. Kermode. February 2000. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2776) 2777 Publicly Verifiable Nomcom Random Selection. D. Eastlake 3rd. February 2000. (Format: TXT, HTML) (Obsoleted by RFC3797) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2777) 2778 A Model for Presence and Instant Messaging. M. Day, J. Rosenberg, H. Sugano. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2778) 2779 Instant Messaging / Presence Protocol Requirements. M. Day, S. Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2779) 2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000. (Format: TXT, HTML) (Updated by RFC4443, RFC5237, RFC5771, RFC6335, RFC7045) (Also BCP0037) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2780) 2781 UTF-16, an encoding of ISO 10646. P. Hoffman, F. Yergeau. February 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2781) 2782 A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. (Format: TXT, HTML) (Obsoletes RFC2052) (Updated by RFC6335, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2782) 2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0. J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2783) 2784 Generic Routing Encapsulation (GRE). D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina. March 2000. (Format: TXT, HTML) (Updated by RFC2890) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2784) 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME. R. Zuccherato. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2785) 2786 Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2786) 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol. B. Jewell, D. Chuang. March 2000. (Format: TXT, HTML) (Obsoleted by RFC6527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2787) 2788 Network Services Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT, HTML) (Obsoletes RFC2248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2788) 2789 Mail Monitoring MIB. N. Freed, S. Kille. March 2000. (Format: TXT, HTML) (Obsoletes RFC2249, RFC1566) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2789) 2790 Host Resources MIB. S. Waldbusser, P. Grillo. March 2000. (Format: TXT, HTML) (Obsoletes RFC1514) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2790) 2791 Scalable Routing Design Principles. J. Yu. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2791) 2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System. M. Blaze, J. Ioannidis, A. Keromytis. March 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2792) 2793 RTP Payload for Text Conversation. G. Hellstrom. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4103) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2793) 2794 Mobile IP Network Access Identifier Extension for IPv4. P. Calhoun, C. Perkins. March 2000. (Format: TXT, HTML) (Updates RFC2290) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2794) 2795 The Infinite Monkey Protocol Suite (IMPS). S. Christey. 1 April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2795) 2796 BGP Route Reflection - An Alternative to Full Mesh IBGP. T. Bates, R. Chandra, E. Chen. April 2000. (Format: TXT, HTML) (Obsoleted by RFC4456) (Updates RFC1966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2796) 2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J. Schaad, J. Weinstein. April 2000. (Format: TXT, HTML) (Obsoleted by RFC5272) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2797) 2798 Definition of the inetOrgPerson LDAP Object Class. M. Smith. April 2000. (Format: TXT, HTML) (Updated by RFC3698, RFC4519, RFC4524) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2798) 2799 Request for Comments Summary RFC Numbers 2700-2799. S. Ginoza. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2799) 2800 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. May 2001. (Format: TXT, HTML) (Obsoletes RFC2700) (Obsoleted by RFC2900) (Status: HISTORIC) (DOI: 10.17487/RFC2800) 2801 Internet Open Trading Protocol - IOTP Version 1.0. D. Burdett. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2801) 2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP). K. Davidson, Y. Kawatsura. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2802) 2803 Digest Values for DOM (DOMHASH). H. Maruyama, K. Tamura, N. Uramoto. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2803) 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2804) 2805 Media Gateway Control Protocol Architecture and Requirements. N. Greene, M. Ramalho, B. Rosen. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2805) 2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format: TXT, HTML) (Obsoleted by RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2806) 2807 XML Signature Requirements. J. Reagle. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2807) 2808 The SecurID(r) SASL Mechanism. M. Nystrom. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2808) 2809 Implementation of L2TP Compulsory Tunneling via RADIUS. B. Aboba, G. Zorn. April 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2809) 2810 Internet Relay Chat: Architecture. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2810) 2811 Internet Relay Chat: Channel Management. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2811) 2812 Internet Relay Chat: Client Protocol. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2812) 2813 Internet Relay Chat: Server Protocol. C. Kalt. April 2000. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2813) 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks. R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. May 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2814) 2815 Integrated Service Mappings on IEEE 802 Networks. M. Seaman, A. Smith, E. Crawley, J. Wroclawski. May 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2815) 2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies. A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2816) 2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May 2000. (Format: TXT, HTML) (Updates RFC2616) (Updated by RFC7230, RFC7231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2817) 2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT, HTML) (Updated by RFC5785, RFC7230) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2818) 2819 Remote Network Monitoring Management Information Base. S. Waldbusser. May 2000. (Format: TXT, HTML) (Obsoletes RFC1757) (Also STD0059) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2819) 2820 Access Control Requirements for LDAP. E. Stokes, D. Byrne, B. Blakley, P. Behera. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2820) 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT, HTML) (Obsoletes RFC0821, RFC0974, RFC1869) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2821) 2822 Internet Message Format. P. Resnick, Ed.. April 2001. (Format: TXT, HTML) (Obsoletes RFC0822) (Obsoleted by RFC5322) (Updated by RFC5335, RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2822) 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing. J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester. May 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2823) 2824 Call Processing Language Framework and Requirements. J. Lennox, H. Schulzrinne. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2824) 2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols. IAB, L. Daigle, Ed.. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2825) 2826 IAB Technical Comment on the Unique DNS Root. Internet Architecture Board. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2826) 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT, HTML) (Obsoletes RFC2267) (Updated by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2827) 2828 Internet Security Glossary. R. Shirey. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4949) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2828) 2829 Authentication Methods for LDAP. M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4513, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2829) 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. J. Hodges, R. Morgan, M. Wahl. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4511, RFC4513, RFC4510) (Updated by RFC3377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2830) 2831 Using Digest Authentication as a SASL Mechanism. P. Leach, C. Newman. May 2000. (Format: TXT, HTML) (Obsoleted by RFC6331) (Status: HISTORIC) (DOI: 10.17487/RFC2831) 2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0. S. Hollenbeck, M. Srivastava. May 2000. (Format: TXT, HTML) (Updated by RFC3632) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2832) 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. H. Schulzrinne, S. Petrack. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4733, RFC4734) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2833) 2834 ARP and IP Broadcast over HIPPI-800. J.-M. Pittet. May 2000. (Format: TXT, HTML) (Obsoletes RFC1374) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2834) 2835 IP and ARP over HIPPI-6400 (GSN). J.-M. Pittet. May 2000. (Format: TXT, HTML) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2835) 2836 Per Hop Behavior Identification Codes. S. Brim, B. Carpenter, F. Le Faucheur. May 2000. (Format: TXT, HTML) (Obsoleted by RFC3140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2836) 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard. K. Teow. May 2000. (Format: TXT, HTML) (Obsoleted by RFC4044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2837) 2838 Uniform Resource Identifiers for Television Broadcasts. D. Zigmond, M. Vickers. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2838) 2839 Internet Kermit Service. F. da Cruz, J. Altman. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2839) 2840 TELNET KERMIT OPTION. J. Altman, F. da Cruz. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2840) 2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC). P. Metzger, W. Simpson. November 2000. (Format: TXT, HTML) (Obsoletes RFC1852) (Status: HISTORIC) (DOI: 10.17487/RFC2841) 2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. May 2000. (Format: TXT, HTML) (Obsoleted by RFC3392) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2842) 2843 Proxy-PAR. P. Droz, T. Przygienda. May 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2843) 2844 OSPF over ATM and Proxy-PAR. T. Przygienda, P. Droz, R. Haas. May 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2844) 2845 Secret Key Transaction Authentication for DNS (TSIG). P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington. May 2000. (Format: TXT, HTML) (Updates RFC1035) (Updated by RFC3645, RFC4635, RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2845) 2846 GSTN Address Element Extensions in E-mail Services. C. Allocchio. June 2000. (Format: TXT, HTML) (Updated by RFC3191, RFC3192) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2846) 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM. M. Eisler. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2847) 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services. S. Petrack, L. Conroy. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2848) 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification. G. Good. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2849) 2850 Charter of the Internet Architecture Board (IAB). Internet Architecture Board, B. Carpenter, Ed.. May 2000. (Format: TXT, HTML) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2850) 2851 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. June 2000. (Format: TXT, HTML) (Obsoleted by RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2851) 2852 Deliver By SMTP Service Extension. D. Newman. June 2000. (Format: TXT, HTML) (Updates RFC1894) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2852) 2853 Generic Security Service API Version 2 : Java Bindings. J. Kabat, M. Upadhyay. June 2000. (Format: TXT, HTML) (Obsoleted by RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2853) 2854 The 'text/html' Media Type. D. Connolly, L. Masinter. June 2000. (Format: TXT, HTML) (Obsoletes RFC2070, RFC1980, RFC1942, RFC1867, RFC1866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2854) 2855 DHCP for IEEE 1394. K. Fujisawa. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2855) 2856 Textual Conventions for Additional High Capacity Data Types. A. Bierman, K. McCloghrie, R. Presuhn. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2856) 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH. A. Keromytis, N. Provos. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2857) 2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. June 2000. (Format: TXT, HTML) (Obsoletes RFC2283) (Obsoleted by RFC4760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2858) 2859 A Time Sliding Window Three Colour Marker (TSWTCM). W. Fang, N. Seddigh, B. Nandy. June 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2859) 2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority. B. Carpenter, F. Baker, M. Roberts. June 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2860) 2861 TCP Congestion Window Validation. M. Handley, J. Padhye, S. Floyd. June 2000. (Format: TXT, HTML) (Obsoleted by RFC7661) (Status: HISTORIC) (DOI: 10.17487/RFC2861) 2862 RTP Payload Format for Real-Time Pointers. M. Civanlar, G. Cash. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2862) 2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Format: TXT, HTML) (Obsoletes RFC2233) (Updated by RFC8892) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2863) 2864 The Inverted Stack Table Extension to the Interfaces Group MIB. K. McCloghrie, G. Hanson. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2864) 2865 Remote Authentication Dial In User Service (RADIUS). C. Rigney, S. Willens, A. Rubens, W. Simpson. June 2000. (Format: TXT, HTML) (Obsoletes RFC2138) (Updated by RFC2868, RFC3575, RFC5080, RFC6929, RFC8044) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2865) 2866 RADIUS Accounting. C. Rigney. June 2000. (Format: TXT, HTML) (Obsoletes RFC2139) (Updated by RFC2867, RFC5080, RFC5997) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2866) 2867 RADIUS Accounting Modifications for Tunnel Protocol Support. G. Zorn, B. Aboba, D. Mitton. June 2000. (Format: TXT, HTML) (Updates RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2867) 2868 RADIUS Attributes for Tunnel Protocol Support. G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. June 2000. (Format: TXT, HTML) (Updates RFC2865) (Updated by RFC3575) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2868) 2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000. (Format: TXT, HTML) (Updated by RFC3579, RFC5080) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2869) 2870 Root Name Server Operational Requirements. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT, HTML) (Obsoletes RFC2010) (Obsoleted by RFC7720) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2870) 2871 A Framework for Telephony Routing over IP. J. Rosenberg, H. Schulzrinne. June 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2871) 2872 Application and Sub Application Identity Policy Element for Use with RSVP. Y. Bernet, R. Pabbati. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2872) 2873 TCP Processing of the IPv4 Precedence Field. X. Xiao, A. Hannan, V. Paxson, E. Crabbe. June 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2873) 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT, HTML) (Updates RFC1886) (Updated by RFC3152, RFC3226, RFC3363, RFC3364) (Status: HISTORIC) (DOI: 10.17487/RFC2874) 2875 Diffie-Hellman Proof-of-Possession Algorithms. H. Prafullchandra, J. Schaad. July 2000. (Format: TXT, HTML) (Obsoleted by RFC6955) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2875) 2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2876) 2877 5250 Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. July 2000. (Format: TXT, HTML) (Obsoleted by RFC4777) (Updates RFC1205) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2877) 2878 PPP Bridging Control Protocol (BCP). M. Higashiyama, F. Baker. July 2000. (Format: TXT, HTML) (Obsoletes RFC1638) (Obsoleted by RFC3518) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2878) 2879 Content Feature Schema for Internet Fax (V2). G. Klyne, L. McIntyre. August 2000. (Format: TXT, HTML) (Obsoletes RFC2531) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2879) 2880 Internet Fax T.30 Feature Mapping. L. McIntyre, G. Klyne. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2880) 2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model. D. Mitton, M. Beadles. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2881) 2882 Network Access Servers Requirements: Extended RADIUS Practices. D. Mitton. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2882) 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP. S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. July 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2883) 2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks. J. Hadi Salim, U. Ahmed. July 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2884) 2885 Megaco Protocol version 0.8. F. Cuervo, N. Greene, C. Huitema, A. Rayhan, B. Rosen, J. Segers. August 2000. (Format: TXT, HTML) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2885) 2886 Megaco Errata. T. Taylor. August 2000. (Format: TXT, HTML) (Obsoleted by RFC3015) (Status: HISTORIC) (DOI: 10.17487/RFC2886) 2887 The Reliable Multicast Design Space for Bulk Data Transfer. M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2887) 2888 Secure Remote Access with L2TP. P. Srisuresh. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2888) 2889 Benchmarking Methodology for LAN Switching Devices. R. Mandeville, J. Perser. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2889) 2890 Key and Sequence Number Extensions to GRE. G. Dommety. September 2000. (Format: TXT, HTML) (Updates RFC2784) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2890) 2891 LDAP Control Extension for Server Side Sorting of Search Results. T. Howes, M. Wahl, A. Anantha. August 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2891) 2892 The Cisco SRP MAC Layer Protocol. D. Tsiang, G. Suwala. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2892) 2893 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E. Nordmark. August 2000. (Format: TXT, HTML) (Obsoletes RFC1933) (Obsoleted by RFC4213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2893) 2894 Router Renumbering for IPv6. M. Crawford. August 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2894) 2895 Remote Network Monitoring MIB Protocol Identifier Reference. A. Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT, HTML) (Obsoletes RFC2074) (Updated by RFC3395) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC2895) 2896 Remote Network Monitoring MIB Protocol Identifier Macros. A. Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2896) 2897 Proposal for an MGCP Advanced Audio Package. D. Cromwell. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2897) 2898 PKCS #5: Password-Based Cryptography Specification Version 2.0. B. Kaliski. September 2000. (Format: TXT, HTML) (Obsoleted by RFC8018) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2898) 2899 Request for Comments Summary RFC Numbers 2800-2899. S. Ginoza. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2899) 2900 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza. August 2001. (Format: TXT, HTML) (Obsoletes RFC2800) (Obsoleted by RFC3000) (Status: HISTORIC) (DOI: 10.17487/RFC2900) 2901 Guide to Administrative Procedures of the Internet Infrastructure. Z. Wenzel, J. Klensin, R. Bush, S. Huter. August 2000. (Format: TXT, HTML) (Also FYI0037) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2901) 2902 Overview of the 1998 IAB Routing Workshop. S. Deering, S. Hares, C. Perkins, R. Perlman. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2902) 2903 Generic AAA Architecture. C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence. August 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2903) 2904 AAA Authorization Framework. J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2904) 2905 AAA Authorization Application Examples. J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2905) 2906 AAA Authorization Requirements. S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. August 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2906) 2907 MADCAP Multicast Scope Nesting State Option. R. Kermode. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2907) 2908 The Internet Multicast Address Allocation Architecture. D. Thaler, M. Handley, D. Estrin. September 2000. (Format: TXT, HTML) (Obsoleted by RFC6308) (Status: HISTORIC) (DOI: 10.17487/RFC2908) 2909 The Multicast Address-Set Claim (MASC) Protocol. P. Radoslavov, D. Estrin, R. Govindan, M. Handley, S. Kumar, D. Thaler. September 2000. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC2909) 2910 Internet Printing Protocol/1.1: Encoding and Transport. R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. September 2000. (Format: TXT, HTML) (Obsoletes RFC2565) (Obsoleted by RFC8010) (Updated by RFC3380, RFC3381, RFC3382, RFC3510, RFC3995, RFC7472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2910) 2911 Internet Printing Protocol/1.1: Model and Semantics. T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell. September 2000. (Format: TXT, HTML) (Obsoletes RFC2566) (Obsoleted by RFC8011) (Updated by RFC3380, RFC3382, RFC3996, RFC3995, RFC7472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2911) 2912 Indicating Media Features for MIME Content. G. Klyne. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2912) 2913 MIME Content Types in Media Feature Expressions. G. Klyne. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2913) 2914 Congestion Control Principles. S. Floyd. September 2000. (Format: TXT, HTML) (Updated by RFC7141) (Also BCP0041) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2914) 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record. M. Mealling, R. Daniel. September 2000. (Format: TXT, HTML) (Obsoleted by RFC3401, RFC3402, RFC3403, RFC3404) (Updates RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2915) 2916 E.164 number and DNS. P. Faltstrom. September 2000. (Format: TXT, HTML) (Obsoleted by RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2916) 2917 A Core MPLS IP VPN Architecture. K. Muthukrishnan, A. Malis. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2917) 2918 Route Refresh Capability for BGP-4. E. Chen. September 2000. (Format: TXT, HTML) (Updated by RFC7313) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2918) 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists. R. Chandhok, G. Wenger. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2919) 2920 SMTP Service Extension for Command Pipelining. N. Freed. September 2000. (Format: TXT, HTML) (Obsoletes RFC2197) (Also STD0060) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC2920) 2921 6BONE pTLA and pNLA Formats (pTLA). B. Fink. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2921) 2922 Physical Topology MIB. A. Bierman, K. Jones. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2922) 2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2923) 2924 Accounting Attributes and Record Formats. N. Brownlee, A. Blount. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2924) 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. K. White. September 2000. (Format: TXT, HTML) (Obsoleted by RFC4560) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2925) 2926 Conversion of LDAP Schemas to and from SLP Templates. J. Kempf, R. Moats, P. St. Pierre. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2926) 2927 MIME Directory Profile for LDAP Schema. M. Wahl. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2927) 2928 Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S. Deering, R. Fink, T. Hain. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2928) 2929 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd, E. Brunner-Williams, B. Manning. September 2000. (Format: TXT, HTML) (Obsoleted by RFC5395) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2929) 2930 Secret Key Establishment for DNS (TKEY RR). D. Eastlake 3rd. September 2000. (Format: TXT, HTML) (Updated by RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2930) 2931 DNS Request and Transaction Signatures ( SIG(0)s ). D. Eastlake 3rd. September 2000. (Format: TXT, HTML) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2931) 2932 IPv4 Multicast Routing MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT, HTML) (Obsoleted by RFC5132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2932) 2933 Internet Group Management Protocol MIB. K. McCloghrie, D. Farinacci, D. Thaler. October 2000. (Format: TXT, HTML) (Obsoleted by RFC5519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2933) 2934 Protocol Independent Multicast MIB for IPv4. K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner. October 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2934) 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement. D. Eastlake 3rd, C. Smith. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2935) 2936 HTTP MIME Type Handler Detection. D. Eastlake 3rd, C. Smith, D. Soroka. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2936) 2937 The Name Service Search Option for DHCP. C. Smith. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2937) 2938 Identifying Composite Media Features. G. Klyne, L. Masinter. September 2000. (Format: TXT, HTML) (Updates RFC2533) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2938) 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types. R. Droms. September 2000. (Format: TXT, HTML) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2939) 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients. A. Smith, D. Partain, J. Seligson. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2940) 2941 Telnet Authentication Option. T. Ts'o, Ed., J. Altman. September 2000. (Format: TXT, HTML) (Obsoletes RFC1416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2941) 2942 Telnet Authentication: Kerberos Version 5. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2942) 2943 TELNET Authentication Using DSA. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2943) 2944 Telnet Authentication: SRP. T. Wu. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2944) 2945 The SRP Authentication and Key Exchange System. T. Wu. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2945) 2946 Telnet Data Encryption Option. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2946) 2947 Telnet Encryption: DES3 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2947) 2948 Telnet Encryption: DES3 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2948) 2949 Telnet Encryption: CAST-128 64 bit Output Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2949) 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback. J. Altman. September 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2950) 2951 TELNET Authentication Using KEA and SKIPJACK. R. Housley, T. Horting, P. Yee. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2951) 2952 Telnet Encryption: DES 64 bit Cipher Feedback. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2952) 2953 Telnet Encryption: DES 64 bit Output Feedback. T. Ts'o. September 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2953) 2954 Definitions of Managed Objects for Frame Relay Service. K. Rehbehn, D. Fowler. October 2000. (Format: TXT, HTML) (Obsoletes RFC1604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2954) 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function. K. Rehbehn, O. Nicklass, G. Mouradian. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2955) 2956 Overview of 1999 IAB Network Layer Workshop. M. Kaat. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2956) 2957 The application/whoispp-query Content-Type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2957) 2958 The application/whoispp-response Content-type. L. Daigle, P. Faltstrom. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2958) 2959 Real-Time Transport Protocol Management Information Base. M. Baugher, B. Strahm, I. Suconick. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2959) 2960 Stream Control Transmission Protocol. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. October 2000. (Format: TXT, HTML) (Obsoleted by RFC4960) (Updated by RFC3309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2960) 2961 RSVP Refresh Overhead Reduction Extensions. L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini. April 2001. (Format: TXT, HTML) (Updated by RFC5063) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2961) 2962 An SNMP Application Level Gateway for Payload Address Translation. D. Raz, J. Schoenwaelder, B. Sugla. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2962) 2963 A Rate Adaptive Shaper for Differentiated Services. O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2963) 2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT, HTML) (Also BCP0044) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2964) 2965 HTTP State Management Mechanism. D. Kristol, L. Montulli. October 2000. (Format: TXT, HTML) (Obsoletes RFC2109) (Obsoleted by RFC6265) (Status: HISTORIC) (DOI: 10.17487/RFC2965) 2966 Domain-wide Prefix Distribution with Two-Level IS-IS. T. Li, T. Przygienda, H. Smit. October 2000. (Format: TXT, HTML) (Obsoleted by RFC5302) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2966) 2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways. L. Daigle, R. Hedberg. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2967) 2968 Mesh of Multiple DAG servers - Results from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2968) 2969 Wide Area Directory Deployment - Experiences from TISDAG. T. Eklof, L. Daigle. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2969) 2970 Architecture for Integrated Directory Services - Result from TISDAG. L. Daigle, T. Eklof. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2970) 2971 IMAP4 ID extension. T. Showalter. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2971) 2972 Context and Goals for Common Name Resolution. N. Popp, M. Mealling, L. Masinter, K. Sollins. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2972) 2973 IS-IS Mesh Groups. R. Balay, D. Katz, J. Parker. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2973) 2974 Session Announcement Protocol. M. Handley, C. Perkins, E. Whelan. October 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC2974) 2975 Introduction to Accounting Management. B. Aboba, J. Arkko, D. Harrington. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2975) 2976 The SIP INFO Method. S. Donovan. October 2000. (Format: TXT, HTML) (Obsoleted by RFC6086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2976) 2977 Mobile IP Authentication, Authorization, and Accounting Requirements. S. Glass, T. Hiller, S. Jacobs, C. Perkins. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2977) 2978 IANA Charset Registration Procedures. N. Freed, J. Postel. October 2000. (Format: TXT, HTML) (Obsoletes RFC2278) (Also BCP0019) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC2978) 2979 Behavior of and Requirements for Internet Firewalls. N. Freed. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2979) 2980 Common NNTP Extensions. S. Barber. October 2000. (Format: TXT, HTML) (Updated by RFC3977, RFC4643, RFC4644, RFC6048) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2980) 2981 Event MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2981) 2982 Distributed Management Expression MIB. R. Kavasseri, Ed.. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2982) 2983 Differentiated Services and Tunnels. D. Black. October 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2983) 2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams. October 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2984) 2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0. M. Nystrom, B. Kaliski. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2985) 2986 PKCS #10: Certification Request Syntax Specification Version 1.7. M. Nystrom, B. Kaliski. November 2000. (Format: TXT, HTML) (Obsoletes RFC2314) (Updated by RFC5967) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2986) 2987 Registration of Charset and Languages Media Features Tags. P. Hoffman. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2987) 2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000. (Format: TXT, HTML) (Obsoleted by RFC6298) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2988) 2989 Criteria for Evaluating AAA Protocols for Network Access. B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2989) 2990 Next Steps for the IP QoS Architecture. G. Huston. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2990) 2991 Multipath Issues in Unicast and Multicast Next-Hop Selection. D. Thaler, C. Hopps. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2991) 2992 Analysis of an Equal-Cost Multi-Path Algorithm. C. Hopps. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2992) 2993 Architectural Implications of NAT. T. Hain. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2993) 2994 A Description of the MISTY1 Encryption Algorithm. H. Ohta, M. Matsui. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2994) 2995 Pre-Spirits Implementations of PSTN-initiated Services. H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2995) 2996 Format of the RSVP DCLASS Object. Y. Bernet. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2996) 2997 Specification of the Null Service Type. Y. Bernet, A. Smith, B. Davie. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC2997) 2998 A Framework for Integrated Services Operation over Diffserv Networks. Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. November 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2998) 2999 Request for Comments Summary RFC Numbers 2900-2999. S. Ginoza. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC2999) 3000 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, L. Shiota. November 2001. (Format: TXT, HTML) (Obsoletes RFC2900) (Obsoleted by RFC3300) (Status: HISTORIC) (DOI: 10.17487/RFC3000) 3001 A URN Namespace of Object Identifiers. M. Mealling. November 2000. (Format: TXT, HTML) (Obsoleted by RFC3061) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3001) 3002 Overview of 2000 IAB Wireless Internetworking Workshop. D. Mitzel. December 2000. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3002) 3003 The audio/mpeg Media Type. M. Nilsson. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3003) 3004 The User Class Option for DHCP. G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3004) 3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT, HTML) (Updated by RFC8717) (Also BCP0045) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3005) 3006 Integrated Services in the Presence of Compressible Flows. B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3006) 3007 Secure Domain Name System (DNS) Dynamic Update. B. Wellington. November 2000. (Format: TXT, HTML) (Obsoletes RFC2137) (Updates RFC2535, RFC2136) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3007) 3008 Domain Name System Security (DNSSEC) Signing Authority. B. Wellington. November 2000. (Format: TXT, HTML) (Obsoleted by RFC4035, RFC4033, RFC4034) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3008) 3009 Registration of parityfec MIME types. J. Rosenberg, H. Schulzrinne. November 2000. (Format: TXT, HTML) (Obsoleted by RFC5109) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3009) 3010 NFS version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. December 2000. (Format: TXT, HTML) (Obsoleted by RFC3530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3010) 3011 The IPv4 Subnet Selection Option for DHCP. G. Waters. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3011) 3012 Mobile IPv4 Challenge/Response Extensions. C. Perkins, P. Calhoun. November 2000. (Format: TXT, HTML) (Obsoleted by RFC4721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3012) 3013 Recommended Internet Service Provider Security Services and Procedures. T. Killalea. November 2000. (Format: TXT, HTML) (Also BCP0046) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3013) 3014 Notification Log MIB. R. Kavasseri. November 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3014) 3015 Megaco Protocol Version 1.0. F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. November 2000. (Format: TXT, HTML) (Obsoletes RFC2885, RFC2886) (Obsoleted by RFC3525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3015) 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams. Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. November 2000. (Format: TXT, HTML) (Obsoleted by RFC6416) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3016) 3017 XML DTD for Roaming Access Phone Book. M. Riegel, G. Zorn. December 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3017) 3018 Unified Memory Space Protocol Specification. A. Bogdanov. December 2000. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3018) 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol. B. Haberman, R. Worzella. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3019) 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function. P. Pate, B. Lynch, K. Rehbehn. December 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3020) 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links. A. Retana, R. White, V. Fuller, D. McPherson. December 2000. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3021) 3022 Traditional IP Network Address Translator (Traditional NAT). P. Srisuresh, K. Egevang. January 2001. (Format: TXT, HTML) (Obsoletes RFC1631) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3022) 3023 XML Media Types. M. Murata, S. St. Laurent, D. Kohn. January 2001. (Format: TXT, HTML) (Obsoletes RFC2376) (Obsoleted by RFC7303) (Updates RFC2048) (Updated by RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3023) 3024 Reverse Tunneling for Mobile IP, revised. G. Montenegro, Ed.. January 2001. (Format: TXT, HTML) (Obsoletes RFC2344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3024) 3025 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. February 2001. (Format: TXT, HTML) (Obsoleted by RFC3115) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3025) 3026 Liaison to IETF/ISOC on ENUM. R. Blane. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3026) 3027 Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3027) 3028 Sieve: A Mail Filtering Language. T. Showalter. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5228, RFC5429) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3028) 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols. C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato. February 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3029) 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages. G. Vaudreuil. December 2000. (Format: TXT, HTML) (Obsoletes RFC1830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3030) 3031 Multiprotocol Label Switching Architecture. E. Rosen, A. Viswanathan, R. Callon. January 2001. (Format: TXT, HTML) (Updated by RFC6178, RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3031) 3032 MPLS Label Stack Encoding. E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. January 2001. (Format: TXT, HTML) (Updated by RFC3443, RFC4182, RFC5332, RFC3270, RFC5129, RFC5462, RFC5586, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3032) 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol. M. Suzuki. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3033) 3034 Use of Label Switching on Frame Relay Networks Specification. A. Conta, P. Doolan, A. Malis. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3034) 3035 MPLS using LDP and ATM VC Switching. B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3035) 3036 LDP Specification. L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5036) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3036) 3037 LDP Applicability. B. Thomas, E. Gray. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3037) 3038 VCID Notification over ATM link for LDP. K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan. January 2001. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3038) 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile. S. Santesson, W. Polk, P. Barzin, M. Nystrom. January 2001. (Format: TXT, HTML) (Obsoleted by RFC3739) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3039) 3040 Internet Web Replication and Caching Taxonomy. I. Cooper, I. Melve, G. Tomlinson. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3040) 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves. January 2001. (Format: TXT, HTML) (Obsoleted by RFC4941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3041) 3042 Enhancing TCP's Loss Recovery Using Limited Transmit. M. Allman, H. Balakrishnan, S. Floyd. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3042) 3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations. M. Mealling. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3043) 3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace. S. Rozenfeld. January 2001. (Format: TXT, HTML) (Obsoleted by RFC8254) (Status: HISTORIC) (DOI: 10.17487/RFC3044) 3045 Storing Vendor Information in the LDAP root DSE. M. Meredith. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3045) 3046 DHCP Relay Agent Information Option. M. Patrick. January 2001. (Format: TXT, HTML) (Updated by RFC6607) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3046) 3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. January 2001. (Format: TXT, HTML) (Obsoleted by RFC5577) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3047) 3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer. B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3048) 3049 TN3270E Service Location and Session Balancing. J. Naugle, K. Kasthurirangan, G. Ledford. January 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3049) 3050 Common Gateway Interface for SIP. J. Lennox, H. Schulzrinne, J. Rosenberg. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3050) 3051 IP Payload Compression Using ITU-T V.44 Packet Method. J. Heath, J. Border. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3051) 3052 Service Management Architectures Issues and Review. M. Eder, S. Nag. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3052) 3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3053) 3054 Megaco IP Phone Media Gateway Application Profile. P. Blatherwick, R. Bell, P. Holland. January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3054) 3055 Management Information Base for the PINT Services Architecture. M. Krishnaswamy, D. Romascanu. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3055) 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3056) 3057 ISDN Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. February 2001. (Format: TXT, HTML) (Obsoleted by RFC4233) (Updated by RFC3807) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3057) 3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P. Hartmann, D. Kuenzi. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3058) 3059 Attribute List Extension for the Service Location Protocol. E. Guttman. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3059) 3060 Policy Core Information Model -- Version 1 Specification. B. Moore, E. Ellesson, J. Strassner, A. Westerinen. February 2001. (Format: TXT, HTML) (Updated by RFC3460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3060) 3061 A URN Namespace of Object Identifiers. M. Mealling. February 2001. (Format: TXT, HTML) (Obsoletes RFC3001) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3061) 3062 LDAP Password Modify Extended Operation. K. Zeilenga. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3062) 3063 MPLS Loop Prevention Mechanism. Y. Ohba, Y. Katsube, E. Rosen, P. Doolan. February 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3063) 3064 MGCP CAS Packages. B. Foster. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3064) 3065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. February 2001. (Format: TXT, HTML) (Obsoletes RFC1965) (Obsoleted by RFC5065) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3065) 3066 Tags for the Identification of Languages. H. Alvestrand. January 2001. (Format: TXT, HTML) (Obsoletes RFC1766) (Obsoleted by RFC4646, RFC4647) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3066) 3067 TERENA'S Incident Object Description and Exchange Format Requirements. J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3067) 3068 An Anycast Prefix for 6to4 Relay Routers. C. Huitema. June 2001. (Format: TXT, HTML) (Obsoleted by RFC7526) (Status: HISTORIC) (DOI: 10.17487/RFC3068) 3069 VLAN Aggregation for Efficient IP Address Allocation. D. McPherson, B. Dykes. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3069) 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay. V. Rawat, R. Tio, S. Nanji, R. Verma. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3070) 3071 Reflections on the DNS, RFC 1591, and Categories of Domains. J. Klensin. February 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3071) 3072 Structured Data Exchange Format (SDXF). M. Wildgrube. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3072) 3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration. J. Collins. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3073) 3074 DHC Load Balancing Algorithm. B. Volz, S. Gonczi, T. Lemon, R. Stevens. February 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3074) 3075 XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2001. (Format: TXT, HTML) (Obsoleted by RFC3275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3075) 3076 Canonical XML Version 1.0. J. Boyer. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3076) 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links. E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3077) 3078 Microsoft Point-To-Point Encryption (MPPE) Protocol. G. Pall, G. Zorn. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3078) 3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). G. Zorn. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3079) 3080 The Blocks Extensible Exchange Protocol Core. M. Rose. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3080) 3081 Mapping the BEEP Core onto TCP. M. Rose. March 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3081) 3082 Notification and Subscription for SLP. J. Kempf, J. Goldschmidt. March 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3082) 3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems. R. Woundy. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3083) 3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3084) 3085 URN Namespace for NewsML Resources. A. Coates, D. Allen, D. Rivers-Moore. March 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3085) 3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification. K. Nichols, B. Carpenter. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3086) 3087 Control of Service Context using SIP Request-URI. B. Campbell, R. Sparks. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3087) 3088 OpenLDAP Root Service An experimental LDAP referral service. K. Zeilenga. April 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3088) 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. H. Kitamura. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3089) 3090 DNS Security Extension Clarification on Zone Status. E. Lewis. March 2001. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Updated by RFC3658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3090) 3091 Pi Digit Generation Protocol. H. Kennedy. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3091) 3092 Etymology of "Foo". D. Eastlake 3rd, C. Manros, E. Raymond. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3092) 3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner. 1 April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3093) 3094 Tekelec's Transport Adapter Layer Interface. D. Sprague, R. Benedyk, D. Brendes, J. Keller. April 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3094) 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT, HTML) (Updated by RFC3759, RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3095) 3096 Requirements for robust IP/UDP/RTP header compression. M. Degermark, Ed.. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3096) 3097 RSVP Cryptographic Authentication -- Updated Message Type Value. R. Braden, L. Zhang. April 2001. (Format: TXT, HTML) (Updates RFC2747) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3097) 3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$. T. Gavin, D. Eastlake 3rd, S. Hambridge. April 2001. (Format: TXT, HTML) (Also FYI0038) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3098) 3099 Request for Comments Summary RFC Numbers 3000-3099. S. Ginoza. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3099) 3100 Not Issued. 3101 The OSPF Not-So-Stubby Area (NSSA) Option. P. Murphy. January 2003. (Format: TXT, HTML) (Obsoletes RFC1587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3101) 3102 Realm Specific IP: Framework. M. Borella, J. Lo, D. Grabelsky, G. Montenegro. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3102) 3103 Realm Specific IP: Protocol Specification. M. Borella, D. Grabelsky, J. Lo, K. Taniguchi. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3103) 3104 RSIP Support for End-to-end IPsec. G. Montenegro, M. Borella. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3104) 3105 Finding an RSIP Server with SLP. J. Kempf, G. Montenegro. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3105) 3106 ECML v1.1: Field Specifications for E-Commerce. D. Eastlake 3rd, T. Goldstein. April 2001. (Format: TXT, HTML) (Obsoletes RFC2706) (Updated by RFC4112) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3106) 3107 Carrying Label Information in BGP-4. Y. Rekhter, E. Rosen. May 2001. (Format: TXT, HTML) (Obsoleted by RFC8277) (Updated by RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3107) 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections. R. Kumar, M. Mostafa. May 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3108) 3109 Request to Move STD 39 to Historic Status. R. Braden, R. Bush, J. Klensin. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3109) 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS). D. Eastlake 3rd. May 2001. (Format: TXT, HTML) (Obsoletes RFC2537) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3110) 3111 Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3111) 3112 LDAP Authentication Password Schema. K. Zeilenga. May 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3112) 3113 3GPP-IETF Standardization Collaboration. K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3113) 3114 Implementing Company Classification Policy with the S/MIME Security Label. W. Nicolls. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3114) 3115 Mobile IP Vendor/Organization-Specific Extensions. G. Dommety, K. Leung. April 2001. (Format: TXT, HTML) (Obsoletes RFC3025) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3115) 3116 Methodology for ATM Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3116) 3117 On the Design of Application Protocols. M. Rose. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3117) 3118 Authentication for DHCP Messages. R. Droms, Ed., W. Arbaugh, Ed.. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3118) 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. June 2001. (Format: TXT, HTML) (Obsoleted by RFC5219) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3119) 3120 A URN Namespace for XML.org. K. Best, N. Walsh. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3120) 3121 A URN Namespace for OASIS. K. Best, N. Walsh. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3121) 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification. A. Conta. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3122) 3123 A DNS RR Type for Lists of Address Prefixes (APL RR). P. Koch. June 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3123) 3124 The Congestion Manager. H. Balakrishnan, S. Seshan. June 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3124) 3125 Electronic Signature Policies. J. Ross, D. Pinkas, N. Pope. September 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3125) 3126 Electronic Signature Formats for long term electronic signatures. D. Pinkas, J. Ross, N. Pope. September 2001. (Format: TXT, HTML) (Obsoleted by RFC5126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3126) 3127 Authentication, Authorization, and Accounting: Protocol Evaluation. D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, B. Wolff. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3127) 3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858). I. Miller. June 2001. (Format: TXT, HTML) (Updates RFC1858) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3128) 3129 Requirements for Kerberized Internet Negotiation of Keys. M. Thomas. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3129) 3130 Notes from the State-Of-The-Technology: DNSSEC. E. Lewis. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3130) 3131 3GPP2-IETF Standardization Collaboration. S. Bradner, P. Calhoun, H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3131) 3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement. J. Kempf. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3132) 3133 Terminology for Frame Relay Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3133) 3134 Terminology for ATM ABR Benchmarking. J. Dunn, C. Martin. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3134) 3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations. J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3135) 3136 The SPIRITS Architecture. L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3136) 3137 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. June 2001. (Format: TXT, HTML) (Obsoleted by RFC6987) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3137) 3138 Extended Assignments in 233/8. D. Meyer. June 2001. (Format: TXT, HTML) (Obsoleted by RFC5771) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3138) 3139 Requirements for Configuration Management of IP-based Networks. L. Sanchez, K. McCloghrie, J. Saperia. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3139) 3140 Per Hop Behavior Identification Codes. D. Black, S. Brim, B. Carpenter, F. Le Faucheur. June 2001. (Format: TXT, HTML) (Obsoletes RFC2836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3140) 3141 CDMA2000 Wireless Data Requirements for AAA. T. Hiller, P. Walsh, X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. Calhoun, C. Lo, E. Jaques, E. Campbell, Y. Xu, S. Baba, T. Ayaki, T. Seki, A. Hameed. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3141) 3142 An IPv6-to-IPv4 Transport Relay Translator. J. Hagino, K. Yamamoto. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3142) 3143 Known HTTP Proxy/Caching Problems. I. Cooper, J. Dilley. June 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3143) 3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring. D. Romascanu. August 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3144) 3145 L2TP Disconnect Cause Information. R. Verma, M. Verma, J. Carlson. July 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3145) 3146 Transmission of IPv6 Packets over IEEE 1394 Networks. K. Fujisawa, A. Onoe. October 2001. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3146) 3147 Generic Routing Encapsulation over CLNS Networks. P. Christian. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3147) 3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics. M. Mathis, M. Allman. July 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3148) 3149 MGCP Business Phone Packages. A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3149) 3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G. Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT, HTML) (Also BCP0048) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3150) 3151 A URN Namespace for Public Identifiers. N. Walsh, J. Cowan, P. Grosso. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3151) 3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT, HTML) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3152) 3153 PPP Multiplexing. R. Pazhyannur, I. Ali, C. Fox. August 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3153) 3154 Requirements and Functional Architecture for an IP Host Alerting Protocol. J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3154) 3155 End-to-end Performance Implications of Links with Errors. S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. August 2001. (Format: TXT, HTML) (Also BCP0050) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3155) 3156 MIME Security with OpenPGP. M. Elkins, D. Del Torto, R. Levien, T. Roessler. August 2001. (Format: TXT, HTML) (Updates RFC2015) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3156) 3157 Securely Available Credentials - Requirements. A. Arsenault, S. Farrell. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3157) 3158 RTP Testing Strategies. C. Perkins, J. Rosenberg, H. Schulzrinne. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3158) 3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3159) 3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. S. Harris. August 2001. (Format: TXT, HTML) (Obsoletes RFC1718) (Obsoleted by RFC4677) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3160) 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001. (Format: TXT, HTML) (Updated by RFC5816) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3161) 3162 RADIUS and IPv6. B. Aboba, G. Zorn, D. Mitton. August 2001. (Format: TXT, HTML) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3162) 3163 ISO/IEC 9798-3 Authentication SASL Mechanism. R. Zuccherato, M. Nystrom. August 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3163) 3164 The BSD Syslog Protocol. C. Lonvick. August 2001. (Format: TXT, HTML) (Obsoleted by RFC5424) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3164) 3165 Definitions of Managed Objects for the Delegation of Management Scripts. D. Levi, J. Schoenwaelder. August 2001. (Format: TXT, HTML) (Obsoletes RFC2592) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3165) 3166 Request to Move RFC 1403 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3166) 3167 Request to Move RFC 1745 to Historic Status. D. Meyer, J. Scudder. August 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3167) 3168 The Addition of Explicit Congestion Notification (ECN) to IP. K. Ramakrishnan, S. Floyd, D. Black. September 2001. (Format: TXT, HTML) (Obsoletes RFC2481) (Updates RFC2003, RFC2474, RFC2401, RFC0793) (Updated by RFC4301, RFC6040, RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3168) 3169 Criteria for Evaluating Network Access Server Protocols. M. Beadles, D. Mitton. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3169) 3170 IP Multicast Applications: Challenges and Solutions. B. Quinn, K. Almeroth. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3170) 3171 IANA Guidelines for IPv4 Multicast Address Assignments. Z. Albanna, K. Almeroth, D. Meyer, M. Schipper. August 2001. (Format: TXT, HTML) (Obsoleted by RFC5771) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3171) 3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). G. Huston, Ed.. September 2001. (Format: TXT, HTML) (Also BCP0052) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3172) 3173 IP Payload Compression Protocol (IPComp). A. Shacham, B. Monsour, R. Pereira, M. Thomas. September 2001. (Format: TXT, HTML) (Obsoletes RFC2393) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3173) 3174 US Secure Hash Algorithm 1 (SHA1). D. Eastlake 3rd, P. Jones. September 2001. (Format: TXT, HTML) (Updated by RFC4634, RFC6234) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3174) 3175 Aggregation of RSVP for IPv4 and IPv6 Reservations. F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. September 2001. (Format: TXT, HTML) (Updated by RFC5350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3175) 3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks. P. Phaal, S. Panchen, N. McKee. September 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3176) 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT, HTML) (Obsoleted by RFC6177) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3177) 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3178) 3179 Script MIB Extensibility Protocol Version 1.1. J. Schoenwaelder, J. Quittek. October 2001. (Format: TXT, HTML) (Obsoletes RFC2593) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3179) 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. (Format: TXT, HTML) (Obsoletes RFC2770) (Also BCP0053) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3180) 3181 Signaled Preemption Priority Policy Element. S. Herzog. October 2001. (Format: TXT, HTML) (Obsoletes RFC2751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3181) 3182 Identity Representation for RSVP. S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, R. Hess. October 2001. (Format: TXT, HTML) (Obsoletes RFC2752) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3182) 3183 Domain Security Services using S/MIME. T. Dean, W. Ottaway. October 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3183) 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT, HTML) (Obsoleted by RFC7154) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3184) 3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner. October 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3185) 3186 MAPOS/PPP Tunneling mode. S. Shimizu, T. Kawano, K. Murakami, E. Beier. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3186) 3187 Using International Standard Book Numbers as Uniform Resource Names. J. Hakala, H. Walravens. October 2001. (Format: TXT, HTML) (Obsoleted by RFC8254) (Status: HISTORIC) (DOI: 10.17487/RFC3187) 3188 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2001. (Format: TXT, HTML) (Obsoleted by RFC8458) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3188) 3189 RTP Payload Format for DV (IEC 61834) Video. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT, HTML) (Obsoleted by RFC6469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3189) 3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio. K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3190) 3191 Minimal GSTN address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT, HTML) (Obsoletes RFC2303) (Updates RFC2846) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3191) 3192 Minimal FAX address format in Internet Mail. C. Allocchio. October 2001. (Format: TXT, HTML) (Obsoletes RFC2304) (Updates RFC2846) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3192) 3193 Securing L2TP using IPsec. B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth. November 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3193) 3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio. A. Durand, C. Huitema. November 2001. (Format: TXT, HTML) (Updates RFC1715) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3194) 3195 Reliable Delivery for syslog. D. New, M. Rose. November 2001. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3195) 3196 Internet Printing Protocol/1.1: Implementor's Guide. T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst. November 2001. (Format: TXT, HTML) (Obsoletes RFC2639) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3196) 3197 Applicability Statement for DNS MIB Extensions. R. Austein. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3197) 3198 Terminology for Policy-Based Management. A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198) 3199 Request for Comments Summary RFC Numbers 3100-3199. S. Ginoza. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3199) 3200 Not Issued. 3201 Definitions of Managed Objects for Circuit to Interface Translation. R. Steinberger, O. Nicklass. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3201) 3202 Definitions of Managed Objects for Frame Relay Service Level Definitions. R. Steinberger, O. Nicklass. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3202) 3203 DHCP reconfigure extension. Y. T'Joens, C. Hublet, P. De Schrijver. December 2001. (Format: TXT, HTML) (Updated by RFC6704) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3203) 3204 MIME media types for ISUP and QSIG Objects. E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. December 2001. (Format: TXT, HTML) (Updated by RFC3459, RFC5621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3204) 3205 On the use of HTTP as a Substrate. K. Moore. February 2002. (Format: TXT, HTML) (Also BCP0056) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3205) 3206 The SYS and AUTH POP Response Codes. R. Gellens. February 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3206) 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security. P. Hoffman. February 2002. (Format: TXT, HTML) (Obsoletes RFC2487) (Updated by RFC7817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3207) 3208 PGM Reliable Transport Protocol Specification. T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano. December 2001. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3208) 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels. D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. December 2001. (Format: TXT, HTML) (Updated by RFC3936, RFC4420, RFC4874, RFC5151, RFC5420, RFC5711, RFC6780, RFC6790, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3209) 3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels. D. Awduche, A. Hannan, X. Xiao. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3210) 3211 Password-based Encryption for CMS. P. Gutmann. December 2001. (Format: TXT, HTML) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3211) 3212 Constraint-Based LSP Setup using LDP. B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis. January 2002. (Format: TXT, HTML) (Updated by RFC3468, RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3212) 3213 Applicability Statement for CR-LDP. J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3213) 3214 LSP Modification Using CR-LDP. J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3214) 3215 LDP State Machine. C. Boscher, P. Cheval, L. Wu, E. Gray. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3215) 3216 SMIng Objectives. C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3216) 3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3217) 3218 Preventing the Million Message Attack on Cryptographic Message Syntax. E. Rescorla. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3218) 3219 Telephony Routing over IP (TRIP). J. Rosenberg, H. Salama, M. Squire. January 2002. (Format: TXT, HTML) (Updated by RFC8602) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3219) 3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT, HTML) (Obsoletes RFC2002) (Obsoleted by RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3220) 3221 Commentary on Inter-Domain Routing in the Internet. G. Huston. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3221) 3222 Terminology for Forwarding Information Base (FIB) based Router Performance. G. Trotter. December 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3222) 3223 Not Issued. 3224 Vendor Extensions for Service Location Protocol, Version 2. E. Guttman. January 2002. (Format: TXT, HTML) (Updates RFC2608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3224) 3225 Indicating Resolver Support of DNSSEC. D. Conrad. December 2001. (Format: TXT, HTML) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3225) 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements. O. Gudmundsson. December 2001. (Format: TXT, HTML) (Updates RFC2535, RFC2874) (Updated by RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3226) 3227 Guidelines for Evidence Collection and Archiving. D. Brezinski, T. Killalea. February 2002. (Format: TXT, HTML) (Also BCP0055) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3227) 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP). B. Fenner. February 2002. (Format: TXT, HTML) (Also BCP0057) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3228) 3229 Delta encoding in HTTP. J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3229) 3230 Instance Digests in HTTP. J. Mogul, A. Van Hoff. January 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3230) 3231 Definitions of Managed Objects for Scheduling Management Operations. D. Levi, J. Schoenwaelder. January 2002. (Format: TXT, HTML) (Obsoletes RFC2591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3231) 3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database. J. Reynolds, Ed.. January 2002. (Format: TXT, HTML) (Obsoletes RFC1700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3232) 3233 Defining the IETF. P. Hoffman, S. Bradner. February 2002. (Format: TXT, HTML) (Also BCP0058) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3233) 3234 Middleboxes: Taxonomy and Issues. B. Carpenter, S. Brim. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3234) 3235 Network Address Translator (NAT)-Friendly Application Design Guidelines. D. Senie. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3235) 3236 The 'application/xhtml+xml' Media Type. M. Baker, P. Stark. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3236) 3237 Requirements for Reliable Server Pooling. M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3237) 3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services. S. Floyd, L. Daigle. January 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3238) 3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations. C. Kugler, H. Lewis, T. Hastings. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3239) 3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration. D. Clunie, E. Cordonnier. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3240) 3241 Robust Header Compression (ROHC) over PPP. C. Bormann. April 2002. (Format: TXT, HTML) (Updates RFC1332) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3241) 3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP. L-E. Jonsson, G. Pelletier. April 2002. (Format: TXT, HTML) (Obsoleted by RFC4362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3242) 3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression. L-E. Jonsson. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3243) 3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols. M. Swift, J. Trostle, J. Brezak. February 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3244) 3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2). J. Klensin, Ed., IAB. March 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3245) 3246 An Expedited Forwarding PHB (Per-Hop Behavior). B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis. March 2002. (Format: TXT, HTML) (Obsoletes RFC2598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3246) 3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3247) 3248 A Delay Bound alternative revision of RFC 2598. G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein. March 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3248) 3249 Implementers Guide for Facsimile Using Internet Mail. V. Cancio, M. Moldovan, H. Tamura, D. Wing. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3249) 3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration. L. McIntyre, G. Parsons, J. Rafferty. September 2002. (Format: TXT, HTML) (Obsoleted by RFC3950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3250) 3251 Electricity over IP. B. Rajagopalan. 1 April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3251) 3252 Binary Lexical Octet Ad-hoc Transport. H. Kennedy. 1 April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3252) 3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning). G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. March 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3253) 3254 Definitions for talking about directories. H. Alvestrand. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3254) 3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads. N. Jones, C. Murton. April 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3255) 3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option. D. Jones, R. Woundy. April 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3256) 3257 Stream Control Transmission Protocol Applicability Statement. L. Coene. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3257) 3258 Distributing Authoritative Name Servers via Shared Unicast Addresses. T. Hardie. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3258) 3259 A Message Bus for Local Coordination. J. Ott, C. Perkins, D. Kutscher. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3259) 3260 New Terminology and Clarifications for Diffserv. D. Grossman. April 2002. (Format: TXT, HTML) (Updates RFC2474, RFC2475, RFC2597) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3260) 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Updated by RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC5621, RFC5626, RFC5630, RFC5922, RFC5954, RFC6026, RFC6141, RFC6665, RFC6878, RFC7462, RFC7463, RFC8217, RFC8591, RFC8760, RFC8898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3261) 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3262) 3263 Session Initiation Protocol (SIP): Locating SIP Servers. J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Updated by RFC7984, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3263) 3264 An Offer/Answer Model with Session Description Protocol (SDP). J. Rosenberg, H. Schulzrinne. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Updated by RFC6157) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3264) 3265 Session Initiation Protocol (SIP)-Specific Event Notification. A. B. Roach. June 2002. (Format: TXT, HTML) (Obsoletes RFC2543) (Obsoleted by RFC6665) (Updates RFC3261) (Updated by RFC5367, RFC5727, RFC6446) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3265) 3266 Support for IPv6 in Session Description Protocol (SDP). S. Olson, G. Camarillo, A. B. Roach. June 2002. (Format: TXT, HTML) (Obsoleted by RFC4566) (Updates RFC2327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3266) 3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. June 2002. (Format: TXT, HTML) (Obsoleted by RFC4867) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3267) 3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS). P. Chown. June 2002. (Format: TXT, HTML) (Obsoleted by RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3268) 3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents. R. Kermode, L. Vicisano. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3269) 3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services. F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. May 2002. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3270) 3271 The Internet is for Everyone. V. Cerf. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3271) 3272 Overview and Principles of Internet Traffic Engineering. D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. May 2002. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3272) 3273 Remote Network Monitoring Management Information Base for High Capacity Networks. S. Waldbusser. July 2002. (Format: TXT, HTML) (Updated by RFC4502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3273) 3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS). P. Gutmann. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3274) 3275 (Extensible Markup Language) XML-Signature Syntax and Processing. D. Eastlake 3rd, J. Reagle, D. Solo. March 2002. (Format: TXT, HTML) (Obsoletes RFC3075) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3275) 3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing. B. Ray, R. Abbi. May 2002. (Format: TXT, HTML) (Obsoleted by RFC4319) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3276) 3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance. D. McPherson. April 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3277) 3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, P. Lambert. April 2002. (Format: TXT, HTML) (Obsoleted by RFC5753) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3278) 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. L. Bassham, W. Polk, R. Housley. April 2002. (Format: TXT, HTML) (Updated by RFC4055, RFC4491, RFC5480, RFC5758, RFC8692) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3279) 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W. Ford, D. Solo. April 2002. (Format: TXT, HTML) (Obsoletes RFC2459) (Obsoleted by RFC5280) (Updated by RFC4325, RFC4630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3280) 3281 An Internet Attribute Certificate Profile for Authorization. S. Farrell, R. Housley. April 2002. (Format: TXT, HTML) (Obsoleted by RFC5755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3281) 3282 Content Language Headers. H. Alvestrand. May 2002. (Format: TXT, HTML) (Obsoletes RFC1766) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3282) 3283 Guide to Internet Calendaring. B. Mahoney, G. Babics, A. Taler. June 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3283) 3284 The VCDIFF Generic Differencing and Compression Data Format. D. Korn, J. MacDonald, J. Mogul, K. Vo. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3284) 3285 Using Microsoft Word to create Internet Drafts and RFCs. M. Gahrns, T. Hain. May 2002. (Format: TXT, HTML) (Obsoleted by RFC5385) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3285) 3286 An Introduction to the Stream Control Transmission Protocol (SCTP). L. Ong, J. Yoakum. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3286) 3287 Remote Monitoring MIB Extensions for Differentiated Services. A. Bierman. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3287) 3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. June 2002. (Format: TXT, HTML) (Obsoleted by RFC4227) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3288) 3289 Management Information Base for the Differentiated Services Architecture. F. Baker, K. Chan, A. Smith. May 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3289) 3290 An Informal Management Model for Diffserv Routers. Y. Bernet, S. Blake, D. Grossman, A. Smith. May 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3290) 3291 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. May 2002. (Format: TXT, HTML) (Obsoletes RFC2851) (Obsoleted by RFC4001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3291) 3292 General Switch Management Protocol (GSMP) V3. A. Doria, F. Hellstrand, K. Sundell, T. Worster. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3292) 3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP). T. Worster, A. Doria, J. Buerkle. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3293) 3294 General Switch Management Protocol (GSMP) Applicability. A. Doria, K. Sundell. June 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3294) 3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP). H. Sjostrand, J. Buerkle, B. Srinivasan. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3295) 3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories. K. Zeilenga. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3296) 3297 Content Negotiation for Messaging Services based on Email. G. Klyne, R. Iwazaki, D. Crocker. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3297) 3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements. I. Faynberg, J. Gato, H. Lu, L. Slutsman. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3298) 3299 Request for Comments Summary RFC Numbers 3200-3299. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3299) 3300 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. November 2002. (Format: TXT, HTML) (Obsoletes RFC3000) (Obsoleted by RFC3600) (Status: HISTORIC) (DOI: 10.17487/RFC3300) 3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions. Y. T'Joens, P. Crivellari, B. Sales. June 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3301) 3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration. G. Parsons, J. Rafferty. September 2002. (Format: TXT, HTML) (Obsoletes RFC2302) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3302) 3303 Middlebox communication architecture and framework. P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3303) 3304 Middlebox Communications (midcom) Protocol Requirements. R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3304) 3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations. M. Mealling, Ed., R. Denenberg, Ed.. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3305) 3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. (Format: TXT, HTML) (Updated by RFC3956, RFC4489, RFC7371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3306) 3307 Allocation Guidelines for IPv6 Multicast Addresses. B. Haberman. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3307) 3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension. P. Calhoun, W. Luo, D. McPherson, K. Peirce. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3308) 3309 Stream Control Transmission Protocol (SCTP) Checksum Change. J. Stone, R. Stewart, D. Otis. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4960) (Updates RFC2960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3309) 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA). A. Niemi, J. Arkko, V. Torvinen. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3310) 3311 The Session Initiation Protocol (SIP) UPDATE Method. J. Rosenberg. October 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3311) 3312 Integration of Resource Management and Session Initiation Protocol (SIP). G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. October 2002. (Format: TXT, PS, PDF, HTML) (Updated by RFC4032, RFC5027) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3312) 3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization. W. Marshall, Ed.. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3313) 3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards. M. Wasserman, Ed.. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3314) 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updated by RFC4361, RFC5494, RFC6221, RFC6422, RFC6644, RFC7083, RFC7227, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3315) 3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts. J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. April 2003. (Format: TXT, HTML) (Obsoleted by RFC7066) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3316) 3317 Differentiated Services Quality of Service Policy Information Base. K. Chan, R. Sahita, S. Hahn, K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3317) 3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan, K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3318) 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers. H. Schulzrinne, B. Volz. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3319) 3320 Signaling Compression (SigComp). R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. January 2003. (Format: TXT, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3320) 3321 Signaling Compression (SigComp) - Extended Operations. H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. January 2003. (Format: TXT, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3321) 3322 Signaling Compression (SigComp) Requirements & Assumptions. H. Hannu. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3322) 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP). J. Peterson. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3323) 3324 Short Term Requirements for Network Asserted Identity. M. Watson. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3324) 3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks. C. Jennings, J. Peterson, M. Watson. November 2002. (Format: TXT, HTML) (Updated by RFC5876, RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3325) 3326 The Reason Header Field for the Session Initiation Protocol (SIP). H. Schulzrinne, D. Oran, G. Camarillo. December 2002. (Format: TXT, HTML) (Updated by RFC8606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3326) 3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts. D. Willis, B. Hoeneisen. December 2002. (Format: TXT, HTML) (Updated by RFC5626) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3327) 3328 Not Issued. 3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP). J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. January 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3329) 3330 Special-Use IPv4 Addresses. IANA. September 2002. (Format: TXT, HTML) (Obsoleted by RFC5735) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3330) 3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer. K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz. September 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3331) 3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4666) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3332) 3333 Not Issued. 3334 Policy-Based Accounting. T. Zseby, S. Zander, C. Carle. October 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3334) 3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet. T. Harding, R. Drummond, C. Shih. September 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3335) 3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2). B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3336) 3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2. B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3337) 3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA). S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. October 2002. (Format: TXT, HTML) (Obsoleted by RFC6535) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3338) 3339 Date and Time on the Internet: Timestamps. G. Klyne, C. Newman. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3339) 3340 The Application Exchange Core. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3340) 3341 The Application Exchange (APEX) Access Service. M. Rose, G. Klyne, D. Crocker. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3341) 3342 The Application Exchange (APEX) Option Party Pack, Part Deux!. E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz. July 2002. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3342) 3343 The Application Exchange (APEX) Presence Service. M. Rose, G. Klyne, D. Crocker. April 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3343) 3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT, HTML) (Obsoletes RFC3220) (Obsoleted by RFC5944) (Updated by RFC4636, RFC4721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3344) 3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition. D. McPherson, V. Gill, D. Walton, A. Retana. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3345) 3346 Applicability Statement for Traffic Engineering with MPLS. J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3346) 3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations. M. Krueger, R. Haagens. July 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3347) 3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension. M. Gahrns, R. Cheng. July 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3348) 3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force. M. Rose. July 2002. (Format: TXT, HTML) (Also BCP0059) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3349) 3350 Not Issued. 3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals. N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3351) 3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status. K. Zeilenga. March 2003. (Format: TXT, HTML) (Obsoletes RFC1798) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3352) 3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment. D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3353) 3354 Internet Open Trading Protocol Version 2 Requirements. D. Eastlake 3rd. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3354) 3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5). A. Singh, R. Turner, R. Tio, S. Nanji. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3355) 3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines. G. Fishman, S. Bradner. August 2002. (Format: TXT, HTML) (Obsoletes RFC2436) (Obsoleted by RFC6756) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3356) 3357 One-way Loss Pattern Sample Metrics. R. Koodli, R. Ravikanth. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3357) 3358 Optional Checksums in Intermediate System to Intermediate System (ISIS). T. Przygienda. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3358) 3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System. T. Przygienda. August 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3359) 3360 Inappropriate TCP Resets Considered Harmful. S. Floyd. August 2002. (Format: TXT, HTML) (Also BCP0060) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3360) 3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers. H. Schulzrinne. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3361) 3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration. G. Parsons. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3362) 3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002. (Format: TXT, HTML) (Updates RFC2673, RFC2874) (Updated by RFC6672) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3363) 3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein. August 2002. (Format: TXT, HTML) (Updates RFC2673, RFC2874) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3364) 3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols. J. Schiller. August 2002. (Format: TXT, HTML) (Also BCP0061) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3365) 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ). G. Fairhurst, L. Wood. August 2002. (Format: TXT, HTML) (Also BCP0062) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3366) 3367 Common Name Resolution Protocol (CNRP). N. Popp, M. Mealling, M. Moseley. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3367) 3368 The 'go' URI Scheme for the Common Name Resolution Protocol. M. Mealling. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3368) 3369 Cryptographic Message Syntax (CMS). R. Housley. August 2002. (Format: TXT, HTML) (Obsoletes RFC2630, RFC3211) (Obsoleted by RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3369) 3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August 2002. (Format: TXT, HTML) (Obsoletes RFC2630, RFC3211) (Updated by RFC5754, RFC8702) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3370) 3371 Layer Two Tunneling Protocol "L2TP" Management Information Base. E. Caves, P. Calhoun, R. Wheeler. August 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3371) 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures. A. Vemuri, J. Peterson. September 2002. (Format: TXT, HTML) (Also BCP0063) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3372) 3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies. D. Katz, R. Saluja. September 2002. (Format: TXT, HTML) (Obsoleted by RFC5303) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3373) 3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network. J. Kempf, Ed.. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3374) 3375 Generic Registry-Registrar Protocol Requirements. S. Hollenbeck. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3375) 3376 Internet Group Management Protocol, Version 3. B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. October 2002. (Format: TXT, HTML) (Updates RFC2236) (Updated by RFC4604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3376) 3377 Lightweight Directory Access Protocol (v3): Technical Specification. J. Hodges, R. Morgan. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4510) (Updates RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3377) 3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams. R. Housley, S. Hollenbeck. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3378) 3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements. D. Pinkas, R. Housley. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3379) 3380 Internet Printing Protocol (IPP): Job and Printer Set Operations. T. Hastings, R. Herriot, C. Kugler, H. Lewis. September 2002. (Format: TXT, HTML) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3380) 3381 Internet Printing Protocol (IPP): Job Progress Attributes. T. Hastings, H. Lewis, R. Bergman. September 2002. (Format: TXT, HTML) (Obsoleted by RFC8011) (Updates RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3381) 3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax. R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler. September 2002. (Format: TXT, HTML) (Obsoleted by RFC8010, RFC8011) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3382) 3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. September 2002. (Format: TXT, HTML) (Obsoleted by RFC4520) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3383) 3384 Lightweight Directory Access Protocol (version 3) Replication Requirements. E. Stokes, R. Weiser, R. Moats, R. Huber. October 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3384) 3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations. D. Sheinwald, J. Satran, P. Thaler, V. Cavanna. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3385) 3386 Network Hierarchy and Multilayer Survivability. W. Lai, Ed., D. McDysan, Ed.. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3386) 3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network. M. Eder, H. Chaskar, S. Nag. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3387) 3388 Grouping of Media Lines in the Session Description Protocol (SDP). G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5888) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3388) 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN). R. Zopf. September 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3389) 3390 Increasing TCP's Initial Window. M. Allman, S. Floyd, C. Partridge. October 2002. (Format: TXT, HTML) (Obsoletes RFC2414) (Updates RFC2581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3390) 3391 The MIME Application/Vnd.pwg-multiplexed Content-Type. R. Herriot. December 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3391) 3392 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. November 2002. (Format: TXT, HTML) (Obsoletes RFC2842) (Obsoleted by RFC5492) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3392) 3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). C. Demichelis, P. Chimento. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3393) 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad, R. Housley. September 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3394) 3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions. A. Bierman, C. Bucci, R. Dietz, A. Warth. September 2002. (Format: TXT, HTML) (Updates RFC2895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3395) 3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4). T. Lemon, S. Cheshire. November 2002. (Format: TXT, HTML) (Updates RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3396) 3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option. B. Aboba, S. Cheshire. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3397) 3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping. G. Camarillo, A. B. Roach, J. Peterson, L. Ong. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3398) 3399 Not Issued. 3400 Not Issued. 3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS. M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Updates RFC2276) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3401) 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm. M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3402) 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database. M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3403) 3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI). M. Mealling. October 2002. (Format: TXT, HTML) (Obsoletes RFC2915, RFC2168) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3404) 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures. M. Mealling. October 2002. (Format: TXT, HTML) (Also BCP0065) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3405) 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. October 2002. (Format: TXT, HTML) (Obsoletes RFC2611) (Obsoleted by RFC8141) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3406) 3407 Session Description Protocol (SDP) Simple Capability Declaration. F. Andreasen. October 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3407) 3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile. Z. Liu, K. Le. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3408) 3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression. K. Svanbro. December 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3409) 3410 Introduction and Applicability Statements for Internet-Standard Management Framework. J. Case, R. Mundy, D. Partain, B. Stewart. December 2002. (Format: TXT, HTML) (Obsoletes RFC2570) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3410) 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT, HTML) (Obsoletes RFC2571) (Updated by RFC5343, RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3411) 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). J. Case, D. Harrington, R. Presuhn, B. Wijnen. December 2002. (Format: TXT, HTML) (Obsoletes RFC2572) (Updated by RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3412) 3413 Simple Network Management Protocol (SNMP) Applications. D. Levi, P. Meyer, B. Stewart. December 2002. (Format: TXT, HTML) (Obsoletes RFC2573) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3413) 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). U. Blumenthal, B. Wijnen. December 2002. (Format: TXT, HTML) (Obsoletes RFC2574) (Updated by RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3414) 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). B. Wijnen, R. Presuhn, K. McCloghrie. December 2002. (Format: TXT, HTML) (Obsoletes RFC2575) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3415) 3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT, HTML) (Obsoletes RFC1905) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3416) 3417 Transport Mappings for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT, HTML) (Obsoletes RFC1906) (Updated by RFC4789, RFC5590) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3417) 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). R. Presuhn, Ed.. December 2002. (Format: TXT, HTML) (Obsoletes RFC1907) (Also STD0062) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3418) 3419 Textual Conventions for Transport Addresses. M. Daniele, J. Schoenwaelder. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3419) 3420 Internet Media Type message/sipfrag. R. Sparks. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3420) 3421 Select and Sort Extensions for the Service Location Protocol (SLP). W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. November 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3421) 3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS). O. Okamoto, M. Maruyama, T. Sajima. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3422) 3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0. K. Zhang, E. Elkin. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3423) 3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation. L. Daigle, Ed., IAB. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3424) 3425 Obsoleting IQUERY. D. Lawrence. November 2002. (Format: TXT, HTML) (Updates RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3425) 3426 General Architectural and Policy Considerations. S. Floyd. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3426) 3427 Change Process for the Session Initiation Protocol (SIP). A. Mankin, S. Bradner, R. Mahy, D. Willis, J. Ott, B. Rosen. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5727) (Updated by RFC3968, RFC3969) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3427) 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. December 2002. (Format: TXT, HTML) (Updated by RFC8591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3428) 3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions. H. Ohta. November 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3429) 3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping. J. Schoenwaelder. December 2002. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3430) 3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3431) 3432 Network performance measurement with periodic streams. V. Raisanen, G. Grotefeld, A. Morton. November 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3432) 3433 Entity Sensor Management Information Base. A. Bierman, D. Romascanu, K.C. Norseth. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3433) 3434 Remote Monitoring MIB Extensions for High Capacity Alarms. A. Bierman, K. McCloghrie. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3434) 3435 Media Gateway Control Protocol (MGCP) Version 1.0. F. Andreasen, B. Foster. January 2003. (Format: TXT, HTML) (Obsoletes RFC2705) (Updated by RFC3661) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3435) 3436 Transport Layer Security over Stream Control Transmission Protocol. A. Jungmaier, E. Rescorla, M. Tuexen. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3436) 3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation. W. Palter, W. Townsley. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3437) 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update. W. Townsley. December 2002. (Format: TXT, HTML) (Also BCP0068) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3438) 3439 Some Internet Architectural Guidelines and Philosophy. R. Bush, D. Meyer. December 2002. (Format: TXT, HTML) (Updates RFC1958) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3439) 3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines. F. Ly, G. Bathrick. December 2002. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3440) 3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP). R. Kumar. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3441) 3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4. T. Lemon, S. Cheshire, B. Volz. December 2002. (Format: TXT, HTML) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3442) 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks. P. Agarwal, B. Akyol. January 2003. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3443) 3444 On the Difference between Information Models and Data Models. A. Pras, J. Schoenwaelder. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3444) 3445 Limiting the Scope of the KEY Resource Record (RR). D. Massey, S. Rose. December 2002. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3445) 3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP). D. Kim, D. Meyer, H. Kilmer, D. Farinacci. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3446) 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. J. Jonsson, B. Kaliski. February 2003. (Format: TXT, HTML) (Obsoletes RFC2437) (Obsoleted by RFC8017) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3447) 3448 TCP Friendly Rate Control (TFRC): Protocol Specification. M. Handley, S. Floyd, J. Padhye, J. Widmer. January 2003. (Format: TXT, HTML) (Obsoleted by RFC5348) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3448) 3449 TCP Performance Implications of Network Path Asymmetry. H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002. (Format: TXT, HTML) (Also BCP0069) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3449) 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation. M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5775) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3450) 3451 Layered Coding Transport (LCT) Building Block. M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5651) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3451) 3452 Forward Error Correction (FEC) Building Block. M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT, HTML) (Obsoleted by RFC5052, RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3452) 3453 The Use of Forward Error Correction (FEC) in Reliable Multicast. M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3453) 3454 Preparation of Internationalized Strings ("stringprep"). P. Hoffman, M. Blanchet. December 2002. (Format: TXT, HTML) (Obsoleted by RFC7564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3454) 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP). M. Garcia-Martin, E. Henrikson, D. Mills. January 2003. (Format: TXT, HTML) (Obsoleted by RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3455) 3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode. B. Patel, B. Aboba, S. Kelly, V. Gupta. January 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3456) 3457 Requirements for IPsec Remote Access Scenarios. S. Kelly, S. Ramamoorthi. January 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3457) 3458 Message Context for Internet Mail. E. Burger, E. Candell, C. Eliot, G. Klyne. January 2003. (Format: TXT, HTML) (Updated by RFC3938) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3458) 3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter. E. Burger. January 2003. (Format: TXT, HTML) (Updates RFC3204) (Updated by RFC5621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3459) 3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed.. January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3460) 3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). K. Moore. January 2003. (Format: TXT, HTML) (Obsoletes RFC1891) (Updated by RFC3798, RFC3885, RFC5337, RFC6533, RFC8098) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3461) 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. G. Vaudreuil. January 2003. (Format: TXT, HTML) (Obsoletes RFC1892) (Obsoleted by RFC6522) (Updated by RFC5337) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3462) 3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003. (Format: TXT, HTML) (Obsoletes RFC1893) (Updated by RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3463) 3464 An Extensible Message Format for Delivery Status Notifications. K. Moore, G. Vaudreuil. January 2003. (Format: TXT, HTML) (Obsoletes RFC1894) (Updated by RFC4865, RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3464) 3465 TCP Congestion Control with Appropriate Byte Counting (ABC). M. Allman. February 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3465) 3466 A Model for Content Internetworking (CDI). M. Day, B. Cain, G. Tomlinson, P. Rzewski. February 2003. (Format: TXT, HTML) (Obsoleted by RFC7336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3466) 3467 Role of the Domain Name System (DNS). J. Klensin. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3467) 3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols. L. Andersson, G. Swallow. February 2003. (Format: TXT, HTML) (Updates RFC3212, RFC3472, RFC3475, RFC3476) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3468) 3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery. V. Sharma, Ed., F. Hellstrand, Ed.. February 2003. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3469) 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols. S. Hollenbeck, M. Rose, L. Masinter. January 2003. (Format: TXT, HTML) (Also BCP0070) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3470) 3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description. L. Berger, Ed.. January 2003. (Format: TXT, HTML) (Updated by RFC4201, RFC4328, RFC4872, RFC6002, RFC6003, RFC6205, RFC7074, RFC7699, RFC8359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3471) 3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions. P. Ashwood-Smith, Ed., L. Berger, Ed.. January 2003. (Format: TXT, HTML) (Updated by RFC3468, RFC4201) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3472) 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions. L. Berger, Ed.. January 2003. (Format: TXT, HTML) (Updated by RFC4003, RFC4201, RFC4420, RFC4783, RFC4874, RFC4873, RFC4974, RFC5063, RFC5151, RFC5420, RFC6002, RFC6003, RFC6780, RFC8359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3473) 3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON). Z. Lin, D. Pendarakis. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3474) 3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON). O. Aboul-Magd. March 2003. (Format: TXT, HTML) (Updated by RFC3468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3475) 3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling. B. Rajagopalan. March 2003. (Format: TXT, HTML) (Updated by RFC3468) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3476) 3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE). K. Kompella, Y. Rekhter. January 2003. (Format: TXT, HTML) (Updated by RFC6107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3477) 3478 Graceful Restart Mechanism for Label Distribution Protocol. M. Leelanivas, Y. Rekhter, R. Aggarwal. February 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3478) 3479 Fault Tolerance for the Label Distribution Protocol (LDP). A. Farrel, Ed.. February 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3479) 3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol). K. Kompella, Y. Rekhter, A. Kullberg. February 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3480) 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks. H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. February 2003. (Format: TXT, HTML) (Also BCP0071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3481) 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview. M. Foster, T. McGarry, J. Yu. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3482) 3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR). D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3483) 3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT, HTML) (Obsoleted by RFC6724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3484) 3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp). M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach. February 2003. (Format: TXT, HTML) (Updated by RFC4896) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3485) 3486 Compressing the Session Initiation Protocol (SIP). G. Camarillo. February 2003. (Format: TXT, HTML) (Updated by RFC5049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3486) 3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP). H. Schulzrinne. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3487) 3488 Cisco Systems Router-port Group Management Protocol (RGMP). I. Wu, T. Eckert. February 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3488) 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. March 2003. (Format: TXT, HTML) (Obsoleted by RFC5389) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3489) 3490 Internationalizing Domain Names in Applications (IDNA). P. Faltstrom, P. Hoffman, A. Costello. March 2003. (Format: TXT, HTML) (Obsoleted by RFC5890, RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3490) 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN). P. Hoffman, M. Blanchet. March 2003. (Format: TXT, HTML) (Obsoleted by RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3491) 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. (Format: TXT, HTML) (Updated by RFC5891) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3492) 3493 Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. February 2003. (Format: TXT, HTML) (Obsoletes RFC2553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3493) 3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status. K. Zeilenga. March 2003. (Format: TXT, HTML) (Obsoletes RFC1484, RFC1485, RFC1487, RFC1777, RFC1778, RFC1779, RFC1781, RFC2559) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3494) 3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration. B. Beser, P. Duffy, Ed.. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3495) 3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. A. G. Malis, T. Hsiao. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3496) 3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video. L. Gharai, C. Perkins, G. Goncher, A. Mankin. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3497) 3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures. J. Kuhfeld, J. Johnson, M. Thatcher. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3498) 3499 Request for Comments Summary RFC Numbers 3400-3499. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3499) 3500 Not Issued. 3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. M. Crispin. March 2003. (Format: TXT, HTML) (Obsoletes RFC2060) (Updated by RFC4466, RFC4469, RFC4551, RFC5032, RFC5182, RFC5738, RFC6186, RFC6858, RFC7817, RFC8314, RFC8437, RFC8474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3501) 3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension. M. Crispin. March 2003. (Format: TXT, HTML) (Updated by RFC4466, RFC4469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3502) 3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP). A. Melnikov. March 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3503) 3504 Internet Open Trading Protocol (IOTP) Version 1, Errata. D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3504) 3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements. D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3505) 3506 Requirements and Design for Voucher Trading System (VTS). K. Fujimura, D. Eastlake. March 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3506) 3507 Internet Content Adaptation Protocol (ICAP). J. Elson, A. Cerpa. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3507) 3508 H.323 Uniform Resource Locator (URL) Scheme Registration. O. Levin. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3508) 3509 Alternative Implementations of OSPF Area Border Routers. A. Zinin, A. Lindem, D. Yeung. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3509) 3510 Internet Printing Protocol/1.1: IPP URL Scheme. R. Herriot, I. McDonald. April 2003. (Format: TXT, HTML) (Updates RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3510) 3511 Benchmarking Methodology for Firewall Performance. B. Hickman, D. Newman, S. Tadjudin, T. Martin. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3511) 3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP). M. MacFaden, D. Partain, J. Saperia, W. Tackabury. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3512) 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. (Format: TXT, HTML) (Obsoletes RFC2373) (Obsoleted by RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3513) 3514 The Security Flag in the IPv4 Header. S. Bellovin. 1 April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3514) 3515 The Session Initiation Protocol (SIP) Refer Method. R. Sparks. April 2003. (Format: TXT, HTML) (Updated by RFC7647, RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3515) 3516 IMAP4 Binary Content Extension. L. Nerenberg. April 2003. (Format: TXT, HTML) (Updated by RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3516) 3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP. E. Blanton, M. Allman, K. Fall, L. Wang. April 2003. (Format: TXT, HTML) (Obsoleted by RFC6675) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3517) 3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP). M. Higashiyama, F. Baker, T. Liao. April 2003. (Format: TXT, HTML) (Obsoletes RFC2878) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3518) 3519 Mobile IP Traversal of Network Address Translation (NAT) Devices. H. Levkowetz, S. Vaarala. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3519) 3520 Session Authorization Policy Element. L-N. Hamer, B. Gage, B. Kosinski, H. Shieh. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3520) 3521 Framework for Session Set-up with Media Authorization. L-N. Hamer, B. Gage, H. Shieh. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3521) 3522 The Eifel Detection Algorithm for TCP. R. Ludwig, M. Meyer. April 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3522) 3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology. J. Polk. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3523) 3524 Mapping of Media Streams to Resource Reservation Flows. G. Camarillo, A. Monrad. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3524) 3525 Gateway Control Protocol Version 1. C. Groves, Ed., M. Pantaleo, Ed., T. Anderson, Ed., T. Taylor, Ed.. June 2003. (Format: TXT, HTML) (Obsoletes RFC3015) (Obsoleted by RFC5125) (Status: HISTORIC) (DOI: 10.17487/RFC3525) 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). T. Kivinen, M. Kojo. May 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3526) 3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4. K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy. April 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3527) 3528 Mesh-enhanced Service Location Protocol (mSLP). W. Zhao, H. Schulzrinne, E. Guttman. April 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3528) 3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP). W. Harold. April 2003. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3529) 3530 Network File System (NFS) version 4 Protocol. S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. April 2003. (Format: TXT, HTML) (Obsoletes RFC3010) (Obsoleted by RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3530) 3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block. M. Blanchet. April 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3531) 3532 Requirements for the Dynamic Partitioning of Switching Elements. T. Anderson, J. Buerkle. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3532) 3533 The Ogg Encapsulation Format Version 0. S. Pfeiffer. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3533) 3534 The application/ogg Media Type. L. Walleij. May 2003. (Format: TXT, HTML) (Obsoleted by RFC5334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3534) 3535 Overview of the 2002 IAB Network Management Workshop. J. Schoenwaelder. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3535) 3536 Terminology Used in Internationalization in the IETF. P. Hoffman. May 2003. (Format: TXT, HTML) (Obsoleted by RFC6365) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3536) 3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key. J. Schaad, R. Housley. May 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3537) 3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP). Y. Kawatsura. June 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3538) 3539 Authentication, Authorization and Accounting (AAA) Transport Profile. B. Aboba, J. Wood. June 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3539) 3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces. N. Spring, D. Wetherall, D. Ely. June 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3540) 3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D). A. Walsh. May 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3541) 3542 Advanced Sockets Application Program Interface (API) for IPv6. W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. May 2003. (Format: TXT, HTML) (Obsoletes RFC2292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3542) 3543 Registration Revocation in Mobile IPv4. S. Glass, M. Chandra. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3543) 3544 IP Header Compression over PPP. T. Koren, S. Casner, C. Bormann. July 2003. (Format: TXT, HTML) (Obsoletes RFC2509) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3544) 3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering. T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3545) 3546 Transport Layer Security (TLS) Extensions. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. June 2003. (Format: TXT, HTML) (Obsoleted by RFC4366) (Updates RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3546) 3547 The Group Domain of Interpretation. M. Baugher, B. Weis, T. Hardjono, H. Harney. July 2003. (Format: TXT, HTML) (Obsoleted by RFC6407) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3547) 3548 The Base16, Base32, and Base64 Data Encodings. S. Josefsson, Ed.. July 2003. (Format: TXT, HTML) (Obsoleted by RFC4648) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3548) 3549 Linux Netlink as an IP Services Protocol. J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3549) 3550 RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 2003. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1889) (Updated by RFC5506, RFC5761, RFC6051, RFC6222, RFC7022, RFC7160, RFC7164, RFC8083, RFC8108) (Also STD0064) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3550) 3551 RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne, S. Casner. July 2003. (Format: TXT, PS, PDF, HTML) (Obsoletes RFC1890) (Updated by RFC5761, RFC7007) (Also STD0065) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3551) 3552 Guidelines for Writing RFC Text on Security Considerations. E. Rescorla, B. Korver. July 2003. (Format: TXT, HTML) (Also BCP0072) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3552) 3553 An IETF URN Sub-namespace for Registered Protocol Parameters. M. Mealling, L. Masinter, T. Hardie, G. Klyne. June 2003. (Format: TXT, HTML) (Also BCP0073) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3553) 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec. S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3554) 3555 MIME Type Registration of RTP Payload Formats. S. Casner, P. Hoschka. July 2003. (Format: TXT, HTML) (Obsoleted by RFC4855, RFC4856) (Updated by RFC3625, RFC4629) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3555) 3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth. S. Casner. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3556) 3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding. Q. Xie, Ed.. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3557) 3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV). A. Li. July 2003. (Format: TXT, HTML) (Updated by RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3558) 3559 Multicast Address Allocation MIB. D. Thaler. June 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3559) 3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS). R. Housley. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3560) 3561 Ad hoc On-Demand Distance Vector (AODV) Routing. C. Perkins, E. Belding-Royer, S. Das. July 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3561) 3562 Key Management Considerations for the TCP MD5 Signature Option. M. Leech. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3562) 3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development. A. Zinin. July 2003. (Format: TXT, HTML) (Updated by RFC6233) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3563) 3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. July 2003. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3564) 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3565) 3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec. S. Frankel, H. Herbert. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3566) 3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication. T. Li, R. Atkinson. July 2003. (Format: TXT, HTML) (Obsoleted by RFC5304) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3567) 3568 Known Content Network (CN) Request-Routing Mechanisms. A. Barbir, B. Cain, R. Nair, O. Spatscheck. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3568) 3569 An Overview of Source-Specific Multicast (SSM). S. Bhattacharyya, Ed.. July 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3569) 3570 Content Internetworking (CDI) Scenarios. P. Rzewski, M. Day, D. Gilletti. July 2003. (Format: TXT, HTML) (Obsoleted by RFC6770) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3570) 3571 Framework Policy Information Base for Usage Feedback. D. Rawlins, A. Kulkarni, K. Ho Chan, M. Bokaemper, D. Dutt. August 2003. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3571) 3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH). T. Ogura, M. Maruyama, T. Yoshida. July 2003. (Format: TXT, HTML) (Updated by RFC8064) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3572) 3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP). I. Goyret. July 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3573) 3574 Transition Scenarios for 3GPP Networks. J. Soininen, Ed.. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3574) 3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service). B. Aboba. July 2003. (Format: TXT, HTML) (Updates RFC2865, RFC2868) (Updated by RFC6929) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3575) 3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. July 2003. (Format: TXT, HTML) (Obsoleted by RFC5176) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3576) 3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules. S. Waldbusser, R. Cole, C. Kalbfleisch, D. Romascanu. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3577) 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP). G. Camarillo, A. B. Roach, J. Peterson, L. Ong. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3578) 3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP). B. Aboba, P. Calhoun. September 2003. (Format: TXT, HTML) (Updates RFC2869) (Updated by RFC5080) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3579) 3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines. P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. September 2003. (Format: TXT, HTML) (Updated by RFC7268) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3580) 3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing. J. Rosenberg, H. Schulzrinne. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3581) 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3582) 3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP. H. Chaskar, Ed.. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3583) 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. August 2003. (Format: TXT, HTML) (Obsoletes RFC2576) (Also BCP0074) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3584) 3585 IPsec Configuration Policy Information Model. J. Jason, L. Rafalow, E. Vyncke. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3585) 3586 IP Security Policy (IPSP) Requirements. M. Blaze, A. Keromytis, M. Richardson, L. Sanchez. August 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3586) 3587 IPv6 Global Unicast Address Format. R. Hinden, S. Deering, E. Nordmark. August 2003. (Format: TXT, HTML) (Obsoletes RFC2374) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3587) 3588 Diameter Base Protocol. P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko. September 2003. (Format: TXT, HTML) (Obsoleted by RFC6733) (Updated by RFC5729, RFC5719, RFC6408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3588) 3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. J. Loughney. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3589) 3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol. B. Haberman. September 2003. (Format: TXT, HTML) (Updates RFC2710) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3590) 3591 Definitions of Managed Objects for the Optical Interface Type. H-K. Lam, M. Stewart, A. Huynh. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3591) 3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type. K. Tesink. September 2003. (Format: TXT, HTML) (Obsoletes RFC2558) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3592) 3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. K. Tesink, Ed.. September 2003. (Format: TXT, HTML) (Obsoletes RFC2493) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3593) 3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option. P. Duffy. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3594) 3595 Textual Conventions for IPv6 Flow Label. B. Wijnen. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3595) 3596 DNS Extensions to Support IP Version 6. S. Thomson, C. Huitema, V. Ksinant, M. Souissi. October 2003. (Format: TXT, HTML) (Obsoletes RFC3152, RFC1886) (Also STD0088) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3596) 3597 Handling of Unknown DNS Resource Record (RR) Types. A. Gustafsson. September 2003. (Format: TXT, HTML) (Updates RFC2163, RFC2535) (Updated by RFC4033, RFC4034, RFC4035, RFC5395, RFC6195, RFC6895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3597) 3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison. September 2003. (Format: TXT, HTML) (Obsoleted by RFC5233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3598) 3599 Request for Comments Summary RFC Numbers 3500-3599. S. Ginoza. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3599) 3600 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. November 2003. (Format: TXT, HTML) (Obsoletes RFC3300) (Obsoleted by RFC3700) (Status: HISTORIC) (DOI: 10.17487/RFC3600) 3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses. C. Allocchio. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3601) 3602 The AES-CBC Cipher Algorithm and Its Use with IPsec. S. Frankel, R. Glenn, S. Kelly. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3602) 3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. W. Marshall, Ed., F. Andreasen, Ed.. October 2003. (Format: TXT, HTML) (Obsoleted by RFC5503) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3603) 3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3). H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3604) 3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). C. Huitema. October 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3605) 3606 Definitions of Supplemental Managed Objects for ATM Interface. F. Ly, M. Noto, A. Smith, E. Spiegel, K. Tesink. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3606) 3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool. M. Leech. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3607) 3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration. D. Willis, B. Hoeneisen. October 2003. (Format: TXT, HTML) (Updated by RFC5630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3608) 3609 Tracing Requirements for Generic Tunnels. R. Bonica, K. Kompella, D. Meyer. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3609) 3610 Counter with CBC-MAC (CCM). D. Whiting, R. Housley, N. Ferguson. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3610) 3611 RTP Control Protocol Extended Reports (RTCP XR). T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed.. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3611) 3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP). A. Farrel. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3612) 3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE). R. Morgan, K. Hazelton. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3613) 3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG). J. Smith. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3614) 3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging. J. Gustin, A. Goyens. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3615) 3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA). F. Bellifemine, I. Constantinescu, S. Willmott. September 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3616) 3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP). E. Lear. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3617) 3618 Multicast Source Discovery Protocol (MSDP). B. Fenner, Ed., D. Meyer, Ed.. October 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3618) 3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1. S. Shah, M. Yip. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3619) 3620 The TUNNEL Profile. D. New. October 2003. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3620) 3621 Power Ethernet MIB. A. Berger, D. Romascanu. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3621) 3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project. M. Mealling. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3622) 3623 Graceful OSPF Restart. J. Moy, P. Pillay-Esnault, A. Lindem. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3623) 3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package. B. Foster, D. Auerbach, F. Andreasen. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3624) 3625 The QCP File Format and Media Types for Speech Data. R. Gellens, H. Garudadri. September 2003. (Format: TXT, HTML) (Updates RFC3555) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3625) 3626 Optimized Link State Routing Protocol (OLSR). T. Clausen, Ed., P. Jacquet, Ed.. October 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3626) 3627 Use of /127 Prefix Length Between Routers Considered Harmful. P. Savola. September 2003. (Format: TXT, HTML) (Obsoleted by RFC6547) (Status: HISTORIC) (DOI: 10.17487/RFC3627) 3628 Policy Requirements for Time-Stamping Authorities (TSAs). D. Pinkas, N. Pope, J. Ross. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3628) 3629 UTF-8, a transformation format of ISO 10646. F. Yergeau. November 2003. (Format: TXT, HTML) (Obsoletes RFC2279) (Also STD0063) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3629) 3630 Traffic Engineering (TE) Extensions to OSPF Version 2. D. Katz, K. Kompella, D. Yeung. September 2003. (Format: TXT, HTML) (Updates RFC2370) (Updated by RFC4203, RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3630) 3631 Security Mechanisms for the Internet. S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed.. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3631) 3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0. S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli. November 2003. (Format: TXT, HTML) (Updates RFC2832) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3632) 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. O. Troan, R. Droms. December 2003. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updated by RFC6603, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3633) 3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option. K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3634) 3635 Definitions of Managed Objects for the Ethernet-like Interface Types. J. Flick. September 2003. (Format: TXT, HTML) (Obsoletes RFC2665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3635) 3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). J. Flick. September 2003. (Format: TXT, HTML) (Obsoletes RFC2668, RFC1515) (Obsoleted by RFC4836) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3636) 3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer. C.M. Heard, Ed.. September 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3637) 3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status. J. Flick, C. M. Heard. September 2003. (Format: TXT, HTML) (Obsoletes RFC1643) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3638) 3639 Considerations on the use of a Service Identifier in Packet Headers. M. St. Johns, Ed., G. Huston, Ed., IAB. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3639) 3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams. J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric. November 2003. (Format: TXT, HTML) (Updated by RFC5691) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3640) 3641 Generic String Encoding Rules (GSER) for ASN.1 Types. S. Legg. October 2003. (Format: TXT, HTML) (Updated by RFC4792) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3641) 3642 Common Elements of Generic String Encoding Rules (GSER) Encodings. S. Legg. October 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3642) 3643 Fibre Channel (FC) Frame Encapsulation. R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3643) 3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644) 3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG). S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall. October 2003. (Format: TXT, HTML) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3645) 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed.. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3646) 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. November 2003. (Format: TXT, HTML) (Obsoletes RFC2527) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3647) 3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol. J. Whitehead, J. Reschke, Ed.. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3648) 3649 HighSpeed TCP for Large Congestion Windows. S. Floyd. December 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3649) 3650 Handle System Overview. S. Sun, L. Lannom, B. Boesch. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3650) 3651 Handle System Namespace and Service Definition. S. Sun, S. Reilly, L. Lannom. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3651) 3652 Handle System Protocol (ver 2.1) Specification. S. Sun, S. Reilly, L. Lannom, J. Petrone. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3652) 3653 XML-Signature XPath Filter 2.0. J. Boyer, M. Hughes, J. Reagle. December 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3653) 3654 Requirements for Separation of IP Control and Forwarding. H. Khosravi, Ed., T. Anderson, Ed.. November 2003. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3654) 3655 Redefinition of DNS Authenticated Data (AD) bit. B. Wellington, O. Gudmundsson. November 2003. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3655) 3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol. R. Siemborski. December 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3656) 3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS). S. Moriai, A. Kato. January 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3657) 3658 Delegation Signer (DS) Resource Record (RR). O. Gudmundsson. December 2003. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3090, RFC3008, RFC2535, RFC1035) (Updated by RFC3755) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3658) 3659 Extensions to FTP. P. Hethmon. March 2007. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3659) 3660 Basic Media Gateway Control Protocol (MGCP) Packages. B. Foster, F. Andreasen. December 2003. (Format: TXT, HTML) (Updates RFC2705) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3660) 3661 Media Gateway Control Protocol (MGCP) Return Code Usage. B. Foster, C. Sivachelvan. December 2003. (Format: TXT, HTML) (Updates RFC3435) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3661) 3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services. R. Bless, K. Nichols, K. Wehrle. December 2003. (Format: TXT, HTML) (Obsoleted by RFC8622) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3662) 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP). A. Newton. December 2003. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3663) 3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE). P. Hoffman. January 2004. (Format: TXT, HTML) (Obsoleted by RFC4434) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3664) 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT, HTML) (Also BCP0075) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3665) 3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT, HTML) (Also BCP0076) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3666) 3667 IETF Rights in Contributions. S. Bradner. February 2004. (Format: TXT, HTML) (Obsoleted by RFC3978) (Updates RFC2026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3667) 3668 Intellectual Property Rights in IETF Technology. S. Bradner. February 2004. (Format: TXT, HTML) (Obsoleted by RFC3979) (Updates RFC2026, RFC2028) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3668) 3669 Guidelines for Working Groups on Intellectual Property Issues. S. Brim. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3669) 3670 Information Model for Describing Network Device QoS Datapath Mechanisms. B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss. January 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3670) 3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3671) 3672 Subentries in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3672) 3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes. K. Zeilenga. December 2003. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3673) 3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP). K. Zeilenga. December 2003. (Format: TXT, HTML) (Obsoleted by RFC4512) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3674) 3675 .sex Considered Dangerous. D. Eastlake 3rd. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3675) 3676 The Text/Plain Format and DelSp Parameters. R. Gellens. February 2004. (Format: TXT, HTML) (Obsoletes RFC2646) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3676) 3677 IETF ISOC Board of Trustee Appointment Procedures. L. Daigle, Ed., Internet Architecture Board. December 2003. (Format: TXT, HTML) (Also BCP0077) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3677) 3678 Socket Interface Extensions for Multicast Source Filters. D. Thaler, B. Fenner, B. Quinn. January 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3678) 3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes. R. Droms. January 2004. (Format: TXT, HTML) (Updated by RFC8910) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3679) 3680 A Session Initiation Protocol (SIP) Event Package for Registrations. J. Rosenberg. March 2004. (Format: TXT, HTML) (Updated by RFC6140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3680) 3681 Delegation of E.F.F.3.IP6.ARPA. R. Bush, R. Fink. January 2004. (Format: TXT, HTML) (Also BCP0080) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3681) 3682 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5082) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3682) 3683 A Practice for Revoking Posting Rights to IETF Mailing Lists. M. Rose. March 2004. (Format: TXT, HTML) (Also BCP0083) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3683) 3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF). R. Ogier, F. Templin, M. Lewis. February 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3684) 3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C. Daboo. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3685) 3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP). R. Housley. January 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3686) 3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules. S. Legg. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3687) 3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT, HTML) (Also BCP0081) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3688) 3689 General Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3689) 3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS). K. Carlberg, R. Atkinson. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3690) 3691 Internet Message Access Protocol (IMAP) UNSELECT command. A. Melnikov. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3691) 3692 Assigning Experimental and Testing Numbers Considered Useful. T. Narten. January 2004. (Format: TXT, HTML) (Updates RFC2434) (Also BCP0082) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3692) 3693 Geopriv Requirements. J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. February 2004. (Format: TXT, HTML) (Updated by RFC6280, RFC7459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3693) 3694 Threat Analysis of the Geopriv Protocol. M. Danley, D. Mulligan, J. Morris, J. Peterson. February 2004. (Format: TXT, HTML) (Updated by RFC6280) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3694) 3695 Compact Forward Error Correction (FEC) Schemes. M. Luby, L. Vicisano. February 2004. (Format: TXT, HTML) (Obsoleted by RFC5445) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3695) 3696 Application Techniques for Checking and Transformation of Names. J. Klensin. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3696) 3697 IPv6 Flow Label Specification. J. Rajahalme, A. Conta, B. Carpenter, S. Deering. March 2004. (Format: TXT, HTML) (Obsoleted by RFC6437) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3697) 3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules. K. Zeilenga, Ed.. February 2004. (Format: TXT, HTML) (Updates RFC2798) (Updated by RFC4517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3698) 3699 Not Issued. 3700 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC3600) (Obsoleted by RFC5000) (Status: HISTORIC) (DOI: 10.17487/RFC3700) 3701 6bone (IPv6 Testing Address Allocation) Phaseout. R. Fink, R. Hinden. March 2004. (Format: TXT, HTML) (Obsoletes RFC2471) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3701) 3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP). J. Loughney, G. Camarillo. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3702) 3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema. J. Strassner, B. Moore, R. Moats, E. Ellesson. February 2004. (Format: TXT, HTML) (Updated by RFC4104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3703) 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT, HTML) (Updates RFC2827) (Updated by RFC8704) (Also BCP0084) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3704) 3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals. B. Ray, R. Abbi. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3705) 3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers. G. Huang, S. Beaulieu, D. Rochefort. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3706) 3707 Cross Registry Internet Service Protocol (CRISP) Requirements. A. Newton. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3707) 3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions. E. Blanton, M. Allman. February 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3708) 3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates. S. Santesson, R. Housley, T. Freeman. February 2004. (Format: TXT, HTML) (Updated by RFC6170) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3709) 3710 An IESG charter. H. Alvestrand. February 2004. (Format: TXT, HTML) (Updated by RFC3932, RFC5742, RFC8717) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3710) 3711 The Secure Real-time Transport Protocol (SRTP). M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. March 2004. (Format: TXT, HTML) (Updated by RFC5506, RFC6904) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3711) 3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services. P. Fleming, I. McDonald. February 2004. (Format: TXT, HTML) (Obsoleted by RFC7612) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3712) 3713 A Description of the Camellia Encryption Algorithm. M. Matsui, J. Nakajima, S. Moriai. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3713) 3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet. S. Floyd, Ed., J. Kempf, Ed.. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3714) 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements. B. Aboba, W. Dixon. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3715) 3716 IETF in the Large: Administration and Execution. IAB Advisory Committee. March 2004. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3716) 3717 IP over Optical Networks: A Framework. B. Rajagopalan, J. Luciani, D. Awduche. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3717) 3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access. R. McGowan. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3718) 3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. February 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3719) 3720 Internet Small Computer Systems Interface (iSCSI). J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner. April 2004. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updated by RFC3980, RFC4850, RFC5048, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3720) 3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery. M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. April 2004. (Format: TXT, HTML) (Updated by RFC7143) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3721) 3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names. M. Bakke. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3722) 3723 Securing Block Storage Protocols over IP. B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino. April 2004. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3723) 3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture. J. Kempf, Ed., R. Austein, Ed., IAB. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3724) 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. April 2004. (Format: TXT, HTML) (Also BCP0085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3725) 3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3726) 3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules. S. Legg. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3727) 3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL). B. Ray, R. Abbi. February 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3728) 3729 Application Performance Measurement MIB. S. Waldbusser. March 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3729) 3730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4930) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3730) 3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3731) 3732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3732) 3733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3733) 3734 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. March 2004. (Format: TXT, HTML) (Obsoleted by RFC4934) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3734) 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP). S. Hollenbeck. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3735) 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. R. Droms. April 2004. (Format: TXT, HTML) (Obsoleted by RFC8415) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3736) 3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules. B. Wijnen, A. Bierman. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3737) 3738 Wave and Equation Based Rate Control (WEBRC) Building Block. M. Luby, V. Goyal. April 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3738) 3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile. S. Santesson, M. Nystrom, T. Polk. March 2004. (Format: TXT, HTML) (Obsoletes RFC3039) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3739) 3740 The Multicast Group Security Architecture. T. Hardjono, B. Weis. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3740) 3741 Exclusive XML Canonicalization, Version 1.0. J. Boyer, D. Eastlake 3rd, J. Reagle. March 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3741) 3742 Limited Slow-Start for TCP with Large Congestion Windows. S. Floyd. March 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3742) 3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean. K. Konishi, K. Huang, H. Qian, Y. Ko. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3743) 3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol. G. Clemm, J. Reschke, E. Sedlar, J. Whitehead. May 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3744) 3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444). D. Singer, R. Clark, D. Lee. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3745) 3746 Forwarding and Control Element Separation (ForCES) Framework. L. Yang, R. Dantu, T. Anderson, R. Gopal. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3746) 3747 The Differentiated Services Configuration MIB. H. Hazewinkel, Ed., D. Partain, Ed.. April 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3747) 3748 Extensible Authentication Protocol (EAP). B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed.. June 2004. (Format: TXT, HTML) (Obsoletes RFC2284) (Updated by RFC5247, RFC7057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3748) 3749 Transport Layer Security Protocol Compression Methods. S. Hollenbeck. May 2004. (Format: TXT, HTML) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3749) 3750 Unmanaged Networks IPv6 Transition Scenarios. C. Huitema, R. Austein, S. Satapati, R. van der Pol. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3750) 3751 Omniscience Protocol Requirements. S. Bradner. 1 April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3751) 3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios. A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3752) 3753 Mobility Related Terminology. J. Manner, Ed., M. Kojo, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3753) 3754 IP Multicast in Differentiated Services (DS) Networks. R. Bless, K. Wehrle. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3754) 3755 Legacy Resolver Compatibility for Delegation Signer (DS). S. Weiler. May 2004. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3658, RFC2535) (Updated by RFC3757, RFC3845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3755) 3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats. P. Nikander, Ed., J. Kempf, E. Nordmark. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3756) 3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag. O. Kolkman, J. Schlyter, E. Lewis. April 2004. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3755, RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3757) 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension. R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad. May 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3758) 3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples. L-E. Jonsson. April 2004. (Format: TXT, HTML) (Updates RFC3095) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3759) 3760 Securely Available Credentials (SACRED) - Credential Server Framework. D. Gustafson, M. Just, M. Nystrom. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3760) 3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). P. Faltstrom, M. Mealling. April 2004. (Format: TXT, HTML) (Obsoletes RFC2916) (Obsoleted by RFC6116, RFC6117) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3761) 3762 Telephone Number Mapping (ENUM) Service Registration for H.323. O. Levin. April 2004. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3762) 3763 One-way Active Measurement Protocol (OWAMP) Requirements. S. Shalunov, B. Teitelbaum. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3763) 3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record. J. Peterson. April 2004. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3764) 3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control. G. Huston. April 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3765) 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys. H. Orman, P. Hoffman. April 2004. (Format: TXT, HTML) (Also BCP0086) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3766) 3767 Securely Available Credentials Protocol. S. Farrell, Ed.. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3767) 3768 Virtual Router Redundancy Protocol (VRRP). R. Hinden, Ed.. April 2004. (Format: TXT, HTML) (Obsoletes RFC2338) (Obsoleted by RFC5798) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3768) 3769 Requirements for IPv6 Prefix Delegation. S. Miyakawa, R. Droms. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3769) 3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). R. Housley, T. Moore. May 2004. (Format: TXT, HTML) (Obsoleted by RFC4334) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3770) 3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message. R. Harrison, K. Zeilenga. April 2004. (Format: TXT, HTML) (Obsoleted by RFC4511, RFC4510) (Updates RFC2251) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3771) 3772 Point-to-Point Protocol (PPP) Vendor Protocol. J. Carlson, R. Winslow. May 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3772) 3773 High-Level Requirements for Internet Voice Mail. E. Candell. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3773) 3774 IETF Problem Statement. E. Davies, Ed.. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3774) 3775 Mobility Support in IPv6. D. Johnson, C. Perkins, J. Arkko. June 2004. (Format: TXT, HTML) (Obsoleted by RFC6275) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3775) 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. J. Arkko, V. Devarapalli, F. Dupont. June 2004. (Format: TXT, HTML) (Updated by RFC4877) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3776) 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin, Ed.. June 2004. (Format: TXT, HTML) (Obsoletes RFC2727) (Obsoleted by RFC7437) (Updated by RFC5078, RFC5633, RFC5680, RFC6859) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3777) 3778 The application/pdf Media Type. E. Taft, J. Pravetz, S. Zilles, L. Masinter. May 2004. (Format: TXT, HTML) (Obsoleted by RFC8118) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3778) 3779 X.509 Extensions for IP Addresses and AS Identifiers. C. Lynn, S. Kent, K. Seo. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3779) 3780 SMIng - Next Generation Structure of Management Information. F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3780) 3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP). F. Strauss, J. Schoenwaelder. May 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3781) 3782 The NewReno Modification to TCP's Fast Recovery Algorithm. S. Floyd, T. Henderson, A. Gurtov. April 2004. (Format: TXT, HTML) (Obsoletes RFC2582) (Obsoleted by RFC6582) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3782) 3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI. M. Chadalapaka, R. Elliott. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3783) 3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE). H. Smit, T. Li. June 2004. (Format: TXT, HTML) (Obsoleted by RFC5305) (Updated by RFC4205) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3784) 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric. F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. May 2004. (Format: TXT, HTML) (Also BCP0087) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3785) 3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit. A. Hermelin, S. Previdi, M. Shand. May 2004. (Format: TXT, HTML) (Obsoleted by RFC5311) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3786) 3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. May 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3787) 3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols. J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3788) 3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3789) 3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents. C. Mickles, Ed., P. Nesser, II. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3790) 3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents. C. Olvera, P. Nesser, II. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3791) 3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3792) 3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3793) 3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3794) 3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents. R. Sofia, P. Nesser, II. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3795) 3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents. P. Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3796) 3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection. D. Eastlake 3rd. June 2004. (Format: TXT, HTML) (Obsoletes RFC2777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3797) 3798 Message Disposition Notification. T. Hansen, Ed., G. Vaudreuil, Ed.. May 2004. (Format: TXT, HTML) (Obsoletes RFC2298) (Obsoleted by RFC8098) (Updates RFC3461, RFC2046) (Updated by RFC5337, RFC6533) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3798) 3799 Not Issued. 3800 Not Issued. 3801 Voice Profile for Internet Mail - version 2 (VPIMv2). G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2421, RFC2423) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3801) 3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2422) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3802) 3803 Content Duration MIME Header Definition. G. Vaudreuil, G. Parsons. June 2004. (Format: TXT, HTML) (Obsoletes RFC2424) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3803) 3804 Voice Profile for Internet Mail (VPIM) Addressing. G. Parsons. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3804) 3805 Printer MIB v2. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT, HTML) (Obsoletes RFC1759) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3805) 3806 Printer Finishing MIB. R. Bergman, H. Lewis, I. McDonald. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3806) 3807 V5.2-User Adaptation Layer (V5UA). E. Weilandt, N. Khanchandani, S. Rao. June 2004. (Format: TXT, HTML) (Updates RFC3057) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3807) 3808 IANA Charset MIB. I. McDonald. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3808) 3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN). A. Nagarajan, Ed.. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3809) 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6. R. Vida, Ed., L. Costa, Ed.. June 2004. (Format: TXT, HTML) (Updates RFC2710) (Updated by RFC4604) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3810) 3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management. T. Nadeau, Ed., J. Cucchiara, Ed.. June 2004. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3811) 3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3812) 3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB). C. Srinivasan, A. Viswanathan, T. Nadeau. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3813) 3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB). T. Nadeau, C. Srinivasan, A. Viswanathan. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3814) 3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP). J. Cucchiara, H. Sjostrand, J. Luciani. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3815) 3816 Definitions of Managed Objects for RObust Header Compression (ROHC). J. Quittek, M. Stiemerling, H. Hartenstein. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3816) 3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE). W. Townsley, R. da Silva. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3817) 3818 IANA Considerations for the Point-to-Point Protocol (PPP). V. Schryver. June 2004. (Format: TXT, HTML) (Also BCP0088) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3818) 3819 Advice for Internet Subnetwork Designers. P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. July 2004. (Format: TXT, HTML) (Also BCP0089) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3819) 3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3820) 3821 Fibre Channel Over TCP/IP (FCIP). M. Rajagopal, E. Rodriguez, R. Weber. July 2004. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3821) 3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2). D. Peterson. July 2004. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3822) 3823 MIME Media Type for the Systems Biology Markup Language (SBML). B. Kovitz. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3823) 3824 Using E.164 numbers with the Session Initiation Protocol (SIP). J. Peterson, H. Liu, J. Yu, B. Campbell. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3824) 3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information. J. Polk, J. Schnizlein, M. Linsner. July 2004. (Format: TXT, HTML) (Obsoleted by RFC6225) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3825) 3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model. U. Blumenthal, F. Maino, K. McCloghrie. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3826) 3827 Additional Snoop Datalink Types. K. Sarcar. June 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3827) 3828 The Lightweight User Datagram Protocol (UDP-Lite). L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. July 2004. (Format: TXT, HTML) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3828) 3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls. R. Weltman, M. Smith, M. Wahl. July 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3829) 3830 MIKEY: Multimedia Internet KEYing. J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman. August 2004. (Format: TXT, HTML) (Updated by RFC4738, RFC6309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3830) 3831 Transmission of IPv6 Packets over Fibre Channel. C. DeSanti. July 2004. (Format: TXT, HTML) (Obsoleted by RFC4338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3831) 3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV. W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. July 2004. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3832) 3833 Threat Analysis of the Domain Name System (DNS). D. Atkins, R. Austein. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3833) 3834 Recommendations for Automatic Responses to Electronic Mail. K. Moore. August 2004. (Format: TXT, HTML) (Updated by RFC5436) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3834) 3835 An Architecture for Open Pluggable Edge Services (OPES). A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3835) 3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols. A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3836) 3837 Security Threats and Risks for Open Pluggable Edge Services (OPES). A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3837) 3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES). A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3838) 3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files. R. Castagno, D. Singer. July 2004. (Format: TXT, HTML) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3839) 3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, P. Kyzivat. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3840) 3841 Caller Preferences for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, P. Kyzivat. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3841) 3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP). R. Mahy. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3842) 3843 RObust Header Compression (ROHC): A Compression Profile for IP. L-E. Jonsson, G. Pelletier. June 2004. (Format: TXT, HTML) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3843) 3844 IETF Problem Resolution Process. E. Davies, Ed., J. Hofmann, Ed.. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3844) 3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format. J. Schlyter, Ed.. August 2004. (Format: TXT, HTML) (Obsoleted by RFC4033, RFC4034, RFC4035) (Updates RFC3755, RFC2535) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3845) 3846 Mobile IPv4 Extension for Carrying Network Access Identifiers. F. Johansson, T. Johansson. June 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3846) 3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS). M. Shand, L. Ginsberg. July 2004. (Format: TXT, HTML) (Obsoleted by RFC5306) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3847) 3848 ESMTP and LMTP Transmission Types Registration. C. Newman. July 2004. (Format: TXT, HTML) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3848) 3849 IPv6 Address Prefix Reserved for Documentation. G. Huston, A. Lord, P. Smith. July 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3849) 3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. B. Ramsdell, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC2632) (Obsoleted by RFC5750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3850) 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. B. Ramsdell, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC2633) (Obsoleted by RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3851) 3852 Cryptographic Message Syntax (CMS). R. Housley. July 2004. (Format: TXT, HTML) (Obsoletes RFC3369) (Obsoleted by RFC5652) (Updated by RFC4853, RFC5083) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3852) 3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP). J. Peterson. July 2004. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3853) 3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME). P. Hoffman, C. Bonatti, A. Eggen. July 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3854) 3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400. P. Hoffman, C. Bonatti. July 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3855) 3856 A Presence Event Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3856) 3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3857) 3858 An Extensible Markup Language (XML) Based Format for Watcher Information. J. Rosenberg. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3858) 3859 Common Profile for Presence (CPP). J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3859) 3860 Common Profile for Instant Messaging (CPIM). J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3860) 3861 Address Resolution for Instant Messaging and Presence. J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3861) 3862 Common Presence and Instant Messaging (CPIM): Message Format. G. Klyne, D. Atkins. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3862) 3863 Presence Information Data Format (PIDF). H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson. August 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3863) 3864 Registration Procedures for Message Header Fields. G. Klyne, M. Nottingham, J. Mogul. September 2004. (Format: TXT, HTML) (Also BCP0090) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3864) 3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension. C. Malamud. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3865) 3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). K. Zeilenga, Ed.. July 2004. (Format: TXT, HTML) (Obsoletes RFC2596) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3866) 3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP). Y. Kawatsura, M. Hiroya, H. Beykirch. November 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3867) 3868 Signalling Connection Control Part User Adaptation Layer (SUA). J. Loughney, Ed., G. Sidebottom, L. Coene, G. Verwimp, J. Keller, B. Bidulock. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3868) 3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution. R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. August 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3869) 3870 application/rdf+xml Media Type Registration. A. Swartz. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3870) 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3871) 3872 Management Information Base for Telephony Routing over IP (TRIP). D. Zinman, D. Walker, J. Jiang. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3872) 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB). J. Pastor, M. Belinchon. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3873) 3874 A 224-bit One-way Hash Function: SHA-224. R. Housley. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3874) 3875 The Common Gateway Interface (CGI) Version 1.1. D. Robinson, K. Coar. October 2004. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3875) 3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3). D. Chadwick, S. Mullan. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3876) 3877 Alarm Management Information Base (MIB). S. Chisholm, D. Romascanu. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3877) 3878 Alarm Reporting Control Management Information Base (MIB). H. Lam, A. Huynh, D. Perkins. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3878) 3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3879) 3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services. J. Lennox, X. Wu, H. Schulzrinne. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3880) 3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications. G. Marshall. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3881) 3882 Configuring BGP to Block Denial-of-Service Attacks. D. Turk. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3882) 3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC). S. Rao, A. Zinin, A. Roy. October 2004. (Format: TXT, HTML) (Updates RFC1793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3883) 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3884) 3885 SMTP Service Extension for Message Tracking. E. Allman, T. Hansen. September 2004. (Format: TXT, HTML) (Updates RFC3461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3885) 3886 An Extensible Message Format for Message Tracking Responses. E. Allman. September 2004. (Format: TXT, HTML) (Updates RFC3463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3886) 3887 Message Tracking Query Protocol. T. Hansen. September 2004. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3887) 3888 Message Tracking Model and Requirements. T. Hansen. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3888) 3889 Not Issued. 3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP). M. Westerlund. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3890) 3891 The Session Initiation Protocol (SIP) "Replaces" Header. R. Mahy, B. Biggs, R. Dean. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3891) 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism. R. Sparks. September 2004. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3892) 3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format. J. Peterson. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3893) 3894 Sieve Extension: Copying Without Side Effects. J. Degener. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3894) 3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types. O. Nicklass, Ed.. September 2004. (Format: TXT, HTML) (Obsoletes RFC2495) (Obsoleted by RFC4805) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3895) 3896 Definitions of Managed Objects for the DS3/E3 Interface Type. O. Nicklass, Ed.. September 2004. (Format: TXT, HTML) (Obsoletes RFC2496) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3896) 3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication. A. Barbir. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3897) 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). V. Kalusivalingam. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3898) 3899 Not Issued. 3900 Not Issued. 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT, HTML) (Also BCP0091) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3901) 3902 The "application/soap+xml" media type. M. Baker, M. Nottingham. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3902) 3903 Session Initiation Protocol (SIP) Extension for Event State Publication. A. Niemi, Ed.. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3903) 3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks. C. Huitema, R. Austein, S. Satapati, R. van der Pol. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3904) 3905 A Template for IETF Patent Disclosures and Licensing Declarations. V. See, Ed.. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3905) 3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels. N. Shen, H. Smit. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3906) 3907 Not Issued. 3908 Not Issued. 3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation. K. Zeilenga. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3909) 3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol. V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H. Lu, M. Unmehopa. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3910) 3911 The Session Initiation Protocol (SIP) "Join" Header. R. Mahy, D. Petrie. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3911) 3912 WHOIS Protocol Specification. L. Daigle. September 2004. (Format: TXT, HTML) (Obsoletes RFC0954, RFC0812) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3912) 3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification. D. Thaler. September 2004. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC3913) 3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations. A. Barbir, A. Rousskov. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3914) 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. September 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3915) 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3). X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.. September 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3916) 3917 Requirements for IP Flow Information Export (IPFIX). J. Quittek, T. Zseby, B. Claise, S. Zander. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3917) 3918 Methodology for IP Multicast Benchmarking. D. Stopp, B. Hickman. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3918) 3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS). E. Stephan, J. Palet. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3919) 3920 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre, Ed.. October 2004. (Format: TXT, HTML) (Obsoleted by RFC6120) (Updated by RFC6122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3920) 3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. P. Saint-Andre, Ed.. October 2004. (Format: TXT, HTML) (Obsoleted by RFC6121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3921) 3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM). P. Saint-Andre. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3922) 3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3923) 3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker, B. Foster, C. Sharp. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3924) 3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4). J. Littlefield. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3925) 3926 FLUTE - File Delivery over Unidirectional Transport. T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh. October 2004. (Format: TXT, HTML) (Obsoleted by RFC6726) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3926) 3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire, B. Aboba, E. Guttman. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3927) 3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). R. Megginson, Ed., M. Smith, O. Natkovich, J. Parham. October 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3928) 3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF. T. Hardie. October 2004. (Format: TXT, HTML) (Updated by RFC8717) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3929) 3930 The Protocol versus Document Points of View in Computer Protocols. D. Eastlake 3rd. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3930) 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3). J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.. March 2005. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3931) 3932 The IESG and RFC Editor Documents: Procedures. H. Alvestrand. October 2004. (Format: TXT, HTML) (Obsoleted by RFC5742) (Updates RFC2026, RFC3710) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3932) 3933 A Model for IETF Process Experiments. J. Klensin, S. Dawkins. November 2004. (Format: TXT, HTML) (Also BCP0093) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3933) 3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists. M. Wasserman. October 2004. (Format: TXT, HTML) (Updates RFC2418) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3934) 3935 A Mission Statement for the IETF. H. Alvestrand. October 2004. (Format: TXT, HTML) (Also BCP0095) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3935) 3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP). K. Kompella, J. Lang. October 2004. (Format: TXT, HTML) (Updates RFC3209, RFC2205) (Also BCP0096) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3936) 3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC). M. Steidl. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3937) 3938 Video-Message Message-Context. T. Hansen. October 2004. (Format: TXT, HTML) (Updates RFC3458) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3938) 3939 Calling Line Identification for Voice Mail Messages. G. Parsons, J. Maruszak. December 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3939) 3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT, HTML) (Obsoleted by RFC5740) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3940) 3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2004. (Format: TXT, HTML) (Obsoleted by RFC5401) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3941) 3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options. B. Volz. November 2004. (Format: TXT, HTML) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3942) 3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS). R. Friend. November 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3943) 3944 H.350 Directory Services. T. Johnson, S. Okubo, S. Campos. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3944) 3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture. E. Mannie, Ed.. October 2004. (Format: TXT, HTML) (Updated by RFC6002) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3945) 3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. E. Mannie, D. Papadimitriou. October 2004. (Format: TXT, HTML) (Obsoleted by RFC4606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3946) 3947 Negotiation of NAT-Traversal in the IKE. T. Kivinen, B. Swander, A. Huttunen, V. Volpe. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3947) 3948 UDP Encapsulation of IPsec ESP Packets. A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3948) 3949 File Format for Internet Fax. R. Buckley, D. Venable, L. McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT, HTML) (Obsoletes RFC2301) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3949) 3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration. L. McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT, HTML) (Obsoletes RFC3250) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3950) 3951 Internet Low Bit Rate Codec (iLBC). S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden. December 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3951) 3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech. A. Duric, S. Andersen. December 2004. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3952) 3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services. J. Peterson. January 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3953) 3954 Cisco Systems NetFlow Services Export Version 9. B. Claise, Ed.. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3954) 3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX). S. Leinen. October 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3955) 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. (Format: TXT, HTML) (Updates RFC3306) (Updated by RFC7371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3956) 3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4. C. Perkins, P. Calhoun. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3957) 3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS). L. Daigle, A. Newton. January 2005. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3958) 3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3959) 3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP). G. Camarillo, H. Schulzrinne. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3960) 3961 Encryption and Checksum Specifications for Kerberos 5. K. Raeburn. February 2005. (Format: TXT, HTML) (Updated by RFC8429) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3961) 3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5. K. Raeburn. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3962) 3963 Network Mobility (NEMO) Basic Support Protocol. V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3963) 3964 Security Considerations for 6to4. P. Savola, C. Patel. December 2004. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3964) 3965 A Simple Mode of Facsimile Using Internet Mail. K. Toyoda, H. Ohno, J. Murai, D. Wing. December 2004. (Format: TXT, HTML) (Obsoletes RFC2305) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC3965) 3966 The tel URI for Telephone Numbers. H. Schulzrinne. December 2004. (Format: TXT, HTML) (Obsoletes RFC2806) (Updated by RFC5341) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3966) 3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level. R. Bush, T. Narten. December 2004. (Format: TXT, HTML) (Updated by RFC4897, RFC8067) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3967) 3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT, HTML) (Updates RFC3427) (Also BCP0098) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3968) 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT, HTML) (Updates RFC3427) (Updated by RFC5727) (Also BCP0099) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3969) 3970 A Traffic Engineering (TE) MIB. K. Kompella. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3970) 3971 SEcure Neighbor Discovery (SEND). J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander. March 2005. (Format: TXT, HTML) (Updated by RFC6494, RFC6495, RFC6980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3971) 3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005. (Format: TXT, HTML) (Updated by RFC4581, RFC4982) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3972) 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). A. Adams, J. Nicholas, W. Siadak. January 2005. (Format: TXT, HTML) (Updated by RFC8736) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3973) 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3974) 3975 OMA-IETF Standardization Collaboration. G. Huston, Ed., I. Leuca, Ed.. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3975) 3976 Interworking SIP and Intelligent Network (IN) Applications. V. K. Gurbani, F. Haerens, V. Rastogi. January 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3976) 3977 Network News Transfer Protocol (NNTP). C. Feather. October 2006. (Format: TXT, HTML) (Obsoletes RFC0977) (Updates RFC2980) (Updated by RFC6048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3977) 3978 IETF Rights in Contributions. S. Bradner, Ed.. March 2005. (Format: TXT, HTML) (Obsoletes RFC3667) (Obsoleted by RFC5378) (Updates RFC2026) (Updated by RFC4748) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3978) 3979 Intellectual Property Rights in IETF Technology. S. Bradner, Ed.. March 2005. (Format: TXT, HTML) (Obsoletes RFC3668) (Obsoleted by RFC8179) (Updates RFC2026, RFC2028) (Updated by RFC4879) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC3979) 3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names. M. Krueger, M. Chadalapaka, R. Elliott. February 2005. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updates RFC3720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3980) 3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol. A. Newton, M. Sanz. January 2005. (Format: TXT, HTML) (Updated by RFC4992) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3981) 3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS). A. Newton, M. Sanz. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3982) 3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP). A. Newton, M. Sanz. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3983) 3984 RTP Payload Format for H.264 Video. S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. February 2005. (Format: TXT, HTML) (Obsoleted by RFC6184) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3984) 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. S. Bryant, Ed., P. Pate, Ed.. March 2005. (Format: TXT, HTML) (Updated by RFC5462) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3985) 3986 Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. January 2005. (Format: TXT, HTML) (Obsoletes RFC2732, RFC2396, RFC1808) (Updates RFC1738) (Updated by RFC6874, RFC7320, RFC8820) (Also STD0066) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC3986) 3987 Internationalized Resource Identifiers (IRIs). M. Duerst, M. Suignard. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3987) 3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol. B. Black, K. Kompella. January 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC3988) 3989 Middlebox Communications (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. February 2005. (Format: TXT, HTML) (Obsoleted by RFC5189) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3989) 3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement. B. O'Hara, P. Calhoun, J. Kempf. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3990) 3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package. B. Foster, F. Andreasen. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3991) 3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism. B. Foster, F. Andreasen. February 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3992) 3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. R. Johnson, T. Palaniappan, M. Stapp. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3993) 3994 Indication of Message Composition for Instant Messaging. H. Schulzrinne. January 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3994) 3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions. R. Herriot, T. Hastings. March 2005. (Format: TXT, HTML) (Updates RFC2911, RFC2910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3995) 3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications. R. Herriot, T. Hastings, H. Lewis. March 2005. (Format: TXT, HTML) (Updates RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3996) 3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications. T. Hastings, Ed., R. K. deBry, H. Lewis. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3997) 3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations. C. Kugler, H. Lewis, T. Hastings, Ed.. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3998) 3999 Not Issued. 4000 Not Issued. 4001 Textual Conventions for Internet Network Addresses. M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. February 2005. (Format: TXT, HTML) (Obsoletes RFC3291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4001) 4002 IANA Registration for Enumservice 'web' and 'ft'. R. Brandner, L. Conroy, R. Stastny. February 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4002) 4003 GMPLS Signaling Procedure for Egress Control. L. Berger. February 2005. (Format: TXT, HTML) (Updates RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4003) 4004 Diameter Mobile IPv4 Application. P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4004) 4005 Diameter Network Access Server Application. P. Calhoun, G. Zorn, D. Spence, D. Mitton. August 2005. (Format: TXT, HTML) (Obsoleted by RFC7155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4005) 4006 Diameter Credit-Control Application. H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney. August 2005. (Format: TXT, HTML) (Obsoleted by RFC8506) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4006) 4007 IPv6 Scoped Address Architecture. S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. March 2005. (Format: TXT, HTML) (Updated by RFC7346) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4007) 4008 Definitions of Managed Objects for Network Address Translators (NAT). R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang. March 2005. (Format: TXT, HTML) (Obsoleted by RFC7658) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4008) 4009 The SEED Encryption Algorithm. J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT, HTML) (Obsoleted by RFC4269) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4009) 4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Park, S. Lee, J. Kim, J. Lee. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4010) 4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4011) 4012 Routing Policy Specification Language next generation (RPSLng). L. Blunk, J. Damas, F. Parent, A. Robachevsky. March 2005. (Format: TXT, HTML) (Updates RFC2725, RFC2622) (Updated by RFC7909) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4012) 4013 SASLprep: Stringprep Profile for User Names and Passwords. K. Zeilenga. February 2005. (Format: TXT, HTML) (Obsoleted by RFC7613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4013) 4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option. R. Droms, J. Schnizlein. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4014) 4015 The Eifel Response Algorithm for TCP. R. Ludwig, A. Gurtov. February 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4015) 4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements. M. Parthasarathy. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4016) 4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs. D. Stanley, J. Walker, B. Aboba. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4017) 4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2). M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. April 2005. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4018) 4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite. G. Pelletier. April 2005. (Format: TXT, HTML) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4019) 4020 Early IANA Allocation of Standards Track Code Points. K. Kompella, A. Zinin. February 2005. (Format: TXT, HTML) (Obsoleted by RFC7120) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4020) 4021 Registration of Mail and MIME Header Fields. G. Klyne, J. Palme. March 2005. (Format: TXT, HTML) (Updated by RFC5322) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4021) 4022 Management Information Base for the Transmission Control Protocol (TCP). R. Raghunarayan, Ed.. March 2005. (Format: TXT, HTML) (Obsoletes RFC2452, RFC2012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4022) 4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE). T. Worster, Y. Rekhter, E. Rosen, Ed.. March 2005. (Format: TXT, HTML) (Updated by RFC5332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4023) 4024 Voice Messaging Client Behaviour. G. Parsons, J. Maruszak. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4024) 4025 A Method for Storing IPsec Keying Material in DNS. M. Richardson. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4025) 4026 Provider Provisioned Virtual Private Network (VPN) Terminology. L. Andersson, T. Madsen. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4026) 4027 Domain Name System Media Types. S. Josefsson. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4027) 4028 Session Timers in the Session Initiation Protocol (SIP). S. Donovan, J. Rosenberg. April 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4028) 4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks. M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4029) 4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. M. Stapp, T. Lemon. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4030) 4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs). M. Carugi, Ed., D. McDysan, Ed.. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4031) 4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework. G. Camarillo, P. Kyzivat. March 2005. (Format: TXT, HTML) (Updates RFC3312) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4032) 4033 DNS Security Introduction and Requirements. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC6014, RFC6840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4033) 4034 Resource Records for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840, RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4034) 4035 Protocol Modifications for the DNS Security Extensions. R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. (Format: TXT, HTML) (Obsoletes RFC2535, RFC3008, RFC3090, RFC3445, RFC3655, RFC3658, RFC3755, RFC3757, RFC3845) (Updates RFC1034, RFC1035, RFC2136, RFC2181, RFC2308, RFC3225, RFC3597, RFC3226) (Updated by RFC4470, RFC6014, RFC6840, RFC8198) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4035) 4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management. W. Sawyer. April 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4036) 4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core. A. Rousskov. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4037) 4038 Application Aspects of IPv6 Transition. M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. March 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4038) 4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4). S. Park, P. Kim, B. Volz. March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4039) 4040 RTP Payload Format for a 64 kbit/s Transparent Call. R. Kreuter. April 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4040) 4041 Requirements for Morality Sections in Routing Area Drafts. A. Farrel. 1 April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4041) 4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode. M. Crispin. 1 April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4042) 4043 Internet X.509 Public Key Infrastructure Permanent Identifier. D. Pinkas, T. Gindin. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4043) 4044 Fibre Channel Management MIB. K. McCloghrie. May 2005. (Format: TXT, HTML) (Obsoletes RFC2837) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4044) 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP). G. Bourdon. April 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4045) 4046 Multicast Security (MSEC) Group Key Management Architecture. M. Baugher, R. Canetti, L. Dondeti, F. Lindholm. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4046) 4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS). S. Allen, D. Wells. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4047) 4048 RFC 1888 Is Obsolete. B. Carpenter. April 2005. (Format: TXT, HTML) (Obsoletes RFC1888) (Updated by RFC4548) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4048) 4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1. R. Housley. April 2005. (Format: TXT, HTML) (Obsoleted by RFC6019) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4049) 4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures. S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4050) 4051 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2005. (Format: TXT, HTML) (Obsoleted by RFC6931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4051) 4052 IAB Processes for Management of IETF Liaison Relationships. L. Daigle, Ed., Internet Architecture Board. April 2005. (Format: TXT, HTML) (Also BCP0102) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4052) 4053 Procedures for Handling Liaison Statements to and from the IETF. S. Trowbridge, S. Bradner, F. Baker. April 2005. (Format: TXT, HTML) (Also BCP0103) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4053) 4054 Impairments and Other Constraints on Optical Layer Routing. J. Strand, Ed., A. Chiu, Ed.. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4054) 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. J. Schaad, B. Kaliski, R. Housley. June 2005. (Format: TXT, HTML) (Updates RFC3279) (Updated by RFC5756) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4055) 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4056) 4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4057) 4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements. A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4058) 4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension. D. Linsenbardt, S. Pontius, A. Sturgeon. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4059) 4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding. Q. Xie, D. Pearce. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4060) 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4061) 4062 OSPF Benchmarking Terminology and Concepts. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4062) 4063 Considerations When Using Basic OSPF Convergence Benchmarks. V. Manral, R. White, A. Shaikh. April 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4063) 4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4. A. Patel, K. Leung. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4064) 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations. J. Kempf. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4065) 4066 Candidate Access Router Discovery (CARD). M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4066) 4067 Context Transfer Protocol (CXTP). J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli. July 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4067) 4068 Fast Handovers for Mobile IPv6. R. Koodli, Ed.. July 2005. (Format: TXT, HTML) (Obsoleted by RFC5268) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4068) 4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding. M. Dodge, B. Ray. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4069) 4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding. M. Dodge, B. Ray. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4070) 4071 Structure of the IETF Administrative Support Activity (IASA). R. Austein, Ed., B. Wijnen, Ed.. April 2005. (Format: TXT, HTML) (Obsoleted by RFC8711) (Updated by RFC4371, RFC7691) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4071) 4072 Diameter Extensible Authentication Protocol (EAP) Application. P. Eronen, Ed., T. Hiller, G. Zorn. August 2005. (Format: TXT, HTML) (Updated by RFC7268, RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4072) 4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS). R. Housley. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4073) 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses. Y. Morishita, T. Jinmei. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4074) 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6. V. Kalusivalingam. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4075) 4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Chown, S. Venaas, A. Vijayabhaskar. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4076) 4077 A Negative Acknowledgement Mechanism for Signaling Compression. A.B. Roach. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4077) 4078 The TV-Anytime Content Reference Identifier (CRID). N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4078) 4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects. J. Peterson. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4079) 4080 Next Steps in Signaling (NSIS): Framework. R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4080) 4081 Security Threats for Next Steps in Signaling (NSIS). H. Tschofenig, D. Kroeselberg. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4081) 4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction. A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4082) 4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP). M. Garcia-Martin. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4083) 4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT, HTML) (Also BCP0104) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4084) 4085 Embedding Globally-Routable Internet Addresses Considered Harmful. D. Plonka. June 2005. (Format: TXT, HTML) (Also BCP0105) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4085) 4086 Randomness Requirements for Security. D. Eastlake 3rd, J. Schiller, S. Crocker. June 2005. (Format: TXT, HTML) (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4086) 4087 IP Tunnel MIB. D. Thaler. June 2005. (Format: TXT, HTML) (Obsoletes RFC2667) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4087) 4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP). D. Black, K. McCloghrie, J. Schoenwaelder. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4088) 4089 IAB and IESG Recommendation for IETF Administrative Restructuring. S. Hollenbeck, Ed., IAB and IESG. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4089) 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.. May 2005. (Format: TXT, HTML) (Updated by RFC8271, RFC8537, RFC8796) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4090) 4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework. G. Camarillo, J. Rosenberg. June 2005. (Format: TXT, HTML) (Obsoleted by RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4091) 4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP). G. Camarillo, J. Rosenberg. June 2005. (Format: TXT, HTML) (Obsoleted by RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4092) 4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways. F. Adrangi, Ed., H. Levkowetz, Ed.. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4093) 4094 Analysis of Existing Quality-of-Service Signaling Protocols. J. Manner, X. Fu. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4094) 4095 Attaching Meaning to Solicitation Class Keywords. C. Malamud. May 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4095) 4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best. C. Malamud. May 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4096) 4097 Middlebox Communications (MIDCOM) Protocol Evaluation. M. Barnes, Ed.. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4097) 4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane. H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4098) 4099 Not Issued. 4100 Not Issued. 4101 Writing Protocol Models. E. Rescorla, IAB. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4101) 4102 Registration of the text/red MIME Sub-Type. P. Jones. June 2005. (Format: TXT, HTML) (Updated by RFC6354) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4102) 4103 RTP Payload for Text Conversation. G. Hellstrom, P. Jones. June 2005. (Format: TXT, HTML) (Obsoletes RFC2793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4103) 4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner. June 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4104) 4105 Requirements for Inter-Area MPLS Traffic Engineering. J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed.. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4105) 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP). J. Viega, D. McGrew. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4106) 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT, HTML) (Also BCP0107) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4107) 4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages. R. Housley. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4108) 4109 Algorithms for Internet Key Exchange version 1 (IKEv1). P. Hoffman. May 2005. (Format: TXT, HTML) (Updates RFC2409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4109) 4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). R. Callon, M. Suzuki. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4110) 4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs). L. Fang, Ed.. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4111) 4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification. D. Eastlake 3rd. June 2005. (Format: TXT, HTML) (Updates RFC3106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4112) 4113 Management Information Base for the User Datagram Protocol (UDP). B. Fenner, J. Flick. June 2005. (Format: TXT, HTML) (Obsoletes RFC2454, RFC2013) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4113) 4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4114) 4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic. O. Aboul-Magd, S. Rabie. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4115) 4116 IPv4 Multihoming Practices and Limitations. J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4116) 4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc). G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4117) 4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP). L. Yang, P. Zerfos, E. Sadot. June 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4118) 4119 A Presence-based GEOPRIV Location Object Format. J. Peterson. December 2005. (Format: TXT, HTML) (Updated by RFC5139, RFC5491, RFC7459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4119) 4120 The Kerberos Network Authentication Service (V5). C. Neuman, T. Yu, S. Hartman, K. Raeburn. July 2005. (Format: TXT, HTML) (Obsoletes RFC1510) (Updated by RFC4537, RFC5021, RFC5896, RFC6111, RFC6112, RFC6113, RFC6649, RFC6806, RFC7751, RFC8062, RFC8129, RFC8429, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4120) 4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. L. Zhu, K. Jaganathan, S. Hartman. July 2005. (Format: TXT, HTML) (Updates RFC1964) (Updated by RFC5896, RFC6112, RFC6542, RFC6649, RFC8062) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4121) 4122 A Universally Unique IDentifier (UUID) URN Namespace. P. Leach, M. Mealling, R. Salz. July 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4122) 4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements. H. Schulzrinne, C. Agboh. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4123) 4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4124) 4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, W. Lai. June 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4125) 4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons. J. Ash. June 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4126) 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. F. Le Faucheur, Ed.. June 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4127) 4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation. W. Lai. June 2005. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4128) 4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol. R. Mukundan, K. Morneault, N. Mangalpally. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4129) 4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2). D. Moberg, R. Drummond. July 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4130) 4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus. S. Green, K. Ozawa, E. Cardona, Ed., A. Katsnelson. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4131) 4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS). S. Moriai, A. Kato, M. Kanda. July 2005. (Format: TXT, HTML) (Obsoleted by RFC5932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4132) 4133 Entity MIB (Version 3). A. Bierman, K. McCloghrie. August 2005. (Format: TXT, HTML) (Obsoletes RFC2737) (Obsoleted by RFC6933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4133) 4134 Examples of S/MIME Messages. P. Hoffman, Ed.. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4134) 4135 Goals of Detecting Network Attachment in IPv6. JH. Choi, G. Daley. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4135) 4136 OSPF Refresh and Flooding Reduction in Stable Topologies. P. Pillay-Esnault. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4136) 4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator. J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba. August 2005. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4137) 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP). P. Sarolahti, M. Kojo. August 2005. (Format: TXT, HTML) (Updated by RFC5682) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4138) 4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON). D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong. July 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4139) 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6). H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. August 2005. (Format: TXT, HTML) (Obsoleted by RFC5380) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4140) 4141 SMTP and MIME Extensions for Content Conversion. K. Toyoda, D. Crocker. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4141) 4142 Full-mode Fax Profile for Internet Mail (FFPIM). D. Crocker, G. Klyne. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4142) 4143 Facsimile Using Internet Mail (IFAX) Service of ENUM. K. Toyoda, D. Crocker. November 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4143) 4144 How to Gain Prominence and Influence in Standards Organizations. D. Eastlake 3rd. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4144) 4145 TCP-Based Media Transport in the Session Description Protocol (SDP). D. Yon, G. Camarillo. September 2005. (Format: TXT, HTML) (Updated by RFC4572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4145) 4146 Simple New Mail Notification. R. Gellens. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4146) 4147 Proposed Changes to the Format of the IANA IPv6 Registry. G. Huston. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4147) 4148 IP Performance Metrics (IPPM) Metrics Registry. E. Stephan. August 2005. (Format: TXT, HTML) (Obsoleted by RFC6248) (Also BCP0108) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4148) 4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms. C. Kalbfleisch, R. Cole, D. Romascanu. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4149) 4150 Transport Performance Metrics MIB. R. Dietz, R. Cole. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4150) 4151 The 'tag' URI Scheme. T. Kindberg, S. Hawke. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4151) 4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code. K. Tesink, R. Fox. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4152) 4153 XML Voucher: Generic Voucher Language. K. Fujimura, M. Terada, D. Eastlake 3rd. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4153) 4154 Voucher Trading System Application Programming Interface (VTS-API). M. Terada, K. Fujimura. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4154) 4155 The application/mbox Media Type. E. Hall. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4155) 4156 The wais URI Scheme. P. Hoffman. August 2005. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4156) 4157 The prospero URI Scheme. P. Hoffman. August 2005. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4157) 4158 Internet X.509 Public Key Infrastructure: Certification Path Building. M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4158) 4159 Deprecation of "ip6.int". G. Huston. August 2005. (Format: TXT, HTML) (Also BCP0109) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4159) 4160 Internet Fax Gateway Requirements. K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4160) 4161 Guidelines for Optional Services for Internet Fax Gateways. K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4161) 4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS). H.J. Lee, J.H. Yoon, J.I. Lee. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4162) 4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression. L-E. Jonsson. August 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4163) 4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles. G. Pelletier. August 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4164) 4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA). T. George, B. Bidulock, R. Dantu, H. Schwarzbauer, K. Morneault. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4165) 4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement. L. Coene, J. Pastor-Balbas. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4166) 4167 Graceful OSPF Restart Implementation Report. A. Lindem. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4167) 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, G. Camarillo. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4168) 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2. V. Torvinen, J. Arkko, M. Naslund. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4169) 4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T. Koren, D. Wing. November 2005. (Format: TXT, HTML) (Also BCP0110) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4170) 4171 Internet Storage Name Service (iSNS). J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza. September 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4171) 4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking. C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards. September 2005. (Format: TXT, HTML) (Updated by RFC6172, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4172) 4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol. P. Sarkar, D. Missimer, C. Sapuntzakis. September 2005. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4173) 4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service. C. Monia, J. Tseng, K. Gibbons. September 2005. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4174) 4175 RTP Payload Format for Uncompressed Video. L. Gharai, C. Perkins. September 2005. (Format: TXT, HTML) (Updated by RFC4421) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4175) 4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management. Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4176) 4177 Architectural Approaches to Multi-homing for IPv6. G. Huston. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4177) 4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism. L. Zhu, P. Leach, K. Jaganathan, W. Ingersoll. October 2005. (Format: TXT, HTML) (Obsoletes RFC2478) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4178) 4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN). S. Kang. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4179) 4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files. Y. Shafranovich. October 2005. (Format: TXT, HTML) (Updated by RFC7111) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4180) 4181 Guidelines for Authors and Reviewers of MIB Documents. C. Heard, Ed.. September 2005. (Format: TXT, HTML) (Updated by RFC4841) (Also BCP0111) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4181) 4182 Removing a Restriction on the use of MPLS Explicit NULL. E. Rosen. September 2005. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4182) 4183 A Suggested Scheme for DNS Resolution of Networks and Gateways. E. Warnicke. September 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4183) 4184 RTP Payload Format for AC-3 Audio. B. Link, T. Hager, J. Flaks. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4184) 4185 National and Local Characters for DNS Top Level Domain (TLD) Names. J. Klensin. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4185) 4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM). H. Haverinen, Ed., J. Salowey, Ed.. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4186) 4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). J. Arkko, H. Haverinen. January 2006. (Format: TXT, HTML) (Updated by RFC5448) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4187) 4188 Definitions of Managed Objects for Bridges. K. Norseth, Ed., E. Bell, Ed.. September 2005. (Format: TXT, HTML) (Obsoletes RFC1493) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4188) 4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP). K. Ono, S. Tachimoto. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4189) 4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony. K. Carlberg, I. Brown, C. Beard. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4190) 4191 Default Router Preferences and More-Specific Routes. R. Draves, D. Thaler. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4191) 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT, HTML) (Updates RFC2072) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4192) 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4193) 4194 The S Hexdump Format. J. Strombergson, L. Walleij, P. Faltstrom. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4194) 4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum. W. Kameyama. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4195) 4196 The SEED Cipher Algorithm and Its Use with IPsec. H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4196) 4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks. M. Riegel, Ed.. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4197) 4198 A Uniform Resource Name (URN) Namespace for Federated Content. D. Tessman. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4198) 4199 Not Issued. 4200 Not Issued. 4201 Link Bundling in MPLS Traffic Engineering (TE). K. Kompella, Y. Rekhter, L. Berger. October 2005. (Format: TXT, HTML) (Updates RFC3471, RFC3472, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4201) 4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT, HTML) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4202) 4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT, HTML) (Updates RFC3630) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4203) 4204 Link Management Protocol (LMP). J. Lang, Ed.. October 2005. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4204) 4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2005. (Format: TXT, HTML) (Obsoleted by RFC5307) (Updates RFC3784) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4205) 4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE). K. Kompella, Y. Rekhter. October 2005. (Format: TXT, HTML) (Updated by RFC6001, RFC6107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4206) 4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages. J. Lang, D. Papadimitriou. October 2005. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4207) 4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model. G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4208) 4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems. A. Fredette, Ed., J. Lang, Ed.. October 2005. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4209) 4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). C. Adams, S. Farrell, T. Kause, T. Mononen. September 2005. (Format: TXT, HTML) (Obsoletes RFC2510) (Updated by RFC6712) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4210) 4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). J. Schaad. September 2005. (Format: TXT, HTML) (Obsoletes RFC2511) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4211) 4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols. M. Blinov, C. Adams. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4212) 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT, HTML) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213) 4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T. Gleeson, M. Talwar, D. Thaler. October 2005. (Format: TXT, HTML) (Obsoleted by RFC5214) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4214) 4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks. J. Wiljakka, Ed.. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4215) 4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements. R. Zhang, Ed., J.-P. Vasseur, Ed.. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4216) 4217 Securing FTP with TLS. P. Ford-Hutchinson. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4217) 4218 Threats Relating to IPv6 Multihoming Solutions. E. Nordmark, T. Li. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4218) 4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About. E. Lear. October 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4219) 4220 Traffic Engineering Link Management Information Base. M. Dubuc, T. Nadeau, J. Lang. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4220) 4221 Multiprotocol Label Switching (MPLS) Management Overview. T. Nadeau, C. Srinivasan, A. Farrel. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4221) 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance. G. Choudhury, Ed.. October 2005. (Format: TXT, HTML) (Also BCP0112) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4222) 4223 Reclassification of RFC 1863 to Historic. P. Savola. October 2005. (Format: TXT, HTML) (Obsoletes RFC1863) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4223) 4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets. G. Pelletier, L-E. Jonsson, K. Sandlund. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4224) 4225 Mobile IP Version 6 Route Optimization Security Design Background. P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4225) 4226 HOTP: An HMAC-Based One-Time Password Algorithm. D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4226) 4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP). E. O'Tuathail, M. Rose. January 2006. (Format: TXT, HTML) (Obsoletes RFC3288) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4227) 4228 Requirements for an IETF Draft Submission Toolset. A. Rousskov. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4228) 4229 HTTP Header Field Registrations. M. Nottingham, J. Mogul. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4229) 4230 RSVP Security Properties. H. Tschofenig, R. Graveman. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4230) 4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. M. Nystrom. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4231) 4232 Not Issued. 4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer. K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. January 2006. (Format: TXT, HTML) (Obsoletes RFC3057) (Updated by RFC5133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4233) 4234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. October 2005. (Format: TXT, HTML) (Obsoletes RFC2234) (Obsoleted by RFC5234) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4234) 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, R. Mahy, Ed.. November 2005. (Format: TXT, HTML) (Updated by RFC7463) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4235) 4236 HTTP Adaptation with Open Pluggable Edge Services (OPES). A. Rousskov, M. Stecher. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4236) 4237 Voice Messaging Directory Service. G. Vaudreuil. October 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4237) 4238 Voice Message Routing Service. G. Vaudreuil. October 2005. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4238) 4239 Internet Voice Messaging (IVM). S. McRae, G. Parsons. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4239) 4240 Basic Network Media Services with SIP. E. Burger, Ed., J. Van Dyke, A. Spitzer. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4240) 4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service. Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4241) 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). S. Venaas, T. Chown, B. Volz. November 2005. (Format: TXT, HTML) (Obsoleted by RFC8415) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4242) 4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option. M. Stapp, R. Johnson, T. Palaniappan. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4243) 4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information. M. Barnes, Ed.. November 2005. (Format: TXT, HTML) (Obsoleted by RFC7044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4244) 4245 High-Level Requirements for Tightly Coupled SIP Conferencing. O. Levin, R. Even. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4245) 4246 International Standard Audiovisual Number (ISAN) URN Definition. M. Dolan. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4246) 4247 Requirements for Header Compression over MPLS. J. Ash, B. Goode, J. Hand, R. Zhang. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4247) 4248 The telnet URI Scheme. P. Hoffman. October 2005. (Format: TXT, HTML) (Obsoletes RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4248) 4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components. B. Lilly. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4249) 4250 The Secure Shell (SSH) Protocol Assigned Numbers. S. Lehtinen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8268) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4250) 4251 The Secure Shell (SSH) Protocol Architecture. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4251) 4252 The Secure Shell (SSH) Authentication Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308, RFC8332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4252) 4253 The Secure Shell (SSH) Transport Layer Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC6668, RFC8268, RFC8308, RFC8332, RFC8709, RFC8758) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4253) 4254 The Secure Shell (SSH) Connection Protocol. T. Ylonen, C. Lonvick, Ed.. January 2006. (Format: TXT, HTML) (Updated by RFC8308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4254) 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints. J. Schlyter, W. Griffin. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4255) 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH). F. Cusack, M. Forssen. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4256) 4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks. G. Bernstein, E. Mannie, V. Sharma, E. Gray. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4257) 4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON). D. Brungard, Ed.. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4258) 4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks. M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4259) 4260 Mobile IPv6 Fast Handovers for 802.11 Networks. P. McCann. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4260) 4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS). J. Walker, A. Kulkarni, Ed.. December 2005. (Format: TXT, HTML) (Updates RFC2748) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4261) 4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities. S. Santesson. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4262) 4263 Media Subtype Registration for Media Type text/troff. B. Lilly. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4263) 4264 BGP Wedgies. T. Griffin, G. Huston. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4264) 4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management. B. Schliesser, T. Nadeau. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4265) 4266 The gopher URI Scheme. P. Hoffman. November 2005. (Format: TXT, HTML) (Obsoletes RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4266) 4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml. M. Froumentin. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4267) 4268 Entity State MIB. S. Chisholm, D. Perkins. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4268) 4269 The SEED Encryption Algorithm. H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee. December 2005. (Format: TXT, HTML) (Obsoletes RFC4009) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4269) 4270 Attacks on Cryptographic Hashes in Internet Protocols. P. Hoffman, B. Schneier. November 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4270) 4271 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.. January 2006. (Format: TXT, HTML) (Obsoletes RFC1771) (Updated by RFC6286, RFC6608, RFC6793, RFC7606, RFC7607, RFC7705, RFC8212, RFC8654) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4271) 4272 BGP Security Vulnerabilities Analysis. S. Murphy. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4272) 4273 Definitions of Managed Objects for BGP-4. J. Haas, Ed., S. Hares, Ed.. January 2006. (Format: TXT, HTML) (Obsoletes RFC1269, RFC1657) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4273) 4274 BGP-4 Protocol Analysis. D. Meyer, K. Patel. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4274) 4275 BGP-4 MIB Implementation Survey. S. Hares, D. Hares. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4275) 4276 BGP-4 Implementation Report. S. Hares, A. Retana. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4276) 4277 Experience with the BGP-4 Protocol. D. McPherson, K. Patel. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4277) 4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification. S. Bellovin, A. Zinin. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4278) 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4279) 4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers. K. Chowdhury, P. Yegani, L. Madour. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4280) 4281 The Codecs Parameter for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. November 2005. (Format: TXT, HTML) (Obsoleted by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4281) 4282 The Network Access Identifier. B. Aboba, M. Beadles, J. Arkko, P. Eronen. December 2005. (Format: TXT, HTML) (Obsoletes RFC2486) (Obsoleted by RFC7542) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4282) 4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6). A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. November 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4283) 4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP). F. Adrangi, V. Lortz, F. Bari, P. Eronen. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4284) 4285 Authentication Protocol for Mobile IPv6. A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4285) 4286 Multicast Router Discovery. B. Haberman, J. Martin. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4286) 4287 The Atom Syndication Format. M. Nottingham, Ed., R. Sayre, Ed.. December 2005. (Format: TXT, HTML) (Updated by RFC5988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4287) 4288 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT, HTML) (Obsoletes RFC2048) (Obsoleted by RFC6838) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4288) 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT, HTML) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4289) 4290 Suggested Practices for Registration of Internationalized Domain Names (IDN). J. Klensin. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4290) 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering. February 2006. (Format: TXT, HTML) (Obsoletes RFC3513) (Updated by RFC5952, RFC6052, RFC7136, RFC7346, RFC7371, RFC8064) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4291) 4292 IP Forwarding Table MIB. B. Haberman. April 2006. (Format: TXT, HTML) (Obsoletes RFC2096) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4292) 4293 Management Information Base for the Internet Protocol (IP). S. Routhier, Ed.. April 2006. (Format: TXT, HTML) (Obsoletes RFC2011, RFC2465, RFC2466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4293) 4294 IPv6 Node Requirements. J. Loughney, Ed.. April 2006. (Format: TXT, HTML) (Obsoleted by RFC6434) (Updated by RFC5095) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4294) 4295 Mobile IPv6 Management Information Base. G. Keeni, K. Koide, K. Nagami, S. Gundavelli. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4295) 4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols. S. Bailey, T. Talpey. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4296) 4297 Remote Direct Memory Access (RDMA) over IP Problem Statement. A. Romanow, J. Mogul, T. Talpey, S. Bailey. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4297) 4298 RTP Payload Format for BroadVoice Speech Codecs. J.-H. Chen, W. Lee, J. Thyssen. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4298) 4299 Not Issued. 4300 Not Issued. 4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo. December 2005. (Format: TXT, HTML) (Obsoletes RFC2401) (Updates RFC3168) (Updated by RFC6040, RFC7619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4301) 4302 IP Authentication Header. S. Kent. December 2005. (Format: TXT, HTML) (Obsoletes RFC2402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4302) 4303 IP Encapsulating Security Payload (ESP). S. Kent. December 2005. (Format: TXT, HTML) (Obsoletes RFC2406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4303) 4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP). S. Kent. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4304) 4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. Eastlake 3rd. December 2005. (Format: TXT, HTML) (Obsoletes RFC2402, RFC2406) (Obsoleted by RFC4835) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4305) 4306 Internet Key Exchange (IKEv2) Protocol. C. Kaufman, Ed.. December 2005. (Format: TXT, HTML) (Obsoletes RFC2407, RFC2408, RFC2409) (Obsoleted by RFC5996) (Updated by RFC5282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4306) 4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2). J. Schiller. December 2005. (Format: TXT, HTML) (Obsoleted by RFC8247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4307) 4308 Cryptographic Suites for IPsec. P. Hoffman. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4308) 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP). R. Housley. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4309) 4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). S. Hollenbeck. December 2005. (Format: TXT, HTML) (Obsoleted by RFC5910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4310) 4311 IPv6 Host-to-Router Load Sharing. R. Hinden, D. Thaler. November 2005. (Format: TXT, HTML) (Updates RFC2461) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4311) 4312 The Camellia Cipher Algorithm and Its Use With IPsec. A. Kato, S. Moriai, M. Kanda. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4312) 4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources. D. Oran. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4313) 4314 IMAP4 Access Control List (ACL) Extension. A. Melnikov. December 2005. (Format: TXT, HTML) (Obsoletes RFC2086) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4314) 4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension. M. Crispin. December 2005. (Format: TXT, HTML) (Obsoletes RFC2359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4315) 4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties. J. Reschke. December 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4316) 4317 Session Description Protocol (SDP) Offer/Answer Examples. A. Johnston, R. Sparks. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4317) 4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol. D. Levi, D. Harrington. December 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4318) 4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines. C. Sikes, B. Ray, R. Abbi. December 2005. (Format: TXT, HTML) (Obsoletes RFC3276) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4319) 4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction. R. Sparks. January 2006. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4320) 4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction. R. Sparks. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4321) 4322 Opportunistic Encryption using the Internet Key Exchange (IKE). M. Richardson, D.H. Redelmeier. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4322) 4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB). M. Patrick, W. Murwin. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4323) 4324 Calendar Access Protocol (CAP). D. Royer, G. Babics, S. Mansour. December 2005. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4324) 4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension. S. Santesson, R. Housley. December 2005. (Format: TXT, HTML) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4325) 4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS). G. Fairhurst, B. Collini-Nocker. December 2005. (Format: TXT, HTML) (Updated by RFC7280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4326) 4327 Link Management Protocol (LMP) Management Information Base (MIB). M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. January 2006. (Format: TXT, HTML) (Obsoleted by RFC4631) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4327) 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control. D. Papadimitriou, Ed.. January 2006. (Format: TXT, HTML) (Updates RFC3471) (Updated by RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4328) 4329 Scripting Media Types. B. Hoehrmann. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4329) 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. January 2006. (Format: TXT, HTML) (Obsoletes RFC2030, RFC1769) (Obsoleted by RFC5905) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4330) 4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections. B. Korver, L. Dusseault. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4331) 4332 Cisco's Mobile IPv4 Host Configuration Extensions. K. Leung, A. Patel, G. Tsirtsis, E. Klovning. December 2005. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4332) 4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process. G. Huston, Ed., B. Wijnen, Ed.. December 2005. (Format: TXT, HTML) (Obsoleted by RFC8711) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4333) 4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN). R. Housley, T. Moore. February 2006. (Format: TXT, HTML) (Obsoletes RFC3770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4334) 4335 The Secure Shell (SSH) Session Channel Break Extension. J. Galbraith, P. Remaker. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4335) 4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP). S. Floyd, M. Handley, E. Kohler. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4336) 4337 MIME Type Registration for MPEG-4. Y Lim, D. Singer. March 2006. (Format: TXT, HTML) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4337) 4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel. C. DeSanti, C. Carlson, R. Nixon. January 2006. (Format: TXT, HTML) (Obsoletes RFC3831, RFC2625) (Updated by RFC5494, RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4338) 4339 IPv6 Host Configuration of DNS Server Information Approaches. J. Jeong, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4339) 4340 Datagram Congestion Control Protocol (DCCP). E. Kohler, M. Handley, S. Floyd. March 2006. (Format: TXT, HTML) (Updated by RFC5595, RFC5596, RFC6335, RFC6773) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4340) 4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control. S. Floyd, E. Kohler. March 2006. (Format: TXT, HTML) (Updated by RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4341) 4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). S. Floyd, E. Kohler, J. Padhye. March 2006. (Format: TXT, HTML) (Updated by RFC5348, RFC6323, RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4342) 4343 Domain Name System (DNS) Case Insensitivity Clarification. D. Eastlake 3rd. January 2006. (Format: TXT, HTML) (Updates RFC1034, RFC1035, RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4343) 4344 The Secure Shell (SSH) Transport Layer Encryption Modes. M. Bellare, T. Kohno, C. Namprempre. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4344) 4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4345) 4346 The Transport Layer Security (TLS) Protocol Version 1.1. T. Dierks, E. Rescorla. April 2006. (Format: TXT, HTML) (Obsoletes RFC2246) (Obsoleted by RFC5246) (Updated by RFC4366, RFC4680, RFC4681, RFC5746, RFC6176, RFC7465, RFC7507, RFC7919) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4346) 4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu. April 2006. (Format: TXT, HTML) (Obsoleted by RFC6347) (Updated by RFC5746, RFC7507) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4347) 4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec. S. Ahmadi. January 2006. (Format: TXT, HTML) (Updated by RFC4424) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4348) 4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3). C. Pignataro, M. Townsley. February 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4349) 4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government. F. Hendrikx, C. Wallis. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4350) 4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream. G. Hellstrom, P. Jones. January 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4351) 4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec. J. Sjoberg, M. Westerlund, A. Lakaniemi, S. Wenger. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4352) 4353 A Framework for Conferencing with the Session Initiation Protocol (SIP). J. Rosenberg. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4353) 4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service. M. Garcia-Martin. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4354) 4355 IANA Registration for Enumservices email, fax, mms, ems, and sms. R. Brandner, L. Conroy, R. Stastny. January 2006. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4355) 4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail. R. Gellens. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4356) 4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms. V. Popov, I. Kurepkin, S. Leontiev. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4357) 4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA). D. Smith. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4358) 4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH). B. Weis. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4359) 4360 BGP Extended Communities Attribute. S. Sangli, D. Tappan, Y. Rekhter. February 2006. (Format: TXT, HTML) (Updated by RFC7153, RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4360) 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). T. Lemon, B. Sommerfeld. February 2006. (Format: TXT, HTML) (Updates RFC2131, RFC2132, RFC3315) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4361) 4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP. L-E. Jonsson, G. Pelletier, K. Sandlund. January 2006. (Format: TXT, HTML) (Obsoletes RFC3242) (Updated by RFC4815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4362) 4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions. D. Levi, D. Harrington. January 2006. (Format: TXT, HTML) (Obsoletes RFC2674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4363) 4364 BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, Y. Rekhter. February 2006. (Format: TXT, HTML) (Obsoletes RFC2547) (Updated by RFC4577, RFC4684, RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4364) 4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4365) 4366 Transport Layer Security (TLS) Extensions. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. April 2006. (Format: TXT, HTML) (Obsoletes RFC3546) (Obsoleted by RFC5246, RFC6066) (Updates RFC4346) (Updated by RFC5746) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4366) 4367 What's in a Name: False Assumptions about DNS Names. J. Rosenberg, Ed., IAB. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4367) 4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition. T. Nadeau, S. Hegde. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4368) 4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP). K. Gibbons, C. Monia, J. Tseng, F. Travostino. January 2006. (Format: TXT, HTML) (Obsoleted by RFC6173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4369) 4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control. R. Weltman. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4370) 4371 BCP 101 Update for IPR Trust. B. Carpenter, Ed., L. Lynch, Ed.. January 2006. (Format: TXT, HTML) (Obsoleted by RFC8714) (Updates RFC4071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4371) 4372 Chargeable User Identity. F. Adrangi, A. Lior, J. Korhonen, J. Loughney. January 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4372) 4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP). R. Harrison, J. Sermersheim, Y. Dong. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4373) 4374 The application/xv+xml Media Type. G. McCobb. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4374) 4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain. K. Carlberg. January 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4375) 4376 Requirements for Floor Control Protocols. P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4376) 4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks. T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4377) 4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM). D. Allan, Ed., T. Nadeau, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4378) 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. K. Kompella, G. Swallow. February 2006. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC1122) (Updated by RFC5462, RFC6424, RFC6425, RFC6426, RFC6829, RFC7506, RFC7537, RFC7743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4379) 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). C. Huitema. February 2006. (Format: TXT, HTML) (Updated by RFC5991, RFC6081) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4380) 4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs). M. Behringer. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4381) 4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base. T. Nadeau, Ed., H. van der Linde, Ed.. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4382) 4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP). M. Baugher, E. Carrara. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4383) 4384 BGP Communities for Data Collection. D. Meyer. February 2006. (Format: TXT, HTML) (Also BCP0114) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4384) 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN. S. Bryant, G. Swallow, L. Martini, D. McPherson. February 2006. (Format: TXT, HTML) (Updated by RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4385) 4386 Internet X.509 Public Key Infrastructure Repository Locator Service. S. Boeyen, P. Hallam-Baker. February 2006. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4386) 4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP. P. Gutmann, Ed.. February 2006. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4387) 4388 Dynamic Host Configuration Protocol (DHCP) Leasequery. R. Woundy, K. Kinnear. February 2006. (Format: TXT, HTML) (Updated by RFC6148) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4388) 4389 Neighbor Discovery Proxies (ND Proxy). D. Thaler, M. Talwar, C. Patel. April 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4389) 4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand. V. Kashyap. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4390) 4391 Transmission of IP over InfiniBand (IPoIB). J. Chu, V. Kashyap. April 2006. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4391) 4392 IP over InfiniBand (IPoIB) Architecture. V. Kashyap. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4392) 4393 MIME Type Registrations for 3GPP2 Multimedia Files. H. Garudadri. March 2006. (Format: TXT, HTML) (Updated by RFC6381) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4393) 4394 A Transport Network View of the Link Management Protocol (LMP). D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4394) 4395 Guidelines and Registration Procedures for New URI Schemes. T. Hansen, T. Hardie, L. Masinter. February 2006. (Format: TXT, HTML) (Obsoletes RFC2717, RFC2718) (Obsoleted by RFC7595) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4395) 4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text. J. Rey, Y. Matsui. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4396) 4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture. I. Bryskin, A. Farrel. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4397) 4398 Storing Certificates in the Domain Name System (DNS). S. Josefsson. March 2006. (Format: TXT, HTML) (Obsoletes RFC2538) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4398) 4399 Not Issued. 4400 Not Issued. 4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API). N. Williams. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4401) 4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism. N. Williams. February 2006. (Format: TXT, HTML) (Obsoleted by RFC7802) (Status: HISTORIC) (DOI: 10.17487/RFC4402) 4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3). B. Bergeson, K. Boogert, V. Nanjundaswamy. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4403) 4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP). R. Natarajan, A. Rijhsinghani. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4404) 4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message. E. Allman, H. Katz. April 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4405) 4406 Sender ID: Authenticating E-Mail. J. Lyon, M. Wong. April 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4406) 4407 Purported Responsible Address in E-Mail Messages. J. Lyon. April 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4407) 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1. M. Wong, W. Schlitt. April 2006. (Format: TXT, HTML) (Obsoleted by RFC7208) (Updated by RFC6652) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4408) 4409 Message Submission for Mail. R. Gellens, J. Klensin. April 2006. (Format: TXT, HTML) (Obsoletes RFC2476) (Obsoleted by RFC6409) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4409) 4410 Selectively Reliable Multicast Protocol (SRMP). M. Pullen, F. Zhao, D. Cohen. February 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4410) 4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events. J. Polk. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4411) 4412 Communications Resource Priority for the Session Initiation Protocol (SIP). H. Schulzrinne, J. Polk. February 2006. (Format: TXT, HTML) (Updated by RFC7134) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4412) 4413 TCP/IP Field Behavior. M. West, S. McCann. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4413) 4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS). A. Newton. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4414) 4415 IANA Registration for Enumservice Voice. R. Brandner, L. Conroy, R. Stastny. February 2006. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4415) 4416 Goals for Internet Messaging to Support Diverse Service Environments. J. Wong, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4416) 4417 Report of the 2004 IAB Messaging Workshop. P. Resnick, Ed., P. Saint-Andre, Ed.. February 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4417) 4418 UMAC: Message Authentication Code using Universal Hashing. T. Krovetz, Ed.. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4418) 4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol. M. Friedl, N. Provos, W. Simpson. March 2006. (Format: TXT, HTML) (Updated by RFC8270) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4419) 4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). A. Farrel, Ed., D. Papadimitriou, J.-P. Vasseur, A. Ayyangar. February 2006. (Format: TXT, HTML) (Obsoleted by RFC5420) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4420) 4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes. C. Perkins. February 2006. (Format: TXT, HTML) (Updates RFC4175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4421) 4422 Simple Authentication and Security Layer (SASL). A. Melnikov, Ed., K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4422) 4423 Host Identity Protocol (HIP) Architecture. R. Moskowitz, P. Nikander. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4423) 4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec. S. Ahmadi. February 2006. (Format: TXT, HTML) (Updates RFC4348) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4424) 4425 RTP Payload Format for Video Codec 1 (VC-1). A. Klemets. February 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4425) 4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification. J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed.. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4426) 4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS). E. Mannie, Ed., D. Papadimitriou, Ed.. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4427) 4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration). D. Papadimitriou, Ed., E. Mannie, Ed.. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4428) 4429 Optimistic Duplicate Address Detection (DAD) for IPv6. N. Moore. April 2006. (Format: TXT, HTML) (Updated by RFC7527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4429) 4430 Kerberized Internet Negotiation of Keys (KINK). S. Sakane, K. Kamada, M. Thomas, J. Vilhuber. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4430) 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record. M. Andrews, S. Weiler. February 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4431) 4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol. B. Harris. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4432) 4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment. M. Kulkarni, A. Patel, K. Leung. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4433) 4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE). P. Hoffman. February 2006. (Format: TXT, HTML) (Obsoletes RFC3664) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4434) 4435 A Framework for the Usage of Internet Media Guides (IMGs). Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4435) 4436 Detecting Network Attachment in IPv4 (DNAv4). B. Aboba, J. Carlson, S. Cheshire. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4436) 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources. J. Whitehead, G. Clemm, J. Reschke, Ed.. March 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4437) 4438 Fibre-Channel Name Server MIB. C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4438) 4439 Fibre Channel Fabric Address Manager MIB. C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4439) 4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF). S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4440) 4441 The IEEE 802/IETF Relationship. B. Aboba, Ed.. March 2006. (Format: TXT, HTML) (Obsoleted by RFC7241) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4441) 4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA). S. Fries, H. Tschofenig. March 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4442) 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M. Gupta, Ed.. March 2006. (Format: TXT, HTML) (Obsoletes RFC2463) (Updates RFC2780) (Updated by RFC4884) (Also STD0089) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4443) 4444 Management Information Base for Intermediate System to Intermediate System (IS-IS). J. Parker, Ed.. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4444) 4445 A Proposed Media Delivery Index (MDI). J. Welch, J. Clark. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4445) 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). L. Martini. April 2006. (Format: TXT, HTML) (Also BCP0116) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4446) 4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G. Heron. April 2006. (Format: TXT, HTML) (Obsoleted by RFC8077) (Updated by RFC6723, RFC6870, RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4447) 4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks. L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron. April 2006. (Format: TXT, HTML) (Updated by RFC5462, RFC8469) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4448) 4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key. C. Perkins. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4449) 4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents. E. Lear, H. Alvestrand. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4450) 4451 BGP MULTI_EXIT_DISC (MED) Considerations. D. McPherson, V. Gill. March 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4451) 4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces. H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4452) 4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D. Willis. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4453) 4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3). S. Singh, M. Townsley, C. Pignataro. May 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4454) 4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities. M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie. April 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4455) 4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP). T. Bates, E. Chen, R. Chandra. April 2006. (Format: TXT, HTML) (Obsoletes RFC2796, RFC1966) (Updated by RFC7606) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4456) 4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header). G. Camarillo, G. Blanco. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4457) 4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR). C. Jennings, F. Audet, J. Elwell. April 2006. (Format: TXT, HTML) (Updated by RFC8119) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4458) 4459 MTU and Fragmentation Issues with In-the-Network Tunneling. P. Savola. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4459) 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues. R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4460) 4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs). S. Yasukawa, Ed.. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4461) 4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol. J. Hutzelman, J. Salowey, J. Galbraith, V. Welch. May 2006. (Format: TXT, HTML) (Updated by RFC8732) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4462) 4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks. S. Shanmugham, P. Monaco, B. Eberman. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4463) 4464 Signaling Compression (SigComp) Users' Guide. A. Surtees, M. West. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4464) 4465 Signaling Compression (SigComp) Torture Tests. A. Surtees, M. West. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4465) 4466 Collected Extensions to IMAP4 ABNF. A. Melnikov, C. Daboo. April 2006. (Format: TXT, HTML) (Updates RFC2088, RFC2342, RFC3501, RFC3502, RFC3516) (Updated by RFC6237, RFC7377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4466) 4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension. M. Crispin. May 2006. (Format: TXT, HTML) (Updated by RFC5092, RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4467) 4468 Message Submission BURL Extension. C. Newman. May 2006. (Format: TXT, HTML) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4468) 4469 Internet Message Access Protocol (IMAP) CATENATE Extension. P. Resnick. April 2006. (Format: TXT, HTML) (Updates RFC3501, RFC3502) (Updated by RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4469) 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing. S. Weiler, J. Ihren. April 2006. (Format: TXT, HTML) (Updates RFC4035, RFC4034) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4470) 4471 Derivation of DNS Name Predecessor and Successor. G. Sisson, B. Laurie. September 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4471) 4472 Operational Considerations and Issues with IPv6 DNS. A. Durand, J. Ihren, P. Savola. April 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4472) 4473 Requirements for Internet Media Guides (IMGs). Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4473) 4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP). J. Peterson, C. Jennings. August 2006. (Format: TXT, HTML) (Obsoleted by RFC8224) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4474) 4475 Session Initiation Protocol (SIP) Torture Test Messages. R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4475) 4476 Attribute Certificate (AC) Policies Extension. C. Francis, D. Pinkas. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4476) 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues. T. Chown, S. Venaas, C. Strauf. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4477) 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol. Y. Nir. April 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4478) 4479 A Data Model for Presence. J. Rosenberg. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4479) 4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF). H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4480) 4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals. H. Schulzrinne. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4481) 4482 CIPID: Contact Information for the Presence Information Data Format. H. Schulzrinne. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4482) 4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages. E. Burger, Ed.. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4483) 4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP). J. Peterson, J. Polk, D. Sicker, H. Tschofenig. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4484) 4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4485) 4486 Subcodes for BGP Cease Notification Message. E. Chen, V. Gillet. April 2006. (Format: TXT, HTML) (Updated by RFC8203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4486) 4487 Mobile IPv6 and Firewalls: Problem Statement. F. Le, S. Faccin, B. Patil, H. Tschofenig. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4487) 4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription. O. Levin. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4488) 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses. J-S. Park, M-K. Shin, H-J. Kim. April 2006. (Format: TXT, HTML) (Updates RFC3306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4489) 4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS). S. Leontiev, Ed., G. Chudov, Ed.. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4490) 4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S. Leontiev, Ed., D. Shefanovski, Ed.. May 2006. (Format: TXT, HTML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4491) 4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS). S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller. May 2006. (Format: TXT, HTML) (Obsoleted by RFC8422) (Updated by RFC5246, RFC7027, RFC7919) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4492) 4493 The AES-CMAC Algorithm. JH. Song, R. Poovendran, J. Lee, T. Iwata. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4493) 4494 The AES-CMAC-96 Algorithm and Its Use with IPsec. JH. Song, R. Poovendran, J. Lee. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4494) 4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow. J. Polk, S. Dhesikan. May 2006. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4495) 4496 Open Pluggable Edge Services (OPES) SMTP Use Cases. M. Stecher, A. Barbir. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4496) 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG. J. Elwell, F. Derks, P. Mourot, O. Rousseau. May 2006. (Format: TXT, HTML) (Also BCP0117) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4497) 4498 The Managed Object Aggregation MIB. G. Keeni. May 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4498) 4499 Not Issued. 4500 Not Issued. 4501 Domain Name System Uniform Resource Identifiers. S. Josefsson. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4501) 4502 Remote Network Monitoring Management Information Base Version 2. S. Waldbusser. May 2006. (Format: TXT, HTML) (Obsoletes RFC2021) (Updates RFC3273) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4502) 4503 A Description of the Rabbit Stream Cipher Algorithm. M. Boesgaard, M. Vesterager, E. Zenner. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4503) 4504 SIP Telephony Device Requirements and Configuration. H. Sinnreich, Ed., S. Lass, C. Stredicke. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4504) 4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC2245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4505) 4506 XDR: External Data Representation Standard. M. Eisler, Ed.. May 2006. (Format: TXT, HTML) (Obsoletes RFC1832) (Also STD0067) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC4506) 4507 Transport Layer Security (TLS) Session Resumption without Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. May 2006. (Format: TXT, HTML) (Obsoleted by RFC5077) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4507) 4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method. O. Levin, A. Johnston. May 2006. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4508) 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs). W. Hardaker. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4509) 4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830, RFC3377, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4510) 4511 Lightweight Directory Access Protocol (LDAP): The Protocol. J. Sermersheim, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2830, RFC3771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4511) 4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4512) 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms. R. Harrison, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2251, RFC2829, RFC2830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4513) 4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4514) 4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters. M. Smith, Ed., T. Howes. June 2006. (Format: TXT, HTML) (Obsoletes RFC2254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4515) 4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator. M. Smith, Ed., T. Howes. June 2006. (Format: TXT, HTML) (Obsoletes RFC2255) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4516) 4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules. S. Legg, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2252, RFC2256) (Updates RFC3698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4517) 4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4518) 4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4519) 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC3383) (Also BCP0064) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4520) 4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions. K. Zeilenga. June 2006. (Format: TXT, HTML) (Also BCP0118) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4521) 4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option. S. Legg. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4522) 4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates. K. Zeilenga. June 2006. (Format: TXT, HTML) (Obsoletes RFC2252, RFC2256, RFC2587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4523) 4524 COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC1274) (Updates RFC2247, RFC2798) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4524) 4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4525) 4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4526) 4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4527) 4528 Lightweight Directory Access Protocol (LDAP) Assertion Control. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4528) 4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4529) 4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4530) 4531 Lightweight Directory Access Protocol (LDAP) Turn Operation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4531) 4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation. K. Zeilenga. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4532) 4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. K. Zeilenga, J.H. Choi. June 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4533) 4534 Group Security Policy Token v1. A Colegrove, H Harney. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4534) 4535 GSAKMP: Group Secure Association Key Management Protocol. H. Harney, U. Meth, A. Colegrove, G. Gross. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4535) 4536 The application/smil and application/smil+xml Media Types. P. Hoschka. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4536) 4537 Kerberos Cryptosystem Negotiation Extension. L. Zhu, P. Leach, K. Jaganathan. June 2006. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4537) 4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP). J. Rosenberg. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4538) 4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). T. Edwards. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4539) 4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0. M. Stiemerling, J. Quittek, C. Cadar. May 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4540) 4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. M. Christensen, K. Kimball, F. Solensky. May 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4541) 4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite. F. Baker, J. Polk. May 2006. (Format: TXT, HTML) (Updated by RFC5865) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4542) 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH. D. McGrew, J. Viega. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4543) 4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI). M. Bakke, M. Krueger, T. McSweeney, J. Muchow. May 2006. (Format: TXT, HTML) (Obsoleted by RFC7147) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4544) 4545 Definitions of Managed Objects for IP Storage User Identity Authorization. M. Bakke, J. Muchow. May 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4545) 4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces. D. Raftus, E. Cardona. June 2006. (Format: TXT, HTML) (Obsoletes RFC2670) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4546) 4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems. A. Ahmad, G. Nakanishi. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4547) 4548 Internet Code Point (ICP) Assignments for NSAP Addresses. E. Gray, J. Rutemiller, G. Swallow. May 2006. (Format: TXT, HTML) (Updates RFC1888, RFC4048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4548) 4549 Synchronization Operations for Disconnected IMAP4 Clients. A. Melnikov, Ed.. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4549) 4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile. S. Maes, A. Melnikov. June 2006. (Format: TXT, HTML) (Obsoleted by RFC5550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4550) 4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization. A. Melnikov, S. Hole. June 2006. (Format: TXT, HTML) (Obsoleted by RFC7162) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4551) 4552 Authentication/Confidentiality for OSPFv3. M. Gupta, N. Melam. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4552) 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP). A. Vainshtein, Ed., YJ. Stein, Ed.. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4553) 4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks. T. Chown. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4554) 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). P. Eronen. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4555) 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, B. Tung. June 2006. (Format: TXT, HTML) (Updated by RFC6112, RFC8062, RFC8636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4556) 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, K. Jaganathan, N. Williams. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4557) 4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement. Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4558) 4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4559) 4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. J. Quittek, Ed., K. White, Ed.. June 2006. (Format: TXT, HTML) (Obsoletes RFC2925) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4560) 4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object. J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4561) 4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network. T. Melsen, S. Blake. June 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4562) 4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY). E. Carrara, V. Lehtovirta, K. Norrman. June 2006. (Format: TXT, HTML) (Updated by RFC6309) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4563) 4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP). S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4564) 4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols. D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4565) 4566 SDP: Session Description Protocol. M. Handley, V. Jacobson, C. Perkins. July 2006. (Format: TXT, HTML) (Obsoletes RFC2327, RFC3266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4566) 4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP). J. Arkko, F. Lindholm, M. Naslund, K. Norrman, E. Carrara. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4567) 4568 Session Description Protocol (SDP) Security Descriptions for Media Streams. F. Andreasen, M. Baugher, D. Wing. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4568) 4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag. G. Camarillo. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4569) 4570 Session Description Protocol (SDP) Source Filters. B. Quinn, R. Finlayson. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4570) 4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport. J. Lazzaro. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4571) 4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). J. Lennox. July 2006. (Format: TXT, HTML) (Obsoleted by RFC8122) (Updates RFC4145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4572) 4573 MIME Type Registration for RTP Payload Format for H.224. R. Even, A. Lochbaum. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4573) 4574 The Session Description Protocol (SDP) Label Attribute. O. Levin, G. Camarillo. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4574) 4575 A Session Initiation Protocol (SIP) Event Package for Conference State. J. Rosenberg, H. Schulzrinne, O. Levin, Ed.. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4575) 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4576) 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT, HTML) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4577) 4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE). M. Johnston, S. Venaas, Ed.. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4578) 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents. A. Johnston, O. Levin. August 2006. (Format: TXT, HTML) (Also BCP0119) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4579) 4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option. B. Volz. June 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4580) 4581 Cryptographically Generated Addresses (CGA) Extension Field Format. M. Bagnulo, J. Arkko. October 2006. (Format: TXT, HTML) (Updates RFC3972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4581) 4582 The Binary Floor Control Protocol (BFCP). G. Camarillo, J. Ott, K. Drage. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4582) 4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams. G. Camarillo. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4583) 4584 Extension to Sockets API for Mobile IPv6. S. Chakrabarti, E. Nordmark. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4584) 4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF). J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey. July 2006. (Format: TXT, HTML) (Updated by RFC5506, RFC8108) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4585) 4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations. C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4586) 4587 RTP Payload Format for H.261 Video Streams. R. Even. August 2006. (Format: TXT, HTML) (Obsoletes RFC2032) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4587) 4588 RTP Retransmission Payload Format. J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4588) 4589 Location Types Registry. H. Schulzrinne, H. Tschofenig. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4589) 4590 RADIUS Extension for Digest Authentication. B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. July 2006. (Format: TXT, HTML) (Obsoleted by RFC5090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4590) 4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3). M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. August 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4591) 4592 The Role of Wildcards in the Domain Name System. E. Lewis. July 2006. (Format: TXT, HTML) (Updates RFC1034, RFC2672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4592) 4593 Generic Threats to Routing Protocols. A. Barbir, S. Murphy, Y. Yang. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4593) 4594 Configuration Guidelines for DiffServ Service Classes. J. Babiarz, K. Chan, F. Baker. August 2006. (Format: TXT, HTML) (Updated by RFC5865, RFC8622) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4594) 4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol. F. Maino, D. Black. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4595) 4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension. J. Rosenberg, P. Kyzivat. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4596) 4597 Conferencing Scenarios. R. Even, N. Ismail. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4597) 4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio. B. Link. July 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4598) 4599 Not Issued. 4600 Not Issued. 4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas. August 2006. (Format: TXT, PDF, HTML) (Obsoletes RFC2362) (Obsoleted by RFC7761) (Updated by RFC5059, RFC5796, RFC6226) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4601) 4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis. T. Pusateri. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4602) 4603 Additional Values for the NAS-Port-Type Attribute. G. Zorn, G. Weber, R. Foltak. July 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4603) 4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast. H. Holbrook, B. Cain, B. Haberman. August 2006. (Format: TXT, HTML) (Updates RFC3376, RFC3810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4604) 4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying"). B. Fenner, H. He, B. Haberman, H. Sandick. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4605) 4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. E. Mannie, D. Papadimitriou. August 2006. (Format: TXT, HTML) (Obsoletes RFC3946) (Updated by RFC6344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4606) 4607 Source-Specific Multicast for IP. H. Holbrook, B. Cain. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4607) 4608 Source-Specific Protocol Independent Multicast in 232/8. D. Meyer, R. Rockell, G. Shepherd. August 2006. (Format: TXT, HTML) (Also BCP0120) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4608) 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements. P. Savola, R. Lehtonen, D. Meyer. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4609) 4610 Anycast-RP Using Protocol Independent Multicast (PIM). D. Farinacci, Y. Cai. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4610) 4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios. M. McBride, J. Meylor, D. Meyer. August 2006. (Format: TXT, HTML) (Also BCP0121) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4611) 4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration. P. Jones, H. Tamura. August 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4612) 4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI). P. Frojdh, U. Lindgren, M. Westerlund. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4613) 4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents. M. Duke, R. Braden, W. Eddy, E. Blanton. September 2006. (Format: TXT, HTML) (Obsoleted by RFC7414) (Updated by RFC6247) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4614) 4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE). J. Song, R. Poovendran, J. Lee, T. Iwata. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4615) 4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism. K. Zeilenga, Ed.. August 2006. (Format: TXT, HTML) (Updates RFC2595) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4616) 4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project. J. Kornijenko. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4617) 4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks. L. Martini, E. Rosen, G. Heron, A. Malis. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4618) 4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks. L. Martini, Ed., C. Kawa, Ed., A. Malis, Ed.. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4619) 4620 IPv6 Node Information Queries. M. Crawford, B. Haberman, Ed.. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4620) 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. T. Kivinen, H. Tschofenig. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4621) 4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. July 2006. (Format: TXT, HTML) (Obsoleted by RFC5122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4622) 4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly. A. Malis, M. Townsley. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4623) 4624 Multicast Source Discovery Protocol (MSDP) MIB. B. Fenner, D. Thaler. October 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4624) 4625 Fibre Channel Routing Information MIB. C. DeSanti, K. McCloghrie, S. Kode, S. Gai. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4625) 4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol. C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4626) 4627 The application/json Media Type for JavaScript Object Notation (JSON). D. Crockford. July 2006. (Format: TXT, HTML) (Obsoleted by RFC7159) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4627) 4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status. R. Even. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4628) 4629 RTP Payload Format for ITU-T Rec. H.263 Video. J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed.. January 2007. (Format: TXT, HTML) (Obsoletes RFC2429) (Updates RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4629) 4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, S. Santesson. August 2006. (Format: TXT, HTML) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4630) 4631 Link Management Protocol (LMP) Management Information Base (MIB). M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel. September 2006. (Format: TXT, HTML) (Obsoletes RFC4327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4631) 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT, HTML) (Obsoletes RFC1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4632) 4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists. S. Hartman. August 2006. (Format: TXT, HTML) (Updated by RFC8717) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4633) 4634 US Secure Hash Algorithms (SHA and HMAC-SHA). D. Eastlake 3rd, T. Hansen. July 2006. (Format: TXT, HTML) (Obsoleted by RFC6234) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4634) 4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers. D. Eastlake 3rd. August 2006. (Format: TXT, HTML) (Updates RFC2845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4635) 4636 Foreign Agent Error Extension for Mobile IPv4. C. Perkins. October 2006. (Format: TXT, HTML) (Updates RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4636) 4637 Not Issued. 4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE). P. Arberg, D. Kourkouzelis, M. Duckett, T. Anschutz, J. Moisand. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4638) 4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems. R. Woundy, K. Marez. December 2006. (Format: TXT, HTML) (Obsoletes RFC2669) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4639) 4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6). A. Patel, Ed., G. Giaretta, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4640) 4641 DNSSEC Operational Practices. O. Kolkman, R. Gieben. September 2006. (Format: TXT, HTML) (Obsoletes RFC2541) (Obsoleted by RFC6781) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4641) 4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). K. Murchison, J. Vinocur, C. Newman. October 2006. (Format: TXT, HTML) (Updated by RFC8143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4642) 4643 Network News Transfer Protocol (NNTP) Extension for Authentication. J. Vinocur, K. Murchison. October 2006. (Format: TXT, HTML) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4643) 4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds. J. Vinocur, K. Murchison. October 2006. (Format: TXT, HTML) (Updates RFC2980) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4644) 4645 Initial Language Subtag Registry. D. Ewell. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4645) 4646 Tags for Identifying Languages. A. Phillips, M. Davis. September 2006. (Format: TXT, HTML) (Obsoletes RFC3066) (Obsoleted by RFC5646) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4646) 4647 Matching of Language Tags. A. Phillips, M. Davis. September 2006. (Format: TXT, HTML) (Obsoletes RFC3066) (Also BCP0047) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4647) 4648 The Base16, Base32, and Base64 Data Encodings. S. Josefsson. October 2006. (Format: TXT, HTML) (Obsoletes RFC3548) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4648) 4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option. B. Volz. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4649) 4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY). M. Euchner. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4650) 4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization. C. Vogt, J. Arkko. February 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4651) 4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements. D. Papadimitriou, Ed., L.Ong, J. Sadler, S. Shew, D. Ward. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4652) 4653 Improving the Robustness of TCP to Non-Congestion Events. S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4653) 4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification. J. Widmer, M. Handley. August 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4654) 4655 A Path Computation Element (PCE)-Based Architecture. A. Farrel, J.-P. Vasseur, J. Ash. August 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4655) 4656 A One-way Active Measurement Protocol (OWAMP). S. Shalunov, B. Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006. (Format: TXT, HTML) (Updated by RFC7717, RFC7718, RFC8545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4656) 4657 Path Computation Element (PCE) Communication Protocol Generic Requirements. J. Ash, Ed., J.L. Le Roux, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4657) 4658 Not Issued. 4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN. J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4659) 4660 Functional Description of Event Notification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT, HTML) (Updated by RFC6665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4660) 4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering. H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4661) 4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists. A. B. Roach, B. Campbell, J. Rosenberg. August 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4662) 4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG. D. Harrington. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4663) 4664 Framework for Layer 2 Virtual Private Networks (L2VPNs). L. Andersson, Ed., E. Rosen, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4664) 4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks. W. Augustyn, Ed., Y. Serbest, Ed.. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4665) 4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA). K. Morneault, Ed., J. Pastor-Balbas, Ed.. September 2006. (Format: TXT, HTML) (Obsoletes RFC3332) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4666) 4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP). W. Luo. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4667) 4668 RADIUS Authentication Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2618) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4668) 4669 RADIUS Authentication Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2619) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4669) 4670 RADIUS Accounting Client MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2620) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4670) 4671 RADIUS Accounting Server MIB for IPv6. D. Nelson. August 2006. (Format: TXT, HTML) (Obsoletes RFC2621) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4671) 4672 RADIUS Dynamic Authorization Client MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4672) 4673 RADIUS Dynamic Authorization Server MIB. S. De Cnodder, N. Jonnala, M. Chiba. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4673) 4674 Requirements for Path Computation Element (PCE) Discovery. J.L. Le Roux, Ed.. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4674) 4675 RADIUS Attributes for Virtual LAN and Priority Support. P. Congdon, M. Sanchez, B. Aboba. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4675) 4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. October 2006. (Format: TXT, HTML) (Obsoleted by RFC4776) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4676) 4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force. P. Hoffman, S. Harris. September 2006. (Format: TXT, HTML) (Obsoletes RFC3160) (Obsoleted by RFC6722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4677) 4678 Server/Application State Protocol v1. A. Bivens. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4678) 4679 DSL Forum Vendor-Specific RADIUS Attributes. V. Mammoliti, G. Zorn, P. Arberg, R. Rennison. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4679) 4680 TLS Handshake Message for Supplemental Data. S. Santesson. October 2006. (Format: TXT, HTML) (Updates RFC4346) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4680) 4681 TLS User Mapping Extension. S. Santesson, A. Medvinsky, J. Ball. October 2006. (Format: TXT, HTML) (Updates RFC4346) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4681) 4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices. E. Nechamkin, J-F. Mule. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4682) 4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM). J. Park, J. Lee, H.. Lee, S. Park, T. Polk. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4683) 4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs). P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. November 2006. (Format: TXT, HTML) (Updates RFC4364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4684) 4685 Atom Threading Extensions. J. Snell. September 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4685) 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM). J. Fenton. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4686) 4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks. S. Yasukawa, A. Farrel, D. King, T. Nadeau. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4687) 4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. S. Rushing. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4688) 4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms. S. Poretsky, J. Perser, S. Erramilli, S. Khurana. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4689) 4690 Review and Recommendations for Internationalized Domain Names (IDNs). J. Klensin, P. Faltstrom, C. Karp, IAB. September 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4690) 4691 Guidelines for Acting as an IETF Liaison to Another Organization. L. Andersson, Ed.. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4691) 4692 Considerations on the IPv6 Host Density Metric. G. Huston. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4692) 4693 IETF Operational Notes. H. Alvestrand. October 2006. (Format: TXT, HTML) (Obsoleted by RFC6393) (Status: HISTORIC) (DOI: 10.17487/RFC4693) 4694 Number Portability Parameters for the "tel" URI. J. Yu. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4694) 4695 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT, HTML) (Obsoleted by RFC6295) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4695) 4696 An Implementation Guide for RTP MIDI. J. Lazzaro, J. Wawrzynek. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4696) 4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT, HTML) (Also BCP0123) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4697) 4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service. E. Gunduz, A. Newton, S. Kerr. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4698) 4699 Not Issued. 4700 Not Issued. 4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR). M. Stapp, T. Lemon, A. Gustafsson. October 2006. (Format: TXT, HTML) (Updated by RFC5494) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4701) 4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option. M. Stapp, B. Volz, Y. Rekhter. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4702) 4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients. M. Stapp, B. Volz. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4703) 4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option. B. Volz. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4704) 4705 GigaBeam High-Speed Radio Link Encryption. R. Housley, A. Corry. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4705) 4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2). M. Morgenstern, M. Dodge, S. Baillie, U. Bonollo. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4706) 4707 Netnews Administration System (NAS). P. Grau, V. Heinau, H. Schlichting, R. Schuettler. October 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4707) 4708 CellML Media Type. A. Miller. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4708) 4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers. J. Reschke. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4709) 4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4710) 4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB. A. Siddiqui, D. Romascanu, E. Golovinsky. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4711) 4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU). A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman,Y. Kim. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4712) 4713 Registration and Administration Recommendations for Chinese Domain Names. X. Lee, W. Mao, E. Chen, N. Hsu, J. Klensin. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4713) 4714 Requirements for IETF Technical Publication Service. A. Mankin, S. Hayes. October 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4714) 4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI. M. Munakata, S. Schubert, T. Ohba. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4715) 4716 The Secure Shell (SSH) Public Key File Format. J. Galbraith, R. Thayer. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4716) 4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks. L. Martini, J. Jayakumar, M. Bocci, N. El-Aawar, J. Brayley, G. Koleyni. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4717) 4718 IKEv2 Clarifications and Implementation Guidelines. P. Eronen, P. Hoffman. October 2006. (Format: TXT, HTML) (Obsoleted by RFC5996) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4718) 4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3). R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.. November 2006. (Format: TXT, HTML) (Updated by RFC5641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4719) 4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention. A. Malis, D. Allan, N. Del Regno. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4720) 4721 Mobile IPv4 Challenge/Response Extensions (Revised). C. Perkins, P. Calhoun, J. Bharatia. January 2007. (Format: TXT, HTML) (Obsoletes RFC3012) (Updates RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4721) 4722 Media Server Control Markup Language (MSCML) and Protocol. J. Van Dyke, E. Burger, Ed., A. Spitzer. November 2006. (Format: TXT, HTML) (Obsoleted by RFC5022) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4722) 4723 Registration of Media Type audio/mobile-xmf. T. Kosonen, T. White. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4723) 4724 Graceful Restart Mechanism for BGP. S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter. January 2007. (Format: TXT, HTML) (Updated by RFC8538) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4724) 4725 ENUM Validation Architecture. A. Mayrhofer, B. Hoeneisen. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4725) 4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. A. Farrel, J.-P. Vasseur, A. Ayyangar. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4726) 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. B. Fenner. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4727) 4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4. D. Johnson, Y. Hu, D. Maltz. February 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4728) 4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum. M. Abel. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4729) 4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML). E. Burger, M. Dolly. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4730) 4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned. A. Melnikov, D. Cridland. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4731) 4732 Internet Denial-of-Service Considerations. M. Handley, Ed., E. Rescorla, Ed., IAB. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4732) 4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT, HTML) (Obsoletes RFC2833) (Updated by RFC4734, RFC5244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4733) 4734 Definition of Events for Modem, Fax, and Text Telephony Signals. H. Schulzrinne, T. Taylor. December 2006. (Format: TXT, HTML) (Obsoletes RFC2833) (Updates RFC4733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4734) 4735 Example Media Types for Use in Documentation. T. Taylor. October 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4735) 4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP). JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4736) 4737 Packet Reordering Metrics. A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. November 2006. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4737) 4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). D. Ignjatic, L. Dondeti, F. Audet, P. Lin. November 2006. (Format: TXT, HTML) (Updates RFC3830) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4738) 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol. P. Eronen, J. Korhonen. November 2006. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4739) 4740 Diameter Session Initiation Protocol (SIP) Application. M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4740) 4741 NETCONF Configuration Protocol. R. Enns, Ed.. December 2006. (Format: TXT, HTML) (Obsoleted by RFC6241) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4741) 4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH). M. Wasserman, T. Goddard. December 2006. (Format: TXT, HTML) (Obsoleted by RFC6242) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4742) 4743 Using NETCONF over the Simple Object Access Protocol (SOAP). T. Goddard. December 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4743) 4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP). E. Lear, K. Crozier. December 2006. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4744) 4745 Common Policy: A Document Format for Expressing Privacy Preferences. H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, J. Rosenberg. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4745) 4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange. T. Clancy, W. Arbaugh. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4746) 4747 The Virtual Fabrics MIB. S. Kipp, G. Ramkumar, K. McCloghrie. November 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4747) 4748 RFC 3978 Update to Recognize the IETF Trust. S. Bradner, Ed.. October 2006. (Format: TXT, HTML) (Obsoleted by RFC5378) (Updates RFC3978) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4748) 4749 RTP Payload Format for the G.729.1 Audio Codec. A. Sollaud. October 2006. (Format: TXT, HTML) (Updated by RFC5459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4749) 4750 OSPF Version 2 Management Information Base. D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker. December 2006. (Format: TXT, HTML) (Obsoletes RFC1850) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4750) 4751 Not Issued. 4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism. A. Melnikov, Ed.. November 2006. (Format: TXT, HTML) (Obsoletes RFC2222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4752) 4753 ECP Groups For IKE and IKEv2. D. Fu, J. Solinas. January 2007. (Format: TXT, HTML) (Obsoleted by RFC5903) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4753) 4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA). D. Fu, J. Solinas. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4754) 4755 IP over InfiniBand: Connected Mode. V. Kashyap. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4755) 4756 Forward Error Correction Grouping Semantics in Session Description Protocol. A. Li. November 2006. (Format: TXT, HTML) (Obsoleted by RFC5956) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4756) 4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows. K. Jaganathan, L. Zhu, J. Brezak. December 2006. (Format: TXT, HTML) (Updated by RFC6649) (Status: HISTORIC) (DOI: 10.17487/RFC4757) 4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1. M. Nystroem. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4758) 4759 The ENUM Dip Indicator Parameter for the "tel" URI. R. Stastny, R. Shockey, L. Conroy. December 2006. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4759) 4760 Multiprotocol Extensions for BGP-4. T. Bates, R. Chandra, D. Katz, Y. Rekhter. January 2007. (Format: TXT, HTML) (Obsoletes RFC2858) (Updated by RFC7606) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4760) 4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling. K. Kompella, Ed., Y. Rekhter, Ed.. January 2007. (Format: TXT, HTML) (Updated by RFC5462, RFC8395, RFC8614) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4761) 4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling. M. Lasserre, Ed., V. Kompella, Ed.. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4762) 4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE). M. Vanderveen, H. Soliman. November 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4763) 4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method. F. Bersani, H. Tschofenig. January 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4764) 4765 The Intrusion Detection Message Exchange Format (IDMEF). H. Debar, D. Curry, B. Feinstein. March 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4765) 4766 Intrusion Detection Message Exchange Requirements. M. Wood, M. Erlinger. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4766) 4767 The Intrusion Detection Exchange Protocol (IDXP). B. Feinstein, G. Matthews. March 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4767) 4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming. S. Hartman. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4768) 4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information. J. Livingood, R. Shockey. November 2006. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4769) 4770 vCard Extensions for Instant Messaging (IM). C. Jennings, J. Reschke, Ed.. January 2007. (Format: TXT, HTML) (Obsoleted by RFC6350) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4770) 4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP). V. Lehtovirta, M. Naslund, K. Norrman. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4771) 4772 Security Implications of Using the Data Encryption Standard (DES). S. Kelly. December 2006. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4772) 4773 Administration of the IANA Special Purpose IPv6 Address Block. G. Huston. December 2006. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4773) 4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. S. Floyd. November 2006. (Format: TXT, HTML) (Updated by RFC6040) (Also BCP0124) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4774) 4775 Procedures for Protocol Extensions and Variations. S. Bradner, B. Carpenter, Ed., T. Narten. December 2006. (Format: TXT, HTML) (Also BCP0125) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4775) 4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. H. Schulzrinne. November 2006. (Format: TXT, HTML) (Obsoletes RFC4676) (Updated by RFC5774, RFC6848) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4776) 4777 IBM's iSeries Telnet Enhancements. T. Murphy Jr., P. Rieth, J. Stevens. November 2006. (Format: TXT, HTML) (Obsoletes RFC2877) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4777) 4778 Operational Security Current Practices in Internet Service Provider Environments. M. Kaeo. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4778) 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4779) 4780 Management Information Base for the Session Initiation Protocol (SIP). K. Lingle, J-F. Mule, J. Maeng, D. Walker. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4780) 4781 Graceful Restart Mechanism for BGP with MPLS. Y. Rekhter, R. Aggarwal. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4781) 4782 Quick-Start for TCP and IP. S. Floyd, M. Allman, A. Jain, P. Sarolahti. January 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4782) 4783 GMPLS - Communication of Alarm Information. L. Berger, Ed.. December 2006. (Format: TXT, HTML) (Updates RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4783) 4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks. C. Carroll, F. Quick. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4784) 4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS). U. Blumenthal, P. Goel. January 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4785) 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT, HTML) (Also BCP0126) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4786) 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. F. Audet, Ed., C. Jennings. January 2007. (Format: TXT, HTML) (Updated by RFC6888, RFC7857) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4787) 4788 Enhancements to RTP Payload Formats for EVRC Family Codecs. Q. Xie, R. Kapoor. January 2007. (Format: TXT, HTML) (Updates RFC3558) (Updated by RFC5188) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4788) 4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks. J. Schoenwaelder, T. Jeffree. November 2006. (Format: TXT, HTML) (Obsoletes RFC1089) (Updates RFC3417) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4789) 4790 Internet Application Protocol Collation Registry. C. Newman, M. Duerst, A. Gulbrandsen. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4790) 4791 Calendaring Extensions to WebDAV (CalDAV). C. Daboo, B. Desruisseaux, L. Dusseault. March 2007. (Format: TXT, HTML) (Updated by RFC5689, RFC6638, RFC6764, RFC7809, RFC7953) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4791) 4792 Encoding Instructions for the Generic String Encoding Rules (GSER). S. Legg. January 2007. (Format: TXT, HTML) (Updates RFC3641) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4792) 4793 The EAP Protected One-Time Password Protocol (EAP-POTP). M. Nystroem. February 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4793) 4794 RFC 1264 Is Obsolete. B. Fenner. December 2006. (Format: TXT, HTML) (Obsoletes RFC1264) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4794) 4795 Link-local Multicast Name Resolution (LLMNR). B. Aboba, D. Thaler, L. Esibov. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4795) 4796 The Session Description Protocol (SDP) Content Attribute. J. Hautakorpi, G. Camarillo. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4796) 4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks. Y. Rekhter, R. Bonica, E. Rosen. January 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4797) 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4798) 4799 Not Issued. 4800 Not Issued. 4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4801) 4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4802) 4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base. T. Nadeau, Ed., A. Farrel, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4803) 4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels. F. Le Faucheur, Ed.. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4804) 4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types. O. Nicklass, Ed.. March 2007. (Format: TXT, HTML) (Obsoletes RFC3895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4805) 4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2. M. Myers, H. Tschofenig. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4806) 4807 IPsec Security Policy Database Configuration MIB. M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4807) 4808 Key Change Strategies for TCP-MD5. S. Bellovin. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4808) 4809 Requirements for an IPsec Certificate Management Profile. C. Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed.. February 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4809) 4810 Long-Term Archive Service Requirements. C. Wallace, U. Pordesch, R. Brandner. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4810) 4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4811) 4812 OSPF Restart Signaling. L. Nguyen, A. Roy, A. Zinin. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4812) 4813 OSPF Link-Local Signaling. B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. March 2007. (Format: TXT, HTML) (Obsoleted by RFC5613) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4813) 4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking. D. Newman, T. Player. March 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4814) 4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095. L-E. Jonsson, K. Sandlund, G. Pelletier, P. Kremer. February 2007. (Format: TXT, HTML) (Updates RFC3095, RFC3241, RFC3843, RFC4019, RFC4362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4815) 4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service. A. Malis, L. Martini, J. Brayley, T. Walsh. February 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4816) 4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3. M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4817) 4818 RADIUS Delegated-IPv6-Prefix Attribute. J. Salowey, R. Droms. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4818) 4819 Secure Shell Public Key Subsystem. J. Galbraith, J. Van Dyke, J. Bright. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4819) 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Stewart, P. Lei. March 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4820) 4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner. March 2007. (Format: TXT, HTML) (Updated by RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4821) 4822 RIPv2 Cryptographic Authentication. R. Atkinson, M. Fanto. February 2007. (Format: TXT, HTML) (Obsoletes RFC2082) (Updates RFC2453) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4822) 4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet. T. Harding, R. Scott. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4823) 4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS). J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed.. 1 April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4824) 4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). J. Rosenberg. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4825) 4826 Extensible Markup Language (XML) Formats for Representing Resource Lists. J. Rosenberg. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4826) 4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents. M. Isomaki, E. Leppanen. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4827) 4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant. S. Floyd, E. Kohler. April 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4828) 4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering. J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C. Scoglio. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4829) 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4830) 4831 Goals for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4831) 4832 Security Threats to Network-Based Localized Mobility Management (NETLMM). C. Vogt, J. Kempf. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4832) 4833 Timezone Options for DHCP. E. Lear, P. Eggert. April 2007. (Format: TXT, HTML) (Updates RFC2132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4833) 4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). T. Morin, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4834) 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH). V. Manral. April 2007. (Format: TXT, HTML) (Obsoletes RFC4305) (Obsoleted by RFC7321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4835) 4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs). E. Beili. April 2007. (Format: TXT, HTML) (Obsoletes RFC3636) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4836) 4837 Managed Objects of Ethernet Passive Optical Networks (EPON). L. Khermosh. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4837) 4838 Delay-Tolerant Networking Architecture. V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4838) 4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF). G. Conboy, J. Rivlin, J. Ferraiolo. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4839) 4840 Multiple Encapsulation Methods Considered Harmful. B. Aboba, Ed., E. Davies, D. Thaler. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4840) 4841 RFC 4181 Update to Recognize the IETF Trust. C. Heard, Ed.. March 2007. (Format: TXT, HTML) (Updates RFC4181) (Also BCP0111) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4841) 4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP). A. Malis, P. Pate, R. Cohen, Ed., D. Zelig. April 2007. (Format: TXT, HTML) (Obsoletes RFC5143) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4842) 4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT, HTML) (Obsoleted by RFC7343) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4843) 4844 The RFC Series and RFC Editor. L. Daigle, Ed., Internet Architecture Board. July 2007. (Format: TXT, HTML) (Obsoleted by RFC8729) (Updated by RFC5741) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4844) 4845 Process for Publication of IAB RFCs. L. Daigle, Ed., Internet Architecture Board. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4845) 4846 Independent Submissions to the RFC Editor. J. Klensin, Ed., D. Thaler, Ed.. July 2007. (Format: TXT, HTML) (Updated by RFC5744) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4846) 4847 Framework and Requirements for Layer 1 Virtual Private Networks. T. Takeda, Ed.. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4847) 4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS). L. Daigle. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4848) 4849 RADIUS Filter Rule Attribute. P. Congdon, M. Sanchez, B. Aboba. April 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4849) 4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture. D. Wysochanski. April 2007. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updates RFC3720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4850) 4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST). N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4851) 4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4852) 4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification. R. Housley. April 2007. (Format: TXT, HTML) (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4853) 4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4854) 4855 Media Type Registration of RTP Payload Formats. S. Casner. February 2007. (Format: TXT, HTML) (Obsoletes RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4855) 4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences. S. Casner. February 2007. (Format: TXT, HTML) (Obsoletes RFC3555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4856) 4857 Mobile IPv4 Regional Registration. E. Fogelstroem, A. Jonsson, C. Perkins. June 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4857) 4858 Document Shepherding from Working Group Last Call to Publication. H. Levkowetz, D. Meyer, L. Eggert, A. Mankin. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4858) 4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object. A. Farrel. April 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4859) 4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations. F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. Davenport. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4860) 4861 Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT, HTML) (Obsoletes RFC2461) (Updated by RFC5942, RFC6980, RFC7048, RFC7527, RFC7559, RFC8028, RFC8319, RFC8425) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4861) 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT, HTML) (Obsoletes RFC2462) (Updated by RFC7527) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4862) 4863 Wildcard Pseudowire Type. L. Martini, G. Swallow. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4863) 4864 Local Network Protection for IPv6. G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4864) 4865 SMTP Submission Service Extension for Future Message Release. G. White, G. Vaudreuil. May 2007. (Format: TXT, HTML) (Updates RFC3463, RFC3464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4865) 4866 Enhanced Route Optimization for Mobile IPv6. J. Arkko, C. Vogt, W. Haddad. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4866) 4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. April 2007. (Format: TXT, HTML) (Obsoletes RFC3267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4867) 4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec. S. Kelly, S. Frankel. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4868) 4869 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. May 2007. (Format: TXT, HTML) (Obsoleted by RFC6379) (Status: HISTORIC) (DOI: 10.17487/RFC4869) 4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys). M. Delany. May 2007. (Format: TXT, HTML) (Obsoleted by RFC4871) (Status: HISTORIC) (DOI: 10.17487/RFC4870) 4871 DomainKeys Identified Mail (DKIM) Signatures. E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. May 2007. (Format: TXT, HTML) (Obsoletes RFC4870) (Obsoleted by RFC6376) (Updated by RFC5672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4871) 4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery. J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.. May 2007. (Format: TXT, HTML) (Updates RFC3471) (Updated by RFC4873, RFC6780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4872) 4873 GMPLS Segment Recovery. L. Berger, I. Bryskin, D. Papadimitriou, A. Farrel. May 2007. (Format: TXT, HTML) (Updates RFC3473, RFC4872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4873) 4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE). CY. Lee, A. Farrel, S. De Cnodder. April 2007. (Format: TXT, HTML) (Updates RFC3209, RFC3473) (Updated by RFC6001, RFC8390) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4874) 4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs). R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. May 2007. (Format: TXT, HTML) (Updated by RFC6510) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4875) 4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents. B. Neal-Joslin, Ed., L. Howard, M. Ansari. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4876) 4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture. V. Devarapalli, F. Dupont. April 2007. (Format: TXT, HTML) (Updates RFC3776) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4877) 4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces. M. Squire. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4878) 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979. T. Narten. April 2007. (Format: TXT, HTML) (Obsoleted by RFC8179) (Updates RFC3979) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4879) 4880 OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, D. Shaw, R. Thayer. November 2007. (Format: TXT, HTML) (Obsoletes RFC1991, RFC2440) (Updated by RFC5581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4880) 4881 Low-Latency Handoffs in Mobile IPv4. K. El Malki, Ed.. June 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4881) 4882 IP Address Location Privacy and Mobile IPv6: Problem Statement. R. Koodli. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4882) 4883 Benchmarking Terminology for Resource Reservation Capable Routers. G. Feher, K. Nemeth, A. Korn, I. Cselenyi. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4883) 4884 Extended ICMP to Support Multi-Part Messages. R. Bonica, D. Gan, D. Tappan, C. Pignataro. April 2007. (Format: TXT, HTML) (Updates RFC0792, RFC4443) (Updated by RFC8335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4884) 4885 Network Mobility Support Terminology. T. Ernst, H-Y. Lach. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4885) 4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4886) 4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V. Devarapalli. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4887) 4888 Network Mobility Route Optimization Problem Statement. C. Ng, P. Thubert, M. Watari, F. Zhao. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4888) 4889 Network Mobility Route Optimization Solution Space Analysis. C. Ng, F. Zhao, M. Watari, P. Thubert. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4889) 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E. Davies, J. Mohacsi. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4890) 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4891) 4892 Requirements for a Mechanism Identifying a Name Server Instance. S. Woolf, D. Conrad. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4892) 4893 BGP Support for Four-octet AS Number Space. Q. Vohra, E. Chen. May 2007. (Format: TXT, HTML) (Obsoleted by RFC6793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4893) 4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec. P. Hoffman. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4894) 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Stewart, P. Lei, E. Rescorla. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4895) 4896 Signaling Compression (SigComp) Corrections and Clarifications. A. Surtees, M. West, A.B. Roach. June 2007. (Format: TXT, HTML) (Updates RFC3320, RFC3321, RFC3485) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4896) 4897 Handling Normative References to Standards-Track Documents. J. Klensin, S. Hartman. June 2007. (Format: TXT, HTML) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4897) 4898 TCP Extended Statistics MIB. M. Mathis, J. Heffner, R. Raghunarayan. May 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4898) 4899 Not Issued. 4900 Not Issued. 4901 Protocol Extensions for Header Compression over MPLS. J. Ash, Ed., J. Hand, Ed., A. Malis, Ed.. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4901) 4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP. M. Stecher. May 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4902) 4903 Multi-Link Subnet Issues. D. Thaler. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4903) 4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs). V. Gurbani, C. Jennings. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4904) 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4905) 4906 Transport of Layer 2 Frames Over MPLS. L. Martini, Ed., E. Rosen, Ed., N. El-Aawar, Ed.. June 2007. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC4906) 4907 Architectural Implications of Link Indications. B. Aboba, Ed.. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4907) 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO. K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi. June 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4908) 4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport. L. Dondeti, Ed., D. Castleford, F. Hartung. June 2007. (Format: TXT, HTML) (Obsoleted by RFC5410, RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4909) 4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1). S. Legg, D. Prager. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4910) 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4911) 4912 Abstract Syntax Notation X (ASN.X). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4912) 4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4913) 4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER). S. Legg. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4914) 4915 Multi-Topology (MT) Routing in OSPF. P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-Esnault. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4915) 4916 Connected Identity in the Session Initiation Protocol (SIP). J. Elwell. June 2007. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4916) 4917 Mobile IPv4 Message String Extension. V. Sastry, K. Leung, A. Patel. June 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4917) 4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). L. Dusseault, Ed.. June 2007. (Format: TXT, HTML) (Obsoletes RFC2518) (Updated by RFC5689) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4918) 4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. N. Kushalnagar, G. Montenegro, C. Schumacher. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4919) 4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE. A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita, G. Ash. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4920) 4921 Not Issued. 4922 Not Issued. 4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network. F. Baker, P. Bose. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4923) 4924 Reflections on Internet Transparency. B. Aboba, Ed., E. Davies. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4924) 4925 Softwire Problem Statement. X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed.. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4925) 4926 A URN Namespace for GEANT. T.Kalin, M.Molina. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4926) 4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering. J.-L. Le Roux, Ed.. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4927) 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks. G. Swallow, S. Bryant, L. Andersson. June 2007. (Format: TXT, HTML) (Updated by RFC7274) (Also BCP0128) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4928) 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures. L. Andersson, Ed., A. Farrel, Ed.. June 2007. (Format: TXT, HTML) (Also BCP0129) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4929) 4930 Extensible Provisioning Protocol (EPP). S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3730) (Obsoleted by RFC5730) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4930) 4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3731) (Obsoleted by RFC5731) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4931) 4932 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3732) (Obsoleted by RFC5732) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4932) 4933 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3733) (Obsoleted by RFC5733) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4933) 4934 Extensible Provisioning Protocol (EPP) Transport Over TCP. S. Hollenbeck. May 2007. (Format: TXT, HTML) (Obsoletes RFC3734) (Obsoleted by RFC5734) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4934) 4935 Fibre Channel Fabric Configuration Server MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4935) 4936 Fibre Channel Zone Server MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4936) 4937 IANA Considerations for PPP over Ethernet (PPPoE). P. Arberg, V. Mammoliti. June 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4937) 4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics. B. Berry, H. Holgate. June 2007. (Format: TXT, HTML) (Obsoleted by RFC5578) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4938) 4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service). K. Gibbons, G. Ramkumar, S. Kipp. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4939) 4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT, HTML) (Also BCP0130) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4940) 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT, HTML) (Obsoletes RFC3041) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC4941) 4942 IPv6 Transition/Co-existence Security Considerations. E. Davies, S. Krishnan, P. Savola. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4942) 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S. Roy, A. Durand, J. Paugh. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4943) 4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks. G. Montenegro, N. Kushalnagar, J. Hui, D. Culler. September 2007. (Format: TXT, HTML) (Updated by RFC6282, RFC6775, RFC8025, RFC8066, RFC8931) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4944) 4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX. B. Korver. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4945) 4946 Atom License Extension. J. Snell. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4946) 4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks. G. Fairhurst, M. Montpetit. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4947) 4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006. L. Andersson, E. Davies, L. Zhang. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4948) 4949 Internet Security Glossary, Version 2. R. Shirey. August 2007. (Format: TXT, HTML) (Obsoletes RFC2828) (Also FYI0036) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4949) 4950 ICMP Extensions for Multiprotocol Label Switching. R. Bonica, D. Gan, D. Tappan, C. Pignataro. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4950) 4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover". V. Jain, Ed.. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4951) 4952 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. July 2007. (Format: TXT, HTML) (Obsoleted by RFC6530) (Updated by RFC5336) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4952) 4953 Defending TCP Against Spoofing Attacks. J. Touch. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4953) 4954 SMTP Service Extension for Authentication. R. Siemborski, Ed., A. Melnikov, Ed.. July 2007. (Format: TXT, HTML) (Obsoletes RFC2554) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4954) 4955 DNS Security (DNSSEC) Experiments. D. Blacka. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4955) 4956 DNS Security (DNSSEC) Opt-In. R. Arends, M. Kosters, D. Blacka. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4956) 4957 Link-Layer Event Notifications for Detecting Network Attachments. S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed.. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4957) 4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain. K. Carlberg. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4958) 4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response. R. Siemborski, A. Gulbrandsen. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4959) 4960 Stream Control Transmission Protocol. R. Stewart, Ed.. September 2007. (Format: TXT, HTML) (Obsoletes RFC2960, RFC3309) (Updated by RFC6096, RFC6335, RFC7053, RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4960) 4961 Symmetric RTP / RTP Control Protocol (RTCP). D. Wing. July 2007. (Format: TXT, HTML) (Also BCP0131) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4961) 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management. R. Housley, B. Aboba. July 2007. (Format: TXT, HTML) (Also BCP0132) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC4962) 4963 IPv4 Reassembly Errors at High Data Rates. J. Heffner, M. Mathis, B. Chandler. July 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4963) 4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular. A. Allen, Ed., J. Holm, T. Hallin. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4964) 4965 CableLabs - IETF Standardization Collaboration. J-F. Mule, W. Townsley. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4965) 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status. C. Aoun, E. Davies. July 2007. (Format: TXT, HTML) (Obsoletes RFC2766) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4966) 4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier. B. Rosen. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4967) 4968 Analysis of IPv6 Link Models for 802.16 Based Networks. S. Madanapalli, Ed.. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4968) 4969 IANA Registration for vCard Enumservice. A. Mayrhofer. August 2007. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4969) 4970 Extensions to OSPF for Advertising Optional Router Capabilities. A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. July 2007. (Format: TXT, HTML) (Obsoleted by RFC7770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4970) 4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information. JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed.. July 2007. (Format: TXT, HTML) (Obsoleted by RFC7981) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4971) 4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership. JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4972) 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering. P. Srisuresh, P. Joseph. July 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4973) 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls. D. Papadimitriou, A. Farrel. August 2007. (Format: TXT, HTML) (Updates RFC3473) (Updated by RFC6001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4974) 4975 The Message Session Relay Protocol (MSRP). B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed.. September 2007. (Format: TXT, HTML) (Updated by RFC7977, RFC8591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4975) 4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP). C. Jennings, R. Mahy, A. B. Roach. September 2007. (Format: TXT, HTML) (Updated by RFC7977, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4976) 4977 Problem Statement: Dual Stack Mobility. G. Tsirtsis, H. Soliman. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4977) 4978 The IMAP COMPRESS Extension. A. Gulbrandsen. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4978) 4979 IANA Registration for Enumservice 'XMPP'. A. Mayrhofer. August 2007. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4979) 4980 Analysis of Multihoming in Network Mobility Support. C. Ng, T. Ernst, E. Paik, M. Bagnulo. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4980) 4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods. J. Risson, T. Moors. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4981) 4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs). M. Bagnulo, J. Arkko. July 2007. (Format: TXT, HTML) (Updates RFC3972) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4982) 4983 Fibre Channel Registered State Change Notification (RSCN) MIB. C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4983) 4984 Report from the IAB Workshop on Routing and Addressing. D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed.. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4984) 4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name. S. Santesson. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4985) 4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover. H. Eland, R. Mundy, S. Crocker, S. Krishnaswamy. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4986) 4987 TCP SYN Flooding Attacks and Common Mitigations. W. Eddy. August 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4987) 4988 Mobile IPv4 Fast Handovers. R. Koodli, C. Perkins. October 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC4988) 4989 Not Issued. 4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks. K. Shiomoto, R. Papneja, R. Rabbat. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC4990) 4991 A Common Schema for Internet Registry Information Service Transfer Protocols. A. Newton. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4991) 4992 XML Pipelining with Chunks for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT, HTML) (Updates RFC3981) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4992) 4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service. A. Newton. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4993) 4994 DHCPv6 Relay Agent Echo Request Option. S. Zeng, B. Volz, K. Kinnear, J. Brzozowski. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4994) 4995 The RObust Header Compression (ROHC) Framework. L-E. Jonsson, G. Pelletier, K. Sandlund. July 2007. (Format: TXT, HTML) (Obsoleted by RFC5795) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4995) 4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP). G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. July 2007. (Format: TXT, HTML) (Obsoleted by RFC6846) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4996) 4997 Formal Notation for RObust Header Compression (ROHC-FN). R. Finking, G. Pelletier. July 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4997) 4998 Evidence Record Syntax (ERS). T. Gondrom, R. Brandner, U. Pordesch. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4998) 4999 Not Issued. 5000 Internet Official Protocol Standards. RFC Editor. May 2008. (Format: TXT, HTML) (Obsoletes RFC3700) (Obsoleted by RFC7100) (Status: HISTORIC) (DOI: 10.17487/RFC5000) 5001 DNS Name Server Identifier (NSID) Option. R. Austein. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5001) 5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header). G. Camarillo, G. Blanco. August 2007. (Format: TXT, HTML) (Updated by RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5002) 5003 Attachment Individual Identifier (AII) Types for Aggregation. C. Metz, L. Martini, F. Balus, J. Sugimoto. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5003) 5004 Avoid BGP Best Path Transitions from One External to Another. E. Chen, S. Sangli. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5004) 5005 Feed Paging and Archiving. M. Nottingham. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5005) 5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format: TXT, HTML) (Obsoleted by RFC6106) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5006) 5007 DHCPv6 Leasequery. J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5007) 5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME). R. Housley, J. Solinas. September 2007. (Format: TXT, HTML) (Obsoleted by RFC6318) (Status: HISTORIC) (DOI: 10.17487/RFC5008) 5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media. R. Ejza. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5009) 5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption. K. Kinnear, M. Normoyle, M. Stapp. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5010) 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors. M. StJohns. September 2007. (Format: TXT, HTML) (Also STD0074) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5011) 5012 Requirements for Emergency Context Resolution with Internet Technologies. H. Schulzrinne, R. Marshall, Ed.. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5012) 5013 The Dublin Core Metadata Element Set. J. Kunze, T. Baker. August 2007. (Format: TXT, HTML) (Obsoletes RFC2413) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5013) 5014 IPv6 Socket API for Source Address Selection. E. Nordmark, S. Chakrabarti, J. Laganier. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5014) 5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM). M. Handley, I. Kouvelas, T. Speakman, L. Vicisano. October 2007. (Format: TXT, HTML) (Updated by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5015) 5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol. M. Thomas. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5016) 5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs). D. McWalter, Ed.. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5017) 5018 Connection Establishment in the Binary Floor Control Protocol (BFCP). G. Camarillo. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5018) 5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, R. Hurst. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5019) 5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute. K. Zeilenga. August 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5020) 5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP. S. Josefsson. August 2007. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5021) 5022 Media Server Control Markup Language (MSCML) and Protocol. J. Van Dyke, E. Burger, Ed., A. Spitzer. September 2007. (Format: TXT, HTML) (Obsoletes RFC4722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5022) 5023 The Atom Publishing Protocol. J. Gregorio, Ed., B. de hOra, Ed.. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5023) 5024 ODETTE File Transfer Protocol 2.0. I. Friend. November 2007. (Format: TXT, HTML) (Obsoletes RFC2204) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5024) 5025 Presence Authorization Rules. J. Rosenberg. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5025) 5026 Mobile IPv6 Bootstrapping in Split Scenario. G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. October 2007. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5026) 5027 Security Preconditions for Session Description Protocol (SDP) Media Streams. F. Andreasen, D. Wing. October 2007. (Format: TXT, HTML) (Updates RFC3312) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5027) 5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services. R. Mahy. October 2007. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5028) 5029 Definition of an IS-IS Link Attribute Sub-TLV. JP. Vasseur, S. Previdi. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5029) 5030 Mobile IPv4 RADIUS Requirements. M. Nakhjiri, Ed., K. Chowdhury, A. Lior, K. Leung. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5030) 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services. H. Schulzrinne. January 2008. (Format: TXT, HTML) (Updated by RFC7163) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5031) 5032 WITHIN Search Extension to the IMAP Protocol. E. Burger, Ed.. September 2007. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5032) 5033 Specifying New Congestion Control Algorithms. S. Floyd, M. Allman. August 2007. (Format: TXT, HTML) (Also BCP0133) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5033) 5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism. R. Siemborski, A. Menon-Sen. July 2007. (Format: TXT, HTML) (Obsoletes RFC1734) (Updates RFC2449) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5034) 5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility. J. Schaad. August 2007. (Format: TXT, HTML) (Updates RFC2634) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5035) 5036 LDP Specification. L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. October 2007. (Format: TXT, HTML) (Obsoletes RFC3036) (Updated by RFC6720, RFC6790, RFC7358, RFC7552) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5036) 5037 Experience with the Label Distribution Protocol (LDP). L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5037) 5038 The Label Distribution Protocol (LDP) Implementation Survey Results. B. Thomas, L. Andersson. October 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5038) 5039 The Session Initiation Protocol (SIP) and Spam. J. Rosenberg, C. Jennings. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5039) 5040 A Remote Direct Memory Access Protocol Specification. R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5040) 5041 Direct Data Placement over Reliable Transports. H. Shah, J. Pinkerton, R. Recio, P. Culley. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5041) 5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security. J. Pinkerton, E. Deleganes. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5042) 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation. C. Bestler, Ed., R. Stewart, Ed.. October 2007. (Format: TXT, HTML) (Updated by RFC6581, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5043) 5044 Marker PDU Aligned Framing for TCP Specification. P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier. October 2007. (Format: TXT, HTML) (Updated by RFC6581, RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5044) 5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP). C. Bestler, Ed., L. Coene. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5045) 5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA). M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. October 2007. (Format: TXT, HTML) (Obsoleted by RFC7145) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5046) 5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI). M. Chadalapaka, J. Hufferd, J. Satran, H. Shah. October 2007. (Format: TXT, HTML) (Updated by RFC7146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5047) 5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications. M. Chadalapaka, Ed.. October 2007. (Format: TXT, HTML) (Obsoleted by RFC7143) (Updates RFC3720) (Updated by RFC7146) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5048) 5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP). C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed.. December 2007. (Format: TXT, HTML) (Updates RFC3486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5049) 5050 Bundle Protocol Specification. K. Scott, S. Burleigh. November 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5050) 5051 i;unicode-casemap - Simple Unicode Collation Algorithm. M. Crispin. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5051) 5052 Forward Error Correction (FEC) Building Block. M. Watson, M. Luby, L. Vicisano. August 2007. (Format: TXT, HTML) (Obsoletes RFC3452) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5052) 5053 Raptor Forward Error Correction Scheme for Object Delivery. M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer. October 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5053) 5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication. D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin. November 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5054) 5055 Server-Based Certificate Validation Protocol (SCVP). T. Freeman, R. Housley, A. Malpani, D. Cooper, W. Polk. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5055) 5056 On the Use of Channel Bindings to Secure Channels. N. Williams. November 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5056) 5057 Multiple Dialog Usages in the Session Initiation Protocol. R. Sparks. November 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5057) 5058 Explicit Multicast (Xcast) Concepts and Options. R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms. November 2007. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5058) 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM). N. Bhaskar, A. Gall, J. Lingard, S. Venaas. January 2008. (Format: TXT, PDF, HTML) (Obsoletes RFC2362) (Updates RFC4601) (Updated by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5059) 5060 Protocol Independent Multicast MIB. R. Sivaramu, J. Lingard, D. McWalter, B. Joshi, A. Kessler. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5060) 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration. R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka. September 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5061) 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures. R. Stewart, M. Tuexen, G. Camarillo. September 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5062) 5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart. A. Satyanarayana, Ed., R. Rahman, Ed.. October 2007. (Format: TXT, HTML) (Updates RFC2961, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5063) 5064 The Archived-At Message Header Field. M. Duerst. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5064) 5065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. August 2007. (Format: TXT, HTML) (Obsoletes RFC3065) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5065) 5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. November 2007. (Format: TXT, HTML) (Updated by RFC7124) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5066) 5067 Infrastructure ENUM Requirements. S. Lind, P. Pfautz. November 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5067) 5068 Email Submission Operations: Access and Accountability Requirements. C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. November 2007. (Format: TXT, HTML) (Updated by RFC8314) (Also BCP0134) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5068) 5069 Security Threats and Requirements for Emergency Call Marking and Mapping. T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5069) 5070 The Incident Object Description Exchange Format. R. Danyliw, J. Meijer, Y. Demchenko. December 2007. (Format: TXT, HTML) (Obsoleted by RFC7970) (Updated by RFC6685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5070) 5071 Dynamic Host Configuration Protocol Options Used by PXELINUX. D. Hankins. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5071) 5072 IP Version 6 over PPP. S. Varada, Ed., D. Haskins, E. Allen. September 2007. (Format: TXT, HTML) (Obsoletes RFC2472) (Updated by RFC8064) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5072) 5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities. J.P. Vasseur, Ed., J.L. Le Roux, Ed.. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5073) 5074 DNSSEC Lookaside Validation (DLV). S. Weiler. November 2007. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5074) 5075 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. November 2007. (Format: TXT, HTML) (Obsoleted by RFC5175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5075) 5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol. B. Hoeneisen. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5076) 5077 Transport Layer Security (TLS) Session Resumption without Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. January 2008. (Format: TXT, HTML) (Obsoletes RFC4507) (Obsoleted by RFC8446) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5077) 5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline. S. Dawkins. October 2007. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5078) 5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP). J. Rosenberg. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5079) 5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes. D. Nelson, A. DeKok. December 2007. (Format: TXT, HTML) (Updates RFC2865, RFC2866, RFC2869, RFC3579) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5080) 5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos. November 2007. (Format: TXT, HTML) (Obsoleted by RFC6091) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5081) 5082 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. October 2007. (Format: TXT, HTML) (Obsoletes RFC3682) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5082) 5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type. R. Housley. November 2007. (Format: TXT, HTML) (Updates RFC3852) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5083) 5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS). R. Housley. November 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5084) 5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires. T. Nadeau, Ed., C. Pignataro, Ed.. December 2007. (Format: TXT, HTML) (Updated by RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5085) 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN). A. Vainshtein, Ed., I. Sasson, E. Metz, T. Frost, P. Pate. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5086) 5087 Time Division Multiplexing over IP (TDMoIP). Y(J). Stein, R. Shashoua, R. Insler, M. Anavi. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5087) 5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery. JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5088) 5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery. JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5089) 5090 RADIUS Extension for Digest Authentication. B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. February 2008. (Format: TXT, HTML) (Obsoletes RFC4590) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5090) 5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems. X. Boyen, L. Martin. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5091) 5092 IMAP URL Scheme. A. Melnikov, Ed., C. Newman. November 2007. (Format: TXT, HTML) (Obsoletes RFC2192) (Updates RFC4467) (Updated by RFC5593) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5092) 5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ). G. Hunt. December 2007. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5093) 5094 Mobile IPv6 Vendor Specific Option. V. Devarapalli, A. Patel, K. Leung. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5094) 5095 Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT, HTML) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5095) 5096 Mobile IPv6 Experimental Messages. V. Devarapalli. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5096) 5097 MIB for the UDP-Lite protocol. G. Renker, G. Fairhurst. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5097) 5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs). G. Beacham, S. Kumar, S. Channabasappa. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5098) 5099 Not Issued. 5100 Not Issued. 5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. B. Claise, Ed.. January 2008. (Format: TXT, HTML) (Obsoleted by RFC7011) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5101) 5102 Information Model for IP Flow Information Export. J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. January 2008. (Format: TXT, HTML) (Obsoleted by RFC7012) (Updated by RFC6313) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5102) 5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX). B. Trammell, E. Boschi. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5103) 5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF). S. Wenger, U. Chandra, M. Westerlund, B. Burman. February 2008. (Format: TXT, HTML) (Updated by RFC7728, RFC8082) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5104) 5105 ENUM Validation Token Format Definition. O. Lendl. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5105) 5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method. H. Tschofenig, D. Kroeselberg, A. Pashalidis, Y. Ohba, F. Bersani. February 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5106) 5107 DHCP Server Identifier Override Suboption. R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5107) 5108 Not Issued. 5109 RTP Payload Format for Generic Forward Error Correction. A. Li, Ed.. December 2007. (Format: TXT, HTML) (Obsoletes RFC2733, RFC3009) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5109) 5110 Overview of the Internet Multicast Routing Architecture. P. Savola. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5110) 5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF). B. Aboba, L. Dondeti. January 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5111) 5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp). M. Garcia-Martin. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5112) 5113 Network Discovery and Selection Problem. J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5113) 5114 Additional Diffie-Hellman Groups for Use with IETF Standards. M. Lepinski, S. Kent. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5114) 5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority. K. Carlberg, P. O'Hanlon. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5115) 5116 An Interface and Algorithms for Authenticated Encryption. D. McGrew. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5116) 5117 RTP Topologies. M. Westerlund, S. Wenger. January 2008. (Format: TXT, HTML) (Obsoleted by RFC7667) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5117) 5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6). V. Gurbani, C. Boulton, R. Sparks. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5118) 5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE). T. Edwards. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5119) 5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs). T. Przygienda, N. Shen, N. Sheth. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5120) 5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks. B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. February 2008. (Format: TXT, HTML) (Updated by RFC8064) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5121) 5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre. February 2008. (Format: TXT, HTML) (Obsoletes RFC4622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5122) 5123 Considerations in Validating the Path in BGP. R. White, B. Akyol. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5123) 5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF). J. Ott, E. Carrara. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5124) 5125 Reclassification of RFC 3525 to Historic. T. Taylor. February 2008. (Format: TXT, HTML) (Obsoletes RFC3525) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5125) 5126 CMS Advanced Electronic Signatures (CAdES). D. Pinkas, N. Pope, J. Ross. March 2008. (Format: TXT, HTML) (Obsoletes RFC3126) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5126) 5127 Aggregation of Diffserv Service Classes. K. Chan, J. Babiarz, F. Baker. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5127) 5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs). P. Srisuresh, B. Ford, D. Kegel. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5128) 5129 Explicit Congestion Marking in MPLS. B. Davie, B. Briscoe, J. Tay. January 2008. (Format: TXT, HTML) (Updates RFC3032) (Updated by RFC5462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5129) 5130 A Policy Control Mechanism in IS-IS Using Administrative Tags. S. Previdi, M. Shand, Ed., C. Martin. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5130) 5131 A MIB Textual Convention for Language Tags. D. McWalter, Ed.. December 2007. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5131) 5132 IP Multicast MIB. D. McWalter, D. Thaler, A. Kessler. December 2007. (Format: TXT, HTML) (Obsoletes RFC2932) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5132) 5133 Terminal Endpoint Identifier (TEI) Query Request Number Change. M. Tuexen, K. Morneault. December 2007. (Format: TXT, HTML) (Updates RFC4233) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5133) 5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards. M. Mealling. January 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5134) 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT, HTML) (Also BCP0135) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5135) 5136 Defining Network Capacity. P. Chimento, J. Ishac. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5136) 5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT, HTML) (Also BCP0137) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5137) 5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI). S. Cox. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5138) 5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2008. (Format: TXT, HTML) (Updates RFC4119) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5139) 5140 A Telephony Gateway REgistration Protocol (TGREP). M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5140) 5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO). J. Goodwin, H. Apel. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5141) 5142 Mobility Header Home Agent Switch Message. B. Haley, V. Devarapalli, H. Deng, J. Kempf. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5142) 5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation. A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. February 2008. (Format: TXT, HTML) (Obsoleted by RFC4842) (Status: HISTORIC) (DOI: 10.17487/RFC5143) 5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS). A. Newton, M. Sanz. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5144) 5145 Framework for MPLS-TE to GMPLS Migration. K. Shiomoto, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5145) 5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks. K. Kumaki, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5146) 5147 URI Fragment Identifiers for the text/plain Media Type. E. Wilde, M. Duerst. April 2008. (Format: TXT, HTML) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5147) 5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs). T. Clausen, C. Dearlove, B. Adamson. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5148) 5149 Service Selection for Mobile IPv6. J. Korhonen, U. Nilsson, V. Devarapalli. February 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5149) 5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE). A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5150) 5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions. A. Farrel, Ed., A. Ayyangar, JP. Vasseur. February 2008. (Format: TXT, HTML) (Updates RFC3209, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5151) 5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs). JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang. February 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5152) 5153 IP Flow Information Export (IPFIX) Implementation Guidelines. E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5153) 5154 IP over IEEE 802.16 Problem Statement and Goals. J. Jee, Ed., S. Madanapalli, J. Mandin. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5154) 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. B. Laurie, G. Sisson, R. Arends, D. Blacka. March 2008. (Format: TXT, HTML) (Updated by RFC6840, RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5155) 5156 Special-Use IPv6 Addresses. M. Blanchet. April 2008. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5156) 5157 IPv6 Implications for Network Scanning. T. Chown. March 2008. (Format: TXT, HTML) (Obsoleted by RFC7707) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5157) 5158 6to4 Reverse DNS Delegation Specification. G. Huston. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5158) 5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection. L. Dondeti, Ed., A. Jerichow. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5159) 5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS). P. Levis, M. Boucadair. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5160) 5161 The IMAP ENABLE Extension. A. Gulbrandsen, Ed., A. Melnikov, Ed.. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5161) 5162 IMAP4 Extensions for Quick Mailbox Resynchronization. A. Melnikov, D. Cridland, C. Wilson. March 2008. (Format: TXT, HTML) (Obsoleted by RFC7162) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5162) 5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE). G. Fairhurst, B. Collini-Nocker. April 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5163) 5164 Mobility Services Transport: Problem Statement. T. Melia, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5164) 5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC). C. Reed. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5165) 5166 Metrics for the Evaluation of Congestion Control Mechanisms. S. Floyd, Ed.. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5166) 5167 Media Server Control Protocol Requirements. M. Dolly, R. Even. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5167) 5168 XML Schema for Media Control. O. Levin, R. Even, P. Hagendorf. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5168) 5169 Handover Key Management and Re-Authentication Problem Statement. T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5169) 5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes. V. Roca, C. Neumann, D. Furodet. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5170) 5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol. M. Foschiano. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5171) 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol. S. Varada, Ed.. March 2008. (Format: TXT, HTML) (Obsoletes RFC2472) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5172) 5173 Sieve Email Filtering: Body Extension. J. Degener, P. Guenther. April 2008. (Format: TXT, HTML) (Updates RFC5229) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5173) 5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU). J-P. Evain. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5174) 5175 IPv6 Router Advertisement Flags Option. B. Haberman, Ed., R. Hinden. March 2008. (Format: TXT, HTML) (Obsoletes RFC5075) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5175) 5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS). M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. January 2008. (Format: TXT, HTML) (Obsoletes RFC3576) (Updated by RFC8559) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5176) 5177 Network Mobility (NEMO) Extensions for Mobile IPv4. K. Leung, G. Dommety, V. Narayanan, A. Petrescu. April 2008. (Format: TXT, HTML) (Updated by RFC6626) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5177) 5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type. N. Williams, A. Melnikov. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5178) 5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism. N. Williams. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5179) 5180 IPv6 Benchmarking Methodology for Network Interconnect Devices. C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5180) 5181 IPv6 Deployment Scenarios in 802.16 Networks. M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5181) 5182 IMAP Extension for Referencing the Last SEARCH Result. A. Melnikov. March 2008. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5182) 5183 Sieve Email Filtering: Environment Extension. N. Freed. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5183) 5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover. F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani. May 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5184) 5185 OSPF Multi-Area Adjacency. S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5185) 5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction. B. Haberman, J. Martin. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5186) 5187 OSPFv3 Graceful Restart. P. Pillay-Esnault, A. Lindem. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5187) 5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec. H. Desineni, Q. Xie. February 2008. (Format: TXT, HTML) (Updates RFC4788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5188) 5189 Middlebox Communication (MIDCOM) Protocol Semantics. M. Stiemerling, J. Quittek, T. Taylor. March 2008. (Format: TXT, HTML) (Obsoletes RFC3989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5189) 5190 Definitions of Managed Objects for Middlebox Communication. J. Quittek, M. Stiemerling, P. Srisuresh. March 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5190) 5191 Protocol for Carrying Authentication for Network Access (PANA). D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin. May 2008. (Format: TXT, HTML) (Updated by RFC5872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5191) 5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents. L. Morand, A. Yegin, S. Kumar, S. Madanapalli. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5192) 5193 Protocol for Carrying Authentication for Network Access (PANA) Framework. P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A. Yegin. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5193) 5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). A. van Wijk, Ed., G. Gybels, Ed.. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5194) 5195 BGP-Based Auto-Discovery for Layer-1 VPNs. H. Ould-Brahim, D. Fedyk, Y. Rekhter. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5195) 5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF). M. Lonnfors, K. Kiss. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5196) 5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions. S. Fries, D. Ignjatic. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5197) 5198 Unicode Format for Network Interchange. J. Klensin, M. Padlipsky. March 2008. (Format: TXT, HTML) (Obsoletes RFC0698) (Updates RFC0854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5198) 5199 Not Issued. 5200 Not Issued. 5201 Host Identity Protocol. R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. April 2008. (Format: TXT, HTML) (Obsoleted by RFC7401) (Updated by RFC6253) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5201) 5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, P. Nikander. April 2008. (Format: TXT, HTML) (Obsoleted by RFC7402) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5202) 5203 Host Identity Protocol (HIP) Registration Extension. J. Laganier, T. Koponen, L. Eggert. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8003) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5203) 5204 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8004) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5204) 5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions. P. Nikander, J. Laganier. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8005) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5205) 5206 End-Host Mobility and Multihoming with the Host Identity Protocol. P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. April 2008. (Format: TXT, HTML) (Obsoleted by RFC8046) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5206) 5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication. M. Stiemerling, J. Quittek, L. Eggert. April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5207) 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2. B. Kaliski. May 2008. (Format: TXT, HTML) (Obsoleted by RFC5958) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5208) 5209 Network Endpoint Assessment (NEA): Overview and Requirements. P. Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5209) 5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience. J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams. June 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5210) 5211 An Internet Transition Plan. J. Curran. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5211) 5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN). K. Shiomoto, D. Papadimitriou, JL. Le Roux, M. Vigoureux, D. Brungard. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5212) 5213 Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. August 2008. (Format: TXT, HTML) (Updated by RFC6543, RFC7864) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5213) 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin, T. Gleeson, D. Thaler. March 2008. (Format: TXT, HTML) (Obsoletes RFC4214) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5214) 5215 RTP Payload Format for Vorbis Encoded Audio. L. Barbato. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5215) 5216 The EAP-TLS Authentication Protocol. D. Simon, B. Aboba, R. Hurst. March 2008. (Format: TXT, HTML) (Obsoletes RFC2716) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5216) 5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability. M. Shimaoka, Ed., N. Hastings, R. Nielsen. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5217) 5218 What Makes for a Successful Protocol?. D. Thaler, B. Aboba. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5218) 5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio. R. Finlayson. February 2008. (Format: TXT, HTML) (Obsoletes RFC3119) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5219) 5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5220) 5221 Requirements for Address Selection Mechanisms. A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5221) 5222 LoST: A Location-to-Service Translation Protocol. T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig. August 2008. (Format: TXT, HTML) (Updated by RFC6848, RFC8917) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5222) 5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP). H. Schulzrinne, J. Polk, H. Tschofenig. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5223) 5224 Diameter Policy Processing Application. M. Brenner. March 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5224) 5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite. G. Pelletier, K. Sandlund. April 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5225) 5226 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. May 2008. (Format: TXT, HTML) (Obsoletes RFC2434) (Obsoleted by RFC8126) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5226) 5227 IPv4 Address Conflict Detection. S. Cheshire. July 2008. (Format: TXT, HTML) (Updates RFC0826) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5227) 5228 Sieve: An Email Filtering Language. P. Guenther, Ed., T. Showalter, Ed.. January 2008. (Format: TXT, HTML) (Obsoletes RFC3028) (Updated by RFC5229, RFC5429, RFC6785) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5228) 5229 Sieve Email Filtering: Variables Extension. K. Homme. January 2008. (Format: TXT, HTML) (Updates RFC5228) (Updated by RFC5173) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5229) 5230 Sieve Email Filtering: Vacation Extension. T. Showalter, N. Freed, Ed.. January 2008. (Format: TXT, HTML) (Updated by RFC8580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5230) 5231 Sieve Email Filtering: Relational Extension. W. Segmuller, B. Leiba. January 2008. (Format: TXT, HTML) (Obsoletes RFC3431) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5231) 5232 Sieve Email Filtering: Imap4flags Extension. A. Melnikov. January 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5232) 5233 Sieve Email Filtering: Subaddress Extension. K. Murchison. January 2008. (Format: TXT, HTML) (Obsoletes RFC3598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5233) 5234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. January 2008. (Format: TXT, HTML) (Obsoletes RFC4234) (Updated by RFC7405) (Also STD0068) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5234) 5235 Sieve Email Filtering: Spamtest and Virustest Extensions. C. Daboo. January 2008. (Format: TXT, HTML) (Obsoletes RFC3685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5235) 5236 Improved Packet Reordering Metrics. A. Jayasumana, N. Piratla, T. Banka, A. Bare, R. Whitner. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5236) 5237 IANA Allocation Guidelines for the Protocol Field. J. Arkko, S. Bradner. February 2008. (Format: TXT, HTML) (Updates RFC2780) (Also BCP0037) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5237) 5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). T. Phelan. May 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5238) 5239 A Framework for Centralized Conferencing. M. Barnes, C. Boulton, O. Levin. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5239) 5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB. B. Joshi, R. Bijlani. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5240) 5241 Naming Rights in IETF Protocols. A. Falk, S. Bradner. 1 April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5241) 5242 A Generalized Unified Character Code: Western European and CJK Sections. J. Klensin, H. Alvestrand. 1 April 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5242) 5243 OSPF Database Exchange Summary List Optimization. R. Ogier. May 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5243) 5244 Definition of Events for Channel-Oriented Telephony Signalling. H. Schulzrinne, T. Taylor. June 2008. (Format: TXT, HTML) (Updates RFC4733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5244) 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. J. Rosenberg. April 2010. (Format: TXT, HTML) (Obsoletes RFC4091, RFC4092) (Obsoleted by RFC8445) (Updated by RFC6336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5245) 5246 The Transport Layer Security (TLS) Protocol Version 1.2. T. Dierks, E. Rescorla. August 2008. (Format: TXT, HTML) (Obsoletes RFC3268, RFC4346, RFC4366) (Obsoleted by RFC8446) (Updates RFC4492) (Updated by RFC5746, RFC5878, RFC6176, RFC7465, RFC7507, RFC7568, RFC7627, RFC7685, RFC7905, RFC7919, RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5246) 5247 Extensible Authentication Protocol (EAP) Key Management Framework. B. Aboba, D. Simon, P. Eronen. August 2008. (Format: TXT, HTML) (Updates RFC3748) (Updated by RFC8940) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5247) 5248 A Registry for SMTP Enhanced Mail System Status Codes. T. Hansen, J. Klensin. June 2008. (Format: TXT, HTML) (Updates RFC3463, RFC4468, RFC4954) (Also BCP0138) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5248) 5249 Templates for Internet-Drafts Containing MIB Modules. D. Harrington, Ed.. July 2008. (Format: TXT, HTML) (Also BCP0139) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5249) 5250 The OSPF Opaque LSA Option. L. Berger, I. Bryskin, A. Zinin, R. Coltun. July 2008. (Format: TXT, HTML) (Obsoletes RFC2370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5250) 5251 Layer 1 VPN Basic Mode. D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, R. Rabbat, L. Berger. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5251) 5252 OSPF-Based Layer 1 VPN Auto-Discovery. I. Bryskin, L. Berger. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5252) 5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode. T. Takeda, Ed.. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5253) 5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3). N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed.. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5254) 5255 Internet Message Access Protocol Internationalization. C. Newman, A. Gulbrandsen, A. Melnikov. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5255) 5256 Internet Message Access Protocol - SORT and THREAD Extensions. M. Crispin, K. Murchison. June 2008. (Format: TXT, HTML) (Updated by RFC5957) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5256) 5257 Internet Message Access Protocol - ANNOTATE Extension. C. Daboo, R. Gellens. June 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5257) 5258 Internet Message Access Protocol version 4 - LIST Command Extensions. B. Leiba, A. Melnikov. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5258) 5259 Internet Message Access Protocol - CONVERT Extension. A. Melnikov, Ed., P. Coates, Ed.. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5259) 5260 Sieve Email Filtering: Date and Index Extensions. N. Freed. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5260) 5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors. J. Urpalainen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5261) 5262 Presence Information Data Format (PIDF) Extension for Partial Presence. M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5262) 5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information. M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5263) 5264 Publication of Partial Presence Information. A. Niemi, M. Lonnfors, E. Leppanen. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5264) 5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways. S. Vaarala, E. Klovning. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5265) 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT, HTML) (Also BCP0136) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5266) 5267 Contexts for IMAP4. D. Cridland, C. King. July 2008. (Format: TXT, HTML) (Updated by RFC5465) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5267) 5268 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. June 2008. (Format: TXT, HTML) (Obsoletes RFC4068) (Obsoleted by RFC5568) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5268) 5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND). J. Kempf, R. Koodli. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5269) 5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. H. Jang, J. Jee, Y. Han, S. Park, J. Cha. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5270) 5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks. H. Yokota, G. Dommety. June 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5271) 5272 Certificate Management over CMS (CMC). J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (Obsoletes RFC2797) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5272) 5273 Certificate Management over CMS (CMC): Transport Protocols. J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5273) 5274 Certificate Management Messages over CMS (CMC): Compliance Requirements. J. Schaad, M. Myers. June 2008. (Format: TXT, HTML) (Updated by RFC6402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5274) 5275 CMS Symmetric Key Management and Distribution. S. Turner. June 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5275) 5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records. C. Wallace. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5276) 5277 NETCONF Event Notifications. S. Chisholm, H. Trevino. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5277) 5278 IANA Registration of Enumservices for Voice and Video Messaging. J. Livingood, D. Troshynski. July 2008. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5278) 5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP). A. Monrad, S. Loreto. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5279) 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. May 2008. (Format: TXT, HTML) (Obsoletes RFC3280, RFC4325, RFC4630) (Updated by RFC6818, RFC8398, RFC8399) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5280) 5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0). P. Funk, S. Blake-Wilson. August 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5281) 5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol. D. Black, D. McGrew. August 2008. (Format: TXT, HTML) (Updates RFC4306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5282) 5283 LDP Extension for Inter-Area Label Switched Paths (LSPs). B. Decraene, JL. Le Roux, I. Minei. July 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5283) 5284 User-Defined Errors for RSVP. G. Swallow, A. Farrel. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5284) 5285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni. July 2008. (Format: TXT, HTML) (Obsoleted by RFC8285) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5285) 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates. A. Atlas, Ed., A. Zinin, Ed.. September 2008. (Format: TXT, HTML) (Updated by RFC8518) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5286) 5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks. A. Vainshtein, Y(J). Stein. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5287) 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS. J. Salowey, A. Choudhury, D. McGrew. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5288) 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM). E. Rescorla. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5289) 5290 Comments on the Usefulness of Simple Best-Effort Traffic. S. Floyd, M. Allman. July 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5290) 5291 Outbound Route Filtering Capability for BGP-4. E. Chen, Y. Rekhter. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5291) 5292 Address-Prefix-Based Outbound Route Filter for BGP-4. E. Chen, S. Sangli. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5292) 5293 Sieve Email Filtering: Editheader Extension. J. Degener, P. Guenther. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5293) 5294 Host Threats to Protocol Independent Multicast (PIM). P. Savola, J. Lingard. August 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5294) 5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK). J. Salowey, L. Dondeti, V. Narayanan, M. Nakhjiri. August 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5295) 5296 EAP Extensions for EAP Re-authentication Protocol (ERP). V. Narayanan, L. Dondeti. August 2008. (Format: TXT, HTML) (Obsoleted by RFC6696) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5296) 5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES). D. Harkins. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5297) 5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery. T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur. August 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5298) 5299 Not Issued. 5300 Not Issued. 5301 Dynamic Hostname Exchange Mechanism for IS-IS. D. McPherson, N. Shen. October 2008. (Format: TXT, HTML) (Obsoletes RFC2763) (Updated by RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5301) 5302 Domain-Wide Prefix Distribution with Two-Level IS-IS. T. Li, H. Smit, T. Przygienda. October 2008. (Format: TXT, HTML) (Obsoletes RFC2966) (Updates RFC1195) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5302) 5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies. D. Katz, R. Saluja, D. Eastlake 3rd. October 2008. (Format: TXT, HTML) (Obsoletes RFC3373) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5303) 5304 IS-IS Cryptographic Authentication. T. Li, R. Atkinson. October 2008. (Format: TXT, HTML) (Obsoletes RFC3567) (Updates RFC1195) (Updated by RFC6233, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5304) 5305 IS-IS Extensions for Traffic Engineering. T. Li, H. Smit. October 2008. (Format: TXT, HTML) (Obsoletes RFC3784) (Updated by RFC5307, RFC8918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5305) 5306 Restart Signaling for IS-IS. M. Shand, L. Ginsberg. October 2008. (Format: TXT, HTML) (Obsoletes RFC3847) (Obsoleted by RFC8706) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5306) 5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). K. Kompella, Ed., Y. Rekhter, Ed.. October 2008. (Format: TXT, HTML) (Obsoletes RFC4205) (Updates RFC5305) (Updated by RFC6001, RFC6002, RFC7074) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5307) 5308 Routing IPv6 with IS-IS. C. Hopps. October 2008. (Format: TXT, HTML) (Updated by RFC7775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5308) 5309 Point-to-Point Operation over LAN in Link State Routing Protocols. N. Shen, Ed., A. Zinin, Ed.. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5309) 5310 IS-IS Generic Cryptographic Authentication. M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto. February 2009. (Format: TXT, HTML) (Updated by RFC6233, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5310) 5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS. D. McPherson, Ed., L. Ginsberg, S. Previdi, M. Shand. February 2009. (Format: TXT, HTML) (Obsoletes RFC3786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5311) 5312 Not Issued. 5313 Not Issued. 5314 Not Issued. 5315 Not Issued. 5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. M. Chen, R. Zhang, X. Duan. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5316) 5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile. S. Bryant, Ed., L. Andersson, Ed.. February 2009. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5317) 5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). J. Hautakorpi, G. Camarillo. December 2008. (Format: TXT, HTML) (Updated by RFC8217) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5318) 5319 Not Issued. 5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL). F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5320) 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT, HTML) (Obsoletes RFC2821) (Updates RFC1123) (Updated by RFC7504) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5321) 5322 Internet Message Format. P. Resnick, Ed.. October 2008. (Format: TXT, HTML) (Obsoletes RFC2822) (Updates RFC4021) (Updated by RFC6854) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5322) 5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH. J. Reschke, Ed., S. Reddy, J. Davis, A. Babich. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5323) 5324 MIB for Fibre-Channel Security Protocols (FC-SP). C. DeSanti, F. Maino, K. McCloghrie. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5324) 5325 Licklider Transmission Protocol - Motivation. S. Burleigh, M. Ramadas, S. Farrell. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5325) 5326 Licklider Transmission Protocol - Specification. M. Ramadas, S. Burleigh, S. Farrell. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5326) 5327 Licklider Transmission Protocol - Security Extensions. S. Farrell, M. Ramadas, S. Burleigh. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5327) 5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB). A. Adolf, P. MacAvock. September 2008. (Format: TXT, HTML) (Updated by RFC7354, RFC8553) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5328) 5329 Traffic Engineering Extensions to OSPF Version 3. K. Ishiguro, V. Manral, A. Davey, A. Lindem, Ed.. September 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5329) 5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link. JP. Vasseur, Ed., M. Meyer, K. Kumaki, A. Bonda. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5330) 5331 MPLS Upstream Label Assignment and Context-Specific Label Space. R. Aggarwal, Y. Rekhter, E. Rosen. August 2008. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5331) 5332 MPLS Multicast Encapsulations. T. Eckert, E. Rosen, Ed., R. Aggarwal, Y. Rekhter. August 2008. (Format: TXT, HTML) (Updates RFC3032, RFC4023) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5332) 5333 IANA Registration of Enumservices for Internet Calendaring. R. Mahy, B. Hoeneisen. October 2009. (Format: TXT, HTML) (Updated by RFC6118) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5333) 5334 Ogg Media Types. I. Goncalves, S. Pfeiffer, C. Montgomery. September 2008. (Format: TXT, HTML) (Obsoletes RFC3534) (Updated by RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5334) 5335 Internationalized Email Headers. A. Yang, Ed.. September 2008. (Format: TXT, HTML) (Obsoleted by RFC6532) (Updates RFC2045, RFC2822) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5335) 5336 SMTP Extension for Internationalized Email Addresses. J. Yao, Ed., W. Mao, Ed.. September 2008. (Format: TXT, HTML) (Obsoleted by RFC6531) (Updates RFC2821, RFC2822, RFC4952) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5336) 5337 Internationalized Delivery Status and Disposition Notifications. C. Newman, A. Melnikov, Ed.. September 2008. (Format: TXT, HTML) (Obsoleted by RFC6533) (Updates RFC3461, RFC3462, RFC3464, RFC3798) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5337) 5338 Using the Host Identity Protocol with Legacy Applications. T. Henderson, P. Nikander, M. Komu. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5338) 5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN). JL. Le Roux, Ed., D. Papadimitriou, Ed.. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5339) 5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July 2008. (Format: TXT, HTML) (Obsoletes RFC2740) (Updated by RFC6845, RFC6860, RFC7503, RFC8362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5340) 5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry. C. Jennings, V. Gurbani. September 2008. (Format: TXT, HTML) (Updates RFC3966) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5341) 5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters. D. Eastlake 3rd. September 2008. (Format: TXT, HTML) (Obsoleted by RFC7042) (Updates RFC2153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5342) 5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery. J. Schoenwaelder. September 2008. (Format: TXT, HTML) (Updates RFC3411) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5343) 5344 Presence and Instant Messaging Peering Use Cases. A. Houri, E. Aoki, S. Parameswar. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5344) 5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats. J. Schoenwaelder. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5345) 5346 Operational Requirements for ENUM-Based Softswitch Use. J. Lim, W. Kim, C. Park, L. Conroy. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5346) 5347 Media Gateway Control Protocol Fax Package. F. Andreasen, D. Hancock. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5347) 5348 TCP Friendly Rate Control (TFRC): Protocol Specification. S. Floyd, M. Handley, J. Padhye, J. Widmer. September 2008. (Format: TXT, HTML) (Obsoletes RFC3448) (Updates RFC4342) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5348) 5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). L. Zhu, K. Jaganathan, K. Lauter. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5349) 5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options. J. Manner, A. McDonald. September 2008. (Format: TXT, HTML) (Updates RFC2113, RFC3175) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5350) 5351 An Overview of Reliable Server Pooling Protocols. P. Lei, L. Ong, M. Tuexen, T. Dreibholz. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5351) 5352 Aggregate Server Access Protocol (ASAP). R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5352) 5353 Endpoint Handlespace Redundancy Protocol (ENRP). Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5353) 5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters. R. Stewart, Q. Xie, M. Stillman, M. Tuexen. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5354) 5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats. M. Stillman, Ed., R. Gopal, E. Guttman, S. Sengodan, M. Holdrege. September 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5355) 5356 Reliable Server Pooling Policies. T. Dreibholz, M. Tuexen. September 2008. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5356) 5357 A Two-Way Active Measurement Protocol (TWAMP). K. Hedayat, R. Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008. (Format: TXT, HTML) (Updated by RFC5618, RFC5938, RFC6038, RFC7717, RFC7750, RFC8545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5357) 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT, HTML) (Also BCP0140) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5358) 5359 Session Initiation Protocol Service Examples. A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. October 2008. (Format: TXT, HTML) (Also BCP0144) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5359) 5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP). J. Rosenberg, G. Camarillo, Ed., D. Willis. October 2008. (Format: TXT, HTML) (Updated by RFC8217) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5360) 5361 A Document Format for Requesting Consent. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5361) 5362 The Session Initiation Protocol (SIP) Pending Additions Event Package. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5362) 5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services. G. Camarillo, A.B. Roach. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5363) 5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists. M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5364) 5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP). M. Garcia-Martin, G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5365) 5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP). G. Camarillo, A. Johnston. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5366) 5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP). G. Camarillo, A.B. Roach, O. Levin. October 2008. (Format: TXT, HTML) (Updates RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5367) 5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP). G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin, H. Khartabil. October 2008. (Format: TXT, HTML) (Updated by RFC8262) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5368) 5369 Framework for Transcoding with the Session Initiation Protocol (SIP). G. Camarillo. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5369) 5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model. G. Camarillo. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5370) 5371 RTP Payload Format for JPEG 2000 Video Streams. S. Futemma, E. Itakura, A. Leung. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5371) 5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery. A. Leung, S. Futemma, E. Itakura. October 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5372) 5373 Requesting Answering Modes for the Session Initiation Protocol (SIP). D. Willis, Ed., A. Allen. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5373) 5374 Multicast Extensions to the Security Architecture for the Internet Protocol. B. Weis, G. Gross, D. Ignjatic. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5374) 5375 IPv6 Unicast Address Assignment Considerations. G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5375) 5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP). N. Bitar, R. Zhang, K. Kumaki. November 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5376) 5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents. J. Halpern, Ed.. November 2008. (Format: TXT, HTML) (Obsoleted by RFC8721) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5377) 5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed., J. Contreras, Ed.. November 2008. (Format: TXT, HTML) (Obsoletes RFC3978, RFC4748) (Updates RFC2026) (Also BCP0078) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5378) 5379 Guidelines for Using the Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5379) 5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management. H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier. October 2008. (Format: TXT, HTML) (Obsoletes RFC4140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5380) 5381 Experience of Implementing NETCONF over SOAP. T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita. October 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5381) 5382 NAT Behavioral Requirements for TCP. S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. October 2008. (Format: TXT, HTML) (Updated by RFC7857) (Also BCP0142) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5382) 5383 Deployment Considerations for Lemonade-Compliant Mobile Email. R. Gellens. October 2008. (Format: TXT, HTML) (Also BCP0143) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5383) 5384 The Protocol Independent Multicast (PIM) Join Attribute Format. A. Boers, I. Wijnands, E. Rosen. November 2008. (Format: TXT, HTML) (Updated by RFC7887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5384) 5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs. J. Touch. February 2010. (Format: TXT, HTML) (Obsoletes RFC3285) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5385) 5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec. N. Williams, M. Richardson. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5386) 5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS). J. Touch, D. Black, Y. Wang. November 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5387) 5388 Information Model and XML Data Model for Traceroute Measurements. S. Niccolini, S. Tartarelli, J. Quittek, T. Dietz, M. Swany. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5388) 5389 Session Traversal Utilities for NAT (STUN). J. Rosenberg, R. Mahy, P. Matthews, D. Wing. October 2008. (Format: TXT, HTML) (Obsoletes RFC3489) (Obsoleted by RFC8489) (Updated by RFC7350, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5389) 5390 Requirements for Management of Overload in the Session Initiation Protocol. J. Rosenberg. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5390) 5391 RTP Payload Format for ITU-T Recommendation G.711.1. A. Sollaud. November 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5391) 5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering. M. Chen, R. Zhang, X. Duan. January 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5392) 5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. R. Sparks, Ed., S. Lawrence, A. Hawrylyshen, B. Campen. December 2008. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5393) 5394 Policy-Enabled Path Computation Framework. I. Bryskin, D. Papadimitriou, L. Berger, J. Ash. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5394) 5395 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. November 2008. (Format: TXT, HTML) (Obsoletes RFC2929) (Obsoleted by RFC6195) (Updates RFC1183, RFC3597) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5395) 5396 Textual Representation of Autonomous System (AS) Numbers. G. Huston, G. Michaelson. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5396) 5397 WebDAV Current Principal Extension. W. Sanchez, C. Daboo. December 2008. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5397) 5398 Autonomous System (AS) Number Reservation for Documentation Use. G. Huston. December 2008. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5398) 5399 Not Issued. 5400 Not Issued. 5401 Multicast Negative-Acknowledgment (NACK) Building Blocks. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2008. (Format: TXT, HTML) (Obsoletes RFC3941) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5401) 5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message. T. Harding, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5402) 5403 RPCSEC_GSS Version 2. M. Eisler. February 2009. (Format: TXT, HTML) (Updates RFC2203) (Updated by RFC7861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5403) 5404 RTP Payload Format for G.719. M. Westerlund, I. Johansson. January 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5404) 5405 Unicast UDP Usage Guidelines for Application Designers. L. Eggert, G. Fairhurst. November 2008. (Format: TXT, HTML) (Obsoleted by RFC8085) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5405) 5406 Guidelines for Specifying the Use of IPsec Version 2. S. Bellovin. February 2009. (Format: TXT, HTML) (Also BCP0146) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5406) 5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP). M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. December 2008. (Format: TXT, HTML) (Also BCP0147) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5407) 5408 Identity-Based Encryption Architecture and Supporting Data Structures. G. Appenzeller, L. Martin, M. Schertler. January 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5408) 5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS). L. Martin, M. Schertler. January 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5409) 5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0. A. Jerichow, Ed., L. Piron. January 2009. (Format: TXT, HTML) (Obsoletes RFC4909) (Updated by RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5410) 5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP). J. Rosenberg. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5411) 5412 Lightweight Access Point Protocol. P. Calhoun, R. Suri, N. Cam-Winget, M. Williams, S. Hares, B. O'Hara, S. Kelly. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5412) 5413 SLAPP: Secure Light Access Point Protocol. P. Narasimhan, D. Harkins, S. Ponnuswamy. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5413) 5414 Wireless LAN Control Protocol (WiCoP). S. Iino, S. Govindan, M. Sugiura, H. Cheng. February 2010. (Format: TXT, HTML) (Obsoleted by RFC5415) (Status: HISTORIC) (DOI: 10.17487/RFC5414) 5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification. P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. March 2009. (Format: TXT, HTML) (Obsoletes RFC5414) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5415) 5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11. P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5416) 5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option. P. Calhoun. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5417) 5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments. S. Kelly, T. Clancy. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5418) 5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6). B. Patil, G. Dommety. January 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5419) 5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE). A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangar. February 2009. (Format: TXT, HTML) (Obsoletes RFC4420) (Updates RFC3209, RFC3473) (Updated by RFC6510) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5420) 5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST). N. Cam-Winget, H. Zhou. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5421) 5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST). N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5422) 5423 Internet Message Store Events. R. Gellens, C. Newman. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5423) 5424 The Syslog Protocol. R. Gerhards. March 2009. (Format: TXT, HTML) (Obsoletes RFC3164) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5424) 5425 Transport Layer Security (TLS) Transport Mapping for Syslog. F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed.. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5425) 5426 Transmission of Syslog Messages over UDP. A. Okmianski. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5426) 5427 Textual Conventions for Syslog Management. G. Keeni. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5427) 5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices. S. Channabasappa, W. De Ketelaere, E. Nechamkin. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5428) 5429 Sieve Email Filtering: Reject and Extended Reject Extensions. A. Stone, Ed.. March 2009. (Format: TXT, HTML) (Obsoletes RFC3028) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5429) 5430 Suite B Profile for Transport Layer Security (TLS). M. Salter, E. Rescorla, R. Housley. March 2009. (Format: TXT, HTML) (Obsoleted by RFC6460) (Status: HISTORIC) (DOI: 10.17487/RFC5430) 5431 Diameter ITU-T Rw Policy Enforcement Interface Application. D. Sun. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5431) 5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP). J. Polk, S. Dhesikan, G. Camarillo. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5432) 5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method. T. Clancy, H. Tschofenig. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5433) 5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session. T. Narten. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5434) 5435 Sieve Email Filtering: Extension for Notifications. A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin. January 2009. (Format: TXT, HTML) (Updated by RFC8580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5435) 5436 Sieve Notification Mechanism: mailto. B. Leiba, M. Haardt. January 2009. (Format: TXT, HTML) (Updates RFC3834) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5436) 5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, A. Melnikov. January 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5437) 5438 Instant Message Disposition Notification (IMDN). E. Burger, H. Khartabil. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5438) 5439 An Analysis of Scaling Issues in MPLS-TE Core Networks. S. Yasukawa, A. Farrel, O. Komolafe. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5439) 5440 Path Computation Element (PCE) Communication Protocol (PCEP). JP. Vasseur, Ed., JL. Le Roux, Ed.. March 2009. (Format: TXT, HTML) (Updated by RFC7896, RFC8253, RFC8356) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5440) 5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths. JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5441) 5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail. E. Burger, G. Parsons. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5442) 5443 LDP IGP Synchronization. M. Jork, A. Atlas, L. Fang. March 2009. (Format: TXT, HTML) (Updated by RFC6138) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5443) 5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format. T. Clausen, C. Dearlove, J. Dean, C. Adjih. February 2009. (Format: TXT, HTML) (Updated by RFC7631, RFC8245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5444) 5445 Basic Forward Error Correction (FEC) Schemes. M. Watson. March 2009. (Format: TXT, HTML) (Obsoletes RFC3452, RFC3695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5445) 5446 Service Selection for Mobile IPv4. J. Korhonen, U. Nilsson. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5446) 5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5447) 5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA'). J. Arkko, V. Lehtovirta, P. Eronen. May 2009. (Format: TXT, HTML) (Updates RFC4187) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5448) 5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks. E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen. February 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5449) 5450 Transmission Time Offsets in RTP Streams. D. Singer, H. Desineni. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5450) 5451 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. April 2009. (Format: TXT, HTML) (Obsoleted by RFC7001) (Updated by RFC6577) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5451) 5452 Measures for Making DNS More Resilient against Forged Answers. A. Hubert, R. van Mook. January 2009. (Format: TXT, HTML) (Updates RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5452) 5453 Reserved IPv6 Interface Identifiers. S. Krishnan. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5453) 5454 Dual-Stack Mobile IPv4. G. Tsirtsis, V. Park, H. Soliman. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5454) 5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol. S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5455) 5456 IAX: Inter-Asterisk eXchange Version 2. M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5456) 5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2. E. Guy, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5457) 5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol. H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5458) 5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support. A. Sollaud. January 2009. (Format: TXT, HTML) (Updates RFC4749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5459) 5460 DHCPv6 Bulk Leasequery. M. Stapp. February 2009. (Format: TXT, HTML) (Updated by RFC7653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5460) 5461 TCP's Reaction to Soft Errors. F. Gont. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5461) 5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field. L. Andersson, R. Asati. February 2009. (Format: TXT, HTML) (Updates RFC3032, RFC3270, RFC3272, RFC3443, RFC3469, RFC3564, RFC3985, RFC4182, RFC4364, RFC4379, RFC4448, RFC4761, RFC5129) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5462) 5463 Sieve Email Filtering: Ihave Extension. N. Freed. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5463) 5464 The IMAP METADATA Extension. C. Daboo. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5464) 5465 The IMAP NOTIFY Extension. A. Gulbrandsen, C. King, A. Melnikov. February 2009. (Format: TXT, HTML) (Updates RFC5267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5465) 5466 IMAP4 Extension for Named Searches (Filters). A. Melnikov, C. King. February 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5466) 5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. March 2009. (Format: TXT, HTML) (Obsoleted by RFC6387) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5467) 5468 Performance Analysis of Inter-Domain Path Computation Methodologies. S. Dasgupta, J. de Oliveira, JP. Vasseur. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5468) 5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS). P. Eronen, Ed.. February 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5469) 5470 Architecture for IP Flow Information Export. G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. March 2009. (Format: TXT, HTML) (Updated by RFC6183) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5470) 5471 Guidelines for IP Flow Information Export (IPFIX) Testing. C. Schmoll, P. Aitken, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5471) 5472 IP Flow Information Export (IPFIX) Applicability. T. Zseby, E. Boschi, N. Brownlee, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5472) 5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports. E. Boschi, L. Mark, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5473) 5474 A Framework for Packet Selection and Reporting. N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5474) 5475 Sampling and Filtering Techniques for IP Packet Selection. T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5475) 5476 Packet Sampling (PSAMP) Protocol Specifications. B. Claise, Ed., A. Johnson, J. Quittek. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5476) 5477 Information Model for Packet Sampling Exports. T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5477) 5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces. J. Polk. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5478) 5479 Requirements and Analysis of Media Security Management Protocols. D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5479) 5480 Elliptic Curve Cryptography Subject Public Key Information. S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. March 2009. (Format: TXT, HTML) (Updates RFC3279) (Updated by RFC8813) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5480) 5481 Packet Delay Variation Applicability Statement. A. Morton, B. Claise. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5481) 5482 TCP User Timeout Option. L. Eggert, F. Gont. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5482) 5483 ENUM Implementation Issues and Experiences. L. Conroy, K. Fujiwara. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5483) 5484 Associating Time-Codes with RTP Streams. D. Singer. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5484) 5485 Digital Signatures on Internet-Draft Documents. R. Housley. March 2009. (Format: TXT, HTML) (Updated by RFC8358) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5485) 5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology. D. Malas, Ed., D. Meyer, Ed.. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5486) 5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode. M. Badra. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5487) 5488 Network Mobility (NEMO) Management Information Base. S. Gundavelli, G. Keeni, K. Koide, K. Nagami. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5488) 5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS). M. Badra, I. Hajjeh. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5489) 5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata. A. Melnikov. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5490) 5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations. J. Winterbottom, M. Thomson, H. Tschofenig. March 2009. (Format: TXT, HTML) (Updates RFC4119) (Updated by RFC7459) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5491) 5492 Capabilities Advertisement with BGP-4. J. Scudder, R. Chandra. February 2009. (Format: TXT, HTML) (Obsoletes RFC3392) (Updated by RFC8810) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5492) 5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network. D. Caviglia, D. Bramanti, D. Li, D. McDysan. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5493) 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP). J. Arkko, C. Pignataro. April 2009. (Format: TXT, HTML) (Updates RFC0826, RFC0951, RFC1044, RFC1329, RFC2131, RFC2132, RFC2176, RFC2225, RFC2834, RFC2835, RFC3315, RFC4338, RFC4361, RFC4701) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5494) 5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures. D. Li, J. Gao, A. Satyanarayana, S. Bardalai. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5495) 5496 The Reverse Path Forwarding (RPF) Vector TLV. IJ. Wijnands, A. Boers, E. Rosen. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5496) 5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs). T. Clausen, C. Dearlove. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5497) 5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols. I. Chakeres. March 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5498) 5499 Not Issued. 5500 Not Issued. 5501 Requirements for Multicast Support in Virtual Private LAN Services. Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang. March 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5501) 5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem. J. van Elburg. April 2009. (Format: TXT, HTML) (Updated by RFC8217, RFC8498) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5502) 5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. F. Andreasen, B. McKibben, B. Marshall. March 2009. (Format: TXT, HTML) (Obsoletes RFC3603) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5503) 5504 Downgrading Mechanism for Email Address Internationalization. K. Fujiwara, Ed., Y. Yoneya, Ed.. March 2009. (Format: TXT, HTML) (Obsoleted by RFC6530) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5504) 5505 Principles of Internet Host Configuration. B. Aboba, D. Thaler, L. Andersson, S. Cheshire. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5505) 5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences. I. Johansson, M. Westerlund. April 2009. (Format: TXT, HTML) (Updates RFC3550, RFC3711, RFC4585) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5506) 5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5507) 5508 NAT Behavioral Requirements for ICMP. P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. April 2009. (Format: TXT, HTML) (Updated by RFC7857) (Also BCP0148) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5508) 5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP). S. Loreto. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5509) 5510 Reed-Solomon Forward Error Correction (FEC) Schemes. J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5510) 5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications. A. Farrel. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5511) 5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute. P. Mohapatra, E. Rosen. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5512) 5513 IANA Considerations for Three Letter Acronyms. A. Farrel. 1 April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5513) 5514 IPv6 over Social Networks. E. Vyncke. 1 April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5514) 5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions. V. Mammoliti, C. Pignataro, P. Arberg, J. Gibbons, P. Howard. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5515) 5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). M. Jones, L. Morand. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5516) 5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment. S. HomChaudhuri, M. Foschiano. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5517) 5518 Vouch By Reference. P. Hoffman, J. Levine, A. Hathcock. April 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5518) 5519 Multicast Group Membership Discovery MIB. J. Chesterfield, B. Haberman, Ed.. April 2009. (Format: TXT, HTML) (Obsoletes RFC2933, RFC3019) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5519) 5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism. R. Bradford, Ed., JP. Vasseur, A. Farrel. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5520) 5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions. E. Oki, T. Takeda, A. Farrel. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5521) 5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks. W. Eddy, W. Ivancic, T. Davis. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5522) 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery. L. Berger. April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5523) 5524 Extended URLFETCH for Binary and Converted Parts. D. Cridland. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5524) 5525 Reliable Server Pooling MIB Module Definition. T. Dreibholz, J. Mulik. April 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5525) 5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM. J. Livingood, P. Pfautz, R. Stastny. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5526) 5527 Combined User and Infrastructure ENUM in the e164.arpa Tree. M. Haberler, O. Lendl, R. Stastny. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5527) 5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms. A. Kato, M. Kanda, S. Kanno. April 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5528) 5529 Modes of Operation for Camellia for Use with IPsec. A. Kato, M. Kanda, S. Kanno. April 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5529) 5530 IMAP Response Codes. A. Gulbrandsen. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5530) 5531 RPC: Remote Procedure Call Protocol Specification Version 2. R. Thurlow. May 2009. (Format: TXT, HTML) (Obsoletes RFC1831) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5531) 5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement. T. Talpey, C. Juszczak. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5532) 5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6. E. Nordmark, M. Bagnulo. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5533) 5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. J. Arkko, I. van Beijnum. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5534) 5535 Hash-Based Addresses (HBA). M. Bagnulo. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5535) 5536 Netnews Article Format. K. Murchison, Ed., C. Lindsey, D. Kohn. November 2009. (Format: TXT, HTML) (Obsoletes RFC1036, RFC1849) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5536) 5537 Netnews Architecture and Protocols. R. Allbery, Ed., C. Lindsey. November 2009. (Format: TXT, HTML) (Obsoletes RFC1036, RFC1849) (Updated by RFC8315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5537) 5538 The 'news' and 'nntp' URI Schemes. F. Ellermann. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5538) 5539 NETCONF over Transport Layer Security (TLS). M. Badra. May 2009. (Format: TXT, HTML) (Obsoleted by RFC7589) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5539) 5540 40 Years of RFCs. RFC Editor. April 2009. (Format: TXT, HTML) (Updated by RFC8700) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5540) 5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP). JL. Le Roux, JP. Vasseur, Y. Lee. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5541) 5542 Definitions of Textual Conventions for Pseudowire (PW) Management. T. Nadeau, Ed., D. Zelig, Ed., O. Nicklass, Ed.. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5542) 5543 BGP Traffic Engineering Attribute. H. Ould-Brahim, D. Fedyk, Y. Rekhter. May 2009. (Format: TXT, HTML) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5543) 5544 Syntax for Binding Documents with Time-Stamps. A. Santoni. February 2010. (Format: TXT, HTML) (Updated by RFC5955) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5544) 5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar). B. Desruisseaux, Ed.. September 2009. (Format: TXT, HTML) (Obsoletes RFC2445) (Updated by RFC5546, RFC6868, RFC7529, RFC7953, RFC7986) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5545) 5546 iCalendar Transport-Independent Interoperability Protocol (iTIP). C. Daboo, Ed.. December 2009. (Format: TXT, HTML) (Obsoletes RFC2446) (Updates RFC5545) (Updated by RFC6638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5546) 5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer. M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5547) 5548 Routing Requirements for Urban Low-Power and Lossy Networks. M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5548) 5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. F. Le Faucheur, E. Rosen. May 2009. (Format: TXT, HTML) (Obsoleted by RFC8950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5549) 5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile. D. Cridland, Ed., A. Melnikov, Ed., S. Maes, Ed.. August 2009. (Format: TXT, HTML) (Obsoletes RFC4550) (Updates RFC4469, RFC4467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5550) 5551 Lemonade Notifications Architecture. R. Gellens, Ed.. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5551) 5552 SIP Interface to VoiceXML Media Services. D. Burke, M. Scott. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5552) 5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support. A. Farrel, Ed., R. Bradford, JP. Vasseur. May 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5553) 5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings. N. Williams. May 2009. (Format: TXT, HTML) (Updates RFC2743) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5554) 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5555) 5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement. J. Touch, R. Perlman. May 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5556) 5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization. Y. Lee, JL. Le Roux, D. King, E. Oki. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5557) 5558 Virtual Enterprise Traversal (VET). F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5558) 5559 Pre-Congestion Notification (PCN) Architecture. P. Eardley, Ed.. June 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5559) 5560 A One-Way Packet Duplication Metric. H. Uijterwaal. May 2009. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5560) 5561 LDP Capabilities. B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5561) 5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets. A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan. June 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5562) 5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4. K. Leung, G. Dommety, P. Yegani, K. Chowdhury. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5563) 5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains. A. El-Sherbiny, M. Farah, I. Oueichek, A. Al-Zoman. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5564) 5565 Softwire Mesh Framework. J. Wu, Y. Cui, C. Metz, E. Rosen. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5565) 5566 BGP IPsec Tunnel Encapsulation Attribute. L. Berger, R. White, E. Rosen. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5566) 5567 An Architectural Framework for Media Server Control. T. Melanchuk, Ed.. June 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5567) 5568 Mobile IPv6 Fast Handovers. R. Koodli, Ed.. July 2009. (Format: TXT, HTML) (Obsoletes RFC5268) (Updated by RFC7411) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5568) 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). R. Despres. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5569) 5570 Common Architecture Label IPv6 Security Option (CALIPSO). M. StJohns, R. Atkinson, G. Thomas. July 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5570) 5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2). B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5571) 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). M. Blanchet, F. Parent. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5572) 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP). M. Thomson. June 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5573) 5574 RTP Payload Format for the Speex Codec. G. Herlein, J. Valin, A. Heggestad, A. Moizard. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5574) 5575 Dissemination of Flow Specification Rules. P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. August 2009. (Format: TXT, HTML) (Updated by RFC7674) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5575) 5576 Source-Specific Media Attributes in the Session Description Protocol (SDP). J. Lennox, J. Ott, T. Schierl. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5576) 5577 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi, R. Even. July 2009. (Format: TXT, HTML) (Obsoletes RFC3047) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5577) 5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics. B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams. February 2010. (Format: TXT, HTML) (Obsoletes RFC4938) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5578) 5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces. F. Templin, Ed.. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5579) 5580 Carrying Location Objects in RADIUS and Diameter. H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. August 2009. (Format: TXT, HTML) (Updated by RFC8559) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5580) 5581 The Camellia Cipher in OpenPGP. D. Shaw. June 2009. (Format: TXT, HTML) (Updates RFC4880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5581) 5582 Location-to-URL Mapping Architecture and Framework. H. Schulzrinne. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5582) 5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP). T. Schierl, S. Wenger. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5583) 5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family. M. Hatanaka, J. Matsumoto. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5584) 5585 DomainKeys Identified Mail (DKIM) Service Overview. T. Hansen, D. Crocker, P. Hallam-Baker. July 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5585) 5586 MPLS Generic Associated Channel. M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. June 2009. (Format: TXT, HTML) (Updates RFC3032, RFC4385, RFC5085) (Updated by RFC6423, RFC7026, RFC7214, RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5586) 5587 Extended Generic Security Service Mechanism Inquiry APIs. N. Williams. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5587) 5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials. N. Williams. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5588) 5589 Session Initiation Protocol (SIP) Call Control - Transfer. R. Sparks, A. Johnston, Ed., D. Petrie. June 2009. (Format: TXT, HTML) (Also BCP0149) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5589) 5590 Transport Subsystem for the Simple Network Management Protocol (SNMP). D. Harrington, J. Schoenwaelder. June 2009. (Format: TXT, HTML) (Updates RFC3411, RFC3412, RFC3414, RFC3417) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5590) 5591 Transport Security Model for the Simple Network Management Protocol (SNMP). D. Harrington, W. Hardaker. June 2009. (Format: TXT, HTML) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5591) 5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP). D. Harrington, J. Salowey, W. Hardaker. June 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5592) 5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension. N. Cook. June 2009. (Format: TXT, HTML) (Updates RFC5092) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5593) 5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008. J. Peterson, A. Cooper. July 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5594) 5595 The Datagram Congestion Control Protocol (DCCP) Service Codes. G. Fairhurst. September 2009. (Format: TXT, HTML) (Updates RFC4340) (Updated by RFC6335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5595) 5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal. G. Fairhurst. September 2009. (Format: TXT, HTML) (Updates RFC4340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5596) 5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol. R. Denis-Courmont. September 2009. (Format: TXT, HTML) (Also BCP0150) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5597) 5598 Internet Mail Architecture. D. Crocker. July 2009. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5598) 5599 Not Issued. 5600 Not Issued. 5601 Pseudowire (PW) Management Information Base (MIB). T. Nadeau, Ed., D. Zelig, Ed.. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5601) 5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB). D. Zelig, Ed., T. Nadeau, Ed.. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5602) 5603 Ethernet Pseudowire (PW) Management Information Base (MIB). D. Zelig, Ed., T. Nadeau, Ed.. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5603) 5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs). O. Nicklass. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5604) 5605 Managed Objects for ATM over Packet Switched Networks (PSNs). O. Nicklass, T. Nadeau. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5605) 5606 Implications of 'retransmission-allowed' for SIP Location Conveyance. J. Peterson, T. Hardie, J. Morris. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5606) 5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management. D. Nelson, G. Weber. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5607) 5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models. K. Narayan, D. Nelson. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5608) 5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA). V. Fajardo, Ed., Y. Ohba, R. Marin-Lopez. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5609) 5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements. E. Boschi, B. Trammell, L. Mark, T. Zseby. July 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5610) 5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires. A. Vainshtein, S. Galtzur. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5611) 5612 Enterprise Number for Documentation Use. P. Eronen, D. Harrington. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5612) 5613 OSPF Link-Local Signaling. A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung. August 2009. (Format: TXT, HTML) (Obsoletes RFC4813) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5613) 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding. R. Ogier, P. Spagnolo. August 2009. (Format: TXT, HTML) (Updated by RFC7038) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5614) 5615 H.248/MEGACO Registration Procedures. C. Groves, Y. Lin. August 2009. (Format: TXT, HTML) (Also BCP0151) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5615) 5616 Streaming Internet Messaging Attachments. N. Cook. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5616) 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). E. Allman, J. Fenton, M. Delany, J. Levine. August 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: HISTORIC) (DOI: 10.17487/RFC5617) 5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP). A. Morton, K. Hedayat. August 2009. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5618) 5619 Softwire Security Analysis and Requirements. S. Yamamoto, C. Williams, H. Yokota, F. Parent. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5619) 5620 RFC Editor Model (Version 1). O. Kolkman, Ed., IAB. August 2009. (Format: TXT, HTML) (Obsoleted by RFC6548, RFC6635) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5620) 5621 Message Body Handling in the Session Initiation Protocol (SIP). G. Camarillo. September 2009. (Format: TXT, HTML) (Updates RFC3204, RFC3261, RFC3459) (Updated by RFC8262) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5621) 5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP). S. Floyd, E. Kohler. August 2009. (Format: TXT, HTML) (Updated by RFC6323, RFC8311) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5622) 5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering. E. Oki, T. Takeda, JL. Le Roux, A. Farrel. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5623) 5624 Quality of Service Parameters for Usage with Diameter. J. Korhonen, Ed., H. Tschofenig, E. Davies. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5624) 5625 DNS Proxy Implementation Guidelines. R. Bellis. August 2009. (Format: TXT, HTML) (Also BCP0152) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5625) 5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). C. Jennings, Ed., R. Mahy, Ed., F. Audet, Ed.. October 2009. (Format: TXT, HTML) (Updates RFC3261, RFC3327) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5626) 5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP). J. Rosenberg. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5627) 5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs). P. Kyzivat. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5628) 5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP). J. Rosenberg. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5629) 5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP). F. Audet. October 2009. (Format: TXT, HTML) (Updates RFC3261, RFC3608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5630) 5631 Session Initiation Protocol (SIP) Session Mobility. R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5631) 5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial. C. Griffiths, J. Livingood, L. Popkin, R. Woundy, Y. Yang. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5632) 5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers. S. Dawkins, Ed.. August 2009. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5633) 5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP). G. Fairhurst, A. Sathiaseelan. August 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5634) 5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF). W. Kumari, D. McPherson. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5635) 5636 Traceable Anonymous Certificate. S. Park, H. Park, Y. Won, J. Lee, S. Kent. August 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5636) 5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6. G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5637) 5638 Simple SIP Usage Scenario for Applications in the Endpoints. H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5638) 5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation. M. Lochter, J. Merkle. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5639) 5640 Load-Balancing for Mesh Softwires. C. Filsfils, P. Mohapatra, C. Pignataro. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5640) 5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values. N. McGill, C. Pignataro. August 2009. (Format: TXT, HTML) (Updates RFC3931, RFC4349, RFC4454, RFC4591, RFC4719) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5641) 5642 Dynamic Hostname Exchange Mechanism for OSPF. S. Venkata, S. Harwani, C. Pignataro, D. McPherson. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5642) 5643 Management Information Base for OSPFv3. D. Joyal, Ed., V. Manral, Ed.. August 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5643) 5644 IP Performance Metrics (IPPM): Spatial and Multicast. E. Stephan, L. Liang, A. Morton. October 2009. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5644) 5645 Update to the Language Subtag Registry. D. Ewell, Ed.. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5645) 5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed.. September 2009. (Format: TXT, HTML) (Obsoletes RFC4646) (Also BCP0047) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5646) 5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol. K. Igoe, J. Solinas. August 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5647) 5648 Multiple Care-of Addresses Registration. R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. October 2009. (Format: TXT, HTML) (Updated by RFC6089) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5648) 5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm. R. Housley, M. Dworkin. September 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5649) 5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2). M. Morgenstern, S. Baillie, U. Bonollo. September 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5650) 5651 Layered Coding Transport (LCT) Building Block. M. Luby, M. Watson, L. Vicisano. October 2009. (Format: TXT, HTML) (Obsoletes RFC3451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5651) 5652 Cryptographic Message Syntax (CMS). R. Housley. September 2009. (Format: TXT, HTML) (Obsoletes RFC3852) (Updated by RFC8933) (Also STD0070) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5652) 5653 Generic Security Service API Version 2: Java Bindings Update. M. Upadhyay, S. Malkani. August 2009. (Format: TXT, HTML) (Obsoletes RFC2853) (Obsoleted by RFC8353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5653) 5654 Requirements of an MPLS Transport Profile. B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno. September 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5654) 5655 Specification of the IP Flow Information Export (IPFIX) File Format. B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5655) 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. D. Stebila, J. Green. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5656) 5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard. L. Dusseault, R. Sparks. September 2009. (Format: TXT, HTML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5657) 5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP). T. Froment, C. Lebel, B. Bonnaerens. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5658) 5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge. M. Bocci, S. Bryant. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5659) 5660 IPsec Channels: Connection Latching. N. Williams. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5660) 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol. S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8881) (Updated by RFC8178, RFC8434) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5661) 5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description. S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5662) 5663 Parallel NFS (pNFS) Block/Volume Layout. D. Black, S. Fridella, J. Glasgow. January 2010. (Format: TXT, HTML) (Updated by RFC6688) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5663) 5664 Object-Based Parallel NFS (pNFS) Operations. B. Halevy, B. Welch, J. Zelenka. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5664) 5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats. M. Eisler. January 2010. (Format: TXT, HTML) (Updates RFC1833) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5665) 5666 Remote Direct Memory Access Transport for Remote Procedure Call. T. Talpey, B. Callaghan. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5666) 5667 Network File System (NFS) Direct Data Placement. T. Talpey, B. Callaghan. January 2010. (Format: TXT, HTML) (Obsoleted by RFC8267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5667) 5668 4-Octet AS Specific BGP Extended Community. Y. Rekhter, S. Sangli, D. Tappan. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5668) 5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP). S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5669) 5670 Metering and Marking Behaviour of PCN-Nodes. P. Eardley, Ed.. November 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5670) 5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE). S. Yasukawa, A. Farrel, Ed.. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5671) 5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update. D. Crocker, Ed.. August 2009. (Format: TXT, HTML) (Obsoleted by RFC6376) (Updates RFC4871) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5672) 5673 Industrial Routing Requirements in Low-Power and Lossy Networks. K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5673) 5674 Alarms in Syslog. S. Chisholm, R. Gerhards. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5674) 5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages. V. Marinov, J. Schoenwaelder. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5675) 5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications. J. Schoenwaelder, A. Clemm, A. Karmakar. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5676) 5677 IEEE 802.21 Mobility Services Framework Design (MSFD). T. Melia, Ed., G. Bajko, S. Das, N. Golmie, JC. Zuniga. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5677) 5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery. G. Bajko, S. Das. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5678) 5679 Locating IEEE 802.21 Mobility Services Using DNS. G. Bajko. December 2009. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5679) 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees. S. Dawkins, Ed.. October 2009. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5680) 5681 TCP Congestion Control. M. Allman, V. Paxson, E. Blanton. September 2009. (Format: TXT, HTML) (Obsoletes RFC2581) (Status: DRAFT STANDARD) (DOI: 10.17487/RFC5681) 5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP. P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata. September 2009. (Format: TXT, HTML) (Updates RFC4138) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5682) 5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange. A. Brusilovsky, I. Faynberg, Z. Zeltsan, S. Patel. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5683) 5684 Unintended Consequences of NAT Deployments with Overlapping Address Space. P. Srisuresh, B. Ford. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5684) 5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2). V. Devarapalli, K. Weniger. November 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5685) 5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec. Y. Hiwasaki, H. Ohmuro. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5686) 5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements. H. Tschofenig, H. Schulzrinne. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5687) 5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes. J. Rosenberg. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5688) 5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV). C. Daboo. September 2009. (Format: TXT, HTML) (Updates RFC4791, RFC4918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5689) 5690 Adding Acknowledgement Congestion Control to TCP. S. Floyd, A. Arcia, D. Ros, J. Iyengar. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5690) 5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio. F. de Bont, S. Doehla, M. Schmidt, R. Sperschneider. October 2009. (Format: TXT, HTML) (Updates RFC3640) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5691) 5692 Transmission of IP over Ethernet over IEEE 802.16 Networks. H. Jeon, S. Jeong, M. Riegel. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5692) 5693 Application-Layer Traffic Optimization (ALTO) Problem Statement. J. Seedorf, E. Burger. October 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5693) 5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability. G. Camarillo, Ed., IAB. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5694) 5695 MPLS Forwarding Benchmarking Methodology for IP Flows. A. Akhter, R. Asati, C. Pignataro. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5695) 5696 Baseline Encoding and Transport of Pre-Congestion Information. T. Moncaster, B. Briscoe, M. Menth. November 2009. (Format: TXT, HTML) (Obsoleted by RFC6660) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5696) 5697 Other Certificates Extension. S. Farrell. November 2009. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5697) 5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC). T. Kunz, S. Okunick, U. Pordesch. November 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5698) 5699 Not Issued. 5700 Not Issued. 5701 IPv6 Address Specific BGP Extended Community Attribute. Y. Rekhter. November 2009. (Format: TXT, HTML) (Updated by RFC7153, RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5701) 5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC. J. Jansen. October 2009. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5702) 5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure. T. Hansen, C. Daboo. October 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5703) 5704 Uncoordinated Protocol Development Considered Harmful. S. Bryant, Ed., M. Morrow, Ed., IAB. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5704) 5705 Keying Material Exporters for Transport Layer Security (TLS). E. Rescorla. March 2010. (Format: TXT, HTML) (Updated by RFC8446, RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5705) 5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions. D. Harrington. November 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5706) 5707 Media Server Markup Language (MSML). A. Saleem, Y. Xin, G. Sharratt. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5707) 5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System. A. Keromytis. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5708) 5709 OSPFv2 HMAC-SHA Cryptographic Authentication. M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. October 2009. (Format: TXT, HTML) (Updates RFC2328) (Updated by RFC7474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5709) 5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes. L. Berger, D. Papadimitriou, JP. Vasseur. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5710) 5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages. JP. Vasseur, Ed., G. Swallow, I. Minei. January 2010. (Format: TXT, HTML) (Updates RFC3209) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5711) 5712 MPLS Traffic Engineering Soft Preemption. M. Meyer, Ed., JP. Vasseur, Ed.. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5712) 5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP). H. Moustafa, H. Tschofenig, S. De Cnodder. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5713) 5714 IP Fast Reroute Framework. M. Shand, S. Bryant. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5714) 5715 A Framework for Loop-Free Convergence. M. Shand, S. Bryant. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5715) 5716 Requirements for Federated File Systems. J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik. January 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5716) 5717 Partial Lock Remote Procedure Call (RPC) for NETCONF. B. Lengyel, M. Bjorklund. December 2009. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5717) 5718 An In-Band Data Communication Network For the MPLS Transport Profile. D. Beller, A. Farrel. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5718) 5719 Updated IANA Considerations for Diameter Command Code Allocations. D. Romascanu, H. Tschofenig. January 2010. (Format: TXT, HTML) (Obsoleted by RFC6733) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5719) 5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER). F. Templin. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5720) 5721 POP3 Support for UTF-8. R. Gellens, C. Newman. February 2010. (Format: TXT, HTML) (Obsoleted by RFC6856) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5721) 5722 Handling of Overlapping IPv6 Fragments. S. Krishnan. December 2009. (Format: TXT, HTML) (Updates RFC2460) (Updated by RFC6946) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5722) 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption. Y. Sheffer, H. Tschofenig. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5723) 5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS). E. Wilde, A. Vaha-Sipila. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5724) 5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs). A. Begen, D. Hsu, M. Lague. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5725) 5726 Mobile IPv6 Location Privacy Solutions. Y. Qiu, F. Zhao, Ed., R. Koodli. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5726) 5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area. J. Peterson, C. Jennings, R. Sparks. March 2010. (Format: TXT, HTML) (Obsoletes RFC3427) (Updates RFC3265, RFC3969) (Updated by RFC7957) (Also BCP0067) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5727) 5728 The SatLabs Group DVB-RCS MIB. S. Combes, P. Amundsen, M. Lambert, H-P. Lexow. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5728) 5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm. J. Korhonen, Ed., M. Jones, L. Morand, T. Tsou. December 2009. (Format: TXT, HTML) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5729) 5730 Extensible Provisioning Protocol (EPP). S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4930) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5730) 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4931) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5731) 5732 Extensible Provisioning Protocol (EPP) Host Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4932) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5732) 5733 Extensible Provisioning Protocol (EPP) Contact Mapping. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4933) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5733) 5734 Extensible Provisioning Protocol (EPP) Transport over TCP. S. Hollenbeck. August 2009. (Format: TXT, HTML) (Obsoletes RFC4934) (Also STD0069) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC5734) 5735 Special Use IPv4 Addresses. M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (Obsoletes RFC3330) (Obsoleted by RFC6890) (Updated by RFC6598) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5735) 5736 IANA IPv4 Special Purpose Address Registry. G. Huston, M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (Obsoleted by RFC6890) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5736) 5737 IPv4 Address Blocks Reserved for Documentation. J. Arkko, M. Cotton, L. Vegoda. January 2010. (Format: TXT, HTML) (Updates RFC1166) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5737) 5738 IMAP Support for UTF-8. P. Resnick, C. Newman. March 2010. (Format: TXT, HTML) (Obsoleted by RFC6855) (Updates RFC3501) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5738) 5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2). P. Eronen, J. Laganier, C. Madson. February 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5739) 5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol. B. Adamson, C. Bormann, M. Handley, J. Macker. November 2009. (Format: TXT, HTML) (Obsoletes RFC3940) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5740) 5741 RFC Streams, Headers, and Boilerplates. L. Daigle, Ed., O. Kolkman, Ed., IAB. December 2009. (Format: TXT, HTML) (Obsoleted by RFC7841) (Updates RFC2223, RFC4844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5741) 5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions. H. Alvestrand, R. Housley. December 2009. (Format: TXT, HTML) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5742) 5743 Definition of an Internet Research Task Force (IRTF) Document Stream. A. Falk. December 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5743) 5744 Procedures for Rights Handling in the RFC Independent Submission Stream. R. Braden, J. Halpern. December 2009. (Format: TXT, HTML) (Updates RFC4846) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5744) 5745 Procedures for Rights Handling in the RFC IAB Stream. A. Malis, Ed., IAB. December 2009. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5745) 5746 Transport Layer Security (TLS) Renegotiation Indication Extension. E. Rescorla, M. Ray, S. Dispensa, N. Oskov. February 2010. (Format: TXT, HTML) (Updates RFC5246, RFC4366, RFC4347, RFC4346, RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5746) 5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions. J. Wu, Y. Cui, X. Li, M. Xu, C. Metz. March 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5747) 5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY). S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5748) 5749 Distribution of EAP-Based Keys for Handover and Re-Authentication. K. Hoeper, Ed., M. Nakhjiri, Y. Ohba, Ed.. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5749) 5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling. B. Ramsdell, S. Turner. January 2010. (Format: TXT, HTML) (Obsoletes RFC3850) (Obsoleted by RFC8550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5750) 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification. B. Ramsdell, S. Turner. January 2010. (Format: TXT, HTML) (Obsoletes RFC3851) (Obsoleted by RFC8551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5751) 5752 Multiple Signatures in Cryptographic Message Syntax (CMS). S. Turner, J. Schaad. January 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5752) 5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS). S. Turner, D. Brown. January 2010. (Format: TXT, HTML) (Obsoletes RFC3278) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5753) 5754 Using SHA2 Algorithms with Cryptographic Message Syntax. S. Turner. January 2010. (Format: TXT, HTML) (Updates RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5754) 5755 An Internet Attribute Certificate Profile for Authorization. S. Farrell, R. Housley, S. Turner. January 2010. (Format: TXT, HTML) (Obsoletes RFC3281) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5755) 5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters. S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. January 2010. (Format: TXT, HTML) (Updates RFC4055) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5756) 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey. T. Schmidt, M. Waehlisch, G. Fairhurst. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5757) 5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA. Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk. January 2010. (Format: TXT, HTML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5758) 5759 Suite B Certificate and Certificate Revocation List (CRL) Profile. J. Solinas, L. Zieglar. January 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5759) 5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback. J. Ott, J. Chesterfield, E. Schooler. February 2010. (Format: TXT, HTML) (Updated by RFC6128) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5760) 5761 Multiplexing RTP Data and Control Packets on a Single Port. C. Perkins, M. Westerlund. April 2010. (Format: TXT, HTML) (Updates RFC3550, RFC3551) (Updated by RFC8035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5761) 5762 RTP and the Datagram Congestion Control Protocol (DCCP). C. Perkins. April 2010. (Format: TXT, HTML) (Updated by RFC6773) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5762) 5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS). J. Fischl, H. Tschofenig, E. Rescorla. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5763) 5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). D. McGrew, E. Rescorla. May 2010. (Format: TXT, HTML) (Updated by RFC7983) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5764) 5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications. H. Schulzrinne, E. Marocco, E. Ivov. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5765) 5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). R. Mahy, P. Matthews, J. Rosenberg. April 2010. (Format: TXT, HTML) (Obsoleted by RFC8656) (Updated by RFC8155, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5766) 5767 User-Agent-Driven Privacy Mechanism for SIP. M. Munakata, S. Schubert, T. Ohba. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5767) 5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP). J. Rosenberg. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5768) 5769 Test Vectors for Session Traversal Utilities for NAT (STUN). R. Denis-Courmont. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5769) 5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators. M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed.. April 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5770) 5771 IANA Guidelines for IPv4 Multicast Address Assignments. M. Cotton, L. Vegoda, D. Meyer. March 2010. (Format: TXT, HTML) (Obsoletes RFC3138, RFC3171) (Updates RFC2780) (Also BCP0051) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5771) 5772 A Set of Possible Requirements for a Future Routing Architecture. A. Doria, E. Davies, F. Kastenholz. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5772) 5773 Analysis of Inter-Domain Routing Requirements and History. E. Davies, A. Doria. February 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5773) 5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition. K. Wolf, A. Mayrhofer. March 2010. (Format: TXT, HTML) (Updates RFC4776) (Also BCP0154) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5774) 5775 Asynchronous Layered Coding (ALC) Protocol Instantiation. M. Luby, M. Watson, L. Vicisano. April 2010. (Format: TXT, HTML) (Obsoletes RFC3450) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5775) 5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca, A. Francillon, S. Faurite. April 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5776) 5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter. J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5777) 5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction. J. Korhonen, Ed., H. Tschofenig, J. Bournelle, G. Giaretta, M. Nakhjiri. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5778) 5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server. J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5779) 5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN). D. MacDonald, B. Lowekamp. May 2010. (Format: TXT, HTML) (Updated by RFC8553) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5780) 5781 The rsync URI Scheme. S. Weiler, D. Ward, R. Housley. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5781) 5782 DNS Blacklists and Whitelists. J. Levine. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5782) 5783 Congestion Control in the RFC Series. M. Welzl, W. Eddy. February 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5783) 5784 Sieve Email Filtering: Sieves and Display Directives in XML. N. Freed, S. Vedam. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5784) 5785 Defining Well-Known Uniform Resource Identifiers (URIs). M. Nottingham, E. Hammer-Lahav. April 2010. (Format: TXT, HTML) (Obsoleted by RFC8615) (Updates RFC2616, RFC2818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5785) 5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions. R. Aggarwal, K. Kompella. March 2010. (Format: TXT, HTML) (Updates RFC3630) (Updated by RFC6827, RFC8687) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5786) 5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing. D. Papadimitriou. March 2010. (Format: TXT, HTML) (Obsoleted by RFC6827) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5787) 5788 IMAP4 Keyword Registry. A. Melnikov, D. Cridland. March 2010. (Format: TXT, HTML) (Updated by RFC8621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5788) 5789 PATCH Method for HTTP. L. Dusseault, J. Snell. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5789) 5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols. H. Liu, W. Cao, H. Asaeda. February 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5790) 5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete. J. Reschke, J. Kunze. February 2010. (Format: TXT, HTML) (Obsoletes RFC2731) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5791) 5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC). P. Sangster, K. Narayan. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5792) 5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC). R. Sahita, S. Hanna, R. Hurst, K. Narayan. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5793) 5794 A Description of the ARIA Encryption Algorithm. J. Lee, J. Lee, J. Kim, D. Kwon, C. Kim. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5794) 5795 The RObust Header Compression (ROHC) Framework. K. Sandlund, G. Pelletier, L-E. Jonsson. March 2010. (Format: TXT, HTML) (Obsoletes RFC4995) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5795) 5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages. W. Atwood, S. Islam, M. Siami. March 2010. (Format: TXT, HTML) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5796) 5797 FTP Command and Extension Registry. J. Klensin, A. Hoenes. March 2010. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5797) 5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6. S. Nadas, Ed.. March 2010. (Format: TXT, HTML) (Obsoletes RFC3768) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5798) 5799 Not Issued. 5800 Not Issued. 5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family. S. Josefsson, N. Williams. July 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5801) 5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. C. Newman, A. Menon-Sen, A. Melnikov, N. Williams. July 2010. (Format: TXT, HTML) (Updated by RFC7677) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5802) 5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets. A. Melnikov. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5803) 5804 A Protocol for Remotely Managing Sieve Scripts. A. Melnikov, Ed., T. Martin. July 2010. (Format: TXT, HTML) (Updated by RFC7817, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5804) 5805 Lightweight Directory Access Protocol (LDAP) Transactions. K. Zeilenga. March 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5805) 5806 Diversion Indication in SIP. S. Levy, M. Mohali, Ed.. March 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC5806) 5807 Definition of Master Key between PANA Client and Enforcement Point. Y. Ohba, A. Yegin. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5807) 5808 Requirements for a Location-by-Reference Mechanism. R. Marshall, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5808) 5809 Not Issued. 5810 Forwarding and Control Element Separation (ForCES) Protocol Specification. A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern. March 2010. (Format: TXT, HTML) (Updated by RFC7121, RFC7391) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5810) 5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol. J. Hadi Salim, K. Ogawa. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5811) 5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model. J. Halpern, J. Hadi Salim. March 2010. (Format: TXT, HTML) (Updated by RFC7408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5812) 5813 Forwarding and Control Element Separation (ForCES) MIB. R. Haas. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5813) 5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks. W. Sun, Ed., G. Zhang, Ed.. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5814) 5815 Definitions of Managed Objects for IP Flow Information Export. T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. April 2010. (Format: TXT, HTML) (Obsoleted by RFC6615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5815) 5816 ESSCertIDv2 Update for RFC 3161. S. Santesson, N. Pope. April 2010. (Format: TXT, HTML) (Updates RFC3161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5816) 5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks. Z. Ali, JP. Vasseur, A. Zamfir, J. Newton. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5817) 5818 Data Channel Status Confirmation Extensions for the Link Management Protocol. D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia. April 2010. (Format: TXT, HTML) (Updated by RFC6898) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5818) 5819 IMAP4 Extension for Returning STATUS Information in Extended LIST. A. Melnikov, T. Sirainen. March 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5819) 5820 Extensions to OSPF to Support Mobile Ad Hoc Networking. A. Roy, Ed., M. Chandra, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC7137) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5820) 5821 Not Issued. 5822 Not Issued. 5823 Not Issued. 5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN. K. Kumaki, Ed., R. Zhang, Y. Kamite. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5824) 5825 Displaying Downgraded Messages for Email Address Internationalization. K. Fujiwara, B. Leiba. April 2010. (Format: TXT, HTML) (Obsoleted by RFC6530) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5825) 5826 Home Automation Routing Requirements in Low-Power and Lossy Networks. A. Brandt, J. Buron, G. Porcu. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5826) 5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP). M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig. May 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5827) 5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework. D. Fedyk, L. Berger, L. Andersson. March 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5828) 5829 Link Relation Types for Simple Version Navigation between Web Resources. A. Brown, G. Clemm, J. Reschke, Ed.. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5829) 5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC8891) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5830) 5831 GOST R 34.11-94: Hash Function Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC6986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5831) 5832 GOST R 34.10-2001: Digital Signature Algorithm. V. Dolmatov, Ed.. March 2010. (Format: TXT, HTML) (Updated by RFC7091) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5832) 5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB. Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5833) 5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11. Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5834) 5835 Framework for Metric Composition. A. Morton, Ed., S. Van den Berghe, Ed.. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5835) 5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement. Y. Ohba, Ed., Q. Wu, Ed., G. Zorn, Ed.. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5836) 5837 Extending ICMP for Interface and Next-Hop Identification. A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5837) 5838 Support of Address Families in OSPFv3. A. Lindem, Ed., S. Mirtorabi, A. Roy, M. Barnes, R. Aggarwal. April 2010. (Format: TXT, HTML) (Updated by RFC6969, RFC7949, RFC8362) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5838) 5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification. A. Niemi, D. Willis, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5839) 5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility. K. Grewal, G. Montenegro, M. Bhatia. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5840) 5841 TCP Option to Denote Packet Mood. R. Hay, W. Turkal. 1 April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5841) 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead. April 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5842) 5843 Additional Hash Algorithms for HTTP Instance Digests. A. Bryan. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5843) 5844 IPv4 Support for Proxy Mobile IPv6. R. Wakikawa, S. Gundavelli. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5844) 5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6. A. Muhanna, M. Khalil, S. Gundavelli, K. Leung. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5845) 5846 Binding Revocation for IPv6 Mobility. A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5846) 5847 Heartbeat Mechanism for Proxy Mobile IPv6. V. Devarapalli, Ed., R. Koodli, Ed., H. Lim, N. Kant, S. Krishnan, J. Laganier. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5847) 5848 Signed Syslog Messages. J. Kelsey, J. Callas, A. Clemm. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5848) 5849 The OAuth 1.0 Protocol. E. Hammer-Lahav, Ed.. April 2010. (Format: TXT, HTML) (Obsoleted by RFC6749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5849) 5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP). R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5850) 5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks. S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5851) 5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network. D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai. April 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5852) 5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments. J. Hautakorpi, Ed., G. Camarillo, R. Penfield, A. Hawrylyshen, M. Bhatia. April 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5853) 5854 The Metalink Download Description Format. A. Bryan, T. Tsujikawa, N. McNab, P. Poeml. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5854) 5855 Nameservers for IPv4 and IPv6 Reverse Zones. J. Abley, T. Manderson. May 2010. (Format: TXT, HTML) (Also BCP0155) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC5855) 5856 Integration of Robust Header Compression over IPsec Security Associations. E. Ertekin, R. Jasani, C. Christou, C. Bormann. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5856) 5857 IKEv2 Extensions to Support Robust Header Compression over IPsec. E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5857) 5858 IPsec Extensions to Support Robust Header Compression over IPsec. E. Ertekin, C. Christou, C. Bormann. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5858) 5859 TFTP Server Address Option for DHCPv4. R. Johnson. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5859) 5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks. M. Vigoureux, Ed., D. Ward, Ed., M. Betts, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5860) 5861 HTTP Cache-Control Extensions for Stale Content. M. Nottingham. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5861) 5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE. S. Yasukawa, A. Farrel. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5862) 5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations. T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5863) 5864 DNS SRV Resource Records for AFS. R. Allbery. April 2010. (Format: TXT, HTML) (Updates RFC1183) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5864) 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic. F. Baker, J. Polk, M. Dolly. May 2010. (Format: TXT, HTML) (Updates RFC4542, RFC4594) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5865) 5866 Diameter Quality-of-Service Application. D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5866) 5867 Building Automation Routing Requirements in Low-Power and Lossy Networks. J. Martocci, Ed., P. De Mil, N. Riou, W. Vermeylen. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5867) 5868 Problem Statement on the Cross-Realm Operation of Kerberos. S. Sakane, K. Kamada, S. Zrelli, M. Ishiyama. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5868) 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF). H. Krawczyk, P. Eronen. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5869) 5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI). A. Mayrhofer, C. Spanring. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5870) 5871 IANA Allocation Guidelines for the IPv6 Routing Header. J. Arkko, S. Bradner. May 2010. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5871) 5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA). J. Arkko, A. Yegin. May 2010. (Format: TXT, HTML) (Updates RFC5191) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5872) 5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA). Y. Ohba, A. Yegin. May 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5873) 5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources. J. Rosenberg, J. Urpalainen. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5874) 5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package. J. Urpalainen, D. Willis, Ed.. May 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5875) 5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP). J. Elwell. April 2010. (Format: TXT, HTML) (Updates RFC3325) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5876) 5877 The application/pkix-attr-cert Media Type for Attribute Certificates. R. Housley. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5877) 5878 Transport Layer Security (TLS) Authorization Extensions. M. Brown, R. Housley. May 2010. (Format: TXT, HTML) (Updates RFC5246) (Updated by RFC8447) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5878) 5879 Heuristics for Detecting ESP-NULL Packets. T. Kivinen, D. McDonald. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5879) 5880 Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Updated by RFC7419, RFC7880, RFC8562) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5880) 5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5881) 5882 Generic Application of Bidirectional Forwarding Detection (BFD). D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5882) 5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths. D. Katz, D. Ward. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5883) 5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs). R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow. June 2010. (Format: TXT, HTML) (Updates RFC1122) (Updated by RFC7726) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5884) 5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV). T. Nadeau, Ed., C. Pignataro, Ed.. June 2010. (Format: TXT, HTML) (Updated by RFC6478, RFC7885) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5885) 5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture. JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5886) 5887 Renumbering Still Needs Work. B. Carpenter, R. Atkinson, H. Flinck. May 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5887) 5888 The Session Description Protocol (SDP) Grouping Framework. G. Camarillo, H. Schulzrinne. June 2010. (Format: TXT, HTML) (Obsoletes RFC3388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5888) 5889 IP Addressing Model in Ad Hoc Networks. E. Baccelli, Ed., M. Townsley, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5889) 5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. (Format: TXT, HTML) (Obsoletes RFC3490) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5890) 5891 Internationalized Domain Names in Applications (IDNA): Protocol. J. Klensin. August 2010. (Format: TXT, HTML) (Obsoletes RFC3490, RFC3491) (Updates RFC3492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5891) 5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA). P. Faltstrom, Ed.. August 2010. (Format: TXT, HTML) (Updated by RFC8753) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5892) 5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA). H. Alvestrand, Ed., C. Karp. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5893) 5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale. J. Klensin. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5894) 5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008. P. Resnick, P. Hoffman. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5895) 5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy. L. Hornquist Astrand, S. Hartman. June 2010. (Format: TXT, HTML) (Updates RFC2743, RFC2744, RFC4120, RFC4121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5896) 5897 Identification of Communications Services in the Session Initiation Protocol (SIP). J. Rosenberg. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5897) 5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams. F. Andreasen, G. Camarillo, D. Oran, D. Wing. July 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5898) 5899 Not Issued. 5900 Not Issued. 5901 Extensions to the IODEF-Document Class for Reporting Phishing. P. Cain, D. Jevans. July 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5901) 5902 IAB Thoughts on IPv6 Network Address Translation. D. Thaler, L. Zhang, G. Lebovitz. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5902) 5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2. D. Fu, J. Solinas. June 2010. (Format: TXT, HTML) (Obsoletes RFC4753) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5903) 5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support. G. Zorn. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5904) 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification. D. Mills, J. Martin, Ed., J. Burbank, W. Kasch. June 2010. (Format: TXT, HTML) (Obsoletes RFC1305, RFC4330) (Updated by RFC7822, RFC8573) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5905) 5906 Network Time Protocol Version 4: Autokey Specification. B. Haberman, Ed., D. Mills. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5906) 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4). H. Gerstung, C. Elliott, B. Haberman, Ed.. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5907) 5908 Network Time Protocol (NTP) Server Option for DHCPv6. R. Gayraud, B. Lourdelet. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5908) 5909 Securing Neighbor Discovery Proxy: Problem Statement. J-M. Combes, S. Krishnan, G. Daley. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5909) 5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP). J. Gould, S. Hollenbeck. May 2010. (Format: TXT, HTML) (Obsoletes RFC4310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5910) 5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME. P. Hoffman, J. Schaad. June 2010. (Format: TXT, HTML) (Updated by RFC6268) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5911) 5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX). P. Hoffman, J. Schaad. June 2010. (Format: TXT, HTML) (Updated by RFC6960) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5912) 5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension. S. Turner, S. Chokhani. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5913) 5914 Trust Anchor Format. R. Housley, S. Ashmore, C. Wallace. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5914) 5915 Elliptic Curve Private Key Structure. S. Turner, D. Brown. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5915) 5916 Device Owner Attribute. S. Turner. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5916) 5917 Clearance Sponsor Attribute. S. Turner. June 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5917) 5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC). R. Asati, I. Minei, B. Thomas. August 2010. (Format: TXT, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5918) 5919 Signaling LDP Label Advertisement Completion. R. Asati, P. Mohapatra, E. Chen, B. Thomas. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5919) 5920 Security Framework for MPLS and GMPLS Networks. L. Fang, Ed.. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5920) 5921 A Framework for MPLS in Transport Networks. M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger. July 2010. (Format: TXT, HTML) (Updated by RFC6215, RFC7274) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5921) 5922 Domain Certificates in the Session Initiation Protocol (SIP). V. Gurbani, S. Lawrence, A. Jeffrey. June 2010. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5922) 5923 Connection Reuse in the Session Initiation Protocol (SIP). V. Gurbani, Ed., R. Mahy, B. Tate. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5923) 5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates. S. Lawrence, V. Gurbani. June 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5924) 5925 The TCP Authentication Option. J. Touch, A. Mankin, R. Bonica. June 2010. (Format: TXT, HTML) (Obsoletes RFC2385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5925) 5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO). G. Lebovitz, E. Rescorla. June 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5926) 5927 ICMP Attacks against TCP. F. Gont. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5927) 5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism. M. Petit-Huguenin. August 2010. (Format: TXT, HTML) (Updated by RFC7350, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5928) 5929 Channel Bindings for TLS. J. Altman, N. Williams, L. Zhu. July 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5929) 5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol. S. Shen, Y. Mao, NSS. Murthy. July 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5930) 5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password. D. Harkins, G. Zorn. August 2010. (Format: TXT, HTML) (Updated by RFC8146) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5931) 5932 Camellia Cipher Suites for TLS. A. Kato, M. Kanda, S. Kanno. June 2010. (Format: TXT, HTML) (Obsoletes RFC4132) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5932) 5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC. V. Dolmatov, Ed., A. Chuprina, I. Ustinov. July 2010. (Format: TXT, HTML) (Updated by RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5933) 5934 Trust Anchor Management Protocol (TAMP). R. Housley, S. Ashmore, C. Wallace. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5934) 5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language. M. Ellison, B. Natale. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5935) 5936 DNS Zone Transfer Protocol (AXFR). E. Lewis, A. Hoenes, Ed.. June 2010. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5936) 5937 Using Trust Anchor Constraints during Certification Path Processing. S. Ashmore, C. Wallace. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5937) 5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP). A. Morton, M. Chiba. August 2010. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5938) 5939 Session Description Protocol (SDP) Capability Negotiation. F. Andreasen. September 2010. (Format: TXT, HTML) (Updated by RFC6871) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5939) 5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices. S. Turner, R. Housley. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5940) 5941 Sharing Transaction Fraud Data. D. M'Raihi, S. Boeyen, M. Grandcolas, S. Bajaj. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5941) 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes. H. Singh, W. Beebee, E. Nordmark. July 2010. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5942) 5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing. B. Haberman, Ed.. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5943) 5944 IP Mobility Support for IPv4, Revised. C. Perkins, Ed.. November 2010. (Format: TXT, HTML) (Obsoletes RFC3344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5944) 5945 Resource Reservation Protocol (RSVP) Proxy Approaches. F. Le Faucheur, J. Manner, D. Wing, A. Guillou. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5945) 5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy. F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, H. Malik. October 2010. (Format: TXT, HTML) (Updates RFC2205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5946) 5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP). J. Elwell, H. Kaplan. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5947) 5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16. S. Madanapalli, S. Park, S. Chakrabarti, G. Montenegro. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5948) 5949 Fast Handovers for Proxy Mobile IPv6. H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5949) 5950 Network Management Framework for MPLS-based Transport Networks. S. Mansfield, Ed., E. Gray, Ed., K. Lam, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5950) 5951 Network Management Requirements for MPLS-based Transport Networks. K. Lam, S. Mansfield, E. Gray. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5951) 5952 A Recommendation for IPv6 Address Text Representation. S. Kawamura, M. Kawashima. August 2010. (Format: TXT, HTML) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5952) 5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP). W. Hardaker. August 2010. (Format: TXT, HTML) (Obsoleted by RFC6353) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5953) 5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261. V. Gurbani, Ed., B. Carpenter, Ed., B. Tate, Ed.. August 2010. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5954) 5955 The application/timestamped-data Media Type. A. Santoni. August 2010. (Format: TXT, HTML) (Updates RFC5544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5955) 5956 Forward Error Correction Grouping Semantics in the Session Description Protocol. A. Begen. September 2010. (Format: TXT, HTML) (Obsoletes RFC4756) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5956) 5957 Display-Based Address Sorting for the IMAP4 SORT Extension. D. Karp. July 2010. (Format: TXT, HTML) (Updates RFC5256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5957) 5958 Asymmetric Key Packages. S. Turner. August 2010. (Format: TXT, HTML) (Obsoletes RFC5208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5958) 5959 Algorithms for Asymmetric Key Package Content Type. S. Turner. August 2010. (Format: TXT, HTML) (Updated by RFC6162) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5959) 5960 MPLS Transport Profile Data Plane Architecture. D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.. August 2010. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5960) 5961 Improving TCP's Robustness to Blind In-Window Attacks. A. Ramaiah, R. Stewart, M. Dalal. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5961) 5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO). H. Schulzrinne, V. Singh, H. Tschofenig, M. Thomson. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5962) 5963 IPv6 Deployment in Internet Exchange Points (IXPs). R. Gagliano. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5963) 5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries. J. Winterbottom, M. Thomson. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5964) 5965 An Extensible Format for Email Feedback Reports. Y. Shafranovich, J. Levine, M. Kucherawy. August 2010. (Format: TXT, HTML) (Updated by RFC6650) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5965) 5966 DNS Transport over TCP - Implementation Requirements. R. Bellis. August 2010. (Format: TXT, HTML) (Obsoleted by RFC7766) (Updates RFC1035, RFC1123) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5966) 5967 The application/pkcs10 Media Type. S. Turner. August 2010. (Format: TXT, HTML) (Updates RFC2986) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5967) 5968 Guidelines for Extending the RTP Control Protocol (RTCP). J. Ott, C. Perkins. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5968) 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification. W. Townsley, O. Troan. August 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5969) 5970 DHCPv6 Options for Network Boot. T. Huth, J. Freimann, V. Zimmer, D. Thaler. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5970) 5971 GIST: General Internet Signalling Transport. H. Schulzrinne, R. Hancock. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5971) 5972 General Internet Signaling Transport (GIST) State Machine. T. Tsenov, H. Tschofenig, X. Fu, Ed., C. Aoun, E. Davies. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5972) 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP). M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5973) 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling. J. Manner, G. Karagiannis, A. McDonald. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5974) 5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP). G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed.. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5975) 5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes. G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5976) 5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv. A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5977) 5978 Using and Extending the NSIS Protocol Family. J. Manner, R. Bless, J. Loughney, E. Davies, Ed.. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5978) 5979 NSIS Operation over IP Tunnels. C. Shen, H. Schulzrinne, S. Lee, J. Bang. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5979) 5980 NSIS Protocol Operation in Mobile Environments. T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5980) 5981 Authorization for NSIS Signaling Layer Protocols. J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed.. February 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5981) 5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement. A. Kobayashi, Ed., B. Claise, Ed.. August 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5982) 5983 Mailing Lists and Internationalized Email Addresses. R. Gellens. October 2010. (Format: TXT, HTML) (Obsoleted by RFC6783) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5983) 5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding. K-M. Moller. 1 April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC5984) 5985 HTTP-Enabled Location Delivery (HELD). M. Barnes, Ed.. September 2010. (Format: TXT, HTML) (Updated by RFC7840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5985) 5986 Discovering the Local Location Information Server (LIS). M. Thomson, J. Winterbottom. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5986) 5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters. J. Reschke. August 2010. (Format: TXT, HTML) (Obsoleted by RFC8187) (Status: HISTORIC) (DOI: 10.17487/RFC5987) 5988 Web Linking. M. Nottingham. October 2010. (Format: TXT, HTML) (Obsoleted by RFC8288) (Updates RFC4287) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5988) 5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource. A.B. Roach. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5989) 5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS). J. Randall, B. Kaliski, J. Brainard, S. Turner. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5990) 5991 Teredo Security Updates. D. Thaler, S. Krishnan, J. Hoagland. September 2010. (Format: TXT, HTML) (Updates RFC4380) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5991) 5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic. S. Sharikov, D. Miloshevic, J. Klensin. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5992) 5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR). X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5993) 5994 Application of Ethernet Pseudowires to MPLS Transport Networks. S. Bryant, Ed., M. Morrow, G. Swallow, R. Cherukuri, T. Nadeau, N. Harrison, B. Niven-Jenkins. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5994) 5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections. J. Reschke. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5995) 5996 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. September 2010. (Format: TXT, HTML) (Obsoletes RFC4306, RFC4718) (Obsoleted by RFC7296) (Updated by RFC5998, RFC6989) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5996) 5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol. A. DeKok. August 2010. (Format: TXT, HTML) (Updates RFC2866) (Status: INFORMATIONAL) (DOI: 10.17487/RFC5997) 5998 An Extension for EAP-Only Authentication in IKEv2. P. Eronen, H. Tschofenig, Y. Sheffer. September 2010. (Format: TXT, HTML) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC5998) 5999 Not Issued. 6000 Not Issued. 6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN). D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, JL. Le Roux. October 2010. (Format: TXT, HTML) (Updates RFC4202, RFC4203, RFC4206, RFC4874, RFC4974, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6001) 6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions. L. Berger, D. Fedyk. October 2010. (Format: TXT, HTML) (Updates RFC3471, RFC3473, RFC3945, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6002) 6003 Ethernet Traffic Parameters. D. Papadimitriou. October 2010. (Format: TXT, HTML) (Updates RFC3471, RFC3473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6003) 6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching. L. Berger, D. Fedyk. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6004) 6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI). L. Berger, D. Fedyk. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6005) 6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths. Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric. September 2010. (Format: TXT, HTML) (Obsoleted by RFC8306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6006) 6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations. I. Nishioka, D. King. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6007) 6008 Authentication-Results Registration for Differentiating among Cryptographic Results. M. Kucherawy. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6008) 6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions. N. Freed. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6009) 6010 Cryptographic Message Syntax (CMS) Content Constraints Extension. R. Housley, S. Ashmore, C. Wallace. September 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6010) 6011 Session Initiation Protocol (SIP) User Agent Configuration. S. Lawrence, Ed., J. Elwell. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6011) 6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog. J. Salowey, T. Petch, R. Gerhards, H. Feng. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6012) 6013 TCP Cookie Transactions (TCPCT). W. Simpson. January 2011. (Format: TXT, HTML) (Obsoleted by RFC7805) (Status: HISTORIC) (DOI: 10.17487/RFC6013) 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC. P. Hoffman. November 2010. (Format: TXT, HTML) (Updates RFC4033, RFC4034, RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6014) 6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC). A. Begen. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6015) 6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs. B. Davie, F. Le Faucheur, A. Narayanan. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6016) 6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field. K. Meadors, Ed.. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6017) 6018 IPv4 and IPv6 Greynets. F. Baker, W. Harrop, G. Armitage. September 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6018) 6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1. R. Housley. September 2010. (Format: TXT, HTML) (Obsoletes RFC4049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6019) 6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF). M. Bjorklund, Ed.. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6020) 6021 Common YANG Data Types. J. Schoenwaelder, Ed.. October 2010. (Format: TXT, HTML) (Obsoleted by RFC6991) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6021) 6022 YANG Module for NETCONF Monitoring. M. Scott, M. Bjorklund. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6022) 6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA). Y. Nir, H. Tschofenig, H. Deng, R. Singh. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6023) 6024 Trust Anchor Management Requirements. R. Reddy, C. Wallace. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6024) 6025 ASN.1 Translation. C. Wallace, C. Gardiner. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6025) 6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests. R. Sparks, T. Zourzouvillys. September 2010. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6026) 6027 IPsec Cluster Problem Statement. Y. Nir. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6027) 6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension. G. Camarillo, A. Keranen. October 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6028) 6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem. I. Rimac, V. Hilt, M. Tomsu, V. Gurbani, E. Marocco. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6029) 6030 Portable Symmetric Key Container (PSKC). P. Hoyer, M. Pei, S. Machani. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6030) 6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type. S. Turner, R. Housley. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6031) 6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner, R. Housley. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6032) 6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner. December 2010. (Format: TXT, HTML) (Updated by RFC6161) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6033) 6034 Unicast-Prefix-Based IPv4 Multicast Addresses. D. Thaler. October 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6034) 6035 Session Initiation Protocol Event Package for Voice Quality Reporting. A. Pendleton, A. Clark, A. Johnston, H. Sinnreich. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6035) 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S. Jiang. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6036) 6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs. E. Rosen, Ed., Y. Cai, Ed., IJ. Wijnands. October 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6037) 6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features. A. Morton, L. Ciavattone. October 2010. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6038) 6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols. V. Manral, M. Bhatia, J. Jaeggli, R. White. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6039) 6040 Tunnelling of Explicit Congestion Notification. B. Briscoe. November 2010. (Format: TXT, HTML) (Updates RFC3168, RFC4301, RFC4774) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6040) 6041 Forwarding and Control Element Separation (ForCES) Applicability Statement. A. Crouch, H. Khosravi, A. Doria, Ed., X. Wang, K. Ogawa. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6041) 6042 Transport Layer Security (TLS) Authorization Using KeyNote. A. Keromytis. October 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6042) 6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY). J. Mattsson, T. Tian. March 2011. (Format: TXT, HTML) (Updated by RFC6309) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6043) 6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP). M. Mohali. October 2010. (Format: TXT, HTML) (Obsoleted by RFC7544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6044) 6045 Real-time Inter-network Defense (RID). K. Moriarty. November 2010. (Format: TXT, HTML) (Obsoleted by RFC6545) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6045) 6046 Transport of Real-time Inter-network Defense (RID) Messages. K. Moriarty, B. Trammell. November 2010. (Format: TXT, HTML) (Obsoleted by RFC6546) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6046) 6047 iCalendar Message-Based Interoperability Protocol (iMIP). A. Melnikov, Ed.. December 2010. (Format: TXT, HTML) (Obsoletes RFC2447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6047) 6048 Network News Transfer Protocol (NNTP) Additions to LIST Command. J. Elie. November 2010. (Format: TXT, HTML) (Updates RFC2980, RFC3977) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6048) 6049 Spatial Composition of Metrics. A. Morton, E. Stephan. January 2011. (Format: TXT, HTML) (Updated by RFC6248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6049) 6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services. K. Drage. November 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6050) 6051 Rapid Synchronisation of RTP Flows. C. Perkins, T. Schierl. November 2010. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6051) 6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT, HTML) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6052) 6053 Implementation Report for Forwarding and Control Element Separation (ForCES). E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim. November 2010. (Format: TXT, HTML) (Updated by RFC6984) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6053) 6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic. D. McGrew, B. Weis. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6054) 6055 IAB Thoughts on Encodings for Internationalized Domain Names. D. Thaler, J. Klensin, S. Cheshire. February 2011. (Format: TXT, HTML) (Updates RFC2130) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6055) 6056 Recommendations for Transport-Protocol Port Randomization. M. Larsen, F. Gont. January 2011. (Format: TXT, HTML) (Also BCP0156) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6056) 6057 Comcast's Protocol-Agnostic Congestion Management System. C. Bastian, T. Klieber, J. Livingood, J. Mills, R. Woundy. December 2010. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6057) 6058 Transient Binding for Proxy Mobile IPv6. M. Liebsch, Ed., A. Muhanna, O. Blume. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6058) 6059 Simple Procedures for Detecting Network Attachment in IPv6. S. Krishnan, G. Daley. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6059) 6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE). D. Fedyk, H. Shah, N. Bitar, A. Takacs. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6060) 6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA). B. Rosen. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6061) 6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations. S. Perreault, Ed., J. Rosenberg. November 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6062) 6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP). A. Doherty, M. Pei, S. Machani, M. Nystrom. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6063) 6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service. M. Westerlund, P. Frojdh. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6064) 6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings. K. Narayan, D. Nelson, R. Presuhn, Ed.. December 2010. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6065) 6066 Transport Layer Security (TLS) Extensions: Extension Definitions. D. Eastlake 3rd. January 2011. (Format: TXT, HTML) (Obsoletes RFC4366) (Updated by RFC8446, RFC8449) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6066) 6067 BCP 47 Extension U. M. Davis, A. Phillips, Y. Umaoka. December 2010. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6067) 6068 The 'mailto' URI Scheme. M. Duerst, L. Masinter, J. Zawinski. October 2010. (Format: TXT, HTML) (Obsoletes RFC2368) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6068) 6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD). A. Zimmermann, A. Hannemann. December 2010. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6069) 6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors. S. Josefsson. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6070) 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. S. Frankel, S. Krishnan. February 2011. (Format: TXT, HTML) (Obsoletes RFC2411) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6071) 6072 Certificate Management Service for the Session Initiation Protocol (SIP). C. Jennings, J. Fischl, Ed.. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6072) 6073 Segmented Pseudowire. L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. January 2011. (Format: TXT, HTML) (Updated by RFC6723, RFC7267) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6073) 6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs). E. Rosen, B. Davie, V. Radoaca, W. Luo. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6074) 6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry. D. Cridland. December 2010. (Format: TXT, HTML) (Updates RFC2244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6075) 6076 Basic Telephony SIP End-to-End Performance Metrics. D. Malas, A. Morton. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6076) 6077 Open Research Issues in Internet Congestion Control. D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6077) 6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS). G. Camarillo, J. Melen. January 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6078) 6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE). G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston. January 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6079) 6080 A Framework for Session Initiation Protocol User Agent Profile Delivery. D. Petrie, S. Channabasappa, Ed.. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6080) 6081 Teredo Extensions. D. Thaler. January 2011. (Format: TXT, HTML) (Updates RFC4380) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6081) 6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic. K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin. November 2010. (Format: TXT, HTML) (Obsoletes RFC2482) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6082) 6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP). M. Tuexen, R. Seggelmann, E. Rescorla. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6083) 6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). X. Fu, C. Dickmann, J. Crowcroft. January 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6084) 6085 Address Mapping of IPv6 Multicast Packets on Ethernet. S. Gundavelli, M. Townsley, O. Troan, W. Dec. January 2011. (Format: TXT, HTML) (Updates RFC2464) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6085) 6086 Session Initiation Protocol (SIP) INFO Method and Package Framework. C. Holmberg, E. Burger, H. Kaplan. January 2011. (Format: TXT, HTML) (Obsoletes RFC2976) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6086) 6087 Guidelines for Authors and Reviewers of YANG Data Model Documents. A. Bierman. January 2011. (Format: TXT, HTML) (Obsoleted by RFC8407) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6087) 6088 Traffic Selectors for Flow Bindings. G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont. January 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6088) 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support. G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. January 2011. (Format: TXT, HTML) (Updates RFC5648) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6089) 6090 Fundamental Elliptic Curve Cryptography Algorithms. D. McGrew, K. Igoe, M. Salter. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6090) 6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication. N. Mavrogiannopoulos, D. Gillmor. February 2011. (Format: TXT, HTML) (Obsoletes RFC5081) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6091) 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service. J. Woodyatt, Ed.. January 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6092) 6093 On the Implementation of the TCP Urgent Mechanism. F. Gont, A. Yourtchenko. January 2011. (Format: TXT, HTML) (Updates RFC0793, RFC1011, RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6093) 6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols. M. Bhatia, V. Manral. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6094) 6095 Extending YANG with Language Abstractions. B. Linowski, M. Ersue, S. Kuryla. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6095) 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration. M. Tuexen, R. Stewart. January 2011. (Format: TXT, HTML) (Updates RFC4960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6096) 6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6. J. Korhonen, V. Devarapalli. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6097) 6098 Generic Notification Message for Mobile IPv4. H. Deng, H. Levkowetz, V. Devarapalli, S. Gundavelli, B. Haley. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6098) 6099 Not Issued. 6100 Not Issued. 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0. A. Freier, P. Karlton, P. Kocher. August 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6101) 6102 Not Issued. 6103 Not Issued. 6104 Rogue IPv6 Router Advertisement Problem Statement. T. Chown, S. Venaas. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6104) 6105 IPv6 Router Advertisement Guard. E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi. February 2011. (Format: TXT, HTML) (Updated by RFC7113) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6105) 6106 IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. November 2010. (Format: TXT, HTML) (Obsoletes RFC5006) (Obsoleted by RFC8106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6106) 6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths. K. Shiomoto, Ed., A. Farrel, Ed.. February 2011. (Format: TXT, HTML) (Updates RFC3477, RFC4206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6107) 6108 Comcast's Web Notification System Design. C. Chung, A. Kasyanov, J. Livingood, N. Mody, B. Van Lieu. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6108) 6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail. C. Petrucci, F. Gennai, A. Shahin, A. Vinciarelli. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6109) 6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content. L. Lhotka, Ed.. February 2011. (Format: TXT, HTML) (Updated by RFC7952) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6110) 6111 Additional Kerberos Naming Constraints. L. Zhu. April 2011. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6111) 6112 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8062) (Updates RFC4120, RFC4121, RFC4556) (Status: HISTORIC) (DOI: 10.17487/RFC6112) 6113 A Generalized Framework for Kerberos Pre-Authentication. S. Hartman, L. Zhu. April 2011. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6113) 6114 The 128-Bit Blockcipher CLEFIA. M. Katagi, S. Moriai. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6114) 6115 Recommendation for a Routing Architecture. T. Li, Ed.. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6115) 6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM). S. Bradner, L. Conroy, K. Fujiwara. March 2011. (Format: TXT, HTML) (Obsoletes RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6116) 6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations. B. Hoeneisen, A. Mayrhofer, J. Livingood. March 2011. (Format: TXT, HTML) (Obsoletes RFC3761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6117) 6118 Update of Legacy IANA Registrations of Enumservices. B. Hoeneisen, A. Mayrhofer. March 2011. (Format: TXT, HTML) (Updates RFC3762, RFC3764, RFC3953, RFC4143, RFC4002, RFC4238, RFC4355, RFC4415, RFC4769, RFC4969, RFC4979, RFC5028, RFC5278, RFC5333) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6118) 6119 IPv6 Traffic Engineering in IS-IS. J. Harrison, J. Berger, M. Bartlett. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6119) 6120 Extensible Messaging and Presence Protocol (XMPP): Core. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoletes RFC3920) (Updated by RFC7590, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6120) 6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoletes RFC3921) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6121) 6122 Extensible Messaging and Presence Protocol (XMPP): Address Format. P. Saint-Andre. March 2011. (Format: TXT, HTML) (Obsoleted by RFC7622) (Updates RFC3920) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6122) 6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts. A. Farrel. February 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6123) 6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol. Y. Sheffer, G. Zorn, H. Tschofenig, S. Fluhrer. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6124) 6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). P. Saint-Andre, J. Hodges. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6125) 6126 The Babel Routing Protocol. J. Chroboczek. April 2011. (Format: TXT, HTML) (Updated by RFC7298, RFC7557) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6126) 6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios. J. Arkko, M. Townsley. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6127) 6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions. A. Begen. February 2011. (Format: TXT, HTML) (Updates RFC5760) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6128) 6129 The 'application/tei+xml' Media Type. L. Romary, S. Lundberg. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6129) 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP). T. Clausen, C. Dearlove, J. Dean. April 2011. (Format: TXT, HTML) (Updated by RFC7183, RFC7188, RFC7466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6130) 6131 Sieve Vacation Extension: "Seconds" Parameter. R. George, B. Leiba. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6131) 6132 Sieve Notification Using Presence Information. R. George, B. Leiba. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6132) 6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality. R. George, B. Leiba, A. Melnikov. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6133) 6134 Sieve Extension: Externally Stored Lists. A. Melnikov, B. Leiba. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6134) 6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP). C. Holmberg, S. Blau. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6135) 6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework. A. Sajassi, Ed., D. Mohan, Ed.. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6136) 6137 The Network Trouble Ticket Data Model (NTTDM). D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed.. February 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6137) 6138 LDP IGP Synchronization for Broadcast Networks. S. Kini, Ed., W. Lu, Ed.. February 2011. (Format: TXT, HTML) (Updates RFC5443) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6138) 6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios. S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed.. February 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6139) 6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP). A.B. Roach. March 2011. (Format: TXT, HTML) (Updates RFC3680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6140) 6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP). G. Camarillo, Ed., C. Holmberg, Y. Gao. March 2011. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6141) 6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP. A. Moise, J. Brodkin. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6142) 6143 The Remote Framebuffer Protocol. T. Richardson, J. Levine. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6143) 6144 Framework for IPv4/IPv6 Translation. F. Baker, X. Li, C. Bao, K. Yin. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6144) 6145 IP/ICMP Translation Algorithm. X. Li, C. Bao, F. Baker. April 2011. (Format: TXT, HTML) (Obsoletes RFC2765) (Obsoleted by RFC7915) (Updated by RFC6791, RFC7757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6145) 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6146) 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6147) 6148 DHCPv4 Lease Query by Relay Agent Remote ID. P. Kurapati, R. Desetti, B. Joshi. February 2011. (Format: TXT, HTML) (Updates RFC4388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6148) 6149 MD2 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Obsoletes RFC1319) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6149) 6150 MD4 to Historic Status. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Obsoletes RFC1320) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6150) 6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms. S. Turner, L. Chen. March 2011. (Format: TXT, HTML) (Updates RFC1321, RFC2104) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6151) 6152 SMTP Service Extension for 8-bit MIME Transport. J. Klensin, N. Freed, M. Rose, D. Crocker, Ed.. March 2011. (Format: TXT, HTML) (Obsoletes RFC1652) (Also STD0071) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6152) 6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery. S. Das, G. Bajko. February 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6153) 6154 IMAP LIST Extension for Special-Use Mailboxes. B. Leiba, J. Nicolson. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6154) 6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD). J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. March 2011. (Format: TXT, HTML) (Updated by RFC6915) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6155) 6156 Traversal Using Relays around NAT (TURN) Extension for IPv6. G. Camarillo, O. Novo, S. Perreault, Ed.. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8656) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6156) 6157 IPv6 Transition in the Session Initiation Protocol (SIP). G. Camarillo, K. El Malki, V. Gurbani. April 2011. (Format: TXT, HTML) (Updates RFC3264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6157) 6158 RADIUS Design Guidelines. A. DeKok, Ed., G. Weber. March 2011. (Format: TXT, HTML) (Updated by RFC6929, RFC8044) (Also BCP0158) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6158) 6159 Session-Specific Explicit Diameter Request Routing. T. Tsou, G. Zorn, T. Taylor, Ed.. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6159) 6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types. S. Turner. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6160) 6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type. S. Turner. April 2011. (Format: TXT, HTML) (Updates RFC6033) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6161) 6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type. S. Turner. April 2011. (Format: TXT, HTML) (Updates RFC5959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6162) 6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs). Y. Lee, Ed., G. Bernstein, Ed., W. Imajuku. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6163) 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links. M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. April 2011. (Format: TXT, HTML) (Updated by RFC6547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6164) 6165 Extensions to IS-IS for Layer-2 Systems. A. Banerjee, D. Ward. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6165) 6166 A Registry for PIM Message Types. S. Venaas. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6166) 6167 URI Scheme for Java(tm) Message Service 1.0. M. Phillips, P. Adams, D. Rokicki, E. Johnson. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6167) 6168 Requirements for Management of Name Servers for the DNS. W. Hardaker. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6168) 6169 Security Concerns with IP Tunneling. S. Krishnan, D. Thaler, J. Hoagland. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6169) 6170 Internet X.509 Public Key Infrastructure -- Certificate Image. S. Santesson, R. Housley, S. Bajaj, L. Rosenthol. May 2011. (Format: TXT, HTML) (Updates RFC3709) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6170) 6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control. K. Zeilenga. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6171) 6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode. D. Black, D. Peterson. March 2011. (Format: TXT, HTML) (Updates RFC4172) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6172) 6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP). P. Venkatesen, Ed.. March 2011. (Format: TXT, HTML) (Obsoletes RFC4369) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6173) 6174 Definition of IETF Working Group Document States. E. Juskevicius. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6174) 6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors. E. Juskevicius. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6175) 6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0. S. Turner, T. Polk. March 2011. (Format: TXT, HTML) (Updates RFC2246, RFC4346, RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6176) 6177 IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Format: TXT, HTML) (Obsoletes RFC3177) (Also BCP0157) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6177) 6178 Label Edge Router Forwarding of IPv4 Option Packets. D. Smith, J. Mullooly, W. Jaeger, T. Scholl. March 2011. (Format: TXT, HTML) (Updates RFC3031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6178) 6179 The Internet Routing Overlay Network (IRON). F. Templin, Ed.. March 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6179) 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180) 6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses. M. Bagnulo. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6181) 6182 Architectural Guidelines for Multipath TCP Development. A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6182) 6183 IP Flow Information Export (IPFIX) Mediation: Framework. A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi. April 2011. (Format: TXT, HTML) (Updates RFC5470) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6183) 6184 RTP Payload Format for H.264 Video. Y.-K. Wang, R. Even, T. Kristensen, R. Jesup. May 2011. (Format: TXT, HTML) (Obsoletes RFC3984) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6184) 6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video. T. Kristensen, P. Luthi. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6185) 6186 Use of SRV Records for Locating Email Submission/Access Services. C. Daboo. March 2011. (Format: TXT, HTML) (Updates RFC1939, RFC3501) (Updated by RFC8314, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6186) 6187 X.509v3 Certificates for Secure Shell Authentication. K. Igoe, D. Stebila. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6187) 6188 The Use of AES-192 and AES-256 in Secure RTP. D. McGrew. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6188) 6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP. P. Zimmermann, A. Johnston, Ed., J. Callas. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6189) 6190 RTP Payload Format for Scalable Video Coding. S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6190) 6191 Reducing the TIME-WAIT State Using TCP Timestamps. F. Gont. April 2011. (Format: TXT, HTML) (Also BCP0159) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6191) 6192 Protecting the Router Control Plane. D. Dugal, C. Pignataro, R. Dunn. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6192) 6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP). M. Saito, D. Wing, M. Toyama. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6193) 6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms. T. Polk, L. Chen, S. Turner, P. Hoffman. March 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6194) 6195 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. March 2011. (Format: TXT, HTML) (Obsoletes RFC5395) (Obsoleted by RFC6895) (Updates RFC1183, RFC3597) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6195) 6196 Moving mailserver: URI Scheme to Historic. A. Melnikov. March 2011. (Format: TXT, HTML) (Updates RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6196) 6197 Location-to-Service Translation (LoST) Service List Boundary Extension. K. Wolf. April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6197) 6198 Requirements for the Graceful Shutdown of BGP Sessions. B. Decraene, P. Francois, C. Pelsser, Z. Ahmad, A.J. Elizondo Armengol, T. Takeda. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6198) 6199 Not Issued. 6200 Not Issued. 6201 Device Reset Characterization. R. Asati, C. Pignataro, F. Calabria, C. Olvera. March 2011. (Format: TXT, HTML) (Updates RFC1242, RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6201) 6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. S. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6202) 6203 IMAP4 Extension for Fuzzy Search. T. Sirainen. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6203) 6204 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. April 2011. (Format: TXT, HTML) (Obsoleted by RFC7084) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6204) 6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers. T. Otani, Ed., D. Li, Ed.. March 2011. (Format: TXT, HTML) (Updates RFC3471) (Updated by RFC7699, RFC8359) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6205) 6206 The Trickle Algorithm. P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko. March 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6206) 6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml. R. Denenberg, Ed.. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6207) 6208 Cloud Data Management Interface (CDMI) Media Types. K. Sankar, Ed., A. Jones. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6208) 6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS). W. Kim, J. Lee, J. Park, D. Kwon. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6209) 6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME. J. Schaad. April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6210) 6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute. J. Schaad. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6211) 6212 Authentication-Results Registration for Vouch by Reference Results. M. Kucherawy. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6212) 6213 IS-IS BFD-Enabled TLV. C. Hopps, L. Ginsberg. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6213) 6214 Adaptation of RFC 1149 for IPv6. B. Carpenter, R. Hinden. 1 April 2011. (Format: TXT, HTML) (Updates RFC1149) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6214) 6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces. M. Bocci, L. Levrau, D. Frost. April 2011. (Format: TXT, HTML) (Updates RFC5921) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6215) 6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms. C. Jennings, K. Ono, R. Sparks, B. Hibbard, Ed.. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6216) 6217 Regional Broadcast Using an Atmospheric Link Layer. T. Ritter. 1 April 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6217) 6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material. G. Zorn, T. Zhang, J. Walker, J. Salowey. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6218) 6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition. X. Li, C. Bao, M. Chen, H. Zhang, J. Wu. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6219) 6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators. D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board. April 2011. (Format: TXT, HTML) (Obsoleted by RFC8722) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6220) 6221 Lightweight DHCPv6 Relay Agent. D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh. May 2011. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6221) 6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). A. Begen, C. Perkins, D. Wing. April 2011. (Format: TXT, HTML) (Obsoleted by RFC7022) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6222) 6223 Indication of Support for Keep-Alive. C. Holmberg. April 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6223) 6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, M. Waehlisch, S. Krishnan. April 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6224) 6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information. J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed.. July 2011. (Format: TXT, HTML) (Obsoletes RFC3825) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6225) 6226 PIM Group-to-Rendezvous-Point Mapping. B. Joshi, A. Kessler, D. McWalter. May 2011. (Format: TXT, HTML) (Updates RFC4601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6226) 6227 Design Goals for Scalable Internet Routing. T. Li, Ed.. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6227) 6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. C. Holmberg. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6228) 6229 Test Vectors for the Stream Cipher RC4. J. Strombergson, S. Josefsson. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6229) 6230 Media Control Channel Framework. C. Boulton, T. Melanchuk, S. McGlashan. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6230) 6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework. S. McGlashan, T. Melanchuk, C. Boulton. May 2011. (Format: TXT, HTML) (Updated by RFC6623) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6231) 6232 Purge Originator Identification TLV for IS-IS. F. Wei, Y. Qin, Z. Li, T. Li, J. Dong. May 2011. (Format: TXT, HTML) (Updates RFC5301, RFC5304, RFC5310) (Updated by RFC8918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6232) 6233 IS-IS Registry Extension for Purges. T. Li, L. Ginsberg. May 2011. (Format: TXT, HTML) (Updates RFC3563, RFC5304, RFC5310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6233) 6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF). D. Eastlake 3rd, T. Hansen. May 2011. (Format: TXT, HTML) (Obsoletes RFC4634) (Updates RFC3174) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6234) 6235 IP Flow Anonymization Support. E. Boschi, B. Trammell. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6235) 6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP). I. Johansson, K. Jung. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6236) 6237 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. May 2011. (Format: TXT, HTML) (Obsoleted by RFC7377) (Updates RFC4466) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6237) 6238 TOTP: Time-Based One-Time Password Algorithm. D. M'Raihi, S. Machani, M. Pei, J. Rydell. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6238) 6239 Suite B Cryptographic Suites for Secure Shell (SSH). K. Igoe. May 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6239) 6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2. D. Zelig, Ed., R. Cohen, Ed., T. Nadeau, Ed.. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6240) 6241 Network Configuration Protocol (NETCONF). R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.. June 2011. (Format: TXT, HTML) (Obsoletes RFC4741) (Updated by RFC7803, RFC8526) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6241) 6242 Using the NETCONF Protocol over Secure Shell (SSH). M. Wasserman. June 2011. (Format: TXT, HTML) (Obsoletes RFC4742) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6242) 6243 With-defaults Capability for NETCONF. A. Bierman, B. Lengyel. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6243) 6244 An Architecture for Network Management Using NETCONF and YANG. P. Shafer. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6244) 6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4. P. Yegani, K. Leung, A. Lior, K. Chowdhury, J. Navali. May 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6245) 6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges. A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6246) 6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status. L. Eggert. May 2011. (Format: TXT, HTML) (Obsoletes RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644, RFC1693) (Updates RFC4614) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6247) 6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete. A. Morton. April 2011. (Format: TXT, HTML) (Obsoletes RFC4148) (Updates RFC4737, RFC5560, RFC5644, RFC6049) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6248) 6249 Metalink/HTTP: Mirrors and Hashes. A. Bryan, N. McNab, T. Tsujikawa, P. Poeml, H. Nordstrom. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6249) 6250 Evolution of the IP Model. D. Thaler. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6250) 6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol. S. Josefsson. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6251) 6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization. A. Dutta, Ed., V. Fajardo, Y. Ohba, K. Taniuchi, H. Schulzrinne. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6252) 6253 Host Identity Protocol Certificates. T. Heer, S. Varjonen. May 2011. (Format: TXT, HTML) (Obsoleted by RFC8002) (Updates RFC5201) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6253) 6254 Request to Move RFC 2754 to Historic Status. M. McFadden. May 2011. (Format: TXT, HTML) (Obsoletes RFC2754) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6254) 6255 Delay-Tolerant Networking Bundle Protocol IANA Registries. M. Blanchet. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6255) 6256 Using Self-Delimiting Numeric Values in Protocols. W. Eddy, E. Davies. May 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6256) 6257 Bundle Security Protocol Specification. S. Symington, S. Farrell, H. Weiss, P. Lovell. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6257) 6258 Delay-Tolerant Networking Metadata Extension Block. S. Symington. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6258) 6259 Delay-Tolerant Networking Previous-Hop Insertion Block. S. Symington. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6259) 6260 Compressed Bundle Header Encoding (CBHE). S. Burleigh. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6260) 6261 Encrypted Signaling Transport Modes for the Host Identity Protocol. A. Keranen. May 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6261) 6262 RTP Payload Format for IP-MR Speech Codec. S. Ikonin. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6262) 6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows. X. Marjou, A. Sollaud. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6263) 6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition. S. Jiang, D. Guo, B. Carpenter. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6264) 6265 HTTP State Management Mechanism. A. Barth. April 2011. (Format: TXT, HTML) (Obsoletes RFC2965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6265) 6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP). J. Reschke. June 2011. (Format: TXT, HTML) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6266) 6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY). V. Cakulev, G. Sundaram. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6267) 6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX). J. Schaad, S. Turner. July 2011. (Format: TXT, HTML) (Updates RFC5911) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6268) 6269 Issues with IP Address Sharing. M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6269) 6270 The 'tn3270' URI Scheme. M. Yevstifeyev. June 2011. (Format: TXT, HTML) (Updates RFC2355, RFC1738, RFC1041) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6270) 6271 Requirements for SIP-Based Session Peering. J-F. Mule. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6271) 6272 Internet Protocols for the Smart Grid. F. Baker, D. Meyer. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6272) 6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis. A. Kukec, S. Krishnan, S. Jiang. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6273) 6274 Security Assessment of the Internet Protocol Version 4. F. Gont. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6274) 6275 Mobility Support in IPv6. C. Perkins, Ed., D. Johnson, J. Arkko. July 2011. (Format: TXT, HTML) (Obsoletes RFC3775) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6275) 6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO). R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6276) 6277 Online Certificate Status Protocol Algorithm Agility. S. Santesson, P. Hallam-Baker. June 2011. (Format: TXT, HTML) (Obsoleted by RFC6960) (Updates RFC2560) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6277) 6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax. J. Herzog, R. Khazan. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6278) 6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement. M. Liebsch, Ed., S. Jeong, Q. Wu. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6279) 6280 An Architecture for Location and Location Privacy in Internet Applications. R. Barnes, M. Lepinski, A. Cooper, J. Morris, H. Tschofenig, H. Schulzrinne. July 2011. (Format: TXT, HTML) (Updates RFC3693, RFC3694) (Also BCP0160) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6280) 6281 Understanding Apple's Back to My Mac (BTMM) Service. S. Cheshire, Z. Zhu, R. Wakikawa, L. Zhang. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6281) 6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks. J. Hui, Ed., P. Thubert. September 2011. (Format: TXT, HTML) (Updates RFC4944) (Updated by RFC8066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6282) 6283 Extensible Markup Language Evidence Record Syntax (XMLERS). A. Jerman Blazic, S. Saljic, T. Gondrom. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6283) 6284 Port Mapping between Unicast and Multicast RTP Sessions. A. Begen, D. Wing, T. Van Caenegem. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6284) 6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions. B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6285) 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4. E. Chen, J. Yuan. June 2011. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6286) 6287 OCRA: OATH Challenge-Response Algorithm. D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6287) 6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG). C. Reed. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6288) 6289 A Uniform Resource Name (URN) Namespace for CableLabs. E. Cardona, S. Channabasappa, J-F. Mule. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6289) 6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE). Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi. June 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6290) 6291 Guidelines for the Use of the "OAM" Acronym in the IETF. L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield. June 2011. (Format: TXT, HTML) (Also BCP0161) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6291) 6292 Requirements for a Working Group Charter Tool. P. Hoffman. June 2011. (Format: TXT, HTML) (Updated by RFC6433) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6292) 6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker. P. Hoffman. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6293) 6294 Survey of Proposed Use Cases for the IPv6 Flow Label. Q. Hu, B. Carpenter. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6294) 6295 RTP Payload Format for MIDI. J. Lazzaro, J. Wawrzynek. June 2011. (Format: TXT, HTML) (Obsoletes RFC4695) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6295) 6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker. June 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6296) 6297 A Survey of Lower-than-Best-Effort Transport Protocols. M. Welzl, D. Ros. June 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6297) 6298 Computing TCP's Retransmission Timer. V. Paxson, M. Allman, J. Chu, M. Sargent. June 2011. (Format: TXT, HTML) (Obsoletes RFC2988) (Updates RFC1122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6298) 6299 Not Issued. 6300 Not Issued. 6301 A Survey of Mobility Support in the Internet. Z. Zhu, R. Wakikawa, L. Zhang. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6301) 6302 Logging Recommendations for Internet-Facing Servers. A. Durand, I. Gashinsky, D. Lee, S. Sheppard. June 2011. (Format: TXT, HTML) (Also BCP0162) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6302) 6303 Locally Served DNS Zones. M. Andrews. July 2011. (Format: TXT, HTML) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6303) 6304 AS112 Nameserver Operations. J. Abley, W. Maton. July 2011. (Format: TXT, HTML) (Obsoleted by RFC7534) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6304) 6305 I'm Being Attacked by PRISONER.IANA.ORG!. J. Abley, W. Maton. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6305) 6306 Hierarchical IPv4 Framework. P. Frejborg. July 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6306) 6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks. D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6307) 6308 Overview of the Internet Multicast Addressing Architecture. P. Savola. June 2011. (Format: TXT, HTML) (Obsoletes RFC2908) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6308) 6309 IANA Rules for MIKEY (Multimedia Internet KEYing). J. Arkko, A. Keranen, J. Mattsson. August 2011. (Format: TXT, HTML) (Obsoletes RFC4909) (Updates RFC3830, RFC4563, RFC5410, RFC6043) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6309) 6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping. M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6310) 6311 Protocol Support for High Availability of IKEv2/IPsec. R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6311) 6312 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. July 2011. (Format: TXT, HTML) (Obsoleted by RFC6342) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6312) 6313 Export of Structured Data in IP Flow Information Export (IPFIX). B. Claise, G. Dhandapani, P. Aitken, S. Yates. July 2011. (Format: TXT, HTML) (Updates RFC5102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6313) 6314 NAT Traversal Practices for Client-Server SIP. C. Boulton, J. Rosenberg, G. Camarillo, F. Audet. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6314) 6315 IANA Registration for Enumservice 'iax'. E. Guy, K. Darilion. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6315) 6316 Sockets Application Program Interface (API) for Multihoming Shim. M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Ed.. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6316) 6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP). M. Komu, T. Henderson. July 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6317) 6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME). R. Housley, J. Solinas. June 2011. (Format: TXT, HTML) (Obsoletes RFC5008) (Status: HISTORIC) (DOI: 10.17487/RFC6318) 6319 Issues Associated with Designating Additional Private IPv4 Address Space. M. Azinger, L. Vegoda. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6319) 6320 Protocol for Access Node Control Mechanism in Broadband Networks. S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed.. October 2011. (Format: TXT, HTML) (Updated by RFC7256) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6320) 6321 xCal: The XML Format for iCalendar. C. Daboo, M. Douglass, S. Lees. August 2011. (Format: TXT, HTML) (Updated by RFC6868, RFC7529) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6321) 6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams. P. Hoffman. July 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6322) 6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP). G. Renker, G. Fairhurst. July 2011. (Format: TXT, HTML) (Updates RFC4342, RFC5622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6323) 6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations. G. Nakibly, F. Templin. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6324) 6325 Routing Bridges (RBridges): Base Protocol Specification. R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani. July 2011. (Format: TXT, HTML) (Updated by RFC6327, RFC6439, RFC7172, RFC7177, RFC7357, RFC7179, RFC7180, RFC7455, RFC7780, RFC7783, RFC8139, RFC8249, RFC8361, RFC8377) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6325) 6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS. D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani. July 2011. (Format: TXT, HTML) (Obsoleted by RFC7176) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6326) 6327 Routing Bridges (RBridges): Adjacency. D. Eastlake 3rd, R. Perlman, A. Ghanwani, D. Dutt, V. Manral. July 2011. (Format: TXT, HTML) (Obsoleted by RFC7177) (Updates RFC6325) (Updated by RFC7180) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6327) 6328 IANA Considerations for Network Layer Protocol Identifiers. D. Eastlake 3rd. July 2011. (Format: TXT, HTML) (Also BCP0164) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6328) 6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging. D. Fedyk, Ed., P. Ashwood-Smith, Ed., D. Allan, A. Bragg, P. Unbehagen. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6329) 6330 RaptorQ Forward Error Correction Scheme for Object Delivery. M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6330) 6331 Moving DIGEST-MD5 to Historic. A. Melnikov. July 2011. (Format: TXT, HTML) (Obsoletes RFC2831) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6331) 6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs). A. Begen, E. Friedrich. July 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6332) 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion. A. Durand, R. Droms, J. Woodyatt, Y. Lee. August 2011. (Format: TXT, HTML) (Updated by RFC7335) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6333) 6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite. D. Hankins, T. Mrugalski. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6334) 6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire. August 2011. (Format: TXT, HTML) (Updates RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595) (Also BCP0165) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6335) 6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options. M. Westerlund, C. Perkins. July 2011. (Format: TXT, HTML) (Updates RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6336) 6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model. S. Okumura, T. Sawada, P. Kyzivat. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6337) 6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC). V. Giralt, R. McDuff. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6338) 6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API). S. Josefsson, L. Hornquist Astrand. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6339) 6340 Textual Conventions for the Representation of Floating-Point Numbers. R. Presuhn. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6340) 6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC). K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6341) 6342 Mobile Networks Considerations for IPv6 Deployment. R. Koodli. August 2011. (Format: TXT, HTML) (Obsoletes RFC6312) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6342) 6343 Advisory Guidelines for 6to4 Deployment. B. Carpenter. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6343) 6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS). G. Bernstein, Ed., D. Caviglia, R. Rabbat, H. van Helvoort. August 2011. (Format: TXT, HTML) (Updates RFC4606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6344) 6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element. P. Duffy, S. Chakrabarti, R. Cragie, Y. Ohba, Ed., A. Yegin. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6345) 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage. R. Bush, Ed.. August 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6346) 6347 Datagram Transport Layer Security Version 1.2. E. Rescorla, N. Modadugu. January 2012. (Format: TXT, HTML) (Obsoletes RFC4347) (Updated by RFC7507, RFC7905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6347) 6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol. JL. Le Roux, Ed., T. Morin, Ed.. September 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6348) 6349 Framework for TCP Throughput Testing. B. Constantine, G. Forget, R. Geib, R. Schrage. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6349) 6350 vCard Format Specification. S. Perreault. August 2011. (Format: TXT, HTML) (Obsoletes RFC2425, RFC2426, RFC4770) (Updates RFC2739) (Updated by RFC6868) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6350) 6351 xCard: vCard XML Representation. S. Perreault. August 2011. (Format: TXT, HTML) (Updated by RFC6868) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6351) 6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV). C. Daboo. August 2011. (Format: TXT, HTML) (Updated by RFC6764) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6352) 6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP). W. Hardaker. July 2011. (Format: TXT, HTML) (Obsoletes RFC5953) (Also STD0078) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6353) 6354 Forward-Shifted RTP Redundancy Payload Support. Q. Xie. August 2011. (Format: TXT, HTML) (Updates RFC2198, RFC4102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6354) 6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID). T. Narten, J. Johnson. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6355) 6356 Coupled Congestion Control for Multipath Transport Protocols. C. Raiciu, M. Handley, D. Wischik. October 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6356) 6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control. V. Hilt, E. Noel, C. Shen, A. Abdelal. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6357) 6358 Additional Master Secret Inputs for TLS. P. Hoffman. January 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6358) 6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information. S. Ginoza, M. Cotton, A. Morris. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6359) 6360 Conclusion of FYI RFC Sub-Series. R. Housley. August 2011. (Format: TXT, HTML) (Obsoletes RFC1150) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6360) 6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol. J. Carlson, D. Eastlake 3rd. August 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6361) 6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT). K. Meadors, Ed.. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6362) 6363 Forward Error Correction (FEC) Framework. M. Watson, A. Begen, V. Roca. October 2011. (Format: TXT, HTML) (Updated by RFC8680) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6363) 6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework. A. Begen. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6364) 6365 Terminology Used in Internationalization in the IETF. P. Hoffman, J. Klensin. September 2011. (Format: TXT, HTML) (Obsoletes RFC3536) (Also BCP0166) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6365) 6366 Requirements for an Internet Audio Codec. J. Valin, K. Vos. August 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6366) 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS). S. Kanno, M. Kanda. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6367) 6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata. September 2011. (Format: TXT, HTML) (Updated by RFC7606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6368) 6369 Forwarding and Control Element Separation (ForCES) Implementation Experience. E. Haleplidis, O. Koufopavlou, S. Denazis. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6369) 6370 MPLS Transport Profile (MPLS-TP) Identifiers. M. Bocci, G. Swallow, E. Gray. September 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6370) 6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks. I. Busi, Ed., D. Allan, Ed.. September 2011. (Format: TXT, HTML) (Updated by RFC6435) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6371) 6372 MPLS Transport Profile (MPLS-TP) Survivability Framework. N. Sprecher, Ed., A. Farrel, Ed.. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6372) 6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework. L. Andersson, Ed., L. Berger, Ed., L. Fang, Ed., N. Bitar, Ed., E. Gray, Ed.. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6373) 6374 Packet Loss and Delay Measurement for MPLS Networks. D. Frost, S. Bryant. September 2011. (Format: TXT, HTML) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6374) 6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks. D. Frost, Ed., S. Bryant, Ed.. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6375) 6376 DomainKeys Identified Mail (DKIM) Signatures. D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.. September 2011. (Format: TXT, HTML) (Obsoletes RFC4871, RFC5672) (Updated by RFC8301, RFC8463, RFC8553, RFC8616) (Also STD0076) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6376) 6377 DomainKeys Identified Mail (DKIM) and Mailing Lists. M. Kucherawy. September 2011. (Format: TXT, HTML) (Also BCP0167) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6377) 6378 MPLS Transport Profile (MPLS-TP) Linear Protection. Y. Weingarten, Ed., S. Bryant, E. Osborne, N. Sprecher, A. Fulignoli, Ed.. October 2011. (Format: TXT, HTML) (Updated by RFC7214, RFC7271, RFC7324) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6378) 6379 Suite B Cryptographic Suites for IPsec. L. Law, J. Solinas. October 2011. (Format: TXT, HTML) (Obsoletes RFC4869) (Status: HISTORIC) (DOI: 10.17487/RFC6379) 6380 Suite B Profile for Internet Protocol Security (IPsec). K. Burgin, M. Peck. October 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6380) 6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types. R. Gellens, D. Singer, P. Frojdh. August 2011. (Format: TXT, HTML) (Obsoletes RFC4281) (Updates RFC3839, RFC4393, RFC4337) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6381) 6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services. D. McPherson, R. Donnelly, F. Scalzo. October 2011. (Format: TXT, HTML) (Also BCP0169) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6382) 6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE. K. Shiomoto, A. Farrel. September 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6383) 6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation. I. van Beijnum. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6384) 6385 General Area Review Team (Gen-ART) Experiences. M. Barnes, A. Doria, H. Alvestrand, B. Carpenter. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6385) 6386 VP8 Data Format and Decoding Guide. J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, Y. Xu. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6386) 6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). A. Takacs, L. Berger, D. Caviglia, D. Fedyk, J. Meuric. September 2011. (Format: TXT, HTML) (Obsoletes RFC5467) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6387) 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas. November 2011. (Format: TXT, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6388) 6389 MPLS Upstream Label Assignment for LDP. R. Aggarwal, JL. Le Roux. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6389) 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT, HTML) (Also BCP0170) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6390) 6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network. S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante. November 2011. (Format: TXT, HTML) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6391) 6392 A Survey of In-Network Storage Systems. R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed.. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6392) 6393 Moving RFC 4693 to Historic. M. Yevstifeyev. September 2011. (Format: TXT, HTML) (Obsoletes RFC4693) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6393) 6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE). R. Barnes. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6394) 6395 An Interface Identifier (ID) Hello Option for PIM. S. Gulrajani, S. Venaas. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6395) 6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format. L. Blunk, M. Karir, C. Labovitz. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6396) 6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions. T. Manderson. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6397) 6398 IP Router Alert Considerations and Usage. F. Le Faucheur, Ed.. October 2011. (Format: TXT, HTML) (Updates RFC2113, RFC2711) (Also BCP0168) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6398) 6399 Not Issued. 6400 Not Issued. 6401 RSVP Extensions for Admission Priority. F. Le Faucheur, J. Polk, K. Carlberg. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6401) 6402 Certificate Management over CMS (CMC) Updates. J. Schaad. November 2011. (Format: TXT, HTML) (Updates RFC5272, RFC5273, RFC5274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6402) 6403 Suite B Profile of Certificate Management over CMS. L. Zieglar, S. Turner, M. Peck. November 2011. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6403) 6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures. J. Seedorf, S. Niccolini, E. Chen, H. Scholz. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6404) 6405 Voice over IP (VoIP) SIP Peering Use Cases. A. Uzelac, Ed., Y. Lee, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6405) 6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture. D. Malas, Ed., J. Livingood, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6406) 6407 The Group Domain of Interpretation. B. Weis, S. Rowles, T. Hardjono. October 2011. (Format: TXT, HTML) (Obsoletes RFC3547) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6407) 6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage. M. Jones, J. Korhonen, L. Morand. November 2011. (Format: TXT, HTML) (Updates RFC3588) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6408) 6409 Message Submission for Mail. R. Gellens, J. Klensin. November 2011. (Format: TXT, HTML) (Obsoletes RFC4409) (Updated by RFC8314) (Also STD0072) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6409) 6410 Reducing the Standards Track to Two Maturity Levels. R. Housley, D. Crocker, E. Burger. October 2011. (Format: TXT, HTML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6410) 6411 Applicability of Keying Methods for RSVP Security. M. Behringer, F. Le Faucheur, B. Weis. October 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6411) 6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence. S. Poretsky, B. Imhoff, K. Michielsen. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6412) 6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence. S. Poretsky, B. Imhoff, K. Michielsen. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6413) 6414 Benchmarking Terminology for Protection Performance. S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6414) 6415 Web Host Metadata. E. Hammer-Lahav, Ed., B. Cook. October 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6415) 6416 RTP Payload Format for MPEG-4 Audio/Visual Streams. M. Schmidt, F. de Bont, S. Doehla, J. Kim. October 2011. (Format: TXT, HTML) (Obsoletes RFC3016) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6416) 6417 How to Contribute Research Results to Internet Standardization. P. Eardley, L. Eggert, M. Bagnulo, R. Winter. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6417) 6418 Multiple Interfaces and Provisioning Domains Problem Statement. M. Blanchet, P. Seite. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6418) 6419 Current Practices for Multiple-Interface Hosts. M. Wasserman, P. Seite. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6419) 6420 PIM Multi-Topology ID (MT-ID) Join Attribute. Y. Cai, H. Ou. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6420) 6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS). D. Nelson, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6421) 6422 Relay-Supplied DHCP Options. T. Lemon, Q. Wu. December 2011. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6422) 6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP). H. Li, L. Martini, J. He, F. Huang. November 2011. (Format: TXT, HTML) (Updates RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6423) 6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels. N. Bahadur, K. Kompella, G. Swallow. November 2011. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC4379) (Updated by RFC7537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6424) 6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping. S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau. November 2011. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6425) 6426 MPLS On-Demand Connectivity Verification and Route Tracing. E. Gray, N. Bahadur, S. Boutros, R. Aggarwal. November 2011. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6426) 6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM). G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward. November 2011. (Format: TXT, HTML) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6427) 6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile. D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.. November 2011. (Format: TXT, HTML) (Updated by RFC7214) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6428) 6429 TCP Sender Clarification for Persist Condition. M. Bashyam, M. Jethanandani, A. Ramaiah. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6429) 6430 Email Feedback Report Type Value: not-spam. K. Li, B. Leiba. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6430) 6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP). M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6431) 6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses. R. Jesske, L. Liess. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6432) 6433 Requirements for a Working Group Milestones Tool. P. Hoffman. November 2011. (Format: TXT, HTML) (Updates RFC6292) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6433) 6434 IPv6 Node Requirements. E. Jankiewicz, J. Loughney, T. Narten. December 2011. (Format: TXT, HTML) (Obsoletes RFC4294) (Obsoleted by RFC8504) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6434) 6435 MPLS Transport Profile Lock Instruct and Loopback Functions. S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.. November 2011. (Format: TXT, HTML) (Updates RFC6371) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6435) 6436 Rationale for Update to the IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6436) 6437 IPv6 Flow Label Specification. S. Amante, B. Carpenter, S. Jiang, J. Rajahalme. November 2011. (Format: TXT, HTML) (Obsoletes RFC3697) (Updates RFC2205, RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6437) 6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels. B. Carpenter, S. Amante. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6438) 6439 Routing Bridges (RBridges): Appointed Forwarders. R. Perlman, D. Eastlake, Y. Li, A. Banerjee, F. Hu. November 2011. (Format: TXT, HTML) (Obsoleted by RFC8139) (Updates RFC6325) (Updated by RFC7180) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6439) 6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option. G. Zorn, Q. Wu, Y. Wang. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6440) 6441 Time to Remove Filters for Previously Unallocated IPv4 /8s. L. Vegoda. November 2011. (Format: TXT, HTML) (Also BCP0171) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6441) 6442 Location Conveyance for the Session Initiation Protocol. J. Polk, B. Rosen, J. Peterson. December 2011. (Format: TXT, HTML) (Updated by RFC8262, RFC8787) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6442) 6443 Framework for Emergency Calling Using Internet Multimedia. B. Rosen, H. Schulzrinne, J. Polk, A. Newton. December 2011. (Format: TXT, HTML) (Updated by RFC7852) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6443) 6444 Location Hiding: Problem Statement and Requirements. H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6444) 6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute. T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed.. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6445) 6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control. A. Niemi, K. Kiss, S. Loreto. January 2012. (Format: TXT, HTML) (Updates RFC3265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6446) 6447 Filtering Location Notifications in the Session Initiation Protocol (SIP). R. Mahy, B. Rosen, H. Tschofenig. January 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6447) 6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message. R. Yount. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6448) 6449 Complaint Feedback Loop Operational Recommendations. J. Falk, Ed.. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6449) 6450 Multicast Ping Protocol. S. Venaas. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6450) 6451 Location-to-Service Translation (LoST) Protocol Extensions. A. Forte, H. Schulzrinne. December 2011. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6451) 6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0. P. Faltstrom, Ed., P. Hoffman, Ed.. November 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6452) 6453 A URN Namespace for the Open Grid Forum (OGF). F. Dijkstra, R. Hughes-Jones. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6453) 6454 The Web Origin Concept. A. Barth. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6454) 6455 The WebSocket Protocol. I. Fette, A. Melnikov. December 2011. (Format: TXT, HTML) (Updated by RFC7936, RFC8307, RFC8441) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6455) 6456 Multi-Segment Pseudowires in Passive Optical Networks. H. Li, R. Zheng, A. Farrel. November 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6456) 6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering. T. Takeda, Ed., A. Farrel. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6457) 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP). R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6458) 6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS). J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6459) 6460 Suite B Profile for Transport Layer Security (TLS). M. Salter, R. Housley. January 2012. (Format: TXT, HTML) (Obsoletes RFC5430) (Status: HISTORIC) (DOI: 10.17487/RFC6460) 6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements. S. Channabasappa, Ed.. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6461) 6462 Report from the Internet Privacy Workshop. A. Cooper. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6462) 6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6. J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6463) 6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication. J. Lennox, Ed., E. Ivov, E. Marocco. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6464) 6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication. E. Ivov, Ed., E. Marocco, Ed., J. Lennox. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6465) 6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP). G. Salgueiro. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6466) 6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2). T. Kivinen. December 2011. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6467) 6468 Sieve Notification Mechanism: SIP MESSAGE. A. Melnikov, B. Leiba, K. Li. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6468) 6469 RTP Payload Format for DV (IEC 61834) Video. K. Kobayashi, K. Mishima, S. Casner, C. Bormann. December 2011. (Format: TXT, HTML) (Obsoletes RFC3189) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6469) 6470 Network Configuration Protocol (NETCONF) Base Notifications. A. Bierman. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6470) 6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices. C. Lewis, M. Sergeant. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6471) 6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. W. Kumari, K. Sriram. December 2011. (Format: TXT, HTML) (Also BCP0172) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6472) 6473 vCard KIND:application. P. Saint-Andre. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6473) 6474 vCard Format Extensions: Place of Birth, Place and Date of Death. K. Li, B. Leiba. December 2011. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6474) 6475 Proxy Mobile IPv6 Management Information Base. G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6475) 6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS). P. Gutmann. January 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6476) 6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail. A. Melnikov, G. Lunt. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6477) 6478 Pseudowire Status for Static Pseudowires. L. Martini, G. Swallow, G. Heron, M. Bocci. May 2012. (Format: TXT, HTML) (Updates RFC5885) (Updated by RFC7274) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6478) 6479 IPsec Anti-Replay Algorithm without Bit Shifting. X. Zhang, T. Tsou. January 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6479) 6480 An Infrastructure to Support Secure Internet Routing. M. Lepinski, S. Kent. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6480) 6481 A Profile for Resource Certificate Repository Structure. G. Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6481) 6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S. Kent, D. Kong. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6482) 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs). G. Huston, G. Michaelson. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6483) 6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI). S. Kent, D. Kong, K. Seo, R. Watro. February 2012. (Format: TXT, HTML) (Also BCP0173) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6484) 6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI). G. Huston. February 2012. (Format: TXT, HTML) (Obsoleted by RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6485) 6486 Manifests for the Resource Public Key Infrastructure (RPKI). R. Austein, G. Huston, S. Kent, M. Lepinski. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6486) 6487 A Profile for X.509 PKIX Resource Certificates. G. Huston, G. Michaelson, R. Loomans. February 2012. (Format: TXT, HTML) (Updated by RFC7318, RFC8209) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6487) 6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI). M. Lepinski, A. Chi, S. Kent. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6488) 6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI). G. Huston, G. Michaelson, S. Kent. February 2012. (Format: TXT, HTML) (Also BCP0174) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6489) 6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. February 2012. (Format: TXT, HTML) (Obsoleted by RFC7730) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6490) 6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA. T. Manderson, L. Vegoda, S. Kent. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6491) 6492 A Protocol for Provisioning Resource Certificates. G. Huston, R. Loomans, B. Ellacott, R. Austein. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6492) 6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record. R. Bush. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6493) 6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND). R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT, HTML) (Updates RFC3971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6494) 6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields. R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT, HTML) (Updates RFC3971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6495) 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND). S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6496) 6497 BCP 47 Extension T - Transformed Content. M. Davis, A. Phillips, Y. Umaoka, C. Falk. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6497) 6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package. J. Stone, R. Kumar, F. Andreasen. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6498) 6499 Not Issued. 6500 Not Issued. 6501 Conference Information Data Model for Centralized Conferencing (XCON). O. Novo, G. Camarillo, D. Morgan, J. Urpalainen. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6501) 6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON). G. Camarillo, S. Srinivasan, R. Even, J. Urpalainen. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6502) 6503 Centralized Conferencing Manipulation Protocol. M. Barnes, C. Boulton, S. Romano, H. Schulzrinne. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6503) 6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples. M. Barnes, L. Miniero, R. Presta, S P. Romano. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6504) 6505 A Mixer Control Package for the Media Control Channel Framework. S. McGlashan, T. Melanchuk, C. Boulton. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6505) 6506 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. February 2012. (Format: TXT, HTML) (Obsoleted by RFC7166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6506) 6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6507) 6508 Sakai-Kasahara Key Encryption (SAKKE). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6508) 6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY). M. Groves. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6509) 6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects. L. Berger, G. Swallow. February 2012. (Format: TXT, HTML) (Updates RFC4875, RFC5420) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6510) 6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths. Z. Ali, G. Swallow, R. Aggarwal. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6511) 6512 Using Multipoint LDP When the Backbone Has No Route to the Root. IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6512) 6513 Multicast in MPLS/BGP IP VPNs. E. Rosen, Ed., R. Aggarwal, Ed.. February 2012. (Format: TXT, HTML) (Updated by RFC7582, RFC7900, RFC7988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6513) 6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs. R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter. February 2012. (Format: TXT, HTML) (Updated by RFC6515, RFC6625, RFC7385, RFC7441, RFC7582, RFC7899, RFC7900, RFC7902, RFC7988, RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6514) 6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN. R. Aggarwal, E. Rosen. February 2012. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6515) 6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages. Y. Cai, E. Rosen, Ed., I. Wijnands. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6516) 6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution. T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6517) 6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines. G. Lebovitz, M. Bhatia. February 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6518) 6519 RADIUS Extensions for Dual-Stack Lite. R. Maglione, A. Durand. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6519) 6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. R. Seggelmann, M. Tuexen, M. Williams. February 2012. (Format: TXT, HTML) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6520) 6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks. A. Makela, J. Korhonen. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6521) 6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages. M. Kucherawy, Ed.. January 2012. (Format: TXT, HTML) (Obsoletes RFC3462) (Updated by RFC6533) (Also STD0073) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6522) 6523 Not Issued. 6524 Not Issued. 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration. R. Stewart, M. Tuexen, P. Lei. February 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6525) 6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream. B. Claise, P. Aitken, A. Johnson, G. Muenz. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6526) 6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3). K. Tata. March 2012. (Format: TXT, HTML) (Obsoletes RFC2787) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6527) 6528 Defending against Sequence Number Attacks. F. Gont, S. Bellovin. February 2012. (Format: TXT, HTML) (Obsoletes RFC1948) (Updates RFC0793) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6528) 6529 Host/Host Protocol for the ARPA Network. A. McKenzie, S. Crocker. April 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6529) 6530 Overview and Framework for Internationalized Email. J. Klensin, Y. Ko. February 2012. (Format: TXT, HTML) (Obsoletes RFC4952, RFC5504, RFC5825) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6530) 6531 SMTP Extension for Internationalized Email. J. Yao, W. Mao. February 2012. (Format: TXT, HTML) (Obsoletes RFC5336) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6531) 6532 Internationalized Email Headers. A. Yang, S. Steele, N. Freed. February 2012. (Format: TXT, HTML) (Obsoletes RFC5335) (Updates RFC2045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6532) 6533 Internationalized Delivery Status and Disposition Notifications. T. Hansen, Ed., C. Newman, A. Melnikov. February 2012. (Format: TXT, HTML) (Obsoletes RFC5337) (Updates RFC3461, RFC3464, RFC3798, RFC6522) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6533) 6534 Loss Episode Metrics for IP Performance Metrics (IPPM). N. Duffield, A. Morton, J. Sommers. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6534) 6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH). B. Huang, H. Deng, T. Savolainen. February 2012. (Format: TXT, HTML) (Obsoletes RFC2767, RFC3338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6535) 6536 Network Configuration Protocol (NETCONF) Access Control Model. A. Bierman, M. Bjorklund. March 2012. (Format: TXT, HTML) (Obsoleted by RFC8341) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6536) 6537 Host Identity Protocol Distributed Hash Table Interface. J. Ahrenholz. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6537) 6538 The Host Identity Protocol (HIP) Experiment Report. T. Henderson, A. Gurtov. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6538) 6539 IBAKE: Identity-Based Authenticated Key Exchange. V. Cakulev, G. Sundaram, I. Broustis. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6539) 6540 IPv6 Support Required for All IP-Capable Nodes. W. George, C. Donley, C. Liljenstolpe, L. Howard. April 2012. (Format: TXT, HTML) (Also BCP0177) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6540) 6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures. M. Kucherawy. February 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6541) 6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility. S. Emery. March 2012. (Format: TXT, HTML) (Updates RFC4121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6542) 6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6. S. Gundavelli. May 2012. (Format: TXT, HTML) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6543) 6544 TCP Candidates with Interactive Connectivity Establishment (ICE). J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6544) 6545 Real-time Inter-network Defense (RID). K. Moriarty. April 2012. (Format: TXT, HTML) (Obsoletes RFC6045) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6545) 6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS. B. Trammell. April 2012. (Format: TXT, HTML) (Obsoletes RFC6046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6546) 6547 RFC 3627 to Historic Status. W. George. February 2012. (Format: TXT, HTML) (Obsoletes RFC3627) (Updates RFC6164) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6547) 6548 Independent Submission Editor Model. N. Brownlee, Ed., IAB. June 2012. (Format: TXT, HTML) (Obsoletes RFC5620) (Obsoleted by RFC8730) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6548) 6549 OSPFv2 Multi-Instance Extensions. A. Lindem, A. Roy, S. Mirtorabi. March 2012. (Format: TXT, HTML) (Updates RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6549) 6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6550) 6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks. JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6551) 6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL). P. Thubert, Ed.. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6552) 6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams. J. Hui, JP. Vasseur. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6553) 6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL). J. Hui, JP. Vasseur, D. Culler, V. Manral. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6554) 6555 Happy Eyeballs: Success with Dual-Stack Hosts. D. Wing, A. Yourtchenko. April 2012. (Format: TXT, HTML) (Obsoleted by RFC8305) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6555) 6556 Testing Eyeball Happiness. F. Baker. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6556) 6557 Procedures for Maintaining the Time Zone Database. E. Lear, P. Eggert. February 2012. (Format: TXT, HTML) (Also BCP0175) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6557) 6558 Sieve Extension for Converting Messages before Delivery. A. Melnikov, B. Leiba, K. Li. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6558) 6559 A Reliable Transport Mechanism for PIM. D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala. March 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6559) 6560 One-Time Password (OTP) Pre-Authentication. G. Richards. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6560) 6561 Recommendations for the Remediation of Bots in ISP Networks. J. Livingood, N. Mody, M. O'Reirdan. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6561) 6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP. C. Perkins, JM. Valin. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6562) 6563 Moving A6 to Historic Status. S. Jiang, D. Conrad, B. Carpenter. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6563) 6564 A Uniform Format for IPv6 Extension Headers. S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia. April 2012. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6564) 6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol. P. Pillay-Esnault, P. Moyer, J. Doyle, E. Ertekin, M. Lundberg. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6565) 6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments. Y. Lee, Ed., G. Bernstein, Ed., D. Li, G. Martinelli. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6566) 6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP. A. Johnston, L. Liess. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6567) 6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). E. Kim, D. Kaspar, JP. Vasseur. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6568) 6569 Guidelines for Development of an Audio Codec within the IETF. JM. Valin, S. Borilin, K. Vos, C. Montgomery, R. Chen. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6569) 6570 URI Template. J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6570) 6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks. C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6571) 6572 RADIUS Support for Proxy Mobile IPv6. F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic. June 2012. (Format: TXT, HTML) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6572) 6573 The Item and Collection Link Relations. M. Amundsen. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6573) 6574 Report from the Smart Object Workshop. H. Tschofenig, J. Arkko. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6574) 6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs. H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed.. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6575) 6576 IP Performance Metrics (IPPM) Standard Advancement Testing. R. Geib, Ed., A. Morton, R. Fardid, A. Steinmitz. March 2012. (Format: TXT, HTML) (Also BCP0176) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6576) 6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results. M. Kucherawy. March 2012. (Format: TXT, HTML) (Obsoleted by RFC7001) (Updates RFC5451) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6577) 6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV). C. Daboo, A. Quillaud. March 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6578) 6579 The 'disclosure' Link Relation Type. M. Yevstifeyev. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6579) 6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols. M. Ko, D. Black. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6580) 6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment. A. Kanevsky, Ed., C. Bestler, Ed., R. Sharp, S. Wise. April 2012. (Format: TXT, HTML) (Updates RFC5043, RFC5044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6581) 6582 The NewReno Modification to TCP's Fast Recovery Algorithm. T. Henderson, S. Floyd, A. Gurtov, Y. Nishida. April 2012. (Format: TXT, HTML) (Obsoletes RFC3782) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6582) 6583 Operational Neighbor Discovery Problems. I. Gashinsky, J. Jaeggli, W. Kumari. March 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6583) 6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6584) 6585 Additional HTTP Status Codes. M. Nottingham, R. Fielding. April 2012. (Format: TXT, HTML) (Updates RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6585) 6586 Experiences from an IPv6-Only Network. J. Arkko, A. Keranen. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6586) 6587 Transmission of Syslog Messages over TCP. R. Gerhards, C. Lonvick. April 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6587) 6588 A URN Namespace for ucode. C. Ishikawa. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6588) 6589 Considerations for Transitioning Content to IPv6. J. Livingood. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6589) 6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports. J. Falk, Ed., M. Kucherawy, Ed.. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6590) 6591 Authentication Failure Reporting Using the Abuse Reporting Format. H. Fontana. April 2012. (Format: TXT, HTML) (Updated by RFC6692) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6591) 6592 The Null Packet. C. Pignataro. 1 April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6592) 6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS). C. Pignataro, J. Clarke, G. Salgueiro. 1 April 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6593) 6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records. O. Sury. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6594) 6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML). K. Wierenga, E. Lear, S. Josefsson. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6595) 6596 The Canonical Link Relation. M. Ohye, J. Kupke. April 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6596) 6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data. J. Downs, Ed., J. Arbeiter, Ed.. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6597) 6598 IANA-Reserved IPv4 Prefix for Shared Address Space. J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, M. Azinger. April 2012. (Format: TXT, HTML) (Updates RFC5735) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6598) 6599 Not Issued. 6600 Not Issued. 6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks. G. Ash, Ed., D. McDysan. April 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6601) 6602 Bulk Binding Update Support for Proxy Mobile IPv6. F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6602) 6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation. J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan. May 2012. (Format: TXT, HTML) (Updates RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6603) 6604 xNAME RCODE and Status Bits Clarification. D. Eastlake 3rd. April 2012. (Format: TXT, HTML) (Updates RFC1035, RFC2308, RFC2672) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6604) 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC. P. Hoffman, W.C.A. Wijngaards. April 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6605) 6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing. E. Kim, D. Kaspar, C. Gomez, C. Bormann. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6606) 6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6. K. Kinnear, R. Johnson, M. Stapp. April 2012. (Format: TXT, HTML) (Updates RFC3046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6607) 6608 Subcodes for BGP Finite State Machine Error. J. Dong, M. Chen, A. Suryanarayana. May 2012. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6608) 6609 Sieve Email Filtering: Include Extension. C. Daboo, A. Stone. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6609) 6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6). H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6610) 6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario. K. Chowdhury, Ed., A. Yegin. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6611) 6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues. G. Giaretta, Ed.. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6612) 6613 RADIUS over TCP. A. DeKok. May 2012. (Format: TXT, HTML) (Updated by RFC7930) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6613) 6614 Transport Layer Security (TLS) Encryption for RADIUS. S. Winter, M. McCauley, S. Venaas, K. Wierenga. May 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6614) 6615 Definitions of Managed Objects for IP Flow Information Export. T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. June 2012. (Format: TXT, HTML) (Obsoletes RFC5815) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6615) 6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID. E. Lear, H. Tschofenig, H. Mauldin, S. Josefsson. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6616) 6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE). D. Harkins. June 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6617) 6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent. J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg. May 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6618) 6619 Scalable Operation of Address Translators with Per-Interface Bindings. J. Arkko, L. Eggert, M. Townsley. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6619) 6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses. E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. May 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6620) 6621 Simplified Multicast Forwarding. J. Macker, Ed.. May 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6621) 6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs). U. Herberg, T. Clausen. May 2012. (Format: TXT, HTML) (Obsoleted by RFC7182) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6622) 6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package. E. Burger. May 2012. (Format: TXT, HTML) (Updates RFC6231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6623) 6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling. K. Kompella, B. Kothari, R. Cherukuri. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6624) 6625 Wildcards in Multicast VPN Auto-Discovery Routes. E. Rosen, Ed., Y. Rekhter, Ed., W. Hendrickx, R. Qiu. May 2012. (Format: TXT, HTML) (Updates RFC6514) (Updated by RFC7582, RFC7900, RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6625) 6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4). G. Tsirtsis, V. Park, V. Narayanan, K. Leung. May 2012. (Format: TXT, HTML) (Updates RFC5177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6626) 6627 Overview of Pre-Congestion Notification Encoding. G. Karagiannis, K. Chan, T. Moncaster, M. Menth, P. Eardley, B. Briscoe. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6627) 6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2. S. Shin, K. Kobara. June 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6628) 6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6). J. Abley, M. Bagnulo, A. Garcia-Martinez. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6629) 6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK). Z. Cao, H. Deng, Q. Wu, G. Zorn, Ed.. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6630) 6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2). D. Kuegler, Y. Sheffer. June 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6631) 6632 An Overview of the IETF Network Management Standards. M. Ersue, Ed., B. Claise. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6632) 6633 Deprecation of ICMP Source Quench Messages. F. Gont. May 2012. (Format: TXT, HTML) (Updates RFC0792, RFC1122, RFC1812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6633) 6634 Not Issued. 6635 RFC Editor Model (Version 2). O. Kolkman, Ed., J. Halpern, Ed., IAB. June 2012. (Format: TXT, HTML) (Obsoletes RFC5620) (Obsoleted by RFC8728) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6635) 6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks. H. Asaeda, H. Liu, Q. Wu. May 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6636) 6637 Elliptic Curve Cryptography (ECC) in OpenPGP. A. Jivsov. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6637) 6638 Scheduling Extensions to CalDAV. C. Daboo, B. Desruisseaux. June 2012. (Format: TXT, HTML) (Updates RFC4791, RFC5546) (Updated by RFC7953) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6638) 6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview. D. King, Ed., M. Venkatesan, Ed.. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6639) 6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions. W. George. June 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6640) 6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4. C. Everhart, W. Adamson, J. Zhang. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6641) 6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report. Q. Wu, Ed., F. Xia, R. Even. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6642) 6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules. J. Schoenwaelder. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6643) 6644 Rebind Capability in DHCPv6 Reconfigure Messages. D. Evans, R. Droms, S. Jiang. July 2012. (Format: TXT, HTML) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6644) 6645 IP Flow Information Accounting and Export Benchmarking Methodology. J. Novak. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6645) 6646 DECoupled Application Data Enroute (DECADE) Problem Statement. H. Song, N. Zong, Y. Yang, R. Alimi. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6646) 6647 Email Greylisting: An Applicability Statement for SMTP. M. Kucherawy, D. Crocker. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6647) 6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols. P. Saint-Andre, D. Crocker, M. Nottingham. June 2012. (Format: TXT, HTML) (Also BCP0178) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6648) 6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos. L. Hornquist Astrand, T. Yu. July 2012. (Format: TXT, HTML) (Obsoletes RFC1510) (Updates RFC1964, RFC4120, RFC4121, RFC4757) (Also BCP0179) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6649) 6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF). J. Falk, M. Kucherawy, Ed.. June 2012. (Format: TXT, HTML) (Updates RFC5965) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6650) 6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting. M. Kucherawy. June 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6651) 6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format. S. Kitterman. June 2012. (Format: TXT, HTML) (Updates RFC4408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6652) 6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks. B. Sarikaya, F. Xia, T. Lemon. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6653) 6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd). T. Tsou, C. Zhou, T. Taylor, Q. Chen. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6654) 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS). D. McGrew, D. Bailey. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6655) 6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4. R. Johnson, K. Kinnear, M. Stapp. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6656) 6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types. A. Melnikov, J. Reschke. July 2012. (Format: TXT, HTML) (Updates RFC2046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6657) 6658 Packet Pseudowire Encapsulation over an MPLS PSN. S. Bryant, Ed., L. Martini, G. Swallow, A. Malis. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6658) 6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method. A. Begen. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6659) 6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP). B. Briscoe, T. Moncaster, M. Menth. July 2012. (Format: TXT, HTML) (Obsoletes RFC5696) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6660) 6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation. A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed.. July 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6661) 6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation. A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed.. July 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6662) 6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain. G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6663) 6664 S/MIME Capabilities for Public Key Definitions. J. Schaad. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6664) 6665 SIP-Specific Event Notification. A.B. Roach. July 2012. (Format: TXT, HTML) (Obsoletes RFC3265) (Updates RFC3261, RFC4660) (Updated by RFC7621) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6665) 6666 A Discard Prefix for IPv6. N. Hilliard, D. Freedman. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6666) 6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements. K. Raza, S. Boutros, C. Pignataro. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6667) 6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol. D. Bider, M. Baushke. July 2012. (Format: TXT, HTML) (Updates RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6668) 6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks. N. Sprecher, L. Fang. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6669) 6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). N. Sprecher, KY. Hong. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6670) 6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM). M. Betts. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6671) 6672 DNAME Redirection in the DNS. S. Rose, W. Wijngaards. June 2012. (Format: TXT, HTML) (Obsoletes RFC2672) (Updates RFC3363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6672) 6673 Round-Trip Packet Loss Metrics. A. Morton. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6673) 6674 Gateway-Initiated Dual-Stack Lite Deployment. F. Brockners, S. Gundavelli, S. Speicher, D. Ward. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6674) 6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP. E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida. August 2012. (Format: TXT, HTML) (Obsoletes RFC3517) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6675) 6676 Multicast Addresses for Documentation. S. Venaas, R. Parekh, G. Van de Velde, T. Chown, M. Eubanks. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6676) 6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods. S. Hartman, Ed., T. Clancy, K. Hoeper. July 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6677) 6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method. K. Hoeper, S. Hanna, H. Zhou, J. Salowey, Ed.. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6678) 6679 Explicit Congestion Notification (ECN) for RTP over UDP. M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg. August 2012. (Format: TXT, HTML) (Updated by RFC8311) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6679) 6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions. N. Williams, L. Johansson, S. Hartman, S. Josefsson. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6680) 6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME. M. Watson, T. Stockhammer, M. Luby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6681) 6682 RTP Payload Format for Raptor Forward Error Correction (FEC). M. Watson, T. Stockhammer, M. Luby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6682) 6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection. A. Begen, T. Stockhammer. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6683) 6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF). B. Trammell. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6684) 6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry. B. Trammell. July 2012. (Format: TXT, HTML) (Obsoleted by RFC7970) (Updates RFC5070) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6685) 6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments. M. Kucherawy. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6686) 6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL). J. Tripathi, Ed., J. de Oliveira, Ed., JP. Vasseur, Ed.. October 2012. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6687) 6688 Parallel NFS (pNFS) Block Disk Protection. D. Black, Ed., J. Glasgow, S. Faibish. July 2012. (Format: TXT, HTML) (Updates RFC5663) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6688) 6689 Usage of the RSVP ASSOCIATION Object. L. Berger. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6689) 6690 Constrained RESTful Environments (CoRE) Link Format. Z. Shelby. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6690) 6691 TCP Options and Maximum Segment Size (MSS). D. Borman. July 2012. (Format: TXT, HTML) (Updates RFC0879, RFC2385) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6691) 6692 Source Ports in Abuse Reporting Format (ARF) Reports. R. Clayton, M. Kucherawy. July 2012. (Format: TXT, HTML) (Updates RFC6591) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6692) 6693 Probabilistic Routing Protocol for Intermittently Connected Networks. A. Lindgren, A. Doria, E. Davies, S. Grasic. August 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6693) 6694 The "about" URI Scheme. S. Moonesamy, Ed.. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6694) 6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information. R. Asati. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6695) 6696 EAP Extensions for the EAP Re-authentication Protocol (ERP). Z. Cao, B. He, Y. Shi, Q. Wu, Ed., G. Zorn, Ed.. July 2012. (Format: TXT, HTML) (Obsoletes RFC5296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6696) 6697 Handover Keying (HOKEY) Architecture Design. G. Zorn, Ed., Q. Wu, T. Taylor, Y. Nir, K. Hoeper, S. Decugis. July 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6697) 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. P. Hoffman, J. Schlyter. August 2012. (Format: TXT, HTML) (Updated by RFC7218, RFC7671, RFC8749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6698) 6699 Not Issued. 6700 Not Issued. 6701 Sanctions Available for Application to Violators of IETF IPR Policy. A. Farrel, P. Resnick. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6701) 6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules. T. Polk, P. Saint-Andre. August 2012. (Format: TXT, HTML) (Updated by RFC8717) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6702) 6703 Reporting IP Network Performance Metrics: Different Points of View. A. Morton, G. Ramachandran, G. Maguluri. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6703) 6704 Forcerenew Nonce Authentication. D. Miles, W. Dec, J. Bristow, R. Maglione. August 2012. (Format: TXT, HTML) (Updates RFC3203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6704) 6705 Localized Routing for Proxy Mobile IPv6. S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6705) 6706 Asymmetric Extended Route Optimization (AERO). F. Templin, Ed.. August 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6706) 6707 Content Distribution Network Interconnection (CDNI) Problem Statement. B. Niven-Jenkins, F. Le Faucheur, N. Bitar. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6707) 6708 Application-Layer Traffic Optimization (ALTO) Requirements. S. Kiesel, Ed., S. Previdi, M. Stiemerling, R. Woundy, Y. Yang. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6708) 6709 Design Considerations for Protocol Extensions. B. Carpenter, B. Aboba, Ed., S. Cheshire. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6709) 6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities. A. Melnikov, K. Carlberg. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6710) 6711 An IANA Registry for Level of Assurance (LoA) Profiles. L. Johansson. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6711) 6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP). T. Kause, M. Peylo. September 2012. (Format: TXT, HTML) (Updates RFC4210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6712) 6713 The 'application/zlib' and 'application/gzip' Media Types. J. Levine. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6713) 6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP). C. Holmberg, S. Blau, E. Burger. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6714) 6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group. D. Cauchie, B. Leiba, K. Li. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6715) 6716 Definition of the Opus Audio Codec. JM. Valin, K. Vos, T. Terriberry. September 2012. (Format: TXT, HTML) (Updated by RFC8251) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6716) 6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012. H. Hotz, R. Allbery. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6717) 6718 Pseudowire Redundancy. P. Muley, M. Aissaoui, M. Bocci. August 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6718) 6719 The Minimum Rank with Hysteresis Objective Function. O. Gnawali, P. Levis. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6719) 6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP). C. Pignataro, R. Asati. August 2012. (Format: TXT, HTML) (Updates RFC5036) (Updated by RFC7552) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6720) 6721 The Atom "deleted-entry" Element. J. Snell. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6721) 6722 Publishing the "Tao of the IETF" as a Web Page. P. Hoffman, Ed.. August 2012. (Format: TXT, HTML) (Obsoletes RFC4677) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6722) 6723 Update of the Pseudowire Control-Word Negotiation Mechanism. L. Jin, Ed., R. Key, Ed., S. Delord, T. Nadeau, S. Boutros. September 2012. (Format: TXT, HTML) (Obsoleted by RFC8077) (Updates RFC4447, RFC6073) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6723) 6724 Default Address Selection for Internet Protocol Version 6 (IPv6). D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown. September 2012. (Format: TXT, HTML) (Obsoletes RFC3484) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6724) 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates. S. Rose. August 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6725) 6726 FLUTE - File Delivery over Unidirectional Transport. T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen. November 2012. (Format: TXT, HTML) (Obsoletes RFC3926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6726) 6727 Definitions of Managed Objects for Packet Sampling. T. Dietz, Ed., B. Claise, J. Quittek. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6727) 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols. G. Muenz, B. Claise, P. Aitken. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6728) 6729 Indicating Email Handling States in Trace Fields. D. Crocker, M. Kucherawy. September 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6729) 6730 Requirements for IETF Nominations Committee Tools. S. Krishnan, J. Halpern. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6730) 6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes. T. Savolainen, J. Kato, T. Lemon. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6731) 6732 6to4 Provider Managed Tunnels. V. Kuarsingh, Ed., Y. Lee, O. Vautrin. September 2012. (Format: TXT, HTML) (Obsoleted by RFC7526) (Status: HISTORIC) (DOI: 10.17487/RFC6732) 6733 Diameter Base Protocol. V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.. October 2012. (Format: TXT, HTML) (Obsoletes RFC3588, RFC5719) (Updated by RFC7075, RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6733) 6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport. G. Zorn, Q. Wu, V. Cakulev. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6734) 6735 Diameter Priority Attribute-Value Pairs. K. Carlberg, Ed., T. Taylor. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6735) 6736 Diameter Network Address and Port Translation Control Application. F. Brockners, S. Bhandari, V. Singh, V. Fajardo. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6736) 6737 The Diameter Capabilities Update Application. K. Jiao, G. Zorn. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6737) 6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers. V. Cakulev, A. Lior, S. Mizikovsky. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6738) 6739 Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol. H. Schulzrinne, H. Tschofenig. October 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6739) 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6740) 6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations. RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6741) 6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti, S. Rose. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6742) 6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6743) 6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6744) 6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6745) 6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6746) 6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6747) 6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP). RJ Atkinson, SN Bhatti. November 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6748) 6749 The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. October 2012. (Format: TXT, HTML) (Obsoletes RFC5849) (Updated by RFC8252) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6749) 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage. M. Jones, D. Hardt. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6750) 6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44). R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang. October 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6751) 6752 Issues with Private IP Addressing in the Internet. A. Kirkham. September 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6752) 6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD). J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6753) 6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect. Y. Cai, L. Wei, H. Ou, V. Arya, S. Jethwani. October 2012. (Format: TXT, HTML) (Updated by RFC8736) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6754) 6755 An IETF URN Sub-Namespace for OAuth. B. Campbell, H. Tschofenig. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6755) 6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines. S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed.. September 2012. (Format: TXT, HTML) (Obsoletes RFC3356) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6756) 6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6. S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. October 2012. (Format: TXT, HTML) (Updated by RFC7563) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6757) 6758 Tunneling of SMTP Message Transfer Priorities. A. Melnikov, K. Carlberg. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6758) 6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX). B. Claise, P. Aitken, N. Ben-Dvora. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6759) 6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP). S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6760) 6761 Special-Use Domain Names. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Updates RFC1918, RFC2606) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6761) 6762 Multicast DNS. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6762) 6763 DNS-Based Service Discovery. S. Cheshire, M. Krochmal. February 2013. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6763) 6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV). C. Daboo. February 2013. (Format: TXT, HTML) (Updates RFC4791, RFC6352) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6764) 6765 xDSL Multi-Pair Bonding (G.Bond) MIB. E. Beili, M. Morgenstern. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6765) 6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB. E. Beili. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6766) 6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB. E. Beili, M. Morgenstern. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6767) 6768 ATM-Based xDSL Bonded Interfaces MIB. E. Beili. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6768) 6769 Simple Virtual Aggregation (S-VA). R. Raszuk, J. Heitz, A. Lo, L. Zhang, X. Xu. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6769) 6770 Use Cases for Content Delivery Network Interconnection. G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson. November 2012. (Format: TXT, HTML) (Obsoletes RFC3570) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6770) 6771 Considerations for Having a Successful "Bar BOF" Side Meeting. L. Eggert, G. Camarillo. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6771) 6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information. H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6772) 6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal. T. Phelan, G. Fairhurst, C. Perkins. November 2012. (Format: TXT, HTML) (Updates RFC4340, RFC5762) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6773) 6774 Distribution of Diverse BGP Paths. R. Raszuk, Ed., R. Fernando, K. Patel, D. McPherson, K. Kumaki. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6774) 6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann. November 2012. (Format: TXT, HTML) (Updates RFC4944) (Updated by RFC8505, RFC8929) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6775) 6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block. A. Clark, Q. Wu. October 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6776) 6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks. W. Sun, Ed., G. Zhang, Ed., J. Gao, G. Xie, R. Papneja. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6777) 6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching. R. Sparks. October 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6778) 6779 Definition of Managed Objects for the Neighborhood Discovery Protocol. U. Herberg, R. Cole, I. Chakeres. October 2012. (Format: TXT, HTML) (Obsoleted by RFC7939) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6779) 6780 RSVP ASSOCIATION Object Extensions. L. Berger, F. Le Faucheur, A. Narayanan. October 2012. (Format: TXT, HTML) (Updates RFC2205, RFC3209, RFC3473, RFC4872) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6780) 6781 DNSSEC Operational Practices, Version 2. O. Kolkman, W. Mekking, R. Gieben. December 2012. (Format: TXT, HTML) (Obsoletes RFC4641) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6781) 6782 Wireline Incremental IPv6. V. Kuarsingh, Ed., L. Howard. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6782) 6783 Mailing Lists and Non-ASCII Addresses. J. Levine, R. Gellens. November 2012. (Format: TXT, HTML) (Obsoletes RFC5983) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6783) 6784 Kerberos Options for DHCPv6. S. Sakane, M. Ishiyama. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6784) 6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve. B. Leiba. November 2012. (Format: TXT, HTML) (Updates RFC5228) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6785) 6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs. A. Yegin, R. Cragie. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6786) 6787 Media Resource Control Protocol Version 2 (MRCPv2). D. Burnett, S. Shanmugham. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6787) 6788 The Line-Identification Option. S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6788) 6789 Congestion Exposure (ConEx) Concepts and Use Cases. B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed.. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6789) 6790 The Use of Entropy Labels in MPLS Forwarding. K. Kompella, J. Drake, S. Amante, W. Henderickx, L. Yong. November 2012. (Format: TXT, HTML) (Updates RFC3031, RFC3107, RFC3209, RFC5036) (Updated by RFC7274, RFC7447, RFC8012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6790) 6791 Stateless Source Address Mapping for ICMPv6 Packets. X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston. November 2012. (Format: TXT, HTML) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6791) 6792 Guidelines for Use of the RTP Monitoring Framework. Q. Wu, Ed., G. Hunt, P. Arden. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6792) 6793 BGP Support for Four-Octet Autonomous System (AS) Number Space. Q. Vohra, E. Chen. December 2012. (Format: TXT, HTML) (Obsoletes RFC4893) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6793) 6794 A Framework for Session Initiation Protocol (SIP) Session Policies. V. Hilt, G. Camarillo, J. Rosenberg. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6794) 6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies. V. Hilt, G. Camarillo. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6795) 6796 A User Agent Profile Data Set for Media Policy. V. Hilt, G. Camarillo, J. Rosenberg, D. Worley. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6796) 6797 HTTP Strict Transport Security (HSTS). J. Hodges, C. Jackson, A. Barth. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6797) 6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting. A. Clark, Q. Wu. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6798) 6799 Not Issued. 6800 Not Issued. 6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework. U. Kozat, A. Begen. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6801) 6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets. S. Baillargeon, C. Flinta, A. Johnsson. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6802) 6803 Camellia Encryption for Kerberos 5. G. Hudson. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6803) 6804 DISCOVER: Supporting Multicast DNS Queries. B. Manning. November 2012. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC6804) 6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. D. King, Ed., A. Farrel, Ed.. November 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6805) 6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals. S. Hartman, Ed., K. Raeburn, L. Zhu. November 2012. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6806) 6807 Population Count Extensions to Protocol Independent Multicast (PIM). D. Farinacci, G. Shepherd, S. Venaas, Y. Cai. December 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6807) 6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track. L. Ciavattone, R. Geib, A. Morton, M. Wieser. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6808) 6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP). C. Holmberg, I. Sedlacek, H. Kaplan. November 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6809) 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, R. Austein. January 2013. (Format: TXT, HTML) (Updated by RFC8210) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6810) 6811 BGP Prefix Origin Validation. P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. January 2013. (Format: TXT, HTML) (Updated by RFC8481, RFC8893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6811) 6812 Cisco Service-Level Assurance Protocol. M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6812) 6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis. J. Salowey, S. Hanna. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6813) 6814 Formally Deprecating Some IPv4 Options. C. Pignataro, F. Gont. November 2012. (Format: TXT, HTML) (Obsoletes RFC1385, RFC1393, RFC1475, RFC1770) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6814) 6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful. S. Bradner, K. Dubray, J. McQuaid, A. Morton. November 2012. (Format: TXT, HTML) (Updates RFC2544) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6815) 6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME. V. Roca, M. Cunche, J. Lacan. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6816) 6817 Low Extra Delay Background Transport (LEDBAT). S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind. December 2012. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6817) 6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. P. Yee. January 2013. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6818) 6819 OAuth 2.0 Threat Model and Security Considerations. T. Lodderstedt, Ed., M. McGloin, P. Hunt. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6819) 6820 Address Resolution Problems in Large Data Center Networks. T. Narten, M. Karir, I. Foo. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6820) 6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality. E. Marocco, A. Fusco, I. Rimac, V. Gurbani. December 2012. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6821) 6822 IS-IS Multi-Instance. S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward. December 2012. (Format: TXT, HTML) (Obsoleted by RFC8202) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6822) 6823 Advertising Generic Information in IS-IS. L. Ginsberg, S. Previdi, M. Shand. December 2012. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6823) 6824 TCP Extensions for Multipath Operation with Multiple Addresses. A. Ford, C. Raiciu, M. Handley, O. Bonaventure. January 2013. (Format: TXT, HTML) (Obsoleted by RFC8684) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6824) 6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS. M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6825) 6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala. January 2013. (Format: TXT, HTML) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6826) 6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols. A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed.. January 2013. (Format: TXT, HTML) (Obsoletes RFC5787) (Updates RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6827) 6828 Content Splicing for RTP Sessions. J. Xia. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6828) 6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6. M. Chen, P. Pan, C. Pignataro, R. Asati. January 2013. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6829) 6830 The Locator/ID Separation Protocol (LISP). D. Farinacci, V. Fuller, D. Meyer, D. Lewis. January 2013. (Format: TXT, HTML) (Updated by RFC8113) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6830) 6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments. D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6831) 6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites. D. Lewis, D. Meyer, D. Farinacci, V. Fuller. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6832) 6833 Locator/ID Separation Protocol (LISP) Map-Server Interface. V. Fuller, D. Farinacci. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6833) 6834 Locator/ID Separation Protocol (LISP) Map-Versioning. L. Iannone, D. Saucez, O. Bonaventure. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6834) 6835 The Locator/ID Separation Protocol Internet Groper (LIG). D. Farinacci, D. Meyer. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6835) 6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT). V. Fuller, D. Farinacci, D. Meyer, D. Lewis. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6836) 6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database. E. Lear. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6837) 6838 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin, T. Hansen. January 2013. (Format: TXT, HTML) (Obsoletes RFC4288) (Also BCP0013) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6838) 6839 Additional Media Type Structured Syntax Suffixes. T. Hansen, A. Melnikov. January 2013. (Format: TXT, HTML) (Updates RFC3023) (Updated by RFC7303) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6839) 6840 Clarifications and Implementation Notes for DNS Security (DNSSEC). S. Weiler, Ed., D. Blacka, Ed.. February 2013. (Format: TXT, HTML) (Updates RFC4033, RFC4034, RFC4035, RFC5155) (Updated by RFC8749) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6840) 6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements. F. Ljunggren, AM. Eklund Lowinder, T. Okubo. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6841) 6842 Client Identifier Option in DHCP Server Replies. N. Swamy, G. Halwasia, P. Jhingran. January 2013. (Format: TXT, HTML) (Updates RFC2131) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6842) 6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting. A. Clark, K. Gross, Q. Wu. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6843) 6844 DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, R. Stradling. January 2013. (Format: TXT, HTML) (Obsoleted by RFC8659) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6844) 6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type. N. Sheth, L. Wang, J. Zhang. January 2013. (Format: TXT, HTML) (Updates RFC2328, RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6845) 6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP). G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. January 2013. (Format: TXT, HTML) (Obsoletes RFC4996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6846) 6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL). D. Melman, T. Mizrahi, D. Eastlake 3rd. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6847) 6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO). J. Winterbottom, M. Thomson, R. Barnes, B. Rosen, R. George. January 2013. (Format: TXT, HTML) (Updates RFC4776, RFC5222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6848) 6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback. H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6849) 6850 Definitions of Managed Objects for Routing Bridges (RBridges). A. Rijhsinghani, K. Zebrose. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6850) 6851 Internet Message Access Protocol (IMAP) - MOVE Extension. A. Gulbrandsen, N. Freed, Ed.. January 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6851) 6852 Affirmation of the Modern Paradigm for Standards. R. Housley, S. Mills, J. Jaffe, B. Aboba, L. St.Amour. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6852) 6853 DHCPv6 Redundancy Deployment Considerations. J. Brzozowski, J. Tremblay, J. Chen, T. Mrugalski. February 2013. (Format: TXT, HTML) (Also BCP0180) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6853) 6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields. B. Leiba. March 2013. (Format: TXT, HTML) (Updates RFC5322) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6854) 6855 IMAP Support for UTF-8. P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.. March 2013. (Format: TXT, HTML) (Obsoletes RFC5738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6855) 6856 Post Office Protocol Version 3 (POP3) Support for UTF-8. R. Gellens, C. Newman, J. Yao, K. Fujiwara. March 2013. (Format: TXT, HTML) (Obsoletes RFC5721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6856) 6857 Post-Delivery Message Downgrading for Internationalized Email Messages. K. Fujiwara. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6857) 6858 Simplified POP and IMAP Downgrading for Internationalized Email. A. Gulbrandsen. March 2013. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6858) 6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership. B. Leiba. January 2013. (Format: TXT, HTML) (Obsoleted by RFC7437) (Updates RFC3777) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6859) 6860 Hiding Transit-Only Networks in OSPF. Y. Yang, A. Retana, A. Roy. January 2013. (Format: TXT, HTML) (Updates RFC2328, RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6860) 6861 The "create-form" and "edit-form" Link Relations. I. Dzmanashvili. January 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6861) 6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements. G. Lebovitz, M. Bhatia, B. Weis. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6862) 6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide. S. Hartman, D. Zhang. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6863) 6864 Updated Specification of the IPv4 ID Field. J. Touch. February 2013. (Format: TXT, HTML) (Updates RFC0791, RFC1122, RFC2003) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6864) 6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME. V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6865) 6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks. B. Carpenter, S. Jiang. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6866) 6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP). Y. Nir, Q. Wu. January 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6867) 6868 Parameter Value Encoding in iCalendar and vCard. C. Daboo. February 2013. (Format: TXT, HTML) (Updates RFC5545, RFC6321, RFC6350, RFC6351) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6868) 6869 vCard KIND:device. G. Salgueiro, J. Clarke, P. Saint-Andre. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6869) 6870 Pseudowire Preferential Forwarding Status Bit. P. Muley, Ed., M. Aissaoui, Ed.. February 2013. (Format: TXT, HTML) (Updates RFC4447) (Updated by RFC7771) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6870) 6871 Session Description Protocol (SDP) Media Capabilities Negotiation. R. Gilman, R. Even, F. Andreasen. February 2013. (Format: TXT, HTML) (Updates RFC5939) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6871) 6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model. V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6872) 6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF). G. Salgueiro, V. Gurbani, A. B. Roach. February 2013. (Format: TXT, HTML) (Updated by RFC7355) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6873) 6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. B. Carpenter, S. Cheshire, R. Hinden. February 2013. (Format: TXT, HTML) (Updates RFC3986) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6874) 6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan. S. Kamei, T. Momose, T. Inoue, T. Nishitani. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6875) 6876 A Posture Transport Protocol over TLS (PT-TLS). P. Sangster, N. Cam-Winget, J. Salowey. February 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6876) 6877 464XLAT: Combination of Stateful and Stateless Translation. M. Mawatari, M. Kawashima, C. Byrne. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6877) 6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field. A.B. Roach. March 2013. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6878) 6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods. S. Jiang, B. Liu, B. Carpenter. February 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6879) 6880 An Information Model for Kerberos Version 5. L. Johansson. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6880) 6881 Best Current Practice for Communications Services in Support of Emergency Calling. B. Rosen, J. Polk. March 2013. (Format: TXT, HTML) (Updated by RFC7840, RFC7852) (Also BCP0181) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6881) 6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs). K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang. March 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6882) 6883 IPv6 Guidance for Internet Content Providers and Application Service Providers. B. Carpenter, S. Jiang. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6883) 6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Z. Fang. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6884) 6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS). M. Blanchet, A. Sullivan. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6885) 6886 NAT Port Mapping Protocol (NAT-PMP). S. Cheshire, M. Krochmal. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6886) 6887 Port Control Protocol (PCP). D. Wing, Ed., S. Cheshire, M. Boucadair, R. Penno, P. Selkirk. April 2013. (Format: TXT, HTML) (Updated by RFC7488, RFC7652, RFC7843) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6887) 6888 Common Requirements for Carrier-Grade NATs (CGNs). S. Perreault, Ed., I. Yamagata, S. Miyakawa, A. Nakagawa, H. Ashida. April 2013. (Format: TXT, HTML) (Updates RFC4787) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6888) 6889 Analysis of Stateful 64 Translation. R. Penno, T. Saxena, M. Boucadair, S. Sivakumar. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6889) 6890 Special-Purpose IP Address Registries. M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman. April 2013. (Format: TXT, HTML) (Obsoletes RFC4773, RFC5156, RFC5735, RFC5736) (Updated by RFC8190) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6890) 6891 Extension Mechanisms for DNS (EDNS(0)). J. Damas, M. Graff, P. Vixie. April 2013. (Format: TXT, HTML) (Obsoletes RFC2671, RFC2673) (Also STD0075) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC6891) 6892 The 'describes' Link Relation Type. E. Wilde. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6892) 6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF). P. Higgs, P. Szucs. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6893) 6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection. R. Papneja, S. Vapiwala, J. Karthik, S. Poretsky, S. Rao, JL. Le Roux. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6894) 6895 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. April 2013. (Format: TXT, HTML) (Obsoletes RFC6195) (Updates RFC1183, RFC2845, RFC2930, RFC3597) (Also BCP0042) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6895) 6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP. S. Barbato, S. Dorigotti, T. Fossati, Ed.. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6896) 6897 Multipath TCP (MPTCP) Application Interface Considerations. M. Scharf, A. Ford. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6897) 6898 Link Management Protocol Behavior Negotiation and Configuration Modifications. D. Li, D. Ceccarelli, L. Berger. March 2013. (Format: TXT, HTML) (Updates RFC4204, RFC4207, RFC4209, RFC5818) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6898) 6899 Not Issued. 6900 Not Issued. 6901 JavaScript Object Notation (JSON) Pointer. P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6901) 6902 JavaScript Object Notation (JSON) Patch. P. Bryan, Ed., M. Nottingham, Ed.. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6902) 6903 Additional Link Relation Types. J. Snell. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6903) 6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP). J. Lennox. April 2013. (Format: TXT, HTML) (Updates RFC3711) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6904) 6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL). T. Senevirathne, D. Bond, S. Aldrin, Y. Li, R. Watve. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6905) 6906 The 'profile' Link Relation Type. E. Wilde. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6906) 6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties. T. Manderson, K. Sriram, R. White. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6907) 6908 Deployment Considerations for Dual-Stack Lite. Y. Lee, R. Maglione, C. Williams, C. Jacquenet, M. Boucadair. March 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6908) 6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6. S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6909) 6910 Completion of Calls for the Session Initiation Protocol (SIP). D. Worley, M. Huelsemann, R. Jesske, D. Alexeitsev. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6910) 6911 RADIUS Attributes for IPv6 Access Networks. W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6911) 6912 Principles for Unicode Code Point Inclusion in Labels in the DNS. A. Sullivan, D. Thaler, J. Klensin, O. Kolkman. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6912) 6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP). D. Hanes, G. Salgueiro, K. Fleming. March 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6913) 6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP). J. Rosenberg. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6914) 6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD). R. Bellis. April 2013. (Format: TXT, HTML) (Updates RFC6155) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6915) 6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI). R. Gagliano, S. Kent, S. Turner. April 2013. (Format: TXT, HTML) (Also BCP0182) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6916) 6917 Media Resource Brokering. C. Boulton, L. Miniero, G. Munson. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6917) 6918 Formally Deprecating Some ICMPv4 Message Types. F. Gont, C. Pignataro. April 2013. (Format: TXT, HTML) (Obsoletes RFC1788) (Updates RFC0792, RFC0950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6918) 6919 Further Key Words for Use in RFCs to Indicate Requirement Levels. R. Barnes, S. Kent, E. Rescorla. 1 April 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6919) 6920 Naming Things with Hashes. S. Farrell, D. Kutscher, C. Dannewitz, B. Ohlman, A. Keranen, P. Hallam-Baker. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6920) 6921 Design Considerations for Faster-Than-Light (FTL) Communication. R. Hinden. 1 April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6921) 6922 The application/sql Media Type. Y. Shafranovich. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6922) 6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions. R. Winter, E. Gray, H. van Helvoort, M. Betts. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6923) 6924 Registration of Second-Level URN Namespaces under "ietf". B. Leiba. April 2013. (Format: TXT, HTML) (Updates RFC2648) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6924) 6925 The DHCPv4 Relay Agent Identifier Sub-Option. B. Joshi, R. Desetti, M. Stapp. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6925) 6926 DHCPv4 Bulk Leasequery. K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz. April 2013. (Format: TXT, HTML) (Updated by RFC7724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6926) 6927 Variants in Second-Level Names Registered in Top-Level Domains. J. Levine, P. Hoffman. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6927) 6928 Increasing TCP's Initial Window. J. Chu, N. Dukkipati, Y. Cheng, M. Mathis. April 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6928) 6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions. A. DeKok, A. Lior. April 2013. (Format: TXT, HTML) (Updates RFC2865, RFC3575, RFC6158) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6929) 6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). D. Guo, S. Jiang, Ed., R. Despres, R. Maglione. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6930) 6931 Additional XML Security Uniform Resource Identifiers (URIs). D. Eastlake 3rd. April 2013. (Format: TXT, HTML) (Obsoletes RFC4051) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6931) 6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry. D. Harkins, Ed.. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6932) 6933 Entity MIB (Version 4). A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli. May 2013. (Format: TXT, HTML) (Obsoletes RFC4133) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6933) 6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs). N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li. June 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6934) 6935 IPv6 and UDP Checksums for Tunneled Packets. M. Eubanks, P. Chimento, M. Westerlund. April 2013. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6935) 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6936) 6937 Proportional Rate Reduction for TCP. M. Mathis, N. Dukkipati, Y. Cheng. May 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6937) 6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID. J. Scudder. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6938) 6939 Client Link-Layer Address Option in DHCPv6. G. Halwasia, S. Bhandari, W. Dec. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6939) 6940 REsource LOcation And Discovery (RELOAD) Base Protocol. C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6940) 6941 MPLS Transport Profile (MPLS-TP) Security Framework. L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed.. April 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6941) 6942 Diameter Support for the EAP Re-authentication Protocol (ERP). J. Bournelle, L. Morand, S. Decugis, Q. Wu, G. Zorn. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6942) 6943 Issues in Identifier Comparison for Security Purposes. D. Thaler, Ed.. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6943) 6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status. S. Rose. April 2013. (Format: TXT, HTML) (Obsoleted by RFC8624) (Updates RFC2536, RFC2539, RFC3110, RFC4034, RFC4398, RFC5155, RFC5702, RFC5933) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6944) 6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol. R. Bush, B. Wijnen, K. Patel, M. Baer. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6945) 6946 Processing of IPv6 "Atomic" Fragments. F. Gont. May 2013. (Format: TXT, HTML) (Updates RFC2460, RFC5722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6946) 6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute. M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6947) 6948 Some Measurements on World IPv6 Day from an End-User Perspective. A. Keranen, J. Arkko. July 2013. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6948) 6949 RFC Series Format Requirements and Future Development. H. Flanagan, N. Brownlee. May 2013. (Format: TXT, HTML) (Updates RFC2223) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6949) 6950 Architectural Considerations on Application Features in the DNS. J. Peterson, O. Kolkman, H. Tschofenig, B. Aboba. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6950) 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. M. Tuexen, R. Stewart. May 2013. (Format: TXT, HTML) (Updated by RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6951) 6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide. M. Jethanandani, K. Patel, L. Zheng. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6952) 6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements. A. Mancuso, Ed., S. Probasco, B. Patil. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6953) 6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2). J. Merkle, M. Lochter. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6954) 6955 Diffie-Hellman Proof-of-Possession Algorithms. J. Schaad, H. Prafullchandra. May 2013. (Format: TXT, HTML) (Obsoletes RFC2875) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6955) 6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library. W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern. June 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6956) 6957 Duplicate Address Detection Proxy. F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li. June 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6957) 6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting. A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed.. May 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6958) 6959 Source Address Validation Improvement (SAVI) Threat Scope. D. McPherson, F. Baker, J. Halpern. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6959) 6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. June 2013. (Format: TXT, HTML) (Obsoletes RFC2560, RFC6277) (Updates RFC5912) (Updated by RFC8954) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6960) 6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension. Y. Pettersen. June 2013. (Format: TXT, HTML) (Obsoleted by RFC8446) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6961) 6962 Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6962) 6963 A Uniform Resource Name (URN) Namespace for Examples. P. Saint-Andre. May 2013. (Format: TXT, HTML) (Also BCP0183) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6963) 6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F. Templin. May 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6964) 6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design. L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6965) 6966 Not Issued. 6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments. M. Boucadair, J. Touch, P. Levis, R. Penno. June 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6967) 6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols. V. Roca, B. Adamson. July 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6968) 6969 OSPFv3 Instance ID Registry Update. A. Retana, D. Cheng. July 2013. (Format: TXT, HTML) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6969) 6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). M. Boucadair, R. Penno, D. Wing. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6970) 6971 Depth-First Forwarding (DFF) in Unreliable Networks. U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes. June 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6971) 6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP). Y. Zhang, N. Zong. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6972) 6973 Privacy Considerations for Internet Protocols. A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6973) 6974 Applicability of MPLS Transport Profile for Ring Topologies. Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6974) 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC). S. Crocker, S. Rose. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6975) 6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach. M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O. Bonaventure. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6976) 6977 Triggering DHCPv6 Reconfiguration from Relay Agents. M. Boucadair, X. Pougnard. July 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6977) 6978 A TCP Authentication Option Extension for NAT Traversal. J. Touch. July 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6978) 6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA). T. Pornin. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6979) 6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. F. Gont. August 2013. (Format: TXT, HTML) (Updates RFC3971, RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6980) 6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses. S. Bryant, S. Previdi, M. Shand. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6981) 6982 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2013. (Format: TXT, HTML) (Obsoleted by RFC7942) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6982) 6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI). R. van Brandenburg, O. van Deventer, F. Le Faucheur, K. Leung. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6983) 6984 Interoperability Report for Forwarding and Control Element Separation (ForCES). W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim. August 2013. (Format: TXT, HTML) (Updates RFC6053) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6984) 6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing. A. Morton. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6985) 6986 GOST R 34.11-2012: Hash Function. V. Dolmatov, Ed., A. Degtyarev. August 2013. (Format: TXT, HTML) (Updates RFC5831) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6986) 6987 OSPF Stub Router Advertisement. A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson. September 2013. (Format: TXT, HTML) (Obsoletes RFC3137) (Updated by RFC8770) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6987) 6988 Requirements for Energy Management. J. Quittek, Ed., M. Chandramouli, R. Winter, T. Dietz, B. Claise. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6988) 6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Sheffer, S. Fluhrer. July 2013. (Format: TXT, HTML) (Updates RFC5996) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6989) 6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting. R. Huang, Q. Wu, H. Asaeda, G. Zorn. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6990) 6991 Common YANG Data Types. J. Schoenwaelder, Ed.. July 2013. (Format: TXT, HTML) (Obsoletes RFC6021) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6991) 6992 Routing for IPv4-Embedded IPv6 Packets. D. Cheng, M. Boucadair, A. Retana. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6992) 6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP). P. Saint-Andre. July 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6993) 6994 Shared Use of Experimental TCP Options. J. Touch. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC6994) 6995 Not Issued. 6996 Autonomous System (AS) Reservation for Private Use. J. Mitchell. July 2013. (Format: TXT, HTML) (Updates RFC1930) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC6996) 6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks. M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci. August 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6997) 6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network. M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci. August 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC6998) 6999 Not Issued. 7000 Not Issued. 7001 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. September 2013. (Format: TXT, HTML) (Obsoletes RFC5451, RFC6577) (Obsoleted by RFC7601) (Updated by RFC7410) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7001) 7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting. A. Clark, G. Zorn, Q. Wu. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7002) 7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting. A. Clark, R. Huang, Q. Wu, Ed.. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7003) 7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting. G. Zorn, R. Schott, Q. Wu, Ed., R. Huang. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7004) 7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting. A. Clark, V. Singh, Q. Wu. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7005) 7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP). M. Garcia-Martin, S. Veikkolainen, R. Gilman. September 2013. (Format: TXT, PDF, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7006) 7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP). T. Terriberry. August 2013. (Format: TXT, HTML) (Updates RFC3551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7007) 7008 A Description of the KCipher-2 Encryption Algorithm. S. Kiyomoto, W. Shin. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7008) 7009 OAuth 2.0 Token Revocation. T. Lodderstedt, Ed., S. Dronia, M. Scurtescu. August 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7009) 7010 IPv6 Site Renumbering Gap Analysis. B. Liu, S. Jiang, B. Carpenter, S. Venaas, W. George. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7010) 7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information. B. Claise, Ed., B. Trammell, Ed., P. Aitken. September 2013. (Format: TXT, HTML) (Obsoletes RFC5101) (Also STD0077) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7011) 7012 Information Model for IP Flow Information Export (IPFIX). B. Claise, Ed., B. Trammell, Ed.. September 2013. (Format: TXT, HTML) (Obsoletes RFC5102) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7012) 7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements. B. Trammell, B. Claise. September 2013. (Format: TXT, HTML) (Also BCP0184) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7013) 7014 Flow Selection Techniques. S. D'Antonio, T. Zseby, C. Henke, L. Peluso. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7014) 7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol. B. Trammell, A. Wagner, B. Claise. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7015) 7016 Adobe's Secure Real-Time Media Flow Protocol. M. Thornburgh. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7016) 7017 IMAP Access to IETF Email List Archives. R. Sparks. August 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7017) 7018 Auto-Discovery VPN Problem Statement and Requirements. V. Manral, S. Hanna. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7018) 7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD). J. Buford, M. Kolberg, Ed.. September 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7019) 7020 The Internet Numbers Registry System. R. Housley, J. Curran, G. Huston, D. Conrad. August 2013. (Format: TXT, HTML) (Obsoletes RFC2050) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7020) 7021 Assessing the Impact of Carrier-Grade NAT on Network Applications. C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7021) 7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs). A. Begen, C. Perkins, D. Wing, E. Rescorla. September 2013. (Format: TXT, HTML) (Obsoletes RFC6222) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7022) 7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking. D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7023) 7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs. H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7024) 7025 Requirements for GMPLS Applications of PCE. T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7025) 7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel. A. Farrel, S. Bryant. September 2013. (Format: TXT, HTML) (Updates RFC5586) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7026) 7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS). J. Merkle, M. Lochter. October 2013. (Format: TXT, HTML) (Updates RFC4492) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7027) 7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6. JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim. September 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7028) 7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding. S. Hartman, M. Wasserman, D. Zhang. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7029) 7030 Enrollment over Secure Transport. M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed.. October 2013. (Format: TXT, HTML) (Updated by RFC8951) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7030) 7031 DHCPv6 Failover Requirements. T. Mrugalski, K. Kinnear. September 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7031) 7032 LDP Downstream-on-Demand in Seamless MPLS. T. Beckhaus, Ed., B. Decraene, K. Tiruveedhula, M. Konstantynowicz, Ed., L. Martini. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7032) 7033 WebFinger. P. Jones, G. Salgueiro, M. Jones, J. Smarr. September 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7033) 7034 HTTP Header Field X-Frame-Options. D. Ross, T. Gondrom. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7034) 7035 Relative Location Representation. M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7035) 7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group. R. Housley. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7036) 7037 RADIUS Option for the DHCPv6 Relay Agent. L. Yeh, M. Boucadair. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7037) 7038 Use of OSPF-MDR in Single-Hop Broadcast Networks. R. Ogier. October 2013. (Format: TXT, HTML) (Updates RFC5614) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7038) 7039 Source Address Validation Improvement (SAVI) Framework. J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7039) 7040 Public IPv4-over-IPv6 Access Network. Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7040) 7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging. F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed.. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7041) 7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters. D. Eastlake 3rd, J. Abley. October 2013. (Format: TXT, HTML) (Obsoletes RFC5342) (Updates RFC2153) (Also BCP0141) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7042) 7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS. J. Abley. October 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7043) 7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information. M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg. February 2014. (Format: TXT, HTML) (Obsoletes RFC4244) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7044) 7045 Transmission and Processing of IPv6 Extension Headers. B. Carpenter, S. Jiang. December 2013. (Format: TXT, HTML) (Updates RFC2460, RFC2780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7045) 7046 A Common API for Transparent Hybrid Multicast. M. Waehlisch, T. Schmidt, S. Venaas. December 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7046) 7047 The Open vSwitch Database Management Protocol. B. Pfaff, B. Davie, Ed.. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7047) 7048 Neighbor Unreachability Detection Is Too Impatient. E. Nordmark, I. Gashinsky. January 2014. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7048) 7049 Concise Binary Object Representation (CBOR). C. Bormann, P. Hoffman. October 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7049) 7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis. T. Savolainen, J. Korhonen, D. Wing. November 2013. (Format: TXT, HTML) (Updated by RFC8880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7050) 7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix. J. Korhonen, Ed., T. Savolainen, Ed.. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7051) 7052 Locator/ID Separation Protocol (LISP) MIB. G. Schudel, A. Jain, V. Moreno. October 2013. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7052) 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol. M. Tuexen, I. Ruengeler, R. Stewart. November 2013. (Format: TXT, HTML) (Updates RFC4960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7053) 7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs). A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7054) 7055 A GSS-API Mechanism for the Extensible Authentication Protocol. S. Hartman, Ed., J. Howlett. December 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7055) 7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism. S. Hartman, J. Howlett. December 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7056) 7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB). S. Winter, J. Salowey. December 2013. (Format: TXT, HTML) (Updates RFC3748) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7057) 7058 Media Control Channel Framework (CFW) Call Flow Examples. A. Amirante, T. Castaldi, L. Miniero, S P. Romano. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7058) 7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms. S. Steffann, I. van Beijnum, R. van Rein. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7059) 7060 Using LDP Multipoint Extensions on Targeted LDP Sessions. M. Napierala, E. Rosen, IJ. Wijnands. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7060) 7061 eXtensible Access Control Markup Language (XACML) XML Media Type. R. Sinnema, E. Wilde. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7061) 7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks. F. Zhang, Ed., D. Li, H. Li, S. Belotti, D. Ceccarelli. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7062) 7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments. L. Zheng, J. Zhang, R. Parekh. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7063) 7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol. S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7064) 7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers. M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7065) 7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts. J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan. November 2013. (Format: TXT, HTML) (Obsoletes RFC3316) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7066) 7067 Directory Assistance Problem and High-Level Design Proposal. L. Dunbar, D. Eastlake 3rd, R. Perlman, I. Gashinsky. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7067) 7068 Diameter Overload Control Requirements. E. McMurry, B. Campbell. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7068) 7069 DECoupled Application Data Enroute (DECADE). R. Alimi, A. Rahman, D. Kutscher, Y. Yang, H. Song, K. Pentikousis. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7069) 7070 An Architecture for Reputation Reporting. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7070) 7071 A Media Type for Reputation Interchange. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7071) 7072 A Reputation Query Protocol. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7072) 7073 A Reputation Response Set for Email Identifiers. N. Borenstein, M. Kucherawy. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7073) 7074 Revised Definition of the GMPLS Switching Capability and Type Fields. L. Berger, J. Meuric. November 2013. (Format: TXT, HTML) (Updates RFC3471, RFC4202, RFC4203, RFC5307) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7074) 7075 Realm-Based Redirection In Diameter. T. Tsou, R. Hao, T. Taylor, Ed.. November 2013. (Format: TXT, HTML) (Updates RFC6733) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7075) 7076 P6R's Secure Shell Public Key Subsystem. M. Joseph, J. Susoy. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7076) 7077 Update Notifications for Proxy Mobile IPv6. S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota, J. Korhonen. November 2013. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7077) 7078 Distributing Address Selection Policy Using DHCPv6. A. Matsumoto, T. Fujisaki, T. Chown. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7078) 7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results. N. Del Regno, Ed., A. Malis, Ed.. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7079) 7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges. A. Sajassi, S. Salam, N. Bitar, F. Balus. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7080) 7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). E. Ivov, P. Saint-Andre, E. Marocco. November 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7081) 7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP). R. Shekh-Yusef, M. Barnes. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7082) 7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT. R. Droms. November 2013. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7083) 7084 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark. November 2013. (Format: TXT, HTML) (Obsoletes RFC6204) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7084) 7085 Top-Level Domains That Are Already Dotless. J. Levine, P. Hoffman. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7085) 7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD). A. Keranen, G. Camarillo, J. Maenpaa. January 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7086) 7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations. H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed.. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7087) 7088 Session Initiation Protocol Service Example -- Music on Hold. D. Worley. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7088) 7089 HTTP Framework for Time-Based Access to Resource States -- Memento. H. Van de Sompel, M. Nelson, R. Sanderson. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7089) 7090 Public Safety Answering Point (PSAP) Callback. H. Schulzrinne, H. Tschofenig, C. Holmberg, M. Patel. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7090) 7091 GOST R 34.10-2012: Digital Signature Algorithm. V. Dolmatov, Ed., A. Degtyarev. December 2013. (Format: TXT, HTML) (Updates RFC5832) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7091) 7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents. H. Kaplan, V. Pascual. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7092) 7093 Additional Methods for Generating Key Identifiers Values. S. Turner, S. Kent, J. Manger. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7093) 7094 Architectural Considerations of IP Anycast. D. McPherson, D. Oran, D. Thaler, E. Osterweil. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7094) 7095 jCard: The JSON Format for vCard. P. Kewisch. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7095) 7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs). S. Belotti, Ed., P. Grandi, D. Ceccarelli, Ed., D. Caviglia, F. Zhang, D. Li. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7096) 7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets. J. Ott, V. Singh, Ed., I. Curcio. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7097) 7098 Using the IPv6 Flow Label for Load Balancing in Server Farms. B. Carpenter, S. Jiang, W. Tarreau. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7098) 7099 Not Issued. 7100 Retirement of the "Internet Official Protocol Standards" Summary Document. P. Resnick. December 2013. (Format: TXT, HTML) (Obsoletes RFC5000) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7100) 7101 List of Internet Official Protocol Standards: Replaced by a Web Page. S. Ginoza. December 2013. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7101) 7102 Terms Used in Routing for Low-Power and Lossy Networks. JP. Vasseur. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7102) 7103 Advice for Safe Handling of Malformed Messages. M. Kucherawy, G. Shapiro, N. Freed. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7103) 7104 Duplication Grouping Semantics in the Session Description Protocol. A. Begen, Y. Cai, H. Ou. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7104) 7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols. M. Thomson, J. Winterbottom. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7105) 7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State. E. Ivov. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7106) 7107 Object Identifier Registry for the S/MIME Mail Security Working Group. R. Housley. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7107) 7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes. J. Abley, T. Manderson. January 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7108) 7109 Flow Bindings Initiated by Home Agents for Mobile IPv6. H. Yokota, D. Kim, B. Sarikaya, F. Xia. February 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7109) 7110 Return Path Specified Label Switched Path (LSP) Ping. M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord. January 2014. (Format: TXT, HTML) (Updated by RFC7737) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7110) 7111 URI Fragment Identifiers for the text/csv Media Type. M. Hausenblas, E. Wilde, J. Tennison. January 2014. (Format: TXT, HTML) (Updates RFC4180) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7111) 7112 Implications of Oversized IPv6 Header Chains. F. Gont, V. Manral, R. Bonica. January 2014. (Format: TXT, HTML) (Updates RFC2460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7112) 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard). F. Gont. February 2014. (Format: TXT, HTML) (Updates RFC6105) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7113) 7114 Creation of a Registry for smime-type Parameter Values. B. Leiba. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7114) 7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI). R. Bush. January 2014. (Format: TXT, HTML) (Also BCP0185) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7115) 7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries. K. Scott, M. Blanchet. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7116) 7117 Multicast in Virtual Private LAN Service (VPLS). R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya. February 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7117) 7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP). I. Baz Castillo, J. Millan Villegas, V. Pascual. January 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7118) 7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators. B. Claise, A. Kobayashi, B. Trammell. February 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7119) 7120 Early IANA Allocation of Standards Track Code Points. M. Cotton. January 2014. (Format: TXT, HTML) (Obsoletes RFC4020) (Also BCP0100) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7120) 7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element. K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim. February 2014. (Format: TXT, HTML) (Updates RFC5810) (Updated by RFC7391) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7121) 7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP). H. Kruse, S. Jero, S. Ostermann. March 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7122) 7123 Security Implications of IPv6 on IPv4 Networks. F. Gont, W. Liu. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7123) 7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB. E. Beili. February 2014. (Format: TXT, HTML) (Updates RFC5066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7124) 7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element. B. Trammell, P. Aitken. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7125) 7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options. F. Gont, R. Atkinson, C. Pignataro. February 2014. (Format: TXT, HTML) (Also BCP0186) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7126) 7127 Characterization of Proposed Standards. O. Kolkman, S. Bradner, S. Turner. January 2014. (Format: TXT, HTML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7127) 7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report. R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7128) 7129 Authenticated Denial of Existence in the DNS. R. Gieben, W. Mekking. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7129) 7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces. M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed.. February 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7130) 7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples. M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7131) 7132 Threat Model for BGP Path Security. S. Kent, A. Chi. February 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7132) 7133 Information Elements for Data Link Layer Traffic Measurement. S. Kashima, A. Kobayashi, Ed., P. Aitken. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7133) 7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review". B. Rosen. March 2014. (Format: TXT, HTML) (Updates RFC4412) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7134) 7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications. J. Polk. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7135) 7136 Significance of IPv6 Interface Identifiers. B. Carpenter, S. Jiang. February 2014. (Format: TXT, HTML) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7136) 7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks. A. Retana, S. Ratliff. February 2014. (Format: TXT, HTML) (Updates RFC5820) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7137) 7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks. D. Ceccarelli, Ed., F. Zhang, S. Belotti, R. Rao, J. Drake. March 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7138) 7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks. F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan. March 2014. (Format: TXT, HTML) (Updates RFC4328) (Updated by RFC7892) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7139) 7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path. L. Jin, F. Jounay, IJ. Wijnands, N. Leymann. March 2014. (Format: TXT, HTML) (Updated by RFC7358) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7140) 7141 Byte and Packet Congestion Notification. B. Briscoe, J. Manner. February 2014. (Format: TXT, HTML) (Updates RFC2309, RFC2914) (Also BCP0041) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7141) 7142 Reclassification of RFC 1142 to Historic. M. Shand, L. Ginsberg. February 2014. (Format: TXT, HTML) (Obsoletes RFC1142) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7142) 7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated). M. Chadalapaka, J. Satran, K. Meth, D. Black. April 2014. (Format: TXT, HTML) (Obsoletes RFC3720, RFC3980, RFC4850, RFC5048) (Updates RFC3721) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7143) 7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update. F. Knight, M. Chadalapaka. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7144) 7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification. M. Ko, A. Nezhinsky. April 2014. (Format: TXT, HTML) (Obsoletes RFC5046) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7145) 7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3. D. Black, P. Koning. April 2014. (Format: TXT, HTML) (Updates RFC3720, RFC3723, RFC3821, RFC3822, RFC4018, RFC4172, RFC4173, RFC4174, RFC5040, RFC5041, RFC5042, RFC5043, RFC5044, RFC5045, RFC5046, RFC5047, RFC5048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7146) 7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI). M. Bakke, P. Venkatesen. April 2014. (Format: TXT, HTML) (Obsoletes RFC4544) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7147) 7148 Prefix Delegation Support for Proxy Mobile IPv6. X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos. March 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7148) 7149 Software-Defined Networking: A Perspective from within a Service Provider Environment. M. Boucadair, C. Jacquenet. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7149) 7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol. F. Zhang, A. Farrel. March 2014. (Format: TXT, HTML) (Obsoleted by RFC7470) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7150) 7151 File Transfer Protocol HOST Command for Virtual Hosts. P. Hethmon, R. McMurray. March 2014. (Format: TXT, HTML) (Updates RFC0959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7151) 7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN). R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7152) 7153 IANA Registries for BGP Extended Communities. E. Rosen, Y. Rekhter. March 2014. (Format: TXT, HTML) (Updates RFC4360, RFC5701) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7153) 7154 IETF Guidelines for Conduct. S. Moonesamy, Ed.. March 2014. (Format: TXT, HTML) (Obsoletes RFC3184) (Also BCP0054) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7154) 7155 Diameter Network Access Server Application. G. Zorn, Ed.. April 2014. (Format: TXT, HTML) (Obsoletes RFC4005) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7155) 7156 Diameter Support for Proxy Mobile IPv6 Localized Routing. G. Zorn, Q. Wu, J. Korhonen. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7156) 7157 IPv6 Multihoming without Network Address Translation. O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7157) 7158 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT, HTML) (Obsoleted by RFC7159) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7158) 7159 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. March 2014. (Format: TXT, HTML) (Obsoletes RFC4627, RFC7158) (Obsoleted by RFC8259) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7159) 7160 Support for Multiple Clock Rates in an RTP Session. M. Petit-Huguenin, G. Zorn, Ed.. April 2014. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7160) 7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL). LM. Contreras, CJ. Bernardos, I. Soto. March 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7161) 7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC). A. Melnikov, D. Cridland. May 2014. (Format: TXT, HTML) (Obsoletes RFC4551, RFC5162) (Updates RFC2683) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7162) 7163 URN for Country-Specific Emergency Services. C. Holmberg, I. Sedlacek. March 2014. (Format: TXT, HTML) (Updates RFC5031) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7163) 7164 RTP and Leap Seconds. K. Gross, R. Brandenburg. March 2014. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7164) 7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). R. Barnes. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7165) 7166 Supporting Authentication Trailer for OSPFv3. M. Bhatia, V. Manral, A. Lindem. March 2014. (Format: TXT, HTML) (Obsoletes RFC6506) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7166) 7167 A Framework for Point-to-Multipoint MPLS in Transport Networks. D. Frost, S. Bryant, M. Bocci, L. Berger. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7167) 7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA). I. Nazar. 1 April 2014. (Format: TXT, HTML) (Updates RFC2324) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7168) 7169 The NSA (No Secrecy Afforded) Certificate Extension. S. Turner. 1 April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7169) 7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1. H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7170) 7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods. N. Cam-Winget, P. Sangster. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7171) 7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling. D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt. May 2014. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7172) 7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires. L. Yong, D. Eastlake 3rd, S. Aldrin, J. Hudson. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7173) 7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework. S. Salam, T. Senevirathne, S. Aldrin, D. Eastlake 3rd. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7174) 7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support. V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee. May 2014. (Format: TXT, HTML) (Updated by RFC8564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7175) 7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS. D. Eastlake 3rd, T. Senevirathne, A. Ghanwani, D. Dutt, A. Banerjee. May 2014. (Format: TXT, HTML) (Obsoletes RFC6326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7176) 7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency. D. Eastlake 3rd, R. Perlman, A. Ghanwani, H. Yang, V. Manral. May 2014. (Format: TXT, HTML) (Obsoletes RFC6327) (Updates RFC6325) (Updated by RFC7780, RFC8139, RFC8249, RFC8377, RFC8564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7177) 7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support. D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward. May 2014. (Format: TXT, HTML) (Updated by RFC7978) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7178) 7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension. D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler. May 2014. (Format: TXT, HTML) (Updates RFC6325) (Updated by RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7179) 7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang, A. Ghanwani, V. Manral, A. Banerjee. May 2014. (Format: TXT, HTML) (Obsoleted by RFC7780) (Updates RFC6325, RFC6327, RFC6439) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7180) 7181 The Optimized Link State Routing Protocol Version 2. T. Clausen, C. Dearlove, P. Jacquet, U. Herberg. April 2014. (Format: TXT, HTML) (Updated by RFC7183, RFC7187, RFC7188, RFC7466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7181) 7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs). U. Herberg, T. Clausen, C. Dearlove. April 2014. (Format: TXT, HTML) (Obsoletes RFC6622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7182) 7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2). U. Herberg, C. Dearlove, T. Clausen. April 2014. (Format: TXT, HTML) (Updates RFC6130, RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7183) 7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2. U. Herberg, R. Cole, T. Clausen. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7184) 7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale. C. Dearlove, T. Clausen, P. Jacquet. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7185) 7186 Security Threats for the Neighborhood Discovery Protocol (NHDP). J. Yi, U. Herberg, T. Clausen. April 2014. (Format: TXT, HTML) (Updated by RFC7985) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7186) 7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2). C. Dearlove, T. Clausen. April 2014. (Format: TXT, HTML) (Updates RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7187) 7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs. C. Dearlove, T. Clausen. April 2014. (Format: TXT, HTML) (Updates RFC6130, RFC7181) (Updated by RFC7722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7188) 7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP). G. Mirsky. March 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7189) 7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP). C. Villamizar. March 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7190) 7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. R. Housley. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7191) 7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types. S. Turner. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7192) 7193 The application/cms Media Type. S. Turner, R. Housley, J. Schaad. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7193) 7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL. R. Hartmann. August 2014. (Format: TXT, HTML) (Updates RFC1459) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7194) 7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN). M. Garcia-Martin, S. Veikkolainen. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7195) 7196 Making Route Flap Damping Usable. C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7196) 7197 Duplication Delay Attribute in the Session Description Protocol. A. Begen, Y. Cai, H. Ou. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7197) 7198 Duplicating RTP Streams. A. Begen, C. Perkins. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7198) 7199 Location Configuration Extensions for Policy Management. R. Barnes, M. Thomson, J. Winterbottom, H. Tschofenig. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7199) 7200 A Session Initiation Protocol (SIP) Load-Control Event Package. C. Shen, H. Schulzrinne, A. Koike. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7200) 7201 Options for Securing RTP Sessions. M. Westerlund, C. Perkins. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7201) 7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution. C. Perkins, M. Westerlund. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7202) 7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information. T. Takahashi, K. Landfield, Y. Kadobayashi. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7203) 7204 Requirements for Labeled NFS. T. Haynes. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7204) 7205 Use Cases for Telepresence Multistreams. A. Romanow, S. Botzko, M. Duckworth, R. Even, Ed.. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7205) 7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks. P. Jones, G. Salgueiro, J. Polk, L. Liess, H. Kaplan. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7206) 7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging. M. Ortseifen, G. Dickfeld. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7207) 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. S. Kitterman. April 2014. (Format: TXT, HTML) (Obsoletes RFC4408) (Updated by RFC7372, RFC8553, RFC8616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7208) 7209 Requirements for Ethernet VPN (EVPN). A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7209) 7210 Database of Long-Lived Symmetric Cryptographic Keys. R. Housley, T. Polk, S. Hartman, D. Zhang. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7210) 7211 Operations Model for Router Keying. S. Hartman, D. Zhang. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7211) 7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol. D. Frost, S. Bryant, M. Bocci. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7212) 7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing. D. Frost, S. Bryant, M. Bocci. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7213) 7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry. L. Andersson, C. Pignataro. May 2014. (Format: TXT, HTML) (Updates RFC5586, RFC6374, RFC6378, RFC6427, RFC6428) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7214) 7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations. L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis. April 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7215) 7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS. M. Thomson, R. Bellis. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7216) 7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). F. Gont. April 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7217) 7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE). O. Gudmundsson. April 2014. (Format: TXT, HTML) (Updates RFC6698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7218) 7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI). M. Bagnulo, A. Garcia-Martinez. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7219) 7220 Description Option for the Port Control Protocol (PCP). M. Boucadair, R. Penno, D. Wing. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7220) 7221 Handling of Internet-Drafts by IETF Working Groups. A. Farrel, D. Crocker, Ed.. April 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7221) 7222 Quality-of-Service Option for Proxy Mobile IPv6. M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7222) 7223 A YANG Data Model for Interface Management. M. Bjorklund. May 2014. (Format: TXT, HTML) (Obsoleted by RFC8343) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7223) 7224 IANA Interface Type YANG Module. M. Bjorklund. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7224) 7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP). M. Boucadair. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7225) 7226 Requirements for Advanced Multipath in MPLS Networks. C. Villamizar, Ed., D. McDysan, Ed., S. Ning, A. Malis, L. Yong. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7226) 7227 Guidelines for Creating New DHCPv6 Options. D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan. May 2014. (Format: TXT, HTML) (Updates RFC3315) (Also BCP0187) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7227) 7228 Terminology for Constrained-Node Networks. C. Bormann, M. Ersue, A. Keranen. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7228) 7229 Object Identifiers for Test Certificate Policies. R. Housley. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7229) 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2145, RFC2616) (Updates RFC2817, RFC2818) (Updated by RFC8615) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7230) 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Updates RFC2817) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7231) 7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7232) 7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7233) 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7234) 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed., J. Reschke, Ed.. June 2014. (Format: TXT, HTML) (Obsoletes RFC2616, RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7235) 7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations. J. Reschke. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7236) 7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations. J. Reschke. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7237) 7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. June 2014. (Format: TXT, HTML) (Obsoleted by RFC7538) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7238) 7239 Forwarded HTTP Extension. A. Petersson, M. Nilsson. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7239) 7240 Prefer Header for HTTP. J. Snell. June 2014. (Format: TXT, HTML) (Updated by RFC8144) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7240) 7241 The IEEE 802/IETF Relationship. S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed.. July 2014. (Format: TXT, HTML) (Obsoletes RFC4441) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7241) 7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol. M. Demmer, J. Ott, S. Perreault. June 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7242) 7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric. V. Singh, Ed., J. Ott, I. Curcio. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7243) 7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting. H. Asaeda, Q. Wu, R. Huang. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7244) 7245 An Architecture for Media Recording Using the Session Initiation Protocol. A. Hutton, Ed., L. Portman, Ed., R. Jain, K. Rehor. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7245) 7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context. IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura. June 2014. (Format: TXT, HTML) (Updated by RFC7438) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7246) 7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling. P. Saint-Andre, A. Houri, J. Hildebrand. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7247) 7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre, A. Houri, J. Hildebrand. May 2014. (Format: TXT, HTML) (Obsoleted by RFC8048) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7248) 7249 Internet Numbers Registries. R. Housley. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7249) 7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7250) 7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS. D. McGrew, D. Bailey, M. Campagna, R. Dugal. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7251) 7252 The Constrained Application Protocol (CoAP). Z. Shelby, K. Hartke, C. Bormann. June 2014. (Format: TXT, HTML) (Updated by RFC7959, RFC8613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7252) 7253 The OCB Authenticated-Encryption Algorithm. T. Krovetz, P. Rogaway. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7253) 7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI). M. Montemurro, Ed., A. Allen, D. McDonald, P. Gosden. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7254) 7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID. A. Allen, Ed.. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7255) 7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP). F. Le Faucheur, R. Maglione, T. Taylor. July 2014. (Format: TXT, HTML) (Updates RFC6320) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7256) 7257 Virtual Private LAN Service (VPLS) Management Information Base. T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7257) 7258 Pervasive Monitoring Is an Attack. S. Farrell, H. Tschofenig. May 2014. (Format: TXT, HTML) (Also BCP0188) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7258) 7259 The Jabber-ID Header Field. P. Saint-Andre. May 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7259) 7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration. A. Takacs, D. Fedyk, J. He. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7260) 7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B. M. Perumal, P. Ravindran. May 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7261) 7262 Requirements for Telepresence Multistreams. A. Romanow, S. Botzko, M. Barnes. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7262) 7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing. N. Zong, X. Jiang, R. Even, Y. Zhang. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7263) 7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing. N. Zong, X. Jiang, R. Even, Y. Zhang. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7264) 7265 jCal: The JSON Format for iCalendar. P. Kewisch, C. Daboo, M. Douglass. May 2014. (Format: TXT, HTML) (Updated by RFC7529) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7265) 7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting. A. Clark, Q. Wu, R. Schott, G. Zorn. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7266) 7267 Dynamic Placement of Multi-Segment Pseudowires. L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed.. June 2014. (Format: TXT, HTML) (Updates RFC6073) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7267) 7268 RADIUS Attributes for IEEE 802 Networks. B. Aboba, J. Malinen, P. Congdon, J. Salowey, M. Jones. July 2014. (Format: TXT, HTML) (Updates RFC3580, RFC4072) (Updated by RFC8044) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7268) 7269 NAT64 Deployment Options and Experience. G. Chen, Z. Cao, C. Xie, D. Binet. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7269) 7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX). A. Yourtchenko, P. Aitken, B. Claise. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7270) 7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators. J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne. June 2014. (Format: TXT, HTML) (Updates RFC6378) (Updated by RFC8234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7271) 7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP). R. van Brandenburg, H. Stokking, O. van Deventer, F. Boronat, M. Montagud, K. Gross. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7272) 7273 RTP Clock Source Signalling. A. Williams, K. Gross, R. van Brandenburg, H. Stokking. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7273) 7274 Allocating and Retiring Special-Purpose MPLS Labels. K. Kompella, L. Andersson, A. Farrel. June 2014. (Format: TXT, HTML) (Updates RFC3032, RFC3038, RFC3209, RFC3811, RFC4182, RFC4928, RFC5331, RFC5586, RFC5921, RFC5960, RFC6391, RFC6478, RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7274) 7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy. L. Martini, S. Salam, A. Sajassi, M. Bocci, S. Matsushima, T. Nadeau. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7275) 7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools. T. Mizrahi, N. Sprecher, E. Bellagamba, Y. Weingarten. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7276) 7277 A YANG Data Model for IP Management. M. Bjorklund. June 2014. (Format: TXT, HTML) (Obsoleted by RFC8344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7277) 7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link. C. Byrne, D. Drown, A. Vizdal. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7278) 7279 An Acceptable Use Policy for New ICMP Types and Codes. M. Shore, C. Pignataro. May 2014. (Format: TXT, HTML) (Also BCP0189) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7279) 7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry. G. Fairhurst. June 2014. (Format: TXT, HTML) (Updates RFC4326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7280) 7281 Authentication-Results Registration for S/MIME Signature Verification. A. Melnikov. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7281) 7282 On Consensus and Humming in the IETF. P. Resnick. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7282) 7283 Handling Unknown DHCPv6 Messages. Y. Cui, Q. Sun, T. Lemon. July 2014. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7283) 7284 The Profile URI Registry. M. Lanthaler. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7284) 7285 Application-Layer Traffic Optimization (ALTO) Protocol. R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7285) 7286 Application-Layer Traffic Optimization (ALTO) Server Discovery. S. Kiesel, M. Stiemerling, N. Schwan, M. Scharf, H. Song. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7286) 7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch. June 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7287) 7288 Reflections on Host Firewalls. D. Thaler. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7288) 7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs. V. Kuarsingh, Ed., J. Cianfarani. June 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7289) 7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track. L. Ciavattone, R. Geib, A. Morton, M. Wieser. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7290) 7291 DHCP Options for the Port Control Protocol (PCP). M. Boucadair, R. Penno, D. Wing. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7291) 7292 PKCS #12: Personal Information Exchange Syntax v1.1. K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7292) 7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension. W. Mills, M. Kucherawy. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7293) 7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications. A. Clark, G. Zorn, C. Bi, Q. Wu. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7294) 7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication. H. Tschofenig, L. Eggert, Z. Sarker. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7295) 7296 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen. October 2014. (Format: TXT, HTML) (Obsoletes RFC5996) (Updated by RFC7427, RFC7670, RFC8247) (Also STD0079) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7296) 7297 IP Connectivity Provisioning Profile (CPP). M. Boucadair, C. Jacquenet, N. Wang. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7297) 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication. D. Ovsienko. July 2014. (Format: TXT, HTML) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7298) 7299 Object Identifier Registry for the PKIX Working Group. R. Housley. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7299) 7300 Reservation of Last Autonomous System (AS) Numbers. J. Haas, J. Mitchell. July 2014. (Format: TXT, HTML) (Updates RFC1930) (Also BCP0006) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7300) 7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. S. Friedl, A. Popov, A. Langley, E. Stephan. July 2014. (Format: TXT, HTML) (Updated by RFC8447) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7301) 7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. July 2014. (Format: TXT, HTML) (Obsoleted by RFC7972) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7302) 7303 XML Media Types. H. Thompson, C. Lilley. July 2014. (Format: TXT, HTML) (Obsoletes RFC3023) (Updates RFC6839) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7303) 7304 A Method for Mitigating Namespace Collisions. W. Kumari. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7304) 7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT). E. Lear, Ed.. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7305) 7306 Remote Direct Memory Access (RDMA) Protocol Extensions. H. Shah, F. Marti, W. Noureddine, A. Eiriksson, R. Sharp. June 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7306) 7307 LDP Extensions for Multi-Topology. Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7307) 7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE). E. Osborne. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7308) 7309 Redundancy Mechanism for Inter-domain VPLS Service. Z. Liu, L. Jin, R. Chen, D. Cai, S. Salam. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7309) 7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs. J. Lindsay, H. Foerster. July 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7310) 7311 The Accumulated IGP Metric Attribute for BGP. P. Mohapatra, R. Fernando, E. Rosen, J. Uttaro. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7311) 7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM). J. Fabini, A. Morton. August 2014. (Format: TXT, HTML) (Updates RFC2330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7312) 7313 Enhanced Route Refresh Capability for BGP-4. K. Patel, E. Chen, B. Venkatachalapathy. July 2014. (Format: TXT, HTML) (Updates RFC2918) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7313) 7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option. M. Andrews. July 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7314) 7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP. R. Jesske, K. Drage, C. Holmberg. July 2014. (Format: TXT, HTML) (Obsoletes RFC3455) (Updated by RFC7913, RFC7976) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7315) 7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header). J. van Elburg, K. Drage, M. Ohsugi, S. Schubert, K. Arai. July 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7316) 7317 A YANG Data Model for System Management. A. Bierman, M. Bjorklund. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7317) 7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates. A. Newton, G. Huston. July 2014. (Format: TXT, HTML) (Updates RFC6487) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7318) 7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points. D. Eastlake 3rd. July 2014. (Format: TXT, HTML) (Also BCP0191) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7319) 7320 URI Design and Ownership. M. Nottingham. July 2014. (Format: TXT, HTML) (Obsoleted by RFC8820) (Updates RFC3986) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7320) 7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). D. McGrew, P. Hoffman. August 2014. (Format: TXT, HTML) (Obsoletes RFC4835) (Obsoleted by RFC8221) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7321) 7322 RFC Style Guide. H. Flanagan, S. Ginoza. September 2014. (Format: TXT, HTML) (Obsoletes RFC2223) (Updated by RFC7997) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7322) 7323 TCP Extensions for High Performance. D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.. September 2014. (Format: TXT, HTML) (Obsoletes RFC1323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7323) 7324 Updates to MPLS Transport Profile Linear Protection. E. Osborne. July 2014. (Format: TXT, HTML) (Updates RFC6378) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7324) 7325 MPLS Forwarding Compliance and Performance Requirements. C. Villamizar, Ed., K. Kompella, S. Amante, A. Malis, C. Pignataro. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7325) 7326 Energy Management Framework. J. Parello, B. Claise, B. Schoening, J. Quittek. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7326) 7327 Not Issued. 7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML. R. Gieben. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7328) 7329 A Session Identifier for the Session Initiation Protocol (SIP). H. Kaplan. August 2014. (Format: TXT, HTML) (Obsoleted by RFC7989) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7329) 7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management. T. Nadeau, Z. Ali, N. Akiya. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7330) 7331 Bidirectional Forwarding Detection (BFD) Management Information Base. T. Nadeau, Z. Ali, N. Akiya. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7331) 7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs). H. Kaplan, V. Pascual. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7332) 7333 Requirements for Distributed Mobility Management. H. Chan, Ed., D. Liu, P. Seite, H. Yokota, J. Korhonen. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7333) 7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths. Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas. August 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7334) 7335 IPv4 Service Continuity Prefix. C. Byrne. August 2014. (Format: TXT, HTML) (Updates RFC6333) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7335) 7336 Framework for Content Distribution Network Interconnection (CDNI). L. Peterson, B. Davie, R. van Brandenburg, Ed.. August 2014. (Format: TXT, HTML) (Obsoletes RFC3466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7336) 7337 Content Distribution Network Interconnection (CDNI) Requirements. K. Leung, Ed., Y. Lee, Ed.. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7337) 7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks. F. Jounay, Ed., Y. Kamite, Ed., G. Heron, M. Bocci. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7338) 7339 Session Initiation Protocol (SIP) Overload Control. V. Gurbani, Ed., V. Hilt, H. Schulzrinne. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7339) 7340 Secure Telephone Identity Problem Statement and Requirements. J. Peterson, H. Schulzrinne, H. Tschofenig. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7340) 7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport. Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7341) 7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers. L. Dunbar, W. Kumari, I. Gashinsky. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7342) 7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). J. Laganier, F. Dupont. September 2014. (Format: TXT, HTML) (Obsoletes RFC4843) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7343) 7344 Automating DNSSEC Delegation Trust Maintenance. W. Kumari, O. Gudmundsson, G. Barwood. September 2014. (Format: TXT, HTML) (Updated by RFC8078) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7344) 7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS). C. Holmberg, I. Sedlacek, G. Salgueiro. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7345) 7346 IPv6 Multicast Address Scopes. R. Droms. August 2014. (Format: TXT, HTML) (Updates RFC4007, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7346) 7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP). H. van Helvoort, Ed., J. Ryoo, Ed., H. Zhang, F. Huang, H. Li, A. D'Alessandro. September 2014. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7347) 7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks. M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7348) 7349 LDP Hello Cryptographic Authentication. L. Zheng, M. Chen, M. Bhatia. August 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7349) 7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN). M. Petit-Huguenin, G. Salgueiro. August 2014. (Format: TXT, HTML) (Updates RFC5389, RFC5928) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7350) 7351 A Media Type for XML Patch Operations. E. Wilde. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7351) 7352 Sieve Email Filtering: Detecting Duplicate Deliveries. S. Bosch. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7352) 7353 Security Requirements for BGP Path Validation. S. Bellovin, R. Bush, D. Ward. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7353) 7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace. A. Adolf, P. Siebert. September 2014. (Format: TXT, HTML) (Updates RFC5328) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7354) 7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF). G. Salgueiro, V. Pascual, A. Roman, S. Garcia. September 2014. (Format: TXT, HTML) (Updates RFC6873) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7355) 7356 IS-IS Flooding Scope Link State PDUs (LSPs). L. Ginsberg, S. Previdi, Y. Yang. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7356) 7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol. H. Zhai, F. Hu, R. Perlman, D. Eastlake 3rd, O. Stokes. September 2014. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7357) 7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs). K. Raza, S. Boutros, L. Martini, N. Leymann. October 2014. (Format: TXT, HTML) (Updates RFC3212, RFC4447, RFC5036, RFC5918, RFC6388, RFC7140) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7358) 7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks. F. Gont. August 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7359) 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS. A. DeKok. September 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7360) 7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS). P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7361) 7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication. E. Ivov, H. Kaplan, D. Wing. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7362) 7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD). J. Maenpaa, G. Camarillo. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7363) 7364 Problem Statement: Overlays for Network Virtualization. T. Narten, Ed., E. Gray, Ed., D. Black, L. Fang, L. Kreeger, M. Napierala. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7364) 7365 Framework for Data Center (DC) Network Virtualization. M. Lasserre, F. Balus, T. Morin, N. Bitar, Y. Rekhter. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7365) 7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). P. Gutmann. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7366) 7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process. R. Cole, J. Macker, B. Adamson. October 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7367) 7368 IPv6 Home Networking Architecture Principles. T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7368) 7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration. A. Takacs, B. Gero, H. Long. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7369) 7370 Updates to the IS-IS TLV Codepoints Registry. L. Ginsberg. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7370) 7371 Updates to the IPv6 Multicast Addressing Architecture. M. Boucadair, S. Venaas. September 2014. (Format: TXT, HTML) (Updates RFC3306, RFC3956, RFC4291) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7371) 7372 Email Authentication Status Codes. M. Kucherawy. September 2014. (Format: TXT, HTML) (Updates RFC7208) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7372) 7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types. B. Trammell. September 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7373) 7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD). J. Maenpaa, G. Camarillo. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7374) 7375 Secure Telephone Identity Threat Model. J. Peterson. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7375) 7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN). T. Reddy, R. Ravindranath, M. Perumal, A. Yegin. September 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7376) 7377 IMAP4 Multimailbox SEARCH Extension. B. Leiba, A. Melnikov. October 2014. (Format: TXT, HTML) (Obsoletes RFC6237) (Updates RFC4466) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7377) 7378 Trustworthy Location. H. Tschofenig, H. Schulzrinne, B. Aboba, Ed.. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7378) 7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge. Y. Li, W. Hao, R. Perlman, J. Hudson, H. Zhai. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7379) 7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting. J. Tong, C. Bi, Ed., R. Even, Q. Wu, Ed., R. Huang. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7380) 7381 Enterprise IPv6 Deployment Guidelines. K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7381) 7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI). S. Kent, D. Kong, K. Seo. April 2015. (Format: TXT, HTML) (Also BCP0173) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7382) 7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation. V. Smyslov. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7383) 7384 Security Requirements of Time Protocols in Packet Switched Networks. T. Mizrahi. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7384) 7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points. L. Andersson, G. Swallow. October 2014. (Format: TXT, HTML) (Updates RFC6514) (Updated by RFC8317, RFC8338) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7385) 7386 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT, HTML) (Obsoleted by RFC7396) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7386) 7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network. R. Key, Ed., L. Yong, Ed., S. Delord, F. Jounay, L. Jin. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7387) 7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7388) 7389 Separation of Control and User Plane for Proxy Mobile IPv6. R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7389) 7390 Group Communication for the Constrained Application Protocol (CoAP). A. Rahman, Ed., E. Dijk, Ed.. October 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7390) 7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions. J. Hadi Salim. October 2014. (Format: TXT, HTML) (Updates RFC5810, RFC7121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7391) 7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires. P. Dutta, M. Bocci, L. Martini. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7392) 7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS. X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou. November 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7393) 7394 Definition of Time to Live TLV for LSP-Ping Mechanisms. S. Boutros, S. Sivabalan, G. Swallow, S. Saxena, V. Manral, S. Aldrin. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7394) 7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket. L. Stout, Ed., J. Moffitt, E. Cestari. October 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7395) 7396 JSON Merge Patch. P. Hoffman, J. Snell. October 2014. (Format: TXT, HTML) (Obsoletes RFC7386) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7396) 7397 Report from the Smart Object Security Workshop. J. Gilger, H. Tschofenig. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7397) 7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance. M. Bagnulo, T. Burbridge, S. Crawford, P. Eardley, A. Morton. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7398) 7399 Unanswered Questions in the Path Computation Element Architecture. A. Farrel, D. King. October 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7399) 7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). C. Bormann. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7400) 7401 Host Identity Protocol Version 2 (HIPv2). R. Moskowitz, Ed., T. Heer, P. Jokela, T. Henderson. April 2015. (Format: TXT, HTML) (Obsoletes RFC5201) (Updated by RFC8002) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7401) 7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, J. Melen. April 2015. (Format: TXT, HTML) (Obsoletes RFC5202) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7402) 7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP). H. Kaplan. November 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7403) 7404 Using Only Link-Local Addressing inside an IPv6 Network. M. Behringer, E. Vyncke. November 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7404) 7405 Case-Sensitive String Support in ABNF. P. Kyzivat. December 2014. (Format: TXT, HTML) (Updates RFC5234) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7405) 7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices. H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7406) 7407 A YANG Data Model for SNMP Configuration. M. Bjorklund, J. Schoenwaelder. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7407) 7408 Forwarding and Control Element Separation (ForCES) Model Extension. E. Haleplidis. November 2014. (Format: TXT, HTML) (Updates RFC5812) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7408) 7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization. E. Haleplidis, J. Halpern. November 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7409) 7410 A Property Types Registry for the Authentication-Results Header Field. M. Kucherawy. December 2014. (Format: TXT, HTML) (Obsoleted by RFC7601) (Updates RFC7001) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7410) 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers. T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu. November 2014. (Format: TXT, HTML) (Updates RFC5568) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7411) 7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection. Y. Weingarten, S. Aldrin, P. Pan, J. Ryoo, G. Mirsky. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7412) 7413 TCP Fast Open. Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain. December 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7413) 7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents. M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann. February 2015. (Format: TXT, HTML) (Obsoletes RFC4614) (Updated by RFC7805) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7414) 7415 Session Initiation Protocol (SIP) Rate Control. E. Noel, P. Williams. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7415) 7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed.. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7416) 7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains. G. Karagiannis, A. Bhargava. December 2014. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7417) 7418 An IRTF Primer for IETF Participants. S. Dawkins, Ed.. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7418) 7419 Common Interval Support in Bidirectional Forwarding Detection. N. Akiya, M. Binderberger, G. Mirsky. December 2014. (Format: TXT, HTML) (Updates RFC5880) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7419) 7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module. A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick. December 2014. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7420) 7421 Analysis of the 64-bit Boundary in IPv6 Addressing. B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7421) 7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments. C. Donley, C. Grundemann, V. Sarawat, K. Sundaresan, O. Vautrin. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7422) 7423 Diameter Applications Design Guidelines. L. Morand, Ed., V. Fajardo, H. Tschofenig. November 2014. (Format: TXT, HTML) (Also BCP0193) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7423) 7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks. R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7424) 7425 Adobe's RTMFP Profile for Flash Communication. M. Thornburgh. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7425) 7426 Software-Defined Networking (SDN): Layers and Architecture Terminology. E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, O. Koufopavlou. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7426) 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2). T. Kivinen, J. Snyder. January 2015. (Format: TXT, HTML) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7427) 7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks. A. Brandt, J. Buron. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7428) 7429 Distributed Mobility Management: Current Practices and Gap Analysis. D. Liu, Ed., JC. Zuniga, Ed., P. Seite, H. Chan, CJ. Bernardos. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7429) 7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP). M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7430) 7431 Multicast-Only Fast Reroute. A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7431) 7432 BGP MPLS-Based Ethernet VPN. A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx. February 2015. (Format: TXT, HTML) (Updated by RFC8584) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7432) 7433 A Mechanism for Transporting User-to-User Call Control Information in SIP. A. Johnston, J. Rafferty. January 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7433) 7434 Interworking ISDN Call Control User Information with SIP. K. Drage, Ed., A. Johnston. January 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7434) 7435 Opportunistic Security: Some Protection Most of the Time. V. Dukhovni. December 2014. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7435) 7436 IP-Only LAN Service (IPLS). H. Shah, E. Rosen, F. Le Faucheur, G. Heron. January 2015. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC7436) 7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. M. Kucherawy, Ed.. January 2015. (Format: TXT, HTML) (Obsoletes RFC3777, RFC5078, RFC5633, RFC5680, RFC6859) (Obsoleted by RFC8713) (Updated by RFC8318) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7437) 7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards. IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura. January 2015. (Format: TXT, HTML) (Updates RFC6826, RFC7246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7438) 7439 Gap Analysis for Operating IPv6-Only MPLS Networks. W. George, Ed., C. Pignataro, Ed.. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7439) 7440 TFTP Windowsize Option. P. Masotta. January 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7440) 7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes. IJ. Wijnands, E. Rosen, U. Joorde. January 2015. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7441) 7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP). Y. Rekhter, R. Aggarwal, N. Leymann, W. Henderickx, Q. Zhao, R. Li. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7442) 7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages. P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin. January 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7443) 7444 Security Labels in Internet Email. K. Zeilenga, A. Melnikov. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7444) 7445 Analysis of Failure Cases in IPv6 Roaming Scenarios. G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7445) 7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks. Y. Lee, Ed., G. Bernstein, Ed., D. Li, W. Imajuku. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7446) 7447 Deprecation of BGP Entropy Label Capability Attribute. J. Scudder, K. Kompella. February 2015. (Format: TXT, HTML) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7447) 7448 MIB Transfer from the IETF to the IEEE 802.3 WG. T. Taylor, Ed., D. Romascanu. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7448) 7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment. Y. Lee, Ed., G. Bernstein, Ed., J. Martensson, T. Takeda, T. Tsuritani, O. Gonzalez de Dios. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7449) 7450 Automatic Multicast Tunneling. G. Bumgardner. February 2015. (Format: TXT, HTML) (Updated by RFC8777) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7450) 7451 Extension Registry for the Extensible Provisioning Protocol. S. Hollenbeck. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7451) 7452 Architectural Considerations in Smart Object Networking. H. Tschofenig, J. Arkko, D. Thaler, D. McPherson. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7452) 7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB). V. Mahalingam, K. Sampath, S. Aldrin, T. Nadeau. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7453) 7454 BGP Operations and Security. J. Durand, I. Pepelnjak, G. Doering. February 2015. (Format: TXT, HTML) (Also BCP0194) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7454) 7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management. T. Senevirathne, N. Finn, S. Salam, D. Kumar, D. Eastlake 3rd, S. Aldrin, Y. Li. March 2015. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7455) 7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL). T. Mizrahi, T. Senevirathne, S. Salam, D. Kumar, D. Eastlake 3rd. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7456) 7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS). Y. Sheffer, R. Holz, P. Saint-Andre. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7457) 7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core. R. Valmikam, R. Koodli. February 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7458) 7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO). M. Thomson, J. Winterbottom. February 2015. (Format: TXT, HTML) (Updates RFC3693, RFC4119, RFC5491) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7459) 7460 Monitoring and Control MIB for Power and Energy. M. Chandramouli, B. Claise, B. Schoening, J. Quittek, T. Dietz. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7460) 7461 Energy Object Context MIB. J. Parello, B. Claise, M. Chandramouli. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7461) 7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP). L. Liess, Ed., R. Jesske, A. Johnston, D. Worley, P. Kyzivat. March 2015. (Format: TXT, HTML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7462) 7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR). A. Johnston, Ed., M. Soroushnejad, Ed., V. Venkataramanan. March 2015. (Format: TXT, HTML) (Updates RFC3261, RFC4235) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7463) 7464 JavaScript Object Notation (JSON) Text Sequences. N. Williams. February 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7464) 7465 Prohibiting RC4 Cipher Suites. A. Popov. February 2015. (Format: TXT, HTML) (Updates RFC5246, RFC4346, RFC2246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7465) 7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP). C. Dearlove, T. Clausen. March 2015. (Format: TXT, HTML) (Updates RFC6130, RFC7181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7466) 7467 URN Namespace for the North Atlantic Treaty Organization (NATO). A. Murdock. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7467) 7468 Textual Encodings of PKIX, PKCS, and CMS Structures. S. Josefsson, S. Leonard. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7468) 7469 Public Key Pinning Extension for HTTP. C. Evans, C. Palmer, R. Sleevi. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7469) 7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol. F. Zhang, A. Farrel. March 2015. (Format: TXT, HTML) (Obsoletes RFC7150) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7470) 7471 OSPF Traffic Engineering (TE) Metric Extensions. S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7471) 7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme. I. McDonald, M. Sweet. March 2015. (Format: TXT, HTML) (Updates RFC2910, RFC2911) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7472) 7473 Controlling State Advertisements of Non-negotiated LDP Applications. K. Raza, S. Boutros. March 2015. (Format: TXT, HTML) (Updated by RFC8223) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7473) 7474 Security Extension for OSPFv2 When Using Manual Key Management. M. Bhatia, S. Hartman, D. Zhang, A. Lindem, Ed.. April 2015. (Format: TXT, HTML) (Updates RFC2328, RFC5709) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7474) 7475 Increasing the Number of Area Directors in an IETF Area. S. Dawkins. March 2015. (Format: TXT, HTML) (Updates RFC2026, RFC2418) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7475) 7476 Information-Centric Networking: Baseline Scenarios. K. Pentikousis, Ed., B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, S. Eum. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7476) 7477 Child-to-Parent Synchronization in DNS. W. Hardaker. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7477) 7478 Web Real-Time Communication Use Cases and Requirements. C. Holmberg, S. Hakansson, G. Eriksson. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7478) 7479 Using Ed25519 in SSHFP Resource Records. S. Moonesamy. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7479) 7480 HTTP Usage in the Registration Data Access Protocol (RDAP). A. Newton, B. Ellacott, N. Kong. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7480) 7481 Security Services for the Registration Data Access Protocol (RDAP). S. Hollenbeck, N. Kong. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7481) 7482 Registration Data Access Protocol (RDAP) Query Format. A. Newton, S. Hollenbeck. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7482) 7483 JSON Responses for the Registration Data Access Protocol (RDAP). A. Newton, S. Hollenbeck. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7483) 7484 Finding the Authoritative Registration Data (RDAP) Service. M. Blanchet. March 2015. (Format: TXT, HTML) (Updated by RFC8521) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7484) 7485 Inventory and Analysis of WHOIS Registration Objects. L. Zhou, N. Kong, S. Shen, S. Sheng, A. Servin. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7485) 7486 HTTP Origin-Bound Authentication (HOBA). S. Farrell, P. Hoffman, M. Thomas. March 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7486) 7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE. E. Bellagamba, A. Takacs, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7487) 7488 Port Control Protocol (PCP) Server Selection. M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy. March 2015. (Format: TXT, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7488) 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC). M. Kucherawy, Ed., E. Zwicky, Ed.. March 2015. (Format: TXT, HTML) (Updated by RFC8553, RFC8616) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7489) 7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR). S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7490) 7491 A PCE-Based Architecture for Application-Based Network Operations. D. King, A. Farrel. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7491) 7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines. M. Bhatia, D. Zhang, M. Jethanandani. March 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7492) 7493 The I-JSON Message Format. T. Bray, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7493) 7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP). C. Shao, H. Deng, R. Pazhyannur, F. Bari, R. Zhang, S. Matsushima. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7494) 7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF). A. Montville, D. Black. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7495) 7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension. M. Tuexen, R. Seggelmann, R. Stewart, S. Loreto. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7496) 7497 Rate Measurement Test Protocol Problem Statement and Requirements. A. Morton. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7497) 7498 Problem Statement for Service Function Chaining. P. Quinn, Ed., T. Nadeau, Ed.. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7498) 7499 Support of Fragmentation of RADIUS Packets. A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok. April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7499) 7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries. R. Housley, Ed., O. Kolkman, Ed.. April 2015. (Format: TXT, HTML) (Obsoleted by RFC8720) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7500) 7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration. C. Davids, V. Gurbani, S. Poretsky. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7501) 7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration. C. Davids, V. Gurbani, S. Poretsky. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7502) 7503 OSPFv3 Autoconfiguration. A. Lindem, J. Arkko. April 2015. (Format: TXT, HTML) (Updates RFC5340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7503) 7504 SMTP 521 and 556 Reply Codes. J. Klensin. June 2015. (Format: TXT, HTML) (Updates RFC1846, RFC5321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7504) 7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail. J. Levine, M. Delany. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7505) 7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM). K. Raza, N. Akiya, C. Pignataro. April 2015. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7506) 7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. B. Moeller, A. Langley. April 2015. (Format: TXT, HTML) (Updates RFC2246, RFC4346, RFC4347, RFC5246, RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7507) 7508 Securing Header Fields with S/MIME. L. Cailleux, C. Bonatti. April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7508) 7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics. R. Huang, V. Singh. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7509) 7510 Encapsulating MPLS in UDP. X. Xu, N. Sheth, L. Yong, R. Callon, D. Black. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7510) 7511 Scenic Routing for IPv6. M. Wilhelm. 1 April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7511) 7512 The PKCS #11 URI Scheme. J. Pechanec, D. Moffat. April 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7512) 7513 Source Address Validation Improvement (SAVI) Solution for DHCP. J. Bi, J. Wu, G. Yao, F. Baker. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7513) 7514 Really Explicit Congestion Notification (RECN). M. Luckie. 1 April 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7514) 7515 JSON Web Signature (JWS). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7515) 7516 JSON Web Encryption (JWE). M. Jones, J. Hildebrand. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7516) 7517 JSON Web Key (JWK). M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7517) 7518 JSON Web Algorithms (JWA). M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7518) 7519 JSON Web Token (JWT). M. Jones, J. Bradley, N. Sakimura. May 2015. (Format: TXT, HTML) (Updated by RFC7797, RFC8725) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7519) 7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE). M. Miller. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7520) 7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants. B. Campbell, C. Mortimore, M. Jones, Y. Goland. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7521) 7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants. B. Campbell, C. Mortimore, M. Jones. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7522) 7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. M. Jones, B. Campbell, C. Mortimore. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7523) 7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs). Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad. May 2015. (Format: TXT, HTML) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7524) 7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). Y. Sheffer, R. Holz, P. Saint-Andre. May 2015. (Format: TXT, HTML) (Also BCP0195) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7525) 7526 Deprecating the Anycast Prefix for 6to4 Relay Routers. O. Troan, B. Carpenter, Ed.. May 2015. (Format: TXT, HTML) (Obsoletes RFC3068, RFC6732) (Also BCP0196) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7526) 7527 Enhanced Duplicate Address Detection. R. Asati, H. Singh, W. Beebee, C. Pignataro, E. Dart, W. George. April 2015. (Format: TXT, HTML) (Updates RFC4429, RFC4861, RFC4862) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7527) 7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association. P. Higgs, J. Piesing. April 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7528) 7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar). C. Daboo, G. Yakushev. May 2015. (Format: TXT, HTML) (Updates RFC5545, RFC6321, RFC7265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7529) 7530 Network File System (NFS) Version 4 Protocol. T. Haynes, Ed., D. Noveck, Ed.. March 2015. (Format: TXT, HTML) (Obsoletes RFC3530) (Updated by RFC7931, RFC8587) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7530) 7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description. T. Haynes, Ed., D. Noveck, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7531) 7532 Namespace Database (NSDB) Protocol for Federated File Systems. J. Lentini, R. Tewari, C. Lever, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7532) 7533 Administration Protocol for Federated File Systems. J. Lentini, R. Tewari, C. Lever, Ed.. March 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7533) 7534 AS112 Nameserver Operations. J. Abley, W. Sotomayor. May 2015. (Format: TXT, HTML) (Obsoletes RFC6304) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7534) 7535 AS112 Redirection Using DNAME. J. Abley, B. Dickson, W. Kumari, G. Michaelson. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7535) 7536 Large-Scale Broadband Measurement Use Cases. M. Linsner, P. Eardley, T. Burbridge, F. Sorensen. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7536) 7537 IANA Registries for LSP Ping Code Points. B. Decraene, N. Akiya, C. Pignataro, L. Andersson, S. Aldrin. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8029) (Updates RFC4379, RFC6424) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7537) 7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. (Format: TXT, HTML) (Obsoletes RFC7238) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7538) 7539 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8439) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7539) 7540 Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe, R. Peon, M. Thomson, Ed.. May 2015. (Format: TXT, HTML) (Updated by RFC8740) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7540) 7541 HPACK: Header Compression for HTTP/2. R. Peon, H. Ruellan. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7541) 7542 The Network Access Identifier. A. DeKok. May 2015. (Format: TXT, HTML) (Obsoletes RFC4282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7542) 7543 Covering Prefixes Outbound Route Filter for BGP-4. H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7543) 7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP). M. Mohali. August 2015. (Format: TXT, HTML) (Obsoletes RFC6044) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7544) 7545 Protocol to Access White-Space (PAWS) Databases. V. Chen, Ed., S. Das, L. Zhu, J. Malyar, P. McCann. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7545) 7546 Structure of the Generic Security Service (GSS) Negotiation Loop. B. Kaduk. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7546) 7547 Management of Networks with Constrained Devices: Problem Statement and Requirements. M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7547) 7548 Management of Networks with Constrained Devices: Use Cases. M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7548) 7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter. C. Holmberg, J. Holm, R. Jesske, M. Dolly. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7549) 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options. O. Troan, B. Volz, M. Siodelski. May 2015. (Format: TXT, HTML) (Obsoleted by RFC8415) (Updates RFC3315, RFC3633) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7550) 7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs). F. Zhang, Ed., R. Jing, R. Gandhi, Ed.. May 2015. (Format: TXT, HTML) (Updated by RFC8537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7551) 7552 Updates to LDP for IPv6. R. Asati, C. Pignataro, K. Raza, V. Manral, R. Papneja. June 2015. (Format: TXT, HTML) (Updates RFC5036, RFC6720) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7552) 7553 The Uniform Resource Identifier (URI) DNS Resource Record. P. Faltstrom, O. Kolkman. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7553) 7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement. T. Watteyne, Ed., M. Palattella, L. Grieco. May 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7554) 7555 Proxy MPLS Echo Request. G. Swallow, V. Lim, S. Aldrin. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7555) 7556 Multiple Provisioning Domain Architecture. D. Anipko, Ed.. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7556) 7557 Extension Mechanism for the Babel Routing Protocol. J. Chroboczek. May 2015. (Format: TXT, HTML) (Updates RFC6126) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7557) 7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions. K. Lynn, S. Cheshire, M. Blanchet, D. Migault. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7558) 7559 Packet-Loss Resiliency for Router Solicitations. S. Krishnan, D. Anipko, D. Thaler. May 2015. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7559) 7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback. M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7560) 7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN. J. Kaippallimalil, R. Pazhyannur, P. Yegani. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7561) 7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates. D. Thakore. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7562) 7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option. R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil. June 2015. (Format: TXT, HTML) (Updates RFC6757) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7563) 7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. P. Saint-Andre, M. Blanchet. May 2015. (Format: TXT, HTML) (Obsoletes RFC3454) (Obsoleted by RFC8264) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7564) 7565 The 'acct' URI Scheme. P. Saint-Andre. May 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7565) 7566 Enumservice Registration for 'acct' URI. L. Goix, K. Li. June 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7566) 7567 IETF Recommendations Regarding Active Queue Management. F. Baker, Ed., G. Fairhurst, Ed.. July 2015. (Format: TXT, HTML) (Obsoletes RFC2309) (Also BCP0197) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7567) 7568 Deprecating Secure Sockets Layer Version 3.0. R. Barnes, M. Thomson, A. Pironti, A. Langley. June 2015. (Format: TXT, HTML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7568) 7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats. D. Quigley, J. Lu, T. Haynes. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7569) 7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO). C. Margaria, Ed., G. Martinelli, S. Balls, B. Wright. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7570) 7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback. J. Dong, M. Chen, Z. Li, D. Ceccarelli. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7571) 7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging. P. Saint-Andre, A. Houri, J. Hildebrand. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7572) 7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions. P. Saint-Andre, S. Loreto. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7573) 7574 Peer-to-Peer Streaming Peer Protocol (PPSPP). A. Bakker, R. Petrocco, V. Grishchenko. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7574) 7575 Autonomic Networking: Definitions and Design Goals. M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7575) 7576 General Gap Analysis for Autonomic Networking. S. Jiang, B. Carpenter, M. Behringer. June 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7576) 7577 Definition of Managed Objects for Battery Monitoring. J. Quittek, R. Winter, T. Dietz. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7577) 7578 Returning Values from Forms: multipart/form-data. L. Masinter. July 2015. (Format: TXT, HTML) (Obsoletes RFC2388) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7578) 7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks. G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7579) 7580 OSPF-TE Extensions for General Network Element Constraints. F. Zhang, Y. Lee, J. Han, G. Bernstein, Y. Xu. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7580) 7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks. G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7581) 7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels. E. Rosen, IJ. Wijnands, Y. Cai, A. Boers. July 2015. (Format: TXT, HTML) (Updates RFC6513, RFC6514, RFC6625) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7582) 7583 DNSSEC Key Rollover Timing Considerations. S. Morris, J. Ihren, J. Dickinson, W. Mekking. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7583) 7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs). R. Ravindranath, T. Reddy, G. Salgueiro. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7584) 7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI). S. Winter, M. McCauley. October 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7585) 7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers. Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi. June 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7586) 7587 RTP Payload Format for the Opus Speech and Audio Codec. J. Spittka, K. Vos, JM. Valin. June 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7587) 7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem. R. Bonica, C. Pignataro, J. Touch. July 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7588) 7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication. M. Badra, A. Luchuk, J. Schoenwaelder. June 2015. (Format: TXT, HTML) (Obsoletes RFC5539) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7589) 7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, T. Alkemade. June 2015. (Format: TXT, HTML) (Updates RFC6120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7590) 7591 OAuth 2.0 Dynamic Client Registration Protocol. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7591) 7592 OAuth 2.0 Dynamic Client Registration Management Protocol. J. Richer, Ed., M. Jones, J. Bradley, M. Machulak. July 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7592) 7593 The eduroam Architecture for Network Roaming. K. Wierenga, S. Winter, T. Wolniewicz. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7593) 7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP). P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7594) 7595 Guidelines and Registration Procedures for URI Schemes. D. Thaler, Ed., T. Hansen, T. Hardie. June 2015. (Format: TXT, HTML) (Obsoletes RFC4395) (Updated by RFC8615) (Also BCP0035) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7595) 7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7596) 7597 Mapping of Address and Port with Encapsulation (MAP-E). O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed.. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7597) 7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients. T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. July 2015. (Format: TXT, HTML) (Updated by RFC8539) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7598) 7599 Mapping of Address and Port using Translation (MAP-T). X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7599) 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd). R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen. July 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7600) 7601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. August 2015. (Format: TXT, HTML) (Obsoletes RFC7001, RFC7410) (Obsoleted by RFC8601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7601) 7602 IS-IS Extended Sequence Number TLV. U. Chunduri, W. Lu, A. Tian, N. Shen. July 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7602) 7603 Energy Management (EMAN) Applicability Statement. B. Schoening, M. Chandramouli, B. Nordman. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7603) 7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP). M. Westerlund, T. Zeng. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7604) 7605 Recommendations on Using Assigned Transport Port Numbers. J. Touch. August 2015. (Format: TXT, HTML) (Also BCP0165) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7605) 7606 Revised Error Handling for BGP UPDATE Messages. E. Chen, Ed., J. Scudder, Ed., P. Mohapatra, K. Patel. August 2015. (Format: TXT, HTML) (Updates RFC1997, RFC4271, RFC4360, RFC4456, RFC4760, RFC5543, RFC5701, RFC6368) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7606) 7607 Codification of AS 0 Processing. W. Kumari, R. Bush, H. Schiller, K. Patel. August 2015. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7607) 7608 IPv6 Prefix Length Recommendation for Forwarding. M. Boucadair, A. Petrescu, F. Baker. July 2015. (Format: TXT, HTML) (Also BCP0198) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7608) 7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol. M. Fox, C. Kassimis, J. Stevens. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7609) 7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers. F. Gont, W. Liu, G. Van de Velde. August 2015. (Format: TXT, HTML) (Also BCP0199) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7610) 7611 BGP ACCEPT_OWN Community Attribute. J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7611) 7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services. P. Fleming, I. McDonald. June 2015. (Format: TXT, HTML) (Obsoletes RFC3712) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7612) 7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords. P. Saint-Andre, A. Melnikov. August 2015. (Format: TXT, HTML) (Obsoletes RFC4013) (Obsoleted by RFC8265) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7613) 7614 Explicit Subscriptions for the REFER Method. R. Sparks. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7614) 7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields. J. Reschke. September 2015. (Format: TXT, HTML) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7615) 7616 HTTP Digest Access Authentication. R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer. September 2015. (Format: TXT, HTML) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7616) 7617 The 'Basic' HTTP Authentication Scheme. J. Reschke. September 2015. (Format: TXT, HTML) (Obsoletes RFC2617) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7617) 7618 Dynamic Allocation of Shared IPv4 Addresses. Y. Cui, Q. Sun, I. Farrer, Y. Lee, Q. Sun, M. Boucadair. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7618) 7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2). V. Smyslov, P. Wouters. August 2015. (Format: TXT, HTML) (Updates RFC4301) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7619) 7620 Scenarios with Host Identification Complications. M. Boucadair, Ed., B. Chatras, T. Reddy, B. Williams, B. Sarikaya. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7620) 7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework. A.B. Roach. August 2015. (Format: TXT, HTML) (Updates RFC6665) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7621) 7622 Extensible Messaging and Presence Protocol (XMPP): Address Format. P. Saint-Andre. September 2015. (Format: TXT, HTML) (Obsoletes RFC6122) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7622) 7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN). A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. Henderickx. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7623) 7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement. R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7624) 7625 Architecture of an IP/MPLS Network with Hardened Pipes. J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, M. Chen. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7625) 7626 DNS Privacy Considerations. S. Bortzmeyer. August 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7626) 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension. K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray. September 2015. (Format: TXT, HTML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7627) 7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth. W. Mills, T. Showalter, H. Tschofenig. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7628) 7629 Flow-Binding Support for Mobile IP. S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu. August 2015. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7629) 7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3. J. Merkle, Ed., M. Lochter. October 2015. (Format: TXT, HTML) (Obsoleted by RFC7860) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7630) 7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format. C. Dearlove, T. Clausen. September 2015. (Format: TXT, HTML) (Updates RFC5444) (Updated by RFC7722) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7631) 7632 Endpoint Security Posture Assessment: Enterprise Use Cases. D. Waltermire, D. Harrington. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7632) 7633 X.509v3 Transport Layer Security (TLS) Feature Extension. P. Hallam-Baker. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7633) 7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec. Y. Nir. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7634) 7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization. T. Reddy, P. Patil, R. Ravindranath, J. Uberti. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7635) 7636 Proof Key for Code Exchange by OAuth Public Clients. N. Sakimura, Ed., J. Bradley, N. Agarwal. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7636) 7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation. P. Garg, Ed., Y. Wang, Ed.. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7637) 7638 JSON Web Key (JWK) Thumbprint. M. Jones, N. Sakimura. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7638) 7639 The ALPN HTTP Header Field. A. Hutton, J. Uberti, M. Thomson. August 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7639) 7640 Traffic Management Benchmarking. B. Constantine, R. Krishnan. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7640) 7641 Observing Resources in the Constrained Application Protocol (CoAP). K. Hartke. September 2015. (Format: TXT, HTML) (Updated by RFC8323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7641) 7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements. K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7642) 7643 System for Cross-domain Identity Management: Core Schema. P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7643) 7644 System for Cross-domain Identity Management: Protocol. P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7644) 7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis. U. Chunduri, A. Tian, W. Lu. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7645) 7646 Definition and Use of DNSSEC Negative Trust Anchors. P. Ebersman, W. Kumari, C. Griffiths, J. Livingood, R. Weber. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7646) 7647 Clarifications for the Use of REFER with RFC 6665. R. Sparks, A.B. Roach. September 2015. (Format: TXT, HTML) (Updates RFC3515) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7647) 7648 Port Control Protocol (PCP) Proxy Function. S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7648) 7649 The Jabber Scribe Role at IETF Meetings. P. Saint-Andre, D. York. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7649) 7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). J. Jimenez, J. Lopez-Vega, J. Maenpaa, G. Camarillo. September 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7650) 7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2). A. Dodd-Noble, S. Gundavelli, J. Korhonen, F. Baboescu, B. Weis. September 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7651) 7652 Port Control Protocol (PCP) Authentication Mechanism. M. Cullen, S. Hartman, D. Zhang, T. Reddy. September 2015. (Format: TXT, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7652) 7653 DHCPv6 Active Leasequery. D. Raghuvanshi, K. Kinnear, D. Kukrety. October 2015. (Format: TXT, HTML) (Updates RFC5460) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7653) 7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU). S. Banks, F. Calabria, G. Czirjak, R. Machat. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7654) 7655 RTP Payload Format for G.711.0. M. Ramalho, Ed., P. Jones, N. Harada, M. Perumal, L. Miao. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7655) 7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources. J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed.. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7656) 7657 Differentiated Services (Diffserv) and Real-Time Communication. D. Black, Ed., P. Jones. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7657) 7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs). S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. October 2015. (Format: TXT, HTML) (Obsoletes RFC4008) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7658) 7659 Definitions of Managed Objects for Network Address Translators (NATs). S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7659) 7660 Diameter Congestion and Filter Attributes. L. Bertz, S. Manning, B. Hirschman. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7660) 7661 Updating TCP to Support Rate-Limited Traffic. G. Fairhurst, A. Sathiaseelan, R. Secchi. October 2015. (Format: TXT, HTML) (Obsoletes RFC2861) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7661) 7662 OAuth 2.0 Token Introspection. J. Richer, Ed.. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7662) 7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI). B. Trammell, Ed., M. Kuehlewind, Ed.. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7663) 7664 Dragonfly Key Exchange. D. Harkins, Ed.. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7664) 7665 Service Function Chaining (SFC) Architecture. J. Halpern, Ed., C. Pignataro, Ed.. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7665) 7666 Management Information Base for Virtual Machines Controlled by a Hypervisor. H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. Tsou. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7666) 7667 RTP Topologies. M. Westerlund, S. Wenger. November 2015. (Format: TXT, HTML) (Obsoletes RFC5117) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7667) 7668 IPv6 over BLUETOOTH(R) Low Energy. J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7668) 7669 Assigning Digital Object Identifiers to RFCs. J. Levine. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7669) 7670 Generic Raw Public-Key Support for IKEv2. T. Kivinen, P. Wouters, H. Tschofenig. January 2016. (Format: TXT, HTML) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7670) 7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance. V. Dukhovni, W. Hardaker. October 2015. (Format: TXT, HTML) (Updates RFC6698) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7671) 7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). V. Dukhovni, W. Hardaker. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7672) 7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records. T. Finch, M. Miller, P. Saint-Andre. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7673) 7674 Clarification of the Flowspec Redirect Extended Community. J. Haas, Ed.. October 2015. (Format: TXT, HTML) (Updates RFC5575) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7674) 7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness. M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7675) 7676 IPv6 Support for Generic Routing Encapsulation (GRE). C. Pignataro, R. Bonica, S. Krishnan. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7676) 7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms. T. Hansen. November 2015. (Format: TXT, HTML) (Updates RFC5802) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7677) 7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions. C. Zhou, T. Taylor, Q. Sun, M. Boucadair. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7678) 7679 A One-Way Delay Metric for IP Performance Metrics (IPPM). G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. January 2016. (Format: TXT, HTML) (Obsoletes RFC2679) (Also STD0081) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7679) 7680 A One-Way Loss Metric for IP Performance Metrics (IPPM). G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. January 2016. (Format: TXT, HTML) (Obsoletes RFC2680) (Also STD0082) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7680) 7681 Email Exchange of Secondary School Transcripts. J. Davin. October 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7681) 7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration. D. McPherson, S. Amante, E. Osterweil, L. Blunk, D. Mitchell. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7682) 7683 Diameter Overload Indication Conveyance. J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand. October 2015. (Format: TXT, HTML) (Updated by RFC8581) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7683) 7684 OSPFv2 Prefix/Link Attribute Advertisement. P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7684) 7685 A Transport Layer Security (TLS) ClientHello Padding Extension. A. Langley. October 2015. (Format: TXT, HTML) (Updates RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7685) 7686 The ".onion" Special-Use Domain Name. J. Appelbaum, A. Muffett. October 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7686) 7687 Report from the Strengthening the Internet (STRINT) Workshop. S. Farrell, R. Wenning, B. Bos, M. Blanchet, H. Tschofenig. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7687) 7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks. Y. Lee, Ed., G. Bernstein, Ed.. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7688) 7689 Signaling Extensions for Wavelength Switched Optical Networks. G. Bernstein, Ed., S. Xu, Y. Lee, Ed., G. Martinelli, H. Harai. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7689) 7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)). M. Byerly, M. Hite, J. Jaeggli. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7690) 7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members. S. Bradner, Ed.. November 2015. (Format: TXT, HTML) (Obsoleted by RFC8711) (Updates RFC4071) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7691) 7692 Compression Extensions for WebSocket. T. Yoshino. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7692) 7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC). M-J. Saarinen, Ed., J-P. Aumasson. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7693) 7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding. J. Reschke. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7694) 7695 Distributed Prefix Assignment Algorithm. P. Pfister, B. Paterson, J. Arkko. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7695) 7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms. R. Housley. November 2015. (Format: TXT, HTML) (Also BCP0201) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7696) 7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB). P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7697) 7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. O. Gonzalez de Dios, Ed., R. Casellas, Ed., F. Zhang, X. Fu, D. Ceccarelli, I. Hussain. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7698) 7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers. A. Farrel, D. King, Y. Li, F. Zhang. November 2015. (Format: TXT, HTML) (Updates RFC3471, RFC6205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7699) 7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames. P. Saint-Andre. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8266) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7700) 7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP). A. Niemi, M. Garcia-Martin, G. Sandbakken. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7701) 7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat. P. Saint-Andre, S. Ibarra, S. Loreto. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7702) 7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T). E. Cordeiro, R. Carnier, A. Moreiras. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7703) 7704 An IETF with Much Diversity and Professional Conduct. D. Crocker, N. Clark. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7704) 7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute. W. George, S. Amante. November 2015. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7705) 7706 Decreasing Access Time to Root Servers by Running One on Loopback. W. Kumari, P. Hoffman. November 2015. (Format: TXT, HTML) (Obsoleted by RFC8806) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7706) 7707 Network Reconnaissance in IPv6 Networks. F. Gont, T. Chown. March 2016. (Format: TXT, HTML) (Obsoletes RFC5157) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7707) 7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator. T. Nadeau, L. Martini, S. Bryant. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7708) 7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). A. Malis, Ed., B. Wilson, G. Clapp, V. Shukla. November 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7709) 7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs). W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8910) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7710) 7711 PKIX over Secure HTTP (POSH). M. Miller, P. Saint-Andre. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7711) 7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). P. Saint-Andre, M. Miller, P. Hancke. November 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7712) 7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements. M. Mathis, B. Briscoe. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7713) 7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP). D. McGrew, K. Igoe. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7714) 7715 Multipoint LDP (mLDP) Node Protection. IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7715) 7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures. J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7716) 7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). K. Pentikousis, Ed., E. Zhang, Y. Cui. December 2015. (Format: TXT, HTML) (Updates RFC4656, RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7717) 7718 Registries for the One-Way Active Measurement Protocol (OWAMP). A. Morton. December 2015. (Format: TXT, HTML) (Updates RFC4656) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7718) 7719 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. December 2015. (Format: TXT, HTML) (Obsoleted by RFC8499) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7719) 7720 DNS Root Name Service Protocol and Deployment Requirements. M. Blanchet, L-J. Liman. December 2015. (Format: TXT, HTML) (Obsoletes RFC2870) (Also BCP0040) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7720) 7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms. A. Cooper, F. Gont, D. Thaler. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7721) 7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2). C. Dearlove, T. Clausen. December 2015. (Format: TXT, HTML) (Updates RFC7188, RFC7631) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7722) 7723 Port Control Protocol (PCP) Anycast Addresses. S. Kiesel, R. Penno. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7723) 7724 Active DHCPv4 Lease Query. K. Kinnear, M. Stapp, B. Volz, N. Russell. December 2015. (Format: TXT, HTML) (Updates RFC6926) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7724) 7725 An HTTP Status Code to Report Legal Obstacles. T. Bray. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7725) 7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs). V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin. January 2016. (Format: TXT, HTML) (Updates RFC5884) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7726) 7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP). M. Zhang, H. Wen, J. Hu. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7727) 7728 RTP Stream Pause and Resume. B. Burman, A. Akram, R. Even, M. Westerlund. February 2016. (Format: TXT, HTML) (Updates RFC5104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7728) 7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management. B. Khasnabish, E. Haleplidis, J. Hadi Salim, Ed.. December 2015. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7729) 7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. January 2016. (Format: TXT, HTML) (Obsoletes RFC6490) (Obsoleted by RFC8630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7730) 7731 Multicast Protocol for Low-Power and Lossy Networks (MPL). J. Hui, R. Kelsey. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7731) 7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL). P. van der Stok, R. Cragie. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7732) 7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control. A. Brandt, E. Baccelli, R. Cragie, P. van der Stok. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7733) 7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN). D. Allan, Ed., J. Tantsura, D. Fedyk, A. Sajassi. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7734) 7735 Tracking Reviews of Documents. R. Sparks, T. Kivinen. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7735) 7736 Content Delivery Network Interconnection (CDNI) Media Type Registration. K. Ma. December 2015. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7736) 7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification. N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen. January 2016. (Format: TXT, HTML) (Updates RFC7110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7737) 7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS). M. Blanchet, A. Schiltknecht, P. Shames. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7738) 7739 Security Implications of Predictable Fragment Identification Values. F. Gont. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7739) 7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication. Z. Zhang, Y. Rekhter, A. Dolganow. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7740) 7741 RTP Payload Format for VP8 Video. P. Westin, H. Lundin, M. Glover, J. Uberti, F. Galligan. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7741) 7742 WebRTC Video Processing and Codec Requirements. A.B. Roach. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7742) 7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping. J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed.. January 2016. (Format: TXT, HTML) (Updates RFC4379) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7743) 7744 Use Cases for Authentication and Authorization in Constrained Environments. L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7744) 7745 XML Schemas for Reverse DNS Management. T. Manderson. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7745) 7746 Label Switched Path (LSP) Self-Ping. R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki. January 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7746) 7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence. R. Papneja, B. Parise, S. Hares, D. Lee, I. Varlashkin. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7747) 7748 Elliptic Curves for Security. A. Langley, M. Hamburg, S. Turner. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7748) 7749 The "xml2rfc" Version 2 Vocabulary. J. Reschke. February 2016. (Format: TXT, HTML) (Obsoletes RFC2629) (Obsoleted by RFC7991) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7749) 7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP). J. Hedin, G. Mirsky, S. Baillargeon. February 2016. (Format: TXT, HTML) (Updates RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7750) 7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs). S. Sorce, T. Yu. March 2016. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7751) 7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP. H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7752) 7753 Port Control Protocol (PCP) Extension for Port-Set Allocation. Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7753) 7754 Technical Considerations for Internet Service Blocking and Filtering. R. Barnes, A. Cooper, O. Kolkman, D. Thaler, E. Nordmark. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7754) 7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments. T. Anderson. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7755) 7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode. T. Anderson, S. Steffann. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7756) 7757 Explicit Address Mappings for Stateless IP/ICMP Translation. T. Anderson, A. Leiva Popper. February 2016. (Format: TXT, HTML) (Updates RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7757) 7758 Time Capability in NETCONF. T. Mizrahi, Y. Moses. February 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7758) 7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping. E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, J. Drake. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7759) 7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics. R. Housley. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7760) 7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng. March 2016. (Format: TXT, HTML) (Obsoletes RFC4601) (Updated by RFC8736) (Also STD0083) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC7761) 7762 Initial Assignment for the Content Security Policy Directives Registry. M. West. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7762) 7763 The text/markdown Media Type. S. Leonard. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7763) 7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations. S. Leonard. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7764) 7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart. P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl. February 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7765) 7766 DNS Transport over TCP - Implementation Requirements. J. Dickinson, S. Dickinson, R. Bellis, A. Mankin, D. Wessels. March 2016. (Format: TXT, HTML) (Obsoletes RFC5966) (Updates RFC1035, RFC1123) (Updated by RFC8490) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7766) 7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP). S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7767) 7768 Port Management to Reduce Logging in Large-Scale NATs. T. Tsou, W. Li, T. Taylor, J. Huang. January 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7768) 7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire. S. Sivabalan, S. Boutros, H. Shah, S. Aldrin, M. Venkatesan. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7769) 7770 Extensions to OSPF for Advertising Optional Router Capabilities. A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. February 2016. (Format: TXT, HTML) (Obsoletes RFC4970) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7770) 7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires. A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro. January 2016. (Format: TXT, HTML) (Updates RFC6870) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7771) 7772 Reducing Energy Consumption of Router Advertisements. A. Yourtchenko, L. Colitti. February 2016. (Format: TXT, HTML) (Also BCP0202) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7772) 7773 Authentication Context Certificate Extension. S. Santesson. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7773) 7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6. Y. Doi, M. Gillmore. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7774) 7775 IS-IS Route Preference for Extended IP and IPv6 Reachability. L. Ginsberg, S. Litkowski, S. Previdi. February 2016. (Format: TXT, HTML) (Updates RFC5308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7775) 7776 IETF Anti-Harassment Procedures. P. Resnick, A. Farrel. March 2016. (Format: TXT, HTML) (Updates RFC2418) (Updated by RFC8716) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7776) 7777 Advertising Node Administrative Tags in OSPF. S. Hegde, R. Shakir, A. Smirnov, Z. Li, B. Decraene. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7777) 7778 Mobile Communication Congestion Exposure Scenario. D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7778) 7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2). H. Rogge, E. Baccelli. April 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7779) 7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang, R. Perlman, A. Banerjee, A. Ghanwani, S. Gupta. February 2016. (Format: TXT, HTML) (Obsoletes RFC7180) (Updates RFC6325, RFC7177, RFC7179) (Updated by RFC8249) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7780) 7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access. H. Zhai, T. Senevirathne, R. Perlman, M. Zhang, Y. Li. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7781) 7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments. M. Zhang, R. Perlman, H. Zhai, M. Durrani, S. Gupta. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7782) 7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL). T. Senevirathne, J. Pathangi, J. Hudson. February 2016. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7783) 7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB. D. Kumar, S. Salam, T. Senevirathne. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7784) 7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite. S. Vinapamula, M. Boucadair. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7785) 7786 TCP Modifications for Congestion Exposure (ConEx). M. Kuehlewind, Ed., R. Scheffenegger. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7786) 7787 Distributed Node Consensus Protocol. M. Stenberg, S. Barth. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7787) 7788 Home Networking Control Protocol. M. Stenberg, S. Barth, P. Pfister. April 2016. (Format: TXT, HTML) (Updated by RFC8375) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7788) 7789 Impact of BGP Filtering on Inter-Domain Routing Policies. C. Cardona, P. Francois, P. Lucente. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7789) 7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS). Y. Yoneya, T. Nemoto. February 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7790) 7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2). D. Migault, Ed., V. Smyslov. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7791) 7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, D. Ceccarelli. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7792) 7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry. M. Andrews. May 2016. (Format: TXT, HTML) (Also BCP0163) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7793) 7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability. L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7794) 7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE). J. Dong, H. Wang. February 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7795) 7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS). Y. Jiang, Ed., L. Yong, M. Paul. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7796) 7797 JSON Web Signature (JWS) Unencoded Payload Option. M. Jones. February 2016. (Format: TXT, HTML) (Updates RFC7519) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7797) 7798 RTP Payload Format for High Efficiency Video Coding (HEVC). Y.-K. Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7798) 7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between). A. Morton. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7799) 7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs). M. Jones, J. Bradley, H. Tschofenig. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7800) 7801 GOST R 34.12-2015: Block Cipher "Kuznyechik". V. Dolmatov, Ed.. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7801) 7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism. S. Emery, N. Williams. March 2016. (Format: TXT, HTML) (Obsoletes RFC4402) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7802) 7803 Changing the Registration Policy for the NETCONF Capability URNs Registry. B. Leiba. February 2016. (Format: TXT, HTML) (Updates RFC6241) (Also BCP0203) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7803) 7804 Salted Challenge Response HTTP Authentication Mechanism. A. Melnikov. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7804) 7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status. A. Zimmermann, W. Eddy, L. Eggert. April 2016. (Format: TXT, HTML) (Obsoletes RFC0675, RFC0721, RFC0761, RFC0813, RFC0816, RFC0879, RFC0896, RFC1078, RFC6013) (Updates RFC7414) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7805) 7806 On Queuing, Marking, and Dropping. F. Baker, R. Pan. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7806) 7807 Problem Details for HTTP APIs. M. Nottingham, E. Wilde. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7807) 7808 Time Zone Data Distribution Service. M. Douglass, C. Daboo. March 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7808) 7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference. C. Daboo. March 2016. (Format: TXT, HTML) (Updates RFC4791) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7809) 7810 IS-IS Traffic Engineering (TE) Metric Extensions. S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. May 2016. (Format: TXT, HTML) (Obsoleted by RFC8570) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7810) 7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR). G. Enyedi, A. Csaszar, A. Atlas, C. Bowers, A. Gopalan. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7811) 7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR). A. Atlas, C. Bowers, G. Enyedi. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7812) 7813 IS-IS Path Control and Reservation. J. Farkas, Ed., N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, C. Bowers. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7813) 7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution. X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7814) 7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation. T. Kivinen. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7815) 7816 DNS Query Name Minimisation to Improve Privacy. S. Bortzmeyer. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7816) 7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols. A. Melnikov. March 2016. (Format: TXT, HTML) (Updates RFC2595, RFC3207, RFC3501, RFC5804) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7817) 7818 URN Namespace for MEF Documents. M. Jethanandani. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7818) 7819 Privacy Considerations for DHCP. S. Jiang, S. Krishnan, T. Mrugalski. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7819) 7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP). T. Mizrahi. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7820) 7821 UDP Checksum Complement in the Network Time Protocol (NTP). T. Mizrahi. March 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7821) 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields. T. Mizrahi, D. Mayer. March 2016. (Format: TXT, HTML) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7822) 7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions. A. Atlas, J. Drake, S. Giacalone, S. Previdi. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7823) 7824 Privacy Considerations for DHCPv6. S. Krishnan, T. Mrugalski, S. Jiang. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7824) 7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP). J. Goldberg, M. Westerlund, T. Zeng. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7825) 7826 Real-Time Streaming Protocol Version 2.0. H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed.. December 2016. (Format: TXT, HTML) (Obsoletes RFC2326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7826) 7827 The Role of the IRTF Chair. L. Eggert. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7827) 7828 The edns-tcp-keepalive EDNS0 Option. P. Wouters, J. Abley, S. Dickinson, R. Bellis. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7828) 7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol. Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7829) 7830 The EDNS(0) Padding Option. A. Mayrhofer. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7830) 7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture. J. Howlett, S. Hartman, H. Tschofenig, J. Schaad. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7831) 7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases. R. Smith, Ed.. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7832) 7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML). J. Howlett, S. Hartman, A. Perez-Mendez, Ed.. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7833) 7834 Locator/ID Separation Protocol (LISP) Impact. D. Saucez, L. Iannone, A. Cabellos, F. Coras. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7834) 7835 Locator/ID Separation Protocol (LISP) Threat Analysis. D. Saucez, L. Iannone, O. Bonaventure. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7835) 7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012. S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov, S. Leontiev, V. Podobaev, D. Belyavsky. March 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7836) 7837 IPv6 Destination Option for Congestion Exposure (ConEx). S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7837) 7838 HTTP Alternative Services. M. Nottingham, P. McManus, J. Reschke. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7838) 7839 Access-Network-Identifier Option in DHCP. S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7839) 7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol. J. Winterbottom, H. Tschofenig, L. Liess. May 2016. (Format: TXT, HTML) (Updates RFC5985, RFC6881) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7840) 7841 RFC Streams, Headers, and Boilerplates. J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed.. May 2016. (Format: TXT, HTML) (Obsoletes RFC5741) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7841) 7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool. R. Sparks. April 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7842) 7843 Port Control Protocol (PCP) Third-Party ID Option. A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva. May 2016. (Format: TXT, HTML) (Updates RFC6887) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7843) 7844 Anonymity Profiles for DHCP Clients. C. Huitema, T. Mrugalski, S. Krishnan. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7844) 7845 Ogg Encapsulation for the Opus Audio Codec. T. Terriberry, R. Lee, R. Giles. April 2016. (Format: TXT, HTML) (Updates RFC5334) (Updated by RFC8486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7845) 7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP). R. Cruz, M. Nunes, J. Xia, R. Huang, Ed., J. Taveira, D. Lingli. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7846) 7847 Logical-Interface Support for IP Hosts with Multi-Access Support. T. Melia, Ed., S. Gundavelli, Ed.. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7847) 7848 Mark and Signed Mark Objects Mapping. G. Lozano. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7848) 7849 An IPv6 Profile for 3GPP Mobile Devices. D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7849) 7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles. S. Nandakumar. April 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7850) 7851 Peer-to-Peer (P2P) Overlay Diagnostics. H. Song, X. Jiang, R. Even, D. Bryan, Y. Sun. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7851) 7852 Additional Data Related to an Emergency Call. R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom. July 2016. (Format: TXT, HTML) (Updates RFC6443, RFC6881) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7852) 7853 A URN Namespace for Globus. S. Martin, S. Tuecke, B. McCollam, M. Lidman. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7853) 7854 BGP Monitoring Protocol (BMP). J. Scudder, Ed., R. Fernando, S. Stuart. June 2016. (Format: TXT, HTML) (Updated by RFC8671) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7854) 7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements. S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7855) 7856 Softwire Mesh Management Information Base (MIB). Y. Cui, J. Dong, P. Wu, M. Xu, A. Yla-Jaaski. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7856) 7857 Updates to Network Address Translation (NAT) Behavioral Requirements. R. Penno, S. Perreault, M. Boucadair, Ed., S. Sivakumar, K. Naito. April 2016. (Format: TXT, HTML) (Updates RFC4787, RFC5382, RFC5508) (Also BCP0127) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7857) 7858 Specification for DNS over Transport Layer Security (TLS). Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman. May 2016. (Format: TXT, HTML) (Updated by RFC8310) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7858) 7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols. C. Dearlove. May 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7859) 7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3. J. Merkle, Ed., M. Lochter. April 2016. (Format: TXT, HTML) (Obsoletes RFC7630) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7860) 7861 Remote Procedure Call (RPC) Security Version 3. A. Adamson, N. Williams. November 2016. (Format: TXT, HTML) (Updates RFC5403) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7861) 7862 Network File System (NFS) Version 4 Minor Version 2 Protocol. T. Haynes. November 2016. (Format: TXT, HTML) (Updated by RFC8178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7862) 7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description. T. Haynes. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7863) 7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility. CJ. Bernardos, Ed.. May 2016. (Format: TXT, HTML) (Updates RFC5213) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7864) 7865 Session Initiation Protocol (SIP) Recording Metadata. R. Ravindranath, P. Ravindran, P. Kyzivat. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7865) 7866 Session Recording Protocol. L. Portman, H. Lum, Ed., C. Eckel, A. Johnston, A. Hutton. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7866) 7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications. R. Huang. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7867) 7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP). D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. White. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7868) 7869 The "vnc" URI Scheme. D. Warden, I. Iordanov. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7869) 7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs). Y. Fu, S. Jiang, J. Dong, Y. Chen. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7870) 7871 Client Subnet in DNS Queries. C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7871) 7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World. F. Gont, J. Linkova, T. Chown, W. Liu. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7872) 7873 Domain Name System (DNS) Cookies. D. Eastlake 3rd, M. Andrews. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7873) 7874 WebRTC Audio Codec and Processing Requirements. JM. Valin, C. Bran. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7874) 7875 Additional WebRTC Audio Codecs for Interoperability. S. Proust, Ed.. May 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7875) 7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks. S. Bryant, S. Sivabalan, S. Soni. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7876) 7877 Session Peering Provisioning Framework (SPPF). K. Cartwright, V. Bhatia, S. Ali, D. Schwartz. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7877) 7878 Session Peering Provisioning (SPP) Protocol over SOAP. K. Cartwright, V. Bhatia, J-F. Mule, A. Mayrhofer. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7878) 7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents. R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7879) 7880 Seamless Bidirectional Forwarding Detection (S-BFD). C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S. Pallagatti. July 2016. (Format: TXT, HTML) (Updates RFC5880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7880) 7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS. C. Pignataro, D. Ward, N. Akiya. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7881) 7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases. S. Aldrin, C. Pignataro, G. Mirsky, N. Kumar. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7882) 7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS. L. Ginsberg, N. Akiya, M. Chen. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7883) 7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators. C. Pignataro, M. Bhatia, S. Aldrin, T. Ranganath. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7884) 7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV). V. Govindan, C. Pignataro. July 2016. (Format: TXT, HTML) (Updates RFC5885) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7885) 7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3). V. Govindan, C. Pignataro. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7886) 7887 Hierarchical Join/Prune Attributes. S. Venaas, J. Arango, I. Kouvelas. June 2016. (Format: TXT, HTML) (Updates RFC5384) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7887) 7888 IMAP4 Non-synchronizing Literals. A. Melnikov, Ed.. May 2016. (Format: TXT, HTML) (Obsoletes RFC2088) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7888) 7889 The IMAP APPENDLIMIT Extension. J. SrimushnamBoovaraghamoorthy, N. Bisht. May 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7889) 7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP). D. Bryan, P. Matthews, E. Shim, D. Willis, S. Dawkins. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7890) 7891 Explicit Reverse Path Forwarding (RPF) Vector. J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, V. Arya. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7891) 7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry. Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. May 2016. (Format: TXT, HTML) (Updates RFC7139) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7892) 7893 Pseudowire Congestion Considerations. Y(J) Stein, D. Black, B. Briscoe. June 2016. (Format: TXT, PDF, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7893) 7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport. M. Pritikin, C. Wallace. June 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7894) 7895 YANG Module Library. A. Bierman, M. Bjorklund, K. Watsen. June 2016. (Format: TXT, HTML) (Obsoleted by RFC8525) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7895) 7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP). D. Dhody. June 2016. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7896) 7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP). D. Dhody, U. Palle, R. Casellas. June 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7897) 7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE). D. Dhody, U. Palle, V. Kondreddy, R. Casellas. June 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7898) 7899 Multicast VPN State Damping. T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas. June 2016. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7899) 7900 Extranet Multicast in BGP/IP MPLS VPNs. Y. Rekhter, Ed., E. Rosen, Ed., R. Aggarwal, Y. Cai, T. Morin. June 2016. (Format: TXT, HTML) (Updates RFC6513, RFC6514, RFC6625) (Updated by RFC8534) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7900) 7901 CHAIN Query Requests in DNS. P. Wouters. June 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7901) 7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags. E. Rosen, T. Morin. June 2016. (Format: TXT, HTML) (Updates RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7902) 7903 Windows Image Media Types. S. Leonard. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7903) 7904 A SIP Usage for REsource LOcation And Discovery (RELOAD). C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed.. October 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7904) 7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS). A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson. June 2016. (Format: TXT, HTML) (Updates RFC5246, RFC6347) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7905) 7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes. P. Timmel, R. Housley, S. Turner. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7906) 7907 Not Issued. 7908 Problem Definition and Classification of BGP Route Leaks. K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7908) 7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures. R. Kisteleki, B. Haberman. June 2016. (Format: TXT, HTML) (Updates RFC2622, RFC4012) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7909) 7910 Interoperability between the Virtual Router Redundancy Protocol and PIM. W. Zhou. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7910) 7911 Advertisement of Multiple Paths in BGP. D. Walton, A. Retana, E. Chen, J. Scudder. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7911) 7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure. A. Melnikov. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7912) 7913 P-Access-Network-Info ABNF Update. C. Holmberg. June 2016. (Format: TXT, HTML) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7913) 7914 The scrypt Password-Based Key Derivation Function. C. Percival, S. Josefsson. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7914) 7915 IP/ICMP Translation Algorithm. C. Bao, X. Li, F. Baker, T. Anderson, F. Gont. June 2016. (Format: TXT, HTML) (Obsoletes RFC6145) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7915) 7916 Operational Management of Loop-Free Alternates. S. Litkowski, Ed., B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7916) 7917 Advertising Node Administrative Tags in IS-IS. P. Sarkar, Ed., H. Gredler, S. Hegde, S. Litkowski, B. Decraene. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7917) 7918 Transport Layer Security (TLS) False Start. A. Langley, N. Modadugu, B. Moeller. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7918) 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS). D. Gillmor. August 2016. (Format: TXT, HTML) (Updates RFC2246, RFC4346, RFC4492, RFC5246) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7919) 7920 Problem Statement for the Interface to the Routing System. A. Atlas, Ed., T. Nadeau, Ed., D. Ward. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7920) 7921 An Architecture for the Interface to the Routing System. A. Atlas, J. Halpern, S. Hares, D. Ward, T. Nadeau. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7921) 7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model. J. Clarke, G. Salgueiro, C. Pignataro. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7922) 7923 Requirements for Subscription to YANG Datastores. E. Voit, A. Clemm, A. Gonzalez Prieto. June 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7923) 7924 Transport Layer Security (TLS) Cached Information Extension. S. Santesson, H. Tschofenig. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7924) 7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things. H. Tschofenig, Ed., T. Fossati. July 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7925) 7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks. A. Farrel, Ed., J. Drake, N. Bitar, G. Swallow, D. Ceccarelli, X. Zhang. July 2016. (Format: TXT, HTML) (Also BCP0206) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7926) 7927 Information-Centric Networking (ICN) Research Challenges. D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7927) 7928 Characterization Guidelines for Active Queue Management (AQM). N. Kuhn, Ed., P. Natarajan, Ed., N. Khademi, Ed., D. Ros. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7928) 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. P. Wouters. August 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7929) 7930 Larger Packets for RADIUS over TCP. S. Hartman. August 2016. (Format: TXT, HTML) (Updates RFC6613) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7930) 7931 NFSv4.0 Migration: Specification Update. D. Noveck, Ed., P. Shivam, C. Lever, B. Baker. July 2016. (Format: TXT, HTML) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7931) 7932 Brotli Compressed Data Format. J. Alakuijala, Z. Szabadka. July 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7932) 7933 Adaptive Video Streaming over Information-Centric Networking (ICN). C. Westphal, Ed., S. Lederer, D. Posch, C. Timmerer, A. Azgin, W. Liu, C. Mueller, A. Detti, D. Corujo, J. Wang, M. Montpetit, N. Murray. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7933) 7934 Host Address Availability Recommendations. L. Colitti, V. Cerf, S. Cheshire, D. Schinazi. July 2016. (Format: TXT, HTML) (Also BCP0204) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7934) 7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure. G. Huston, G. Michaelson, Ed.. August 2016. (Format: TXT, HTML) (Obsoletes RFC6485) (Updated by RFC8208, RFC8608) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7935) 7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry. T. Hardie. July 2016. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7936) 7937 Content Distribution Network Interconnection (CDNI) Logging Interface. F. Le Faucheur, Ed., G. Bertrand, Ed., I. Oprescu, Ed., R. Peterkofsky. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7937) 7938 Use of BGP for Routing in Large-Scale Data Centers. P. Lapukhov, A. Premji, J. Mitchell, Ed.. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7938) 7939 Definition of Managed Objects for the Neighborhood Discovery Protocol. U. Herberg, R. Cole, I. Chakeres, T. Clausen. August 2016. (Format: TXT, HTML) (Obsoletes RFC6779) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7939) 7940 Representing Label Generation Rulesets Using XML. K. Davies, A. Freytag. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7940) 7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items. M. Westerlund, B. Burman, R. Even, M. Zanaty. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7941) 7942 Improving Awareness of Running Code: The Implementation Status Section. Y. Sheffer, A. Farrel. July 2016. (Format: TXT, HTML) (Obsoletes RFC6982) (Also BCP0205) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7942) 7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). F. Gont, W. Liu. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7943) 7944 Diameter Routing Message Priority. S. Donovan. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7944) 7945 Information-Centric Networking: Evaluation and Security Considerations. K. Pentikousis, Ed., B. Ohlman, E. Davies, S. Spirou, G. Boggia. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7945) 7946 The GeoJSON Format. H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7946) 7947 Internet Exchange BGP Route Server. E. Jasinska, N. Hilliard, R. Raszuk, N. Bakker. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7947) 7948 Internet Exchange BGP Route Server Operations. N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7948) 7949 OSPFv3 over IPv4 for IPv6 Transition. I. Chen, A. Lindem, R. Atkinson. August 2016. (Format: TXT, HTML) (Updates RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7949) 7950 The YANG 1.1 Data Modeling Language. M. Bjorklund, Ed.. August 2016. (Format: TXT, HTML) (Updated by RFC8342, RFC8526) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7950) 7951 JSON Encoding of Data Modeled with YANG. L. Lhotka. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7951) 7952 Defining and Using Metadata with YANG. L. Lhotka. August 2016. (Format: TXT, HTML) (Updates RFC6110) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7952) 7953 Calendar Availability. C. Daboo, M. Douglass. August 2016. (Format: TXT, HTML) (Updates RFC4791, RFC5545, RFC6638) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7953) 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block. L. Iannone, D. Lewis, D. Meyer, V. Fuller. September 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7954) 7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block. L. Iannone, R. Jorgensen, D. Conrad, G. Huston. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7955) 7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway. W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7956) 7957 DISPATCH-Style Working Groups and the SIP Change Process. B. Campbell, Ed., A. Cooper, B. Leiba. August 2016. (Format: TXT, HTML) (Updates RFC5727) (Also BCP0067) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC7957) 7958 DNSSEC Trust Anchor Publication for the Root Zone. J. Abley, J. Schlyter, G. Bailey, P. Hoffman. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7958) 7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP). C. Bormann, Z. Shelby, Ed.. August 2016. (Format: TXT, HTML) (Updates RFC7252) (Updated by RFC8323) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7959) 7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows. F. Martin, Ed., E. Lear, Ed., T. Draegen. Ed., E. Zwicky, Ed., K. Andersen, Ed.. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7960) 7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV. D. Eastlake 3rd, L. Yizhou. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7961) 7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures. J. Saldana, Ed., A. Arcia-Moret, B. Braem, E. Pietrosemoli, A. Sathiaseelan, M. Zennaro. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7962) 7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs). Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7963) 7964 Solutions for BGP Persistent Route Oscillation. D. Walton, A. Retana, E. Chen, J. Scudder. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7964) 7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels. M. Chen, W. Cao, A. Takacs, P. Pan. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7965) 7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements. H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay. September 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7966) 7967 Constrained Application Protocol (CoAP) Option for No Server Response. A. Bhattacharyya, S. Bandyopadhyay, A. Pal, T. Bose. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7967) 7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data. Y. Li, D. Eastlake 3rd, W. Hao, H. Chen, S. Chatterjee. August 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7968) 7969 Customizing DHCP Configuration on the Basis of Network Topology. T. Lemon, T. Mrugalski. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7969) 7970 The Incident Object Description Exchange Format Version 2. R. Danyliw. November 2016. (Format: TXT, HTML) (Obsoletes RFC5070, RFC6685) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7970) 7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations. M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, S. Previdi. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7971) 7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition. P. Lemieux. September 2016. (Format: TXT, HTML) (Obsoletes RFC7302) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7972) 7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation. R. Droms, P. Duffy. November 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7973) 7974 An Experimental TCP Option for Host Identification. B. Williams, M. Boucadair, D. Wing. October 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC7974) 7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection. B. Niven-Jenkins, Ed., R. van Brandenburg, Ed.. October 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7975) 7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses. C. Holmberg, N. Biondic, G. Salgueiro. September 2016. (Format: TXT, HTML) (Updates RFC7315) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7976) 7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP). P. Dunkley, G. Llewellyn, V. Pascual, G. Salgueiro, R. Ravindranath. September 2016. (Format: TXT, HTML) (Updates RFC4975, RFC4976) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7977) 7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension. D. Eastlake 3rd, M. Umair, Y. Li. September 2016. (Format: TXT, HTML) (Updates RFC7178) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7978) 7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries. E. Lear, Ed., R. Housley, Ed.. August 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7979) 7980 A Framework for Defining Network Complexity. M. Behringer, A. Retana, R. White, G. Huston. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7980) 7981 IS-IS Extensions for Advertising Router Information. L. Ginsberg, S. Previdi, M. Chen. October 2016. (Format: TXT, HTML) (Obsoletes RFC4971) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7981) 7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN). P. Martinsen, T. Reddy, D. Wing, V. Singh. September 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7982) 7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS). M. Petit-Huguenin, G. Salgueiro. September 2016. (Format: TXT, HTML) (Updates RFC5764) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7983) 7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network. O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed.. September 2016. (Format: TXT, HTML) (Updates RFC3263) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7984) 7985 Security Threats to Simplified Multicast Forwarding (SMF). J. Yi, T. Clausen, U. Herberg. November 2016. (Format: TXT, HTML) (Updates RFC7186) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7985) 7986 New Properties for iCalendar. C. Daboo. October 2016. (Format: TXT, HTML) (Updates RFC5545) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7986) 7987 IS-IS Minimum Remaining Lifetime. L. Ginsberg, P. Wells, B. Decraene, T. Przygienda, H. Gredler. October 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7987) 7988 Ingress Replication Tunnels in Multicast VPN. E. Rosen, Ed., K. Subramanian, Z. Zhang. October 2016. (Format: TXT, HTML) (Updates RFC6513, RFC6514) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7988) 7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks. P. Jones, G. Salgueiro, C. Pearce, P. Giralt. October 2016. (Format: TXT, HTML) (Obsoletes RFC7329) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7989) 7990 RFC Format Framework. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7990) 7991 The "xml2rfc" Version 3 Vocabulary. P. Hoffman. December 2016. (Format: TXT, HTML) (Obsoletes RFC7749) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7991) 7992 HTML Format for RFCs. J. Hildebrand, Ed., P. Hoffman. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7992) 7993 Cascading Style Sheets (CSS) Requirements for RFCs. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7993) 7994 Requirements for Plain-Text RFCs. H. Flanagan. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7994) 7995 PDF Format for RFCs. T. Hansen, Ed., L. Masinter, M. Hardy. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7995) 7996 SVG Drawings for RFCs: SVG 1.2 RFC. N. Brownlee. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7996) 7997 The Use of Non-ASCII Characters in RFCs. H. Flanagan, Ed.. December 2016. (Format: TXT, PDF, HTML) (Updates RFC7322) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7997) 7998 "xml2rfc" Version 3 Preparation Tool Description. P. Hoffman, J. Hildebrand. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7998) 7999 BLACKHOLE Community. T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC7999) 8000 Requirements for NFSv4 Multi-Domain Namespace Deployment. A. Adamson, N. Williams. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8000) 8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information. F. Zhang, Ed., O. Gonzalez de Dios, Ed., C. Margaria, M. Hartley, Z. Ali. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8001) 8002 Host Identity Protocol Certificates. T. Heer, S. Varjonen. October 2016. (Format: TXT, HTML) (Obsoletes RFC6253) (Updates RFC7401) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8002) 8003 Host Identity Protocol (HIP) Registration Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT, HTML) (Obsoletes RFC5203) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8003) 8004 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. October 2016. (Format: TXT, HTML) (Obsoletes RFC5204) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8004) 8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension. J. Laganier. October 2016. (Format: TXT, HTML) (Obsoletes RFC5205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8005) 8006 Content Delivery Network Interconnection (CDNI) Metadata. B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8006) 8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers. R. Murray, B. Niven-Jenkins. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8007) 8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics. J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8008) 8009 AES Encryption with HMAC-SHA2 for Kerberos 5. M. Jenkins, M. Peck, K. Burgin. October 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8009) 8010 Internet Printing Protocol/1.1: Encoding and Transport. M. Sweet, I. McDonald. January 2017. (Format: TXT, HTML) (Obsoletes RFC2910, RFC3382) (Also STD0092) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8010) 8011 Internet Printing Protocol/1.1: Model and Semantics. M. Sweet, I. McDonald. January 2017. (Format: TXT, HTML) (Obsoletes RFC2911, RFC3381, RFC3382) (Also STD0092) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8011) 8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs). N. Akiya, G. Swallow, C. Pignataro, A. Malis, S. Aldrin. November 2016. (Format: TXT, HTML) (Updates RFC6790) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8012) 8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB). D. Joachimpillai, J. Hadi Salim. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8013) 8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3). D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten. December 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8014) 8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics. V. Singh, C. Perkins, A. Clark, R. Huang. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8015) 8016 Mobility with Traversal Using Relays around NAT (TURN). T. Reddy, D. Wing, P. Patil, P. Martinsen. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8016) 8017 PKCS #1: RSA Cryptography Specifications Version 2.2. K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch. November 2016. (Format: TXT, HTML) (Obsoletes RFC3447) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8017) 8018 PKCS #5: Password-Based Cryptography Specification Version 2.1. K. Moriarty, Ed., B. Kaliski, A. Rusch. January 2017. (Format: TXT, HTML) (Obsoletes RFC2898) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8018) 8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks. Y. Nir, V. Smyslov. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8019) 8020 NXDOMAIN: There Really Is Nothing Underneath. S. Bortzmeyer, S. Huque. November 2016. (Format: TXT, HTML) (Updates RFC1034, RFC2308) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8020) 8021 Generation of IPv6 Atomic Fragments Considered Harmful. F. Gont, W. Liu, T. Anderson. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8021) 8022 A YANG Data Model for Routing Management. L. Lhotka, A. Lindem. November 2016. (Format: TXT, HTML) (Obsoleted by RFC8349) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8022) 8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions. M. Thomas, A. Mankin, L. Zhang. November 2016. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8023) 8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS. Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8024) 8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch. P. Thubert, Ed., R. Cragie. November 2016. (Format: TXT, HTML) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8025) 8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism. M. Boucadair, I. Farrer. November 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8026) 8027 DNSSEC Roadblock Avoidance. W. Hardaker, O. Gudmundsson, S. Krishnaswamy. November 2016. (Format: TXT, HTML) (Also BCP0207) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8027) 8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network. F. Baker, B. Carpenter. November 2016. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8028) 8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures. K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen. March 2017. (Format: TXT, HTML) (Obsoletes RFC4379, RFC6424, RFC6829, RFC7537) (Updates RFC1122) (Updated by RFC8611) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8029) 8030 Generic Event Delivery Using HTTP Push. M. Thomson, E. Damaggio, B. Raymor, Ed.. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8030) 8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement. Y. Nir, S. Josefsson. December 2016. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8031) 8032 Edwards-Curve Digital Signature Algorithm (EdDSA). S. Josefsson, I. Liusvaara. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8032) 8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem. R. Pan, P. Natarajan, F. Baker, G. White. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8033) 8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems. G. White, R. Pan. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8034) 8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing. C. Holmberg. November 2016. (Format: TXT, HTML) (Updates RFC5761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8035) 8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks. N. Cam-Winget, Ed., J. Hui, D. Popa. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8036) 8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE). I. Liusvaara. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8037) 8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol. P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8038) 8039 Multipath Time Synchronization. A. Shpiner, R. Tse, C. Schelp, T. Mizrahi. December 2016. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8039) 8040 RESTCONF Protocol. A. Bierman, M. Bjorklund, K. Watsen. January 2017. (Format: TXT, HTML) (Updated by RFC8527) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8040) 8041 Use Cases and Operational Experience with Multipath TCP. O. Bonaventure, C. Paasch, G. Detal. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8041) 8042 OSPF Two-Part Metric. Z. Zhang, L. Wang, A. Lindem. December 2016. (Format: TXT, HTML) (Updates RFC2328) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8042) 8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space. B. Sarikaya, M. Boucadair. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8043) 8044 Data Types in RADIUS. A. DeKok. January 2017. (Format: TXT, HTML) (Updates RFC2865, RFC3162, RFC4072, RFC6158, RFC6572, RFC7268) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8044) 8045 RADIUS Extensions for IP Port Configuration and Reporting. D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8045) 8046 Host Mobility with the Host Identity Protocol. T. Henderson, Ed., C. Vogt, J. Arkko. February 2017. (Format: TXT, HTML) (Obsoletes RFC5206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8046) 8047 Host Multihoming with the Host Identity Protocol. T. Henderson, Ed., C. Vogt, J. Arkko. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8047) 8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence. P. Saint-Andre. December 2016. (Format: TXT, HTML) (Obsoletes RFC7248) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8048) 8049 YANG Data Model for L3VPN Service Delivery. S. Litkowski, L. Tomotaki, K. Ogaki. February 2017. (Format: TXT, HTML) (Obsoleted by RFC8299) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8049) 8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions. C. Petrie, T. King. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8050) 8051 Applicability of a Stateful Path Computation Element (PCE). X. Zhang, Ed., I. Minei, Ed.. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8051) 8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services. B. Weis, M. Seewald, H. Falk. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8052) 8053 HTTP Authentication Extensions for Interactive Clients. Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. January 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8053) 8054 Network News Transfer Protocol (NNTP) Extension for Compression. K. Murchison, J. Elie. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8054) 8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm. C. Holmberg, Y. Jiang. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8055) 8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping. J. Gould. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8056) 8057 Uniform Resource Name (URN) Namespaces for Broadband Forum. B. Stark, D. Sinicrope, W. Lupton. January 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8057) 8058 Signaling One-Click Functionality for List Email Headers. J. Levine, T. Herkula. January 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8058) 8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments. J. Arango, S. Venaas, I. Kouvelas, D. Farinacci. January 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8059) 8060 LISP Canonical Address Format (LCAF). D. Farinacci, D. Meyer, J. Snijders. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8060) 8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality. D. Farinacci, B. Weis. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8061) 8062 Anonymity Support for Kerberos. L. Zhu, P. Leach, S. Hartman, S. Emery, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC6112) (Updates RFC4120, RFC4121, RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8062) 8063 Key Relay Mapping for the Extensible Provisioning Protocol. H.W. Ribbers, M.W. Groeneweg, R. Gieben, A.L.J. Verschuren. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8063) 8064 Recommendation on Stable IPv6 Interface Identifiers. F. Gont, A. Cooper, D. Thaler, W. Liu. February 2017. (Format: TXT, HTML) (Updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, RFC5121) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8064) 8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms. D. Thaler. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8065) 8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines. S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt. February 2017. (Format: TXT, HTML) (Updates RFC4944, RFC6282) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8066) 8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level. B. Leiba. January 2017. (Format: TXT, HTML) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8067) 8068 Session Initiation Protocol (SIP) Recording Call Flows. R. Ravindranath, P. Ravindran, P. Kyzivat. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8068) 8069 URN Namespace for IEEE. A. Thomas. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8069) 8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension. M. Short, Ed., S. Moore, P. Miller. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8070) 8071 NETCONF Call Home and RESTCONF Call Home. K. Watsen. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8071) 8072 YANG Patch Media Type. A. Bierman, M. Bjorklund, K. Watsen. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8072) 8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report. K. Moriarty, M. Ford. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8073) 8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario. J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8074) 8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP). A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8075) 8076 A Usage for Shared Resources in RELOAD (ShaRe). A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8076) 8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP). L. Martini, Ed., G. Heron, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC4447, RFC6723) (Also STD0084) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8077) 8078 Managing DS Records from the Parent via CDS/CDNSKEY. O. Gudmundsson, P. Wouters. March 2017. (Format: TXT, HTML) (Updates RFC7344) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8078) 8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs). L. Miniero, S. Garcia Murillo, V. Pascual. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8079) 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC. O. Sury, R. Edmonds. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8080) 8081 The "font" Top-Level Media Type. C. Lilley. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8081) 8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs. S. Wenger, J. Lennox, B. Burman, M. Westerlund. March 2017. (Format: TXT, HTML) (Updates RFC5104) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8082) 8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions. C. Perkins, V. Singh. March 2017. (Format: TXT, HTML) (Updates RFC3550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8083) 8084 Network Transport Circuit Breakers. G. Fairhurst. March 2017. (Format: TXT, HTML) (Also BCP0208) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8084) 8085 UDP Usage Guidelines. L. Eggert, G. Fairhurst, G. Shepherd. March 2017. (Format: TXT, HTML) (Obsoletes RFC5405) (Updated by RFC8899) (Also BCP0145) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8085) 8086 GRE-in-UDP Encapsulation. L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8086) 8087 The Benefits of Using Explicit Congestion Notification (ECN). G. Fairhurst, M. Welzl. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8087) 8088 How to Write an RTP Payload Format. M. Westerlund. May 2017. (Format: TXT, HTML) (Updates RFC2736) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8088) 8089 The "file" URI Scheme. M. Kerwin. February 2017. (Format: TXT, HTML) (Updates RFC1738) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8089) 8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG). R. Housley. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8090) 8091 A Media Type Structured Syntax Suffix for JSON Text Sequences. E. Wilde. February 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8091) 8092 BGP Large Communities Attribute. J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8092) 8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243. J. Snijders. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8093) 8094 DNS over Datagram Transport Layer Security (DTLS). T. Reddy, D. Wing, P. Patil. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8094) 8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms. G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8095) 8096 The IPv6-Specific MIB Modules Are Obsolete. B. Fenner. April 2017. (Format: TXT, HTML) (Obsoletes RFC2452, RFC2454, RFC2465, RFC2466) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8096) 8097 BGP Prefix Origin Validation State Extended Community. P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8097) 8098 Message Disposition Notification. T. Hansen, Ed., A. Melnikov, Ed.. February 2017. (Format: TXT, HTML) (Obsoletes RFC3798) (Updates RFC2046, RFC3461) (Also STD0085) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8098) 8099 OSPF Topology-Transparent Zone. H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu. February 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8099) 8100 Diffserv-Interconnection Classes and Practice. R. Geib, Ed., D. Black. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8100) 8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service. C. Holmberg, J. Axell. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8101) 8102 Remote-LFA Node Protection and Manageability. P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8102) 8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). R. Housley. February 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8103) 8104 Pseudowire (PW) Endpoint Fast Failure Protection. Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8104) 8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE). P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8105) 8106 IPv6 Router Advertisement Options for DNS Configuration. J. Jeong, S. Park, L. Beloeil, S. Madanapalli. March 2017. (Format: TXT, HTML) (Obsoletes RFC6106) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8106) 8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition. J. Wold. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8107) 8108 Sending Multiple RTP Streams in a Single RTP Session. J. Lennox, M. Westerlund, Q. Wu, C. Perkins. March 2017. (Format: TXT, HTML) (Updates RFC3550, RFC4585) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8108) 8109 Initializing a DNS Resolver with Priming Queries. P. Koch, M. Larson, P. Hoffman. March 2017. (Format: TXT, HTML) (Also BCP0209) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8109) 8110 Opportunistic Wireless Encryption. D. Harkins, Ed., W. Kumari, Ed.. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8110) 8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT). V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8111) 8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG). D. Farinacci, A. Jain, I. Kouvelas, D. Lewis. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8112) 8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations. M. Boucadair, C. Jacquenet. March 2017. (Format: TXT, HTML) (Updates RFC6830) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8113) 8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network. M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8114) 8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes. M. Boucadair, J. Qin, T. Tsou, X. Deng. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8115) 8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2). T. Clausen, U. Herberg, J. Yi. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8116) 8117 Current Hostname Practice Considered Harmful. C. Huitema, D. Thaler, R. Winter. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8117) 8118 The application/pdf Media Type. M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey. March 2017. (Format: TXT, HTML) (Obsoletes RFC3778) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8118) 8119 SIP "cause" URI Parameter for Service Number Translation. M. Mohali, M. Barnes. March 2017. (Format: TXT, HTML) (Updates RFC4458) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8119) 8120 Mutual Authentication Protocol for HTTP. Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8120) 8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3). Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8121) 8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP). J. Lennox, C. Holmberg. March 2017. (Format: TXT, HTML) (Obsoletes RFC4572) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8122) 8123 Requirements for Marking SIP Messages to be Logged. P. Dawes, C. Arunachalam. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8123) 8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute. R. Ravindranath, G. Salgueiro. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8124) 8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes. J. Schmidt. April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8125) 8126 Guidelines for Writing an IANA Considerations Section in RFCs. M. Cotton, B. Leiba, T. Narten. June 2017. (Format: TXT, HTML) (Obsoletes RFC5226) (Also BCP0026) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8126) 8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor. D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8127) 8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee. C. Morgan. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8128) 8129 Authentication Indicator in Kerberos Tickets. A. Jain, N. Kinder, N. McCallum. March 2017. (Format: TXT, HTML) (Updates RFC4120) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8129) 8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec. V. Demjanenko, D. Satterlee. March 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8130) 8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing. X. Zhang, H. Zheng, Ed., R. Gandhi, Ed., Z. Ali, P. Brzozowski. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8131) 8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP). P. van der Stok, C. Bormann, A. Sehgal. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8132) 8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol. S. Smyshlyaev. Ed., E. Alekseev, I. Oshkin, V. Popov. March 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8133) 8134 Management Incident Lightweight Exchange (MILE) Implementation Report. C. Inacio, D. Miyamoto. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8134) 8135 Complex Addressing in IPv6. M. Danielson, M. Nilsson. 1 April 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8135) 8136 Additional Transition Functionality for IPv6. B. Carpenter, R. Hinden. 1 April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8136) 8137 IEEE 802.15.4 Information Element for the IETF. T. Kivinen, P. Kinney. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8137) 8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header. P. Thubert, Ed., C. Bormann, L. Toutain, R. Cragie. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8138) 8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders. D. Eastlake 3rd, Y. Li, M. Umair, A. Banerjee, F. Hu. June 2017. (Format: TXT, HTML) (Obsoletes RFC6439) (Updates RFC6325, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8139) 8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character. A. Farrel. 1 April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8140) 8141 Uniform Resource Names (URNs). P. Saint-Andre, J. Klensin. April 2017. (Format: TXT, HTML) (Obsoletes RFC2141, RFC3406) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8141) 8142 GeoJSON Text Sequences. S. Gillies. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8142) 8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP). J. Elie. April 2017. (Format: TXT, HTML) (Updates RFC4642) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8143) 8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV). K. Murchison. April 2017. (Format: TXT, HTML) (Updates RFC7240) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8144) 8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC). D. Wessels, W. Kumari, P. Hoffman. April 2017. (Format: TXT, HTML) (Updated by RFC8553) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8145) 8146 Adding Support for Salted Password Databases to EAP-pwd. D. Harkins. April 2017. (Format: TXT, HTML) (Updates RFC5931) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8146) 8147 Next-Generation Pan-European eCall. R. Gellens, H. Tschofenig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8147) 8148 Next-Generation Vehicle-Initiated Emergency Calls. R. Gellens, B. Rosen, H. Tschofenig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8148) 8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs). T. Saad, Ed., R. Gandhi, Ed., Z. Ali, R. Venator, Y. Kamite. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8149) 8150 MPLS Transport Profile Linear Protection MIB. S. Kingston Smiler, M. Venkatesan, D. King, S. Aldrin, J. Ryoo. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8150) 8151 Use Cases for Data Center Network Virtualization Overlay Networks. L. Yong, L. Dunbar, M. Toy, A. Isaac, V. Manral. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8151) 8152 CBOR Object Signing and Encryption (COSE). J. Schaad. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8152) 8153 Digital Preservation Considerations for the RFC Series. H. Flanagan. April 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8153) 8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout. C. Hellwig. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8154) 8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery. P. Patil, T. Reddy, D. Wing. April 2017. (Format: TXT, HTML) (Updates RFC5766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8155) 8156 DHCPv6 Failover Protocol. T. Mrugalski, K. Kinnear. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8156) 8157 Huawei's GRE Tunnel Bonding Protocol. N. Leymann, C. Heidemann, M. Zhang, B. Sarikaya, M. Cullen. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8157) 8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events. S. Sivakumar, R. Penno. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8158) 8159 Keyed IPv6 Tunnel. M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8159) 8160 IUTF8 Terminal Mode in Secure Shell (SSH). S. Tatham, D. Tucker. April 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8160) 8161 Benchmarking the Neighbor Discovery Protocol. W. Cerveny, R. Bonica, R. Thomas. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8161) 8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME. P. Hoffman, J. Schlyter. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8162) 8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks. K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8163) 8164 Opportunistic Security for HTTP/2. M. Nottingham, M. Thomson. May 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8164) 8165 Design Considerations for Metadata Insertion. T. Hardie. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8165) 8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1. C. Lever, Ed., W. Simpson, T. Talpey. June 2017. (Format: TXT, HTML) (Obsoletes RFC5666) (Updated by RFC8797) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8166) 8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports. C. Lever. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8167) 8168 DHCPv6 Prefix-Length Hint Issues. T. Li, C. Liu, Y. Cui. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8168) 8169 Residence Time Measurement in MPLS Networks. G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein. May 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8169) 8170 Planning for Protocol Adoption and Subsequent Transitions. D. Thaler, Ed.. May 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8170) 8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms. D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8171) 8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure. A. Morton. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8172) 8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base. V. Shankarkumar, L. Montini, T. Frost, G. Dowd. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8173) 8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. May 2017. (Format: TXT, HTML) (Updates RFC2119) (Also BCP0014) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8174) 8175 Dynamic Link Exchange Protocol (DLEP). S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8175) 8176 Authentication Method Reference Values. M. Jones, P. Hunt, A. Nadalin. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8176) 8177 YANG Data Model for Key Chains. A. Lindem, Ed., Y. Qu, D. Yeung, I. Chen, J. Zhang. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8177) 8178 Rules for NFSv4 Extensions and Minor Versions. D. Noveck. July 2017. (Format: TXT, HTML) (Updates RFC5661, RFC7862) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8178) 8179 Intellectual Property Rights in IETF Technology. S. Bradner, J. Contreras. May 2017. (Format: TXT, HTML) (Obsoletes RFC3979, RFC4879) (Updates RFC2026) (Also BCP0079) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8179) 8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration. X. Vilajosana, Ed., K. Pister, T. Watteyne. May 2017. (Format: TXT, HTML) (Also BCP0210) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8180) 8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI). S. Weiler, A. Sonalker, R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8181) 8182 The RPKI Repository Delta Protocol (RRDP). T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8182) 8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services. R. Austein. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8183) 8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires. W. Cheng, L. Wang, H. Li, S. Davari, J. Dong. June 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8184) 8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection. W. Cheng, L. Wang, H. Li, J. Dong, A. D'Alessandro. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8185) 8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP). G. Mirsky, I. Meilik. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8186) 8187 Indicating Character Encoding and Language for HTTP Header Field Parameters. J. Reschke. September 2017. (Format: TXT, HTML) (Obsoletes RFC5987) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8187) 8188 Encrypted Content-Encoding for HTTP. M. Thomson. June 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8188) 8189 Multi-Cost Application-Layer Traffic Optimization (ALTO). S. Randriamasy, W. Roome, N. Schwan. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8189) 8190 Updates to the Special-Purpose IP Address Registries. R. Bonica, M. Cotton, B. Haberman, L. Vegoda. June 2017. (Format: TXT, HTML) (Updates RFC6890) (Also BCP0153) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8190) 8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6). Z. Yan, J. Lee, X. Lee. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8191) 8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases. S. Hares, D. Lopez, M. Zarny, C. Jacquenet, R. Kumar, J. Jeong. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8192) 8193 Information Model for Large-Scale Measurement Platforms (LMAPs). T. Burbridge, P. Eardley, M. Bagnulo, J. Schoenwaelder. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8193) 8194 A YANG Data Model for LMAP Measurement Agents. J. Schoenwaelder, V. Bajpai. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8194) 8195 Use of BGP Large Communities. J. Snijders, J. Heasley, M. Schmidt. June 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8195) 8196 IS-IS Autoconfiguration. B. Liu, Ed., L. Ginsberg, B. Decraene, I. Farrer, M. Abrahamsson. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8196) 8197 A SIP Response Code for Unwanted Calls. H. Schulzrinne. July 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8197) 8198 Aggressive Use of DNSSEC-Validated Cache. K. Fujiwara, A. Kato, W. Kumari. July 2017. (Format: TXT, HTML) (Updates RFC4035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8198) 8199 YANG Module Classification. D. Bogdanovic, B. Claise, C. Moberg. July 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8199) 8200 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. July 2017. (Format: TXT, HTML) (Obsoletes RFC2460) (Also STD0086) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8200) 8201 Path MTU Discovery for IP version 6. J. McCann, S. Deering, J. Mogul, R. Hinden, Ed.. July 2017. (Format: TXT, HTML) (Obsoletes RFC1981) (Also STD0087) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8201) 8202 IS-IS Multi-Instance. L. Ginsberg, S. Previdi, W. Henderickx. June 2017. (Format: TXT, HTML) (Obsoletes RFC6822) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8202) 8203 BGP Administrative Shutdown Communication. J. Snijders, J. Heitz, J. Scudder. July 2017. (Format: TXT, HTML) (Updates RFC4486) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8203) 8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV). M. Tahhan, B. O'Mahony, A. Morton. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8204) 8205 BGPsec Protocol Specification. M. Lepinski, Ed., K. Sriram, Ed.. September 2017. (Format: TXT, HTML) (Updated by RFC8206) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8205) 8206 BGPsec Considerations for Autonomous System (AS) Migration. W. George, S. Murphy. September 2017. (Format: TXT, HTML) (Updates RFC8205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8206) 8207 BGPsec Operational Considerations. R. Bush. September 2017. (Format: TXT, HTML) (Also BCP0211) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8207) 8208 BGPsec Algorithms, Key Formats, and Signature Formats. S. Turner, O. Borchert. September 2017. (Format: TXT, HTML) (Obsoleted by RFC8608) (Updates RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8208) 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests. M. Reynolds, S. Turner, S. Kent. September 2017. (Format: TXT, HTML) (Updates RFC6487) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8209) 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1. R. Bush, R. Austein. September 2017. (Format: TXT, HTML) (Updates RFC6810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8210) 8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI). S. Kent, D. Ma. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8211) 8212 Default External BGP (EBGP) Route Propagation Behavior without Policies. J. Mauch, J. Snijders, G. Hankins. July 2017. (Format: TXT, HTML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8212) 8213 Security of Messages Exchanged between Servers and Relay Agents. B. Volz, Y. Pal. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8213) 8214 Virtual Private Wire Service Support in Ethernet VPN. S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8214) 8215 Local-Use IPv4/IPv6 Translation Prefix. T. Anderson. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8215) 8216 HTTP Live Streaming. R. Pantos, Ed., W. May. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8216) 8217 Clarifications for When to Use the name-addr Production in SIP Messages. R. Sparks. August 2017. (Format: TXT, HTML) (Updates RFC3261, RFC3325, RFC3515, RFC3892, RFC4508, RFC5002, RFC5318, RFC5360, RFC5502) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8217) 8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2). J. Yi, B. Parrein. August 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8218) 8219 Benchmarking Methodology for IPv6 Transition Technologies. M. Georgescu, L. Pislaru, G. Lencse. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8219) 8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS). O. Dornon, J. Kotalwar, V. Hemige, R. Qiu, Z. Zhang. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8220) 8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH). P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen. October 2017. (Format: TXT, HTML) (Obsoletes RFC7321) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8221) 8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery. A. Sullivan. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8222) 8223 Application-Aware Targeted LDP. S. Esale, R. Torvi, L. Jalil, U. Chunduri, K. Raza. August 2017. (Format: TXT, HTML) (Updates RFC7473) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8223) 8224 Authenticated Identity Management in the Session Initiation Protocol (SIP). J. Peterson, C. Jennings, E. Rescorla, C. Wendt. February 2018. (Format: TXT, HTML) (Obsoletes RFC4474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8224) 8225 PASSporT: Personal Assertion Token. C. Wendt, J. Peterson. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8225) 8226 Secure Telephone Identity Credentials: Certificates. J. Peterson, S. Turner. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8226) 8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology. W. Cheng, L. Wang, H. Li, H. van Helvoort, J. Dong. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8227) 8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels. A. Freytag. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8228) 8229 TCP Encapsulation of IKE and IPsec Packets. T. Pauly, S. Touati, R. Mantha. August 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8229) 8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages. M. Jones. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8230) 8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE. E. Crabbe, I. Minei, J. Medved, R. Varga. September 2017. (Format: TXT, HTML) (Updated by RFC8786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8231) 8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE. E. Crabbe, I. Minei, J. Medved, R. Varga, X. Zhang, D. Dhody. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8232) 8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs). D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8233) 8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode. J. Ryoo, T. Cheung, H. van Helvoort, I. Busi, G. Wen. August 2017. (Format: TXT, HTML) (Updates RFC7271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8234) 8235 Schnorr Non-interactive Zero-Knowledge Proof. F. Hao, Ed.. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8235) 8236 J-PAKE: Password-Authenticated Key Exchange by Juggling. F. Hao, Ed.. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8236) 8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs. L. Martini, G. Swallow, E. Bellagamba. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8237) 8238 Data Center Benchmarking Terminology. L. Avramov, J. Rapp. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8238) 8239 Data Center Benchmarking Methodology. L. Avramov, J. Rapp. August 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8239) 8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016. H. Tschofenig, S. Farrell. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8240) 8241 Interface to the Routing System (I2RS) Security-Related Requirements. S. Hares, D. Migault, J. Halpern. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8241) 8242 Interface to the Routing System (I2RS) Ephemeral State Requirements. J. Haas, S. Hares. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8242) 8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL). R. Perlman, D. Eastlake 3rd, M. Zhang, A. Ghanwani, H. Zhai. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8243) 8244 Special-Use Domain Names Problem Statement. T. Lemon, R. Droms, W. Kumari. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8244) 8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444. T. Clausen, C. Dearlove, U. Herberg, H. Rogge. October 2017. (Format: TXT, HTML) (Updates RFC5444) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8245) 8246 HTTP Immutable Responses. P. McManus. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8246) 8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Nir, T. Kivinen, P. Wouters, D. Migault. September 2017. (Format: TXT, HTML) (Obsoletes RFC4307) (Updates RFC7296) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8247) 8248 Security Automation and Continuous Monitoring (SACM) Requirements. N. Cam-Winget, L. Lorenzin. September 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8248) 8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation. M. Zhang, X. Zhang, D. Eastlake 3rd, R. Perlman, S. Chatterjee. September 2017. (Format: TXT, HTML) (Updates RFC6325, RFC7177, RFC7780) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8249) 8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option. N. Elkins, R. Hamilton, M. Ackermann. September 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8250) 8251 Updates to the Opus Audio Codec. JM. Valin, K. Vos. October 2017. (Format: TXT, HTML) (Updates RFC6716) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8251) 8252 OAuth 2.0 for Native Apps. W. Denniss, J. Bradley. October 2017. (Format: TXT, HTML) (Updates RFC6749) (Also BCP0212) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8252) 8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP). D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody. October 2017. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8253) 8254 Uniform Resource Name (URN) Namespace Registration Transition. J. Klensin, J. Hakala. October 2017. (Format: TXT, HTML) (Obsoletes RFC3044, RFC3187) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8254) 8255 Multiple Language Content Type. N. Tomkinson, N. Borenstein. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8255) 8256 Requirements for Hitless MPLS Path Segment Monitoring. A. D'Alessandro, L. Andersson, S. Ueno, K. Arai, Y. Koike. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8256) 8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers. S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8257) 8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI). D. Ceccarelli, L. Berger. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8258) 8259 The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. December 2017. (Format: TXT, HTML) (Obsoletes RFC7159) (Also STD0090) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8259) 8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol. R. Stewart, M. Tuexen, S. Loreto, R. Seggelmann. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8260) 8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets. M. Tuexen, R. Stewart, R. Jesup, S. Loreto. November 2017. (Format: TXT, HTML) (Updated by RFC8899) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8261) 8262 Content-ID Header Field in the Session Initiation Protocol (SIP). C. Holmberg, I. Sedlacek. October 2017. (Format: TXT, HTML) (Updates RFC5621, RFC5368, RFC6442) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8262) 8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message. B. Weis, U. Mangla, T. Karl, N. Maheshwari. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8263) 8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols. P. Saint-Andre, M. Blanchet. October 2017. (Format: TXT, HTML) (Obsoletes RFC7564) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8264) 8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords. P. Saint-Andre, A. Melnikov. October 2017. (Format: TXT, HTML) (Obsoletes RFC7613) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8265) 8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames. P. Saint-Andre. October 2017. (Format: TXT, HTML) (Obsoletes RFC7700) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8266) 8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1. C. Lever. October 2017. (Format: TXT, HTML) (Obsoletes RFC5667) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8267) 8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH). M. Baushke. December 2017. (Format: TXT, HTML) (Updates RFC4250, RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8268) 8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP). W. Kim, J. Lee, J. Park, D. Kwon, D. Kim. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8269) 8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits. L. Velvindron, M. Baushke. December 2017. (Format: TXT, HTML) (Updates RFC4419) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8270) 8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs). M. Taillon, T. Saad, Ed., R. Gandhi, Ed., Z. Ali, M. Bhatia. October 2017. (Format: TXT, HTML) (Updates RFC4090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8271) 8272 TinyIPFIX for Smart Meters in Constrained Networks. C. Schmitt, B. Stiller, B. Trammell. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8272) 8273 Unique IPv6 Prefix per Host. J. Brzozowski, G. Van de Velde. December 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8273) 8274 Incident Object Description Exchange Format Usage Guidance. P. Kampanakis, M. Suzuki. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8274) 8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask. J. Fields, A. Gruenbacher. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8275) 8276 File System Extended Attributes in NFSv4. M. Naik, M. Eshel. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8276) 8277 Using BGP to Bind MPLS Labels to Address Prefixes. E. Rosen. October 2017. (Format: TXT, HTML) (Obsoletes RFC3107) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8277) 8278 Mobile Access Gateway (MAG) Multipath Options. P. Seite, A. Yegin, S. Gundavelli. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8278) 8279 Multicast Using Bit Index Explicit Replication (BIER). IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, T. Przygienda, S. Aldrin. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8279) 8280 Research into Human Rights Protocol Considerations. N. ten Oever, C. Cath. October 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8280) 8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model. E. Crabbe, I. Minei, S. Sivabalan, R. Varga. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8281) 8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering. E. Oki, T. Takeda, A. Farrel, F. Zhang. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8282) 8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control. A. Farrel, Ed., Q. Zhao, Ed., Z. Li, C. Zhou. December 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8283) 8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages. S. Kille. November 2017. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8284) 8285 A General Mechanism for RTP Header Extensions. D. Singer, H. Desineni, R. Even, Ed.. October 2017. (Format: TXT, HTML) (Obsoletes RFC5285) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8285) 8286 RTP/RTCP Extension for RTP Splicing Notification. J. Xia, R. Even, R. Huang, L. Deng. October 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8286) 8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes. N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen. December 2017. (Format: TXT, HTML) (Updated by RFC8690) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8287) 8288 Web Linking. M. Nottingham. October 2017. (Format: TXT, HTML) (Obsoletes RFC5988) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8288) 8289 Controlled Delay Active Queue Management. K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed.. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8289) 8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm. T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8290) 8291 Message Encryption for Web Push. M. Thomson. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8291) 8292 Voluntary Application Server Identification (VAPID) for Web Push. M. Thomson, P. Beverloo. November 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8292) 8293 A Framework for Multicast in Network Virtualization over Layer 3. A. Ghanwani, L. Dunbar, M. McBride, V. Bannai, R. Krishnan. January 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8293) 8294 Common YANG Data Types for the Routing Area. X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger. December 2017. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8294) 8295 EST (Enrollment over Secure Transport) Extensions. S. Turner. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8295) 8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks. IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, J. Tantsura, S. Aldrin, I. Meilik. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8296) 8297 An HTTP Status Code for Indicating Hints. K. Oku. December 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8297) 8298 Self-Clocked Rate Adaptation for Multimedia. I. Johansson, Z. Sarker. December 2017. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8298) 8299 YANG Data Model for L3VPN Service Delivery. Q. Wu, Ed., S. Litkowski, L. Tomotaki, K. Ogaki. January 2018. (Format: TXT, HTML) (Obsoletes RFC8049) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8299) 8300 Network Service Header (NSH). P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed.. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8300) 8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM). S. Kitterman. January 2018. (Format: TXT, HTML) (Updates RFC6376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8301) 8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization. Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair. January 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8302) 8303 On the Usage of Transport Features Provided by IETF Transport Protocols. M. Welzl, M. Tuexen, N. Khademi. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8303) 8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite). G. Fairhurst, T. Jones. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8304) 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency. D. Schinazi, T. Pauly. December 2017. (Format: TXT, HTML) (Obsoletes RFC6555) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8305) 8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths. Q. Zhao, D. Dhody, Ed., R. Palleti, D. King. November 2017. (Format: TXT, HTML) (Obsoletes RFC6006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8306) 8307 Well-Known URIs for the WebSocket Protocol. C. Bormann. January 2018. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8307) 8308 Extension Negotiation in the Secure Shell (SSH) Protocol. D. Bider. March 2018. (Format: TXT, HTML) (Updates RFC4251, RFC4252, RFC4253, RFC4254) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8308) 8309 Service Models Explained. Q. Wu, W. Liu, A. Farrel. January 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8309) 8310 Usage Profiles for DNS over TLS and DNS over DTLS. S. Dickinson, D. Gillmor, T. Reddy. March 2018. (Format: TXT, HTML) (Updates RFC7858) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8310) 8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation. D. Black. January 2018. (Format: TXT, HTML) (Updates RFC3168, RFC4341, RFC4342, RFC5622, RFC6679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8311) 8312 CUBIC for Fast Long-Distance Networks. I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8312) 8313 Use of Multicast across Inter-domain Peering Points. P. Tarapore, Ed., R. Sayko, G. Shepherd, T. Eckert, Ed., R. Krishnan. January 2018. (Format: TXT, HTML) (Also BCP0213) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8313) 8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. K. Moore, C. Newman. January 2018. (Format: TXT, HTML) (Updates RFC1939, RFC2595, RFC3501, RFC5068, RFC6186, RFC6409) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8314) 8315 Cancel-Locks in Netnews Articles. M. Baeuerle. February 2018. (Format: TXT, HTML) (Updates RFC5537) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8315) 8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations. J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8316) 8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN). A. Sajassi, Ed., S. Salam, J. Drake, J. Uttaro, S. Boutros, J. Rabadan. January 2018. (Format: TXT, HTML) (Updates RFC7385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8317) 8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee. S. Dawkins. January 2018. (Format: TXT, HTML) (Obsoleted by RFC8713) (Updates RFC7437) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8318) 8319 Support for Adjustable Maximum Router Lifetimes per Link. S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko. February 2018. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8319) 8320 LDP Extensions to Support Maximally Redundant Trees. A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8320) 8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring. G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi. January 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8321) 8322 Resource-Oriented Lightweight Information Exchange (ROLIE). J. Field, S. Banghart, D. Waltermire. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8322) 8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed.. February 2018. (Format: TXT, HTML) (Updates RFC7641, RFC7959) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8323) 8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?. J. Klensin. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8324) 8325 Mapping Diffserv to IEEE 802.11. T. Szigeti, J. Henry, F. Baker. February 2018. (Format: TXT, HTML) (Updated by RFC8622) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8325) 8326 Graceful BGP Session Shutdown. P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K. Patel, C. Filsfils. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8326) 8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling. W. Hargrave, M. Griswold, J. Snijders, N. Hilliard. March 2018. (Format: TXT, HTML) (Also BCP0214) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8327) 8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis, M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8328) 8329 Framework for Interface to Network Security Functions. D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar. February 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8329) 8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth. H. Long, M. Ye, G. Mirsky, A. D'Alessandro, H. Shah. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8330) 8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data. T. Edwards. February 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8331) 8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol. D. Bider. March 2018. (Format: TXT, HTML) (Updates RFC4252, RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8332) 8333 Micro-loop Prevention by Introducing a Local Convergence Delay. S. Litkowski, B. Decraene, C. Filsfils, P. Francois. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8333) 8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP). J. Gould, W. Tan, G. Brown. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8334) 8335 PROBE: A Utility for Probing Interfaces. R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair. February 2018. (Format: TXT, HTML) (Updates RFC4884) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8335) 8336 The ORIGIN HTTP/2 Frame. M. Nottingham, E. Nygren. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8336) 8337 Model-Based Metrics for Bulk Transport Capacity. M. Mathis, A. Morton. March 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8337) 8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP. S. Boutros, Ed., S. Sivabalan, Ed.. March 2018. (Format: TXT, HTML) (Updates RFC7385) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8338) 8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms. P. Jain, Ed., S. Boutros, S. Aldrin. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8339) 8340 YANG Tree Diagrams. M. Bjorklund, L. Berger, Ed.. March 2018. (Format: TXT, HTML) (Updated by RFC8791) (Also BCP0215) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8340) 8341 Network Configuration Access Control Model. A. Bierman, M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC6536) (Also STD0091) (Status: INTERNET STANDARD) (DOI: 10.17487/RFC8341) 8342 Network Management Datastore Architecture (NMDA). M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2018. (Format: TXT, HTML) (Updates RFC7950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8342) 8343 A YANG Data Model for Interface Management. M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC7223) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8343) 8344 A YANG Data Model for IP Management. M. Bjorklund. March 2018. (Format: TXT, HTML) (Obsoletes RFC7277) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8344) 8345 A YANG Data Model for Network Topologies. A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, X. Liu. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8345) 8346 A YANG Data Model for Layer 3 Topologies. A. Clemm, J. Medved, R. Varga, X. Liu, H. Ananthakrishnan, N. Bahadur. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8346) 8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP). X. Liu, Ed., A. Kyparlis, R. Parikh, A. Lindem, M. Zhang. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8347) 8348 A YANG Data Model for Hardware Management. A. Bierman, M. Bjorklund, J. Dong, D. Romascanu. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8348) 8349 A YANG Data Model for Routing Management (NMDA Version). L. Lhotka, A. Lindem, Y. Qu. March 2018. (Format: TXT, HTML) (Obsoletes RFC8022) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8349) 8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP). R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du. April 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8350) 8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type. S. Leonard. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8351) 8352 Energy-Efficient Features of Internet of Things Protocols. C. Gomez, M. Kovatsch, H. Tian, Z. Cao, Ed.. April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8352) 8353 Generic Security Service API Version 2: Java Bindings Update. M. Upadhyay, S. Malkani, W. Wang. May 2018. (Format: TXT, HTML) (Obsoletes RFC5653) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8353) 8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING). J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8354) 8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks. C. Filsfils, Ed., S. Previdi, Ed., B. Decraene, R. Shakir. March 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8355) 8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP). D. Dhody, D. King, A. Farrel. March 2018. (Format: TXT, HTML) (Updates RFC5440) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8356) 8357 Generalized UDP Source Port for DHCP Relay. N. Shen, E. Chen. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8357) 8358 Update to Digital Signatures on Internet-Draft Documents. R. Housley. March 2018. (Format: TXT, HTML) (Updates RFC5485) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8358) 8359 Network-Assigned Upstream Label. X. Zhang, Ed., V. Beeram, Ed., I. Bryskin, D. Ceccarelli, O. Gonzalez de Dios. March 2018. (Format: TXT, HTML) (Updates RFC3471, RFC3473, RFC6205) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8359) 8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered. G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw. April 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8360) 8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic. W. Hao, Y. Li, M. Durrani, S. Gupta, A. Qu. April 2018. (Format: TXT, HTML) (Updates RFC6325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8361) 8362 OSPFv3 Link State Advertisement (LSA) Extensibility. A. Lindem, A. Roy, D. Goethals, V. Reddy Vallem, F. Baker. April 2018. (Format: TXT, HTML) (Updates RFC5340, RFC5838) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8362) 8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks. X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. Ceccarelli. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8363) 8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD). IJ. Wijnands, S. Venaas, M. Brig, A. Jonasson. March 2018. (Format: TXT, HTML) (Updated by RFC8736) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8364) 8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN). A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx. March 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8365) 8366 A Voucher Artifact for Bootstrapping Protocols. K. Watsen, M. Richardson, M. Pritikin, T. Eckert. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8366) 8367 Wrongful Termination of Internet Protocol (IP) Packets. T. Mizrahi, J. Yallouz. 1 April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8367) 8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM). T. Eckert, Ed., M. Behringer. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8368) 8369 Internationalizing IPv6 Using 128-Bit Unicode. H. Kaplan. 1 April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8369) 8370 Techniques to Improve the Scalability of RSVP-TE Deployments. V. Beeram, Ed., I. Minei, R. Shakir, D. Pacella, T. Saad. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8370) 8371 Mobile Node Identifier Types for MIPv6. C. Perkins, V. Devarapalli. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8371) 8372 MPLS Flow Identification Considerations. S. Bryant, C. Pignataro, M. Chen, Z. Li, G. Mirsky. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8372) 8373 Negotiating Human Language in Real-Time Communications. R. Gellens. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8373) 8374 BGPsec Design Choices and Summary of Supporting Discussions. K. Sriram, Ed.. April 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8374) 8375 Special-Use Domain 'home.arpa.'. P. Pfister, T. Lemon. May 2018. (Format: TXT, HTML) (Updates RFC7788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8375) 8376 Low-Power Wide Area Network (LPWAN) Overview. S. Farrell, Ed.. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8376) 8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology. D. Eastlake 3rd, M. Zhang, A. Banerjee. July 2018. (Format: TXT, HTML) (Updates RFC6325, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8377) 8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast. V. Moreno, D. Farinacci. May 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8378) 8379 OSPF Graceful Link Shutdown. S. Hegde, P. Sarkar, H. Gredler, M. Nanduri, L. Jalil. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8379) 8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation. L. Dunbar, D. Eastlake 3rd, R. Perlman. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8380) 8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol. D. Eastlake 3rd, Y. Li, W. Hao, A. Banerjee. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8381) 8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth. June 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8382) 8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message. W. Hao, D. Eastlake 3rd, Y. Li, M. Umair. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8383) 8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes. R. Perlman, F. Hu, D. Eastlake 3rd, T. Liao. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8384) 8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS. M. Umair, S. Kingston Smiler, D. Eastlake 3rd, L. Yong. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8385) 8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast. R. Winter, M. Faath, F. Weisshaar. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8386) 8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks. M. Sethi, J. Arkko, A. Keranen, H. Back. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8387) 8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN. J. Rabadan, Ed., S. Palislamovic, W. Henderickx, A. Sajassi, J. Uttaro. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8388) 8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E). Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8389) 8390 RSVP-TE Path Diversity Using Exclude Route. Z. Ali, Ed., G. Swallow, Ed., F. Zhang, Ed., D. Beller, Ed.. July 2018. (Format: TXT, HTML) (Updates RFC4874) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8390) 8391 XMSS: eXtended Merkle Signature Scheme. A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8391) 8392 CBOR Web Token (CWT). M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8392) 8393 Operating the Network Service Header (NSH) with Next Protocol "None". A. Farrel, J. Drake. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8393) 8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements. Y. Li, D. Eastlake 3rd, L. Kreeger, T. Narten, D. Black. May 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8394) 8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels. K. Patel, S. Boutros, J. Liste, B. Wen, J. Rabadan. June 2018. (Format: TXT, HTML) (Updates RFC4761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8395) 8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework. J. Peterson, T. McGarry. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8396) 8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames. M. Zhang, D. Eastlake 3rd, R. Perlman, H. Zhai, D. Liu. May 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8397) 8398 Internationalized Email Addresses in X.509 Certificates. A. Melnikov, Ed., W. Chuang, Ed.. May 2018. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8398) 8399 Internationalization Updates to RFC 5280. R. Housley. May 2018. (Format: TXT, HTML) (Updates RFC5280) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8399) 8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection. H. Chen, A. Liu, T. Saad, F. Xu, L. Huang. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8400) 8401 Bit Index Explicit Replication (BIER) Support via IS-IS. L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8401) 8402 Segment Routing Architecture. C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8402) 8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System. R. Geib, Ed., C. Filsfils, C. Pignataro, Ed., N. Kumar. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8403) 8404 Effects of Pervasive Encryption on Operators. K. Moriarty, Ed., A. Morton, Ed.. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8404) 8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs. B. Decraene, S. Litkowski, H. Gredler, A. Lindem, P. Francois, C. Bowers. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8405) 8406 Taxonomy of Coding Techniques for Efficient Network Communications. B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Ed., P. Saxena, S. Sivakumar. June 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8406) 8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models. A. Bierman. October 2018. (Format: TXT, HTML) (Obsoletes RFC6087) (Also BCP0216) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8407) 8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages. S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick. July 2018. (Format: TXT, HTML) (Updated by RFC8664) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8408) 8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types. I. Young, Ed., L. Johansson, S. Cantor. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8409) 8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure. S. Josefsson, J. Schaad. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8410) 8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range. J. Schaad, R. Andrews. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8411) 8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC. C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, J. Fitzgerald-McKay. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8412) 8413 Framework for Scheduled Use of Resources. Y. Zhuang, Q. Wu, H. Chen, A. Farrel. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8413) 8414 OAuth 2.0 Authorization Server Metadata. M. Jones, N. Sakimura, J. Bradley. June 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8414) 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters. November 2018. (Format: TXT, HTML) (Obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, RFC7283, RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8415) 8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM). D. Ma, D. Mandelberg, T. Bruijnzeels. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8416) 8417 Security Event Token (SET). P. Hunt, Ed., M. Jones, W. Denniss, M. Ansari. July 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8417) 8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS). R. Housley. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8418) 8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS). R. Housley. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8419) 8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2). Y. Nir. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8420) 8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE). P. Martinsen, T. Reddy, P. Patil. July 2018. (Format: TXT, HTML) (Also BCP0217) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8421) 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier. Y. Nir, S. Josefsson, M. Pegourie-Gonnard. August 2018. (Format: TXT, HTML) (Obsoletes RFC4492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8422) 8423 Reclassification of Suite B Documents to Historic Status. R. Housley, L. Zieglar. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8423) 8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection. H. Chen, Ed., R. Torvi, Ed.. August 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8424) 8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags. O. Troan. July 2018. (Format: TXT, HTML) (Updates RFC4861) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8425) 8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence. H. Sitaraman, Ed., V. Beeram, I. Minei, S. Sivabalan. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8426) 8427 Representing DNS Messages in JSON. P. Hoffman. July 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8427) 8428 Sensor Measurement Lists (SenML). C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8428) 8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos. B. Kaduk, M. Short. October 2018. (Format: TXT, HTML) (Updates RFC3961, RFC4120) (Also BCP0218) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8429) 8430 RIB Information Model. N. Bahadur, Ed., S. Kini, Ed., J. Medved. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8430) 8431 A YANG Data Model for the Routing Information Base (RIB). L. Wang, M. Chen, A. Dass, H. Ananthakrishnan, S. Kini, N. Bahadur. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8431) 8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters. J. Ahlberg, Ed., M. Ye, Ed., X. Li, LM. Contreras, CJ. Bernardos. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8432) 8433 A Simpler Method for Resolving Alert-Info URNs. D. Worley. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8433) 8434 Requirements for Parallel NFS (pNFS) Layout Types. T. Haynes. August 2018. (Format: TXT, HTML) (Updates RFC5661) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8434) 8435 Parallel NFS (pNFS) Flexible File Layout. B. Halevy, T. Haynes. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8435) 8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry. G. Fairhurst. August 2018. (Format: TXT, HTML) (Updates RFC2474) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8436) 8437 IMAP UNAUTHENTICATE Extension for Connection Reuse. C. Newman. August 2018. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8437) 8438 IMAP Extension for STATUS=SIZE. S. Bosch. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8438) 8439 ChaCha20 and Poly1305 for IETF Protocols. Y. Nir, A. Langley. June 2018. (Format: TXT, HTML) (Obsoletes RFC7539) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8439) 8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST. K. Murchison, B. Gondwana. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8440) 8441 Bootstrapping WebSockets with HTTP/2. P. McManus. September 2018. (Format: TXT, HTML) (Updates RFC6455) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8441) 8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2. J. Mattsson, D. Migault. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8442) 8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization. R. Singh, M. Dolly, S. Das, A. Nguyen. August 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8443) 8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER). P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8444) 8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. A. Keranen, C. Holmberg, J. Rosenberg. July 2018. (Format: TXT, HTML) (Obsoletes RFC5245) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8445) 8446 The Transport Layer Security (TLS) Protocol Version 1.3. E. Rescorla. August 2018. (Format: TXT, HTML) (Obsoletes RFC5077, RFC5246, RFC6961) (Updates RFC5705, RFC6066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8446) 8447 IANA Registry Updates for TLS and DTLS. J. Salowey, S. Turner. August 2018. (Format: TXT, HTML) (Updates RFC3749, RFC4680, RFC5077, RFC5246, RFC5705, RFC5878, RFC6520, RFC7301) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8447) 8448 Example Handshake Traces for TLS 1.3. M. Thomson. January 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8448) 8449 Record Size Limit Extension for TLS. M. Thomson. August 2018. (Format: TXT, HTML) (Updates RFC6066) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8449) 8450 RTP Payload Format for VC-2 High Quality (HQ) Profile. J. Weaver. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8450) 8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API. V. Singh, R. Huang, R. Even, D. Romascanu, L. Deng. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8451) 8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption. S. Gueron, A. Langley, Y. Lindell. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8452) 8453 Framework for Abstraction and Control of TE Networks (ACTN). D. Ceccarelli, Ed., Y. Lee, Ed.. August 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8453) 8454 Information Model for Abstraction and Control of TE Networks (ACTN). Y. Lee, S. Belotti, D. Dhody, D. Ceccarelli, B. Yoon. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8454) 8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance. V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8455) 8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance. V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8456) 8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute. B. Leiba, Ed.. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8457) 8458 Using National Bibliography Numbers as Uniform Resource Names. J. Hakala. October 2018. (Format: TXT, HTML) (Obsoletes RFC3188) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8458) 8459 Hierarchical Service Function Chaining (hSFC). D. Dolson, S. Homma, D. Lopez, M. Boucadair. September 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8459) 8460 SMTP TLS Reporting. D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8460) 8461 SMTP MTA Strict Transport Security (MTA-STS). D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, J. Jones. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8461) 8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW). N. Rooney, S. Dawkins, Ed.. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8462) 8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM). J. Levine. September 2018. (Format: TXT, HTML) (Updates RFC6376) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8463) 8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID). R. Atarius. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8464) 8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID. R. Atarius, Ed.. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8465) 8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery. B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8466) 8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)). A. Mayrhofer. October 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8467) 8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework. A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde. November 2018. (Format: TXT, HTML) (Updates RFC2330) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8468) 8469 Recommendation to Use the Ethernet Control Word. S. Bryant, A. Malis, I. Bagdonas. November 2018. (Format: TXT, HTML) (Updates RFC4448) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8469) 8470 Using Early Data in HTTP. M. Thomson, M. Nottingham, W. Tarreau. September 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8470) 8471 The Token Binding Protocol Version 1.0. A. Popov, Ed., M. Nystroem, D. Balfanz, J. Hodges. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8471) 8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation. A. Popov, Ed., M. Nystroem, D. Balfanz. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8472) 8473 Token Binding over HTTP. A. Popov, M. Nystroem, D. Balfanz, Ed., N. Harper, J. Hodges. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8473) 8474 IMAP Extension for Object Identifiers. B. Gondwana, Ed.. September 2018. (Format: TXT, HTML) (Updates RFC3501) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8474) 8475 Using Conditional Router Advertisements for Enterprise Multihoming. J. Linkova, M. Stucchi. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8475) 8476 Signaling Maximum SID Depth (MSD) Using OSPF. J. Tantsura, U. Chunduri, S. Aldrin, P. Psenak. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8476) 8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016. J. Jimenez, H. Tschofenig, D. Thaler. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8477) 8478 Zstandard Compression and the application/zstd Media Type. Y. Collet, M. Kucherawy, Ed.. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8478) 8479 Storing Validation Parameters in PKCS#8. N. Mavrogiannopoulos. September 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8479) 8480 6TiSCH Operation Sublayer (6top) Protocol (6P). Q. Wang, Ed., X. Vilajosana, T. Watteyne. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8480) 8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI). R. Bush. September 2018. (Format: TXT, HTML) (Updates RFC6811) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8481) 8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY. J. Abley, O. Gudmundsson, M. Majkowski, E. Hunt. January 2019. (Format: TXT, HTML) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8482) 8483 Yeti DNS Testbed. L. Song, Ed., D. Liu, P. Vixie, A. Kato, S. Kerr. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8483) 8484 DNS Queries over HTTPS (DoH). P. Hoffman, P. McManus. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8484) 8485 Vectors of Trust. J. Richer, Ed., L. Johansson. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8485) 8486 Ambisonics in an Ogg Opus Container. J. Skoglund, M. Graczyk. October 2018. (Format: TXT, HTML) (Updates RFC7845) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8486) 8487 Mtrace Version 2: Traceroute Facility for IP Multicast. H. Asaeda, K. Meyer, W. Lee. Ed.. October 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8487) 8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation. O. Muravskiy, T. Bruijnzeels. December 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8488) 8489 Session Traversal Utilities for NAT (STUN). M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews. February 2020. (Format: TXT, HTML) (Obsoletes RFC5389) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8489) 8490 DNS Stateful Operations. R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri. March 2019. (Format: TXT, HTML) (Updates RFC1035, RFC7766) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8490) 8491 Signaling Maximum SID Depth (MSD) Using IS-IS. J. Tantsura, U. Chunduri, S. Aldrin, L. Ginsberg. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8491) 8492 Secure Password Ciphersuites for Transport Layer Security (TLS). D. Harkins, Ed.. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8492) 8493 The BagIt File Packaging Format (V1.0). J. Kunze, J. Littman, E. Madden, J. Scancella, C. Adams. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8493) 8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142. D. Wilson, A. Melnikov, Ed.. November 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8494) 8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP). J. Gould, K. Feher. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8495) 8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP). D. York, T. Asveren. October 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8496) 8497 Marking SIP Messages to Be Logged. P. Dawes, C. Arunachalam. November 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8497) 8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP). M. Mohali. February 2019. (Format: TXT, HTML) (Updates RFC5502) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8498) 8499 DNS Terminology. P. Hoffman, A. Sullivan, K. Fujiwara. January 2019. (Format: TXT, HTML) (Obsoletes RFC7719) (Updates RFC2308) (Also BCP0219) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8499) 8500 IS-IS Routing with Reverse Metric. N. Shen, S. Amante, M. Abrahamsson. February 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8500) 8501 Reverse DNS in IPv6 for Internet Service Providers. L. Howard. November 2018. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8501) 8502 L2L3 VPN Multicast MIB. Z. Zhang, H. Tsunoda. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8502) 8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base. H. Tsunoda. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8503) 8504 IPv6 Node Requirements. T. Chown, J. Loughney, T. Winters. January 2019. (Format: TXT, HTML) (Obsoletes RFC6434) (Also BCP0220) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8504) 8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery. P. Thubert, Ed., E. Nordmark, S. Chakrabarti, C. Perkins. November 2018. (Format: TXT, HTML) (Updates RFC6775) (Updated by RFC8928, RFC8929) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8505) 8506 Diameter Credit-Control Application. L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed.. March 2019. (Format: TXT, HTML) (Obsoletes RFC4006) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8506) 8507 Simple Internet Protocol (SIP) Specification. S. Deering, R. Hinden, Ed.. December 2018. (Format: TXT, HTML) (Status: HISTORIC) (DOI: 10.17487/RFC8507) 8508 IMAP REPLACE Extension. S. Brandt. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8508) 8509 A Root Key Trust Anchor Sentinel for DNSSEC. G. Huston, J. Damas, W. Kumari. December 2018. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8509) 8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement. P. Psenak, Ed., K. Talaulikar, W. Henderickx, P. Pillay-Esnault. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8510) 8511 TCP Alternative Backoff with ECN (ABE). N. Khademi, M. Welzl, G. Armitage, G. Fairhurst. December 2018. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8511) 8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT). M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8512) 8513 A YANG Data Model for Dual-Stack Lite (DS-Lite). M. Boucadair, C. Jacquenet, S. Sivakumar. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8513) 8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension. S. Bosch. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8514) 8515 URN Namespace for ETSI Documents. M. Jethanandani, M.A. Reina Ortega. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8515) 8516 "Too Many Requests" Response Code for the Constrained Application Protocol. A. Keranen. January 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8516) 8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective. D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., C. Jacquenet. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8517) 8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes. P. Sarkar, Ed., U. Chunduri, Ed., S. Hegde, J. Tantsura, H. Gredler. March 2019. (Format: TXT, HTML) (Updates RFC5286) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8518) 8519 YANG Data Model for Network Access Control Lists (ACLs). M. Jethanandani, S. Agarwal, L. Huang, D. Blair. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8519) 8520 Manufacturer Usage Description Specification. E. Lear, R. Droms, D. Romascanu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8520) 8521 Registration Data Access Protocol (RDAP) Object Tagging. S. Hollenbeck, A. Newton. November 2018. (Format: TXT, HTML) (Updates RFC7484) (Also BCP0221) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8521) 8522 Looking Glass Command Set. M. Stubbig. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8522) 8525 YANG Library. A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Obsoletes RFC7895) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8525) 8526 NETCONF Extensions to Support the Network Management Datastore Architecture. M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Updates RFC6241, RFC7950) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8526) 8527 RESTCONF Extensions to Support the Network Management Datastore Architecture. M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. March 2019. (Format: TXT, HTML) (Updates RFC8040) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8527) 8528 YANG Schema Mount. M. Bjorklund, L. Lhotka. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8528) 8529 YANG Data Model for Network Instances. L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8529) 8530 YANG Model for Logical Network Elements. L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8530) 8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols. D. Kumar, Q. Wu, Z. Wang. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8531) 8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications. D. Kumar, Z. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8532) 8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications. D. Kumar, M. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8533) 8534 Explicit Tracking with Wildcard Routes in Multicast VPN. A. Dolganow, J. Kotalwar, E. Rosen, Ed., Z. Zhang. February 2019. (Format: TXT, HTML) (Updates RFC6514, RFC6625, RFC7524, RFC7582, RFC7900) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8534) 8536 The Time Zone Information Format (TZif). A. Olson, P. Eggert, K. Murchison. February 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8536) 8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs). R. Gandhi, Ed., H. Shah, J. Whittaker. February 2019. (Format: TXT, HTML) (Updates RFC4090, RFC7551) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8537) 8538 Notification Message Support for BGP Graceful Restart. K. Patel, R. Fernando, J. Scudder, J. Haas. March 2019. (Format: TXT, HTML) (Updates RFC4724) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8538) 8539 Softwire Provisioning Using DHCPv4 over DHCPv6. I. Farrer, Q. Sun, Y. Cui, L. Sun. March 2019. (Format: TXT, HTML) (Updates RFC7598) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8539) 8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960. R. Stewart, M. Tuexen, M. Proshin. February 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8540) 8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops. S. Litkowski, B. Decraene, M. Horneffer. March 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8541) 8542 A YANG Data Model for Fabric Topology in Data-Center Networks. Y. Zhuang, D. Shi, R. Gu, H. Ananthakrishnan. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8542) 8543 Extensible Provisioning Protocol (EPP) Organization Mapping. L. Zhou, N. Kong, J. Yao, J. Gould, G. Zhou. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8543) 8544 Organization Extension for the Extensible Provisioning Protocol (EPP). L. Zhou, N. Kong, J. Wei, J. Yao, J. Gould. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8544) 8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP). A. Morton, Ed., G. Mirsky, Ed.. March 2019. (Format: TXT, HTML) (Updates RFC4656, RFC5357) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8545) 8546 The Wire Image of a Network Protocol. B. Trammell, M. Kuehlewind. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8546) 8547 TCP-ENO: Encryption Negotiation Option. A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith. May 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8547) 8548 Cryptographic Protection of TCP Streams (tcpcrypt). A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith. May 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8548) 8549 Export of BGP Community Information in IP Flow Information Export (IPFIX). Z. Li, R. Gu, J. Dong. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8549) 8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling. J. Schaad, B. Ramsdell, S. Turner. April 2019. (Format: TXT, HTML) (Obsoletes RFC5750) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8550) 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. J. Schaad, B. Ramsdell, S. Turner. April 2019. (Format: TXT, HTML) (Obsoletes RFC5751) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8551) 8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves. D. Crocker. March 2019. (Format: TXT, HTML) (Also BCP0222) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8552) 8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names. D. Crocker. March 2019. (Format: TXT, HTML) (Updates RFC2782, RFC3263, RFC3529, RFC3620, RFC3832, RFC3887, RFC3958, RFC4120, RFC4227, RFC4386, RFC4387, RFC4976, RFC5026, RFC5328, RFC5389, RFC5415, RFC5518, RFC5555, RFC5617, RFC5679, RFC5766, RFC5780, RFC5804, RFC5864, RFC5928, RFC6120, RFC6186, RFC6376, RFC6733, RFC6763, RFC7208, RFC7489, RFC8145) (Also BCP0222) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8553) 8554 Leighton-Micali Hash-Based Signatures. D. McGrew, M. Curcio, S. Fluhrer. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8554) 8555 Automatic Certificate Management Environment (ACME). R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8555) 8556 Multicast VPN Using Bit Index Explicit Replication (BIER). E. Rosen, Ed., M. Sivakumar, T. Przygienda, S. Aldrin, A. Dolganow. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8556) 8557 Deterministic Networking Problem Statement. N. Finn, P. Thubert. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8557) 8558 Transport Protocol Path Signals. T. Hardie, Ed.. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8558) 8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol. A. DeKok, J. Korhonen. April 2019. (Format: TXT, HTML) (Updates RFC5176, RFC5580) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8559) 8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents. A. Sajassi, Ed., S. Salam, N. Del Regno, J. Rabadan. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8560) 8561 A YANG Data Model for Microwave Radio Link. J. Ahlberg, M. Ye, X. Li, D. Spreafico, M. Vaupotic. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8561) 8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks. D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. April 2019. (Format: TXT, HTML) (Updates RFC5880) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8562) 8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails. D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8563) 8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL). M. Zhang, S. Pallagatti, V. Govindan. April 2019. (Format: TXT, HTML) (Updates RFC7175, RFC7177) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8564) 8565 Hypertext Jeopardy Protocol (HTJP/1.0). E. Fokschaner. 1 April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8565) 8567 Customer Management DNS Resource Records. E. Rye, R. Beverly. 1 April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8567) 8568 Network Virtualization Research Challenges. CJ. Bernardos, A. Rahman, JC. Zuniga, LM. Contreras, P. Aranda, P. Lynch. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8568) 8569 Content-Centric Networking (CCNx) Semantics. M. Mosko, I. Solis, C. Wood. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8569) 8570 IS-IS Traffic Engineering (TE) Metric Extensions. L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. March 2019. (Format: TXT, HTML) (Obsoletes RFC7810) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8570) 8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions. L. Ginsberg, Ed., S. Previdi, Q. Wu, J. Tantsura, C. Filsfils. March 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8571) 8572 Secure Zero Touch Provisioning (SZTP). K. Watsen, I. Farrer, M. Abrahamsson. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8572) 8573 Message Authentication Code for the Network Time Protocol. A. Malhotra, S. Goldberg. June 2019. (Format: TXT, HTML) (Updates RFC5905) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8573) 8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing. H. Van de Sompel, M. Nelson, G. Bilder, J. Kunze, S. Warner. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8574) 8575 YANG Data Model for the Precision Time Protocol (PTP). Y. Jiang, Ed., X. Liu, J. Xu, R. Cummings, Ed.. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8575) 8576 Internet of Things (IoT) Security: State of the Art and Challenges. O. Garcia-Morchon, S. Kumar, M. Sethi. April 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8576) 8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane. H. Sitaraman, V. Beeram, T. Parikh, T. Saad. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8577) 8578 Deterministic Networking Use Cases. E. Grossman, Ed.. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8578) 8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes. S. Bosch. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8579) 8580 Sieve Extension: File Carbon Copy (FCC). K. Murchison, B. Gondwana. May 2019. (Format: TXT, HTML) (Updates RFC5230, RFC5435) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8580) 8581 Diameter Agent Overload and the Peer Overload Report. S. Donovan. August 2019. (Format: TXT, HTML) (Updates RFC7683) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8581) 8582 Diameter Overload Rate Control. S. Donovan, Ed., E. Noel. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8582) 8583 Diameter Load Information Conveyance. B. Campbell, S. Donovan, Ed., JJ. Trottin. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8583) 8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility. J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. Drake, K. Nagaraj, S. Sathappan. April 2019. (Format: TXT, HTML) (Updates RFC7432) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8584) 8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service. J. Palet Martinez, H. M.-H. Liu, M. Kawashima. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8585) 8586 Loop Detection in Content Delivery Networks (CDNs). S. Ludin, M. Nottingham, N. Sullivan. April 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8586) 8587 NFS Version 4.0 Trunking Update. C. Lever, Ed., D. Noveck. May 2019. (Format: TXT, HTML) (Updates RFC7530) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8587) 8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN). C. Wendt, M. Barnes. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8588) 8589 The 'leaptofrogans' URI Scheme. A. Tamas, B. Phister, Ed., J-E. Rodriguez. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8589) 8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP). J. Gould, K. Feher. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8590) 8591 SIP-Based Messaging with S/MIME. B. Campbell, R. Housley. April 2019. (Format: TXT, HTML) (Updates RFC3261, RFC3428, RFC4975) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8591) 8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH). R. Browne, A. Chilikin, T. Mizrahi. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8592) 8593 Video Traffic Models for RTP Congestion Control Evaluations. X. Zhu, S. Mena, Z. Sarker. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8593) 8594 The Sunset HTTP Header Field. E. Wilde. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8594) 8595 An MPLS-Based Forwarding Plane for Service Function Chaining. A. Farrel, S. Bryant, J. Drake. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8595) 8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH). A. Malis, S. Bryant, J. Halpern, W. Henderickx. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8596) 8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS). LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, P. Iovanna. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8597) 8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2). T. Pauly, P. Wouters. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8598) 8599 Push Notification with the Session Initiation Protocol (SIP). C. Holmberg, M. Arnold. May 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8599) 8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange. N. Cam-Winget, Ed., S. Appala, S. Pope, P. Saint-Andre. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8600) 8601 Message Header Field for Indicating Message Authentication Status. M. Kucherawy. May 2019. (Format: TXT, HTML) (Obsoletes RFC7601) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8601) 8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses. J. Arkko, T. Hardie. July 2019. (Format: TXT, HTML) (Updates RFC3219) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8602) 8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile. M. Jenkins, L. Zieglar. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8603) 8604 Interconnecting Millions of Endpoints with Segment Routing. C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., W. Henderickx, D. Cooper. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8604) 8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP). S. Hollenbeck, R. Carney. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8605) 8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field. R. Jesske. June 2019. (Format: TXT, HTML) (Updates RFC3326) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8606) 8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments. C. Daboo, A. Quillaud, K. Murchison, Ed.. June 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8607) 8608 BGPsec Algorithms, Key Formats, and Signature Formats. S. Turner, O. Borchert. June 2019. (Format: TXT, HTML) (Obsoletes RFC8208) (Updates RFC7935) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8608) 8609 Content-Centric Networking (CCNx) Messages in TLV Format. M. Mosko, I. Solis, C. Wood. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8609) 8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures. H. Birkholz, C. Vigano, C. Bormann. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8610) 8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces. N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen. June 2019. (Format: TXT, HTML) (Updates RFC8029) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8611) 8612 DDoS Open Threat Signaling (DOTS) Requirements. A. Mortensen, T. Reddy, R. Moskowitz. May 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8612) 8613 Object Security for Constrained RESTful Environments (OSCORE). G. Selander, J. Mattsson, F. Palombini, L. Seitz. July 2019. (Format: TXT, HTML) (Updates RFC7252) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8613) 8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS). R. Singh, K. Kompella, S. Palislamovic. June 2019. (Format: TXT, HTML) (Updates RFC4761) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8614) 8615 Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. May 2019. (Format: TXT, HTML) (Obsoletes RFC5785) (Updates RFC7230, RFC7595) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8615) 8616 Email Authentication for Internationalized Mail. J. Levine. June 2019. (Format: TXT, HTML) (Updates RFC6376, RFC7208, RFC7489) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8616) 8617 The Authenticated Received Chain (ARC) Protocol. K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed.. July 2019. (Format: TXT, HTML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8617) 8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture. J. Dickinson, J. Hague, S. Dickinson, T. Manderson, J. Bond. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8618) 8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF). R. Housley. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8619) 8620 The JSON Meta Application Protocol (JMAP). N. Jenkins, C. Newman. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8620) 8621 The JSON Meta Application Protocol (JMAP) for Mail. N. Jenkins, C. Newman. August 2019. (Format: TXT, HTML) (Updates RFC5788) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8621) 8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services. R. Bless. June 2019. (Format: TXT, HTML) (Obsoletes RFC3662) (Updates RFC4594, RFC8325) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8622) 8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs). U. Palle, D. Dhody, Y. Tanaka, V. Beeram. June 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8623) 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC. P. Wouters, O. Sury. June 2019. (Format: TXT, HTML) (Obsoletes RFC6944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8624) 8625 Ethernet Traffic Parameters with Availability Information. H. Long, M. Ye, Ed., G. Mirsky, Ed., A. D'Alessandro, H. Shah. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8625) 8627 RTP Payload Format for Flexible Forward Error Correction (FEC). M. Zanaty, V. Singh, A. Begen, G. Mandyam. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8627) 8628 OAuth 2.0 Device Authorization Grant. W. Denniss, J. Bradley, M. Jones, H. Tschofenig. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8628) 8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension. B. Cheng, L. Berger, Ed.. July 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8629) 8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels. August 2019. (Format: TXT, HTML) (Obsoletes RFC7730) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8630) 8631 Link Relation Types for Web Services. E. Wilde. July 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8631) 8632 A YANG Data Model for Alarm Management. S. Vallin, M. Bjorklund. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8632) 8633 Network Time Protocol Best Current Practices. D. Reilly, H. Stenn, D. Sibold. July 2019. (Format: TXT, HTML) (Also BCP0223) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8633) 8634 BGPsec Router Certificate Rollover. B. Weis, R. Gagliano, K. Patel. August 2019. (Format: TXT, HTML) (Also BCP0224) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8634) 8635 Router Keying for BGPsec. R. Bush, S. Turner, K. Patel. August 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8635) 8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility. L. Hornquist Astrand, L. Zhu, M. Cullen, G. Hudson. July 2019. (Format: TXT, HTML) (Updates RFC4556) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8636) 8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN). D. Dhody, Y. Lee, D. Ceccarelli. July 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8637) 8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks. M. Xu, Y. Cui, J. Wu, S. Yang, C. Metz. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8638) 8639 Subscription to YANG Notifications. E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8639) 8640 Dynamic Subscription to YANG Events and Datastores over NETCONF. E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8640) 8641 Subscription to YANG Notifications for Datastore Updates. A. Clemm, E. Voit. September 2019. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8641) 8642 Policy Behavior for Well-Known BGP Communities. J. Borkenhagen, R. Bush, R. Bonica, S. Bayraktar. August 2019. (Format: TXT, HTML) (Updates RFC1997) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8642) 8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP). A. Johnston, B. Aboba, A. Hutton, R. Jesske, T. Stach. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8643) 8645 Re-keying Mechanisms for Symmetric Keys. S. Smyshlyaev, Ed.. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8645) 8649 Hash Of Root Key Certificate Extension. R. Housley. August 2019. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8649) 8650 Dynamic Subscription to YANG Events and Datastores over RESTCONF. E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8650) 8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension. B. Cheng, D. Wiggins, L. Berger, Ed.. October 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8651) 8652 A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD). X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8652) 8653 On-Demand Mobility Management. A. Yegin, D. Moses, S. Jeon. October 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8653) 8654 Extended Message Support for BGP. R. Bush, K. Patel, D. Ward. October 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC4271) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8654) 8655 Deterministic Networking Architecture. N. Finn, P. Thubert, B. Varga, J. Farkas. October 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8655) 8656 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). T. Reddy, Ed., A. Johnston, Ed., P. Matthews, J. Rosenberg. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5766, RFC6156) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8656) 8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding. H. Landau. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8657) 8658 RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P). S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair, Ed.. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8658) 8659 DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews. November 2019. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6844) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8659) 8660 Segment Routing with the MPLS Data Plane. A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8660) 8661 Segment Routing MPLS Interworking with LDP. A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8661) 8662 Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels. S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8662) 8663 MPLS Segment Routing over IP. X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8663) 8664 Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing. S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC8408) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8664) 8665 OSPF Extensions for Segment Routing. P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8665) 8666 OSPFv3 Extensions for Segment Routing. P. Psenak, Ed., S. Previdi, Ed.. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8666) 8667 IS-IS Extensions for Segment Routing. S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8667) 8668 Advertising Layer 2 Bundle Member Link Attributes in IS-IS. L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8668) 8669 Segment Routing Prefix Segment Identifier Extensions for BGP. S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8669) 8670 BGP Prefix Segment in Large-Scale Data Centers. C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8670) 8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP). T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang. November 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC7854) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8671) 8672 TLS Server Identity Pinning with Tickets. Y. Sheffer, D. Migault. October 2019. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8672) 8673 HTTP Random Access and Live Content. C. Pratt, D. Thakore, B. Stark. November 2019. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8673) 8674 The "safe" HTTP Preference. M. Nottingham. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8674) 8675 A YANG Data Model for Tunnel Interface Types. M. Boucadair, I. Farrer, R. Asati. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8675) 8676 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires. I. Farrer, Ed., M. Boucadair, Ed.. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8676) 8677 Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework. D. Trossen, D. Purkayastha, A. Rahman. November 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8677) 8678 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions. F. Baker, C. Bowers, J. Linkova. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8678) 8679 MPLS Egress Protection Framework. Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8679) 8680 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes. V. Roca, A. Begen. January 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6363) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8680) 8681 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME. V. Roca, B. Teibi. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8681) 8682 TinyMT32 Pseudorandom Number Generator (PRNG). M. Saito, M. Matsumoto, V. Roca, Ed., E. Baccelli. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8682) 8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks. J. Palet Martinez. November 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8683) 8684 TCP Extensions for Multipath Operation with Multiple Addresses. A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch. March 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6824) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8684) 8685 Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture. F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8685) 8686 Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery. S. Kiesel, M. Stiemerling. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8686) 8687 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels. A. Smirnov, A. Retana, M. Barnes. November 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC5786) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8687) 8688 A Session Initiation Protocol (SIP) Response Code for Rejected Calls. E.W. Burger, B. Nagda. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8688) 8689 SMTP Require TLS Option. J. Fenton. November 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8689) 8690 Clarification of Segment ID Sub-TLV Length for RFC 8287. N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC8287) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8690) 8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11. N. Benamar, J. Härri, J. Lee, T. Ernst. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8691) 8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs. P. Kampanakis, Q. Dang. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC3279) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8692) 8693 OAuth 2.0 Token Exchange. M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8693) 8694 Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering. D. King, H. Zheng. December 2019. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8694) 8695 A YANG Data Model for the Routing Information Protocol (RIP). X. Liu, P. Sarda, V. Choudhary. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8695) 8696 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS). R. Housley. December 2019. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8696) 8697 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs). I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka. January 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8697) 8698 Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media. X. Zhu, R. Pan, M. Ramalho, S. Mena. February 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8698) 8699 Coupled Congestion Control for RTP Media. S. Islam, M. Welzl, S. Gjessing. January 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8699) 8700 Fifty Years of RFCs. H. Flanagan, Ed.. December 2019. (Format: HTML, TXT, PDF, XML) (Updates RFC2555, RFC5540) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8700) 8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility. D. Benjamin. January 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8701) 8702 Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS). P. Kampanakis, Q. Dang. January 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3370) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8702) 8703 Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension. R. Taylor, S. Ratliff. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8703) 8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding. K. Sriram, D. Montgomery, J. Haas. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3704) (Also BCP0084) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8704) 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8705) 8706 Restart Signaling for IS-IS. L. Ginsberg, P. Wells. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5306) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8706) 8707 Resource Indicators for OAuth 2.0. B. Campbell, J. Bradley, H. Tschofenig. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8707) 8708 Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS). R. Housley. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8708) 8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol. B. Harris, L. Velvindron. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4253) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8709) 8710 Multipart Content-Format for the Constrained Application Protocol (CoAP). T. Fossati, K. Hartke, C. Bormann. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8710) 8711 Structure of the IETF Administrative Support Activity, Version 2.0. B. Haberman, J. Hall, J. Livingood. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4071, RFC4333, RFC7691) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8711) 8712 The IETF-ISOC Relationship. G. Camarillo, J. Livingood. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC2031) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8712) 8713 IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees. M. Kucherawy, Ed., R. Hinden, Ed., J. Livingood, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7437, RFC8318) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8713) 8714 Update to the Process for Selection of Trustees for the IETF Trust. J. Arkko, T. Hardie. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4371) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8714) 8715 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust. J. Arkko. February 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8715) 8716 Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC. P. Resnick, A. Farrel. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7776) (Also BCP0025) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8716) 8717 IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology. J. Klensin, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2028, RFC2418, RFC3005, RFC3710, RFC3929, RFC4633, RFC6702) (Also BCP0101) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8717) 8718 IETF Plenary Meeting Venue Selection Process. E. Lear, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0226) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8718) 8719 High-Level Guidance for the Meeting Policy of the IETF. S. Krishnan. February 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0226) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8719) 8720 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries. R. Housley, Ed., O. Kolkman, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7500) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8720) 8721 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents. J. Halpern, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5377) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8721) 8722 Defining the Role and Function of IETF Protocol Parameter Registry Operators. D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6220) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8722) 8723 Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP). C. Jennings, P. Jones, R. Barnes, A.B. Roach. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8723) 8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation. A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zúñiga. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8724) 8725 JSON Web Token Best Current Practices. Y. Sheffer, D. Hardt, M. Jones. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7519) (Also BCP0225) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8725) 8726 How Requests for IANA Action Will Be Handled on the Independent Stream. A. Farrel. November 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8726) 8727 JSON Binding of the Incident Object Description Exchange Format. T. Takahashi, R. Danyliw, M. Suzuki. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8727) 8728 RFC Editor Model (Version 2). O. Kolkman, Ed., J. Halpern, Ed., R. Hinden, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6635) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8728) 8729 The RFC Series and RFC Editor. R. Housley, Ed., L. Daigle, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC4844) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8729) 8730 Independent Submission Editor Model. N. Brownlee, Ed., B. Hinden, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6548) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8730) 8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448. A. Adamantiadis, S. Josefsson, M. Baushke. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8731) 8732 Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2. S. Sorce, H. Kario. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4462) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8732) 8733 Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE. D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8733) 8734 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3. L. Bruckert, J. Merkle, M. Lochter. February 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8734) 8735 Scenarios and Simulation Results of PCE in a Native IP Network. A. Wang, X. Huang, C. Kou, Z. Li, P. Mi. February 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8735) 8736 PIM Message Type Space Extension and Reserved Bits. S. Venaas, A. Retana. February 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC6166) (Updates RFC3973, RFC5015, RFC5059, RFC6754, RFC7761, RFC8364) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8736) 8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension. R.B. Shoemaker. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8737) 8738 Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B. Shoemaker. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8738) 8739 Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME). Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8739) 8740 Using TLS 1.3 with HTTP/2. D. Benjamin. February 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7540) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8740) 8741 Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP). A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8741) 8742 Concise Binary Object Representation (CBOR) Sequences. C. Bormann. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8742) 8743 Multiple Access Management Services Multi-Access Management Services (MAMS). S. Kanugovi, F. Baboescu, J. Zhu, S. Seo. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8743) 8744 Issues and Requirements for Server Name Identification (SNI) Encryption in TLS. C. Huitema. July 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8744) 8745 Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE. H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8745) 8746 Concise Binary Object Representation (CBOR) Tags for Typed Arrays. C. Bormann, Ed.. February 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8746) 8747 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs). M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8747) 8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP). R. Carney, G. Brown, J. Frakes. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8748) 8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status. W. Mekking, D. Mahoney. March 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6698, RFC6840) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8749) 8750 Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP). D. Migault, T. Guggemos, Y. Nir. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8750) 8751 Hierarchical Stateful Path Computation Element (PCE). D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8751) 8752 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE). M. Thomson, M. Nottingham. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8752) 8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions. J. Klensin, P. Fältström. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5892) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8753) 8754 IPv6 Segment Routing Header (SRH). C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8754) 8755 Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions. M. Jenkins. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8755) 8756 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS. M. Jenkins, L. Zieglar. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8756) 8757 Dynamic Link Exchange Protocol (DLEP) Latency Range Extension. B. Cheng, L. Berger, Ed.. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8757) 8758 Deprecating RC4 in Secure Shell (SSH). L. Velvindron. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4253) (Also BCP0227) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8758) 8759 RTP Payload for Timed Text Markup Language (TTML). J. Sandford. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8759) 8760 The Session Initiation Protocol (SIP) Digest Access Authentication Scheme. R. Shekh-Yusef. March 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8760) 8761 Video Codec Requirements and Evaluation Methodology. A. Filippov, A. Norkin, J.R. Alvarez. April 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8761) 8762 Simple Two-Way Active Measurement Protocol. G. Mirsky, G. Jun, H. Nydell, R. Foote. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8762) 8763 Deployment Considerations for Information-Centric Networking (ICN). A. Rahman, D. Trossen, D. Kutscher, R. Ravindran. April 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8763) 8764 Apple's DNS Long-Lived Queries Protocol. S. Cheshire, M. Krochmal. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8764) 8765 DNS Push Notifications. T. Pusateri, S. Cheshire. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8765) 8766 Discovery Proxy for Multicast DNS-Based Service Discovery. S. Cheshire. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8766) 8767 Serving Stale Data to Improve DNS Resiliency. D. Lawrence, W. Kumari, P. Sood. March 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC1034, RFC1035, RFC2181) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8767) 8768 Constrained Application Protocol (CoAP) Hop-Limit Option. M. Boucadair, T. Reddy.K, J. Shallow. March 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8768) 8769 Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR). J. Schaad. March 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8769) 8770 Host Router Support for OSPFv2. K. Patel, P. Pillay-Esnault, M. Bhardwaj, S. Bayraktar. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6987) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8770) 8771 The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO). A. Mayrhofer, J. Hague. 1 April 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8771) 8772 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP). S. Hu, D. Eastlake, F. Qin, T. Chua, D. Huang. May 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8772) 8773 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key. R. Housley. March 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8773) 8774 The Quantum Bug. M. Welzl. 1 April 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8774) 8775 PIM Designated Router Load Balancing. Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8775) 8776 Common YANG Data Types for Traffic Engineering. T. Saad, R. Gandhi, X. Liu, V. Beeram, I. Bryskin. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8776) 8777 DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery. J. Holland. April 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7450) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8777) 8778 Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE). R. Housley. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8778) 8779 Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS. C. Margaria, Ed., O. Gonzalez de Dios, Ed., F. Zhang, Ed.. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8779) 8780 The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA). Y. Lee, Ed., R. Casellas, Ed.. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8780) 8781 Discovering PREF64 in Router Advertisements. L. Colitti, J. Linkova. April 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8781) 8782 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification. T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague. May 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8782) 8783 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification. M. Boucadair, Ed., T. Reddy.K, Ed.. May 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8783) 8784 Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security. S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8784) 8785 JSON Canonicalization Scheme (JCS). A. Rundgren, B. Jordan, S. Erdtman. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8785) 8786 Updated Rules for Processing Stateful PCE Request Parameters Flags. A. Farrel. May 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8231) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8786) 8787 Location Source Parameter for the SIP Geolocation Header Field. J. Winterbottom, R. Jesske, B. Chatras, A. Hutton. May 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6442) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8787) 8788 Eligibility for the 2020-2021 Nominating Committee. B. Leiba. May 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0010) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8788) 8789 IETF Stream Documents Require IETF Rough Consensus. J. Halpern, Ed., E. Rescorla, Ed.. June 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8789) 8790 FETCH and PATCH with Sensor Measurement Lists (SenML). A. Keränen, M. Mohajer. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8790) 8791 YANG Data Structure Extensions. A. Bierman, M. Björklund, K. Watsen. June 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8340) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8791) 8792 Handling Long Lines in Content of Internet-Drafts and RFCs. K. Watsen, E. Auerswald, A. Farrel, Q. Wu. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8792) 8793 Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology. B. Wissingh, C. Wood, A. Afanasyev, L. Zhang, D. Oran, C. Tschudin. June 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8793) 8794 Extensible Binary Meta Language. S. Lhomme, D. Rice, M. Bunkus. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8794) 8795 YANG Data Model for Traffic Engineering (TE) Topologies. X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Gonzalez de Dios. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8795) 8796 RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels. M. Taillon, T. Saad, Ed., R. Gandhi, A. Deshmukh, M. Jork, V. Beeram. July 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4090) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8796) 8797 Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1. C. Lever. June 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8166) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8797) 8798 Additional Units for Sensor Measurement Lists (SenML). C. Bormann. June 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8798) 8799 Limited Domains and Internet Protocols. B. Carpenter, B. Liu. July 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8799) 8800 Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling. S. Litkowski, S. Sivabalan, C. Barth, M. Negi. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8800) 8801 Discovering Provisioning Domain Names and Data. P. Pfister, É. Vyncke, T. Pauly, D. Schinazi, W. Shao. July 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8801) 8802 The Quality for Service (Q4S) Protocol. J.J. Aranda, M. Cortes, J. Salvachúa, M. Narganes, I. Martínez-Sarriegui. July 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8802) 8803 0-RTT TCP Convert Protocol. O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans. July 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8803) 8804 Content Delivery Network Interconnection (CDNI) Request Routing Extensions. O. Finkelman, S. Mishra. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8804) 8805 A Format for Self-Published IP Geolocation Feeds. E. Kline, K. Duleba, Z. Szamonek, S. Moser, W. Kumari. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8805) 8806 Running a Root Server Local to a Resolver. W. Kumari, P. Hoffman. June 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7706) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8806) 8807 Login Security Extension for the Extensible Provisioning Protocol (EPP). J. Gould, M. Pozun. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8807) 8808 A YANG Data Model for Factory Default Settings. Q. Wu, B. Lengyel, Y. Niu. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8808) 8809 Registries for Web Authentication (WebAuthn). J. Hodges, G. Mandyam, M. Jones. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8809) 8810 Revision to Capability Codes Registration Procedures. J. Scudder. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5492) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8810) 8811 DDoS Open Threat Signaling (DOTS) Architecture. A. Mortensen, Ed., T. Reddy.K, Ed., F. Andreasen, N. Teague, R. Compton. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8811) 8812 CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms. M. Jones. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8812) 8813 Clarifications for Elliptic Curve Cryptography Subject Public Key Information. T. Ito, S. Turner. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5480) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8813) 8814 Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State. J. Tantsura, U. Chunduri, K. Talaulikar, G. Mirsky, N. Triantafillis. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8814) 8815 Deprecating Any-Source Multicast (ASM) for Interdomain Multicast. M. Abrahamsson, T. Chown, L. Giuliano, T. Eckert. August 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0229) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8815) 8817 RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec. V. Demjanenko, J. Punaro, D. Satterlee. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8817) 8818 Distributed Mobility Anchoring. H. Chan, Ed., X. Wei, J. Lee, S. Jeon, CJ. Bernardos, Ed.. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8818) 8820 URI Design and Ownership. M. Nottingham. June 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7320) (Updates RFC3986) (Also BCP0190) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8820) 8874 Working Group GitHub Usage Guidance. M. Thomson, B. Stark. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8874) 8875 Working Group GitHub Administration. A. Cooper, P. Hoffman. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8875) 8876 Non-interactive Emergency Calls. B. Rosen, H. Schulzrinne, H. Tschofenig, R. Gellens. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8876) 8877 Guidelines for Defining Packet Timestamps. T. Mizrahi, J. Fabini, A. Morton. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8877) 8880 Special Use Domain Name 'ipv4only.arpa'. S. Cheshire, D. Schinazi. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7050) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8880) 8881 Network File System (NFS) Version 4 Minor Version 1 Protocol. D. Noveck, Ed., C. Lever. August 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5661) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8881) 8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements. C. Huitema, D. Kaiser. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8882) 8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits. T. Herbert. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8883) 8884 Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios. J. Seedorf, M. Arumaithurai, A. Tagami, K. Ramakrishnan, N. Blefari-Melazzi. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8884) 8885 Proxy Mobile IPv6 Extensions for Distributed Mobility Management. CJ. Bernardos, A. de la Oliva, F. Giust, JC. Zúñiga, A. Mourad. October 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8885) 8886 Secure Device Install. W. Kumari, C. Doyle. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8886) 8887 A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket. K. Murchison. August 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8887) 8889 Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring. G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto. August 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8889) 8890 The Internet is for End Users. M. Nottingham. August 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8890) 8891 GOST R 34.12-2015: Block Cipher "Magma". V. Dolmatov, Ed., D. Baryshkov. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5830) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8891) 8892 Guidelines and Registration Procedures for Interface Types and Tunnel Types. D. Thaler, D. Romascanu. August 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2863) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8892) 8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export. R. Bush, R. Volk, J. Heitz. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6811) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8893) 8894 Simple Certificate Enrolment Protocol. P. Gutmann. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8894) 8895 Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE). W. Roome, Y. Yang. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8895) 8896 Application-Layer Traffic Optimization (ALTO) Cost Calendar. S. Randriamasy, R. Yang, Q. Wu, L. Deng, N. Schwan. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8896) 8897 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties. D. Ma, S. Kent. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8897) 8898 Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP). R. Shekh-Yusef, C. Holmberg, V. Pascual. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC3261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8898) 8899 Packetization Layer Path MTU Discovery for Datagram Transports. G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4821, RFC4960, RFC6951, RFC8085, RFC8261) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8899) 8900 IP Fragmentation Considered Fragile. R. Bonica, F. Baker, G. Huston, R. Hinden, O. Troan, F. Gont. September 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0230) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8900) 8901 Multi-Signer DNSSEC Models. S. Huque, P. Aras, J. Dickinson, J. Vcelak, D. Blacka. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8901) 8902 TLS Authentication Using Intelligent Transport System (ITS) Certificates. M. Msahli, Ed., N. Cam-Winget, Ed., W. Whyte, Ed., A. Serhrouchni, H. Labiod. September 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8902) 8904 DNS Whitelist (DNSWL) Email Authentication Method Extension. A. Vesely. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8904) 8905 The 'payto' URI Scheme for Payments. F. Dold, C. Grothoff. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8905) 8906 A Common Operational Problem in DNS Servers: Failure to Communicate. M. Andrews, R. Bellis. September 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0231) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8906) 8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol. T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant. September 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8907) 8908 Captive Portal API. T. Pauly, Ed., D. Thakore, Ed.. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8908) 8909 Registry Data Escrow Specification. G. Lozano. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8909) 8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs). W. Kumari, E. Kline. September 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC7710) (Updates RFC3679) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8910) 8914 Extended DNS Errors. W. Kumari, E. Hunt, R. Arends, W. Hardaker, D. Lawrence. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8914) 8915 Network Time Security for the Network Time Protocol. D. Franke, D. Sibold, K. Teichel, M. Dansarie, R. Sundblad. September 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8915) 8916 A YANG Data Model for the Multicast Source Discovery Protocol (MSDP). X. Liu, Z. Zhang, Ed., A. Peter, M. Sivakumar, F. Guo, P. McAllister. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8916) 8917 The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag. R. Gellens, B. Rosen. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5222) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8917) 8918 Invalid TLV Handling in IS-IS. L. Ginsberg, P. Wells, T. Li, T. Przygienda, S. Hegde. September 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5305, RFC6232) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8918) 8919 IS-IS Application-Specific Link Attributes. L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8919) 8920 OSPF Application-Specific Link Attributes. P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8920) 8921 Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP). M. Boucadair, Ed., C. Jacquenet, D. Zhang, P. Georgatsos. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8921) 8922 A Survey of the Interaction between Security Protocols and Transport Services. T. Enghardt, T. Pauly, C. Perkins, K. Rose, C. Wood. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8922) 8923 A Minimal Set of Transport Services for End Systems. M. Welzl, S. Gjessing. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8923) 8924 Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework. S. Aldrin, C. Pignataro, Ed., N. Kumar, Ed., R. Krishnan, A. Ghanwani. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8924) 8925 IPv6-Only Preferred Option for DHCPv4. L. Colitti, J. Linkova, M. Richardson, T. Mrugalski. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC2563) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8925) 8926 Geneve: Generic Network Virtualization Encapsulation. J. Gross, Ed., I. Ganga, Ed., T. Sridhar, Ed.. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8926) 8927 JSON Type Definition. U. Carion. November 2020. (Format: HTML, TXT, PDF, XML) (Status: EXPERIMENTAL) (DOI: 10.17487/RFC8927) 8928 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks. P. Thubert, Ed., B. Sarikaya, M. Sethi, R. Struik. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC8505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8928) 8929 IPv6 Backbone Router. P. Thubert, Ed., C.E. Perkins, E. Levy-Abegnoli. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6775, RFC8505) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8929) 8930 On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network. T. Watteyne, Ed., P. Thubert, Ed., C. Bormann. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8930) 8931 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery. P. Thubert, Ed.. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC4944) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8931) 8932 Recommendations for DNS Privacy Service Operators. S. Dickinson, B. Overeinder, R. van Rijswijk-Deij, A. Mankin. October 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0232) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8932) 8933 Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection. R. Housley. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5652) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8933) 8934 PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE. H. Chen, Ed., Y. Zhuang, Ed., Q. Wu, D. Ceccarelli. October 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8934) 8937 Randomness Improvements for Security Protocols. C. Cremers, L. Garratt, S. Smyshlyaev, N. Sullivan, C. Wood. October 2020. (Format: HTML, TXT, PDF, XML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC8937) 8940 Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP). A. DeKok. October 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC5247) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8940) 8943 Concise Binary Object Representation (CBOR) Tags for Date. M. Jones, A. Nadalin, J. Richter. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8943) 8944 A YANG Data Model for Layer 2 Network Topologies. J. Dong, X. Wei, Q. Wu, M. Boucadair, A. Liu. November 2020. (Format: HTML, TXT, PDF, XML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8944) 8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop. S. Litkowski, S. Agrawal, K. Ananthamurthy, K. Patel. November 2020. (Format: HTML, TXT, PDF, XML) (Obsoletes RFC5549) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8950) 8951 Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1. M. Richardson, T. Werner, W. Pan. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC7030) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8951) 8954 Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed.. November 2020. (Format: HTML, TXT, PDF, XML) (Updates RFC6960) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8954) 8961 Requirements for Time-Based Loss Detection. M. Allman. November 2020. (Format: HTML, TXT, PDF, XML) (Also BCP0233) (Status: BEST CURRENT PRACTICE) (DOI: 10.17487/RFC8961) ./draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt0000644000764400076440000013226012665667627023012 0ustar iustyiusty AVTCORE WG J. Lennox Internet-Draft Vidyo Intended status: Standards Track M. Westerlund Expires: September 3, 2016 Ericsson Q. Wu Huawei C. Perkins University of Glasgow March 2, 2016 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback draft-ietf-avtcore-rtp-multi-stream-optimisation-12 Abstract RTP allows multiple RTP streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 3, 2016. Lennox, et al. Expires September 3, 2016 [Page 1] Internet-Draft Grouping RTCP Reception Statistics March 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTCP Reporting Groups . . . . . . . . . . . . . . . . . . . . 3 3.1. Semantics and Behaviour of RTCP Reporting Groups . . . . 4 3.2. Identifying Members of an RTCP Reporting Group . . . . . 5 3.2.1. Definition and Use of the RTCP RGRP SDES Item . . . . 5 3.2.2. Definition and Use of the RTCP RGRS Packet . . . . . 6 3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 8 3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 12 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 12 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for group communication, supporting multiparty multimedia sessions. A single RTP session can support multiple participants sending at once, and can also support participants sending multiple simultaneous RTP streams. Examples of the latter might include a participant with multiple cameras who chooses to send multiple views of a scene, or a participant that sends audio and video flows multiplexed in a single RTP session. Rules for handling RTP sessions containing multiple RTP Lennox, et al. Expires September 3, 2016 [Page 2] Internet-Draft Grouping RTCP Reception Statistics March 2016 streams are described in [RFC3550] with some clarifications in [I-D.ietf-avtcore-rtp-multi-stream]. An RTP endpoint will have one or more synchronisation sources (SSRCs). It will have at least one RTP Stream, and thus SSRC, for each media source it sends, and might use multiple SSRCs per media source when using media scalability features [RFC6190], forward error correction, RTP retransmission [RFC4588], or similar mechanisms. An endpoint that is not sending any RTP stream, will have at least one SSRC to use for reporting and any feedback messages. Each SSRC has to send RTCP sender reports corresponding to the RTP packets it sends, and receiver reports for traffic it receives. That is, every SSRC will send RTCP packets to report on every other SSRC. This rule is simple, but can be quite inefficient for endpoints that send large numbers of RTP streams in a single RTP session. Consider a session comprising ten participants, each sending three media sources, each with their own RTP stream. There will be 30 SSRCs in such an RTP session, and each of those 30 SSRCs will send an RTCP Sender Report/ Receiver Report packet (containing several report blocks) per reporting interval as each SSRC reports on all the others. However, the three SSRCs comprising each participant are commonly co-located such that they see identical reception quality. If there was a way to indicate that several SSRCs are co-located, and see the same reception quality, then two-thirds of those RTCP reports could be suppressed. This would allow the remaining RTCP reports to be sent more often, while keeping within the same RTCP bandwidth fraction. This memo defines such an RTCP extension, RTCP Reporting Groups. This extension is used to indicate the SSRCs that originate from the same endpoint, and therefore have identical reception quality, hence allowing the endpoints to suppress unnecessary RTCP reception quality reports. 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]. 3. RTCP Reporting Groups An RTCP Reporting Group is a set of synchronization sources (SSRCs) that are co-located at a single endpoint (which could be an end host or a middlebox) in an RTP session. Since they are co-located, every SSRC in the RTCP reporting group will have an identical view of the network conditions, and see the same lost packets, jitter, etc. This allows a single representative to send RTCP reception quality reports Lennox, et al. Expires September 3, 2016 [Page 3] Internet-Draft Grouping RTCP Reception Statistics March 2016 on behalf of the rest of the reporting group, reducing the number of RTCP packets that need to be sent without loss of information. 3.1. Semantics and Behaviour of RTCP Reporting Groups A group of co-located SSRCs that see identical network conditions can form an RTCP reporting group. If reporting groups are in use, an RTP endpoint with multiple SSRCs MAY put those SSRCs into a reporting group if their view of the network is identical; i.e., if they report on traffic received at the same interface of an RTP endpoint. SSRCs with different views of the network MUST NOT be put into the same reporting group. An endpoint that has combined its SSRCs into an RTCP reporting group will choose one (or a subset) of those SSRCs to act as "reporting source(s)" for that RTCP reporting group. A reporting source will send RTCP SR/RR reception quality reports on behalf of the other members of the RTCP reporting group. A reporting source MUST suppress the RTCP SR/RR reports that relate to other members of the reporting group, and only report on remote SSRCs. The other members (non reporting sources) of the RTCP reporting group will suppress their RTCP reception quality reports, and instead send an RTCP RGRS packet (see Section 3.2.2) to indicate that they are part of an RTCP reporting group and give the SSRCs of the reporting sources. If there are large numbers of remote SSRCs in the RTP session, then the reception quality reports generated by the reporting source might grow too large to fit into a single compound RTCP packet, forcing the reporting source to use a round-robin policy to determine what remote SSRCs it includes in each compound RTCP packet, and so reducing the frequency of reports on each SSRC. To avoid this, in sessions with large numbers of remote SSRCs, an RTCP reporting group MAY use more than one reporting source. If several SSRCs are acting as reporting sources for an RTCP reporting group, then each reporting source MUST have non-overlapping sets of remote SSRCs it reports on. An endpoint MUST NOT create an RTCP reporting group that comprises only a single local SSRC (i.e., an RTCP reporting group where the reporting source is the only member of the group), unless it is anticipated that the group might have additional SSRCs added to it in the future. If a reporting source leaves the RTP session (i.e., if it sends a RTCP BYE packet, or leaves the session without sending BYE under the rules of [RFC3550] section 6.3.7), the remaining members of the RTCP reporting group MUST either (a) have another reporting source, if one exists, report on the remote SSRCs the leaving SSRC reported on, (b) choose a new reporting source, or (c) disband the RTCP reporting Lennox, et al. Expires September 3, 2016 [Page 4] Internet-Draft Grouping RTCP Reception Statistics March 2016 group and begin sending reception quality reports following [RFC3550] and [I-D.ietf-avtcore-rtp-multi-stream]. The RTCP timing rules assign different bandwidth fractions to senders and receivers. This lets senders transmit RTCP reception quality reports more often than receivers. If a reporting source in an RTCP reporting group is a receiver, but one or more non-reporting SSRCs in the RTCP reporting group are senders, then the endpoint MAY treat the reporting source as a sender for the purpose of RTCP bandwidth allocation, increasing its RTCP bandwidth allocation, provided it also treats one of the senders as if it were a receiver and makes the corresponding reduction in RTCP bandwidth for that SSRC. However, the application needs to consider the impact on the frequency of transmitting of the synchronization information included in RTCP Sender Reports. 3.2. Identifying Members of an RTCP Reporting Group When RTCP Reporting Groups are in use, the other SSRCs in the RTP session need to be able to identify which SSRCs are members of an RTCP reporting group. Two RTCP extensions are defined to support this: the RTCP RGRP SDES item is used by the reporting source(s) to identify an RTCP reporting group, and the RTCP RGRS packet is used by other members of an RTCP reporting group to identify the reporting source(s). 3.2.1. Definition and Use of the RTCP RGRP SDES Item This document defines a new RTCP SDES item to identify an RTCP reporting group. The motivation for giving a reporting group an identify is to ensure that the RTCP reporting group and its member SSRCs can be correctly associated when there are multiple reporting sources, and to ensure that a reporting SSRC can be associated with the correct reporting group if an SSRC collision occurs. This document defines the RTCP Source Description (SDES) RGRP item. The RTCP SDES RGRP item MUST be sent by the reporting sources in a reporting group, and MUST NOT be sent by other members of the reporting group or by SSRCs that are not members of any RTCP reporting group. Specifically, every reporting source in an RTCP reporting group MUST include an RTCP SDES packet containing an RGRP item in every compound RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Syntactically, the format of the RTCP SDES RGRP item is identical to that of the RTCP SDES CNAME item [RFC7022], except that the SDES item type field MUST have value RGRP=(TBA) instead of CNAME=1. The value Lennox, et al. Expires September 3, 2016 [Page 5] Internet-Draft Grouping RTCP Reception Statistics March 2016 of the RTCP SDES RGRP item MUST be chosen with the same concerns about global uniqueness and the same privacy considerations as the RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable throughout the lifetime of the reporting group, even if some or all of the reporting sources change their SSRC due to collisions, or if the set of reporting sources changes. Note to RFC Editor: please replace (TBA) in the above paragraph with the RTCP SDES item type number assigned to the RGRP item, then delete this note. An RTP mixer or translator that forwards RTCP SR or RR packets from members of a reporting group MUST forward the corresponding RTCP SDES RGRP items as well, even if it otherwise strips SDES items other than the CNAME item. 3.2.2. Definition and Use of the RTCP RGRS Packet A new RTCP packet type is defined to allow the members of an RTCP reporting group to identify the reporting sources for that group. This allows participants in an RTP session to distinguish an SSRC that is sending empty RTCP reception reports because it is a member of an RTCP reporting group, from an SSRC that is sending empty RTCP reception reports because it is not receiving any traffic. It also explicitly identifies the reporting sources, allowing other members of the RTP session to know which SSRCs are acting as the reporting sources for an RTCP reporting group, and allowing them to detect if RTCP packets from any of the reporting sources are being lost. The format of the RTCP RGRS packet is defined below. It comprises the fixed RTCP header that indicates the packet type and length, the SSRC of the packet sender, and a list of reporting sources for the RTCP reporting group of which the packet sender is a member. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=RGRS(TBA) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : List of SSRC(s) for the Reporting Source(s) : : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the RTCP RGRS packet have the following definition: Lennox, et al. Expires September 3, 2016 [Page 6] Internet-Draft Grouping RTCP Reception Statistics March 2016 version (V): 2 bits unsigned integer. This field identifies the RTP version. The current RTP version is 2. padding (P): 1 bit. If set, the padding bit indicates that the RTCP packet contains additional padding octets at the end that are not part of the control information but are included in the length field. See [RFC3550]. Source Count (SC): 5 bits unsigned integer. Indicates the number of reporting source SSRCs that are included in this RTCP packet. As the RTCP RGRS packet MUST NOT be not sent by reporting sources, all the SSRCs in the list of reporting sources will be different from the SSRC of the packet sender. Every RTCP RGRS packet MUST contain at least one reporting source SSRC. Payload type (PT): 8 bits unsigned integer. The RTCP packet type number that identifies the packet as being an RTCP RGRS packet. The RGRS RTCP packet has the value [TBA]. Note to RFC Editor: please replace [TBA] here, and in the packet format diagram above, with the RTCP packet type that IANA assigns to the RTCP RGRS packet. Length: 16 bits unsigned integer. The length of this packet in 32-bit words minus one, including the header and any padding. This is in line with the definition of the length field used in RTCP sender and receiver reports [RFC3550]. Since all RTCP RGRS packets include at least one reporting source SSRC, the length will always be 2 or greater. SSRC of packet sender: 32 bits. The SSRC of the sender of this packet. List of SSRCs for the Reporting Source(s): A variable length size (as indicated by SC header field) of the 32 bit SSRC values of the reporting sources for the RTCP Reporting Group of which the packet sender is a member. Every source that belongs to an RTCP reporting group but is not a reporting source MUST include an RTCP RGRS packet in every compound RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Each RTCP RGRS packet MUST contain the SSRC identifier of at least one reporting source. If there are more reporting sources in an RTCP reporting group than can fit into an RTCP RGRS packet, the members of that reporting group MUST send the SSRCs of the reporting sources in a round-robin fashion in consecutive RTCP RGRS packets, such that all Lennox, et al. Expires September 3, 2016 [Page 7] Internet-Draft Grouping RTCP Reception Statistics March 2016 the SSRCs of the reporting sources are included over the course of several RTCP reporting intervals. An RTP mixer or translator that forwards RTCP SR or RR packets from members of a reporting group MUST also forward the corresponding RGRS RTCP packets. If the RTP mixer or translator rewrites SSRC values of the packets it forwards, it MUST make the corresponding changes to the RTCP RGRS packets. 3.3. Interactions with the RTP/AVPF Feedback Profile Use of the RTP/AVPF Feedback Profile [RFC4585] allows SSRCs to send rapid RTCP feedback requests and codec control messages. If use of the RTP/AVPF profile has been negotiated in an RTP session, members of an RTCP reporting group can send rapid RTCP feedback and codec control messages following [RFC4585] and [RFC5104], as updated by Section 5.4 of [I-D.ietf-avtcore-rtp-multi-stream], and by the following considerations. The members of an RTCP reporting group will all see identical network conditions. Accordingly, one might therefore think that it doesn't matter which SSRC in the reporting group sends the RTP/AVPF feedback or codec control messages. There might be, however, cases where the sender of the feedback/codec control message has semantic importance, or when only a subset of the members of an RTCP reporting group might want to send RTP/AVPF feedback or a codec control message in response to a particular event. For example, an RTP video sender might choose to treat packet loss feedback received from SSRCs known to be audio receivers with less urgency than feedback that it receives from video receivers when deciding what packets to retransmit, and a multimedia receiver using reporting groups might want to choose the outgoing SSRC for feedback packets to reflect this. Each member of an RTCP reporting group SHOULD therefore send RTP/AVPF feedback/codec control messages independently of the other members of the reporting group, to respect the semantic meaning of the message sender. The suppression rules of [RFC4585] will ensure that only a single copy of each feedback packet is (typically) generated, even if several members of a reporting group send the same feedback. When an endpoint knows that several members of its RTCP reporting group will be sending identical feedback, and that the sender of the feedback is not semantically important, then that endpoint MAY choose to send all its feedback from the reporting source and deterministically suppress feedback packets generated by the other sources in the reporting group. It is important to note that the RTP/AVPF timing rules operate on a per-SSRC basis. Using a single reporting source to send all feedback Lennox, et al. Expires September 3, 2016 [Page 8] Internet-Draft Grouping RTCP Reception Statistics March 2016 for a reporting group will hence limit the amount of feedback that can be sent to that which can be sent by one SSRC. If this limit is a problem, then the reporting group can allow each of its members to send its own feedback, using its own SSRC. If the RTP/AVPF feedback messages or codec control requests are sent as compound RTCP packets, then those compound RTCP packets MUST include either an RTCP RGRS packet or an RTCP SDES RGRP item, depending on whether they are sent by the reporting source or a non- reporting source in the RTCP reporting group respectively. The contents of non-compound RTCP feedback or codec control messages are not affected by the use of RTCP reporting groups. 3.4. Interactions with RTCP Extended Report (XR) Packets When using RTCP Extended Reports (XR) [RFC3611] with RTCP reporting groups, it is RECOMMENDED that the reporting source is used to send the RTCP XR packets. If multiple reporting sources are in use, the reporting source that sends the SR/RR packets that relate to a particular remote SSRC SHOULD send the RTCP XR reports about that SSRC. This is motivated as one commonly combine the RTCP XR metrics with the regular report block to more fully understand the situation. Receiving these blocks in different compound packets reduces their value as the measuring intervals are not synchronized in those cases. Some RTCP XR report blocks are specific to particular types of media, and might be relevant to only some members of a reporting group. For example, it would make no sense for an SSRC that is receiving video to send a VoIP metric RTCP XR report block. Such media specific RTCP XR report blocks MUST be sent by the SSRC to which they are relevant, and MUST NOT be included in the common report sent by the reporting source. This might mean that some SSRCs send RTCP XR packets in compound RTCP packets that contain an empty RTCP SR/RR packet, and that the time period covered by the RTCP XR packet is different to that covered by the RTCP SR/RR packet. If it is important that the RTCP XR packet and RTCP SR/RR packet cover the same time period, then that source SHOULD be removed from the RTCP reporting group, and send standard RTCP packets instead. 3.5. Middlebox Considerations Many different types of middlebox are used with RTP. RTCP reporting groups are potentially relevant to those types of RTP middlebox that have their own SSRCs and generate RTCP reports for the traffic they receive. RTP middleboxes that do not have their own SSRC, and that don't send RTCP reports on the traffic they receive, cannot use the RTCP reporting groups extension, since they generate no RTCP reports to group. Lennox, et al. Expires September 3, 2016 [Page 9] Internet-Draft Grouping RTCP Reception Statistics March 2016 An RTP middlebox that has several SSRCs of its own can use the RTCP reporting groups extension to group the RTCP reports it generates. This can occur, for example, if a middlebox is acting as an RTP mixer for both audio and video flows that are multiplexed onto a single RTP session, where the middlebox has one SSRC for the audio mixer and one for the video mixer part, and when the middlebox wants to avoid cross reporting between audio and video. A middlebox cannot use the RTCP reporting groups extension to group RTCP packets from the SSRCs that it is forwarding. It can, however, group the RTCP packets from the SSRCs it is forwarding into compound RTCP packets following the rules in Section 6.1 of [RFC3550] and Section 5.3 of [I-D.ietf-avtcore-rtp-multi-stream]. If the middlebox is using RTCP reporting groups for its own SSRCs, it MAY include RTCP packets from the SSRCs that it is forwarding as part of the compound RTCP packets its reporting source generates. A middlebox that forwards RTCP SR or RR packets sent by members of a reporting group MUST forward the corresponding RTCP SDES RGRP items, as described in Section 3.2.1. A middlebox that forwards RTCP SR or RR packets sent by member of a reporting group MUST also forward the corresponding RTCP RGRS packets, as described in Section 3.2.2. Failure to forward these packets can cause compatibility problems, as described in Section 4.2. If a middlebox rewrites SSRC values in the RTP and RTCP packets that it is forwarding, then it MUST make the corresponding changes in RTCP SDES packets containing RGRP items and in RTCP RGRS packets, to allow them to be associated with the rewritten SSRCs. 3.6. SDP Signalling for Reporting Groups This document defines the "a=rtcp-rgrp" Session Description Protocol (SDP) [RFC4566] attribute to indicate if the session participant is capable of supporting RTCP Reporting Groups for applications that use SDP for configuration of RTP sessions. It is a property attribute, and hence takes no value. The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] is IDENTICAL, as the functionality applies on RTP session level. A participant that proposes the use of RTCP Reporting Groups SHALL itself support the reception of RTCP Reporting Groups. The formal definition of this attribute is: Lennox, et al. Expires September 3, 2016 [Page 10] Internet-Draft Grouping RTCP Reception Statistics March 2016 Name: rtcp-rgrp Value: Usage Level: session, media Charset Dependent: no Example: a=rtcp-rgrp When using SDP Offer/Answer [RFC3264], the following procedures are to be used: o Generating the initial SDP offer: If the offerer supports the RTCP reporting group extensions, and is willing to accept RTCP packets containing those extensions, then it MUST include an "a=rtcp-rgrp" attribute in the initial offer. If the offerer does not support RTCP reporting groups extensions, or is not willing to accept RTCP packets containing those extensions, then it MUST NOT include the "a=rtcp-rgrp" attribute in the offer. o Generating the SDP answer: If the SDP offer contains an "a=rtcp- rgrp" attribute, and if the answerer supports RTCP reporting groups and is willing to receive RTCP packets using the RTCP reporting groups extensions, then the answerer MAY include an "a=rtcp-rgrp" attribute in the answer and MAY send RTCP packets containing the RTCP reporting groups extensions. If the offer does not contain an "a=rtcp-rgrp" attribute, or if the offer does contain such an attribute but the answerer does not wish to accept RTCP packets using the RTCP reporting groups extensions, then the answer MUST NOT include an "a=rtcp-rgrp" attribute. o Offerer Processing of the SDP Answer: If the SDP answer contains an "a=rtcp-rgrp" attribute, and the corresponding offer also contained an "a=rtcp-rgrp" attribute, then the offerer MUST be prepared to accept and process RTCP packets that contain the reporting groups extension, and MAY send RTCP packets that contain the reporting groups extension. If the SDP answer contains an "a=rtcp-rgrp" attribute, but the corresponding offer did not contain the "a=rtcp-rgrp" attribute, then the offerer MUST reject the call. If the SDP answer does not contain an "a=rtcp-rgrp" attribute, then the offerer MUST NOT send packets containing the RTCP reporting groups extensions, and does not need to process packet containing the RTCP reporting groups extensions. In declarative usage of SDP, such as the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) [RFC2974], the presence of the attribute indicates that the session participant MAY use RTCP Reporting Groups in its RTCP transmissions. An implementation that doesn't explicitly support RTCP Reporting Groups MAY join a RTP session as long as it has been verified that Lennox, et al. Expires September 3, 2016 [Page 11] Internet-Draft Grouping RTCP Reception Statistics March 2016 the implementation doesn't suffer from the problems discussed in Section 4.2. 4. Properties of RTCP Reporting Groups This section provides additional information on what the resulting properties are with the design specified in Section 3. The content of this section is non-normative. 4.1. Bandwidth Benefits of RTCP Reporting Groups To understand the benefits of RTCP reporting groups, consider a scenario in which the two endpoints in a session each have a hundred sources, of which eight each are sending within any given reporting interval. For ease of analysis, we can make the simplifying approximation that the duration of the RTCP reporting interval is equal to the total size of the RTCP packets sent during an RTCP interval, divided by the RTCP bandwidth. (This will be approximately true in scenarios where the bandwidth is not so high that the minimum RTCP interval is reached.) For further simplification, we can assume RTCP senders are following the recommendations regarding Compound RTCP Packets in [I-D.ietf-avtcore-rtp-multi-stream]; thus, the per-packet transport- layer overhead will be small relative to the RTCP data. Thus, only the actual RTCP data itself need be considered. In a report interval in this scenario, there will, as a baseline, be 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to approximately 6.5 kB of RTCP per report interval, assuming 16-byte CNAMEs and no other SDES information. Using the original [RFC3550] everyone-reports-on-every-sender feedback rules, each of the 184 receivers will send 16 report blocks, and each of the 16 senders will send 15. This amounts to approximately 76 kB of report block traffic per interval; 92% of RTCP traffic consists of report blocks. If reporting groups are used, however, there is only 0.4 kB of reports per interval, with no loss of useful information. Additionally, there will be (assuming 16-byte RGRPs, and a single reporting source per reporting group) an additional 2.4 kB per cycle of RGRP SDES items and RGRS packets. Put another way, the unmodified [RFC3550] reporting interval is approximately 9 times longer than if reporting groups are in use. Lennox, et al. Expires September 3, 2016 [Page 12] Internet-Draft Grouping RTCP Reception Statistics March 2016 4.2. Compatibility of RTCP Reporting Groups The RTCP traffic generated by receivers using RTCP Reporting Groups might appear, to observers unaware of these semantics, to be generated by receivers who are experiencing a network disconnection, as the non-reporting sources appear not to be receiving a given sender at all. This could be a potentially critical problem for such a sender using RTCP for congestion control, as such a sender might think that it is sending so much traffic that it is causing complete congestion collapse. However, such an interpretation of the session statistics would require a fairly sophisticated RTCP analysis. Any receiver of RTCP statistics which is just interested in information about itself needs to be prepared that any given reception report might not contain information about a specific media source, because reception reports in large conferences can be round-robined. Thus, it is unclear to what extent such backward compatibility issues would actually cause trouble in practice. 5. Security Considerations The security considerations of [RFC3550] and [I-D.ietf-avtcore-rtp-multi-stream] apply. If the RTP/AVPF profile is in use, then the security considerations of [RFC4585] (and [RFC5104], if used) also apply. If RTCP XR is used, the security consideration of [RFC3611] and any XR report blocks used also apply. The RTCP SDES RGRP item is vulnerable to malicious modifications unless integrity protected is used. A modification of this item's length field cause the parsing of the RTCP packet in which it is contained to fail. Depending on the implementation, parsing of the full compound RTCP packet can also fail causing the whole packet to be discarded. A modification to the value of this SDES item would make the receiver of the report think that the sender of the report was a member of a different RTCP reporting group. This will potentially create an inconsistency, when the RGRS reports the source as being in the same reporting group as another source with another reporting group identifier. What impact on a receiver implementation such inconsistencies would have are difficult to fully predict. One case is when congestion control or other adaptation mechanisms are used, an inconsistent report can result in a media sender to reduce its bit-rate. However, a direct modification of the receiver report or a feedback message itself would be a more efficient attack, and equally costly to perform. Lennox, et al. Expires September 3, 2016 [Page 13] Internet-Draft Grouping RTCP Reception Statistics March 2016 The new RGRS RTCP Packet type is very simple. The common RTCP packet type header shares the security risks with previous RTCP packet types. Errors or modification of the length field can cause the full compound packet to fail header validation (see Appendix A.2 in [RFC3550]) resulting in the whole compound RTCP packet being discarded. Modification of the SC or P fields would cause inconsistency when processing the RTCP packet, likely resulting it being classified as invalid. A modification of the PT field would cause the packet being interpreted under some other packet type's rules. In such case the result might be more or less predictable but packet type specific. Modification of the SSRC of packet sender would attribute this packet to another sender. Resulting in a receiver believing the reporting group applies also for this SSRC, if it exists. If it doesn't exist, unless also corresponding modifications are done on a SR/RR packet and a SDES packet the RTCP packet SHOULD be discarded. If consistent changes are done, that could be part of a resource exhaustion attack on a receiver implementation. Modification of the "List of SSRCs for the Reporting Source(s)" would change the SSRC the receiver expect to report on behalf of this SSRC. If that SSRC exist, that could potentially change the report group used for this SSRC. A change to another reporting group belonging to another endpoint is likely detectable as there would be a mismatch between the SSRC of the packet sender's endpoint information, transport addresses, SDES CNAME etc and the corresponding information from the reporting group indicated. In general the reporting group is providing limited impacts attacks. The most significant result from an deliberate attack would be to cause the information to be discarded or be inconsistent, including discard of all RTCP packets that are modified. This causes a lack of information at any receiver entity, possibly disregarding the endpoints participation in the session. To protect against this type of attacks from external non trusted entities, integrity and source authentication SHOULD be applied. This can be done, for example, by using SRTP [RFC3711] with appropriate key-management, other options exist as discussed in RTP Security Options [RFC7201]. The Report Group Identifier has a potential privacy impacting properties. If this would be generated by an implementation in such a way that is long term stable or predictable, it could be used for tracking a particular end-point. Therefore it is RECOMMENDED that it be generated as a short-term persistent RGRP, following the rules for short-term persistent CNAMEs in [RFC7022]. The rest of the information revealed, i.e. the SSRCs, the size of reporting group and the number of reporting sources in a reporting group is of less sensitive nature, considering that the SSRCs and the communication Lennox, et al. Expires September 3, 2016 [Page 14] Internet-Draft Grouping RTCP Reception Statistics March 2016 would anyway be revealed without this extension. By encrypting the report group extensions the SSRC values would preserved confidential, but can still be revealed if SRTP [RFC3711] is used. The size of the reporting groups and number of reporting sources are likely determinable from analysis of the packet pattern and sizes. However, this information appears to have limited value. 6. IANA Considerations (Note to the RFC-Editor: in the following, please replace "TBA" with the IANA-assigned value, and "XXXX" with the number of this document, then delete this note) The IANA is requested to register one new RTCP SDES items in the "RTCP SDES Item Types" registry, as follows: Value Abbrev Name Reference TBA RGRP Reporting Group Identifier [RFCXXXX] The definition of the RTCP SDES RGRP item is given in Section 3.2.1 of this memo. The IANA is also requested to register one new RTCP packet type in the "RTCP Control Packet Types (PT)" Registry as follows: Value Abbrev Name Reference TBA RGRS Reporting Group Reporting Sources [RFCXXXX] The definition of the RTCP RGRS packet type is given in Section 3.2.2 of this memo. The IANA is also requested to register one new SDP attribute: SDP Attribute ("att-field"): Attribute name: rtcp-rgrp Long form: RTCP Reporting Groups Type of name: att-field Type of attribute: Media or session level Subject to charset: No Purpose: Negotiate or configure the use of the RTCP Reporting Group Extension. Reference: [RFCXXXX] Values: None The definition of the "a=rtcp-rgrp" SDES attribute is given in Section 3.6 of this memo. Lennox, et al. Expires September 3, 2016 [Page 15] Internet-Draft Grouping RTCP Reception Statistics March 2016 7. References 7.1. Normative References [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 (work in progress), January 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . 7.2. Informative References [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, . Lennox, et al. Expires September 3, 2016 [Page 16] Internet-Draft Grouping RTCP Reception Statistics March 2016 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . Lennox, et al. Expires September 3, 2016 [Page 17] Internet-Draft Grouping RTCP Reception Statistics March 2016 Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org Lennox, et al. Expires September 3, 2016 [Page 18] ./draft-ietf-ice-trickle-21.txt0000644000764400076440000022122613265005701015552 0ustar iustyiusty Network Working Group E. Ivov Internet-Draft Atlassian Intended status: Standards Track E. Rescorla Expires: October 17, 2018 RTFM, Inc. J. Uberti Google P. Saint-Andre Mozilla April 15, 2018 Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol draft-ietf-ice-trickle-21 Abstract This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 17, 2018. Copyright Notice Copyright (c) 2018 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 Ivov, et al. Expires October 17, 2018 [Page 1] Internet-Draft Trickle ICE April 2018 (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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Determining Support for Trickle ICE . . . . . . . . . . . . . 6 4. Generating the Initial ICE Description . . . . . . . . . . . 7 5. Handling the Initial ICE Description and Generating the Initial ICE Response . . . . . . . . . . . . . . . . . . . . 7 6. Handling the Initial ICE Response . . . . . . . . . . . . . . 8 7. Forming Check Lists . . . . . . . . . . . . . . . . . . . . . 8 8. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 9. Gathering and Conveying Newly Gathered Local Candidates . . . 9 10. Pairing Newly Gathered Local Candidates . . . . . . . . . . . 10 11. Receiving Trickled Candidates . . . . . . . . . . . . . . . . 11 12. Inserting Trickled Candidate Pairs into a Check List . . . . 12 13. Generating an End-of-Candidates Indication . . . . . . . . . 16 14. Receiving an End-of-Candidates Indication . . . . . . . . . . 17 15. Subsequent Exchanges and ICE Restarts . . . . . . . . . . . . 18 16. Half Trickle . . . . . . . . . . . . . . . . . . . . . . . . 18 17. Preserving Candidate Order while Trickling . . . . . . . . . 19 18. Requirements for Using Protocols . . . . . . . . . . . . . . 20 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 20. Security Considerations . . . . . . . . . . . . . . . . . . . 21 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 22.1. Normative References . . . . . . . . . . . . . . . . . . 22 22.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Interaction with Regular ICE . . . . . . . . . . . . 23 Appendix B. Interaction with ICE Lite . . . . . . . . . . . . . 25 Appendix C. Changes from Earlier Versions . . . . . . . . . . . 26 C.1. Changes from draft-ietf-ice-trickle-20 . . . . . . . . . 26 C.2. Changes from draft-ietf-ice-trickle-19 . . . . . . . . . 26 C.3. Changes from draft-ietf-ice-trickle-18 . . . . . . . . . 26 C.4. Changes from draft-ietf-ice-trickle-17 . . . . . . . . . 27 C.5. Changes from draft-ietf-ice-trickle-16 . . . . . . . . . 27 C.6. Changes from draft-ietf-ice-trickle-15 . . . . . . . . . 27 C.7. Changes from draft-ietf-ice-trickle-14 . . . . . . . . . 27 C.8. Changes from draft-ietf-ice-trickle-13 . . . . . . . . . 27 C.9. Changes from draft-ietf-ice-trickle-12 . . . . . . . . . 27 C.10. Changes from draft-ietf-ice-trickle-11 . . . . . . . . . 28 Ivov, et al. Expires October 17, 2018 [Page 2] Internet-Draft Trickle ICE April 2018 C.11. Changes from draft-ietf-ice-trickle-10 . . . . . . . . . 28 C.12. Changes from draft-ietf-ice-trickle-09 . . . . . . . . . 28 C.13. Changes from draft-ietf-ice-trickle-08 . . . . . . . . . 28 C.14. Changes from draft-ietf-ice-trickle-07 . . . . . . . . . 28 C.15. Changes from draft-ietf-ice-trickle-06 . . . . . . . . . 28 C.16. Changes from draft-ietf-ice-trickle-05 . . . . . . . . . 28 C.17. Changes from draft-ietf-ice-trickle-04 . . . . . . . . . 29 C.18. Changes from draft-ietf-ice-trickle-03 . . . . . . . . . 29 C.19. Changes from draft-ietf-ice-trickle-02 . . . . . . . . . 29 C.20. Changes from draft-ietf-ice-trickle-01 . . . . . . . . . 29 C.21. Changes from draft-ietf-ice-trickle-00 . . . . . . . . . 29 C.22. Changes from draft-mmusic-trickle-ice-02 . . . . . . . . 29 C.23. Changes from draft-ivov-01 and draft-mmusic-00 . . . . . 30 C.24. Changes from draft-ivov-00 . . . . . . . . . . . . . . . 30 C.25. Changes from draft-rescorla-01 . . . . . . . . . . . . . 31 C.26. Changes from draft-rescorla-00 . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction The Interactive Connectivity Establishment (ICE) protocol [rfc5245bis] describes how an ICE agent gathers candidates, exchanges candidates with a peer ICE agent, and creates candidate pairs. Once the pairs have been gathered, the ICE agent will perform connectivity checks, and eventually nominate and select pairs that will be used for sending and receiving data within a communication session. Following the procedures in [rfc5245bis] can lead to somewhat lengthy establishment times for communication sessions, because candidate gathering often involves querying STUN servers [RFC5389] and allocating relayed candidates using TURN servers [RFC5766]. Although many ICE procedures can be completed in parallel, the pacing requirements from [rfc5245bis] still need to be followed. This document defines "Trickle ICE", a supplementary mode of ICE operation in which candidates can be exchanged incrementally as soon as they become available (and simultaneously with the gathering of other candidates). Connectivity checks can also start as soon as candidate pairs have been created. Because Trickle ICE enables candidate gathering and connectivity checks to be done in parallel, the method can considerably accelerate the process of establishing a communication session. This document also defines how to discover support for Trickle ICE, how the procedures in [rfc5245bis] are modified or supplemented when using Trickle ICE, and how a Trickle ICE agent can interoperate with an ICE agent compliant to [rfc5245bis]. Ivov, et al. Expires October 17, 2018 [Page 3] Internet-Draft Trickle ICE April 2018 This document does not define any protocol-specific usage of Trickle ICE. Instead, protocol-specific details for Trickle ICE are defined in separate usage documents. Examples of such documents are [I-D.ietf-mmusic-trickle-ice-sip] (which defines usage with the Session Initiation Protocol (SIP) [RFC3261] and the Session Description Protocol [RFC3261]) and [XEP-0176] (which defines usage with XMPP [RFC6120]). However, some of the examples in the document use SDP and the offer/answer model [RFC3264] to explain the underlying concepts. The following diagram illustrates a successful Trickle ICE exchange with a using protocol that follows the offer/answer model: Alice Bob | Offer | |---------------------------------------------->| | Additional Candidates | |---------------------------------------------->| | Answer | |<----------------------------------------------| | Additional Candidates | |<----------------------------------------------| | Additional Candidates and Connectivity Checks | |<--------------------------------------------->| |<========== CONNECTION ESTABLISHED ===========>| Figure 1: Flow The main body of this document is structured to describe the behavior of Trickle ICE agents in roughly the order of operations and interactions during an ICE session: 1. Determining support for trickle ICE 2. Generating the initial ICE description 3. Handling the initial ICE description and generating the initial ICE response 4. Handling the initial ICE response 5. Forming check lists, pruning candidates, performing connectivity checks, etc. Ivov, et al. Expires October 17, 2018 [Page 4] Internet-Draft Trickle ICE April 2018 6. Gathering and conveying candidates after the initial ICE description and response 7. Handling inbound trickled candidates 8. Generating and handling the end-of-candidates indication 9. Handling ICE restarts There is quite a bit of operational experience with the technique behind Trickle ICE, going back as far as 2005 (when the XMPP Jingle extension defined a "dribble mode" as specified in [XEP-0176]); this document incorporates feedback from those who have implemented and deployed the technique over the years. 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 specification makes use of all terminology defined for Interactive Connectivity Establishment in [rfc5245bis]. In addition, it defines the following terms: Full Trickle: The typical mode of operation for Trickle ICE agents, in which the initial ICE description can include any number of candidates (even zero candidates) and does not need to include a full generation of candidates as in half trickle. Generation: All of the candidates conveyed within an ICE session. Half Trickle: A Trickle ICE mode of operation in which the initiator gathers a full generation of candidates strictly before creating and conveying the initial ICE description. Once conveyed, this candidate information can be processed by regular ICE agents, which do not require support for Trickle ICE. It also allows Trickle ICE capable responders to still gather candidates and perform connectivity checks in a non-blocking way, thus providing roughly "half" the advantages of Trickle ICE. The half trickle mechanism is mostly meant for use when the responder's support for Trickle ICE cannot be confirmed prior to conveying the initial ICE description. ICE Description: Any attributes related to the ICE session (not candidates) required to configure an ICE agent. These include but are not limited to the username fragment, password, and other attributes. Ivov, et al. Expires October 17, 2018 [Page 5] Internet-Draft Trickle ICE April 2018 Trickled Candidates: Candidates that a Trickle ICE agent conveys after conveying the initial ICE description or responding to the initial ICE description, but within the same ICE session. Trickled candidates can be conveyed in parallel with candidate gathering and connectivity checks. Trickling: The act of incrementally conveying trickled candidates. Empty Check List: A check list that initially does not contain any candidate pairs because they will be incrementally added as they are trickled. (This scenario does not arise with a regular ICE agent, because all candidate pairs are known when the agent creates the check list set). 3. Determining Support for Trickle ICE To fully support Trickle ICE, using protocols SHOULD incorporate one of the following mechanisms so that implementations can determine whether Trickle ICE is supported: 1. Provide a capabilities discovery method so that agents can verify support of Trickle ICE prior to initiating a session (XMPP's Service Discovery [XEP-0030] is one such mechanism). 2. Make support for Trickle ICE mandatory so that user agents can assume support. If a using protocol does not provide a method of determining ahead of time whether Trickle ICE is supported, agents can make use of the half trickle procedure described in Section 16. Prior to conveying the initial ICE description, agents that implement using protocols that support capabilities discovery can attempt to verify whether or not the remote party supports Trickle ICE. If an agent determines that the remote party does not support Trickle ICE, it MUST fall back to using regular ICE or abandon the entire session. Even if a using protocol does not include a capabilities discovery method, a user agent can provide an indication within the ICE description that it supports Trickle ICE by communicating an ICE option of 'trickle'. This token MUST be provided either at the session level or, if at the data stream level, for every data stream (an agent MUST NOT specify Trickle ICE support for some data streams but not others). Note: The encoding of the 'trickle' ICE option, and the message(s) used to carry it to the peer, are protocol specific; for instance, the encoding for the Session Description Protocol (SDP) [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip]. Ivov, et al. Expires October 17, 2018 [Page 6] Internet-Draft Trickle ICE April 2018 Dedicated discovery semantics and half trickle are needed only prior to initiation of an ICE session. After an ICE session is established and Trickle ICE support is confirmed for both parties, either agent can use full trickle for subsequent exchanges (see also Section 15). 4. Generating the Initial ICE Description An ICE agent can start gathering candidates as soon as it has an indication that communication is imminent (e.g., a user interface cue or an explicit request to initiate a communication session). Unlike in regular ICE, in Trickle ICE implementations do not need to gather candidates in a blocking manner. Therefore, unless half trickle is being used, the user experience is improved if the initiating agent generates and transmits its initial ICE description as early as possible (thus enabling the remote party to start gathering and trickling candidates). An initiator MAY include any mix of candidates when conveying the initial ICE description. This includes the possibility of conveying all the candidates the initiator plans to use (as in half trickle), conveying only a publicly-reachable IP address (e.g., a candidate at a data relay that is known to not be behind a firewall), or conveying no candidates at all (in which case the initiator can obtain the responder's initial candidate list sooner and the responder can begin candidate gathering more quickly). For candidates included in the initial ICE description, the methods for calculating priorities and foundations, determining redundancy of candidates, and the like work just as in regular ICE [rfc5245bis]. 5. Handling the Initial ICE Description and Generating the Initial ICE Response When a responder receives the initial ICE description, it will first check if the ICE description or initiator indicates support for Trickle ICE as explained in Section 3. If not, the responder MUST process the initial ICE description according to regular ICE procedures [rfc5245bis] (or, if no ICE support is detected at all, according to relevant processing rules for the using protocol, such as offer/answer processing rules [RFC3264]). However, if support for Trickle ICE is confirmed, a responder will automatically assume support for regular ICE as well. If the initial ICE description indicates support for Trickle ICE, the responder will determine its role and start gathering and prioritizing candidates; while doing so, it will also respond by conveying an initial ICE response, so that both the initiator and the responder can form check lists and begin connectivity checks. Ivov, et al. Expires October 17, 2018 [Page 7] Internet-Draft Trickle ICE April 2018 A responder can respond to the initial ICE description at any point while gathering candidates. The initial ICE response MAY contain any set of candidates, including all candidates or no candidates. (The benefit of including no candidates is to convey the initial ICE response as quickly as possible, so that both parties can consider the ICE session to be under active negotiation as soon as possible.) As noted in Section 3, in using protocols that use SDP the initial ICE response can indicate support for Trickle ICE by including a token of "trickle" in the ice-options attribute. 6. Handling the Initial ICE Response When processing the initial ICE response, the initiator follows regular ICE procedures to determine its role, after which it forms check lists (Section 7) and performs connectivity checks (Section 8). 7. Forming Check Lists According to regular ICE procedures [rfc5245bis], in order for candidate pairing to be possible and for redundant candidates to be pruned, the candidates would need to be provided in the initial ICE description and initial ICE response. By contrast, under Trickle ICE check lists can be empty until candidates are conveyed or received. Therefore a Trickle ICE agent handles check list formation and candidate pairing in a slightly different way than a regular ICE agent: the agent still forms the check lists, but it populates a given check list only after it actually has candidate pairs for that check list. Every check list is initially placed in the Running state, even if the check list is empty (this is consistent with Section 6.1.2.1 of [rfc5245bis]). 8. Performing Connectivity Checks As specified in [rfc5245bis], whenever timer Ta fires, only check lists in the Running state will be picked when scheduling connectivity checks for candidate pairs. Therefore, a Trickle ICE agent MUST keep each check list in the Running state as long as it expects candidate pairs to be incrementally added to the check list. After that, the check list state is set according to the procedures in [rfc5245bis]. Whenever timer Ta fires and an empty check list is picked, no action is performed for the list. Without waiting for timer Ta to expire again, the agent selects the next check list in the Running state, in accordance with Section 6.1.4.2 of [rfc5245bis]. Ivov, et al. Expires October 17, 2018 [Page 8] Internet-Draft Trickle ICE April 2018 Section 7.2.5.3.3 of [rfc5245bis] requires that agents update check lists and timer states upon completing a connectivity check transaction. During such an update, regular ICE agents would set the state of a check list to Failed if both of the following two conditions are satisfied: o all of the pairs in the check list are either in the Failed state or Succeeded state; and o there is not a pair in the valid list for each component of the data stream. With Trickle ICE, the above situation would often occur when candidate gathering and trickling are still in progress, even though it is quite possible that future checks will succeed. For this reason, Trickle ICE agents add the following conditions to the above list: o all candidate gathering has completed and the agent is not expecting to discover any new local candidates; and o the remote agent has conveyed an end-of-candidates indication for that check list as described in Section 13. 9. Gathering and Conveying Newly Gathered Local Candidates After Trickle ICE agents have conveyed initial ICE descriptions and initial ICE responses, they will most likely continue gathering new local candidates as STUN, TURN, and other non-host candidate gathering mechanisms begin to yield results. Whenever an agent discovers such a new candidate it will compute its priority, type, foundation, and component ID according to regular ICE procedures. The new candidate is then checked for redundancy against the existing list of local candidates. If its transport address and base match those of an existing candidate, it will be considered redundant and will be ignored. This would often happen for server reflexive candidates that match the host addresses they were obtained from (e.g., when the latter are public IPv4 addresses). Contrary to regular ICE, Trickle ICE agents will consider the new candidate redundant regardless of its priority. Next the agent "trickles" the newly discovered candidate(s) to the remote agent. The actual delivery of the new candidates is handled by a using protocol such as SIP or XMPP. Trickle ICE imposes no restrictions on the way this is done (e.g., some using protocols might choose not to trickle updates for server reflexive candidates and instead rely on the discovery of peer reflexive ones). Ivov, et al. Expires October 17, 2018 [Page 9] Internet-Draft Trickle ICE April 2018 When candidates are trickled, the using protocol MUST deliver each candidate (and any end-of-candidates indication as described in Section 13) to the receiving Trickle ICE implementation exactly once and in the same order it was conveyed. If the using protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. Also, candidate trickling needs to be correlated to a specific ICE session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored by the receiving party. For example, using protocols that signal candidates via SDP might include a Username Fragment value in the corresponding a=candidate line, such as: a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY Or, as another example, WebRTC implementations might include a Username Fragment in the JavaScript objects that represent candidates. Note: The using protocol needs to provide a mechanism for both parties to indicate and agree on the ICE session in force (as identified by the Username Fragment and Password combination) so that they have a consistent view of which candidates are to be paired. This is especially important in the case of ICE restarts (see Section 15). Note: A using protocol might prefer not to trickle server reflexive candidates to entities that are known to be publicly accessible and where sending a direct STUN binding request is likely to reach the destination faster than the trickle update that travels through the signaling path. 10. Pairing Newly Gathered Local Candidates As a Trickle ICE agent gathers local candidates, it needs to form candidate pairs; this works as described in the ICE specification [rfc5245bis], with the following provisos: 1. A Trickle ICE agent MUST NOT pair a local candidate until it has been trickled to the remote party. 2. Once the agent has conveyed the local candidate to the remote party, the agent checks if any remote candidates are currently known for this same stream and component. If not, the agent Ivov, et al. Expires October 17, 2018 [Page 10] Internet-Draft Trickle ICE April 2018 merely adds the new candidate to the list of local candidates (without pairing it). 3. Otherwise, if the agent has already learned of one or more remote candidates for this stream and component, it attempts to pair the new local candidate as described in the ICE specification [rfc5245bis]. 4. If a newly formed pair has a local candidate whose type is server reflexive, the agent MUST replace the local candidate with its base before completing the relevant redundancy tests. 5. The agent prunes redundant pairs by following the rules in Section 6.1.2.4 of [rfc5245bis], but checks existing pairs only if they have a state of Waiting or Frozen; this avoids removal of pairs for which connectivity checks are in flight (a state of In- Progress) or for which connectivity checks have already yielded a definitive result (a state of Succeeded or Failed). 6. If after the relevant redundancy tests the check list where the pair is to be added already contains the maximum number of candidate pairs (100 by default as per [rfc5245bis]), the agent SHOULD discard any pairs in the Failed state to make room for the new pair. If there are no such pairs, the agent SHOULD discard a pair with a lower priority than the new pair in order to make room for the new pair, until the number of pairs is equal to the maximum number of pairs. This processing is consistent with Section 6.1.2.5 of [rfc5245bis]. 11. Receiving Trickled Candidates At any time during an ICE session, a Trickle ICE agent might receive new candidates from the remote agent, from which it will attempt to form a candidate pair; this works as described in the ICE specification [rfc5245bis], with the following provisos: 1. The agent checks if any local candidates are currently known for this same stream and component. If not, the agent merely adds the new candidate to the list of remote candidates (without pairing it). 2. Otherwise, if the agent has already gathered one or more local candidates for this stream and component, it attempts to pair the new remote candidate as described in the ICE specification [rfc5245bis]. Ivov, et al. Expires October 17, 2018 [Page 11] Internet-Draft Trickle ICE April 2018 3. If a newly formed pair has a local candidate whose type is server reflexive, the agent MUST replace the local candidate with its base before completing the redundancy check in the next step. 4. The agent prunes redundant pairs as described below, but checks existing pairs only if they have a state of Waiting or Frozen; this avoids removal of pairs for which connectivity checks are in flight (a state of In-Progress) or for which connectivity checks have already yielded a definitive result (a state of Succeeded or Failed). A. If the agent finds a redundancy between two pairs and one of those pairs contains a newly received remote candidate whose type is peer reflexive, the agent SHOULD discard the pair containing that candidate, set the priority of the existing pair to the priority of the discarded pair, and re-sort the check list. (This policy helps to eliminate problems with remote peer reflexive candidates for which a STUN binding request is received before signaling of the candidate is trickled to the receiving agent, such as a different view of pair priorities between the local agent and the remote agent, since the same candidate could be perceived as peer reflexive by one agent and as server reflexive by the other agent.) B. The agent then applies the rules defined in Section 6.1.2.4 of [rfc5245bis]. 5. If after the relevant redundancy tests the check list where the pair is to be added already contains the maximum number of candidate pairs (100 by default as per [rfc5245bis]), the agent SHOULD discard any pairs in the Failed state to make room for the new pair. If there are no such pairs, the agent SHOULD discard a pair with a lower priority than the new pair in order to make room for the new pair, until the number of pairs is equal to the maximum number of pairs. This processing is consistent with Section 6.1.2.5 of [rfc5245bis]. 12. Inserting Trickled Candidate Pairs into a Check List After a local agent has trickled a candidate and formed a candidate pair from that local candidate (Section 9), or after a remote agent has received a trickled candidate and formed a candidate pair from that remote candidate (Section 11), a Trickle ICE agent adds the new candidate pair to a check list as defined in this section. As an aid to understanding the procedures defined in this section, consider the following tabular representation of all check lists in Ivov, et al. Expires October 17, 2018 [Page 12] Internet-Draft Trickle ICE April 2018 an agent (note that initially for one of the foundations, i.e., f5, there are no candidate pairs): +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | F | F | F | | | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | F | F | F | F | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | F | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | F | | | | | +-----------------+------+------+------+------+------+ Figure 2: Example of Check List State Each row in the table represents a component for a given data stream (e.g., s1 and s2 might be the RTP and RTCP components for audio) and thus a single check list in the check list set. Each column represents one foundation. Each cell represents one candidate pair. In the tables shown in this section, "F" stands for "frozen", "W" stands for "waiting", and "S" stands for "succeeded"; in addition, "^^" is used to notate newly-added candidate pairs. When an agent commences ICE processing, in accordance with Section 6.1.2.6 of [rfc5245bis], for each foundation it will unfreeze the pair with the lowest component ID and, if the component IDs are equal, with the highest priority (this is the topmost candidate pair in every column). This initial state is shown in the following table. Ivov, et al. Expires October 17, 2018 [Page 13] Internet-Draft Trickle ICE April 2018 +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | W | W | W | | | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | F | F | F | W | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | F | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | F | | | | | +-----------------+------+------+------+------+------+ Figure 3: Initial Check List State Then, as the checks proceed (see Section 7.2.5.4 of [rfc5245bis]), for each pair that enters the Succeeded state (denoted here by "S"), the agent will unfreeze all pairs for all data streams with the same foundation (e.g., if the pair in column 1, row 1 succeeds then the agent will unfreeze the pair in column 1, rows 2, 3, and 4). +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 4: Check List State with Succeeded Candidate Pair Trickle ICE preserves all of these rules as they apply to "static" check list sets. This implies that if a Trickle ICE agent were to begin connectivity checks with all of its pairs already present, the way that pair states change is indistinguishable from that of a regular ICE agent. Of course, the major difference with Trickle ICE is that check list sets can be dynamically updated because candidates can arrive after connectivity checks have started. When this happens, an agent sets the state of the newly formed pair as described below. Ivov, et al. Expires October 17, 2018 [Page 14] Internet-Draft Trickle ICE April 2018 Rule 1: If the newly formed pair has the lowest component ID and, if the component IDs are equal, the highest priority of any candidate pair for this foundation (i.e., if it is the topmost pair in the column), set the state to Waiting. For example, this would be the case if the newly formed pair were placed in column 5, row 1. This rule is consistent with Section 6.1.2.6 of [rfc5245bis]. +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | ^W^ | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 5: Check List State with Newly Formed Pair, Rule 1 Rule 2: If there is at least one pair in the Succeeded state for this foundation, set the state to Waiting. For example, this would be the case if the pair in column 5, row 1 succeeded and the newly formed pair were placed in column 5, row 2. This rule is consistent with Section 7.2.5.3.3 of [rfc5245bis]. +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | S | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | ^W^ | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 6: Check List State with Newly Formed Pair, Rule 2 Rule 3: In all other cases, set the state to Frozen. For example, this would be the case if the newly formed pair were placed in column 3, row 3. Ivov, et al. Expires October 17, 2018 [Page 15] Internet-Draft Trickle ICE April 2018 +-----------------+------+------+------+------+------+ | | f1 | f2 | f3 | f4 | f5 | +-----------------+------+------+------+------+------+ | s1 (Audio.RTP) | S | W | W | | S | +-----------------+------+------+------+------+------+ | s2 (Audio.RTCP) | W | F | F | W | W | +-----------------+------+------+------+------+------+ | s3 (Video.RTP) | W | | ^F^ | | | +-----------------+------+------+------+------+------+ | s4 (Video.RTCP) | W | | | | | +-----------------+------+------+------+------+------+ Figure 7: Check List State with Newly Formed Pair, Rule 3 13. Generating an End-of-Candidates Indication Once all candidate gathering is completed or expires for an ICE session associated with a specific data stream, the agent will generate an "end-of-candidates" indication for that session and convey it to the remote agent via the signaling channel. Although the exact form of the indication depends on the using protocol, the indication MUST specify the generation (Username Fragment and Password combination) so that an agent can correlate the end-of- candidates indication with a particular ICE session. The indication can be conveyed in the following ways: o As part of an initiation request (which would typically be the case with the initial ICE description for half trickle) o Along with the last candidate an agent can send for a stream o As a standalone notification (e.g., after STUN Binding requests or TURN Allocate requests to a server time out and the agent is no longer actively gathering candidates) Conveying an end-of-candidates indication in a timely manner is important in order to avoid ambiguities and speed up the conclusion of ICE processing. In particular: o A controlled Trickle ICE agent SHOULD convey an end-of-candidates indication after it has completed gathering for a data stream, unless ICE processing terminates before the agent has had a chance to complete gathering. o A controlling agent MAY conclude ICE processing prior to conveying end-of-candidates indications for all streams. However, it is RECOMMENDED for a controlling agent to convey end-of-candidates Ivov, et al. Expires October 17, 2018 [Page 16] Internet-Draft Trickle ICE April 2018 indications whenever possible for the sake of consistency and to keep middleboxes and controlled agents up-to-date on the state of ICE processing. When conveying an end-of-candidates indication during trickling (rather than as a part of the initial ICE description or a response thereto), it is the responsibility of the using protocol to define methods for associating the indication with one or more specific data streams. An agent MAY also choose to generate an end-of-candidates indication before candidate gathering has actually completed, if the agent determines that gathering has continued for more than an acceptable period of time. However, an agent MUST NOT convey any more candidates after it has conveyed an end-of-candidates indication. When performing half trickle, an agent SHOULD convey an end-of- candidates indication together with its initial ICE description unless it is planning to potentially trickle additional candidates (e.g., in case the remote party turns out to support Trickle ICE). After an agent conveys the end-of-candidates indication, it will update the state of the corresponding check list as explained in Section 8. Past that point, an agent MUST NOT trickle any new candidates within this ICE session. Therefore, adding new candidates to the negotiation is possible only through an ICE restart (see Section 15). This specification does not override regular ICE semantics for concluding ICE processing. Therefore, even if end-of-candidates indications are conveyed, an agent will still need to go through pair nomination. Also, if pairs have been nominated for components and data streams, ICE processing MAY still conclude even if end-of- candidates indications have not been received for all streams. In all cases, an agent MUST NOT trickle any new candidates within an ICE session after nomination of a candidate pair as described in Section 8.1.1 of [rfc5245bis]. 14. Receiving an End-of-Candidates Indication Receiving an end-of-candidates indication enables an agent to update check list states and, in case valid pairs do not exist for every component in every data stream, determine that ICE processing has failed. It also enables an agent to speed up the conclusion of ICE processing when a candidate pair has been validated but it involves the use of lower-preference transports such as TURN. In such situations, an implementation MAY choose to wait and see if higher- priority candidates are received; in this case the end-of-candidates Ivov, et al. Expires October 17, 2018 [Page 17] Internet-Draft Trickle ICE April 2018 indication provides a notification that such candidates are not forthcoming. When an agent receives an end-of-candidates indication for a specific data stream, it will update the state of the relevant check list as per Section 8 (which might lead to some check lists being marked as Failed). If the check list is still in the Running state after the update, the agent will persist the fact that an end-of-candidates indication has been received and take it into account in future updates to the check list. After an agent has received an end-of-candidates indication, it MUST ignore any newly received candidates for that data stream or data session. 15. Subsequent Exchanges and ICE Restarts Before conveying an end-of-candidates indication, either agent MAY convey subsequent candidate information at any time allowed by the using protocol. When this happens, agents will use [rfc5245bis] semantics (e.g., checking of the Username Fragment and Password combination) to determine whether or not the new candidate information requires an ICE restart. If an ICE restart occurs, the agents can assume that Trickle ICE is still supported if support was determined previously, and thus can engage in Trickle ICE behavior as they would in an initial exchange of ICE descriptions where support was determined through a capabilities discovery method. 16. Half Trickle In half trickle, the initiator conveys the initial ICE description with a usable but not necessarily full generation of candidates. This ensures that the ICE description can be processed by a regular ICE responder and is mostly meant for use in cases where support for Trickle ICE cannot be confirmed prior to conveying the initial ICE description. The initial ICE description indicates support for Trickle ICE, so that the responder can respond with something less than a full generation of candidates and then trickle the rest. The initial ICE description for half trickle can contain an end-of- candidates indication, although this is not mandatory because if trickle support is confirmed then the initiator can choose to trickle additional candidates before it conveys an end-of-candidates indication. The half trickle mechanism can be used in cases where there is no way for an agent to verify in advance whether a remote party supports Ivov, et al. Expires October 17, 2018 [Page 18] Internet-Draft Trickle ICE April 2018 Trickle ICE. Because the initial ICE description contain a full generation of candidates, it can thus be handled by a regular ICE agent, while still allowing a Trickle ICE agent to use the optimization defined in this specification. This prevents negotiation from failing in the former case while still giving roughly half the Trickle ICE benefits in the latter. Use of half trickle is only necessary during an initial exchange of ICE descriptions. After both parties have received an ICE description from their peer, they can each reliably determine Trickle ICE support and use it for all subsequent exchanges (see Section 15). In some instances, using half trickle might bring more than just half the improvement in terms of user experience. This can happen when an agent starts gathering candidates upon user interface cues that the user will soon be initiating an interaction, such as activity on a keypad or the phone going off hook. This would mean that some or all of the candidate gathering could be completed before the agent actually needs to convey the candidate information. Because the responder will be able to trickle candidates, both agents will be able to start connectivity checks and complete ICE processing earlier than with regular ICE and potentially even as early as with full trickle. However, such anticipation is not always possible. For example, a multipurpose user agent or a WebRTC web page where communication is a non-central feature (e.g., calling a support line in case of a problem with the main features) would not necessarily have a way of distinguishing between call intentions and other user activity. In such cases, using full trickle is most likely to result in an ideal user experience. Even so, using half trickle would be an improvement over regular ICE because it would result in a better experience for responders. 17. Preserving Candidate Order while Trickling One important aspect of regular ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by both agents, so that any firewalls or NATs fronting the agents would whitelist both endpoints and allow all except for the first ("suicide") packets to go through. This is also important to unfreezing candidates at the right time. While not crucial, preserving this behavior in Trickle ICE is likely to improve ICE performance. To achieve this, when trickling candidates, agents SHOULD respect the order of components as reflected by their component IDs; that is, candidates for a given component SHOULD NOT be conveyed prior to Ivov, et al. Expires October 17, 2018 [Page 19] Internet-Draft Trickle ICE April 2018 candidates for a component with a lower ID number within the same foundation. In addition, candidates SHOULD be paired, following the procedures in Section 12, in the same order they are conveyed. For example, the following SDP description contains two components (RTP and RTCP) and two foundations (host and server reflexive): v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 10.0.1.1 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 5000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx raddr 10.0.1.1 rport 8998 a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx raddr 10.0.1.1 rport 8998 For this candidate information the RTCP host candidate would not be conveyed prior to the RTP host candidate. Similarly the RTP server reflexive candidate would be conveyed together with or prior to the RTCP server reflexive candidate. 18. Requirements for Using Protocols In order to fully enable the use of Trickle ICE, this specification defines the following requirements for using protocols. o A using protocol SHOULD provide a way for parties to advertise and discover support for Trickle ICE before an ICE session begins (see Section 3). o A using protocol MUST provide methods for incrementally conveying (i.e., "trickling") additional candidates after conveying the initial ICE description (see Section 9). o A using protocol MUST deliver each trickled candidate or end-of- candidates indication exactly once and in the same order it was conveyed (see Section 9). Ivov, et al. Expires October 17, 2018 [Page 20] Internet-Draft Trickle ICE April 2018 o A using protocol MUST provide a mechanism for both parties to indicate and agree on the ICE session in force (see Section 9). o A using protocol MUST provide a way for parties to communicate the end-of-candidates indication, which MUST specify the particular ICE session to which the indication applies (see Section 13). 19. IANA Considerations IANA is requested to register the following ICE option in the "ICE Options" sub-registry of the "Interactive Connectivity Establishment (ICE) registry", following the procedures defined in [RFC6336]. ICE Option: trickle Contact: IESG, iesg@ietf.org Change control: IESG Description: An ICE option of "trickle" indicates support for incremental communication of ICE candidates. Reference: RFC XXXX 20. Security Considerations This specification inherits most of its semantics from [rfc5245bis] and as a result all security considerations described there apply to Trickle ICE. If the privacy implications of revealing host addresses on an endpoint device are a concern (see for example the discussion in [I-D.ietf-rtcweb-ip-handling] and in Section 19 of [rfc5245bis]), agents can generate ICE descriptions that contain no candidates and then only trickle candidates that do not reveal host addresses (e.g., relayed candidates). 21. Acknowledgements The authors would like to thank Bernard Aboba, Flemming Andreasen, Rajmohan Banavi, Taylor Brandstetter, Philipp Hancke, Christer Holmberg, Ari Keranen, Paul Kyzivat, Jonathan Lennox, Enrico Marocco, Pal Martinsen, Nils Ohlmeier, Thomas Stach, Peter Thatcher, Martin Thomson, Brandon Williams, and Dale Worley for their reviews and suggestions on improving this document. Sarah Banks, Roni Even, and David Mandelberg completed opsdir, genart, and security reviews, respectively. Thanks also to Ari Keranen and Peter Thatcher in their Ivov, et al. Expires October 17, 2018 [Page 21] Internet-Draft Trickle ICE April 2018 role as chairs, and Ben Campbell in his role as responsible Area Director. 22. References 22.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, . [rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-20 (work in progress), March 2018. 22.2. Informative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), February 2018. [I-D.ietf-rtcweb-ip-handling] Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-06 (work in progress), March 2018. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . Ivov, et al. Expires October 17, 2018 [Page 22] Internet-Draft Trickle ICE April 2018 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, DOI 10.17487/RFC6336, July 2011, . [XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- Andre, "XEP-0030: Service Discovery", XEP XEP-0030, June 2008. [XEP-0176] Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J., Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP Transport Method", XEP XEP-0176, June 2009. Appendix A. Interaction with Regular ICE The ICE protocol was designed to be flexible enough to work in and adapt to as many network environments as possible. Despite that flexibility, ICE as specified in [rfc5245bis] does not by itself support trickle ICE. This section describes how trickling of candidates interacts with ICE. Ivov, et al. Expires October 17, 2018 [Page 23] Internet-Draft Trickle ICE April 2018 [rfc5245bis] describes the conditions required to update check lists and timer states while an ICE agent is in the Running state. These conditions are verified upon transaction completion and one of them stipulates that: If there is not a pair in the valid list for each component of the data stream, the state of the check list is set to Failed. This could be a problem and cause ICE processing to fail prematurely in a number of scenarios. Consider the following case: 1. Alice and Bob are both located in different networks with Network Address Translation (NAT). Alice and Bob themselves have different address but both networks use the same private internet block (e.g., the "20-bit block" 172.16/12 specified in [RFC1918]). 2. Alice conveys to Bob the candidate 172.16.0.1 which also happens to correspond to an existing host on Bob's network. 3. Bob creates a check list consisting solely of 172.16.0.1 and starts checks. 4. These checks reach the host at 172.16.0.1 in Bob's network, which responds with an ICMP "port unreachable" error; per [rfc5245bis] Bob marks the transaction as Failed. At this point the check list only contains Failed candidates and the valid list is empty. This causes the data stream and potentially all ICE processing to fail, even though if Trickle ICE agents could subsequently convey candidates that would cause previously empty check lists to become non-empty. A similar race condition would occur if the initial ICE description from Alice contain only candidates that can be determined as unreachable from any of the candidates that Bob has gathered (e.g., this would be the case if Bob's candidates only contain IPv4 addresses and the first candidate that he receives from Alice is an IPv6 one). Another potential problem could arise when a non-trickle ICE implementation initiates an interaction with a Trickle ICE implementation. Consider the following case: 1. Alice's client has a non-Trickle ICE implementation. 2. Bob's client has support for Trickle ICE. Ivov, et al. Expires October 17, 2018 [Page 24] Internet-Draft Trickle ICE April 2018 3. Alice and Bob are behind NATs with address-dependent filtering [RFC4787]. 4. Bob has two STUN servers but one of them is currently unreachable. After Bob's agent receives Alice's initial ICE description it would immediately start connectivity checks. It would also start gathering candidates, which would take a long time because of the unreachable STUN server. By the time Bob's answer is ready and conveyed to Alice, Bob's connectivity checks might have failed: until Alice gets Bob's answer, she won't be able to start connectivity checks and punch holes in her NAT. The NAT would hence be filtering Bob's checks as originating from an unknown endpoint. Appendix B. Interaction with ICE Lite The behavior of ICE lite agents that are capable of Trickle ICE does not require any particular rules other than those already defined in this specification and [rfc5245bis]. This section is hence provided only for informational purposes. An ICE lite agent would generate candidate information as per [rfc5245bis] and would indicate support for Trickle ICE. Given that the candidate information will contain a full generation of candidates, it would also be accompanied by an end-of-candidates indication. When performing full trickle, a full ICE implementation could convey the initial ICE description or response thereto with no candidates. After receiving a response that identifies the remote agent as an ICE lite implementation, the initiator can choose to not trickle any additional candidates. The same is also true in the case when the ICE lite agent initiates the interaction and the full ICE agent is the responder. In these cases the connectivity checks would be enough for the ICE lite implementation to discover all potentially useful candidates as peer reflexive. The following example illustrates one such ICE session using SDP syntax: Ivov, et al. Expires October 17, 2018 [Page 25] Internet-Draft Trickle ICE April 2018 ICE Lite Bob Agent | Offer (a=ice-lite a=ice-options:trickle) | |---------------------------------------------->| | |no cand | Answer (a=ice-options:trickle) |trickling |<----------------------------------------------| | Connectivity Checks | |<--------------------------------------------->| peer rflx| | cand disco| | |<========== CONNECTION ESTABLISHED ===========>| Figure 8: Example In addition to reducing signaling traffic this approach also removes the need to discover STUN bindings or make TURN allocations, which can considerably lighten ICE processing. Appendix C. Changes from Earlier Versions Note to the RFC Editor: please remove this section prior to publication as an RFC. C.1. Changes from draft-ietf-ice-trickle-20 o Slight corrections to hanlding of peer reflexive candidates. o Wordsmithing in a few sections. C.2. Changes from draft-ietf-ice-trickle-19 o Further clarified handling of remote peer reflexive candidates. o To improve readibility, renamed and restructured some sections and subsections, and modified some wording. C.3. Changes from draft-ietf-ice-trickle-18 o Cleaned up pairing and redundancy checking rules for newly discovered candidates per IESG feedback and WG discussion. o Improved wording in half trickle section. o Changed "not more than once" to "exactly once". Ivov, et al. Expires October 17, 2018 [Page 26] Internet-Draft Trickle ICE April 2018 o Changed NAT examples back to IPv4. C.4. Changes from draft-ietf-ice-trickle-17 o Simplified the rules for inserting a new pair in a check list. o Clarified it is not allowed to nominate a candidate pair after a pair has already been nominated (a.k.a. renomination or continuous nomination). o Removed some text that referenced older versions of rfc5245bis. o Removed some text that duplicated concepts and procedures specified in rfc5245bis. o Removed the ill-defined concept of stream order. o Shortened the introduction. C.5. Changes from draft-ietf-ice-trickle-16 o Made "ufrag" terminology consistent with 5245bis. o Applied in-order delivery rule to end-of-candidates indication. C.6. Changes from draft-ietf-ice-trickle-15 o Adjustments to address AD review feedback. C.7. Changes from draft-ietf-ice-trickle-14 o Minor modifications to track changes to ICE core. C.8. Changes from draft-ietf-ice-trickle-13 o Removed independent monitoring of check list "states" of frozen or active, since this is handled by placing a check list in the Running state defined in ICE core. C.9. Changes from draft-ietf-ice-trickle-12 o Specified that the end-of-candidates indication must include the generation (ufrag/pwd) to enable association with a particular ICE session. o Further editorial fixes to address WGLC feedback. Ivov, et al. Expires October 17, 2018 [Page 27] Internet-Draft Trickle ICE April 2018 C.10. Changes from draft-ietf-ice-trickle-11 o Editorial and terminological fixes to address WGLC feedback. C.11. Changes from draft-ietf-ice-trickle-10 o Minor editorial fixes. C.12. Changes from draft-ietf-ice-trickle-09 o Removed immediate unfreeze upon Fail. o Specified MUST NOT regarding ice-options. o Changed terminology regarding initial ICE parameters to avoid implementer confusion. C.13. Changes from draft-ietf-ice-trickle-08 o Reinstated text about in-order processing of messages as a requirement for signaling protocols. o Added IANA registration template for ICE option. o Corrected Case 3 rule in Section 8.1.1 to ensure consistency with regular ICE rules. o Added tabular representations to Section 8.1.1 in order to illustrate the new pair rules. C.14. Changes from draft-ietf-ice-trickle-07 o Changed "ICE description" to "candidate information" for consistency with 5245bis. C.15. Changes from draft-ietf-ice-trickle-06 o Addressed editorial feedback from chairs' review. o Clarified terminology regarding generations. C.16. Changes from draft-ietf-ice-trickle-05 o Rewrote the text on inserting a new pair into a check list. Ivov, et al. Expires October 17, 2018 [Page 28] Internet-Draft Trickle ICE April 2018 C.17. Changes from draft-ietf-ice-trickle-04 o Removed dependency on SDP and offer/answer model. o Removed mentions of aggressive nomination, since it is deprecated in 5245bis. o Added section on requirements for signaling protocols. o Clarified terminology. o Addressed various WG feedback. C.18. Changes from draft-ietf-ice-trickle-03 o Provided more detailed description of unfreezing behavior, specifically how to replace pre-existing peer-reflexive candidates with higher-priority ones received via trickling. C.19. Changes from draft-ietf-ice-trickle-02 o Adjusted unfreezing behavior when there are disparate foundations. C.20. Changes from draft-ietf-ice-trickle-01 o Changed examples to use IPv6. C.21. Changes from draft-ietf-ice-trickle-00 o Removed dependency on SDP (which is to be provided in a separate specification). o Clarified text about the fact that a check list can be empty if no candidates have been sent or received yet. o Clarified wording about check list states so as not to define new states for "Active" and "Frozen" because those states are not defined for check lists (only for candidate pairs) in ICE core. o Removed open issues list because it was out of date. o Completed a thorough copy edit. C.22. Changes from draft-mmusic-trickle-ice-02 o Addressed feedback from Rajmohan Banavi and Brandon Williams. Ivov, et al. Expires October 17, 2018 [Page 29] Internet-Draft Trickle ICE April 2018 o Clarified text about determining support and about how to proceed if it can be determined that the answering agent does not support Trickle ICE. o Clarified text about check list and timer updates. o Clarified when it is appropriate to use half trickle or to send no candidates in an offer or answer. o Updated the list of open issues. C.23. Changes from draft-ivov-01 and draft-mmusic-00 o Added a requirement to trickle candidates by order of components to avoid deadlocks in the unfreezing algorithm. o Added an informative note on peer-reflexive candidates explaining that nothing changes for them semantically but they do become a more likely occurrence for Trickle ICE. o Limit the number of pairs to 100 to comply with 5245. o Added clarifications on the non-importance of how newly discovered candidates are trickled/sent to the remote party or if this is done at all. o Added transport expectations for trickled candidates as per Dale Worley's recommendation. C.24. Changes from draft-ivov-00 o Specified that end-of-candidates is a media level attribute which can of course appear as session level, which is equivalent to having it appear in all m-lines. Also made end-of-candidates optional for cases such as aggressive nomination for controlled agents. o Added an example for ICE lite and Trickle ICE to illustrate how, when talking to an ICE lite agent doesn't need to send or even discover any candidates. o Added an example for ICE lite and Trickle ICE to illustrate how, when talking to an ICE lite agent doesn't need to send or even discover any candidates. o Added wording that explicitly states ICE lite agents have to be prepared to receive no candidates over signaling and that they Ivov, et al. Expires October 17, 2018 [Page 30] Internet-Draft Trickle ICE April 2018 should not freak out if this happens. (Closed the corresponding open issue). o It is now mandatory to use MID when trickling candidates and using m-line indexes is no longer allowed. o Replaced use of 0.0.0.0 to IP6 :: in order to avoid potential issues with RFC2543 SDP libraries that interpret 0.0.0.0 as an on- hold operation. Also changed the port number here from 1 to 9 since it already has a more appropriate meaning. (Port change suggested by Jonathan Lennox). o Closed the Open Issue about use about what to do with cands received after end-of-cands. Solution: ignore, do an ICE restart if you want to add something. o Added more terminology, including trickling, trickled candidates, half trickle, full trickle, o Added a reference to the SIP usage for Trickle ICE as requested at the Boston interim. C.25. Changes from draft-rescorla-01 o Brought back explicit use of Offer/Answer. There are no more attempts to try to do this in an O/A independent way. Also removed the use of ICE Descriptions. o Added SDP specification for trickled candidates, the trickle option and 0.0.0.0 addresses in m-lines, and end-of-candidates. o Support and Discovery. Changed that section to be less abstract. As discussed in IETF85, the draft now says implementations and usages need to either determine support in advance and directly use trickle, or do half trickle. Removed suggestion about use of discovery in SIP or about letting implementing protocols do what they want. o Defined Half Trickle. Added a section that says how it works. Mentioned that it only needs to happen in the first o/a (not necessary in updates), and added Jonathan's comment about how it could, in some cases, offer more than half the improvement if you can pre-gather part or all of your candidates before the user actually presses the call button. o Added a short section about subsequent offer/answer exchanges. Ivov, et al. Expires October 17, 2018 [Page 31] Internet-Draft Trickle ICE April 2018 o Added a short section about interactions with ICE Lite implementations. o Added two new entries to the open issues section. C.26. Changes from draft-rescorla-00 o Relaxed requirements about verifying support following a discussion on MMUSIC. o Introduced ICE descriptions in order to remove ambiguous use of 3264 language and inappropriate references to offers and answers. o Removed inappropriate assumption of adoption by RTCWEB pointed out by Martin Thomson. Authors' Addresses Emil Ivov Atlassian 303 Colorado Street, #1600 Austin, TX 78701 USA Phone: +1-512-640-3000 Email: eivov@atlassian.com Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 Email: ekr@rtfm.com Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Phone: +1 857 288 8888 Email: justin@uberti.name Ivov, et al. Expires October 17, 2018 [Page 32] Internet-Draft Trickle ICE April 2018 Peter Saint-Andre Mozilla P.O. Box 787 Parker, CO 80134 USA Phone: +1 720 256 6756 Email: stpeter@mozilla.com URI: https://www.mozilla.com/ Ivov, et al. Expires October 17, 2018 [Page 33] ./draft-ietf-avtext-lrr-07.txt0000644000764400076440000007633613126302536015507 0ustar iustyiusty Payload Working Group J. Lennox Internet-Draft D. Hong Intended status: Standards Track Vidyo Expires: December 31, 2017 J. Uberti S. Holmer M. Flodman Google June 29, 2017 The Layer Refresh Request (LRR) RTCP Feedback Message draft-ietf-avtext-lrr-07 Abstract This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 31, 2017. Copyright Notice Copyright (c) 2017 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 Lennox, et al. Expires December 31, 2017 [Page 1] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 2 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Layer Refresh Request . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Usage with specific codecs . . . . . . . . . . . . . . . . . 8 4.1. H264 SVC . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. VP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. H265 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Usage with different scalability transmission mechanisms . . 11 6. SDP Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This memo describes an RTCP [RFC3550] Payload-Specific Feedback Message [RFC4585] "Layer Refresh Request" (LRR). It is designed to allow a receiver of a layered media stream to request that one or more of its substreams be refreshed, such that it can then be decoded by an endpoint which previously was not receiving those layers, without requiring that the entire stream be refreshed (as it would be if the receiver sent a Full Intra Request (FIR); [RFC5104] see also [RFC8082]). The feedback message is applicable both to temporally and spatially scaled streams, and to both single-stream and multi-stream scalability modes. 2. Conventions, Definitions and Acronyms 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]. Lennox, et al. Expires December 31, 2017 [Page 2] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 2.1. Terminology A "Layer Refresh Point" is a point in a scalable stream after which a decoder, which previously had been able to decode only some (possibly none) of the available layers of stream, is able to decode a greater number of the layers. For spatial (or quality) layers, in normal encoding, a subpicture can depend both on earlier pictures of that spatial layer and also on lower-layer pictures of the current picture. A layer refresh, however, typically requires that a spatial layer picture be encoded in a way that references only the lower-layer subpictures of the current picture, not any earlier pictures of that spatial layer. Additionally, the encoder must promise that no earlier pictures of that spatial layer will be used as reference in the future. However, even in a layer refresh, layers other than the ones being refreshed may still maintain dependency on earlier content of the stream. This is the difference between a layer refresh and a Full Intra Request [RFC5104]. This minimizes the coding overhead of refresh to only those parts of the stream that actually need to be refreshed at any given time. An illustration of spatial layer refresh of an enhancement layer is shown below. <-- indicates a coding dependency. ... <-- S1 <-- S1 S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... 1 2 3 4 Figure 1 In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a decoder which had previously only been decoding spatial layer S0 would be able to decode layer S1 starting at frame 3. Lennox, et al. Expires December 31, 2017 [Page 3] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 An illustration of spatial layer refresh of a base layer is shown below. <-- indicates a coding dependency. ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 S0 <-- S0 <-- ... 1 2 3 4 Figure 2 In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a decoder which had previously not been decoding the stream at all could decode layer S0 starting at frame 3. For temporal layers, while normal encoding allows frames to depend on earlier frames of the same temporal layer, layer refresh requires that the layer be "temporally nested", i.e. use as reference only earlier frames of a lower temporal layer, not any earlier frames of this temporal layer, and also promise that no future frames of this temporal layer will reference frames of this temporal layer before the refresh point. In many cases, the temporal structure of the stream will mean that all frames are temporally nested, in which case decoders will have no need to send LRR messages for the stream. An illustration of temporal layer refresh is shown below. <-- indicates a coding dependency. ... <----- T1 <------ T1 T1 <------ ... / / / |_ |_ |_ ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 1 2 3 4 5 6 7 Figure 3 In Figure 3, frame 6 is a layer refresh point for temporal layer T1; a decoder which had previously only been decoding temporal layer T0 would be able to decode layer T1 starting at frame 6. Lennox, et al. Expires December 31, 2017 [Page 4] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 An illustration of an inherently temporally nested stream is shown below. <-- indicates a coding dependency. T1 T1 T1 / / / |_ |_ |_ ... <-- T0 <------ T0 <------ T0 <------ T0 <--- ... 1 2 3 4 5 6 7 Figure 4 In Figure 4, the stream is temporally nested in its ordinary structure; a decoder receiving layer T0 can begin decoding layer T1 at any point. A "Layer Index" is a numeric label for a specific spatial and temporal layer of a scalable stream. It consists of the pair of a "temporal ID" identifying the temporal layer, and a "layer ID" identifying the spatial or quality layer. The details of how layers of a scalable stream are labeled are codec-specific. Details for several codecs are defined in Section 4. 3. Layer Refresh Request A layer refresh frame can be requested by sending a Layer Refresh Request (LRR), which is an RTP Control Protocol (RTCP) [RFC3550] payload-specific feedback message [RFC4585] asking the encoder to encode a frame which makes it possible to upgrade to a higher layer. The LRR contains one or two tuples, indicating the temporal and spatial layer the decoder wants to upgrade to, and (optionally) the currently highest temporal and spatial layer the decoder can decode. The specific format of the tuples, and the mechanism by which a receiver recognizes a refresh frame, is codec-dependent. Usage for several codecs is discussed in Section 4. LRR follows the model of the Full Intra Request (FIR) [RFC5104] (Section 3.5.1) for its retransmission, reliability, and use in multipoint conferences. The LRR message is identified by RTCP packet type value PT=PSFB and FMT=TBD. The FCI field MUST contain one or more LRR entries. Each entry applies to a different media sender, identified by its SSRC. [NOTE TO RFC Editor: Please replace "TBD" with the IANA-assigned payload-specific feedback number.] Lennox, et al. Expires December 31, 2017 [Page 5] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 3.1. Message Format The Feedback Control Information (FCI) for the Layer Refresh Request consists of one or more FCI entries, the content of which is depicted in Figure 5. The length of the LRR feedback message MUST be set to 2+3*N 32-bit words, where N is the number of FCI entries. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq nr. |C| Payload Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TTID| TLID | RES | CTID| CLID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 SSRC (32 bits) The SSRC value of the media sender that is requested to send a layer refresh point. Seq nr. (8 bits) Command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 for each new command (modulo 256, so the value after 255 is 0). A repetition SHALL NOT increase the sequence number. The initial value is arbitrary. C (1 bit) A flag bit indicating whether the "Current Temporal Layer ID (CTID)" and "Current Layer ID (CLID)" fields are present in the FCI. If this bit is 0, the sender of the LRR message is requesting refresh of all layers up to and including the target layer. Payload Type (7 bits) The RTP payload type for which the LRR is being requested. This gives the context in which the target layer index is to be interpreted. Reserved (RES) (three separate fields, 16 bits / 5 bits / 5 bits) All bits SHALL be set to 0 by the sender and SHALL be ignored on reception. Target Temporal Layer ID (TTID) (3 bits) The temporal ID of the target layer for which the receiver wishes a refresh point. Lennox, et al. Expires December 31, 2017 [Page 6] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Target Layer ID (TLID) (8 bits) The layer ID of the target spatial or quality layer for which the receiver wishes a refresh point. Its format is dependent on the payload type field. Current Temporal Layer ID (CTID) (3 bits) If C is 1, the ID of the current temporal layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to 0 by the sender and SHALL be ignored on reception. Current Layer ID (CLID) (8 bits) If C is 1, the layer ID of the current spatial or quality layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to 0 by the sender and SHALL be ignored on reception. When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID; at least one of TTID or TLID MUST be greater than CTID or CLID respectively. That is to say, the target layer index MUST be a layer upgrade from the current layer index . A sender MAY request an upgrade in both temporal and spatial/quality layers simultaneously. A receiver receiving an LRR feedback packet which does not satisfy the requirements of the previous paragraph, i.e. one where the C bit is present but TTID is less than CTID or TLID is less than CLID, MUST discard the request. Note: the syntax of the TTID, TLID, CTID, and CLID fields match, by design, the TID and LID fields in [I-D.ietf-avtext-framemarking]. 3.2. Semantics Within the common packet header for feedback messages (as defined in section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to 0. The SSRCs of the media senders to which the LRR command applies are in the corresponding FCI entries. A LRR message MAY contain requests to multiple media senders, using one FCI entry per target media sender. Upon reception of LRR, the encoder MUST send a decoder refresh point (see Section 2.1) as soon as possible. The sender MUST respect bandwidth limits provided by the application of congestion control, as described in Section 5 of [RFC5104]. As layer refresh points will often be larger than non-refreshing frames, Lennox, et al. Expires December 31, 2017 [Page 7] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 this may restrict a sender's ability to send a layer refresh point quickly. LRR MUST NOT be sent as a reaction to picture losses due to packet loss or corruption -- it is RECOMMENDED to use PLI [RFC4585] instead. LRR SHOULD be used only in situations where there is an explicit change in decoders' behavior, for example when a receiver will start decoding a layer which it previously had been discarding. 4. Usage with specific codecs In order for LRR to be used with a scalable codec, the format of the temporal and layer ID fields (for both the target and current layer indices) needs to be specified for that codec's RTP packetization. New RTP packetization specifications for scalable codecs SHOULD define how this is done. (The VP9 payload [I-D.ietf-payload-vp9], for instance, has done so.) If the payload also specifies how it is used with the Frame Marking RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST be defined in the same manner as the TID and LID fields in that header. 4.1. H264 SVC H.264 SVC [RFC6190] defines temporal, dependency (spatial), and quality scalability modes. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |R| DID | QID | +---------------+---------------+ Figure 6 Figure 6 shows the format of the layer index fields for H.264 SVC streams. The "R" and "RES" fields MUST be set to 0 on transmission and ignored on reception. See [RFC6190] Section 1.1.3 for details on the DID, QID, and TID fields. A dependency or quality layer refresh of a given layer in H.264 SVC can be identified by the "I" bit (idr_flag) in the extended NAL unit header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of the base layer can also be identified by its NAL unit type of its coded slices, which is "5" rather than "1". A dependency or quality layer refresh is complete once this bit has been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. Lennox, et al. Expires December 31, 2017 [Page 8] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Note that as the "I" bit in a PACSI header is set if the corresponding bit is set in any of the aggregated NAL units it describes; thus, it is not sufficient to identify layer refresh when NAL units of multiple dependency or quality layers are aggregated. In H.264 SVC, temporal layer refresh information can be determined from various Supplemental Encoding Information (SEI) messages in the bitstream. Whether an H.264 SVC stream is scalably nested can be determined from the Scalability Information SEI message's temporal_id_nesting flag. If this flag is set in a stream's currently applicable Scalability Information SEI, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. (The Scalability Information SEI message may also be available in the signaling negotiation of H.264 SVC, as the sprop- scalability-info parameter.) If a stream's temporal_id_nesting flag is not set, the Temporal Level Switching Point SEI message identifies temporal layer switching points. A temporal layer refresh is satisfied when this SEI message is present in a frame with the target layer index, if the message's delta_frame_num refers to a frame with the requested current layer index. (Alternately, temporal layer refresh can also be satisfied by a complete state refresh, such as an IDR.) Senders which support receiving LRR for non-temporally-nested streams MUST insert Temporal Level Switching Point SEI messages as appropriate. 4.2. VP8 The VP8 RTP payload format [RFC7741] defines temporal scalability modes. It does not support spatial scalability. +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID | RES | +---------------+---------------+ Figure 7 Figure 7 shows the format of the layer index field for VP8 streams. The "RES" fields MUST be set to 0 on transmission and be ignored on reception. See [RFC7741] Section 4.2 for details on the TID field. A VP8 layer refresh point can be identified by the presence of the "Y" bit in the VP8 payload header. When this bit is set, this and all subsequent frames depend only on the current base temporal layer. Lennox, et al. Expires December 31, 2017 [Page 9] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 On receipt of an LRR for a VP8 stream, A sender which supports LRR MUST encode the stream so it can set the Y bit in a packet whose temporal layer is at or below the target layer index. Note that in VP8, not every layer switch point can be identified by the Y bit, since the Y bit implies layer switch of all layers, not just the layer in which it is sent. Thus the use of LRR with VP8 can result in some inefficiency in transmision. However, this is not expected to be a major issue for temporal structures in normal use. 4.3. H265 The initial version of the H.265 payload format [RFC7798] defines temporal scalability, with protocol elements reserved for spatial or other scalability modes (which are expected to be defined in a future version of the specification). +---------------+---------------+ |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | TID |RES| LayerId | +---------------+---------------+ Figure 8 Figure 8 shows the format of the layer index field for H.265 streams. The "RES" fields MUST be set to 0 on transmission and ignored on reception. See [RFC7798] Section 1.1.4 for details on the LayerId and TID fields. H.265 streams signal whether they are temporally nested, using the vps_temporal_id_nesting_flag in the Video Parameter Set (VPS), and the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If this flag is set in a stream's currently applicable VPS or SPS, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit types 2 to 5 inclusively identify temporal layer switching points. A layer refresh to any higher target temporal layer is satisfied when a NAL unit type of 4 or 5 with TID equal to 1 more than current TID is seen. Alternatively, layer refresh to a target temporal layer can be incrementally satisfied with NAL unit type of 2 or 3. In this case, given current TID = TO and target TID = TN, layer refresh to TN is satisfied when NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up to TID = TN. During this incremental process, layer refresh to TN can be completely satisfied as soon as a NAL unit type of 2 or 3 is seen. Lennox, et al. Expires December 31, 2017 [Page 10] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Of course, temporal layer refresh can also be satisfied whenever any Intra Random Access Point (IRAP) NAL unit type (with values 16-23, inclusively) is seen. An IRAP picture is similar to an IDR picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start without any older pictures. In the (future) H.265 payloads that support spatial scalability, a spatial layer refresh of a specific layer can be identified by NAL units with the requested layer ID and NAL unit types between 16 and 21 inclusive. A dependency or quality layer refresh is complete once NAL units of this type have been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index. 5. Usage with different scalability transmission mechanisms Several different mechanisms are defined for how scalable streams can be transmitted in RTP. The RTP Taxonomy [RFC7656] Section 3.7 defines three mechanisms: Single RTP Stream on a Single Media Transport (SRST), Multiple RTP Streams on a Single Media Transport (MRST), and Multiple RTP Streams on Multiple Media Transports (MRMT). The LRR message is applicable to all these mechanisms. For MRST and MRMT mechanisms, the "media source" field of the LRR FCI is set to the SSRC of the RTP stream containing the layer indicated by the Current Layer Index (if "C" is 1), or the stream containing the base encoded stream (if "C" is 0). For MRMT, it is sent on the RTP session on which this stream is sent. On receipt, the sender MUST refresh all the layers requested in the stream, simultaneously in decode order. 6. SDP Definitions Section 7 of [RFC5104] defines SDP procedures for indicating and negotiating support for codec control messages (CCM) in SDP. This document extends this with a new codec control command, "lrr", which indicates support of the Layer Refresh Request (LRR). Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, extending the grammar defined in [RFC5104]. rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request Figure 9: Syntax of the "lrr" ccm The Offer-Answer considerations defined in [RFC5104] Section 7.2 apply. Lennox, et al. Expires December 31, 2017 [Page 11] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 7. Security Considerations All the security considerations of FIR feedback packets [RFC5104] apply to LRR feedback packets as well. Additionally, media senders receiving LRR feedback packets MUST validate that the payload types and layer indices they are receiving are valid for the stream they are currently sending, and discard the requests if not. 8. IANA Considerations This document defines a new entry to the "Codec Control Messages" subregistry of the "Session Description Protocol (SDP) Parameters" registry, according to the following data: Value name: lrr Long name: Layer Refresh Request Command Usable with: ccm Mux: IDENTICAL-PER-PT Reference: RFC XXXX This document also defines a new entry to the "FMT Values for PSFB Payload Types" subregistry of the "Real-Time Transport Protocol (RTP) Parameters" registry, according to the following data: Name: LRR Long Name: Layer Refresh Request Command Value: TBD Reference: RFC XXXX 9. References 9.1. Normative References [I-D.ietf-avtext-framemarking] Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking RTP Header Extension", draft-ietf-avtext-framemarking-04 (work in progress), March 2017. Lennox, et al. Expires December 31, 2017 [Page 12] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, . [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, . 9.2. Informative References [I-D.ietf-payload-vp9] Uberti, J., Holmer, S., Flodman, M., Lennox, J., and D. Hong, "RTP Payload Format for VP9 Video", draft-ietf- payload-vp9-03 (work in progress), March 2017. Lennox, et al. Expires December 31, 2017 [Page 13] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund, "Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs", RFC 8082, DOI 10.17487/RFC8082, March 2017, . Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Danny Hong Vidyo, Inc. 433 Hackensack Avenue Seventh Floor Hackensack, NJ 07601 US Email: danny@vidyo.com Justin Uberti Google, Inc. 747 6th Street South Kirkland, WA 98033 USA Email: justin@uberti.name Lennox, et al. Expires December 31, 2017 [Page 14] Internet-Draft Layer Refresh Request RTCP Feedback June 2017 Stefan Holmer Google, Inc. Kungsbron 2 Stockholm 111 22 Sweden Email: holmer@google.com Magnus Flodman Google, Inc. Kungsbron 2 Stockholm 111 22 Sweden Email: mflodman@google.com Lennox, et al. Expires December 31, 2017 [Page 15] ./draft-ietf-idr-flow-spec-v6-21.txt0000644000764400076440000011121613757224101016363 0ustar iustyiusty IDR Working Group C. Loibl, Ed. Internet-Draft next layer Telekom GmbH Updates: I-D.ietf-idr-rfc5575bis (if R. Raszuk, Ed. approved) Bloomberg LP Intended status: Standards Track S. Hares, Ed. Expires: May 28, 2021 Huawei November 24, 2020 Dissemination of Flow Specification Rules for IPv6 draft-ietf-idr-flow-spec-v6-21 Abstract Dissemination of Flow Specification Rules I-D.ietf-idr-rfc5575bis provides a Border Gateway Protocol extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends I-D.ietf-idr-rfc5575bis with IPv6 functionality. It also updates I-D.ietf-idr-rfc5575bis by changing the IANA Flow Spec Component Types registry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 28, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of Loibl, et al. Expires May 28, 2021 [Page 1] Internet-Draft IPv6 Flow Specification November 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Definitions of Terms Used in This Memo . . . . . . . . . 3 2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . 3 3. IPv6 Flow Specification components . . . . . . . . . . . . . 3 3.1. Type 1 - Destination IPv6 Prefix . . . . . . . . . . . . 4 3.2. Type 2 - Source IPv6 Prefix . . . . . . . . . . . . . . . 4 3.3. Type 3 - Upper-Layer Protocol . . . . . . . . . . . . . . 5 3.4. Type 7 - ICMPv6 Type . . . . . . . . . . . . . . . . . . 5 3.5. Type 8 - ICMPv6 Code . . . . . . . . . . . . . . . . . . 5 3.6. Type 12 - Fragment . . . . . . . . . . . . . . . . . . . 6 3.7. Type 13 - Flow Label (new) . . . . . . . . . . . . . . . 7 3.8. Encoding Example . . . . . . . . . . . . . . . . . . . . 7 4. Ordering of Flow Specifications . . . . . . . . . . . . . . . 9 5. Validation Procedure . . . . . . . . . . . . . . . . . . . . 10 6. IPv6 Traffic Filtering Action changes . . . . . . . . . . . . 10 6.1. Redirect IPv6 (rt-redirect-ipv6) Type/Sub-Type 0x80/TBD . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8.1. Flow Spec IPv6 Component Types . . . . . . . . . . . . . 11 8.1.1. Registry Template . . . . . . . . . . . . . . . . . . 11 8.1.2. Registry Contents . . . . . . . . . . . . . . . . . . 11 8.2. Extended Community Flow Spec IPv6 Actions . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Example python code: flow_rule_cmp_v6 . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The growing amount of IPv6 traffic in private and public networks requires the extension of tools used in IPv4-only networks to also support IPv6 data packets. This document analyzes the differences between describing IPv6 [RFC8200] flows and those of IPv4 packets. It specifies new Border Loibl, et al. Expires May 28, 2021 [Page 2] Internet-Draft IPv6 Flow Specification November 2020 Gateway Protocol [RFC4271] encoding formats to enable Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis] for IPv6. This specification is an extension of the base [I-D.ietf-idr-rfc5575bis]. It only defines the delta changes required to support IPv6 while all other definitions and operation mechanisms of Dissemination of Flow Specification Rules will remain in the main specification and will not be repeated here. 1.1. Definitions of Terms Used in This Memo AFI - Address Family Identifier. AS - Autonomous System. NLRI - Network Layer Reachability Information. SAFI - Subsequent Address Family Identifier. VRF - Virtual Routing and Forwarding instance. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. IPv6 Flow Specification encoding in BGP [I-D.ietf-idr-rfc5575bis] defines SAFIs 133 (Dissemination of Flow Specification) and 134 (L3VPN Dissemination of Flow Specification) in order to carry the corresponding Flow Specification. Implementations wishing to exchange IPv6 Flow Specifications MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in [RFC4760]. The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be: (AFI=2, SAFI=133) for IPv6 Flow Specification, and (AFI=2, SAFI=134) for VPNv6 Flow Specification. 3. IPv6 Flow Specification components The encoding of each of the components begins with a type field (1 octet) followed by a variable length parameter. The following sections define component types and parameter encodings for IPv6. Types 4 (Port), 5 (Destination Port), 6 (Source Port), 9 (TCP flags), 10 (Packet length) and 11 (DSCP), as defined in Loibl, et al. Expires May 28, 2021 [Page 3] Internet-Draft IPv6 Flow Specification November 2020 [I-D.ietf-idr-rfc5575bis], also apply to IPv6. Note that IANA is requested to update the "Flow Spec Component Types" registry in order to contain both IPv4 and IPv6 Flow Specification component type numbers in a single registry (Section 8). 3.1. Type 1 - Destination IPv6 Prefix Encoding: Defines the destination prefix to match. The offset has been defined to allow for flexible matching to portions of an IPv6 address where one is required to skip over the first N bits of the address (these bits skipped are often indicated as "don't care" bits). This can be especially useful where part of the IPv6 address consists of an embedded IPv4 address and matching needs to happen only on the embedded IPv4 address. The encoded pattern contains enough octets for the bits used in matching (length minus offset bits). length - The length field indicates the N-th most significant bit in the address where bitwise pattern matching stops. offset - The offset field indicates the number of most significant address bits to skip before bitwise pattern matching starts. pattern - Contains the matching pattern. The length of the pattern is defined by the number of bits needed for pattern matching (length minus offset). padding - The minimum number of bits required to pad the component to an octet boundary. Padding bits MUST be 0 on encoding and MUST be ignored on decoding. length = offset = 0 matches every address, otherwise length MUST be in the range offset < length < 129 or the component is malformed. Note: This Flow Specification component can be represented by the notation ipv6address/length if offset is 0, or ipv6address/offset- length. The ipv6address in this notation is the textual IPv6 representation of the pattern shifted to the right by the number of offset bits. See also Section 3.8. 3.2. Type 2 - Source IPv6 Prefix Encoding: Loibl, et al. Expires May 28, 2021 [Page 4] Internet-Draft IPv6 Flow Specification November 2020 Defines the source prefix to match. The length, offset, pattern and padding are the same as in Section 3.1. 3.3. Type 3 - Upper-Layer Protocol Encoding: Contains a list of {numeric_op, value} pairs that are used to match the first Next Header value octet in IPv6 packets that is not an extension header and thus indicates that the next item in the packet is the corresponding upper-layer header (see [RFC8200] Section 4). This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=00). Note: While IPv6 allows for more than one Next Header field in the packet, the main goal of the Type 3 Flow Specification component is to match on the first upper-layer IP protocol value. Therefore the definition is limited to match only on this specific Next Header field in the packet. 3.4. Type 7 - ICMPv6 Type Encoding: Defines a list of {numeric_op, value} pairs used to match the type field of an ICMPv6 packet (see also [RFC4443] Section 2.1). This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 7 component values SHOULD be encoded as single octet (numeric_op len=00). In case of the presence of the ICMPv6 Type component only ICMPv6 packets can match the entire Flow Specification. The ICMPv6 Type component, if present, never matches when the packet's upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header. 3.5. Type 8 - ICMPv6 Code Encoding: Defines a list of {numeric_op, value} pairs used to match the code field of an ICMPv6 packet (see also [RFC4443] Section 2.1). Loibl, et al. Expires May 28, 2021 [Page 5] Internet-Draft IPv6 Flow Specification November 2020 This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 8 component values SHOULD be encoded as single octet (numeric_op len=00). In case of the presence of the ICMPv6 Code component only ICMPv6 packets can match the entire Flow Specification. The ICMPv6 code component, if present, never matches when the packet's upper-layer IP protocol value is not 58 (ICMPv6), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header. 3.6. Type 12 - Fragment Encoding: Defines a list of {bitmask_op, bitmask} pairs used to match specific IP fragments. This component uses the Bitmask Operator (bitmask_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.2. The Type 12 component bitmask MUST be encoded as single octet bitmask (bitmask_op len=00). 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 |LF |FF |IsF| 0 | +---+---+---+---+---+---+---+---+ Figure 1: Fragment Bitmask Operand Bitmask values: IsF - Is a fragment other than the first - match if IPv6 Fragment Header ([RFC8200] Section 4.5) Fragment Offset is not 0 FF - First fragment - match if IPv6 Fragment Header ([RFC8200] Section 4.5) Fragment Offset is 0 AND M flag is 1 LF - Last fragment - match if IPv6 Fragment Header ([RFC8200] Section 4.5) Fragment Offset is not 0 AND M flag is 0 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding Loibl, et al. Expires May 28, 2021 [Page 6] Internet-Draft IPv6 Flow Specification November 2020 3.7. Type 13 - Flow Label (new) Encoding: Contains a list of {numeric_op, value} pairs that are used to match the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3). This component uses the Numeric Operator (numeric_op) described in [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1. Type 13 component values SHOULD be encoded as 4-octet quantities (numeric_op len=10). 3.8. Encoding Example 3.8.1. Example 1 The following example demonstrates the prefix encoding for: "packets from ::1234:5678:9a00:0/64-104 to 2001:db8::/32 and upper-layer- protocol tcp". +--------+----------------------+-------------------------+----------+ | length | destination | source | ul-proto | +--------+----------------------+-------------------------+----------+ | 0x12 | 01 20 00 20 01 0D B8 | 02 68 40 12 34 56 78 9A | 03 81 06 | +--------+----------------------+-------------------------+----------+ Decoded: Loibl, et al. Expires May 28, 2021 [Page 7] Internet-Draft IPv6 Flow Specification November 2020 +-------+------------+-------------------------------+ | Value | | | +-------+------------+-------------------------------+ | 0x12 | length | 18 octets (len<240 1-octet) | | 0x01 | type | Type 1 - Dest. IPv6 Prefix | | 0x20 | length | 32 bit | | 0x00 | offset | 0 bit | | 0x20 | pattern | | | 0x01 | pattern | | | 0x0D | pattern | | | 0xB8 | pattern | (no padding needed) | | 0x02 | type | Type 2 - Source IPv6 Prefix | | 0x68 | length | 104 bit | | 0x40 | offset | 64 bit | | 0x12 | pattern | | | 0x34 | pattern | | | 0x56 | pattern | | | 0x78 | pattern | | | 0x9A | pattern | (no padding needed) | | 0x03 | type | Type 3 - upper-layer-proto | | 0x81 | numeric_op | end-of-list, value size=1, == | | 0x06 | value | 06 | +-------+------------+-------------------------------+ This constitutes a NLRI with a NLRI length of 18 octets. Padding is not needed either for the destination prefix pattern (length - offset = 32 bit) or for the source prefix pattern (length - offset = 40 bit), as both patterns end on an octet boundary. 3.8.2. Example 2 The following example demonstrates the prefix encoding for: "all packets from ::1234:5678:9a00:0/65-104 to 2001:db8::/32". +--------+----------------------+-------------------------+ | length | destination | source | +--------+----------------------+-------------------------+ | 0x0f | 01 20 00 20 01 0D B8 | 02 68 41 24 68 ac f1 34 | +--------+----------------------+-------------------------+ Decoded: Loibl, et al. Expires May 28, 2021 [Page 8] Internet-Draft IPv6 Flow Specification November 2020 +-------+-------------+-------------------------------+ | Value | | | +-------+-------------+-------------------------------+ | 0x0f | length | 15 octets (len<240 1-octet) | | 0x01 | type | Type 1 - Dest. IPv6 Prefix | | 0x20 | length | 32 bit | | 0x00 | offset | 0 bit | | 0x20 | pattern | | | 0x01 | pattern | | | 0x0D | pattern | | | 0xB8 | pattern | (no padding needed) | | 0x02 | type | Type 2 - Source IPv6 Prefix | | 0x68 | length | 104 bit | | 0x41 | offset | 65 bit | | 0x24 | pattern | | | 0x68 | pattern | | | 0xac | pattern | | | 0xf1 | pattern | | | 0x34 | pattern/pad | (contains 1 bit padding) | +-------+-------------+-------------------------------+ This constitutes a NLRI with a NLRI length of 15 octets. The source prefix pattern is 104 - 65 = 39 bits in length. After the pattern one bit of padding needs to be added so that the component ends on a octet boundary. However, only the first 39 bits are actually used for bitwise pattern matching starting with a 65 bit offset from the topmost bit of the address. 4. Ordering of Flow Specifications The definition for the order of traffic filtering rules from [I-D.ietf-idr-rfc5575bis] Section 5.1 is reused with new consideration for the IPv6 prefix offset. As long as the offsets are equal, the comparison is the same, retaining longest-prefix-match semantics. If the offsets are not equal, the lowest offset has precedence, as this Flow Specification matches the most significant bit. The code in Appendix A shows a Python3 implementation of the resulting comparison algorithm. The full code was tested with Python 3.7.2 and can be obtained at https://github.com/stoffi92/draft-ietf- idr-flow-spec-v6/tree/master/flowspec-cmp [1]. Loibl, et al. Expires May 28, 2021 [Page 9] Internet-Draft IPv6 Flow Specification November 2020 5. Validation Procedure The validation procedure is the same as specified in [I-D.ietf-idr-rfc5575bis] Section 6 with the exception that item a) of the validation procedure should now read as follows: a) A destination prefix component with offset=0 is embedded in the Flow Specification 6. IPv6 Traffic Filtering Action changes Traffic Filtering Actions from [I-D.ietf-idr-rfc5575bis] Section 7 can also be applied to IPv6 Flow Specifications. To allow an IPv6 address specific route-target, a new Traffic Filtering Action IPv6 address specific extended community is specified in Section 6.1 below. 6.1. Redirect IPv6 (rt-redirect-ipv6) Type/Sub-Type 0x80/TBD The redirect IPv6 address specific extended community allows the traffic to be redirected to a VRF routing instance that lists the specified IPv6 address specific route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This extended community uses the same encoding as the IPv6 address specific Route Target extended community [RFC5701] Section 2 with the high-order octet of the Type always set to 0x80 and the Sub-Type always TBD. The Local Administrator sub-field contains a number from a numbering space that is administered by the organization to which the IP address carried in the Global Administrator sub-field has been assigned by an appropriate authority. Interferes with: All BGP Flow Specification redirect Traffic Filtering Actions (with itself and those specified in [I-D.ietf-idr-rfc5575bis] Section 7.4). 7. Security Considerations This document extends the functionality in [I-D.ietf-idr-rfc5575bis] to be applicable to IPv6 data packets. The same Security Considerations from [I-D.ietf-idr-rfc5575bis] now also apply to IPv6 networks. Loibl, et al. Expires May 28, 2021 [Page 10] Internet-Draft IPv6 Flow Specification November 2020 [RFC7112] describes the impact of oversized IPv6 header chains when trying to match on the transport header; [RFC8200] Section 4.5 also requires that the first fragment must include the upper-layer header but there could be wrongly formatted packets not respecting [RFC8200]. IPv6 Flow Specification component type 3 (Section 3.3) will not be enforced for those illegal packets. Moreover, there are hardware limitations in several routers ([RFC8883] Section 1) that may make it impossible to enforce a policy signaled by a type 3 Flow Specification component or Flow Specification components that match on upper-layer properties of the packet. 8. IANA Considerations This section complies with [RFC7153]. 8.1. Flow Spec IPv6 Component Types IANA has created and maintains a registry entitled "Flow Spec Component Types". IANA is requested to add [this document] to the reference for this registry. Furthermore the registry should be rewritten to also contain the IPv6 Flow Specification Component Types as described below. The registration procedure should remain unchanged. 8.1.1. Registry Template Type Value: Contains the assigned Flow Specification component type value. IPv4 Name: Contains the associated IPv4 Flow Specification component name as specified in [I-D.ietf-idr-rfc5575bis]. IPv6 Name: Contains the associated IPv6 Flow Specification component name as specified in this document. Reference: Contains referenced to the specifications. 8.1.2. Registry Contents + Type Value: 0 + IPv4 Name: Reserved + IPv6 Name: Reserved + Reference: [I-D.ietf-idr-rfc5575bis] [this document] Loibl, et al. Expires May 28, 2021 [Page 11] Internet-Draft IPv6 Flow Specification November 2020 + Type Value: 1 + IPv4 Name: Destination Prefix + IPv6 Name: Destination IPv6 Prefix + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 2 + IPv4 Name: Source Prefix + IPv6 Name: Source IPv6 Prefix + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 3 + IPv4 Name: IP Protocol + IPv6 Name: Upper-Layer Protocol + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 4 + IPv4 Name: Port + IPv6 Name: Port + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 5 + IPv4 Name: Destination Port + IPv6 Name: Destination Port + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 6 + IPv4 Name: Source Port + IPv6 Name: Source Port + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 7 + IPv4 Name: ICMP Type + IPv6 Name: ICMPv6 Type + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 8 + IPv4 Name: ICMP Code + IPv6 Name: ICMPv6 Code + Reference: [I-D.ietf-idr-rfc5575bis] [this document] Loibl, et al. Expires May 28, 2021 [Page 12] Internet-Draft IPv6 Flow Specification November 2020 + Type Value: 9 + IPv4 Name: TCP flags + IPv6 Name: TCP flags + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 10 + IPv4 Name: Packet length + IPv6 Name: Packet length + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 11 + IPv4 Name: DSCP + IPv6 Name: DSCP + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 12 + IPv4 Name: Fragment + IPv6 Name: Fragment + Reference: [I-D.ietf-idr-rfc5575bis] [this document] + Type Value: 13 + IPv4 Name: Unassigned + IPv6 Name: Flow Label + Reference: [this document] + Type Value: 14-254 + IPv4 Name: Unassigned + IPv6 Name: Unassigned + Reference: + Type Value: 255 + IPv4 Name: Reserved + IPv6 Name: Reserved + Reference: [I-D.ietf-idr-rfc5575bis] [this document] 8.2. Extended Community Flow Spec IPv6 Actions IANA maintains a registry entitled "Generic Transitive Experimental Use Extended Community Sub-Types". For the purpose of this work, IANA is requested to assign a new value: Loibl, et al. Expires May 28, 2021 [Page 13] Internet-Draft IPv6 Flow Specification November 2020 +----------------+--------------------------------+-----------------+ | Sub-Type Value | Name | Reference | +----------------+--------------------------------+-----------------+ | TBD | Flow spec rt-redirect-ipv6 | [this document] | | | format | | +----------------+--------------------------------+-----------------+ Table 1: Registry: Generic Transitive Experimental Use Extended Community Sub-Types 9. Acknowledgements Authors would like to thank Pedro Marques, Hannes Gredler, Bruno Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. 10. Contributors Danny McPherson Verisign, Inc. Email: dmcpherson@verisign.com Burjiz Pithawala Individual Email: burjizp@gmail.com Andy Karch Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: akarch@cisco.com 11. References 11.1. Normative References [I-D.ietf-idr-rfc5575bis] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", draft-ietf-idr-rfc5575bis-27 (work in progress), October 2020. Loibl, et al. Expires May 28, 2021 [Page 14] Internet-Draft IPv6 Flow Specification November 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, . [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, . [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to Processing Limits", RFC 8883, DOI 10.17487/RFC8883, September 2020, . Loibl, et al. Expires May 28, 2021 [Page 15] Internet-Draft IPv6 Flow Specification November 2020 11.2. URIs [1] https://github.com/stoffi92/draft-ietf-idr-flow-spec- v6/tree/master/flowspec-cmp Appendix A. Example python code: flow_rule_cmp_v6 """ Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). """ import itertools import collections import ipaddress EQUAL = 0 A_HAS_PRECEDENCE = 1 B_HAS_PRECEDENCE = 2 IP_DESTINATION = 1 IP_SOURCE = 2 FS_component = collections.namedtuple('FS_component', 'component_type value') class FS_IPv6_prefix_component: def __init__(self, prefix, offset=0, component_type=IP_DESTINATION): self.offset = offset self.component_type = component_type # make sure if offset != 0 that none of the # first offset bits are set in the prefix self.value = prefix if offset != 0: i = ipaddress.IPv6Interface( (self.value.network_address, offset)) if i.network.network_address != \ ipaddress.ip_address('0::0'): raise ValueError('Bits set in the offset') Loibl, et al. Expires May 28, 2021 [Page 16] Internet-Draft IPv6 Flow Specification November 2020 class FS_nlri(object): """ FS_nlri class implementation that allows sorting. By calling .sort() on an array of FS_nlri objects these will be sorted according to the flow_rule_cmp algorithm. Example: nlri = [ FS_nlri(components=[ FS_component(component_type=4, value=bytearray([0,1,2,3,4,5,6])), ]), FS_nlri(components=[ FS_component(component_type=5, value=bytearray([0,1,2,3,4,5,6])), FS_component(component_type=6, value=bytearray([0,1,2,3,4,5,6])), ]), ] nlri.sort() # sorts the array according to the algorithm """ def __init__(self, components = None): """ components: list of type FS_component """ self.components = components def __lt__(self, other): # use the below algorithm for sorting result = flow_rule_cmp_v6(self, other) if result == B_HAS_PRECEDENCE: return True else: return False def flow_rule_cmp_v6(a, b): """ Implementation of the flowspec sorting algorithm in draft-ietf-idr-flow-spec-v6. """ for comp_a, comp_b in itertools.zip_longest(a.components, b.components): # If a component type does not exist in one rule # this rule has lower precedence if not comp_a: return B_HAS_PRECEDENCE if not comp_b: Loibl, et al. Expires May 28, 2021 [Page 17] Internet-Draft IPv6 Flow Specification November 2020 return A_HAS_PRECEDENCE # Higher precedence for lower component type if comp_a.component_type < comp_b.component_type: return A_HAS_PRECEDENCE if comp_a.component_type > comp_b.component_type: return B_HAS_PRECEDENCE # component types are equal -> type specific comparison if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): if comp_a.offset < comp_b.offset: return A_HAS_PRECEDENCE if comp_a.offset > comp_b.offset: return B_HAS_PRECEDENCE # both components have the same offset # assuming comp_a.value, comp_b.value of type # ipaddress.IPv6Network # and the offset bits are reset to 0 (since they are # not represented in the NLRI) if comp_a.value.overlaps(comp_b.value): # longest prefixlen has precedence if comp_a.value.prefixlen > \ comp_b.value.prefixlen: return A_HAS_PRECEDENCE if comp_a.value.prefixlen < \ comp_b.value.prefixlen: return B_HAS_PRECEDENCE # components equal -> continue with next # component elif comp_a.value > comp_b.value: return B_HAS_PRECEDENCE elif comp_a.value < comp_b.value: return A_HAS_PRECEDENCE else: # assuming comp_a.value, comp_b.value of type # bytearray if len(comp_a.value) == len(comp_b.value): if comp_a.value > comp_b.value: return B_HAS_PRECEDENCE if comp_a.value < comp_b.value: return A_HAS_PRECEDENCE # components equal -> continue with next # component else: common = min(len(comp_a.value), len(comp_b.value)) if comp_a.value[:common] > \ comp_b.value[:common]: return B_HAS_PRECEDENCE elif comp_a.value[:common] < \ Loibl, et al. Expires May 28, 2021 [Page 18] Internet-Draft IPv6 Flow Specification November 2020 comp_b.value[:common]: return A_HAS_PRECEDENCE # the first common bytes match elif len(comp_a.value) > len(comp_b.value): return A_HAS_PRECEDENCE else: return B_HAS_PRECEDENCE return EQUAL Authors' Addresses Christoph Loibl (editor) next layer Telekom GmbH Mariahilfer Guertel 37/7 Vienna 1150 AT Phone: +43 664 1176414 Email: cl@tix.at Robert Raszuk (editor) Bloomberg LP 731 Lexington Ave New York City, NY 10022 USA Email: robert@raszuk.net Susan Hares (editor) Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Loibl, et al. Expires May 28, 2021 [Page 19] ./draft-ietf-avtext-rid-09.txt0000644000764400076440000004622412775522766015503 0ustar iustyiusty Network Working Group A. Roach Internet-Draft Mozilla Intended status: Standards Track S. Nandakumar Expires: April 9, 2017 Cisco Systems P. Thatcher Google October 06, 2016 RTP Stream Identifier Source Description (SDES) draft-ietf-avtext-rid-09 Abstract This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 9, 2017. 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 Roach, et al. Expires April 9, 2017 [Page 1] Internet-Draft RtpStreamId SDES October 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage of RtpStreamId and RepairedRtpStreamId in RTP and RTCP 3 3.1. RTCP 'RtpStreamId' SDES Extension . . . . . . . . . . . . 5 3.2. RTCP 'RepairedRtpStreamId' SDES Extension . . . . . . . . 5 3.3. RTP 'RtpStreamId' and 'RepairedRtpStreamId' Header Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4.1. New RtpStreamId SDES item . . . . . . . . . . . . . . . . 6 4.2. New RepairRtpStreamId SDES item . . . . . . . . . . . . . 6 4.3. New RtpStreamId Header Extension URI . . . . . . . . . . 7 4.4. New RepairRtpStreamId Header Extension URI . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction RTP sessions frequently consist of multiple streams, each of which is identified at any given time by its SSRC; however, the SSRC associated with a stream is not guaranteed to be stable over its lifetime. Within a session, these streams can be tagged with a number of identifiers, including CNAMEs and MSIDs [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time. While approaches that use unique Payload Types (PTs) per stream have been used in some applications, this is a semantic overloading of that field, and one for which its size is inadequate: in moderately complex systems that use PT to uniquely identify every potential combination of codec configuration and unique stream, it is possible to simply run out of values. To address this situation, we define a new RTCP Stream Identifier Source Description (SDES) identifier, RtpStreamId, that uniquely identifies a single RTP stream. A key motivator for defining this identifier is the ability to differentiate among different encodings of a single Source Stream that are sent simultaneously (i.e., simulcast). This need for unique identification extends to dependent Roach, et al. Expires April 9, 2017 [Page 2] Internet-Draft RtpStreamId SDES October 2016 streams (e.g., where layers used by a layered codec are transmitted on separate streams). At the same time, when redundancy RTP streams are in use, we also need an identifier that connects such streams to the RTP stream for which they are providing redundancy. For this purpose, we define an additional SDES identifier, RepairedRtpStreamId. This identifier can appear only in packets associated with a redundancy RTP stream. They carry the same value as the RtpStreamId of the RTP stream that the redundant RTP stream is correcting. 2. Terminology In this document, the terms "source stream", "RTP stream", "source RTP stream", "dependent stream", "received RTP stream", and "redundancy RTP stream" are used as defined in [RFC7656]. The following acronyms are also used: o CNAME: Canonical End-Point Identifier, defined in [RFC3550] o MID: Media Identification, defined in [I-D.ietf-mmusic-sdp-bundle-negotiation] o MSID: Media Stream Identifier, defined in [I-D.ietf-mmusic-msid] o RTCP: Real-time Transport Control Protocol, defined in [RFC3550] o RTP: Real-time Transport Protocol, defined in [RFC3550] o SDES: Source Description, defined in [RFC3550] o SSRC: Synchronization Source, defined in [RFC3550] 3. Usage of RtpStreamId and RepairedRtpStreamId in RTP and RTCP The RTP fixed header includes the payload type number and the SSRC values of the RTP stream. RTP defines how you de-multiplex streams within an RTP session; however, in some use cases, applications need further identifiers in order to effectively map the individual RTP Streams to their equivalent payload configurations in the SDP. This specification defines two new RTCP SDES items [RFC3550]. The first item is 'RtpStreamId', which is used to carry RTP stream identifiers within RTCP SDES packets. This makes it possible for a receiver to associate received RTP packets (identifying the RTP stream) with a media description having the format constraint specified. The second is 'RepairedRtpStreamId', which can be used in Roach, et al. Expires April 9, 2017 [Page 3] Internet-Draft RtpStreamId SDES October 2016 redundancy RTP streams to indicate the RTP stream repaired by a redundancy RTP stream. To be clear: the value carried in a RepairedRtpStreamId will always match the RtpStreamId value from another RTP stream in the same session. For example, if a source RTP stream is identified by RtpStreamId "A", then any redundancy RTP stream that repairs that source RTP stream will contain a RepairedRtpStreamId of "A" (if this mechanism is being used to perform such correlation). These redundant RTP streams may also contain their own unique RtpStreamId. This specification also uses the RTP header extension for RTCP SDES items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RtpStreamId and RepairedRtpStreamId values in RTP packets. This allows correlation at stream startup, or after stream changes where the use of RTCP may not be sufficiently responsive. This speed of response is necessary since, in many cases, the stream cannot be properly processed until it can be identified. RtpStreamId and RepairedRtpStreamId values are scoped by source identifier (e.g., CNAME) and by media session. When the media is multiplexed using the BUNDLE extension [I-D.ietf-mmusic-sdp-bundle-negotiation], these values are further scoped by their associated MID values. For example: an RtpStreamId of "1" may be present in the stream identified with a CNAME of "1234@example.com", and may also be present in a stream with a CNAME of "5678@example.org", and these would refer to different streams. Similarly, an RtpStreamId of "1" may be present with an MID of "A", and again with a MID of "B", and also refer to two different streams. Note that the RepairedRtpStreamId mechanism is limited to indicating one repaired stream per redundancy stream. If systems require correlation for schemes in which a redundancy stream contains information used to repair more than one stream, they will have to use a more complex mechanism than the one defined in this specification. As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited to a total of 255 octets in length. RtpStreamId and RepairedStreamId are constrained to contain only alphanumeric characters. For avoidance of doubt, the only allowed byte values for these IDs are decimal 48 through 57, 65 through 90, and 97 through 122. Roach, et al. Expires April 9, 2017 [Page 4] Internet-Draft RtpStreamId SDES October 2016 3.1. RTCP 'RtpStreamId' SDES Extension 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |RtpStreamId=TBD| length | RtpStreamId ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RtpStreamId payload is ASCII encoded and is not null-terminated. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. 3.2. RTCP 'RepairedRtpStreamId' SDES Extension 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Repaired...=TBD| length | RepairRtpStreamId ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The RepairedRtpStreamId payload is ASCII encoded and is not null- terminated. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. 3.3. RTP 'RtpStreamId' and 'RepairedRtpStreamId' Header Extensions Because recipients of RTP packets will typically need to know which streams they correspond to immediately upon receipt, this specification also defines a means of carrying RtpStreamId and RepairedRtpStreamId identifiers in RTP extension headers, using the technique described in [I-D.ietf-avtext-sdes-hdr-ext]. As described in that document, the header extension element can be encoded using either the one-byte or two-byte header, and the identification-tag payload is ASCII-encoded. As the identifier is included in an RTP header extension, there should be some consideration given to the packet expansion caused by the identifier. To avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the header extension's size needs to be taken into account when encoding media. Note that the set of header extensions included in the packet needs to be padded to the next 32-bit boundary [RFC5285]. Roach, et al. Expires April 9, 2017 [Page 5] Internet-Draft RtpStreamId SDES October 2016 In many cases, a one-byte identifier will be sufficient to distinguish streams in a session; implementations are strongly encouraged to use the shortest identifier that fits their purposes. Implementors are warned, in particular, not to include any information in the identifier that is derived from potentially user- identifying information, such as user ID or IP address. To avoid identification of specific implementations based on their pattern of tag generation, implementations are encouraged to use a simple scheme that starts with the ASCII digit "1", and increments by one for each subsequent identifier. 4. IANA Considerations 4.1. New RtpStreamId SDES item RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. This document adds the RtpStreamId SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: RtpStreamId Name: RTP Stream Identifier Reference: RFCXXXX 4.2. New RepairRtpStreamId SDES item RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value. This document adds the RepairedRtpStreamId SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: RepairedRtpStreamId Name: Repaired RTP Stream Identifier Reference: RFCXXXX Roach, et al. Expires April 9, 2017 [Page 6] Internet-Draft RtpStreamId SDES October 2016 4.3. New RtpStreamId Header Extension URI RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. This document defines a new extension URI in the RTP SDES Compact Header Extensions sub-registry of the RTP Compact Header Extensions registry sub-registry, as follows Extension URI: urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Description: RTP Stream Identifier Contact: adam@nostrum.com Reference: RFCXXXX 4.4. New RepairRtpStreamId Header Extension URI RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. This document defines a new extension URI in the RTP SDES Compact Header Extensions sub-registry of the RTP Compact Header Extensions registry sub-registry, as follows Extension URI: urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id Description: RTP Repaired Stream Identifier Contact: adam@nostrum.com Reference: RFCXXXX 5. Security Considerations Although the identifiers defined in this document are limited to be strictly alphanumeric, SDES items have the potential to carry any string. As a consequence, there exists a risk that it might carry privacy-sensitive information. Implementations need to take care when generating identifiers so that they do not contain information that can identify the user or allow for long term tracking of the device. Following the generation recommendations in Section 3.3 will result in non-instance-specific labels, with only minor fingerprinting possibilities in the total number of used RtpStreamIds and RepairedRtpStreamIds. Even if the SDES items are generated to convey as little information as possible, implementors are strongly encouraged to encrypt SDES items - both in RTCP and RTP header extensions - so as to preserve privacy against third parties. As the SDES items are used for identification of the RTP streams for different application purposes, it is important that the intended values are received. An attacker, either a third party or malicious RTP middlebox, that removes, or changes the values for these SDES Roach, et al. Expires April 9, 2017 [Page 7] Internet-Draft RtpStreamId SDES October 2016 items, can severely impact the application. The impact can include failure to decode or display the media content of the RTP stream. It can also result in incorrectly attributing media content to identifiers of the media source, such as incorrectly identifying the speaker. To prevent this from occurring due to third party attacks, integrity and source authentication is needed. Options for Securing RTP Sessions [RFC7201] discusses options for how encryption, integrity and source authentication can be accomplished. 6. Acknowledgements Many thanks for review and input from Cullen Jennings, Magnus Westerlund, Colin Perkins, Jonathan Lennox, and Paul Kyzivat. Magnus Westerlund provided substantially all of the Security Considerations section. 7. References 7.1. Normative References [I-D.ietf-avtext-sdes-hdr-ext] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for RTCP Source Description Items", draft-ietf-avtext-sdes-hdr-ext-07 (work in progress), June 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-32 (work in progress), August 2016. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . Roach, et al. Expires April 9, 2017 [Page 8] Internet-Draft RtpStreamId SDES October 2016 7.2. Informative References [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-15 (work in progress), July 2016. [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . Authors' Addresses Adam Roach Mozilla Email: adam@nostrum.com Suhas Nandakumar Cisco Systems Email: snandaku@cisco.com Peter Thatcher Google Email: pthatcher@google.com Roach, et al. Expires April 9, 2017 [Page 9] ./draft-ietf-dnsop-dns-zone-digest-14.txt0000644000764400076440000024536413742077433017540 0ustar iustyiusty Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Standards Track Verisign Expires: April 18, 2021 M. Weinberg Amazon W. Kumari Google W. Hardaker USC/ISI October 15, 2020 Message Digest for DNS Zones draft-ietf-dnsop-dns-zone-digest-14 Abstract This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC. Whereas DNSSEC protects individual RRSets (DNS data with fine granularity), ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, The ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Wessels, et al. Expires April 18, 2021 [Page 1] Internet-Draft DNS Zone Digest October 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Alternative Approaches . . . . . . . . . . . . . . . . . 4 1.3. Design Overview . . . . . . . . . . . . . . . . . . . . . 6 1.4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 1.4.2. Providers, Secondaries, and Anycast . . . . . . . . . 7 1.4.3. Response Policy Zones . . . . . . . . . . . . . . . . 7 1.4.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.4.5. General Purpose Comparison Check . . . . . . . . . . 7 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 8 2.1. Non-apex ZONEMD Records . . . . . . . . . . . . . . . . . 8 2.2. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.2.1. The Serial Field . . . . . . . . . . . . . . . . . . 9 2.2.2. The Scheme Field . . . . . . . . . . . . . . . . . . 9 2.2.3. The Hash Algorithm Field . . . . . . . . . . . . . . 9 2.2.4. The Digest Field . . . . . . . . . . . . . . . . . . 10 2.3. ZONEMD Presentation Format . . . . . . . . . . . . . . . 10 2.4. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 10 2.5. Including ZONEMD RRs in a Zone . . . . . . . . . . . . . 10 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 11 3.1. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 11 3.2. Optionally Sign the Zone . . . . . . . . . . . . . . . . 12 Wessels, et al. Expires April 18, 2021 [Page 2] Internet-Draft DNS Zone Digest October 2020 3.3. Scheme-Specific Processing . . . . . . . . . . . . . . . 12 3.3.1. The SIMPLE Scheme . . . . . . . . . . . . . . . . . . 12 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules . . . . . 12 3.3.1.2. SIMPLE Scheme Digest Calculation . . . . . . . . 13 3.4. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 13 4. Verifying Zone Digest . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 15 5.2. ZONEMD Scheme . . . . . . . . . . . . . . . . . . . . . . 15 5.3. ZONEMD Hash Algorithm . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Using Zone Digest Without DNSSEC . . . . . . . . . . . . 16 6.2. Attacks Against the Zone Digest . . . . . . . . . . . . . 16 6.3. Use of Multiple ZONEMD Hash Algorithms . . . . . . . . . 17 6.4. DNSSEC Timing Considerations . . . . . . . . . . . . . . 17 6.5. Attacks Utilizing ZONEMD Queries . . . . . . . . . . . . 17 6.6. Resilience and Fragility . . . . . . . . . . . . . . . . 18 7. Performance Considerations . . . . . . . . . . . . . . . . . 18 7.1. SIMPLE SHA384 . . . . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Example Zones With Digests . . . . . . . . . . . . . 30 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 30 A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 30 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 31 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 32 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 35 Appendix B. Implementation Status . . . . . . . . . . . . . . . 37 B.1. Authors' Implementation . . . . . . . . . . . . . . . . . 37 B.2. Shane Kerr's Implementation . . . . . . . . . . . . . . . 37 B.3. NIC Chile Labs Implementation . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction In the DNS, a zone is the collection of authoritative resource records (RRs) sharing a common origin ([RFC8499]). Zones are often stored as files in the so-called master file format [RFC1034]. Zones are generally distributed among name servers using the AXFR (zone transfer [RFC5936]), and IXFR (incremental zone transfer [RFC1995]) protocols. They can also be distributed outside of the DNS, with any file transfer protocol such as FTP, HTTP, and rsync, or even as email attachments. Currently, there is no standard way to compute a hash or message digest for a stand-alone zone. Wessels, et al. Expires April 18, 2021 [Page 3] Internet-Draft DNS Zone Digest October 2020 This document specifies an RR type that provides a cryptographic message digest of the data in a zone. It allows a receiver of the zone to verify the zone's integrity and authenticity when used in combination with DNSSEC. The digest RR is a part of the zone itself, allowing verification of the zone, no matter how it is transmitted. The digest uses the wire format of zone data in a canonical ordering. Thus, it is independent of presentation format, such as whitespace, capitalization, and comments. This specification is OPTIONAL to implement by both publishers and consumers of zone data. 1.1. Motivation The primary motivation for this protocol enhancement is the desire to verify the data integrity and origin authenticity of a stand-alone zone, regardless of how it is transmitted. A consumer of zone data should be able to verify that it is as-published by the zone operator. Note, however, that integrity and authenticity can only be assured when the zone is signed. DNSSEC provides three strong security guarantees relevant to this protocol: 1. whether or not to expect DNSSEC records in the zone, 2. whether or not to expect a ZONEMD record in a signed zone, and 3. whether or not the ZONEMD record has been altered since it was signed. A secondary motivation is to provide the equivalent of a checksum, allowing a zone recipient to check for unintended changes and operational errors, such as accidental truncation. 1.2. Alternative Approaches One approach to preventing data tampering and corruption is to secure the distribution channel. The DNS has a number of features that are already used for channel security. Perhaps the most widely used is DNS transaction signatures (TSIG [RFC2845]). TSIG uses shared secret keys and a message digest to protect individual query and response messages. It is generally used to authenticate and validate UPDATE [RFC2136], AXFR [RFC5936], and IXFR [RFC1995] messages. DNS Request and Transaction Signatures (SIG(0) [RFC2931]) is another protocol extension that authenticates individual DNS transactions. Whereas SIG records normally cover specific RR types, SIG(0) is used Wessels, et al. Expires April 18, 2021 [Page 4] Internet-Draft DNS Zone Digest October 2020 to sign an entire DNS message. Unlike TSIG, SIG(0) uses public key cryptography rather than shared secrets. The Transport Layer Security protocol suite also provides channel security. The DPRIVE working group is in the process of specifying DNS Zone Transfer-over-TLS [I-D.ietf-dprive-xfr-over-tls]. One can also easily imagine the distribution of zones over HTTPS-enabled web servers, as well as DNS-over-HTTPS [RFC8484]. Unfortunately, the protections provided by these channel security techniques are (in practice) ephemeral and are not retained after the data transfer is complete. They ensure that the client receives the data from the expected server, and that the data sent by the server is not modified during transmission. However, they do not guarantee that the server transmits the data as originally published, and do not provide any methods to verify data that is read after transmission is complete. For example, a name server loading saved zone data upon restart cannot guarantee that the on-disk data has not been modified. Such modification could be the result of an accidental corruption of the file, or perhaps an incompletely saved file [disk-full-failure]. For these reasons, it is preferable to protect the integrity of the data itself. Why not simply rely on DNSSEC, which provides certain data security guarantees? For zones that are signed, a recipient could validate all of the signed RRSets. Additionally, denial-of-existence records prove that RRSets have not been added or removed. However, delegations (non-apex NS records) are not signed by DNSSEC, and neither are any glue records. ZONEMD protects the integrity of delegation, glue, and other records that are not otherwise covered by DNSSEC. Furthermore, zones that employ NSEC3 with opt-out [RFC5155] are susceptible to the removal or addition of names between the signed nodes. Whereas DNSSEC primarily protects consumers of DNS response messages, this protocol protects consumers of zones. There are existing tools and protocols that provide data security, such as OpenPGP [RFC4880] and S/MIME [RFC5751]. In fact, the internic.net site publishes PGP signatures alongside the root zone and other files available there. However, this is a detached signature with no strong association to the corresponding zone file other than its timestamp. Non-detached signatures are, of course, possible, but these necessarily change the format of the file being distributed; a zone signed with OpenPGP or S/MIME no longer looks like a DNS zone and could not directly be loaded into a name server. Once loaded the signature data is lost, so it cannot be further propagated. Wessels, et al. Expires April 18, 2021 [Page 5] Internet-Draft DNS Zone Digest October 2020 It seems the desire for data security in DNS zones was envisioned as far back as 1997. [RFC2065] is an obsoleted specification of the first generation DNSSEC Security Extensions. It describes a zone transfer signature, identified as the AXFR SIG, which is similar to the technique proposed by this document. That is, it proposes ordering all (signed) RRSets in a zone, hashing their contents, and then signing the zone hash. The AXFR SIG is described only for use during zone transfers. It did not postulate the need to validate zone data distributed outside of the DNS. Furthermore, its successor, [RFC2535], omits the AXFR SIG, while at the same time introducing an IXFR SIG. 1.3. Design Overview This document specifies a new Resource Record type to convey a message digest of the content of a zone. The digest is calculated at the time of zone publication. If the zone is signed with DNSSEC, any modifications of the digest can be detected. The procedures for digest calculation and DNSSEC signing are similar. Both require data to be processed in a well-defined order and format. It may be possible to perform DNSSEC signing and digest calculation in parallel. The zone digest is designed to be used on zones that have infrequent updates. As specified herein, the digest is re-calculated over the entire zone content each time the zone is updated. This specification does not provide an efficient mechanism for updating the digest on incremental updates of zone data. It is, however, extensible so that future schemes may be defined to support efficient incremental digest updates. It is expected that verification of a zone digest will be implemented in name server software. That is, a name server can verify the zone data it was given and refuse to serve a zone which fails verification. For signed zones, the name server needs a trust anchor to perform DNSSEC validation. For signed non-root zones, the name server may need to send queries to validate a chain of trust. Digest verification could also be performed externally. 1.4. Use Cases 1.4.1. Root Zone The root zone [InterNIC] is one of the most widely distributed DNS zone on the Internet, served by more than 1000 separate instances [RootServers] at the time of this writing. Additionally, many organizations configure their own name servers to serve the root zone locally. Reasons for doing so include privacy and reduced access Wessels, et al. Expires April 18, 2021 [Page 6] Internet-Draft DNS Zone Digest October 2020 time. [RFC8806] describes one way to do this. As the root zone spreads beyond its traditional deployment boundaries, the verification of the completeness of the zone contents becomes more important. 1.4.2. Providers, Secondaries, and Anycast Since its very early days, the developers of the DNS recognized the importance of secondary name servers and service diversity. However, modern DNS service has complex provisioning which includes multiple third-party providers ([RFC8901]) and hundreds of anycast instances ([RFC3258]). Instead of a simple primary-to-secondary zone distribution system, today it is possible to have multiple levels, multiple parties, and multiple protocols involved in the distribution of zone data. This complexity introduces new places for problems to arise. The zone digest protects the integrity of data that flows through such systems. 1.4.3. Response Policy Zones A Response Policy Zone (RPZ) is "a mechanism to introduce a customized policy in Domain Name System servers, so that recursive resolvers return possibly modified results" [RPZ]. The policy information is carried inside specially constructed DNS zones. A number of companies provide RPZ feeds, which are consumed by name server and firewall products. While RPZ zones can be signed with DNSSEC, the data is not queried directly, and would not be subject to DNSSEC validation. 1.4.4. Centralized Zone Data Service ICANN operates the Centralized Zone Data Service [CZDS], which is a repository of top-level domain zone files. Users that have been granted access are then able to download zone data. Adding a zone digest to these would provide CZDS users with assurances that the data has not been modified between origination and retrieval. Note that ZONEMD could be added to zone data supplied to CZDS without requiring it to be present in the zone data served by production name servers, since the digest is inherently attached to the specific copy of the zone. 1.4.5. General Purpose Comparison Check Since the zone digest calculation does not depend on presentation format, it could be used to compare multiple copies of a zone received from different sources, or copies generated by different processes. In this case, it serves as a checksum and can be useful even for unsigned zones. Wessels, et al. Expires April 18, 2021 [Page 7] Internet-Draft DNS Zone Digest October 2020 1.5. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms Private Use, Reserved, Unassigned, and Specification Required are to be interpreted as defined in [RFC8126]. 2. The ZONEMD Resource Record This section describes the ZONEMD Resource Record, including its fields, wire format, and presentation format. The Type value for the ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of the resource record consists of four fields: Serial, Scheme, Hash Algorithm, and Digest. 2.1. Non-apex ZONEMD Records This document specifies ZONEMD RRs located at the zone apex. Non- apex ZONEMD RRs are not forbidden, but have no meaning in this specification. Non-apex ZONEMD RRs MUST NOT be used for verification. During digest calculation, non-apex ZONEMD RRs are treated as ordinary RRs. They are digested as-is and the RR is not replaced by a placeholder RR. Unless explicitly stated otherwise, "ZONEMD" always refers to apex records throughout this document. 2.2. ZONEMD RDATA Wire Format The ZONEMD RDATA wire format is encoded as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scheme |Hash Algorithm | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Digest | / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wessels, et al. Expires April 18, 2021 [Page 8] Internet-Draft DNS Zone Digest October 2020 2.2.1. The Serial Field The Serial field is a 32-bit unsigned integer in network byte order. It is the serial number from the zone's SOA record ([RFC1035] section 3.3.13) for which the zone digest was generated. It is included here to clearly bind the ZONEMD RR to a particular version of the zone's content. Without the serial number, a stand- alone ZONEMD digest has no obvious association to any particular instance of a zone. 2.2.2. The Scheme Field The Scheme field is an 8-bit unsigned integer that identifies the methods by which data is collated and presented as input to the hashing function. Herein, SIMPLE, with Scheme value 1, is the only standardized Scheme defined for ZONEMD records and it MUST be supported by implementations. The Scheme registry is further described in Section 5. Scheme values 240-254 are allocated for Private Use. 2.2.3. The Hash Algorithm Field The Hash Algorithm field is an 8-bit unsigned integer that identifies the cryptographic hash algorithm used to construct the digest. Herein, SHA384 [RFC6234], with Hash Algorithm value 1, is the only standardized Hash Algorithm defined for ZONEMD records that MUST be supported by implementations. When SHA384 is used, the size of the Digest field is 48 octets. The result of the SHA384 digest algorithm MUST NOT be truncated, and the entire 48 octet digest is published in the ZONEMD record. SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for ZONEMD records, and SHOULD be supported by implementations. When SHA512 is used, the size of the Digest field is 64 octets. The result of the SHA512 digest algorithm MUST NOT be truncated, and the entire 64 octet digest is published in the ZONEMD record. Hash Algorithm values 240-254 are allocated for Private Use. The Hash Algorithm registry is further described in Section 5. Wessels, et al. Expires April 18, 2021 [Page 9] Internet-Draft DNS Zone Digest October 2020 2.2.4. The Digest Field The Digest field is a variable-length sequence of octets containing the output of the hash algorithm. The length of the Digest field is determined by deducting the fixed size of the Serial, Scheme, and Hash Algorithm fields from the RDATA size in the ZONEMD RR header. The Digest field MUST NOT be shorter than 12 octets. Digests for the SHA384 and SHA512 hash algorithms specified herein are never truncated. Digests for future hash algorithms MAY be truncated, but MUST NOT be truncated to a length that results in less than 96-bits (12 octets) of equivalent strength. Section 3 describes how to calculate the digest for a zone. Section 4 describes how to use the digest to verify the contents of a zone. 2.3. ZONEMD Presentation Format The presentation format of the RDATA portion is as follows: The Serial field is represented as an unsigned decimal integer. The Scheme field is represented as an unsigned decimal integer. The Hash Algorithm field is represented as an unsigned decimal integer. The Digest is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text. 2.4. ZONEMD Example The following example shows a ZONEMD RR in presentation format: example.com. 86400 IN ZONEMD 2018031500 1 1 ( FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 2.5. Including ZONEMD RRs in a Zone The zone operator chooses an appropriate hash algorithm and scheme, and includes the calculated zone digest in the apex ZONEMD RRset. The zone operator MAY choose any of the defined hash algorithms and schemes, including the private use code points. Wessels, et al. Expires April 18, 2021 [Page 10] Internet-Draft DNS Zone Digest October 2020 The ZONEMD RRSet MAY contain multiple records to support algorithm agility [RFC7696]. [RFC Editor: change that to BCP 201] When multiple ZONEMD RRs are present, each MUST specify a unique Scheme and Hash Algorithm tuple. It is RECOMMENDED that a zone include only one ZONEMD RR, unless the zone operator is in the process of transitioning to a new scheme or hash algorithm. 3. Calculating the Digest The algorithm described in this section is designed for the common case of offline DNSSEC signing. Slight deviations may be permitted or necessary in other situations, such as with unsigned zones or online DNSSEC signing. Implementations that deviate from the described algorithm are advised to ensure that it produces ZONEMD RRs, signatures, and dential-of-existence records that are identical to the ones generated by this procedure. 3.1. Add ZONEMD Placeholder In preparation for calculating the zone digest(s), any existing ZONEMD records (and covering RRSIGs) at the zone apex are first deleted. Prior to calculation of the digest, and prior to signing with DNSSEC, one or more placeholder ZONEMD records are added to the zone apex. This ensures that denial-of-existence (NSEC, NSEC3) records are created correctly if the zone is signed with DNSSEC. If placeholders were not added prior to signing, the later addition of ZONEMD records would also require updating the Type Bit Maps field of any apex NSEC/ NSEC3 RRs, which then invalidates the calculated digest value. When multiple ZONEMD RRs are published in the zone, e.g., during an algorithm rollover, each MUST specify a unique Scheme and Hash Algorithm tuple. It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of the SOA. However, the TTL of the ZONEMD record may be safely ignored during verification in all cases. In the placeholder record, the Serial field is set to the current SOA Serial. The Scheme field is set to the value for the chosen collation scheme. The Hash Algorithm field is set to the value for the chosen hash algorithm. Since apex ZONEMD records are excluded from digest calculation, the value of the Digest field does not matter at this point in the process. Wessels, et al. Expires April 18, 2021 [Page 11] Internet-Draft DNS Zone Digest October 2020 3.2. Optionally Sign the Zone Following addition of placeholder records, the zone may be signed with DNSSEC. When the digest calculation is complete, and the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet MUST be recalculated and updated as well. Therefore, the signer is not required to calculate a signature over the placeholder record at this step in the process, but it is harmless to do so. 3.3. Scheme-Specific Processing Herein, only the SIMPLE collation scheme is defined. Additional schemes may be defined in future updates to this document. 3.3.1. The SIMPLE Scheme For the SIMPLE scheme, the digest is calculated over the zone as a whole. This means that a change to a single RR in the zone requires iterating over all RRs in the zone to recalculate the digest. SIMPLE is a good choice for zones that are small and/or stable, but probably not good for zones that are large and/or dynamic. Calculation of a zone digest requires RRs to be processed in a consistent format and ordering. This specification uses DNSSEC's canonical on-the-wire RR format (without name compression) and ordering as specified in Sections 6.1, 6.2, and 6.3 of [RFC4034] with the additional provision that RRSets having the same owner name MUST be numerically ordered, in ascending order, by their numeric RR TYPE. 3.3.1.1. SIMPLE Scheme Inclusion/Exclusion Rules When iterating over records in the zone, the following inclusion/ exclusion rules apply: o All records in the zone, including glue records, MUST be included, unless excluded by a subsequent rule. o Occluded data ([RFC5936] Section 3.5) MUST be included. o If there are duplicate RRs with equal owner, class, type, and RDATA, only one instance is included ([RFC4034] Section 6.3), and the duplicates MUST be omitted. o The placeholder apex ZONEMD RR(s) MUST NOT be included. o If the zone is signed, DNSSEC RRs MUST be included, except: Wessels, et al. Expires April 18, 2021 [Page 12] Internet-Draft DNS Zone Digest October 2020 o The RRSIG covering the apex ZONEMD RRSet MUST NOT be included because the RRSIG will be updated after all digests have been calculated. 3.3.1.2. SIMPLE Scheme Digest Calculation A zone digest using the SIMPLE scheme is calculated by concatenating all RRs in the zone, in the format and order described in Section 3.3.1 subject to the inclusion/exclusion rules described in Section 3.3.1.1, and then applying the chosen hash algorithm: digest = hash( RR(1) | RR(2) | RR(3) | ... ) where "|" denotes concatenation. 3.4. Update ZONEMD RR The calculated zone digest is inserted into the placeholder ZONEMD RR. Repeat for each digest if multiple digests are to be published. If the zone is signed with DNSSEC, the RRSIG record(s) covering the ZONEMD RRSet MUST then be added or updated. Because the ZONEMD placeholder was added prior to signing, the zone will already have the appropriate denial-of-existence (NSEC, NSEC3) records. Some DNSSEC implementations (especially "online signing") might update the SOA serial number whenever a new signature is made. To preserve the calculated digest, generation of a ZONEMD signature MUST NOT also result in a change to the SOA serial number. The ZONEMD RR and the matching SOA MUST be published at the same time. 4. Verifying Zone Digest The recipient of a zone that has a ZONEMD RR verifies the zone by calculating the digest as follows. If multiple ZONEMD RRs are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Schemes and Hash Algorithms is sufficient to verify the zone. The verifier MAY ignore a ZONEMD RR if its Scheme and Hash Algorithm violates local policy. 1. The verifier MUST first determine whether or not to expect DNSSEC records in the zone. By examining locally configured trust anchors, and, if necessary, querying for and validating DS RRs in the parent zone, the verifier knows whether or not the zone to be verified should include DNSSEC keys and signatures. For zones where signatures are not expected, or if DNSSEC validation is not performed, digest verification continues at step 4 below. Wessels, et al. Expires April 18, 2021 [Page 13] Internet-Draft DNS Zone Digest October 2020 2. For zones where signatures are expected, the existence of the apex ZONEMD record MUST be validated. If the DNSSEC data proves the ZONEMD RRSet does not exist, digest verification cannot occur. If the DNSSEC data proves the ZONEMD does exist, but is not found in the zone, digest verification MUST NOT be considered successful. 3. For zones where signatures are expected, the SOA and ZONEMD RRSets MUST have valid signatures, chaining up to a trust anchor. If DNSSEC validation of the SOA or ZONEMD RRSets fails, digest verification MUST NOT be considered successful. 4. When multiple ZONEMD RRs are present, each MUST specify a unique Scheme and Hash Algorithm tuple. If the ZONEMD RRSet contains more than one RR with the same Scheme and Hash Algorithm, digest verification for those ZONEMD RRs MUST NOT be considered successful. 5. Loop over all apex ZONEMD RRs and perform the following steps: A. The SOA Serial field MUST exactly match the ZONEMD Serial field. If the fields do not match, digest verification MUST NOT be considered successful with this ZONEMD RR. B. The Scheme field MUST be checked. If the verifier does not support the given scheme, verification MUST NOT be considered successful with this ZONEMD RR. C. The Hash Algorithm field MUST be checked. If the verifier does not support the given hash algorithm, verification MUST NOT be considered successful with this ZONEMD RR. D. The Digest field size MUST be checked. If the size of the given Digest field is smaller than 12 octets, or if the size is not equal to the size expected for the corresponding Hash Algorithm, verification MUST NOT be considered successful with this ZONEMD RR. E. The zone digest is computed over the zone data as described in Section 3.3, using the Scheme and Hash Algorithm for the current ZONEMD RR. F. The computed digest is compared to the received digest. If the two digest values match, verification is considered successful. Otherwise, verification MUST NOT be considered successful for this ZONEMD RR. Wessels, et al. Expires April 18, 2021 [Page 14] Internet-Draft DNS Zone Digest October 2020 Each time zone verification is performed, the verifier SHOULD report the status as either successful or unsuccessful. When unsuccessful, the verifier SHOULD report the reason(s) that verification did not succeed. 5. IANA Considerations 5.1. ZONEMD RRtype This document defines a new DNS RR type, ZONEMD, whose value 63 has been allocated by IANA from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry: Type: ZONEMD Value: 63 Meaning: Message Digest Over Zone Data Reference: [this document] 5.2. ZONEMD Scheme IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: Registry Name: ZONEMD Schemes Registration Procedure: Specification Required Reference: [this document] +---------+-------------------------+----------+-----------------+ | Value | Description | Mnemonic | Reference | +---------+-------------------------+----------+-----------------+ | 0 | Reserved | | | | 1 | Simple ZONEMD collation | SIMPLE | [this document] | | 2-239 | Unassigned | | | | 240-254 | Private Use | N/A | [this document] | | 255 | Reserved | | | +---------+-------------------------+----------+-----------------+ Table 1: ZONEMD Scheme Registry Wessels, et al. Expires April 18, 2021 [Page 15] Internet-Draft DNS Zone Digest October 2020 5.3. ZONEMD Hash Algorithm IANA is requested to create a new registry on the "Domain Name System (DNS) Parameters" web page as follows: Registry Name: ZONEMD Hash Algorithms Registration Procedure: Specification Required Reference: [this document] +---------+-------------+----------+-----------------+ | Value | Description | Mnemonic | Reference | +---------+-------------+----------+-----------------+ | 0 | Reserved | | | | 1 | SHA-384 | SHA384 | [this document] | | 2 | SHA-512 | SHA512 | [this document] | | 3-239 | Unassigned | | | | 240-254 | Private Use | N/A | [his document] | | 255 | Reserved | | | +---------+-------------+----------+-----------------+ Table 2: ZONEMD Hash Algorithm Registry 6. Security Considerations 6.1. Using Zone Digest Without DNSSEC Users of ZONEMD with unsigned zones are advised that it provides no real protection against attacks. While zone digests can be used in the absence of DNSSEC, this only provides protection against accidental zone corruption, such as transmission errors and truncation. When used in this manner, it effectively serves only as a checksum. For zones not signed with DNSSEC, an attacker can make any zone modifications appear to be valid by recomputing Digest field of a ZONEMD RR. 6.2. Attacks Against the Zone Digest An attacker, whose goal is to modify zone content before it is used by the victim, may consider a number of different approaches. The attacker might perform a downgrade attack to an unsigned zone. This is why Section 4 talks about determining whether or not to expect DNSSEC signatures for the zone in step 1. The attacker might perform a downgrade attack by removing one or more ZONEMD records. Such a removal is detectable only with DNSSEC Wessels, et al. Expires April 18, 2021 [Page 16] Internet-Draft DNS Zone Digest October 2020 validation and is why Section 4 talks about checking denial-of- existence proofs in step 2 and signature validation in step 3. The attacker might alter the Scheme, Hash Algorithm, or Digest fields of the ZONEMD record. Such modifications are detectable only with DNSSEC validation. As stated in [RFC7696], cryptographic algorithms age and become weaker as cryptanalysis techniques and computing resources improve with time. Implementors and publishers of zone digests should anticipate the need for algorithm agility on long timescales. 6.3. Use of Multiple ZONEMD Hash Algorithms When a zone publishes multiple ZONEMD RRs, the overall security is only as good as the weakest hash algorithm in use. For this reason, Section 2 recommends only publishing multiple ZONEMD RRs when transitioning to a new scheme or hash algorithm. Once the transition is complete, the old scheme or hash algorithm should be removed from the ZONEMD RRSet. 6.4. DNSSEC Timing Considerations As with all DNSSEC signatures, the ability to perform signature validation of a ZONEMD record is limited in time. If the DS record(s) or trust anchors for the zone to be verified are no longer available, the recipient cannot validate the ZONEMD RRSet. This could happen even if the ZONEMD signature is still current (not expired), since the zone's DS record(s) may have been withdrawn following a Key Signing Key (KSK) rollover. For zones where it may be important to validate a ZONEMD RRSet through its entire signature validity period, the zone operator should ensure that KSK rollover timing takes this into consideration. 6.5. Attacks Utilizing ZONEMD Queries Nothing in this specification prevents clients from making, and servers from responding to, ZONEMD queries. Servers SHOULD NOT calculate zone digests dynamically (for each query) as this can be used as a CPU resource exhaustion attack. ZONEMD responses could be used in a distributed denial-of-service amplification attack. The ZONEMD RR is moderately sized, much like the DS RR. A single ZONEMD RR contributes approximately 65 to 95 octets to a DNS response, for digest types defined herein. Other RR types, such as DNSKEY, can result in larger amplification effects. Wessels, et al. Expires April 18, 2021 [Page 17] Internet-Draft DNS Zone Digest October 2020 6.6. Resilience and Fragility ZONEMD is used to detect incomplete or corrupted zone data prior to its use, thereby increasing resilience by not using corrupt data, but also introduces some denial-of-service fragility by making good data in a zone unavailable if some other data is missing or corrupt. Publishers and consumers of zones containing ZONEMD records should be aware of these tradeoffs. While the intention is to secure the zone data, misconfigurations or implementation bugs are generally indistinguishable from intentional tampering, and could lead to service failures when verification is performed automatically. Zone publishers may want to deploy ZONEMD gradually, perhaps by utilizing one of the private use hash algorithm code points listed in Section 5.3. Similarly, recipients may want to initially configure verification failures only as a warning, and later as an error after gaining experience and confidence with the feature. 7. Performance Considerations This section is provided to make zone publishers aware of the performance requirements and implications of including ZONEMD RRs in a zone. 7.1. SIMPLE SHA384 As mentioned previously, the SIMPLE scheme may be impractical for use in zones that are either large or highly dynamic. Zone publishers should carefully consider the use of ZONEMD in such zones, since it might cause consumers of zone data (e.g., secondary name servers) to expend resources on digest calculation. For such use cases, it is recommended that ZONEMD only be used when digest calculation time is significantly less than propagation times and update intervals. The authors' implementation (Appendix B.1) includes an option to record and report CPU usage of its operation. The software was used to generate digests for more than 800 TLD zones available from [CZDS]. The table below summarizes the results for the SIMPLE scheme and SHA384 hash algorithm grouped by zone size. The Rate column is the mean amount of time per RR to calculate the digest, running on commodity hardware in early 2020. Wessels, et al. Expires April 18, 2021 [Page 18] Internet-Draft DNS Zone Digest October 2020 +---------------------+----------------+ | Zone Size (RRs) | Rate (msec/RR) | +---------------------+----------------+ | 10 - 99 | 0.00683 | | 100 - 999 | 0.00551 | | 1000 - 9999 | 0.00505 | | 10000 - 99999 | 0.00602 | | 100000 - 999999 | 0.00845 | | 1000000 - 9999999 | 0.0108 | | 10000000 - 99999999 | 0.0148 | +---------------------+----------------+ For example, based on the above table, it takes approximately 0.13 seconds to calculate a SIMPLE SHA384 digest for a zone with 22,000 RRs, and about 2.5 seconds for a zone with 300,000 RRs. These benchmarks attempt to emulate a worst-case scenario and take into account the time required to canonicalize the zone for processing. Each of the 800+ zones were measured three times, and then averaged, with a different random sorting of the input data prior to each measurement. 8. Privacy Considerations This specification has no impact on user privacy. 9. Acknowledgments The authors wish to thank David Blacka, Scott Hollenbeck, and Rick Wilhelm for providing feedback on early drafts of this document. Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans, Donald Eastlake, Richard Gibson, Olafur Gudmundsson, Bob Harold, Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Mike St. Johns, Burt Kaliski, Shane Kerr, Matt Larson, Barry Leiba, John Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinski, Wouter Wijngaards, Paul Wouters, and other members of the DNSOP working group for their input. 10. Change Log RFC Editor: Please remove this section before publication. This section lists substantial changes to the document as it is being worked on. From -00 to -01: Wessels, et al. Expires April 18, 2021 [Page 19] Internet-Draft DNS Zone Digest October 2020 o Removed requirement to sort by RR CLASS. o Added Kumari and Hardaker as coauthors. o Added Change Log section. o Minor clarifications and grammatical edits. From -01 to -02: o Emphasize desire for data security over channel security. o Expanded motivation into its own subsection. o Removed discussion topic whether or not to include serial in ZONEMD. o Clarified that a zone's NS records always sort before the SOA record. o Clarified that all records in the zone must are digested, except as specified in the exclusion rules. o Added for discussion out-of-zone and occluded records. o Clarified that update of ZONEMD signature must not cause a serial number change. o Added persons to acknowledgments. From -02 to -03: o Added recommendation to set ZONEMD TTL to SOA TTL. o Clarified that digest input uses uncompressed names. o Updated Implementations section. o Changed intended status from Standards Track to Experimental and added Scope of Experiment section. o Updated Motivation, Introduction, and Design Overview sections in response to working group discussion. o Gave ZONEMD digest types their own status, separate from DS digest types. Request IANA to create a registry. o Added Reserved field for future work supporting dynamic updates. Wessels, et al. Expires April 18, 2021 [Page 20] Internet-Draft DNS Zone Digest October 2020 o Be more rigorous about having just ONE ZONEMD record in the zone. o Expanded use cases. From -03 to -04: o Added an appendix with example zones and digests. o Clarified that only apex ZONEMD RRs shall be processed. From -04 to -05: o Made SHA384 the only supported ZONEMD digest type. o Disassociated ZONEMD digest types from DS digest types. o Updates to Introduction based on list feedback. o Changed "zone file" to "zone" everywhere. o Restored text about why ZONEMD has a Serial field. o Clarified ordering of RRSets having same owner to be numerically ascending. o Clarified that all duplicate RRs (not just SOA) must be suppressed in digest calculation. o Clarified that the Reserved field must be set to zero and checked for zero in verification. o Clarified that occluded data must be included. o Clarified procedure for verification, using temporary location for received digest. o Explained why Reserved field is 8-bits. o IANA Considerations section now more specific. o Added complex zone to examples. o From -05 to -06: o RR type code 63 was assigned to ZONEMD by IANA. Wessels, et al. Expires April 18, 2021 [Page 21] Internet-Draft DNS Zone Digest October 2020 From -06 to -07: o Fixed mistakes in ZONEMD examples. o Added private use Digest Type values 240-254. o Clarified that Digest field must not be empty. From -07 to draft-ietf-dnsop-dns-zone-digest-00: o Adopted by dnsop. o Clarified further that non-apex ZONEMD RRs have no meaning. o Changed "provably [un]signed" to "provably [in]secure". o Allow multiple ZONEMD RRs to support algorithm agility/rollovers. o Describe verification when there are multiple ZONEMD RRs. From -00 to -01: o Simplified requirements around verifying multiple digests. Any one match is sufficient. o Updated implementation notes. o Both implementations produce expected results on examples given in this document. From -01 to -02: o Changed the name of the Reserved field to Parameter. o Changed the name of Digest Type 1 from SHA384 to SHA384-STABLE. o The meaning of the Parameter field now depends on Digest Type. o No longer require Parameter field to be zero in verification. o Updated a rule from earlier versions that said multiple ZONEMD RRs were not allowed. From -02 to -03: o Changed the name of Digest Type 1 from SHA384-STABLE to SHA384-SIMPLE. Wessels, et al. Expires April 18, 2021 [Page 22] Internet-Draft DNS Zone Digest October 2020 o Changed document status from Experimental to Standards Track. o Removed Scope of Experimentation section. From -03 to -04: o Addressing WGLC feedback. o Changed from "Digest Type + Paramter" to "Scheme + Hash Algorithm". This should make it more obvious how ZONEMD can be expanded in the future with new schemes and hash algorithms, while sacrificing some of the flexibility that the Parameter was intended to provide. o Note: old RDATA fields: Serial, Digest Type, Parameter, Digest. o Note: new RDATA fields: Serial, Scheme, Hash Algorithm, Digest. o Add new IANA requirement for a Scheme registry. o Rearranged some sections and separated scheme-specific aspects from general aspects of digest calculation. o When discussing multiple ZONEMD RRs, allow for Scheme, as well as Hash Algorithm, transition. o Added Performance Considerations section with some benchmarks. o Further clarifications about non-apex ZONEMD RRs. o Clarified inclusion rule for duplicate RRs. o Removed or lowercased some inappropriately used RFC 2119 key words. o Clarified that all ZONEMD RRs, even for unsupported hash algorithms, must be zeroized during digest calculation. o Added Resilience and Fragility to security considerations. o Updated examples since changes in this version result in different hash values. From -04 to -05: o Clarifications about non-apex and multiple ZONEMD RRs. o Clarifications about benchmark results. Wessels, et al. Expires April 18, 2021 [Page 23] Internet-Draft DNS Zone Digest October 2020 o Don't compute ZONEMD on-the-fly. o Specification Required for updates to ZONEMD protocol registries. o Other rewording based on WGLC feedback. o Updated RFC numbers for some references. o Use documentation IP addresses instead of loopback. o Updated examples in the appendix. From -05 to -06: o Per WG suggestion, no longer include any apex ZONEMD record in digest calculation. o Updated examples in the appendix. o Clarified verification procedure by describing a loop over all ZONEMD RRs. From -06 to -07: o Added NIC Chile Labs implementation. From -07 to -08: o Update an author's affiliation. o Clarified why placeholder RRs are still important (for NSEC/ NSEC3). o Moved subsection ("Order of RRSets Having the Same Owner Name") with single sentence paragraph up into parent section. From -08 to -09: o Moved format, ordering, inclusion/exclusion into a sub section specific to the SIMPLE scheme. o Further clarified rules about multiple ZONEMD RRs (AD comments). o Reworded rules about processing of duplicate zone RRs (AD comments). o Removed sentence about optional zeroing of digest prior to calculation (AD comments). Wessels, et al. Expires April 18, 2021 [Page 24] Internet-Draft DNS Zone Digest October 2020 o Other minor changes (AD comments). From -09 to -10: o Add clarification and reference to on-disk modification / corruption of zone files. o Added concerns that timing of KSK rollovers could affect validation of ZONEMD record. o Addressed SECDIR review and accepted most proposed edits. o From SECDIR review, require minimum digest length of 12 octets. o From SECDIR review, add SHA512 has hash algorithm 2. o From SECDIR review, say that ZONEMD RRs MAY be ignored by local policy. o Moved Implementation Status to an appendix with the intention to retain it in RFC. o In registry tables, changed Status column to Implementation Requirement. From -10 to -11: o Fixed people's names in the acknowledgments section (blush) o Say "has not been modified between origination and retrieval." o Say that ZONEMD TTL doesn't matter during verification. o Further clarification that the SHA-384 and SHA-512 hashes are not truncated. Future algs might be truncated, but never below 96 bits. From -11 to -12: o SECDIR review: make "recommended" all caps. o SECDIR review: tweak explanation of why ZONEMD RR has copy of SOA serial. o SECDIR review: be even more clear about apex ZONEMD RRs vs non- apex. Wessels, et al. Expires April 18, 2021 [Page 25] Internet-Draft DNS Zone Digest October 2020 o SECDIR review: Forgot to delete sentence about IANA policy for adding new hash algorithms. o SECDIR review: Spell out Key Signing Key first time. o SECDIR review: say "private use hash algorithm code points." o SECDIR review: Update estimates of ZONEMD RR size. From -12 to -13: o Added reference to draft-ietf-dprive-xfr-over-tls. o Dropped Implementation Requirement from registry tables. o Added Use of Multiple ZONEMD Hash Algorithms to Security Considerations. o Added Using Zone Digest Without DNSSEC to Security Considerations. o Added notes about the need for algorithm agility due to crypto algorithm aging. o Further clarified that only with DNSSEC can ZONEMD guarantee integrity and authenticity. o For unsigned zones, ZONEMD serves only as a checksum. o Calculation algorithm is designed for common case of offline signing. Deviations may be allowed as long as the end result is the same. o Numerous small edits and clarifications from IESG reviewer comments. From -13 to -14: o A few more edits and clarifications from IESG reviewer comments. o Moved paragraph about multiple digests to new section titled Including ZONEMD RRs in a Zone. o MUST be implemented -> MUST be supported by implementations. o Consolidated SHOULD requirements about error reporting to single place at the conclusion of verification. Wessels, et al. Expires April 18, 2021 [Page 26] Internet-Draft DNS Zone Digest October 2020 o Rephrased "provably insecure" etc as using DNSSEC validation to know whether or not the zone is expected to have keys and signatures. 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [CZDS] Internet Corporation for Assigned Names and Numbers, "Centralized Zone Data Service", October 2018, . [disk-full-failure] DENIC, "Background of the Partial Failure of the Name Service for .de Domains", May 2010, . Wessels, et al. Expires April 18, 2021 [Page 27] Internet-Draft DNS Zone Digest October 2020 [DnsTools] NIC Chile Labs, "DNS tools for zone signature (file, pkcs11-hsm) and validation, and zone digest (ZONEMD)", April 2020, . [I-D.ietf-dprive-xfr-over-tls] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. Mankin, "DNS Zone Transfer-over-TLS", draft-ietf-dprive- xfr-over-tls-02 (work in progress), July 2020. [InterNIC] ICANN, "InterNIC FTP site", May 2018, . [ldns-zone-digest] Verisign, "Implementation of Message Digests for DNS Zones using the ldns library", July 2018, . [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, . [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, DOI 10.17487/RFC2065, January 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, . [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, . [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 2000, . [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, DOI 10.17487/RFC3258, April 2002, . Wessels, et al. Expires April 18, 2021 [Page 28] Internet-Draft DNS Zone Digest October 2020 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, . [RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, . Wessels, et al. Expires April 18, 2021 [Page 29] Internet-Draft DNS Zone Digest October 2020 [RootServers] Root Server Operators, "Root Server Technical Operations", July 2018, . [RPZ] Wikipedia, "Response policy zone", May 2020, . [ZoneDigestHackathon] Kerr, S., "Prototype implementation of ZONEMD for the IETF 102 hackathon in Python", July 2018, . Appendix A. Example Zones With Digests This appendix contains example zones with accurate ZONEMD records. These can be used to verify an implementation of the zone digest protocol. A.1. Simple EXAMPLE Zone Here, the EXAMPLE zone contains an SOA record, NS and glue records, and a ZONEMD record. example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) 86400 IN NS ns1 86400 IN NS ns2 86400 IN ZONEMD 2018031900 1 1 ( c68090d90a7aed71 6bc459f9340e3d7c 1370d4d24b7e2fc3 a1ddc0b9a87153b9 a9713b3c9ae5cc27 777f98b8e730044c ) ns1 3600 IN A 203.0.113.63 ns2 3600 IN AAAA 2001:db8::63 A.2. Complex EXAMPLE Zone Here, the EXAMPLE zone contains duplicate RRs, and an occluded RR, and one out-of-zone RR. Wessels, et al. Expires April 18, 2021 [Page 30] Internet-Draft DNS Zone Digest October 2020 example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) 86400 IN NS ns1 86400 IN NS ns2 86400 IN ZONEMD 2018031900 1 1 ( 31cefb03814f5062 ad12fa951ba0ef5f 8da6ae354a415767 246f7dc932ceb1e7 42a2108f529db6a3 3a11c01493de358d ) ns1 3600 IN A 203.0.113.63 ns2 3600 IN AAAA 2001:db8::63 occluded.sub 7200 IN TXT "I'm occluded but must be digested" sub 7200 IN NS ns1 duplicate 300 IN TXT "I must be digested just once" duplicate 300 IN TXT "I must be digested just once" foo.test. 555 IN TXT "out-of-zone data must be excluded" non-apex 900 IN ZONEMD 2018031900 1 1 ( 616c6c6f77656420 6275742069676e6f 7265642e20616c6c 6f77656420627574 2069676e6f726564 2e20616c6c6f7765 ) A.3. EXAMPLE Zone with multiple digests Here, the EXAMPLE zone contains multiple ZONEMD records. It has both SHA384 and SHA512 digests using the SIMPLE scheme. It also includes ZONEMD records with Scheme and Hash Algorithm values in the private range (240-254). These additional private-range digests are not verifiable. Wessels, et al. Expires April 18, 2021 [Page 31] Internet-Draft DNS Zone Digest October 2020 example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) example. 86400 IN NS ns1.example. example. 86400 IN NS ns2.example. example. 86400 IN ZONEMD 2018031900 1 1 ( 62e6cf51b02e54b9 b5f967d547ce4313 6792901f9f88e637 493daaf401c92c27 9dd10f0edb1c56f8 080211f8480ee306 ) example. 86400 IN ZONEMD 2018031900 1 2 ( 08cfa1115c7b948c 4163a901270395ea 226a930cd2cbcf2f a9a5e6eb85f37c8a 4e114d884e66f176 eab121cb02db7d65 2e0cc4827e7a3204 f166b47e5613fd27 ) example. 86400 IN ZONEMD 2018031900 1 240 ( e2d523f654b9422a 96c5a8f44607bbee ) example. 86400 IN ZONEMD 2018031900 241 1 ( e1846540e33a9e41 89792d18d5d131f6 05fc283e ) ns1.example. 3600 IN A 203.0.113.63 ns2.example. 86400 IN TXT "This example has multiple digests" ns2.example. 3600 IN AAAA 2001:db8::63 A.4. The URI.ARPA Zone The URI.ARPA zone retrieved 2018-10-21. Note this sample zone has (expired) signatures, but no signature for the ZONEMD RR. ; <<>> DiG 9.9.4 <<>> @lax.xfr.dns.icann.org uri.arpa axfr ; (2 servers found) ;; global options: +cmd uri.arpa. 3600 IN SOA sns.dns.icann.org. ( noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) uri.arpa. 3600 IN RRSIG NSEC 8 2 3600 ( 20181028142623 20181007205525 47155 uri.arpa. eEC4w/oXLR1Epwgv4MBiDtSBsXhqrJVvJWUpbX8XpetAvD35bxwNCUTi /pAJVUXefegWeiriD2rkTgCBCMmn7YQIm3gdR+HjY/+o3BXNQnz97f+e HAE9EDDzoNVfL1PyV/2fde9tDeUuAGVVwmD399NGq9jWYMRpyri2kysr q/g= ) uri.arpa. 86400 IN RRSIG NS 8 2 86400 ( 20181028172020 20181007175821 47155 uri.arpa. Wessels, et al. Expires April 18, 2021 [Page 32] Internet-Draft DNS Zone Digest October 2020 ATyV2A2A8ZoggC+68u4GuP5MOUuR+2rr3eWOkEU55zAHld/7FiBxl4ln 4byJYy7NudUwlMOEXajqFZE7DVl8PpcvrP3HeeGaVzKqaWj+aus0jbKF Bsvs2b1qDZemBfkz/IfAhUTJKnto0vSUicJKfItu0GjyYNJCz2CqEuGD Wxc= ) uri.arpa. 600 IN RRSIG MX 8 2 600 ( 20181028170556 20181007175821 47155 uri.arpa. e7/r3KXDohX1lyVavetFFObp8fB8aXT76HnN9KCQDxSnSghNM83UQV0t lTtD8JVeN1mCvcNFZpagwIgB7XhTtm6Beur/m5ES+4uSnVeS6Q66HBZK A3mR95IpevuVIZvvJ+GcCAQpBo6KRODYvJ/c/ZG6sfYWkZ7qg/Em5/+3 4UI= ) uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 ( 20181028152832 20181007175821 15796 uri.arpa. nzpbnh0OqsgBBP8St28pLvPEQ3wZAUdEBuUwil+rtjjWlYYiqjPxZ286 XF4Rq1usfV5x71jZz5IqswOaQgia91ylodFpLuXD6FTGs2nXGhNKkg1V chHgtwj70mXU72GefVgo8TxrFYzxuEFP5ZTP92t97FVWVVyyFd86sbbR 6DZj3uA2wEvqBVLECgJLrMQ9Yy7MueJl3UA4h4E6zO2JY9Yp0W9woq0B dqkkwYTwzogyYffPmGAJG91RJ2h6cHtFjEZe2MnaY2glqniZ0WT9vXXd uFPm0KD9U77Ac+ZtctAF9tsZwSdAoL365E2L1usZbA+K0BnPPqGFJRJk 5R0A1w== ) uri.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 ( 20181028152832 20181007175821 55480 uri.arpa. lWtQV/5szQjkXmbcD47/+rOW8kJPksRFHlzxxmzt906+DBYyfrH6uq5X nHvrUlQO6M12uhqDeL+bDFVgqSpNy+42/OaZvaK3J8EzPZVBHPJykKMV 63T83aAiJrAyHzOaEdmzLCpalqcEE2ImzlLHSafManRfJL8Yuv+JDZFj 2WDWfEcUuwkmIZWX11zxp+DxwzyUlRl7x4+ok5iKZWIg5UnBAf6B8T75 WnXzlhCw3F2pXI0a5LYg71L3Tp/xhjN6Yy9jGlIRf5BjB59X2zra3a2R PkI09SSnuEwHyF1mDaV5BmQrLGRnCjvwXA7ho2m+vv4SP5dUdXf+GTeA 1HeBfw== ) uri.arpa. 3600 IN RRSIG SOA 8 2 3600 ( 20181029114753 20181008222815 47155 uri.arpa. qn8yBNoHDjGdT79U2Wu9IIahoS0YPOgYP8lG+qwPcrZ1BwGiHywuoUa2 Mx6BWZlg+HDyaxj2iOmox+IIqoUHhXUbO7IUkJFlgrOKCgAR2twDHrXu 9BUQHy9SoV16wYm3kBTEPyxW5FFm8vcdnKAF7sxSY8BbaYNpRIEjDx4A JUc= ) uri.arpa. 3600 IN NSEC ftp.uri.arpa. NS SOA ( MX RRSIG NSEC DNSKEY ) uri.arpa. 86400 IN NS a.iana-servers.net. uri.arpa. 86400 IN NS b.iana-servers.net. uri.arpa. 86400 IN NS c.iana-servers.net. uri.arpa. 86400 IN NS ns2.lacnic.net. uri.arpa. 86400 IN NS sec3.apnic.net. uri.arpa. 600 IN MX 10 pechora.icann.org. uri.arpa. 3600 IN DNSKEY 256 3 8 ( AwEAAcBi7tSart2J599zbYWspMNGN70IBWb4ziqyQYH9MTB/VCz6WyUK uXunwiJJbbQ3bcLqTLWEw134B6cTMHrZpjTAb5WAwg4XcWUu8mdcPTiL Bl6qVRlRD0WiFCTzuYUfkwsh1Rbr7rvrxSQhF5rh71zSpwV5jjjp65Wx SdJjlH0B ) uri.arpa. 3600 IN DNSKEY 257 3 8 ( AwEAAbNVv6ulgRdO31MtAehz7j3ALRjwZglWesnzvllQl/+hBRZr9QoY cO2I+DkO4Q1NKxox4DUIxj8SxPO3GwDuOFR9q2/CFi2O0mZjafbdYtWc 3zSdBbi3q0cwCIx7GuG9eqlL+pg7mdk9dgdNZfHwB0LnqTD8ebLPsrO/ Wessels, et al. Expires April 18, 2021 [Page 33] Internet-Draft DNS Zone Digest October 2020 Id7kBaiqYOfMlZnh2fp+2h6OOJZHtY0DK1UlssyB5PKsE0tVzo5s6zo9 iXKe5u+8WTMaGDY49vG80JPAKE7ezMiH/NZcUMiE0PRZ8D3foq2dYuS5 ym+vA83Z7v8A+Rwh4UGnjxKB8zmr803V0ASAmHz/gwH5Vb0nH+LObwFt l3wpbp+Wpm8= ) uri.arpa. 3600 IN DNSKEY 257 3 8 ( AwEAAbwnFTakCvaUKsXji4mgmxZUJi1IygbnGahbkmFEa0L16J+TchKR wcgzVfsxUGa2MmeA4hgkAooC3uy+tTmoMsgy8uq/JAj24DjiHzd46LfD FK/qMidVqFpYSHeq2Vv5ojkuIsx4oe4KsafGWYNOczKZgH5loGjN2aJG mrIm++XCphOskgCsQYl65MIzuXffzJyxlAuts+ecAIiVeqRaqQfr8LRU 7wIsLxinXirprtQrbor+EtvlHp9qXE6ARTZDzf4jvsNpKvLFZtmxzFf3 e/UJz5eHjpwDSiZL7xE8aE1o1nGfPtJx9ZnB3bapltaJ5wY+5XOCKgY0 xmJVvNQlwdE= ) ftp.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 20181028080856 20181007175821 47155 uri.arpa. HClGAqPxzkYkAT7Q/QNtQeB6YrkP6EPOef+9Qo5/2zngwAewXEAQiyF9 jD1USJiroM11QqBS3v3aIdW/LXORs4Ez3hLcKNO1cKHsOuWAqzmE+BPP Arfh8N95jqh/q6vpaB9UtMkQ53tM2fYU1GszOLN0knxbHgDHAh2axMGH lqM= ) ftp.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( 20181028103644 20181007205525 47155 uri.arpa. WoLi+vZzkxaoLr2IGZnwkRvcDf6KxiWQd1WZP/U+AWnV+7MiqsWPZaf0 9toRErerGoFOiOASNxZjBGJrRgjmavOM9U+LZSconP9zrNFd4dIu6kp5 YxlQJ0uHOvx1ZHFCj6lAt1ACUIw04ZhMydTmi27c8MzEOMepvn7iH7r7 k7k= ) ftp.uri.arpa. 3600 IN NSEC http.uri.arpa. NAPTR ( RRSIG NSEC ) ftp.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( "!^ftp://([^:/?#]*).*$!\\1!i" . ) http.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 20181029010647 20181007175821 47155 uri.arpa. U03NntQ73LHWpfLmUK8nMsqkwVsOGW2KdsyuHYAjqQSZvKbtmbv7HBmE H1+Ii3Z+wtfdMZBy5aC/6sHdx69BfZJs16xumycMlAy6325DKTQbIMN+ ift9GrKBC7cgCd2msF/uzSrYxxg4MJQzBPvlkwXnY3b7eJSlIXisBIn7 3b8= ) http.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( 20181029011815 20181007205525 47155 uri.arpa. T7mRrdag+WSmG+n22mtBSQ/0Y3v+rdDnfQV90LN5Fq32N5K2iYFajF7F Tp56oOznytfcL4fHrqOE0wRc9NWOCCUec9C7Wa1gJQcllEvgoAM+L6f0 RsEjWq6+9jvlLKMXQv0xQuMX17338uoD/xiAFQSnDbiQKxwWMqVAimv5 7Zs= ) http.uri.arpa. 3600 IN NSEC mailto.uri.arpa. NAPTR ( RRSIG NSEC ) http.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( "!^http://([^:/?#]*).*$!\\1!i" . ) mailto.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 20181028110727 20181007175821 47155 uri.arpa. GvxzVL85rEukwGqtuLxek9ipwjBMfTOFIEyJ7afC8HxVMs6mfFa/nEM/ IdFvvFg+lcYoJSQYuSAVYFl3xPbgrxVSLK125QutCFMdC/YjuZEnq5cl fQciMRD7R3+znZfm8d8u/snLV9w4D+lTBZrJJUBe1Efc8vum5vvV7819 ZoY= ) mailto.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( 20181028141825 20181007205525 47155 uri.arpa. MaADUgc3fc5v++M0YmqjGk3jBdfIA5RuP62hUSlPsFZO4k37erjIGCfF Wessels, et al. Expires April 18, 2021 [Page 34] Internet-Draft DNS Zone Digest October 2020 j+g84yc+QgbSde0PQHszl9fE/+SU5ZXiS9YdcbzSZxp2erFpZOTchrpg 916T4vx6i59scodjb0l6bDyZ+mtIPrc1w6b4hUyOUTsDQoAJYxdfEuMg Vy4= ) mailto.uri.arpa. 3600 IN NSEC urn.uri.arpa. NAPTR ( RRSIG NSEC ) mailto.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( "!^mailto:(.*)@(.*)$!\\2!i" . ) urn.uri.arpa. 3600 IN RRSIG NSEC 8 3 3600 ( 20181028123243 20181007175821 47155 uri.arpa. Hgsw4Deops1O8uWyELGe6hpR/OEqCnTHvahlwiQkHhO5CSEQrbhmFAWe UOkmGAdTEYrSz+skLRQuITRMwzyFf4oUkZihGyhZyzHbcxWfuDc/Pd/9 DSl56gdeBwy1evn5wBTms8yWQVkNtphbJH395gRqZuaJs3LD/qTyJ5Dp LvA= ) urn.uri.arpa. 604800 IN RRSIG NAPTR 8 3 604800 ( 20181029071816 20181007205525 47155 uri.arpa. ALIZD0vBqAQQt40GQ0Efaj8OCyE9xSRJRdyvyn/H/wZVXFRFKrQYrLAS D/K7q6CMTOxTRCu2J8yes63WJiaJEdnh+dscXzZkmOg4n5PsgZbkvUSW BiGtxvz5jNncM0xVbkjbtByrvJQAO1cU1mnlDKe1FmVB1uLpVdA9Ib4J hMU= ) urn.uri.arpa. 3600 IN NSEC uri.arpa. NAPTR RRSIG ( NSEC ) urn.uri.arpa. 604800 IN NAPTR 0 0 "" "" ( "/urn:([^:]+)/\\1/i" . ) uri.arpa. 3600 IN SOA sns.dns.icann.org. ( noc.dns.icann.org. 2018100702 10800 3600 1209600 3600 ) ;; Query time: 66 msec ;; SERVER: 192.0.32.132#53(192.0.32.132) ;; WHEN: Sun Oct 21 20:39:28 UTC 2018 ;; XFR size: 34 records (messages 1, bytes 3941) uri.arpa. 3600 IN ZONEMD 2018100702 1 1 ( 1291b78ddf7669b1a39d014d87626b709b55774c5d7d58fa dc556439889a10eaf6f11d615900a4f996bd46279514e473 ) A.5. The ROOT-SERVERS.NET Zone The ROOT-SERVERS.NET zone retrieved 2018-10-21. Wessels, et al. Expires April 18, 2021 [Page 35] Internet-Draft DNS Zone Digest October 2020 root-servers.net. 3600000 IN SOA a.root-servers.net. ( nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) root-servers.net. 3600000 IN NS a.root-servers.net. root-servers.net. 3600000 IN NS b.root-servers.net. root-servers.net. 3600000 IN NS c.root-servers.net. root-servers.net. 3600000 IN NS d.root-servers.net. root-servers.net. 3600000 IN NS e.root-servers.net. root-servers.net. 3600000 IN NS f.root-servers.net. root-servers.net. 3600000 IN NS g.root-servers.net. root-servers.net. 3600000 IN NS h.root-servers.net. root-servers.net. 3600000 IN NS i.root-servers.net. root-servers.net. 3600000 IN NS j.root-servers.net. root-servers.net. 3600000 IN NS k.root-servers.net. root-servers.net. 3600000 IN NS l.root-servers.net. root-servers.net. 3600000 IN NS m.root-servers.net. a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30 a.root-servers.net. 3600000 IN A 198.41.0.4 b.root-servers.net. 3600000 IN MX 20 mail.isi.edu. b.root-servers.net. 3600000 IN AAAA 2001:500:200::b b.root-servers.net. 3600000 IN A 199.9.14.201 c.root-servers.net. 3600000 IN AAAA 2001:500:2::c c.root-servers.net. 3600000 IN A 192.33.4.12 d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d d.root-servers.net. 3600000 IN A 199.7.91.13 e.root-servers.net. 3600000 IN AAAA 2001:500:a8::e e.root-servers.net. 3600000 IN A 192.203.230.10 f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f f.root-servers.net. 3600000 IN A 192.5.5.241 g.root-servers.net. 3600000 IN AAAA 2001:500:12::d0d g.root-servers.net. 3600000 IN A 192.112.36.4 h.root-servers.net. 3600000 IN AAAA 2001:500:1::53 h.root-servers.net. 3600000 IN A 198.97.190.53 i.root-servers.net. 3600000 IN MX 10 mx.i.root-servers.org. i.root-servers.net. 3600000 IN AAAA 2001:7fe::53 i.root-servers.net. 3600000 IN A 192.36.148.17 j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30 j.root-servers.net. 3600000 IN A 192.58.128.30 k.root-servers.net. 3600000 IN AAAA 2001:7fd::1 k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN AAAA 2001:500:9f::42 l.root-servers.net. 3600000 IN A 199.7.83.42 m.root-servers.net. 3600000 IN AAAA 2001:dc3::35 m.root-servers.net. 3600000 IN A 202.12.27.33 root-servers.net. 3600000 IN SOA a.root-servers.net. ( nstld.verisign-grs.com. 2018091100 14400 7200 1209600 3600000 ) root-servers.net. 3600000 IN ZONEMD 2018091100 1 1 ( f1ca0ccd91bd5573d9f431c00ee0101b2545c97602be0a97 8a3b11dbfc1c776d5b3e86ae3d973d6b5349ba7f04340f79 ) Wessels, et al. Expires April 18, 2021 [Page 36] Internet-Draft DNS Zone Digest October 2020 Appendix B. Implementation Status RFC Editor: Please retain this section upon publication. This section records the status of known implementations of the protocol defined by this specification at the time of publication, and is inspired by the concepts described in RFC7942. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. B.1. Authors' Implementation The authors have an open source implementation in C, using the ldns library [ldns-zone-digest]. This implementation is able to perform the following functions: o Read an input zone and output a zone with the ZONEMD placeholder. o Compute zone digest over signed zone and update the ZONEMD record. o Re-compute DNSSEC signature over the ZONEMD record. o Verify the zone digest from an input zone. This implementation does not: o Perform DNSSEC validation of the ZONEMD record during verification. B.2. Shane Kerr's Implementation Shane Kerr wrote an implementation of this specification during the IETF 102 hackathon [ZoneDigestHackathon]. This implementation is in Python and is able to perform the following functions: o Read an input zone and output a zone with ZONEMD record. o Verify the zone digest from an input zone. o Output the ZONEMD record in its defined presentation format. This implementation does not: Wessels, et al. Expires April 18, 2021 [Page 37] Internet-Draft DNS Zone Digest October 2020 o Re-compute DNSSEC signature over the ZONEMD record. o Perform DNSSEC validation of the ZONEMD record. B.3. NIC Chile Labs Implementation NIC Chile Labs wrote an implementation of this specification as part of "dns-tools" suite [DnsTools], which besides digesting, can also sign and verify zones. This implementation is in Go and is able to perform the following functions: o Compute zone digest over signed zone and update the ZONEMD record. o Verify the zone digest from an input zone. o Perform DNSSEC validation of the ZONEMD record during verification. o Re-compute DNSSEC signature over the ZONEMD record. Authors' Addresses Duane Wessels Verisign 12061 Bluemont Way Reston, VA 20190 Phone: +1 703 948-3200 Email: dwessels@verisign.com URI: https://verisign.com Piet Barber Verisign 12061 Bluemont Way Reston, VA 20190 Phone: +1 703 948-3200 Email: pbarber@verisign.com URI: https://verisign.com Matt Weinberg Amazon Email: matweinb@amazon.com URI: https://amazon.com Wessels, et al. Expires April 18, 2021 [Page 38] Internet-Draft DNS Zone Digest October 2020 Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 Email: warren@kumari.net Wes Hardaker USC/ISI P.O. Box 382 Davis, CA 95617 Email: ietf@hardakers.net Wessels, et al. Expires April 18, 2021 [Page 39] ./draft-ietf-babel-applicability-10.txt0000644000764400076440000005760613526053707017270 0ustar iustyiusty Network Working Group J. Chroboczek Internet-Draft IRIF, University of Paris-Diderot Intended status: Informational August 17, 2019 Expires: February 18, 2020 Applicability of the Babel routing protocol draft-ietf-babel-applicability-10 Abstract Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 18, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Chroboczek Expires February 18, 2020 [Page 1] Internet-Draft Babel Protocol Applicability August 2019 Table of Contents 1. Introduction and background . . . . . . . . . . . . . . . . . 2 1.1. Technical overview of the Babel protocol . . . . . . . . 2 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 2.1. Simplicity and implementability . . . . . . . . . . . . . 3 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 3.1. Heterogeneous networks . . . . . . . . . . . . . . . . . 6 3.2. Large scale overlay networks . . . . . . . . . . . . . . 7 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informational References . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction and background Babel [RFC6126bis] is a routing protocol based on the familiar distance-vector algorithm (sometimes known as distributed Bellman- Ford) augmented with mechanisms for loop avoidance (there is no "counting to infinity") and starvation avoidance. This document describes a number of niches where Babel is useful and that are arguably not adequately served by more mature protocols such as OSPF [RFC5340] and IS-IS [RFC1195]. 1.1. Technical overview of the Babel protocol At its core, Babel is a distance-vector protocol based on the distributed Bellman-Ford algorithm, similar in principle to RIP [RFC2453], but with two important extensions: provisions for sensing of neighbour reachability, bidirectional reachability and link quality, and support for multiple address families (e.g., IPv6 and IPv4) in a single protocol instance. Algorithms of this class are simple to understand and simple to implement, but unfortunately they do not work very well -- they suffer from "counting to infinity", a case of pathologically slow convergence in some topologies after a link failure. Babel uses a mechanism pioneered by EIGRP [DUAL] [RFC7868], known as "feasibility", which avoids routing loops and therefore makes counting to infinity impossible. Chroboczek Expires February 18, 2020 [Page 2] Internet-Draft Babel Protocol Applicability August 2019 Feasibility is a conservative mechanism, one that not only avoids all looping routes but also rejects some loop-free routes. Thus, it can lead to a situation known as "starvation", where a router rejects all routes to a given destination, even those that are loop-free. In order to recover from starvation, Babel uses a mechanism pioneered by the Destination-Sequenced Distance-Vector Routing Protocol (DSDV) [DSDV] and known as "sequenced routes". In Babel, this mechanism is generalised to deal with prefixes of arbitrary length and routes announced at multiple points in a single routing domain (DSDV was a pure mesh protocol, and only carried host routes). In DSDV, the sequenced routes algorithm is slow to react to a starvation episode. In Babel, starvation recovery is accelerated by using explicit requests (known as "seqno requests" in the protocol) that signal a starvation episode and cause a new sequenced route to be propagated in a timely manner. In the absence of packet loss, this mechanism is provably complete and clears the starvation in time proportional to the diameter of the network, at the cost of some additional signalling traffic. 2. Properties of the Babel protocol This section describes the properties of the Babel protocol as well as its known limitations. 2.1. Simplicity and implementability Babel is a conceptually simple protocol. It consists of a familiar algorithm (distributed Bellman-Ford) augmented with three simple and well-defined mechanisms (feasibility, sequenced routes and explicit requests). Given a sufficiently friendly audience, the principles behind Babel can be explained in 15 minutes, and a full description of the protocol can be done in 52 minutes (one microcentury). An important consequence is that Babel is easy to implement. At the time of writing, there exist four independent, interoperable implementations, including one that was reportedly written and debugged in just two nights. 2.2. Robustness The fairly strong properties of the Babel protocol (convergence, loop avoidance, starvation avoidance) rely on some reasonably weak properties of the network and the metric being used. The most significant are: o causality: the "happens-before" relation is acyclic (intuitively, a control message is not received before it has been sent); Chroboczek Expires February 18, 2020 [Page 3] Internet-Draft Babel Protocol Applicability August 2019 o strict monotonicity of the metric: for any metric M and link cost C, M < C + M (intuitively, this implies that cycles have a strictly positive metric); o left-distributivity of the metric: for any metrics M and M' and cost C, if M <= M', then C + M <= C + M' (intuitively, this implies that a good choice made by a neighbour B of a node A is also a good choice for A). See [METAROUTING] for more information about these properties and their consequences. In particular, Babel does not assume a reliable transport, it does not assume ordered delivery, it does not assume that communication is transitive, and it does not require that the metric be discrete (continuous metrics are possible, reflecting for example packet loss rates). This is in contrast to link-state routing protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable flooding algorithm and make stronger requirements on the underlying network and metric. These weak requirements make Babel a robust protocol: o robust with respect to unusual networks: an unusual network (non- transitive links, unstable link costs, etc.) is likely not to violate the assumptions of the protocol; o robust with respect to novel metrics: an unusual metric (continuous, constantly fluctuating, etc.) is likely not to violate the assumptions of the protocol. Section 3 below gives examples of successful deployments of Babel that illustrate these properties. These robustness properties have important consequences for the applicability of the protocol: Babel works (more or less efficiently) in a range of circumstances where traditional routing protocols don't work well (or at all). 2.3. Extensibility Babel's packet format has a number of features that make the protocol extensible (see Appendix C of [RFC6126bis]), and a number of extensions have been designed to make Babel work better in situations that were not envisioned when the protocol was initially designed. The ease of extensibility is not an accident, but a consequence of the design of the protocol: it is reasonably easy to check whether a given extension violates the assumptions on which Babel relies. Chroboczek Expires February 18, 2020 [Page 4] Internet-Draft Babel Protocol Applicability August 2019 All of the extensions designed to date interoperate with the base protocol and with each other. This, again, is a consequence of the protocol design: in order to check that two extensions to the Babel protocol are interoperable, it is enough to verify that the interaction of the two does not violate the base protocol's assumptions. Notable extensions deployed to date include: o source-specific routing (SADR) [BABEL-SS] allows forwarding to take a packet's source address into account, thus enabling a cheap form of multihoming [SS-ROUTING]; o RTT-based routing [BABEL-RTT] minimises link delay, which is useful in overlay network (where both hop count and packet loss are poor metrics). Some other extensions have been designed, but have not seen deployment in production (and their usefulness is yet to be demonstrated): o frequency-aware routing [BABEL-Z] aims to minimise radio interference in wireless networks; o ToS-aware routing [BABEL-TOS] allows routing to take a packet's ToS marking into account for selected routes without incurring the full cost of a multi-topology routing protocol. 2.4. Limitations Babel has some undesirable properties that make it suboptimal or even unusable in some deployments. 2.4.1. Periodic updates The main mechanisms used by Babel to reconverge after a topology change are reactive: triggered updates, triggered retractions and explicit requests. However, Babel relies on periodic updates to clear pathologies after a mobility event or in the presence of heavy packet loss. The use of periodic updates makes Babel unsuitable in at least two kinds of environments: o large, stable networks: since Babel sends periodic updates even in the absence of topology changes, in well-managed, large, stable networks the amount of control traffic will be reduced by using a protocol that uses a reliable transport (such as OSPF, IS-IS or EIGRP); Chroboczek Expires February 18, 2020 [Page 5] Internet-Draft Babel Protocol Applicability August 2019 o low-power networks: the periodic updates use up battery power even when there are no topology changes and no user traffic, which makes Babel wasteful in low-power networks. 2.4.2. Full routing table While there exist techniques that allow a Babel speaker to function with a partial routing table (e.g., by learning just a default route or, more generally, performing route aggregation), Babel is designed around the assumption that every router has a full routing table. In networks where some nodes are too constrained to hold a full routing table, it might be preferable to use a protocol that was designed from the outset to work with a partial routing table (such as AODV [RFC3561], RPL [RFC6550] or LOADng [LOADng]). 2.4.3. Slow aggregation Babel's loop-avoidance mechanism relies on making a route unreachable after a retraction until all neighbours have been guaranteed to have acted upon the retraction, even in the presence of packet loss. Unless the second algorithm described in Section 3.5.5 of [RFC6126bis] is implemented, this entails that a node is unreachable for a few minutes after the most specific route to it has been retracted. This delay makes Babel slow to recover from a topology change in networks that perform automatic route aggregation. 3. Successful deployments of Babel This section gives a few examples of environments where Babel has been successfully deployed. 3.1. Heterogeneous networks Babel is able to deal with both classical, prefix-based ("Internet- style") routing and flat ("mesh-style") routing over non-transitive link technologies. Just like traditional distance-vector protocols, Babel is able to carry prefixes of arbitrary length, to supress redundant announcements by applying the split-horizon optimisation where applicable, and can be configured to filter out redundant announcements (manual aggregation). Just like specialised mesh protocols, Babel doesn't by default assume that links are transitive or symmetric, can dynamically compute metrics based on an estimation of link quality, and carries large numbers of host routes efficiently by omitting common prefixes. Because of these properties, Babel has seen a number of successful deployments in medium-sized heterogeneous networks, networks that Chroboczek Expires February 18, 2020 [Page 6] Internet-Draft Babel Protocol Applicability August 2019 combine a wired, aggregated backbone with meshy wireless bits at the edges. Efficient operation in heterogeneous networks requires the implementation to distinguish between wired and wireless links, and to perform link quality estimation on wireless links. 3.2. Large scale overlay networks The algorithms used by Babel (loop avoidance, hysteresis, delayed updates) allow it to remain stable in the presence of unstable metrics, even in the presence of a feedback loop. For this reason, it has been successfully deployed in large scale overlay networks, built out of thousands of tunnels spanning continents, where it is used with a metric computed from links' latencies. This particular application depends on the extension for RTT- sensitive routing [DELAY-BASED]. 3.3. Pure mesh networks While Babel is a general-purpose routing protocol, it has been shown to be competitive with dedicated routing protocols for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. Although this particular niche is already served by a number of mature protocols, notably OLSR-ETX and OLSRv2 [RFC7181] (equipped e.g. with the DAT metric [RFC7779]), Babel has seen a moderate amount of successful deployment in pure mesh networks. 3.4. Small unmanaged networks Because of its small size and simple configuration, Babel has been deployed in small, unmanaged networks (e.g., home and small office networks), where it serves as a more efficient replacement for RIP [RFC2453], over which it has two significant advantages: the ability to route multiple address families (IPv6 and IPv4) in a single protocol instance, and good support for using wireless links for transit. 4. IANA Considerations This document requires no IANA actions. [RFC Editor: please remove this section before publication.] Chroboczek Expires February 18, 2020 [Page 7] Internet-Draft Babel Protocol Applicability August 2019 5. Security Considerations As is the case in all distance-vector routing protocols, a Babel speaker receives reachability information from its neighbours, which by default is trusted by all nodes in the routing domain. At the time of writing, the Babel protocol is usually run over a network that is secured either at the physical layer (e.g., physically protecting Ethernet sockets) or at the link layer (using a protocol such as WiFi Protected Access (WPA2)). If Babel is being run over an unprotected network, then the routing traffic needs to be protected using a sufficiently strong cryptographic mechanism. At the time of writing, two such mechanisms have been defined. Babel-MAC [BABEL-MAC] is a simple and easy to implement mechanism that only guarantees authenticity, integrity and replay protection of the routing traffic, and only supports symmetric keying with a small number of keys (typically just one or two). Babel-DTLS [BABEL-DTLS] is a more complex mechanism, that requires some minor changes to be made to a typical Babel implementation and depends on a DTLS stack being available, but inherits all of the features of DTLS, notably confidentiality, optional replay protection, and the ability to use asymmetric keys. Due to its simplicity, Babel-MAC should be the preferred security mechanism in most deployments, with Babel-DTLS available for networks that require its additional features. In addition to the above, the information that a mobile Babel node announces to the whole routing domain is often sufficient to determine a mobile node's physical location with reasonable precision. This might make Babel unapplicable in scenarios where a node's location is considered confidential. 6. Acknowledgments The author is indebted to Jean-Paul Smetz and Alexander Vainshtein for their input to this document. 7. References 7.1. Normative References [RFC6126bis] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", Internet Draft draft-ietf-babel-rfc6126bis-14, August 2019. Chroboczek Expires February 18, 2020 [Page 8] Internet-Draft Babel Protocol Applicability August 2019 7.2. Informational References [BABEL-DTLS] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", Internet Draft draft-ietf-babel-dtls-09, August 2019. [BABEL-MAC] Do, C., Kolodziejak, W., and J. Chroboczek, "MAC authentication for the Babel routing protocol", Internet Draft draft-ietf-babel-hmac-10, August 2019. [BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", draft-jonglez- babel-rtt-extension-01 (work in progress), May 2015. [BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", draft-ietf-babel-source-specific-04 (work in progress), October 2018. [BABEL-TOS] Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in Babel", draft-chouasne-babel-tos-specific-00 (work in progress), July 2017. [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", draft-chroboczek-babel-diversity-routing-01 (work in progress), February 2016. [BRIDGING-LAYERS] Murray, D., Dixon, M., and T. Koziniec, "An Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc Networks", Proc. ATNAC 2010, 2010. [DELAY-BASED] Jonglez, B. and J. Chroboczek, "A delay-based routing metric", March 2014, . [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- Sequenced Distance-Vector Routing (DSDV) for Mobile Computers", ACM SIGCOMM'94 Conference on Communications Architectures, Protocols and Applications 234-244, 1994. [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing Computations", IEEE/ACM Transactions on Networking 1:1, February 1993. Chroboczek Expires February 18, 2020 [Page 9] Internet-Draft Babel Protocol Applicability August 2019 [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. Dean, "The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", draft- clausen-lln-loadng-15 (work in progress), January 2017. [METAROUTING] Griffin, T. and J. Sobrinho, "Metarouting", 2005. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM'05). [REAL-WORLD] Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world performance of current proactive multi-hop mesh protocols", Asia-Pacific Conference on Communication 2009, 2009. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol Version 2", RFC 7181, April 2014. [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)", RFC 7779, DOI 10.17487/RFC7779, April 2016. Chroboczek Expires February 18, 2020 [Page 10] Internet-Draft Babel Protocol Applicability August 2019 [RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and R. White, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 2016. [SS-ROUTING] Boutier, M. and J. Chroboczek, "Source-Specific Routing", August 2014, . In Proc. IFIP Networking 2015. Author's Address Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr Chroboczek Expires February 18, 2020 [Page 11] ./draft-ietf-idr-rfc5575bis-27.txt0000644000764400076440000026141013742005230015733 0ustar iustyiusty IDR Working Group C. Loibl Internet-Draft next layer Telekom GmbH Obsoletes: 5575,7674 (if approved) S. Hares Intended status: Standards Track Huawei Expires: April 18, 2021 R. Raszuk Bloomberg LP D. McPherson Verisign M. Bacher T-Mobile Austria October 15, 2020 Dissemination of Flow Specification Rules draft-ietf-idr-rfc5575bis-27 Abstract This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, that can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. Other applications (e.g. centralized control of traffic in a SDN or NFV context) are also possible. Other documents may specify Flow Specification extensions. The information is carried via BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. This document obsoletes both RFC5575 and RFC7674. Loibl, et al. Expires April 18, 2021 [Page 1] Internet-Draft Flow Specification October 2020 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Definitions of Terms Used in This Memo . . . . . . . . . . . 5 3. Flow Specifications . . . . . . . . . . . . . . . . . . . . . 5 4. Dissemination of IPv4 Flow Specification Information . . . . 6 4.1. Length Encoding . . . . . . . . . . . . . . . . . . . . . 7 4.2. NLRI Value Encoding . . . . . . . . . . . . . . . . . . . 7 4.2.1. Operators . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Components . . . . . . . . . . . . . . . . . . . . . 9 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 14 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Ordering of Flow Specifications . . . . . . . . . . . . . 17 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 18 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 19 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 21 Loibl, et al. Expires April 18, 2021 [Page 2] Internet-Draft Flow Specification October 2020 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 21 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 22 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 23 7.6. Interaction with other Filtering Mechanisms in Routers . 23 7.7. Considerations on Traffic Filtering Action Interference . 24 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 24 9. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 25 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 25 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 27 11.3. Extended Community Flow Specification Actions . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.1. Normative References . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . 34 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Example Python code: flow_rule_cmp . . . . . . . . . 35 Appendix B. Comparison with RFC 5575 . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 1. Introduction This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575] (see Appendix B for the differences). This document also obsoletes "Clarification of the Flowspec Redirect Extended Community" [RFC7674] since it incorporates the encoding of the BGP Flow Specification Redirect Extended Community in Section 7.4. Modern IP routers have the capability to forward traffic and to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. These traffic policy mechanisms allow the operator to define match rules that operate on multiple fields of the packet header. Actions such as the ones described above can be associated with each rule. The n-tuple consisting of the matching criteria defines an aggregate traffic Flow Specification. The matching criteria can include elements such as source and destination address prefixes, IP protocol, and transport protocol port numbers. Section 4 of this document defines a general procedure to encode Flow Specifications for aggregated traffic flows so that they can be distributed as a BGP [RFC4271] NLRI. Additionally, Section 7 of this Loibl, et al. Expires April 18, 2021 [Page 3] Internet-Draft Flow Specification October 2020 document defines the required Traffic Filtering Actions BGP Extended Communities and mechanisms to use BGP for intra- and inter-provider distribution of traffic filtering rules to filter (distributed) denial-of-service (DoS) attacks. By expanding routing information with Flow Specifications, the routing system can take advantage of the ACL (Access Control List) or firewall capabilities in the router's forwarding path. Flow Specifications can be seen as more specific routing entries to a unicast prefix and are expected to depend upon the existing unicast data information. A Flow Specification received from an external autonomous system will need to be validated against unicast routing before being accepted (Section 6). The Flow Specification received from an internal BGP peer within the same autonomous system [RFC4271] is assumed to have been validated prior to transmission within the internal BGP (iBGP) mesh of an autonomous system. If the aggregate traffic flow defined by the unicast destination prefix is forwarded to a given BGP peer, then the local system can install more specific Flow Specifications that may result in different forwarding behavior, as requested by this system. From an operational perspective, the utilization of BGP as the carrier for this information allows a network service provider to reuse both internal route distribution infrastructure (e.g., route reflector or confederation design) and existing external relationships (e.g., inter-domain BGP sessions to a customer network). While it is certainly possible to address this problem using other mechanisms, this solution has been utilized in deployments because of the substantial advantage of being an incremental addition to already deployed mechanisms. In current deployments, the information distributed by this extension is originated both manually as well as automatically, the latter by systems that are able to detect malicious traffic flows. When automated systems are used, care should be taken to ensure the correctness of the automated system. The the limitations of the receiving systems that need to process these automated Flow Specifications need to be taken in consideration as well (see also Section 12). This specification defines required protocol extensions to address most common applications of IPv4 unicast and VPNv4 unicast filtering. The same mechanism can be reused and new match criteria added to Loibl, et al. Expires April 18, 2021 [Page 4] Internet-Draft Flow Specification October 2020 address similar filtering needs for other BGP address families such as IPv6 families [I-D.ietf-idr-flow-spec-v6]. 2. Definitions of Terms Used in This Memo AFI - Address Family Identifier. AS - Autonomous System. Loc-RIB - The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process [RFC4271]. NLRI - Network Layer Reachability Information. PE - Provider Edge router. RIB - Routing Information Base. SAFI - Subsequent Address Family Identifier. VRF - Virtual Routing and Forwarding instance. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Flow Specifications A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined Flow Specification if it matches all the specified criteria. This n-tuple is encoded into a BGP NLRI defined below. A given Flow Specification may be associated with a set of attributes, depending on the particular application; such attributes may or may not include reachability information (i.e., NEXT_HOP). Well-known or AS-specific community attributes can be used to encode a set of predetermined actions. A particular application is identified by a specific (Address Family Identifier, Subsequent Address Family Identifier (AFI, SAFI)) pair [RFC4760] and corresponds to a distinct set of RIBs. Those RIBs should be treated independently from each other in order to assure non-interference between distinct applications. Loibl, et al. Expires April 18, 2021 [Page 5] Internet-Draft Flow Specification October 2020 BGP itself treats the NLRI as a key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics, which is application dependent. This is consistent with existing BGP applications. For instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast reverse-path information (AFI=1, SAFI=2) are handled by BGP without any particular semantics being associated with them until installed in the Loc-RIB. Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix as well as community matching and must apply to the Flow specification defined NLRI-type. Network operators can also control propagation of such routing updates by enabling or disabling the exchange of a particular (AFI, SAFI) pair on a given BGP peering session. 4. Dissemination of IPv4 Flow Specification Information This document defines a Flow Specification NLRI type (Figure 1) that may include several components such as destination prefix, source prefix, protocol, ports, and others (see Section 4.2 below). This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in [RFC4760]. When advertising Flow Specifications, the Length of Next Hop Network Address MUST be set to 0. The Network Address of Next Hop field MUST be ignored. The NLRI field of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as one or more 2-tuples of the form . It consists of a 1- or 2-octet length field followed by a variable-length NLRI value. The length is expressed in octets. +-------------------------------+ | length (0xnn or 0xfnnn) | +-------------------------------+ | NLRI value (variable) | +-------------------------------+ Figure 1: Flow Specification NLRI for IPv4 Implementations wishing to exchange Flow Specification MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in [RFC4760]. The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification, and (AFI=1, SAFI=134) for VPNv4 Flow Specification. Loibl, et al. Expires April 18, 2021 [Page 6] Internet-Draft Flow Specification October 2020 4.1. Length Encoding o If the NLRI length is smaller than 240 (0xf0 hex) octets, the length field can be encoded as a single octet. o Otherwise, it is encoded as an extended-length 2-octet value in which the most significant nibble has the hex value 0xf. In Figure 1 above, values less-than 240 are encoded using two hex digits (0xnn). Values above 239 are encoded using 3 hex digits (0xfnnn). The highest value that can be represented with this encoding is 4095. For example the length value of 239 is encoded as 0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet). 4.2. NLRI Value Encoding The Flow Specification NLRI value consists of a list of optional components and is encoded as follows: Encoding: <[component]+> A specific packet is considered to match the Flow Specification when it matches the intersection (AND) of all the components present in the Flow Specification. Components MUST follow strict type ordering by increasing numerical order. A given component type MAY (exactly once) be present in the Flow Specification. If present, it MUST precede any component of higher numeric type value. All combinations of components within a single Flow Specification are allowed. However, some combinations cannot match any packets (e.g. "ICMP Type AND Port" will never match any packets), and thus SHOULD NOT be propagated by BGP. A NLRI value not encoded as specified here, including a NLRI that contains an unknown component type, is considered malformed and error handling according to Section 10 is performed. 4.2.1. Operators Most of the components described below make use of comparison operators. Which of the two operators is used is defined by the components in Section 4.2.2. The operators are encoded as a single octet. Loibl, et al. Expires April 18, 2021 [Page 7] Internet-Draft Flow Specification October 2020 4.2.1.1. Numeric Operator (numeric_op) This operator is encoded as shown in Figure 2. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | e | a | len | 0 |lt |gt |eq | +---+---+---+---+---+---+---+---+ Figure 2: Numeric Operator (numeric_op) e - end-of-list bit: Set in the last {op, value} pair in the list. a - AND bit: If unset, the result of the previous {op, value} pair is logically ORed with the current one. If set, the operation is a logical AND. In the first operator octet of a sequence it MUST be encoded as unset and MUST be treated as always unset on decoding. The AND operator has higher priority than OR for the purposes of evaluating logical expressions. len - length: The length of the value field for this operator given as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), 8 (len=11) octets. 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding lt - less than comparison between data and value. gt - greater than comparison between data and value. eq - equality between data and value. The bits lt, gt, and eq can be combined to produce common relational operators such as "less or equal", "greater or equal", and "not equal to" as shown in Table 1. Loibl, et al. Expires April 18, 2021 [Page 8] Internet-Draft Flow Specification October 2020 +----+----+----+-----------------------------------+ | lt | gt | eq | Resulting operation | +----+----+----+-----------------------------------+ | 0 | 0 | 0 | false (independent of the value) | | 0 | 0 | 1 | == (equal) | | 0 | 1 | 0 | > (greater than) | | 0 | 1 | 1 | >= (greater than or equal) | | 1 | 0 | 0 | < (less than) | | 1 | 0 | 1 | <= (less than or equal) | | 1 | 1 | 0 | != (not equal value) | | 1 | 1 | 1 | true (independent of the value) | +----+----+----+-----------------------------------+ Table 1: Comparison operation combinations 4.2.1.2. Bitmask Operator (bitmask_op) This operator is encoded as shown in Figure 3. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | e | a | len | 0 | 0 |not| m | +---+---+---+---+---+---+---+---+ Figure 3: Bitmask Operator (bitmask_op) e, a, len - Most significant nibble: (end-of-list bit, AND bit, and length field), as defined in the Numeric Operator format in Section 4.2.1.1. not - NOT bit: If set, logical negation of operation. m - Match bit: If set, this is a bitwise match operation defined as "(data AND value) == value"; if unset, (data AND value) evaluates to TRUE if any of the bits in the value mask are set in the data 0 - all 0 bits: MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding 4.2.2. Components The encoding of each of the components begins with a type field (1 octet) followed by a variable length parameter. The following sections define component types and parameter encodings for the IPv4 IP layer and transport layer headers. IPv6 NLRI component types are described in [I-D.ietf-idr-flow-spec-v6]. Loibl, et al. Expires April 18, 2021 [Page 9] Internet-Draft Flow Specification October 2020 4.2.2.1. Type 1 - Destination Prefix Encoding: Defines the destination prefix to match. The length and prefix fields are encoded as in BGP UPDATE messages [RFC4271] 4.2.2.2. Type 2 - Source Prefix Encoding: Defines the source prefix to match. The length and prefix fields are encoded as in BGP UPDATE messages [RFC4271] 4.2.2.3. Type 3 - IP Protocol Encoding: Contains a list of {numeric_op, value} pairs that are used to match the IP protocol value octet in IP packet header (see [RFC0791] Section 3.1). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 3 component values SHOULD be encoded as single octet (numeric_op len=00). 4.2.2.4. Type 4 - Port Encoding: Defines a list of {numeric_op, value} pairs that matches source OR destination TCP/UDP ports (see [RFC0793] Section 3.1 and [RFC0768] Section "Format"). This component matches if either the destination port OR the source port of a IP packet matches the value. This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 4 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). In case of the presence of the port (destination-port Section 4.2.2.5, source-port Section 4.2.2.6) component only TCP or UDP packets can match the entire Flow Specification. The port component, if present, never matches when the packet's IP protocol value is not 6 (TCP) or 17 (UDP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. Loibl, et al. Expires April 18, 2021 [Page 10] Internet-Draft Flow Specification October 2020 4.2.2.5. Type 5 - Destination Port Encoding: Defines a list of {numeric_op, value} pairs used to match the destination port of a TCP or UDP packet (see also [RFC0793] Section 3.1 and [RFC0768] Section "Format"). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 5 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). The last paragraph of Section 4.2.2.4 also applies to this component. 4.2.2.6. Type 6 - Source Port Encoding: Defines a list of {numeric_op, value} pairs used to match the source port of a TCP or UDP packet (see also [RFC0793] Section 3.1 and [RFC0768] Section "Format"). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 6 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). The last paragraph of Section 4.2.2.4 also applies to this component. 4.2.2.7. Type 7 - ICMP type Encoding: Defines a list of {numeric_op, value} pairs used to match the type field of an ICMP packet (see also [RFC0792] Section "Message Formats"). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 7 component values SHOULD be encoded as single octet (numeric_op len=00). In case of the presence of the ICMP type component only ICMP packets can match the entire Flow Specification. The ICMP type component, if present, never matches when the packet's IP protocol value is not 1 (ICMP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. Loibl, et al. Expires April 18, 2021 [Page 11] Internet-Draft Flow Specification October 2020 4.2.2.8. Type 8 - ICMP code Encoding: Defines a list of {numeric_op, value} pairs used to match the code field of an ICMP packet (see also [RFC0792] Section "Message Formats"). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 8 component values SHOULD be encoded as single octet (numeric_op len=00). In case of the presence of the ICMP code component only ICMP packets can match the entire Flow Specification. The ICMP code component, if present, never matches when the packet's IP protocol value is not 1 (ICMP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. 4.2.2.9. Type 9 - TCP flags Encoding: Defines a list of {bitmask_op, bitmask} pairs used to match TCP Control Bits (see also [RFC0793] Section 3.1). This component uses the Bitmask Operator (bitmask_op) described in Section 4.2.1.2. Type 9 component bitmasks MUST be encoded as 1- or 2-octet bitmask (bitmask_op len=00 or len=01). When a single octet (bitmask_op len=00) is specified, it matches octet 14 of the TCP header (see also [RFC0793] Section 3.1), which contains the TCP Control Bits. When a 2-octet (bitmask_op len=01) encoding is used, it matches octets 13 and 14 of the TCP header with the data offset (leftmost 4 bits) always treated as 0. In case of the presence of the TCP flags component only TCP packets can match the entire Flow Specification. The TCP flags component, if present, never matches when the packet's IP protocol value is not 6 (TCP), if the packet is fragmented and this is not the first fragment, or if the system is unable to locate the transport header. Different implementations may or may not be able to decode the transport header in the presence of IP options or Encapsulating Security Payload (ESP) NULL [RFC4303] encryption. Loibl, et al. Expires April 18, 2021 [Page 12] Internet-Draft Flow Specification October 2020 4.2.2.10. Type 10 - Packet length Encoding: Defines a list of {numeric_op, value} pairs used to match on the total IP packet length (excluding Layer 2 but including IP header). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 10 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). 4.2.2.11. Type 11 - DSCP (Diffserv Code Point) Encoding: Defines a list of {numeric_op, value} pairs used to match the 6-bit DSCP field (see also [RFC2474]). This component uses the Numeric Operator (numeric_op) described in Section 4.2.1.1. Type 11 component values MUST be encoded as single octet (numeric_op len=00). The six least significant bits contain the DSCP value. All other bits SHOULD be treated as 0. 4.2.2.12. Type 12 - Fragment Encoding: Defines a list of {bitmask_op, bitmask} pairs used to match specific IP fragments. This component uses the Bitmask Operator (bitmask_op) described in Section 4.2.1.2. The Type 12 component bitmask MUST be encoded as single octet bitmask (bitmask_op len=00). 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 |LF |FF |IsF|DF | +---+---+---+---+---+---+---+---+ Figure 4: Fragment Bitmask Operand Bitmask values: DF - Don't fragment - match if [RFC0791] IP Header Flags Bit-1 (DF) is 1 Loibl, et al. Expires April 18, 2021 [Page 13] Internet-Draft Flow Specification October 2020 IsF - Is a fragment other than the first - match if [RFC0791] IP Header Fragment Offset is not 0 FF - First fragment - match if [RFC0791] IP Header Fragment Offset is 0 AND Flags Bit-2 (MF) is 1 LF - Last fragment - match if [RFC0791] IP Header Fragment Offset is not 0 AND Flags Bit-2 (MF) is 0 0 - MUST be set to 0 on NLRI encoding, and MUST be ignored during decoding 4.3. Examples of Encodings 4.3.1. Example 1 An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.0/24 and TCP port 25". +--------+----------------+----------+----------+ | length | destination | protocol | port | +--------+----------------+----------+----------+ | 0x0b | 01 18 c0 00 02 | 03 81 06 | 04 81 19 | +--------+----------------+----------+----------+ Decoded: +-------+------------+-------------------------------+ | Value | | | +-------+------------+-------------------------------+ | 0x0b | length | 11 octets (len<240 1-octet) | | 0x01 | type | Type 1 - Destination Prefix | | 0x18 | length | 24 bit | | 0xc0 | prefix | 192 | | 0x00 | prefix | 0 | | 0x02 | prefix | 2 | | 0x03 | type | Type 3 - IP Protocol | | 0x81 | numeric_op | end-of-list, value size=1, == | | 0x06 | value | 6 (TCP) | | 0x04 | type | Type 4 - Port | | 0x81 | numeric_op | end-of-list, value size=1, == | | 0x19 | value | 25 | +-------+------------+-------------------------------+ This constitutes a NLRI with a NLRI length of 11 octets. Loibl, et al. Expires April 18, 2021 [Page 14] Internet-Draft Flow Specification October 2020 4.3.2. Example 2 An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.0/24 from 203.0.113.0/24 and port {range [137, 139] or 8080}". +--------+----------------+----------------+-------------------------+ | length | destination | source | port | +--------+----------------+----------------+-------------------------+ | 0x12 | 01 18 c0 00 02 | 02 18 cb 00 71 | 04 03 89 45 8b 91 1f 90 | +--------+----------------+----------------+-------------------------+ Decoded: +--------+------------+-------------------------------+ | Value | | | +--------+------------+-------------------------------+ | 0x12 | length | 18 octets (len<240 1-octet) | | 0x01 | type | Type 1 - Destination Prefix | | 0x18 | length | 24 bit | | 0xc0 | prefix | 192 | | 0x00 | prefix | 0 | | 0x02 | prefix | 2 | | 0x02 | type | Type 2 - Source Prefix | | 0x18 | length | 24 bit | | 0xcb | prefix | 203 | | 0x00 | prefix | 0 | | 0x71 | prefix | 113 | | 0x04 | type | Type 4 - Port | | 0x03 | numeric_op | value size=1, >= | | 0x89 | value | 137 | | 0x45 | numeric_op | "AND", value size=1, <= | | 0x8b | value | 139 | | 0x91 | numeric_op | end-of-list, value size=2, == | | 0x1f90 | value | 8080 | +--------+------------+-------------------------------+ This constitutes a NLRI with a NLRI length of 18 octets. 4.3.3. Example 3 An example of a Flow Specification NLRI encoding for: "all packets to 192.0.2.1/32 and fragment { DF or FF } (matching packet with DF bit set or First Fragments) Loibl, et al. Expires April 18, 2021 [Page 15] Internet-Draft Flow Specification October 2020 +--------+-------------------+----------+ | length | destination | fragment | +--------+-------------------+----------+ | 0x09 | 01 20 c0 00 02 01 | 0c 80 05 | +--------+-------------------+----------+ Decoded: +-------+------------+------------------------------+ | Value | | | +-------+------------+------------------------------+ | 0x09 | length | 9 octets (len<240 1-octet) | | 0x01 | type | Type 1 - Destination Prefix | | 0x20 | length | 32 bit | | 0xc0 | prefix | 192 | | 0x00 | prefix | 0 | | 0x02 | prefix | 2 | | 0x01 | prefix | 1 | | 0x0c | type | Type 12 - Fragment | | 0x80 | bitmask_op | end-of-list, value size=1 | | 0x05 | bitmask | DF=1, FF=1 | +-------+------------+------------------------------+ This constitutes a NLRI with a NLRI length of 9 octets. 5. Traffic Filtering Traffic filtering policies have been traditionally considered to be relatively static. Limitations of these static mechanisms caused this new dynamic mechanism to be designed for the three new applications of traffic filtering: o Prevention of traffic-based, denial-of-service (DOS) attacks. o Traffic filtering in the context of BGP/MPLS VPN service. o Centralized traffic control for SDN/NFV networks. These applications require coordination among service providers and/ or coordination among the AS within a service provider. The Flow Specification NLRI defined in Section 4 conveys information about traffic filtering rules for traffic that should be discarded or handled in a manner specified by a set of pre-defined actions (which are defined in BGP Extended Communities). This mechanism is primarily designed to allow an upstream autonomous system to perform inbound filtering in their ingress routers of traffic that a given downstream AS wishes to drop. Loibl, et al. Expires April 18, 2021 [Page 16] Internet-Draft Flow Specification October 2020 In order to achieve this goal, this document specifies two application-specific NLRI identifiers that provide traffic filters, and a set of actions encoding in BGP Extended Communities. The two application-specific NLRI identifiers are: o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with specific semantic rules for IPv4 routes, and o VPNv4 Flow Specification identifier (AFI=1, SAFI=134) value, which can be used to propagate traffic filtering information in a BGP/ MPLS VPN environment. Encoding of the NLRI is described in Section 4 for IPv4 Flow Specification and in Section 8 for VPNv4 Flow Specification. The filtering actions are described in Section 7. 5.1. Ordering of Flow Specifications More than one Flow Specification may match a particular traffic flow. Thus, it is necessary to define the order in which Flow Specifications get matched and actions being applied to a particular traffic flow. This ordering function is such that it does not depend on the arrival order of the Flow Specification via BGP and thus is consistent in the network. The relative order of two Flow Specifications is determined by comparing their respective components. The algorithm starts by comparing the left-most components (lowest component type value) of the Flow Specifications. If the types differ, the Flow Specification with lowest numeric type value has higher precedence (and thus will match before) than the Flow Specification that doesn't contain that component type. If the component types are the same, then a type- specific comparison is performed (see below). If the types are equal the algorithm continues with the next component. For IP prefix values (IP destination or source prefix): If one of the two prefixes to compare is a more specific prefix of the other, the more specific prefix has higher precedence. Otherwise the one with the lowest IP value has higher precedence. For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal the string with the lowest prefix has higher precedence. If the common prefix is equal, Loibl, et al. Expires April 18, 2021 [Page 17] Internet-Draft Flow Specification October 2020 the longest string is considered to have higher precedence than the shorter one. The code in Appendix A shows a Python3 implementation of the comparison algorithm. The full code was tested with Python 3.6.3 and can be obtained at https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp [1]. 6. Validation Procedure Flow Specifications received from a BGP peer that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of two routes for the same Flow Specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise. The first step of the BGP Route Selection procedure (Section 9.1.2 of [RFC4271] is to exclude from the selection procedure routes that are considered non-feasible. In the context of IP routing information, this step is used to validate that the NEXT_HOP attribute of a given route is resolvable. The concept can be extended, in the case of the Flow Specification NLRI, to allow other validation procedures. The validation process described below validates Flow Specifications against unicast routes received over the same AFI but the associated unicast routing information SAFI: Flow Specification received over SAFI=133 will be validated against routes received over SAFI=1 Flow Specification received over SAFI=134 will be validated against routes received over SAFI=128 In the absence of explicit configuration a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the conditions below are true: a) A destination prefix component is embedded in the Flow Specification. b) The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification (this is the unicast route with the longest possible prefix length covering the destination prefix embedded in the Flow Specification). Loibl, et al. Expires April 18, 2021 [Page 18] Internet-Draft Flow Specification October 2020 c) There are no "more-specific" unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in rule b). However, rule a) MAY be relaxed by explicit configuration, permitting Flow Specifications that include no destination prefix component. If such is the case, rules b) and c) are moot and MUST be disregarded. By "originator" of a BGP route, we mean either the address of the originator in the ORIGINATOR_ID Attribute [RFC4456], or the source IP address of the BGP peer, if this path attribute is not present. BGP implementations MUST also enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the left-most position of the AS_PATH attribute. While this rule is optional in the BGP specification, it becomes necessary to enforce it here for security reasons. The best-match unicast route may change over the time independently of the Flow Specification NLRI. Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. Revalidation is defined as retesting rules a) to c) as described above. Explanation: The underlying concept is that the neighboring AS that advertises the best unicast route for a destination is allowed to advertise Flow Specification information that conveys a destination prefix that is more or equally specific. Thus, as long as there are no "more- specific" unicast routes, received from a different neighboring AS, which would be affected by that Flow Specification, the Flow Specification is validated successfully. The neighboring AS is the immediate destination of the traffic described by the Flow Specification. If it requests these flows to be dropped, that request can be honored without concern that it represents a denial of service in itself. The reasoning is that this is as if the traffic is being dropped by the downstream autonomous system, and there is no added value in carrying the traffic to it. 7. Traffic Filtering Actions This document defines a minimum set of Traffic Filtering Actions that it standardizes as BGP extended communities [RFC4360]. This is not meant to be an inclusive list of all the possible actions, but only a subset that can be interpreted consistently across the network. Loibl, et al. Expires April 18, 2021 [Page 19] Internet-Draft Flow Specification October 2020 Additional actions can be defined as either requiring standards or as vendor specific. The default action for a matching Flow Specification is to accept the packet (treat the packet according to the normal forwarding behaviour of the system). This document defines the following extended communities values shown in Table 2 in the form 0xttss where tt indicates the type and ss indicates the sub-type of the extended community. Encodings for these extended communities are described below. +-------------+---------------------------+-------------------------+ | community | action | encoding | | 0xttss | | | +-------------+---------------------------+-------------------------+ | 0x8006 | traffic-rate-bytes | 2-octet AS, 4-octet | | | (Section 7.1) | float | | TBD | traffic-rate-packets | 2-octet AS, 4-octet | | | (Section 7.1) | float | | 0x8007 | traffic-action | bitmask | | | (Section 7.3) | | | 0x8008 | rt-redirect AS-2octet | 2-octet AS, 4-octet | | | (Section 7.4) | value | | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 address, | | | (Section 7.4) | 2-octet value | | 0x8208 | rt-redirect AS-4octet | 4-octet AS, 2-octet | | | (Section 7.4) | value | | 0x8009 | traffic-marking | DSCP value | | | (Section 7.5) | | +-------------+---------------------------+-------------------------+ Table 2: Traffic Filtering Action Extended Communities Multiple Traffic Filtering Actions defined in this document may be present for a single Flow Specification and SHOULD be applied to the traffic flow (for example traffic-rate-bytes and rt-redirect can be applied to packets at the same time). If not all of the Traffic Filtering Actions can be applied to a traffic flow they should be treated as interfering Traffic Filtering Actions (see below). Some Traffic Filtering Actions may interfere with each other or even contradict. Section 7.7 of this document provides general considerations on such Traffic Filtering Action interference. Any additional definition of Traffic Filtering Actions SHOULD specify the action to take if those Traffic Filtering Actions interfere (also with existing Traffic Filtering Actions). Loibl, et al. Expires April 18, 2021 [Page 20] Internet-Draft Flow Specification October 2020 All Traffic Filtering Actions are specified as transitive BGP Extended Communities. 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 The traffic-rate-bytes extended community uses the following extended community encoding: The first two octets carry the 2-octet id, which can be assigned from a 2-octet AS number. When a 4-octet AS number is locally present, the 2 least significant octets of such an AS number can be used. This value is purely informational and SHOULD NOT be interpreted by the implementation. The remaining 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded. On encoding the traffic-rate MUST NOT be negative. On decoding negative values MUST be treated as zero (discard all traffic). Interferes with: May interfere with the traffic-rate-packets (see Section 7.2). A policy may allow both filtering by traffic-rate- packets and traffic-rate-bytes. If the policy does not allow this, these two actions will conflict. 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type TBD The traffic-rate-packets extended community uses the same encoding as the traffic-rate-bytes extended community. The floating point value carries the maximum packet rate in packets per second. A traffic- rate-packets of 0 should result in all traffic for the particular flow to be discarded. On encoding the traffic-rate-packets MUST NOT be negative. On decoding negative values MUST be treated as zero (discard all traffic). Interferes with: May interfere with the traffic-rate-bytes (see Section 7.1). A policy may allow both filtering by traffic-rate- packets and traffic-rate-bytes. If the policy does not allow this, these two actions will conflict. 7.3. Traffic-action (traffic-action) sub-type 0x07 The traffic-action extended community consists of 6 octets of which only the 2 least significant bits of the 6th octet (from left to right) are defined by this document as shown in Figure 5. Loibl, et al. Expires April 18, 2021 [Page 21] Internet-Draft Flow Specification October 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Action Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tr. Action Field (cont.) |S|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Traffic-action Extended Community Encoding where S and T are defined as: o T: Terminal Action (bit 47): When this bit is set, the traffic filtering engine will evaluate any subsequent Flow Specifications (as defined by the ordering procedure Section 5.1). If not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. o S: Sample (bit 46): Enables traffic sampling and logging for this Flow Specification (only effective when set). o Traffic Action Field: Other Traffic Action Field (see Section 11) bits unused in this specification. These bits MUST be set to 0 on encoding, and MUST be ignored during decoding. The use of the Terminal Action (bit 47) may result in more than one Flow Specification matching a particular traffic flow. All the Traffic Filtering Actions from these Flow Specifications shall be collected and applied. In case of interfering Traffic Filtering Actions it is an implementation decision which Traffic Filtering Actions are selected. See also Section 7.7. Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. 7.4. RT Redirect (rt-redirect) sub-type 0x08 The redirect extended community allows the traffic to be redirected to a VRF routing instance that lists the specified route-target in its import policy. If several local instances match this criteria, the choice between them is a local matter (for example, the instance with the lowest Route Distinguisher value can be elected). This Extended Community allows 3 different encodings formats for the route-target (type 0x80, 0x81, 0x82). It uses the same encoding as the Route Target Extended Community in Sections 3.1 (type 0x80: 2-octet AS, 4-octet value), 3.2 (type 0x81: 4-octet IPv4 address, 2-octet value) and 4 of [RFC4360] and Section 2 (type 0x82: 4-octet Loibl, et al. Expires April 18, 2021 [Page 22] Internet-Draft Flow Specification October 2020 AS, 2-octet value) of [RFC5668] with the high-order octet of the Type field 0x80, 0x81, 0x82 respectively and the low-order of the Type field (Sub-Type) always 0x08. Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. 7.5. Traffic Marking (traffic-marking) sub-type 0x09 The traffic marking extended community instructs a system to modify the DSCP bits in the IP header ([RFC2474] Section 3) of a transiting IP packet to the corresponding value encoded in the 6 least significant bits of the extended community value as shown in Figure 6. The extended is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | reserved | reserved | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | r.| DSCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Traffic Marking Extended Community Encoding o DSCP: new DSCP value for the transiting IP packet. o reserved, r.: MUST be set to 0 on encoding, and MUST be ignored during decoding. Interferes with: No other BGP Flow Specification Traffic Filtering Action in this document. 7.6. Interaction with other Filtering Mechanisms in Routers Implementations should provide mechanisms that map an arbitrary BGP community value (normal or extended) to Traffic Filtering Actions that require different mappings on different systems in the network. For instance, providing packets with a worse-than-best-effort per-hop behavior is a functionality that is likely to be implemented differently in different systems and for which no standard behavior is currently known. Rather than attempting to define it here, this can be accomplished by mapping a user-defined community value to platform-/network-specific behavior via user configuration. Loibl, et al. Expires April 18, 2021 [Page 23] Internet-Draft Flow Specification October 2020 7.7. Considerations on Traffic Filtering Action Interference Since Traffic Filtering Actions are represented as BGP extended community values, Traffic Filtering Actions may interfere with each other (e.g. there may be more than one conflicting traffic-rate-bytes Traffic Filtering Action associated with a single Flow Specification). Traffic Filtering Action interference has no impact on BGP propagation of Flow Specifications (all communities are propagated according to policies). If a Flow Specification associated with interfering Traffic Filtering Actions is selected for packet forwarding, it is an implementation decision which of the interfering Traffic Filtering Actions are selected. Implementors of this specification SHOULD document the behaviour of their implementation in such cases. Operators are encouraged to make use of the BGP policy framework supported by their implementation in order to achieve a predictable behaviour. See also Section 12. 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks Provider-based Layer 3 VPN networks, such as the ones using a BGP/ MPLS IP VPN [RFC4364] control plane, may have different traffic filtering requirements than Internet service providers. But also Internet service providers may use those VPNs for scenarios like having the Internet routing table in a VRF, resulting in the same traffic filtering requirements as defined for the global routing table environment within this document. This document defines an additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used to propagate Flow Specification in a BGP/MPLS VPN environment. The NLRI format for this address family consists of a fixed-length Route Distinguisher field (8 octets) followed by the Flow Specification NLRI value (Section 4.2). The NLRI length field shall include both the 8 octets of the Route Distinguisher as well as the subsequent Flow Specification NLRI value. The resulting encoding is shown in Figure 7. +--------------------------------+ | length (0xnn or 0xfn nn) | +--------------------------------+ | Route Distinguisher (8 octets) | +--------------------------------+ | NLRI value (variable) | +--------------------------------+ Figure 7: Flow Specification NLRI for MPLS Loibl, et al. Expires April 18, 2021 [Page 24] Internet-Draft Flow Specification October 2020 Propagation of this NLRI is controlled by matching Route Target extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as described in BGP/ MPLS IP VPNs [RFC4364]. Flow Specifications received via this NLRI apply only to traffic that belongs to the VRF(s) in which it is imported. By default, traffic received from a remote PE is switched via an MPLS forwarding decision and is not subject to filtering. Contrary to the behavior specified for the non-VPN NLRI, Flow Specifications are accepted by default, when received from remote PE routers. The validation procedure (Section 6) and Traffic Filtering Actions (Section 7) are the same as for IPv4. 9. Traffic Monitoring Traffic filtering applications require monitoring and traffic statistics facilities. While this is an implementation specific choice, implementations SHOULD provide: o A mechanism to log the packet header of filtered traffic. o A mechanism to count the number of matches for a given Flow Specification. 10. Error Handling Error handling according to [RFC7606] and [RFC4760] applies to this specification. This document introduces Traffic Filtering Action Extended Communities. Malformed Traffic Filtering Action Extended Communities in the sense of [RFC7606] Section 7.14. are Extended Community values that cannot be decoded according to Section 7 of this document. 11. IANA Considerations This section complies with [RFC7153]. 11.1. AFI/SAFI Definitions IANA maintains a registry entitled "SAFI Values". For the purpose of this work, IANA is requested to update the following SAFIs to read according to the table below (Note: This document obsoletes both Loibl, et al. Expires April 18, 2021 [Page 25] Internet-Draft Flow Specification October 2020 RFC7674 and RFC5575 and all references to those documents should be deleted from the registry below): +-------+------------------------------------------+----------------+ | Value | Name | Reference | +-------+------------------------------------------+----------------+ | 133 | Dissemination of Flow Specification | [this | | | rules | document] | | 134 | L3VPN Dissemination of Flow | [this | | | Specification rules | document] | +-------+------------------------------------------+----------------+ Table 3: Registry: SAFI Values The above textual changes generalise the definition of the SAFIs rather than change its underlying meaning. Therefore, based on "The YANG 1.1 Data Modeling Language" [RFC7950], the above text implies that the following YANG enums from "Common YANG Data Types for the Routing Area" [RFC8294] need to have their names and descriptions at https://www.iana.org/assignments/ iana-routing-types [2] changed to: enum flow-spec-safi { value 133; description "Dissemination of Flow Specification rules SAFI."; } enum l3vpn-flow-spec-safi { value 134; description "L3VPN Dissemination of Flow Specification rules SAFI."; } A new revision statement should be added to the module as follows: revision [revision date] { description "Non-backwards-compatible change of SAFI names (SAFI values 133, 134)."; reference "[this document]: Dissemination of Flow Specification Rules."; } Loibl, et al. Expires April 18, 2021 [Page 26] Internet-Draft Flow Specification October 2020 11.2. Flow Component Definitions A Flow Specification consists of a sequence of flow components, which are identified by an 8-bit component type. IANA has created and maintains a registry entitled "Flow Spec Component Types". IANA is requested to update the reference for this registry to [this document]. Furthermore the references to the values should be updated according to the table below (Note: This document obsoletes both RFC7674 and RFC5575 and all references to those documents should be deleted from the registry below). +-------+--------------------+-----------------+ | Value | Name | Reference | +-------+--------------------+-----------------+ | 1 | Destination Prefix | [this document] | | 2 | Source Prefix | [this document] | | 3 | IP Protocol | [this document] | | 4 | Port | [this document] | | 5 | Destination port | [this document] | | 6 | Source port | [this document] | | 7 | ICMP type | [this document] | | 8 | ICMP code | [this document] | | 9 | TCP flags | [this document] | | 10 | Packet length | [this document] | | 11 | DSCP | [this document] | | 12 | Fragment | [this document] | +-------+--------------------+-----------------+ Table 4: Registry: Flow Spec Component Types In order to manage the limited number space and accommodate several usages, the following policies defined by [RFC8126] are used: +--------------+------------------------+ | Type Values | Policy | +--------------+------------------------+ | 0 | Reserved | | [1 .. 127] | Specification Required | | [128 .. 254] | Expert Review | | 255 | Reserved | +--------------+------------------------+ Table 5: Flow Spec Component Types Policies Guidance for Experts: 128-254 requires Expert Review as the registration policy. The Experts are expected to check the clarity of purpose and use of the requested code points. The Experts must also verify that Loibl, et al. Expires April 18, 2021 [Page 27] Internet-Draft Flow Specification October 2020 any specification produced in the IETF that requests one of these code points has been made available for review by the IDR working group and that any specification produced outside the IETF does not conflict with work that is active or already published within the IETF. It must be pointed out that introducing new component types may break interoperability with existing implementations of this protocol. 11.3. Extended Community Flow Specification Actions The Extended Community Flow Specification Action types defined in this document consist of two parts: Type (BGP Transitive Extended Community Type) Sub-Type For the type-part, IANA maintains a registry entitled "BGP Transitive Extended Community Types". For the purpose of this work (Section 7), IANA is requested to update the references to the following entries according to the table below (Note: This document obsoletes both RFC7674 and RFC5575 and all references to those documents should be deleted in the registry below): +-------+-----------------------------------------------+-----------+ | Type | Name | Reference | | Value | | | +-------+-----------------------------------------------+-----------+ | 0x81 | Generic Transitive Experimental | [this | | | Use Extended Community Part 2 (Sub-Types are | document] | | | defined in the "Generic Transitive | | | | Experimental Use Extended Community Part 2 | | | | Sub-Types" Registry) | | | 0x82 | Generic Transitive Experimental | [this | | | Use Extended Community Part 3 | document] | | | (Sub-Types are defined in the "Generic | | | | Transitive Experimental Use | | | | Extended Community Part 3 Sub-Types" | | | | Registry) | | +-------+-----------------------------------------------+-----------+ Table 6: Registry: BGP Transitive Extended Community Types For the sub-type part of the extended community Traffic Filtering Actions IANA maintains the following registries. IANA is requested to update all names and references according to the tables below and assign a new value for the "Flow spec traffic-rate-packets" Sub-Type (Note: This document obsoletes both RFC7674 and RFC5575 and all Loibl, et al. Expires April 18, 2021 [Page 28] Internet-Draft Flow Specification October 2020 references to those documents should be deleted from the registries below). +----------+--------------------------------------------+-----------+ | Sub-Type | Name | Reference | | Value | | | +----------+--------------------------------------------+-----------+ | 0x06 | Flow spec traffic-rate-bytes | [this | | | | document] | | TBD | Flow spec traffic-rate-packets | [this | | | | document] | | 0x07 | Flow spec traffic-action (Use | [this | | | of the "Value" field is defined in the | document] | | | "Traffic Action Fields" registry) | | | 0x08 | Flow spec rt-redirect | [this | | | AS-2octet format | document] | | 0x09 | Flow spec traffic-remarking | [this | | | | document] | +----------+--------------------------------------------+-----------+ Table 7: Registry: Generic Transitive Experimental Use Extended Community Sub-Types +------------+----------------------------------------+-------------+ | Sub-Type | Name | Reference | | Value | | | +------------+----------------------------------------+-------------+ | 0x08 | Flow spec rt-redirect IPv4 | [this | | | format | document] | +------------+----------------------------------------+-------------+ Table 8: Registry: Generic Transitive Experimental Use Extended Community Part 2 Sub-Types +------------+-----------------------------------------+------------+ | Sub-Type | Name | Reference | | Value | | | +------------+-----------------------------------------+------------+ | 0x08 | Flow spec rt-redirect | [this | | | AS-4octet format | document] | +------------+-----------------------------------------+------------+ Table 9: Registry: Generic Transitive Experimental Use Extended Community Part 3 Sub-Types Furthermore IANA is requested to update the reference for the registries "Generic Transitive Experimental Use Extended Community Loibl, et al. Expires April 18, 2021 [Page 29] Internet-Draft Flow Specification October 2020 Part 2 Sub-Types" and "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types" to [this document]. The "traffic-action" extended community (Section 7.3) defined in this document has 46 unused bits, which can be used to convey additional meaning. IANA created and maintains a registry entitled: "Traffic Action Fields". IANA is requested to update the reference for this registry to [this document]. Furthermore IANA is requested to update the references according to the table below. These values should be assigned via IETF Review rules only (Note: This document obsoletes both RFC7674 and RFC5575 and all references to those documents should be deleted from the registry below). +-----+-----------------+-----------------+ | Bit | Name | Reference | +-----+-----------------+-----------------+ | 47 | Terminal Action | [this document] | | 46 | Sample | [this document] | +-----+-----------------+-----------------+ Table 10: Registry: Traffic Action Fields 12. Security Considerations As long as Flow Specifications are restricted to match the corresponding unicast routing paths for the relevant prefixes (Section 6), the security characteristics of this proposal are equivalent to the existing security properties of BGP unicast routing. Any relaxation of the validation procedure described in Section 6 may allow unwanted Flow Specifications to be propagated and thus unwanted Traffic Filtering Actions may be applied to flows. Where the above mechanisms are not in place, this could open the door to further denial-of-service attacks such as unwanted traffic filtering, remarking or redirection. Deployment of specific relaxations of the validation within an administrative boundary of a network are useful in some networks for quickly distributing filters to prevent denial-of-service attacks. For a network to utilize this relaxation, the BGP policies must support additional filtering since the origin AS field is empty. Specifications relaxing the validation restrictions MUST contain security considerations that provide details on the required additional filtering. For example, the use of Origin validation can provide enhanced filtering within an AS confederation. Inter-provider routing is based on a web of trust. Neighboring autonomous systems are trusted to advertise valid reachability Loibl, et al. Expires April 18, 2021 [Page 30] Internet-Draft Flow Specification October 2020 information. If this trust model is violated, a neighboring autonomous system may cause a denial-of-service attack by advertising reachability information for a given prefix for which it does not provide service (unfiltered address space hijack). Since validation of the Flow Specification is tied to the announcement of the best unicast route, the failure in the validation of best path route may prevent the Flow Specificaiton from being used by a local router. Possible mitigations are [RFC6811] and [RFC8205]. On IXPs routes are often exchanged via route servers which do not extend the AS_PATH. In such cases it is not possible to enforce the left-most AS in the AS_PATH to be the neighbor AS (the AS of the route server). Since the validation of Flow Specification (Section 6) depends on this, additional care must be taken. It is advised to use a strict inbound route policy in such scenarios. Enabling firewall-like capabilities in routers without centralized management could make certain failures harder to diagnose. For example, it is possible to allow TCP packets to pass between a pair of addresses but not ICMP packets. It is also possible to permit packets smaller than 900 or greater than 1000 octets to pass between a pair of addresses, but not packets whose length is in the range 900- 1000. Such behavior may be confusing and these capabilities should be used with care whether manually configured or coordinated through the protocol extensions described in this document. Flow Specification BGP speakers (e.g. automated DDoS controllers) not properly programmed, algorithms that are not performing as expected, or simply rogue systems may announce unintended Flow Specifications, send updates at a high rate or generate a high number of Flow Specifications. This may stress the receiving systems, exceed their capacity, or lead to unwanted Traffic Filtering Actions being applied to flows. While the general verification of the Flow Specification NLRI is specified in this document (Section 6) the Traffic Filtering Actions received by a third party may need custom verification or filtering. In particular all non traffic-rate actions may allow a third party to modify packet forwarding properties and potentially gain access to other routing-tables/VPNs or undesired queues. This can be avoided by proper filtering/screening of the Traffic Filtering Action communities at network borders and only exposing a predefined subset of Traffic Filtering Actions (see Section 7) to third parties. One way to achieve this is by mapping user-defined communities, that can be set by the third party, to Traffic Filtering Actions and not accepting Traffic Filtering Action extended communities from third parties. Loibl, et al. Expires April 18, 2021 [Page 31] Internet-Draft Flow Specification October 2020 This extension adds additional information to Internet routers. These are limited in terms of the maximum number of data elements they can hold as well as the number of events they are able to process in a given unit of time. Service providers need to consider the maximum capacity of their devices and may need to limit the number of Flow Specifications accepted and processed. 13. Contributors Barry Greene, Pedro Marques, Jared Mauch and Nischal Sheth were authors on [RFC5575], and therefore are contributing authors on this document. 14. Acknowledgements The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris Morrow, Charlie Kaufman, and David Smith for their comments for the comments on the original [RFC5575]. Chaitanya Kodeboyina helped design the flow validation procedure; and Steven Lin and Jim Washburn ironed out all the details necessary to produce a working implementation in the original [RFC5575]. A packet rate Traffic Filtering Action was also described in a Flow Specification extension draft and the authors like to thank Wesley Eddy, Justin Dailey and Gilbert Clark for their work. Additionally, the authors would like to thank Alexander Mayrhofer, Nicolas Fevrier, Job Snijders, Jeffrey Haas and Adam Chappell for their comments and review. 15. References 15.1. Normative References [IEEE.754.1985] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE 754-1985, August 1985. [ISO_IEC_9899] ISO, "Information technology -- Programming languages -- C", ISO/IEC 9899:2018, June 2018. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . Loibl, et al. Expires April 18, 2021 [Page 32] Internet-Draft Flow Specification October 2020 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . Loibl, et al. Expires April 18, 2021 [Page 33] Internet-Draft Flow Specification October 2020 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, DOI 10.17487/RFC5668, October 2009, . [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References [I-D.ietf-idr-flow-spec-v6] Loibl, C., Raszuk, R., and S. Hares, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow- spec-v6-15 (work in progress), September 2020. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect Extended Community", RFC 7674, DOI 10.17487/RFC7674, October 2015, . Loibl, et al. Expires April 18, 2021 [Page 34] Internet-Draft Flow Specification October 2020 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . 15.3. URIs [1] https://github.com/stoffi92/rfc5575bis/tree/master/flowspec-cmp [2] https://www.iana.org/assignments/iana-routing-types Appendix A. Example Python code: flow_rule_cmp """ Copyright (c) 2020 IETF Trust and the persons identified as authors of draft-ietf-idr-rfc5575bis. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). """ import itertools import collections import ipaddress EQUAL = 0 A_HAS_PRECEDENCE = 1 B_HAS_PRECEDENCE = 2 IP_DESTINATION = 1 IP_SOURCE = 2 FS_component = collections.namedtuple('FS_component', 'component_type op_value') Loibl, et al. Expires April 18, 2021 [Page 35] Internet-Draft Flow Specification October 2020 class FS_nlri(object): """ FS_nlri class implementation that allows sorting. By calling .sort() on a array of FS_nlri objects these will be sorted according to the flow_rule_cmp algorithm. Example: nlri = [ FS_nlri(components=[ FS_component(component_type=IP_DESTINATION, op_value=ipaddress.ip_network('10.1.0.0/16') ), FS_component(component_type=4, op_value=bytearray([0,1,2,3,4,5,6])), ]), FS_nlri(components=[ FS_component(component_type=5, op_value=bytearray([0,1,2,3,4,5,6])), FS_component(component_type=6, op_value=bytearray([0,1,2,3,4,5,6])), ]), ] nlri.sort() # sorts the array accorinding to the algorithm """ def __init__(self, components = None): """ components: list of type FS_component """ self.components = components def __lt__(self, other): # use the below algorithm for sorting result = flow_rule_cmp(self, other) if result == B_HAS_PRECEDENCE: return True else: return False def flow_rule_cmp(a, b): """ Example of the flowspec comparison algorithm. """ for comp_a, comp_b in itertools.zip_longest(a.components, b.components): # If a component type does not exist in one rule # this rule has lower precedence if not comp_a: return B_HAS_PRECEDENCE Loibl, et al. Expires April 18, 2021 [Page 36] Internet-Draft Flow Specification October 2020 if not comp_b: return A_HAS_PRECEDENCE # Higher precedence for lower component type if comp_a.component_type < comp_b.component_type: return A_HAS_PRECEDENCE if comp_a.component_type > comp_b.component_type: return B_HAS_PRECEDENCE # component types are equal -> type specific comparison if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): # assuming comp_a.op_value, comp_b.op_value of # type ipaddress.IPv4Network if comp_a.op_value.overlaps(comp_b.op_value): # longest prefixlen has precedence if comp_a.op_value.prefixlen > \ comp_b.op_value.prefixlen: return A_HAS_PRECEDENCE if comp_a.op_value.prefixlen < \ comp_b.op_value.prefixlen: return B_HAS_PRECEDENCE # components equal -> continue with next component elif comp_a.op_value > comp_b.op_value: return B_HAS_PRECEDENCE elif comp_a.op_value < comp_b.op_value: return A_HAS_PRECEDENCE else: # assuming comp_a.op_value, comp_b.op_value of type # bytearray if len(comp_a.op_value) == len(comp_b.op_value): if comp_a.op_value > comp_b.op_value: return B_HAS_PRECEDENCE if comp_a.op_value < comp_b.op_value: return A_HAS_PRECEDENCE # components equal -> continue with next component else: common = min(len(comp_a.op_value), len(comp_b.op_value)) if comp_a.op_value[:common] > comp_b.op_value[:common]: return B_HAS_PRECEDENCE elif comp_a.op_value[:common] < \ comp_b.op_value[:common]: return A_HAS_PRECEDENCE # the first common bytes match elif len(comp_a.op_value) > len(comp_b.op_value): return A_HAS_PRECEDENCE else: return B_HAS_PRECEDENCE return EQUAL Loibl, et al. Expires April 18, 2021 [Page 37] Internet-Draft Flow Specification October 2020 Appendix B. Comparison with RFC 5575 This document includes numerous editorial changes to [RFC5575]. It also completely incorporates the redirect action clarification document [RFC7674]. It is recommended to read the entire document. The authors, however want to point out the following technical changes to [RFC5575]: Section 1 introduces the Flow Specification NLRI. In [RFC5575] this NLRI was defined as an opaque-key in BGPs database. This specification has removed all references to an opaque-key property. BGP implementations are able to understand the NLRI encoding. Section 4.2.1.1 defines a numeric operator and comparison bit combinations. In [RFC5575] the meaning of those bit combination was not explicitly defined and left open to the reader. Section 4.2.2.3 - Section 4.2.2.8, Section 4.2.2.10, Section 4.2.2.11 make use of the above numeric operator. The allowed length of the comparison value was not consistently defined in [RFC5575]. Section 7 defines all Traffic Filtering Action Extended communities as transitive extended communities. [RFC5575] defined the traffic-rate action to be non-transitive and did not define the transitivity of the other Traffic Filtering Action communities at all. Section 7.2 introduces a new Traffic Filtering Action (traffic- rate-packets). This action did not exist in [RFC5575]. Section 7.4 contains the same redirect actions already defined in [RFC5575] however, these actions have been renamed to "rt- redirect" to make it clearer that the redirection is based on route-target. This section also completely incorporates the [RFC7674] clarifications of the Flowspec Redirect Extended Community. Section 7.7 contains general considerations on interfering traffic actions. Section 7.3 also cross-references Section 7.7. [RFC5575] did not mention this. Section 10 contains new error handling. Loibl, et al. Expires April 18, 2021 [Page 38] Internet-Draft Flow Specification October 2020 Authors' Addresses Christoph Loibl next layer Telekom GmbH Mariahilfer Guertel 37/7 Vienna 1150 AT Phone: +43 664 1176414 Email: cl@tix.at Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 USA Email: robert@raszuk.net Danny McPherson Verisign USA Email: dmcpherson@verisign.com Martin Bacher T-Mobile Austria Rennweg 97-99 Vienna 1030 AT Email: mb.ietf@gmail.com Loibl, et al. Expires April 18, 2021 [Page 39] ./draft-ietf-babel-dtls-10.txt0000644000764400076440000005524313676741736015417 0ustar iustyiusty Network Working Group A. Decimo Internet-Draft IRIF, University of Paris-Diderot Intended status: Standards Track D. Schinazi Expires: January 1, 2021 Google LLC J. Chroboczek IRIF, University of Paris-Diderot June 30, 2020 Babel Routing Protocol over Datagram Transport Layer Security draft-ietf-babel-dtls-10 Abstract The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 1, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Decimo, et al. Expires January 1, 2021 [Page 1] Internet-Draft Babel over DTLS June 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Specification of Requirements . . . . . . . . . . . . . . 2 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 2. Operation of the Protocol . . . . . . . . . . . . . . . . . . 3 2.1. DTLS Connection Initiation . . . . . . . . . . . . . . . 3 2.2. Protocol Encoding . . . . . . . . . . . . . . . . . . . . 4 2.3. Transmission . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Reception . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Neighbour table entry . . . . . . . . . . . . . . . . . . 5 2.6. Simultaneous operation of both Babel over DTLS and unprotected Babel on a Node . . . . . . . . . . . . . . . 5 2.7. Simultaneous operation of both Babel over DTLS and unprotected Babel on a Network . . . . . . . . . . . . . 6 3. Interface Maximum Transmission Unit Issues . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Performance Considerations . . . . . . . . . . . . . 9 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Babel Routing Protocol [RFC6126bis] does not contain any means to authenticate neighbours or protect messages sent between them. Because of this, an attacker is able to send maliciously crafted Babel messages which could lead a network to route traffic to an attacker or to an under-resourced target causing denial of service. This document specifies a mechanism to prevent such attacks, using Datagram Transport Layer Security (DTLS) [RFC6347]. 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Decimo, et al. Expires January 1, 2021 [Page 2] Internet-Draft Babel over DTLS June 2020 1.2. Applicability The protocol described in this document protects Babel packets with DTLS. As such, it inherits the features offered by DTLS, notably authentication, integrity, optional replay protection, confidentiality and asymmetric keying. It is therefore expected to be applicable in a wide range of environments. There exists another mechanism for securing Babel, namely Babel HMAC authentication [BABEL-HMAC]. HMAC only offers basic features, namely authentication, integrity and replay protection with a small number of symmetric keys. A comparison of Babel security mechanisms and their applicability can be found in [RFC6126bis]. Note that Babel over DTLS provides a single authentication domain, meaning that all nodes that have the right credentials can convey any and all routing information. DTLS supports several mechanisms by which nodes can identify themselves and prove possession of secrets tied to these identities. This document does not prescribe which of these mechanisms to use; details of identity management are left to deployment profiles of Babel over DTLS. 2. Operation of the Protocol Babel over DTLS requires some changes to how Babel operates. First, DTLS is a client-server protocol, while Babel is a peer-to-peer protocol. Second, DTLS can only protect unicast communication, while Babel packets can be sent to both unicast and multicast destinations. 2.1. DTLS Connection Initiation Babel over DTLS operates on a different port than unencrypted Babel. All Babel over DTLS nodes MUST act as DTLS servers on a given UDP port, and MUST listen for unencrypted Babel traffic on another UDP port, which MUST be distinct from the first one. The default port for Babel over DTLS is registered with IANA as the "babel-dtls" port (UDP port TBD, see Section 4), and the port exchanging unencrypted Babel traffic is registered as the "babel" port (UDP port 6696, see Section 5 of [RFC6126bis]). When a Babel node discovers a new neighbour (generally by receiving an unencrypted multicast Babel packet), it compares the neighbour's IP address with its own, using network byte ordering. If a node's address is lower than the recently discovered neighbour's address, it acts as a client and connects to the neighbour. In other words, the node with the lowest address is the DTLS client for this pairwise Decimo, et al. Expires January 1, 2021 [Page 3] Internet-Draft Babel over DTLS June 2020 relationship. As an example, fe80::1:2 is considered lower than fe80::2:1. The node acting as DTLS client initiates its DTLS connection from an ephemeral UDP port. Nodes SHOULD ensure that new client DTLS connections use different ephemeral ports from recently used connections to allow servers to differentiate between the new and old DTLS connections. Alternatively, nodes could use DTLS connection identifiers [DTLS-CID] as a higher-entropy mechanism to distinguish between connections. When a node receives a new DTLS connection, it MUST verify that the source IP address is either an IPv6 link-local address or an IPv4 address belonging to the local network; if it is neither, it MUST reject the connection. Nodes use mutual authentication (authenticating both client and server); clients MUST authenticate servers and servers MUST authenticate clients. Implementations MUST support authenticating peers against a local store of credentials. If either node fails to authenticate its peer against its local policy, it MUST abort the DTLS handshake. The guidance given in [BCP195] MUST be followed to avoid attacks on DTLS. Additionally, nodes MUST only negotiate DTLS version 1.2 or higher. Nodes MUST use DTLS replay protection to prevent attackers from replaying stale information. Nodes SHOULD drop packets that have been reordered by more than two IHU (I Heard You) intervals, to avoid letting attackers make stale information last longer. If a node receives a new DTLS connection from a neighbour to whom it already has a connection, the node MUST NOT discard the older connection until it has completed the handshake of the new one and validated the identity of the peer. 2.2. Protocol Encoding Babel over DTLS sends all unicast Babel packets protected by DTLS. The entire Babel packet, from the Magic byte at the start of the Babel header to the last byte of the Babel packet trailer, is sent protected by DTLS. 2.3. Transmission When sending packets, Babel over DTLS nodes MUST NOT send any TLVs over the unprotected "babel" port, with the exception of Hello TLVs without the Unicast flag set. Babel over DTLS nodes MUST NOT send any unprotected unicast packets. This ensures the confidentiality of the information sent in Babel packets (e.g., the network topology) by only sending it encrypted by DTLS. Unless some out-of-band neighbour discovery mechanism is available, nodes SHOULD periodically send unprotected multicast Hellos to ensure discovery of new neighbours. In order to maintain bidirectional reachability, nodes can either Decimo, et al. Expires January 1, 2021 [Page 4] Internet-Draft Babel over DTLS June 2020 rely entirely on unprotected multicast Hellos, or send protected unicast Hellos in addition to the multicast Hellos. Since Babel over DTLS only protects unicast packets, implementors may implement Babel over DTLS by modifying an implementation of Babel without DTLS support, and replacing any TLV previously sent over multicast with a separate TLV sent over unicast for each neighbour. TLVs previously sent over multicast can be replaced with the same contents over unicast, with the exception of Hellos as described above. Some implementations could also change the contents of IHU TLVs when converting to unicast in order to remove redundant information. 2.4. Reception Babel over DTLS nodes can receive Babel packets either protected over a DTLS connection, or unprotected directly over the "babel" port. To ensure the security properties of this mechanism, unprotected packets are treated differently. Nodes MUST silently ignore any unprotected packet sent over unicast. When parsing an unprotected packet, a node MUST silently ignore all TLVs that are not of type Hello. Nodes MUST also silently ignore any unprotected Hello with the Unicast flag set. Note that receiving an unprotected packet can still be used to discover new neighbours, even when all TLVs in that packet are silently ignored. 2.5. Neighbour table entry It is RECOMMENDED for nodes to associate the state of their DTLS connection with their neighbour table. When a neighbour entry is flushed from the neighbour table (Appendix A of [RFC6126bis]), its associated DTLS state SHOULD be discarded. The node SHOULD send a DTLS close_notify alert to the neighbour if it believes the link is still viable. 2.6. Simultaneous operation of both Babel over DTLS and unprotected Babel on a Node Implementations MAY implement both Babel over DTLS and unprotected Babel. Additionally, a node MAY simultaneously run both Babel over DTLS and unprotected Babel. However, a node running both MUST ensure that it runs them on separate interfaces, as the security properties of Babel over DTLS rely on not accepting unprotected Babel packets (other than multicast Hellos). An implementation MAY offer configuration options to allow unprotected Babel on some interfaces but not others; this effectively gives nodes on that interface the same access as authenticated nodes, and SHOULD NOT be done unless Decimo, et al. Expires January 1, 2021 [Page 5] Internet-Draft Babel over DTLS June 2020 that interface has a mechanism to authenticate nodes at a lower layer (e.g., IPsec). 2.7. Simultaneous operation of both Babel over DTLS and unprotected Babel on a Network If Babel over DTLS and unprotected Babel are both operated on the same network, the Babel over DTLS implementation will receive unprotected multicast Hellos and attempt to initiate a DTLS connection. These connection attempts can be sent to nodes that only run unprotected Babel, who will not respond. Babel over DTLS implementations SHOULD therefore rate-limit their DTLS connection attempts to avoid causing undue load on the network. 3. Interface Maximum Transmission Unit Issues Compared to unprotected Babel, DTLS adds header, authentication tag and possibly block-size padding overhead to every packet. This reduces the size of the Babel payload that can be carried. This document does not relax the packet size requirements in Section 4 of [RFC6126bis], but recommends that DTLS overhead be taken into account when computing maximum packet size. More precisely, nodes SHOULD compute the overhead of DTLS depending on the ciphersuites in use, and SHOULD NOT send Babel packets larger than the interface maximum transmission unit (MTU) minus the overhead of IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the attached interface's MTU adjusted for known lower-layer headers (at least UDP and IP) or 512 octets, whichever is larger, but not exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel speaker MUST be able to receive packets that are as large as any attached interface's MTU adjusted for UDP and IP headers or 512 octets, whichever is larger. Note that this requirement on reception does not take into account the overhead of DTLS because the peer may not have the ability to compute the overhead of DTLS and the packet may be fragmented by lower layers. Note that distinct DTLS connections can use different ciphers, which can have different amounts of per-packet overhead. Therefore, the MTU to one neighbour can be different from the MTU to another neighbour on the same link. 4. IANA Considerations If this document is approved, IANA is requested to register a UDP port number, called "babel-dtls", for use by Babel over DTLS. Details of the request to IANA are as follows: Decimo, et al. Expires January 1, 2021 [Page 6] Internet-Draft Babel over DTLS June 2020 o Assignee: IESG, iesg@ietf.org o Contact Person: IETF Chair, chair@ietf.org o Transport Protocols: UDP only o Service Code: None o Service Name: babel-dtls o Desired Port Number: 6699 o Description: Babel Routing Protocol over DTLS o Reference: This document o Defined TXT Keys: None 5. Security Considerations A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol until the handshake completes and can be obfuscated with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Note that attackers might attempt to keep in- progress handshakes open for as long as possible by using variants on the attack commonly known as Slowloris [SLOWLORIS]. Mitigating these attacks might involve rate limiting handshakes from a given subnet or more advanced denial of service avoidance techniques beyond the scope of this document. Babel over DTLS allows sending multicast Hellos unprotected; attackers can therefore tamper with them. For example, an attacker could send erroneous values for the Seqno and Interval fields, causing bidirectional reachability detection to fail. While implementations MAY use multicast Hellos for link quality estimation, they SHOULD also emit protected unicast Hellos to prevent this class of denial-of-service attack. While DTLS provides protection against an attacker that replays valid packets, DTLS is not able to detect when an active on-path attacker intercepts valid packets and resends them at a later time. This attack could be used to make a node believe it has bidirectional reachability to a neighbour even though that neighbour has disconnected from the network. To prevent this attack, nodes MUST discard the DTLS state associated with a neighbour after a finite time of not receiving valid DTLS packets. This can be implemented by, for example, discarding a neighbour's DTLS state when its Decimo, et al. Expires January 1, 2021 [Page 7] Internet-Draft Babel over DTLS June 2020 associated IHU timer fires. Note that relying solely on the receipt of Hellos is not sufficient as multicast Hellos are sent unprotected. Additionally, an attacker could save some packets and replay them later in hopes of propagating stale routing information at a later time. This can be mitigated by discarding received packets that have been reordered by more than two IHU intervals. 6. References 6.1. Normative References [BCP195] 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6126bis] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", Internet Draft draft-ietf-babel-rfc6126bis-17, February 2020. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [BABEL-HMAC] Do, C., Kolodziejak, W., and J. Chroboczek, "Babel Cryptographic Authentication", Internet Draft draft-ietf- babel-hmac-10, August 2019. [DTLS-CID] Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, "Connection Identifiers for DTLS 1.2", Internet Draft draft-ietf-tls-dtls-connection-id-07, October 2019. Decimo, et al. Expires January 1, 2021 [Page 8] Internet-Draft Babel over DTLS June 2020 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, . [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, . [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . [SLOWLORIS] Hansen, R., "Welcome to Slowloris...", June 2009, . Appendix A. Performance Considerations To reduce the number of octets taken by the DTLS handshake, especially the size of the certificate in the ServerHello (which can be several kilobytes), Babel peers can use raw public keys [RFC7250] or the Cached Information Extension [RFC7924]. The Cached Information Extension avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake. TLS False Start [RFC7918] can reduce round trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) Babel packet. Appendix B. Acknowledgments The authors would like to thank Roman Danyliw, Donald Eastlake, Thomas Fossati, Benjamin Kaduk, Gabriel Kerneis, Mirja Kuehlewind, Antoni Przygienda, Henning Rogge, Dan Romascanu, Barbara Stark, Markus Stenberg, Dave Taht, Martin Thomson, Sean Turner and Martin Vigoureux for their input and contributions. The performance considerations in this document were inspired from the ones for DNS over DTLS [RFC8094]. Decimo, et al. Expires January 1, 2021 [Page 9] Internet-Draft Babel over DTLS June 2020 Authors' Addresses Antonin Decimo IRIF, University of Paris-Diderot Paris France Email: antonin.decimo@gmail.com David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043 USA Email: dschinazi.ietf@gmail.com Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr Decimo, et al. Expires January 1, 2021 [Page 10] ./draft-ietf-ippm-route-10.txt0000644000764400076440000017604213715260450015467 0ustar iustyiusty Network Working Group J. Alvarez-Hamelin Internet-Draft Universidad de Buenos Aires Updates: 2330 (if approved) A. Morton Intended status: Standards Track AT&T Labs Expires: February 14, 2021 J. Fabini TU Wien C. Pignataro Cisco Systems, Inc. R. Geib Deutsche Telekom August 13, 2020 Advanced Unidirectional Route Assessment (AURA) draft-ietf-ippm-route-10 Abstract This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology, based on the IP Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multi- path technologies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 14, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 1] Internet-Draft AURA Metrics & Methods August 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Issues with Earlier Work to Define a Route Metric . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Route Metric Specifications . . . . . . . . . . . . . . . . . 5 3.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 5 3.2. Formal Name . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Metric Definitions . . . . . . . . . . . . . . . . . . . 7 3.5. Related Round-Trip Delay and Loss Definitions . . . . . . 9 3.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Reporting the Metric . . . . . . . . . . . . . . . . . . 10 4. Route Assessment Methodologies . . . . . . . . . . . . . . . 11 4.1. Active Methodologies . . . . . . . . . . . . . . . . . . 11 4.1.1. Temporal Composition for Route Metrics . . . . . . . 13 4.1.2. Routing Class Identification . . . . . . . . . . . . 15 4.1.3. Intermediate Observation Point Route Measurement . . 16 4.2. Hybrid Methodologies . . . . . . . . . . . . . . . . . . 16 4.3. Combining Different Methods . . . . . . . . . . . . . . . 17 5. Background on Round-Trip Delay Measurement Goals . . . . . . 17 6. RTD Measurements Statistics . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. Appendix I MPLS Methods for Route Assessment . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction The IETF IP Performance Metrics (IPPM) working group first created a framework for metric development in [RFC2330]. This framework has stood the test of time and enabled development of many fundamental metrics. It has been updated in the area of metric composition Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 2] Internet-Draft AURA Metrics & Methods August 2020 [RFC5835], and in several areas related to active stream measurement of modern networks with reactive properties [RFC7312]. The [RFC2330] framework motivated the development of "performance and reliability metrics for paths through the Internet," and Section 5 of [RFC2330] defines terms that support description of a path under test. However, metrics for assessment of paths and related performance aspects had not been attempted in IPPM when the [RFC2330] framework was written. This memo takes up the route measurement challenge and specifies a new route metric, two practical frameworks for methods of measurement (using either active or hybrid active-passive methods [RFC7799]), and Round-Trip Delay and link information discovery using the results of measurements. All route measurements are limited by the willingness of hosts along the path to be discovered, to cooperate with the methods used, or to recognize that the measurement operation is taking place (such as when tunnels are present). 1.1. Issues with Earlier Work to Define a Route Metric Section 7 of [RFC2330] presented a simple example of a "route" metric along with several other examples. The example is reproduced below (where the reference is to Section 5 of [RFC2330]): "route: The path, as defined in Section 5, from A to B at a given time." This example provides a starting point to develop a more complete definition of route. Areas needing clarification include: Time: In practice, the route will be assessed over a time interval, because active path detection methods like Paris Traceroute [PT] rely on hop limits for their operation and cannot accomplish discovery of all hosts using a single packet. Type-P: The legacy route definition lacks the option to cater for packet-dependent routing. In this memo, we assess the route for a specific packet of Type-P, and reflect this in the metric definition. The methods of measurement determine the specific Type-P used. Parallel Paths: Parallel paths are a reality of the Internet and a strength of advanced route assessment methods, so the metric must acknowledge this possibility. Use of Equal Cost Multi-Path (ECMP) and Unequal Cost Multi-Path (UCMP) technologies are common sources of parallel subpaths. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 3] Internet-Draft AURA Metrics & Methods August 2020 Cloud Subpath: May contain hosts that do not decrement hop limit, but may have two or more exchange links connecting "discoverable" hosts or routers. Parallel subpaths contained within clouds cannot be discovered. The assessment methods only discover hosts or routers on the path that decrement hop limit, or cooperate with interrogation protocols. The presence of tunnels and nested tunnels further complicate assessment by hiding hops. Hop: Although the [RFC2330] definition of a hop was a link-host pair, only hosts that are discoverable or have the capability to cooperate with interrogation protocols where link information may be exposed. The refined definition of Route metrics begins in the sections that follow. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Scope The purpose of this memo is to add new route metrics and methods of measurement to the existing set of IPPM metrics. The scope is to define route metrics that can identify the path taken by a packet or a flow traversing the Internet between two hosts. Although primarily intended for hosts communicating on the Internet, the definitions and metrics are constructed to be applicable to other network domains, if desired. The methods of measurement to assess the path may not be able to discover all hosts comprising the path, but such omissions are often deterministic and explainable sources of error. This memo also specifies a framework for active methods of measurement which uses the techniques described in [PT], as well as a framework for hybrid active-passive methods of measurement such as the Hybrid Type I method [RFC7799] described in [I-D.ietf-ippm-ioam-data]. Methods using [I-D.ietf-ippm-ioam-data] are intended only for single administrative domains that provide a protocol for explicit interrogation of nodes on a path. Combinations of active methods and hybrid active-passive methods are also in- scope. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 4] Internet-Draft AURA Metrics & Methods August 2020 Further, this memo provides additional analysis of the round-trip delay measurements made possible by the methods, in an effort to discover more details about the path, such as the link technology in use. This memo updates Section 5 of [RFC2330] in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination address pair (possibly resulting from Equal Cost Multi- Path (ECMP) and Unequal Cost Multi-Path (UCMP) technologies). There are several simple non-goals of this memo. There is no attempt to assess the reverse path from any host on the path to the host attempting the path measurement. The reverse path contribution to delay will be that experienced by ICMP packets (in active methods), and may be different from delays experienced by UDP or TCP packets. Also, the round trip delay will include an unknown contribution of processing time at the host that generates the ICMP response. Therefore, the ICMP-based active methods are not supposed to yield accurate, reproducible estimations of the Round-Trip Delay that UDP or TCP packets will experience. 3. Route Metric Specifications This section sets requirements for the components of the Route Metric. 3.1. Terms and Definitions Host A Host as defined in [RFC2330] (a computer capable of IP communication, includes routers), a.k.a. RFC 2330 Host. Node A Node is any network function on the path capable of IP-layer Communication, includes RFC 2330 Hosts. Node Identity The unique address for Nodes communicating within the network domain. For Nodes communicating on the Internet with IP, it is the globally routable IP address which the Node uses when communicating with other Nodes under normal or error conditions. The Node Identity revealed (and its connection to a Node Name through reverse DNS) determines whether interfaces to parallel links can be associated with a single Node, or appear to identify unique Nodes. Discoverable Node Nodes that convey their Node Identity according to the requirements of their network domain, such as when error conditions are detected by that Node. For Nodes communicating with IP packets, compliance with Section 3.2.2.4 of [RFC1122] when Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 5] Internet-Draft AURA Metrics & Methods August 2020 discarding a packet due to TTL or Hop Limit Exceeded condition, MUST result in sending the corresponding Time Exceeded message (containing a form of Node identity) to the source. This requirement is also consistent with section 5.3.1 of [RFC1812] for routers. Cooperating Node Nodes that respond to direct queries for their Node identity as part of a previously agreed and established interrogation protocol. Nodes SHOULD also provide information such as arrival/departure interface identification, arrival timestamp, and any relevant information about the Node or specific link which delivered the query to the Node. Hop specification A Hop specification MUST contain a Node Identity, and MAY contain arrival and/or departure interface identification, round trip delay, and an arrival timestamp. Routing Class A route that treats equally a class of different types of packets, designated "C" (unrelated to address classes of the past) [RFC2330] [RFC8468]. Knowledge of such a class allows any one of the types of packets within that class to be used for subsequent measurement of the route. The designator "class C" is used for historical reasons, see [RFC2330]. 3.2. Formal Name The formal name of the metric is: Type-P-Route-Ensemble-Method-Variant abbreviated as Route Ensemble. Note that Type-P depends heavily on the chosen method and variant. 3.3. Parameters This section lists the REQUIRED input factors to define and measure a Route metric, as specified in this memo. o Src, the address of a Node (such as the globally routable IP address). o Dst, the address of a Node (such as the globally routable IP address). o i, the limit on the number of Hops a specific packet may visit as it traverses from the Node at Src to the Node at Dst (such as the TTL or Hop Limit). Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 6] Internet-Draft AURA Metrics & Methods August 2020 o MaxHops, the maximum value of i used, (i=1,2,3,...MaxHops). o T0, a time (start of measurement interval) o Tf, a time (end of measurement interval) o MP(address), Measurement Point at address, such as Src or Dst, usually at the same node stack layer as "address". o T, the Node time of a packet as measured at MP(Src), meaning Measurement Point at the Source. o Ta, the Node time of a reply packet's *arrival* as measured at MP(Src), assigned to packets that arrive within a "reasonable" time (see parameter below). o Tmax, a maximum waiting time for reply packets to return to the source, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost), such that the distribution of Round-Trip Delay is not truncated. o F, the number of different flows simulated by the method and variant. o flow, the stream of packets with the same n-tuple of designated header fields that (when held constant) result in identical treatment in a multi-path decision (such as the decision taken in load balancing). Note: The IPv6 flow label MAY be included in the flow definition if the MP(Src) is a Tunnel End Point (TEP) complying with [RFC6438] guidelines. o Type-P, the complete description of the packets for which this assessment applies (including the flow-defining fields). 3.4. Metric Definitions This section defines the REQUIRED measurement components of the Route metrics (unless otherwise indicated): M, the total number of packets sent between T0 and Tf. N, the smallest value of i needed for a packet to be received at Dst (sent between T0 and Tf). Nmax, the largest value of i needed for a packet to be received at Dst (sent between T0 and Tf). Nmax may be equal to N. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 7] Internet-Draft AURA Metrics & Methods August 2020 Next define a *singleton* definition for a Node on the path, with sufficient indexes to identify all Nodes identified in a measurement interval (where *singleton* is part of the IPPM Framework [RFC2330]). A Hop Specification, designated h(i,j), the IP address and/or identity of Discoverable Nodes (or Cooperating Nodes) that are i hops away from the Node with address = Src and part of Route j during the measurement interval, T0 to Tf. As defined here, a Hop singleton measurement MUST contain a Node Identity, hid(i,j), and MAY contain one or more of the following attributes: o a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported) o d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported) o t(i,j) Arrival Timestamp, where t(i,j) is ideally supplied by the Hop. (Note that t(i,j) might be approximated from the sending time of the packet that revealed the Hop, e.g., when the round trip response time is available and divided by 2.) o Measurements of Round-Trip Delay (for each packet that reveals the same Node Identity and flow attributes, then this attribute is computed, see next section) Node Identities and related information can be ordered by their distance from the Node with address Src in Hops h(i,j). Based on this, two forms of Routes are distinguished: A Route Ensemble is defined as the combination of all routes traversed by different flows from the Node at Src address to the Node at Dst address. A single Route traversed by a single flow (determined by an unambiguous tuple of addresses Src and Dst, and other identical flow criteria) is a member of the Route Ensemble and called a Member Route. Using h(i,j) and components and parameters, further define: When considering the set of Hops in the context of a single flow, a Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1, j) and h(i, j) are 1 hop away from each other and Nj satisfying h(Nj,j)=Dst is the minimum count of Hops needed by the packet on Member Route j to reach Dst. Member Routes must be unique. The uniqueness property requires that any two Member routes j and k that are part of the same Route Ensemble differ either in terms of minimum hop count Nj and Nk to reach the destination Dst, or, in the case of identical hop count Nj=Nk, they have at least one distinct Hop: h(i,j) != h(i,k) for at least one i (i=1..Nj). Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 8] Internet-Draft AURA Metrics & Methods August 2020 All the optional information collected to describe a Member Route, such as the arrival interface, departure interface, and Round Trip Delay at each Hop, turns each list item into a rich structure. There may be information on the links between Hops, possibly information on the routing (arrival interface and departure interface), an estimate of distance between Hops based on Round-Trip Delay measurements and calculations, and a time stamp indicating when all these additional details were valid. The Route Ensemble from Src to Dst, during the measurement interval T0 to Tf, is the aggregate of all m distinct Member Routes discovered between the two Nodes with Src and Dst addresses. More formally, with the Node having address Src omitted: Route Ensemble = { {h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst}, {h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst}, ... {h(1,m), h(2,m), h(3,m), ....h(Nm,m)=Dst} } where the following conditions apply: i <= Nj <= Nmax (j=1..m) Note that some h(i,j) may be empty (null) in the case that systems do not reply (not discoverable, or not cooperating). h(i-1,j) and h(i,j) are the Hops on the same Member Route one hop away from each other. Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l ; which means there may be portions shared among different Member Routes (parts of Member Routes may overlap). 3.5. Related Round-Trip Delay and Loss Definitions RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-Trip Delay between the Node with address = Src and the Node at Hop h(i,j) at time T. RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-trip Loss between the Node with address = Src and the Node at Hop h(i,j) at time T. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 9] Internet-Draft AURA Metrics & Methods August 2020 3.6. Discussion Depending on the way that Node Identity is revealed, it may be difficult to determine parallel subpaths between the same pair of Nodes (i.e. multiple parallel links). It is easier to detect parallel subpaths involving different Nodes. o If a pair of discovered Nodes identify two different addresses (IP or not), then they will appear to be different Nodes. See item below. o If a pair of discovered Nodes identify two different IP addresses, and the IP addresses resolve to the same Node name (in the DNS), then they will appear to be the same Nodes. o If a discovered Node always replies using the same network address, regardless of the interface a packet arrives on, then multiple parallel links cannot be detected in that network domain. This condition may apply to traceroute-style methods, but may not apply to other hybrid methods based on In-situ Operations, Administration, and Maintenance (IOAM). For example, if the [RFC5837] ICMP extension mechanism is implemented, then parallel links can be detected with the discovery traceroute-style methods. o If parallel links between routers are aggregated below the IP layer, then from Node point of view, all these links share the same pair of IP addresses. The existence of these parallel links can't be detected at the IP layer. This applies to other network domains with layers below them, as well. This condition may apply to traceroute-style methods, but may not apply to other hybrid methods based on IOAM. When a route assessment employs IP packets (for example), the reality of flow assignment to parallel subpaths involves layers above IP. Thus, the measured Route Ensemble is applicable to IP and higher layers (as described in the methodology's packet of Type-P and flow parameters). 3.7. Reporting the Metric An Information Model and an XML Data Model for Storing Traceroute Measurements is available in [RFC5388]. The measured information at each hop includes four pieces of information: a one-dimensional hop index, Node symbolic address, Node IP address, and RTD for each response. The description of Hop information that may be collected according to this memo covers more dimensions, as defined in Section 3.4 above. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 10] Internet-Draft AURA Metrics & Methods August 2020 For example, the Hop index is two-dimensional to capture the complexity of a Route Ensemble, and it contains corresponding Node identities at a minimum. The models need to be expanded to include these features, as well as Arrival Interface ID, Departure Interface ID, and Arrival Timestamp, when available. The original sending Timestamp from the Src Node anchors a particular measurement in time. 4. Route Assessment Methodologies There are two classes of methods described in this section, active methods relying on the reaction to TTL or Hop Limit Exceeded condition to discover Nodes on a path, and Hybrid active-passive methods that involve direct interrogation of cooperating Nodes (usually within a single domain). Description of these methods follow. 4.1. Active Methodologies This section describes the method employed by current open source tools, thereby providing a practical framework for further advanced techniques to be included as method variants. This method is applicable for use across multiple administrative domains. Internet routing is complex because it depends on the policies of thousands of Autonomous Systems (AS). Most routers perform load balancing on flows using a form of Equal Cost Multiple Path (ECMP). [RFC2991] describes a number of flow-based or hashed approaches (e.g., Modulo-N Hash, Hash-Threshold, Highest Random Weight (HRW)), and makes some good suggestions. Flow-based ECMP avoids increased packet delay variation and possibly overwhelming levels of packet reordering in flows. A few routers still divide the workload through packet-based techniques, such as a round-robin scheme to distribute every new outgoing packet to multiple links, as explained in [RFC2991]. The methods described in this section assume flow-based ECMP. Taking into account that Internet protocol was designed under the "end-to-end" principle, the IP payload and its header do not provide any information about the routes or path necessary to reach some destination. For this reason, the popular tool traceroute was developed to gather the IP addresses of each hop along a path using the ICMP protocol [RFC0792]. Traceroute also measures RTD from each hop. However, the growing complexity of the Internet makes it more challenging to develop an accurate traceroute implementation. For instance, the early traceroute tools would be inaccurate in the current network, mainly because they were not designed to retain a flow state. However, evolved traceroute tools, such as Paris- Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 11] Internet-Draft AURA Metrics & Methods August 2020 traceroute [PT] [MLB] and Scamper [SCAMPER], expect to encounter ECMP and achieve more accurate results when they do, where Scamper ensures traceroute packets will follow the same path in 98% of cases[SCAMPER]. Today's traceroute tools send Type-P of packets, either ICMP, UDP, or TCP. UDP and TCP are used when a particular characteristic needs to be verified, such as filtering or traffic shaping on specific ports (i.e., services). UDP and TCP traceroute are also used when ICMP responses are not received. [SCAMPER] supports IPv6 traceroute measurements, keeping the FlowLabel constant in all packets. Paris-traceroute allows its users to measure the RTD to every Node of the path for a particular flow. Furthermore, either Paris-traceroute or Scamper is capable of unveiling the many available paths between a source and destination (which are visible to active methods). This task is accomplished by repeating complete traceroute measurements with different flow parameters for each measurement; Paris-traceroute provides "exhaustive" mode while scamper provides "tracelb" (stands for traceroute load balance). The Framework for IP Performance Metrics (IPPM) ([RFC2330] updated by[RFC7312]) has the flexibility to require that the Round-Trip Delay measurement [RFC2681] uses packets with the constraints to assure that all packets in a single measurement appear as the same flow. This flexibility covers ICMP, UDP, and TCP. The accompanying methodology of [RFC2681] needs to be expanded to report the sequential hop identifiers along with RTD measurements, but no new metric definition is needed. The advanced route assessment methods used in Paris-traceroute [PT] keep the critical fields constant for every packet to maintain the appearance of the same flow. When considering IPv6 headers, it is necessary to ensure that the IP source and destination addresses and the FlowLabel are constant (but note that many routers ignore the FlowLabel field at this time), see [RFC6437]. Use of IPv6 Extension Headers may add critical fields, and SHOULD be avoided. In IPv4, certain fields of the IP header and the first four bytes of the IP payload should remain constant in a flow. In the IPv4 header, the IP source and destination addresses, protocol number, and Diffserv fields identify flows. The first four payload bytes include the UDP and TCP ports, and the ICMP type, code, and checksum fields. Maintaining a constant ICMP checksum in IPv4 is most challenging, as the ICMP sequence number or identifier fields will usually change for different probes of the same path. Probes should use arbitrary bytes in the ICMP data field to offset changes to sequence number and identifier, thus keeping the checksum constant. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 12] Internet-Draft AURA Metrics & Methods August 2020 Finally, it is also essential to route the resulting ICMP Time Exceeded messages along a consistent path. In IPv6, the fields above are sufficient. In IPv4, the ICMP Time Exceeded message will contain the IP header and the first eight bytes of the IP payload, which affects its ICMP checksum. The TCP sequence number, UDP Length, and UDP checksum will affect this value, and should remain constant. Formally, to maintain the same flow in the measurements to a particular hop, the Type-P-Route-Ensemble-Method-Variant packets should be[PT]: o TCP case: For IPv4, the fields Src, Dst, port-Src, port_Dst, sequence number, and Diffserv Field SHOULD be the same. For IPv6, the field FlowLabel, Src and Dst SHOULD be the same. o UDP case: For IPv4, the fields Src, Dst, port-Src, port-Dst, Diffserv should be the same, and the UDP-checksum SHOULD change to keep the IP checksum of the ICMP time exceeded reply constant. Then, the data length should be fixed, and the data field is used to make it so (consider that ICMP checksum uses its data field, which contains the original IP header plus 8 bytes of UDP, where TTL, IP identification, IP checksum, and UDP checksum changes). For IPv6, the field FlowLabel, and Source and Destination addresses SHOULD be the same. o ICMP case: For IPv4, the Data field SHOULD compensate variations on TTL or Hop Limit, IP identification, and IP checksum for every packet. There is no need to consider ICMPv6 because only FlowLabel of IPv6 and Source and Destination addresses are used, and all of them SHOULD be constant. Then, the way to identify different hops and attempts of the same IPv4 flow is: o TCP case: The IP identification field. o UDP case: The IP identification field. o ICMP case: The IP identification field, and ICMP Sequence number. 4.1.1. Temporal Composition for Route Metrics The Active Route Assessment Methods described above have the ability to discover portions of a path where ECMP load balancing is present, observed as two or more unique Member Routes having one or more distinct Hops which are part of the Route Ensemble. Likewise, attempts to deliberately vary the flow characteristics to discover Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 13] Internet-Draft AURA Metrics & Methods August 2020 all Member Routes will reveal portions of the path which are flow- invariant. Section 9.2 of [RFC2330] describes Temporal Composition of metrics, and introduces the possibility of a relationship between earlier measurement results and the results for measurement at the current time (for a given metric). There is value in establishing a Temporal Composition relationship for Route Metrics. However, this relationship does not represent a forecast of future route conditions in any way. For Route Metric measurements, the value of Temporal Composition is to reduce the measurement iterations required with repeated measurements. Reduced iterations are possible by inferring that current measurements using fixed and previously measured flow characteristics: o will have many common hops with previous measurements. o will have relatively time-stable results at the ingress and egress portions of the path when measured from user locations, as opposed to measurements of backbone networks and across inter-domain gateways. o may have greater potential for time-variation in path portions where ECMP load balancing is observed (because increasing or decreasing the pool of links changes the hash calculations). Optionally, measurement systems may take advantage of the inferences above when seeking to reduce measurement iterations, after exhaustive measurements indicate that the time-stable properties are present. Repetitive Active Route measurement systems: 1. SHOULD occasionally check path portions which have exhibited stable results over time, particularly ingress and egress portions of the path (e.g., daily checks if measuring many times during a day). 2. SHOULD continue testing portions of the path that have previously exhibited ECMP load balancing. 3. SHALL trigger re-assessment of the complete path and Route Ensemble, if any change in hops is observed for a specific (and previously tested) flow. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 14] Internet-Draft AURA Metrics & Methods August 2020 4.1.2. Routing Class Identification There is an opportunity to apply the [RFC2330] notion of equal treatment for a class of packets, "...very useful to know if a given Internet component treats equally a class C of different types of packets", as it applies to Route measurements. The notion of class C was examined further in [RFC8468] as it applied to load-balancing flows over parallel paths, which is the case we develop here. Knowledge of class C parameters (unrelated to address classes of the past) on a path potentially reduces the number of flows required for a given method to assess a Route Ensemble over time. First, recognize that each Member Route of a Route Ensemble will have a corresponding class C. Class C can be discovered by testing with multiple flows, all of which traverse the unique set of hops that comprise a specific Member Route. Second, recognize that the different classes depend primarily on the hash functions used at each instance of ECMP load balancing on the path. Third, recognize the synergy with Temporal Composition methods (described above), where evaluation intends to discover time-stable portions of each Member Route, so that more emphasis can be placed on ECMP portions that also determine class C. The methods to assess the various class C characteristics benefit from the following measurement capabilities: o flows designed to determine which n-tuple header fields are considered by a given hash function and ECMP hop on the path, and which are not. This operation immediately narrows the search space, where possible, and partially defines a class C. o a priori knowledge of the possible types of hash functions in use also helps to design the flows for testing (major router vendors publish information about these hash functions, examples are here [LOAD_BALANCE]. o ability to direct the emphasis of current measurements on ECMP portions of the path, based on recent past measurement results (the Routing Class of some portions of the path is essentially "all packets"). Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 15] Internet-Draft AURA Metrics & Methods August 2020 4.1.3. Intermediate Observation Point Route Measurement There are many examples where passive monitoring of a flow at an Observation Point within the network can detect unexpected Round Trip Delay or Delay Variation. But how can the cause of the anomalous delay be investigated further *from the Observation Point* possibly located at an intermediate point on the path? In this case, knowledge that the flow of interest belongs to a specific Routing Class C will enable measurement of the route where anomalous delay has been observed. Specifically, Round-Trip Delay assessment to each Hop on the path between the Observation Point and the Destination for the flow of interest may discover high or variable delay on a specific link and Hop combination. The determination of a Routing Class C which includes the flow of interest is as described in the section above, aided by computation of the relevant hash function output as the target. 4.2. Hybrid Methodologies The Hybrid Type I methods provide an alternative method for Route Member assessment. As mentioned in the Scope section, [I-D.ietf-ippm-ioam-data] provides a possible set of data fields that would support route identification. In general, nodes in the measured domain would be equipped with specific abilities: o Store the identity of nodes that a packet has visited in header data fields, in the order the packet visited the nodes. o Support of a "Loopback" capability, where a copy of the packet is returned to the encapsulating node, and the packet is processed like any other IOAM packet on the return transfer. In addition to node identity, nodes may also identify the ingress and egress interfaces utilized by the tracing packet, the absolute time when the packet was processed, and other generic data (as described in section 4 of [I-D.ietf-ippm-ioam-data]). Interface identification isn't necessarily limited to IP, i.e. different links in a bundle (LACP) could be identified. Equally well, links without explicit IP addresses can be identified (like with unnumbered interfaces in an IGP deployment). Note that the Type-P packet specification for this method will likely be a partial specification, because most of the packet fields are determined by the user traffic. The packet (encapsulation) header(s) Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 16] Internet-Draft AURA Metrics & Methods August 2020 added by the Hybrid method can certainly be specified in Type-P, in unpopulated form. 4.3. Combining Different Methods In principle, there are advantages if the entity conducting Route measurements can utilize both forms of advanced methods (active and hybrid), and combine the results. For example, if there are Nodes involved in the path that qualify as Cooperating Nodes, but not as Discoverable Nodes, then a more complete view of Hops on the path is possible when a hybrid method (or interrogation protocol) is applied and the results are combined with the active method results collected across all other domains. In order to combine the results of active and hybrid/interrogation methods, the network Nodes that are part of a domain supporting an interrogation protocol have the following attributes: 1. Nodes at the ingress to the domain SHOULD be both Discoverable and Cooperating. 2. Any Nodes within the domain that are both Discoverable and Cooperating SHOULD reveal the same Node Identity in response to both active and hybrid methods. 3. Nodes at the egress to the domain SHOULD be both Discoverable and Cooperating, and SHOULD reveal the same Node Identity in response to both active and hybrid methods. When Nodes follow these requirements, it becomes a simple matter to match single domain measurements with the overlapping results from a multidomain measurement. In practice, Internet users do not typically have the ability to utilize the OAM capabilities of networks that their packets traverse, so the results from a remote domain supporting an interrogation protocol would not normally be accessible. However, a network operator could combine interrogation results from their access domain with other measurements revealing the path outside their domain. 5. Background on Round-Trip Delay Measurement Goals The aim of this method is to use packet probes to unveil the paths between any two end-Nodes of the network. Moreover, information derived from RTD measurements might be meaningful to identify: 1. Intercontinental submarine links Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 17] Internet-Draft AURA Metrics & Methods August 2020 2. Satellite communications 3. Congestion 4. Inter-domain paths This categorization is widely accepted in the literature and among operators alike, and it can be trusted with empirical data and several sources as ground of truth (e.g., [RTTSub] ) but it is an inference measurement nonetheless [bdrmap][IDCong]. The first two categories correspond to the physical distance dependency on Round-Trip Delay (RTD), the next one binds RTD with queuing delay on routers, and the last one helps to identify different ASes using traceroutes. Due to the significant contribution of propagation delay in long-distance hops, RTD will be on the order of 100ms on transatlantic hops, depending on the geolocation of the vantage points. Moreover, RTD is typically higher than 480ms when two hops are connected using geostationary satellite technology (i.e., their orbit is at 36000km). Detecting congestion with latency implies deeper mathematical understanding since network traffic load is not stationary. Nonetheless, as the first approach, a link seems to be congested if observing different/varying statistical results after sending several traceroute probes (e.g., see [IDCong]). Finally, to recognize distinctive ASes in the same traceroute path is challenging, because more data is needed, like AS relationships and RIR delegations among other (for more detail, please consult [bdrmap]). 6. RTD Measurements Statistics Several articles have shown that network traffic presents a self- similar nature [SSNT] [MLRM] which is accountable for filling the queues of the routers. Moreover, router queues are designed to handle traffic bursts, which is one of the most remarkable features of self-similarity. Naturally, while queue length increases, the delay to traverse the queue increases as well and leads to an increase on RTD. Due to traffic bursts generating short-term overflow on buffers (spiky patterns), every RTD only depicts the queueing status on the instant when that packet probe was in transit. For this reason, several RTD measurements during a time window could begin to describe the random behavior of latency. Loss must also be accounted for in the methodology. To understand the ongoing process, examining the quartiles provides a non-parametric way of analysis. Quartiles are defined by five values: minimum RTD (m), RTD value of the 25% of the Empirical Cumulative Distribution Function (ECDF) (Q1), the median value (Q2), Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 18] Internet-Draft AURA Metrics & Methods August 2020 the RTD value of the 75% of the ECDF (Q3) and the maximum RTD (M). Congestion can be inferred when RTD measurements are spread apart, and consequently, the Inter-Quartile Range (IQR), the distance between Q3 and Q1, increases its value. This procedure requires the algorithm presented in [P2] to compute quartile values "on the fly". This procedure allows us to update the quartiles value whenever a new measurement arrives, which is radically different from classic methods of computing quartiles because they need to use the whole dataset to compute the values. This way of calculus provides savings in memory and computing time. To sum up, the proposed measurement procedure consists of performing traceroutes several times to obtain samples of the RTD in every hop from a path, during a time window (W), and compute the quartiles for every hop. This procedure could be done for a single Member Route flow, a non-exhaustive search with parameter E (defined below) set as False, or for every detected Route Ensemble flow (E=True). The identification of a specific Hop in traceroute is based on the IP origin address of the returned ICMP Time Exceeded packet, and on the distance identified by the value set in the TTL (or Hop Limit) field inserted by traceroute. As this specific Hop can be reached by different paths, also the IP source and destination addresses of the traceroute packet need to be recorded. Finally, different return paths are distinguished by evaluating the ICMP Time Exceeded TTL (or Hop Limit) of the reply message: if this TTL (or Hop Limit) is constant for different paths containing the same Hop, the return paths have the same distance. Moreover, this distance can be estimated considering that the TTL (or Hop Limit) value is normally initialized with values 64, 128, or 255. The 5-tuple (origin IP, destination IP, reply IP, distance, response TTL or Hop Limit) unequivocally identifies every measurement. This algorithm below runs in the origin of the traceroute. It returns the Qs quartiles for every Hop and Alt (alternative paths because of balancing). Notice that the "Alt" parameter condenses the parameters of the 5-tuple (origin IP, destination IP, reply IP, distance, response TTL), i.e., one for each possible combination. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 19] Internet-Draft AURA Metrics & Methods August 2020 ================================================================ 0 input: W (window time of the measurement) 1 i_t (time between two measurements, set the i_t time 2 long enough to avoid incomplete results) 3 E (True: exhaustive, False: a single path) 4 Dst (destination IP address) 5 output: Qs (quartiles for every Hop and Alt) ---------------------------------------------------------------- 6 T := start_timer(W) 7 while T is not finished do: 8 | start_timer(i_t) 9 | RTD(Hop,Alt) = advanced-traceroute(Dst,E) 10 | for each Hop and Alt in RTD do: 11 | | Qs[Dst,Hop,Alt] := ComputeQs(RTD(Hop,Alt)) 12 | done 13 | wait until i_t timer is expired 14 done 15 return (Qs) ================================================================ During the time W, lines 6 and 7 assure that the measurement loop is made. Line 8 and 13 set a timer for each cycle of measurements. A cycle comprises the traceroutes packets, considering every possible Hop and the alternatives paths in the Alt variable (ensured in lines 9-12). In line 9, the advance-traceroute could be either Paris- traceroute or Scamper, which will use the "exhaustive" mode or "tracelb" option if E is set True, respectively. The procedure returns a list of tuples (m,Q1,Q2,Q3,M) for each intermediate hop, or "Alt" in as a function of the 5-tuple, in the path towards the Dst. Finally, lines 10 through 12 stores each measurement into the real- time quartiles computation. Notice there are cases where the even having a unique hop at distance h from the Src to Dst, the returning path could have several possibilities, yielding in different total paths. In this situation, the algorithm will return more "Alt" for this particular hop. 7. Security Considerations The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357]. The active measurement process of "changing several fields to keep the checksum of different packets identical" does not require special security considerations because it is part of synthetic traffic generation, and is designed to have minimal to zero impact on network processing (to process the packets for ECMP). Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 20] Internet-Draft AURA Metrics & Methods August 2020 Some of the protocols used (e.g., ICMP) do not provide cryptographic protection for the requested/returned data, and there are risks of processing untrusted data in general, but these are limitations of the existing protocols where we are applying new methods. For applicable Hybrid methods, the security considerations in[I-D.ietf-ippm-ioam-data] apply. When considering privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques which are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large Scale Measurement of Broadband Performance (LMAP) Framework [RFC7594], which covers active and passive techniques. 8. IANA Considerations This memo makes no requests of IANA. We thank the good folks at IANA for having checked this section anyway. 9. Acknowledgements The original 3 authors (Ignacio, Al, Joachim) acknowledge Ruediger Geib, for his penetrating comments on the initial draft, and his initial text for the Appendix on MPLS. Carlos Pignataro challenged the authors to consider a wider scope, and applied his substantial expertise with many technologies and their measurement features in his extensive comments. Frank Brockners also shared useful comments, so did Footer Foote. We thank them all! 10. Appendix I MPLS Methods for Route Assessment A Node assessing an MPLS path must be part of the MPLS domain where the path is implemented. When this condition is met, RFC 8029 provides a powerful set of mechanisms to detect "correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane" [RFC8029]. MPLS routing is based on the presence of a Forwarding Equivalence Class (FEC) Stack in all visited Nodes. Selecting one of several Equal Cost Multi Path (ECMP) is however based on information hidden deeper in the stack. Late deployments may support a so called "Entropy label" for this purpose. State of the art deployments base their choice of an ECMP member interface on the complete MPLS label stack and on IP addresses up to the complete 5 tuple IP header information (see Section 2.4 of [RFC7325]). Load Sharing based on IP Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 21] Internet-Draft AURA Metrics & Methods August 2020 information decouples this function from the actual MPLS routing information. Thus, an MPLS traceroute is able to check how packets with a contiguous number of ECMP relevant IP addresses (and an identical MPLS label stack) are forwarded by a particular router. The minimum number of equivalent MPLS paths traceable at a router should be 32. Implementations supporting more paths are available. The MPLS echo request and reply messages offering this feature must support the Downstream Detailed Mapping TLV (was Downstream Mapping initially, but the latter has been deprecated). The MPLS echo response includes the incoming interface where a router received the MPLS Echo request. The MPLS Echo reply further informs which of the n addresses relevant for the load sharing decision results in a particular next hop interface and contains the next hop's interface address (if available). This ensures that the next hop will receive a properly coded MPLS Echo request in the next step route of assessment. [RFC8403] explains how a central Path Monitoring System could be used to detect arbitrary MPLS paths between any routers within a single MPLS domain. The combination of MPLS forwarding, Segment Routing and MPLS traceroute offers a simple architecture and a powerful mechanism to detect and validate (segment routed) MPLS paths. 11. References 11.1. Normative References [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in progress), July 2020. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 22] Internet-Draft AURA Metrics & Methods August 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, . [RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., and M. Swany, "Information Model and XML Data Model for Traceroute Measurements", RFC 5388, DOI 10.17487/RFC5388, December 2008, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 23] Internet-Draft AURA Metrics & Methods August 2020 [RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, . 11.2. Informative References [bdrmap] Luckie, M., Dhamdhere, A., Huffaker, B., Clark, D., and KC. Claffy, "bdrmap: Inference of Borders Between IP Networks", In Proceedings of the 2016 ACM on Internet Measurement Conference, pp. 381-396. ACM, 2016. [IDCong] Luckie, M., Dhamdhere, A., Clark, D., and B. Huffaker, "Challenges in inferring Internet interdomain congestion", In Proceedings of the 2014 Conference on Internet Measurement Conference, pp. 15-22. ACM, 2014. [LOAD_BALANCE] Sanguanpong, S., Pittayapitak, W., and K. Kasom Koht-Arsa, "COMPARISON OF HASH STRATEGIES FOR FLOW-BASED LOAD BALANCING", International Journal of Electronic Commerce Studies, Vol.6, No.2, pp.259-268. http://dx.doi.org/10.7903/ijecs.1346, 2015. [MLB] Augustin, B., Friedman, T., and R. Teixeira, "Measuring load-balanced paths in the Internet", Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, pp. 149-160. ACM, 2007., 2007. [MLRM] Fontugne, R., Mazel, J., and K. Fukuda, "An empirical mixture model for large-scale RTT measurements", 2015 IEEE Conference on Computer Communications (INFOCOM), pp. 2470-2478. IEEE, 2015., 2015. [P2] Jain, R. and I. Chlamtac, "The P 2 algorithm for dynamic calculation of quartiles and histograms without storing observations", Communications of the ACM 28.10 (1985): 1076-1085, 2015. [PT] Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., Friedman, T., Latapy, M., Magnien, C., and R. Teixeira, "Avoiding traceroute anomalies with Paris traceroute", Proceedings of the 6th ACM SIGCOMM conference on Internet measurement, pp. 153-158. ACM, 2006., 2006. Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 24] Internet-Draft AURA Metrics & Methods August 2020 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 2010, . [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, April 2010, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, . [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, . [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, . Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 25] Internet-Draft AURA Metrics & Methods August 2020 [RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of Cuba: Characterizing Cuba's connectivity", In Proceedings of the 2015 ACM Conference on Internet Measurement Conference, pp. 487-493. ACM, 2015. [SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible packet prober for active measurement of the Internet", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, pp. 239-245. ACM, 2010., 2010. [SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic and Performance Evaluation (1st ed.)", John Wiley & Sons, Inc., New York, NY, USA, 2000. Authors' Addresses J. Ignacio Alvarez-Hamelin Universidad de Buenos Aires Av. Paseo Colon 850 Buenos Aires C1063ACV Argentina Phone: +54 11 5285-0716 Email: ihameli@cnet.fi.uba.ar URI: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acm@research.att.com Joachim Fabini TU Wien Gusshausstrasse 25/E389 Vienna 1040 Austria Phone: +43 1 58801 38813 Fax: +43 1 58801 38898 Email: Joachim.Fabini@tuwien.ac.at URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 26] Internet-Draft AURA Metrics & Methods August 2020 Carlos Pignataro Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709 USA Email: cpignata@cisco.com Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de Alvarez-Hamelin, et al. Expires February 14, 2021 [Page 27] ./draft-ietf-babel-hmac-12.txt0000644000764400076440000014113013724554751015343 0ustar iustyiusty Network Working Group C. Do Internet-Draft W. Kolodziejak Obsoletes: 7298 (if approved) J. Chroboczek Intended status: Standards Track IRIF, University of Paris-Diderot Expires: March 8, 2021 September 4, 2020 MAC authentication for the Babel routing protocol draft-ietf-babel-hmac-12 Abstract This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 8, 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Do, et al. Expires March 8, 2021 [Page 1] Internet-Draft MAC authentication for Babel September 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Assumptions and security properties . . . . . . . . . . . 3 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 4.1. MAC computation . . . . . . . . . . . . . . . . . . . . . 7 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12 5. Incremental deployment and key rotation . . . . . . . . . . . 12 6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. MAC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 14 6.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.2. Informational References . . . . . . . . . . . . . . . . 18 Appendix A. Changes from previous versions . . . . . . . . . . . 19 A.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 19 A.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 19 A.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19 A.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19 A.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 20 A.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 20 A.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 20 A.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction By default, the Babel routing protocol trusts the information contained in every UDP datagram that it receives on the Babel port. An attacker can redirect traffic to itself or to a different node in the network, causing a variety of potential issues. In particular, an attacker might: Do, et al. Expires March 8, 2021 [Page 2] Internet-Draft MAC authentication for Babel September 2020 o spoof a Babel packet, and redirect traffic by announcing a route with a smaller metric, a larger sequence number, or a longer prefix; o spoof a malformed packet, which could cause an insufficiently robust implementation to crash or interfere with the rest of the network; o replay a previously captured Babel packet, which could cause traffic to be redirected or otherwise interfere with the network. Protecting a Babel network is challenging due to the fact that the Babel protocol uses both unicast and multicast communication. One possible approach, used notably by the Babel over Datagram Transport Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use unicast communication for all semantically significant communication, and then use a standard unicast security protocol to protect the Babel traffic. In this document, we take the opposite approach: we define a cryptographic extension to the Babel protocol that is able to protect both unicast and multicast traffic, and thus requires very few changes to the core protocol. This document obsoletes [RFC7298]. 1.1. Applicability The protocol defined in this document assumes that all interfaces on a given link are equally trusted and share a small set of symmetric keys (usually just one, and two during key rotation). The protocol is inapplicable in situations where asymmetric keying is required, where the trust relationship is partial, or where large numbers of trusted keys are provisioned on a single link at the same time. This protocol supports incremental deployment (where an insecure Babel network is made secure with no service interruption), and it supports graceful key rotation (where the set of keys is changed with no service interruption). This protocol does not require synchronised clocks, it does not require persistently monotonic clocks, and it does not require persistent storage except for what might be required for storing cryptographic keys. 1.2. Assumptions and security properties The correctness of the protocol relies on the following assumptions: o that the Message Authentication Code (MAC) being used is invulnerable to forgery, i.e., that an attacker is unable to Do, et al. Expires March 8, 2021 [Page 3] Internet-Draft MAC authentication for Babel September 2020 generate a packet with a correct MAC without access to the secret key; o that a node never generates the same index or nonce twice over the lifetime of a key. The first assumption is a property of the MAC being used. The second assumption can be met either by using a robust random number generator [RFC4086] and sufficiently large indices and nonces, by using a reliable hardware clock, or by rekeying often enough that collisions are unlikely. If the assumptions above are met, the protocol described in this document has the following properties: o it is invulnerable to spoofing: any Babel packet accepted as authentic is the exact copy of a packet originally sent by an authorised node; o locally to a single node, it is invulnerable to replay: if a node has previously accepted a given packet, then it will never again accept a copy of this packet or an earlier packet from the same sender; o among different nodes, it is only vulnerable to immediate replay: if a node A has accepted an authentic packet from C, then a node B will only accept a copy of that packet if B has accepted an older packet from C and B has received no later packet from C. While this protocol makes efforts to mitigate the effects of a denial of service attack, it does not fully protect against such attacks. 1.3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Conceptual overview of the protocol When a node B sends out a Babel packet through an interface that is configured for MAC cryptographic protection, it computes one or more MACs (one per key) which it appends to the packet. When a node A receives a packet over an interface that requires MAC cryptographic protection, it independently computes a set of MACs and compares them Do, et al. Expires March 8, 2021 [Page 4] Internet-Draft MAC authentication for Babel September 2020 to the MACs appended to the packet; if there is no match, the packet is discarded. In order to protect against replay, B maintains a per-interface 32-bit integer known as the "packet counter" (PC). Whenever B sends a packet through the interface, it embeds the current value of the PC within the region of the packet that is protected by the MACs and increases the PC by at least one. When A receives the packet, it compares the value of the PC with the one contained in the previous packet received from B, and unless it is strictly greater, the packet is discarded. By itself, the PC mechanism is not sufficient to protect against replay. Consider a peer A that has no information about a peer B (e.g., because it has recently rebooted). Suppose that A receives a packet ostensibly from B carrying a given PC; since A has no information about B, it has no way to determine whether the packet is freshly generated or a replay of a previously sent packet. In this situation, A discards the packet and challenges B to prove that it knows the MAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen by A, in a packet protected by MAC and containing the new value of B's PC. Since the nonce has never been used before, B's reply proves B's knowledge of the MAC key and the freshness of the PC. By itself, this mechanism is safe against replay if B never resets its PC. In practice, however, this is difficult to ensure, as persistent storage is prone to failure, and hardware clocks, even when available, are occasionally reset. Suppose that B resets its PC to an earlier value, and sends a packet with a previously used PC n. A challenges B, B successfully responds to the challenge, and A accepts the PC equal to n + 1. At this point, an attacker C may send a replayed packet with PC equal to n + 2, which will be accepted by A. Another mechanism is needed to protect against this attack. In this protocol, every PC is tagged with an "index", an arbitrary string of octets. Whenever B resets its PC, or whenever B doesn't know whether its PC has been reset, it picks an index that it has never used before (either by drawing it randomly or by using a reliable hardware clock) and starts sending PCs with that index. Whenever A detects that B has changed its index, it challenges B again. With this additional mechanism, this protocol is invulnerable to replay attacks (see Section 1.2 above). Do, et al. Expires March 8, 2021 [Page 5] Internet-Draft MAC authentication for Babel September 2020 3. Data Structures Every Babel node maintains a set of conceptual data structures described in Section 3.2 of [RFC6126bis]. This protocol extends these data structures as follows. 3.1. The Interface Table Every Babel node maintains an interface table, as described in Section 3.2.3 of [RFC6126bis]. Implementations of this protocol MUST allow each interface to be provisioned with a set of one or more MAC keys and the associated MAC algorithms (see Section 4.1 for suggested algorithms, and Section 7 for suggested methods for key generation). In order to allow incremental deployment of this protocol (see Section 5), implementations SHOULD allow an interface to be configured in a mode in which it participates in the MAC authentication protocol but accepts packets that are not authenticated. This protocol extends each entry in this table that is associated with an interface on which MAC authentication has been configured with two new pieces of data: o a set of one or more MAC keys, each associated with a given MAC algorithm; o a pair (Index, PC), where Index is an arbitrary string of 0 to 32 octets, and PC is a 32-bit (4-octet) integer. We say that an index is fresh when it has never been used before with any of the keys currently configured on the interface. The Index field is initialised to a fresh index, for example by drawing a random string of sufficient length (see Section 7 for suggested sizes), and the PC is initialised to an arbitrary value (typically 0). 3.2. The Neighbour table Every Babel node maintains a neighbour table, as described in Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in this table with two new pieces of data: o a pair (Index, PC), where Index is a string of 0 to 32 octets, and PC is a 32-bit (4-octet) integer; o a Nonce, which is an arbitrary string of 0 to 192 octets, and an associated challenge expiry timer. Do, et al. Expires March 8, 2021 [Page 6] Internet-Draft MAC authentication for Babel September 2020 The Index and PC are initially undefined, and are managed as described in Section 4.3. The Nonce and challenge expiry timer are initially undefined, and used as described in Section 4.3.1.1. 4. Protocol Operation 4.1. MAC computation A Babel node computes the MAC of a Babel packet as follows. First, the node builds a pseudo-header that will participate in MAC computation but will not be sent. If the packet is carried over IPv6, the pseudo-header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Src address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Dest address | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Dest port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the packet is carried over IPv4, the pseudo-header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src port | Dest address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Dest port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Do, et al. Expires March 8, 2021 [Page 7] Internet-Draft MAC authentication for Babel September 2020 Fields : Src address The source IP address of the packet. Src port The source UDP port number of the packet. Dest address The destination IP address of the packet. Src port The destination UDP port number of the packet. The node takes the concatenation of the pseudo-header and the Babel packet including the packet header but excluding the packet trailer (from octet 0 inclusive up to (Body Length + 4) exclusive) and computes a MAC with one of the implemented algorithms. Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and MAY implement other MAC algorithms. 4.2. Packet Transmission A Babel node might delay actually sending TLVs by a small amount, in order to aggregate multiple TLVs in a single packet up to the interface MTU (Section 4 of [RFC6126bis]). For an interface on which MAC protection is configured, the TLV aggregation logic MUST take into account the overhead due to PC TLVs (one in each packet) and MAC TLVs (one per configured key). Before sending a packet, the following actions are performed: o a PC TLV containing the PC and Index associated with the outgoing interface MUST be appended to the packet body; the PC MUST be incremented by a strictly positive amount (typically just 1); if the PC overflows, a fresh index MUST be generated (as defined in Section 3.1); a node MUST NOT include multiple PC TLVs in a single packet; o for each key configured on the interface, a MAC is computed as specified in Section 4.1 above, and stored in a MAC TLV that MUST be appended to the packet trailer (see Section 4.2 of [RFC6126bis]). 4.3. Packet Reception When a packet is received on an interface that is configured for MAC protection, the following steps are performed before the packet is passed to normal processing: Do, et al. Expires March 8, 2021 [Page 8] Internet-Draft MAC authentication for Babel September 2020 o First, the receiver checks whether the trailer of the received packet carries at least one MAC TLV; if not, the packet MUST be immediately dropped and processing stops. Then, for each key configured on the receiving interface, the receiver computes the MAC of the packet. It then compares every generated MAC against every MAC included in the packet; if there is at least one match, the packet passes the MAC test; if there is none, the packet MUST be silently dropped and processing stops at this point. In order to avoid memory exhaustion attacks, an entry in the Neighbour Table MUST NOT be created before the MAC test has passed successfully. The MAC of the packet MUST NOT be computed for each MAC TLV contained in the packet, but only once for each configured key. o If an entry for the sender does not exist in the Neighbour Table, it MAY be created at this point (or, alternatively, its creation can be delayed until a challenge needs to be sent, see below); o The packet body is then parsed a first time. During this "preparse" phase, the packet body is traversed and all TLVs are ignored except PC, Challenge Request and Challenge Reply TLVs. When a PC TLV is encountered, the enclosed PC and Index are saved for later processing; if multiple PCs are found (which should not happen, see Section 4.2 above), only the first one is processed, the remaining ones MUST be silently ignored. If a Challenge Request is encountered, a Challenge Reply MUST be scheduled, as described in Section 4.3.1.2. If a Challenge Reply is encountered, it is tested for validity as described in Section 4.3.1.3 and a note is made of the result of the test. o The preparse phase above has yielded two pieces of data: the PC and Index from the first PC TLV, and a bit indicating whether the packet contains a successful Challenge Reply. If the packet does not contain a PC TLV, the packet MUST be dropped and processing stops at this point. If the packet contains a successful Challenge Reply, then the PC and Index contained in the PC TLV MUST be stored in the Neighbour Table entry corresponding to the sender (which already exists in this case), and the packet is accepted. o Otherwise, if there is no entry in the Neighbour Table corresponding to the sender, or if such an entry exists but contains no Index, or if the Index it contains is different from the Index contained in the PC TLV, then a challenge MUST be sent as described in Section 4.3.1.1, the packet MUST be dropped, and processing stops at this stage. Do, et al. Expires March 8, 2021 [Page 9] Internet-Draft MAC authentication for Babel September 2020 o At this stage, the packet contains no successful challenge reply and the Index contained in the PC TLV is equal to the Index in the Neighbour Table entry corresponding to the sender. The receiver compares the received PC with the PC contained in the Neighbour Table; if the received PC is smaller or equal than the PC contained in the Neighbour Table, the packet MUST be dropped and processing stops (no challenge is sent in this case, since the mismatch might be caused by harmless packet reordering on the link). Otherwise, the PC contained in the Neighbour Table entry is set to the received PC, and the packet is accepted. In the algorithm described above, challenge requests are processed and challenges are sent before the PC/Index pair is verified against the neighbour table. This simplifies the implementation somewhat (the node may simply schedule outgoing requests as it walks the packet during the preparse phase), but relies on the rate-limiting described in Section 4.3.1.1 to avoid sending too many challenges in response to replayed packets. As an optimisation, a node MAY ignore all challenge requests contained in a packet except the last one, and it MAY ignore a challenge request in the case where it is contained in a packet with an Index that matches the one in the Neighbour Table and a PC that is smaller or equal to the one contained in the Neighbour Table. Since it is still possible to replay a packet with an obsolete Index, the rate-limiting described in Section 4.3.1.1 is required even if this optimisation is implemented. The same is true of challenge replies. However, since validating a challenge reply has minimal additional cost (it's just a bitwise comparison of two strings of octets), a similar optimisation for challenge replies is not worthwhile. After the packet has been accepted, it is processed as normal, except that any PC, Challenge Request and Challenge Reply TLVs that it contains are silently ignored. 4.3.1. Challenge requests and replies During the preparse stage, the receiver might encounter a mismatched Index, to which it will react by scheduling a Challenge Request. It might encounter a Challenge Request TLV, to which it will reply with a Challenge Reply TLV. Finally, it might encounter a Challenge Reply TLV, which it will attempt to match with a previously sent Challenge Request TLV in order to update the Neighbour Table entry corresponding to the sender of the packet. Do, et al. Expires March 8, 2021 [Page 10] Internet-Draft MAC authentication for Babel September 2020 4.3.1.1. Sending challenges When it encounters a mismatched Index during the preparse phase, a node picks a nonce that it has never used with any of the keys currently configured on the relevant interface, for example by drawing a sufficiently large random string of bytes or by consulting a strictly monotonic hardware clock. It MUST then store the nonce in the entry of the Neighbour Table associated to the neighbour (the entry might need to be created at this stage), initialise the neighbour's challenge expiry timer to 30 seconds, and send a Challenge Request TLV to the unicast address corresponding to the neighbour. A node MAY aggregate a Challenge Request with other TLVs; in other words, if it has already buffered TLVs to be sent to the unicast address of the neighbour, it MAY send the buffered TLVs in the same packet as the Challenge Request. However, it MUST arrange for the Challenge Request to be sent in a timely manner, as any packets received from that neighbour will be silently ignored until the challenge completes. A node MUST impose a rate limitation to the challenges it sends; the limit SHOULD default to one challenge request every 300ms, and MAY be configurable. This rate limiting serves two purposes. First, since a challenge may be sent in response to a packet replayed by an attacker, it limits the number of challenges that an attacker can cause a node to send. Second, it limits the number of challenges sent when there are multiple packets in flight from a single neighbour. 4.3.1.2. Replying to challenges When it encounters a Challenge Request during the preparse phase, a node constructs a Challenge Reply TLV by copying the Nonce from the Challenge Request into the Challenge Reply. It MUST then send the Challenge Reply to the unicast address from which the Challenge Request was sent. A challenge sent to a multicast address MUST be silently ignored. A node MAY aggregate a Challenge Reply with other TLVs; in other words, if it has already buffered TLVs to be sent to the unicast address of the sender of the Challenge Request, it MAY send the buffered TLVs in the same packet as the Challenge Reply. However, it MUST arrange for the Challenge Reply to be sent in a timely manner (within a few seconds), and SHOULD NOT send any other packets over the same interface before sending the Challenge Reply, as those would be dropped by the challenger. Do, et al. Expires March 8, 2021 [Page 11] Internet-Draft MAC authentication for Babel September 2020 Since a challenge reply might be caused by a replayed challenge request, a node MUST impose a rate limitation to the challenge replies it sends; the limit SHOULD default to one challenge reply for each peer every 300ms and MAY be configurable. 4.3.1.3. Receiving challenge replies When it encounters a Challenge Reply during the preparse phase, a node consults the Neighbour Table entry corresponding to the neighbour that sent the Challenge Reply. If no challenge is in progress, i.e., if there is no Nonce stored in the Neighbour Table entry or the challenge timer has expired, the Challenge Reply MUST be silently ignored and the challenge has failed. Otherwise, the node compares the Nonce contained in the Challenge Reply with the Nonce contained in the Neighbour Table entry. If the two are equal (they have the same length and content), then the challenge has succeeded and the nonce stored in the Neighbour Table for this neighbour SHOULD be discarded; otherwise, the challenge has failed (and the nonce is not discarded). 4.4. Expiring per-neighbour state The per-neighbour (Index, PC) pair is maintained in the neighbour table, and is normally discarded when the neighbour table entry expires. Implementations MUST ensure that an (Index, PC) pair is discarded within a finite time since the last time a packet has been accepted. In particular, unsuccessful challenges MUST NOT prevent an (Index, PC) pair from being discarded for unbounded periods of time. A possible implementation strategy for implementations that use a Hello history (Appendix A of [RFC6126bis]) is to discard the (Index, PC) pair whenever the Hello history becomes empty. Another implementation strategy is to use a timer that is reset whenever a packet is accepted, and to discard the (Index, PC) pair whenever the timer expires. If the latter strategy is being used, the timer SHOULD default to a value of 5 min, and MAY be configurable. 5. Incremental deployment and key rotation In order to perform incremental deployment, the nodes in the network are first configured in a mode where packets are sent with authentication but not checked on reception. Once all the nodes in the network are configured to send authenticated packets, nodes are reconfigured to reject unauthenticated packets. In order to perform key rotation, the new key is added to all the nodes; once this is done, both the old and the new key are sent in Do, et al. Expires March 8, 2021 [Page 12] Internet-Draft MAC authentication for Babel September 2020 all packets, and packets are accepted if they are properly signed by either of the keys. At that point, the old key is removed. In order to support the procedures described above, implementations of this protocol SHOULD support an interface configuration in which packets are sent authenticated but received packets are accepted without verification, and they SHOULD allow changing the set of keys associated with an interface without a restart. 6. Packet Format 6.1. MAC TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 16 | Length | MAC... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 16 to indicate a MAC TLV. Length The length of the body, in octets, exclusive of the Type and Length fields. The length depends on the MAC algorithm being used. MAC The body contains the MAC of the packet, computed as described in Section 4.1. This TLV is allowed in the packet trailer (see Section 4.2 of [RFC6126bis]), and MUST be ignored if it is found in the packet body. 6.2. PC TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 17 | Length | PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Index... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 17 to indicate a PC TLV. Do, et al. Expires March 8, 2021 [Page 13] Internet-Draft MAC authentication for Babel September 2020 Length The length of the body, in octets, exclusive of the Type and Length fields. PC The Packet Counter (PC), a 32-bit (4-octet) unsigned integer which is increased with every packet sent over this interface. A fresh index (as defined in Section 3.1) MUST be generated whenever the PC overflows. Index The sender's Index, an opaque string of 0 to 32 octets. Indices are limited to a size of 32 octets: a node MUST NOT send a TLV with an index of size strictly larger than 32 octets, and a node MAY ignore a PC TLV with an index of length strictly larger than 32 octets. Indices of length 0 are valid: if a node has reliable stable storage and the packet counter never overflows, then only one index is necessary, and the value of length 0 is the canonical choice. 6.3. Challenge Request TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 18 | Length | Nonce... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 18 to indicate a Challenge Request TLV. Length The length of the body, in octets, exclusive of the Type and Length fields. Nonce The nonce uniquely identifying the challenge, an opaque string of 0 to 192 octets. Nonces are limited to a size of 192 octets: a node MUST NOT send a Challenge Request TLV with a nonce of size strictly larger than 192 octets, and a node MAY ignore a nonce that is of size strictly larger than 192 octets. Nonces of length 0 are valid: if a node has reliable stable storage, then it may use a sequential counter for generating nonces which get encoded in the minimum number of octets required; the value 0 is then encoded as the string of length 0. 6.4. Challenge Reply TLV Do, et al. Expires March 8, 2021 [Page 14] Internet-Draft MAC authentication for Babel September 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 19 | Length | Nonce... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 19 to indicate a Challenge Reply TLV. Length The length of the body, in octets, exclusive of the Type and Length fields. Nonce A copy of the nonce contained in the corresponding challenge request. 7. Security Considerations This document defines a mechanism that provides basic security properties for the Babel routing protocol. The scope of this protocol is strictly limited: it only provides authentication (we assume that routing information is not confidential), it only supports symmetric keying, and it only allows for the use of a small number of symmetric keys on every link. Deployments that need more features, e.g., confidentiality or asymmetric keying, should use a more featureful security mechanism such as the one described in [I-D.ietf-babel-dtls]. This mechanism relies on two assumptions, as described in Section 1.2. First, it assumes that the MAC being used is invulnerable to forgery (Section 1.1 of [RFC6039]); at the time of writing, HMAC-SHA256, which is mandatory to implement (Section 4.1), is believed to be safe against practical attacks. Second, it assumes that indices and nonces are generated uniquely over the lifetime of a key used for MAC computation (more precisely, indices must be unique for a given (key, source) pair, and nonces must be unique for a given (key, source, destination) triple). This property can be satisfied either by using a cryptographically secure random number generator to generate indices and nonces that contain enough entropy (64-bit values are believed to be large enough for all practical applications), or by using a reliably monotonic hardware clock. If uniqueness cannot be guaranteed (e.g., because a hardware clock has been reset), then rekeying is necessary. The expiry mechanism mandated in Section 4.4 is required to prevent an attacker from delaying an authentic packet by an unbounded amount of time. If an attacker is able to delay the delivery of a packet Do, et al. Expires March 8, 2021 [Page 15] Internet-Draft MAC authentication for Babel September 2020 (e.g., because it is located at a layer 2 switch), then the packet will be accepted as long as the corresponding (Index, PC) pair is present at the receiver. If the attacker is able to cause the (Index, PC) pair to persist for arbitrary amounts of time (e.g., by repeatedly causing failed challenges), then it is able to delay the packet by arbitrary amounts of time, even after the sender has left the network, which could allow it to redirect or blackhole traffic to destinations previously advertised by the sender. This protocol exposes large numbers of packets and their MACs to an attacker that is able to capture packets; it is therefore vulnerable to brute-force attacks. Keys must be chosen in a manner that makes them difficult to guess. Ideally, they should have a length of 32 octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly. If, for some reason, it is necessary to derive keys from a human- readable passphrase, it is recommended to use a key derivation function that hampers dictionary attacks, such as PBKDF2 [RFC2898], bcrypt [BCRYPT] or scrypt [RFC7914]. In that case, only the derived keys should be communicated to the routers; the original passphrase itself should be kept on the host used to perform the key generation (e.g., an administator's secure laptop computer). While it is probably not possible to be immune against denial of service (DoS) attacks in general, this protocol includes a number of mechanisms designed to mitigate such attacks. In particular, reception of a packet with no correct MAC creates no local Babel state (Section 4.3). Reception of a replayed packet with correct MAC, on the other hand, causes a challenge to be sent; this is mitigated somewhat by requiring that challenges be rate-limited (Section 4.3.1.1). Receiving a replayed packet with an obsolete index causes an entry to be created in the Neighbour Table, which, at first sight, makes the protocol susceptible to resource exhaustion attacks (similarly to the familiar "TCP SYN Flooding" attack [RFC4987]). However, the MAC computation includes the sender address (Section 4.1), and thus the amount of storage that an attacker can force a node to consume is limited by the number of distinct source addresses used with a single MAC key (see also Section 4 of [RFC6126bis], which mandates that the source address is a link-local IPv6 address or a local IPv4 address). In order to make this kind of resource exhaustion attacks less effective, implementations may use a separate table of uncompleted challenges that is separate from the Neighbour Table used by the core protocol (the data structures described in Section 3.2 of [RFC6126bis] are conceptual, and any data structure that yields the same result may be used). Implementers might also consider using the fact that the nonces included in challenge requests and replies can Do, et al. Expires March 8, 2021 [Page 16] Internet-Draft MAC authentication for Babel September 2020 be fairly large (up to 192 octets), which should in principle allow encoding the per-challenge state as a secure "cookie" within the nonce itself; note however that any such scheme will need to prevent cookie replay. 8. IANA Considerations IANA has allocated the following values in the Babel TLV Types registry: +------+-------------------+---------------+ | Type | Name | Reference | +------+-------------------+---------------+ | 16 | MAC | this document | | | | | | 17 | PC | this document | | | | | | 18 | Challenge Request | this document | | | | | | 19 | Challenge Reply | this document | +------+-------------------+---------------+ 9. Acknowledgments The protocol described in this document is based on the original HMAC protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- header was suggested by David Schinazi. The use of an index to avoid replay was suggested by Markus Stenberg. The authors are also indebted to Antonin Decimo, Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn, Benjamin Kaduk, Dave Taht and Martin Vigoureux. 10. References 10.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC6126bis] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", draft-ietf-babel-rfc6126bis-06 (work in progress), October 2018. Do, et al. Expires March 8, 2021 [Page 17] Internet-Draft MAC authentication for Babel September 2020 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, DOI 10.17487/RFC7693, November 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 10.2. Informational References [BCRYPT] Niels, P. and D. Mazieres, "A Future-Adaptable Password Scheme", 1999. In Proceedings of the 1999 USENIX Annual Technical Conference. [I-D.ietf-babel-dtls] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", draft-ietf-babel-dtls-07 (work in progress), July 2019. [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, . Do, et al. Expires March 8, 2021 [Page 18] Internet-Draft MAC authentication for Babel September 2020 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, . [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, August 2016, . Appendix A. Changes from previous versions [RFC Editor: please remove this section before publication.] A.1. Changes since draft-ietf-babel-hmac-00 o Changed the title. o Removed the appendix about the packet trailer, this is now in rfc6126bis. o Removed the appendix with implicit indices. o Clarified the definitions of acronyms. o Limited the size of nonces and indices. A.2. Changes since draft-ietf-babel-hmac-01 o Made BLAKE2s a recommended HMAC algorithm. o Added requirement to expire per-neighbour crypto state. A.3. Changes since draft-ietf-babel-hmac-02 o Clarified that PCs are 32-bit unsigned integers. o Clarified that indices and nonces are of arbitrary size. o Added reference to RFC 4086. A.4. Changes since draft-ietf-babel-hmac-03 o Use the TLV values allocated by IANA. o Fixed an issue with packets that contain a successful challenge reply: they should be accepted before checking the PC value. Do, et al. Expires March 8, 2021 [Page 19] Internet-Draft MAC authentication for Babel September 2020 o Clarified that keys are the exact value of the HMAC hash size, and not subject to preprocessing; this makes management more deterministic. A.5. Changes since draft-ietf-babel-hmac-04 o Use normative language in more places. A.6. Changes since draft-ietf-babel-hmac-05 o Do not update RFC 6126bis. o Clarify that indices and nonces of length 0 are valid. o Clarify that multiple PC TLVs in a single packet are not allowed. o Allow discarding challenge requests when they carry an old PC. A.7. Changes since draft-ietf-babel-hmac-06 o Do not update RFC 6126bis, for real this time. A.8. Changes since draft-ietf-babel-hmac-07 o Clarify that a Neighbour Table entry may be created just after the HMAC has been computed. o Clarify that a Neighbour Table entry already exists when a successful Challenge Reply has been received. o Expand the Security Considerations section with information about resource exhaustion attacks. A.8.1. Changes since draft-ietf-babel-hmac-08 o Fix the size of the key to be equal to the block size, not the hash size. o Moved the information about incremental deployment to the body. o Clarified the double purpose of rate limitation. o Editorial changes. Do, et al. Expires March 8, 2021 [Page 20] Internet-Draft MAC authentication for Babel September 2020 A.8.2. Changes since draft-ietf-babel-hmac-09 o Renamed HMAC to MAC throughout, relevant rewording. o Made it mandatory to rate-limit challenge replies in addition to requests. o Added discussion of key generation. o Added discussion of the consequences of delaying packets. A.8.3. Changes since draft-ietf-babel-hmac-10 o Fixed minor typos. A.8.4. Changes since draft-ietf-babel-hmac-11 o Clarified that the state SHOULD be discarded after a successful challenge. o Replaced "pre-image attack" with "forgery", this is more accurate. o Minor editorial changes. Authors' Addresses Clara Do IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: clarado_perso@yahoo.fr Weronika Kolodziejak IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: weronika.kolodziejak@gmail.com Do, et al. Expires March 8, 2021 [Page 21] Internet-Draft MAC authentication for Babel September 2020 Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr Do, et al. Expires March 8, 2021 [Page 22] ./draft-ietf-httpbis-client-hints-15.txt0000644000764400076440000007211313677617736017465 0ustar iustyiusty HTTP Working Group I. Grigorik Internet-Draft Y. Weiss Intended status: Experimental Google Expires: January 4, 2021 July 3, 2020 HTTP Client Hints draft-ietf-httpbis-client-hints-15 Abstract HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/client-hints [3]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Grigorik & Weiss Expires January 4, 2021 [Page 1] Internet-Draft HTTP Client Hints July 2020 This Internet-Draft will expire on January 4, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 2. Client Hint Request Header Fields . . . . . . . . . . . . . . 4 2.1. Sending Client Hints . . . . . . . . . . . . . . . . . . 4 2.2. Server Processing of Client Hints . . . . . . . . . . . . 5 3. Advertising Server Support . . . . . . . . . . . . . . . . . 5 3.1. The Accept-CH Response Header Field . . . . . . . . . . . 5 3.2. Interaction with Caches . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.1. Information Exposure . . . . . . . . . . . . . . . . . . 7 4.2. Deployment and Security Risks . . . . . . . . . . . . . . 9 4.3. Abuse Detection . . . . . . . . . . . . . . . . . . . . . 9 5. Cost of Sending Hints . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. Accept-CH . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 11 A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 11 A.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.4. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.5. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.6. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.7. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.8. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 12 A.9. Since -08 . . . . . . . . . . . . . . . . . . . . . . . . 13 Grigorik & Weiss Expires January 4, 2021 [Page 2] Internet-Draft HTTP Client Hints July 2020 A.10. Since -09 . . . . . . . . . . . . . . . . . . . . . . . . 13 A.11. Since -10 . . . . . . . . . . . . . . . . . . . . . . . . 13 A.12. Since -11 . . . . . . . . . . . . . . . . . . . . . . . . 13 A.13. Since -12 . . . . . . . . . . . . . . . . . . . . . . . . 13 A.14. Since -13 . . . . . . . . . . . . . . . . . . . . . . . . 13 A.15. Since -14 . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction There are thousands of different devices accessing the web, each with different device capabilities and preference information. These device capabilities include hardware and software characteristics, as well as dynamic user and user agent preferences. Historically, applications that wanted the server to optimize content delivery and user experience based on such capabilities had to rely on passive identification (e.g., by matching the User-Agent header field (Section 5.5.3 of [RFC7231]) against an established database of user agent signatures), use HTTP cookies [RFC6265] and URL parameters, or use some combination of these and similar mechanisms to enable ad hoc content negotiation. Such techniques are expensive to set up and maintain, and are not portable across both applications and servers. They also make it hard for both user agent and server to understand which data are required and is in use during the negotiation: o User agent detection cannot reliably identify all static variables, cannot infer dynamic user agent preferences, requires an external device database, is not cache friendly, and is reliant on a passive fingerprinting surface. o Cookie-based approaches are not portable across applications and servers, impose additional client-side latency by requiring JavaScript execution, and are not cache friendly. o URL parameters, similar to cookie-based approaches, suffer from lack of portability, and are hard to deploy due to a requirement to encode content negotiation data inside of the URL of each resource. Proactive content negotiation (Section 3.4.1 of [RFC7231]) offers an alternative approach; user agents use specified, well-defined request headers to advertise their capabilities and characteristics, so that servers can select (or formulate) an appropriate response based on those request headers (or on other, implicit characteristics). However, traditional proactive content negotiation techniques often mean that user agents send these request headers prolifically. This Grigorik & Weiss Expires January 4, 2021 [Page 3] Internet-Draft HTTP Client Hints July 2020 causes performance concerns (because it creates "bloat" in requests), as well as privacy issues; passively providing such information allows servers to silently fingerprint the user. This document defines Client Hints, a framework that enables servers to opt-in to specific proactive content negotiation features, adapting their content accordingly, as well as guidelines for content negotiation mechanisms that use the framework. This document also defines a new response header, Accept-CH, that allows an origin server to explicitly ask that user agents send these headers in requests. Client Hints mitigate performance concerns by assuring that user agents will only send the request headers when they're actually going to be used, and privacy concerns of passive fingerprinting by requiring explicit opt-in and disclosure of required headers by the server through the use of the Accept-CH response header, turning passive fingerprinting vectors into active ones. The document does not define specific usages of Client Hints. Such usages need to be defined in their respective specifications. One example of such usage is the User Agent Client Hints [UA-CH]. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. 2. Client Hint Request Header Fields A Client Hint request header field is a HTTP header field that is used by HTTP user agents to indicate data that can be used by the server to select an appropriate response. Each one conveys user agent preferences that the server can use to adapt and optimize the response. 2.1. Sending Client Hints User agents choose what Client Hints to send in a request based on their default settings, user configuration, and server preferences expressed in "Accept-CH". The user agent and server can use an opt- Grigorik & Weiss Expires January 4, 2021 [Page 4] Internet-Draft HTTP Client Hints July 2020 in mechanism outlined below to negotiate which header fields need to be sent to allow for efficient content adaption, and optionally use additional mechanisms (e.g., as outlined in [CLIENT-HINTS-INFRASTRUCTURE]) to negotiate delegation policies that control access of third parties to those same header fields. User agents SHOULD require an opt-in to send any hints that are not listed in the low-entropy hint table at [CLIENT-HINTS-INFRASTRUCTURE]. Implementers need to be aware of the fingerprinting implications when implementing support for Client Hints, and follow the considerations outlined in the Security Considerations (Section 4) section of this document. 2.2. Server Processing of Client Hints When presented with a request that contains one or more Client Hint header fields, servers can optimize the response based upon the information in them. When doing so, and if the resource is cacheable, the server MUST also generate a Vary response header field (Section 7.1.4 of [RFC7231]) to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. Servers MUST ignore hints they do not understand nor support. There is no mechanism for servers to indicate to user agents that hints were ignored. Furthermore, the server can generate additional response header fields (as specified by the hint or hints in use) that convey related values to aid client processing. 3. Advertising Server Support Servers can advertise support for Client Hints using the mechanism described below. 3.1. The Accept-CH Response Header Field The Accept-CH response header field indicates server support for the hints indicated in its value. Servers wishing to receive user agent information through Client Hints SHOULD add Accept-CH response header to their responses as early as possible. Accept-CH is a Structured Header [I-D.ietf-httpbis-header-structure]. Its value MUST be an sf-list (Section 3.1 of [I-D.ietf-httpbis-header-structure]) whose members are tokens (Section 3.3.4 of [I-D.ietf-httpbis-header-structure]). Its ABNF is: Grigorik & Weiss Expires January 4, 2021 [Page 5] Internet-Draft HTTP Client Hints July 2020 Accept-CH = sf-list For example: Accept-CH: Sec-CH-Example, Sec-CH-Example-2 When a user agent receives an HTTP response containing "Accept-CH", that indicates that the origin opts-in to receive the indicated request header fields for subsequent same-origin requests. The opt- in MUST be ignored if delivered over non-secure transport (using a scheme different from HTTPS). It SHOULD be persisted and bound to the origin to enable delivery of Client Hints on subsequent requests to the server's origin, for the duration of the user's session (as defined by the user agent). An opt-in overrides previous persisted opt-in values and SHOULD be persisted in its stead. Based on the Accept-CH example above, which is received in response to a user agent navigating to "https://site.example", and delivered over a secure transport, persisted Accept-CH preferences will be bound to "https://site.example". It will then use it for navigations to e.g., "https://site.example/foobar.html", but not to e.g., "https://foobar.site.example/". It will similarly use the preference for any same-origin resource requests (e.g., to "https://site.example/image.jpg") initiated by the page constructed from the navigation's response, but not to cross-origin resource requests (e.g., "https://thirdparty.example/resource.js"). This preference will not extend to resource requests initiated to "https://site.example" from other origins (e.g., from navigations to "https://other.example/"). 3.2. Interaction with Caches When selecting a response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field ([RFC7234]) to indicate which hints can affect the selected response and whether the selected response is appropriate for a later request. Vary: Sec-CH-Example The above example indicates that the cache key needs to include the Sec-CH-Example header field. Vary: Sec-CH-Example, Sec-CH-Example-2 The above example indicates that the cache key needs to include the Sec-CH-Example and Sec-CH-Example-2 header fields. Grigorik & Weiss Expires January 4, 2021 [Page 6] Internet-Draft HTTP Client Hints July 2020 4. Security Considerations 4.1. Information Exposure Request header fields used in features relying on this document expose information about the user's environment to enable privacy- preserving proactive content negotiation, and avoid exposing passive fingerprinting vectors. However, implementers need to bear in mind that in the worst case, uncontrolled and unmonitored active fingerprinting is not better than passive fingerprinting. In order to provide user privacy benefits, user agents need to apply further policies that prevent abuse of the information exposed by features using Client Hints. The information exposed by features might reveal new information about the user and implementers ought to consider the following considerations, recommendations, and best practices. The underlying assumption is that exposing information about the user as a request header is equivalent (from a security perspective) to exposing this information by other means. (For example, if the request's origin can access that information using JavaScript APIs, and transmit it to its servers). Because Client Hints is an explicit opt-in mechanism, that means that servers that want access to information about the user's environment need to actively ask for it, enabling clients and privacy researchers to keep track of which origins collect that data, and potentially act upon it. The header-based opt-in means that removal of passive fingerprinting vectors is possible, such as the User-Agent string (enabling active access to that information through User-Agent Client Hints ([UA-CH]) or otherwise expose information already available through script (e.g., the Save-Data Client Hint [4]), without increasing the passive fingerprinting surface. User agents supporting Client Hints features which send certain information to opted-in servers SHOULD avoid sending the equivalent information passively. Therefore, features relying on this document to define Client Hint headers MUST NOT provide new information that is otherwise not made available to the application by the user agent, such as existing request headers, HTML, CSS, or JavaScript. Such features need to take into account the following aspects of the information exposed: o Entropy - Exposing highly granular data can be used to help identify users across multiple requests to different origins. Grigorik & Weiss Expires January 4, 2021 [Page 7] Internet-Draft HTTP Client Hints July 2020 Reducing the set of header field values that can be expressed, or restricting them to an enumerated range where the advertised value is close to but is not an exact representation of the current value, can improve privacy and reduce risk of linkability by ensuring that the same value is sent by multiple users. o Sensitivity - The feature SHOULD NOT expose user-sensitive information. To that end, information available to the application, but gated behind specific user actions (e.g., a permission prompt or user activation) SHOULD NOT be exposed as a Client Hint. o Change over time - The feature SHOULD NOT expose user information that changes over time, unless the state change itself is also exposed (e.g., through JavaScript callbacks). Different features will be positioned in different points in the space between low-entropy, non-sensitive and static information (e.g., user agent information), and high-entropy, sensitive and dynamic information (e.g., geolocation). User agents need to consider the value provided by a particular feature vs these considerations, and may wish to have different policies regarding that tradeoff on a per-feature or other fine-grained basis. Implementers ought to consider both user- and server- controlled mechanisms and policies to control which Client Hints header fields are advertised: o Implementers SHOULD restrict delivery of some or all Client Hints header fields to the opt-in origin only, unless the opt-in origin has explicitly delegated permission to another origin to request Client Hints header fields. o Implementers considering providing user choice mechanisms that allow users to balance privacy concerns against bandwidth limitations need to also consider that explaining to users the privacy implications involved, such as the risks of passive fingerprinting, may be challenging or even impractical. o Implementations specific to certain use cases or threat models MAY avoid transmitting some or all of Client Hints header fields. For example, avoid transmission of header fields that can carry higher risks of linkability. User agents MUST clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, cookies, or similar, are cleared. Grigorik & Weiss Expires January 4, 2021 [Page 8] Internet-Draft HTTP Client Hints July 2020 4.2. Deployment and Security Risks Deployment of new request headers requires several considerations: o Potential conflicts due to existing use of header field name o Properties of the data communicated in header field value Authors of new Client Hints are advised to carefully consider whether they need to be able to be added by client-side content (e.g., scripts), or whether they need to be exclusively set by the user agent. In the latter case, the Sec- prefix on the header field name has the effect of preventing scripts and other application content from setting them in user agents. Using the "Sec-" prefix signals to servers that the user agent - and not application content - generated the values. See [FETCH] for more information. By convention, request headers that are Client Hints are encouraged to use a CH- prefix, to make them easier to identify as using this framework; for example, CH-Foo or, with a "Sec-" prefix, Sec-CH-Foo. Doing so makes them easier to identify programmatically (e.g., for stripping unrecognised hints from requests by privacy filters). A Client Hints request header negotiated using the Accept-CH opt-in mechanism MUST have a field name that matches sf-token (Section 3.3.4 of [I-D.ietf-httpbis-header-structure]). 4.3. Abuse Detection A user agent that tracks access to active fingerprinting information SHOULD consider emission of Client Hints headers similarly to the way it would consider access to the equivalent API. Research into abuse of Client Hints might look at how HTTP responses to requests that contain Client Hints differ from those with different values, and from those without. This might be used to reveal which Client Hints are in use, allowing researchers to further analyze that use. 5. Cost of Sending Hints Sending Client Hints to the server incurs an increase in request byte size. Some of this increase can be mitigated by HTTP header compression schemes, but each new hint sent will still lead to some increased bandwidth usage. Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Grigorik & Weiss Expires January 4, 2021 [Page 9] Internet-Draft HTTP Client Hints July 2020 Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations [FETCH], where they are more likely to be useful. 6. IANA Considerations Features relying on this document are expected to register added request header fields in the Permanent Message Header Fields registry ([RFC3864]). This document defines the "Accept-CH" HTTP response header field, and registers it in the same registry. 6.1. Accept-CH o Header field name: Accept-CH o Applicable protocol: HTTP o Status: experimental o Author/Change controller: IETF o Specification document(s): Section 3.1 of this document o Related information: for Client Hints 7. References 7.1. Normative References [CLIENT-HINTS-INFRASTRUCTURE] Weiss, Y., "Client Hints Infrastructure", n.d., . [I-D.ietf-httpbis-header-structure] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", draft-ietf-httpbis-header-structure-19 (work in progress), June 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . Grigorik & Weiss Expires January 4, 2021 [Page 10] Internet-Draft HTTP Client Hints July 2020 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [FETCH] van Kesteren, A., "Fetch", n.d., . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [UA-CH] West, M. and Y. Weiss, "User Agent Client Hints", n.d., . 7.3. URIs [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/client-hints [4] https://wicg.github.io/savedata/#save-data-request-header-field Appendix A. Changes A.1. Since -00 o Issue 168 (make Save-Data extensible) updated ABNF. o Issue 163 (CH review feedback) editorial feedback from httpwg list. Grigorik & Weiss Expires January 4, 2021 [Page 11] Internet-Draft HTTP Client Hints July 2020 o Issue 153 (NetInfo API citation) added normative reference. A.2. Since -01 o Issue 200: Moved Key reference to informative. o Issue 215: Extended passive fingerprinting and mitigation considerations. o Changed document status to experimental. A.3. Since -02 o Issue 239: Updated reference to CR-css-values-3 o Issue 240: Updated reference for Network Information API o Issue 241: Consistency in IANA considerations o Issue 250: Clarified Accept-CH A.4. Since -03 o Issue 284: Extended guidance for Accept-CH o Issue 308: Editorial cleanup o Issue 306: Define Accept-CH-Lifetime A.5. Since -04 o Issue 361: Removed Downlink o Issue 361: Moved Key to appendix, plus other editorial feedback A.6. Since -05 o Issue 372: Scoped CH opt-in and delivery to secure transports o Issue 373: Bind CH opt-in to origin A.7. Since -06 o Issue 524: Save-Data is now defined by NetInfo spec, dropping o PR 775: Removed specific features to be defined in other specifications A.8. Since -07 o Issue 761: Clarified that the defined headers are response headers. o Issue 730: Replaced Key reference with Variants. o Issue 700: Replaced ABNF with structured headers. o PR 878: Removed Accept-CH-Lifetime based on feedback at IETF 105 Grigorik & Weiss Expires January 4, 2021 [Page 12] Internet-Draft HTTP Client Hints July 2020 A.9. Since -08 o PR 985: Describe the bytesize cost of hints. o PR 776: Add Sec- and CH- prefix considerations. o PR 1001: Clear CH persistence when cookies are cleared. A.10. Since -09 o PR 1064: Fix merge issues with "cost of sending hints". A.11. Since -10 o PR 1072: LC feedback from Julian Reschke. o PR 1080: Improve list style. o PR 1082: Remove section mentioning Variants. o PR 1097: Editorial feedback from mnot. o PR 1131: Remove unused references. o PR 1132: Remove nested list. A.12. Since -11 o PR 1134: Re-insert back section. A.13. Since -12 o PR 1160: AD review. A.14. Since -13 o PR 1171: Genart review. A.15. Since -14 o PR 1220: AD review. Acknowledgements Thanks to Mark Nottingham, Julian Reschke, Chris Bentzel, Ben Greenstein, Tarun Bansal, Roy Fielding, Vasiliy Faronov, Ted Hardie, Jonas Sicking, Martin Thomson, and numerous other members of the IETF HTTP Working Group for invaluable help and feedback. Authors' Addresses Grigorik & Weiss Expires January 4, 2021 [Page 13] Internet-Draft HTTP Client Hints July 2020 Ilya Grigorik Google Email: ilya@igvita.com URI: https://www.igvita.com/ Yoav Weiss Google Email: yoav@yoav.ws URI: https://blog.yoav.ws/ Grigorik & Weiss Expires January 4, 2021 [Page 14] ./draft-ietf-babel-rfc6126bis-20.txt0000644000764400076440000047245413721037202016221 0ustar iustyiusty Network Working Group J. Chroboczek Internet-Draft IRIF, University of Paris-Diderot Obsoletes: 6126,7557 (if approved) D. Schinazi Intended status: Standards Track Google LLC Expires: February 26, 2021 August 25, 2020 The Babel Routing Protocol draft-ietf-babel-rfc6126bis-20 Abstract Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 26, 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Chroboczek & Schinazi Expires February 26, 2021 [Page 1] Internet-Draft The Babel Routing Protocol August 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . 5 2. Conceptual Description of the Protocol . . . . . . . . . . . 5 2.1. Costs, Metrics and Neighbourship . . . . . . . . . . . . 5 2.2. The Bellman-Ford Algorithm . . . . . . . . . . . . . . . 6 2.3. Transient Loops in Bellman-Ford . . . . . . . . . . . . . 6 2.4. Feasibility Conditions . . . . . . . . . . . . . . . . . 7 2.5. Solving Starvation: Sequencing Routes . . . . . . . . . . 8 2.6. Requests . . . . . . . . . . . . . . . . . . . . . . . . 10 2.7. Multiple Routers . . . . . . . . . . . . . . . . . . . . 11 2.8. Overlapping Prefixes . . . . . . . . . . . . . . . . . . 12 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 12 3.1. Message Transmission and Reception . . . . . . . . . . . 12 3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 13 3.3. Acknowledgments and acknowledgment requests . . . . . . . 17 3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 18 3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 21 3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 25 3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 26 3.8. Explicit Requests . . . . . . . . . . . . . . . . . . . . 28 4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 32 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 32 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 33 4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 34 4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 35 4.5. Parser state and encoding of updates . . . . . . . . . . 36 4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 37 4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 48 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 6. Security Considerations . . . . . . . . . . . . . . . . . . . 52 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.1. Normative References . . . . . . . . . . . . . . . . . . 53 8.2. Informative References . . . . . . . . . . . . . . . . . 54 Appendix A. Cost and Metric Computation . . . . . . . . . . . . 56 A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 56 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 57 A.3. Route selection and hysteresis . . . . . . . . . . . . . 59 Appendix B. Protocol parameters . . . . . . . . . . . . . . . . 60 Appendix C. Route filtering . . . . . . . . . . . . . . . . . . 61 Appendix D. Considerations for protocol extensions . . . . . . . 61 Appendix E. Stub Implementations . . . . . . . . . . . . . . . . 63 Appendix F. Compatibility with previous versions . . . . . . . . 64 Appendix G. Changes from previous versions . . . . . . . . . . . 65 Chroboczek & Schinazi Expires February 26, 2021 [Page 2] Internet-Draft The Babel Routing Protocol August 2020 G.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 65 G.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 65 G.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 65 G.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 66 G.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 66 G.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 67 G.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 67 G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67 G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67 G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67 G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67 G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 68 G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 68 G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 68 G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 68 G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 69 G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 69 G.18. Changes since draft-ietf-babel-rfc6126bis-15 . . . . . . 69 G.19. Changes since draft-ietf-babel-rfc6126bis-16 . . . . . . 69 G.20. Changes since draft-ietf-babel-rfc6126bis-17 . . . . . . 69 G.21. Changes since draft-ietf-babel-rfc6126bis-18 . . . . . . 70 G.22. Changes since draft-ietf-babel-rfc6126bis-19 . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 1. Introduction Babel is a loop-avoiding distance-vector routing protocol that is designed to be robust and efficient both in networks using prefix- based routing and in networks using flat routing ("mesh networks"), and both in relatively stable wired networks and in highly dynamic wireless networks. This document describes the Babel routing protocol, and obsoletes [RFC6126] and [RFC7557]. 1.1. Features The main property that makes Babel suitable for unstable networks is that, unlike naive distance-vector routing protocols [RIP], it strongly limits the frequency and duration of routing pathologies such as routing loops and black-holes during reconvergence. Even after a mobility event is detected, a Babel network usually remains loop-free. Babel then quickly reconverges to a configuration that preserves the loop-freedom and connectedness of the network, but is not necessarily optimal; in many cases, this operation requires no packet exchanges at all. Babel then slowly converges, in a time on the scale of minutes, to an optimal configuration. This is achieved by using sequenced routes, a technique pioneered by Destination- Sequenced Distance-Vector routing [DSDV]. Chroboczek & Schinazi Expires February 26, 2021 [Page 3] Internet-Draft The Babel Routing Protocol August 2020 More precisely, Babel has the following properties: o when every prefix is originated by at most one router, Babel never suffers from routing loops; o when a single prefix is originated by multiple routers, Babel may occasionally create a transient routing loop for this particular prefix; this loop disappears in time proportional to the loop's diameter, and never again (up to an arbitrary garbage-collection (GC) time) will the routers involved participate in a routing loop for the same prefix; o assuming bounded packet loss rates, any routing black-holes that may appear after a mobility event are corrected in a time at most proportional to the network's diameter. Babel has provisions for link quality estimation and for fairly arbitrary metrics. When configured suitably, Babel can implement shortest-path routing, or it may use a metric based, for example, on measured packet loss. Babel nodes will successfully establish an association even when they are configured with different parameters. For example, a mobile node that is low on battery may choose to use larger time constants (hello and update intervals, etc.) than a node that has access to wall power. Conversely, a node that detects high levels of mobility may choose to use smaller time constants. The ability to build such heterogeneous networks makes Babel particularly adapted to the unmanaged or wireless environment. Finally, Babel is a hybrid routing protocol, in the sense that it can carry routes for multiple network-layer protocols (IPv4 and IPv6), regardless of which protocol the Babel packets are themselves being carried over. 1.2. Limitations Babel has two limitations that make it unsuitable for use in some environments. First, Babel relies on periodic routing table updates rather than using a reliable transport; hence, in large, stable networks it generates more traffic than protocols that only send updates when the network topology changes. In such networks, protocols such as OSPF [OSPF], IS-IS [IS-IS], or the Enhanced Interior Gateway Routing Protocol (EIGRP) [EIGRP] might be more suitable. Second, unless the second algorithm described in Section 3.5.4 is implemented, Babel does impose a hold time when a prefix is Chroboczek & Schinazi Expires February 26, 2021 [Page 4] Internet-Draft The Babel Routing Protocol August 2020 retracted. While this hold time does not apply to the exact prefix being retracted, and hence does not prevent fast reconvergence should it become available again, it does apply to any shorter prefix that covers it. This may make those implementations of Babel that do not implement the optional algorithm described in Section 3.5.4 unsuitable for use in networks that implement automatic prefix aggregation. 1.3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Conceptual Description of the Protocol Babel is a loop-avoiding distance vector protocol: it is based on the Bellman-Ford algorithm, just like the venerable RIP [RIP], but includes a number of refinements that either prevent loop formation altogether, or ensure that a loop disappears in a timely manner and doesn't form again. Conceptually, Bellman-Ford is executed in parallel for every source of routing information (destination of data traffic). In the following discussion, we fix a source S; the reader will recall that the same algorithm is executed for all sources. 2.1. Costs, Metrics and Neighbourship For every pair of neighbouring nodes A and B, Babel computes an abstract value known as the cost of the link from A to B, written C(A, B). Given a route between any two (not necessarily neighbouring) nodes, the metric of the route is the sum of the costs of all the links along the route. The goal of the routing algorithm is to compute, for every source S, the tree of routes of lowest metric to S. Costs and metrics need not be integers. In general, they can be values in any algebra that satisfies two fairly general conditions (Section 3.5.2). A Babel node periodically sends Hello messages to all of its neighbours; it also periodically sends an IHU ("I Heard You") message to every neighbour from which it has recently heard a Hello. From the information derived from Hello and IHU messages received from its Chroboczek & Schinazi Expires February 26, 2021 [Page 5] Internet-Draft The Babel Routing Protocol August 2020 neighbour B, a node A computes the cost C(A, B) of the link from A to B. 2.2. The Bellman-Ford Algorithm Every node A maintains two pieces of data: its estimated distance to S, written D(A), and its next-hop router to S, written NH(A). Initially, D(S) = 0, D(A) is infinite, and NH(A) is undefined. Periodically, every node B sends to all of its neighbours a route update, a message containing D(B). When a neighbour A of B receives the route update, it checks whether B is its selected next hop; if that is the case, then NH(A) is set to B, and D(A) is set to C(A, B) + D(B). If that is not the case, then A compares C(A, B) + D(B) to its current value of D(A). If that value is smaller, meaning that the received update advertises a route that is better than the currently selected route, then NH(A) is set to B, and D(A) is set to C(A, B) + D(B). A number of refinements to this algorithm are possible, and are used by Babel. In particular, convergence speed may be increased by sending unscheduled "triggered updates" whenever a major change in the topology is detected, in addition to the regular, scheduled updates. Additionally, a node may maintain a number of alternate routes, which are being advertised by neighbours other than its selected neighbour, and which can be used immediately if the selected route were to fail. 2.3. Transient Loops in Bellman-Ford It is well known that a naive application of Bellman-Ford to distributed routing can cause transient loops after a topology change. Consider for example the following topology: B 1 /| 1 / | S --- A |1 \ | 1 \| C After convergence, D(B) = D(C) = 2, with NH(B) = NH(C) = A. Suppose now that the link between S and A fails: Chroboczek & Schinazi Expires February 26, 2021 [Page 6] Internet-Draft The Babel Routing Protocol August 2020 B 1 /| / | S A |1 \ | 1 \| C When it detects the failure of the link, A switches its next hop to B (which is still advertising a route to S with metric 2), and advertises a metric equal to 3, and then advertises a new route with metric 3. This process of nodes changing selected neighbours and increasing their metric continues until the advertised metric reaches "infinity", a value larger than all the metrics that the routing protocol is able to carry. 2.4. Feasibility Conditions Bellman-Ford is a very robust algorithm: its convergence properties are preserved when routers delay route acquisition or when they discard some updates. Babel routers discard received route announcements unless they can prove that accepting them cannot possibly cause a routing loop. More formally, we define a condition over route announcements, known as the "feasibility condition", that guarantees the absence of routing loops whenever all routers ignore route updates that do not satisfy the feasibility condition. In effect, this makes Bellman- Ford into a family of routing algorithms, parameterised by the feasibility condition. Many different feasibility conditions are possible. For example, BGP can be modelled as being a distance-vector protocol with a (rather drastic) feasibility condition: a routing update is only accepted when the receiving node's AS number is not included in the update's AS-Path attribute (note that BGP's feasibility condition does not ensure the absence of transient "micro-loops" during reconvergence). Another simple feasibility condition, used in the Destination- Sequenced Distance-Vector (DSDV) routing protocol [DSDV] and in the Ad hoc On-Demand Distance Vector (AODV) protocol [RFC3561], stems from the following observation: a routing loop can only arise after a router has switched to a route with a larger metric than the route that it had previously selected. Hence, one may define that a route is feasible when its metric at the local node would be no larger than the metric of the currently selected route, i.e., an announcement carrying a metric D(B) is accepted by A when C(A, B) + D(B) <= D(A). If all routers obey this constraint, then the metric at every router Chroboczek & Schinazi Expires February 26, 2021 [Page 7] Internet-Draft The Babel Routing Protocol August 2020 is nonincreasing, and the following invariant is always preserved: if A has selected B as its next hop, then D(B) < D(A), which implies that the forwarding graph is loop-free. Babel uses a slightly more refined feasibility condition, derived from EIGRP [DUAL]. Given a router A, define the feasibility distance of A, written FD(A), as the smallest metric that A has ever advertised for S to any of its neighbours. An update sent by a neighbour B of A is feasible when the metric D(B) advertised by B is strictly smaller than A's feasibility distance, i.e., when D(B) < FD(A). It is easy to see that this latter condition is no more restrictive than DSDV-feasibility. Suppose that node A obeys DSDV-feasibility; then D(A) is nonincreasing, hence at all times D(A) <= FD(A). Suppose now that A receives a DSDV-feasible update that advertises a metric D(B). Since the update is DSDV-feasible, C(A, B) + D(B) <= D(A), hence D(B) < D(A), and since D(A) <= FD(A), D(B) < FD(A). To see that it is strictly less restrictive, consider the following diagram, where A has selected the route through B, and D(A) = FD(A) = 2. Since D(C) = 1 < FD(A), the alternate route through C is feasible for A, although its metric C(A, C) + D(C) = 5 is larger than that of the currently selected route: B 1 / \ 1 / \ S A \ / 1 \ / 4 C To show that this feasibility condition still guarantees loop- freedom, recall that at the time when A accepts an update from B, the metric D(B) announced by B is no smaller than FD(B); since it is smaller than FD(A), at that point in time FD(B) < FD(A). Since this property is preserved both when A sends updates and when it picks a different next hop, it remains true at all times, which ensures that the forwarding graph has no loops. 2.5. Solving Starvation: Sequencing Routes Obviously, the feasibility conditions defined above cause starvation when a router runs out of feasible routes. Consider the following diagram, where both A and B have selected the direct route to S: Chroboczek & Schinazi Expires February 26, 2021 [Page 8] Internet-Draft The Babel Routing Protocol August 2020 A 1 /| D(A) = 1 / | FD(A) = 1 S |1 \ | D(B) = 2 2 \| FD(B) = 2 B Suppose now that the link between A and S breaks: A | | FD(A) = 1 S |1 \ | D(B) = 2 2 \| FD(B) = 2 B The only route available from A to S, the one that goes through B, is not feasible: A suffers from spurious starvation. At that point, the whole subtree suffering from starvation must be reset, which is essentially what EIGRP does when it performs a global synchronisation of all the routers in the starving subtree (the "active" phase of EIGRP). Babel reacts to starvation in a less drastic manner, by using sequenced routes, a technique introduced by DSDV and adopted by AODV. In addition to a metric, every route carries a sequence number, a nondecreasing integer that is propagated unchanged through the network and is only ever incremented by the source; a pair (s, m), where s is a sequence number and m a metric, is called a distance. A received update is feasible when either it is more recent than the feasibility distance maintained by the receiving node, or it is equally recent and the metric is strictly smaller. More formally, if FD(A) = (s, m), then an update carrying the distance (s', m') is feasible when either s' > s, or s = s' and m' < m. Assuming the sequence number of S is 137, the diagram above becomes: A | | FD(A) = (137, 1) S |1 \ | D(B) = (137, 2) 2 \| FD(B) = (137, 2) B Chroboczek & Schinazi Expires February 26, 2021 [Page 9] Internet-Draft The Babel Routing Protocol August 2020 After S increases its sequence number, and the new sequence number is propagated to B, we have: A | | FD(A) = (137, 1) S |1 \ | D(B) = (138, 2) 2 \| FD(B) = (138, 2) B at which point the route through B becomes feasible again. Note that while sequence numbers are used for determining feasibility, they are not used in route selection: a node ignores the sequence number when selecting the best route to a given destination (Section 3.6). Doing otherwise would cause route oscillation while a sequence number propagates through the network, and might even cause persistent blackholes with some exotic metrics. 2.6. Requests In DSDV, the sequence number of a source is increased periodically. A route becomes feasible again after the source increases its sequence number, and the new sequence number is propagated through the network, which may, in general, require a significant amount of time. Babel takes a different approach. When a node detects that it is suffering from a potentially spurious starvation, it sends an explicit request to the source for a new sequence number. This request is forwarded hop by hop to the source, with no regard to the feasibility condition. Upon receiving the request, the source increases its sequence number and broadcasts an update, which is forwarded to the requesting node. Note that after a change in network topology not all such requests will, in general, reach the source, as some will be sent over links that are now broken. However, if the network is still connected, then at least one among the nodes suffering from spurious starvation has an (unfeasible) route to the source; hence, in the absence of packet loss, at least one such request will reach the source. (Resending requests a small number of times compensates for packet loss.) Since requests are forwarded with no regard to the feasibility condition, they may, in general, be caught in a forwarding loop; this Chroboczek & Schinazi Expires February 26, 2021 [Page 10] Internet-Draft The Babel Routing Protocol August 2020 is avoided by having nodes perform duplicate detection for the requests that they forward. 2.7. Multiple Routers The above discussion assumes that each prefix is originated by a single router. In real networks, however, it is often necessary to have a single prefix originated by multiple routers: for example, the default route will be originated by all of the edge routers of a routing domain. Since synchronising sequence numbers between distinct routers is problematic, Babel treats routes for the same prefix as distinct entities when they are originated by different routers: every route announcement carries the router-id of its originating router, and feasibility distances are not maintained per prefix, but per source, where a source is a pair of a router-id and a prefix. In effect, Babel guarantees loop-freedom for the forwarding graph to every source; since the union of multiple acyclic graphs is not in general acyclic, Babel does not in general guarantee loop-freedom when a prefix is originated by multiple routers, but any loops will be broken in a time at most proportional to the diameter of the loop -- as soon as an update has "gone around" the routing loop. Consider for example the following topology, where A has selected the default route through S, and B has selected the one through S': 1 1 1 ::/0 -- S --- A --- B --- S' -- ::/0 Suppose that both default routes fail at the same time; then nothing prevents A from switching to B, and B simultaneously switching to A. However, as soon as A has successfully advertised the new route to B, the route through A will become unfeasible for B. Conversely, as soon as B will have advertised the route through A, the route through B will become unfeasible for A. In effect, the routing loop disappears at the latest when routing information has gone around the loop. Since this process can be delayed by lost packets, Babel makes certain efforts to ensure that updates are sent reliably after a router-id change (Section 3.7.2). Additionally, after the routers have advertised the two routes, both sources will be in their source tables, which will prevent them from ever again participating in a routing loop involving routes from S and S' (up to the source GC time, which, available memory permitting, can be set to arbitrarily large values). Chroboczek & Schinazi Expires February 26, 2021 [Page 11] Internet-Draft The Babel Routing Protocol August 2020 2.8. Overlapping Prefixes In the above discussion, we have assumed that all prefixes are disjoint, as is the case in flat ("mesh") routing. In practice, however, prefixes may overlap: for example, the default route overlaps with all of the routes present in the network. After a route fails, it is not correct in general to switch to a route that subsumes the failed route. Consider for example the following configuration: 1 1 ::/0 -- A --- B --- C Suppose that node C fails. If B forwards packets destined to C by following the default route, a routing loop will form, and persist until A learns of B's retraction of the direct route to C. B avoids this pitfall by installing an "unreachable" route after a route is retracted; this route is maintained until it can be guaranteed that the former route has been retracted by all of B's neighbours (Section 3.5.4). 3. Protocol Operation Every Babel speaker is assigned a router-id, which is an arbitrary string of 8 octets that is assumed unique across the routing domain. For example, router-ids could be assigned randomly, or they could be derived from a link-layer address. (The protocol encoding is slightly more compact when router-ids are assigned in the same manner as the IPv6 layer assigns host IDs; see the definition of the "R" flag in Section 4.6.9.) 3.1. Message Transmission and Reception Babel protocol packets are sent in the body of a UDP datagram (as described in Section 4 below). Each Babel packet consists of zero or more TLVs. Most TLVs may contain sub-TLVs. The protocol's control traffic can be carried indifferently over IPv6 or over IPv4, and prefixes of either address family can be announced over either protocol. Thus, there are at least two natural deployment models: using IPv6 exclusively for all control traffic, or running two distinct protocol instances, one for each address family. The exclusive use of IPv6 for all control traffic is RECOMMENDED, since using both protocols at the same time doubles the amount of traffic devoted to neighbour discovery and link quality estimation. Chroboczek & Schinazi Expires February 26, 2021 [Page 12] Internet-Draft The Babel Routing Protocol August 2020 The source address of a Babel packet is always a unicast address, link-local in the case of IPv6. Babel packets may be sent to a well- known (link-local) multicast address or to a (link-local) unicast address. In normal operation, a Babel speaker sends both multicast and unicast packets to its neighbours. With the exception of acknowledgments, all Babel TLVs can be sent to either unicast or multicast addresses, and their semantics does not depend on whether the destination is a unicast or a multicast address. Hence, a Babel speaker does not need to determine the destination address of a packet that it receives in order to interpret it. A moderate amount of jitter may be applied to packets sent by a Babel speaker: outgoing TLVs are buffered and SHOULD be sent with a random delay. This is done for two purposes: it avoids synchronisation of multiple Babel speakers across a network [JITTER], and it allows for the aggregation of multiple TLVs into a single packet. The maximum amount of delay a TLV can be subjected to depends on the TLV. When the protocol description specifies that a TLV is urgent (as in Section 3.7.2 and Section 3.8.2), then the TLV MUST be sent within a short time known as the urgent timeout (see Appendix B for recommended values). When the TLV is governed by a timeout explicitly included in a previous TLV, such as in the case of Acknowledgements (Section 4.6.4), Updates (Section 3.7) and IHUs (Section 3.4.2), then the TLV MUST be sent early enough to meet the explicit deadline (with a small margin to allow for propagation delays). In all other cases, the TLV SHOULD be sent out within one- half of the Multicast Hello interval. In order to avoid packet drops (either at the sender or at the receiver), a delay SHOULD be introduced between successive packets sent out on the same interface, within the constraints of the previous paragraph. Note however that such packet pacing might impair the ability of some link layers (e.g., IEEE 802.11 [IEEE802.11]) to perform packet aggregation. 3.2. Data Structures In this section, we give a description of the data structures that every Babel speaker maintains. This description is conceptual: a Babel speaker may use different data structures as long as the resulting protocol is the same as the one described in this document. For example, rather than maintaining a single table containing both selected and unselected (fallback) routes, as described in Section 3.2.6 below, an actual implementation would probably use two tables, one with selected routes and one with fallback routes. Chroboczek & Schinazi Expires February 26, 2021 [Page 13] Internet-Draft The Babel Routing Protocol August 2020 3.2.1. Sequence number arithmetic Sequence numbers (seqnos) appear in a number of Babel data structures, and they are interpreted as integers modulo 2^16. For the purposes of this document, arithmetic on sequence numbers is defined as follows. Given a seqno s and a non-negative integer n, the sum of s and n is defined by s + n (modulo 2^16) = (s + n) MOD 2^16 or, equivalently, s + n (modulo 2^16) = (s + n) AND 65535 where MOD is the modulo operation yielding a non-negative integer and AND is the bitwise conjunction operation. Given two sequence numbers s and s', the relation s is less than s' (s < s') is defined by s < s' (modulo 2^16) when 0 < ((s' - s) MOD 2^16) < 32768 or equivalently s < s' (modulo 2^16) when s /= s' and ((s' - s) AND 32768) = 0. 3.2.2. Node Sequence Number A node's sequence number is a 16-bit integer that is included in route updates sent for routes originated by this node. A node increments its sequence number (modulo 2^16) whenever it receives a request for a new sequence number (Section 3.8.1.2). A node SHOULD NOT increment its sequence number (seqno) spontaneously, since increasing seqnos makes it less likely that other nodes will have feasible alternate routes when their selected routes fail. 3.2.3. The Interface Table The interface table contains the list of interfaces on which the node speaks the Babel protocol. Every interface table entry contains the interface's outgoing Multicast Hello seqno, a 16-bit integer that is sent with each Multicast Hello TLV on this interface and is incremented (modulo 2^16) whenever a Multicast Hello is sent. (Note that an interface's Multicast Hello seqno is unrelated to the node's seqno.) Chroboczek & Schinazi Expires February 26, 2021 [Page 14] Internet-Draft The Babel Routing Protocol August 2020 There are two timers associated with each interface table entry. The periodic Multicast Hello timer governs the sending of scheduled Multicast Hello and IHU packets (Section 3.4. The periodic Update timer governs the sending of periodic route updates (Section 3.7.1). See Appendix B for suggested time constants. 3.2.4. The Neighbour Table The neighbour table contains the list of all neighbouring interfaces from which a Babel packet has been recently received. The neighbour table is indexed by pairs of the form (interface, address), and every neighbour table entry contains the following data: o the local node's interface over which this neighbour is reachable; o the address of the neighbouring interface; o a history of recently received Multicast Hello packets from this neighbour; this can, for example, be a sequence of n bits, for some small value n, indicating which of the n hellos most recently sent by this neighbour have been received by the local node; o a history of recently received Unicast Hello packets from this neighbour; o the "transmission cost" value from the last IHU packet received from this neighbour, or FFFF hexadecimal (infinity) if the IHU hold timer for this neighbour has expired; o the expected incoming Multicast Hello sequence number for this neighbour, an integer modulo 2^16. o the expected incoming Unicast Hello sequence number for this neighbour, an integer modulo 2^16. o the outgoing Unicast Hello sequence number for this neighbour, an integer modulo 2^16 that is sent with each Unicast Hello TLV to this neighbour and is incremented (modulo 2^16) whenever a Unicast Hello is sent. (Note that the outgoing Unicast Hello seqno for a neighbour is distinct from the interface's outgoing Multicast Hello seqno.) There are three timers associated with each neighbour entry -- the multicast hello timer, which is set to the interval value carried by scheduled Multicast Hello TLVs sent by this neighbour, the unicast hello timer, which is set to the interval value carried by scheduled Unicast Hello TLVs, and the IHU timer, which is set to a small Chroboczek & Schinazi Expires February 26, 2021 [Page 15] Internet-Draft The Babel Routing Protocol August 2020 multiple of the interval carried in IHU TLVs (see "IHU Hold time" in Appendix B for suggested values). Note that the neighbour table is indexed by IP addresses, not by router-ids: neighbourship is a relationship between interfaces, not between nodes. Therefore, two nodes with multiple interfaces can participate in multiple neighbourship relationships, a situation that can notably arise when wireless nodes with multiple radios are involved. 3.2.5. The Source Table The source table is used to record feasibility distances. It is indexed by triples of the form (prefix, plen, router-id), and every source table entry contains the following data: o the prefix (prefix, plen), where plen is the prefix length in bits, that this entry applies to; o the router-id of a router originating this prefix; o a pair (seqno, metric), this source's feasibility distance. There is one timer associated with each entry in the source table -- the source garbage-collection timer. It is initialised to a time on the order of minutes and reset as specified in Section 3.7.3. 3.2.6. The Route Table The route table contains the routes known to this node. It is indexed by triples of the form (prefix, plen, neighbour), and every route table entry contains the following data: o the source (prefix, plen, router-id) for which this route is advertised; o the neighbour (an entry in the neighbour table) that advertised this route; o the metric with which this route was advertised by the neighbour, or FFFF hexadecimal (infinity) for a recently retracted route; o the sequence number with which this route was advertised; o the next-hop address of this route; Chroboczek & Schinazi Expires February 26, 2021 [Page 16] Internet-Draft The Babel Routing Protocol August 2020 o a boolean flag indicating whether this route is selected, i.e., whether it is currently being used for forwarding and is being advertised. There is one timer associated with each route table entry -- the route expiry timer. It is initialised and reset as specified in Section 3.5.3. Note that there are two distinct (seqno, metric) pairs associated to each route: the route's distance, which is stored in the route table, and the feasibility distance, stored in the source table and shared between all routes with the same source. 3.2.7. The Table of Pending Seqno Requests The table of pending seqno requests contains a list of seqno requests that the local node has sent (either because they have been originated locally, or because they were forwarded) and to which no reply has been received yet. This table is indexed by triples of the form (prefix, plen, router-id), and every entry in this table contains the following data: o the prefix, plen, router-id, and seqno being requested; o the neighbour, if any, on behalf of which we are forwarding this request; o a small integer indicating the number of times that this request will be resent if it remains unsatisfied. There is one timer associated with each pending seqno request; it governs both the resending of requests and their expiry. 3.3. Acknowledgments and acknowledgment requests A Babel speaker may request that a neighbour receiving a given packet reply with an explicit acknowledgment within a given time. While the use of acknowledgment requests is optional, every Babel speaker MUST be able to reply to such a request. An acknowledgment MUST be sent to a unicast destination. On the other hand, acknowledgment requests may be sent to either unicast or multicast destinations, in which case they request an acknowledgment from all of the receiving nodes. When to request acknowledgments is a matter of local policy; the simplest strategy is to never request acknowledgments and to rely on periodic updates to ensure that any reachable routes are eventually Chroboczek & Schinazi Expires February 26, 2021 [Page 17] Internet-Draft The Babel Routing Protocol August 2020 propagated throughout the routing domain. In order to improve convergence speed and reduce the amount of control traffic, acknowledgment requests MAY be used in order to reliably send urgent updates (Section 3.7.2) and retractions (Section 3.5.4), especially when the number of neighbours on a given interface is small. Since Babel is designed to deal gracefully with packet loss on unreliable media, sending all packets with acknowledgment requests is not necessary, and NOT RECOMMENDED, as the acknowledgments cause additional traffic and may force additional Address Resolution Protocol (ARP) or Neighbour Discovery (ND) exchanges. 3.4. Neighbour Acquisition Neighbour acquisition is the process by which a Babel node discovers the set of neighbours heard over each of its interfaces and ascertains bidirectional reachability. On unreliable media, neighbour acquisition additionally provides some statistics that may be useful for link quality computation. Before it can exchange routing information with a neighbour, a Babel node MUST create an entry for that neighbour in the neighbour table. When to do that is implementation-specific; suitable strategies include creating an entry when any Babel packet is received, or creating an entry when a Hello TLV is parsed. Similarly, in order to conserve system resources, an implementation SHOULD discard an entry when it has been unused for long enough; suitable strategies include dropping the neighbour after a timeout, and dropping a neighbour when the associated Hello histories become empty (see Appendix A.2). 3.4.1. Reverse Reachability Detection Every Babel node sends Hello TLVs to its neighbours to indicate that it is alive, at regular or irregular intervals. Each Hello TLV carries an increasing (modulo 2^16) sequence number and an upper bound on the time interval until the next Hello of the same type (see below). If the time interval is set to 0, then the Hello TLV does not establish a new promise: the deadline carried by the previous Hello of the same type still applies to the next Hello (if the most recent scheduled Hello of the right kind was received at time t0 and carried interval i, then the previous promise of sending another Hello before time t0 + i still holds). We say that a Hello is "scheduled" if it carries a non-zero interval, and "unscheduled" otherwise. There are two kinds of Hellos: Multicast Hellos, which use a per- interface Hello counter (the Multicast Hello seqno), and Unicast Hellos, which use a per-neighbour counter (the Unicast Hello seqno). A Multicast Hello with a given seqno MUST be sent to all neighbours Chroboczek & Schinazi Expires February 26, 2021 [Page 18] Internet-Draft The Babel Routing Protocol August 2020 on a given interface, either by sending it to a multicast address or by sending it to one unicast address per neighbour (hence, the term "Multicast Hello" is a slight misnomer). A Unicast Hello carrying a given seqno should normally be sent to just one neighbour (over unicast), since the sequence numbers of different neighbours are not in general synchronised. Multicast Hellos sent over multicast can be used for neighbour discovery; hence, a node SHOULD send periodic (scheduled) Multicast Hellos unless neighbour discovery is performed by means outside of the Babel protocol. A node MAY send Unicast Hellos or unscheduled Hellos of either kind for any reason, such as reducing the amount of multicast traffic or improving reliability on link technologies with poor support for link-layer multicast. A node MAY send a scheduled Hello ahead of time. A node MAY change its scheduled Hello interval. The Hello interval MAY be decreased at any time; it MAY be increased immediately before sending a Hello TLV, but SHOULD NOT be increased at other times. (Equivalently, a node SHOULD send a scheduled Hello immediately after increasing its Hello interval.) How to deal with received Hello TLVs and what statistics to maintain are considered local implementation matters; typically, a node will maintain some sort of history of recently received Hellos. An example of a suitable algorithm is described in Appendix A.1. After receiving a Hello, or determining that it has missed one, the node recomputes the association's cost (Section 3.4.3) and runs the route selection procedure (Section 3.6). 3.4.2. Bidirectional Reachability Detection In order to establish bidirectional reachability, every node sends periodic IHU ("I Heard You") TLVs to each of its neighbours. Since IHUs carry an explicit interval value, they MAY be sent less often than Hellos in order to reduce the amount of routing traffic in dense networks; in particular, they SHOULD be sent less often than Hellos over links with little packet loss. While IHUs are conceptually unicast, they MAY be sent to a multicast address in order to avoid an ARP or Neighbour Discovery exchange and to aggregate multiple IHUs into a single packet. In addition to the periodic IHUs, a node MAY, at any time, send an unscheduled IHU packet. It MAY also, at any time, decrease its IHU interval, and it MAY increase its IHU interval immediately before sending an IHU, but SHOULD NOT increase it at any other time. Chroboczek & Schinazi Expires February 26, 2021 [Page 19] Internet-Draft The Babel Routing Protocol August 2020 (Equivalently, a node SHOULD send an extra IHU immediately after increasing its Hello interval.) Every IHU TLV contains two pieces of data: the link's rxcost (reception cost) from the sender's perspective, used by the neighbour for computing link costs (Section 3.4.3), and the interval between periodic IHU packets. A node receiving an IHU sets the value of the txcost (transmission cost) maintained in the neighbour table to the value contained in the IHU, and resets the IHU timer associated to this neighbour to a small multiple of the interval value received in the IHU (see "IHU Hold time" in Appendix B for suggested values). When a neighbour's IHU timer expires, the neighbour's txcost is set to infinity. After updating a neighbour's txcost, the receiving node recomputes the neighbour's cost (Section 3.4.3) and runs the route selection procedure (Section 3.6). 3.4.3. Cost Computation A neighbourship association's link cost is computed from the values maintained in the neighbour table: the statistics kept in the neighbour table about the reception of Hellos, and the txcost computed from received IHU packets. For every neighbour, a Babel node computes a value known as this neighbour's rxcost. This value is usually derived from the Hello history, which may be combined with other data, such as statistics maintained by the link layer. The rxcost is sent to a neighbour in each IHU. Since nodes do not necessarily send periodic Unicast Hellos but do usually send periodic Multicast Hellos (Section 3.4.1), a node SHOULD use an algorithm that yields a finite rxcost when only Multicast Hellos are received, unless interoperability with nodes that only send Multicast Hellos is not required. How the txcost and rxcost are combined in order to compute a link's cost is a matter of local policy; as far as Babel's correctness is concerned, only the following conditions MUST be satisfied: o the cost is strictly positive; o if no Hello TLVs of either kind were received recently, then the cost is infinite; o if the txcost is infinite, then the cost is infinite. Chroboczek & Schinazi Expires February 26, 2021 [Page 20] Internet-Draft The Babel Routing Protocol August 2020 See Appendix A.2 for RECOMMENDED strategies for computing a link's cost. 3.5. Routing Table Maintenance Conceptually, a Babel update is a quintuple (prefix, plen, router-id, seqno, metric), where (prefix, plen) is the prefix for which a route is being advertised, router-id is the router-id of the router originating this update, seqno is a nondecreasing (modulo 2^16) integer that carries the originating router seqno, and metric is the announced metric. Before being accepted, an update is checked against the feasibility condition (Section 3.5.1), which ensures that the route does not create a routing loop. If the feasibility condition is not satisfied, the update is either ignored or prevents the route from being selected, as described in Section 3.5.3. If the feasibility condition is satisfied, then the update cannot possibly cause a routing loop. 3.5.1. The Feasibility Condition The feasibility condition is applied to all received updates. The feasibility condition compares the metric in the received update with the metrics of the updates previously sent by the receiving node; updates that fail the feasibility condition, and therefore have metrics large enough to cause a routing loop, are either ignored or prevent the resulting route from being selected. A feasibility distance is a pair (seqno, metric), where seqno is an integer modulo 2^16 and metric is a positive integer. Feasibility distances are compared lexicographically, with the first component inverted: we say that a distance (seqno, metric) is strictly better than a distance (seqno', metric'), written (seqno, metric) < (seqno', metric') when seqno > seqno' or (seqno = seqno' and metric < metric') where sequence numbers are compared modulo 2^16. Given a source (prefix, plen, router-id), a node's feasibility distance for this source is the minimum, according to the ordering defined above, of the distances of all the finite updates ever sent by this particular node for the prefix (prefix, plen) and the given Chroboczek & Schinazi Expires February 26, 2021 [Page 21] Internet-Draft The Babel Routing Protocol August 2020 router-id. Feasibility distances are maintained in the source table, the exact procedure is given in Section 3.7.3. A received update is feasible when either it is a retraction (its metric is FFFF hexadecimal), or the advertised distance is strictly better, in the sense defined above, than the feasibility distance for the corresponding source. More precisely, a route advertisement carrying the quintuple (prefix, plen, router-id, seqno, metric) is feasible if one of the following conditions holds: o metric is infinite; or o no entry exists in the source table indexed by (prefix, plen, router-id); or o an entry (prefix, plen, router-id, seqno', metric') exists in the source table, and either * seqno' < seqno or * seqno = seqno' and metric < metric'. Note that the feasibility condition considers the metric advertised by the neighbour, not the route's metric; hence, a fluctuation in a neighbour's cost cannot render a selected route unfeasible. Note further that retractions (updates with infinite metric) are always feasible, since they cannot possibly cause a routing loop. 3.5.2. Metric Computation A route's metric is computed from the metric advertised by the neighbour and the neighbour's link cost. Just like cost computation, metric computation is considered a local policy matter; as far as Babel is concerned, the function M(c, m) used for computing a metric from a locally computed link cost c and the metric m advertised by a neighbour MUST only satisfy the following conditions: o if c is infinite, then M(c, m) is infinite; o M is strictly monotonic: M(c, m) > m. Additionally, the metric SHOULD satisfy the following condition: o M is left-distributive: if m <= m', then M(c, m) <= M(c, m'). While strict monotonicity is essential to the integrity of the network (persistent routing loops may arise if it is not satisfied), left distributivity is not: if it is not satisfied, Babel will still Chroboczek & Schinazi Expires February 26, 2021 [Page 22] Internet-Draft The Babel Routing Protocol August 2020 converge to a loop-free configuration, but might not reach a global optimum (in fact, a global optimum may not even exist). The conditions above are easily satisfied by using the additive metric, i.e., by defining M(c, m) = c + m. Since the additive metric is useful with a large range of cost computation strategies, it is the RECOMMENDED default. See also Appendix C, which describes a technique that makes it possible to tweak the values of individual metrics without running the risk of creating routing loops. 3.5.3. Route Acquisition When a Babel node receives an update (prefix, plen, router-id, seqno, metric) from a neighbour neigh, it checks whether it already has a route table entry indexed by (prefix, plen, neigh). If no such entry exists: o if the update is unfeasible, it MAY be ignored; o if the metric is infinite (the update is a retraction of a route we do not know about), the update is ignored; o otherwise, a new entry is created in the route table, indexed by (prefix, plen, neigh), with source equal to (prefix, plen, router- id), seqno equal to seqno and an advertised metric equal to the metric carried by the update. If such an entry exists: o if the entry is currently selected, the update is unfeasible, and the router-id of the update is equal to the router-id of the entry, then the update MAY be ignored; o otherwise, the entry's sequence number, advertised metric, metric, and router-id are updated and, if the advertised metric is not infinite, the route's expiry timer is reset to a small multiple of the Interval value included in the update (see "Route Hold time" in Appendix B for suggested values). If the update is unfeasible, then the (now unfeasible) entry MUST be immediately unselected. If the update caused the router-id of the entry to change, an update (possibly a retraction) MUST be sent in a timely manner as described in Section 3.7.2. Note that the route table may contain unfeasible routes, either because they were created by an unfeasible update or due to a metric fluctuation. Such routes are never selected, since they are not known to be loop-free; should all the feasible routes become Chroboczek & Schinazi Expires February 26, 2021 [Page 23] Internet-Draft The Babel Routing Protocol August 2020 unusable, however, the unfeasible routes can be made feasible and therefore possible to select by sending requests along them (see Section 3.8.2). When a route's expiry timer triggers, the behaviour depends on whether the route's metric is finite. If the metric is finite, it is set to infinity and the expiry timer is reset. If the metric is already infinite, the route is flushed from the route table. After the route table is updated, the route selection procedure (Section 3.6) is run. 3.5.4. Hold Time When a prefix P is retracted, because all routes are unfeasible or have an infinite metric (whether due to the expiry timer or to other reasons), and a shorter prefix P' that covers P is reachable, P' cannot in general be used for routing packets destined to P without running the risk of creating a routing loop (Section 2.8). To avoid this issue, whenever a prefix P is retracted, a route table entry with infinite metric is maintained as described in Section 3.5.3 above. As long as this entry is maintained, packets destined to an address within P MUST NOT be forwarded by following a route for a shorter prefix. This entry is removed as soon as a finite-metric update for prefix P is received and the resulting route selected. If no such update is forthcoming, the infinite metric entry SHOULD be maintained at least until it is guaranteed that no neighbour has selected the current node as next-hop for prefix P. This can be achieved by either: o waiting until the route's expiry timer has expired (Section 3.5.3); o sending a retraction with an acknowledgment request (Section 3.3) to every reachable neighbour that has not explicitly retracted prefix P, and waiting for all acknowledgments. The former option is simpler and ensures that at that point, any routes for prefix P pointing at the current node have expired. However, since the expiry time can be as high as a few minutes, doing that prevents automatic aggregation by creating spurious black-holes for aggregated routes. The latter option is RECOMMENDED as it dramatically reduces the time for which a prefix is unreachable in the presence of aggregated routes. Chroboczek & Schinazi Expires February 26, 2021 [Page 24] Internet-Draft The Babel Routing Protocol August 2020 3.6. Route Selection Route selection is the process by which a single route for a given prefix is selected to be used for forwarding packets and to be re- advertised to a node's neighbours. Babel is designed to allow flexible route selection policies. As far as the algorithm's correctness is concerned, the route selection policy MUST only satisfy the following properties: o a route with infinite metric (a retracted route) is never selected; o an unfeasible route is never selected. Babel nodes using different route selection strategies will interoperate and not create routing loops as long as these two properties hold. Route selection MUST NOT take seqnos into account: a route MUST NOT be preferred just because it carries a higher (more recent) seqno. Doing otherwise would cause route oscillation while a new seqno propagates across the network, and might create persistent blackholes if the metric being used is not left-distributive (Section 3.5.2). The obvious route selection strategy is to pick, for every destination, the feasible route with minimal metric. When all metrics are stable, this approach ensures convergence to a tree of shortest paths (assuming that the metric is left-distributive, see Section 3.5.2). There are two reasons, however, why this strategy may lead to instability in the presence of continuously varying metrics. First, if two parallel routes oscillate around a common value, then the smallest metric strategy will keep switching between the two. Second, when a route is selected, congestion along it increases, which might increase packet loss, which in turn could cause its metric to increase; this is a feedback loop, of the kind that is prone to causing persistent oscillations. In order to limit these kinds of instabilities, a route selection strategy SHOULD include some form of hysteresis, i.e., be sensitive to a route's history: if a route is currently selected, then the strategy should only switch to a different route if the latter has been consistently good for some period of time. A RECOMMENDED hysteresis algorithm is given in Appendix A.3. After the route selection procedure is run, triggered updates (Section 3.7.2) and requests (Section 3.8.2) are sent. Chroboczek & Schinazi Expires February 26, 2021 [Page 25] Internet-Draft The Babel Routing Protocol August 2020 3.7. Sending Updates A Babel speaker advertises to its neighbours its set of selected routes. Normally, this is done by sending one or more multicast packets containing Update TLVs on all of its connected interfaces; however, on link technologies where multicast is significantly more expensive than unicast, a node MAY choose to send multiple copies of updates in unicast packets, especially when the number of neighbours is small. Additionally, in order to ensure that any black-holes are reliably cleared in a timely manner, a Babel node may send retractions (updates with an infinite metric) for any recently retracted prefixes. If an update is for a route injected into the Babel domain by the local node (e.g., it carries the address of a local interface, the prefix of a directly attached network, or a prefix redistributed from a different routing protocol), the router-id is set to the local node's router-id, the metric is set to some arbitrary finite value (typically 0), and the seqno is set to the local router's sequence number. If an update is for a route learned from another Babel speaker, the router-id and sequence number are copied from the route table entry, and the metric is computed as specified in Section 3.5.2. 3.7.1. Periodic Updates Every Babel speaker MUST advertise each of its selected routes on every interface, at least once every Update interval. Since Babel doesn't suffer from routing loops (there is no "counting to infinity") and relies heavily on triggered updates (Section 3.7.2), this full dump only needs to happen infrequently (see Appendix B for suggested intervals). 3.7.2. Triggered Updates In addition to periodic routing updates, a Babel speaker sends unscheduled, or triggered, updates in order to inform its neighbours of a significant change in the network topology. A change of router-id for the selected route to a given prefix may be indicative of a routing loop in formation; hence, whenever it changes the selected router-id for a given destination, a node MUST send an update as an urgent TLV (as defined in Section 3.1). Additionally, it SHOULD make a reasonable attempt at ensuring that all reachable neighbours receive this update. Chroboczek & Schinazi Expires February 26, 2021 [Page 26] Internet-Draft The Babel Routing Protocol August 2020 There are two strategies for ensuring that. If the number of neighbours is small, then it is reasonable to send the update together with an acknowledgment request; the update is resent until all neighbours have acknowledged the packet, up to some number of times. If the number of neighbours is large, however, requesting acknowledgments from all of them might cause a non-negligible amount of network traffic; in that case, it may be preferable to simply repeat the update some reasonable number of times (say, 3 for wireless and 2 for wired links). The number of copies MUST NOT exceed 5, and the copies SHOULD be separated by a small delay, as described in Section 3.1. A route retraction is somewhat less worrying: if the route retraction doesn't reach all neighbours, a black-hole might be created, which, unlike a routing loop, does not endanger the integrity of the network. When a route is retracted, a node SHOULD send a triggered update and SHOULD make a reasonable attempt at ensuring that all neighbours receive this retraction. Finally, a node MAY send a triggered update when the metric for a given prefix changes in a significant manner, due to a received update, because a link's cost has changed, or because a different next hop has been selected. A node SHOULD NOT send triggered updates for other reasons, such as when there is a minor fluctuation in a route's metric, when the selected next hop changes without inducing a significant change to the route's metric, or to propagate a new sequence number (except to satisfy a request, as specified in Section 3.8). 3.7.3. Maintaining Feasibility Distances Before sending an update (prefix, plen, router-id, seqno, metric) with finite metric (i.e., not a route retraction), a Babel node updates the feasibility distance maintained in the source table. This is done as follows. If no entry indexed by (prefix, plen, router-id) exists in the source table, then one is created with value (prefix, plen, router-id, seqno, metric). If an entry (prefix, plen, router-id, seqno', metric') exists, then it is updated as follows: o if seqno > seqno', then seqno' := seqno, metric' := metric; o if seqno = seqno' and metric' > metric, then metric' := metric; o otherwise, nothing needs to be done. Chroboczek & Schinazi Expires February 26, 2021 [Page 27] Internet-Draft The Babel Routing Protocol August 2020 The garbage-collection timer for the entry is then reset. Note that the feasibility distance is not updated and the garbage-collection timer is not reset when a retraction (an update with infinite metric) is sent. When the garbage-collection timer expires, the entry is removed from the source table. 3.7.4. Split Horizon When running over a transitive, symmetric link technology, e.g., a point-to-point link or a wired LAN technology such as Ethernet, a Babel node SHOULD use an optimisation known as split horizon. When split horizon is used on a given interface, a routing update for prefix P is not sent on the particular interface over which the selected route towards prefix P was learnt. Split horizon SHOULD NOT be applied to an interface unless the interface is known to be symmetric and transitive; in particular, split horizon is not applicable to decentralised wireless link technologies (e.g., IEEE 802.11 in ad hoc mode) when routing updates are sent over multicast. 3.8. Explicit Requests In normal operation, a node's route table is populated by the regular and triggered updates sent by its neighbours. Under some circumstances, however, a node sends explicit requests in order to cause a resynchronisation with the source after a mobility event or to prevent a route from spuriously expiring. The Babel protocol provides two kinds of explicit requests: route requests, which simply request an update for a given prefix, and seqno requests, which request an update for a given prefix with a specific sequence number. The former are never forwarded; the latter are forwarded if they cannot be satisfied by the receiver. 3.8.1. Handling Requests Upon receiving a request, a node either forwards the request or sends an update in reply to the request, as described in the following sections. If this causes an update to be sent, the update is either sent to a multicast address on the interface on which the request was received, or to the unicast address of the neighbour that sent the request. The exact behaviour is different for route requests and seqno requests. Chroboczek & Schinazi Expires February 26, 2021 [Page 28] Internet-Draft The Babel Routing Protocol August 2020 3.8.1.1. Route Requests When a node receives a route request for a given prefix, it checks its route table for a selected route to this exact prefix. If such a route exists, it MUST send an update (over unicast or over multicast); if such a route does not exist, it MUST send a retraction for that prefix. When a node receives a wildcard route request, it SHOULD send a full route table dump. Full route dumps SHOULD be rate-limited, especially if they are sent over multicast. 3.8.1.2. Seqno Requests When a node receives a seqno request for a given router-id and sequence number, it checks whether its route table contains a selected entry for that prefix. If a selected route for the given prefix exists, it has finite metric, and either the router-ids are different or the router-ids are equal and the entry's sequence number is no smaller (modulo 2^16) than the requested sequence number, the node MUST send an update for the given prefix. If the router-ids match but the requested seqno is larger (modulo 2^16) than the route entry's, the node compares the router-id against its own router-id. If the router-id is its own, then it increases its sequence number by 1 (modulo 2^16) and sends an update. A node MUST NOT increase its sequence number by more than 1 in reaction to a single seqno request. Otherwise, if the requested router-id is not its own, the received node consults the hop count field of the request. If the hop count is 2 or more, and the node is advertising the prefix to its neighbours, the node selects a neighbour to forward the request to as follows: o if the node has one or more feasible routes toward the requested prefix with a next hop that is not the requesting node, then the node MUST forward the request to the next hop of one such route; o otherwise, if the node has one or more (not feasible) routes to the requested prefix with a next hop that is not the requesting node, then the node SHOULD forward the request to the next hop of one such route. In order to actually forward the request, the node decrements the hop count and sends the request in a unicast packet destined to the selected neighbour. The forwarded request SHOULD be sent as an urgent TLV (as defined in Section 3.1). Chroboczek & Schinazi Expires February 26, 2021 [Page 29] Internet-Draft The Babel Routing Protocol August 2020 A node SHOULD maintain a list of recently forwarded seqno requests and forward the reply (an update with a seqno sufficiently large to satisfy the request) as an urgent TLV (as defined in Section 3.1). A node SHOULD compare every incoming seqno request against its list of recently forwarded seqno requests and avoid forwarding it if it is redundant (i.e., if it has recently sent a request with the same prefix, router-id and a seqno that is not smaller modulo 2^16). Since the request-forwarding mechanism does not necessarily obey the feasibility condition, it may get caught in routing loops; hence, requests carry a hop count to limit the time during which they remain in the network. However, since requests are only ever forwarded as unicast packets, the initial hop count need not be kept particularly low, and performing an expanding horizon search is not necessary. A single request MUST NOT be duplicated: it MUST NOT be forwarded to a multicast address, and it MUST NOT be forwarded to multiple neighbours. However, if a seqno request is resent by its originator, the subsequent copies may be forwarded to a different neighbour than the initial one. 3.8.2. Sending Requests A Babel node MAY send a route or seqno request at any time, to a multicast or a unicast address; there is only one case when originating requests is required (Section 3.8.2.1). 3.8.2.1. Avoiding Starvation When a route is retracted or expires, a Babel node usually switches to another feasible route for the same prefix. It may be the case, however, that no such routes are available. A node that has lost all feasible routes to a given destination but still has unexpired unfeasible routes to that destination MUST send a seqno request; if it doesn't have any such routes, it MAY still send a seqno request. The router-id of the request is set to the router- id of the route that it has just lost, and the requested seqno is the value contained in the source table plus 1. The request carries a hop count, which is used as a last-resort mechanism to ensure that it eventually vanishes from the network; it MAY be set to any value that is larger than the diameter of the network (64 is a suitable default value). If the node has any (unfeasible) routes to the requested destination, then it MUST send the request to at least one of the next-hop neighbours that advertised these routes, and SHOULD send it to all of them; in any case, it MAY send the request to any other neighbours, whether they advertise a route to the requested destination or not. Chroboczek & Schinazi Expires February 26, 2021 [Page 30] Internet-Draft The Babel Routing Protocol August 2020 A simple implementation strategy is therefore to unconditionally multicast the request over all interfaces. Similar requests will be sent by other nodes that are affected by the route's loss. If the network is still connected, and assuming no packet loss, then at least one of these requests will be forwarded to the source, resulting in a route being advertised with a new sequence number. (Due to duplicate suppression, only a small number of such requests are expected to actually reach the source.) In order to compensate for packet loss, a node SHOULD repeat such a request a small number of times if no route becomes feasible within a short time (see "Request Timeout" in Appendix B for suggested values). In the presence of heavy packet loss, however, all such requests might be lost; in that case, the mechanism in the next section will eventually ensure that a new seqno is received. 3.8.2.2. Dealing with Unfeasible Updates When a route's metric increases, a node might receive an unfeasible update for a route that it has currently selected. As specified in Section 3.5.1, the receiving node will either ignore the update or unselect the route. In order to keep routes from spuriously expiring because they have become unfeasible, a node SHOULD send a unicast seqno request when it receives an unfeasible update for a route that is currently selected. The requested sequence number is computed from the source table as in Section 3.8.2.1 above. Additionally, since metric computation does not necessarily coincide with the delay in propagating updates, a node might receive an unfeasible update from a currently unselected neighbour that is preferable to the currently selected route (e.g., because it has a much smaller metric); in that case, the node SHOULD send a unicast seqno request to the neighbour that advertised the preferable update. 3.8.2.3. Preventing Routes from Expiring In normal operation, a route's expiry timer never triggers: since a route's hold time is computed from an explicit interval included in Update TLVs, a new update (possibly a retraction) should arrive in time to prevent a route from expiring. In the presence of packet loss, however, it may be the case that no update is successfully received for an extended period of time, causing a route to expire. In order to avoid such spurious expiry, shortly before a selected route expires, a Babel node SHOULD send a Chroboczek & Schinazi Expires February 26, 2021 [Page 31] Internet-Draft The Babel Routing Protocol August 2020 unicast route request to the neighbour that advertised this route; since nodes always send either updates or retractions in response to non-wildcard route requests (Section 3.8.1.1), this will usually result in the route being either refreshed or retracted. 4. Protocol Encoding A Babel packet MUST be sent as the body of a UDP datagram, with network-layer hop count set to 1, destined to a well-known multicast address or to a unicast address, over IPv4 or IPv6; in the case of IPv6, these addresses are link-local. Both the source and destination UDP port are set to a well-known port number. A Babel packet MUST be silently ignored unless its source address is either a link-local IPv6 address or an IPv4 address belonging to the local network, and its source port is the well-known Babel port. It MAY be silently ignored if its destination address is a global IPv6 address. In order to minimise the number of packets being sent while avoiding lower-layer fragmentation, a Babel node SHOULD maximise the size of the packets it sends, up to the outgoing interface's MTU adjusted for lower-layer headers (28 octets for UDP over IPv4, 48 octets for UDP over IPv6). It MUST NOT send packets larger than the attached interface's MTU adjusted for lower-layer headers or 512 octets, whichever is larger, but not exceeding 2^16 - 1 adjusted for lower- layer headers. Every Babel speaker MUST be able to receive packets that are as large as any attached interface's MTU adjusted for lower- layer headers or 512 octets, whichever is larger. Babel packets MUST NOT be sent in IPv6 Jumbograms [RFC2675]. 4.1. Data Types 4.1.1. Representation of integers All multi-octet fields that represent integers are encoded with the most significant octet first (in Big-Endian format [IEN137], also called Network Order). The base protocol only carries unsigned values; if an extension needs to carry signed values, it will need to specify their encoding (e.g., two's complement). 4.1.2. Interval Relative times are carried as 16-bit values specifying a number of centiseconds (hundredths of a second). This allows times up to roughly 11 minutes with a granularity of 10ms, which should cover all reasonable applications of Babel (see also Appendix B). Chroboczek & Schinazi Expires February 26, 2021 [Page 32] Internet-Draft The Babel Routing Protocol August 2020 4.1.3. Router-Id A router-id is an arbitrary 8-octet value. A router-id MUST NOT consist of either all binary zeroes (0000000000000000 hexadecimal) or all binary ones (FFFFFFFFFFFFFFFF hexadecimal). 4.1.4. Address Since the bulk of the protocol is taken by addresses, multiple ways of encoding addresses are defined. Additionally, within Update TLVs a common subnet prefix may be omitted when multiple addresses are sent in a single packet -- this is known as address compression (Section 4.6.9). Address encodings: o AE 0: wildcard address. The value is 0 octets long. o AE 1: IPv4 address. Compression is allowed. 4 octets or less. o AE 2: IPv6 address. Compression is allowed. 16 octets or less. o AE 3: link-local IPv6 address. Compression is not allowed. The value is 8 octets long, a prefix of fe80::/64 is implied. The address family associated to an address encoding is either IPv4 or IPv6; it is undefined for AE 0, IPv4 for AE 1, and IPv6 for AEs 2 and 3. 4.1.5. Prefixes A network prefix is encoded just like a network address, but it is stored in the smallest number of octets that are enough to hold the significant bits (up to the prefix length). 4.2. Packet Format A Babel packet consists of a 4-octet header, followed by a sequence of TLVs (the packet body), optionally followed by a second sequence of TLVs (the packet trailer). The format is designed to be extensible; see Appendix D for extensibility considerations. Chroboczek & Schinazi Expires February 26, 2021 [Page 33] Internet-Draft The Babel Routing Protocol August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic | Version | Body length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Body ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Packet Trailer... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Magic The arbitrary but carefully chosen value 42 (decimal); packets with a first octet different from 42 MUST be silently ignored. Version This document specifies version 2 of the Babel protocol. Packets with a second octet different from 2 MUST be silently ignored. Body length The length in octets of the body following the packet header (excluding the Magic, Version and Body length fields, and excluding the packet trailer). Packet Body The packet body; a sequence of TLVs. Packet Trailer The packet trailer; another sequence of TLVs. The packet body and trailer are both sequences of TLVs. The packet body is the normal place to store TLVs; the packet trailer only contains specialised TLVs that do not need to be protected by cryptographic security mechanisms. When parsing the trailer, the receiver MUST ignore any TLV unless its definition explicitly states that it is allowed to appear there. Among the TLVs defined in this document, only Pad1 and PadN are allowed in the trailer; since these TLVs are ignored in any case, an implementation MAY silently ignore the packet trailer without even parsing it, unless it implements at least one protocol extension that defines TLVs that are allowed to appear in the trailer. 4.3. TLV Format With the exception of Pad1, all TLVs have the following structure: Chroboczek & Schinazi Expires February 26, 2021 [Page 34] Internet-Draft The Babel Routing Protocol August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type The type of the TLV. Length The length of the body in octets, exclusive of the Type and Length fields. Payload The TLV payload, which consists of a body and, for selected TLV types, an optional list of sub-TLVs. TLVs with an unknown type value MUST be silently ignored. 4.4. Sub-TLV Format Every TLV carries an explicit length in its header; however, most TLVs are self-terminating, in the sense that it is possible to determine the length of the body without reference to the explicit Length field. If a TLV has a self-terminating format, then the space between the natural size of the TLV and the size announced in the Length field may be used to store a sequence of sub-TLVs. Sub-TLVs have the same structure as TLVs. With the exception of Pad1, all TLVs have the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Body... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type The type of the sub-TLV. Length The length of the body in octets, exclusive of the Type and Length fields. Body The sub-TLV body, the interpretation of which depends on both the type of the sub-TLV and the type of the TLV within which it is embedded. Chroboczek & Schinazi Expires February 26, 2021 [Page 35] Internet-Draft The Babel Routing Protocol August 2020 The most-significant bit of the sub-TLV type (the bit with value 80 hexadecimal), is called the mandatory bit; in other words, sub-TLV types 128 through 255 have the mandatory bit set. This bit indicates how to handle unknown sub-TLVs. If the mandatory bit is not set, then an unknown sub-TLV MUST be silently ignored, and the rest of the TLV is processed normally. If the mandatory bit is set, then the whole enclosing TLV MUST be silently ignored (except for updating the parser state by a Router-Id, Next-Hop or Update TLV, as described in the next section). 4.5. Parser state and encoding of updates In a large network, the bulk of Babel traffic consists of route updates; hence, some care has been given to encoding them efficiently. The data conceptually contained in an update (Section 3.5) is split into three pieces: o the prefix, seqno and metric are contained in the Update TLV itself (Section 4.6.9); o the router-id is taken from Router-Id TLV that precedes the Update TLV, and may be shared among multiple Update TLVs (Section 4.6.7); o the next hop is taken either from the source-address of the network-layer packet that contains the Babel packet, or from an explicit Next-Hop TLV (Section 4.6.8). In addition to the above, an Update TLV can omit a prefix of the prefix being announced, which is then extracted from the preceding Update TLV in the same address family (IPv4 or IPv6). Finally, as a special optimisation for the case when a router-id coincides with the interface-id part of an IPv6 address, Router-ID TLV itself may be omitted and the router-id derived from the low-order bits of the advertised prefix (Section 4.6.9). In order to implement these compression techniques, Babel uses a stateful parser: a TLV may refer to data from a previous TLV. The parser state consists of the following pieces of data: o for each address encoding that allows compression, the current default prefix; this is undefined at the start of the packet, and is updated by each Update TLV with the Prefix flag set (Section 4.6.9); o for each address family (IPv4 or IPv6), the current next-hop; this is the source address of the enclosing packet for the matching address family at the start of a packet, and is updated by each Next-Hop TLV (Section 4.6.8); Chroboczek & Schinazi Expires February 26, 2021 [Page 36] Internet-Draft The Babel Routing Protocol August 2020 o the current router-id; this is undefined at the start of the packet, and is updated by each Router-ID TLV (Section 4.6.7) and by each Update TLV with Router-Id flag set. Since the parser state must be identical across implementations, it is updated before checking for mandatory sub-TLVs: parsing a TLV MUST update the parser state even if the TLV is otherwise ignored due to an unknown mandatory sub-TLV or for any other reason. None of the TLVs that modify the parser state are allowed in the packet trailer; hence, an implementation may choose to use a dedicated stateless parser to parse the packet trailer. 4.6. Details of Specific TLVs 4.6.1. Pad1 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0 | +-+-+-+-+-+-+-+-+ Fields : Type Set to 0 to indicate a Pad1 TLV. This TLV is silently ignored on reception. It is allowed in the packet trailer. 4.6.2. PadN 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | MBZ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 1 to indicate a PadN TLV. Length The length of the body in octets, exclusive of the Type and Length fields. MBZ Must be zero, set to 0 on transmission. Chroboczek & Schinazi Expires February 26, 2021 [Page 37] Internet-Draft The Babel Routing Protocol August 2020 This TLV is silently ignored on reception. It is allowed in the packet trailer. 4.6.3. Acknowledgment Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV requests that the receiver send an Acknowledgment TLV within the number of centiseconds specified by the Interval field. Fields : Type Set to 2 to indicate an Acknowledgment Request TLV. Length The length of the body in octets, exclusive of the Type and Length fields. Reserved Sent as 0 and MUST be ignored on reception. Opaque An arbitrary value that will be echoed in the receiver's Acknowledgment TLV. Interval A time interval in centiseconds after which the sender will assume that this packet has been lost. This MUST NOT be 0. The receiver MUST send an Acknowledgment TLV before this time has elapsed (with a margin allowing for propagation time). This TLV is self-terminating, and allows sub-TLVs. 4.6.4. Acknowledgment 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | Opaque | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV is sent by a node upon receiving an Acknowledgment Request. Fields : Chroboczek & Schinazi Expires February 26, 2021 [Page 38] Internet-Draft The Babel Routing Protocol August 2020 Type Set to 3 to indicate an Acknowledgment TLV. Length The length of the body in octets, exclusive of the Type and Length fields. Opaque Set to the Opaque value of the Acknowledgment Request that prompted this Acknowledgment. Since Opaque values are not globally unique, this TLV MUST be sent to a unicast address. This TLV is self-terminating, and allows sub-TLVs. 4.6.5. Hello 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seqno | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV is used for neighbour discovery and for determining a neighbour's reception cost. Fields : Type Set to 4 to indicate a Hello TLV. Length The length of the body in octets, exclusive of the Type and Length fields. Flags The individual bits of this field specify special handling of this TLV (see below). Seqno If the Unicast flag is set, this is the value of the sending node's outgoing Unicast Hello seqno for this neighbour. Otherwise, it is the sending node's outgoing Multicast Hello seqno for this interface. Interval If non-zero, this is an upper bound, expressed in centiseconds, on the time after which the sending node will send a new scheduled Hello TLV with the same setting of the Unicast flag. If this is 0, then this Hello represents an unscheduled Hello, and doesn't carry any new information about times at which Hellos are sent. Chroboczek & Schinazi Expires February 26, 2021 [Page 39] Internet-Draft The Babel Routing Protocol August 2020 The Flags field is interpreted as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o U (Unicast) flag (8000 hexadecimal): if set, then this Hello represents a Unicast Hello, otherwise it represents a Multicast Hello; o X: all other bits MUST be sent as 0 and silently ignored on reception. Every time a Hello is sent, the corresponding seqno counter MUST be incremented. Since there is a single seqno counter for all the Multicast Hellos sent by a given node over a given interface, if the Unicast flag is not set, this TLV MUST be sent to all neighbors on this link, which can be achieved by sending to a multicast destination, or by sending multiple packets to the unicast addresses of all reachable neighbours. Conversely, if the Unicast flag is set, this TLV MUST be sent to a single neighbour, which can achieved by sending to a unicast destination. In order to avoid large discontinuities in link quality, multiple Hello TLVs SHOULD NOT be sent in the same packet. This TLV is self-terminating, and allows sub-TLVs. 4.6.6. IHU 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length | AE | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rxcost | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address... +-+-+-+-+-+-+-+-+-+-+-+- An IHU ("I Heard You") TLV is used for confirming bidirectional reachability and carrying a link's transmission cost. Fields : Type Set to 5 to indicate an IHU TLV. Chroboczek & Schinazi Expires February 26, 2021 [Page 40] Internet-Draft The Babel Routing Protocol August 2020 Length The length of the body in octets, exclusive of the Type and Length fields. AE The encoding of the Address field. This should be 1 or 3 in most cases. As an optimisation, it MAY be 0 if the TLV is sent to a unicast address, if the association is over a point-to-point link, or when bidirectional reachability is ascertained by means outside of the Babel protocol. Reserved Sent as 0 and MUST be ignored on reception. Rxcost The rxcost according to the sending node of the interface whose address is specified in the Address field. The value FFFF hexadecimal (infinity) indicates that this interface is unreachable. Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new IHU; this MUST NOT be 0. The receiving node will use this value in order to compute a hold time for this symmetric association. Address The address of the destination node, in the format specified by the AE field. Address compression is not allowed. Conceptually, an IHU is destined to a single neighbour. However, IHU TLVs contain an explicit destination address, and MAY be sent to a multicast address, as this allows aggregation of IHUs destined to distinct neighbours into a single packet and avoids the need for an ARP or Neighbour Discovery exchange when a neighbour is not being used for data traffic. IHU TLVs with an unknown value in the AE field MUST be silently ignored. This TLV is self-terminating, and allows sub-TLVs. 4.6.7. Router-Id 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Router-Id + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chroboczek & Schinazi Expires February 26, 2021 [Page 41] Internet-Draft The Babel Routing Protocol August 2020 A Router-Id TLV establishes a router-id that is implied by subsequent Update TLVs, as described in Section 4.5. This TLV sets the router- id even if it is otherwise ignored due to an unknown mandatory sub- TLV. Fields : Type Set to 6 to indicate a Router-Id TLV. Length The length of the body in octets, exclusive of the Type and Length fields. Reserved Sent as 0 and MUST be ignored on reception. Router-Id The router-id for routes advertised in subsequent Update TLVs. This MUST NOT consist of all zeroes or all ones. This TLV is self-terminating, and allows sub-TLVs. 4.6.8. Next Hop 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length | AE | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next hop... +-+-+-+-+-+-+-+-+-+-+-+- A Next Hop TLV establishes a next-hop address for a given address family (IPv4 or IPv6) that is implied in subsequent Update TLVs, as described in Section 4.5. This TLV sets up the next-hop for subsequent Update TLVs even if it is otherwise ignored due to an unknown mandatory sub-TLV. Fields : Type Set to 7 to indicate a Next Hop TLV. Length The length of the body in octets, exclusive of the Type and Length fields. AE The encoding of the Address field. This SHOULD be 1 (IPv4) or 3 (link-local IPv6), and MUST NOT be 0. Reserved Sent as 0 and MUST be ignored on reception. Chroboczek & Schinazi Expires February 26, 2021 [Page 42] Internet-Draft The Babel Routing Protocol August 2020 Next hop The next-hop address advertised by subsequent Update TLVs, for this address family. When the address family matches the network-layer protocol that this packet is transported over, a Next Hop TLV is not needed: in the absence of a Next Hop TLV in a given address family, the next hop address is taken to be the source address of the packet. Next Hop TLVs with an unknown value for the AE field MUST be silently ignored. This TLV is self-terminating, and allows sub-TLVs. 4.6.9. Update 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Length | AE | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Plen | Omitted | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seqno | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix... +-+-+-+-+-+-+-+-+-+-+-+- An Update TLV advertises or retracts a route. As an optimisation, it can optionally have the side effect of establishing a new implied router-id and a new default prefix, as described in Section 4.5. Fields : Type Set to 8 to indicate an Update TLV. Length The length of the body in octets, exclusive of the Type and Length fields. AE The encoding of the Prefix field. Flags The individual bits of this field specify special handling of this TLV (see below). Plen The length in bits of the advertised prefix. If AE is 3 (link-local IPv6), Omitted MUST be 0. Omitted The number of octets that have been omitted at the beginning of the advertised prefix and that should be taken Chroboczek & Schinazi Expires February 26, 2021 [Page 43] Internet-Draft The Babel Routing Protocol August 2020 from a preceding Update TLV in the same address family with the Prefix flag set. Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new update for this prefix. This MUST NOT be 0. The receiving node will use this value to compute a hold time for the route table entry. The value FFFF hexadecimal (infinity) expresses that this announcement will not be repeated unless a request is received (Section 3.8.2.3). Seqno The originator's sequence number for this update. Metric The sender's metric for this route. The value FFFF hexadecimal (infinity) means that this is a route retraction. Prefix The prefix being advertised. This field's size is (Plen/8 - Omitted) rounded upwards. The Flags field is interpreted as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P|R|X|X|X|X|X|X| +-+-+-+-+-+-+-+-+ o P (Prefix) flag (80 hexadecimal): if set, then this Update establishes a new default prefix for subsequent Update TLVs with a matching address encoding within the same packet, even if this TLV is otherwise ignored due to an unknown mandatory sub-TLV; o R (Router-Id) flag (40 hexadecimal): if set, then this TLV establishes a new default router-id for this TLV and subsequent Update TLVs in the same packet, even if this TLV is otherwise ignored due to an unknown mandatory sub-TLV. This router-id is computed from the first address of the advertised prefix as follows: * if the length of the address is 8 octets or more, then the new router-id is taken from the 8 last octets of the address; * if the length of the address is smaller than 8 octets, then the new router-id consists of the required number of zero octets followed by the address, i.e., the address is stored on the right of the router-id. For example, for an IPv4 address, the router-id consists of 4 octets of zeroes followed by the IPv4 address. Chroboczek & Schinazi Expires February 26, 2021 [Page 44] Internet-Draft The Babel Routing Protocol August 2020 o X: all other bits MUST be sent as 0 and silently ignored on reception. The prefix being advertised by an Update TLV is computed as follows: o the first Omitted octets of the prefix are taken from the previous Update TLV with the Prefix flag set and the same address encoding, even if it was ignored due to an unknown mandatory sub-TLV; if Omitted is not zero and there is no such TLV, then this Update MUST be ignored; o the next (Plen/8 - Omitted) rounded upwards octets are taken from the Prefix field; o if Plen is not a multiple of 8, then any bits beyond Plen (i.e., the low-order (8 - Plen MOD 8) bits of the last octet) are cleared; o the remaining octets are set to 0. If the Metric field is finite, the router-id of the originating node for this announcement is taken from the prefix advertised by this Update if the Router-Id flag is set, computed as described above. Otherwise, it is taken either from the preceding Router-Id TLV, or the preceding Update TLV with the Router-Id flag set, whichever comes last, even if that TLV is otherwise ignored due to an unknown mandatory sub-TLV; if there is no suitable TLV, then this update is ignored. The next-hop address for this update is taken from the last preceding Next Hop TLV with a matching address family (IPv4 or IPv6) in the same packet even if it was otherwise ignored due to an unknown mandatory sub-TLV; if no such TLV exists, it is taken from the network-layer source address of this packet if it belongs to the same address family as the prefix being announced; otherwise, this Update MUST be ignored. If the metric field is FFFF hexadecimal, this TLV specifies a retraction. In that case, the router-id, next-hop and seqno are not used. AE MAY then be 0, in which case this Update retracts all of the routes previously advertised by the sending interface. If the metric is finite, AE MUST NOT be 0; Update TLVs with finite metric and AE equal to 0 MUST be ignored. If the metric is infinite and AE is 0, Plen and Omitted MUST both be 0; Update TLVs that do not satisfy this requirement MUST be ignored. Update TLVs with an unknown value in the AE field MUST be silently ignored. Chroboczek & Schinazi Expires February 26, 2021 [Page 45] Internet-Draft The Babel Routing Protocol August 2020 This TLV is self-terminating, and allows sub-TLVs. 4.6.10. Route Request 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length | AE | Plen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix... +-+-+-+-+-+-+-+-+-+-+-+- A Route Request TLV prompts the receiver to send an update for a given prefix, or a full route table dump. Fields : Type Set to 9 to indicate a Route Request TLV. Length The length of the body in octets, exclusive of the Type and Length fields. AE The encoding of the Prefix field. The value 0 specifies that this is a request for a full route table dump (a wildcard request). Plen The length in bits of the requested prefix. Prefix The prefix being requested. This field's size is Plen/8 rounded upwards. A Request TLV prompts the receiver to send an update message (possibly a retraction) for the prefix specified by the AE, Plen, and Prefix fields, or a full dump of its route table if AE is 0 (in which case Plen must be 0 and Prefix is of length 0). A Request TLV with AE set to 0 and Plen not set to 0 MUST be ignored. This TLV is self-terminating, and allows sub-TLVs. 4.6.11. Seqno Request Chroboczek & Schinazi Expires February 26, 2021 [Page 46] Internet-Draft The Babel Routing Protocol August 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 | Length | AE | Plen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seqno | Hop Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Router-Id + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix... +-+-+-+-+-+-+-+-+-+-+ A Seqno Request TLV prompts the receiver to send an Update for a given prefix with a given sequence number, or to forward the request further if it cannot be satisfied locally. Fields : Type Set to 10 to indicate a Seqno Request TLV. Length The length of the body in octets, exclusive of the Type and Length fields. AE The encoding of the Prefix field. This MUST NOT be 0. Plen The length in bits of the requested prefix. Seqno The sequence number that is being requested. Hop Count The maximum number of times that this TLV may be forwarded, plus 1. This MUST NOT be 0. Reserved Sent as 0 and MUST be ignored on reception. Router-Id The Router-Id that is being requested. This MUST NOT consist of all zeroes or all ones. Prefix The prefix being requested. This field's size is Plen/8 rounded upwards. A Seqno Request TLV prompts the receiving node to send a finite- metric Update for the prefix specified by the AE, Plen, and Prefix fields, with either a router-id different from what is specified by the Router-Id field, or a Seqno no less (modulo 2^16) than what is specified by the Seqno field. If this request cannot be satisfied Chroboczek & Schinazi Expires February 26, 2021 [Page 47] Internet-Draft The Babel Routing Protocol August 2020 locally, then it is forwarded according to the rules set out in Section 3.8.1.2. While a Seqno Request MAY be sent to a multicast address, it MUST NOT be forwarded to a multicast address and MUST NOT be forwarded to more than one neighbour. A request MUST NOT be forwarded if its Hop Count field is 1. This TLV is self-terminating, and allows sub-TLVs. 4.7. Details of specific sub-TLVs 4.7.1. Pad1 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0 | +-+-+-+-+-+-+-+-+ Fields : Type Set to 0 to indicate a Pad1 sub-TLV. This sub-TLV is silently ignored on reception. It is allowed within any TLV that allows sub-TLVs. 4.7.2. PadN 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | MBZ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to 1 to indicate a PadN sub-TLV. Length The length of the body in octets, exclusive of the Type and Length fields. MBZ Must be zero, set to 0 on transmission. This sub-TLV is silently ignored on reception. It is allowed within any TLV that allows sub-TLVs. Chroboczek & Schinazi Expires February 26, 2021 [Page 48] Internet-Draft The Babel Routing Protocol August 2020 5. IANA Considerations IANA has registered the UDP port number 6696, called "babel", for use by the Babel protocol. IANA has registered the IPv6 multicast group ff02::1:6 and the IPv4 multicast group 224.0.0.111 for use by the Babel protocol. IANA has created a registry called "Babel TLV Types". The allocation policy for this registry is Specification Required [RFC8126] for Types 0-223, and Experimental Use for Types 224-254. The values in this registry are as follows: +---------+-----------------------------------------+---------------+ | Type | Name | Reference | +---------+-----------------------------------------+---------------+ | 0 | Pad1 | this document | | | | | | 1 | PadN | this document | | | | | | 2 | Acknowledgment Request | this document | | | | | | 3 | Acknowledgment | this document | | | | | | 4 | Hello | this document | | | | | | 5 | IHU | this document | | | | | | 6 | Router-Id | this document | | | | | | 7 | Next Hop | this document | | | | | | 8 | Update | this document | | | | | | 9 | Route Request | this document | | | | | | 10 | Seqno Request | this document | | | | | | 11 | TS/PC | [RFC7298] | | | | | | 12 | HMAC | [RFC7298] | | | | | | 13 | Source-specific Update | [BABEL-SS] | | | | | | 14 | Source-specific Request | [BABEL-SS] | | | | | | 15 | Source-specific Seqno Request | [BABEL-SS] | | | | | Chroboczek & Schinazi Expires February 26, 2021 [Page 49] Internet-Draft The Babel Routing Protocol August 2020 | 16 | MAC | [BABEL-MAC] | | | | | | 17 | PC | [BABEL-MAC] | | | | | | 18 | Challenge Request | [BABEL-MAC] | | | | | | 19 | Challenge Reply | [BABEL-MAC] | | | | | | 20-223 | Unassigned | | | | | | | 224-254 | Reserved for Experimental Use | this document | | | | | | 255 | Reserved for expansion of the type | this document | | | space | | +---------+-----------------------------------------+---------------+ IANA has created a registry called "Babel sub-TLV Types". The allocation policy for this registry is Specification Required for Types 0-111 and 128-239, and Experimental Use for Types 112-126 and 240-254. The values in this registry are as follows: +---------+-------------------------------------+-------------------+ | Type | Name | Reference | +---------+-------------------------------------+-------------------+ | 0 | Pad1 | this document | | | | | | 1 | PadN | this document | | | | | | 2 | Diversity | [BABEL-DIVERSITY] | | | | | | 3 | Timestamp | [BABEL-RTT] | | | | | | 4-111 | Unassigned | | | | | | | 112-126 | Reserved for Experimental Use | this document | | | | | | 127 | Reserved for expansion of the type | this document | | | space | | | | | | | 128 | Source Prefix | [BABEL-SS] | | | | | | 129-239 | Unassigned | | | | | | | 240-254 | Reserved for Experimental Use | this document | | | | | | 255 | Reserved for expansion of the type | this document | | | space | | +---------+-------------------------------------+-------------------+ Chroboczek & Schinazi Expires February 26, 2021 [Page 50] Internet-Draft The Babel Routing Protocol August 2020 IANA is instructed to create a registry called "Babel Address Encodings". The allocation policy for this registry is Specification Required for Address Encodings (AEs) 0-223, and Experimental Use for AEs 224-254. The values in this registry are as follows: +---------+----------------------------------------+---------------+ | AE | Name | Reference | +---------+----------------------------------------+---------------+ | 0 | Wildcard address | this document | | | | | | 1 | IPv4 address | this document | | | | | | 2 | IPv6 address | this document | | | | | | 3 | Link-local IPv6 address | this document | | | | | | 4-223 | Unassigned | | | | | | | 224-254 | Reserved for Experimental Use | this document | | | | | | 255 | Reserved for expansion of the AE space | this document | +---------+----------------------------------------+---------------+ IANA has created a registry called "Babel Flags Values". The allocation policy for this registry is Specification Required. IANA is instructed to rename this registry to "Babel Update Flags Values". The values in this registry are as follows: +-----+-------------------+---------------+ | Bit | Name | Reference | +-----+-------------------+---------------+ | 0 | Default prefix | this document | | | | | | 1 | Default Router-ID | this document | | | | | | 2-7 | Unassigned | | +-----+-------------------+---------------+ IANA is instructed to create a new registry called "Babel Hello Flags Values". The allocation policy for this registry is Specification Required. The initial values in this registry are as follows: Chroboczek & Schinazi Expires February 26, 2021 [Page 51] Internet-Draft The Babel Routing Protocol August 2020 +------+------------+---------------+ | Bit | Name | Reference | +------+------------+---------------+ | 0 | Unicast | this document | | | | | | 1-15 | Unassigned | | +------+------------+---------------+ IANA is instructed to replace all references to RFCs 6126 and 7557 in all of the registries mentioned above by references to this document. 6. Security Considerations As defined in this document, Babel is a completely insecure protocol. Without additional security mechanisms, Babel trusts any information it receives in plaintext UDP datagrams and acts on it. An attacker that is present on the local network can impact Babel operation in a variety of ways; for example they can: o spoof a Babel packet, and redirect traffic by announcing a route with a smaller metric, a larger sequence number, or a longer prefix; o spoof a malformed packet, which could cause an insufficiently robust implementation to crash or interfere with the rest of the network; o replay a previously captured Babel packet, which could cause traffic to be redirected, blackholed or otherwise interfere with the network. When carried over IPv6, Babel packets are ignored unless they are sent from a link-local IPv6 address; since routers don't forward link-local IPv6 packets, this mitigates the attacks outlined above by restricting them to on-link attackers. No such natural protection exists when Babel packets are carried over IPv4, which is one of the reasons why it is recommended to deploy Babel over IPv6 (Section 3.1). It is usually difficult to ensure that packets arriving at a Babel node are trusted, even in the case where the local link is believed to be secure. For that reason, it is RECOMMENDED that all Babel traffic be protected by an application-layer cryptographic protocol. There are currently two suitable mechanisms, which implement different tradeoffs between implementation simplicity and security: Chroboczek & Schinazi Expires February 26, 2021 [Page 52] Internet-Draft The Babel Routing Protocol August 2020 o Babel over DTLS [BABEL-DTLS] runs the majority of Babel traffic over DTLS, and leverages DTLS to authenticate nodes and provide confidentiality and integrity protection; o MAC authentication [BABEL-MAC] appends a message authentication code (MAC) to every Babel packet to prove that it originated at a node that knows a shared secret, and includes sufficient additional information to prove that the packet is fresh (not replayed). Both mechanisms enable nodes to ignore packets generated by attackers without the proper credentials. They also ensure integrity of messages and prevent message replay. While Babel-DTLS supports asymmetric keying and ensures confidentiality, Babel-MAC has a much more limited scope (see Sections 1.1, 1.2 and 7 of [BABEL-MAC]). Since Babel-MAC is simpler and more lightweight, it is recommended in preference to Babel-DTLS in deployments where its limitations are acceptable, i.e., when symmetric keying is sufficient and where the routing information is not considered confidential. Every implementation of Babel SHOULD implement BABEL-MAC. One should be aware that the information that a mobile Babel node announces to the whole routing domain is sufficient to determine the mobile node's physical location with reasonable precision, which might cause privacy concerns even if the control traffic is protected from unauthenticated attackers by a cryptographic mechanism such as Babel-DTLS. This issue may be mitigated somewhat by using randomly chosen router-ids and randomly chosen IP addresses, and changing them often enough. 7. Acknowledgments A number of people have contributed text and ideas to this specification. The authors are particularly indebted to Matthieu Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke Hoiland-Jorgensen, Benjamin Kaduk, Joao Sobrinho and Martin Vigoureux. Earlier versions of this document greatly benefited from the input of Joel Halpern. The address compression technique was inspired by [PACKETBB]. 8. References 8.1. Normative References Chroboczek & Schinazi Expires February 26, 2021 [Page 53] Internet-Draft The Babel Routing Protocol August 2020 [BABEL-MAC] Do, C., Kolodziejak, W., and J. Chroboczek, "MAC authentication for the Babel routing protocol", Internet Draft draft-ietf-babel-hmac-10, August 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 8.2. Informative References [BABEL-DIVERSITY] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", draft-chroboczek-babel-diversity-routing-01 (work in progress), February 2016. [BABEL-DTLS] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", Internet Draft draft-ietf-babel-dtls-10, June 2020. [BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", draft-ietf- babel-rtt-extension-00 (work in progress), April 2019. [BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", draft-ietf-babel-source-specific-05 (work in progress), April 2019. [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- Sequenced Distance-Vector Routing (DSDV) for Mobile Computers", ACM SIGCOMM'94 Conference on Communications Architectures, Protocols and Applications 234-244, 1994. Chroboczek & Schinazi Expires February 26, 2021 [Page 54] Internet-Draft The Babel Routing Protocol August 2020 [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing Computations", IEEE/ACM Transactions on Networking 1:1, February 1993. [EIGRP] Albrightson, B., Garcia Luna Aceves, J., and J. Boyle, "EIGRP -- a Fast Routing Protocol Based on Distance Vectors", Proc. Interop 94, 1994. [ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A high-throughput path metric for multi-hop wireless networks", Proc. MobiCom 2003, 2003. [IEEE802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012. [IEN137] Cohen, D., "On holy wars and a plea for peace", IEN 137, April 1980. [IS-IS] Standardization, I. O. F., "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/ IEC 10589:2002, 2002. [JITTER] Floyd, S. and V. Jacobson, "The synchronization of periodic routing messages", IEEE/ACM Transactions on Networking 2, 2, 122-136, April 1994. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [PACKETBB] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999. Chroboczek & Schinazi Expires February 26, 2021 [Page 55] Internet-Draft The Babel Routing Protocol August 2020 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, . [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011. [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014. [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", RFC 7557, DOI 10.17487/RFC7557, May 2015. [RIP] Malkin, G., "RIP Version 2", RFC 2453, November 1998. Appendix A. Cost and Metric Computation The strategy for computing link costs and route metrics is a local matter; Babel itself only requires that it comply with the conditions given in Section 3.4.3 and Section 3.5.2. Different nodes may use different strategies in a single network and may use different strategies on different interface types. This section describes a set of strategies that have been found to work well in actual networks. In summary, a node maintains per-neighbour statistics about the last 16 received Hello TLVs of each kind (Appendix A.1), it computes costs by using the 2-out-of-3 strategy (Appendix A.2.1) on wired links, and ETX (Appendix A.2.2) on wireless links. It uses an additive algebra for metric computation (Section 3.5.2). A.1. Maintaining Hello History For each neighbour, a node maintains two sets of Hello history, one for each kind of Hello, and an expected sequence number, one for Multicast and one for Unicast Hellos. Each Hello history is a vector of 16 bits, where a 1 value represents a received Hello, and a 0 value a missed Hello. For each kind of Hello, the expected sequence number, written ne, is the sequence number that is expected to be carried by the next received Hello from this neighbour. Whenever it receives a Hello packet of a given kind from a neighbour, a node compares the received sequence number nr for that kind of Hello with its expected sequence number ne. Depending on the outcome of this comparison, one of the following actions is taken: Chroboczek & Schinazi Expires February 26, 2021 [Page 56] Internet-Draft The Babel Routing Protocol August 2020 o if the two differ by more than 16 (modulo 2^16), then the sending node has probably rebooted and lost its sequence number; the whole associated neighbour table entry is flushed and a new one is created; o otherwise, if the received nr is smaller (modulo 2^16) than the expected sequence number ne, then the sending node has increased its Hello interval without us noticing; the receiving node removes the last (ne - nr) entries from this neighbour's Hello history (we "undo history"); o otherwise, if nr is larger (modulo 2^16) than ne, then the sending node has decreased its Hello interval, and some Hellos were lost; the receiving node adds (nr - ne) 0 bits to the Hello history (we "fast-forward"). The receiving node then appends a 1 bit to the Hello history and sets ne to (nr + 1). If the Interval field of the received Hello is not zero, it resets the neighbour's hello timer to 1.5 times the advertised Interval (the extra margin allows for delay due to jitter). Whenever either Hello timer associated to a neighbour expires, the local node adds a 0 bit to the corresponding Hello history, and increments the expected Hello number. If both Hello histories are empty (they contain 0 bits only), the neighbour entry is flushed; otherwise, the relevant hello timer is reset to the value advertised in the last Hello of that kind received from this neighbour (no extra margin is necessary in this case, since jitter was already taken into account when computing the timeout that has just expired). A.2. Cost Computation This section describes two algorithms suitable for computing costs (Section 3.4.3) based on Hello history. Appendix A.2.1 applies to wired links, and Appendix A.2.2 to wireless links. RECOMMENDED default values of the parameters that appear in these algorithms are given in Appendix B. A.2.1. k-out-of-j K-out-of-j link sensing is suitable for wired links that are either up, in which case they only occasionally drop a packet, or down, in which case they drop all packets. The k-out-of-j strategy is parameterised by two small integers k and j, such that 0 < k <= j, and the nominal link cost, a constant C >= 1. A node keeps a history of the last j hellos; if k or more of Chroboczek & Schinazi Expires February 26, 2021 [Page 57] Internet-Draft The Babel Routing Protocol August 2020 those have been correctly received, the link is assumed to be up, and the rxcost is set to C; otherwise, the link is assumed to be down, and the rxcost is set to infinity. Since Babel supports two kinds of Hellos, a Babel node performs k- out-of-j twice for each neighbour, once on the Unicast and once on the Multicast Hello history. If either of the instances of k-out- of-j indicates that the link is up, then the link is assumed to be up, and the rxcost is set to C; if both instances indicate that the link is down, then the link is assumed to be down, and the rxcost is set to infinity. In other words, the resulting rxcost is the minimum of the rxcosts yielded by the two instances of k-out-of-j link sensing. The cost of a link performing k-out-of-j link sensing is defined as follows: o cost = FFFF hexadecimal if rxcost = FFFF hexadecimal; o cost = txcost otherwise. A.2.2. ETX Unlike wired links which are bimodal (either up or down), wireless links exhibit continuous variation of the link quality. Naive application of hop-count routing in networks that use wireless links for transit tends to select long, lossy links in preference to shorter, lossless links, which can dramatically reduce throughput. For that reason, a routing protocol designed to support wireless links must perform some form of link-quality estimation. The Expected Transmission Cost algorithm, or ETX [ETX], is a simple link-quality estimation algorithm that is designed to work well with the IEEE 802.11 MAC [IEEE802.11]. By default, the IEEE 802.11 MAC performs Automatic Repeat Query (ARQ) and rate adaptation on unicast frames, but not on multicast frames, which are sent at a fixed rate with no ARQ; therefore, measuring the loss rate of multicast frames yields a useful estimate of a link's quality. A node performing ETX link quality estimation uses a neighbour's Multicast Hello history to compute an estimate, written beta, of the probability that a Hello TLV is successfully received. Beta can be computed as the fraction of 1 bits within a small number (say, 6) of the most recent entries in the Multicast Hello history, or it can be an exponential average, or some combination of both approaches. Let rxcost be 256 / beta. Chroboczek & Schinazi Expires February 26, 2021 [Page 58] Internet-Draft The Babel Routing Protocol August 2020 Let alpha be MIN(1, 256/txcost), an estimate of the probability of successfully sending a Hello TLV. The cost is then computed by cost = 256/(alpha * beta) or, equivalently, cost = (MAX(txcost, 256) * rxcost) / 256. Since the IEEE 802.11 MAC performs ARQ on unicast frames, unicast frames do not provide a useful measure of link quality, and therefore ETX ignores the Unicast Hello history. Thus, a node performing ETX link-quality estimation will not route through neighbouring nodes unless they send periodic Multicast Hellos (possibly in addition to Unicast Hellos). A.3. Route selection and hysteresis Route selection (Section 3.6) is the process by which a node selects a single route among the routes that it has available towards a given destination. With Babel, any route selection procedure that only ever chooses feasible routes with a finite metric will yield a set of loop-free routes; however, in the presence of continuously variable metrics such as ETX (Appendix A.2.2), a naive route selection procedure might lead to persistent oscillations. Such oscillations can be limited or avoided altogether by implementing hysteresis within the route selection algorithm, i.e., by making the route selection algorithm sensitive to a route's history. Any reasonable hysteresis algorithm should yield good results; the following algorithm is simple to implement and has been successfully deployed in a variety of environments. For every route R, in addition to the route's metric m(R), maintain a smoothed version of m(R) written ms(R) (we RECOMMEND computing ms(R) as an exponentially smoothed average (see Section 3.7 of [RFC793]) of m(R) with a time constant equal to the Hello interval multiplied by a small number such as 3). If no route to a given destination is selected, then select the route with the smallest metric, ignoring the smoothed metric. If a route R is selected, then switch to a route R' only when both m(R') < m(R) and ms(R') < ms(R). Intuitively, the smoothed metric is a long-term estimate of the quality of a route. The algorithm above works by only switching routes when both the instantaneous and the long-term estimate of the route's quality indicate that switching is profitable. Chroboczek & Schinazi Expires February 26, 2021 [Page 59] Internet-Draft The Babel Routing Protocol August 2020 Appendix B. Protocol parameters The choice of time constants is a trade-off between fast detection of mobility events and protocol overhead. Two instances of Babel running with different time constants will interoperate, although the resulting worst-case convergence time will be dictated by the slower of the two. The Hello interval is the most important time constant: an outage or a mobility event is detected within 1.5 to 3.5 Hello intervals. Due to Babel's use of a redundant route table, and due to its reliance on triggered updates and explicit requests, the Update interval has little influence on the time needed to reconverge after an outage: in practice, it only has a significant effect on the time needed to acquire new routes after a mobility event. While the protocol allows intervals as low as 10ms, such low values would cause significant amounts of protocol traffic for little practical benefit. The following values have been found to work well in a variety of environments, and are therefore RECOMMENDED default values: Multicast Hello Interval: 4 seconds. Unicast Hello Interval: infinite (no Unicast Hellos are sent). Link cost: estimated using ETX on wireless links; 2-out-of-3 with C=96 on wired links. IHU Interval: the advertised IHU interval is always 3 times the Multicast Hello interval. IHUs are actually sent with each Hello on lossy links (as determined from the Hello history), but only with every third Multicast Hello on lossless links. Update Interval: 4 times the Multicast Hello interval. IHU Hold Time: 3.5 times the advertised IHU interval. Route Expiry Time: 3.5 times the advertised update interval. Request timeout: initially 2 seconds, doubled every time a request is resent, up to a maximum of three times. Urgent timeout: 0.2 seconds. Source GC time: 3 minutes. Chroboczek & Schinazi Expires February 26, 2021 [Page 60] Internet-Draft The Babel Routing Protocol August 2020 Appendix C. Route filtering Route filtering is a procedure where an instance of a routing protocol either discards some of the routes announced by its neighbours, or learns them with a metric that is higher than what would be expected. Like all distance-vector protocols, Babel has the ability to apply arbitrary filtering to the routes it learns, and implementations of Babel that apply different sets of filtering rules will interoperate without causing routing loops. The protocol's ability to perform route filtering is a consequence of the latitude given in Section 3.5.2: Babel can use any metric that is strictly monotonic, including one that assigns an infinite metric to a selected subset of routes. (See also Section 3.8.1, where requests for nonexistent routes are treated in the same way as requests for routes with infinite metric.) It is not in general correct to learn a route with a metric smaller than the one it was announced with, or to replace a route's destination prefix with a more specific (longer) one. Doing either of these may cause persistent routing loops. Route filtering is a useful tool, since it allows fine-grained tuning of the routing decisions made by the routing protocol. Accordingly, some implementations of Babel implement a rich configuration language that allows applying filtering to sets of routes defined, for example, by incoming interface and destination prefix. In order to limit the consequences of misconfiguration, Babel implementations provide a reasonable set of default filtering rules even when they don't allow configuration of filtering by the user. At a minimum, they discard routes with a destination prefix in fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32 and 224.0.0.0/8. Appendix D. Considerations for protocol extensions Babel is an extensible protocol, and this document defines a number of mechanisms that can be used to extend the protocol in a backwards compatible manner: o increasing the version number in the packet header; o defining new TLVs; o defining new sub-TLVs (with or without the mandatory bit set); o defining new AEs; o using the packet trailer. Chroboczek & Schinazi Expires February 26, 2021 [Page 61] Internet-Draft The Babel Routing Protocol August 2020 This appendix is intended to guide designers of protocol extensions in choosing a particular encoding. The version number in the Babel header should only be increased if the new version is not backwards compatible with the original protocol. In many cases, an extension could be implemented either by defining a new TLV, or by adding a new sub-TLV to an existing TLV. For example, an extension whose purpose is to attach additional data to route updates can be implemented either by creating a new "enriched" Update TLV, by adding a non-mandatory sub-TLV to the Update TLV, or by adding a mandatory sub-TLV. The various encodings are treated differently by implementations that do not understand the extension. In the case of a new TLV or of a sub-TLV with the mandatory bit set, the whole TLV is ignored by implementations that do not implement the extension, while in the case of a non-mandatory sub-TLV, the TLV is parsed and acted upon, and only the unknown sub-TLV is silently ignored. Therefore, a non- mandatory sub-TLV should be used by extensions that extend the Update in a compatible manner (the extension data may be silently ignored), while a mandatory sub-TLV or a new TLV must be used by extensions that make incompatible extensions to the meaning of the TLV (the whole TLV must be thrown away if the extension data is not understood). Experience shows that the need for additional data tends to crop up in the most unexpected places. Hence, it is recommended that extensions that define new TLVs should make them self-terminating, and allow attaching sub-TLVs to them. Adding a new AE is essentially equivalent to adding a new TLV: Update TLVs with an unknown AE are ignored, just like unknown TLVs. However, adding a new AE is more involved than adding a new TLV, since it creates a new set of compression state. Additionally, since the Next Hop TLV creates state specific to a given address family, as opposed to a given AE, a new AE for a previously defined address family must not be used in the Next Hop TLV if backwards compatibility is required. A similar issue arises with Update TLVs with unknown AEs establishing a new router-id (due to the Router-Id flag being set). Therefore, defining new AEs must be done with care if compatibility with unextended implementations is required. The packet trailer is intended to carry cryptographic signatures that only cover the packet body; storing the cryptographic signatures in the packet trailer avoids clearing the signature before computing a hash of the packet body, and makes it possible to check a Chroboczek & Schinazi Expires February 26, 2021 [Page 62] Internet-Draft The Babel Routing Protocol August 2020 cryptographic signature before running the full, stateful TLV parser. Hence, only TLVs that don't need to be protected by cryptographic security protocols should be allowed in the packet trailer. Any such TLVs should be easy to parse, and in particular should not require stateful parsing. Appendix E. Stub Implementations Babel is a fairly economic protocol. Updates take between 12 and 40 octets per destination, depending on the address family and how successful compression is; in a double-stack flat network, an average of less than 24 octets per update is typical. The route table occupies about 35 octets per IPv6 entry. To put these values into perspective, a single full-size Ethernet frame can carry some 65 route updates, and a megabyte of memory can contain a 20000-entry route table and the associated source table. Babel is also a reasonably simple protocol. One complete implementation consists of less than 12 000 lines of C code, and it compiles to less than 120 kB of text on a 32-bit CISC architecture; about half of this figure is due to protocol extensions and user- interface code. Nonetheless, in some very constrained environments, such as PDAs, microwave ovens, or abacuses, it may be desirable to have subset implementations of the protocol. There are many different definitions of a stub router, but for the needs of this section a stub implementation of Babel is one that announces one or more directly attached prefixes into a Babel network but doesn't reannounce any routes that it has learnt from its neighbours, and always prefers the direct route to a directly attached prefix to a route learned over the Babel protocol, even when the prefixes are the same. It may either maintain a full routing table, or simply select a default gateway through any one of its neighbours that announces a default route. Since a stub implementation never forwards packets except from or to a directly attached link, it cannot possibly participate in a routing loop, and hence it need not evaluate the feasibility condition or maintain a source table. No matter how primitive, a stub implementation must parse sub-TLVs attached to any TLVs that it understands and check the mandatory bit. It must answer acknowledgment requests and must participate in the Hello/IHU protocol. It must also be able to reply to seqno requests for routes that it announces and, and it should be able to reply to route requests. Chroboczek & Schinazi Expires February 26, 2021 [Page 63] Internet-Draft The Babel Routing Protocol August 2020 Experience shows that an IPv6-only stub implementation of Babel can be written in less than 1000 lines of C code and compile to 13 kB of text on 32-bit CISC architecture. Appendix F. Compatibility with previous versions The protocol defined in this document is a successor to the protocol defined in [RFC6126] and [RFC7557]. While the two protocols are not entirely compatible, the new protocol has been designed so that it can be deployed in existing RFC 6126 networks without requiring a flag day. There are three optional features that make this protocol incompatible with its predecessor. First of all, RFC 6126 did not define Unicast hellos (Section 3.4.1), and an implementation of RFC 6126 will mis-interpret a Unicast Hello for a Multicast one; since the sequence number space of Unicast Hellos is distinct from the sequence space of Multicast Hellos, sending a Unicast Hello to an implementation of RFC 6126 will confuse its link quality estimator. Second, RFC 6126 did not define unscheduled Hellos, and an implementation of RFC 6126 will mis-parse Hellos with an interval equal to 0. Finally, RFC 7557 did not define mandatory sub-TLVs (Section 4.4), and thus, an implementation of RFCs 6126 and 7557 will not correctly ignore a TLV that carries an unknown mandatory sub-TLV; depending on the sub-TLV, this might cause routing pathologies. An implementation of this specification that never sends Unicast or unscheduled Hellos and doesn't implement any extensions that use mandatory sub-TLVs is safe to deploy in a network in which some nodes implement the protocol described in RFCs 6126 and 7557. Two changes need to be made to an implementation of RFCs 6126 and 7557 so that it can safely interoperate in all cases with implementations of this protocol. First, it needs to be modified to either ignore or process Unicast and unscheduled Hellos. Second, it needs to be modified to parse sub-TLVs of all the TLVs that it understands and that allow sub-TLVs, and to ignore the TLV if an unknown mandatory sub-TLV is found. It is not necessary to parse unknown TLVs, as these are ignored in any case. There are other changes, but these are not of a nature to prevent interoperability: o the conditions on route acquisition (Section 3.5.3) have been relaxed; o route selection should no longer use the route's sequence number (Section 3.6); Chroboczek & Schinazi Expires February 26, 2021 [Page 64] Internet-Draft The Babel Routing Protocol August 2020 o the format of the packet trailer has been defined (Section 4.2); o router-ids with a value of all-zeros or all-ones have been forbidden (Section 4.1.3); o the compression state is now specific to an address family rather than an address encoding (Section 4.5); o packet pacing is now recommended (Section 3.1). Appendix G. Changes from previous versions [RFC Editor: Please delete this section before publication.] G.1. Changes since RFC 6126 o Changed UDP port number to 6696. o Consistently use router-id rather than id. o Clarified that the source garbage collection timer is reset after sending an update even if the entry was not modified. o In section "Seqno Requests", fixed an erroneous "route request". o In the description of the Seqno Request TLV, added the description of the Router-Id field. o Made router-ids all-0 and all-1 forbidden. G.2. Changes since draft-ietf-babel-rfc6126bis-00 o Added security considerations. G.3. Changes since draft-ietf-babel-rfc6126bis-01 o Integrated the format of sub-TLVs. o Mentioned for each TLV whether it supports sub-TLVs. o Added Appendix D. o Added a mandatory bit in sub-TLVs. o Changed compression state to be per-AF rather than per-AE. o Added implementation hint for the routing table. Chroboczek & Schinazi Expires February 26, 2021 [Page 65] Internet-Draft The Babel Routing Protocol August 2020 o Clarified how router-ids are computed when bit 0x40 is set in Updates. o Relaxed the conditions for sending requests, and tightened the conditions for forwarding requests. o Clarified that neighbours should be acquired at some point, but it doesn't matter when. G.4. Changes since draft-ietf-babel-rfc6126bis-02 o Added Unicast Hellos. o Added unscheduled (interval-less) Hellos. o Changed Appendix A to consider Unicast and unscheduled Hellos. o Changed Appendix B to agree with the reference implementation. o Added optional algorithm to avoid the hold time. o Changed the table of pending seqno requests to be indexed by router-id in addition to prefixes. o Relaxed the route acquisition algorithm. o Replaced minimal implementations by stub implementations. o Added acknowledgments section. G.5. Changes since draft-ietf-babel-rfc6126bis-03 o Clarified that all the data structures are conceptual. o Made sending and receiving Multicast Hellos a SHOULD, avoids expressing any opinion about Unicast Hellos. o Removed opinion about Multicast vs. Unicast Hellos (Appendix A.4). o Made hold-time into a SHOULD rather than MUST. o Clarified that Seqno Requests are for a finite-metric Update. o Clarified that sub-TLVs Pad1 and PadN are allowed within any TLV that allows sub-TLVs. o Updated IANA Considerations. Chroboczek & Schinazi Expires February 26, 2021 [Page 66] Internet-Draft The Babel Routing Protocol August 2020 o Updated Security Considerations. o Renamed routing table back to route table. o Made buffering outgoing updates a SHOULD. o Weakened advice to use modified EUI-64 in router-ids. o Added information about sending requests to Appendix B. o A number of minor wording changes and clarifications. G.6. Changes since draft-ietf-babel-rfc6126bis-03 Minor editorial changes. G.7. Changes since draft-ietf-babel-rfc6126bis-04 o Renamed isotonicity to left-distributivity. o Minor clarifications to unicast hellos. o Updated requirements boilerplate to RFC 8174. o Minor editorial changes. G.8. Changes since draft-ietf-babel-rfc6126bis-05 o Added information about the packet trailer, now that it is used by draft-ietf-babel-hmac. G.9. Changes since draft-ietf-babel-rfc6126bis-06 o Added references to security documents. G.10. Changes since draft-ietf-babel-rfc6126bis-07 o Added list of obsoleted drafts to the abstract. o Updated references. G.11. Changes since draft-ietf-babel-rfc6126bis-08 o Added recommendation that route selection should not take seqnos into account. Chroboczek & Schinazi Expires February 26, 2021 [Page 67] Internet-Draft The Babel Routing Protocol August 2020 G.12. Changes since draft-ietf-babel-rfc6126bis-09 o Editorial changes only. G.13. Changes since draft-ietf-babel-rfc6126bis-10 o Editorial changes only. G.14. Changes since draft-ietf-babel-rfc6126bis-11 o Added recommendation that control traffic should be carried over IPv6 only. G.15. Changes since draft-ietf-babel-rfc6126bis-12 o Removed appendix about software availability. o Expanded appendix about recommended values and added more references to it in the body of the document. o Added appendix about route filtering. o Clarified definition of mandatory bit. o Added recommendations for packet pacing. o Made time limiting of full updates a SHOULD. o Normative language in a few more places. o Removed normative language from stub implementations. o Added requirement to clear the undefined bits in an Update. o Added error checking requirements. o Reworked security considerations. o Added "in octets" and "in bits" in random places. o Inserted full IANA registries. o Editorial changes. Chroboczek & Schinazi Expires February 26, 2021 [Page 68] Internet-Draft The Babel Routing Protocol August 2020 G.16. Changes since draft-ietf-babel-rfc6126bis-13 o Added a section about compatibility with 6126. o Added AE registry to IANA considerations. o Replaced Babel-HMAC with Babel-MAC, consistent with the change in draft-ietf-babel-hmac. o Removed section about external sources of willingness; filtering is a better approach. o Added recommendation to use a cost of 96 on wired links. o Editorial changes. G.17. Changes since draft-ietf-babel-rfc6126bis-14 o Added unscheduled Hellos to compatibility considerations. o Created new appendix about route selection. o Reworked security considerations. o Added some comments about packet pacing and low update intervals. G.18. Changes since draft-ietf-babel-rfc6126bis-15 o Implementing Babel-MAC is now recommended. G.19. Changes since draft-ietf-babel-rfc6126bis-16 o Make the values in Appendix B normatively recommended defaults. G.20. Changes since draft-ietf-babel-rfc6126bis-17 o Hysteresis in route selection is now RECOMMENDED. o Additive metric algebra is now RECOMMENDED default. o 2-out-of-3 cost computation is now RECOMMENDED on LANs. o Reference to RFC 793 Section 3.7 added as exponential smoothing example. Chroboczek & Schinazi Expires February 26, 2021 [Page 69] Internet-Draft The Babel Routing Protocol August 2020 G.21. Changes since draft-ietf-babel-rfc6126bis-18 o Reserved Address Encodings 224-254 for Experimental Use, and 255 for future expansion. G.22. Changes since draft-ietf-babel-rfc6126bis-19 o Mention that multi-octet fields are in big-endian. o Minor typos and clarifications. Authors' Addresses Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043 USA Email: dschinazi.ietf@gmail.com Chroboczek & Schinazi Expires February 26, 2021 [Page 70] ./draft-ietf-dnsop-rfc2845bis-09.txt0000644000764400076440000020201113702077735016304 0ustar iustyiusty Internet Engineering Task Force F. Dupont Internet-Draft S. Morris Obsoletes: 2845, 4635 (if approved) ISC Intended status: Standards Track P. Vixie Expires: January 11, 2021 Farsight D. Eastlake 3rd Futurewei O. Gudmundsson Cloudflare B. Wellington Akamai July 10, 2020 Secret Key Transaction Authentication for DNS (TSIG) draft-ietf-dnsop-rfc2845bis-09 Abstract This document describes a protocol for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client, or to authenticate responses as coming from an approved name server. No recommendation is made here for distributing the shared secrets: it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism. This document obsoletes RFC2845 and RFC4635. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 11, 2021. Dupont, et al. Expires January 11, 2021 [Page 1] Internet-Draft DNS TSIG July 2020 Copyright Notice Copyright (c) 2020 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 (https://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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 1.3. Document History . . . . . . . . . . . . . . . . . . . . 4 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 5 4. TSIG RR Format . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. TSIG RR Type . . . . . . . . . . . . . . . . . . . . . . 5 4.2. TSIG Record Format . . . . . . . . . . . . . . . . . . . 6 4.3. MAC Computation . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Request MAC . . . . . . . . . . . . . . . . . . . . . 8 4.3.2. DNS Message . . . . . . . . . . . . . . . . . . . . . 9 4.3.3. TSIG Variables . . . . . . . . . . . . . . . . . . . 9 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Generation of TSIG on Requests . . . . . . . . . . . . . 10 5.2. Server Processing of Request . . . . . . . . . . . . . . 10 5.2.1. Key Check and Error Handling . . . . . . . . . . . . 11 5.2.2. MAC Check and Error Handling . . . . . . . . . . . . 11 5.2.3. Time Check and Error Handling . . . . . . . . . . . . 12 Dupont, et al. Expires January 11, 2021 [Page 2] Internet-Draft DNS TSIG July 2020 5.2.4. Truncation Check and Error Handling . . . . . . . . . 13 5.3. Generation of TSIG on Answers . . . . . . . . . . . . . . 13 5.3.1. TSIG on TCP Connections . . . . . . . . . . . . . . . 13 5.3.2. Generation of TSIG on Error Returns . . . . . . . . . 14 5.4. Client Processing of Answer . . . . . . . . . . . . . . . 15 5.4.1. Key Error Handling . . . . . . . . . . . . . . . . . 15 5.4.2. MAC Error Handling . . . . . . . . . . . . . . . . . 15 5.4.3. Time Error Handling . . . . . . . . . . . . . . . . . 15 5.4.4. Truncation Error Handling . . . . . . . . . . . . . . 16 5.5. Special Considerations for Forwarding Servers . . . . . . 16 6. Algorithms and Identifiers . . . . . . . . . . . . . . . . . 16 7. TSIG Truncation Policy . . . . . . . . . . . . . . . . . . . 17 8. Shared Secrets . . . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10.1. Issue Fixed in this Document . . . . . . . . . . . . . . 20 10.2. Why not DNSSEC? . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Appendix B. Change History (to be removed before publication) . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction 1.1. Background The Domain Name System (DNS, [RFC1034], [RFC1035]) is a replicated hierarchical distributed database system that provides information fundamental to Internet operations, such as name to address translation and mail handling information. This document specifies use of a message authentication code (MAC), generated using certain keyed hash functions, to provide an efficient means of point-to-point authentication and integrity checking for DNS transactions. Such transactions include DNS update requests and responses for which this can provide a lightweight alternative to the secure DNS dynamic update protocol described by [RFC3007]. A further use of this mechanism is to protect zone transfers. In this case the data covered would be the whole zone transfer including any glue records sent. The protocol described by DNSSEC ([RFC4033], [RFC4034], [RFC4035]) does not protect glue records and unsigned records. The authentication mechanism proposed here provides a simple and efficient authentication between clients and servers, by using shared Dupont, et al. Expires January 11, 2021 [Page 3] Internet-Draft DNS TSIG July 2020 secret keys to establish a trust relationship between two entities. Such keys must be protected in a manner similar to private keys, lest a third party masquerade as one of the intended parties (by forging the MAC). The proposal is unsuitable for general server to server authentication and for servers which speak with many other servers, since key management would become unwieldy with the number of shared keys going up quadratically. But it is suitable for many resolvers on hosts that only talk to a few recursive servers. 1.2. Protocol Overview Secret Key Transaction Authentication makes use of signatures on messages sent between the parties involved (e.g. resolver and server). These are known as "transaction signatures", or TSIG. For historical reasons, in this document they are referred to as message authentication codes (MAC). Use of TSIG presumes prior agreement between the two parties involved (e.g., resolver and server) as to any algorithm and key to be used. The way that this agreement is reached is outside the scope of the document. A DNS message exchange involves the sending of a query and the receipt of one of more DNS messages in response. For the query, the MAC is calculated based on the hash of the contents and the agreed TSIG key. The MAC for the response is similar, but also includes the MAC of the query as part of the calculation. Where a response comprises multiple packets, the calculation of the MAC associated with the second and subsequent packets includes in its inputs the MAC for the preceding packet. In this way it is possible to detect any interruption in the packet sequence, although not its premature termination. The MAC is contained in a TSIG resource record included in the Additional Section of the DNS message. 1.3. Document History TSIG was originally specified by [RFC2845]. In 2017, two nameserver implementations strictly following that document (and the related [RFC4635]) were discovered to have security problems related to this feature ([CVE-2017-3142], [CVE-2017-3143], [CVE-2017-11104]). The implementations were fixed but, to avoid similar problems in the future, the two documents were updated and merged, producing this revised specification for TSIG. While TSIG implemented according to this RFC provides for enhanced security, there are no changes in interoperability. TSIG is on the Dupont, et al. Expires January 11, 2021 [Page 4] Internet-Draft DNS TSIG July 2020 wire still the same mechanism described in [RFC2845]; only the checking semantics have been changed. See Section 10.1 for further details. 2. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Assigned Numbers This document defines the following RR type and associated value: TSIG (250) In addition, the document also defines the following DNS RCODEs and associated names: 16 (BADSIG) 17 (BADKEY) 18 (BADTIME) 22 (BADTRUNC) (See [RFC6895] Section 2.3 concerning the assignment of the value 16 to BADSIG.) These RCODES may appear within the "Error" field of a TSIG RR. 4. TSIG RR Format 4.1. TSIG RR Type To provide secret key authentication, we use an RR type whose mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and MUST NOT be cached. TSIG RRs are used for authentication between DNS entities that have established a shared secret key. TSIG RRs are dynamically computed to cover a particular DNS transaction and are not DNS RRs in the usual sense. As the TSIG RRs are related to one DNS request/response, there is no value in storing or retransmitting them, thus the TSIG RR is discarded once it has been used to authenticate a DNS message. Dupont, et al. Expires January 11, 2021 [Page 5] Internet-Draft DNS TSIG July 2020 4.2. TSIG Record Format The fields of the TSIG RR are described below. As is usual, all multi-octet integers in the record are sent in network byte order (see [RFC1035] 2.3.2). NAME The name of the key used, in domain name syntax. The name should reflect the names of the hosts and uniquely identify the key among a set of keys these two hosts may share at any given time. For example, if hosts A.site.example and B.example.net share a key, possibilities for the key name include .A.site.example, .B.example.net, and .A.site.example.B.example.net. It should be possible for more than one key to be in simultaneous use among a set of interacting hosts. This allows for periodic key rotation as per best operational practices, as well as algorithm agility as indicated by [BCP201]. The name may be used as a local index to the key involved but it is recommended that it be globally unique. Where a key is just shared between two hosts, its name actually need only be meaningful to them but it is recommended that the key name be mnemonic and incorporates the names of participating agents or resources as suggested above. TYPE This MUST be TSIG (250: Transaction SIGnature) CLASS This MUST be ANY TTL This MUST be 0 RdLen (variable) RDATA The RDATA for a TSIG RR consists of a number of fields, described below: Dupont, et al. Expires January 11, 2021 [Page 6] Internet-Draft DNS TSIG July 2020 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Algorithm Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Time Signed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Fudge | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Size | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original ID | Error | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Len | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Other Data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The contents of the RDATA fields are: * Algorithm Name - a octet sequence identifying the TSIG algorithm name in the domain name syntax. (Allowed names are listed in Table 2.) The name is stored in the DNS name wire format as described in [RFC1034]. As per [RFC3597], this name MUST NOT be compressed. * Time Signed - an unsigned 48-bit integer containing the time the message was signed as seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds. * Fudge - an unsigned 16-bit integer specifying the allowed time difference in seconds permitted in the Time Signed field. * MAC Size - an unsigned 16-bit integer giving the length of MAC field in octets. Truncation is indicated by a MAC size less than the size of the keyed hash produced by the algorithm specified by the Algorithm Name. * MAC - a sequence of octets whose contents are defined by the TSIG algorithm used, possibly truncated as specified by MAC Size. The length of this field is given by the Mac Size. Calculation of the MAC is detailed in Section 4.3. * Original ID - An unsigned 16-bit integer holding the message ID of the original request message. For a TSIG RR on a Dupont, et al. Expires January 11, 2021 [Page 7] Internet-Draft DNS TSIG July 2020 request, it is set equal to the DNS message ID. In a TSIG attached to a response - or in cases such as the forwarding of a dynamic update request - the field contains the ID of the original DNS request. * Error - in responses, an unsigned 16-bit integer containing the extended RCODE covering TSIG processing. In requests, this MUST be zero. * Other Len - an unsigned 16-bit integer specifying the length of the "Other Data" field in octets. * Other Data - additional data relevant to the TSIG record. In responses, this will be empty (i.e. "Other Len" will be zero) unless the content of the Error field is BADTIME, in which case it will be a 48-bit unsigned integer containing the server's current time as the number of seconds since 00:00 on 1970-01-01 UTC, ignoring leap seconds (see Section 5.2.3). This document assigns no meaning to its contents in requests. 4.3. MAC Computation When generating or verifying the contents of a TSIG record, the data listed in the rest of this section are passed, in the order listed below, as input to MAC computation. The data are passed in network byte order or wire format, as appropriate, and are fed into the hashing function as a continuous octet sequence with no inter-field separator or padding. 4.3.1. Request MAC Only included in the computation of a MAC for a response message (or the first message in a multi-message response), the validated request MAC MUST be included in the MAC computation. If the request MAC failed to validate, an unsigned error message MUST be returned instead. (Section 5.3.2). The request's MAC, comprising the following fields, is digested in wire format: Field Type Description ---------- ----------------------- ---------------------- MAC Length Unsigned 16-bit integer in network byte order MAC Data octet sequence exactly as transmitted Special considerations apply to the TSIG calculation for the second and subsequent messages a response that consists of multiple DNS Dupont, et al. Expires January 11, 2021 [Page 8] Internet-Draft DNS TSIG July 2020 messages (e.g. a zone transfer). These are described in Section 5.3.1. 4.3.2. DNS Message The DNS message used in the MAC computation is a whole and complete DNS message in wire format. When creating a TSIG, it is the message before the TSIG RR has been added to the additional data section and before the DNS Message Header's ARCOUNT field has been incremented to contain the TSIG RR. When verifying an incoming message, it is the message after the TSIG RR has been removed and the ARCOUNT field decremented. If the message ID differs from the original message ID, the original message ID is substituted for the message ID. (This could happen, for example, when forwarding a dynamic update request.) 4.3.3. TSIG Variables Also included in the digest is certain information present in the TSIG RR. Adding this data provides further protection against an attempt to interfere with the message. Source Field Name Notes ---------- -------------- ----------------------------------------- TSIG RR NAME Key name, in canonical wire format TSIG RR CLASS (Always ANY in the current specification) TSIG RR TTL (Always 0 in the current specification) TSIG RDATA Algorithm Name in canonical wire format TSIG RDATA Time Signed in network byte order TSIG RDATA Fudge in network byte order TSIG RDATA Error in network byte order TSIG RDATA Other Len in network byte order TSIG RDATA Other Data exactly as transmitted Table 1 The RR RDLEN and RDATA MAC Length are not included in the input to MAC computation since they are not guaranteed to be knowable before the MAC is generated. The Original ID field is not included in this section, as it has already been substituted for the message ID in the DNS header and hashed. For each label type, there must be a defined "Canonical wire format" that specifies how to express a label in an unambiguous way. For Dupont, et al. Expires January 11, 2021 [Page 9] Internet-Draft DNS TSIG July 2020 label type 00, this is defined in [RFC4034] Section 6.2. The use of label types other than 00 is not defined for this specification. 4.3.3.1. Time Values Used in TSIG Calculations The data digested includes the two timer values in the TSIG header in order to defend against replay attacks. If this were not done, an attacker could replay old messages but update the "Time Signed" and "Fudge" fields to make the message look new. This data is named "TSIG Timers", and for the purpose of MAC calculation, they are hashed in their "on the wire" format, in the following order: first Time Signed, then Fudge. 5. Protocol Details 5.1. Generation of TSIG on Requests Once the outgoing record has been constructed, the client performs the keyed hash (HMAC) computation, appends a TSIG record with the calculated MAC to the Additional Data section (incrementing the ARCOUNT to reflect the additional RR), and transmits the request to the server. This TSIG record MUST be the only TSIG RR in the message and MUST be last record in the Additional Data section. The client MUST store the MAC and the key name from the request while awaiting an answer. The digest components for a request are: DNS Message (request) TSIG Variables (request) 5.2. Server Processing of Request If an incoming message contains a TSIG record, it MUST be the last record in the additional section. Multiple TSIG records are not allowed. If multiple TSIG records are detected or a TSIG record is present in any other position, the DNS message is dropped and a response with RCODE 1 (FORMERR) MUST be returned. Upon receipt of a message with exactly one correctly placed TSIG RR, a copy of the TSIG RR is stored, and the TSIG RR is removed from the DNS Message, and decremented out of the DNS message header's ARCOUNT. If the TSIG RR cannot be interpreted, the server MUST regard the message as corrupt and return a FORMERR to the server. Otherwise the server is REQUIRED to return a TSIG RR in the response. To validate the received TSIG RR, the server MUST perform the following checks in the following order: Dupont, et al. Expires January 11, 2021 [Page 10] Internet-Draft DNS TSIG July 2020 1. Check KEY 2. Check MAC 3. Check TIME values 4. Check Truncation policy 5.2.1. Key Check and Error Handling If a non-forwarding server does not recognize the key or algorithm used by the client (or recognizes the algorithm but does not implement it), the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned as specified in Section 5.3.2. The server SHOULD log the error. (Special considerations apply to forwarding servers, see Section 5.5.) 5.2.2. MAC Check and Error Handling Using the information in the TSIG, the server MUST verify the MAC by doing its own calculation and comparing the result with the MAC received. If the MAC fails to verify, the server MUST generate an error response as specified in Section 5.3.2 with RCODE 9 (NOTAUTH) and TSIG ERROR 16 (BADSIG). This response MUST be unsigned as specified in Section 5.3.2. The server SHOULD log the error. 5.2.2.1. MAC Truncation When space is at a premium and the strength of the full length of a MAC is not needed, it is reasonable to truncate the keyed hash and use the truncated value for authentication. HMAC SHA-1 truncated to 96 bits is an option available in several IETF protocols, including IPsec and TLS. However, while this option is kept for backwards compatibility, it may not provide a security level appropriate for all cases in the modern environment. In these cases, it is preferable to use a hashing algorithm such as SHA-256-128, SHA- 384-192 or SHA-512-256 [RFC4868]. Processing of a truncated MAC follows these rules: 1. If "MAC size" field is greater than keyed hash output length: This case MUST NOT be generated and, if received, MUST cause the DNS message to be dropped and RCODE 1 (FORMERR) to be returned. 2. If "MAC size" field equals keyed hash output length: The entire output keyed hash output is present and used. Dupont, et al. Expires January 11, 2021 [Page 11] Internet-Draft DNS TSIG July 2020 3. "MAC size" field is less than the larger of 10 (octets) and half the length of the hash function in use: With the exception of certain TSIG error messages described in Section 5.3.2, where it is permitted that the MAC size be zero, this case MUST NOT be generated and, if received, MUST cause the DNS message to be dropped and RCODE 1 (FORMERR) to be returned. 4. Otherwise: This is sent when the signer has truncated the keyed hash output to an allowable length, as described in [RFC2104], taking initial octets and discarding trailing octets. TSIG truncation can only be to an integral number of octets. On receipt of a DNS message with truncation thus indicated, the locally calculated MAC is similarly truncated and only the truncated values are compared for authentication. The request MAC used when calculating the TSIG MAC for a reply is the truncated request MAC. 5.2.3. Time Check and Error Handling If the server time is outside the time interval specified by the request (which is: Time Signed, plus/minus Fudge), the server MUST generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 (BADTIME). The server SHOULD also cache the most recent Time Signed value in a message generated by a key, and SHOULD return BADTIME if a message received later has an earlier Time Signed value. A response indicating a BADTIME error MUST be signed by the same key as the request. It MUST include the client's current time in the Time Signed field, the server's current time (an unsigned 48-bit integer) in the Other Data field, and 6 in the Other Len field. This is done so that the client can verify a message with a BADTIME error without the verification failing due to another BADTIME error. In addition, the Fudge field MUST be set to the fudge value received from the client. The data signed is specified in Section 5.3.2. The server SHOULD log the error. Caching the most recent Time Signed value and rejecting requests with an earlier one could lead to valid messages being rejected if transit through the network led to UDP packets arriving in a different order to the one in which they were sent. Implementations should be aware of this possibility and be prepared to deal with it, e.g. by retransmitting the rejected request with a new TSIG once outstanding requests have completed or the time given by their Time Signed plus fudge value has passed. If implementations do retry requests in these cases, a limit SHOULD be placed on the maximum number of retries. Dupont, et al. Expires January 11, 2021 [Page 12] Internet-Draft DNS TSIG July 2020 5.2.4. Truncation Check and Error Handling If a TSIG is received with truncation that is permitted under Section 5.2.2.1 above but the MAC is too short for the local policy in force, an RCODE 9 (NOTAUTH) and TSIG ERROR 22 (BADTRUNC) MUST be returned. The server SHOULD log the error. 5.3. Generation of TSIG on Answers When a server has generated a response to a signed request, it signs the response using the same algorithm and key. The server MUST NOT generate a signed response to a request if either the KEY is invalid (e.g. key name or algorithm name are unknown), or the MAC fails validation: see Section 5.3.2 for details of responding in these cases. It also MUST NOT not generate a signed response to an unsigned request, except in the case of a response to a client's unsigned TKEY request if the secret key is established on the server side after the server processed the client's request. Signing responses to unsigned TKEY requests MUST be explicitly specified in the description of an individual secret key establishment algorithm [RFC3645]. The digest components used to generate a TSIG on a response are: Request MAC DNS Message (response) TSIG Variables (response) (This calculation is different for the second and subsequent message in a multi-message answer, see below.) If addition of the TSIG record will cause the message to be truncated, the server MUST alter the response so that a TSIG can be included. This response consists of only the question and a TSIG record, and has the TC bit set and an RCODE of 0 (NOERROR). The client SHOULD at this point retry the request using TCP (as per [RFC1035] 4.2.2). 5.3.1. TSIG on TCP Connections A DNS TCP session such as a zone transfer can include multiple DNS messages. Using TSIG on such a connection can protect the connection from attack and provide data integrity. The TSIG MUST be included on all DNS messages in the response. For backward compatibility, a client which receives DNS messages and verifies TSIG MUST accept up to 99 intermediary messages without a TSIG and MUST verify that both the first and last message contain a TSIG. Dupont, et al. Expires January 11, 2021 [Page 13] Internet-Draft DNS TSIG July 2020 The first message is processed as a standard answer (see Section 5.3) but subsequent messages have the following digest components: Prior MAC (running) DNS Messages (any unsigned messages since the last TSIG) TSIG Timers (current message) The "Prior MAC" is the MAC from the TSIG attached to the last message containing a TSIG. "DNS Messages" comprises the concatenation (in message order) of all messages after the last message that included a TSIG and includes the current message. "TSIG timers" comprises the "Time Signed" and "Fudge" fields (in that order) pertaining to the message for which the TSIG is being created: this means that the successive TSIG records in the stream will have non-decreasing "Time Signed" fields. Note that only the timers are included in the second and subsequent messages, not all the TSIG variables. This allows the client to rapidly detect when the session has been altered; at which point it can close the connection and retry. If a client TSIG verification fails, the client MUST close the connection. If the client does not receive TSIG records frequently enough (as specified above) it SHOULD assume the connection has been hijacked and it SHOULD close the connection. The client SHOULD treat this the same way as they would any other interrupted transfer (although the exact behavior is not specified). 5.3.2. Generation of TSIG on Error Returns When a server detects an error relating to the key or MAC in the incoming request, the server SHOULD send back an unsigned error message (MAC size == 0 and empty MAC). It MUST NOT send back a signed error message. If an error is detected relating to the TSIG validity period or the MAC is too short for the local policy, the server SHOULD send back a signed error message. The digest components are: Request MAC (if the request MAC validated) DNS Message (response) TSIG Variables (response) The reason that the request MAC is not included in this MAC in some cases is to make it possible for the client to verify the error. If the error is not a TSIG error the response MUST be generated as specified in Section 5.3. Dupont, et al. Expires January 11, 2021 [Page 14] Internet-Draft DNS TSIG July 2020 5.4. Client Processing of Answer When a client receives a response from a server and expects to see a TSIG, it first checks if the TSIG RR is present in the response. If not, the response is treated as having a format error and is discarded. If the TSIG RR is present, the client performs the same checks as described in Section 5.2. If the TSIG RR is unsigned as specified in Section 5.3.2 or does not validate, the message MUST be discarded unless the RCODE is 9 (NOAUTH). In this case, the client SHOULD attempt to verify the response as if it were a TSIG error, as described in the following subsections. Regardless of the RCODE, a message containing a TSIG RR that is unsigned as specified in Section 5.3.2 or which fails verification SHOULD NOT be considered an acceptable response as it may have been spoofed or manipulated. Instead, the client SHOULD log an error and continue to wait for a signed response until the request times out. 5.4.1. Key Error Handling If an RCODE on a response is 9 (NOTAUTH), but the response TSIG validates and the TSIG key is recognized by the client but different from that used on the request, then this is a Key Error. The client MAY retry the request using the key specified by the server. However, this should never occur, as a server MUST NOT sign a response with a different key to that used to sign the request. 5.4.2. MAC Error Handling If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), this is a MAC error, and client MAY retry the request with a new request ID but it would be better to try a different shared key if one is available. Clients SHOULD keep track of how many MAC errors are associated with each key. Clients SHOULD log this event. 5.4.3. Time Error Handling If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 (BADTIME), or the current time does not fall in the range specified in the TSIG record, then this is a Time error. This is an indication that the client and server clocks are not synchronized. In this case the client SHOULD log the event. DNS resolvers MUST NOT adjust any clocks in the client based on BADTIME errors, but the server's time in the Other Data field SHOULD be logged. Dupont, et al. Expires January 11, 2021 [Page 15] Internet-Draft DNS TSIG July 2020 5.4.4. Truncation Error Handling If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 22 (BADTRUNC) then this is a Truncation error. The client MAY retry with a lesser truncation up to the full HMAC output (no truncation), using the truncation used in the response as a hint for what the server policy allowed (Section 7). Clients SHOULD log this event. 5.5. Special Considerations for Forwarding Servers A server acting as a forwarding server of a DNS message SHOULD check for the existence of a TSIG record. If the name on the TSIG is not of a secret that the server shares with the originator the server MUST forward the message unchanged including the TSIG. If the name of the TSIG is of a key this server shares with the originator, it MUST process the TSIG. If the TSIG passes all checks, the forwarding server MUST, if possible, include a TSIG of its own, to the destination or the next forwarder. If no transaction security is available to the destination and the message is a query then, if the corresponding response has the AD flag (see [RFC4035]) set, the forwarder MUST clear the AD flag before adding the TSIG to the response and returning the result to the system from which it received the query. 6. Algorithms and Identifiers The only message digest algorithm specified in the first version of these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321], [RFC2104]). Although a review of its security some years ago [RFC6151] concluded that "it may not be urgent to remove HMAC-MD5 from the existing protocols", with the availability of more secure alternatives the opportunity has been taken to make the implementation of this algorithm optional. [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4], [RFC3174]. SHA-1 collisions have been demonstrated [SHA1SHAMBLES] so the MD5 security considerations described in section 2 of [RFC6151] apply to SHA-1 in a similar manner. Although support for hmac-sha1 in TSIG is still mandatory for compatibility reasons, existing uses SHOULD be replaced with hmac-sha256 or other SHA-2 digest algorithms [FIPS180-4], [RFC3874], [RFC6234]. Use of TSIG between two DNS agents is by mutual agreement. That agreement can include the support of additional algorithms and criteria as to which algorithms and truncations are acceptable, subject to the restriction and guidelines in Section 5.2.2.1 above. Key agreement can be by the TKEY mechanism [RFC2930] or some other mutually agreeable method. Dupont, et al. Expires January 11, 2021 [Page 16] Internet-Draft DNS TSIG July 2020 Implementations that support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig and the other algorithms listed below. SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. Name Implementation Use ------------------------ -------------- --------------- HMAC-MD5.SIG-ALG.REG.INT MAY MUST NOT gss-tsig MAY MAY hmac-sha1 MUST NOT RECOMMENDED hmac-sha224 MAY MAY hmac-sha256 MUST RECOMMENDED hmac-sha256-128 MAY MAY hmac-sha384 MAY MAY hmac-sha384-192 MAY MAY hmac-sha512 MAY MAY hmac-sha512-256 MAY MAY Table 2 7. TSIG Truncation Policy As noted above, two DNS agents (e.g., resolver and server) must mutually agree to use TSIG. Implicit in such an "agreement" are criteria as to acceptable keys and algorithms and, with the extensions in this document, truncations. Local policies MAY require the rejection of TSIGs, even though they use an algorithm for which implementation is mandatory. When a local policy permits acceptance of a TSIG with a particular algorithm and a particular non-zero amount of truncation, it SHOULD also permit the use of that algorithm with lesser truncation (a longer MAC) up to the full keyed hash output. Regardless of a lower acceptable truncated MAC length specified by local policy, a reply SHOULD be sent with a MAC at least as long as that in the corresponding request. Note if the request specified a MAC length longer than the keyed hash output it will be rejected by processing rules Section 5.2.2.1 case 1. Implementations permitting multiple acceptable algorithms and/or truncations SHOULD permit this list to be ordered by presumed strength and SHOULD allow different truncations for the same algorithm to be treated as separate entities in this list. When so implemented, policies SHOULD accept a presumed stronger algorithm and truncation than the minimum strength required by the policy. Dupont, et al. Expires January 11, 2021 [Page 17] Internet-Draft DNS TSIG July 2020 8. Shared Secrets Secret keys are very sensitive information and all available steps should be taken to protect them on every host on which they are stored. Generally such hosts need to be physically protected. If they are multi-user machines, great care should be taken that unprivileged users have no access to keying material. Resolvers often run unprivileged, which means all users of a host would be able to see whatever configuration data is used by the resolver. A name server usually runs privileged, which means its configuration data need not be visible to all users of the host. For this reason, a host that implements transaction-based authentication should probably be configured with a "stub resolver" and a local caching and forwarding name server. This presents a special problem for [RFC2136] which otherwise depends on clients to communicate only with a zone's authoritative name servers. Use of strong random shared secrets is essential to the security of TSIG. See [RFC4086] for a discussion of this issue. The secret SHOULD be at least as long as the keyed hash output [RFC2104]. 9. IANA Considerations IANA maintains a registry of algorithm names to be used as "Algorithm Names" as defined in Section 4.2. Algorithm names are text strings encoded using the syntax of a domain name. There is no structure to the names, and algorithm names are compared as if they were DNS names, i.e., comparison is case insensitive. Previous specifications [RFC2845] and [RFC4635] defined values for the HMAC-MD5 and some HMAC-SHA algorithms. IANA has also registered "gss-tsig" as an identifier for TSIG authentication where the cryptographic operations are delegated to the Generic Security Service (GSS) [RFC3645]. This document adds to allowed algorithms, and the registry should be updated with the names listed in Table 2. New algorithms are assigned using the IETF Review policy defined in [RFC8126]. The algorithm name HMAC-MD5.SIG-ALG.REG.INT looks like a fully-qualified domain name for historical reasons; other algorithm names are simple, single-component names. IANA maintains a registry of RCODES (error codes), including "TSIG Error values" to be used for "Error" values as defined in Section 4.2. New error codes are assigned and specified as in [RFC6895]. Dupont, et al. Expires January 11, 2021 [Page 18] Internet-Draft DNS TSIG July 2020 10. Security Considerations The approach specified here is computationally much less expensive than the signatures specified in DNSSEC. As long as the shared secret key is not compromised, strong authentication is provided between two DNS systems, e.g., for the last hop from a local name server to the user resolver, or between primary and secondary nameservers. Recommendations for choosing and maintaining secret keys can be found in [RFC2104]. If the client host has been compromised, the server should suspend the use of all secrets known to that client. If possible, secrets should be stored in encrypted form. Secrets should never be transmitted in the clear over any network. This document does not address the issue on how to distribute secrets except that it mentions the possibilities of manual configuration and the use of TKEY [RFC2930]. Secrets SHOULD NOT be shared by more than two entities; any such additional sharing would allow any party knowing the key to impersonate any other such party to members of the group. This mechanism does not authenticate source data, only its transmission between two parties who share some secret. The original source data can come from a compromised zone master or can be corrupted during transit from an authentic zone master to some "caching forwarder." However, if the server is faithfully performing the full DNSSEC security checks, then only security checked data will be available to the client. A fudge value that is too large may leave the server open to replay attacks. A fudge value that is too small may cause failures if machines are not time synchronized or there are unexpected network delays. The RECOMMENDED value in most situations is 300 seconds. To prevent cross-algorithm attacks, there SHOULD only be one algorithm associated with any given key name. In several cases where errors are detected, an unsigned error message must be returned. This can allow for an attacker to spoof or manipulate these responses. Section 5.4 recommends logging these as errors and continuing to wait for a signed response until the request times out. Although the strength of an algorithm determines its security, there have been some arguments that mild truncation can strengthen a MAC by reducing the information available to an attacker. However, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to break the authentication by brute force [RFC2104]. Dupont, et al. Expires January 11, 2021 [Page 19] Internet-Draft DNS TSIG July 2020 Significant progress has been made recently in cryptanalysis of hash functions of the types used here. While the results so far should not affect HMAC, the stronger SHA-256 algorithm is being made mandatory as a precaution. See also the Security Considerations section of [RFC2104] from which the limits on truncation in this RFC were taken. 10.1. Issue Fixed in this Document When signing a DNS reply message using TSIG, the MAC computation uses the request message's MAC as an input to cryptographically relate the reply to the request. The original TSIG specification [RFC2845] required that the TIME values be checked before the request's MAC. If the TIME was invalid, some implementations failed to carry out further checks and could use an invalid request MAC in the signed reply. This document makes it a mandatory that the request MAC is considered to be invalid until it has been validated: until then, any answer must be unsigned. For this reason, the request MAC is now checked before the TIME value. 10.2. Why not DNSSEC? These extracts from the original document [RFC2845] (updated to reference current standards) analyze DNSSEC in order to justify the introduction of TSIG. DNS has recently been extended by DNSSEC ([RFC4033], [RFC4034] and [RFC4035]) to provide for data origin authentication, and public key distribution, all based on public key cryptography and public key based digital signatures. To be practical, this form of security generally requires extensive local caching of keys and tracing of authentication through multiple keys and signatures to a pre-trusted locally configured key. One difficulty with the DNSSEC scheme is that common DNS implementations include simple "stub" resolvers which do not have caches. Such resolvers typically rely on a caching DNS server on another host. It is impractical for these stub resolvers to perform general DNSSEC authentication and they would naturally depend on their caching DNS server to perform such services for them. To do so securely requires secure communication of queries and responses. DNSSEC provides public key transaction signatures to support this, but such signatures are very expensive computationally to generate. In general, these require the same complex public key logic that is impractical for stubs. Dupont, et al. Expires January 11, 2021 [Page 20] Internet-Draft DNS TSIG July 2020 and A second area where use of straight DNSSEC public key based mechanisms may be impractical is authenticating dynamic update [RFC2136] requests. DNSSEC provides for request signatures but with DNSSEC they, like transaction signatures, require computationally expensive public key cryptography and complex authentication logic. Secure Domain Name System Dynamic Update ([RFC3007]) describes how different keys are used in dynamically updated zones. 11. References 11.1. Normative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, . [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, . [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, DOI 10.17487/RFC4635, August 2006, . Dupont, et al. Expires January 11, 2021 [Page 21] Internet-Draft DNS TSIG July 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [BCP201] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [CVE-2017-11104] Common Vulnerabilities and Exposures, "CVE-2017-11104: Improper TSIG validity period check can allow TSIG forgery", June 2017, . [CVE-2017-3142] Common Vulnerabilities and Exposures, "CVE-2017-3142: An error in TSIG authentication can permit unauthorized zone transfers", June 2017, . [CVE-2017-3143] Common Vulnerabilities and Exposures, "CVE-2017-3143: An error in TSIG authentication can permit unauthorized dynamic updates", June 2017, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, . Dupont, et al. Expires January 11, 2021 [Page 22] Internet-Draft DNS TSIG July 2020 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, . [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, . [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, DOI 10.17487/RFC3645, October 2003, . [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, DOI 10.17487/RFC3874, September 2004, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . Dupont, et al. Expires January 11, 2021 [Page 23] Internet-Draft DNS TSIG July 2020 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [SHA1SHAMBLES] Leurent, G. and T. Peyrin, "SHA-1 is a Shambles", January 2020, . Appendix A. Acknowledgments This document consolidates and updates the earlier documents by the authors of [RFC2845] (Paul Vixie, Olafur Gudmundsson, Donald E. Eastlake 3rd and Brian Wellington) and [RFC4635] (Donald E. Eastlake 3rd). The security problem addressed by this document was reported by Clement Berthaux from Synacktiv. Note for the RFC Editor (to be removed before publication): the first 'e' in Clement is a fact a small 'e' with acute, unicode code U+00E9. I do not know if xml2rfc supports non ASCII characters so I prefer to not experiment with it. BTW I am French too so I can help if you have questions like correct spelling... Peter van Dijk, Benno Overeinder, Willem Toroop, Ondrej Sury, Mukund Sivaraman and Ralph Dolmans participated in the discussions that prompted this document. Mukund Sivaraman, Martin Hoffman and Tony Finch made extremely helpful suggestions concerning the structure and wording of the updated document. Appendix B. Change History (to be removed before publication) RFC EDITOR: Please remove this appendix before publication. draft-dupont-dnsop-rfc2845bis-00 [RFC4635] was merged. Dupont, et al. Expires January 11, 2021 [Page 24] Internet-Draft DNS TSIG July 2020 Authors of original documents were moved to Acknowledgments (Appendix A). Section 2 was updated to [RFC8174] style. Spit references into normative and informative references and updated them. Added a text explaining why this document was written in the Abstract and at the beginning of the introduction. Clarified the layout of TSIG RDATA. Moved the text about using DNSSEC from the Introduction to the end of Security Considerations. Added the security clarifications: 1. Emphasized that MAC is invalid until it is successfully validated. 2. Added requirement that a request MAC that has not been successfully validated MUST NOT be included into a response. 3. Added requirement that a request that has not been validated MUST NOT generate a signed response. 4. Added note about MAC too short for the local policy to Section 5.3.2. 5. Changed the order of server checks and swapped corresponding sections. 6. Removed the truncation size limit "also case" as it does not apply and added confusion. 7. Relocated the error provision for TSIG truncation to the new Section 5.2.4. Moved from RCODE 22 to RCODE 9 and TSIG ERROR 22, i.e., aligned with other TSIG error cases. 8. Added Section 5.4.4 about truncation error handling by clients. 9. Removed the limit to HMAC output in replies as a request which specified a MAC length longer than the HMAC output is invalid according to the first processing rule in Section 5.2.2.1. Dupont, et al. Expires January 11, 2021 [Page 25] Internet-Draft DNS TSIG July 2020 10. Promoted the requirement that a secret length should be at least as long as the HMAC output to a SHOULD [RFC2119] key word. 11. Added a short text to explain the security issue. draft-dupont-dnsop-rfc2845bis-01 Improved wording (post-publication comments). Specialized and renamed the "TSIG on TCP connection" (Section 5.3.1) to "TSIG on zone transfer over a TCP connection". Added a SHOULD for a TSIG in each message (was envelope) for new implementations. draft-ietf-dnsop-rfc2845bis-00 Adopted by the IETF DNSOP working group: title updated and version counter reset to 00. draft-ietf-dnsop-rfc2845bis-01 Relationship between protocol change and principle of assuming the request MAC is invalid until validated clarified. (Jinmei Tatuya) Cross reference to considerations for forwarding servers added. (Bob Harold) Added text from [RFC3645] concerning the signing behavior if a secret key is added during a multi-message exchange. Added reference to [RFC6895]. Many improvements in the wording. Added RFC 2845 authors as co-authors of this document. draft-ietf-dnsop-rfc2845bis-02 Added a recommendation to copy time fields in BADKEY errors. (Mark Andrews) draft-ietf-dnsop-rfc2845bis-03 Further changes as a result of comments by Mukund Sivaraman. Miscellaneous changes to wording. Dupont, et al. Expires January 11, 2021 [Page 26] Internet-Draft DNS TSIG July 2020 draft-ietf-dnsop-rfc2845bis-04 Major restructuring as a result of comprehensive review by Martin Hoffman. Amongst the more significant changes: * More comprehensive introduction. * Merged "Protocol Description" and "Protocol Details" sections. * Reordered sections so as to follow message exchange through "client "sending", "server receipt", "server sending", "client receipt". * Added miscellaneous clarifications. draft-ietf-dnsop-rfc2845bis-05 Make implementation of HMAC-MD5 optional. Require that the Fudge field in BADTIME response be equal to the Fudge field received from the client. Added comment concerning the handling of BADTIME messages due to out of order packet reception. draft-ietf-dnsop-rfc2845bis-06 Wording changes and minor corrections after feedback. draft-ietf-dnsop-rfc2845bis-07 Updated text about use of hmac-sha1 using suggestion from Tony Finch. Corrected name of review policy used for new algorithms. draft-ietf-dnsop-rfc2845bis-08 Addressed comments from IESG review. These can be found at https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ ballot. Significant changes are: * Added references to CVEs that initiated this draft. * Added reference to paper describing SHA1 collisions. * Modified some paragraphs to remove language that has not "aged well". Dupont, et al. Expires January 11, 2021 [Page 27] Internet-Draft DNS TSIG July 2020 * Mentioned that multiple keys allows for periodic key rotation. * Noted that TSIG detects interruption of packet sequence but not premature termination. * Added new algorithms to the algorithm list. * Marked hmac-sha224 as NOT RECOMMENDED. * Added recommendation that there should only be one algorithm for each key. * Added some paragraphs to the security recommendations section. Other changes: * Explicitly define contents Error field in requests. State that "Other Data" currently has no meaning in requests. * Reworked the section on client processing of response to remove ambiguity. * Section on TSIG over TCP now mentions zone transfer as an example, rather than the entire section being about zone transfers. * Note that quote from RFC2845 in "What is DNSSEC?" section has been edited to refer to the latest standards. draft-ietf-dnsop-rfc2845bis-09 Change use of hmac-224 from NOT RECOMMENDED to MAY. Authors' Addresses Francis Dupont Internet Systems Consortium, Inc. PO Box 360 Newmarket, NH 03857 United States of America Email: Francis.Dupont@fdupont.fr Dupont, et al. Expires January 11, 2021 [Page 28] Internet-Draft DNS TSIG July 2020 Stephen Morris Internet Systems Consortium, Inc. PO Box 360 Newmarket, NH 03857 United States of America Email: sa.morris8@gmail.com Paul Vixie Farsight Security Inc 177 Bovet Road, Suite 180 San Mateo, CA 94402 United States of America Email: paul@redbarn.org Donald E. Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America Email: d3e3e3@gmail.com Olafur Gudmundsson Cloudflare San Francisco, CA 94107 United States of America Email: olafur+ietf@cloudflare.com Brian Wellington Akamai United States of America Email: bwelling@akamai.com Dupont, et al. Expires January 11, 2021 [Page 29] ./draft-ietf-bess-dci-evpn-overlay-10.txt0000644000764400076440000020354313246335700017501 0ustar iustyiusty BESS Workgroup J. Rabadan (Ed.) Internet Draft S. Sathappan Intended status: Standards Track W. Henderickx Nokia A. Sajassi Cisco J. Drake Juniper Expires: September 3, 2018 March 2, 2018 Interconnect Solution for EVPN Overlay networks draft-ietf-bess-dci-evpn-overlay-10 Abstract This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private LAN Services (VPLS), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how the existing technical specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, and the use of the Unknown MAC route to avoid MAC scale issues on Data Center Network Virtualization Edge (NVE) devices. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Rabadan et al. Expires September 3, 2018 [Page 1] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 3, 2018. Copyright Notice Copyright (c) 2018 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. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Decoupled Interconnect solution for EVPN overlay networks . . . 6 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 7 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 8 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 9 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 9 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 9 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 10 3.5.3. Handling failures between GW and WAN Edge routers . . . 11 4. Integrated Interconnect solution for EVPN overlay networks . . 11 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 12 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 13 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 13 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 14 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 14 Rabadan et al. Expires September 3, 2018 [Page 2] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 14 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 15 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 15 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 15 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 17 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 18 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 20 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 20 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 21 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 22 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 22 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 22 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 23 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 23 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 23 4.6.1. Globally unique VNIs in the Interconnect network . . . 24 4.6.2. Downstream assigned VNIs in the Interconnect network . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 27 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. AC: Attachment Circuit. ARP: Address Resolution Protocol. BUM: refers to Broadcast, Unknown unicast and Multicast traffic. CE: Customer Equipment. CFM: Connectivity Fault Management. DC and DCI: Data Center and Data Center Interconnect. Rabadan et al. Expires September 3, 2018 [Page 3] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 DC RR(s) and WAN RR(s): refers to the Data Center and Wide Area Network Route Reflectors, respectively. DF and NDF: Designated Forwarder and Non-Designated Forwarder. EVPN: Ethernet Virtual Private Network, as in [RFC7432]. EVI: EVPN Instance. EVPN Tunnel binding: refers to a tunnel to a remote PE/NVE for a given EVI. Ethernet packets in these bindings are encapsulated with the Overlay or MPLS encapsulation and the EVPN label at the bottom of the stack. ES and vES: Ethernet Segment and virtual Ethernet Segment. ESI: Ethernet Segment Identifier. GW: Gateway or Data Center Gateway. I-ES and I-ESI: Interconnect Ethernet Segment and Interconnect Ethernet Segment Identifier. An I-ES is defined on the GWs for multi- homing to/from the WAN. MAC-VRF: refers to an EVI instance in a particular node. MP2P and LSM tunnels: refer to Multi-Point to Point and Label Switched Multicast tunnels. ND: Neighbor Discovery protocol. NVE: Network Virtualization Edge. NVGRE: Network Virtualization using Generic Routing Encapsulation. NVO: refers to Network Virtualization Overlays. OAM: Operations and Maintenance. PBB: Provider Backbone Bridging. PE: Provider Edge. PW: Pseudowire. RD: Route-Distinguisher. RT: Route-Target. Rabadan et al. Expires September 3, 2018 [Page 4] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 S/C-TAG: refers to a combination of Service Tag and Customer Tag in a 802.1Q frame. TOR: Top-Of-Rack switch. UMR: Unknown MAC Route. VNI/VSID: refers to VXLAN/NVGRE virtual identifiers. VPLS: Virtual Private LAN Service. VSI: Virtual Switch Instance or VPLS instance in a particular PE. VXLAN: Virtual eXtensible LAN. 2. Introduction [EVPN-Overlays] discusses the use of Ethernet Virtual Private Networks (EVPN) [RFC7432] as the control plane for Network Virtualization Overlays (NVO), where VXLAN [RFC7348], NVGRE [RFC7637] or MPLS over GRE [RFC4023] can be used as possible data plane encapsulation options. While this model provides a scalable and efficient multi-tenant solution within the Data Center, it might not be easily extended to the Wide Area Network (WAN) in some cases due to the requirements and existing deployed technologies. For instance, a Service Provider might have an already deployed Virtual Private LAN Service (VPLS) [RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging (PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network that has to be used to interconnect Data Centers and WAN VPN users. A Gateway (GW) function is required in these cases. In fact, [EVPN- Overlays] discusses two main Data Center Interconnect solution groups: "DCI using GWs" and "DCI using ASBRs". This document specifies the solutions that correspond to the "DCI using GWs" group. It is assumed that the NVO Gateway (GW) and the WAN Edge functions can be decoupled in two separate systems or integrated into the same system. The former option will be referred as "Decoupled Interconnect solution" throughout the document, whereas the latter one will be referred as "Integrated Interconnect solution". The specified procedures are local to the redundant GWs connecting a DC to the WAN. The document does not preclude any combination across different DCs for the same tenant. For instance, a "Decoupled" solution can be used in GW1 and GW2 (for DC1) and an "Integrated" solution can be used in GW3 and GW4 (for DC2). Rabadan et al. Expires September 3, 2018 [Page 5] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 While the Gateways and WAN PEs use existing specifications in some cases, the document also defines extensions that are specific to DCI. In particular, those extensions are: o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that can be associated to a set of PWs or other tunnels. I-ES defined in this document is not associated with a set of Ethernet links, as per [RFC7432], but rather with a set of virtual tunnels (e.g., a set of PWs). This set of virtual tunnels is referred to as vES [VIRTUAL-ES]. o The use of the Unknown MAC route in a DCI scenario. o The processing of EVPN routes on Gateways with MAC-VRFs connecting EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN- Overlay networks. 3. Decoupled Interconnect solution for EVPN overlay networks This section describes the interconnect solution when the GW and WAN Edge functions are implemented in different systems. Figure 1 depicts the reference model described in this section. Note that, although not shown in Figure 1, GWs may have local ACs (Attachment Circuits). Rabadan et al. Expires September 3, 2018 [Page 6] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 +--+ |CE| +--+ | +----+ +----| PE |----+ +---------+ | +----+ | +---------+ +----+ | +---+ +----+ +----+ +---+ | +----+ |NVE1|--| | | |WAN | |WAN | | | |--|NVE3| +----+ | |GW1|--|Edge| |Edge|--|GW3| | +----+ | +---+ +----+ +----+ +---+ | | NVO-1 | | WAN | | NVO-2 | | +---+ +----+ +----+ +---+ | | | | |WAN | |WAN | | | | +----+ | |GW2|--|Edge| |Edge|--|GW4| | +----+ |NVE2|--| +---+ +----+ +----+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->| hand-off hand-off Figure 1 Decoupled Interconnect model The following section describes the interconnect requirements for this model. 3.1. Interconnect requirements The Decoupled Interconnect architecture is intended to be deployed in networks where the EVPN-Overlay and WAN providers are different entities and a clear demarcation is needed. This solution solves the following requirements: o A simple connectivity hand-off between the EVPN-Overlay network provider and the WAN provider so that QoS and security enforcement is easily accomplished. o Independence of the Layer Two VPN (L2VPN) technology deployed in the WAN. o Multi-homing between GW and WAN Edge routers, including per-service load balancing. Per-flow load balancing is not a strong requirement since a deterministic path per service is usually required for an easy QoS and security enforcement. o Support of Ethernet OAM and Connectivity Fault Management (CFM) [802.1AG][Y.1731] functions between the GW and the WAN Edge router Rabadan et al. Expires September 3, 2018 [Page 7] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 to detect individual AC failures. o Support for the following optimizations at the GW: + Flooding reduction of unknown unicast traffic sourced from the DC Network Virtualization Edge devices (NVEs). + Control of the WAN MAC addresses advertised to the DC. + Address Resolution Protocol (ARP) and Neighbor Discovery (ND) flooding control for the requests coming from the WAN. 3.2. VLAN-based hand-off In this option, the hand-off between the GWs and the WAN Edge routers is based on VLANs [802.1Q-2014]. This is illustrated in Figure 1 (between the GWs in NVO-1 and the WAN Edge routers). Each MAC-VRF in the GW is connected to a different VSI/MAC-VRF instance in the WAN Edge router by using a different C-TAG VLAN ID or a different combination of S/C-TAG VLAN IDs that matches at both sides. This option provides the best possible demarcation between the DC and WAN providers and it does not require control plane interaction between both providers. The disadvantage of this model is the provisioning overhead since the service has to be mapped to a C-TAG or S/C-TAG VLAN ID combination at both GW and WAN Edge routers. In this model, the GW acts as a regular Network Virtualization Edge (NVE) towards the DC. Its control plane, data plane procedures and interactions are described in [EVPN-Overlays]. The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with attachment circuits (ACs) to the GWs. Its functions are described in [RFC4761], [RFC4762], [RFC6074] or [RFC7432], [RFC7623]. 3.3. PW-based (Pseudowire-based) hand-off If MPLS between the GW and the WAN Edge router is an option, a PW- based Interconnect solution can be deployed. In this option the hand-off between both routers is based on FEC128-based PWs [RFC4762] or FEC129-based PWs (for a greater level of network automation) [RFC6074]. Note that this model still provides a clear demarcation boundary between DC and WAN (since there is a single PW between each MAC-VRF and peer VSI), and security/QoS policies may be applied on a per PW basis. This model provides better scalability than a C-TAG based hand-off and less provisioning overhead than a combined C/S-TAG hand-off. The PW-based hand-off interconnect is illustrated in Figure 1 (between the NVO-2 GWs and the WAN Edge routers). In this model, besides the usual MPLS procedures between GW and WAN Rabadan et al. Expires September 3, 2018 [Page 8] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 Edge router [RFC3031], the GW MUST support an interworking function in each MAC-VRF that requires extension to the WAN: o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI (WAN Edge), the corresponding VCID MUST be provisioned on the MAC- VRF and match the VCID used in the peer VSI at the WAN Edge router. o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used between the GW MAC-VRF and the WAN Edge VSI, the provisioning of the VPLS-ID MUST be supported on the MAC-VRF and MUST match the VPLS-ID used in the WAN Edge VSI. If a PW-based handoff is used, the GW's AC (or point of attachment to the EVPN Instance) uses a combination of a PW label and VLAN IDs. PWs are treated as service interfaces defined in [RFC7432]. 3.4. Multi-homing solution on the GWs EVPN single-active multi-homing, i.e. per-service load-balancing multi-homing is required in this type of interconnect. The GWs will be provisioned with a unique ES per WAN interconnect, and the hand-off attachment circuits or PWs between the GW and the WAN Edge router will be assigned an ESI for such ES. The ESI will be administratively configured on the GWs according to the procedures in [RFC7432]. This Interconnect ES will be referred as "I-ES" hereafter, and its identifier will be referred as "I-ESI". [RFC7432] describes different ESI Types. The use of Type 0 for the I-ESI is RECOMMENDED in this document. The solution (on the GWs) MUST follow the single-active multi-homing procedures as described in [EVPN-Overlays] for the provisioned I-ESI, i.e. Ethernet A-D routes per ES and per EVI will be advertised to the DC NVEs for the multi-homing functions, ES routes will be advertised so that ES discovery and Designated Forwarder (DF) procedures can be followed. The MAC addresses learned (in the data plane) on the hand- off links will be advertised with the I-ESI encoded in the ESI field. 3.5. Gateway Optimizations The following GW features are optional and optimize the control plane and data plane in the DC. 3.5.1. MAC Address Advertisement Control The use of EVPN in NVO networks brings a significant number of benefits as described in [EVPN-Overlays]. However, if multiple DCs Rabadan et al. Expires September 3, 2018 [Page 9] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 are interconnected into a single EVI, each DC will have to import all of the MAC addresses from each of the other DCs. Even if optimized BGP techniques like RT-constraint [RFC4684] are used, the number of MAC addresses to advertise or withdraw (in case of failure) by the GWs of a given DC could overwhelm the NVEs within that DC, particularly when the NVEs reside in the hypervisors. The solution specified in this document uses the 'Unknown MAC Route' (UMR) which is advertised into a given DC by each of the DC's GWs. This route is defined in [RFC7543] and is a regular EVPN MAC/IP Advertisement route in which the MAC Address Length is set to 48, the MAC address is set to 0, and the ESI field is set to the DC GW's I- ESI. An NVE within that DC that understands and process the UMR will send unknown unicast frames to one of the DCs GWs, which will then forward that packet to the correct egress PE. Note that, because the ESI is set to the DC GW's I-ESI, all-active multi-homing can be applied to unknown unicast MAC addresses. An NVE that does not understand the Unknown MAC route will handle unknown unicast as described in [RFC7432]. This document proposes that local policy determines whether MAC addresses and/or the UMR are advertised into a given DC. As an example, when all the DC MAC addresses are learned in the control/management plane, it may be appropriate to advertise only the UMR. Advertising all the DC MAC addresses in the control/management plane is usually the case when the NVEs reside in hypervisors. Refer to [EVPN-Overlays] section 7. It is worth noting that the UMR usage in [RFC7543] and the UMR usage in this document are different. In the former, a Virtual Spoke (V- spoke) does not necessarily learn all the MAC addresses pertaining to hosts in other V-spokes of the same network. The communication between two V-spokes is done through the DMG, until the V-spokes learn each other's MAC addresses. In this document, two leaf switches in the same DC are recommended to learn each other's MAC addresses for the same EVI. The leaf to leaf communication is always direct and does not go through the GW. 3.5.2. ARP/ND flooding control Another optimization mechanism, naturally provided by EVPN in the GWs, is the Proxy ARP/ND function. The GWs should build a Proxy ARP/ND cache table as per [RFC7432]. When the active GW receives an ARP/ND request/solicitation coming from the WAN, the GW does a Proxy Rabadan et al. Expires September 3, 2018 [Page 10] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 ARP/ND table lookup and replies as long as the information is available in its table. This mechanism is especially recommended on the GWs, since it protects the DC network from external ARP/ND-flooding storms. 3.5.3. Handling failures between GW and WAN Edge routers Link/PE failures are handled on the GWs as specified in [RFC7432]. The GW detecting the failure will withdraw the EVPN routes as per [RFC7432]. Individual AC/PW failures may be detected by OAM mechanisms. For instance: o If the Interconnect solution is based on a VLAN hand-off, Ethernet- CFM [802.1AG][Y.1731] may be used to detect individual AC failures on both, the GW and WAN Edge router. An individual AC failure will trigger the withdrawal of the corresponding A-D per EVI route as well as the MACs learned on that AC. o If the Interconnect solution is based on a PW hand-off, the Label Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be used to detect individual PW failures on both, the GW and WAN Edge router. 4. Integrated Interconnect solution for EVPN overlay networks When the DC and the WAN are operated by the same administrative entity, the Service Provider can decide to integrate the GW and WAN Edge PE functions in the same router for obvious CAPEX and OPEX saving reasons. This is illustrated in Figure 2. Note that this model does not provide an explicit demarcation link between DC and WAN anymore. Although not shown in Figure 2, note that the GWs may have local ACs. Rabadan et al. Expires September 3, 2018 [Page 11] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 +--+ |CE| +--+ | +----+ +----| PE |----+ +---------+ | +----+ | +---------+ +----+ | +---+ +---+ | +----+ |NVE1|--| | | | | |--|NVE3| +----+ | |GW1| |GW3| | +----+ | +---+ +---+ | | NVO-1 | WAN | NVO-2 | | +---+ +---+ | | | | | | | +----+ | |GW2| |GW4| | +----+ |NVE2|--| +---+ +---+ |--|NVE4| +----+ +---------+ | | +---------+ +----+ +--------------+ |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->| |<--PBB-VPLS-->| Interconnect -> |<-EVPN-MPLS-->| options |<--EVPN-Ovl-->|* |<--PBB-EVPN-->| Figure 2 Integrated Interconnect model * EVPN-Ovl stands for EVPN-Overlay (and it's an Interconnect option). 4.1. Interconnect requirements The Integrated Interconnect solution meets the following requirements: o Control plane and data plane interworking between the EVPN-overlay network and the L2VPN technology supported in the WAN, irrespective of the technology choice, i.e. (PBB-)VPLS or (PBB-)EVPN, as depicted in Figure 2. o Multi-homing, including single-active multi-homing with per-service load balancing or all-active multi-homing, i.e. per-flow load- balancing, as long as the technology deployed in the WAN supports it. o Support for end-to-end MAC Mobility, Static MAC protection and other procedures (e.g. proxy-arp) described in [RFC7432] as long as EVPN-MPLS is the technology of choice in the WAN. Rabadan et al. Expires September 3, 2018 [Page 12] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o Independent inclusive multicast trees in the WAN and in the DC. That is, the inclusive multicast tree type defined in the WAN does not need to be the same as in the DC. 4.2. VPLS Interconnect for EVPN-Overlay networks 4.2.1. Control/Data Plane setup procedures on the GWs Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that different route-targets for the DC and for the WAN are normally required (unless [RFC4762] is used in the WAN, in which case no WAN route-target is needed). A single type-1 RD per service may be used. In order to support multi-homing, the GWs will be provisioned with an I-ESI (see section 3.4), that will be unique per interconnection. The I-ES in this case will represent the group of PWs to the WAN PEs and GWs. All the [RFC7432] procedures are still followed for the I-ES, e.g. any MAC address learned from the WAN will be advertised to the DC with the I-ESI in the ESI field. A MAC-VRF per EVI will be created in each GW. The MAC-VRF will have two different types of tunnel bindings instantiated in two different split-horizon-groups: o VPLS PWs will be instantiated in the "WAN split-horizon-group". o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated in the "DC split-horizon-group". Attachment circuits are also supported on the same MAC-VRF (although not shown in Figure 2), but they will not be part of any of the above split-horizon-groups. Traffic received in a given split-horizon-group will never be forwarded to a member of the same split-horizon-group. As far as BUM flooding is concerned, a flooding list will be composed of the sub-list created by the inclusive multicast routes and the sub-list created for VPLS in the WAN. BUM frames received from a local Attachment Circuit (AC) will be forwarded to the flooding list. BUM frames received from the DC or the WAN will be forwarded to the flooding list observing the split-horizon-group rule described above. Note that the GWs are not allowed to have an EVPN binding and a PW to the same far-end within the same MAC-VRF, so that loops and packet duplication are avoided. In case a GW can successfully establish Rabadan et al. Expires September 3, 2018 [Page 13] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 both, an EVPN binding and a PW to the same far-end PE, the EVPN binding will prevail and the PW will be brought operationally down. The optimizations procedures described in section 3.5 can also be applied to this model. 4.2.2. Multi-homing procedures on the GWs This model supports single-active multi-homing on the GWs. All-active multi-homing is not supported by VPLS, therefore it cannot be used on the GWs. In this case, for a given EVI, all the PWs in the WAN split-horizon- group are assigned to I-ES. All the single-active multi-homing procedures as described by [EVPN-Overlays] will be followed for the I-ES. The non-DF GW for the I-ES will block the transmission and reception of all the PWs in the "WAN split-horizon-group" for BUM and unicast traffic. 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks 4.3.1. Control/Data Plane setup procedures on the GWs In this case, there is no impact on the procedures described in [RFC7041] for the B-component. However the I-component instances become EVI instances with EVPN-Overlay bindings and potentially local attachment circuits. A number of MAC-VRF instances can be multiplexed into the same B-component instance. This option provides significant savings in terms of PWs to be maintained in the WAN. The I-ESI concept described in section 4.2.1 will also be used for the PBB-VPLS-based Interconnect. B-component PWs and I-component EVPN-overlay bindings established to the same far-end will be compared. The following rules will be observed: o Attempts to setup a PW between the two GWs within the B- component context will never be blocked. o If a PW exists between two GWs for the B-component and an attempt is made to setup an EVPN binding on an I-component linked to that B-component, the EVPN binding will be kept operationally down. Note that the BGP EVPN routes will still be valid but not used. Rabadan et al. Expires September 3, 2018 [Page 14] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o The EVPN binding will only be up and used as long as there is no PW to the same far-end in the corresponding B-component. The EVPN bindings in the I-components will be brought down before the PW in the B-component is brought up. The optimizations procedures described in section 3.5 can also be applied to this Interconnect option. 4.3.2. Multi-homing procedures on the GWs This model supports single-active multi-homing on the GWs. All-active multi-homing is not supported by this scenario. The single-active multi-homing procedures as described by [EVPN- Overlays] will be followed for the I-ES for each EVI instance connected to the B-component. Note that in this case, for a given EVI, all the EVPN bindings in the I-component are assigned to the I- ES. The non-DF GW for the I-ES will block the transmission and reception of all the I-component EVPN bindings for BUM and unicast traffic. When learning MACs from the WAN, the non-DF MUST NOT advertise EVPN MAC/IP routes for those MACs. 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks If EVPN for MPLS tunnels, EVPN-MPLS hereafter, is supported in the WAN, an end-to-end EVPN solution can be deployed. The following sections describe the proposed solution as well as the impact required on the [RFC7432] procedures. 4.4.1. Control Plane setup procedures on the GWs The GWs MUST establish separate BGP sessions for sending/receiving EVPN routes to/from the DC and to/from the WAN. Normally each GW will setup one BGP EVPN session to the DC RR (or two BGP EVPN sessions if there are redundant DC RRs) and one session to the WAN RR (or two sessions if there are redundant WAN RRs). In order to facilitate separate BGP processes for DC and WAN, EVPN routes sent to the WAN SHOULD carry a different route-distinguisher (RD) than the EVPN routes sent to the DC. In addition, although reusing the same value is possible, different route-targets are expected to be handled for the same EVI in the WAN and the DC. Note that the EVPN service routes sent to the DC RRs will normally include a [TUNNEL-ENCAP] BGP encapsulation extended community with a different tunnel type than the one sent to the WAN RRs. As in the other discussed options, an I-ES and its assigned I-ESI Rabadan et al. Expires September 3, 2018 [Page 15] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 will be configured on the GWs for multi-homing. This I-ES represents the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to the WAN. Optionally, different I-ESI values are configured for representing the WAN and the DC. If different EVPN-Overlay networks are connected to the same group of GWs, each EVPN-Overlay network MUST get assigned a different I-ESI. Received EVPN routes will never be reflected on the GWs but consumed and re-advertised (if needed): o Ethernet A-D routes, ES routes and Inclusive Multicast routes are consumed by the GWs and processed locally for the corresponding [RFC7432] procedures. o MAC/IP advertisement routes will be received, imported and if they become active in the MAC-VRF, the information will be re- advertised as new routes with the following fields: + The RD will be the GW's RD for the MAC-VRF. + The ESI will be set to the I-ESI. + The Ethernet-tag value will be kept from the received NLRI. + The MAC length, MAC address, IP Length and IP address values will be kept from the received NLRI. + The MPLS label will be a local 20-bit value (when sent to the WAN) or a DC-global 24-bit value (when sent to the DC for encapsulations using a VNI). + The appropriate Route-Targets (RTs) and [TUNNEL-ENCAP] BGP Encapsulation extended community will be used according to [EVPN-Overlays]. The GWs will also generate the following local EVPN routes that will be sent to the DC and WAN, with their corresponding RTs and [TUNNEL- ENCAP] BGP Encapsulation extended community values: o ES route(s) for the I-ESI(s). o Ethernet A-D routes per ES and EVI for the I-ESI(s). The A-D per-EVI routes sent to the WAN and the DC will have consistent Ethernet-Tag values. o Inclusive Multicast routes with independent tunnel type value for the WAN and DC. E.g. a P2MP LSP may be used in the WAN whereas ingress replication may be used in the DC. The routes Rabadan et al. Expires September 3, 2018 [Page 16] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 sent to the WAN and the DC will have a consistent Ethernet-Tag. o MAC/IP advertisement routes for MAC addresses learned in local attachment circuits. Note that these routes will not include the I-ESI, but ESI=0 or different from 0 for local multi-homed Ethernet Segments (ES). The routes sent to the WAN and the DC will have a consistent Ethernet-Tag. Assuming GW1 and GW2 are peer GWs of the same DC, each GW will generate two sets of the above local service routes: Set-DC will be sent to the DC RRs and will include A-D per EVI, Inclusive Multicast and MAC/IP routes for the DC encapsulation and RT. Set-WAN will be sent to the WAN RRs and will include the same routes but using the WAN RT and encapsulation. GW1 and GW2 will receive each other's set- DC and set-WAN. This is the expected behavior on GW1 and GW2 for locally generated routes: o Inclusive multicast routes: when setting up the flooding lists for a given MAC-VRF, each GW will include its DC peer GW only in the EVPN-MPLS flooding list (by default) and not the EVPN- Overlay flooding list. That is, GW2 will import two Inclusive Multicast routes from GW1 (from set-DC and set-WAN) but will only consider one of the two, having the set-WAN route higher priority. An administrative option MAY change this preference so that the set-DC route is selected first. o MAC/IP advertisement routes for local attachment circuits: as above, the GW will select only one, having the route from the set-WAN a higher priority. As with the Inclusive multicast routes, an administrative option MAY change this priority. 4.4.2. Data Plane setup procedures on the GWs The procedure explained at the end of the previous section will make sure there are no loops or packet duplication between the GWs of the same EVPN-Overlay network (for frames generated from local ACs) since only one EVPN binding per EVI (or per Ethernet Tag in case of VLAN- aware bundle services) will be setup in the data plane between the two nodes. That binding will by default be added to the EVPN-MPLS flooding list. As for the rest of the EVPN tunnel bindings, they will be added to one of the two flooding lists that each GW sets up for the same MAC- VRF: o EVPN-overlay flooding list (composed of bindings to the remote NVEs or multicast tunnel to the NVEs). Rabadan et al. Expires September 3, 2018 [Page 17] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the remote PEs) Each flooding list will be part of a separate split-horizon-group: the WAN split-horizon-group or the DC split-horizon-group. Traffic generated from a local AC can be flooded to both split-horizon-groups. Traffic from a binding of a split-horizon-group can be flooded to the other split-horizon-group and local ACs, but never to a member of its own split-horizon-group. When either GW1 or GW2 receive a BUM frame on an MPLS tunnel including an ESI label at the bottom of the stack, they will perform an ESI label lookup and split-horizon filtering as per [RFC7432] in case the ESI label identifies a local ESI (I-ESI or any other non- zero ESI). 4.4.3. Multi-homing procedure extensions on the GWs This model supports single-active as well as all-active multi-homing. All the [RFC7432] multi-homing procedures for the DF election on I- ES(s) as well as the backup-path (single-active) and aliasing (all- active) procedures will be followed on the GWs. Remote PEs in the EVPN-MPLS network will follow regular [RFC7432] aliasing or backup- path procedures for MAC/IP routes received from the GWs for the same I-ESI. So will NVEs in the EVPN-Overlay network for MAC/IP routes received with the same I-ESI. As far as the forwarding plane is concerned, by default, the EVPN- Overlay network will have an analogous behavior to the access ACs in [RFC7432] multi-homed Ethernet Segments. The forwarding behavior on the GWs is described below: o Single-active multi-homing; assuming a WAN split-horizon-group (comprised of EVPN-MPLS bindings), a DC split-horizon-group (comprised of EVPN-Overlay bindings) and local ACs on the GWs: + Forwarding behavior on the non-DF: the non-DF MUST block ingress and egress forwarding on the EVPN-Overlay bindings associated to the I-ES. The EVPN-MPLS network is considered to be the core network and the EVPN-MPLS bindings to the remote PEs and GWs will be active. + Forwarding behavior on the DF: the DF MUST NOT forward BUM or unicast traffic received from a given split-horizon-group to a member of his own split-horizon group. Forwarding to other Rabadan et al. Expires September 3, 2018 [Page 18] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 split-horizon-groups and local ACs is allowed (as long as the ACs are not part of an ES for which the node is non-DF). As per [RFC7432] and for split-horizon purposes, when receiving BUM traffic on the EVPN-Overlay bindings associated to an I- ES, the DF GW SHOULD add the I-ESI label when forwarding to the peer GW over EVPN-MPLS. + When receiving EVPN MAC/IP routes from the WAN, the non-DF MUST NOT re-originate the EVPN routes and advertise them to the DC peers. In the same way, EVPN MAC/IP routes received from the DC MUST NOT be advertised to the WAN peers. This is consistent with [RFC7432] and allows the remote PE/NVEs know who the primary GW is, based on the reception of the MAC/IP routes. o All-active multi-homing; assuming a WAN split-horizon-group (comprised of EVPN-MPLS bindings), a DC split-horizon-group (comprised of EVPN-Overlay bindings) and local ACs on the GWs: + Forwarding behavior on the non-DF: the non-DF follows the same behavior as the non-DF in the single-active case but only for BUM traffic. Unicast traffic received from a split-horizon- group MUST NOT be forwarded to a member of its own split- horizon-group but can be forwarded normally to the other split-horizon-groups and local ACs. If a known unicast packet is identified as a "flooded" packet, the procedures for BUM traffic MUST be followed. + Forwarding behavior on the DF: the DF follows the same behavior as the DF in the single-active case but only for BUM traffic. Unicast traffic received from a split-horizon-group MUST NOT be forwarded to a member of its own split-horizon- group but can be forwarded normally to the other split- horizon-group and local ACs. If a known unicast packet is identified as a "flooded" packet, the procedures for BUM traffic MUST be followed. As per [RFC7432] and for split- horizon purposes, when receiving BUM traffic on the EVPN- Overlay bindings associated to an I-ES, the DF GW MUST add the I-ESI label when forwarding to the peer GW over EVPN-MPLS. + Contrary to the single-active multi-homing case, both DF and non-DF re-originate and advertise MAC/IP routes received from the WAN/DC peers, adding the corresponding I-ESI so that the remote PE/NVEs can perform regular aliasing as per [RFC7432]. The example in Figure 3 illustrates the forwarding of BUM traffic originated from an NVE on a pair of all-active multi-homing GWs. Rabadan et al. Expires September 3, 2018 [Page 19] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 |<--EVPN-Overlay--->|<--EVPN-MPLS-->| +---------+ +--------------+ +----+ BUM +---+ | |NVE1+----+----> | +-+-----+ | +----+ | | DF |GW1| | | | | | +-+-+ | | ++--+ | | | | +--> |PE1| | +--->X +-+-+ | ++--+ | NDF| | | | +----+ | |GW2<-+ | |NVE2+--+ +-+-+ | +----+ +--------+ | +------------+ v +--+ |CE| +--+ Figure 3 Multi-homing BUM forwarding GW2 is the non-DF for the I-ES and blocks the BUM forwarding. GW1 is the DF and forwards the traffic to PE1 and GW2. Packets sent to GW2 will include the ESI-label for the I-ES. Based on the ESI-label, GW2 identifies the packets as I-ES-generated packets and will only forward them to local ACs (CE in the example) and not back to the EVPN-Overlay network. 4.4.4. Impact on MAC Mobility procedures MAC Mobility procedures described in [RFC7432] are not modified by this document. Note that an intra-DC MAC move still leaves the MAC attached to the same I-ES, so under the rules of [RFC7432] this is not considered a MAC mobility event. Only when the MAC moves from the WAN domain to the DC domain (or from one DC to another) the MAC will be learned from a different ES and the MAC Mobility procedures will kick in. The sticky bit indication in the MAC Mobility extended community MUST be propagated between domains. 4.4.5. Gateway optimizations All the Gateway optimizations described in section 3.5 MAY be applied to the GWs when the Interconnect is based on EVPN-MPLS. In particular, the use of the Unknown MAC Route, as described in Rabadan et al. Expires September 3, 2018 [Page 20] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 section 3.5.1, solves some transient packet duplication issues in cases of all-active multi-homing, as explained below. Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- active multi-homing, and the following sequence: a) MAC Address M1 is advertised from NVE3 in EVI-1. b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN with I-ESI-2 in the ESI field. c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following the EVPN aliasing procedures. d) Before NVE1 learns M1, a packet arrives at NVE1 with destination M1. If the Unknown MAC Route had not been advertised into the DC, NVE1 would have flooded the packet throughout the DC, in particular to both GW1 and GW2. If the same VNI/VSID is used for both known unicast and BUM traffic, as is typically the case, there is no indication in the packet that it is a BUM packet and both GW1 and GW2 would have forwarded it, creating packet duplication. However, because the Unknown MAC Route had been advertised into the DC, NVE1 will unicast the packet to either GW1 or GW2. e) Since both GW1 and GW2 know M1, the GW receiving the packet will forward it to either GW3 or GW4. 4.4.6. Benefits of the EVPN-MPLS Interconnect solution The [EVPN-Overlays] "DCI using ASBRs" solution and the GW solution with EVPN-MPLS Interconnect may be seen similar since they both retain the EVPN attributes between Data Centers and throughout the WAN. However the EVPN-MPLS Interconnect solution on the GWs has significant benefits compared to the "DCI using ASBRs" solution: o As in any of the described GW models, this solution supports the connectivity of local attachment circuits on the GWs. This is not possible in a "DCI using ASBRs" solution. o Different data plane encapsulations can be supported in the DC and the WAN, while a uniform encapsulation is needed in the "DCI using ASBRs" solution. o Optimized multicast solution, with independent inclusive multicast trees in DC and WAN. Rabadan et al. Expires September 3, 2018 [Page 21] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 o MPLS Label aggregation: for the case where MPLS labels are signaled from the NVEs for MAC/IP Advertisement routes, this solution provides label aggregation. A remote PE MAY receive a single label per GW MAC-VRF as opposed to a label per NVE/MAC- VRF connected to the GW MAC-VRF. For instance, in Figure 2, PE would receive only one label for all the routes advertised for a given MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF. o The GW will not propagate MAC mobility for the MACs moving within a DC. Mobility intra-DC is solved by all the NVEs in the DC. The MAC Mobility procedures on the GWs are only required in case of mobility across DCs. o Proxy-ARP/ND function on the DC GWs can be leveraged to reduce ARP/ND flooding in the DC or/and in the WAN. 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks PBB-EVPN [RFC7623] is yet another Interconnect option. It requires the use of GWs where I-components and associated B-components are part of EVI instances. 4.5.1. Control/Data Plane setup procedures on the GWs EVPN will run independently in both components, the I-component MAC- VRF and B-component MAC-VRF. Compared to [RFC7623], the DC C-MACs are no longer learned in the data plane on the GW but in the control plane through EVPN running on the I-component. Remote C-MACs coming from remote PEs are still learned in the data plane. B-MACs in the B- component will be assigned and advertised following the procedures described in [RFC7623]. An I-ES will be configured on the GWs for multi-homing, but its I-ESI will only be used in the EVPN control plane for the I-component EVI. No non-reserved ESIs will be used in the control plane of the B- component EVI as per [RFC7623], that is, the I-ES will be represented to the WAN PBB-EVPN PEs using shared or dedicated B-MACs. The rest of the control plane procedures will follow [RFC7432] for the I-component EVI and [RFC7623] for the B-component EVI. From the data plane perspective, the I-component and B-component EVPN bindings established to the same far-end will be compared and the I- component EVPN-overlay binding will be kept down following the rules described in section 4.3.1. 4.5.2. Multi-homing procedures on the GWs Rabadan et al. Expires September 3, 2018 [Page 22] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 This model supports single-active as well as all-active multi-homing. The forwarding behavior of the DF and non-DF will be changed based on the description outlined in section 4.4.3, only replacing the "WAN split-horizon-group" for the B-component, and using [RFC7623] procedures for the traffic sent or received on the B-component. 4.5.3. Impact on MAC Mobility procedures C-MACs learned from the B-component will be advertised in EVPN within the I-component EVI scope. If the C-MAC was previously known in the I-component database, EVPN would advertise the C-MAC with a higher sequence number, as per [RFC7432]. From a Mobility perspective and the related procedures described in [RFC7432], the C-MACs learned from the B-component are considered local. 4.5.4. Gateway optimizations All the considerations explained in section 4.4.5 are applicable to the PBB-EVPN Interconnect option. 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks If EVPN for Overlay tunnels is supported in the WAN and a GW function is required, an end-to-end EVPN solution can be deployed. While multiple Overlay tunnel combinations at the WAN and the DC are possible (MPLSoGRE, nvGRE, etc.), VXLAN is described here, given its popularity in the industry. This section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the [RFC7432] procedures. The procedures described in section 4.4 apply to this section too, only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and using [EVPN-Overlays] "Local Bias" procedures instead of section 4.4.3. Since there are no ESI-labels in VXLAN, GWs need to rely on "Local Bias" to apply split-horizon on packets generated from the I- ES and sent to the peer GW. This use-case assumes that NVEs need to use the VNIs or VSIDs as a globally unique identifiers within a data center, and a Gateway needs to be employed at the edge of the data center network to translate the VNI or VSID when crossing the network boundaries. This GW function provides VNI and tunnel IP address translation. The use-case in which local downstream assigned VNIs or VSIDs can be used (like MPLS labels) is described by [EVPN-Overlays]. While VNIs are globally significant within each DC, there are two possibilities in the Interconnect network: Rabadan et al. Expires September 3, 2018 [Page 23] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 a) Globally unique VNIs in the Interconnect network: In this case, the GWs and PEs in the Interconnect network will agree on a common VNI for a given EVI. The RT to be used in the Interconnect network can be auto-derived from the agreed Interconnect VNI. The VNI used inside each DC MAY be the same as the Interconnect VNI. b) Downstream assigned VNIs in the Interconnect network. In this case, the GWs and PEs MUST use the proper RTs to import/export the EVPN routes. Note that even if the VNI is downstream assigned in the Interconnect network, and unlike option (a), it only identifies the pair and not the pair. The VNI used inside each DC MAY be the same as the Interconnect VNI. GWs SHOULD support multiple VNI spaces per EVI (one per Interconnect network they are connected to). In both options, NVEs inside a DC only have to be aware of a single VNI space, and only GWs will handle the complexity of managing multiple VNI spaces. In addition to VNI translation above, the GWs will provide translation of the tunnel source IP for the packets generated from the NVEs, using their own IP address. GWs will use that IP address as the BGP next-hop in all the EVPN updates to the Interconnect network. The following sections provide more details about these two options. 4.6.1. Globally unique VNIs in the Interconnect network Considering Figure 2, if a host H1 in NVO-1 needs to communicate with a host H2 in NVO-2, and assuming that different VNIs are used in each DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs MUST be translated to a common Interconnect VNI (e.g. VNI- 100) on the GWs. Each GW is provisioned with a VNI translation mapping so that it can translate the VNI in the control plane when sending BGP EVPN route updates to the Interconnect network. In other words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the BGP update messages for H1's MAC route. This mapping is also used to translate the VNI in the data plane in both directions, that is, VNI- 10 to VNI-100 when the packet is received from NVO-1 and the reverse mapping from VNI-100 to VNI-10 when the packet is received from the remote NVO-2 network and needs to be forwarded to NVO-1. The procedures described in section 4.4 will be followed, considering that the VNIs advertised/received by the GWs will be translated accordingly. 4.6.2. Downstream assigned VNIs in the Interconnect network Rabadan et al. Expires September 3, 2018 [Page 24] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 In this case, if a host H1 in NVO-1 needs to communicate with a host H2 in NVO-2, and assuming that different VNIs are used in each DC for the same EVI, e.g. VNI-10 in NVO-1 and VNI-20 in NVO-2, then the VNIs MUST be translated as in section 4.6.1. However, in this case, there is no need to translate to a common Interconnect VNI on the GWs. Each GW can translate the VNI received in an EVPN update to a locally assigned VNI advertised to the Interconnect network. Each GW can use a different Interconnect VNI, hence this VNI does not need to be agreed on all the GWs and PEs of the Interconnect network. The procedures described in section 4.4 will be followed, taking the considerations above for the VNI translation. 5. Security Considerations This document applies existing specifications to a number of Interconnect models. The Security Considerations included in those documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761] and [RFC4762] apply to this document whenever those technologies are used. As discussed, [EVPN-Overlays] discusses two main DCI solution groups: "DCI using GWs" and "DCI using ASBRs". This document specifies the solutions that correspond to the "DCI using GWs" group. It is important to note that the use of GWs provide a superior level of security on a per tenant basis, compared to the use of ASBRs. This is due to the fact that GWs need to perform a MAC lookup on the frames being received from the WAN, and they apply security procedures, such as filtering of undesired frames, filtering of frames with a source MAC that matches a protected MAC in the DC or application of MAC duplication procedures defined in [RFC7432]. On ASBRs though, traffic is forwarded based on a label or VNI swap and there is usually no visibility of the encapsulated frames, which can carry malicious traffic. In addition, the GW optimizations specified in this document, provide additional protection of the DC Tenant Systems. For instance, the MAC address advertisement control and Unknown MAC Route defined in section 3.5.1 protect the DC NVEs from being overwhelmed with an excessive number MAC/IP routes being learned on the GWs from the WAN. The ARP/ND flooding control described in 3.5.2 can reduce/suppress broadcast storms being injected from the WAN. Finally, the reader should be aware of the potential security implications of designing a DCI with the Decoupled Interconnect solution (section 3) or the Integrated Interconnect solution (section 4). In the Decoupled Interconnect solution the DC is typically easier Rabadan et al. Expires September 3, 2018 [Page 25] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 to protect from the WAN, since each GW has a single logical link to one WAN PE, whereas in the Integrated solution, the GW has logical links to all the WAN PEs that are attached to the tenant. In either model, proper control plane and data plane policies should be put in place in the GWs in order to protect the DC from potential attacks coming from the WAN. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, . [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, . [RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 10.17487/RFC7041, November 2013, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC Rabadan et al. Expires September 3, 2018 [Page 26] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-08, work in progress, January 11, 2018. [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, . [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt, work in progress, January 2018. [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 10.17487/RFC7543, May 2015, . 7.2. Informative References [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using Generic Routing Encapsulation", RFC 7637, September, 2015 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, . [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms for Ethernet based networks", July 2011. Rabadan et al. Expires September 3, 2018 [Page 27] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 [802.1AG] IEEE 802.1AG_2007, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", January 2008. [802.1Q-2014] IEEE 802.1Q-2014, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", December 2014. [RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire Preferential Forwarding Status Bit", RFC 6870, DOI 10.17487/RFC6870, February 2013, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [VIRTUAL-ES] Sajassi et al., "EVPN Virtual Ethernet Segment", draft- sajassi-bess-evpn-virtual-eth-segment-03, work in progress, February 2018. 8. Acknowledgments The authors would like to thank Neil Hart, Vinod Prabhu and Kiran Nagaraj for their valuable comments and feedback. We would also like to thank Martin Vigoureux and Alvaro Retana for his detailed review and comments. 9. Contributors In addition to the authors listed on the front page, the following co-authors have also contributed to this document: Ravi Shekhar Anil Lohiya Wen Lin Juniper Networks Florin Balus Patrice Brissette Cisco Senad Palislamovic Nokia Dennis Cai Alibaba Rabadan et al. Expires September 3, 2018 [Page 28] Internet-Draft Interconnect for EVPN-Overlays March 2, 2018 10. Authors' Addresses Jorge Rabadan Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Senthil Sathappan Nokia Email: senthil.sathappan@nokia.com Wim Henderickx Nokia Email: wim.henderickx@nokia.com Ali Sajassi Cisco Email: sajassi@cisco.com John Drake Juniper Email: jdrake@juniper.net Rabadan et al. Expires September 3, 2018 [Page 29] ./draft-ietf-clue-signaling-15.txt0000644000764400076440000030111113573602053016260 0ustar iustyiusty Network Working Group R. Hanton Internet-Draft Cisco Systems Intended status: Standards Track P. Kyzivat Expires: June 11, 2020 L. Xiao Huawei C. Groves December 9, 2019 Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) draft-ietf-clue-signaling-15 Abstract This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 11, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Hanton, et al. Expires June 11, 2020 [Page 1] Internet-Draft CLUE Signaling December 2019 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. Media Feature Tag Definition . . . . . . . . . . . . . . . . 4 4. SDP Grouping Framework CLUE Extension Semantics . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. The CLUE data channel and the CLUE grouping semantic . . 5 4.3. CLUE-controlled media and the CLUE grouping semantic . . 5 4.4. SDP semantics for CLUE-controlled media . . . . . . . . . 5 4.4.1. Signaling CLUE Encodings . . . . . . . . . . . . . . 6 4.4.1.1. Referencing Encodings in the CLUE protocol . . . 6 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP 7 4.5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 7 4.5.1. Generating the Initial Offer . . . . . . . . . . . . 7 4.5.2. Generating the Answer . . . . . . . . . . . . . . . . 8 4.5.2.1. Negotiating use of CLUE and the CLUE data channel 8 4.5.2.2. Negotiating CLUE-controlled media . . . . . . . . 8 4.5.2.3. Negotiating non-CLUE controlled media . . . . . . 9 4.5.3. Processing the initial Offer/Answer negotiation . . . 9 4.5.3.1. Successful CLUE negotiation . . . . . . . . . . . 9 4.5.3.2. CLUE negotiation failure . . . . . . . . . . . . 10 4.5.4. Modifying the session . . . . . . . . . . . . . . . . 10 4.5.4.1. Adding and removing CLUE-controlled media . . . . 10 4.5.4.2. Enabling CLUE mid-call . . . . . . . . . . . . . 10 4.5.4.3. Disabling CLUE mid-call . . . . . . . . . . . . . 10 4.5.4.4. CLUE protocol failure mid-call . . . . . . . . . 11 5. Interaction of CLUE protocol and SDP negotiations . . . . . . 11 5.1. Independence of SDP and CLUE negotiation . . . . . . . . 12 5.2. Constraints on sending media . . . . . . . . . . . . . . 13 5.3. Recommendations for operating with non-atomic operations 13 6. Interaction of CLUE protocol and RTP/RTCP CaptureID . . . . . 14 6.1. CaptureID reception during MCC redefinition . . . . . . . 14 7. Multiplexing of CLUE-controlled media using BUNDLE . . . . . 15 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Usage of BUNDLE with CLUE . . . . . . . . . . . . . . . . 15 7.2.1. Generating the Initial Offer . . . . . . . . . . . . 16 7.2.2. Multiplexing of the data channel and RTP media . . . 16 8. Example: A call between two CLUE-capable Endpoints . . . . . 16 9. Example: A call between a CLUE-capable and non-CLUE Endpoint 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11.1. New SDP Grouping Framework Attribute . . . . . . . . . . 27 Hanton, et al. Expires June 11, 2020 [Page 2] Internet-Draft CLUE Signaling December 2019 11.2. New SIP Media Feature Tag . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.1. Normative References . . . . . . . . . . . . . . . . . . 39 14.2. Informative References . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction To enable devices to participate in a telepresence call, selecting the sources they wish to view, receiving those media sources and displaying them in an optimal fashion, CLUE (ControLling mUltiple streams for tElepresence) employs two principal and inter-related protocol negotiations. SDP [RFC4566], conveyed via SIP [RFC3261], is used to negotiate the specific media capabilities that can be delivered to specific addresses on a device. Meanwhile, CLUE protocol [I-D.ietf-clue-protocol] messages, transported via a CLUE data channel [I-D.ietf-clue-datachannel], are used to negotiate the Capture Sources available, their attributes and any constraints in their use. They also allow the far end device to specify which Captures they wish to receive. It is recommended that those documents be read prior to this one as this document assumes familiarity with those protocols and hence uses terminology from each with limited introduction. Beyond negotiating the CLUE channel, SDP is also used to negotiate the details of supported media streams and the maximum capability of each of those streams. As the CLUE Framework [I-D.ietf-clue-framework] defines a manner in which the Media Provider expresses their maximum encoding group capabilities, SDP is also used to express the encoding limits for each potential Encoding. Backwards-compatibility is an important consideration of the protocol: it is vital that a CLUE-capable device contacting a device that does not support CLUE is able to fall back to a fully functional non-CLUE call. The document also defines how a non-CLUE call may be upgraded to CLUE in mid-call, and similarly how CLUE functionality can be removed mid-call to return to a standard non-CLUE call. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Hanton, et al. Expires June 11, 2020 [Page 3] Internet-Draft CLUE Signaling December 2019 This document uses terminology defined in the CLUE Framework [I-D.ietf-clue-framework]. A few additional terms specific to this document are defined as follows: non-CLUE device: A device that supports standard SIP and SDP, but either does not support CLUE, or that does but does not currently wish to invoke CLUE capabilities. CLUE-controlled media: A media "m=" line that is under CLUE control; the Capture Source that provides the media on this "m=" line is negotiated in CLUE. See Section 4 for details of how this control is signaled in SDP. There is a corresponding "non-CLUE- controlled" media term. 3. Media Feature Tag Definition The "sip.clue" media feature tag [RFC3840] indicates support for CLUE in SIP [RFC3261] calls. A CLUE-capable device SHOULD include this media feature tag in its REGISTER requests and OPTION responses. It SHOULD also include the media feature tag in INVITE and UPDATE [RFC3311] requests and responses. Presence of the media feature tag in the contact field of a request or response can be used to determine that the far end supports CLUE. 4. SDP Grouping Framework CLUE Extension Semantics 4.1. General This section defines a new SDP Grouping Framework [RFC5888] extension called 'CLUE'. The CLUE extension can be indicated using an SDP session-level 'group' attribute. Each SDP media "m=" line that is included in this group, using SDP media-level mid attributes, is CLUE-controlled, by a CLUE data channel also included in this CLUE group. Currently only support for a single CLUE group is specified; support for multiple CLUE groups in a single session is outside the scope of this document. A device MUST NOT include more than one CLUE group in its SDP message unless it is following a specification that defines how multiple CLUE channels are signaled, and is either able to determine that the other side of the SDP exchange supports multiple CLUE channels, or is able to fail gracefully in the event it does not. Hanton, et al. Expires June 11, 2020 [Page 4] Internet-Draft CLUE Signaling December 2019 4.2. The CLUE data channel and the CLUE grouping semantic The CLUE data channel [I-D.ietf-clue-datachannel] is a bidirectional data channel [I-D.ietf-rtcweb-data-channel] used for the transport of CLUE messages, conveyed within an SCTP over DTLS connection. This channel must be established before CLUE protocol messages can be exchanged and CLUE-controlled media can be sent. The data channel is negotiated over SDP as described in [I-D.ietf-mmusic-data-channel-sdpneg]. A CLUE-capable device wishing to negotiate CLUE MUST also include a CLUE group in their SDP offer or answer and include the "mid" of the "m=" line for the data channel in that group. The CLUE group MUST include the "mid" of the "m=" line for one (and only one) data channel. Presence of the data channel in the CLUE group in an SDP offer or answer also serves, along with the "sip.clue" media feature tag, as an indication that the device supports CLUE and wishes to upgrade the call to include CLUE-controlled media. A CLUE-capable device SHOULD include a data channel "m=" line in offers and, when allowed by [RFC3264], answers. 4.3. CLUE-controlled media and the CLUE grouping semantic CLUE-controlled media lines in an SDP are "m=" lines in which the content of the media streams to be sent is negotiated via the CLUE protocol [I-D.ietf-clue-protocol]. For an "m=" line to be CLUE- controlled, its "mid" value MUST be included in the CLUE group. CLUE-controlled media is controlled by the CLUE protocol as negotiated on the CLUE data channel with an "mid" included in the CLUE group. "m=" lines not specified as under CLUE control follow normal rules for media streams negotiated in SDP as defined in documents such as [RFC3264]. The restrictions on CLUE-controlled media that are defined below always apply to "m=" lines in an SDP offer or answer, even if negotiation of the data channel in SDP failed due to lack of CLUE support by the remote device or for any other reason, or in an offer if the recipient does not include the "mid" of the corresponding "m=" line in their CLUE group. 4.4. SDP semantics for CLUE-controlled media Hanton, et al. Expires June 11, 2020 [Page 5] Internet-Draft CLUE Signaling December 2019 4.4.1. Signaling CLUE Encodings The CLUE Framework [I-D.ietf-clue-framework] defines the concept of "Encodings", which represent the sender's encode ability. Each Encoding the Media Provider wishes to signal is signaled via an "m=" line of the appropriate media type, which MUST be marked as sendonly with the "a=sendonly" attribute or as inactive with the "a=inactive" attribute. The encoder limits of active (eg, "a=sendonly") Encodings can then be expressed using existing SDP syntax. For instance, for H.264 see Table 6 in [RFC6184] for a list of valid parameters for representing encoder sender stream limits. These Encodings are CLUE-controlled and hence MUST include an "mid" in the CLUE group as defined above. As well as the normal restrictions defined in [RFC3264] the stream MUST be treated as if the "m=" line direction attribute had been set to "a=inactive" until the Media Provider has received a valid CLUE 'configure' message specifying the Capture to be used for this stream. This means that RTP packets MUST NOT be sent until configuration is complete, while non-media packets such as STUN, RTCP and DTLS MUST be sent as per their relevant specifications if negotiated. Every "m=" line representing a CLUE Encoding MUST contain a "label" attribute as defined in [RFC4574]. This label is used to identify the Encoding by the sender in CLUE 'advertisement' messages and by the receiver in CLUE 'configure' messages. Each label used for a CLUE-controlled "m=" line MUST be different from the label on all other "m=" lines in the CLUE group, unless an "m=" line represents a dependent stream related to another "m=" line (such as an FEC stream), in which case it MUST have the same label value as the "m=" line on which it depends. 4.4.1.1. Referencing Encodings in the CLUE protocol CLUE Encodings are defined in SDP, but can be referenced from CLUE protocol messages - this is how the protocol defines which Encodings are part of an Encoding Group (in 'advertisement' messages) and which Encoding with which to encode a specific Capture (in 'configure' messages). The labels on the CLUE-controlled "m=" lines are the references that are used in the CLUE protocol. Each (in encodingIDList) in a CLUE 'advertisement' message SHOULD represent an Encoding defined in SDP; the specific Encoding referenced is a CLUE-controlled "m=" line in the most recent SDP Hanton, et al. Expires June 11, 2020 [Page 6] Internet-Draft CLUE Signaling December 2019 Offer/Answer message sent by the sender of the 'advertisement' message with a label value corresponding to the text content of the . If the is not defined in SDP it MUST be one it anticipates sending in a subsequent SDP Offer/Answer exchange. Each (in captureEncodingType) in a CLUE 'configure' message MUST represent an Encoding defined in SDP; the specific Encoding referenced is a CLUE-controlled "m=" line in the most recent SDP Offer/Answer message received by the sender of the 'configure' message with a label value corresponding to the text content of the . Note that the non-atomic nature of SDP/CLUE protocol interaction may mean that there are temporary periods where an / in a CLUE message does not reference an SDP "m=" line, or where an Encoding represented in SDP is not referenced in a CLUE protocol message. See Section 5 for specifics. 4.4.2. Negotiating receipt of CLUE Capture Encodings in SDP A receiver who wishes to receive a CLUE stream via a specific Encoding requires an "a=recvonly" "m=" line that matches the "a=sendonly" Encoding. These "m=" lines are CLUE-controlled and hence MUST include their "mid" in the CLUE group. They MAY include a "label" attribute, but this is not required by CLUE, as only label values associated with "a=sendonly" Encodings are referenced by CLUE protocol messages. 4.5. SDP Offer/Answer Procedures 4.5.1. Generating the Initial Offer A CLUE-capable device sending an initial SDP offer of a SIP session and wishing to negotiate CLUE will include an "m=" line for the data channel to convey the CLUE protocol, along with a CLUE group containing the "mid" of the data channel "m=" line. For interoperability with non-CLUE devices a CLUE-capable device sending an initial SDP offer SHOULD NOT include any "m=" line for CLUE-controlled media beyond the "m=" line for the CLUE data channel, and SHOULD include at least one non-CLUE-controlled media "m=" line. If the device has evidence that the receiver is also CLUE-capable, for instance due to receiving an initial INVITE with no SDP but including a "sip.clue" media feature tag, the above recommendation is waived, and the initial offer MAY contain "m=" lines for CLUE- controlled media. Hanton, et al. Expires June 11, 2020 [Page 7] Internet-Draft CLUE Signaling December 2019 With the same interoperability recommendations as for Encodings, the sender of the initial SDP offer MAY also include "a=recvonly" media lines to preallocate "m=" lines to receive media. Alternatively, it MAY wait until CLUE protocol negotiation has completed before including these lines in a new offer/answer exchange - see Section 5 for recommendations. 4.5.2. Generating the Answer 4.5.2.1. Negotiating use of CLUE and the CLUE data channel If the recipient of an initial offer is CLUE-capable, and the offer contains both an "m=" line for a data channel and a CLUE group containing the "mid" for that "m=" line, they SHOULD negotiate data channel support for an "m=" line, and include the "mid" of that "m=" line in a corresponding CLUE group. A CLUE-capable recipient that receives an "m=" line for a data channel but no corresponding CLUE group containing the "mid" of that "m=" line MAY still include a corresponding data channel "m=" line if there are any other non-CLUE protocols it can convey over that channel, but MUST NOT negotiate use of the CLUE protocol on this channel. 4.5.2.2. Negotiating CLUE-controlled media If the initial offer contained "a=recvonly" CLUE-controlled media lines the recipient SHOULD include corresponding "a=sendonly" CLUE- controlled media lines for accepted Encodings, up to the maximum number of Encodings it wishes to advertise. As CLUE-controlled media, the "mid" of these "m=" lines MUST be included in the corresponding CLUE group. The recipient MUST set the direction of the corresponding "m=" lines of any remaining "a=recvonly" CLUE- controlled media lines received in the offer to "a=inactive". If the initial offer contained "a=sendonly" CLUE-controlled media lines the recipient MAY include corresponding "a=recvonly" CLUE- controlled media lines, up to the maximum number of Capture Encodings it wishes to receive. Alternatively, it MAY wait until CLUE protocol negotiation has completed before including these lines in a new offer/answer exchange - see Section 5 for recommendations. The recipient MUST set the direction of the corresponding "m=" lines of any remaining "a=sendonly" CLUE-controlled media lines received in the offer to "a=inactive" Hanton, et al. Expires June 11, 2020 [Page 8] Internet-Draft CLUE Signaling December 2019 4.5.2.3. Negotiating non-CLUE controlled media A CLUE-controlled device implementation MAY prefer to render initial, single-stream audio and/or video for the user as rapidly as possible, transitioning to CLUE-controlled media once that has been negotiated. Alternatively, an implementation MAY wish to suppress initial media, only providing media once the final, CLUE-controlled streams have been negotiated. The receiver of the initial offer, if making the call CLUE-enabled with their SDP answer, can make their preference clear by their action in accepting or rejecting non-CLUE-controlled media lines. Rejecting these "m=" lines will ensure that no non-CLUE-controlled media flows before the CLUE-controlled media is negotiated. In contrast, accepting one or more non-CLUE-controlled "m=" lines in this initial answer will enable initial media to flow. If the answerer chooses to send initial non-CLUE-controlled media in a CLUE-enabled call, Section 4.5.4.1 addresses the need to disable it once CLUE-controlled media is fully negotiated. 4.5.3. Processing the initial Offer/Answer negotiation In the event that both offer and answer include a data channel "m=" line with a mid value included in corresponding CLUE groups, CLUE has been successfully negotiated and the call is now CLUE-enabled. If not then the call is not CLUE-enabled. 4.5.3.1. Successful CLUE negotiation In the event of successful CLUE-enablement of the call, devices MUST now begin negotiation of the CLUE channel, see [I-D.ietf-clue-datachannel] for negotiation details. If negotiation is successful, sending of CLUE protocol [I-D.ietf-clue-protocol] messages can begin. A CLUE-capable device MAY choose not to send RTP on the non-CLUE- controlled channels during the period in which control of the CLUE- controlled media lines is being negotiated (though RTCP MUST still be sent and received as normal). However, a CLUE-capable device MUST still be prepared to receive media on non-CLUE-controlled media lines that have been successfully negotiated as defined in [RFC3264]. If either side of the call wishes to add additional CLUE-controlled "m=" lines to send or receive CLUE-controlled media they MAY now send a SIP request with a new SDP offer following the normal rules of SDP offer/answer and any negotiated extensions. Hanton, et al. Expires June 11, 2020 [Page 9] Internet-Draft CLUE Signaling December 2019 4.5.3.2. CLUE negotiation failure In the event that the negotiation of CLUE fails and the call is not CLUE-enabled once the initial offer/answer negotiation completes then CLUE is not in use in the call. The CLUE-capable devices MUST either revert to non-CLUE behaviour or terminate the call. 4.5.4. Modifying the session 4.5.4.1. Adding and removing CLUE-controlled media Subsequent offer/answer exchanges MAY add additional "m=" lines for CLUE-controlled media, or activate or deactivate existing "m=" lines per the standard SDP mechanisms. In most cases at least one additional exchange after the initial offer/answer exchange will be required before both sides have added all the Encodings and ability to receive Encodings that they desire. Devices MAY delay adding "a=recvonly" CLUE-controlled "m=" lines until after CLUE protocol negotiation completes - see Section 5 for recommendations. Once CLUE media has been successfully negotiated devices SHOULD ensure that non-CLUE-controlled media is deactivated by setting their ports to 0 in cases where it corresponds to the media type of CLUE- controlled media that has been successfully negotiated. This deactivation may require an additional SDP exchange, or may be incorporated into one that is part of the CLUE negotiation. 4.5.4.2. Enabling CLUE mid-call A CLUE-capable device that receives an initial SDP offer from a non- CLUE device SHOULD include a new data channel "m=" line and corresponding CLUE group in any subsequent offers it sends, to indicate that it is CLUE-capable. If, in an ongoing non-CLUE call, an SDP offer/answer exchange completes with both sides having included a data channel "m=" line in their SDP and with the "mid" for that channel in a corresponding CLUE group then the call is now CLUE-enabled; negotiation of the data channel and subsequently the CLUE protocol begins. 4.5.4.3. Disabling CLUE mid-call If, during an ongoing CLUE-enabled call a device wishes to disable CLUE, it can do so by following the procedures for closing a data channel defined in Section 5.2.4 of [I-D.ietf-mmusic-data-channel-sdpneg]: sending a new SDP offer/answer Hanton, et al. Expires June 11, 2020 [Page 10] Internet-Draft CLUE Signaling December 2019 exchange and subsequent SCTP SSN reset for the CLUE channel. It MUST also remove the CLUE group. Without the CLUE group any "m=" lines that were previously CLUE-controlled no longer are; implementations MAY disable them by setting their ports to 0 or MAY continue to use them - in the latter case how they are used is outside the scope of this document. If a device follows the procedure above, or an SDP offer-answer negotiation completes in a fashion in which either the "m=" CLUE data channel line was not successfully negotiated, and/or one side did not include the data channel in the CLUE group then CLUE for this call is disabled. In the event that this occurs, CLUE is no longer enabled. Any active "m=" lines still included in the CLUE group are no longer CLUE-controlled and the implementation MAY either disable them in a subsequent negotiation or continue to use them in some other fashion. If the data channel is still present but not included in the CLUE group semantic CLUE protocol messages MUST no longer be sent. 4.5.4.4. CLUE protocol failure mid-call In contrast to the specific disablement of the use of CLUE described above, the CLUE channel may fail unexpectedly. Two circumstances where this can occur are: o The CLUE data channel terminates, either gracefully or ungracefully, without any corresponding SDP renegotiation. o A channel error of the CLUE protocol causes it to return to the IDLE state as defined in Section 6. of [I-D.ietf-clue-protocol]. In this circumstance implementations SHOULD continue to transmit and receive CLUE-controlled media on the basis of the last negotiated CLUE messages, until the CLUE protocol is re-established (in the event of a channel error) or disabled mid-call by an SDP exchange as defined in Section 4.5.4.3. Implementations MAY choose to send such an SDP request to disable CLUE immediately or MAY continue on in a call-preservation mode. 5. Interaction of CLUE protocol and SDP negotiations Information about media streams in CLUE is split between two message types: SDP, which defines media addresses and limits, and the CLUE channel, which defines properties of Capture Devices available, scene information and additional constraints. As a result certain operations, such as advertising support for a new transmissible Capture with associated stream, cannot be performed atomically, as they require changes to both SDP and CLUE messaging. Hanton, et al. Expires June 11, 2020 [Page 11] Internet-Draft CLUE Signaling December 2019 This section defines how the negotiation of the two protocols interact, provides some recommendations on dealing with intermediate stages in non-atomic operations, and mandates additional constraints on when CLUE-configured media can be sent. 5.1. Independence of SDP and CLUE negotiation To avoid the need to implement interlocking state machines with the potential to reach invalid states if messages were to be lost, or be rewritten en-route by middle boxes, the state machines in SDP and CLUE operate independently. The state of the CLUE channel does not restrict when an implementation may send a new SDP offer or answer, and likewise the implementation's ability to send a new CLUE 'advertisement' or 'configure' message is not restricted by the results of or the state of the most recent SDP negotiation (unless the SDP negotiation has removed the CLUE channel). The primary implication of this is that a device may receive an SDP Offer/Answer message with a CLUE Encoding for which it does not yet have Capture information, or receive a CLUE 'configure' message specifying a Capture Encoding for which the far end has not negotiated a media stream in SDP. CLUE messages contain an (in encodingIDList) or (in captureEncodingType), which is used to identify a specific encoding or captureEncoding in SDP; see [I-D.ietf-clue-data-model-schema] for specifics. The non-atomic nature of CLUE negotiation means that a sender may wish to send a new CLUE 'advertisement' message before the corresponding SDP message. As such the sender of the CLUE message MAY include an which does not currently match a CLUE-controlled "m=" line label in SDP; A CLUE-capable implementation MUST NOT reject a CLUE protocol message solely because it contains elements that do not match a label in SDP. The current state of the CLUE participant or Media Provider/Consumer state machines do not affect compliance with any of the normative language of [RFC3264]. That is, they MUST NOT delay an ongoing SDP exchange as part of a SIP server or client transaction; an implementation MUST NOT delay an SDP exchange while waiting for CLUE negotiation to complete or for a 'configure' message to arrive. Similarly, a device in a CLUE-enabled call MUST NOT delay any mandatory state transitions in the CLUE Participant or Media Provider/Consumer state machines due to the presence or absence of an ongoing SDP exchange. Hanton, et al. Expires June 11, 2020 [Page 12] Internet-Draft CLUE Signaling December 2019 A device with the CLUE Participant state machine in the ACTIVE state MAY choose to delay moving from ESTABLISHED to ADV (Media Provider state machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media Consumer state machine) based on the SDP state. See [I-D.ietf-clue-protocol] for CLUE state machine specifics. Similarly, a device MAY choose to delay initiating a new SDP exchange based on the state of their CLUE state machines. 5.2. Constraints on sending media While SDP and CLUE message states do not impose constraints on each other, both impose constraints on the sending of media - CLUE- controlled media MUST NOT be sent unless it has been negotiated in both CLUE and SDP: an implementation MUST NOT send a specific CLUE Capture Encoding unless its most recent SDP exchange contains an active media channel for that Encoding AND it has received a CLUE 'configure' message specifying a valid Capture for that Encoding. 5.3. Recommendations for operating with non-atomic operations CLUE-capable devices MUST be able to handle states in which CLUE messages make reference to EncodingIDs that do not match the most recently received SDP, irrespective of the order in which SDP and CLUE messages are received. While these mismatches will usually be transitory a device MUST be able to cope with such mismatches remaining indefinitely. However, this document makes some recommendations on message ordering for these non-atomic transitions. CLUE-capable devices MUST ensure that any inconsistencies between SDP and CLUE signaling are temporary by sending updated SDP or CLUE messages as soon as the relevant state machines and other constraints permit. Generally, implementations that receive messages for which they have incomplete information will be most efficient if they wait until they have the corresponding information they lack before sending messages to make changes related to that information. For example, an answerer that receives a new SDP offer with three new "a=sendonly" CLUE "m=" lines for which it has received no CLUE 'advertisement' message providing the corresponding capture information would typically inclue corresponding "a=inactive" lines in its answer, and only make a new SDP offer with "a=recvonly" when and if a new 'advertisement' message arrives with Captures relevant to those Encodings. Because of the constraints of SDP offer/answer and because new SDP negotiations are generally more 'costly' than sending a new CLUE message, implementations needing to make changes to both channels Hanton, et al. Expires June 11, 2020 [Page 13] Internet-Draft CLUE Signaling December 2019 SHOULD prioritize sending the updated CLUE message over sending the new SDP message. The aim is for the recipient to receive the CLUE changes before the SDP changes, allowing the recipient to send their SDP answers without incomplete information, reducing the number of new SDP offers required. 6. Interaction of CLUE protocol and RTP/RTCP CaptureID The CLUE Framework [I-D.ietf-clue-framework] allows for Multiple Content Captures (MCCs): Captures which contain multiple source Captures, whether composited into a single stream or switched based on some metric. The Captures that contribute to these MCCs may or may not be defined in the 'advertisement' message. If they are defined and the MCC is providing them in a switched format the recipient may wish to determine which originating source Capture is currently being provided, so that they can apply geometric corrections based on that Capture's geometry, or take some other action based on the original Capture information. To do this, [I-D.ietf-clue-rtp-mapping] allows for the CaptureID of the originating Capture to be conveyed via RTP or RTCP. A Media Provider sending switched media for an MCC with defined originating sources MUST send the CaptureID in both RTP and RTCP, as described in the mapping document. 6.1. CaptureID reception during MCC redefinition Because the RTP/RTCP CaptureID is delivered via a different channel to the 'advertisement' message in which in the contents of the MCC are defined there is an intrinsic race condition in cases in which the contents of an MCC are redefined. When a Media Provider redefines an MCC which involves CaptureIDs, the reception of the relevant CaptureIDs by the recipient will either lead or lag reception and processing of the new 'advertisement' message by the recipient. As such, a Media Consumer MUST NOT be disrupted by any of the following in any CLUE-controlled media stream it is receiving, whether that stream is for a static Capture or for an MCC (as any static Capture may be redefined to an MCC in a later 'advertisement' message): o Receiving RTP or RTCP containing a CaptureID when the most recently processed 'advertisement' message means that none are expected. Hanton, et al. Expires June 11, 2020 [Page 14] Internet-Draft CLUE Signaling December 2019 o Receiving RTP or RTCP without CaptureIDs when the most recently processed 'advertisement' message means that media CaptureIDs are expected. o Receiving a CaptureID in RTP or RTCP for a Capture defined in the most recently processed 'advertisement' message, but which the same 'advertisement' message does not include in the MCC. o Receiving a CaptureID in RTP or RTCP for a Capture not defined in the most recently processed 'advertisement' message. 7. Multiplexing of CLUE-controlled media using BUNDLE 7.1. Overview A CLUE call may involve sending and/or receiving significant numbers of media streams. Conventionally, media streams are sent and received on unique ports. However, each separate port used for this purpose may impose costs that a device wishes to avoid, such as the need to open that port on firewalls and NATs, the need to collect ICE candidates [RFC8445], etc. The BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] extension can be used to negotiate the multiplexing of multiple media lines onto a single 5-tuple for sending and receiving media, allowing devices in calls to another BUNDLE-supporting device to potentially avoid some of the above costs. While CLUE-capable devices MAY support the BUNDLE extension for this purpose supporting the extension is not mandatory for a device to be CLUE-compliant. A CLUE-capable device that supports BUNDLE SHOULD also support rtcp- mux [RFC5761]. However, a CLUE-capable device that supports rtcp-mux may or may not support BUNDLE. 7.2. Usage of BUNDLE with CLUE This specification imposes no additional requirements or restrictions on the usage of BUNDLE when used with CLUE. There is no restriction on combining CLUE-controlled media lines and non-CLUE-controlled media lines in the same BUNDLE group or in multiple such groups. However, there are several steps an implementation may wish to take to ameliorate the cost and time requirements of extra SDP offer/ answer exchanges between CLUE and BUNDLE. Hanton, et al. Expires June 11, 2020 [Page 15] Internet-Draft CLUE Signaling December 2019 7.2.1. Generating the Initial Offer BUNDLE mandates that the initial SDP offer MUST use a unique address for each "m=" line with a non-zero port. Because CLUE implementations generally will not include CLUE-controlled media lines with the exception of the data channel in the initial SDP offer, CLUE devices that support large numbers of streams can avoid ever having to open large numbers of ports if they successfully negotiate BUNDLE. An implementation that does include CLUE-controlled media lines in its initial SDP offer while also using BUNDLE must take care to avoid renderings its CLUE-controlled media lines unusable in the event the far end does not negotiate BUNDLE if it wishes to avoid the risk of additional SDP exchanges to resolve this issue. This is best achieved by not sending any CLUE-controlled media lines in an initial offer with the 'bundle-only' attribute unless it has been established via some other channel that the recipient supports and is able to use BUNDLE. 7.2.2. Multiplexing of the data channel and RTP media BUNDLE-supporting CLUE-capable devices MAY include the data channel in the same BUNDLE group as RTP media. In this case the device MUST be able to demultiplex the various transports - see section 9.2 of the BUNDLE draft [I-D.ietf-mmusic-sdp-bundle-negotiation]. If the BUNDLE group includes other protocols than the data channel transported via DTLS the device MUST also be able to differentiate the various protocols. 8. Example: A call between two CLUE-capable Endpoints This example illustrates a call between two CLUE-capable Endpoints. Alice, initiating the call, is a system with three cameras and three screens. Bob, receiving the call, is a system with two cameras and two screens. A call-flow diagram is presented, followed by a summary of each message. To manage the size of this section the SDP snippets only illustrate video "m=" lines. SIP ACKs are not always discussed. Note that BUNDLE is not in use. Hanton, et al. Expires June 11, 2020 [Page 16] Internet-Draft CLUE Signaling December 2019 +----------+ +-----------+ | Alice | | Bob | | | | | +----+-----+ +-----+-----+ | | | | | SIP INVITE 1 | |--------------------------------->| | | | | | SIP 200 OK 1 | |<---------------------------------| | | | | | SIP ACK 1 | |--------------------------------->| | | | | | | |<########### MEDIA 1 ############>| | 1 video A->B, 1 video B->A | |<################################>| | | | | | | |<================================>| | CLUE DATA CHANNEL ESTABLISHED | |<================================>| | | | | | CLUE OPTIONS | |<*********************************| | | | | | CLUE OPTIONS RESPONSE | |*********************************>| | | | | | CLUE ADVERTISEMENT 1 | |*********************************>| | | | | | CLUE ADVERTISEMENT 2 | |<*********************************| | | | | | CLUE ACK 1 | |<*********************************| Hanton, et al. Expires June 11, 2020 [Page 17] Internet-Draft CLUE Signaling December 2019 | | | | | CLUE ACK 2 | |*********************************>| | | | | | SIP INVITE 2 (+3 sendonly) | |--------------------------------->| | | | | | CLUE CONFIGURE 1 | |<*********************************| | | | | | SIP 200 OK 2 (+2 recvonly) | |<---------------------------------| | | | | | CLUE CONFIGURE RESPONSE 1 | |*********************************>| | | | | | SIP ACK 2 | |--------------------------------->| | | | | | | |<########### MEDIA 2 ############>| | 2 video A->B, 1 video B->A | |<################################>| | | | | | SIP INVITE 3 (+2 sendonly) | |<---------------------------------| | | | | | CLUE CONFIGURE 2 | |*********************************>| | | | | | SIP 200 OK 3 (+2 recvonly) | |--------------------------------->| | | | | | CLUE CONFIGURE RESPONSE 2 | |<*********************************| | | | | Hanton, et al. Expires June 11, 2020 [Page 18] Internet-Draft CLUE Signaling December 2019 | SIP ACK 3 | |<---------------------------------| | | | | | | |<########### MEDIA 3 ############>| | 2 video A->B, 2 video B->A | |<################################>| | | | | | | v v In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body the basic audio and video capabilities and the data channel as per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" media feature tag in the INVITE. A snippet of the SDP showing the grouping attribute and the video "m=" line are shown below. Alice has included a "CLUE" group, and included the mid corresponding to a data channel in the group (3). Note that Alice has chosen not to include any CLUE-controlled media in the initial offer - the mid value of the video line is not included in the "CLUE" group. ... a=group:CLUE 3 ... m=video 6002 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=sendrecv a=mid:2 ... m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=setup:actpass a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE";ordered=true a=mid:3 Bob responds with a similar SDP in SIP 200 OK 1, which also has a "CLUE" group including the mid value of a data channel; due to their similarity no SDP snippet is shown here. Bob wishes to receive initial media, and so includes corresponding non-CLUE-controlled audio and video lines. Bob also includes the "sip.clue" media feature tag in the 200 OK. Alice and Bob are each now able to send a single audio and video stream. This is illustrated as MEDIA 1. Hanton, et al. Expires June 11, 2020 [Page 19] Internet-Draft CLUE Signaling December 2019 With the successful initial SDP Offer/Answer exchange complete Alice and Bob are also free to negotiate the CLUE data channel. This is illustrated as CLUE DATA CHANNEL ESTABLISHED. Once the data channel is established CLUE protocol negotiation begins. In this case Bob was the DTLS client (sending a=active in his SDP answer) and hence is the CLUE Channel Initiator and sends a CLUE OPTIONS message describing his version support. On receiving that message Alice sends her corresponding CLUE OPTIONS RESPONSE. With the OPTIONS phase complete Alice now sends her CLUE 'advertisement' message (CLUE ADVERTISEMENT 1). She advertises three static Captures representing her three cameras. She also includes switched Captures suitable for two- and one-screen systems. All of these Captures are in a single Capture Scene, with suitable Capture Scene Views to tell Bob that he should either subscribe to the three static Captures, the two switched Captures or the one switched Capture. Alice has no simultaneity constraints, so includes all six Captures in one simultaneous set. Finally, Alice includes an Encoding Group with three Encoding IDs: "enc1", "enc2" and "enc3". These Encoding IDs aren't currently valid, but will match the next SDP offer she sends. Bob received CLUE ADVERTISEMENT 1 but does not yet send a 'configure' message, because he has not yet received Alice's Encoding information, so as yet he does not know if she will have sufficient resources to send him the two streams he ideally wants at a quality he is happy with. Because Bob is not sending an immediate 'configure' message with the "ack" element set he must send an explicit 'ack' message (CLUE ACK 1) to signal receipt of CLUE ADVERTISEMENT 1. Bob also sends his CLUE 'advertisement' message (CLUE ADVERTISEMENT 2) - though the diagram shows that this occurs after Alice sends CLUE ADVERTISEMENT 1 Bob sends his 'advertisement' message independently and does not wait for CLUE ADVERTISEMENT 1 to arrive. He advertises two static Captures representing his cameras. He also includes a single composed Capture for single-screen systems, in which he will composite the two camera views into a single video stream. All three Captures are in a single Capture Scene, with suitable Capture Scene Views to tell Alice that she should either subscribe to the two static Captures, or the single composed Capture. Bob also has no simultaneity constraints, so includes all three Captures in one simultaneous set. Bob also includes a single Encoding Group with two Encoding IDs: "foo" and "bar". Hanton, et al. Expires June 11, 2020 [Page 20] Internet-Draft CLUE Signaling December 2019 Similarly, Alice receives CLUE ADVERTISEMENT 2 but does not yet send a 'configure' message, because she has not yet received Bob's Encoding information, sending instead an 'ack' message (CLUE ACK 2). Both sides have now sent their CLUE 'advertisement' messages and an SDP exchange is required to negotiate Encodings. For simplicity, in this case Alice is shown sending an INVITE with a new offer; in many implementations both sides might send an INVITE, which would be resolved by use of the 491 Request Pending resolution mechanism from [RFC3261]. Alice now sends SIP INVITE 2. She maintains the sendrecv audio, video and CLUE "m=" lines, and she adds three new sendonly "m=" lines to represent the three CLUE-controlled Encodings she can send. Each of these "m=" lines has a label corresponding to one of the Encoding IDs from CLUE ADVERTISEMENT 1. Each also has its mid added to the grouping attribute to show they are controlled by the CLUE data channel. A snippet of the SDP showing the grouping attribute, data channel and the video "m=" lines are shown below: Hanton, et al. Expires June 11, 2020 [Page 21] Internet-Draft CLUE Signaling December 2019 ... a=group:CLUE 3 4 5 6 ... m=video 6002 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=sendrecv a=mid:2 ... m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE";ordered=true a=mid:3 ... m=video 6004 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=mid:4 a=label:enc1 m=video 6006 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=mid:5 a=label:enc2 m=video 6008 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=mid:6 a=label:enc3 Bob now has all the information he needs to decide which streams to configure, allowing him to send both a CLUE 'configure' message and his SDP answer. As such he now sends CLUE CONFIGURE 1. This requests the pair of switched Captures that represent Alice's scene, and he configures them with encoder ids "enc1" and "enc2". Bob also sends his SDP answer as part of SIP 200 OK 2. Alongside his original audio, video and CLUE "m=" lines he includes three additional "m=" lines corresponding to the three added by Alice; two active recvonly "m= "lines and an inactive "m=" line for the third. He adds their mid values to the grouping attribute to show they are controlled by the CLUE data channel. A snippet of the SDP showing the grouping attribute and the video "m=" lines are shown below (mid 100 represents the CLUE data channel, not shown): Hanton, et al. Expires June 11, 2020 [Page 22] Internet-Draft CLUE Signaling December 2019 ... a=group:CLUE 11 12 13 100 ... m=video 58722 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=sendrecv a=mid:10 ... m=video 58724 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=recvonly a=mid:11 m=video 58726 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=recvonly a=mid:12 m=video 58728 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=inactive a=mid:13 Alice receives Bob's message CLUE CONFIGURE 1 and sends CLUE CONFIGURE RESPONSE 1 to ack its reception. She does not yet send the Capture Encodings specified, because at this stage she hasn't processed Bob's answer SDP and so hasn't negotiated the ability for Bob to receive these streams. On receiving SIP 200 OK 2 from Bob Alice sends her SIP ACK (SIP ACK 2). She is now able to send the two streams of video Bob requested - this is illustrated as MEDIA 2. The constraints of offer/answer meant that Bob could not include his encoding information as new "m=" lines in SIP 200 OK 2. As such Bob now sends SIP INVITE 3 to generate a new offer. Along with all the streams from SIP 200 OK 2 Bob also includes two new sendonly streams. Each stream has a label corresponding to the Encoding IDs in his CLUE ADVERTISEMENT 2 message. He also adds their mid values to the grouping attribute to show they are controlled by the CLUE data channel. A snippet of the SDP showing the grouping attribute and the video "m=" lines are shown below (mid 100 represents the CLUE data channel, not shown): Hanton, et al. Expires June 11, 2020 [Page 23] Internet-Draft CLUE Signaling December 2019 ... a=group:CLUE 11 12 14 15 100 ... m=video 58722 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=sendrecv a=mid:10 ... m=video 58724 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=recvonly a=mid:11 m=video 58726 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=recvonly a=mid:12 m=video 0 RTP/AVP 96 a=mid:13 m=video 58728 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=label:foo a=mid:14 m=video 58730 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=label:bar a=mid:15 Having received this, Alice now has all the information she needs to send her CLUE 'configure' message and her SDP answer. In CLUE CONFIGURE 2 she requests the two static Captures from Bob, to be sent on Encodings "foo" and "bar". Alice also sends SIP 200 OK 3, matching two recvonly "m=" lines to Bob's new sendonly lines. She includes their mid values in the grouping attribute to show they are controlled by the CLUE cdata hannel. Alice also now deactivates the initial non-CLUE-controlled media, as bidirectional CLUE-controlled media is now available. A snippet of the SDP showing the grouping attribute and the video "m=" lines are shown below (mid 3 represents the data channel, not shown): Hanton, et al. Expires June 11, 2020 [Page 24] Internet-Draft CLUE Signaling December 2019 ... a=group:CLUE 3 4 5 7 8 ... m=video 0 RTP/AVP 96 a=mid:2 ... m=video 6004 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=mid:4 a=label:enc1 m=video 6006 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016 a=sendonly a=mid:5 a=label:enc2 m=video 0 RTP/AVP 96 a=mid:6 m=video 6010 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=recvonly a=mid:7 m=video 6012 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=recvonly a=mid:8 Bob receives Alice's message CLUE CONFIGURE 2 and sends CLUE CONFIGURE RESPONSE 2 to ack its reception. Bob does not yet send the Capture Encodings specified, because he hasn't yet received and processed Alice's SDP answer and negotiated the ability to send these streams. Finally, on receiving SIP 200 OK 3 Bob is now able to send the two streams of video Alice requested - this is illustrated as MEDIA 3. Both sides of the call are now sending multiple video streams with their sources defined via CLUE negotiation. As the call progresses either side can send new 'advertisement' or 'configure' message or new SDP offer/answers to add, remove or change what they have available or want to receive. Hanton, et al. Expires June 11, 2020 [Page 25] Internet-Draft CLUE Signaling December 2019 9. Example: A call between a CLUE-capable and non-CLUE Endpoint In this brief example Alice is a CLUE-capable Endpoint making a call to Bob, who is not CLUE-capable (i.e. is not able to use the CLUE protocol). +----------+ +-----------+ | Alice | | Bob | | | | | +----+-----+ +-----+-----+ | | | | | SIP INVITE 1 | |--------------------------------->| | | | | | 200 0K 1 | |<---------------------------------| | | | | | SIP ACK 1 | |--------------------------------->| | | | | | | |<########### MEDIA 1 ############>| | 1 video A->B, 1 video B->A | |<################################>| | | | | | | | | v v In SIP INVITE 1, Alice sends Bob a SIP INVITE including in the SDP body the basic audio and video capabilities and the data channel as per [I-D.ietf-mmusic-sctp-sdp]. Alice also includes the "sip.clue" media feature tag in the INVITE. A snippet of the SDP showing the grouping attribute and the video "m=" line are shown below. Alice has included a "CLUE" group, and included the mid corresponding to a data channel in the group (3). Note that Alice has chosen not to include any CLUE-controlled media in the initial offer - the mid value of the video line is not included in the "CLUE" group. Hanton, et al. Expires June 11, 2020 [Page 26] Internet-Draft CLUE Signaling December 2019 ... a=group:CLUE 3 ... m=video 6002 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=sendrecv a=mid:2 ... m=application 6100 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE";ordered=true a=mid:3 Bob is not CLUE-capable, and hence does not recognize the "CLUE" semantic for grouping attribute, nor does he support the data channel. IN SIP 200 OK 1 he responds with an answer with audio and video, but with the data channel zeroed. From the lack of a CLUE group Alice understands that Bob does not support CLUE, or does not wish to use it. Both sides are now able to send a single audio and video stream to each other. Alice at this point begins to send her fallback video: in this case likely a switched view from whichever camera shows the current loudest participant on her side. 10. Acknowledgements Besides the authors, the team focusing on this draft consists of: Roni Even, Simon Pietro-Romano, Roberta Presta. Christian Groves, Jonathan Lennox and Adam Roach have contributed detailed comments and suggestions. 11. IANA Considerations 11.1. New SDP Grouping Framework Attribute This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry per [RFC5888]: Hanton, et al. Expires June 11, 2020 [Page 27] Internet-Draft CLUE Signaling December 2019 Semantics Token Reference ------------------------------------- ------ --------- CLUE-controlled m-line CLUE [this draft] 11.2. New SIP Media Feature Tag This specification registers a new media feature tag in the SIP [RFC3261] tree per the procedures defined in [RFC2506] and [RFC3840]. Media feature tag name: sip.clue ASN.1 Identifier: [to be assigned] Summary of the media feature indicated by this tag: This feature tag indicates that the device supports CLUE-controlled media. Values appropriate for use with this feature tag: Boolean. The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is most useful in a communications application for describing the capabilities of a device to use the CLUE control protocol to negotiate the use of multiple media streams. Related standards or documents: [this draft] Security Considerations: Security considerations for this media feature tag are discussed in Section 12 of [this draft]. Name(s) & email address(es) of person(s) to contact for further information: o Internet Engineering Steering Group: iesg@ietf.org Intended usage: COMMON 12. Security Considerations CLUE makes use of a number of protocols and mechanisms, either defined by CLUE or long-standing. The security considerations section of the CLUE Framework [I-D.ietf-clue-framework] addresses the need to secure these mechanisms by following the recommendations of the individual protocols. Beyond the need to secure the constituent protocols, the use of CLUE does impose additional security concerns. One area of increased risk Hanton, et al. Expires June 11, 2020 [Page 28] Internet-Draft CLUE Signaling December 2019 involves the potential for a malicious party to subvert a CLUE- capable device to attack a third party by driving large volumes of media (particularly video) traffic at them by establishing a connection to the CLUE-capable device and directing the media to the victim. While this is a risk for all media devices, a CLUE-capable device may allow the attacker to configure multiple media streams to be sent, significantly increasing the volume of traffic directed at the victim. This attack can be prevented by ensuring that the media recipient intends to receive the media packets. As such all CLUE-capable devices MUST support key negotiation and receiver intent assurance via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines, and MUST use it or some other mechanism that provides receiver intent assurance. All CLUE-controlled RTP "m" lines must be secured and implemented using mechanisms such as SRTP [RFC3711]. CLUE implementations MAY choose not to require the use of SRTP to secure legacy (non-CLUE-controlled) media for backwards compatibility with older SIP clients that are incapable of supporting it. CLUE also defines a new media feature tag that indicates CLUE support. This tag may be present even in non-CLUE calls, which increases the metadata available about the sending device, which can help an attacker differentiate between multiple devices and help them identify otherwise anonymised users via the fingerprint of features their device supports. To prevent this, SIP signaling used to set up CLUE sessions SHOULD always be encrypted using TLS [RFC5630]. The CLUE protocol also carries additional information that could be used to help fingerprint a particular user or to identify the specific version of software being used. CLUE Framework [I-D.ietf-clue-protocol] provides details of these issues and how to mitigate them. 13. Change History Note to RFC Editor: please remove this section prior to publication -15: Revision by Rob Hanton * Clarified that using an 'EncID' defined in SDP in an CLUE ADVERTISEMENT message is only a SHOULD because of the inherent race conditions about the ordering of the SDP and CLUE message. In contrast, changed the use of 'EncID' in a CLUE CONFIGURE message to a MUST as that is defined by the far end and so there is no way for the sending of the CONFIGURE to anticipate it. Hanton, et al. Expires June 11, 2020 [Page 29] Internet-Draft CLUE Signaling December 2019 * Updated the description of handling the failure of the CLUE channel to reflect the fact that the protocol state machine now returns to the IDLE state on failure rather than a specific termination state, which also means defining an allowance for the CLUE channel being recovered. * Updated all instances of advertisment, configure and ack messages throughout to match the styling of the protocol document * Security section updated to make DTLs-SRTP mandatory to use as well as support unless intent assurance is provided by some other mechanism per mailing list proposal (to resolve the concern from a previous IETF session of those wanting to use CLUE in a closed environment where intent assurance was provided by other prorietary mechanisms). * Removed OID value for "sip.clue" media feature tag pending its actual assignment on registration, leaving a placeholder * All lower-case uses of 'must', 'should' and 'may' reviewed and a few made normative * Fixed various spelling mistakes, clarified grammar, and fixed a copy/paste error. * Updated boilerplate to RFC 8174 * Some informative references moved to normative. -14: Revision by Rob Hanton * Reference to RFC5245 updated to RFC8445 * Updated my name to reflect surname change (Hansen to Hanton). * Reviewed recent changes to clue protocol document and concluded that none affected this document * Added recommendation that the SDP O/A spec and clue protocol be read prior to this document * Several acronyms expanded at the point of initial use * Some unnecessary normative language replaced with prose -13: Revision by Rob Hansen Hanton, et al. Expires June 11, 2020 [Page 30] Internet-Draft CLUE Signaling December 2019 * Added a section on handling failures of the protocol channel or data channel mid-call - instructions are that media must continue as if the clue channel were still established and unchanged until CLUE is disabled by either side via SDP exchange. * Example in section on efficient operation with non-atomic transactions has had all normative language removed and is now entirely descriptive (normative language retained in the non- example portion). * draft-ietf-clue-protocol-14 reviewed for relevant changes, and use of CLUE ACK and RESPONSE messages made consistent with that document (ADVERTISEMENT ACKNOWLEDGEMENT and CONFIGURE RESPONSE respectively). * Order of authors revised to reflect updates since Jan 2014. -12: Revision by Rob Hansen * Title change to expand and elucidate our totally-not-contrived acronym * Explicit reference to RFC3840 added when first mentioning media feature tags * Have standardised references to Clue protocol messages to ADVERTISEMENT, CONFIGURE and ACK, in line with section 12.4.1. of the protocol document (though the protocol document also uses ADV and CONF). * 'MUST' in opening paragraph of 4.2 changed from normative 'MUST' to logical 'must' * Per his request, removed Cristian's company affiliation and changed his email address * Clarified that an implementation that chooses not to send media during the initial negotiation process must still send RTCP as normal * Rewrote the section on adding/remove clue m-lines after the initial exchange to make clear that this is just standard SDP. For non-clue controlled lines, recommended they are deactivated by zeroing the port when turning them off after clue is successfully negotiated. Hanton, et al. Expires June 11, 2020 [Page 31] Internet-Draft CLUE Signaling December 2019 * Added guidance that an initial offer containing clue-controlled m-lines MUST NOT set them bundle-only unless they somehow know the far end actually supports BUNDLE * Added section saying that CLUE devices that do BUNDLE SHOULD do rtcp-mux, but that the requirement doesn't exist in the other direction (eg, supporting rtcp-mux does not require or imply the need to implement BUNDLE) * For clue-controlled m-lines where the sender included more encodings than the recipient wants, have standardised on using "a=inactive" to not receive RTP on them (previously had a mix of "a=inactive" or port 0, or in some cases did not specify). * Page break added before the big ladder diagram in the example * Have added a direction attribute to the SDP example in the data channel, and made explicit that Bob is the DTLS client and hence the CLUE Channel Initiator. * Have removed all language that referenced the possibility of having multiple CLUE groups * Removed names appearing in the authors list from the acknowledgements * Changed the contact for the IANA registration to iesg@ietf.org * Security section updated to clarify that DTLS-SRTP must be supported (as opposed to DTLS) and removed the reference to RFC7202. * Other syntactic tweaks based on Paul and Adam's feedback -11: Revision by Rob Hansen * Some informative references added for SIP and SDP. * 'a=mid' lines added to example m-lines with port 0, per RFC5888 section 6. * Instace of 'must' changed to normative 'MUST', along with various minor clarifications and corrections. * Abstract made standalone without citations, per RFC7322 section 4.3. * RFC editor note added to remove this section. Hanton, et al. Expires June 11, 2020 [Page 32] Internet-Draft CLUE Signaling December 2019 -10: Revision by Rob Hansen * Changes to draft-ietf-clue-protocol between 07 and 11 reviewed to ensure compatibility between documents has been maintained. * Expanded the portion of the document related to fingerprinting with info on the CLUE channel as well as SIP. -09: Revision by Rob Hansen * A few minor spelling tweaks * Made removing the CLUE group mandatory when disabling CLUE mid- call. Made clear that any CLUE-controlled m-lines should be disabled or else how they're used is up to the implementation. -08: Revision by Rob Hansen * Spelling and grammar fixes from Paul and Christian gratefully adopted * Expanded the section on disabling CLUE mid-call to make explicit the actions required to disable the CLUE channel gracefully, or to handle someone else doing the same. * Made a number of fixes to the example call flow to better reflect the recommendations in the document. -07: Revision by Rob Hansen * Removed the entire 'Media line directionality' section as a discussion of the pros/cons of using bidirectional vs unidirectional schemes wasn't suitable for a finalised version. The unidirectionality requirement is covered normatively in an earlier section. * BUNDLE no longer includes an address synchronisation step so the suggestion to wait until that done has been replaced with some general language about following any negotiated extensions. * Added OPTIONS negotiation to the example flow, and revised the flow to ensure it matched protocol document. * Section on not sending CLUE control media until CLUE negotiation completes narrowed to notify that only RTP should not be sent until negotiation completes and add RTCP to the Hanton, et al. Expires June 11, 2020 [Page 33] Internet-Draft CLUE Signaling December 2019 list of things that should be sent as normal, in line with a=inactive. * Make explicit that m=recvonly lines don't need to have a label, as only m=sendonly lines are referenced by CLUE protocol messages. * Fix formatting of IANA sections. Improve syntax of feature tag section in line with Paul's suggestions. Definition of feature tag narrowed to be multiple media lines *negotiated via CLUE protocol* rather than more generic 'multiple media lines'. * General corrections to grammar, spelling and readability based on Christian, Paul and Mark; in many cases suggested text was gratefully accepted. -06: Revision by Rob Hansen * State machine interactions updated to match versions in -04 of protocol doc. * Section on encoding updated to specify both encID and encodingID from data model doc. * Removed the limitations on describing H264 encoding limits using SDP syntax as an open issue. * Previous draft had SRTP and DTLS mandatory to implement and to use on CLUE- controlled m lines. Current version has DTLS mandatory to implement, and 'security' mandatory to use but does not define what that security is. * Terminology reference to framework doc reinforced. All terminology that duplicates framework removed. All text updated with capitalisation that matches framework document's terminology. * SDP example syntax updated to match that of ietf-clue- datachannel and hence ietf-mmusic-data-channel-sdpneg. -05: Revision by Rob Hansen * SRTP/DTLS made mandatory for CLUE-controlled media lines. * IANA consideration section added (text as proposed by Christian Groves). Hanton, et al. Expires June 11, 2020 [Page 34] Internet-Draft CLUE Signaling December 2019 * Includes provision for dependent streams on seperate "m" lines having the same encID as their parent "m" line. * References to putting CLUE-controlled media and data channels in more than one CLUE group removed, since the document no longer supports using more than one CLUE group. * Section on CLUE controlled media restrictions still applying even if the call does not end up being CLUE enabled being rewritten to hopefully be clearer. * Other minor syntax improvements. -04: Revision by Rob Hansen * Updated DTLS/SCTP channel syntax in examples to fix errors and match latest format defined in draft-ietf-mmusic-sctp-sdp-07. * Clarified the behaviour if an SDP offer includes a CLUE- controlled "m" line and the answer accepts that "m" line but without CLUE control of that line. * Added a new section on the sending and receiving of CaptureIDs in RTP and RTCP. Includes a section on the necessity of the receiver coping with unexpected CaptureIDs (or the lack thereof) due to MCCs being redefined in new Advertisement messages. * Added reminder on IANA section on registering grouping semantic and media feature tag, removed the less formal sections that did the same job. * Fixed and clarified issues raised by Christian's document review. * Added a number of security considerations. -03: Revision by Rob Hansen * Clarified text on not rejecting messages because they contain unknown encIDs. * Removed normative language in section on accepting/rejecting non-CLUE-controlled media in the initial answer. * Example SDP updated to include the data channel "m" lines. Hanton, et al. Expires June 11, 2020 [Page 35] Internet-Draft CLUE Signaling December 2019 * Example call flow updated to show disablement of non-CLUE- controlled media once CLUE-controlled media is flowing. -02: Revision by Rob Hansen * Added section on not accepting non-CLUE-controlled "m" lines in the initial answer when CLUE is to be negotiated. * Removed previous language attempting to describe media restrictions for CLUE-controlled "m" lines that had not been configured, and replaced it with much more accurate 'treat as "a=inactive" was set'. * Made label element mandatory for CLUE-controlled media (was previously "SHOULD include", but there didn't seem a good reason for this - anyone wishing to include the "m" line but not immediately use it in CLUE can simply leave it out of the .) * Added a section on the specifics of relating encodings in SDP to elements in the CLUE protocol, including the fact that both Advertisement and Configure messages reference the *encoding* (eg, in the Configure case the sender of the Configure message includes the labels of the recipient's "m" lines as their contents). * Minor revisions to the section on complying with normative SDP/ CLUEstate machine language to clarify that these were not new normative language, merely that existing normative language still applies. * Removed appendices which previously contained information to be transferred to the protocol and data channel drafts. Removed other text that discussed alternatives to the current approach. * Cleaned up some 'todo' text. -01: Revision by Rob Hansen * Revised terminology - removed the term 'CLUE-enabled' device as insufficiently distinct from 'CLUE-capable' and instead added a term for 'CLUE-enabled' calls. * Removed text forbidding RTCP and instead added text that ICE/ DTLS negotiation for CLUE controlled media must be done as normal irrespective of CLUE negotiation. Hanton, et al. Expires June 11, 2020 [Page 36] Internet-Draft CLUE Signaling December 2019 * Changed 'sip.telepresence' to 'sip.clue' and 'TELEPRESENCE' grouping semantic back to CLUE. * Made it mandatory to have exactly one mid corresponding to a data channel in a CLUE group * Forbade having multiple CLUE groups unless a specification for doing so is published. * Refactored SDP-related text; previously the encoding information had been in the "initial offer" section despite the fact that we recommend that the initial offer doesn't actually include any encodings. I moved the specifications of encodings and how they're received to an earlier, seperate section. * Added text on how the state machines in CLUE and SDP are allowed to affect one another, and further recommendations on how a device should handle the sending of CLUE and SDP changes. -00: Revision by Rob Hansen * Submitted as -00 working group document draft-kyzivat-08: Revisions by Rob Hansen * Added media feature tag for CLUE support ('sip.telepresence') * Changed grouping semantic from 'CLUE' to 'TELEPRESENCE' * Restructured document to be more centred on the grouping semantic and its use with O/A * Lots of additional text on usage of the grouping semantic * Stricter definition of CLUE-controlled m lines and how they work * Some additional text on defining what happens when CLUE supports is added or removed * Added details on when to not send RTCP for CLUE-controlled "m" lines. * Added a section on using BUNDLE with CLUE * Updated data channel references to point at new WG document rather than indivual draft Hanton, et al. Expires June 11, 2020 [Page 37] Internet-Draft CLUE Signaling December 2019 draft-kyzivat-07: Revisions by Rob Hansen * Removed the text providing arguments for encoding limits being in SDP and Encoding Groups in the CLUE protocol in favor of the specifics of how to negotiate encodings in SDP * Added normative language on the setting up of a CLUE call, and added sections on mid-call changes to the CLUE status. * Added references to [I-D.ietf-clue-datachannel] where appropriate. * Added some terminology for various types of CLUE and non-CLUE states of operation. * Moved language related to topics that should be in [I-D.ietf-clue-datachannel] and [I-D.ietf-clue-protocol], but that has not yet been resolved in those documents, into an appendix. draft-kyzivat-06: Revisions by Rob Hansen * Removed CLUE message XML schema and details that are now in draft-presta-clue-protocol * Encoding limits in SDP section updated to note that this has been investigated and discussed and is the current working assumption of the WG, though consensus has not been fully achieved. * A section has also been added on the current mandation of unidirectional "m" lines. * Updated CLUE messaging in example call flow to match draft- presta-clue-protocol-03 draft-kyzivat-05: Revisions by pkyzivat: * Specified versioning model and mechanism. * Added explicit response to all messages. * Rearranged text to work with the above changes. (Which rendered diff almost useless.) draft-kyzivat-04: Revisions by Rob Hansen: ??? draft-kyzivat-03: Revisions by pkyzivat: Hanton, et al. Expires June 11, 2020 [Page 38] Internet-Draft CLUE Signaling December 2019 * Added a syntax section with an XML schema for CLUE messages. This is a strawhorse, and is very incomplete, but it establishes a template for doing this based on elements defined in the data model. (Thanks to Roberta for help with this!) * Did some rewording to fit the syntax section in and reference it. * Did some relatively minor restructuring of the document to make it flow better in a logical way. draft-kyzivat-02: A bunch of revisions by pkyzivat: * Moved roberta's call flows to a more appropriate place in the document. * New section on versioning. * New section on NAK. * A couple of possible alternatives for message acknowledgment. * Some discussion of when/how to signal changes in provider state. * Some discussion about the handling of transport errors. * Added a change history section. These were developed by Lennard Xiao, Christian Groves and Paul, so added Lennard and Christian as authors. draft-kyzivat-01: Updated by roberta to include some sample call flows. draft-kyzivat-00: Initial version by pkyzivat. Established general outline for the document, and specified a few things thought to represent wg consensus. 14. References 14.1. Normative References [I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, "An XML Schema for the CLUE data model", draft-ietf-clue-data-model-schema-17 (work in progress), August 2016. Hanton, et al. Expires June 11, 2020 [Page 39] Internet-Draft CLUE Signaling December 2019 [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf- clue-datachannel-18 (work in progress), April 2019. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Telepresence Multi-Streams", draft-ietf-clue- framework-25 (work in progress), January 2016. [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", draft-ietf- clue-protocol-19 (work in progress), July 2019. [I-D.ietf-clue-rtp-mapping] Even, R. and J. Lennox, "Mapping RTP streams to CLUE Media Captures", draft-ietf-clue-rtp-mapping-14 (work in progress), February 2017. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, "SDP-based Data Channel Negotiation", draft-ietf- mmusic-data-channel-sdpneg-28 (work in progress), May 2019. [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Hanton, et al. Expires June 11, 2020 [Page 40] Internet-Draft CLUE Signaling December 2019 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, . [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, DOI 10.17487/RFC2506, March 1999, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . Hanton, et al. Expires June 11, 2020 [Page 41] Internet-Draft CLUE Signaling December 2019 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, DOI 10.17487/RFC5630, October 2009, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . Authors' Addresses Robert Hanton Cisco Systems Email: rohanse2@cisco.com Paul Kyzivat Email: pkyzivat@alum.mit.edu Lennard Xiao Huawei Email: lennard.xiao@huawei.com Hanton, et al. Expires June 11, 2020 [Page 42] Internet-Draft CLUE Signaling December 2019 Christian Groves Email: cngroves.std@gmail.com Hanton, et al. Expires June 11, 2020 [Page 43]./draft-ietf-bess-evpn-prefix-advertisement-11.txt0000644000764400076440000024223513277623635021445 0ustar iustyiusty BESS Workgroup J. Rabadan, Ed. Internet Draft W. Henderickx Intended status: Standards Track Nokia J. Drake W. Lin Juniper A. Sajassi Cisco Expires: November 19, 2018 May 18, 2018 IP Prefix Advertisement in EVPN draft-ietf-bess-evpn-prefix-advertisement-11 Abstract The BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO (Network Virtualization Overlay) [RFC7365] network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at Rabadan et al. Expires November 19, 2018 [Page 1] Internet-Draft EVPN Prefix Advertisement May 18, 2018 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 19, 2018. Copyright Notice Copyright (c) 2018 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 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Inter-Subnet Connectivity Requirements in Data Centers . . . 5 2.2 The Need for the EVPN IP Prefix Route . . . . . . . . . . . 8 3. The BGP EVPN IP Prefix Route . . . . . . . . . . . . . . . . . 10 3.1 IP Prefix Route Encoding . . . . . . . . . . . . . . . . . . 11 3.2 Overlay Indexes and Recursive Lookup Resolution . . . . . . 13 4. Overlay Index Use-Cases . . . . . . . . . . . . . . . . . . . . 15 4.1 TS IP Address Overlay Index Use-Case . . . . . . . . . . . . 16 4.2 Floating IP Overlay Index Use-Case . . . . . . . . . . . . . 18 4.3 Bump-in-the-Wire Use-Case . . . . . . . . . . . . . . . . . 20 4.4 IP-VRF-to-IP-VRF Model . . . . . . . . . . . . . . . . . . . 23 4.4.1 Interface-less IP-VRF-to-IP-VRF Model . . . . . . . . . 24 4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD IRB . . . . . . 27 4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 33 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 33 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 34 7.2 Informative References . . . . . . . . . . . . . . . . . . . 34 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 35 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 Rabadan et al. Expires November 19, 2018 [Page 2] Internet-Draft EVPN Prefix Advertisement May 18, 2018 1. Introduction [RFC7365] provides a framework for Data Center (DC) Network Virtualization over Layer 3 and specifies that the Network Virtualization Edge devices (NVEs) must provide layer 2 and layer 3 virtualized network services in multi-tenant DCs. [RFC8365] discusses the use of EVPN as the technology of choice to provide layer 2 or intra-subnet services in these DCs. This document, along with [EVPN- INTERSUBNET], specifies the use of EVPN for layer 3 or inter-subnet connectivity services. [EVPN-INTERSUBNET] defines some fairly common inter-subnet forwarding scenarios where TSes can exchange packets with TSes located in remote subnets. In order to achieve this, [EVPN-INTERSUBNET] describes how MAC/IPs encoded in TS RT-2 routes are not only used to populate MAC- VRF and overlay ARP tables, but also IP-VRF tables with the encoded TS host routes (/32 or /128). In some cases, EVPN may advertise IP Prefixes and therefore provide aggregation in the IP-VRF tables, as opposed to propagate individual host routes. This document complements the scenarios described in [EVPN-INTERSUBNET] and defines how EVPN may be used to advertise IP Prefixes. Interoperability between EVPN and L3VPN [RFC4364] IP Prefix routes is out of the scope of this document. Section 2.1 describes the inter-subnet connectivity requirements in Data Centers. Section 2.2 explains why a new EVPN route type is required for IP Prefix advertisements. Sections 3, 4 and 5 will describe this route type and how it is used in some specific use cases. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. AC: Attachment Circuit. ARP: Address Resolution Protocol. BD: Broadcast Domain. As per [RFC7432], an EVI consists of a single or multiple BDs. In case of VLAN-bundle and VLAN-based service models (see [RFC7432]), a BD is equivalent to an EVI. In case of VLAN-aware bundle service model, an EVI contains multiple BDs. Also, in this document, BD and subnet are equivalent terms. Rabadan et al. Expires November 19, 2018 [Page 3] Internet-Draft EVPN Prefix Advertisement May 18, 2018 BD Route Target: refers to the Broadcast Domain assigned Route Target [RFC4364]. In case of VLAN-aware bundle service model, all the BD instances in the MAC-VRF share the same Route Target. BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per [RFC7432]. DGW: Data Center Gateway. Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per [RFC7432]. Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels with Ethernet payload. Examples of this type of tunnels are VXLAN or GENEVE. EVI: EVPN Instance spanning the NVE/PE devices that are participating on that EVPN, as per [RFC7432]. EVPN: Ethernet Virtual Private Networks, as per [RFC7432]. GRE: Generic Routing Encapsulation. GW IP: Gateway IP Address. IPL: IP Prefix Length. IP NVO tunnel: it refers to Network Virtualization Overlay tunnels with IP payload (no MAC header in the payload). IP-VRF: A VPN Routing and Forwarding table for IP routes on an NVE/PE. The IP routes could be populated by EVPN and IP-VPN address families. An IP-VRF is also an instantiation of a layer 3 VPN in an NVE/PE. IRB: Integrated Routing and Bridging interface. It connects an IP-VRF to a BD (or subnet). MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is also an instantiation of an EVI in an NVE/PE. ML: MAC address length. ND: Neighbor Discovery Protocol. NVE: Network Virtualization Edge. Rabadan et al. Expires November 19, 2018 [Page 4] Internet-Draft EVPN Prefix Advertisement May 18, 2018 GENEVE: Generic Network Virtualization Encapsulation, [GENEVE]. NVO: Network Virtualization Overlays. RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined in [RFC7432]. RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in Section 3. SBD: Supplementary Broadcast Domain. A BD that does not have any ACs, only IRB interfaces, and it is used to provide connectivity among all the IP-VRFs of the tenant. The SBD is only required in IP-VRF- to-IP-VRF use-cases (see Section 4.4.). SN: Subnet. TS: Tenant System. VA: Virtual Appliance. VNI: Virtual Network Identifier. As in [RFC8365], the term is used as a representation of a 24-bit NVO instance identifier, with the understanding that VNI will refer to a VXLAN Network Identifier in VXLAN, or Virtual Network Identifier in GENEVE, etc. unless it is stated otherwise. VTEP: VXLAN Termination End Point, as in [RFC7348]. VXLAN: Virtual Extensible LAN, as in [RFC7348]. This document also assumes familiarity with the terminology of [RFC7432], [RFC8365] and [RFC7365]. 2. Problem Statement This Section describes the inter-subnet connectivity requirements in Data Centers and why a specific route type to advertise IP Prefixes is needed. 2.1 Inter-Subnet Connectivity Requirements in Data Centers [RFC7432] is used as the control plane for a Network Virtualization Overlay (NVO) solution in Data Centers (DC), where Network Virtualization Edge (NVE) devices can be located in Hypervisors or Rabadan et al. Expires November 19, 2018 [Page 5] Internet-Draft EVPN Prefix Advertisement May 18, 2018 Top of Rack switches (ToRs), as described in [RFC8365]. The following considerations apply to Tenant Systems (TS) that are physical or virtual systems identified by MAC and maybe IP addresses and connected to BDs by Attachment Circuits: o The Tenant Systems may be Virtual Machines (VMs) that generate traffic from their own MAC and IP. o The Tenant Systems may be Virtual Appliance entities (VAs) that forward traffic to/from IP addresses of different End Devices sitting behind them. o These VAs can be firewalls, load balancers, NAT devices, other appliances or virtual gateways with virtual routing instances. o These VAs do not necessarily participate in dynamic routing protocols and hence rely on the EVPN NVEs to advertise the routes on their behalf. o In all these cases, the VA will forward traffic to other TSes using its own source MAC but the source IP will be the one associated to the End Device sitting behind or a translated IP address (part of a public NAT pool) if the VA is performing NAT. o Note that the same IP address and endpoint could exist behind two of these TSes. One example of this would be certain appliance resiliency mechanisms, where a virtual IP or floating IP can be owned by one of the two VAs running the resiliency protocol (the master VA). Virtual Router Redundancy Protocol (VRRP), RFC5798, is one particular example of this. Another example is multi-homed subnets, i.e., the same subnet is connected to two VAs. o Although these VAs provide IP connectivity to VMs and subnets behind them, they do not always have their own IP interface connected to the EVPN NVE, e.g., layer 2 firewalls are examples of VAs not supporting IP interfaces. Figure 1 illustrates some of the examples described above. Rabadan et al. Expires November 19, 2018 [Page 6] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1 +-----------+ TS1(VM)--| (BD-10) |-----+ IP1/M1 +-----------+ | DGW1 +---------+ +-------------+ | |----| (BD-10) | SN1---+ NVE2 | | | IRB1\ | | +-----------+ | | | (IP-VRF)|---+ SN2---TS2(VA)--| (BD-10) |-| | +-------------+ _|_ | IP2/M2 +-----------+ | VXLAN/ | ( ) IP4---+ <-+ | GENEVE | DGW2 ( WAN ) | | | +-------------+ (___) vIP23 (floating) | |----| (BD-10) | | | +---------+ | IRB2\ | | SN1---+ <-+ NVE3 | | | | (IP-VRF)|---+ | IP3/M3 +-----------+ | | | +-------------+ SN3---TS3(VA)--| (BD-10) |---+ | | | +-----------+ | | IP5---+ | | | | NVE4 | | NVE5 +--SN5 +---------------------+ | | +-----------+ | IP6------| (BD-1) | | +-| (BD-10) |--TS4(VA)--SN6 | \ | | +-----------+ | | (IP-VRF) |--+ ESI4 +--SN7 | / \IRB3 | |---| (BD-2) (BD-10) | SN4| +---------------------+ Figure 1 DC inter-subnet use-cases Where: NVE1, NVE2, NVE3, NVE4, NVE5, DGW1 and DGW2 share the same BD for a particular tenant. BD-10 is comprised of the collection of BD instances defined in all the NVEs. All the hosts connected to BD-10 belong to the same IP subnet. The hosts connected to BD-10 are listed below: o TS1 is a VM that generates/receives traffic from/to IP1, where IP1 belongs to the BD-10 subnet. o TS2 and TS3 are Virtual Appliances (VA) that send/receive traffic from/to the subnets and hosts sitting behind them (SN1, SN2, SN3, IP4 and IP5). Their IP addresses (IP2 and IP3) belong to the BD-10 subnet and they can also generate/receive traffic. When these VAs receive packets destined to their own MAC addresses (M2 and M3) they will route the packets to the proper subnet or host. These VAs Rabadan et al. Expires November 19, 2018 [Page 7] Internet-Draft EVPN Prefix Advertisement May 18, 2018 do not support routing protocols to advertise the subnets connected to them and can move to a different server and NVE when the Cloud Management System decides to do so. These VAs may also support redundancy mechanisms for some subnets, similar to VRRP, where a floating IP is owned by the master VA and only the master VA forwards traffic to a given subnet. E.g.,: vIP23 in Figure 1 is a floating IP that can be owned by TS2 or TS3 depending on which system is the master. Only the master will forward traffic to SN1. o Integrated Routing and Bridging interfaces IRB1, IRB2 and IRB3 have their own IP addresses that belong to the BD-10 subnet too. These IRB interfaces connect the BD-10 subnet to Virtual Routing and Forwarding (IP-VRF) instances that can route the traffic to other subnets for the same tenant (within the DC or at the other end of the WAN). o TS4 is a layer 2 VA that provides connectivity to subnets SN5, SN6 and SN7, but does not have an IP address itself in the BD-10. TS4 is connected to a port on NVE5 assigned to Ethernet Segment Identifier 4. For a BD that an ingress NVE is attached to, "Overlay Index" is defined as an identifier that the ingress EVPN NVE requires in order to forward packets to a subnet or host in a remote subnet. As an example, vIP23 (Figure 1) is an Overlay Index that any NVE attached to BD-10 needs to know in order to forward packets to SN1. IRB3 IP address is an Overlay Index required to get to SN4, and ESI4 (Ethernet Segment Identifier 4) is an Overlay Index needed to forward traffic to SN5. In other words, the Overlay Index is a next-hop in the overlay address space that can be an IP address, a MAC address or an ESI. When advertised along with an IP Prefix, the Overlay Index requires a recursive resolution to find out to what egress NVE the EVPN packets need to be sent. All the DC use cases in Figure 1 require inter-subnet forwarding and therefore, the individual host routes and subnets: a) must be advertised from the NVEs (since VAs and VMs do not participate in dynamic routing protocols) and b) may be associated to an Overlay Index that can be a VA IP address, a floating IP address, a MAC address or an ESI. The Overlay Index is further discussed in Section 3.2. 2.2 The Need for the EVPN IP Prefix Route [RFC7432] defines a MAC/IP route (also referred as RT-2) where a MAC Rabadan et al. Expires November 19, 2018 [Page 8] Internet-Draft EVPN Prefix Advertisement May 18, 2018 address can be advertised together with an IP address length and IP address (IP). While a variable IP address length might have been used to indicate the presence of an IP prefix in a route type 2, there are several specific use cases in which using this route type to deliver IP Prefixes is not suitable. One example of such use cases is the "floating IP" example described in Section 2.1. In this example it is needed to decouple the advertisement of the prefixes from the advertisement of MAC address of either M2 or M3, otherwise the solution gets highly inefficient and does not scale. For example, if 1,000 prefixes are advertised from M2 (using RT-2) and the floating IP owner changes from M2 to M3, 1,000 routes would be withdrawn from M2 and readvertise 1k routes from M3. However if a separate route type is used, 1,000 routes can be advertised as associated to the floating IP address (vIP23) and only one RT-2 for advertising the ownership of the floating IP, i.e., vIP23 and M2 in the route type 2. When the floating IP owner changes from M2 to M3, a single RT-2 withdraw/update is required to indicate the change. The remote DGW will not change any of the 1,000 prefixes associated to vIP23, but will only update the ARP resolution entry for vIP23 (now pointing at M3). An EVPN route (type 5) for the advertisement of IP Prefixes is described in this document. This new route type has a differentiated role from the RT-2 route and addresses the Data Center (or NVO-based networks in general) inter-subnet connectivity scenarios described in this document. Using this new RT-5, an IP Prefix may be advertised along with an Overlay Index that can be a GW IP address, a MAC or an ESI, or without an Overlay Index, in which case the BGP next-hop will point at the egress NVE/ASBR/ABR and the MAC in the Router's MAC Extended Community will provide the inner MAC destination address to be used. As discussed throughout the document, the EVPN RT-2 does not meet the requirements for all the DC use cases, therefore this EVPN route type 5 is required. The EVPN route type 5 decouples the IP Prefix advertisements from the MAC/IP route advertisements in EVPN, hence: a) Allows the clean and clear advertisements of IPv4 or IPv6 prefixes in an NLRI (Network Layer Reachability Information message) with no MAC addresses. b) Since the route type is different from the MAC/IP Advertisement route, the current [RFC7432] procedures do not need to be modified. Rabadan et al. Expires November 19, 2018 [Page 9] Internet-Draft EVPN Prefix Advertisement May 18, 2018 c) Allows a flexible implementation where the prefix can be linked to different types of Overlay/Underlay Indexes: overlay IP address, overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc. d) An EVPN implementation not requiring IP Prefixes can simply discard them by looking at the route type value. The following Sections describe how EVPN is extended with a route type for the advertisement of IP prefixes and how this route is used to address the inter-subnet connectivity requirements existing in the Data Center. 3. The BGP EVPN IP Prefix Route The BGP EVPN NLRI as defined in [RFC7432] is shown below: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ Figure 2 BGP EVPN NLRI This document defines an additional route type (RT-5) in the IANA EVPN Route Types registry [EVPNRouteTypes], to be used for the advertisement of EVPN routes using IP Prefixes: Value: 5 Description: IP Prefix Route According to Section 5.4 in [RFC7606], a node that doesn't recognize the Route Type 5 (RT-5) will ignore it. Therefore an NVE following this document can still be attached to a BD where an NVE ignoring RT- 5s is attached to. Regular [RFC7432] procedures would apply in that case for both NVEs. In case two or more NVEs are attached to different BDs of the same tenant, they MUST support RT-5 for the proper Inter-Subnet Forwarding operation of the tenant. The detailed encoding of this route and associated procedures are described in the following Sections. Rabadan et al. Expires November 19, 2018 [Page 10] Internet-Draft EVPN Prefix Advertisement May 18, 2018 3.1 IP Prefix Route Encoding An IP Prefix Route Type for IPv4 has the Length field set to 34 and consists of the following fields: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | IP Prefix Length (1 octet, 0 to 32) | +---------------------------------------+ | IP Prefix (4 octets) | +---------------------------------------+ | GW IP Address (4 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ Figure 3 EVPN IP Prefix route NLRI for IPv4 An IP Prefix Route Type for IPv6 has the Length field set to 58 and consists of the following fields: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | IP Prefix Length (1 octet, 0 to 128) | +---------------------------------------+ | IP Prefix (16 octets) | +---------------------------------------+ | GW IP Address (16 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ Figure 4 EVPN IP Prefix route NLRI for IPv6 Where: Rabadan et al. Expires November 19, 2018 [Page 11] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o The Length field of the BGP EVPN NLRI for an EVPN IP Prefix route MUST be either 34 (if IPv4 addresses are carried) or 58 (if IPv6 addresses are carried). The IP Prefix and Gateway IP Address MUST be from the same IP address family. o Route Distinguisher (RD) and Ethernet Tag ID MUST be used as defined in [RFC7432] and [RFC8365]. In particular, the RD is unique per MAC-VRF (or IP-VRF). The MPLS Label field is set to either an MPLS label or a VNI, as described in [RFC8365] for other EVPN route types. o The Ethernet Segment Identifier MUST be a non-zero 10-octet identifier if the ESI is used as an Overlay Index (see the definition of Overlay Index in Section 3.2). It MUST be all bytes zero otherwise. The ESI format is described in [RFC7432]. o The IP Prefix Length can be set to a value between 0 and 32 (bits) for IPv4 and between 0 and 128 for IPv6, and specifies the number of bits in the Prefix. The value MUST NOT be greater than 128. o The IP Prefix is a 4 or 16-octet field (IPv4 or IPv6). o The GW (Gateway) IP Address field is a 4 or 16-octet field (IPv4 or IPv6), and will encode a valid IP address as an Overlay Index for the IP Prefixes. The GW IP field MUST be all bytes zero if it is not used as an Overlay Index. Refer to Section 3.2 for the definition and use of the Overlay Index. o The MPLS Label field is encoded as 3 octets, where the high-order 20 bits contain the label value, as per [RFC7432]. When sending, the label value SHOULD be zero if recursive resolution based on overlay index is used. If the received MPLS Label value is zero, the route MUST contain an Overlay Index and the ingress NVE/PE MUST do recursive resolution to find the egress NVE/PE. If the received Label is zero and the route does not contain an Overlay Index, it MUST be treat-as-withdraw [RFC7606]. The RD, Ethernet Tag ID, IP Prefix Length and IP Prefix are part of the route key used by BGP to compare routes. The rest of the fields are not part of the route key. An IP Prefix Route MAY be sent along with a Router's MAC Extended Community (defined in [EVPN-INTERSUBNET]) to carry the MAC address that is used as the overlay index. Note that the MAC address may be that of an TS. As described in Section 3.2, certain data combinations in a received routes would imply a "treat-as-withdraw" handling of the route Rabadan et al. Expires November 19, 2018 [Page 12] Internet-Draft EVPN Prefix Advertisement May 18, 2018 [RFC7606]. 3.2 Overlay Indexes and Recursive Lookup Resolution RT-5 routes support recursive lookup resolution through the use of Overlay Indexes as follows: o An Overlay Index can be an ESI, IP address in the address space of the tenant or MAC address and it is used by an NVE as the next-hop for a given IP Prefix. An Overlay Index always needs a recursive route resolution on the NVE/PE that installs the RT-5 into one of its IP-VRFs, so that the NVE knows to which egress NVE/PE it needs to forward the packets. It is important to note that recursive resolution of the Overlay Index applies upon installation into an IP-VRF, and not upon BGP propagation (for instance, on an ASBR). Also, as a result of the recursive resolution, the egress NVE/PE is not necessarily the same NVE that originated the RT-5. o The Overlay Index is indicated along with the RT-5 in the ESI field, GW IP field or Router's MAC Extended Community, depending on whether the IP Prefix next-hop is an ESI, IP address or MAC address in the tenant space. The Overlay Index for a given IP Prefix is set by local policy at the NVE that originates an RT-5 for that IP Prefix (typically managed by the Cloud Management System). o In order to enable the recursive lookup resolution at the ingress NVE, an NVE that is a possible egress NVE for a given Overlay Index must originate a route advertising itself as the BGP next hop on the path to the system denoted by the Overlay Index. For instance: . If an NVE receives an RT-5 that specifies an Overlay Index, the NVE cannot use the RT-5 in its IP-VRF unless (or until) it can recursively resolve the Overlay Index. . If the RT-5 specifies an ESI as the Overlay Index, recursive resolution can only be done if the NVE has received and installed an RT-1 (Auto-Discovery per-EVI) route specifying that ESI. . If the RT-5 specifies a GW IP address as the Overlay Index, recursive resolution can only be done if the NVE has received and installed an RT-2 (MAC/IP route) specifying that IP address in the IP address field of its NLRI. . If the RT-5 specifies a MAC address as the Overlay Index, recursive resolution can only be done if the NVE has received and installed an RT-2 (MAC/IP route) specifying that MAC address in the MAC address field of its NLRI. Note that the RT-1 or RT-2 routes needed for the recursive resolution may arrive before or after the given RT-5 route. Rabadan et al. Expires November 19, 2018 [Page 13] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Irrespective of the recursive resolution, if there is no IGP or BGP route to the BGP next-hop of an RT-5, BGP MUST NOT install the RT-5 even if the Overlay Index can be resolved. o The ESI and GW IP fields may both be zero at the same time. However, they MUST NOT both be non-zero at the same time. A route containing a non-zero GW IP and a non-zero ESI (at the same time) SHOULD be treat-as-withdraw [RFC7606]. o If either the ESI or GW IP are non-zero, then the non-zero one is the Overlay Index, regardless of whether the Router's MAC Extended Community is present or the value of the Label. In case the GW IP is the Overlay Index (hence ESI is zero), the Router's MAC Extended Community is ignored if present. o A route where ESI, GW IP, MAC and Label are all zero at the same time SHOULD be treat-as-withdraw. The indirection provided by the Overlay Index and its recursive lookup resolution is required to achieve fast convergence in case of a failure of the object represented by the Overlay Index (see the example described in Section 2.2). Table 1 shows the different RT-5 field combinations allowed by this specification and what Overlay Index must be used by the receiving NVE/PE in each case. Those cases where there is no Overlay Index, are indicated as "None" in Table 1. If there is no Overlay Index the receiving NVE/PE will not perform any recursive resolution, and the actual next-hop is given by the RT-5's BGP next-hop. +----------+----------+----------+------------+----------------+ | ESI | GW IP | MAC* | Label | Overlay Index | |--------------------------------------------------------------| | Non-Zero | Zero | Zero | Don't Care | ESI | | Non-Zero | Zero | Non-Zero | Don't Care | ESI | | Zero | Non-Zero | Zero | Don't Care | GW IP | | Zero | Zero | Non-Zero | Zero | MAC | | Zero | Zero | Non-Zero | Non-Zero | MAC or None** | | Zero | Zero | Zero | Non-Zero | None*** | +----------+----------+----------+------------+----------------+ Table 1 - RT-5 fields and Indicated Overlay Index Table NOTES: * MAC with Zero value means no Router's MAC extended community is present along with the RT-5. Non-Zero indicates that the extended community is present and carries a valid MAC address. The Rabadan et al. Expires November 19, 2018 [Page 14] Internet-Draft EVPN Prefix Advertisement May 18, 2018 encoding of a MAC address MUST be the 6-octet MAC address specified by [802.1Q] and [802.1D-REV]. Examples of invalid MAC addresses are broadcast or multicast MAC addresses. The route MUST be treat-as-withdraw in case of an invalid MAC address. The presence of the Router's MAC extended community alone is not enough to indicate the use of the MAC address as the Overlay Index, since the extended community can be used for other purposes. ** In this case, the Overlay Index may be the RT-5's MAC address or None, depending on the local policy of the receiving NVE/PE. Note that the advertising NVE/PE that sets the Overlay Index SHOULD advertise an RT-2 for the MAC Overlay Index if there are receiving NVE/PEs configured to use the MAC as the Overlay Index. This case in Table 1 is used in the IP-VRF-to-IP-VRF implementations described in 4.4.1 and 4.4.3. The support of a MAC Overlay Index in this model is OPTIONAL. *** The Overlay Index is None. This is a special case used for IP- VRF-to-IP-VRF where the NVE/PEs are connected by IP NVO tunnels as opposed to Ethernet NVO tunnels. If the combination of ESI, GW IP, MAC and Label in the receiving RT-5 is different than the combinations shown in Table 1, the router will process the route as per the rules described at the beginning of this Section (3.2). Table 2 shows the different inter-subnet use-cases described in this document and the corresponding coding of the Overlay Index in the route type 5 (RT-5). +---------+---------------------+----------------------------+ | Section | Use-case | Overlay Index in the RT-5 | +-------------------------------+----------------------------+ | 4.1 | TS IP address | GW IP | | 4.2 | Floating IP address | GW IP | | 4.3 | "Bump in the wire" | ESI or MAC | | 4.4 | IP-VRF-to-IP-VRF | GW IP, MAC or None | +---------+---------------------+----------------------------+ Table 2 - Use-cases and Overlay Indexes for Recursive Resolution The above use-cases are representative of the different Overlay Indexes supported by RT-5 (GW IP, ESI, MAC or None). 4. Overlay Index Use-Cases Rabadan et al. Expires November 19, 2018 [Page 15] Internet-Draft EVPN Prefix Advertisement May 18, 2018 This Section describes some use-cases for the Overlay Index types used with the IP Prefix route. Although the examples use IPv4 Prefixes and subnets, the descriptions of the RT-5 are valid for the same cases with IPv6, only replacing the IP Prefixes, IPL and GW IP by the corresponding IPv6 values. 4.1 TS IP Address Overlay Index Use-Case Figure 5 illustrates an example of inter-subnet forwarding for subnets sitting behind Virtual Appliances (on TS2 and TS3). IP4---+ NVE2 DGW1 | +-----------+ +---------+ +-------------+ SN2---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | IP2/M2 +-----------+ | | | IRB1\ | -+---+ | | | (IP-VRF)|---+ | | | +-------------+ _|_ SN1 | VXLAN/ | ( ) | | GENEVE | DGW2 ( WAN ) -+---+ NVE3 | | +-------------+ (___) | IP3/M3 +-----------+ | |----| (BD-10) | | SN3---TS3(VA)--| (BD-10) |-| | | IRB2\ | | | +-----------+ +---------+ | (IP-VRF)|---+ IP5---+ +-------------+ Figure 5 TS IP address use-case An example of inter-subnet forwarding between subnet SN1, which uses a 24 bit IP prefix (written as SN1/24 in future), and a subnet sitting in the WAN is described below. NVE2, NVE3, DGW1 and DGW2 are running BGP EVPN. TS2 and TS3 do not participate in dynamic routing protocols, and they only have a static route to forward the traffic to the WAN. SN1/24 is dual-homed to NVE2 and NVE3. In this case, a GW IP is used as an Overlay Index. Although a different Overlay Index type could have been used, this use-case assumes that the operator knows the VA's IP addresses beforehand, whereas the VA's MAC address is unknown and the VA's ESI is zero. Because of this, the GW IP is the suitable Overlay Index to be used with the RT-5s. The NVEs know the GW IP to be used for a given Prefix by policy. (1) NVE2 advertises the following BGP routes on behalf of TS2: o Route type 2 (MAC/IP route) containing: ML=48 (MAC Address Length), M=M2 (MAC Address), IPL=32 (IP Prefix Length), IP=IP2 and [RFC5512] BGP Encapsulation Extended Community with the corresponding Tunnel type. The MAC and IP addresses may be Rabadan et al. Expires November 19, 2018 [Page 16] Internet-Draft EVPN Prefix Advertisement May 18, 2018 learned via ARP snooping. o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=IP2. The prefix and GW IP are learned by policy. (2) Similarly, NVE3 advertises the following BGP routes on behalf of TS3: o Route type 2 (MAC/IP route) containing: ML=48, M=M3, IPL=32, IP=IP3 (and BGP Encapsulation Extended Community). o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=IP3. (3) DGW1 and DGW2 import both received routes based on the Route Targets: o Based on the BD-10 Route Target in DGW1 and DGW2, the MAC/IP route is imported and M2 is added to the BD-10 along with its corresponding tunnel information. For instance, if VXLAN is used, the VTEP will be derived from the MAC/IP route BGP next- hop and VNI from the MPLS Label1 field. IP2 - M2 is added to the ARP table. Similarly, M3 is added to BD-10 and IP3 - M3 to the ARP table. o Based on the BD-10 Route Target in DGW1 and DGW2, the IP Prefix route is also imported and SN1/24 is added to the IP- VRF with Overlay Index IP2 pointing at the local BD-10. In this example, it is assumed that the RT-5 from NVE2 is preferred over the RT-5 from NVE3. If both routes were equally preferable and ECMP enabled, SN1/24 would also be added to the routing table with Overlay Index IP3. (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table and Overlay Index=IP2 is found. Since IP2 is an Overlay Index a recursive route resolution is required for IP2. o IP2 is resolved to M2 in the ARP table, and M2 is resolved to the tunnel information given by the BD FIB (e.g., remote VTEP and VNI for the VXLAN case). o The IP packet destined to IPx is encapsulated with: Rabadan et al. Expires November 19, 2018 [Page 17] Internet-Draft EVPN Prefix Advertisement May 18, 2018 . Source inner MAC = IRB1 MAC. . Destination inner MAC = M2. . Tunnel information provided by the BD (VNI, VTEP IPs and MACs for the VXLAN case). (5) When the packet arrives at NVE2: o Based on the tunnel information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup. o Encapsulation is stripped off and based on a MAC lookup (assuming MAC forwarding on the egress NVE), the packet is forwarded to TS2, where it will be properly routed. (6) Should TS2 move from NVE2 to NVE3, MAC Mobility procedures will be applied to the MAC route IP2/M2, as defined in [RFC7432]. Route type 5 prefixes are not subject to MAC mobility procedures, hence no changes in the DGW IP-VRF routing table will occur for TS2 mobility, i.e., all the prefixes will still be pointing at IP2 as Overlay Index. There is an indirection for e.g., SN1/24, which still points at Overlay Index IP2 in the routing table, but IP2 will be simply resolved to a different tunnel, based on the outcome of the MAC mobility procedures for the MAC/IP route IP2/M2. Note that in the opposite direction, TS2 will send traffic based on its static-route next-hop information (IRB1 and/or IRB2), and regular EVPN procedures will be applied. 4.2 Floating IP Overlay Index Use-Case Sometimes Tenant Systems (TS) work in active/standby mode where an upstream floating IP - owned by the active TS - is used as the Overlay Index to get to some subnets behind. This redundancy mode, already introduced in Section 2.1 and 2.2, is illustrated in Figure 6. Rabadan et al. Expires November 19, 2018 [Page 18] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE2 DGW1 +-----------+ +---------+ +-------------+ +---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | IP2/M2 +-----------+ | | | IRB1\ | | <-+ | | | (IP-VRF)|---+ | | | | +-------------+ _|_ SN1 vIP23 (floating) | VXLAN/ | ( ) | | | GENEVE | DGW2 ( WAN ) | <-+ NVE3 | | +-------------+ (___) | IP3/M3 +-----------+ | |----| (BD-10) | | +---TS3(VA)--| (BD-10) |-| | | IRB2\ | | +-----------+ +---------+ | (IP-VRF)|---+ +-------------+ Figure 6 Floating IP Overlay Index for redundant TS In this use-case, a GW IP is used as an Overlay Index for the same reasons as in 4.1. However, this GW IP is a floating IP that belongs to the active TS. Assuming TS2 is the active TS and owns vIP23: (1) NVE2 advertises the following BGP routes for TS2: o Route type 2 (MAC/IP route) containing: ML=48, M=M2, IPL=32, IP=vIP23 (and BGP Encapsulation Extended Community). The MAC and IP addresses may be learned via ARP snooping. o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=vIP23. The prefix and GW IP are learned by policy. (2) NVE3 advertises the following BGP route for TS3 (it does not advertise an RT-2 for vIP23/M3): o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=0, GW IP address=vIP23. The prefix and GW IP are learned by policy. (3) DGW1 and DGW2 import both received routes based on the Route Target: o M2 is added to the BD-10 FIB along with its corresponding tunnel information. For the VXLAN use case, the VTEP will be derived from the MAC/IP route BGP next-hop and VNI from the VNI field. vIP23 - M2 is added to the ARP table. o SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay index vIP23 pointing at M2 in the local BD-10. Rabadan et al. Expires November 19, 2018 [Page 19] Internet-Draft EVPN Prefix Advertisement May 18, 2018 (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table and Overlay Index=vIP23 is found. Since vIP23 is an Overlay Index, a recursive route resolution for vIP23 is required. o vIP23 is resolved to M2 in the ARP table, and M2 is resolved to the tunnel information given by the BD (remote VTEP and VNI for the VXLAN case). o The IP packet destined to IPx is encapsulated with: . Source inner MAC = IRB1 MAC. . Destination inner MAC = M2. . Tunnel information provided by the BD FIB (VNI, VTEP IPs and MACs for the VXLAN case). (5) When the packet arrives at NVE2: o Based on the tunnel information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup. o Encapsulation is stripped off and based on a MAC lookup (assuming MAC forwarding on the egress NVE), the packet is forwarded to TS2, where it will be properly routed. (6) When the redundancy protocol running between TS2 and TS3 appoints TS3 as the new active TS for SN1, TS3 will now own the floating vIP23 and will signal this new ownership, using a gratuitous ARP REPLY message (explained in [RFC5227]) or similar. Upon receiving the new owner's notification, NVE3 will issue a route type 2 for M3-vIP23 and NVE2 will withdraw the RT-2 for M2-vIP23. DGW1 and DGW2 will update their ARP tables with the new MAC resolving the floating IP. No changes are made in the IP-VRF routing table. 4.3 Bump-in-the-Wire Use-Case Figure 7 illustrates an example of inter-subnet forwarding for an IP Prefix route that carries a subnet SN1. In this use-case, TS2 and TS3 are layer 2 VA devices without any IP address that can be included as an Overlay Index in the GW IP field of the IP Prefix route. Their MAC addresses are M2 and M3 respectively and are connected to BD-10. Note that IRB1 and IRB2 (in DGW1 and DGW2 respectively) have IP addresses Rabadan et al. Expires November 19, 2018 [Page 20] Internet-Draft EVPN Prefix Advertisement May 18, 2018 in a subnet different than SN1. NVE2 DGW1 M2 +-----------+ +---------+ +-------------+ +---TS2(VA)--| (BD-10) |-| |----| (BD-10) | | ESI23 +-----------+ | | | IRB1\ | | + | | | (IP-VRF)|---+ | | | | +-------------+ _|_ SN1 | | VXLAN/ | ( ) | | | GENEVE | DGW2 ( WAN ) | + NVE3 | | +-------------+ (___) | ESI23 +-----------+ | |----| (BD-10) | | +---TS3(VA)--| (BD-10) |-| | | IRB2\ | | M3 +-----------+ +---------+ | (IP-VRF)|---+ +-------------+ Figure 7 Bump-in-the-wire use-case Since neither TS2 nor TS3 can participate in any dynamic routing protocol and have no IP address assigned, there are two potential Overlay Index types that can be used when advertising SN1: a) an ESI, i.e., ESI23, that can be provisioned on the attachment ports of NVE2 and NVE3, as shown in Figure 7. b) or the VA's MAC address, that can be added to NVE2 and NVE3 by policy. The advantage of using an ESI as Overlay Index as opposed to the VA's MAC address, is that the forwarding to the egress NVE can be done purely based on the state of the AC in the ES (notified by the Ethernet A-D per-EVI route) and all the EVPN multi-homing redundancy mechanisms can be reused. For instance, the [RFC7432] mass-withdrawal mechanism for fast failure detection and propagation can be used. This Section assumes that an ESI Overlay Index is used in this use- case but it does not prevent the use of the VA's MAC address as an Overlay Index. If a MAC is used as Overlay Index, the control plane must follow the procedures described in Section 4.4.3. The model supports VA redundancy in a similar way to the one described in Section 4.2 for the floating IP Overlay Index use-case, except that it uses the EVPN Ethernet A-D per-EVI route instead of the MAC advertisement route to advertise the location of the Overlay Index. The procedure is explained below: (1) Assuming TS2 is the active TS in ESI23, NVE2 advertises the following BGP routes: Rabadan et al. Expires November 19, 2018 [Page 21] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Route type 1 (Ethernet A-D route for BD-10) containing: ESI=ESI23 and the corresponding tunnel information (VNI field), as well as the BGP Encapsulation Extended Community as per [RFC8365]. o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=ESI23, GW IP address=0. The Router's MAC Extended Community defined in [EVPN-INTERSUBNET] is added and carries the MAC address (M2) associated to the TS behind which SN1 sits. M2 may be learned by policy, however the MAC in the Extended Community is preferred if sent with the route. (2) NVE3 advertises the following BGP route for TS3 (no AD per-EVI route is advertised): o Route type 5 (IP Prefix route) containing: IPL=24, IP=SN1, ESI=23, GW IP address=0. The Router's MAC Extended Community is added and carries the MAC address (M3) associated to the TS behind which SN1 sits. M3 may be learned by policy, however the MAC in the Extended Community is preferred if sent with the route. (3) DGW1 and DGW2 import the received routes based on the Route Target: o The tunnel information to get to ESI23 is installed in DGW1 and DGW2. For the VXLAN use case, the VTEP will be derived from the Ethernet A-D route BGP next-hop and VNI from the VNI/VSID field (see [RFC8365]). o The RT-5 coming from the NVE that advertised the RT-1 is selected and SN1/24 is added to the IP-VRF in DGW1 and DGW2 with Overlay Index ESI23 and MAC = M2. (4) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table and Overlay Index=ESI23 is found. Since ESI23 is an Overlay Index, a recursive route resolution is required to find the egress NVE where ESI23 resides. o The IP packet destined to IPx is encapsulated with: . Source inner MAC = IRB1 MAC. . Destination inner MAC = M2 (this MAC will be obtained from the Router's MAC Extended Community received along Rabadan et al. Expires November 19, 2018 [Page 22] Internet-Draft EVPN Prefix Advertisement May 18, 2018 with the RT-5 for SN1). Note that the Router's MAC Extended Community is used in this case to carry the TS' MAC address, as opposed to the NVE/PE's MAC address. . Tunnel information for the NVO tunnel is provided by the Ethernet A-D route per-EVI for ESI23 (VNI and VTEP IP for the VXLAN case). (5) When the packet arrives at NVE2: o Based on the tunnel demultiplexer information (VNI for the VXLAN case), the BD-10 context is identified for a MAC lookup (assuming MAC-based disposition model [RFC7432]) or the VNI may directly identify the egress interface (for a MPLS-based disposition model, which in this context is a VNI-based disposition model). o Encapsulation is stripped off and based on a MAC lookup (assuming MAC forwarding on the egress NVE) or a VNI lookup (in case of VNI forwarding), the packet is forwarded to TS2, where it will be forwarded to SN1. (6) If the redundancy protocol running between TS2 and TS3 follows an active/standby model and there is a failure, appointing TS3 as the new active TS for SN1, TS3 will now own the connectivity to SN1 and will signal this new ownership. Upon receiving the new owner's notification, NVE3's AC will become active and issue a route type 1 for ESI23, whereas NVE2 will withdraw its Ethernet A-D route for ESI23. DGW1 and DGW2 will update their tunnel information to resolve ESI23. The destination inner MAC will be changed to M3. 4.4 IP-VRF-to-IP-VRF Model This use-case is similar to the scenario described in "IRB forwarding on NVEs for Tenant Systems" in [EVPN-INTERSUBNET], however the new requirement here is the advertisement of IP Prefixes as opposed to only host routes. In the examples described in Sections 4.1, 4.2 and 4.3, the BD instance can connect IRB interfaces and any other Tenant Systems connected to it. EVPN provides connectivity for: 1. Traffic destined to the IRB or TS IP interfaces as well as 2. Traffic destined to IP subnets sitting behind the TS, e.g., SN1 or SN2. Rabadan et al. Expires November 19, 2018 [Page 23] Internet-Draft EVPN Prefix Advertisement May 18, 2018 In order to provide connectivity for (1), MAC/IP routes (RT-2) are needed so that IRB or TS MACs and IPs can be distributed. Connectivity type (2) is accomplished by the exchange of IP Prefix routes (RT-5) for IPs and subnets sitting behind certain Overlay Indexes, e.g., GW IP or ESI or TS MAC. In some cases, IP Prefix routes may be advertised for subnets and IPs sitting behind an IRB. This use-case is referred to as the "IP-VRF- to-IP-VRF" model. [EVPN-INTERSUBNET] defines an asymmetric IRB model and a symmetric IRB model, based on the required lookups at the ingress and egress NVE: the asymmetric model requires an IP lookup and a MAC lookup at the ingress NVE, whereas only a MAC lookup is needed at the egress NVE; the symmetric model requires IP and MAC lookups at both, ingress and egress NVE. From that perspective, the IP-VRF-to-IP-VRF use-case described in this Section is a symmetric IRB model. Note that, in an IP-VRF-to-IP-VRF scenario, out of the many subnets that a tenant may have, it may be the case that only a few are attached to a given NVE/PE's IP-VRF. In order to provide inter-subnet connectivity among the set of NVE/PEs where the tenant is connected, a new SBD is created on all of them if recursive resolution is needed. This SBD is instantiated as a regular BD (with no ACs) in each NVE/PE and has an IRB interface that connects the SBD to the IP- VRF. The IRB interface's IP or MAC address is used as the overlay index for recursive resolution. Depending on the existence and characteristics of the SBD and IRB interfaces for the IP-VRFs, there are three different IP-VRF-to-IP- VRF scenarios identified and described in this document: 1) Interface-less model: no SBD and no overlay indexes required. 2) Interface-ful with SBD IRB model: it requires SBD, as well as GW IP addresses as overlay indexes. 3) Interface-ful with unnumbered SBD IRB model: it requires SBD, as well as MAC addresses as overlay indexes. Inter-subnet IP multicast is outside the scope of this document. 4.4.1 Interface-less IP-VRF-to-IP-VRF Model Figure 8 will be used for the description of this model. Rabadan et al. Expires November 19, 2018 [Page 24] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1(M1) +------------+ IP1+----| (BD-1) | DGW1(M3) | \ | +---------+ +--------+ | (IP-VRF)|----| |-|(IP-VRF)|----+ | / | | | +--------+ | +---| (BD-2) | | | _+_ | +------------+ | | ( ) SN1| | VXLAN/ | ( WAN )--H1 | NVE2(M2) | GENEVE/| (___) | +------------+ | MPLS | + +---| (BD-2) | | | DGW2(M4) | | \ | | | +--------+ | | (IP-VRF)|----| |-|(IP-VRF)|----+ | / | +---------+ +--------+ SN2+----| (BD-3) | +------------+ Figure 8 Interface-less IP-VRF-to-IP-VRF model In this case: a) The NVEs and DGWs must provide connectivity between hosts in SN1, SN2, IP1 and hosts sitting at the other end of the WAN, for example, H1. It is assumed that the DGWs import/export IP and/or VPN-IP routes from/to the WAN. b) The IP-VRF instances in the NVE/DGWs are directly connected through NVO tunnels, and no IRBs and/or BD instances are instantiated to connect the IP-VRFs. c) The solution must provide layer 3 connectivity among the IP-VRFs for Ethernet NVO tunnels, for instance, VXLAN or GENEVE. d) The solution may provide layer 3 connectivity among the IP-VRFs for IP NVO tunnels, for example, GENEVE (with IP payload). In order to meet the above requirements, the EVPN route type 5 will be used to advertise the IP Prefixes, along with the Router's MAC Extended Community as defined in [EVPN-INTERSUBNET] if the advertising NVE/DGW uses Ethernet NVO tunnels. Each NVE/DGW will advertise an RT-5 for each of its prefixes with the following fields: o RD as per [RFC7432]. Rabadan et al. Expires November 19, 2018 [Page 25] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Ethernet Tag ID=0. o IP Prefix Length and IP address, as explained in the previous Sections. o GW IP address=0. o ESI=0 o MPLS label or VNI corresponding to the IP-VRF. Each RT-5 will be sent with a Route Target identifying the tenant (IP-VRF) and may be sent with two BGP extended communities: o The first one is the BGP Encapsulation Extended Community, as per [RFC5512], identifying the tunnel type. o The second one is the Router's MAC Extended Community as per [EVPN-INTERSUBNET] containing the MAC address associated to the NVE advertising the route. This MAC address identifies the NVE/DGW and MAY be reused for all the IP-VRFs in the NVE. The Router's MAC Extended Community must be sent if the route is associated to an Ethernet NVO tunnel, for instance, VXLAN. If the route is associated to an IP NVO tunnel, for instance GENEVE with IP payload, the Router's MAC Extended Community should not be sent. The following example illustrates the procedure to advertise and forward packets to SN1/24 (IPv4 prefix advertised from NVE1): (1) NVE1 advertises the following BGP route: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label=10. . GW IP= set to 0. . [RFC5512] BGP Encapsulation Extended Community. . Router's MAC Extended Community that contains M1. . Route Target identifying the tenant (IP-VRF). (2) DGW1 imports the received routes from NVE1: o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route Target. Rabadan et al. Expires November 19, 2018 [Page 26] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o Since GW IP=ESI=0, the Label is a non-zero value and the local policy indicates this interface-less model, DGW1 will use the Label and next-hop of the RT-5, as well as the MAC address conveyed in the Router's MAC Extended Community (as inner destination MAC address) to set up the forwarding state and later encapsulate the routed IP packets. (3) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table. The lookup yields SN1/24. o Since the RT-5 for SN1/24 had a GW IP=ESI=0, a non-zero Label and next-hop and the model is interface-less, DGW1 will not need a recursive lookup to resolve the route. o The IP packet destined to IPx is encapsulated with: Source inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer IP (tunnel source IP) = DGW1 IP, Destination outer IP (tunnel destination IP) = NVE1 IP. The Source and Destination inner MAC addresses are not needed if IP NVO tunnels are used. (4) When the packet arrives at NVE1: o NVE1 will identify the IP-VRF for an IP lookup based on the Label (the Destination inner MAC is not needed to identify the IP-VRF). o An IP lookup is performed in the routing context, where SN1 turns out to be a local subnet associated to BD-2. A subsequent lookup in the ARP table and the BD FIB will provide the forwarding information for the packet in BD-2. The model described above is called Interface-less model since the IP-VRFs are connected directly through tunnels and they don't require those tunnels to be terminated in SBDs instead, as in Sections 4.4.2 or 4.4.3. 4.4.2 Interface-ful IP-VRF-to-IP-VRF with SBD IRB Figure 9 will be used for the description of this model. Rabadan et al. Expires November 19, 2018 [Page 27] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1 +------------+ DGW1 IP10+---+(BD-1) | +---------------+ +------------+ | \ | | | | | |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ | / IRB(IP1/M1) IRB(IP3/M3) | | +---+(BD-2) | | | +------------+ _+_ | +------------+ | | ( ) SN1| | VXLAN/ | ( WAN )--H1 | NVE2 | GENEVE/ | (___) | +------------+ | MPLS | DGW2 + +---+(BD-2) | | | +------------+ | | \ | | | | | | |(IP-VRF)-(SBD)| |(SBD)-(IP-VRF)|-----+ | / IRB(IP2/M2) IRB(IP4/M4) | SN2+----+(BD-3) | +---------------+ +------------+ +------------+ Figure 9 Interface-ful with SBD IRB model In this model: a) As in Section 4.4.1, the NVEs and DGWs must provide connectivity between hosts in SN1, SN2, IP10 and hosts sitting at the other end of the WAN. b) However, the NVE/DGWs are now connected through Ethernet NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB interfaces for their connectivity to the SBD. c) Each SBD IRB has an IP and a MAC address, where the IP address must be reachable from other NVEs or DGWs. d) The SBD is attached to all the NVE/DGWs in the tenant domain BDs. e) The solution must provide layer 3 connectivity for Ethernet NVO tunnels, for instance, VXLAN or GENEVE (with Ethernet payload). EVPN type 5 routes will be used to advertise the IP Prefixes, whereas EVPN RT-2 routes will advertise the MAC/IP addresses of each SBD IRB interface. Each NVE/DGW will advertise an RT-5 for each of its prefixes with the following fields: o RD as per [RFC7432]. o Ethernet Tag ID=0. Rabadan et al. Expires November 19, 2018 [Page 28] Internet-Draft EVPN Prefix Advertisement May 18, 2018 o IP Prefix Length and IP address, as explained in the previous Sections. o GW IP address=IRB-IP of the SBD (this is the Overlay Index that will be used for the recursive route resolution). o ESI=0 o Label value should be zero since the RT-5 route requires a recursive lookup resolution to an RT-2 route. It is ignored on reception, and, when forwarding packets, the MPLS label or VNI from the RT-2's MPLS Label1 field is used. Each RT-5 will be sent with a Route Target identifying the tenant (IP-VRF). The Router's MAC Extended Community should not be sent in this case. The following example illustrates the procedure to advertise and forward packets to SN1/24 (IPv4 prefix advertised from NVE1): (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label= SHOULD be set to 0. . GW IP=IP1 (SBD IRB's IP) . Route Target identifying the tenant (IP-VRF). o Route type 2 (MAC/IP route for the SBD IRB) containing: . ML=48, M=M1, IPL=32, IP=IP1, Label=10. . A [RFC5512] BGP Encapsulation Extended Community. . Route Target identifying the SBD. This Route Target may be the same as the one used with the RT-5. (2) DGW1 imports the received routes from NVE1: o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route Target. . Since GW IP is different from zero, the GW IP (IP1) will be used as the Overlay Index for the recursive route resolution to the RT-2 carrying IP1. Rabadan et al. Expires November 19, 2018 [Page 29] Internet-Draft EVPN Prefix Advertisement May 18, 2018 (3) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table. The lookup yields SN1/24, which is associated to the Overlay Index IP1. The forwarding information is derived from the RT-2 received for IP1. o The IP packet destined to IPx is encapsulated with: Source inner MAC = M3, Destination inner MAC = M1, Source outer IP (source VTEP) = DGW1 IP, Destination outer IP (destination VTEP) = IP1. (4) When the packet arrives at NVE1: o NVE1 will identify the IP-VRF for an IP lookup based on the Label and the inner MAC DA. o An IP lookup is performed in the routing context, where SN1 turns out to be a local subnet associated to BD-2. A subsequent lookup in the ARP table and the BD FIB will provide the forwarding information for the packet in BD-2. The model described above is called 'Interface-ful with SBD IRB model' because the tunnels connecting the DGWs and NVEs need to be terminated into the SBD. The SBD is connected to the IP-VRFs via SBD IRB interfaces, and that allows the recursive resolution of RT-5s to GW IP addresses. 4.4.3 Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB Figure 10 will be used for the description of this model. Note that this model is similar to the one described in Section 4.4.2, only without IP addresses on the SBD IRB interfaces. Rabadan et al. Expires November 19, 2018 [Page 30] Internet-Draft EVPN Prefix Advertisement May 18, 2018 NVE1 +------------+ DGW1 IP1+----+(BD-1) | +---------------+ +------------+ | \ | | | | | |(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+ | / IRB(M1)| | IRB(M3) | | +---+(BD-2) | | | +------------+ _+_ | +------------+ | | ( ) SN1| | VXLAN/ | ( WAN )--H1 | NVE2 | GENEVE/ | (___) | +------------+ | MPLS | DGW2 + +---+(BD-2) | | | +------------+ | | \ | | | | | | |(IP-VRF)-(SBD)| (SBD)-(IP-VRF) |-----+ | / IRB(M2)| | IRB(M4) | SN2+----+(BD-3) | +---------------+ +------------+ +------------+ Figure 10 Interface-ful with unnumbered SBD IRB model In this model: a) As in Section 4.4.1 and 4.4.2, the NVEs and DGWs must provide connectivity between hosts in SN1, SN2, IP1 and hosts sitting at the other end of the WAN. b) As in Section 4.4.2, the NVE/DGWs are connected through Ethernet NVO tunnels terminated in the SBD instance. The IP-VRFs use IRB interfaces for their connectivity to the SBD. c) However, each SBD IRB has a MAC address only, and no IP address (that is why the model refers to an 'unnumbered' SBD IRB). In this model, there is no need to have IP reachability to the SBD IRB interfaces themselves and there is a requirement to limit the number of IP addresses used. d) As in Section 4.4.2, the SBD is composed of all the NVE/DGW BDs of the tenant that need inter-subnet-forwarding. e) As in Section 4.4.2, the solution must provide layer 3 connectivity for Ethernet NVO tunnels, for instance, VXLAN or GENEVE (with Ethernet payload). This model will also make use of the RT-5 recursive resolution. EVPN type 5 routes will advertise the IP Prefixes along with the Router's MAC Extended Community used for the recursive lookup, whereas EVPN RT-2 routes will advertise the MAC addresses of each SBD IRB Rabadan et al. Expires November 19, 2018 [Page 31] Internet-Draft EVPN Prefix Advertisement May 18, 2018 interface (this time without an IP). Each NVE/DGW will advertise an RT-5 for each of its prefixes with the same fields as described in 4.4.2 except for: o GW IP address= set to 0. Each RT-5 will be sent with a Route Target identifying the tenant (IP-VRF) and the Router's MAC Extended Community containing the MAC address associated to SBD IRB interface. This MAC address may be reused for all the IP-VRFs in the NVE. The example is similar to the one in Section 4.4.2: (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing the same values as in the example in Section 4.4.2, except for: . GW IP= SHOULD be set to 0. . Router's MAC Extended Community containing M1 (this will be used for the recursive lookup to a RT-2). o Route type 2 (MAC route for the SBD IRB) with the same values as in Section 4.4.2 except for: . ML=48, M=M1, IPL=0, Label=10. (2) DGW1 imports the received routes from NVE1: o DGW1 installs SN1/24 in the IP-VRF identified by the RT-5 Route Target. . The MAC contained in the Router's MAC Extended Community sent along with the RT-5 (M1) will be used as the Overlay Index for the recursive route resolution to the RT-2 carrying M1. (3) When DGW1 receives a packet from the WAN with destination IPx, where IPx belongs to SN1/24: o A destination IP lookup is performed on the DGW1 IP-VRF routing table. The lookup yields SN1/24, which is associated to the Overlay Index M1. The forwarding information is derived from the RT-2 received for M1. o The IP packet destined to IPx is encapsulated with: Source Rabadan et al. Expires November 19, 2018 [Page 32] Internet-Draft EVPN Prefix Advertisement May 18, 2018 inner MAC = M3, Destination inner MAC = M1, Source outer IP (source VTEP) = DGW1 IP, Destination outer IP (destination VTEP) = NVE1 IP. (4) When the packet arrives at NVE1: o NVE1 will identify the IP-VRF for an IP lookup based on the Label and the inner MAC DA. o An IP lookup is performed in the routing context, where SN1 turns out to be a local subnet associated to BD-2. A subsequent lookup in the ARP table and the BD FIB will provide the forwarding information for the packet in BD-2. The model described above is called Interface-ful with unnumbered SBD IRB model (as in Section 4.4.2), only this time the SBD IRB does not have an IP address. 5. Security Considerations This document provides a set of procedures to achieve Inter-Subnet Forwarding across NVEs or PEs attached to a group of BDs that belong to the same tenant (or VPN). The security considerations discussed in [RFC7432] apply to the Intra-Subnet Forwarding or communication within each of those BDs. In addition, the security considerations in [RFC4364] should also be understood, since this document and [RFC4364] may be used in similar applications. Contrary to [RFC4364], this document does not describe PE/CE route distribution techniques, but rather considers the CEs as TSes or VAs that do not run dynamic routing protocols. This can be considered a security advantage, since dynamic routing protocols can be blocked on the NVE/PE ACs, not allowing the tenant to interact with the infrastructure's dynamic routing protocols. In this document, the RT-5 may use a regular BGP Next Hop for its resolution or an Overlay Index that requires a recursive resolution to a different EVPN route (an RT-2 or an RT-1). In the latter case, it is worth noting that any action that ends up filtering or modifying the RT-2/RT-1 routes used to convey the Overlay Indexes, will modify the resolution of the RT-5 and therefore the forwarding of packets to the remote subnet. 6. IANA Considerations This document requests value 5 in the [EVPNRouteTypes] registry Rabadan et al. Expires November 19, 2018 [Page 33] Internet-Draft EVPN Prefix Advertisement May 18, 2018 defined by [RFC7432]: Value Description Reference 5 IP Prefix route [this document] 7. References 7.1 Normative References [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8365] Sajassi-Drake et al., "A Network Virtualization Overlay Solution using EVPN", RFC 8365, DOI 10.17487/RFC8365, March, 2018. [EVPN-INTERSUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt, work in progress, February, 2017 [EVPNRouteTypes] IANA EVPN Route Type registry, https://www.iana.org/assignments/evpn 7.2 Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC7606] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, August Rabadan et al. Expires November 19, 2018 [Page 34] Internet-Draft EVPN Prefix Advertisement May 18, 2018 2015, . [802.1D-REV] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges", IEEE Std. 802.1D, June 2004. [802.1Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q(tm), 2014 Edition, November 2014. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, . [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [GENEVE] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-06, March 2018. 8. Acknowledgments The authors would like to thank Mukul Katiyar and Jeffrey Zhang for their valuable feedback and contributions. The following people also helped improving this document with their feedback: Tony Przygienda and Thomas Morin. Special THANK YOU to Eric Rosen for his detailed review, it really helped improve the readability and clarify the concepts. Thank you to Alvaro Retana for his thorough review. 9. Contributors In addition to the authors listed on the front page, the following co-authors have also contributed to this document: Senthil Sathappan Florin Balus Aldrin Isaac Senad Palislamovic Rabadan et al. Expires November 19, 2018 [Page 35] Internet-Draft EVPN Prefix Advertisement May 18, 2018 Samir Thoria 10. Authors' Addresses Jorge Rabadan (Editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Wim Henderickx Nokia Email: wim.henderickx@nokia.com John E. Drake Juniper Email: jdrake@juniper.net Ali Sajassi Cisco Email: sajassi@cisco.com Wen Lin Juniper Email: wlin@juniper.net Rabadan et al. Expires November 19, 2018 [Page 36] ./draft-ietf-dots-server-discovery-15.txt0000644000764400076440000016074713754413700017663 0ustar iustyiusty DOTS M. Boucadair Internet-Draft Orange Intended status: Standards Track T. Reddy Expires: May 19, 2021 McAfee November 15, 2020 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery draft-ietf-dots-server-discovery-15 Abstract This document specifies mechanisms to configure Distributed Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 19, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Boucadair & Reddy Expires May 19, 2021 [Page 1] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Why Multiple Discovery Mechanisms? . . . . . . . . . . . . . 5 4. DOTS Discovery Procedure . . . . . . . . . . . . . . . . . . 6 5. DHCP Options for DOTS Agent Discovery . . . . . . . . . . . . 8 5.1. DHCPv6 DOTS Options . . . . . . . . . . . . . . . . . . . 9 5.1.1. Format of DOTS Reference Identifier Option . . . . . 9 5.1.2. Format of DOTS Address Option . . . . . . . . . . . . 10 5.1.3. DHCPv6 Client Behavior . . . . . . . . . . . . . . . 11 5.2. DHCPv4 DOTS Options . . . . . . . . . . . . . . . . . . . 11 5.2.1. Format of DOTS Reference Identifier Option . . . . . 11 5.2.2. Format of DOTS Address Option . . . . . . . . . . . . 12 5.2.3. DHCPv4 Client Behavior . . . . . . . . . . . . . . . 13 6. Discovery using Service Resolution . . . . . . . . . . . . . 14 7. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Service Resolution . . . . . . . . . . . . . . . . . . . 19 8.3. DNS Service Discovery . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. The Service Name and Transport Protocol Port Number Registry . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 20 9.3. DHCPv4 Options . . . . . . . . . . . . . . . . . . . . . 21 9.4. Application Service & Application Protocol Tags . . . . . 21 9.4.1. DOTS Application Service Tag Registration . . . . . . 21 9.4.2. DOTS Call Home Application Service Tag Registration . 21 9.4.3. signal.udp Application Protocol Tag Registration . . 22 9.4.4. signal.tcp Application Protocol Tag Registration . . 22 9.4.5. data.tcp Application Protocol Tag Registration . . . 22 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Boucadair & Reddy Expires May 19, 2021 [Page 2] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 1. Introduction DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an architecture, in which a DOTS client can inform a DOTS server that the network is under a potential attack and that appropriate mitigation actions are required. Indeed, because the lack of a common method to coordinate a real-time response among involved actors and network domains inhibits the effectiveness of DDoS attack mitigation, the DOTS signal channel protocol [RFC8782] is meant to carry requests for DDoS attack mitigation. With this approach, DOTS can reduce the impact of an attack and lead to more efficient defensive actions in various deployment scenarios such as those discussed in [I-D.ietf-dots-use-cases]. Moreover, DOTS clients can instruct a DOTS server to install named filtering rules by means of the DOTS data channel protocol [RFC8783]. The basic high-level DOTS architecture is illustrated in Figure 1. +-----------+ +-------------+ | Mitigator | ~~~~~~~~~~ | DOTS Server | +-----------+ +------+------+ | | | +---------------+ +------+------+ | Attack Target | ~~~~~~ | DOTS Client | +---------------+ +-------------+ Figure 1: Basic DOTS Architecture [RFC8811] specifies that the DOTS client may be provided with a list of DOTS servers, each associated with one or more IP addresses. These addresses may or may not be of the same address family. The DOTS client establishes one or more DOTS sessions by connecting to the provided DOTS server addresses. This document specifies methods for DOTS clients to discover their DOTS server(s). The rationale for specifying multiple discovery mechanisms is discussed in Section 3. The discovery methods can also be used by a DOTS server to locate a DOTS client in the context of DOTS Signal Channel Call Home [I-D.ietf-dots-signal-call-home]. The basic high-level DOTS Call Home architecture is illustrated in Figure 2. Boucadair & Reddy Expires May 19, 2021 [Page 3] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 +---------------+ +-------------+ | Alert | ~~~~~~ | Call Home | | | | DOTS client | +---------------+ +------+------+ | | | +---------------+ +------+------+ | Attack | ~~~~~~ | Call Home | | Source(s) | | DOTS server | +---------------+ +-------------+ Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture A DOTS agent may be used to establish base DOTS channels, DOTS Call Home, or both. This specification accommodates all these deployment cases. Considerations for the selection of DOTS server(s) by multi-homed DOTS clients are out of this document scope; readers should refer to [I-D.ietf-dots-multihoming] for more details. This document assumes that security credentials to authenticate DOTS server(s) are pre-provisioned to a DOTS client using a mechanism such as (but not limited to) those discussed in [RFC8572] or [I-D.ietf-anima-bootstrapping-keyinfra]. DOTS clients use those credentials for authentication purposes following the rules documented in [RFC8782]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in [RFC3958]. DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. "DOTS client" refers to a DOTS-aware software module responsible for requesting attack response coordination with other DOTS-aware elements. "DOTS server" is a DOTS-aware software module handling and responding to messages from DOTS clients. The DOTS server enables mitigation on behalf of the DOTS client, if requested, by communicating the DOTS Boucadair & Reddy Expires May 19, 2021 [Page 4] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 client's request to the mitigator and returning selected mitigator feedback to the requesting DOTS client. "Call Home DOTS client" (or "Call Home DOTS server") refers to a DOTS client (or DOTS server) deployed in a Call Home scenario (Figure 2). "DOTS agent" is any DOTS-aware software module capable of participating in a DOTS channel. "Peer DOTS agent" refers to the peer DOTS server (base DOTS operation) or to a peer Call Home DOTS client (for DOTS Signal Channel Call Home). 3. Why Multiple Discovery Mechanisms? Analysis of the various use cases sketched in [I-D.ietf-dots-use-cases] reveals that it is unlikely that one single discovery method can be suitable for all the sample deployments. Concretely: o Many of the use cases discussed in [I-D.ietf-dots-use-cases] do involve a Customer Premises Equipment (CPE) device. Multiple CPEs, connected to distinct network providers, may even be considered. It is intuitive to leverage existing mechanisms such as discovery using service resolution or DHCP to provision the CPE acting as a DOTS client with the DOTS server(s). o Resolving a DOTS server domain name offered by an upstream transit provider provisioned to a DOTS client into IP address(es) requires the use of the appropriate DNS resolvers; otherwise, resolving those names will fail. The use of protocols such as DHCP does allow associating provisioned DOTS server domain names with a list of DNS servers to be used for name resolution. Furthermore, DHCP allows directly providing IP addresses therefore avoiding the need for extra lookup delays. o Some of the use cases may allow DOTS clients to have direct communications with upstream DOTS servers, that is, no DOTS gateway is involved. Leveraging existing protocol behaviors that do not require specific features on the node embedding the DOTS client may ease DOTS deployment. Typically, the use of Straightforward-Naming Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS server administrators to provision the preferred DOTS transport protocol between the DOTS client and the DOTS server and allows the DOTS client to discover this preference. Boucadair & Reddy Expires May 19, 2021 [Page 5] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 o The upstream network provider is not the DDoS mitigation provider for some of these use cases. It is safe to assume that for such deployments, the DOTS server(s) domain name is provided during the service subscription (i.e., manual/local configuration). o Multiple DOTS clients may be enabled within a network (e.g., enterprise network). Dynamic discovery needs to be deterministic from an operational standpoint. o Some of the use cases may involve a DOTS gateway that is responsible for selecting the appropriate DOTS server(s) to relay requests received from DOTS clients. Consequently, this document describes a unified discovery logic (Section 4) which involves the following mechanisms: o Dynamic discovery using DHCP (Section 5). o A resolution mechanism based on Straightforward Naming Authority Pointer (S-NAPTR) resource records in the Domain Name System (DNS) (Section 6). o DNS Service Discovery (Section 7). 4. DOTS Discovery Procedure Operators will need a consistent set of ways in which DOTS clients can discover this information and a consistent priority among these options. If some devices prefer manual configuration over dynamic discovery, while others prefer dynamic discovery over manual configuration, the result will be a process where the operator must find devices that are using the wrong DOTS server(s), determine how to ensure the devices are configured properly, and then reconfigure the device through the preferred method. All DOTS clients MUST support at least one of the three mechanisms below to determine a DOTS server list. All DOTS clients SHOULD implement all three, or as many as are practical for any specific device, of the following ways to discover DOTS servers in order to facilitate the deployment of DOTS in large scale environments. For example, a CPE will support the first two mechanisms, a host within a LAN will support the last two mechanisms, or an application server will support a local configuration. More examples are discussed in Section 3. DOTS clients will prefer information received from the discovery methods in the order listed below. 1. Explicit configuration: Boucadair & Reddy Expires May 19, 2021 [Page 6] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 * Local/Manual configuration: A DOTS client will learn the DOTS server(s) by means of local or manual DOTS configuration (i.e., DOTS servers configured at the system level). Configuration discovered from a DOTS client application is considered as local configuration. An implementation may give the user an opportunity (e.g., by means of configuration file options or menu items) to specify DOTS server(s) for each address family. These may be specified either as a list of IP addresses or the DNS name of a DOTS server. When only DOTS server IP addresses are configured, a reference identifier must also be configured for authentication purposes. * Automatic configuration (e.g., DHCP): The DOTS client attempts to discover DOTS server(s) names and/or addresses from DHCP, as described in Section 5. 2. Service Resolution : The DOTS client attempts to discover DOTS server name(s) using service resolution, as specified in Section 6. 3. DNS SD: DNS Service Discovery. The DOTS client attempts to discover DOTS server name(s) using DNS service discovery, as specified in Section 7. Some of these mechanisms imply the use of DNS to resolve the IP address(es) of the DOTS server, while others imply an IP address of the relevant DOTS server is obtained directly. Implementation options may vary on a per device basis, as some devices may not have DNS capabilities and/or suitable DNS configuration. On hosts with more than one interface or address family (IPv4/IPv6), the DOTS server discovery procedure has to be performed for each interface/address-family combination. A DOTS client may choose to perform the discovery procedure only for a desired interface/address combination if the client does not wish to discover a DOTS server for all interface/address-family combinations. This procedure is also followed by a Call Home DOTS server to discover its Call Home DOTS client in the context of [I-D.ietf-dots-signal-call-home]. The discovery method is performed upon bootstrapping of a DOTS agent, and is reiterated by the DOTS agent upon the following events: o Expiry of a validity timer (e.g., DHCP lease, DHCP information refresh time, DNS TTL) associated with a discovered DOTS agent. Boucadair & Reddy Expires May 19, 2021 [Page 7] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 o Expiry of the certificate of a peer DOTS agent currently in use. o Attachment to a new network. 5. DHCP Options for DOTS Agent Discovery As reported in Section 1.7.2 of [RFC6125]: "Some certification authorities issue server certificates based on IP addresses, but preliminary evidence indicates that such certificates are a very small percentage (less than 1%) of issued certificates". In order to allow for PKIX-based authentication between a DOTS client and server while accommodating the current best practices for issuing certificates, this document allows DOTS agents to retrieve the names of their peer DOTS agents. These names can be used for two purposes: to retrieve the list of IP addresses of a peer DOTS agent or to be presented as a reference identifier for authentication purposes. Defining the option to include a list of IP addresses would avoid a dependency on an underlying name resolution, but that design requires also supplying a name for PKIX-based authentication purposes. Given that DOTS gateways can be involved in a DOTS session, a peer DOTS agent can be reachable using a link-local address. Such addresses can also be discovered using the options defined in Section 5.1. The list of the IP addresses returned by DHCP servers is typically used to feed the DOTS server selection procedure including when DOTS agents are provided with primary and backup IP addresses of their peer DOTS agents. An example of DOTS server selection procedure is specified in Section 4.3 of [RFC8782]. The design assumes that the same peer DOTS agent is used for establishing both signal and data channels. For more customized configurations (e.g., transport-specific configuration, distinct DOTS servers for the signal and the data channels), an operator can supply only a DOTS reference identifier that will be then passed to the procedure described in Section 6. The design allows terminating the base DOTS channels and DOTS Call Home on the same or distinct peer DOTS agents. If distinct peer DOTS agents are deployed, the DHCP option can return, for example, a list of IP addresses to a requesting DOTS agent. This list includes the IP address to be used for the base DOTS channels and the IP address for the DOTS Call Home. The DOTS client (or Call Home DOTS server) Boucadair & Reddy Expires May 19, 2021 [Page 8] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 will then use the address selection procedure specified in Section 4.3 of [RFC8782] to identify the IP address of the peer DOTS server (or Call Home DOTS client). For example: Let's consider that the DOTS server is reachable at 2001:db8:122:300::1 while the Call Home DOTS client is reachable at 2001:db8:122:300::2. The DHCP server will then return one DOTS reference identifier and a list that includes both 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP client. That list is passed to the DOTS client (or Call Home DOTS server) which will try to establish connections to the addresses of that list and destination port number 4646 (or the Call Home port number). As a result, the DOTS client (or Call Home DOTS server) will select 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or Call Home DOTS client). 5.1. DHCPv6 DOTS Options 5.1.1. Format of DOTS Reference Identifier Option The DHCPv6 DOTS Reference Identifier option is used to configure a name of the DOTS server (or the name of the Call Home DOTS client). The format of this option is shown in Figure 3. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V6_DOTS_RI | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | dots-agent-name (FQDN) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: DHCPv6 DOTS Reference Identifier Option The fields of the option shown in Figure 3 are as follows: o Option-code: OPTION_V6_DOTS_RI (TBA1, see Section 9.2) o Option-length: Length of the dots-agent-name field in octets. o dots-agent-name: A fully qualified domain name of the peer DOTS agent. This field is formatted as specified in Section 10 of [RFC8415]. An example of the dots-agent-name encoding is shown in Figure 4. This example conveys the FQDN "dots.example.com.", and the resulting Option-length field is 18. Boucadair & Reddy Expires May 19, 2021 [Page 9] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 +------+------+------+------+------+------+------+------+------+ | 0x04 | d | o | t | s | 0x07 | e | x | a | +------+------+------+------+------+------+------+------+------+ | m | p | l | e | 0x03 | c | o | m | 0x00 | +------+------+------+------+------+------+------+------+------+ Figure 4: An example of the dots-agent-name Encoding 5.1.2. Format of DOTS Address Option The DHCPv6 DOTS Address option can be used to configure a list of IPv6 addresses of a DOTS server (or a Call Home DOTS client). The format of this option is shown in Figure 5. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V6_DOTS_ADDRESS | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DOTS ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | DOTS ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DHCPv6 DOTS Address Option The fields of the option shown in Figure 5 are as follows: o Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see Section 9.2) o Option-length: Length of the 'DOTS ipv6-address(es)' field in octets. MUST be a multiple of 16. o DOTS ipv6-address(es): Includes one or more IPv6 addresses [RFC4291] of the peer DOTS agent to be used by a DOTS agent for establishing a DOTS session. The addresses are listed in the order of preference for use by the DOTS agent. Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) may be included in this option when there is no DHCPv4 server able to advertise the DHCPv4 DOTS options (Section 5.2) and when only IPv4 connectivity is possible to the peer DOTS agent. Boucadair & Reddy Expires May 19, 2021 [Page 10] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 5.1.3. DHCPv6 Client Behavior DHCP clients MAY request options OPTION_V6_DOTS_RI and OPTION_V6_DOTS_ADDRESS, as defined in [RFC8415], Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. As a convenience to the reader, it is mentioned here that the DHCP client includes the requested option codes in the Option Request Option. If the DHCP client receives more than one instance of OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use only the first instance of that option. The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS. If the DHCP client receives and validates both OPTION_V6_DOTS_RI and OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used as the reference identifier for authentication purposes (e.g., PKIX [RFC6125]), while the valid addresses included in OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to an underlying resolution library in the presence of valid OPTION_V6_DOTS_ADDRESS in a response. If the DHCP client receives OPTION_V6_DOTS_RI only, but OPTION_V6_DOTS_RI contains more than one name, the DHCP client MUST use only the first name. Once the name is validated (Section 10 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name is also used as a reference identifier for authentication purposes. If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In addition, these addresses can be used as identifiers for authentication. 5.2. DHCPv4 DOTS Options 5.2.1. Format of DOTS Reference Identifier Option The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to configure a name of the peer DOTS agent. The format of this option is illustrated in Figure 6. Boucadair & Reddy Expires May 19, 2021 [Page 11] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 Code Length Peer DOTS agent name +-----+-----+-----+-----+-----+-----+-----+-- |TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. Figure 6: DHCPv4 DOTS Reference Identifier Option The fields of the option shown in Figure 6 are as follows: o Code: OPTION_V4_DOTS_RI (TBA3, see Section 9.3). o Length: Includes the length of the "Peer DOTS agent name" field in octets. o Peer DOTS agent name: The domain name of the peer DOTS agent. This field is formatted as specified in Section 10 of [RFC8415]. 5.2.2. Format of DOTS Address Option The DHCPv4 DOTS Address option can be used to configure a list of IPv4 addresses of a peer DOTS agent. The format of this option is illustrated in Figure 7. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=TBA4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + DOTS IPv4 Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | | | + DOTS IPv4 Address | | | | optional +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . ... . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Figure 7: DHCPv4 DOTS Address Option The fields of the option shown in Figure 7 are as follows: o Code: OPTION_V4_DOTS_ADDRESS (TBA4, see Section 9.3). o Length: is set to 4*N, where N is the number of IPv4 addresses included in the option. Boucadair & Reddy Expires May 19, 2021 [Page 12] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 o DOTS IPv4 Address(es): Contains one or more IPv4 addresses of the peer DOTS agent to be used by a DOTS agent. The addresses are listed in the order of preference for use by the DOTS agent. OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, the mechanism specified in [RFC3396] MUST be used if OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 octets. 5.2.3. DHCPv4 Client Behavior To discover a peer DOTS agent, the DHCPv4 client MUST include both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request List Option [RFC2132]. If the DHCP client receives more than one instance of OPTION_V4_DOTS_RI option, it MUST use only the first instance of that option. The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] conveyed in OPTION_V4_DOTS_ADDRESS. If the DHCP client receives and validates both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used as the reference identifier for authentication purposes (e.g., PKIX [RFC6125]), while the valid addresses included in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be passed to underlying resolution library in the presence of valid OPTION_V4_DOTS_ADDRESS in a response. If the DHCP client receives OPTION_V4_DOTS_RI only, but OPTION_V4_DOTS_RI option contains more than one name, as distinguished by the presence of multiple root labels, the DHCP client MUST use only the first name. Once the name is validated (Section 10 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name is also used as a reference identifier for authentication purposes. If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS server. In addition, these addresses can be used as identifiers for authentication. Boucadair & Reddy Expires May 19, 2021 [Page 13] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 6. Discovery using Service Resolution This mechanism is performed in two steps: 1. A DNS domain name is retrieved for each combination of interface and address family. A DOTS agent has to determine the domain in which it is located relying on dynamic means such as DHCP (Section 5). Implementations may allow the user to specify a default name that is used, if no specific name has been configured. 2. Retrieved DNS domain names are then used for S-NAPTR lookups [RFC3958]. Further DNS lookups may be necessary to determine the peer DOTS agent IP address(es). Once the DOTS agent has retrieved its DNS domain or discovered the peer DOTS agent name that needs to be resolved, an S-NAPTR lookup with the appropriate application service and the desired protocol tag is made to obtain information necessary to connect to the authoritative peer DOTS agent within the given domain. This specification defines 'DOTS' and 'DOTS-CALL-HOME' as application service tags (Sections 9.4.1 and 9.4.2). It also defines "signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and "data.tcp" (Section 9.4.5) as application protocol tags. An example is provided in Figure 8. In the example below, for domain 'example.net', the resolution algorithm will result in IP address(es), port, tag, and protocol tuples listed in Table 1. Boucadair & Reddy Expires May 19, 2021 [Page 14] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 example.net. IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. signal.example.net. IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net. IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net. data.example.net. IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net. IN NAPTR 200 10 "a" DOTS:data.tcp "" b.example.net. _dots-signal._udp.example.net. IN SRV 0 0 5000 a.example.net. _dots-signal._tcp.example.net. IN SRV 0 0 5001 a.example.net. _dots-data._tcp.example.net. IN SRV 0 0 5002 a.example.net. a.example.net. IN AAAA 2001:db8::1 b.example.net. IN AAAA 2001:db8::2 Figure 8: Example of Discovery of DOTS Servers using Service Resolution +-------+----------+-------------+------+--------+ | Order | Protocol | IP address | Port | Tag | +-------+----------+-------------+------+--------+ | 1 | UDP | 2001:db8::1 | 5000 | Signal | | 2 | TCP | 2001:db8::1 | 5001 | Signal | | 3 | TCP | 2001:db8::1 | 5002 | Data | | 4 | TCP | 2001:db8::2 | 443 | Data | +-------+----------+-------------+------+--------+ Table 1: Resolution Results An example is provided in Figure 9 for the Call Home case. In this example, the resolution algorithm will result in IP address(es), port, and protocol listed in Table 2 for domain 'example.net'. Boucadair & Reddy Expires May 19, 2021 [Page 15] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 example.net. IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. signal.example.net. IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" _dots-call-home._udp.example.net. IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" _dots-call-home._tcp.example.net. _dots-call-home._udp.example.net. IN SRV 0 0 6000 b.example.net. _dots-call-home._tcp.example.net. IN SRV 0 0 6001 b.example.net. b.example.net. IN AAAA 2001:db8::2 Figure 9: Example of Discovery of DOTS Call Home Client using Service Resolution +-------+----------+-------------+------+ | Order | Protocol | IP address | Port | +-------+----------+-------------+------+ | 1 | UDP | 2001:db8::2 | 6000 | | 2 | TCP | 2001:db8::2 | 6001 | +-------+----------+-------------+------+ Table 2: Resolution Results (Call Home) Note that customized port numbers are used for the DOTS signal channel, DOTS data channel, and DOTS signal channel call home in the examples shown in Figures 8 and 9 for illustration purposes. If default port numbers are used in a deployment, the discovery procedure will return 4646 (DOTS signal channel) and 443 (DOTS data channel) as DOTS service port numbers. If no DOTS-specific S-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If more domain names are known, the discovery procedure MAY perform the corresponding S-NAPTR lookups immediately. However, before retrying a lookup that has failed, a DOTS client MUST wait a time period that is appropriate for the encountered error (e.g., NXDOMAIN, timeout, etc.). Boucadair & Reddy Expires May 19, 2021 [Page 16] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 7. DNS Service Discovery DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic solutions for discovering services. DNS-SD defines a set of naming rules for certain DNS record types that they use for advertising and discovering services. Section 4.1 of [RFC6763] specifies that a service instance name in DNS-SD has the following structure: . . The portion specifies the DNS sub-domain where the service instance is registered. It is a conventional domain name such as "example.com.". The portion of the DOTS service instance name MUST be "_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or "_dots-call-home._udp" or "_dots-call-home._tcp". This document does not define any keys; the TXT record of a DNS-SD service is thus empty (Section 6 of [RFC6763]). Figure 10 depicts an excerpt of the DNS zone configuration file listing record examples to discover two DOTS signal channel servers. In this example, only UDP is supported as transport for the establishment of the DOTS signal channel. _dots-signal._udp.example.net. PTR a._dots-signal._udp.example.net. _dots-signal._udp.example.net. PTR b._dots-signal._udp.example.net. a._dots-signal._udp.example.net. SRV 0 0 4646 a.example.net. b._dots-signal._udp.example.net. SRV 0 0 4646 b.example.net. a._dots-signal._udp.example.net. TXT "" b._dots-signal._udp.example.net. TXT "" Figure 10: An Example of DNS-SD Records for the UDP DOTS Signal Channel involving Two Servers with the Same Priority. 8. Security Considerations DOTS-related security considerations are discussed in Section 4 of [RFC8811]. As a reminder, DOTS agents must authenticate each other using (D)TLS before a DOTS session is considered valid according to the [RFC8782]. An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The Boucadair & Reddy Expires May 19, 2021 [Page 17] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 security implications of such attack are those inherent to the fallback discovery mechanism discussed in the following subsections. The results of the discovery procedure are a function of the interface/address family. Contacting a discovered DOTS server via an interface to which it is not bound may exacerbate the delay required to establish a DOTS channel. Moreover, such behavior may reveal that a DOTS service is enabled by a DOTS client domain and exposes the identity of the DOTS service provider (that can be inferred from the name and the destination IP address) to external networks. Security considerations related to how security credentials to authenticate DOTS server(s) are provisioned to a DOTS client are those inherent to the mechanism used for that purpose (see for example, [RFC8572]). 8.1. DHCP The security considerations in [RFC2131] and [RFC8415] are to be considered. In particular, issues related to rogue DHCP servers and means to mitigate many of these attacks are discussed in Section 22 of [RFC8415]. An attacker can get a domain name, domain-validated public certificate from a CA, and host a DOTS agent. An active attacker can then spoof DHCP responses to include the attacker's DOTS agent. Such an attacker can also launch other attacks as discussed in Section 22 of [RFC8415]. In addition to the mitigations listed in Section 22 of [RFC8415], a DOTS agent may be pre-configured with a list of trusted DOTS domain names. If such a list is pre-configured, a DOTS agent will accept a DHCP-discovered name if it matches a name in that list. Also, the DOTS agent has to check that the 'DNS-ID' identifier type within subjectAltName in the server certificate matches a pre- configured name. If the DOTS agent is instructed to trust subdomains of the names in that list as well (e.g., "*.example.com"), a DOTS agent will accept a DHCP-discovered name that matches a name in the pre-configured list (e.g., "dots-1.example.com" or "dots- 2.example.com"). Relying on an underlying resolution library to resolve a supplied reference identifier has similar security issues as those discussed in Section 8.2 (e.g., an active attacker may modify DNS messages used to resolve the supplied reference identifier and point the client to an attacker server). Supplying both an IP address and the reference identifier makes it easier to use a mis-issued certificate. Boucadair & Reddy Expires May 19, 2021 [Page 18] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 8.2. Service Resolution The primary attack against the methods described in Section 6 is one that would lead to impersonation of a peer DOTS agent. An attacker could attempt to compromise the S-NAPTR resolution. The DOTS client (or a Call Home DOTS server) constructs one reference identifier for the DOTS server (or a Call Home DOTS client) based on the domain name which is used for S-NAPTR lookup: DNS-ID. If the reference identifier is found (as described in Section 6 of [RFC6125]) in the PKIX certificate's subjectAltName extension, the DOTS client should accept the certificate for the server. DNS Security Extensions (DNSSEC) [RFC4033] uses cryptographic keys and digital signatures to provide authentication of DNS data. The information that is retrieved from the S-NAPTR lookup and that is validated using DNSSEC is thereby proved to be the authoritative data. 8.3. DNS Service Discovery Since DNS-SD is a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. For DNS queries, DNSSEC SHOULD be used where the authenticity of information is important. For DNS updates, secure updates [RFC2136][RFC3007] SHOULD generally be used to control which clients have permission to update DNS records. Note that means such as DNS over TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC8484] can be used to prevent eavesdroppers from accessing DNS messages. 9. IANA Considerations 9.1. The Service Name and Transport Protocol Port Number Registry IANA is requested to allocate the following service names from the registry available at: https://www.iana.org/assignments/service- names-port-numbers/service-names-port-numbers.xhtml. Boucadair & Reddy Expires May 19, 2021 [Page 19] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 Service Name: dots-data Port Number: N/A Transport Protocol(s): TCP Description: DOTS Data Channel Protocol The service name is used to construct the SRV service name "_dots-data._tcp" for discovering DOTS servers used to establish DOTS data channel. Assignee: IESG Contact: IETF Chair Reference: [ThisDocument] Service Name: dots-call-home Transport Protocol(s): TCP/UDP Description: DOTS Signal Channel Call Home Protocol. The service name is used to construct the SRV service names "_dots-call-home._udp" and "_dots-call-home._tcp" for discovering Call Home DOTS clients used to establish DOTS signal channel call home. Assignee: IESG Contact: IETF Chair Reference: [ThisDocument] IANA is requested to update the following entry from the registry available at: https://www.iana.org/assignments/service-names-port- numbers/service-names-port-numbers.xhtml. Service Name: dots-signal Port Number: 4646 Transport Protocol(s): TCP/UDP Description: DOTS Signal Channel Protocol. The service name is used to construct the SRV service names "_dots-signal._udp" and "_dots-signal._tcp" for discovering DOTS servers used to establish DOTS signal channel. Assignee: IESG Contact: IETF Chair Reference: [RFC8782][ThisDocument] 9.2. DHCPv6 Options IANA is requested to assign the following new DHCPv6 Option Codes in the registry maintained in: https://www.iana.org/assignments/dhcpv6- parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. Boucadair & Reddy Expires May 19, 2021 [Page 20] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 Value Description Client ORO Singleton Option TBA1 OPTION_V6_DOTS_RI Yes Yes TBA2 OPTION_V6_DOTS_ADDRESS Yes Yes 9.3. DHCPv4 Options IANA is requested to assign the following new DHCPv4 Option Codes in the registry maintained in: https://www.iana.org/assignments/bootp- dhcp-parameters/bootp-dhcp-parameters.xhtml#options. Name Tag Data Meaning Reference Length ---------------------- ---- ---------- --------------- -------------- OPTION_V4_DOTS_RI TBA3 N The name of the [ThisDocument] peer DOTS agent. OPTION_V4_DOTS_ADDRESS TBA4 N (the N/4 IPv4 [ThisDocument] minimal addresses of length is peer DOTS 4) agent(s). 9.4. Application Service & Application Protocol Tags This document requests IANA to make the following allocations from the registries available at: https://www.iana.org/assignments/s- naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-1 for Application Service Tags and https://www.iana.org/assignments/s- naptr-parameters/s-naptr-parameters.xhtml#s-naptr-parameters-2 for Application Protocol Tags. 9.4.1. DOTS Application Service Tag Registration o Application Service Tag: DOTS o Intended Usage: See Section 6 o Security Considerations: See Section 8 o Interoperability considerations: None o Relevant publications: This document 9.4.2. DOTS Call Home Application Service Tag Registration o Application Service Tag: DOTS-CALL-HOME o Intended Usage: See Section 6 Boucadair & Reddy Expires May 19, 2021 [Page 21] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 o Security Considerations: See Section 8 o Interoperability considerations: None o Relevant publications: This document 9.4.3. signal.udp Application Protocol Tag Registration o Application Protocol Tag: signal.udp o Intended Usage: See Section 6 o Security Considerations: See Section 8 o Interoperability considerations: None o Relevant publications: This document 9.4.4. signal.tcp Application Protocol Tag Registration o Application Protocol Tag: signal.tcp o Intended Usage: See Section 6 o Security Considerations: See Section 8 o Interoperability considerations: None o Relevant publications: This document 9.4.5. data.tcp Application Protocol Tag Registration o Application Protocol Tag: data.tcp o Intended Usage: See Section 6 o Security Considerations: See Section 8 o Interoperability considerations: None o Relevant publications: This document 10. Contributors Prashanth Patil Cisco Systems, Inc. Email: praspati@cisco.com Boucadair & Reddy Expires May 19, 2021 [Page 22] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 11. Acknowledgements Thanks to Brian Carpenter for the review of the BRSKI text used be in previous versions of the specification. Many thanks to Russ White for the review, comments, and text contribution. Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the review and comments. Thanks to Bernie Volz for the review of the DHCP section. Many thanks to Benjamin Kaduk for the detailed AD review. Thanks to Zhen Cao, Kyle Rose, Nagendra Nainar, and Peter Yee for the directorate reviews. Thanks to Barry Leiba, Martin Duke, Roman Danyliw, Eric Vyncke, and Magnus Westerlund for the IESG review. 12. References 12.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, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, . [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, . [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, . Boucadair & Reddy Expires May 19, 2021 [Page 23] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . 12.2. Informative References [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- keyinfra-45 (work in progress), November 2020. [I-D.ietf-dots-multihoming] Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of- Service Open Threat Signaling (DOTS)", draft-ietf-dots- multihoming-04 (work in progress), May 2020. [I-D.ietf-dots-signal-call-home] Reddy.K, T., Boucadair, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home", draft-ietf-dots-signal-call-home-11 (work in progress), October 2020. [I-D.ietf-dots-use-cases] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", draft-ietf-dots-use-cases-25 (work in progress), July 2020. Boucadair & Reddy Expires May 19, 2021 [Page 24] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, . [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, . [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of- Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, . [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, . Boucadair & Reddy Expires May 19, 2021 [Page 25] Internet-Draft DOTS Server/Call Home Client Discovery November 2020 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, August 2020, . Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: TirumaleswarReddy_Konda@McAfee.com Boucadair & Reddy Expires May 19, 2021 [Page 26] ./draft-ietf-bess-nsh-bgp-control-plane-18.txt0000644000764400076440000050447413720031407020437 0ustar iustyiusty BESS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track J. Drake Expires: February 22, 2021 E. Rosen Juniper Networks J. Uttaro AT&T L. Jalil Verizon August 21, 2020 BGP Control Plane for the Network Service Header in Service Function Chaining draft-ietf-bess-nsh-bgp-control-plane-18 Abstract This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC Address Family Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header defined in RFC 8300. This document adopts the SFC architecture described in RFC 7665. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Farrel, et al. Expires February 22, 2021 [Page 1] Internet-Draft BGP for NSH SFC August 2020 This Internet-Draft will expire on February 22, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Overview of Service Function Chaining . . . . . . . . . . 6 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 17 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 23 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Service Function Instance Routes . . . . . . . . . . . . 24 4.3. Service Function Path Routes . . . . . . . . . . . . . . 25 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 27 4.5. Service Function Forwarder Operation . . . . . . . . . . 27 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 28 5. Selection within Service Function Paths . . . . . . . . . . . 30 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 32 6.1. Protocol Control of Looping, Jumping, and Branching . . . 32 6.2. Implications for Forwarding State . . . . . . . . . . . . 33 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Correlating Service Function Path Instances . . . . . . . 34 7.2. Considerations for Stateful Service Functions . . . . . . 34 7.3. VPN Considerations and Private Service Functions . . . . 35 7.4. Flow Specification for SFC Classifiers . . . . . . . . . 36 Farrel, et al. Expires February 22, 2021 [Page 2] Internet-Draft BGP for NSH SFC August 2020 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 38 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 39 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 39 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 42 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 42 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 43 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 43 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 44 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 45 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 45 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 46 8.9. Examples of SFPs with Stateful Service Functions . . . . 46 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 47 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 48 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 50 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 52 8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 55 8.10.1. Example Explicit SFP With No Choices . . . . . . . . 57 8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 58 8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 58 8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 62 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 62 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 62 10.4. New SFP Association Type Registry . . . . . . . . . . . 63 10.5. New Service Function Type Registry . . . . . . . . . . . 64 10.6. New Generic Transitive Experimental Use Extended Community Sub-Types . . . . . . . . . . . . . . . . . . 66 10.7. New BGP Transitive Extended Community Type . . . . . . . 66 10.8. New SFC Extended Community Sub-Types Registry . . . . . 66 10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 67 10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 67 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 13.1. Normative References . . . . . . . . . . . . . . . . . . 68 13.2. Informative References . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 1. Introduction As described in [RFC7498], the delivery of end-to-end services can require a packet to pass through a series of Service Functions (SFs) (e.g., WAN and application accelerators, Deep Packet Inspection (DPI) Farrel, et al. Expires February 22, 2021 [Page 3] Internet-Draft BGP for NSH SFC August 2020 engines, firewalls, TCP optimizers, and server load balancers) in a specified order: this is termed "Service Function Chaining" (SFC). There are a number of issues associated with deploying and maintaining service function chaining in production networks, which are described below. Historically, if a packet needed to travel through a particular service chain, the nodes hosting the service functions of that chain were placed in the network topology in such a way that the packet could not reach its ultimate destination without first passing through all the service functions in the proper order. This need to place the service functions at particular topological locations limited the ability to adapt a service function chain to changes in network topology (e.g., link or node failures), network utilization, or offered service load. These topological restrictions on where the service functions can be placed raised the following issues: 1. The process of configuring or modifying a service function chain is operationally complex and may require changes to the network topology. 2. Alternate or redundant service functions may need to be co- located with the primary service functions. 3. When there is more than one path between source and destination, forwarding may be asymmetric and it may be difficult to support bidirectional service function chains using simple routing methodologies and protocols without adding mechanisms for traffic steering or traffic engineering. In order to address these issues, the SFC architecture describes Service Function Chains that are built in their own overlay network (the service function overlay network), coexisting with other overlay networks, over a common underlay network [RFC7665]. A Service Function Chain is a sequence of Service Functions through which packet flows that satisfy specified criteria will pass. This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC Address Family Identifier / Subsequent Address Family Identifier (AFI/SAFI) with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller (a centralized network component responsible for planning and coordinating Service Function Chaining within the network) to Farrel, et al. Expires February 22, 2021 [Page 4] Internet-Draft BGP for NSH SFC August 2020 advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header [RFC8300]. This document adopts the SFC architecture described in [RFC7665]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology This document uses the following terms from [RFC7665]: o Bidirectional Service Function Chain o Classifier o Service Function (SF) o Service Function Chain (SFC) o Service Function Forwarder (SFF) o Service Function Instance (SFI) o Service Function Path (SFP) o SFC branching Additionally, this document uses the following terms from [RFC8300]: o Network Service Header (NSH) o Service Index (SI) o Service Path Identifier (SPI) This document introduces the following terms: o Service Function Instance Route (SFIR). A new BGP Route Type advertised by the node that hosts an SFI to describe the SFI and to announce the way to forward a packet to the node through the underlay network. Farrel, et al. Expires February 22, 2021 [Page 5] Internet-Draft BGP for NSH SFC August 2020 o Service Function Overlay Network. The logical network comprised of Classifiers, SFFs, and SFIs that are connected by paths or tunnels through underlay transport networks. o Service Function Path Route (SFPR). A new BGP Route Type originated by Controllers to advertise the details of each SFP. o Service Function Type (SFT). An indication of the function and features of an SFI. 2. Overview This section provides an overview of Service Function Chaining in general, and the control plane defined in this document. After reading this section, readers may find it helpful to look through Section 8 for some simple worked examples. 2.1. Overview of Service Function Chaining In [RFC8300] a Service Function Chain (SFC) is an ordered list of Service Functions (SFs). A Service Function Path (SFP) is an indication of which instances of SFs are acceptable to be traversed in an instantiation of an SFC in a service function overlay network. The Service Path Identifier (SPI) is a 24-bit number that identifies a specific SFP, and a Service Index (SI) is an 8-bit number that identifies a specific point in that path. In the context of a particular SFP (identified by an SPI), an SI represents a particular Service Function, and indicates the order of that SF in the SFP. Within the context of a specific SFP, an SI references a set of one or more SFs. Each of those SFs may be supported by one or more Service Function Instances (SFIs). Thus an SI may represent a choice of SFIs of one or more Service Function Types. By deploying multiple SFIs for a single SF, one can provide load balancing and redundancy. A special functional element, called a Classifier, is located at each ingress point to a service function overlay network. It assigns the packets of a given packet flow to a specific Service Function Path. This may be done by comparing specific fields in a packet's header with local policy, which may be customer/network/service specific. The Classifier picks an SFP and sets the SPI accordingly, it then sets the SI to the value of the SI for the first hop in the SFP, and then prepends a Network Services Header (NSH) [RFC8300] containing the assigned SPI/SI to that packet. Note that the Classifier and the node that hosts the first Service Function in a Service Function Path need not be located at the same point in the service function overlay network. Farrel, et al. Expires February 22, 2021 [Page 6] Internet-Draft BGP for NSH SFC August 2020 Note that the presence of the NSH can make it difficult for nodes in the underlay network to locate the fields in the original packet that would normally be used to constrain equal cost multipath (ECMP) forwarding. Therefore, it is recommended that the node prepending the NSH also provide some form of entropy indicator that can be used in the underlay network. How this indicator is generated and supplied, and how an SFF generates a new entropy indicator when it forwards a packet to the next SFF, are out of scope of this document. The Service Function Forwarder (SFF) receives a packet from the previous node in a Service Function Path, removes the packet's link layer or tunnel encapsulation and hands the packet and the NSH to the Service Function Instance for processing. The SFI has no knowledge of the SFP. When the SFF receives the packet and the NSH back from the SFI it must select the next SFI along the path using the SPI and SI in the NSH and potentially choosing between multiple SFIs (possibly of different Service Function Types) as described in Section 5. In the normal case the SPI remains unchanged and the SI will have been decremented to indicate the next SF along the path. But other possibilities exist if the SF makes other changes to the NSH through a process of re-classification: o The SI in the NSH may indicate: * A previous SF in the path: known as "looping" (see Section 6). * An SF further down the path: known as "jumping" (see also Section 6). o The SPI and the SI may point to an SF on a different SFP: known as "branching" (see also Section 6). Such modifications are limited to within the same service function overlay network. That is, an SPI is known within the scope of service function overlay network. Furthermore, the new SI value is interpreted in the context of the SFP identified by the SPI. As described in [RFC8300], an unknown or invalid SPI is treated as an error and the SFF drops the packet: such errors should be logged, and such logs are subject to rate limits. Also, as described in [RFC8300], an SFF receiving an SI that is unknown in the context of the SPI can reduce the value to the next meaningful SI value in the SFP indicated by the SPI. If no such value exists or if the SFF does not support reducing the SI, the SFF Farrel, et al. Expires February 22, 2021 [Page 7] Internet-Draft BGP for NSH SFC August 2020 drops the packet and should log the event: such logs are also subject to rate limits. The SFF then selects an SFI that provides the SF denoted by the SPI/ SI, and forwards the packet to the SFF that supports that SFI. [RFC8300] makes it clear that the intended scope is for use within a single provider's operational domain. This document adopts the SFC architecture described in [RFC7665] and adds a control plane to support the functions as described in Section 2.2. An essential component of this solution is the Controller. This is a network component responsible for planning SFPs within the network. It gathers information about the availability of SFIs and SFFs, instructs the control plane about the SFPs to be programmed, and instructs the Classifiers how to assign traffic flows to individual SFPs. 2.2. Control Plane Overview To accomplish the function described in Section 2.1, this document introduces the Service Function Type (SFT) that is the category of SF that is supported by an SFF (such as "firewall"). An IANA registry of Service Function Types is introduced in Section 10.5 and is consistent with types used in other work such as [I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs of multiple different SFTs, and may support multiple SFIs of each SF. The registry of SFT values (see Section 10.5) is split into three ranges with assignment policies per [RFC8126]: o The Special Purpose SFT values range is assigned through Standards Action. Values in that range are used for special SFC operations and do not apply to the types of SF that may form part of the SFP. o The First Come First Served range tracks assignments of STF values made by any party that defines an SF type. Reference through an Internet-Draft is desirable, but not required. o The Private Use range is not tracked by IANA and is primarily intended for use in private networks where the meaning of the SFT values is locally tracked and under the control of a local administrator. It is envisaged that the majority of SFT values used will be assigned from the First Come First Served space in the registry. This will ensure interoperability especially in situations where software and hardware from different vendors is deployed in the same networks, or Farrel, et al. Expires February 22, 2021 [Page 8] Internet-Draft BGP for NSH SFC August 2020 when networks are merged. However, operators of private networks may choose to develop their own SFs and manage the configuration and operation of their network through their own list of SFT values. This document also introduces a new BGP AFI/SAFI (values to be assigned by IANA) for "SFC Routes". Two SFC Route Types are defined by this document: the Service Function Instance Route (SFIR), and the Service Function Path Route (SFPR). As detailed in Section 3, the route type is indicated by a sub-field in the Network Layer Reachability Information (NLRI). o The SFIR is advertised by the node that provides access to the service function instance (i.e., the SFF). The SFIR describes a particular instance of a particular Service Function (i.e., an SFI) and the way to forward a packet to it through the underlay network, i.e., IP address and encapsulation information. o The SFPRs are originated by Controllers. One SFPR is originated for each Service Function Path. The SFPR specifies: A. the SPI of the path B. the sequence of SFTs and/or SFIs of which the path consists C. for each such SFT or SFI, the SI that represents it in the identified path. This approach assumes that there is an underlay network that provides connectivity between SFFs and Controllers, and that the SFFs are grouped to form one or more service function overlay networks through which SFPs are built. We assume that the Controllers have BGP connectivity to all SFFs and all Classifiers within each service function overlay network. When choosing the next SFI in a path, the SFF uses the SPI and SI as well as the SFT to choose among the SFIs, applying, for example, a load balancing algorithm or direct knowledge of the underlay network topology as described in Section 4. The SFF then encapsulates the packet using the encapsulation specified by the SFIR of the selected SFI and forwards the packet. See Figure 1. Thus the SFF can be seen as a portal in the underlay network through which a particular SFI is reached. Figure 1 shows a reference model for the SFC architecture. There are four SFFs (SFF-1 through SFF-4) connected by tunnels across the Farrel, et al. Expires February 22, 2021 [Page 9] Internet-Draft BGP for NSH SFC August 2020 underlay network. Packets arrive at a Classifier and are channeled along SFPs to destinations reachable through SFF-4. SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFe). SFF-2 has two types of SF attached: there is one instance of one (SFc), and three instances of the other (SFb). SFF-3 has just one instance of an SF (SFd), but it in this case the type of SFd is the same type as SFb (SFTx). This figure demonstrates how load balancing can be achieved by creating several SFPs that satisfy the same SFC. Suppose an SFC needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs can be constructed using any instance of SFb or using SFd. Load balancing may be applied at two places: o The Classifier may distribute different flows onto different SFPs to share the load in the network and across SFIs. o SFF-2 may distribute different flows (on the same SFP) to different instances of SFb to share the processing load. Note that, for convenience and clarity, Figure 1 shows only a few tunnels between SFFs. There could be a full mesh of such tunnels, or more likely, a selection of tunnels connecting key SFFs to enable the construction of SFPs and to balance load and traffic in the network. Further, the figure does not show any controllers: these would each have BGP connectivity to the Classifier and all of the SFFs. Farrel, et al. Expires February 22, 2021 [Page 10] Internet-Draft BGP for NSH SFC August 2020 Packets | | | ------------ | | | Classifier | | | ------+----- | ---+--- --------- ------- | | Tunnel | | | | | SFF-1 |===============| SFF-2 |=========| SFF-4 | | | | | | | | | -+-----+- | | | | ,,,,,,,,,,,,,,/,, \ | | | | ' .........../. ' ..\...... | | | | ' : SFb / : ' : \ SFc : | | | | ' : ---+- : ' : --+-- : | | | | ' : -| SFI | : ' : | SFI | : | | | | ' : -| ----- : ' : ----- : | | | | ' : | ----- : ' ......... | | | | ' : ----- : ' | | | | ' ............. ' | |--- Dests | | ' ' | |--- Dests | | ' ......... ' | | | | ' : ----- : ' | | | | ' : | SFI | : ' | | | | ' : --+-- : ' | | | | ' :SFd | : ' | | | | ' ....|.... ' | | | | ' | ' | | | | ' SFTx | ' | | | | ',,,,,,,,|,,,,,,,,' | | | | | | | | | ---+--- | | | | | | | | | |======| SFF-3 |====================| | ---+--- | | ---+--- | ------- | ....|.... ....|.... : | SFa: : | SFe: : --+-- : : --+-- : : | SFI | : : | SFI | : : ----- : : ----- : ......... ......... Figure 1: The SFC Architecture Reference Model Farrel, et al. Expires February 22, 2021 [Page 11] Internet-Draft BGP for NSH SFC August 2020 As previously noted, [RFC8300] makes it clear that the mechanisms it defines are intended for use within a single provider's operational domain. This reduces the requirements on the control plane function. [RFC7665] sets out the functions provided by a control plane for an SFC network in Section 5.2. The functions are broken down into six items the first four of which are completely covered by the mechanisms described in this document: 1. Visibility of all SFs and the SFFs through which they are reached. 2. Computation of SFPs and programming into the network. 3. Selection of SFIs explicitly in the SFP or dynamically within the network. 4. Programming of SFFs with forwarding path information. The fifth and six items in the list in RFC 7665 concern the use of metadata. These are more peripheral to the control plane mechanisms defined in this document, but are discussed in Section 4.4. 3. BGP SFC Routes This document defines a new AFI/SAFI for BGP, known as "SFC", with an NLRI that is described in this section. The format of the SFC NLRI is shown in Figure 2. +---------------------------------------+ | Route Type (2 octets) | +---------------------------------------+ | Length (2 octets) | +---------------------------------------+ | Route Type specific (variable) | +---------------------------------------+ Figure 2: The Format of the SFC NLRI The Route Type field determines the encoding of the rest of the route type specific SFC NLRI. The Length field indicates the length in octets of the route type specific field of the SFC NLRI. Farrel, et al. Expires February 22, 2021 [Page 12] Internet-Draft BGP for NSH SFC August 2020 This document defines the following Route Types: 1. Service Function Instance Route (SFIR) 2. Service Function Path Route (SFPR) A Service Function Instance Route (SFIR) is used to identify an SFI. A Service Function Path Route (SFPR) defines a sequence of Service Functions (each of which has at least one instance advertised in an SFIR) that form an SFP. The detailed encoding and procedures for these Route Types are described in subsequent sections. The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC NLRI, encoded as specified above. In order for two BGP speakers to exchange SFC NLRIs, they MUST use BGP Capabilities Advertisements to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI of TBD1 and a SAFI of TBD2. The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST be set to a loopback address of the advertising SFF. 3.1. Service Function Instance Route (SFIR) Figure 3 shows the Route Type specific NLRI of the SFIR. +--------------------------------------------+ | Route Distinguisher (RD) (8 octets) | +--------------------------------------------+ | Service Function Type (2 octets) | +--------------------------------------------+ Figure 3: SFIR Route Type specific NLRI [RFC4364] defines a Route Distinguisher (RD) to consist of a two byte Type field and a six byte Value field and it defines RD types 0, 1, and 2. In this specification, the RD (used for the SFIR) MUST be of type 0, 1, or 2. Farrel, et al. Expires February 22, 2021 [Page 13] Internet-Draft BGP for NSH SFC August 2020 If two SFIRs are originated from different administrative domains (within the same provier's operational domain), they MUST have different RDs. In particular, SFIRs from different VPNs (for different service function overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFIRs. The Service Function Type identifies the functions/features a service function can offer, e.g., Classifier, firewall, load balancer. There may be several SFIs that can perform a given Service Function. Each node hosting an SFI MUST originate an SFIR for each type of SF that it hosts (as indicated by the SFT value), and it MAY advertise an SFIR for each instance of each type of SF. The minimal advertisement allows construction of valid SFPs and leaves the selection of SFIs to the local SFF; the detailed advertisement may have scaling concerns, but allows a Controller that constructs an SFP to make an explicit choice of SFI. Note that a node may advertise all its SFIs of one SFT in one shot using normal BGP Update packing. That is, all of the SFIRs in an Update share a common Tunnel Encapsulation and Route Target (RT) attribute. See also Section 3.2.1. The SFIR representing a given SFI will contain an NLRI with RD field set to an RD as specified above, and with SFT field set to identify that SFI's Service Function Type. The values for the SFT field are taken from a registry administered by IANA (see Section 10). A BGP Update containing one or more SFIRs MUST also include a Tunnel Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be sent to an SFI identified in one of the SFIRs, it will be encapsulated as specified by the Tunnel Encapsulation attribute, and then transmitted through the underlay network. Note that the Tunnel Encapsulation attribute MUST contain sufficient information to allow the advertising SFF to identify the overlay or VPN network which a received packet is transiting. This is because the [SPI, SI] in a received packet is specific to a particular overlay or VPN network. 3.1.1. SFIR Pool Identifier Extended Community This document defines a new transitive extended community [RFC4360] of type TBD6 called the SFC extended community. When used with Sub- Type 1, this is called the SFIR Pool Identifier extended community. It MAY be included in SFIR advertisements, and is used to indicate the identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR may be a member of multiple pools, multiple of these extended communities may be present on a single SFIR advertisement. Farrel, et al. Expires February 22, 2021 [Page 14] Internet-Draft BGP for NSH SFC August 2020 SFIR pools allow SFIRs to be grouped for any purpose. Possible uses include control plane scalability and stability. A pool identifier may be included in an SFPR to indicate a set of SFIs that are acceptable at a specific point on an SFP (see Section 3.2.1.3 and Section 4.3). The SFIR Pool Identifier extended community is encoded in 8 octets as shown in Figure 4. +--------------------------------------------+ | Type = TBD6 (1 octet) | +--------------------------------------------+ | Sub-Type = 1 (1 octet) | +--------------------------------------------+ | SFIR Pool Identifier Value (6 octets) | +--------------------------------------------+ Figure 4: The SFIR Pool Identifier Extended Community The SFIR Pool Identifier Value is encoded in a 6 octet field in network byte order, and the value is unique within the scope of an overlay network. This means that pool identifiers need to be centrally managed, which is consistent with the assignment of SFIs to pools. 3.1.2. MPLS Mixed Swapping/Stacking Extended Community As noted in Section 3.1.1, this document defines a new transitive extended community of type TBD6 called the SFC extended community. When used with Sub-Type 2, this is called the MPLS Mixed Swapping/ Stacking Labels extended community. The community is encoded as shown in Figure 5. It contains a pair of MPLS labels: an SFC Context Label and an SF Label as described in [RFC8595]. Each label is 20 bits encoded in a 3-octet (24 bit) field with 4 trailing bits that MUST be set to zero. Farrel, et al. Expires February 22, 2021 [Page 15] Internet-Draft BGP for NSH SFC August 2020 +--------------------------------------------+ | Type = TBD6 (1 octet) | +--------------------------------------------| | Sub-Type = 2 (1 octet) | +--------------------------------------------| | SFC Context Label (3 octets) | +--------------------------------------------| | SF Label (3 octets) | +--------------------------------------------+ Figure 5: The MPLS Mixed Swapping/Stacking Extended Community Note that it is assumed that each SFF has one or more globally unique SFC Context Labels and that the context label space and the SPI address space are disjoint (i.e., a label value cannot be used both to indicate an SFC context and an SPI, and it can be determined from knowledge of the label spaces whether a label indicates an SFC context or an SPI). If an SFF supports SFP Traversal with an MPLS Label Stack it MUST include this extended community with the SFIRs that it advertises. See Section 7.6 for a description of how this extended community is used. 3.2. Service Function Path Route (SFPR) Figure 6 shows the Route Type specific NLRI of the SFPR. +-----------------------------------------------+ | Route Distinguisher (RD) (8 octets) | +-----------------------------------------------+ | Service Path Identifier (SPI) (3 octets) | +-----------------------------------------------+ Figure 6: SFPR Route Type Specific NLRI [RFC4364] defines a Route Distinguisher (RD) to consist of a two byte Type field and a six byte Value field and it defines RD types 0, 1, and 2. In this specification, the RD (used for the SFPR) MUST be of type 0, 1, or 2. All SFPs MUST be associated with an RD. The association of an SFP with an RD is determined by provisioning. If two SFPRs are originated from different Controllers they MUST have different RDs. Farrel, et al. Expires February 22, 2021 [Page 16] Internet-Draft BGP for NSH SFC August 2020 Additionally, SFPRs from different VPNs (i.e., in different service function overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFPRs. The Service Path Identifier is defined in [RFC8300] and is the value to be placed in the Service Path Identifier field of the NSH header of any packet sent on this Service Function Path. It is expected that one or more Controllers will originate these routes in order to configure a service function overlay network. The SFP is described in a new BGP Path attribute, the SFP attribute. Section 3.2.1 shows the format of that attribute. 3.2.1. The SFP Attribute [RFC4271] defines BGP Path attributes. This document introduces a new Optional Transitive Path attribute called the SFP attribute with value TBD3 to be assigned by IANA. The first SFP attribute MUST be processed and subsequent instances MUST be ignored. The common fields of the SFP attribute are set as follows: o Optional bit is set to 1 to indicate that this is an optional attribute. o The Transitive bit is set to 1 to indicate that this is a transitive attribute. o The Extended Length bit is set if the length of the SFP attribute is encoded in one octet (set to 0) or two octets (set to 1) as described in [RFC4271]. o The Attribute Type Code is set to TBD3. The content of the SFP attribute is a series of Type-Length-Value (TLV) constructs. Some TLVs may include sub-TLVs. All TLVs and sub- TLVs have a common format that is: o Type: A single octet indicating the type of the SFP attribute TLV. Values are taken from the registry described in Section 10.3. o Length: A two octet field indicating the length of the data following the Length field counted in octets. o Value: The contents of the TLV. The formats of the TLVs defined in this document are shown in the following sections. The presence rules and meanings are as follows. Farrel, et al. Expires February 22, 2021 [Page 17] Internet-Draft BGP for NSH SFC August 2020 o The SFP attribute contains a sequence of zero or more Association TLVs. That is, the Association TLV is OPTIONAL. Each Association TLV provides an association between this SFPR and another SFPR. Each associated SFPR is indicated using the RD with which it is advertised (we say the SFPR-RD to avoid ambiguity). o The SFP attribute contains a sequence of one or more Hop TLVs. Each Hop TLV contains all of the information about a single hop in the SFP. o Each Hop TLV contains an SI value and a sequence of one or more SFT TLVs. Each SFT TLV contains an SFI reference for each instance of an SF that is allowed at this hop of the SFP for the specific SFT. Each SFI is indicated using the RD with which it is advertised (we say the SFIR-RD to avoid ambiguity). Section 6 of [RFC4271] describes the handling of malformed BGP attributes, or those that are in error in some way. [RFC7606] revises BGP error handling specifically for the UPDATE message, provides guidelines for the authors of documents defining new attributes, and revises the error handling procedures for a number of existing attributes. This document introduces the SFP attribute and so defines error handling as follows: o When parsing a message, an unknown Attribute Type code or a length that suggests that the attribute is longer than the remaining message is treated as a malformed message and the "treat-as- withdraw" approach used as per [RFC7606]. o When parsing a message that contains an SFP attribute, the following cases constitute errors: 1. Optional bit is set to 0 in SFP attribute. 2. Transitive bit is set to 0 in SFP attribute. 3. Unknown TLV type field found in SFP attribute. 4. TLV length that suggests the TLV extends beyond the end of the SFP attribute. 5. Association TLV contains an unknown SFPR-RD. 6. No Hop TLV found in the SFP attribute. 7. No sub-TLV found in a Hop TLV. 8. Unknown SFIR-RD found in an SFT TLV. Farrel, et al. Expires February 22, 2021 [Page 18] Internet-Draft BGP for NSH SFC August 2020 o The errors listed above are treated as follows: 1., 2., 4., 6., 7.: The attribute MUST be treated as malformed and the "treat-as-withdraw" approach used as per [RFC7606]. 3.: Unknown TLVs MUST be ignored, and message processing MUST continue. 5., 8.: The absence of an RD with which to correlate is nothing more than a soft error. The receiver SHOULD store the information from the SFP attribute until a corresponding advertisement is received. 3.2.1.1. The Association TLV The Association TLV is an optional TLV in the SFP attribute. It MAY be present multiple times. Each occurrence provides an association with another SFP as advertised in another SFPR. The format of the Association TLV is shown in Figure 7 +--------------------------------------------+ | Type = 1 (1 octet) | +--------------------------------------------| | Length (2 octets) | +--------------------------------------------| | Association Type (1 octet) | +--------------------------------------------| | Associated SFPR-RD (8 octets) | +--------------------------------------------| | Associated SPI (3 octets) | +--------------------------------------------+ Figure 7: The Format of the Association TLV The fields are as follows: Type is set to 1 to indicate an Association TLV. Length indicates the length in octets of the Association Type and Associated SFPR-RD fields. The value of the Length field is 12. The Association Type field indicate the type of association. The values are tracked in an IANA registry (see Section 10.4). Only one value is defined in this document: type 1 indicates association of two unidirectional SFPs to form a bidirectional SFP. An SFP attribute SHOULD NOT contain more than one Farrel, et al. Expires February 22, 2021 [Page 19] Internet-Draft BGP for NSH SFC August 2020 Association TLV with Association Type 1: if more than one is present, the first one MUST be processed and subsequent instances MUST be ignored. Note that documents that define new Association Types must also define the presence rules for Association TLVs of the new type. The Associated SFPR-RD contains the RD of the associated SFP as advertised in an SFPR. The Associated SPI contains the SPI of the associated SFP as advertised in an SFPR. Association TLVs with unknown Association Type values SHOULD be ignored. Association TLVs that contain an Associated SFPR-RD value equal to the RD of the SFPR in which they are contained SHOULD be ignored. If the Associated SPI is not equal to the SPI advertised in the SFPR indicated by the Associated SFPR-RD then the Association TLV SHOULD be ignored. In all three of these cases an implementation MAY reject the SFP attribute as malformed and use the "treat-as-withdraw" approach per [RFC7606], however implementers are cautioned that such an approach may make an implementation less flexible in the event of future extensions to this protocol. Note that when two SFPRs reference each other using the Association TLV, one SFPR advertisement will be received before the other. Therefore, processing of an association MUST NOT be rejected simply because the Associated SFPR-RD is unknown. Further discussion of correlation of SFPRs is provided in Section 7.1. 3.2.1.2. The Hop TLV There is one Hop TLV in the SFP attribute for each hop in the SFP. The format of the Hop TLV is shown in Figure 8. At least one Hop TLV MUST be present in an SFP attribute. Farrel, et al. Expires February 22, 2021 [Page 20] Internet-Draft BGP for NSH SFC August 2020 +--------------------------------------------+ | Type = 2 (1 octet) | +--------------------------------------------| | Length (2 octets) | +--------------------------------------------| | Service Index (1 octet) | +--------------------------------------------| | Hop Details (variable) | +--------------------------------------------+ Figure 8: The Format of the Hop TLV The fields are as follows: Type is set to 2 to indicate a Hop TLV. Length indicates the length in octets of the Service Index and Hop Details fields. The Service Index is defined in [RFC8300] and is the value found in the Service Index field of the NSH header that an SFF will use to lookup to which next SFI a packet is to be sent. The Hop Details field consists of a sequence of one or more sub- TLVs. Each hop of the SFP may demand that a specific type of SF is executed, and that type is indicated in sub-TLVs of the Hop TLV. At least one sub-TLV MUST be present. This document defines the SFT Sub-TLV (see Section 3.2.1.3 and the MPLS Swapping/Stacking Sub-TLV (see Section Section 3.2.1.4: other sub-TLVs may be defined in future. This provides a list of which types of SF are acceptable at a specific hop, and for each type it allows a degree of control to be imposed on the choice of SFIs of that particular type. If no Hop TLV is present in an SFP Attribute, it is a malformed attribute 3.2.1.3. The SFT Sub-TLV The SFT Sub-TLV MAY be included in the list of sub-TLVs of the Hop TLV. The format of the SFT Sub-TLV is shown in Figure 9. The Sub- TLV contains a list of SFIR-RD values each taken from the advertisement of an SFI. Together they form a list of acceptable SFIs of the indicated type. Farrel, et al. Expires February 22, 2021 [Page 21] Internet-Draft BGP for NSH SFC August 2020 +--------------------------------------------+ | Type = 3 (1 octet) | +--------------------------------------------| | Length (2 octets) | +--------------------------------------------| | Service Function Type (2 octets) | +--------------------------------------------| | SFIR-RD List (variable) | +--------------------------------------------+ Figure 9: The Format of the SFT Sub-TLV The fields are as follows: Type is set to 3 to indicate an SFT Sub-TLV. Length indicates the length in octets of the Service Function Type and SFIR-RD List fields. The Service Function Type value indicates the category (type) of SF that is to be executed at this hop. The types are as advertised for the SFs supported by the SFFs. SFT values in the range 1-31 are Special Purpose SFT values and have meanings defined by the documents that describe them - the value 'Change Sequence' is defined in Section 6.1 of this document. The hop description is further qualified beyond the specification of the SFTs by listing, for each SFT in each hop, the SFIs that may be used at the hop. The SFIs are identified using the SFIR- RDs from the advertisements of the SFIs in the SFIRs. Note that if the list contains one or more SFIR Pool Identifiers, then for each the SFIR-RD list is effectively expanded to include the SFIR- RD of each SFIR advertised with that SFIR Pool Identifier. An SFIR-RD of value zero has special meaning as described in Section 5. Each entry in the list is eight octets long, and the number of entries in the list can be deduced from the value of the Length field. Note that an SFIR-RD is of type 0, 1, or 2 (as described in Section 3.1. Thus the high order octet of an RD found in an SFIR- RD List always has a value of 0x00. However, the high order octet of an SFIR Pool Identifier (an extended community with Type field TBD6), will always have a non-zero value. This allows the node processing the SFIR-RD List to distinguish between the two types of list entry. Farrel, et al. Expires February 22, 2021 [Page 22] Internet-Draft BGP for NSH SFC August 2020 3.2.1.4. MPLS Swapping/Stacking Sub-TLV The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length sub-TLV that is OPTIONAL in the Hop TLV and is used when the data representation is MPLS (see Section 7.5). When present it indicates to the Classifier imposing an MPLS label stack that the current hop is to use an {SFC Context Label, SF label} rather than an {SPI, SF} label pair. See Section 7.6 for more details. 3.2.1.5. SFP Traversal With MPLS Label Stack TLV The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero length TLV that can be carried in the SFP Attribute and indicates to the Classifier and the SFFs on the SFP that an MPLS label stack with label swapping/stacking is to be used for packets traversing the SFP. All of the SFFs specified at each of the SFP's hops MUST have advertised an MPLS Mixed Swapping/Stacking Extended Community (see Section 3.1.2) for the SFP to be considered usable. 3.2.2. General Rules For The SFP Attribute It is possible for the same SFI, as described by an SFIR, to be used in multiple SFPRs. When two SFPRs have the same SPI but different SFPR-RDs there can be three cases: o Two or more Controllers are originating SFPRs for the same SFP. In this case the content of the SFPRs is identical and the duplication is to ensure receipt and to provide Controller redundancy. o There is a transition in content of the advertised SFP and the advertisements may originate from one or more Controllers. In this case the content of the SFPRs will be different. o The reuse of an SPI may result from a configuration error. In all cases, there is no way for the receiving SFF to know which SFPR to process, and the SFPRs could be received in any order. At any point in time, when multiple SFPRs have the same SPI but different SFPR-RDs, the SFF MUST use the SFPR with the numerically lowest SFPR-RD when interpreting the RDs as 8-octet integers in network byte order. The SFF SHOULD log this occurrence to assist with debugging. Furthermore, a Controller that wants to change the content of an SFP is RECOMMENDED to use a new SPI and so create a new SFP onto which Farrel, et al. Expires February 22, 2021 [Page 23] Internet-Draft BGP for NSH SFC August 2020 the Classifiers can transition packet flows before the SFPR for the old SFP is withdrawn. This avoids any race conditions with SFPR advertisements. Additionally, a Controller SHOULD NOT re-use an SPI after it has withdrawn the SFPR that used it until at least a configurable amount of time has passed. This timer SHOULD have a default of one hour. 4. Mode of Operation This document describes the use of BGP as a control plane to create and manage a service function overlay network. 4.1. Route Targets The main feature introduced by this document is the ability to create multiple service function overlay networks through the use of Route Targets (RTs) [RFC4364]. Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. The RT carried by a particular SFIR or SFPR is determined by the provisioning of the route's originator. Every node in a service function overlay network is configured with one or more import RTs. Thus, each SFF will import only the SFPRs with matching RTs allowing the construction of multiple service function overlay networks or the instantiation of Service Function Chains within an Layer 3 Virtual Private Network (L3VPN) or Ethernet VPN (EVPN) instance (see Section 7.3). An SFF that has a presence in multiple service function overlay networks (i.e., imports more than one RT) will usually maintain separate forwarding state for each overlay network. 4.2. Service Function Instance Routes The SFIR (see Section 3.1) is used to advertise the existence and location of a specific Service Function Instance and consists of: o The RT as just described. o A Service Function Type (SFT) that is the type of service function that is provided (such as "firewall"). o A Route Distinguisher (RD) that is unique to a specific overlay. Farrel, et al. Expires February 22, 2021 [Page 24] Internet-Draft BGP for NSH SFC August 2020 4.3. Service Function Path Routes The SFPR (see Section 3.2) describes a specific path of a Service Function Chain. The SFPR contains the Service Path Identifier (SPI) used to identify the SFP in the NSH in the data plane. It also contains a sequence of Service Indexes (SIs). Each SI identifies a hop in the SFP, and each hop is a choice between one of more SFIs. As described in this document, each Service Function Path Route is identified in the service function overlay network by an RD and an SPI. The SPI is unique within a single VPN instance supported by the underlay network. The SFPR advertisement comprises: o An RT as described in Section 4.1. o A tuple that identifies the SFPR * An RD that identifies an advertisement of an SFPR. * The SPI that uniquely identifies this path within the VPN instance distinguished by the RD. This SPI also appears in the NSH. o A series of Service Indexes. Each SI is used in the context of a particular SPI and identifies one or more SFs (distinguished by their SFTs) and for each SF a set of SFIs that instantiate the SF. The values of the SI indicate the order in which the SFs are to be executed in the SFP that is represented by the SPI. o The SI is used in the NSH to identify the entries in the SFP. Note that the SI values have meaning only relative to a specific path. They have no semantic other than to indicate the order of Service Functions within the path and are assumed to be monotonically decreasing from the start to the end of the path [RFC8300]. o Each Service Index is associated with a set of one or more Service Function Instances that can be used to provide the indexed Service Function within the path. Each member of the set comprises: * The RD used in an SFIR advertisement of the SFI. * The SFT that indicates the type of function as used in the same SFIR advertisement of the SFI. Farrel, et al. Expires February 22, 2021 [Page 25] Internet-Draft BGP for NSH SFC August 2020 This may be summarized as follows where the notations "SFPR-RD" and "SFIR-RD" are used to distinguish the two different RDs, and where "*" indicates a multiplier: RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } Where: RT: Route Target SFPR-RD: The Route Descriptor of the Service Function Path Route advertisement SPI: Service Path Identifier used in the NSH m: The number of hops in the Service Function Path n: The number of choices of Service Function Type for a specific hop p: The number of choices of Service Function Instance for given Service Function Type in a specific hop SI: Service Index used in the NSH to indicate a specific hop SFT: The Service Function Type used in the same advertisement of the Service Function Instance Route SFIR-RD: The Route Descriptor used in an advertisement of the Service Function Instance Route That is, there can be multiple SFTs at a given hop as described in Section 5. Note that the values of SI are from the set {255, ..., 1} and are monotonically decreasing within the SFP. SIs MUST appear in order within the SFPR (i.e., monotonically decreasing) and MUST NOT appear more than once. Gaps MAY appear in the sequence as described in Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR Pool identifiers, then in the above expression, 'p' is the sum of the number of individual SFIR-RD values and the sum for each SFIR Pool Identifier of the number of SFIRs advertised with that SFIR Pool Identifier. I.e., the list of SFIR-RD values is effectively expanded to include the SFIR-RD of each SFIR advertised with each SFIR Pool Identifier in the SFIR-RD list. Farrel, et al. Expires February 22, 2021 [Page 26] Internet-Draft BGP for NSH SFC August 2020 The choice of SFI is explained further in Section 5. Note that an SFIR-RD value of zero has special meaning as described in that Section. 4.4. Classifier Operation As shown in Figure 1, the Classifier is a component that is used to assign packets to an SFP. The Classifier is responsible for determining to which packet flow a packet belongs. The mechanism it uses to achieve that classification is out of scope of this document, but might include inspection of the packet header. The Classifier has been instructed (by the Controller or through some other configuration mechanism - see Section 7.4) which flows are to be assigned to which SFPs, and so it can impose an NSH on each packet and initialize the NSH with the SPI of the selected SFP and the SI of its first hop. Note that instructions delivered to the Classifier may include information about the metadata to encode (and the format for that encoding) on packets that are classified by the Classifier to a particular SFP. As mentioned in Section 2.2, this corresponds to the fifth element of control plane functionality described in [RFC7665]. Such instructions fall outside the scope of this specification (although, see Section 7.4), as do instructions to other SFC elements on how to interpret metadata (as described in the sixth element of control plane functionality described in [RFC7665]. 4.5. Service Function Forwarder Operation Each packet sent to an SFF is transmitted encapsulated in an NSH. The NSH includes an SPI and SI: the SPI indicates the SFPR advertisement that announced the Service Function Path; the tuple SPI/SI indicates a specific hop in a specific path and maps to the RD/SFT of a particular SFIR advertisement. When an SFF gets an SFPR advertisement it will first determine whether to import the route by examining the RT. If the SFPR is imported the SFF then determines whether it is on the SFP by looking for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR. For each occurrence in the SFP, the SFF creates forwarding state for incoming packets and forwarding state for outgoing packets that have been processed by the specified SFI. The SFF creates local forwarding state for packets that it receives from other SFFs. This state makes the association between the SPI/SI in the NSH of the received packet and one or more specific local SFIs as identified by the SFIR-RD/SFT. If there are multiple local SFIs Farrel, et al. Expires February 22, 2021 [Page 27] Internet-Draft BGP for NSH SFC August 2020 that match this is because a single advertisement was made for a set of equivalent SFIs and the SFF may use local policy (such as load balancing) to determine to which SFI to forward a received packet. The SFF also creates next hop forwarding state for packets received back from the local SFI that need to be forwarded to the next hop in the SFP. There may be a choice of next hops as described in Section 4.3. The SFF could install forwarding state for all potential next hops, or it could choose to only install forwarding state to a subset of the potential next hops. If a choice is made then it will be as described in Section 5. The installed forwarding state may change over time reacting to changes in the underlay network and the availability of particular SFIs. Note that the forwarding state describes how one SFF send packets to another SFF, but not how those packets are routed through the underlay network. SFFs may be connected by tunnels across the underlay, or packets may be sent addressed to the next SFF and routed through the underlay. In any case, transmission across the underlay requires encapsulation of packets with a header for transport in the underlay network. Note that SFFs only create and store forwarding state for the SFPs on which they are included. They do not retain state for all SFPs advertised. An SFF may also install forwarding state to support looping, jumping, and branching. The protocol mechanism for explicit control of looping, jumping, and branching uses a specific reserved SFT value at a given hop of an SFPR and is described in Section 6.1. 4.5.1. Processing With 'Gaps' in the SI Sequence The behavior of an SF as described in [RFC8300] is to decrement the value of the SI field in the NSH by one before returning a packet to the local SFF for further processing. This means that there is a good reason to assume that the SFP is composed of a series of SFs each indicated by an SI value one less than the previous. However, there is an advantage to having non-successive SIs in an SPI. Consider the case where an SPI needs to be modified by the insertion or removal of an SF. In the latter case this would lead to a "gap" in the sequence of SIs, and in the former case, this could only be achieved if a gap already existed into which the new SF with its new SI value could be inserted. Otherwise, all "downstream" SFs would need to be renumbered. Farrel, et al. Expires February 22, 2021 [Page 28] Internet-Draft BGP for NSH SFC August 2020 Now, of course, such renumbering could be performed, but would lead to a significant disruption to the SFC as all the SFFs along the SFP were "reprogrammed". Thus, to achieve dynamic modification of an SFP (and even, in-service modification) it is desirable to be able to make these modifications without changing the SIs of the elements that were present before the modification. This will produce much more consistent/predictable behavior during the convergence period where otherwise the change would need to be fully propagated. Another approach says that any change to an SFP simply creates a new SFP that can be assigned a new SPI. All that would be needed would be to give a new instruction to the Classifier and traffic would be switched to the new SFP that contains the new set of SFs. This approach is practical, but neglects to consider that the SFP may be referenced by other SFPs (through "branch" instructions) and used by many Classifiers. In those cases the corresponding configuration resulting from a change in SPI may have wide ripples and give scope for errors that are hard to trace. Therefore, while this document requires that the SI values in an SFP are monotonic decreasing, it makes no assumption that the SI values are sequential. Configuration tools may apply that rule, but they are not required to. To support this, an SFF SHOULD process as follows when it receives a packet: o If the SI indicates a known entry in the SFP, the SFF MUST process the packet as normal, looking up the SI and determining to which local SFI to deliver the packet. o If the SI does not match an entry in the SFP, the SFF MUST reduce the SI value to the next (smaller) value present in the SFP and process the packet using that SI. o If there is no smaller SI (i.e., if the end of the SFP has been reached) the SFF MUST treat the SI value as invalid as described in [RFC8300]. This makes the behavior described in this document a superset of the function in [RFC8300]. That is, an implementation that strictly follows RFC 8300 in performing SI decrements in units of one, is perfectly in line with the mechanisms defined in this document. SFF implementations MAY choose to only support contiguous SI values in an SFP. Such an implementation will not support receiving an SI value that is not present in the SFP and will discard the packets as described in [RFC8300]. Farrel, et al. Expires February 22, 2021 [Page 29] Internet-Draft BGP for NSH SFC August 2020 5. Selection within Service Function Paths As described in Section 2 the SPI/SI in the NSH passed back from an SFI to the SFF may leave the SFF with a choice of next hop SFTs, and a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR. Each entry in an SFPR is a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of these, identify the SFF that supports the chosen SFI, and send the packet to that next hop SFF. The choice be may offered for load balancing across multiple SFIs, or for discrimination between different actions necessary at a specific hop in the SFP. Different SFT values may exist at a given hop in an SFP to support several cases: o There may be multiple instances of similar service functions that are distinguished by different SFT values. For example, firewalls made by vendor A and vendor B may need to be identified by different SFT values because, while they have similar functionality, their behavior is not identical. Then, some SFPs may limit the choice of SF at a given hop by specifying the SFT for vendor A, but other SFPs might not need to control which vendor's SF is used and so can indicate that either SFT can be used. o There may be an obvious branch needed in an SFP such as the processing after a firewall where admitted packets continue along the SFP, but suspect packets are diverted to a "penalty box". In this case, the next hop in the SFP will be indicated with two different SFT values. In the typical case, the SFF chooses a next hop SFF by looking at the set of all SFFs that support the SFs identified by the SI (that set having been advertised in individual SFIR advertisements), finding the one or more that are "nearest" in the underlay network, and choosing between next hop SFFs using its own load-balancing algorithm. An SFI may influence this choice process by passing additional information back along with the packet and NSH. This information may influence local policy at the SFF to cause it to favor a next hop SFF (perhaps selecting one that is not nearest in the underlay), or to influence the load-balancing algorithm. This selection applies to the normal case, but also applies in the case of looping, jumping, and branching (see Section 6). Farrel, et al. Expires February 22, 2021 [Page 30] Internet-Draft BGP for NSH SFC August 2020 Suppose an SFF in a particular service overlay network (identified by a particular import RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y. It does the following: 1. It looks for an installed SFPR that carries RT-z and that has SPI-x in its NLRI. If there is none, then such packets cannot be forwarded. 2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI value set to SI-y. If there is no such Hop TLV, then such packets cannot be forwarded. 3. It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs contained in the Hop TLV as follows: A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI matches the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches an entry in the list of SFIR-RDs in that SFT TLV. B. If an entry in the SFIR-RD list of an SFT TLV contains the value zero, then an SFIR is relevant if it carries RT-z and the SFT in its NLRI matches the SFT value in that SFT TLV. I.e., any SFIR in the service function overlay network defined by RT-z and with the correct SFT is relevant. C. If a pool identifier is in use then an SFIR is relevant if it is a member of the pool. Each of the relevant SFIRs identifies a single SFI, and contains a Tunnel Encapsulation attribute that specifies how to send a packet to that SFI. For a particular packet, the SFF chooses a particular SFI from the set of relevant SFIRs. This choice is made according to local policy. A typical policy might be to figure out the set of SFIs that are closest, and to load balance among them. But this is not the only possible policy. Thus, at any point in time when an SFF selects its next hop, it chooses from the intersection of the set of next hop RDs contained in the SFPR and the RDs contained in the SFF's local set of SFIRs (i.e., according to the determination of "relevance", above). If the intersection is null, the SFPR is unusable. Similarly, when this condition applies on the Controller that originated the SFPR, it SHOULD either withdraw the SFPR or re-advertise it with a new set of RDs for the affected hop. Farrel, et al. Expires February 22, 2021 [Page 31] Internet-Draft BGP for NSH SFC August 2020 6. Looping, Jumping, and Branching As described in Section 2 an SFI or an SFF may cause a packet to "loop back" to a previous SF on a path in order that a sequence of functions may be re-executed. This is simply achieved by replacing the SI in the NSH with a higher value instead of decreasing it as would normally be the case to determine the next hop in the path. Section 2 also describes how an SFI or an SFF may cause a packets to "jump forward" to an SF on a path that is not the immediate next SF in the SFP. This is simply achieved by replacing the SI in the NSH with a lower value than would be achieved by decreasing it by the normal amount. A more complex option to move packets from one SFP to another is described in [RFC8300] and Section 2 where it is termed "branching". This mechanism allows an SFI or SFF to make a choice of downstream treatments for packets based on local policy and output of the local SF. Branching is achieved by changing the SPI in the NSH to indicate the new path and setting the SI to indicate the point in the path at which the packets enter. Note that the NSH does not include a marker to indicate whether a specific packet has been around a loop before. Therefore, the use of NSH metadata ([RFC8300]) may be required in order to prevent infinite loops. 6.1. Protocol Control of Looping, Jumping, and Branching If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT value "Change Sequence" (see Section 10) then this is an indication that the SFF may make a loop, jump, or branch according to local policy and information returned by the local SFI. In this case, the SPI and SI of the next hop are encoded in the eight bytes of an entry in the SFIR-RD list as follows: 3 bytes SPI 1 bytes SI 4 bytes Reserved (SHOULD be set to zero and ignored) If the SI in this encoding is not part of the SFPR indicated by the SPI in this encoding, then this is an explicit error that SHOULD be detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT cause any forwarding state to be installed in the SFF and packets Farrel, et al. Expires February 22, 2021 [Page 32] Internet-Draft BGP for NSH SFC August 2020 received with the SPI that indicates this SFPR SHOULD be silently discarded. If the SPI in this encoding is unknown, the SFF SHOULD NOT install any forwarding state for this SFPR, but MAY hold the SFPR pending receipt of another SFPR that does use the encoded SPI. If the SPI matches the current SPI for the path, this is a loop or jump. In this case, if the SI is greater than to the current SI it is a loop. If the SPI matches and the SI is less than the next SI, it is a jump. If the SPI indicates another path, this is a branch and the SI indicates the point at which to enter that path. The Change Sequence SFT is just another SFT that may appear in a set of SFI/SFT tuples within an SI and is selected as described in Section 5. Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. If such an SFIR is received it SHOULD be ignored. 6.2. Implications for Forwarding State Support for looping and jumping requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate SF. This means that the SFF must have seen the relevant SFIR advertisements and known that it needed to create the forwarding state. This is a matter of local configuration and implementation: for example, an implementation could be configured to install forwarding state for specific looping/jumping. Support for branching requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate entry SF on the other SFP. This means that the SFF must have seen the relevant SFIR and SFPR advertisements and known that it needed to create the forwarding state. This is a matter of local configuration and implementation: for example, an implementation could be configured to install forwarding state for specific branching (identified by SPI and SI). 7. Advanced Topics This section highlights several advanced topics introduced elsewhere in this document. Farrel, et al. Expires February 22, 2021 [Page 33] Internet-Draft BGP for NSH SFC August 2020 7.1. Correlating Service Function Path Instances It is often useful to create bidirectional SFPs to enable packet flows to traverse the same set of SFs, but in the reverse order. However, packets on SFPs in the data plane (per [RFC8300]) do not contain a direction indicator, so each direction must use a different SPI. As described in Section 3.2.1.1 an SFPR can contain one or more correlators encoded in Association TLVs. If the Association Type indicates "Bidirectional SFP" then the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs where the other in the pair is advertised in the SFPR with RD as carried in the Associated SFPR-RD field of the Association TLV. The SPI carried in the Associated SPI field of the Association TLV provides a cross-check against the SPI advertised in the SFPR with RD as carried in the Associated SFPR-RD field of the Association TLV. As noted in Section 3.2.1.1, when SFPRs reference each other, one SFPR advertisement will be received before the other. Therefore, processing of an association will require that the first SFPR is not rejected simply because the Associated SFPR-RD it carries is unknown. However, the SFP defined by the first SFPR is valid and SHOULD be available for use as a unidirectional SFP even in the absence of an advertisement of its partner. Furthermore, in error cases where SFPR-a associates with SFPR-b, but SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs cannot be formed, the individual SFPs are still valid and SHOULD be available for use as unidirectional SFPs. An implementation SHOULD log this situation because it represents a Controller error. Usage of a bidirectional SFP may be programmed into the Classifiers by the Controller. Alternatively, a Classifier may look at incoming packets on a bidirectional packet flow, extract the SPI from the received NSH, and look up the SFPR to find the reverse direction SFP to use when it sends packets. See Section 8 for an example of how this works. 7.2. Considerations for Stateful Service Functions Some service functions are stateful. That means that they build and maintain state derived from configuration or from the packet flows that they handle. In such cases it can be important or necessary that all packets from a flow continue to traverse the same instance of a service function so that the state can be leveraged and does not need to be regenerated. Farrel, et al. Expires February 22, 2021 [Page 34] Internet-Draft BGP for NSH SFC August 2020 In the case of bidirectional SFPs, it may be necessary to traverse the same instances of a stateful service function in both directions. A firewall is a good example of such a service function. This issue becomes a concern where there are multiple parallel instances of a service function and a determination of which one to use could normally be left to the SFF as a load-balancing or local policy choice. For the forward direction SFP, the concern is that the same choice of service function is made for all packets of a flow under normal network conditions. It may be possible to guarantee that the load balancing functions applied in the SFFs are stable and repeatable, but a Controller that constructs SFPs might not want to trust to this. The Controller can, in these cases, build a number of more specific SFPs each traversing a specific instance of the stateful SFs. In this case, the load balancing choice can be left up to the Classifier. Thus the Classifier selects which instance of a stateful SF is used by a particular flow by selecting the SFP that the flow uses. For bidirectional SFPs where the same instance of a stateful SF must be traversed in both directions, it is not enough to leave the choice of service function instance as a local choice even if the load balancing is stable because coordination would be required between the decision points in the forward and reverse directions and this may be hard to achieve in all cases except where it is the same SFF that makes the choice in both directions. Note that this approach necessarily increases the amount of SFP state in the network (i.e., there are more SFPs). It is possible to mitigate this effect by careful construction of SFPs built from a concatenation of other SFPs. Section 8.9 includes some simple examples of SFPs for stateful service functions. 7.3. VPN Considerations and Private Service Functions Likely deployments include reserving specific instances of Service Functions for specific customers or allowing customers to deploy their own Service Functions within the network. Building Service Functions in such environments requires that suitable identifiers are used to ensure that SFFs distinguish which SFIs can be used and which cannot. Farrel, et al. Expires February 22, 2021 [Page 35] Internet-Draft BGP for NSH SFC August 2020 This problem is similar to how VPNs are supported and is solved in a similar way. The RT field is used to indicate a set of Service Functions from which all choices must be made. 7.4. Flow Specification for SFC Classifiers [I-D.ietf-idr-rfc5575bis] defines a set of BGP routes that can be used to identify the packets in a given flow using fields in the header of each packet, and a set of actions, encoded as extended communities, that can be used to disposition those packets. This document enables the use of these mechanisms by SFC Classifiers by defining a new action extended community called "Flow Specification for SFC Classifiers" identified by the value TBD4. Note that implementation of this section of this specification will be Controllers or Classifiers communicating with each other directly for the purpose of instructing the Classifier how to place packets onto an SFP. In order that the implementation of Classifiers can be kept simple and to avoid the confusion between the purpose of different extended communities, a Controller MUST NOT include other action extended communities at the same time as a "Flow Specification for SFC Classifiers" extended community: a "Flow Specification for SFC Classifiers" Traffic Filtering Action Extended Community advertised with any other Traffic Filtering Action Extended Community MUST be treated as malformed in line with [I-D.ietf-idr-rfc5575bis] and result in the Flow Specification UPDATE message being handled as treat-as-withdraw according to [RFC7606] Section 2. To put the Flow Specification into context when multiple SFC overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network for which it is intended. This extended community is encoded as an 8-octet value, as shown in Figure 10. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x80 | Sub-Type=TBD4 | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont.) | SI | SFT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: The Format of the Flow Specification for SFC Classifiers Extended Community Farrel, et al. Expires February 22, 2021 [Page 36] Internet-Draft BGP for NSH SFC August 2020 The extended community contains the Service Path Identifier (SPI), Service Index (SI), and Service Function Type (SFT) as defined elsewhere in this document. Thus, each action extended community defines the entry point (not necessarily the first hop) into a specific service function path. This allows, for example, different flows to enter the same service function path at different points. Note that according to [I-D.ietf-idr-rfc5575bis] a given Flow Specification update may include multiple of these action extended communities. If a given action extended community does not contain an installed SFPR with the specified {SPI, SI, SFT} it MUST NOT be used for dispositioning the packets of the specified flow. The normal case of packet classification for SFC will see a packet enter the SFP at its first hop. In this case the SI in the extended community is superfluous and the SFT may also be unnecessary. To allow these cases to be handled, a special meaning is assigned to a Service Index of zero (not a valid value) and an SFT of zero (a reserved value in the registry - see Section 10.5). o If an SFC Classifiers Extended Community is received with SI = 0 then it means that the first hop of the SFP indicated by the SPI MUST be used. o If an SFC Classifiers Extended Community is received with SFT = 0 then there are two sub-cases: * If there is a choice of SFT in the hop indicated by the value of the SI (including SI = 0) then SFT = 0 means there is a free choice according to local policy of which SFT to use). * If there is no choice of SFT in the hop indicated by the value of SI, then SFT = 0 means that the value of the SFT at that hop as indicated in the SFPR for the indicated SPI MUST be used. One of the filters that the Flow Specification may describe is the VPN to which the traffic belongs. Additionally, as noted above, to put the indicated SPI into context when multiple SFC overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network for which it is intended. Note that future extensions might be made to the Flow Specification for SFC Classifiers Extended Community to provide instruction to the Classifier about what metadata to add to packets that it classifies for forwarding on a specific SFP, but that is outside the scope of this document. Farrel, et al. Expires February 22, 2021 [Page 37] Internet-Draft BGP for NSH SFC August 2020 7.5. Choice of Data Plane SPI/SI Representation This document ties together the control and data planes of an SFC overlay network through the use of the SPI/SI which is nominally carried in the NSH of a given packet. However, in order to handle situations in which the NSH is not ubiquitously deployed, it is also possible to use alternative data plane representations of the SPI/SI by carrying the identical semantics in other protocol fields such as MPLS labels [RFC8595]. This document defines a new sub-TLV for the Tunnel Encapsulation attribute [I-D.ietf-idr-tunnel-encaps], the SPI/SI Representation sub-TLV of type TBD5. This sub-TLV MAY be present in each Tunnel TLV contained in a Tunnel Encapsulation attribute when the attribute is carried by an SFIR. The value field of this sub-TLV is a two octet field of flags numbered counting from the the most significant bit, each of which describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets carried in the tunnels described by the Tunnel TLV. The following bits are defined by this document and are tracked in an IANA registry described in Section 10.10: Bit TBD9: If this bit is set the NSH is to be used to carry the SPI/ SI in the data plane. Bit TBD10: If this bit is set two labels in an MPLS label stack are to be used as described in Section 7.5.1. If a given Tunnel TLV does not contain an SPI/SI Representation sub- TLV then it MUST be processed as if such a sub-TLV is present with Bit TBD9 set and no other bits set. That is, the absence of the sub- TLV SHALL be interpreted to mean that the NSH is to be used. If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with value field that has no flag set then the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit TBD9 and bit TBD10 set then the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding SFC packets. The meaning and rules for presence of other bits is to be defined in future documents, but implementations of this specification MUST set other bits to zero and ignore them on receipt. If a given Tunnel TLV contains more than one SPI/SI Representation sub-TLV then the first one MUST be considered and subsequent instances MUST be ignored. Farrel, et al. Expires February 22, 2021 [Page 38] Internet-Draft BGP for NSH SFC August 2020 Note that the MPLS representation of the logical NSH may be used even if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself). It is a requirement that both ends of a tunnel over the underlay network know that the tunnel is used for SFC and know what form of NSH representation is used. The signaling mechanism described here allows coordination of this information. 7.5.1. MPLS Representation of the SPI/SI If bit TBD10 is set in the in the SPI/SI Representation sub-TLV then labels in the MPLS label stack are used to indicate SFC forwarding and processing instructions to achieve the semantics of a logical NSH. The label stack is encoded as shown in [RFC8595]. 7.6. MPLS Label Swapping/Stacking Operation When a Classifier constructs an MPLS label stack for an SFP it starts with that SFP's last hop. If the last hop requires an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the last hop) and the SFP's SPI onto the MPLS label stack. If the last hop requires a {context label, SFI label} label pair for label stacking it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack. The Classifier then moves sequentially back through the SFP one hop at a time. For each hop, if the hop requires an {SPI, SI]} and there is an {SPI, SI} at the top of the MPLS label stack, the SI is set to the SI value of the current hop. If there is not an {SPI, SI} at the top of the MPLS label stack, it pushes the SI (set to the SI value of the current hop) and the SFP's SPI onto the MPLS label stack. If the hop requires a {context label, SFI label}, it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack. 7.7. Support for MPLS-Encapsulated NSH Packets [RFC8596] describes how to transport SFC packets using the NSH over an MPLS transport network. Signaling MPLS encapsulation of SFC packets using the NSH is also supported by this document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with bit TBD9 set and bit TBD10 cleared. Farrel, et al. Expires February 22, 2021 [Page 39] Internet-Draft BGP for NSH SFC August 2020 In this case the MPLS label stack constructed by the SFF to forward a packet to the next SFF on the SFP will consist of the labels needed to reach that SFF, and if label stacking is used it will also include the labels advertised in the MPLS Label Stack sub-TLV and the labels remaining in the stack needed to traverse the remainder of the SFP. 8. Examples Most of the examples in this section use IPv4 addressing. But there is nothing special about IPv4 in the mechanisms described in this document, and they are equally applicable to IPv6. A few examples using IPv6 addressing are provided in Section 8.10. Assume we have a service function overlay network with four SFFs (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the underlay network as follows: SFF1 192.0.2.1 SFF2 192.0.2.2 SFF3 192.0.2.3 SFF4 192.0.2.4 Each SFF provides access to some SFIs from the four Service Function Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: SFF1 SFT=41 and SFT=42 SFF2 SFT=41 and SFT=43 SFF3 SFT=42 and SFT=44 SFF4 SFT=43 and SFT=44 The service function network also contains a Controller with address 198.51.100.1. This example service function overlay network is shown in Figure 11. Farrel, et al. Expires February 22, 2021 [Page 40] Internet-Draft BGP for NSH SFC August 2020 -------------- | Controller | | 198.51.100.1 | ------ ------ ------ ------ -------------- | SFI | | SFI | | SFI | | SFI | |SFT=41| |SFT=42| |SFT=41| |SFT=43| ------ ------ ------ ------ \ / \ / --------- --------- ---------- | SFF1 | | SFF2 | Packet --> | | |192.0.2.1| |192.0.2.2| Flows --> |Classifier| --------- --------- -->Dest | | --> ---------- --------- --------- | SFF3 | | SFF4 | |192.0.2.3| |192.0.2.4| --------- --------- / \ / \ ------ ------ ------ ------ | SFI | | SFI | | SFI | | SFI | |SFT=42| |SFT=44| |SFT=43| |SFT=44| ------ ------ ------ ------ Figure 11: Example Service Function Overlay Network The SFFs advertise routes to the SFIs they support. These advertisements contain Route Distinguishers that are set according to the network operator's configuration model. In all of these IPv4 examples we use RDs of type 1 such that the available six octets are partitioned as four octets for the IPv4 address of the advertising SFF, and two octets that are a local index of the SFI. This scheme is chosen purely for convenience of documentation, and an operator is totally free to use any other scheme so long as it conforms to the definitions of SFIR and SFPR in Section 3.1 and Section 3.2. Thus we see the following SFIRs advertised: RD = 192.0.2.1/1, SFT = 41 RD = 192.0.2.1/2, SFT = 42 RD = 192.0.2.2/1, SFT = 41 RD = 192.0.2.2/2, SFT = 43 RD = 192.0.2.3/7, SFT = 42 RD = 192.0.2.3/8, SFT = 44 RD = 192.0.2.4/5, SFT = 43 RD = 192.0.2.4/6, SFT = 44 Farrel, et al. Expires February 22, 2021 [Page 41] Internet-Draft BGP for NSH SFC August 2020 Note that the addressing used for communicating between SFFs is taken from the Tunnel Encapsulation attribute of the SFIR and not from the SFIR-RD. 8.1. Example Explicit SFP With No Choices Consider the following SFPR. SFP1: RD = 198.51.100.1/101, SPI = 15, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 43, RD = 192.0.2.2/2] The Service Function Path consists of an SF of type 41 located at SFF1 followed by an SF of type 43 located at SFF2. This path is fully explicit and each SFF is offered no choice in forwarding packets along the path. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (15). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 has no flexibility in the choice of SFF to support the next hop SFI and will forward the packet to SFF2 which will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations. 8.2. Example SFP With Choice of SFIs SFP2: RD = 198.51.100.1/102, SPI = 16, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 43, {RD = 192.0.2.2/2, RD = 192.0.2.4/5 } ] In this example the path also consists of an SF of type 41 located at SFF1 and this is followed by an SF of type 43, but in this case the SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (16). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. Farrel, et al. Expires February 22, 2021 [Page 42] Internet-Draft BGP for NSH SFC August 2020 When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a choice of next hop SFF to execute the next hop in the path. It can either forward packets to SFF2 or SFF4 to execute a function of type 43. It uses its local load balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations. 8.3. Example SFP With Open Choice of SFIs SFP3: RD = 198.51.100.1/103, SPI = 17, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 44, RD = 0] In this example the path also consists of an SF of type 41 located at SFF1 and this is followed by an SI with an RD of zero and SF of type 44. This means that a choice can be made between any SFF that supports an SFI of type 44. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (17). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next hop SFF to execute the next hop in the path selecting between all SFFs that support SFs of type 44. Looking at the SFIRs it has received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. SFF1 uses its local load balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 44 before forwarding the packets to their destinations. 8.4. Example SFP With Choice of SFTs SFP4: RD = 198.51.100.1/104, SPI = 18, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, {SFT = 43, RD = 192.0.2.2/2, SFT = 44, RD = 192.0.2.3/8 } ] This example provides a choice of SF type in the second hop in the path. The SI of 250 indicates a choice between SF type 43 located at SF2 and SF type 44 located at SF3. Farrel, et al. Expires February 22, 2021 [Page 43] Internet-Draft BGP for NSH SFC August 2020 SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (18). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next hop SFF to execute the next hop in the path selecting between all SFFs that support an SF of type 43 and SFF3 that supports an SF of type 44. These may be completely different functions that are to be executed dependent on specific conditions, or may be similar functions identified with different type identifiers (such as firewalls from different vendors). SFF1 uses its local policy and load balancing algorithm to make this choice, and may use additional information passed back from the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI that supports the chose SFT before forwarding the packets to their destinations. 8.5. Example Correlated Bidirectional SFPs SFP5: RD = 198.51.100.1/105, SPI = 19, Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 43, RD = 192.0.2.2/2] SFP6: RD = 198.51.100.1/106, SPI = 20, Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19, [SI = 254, SFT = 43, RD = 192.0.2.2/2], [SI = 249, SFT = 41, RD = 192.0.2.1/1] This example demonstrates correlation of two SFPs to form a bidirectional SFP as described in Section 7.1. Two SFPRs are advertised by the Controller. They have different SPIs (19 and 20) so they are known to be separate SFPs, but they both have Association TLVs with Association Type set to 1 indicating bidirectional SFPs. Each has an Associated SFPR-RD field containing the value of the other SFPR-RD to correlated the two SFPs as a bidirectional pair. As can be seen from the SFPRs in this example, the paths are symmetric: the hops in SFP5 appear in the reverse order in SFP6. Farrel, et al. Expires February 22, 2021 [Page 44] Internet-Draft BGP for NSH SFC August 2020 8.6. Example Correlated Asymmetrical Bidirectional SFPs SFP7: RD = 198.51.100.1/107, SPI = 21, Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 43, RD = 192.0.2.2/2] SFP8: RD = 198.51.100.1/108, SPI = 22, Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21, [SI = 254, SFT = 44, RD = 192.0.2.4/6], [SI = 249, SFT = 41, RD = 192.0.2.1/1] Asymmetric bidirectional SFPs can also be created. This example shows a pair of SFPs with distinct SPIs (21 and 22) that are correlated in the same way as in the example in Section 8.5. However, unlike in that example, the SFPs are different in each direction. Both paths include a hop of SF type 41, but SFP7 includes a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF type 44 supported at SFF4. 8.7. Example Looping in an SFP SFP9: RD = 198.51.100.1/109, SPI = 23, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 44, RD = 192.0.2.4/5], [SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0}, SFT = 42, RD = 192.0.2.3/7 } ] Looping and jumping are described in Section 6. This example shows an SFP that contains an explicit loop-back instruction that is presented as a choice within an SFP hop. The first two hops in the path (SI = 255 and SI = 250) are normal. That is, the packets will be delivered to SFF1 and SFF4 in turn for execution of SFs of type 41 and 44 respectively. The third hop (SI = 245) presents SFF4 with a choice of next hop. It can either forward the packets to SFF3 for an SF of type 42 (the second choice), or it can loop back. The loop-back entry in the SFPR for SI = 245 is indicated by the special purpose SFT value 1 ("Change Sequence"). Within this hop, the RD is interpreted as encoding the SPI and SI of the next hop (see Farrel, et al. Expires February 22, 2021 [Page 45] Internet-Draft BGP for NSH SFC August 2020 Section 6.1. In this case the SPI is 23 which indicates that this is loop or branch: i.e., the next hop is on the same SFP. The SI is set to 255: this is a higher number than the current SI (245) indicating a loop. SFF4 must make a choice between these two next hops. Either the packets will be forwarded to SFF3 with the NSH SI decreased to 245 or looped back to SFF1 with the NSH SI reset to 255. This choice will be made according to local policy, information passed back by the local SFI, and details in the packets' metadata that are used to prevent infinite looping. 8.8. Example Branching in an SFP SFP10: RD = 198.51.100.1/110, SPI = 24, [SI = 254, SFT = 42, RD = 192.0.2.3/7], [SI = 249, SFT = 43, RD = 192.0.2.2/2] SFP11: RD = 198.51.100.1/111, SPI = 25, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] Branching follows a similar procedure to that for looping (and jumping) as shown in Section 8.7 however there are two SFPs involved. SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for execution of service functions of type 42 and 43 respectively. SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 processes the next hop in the path and finds a "Change Sequence" Special Purpose SFT. The SFIR-RD field includes an SPI of 24 which indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and send the packets to the appropriate SFF as advertised in the SFPR for SFP10 (that is, SFF3). 8.9. Examples of SFPs with Stateful Service Functions This section provides some examples to demonstrate establishing SFPs when there is a choice of service functions at a particular hop, and where consistency of choice is required in both directions. The scenarios that give rise to this requirement are discussed in Section 7.2. Farrel, et al. Expires February 22, 2021 [Page 46] Internet-Draft BGP for NSH SFC August 2020 8.9.1. Forward and Reverse Choice Made at the SFF Consider the topology shown in Figure 12. There are three SFFs arranged neatly in a line, and the middle one (SFF2) supports three SFIs all of SFT 42. These three instances can be used by SFF2 to load balance so that no one instance is swamped. ------ ------ ------ ------ ------ | SFI | | SFIa | | SFIb | | SFIc | | SFI | |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| ------ ------\ ------ /------ ------ \ \ | / / --------- --------- --------- ---------- | SFF1 | | SFF2 | | SFF3 | --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> --> |Classifier| --------- --------- --------- | | ---------- Figure 12: Example Where Choice is Made at the SFF This leads to the following SFIRs being advertised. RD = 192.0.2.1/11, SFT = 41 RD = 192.0.2.2/11, SFT = 42 (for SFIa) RD = 192.0.2.2/12, SFT = 42 (for SFIb) RD = 192.0.2.2/13, SFT = 42 (for SFIc) RD = 192.0.2.3/11, SFT = 43 The controller can create a single forward SFP (SFP12) giving SFF2 the choice of which SFI to use to provide function of SFT 42 as follows. The load-balancing choice between the three available SFIs is assumed to be within the capabilities of the SFF and if the SFs are stateful it is assumed that the SFF knows this and arranges load balancing in a stable, flow-dependent way. Farrel, et al. Expires February 22, 2021 [Page 47] Internet-Draft BGP for NSH SFC August 2020 SFP12: RD = 198.51.100.1/112, SPI = 26, Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, {RD = 192.0.2.2/11, 192.0.2.2/12, 192.0.2.2/13 }], [SI = 253, SFT = 43, RD = 192.0.2.3/11] The reverse SFP (SFP13) in this case may also be created as shown below using association with the forward SFP and giving the load- balancing choice to SFF2. This is safe, even in the case that the SFs of type 42 are stateful because SFF2 is doing the load balancing in both directions and can apply the same algorithm to ensure that packets associated with the same flow use the same SFI regardless of the direction of travel. SFP13: RD = 198.51.100.1/113, SPI = 27, Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, {RD = 192.0.2.2/11, 192.0.2.2/12, 192.0.2.2/13 }], [SI = 253, SFT = 41, RD = 192.0.2.1/11] How an SFF knows that an attached SFI is stateful is out of scope of this document. It is assumed that this will form part of the process by which SFIs are registered as local to SFFs. Section 7.2 provides additional observations about the coordination of the use of stateful SFIs in the case of bidirectional SFPs. In general, the problems of load balancing and the selection of the same SFIs in both directions of a bidirectional SFP can be addressed by using sufficiently precisely specified SFPs (specifying the exact SFIs to use) and suitable programming of the Classifiers at each end of the SFPs to make sure that the matching pair of SFPs are used. 8.9.2. Parallel End-to-End SFPs with Shared SFF The mechanism described in Section 8.9.1 might not be desirable because of the functional assumptions it places on SFF2 to be able to load balance with suitable flow identification, stability, and equality in both directions. Instead, it may be desirable to place the responsibility for flow classification in the Classifier and let it determine load balancing with the implied choice of SFIs. Farrel, et al. Expires February 22, 2021 [Page 48] Internet-Draft BGP for NSH SFC August 2020 Consider the network graph as shown in Figure 12 and with the same set of SFIRs as listed in Section 8.9.1. In this case the controller could specify three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional pair of SFPs uses a different SFI for the SF of type 42. The controller can instruct the Classifier how to place traffic on the three bidirectional SFPs, or can treat them as a group leaving the Classifier responsible for balancing the load. SFP14: RD = 198.51.100.1/114, SPI = 28, Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.2/11], [SI = 253, SFT = 43, RD = 192.0.2.3/11] SFP15: RD = 198.51.100.1/115, SPI = 29, Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.2/12], [SI = 253, SFT = 43, RD = 192.0.2.3/11] SFP16: RD = 198.51.100.1/116, SPI = 30, Assoc-Type = 1, Assoc-RD = 198.51.100.1/119, Assoc-SPI = 33, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.2/13], [SI = 253, SFT = 43, RD = 192.0.2.3/11] SFP17: RD = 198.51.100.1/117, SPI = 31, Assoc-Type = 1, Assoc-RD = 198.51.100.1/114, Assoc-SPI = 28, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, RD = 192.0.2.2/11], [SI = 253, SFT = 41, RD = 192.0.2.1/11] SFP18: RD = 198.51.100.1/118, SPI = 32, Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, RD = 192.0.2.2/12], [SI = 253, SFT = 41, RD = 192.0.2.1/11] SFP19: RD = 198.51.100.1/119, SPI = 33, Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, RD = 192.0.2.2/13], [SI = 253, SFT = 41, RD = 192.0.2.1/11] Farrel, et al. Expires February 22, 2021 [Page 49] Internet-Draft BGP for NSH SFC August 2020 8.9.3. Parallel End-to-End SFPs with Separate SFFs While the examples in Section 8.9.1 and Section 8.9.2 place the choice of SFI as subtended from the same SFF, it is also possible that the SFIs are each subtended from a different SFF as shown in Figure 13. In this case it is harder to coordinate the choices for forward and reverse paths without some form of coordination between SFF1 and SFF3. Therefore it would be normal to consider end-to-end parallel SFPs as described in Section 8.9.2. ------ | SFIa | |SFT=42| ------ ------ | | SFI | --------- |SFT=41| | SFF5 | ------ ..|192.0.2.5|.. | ..: --------- :.. ---------.: :.--------- ---------- | SFF1 | --------- | SFF3 | --> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| --> --> |Classifier| ---------: |192.0.2.6| :--------- | | : --------- : | ---------- : | : ------ : ------ : | SFI | :.. | SFIb | ..: |SFT=43| :.. |SFT=42| ..: ------ : ------ : :.---------.: | SFF7 | |192.0.2.7| --------- | ------ | SFIc | |SFT=42| ------ Figure 13: Second Example With Parallel End-to-End SFPs In this case, five SFIRs are advertised as follows: Farrel, et al. Expires February 22, 2021 [Page 50] Internet-Draft BGP for NSH SFC August 2020 RD = 192.0.2.1/11, SFT = 41 RD = 192.0.2.5/11, SFT = 42 (for SFIa) RD = 192.0.2.6/11, SFT = 42 (for SFIb) RD = 192.0.2.7/11, SFT = 42 (for SFIc) RD = 192.0.2.3/11, SFT = 43 In this case the controller could specify three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional pair of SFPs uses a different SFF and SFI for middle hop (for an SF of type 42). The controller can instruct the Classifier how to place traffic on the three bidirectional SFPs, or can treat them as a group leaving the Classifier responsible for balancing the load. Farrel, et al. Expires February 22, 2021 [Page 51] Internet-Draft BGP for NSH SFC August 2020 SFP20: RD = 198.51.100.1/120, SPI = 34, Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.5/11], [SI = 253, SFT = 43, RD = 192.0.2.3/11] SFP21: RD = 198.51.100.1/121, SPI = 35, Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.6/11], [SI = 253, SFT = 43, RD = 192.0.2.3/11] SFP22: RD = 198.51.100.1/122, SPI = 36, Assoc-Type = 1, Assoc-RD = 198.51.100.1/125, Assoc-SPI = 39, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.7/11], [SI = 253, SFT = 43, RD = 192.0.2.3/11] SFP23: RD = 198.51.100.1/123, SPI = 37, Assoc-Type = 1, Assoc-RD = 198.51.100.1/120, Assoc-SPI = 34, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, RD = 192.0.2.5/11], [SI = 253, SFT = 41, RD = 192.0.2.1/11] SFP24: RD = 198.51.100.1/124, SPI = 38, Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, RD = 192.0.2.6/11], [SI = 253, SFT = 41, RD = 192.0.2.1/11] SFP25: RD = 198.51.100.1/125, SPI = 39, Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36, [SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 254, SFT = 42, RD = 192.0.2.7/11], [SI = 253, SFT = 41, RD = 192.0.2.1/11] 8.9.4. Parallel SFPs Downstream of the Choice The mechanism of parallel SFPs demonstrated in Section 8.9.3 is perfectly functional and may be practical in many environments. However, there may be scaling concerns because of the large amount of state (knowledge of SFPs, i.e., SFPR advertisements retained) if there is a very large amount of choice of SFIs (for example, tens of instances of the same stateful SF), or if there are multiple choices of stateful SF along a path. This situation may be mitigated using SFP fragments that are combined to form the end to end SFPs. Farrel, et al. Expires February 22, 2021 [Page 52] Internet-Draft BGP for NSH SFC August 2020 The example presented here is necessarily simplistic, but should convey the basic principle. The example presented in Figure 14 is similar to that in Section 8.9.3 but with an additional first hop. ------ | SFIa | |SFT=43| ------ ------ ------ | | SFI | | SFI | --------- |SFT=41| |SFT=42| | SFF5 | ------ ------ ..|192.0.2.5|.. | | ..: --------- :.. --------- ---------.: :.--------- ------ | SFF1 | | SFF2 | --------- | SFF3 | -->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|--> -->| ifier| --------- ---------: |192.0.2.6| :--------- ------ : --------- : | : | : ------ : ------ : | SFI | :.. | SFIb | ..: |SFT=44| :.. |SFT=43| ..: ------ : ------ : :.---------.: | SFF7 | |192.0.2.7| --------- | ------ | SFIc | |SFT=43| ------ Figure 14: Example With Parallel SFPs Downstream of Choice The six SFIs are advertised as follows: RD = 192.0.2.1/11, SFT = 41 RD = 192.0.2.2/11, SFT = 42 RD = 192.0.2.5/11, SFT = 43 (for SFIa) RD = 192.0.2.6/11, SFT = 43 (for SFIb) RD = 192.0.2.7/11, SFT = 43 (for SFIc) RD = 192.0.2.3/11, SFT = 44 Farrel, et al. Expires February 22, 2021 [Page 53] Internet-Draft BGP for NSH SFC August 2020 SFF2 is the point at which a load balancing choice must be made. So "tail-end" SFPs are constructed as follows. Each takes in a different SFF that provides access to an SF of type 43. SFP26: RD = 198.51.100.1/126, SPI = 40, Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44, [SI = 255, SFT = 43, RD = 192.0.2.5/11], [SI = 254, SFT = 44, RD = 192.0.2.3/11] SFP27: RD = 198.51.100.1/127, SPI = 41, Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45, [SI = 255, SFT = 43, RD = 192.0.2.6/11], [SI = 254, SFT = 44, RD = 192.0.2.3/11] SFP28: RD = 198.51.100.1/128, SPI = 42, Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46, [SI = 255, SFT = 43, RD = 192.0.2.7/11], [SI = 254, SFT = 44, RD = 192.0.2.3/11] Now an end-to-end SFP with load balancing choice can be constructed as follows. The choice made by SFF2 is expressed in terms of entering one of the three "tail end" SFPs. SFP29: RD = 198.51.100.1/129, SPI = 43, [SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 254, SFT = 42, RD = 192.0.2.2/11], [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, RD = {SPI=41, SI=255, Rsv=0}, RD = {SPI=42, SI=255, Rsv=0} } ] Now, despite the load balancing choice being made other than at the initial Classifier, it is possible for the reverse SFPs to be well- constructed without any ambiguity. The three reverse paths appear as follows. Farrel, et al. Expires February 22, 2021 [Page 54] Internet-Draft BGP for NSH SFC August 2020 SFP30: RD = 198.51.100.1/130, SPI = 44, Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40, [SI = 255, SFT = 44, RD = 192.0.2.4/11], [SI = 254, SFT = 43, RD = 192.0.2.5/11], [SI = 253, SFT = 42, RD = 192.0.2.2/11], [SI = 252, SFT = 41, RD = 192.0.2.1/11] SFP31: RD = 198.51.100.1/131, SPI = 45, Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41, [SI = 255, SFT = 44, RD = 192.0.2.4/11], [SI = 254, SFT = 43, RD = 192.0.2.6/11], [SI = 253, SFT = 42, RD = 192.0.2.2/11], [SI = 252, SFT = 41, RD = 192.0.2.1/11] SFP32: RD = 198.51.100.1/132, SPI = 46, Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42, [SI = 255, SFT = 44, RD = 192.0.2.4/11], [SI = 254, SFT = 43, RD = 192.0.2.7/11], [SI = 253, SFT = 42, RD = 192.0.2.2/11], [SI = 252, SFT = 41, RD = 192.0.2.1/11] 8.10. Examples Using IPv6 Addressing This section provides several examples using IPv6 addressing. As will be seen from the examples, there is nothing special or clever about using IPv6 addressing rather than IPv4 addressing. The reference network for these IPv6 examples is based on that described at the top of Section 8 and shown in Figure 11. Assume we have a service function overlay network with four SFFs (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the underlay network as follows: SFF1 2001:db8::192:0:2:1 SFF2 2001:db8::192:0:2:2 SFF3 2001:db8::192:0:2:3 SFF4 2001:db8::192:0:2:4 Each SFF provides access to some SFIs from the four Service Function Types SFT=41, SFT=42, SFT=43, and SFT=44 just as before: Farrel, et al. Expires February 22, 2021 [Page 55] Internet-Draft BGP for NSH SFC August 2020 SFF1 SFT=41 and SFT=42 SFF2 SFT=41 and SFT=43 SFF3 SFT=42 and SFT=44 SFF4 SFT=43 and SFT=44 The service function network also contains a Controller with address 2001:db8::198:51:100:1. This example service function overlay network is shown in Figure 15. ------------------------ | Controller | | 2001:db8::198:51:100:1 | ------------------------ ------ ------ ------ ------ | SFI | | SFI | | SFI | | SFI | |SFT=41| |SFT=42| |SFT=41| |SFT=43| ------ ------ ------ ------ \ / \ / ------------------- ------------------- | SFF1 | | SFF2 | |2001:db8::192:0:2:1| |2001:db8::192:0:2:2| ------------------- ------------------- ---------- Packet --> | | --> Flows --> |Classifier| -->Dest | | --> ---------- ------------------- ------------------- | SFF3 | | SFF4 | |2001:db8::192:0:2:3| |2001:db8::192:0:2:4| ------------------- ------------------- / \ / \ ------ ------ ------ ------ | SFI | | SFI | | SFI | | SFI | |SFT=42| |SFT=44| |SFT=43| |SFT=44| ------ ------ ------ ------ Figure 15: Example Service Function Overlay Network The SFFs advertise routes to the SFIs they support. These advertisements contain Route Distinguishers that are set according to the network operator's configuration model. Note that in an IPv6 network, the RD is not large enough to contain the full IPv6 address as only six octets are available so, in all of these IPv6 examples, Farrel, et al. Expires February 22, 2021 [Page 56] Internet-Draft BGP for NSH SFC August 2020 we use RDs of type 1 such that the available six octets are partitioned as four octets for an IPv4 address of the advertising SFF, and two octets that are a local index of the SFI. Furthermore, we have chosen an IPv6 addressing scheme so that the low order four octets of the IPv6 address match an IPv4 address of the advertising node. This scheme is chosen purely for convenience of documentation, and an operator is totally free to use any other scheme so long as it conforms to the definitions of SFIR and SFPR in Section 3.1 and Section 3.2. Observant readers will notice that this makes the BGP advertisements shown in these examples exactly the same as in the previous examples. All that is different is that the advertising SFFs and Controller have IPv6 addresses. Thus we see the following SFIRs advertised: The SFFs advertise routes to the SFIs they support. So we see the following SFIRs: RD = 192.0.2.1/1, SFT = 41 RD = 192.0.2.1/2, SFT = 42 RD = 192.0.2.2/1, SFT = 41 RD = 192.0.2.2/2, SFT = 43 RD = 192.0.2.3/7, SFT = 42 RD = 192.0.2.3/8, SFT = 44 RD = 192.0.2.4/5, SFT = 43 RD = 192.0.2.4/6, SFT = 44 Note that the addressing used for communicating between SFFs is taken from the Tunnel Encapsulation attribute of the SFIR and not from the SFIR-RD. 8.10.1. Example Explicit SFP With No Choices Consider the following SFPR similar to that in Section 8.1. SFP1: RD = 198.51.100.1/101, SPI = 15, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 43, RD = 192.0.2.2/2] The Service Function Path consists of an SF of type 41 located at SFF1 followed by an SF of type 43 located at SFF2. This path is Farrel, et al. Expires February 22, 2021 [Page 57] Internet-Draft BGP for NSH SFC August 2020 fully explicit and each SFF is offered no choice in forwarding packet along the path. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (15). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 has no flexibility in the choice of SFF to support the next hop SFI and will forward the packet to SFF2 which will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations. 8.10.2. Example SFP With Choice of SFIs SFP2: RD = 198.51.100.1/102, SPI = 16, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 43, {RD = 192.0.2.2/2, RD = 192.0.2.4/5 } ] In this example, like that in Section 8.2, the path also consists of an SF of type 41 located at SFF1 and this is followed by an SF of type 43, but in this case the SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (16). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a choice of next hop SFF to execute the next hop in the path. It can either forward packets to SFF2 or SFF4 to execute a function of type 43. It uses its local load balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations. 8.10.3. Example SFP With Open Choice of SFIs SFP3: RD = 198.51.100.1/103, SPI = 17, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, SFT = 44, RD = 0] Farrel, et al. Expires February 22, 2021 [Page 58] Internet-Draft BGP for NSH SFC August 2020 In this example, like that in Section 8.3 the path also consists of an SF of type 41 located at SFF1 and this is followed by an SI with an RD of zero and SF of type 44. This means that a choice can be made between any SFF that supports an SFI of type 44. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (17). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next hop SFF to execute the next hop in the path selecting between all SFFs that support SFs of type 44. Looking at the SFIRs it has received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. SFF1 uses its local load balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 44 before forwarding the packets to their destinations. 8.10.4. Example SFP With Choice of SFTs SFP4: RD = 198.51.100.1/104, SPI = 18, [SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 250, {SFT = 43, RD = 192.0.2.2/2, SFT = 44, RD = 192.0.2.3/8 } ] This example, similar to that in Section 8.4 provides a choice of SF type in the second hop in the path. The SI of 250 indicates a choice between SF type 43 located through SF2 and SF type 44 located at SF3. SFF1 will receive packets on the path from the Classifier and will identify the path from the SPI (18). The initial SI will be 255 and so SFF1 will deliver the packets to the SFI for SFT 41. When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next hop SFF to execute the next hop in the path selecting between all SFFs that support an SF of type 43 and SFF3 that supports an SF of type 44. These may be completely different functions that are to be executed dependent on specific conditions, or may be similar functions identified with different type identifiers (such as firewalls from different vendors). SFF1 uses its local policy and load balancing algorithm to make this choice, and may use additional information passed back from the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI that supports the chose SFT before forwarding the packets to their destinations. Farrel, et al. Expires February 22, 2021 [Page 59] Internet-Draft BGP for NSH SFC August 2020 9. Security Considerations The mechanisms in this document use BGP for the control plane. Hence, techniques such as those discussed in [RFC5925]] can be used to help authenticate BGP sessions and thus the messages between BGP peers, making it harder to spoof updates (which could be used to install bogus SFPs or to advertise false SIs) or withdrawals. Further discussion of security considerations for BGP may be found in the BGP specification itself [RFC4271] and in the security analysis for BGP [RFC4272]. The original discussion of the use of the TCP MD5 signature option to protect BGP sessions is found in [RFC5925], while [RFC6952] includes an analysis of BGP keying and authentication issues. Additionally, this document depends on other documents that specify BGP Multiprotocol Extensions and the documents that define the attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. [RFC4760] observes that the use of AFI/SAFI does not change the underlying security issues inherent in the existing BGP. Relevant additional security measures are considered in [I-D.ietf-idr-tunnel-encaps]. This document does not fundamentally change the security behavior of BGP deployments, which depend considerably on the network operator's perception of risk in their network. It may be observed that the application of the mechanisms described in this document are scoped to a single domain as implied by [RFC8300] noted in Section 2.1 of this document. Applicability of BGP within a single domain may enable a network operator to make easier and more consistent decisions about what security measures to apply, and the domain boundary, which BGP enforces by definition, provides a safeguard that prevents leakage of SFC programming in either direction at the boundary. Service Function Chaining provides a significant attack opportunity: packets can be diverted from their normal paths through the network, packets can be made to execute unexpected functions, and the functions that are instantiated in software can be subverted. However, this specification does not change the existence of Service Function Chaining and security issues specific to Service Function Chaining are covered in [RFC7665] and [RFC8300]. This document defines a control plane for Service Function Chaining. Clearly, this provides an attack vector for a Service Function Chaining system as an attack on this control plane could be used to make the system misbehave. Thus, the security of the BGP system is critically important to the security of the whole Service Function Farrel, et al. Expires February 22, 2021 [Page 60] Internet-Draft BGP for NSH SFC August 2020 Chaining system. The control plane mechanisms are very similar to those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the security considerations in that document (Section 13) provide good guidance for securing SFC systems reliant on this specification. Of particular relevance is the need to securely distinguish between messages intended for the control of different SFC overlays which is similar to the need to distinguish between different VPNs. Section 19 of [RFC7432] also provides useful guidance on the use of BGP in a similar environment. Note that a component of an SFC system that uses the procedures described in this document also requires communications between a Controller and the SFC network elements (specifically the SFFs and Classifiers). This communication covers instructing the Classifiers using BGP mechanisms (see Section 7.4), thus the use of BGP security is strongly recommended. But it also covers other mechanisms for programming the Classifier and instructing the SFFs and SFs (for example, to bind SFs to an SFF, and to cause the establishment of tunnels between SFFs). This document does not cover these latter mechanisms and so their security is out of scope, but it should be noted that these communications provide an attack vector on the SFC system and so attention must be paid to ensuring that they are secure. There is an intrinsic assumption in SFC systems that nodes that announce support for specific SFs actually offer those functions, and that SFs are not, themselves, attacked or subverted. This is particularly important when the SFs are implemented as software that can be updated. Protection against this sort of concern forms part of the security of any SFC system and so is outside the scope of the control plane mechanisms described in this document. Similarly, there is a vulnerability if a rogue or subverted Controller announces SFPs especially if that controller "takes over" an existing SFP and changes its contents. This is corresponds to a rogue BGP speaker entering a routing system, or even to a Route Reflector becoming subverted. Protection mechanisms, as above, include securing BGP sessions and protecting software loads on the controllers. In an environment where there is concern that rogue Controllers might be introduced to the network and inject false SFPRs or take over and change existing SFPRs, it is RECOMMENDED that each SFF and Classifier be configured with the identities of authorized Controllers. Thus, the announcement of an SFPR by any other BGP peer would be rejected. Farrel, et al. Expires February 22, 2021 [Page 61] Internet-Draft BGP for NSH SFC August 2020 Lastly, note that Section 3.2.2 makes two operational suggestions that have implications for the stability and security of the mechanisms described in this document: o That modifications to active SFPs not be made. o That SPIs not be immediately re-used. 10. IANA Considerations 10.1. New BGP AF/SAFI IANA maintains a registry of "Address Family Numbers". IANA is requested to assign a new Address Family Number from the "Standards Action" range called "BGP SFC" (TBD1 in this document) with this document as a reference. IANA maintains a registry of "Subsequent Address Family Identifiers (SAFI) Parameters". IANA is requested to assign a new SAFI value from the "Standards Action" range called "BGP SFC" (TBD2 in this document) with this document as a reference. 10.2. New BGP Path Attribute IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "BGP Path Attributes". IANA is requested to assign a new Path attribute called "SFP attribute" (TBD3 in this document) with this document as a reference. 10.3. New SFP Attribute TLVs Type Registry IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA is request to create a new subregistry called the "SFP Attribute TLVs" registry. Valid values are in the range 0 to 65535. o Values 0 and 65535 are to be marked "Reserved, not to be allocated". o Values 1 through 65534 are to be assigned according to the "First Come First Served" policy [RFC8126]. This document should be given as a reference for this registry. The new registry should track: o Type Farrel, et al. Expires February 22, 2021 [Page 62] Internet-Draft BGP for NSH SFC August 2020 o Name o Reference Document or Contact o Registration Date The registry should initially be populated as follows: Type | Name | Reference | Date ------+-------------------------+---------------+--------------- 1 | Association TLV | [This.I-D] | Date-to-be-set 2 | Hop TLV | [This.I-D] | Date-to-be-set 3 | SFT TLV | [This.I-D] | Date-to-be-set 4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 10.4. New SFP Association Type Registry IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA is request to create a new subregistry called the "SFP Association Type" registry. Valid values are in the range 0 to 65535. o Values 0 and 65535 are to be marked "Reserved, not to be allocated". o Values 1 through 65534 are to be assigned according to the "First Come First Served" policy [RFC8126]. This document should be given as a reference for this registry. The new registry should track: o Association Type o Name o Reference Document or Contact o Registration Date The registry should initially be populated as follows: Farrel, et al. Expires February 22, 2021 [Page 63] Internet-Draft BGP for NSH SFC August 2020 Association Type | Name | Reference | Date -----------------+--------------------+------------+--------------- 1 | Bidirectional SFP | [This.I-D] | Date-to-be-set 10.5. New Service Function Type Registry IANA is request to create a new top-level registry called "Service Function Chaining Service Function Types". Valid values are in the range 0 to 65535. o Values 0 and 65535 are to be marked "Reserved, not to be allocated". o Values 1 through 31 are to be assigned by "Standards Action" [RFC8126] and are referred to as the Special Purpose SFT values. o Values 32 through 64495 are to be assigned according to the "First Come First Served" policy [RFC8126]. o Values 64496 through 65534 are for Private Use and are not to be recorded by IANA. This document should be given as a reference for this registry. The new registry should track: o Value o Name o Reference Document or Contact o Registration Date The registry should initially be populated as follows where [I-D.darwa] should be expanded to [I-D.dawra-idr-bgp-ls-sr-service-segments]. Farrel, et al. Expires February 22, 2021 [Page 64] Internet-Draft BGP for NSH SFC August 2020 Value | Name | Reference | Date ------+-------------------------+------------+--------------- 0 | Reserved, not to be | [This.I-D] | Date-to-be-set | allocated | | 1 | Change Sequence | [This.I-D] | Date-to-be-set 2-31 | Unassigned | | 32 | Classifier | [This.I-D] | Date-to-be-set | | [I-D.dawra]| 33 | Firewall | [This.I-D] | Date-to-be-set | | [I-D.dawra]| 34 | Load balancer | [This.I-D] | Date-to-be-set | | [I-D.dawra]| 35 | Deep packet inspection | [This.I-D] | Date-to-be-set | engine | [I-D.dawra]| 36 | Penalty box | [This.I-D] | Date-to-be-set | | [RFC8300] | 37 | WAN accelerator | [This.I-D] | Date-to-be-set | | [RFC7665] | | | [RFC8300] | 38 | Application accelerator | [This.I-D] | Date-to-be-set | | [RFC7665] | 39 | TCP optimizer | [This.I-D] | Date-to-be-set | | [RFC7665] | 40 | Network Address | [This.I-D] | Date-to-be-set | Translator | [RFC7665] | 41 | NAT44 | [This.I-D] | Date-to-be-set | | [RFC7665] | | | [RFC3022] | 42 | NAT64 | [This.I-D] | Date-to-be-set | | [RFC7665] | | | [RFC6146] | 43 | NPTv6 | [This.I-D] | Date-to-be-set | | [RFC7665] | | | [RFC6296] | 44 | Lawful intercept | [This.I-D] | Date-to-be-set | | [RFC7665] | 45 | HOST_ID injection | [This.I-D] | Date-to-be-set | | [RFC7665] | 46 | HTTP header enrichment | [This.I-D] | Date-to-be-set | | [RFC7665] | 47 | Caching engine | [This.I-D] | Date-to-be-set | | [RFC7665] | 48- | | | -65534|Unassigned | | 65535 | Reserved, not to be | | | allocated | [This.I-D] | Date-to-be-set Farrel, et al. Expires February 22, 2021 [Page 65] Internet-Draft BGP for NSH SFC August 2020 10.6. New Generic Transitive Experimental Use Extended Community Sub- Types IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "Generic Transitive Experimental Use Extended Community Sub-Type". IANA is requested to assign a new sub-type as follows: "Flow Specification for SFC Classifiers" (TBD4 in this document) with this document as the reference. 10.7. New BGP Transitive Extended Community Type IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "BGP Transitive Extended Community Types". IANA is requested to assign a new type as follows: o SFC (Sub-Types are defined in the "SFC Extended Community Sub- Types" registry) (TBD6 in this document) with this document as the reference. 10.8. New SFC Extended Community Sub-Types Registry IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA is requested to create a new sub-registry called the "SFC Extended Community Sub-Types Registry". IANA should include the following note replacing the string "TBD6" with the value assigned for Section 10.7: This registry contains values of the second octet (the "Sub-Type" field) of an extended community when the value of the first octet (the "Type" field) is set to TBD6. The allocation policy for this registry should be First Come First Served. Valid values are 0 to 255. The value 0 is reserved and should not be allocated. IANA is requested to populate this registry with the following entries: Farrel, et al. Expires February 22, 2021 [Page 66] Internet-Draft BGP for NSH SFC August 2020 Sub-Type | | | Value | Name | Reference | Date ---------+----------------------+-------------+--------------- 0 | Reserved, not to be | | | allocated | | 1 | SFIR Pool Identifier | [This.I-D] | Date-to-be-set 2 | MPLS Label Stack | [This.I-D] | Date-to-be-set | Mixed Swapping/ | | | Stacking Labels | | 3-255 | Unassigned | | All other values should be marked "Unassigned". 10.9. SPI/SI Representation IANA is requested to assign a codepoint from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV" (TBD5 in this document) with this document being the reference. 10.10. SFC SPI/SI Representation Flags Registry IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry and is requested to create an associated registry called the "SFC SPI/SI Representation Flags" registry. Bits are to be assigned by Standards Action. The field is 16 bits long, and bits are counted from the the most significant bit as bit zero. IANA is requested to populate the registry as follows: Bit number | Name | Reference -----------+----------------------+----------- TBD9 | NSH data plane | [This.I-D] TBD10 | MPLS data plane | [This.I-D] 11. Contributors Farrel, et al. Expires February 22, 2021 [Page 67] Internet-Draft BGP for NSH SFC August 2020 Stuart Mackie Juniper Networks Email: wsmackie@juinper.net Keyur Patel Arrcus, Inc. Email: keyur@arrcus.com Avinash Lingala AT&T Email: ar977m@att.com 12. Acknowledgements Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful comments, and to Joel Halpern for discussions that improved this document. Yuanlong Jiang provided a useful review and caught some important issues. Stephane Litkowski did an exceptionally good and detailed document shepherd review. Andy Malis contributed text that formed the basis of Section 7.7. Brian Carpenter and Martin Vigoureux provided useful reviews during IETF last call. Thanks also to Sheng Jiang, Med Boucadair, Ravi Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, Barry Leiba, and Murray Kucherawy for review comments. Ketan Talaulikar provided helpful discussion of the SFT code point registry. Ron Bonica kept us honest on the difference between an RD and RT; Benjamin Kaduk kept us on message about the differnce between an RD and an extended community. 13. References 13.1. Normative References [I-D.ietf-idr-rfc5575bis] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", draft-ietf-idr-rfc5575bis-26 (work in progress), August 2020. Farrel, et al. Expires February 22, 2021 [Page 68] Internet-Draft BGP for NSH SFC August 2020 [I-D.ietf-idr-tunnel-encaps] Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- encaps-17 (work in progress), July 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Farrel, et al. Expires February 22, 2021 [Page 69] Internet-Draft BGP for NSH SFC August 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Forwarding Plane for Service Function Chaining", RFC 8595, DOI 10.17487/RFC8595, June 2019, . [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, "MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)", RFC 8596, DOI 10.17487/RFC8596, June 2019, . 13.2. Informative References [I-D.dawra-idr-bgp-ls-sr-service-segments] Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS Advertisement of Segment Routing Service Segments", draft- dawra-idr-bgp-ls-sr-service-segments-04 (work in progress), August 2020. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . Farrel, et al. Expires February 22, 2021 [Page 70] Internet-Draft BGP for NSH SFC August 2020 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, . [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, . Authors' Addresses Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk John Drake Juniper Networks Email: jdrake@juniper.net Eric Rosen Juniper Networks Email: erosen52@gmail.com Jim Uttaro AT&T Email: ju1738@att.com Luay Jalil Verizon Email: luay.jalil@verizon.com Farrel, et al. Expires February 22, 2021 [Page 71] ./draft-ietf-dots-signal-filter-control-07.txt0000644000764400076440000014153213675136135020564 0ustar iustyiusty DOTS K. Nishizuka Internet-Draft NTT Communications Intended status: Standards Track M. Boucadair Expires: December 27, 2020 Orange T. Reddy McAfee T. Nagata Lepidum June 25, 2020 Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel draft-ietf-dots-signal-filter-control-07 Abstract This document specifies an extension to the Distributed Denial-of- Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de- activate existing filtering rules during a DDoS attack. The characterization of these filtering rules is conveyed by a DOTS client during an idle time (i.e., no mitigation is active) by means of the DOTS data channel protocol. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Controlling Filtering Rules Using Distributed Denial- of-Service Open Threat Signaling (DOTS) Signal Channel"; o reference: RFC XXXX o [RFCXXXX] Please update the "revision" date of the YANG module. Nishizuka, et al. Expires December 27, 2020 [Page 1] Internet-Draft DOTS Signal Filter Control June 2020 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 27, 2020. Copyright Notice Copyright (c) 2020 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 (https://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 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Controlling Filtering Rules Using DOTS Signal Channel . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Controlling Filtering Rules of a DOTS Client . . . . . . . . 5 3.1. Binding DOTS Data and Signal Channels . . . . . . . . . . 5 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6 3.2.1. Parameters and Behaviors . . . . . . . . . . . . . . 6 3.2.2. DOTS Signal Filtering Control Module . . . . . . . . 9 3.2.2.1. Tree Structure . . . . . . . . . . . . . . . . . 10 3.2.2.2. YANG Module . . . . . . . . . . . . . . . . . . . 10 4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Conflict Handling . . . . . . . . . . . . . . . . . . . . 12 4.2. On-Demand Activation of an Accept-List Filter . . . . . . 17 Nishizuka, et al. Expires December 27, 2020 [Page 2] Internet-Draft DOTS Signal Filter Control June 2020 4.3. DOTS Servers/Mitigators Lacking Capacity . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 22 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction 1.1. The Problem In the Distributed Denial-of-Service Open Threat Signaling (DOTS) architecture [I-D.ietf-dots-architecture], DOTS clients and servers communicate using both a signal channel protocol [RFC8782] and a data channel protocol [RFC8783]. The DOTS data channel protocol [RFC8783] is used for bulk data exchange between DOTS agents to improve the coordination of parties involved in the response to a Distributed Denial-of-Service (DDoS) attack. Filter management is one of its tasks which enables a DOTS client to retrieve the filtering capabilities of a DOTS server and to manage filtering rules. Typically, these filtering rules are used for dropping or rate-limiting unwanted traffic, and permitting accept-listed traffic. The DOTS signal channel protocol [RFC8782] is designed to be resilient under extremely hostile network conditions and provides continued contact between DOTS agents even as DDoS attack traffic saturates the link. The DOTS signal channel can be established between two DOTS agents prior to or during an attack. At any time, the DOTS client may send mitigation requests (as per Section 4.4 of [RFC8782]) to a DOTS server over the active signal channel. While mitigation is active, the DOTS server periodically sends status messages to the DOTS client, including basic mitigation feedback details. In case of a massive DDoS attack that saturates the incoming link(s) to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped. However, the DOTS server may still receive DOTS messages sent from the DOTS client over the signalling channel thanks to the heartbeat requests keeping the channel active (as described in Section 4.7 of [RFC8782]). Unlike the DOTS signal channel protocol, the DOTS data channel protocol is not expected to deal with attack conditions. As such, an issue that might be encountered in some deployments is when filters Nishizuka, et al. Expires December 27, 2020 [Page 3] Internet-Draft DOTS Signal Filter Control June 2020 installed by means of the DOTS data channel protocol may not function as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS attack. In such conditions the DOTS data channel protocol cannot be used to change these filters, which may complicate DDoS mitigation operations [Interop]. A typical case is a conflict between filtering rules installed by a DOTS client and the mitigation actions of a DDoS mitigator. Consider, for instance, a DOTS client that configures during 'idle' time (i.e., no mitigation is active) some filtering rules using the DOTS data channel protocol to permit traffic from accept-listed sources. However, during a volumetric DDoS attack the DDoS mitigator identifies the source addresses/prefixes in the accept-listed filtering rules are attacking the target. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attack traffic or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack. [RFC8782] is designed so that the DDoS server notifies the above conflict to the DOTS client (that is, 'conflict-cause' parameter set to 2 (Conflicts with an existing accept list)), but the DOTS client may not be able to withdraw the accept-list rules during the attack period due to the high-volume attack traffic saturating the inbound link to the DOTS client domain. In other words, the DOTS client cannot use the DOTS data channel protocol to withdraw the accept-list filters when a DDoS attack is in progress. 1.2. Controlling Filtering Rules Using DOTS Signal Channel This specification addresses the problems discussed in Section 1.1 by adding a capability for managing filtering rules using the DOTS signal channel protocol, which enables a DOTS client to request the activation (or deactivation) of filtering rules during a DDoS attack. Note that creating these filtering rules is still the responsibility of the DOTS data channel [RFC8783]. The DOTS signal channel protocol is designed to enable a DOTS client to contact a DOTS server for help even under severe network congestion conditions. Therefore, extending the DOTS signal channel protocol to manage the filtering rules during an attack will enhance the protection capability offered by DOTS protocols. Note: The experiment at the IETF103 hackathon [Interop] showed that even when the inbound link is saturated by DDoS attack traffic, the DOTS client can signal mitigation requests using the DOTS signal channel over the saturated link. Nishizuka, et al. Expires December 27, 2020 [Page 4] Internet-Draft DOTS Signal Filter Control June 2020 Conflicts that are induced by filters installed by other DOTS clients of the same domain are not discussed in this specification. An augmentation to the DOTS signal channel YANG module is defined in Section 3.2.2. Sample examples are provided in Section 4, in particular: o Section 4.1 illustrates how the filter control extension is used when conflicts with Access Control Lists (ACLs) are detected and reported by a DOTS server. o Section 4.2 shows how a DOTS client can instruct a DOTS server to safely forward some specific traffic in 'attack' time. o Section 4.3 shows how a DOTS client can react if the DDoS traffic is still being forwarded to the DOTS client domain even if mitigation requests were sent to a DOTS server. The JavaScript Object Notation (JSON) encoding of YANG-modeled data [RFC7951] is used to illustrate the examples. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in [RFC8612]. The terminology for describing YANG modules is defined in [RFC7950]. The meaning of the symbols in the tree diagram is defined in [RFC8340]. 3. Controlling Filtering Rules of a DOTS Client 3.1. Binding DOTS Data and Signal Channels The filtering rules eventually managed using the DOTS signal channel protocol are created a priori by the same DOTS client using the DOTS data channel protocol. Managing conflicts with filters installed by other DOTS clients of the same domain is out of scope. As discussed in Section 4.4.1 of [RFC8782], a DOTS client must use the same 'cuid' for both the DOTS signal and data channels. This Nishizuka, et al. Expires December 27, 2020 [Page 5] Internet-Draft DOTS Signal Filter Control June 2020 requirement is meant to facilitate binding DOTS channels used by the same DOTS client. The DOTS signal and data channels from a DOTS client may or may not use the same DOTS server. Nevertheless, the scope of the mitigation request, alias, and filtering rules are not restricted to the DOTS server but to the DOTS server domain. To that aim, DOTS servers within a domain are assumed to have a mechanism to coordinate the mitigation requests, aliases, and filtering rules to coordinate their decisions for better mitigation operation efficiency. The exact details about such mechanism is out of the scope of this document. A filtering rule controlled by the DOTS signal channel is identified by its ACL name (Section 4.3 of [RFC8782]). Note that an ACL name unambiguously identifies an ACL bound to a DOTS client, but the same name may be used by distinct DOTS clients. The activation or deactivation of an ACL by the DOTS signal channel overrides the 'activation-type' (defined in Section 4.3 of [RFC8783]) a priori conveyed with the filtering rules using the DOTS data channel protocol. Once the attack is mitigated, the DOTS client may use the data channel to control the 'activation-type' (e.g., revert to a default value) of some of the filtering rules controlled by the DOTS signal channel or delete some of these filters. This behavior is deployment specific. 3.2. DOTS Signal Channel Extension 3.2.1. Parameters and Behaviors This specification extends the mitigation request defined in Section 4.4.1 of [RFC8782] to convey the intended control of configured filtering rules. Concretely, the DOTS client conveys 'acl-list' attribute with the following sub-attributes in the CBOR body of a mitigation request (see the YANG structure in Section 3.2.2.1): acl-name: A name of an access list defined using the DOTS data channel (Section 4.3 of [RFC8783]) that is associated with the DOTS client. As a reminder, an ACL is an ordered list of Access Control Entries (ACE). Each ACE has a list of match criteria and a list of actions [RFC8783]. The list of configured ACLs can be retrieved using the DOTS data channel during 'idle' time. Nishizuka, et al. Expires December 27, 2020 [Page 6] Internet-Draft DOTS Signal Filter Control June 2020 This is a mandatory attribute when 'acl-list' is included. activation-type: Indicates the activation type of an ACL overriding the existing 'activation-type' installed by the DOTS client using the DOTS data channel. As a reminder, this attribute can be set to 'deactivate', 'immediate', or 'activate-when-mitigating' as defined in [RFC8783]. Note that both 'immediate' and 'activate-when-mitigating' have an immediate effect when a mitigation request is being processed by the DOTS server. This is an optional attribute. By default, ACL-related operations are achieved using the DOTS data channel protocol when no attack is ongoing. DOTS clients MUST NOT use the filtering control over DOTS signal channel in 'idle' time; such requests MUST be discarded by DOTS servers with 4.00 (Bad Request). During an attack time, DOTS clients may include 'acl-list', 'acl- name', and 'activation-type' attributes in a mitigation request. This request may be the initial mitigation request for a given mitigation scope or a new one overriding an existing request. In both cases, a new 'mid' MUST be used. Nevertheless, it is NOT RECOMMENDED to include ACL attributes in an initial mitigation request for a given mitigation scope or in a mitigation request adjusting the mitigation scope. This recommendation is meant to avoid delaying attack mitigations because of failures to process ACL attributes. As the attack evolves, DOTS clients can adjust the 'activation-type' of an ACL conveyed in a mitigation request or control other filters as necessary. This can be achieved by sending a PUT request with a new 'mid' value. It is RECOMMENDED for a DOTS client to subscribe to asynchronous notifications of the attack mitigation, as detailed in Section 4.4.2.1 of [RFC8782]. If not, the polling mechanism in Section 4.4.2.2 of [RFC8782] has to be followed by the DOTS client. A DOTS client relies on the information received from the DOTS server and/or local information to the DOTS client domain to trigger a filter control request. Only filters that are pertinent for an ongoing mitigation should be controlled by a DOTS client using the DOTS signal channel. Nishizuka, et al. Expires December 27, 2020 [Page 7] Internet-Draft DOTS Signal Filter Control June 2020 'acl-list', 'acl-name', and 'activation-type' are defined as comprehension-required parameters. Following the rules in Section 6 of [RFC8782], if the DOTS server does not understand the 'acl-list' or 'acl-name' or 'activation-type' attributes, it responds with a "4.00 (Bad Request)" error response code. If the DOTS server does not find the ACL name ('acl-name') conveyed in the mitigation request for this DOTS client, it MUST respond with 4.04 (Not Found) error response code. If the DOTS server finds the ACL name for this DOTS client, and assuming the request passed the validation checks in Section 4.4.1 of [RFC8782], the DOTS server MUST proceed with the 'activation-type' update. The update is immediately enforced by the DOTS server and will be maintained as the new activation type for the ACL name even after the termination of the mitigation request. In addition, the DOTS server MUST update the lifetime of the corresponding ACL similar to the update when a refresh request is received using the DOTS data channel (Section 7.2 of [RFC8783]). If, for some reason, the DOTS server fails to apply the filter update, it MUST respond with 5.03 (Service Unavailable) error response code and include the failed ACL update in the diagnostic payload of the response (an example is shown in Figure 1). Else, the DOTS server replies with the appropriate response code defined in Section 4.4.1 of [RFC8782]. { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "mid": 123, "ietf-dots-signal-control:acl-list": [ { "acl-name": "an-accept-list", "activation-type": "deactivate" } ] } ] } } Figure 1: Example of a Diagnostic Payload Including Failed ACL Update The JSON/YANG mappings for DOTS filter control attributes are shown in Table 1. As a reminder, the mapping for 'acl-name' is defined in Table 5 of [RFC8782]. Nishizuka, et al. Expires December 27, 2020 [Page 8] Internet-Draft DOTS Signal Filter Control June 2020 +-------------------+------------+--------+---------------+--------+ | Parameter Name | YANG | CBOR | CBOR Major | JSON | | | Type | Key | Type & | Type | | | | | Information | | +===================+============+========+===============+========+ | activation-type | enumeration| TBA1 | 0 unsigned | String | +-------------------+------------+--------+---------------+--------+ | ietf-dots-signal- | | | | | | control:acl-list | list | TBA2 | 4 array | Array | +-------------------+------------+--------+---------------+--------+ | acl-name | leafref | 23 | 3 text string | String | +-------------------+------------+--------+---------------+--------+ Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes If the DOTS client receives a 5.03 (Service Unavailable) with a diagnostic payload indicating a failed ACL update as a response to an initial mitigation or a mitigation with adjusted scope, the DOTS client MUST immediately send a new request which repeats all the parameters as sent in the failed mitigation request but without including the ACL attributes. After the expiry of Max-Age returned in the 5.03 (Service Unavailable) response, the DOTS client retries with a new mitigation request (i.e., a new 'mid') that repeats all the parameters as sent in the failed mitigation request (i.e., the one including the ACL attributes). If, during an active mitigation, the 'activation-type' is changed at the DOTS server (e.g., as a result of an external action) for an ACL bound to a DOTS client, the DOTS server notifies that DOTS client of the change by including the corresponding ACL parameters in an asynchronous notification (the DOTS client is observing the active mitigation) or in a response to a polling request (Section 4.4.2.2 of [RFC8782]). If the DOTS signal and data channels of a DOTS client are not established with the same DOTS server of a DOTS server domain, the above request processing operations are undertaken using the coordination mechanism discussed in Section 3.1. This specification does not require any modification to the efficacy update and the withdrawal procedures defined in [RFC8782]. In particular, ACL-related clauses are not included in a PUT request used to send an efficacy update and DELETE requests. 3.2.2. DOTS Signal Filtering Control Module Nishizuka, et al. Expires December 27, 2020 [Page 9] Internet-Draft DOTS Signal Filter Control June 2020 3.2.2.1. Tree Structure This document augments the "ietf-dots-signal-channel" YANG module defined in [RFC8782] for managing filtering rules. This document defines the YANG module "ietf-dots-signal-control", which has the following tree structure: module: ietf-dots-signal-control augment /ietf-signal:dots-signal/ietf-signal:message-type /ietf-signal:mitigation-scope/ietf-signal:scope: +--rw acl-list* [acl-name] {control-filtering}? +--rw acl-name | -> /ietf-data:dots-data/dots-client/acls/acl/name +--rw activation-type? ietf-data:activation-type 3.2.2.2. YANG Module This YANG module is not intended to be used via NETCONF/RESTCONF for DOTS server management purposes; such module is out of the scope of this document. It serves only to provide a data model and encoding, but not a management data model. This module uses types defined in [RFC8783]. file "ietf-dots-signal-control@2019-05-13.yang" module ietf-dots-signal-control { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; prefix dots-control; import ietf-dots-signal-channel { prefix ietf-signal; reference "RFC 8782: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; } import ietf-dots-data-channel { prefix ietf-data; reference "RFC 8783: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"; } organization Nishizuka, et al. Expires December 27, 2020 [Page 10] Internet-Draft DOTS Signal Filter Control June 2020 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; contact "WG Web: WG List: Author: Kaname Nishizuka Author: Mohamed Boucadair Author: Konda, Tirumaleswar Reddy Author: Takahiko Nagata "; description "This module contains YANG definition for the signaling messages exchanged between a DOTS client and a DOTS server to control, by means of the DOTS signal channel, filtering rules configured using the DOTS data channel. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-05-13 { description "Initial revision."; reference "RFC XXXX: Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; } feature control-filtering { description "This feature means that the DOTS signal channel is able Nishizuka, et al. Expires December 27, 2020 [Page 11] Internet-Draft DOTS Signal Filter Control June 2020 to manage the filtering rules created by the same DOTS client using the DOTS data channel."; } augment "/ietf-signal:dots-signal/ietf-signal:message-type" + "/ietf-signal:mitigation-scope/ietf-signal:scope" { if-feature control-filtering; description "ACL name and activation type."; list acl-list { key "acl-name"; description "List of ACLs as defined using the DOTS data channel. ACLs bound to a DOTS client are uniquely identified by a name."; leaf acl-name { type leafref { path "/ietf-data:dots-data/ietf-data:dots-client" + "/ietf-data:acls/ietf-data:acl/ietf-data:name"; } description "Reference to the ACL name bound to a DOTS client."; } leaf activation-type { type ietf-data:activation-type; default "activate-when-mitigating"; description "Sets the activation type of an ACL."; } } } } 4. Some Examples This section provides some examples to illustrate the behavior specified in Section 3.2.1. These examples are provided for illustration purposes; they should not be considered as deployment recommendations. 4.1. Conflict Handling Let's consider a DOTS client which contacts its DOTS server during 'idle' time to install an accept-list allowing for UDP traffic issued from 2001:db8:1234::/48 with a destination port number 443 to be Nishizuka, et al. Expires December 27, 2020 [Page 12] Internet-Draft DOTS Signal Filter Control June 2020 forwarded to 2001:db8:6401::2/127. It does so by sending, for example, a PUT request shown in Figure 2. PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /acl=an-accept-list HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "an-accept-list", "type": "ipv6-acl-type", "activation-type": "activate-when-mitigating", "aces": { "ace": [ { "name": "test-ace-ipv6-udp", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/48" }, "udp": { "destination-port-range-or-operator": { "operator": "eq", "port": 443 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 2: DOTS Data Channel Request to Create a Filter Sometime later, consider that a DDoS attack is detected by the DOTS client on 2001:db8:6401::2/127. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in Figure 3. Nishizuka, et al. Expires December 27, 2020 [Page 13] Internet-Draft DOTS Signal Filter Control June 2020 Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "mid=123" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "lifetime": 3600 } ] } } Figure 3: DOTS Signal Channel Mitigation Request The DOTS server accepts immediately the request by replying with 2.01 (Created) (Figure 4 depicts the message body of the response). { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "mid": 123, "lifetime": 3600 } ] } } Figure 4: Status Response (Message Body) Assuming the DOTS client subscribed to asynchronous notifications, when the DOTS server concludes that some of the attack sources belong to 2001:db8:1234::/48, it sends a notification message with 'status' code set to '1 (Attack mitigation is in progress)' and 'conflict- cause' set to '2' (conflict-with-acceptlist) to the DOTS client to Nishizuka, et al. Expires December 27, 2020 [Page 14] Internet-Draft DOTS Signal Filter Control June 2020 indicate that this mitigation request is in progress, but a conflict is detected. Upon receipt of the notification message from the DOTS server, the DOTS client sends a PUT request to deactivate the "an-accept-list" ACL as shown in Figure 5. The DOTS client can also decide to send a PUT request to deactivate the "an-accept-list" ACL, if suspect traffic is received from an accept-listed source (2001:db8:1234::/48). The structure of that PUT is the same as the one shown in Figure 5. Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "mid=124" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "an-accept-list", "activation-type": "deactivate" } ], "lifetime": 3600 } ] } } Figure 5: PUT for Deactivating a Conflicting Filter Then, the DOTS server deactivates "an-accept-list" ACL and replies with 2.04 (Changed) response to the DOTS client to confirm the successful operation. The message body is similar to the one depicted in Figure 4. Nishizuka, et al. Expires December 27, 2020 [Page 15] Internet-Draft DOTS Signal Filter Control June 2020 Once the attack is mitigated, the DOTS client may use the data channel to retrieve its ACLs maintained by the DOTS server. As shown in Figure 6, the activation type is set to 'deactivate' as set by the DOTS signal channel (Figure 5) instead of the type initially set using the DOTS data channel (Figure 2). { "ietf-dots-data-channel:acls": { "acl": [ { "name": "an-accept-list", "type": "ipv6-acl-type", "activation-type": "deactivate", "pending-lifetime": 10021, "aces": { "ace": [ { "name": "test-ace-ipv6-udp", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/48" }, "udp": { "destination-port-range-or-operator": { "operator": "eq", "port": 443 } } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 6: DOTS Data Channel GET Response after Mitigation (Message Body) Nishizuka, et al. Expires December 27, 2020 [Page 16] Internet-Draft DOTS Signal Filter Control June 2020 4.2. On-Demand Activation of an Accept-List Filter Let's consider a DOTS client which contacts its DOTS server during 'idle' time to install an accept-list allowing for UDP traffic issued from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It does so by sending, for example, a PUT request shown in Figure 7. The DOTS server installs this filter with a "deactivated" state. PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ /acl=my-accept-list HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "my-accept-list", "type": "ipv6-acl-type", "activation-type": "deactivate", "aces": { "ace": [ { "name": "an-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:6401::2/127", "source-ipv6-network": "2001:db8:1234::/48", "protocol": 17 } }, "actions": { "forwarding": "accept" } } ] } } ] } } Figure 7: DOTS Data Channel Request to Create an Accept-List Filter Sometime later, consider that a UDP DDoS attack is detected by the DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS Nishizuka, et al. Expires December 27, 2020 [Page 17] Internet-Draft DOTS Signal Filter Control June 2020 client domain. Consequently, the DOTS client sends a mitigation request to its DOTS server as shown in Figure 8. Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" Uri-Path: "mid=4879" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "my-accept-list", "activation-type": "immediate" } ], "lifetime": 3600 } ] } } Figure 8: DOTS Signal Channel Mitigation Request with a Filter Control The DOTS server activates "my-accept-list" ACL and replies with 2.01 (Created) response to the DOTS client to confirm the successful operation. 4.3. DOTS Servers/Mitigators Lacking Capacity This section describes a scenario in which a DOTS client activates a drop-list or a rate-limit filter during an attack. Consider a DOTS client that contacts its DOTS server during 'idle' time to install an accept-list that rate-limits all (or a part thereof) traffic to be forwarded to 2001:db8:123::/48 as a last Nishizuka, et al. Expires December 27, 2020 [Page 18] Internet-Draft DOTS Signal Filter Control June 2020 resort countermeasure whenever required. Installing the accept-list can be done by sending, for example, the PUT request shown in Figure 9. The DOTS server installs this filter with a "deactivated" state. PUT /restconf/data/ietf-dots-data-channel:dots-data\ /dots-client=OopPisZqo4SLv64TLPXrxA/acls\ /acl=my-ratelimit-list HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-dots-data-channel:acls": { "acl": [ { "name": "my-ratelimit-list", "type": "ipv6-acl-type", "activation-type": "deactivate", "aces": { "ace": [ { "name": "my-ace", "matches": { "ipv6": { "destination-ipv6-network": "2001:db8:123::/48" } }, "actions": { "forwarding": "accept", "rate-limit": "20000.00" } } ] } } ] } } Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter Consider now that a DDoS attack is detected by the DOTS client on 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation request to its DOTS server (Figure 10). Nishizuka, et al. Expires December 27, 2020 [Page 19] Internet-Draft DOTS Signal Filter Control June 2020 Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "mid=85" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:123::/48" ], "lifetime": 3600 } ] } } Figure 10: DOTS Signal Channel Mitigation Request For some reason (e.g., the DOTS server, or the mitigator, is lacking a capability or capacity), the DOTS client is still receiving attack traffic which saturates available links. To soften the problem, the DOTS client decides to activate the filter that rate-limits the traffic destined to the DOTS client domain. To that aim, the DOTS client sends the mitigation request to its DOTS server shown in Figure 11. Nishizuka, et al. Expires December 27, 2020 [Page 20] Internet-Draft DOTS Signal Filter Control June 2020 Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "mid=86" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:123::/48" ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "my-ratelimit-list", "activation-type": "immediate" } ], "lifetime": 3600 } ] } } Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate- Limit Filter Then, the DOTS server activates "my-ratelimit-list" ACL and replies with 2.04 (Changed) response to the DOTS client to confirm the successful operation. As the attack mitigation evolves, the DOTS client may decide to deactivate the rate-limit policy (e.g., upon receipt of notification status change from 'attack-exceeded-capability' to 'attack- mitigation-in-progress'). Based on the mitigation status conveyed by the DOTS server, the DOTS client can de-activate the rate-limit action. It does so by sending the request shown in Figure 12. Nishizuka, et al. Expires December 27, 2020 [Page 21] Internet-Draft DOTS Signal Filter Control June 2020 Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "mid=87" Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:123::/48" ], "ietf-dots-signal-control:acl-list": [ { "acl-name": "my-ratelimit-list", "activation-type": "deactivate" } ], "lifetime": 3600 } ] } } Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit Filter 5. IANA Considerations 5.1. DOTS Signal Channel CBOR Mappings Registry This specification registers the following parameters in the IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map]. o Note to the RFC Editor: Please delete (TBA1-TBA2) once the CBOR keys are assigned from the 1-16383 range. Please update Table 1 accordingly. Nishizuka, et al. Expires December 27, 2020 [Page 22] Internet-Draft DOTS Signal Filter Control June 2020 +--------------------+--------+-------+------------+---------------+ | Parameter Name | CBOR | CBOR | Change | Specification | | | Key | Major | Controller | Document(s) | | | Value | Type | | | +====================+========+=======+============+===============+ | activation-type | 52 | | | | | | (TBA1) | 0 | IESG | [RFCXXXX] | +--------------------+--------+-------+------------+---------------+ | ietf-dots-signal- | 53 | | | | | control:acl-list | (TBA2) | 4 | IESG | [RFCXXXX] | +--------------------+--------+-------+------------+---------------+ 5.2. DOTS Signal Filtering Control YANG Module This document requests IANA to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document requests IANA to register the following YANG module in the "YANG Module Names" subregistry [RFC7950] within the "YANG Parameters" registry. Name: ietf-dots-signal-control Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control Maintained by IANA: N Prefix: dots-control Reference: RFC XXXX 6. Security Considerations The security considerations for the DOTS signal channel protocol are discussed in Section 10 of [RFC8782], while those for the DOTS data channel protocol are discussed in Section 10 of [RFC8783]. The following discusses the security considerations that are specific to the DOTS signal channel extension defined in this document. This specification does not allow to create new filtering rules, which is the responsibility of the DOTS data channel. DOTS client domains should be adequately prepared prior to an attack, e.g., by creating filters that will be activated on demand when an attack is detected. Nishizuka, et al. Expires December 27, 2020 [Page 23] Internet-Draft DOTS Signal Filter Control June 2020 A DOTS client is entitled to access only the resources it creates. In particular, a DOTS client can not tweak filtering rules created by other DOTS clients of the same DOTS client domain. As a reminder, DOTS servers must associate filtering rules with the DOTS client that created these resources. Failure to ensure such association by a DOTS server will have severe impact on DOTS client domains. A compromised DOTS client can use the filtering control capability to exacerbate an ongoing attack. Likewise, such a compromised DOTS client may abstain from reacting to an ACL conflict notification received from the DOTS server during attacks. These are not new attack vectors, but variations of threats discussed in [RFC8782] and [RFC8783]. DOTS operators should carefully monitor and audit DOTS agents to detect misbehaviors and to deter misuses. 7. Acknowledgements Many thanks to Wei Pan, Xia Liang, Jon Shallow, Dan Wing, Christer Holmberg, Shawn Emery, Tim Chown, Murray Kucherawy, Roman Danyliw, Erik Kline, and Eric Vyncke for the comments. Thanks to Benjamin Kaduk for the AD review. 8. References 8.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, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Nishizuka, et al. Expires December 27, 2020 [Page 24] Internet-Draft DOTS Signal Filter Control June 2020 [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of- Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, . [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, . 8.2. Informative References [I-D.ietf-dots-architecture] Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and R. Compton, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", draft-ietf-dots- architecture-18 (work in progress), March 2020. [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop test report, IETF 103 Hackathon", November 2018, . [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, . Authors' Addresses Nishizuka, et al. Expires December 27, 2020 [Page 25] Internet-Draft DOTS Signal Filter Control June 2020 Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: kaname@nttv6.jp Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore, Karnataka 560071 India Email: kondtir@gmail.com Takahiko Nagata Lepidum Japan Email: nagata@lepidum.co.jp Nishizuka, et al. Expires December 27, 2020 [Page 26] ./draft-ietf-bfcpbis-bfcp-websocket-15.txt0000644000764400076440000007345113046757044017706 0ustar iustyiusty BFCPBIS Working Group V. Pascual Internet-Draft Oracle Intended status: Standards Track A. Roman Expires: August 12, 2017 Quobis S. Cazeaux France Telecom Orange G. Salgueiro R. Ravindranath Cisco February 8, 2017 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) draft-ietf-bfcpbis-bfcp-websocket-15 Abstract The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 12, 2017. Copyright Notice Copyright (c) 2017 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 Pascual, et al. Expires August 12, 2017 [Page 1] Internet-Draft WebSocket as a Transport for BFCP February 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 3 4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 4 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. BFCP Encoding . . . . . . . . . . . . . . . . . . . . . . 5 5. Transport Reliability . . . . . . . . . . . . . . . . . . . . 5 6. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 6 6.1. Transport Negotiation . . . . . . . . . . . . . . . . . . 6 6.2. SDP Media Attributes . . . . . . . . . . . . . . . . . . 6 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Example Usage of 'websocket-uri' SDP Attribute . . . . . 7 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10.1. Registration of the WebSocket BFCP Sub-Protocol . . . . 10 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The WebSocket(WS) [RFC6455] protocol enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) [RFC5246]. The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure. The Binary Floor Control Protocol (BFCP) is a protocol to coordinate access to shared resources in a conference. It is defined in [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants Pascual, et al. Expires August 12, 2017 [Page 2] Internet-Draft WebSocket as a Transport for BFCP February 2017 and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. This document extends the applicability of [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis] to enable the usage of BFCP in these scenarios. The transport over which BFCP entities exchange messages depends on how the clients obtain information to contact the floor control server (e.g. using an Session Description Protocol (SDP) offer/answer exchange per [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described in RFC5018 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two transports for BFCP: TCP and UDP. This specification defines a new WebSocket sub-protocol (as defined in Section 1.9 in [RFC6455]) for transporting BFCP messages between a WebSocket client and server. This sub-protocol provides a reliable and boundary preserving transport for BFCP when run on top of TCP. Since WebSocket provides a reliable transport, the extensions defined in [I-D.ietf-bfcpbis-rfc4582bis] for sending BFCP over unreliable transports are not applicable. 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]. 2.1. Definitions BFCP WebSocket Client: Any BFCP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket BFCP sub-protocol as defined by this document. BFCP WebSocket Server: Any BFCP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket BFCP sub-protocol as defined by this document. 3. The WebSocket Protocol The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC5246]) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket sub-protocol and extensions Pascual, et al. Expires August 12, 2017 [Page 3] Internet-Draft WebSocket as a Transport for BFCP February 2017 negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes. The WebSocket connection handshake is based on HTTP [RFC7230] and utilizes the HTTP GET method with an "Upgrade" request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, client and server agree on the application protocol to use on top of the WebSocket transport. Such an application protocol (also known as a "WebSocket sub-protocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket BFCP sub-protocol defined in this document). Once the HTTP 101 response is processed both client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges. The WebSocket protocol defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer. 4. The WebSocket BFCP Sub-Protocol The term WebSocket sub-protocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket BFCP sub-protocol for carrying BFCP messages over a WebSocket connection. 4.1. Handshake The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage of the WebSocket BFCP sub-protocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The Client MUST include the value "BFCP" in the Sec-WebSocket-Protocol header in its handshake request. The 101 reply from the Server MUST contain "BFCP" in its corresponding Sec-WebSocket-Protocol header. Below is an example of a WebSocket handshake in which the Client requests the WebSocket BFCP sub-protocol support from the Server: Pascual, et al. Expires August 12, 2017 [Page 4] Internet-Draft WebSocket as a Transport for BFCP February 2017 GET / HTTP/1.1 Host: bfcp-ws.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://www.example.com Sec-WebSocket-Protocol: BFCP Sec-WebSocket-Version: 13 The handshake response from the Server accepting the WebSocket BFCP sub-protocol would look as follows: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: BFCP Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of BFCP messages. 4.2. BFCP Encoding BFCP messages use a TLV (Type-Length-Value) binary encoding, therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be transported in unfragmented binary WebSocket frames (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame data MUST be a valid BCFP message, so the length of the payload of the WebSocket frame MUST be lower than the maximum size allowed (2^16 +12 bytes) for a BCFP message as described in [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be followed. While this specification assumes that BFCP encoding is only TLV binary, future documents may define other mechanisms like JSON serialization. if encoding changes a new subprotocol identifier would need to be selected. Each BFCP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one BFCP message. 5. Transport Reliability WebSocket [RFC6455] provides a reliable transport and therefore the BFCP WebSocket sub-protocol defined by this document also provides reliable BFCP transport. Thus, client and server transactions using WebSocket for transport MUST follow the procedures for reliable Pascual, et al. Expires August 12, 2017 [Page 5] Internet-Draft WebSocket as a Transport for BFCP February 2017 transports as defined in [I-D.ietf-bfcpbis-rfc4582bis] and [I-D.ietf-bfcpbis-rfc4583bis]. BFCP WebSocket clients cannot receive incoming WebSocket connections initiated by any other peer. This means that a BFCP WebSocket client MUST actively initiate a connection towards a BFCP WebSocket server. The BFCP server is a will have a globally routable address and thus does not require ICE as clients always initiate connections to it. 6. SDP Considerations 6.1. Transport Negotiation Rules to generate an 'm' line for a BFCP stream are described in [I-D.ietf-bfcpbis-rfc4583bis], Section 3 New values are defined for the transport field: TCP/WS/BFCP and TCP/WSS/BFCP. TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn runs on top of TCP. TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn runs on top of TLS and TCP. The port field is set following the rules in Section 3 and Section 8.1 of [I-D.ietf-bfcpbis-rfc4583bis]. Depending on the value of the SDP 'setup' attribute defined in [RFC4145], the port field contains the port to which the remote endpoint will direct BFCP messages or is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of 9, which is the discard port. Connection attribute and port MUST follow the rules of [RFC4145] While this document recommends the use of secure WebSockets (i.e.TCP/ WSS) for security reasons, TCP/WS is also permitted so as to achieve maximum compatibility among clients. 6.2. SDP Media Attributes [I-D.ietf-bfcpbis-sdp-ws-uri] defines a new SDP attribute to indicate the connection Uniform Resource Identifier (URI) for the WebSocket Client. The SDP attribute 'websocket-uri' defined in Section 3 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be used when BFCP runs on top of WS or WSS. When the 'websocket-uri' attribute is present in the media section of the SDP, the procedures mentioned in Section 4 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be followed. Pascual, et al. Expires August 12, 2017 [Page 6] Internet-Draft WebSocket as a Transport for BFCP February 2017 7. SDP Offer/Answer Procedures 7.1. General An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each BFCP-over-WebSocket media stream and MUST assign either TCP/WSS/BFCP or TCP/WS/BFCP value to the "proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket. Furthermore, the server side, which could be either the offerer or answerer, MUST add an "a=websocket-uri" attribute in the media section depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in [I-D.ietf-bfcpbis-sdp-ws-uri]. Additionally, the SDP Offer/Answer procedures defined in Section 4 of [I-D.ietf-bfcpbis-sdp-ws-uri] MUST be followed for the "m=" line associated with a BFCP-over-WebSocket media stream. 7.2. Example Usage of 'websocket-uri' SDP Attribute The following is an example of an "m=" line for a BFCP connection. In this example, the offerer sends the SDP with the "proto" field having a value of TCP/WSS/BFCP * indicating that the offerer wishes to use secure WebSocket as a transport for the media stream. Offer (browser): m=application 9 TCP/WSS/BFCP * a=setup:active a=connection:new a=floorctrl:c-only m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31 Answer (server): m=application 50000 TCP/WSS/BFCP * a=setup:passive a=connection:new a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 Pascual, et al. Expires August 12, 2017 [Page 7] Internet-Draft WebSocket as a Transport for BFCP February 2017 It is possible that an endpoint (e.g., a browser) sends an offerless INVITE to the server. In such cases the server will act as SDP offerer. The server MUST assign the SDP "setup" attribute with a value of "passive". The server MUST have an "a=websocket-uri" attribute with a "ws-URI" or "wss-URI" value depending on whether the server wishes to use WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3 of [I-D.ietf-bfcpbis-sdp-ws-uri] . For BFCP application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST be TCP/WS/BFCP. 8. Authentication Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients and floor control servers SHOULD authenticate each other prior to accepting messages, and RECOMMENDS that mutual TLS/DTLS authentication be used. However, browser-based WebSocket clients have no control over the use of TLS in the WebSocket API [WS-API], so it is RECOMMENDED that standard Web-based methods for client and server authentication are used, as follows. When a BFCP WebSocket client connects to a BFCP WebSocket server, it SHOULD use TCP/WSS as its transport. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, Secure WebSocket (WSS) MUST be used, and the floor control server MUST authenticate the client.. The WebSocket client MUST follow the procedures in [RFC7525] while setting up TLS connection with the WebSocket server. The BFCP client validates the server by means of verifying the server certificate. This means the "websocket-uri" value MUST contain a hostname. The verification process does not use a=fingerprint. A floor control server that receives a message over TCP/WS can mandate the use of TCP/WSS by generating an Error message, as described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an Error code with a value of 9 (use TLS). Prior to sending BFCP requests, a BFCP WebSocket client connects to a BFCP WebSocket server and performs the connection handshake. As described in Section 3 the handshake procedure involves a HTTP GET method request from the client and a response from the server including an HTTP 101 status code. In order to authorize the WebSocket connection, the BFCP WebSocket server SHOULD inspect any cookie [RFC6265] headers present in the HTTP GET request. For many web applications the value of such a cookie is provided by the web server once the user has authenticated themselves to the web server, which could be done by many existing Pascual, et al. Expires August 12, 2017 [Page 8] Internet-Draft WebSocket as a Transport for BFCP February 2017 mechanisms. As an alternative method, the BFCP WebSocket Server could request HTTP authentication by replying to the Client's GET method request with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers this usage in Section 4.1: If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures, in particular the client might perform authentication if it receives 401 status code. If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures, in particular the client might perform authentication if it receives 401 status code. The WebSocket clients are vulnerable to the attacks of basic authentication (mentioned in Section 4 of [RFC7617]) and digest authentication (mentioned in Section 5 of [RFC7616]]). To overcome some of these weakness, the WebSocket clients for example can use HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in [RFC7486]. 9. Security Considerations Considerations from [I-D.ietf-bfcpbis-rfc4582bis], [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. It is RECOMMENDED that the BFCP traffic transported over a WebSocket communication be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP). The security considerations in [RFC6455] apply for BFCP over WebSocket as well. The security model here is a typical webserver- client model where the client validates the server certificate and then connects to the server. Section 8 describes the authentication procedures between client and server. When using BFCP over websockets, the security mechanisms defined in [I-D.ietf-bfcpbis-rfc4582bis] are not used. Instead, the application is required to build and rely on the security mechanisms in [RFC6455]. The rest of this section analyses the threats described in Section 14 of [I-D.ietf-bfcpbis-rfc4582bis] when WebSocket is used as transport protocol for BFCP. An attacker attempting to impersonate a floor control server is avoided by having servers accept BFCP messages over WSS only. As with any other web connection, the clients will verify the servers certificate. The floor control WebSocket client MUST follow the Pascual, et al. Expires August 12, 2017 [Page 9] Internet-Draft WebSocket as a Transport for BFCP February 2017 procedures in [RFC7525] (including hostname verification as per Section 6.1 in [RFC7525]) while setting up TLS connection with floor control webSocket server. An attacker attempting to impersonate a floor control client is avoided by having servers accept BFCP messages over WSS only. As described in Section 10.5 of [RFC6455] the floor control server can use any client authentication mechanism and follow the steps in Section 8 of this document. Attackers may attempt to modify messages exchanged by a client and a floor control server. This can be prevented by having WSS between client and server. An attacker trying to replay the messages is prevented by having floor control servers check that messages arriving over a given WSS connection use an authorized user ID. Attackers may may eavesdrop on the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). In order to ensure that BFCP users are getting the level of protection that they would get using the BFCP protocol directly, applications need to have a way to control the websocket libraries to use encryption algorithms specified in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis] . Since the WebSocket API [WS-API] does not have a way to allow an application to select the encryption algorithm to be used, the protection level provided when WSS is used is limited to the underlying TLS algorithm used by WebSocket library. 10. IANA Considerations 10.1. Registration of the WebSocket BFCP Sub-Protocol This specification requests IANA to register the WebSocket BFCP sub- protocol under the "WebSocket Subprotocol Name" Registry with the following data: Subprotocol Identifier: BFCP Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor Control Protocol) Subprotocol Definition: RFCXXXX [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]] Pascual, et al. Expires August 12, 2017 [Page 10] Internet-Draft WebSocket as a Transport for BFCP February 2017 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values This document defines two new values for the SDP 'proto' field under the Session Description Protocol (SDP) Parameters registry. The resulting entries are shown in Figure 1 below: Value Reference ---------- ----------- TCP/WS/BFCP RFCXXXX; TCP/WSS/BFCP RFCXXXX; Figure 1: Values for the SDP 'proto' Field [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]] 11. Acknowledgements The authors want to thank Robert Welbourn, from Acme Packet and Sergio Garcia Murillo who made significant contributions to the first version of this document. This work benefited from the thorough review and constructive comments of Charles Eckel, Christer Holmberg, Paul Kyzivat, Dan Wing and Alissa Cooper. Thanks to Bert Wijnen, Robert Sparks and Mirja Kuehlewind for their reviews and comments on this document. Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey Melnikov, Jari Arkko and Stephen Farrell for their feedback and comments during IESG reviews. 12. References 12.1. Normative References [I-D.ietf-bfcpbis-rfc4582bis] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", draft- ietf-bfcpbis-rfc4582bis-16 (work in progress), November 2015. [I-D.ietf-bfcpbis-rfc4583bis] Camarillo, G., Kristensen, T., and P. Jones, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-16 (work in progress), September 2016. Pascual, et al. Expires August 12, 2017 [Page 11] Internet-Draft WebSocket as a Transport for BFCP February 2017 [I-D.ietf-bfcpbis-sdp-ws-uri] R, R. and G. Salgueiro, "Session Description Protocol (SDP) WebSocket Connection URI Attribute", draft-ietf- bfcpbis-sdp-ws-uri-09 (work in progress), February 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/RFC5018, September 2007, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [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, . 12.2. Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [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, . Pascual, et al. Expires August 12, 2017 [Page 12] Internet-Draft WebSocket as a Transport for BFCP February 2017 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, . [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. Authors' Addresses Victor Pascual Oracle Email: victor.pascual.avila@oracle.com Anton Roman Quobis Email: anton.roman@quobis.com Stephane Cazeaux France Telecom Orange Email: stephane.cazeaux@orange.com Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: gsalguei@cisco.com Pascual, et al. Expires August 12, 2017 [Page 13] Internet-Draft WebSocket as a Transport for BFCP February 2017 Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com Pascual, et al. Expires August 12, 2017 [Page 14] ./draft-ietf-httpbis-expect-ct-08.txt0000644000764400076440000014426413403264142016741 0ustar iustyiusty HTTP E. Stark Internet-Draft Google Intended status: Experimental December 9, 2018 Expires: June 12, 2019 Expect-CT Extension for HTTP draft-ietf-httpbis-expect-ct-08 Abstract This document defines a new HTTP header field named Expect-CT, which allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency deployments. Further, web host operaters can use Expect-CT to ensure that, if a UA which supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at http://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/expect-ct [3]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 12, 2019. Stark Expires June 12, 2019 [Page 1] Internet-Draft Expect-CT December 2018 Copyright Notice Copyright (c) 2018 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 (https://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 5 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 5 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 6 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 7 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 7 2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Host Processing Model . . . . . . . . . . . . . . . . . . 8 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 8 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8 2.3.1. Missing or Malformed Expect-CT Header Fields . . . . 9 2.3.2. Expect-CT Header Field Processing . . . . . . . . . . 9 2.3.3. Reporting . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 11 2.4.1. Skipping CT compliance checks . . . . . . . . . . . . 12 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 12 3.1. Generating a violation report . . . . . . . . . . . . . . 12 3.2. Sending a violation report . . . . . . . . . . . . . . . 14 3.3. Receiving a violation report . . . . . . . . . . . . . . 15 4. Usability Considerations . . . . . . . . . . . . . . . . . . 16 5. Authoring Considerations . . . . . . . . . . . . . . . . . . 16 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.1. Hostile header attacks . . . . . . . . . . . . . . . . . 17 7.2. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 17 7.3. Amplification attacks . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. Header Field Registry . . . . . . . . . . . . . . . . . . 18 Stark Expires June 12, 2019 [Page 2] Internet-Draft Expect-CT December 2018 8.2. Media Types Registry . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Since -07 . . . . . . . . . . . . . . . . . . . . . . . . 21 A.2. Since -06 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. Since -05 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.4. Since -04 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.5. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.6. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.7. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.8. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document defines a new HTTP header field that enables UAs to identify web hosts that expect the presence of Signed Certificate Timestamps (SCTs) [I-D.ietf-trans-rfc6962-bis] in subsequent Transport Layer Security (TLS) [RFC8446] connections. Web hosts that serve the Expect-CT HTTP header field are noted by the UA as Known Expect-CT Hosts. The UA evaluates each connection to a Known Expect-CT Host for compliance with the UA's Certificate Transparency (CT) Policy. If the connection violates the CT Policy, the UA sends a report to a URI configured by the Expect-CT Host and/ or fails the connection, depending on the configuration that the Expect-CT Host has chosen. If misconfigured, Expect-CT can cause unwanted connection failures (for example, if a host deploys Expect-CT but then switches to a legitimate certificate that is not logged in Certificate Transparency logs, or if a web host operator believes their certificate to conform to all UAs' CT policies but is mistaken). Web host operators are advised to deploy Expect-CT with precautions, by using the reporting feature and gradually increasing the time interval during which the UA regards the host as a Known Expect-CT Host. These precautions can help web host operators gain confidence that their Expect-CT deployment is not causing unwanted connection failures. Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to require SCTs for the connection. Thus, the UA will not be able to detect and thwart an attack on the UA's first connection to the host. Still, Expect-CT provides value by 1) allowing UAs to detect the use of unlogged certificates after the initial communication, and 2) Stark Expires June 12, 2019 [Page 3] Internet-Draft Expect-CT December 2018 allowing web hosts to be confident that UAs are only trusting publicly-auditable certificates. Expect-CT is similar to HSTS [RFC6797] and HPKP [RFC7469]. HSTS allows web sites to declare themselves accessible only via secure connections, and HPKP allows web sites to declare their cryptographic identifies. Similarly, Expect-CT allows web sites to declare themselves accessible only via connections that are compliant with CT policy. This Expect-CT specification is compatible with [RFC6962] and [I-D.ietf-trans-rfc6962-bis], but not with future versions of Certificate Transparency. Expect-CT header fields will be ignore from web hosts which use future versions of Certificate Transparency, unless a future version of this document specifies how they should be processed. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Terminology is defined in this section. o "Certificate Transparency Policy" is a policy defined by the UA concerning the number, sources, and delivery mechanisms of Signed Certificate Timestamps that are associated with TLS connections. The policy defines the properties of a connection that must be met in order for the UA to consider it CT-qualified. o "Certificate Transparency Qualified" describes a TLS connection for which the UA has determined that a sufficient quantity and quality of Signed Certificate Timestamps have been provided. o "CT-qualified" is an abbreviation for "Certificate Transparency Qualified". o "CT Policy" is an abbreviation for "Certificate Transparency Policy". o "Effective Expect-CT Date" is the time at which a UA observed a valid Expect-CT header field for a given host. Stark Expires June 12, 2019 [Page 4] Internet-Draft Expect-CT December 2018 o "Expect-CT Host" is a conformant host implementing the HTTP server aspects of Expect-CT. This means that an Expect-CT Host returns the "Expect-CT" HTTP response header field in its HTTP response messages sent over secure transport. The term "host" is equivalent to "server" in this specification. o "Known Expect-CT Host" is an Expect-CT Host that the UA has noted as such. See Section 2.3.2.1 for particulars. o UA is an acronym for "user agent". For the purposes of this specification, a UA is an HTTP client application typically actively manipulated by a user [RFC7230]. o "Unknown Expect-CT Host" is an Expect-CT Host that the UA has not noted. 2. Server and Client Behavior 2.1. Response Header Field Syntax The "Expect-CT" response header field is a new field defined in this specification. It is used by a server to indicate that UAs should evaluate connections to the host emitting the header field for CT compliance (Section 2.4). Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in [RFC5234] and the rules defined in Section 3.2 of [RFC7230]. The "#" ABNF extension is specified in Section 7 of [RFC7230]. Expect-CT = 1#expect-ct-directive expect-ct-directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token / quoted-string Figure 1: Syntax of the Expect-CT header field The directives defined in this specification are described below. The overall requirements for directives are: 1. The order of appearance of directives is not significant. 2. A given directive MUST NOT appear more than once in a given header field. Directives are either optional or required, as stipulated in their definitions. 3. Directive names are case insensitive. Stark Expires June 12, 2019 [Page 5] Internet-Draft Expect-CT December 2018 4. UAs MUST ignore any header fields containing directives, or other header field value data that do not conform to the syntax defined in this specification. In particular, UAs MUST NOT attempt to fix malformed header fields. 5. If a header field contains any directive(s) the UA does not recognize, the UA MUST ignore those directives. 6. If the Expect-CT header field otherwise satisfies the above requirements (1 through 5), and Expect-CT is not disabled for local policy reasons (as discussed in Section 2.4.1), the UA MUST process the directives it recognizes. 2.1.1. The report-uri Directive The OPTIONAL "report-uri" directive indicates the URI to which the UA SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the reports to the given URI as described in Section 3. The "report-uri" directive is REQUIRED to have a directive value, for which the syntax is defined in Figure 2. report-uri-value = absolute-URI Figure 2: Syntax of the report-uri directive value "absolute-URI" is defined in Section 4.3 of [RFC3986]. UAs MUST ignore "report-uri"s that do not use the HTTPS scheme. UAs MUST check Expect-CT compliance when the host in the "report-uri" is a Known Expect-CT Host; similarly, UAs MUST apply HSTS [RFC6797] if the host in the "report-uri" is a Known HSTS Host. UAs SHOULD make their best effort to report Expect-CT failures to the "report-uri", but they may fail to report in exceptional conditions. For example, if connecting to the "report-uri" itself incurs an Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. Similarly, if Expect-CT Host A sets a "report-uri" referring to Expect-CT Host B, and if B sets a "report- uri" referring to A, and if both hosts fail to comply to the UA's CT Policy, the UA SHOULD detect and break the loop by failing to send reports to and about those hosts. Note that the report-uri need not necessarily be in the same Internet domain or web origin as the host being reported about. Hosts are in fact encouraged to use a separate host as the report-uri, so that CT failures on the Expect-CT host do not prevent reports from being sent. Stark Expires June 12, 2019 [Page 6] Internet-Draft Expect-CT December 2018 UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the same report to the same "report-uri" more than once in the same web browsing session. 2.1.2. The enforce Directive The OPTIONAL "enforce" directive is a valueless directive that, if present (i.e., it is "asserted"), signals to the UA that compliance to the CT Policy should be enforced (rather than report-only) and that the UA should refuse future connections that violate its CT Policy. When both the "enforce" directive and "report-uri" directive (as defined in Figure 2) are present, the configuration is referred to as an "enforce-and-report" configuration, signalling to the UA both that compliance to the CT Policy should be enforced and that violations should be reported. 2.1.3. The max-age Directive The "max-age" directive specifies the number of seconds after the reception of the Expect-CT header field during which the UA SHOULD regard the host from whom the message was received as a Known Expect- CT Host. If a response contains an "Expect-CT" header field, then the response MUST contain an "Expect-CT" header field with a "max-age" directive. (A "max-age" directive need not appear in every "Expect-CT" header field in the response.) The "max-age" directive is REQUIRED to have a directive value, for which the syntax (after quoted-string unescaping, if necessary) is defined in Figure 3. max-age-value = delta-seconds delta-seconds = 1*DIGIT Figure 3: Syntax of the max-age directive value "delta-seconds" is used as defined in Section 1.2.1 of [RFC7234]. 2.1.4. Examples The following three examples demonstrate valid Expect-CT response header fields (where the second splits the directives into two field instances): Stark Expires June 12, 2019 [Page 7] Internet-Draft Expect-CT December 2018 Expect-CT: max-age=86400, enforce Expect-CT: max-age=86400,enforce Expect-CT: report-uri="https://foo.example/report" Expect-CT: max-age=86400,report-uri="https://foo.example/report" Figure 4: Examples of valid Expect-CT response header fields 2.2. Host Processing Model This section describes the processing model that Expect-CT Hosts implement. The model has 2 parts: (1) the processing rules for HTTP request messages received over a secure transport (e.g., authenticated, non-anonymous TLS); and (2) the processing rules for HTTP request messages received over non-secure transports, such as TCP. 2.2.1. HTTP-over-Secure-Transport Request Type An Expect-CT Host includes an Expect-CT header field in its response. The header field MUST satisfy the grammar specified in Section 2.1. Establishing a given host as an Expect-CT Host, in the context of a given UA, is accomplished as follows: 1. Over the HTTP protocol running over secure transport, by correctly returning (per this specification) a valid Expect-CT header field to the UA. 2. Through other mechanisms, such as a client-side preloaded Expect- CT Host list. 2.2.2. HTTP Request Type Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP responses conveyed over non-secure transport. 2.3. User Agent Processing Model The UA processing model relies on parsing domain names. Note that internationalized domain names SHALL be canonicalized by the UA according to the scheme in Section 10 of [RFC6797]. The UA stores Known Expect-CT Hosts and their associated Expect-CT directives. This data is collectively known as a host's "Expect-CT" metadata". Stark Expires June 12, 2019 [Page 8] Internet-Draft Expect-CT December 2018 2.3.1. Missing or Malformed Expect-CT Header Fields If an HTTP response does not include an Expect-CT header field that conforms to the grammar specified in Section 2.1, then the UA MUST NOT update any Expect-CT metadata. 2.3.2. Expect-CT Header Field Processing If the UA receives an HTTP response over a secure transport that includes an Expect-CT header field conforming to the grammar specified in Section 2.1, the UA MUST evaluate the connection on which the header field was received for compliance with the UA's CT Policy, and then process the Expect-CT header field as follows. UAs MUST ignore any Expect-CT header field received in an HTTP response conveyed over non-secure transport. If the connection does not comply with the UA's CT Policy (i.e., the connection is not CT-qualified), then the UA MUST NOT update any Expect-CT metadata. If the header field includes a "report-uri" directive, the UA SHOULD send a report to the specified "report-uri" (Section 2.3.3). If the connection complies with the UA's CT Policy (i.e., the connection is CT-qualified), then the UA MUST either: o Note the host as a Known Expect-CT Host if it is not already so noted (see Section 2.3.2.1), or o Update the UA's cached information for the Known Expect-CT Host if the "enforce", "max-age", or "report-uri" header field value directives convey information different from that already maintained by the UA. If the "max-age" directive has a value of 0, the UA MUST remove its cached Expect-CT information if the host was previously noted as a Known Expect-CT Host, and MUST NOT note this host as a Known Expect-CT Host if it is not already noted. If a UA receives an Expect-CT header field over a CT-compliant connection which uses a version of Certificate Transparency other than [RFC6962] or [I-D.ietf-trans-rfc6962-bis], the UA MUST ignore the Expect-CT header field and clear any Expect-CT metadata associated with the host. 2.3.2.1. Noting Expect-CT Upon receipt of the Expect-CT response header field over an error- free TLS connection (with X.509 certificate chain validation as described in [RFC5280], as well as the validation described in Section 2.4), the UA MUST note the host as a Known Expect-CT Host, Stark Expires June 12, 2019 [Page 9] Internet-Draft Expect-CT December 2018 storing the host's domain name and its associated Expect-CT directives in non-volatile storage. To note a host as a Known Expect-CT Host, the UA MUST set its Expect- CT metadata in its Known Expect-CT Host cache (as specified in Section 2.3.2.2, using the metadata given in the most recently received valid Expect-CT header field. For forward compatibility, the UA MUST ignore any unrecognized Expect-CT header field directives, while still processing those directives it does recognize. Section 2.1 specifies the directives "enforce", "max-age", and "report-uri", but future specifications and implementations might use additional directives. 2.3.2.2. Storage Model If the substring matching the host production from the Request-URI (of the message to which the host responded) does not exactly match an existing Known Expect-CT Host's domain name, per the matching procedure for a Congruent Match specified in Section 8.2 of [RFC6797], then the UA MUST add this host to the Known Expect-CT Host cache. The UA caches: o the Expect-CT Host's domain name, o whether the "enforce" directive is present o the Effective Expiration Date, which is the Effective Expect-CT Date plus the value of the "max-age" directive. Alternatively, the UA MAY cache enough information to calculate the Effective Expiration Date. The Effective Expiration Date is calculated from when the UA observed the Expect-CT header field and is independent of when the response was generated. o the value of the "report-uri" directive, if present. If any other metadata from optional or future Expect-CT header directives are present in the Expect-CT header field, and the UA understands them, the UA MAY note them as well. UAs MAY set an upper limit on the value of max-age, so that UAs that have noted erroneous Expect-CT hosts (whether by accident or due to attack) have some chance of recovering over time. If the server sets a max-age greater than the UA's upper limit, the UA may behave as if the server set the max-age to the UA's upper limit. For example, if the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT Host sets a max- age directive of 90 days in its Expect-CT header field, the UA may behave as if the max-age were effectively 60 days. Stark Expires June 12, 2019 [Page 10] Internet-Draft Expect-CT December 2018 (One way to achieve this behavior is for the UA to simply store a value of 60 days instead of the 90-day value provided by the Expect- CT host.) 2.3.3. Reporting If the UA receives, over a secure transport, an HTTP response that includes an Expect-CT header field with a "report-uri" directive, and the connection does not comply with the UA's CT Policy (i.e., the connection is not CT-qualified), and the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD send a report to the specified "report-uri" as specified in Section 3. 2.4. Evaluating Expect-CT Connections for CT Compliance When a UA sets up a TLS connection, the UA determines whether the host is a Known Expect-CT Host according to its Known Expect-CT Host cache. An Expect-CT Host is "expired" if the effective expiration date refers to a date in the past. The UA MUST ignore any expired Expect-CT Hosts in its cache and not treat such hosts as Known Expect-CT hosts. When a UA connects to a Known Expect-CT Host using a TLS connection, if the TLS connection has no errors, then the UA will apply an additional correctness check: compliance with a CT Policy. A UA should evaluate compliance with its CT Policy whenever connecting to a Known Expect-CT Host. However, the check can be skipped for local policy reasons (as discussed in Section 2.4.1), or in the event that other checks cause the UA to terminate the connection before CT compliance is evaluated. For example, a Public Key Pinning failure [RFC7469] could cause the UA to terminate the connection before CT compliance is checked. Similarly, if the UA terminates the connection due to an Expect-CT failure, this could cause the UA to skip subsequent correctness checks. When the CT compliance check is skipped or bypassed, Expect-CT reports (Section 3) will not be sent. When CT compliance is evaluated for a Known Expect-CT Host, the UA MUST evaluate compliance when setting up the TLS session, before beginning an HTTP conversation over the TLS channel. If a connection to a Known Expect-CT Host violates the UA's CT policy (i.e., the connection is not CT-qualified), and if the Known Expect- CT Host's Expect-CT metadata indicates an "enforce" configuration, the UA MUST treat the CT compliance failure as an error. The UA MAY allow the user to bypass the error, unless connection errors should have no user recourse due to other policies in effect (such as HSTS, as described in Section 12.1 of [RFC6797]. Stark Expires June 12, 2019 [Page 11] Internet-Draft Expect-CT December 2018 If a connection to a Known Expect-CT Host violates the UA's CT policy, and if the Known Expect-CT Host's Expect-CT metadata includes a "report-uri", the UA SHOULD send an Expect-CT report to that "report-uri" (Section 3). 2.4.1. Skipping CT compliance checks It is acceptable for a UA to skip CT compliance checks for some hosts according to local policy. For example, a UA MAY disable CT compliance checks for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). If the UA does not evaluate CT compliance, e.g., because the user has elected to disable it, or because a presented certificate chain chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect- CT reports. 3. Reporting Expect-CT Failure When the UA attempts to connect to a Known Expect-CT Host and the connection is not CT-qualified, the UA SHOULD report Expect-CT failures to the "report-uri", if any, in the Known Expect-CT Host's Expect-CT metadata. When the UA receives an Expect-CT response header field over a connection that is not CT-qualified, if the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD report Expect-CT failures to the configured "report-uri", if any. 3.1. Generating a violation report To generate a violation report object, the UA constructs a JSON [RFC8259] object with the following keys and values: o "date-time": the value for this key indicates the UTC time that the UA observed the CT compliance failure. The value is a string formatted according to Section 5.6, "Internet Date/Time Format", of [RFC3339]. o "hostname": the value is the hostname to which the UA made the original request that failed the CT compliance check. The value is provided as a string. o "port": the value is the port to which the UA made the original request that failed the CT compliance check. The value is provided as an integer. Stark Expires June 12, 2019 [Page 12] Internet-Draft Expect-CT December 2018 o "scheme": the value is the scheme with which the UA made the original request that failed the CT compliance check. The value is provided as a string. This key is optional and is assumed to be "https" if not present. o "effective-expiration-date": the value indicates the Effective Expiration Date (see Section 2.3.2.2) for the Expect-CT Host that failed the CT compliance check, in UTC. The value is provided as a string formatted according to Section 5.6 of [RFC3339] ("Internet Date/Time Format"). o "served-certificate-chain": the value is the certificate chain as served by the Expect-CT Host during TLS session setup. The value is provided as an array of strings, which MUST appear in the order that the certificates were served; each string in the array is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in [RFC7468]. o "validated-certificate-chain": the value is the certificate chain as constructed by the UA during certificate chain verification. (This may differ from the value of the "served-certificate-chain" key.) The value is provided as an array of strings, which MUST appear in the order matching the chain that the UA validated; each string in the array is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in [RFC7468]. The first certificate in the chain represents the end- entity certificate being verified. UAs that build certificate chains in more than one way during the validation process SHOULD send the last chain built. o "scts": the value represents the SCTs (if any) that the UA received for the Expect-CT host and their validation statuses. The value is provided as an array of JSON objects. The SCTs may appear in any order. Each JSON object in the array has the following keys: * A "version" key, with an integer value. The UA MUST set this value to "1" if the SCT is in the format defined in Section 3.2 of [RFC6962] and "2" if it is in the format defined in Section 4.5 of [I-D.ietf-trans-rfc6962-bis]. * The "status" key, with a string value that the UA MUST set to one of the following values: "unknown" (indicating that the UA does not have or does not trust the public key of the log from which the SCT was issued), "valid" (indicating that the UA successfully validated the SCT as described in Section 5.2 of [RFC6962] or Section 8.2.3 of [I-D.ietf-trans-rfc6962-bis]), or Stark Expires June 12, 2019 [Page 13] Internet-Draft Expect-CT December 2018 "invalid" (indicating that the SCT validation failed because of a bad signature or an invalid timestamp). * The "source" key, with a string value that indicates from where the UA obtained the SCT, as defined in Section 3 of [RFC6962] and Section 6 of [I-D.ietf-trans-rfc6962-bis]. The UA MUST set the value to one of "tls-extension", "ocsp", or "embedded". These correspond to the three methods of delivering SCTs in the TLS handshake that are described in Section 3.3 of [RFC6962]. * The "serialized_sct" key, with a string value. If the value of the "version" key is "1", the UA MUST set this value to the base64 encoded [RFC4648] serialized "SignedCertificateTimestamp" structure from Section 3.2 of [RFC6962]. The base64 encoding is defined in Section 4 of [RFC4648]. If the value of the "version" key is "2", the UA MUST set this value to the base64 encoded [RFC4648] serialized "TransItem" structure representing the SCT, as defined in Section 4.5 of [I-D.ietf-trans-rfc6962-bis]. o "failure-mode": the value indicates whether the Expect-CT report was triggered by an Expect-CT policy in enforce or report-only mode. The value is provided as a string. The UA MUST set this value to "enforce" if the Expect-CT metadata indicates an "enforce" configuration, and "report-only" otherwise. o "test-report": the value is set to true if the report is being sent by a testing client to verify that the report server behaves correctly. The value is provided as a boolean, and MUST be set to true if the report serves to test the server's behavior and can be discarded. 3.2. Sending a violation report The UA SHOULD report Expect-CT failures for Known Expect-CT Hosts: that is, when a connection to a Known Expect-CT Host does not comply with the UA's CT Policy and the host's Expect-CT metadata contains a "report-uri". Additionally, the UA SHOULD report Expect-CT failures for hosts for which it does not have any stored Expect-CT metadata. That is, when the UA connects to a host and receives an Expect-CT header field which contains the "report-uri" directive, the UA SHOULD report an Expect-CT failure if the the connection does not comply with the UA's CT Policy. The steps to report an Expect-CT failure are as follows. Stark Expires June 12, 2019 [Page 14] Internet-Draft Expect-CT December 2018 1. Prepare a JSON object "report object" with the single key "expect-ct-report", whose value is the result of generating a violation report object as described in Section 3.1. 2. Let "report body" be the JSON stringification of "report object". 3. Let "report-uri" be the value of the "report-uri" directive in the Expect-CT header field. 4. Send an HTTP POST request to "report-uri" with a "Content-Type" header field of "application/expect-ct-report+json", and an entity body consisting of "report body". The UA MAY perform other operations as part of sending the HTTP POST request, for example sending a CORS preflight as part of [FETCH]. Future versions of this specification may need to modify or extend the Expect-CT report format. They may do so by defining a new top- level key to contain the report, replacing the "expect-ct-report" key. Section 3.3 defines how report servers should handle report formats that they do not support. 3.3. Receiving a violation report Upon receiving an Expect-CT violation report, the report server MUST respond with a 2xx (Successful) status code if it can parse the request body as valid JSON, the report conforms to the format described in Section 3.1, and it recognizes the scheme, hostname, and port in the "scheme", "hostname", and "port" fields of the report. If the report body cannot be parsed, or the report does not conform to the format described in Section 3.1, or the report server does not expect to receive reports for the scheme, hostname, or port in the report, then the report server MUST respond with a 400 Bad Request status code. As described in Section 3.2, future versions of this specification may define new report formats that are sent with a different top- level key. If the report server does not recognize the report format, the report server MUST respond with a 501 Not Implemented status code. If the report's "test-report" key is set to true, the server MAY discard the report without further processing but MUST still return a 2xx (Successful) status code. If the "test-report" key is absent or set to false, the server SHOULD store the report for processing and analysis by the owner of the Expect-CT Host. Stark Expires June 12, 2019 [Page 15] Internet-Draft Expect-CT December 2018 4. Usability Considerations When the UA detects a Known Expect-CT Host in violation of the UA's CT Policy, end users will experience denials of service. It is advisable for UAs to explain to users why they cannot access the Expect-CT Host, e.g., in a user interface that explains that the host's certificate cannot be validated. 5. Authoring Considerations Expect-CT could be specified as a TLS extension or X.509 certificate extension instead of an HTTP response header field. Using an HTTP header field as the mechanism for Expect-CT introduces a layering mismatch: for example, the software that terminates TLS and validates Certificate Transparency information might know nothing about HTTP. Nevertheless, an HTTP header field was chosen primarily for ease of deployment. In practice, deploying new certificate extensions requires certificate authorities to support them, and new TLS extensions require server software updates, including possibly to servers outside of the site owner's direct control (such as in the case of a third-party CDN). Ease of deployment is a high priority for Expect-CT because it is intended as a temporary transition mechanism for user agents that are transitioning to universal Certificate Transparency requirements. 6. Privacy Considerations Expect-CT can be used to infer what Certificate Transparency policy a UA is using, by attempting to retrieve specially-configured websites which pass one user agents' policies but not another's. Note that this consideration is true of UAs which enforce CT policies without Expect-CT as well. Additionally, reports submitted to the "report-uri" could reveal information to a third party about which webpage is being accessed and by which IP address, by using individual "report-uri" values for individually-tracked pages. This information could be leaked even if client-side scripting were disabled. Implementations store state about Known Expect-CT Hosts, and hence which domains the UA has contacted. Implementations may choose to not store this state subject to local policy (e.g., in the private browsing mode of a web browser). Violation reports, as noted in Section 3, contain information about the certificate chain that has violated the CT policy. In some cases, such as organization-wide compromise of the end-to-end security of TLS, this may include information about the interception Stark Expires June 12, 2019 [Page 16] Internet-Draft Expect-CT December 2018 tools and design used by the organization that the organization would otherwise prefer not be disclosed. Because Expect-CT causes remotely-detectable behavior, it's advisable that UAs offer a way for privacy-sensitive end users to clear currently noted Expect-CT hosts, and allow users to query the current state of Known Expect-CT Hosts. 7. Security Considerations 7.1. Hostile header attacks When UAs support the Expect-CT header field, it becomes a potential vector for hostile header attacks against site owners. If a site owner uses a certificate issued by a certificate authority which does not embed SCTs nor serve SCTs via OCSP or TLS extension, a malicious server operator or attacker could temporarily reconfigure the host to comply with the UA's CT policy, and add the Expect-CT header field in enforcing mode with a long "max-age". Implementing user agents would note this as an Expect-CT Host (see Section 2.3.2.1). After having done this, the configuration could then be reverted to not comply with the CT policy, prompting failures. Note this scenario would require the attacker to have substantial control over the infrastructure in question, being able to obtain different certificates, change server software, or act as a man-in-the-middle in connections. Site operators can mitigate this situation by one of: reconfiguring their web server to transmit SCTs using the TLS extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis], obtaining a certificate from an alternative certificate authority which provides SCTs by one of the other methods, or by waiting for the user agents' persisted notation of this as an Expect-CT host to reach its "max-age". User agents may choose to implement mechanisms for users to cure this situation, as noted in Section 4. 7.2. Maximum max-age There is a security trade-off in that low maximum values provide a narrow window of protection for users that visit the Known Expect-CT Host only infrequently, while high maximum values might result in a denial of service to a UA in the event of a hostile header attack, or simply an error on the part of the site-owner. There is probably no ideal maximum for the "max-age" directive. Since Expect-CT is primarily a policy-expansion and investigation technology rather than an end-user protection, a value on the order Stark Expires June 12, 2019 [Page 17] Internet-Draft Expect-CT December 2018 of 30 days (2,592,000 seconds) may be considered a balance between these competing security concerns. 7.3. Amplification attacks Another kind of hostile header attack uses the "report-uri" mechanism on many hosts not currently exposing SCTs as a method to cause a denial-of-service to the host receiving the reports. If some highly- trafficked websites emitted a non-enforcing Expect-CT header field with a "report-uri", implementing UAs' reports could flood the reporting host. It is noted in Section 2.1.1 that UAs should limit the rate at which they emit reports, but an attacker may alter the Expect-CT header's fields to induce UAs to submit different reports to different URIs to still cause the same effect. 8. IANA Considerations 8.1. Header Field Registry This document registers the "Expect-CT" header field in the "Permanent Message Header Field Names" registry located at https://www.iana.org/assignments/message-headers [4]. Header field name: Expect-CT Applicable protocol: http Status: experimental Author/Change controller: IETF Specification document(s): This document Related information: (empty) 8.2. Media Types Registry The MIME media type for Expect-CT violation reports is "application/ expect-ct-report+json" (which uses the suffix established in [RFC6839]). Type name: application Subtype name: expect-ct-report+json Required parameters: n/a Optional parameters: n/a Stark Expires June 12, 2019 [Page 18] Internet-Draft Expect-CT December 2018 Encoding considerations: binary Security considerations: See Section 7 Interoperability considerations: n/a Published specification: This document Applications that use this media type: UAs that implement Certificate Transparency compliance checks and reporting Additional information: Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a Person & email address to contact for further information: Emily Stark (estark@google.com) Intended usage: COMMON Restrictions on usage: none Author: Emily Stark (estark@google.com) Change controller: IETF 9. References 9.1. Normative References [I-D.ietf-trans-rfc6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", draft- ietf-trans-rfc6962-bis-30 (work in progress), November 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Stark Expires June 12, 2019 [Page 19] Internet-Draft Expect-CT December 2018 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, . [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [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, . [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, . Stark Expires June 12, 2019 [Page 20] Internet-Draft Expect-CT December 2018 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 9.2. Informative References [FETCH] WHATWG, "Fetch - Living Standard", n.d., . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 9.3. URIs [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] http://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/expect-ct [4] https://www.iana.org/assignments/message-headers Appendix A. Changes A.1. Since -07 o Editorial changes o Specify that the end-entity certificate appears first in the "validated-certificate-chain" field of an Expect-CT report. o Define how report format can be extended by future versions of this specification. Stark Expires June 12, 2019 [Page 21] Internet-Draft Expect-CT December 2018 o Add optional "scheme" key to report format. o Specify exact status codes for report server errors. o Limit report-uris to HTTPS only. o Note that this version of Expect-CT is only compatible with RFC 6962 and 6962-bis, not any future versions of CT. A.2. Since -06 o Editorial changes A.3. Since -05 o Remove SHOULD requirement that UAs disallow certificate error overrides for Known Expect-CT Hosts. o Remove restriction that Expect-CT Hosts cannot be IP addresses. o Editorial changes A.4. Since -04 o Editorial changes A.5. Since -03 o Editorial changes A.6. Since -02 o Add concept of test reports and specify that servers must respond with 2xx status codes to valid reports. o Add "failure-mode" key to reports to allow report servers to distinguish report-only from enforced failures. A.7. Since -01 o Change SCT reporting format to support both RFC 6962 and 6962-bis SCTs. A.8. Since -00 o Editorial changes Stark Expires June 12, 2019 [Page 22] Internet-Draft Expect-CT December 2018 o Change Content-Type header of reports to 'application/expect-ct- report+json' o Update header field syntax to match convention (issue #327) o Reference RFC 6962-bis instead of RFC 6962 Author's Address Emily Stark Google Email: estark@google.com Stark Expires June 12, 2019 [Page 23] ./draft-ietf-bfcpbis-rfc4582bis-16.txt0000644000764400076440000067005012621510104016560 0ustar iustyiusty BFCPbis Working Group G. Camarillo Internet-Draft Ericsson Obsoletes: 4582 (if approved) K. Drage Intended status: Standards Track Alcatel-Lucent Expires: May 16, 2016 T. Kristensen Cisco J. Ott Aalto University C. Eckel Cisco November 13, 2015 The Binary Floor Control Protocol (BFCP) draft-ietf-bfcpbis-rfc4582bis-16 Abstract Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 16, 2016. Camarillo, et al. Expires May 16, 2016 [Page 1] Internet-Draft BFCP November 2015 Copyright Notice Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . 8 3.2. Obtaining Information to Contact a Floor Control Server . 8 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 8 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 9 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 4.1. Floor Participant to Floor Control Server Interface . . . 10 4.2. Floor Chair to Floor Control Server Interface . . . . . . 14 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . 15 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . 18 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . 21 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . 21 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 22 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . 22 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . 23 5.2.6.1. Error-Specific Details for Error Code 4 . . . . . 24 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . 25 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 26 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 26 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 27 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 28 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . 29 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 29 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 30 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 31 5.2.17. FLOOR-REQUEST-STATUS . . . . . . . . . . . . . . . . 31 Camarillo, et al. Expires May 16, 2016 [Page 2] Internet-Draft BFCP November 2015 5.2.18. OVERALL-REQUEST-STATUS . . . . . . . . . . . . . . . 32 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . 33 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . 33 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . 33 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 33 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . 34 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 34 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . 34 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . 35 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 35 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 35 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . 35 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . 36 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.14. FloorRequestStatusAck . . . . . . . . . . . . . . . . 36 5.3.15. FloorStatusAck . . . . . . . . . . . . . . . . . . . 37 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 37 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . 37 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . 38 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . 39 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . 40 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 41 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . 41 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 42 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 43 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 43 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 44 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . 45 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 45 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . 46 9. Authentication and Authorization . . . . . . . . . . . . . . 46 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . 47 10. Floor Participant Operations . . . . . . . . . . . . . . . . 48 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . 48 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . 48 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . 49 10.1.3. Reception of a Subsequent FloorRequestStatus Message 50 10.2. Cancelling a Floor Request and Releasing a Floor . . . . 50 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . 50 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . 51 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 51 11.1. Sending a ChairAction Message . . . . . . . . . . . . . 51 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . 53 12. General Client Operations . . . . . . . . . . . . . . . . . . 53 Camarillo, et al. Expires May 16, 2016 [Page 3] Internet-Draft BFCP November 2015 12.1. Requesting Information about Floors . . . . . . . . . . 53 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . 53 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . 54 12.1.3. Reception of a Subsequent FloorStatus Message . . . 55 12.2. Requesting Information about Floor Requests . . . . . . 55 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . 55 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . 55 12.3. Requesting Information about a User . . . . . . . . . . 56 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . 56 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . 57 12.4. Obtaining the Capabilities of a Floor Control Server . . 57 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . 57 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . 57 13. Floor Control Server Operations . . . . . . . . . . . . . . . 58 13.1. Reception of a FloorRequest Message . . . . . . . . . . 58 13.1.1. Generating the First FloorRequestStatus Message . . 59 13.1.2. Generation of Subsequent FloorRequestStatus Messages 60 13.2. Reception of a FloorRequestQuery Message . . . . . . . . 61 13.3. Reception of a UserQuery Message . . . . . . . . . . . . 63 13.4. Reception of a FloorRelease Message . . . . . . . . . . 64 13.5. Reception of a FloorQuery Message . . . . . . . . . . . 65 13.5.1. Generation of the First FloorStatus Message . . . . 66 13.5.2. Generation of Subsequent FloorStatus Messages . . . 67 13.6. Reception of a ChairAction Message . . . . . . . . . . . 68 13.7. Reception of a Hello Message . . . . . . . . . . . . . . 69 13.8. Error Message Generation . . . . . . . . . . . . . . . . 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . 71 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . 72 15.3. Request Status Subregistry . . . . . . . . . . . . . . . 73 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . 74 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75 16.1. Extensions for an unreliable transport . . . . . . . . . 75 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . 76 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 18.1. Normative References . . . . . . . . . . . . . . . . . . 78 18.2. Informational References . . . . . . . . . . . . . . . . 79 Appendix A. Example Call Flows for BFCP over an Unreliable Transport . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. Motivation for Supporting an Unreliable Transport . 85 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 85 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 87 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . 88 Camarillo, et al. Expires May 16, 2016 [Page 4] Internet-Draft BFCP November 2015 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . 89 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 1. Introduction Within a conference, some applications need to manage the access to a set of shared resources, such as the right to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources. The Requirements for Floor Control Protocol [15] list a set of requirements that need to be met by floor control protocols. The Binary Floor Control Protocol (BFCP), which is specified in this document, meets these requirements. In addition, BFCP has been designed so that it can be used in low- bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keeps the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in a significant way. The remainder of this document is organized as follows: Section 2 defines the terminology used throughout this document, Section 3 discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP and which ones are performed using different mechanisms), Section 4 provides a non-normative overview of BFCP operation, and subsequent sections provide the normative specification of BFCP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. Media Participant: An entity that has access to the media resources of a conference (e.g., it can receive a media stream). In floor- controlled conferences, a given media participant is typically colocated with a floor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. Camarillo, et al. Expires May 16, 2016 [Page 5] Internet-Draft BFCP November 2015 The protocol between a floor participant and a media participant (that are not colocated) is outside the scope of this document. Client: A floor participant or a floor chair that communicates with a floor control server using BFCP. Floor: A temporary permission to access or manipulate a specific shared resource or set of resources. Floor Chair: A logical entity that manages one floor (grants, denies, or revokes a floor). An entity that assumes the logical role of a floor chair for a given transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floor chair and floor participant are defined on a transaction-by- transaction basis. BFCP transactions are defined in Section 8. Floor Control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. Floor Control Server: A logical entity that maintains the state of the floor(s), including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server. The floor control server of a conference may perform other logical roles (e.g., floor participant) in another conference. Floor Participant: A logical entity that requests floors, and possibly information about them, from a floor control server. An entity that assumes the logical role of a floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles of floor participant and floor chair are defined on a transaction-by-transaction basis. BFCP transactions are defined in Section 8. In floor-controlled conferences, a given floor participant is typically colocated with a media participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are not colocated. Participant: An entity that acts as a floor participant, as a media participant, or as both. BFCP Connection: A transport association between BFCP entities, used to exchange BFCP messages. Transaction Failure Window: When communicating over an unreliable transport, this is some period of time less than or equal to T1*2^4 Camarillo, et al. Expires May 16, 2016 [Page 6] Internet-Draft BFCP November 2015 (see Section 8.3). For reliable transports, this period of time is unbounded. 3. Scope As stated earlier, BFCP is a protocol to coordinate access to shared resources in a conference following the requirements defined in [15]. Floor control complements other functions defined in the XCON conferencing framework [16]. The floor control protocol BFCP defined in this document only specifies a means to arbitrate access to floors. The rules and constraints for floor arbitration and the results of floor assignments are outside the scope of this document and are defined by other protocols [16]. Figure 1 shows the tasks that BFCP can perform. +---------+ | Floor | | Chair | | | +---------+ ^ | | | Notification | | Decision | | | | Floor | v +-------------+ Request +---------+ +-------------+ | Floor |----------->| Floor | Notification | Floor | | Participant | | Control |------------->| Participant | | |<-----------| Server | | | +-------------+ Granted or +---------+ +-------------+ Denied Figure 1: Functionality provided by BFCP BFCP provides a means: o for floor participants to send floor requests to floor control servers. o for floor control servers to grant or deny requests to access a given resource from floor participants. o for floor chairs to send floor control servers decisions regarding floor requests. Camarillo, et al. Expires May 16, 2016 [Page 7] Internet-Draft BFCP November 2015 o for floor control servers to keep floor participants and floor chairs informed about the status of a given floor or a given floor request. Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them. 3.1. Floor Creation The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in [16]. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created). Conference control clients using CCMP [21] can specify such floor- related settings in the element [20] of the to-be created conference object provided in the body of a CCMP confRequest/ create message issued to the conference control server. 3.2. Obtaining Information to Contact a Floor Control Server A client needs a set of data in order to establish a BFCP connection to a floor control server. This data includes the transport address of the server, the conference identifier, and a user identifier. Clients can obtain this information in different ways. One is to use an SDP offer/answer [14] exchange, which is described in [10]. How to establish a connection to a BFCP floor control server outside the context of an offer/answer exchange when using a reliable transport is described in [4]. Other mechanisms are described in the XCON framework [16] (and other related documents). For unreliable transports, the use of an SDP offer/answer exchange is the only specified mechanism. 3.3. Obtaining Floor-Resource Associations Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio session as its associated resource. Associations between floors and resources are part of the conference object. Camarillo, et al. Expires May 16, 2016 [Page 8] Internet-Draft BFCP November 2015 Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer [14] exchange. How to use an SDP offer/answer exchange to obtain these associations is described in [10]. Note that floor participants perform SDP offer/answer exchanges with the conference focus of the conference. So, the conference focus needs to obtain information about associations between floors and resources in order to be able to provide this information to a floor participant in an SDP offer/answer exchange. Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP) Focus, are described in the XCON framework [16] (and other related documents). According to the conferencing system policies, conference control clients using CCMP [21] can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the element of the target conference object. More information about CCMP and BFCP interaction can be found in [22]. 3.4. Privileges of Floor Control A participant whose floor request is granted has the right to use the resource or resources associated with the floor that was requested. For example, the participant may have the right to send media over a particular audio stream. Nevertheless, holding a floor does not imply that others will not be able to use its associated resources at the same time, even if they do not have the right to do so. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework [16]. 4. Overview of Operation This section provides a non-normative description of BFCP operations. Section 4.1 describes the interface between floor participants and floor control servers, and Section 4.2 describes the interface between floor chairs and floor control servers. BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of a common header followed by a set of attributes. The common header contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers. Camarillo, et al. Expires May 16, 2016 [Page 9] Internet-Draft BFCP November 2015 BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes. There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. Section 8 describes both types of transactions in detail. 4.1. Floor Participant to Floor Control Server Interface Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not be colocated with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of the common header, and the identity of the beneficiary of the floor (in third- party floor requests) in a BENEFICIARY-ID attribute. Third-party floor requests can be sent, for example, by floor participants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media). FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message. Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest. Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request. Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatus Message from the floor control server. Camarillo, et al. Expires May 16, 2016 [Page 10] Internet-Draft BFCP November 2015 Figures 2 and 3 below show examples of call flows where BFCP is used over a reliable transport. Appendix A shows the same call flow examples using an unreliable transport. Figure 2 shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute. Floor Participant Floor Control Server |(1) FloorRequest | |Transaction ID: 123 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | Camarillo, et al. Expires May 16, 2016 [Page 11] Internet-Draft BFCP November 2015 | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(5) FloorRelease | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 | |---------------------------------------------->| | | |(6) FloorRequestStatus | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| Figure 2: Requesting and releasing a floor Figure 3 shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message. Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0 given this example uses a reliable transport. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted. Floor Participant Floor Control Server |(1) FloorQuery | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorStatus | Camarillo, et al. Expires May 16, 2016 [Page 12] Internet-Draft BFCP November 2015 |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(3) FloorStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(4) FloorStatus | |Transaction ID: 0 | Camarillo, et al. Expires May 16, 2016 [Page 13] Internet-Draft BFCP November 2015 |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| Figure 3: Obtaining status information about a floor FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request. A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same time). The floor control server treats a multi-floor floor request as an atomic package. That is, the floor control server either grants the request for all floors or denies the request for all floors. 4.2. Floor Chair to Floor Control Server Interface Figure 4 shows a floor chair instructing a floor control server to grant a floor. Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server. For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In Camarillo, et al. Expires May 16, 2016 [Page 14] Internet-Draft BFCP November 2015 another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant. So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state. Floor Chair Floor Control Server |(1) ChairAction | |Transaction ID: 769 | |User ID: 357 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | Request Status: Granted | |---------------------------------------------->| | | |(2) ChairActionAck | |Transaction ID: 769 | |User ID: 357 | |<----------------------------------------------| Figure 4: Chair instructing the floor control server 5. Packet Format BFCP packets consist of a 12-octet common header followed by attributes. All the protocol values MUST be sent in network byte order. 5.1. COMMON-HEADER Format The following is the format of the common header. Camarillo, et al. Expires May 16, 2016 [Page 15] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |R|F| Res | Primitive | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | User ID | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Fragment Offset (if F is set) | Fragment Length (if F is set) | +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---- These fragment fields are never present when using reliable transports Figure 5: COMMON-HEADER format Ver: This 3-bit field defines the version of BFCP that this message adheres to. This specification defines two versions: 1 and 2. The version field MUST be set to 1 when using BFCP over a reliable transport. The version field MUST be set to 2 when using BFCP over an unreliable transport. If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the server MUST indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version). Note that BFCP entities supporting only the [3] subset will not support this parameter value. R: The Transaction Responder (R) flag-bit has relevance only for use of BFCP over an unreliable transport. When cleared, it indicates that this message is a request initiating a new transaction, and the Transaction ID that follows has been generated for this transaction. When set, it indicates that this message is a response to a previous request, and the Transaction ID that follows is the one associated with that request. When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and MUST be ignored by the receiver. F: The Fragmentation (F) flag-bit has relevance only for use of BFCP over an unreliable transport. When cleared, the message is not fragmented. When set, it indicates that the message is a fragment of a large fragmented BFCP message. (The optional fields Fragment Offset and Fragment Length described below are present only if the F flag is set). When BFCP is used over a reliable transport, the flag has no significance and MUST be cleared by the sender and the flag MUST be ignored by the receiver. In the latter case, the receiver Camarillo, et al. Expires May 16, 2016 [Page 16] Internet-Draft BFCP November 2015 should also process the COMMON-HEADER as not having the Fragment Offset and Fragment Length fields present. Res: The 3 bits in the reserved field MUST be set to zero by the sender of the message and MUST be ignored by the receiver. Primitive: This 8-bit field identifies the main purpose of the message. The following primitive values are defined: +-------+-----------------------+--------------------------+ | Value | Primitive | Direction | +-------+-----------------------+--------------------------+ | 1 | FloorRequest | P -> S | | 2 | FloorRelease | P -> S | | 3 | FloorRequestQuery | P -> S ; Ch -> S | | 4 | FloorRequestStatus | P <- S ; Ch <- S | | 5 | UserQuery | P -> S ; Ch -> S | | 6 | UserStatus | P <- S ; Ch <- S | | 7 | FloorQuery | P -> S ; Ch -> S | | 8 | FloorStatus | P <- S ; Ch <- S | | 9 | ChairAction | Ch -> S | | 10 | ChairActionAck | Ch <- S | | 11 | Hello | P -> S ; Ch -> S | | 12 | HelloAck | P <- S ; Ch <- S | | 13 | Error | P <- S ; Ch <- S | | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | | 15 | FloorStatusAck | P -> S ; Ch -> S | | 16 | Goodbye | P -> S ; Ch -> S ; | | | | P <- S ; Ch <- S | | 17 | GoodbyeAck | P -> S ; Ch -> S ; | | | | P <- S ; Ch <- S | +-------+-----------------------+--------------------------+ S: Floor Control Server / P: Floor Participant / Ch: Floor Chair Table 1: BFCP primitives Payload Length: This 16-bit field contains the length of the message in 4-octet units, excluding the common header. If a Floor Control Server receives a message with an incorrect Payload Length field value, the receiving server MUST send an Error message with parameter value 13 (Incorrect Message Length) to indicate this and then discard the message. Other entities that receive a message with an incorrect length MUST discard the message. Note: BFCP is designed to achieve small message size, as explained in Section 1, and BFCP entities are required to keep the BFCP message size smaller than the size limited by the 16-bit Payload Camarillo, et al. Expires May 16, 2016 [Page 17] Internet-Draft BFCP November 2015 Length field. To convey information not strictly related to floor control, other protocols should be used such as the XCON framework (cf. Section 3). Conference ID: This 32-bit unsigned integer field identifies the conference to which the message belongs. It is RECOMMENDED that the conference identifier be randomly chosen. (Note that the use of predictable conference identifiers in conjunction with a non-secure transport protocol makes BFCP susceptible to off-path data injection attacks, where an attacker can forge a request or response message.) Transaction ID: This field contains a 16-bit value that allows users to match a given message with its response (see Section 8). User ID: This field contains a 16-bit unsigned integer that uniquely identifies a participant within a conference. The identity used by a participant in BFCP, which is carried in the User ID field, is generally mapped to the identity used by the same participant in the session establishment protocol (e.g., in SIP). The way this mapping is performed is outside the scope of this specification. Fragment Offset: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in previous fragments, excluding the common header. Fragment Length: This optional field is present only if the F flag is set and contains a 16-bit value that specifies the number of 4-octet units contained in this fragment, excluding the common header. BFCP entities that receive message fragments that, individually or collectively, exceed the Payload Length value MUST discard the message. Additionally, if the receiver is a Floor Control Server, it must also send an Error message with parameter value 13 (Incorrect Message Length) 5.2. Attribute Format BFCP attributes are encoded in TLV (Type-Length-Value) format. Attributes are 32-bit aligned. Camarillo, et al. Expires May 16, 2016 [Page 18] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Attribute Contents / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Attribute format Type: This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are: Unsigned16: The contents of the attribute consist of a 16-bit unsigned integer. OctetString16: The contents of the attribute consist of 16 bits of arbitrary data. OctetString: The contents of the attribute consist of arbitrary data of variable length. Grouped: The contents of the attribute consist of a sequence of attributes. Note that extension attributes defined in the future may define new attribute formats. The following attribute types are defined: Camarillo, et al. Expires May 16, 2016 [Page 19] Internet-Draft BFCP November 2015 +------+---------------------------+---------------+ | Type | Attribute | Format | +------+---------------------------+---------------+ | 1 | BENEFICIARY-ID | Unsigned16 | | 2 | FLOOR-ID | Unsigned16 | | 3 | FLOOR-REQUEST-ID | Unsigned16 | | 4 | PRIORITY | OctetString16 | | 5 | REQUEST-STATUS | OctetString16 | | 6 | ERROR-CODE | OctetString | | 7 | ERROR-INFO | OctetString | | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | | 9 | STATUS-INFO | OctetString | | 10 | SUPPORTED-ATTRIBUTES | OctetString | | 11 | SUPPORTED-PRIMITIVES | OctetString | | 12 | USER-DISPLAY-NAME | OctetString | | 13 | USER-URI | OctetString | | 14 | BENEFICIARY-INFORMATION | Grouped | | 15 | FLOOR-REQUEST-INFORMATION | Grouped | | 16 | REQUESTED-BY-INFORMATION | Grouped | | 17 | FLOOR-REQUEST-STATUS | Grouped | | 18 | OVERALL-REQUEST-STATUS | Grouped | +------+---------------------------+---------------+ Table 2: BFCP attributes M: The 'M' bit, known as the Mandatory bit, indicates whether support of the attribute is required. If a Floor Control Server receives an unrecognized attribute with the 'M' bit set the server MUST send an Error message with parameter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this document MUST be understood by the receiver so that the setting of the 'M' bit is irrelevant for these. Unrecognized attributes, such as those that might be specified in future extensions, that do not have the "M" bit set are ignored, but the message is processed. Length: This 8-bit field contains the length of the attribute in octets, excluding any padding defined for specific attributes. The length of attributes that are not grouped includes the Type, 'M' bit, and Length fields. The Length in grouped attributes is the length of the grouped attribute itself (including Type, 'M' bit, and Length fields) plus the total length (including padding) of all the included attributes. Attribute Contents: The contents of the different attributes are defined in the following sections. Camarillo, et al. Expires May 16, 2016 [Page 20] Internet-Draft BFCP November 2015 5.2.1. BENEFICIARY-ID The following is the format of the BENEFICIARY-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: BENEFICIARY-ID format Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference. Note that although the formats of the Beneficiary ID and of the User ID field in the common header are similar, their semantics are different. The Beneficiary ID is used in third-party floor requests and to request information about a particular participant. 5.2.2. FLOOR-ID The following is the format of the FLOOR-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: FLOOR-ID format Floor ID: This field contains a 16-bit value that uniquely identifies a floor within a conference. 5.2.3. FLOOR-REQUEST-ID The following is the format of the FLOOR-REQUEST-ID attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: FLOOR-REQUEST-ID format Camarillo, et al. Expires May 16, 2016 [Page 21] Internet-Draft BFCP November 2015 Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. 5.2.4. PRIORITY The following is the format of the PRIORITY attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: PRIORITY format Prio: This field contains a 3-bit priority value, as shown in Table 3. Senders SHOULD NOT use values higher than 4 in this field. Receivers MUST treat values higher than 4 as if the value received were 4 (Highest). The default priority value when the PRIORITY attribute is missing is 2 (Normal). +-------+----------+ | Value | Priority | +-------+----------+ | 0 | Lowest | | 1 | Low | | 2 | Normal | | 3 | High | | 4 | Highest | +-------+----------+ Table 3: Priority values Reserved: The 13 bits in the reserved field MUST be set to zero by the sender of the message and MUST be ignored by the receiver. 5.2.5. REQUEST-STATUS The following is the format of the REQUEST-STATUS attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: REQUEST-STATUS format Camarillo, et al. Expires May 16, 2016 [Page 22] Internet-Draft BFCP November 2015 Request Status: This 8-bit field contains the status of the request, as described in the following table. +-------+-----------+ | Value | Status | +-------+-----------+ | 1 | Pending | | 2 | Accepted | | 3 | Granted | | 4 | Denied | | 5 | Cancelled | | 6 | Released | | 7 | Revoked | +-------+-----------+ Table 4: Request Status values Queue Position: This 8-bit field contains, when applicable, the position of the floor request in the floor request queue at the server. If the Request Status value is different from Accepted, if the floor control server does not implement a floor request queue, or if the floor control server does not want to provide the client with this information, all the bits of this field SHOULD be set to zero. A floor request is in Pending state if the floor control server needs to contact a floor chair in order to accept the floor request, but has not done it yet. Once the floor control chair accepts the floor request, the floor request is moved to the Accepted state. 5.2.6. ERROR-CODE The following is the format of the ERROR-CODE attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 0|M| Length | Error Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: ERROR-CODE format Camarillo, et al. Expires May 16, 2016 [Page 23] Internet-Draft BFCP November 2015 Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognized by the receiver, then the receiver MUST assume that an error exists, and therefore that the original message that triggered the Error message to be sent is processed, but the nature of the error is unclear. +-------+-----------------------------------------------------------+ | Value | Meaning | +-------+-----------------------------------------------------------+ | 1 | Conference does not Exist | | 2 | User does not Exist | | 3 | Unknown Primitive | | 4 | Unknown Mandatory Attribute | | 5 | Unauthorized Operation | | 6 | Invalid Floor ID | | 7 | Floor Request ID Does Not Exist | | 8 | You have Already Reached the Maximum Number of Ongoing | | | Floor Requests for this Floor | | 9 | Use TLS | | 10 | Unable to Parse Message | | 11 | Use DTLS | | 12 | Unsupported Version | | 13 | Incorrect Message Length | | 14 | Generic Error | +-------+-----------------------------------------------------------+ Table 5: Error Code meaning Note: The Generic Error error code is intended to be used when an error occurs and the other specific error codes do not apply. Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 4 (Unknown Mandatory Attribute). See Section 5.2.6.1 for its definition. Padding: One, two, or three octets of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.6.1. Error-Specific Details for Error Code 4 The following is the format of the Error-Specific Details field for Error Code 4. Camarillo, et al. Expires May 16, 2016 [Page 24] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown Type|R| Unknown Type|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Unknown attributes format Unknown Type: These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to the receiver. R: This bit is reserved. It MUST be set to zero by the sender of the message and MUST be ignored by the receiver. 5.2.7. ERROR-INFO The following is the format of the ERROR-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: ERROR-INFO format Text: This field contains UTF-8 [9] encoded text. In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the Camarillo, et al. Expires May 16, 2016 [Page 25] Internet-Draft BFCP November 2015 receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.8. PARTICIPANT-PROVIDED-INFO The following is the format of the PARTICIPANT-PROVIDED-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: PARTICIPANT-PROVIDED-INFO format Text: This field contains UTF-8 [9] encoded text. Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.9. STATUS-INFO The following is the format of the STATUS-INFO attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: STATUS-INFO format Text: This field contains UTF-8 [9] encoded text. Camarillo, et al. Expires May 16, 2016 [Page 26] Internet-Draft BFCP November 2015 In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, it MAY use this language to generate the Text field. Padding: One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.10. SUPPORTED-ATTRIBUTES The following is the format of the SUPPORTED-ATTRIBUTES attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: SUPPORTED-ATTRIBUTES format Supp. Attr.: These fields contain the Types of the attributes that are supported by the floor control server in the following format: R: Reserved: This bit MUST be set to zero upon transmission and MUST be ignored upon reception. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.11. SUPPORTED-PRIMITIVES The following is the format of the SUPPORTED-PRIMITIVES attribute. Camarillo, et al. Expires May 16, 2016 [Page 27] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primitive | Primitive | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: SUPPORTED-PRIMITIVES format Primitive: These fields contain the types of the BFCP messages that are supported by the floor control server. See Table 1 for the list of BFCP primitives. Padding: One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. 5.2.12. USER-DISPLAY-NAME The following is the format of the USER-DISPLAY-NAME attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: USER-DISPLAY-NAME format Text: This field contains the UTF-8 encoded name of the user. Padding: One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by Camarillo, et al. Expires May 16, 2016 [Page 28] Internet-Draft BFCP November 2015 the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.13. USER-URI The following is the format of the USER-URI attribute. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: USER-URI format Text: This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of the user. Messages containing a user's URI in a USER-URI attribute also contain the user's User ID. This way, a client receiving such a message can correlate the user's URI (e.g., the SIP URI the user used to join a conference) with the user's User ID. Padding: One, two, or three octets of padding added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bits MUST be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. 5.2.14. BENEFICIARY-INFORMATION The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER: Camarillo, et al. Expires May 16, 2016 [Page 29] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 0|M| Length | Beneficiary ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: BENEFICIARY-INFORMATION-HEADER format Beneficiary ID: This field contains a 16-bit value that uniquely identifies a user within a conference. The following is the ABNF (Augmented Backus-Naur Form) [5] of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE Figure 22: BENEFICIARY-INFORMATION format 5.2.15. FLOOR-REQUEST-INFORMATION The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 1|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format Floor Request ID: This field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) Camarillo, et al. Expires May 16, 2016 [Page 30] Internet-Draft BFCP November 2015 FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER [OVERALL-REQUEST-STATUS] 1*FLOOR-REQUEST-STATUS [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO] *EXTENSION-ATTRIBUTE Figure 24: FLOOR-REQUEST-INFORMATION format 5.2.16. REQUESTED-BY-INFORMATION The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY- INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 0|M| Length | Requested-by ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: REQUESTED-BY-INFORMATION-HEADER format Requested-by ID: This field contains a 16-bit value that uniquely identifies a user within a conference. The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE Figure 26: REQUESTED-BY-INFORMATION format 5.2.17. FLOOR-REQUEST-STATUS The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-STATUS- HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-STATUS-HEADER: Camarillo, et al. Expires May 16, 2016 [Page 31] Internet-Draft BFCP November 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 0 1|M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: FLOOR-REQUEST-STATUS-HEADER format Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference. The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO] *EXTENSION-ATTRIBUTE Figure 28: FLOOR-REQUEST-STATUS format 5.2.18. OVERALL-REQUEST-STATUS The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS- HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 0 0 1 0|M| Length | Floor Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: OVERALL-REQUEST-STATUS-HEADER format Floor Request ID: this field contains a 16-bit value that identifies a floor request at the floor control server. The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.) Camarillo, et al. Expires May 16, 2016 [Page 32] Internet-Draft BFCP November 2015 OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO] *EXTENSION-ATTRIBUTE Figure 30: OVERALL-REQUEST-STATUS format 5.3. Message Format This section contains the normative ABNF (Augmented Backus-Naur Form) [5] of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 5.3.1. FloorRequest Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message: FloorRequest = COMMON-HEADER 1*FLOOR-ID [BENEFICIARY-ID] [PARTICIPANT-PROVIDED-INFO] [PRIORITY] *EXTENSION-ATTRIBUTE Figure 31: FloorRequest format 5.3.2. FloorRelease Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message: FloorRelease = COMMON-HEADER FLOOR-REQUEST-ID *EXTENSION-ATTRIBUTE Figure 32: FloorRelease format 5.3.3. FloorRequestQuery Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message: Camarillo, et al. Expires May 16, 2016 [Page 33] Internet-Draft BFCP November 2015 FloorRequestQuery = COMMON-HEADER FLOOR-REQUEST-ID *EXTENSION-ATTRIBUTE Figure 33: FloorRequestQuery format 5.3.4. FloorRequestStatus The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message: FloorRequestStatus = COMMON-HEADER FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 34: FloorRequestStatus format 5.3.5. UserQuery Floor participants and floor chairs request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message: UserQuery = COMMON-HEADER [BENEFICIARY-ID] *EXTENSION-ATTRIBUTE Figure 35: UserQuery format 5.3.6. UserStatus The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message: UserStatus = COMMON-HEADER [BENEFICIARY-INFORMATION] *FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 36: UserStatus format Camarillo, et al. Expires May 16, 2016 [Page 34] Internet-Draft BFCP November 2015 5.3.7. FloorQuery Floor participants and floor chairs request information about a floor or floors by sending a FloorQuery message to the floor control server. The following is the format of the FloorQuery message: FloorQuery = COMMON-HEADER *FLOOR-ID *EXTENSION-ATTRIBUTE Figure 37: FloorQuery format 5.3.8. FloorStatus The floor control server informs floor participants and floor chairs about the status (e.g., the current holder) of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message: FloorStatus = COMMON-HEADER *FLOOR-ID *FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 38: FloorStatus format 5.3.9. ChairAction Floor chairs send instructions to floor control servers by sending them ChairAction messages. The following is the format of the ChairAction message: ChairAction = COMMON-HEADER FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE Figure 39: ChairAction format 5.3.10. ChairActionAck Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message: ChairActionAck = COMMON-HEADER *EXTENSION-ATTRIBUTE Figure 40: ChairActionAck format Camarillo, et al. Expires May 16, 2016 [Page 35] Internet-Draft BFCP November 2015 5.3.11. Hello Floor participants and floor chairs MAY check the liveliness of floor control servers by sending a Hello message. Additionally, clients communicating with a floor control server over a an unreliable transport use the Hello message to initiate communication with the server. The following is the format of the Hello message: Hello = COMMON-HEADER *EXTENSION-ATTRIBUTE Figure 41: Hello format 5.3.12. HelloAck Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message: HelloAck = COMMON-HEADER SUPPORTED-PRIMITIVES SUPPORTED-ATTRIBUTES *EXTENSION-ATTRIBUTE Figure 42: HelloAck format 5.3.13. Error Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message: Error = COMMON-HEADER ERROR-CODE [ERROR-INFO] *EXTENSION-ATTRIBUTE Figure 43: Error format 5.3.14. FloorRequestStatusAck When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorRequestStatus message from the floor control server (cf. Section 13.1.2) by sending a FloorRequestStatusAck message. The following is the format of the FloorRequestStatusAck message: Camarillo, et al. Expires May 16, 2016 [Page 36] Internet-Draft BFCP November 2015 FloorRequestStatusAck = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 44: FloorRequestStatusAck format 5.3.15. FloorStatusAck When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorStatus message from the floor control server (cf. Section 13.5.2) by sending a FloorStatusAck message. The following is the format of the FloorStatusAck message: FloorStatusAck = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 45: FloorStatusAck format 5.3.16. Goodbye BFCP entities communicating over an unreliable transport that wish to dissociate themselves from their remote participant do so through the transmission of a Goodbye. The following is the format of the Goodbye message: Goodbye = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 46: Goodbye format 5.3.17. GoodbyeAck BFCP entities communicating over an unreliable transport acknowledge the receipt of a Goodbye message from a peer. The following is the format of the GoodbyeAck message: GoodbyeAck = (COMMON-HEADER) *EXTENSION-ATTRIBUTE Figure 47: GoodbyeAck format 6. Transport The transport over which BFCP entities exchange messages depends on the information the clients obtain for how to to contact the floor control server, as described in Section 3.2. Two transports are supported: TCP, appropriate where connectivity is not impeded by Camarillo, et al. Expires May 16, 2016 [Page 37] Internet-Draft BFCP November 2015 network elements such as NAT devices or media relays; and UDP for those deployments where TCP may not be applicable or appropriate. Informational note: In practice, products are configured to try one transport first and use the other transport as a fallback. Whether TCP or UDP is chosen as underlying transport depends on the type of product and the deployment environment. See Appendix B for additional considerations. 6.1. Reliable Transport BFCP entities may elect to exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing needs to be implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes. A client MUST NOT use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed. If a BFCP entity (a client or a floor control server) receives data that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connection SHOULD be reestablished. The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server. Once the TCP connection is reestablished, the client MAY resend those messages for which it did not get a response from the floor control server. If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it is RECOMMENDED that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished. If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been Camarillo, et al. Expires May 16, 2016 [Page 38] Internet-Draft BFCP November 2015 kicked out from the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client. In cases where a BFCP entity reestablishes a connection due to protocol errors as described above, the entity SHOULD NOT repeatedly reestablish the connection. Rather, if the same protocol errors persist, the entity MUST cease attempts and SHOULD report the error to the human user and/or log the event. This does not preclude the entity from reestablishing a connection when facing a different set of errors. That said, entities MUST avoid overloading the server with reestablishment requests. A connection MUST NOT be reestablished too frequently. The frequency is a matter of implementation, but SHOULD NOT be attempted more than once in a 30 second period of time. 6.2. Unreliable Transport BFCP entities may elect to exchange BFCP messages using UDP datagrams. UDP is an unreliable transport where neither delivery nor ordering is assured. Each BFCP UDP datagram MUST contain exactly one BFCP message or message fragment. To keep large BFCP messages from being fragmented at the IP layer, the fragmentation of BFCP messages that exceed the path MTU size is performed at the BFCP level. Considerations related to fragmentation are covered in Section 6.2.3. The message format for BFCP messages is the same regardless of whether the messages are sent in UDP datagrams or over a TCP stream. Clients MUST announce their presence to the floor control server by sending a Hello message. The floor control server responds to the Hello message with a HelloAck message. The client considers the floor control service as present and available only upon receiving the HelloAck message. The behavior when timers fire, including the determination that a connection is broken, is described in Section 8.3. As described in Section 8, each request sent by a floor participant or chair forms a client transaction that expects an acknowledgement message back from the floor control server within a transaction failure window. Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent. If a Floor Control Server receives data that cannot be parsed, the receiving server MUST send an Error message with parameter value 10 (Unable to parse message) indicating receipt of a malformed message, Camarillo, et al. Expires May 16, 2016 [Page 39] Internet-Draft BFCP November 2015 given that it is possible to parse the received message to such an extent that an Error message may be built. Entities MUST have at most one outstanding request transaction per peer at any one time. Implicit subscriptions occur for a client- initiated request transaction whose acknowledgement is implied by the first server-initiated response for that transaction, followed by zero of more subsequent server-initiated messages corresponding to the same transaction. An example is a FloorRequest message for which there are potentially multiple responses from the floor control server as it processes intermediate states until a terminal state (e.g., Granted or Denied) is attained. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant is acknowledged with a FloorRequestStatusAck message. By restricting entities to having at most one pending transaction open in a BFCP connection, both the out-of-order receipt of messages as well as the possibility for congestion are mitigated. Additional details regarding congestion control are provided in Section 6.2.1. A server-initiated request (e.g., a FloorStatus with an update from the floor control server) received by a participant before the initial FloorRequestStatus message that closes the client-initiated transaction that was instigated by the FloorRequest MUST be treated as superseding the information conveyed in any such late arriving response. As the floor control server cannot send a second update to the implicit floor status subscription until the first is acknowledged, ordinality is maintained. If a client wishes to end its BFCP connection with a floor control server, it is REQUIRED that the client send a Goodbye message to dissociate itself from any allocated resources. If a floor control server wishes to end its BFCP connection with a client (e.g., the Focus of the conference informs the floor control server that the client has been kicked out from the conference), it is REQUIRED that the floor control server send a Goodbye message towards the client. 6.2.1. Congestion Control BFCP may be characterized to generate "low data-volume" traffic, per the classification in [13]. Nevertheless is it necessary to ensure suitable and necessary congestion control mechanisms are used for BFCP over UDP. As described in Section 6.2, within the same BFCP connection, every entity - client or server - is only allowed to send one request at a time, and await the acknowledging response. This way at most one datagram is sent per RTT given the message is not lost during transmission. In case the message is lost, the request Camarillo, et al. Expires May 16, 2016 [Page 40] Internet-Draft BFCP November 2015 retransmission timer T1 specified in Section 8.3.1 will fire and the message is retransmitted up to three times, in addition to the original transmission of the message. The default initial interval MUST be set to 500ms, but is adjusted dynamically as described in Section 8.3.1. The interval MUST be doubled after each retransmission attempt. This is similar to the specification of the timer A and its initial value T1 in SIP as described in Section 17.1.1.2 of [18], except that the value of T1 in this protocol is not fixed from one transaction to another. 6.2.2. ICMP Error Handling ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transport MUST be ignored. 6.2.3. Fragmentation Handling When using UDP, a single BFCP message could be fragmented at the IP layer if its overall size exceeds the path MTU of the network. To avoid this happening at the IP layer, a fragmentation scheme for BFCP is defined below. BFCP is designed for achieving small message size, due to the binary encoding as described in Section 1. The fragmentation scheme is therefore deliberately kept simple and straightforward, since the probability of fragmentation of BFCP messages being required is small. By design, the fragmentation scheme does not acknowledge individual BFCP message fragments. The whole BFCP message is acknowledged if received completely. BFCP entities SHOULD consider the path MTU size available between the sender and the receiver and MAY run MTU discovery, such as [23][24][25], for this purpose. When transmitting a BFCP message with size greater than the path MTU, the sender MUST fragment the message into a series of N contiguous data ranges. The size of each of these N messages MUST be smaller than the path MTU to help prevent fragmentation overlap attacks. The value for N is defined as ceil((message size - COMMON-HEADER size) / (path MTU size - COMMON-HEADER size)), where ceil is the integer ceiling function and the COMMON-HEADER size includes the Fragment Offset and Fragment Length fields. The sender then creates N BFCP fragment messages (one for each data range) with the same Transaction ID. The size of each of these N messages, with the COMMON-HEADER included, MUST be smaller than the path MTU. The F flag in the Camarillo, et al. Expires May 16, 2016 [Page 41] Internet-Draft BFCP November 2015 COMMON-HEADER in all the fragments is set to indicate fragmentation of the BFCP message. For each of these fragments the Fragment Offset and Fragment Length fields are included in the COMMON-HEADER. The Fragment Offset field denotes the number of 4-octet units contained in the previous fragments, excluding the common header. The Fragment Length contains the length of the fragment itself, also excluding the common header. Note that the Payload Length field contains the length of the entire, unfragmented message. When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission Timer expires. The state machine should handle the BFCP message only after all the fragments for the message have been received. If a fragment of a BFCP message is lost, the sender will not receive an acknowledgement for the message. Therefore the sender will retransmit the message with same transaction ID as specified in Section 8.3. If the acknowledgement message sent by the receiver is lost, then the entire message will be resent by the sender. The receiver MUST then retransmit the acknowledgement. The receiver MAY discard an incomplete buffer utilizing the Response Retransmission Timer, starting the timer after the receipt of the first fragment. A Denial of Service (DoS) attack utilizing the fragmentation scheme described above is mitigated by the fact that the Response Retransmission Timer is started after receipt of the first BFCP message fragment. In addition, the Payload Length field can be compared with the Fragment Offset and Fragment Length fields to verify the message fragments as they arrive. To make DoS attacks with spoofed IP addresses difficult, BFCP entities SHOULD use the cookie exchange mechanism in DTLS [8]. When deciding message fragment size based on path MTU, the BFCP fragmentation handling should take into account how the DTLS record framing expands the datagram size as described in Section 4.1.1.1 of [8]. 6.2.4. NAT Traversal One of the key benefits when using UDP for BFCP communication is the ability to leverage the existing NAT traversal infrastructure and strategies deployed to facilitate transport of the media associated with the video conferencing sessions. Depending on the given deployment, this infrastructure typically includes some subset of ICE [17]. Camarillo, et al. Expires May 16, 2016 [Page 42] Internet-Draft BFCP November 2015 In order to facilitate the initial establishment of NAT bindings, and to maintain those bindings once established, BFCP entities using an unreliable transport are RECOMMENDED to use STUN [12] Binding Indication for keep-alives, as described for ICE [17]. Section 6.7 of [26] provides useful recommendations for middlebox interaction when DTLS is used. Informational note: Since the version number is set to 2 when BFCP is used over an unreliable transport, cf. the Ver field in Section 5.1, it is straight forward to distinguish between STUN and BFCP packets even without checking the STUN magic cookie [12]. In order to facilitate traversal of BFCP packets through NATs, BFCP entities using an unreliable transport are RECOMMENDED to use symmetric ports for sending and receiving BFCP packets, as recommended for RTP/RTCP [11]. 7. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [7] and MUST support DTLS [8] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards compatibility with existing implementations of RFC 4582. In accordance with the recommendations and guidelines in [28], BFCP entities SHOULD support the following cipher suites: o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 8. Protocol Transactions In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. Camarillo, et al. Expires May 16, 2016 [Page 43] Internet-Draft BFCP November 2015 Server-initiated transactions have different requirements and behavior depending on underlying transport: When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). They do not trigger any response. When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server. When using BFCP over an unreliable transport, retransmission timer T1 (see Section 8.3) MUST be used for all requests until the transaction is completed. Note that while T1 varies over time, it remains constant for the duration of a given transaction and is only updated at the completion of a transaction. 8.1. Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously. The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. When using BFCP over an unreliable transport, it is important to choose a Transaction ID value that lets the receiver distinguish the reception of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using an unreliable transport MUST use monotonically increasing Transaction ID values (except for wrap-around). A client receiving a server-initiated transaction over an unreliable transport MUST copy the Transaction ID from the request received from the server into the response. 8.2. Server Behavior A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for Camarillo, et al. Expires May 16, 2016 [Page 44] Internet-Draft BFCP November 2015 client-initiated transactions. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair. 8.3. Timers When BFCP entities are communicating over an unreliable transport, two retransmission timers are employed to help mitigate against loss of datagrams. Retransmission and response caching are not required when BFCP entities communicate over a reliable transport. 8.3.1. Request Retransmission Timer, T1 T1 is a timer that schedules retransmission of a request until an appropriate response is received or until the maximum number of retransmissions have occurred. The timer is computed using the smoothed round-trip time algorithm defind in [2] with an initial retransmission timeout (RTO) value of 500ms and clock granularity (G) of 100ms. In contrast to step 2.4 of Section 2 of [2], if the computed value of RTO is less than 500ms, then RTO shall be set to 500ms. Timer T1 MUST be adjusted with the reception of a response to each request transmitted in order to compute an accurate RTO value, which is the effective T1 value. The RTT value R is the time in milliseconds from the point when a request is transmitted to the time the initial response to that request is received. Responses to retransmitted packets MUST NOT be used to recompute the RTO value, as one cannot determine if a response is to an initial or retransmitted request. If T1 always expires on the initial transmission of a new request, this would suggest the recommended initial T1 (and RTO) value is too low and SHOULD be increased by doubling the initial values of T1 (and RTO) until T1 does not expire when sending a new request. When retransmitting a request, timer T1 is doubled with each retransmission, failing after three unacknowledged retransmission attempts. If a valid response is not received for a client- or server-initiated transaction, the implementation MUST consider the BFCP connection as broken. Implementations SHOULD follow the reestablishment procedure described in section 6. 8.3.2. Response Retransmission Timer, T2 T2 is a timer that, when fired, signals that the BFCP entity can release knowledge of the transaction against which it is running. It is started upon the first transmission of the response to a request and is the only mechanism by which that response is released by the Camarillo, et al. Expires May 16, 2016 [Page 45] Internet-Draft BFCP November 2015 BFCP entity. Any subsequent retransmissions of the same request can be responded to by replaying the cached response, whilst that value is retained until the timer has fired. Refer to Section 6.2.3 for the role this timer has in the fragmentation handling scheme. 8.3.3. Timer Values The table below defines the different timers required when BFCP entities communicate over an unreliable transport. +-------+--------------------------------------+----------------+ | Timer | Description | Value/s | +-------+--------------------------------------+----------------+ | T1 | Initial request retransmission timer | 0.5s (initial) | | T2 | Response retransmission timer | (T1*2^4)*1.25 | +-------+--------------------------------------+----------------+ Table 6: Timers The initial value for T1 is 500ms, which is an estimate of the RTT for completing the transaction. Computation of this value follows the procedures described in Section 8.3.1, which includes exponential backoffs on retransmissions. T2 MUST be set such that it encompasses all legal retransmissions per T1 plus a factor to accommodate network latency between BFCP entities, processing delays, etc. 9. Authentication and Authorization BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, and the extensions in this document are supported, the BFCP clients MUST authenticate the floor control server and the floor control servers MUST authenticate the client before communicating as described above. Note that BFCP entities supporting only the [3] subset may not comply with this mandatory authentication requirement. BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP. Camarillo, et al. Expires May 16, 2016 [Page 46] Internet-Draft BFCP November 2015 Note that future extensions may define additional authentication mechanisms. In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 13.8, with an Error code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorized MUST NOT be processed further. 9.1. TLS/DTLS Based Mutual Authentication BFCP supports TLS/DTLS based mutual authentication between clients and floor control servers. If TLS/DTLS is used, an initial integrity-protected channel is REQUIRED between the client and the floor control server that can be used to exchange their certificates (which MAY be self-signed certificates) or, more commonly, the fingerprints of these certificates. These certificates are used at TLS/DTLS establishment time. The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in [10]. BFCP messages received over an authenticated TLS/DTLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP/UDP (no TLS/DTLS) MAY request the use of TLS/ DTLS by generating an Error message, as described in Section 13.8, with an Error code with a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients configured to require the use of TLS/ DTLS MUST ignore unauthenticated messages. Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority). As described in Section 9, floor control servers need to perform authorization before processing any message. In particular, the floor control server MUST check that messages arriving over a given authenticated TLS/DTLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS/DTLS connection is allowed to use). Camarillo, et al. Expires May 16, 2016 [Page 47] Internet-Draft BFCP November 2015 10. Floor Participant Operations This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Section 11 specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and Section 12 specifies operations that can be performed by any client (i.e., both floor participants and floor chairs). 10.1. Requesting a Floor A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server. 10.1.1. Sending a FloorRequest Message The ABNF in Section 5.3.1 describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor. Note that the name space for both the User ID and the Beneficiary ID is the same. That is, a given participant is identified by a single 16-bit value that can be used in the User ID in the common header and in several attributes: BENEFICIARY-ID, BENEFICIARY- INFORMATION, and REQUESTED-BY-INFORMATION. The floor participant MUST insert at least one FLOOR-ID attribute in the FloorRequest message. If the client inserts more than one FLOOR- ID attribute, the floor control server will treat all the floor requests as an atomic package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message. The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption. Camarillo, et al. Expires May 16, 2016 [Page 48] Internet-Draft BFCP November 2015 The floor participant may request that the server handle the floor request with a certain priority using a PRIORITY attribute. 10.1.2. Receiving a Response A message from the floor control server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication. The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus message. This way, the floor participant can associate subsequent incoming FloorRequestStatus messages with the ongoing floor request. The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request. The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted states. If the floor request value is unknown, then the response is still processed. However, no meaningful value can be reported to the user. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user. The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user. Camarillo, et al. Expires May 16, 2016 [Page 49] Internet-Draft BFCP November 2015 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY- INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in the common header. The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message. If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message. 10.1.3. Reception of a Subsequent FloorRequestStatus Message When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction. 10.2. Cancelling a Floor Request and Releasing a Floor A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it. 10.2.1. Sending a FloorRelease Message The ABNF in Section 5.3.2 describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The floor participant sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor participant sets the User ID in the common header to the floor participant's identifier. Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (from the protocol perspective, both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire. Camarillo, et al. Expires May 16, 2016 [Page 50] Internet-Draft BFCP November 2015 The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling. Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time). 10.2.2. Receiving a Response A message from the floor control server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRelease message, as described in Section 8.1. On receiving such a response, the floor participant follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message. It is possible that the FloorRelease message crosses on the wire with a FloorRequestStatus message from the server with a Request Status different from Cancelled or Released. In any case, such a FloorRequestStatus message will not be a response to the FloorRelease message, as its Transaction ID will not match that of the FloorRelease. 11. Chair Operations This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections. Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message. 11.1. Sending a ChairAction Message The ABNF in Section 5.3.9 describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. Camarillo, et al. Expires May 16, 2016 [Page 51] Internet-Draft BFCP November 2015 The floor chair sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The floor chair sets the User ID in the common header to the floor chair's identifier. The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message. For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other floor chair's decision. The floor chair provides the new status of the floor request as it relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new status of the floor request is Accepted, the floor chair MAY use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position field MUST be set to zero. The floor chair MUST use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and MUST use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted). The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new overall status for the floor request. If the new overall status of the floor request is Accepted, the floor chair can use the Queue Position field to provide a queue position for the floor request. Note that a particular floor control server can implement a different queue for each floor containing all the floor requests that relate to that particular floor, a general queue for all floor requests, or both. Also note that a floor request can involve several floors and that a ChairAction message can only deal with a subset of these floors (e.g., if a single floor chair is not authorized to manage all the floors). In this case, the floor control server will combine the instructions received from the different floor chairs in FLOOR-REQUEST-STATUS attributes to come up with the overall status of the floor request. Camarillo, et al. Expires May 16, 2016 [Page 52] Internet-Draft BFCP November 2015 Note that, while the action of a floor chair may communicate information in the OVERALL-REQUEST-STATUS attribute, the floor control server may override, modify, or ignore this field's content. The floor chair MAY include STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption. 11.2. Receiving a Response A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in Section 8.1. On receiving such a response, the floor chair follows the rules in Section 9 that relate to floor control server authentication. A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message. 12. General Client Operations This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both. 12.1. Requesting Information about Floors A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server. 12.1.1. Sending a FloorQuery Message The ABNF in Section 5.3.7 describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. Camarillo, et al. Expires May 16, 2016 [Page 53] Internet-Draft BFCP November 2015 The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about a particular floor any longer, it sends a new FloorQuery message removing the FLOOR-ID of this floor. If the client does not want to receive information about any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute. 12.1.2. Receiving a Response A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. On reception of the FloorQuery message, the floor control server MUST respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either. FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request. After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about. Camarillo, et al. Expires May 16, 2016 [Page 54] Internet-Draft BFCP November 2015 12.1.3. Reception of a Subsequent FloorStatus Message When communicating over an unreliable transport and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction. 12.2. Requesting Information about Floor Requests A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server. Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request. 12.2.1. Sending a FloorRequestQuery Message The ABNF in Section 5.3.3 describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. The client MUST insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server. 12.2.2. Receiving a Response A message from the floor control server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in Section 8.1. On receiving Camarillo, et al. Expires May 16, 2016 [Page 55] Internet-Draft BFCP November 2015 such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute. If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message. 12.3. Requesting Information about a User A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server. This functionality may be useful for floor chairs or floor participants interested in the display name and the URI of a particular floor participant. In addition, a floor participant may find it useful to request information about itself. For example, a floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist. 12.3.1. Sending a UserQuery Message The ABNF in Section 5.3.5 describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in the common header of the message), the client MUST insert a BENEFICIARY-ID attribute. Camarillo, et al. Expires May 16, 2016 [Page 56] Internet-Draft BFCP November 2015 12.3.2. Receiving a Response A message from the floor control server is considered a response to the UserQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the UserQuery message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes. If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message. 12.4. Obtaining the Capabilities of a Floor Control Server A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server. 12.4.1. Sending a Hello Message The ABNF in Section 5.3.11 describes the attributes that a Hello message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional. The client sets the Conference ID and the Transaction ID in the common header following the rules given in Section 8.1. The client sets the User ID in the common header to the client's identifier. 12.4.2. Receiving Responses A message from the floor control server is considered a response to the Hello message by the client if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the Hello message, as described in Section 8.1. On receiving such a response, the client follows the rules in Section 9 that relate to floor control server authentication. If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server. Camarillo, et al. Expires May 16, 2016 [Page 57] Internet-Draft BFCP November 2015 If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message. 13. Floor Control Server Operations This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections. On reception of a message from a client, the floor control server MUST check whether the value of the Primitive is supported. If it is not, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 3 (Unknown Primitive). On reception of a message from a client, the floor control server MUST check whether the value of the Conference ID matched an existing conference. If it does not, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 1 (Conference does not Exist). On reception of a message from a client, the floor control server follows the rules in Section 9 that relate to the authentication of the message. On reception of a message from a client, the floor control server MUST check whether it understands all the mandatory ('M' bit set) attributes in the message. If the floor control server does not understand all of them, the floor control server MUST send an Error message, as described in Section 13.8, with Error code 4 (Unknown Mandatory Attribute). The Error message SHOULD list the attributes that were not understood. 13.1. Reception of a FloorRequest Message On reception of a FloorRequest message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. BFCP allows floor participants to have several ongoing floor requests for the same floor (e.g., the same floor participant can occupy more than one position in a queue at the same time). A floor control server that only supports a certain number of ongoing floor requests per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Camarillo, et al. Expires May 16, 2016 [Page 58] Internet-Draft BFCP November 2015 Ongoing Floor Requests for this Floor) to inform the floor participant. When communicating over an unreliable transport and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. 13.1.1. Generating the First FloorRequestStatus Message The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of which SHOULD be generated as soon as possible. If the floor control server cannot accept, grant, or deny the floor request right away (e.g., a decision from a chair is needed), it SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates. The policy that a floor control server follows to grant or deny floors is outside the scope of this document. A given floor control server may perform these decisions automatically while another may contact a human acting as a chair every time a decision needs to be made. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the FloorRequestStatus, as described in Section 8.2. Additionally, the floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request. The floor control server MUST assign an identifier that is unique within the conference to this floor request, and MUST insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future. The floor control server MUST copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request). The floor control server SHOULD copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped Camarillo, et al. Expires May 16, 2016 [Page 59] Internet-Draft BFCP November 2015 attribute. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY- INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY copy (if present) the PRIORITY attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute. Note that this attribute carries the priority requested by the participant. The priority that the floor control server assigns to the floor request depends on the priority requested by the participant and the rights the participant has according to the policy of the conference. For example, a participant that is only allowed to use the Normal priority may request Highest priority for a floor request. In that case, the floor control server would ignore the priority requested by the participant. The floor control server MAY copy (if present) the PARTICIPANT- PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- INFORMATION grouped attribute. 13.1.2. Generation of Subsequent FloorRequestStatus Messages A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages. When the status of the floor request changes, the floor control server SHOULD send new FloorRequestStatus messages with the appropriate Request Status. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the first FloorRequestStatus message to any new FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.) When using BFCP over a reliable transport, the floor control server MUST set the Transaction ID of subsequent FloorRequestStatus messages to 0. When using BFCP over an unreliable transport, the Transaction Camarillo, et al. Expires May 16, 2016 [Page 60] Internet-Draft BFCP November 2015 ID MUST be non-zero and unique in the context of outstanding transactions over an unreliable transport as described in Section 8. The rate at which the floor control server sends FloorRequestStatus messages is a matter of local policy. A floor control server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue, while another may choose only to send a new FloorRequestStatus message when the floor request is Granted or Denied. The floor control server may add a STATUS-INFO attribute to any of the FloorRequestStatus messages it generates to provide extra information about its decisions regarding the floor request (e.g., why it was denied). Floor participants and floor chairs may request to be informed about the status of a floor following the procedures in Section 12.1. If the processing of a floor request changes the status of a floor (e.g., the floor request is granted and consequently the floor has a new holder), the floor control server needs to follow the procedures in Section 13.5 to inform the clients that have requested that information. The common header and the rest of the attributes are the same as in the first FloorRequestStatus message. The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked. When communicating over an unreliable transport and a FloorRequestStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorRequestStatus message according to Section 6.2. 13.2. Reception of a FloorRequestQuery Message On reception of a FloorRequestQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. Camarillo, et al. Expires May 16, 2016 [Page 61] Internet-Draft BFCP November 2015 When communicating over an unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in Section 8.2. Additionally, the floor control server MUST include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The floor control server MUST copy the contents of the FLOOR-REQUEST- ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. Camarillo, et al. Expires May 16, 2016 [Page 62] Internet-Draft BFCP November 2015 13.3. Reception of a UserQuery Message On reception of a UserQuery message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the UserStatus message, as described in Section 8.2. The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the common header of the UserQuery message. The floor control server MUST copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control server MAY provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute. The floor control server SHOULD add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST- INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR- REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. Camarillo, et al. Expires May 16, 2016 [Page 63] Internet-Draft BFCP November 2015 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request. The floor control server MUST include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- INFORMATION grouped attribute. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. 13.4. Reception of a FloorRelease Message On reception of a FloorRelease message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a FloorRelease from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. Camarillo, et al. Expires May 16, 2016 [Page 64] Internet-Draft BFCP November 2015 The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in Section 8.2. The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request. The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST- INFORMATION attribute. The floor control server MUST identify the floors being released (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHOULD be Released, if the floor (or floors) had been previously granted, or Cancelled, if the floor (or floors) had not been previously granted. The floor control server MAY add a STATUS- INFO attribute with extra information about the floor request. 13.5. Reception of a FloorQuery Message On reception of a FloorQuery message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the FloorQuery message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. When communicating over an unreliable transport and upon receiving a FloorQuery from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction. A floor control server receiving a FloorQuery message from a client SHOULD keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. Floor Control Servers keep clients informed by using FloorStatus messages. An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors. Camarillo, et al. Expires May 16, 2016 [Page 65] Internet-Draft BFCP November 2015 The information FloorQuery messages carry may depend on the user requesting the information. For example, a chair may be able to receive information about pending requests, while a regular user may not be authorized to do so. 13.5.1. Generation of the First FloorStatus Message The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in Section 8.2. If the FloorQuery message did not contain any FLOOR-ID attribute, the floor control server sends the FloorStatus message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant. If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST- INFORMATION grouped attribute contains a number of attributes that provide information about the floor request. For each FLOOR-REQUEST- INFORMATION attribute, the floor control server follows the following steps. The floor control server MUST identify the floor request the FLOOR- REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. The floor control server MUST add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute). The floor control server SHOULD add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the floor request. Additionally, the floor control server MAY provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute. The floor control server MAY provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Camarillo, et al. Expires May 16, 2016 [Page 66] Internet-Draft BFCP November 2015 The floor control server MAY provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO. The floor control server MAY also add to the FLOOR-REQUEST- INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request. The floor control server MUST add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the floor request. The floor control server MAY add a STATUS-INFO attribute with extra information about the floor request. The floor control server MAY provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes. 13.5.2. Generation of Subsequent FloorStatus Messages If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control server SHOULD generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see Section 13.5.1), but their Transaction ID is 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8). After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messages MUST be 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport (cf. Section 8). The rate at which the floor control server sends FloorStatus messages is a matter of local policy. A floor control server may choose to send a new FloorStatus message every time a new floor request arrives, while another may choose to only send a new FloorStatus message when a new floor request is Granted. When communicating over an unreliable transport and a FloorStatusAck message is not received within the transaction failure window, the floor control server MUST retransmit the FloorStatus message according to Section 6.2. Camarillo, et al. Expires May 16, 2016 [Page 67] Internet-Draft BFCP November 2015 13.6. Reception of a ChairAction Message On reception of a ChairAction message, the floor control server follows the rules in Section 9 that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, which SHOULD be generated as soon as possible. When communicating over an unreliable transport and upon receiving a ChairAction from a chair, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in Section 8.2. The floor control server needs to take into consideration the operation requested in the ChairAction message (e.g., granting a floor) but does not necessarily need to perform it as requested by the floor chair. The operation that the floor control server performs depends on the ChairAction message and on the internal state of the floor control server. For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state. If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that the floor control server assign a queue position (e.g., the last in the queue) to the floor request based on the local policy of the floor control server. (Of course, such a request only applies if the floor control server implements a queue.) Camarillo, et al. Expires May 16, 2016 [Page 68] Internet-Draft BFCP November 2015 13.7. Reception of a Hello Message On reception of a Hello message, the floor control server follows the rules in Section 9 that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, it MUST generate an Error response following the procedures described in Section 13.8. If the version of BFCP specified in the Version field of the COMMON- HEADER is supported by the floor control server, it MUST respond with the same version number in the HelloAck; this defines the version for all subsequent BFCP messages within this BFCP Connection. When communicating over an unreliable transport and upon receiving a Hello from a participant, the floor control server MUST respond with a HelloAck message within the transaction failure window to complete the transaction. The successful processing of a Hello message by a floor control server involves generating a HelloAck message, which SHOULD be generated as soon as possible. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in Section 8.2. The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server. The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server. 13.8. Error Message Generation Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in Section 5.3.13 describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional. The floor control server MUST copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in Section 8.2. The floor control server MUST add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains an Error Code from Table 5. Additionally, the floor control server may add an ERROR- INFO attribute with extra information about the error. Camarillo, et al. Expires May 16, 2016 [Page 69] Internet-Draft BFCP November 2015 14. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to Section 7 always be used. In cases where signaling/control traffic is properly protected, as described in Section 9 it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. An example of other mechanisms is IPSec [19] to effectively secure a non-secure BFCP connection. The remainder of this section analyzes some of the threats against BFCP and how they are addressed. An attacker may attempt to impersonate a client (a floor participant or a floor chair) in order to generate forged floor requests or to grant or deny existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections. The floor control server assumes that attackers cannot hijack the TLS/DTLS connection and, therefore, that messages over the TLS/DTLS connection come from the client that was initially authenticated. An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections, as well as ensuring clients only send and accept messages over authenticated TLS/DTLS connections. Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS/DTLS connections prevents this attack. An attacker may attempt to fetch a valid message sent by a client to a floor control server and replay it over a connection between the attacker and the floor control server. This attack is prevented by having floor control servers check that messages arriving over a given authenticated TLS/DTLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS/DTLS connection is allowed to use). Camarillo, et al. Expires May 16, 2016 [Page 70] Internet-Draft BFCP November 2015 Attackers may attempt to pick messages from the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). TLS/DTLS confidentiality prevents this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm according to Section 7. 15. IANA Considerations [Note to IANA: Much of this text exists from the previous version of this document. While the old and new additions to the registries are presented here, the items for which IANA needs to take action with respect to this draft are highlighted with "Note to IANA", as with this note and the one immediately following. Throughout this document, though, RFC XXXX needs to be replaced with this RFC and the IANA registries for BFCP should to refer only to this RFC.] [Note to IANA: This section instructs the IANA to register new entries in the BFCP Primitive subregistry in Section 15.2 and for the BFCP Error Code subregistry in Section 15.4.] The IANA has created a registry for BFCP parameters called "Binary Floor Control Protocol (BFCP) Parameters". This registry has a number of subregistries, which are described in the following sections. 15.1. Attribute Subregistry This section establishes the Attribute subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP attributes shall be "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the attribute's type, name, format, and semantics. For each BFCP attribute, the IANA registers its type, its name, and the reference to the RFC where the attribute is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 71] Internet-Draft BFCP November 2015 +------+---------------------------+------------+ | Type | Attribute | Reference | +------+---------------------------+------------+ | 1 | BENEFICIARY-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | | 4 | PRIORITY | [RFC XXXX] | | 5 | REQUEST-STATUS | [RFC XXXX] | | 6 | ERROR-CODE | [RFC XXXX] | | 7 | ERROR-INFO | [RFC XXXX] | | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | | 9 | STATUS-INFO | [RFC XXXX] | | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | | 12 | USER-DISPLAY-NAME | [RFC XXXX] | | 13 | USER-URI | [RFC XXXX] | | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | | 17 | FLOOR-REQUEST-STATUS | [RFC XXXX] | | 18 | OVERALL-REQUEST-STATUS | [RFC XXXX] | +------+---------------------------+------------+ Table 7: Initial values of the BFCP Attribute subregistry 15.2. Primitive Subregistry [Note to IANA: This section instructs the IANA to register the following new values for the BFCP Primitive subregistry: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.] This section establishes the Primitive subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP primitives shall be "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the primitive's value, name, format, and semantics. For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 72] Internet-Draft BFCP November 2015 +-------+-----------------------+------------+ | Value | Primitive | Reference | +-------+-----------------------+------------+ | 1 | FloorRequest | [RFC XXXX] | | 2 | FloorRelease | [RFC XXXX] | | 3 | FloorRequestQuery | [RFC XXXX] | | 4 | FloorRequestStatus | [RFC XXXX] | | 5 | UserQuery | [RFC XXXX] | | 6 | UserStatus | [RFC XXXX] | | 7 | FloorQuery | [RFC XXXX] | | 8 | FloorStatus | [RFC XXXX] | | 9 | ChairAction | [RFC XXXX] | | 10 | ChairActionAck | [RFC XXXX] | | 11 | Hello | [RFC XXXX] | | 12 | HelloAck | [RFC XXXX] | | 13 | Error | [RFC XXXX] | | 14 | FloorRequestStatusAck | [RFC XXXX] | | 15 | FloorStatusAck | [RFC XXXX] | | 16 | Goodbye | [RFC XXXX] | | 17 | GoodbyeAck | [RFC XXXX] | +-------+-----------------------+------------+ Table 8: Initial values of the BFCP primitive subregistry 15.3. Request Status Subregistry This section establishes the Request Status subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP request status shall be "Specification Required". For the purposes of this subregistry, the BFCP request status for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the request status. For each BFCP request status, the IANA registers its value, its meaning, and the reference to the RFC where the request status is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 73] Internet-Draft BFCP November 2015 +-------+-----------+------------+ | Value | Status | Reference | +-------+-----------+------------+ | 1 | Pending | [RFC XXXX] | | 2 | Accepted | [RFC XXXX] | | 3 | Granted | [RFC XXXX] | | 4 | Denied | [RFC XXXX] | | 5 | Cancelled | [RFC XXXX] | | 6 | Released | [RFC XXXX] | | 7 | Revoked | [RFC XXXX] | +-------+-----------+------------+ Table 9: Initial values of the Request Status subregistry 15.4. Error Code Subregistry [Note to IANA: This section instructs the IANA to register the following new values for the BFCP Error Code subregistry: 10, 11, 12, 13 and 14.] This section establishes the Error Code subregistry under the BFCP Parameters registry. As per the terminology in RFC 5226 [6], the registration policy for BFCP error codes shall be "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requested MUST be defined by a standards-track RFC. Such an RFC MUST specify the value and the semantics of the error code, and any Error Specific Details that apply to it. For each BFCP primitive, the IANA registers its value, its meaning, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry. Camarillo, et al. Expires May 16, 2016 [Page 74] Internet-Draft BFCP November 2015 +-------+--------------------------------------+------------+ | Value | Meaning | Reference | +-------+--------------------------------------+------------+ | 1 | Conference does not Exist | [RFC XXXX] | | 2 | User does not Exist | [RFC XXXX] | | 3 | Unknown Primitive | [RFC XXXX] | | 4 | Unknown Mandatory Attribute | [RFC XXXX] | | 5 | Unauthorized Operation | [RFC XXXX] | | 6 | Invalid Floor ID | [RFC XXXX] | | 7 | Floor Request ID Does Not Exist | [RFC XXXX] | | 8 | You have Already Reached the Maximum | [RFC XXXX] | | | Number of Ongoing Floor Requests for | | | | this Floor | | | 9 | Use TLS | [RFC XXXX] | | 10 | Unable to parse message | [RFC XXXX] | | 11 | Use DTLS | [RFC XXXX] | | 12 | Unsupported Version | [RFC XXXX] | | 13 | Incorrect Message Length | [RFC XXXX] | | 14 | Generic Error | [RFC XXXX] | +-------+--------------------------------------+------------+ Table 10: Initial Values of the Error Code subregistry 16. Changes from RFC 4582 Following is the list of technical changes and other non-trivial fixes from [3]. 16.1. Extensions for an unreliable transport Main purpose of this work was to revise the specification to support BFCP over an unreliable transport, resulting in the following changes: 1. Overview of Operation (Section 4): Changed the description of client-initiated and server-initiated transactions, referring to Section 8. 2. COMMON-HEADER Format (Section 5.1): Ver(sion) field, where the value 2 is used for the extensions for an unreliable transport. Added new R and F flag-bits for an unreliable transport. Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length fields. 3. New primitives (Section 5.1): Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck. Camarillo, et al. Expires May 16, 2016 [Page 75] Internet-Draft BFCP November 2015 4. New error codes (Section 5.2.6): Added three new error codes: "Unable to Parse Message", "Use DTLS" and "Unsupported Version". Note that two additional error codes were added, see Section 16.2. 5. ABNF for new primitives (Section 5.3): New subsections with normative ABNF for the new primitives. 6. Transport split in two (Section 6): Section 6 specifying the transport was split in two subsections; Section 6.1 for a reliable transport and Section 6.2 for an unreliable transport. Where the specification for an unreliable transport amongst other issues deals with reliability, congestion control, fragmentation and ICMP. 7. Mandate DTLS (Section 7 and Section 9): Mandate DTLS support when transport over UDP is used. 8. Transaction changes (Section 8): Server-initiated transactions over an unreliable transport has non-zero and unique Transaction ID. Over an unreliable transport, the retransmit timers T1 and T2 described in Section 8.3 apply. 9. Requiring timely response (Section 8.3, Section 10.1.2, Section 10.2.2, Section 11.2, Section 12.1.2, Section 12.2.2, Section 12.3.2, Section 12.4.2, Section 10.1.3 and Section 12.1.3): Describing that a given response must be sent within the transaction failure window to complete the transaction. 10. Updated IANA Considerations (Section 15): Added the new primitives and error codes to Section 15.2 and Section 15.4 respectively. 11. Examples over an unreliable transport (Appendix A): Added sample interactions over an unreliable transport for the scenarios in Figure 2 and Figure 3 12. Motivation for an unreliable transport (Appendix B): Introduction to and motivation for extending BFCP to support an unreliable transport. 16.2. Other changes Clarifications and bug fixes: Camarillo, et al. Expires May 16, 2016 [Page 76] Internet-Draft BFCP November 2015 1. ABNF fixes (Figure 22, Figure 24, ="fig:reqby-information"/>, Figure 28, Figure 30, and the ABNF figures in Section 5.3): Although formally correct in [3], the notation has changed in a number of Figures to an equivalent form for clarity, e.g., s/*1(FLOOR-ID)/[FLOOR-ID]/ in Figure 38 and s/*[XXX]/*(XXX)/ in the other figures. 2. Typo (Section 12.4.2): Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the second paragraph. 3. Corrected attribute type (Section 13.1.1): Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in the eighth paragraph, since the note below describes priority and that the last paragraph deals with PARTICIPANT-PROVIDED-INFO. 4. New error codes (Section 5.2.6): Added two additional error codes: "Incorrect Message Length" and "Generic Error". 5. Assorted clarifications (Across the document): Language clarifications as a result of reviews. Also, the normative language where tightened where appropriate, i.e. changed from SHOULD strength to MUST in a number of places. 17. Acknowledgements The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for RFC 4582 [3]. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments during the work with RFC 4582. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from Geir Arne Sandbakken who had the initial idea, Alfred E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava and Alan Ford. In the final phase Ernst Horvath did a thorough review revealing issues that needed clarification and changes. Useful and important final reviews were done by Mary Barnes. Paul Jones helped tremendously as editor for changes addressing IESG review comments. 18. References Camarillo, et al. Expires May 16, 2016 [Page 77] Internet-Draft BFCP November 2015 18.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [2] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, DOI 10.17487/RFC2988, November 2000, . [3] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [4] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/ RFC5018, September 2007, . [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ RFC5246, August 2008, . [8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [10] Camarillo, G., Kristensen, T., and P. Jones, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12 (work in progress), September 2015. Camarillo, et al. Expires May 16, 2016 [Page 78] Internet-Draft BFCP November 2015 [11] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, . [12] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [13] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, DOI 10.17487/RFC5405, November 2008, . 18.2. Informational References [14] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [15] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, DOI 10.17487/RFC4376, February 2006, . [16] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, . [17] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [19] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Camarillo, et al. Expires May 16, 2016 [Page 79] Internet-Draft BFCP November 2015 [20] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, . [21] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, DOI 10.17487/RFC6503, March 2012, . [22] Barnes, M., Miniero, L., Presta, R., and S. Romano, "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March 2012, . [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [24] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, . [25] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [26] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [27] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/ RFC6951, May 2013, . [28] 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, . Camarillo, et al. Expires May 16, 2016 [Page 80] Internet-Draft BFCP November 2015 [29] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, . [30] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/ RFC6081, January 2011, . [31] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [32] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [33] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in progress), July 2010. [34] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", draft-ietf-mmusic- media-path-middleboxes-07 (work in progress), May 2013. [35] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", 2005, . [36] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", April 2005, . Appendix A. Example Call Flows for BFCP over an Unreliable Transport With reference to Section 4.1, the following figures show representative call-flows for requesting and releasing a floor, and obtaining status information about a floor when BFCP is deployed over an unreliable transport. The figures here show a loss-less interaction. Floor Participant Floor Control Server |(1) FloorRequest | |Transaction Responder: 0 | |Transaction ID: 123 | Camarillo, et al. Expires May 16, 2016 [Page 81] Internet-Draft BFCP November 2015 |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction Responder: 1 | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction Responder: 0 | |Transaction ID: 124 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(4) FloorRequestStatusAck | |Transaction Responder: 1 | |Transaction ID: 124 | |User ID: 234 | |---------------------------------------------->| | | |(5) FloorRequestStatus | |Transaction Responder: 0 | |Transaction ID: 125 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| | | |(6) FloorRequestStatusAck | Camarillo, et al. Expires May 16, 2016 [Page 82] Internet-Draft BFCP November 2015 |Transaction Responder: 1 | |Transaction ID: 125 | |User ID: 234 | |---------------------------------------------->| | | |(7) FloorRelease | |Transaction Responder: 0 | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 | |---------------------------------------------->| | | |(8) FloorRequestStatus | |Transaction Responder: 1 | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | |<----------------------------------------------| Figure 48: Requesting and releasing a floor Note that in Figure 48, the FloorRequestStatus message from the floor control server to the floor participant is a transaction-closing message as a response to the client-initiated transaction with Transaction ID 154. As such, it is not followed by a FloorRequestStatusAck message from the floor participant to the floor control server. Floor Participant Floor Control Server |(1) FloorQuery | |Transaction Responder: 0 | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 | |---------------------------------------------->| | | |(2) FloorStatus | |Transaction Responder: 1 | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | Camarillo, et al. Expires May 16, 2016 [Page 83] Internet-Draft BFCP November 2015 | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(3) FloorStatus | |Transaction Responder: 0 | |Transaction ID: 258 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(4) FloorStatusAck | |Transaction Responder: 1 | |Transaction ID: 258 | |User ID: 234 | |---------------------------------------------->| Camarillo, et al. Expires May 16, 2016 [Page 84] Internet-Draft BFCP November 2015 | | |(5) FloorStatus | |Transaction Responder: 0 | |Transaction ID: 259 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 | |<----------------------------------------------| | | |(6) FloorStatusAck | |Transaction Responder: 1 | |Transaction ID: 259 | |User ID: 234 | |---------------------------------------------->| Figure 49: Obtaining status information about a floor Appendix B. Motivation for Supporting an Unreliable Transport This appendix is contained in this document as an aid to understand the background and rationale for adding support for unreliable transport. B.1. Motivation In existing video conferencing deployments, BFCP is used to manage the floor for the content sharing associated with the conference. For peer to peer scenarios, including business to business conferences and point to point conferences in general, it is frequently the case that one or both endpoints exists behind a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in [10], resulting in one endpoint being responsible for opening the TCP connection used for the BFCP communication. Camarillo, et al. Expires May 16, 2016 [Page 85] Internet-Draft BFCP November 2015 +---------+ | Network | +---------+ +-----+ / \ +-----+ | NAT |/ \| NAT | +-----+ +-----+ +----+ / \ +----+ |BFCP|/ \|BFCP| | UA | | UA | +----+ +----+ Figure 50: Use Case The communication session between the video conferencing endpoints typically consists of a number of RTP over UDP media streams, for audio and video, and a BFCP connection for floor control. Existing deployments are most common in, but not limited to, enterprise networks. In existing deployments, NAT traversal for the RTP streams works using ICE and/or other methods, including those described in [34]. When enhancing an existing SIP based video conferencing deployment with support for content sharing, the BFCP connection often poses a problem. The reasons for this fall into two general classes. First, there may be a strong preference for UDP based signaling in general. On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- working gateways), TCP can suffer from head of line blocking, and it uses many kernel buffers. Network operators view UDP as a way to avoid both of these. Second, establishment and traversal of the TCP connection involving ephemeral ports, as is typically the case with BFCP over TCP, can be problematic, as described in Appendix A of [32]. A broad study of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of TCP NAT traversal techniques over a wide range of commercial NAT products concluded it was not possible to establish a TCP connection in 11% of the cases [35]. The results are worse when focusing on enterprise NATs. A study of hole punching as a NAT traversal technique across a wide variety of deployed NATs reported consistently higher success rates when using UDP than when using TCP [36]. It is worth noticing that BFCP over UDP is already being used in real deployments, underlining the necessity to specify a common way to exchange BFCP messages where TCP is not appropriate, to avoid a situation where multiple different and non-interoperable implementations would co-exist in the market. The purpose of this draft is to formalize and publish the extension from the standard specification to facilitate complete interoperability between implementations. Camarillo, et al. Expires May 16, 2016 [Page 86] Internet-Draft BFCP November 2015 B.1.1. Alternatives Considered In selecting the approach of defining UDP as an alternate transport for BFCP, several alternatives were considered and explored to some degree. Each of these is discussed briefly in the following subsections. In summary, while the not chosen alternatives work in a number of scenarios, they are not sufficient, in and of themselves, to address the use case targeted by this draft. The last alternative, presented in Appendix B.1.1.7, is the selected one and is specified in this draft. It is also worth noting that the IETF Transport Area were asked for a way to tunnel TCP over UDP, but at that point there was no consensus on how to achieve that. B.1.1.1. ICE TCP ICE TCP [32] extends ICE to TCP based media, including the ability to offer a mix of TCP and UDP based candidates for a single stream. ICE TCP has, in general, a lower success probability for enabling TCP connectivity without a relay if both of the hosts are behind a NAT (see Appendix A of [32]) than enabling UDP connectivity in the same scenarios. The happens because many of the currently deployed NATs in video conferencing networks do not support the flow of TCP hand shake packets seen in case of TCP simultaneous-open, either because they do not allow incoming TCP SYN packets from an address to which a SYN packet has been sent to recently, or because they do not properly process the subsequent SYNACK. Implementing various techniques advocated for candidate collection in [32] should increase the success probability, but many of these techniques require support from some network elements (e.g., from the NATs). Such support is not common in enterprise NATs. B.1.1.2. Teredo Teredo [29] enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Teredo extensions [30] provide additional capabilities to Teredo, including support for more types of NATs and support for more efficient communication. As defined, Teredo could be used to make BFCP work for the video conferencing use cases addressed in this draft. However, running the service requires the help of "Teredo servers" and "Teredo relays" [29]. These servers and relays generally do not exist in the existing video conferencing deployments. It also requires IPv6 awareness on the endpoints. It should also be noted that ICMP6, as used with Teredo to complete an initial protocol exchange and confirm Camarillo, et al. Expires May 16, 2016 [Page 87] Internet-Draft BFCP November 2015 that the appropriate NAT bindings have been set up, is not a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls discard ICMP messages. As these networks continue to evolve and tackle the transaction to IPv6, Teredo servers and relays may be deployed, making Teredo available as a suitable alternative to BFCP over UDP. B.1.1.3. GUT GUT [33] attempts to facilitate tunneling over UDP by encapsulating the native transport protocol and its payload (in general the whole IP payload) within a UDP packet destined to the well-known port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a readily available implementation, and creating one is a large project in itself. This draft has expired and its future is still not clear as it has not yet been adopted by a working group. B.1.1.4. UPnP IGD Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on the edge of the network, providing connectivity to the Internet for computers internal to the LAN, but do not allow Internet devices to connect to computers on the internal LAN. IGDs enable a computer on an internal LAN to create port mappings on their NAT, through which hosts on the Internet can send data that will be forwarded to the computer on the internal LAN. IGDs may be self-contained hardware devices or may be software components provided within an operating system. In considering UPnP IGD, several issues exist. Not all NATs support UPnP, and many that do support it are configured with it turned off by default. NATs are often multilayered, and UPnP does not work well with such NATs. For example, a typical DSL modems acts as a NAT, and the user plugs in a wireless access point behind that, which adds another layer NAT. The client can discover the first layer of NAT using multicast but it is harder to figure out how to discover and control NATs in the next layer up. B.1.1.5. NAT PMP The NAT Port Mapping Protocol (NAT PMP) allows a computer in a private network (behind a NAT router) to automatically configure the router to allow parties outside the private network to contact it. NAT PMP runs over UDP. It essentially automates the process of port forwarding. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it. Camarillo, et al. Expires May 16, 2016 [Page 88] Internet-Draft BFCP November 2015 Many NATs do not support PMP. In those that do support it, it has similar issues with negotiation of multilayer NATs as UPnP. Video conferencing is used extensively in enterprise networks, and NAT PMP is not generally available in enterprise-class routers. B.1.1.6. SCTP It would be quite straight forward to specify a BFCP binding for SCTP [31], and then tunnel SCTP over UDP in the use case described in Appendix B.1. SCTP is gaining some momentum currently. There was ongoing discussion in the RTCWeb WG regarding this approach, which resulted in [27]. However, this approach for tunneling over UDP was not mature enough when considered and not even fully specified. B.1.1.7. BFCP over UDP transport To overcome the problems with establishing TCP flows between BFCP entities, an alternative is to define UDP as an alternate transport for BFCP, leveraging the same mechanisms in place for the RTP over UDP media streams for the BFCP communication. When using UDP as the transport, it is recommended to follow the guidelines provided in [13]. Minor changes to the transaction model are introduced in that all requests now have an appropriate response to complete the transaction. The requests are sent with a retransmit timer associated with the response to achieve reliability. This alternative does not change the semantics of BFCP. It permits UDP as an alternate transport. Existing implementations, in the spirit of the approach detailed in earlier versions of this draft, have demonstrated this approach to be feasible. Initial compatibility among implementations has been achieved at previous interoperability events. The authors view this extension as a pragmatic solution to an existing deployment challenge. This is the chosen approach, and the extensions are specified in this document. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 FI-02420 Jorvas Finland Email: gonzalo.camarillo@ericsson.com Camarillo, et al. Expires May 16, 2016 [Page 89] Internet-Draft BFCP November 2015 Keith Drage Alcatel-Lucent Quadrant, StoneHill Green, Westlea Swindon, Wilts UK Email: drage@alcatel-lucent.com Tom Kristensen Cisco Philip Pedersens vei 1 NO-1366 Lysaker Norway Email: tomkrist@cisco.com, tomkri@ifi.uio.no Joerg Ott Aalto University Otakaari 5 A FI-02150 Espoo Finland Email: jo@comnet.tkk.fi Charles Eckel Cisco 707 Tasman Drive California, CA 95035 United States Email: eckelcu@cisco.com Camarillo, et al. Expires May 16, 2016 [Page 90] ./draft-ietf-httpbis-header-structure-19.txt0000644000764400076440000023100613666107153020335 0ustar iustyiusty HTTP M. Nottingham Internet-Draft Fastly Intended status: Standards Track P-H. Kamp Expires: December 5, 2020 The Varnish Cache Project June 3, 2020 Structured Field Values for HTTP draft-ietf-httpbis-header-structure-19 Abstract This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. Note to Readers _RFC EDITOR: please remove this section before publication_ Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. Working Group information can be found at https://httpwg.github.io/ [2]; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/header-structure [3]. Tests for implementations are collected at https://github.com/httpwg/ structured-field-tests [4]. Implementations are tracked at https://github.com/httpwg/wiki/wiki/ Structured-Headers [5]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Nottingham & Kamp Expires December 5, 2020 [Page 1] Internet-Draft Structured Field Values for HTTP June 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 5, 2020. Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Intentionally Strict Processing . . . . . . . . . . . . . 4 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5 2. Defining New Structured Fields . . . . . . . . . . . . . . . 5 3. Structured Data Types . . . . . . . . . . . . . . . . . . . . 8 3.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. Inner Lists . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 10 3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Integers . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Decimals . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3. Strings . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.4. Tokens . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.5. Byte Sequences . . . . . . . . . . . . . . . . . . . 15 3.3.6. Booleans . . . . . . . . . . . . . . . . . . . . . . 15 4. Working With Structured Fields in HTTP . . . . . . . . . . . 16 4.1. Serializing Structured Fields . . . . . . . . . . . . . . 16 4.1.1. Serializing a List . . . . . . . . . . . . . . . . . 16 4.1.2. Serializing a Dictionary . . . . . . . . . . . . . . 18 4.1.3. Serializing an Item . . . . . . . . . . . . . . . . . 19 4.1.4. Serializing an Integer . . . . . . . . . . . . . . . 20 4.1.5. Serializing a Decimal . . . . . . . . . . . . . . . . 20 4.1.6. Serializing a String . . . . . . . . . . . . . . . . 21 Nottingham & Kamp Expires December 5, 2020 [Page 2] Internet-Draft Structured Field Values for HTTP June 2020 4.1.7. Serializing a Token . . . . . . . . . . . . . . . . . 22 4.1.8. Serializing a Byte Sequence . . . . . . . . . . . . . 22 4.1.9. Serializing a Boolean . . . . . . . . . . . . . . . . 22 4.2. Parsing Structured Fields . . . . . . . . . . . . . . . . 23 4.2.1. Parsing a List . . . . . . . . . . . . . . . . . . . 24 4.2.2. Parsing a Dictionary . . . . . . . . . . . . . . . . 26 4.2.3. Parsing an Item . . . . . . . . . . . . . . . . . . . 27 4.2.4. Parsing an Integer or Decimal . . . . . . . . . . . . 29 4.2.5. Parsing a String . . . . . . . . . . . . . . . . . . 30 4.2.6. Parsing a Token . . . . . . . . . . . . . . . . . . . 31 4.2.7. Parsing a Byte Sequence . . . . . . . . . . . . . . . 32 4.2.8. Parsing a Boolean . . . . . . . . . . . . . . . . . . 33 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Normative References . . . . . . . . . . . . . . . . . . 33 7.2. Informative References . . . . . . . . . . . . . . . . . 34 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 35 A.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 36 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 36 C.1. Since draft-ietf-httpbis-header-structure-18 . . . . . . 37 C.2. Since draft-ietf-httpbis-header-structure-17 . . . . . . 37 C.3. Since draft-ietf-httpbis-header-structure-16 . . . . . . 37 C.4. Since draft-ietf-httpbis-header-structure-15 . . . . . . 37 C.5. Since draft-ietf-httpbis-header-structure-14 . . . . . . 38 C.6. Since draft-ietf-httpbis-header-structure-13 . . . . . . 38 C.7. Since draft-ietf-httpbis-header-structure-12 . . . . . . 39 C.8. Since draft-ietf-httpbis-header-structure-11 . . . . . . 39 C.9. Since draft-ietf-httpbis-header-structure-10 . . . . . . 39 C.10. Since draft-ietf-httpbis-header-structure-09 . . . . . . 39 C.11. Since draft-ietf-httpbis-header-structure-08 . . . . . . 40 C.12. Since draft-ietf-httpbis-header-structure-07 . . . . . . 40 C.13. Since draft-ietf-httpbis-header-structure-06 . . . . . . 41 C.14. Since draft-ietf-httpbis-header-structure-05 . . . . . . 41 C.15. Since draft-ietf-httpbis-header-structure-04 . . . . . . 41 C.16. Since draft-ietf-httpbis-header-structure-03 . . . . . . 41 C.17. Since draft-ietf-httpbis-header-structure-02 . . . . . . 41 C.18. Since draft-ietf-httpbis-header-structure-01 . . . . . . 42 C.19. Since draft-ietf-httpbis-header-structure-00 . . . . . . 42 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Nottingham & Kamp Expires December 5, 2020 [Page 3] Internet-Draft Structured Field Values for HTTP June 2020 1. Introduction Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in Section 8.3.1 of [RFC7231], there are many decisions - and pitfalls - for a prospective HTTP field author. Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has slightly different handling of what looks like common syntax. This document introduces a set of common data structures for use in definitions of new HTTP field values to address these problems. In particular, it defines a generic, abstract model for them, along with a concrete serialization for expressing that model in HTTP [RFC7230] header and trailer fields. A HTTP field that is defined as a "Structured Header" or "Structured Trailer" (if the field can be either, it is a "Structured Field") uses the types defined in this specification to define its syntax and basic handling rules, thereby simplifying both its definition by specification writers and handling by implementations. Additionally, future versions of HTTP can define alternative serializations of the abstract model of these structures, allowing fields that use that model to be transmitted more efficiently without being redefined. Note that it is not a goal of this document to redefine the syntax of existing HTTP fields; the mechanisms described herein are only intended to be used with fields that explicitly opt into them. Section 2 describes how to specify a Structured Field. Section 3 defines a number of abstract data types that can be used in Structured Fields. Those abstract types can be serialized into and parsed from HTTP field values using the algorithms described in Section 4. 1.1. Intentionally Strict Processing This specification intentionally defines strict parsing and serialization behaviors using step-by-step algorithms; the only error handling defined is to fail the operation altogether. It is designed to encourage faithful implementation and therefore good interoperability. Therefore, an implementation that tried to be Nottingham & Kamp Expires December 5, 2020 [Page 4] Internet-Draft Structured Field Values for HTTP June 2020 helpful by being more tolerant of input would make interoperability worse, since that would create pressure on other implementations to implement similar (but likely subtly different) workarounds. In other words, strict processing is an intentional feature of this specification; it allows non-conformant input to be discovered and corrected by the producer early, and avoids both interoperability and security issues that might otherwise result. Note that as a result of this strictness, if a field is appended to by multiple parties (e.g., intermediaries, or different components in the sender), an error in one party's value is likely to cause the entire field value to fail parsing. 1.2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses algorithms to specify parsing and serialization behaviors, and the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] to illustrate expected syntax in HTTP header fields. In doing so, it uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from [RFC5234]. It also includes the tchar and OWS rules from [RFC7230]. When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms. If there is disagreement between the parsing algorithms and ABNF, the specified algorithms take precedence. For serialization to HTTP fields, the ABNF illustrates their expected wire representations, and the algorithms define the recommended way to produce them. Implementations MAY vary from the specified behavior so long as the output is still correctly handled by the parsing algorithm. 2. Defining New Structured Fields To specify a HTTP field as a Structured Field, its authors needs to: o Normatively reference this specification. Recipients and generators of the field need to know that the requirements of this document are in effect. Nottingham & Kamp Expires December 5, 2020 [Page 5] Internet-Draft Structured Field Values for HTTP June 2020 o Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a Structured Trailer (only in the trailer section), or a Structured Field (both). o Specify the type of the field value; either List (Section 3.1), Dictionary (Section 3.2), or Item (Section 3.3). o Define the semantics of the field value. o Specify any additional constraints upon the field value, as well as the consequences when those constraints are violated. Typically, this means that a field definition will specify the top- level type - List, Dictionary or Item - and then define its allowable types, and constraints upon them. For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only strings beginning with the letter "Q", or strings in lowercase. Likewise, Inner Lists (Section 3.1.1) are only valid when a field definition explicitly allows them. When parsing fails, the entire field is ignored (see Section 4.2); in most situations, violating field-specific constraints should have the same effect. Thus, if a header is defined as an Item and required to be an Integer, but a String is received, the field will by default be ignored. If the field requires different error handling, this should be explicitly specified. Both Items and Inner Lists allow parameters as an extensibility mechanism; this means that values can later be extended to accommodate more information, if need be. To preserve forward compatibility, field specifications are discouraged from defining the presence of an unrecognized Parameter as an error condition. To further assure that this extensibility is available in the future, and to encourage consumers to use a complete parser implementation, a field definition can specify that "grease" Parameters be added by senders. A specification could stipulate that all Parameters that fit a defined pattern are reserved for this use and then encourage them to be sent on some portion of requests. This helps to discourage recipients from writing a parser that does not account for Parameters. Specifications that use Dictionaries can also allow for forward compatibility by requiring that the presence of - as well as value and type associated with - unknown members be ignored. Later Nottingham & Kamp Expires December 5, 2020 [Page 6] Internet-Draft Structured Field Values for HTTP June 2020 specifications can then add additional members, specifying constraints on them as appropriate. An extension to a structured field can then require that an entire field value be ignored by a recipient that understands the extension if constraints on the value it defines are not met. A field definition cannot relax the requirements of this specification because doing so would preclude handling by generic software; they can only add additional constraints (for example, on the numeric range of Integers and Decimals, the format of Strings and Tokens, the types allowed in a Dictionary's values, or the number of Items in a List). Likewise, field definitions can only use this specification for the entire field value, not a portion thereof. This specification defines minimums for the length or number of various structures supported by implementations. It does not specify maximum sizes in most cases, but authors should be aware that HTTP implementations do impose various limits on the size of individual fields, the total number of fields, and/or the size of the entire header or trailer section. Specifications can refer to a field name as a "structured header name", "structured trailer name" or "structured field name" as appropriate. Likewise, they can refer its field value as a "structured header value", "structured trailer value" or "structured field value" as necessary. Field definitions are encouraged to use the ABNF rules beginning with "sf-" defined in this specification; other rules in this specification are not intended for their use. For example, a fictitious Foo-Example header field might be specified as: Nottingham & Kamp Expires December 5, 2020 [Page 7] Internet-Draft Structured Field Values for HTTP June 2020 --8<-- 42. Foo-Example Header The Foo-Example HTTP header field conveys information about how much Foo the message has. Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is: Foo-Example = sf-integer Its value indicates the amount of Foo in the message, and MUST be between 0 and 10, inclusive; other values MUST cause the entire header field to be ignored. The following parameters are defined: * A Parameter whose name is "foourl", and whose value is a String (Section Y.Y of [RFCxxxx]), conveying the Foo URL for the message. See below for processing requirements. "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If its value is not a valid URI-reference, the entire header field MUST be ignored. If its value is a relative reference (Section 4.2 of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before being used. For example: Foo-Example: 2; foourl="https://foo.example.com/" -->8-- 3. Structured Data Types This section defines the abstract types for Structured Fields. The ABNF provided represents the on-wire format in HTTP field values. In summary: o There are three top-level types that a HTTP field can be defined as: Lists, Dictionaries, and Items. o Lists and Dictionaries are containers; their members can be Items or Inner Lists (which are themselves arrays of Items). o Both Items and Inner Lists can be parameterized with key/value pairs. Nottingham & Kamp Expires December 5, 2020 [Page 8] Internet-Draft Structured Field Values for HTTP June 2020 3.1. Lists Lists are arrays of zero or more members, each of which can be an Item (Section 3.3) or an Inner List (Section 3.1.1), both of which can be Parameterized (Section 3.1.2). The ABNF for Lists in HTTP fields is: sf-list = list-member *( OWS "," OWS list-member ) list-member = sf-item / inner-list Each member is separated by a comma and optional whitespace. For example, a field whose value is defined as a List of Strings could look like: Example-StrList: "foo", "bar", "It was the best of times." An empty List is denoted by not serializing the field at all. This implies that fields defined as Lists have a default empty value. Note that Lists can have their members split across multiple lines inside a header or trailer section, as per Section 3.2.2 of [RFC7230]; for example, the following are equivalent: Example-Hdr: foo, bar and Example-Hdr: foo Example-Hdr: bar However, individual members of a List cannot be safely split between across lines; see Section 4.2 for details. Parsers MUST support Lists containing at least 1024 members. Field specifications can constrain the types and cardinality of individual List values as they require. 3.1.1. Inner Lists An Inner List is an array of zero or more Items (Section 3.3). Both the individual Items and the Inner List itself can be Parameterized (Section 3.1.2). The ABNF for Inner Lists is: inner-list = "(" *SP [ sf-item *( 1*SP sf-item ) *SP ] ")" parameters Nottingham & Kamp Expires December 5, 2020 [Page 9] Internet-Draft Structured Field Values for HTTP June 2020 Inner Lists are denoted by surrounding parenthesis, and have their values delimited by one or more spaces. A field whose value is defined as a List of Inner Lists of Strings could look like: Example-StrListList: ("foo" "bar"), ("baz"), ("bat" "one"), () Note that the last member in this example is an empty Inner List. A header field whose value is defined as a List of Inner Lists with Parameters at both levels could look like: Example-ListListParam: ("foo"; a=1;b=2);lvl=5, ("bar" "baz");lvl=1 Parsers MUST support Inner Lists containing at least 256 members. Field specifications can constrain the types and cardinality of individual Inner List members as they require. 3.1.2. Parameters Parameters are an ordered map of key-value pairs that are associated with an Item (Section 3.3) or Inner List (Section 3.1.1). The keys are unique within the scope the Parameters they occur within, and the values are bare items (i.e., they themselves cannot be parameterized; see Section 3.3). The ABNF for Parameters is: parameters = *( ";" *SP parameter ) parameter = param-name [ "=" param-value ] param-name = key key = ( lcalpha / "*" ) *( lcalpha / DIGIT / "_" / "-" / "." / "*" ) lcalpha = %x61-7A ; a-z param-value = bare-item Note that Parameters are ordered as serialized, and Parameter keys cannot contain uppercase letters. A parameter is separated from its Item or Inner List and other parameters by a semicolon. For example: Example-ParamList: abc;a=1;b=2; cde_456, (ghi;jk=4 l);q="9";r=w Parameters whose value is Boolean (see Section 3.3.6) true MUST omit that value when serialized. For example, the "a" parameter here is true, while the "b" parameter is false: Example-Int: 1; a; b=?0 Nottingham & Kamp Expires December 5, 2020 [Page 10] Internet-Draft Structured Field Values for HTTP June 2020 Note that this requirement is only on serialization; parsers are still required to correctly handle the true value when it appears in a parameter. Parsers MUST support at least 256 parameters on an Item or Inner List, and support parameter keys with at least 64 characters. Field specifications can constrain the order of individual Parameters, as well as their values' types as required. 3.2. Dictionaries Dictionaries are ordered maps of name-value pairs, where the names are short textual strings and the values are Items (Section 3.3) or arrays of Items, both of which can be Parameterized (Section 3.1.2). There can be zero or more members, and their names are unique in the scope of the Dictionary they occur within. Implementations MUST provide access to Dictionaries both by index and by name. Specifications MAY use either means of accessing the members. The ABNF for Dictionaries is: sf-dictionary = dict-member *( OWS "," OWS dict-member ) dict-member = member-name [ "=" member-value ] member-name = key member-value = sf-item / inner-list Members are ordered as serialized, and separated by a comma with optional whitespace. Member names cannot contain uppercase characters. Names and values are separated by "=" (without whitespace). For example: Example-Dict: en="Applepie", da=:w4ZibGV0w6ZydGU=: Note that in this example, the final "=" is due to the inclusion of a Byte Sequence; see Section 3.3.5. Members whose value is Boolean (see Section 3.3.6) true MUST omit that value when serialized. For example, here both "b" and "c" are true: Example-Dict: a=?0, b, c; foo=bar Note that this requirement is only on serialization; parsers are still required to correctly handle the true Boolean value when it appears in Dictionary values. Nottingham & Kamp Expires December 5, 2020 [Page 11] Internet-Draft Structured Field Values for HTTP June 2020 A Dictionary with a member whose value is an Inner List of Tokens: Example-DictList: rating=1.5, feelings=(joy sadness) A Dictionary with a mix of Items and Inner Lists, some with Parameters: Example-MixDict: a=(1 2), b=3, c=4;aa=bb, d=(5 6);valid As with lists, an empty Dictionary is represented by omitting the entire field. This implies that fields defined as Dictionaries have a default empty value. Typically, a field specification will define the semantics of Dictionaries by specifying the allowed type(s) for individual members by their names, as well as whether their presence is required or optional. Recipients MUST ignore names that are undefined or unknown, unless the field's specification specifically disallows them. Note that Dictionaries can have their members split across multiple lines inside a header or trailer section; for example, the following are equivalent: Example-Hdr: foo=1, bar=2 and Example-Hdr: foo=1 Example-Hdr: bar=2 However, individual members of a Dictionary cannot be safely split between lines; see Section 4.2 for details. Parsers MUST support Dictionaries containing at least 1024 name/value pairs, and names with at least 64 characters. Field specifications can constrain the order of individual Dictionary members, as well as their values' types as required. 3.3. Items An Item can be a Integer (Section 3.3.1), Decimal (Section 3.3.2), String (Section 3.3.3), Token (Section 3.3.4), Byte Sequence (Section 3.3.5), or Boolean (Section 3.3.6). It can have associated Parameters (Section 3.1.2). The ABNF for Items is: Nottingham & Kamp Expires December 5, 2020 [Page 12] Internet-Draft Structured Field Values for HTTP June 2020 sf-item = bare-item parameters bare-item = sf-integer / sf-decimal / sf-string / sf-token / sf-binary / sf-boolean For example, a header field that is defined to be an Item that is an Integer might look like: Example-IntItemHeader: 5 or with Parameters: Example-IntItem: 5; foo=bar 3.3.1. Integers Integers have a range of -999,999,999,999,999 to 999,999,999,999,999 inclusive (i.e., up to fifteen digits, signed), for IEEE 754 compatibility ([IEEE754]). The ABNF for Integers is: sf-integer = ["-"] 1*15DIGIT For example: Example-Integer: 42 Integers larger than 15 digits can be supported in a variety of ways; for example, by using a String (Section 3.3.3), Byte Sequence (Section 3.3.5), or a parameter on an Integer that acts as a scaling factor. While it is possible to serialise Integers with leading zeros (e.g., "0002", "-01") and signed zero ("-0"), these distinctions may not be preserved by implementations. Note that commas in Integers are used in this section's prose only for readability; they are not valid in the wire format. 3.3.2. Decimals Decimals are numbers with an integer and a fractional component. The integer component has at most 12 digits; the fractional component has at most three digits. The ABNF for decimals is: sf-decimal = ["-"] 1*12DIGIT "." 1*3DIGIT Nottingham & Kamp Expires December 5, 2020 [Page 13] Internet-Draft Structured Field Values for HTTP June 2020 For example, a header whose value is defined as a Decimal could look like: Example-Decimal: 4.5 While it is possible to serialise Decimals with leading zeros (e.g., "0002.5", "-01.334"), trailing zeros (e.g., "5.230", "-0.40"), and signed zero (e.g., "-0.0"), these distinctions may not be preserved by implementations. Note that the serialisation algorithm (Section 4.1.5) rounds input with more than three digits of precision in the fractional component. If an alternative rounding strategy is desired, this should be specified by the header definition to occur before serialisation. 3.3.3. Strings Strings are zero or more printable ASCII [RFC0020] characters (i.e., the range %x20 to %x7E). Note that this excludes tabs, newlines, carriage returns, etc. The ABNF for Strings is: sf-string = DQUOTE *chr DQUOTE chr = unescaped / escaped unescaped = %x20-21 / %x23-5B / %x5D-7E escaped = "\" ( DQUOTE / "\" ) Strings are delimited with double quotes, using a backslash ("\") to escape double quotes and backslashes. For example: Example-String: "hello world" Note that Strings only use DQUOTE as a delimiter; single quotes do not delimit Strings. Furthermore, only DQUOTE and "\" can be escaped; other characters after "\" MUST cause parsing to fail. Unicode is not directly supported in Strings, because it causes a number of interoperability issues, and - with few exceptions - field values do not require it. When it is necessary for a field value to convey non-ASCII content, a Byte Sequence (Section 3.3.5) can be specified, along with a character encoding (preferably [UTF-8]). Parsers MUST support Strings (after any decoding) with at least 1024 characters. Nottingham & Kamp Expires December 5, 2020 [Page 14] Internet-Draft Structured Field Values for HTTP June 2020 3.3.4. Tokens Tokens are short textual words; their abstract model is identical to their expression in the HTTP field value serialization. The ABNF for Tokens is: sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" ) For example: Example-Token: foo123/456 Parsers MUST support Tokens with at least 512 characters. Note that Token allows the same characters as the "token" ABNF rule defined in [RFC7230], with the exceptions that the first character is required to be either ALPHA or "*", and ":" and "/" are also allowed in subsequent characters. 3.3.5. Byte Sequences Byte Sequences can be conveyed in Structured Fields. The ABNF for a Byte Sequence is: sf-binary = ":" *(base64) ":" base64 = ALPHA / DIGIT / "+" / "/" / "=" A Byte Sequence is delimited with colons and encoded using base64 ([RFC4648], Section 4). For example: Example-Binary: :cHJldGVuZCB0aGlzIGlzIGJpbmFyeSBjb250ZW50Lg==: Parsers MUST support Byte Sequences with at least 16384 octets after decoding. 3.3.6. Booleans Boolean values can be conveyed in Structured Fields. The ABNF for a Boolean is: sf-boolean = "?" boolean boolean = "0" / "1" A Boolean is indicated with a leading "?" character followed by a "1" for a true value or "0" for false. For example: Nottingham & Kamp Expires December 5, 2020 [Page 15] Internet-Draft Structured Field Values for HTTP June 2020 Example-Bool: ?1 Note that in Dictionary (Section 3.2) and Parameter (Section 3.1.2) values, Boolean true is indicated by omitting the value. 4. Working With Structured Fields in HTTP This section defines how to serialize and parse Structured Fields in textual HTTP field values and other encodings compatible with them (e.g., in HTTP/2 [RFC7540] before compression with HPACK [RFC7541]). 4.1. Serializing Structured Fields Given a structure defined in this specification, return an ASCII string suitable for use in a HTTP field value. 1. If the structure is a Dictionary or List and its value is empty (i.e., it has no members), do not serialize the field at all (i.e., omit both the field-name and field-value). 2. If the structure is a List, let output_string be the result of running Serializing a List (Section 4.1.1) with the structure. 3. Else if the structure is a Dictionary, let output_string be the result of running Serializing a Dictionary (Section 4.1.2) with the structure. 4. Else if the structure is an Item, let output_string be the result of running Serializing an Item (Section 4.1.3) with the structure. 5. Else, fail serialization. 6. Return output_string converted into an array of bytes, using ASCII encoding [RFC0020]. 4.1.1. Serializing a List Given an array of (member_value, parameters) tuples as input_list, return an ASCII string suitable for use in a HTTP field value. 1. Let output be an empty string. 2. For each (member_value, parameters) of input_list: 1. If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output. Nottingham & Kamp Expires December 5, 2020 [Page 16] Internet-Draft Structured Field Values for HTTP June 2020 2. Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output. 3. If more member_values remain in input_list: 1. Append "," to output. 2. Append a single SP to output. 3. Return output. 4.1.1.1. Serializing an Inner List Given an array of (member_value, parameters) tuples as inner_list, and parameters as list_parameters, return an ASCII string suitable for use in a HTTP field value. 1. Let output be the string "(". 2. For each (member_value, parameters) of inner_list: 1. Append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output. 2. If more values remain in inner_list, append a single SP to output. 3. Append ")" to output. 4. Append the result of running Serializing Parameters (Section 4.1.1.2) with list_parameters to output. 5. Return output. 4.1.1.2. Serializing Parameters Given an ordered Dictionary as input_parameters (each member having a param_name and a param_value), return an ASCII string suitable for use in a HTTP field value. 1. Let output be an empty string. 2. For each param_name with a value of param_value in input_parameters: 1. Append ";" to output. Nottingham & Kamp Expires December 5, 2020 [Page 17] Internet-Draft Structured Field Values for HTTP June 2020 2. Append the result of running Serializing a Key (Section 4.1.1.3) with param_name to output. 3. If param_value is not Boolean true: 1. Append "=" to output. 2. Append the result of running Serializing a bare Item (Section 4.1.3.1) with param_value to output. 3. Return output. 4.1.1.3. Serializing a Key Given a key as input_key, return an ASCII string suitable for use in a HTTP field value. 1. Convert input_key into a sequence of ASCII characters; if conversion fails, fail serialization. 2. If input_key contains characters not in lcalpha, DIGIT, "_", "-", ".", or "*" fail serialization. 3. If the first character of input_key is not lcalpha or "*", fail serialization. 4. Let output be an empty string. 5. Append input_key to output. 6. Return output. 4.1.2. Serializing a Dictionary Given an ordered Dictionary as input_dictionary (each member having a member_name and a tuple value of (member_value, parameters)), return an ASCII string suitable for use in a HTTP field value. 1. Let output be an empty string. 2. For each member_name with a value of (member_value, parameters) in input_dictionary: 1. Append the result of running Serializing a Key (Section 4.1.1.3) with member's member_name to output. 2. If member_value is Boolean true: Nottingham & Kamp Expires December 5, 2020 [Page 18] Internet-Draft Structured Field Values for HTTP June 2020 1. Append the result of running Serializing Parameters (Section 4.1.1.2) with parameters to output. 3. Otherwise: 1. Append "=" to output. 2. If member_value is an array, append the result of running Serializing an Inner List (Section 4.1.1.1) with (member_value, parameters) to output. 3. Otherwise, append the result of running Serializing an Item (Section 4.1.3) with (member_value, parameters) to output. 4. If more members remain in input_dictionary: 1. Append "," to output. 2. Append a single SP to output. 3. Return output. 4.1.3. Serializing an Item Given an Item as bare_item and Parameters as item_parameters, return an ASCII string suitable for use in a HTTP field value. 1. Let output be an empty string. 2. Append the result of running Serializing a Bare Item Section 4.1.3.1 with bare_item to output. 3. Append the result of running Serializing Parameters Section 4.1.1.2 with item_parameters to output. 4. Return output. 4.1.3.1. Serializing a Bare Item Given an Item as input_item, return an ASCII string suitable for use in a HTTP field value. 1. If input_item is an Integer, return the result of running Serializing an Integer (Section 4.1.4) with input_item. 2. If input_item is a Decimal, return the result of running Serializing a Decimal (Section 4.1.5) with input_item. Nottingham & Kamp Expires December 5, 2020 [Page 19] Internet-Draft Structured Field Values for HTTP June 2020 3. If input_item is a String, return the result of running Serializing a String (Section 4.1.6) with input_item. 4. If input_item is a Token, return the result of running Serializing a Token (Section 4.1.7) with input_item. 5. If input_item is a Boolean, return the result of running Serializing a Boolean (Section 4.1.9) with input_item. 6. If input_item is a Byte Sequence, return the result of running Serializing a Byte Sequence (Section 4.1.8) with input_item. 7. Otherwise, fail serialization. 4.1.4. Serializing an Integer Given an Integer as input_integer, return an ASCII string suitable for use in a HTTP field value. 1. If input_integer is not an integer in the range of -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail serialization. 2. Let output be an empty string. 3. If input_integer is less than (but not equal to) 0, append "-" to output. 4. Append input_integer's numeric value represented in base 10 using only decimal digits to output. 5. Return output. 4.1.5. Serializing a Decimal Given a decimal number as input_decimal, return an ASCII string suitable for use in a HTTP field value. 1. If input_decimal is not a decimal number, fail serialization. 2. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant. 3. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialization. Nottingham & Kamp Expires December 5, 2020 [Page 20] Internet-Draft Structured Field Values for HTTP June 2020 4. Let output be an empty string. 5. If input_decimal is less than (but not equal to) 0, append "-" to output. 6. Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0". 7. Append "." to output. 8. If input_decimal's fractional component is zero, append "0" to output. 9. Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal digits) to output. 10. Return output. 4.1.6. Serializing a String Given a String as input_string, return an ASCII string suitable for use in a HTTP field value. 1. Convert input_string into a sequence of ASCII characters; if conversion fails, fail serialization. 2. If input_string contains characters in the range %x00-1f or %x7f (i.e., not in VCHAR or SP), fail serialization. 3. Let output be the string DQUOTE. 4. For each character char in input_string: 1. If char is "\" or DQUOTE: 1. Append "\" to output. 2. Append char to output. 5. Append DQUOTE to output. 6. Return output. Nottingham & Kamp Expires December 5, 2020 [Page 21] Internet-Draft Structured Field Values for HTTP June 2020 4.1.7. Serializing a Token Given a Token as input_token, return an ASCII string suitable for use in a HTTP field value. 1. Convert input_token into a sequence of ASCII characters; if conversion fails, fail serialization. 2. If the first character of input_token is not ALPHA or "*", or the remaining portion contains a character not in tchar, ":" or "/", fail serialization. 3. Let output be an empty string. 4. Append input_token to output. 5. Return output. 4.1.8. Serializing a Byte Sequence Given a Byte Sequence as input_bytes, return an ASCII string suitable for use in a HTTP field value. 1. If input_bytes is not a sequence of bytes, fail serialization. 2. Let output be an empty string. 3. Append ":" to output. 4. Append the result of base64-encoding input_bytes as per [RFC4648], Section 4, taking account of the requirements below. 5. Append ":" to output. 6. Return output. The encoded data is required to be padded with "=", as per [RFC4648], Section 3.2. Likewise, encoded data SHOULD have pad bits set to zero, as per [RFC4648], Section 3.5, unless it is not possible to do so due to implementation constraints. 4.1.9. Serializing a Boolean Given a Boolean as input_boolean, return an ASCII string suitable for use in a HTTP field value. Nottingham & Kamp Expires December 5, 2020 [Page 22] Internet-Draft Structured Field Values for HTTP June 2020 1. If input_boolean is not a boolean, fail serialization. 2. Let output be an empty string. 3. Append "?" to output. 4. If input_boolean is true, append "1" to output. 5. If input_boolean is false, append "0" to output. 6. Return output. 4.2. Parsing Structured Fields When a receiving implementation parses HTTP fields that are known to be Structured Fields, it is important that care be taken, as there are a number of edge cases that can cause interoperability or even security problems. This section specifies the algorithm for doing so. Given an array of bytes input_bytes that represents the chosen field's field-value (which is empty if that field is not present), and field_type (one of "dictionary", "list", or "item"), return the parsed header value. 1. Convert input_bytes into an ASCII string input_string; if conversion fails, fail parsing. 2. Discard any leading SP characters from input_string. 3. If field_type is "list", let output be the result of running Parsing a List (Section 4.2.1) with input_string. 4. If field_type is "dictionary", let output be the result of running Parsing a Dictionary (Section 4.2.2) with input_string. 5. If field_type is "item", let output be the result of running Parsing an Item (Section 4.2.3) with input_string. 6. Discard any leading SP characters from input_string. 7. If input_string is not empty, fail parsing. 8. Otherwise, return output. When generating input_bytes, parsers MUST combine all field lines in the same section (header or trailer) that case-insensitively match the field name into one comma-separated field-value, as per Nottingham & Kamp Expires December 5, 2020 [Page 23] Internet-Draft Structured Field Values for HTTP June 2020 [RFC7230], Section 3.2.2; this assures that the entire field value is processed correctly. For Lists and Dictionaries, this has the effect of correctly concatenating all of the field's lines, as long as individual members of the top-level data structure are not split across multiple header instances. The parsing algorithms for both types allow tab characters, since these might be used to combine field lines by some implementations. Strings split across multiple field lines will have unpredictable results, because comma(s) and whitespace inserted upon combination will become part of the string output by the parser. Since concatenation might be done by an upstream intermediary, the results are not under the control of the serializer or the parser, even when they are both under the control of the same party. Tokens, Integers, Decimals and Byte Sequences cannot be split across multiple field lines because the inserted commas will cause parsing to fail. Parsers MAY fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field. For example, a parsing handling an Example-String field that's defined as a sf-string is allowed to fail when processing this field section: Example-String: "foo Example-String: bar" If parsing fails - including when calling another algorithm - the entire field value MUST be ignored (i.e., treated as if the field were not present in the section). This is intentionally strict, to improve interoperability and safety, and specifications referencing this document are not allowed to loosen this requirement. Note that this requirement does not apply to an implementation that is not parsing the field; for example, an intermediary is not required to strip a failing field from a message before forwarding it. 4.2.1. Parsing a List Given an ASCII string as input_string, return an array of (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value. 1. Let members be an empty array. Nottingham & Kamp Expires December 5, 2020 [Page 24] Internet-Draft Structured Field Values for HTTP June 2020 2. While input_string is not empty: 1. Append the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string to members. 2. Discard any leading OWS characters from input_string. 3. If input_string is empty, return members. 4. Consume the first character of input_string; if it is not ",", fail parsing. 5. Discard any leading OWS characters from input_string. 6. If input_string is empty, there is a trailing comma; fail parsing. 3. No structured data has been found; return members (which is empty). 4.2.1.1. Parsing an Item or Inner List Given an ASCII string as input_string, return the tuple (item_or_inner_list, parameters), where item_or_inner_list can be either a single bare item, or an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value. 1. If the first character of input_string is "(", return the result of running Parsing an Inner List (Section 4.2.1.2) with input_string. 2. Return the result of running Parsing an Item (Section 4.2.3) with input_string. 4.2.1.2. Parsing an Inner List Given an ASCII string as input_string, return the tuple (inner_list, parameters), where inner_list is an array of (bare_item, parameters) tuples. input_string is modified to remove the parsed value. 1. Consume the first character of input_string; if it is not "(", fail parsing. 2. Let inner_list be an empty array. 3. While input_string is not empty: 1. Discard any leading SP characters from input_string. Nottingham & Kamp Expires December 5, 2020 [Page 25] Internet-Draft Structured Field Values for HTTP June 2020 2. If the first character of input_string is ")": 1. Consume the first character of input_string. 2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string. 3. Return the tuple (inner_list, parameters). 3. Let item be the result of running Parsing an Item (Section 4.2.3) with input_string. 4. Append item to inner_list. 5. If the first character of input_string is not SP or ")", fail parsing. 4. The end of the inner list was not found; fail parsing. 4.2.2. Parsing a Dictionary Given an ASCII string as input_string, return an ordered map whose values are (item_or_inner_list, parameters) tuples. input_string is modified to remove the parsed value. 1. Let dictionary be an empty, ordered map. 2. While input_string is not empty: 1. Let this_key be the result of running Parsing a Key (Section 4.2.3.3) with input_string. 2. If the first character of input_string is "=": 1. Consume the first character of input_string. 2. Let member be the result of running Parsing an Item or Inner List (Section 4.2.1.1) with input_string. 3. Otherwise: 1. Let value be Boolean true. 2. Let parameters be the result of running Parsing Parameters Section 4.2.3.2 with input_string. 3. Let member be the tuple (value, parameters). Nottingham & Kamp Expires December 5, 2020 [Page 26] Internet-Draft Structured Field Values for HTTP June 2020 4. Add name this_key with value member to dictionary. If dictionary already contains a name this_key (comparing character-for-character), overwrite its value. 5. Discard any leading OWS characters from input_string. 6. If input_string is empty, return dictionary. 7. Consume the first character of input_string; if it is not ",", fail parsing. 8. Discard any leading OWS characters from input_string. 9. If input_string is empty, there is a trailing comma; fail parsing. 3. No structured data has been found; return dictionary (which is empty). Note that when duplicate Dictionary keys are encountered, this has the effect of ignoring all but the last instance. 4.2.3. Parsing an Item Given an ASCII string as input_string, return a (bare_item, parameters) tuple. input_string is modified to remove the parsed value. 1. Let bare_item be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string. 2. Let parameters be the result of running Parsing Parameters (Section 4.2.3.2) with input_string. 3. Return the tuple (bare_item, parameters). 4.2.3.1. Parsing a Bare Item Given an ASCII string as input_string, return a bare Item. input_string is modified to remove the parsed value. 1. If the first character of input_string is a "-" or a DIGIT, return the result of running Parsing an Integer or Decimal (Section 4.2.4) with input_string. 2. If the first character of input_string is a DQUOTE, return the result of running Parsing a String (Section 4.2.5) with input_string. Nottingham & Kamp Expires December 5, 2020 [Page 27] Internet-Draft Structured Field Values for HTTP June 2020 3. If the first character of input_string is ":", return the result of running Parsing a Byte Sequence (Section 4.2.7) with input_string. 4. If the first character of input_string is "?", return the result of running Parsing a Boolean (Section 4.2.8) with input_string. 5. If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (Section 4.2.6) with input_string. 6. Otherwise, the item type is unrecognized; fail parsing. 4.2.3.2. Parsing Parameters Given an ASCII string as input_string, return an ordered map whose values are bare Items. input_string is modified to remove the parsed value. 1. Let parameters be an empty, ordered map. 2. While input_string is not empty: 1. If the first character of input_string is not ";", exit the loop. 2. Consume a ";" character from the beginning of input_string. 3. Discard any leading SP characters from input_string. 4. let param_name be the result of running Parsing a Key (Section 4.2.3.3) with input_string. 5. Let param_value be Boolean true. 6. If the first character of input_string is "=": 1. Consume the "=" character at the beginning of input_string. 2. Let param_value be the result of running Parsing a Bare Item (Section 4.2.3.1) with input_string. 7. Append key param_name with value param_value to parameters. If parameters already contains a name param_name (comparing character-for-character), overwrite its value. 3. Return parameters. Nottingham & Kamp Expires December 5, 2020 [Page 28] Internet-Draft Structured Field Values for HTTP June 2020 Note that when duplicate Parameter keys are encountered, this has the effect of ignoring all but the last instance. 4.2.3.3. Parsing a Key Given an ASCII string as input_string, return a key. input_string is modified to remove the parsed value. 1. If the first character of input_string is not lcalpha or "*", fail parsing. 2. Let output_string be an empty string. 3. While input_string is not empty: 1. If the first character of input_string is not one of lcalpha, DIGIT, "_", "-", ".", or "*", return output_string. 2. Let char be the result of consuming the first character of input_string. 3. Append char to output_string. 4. Return output_string. 4.2.4. Parsing an Integer or Decimal Given an ASCII string as input_string, return an Integer or Decimal. input_string is modified to remove the parsed value. NOTE: This algorithm parses both Integers (Section 3.3.1) and Decimals (Section 3.3.2), and returns the corresponding structure. 1. Let type be "integer". 2. Let sign be 1. 3. Let input_number be an empty string. 4. If the first character of input_string is "-", consume it and set sign to -1. 5. If input_string is empty, there is an empty integer; fail parsing. 6. If the first character of input_string is not a DIGIT, fail parsing. Nottingham & Kamp Expires December 5, 2020 [Page 29] Internet-Draft Structured Field Values for HTTP June 2020 7. While input_string is not empty: 1. Let char be the result of consuming the first character of input_string. 2. If char is a DIGIT, append it to input_number. 3. Else, if type is "integer" and char is ".": 1. If input_number contains more than 12 characters, fail parsing. 2. Otherwise, append char to input_number and set type to "decimal". 4. Otherwise, prepend char to input_string, and exit the loop. 5. If type is "integer" and input_number contains more than 15 characters, fail parsing. 6. If type is "decimal" and input_number contains more than 16 characters, fail parsing. 8. If type is "integer": 1. Parse input_number as an integer and let output_number be the product of the result and sign. 2. If output_number is outside the range -999,999,999,999,999 to 999,999,999,999,999 inclusive, fail parsing. 9. Otherwise: 1. If the final character of input_number is ".", fail parsing. 2. If the number of characters after "." in input_number is greater than three, fail parsing. 3. Parse input_number as a decimal number and let output_number be the product of the result and sign. 10. Return output_number. 4.2.5. Parsing a String Given an ASCII string as input_string, return an unquoted String. input_string is modified to remove the parsed value. Nottingham & Kamp Expires December 5, 2020 [Page 30] Internet-Draft Structured Field Values for HTTP June 2020 1. Let output_string be an empty string. 2. If the first character of input_string is not DQUOTE, fail parsing. 3. Discard the first character of input_string. 4. While input_string is not empty: 1. Let char be the result of consuming the first character of input_string. 2. If char is a backslash ("\"): 1. If input_string is now empty, fail parsing. 2. Let next_char be the result of consuming the first character of input_string. 3. If next_char is not DQUOTE or "\", fail parsing. 4. Append next_char to output_string. 3. Else, if char is DQUOTE, return output_string. 4. Else, if char is in the range %x00-1f or %x7f (i.e., is not in VCHAR or SP), fail parsing. 5. Else, append char to output_string. 5. Reached the end of input_string without finding a closing DQUOTE; fail parsing. 4.2.6. Parsing a Token Given an ASCII string as input_string, return a Token. input_string is modified to remove the parsed value. 1. If the first character of input_string is not ALPHA or "*", fail parsing. 2. Let output_string be an empty string. 3. While input_string is not empty: 1. If the first character of input_string is not in tchar, ":" or "/", return output_string. Nottingham & Kamp Expires December 5, 2020 [Page 31] Internet-Draft Structured Field Values for HTTP June 2020 2. Let char be the result of consuming the first character of input_string. 3. Append char to output_string. 4. Return output_string. 4.2.7. Parsing a Byte Sequence Given an ASCII string as input_string, return a Byte Sequence. input_string is modified to remove the parsed value. 1. If the first character of input_string is not ":", fail parsing. 2. Discard the first character of input_string. 3. If there is not a ":" character before the end of input_string, fail parsing. 4. Let b64_content be the result of consuming content of input_string up to but not including the first instance of the character ":". 5. Consume the ":" character at the beginning of input_string. 6. If b64_content contains a character not included in ALPHA, DIGIT, "+", "/" and "=", fail parsing. 7. Let binary_content be the result of Base 64 Decoding [RFC4648] b64_content, synthesizing padding if necessary (note the requirements about recipient behavior below). 8. Return binary_content. Because some implementations of base64 do not allow rejection of encoded data that is not properly "=" padded (see [RFC4648], Section 3.2), parsers SHOULD NOT fail when "=" padding is not present, unless they cannot be configured to do so. Because some implementations of base64 do not allow rejection of encoded data that has non-zero pad bits (see [RFC4648], Section 3.5), parsers SHOULD NOT fail when non-zero pad bits are present, unless they cannot be configured to do so. This specification does not relax the requirements in [RFC4648], Section 3.1 and 3.3; therefore, parsers MUST fail on characters outside the base64 alphabet, and on line feeds in encoded data. Nottingham & Kamp Expires December 5, 2020 [Page 32] Internet-Draft Structured Field Values for HTTP June 2020 4.2.8. Parsing a Boolean Given an ASCII string as input_string, return a Boolean. input_string is modified to remove the parsed value. 1. If the first character of input_string is not "?", fail parsing. 2. Discard the first character of input_string. 3. If the first character of input_string matches "1", discard the first character, and return true. 4. If the first character of input_string matches "0", discard the first character, and return false. 5. No value has matched; fail parsing. 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations The size of most types defined by Structured Fields is not limited; as a result, extremely large fields could be an attack vector (e.g., for resource consumption). Most HTTP implementations limit the sizes of individual fields as well as the overall header or trailer section size to mitigate such attacks. It is possible for parties with the ability to inject new HTTP fields to change the meaning of a Structured Field. In some circumstances, this will cause parsing to fail, but it is not possible to reliably fail in all such circumstances. 7. References 7.1. Normative References [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Nottingham & Kamp Expires December 5, 2020 [Page 33] Internet-Draft Structured Field Values for HTTP June 2020 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, ISBN 978-1-5044-5924-2, July 2019, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Nottingham & Kamp Expires December 5, 2020 [Page 34] Internet-Draft Structured Field Values for HTTP June 2020 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . 7.3. URIs [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [2] https://httpwg.github.io/ [3] https://github.com/httpwg/http-extensions/labels/header-structure [4] https://github.com/httpwg/structured-field-tests [5] https://github.com/httpwg/wiki/wiki/Structured-Headers [6] https://github.com/httpwg/structured-field-tests Appendix A. Frequently Asked Questions A.1. Why not JSON? Earlier proposals for Structured Fields were based upon JSON [RFC8259]. However, constraining its use to make it suitable for HTTP header fields required senders and recipients to implement specific additional handling. For example, JSON has specification issues around large numbers and objects with duplicate members. Although advice for avoiding these issues is available (e.g., [RFC7493]), it cannot be relied upon. Likewise, JSON strings are by default Unicode strings, which have a number of potential interoperability issues (e.g., in comparison). Although implementers can be advised to avoid non-ASCII content where unnecessary, this is difficult to enforce. Another example is JSON's ability to nest content to arbitrary depths. Since the resulting memory commitment might be unsuitable (e.g., in embedded and other limited server deployments), it's necessary to limit it in some fashion; however, existing JSON implementations have no such limits, and even if a limit is specified, it's likely that some field definition will find a need to violate it. Because of JSON's broad adoption and implementation, it is difficult to impose such additional constraints across all implementations; some deployments would fail to enforce them, thereby harming Nottingham & Kamp Expires December 5, 2020 [Page 35] Internet-Draft Structured Field Values for HTTP June 2020 interoperability. In short, if it looks like JSON, people will be tempted to use a JSON parser / serializer on field values. Since a major goal for Structured Fields is to improve interoperability and simplify implementation, these concerns led to a format that requires a dedicated parser and serializer. Additionally, there were widely shared feelings that JSON doesn't "look right" in HTTP fields. Appendix B. Implementation Notes A generic implementation of this specification should expose the top- level serialize (Section 4.1) and parse (Section 4.2) functions. They need not be functions; for example, it could be implemented as an object, with methods for each of the different top-level types. For interoperability, it's important that generic implementations be complete and follow the algorithms closely; see Section 1.1. To aid this, a common test suite is being maintained by the community at https://github.com/httpwg/structured-field-tests [6]. Implementers should note that Dictionaries and Parameters are order- preserving maps. Some fields may not convey meaning in the ordering of these data types, but it should still be exposed so that applications which need to use it will have it available. Likewise, implementations should note that it's important to preserve the distinction between Tokens and Strings. While most programming languages have native types that map to the other types well, it may be necessary to create a wrapper "token" object or use a parameter on functions to assure that these types remain separate. The serialization algorithm is defined in a way that it is not strictly limited to the data types defined in Section 3 in every case. For example, Decimals are designed to take broader input and round to allowed values. Implementations are allowed to limit the allowed size of different structures, subject to the minimums defined for each type. When a structure exceeds an implementation limit, that structure fails parsing or serialisation. Appendix C. Changes _RFC Editor: Please remove this section before publication._ Nottingham & Kamp Expires December 5, 2020 [Page 36] Internet-Draft Structured Field Values for HTTP June 2020 C.1. Since draft-ietf-httpbis-header-structure-18 o Use "sf-" prefix for ABNF, not "sh-". o Fix indentation in Dictionary serialisation (#1164). o Add example for Token; tweak example field names (#1147). o Editorial improvements. o Note that exceeding implementation limits implies failure. o Talk about specifying order of Dictionary members and Parameters, not cardinality. o Allow (but don't require) parsers to fail when a single field line isn't valid. o Note that some aspects of Integers and Decimals are not necessarily preserved. o Allow Lists and Dictionaries to be delimited by OWS, rather than *SP, to make parsing more robust. C.2. Since draft-ietf-httpbis-header-structure-17 o Editorial improvements. C.3. Since draft-ietf-httpbis-header-structure-16 o Editorial improvements. o Discussion on forwards compatibility. C.4. Since draft-ietf-httpbis-header-structure-15 o Editorial improvements. o Use HTTP field terminology more consistently, in line with recent changes to HTTP-core. o String length requirements apply to decoded strings (#1051). o Correctly round decimals in serialisation (#1043). o Clarify input to serialisation algorithms (#1055). o Omitted True dictionary value can have parameters (#1083). Nottingham & Kamp Expires December 5, 2020 [Page 37] Internet-Draft Structured Field Values for HTTP June 2020 o Keys can now start with '*' (#1068). C.5. Since draft-ietf-httpbis-header-structure-14 o Editorial improvements. o Allow empty dictionary values (#992). o Change value of omitted parameter value to True (#995). o Explain more about splitting dictionaries and lists across header instances (#997). o Disallow HTAB, replace OWS with spaces (#998). o Change byte sequence delimiters from "*" to ":" (#991). o Allow tokens to start with "*" (#991). o Change Floats to fixed-precision Decimals (#982). o Round the fractional component of decimal, rather than truncating it (#982). o Handle duplicate dictionary and parameter keys by overwriting their values, rather than failing (#997). o Allow "." in key (#1027). o Check first character of key in serialisation (#1037). o Talk about greasing headers (#1015). C.6. Since draft-ietf-httpbis-header-structure-13 o Editorial improvements. o Define "structured header name" and "structured header value" terms (#908). o Corrected text about valid characters in strings (#931). o Removed most instances of the word "textual", as it was redundant (#915). o Allowed parameters on Items and Inner Lists (#907). o Expand the range of characters in token (#961). Nottingham & Kamp Expires December 5, 2020 [Page 38] Internet-Draft Structured Field Values for HTTP June 2020 o Disallow OWS before ";" delimiter in parameters (#961). C.7. Since draft-ietf-httpbis-header-structure-12 o Editorial improvements. o Reworked float serialisation (#896). o Don't add a trailing space in inner-list (#904). C.8. Since draft-ietf-httpbis-header-structure-11 o Allow * in key (#844). o Constrain floats to six digits of precision (#848). o Allow dictionary members to have parameters (#842). C.9. Since draft-ietf-httpbis-header-structure-10 o Update abstract (#799). o Input and output are now arrays of bytes (#662). o Implementations need to preserve difference between token and string (#790). o Allow empty dictionaries and lists (#781). o Change parameterized lists to have primary items (#797). o Allow inner lists in both dictionaries and lists; removes lists of lists (#816). o Subsume Parameterised Lists into Lists (#839). C.10. Since draft-ietf-httpbis-header-structure-09 o Changed Boolean from T/F to 1/0 (#784). o Parameters are now ordered maps (#765). o Clamp integers to 15 digits (#737). Nottingham & Kamp Expires December 5, 2020 [Page 39] Internet-Draft Structured Field Values for HTTP June 2020 C.11. Since draft-ietf-httpbis-header-structure-08 o Disallow whitespace before items properly (#703). o Created "key" for use in dictionaries and parameters, rather than relying on identifier (#702). Identifiers have a separate minimum supported size. o Expanded the range of special characters allowed in identifier to include all of ALPHA, ".", ":", and "%" (#702). o Use "?" instead of "!" to indicate a Boolean (#719). o Added "Intentionally Strict Processing" (#684). o Gave better names for referring specs to use in Parameterised Lists (#720). o Added Lists of Lists (#721). o Rename Identifier to Token (#725). o Add implementation guidance (#727). C.12. Since draft-ietf-httpbis-header-structure-07 o Make Dictionaries ordered mappings (#659). o Changed "binary content" to "byte sequence" to align with Infra specification (#671). o Changed "mapping" to "map" for #671. o Don't fail if byte sequences aren't "=" padded (#658). o Add Booleans (#683). o Allow identifiers in items again (#629). o Disallowed whitespace before items (#703). o Explain the consequences of splitting a string across multiple headers (#686). Nottingham & Kamp Expires December 5, 2020 [Page 40] Internet-Draft Structured Field Values for HTTP June 2020 C.13. Since draft-ietf-httpbis-header-structure-06 o Add a FAQ. o Allow non-zero pad bits. o Explicitly check for integers that violate constraints. C.14. Since draft-ietf-httpbis-header-structure-05 o Reorganise specification to separate parsing out. o Allow referencing specs to use ABNF. o Define serialisation algorithms. o Refine relationship between ABNF, parsing and serialisation algorithms. C.15. Since draft-ietf-httpbis-header-structure-04 o Remove identifiers from item. o Remove most limits on sizes. o Refine number parsing. C.16. Since draft-ietf-httpbis-header-structure-03 o Strengthen language around failure handling. C.17. Since draft-ietf-httpbis-header-structure-02 o Split Numbers into Integers and Floats. o Define number parsing. o Tighten up binary parsing and give it an explicit end delimiter. o Clarify that mappings are unordered. o Allow zero-length strings. o Improve string parsing algorithm. o Improve limits in algorithms. o Require parsers to combine header fields before processing. Nottingham & Kamp Expires December 5, 2020 [Page 41] Internet-Draft Structured Field Values for HTTP June 2020 o Throw an error on trailing garbage. C.18. Since draft-ietf-httpbis-header-structure-01 o Replaced with draft-nottingham-structured-headers. C.19. Since draft-ietf-httpbis-header-structure-00 o Added signed 64bit integer type. o Drop UTF8, and settle on BCP137 ::EmbeddedUnicodeChar for h1- unicode-string. o Change h1_blob delimiter to ":" since "'" is valid t_char Acknowledgements Many thanks to Matthew Kerwin for his detailed feedback and careful consideration during the development of this specification. Thanks also to Ian Clelland, Roy Fielding, Anne van Kesteren, Kazuho Oku, Evert Pot, Julian Reschke, Martin Thomson, Mike West, and Jeffrey Yasskin for their contributions. Authors' Addresses Mark Nottingham Fastly Email: mnot@mnot.net URI: https://www.mnot.net/ Poul-Henning Kamp The Varnish Cache Project Email: phk@varnish-cache.org Nottingham & Kamp Expires December 5, 2020 [Page 42] ./draft-ietf-bfcpbis-rfc4583bis-27.txt0000644000764400076440000013742613402762511016601 0ustar iustyiusty BFCPbis Working Group G. Camarillo Internet-Draft Ericsson Obsoletes: 4583 (if approved) T. Kristensen Intended status: Standards Track Cisco Expires: June 11, 2019 C. Holmberg Ericsson December 8, 2018 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams draft-ietf-bfcpbis-rfc4583bis-27 Abstract This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 11, 2019. Copyright Notice Copyright (c) 2018 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 Camarillo, et al. Expires June 11, 2019 [Page 1] Internet-Draft BFCP December 2018 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Floor Control Roles . . . . . . . . . . . . . . . . . . . . . 4 4. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 4 5. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. SDP 'floorctrl' Attribute . . . . . . . . . . . . . . . . 5 5.2. SDP 'confid' Attribute . . . . . . . . . . . . . . . . . 7 5.3. SDP 'userid' Attribute . . . . . . . . . . . . . . . . . 8 5.4. SDP 'floorid' Attribute . . . . . . . . . . . . . . . . . 9 5.5. SDP 'bfcpver' Attribute . . . . . . . . . . . . . . . . . 10 6. Multiplexing Considerations . . . . . . . . . . . . . . . . . 11 7. BFCP Connection Management . . . . . . . . . . . . . . . . . 12 7.1. TCP Connection Management . . . . . . . . . . . . . . . . 12 8. TLS/DTLS Considerations . . . . . . . . . . . . . . . . . . . 13 9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 14 10.1. Generating the Initial SDP Offer . . . . . . . . . . . . 15 10.2. Generating the SDP Answer . . . . . . . . . . . . . . . 15 10.3. Offerer Processing of the SDP Answer . . . . . . . . . . 16 10.4. Modifying the Session . . . . . . . . . . . . . . . . . 17 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13.1. Registration of SDP 'proto' Values . . . . . . . . . . . 20 13.2. Registration of the SDP 'floorctrl' Attribute . . . . . 20 13.3. Registration of the SDP 'confid' Attribute . . . . . . . 20 13.4. Registration of the SDP 'userid' Attribute . . . . . . . 20 13.5. Registration of the SDP 'floorid' Attribute . . . . . . 21 13.6. Registration of the SDP 'bfcpver' Attribute . . . . . . 21 14. Changes from RFC 4583 . . . . . . . . . . . . . . . . . . . . 21 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 16.1. Normative References . . . . . . . . . . . . . . . . . . 22 16.2. Informational References . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Camarillo, et al. Expires June 11, 2019 [Page 2] Internet-Draft BFCP December 2018 1. Introduction As discussed in the BFCP (Binary Floor Control Protocol) specification [I-D.ietf-bfcpbis-rfc4582bis], a given BFCP client needs a set of data in order to establish a BFCP connection to a floor control server. This data includes the transport address of the server, the conference identifier, and the user identifier. One way for clients to obtain this information is to use an SDP offer/answer [RFC3264] exchange. This document specifies how to encode this information in the SDP session descriptions that are part of such an offer/answer exchange. User agents typically use the offer/answer model to establish a number of media streams of different types. Following this model, a BFCP connection is described as any other media stream by using an SDP 'm' line, possibly followed by a number of SDP lines that also apply to the BFCP connection. Section 4 defines how the field values in 'm' line representing a BFCP connection are set. Section 5 defines SDP attributes that are used when negotiating a BFCP connection. Section 6 defines multiplexing considerations for a BFCP connection. Section 7 defines procedures for managing a BFCP connection. Section 8 defines TLS and DTLS considerations when negotiating a BFCP connection. Section 9 defines the Interactive Connectivity Establishment (ICE) [RFC8445] considerations when negotiating a BFCP connection. Section 10 defines the SDP offer/answer procedures for negotiating a BFCP connection. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Camarillo, et al. Expires June 11, 2019 [Page 3] Internet-Draft BFCP December 2018 3. Floor Control Roles When two endpoints establish a BFCP stream, they need to determine which of them acts as a floor control client and which acts as a floor control server. Once the roles have been determined, the roles will apply to all BFCP-controlled streams associated with the BFCP stream. 4. Fields in the 'm' Line According to the SDP specification [RFC4566], the 'm' line format is the following: m= ... This section describes how to generate an 'm' line of an SDP Media Description ('m' section) describing a BFCP stream. The media field MUST have a value of "application". The port field is set depending on the value of the proto field, as explained below. A port field value of zero has the standard SDP meaning (i.e., rejection of the media stream) regardless of the proto field. When TCP is used as the transport, the port field is set following the rules in [RFC4145]. Depending on the value of the 'setup' attribute (discussed in Section 7.1), the port field contains the port to which the remote endpoint will direct BFCP messages, or in the case where the endpoint will initiate the connection towards the remote endpoint, should be set to a value of 9. When UDP is used as the transport, the port field contains the port to which the remote endpoint will direct BFCP messages regardless of the value of the 'setup' attribute. This document defines five values for the proto field: TCP/BFCP, TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP. The proto value are used as described below: 'TCP/BFCP' is used for TCP transport of BFCP without TLS encryption, and is backward compatible with RFC 4583 compliant endpoints. Camarillo, et al. Expires June 11, 2019 [Page 4] Internet-Draft BFCP December 2018 'TCP/TLS/BFCP' is used for TCP transport of BFCP with TLS encryption, and is backward compatible with RFC 4583 compliant endpoints that support TLS. 'UDP/BFCP' is used for UDP transport of BFCP without DTLS encryption [RFC6347]. 'UDP/TLS/BFCP' is used for UDP transport of BFCP with DTLS encryption. This is one of the options when ICE is used (Section 9). It can also be used without ICE when backward compatibility with RFC 4583 compliant endpoints is not required. 'TCP/DTLS/BFCP' is used for TCP transport of BFCP with DTLS encryption, running on top of TCP using the framing method defined in [RFC4571], with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in RFC 4571 such that the length field defined in RFC 4571 precedes each DTLS message. This is one of the options when ICE is used (Section 9). It can also be used without ICE when backward compatibility with RFC 4583 compliant endpoints is not required. The fmt (format) list is not applicable to BFCP. The fmt list of 'm' lines in the case of any proto field value related to BFCP MUST contain a single "*" character. If the the fmt list contains any other value it MUST be ignored. The following is an example of an 'm' line for a BFCP connection: m=application 50000 TCP/TLS/BFCP * 5. SDP Attributes 5.1. SDP 'floorctrl' Attribute This section defines the SDP 'floorctrl' media-level attribute. The attribute is used to determine the floor control roles (client and server) for the endpoints associated with the BFCP stream. Camarillo, et al. Expires June 11, 2019 [Page 5] Internet-Draft BFCP December 2018 Attribute Name: floorctrl Attribute Value: floor-control Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: floor-control = role *(SP role) role = "c-only" / "s-only" / "c-s" An endpoint includes the attribute to indicate the role(s) it would be willing to perform for the BFCP-controlled media streams: c-only: The endpoint is willing to act as floor control client. s-only: The endpoint is willing to act as floor control server only. When inserted in an offer, the offerer MAY indicate multiple attribute values ("c-only" and "s-only"). When inserted in an answer, the answerer MUST indicate only one attribute value: "c-only" or "s-only". The answerer indicates the role taken by the answerer. The offerer will then take the opposite role. In [RFC4583], there was a third attribute specified, "c-s", which meant that an endpoint was willing to act as both floor control client and floor control server at the same time for the BFCP stream, taking different roles for different BFCP-controlled media streams. The feature was underspecified and implemented in different ways, in particular many implementations interpreted "c-s" to mean that the endpoint is willing to act as either client or server (equivalent to "c-only s-only"). An implementation compliant to this specification MUST NOT include the "c-s" floorctl attribute value in an offer or in an answer, but MUST accept the attribute value in an offer and process it as equivalent to "c-only s-only" (or "s-only c-only"). Also, as an implementation compliant to this specification is only allowed to include one role, either 'c-only' or 's-conly', in an answer, each endpoint will only take one role, and as a result the endpoint will take the same role for each BFCP-controlled media stream associated with the BFCP stream. Table 1 shows the roles that the answerer is allowed to take, based on what roles the offerer has indicated that it is willing to take. Camarillo, et al. Expires June 11, 2019 [Page 6] Internet-Draft BFCP December 2018 +---------+----------+ | Offerer | Answerer | +---------+----------+ | c-only | s-only | | s-only | c-only | | c-s | c-only | | c-s | s-only | +---------+----------+ Table 1: Roles Endpoints compliant with [RFC4583] might not include the 'floorctrl' attribute in offers and answerer. If the 'floorctrl' attribute is not present, in order to be interoperable with such endpoints, the offerer will act as floor control client and the answerer will act as floor control server. The SDP Offer/Answer procedures for the 'floorctrl' attribute are defined in Section 10. The following is an example of a 'floorctrl' attribute in an offer: a=floorctrl:c-only s-only 5.2. SDP 'confid' Attribute This section defines the SDP 'confid' media-level attribute. The attribute is used by a floor control server to convey the conference ID value to the floor control client, using decimal integer representation. Camarillo, et al. Expires June 11, 2019 [Page 7] Internet-Draft BFCP December 2018 Attribute Name: confid Attribute Value: conference-id Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: conference-id = 1*DIGIT DIGIT = The maximum value of the attribute is determined by the COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. The SDP Offer/Answer procedures for the 'confid' attribute are defined in Section 10. 5.3. SDP 'userid' Attribute This section defines the SDP userid' media-level attribute. The attribute is used by a floor control server to convey the user ID value to the floor control client, using decimal integer representation. Camarillo, et al. Expires June 11, 2019 [Page 8] Internet-Draft BFCP December 2018 Attribute Name: userid Attribute Value: user-id Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: user-id = 1*DIGIT DIGIT = The maximum value of the attribute is determined by the COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. The SDP Offer/Answer procedures for the 'userid' attribute are defined in Section 10. 5.4. SDP 'floorid' Attribute This section defines the SDP 'floorid' media-level attribute. The attribute conveys a floor identifier, using decimal integer representation, and optionally pointers to one or more BFCP- controlled media streams. Camarillo, et al. Expires June 11, 2019 [Page 9] Internet-Draft BFCP December 2018 Attribute Name: floorid Attribute Value: floor-id Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: floor-id = 1*DIGIT SP "mstrm:" token *(SP token) DIGIT = token = The maximum value of the attribute is determined by the FLOOR-ID format [I-D.ietf-bfcpbis-rfc4582bis]. The floor identifier value is the integer representation of the Floor ID to be used in BFCP. Each media stream pointer value is associated with an SDP 'label' attribute [RFC4574] of a media stream. The SDP Offer/Answer procedures for the 'floorid' attribute are defined in Section 10. Note: In [RFC4583] 'm-stream' was erroneously used in Section 11. Although the example was non-normative, it is implemented by some vendors and occurs in cases where the endpoint is willing to act as a server. Therefore, it is RECOMMENDED to support parsing and interpreting 'm-stream' the same way as 'mstrm' when receiving. 5.5. SDP 'bfcpver' Attribute This section defines the SDP 'bfcpver' media-level attribute. The attribute is used to negotiate the BFCP version, using decimal integer representation. The Augmented BNF syntax [RFC5234] for the attributes is: Camarillo, et al. Expires June 11, 2019 [Page 10] Internet-Draft BFCP December 2018 Attribute Name: bfcpver Attribute Value: bfcp-version Usage Level: media Charset Dependent: No Mux Category: TBD The Augmented BNF syntax [RFC5234] for the attribute is: bfcp-version = version *(SP version) version = 1*DIGIT DIGIT = The maximum value of the attribute is determined by the COMMON-HEADER format [I-D.ietf-bfcpbis-rfc4582bis]. An endpoint uses the 'bfcpver' attribute to convey the version(s) of BFCP supported by the endpoint, using integer values. For a given version, the attribute value representing the version MUST match the "Version" field that would be presented in the BFCP COMMON-HEADER [I-D.ietf-bfcpbis-rfc4582bis]. The BFCP version that will eventually be used will be conveyed with a BFCP-level Hello/HelloAck. Endpoints compliant with [RFC4583] might not always include the 'bfcpver' attribute in offers and answers. The attribute value, if present, MUST be in accordance with the definition of the Version field in [I-D.ietf-bfcpbis-rfc4582bis]. If the attribute is not present, endpoints MUST assume a default value in accordance with [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport the default attribute value is "1", and when used over an unreliable transport the default attribute value is "2". The value is inferred from the transport specified in the 'm' line (Section 4) of the 'm' section associated with the stream. The SDP Offer/Answer procedures for the 'bfcpver' attribute are defined in Section 10. 6. Multiplexing Considerations [I-D.ietf-mmusic-sdp-bundle-negotiation] defines how multiplexing of multiple media streams can be negotiated. This specification does not define how BFCP streams can be multiplexed with other media streams. Therefore, a BFCP stream MUST NOT be associated with a Camarillo, et al. Expires June 11, 2019 [Page 11] Internet-Draft BFCP December 2018 BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation]. Note that BFCP-controlled media streams might be multiplexed with other media streams. [I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for the SDP attributes defined in this specification, except for the 'bfcpver' attribute. Table 2 defines the mux category for the 'bfcpver' attribute: +---------+-------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +---------+-------------------------------------+-------+-----------+ | bfcpver | Needs further analysis in a | M | TBD | | | separate specification | | | +---------+-------------------------------------+-------+-----------+ Table 2: Multiplexing Attribute Analysis 7. BFCP Connection Management BFCP streams can use TCP or UDP as the underlying transport. Endpoints exchanging BFCP messages over UDP send the BFCP messages towards the peer using the connection address and port provided in the SDP 'c' and 'm' lines. TCP connection management is more complicated and is described in the following Section. Note: When using Interactive Connectivity Establishment (ICE) [RFC8445], TCP/DTLS/BFCP, or UDP/TLS/BFCP, the straight-forward procedures for connection management as UDP/BFCP described above apply. TCP/TLS/BFCP follows the same procedures as TCP/BFCP and is described below. 7.1. TCP Connection Management The management of the TCP connection used to transport BFCP messages is performed using the SDP 'setup' and 'connection' attributes [RFC4145]. The 'setup' attribute indicates which of the endpoints initiates the TCP connection. The 'connection' attribute handles TCP connection re-establishment. The BFCP specification [I-D.ietf-bfcpbis-rfc4582bis] describes a number of situations when the TCP connection between a floor control client and the floor control server needs to be re-established. However, that specification does not describe the re-establishment process because this process depends on how the connection was established in the first place. Endpoints using the offer/answer mechanism follow the following rules. Camarillo, et al. Expires June 11, 2019 [Page 12] Internet-Draft BFCP December 2018 When the existing TCP connection is closed and re-established following the rules in [I-D.ietf-bfcpbis-rfc4582bis], the floor control client MUST send an offer towards the floor control server in order to re-establish the connection. If a TCP connection cannot deliver a BFCP message and times out, the endpoint that attempted to send the message (i.e., the one that detected the TCP timeout) MUST send an offer in order to re-establish the TCP connection. Endpoints that use the offer/answer mechanism to negotiate TCP connections MUST support the 'setup' and 'connection' attributes. 8. TLS/DTLS Considerations When DTLS is used with UDP, the generic procedures defined in Section 5 of [I-D.ietf-mmusic-dtls-sdp] MUST be followed. When TLS is used with TCP, once the underlying connection is established, the answerer always acts as the TLS server. If the TCP connection is lost, the active endpoint [RFC4583] is responsible for re-establishing the TCP connection. Unless a new TLS connection is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. Note: For TLS, it was decided to keep the original procedures in [RFC4583] to determine which endpoint acts as the TLS server in order to retain backwards compatibility. 9. ICE Considerations Generic SDP offer/answer procedures for Interactive Connectivity Establishment (ICE) are defined in [I-D.ietf-mmusic-ice-sip-sdp]. When BFCP is used with UDP based ICE candidates [RFC8445] then the procedures for UDP/TLS/BFCP are used. When BFCP is used with TCP based ICE candidates [RFC6544] then the procedures for TCP/DTLS/BFCP are used. Based on the procedures defined in [I-D.ietf-mmusic-dtls-sdp], endpoints treat all ICE candidate pairs associated with a BFCP stream on top of a DTLS association as part of the same DTLS association. Thus, there will only be one BFCP handshake and one DTLS handshake even if there are multiple valid candidate pairs, and if BFCP media is shifted between candidate pairs (including switching between UDP to TCP candidate pairs) prior to nomination. If new candidates are added, they will also be part of the same DTLS association. Camarillo, et al. Expires June 11, 2019 [Page 13] Internet-Draft BFCP December 2018 In order to maximize the likelihood of interoperability between the endpoints, all ICE enabled BFCP-over-DTLS endpoints SHOULD implement support for UDP/TLS/BFCP. When an SDP offer or answer conveys multiple ICE candidates for a BFCP stream, UDP based candidates SHOULD be included and the default candidate SHOULD be chosen from one of those UDP candidates. If UDP transport is used for the default candidate, then the 'm' line proto value MUST be 'UDP/TLS/BFCP'. If TCP transport is used for the default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'. Note: Usage of ICE with protocols other than UDP/TLS/BFCP and TCP/DTLS/BFCP is outside of scope for this specification. 10. SDP Offer/Answer Procedures This section defines the SDP offer/answer [RFC3264] procedures for negotiating and establishing a BFCP stream. Generic procedures for DTLS are defined in [I-D.ietf-mmusic-dtls-sdp]. Generic procedures for TLS are defined in [RFC8122]. This section only defines the BFCP-specific procedures. Unless explicitly stated otherwise, the procedures apply to an 'm' section describing a BFCP stream. If an offer or answer contains multiple 'm' sections describing BFCP streams, the procedures are applied independently to each stream. Within this document, 'initial offer' refers to the first offer, within an SDP session (e.g. a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP) in which the offerer indicates that it wants to negotiate the establishment of a BFCP stream. If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 'UDP/TLS/BFCP', the offerer and answerer follow the generic procedures defined in [RFC8122]. If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP', 'TCP/DTLS/ TCP' or 'UDP/TLS/BFCP', the offerer and answerer use the SDP 'setup' attribute according to the procedures in [RFC4145]. If the 'm' line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 'TCP/DTLS/BFCP', the offerer and anwerer use the SDP 'connection' attribute according to the procedures in [RFC4145]. Note: The use of source-specific SDP parameters [RFC5576] is not defined for BFCP streams. Camarillo, et al. Expires June 11, 2019 [Page 14] Internet-Draft BFCP December 2018 10.1. Generating the Initial SDP Offer When the offerer creates an initial offer, the offerer MUST include an SDP 'floorctrl' attribute (Section 5.1) and an SDP 'bfcpver' attribute (Section 5.5) in the 'm' section. In addition, if the offerer includes an SDP 'floorctrl' attribute with 's-only' or 'c-s' attribute values in the offer, the offerer: o MUST include an SDP 'confid' attribute (Section 5.2) in the 'm' section; and o MUST include an SDP 'userid' attribute (Section 5.3) in the 'm' section; and o MUST include an SDP 'floorid' attribute (Section 5.4) in the 'm' section; and o MUST include an SDP 'label' attribute ([RFC4574]) with the 'm' section of each BFCP-controlled media stream. Note: If the offerer includes an SDP 'floorctrl' attribute with a 'c-s' attribute value, or both a 'c-only' and a 's-only' attribute value in the offer, the attribute values above will only be used if it is determined (Section 5.1) that the offerer will act as floor control server. 10.2. Generating the SDP Answer When the answerer receives an offer that contains an 'm' section describing a BFCP stream, the answerer MUST check whether it supports one or more of the BFCP versions supported by the offerer (Section 5.5). If the answerer does not support any of the BFCP versions, it MUST NOT accept the 'm' section. Otherwise, if the answerer accepts the 'm' section, it: o MUST insert a corresponding 'm' section in the answer, with an identical 'm' line proto value [RFC3264]; and o MUST include a 'bfcpver' attribute in the 'm' section. The versions indicated by the answer MUST be the same or a subset of the versions indicated by the offerer in the corresponding offer; and o MUST, if the offer contained an SDP 'floorctrl' attribute, include a 'floorctrl' attribute in the 'm' section. Camarillo, et al. Expires June 11, 2019 [Page 15] Internet-Draft BFCP December 2018 In addition, if the answerer includes an SDP 'floorctrl' attribute with an 's-only' attribute value in the answer, the answerer: o MUST include an SDP 'confid' attribute in the 'm' section; and o MUST include an SDP 'userid' attribute in the 'm' section; and o MUST include an SDP 'floorid' attribute in the 'm' section; and o MUST include an SDP 'label' attribute in the 'm' section of each BFCP-controlled media stream. Note: An offerer compliant with [RFC4583] might not include 'floorctrl' and 'bfcpver' attributes in offers, in which cases the default values apply. Once the answerer has sent the answer, the answerer: o MUST, if the answerer is the active endpoint, and if a TCP connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TCP connection; and o MUST, if the answerer is the active endpoint, and if an TLS/DTLS connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TLS/DTLS connection (by sending a ClientHello message). If the answerer does not accept the 'm' section in the offer, it MUST assign a zero port value to the 'm' line of the corresponding 'm' section in the answer. In addition, the answerer MUST NOT establish a TCP connection or a TLS/DTLS connection associated with the 'm' section. 10.3. Offerer Processing of the SDP Answer When the offerer receives an answer that contains an 'm' section with a non-zero port value, describing a BFCP stream, the offerer: o MUST, if the offerer is the active endpoint, and if a TCP connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TCP connection; and o MUST, if the offerer is the active endpoint, and if an TLS/DTLS connection associated with the 'm' section is to be established (or re-established), initiate the establishing of the TLS/DTLS connection (by sending a ClientHello message). Camarillo, et al. Expires June 11, 2019 [Page 16] Internet-Draft BFCP December 2018 Note: An answerer compliant with [RFC4583] might not include 'floorctrl' and 'bfcpver' attributes in answers, in which cases the default values apply. If the 'm' line in the answer contains a zero port value, or if the offerer for some other reason does not accept the answer (e.g., if the answerer only indicates support of BFCP versions not supported by the offerer), the offerer MUST NOT establish a TCP connection or a TLS/DTLS connection associated with the 'm' section. 10.4. Modifying the Session When an offerer sends an updated offer, in order to modify a previously established BFCP stream, it follows the procedures in Section 10.1, with the following exceptions: o If the BFCP stream is carried on top of TCP, and if the offerer does not want to re-establish an existing TCP connection, the offerer MUST include an SDP 'connection' attribute with a value of "existing", in the 'm' section; and o If the offerer wants to disable a previously established BFCP stream, it MUST assign a zero port value to the 'm' line associated with the BFCP connection, following the procedures in [RFC3264]. 11. Examples For the purpose of brevity, the main portion of the session description is omitted in the examples, which only show 'm' sections and their 'm' lines and attributes. The following is an example of an offer sent by a conference server to a client. Camarillo, et al. Expires June 11, 2019 [Page 17] Internet-Draft BFCP December 2018 m=application 50000 TCP/TLS/BFCP * a=setup:actpass a=connection:new a=fingerprint:sha-256 \ 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=floorctrl:c-only s-only a=confid:4321 a=userid:1234 a=floorid:1 mstrm:10 a=floorid:2 mstrm:11 a=bfcpver:1 2 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 Note that due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content. The following is the answer returned by the client. m=application 9 TCP/TLS/BFCP * a=setup:active a=connection:new a=fingerprint:sha-256 \ 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=floorctrl:c-only a=bfcpver:1 m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31 A similar example using unreliable transport and DTLS is shown below, where the offer is sent from a client. Camarillo, et al. Expires June 11, 2019 [Page 18] Internet-Draft BFCP December 2018 m=application 50000 UDP/TLS/BFCP * a=setup:actpass a=dtls-id:abc3dl a=fingerprint:sha-256 \ 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: \ BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=floorctrl:c-only s-only a=confid:4321 a=userid:1234 a=floorid:1 mstrm:10 a=floorid:2 mstrm:11 a=bfcpver:1 2 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11 The following is the answer returned by the server. m=application 55000 UDP/TLS/BFCP * a=setup:active a=dtls-id:abc3dl a=fingerprint:sha-256 \ 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: \ DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 mstrm:10 a=floorid:2 mstrm:11 a=bfcpver:2 m=audio 55002 RTP/AVP 0 m=video 55004 RTP/AVP 31 12. Security Considerations The BFCP [I-D.ietf-bfcpbis-rfc4582bis], SDP [RFC4566], and offer/ answer [RFC3264] specifications discuss security issues related to BFCP, SDP, and offer/answer, respectively. In addition, [RFC4145] and [RFC8122] discuss security issues related to the establishment of TCP and TLS connections using an offer/answer model. Furthermore, when using DTLS over UDP, the generic offer/answer considerations defined in [I-D.ietf-mmusic-dtls-sdp] MUST be followed. The usage of certain proto values in the SDP offer/answer negotiation will result in a BFCP stream that is not protected by TLS or DTLS. Operators will need to provide integrity protection and confidentiality protection of the BFCP stream using other means. Camarillo, et al. Expires June 11, 2019 [Page 19] Internet-Draft BFCP December 2018 The generic security considerations associated with SDP attributes are defined in [RFC3264]. While the attributes defined in this specification do not reveal information about the content of individual BFCP controlled media streams, they do reveal which media streams will be BFCP controlled. 13. IANA Considerations [Editorial note: The changes in Section 13.1 instruct the IANA to register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/ BFCP for the SDP 'proto' field. The new section Section 5.5 registers a new SDP "bfcpver" attribute. The rest is unchanged from [RFC4582].] 13.1. Registration of SDP 'proto' Values The IANA is requested to register the following values for the SDP 'proto' field under the Session Description Protocol (SDP) Parameters registry: +---------------+------------+ | Value | Reference | +---------------+------------+ | TCP/BFCP | [RFC XXXX] | | TCP/DTLS/BFCP | [RFC XXXX] | | TCP/TLS/BFCP | [RFC XXXX] | | UDP/BFCP | [RFC XXXX] | | UDP/TLS/BFCP | [RFC XXXX] | +---------------+------------+ Table 3: Values for the SDP 'proto' field 13.2. Registration of the SDP 'floorctrl' Attribute This document defines the SDP attribute,'floorctrl'. The details of the attribute are defined in Section 5.1. 13.3. Registration of the SDP 'confid' Attribute This document defines the SDP attribute,'confid'. The details of the attribute are defined in Section 5.2. 13.4. Registration of the SDP 'userid' Attribute This document defines the SDP attribute,'userid'. The details of the attribute are defined in Section 5.3. Camarillo, et al. Expires June 11, 2019 [Page 20] Internet-Draft BFCP December 2018 13.5. Registration of the SDP 'floorid' Attribute This document defines the SDP attribute,'floorid'. The details of the attribute are defined in Section 5.4. 13.6. Registration of the SDP 'bfcpver' Attribute This document defines the SDP attribute,'bfcpver'. The details of the attribute are defined in Section 5.5. 14. Changes from RFC 4583 Following is the list of technical changes and other fixes from [RFC4583]. Main purpose of this work was to add signaling support necessary to support BFCP over unreliable transport, as described in [I-D.ietf-bfcpbis-rfc4582bis], resulting in the following changes: 1. Fields in the 'm' line (Section 4): The section is re-written to remove reference to the exclusivity of TCP as a transport for BFCP streams. The proto field values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP added. 2. Security Considerations (Section 12): For the DTLS over UDP case, mention existing considerations and requirements for the offer/answer exchange in [I-D.ietf-mmusic-dtls-sdp]. 3. Registration of SDP 'proto' Values (Section 13.1): Register the three new values TCP/DTLS/BFCP, UDP/BFCP and UDP/TLS/BFCP in the SDP parameters registry. 4. BFCP Version Negotiation (Section 5.5): A new 'bfcpver' SDP media-level attribute is added in order to signal supported version number. In addition to the changes associated with support of BFCP over unreliable transport, the possibility for an endpoint to act as both floor control client and floor control server at the same time has been removed. An endpoint will now take the same role for all BFCP- controlled streams associated with the BFCP stream. Clarification and bug fixes: 1. Errata ID: 712 (Section 3 and Section 10): Camarillo, et al. Expires June 11, 2019 [Page 21] Internet-Draft BFCP December 2018 Language clarification. Don't use terms like an SDP attribute is "used in an 'm' line", instead make clear that the attribute is a media-level attribute. 2. Fix typo in example (Section 11): Do not use 'm-stream' in the SDP example, use the correct 'mstrm' as specified in Section 11. Recommend interpreting 'm-stream' if it is received, since it is present in some implementations. 3. Assorted clarifications (Across the document): Language clarifications as a result of reviews. Also, the normative language where tightened where appropriate, i.e. changed from SHOULD strength to MUST in a number of places. 15. Acknowledgements Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and Oscar Novo provided useful ideas for the original [RFC4583]. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from Geir Arne Sandbakken, Charles Eckel, Alan Ford, Eoin McLeod and Mark Thompson. Useful and important final reviews were done by Ali C. Begen, Mary Barnes and Charles Eckel. In the final stages, Roman Shpount made a considerable effort in adding proper ICE support and considerations. 16. References 16.1. Normative References [I-D.ietf-bfcpbis-rfc4582bis] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", draft- ietf-bfcpbis-rfc4582bis-16 (work in progress), November 2015. [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in progress), November 2018. Camarillo, et al. Expires June 11, 2019 [Page 22] Internet-Draft BFCP December 2018 [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, . [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, . [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, DOI 10.17487/RFC4583, November 2006, . Camarillo, et al. Expires June 11, 2019 [Page 23] Internet-Draft BFCP December 2018 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 16.2. Informational References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-53 (work in progress), September 2018. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . Authors' Addresses Camarillo, et al. Expires June 11, 2019 [Page 24] Internet-Draft BFCP December 2018 Gonzalo Camarillo Ericsson Hirsalantie 11 FI-02420 Jorvas Finland Email: Gonzalo.Camarillo@ericsson.com Tom Kristensen Cisco Philip Pedersens vei 1 NO-1366 Lysaker Norway Email: tomkrist@cisco.com, tomkri@ifi.uio.no Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Camarillo, et al. Expires June 11, 2019 [Page 25] ./draft-ietf-ippm-twamp-yang-13.txt0000644000764400076440000041343513316511417016417 0ustar iustyiusty IPPM WG R. Civil Internet-Draft Ciena Corporation Intended status: Standards Track A. Morton Expires: January 3, 2019 AT&T Labs R. Rahman Cisco Systems M. Jethanandani Xoriant Corporation K. Pentikousis, Ed. Travelping July 2, 2018 Two-Way Active Measurement Protocol (TWAMP) Data Model draft-ietf-ippm-twamp-yang-13 Abstract This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). The document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using a NDMA- compliant YANG model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2019. Copyright Notice Copyright (c) 2018 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 Civil, et al. Expires January 3, 2019 [Page 1] Internet-Draft TWAMP YANG Data Model July 2018 (https://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 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Document Organization . . . . . . . . . . . . . . . . . . 4 2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6 3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7 3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 8 4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8 4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8 4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 13 4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 14 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19 6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48 6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48 6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51 6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 57 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 11.1. Normative References . . . . . . . . . . . . . . . . . . 57 11.2. Informative References . . . . . . . . . . . . . . . . . 59 Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60 A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60 A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62 A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64 A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 65 Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Civil, et al. Expires January 3, 2019 [Page 2] Internet-Draft TWAMP YANG Data Model July 2018 1. Introduction The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to measure network performance parameters such as latency, bandwidth, and packet loss by sending probe packets and measuring their experience in the network. To date, TWAMP implementations do not come with a standard management framework, and, as such, implementers have no choice except to provide a proprietary mechanism. This document addresses this gap by defining the model using UML [UML] class diagrams, and formally specifying a NMDA-complaint [RFC8342] TWAMP data model using YANG 1.1 [RFC7950]. 1.1. Motivation In current TWAMP deployments the lack of a standardized data model limits the flexibility to dynamically instantiate TWAMP-based measurements across equipment from different vendors. In large, virtualized, and dynamically instantiated infrastructures where network functions are placed according to orchestration algorithms, proprietary mechanisms for managing TWAMP measurements pose severe limitations with respect to programmability. Two major trends call for standardizing TWAMP management aspects. First, it is expected that in the coming years large-scale and multi- vendor TWAMP deployments will become the norm. From an operations perspective, using several vendor-specific TWAMP configuration mechanisms when one standard mechanism could provide an alternative is expensive and inefficient. Second, the increasingly software- defined and virtualized nature of network infrastructures, based on dynamic service chains [NSC] and programmable control and management planes Software-Defined Networking (SDN): Layers and Architecture Terminology [RFC7426] requires a well-defined data model for TWAMP implementations. This document defines such a TWAMP data model and specifies it formally using the YANG 1.1 [RFC7950] data modeling language. Note to RFC Editor: Please replace the date 2018-07-02 in Section 5.2 of the draft with the date of publication of this draft as a RFC. Also, replace reference to RFC XXXX, and draft-ietf-ippm-port-twamp-test with the RFC numbers assigned to the drafts. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP Civil, et al. Expires January 3, 2019 [Page 3] Internet-Draft TWAMP YANG Data Model July 2018 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Document Organization The rest of this document is organized as follows. Section 2 presents the scope and applicability of this document. Section 3 provides a high-level overview of the TWAMP data model. Section 4 details the configuration parameters of the data model and Section 5 specifies in YANG the TWAMP data model. Section 6 lists illustrative examples which conform to the YANG data model specified in this document. Appendix A elaborates these examples further. 2. Scope, Model, and Applicability The purpose of this document is the specification of a vendor- independent data model for TWAMP implementations. Figure 1 illustrates a redrawn version of the TWAMP logical model found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated with pointers to the UML [UML] diagrams provided in this document and associated with the data model of the four logical entities in a TWAMP deployment, namely the TWAMP Control-Client, Server, Session- Sender and Session-Reflector. A UML [UML] Notation Guide is available in Section 5 of the said document. As per TWAMP [RFC5357], unlabeled links in Figure 1 are left unspecified and may be proprietary protocols. [Fig. 3] [Fig. 4] +----------------+ +--------+ | Control-Client | <-- TWAMP-Control --> | Server | +----------------+ +--------+ ^ ^ | | V V +----------------+ +-------------------+ | Session-Sender | <-- TWAMP-Test --> | Session-Reflector | +----------------+ +-------------------+ [Fig. 5] [Fig. 6] Figure 1: Annotated TWAMP logical model As per TWAMP [RFC5357], a TWAMP implementation may follow a simplified logical model, in which the same node acts both as Control-Client and Session-Sender, while another node acts at the same time as TWAMP Server and Session-Reflector. Figure 2 illustrates this simplified logical model and indicates the Civil, et al. Expires January 3, 2019 [Page 4] Internet-Draft TWAMP YANG Data Model July 2018 interaction between the TWAMP configuration client and server using, for instance, NETCONF [RFC6241] or RESTCONF [RFC8040]. o-------------------o o-------------------o | Config client | | Config client | o-------------------o o-------------------o || || NETCONF || RESTCONF NETCONF || RESTCONF || || o-------------------o o-------------------o | Config server | | Config server | | [Fig. 3, 5] | | [Fig. 4, 6] | +-------------------+ +-------------------+ | Control-Client | <-- TWAMP-Control --> | Server | | | | | | Session-Sender | <-- TWAMP-Test --> | Session-Reflector | +-------------------+ +-------------------+ Figure 2: Simplified TWAMP model and protocols The data model defined in this document is orthogonal to the specific protocol used between the Config client and Config server to communicate the TWAMP configuration parameters. Operational actions such as how TWAMP-Test sessions are started and stopped, how performance measurement results are retrieved, or how stored results are cleared, and so on, are not addressed by the configuration model defined in this document. As noted above, such operational actions are not part of the TWAMP specification TWAMP [RFC5357] and hence are out of scope of this document. See also Appendix B. In addition, for operational state, current work in Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], can be used to develop an independent model for the performance metrics that need to be captured and retrieved. 3. Data Model Overview The TWAMP data model includes four categories of configuration items. First, global configuration items relate to parameters that are set on a per device level. For example, the administrative status of the device with respect to whether it allows TWAMP sessions and, if so, in what capacity (e.g. Control-Client, Server or both), is a typical instance of a global configuration item. A second category includes attributes that can be configured on a per TWAMP-Control connection basis, such as the Server IP address. Civil, et al. Expires January 3, 2019 [Page 5] Internet-Draft TWAMP YANG Data Model July 2018 A third category includes attributes related to per TWAMP-Test session attributes, for instance setting different values in the Differentiated Services Code Point (DSCP) field. Finally, the data model includes attributes that relate to the operational state of the TWAMP implementation. As the TWAMP data model is described in the remaining sections of this document, readers should keep in mind the functional entity grouping illustrated in Figure 1. 3.1. Control-Client A TWAMP Control-Client has an administrative status field set at the device level that indicates whether the node is enabled to function as such. Each TWAMP Control-Client is associated with zero or more TWAMP- Control connections. The main configuration parameters of each control connection are: o A name which can be used to uniquely identify at the Control- Client a particular control connection. This name is necessary for programmability reasons because at the time of creation of a TWAMP-Control connection not all IP and TCP port number information needed to uniquely identify the connection is available. o The IP address of the interface the Control-Client will use for connections. o The IP address of the remote TWAMP Server. o Authentication and encryption attributes such as KeyID, Token and the Client Initialization Vector (Client-IV); see also Section 3.1 in OWAMP [RFC4656] and Randomness Requirements for Security [RFC4086]. Each TWAMP-Control connection, in turn, is associated with zero or more TWAMP-Test sessions. For each test session, the following configuration items should be noted: o The test session name uniquely identifies a particular test session at the Control-Client and Session-Sender. Similar to the control connections above, this unique test session name is needed because at the time of creation of a TWAMP-Test session, for example, the source UDP port number is not known to uniquely identify the test session. Civil, et al. Expires January 3, 2019 [Page 6] Internet-Draft TWAMP YANG Data Model July 2018 o The IP address and UDP port number of the Session-Sender on the path under test by TWAMP. o The IP address and UDP port number of the Session-Reflector on said path. o Information pertaining to the test packet stream, such as the test starting time, which performance metric is to be used, as defined in Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], or whether the test should be repeated. 3.2. Server Each TWAMP Server has an administrative status field set at the device level to indicate whether the node is enabled to function as a TWAMP Server. Each Server is associated with zero or more TWAMP-Control connections. Each control connection is uniquely identified by the 4-tuple {Control-Client IP address, Control-Client TCP port number, Server IP address, Server TCP port}. Control connection configuration items on a TWAMP Server are read-only. 3.3. Session-Sender A TWAMP Session-Sender has an administrative status field set at the device level that indicates whether the node is enabled to function as such. There is one Session-Sender instance for each TWAMP-Test session that is initiated from the sending device. Primary configuration fields include: o The test session name MUST be identical to the corresponding test session name on the TWAMP Control-Client (Section 3.1). o The control connection name, which along with the test session name uniquely identify the TWAMP Session-Sender instance. o Information pertaining to the test packet stream, such as, the number of test packets and the packet distribution to be employed; see also Network performance measurement with periodic streams [RFC3432]. Civil, et al. Expires January 3, 2019 [Page 7] Internet-Draft TWAMP YANG Data Model July 2018 3.4. Session-Reflector Each TWAMP Session-Reflector has an administrative status field set at the device level to indicate whether the node is enabled to function as such. Each Session-Reflector is associated with zero or more TWAMP-Test sessions. For each test session, the REFWAIT timeout parameter, which determines whether to discontinue the session if no packets have been received (TWAMP [RFC5357], Section 4.2), can be configured. Read-only access to other data model parameters, such as the Sender IP address, is foreseen. Each test session can be uniquely identified by the 4-tuple mentioned in Section 3.2. 4. Data Model Parameters This section defines the TWAMP data model using UML [UML] and introduces selected parameters associated with the four TWAMP logical entities. The complete TWAMP data model specification is provided in the YANG module presented in Section 5.2. 4.1. Control-Client The client container (see Figure 3) holds items that are related to the configuration of the TWAMP Control-Client logical entity (recall Figure 1). The client container includes an administrative configuration parameter (client/admin-state) that indicates whether the device is allowed to initiate TWAMP-Control connections. Civil, et al. Expires January 3, 2019 [Page 8] Internet-Draft TWAMP YANG Data Model July 2018 +-------------+ | client | +-------------+ 1..* +-----------------------+ | admin-state |<>----------------------| mode-preference-chain | | | +-----------------------+ | | 1..* +------------+ | priority | | |<>-----| key-chain | | mode | +-------------+ +------------+ +-----------------------+ ^ | key-id | V | secret-key | | +------------+ | 0..* +------------------------+ | ctrl-connection | +------------------------+ | name | | client-ip | | server-ip | | server-tcp-port | 0..* +----------------------+ | control-packet-dscp |<>-------| test-session-request | | key-id | +----------------------+ | max-count | | name | | client-tcp-port {ro} | | sender-ip | | server-start-time {ro} | | sender-udp-port | | state {ro} | | reflector-ip | | selected-mode {ro} | | reflector-udp-port | | token {ro} | | timeout | | client-iv {ro} | | padding-length | +------------------------+ | test-packet-dscp | | start-time | +-------------+ 1 | repeat | | pm-reg-list |------<>| repeat-interval | +-------------+ | state {ro} | | pm-index | | sid {ro} | +-------------+ +----------------------+ Figure 3: TWAMP Control-Client UML class diagram The client container holds a list (mode-preference-chain) which specifies the Mode values according to their preferred order of use by the operator of this Control-Client, including the authentication and encryption Modes. Specifically, mode-preference-chain lists the mode and its corresponding priority, as a 16-bit unsigned integer. Values for the priority start with zero, the highest priority, and decreasing priority value is indicated by every increase in value by one. Civil, et al. Expires January 3, 2019 [Page 9] Internet-Draft TWAMP YANG Data Model July 2018 Depending on the Modes available in the Server Greeting, the Control- Client MUST choose the highest priority Mode from the configured mode-preference-chain list. Note that the list of preferred Modes may set multiple bit positions independently, such as when referring to the extended TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot determine an acceptable Mode, or when the bit combinations do not make sense, e.g., both authenticated and unauthenticated bit are set, it MUST respond with zero Mode bits set in the Set-up Response message, indicating it will not continue with the control connection. In addition, the client container holds a list named key-chain which relates key-id with the respective secret-key. Both the Server and the Control-Client use the same mappings from key-id to secret-key (in Figure 3); in order for this to work properly, key-id must be unique across all systems in the administrative domain. The Server, being prepared to conduct sessions with more than one Control-Client, uses key-id to choose the appropriate secret-key; a Control-Client would typically have different secret keys for different Servers. The secret-key is the shared secret, of type binary and the length SHOULD contain at least 128 bits of entropy. The key-id and secret- key encoding SHOULD follow Section 9.8 of YANG [RFC7950]. The derived key length (dkLen in PKCS #5: Password-Based Cryptography Specification Version 2.1 [RFC8018]) MUST be 16 octets for the AES Session-key used for encryption and 32 octets for the HMAC-SHA1 Session-key used for authentication; see also Section 6.10 of OWAMP [RFC4656]. Each client container also holds a list of control connections, where each item in the list describes a TWAMP control connection initiated by this Control-Client. There SHALL be one ctrl-connection per TWAMP-Control (TCP) connection that is to be initiated from this device. In turn, each ctrl-connection holds a test-session-request list. Each test-session-request holds information associated with the Control-Client for this test session. This includes information associated with the Request-TW-Session/Accept-Session message exchange (see Section 3.5 of TWAMP [RFC5357]). There SHALL be one instance of test-session-request for each TWAMP- Test session that is to be negotiated by this TWAMP-Control connection via a Request-TW-Session/Accept-Session exchange. Civil, et al. Expires January 3, 2019 [Page 10] Internet-Draft TWAMP YANG Data Model July 2018 The Control-Client is also responsible for scheduling TWAMP-Test sessions, therefore test-session-request holds information related to these actions (e.g. pm-index, repeat-interval). 4.2. Server The server container (see Figure 4) holds items that are related to the configuration of the TWAMP Server logical entity (recall Figure 1). The server container includes an administrative configuration parameter (server/admin-state) that indicates whether the device is allowed to receive TWAMP-Control connections. A device operating in the Server role cannot configure attributes on a per TWAMP-Control connection basis, as it has no foreknowledge of the incoming TWAMP-Control connections to be received. Consequently, any parameter that the Server might want to apply to an incoming control connection must be configured at the overall Server level and applied to all incoming TWAMP-Control connections. Civil, et al. Expires January 3, 2019 [Page 11] Internet-Draft TWAMP YANG Data Model July 2018 +---------------------+ | server | +---------------------+ | admin-state | 1..* +------------+ | server-tcp-port |<>------| key-chain | | servwait | +------------+ | control-packet-dscp | | key-id | | count | | secret-key | | max-count | +------------+ | modes | | | 0..* +--------------------------+ | |<>------| ctrl-connection | +---------------------+ +--------------------------+ | client-ip {ro} | | client-tcp-port {ro} | | server-ip {ro} | | server-tcp-port {ro} | | state {ro} | | control-packet-dscp {ro} | | selected-mode {ro} | | key-id {ro} | | count {ro} | | max-count {ro} | | salt {ro} | | server-iv {ro} | | challenge {ro} | +--------------------------+ Figure 4: TWAMP Server UML class diagram Each server container holds a list named key-chain which relates key- id with the respective secret-key. As mentioned in Section 4.1, both the Server and the Control-Client use the same mapping from key-id to shared secret-key; in order for this to work properly, key-id must be unique across all the systems in the administrative domain. The Server, being prepared to conduct sessions with more than one Control-Client, uses key-id to choose the appropriate secret-key; a Control-Client would typically have different secret keys for different Servers. The key-id tells the Server which shared secret- key the Control-Client wishes to use for authentication or encryption. Each incoming control connection active on the Server is represented by a ctrl-connection. There SHALL be one ctrl-connection per incoming TWAMP-Control (TCP) connection that is received and active on the Server. Each ctrl-connection can be uniquely identified by the 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port}. All items in the ctrl-connection list are read-only. Civil, et al. Expires January 3, 2019 [Page 12] Internet-Draft TWAMP YANG Data Model July 2018 4.3. Session-Sender The session-sender container, illustrated in Figure 5, holds items that are related to the configuration of the TWAMP Session-Sender logical entity. The session-sender container includes an administrative parameter (session-sender/admin-state) that controls whether the device is allowed to initiate TWAMP-Test sessions. +----------------+ | session-sender | +----------------+ 0..* +---------------------------+ | admin-state |<>-----| test-session | +----------------+ +---------------------------+ | name | | ctrl-connection-name {ro} | | fill-mode | | number-of-packets | | state {ro} | | sent-packets {ro} | | rcv-packets {ro} | | last-sent-seq {ro} | | last-rcv-seq {ro} | +---------------------------+ ^ V | 1 +---------------------+ | packet-distribution | +---------------------+ | periodic / poisson | +---------------------+ | | +-------------------+ | | periodic-interval | | +-------------------+ | | +--------------+ | lambda | | max-interval | +--------------+ Figure 5: TWAMP Session-Sender UML class diagram Each TWAMP-Test session initiated by the Session-Sender will be represented by an instance of a test-session object. There SHALL be Civil, et al. Expires January 3, 2019 [Page 13] Internet-Draft TWAMP YANG Data Model July 2018 one instance of test-session for each TWAMP-Test session for which packets are being sent. 4.4. Session-Reflector The session-reflector container, illustrated in Figure 6, holds items that are related to the configuration of the TWAMP Session-Reflector logical entity. The session-reflector container includes an administrative parameter (session-reflector/admin-state) that controls whether the device is allowed to respond to incoming TWAMP-Test sessions. A device operating in the Session-Reflector role cannot configure attributes on a per-session basis, as it has no foreknowledge of what incoming sessions it will receive. As such, any parameter that the Session-Reflector might want to apply to an incoming TWAMP-Test session must be configured at the overall Session-Reflector level and are applied to all incoming sessions. Civil, et al. Expires January 3, 2019 [Page 14] Internet-Draft TWAMP YANG Data Model July 2018 +-------------------+ | session-reflector | +-------------------+ | admin-state | | refwait | +-------------------+ ^ V | | 0..* +----------------------------------------+ | test-session | +----------------------------------------+ | sid {ro} | | sender-ip {ro} | | sender-udp-port {ro} | | reflector-ip {ro} | | reflector-udp-port {ro} | | parent-connection-client-ip {ro} | | parent-connection-client-tcp-port {ro} | | parent-connection-server-ip {ro} | | parent-connection-server-tcp-port {ro} | | test-packet-dscp {ro} | | sent-packets {ro} | | rcv-packets {ro} | | last-sent-seq {ro} | | last-rcv-seq {ro} | +----------------------------------------+ Figure 6: TWAMP Session-Reflector UML class diagram Each incoming TWAMP-Test session that is active on the Session- Reflector SHALL be represented by an instance of a test-session object. All items in the test-session object are read-only. Instances of test-session are indexed by a session identifier (sid). This value is auto-allocated by the TWAMP Server as test session requests are received, and communicated back to the Control-Client in the SID field of the Accept-Session message; see Section 4.3 of TWAMP Reflect Octets and Symmetrical Size Features [RFC6038]. When attempting to retrieve operational data for active test sessions from a Session-Reflector device, the user will not know what sessions are currently active on that device, or what SIDs have been auto- allocated for these test sessions. If the user has network access to the Control-Client device, then it is possible to read the data for this session under client/ctrl-connection/test-session-request/sid and obtain the SID (see Figure 3). The user may then use this SID Civil, et al. Expires January 3, 2019 [Page 15] Internet-Draft TWAMP YANG Data Model July 2018 value as an index to retrieve an individual session-reflector/test- session instance on the Session-Reflector device. If the user has no network access to the Control-Client device, then the only option is to retrieve all test-session instances from the Session-Reflector device, and then pick out specific test-session instances of interest to the user. This could be problematic if a large number of test sessions are currently active on that device. Each Session-Reflector TWAMP-Test session contains the following 4-tuple: {parent-connection-client-ip, parent-connection-client-tcp- port, parent-connection-server-ip, parent-connection-server-tcp- port}. This 4-tuple MUST correspond to the equivalent 4-tuple {client-ip, client-tcp-port, server-ip, server-tcp-port} in server/ ctrl-connection. This 4-tuple allows the user to trace back from the TWAMP-Test session to the (parent) TWAMP-Control connection that negotiated this test session. 5. Data Model This section formally specifies the TWAMP data model using YANG. 5.1. YANG Tree Diagram This section presents a simplified graphical representation of the TWAMP data model using a YANG tree diagram. Readers should keep in mind that the limit of 72 characters per line forces us to introduce artificial line breaks in some tree diagram nodes. Tree diagrams used in this document follow the notation defined in YANG Tree Diagrams [RFC8340]. module: ietf-twamp +--rw twamp +--rw client {control-client}? | +--rw admin-state? boolean | +--rw mode-preference-chain* [priority] | | +--rw priority uint16 | | +--rw mode? twamp-modes | +--rw key-chain* [key-id] | | +--rw key-id string | | +--rw secret-key? binary | +--rw ctrl-connection* [name] | +--rw name string | +--rw client-ip? inet:ip-address | +--rw server-ip inet:ip-address | +--rw server-tcp-port? inet:port-number | +--rw control-packet-dscp? inet:dscp | +--rw key-id? string Civil, et al. Expires January 3, 2019 [Page 16] Internet-Draft TWAMP YANG Data Model July 2018 | +--rw max-count-exponent? uint8 | +--ro client-tcp-port? inet:port-number | +--ro server-start-time? uint64 | +--ro repeat-count? uint64 | +--ro state? | | control-client-connection-state | +--ro selected-mode? twamp-modes | +--ro token? binary | +--ro client-iv? binary | +--rw test-session-request* [name] | +--rw name string | +--rw sender-ip? inet:ip-address | +--rw sender-udp-port? union | +--rw reflector-ip inet:ip-address | +--rw reflector-udp-port? inet:port-number | +--rw timeout? uint64 | +--rw padding-length? uint32 | +--rw test-packet-dscp? inet:dscp | +--rw start-time? uint64 | +--rw repeat? uint32 | +--rw repeat-interval? uint32 | +--rw pm-reg-list* [pm-index] | | +--rw pm-index uint16 | +--ro state? test-session-state | +--ro sid? string +--rw server {server}? | +--rw admin-state? boolean | +--rw server-tcp-port? inet:port-number | +--rw servwait? uint32 | +--rw control-packet-dscp? inet:dscp | +--rw count? uint8 | +--rw max-count-exponent? uint8 | +--rw modes? twamp-modes | +--rw key-chain* [key-id] | | +--rw key-id string | | +--rw secret-key? binary | +--ro ctrl-connection* | [client-ip client-tcp-port server-ip server-tcp-port] | +--ro client-ip inet:ip-address | +--ro client-tcp-port inet:port-number | +--ro server-ip inet:ip-address | +--ro server-tcp-port inet:port-number | +--ro state? server-ctrl-connection-state | +--ro control-packet-dscp? inet:dscp | +--ro selected-mode? twamp-modes | +--ro key-id? string | +--ro count? uint8 | +--ro max-count-exponent? uint8 Civil, et al. Expires January 3, 2019 [Page 17] Internet-Draft TWAMP YANG Data Model July 2018 | +--ro salt? binary | +--ro server-iv? binary | +--ro challenge? binary +--rw session-sender {session-sender}? | +--rw admin-state? boolean | +--rw test-session* [name] | +--rw name string | +--ro ctrl-connection-name? string | +--rw fill-mode? padding-fill-mode | +--rw number-of-packets uint32 | +--rw (packet-distribution)? | | +--:(periodic) | | | +--rw periodic-interval decimal64 | | +--:(poisson) | | +--rw lambda decimal64 | | +--rw max-interval? decimal64 | +--ro state? sender-session-state | +--ro sent-packets? uint32 | +--ro rcv-packets? uint32 | +--ro last-sent-seq? uint32 | +--ro last-rcv-seq? uint32 +--rw session-reflector {session-reflector}? +--rw admin-state? boolean +--rw refwait? uint32 +--ro test-session* [sender-ip sender-udp-port reflector-ip reflector-udp -port] +--ro sid? string +--ro sender-ip inet:ip-address +--ro sender-udp-port | dynamic-port-number +--ro reflector-ip inet:ip-address +--ro reflector-udp-port inet:port-numbe r +--ro parent-connection-client-ip? inet:ip-address +--ro parent-connection-client-tcp-port? inet:port-numbe r +--ro parent-connection-server-ip? inet:ip-address +--ro parent-connection-server-tcp-port? inet:port-numbe r +--ro test-packet-dscp? inet:dscp +--ro sent-packets? uint32 +--ro rcv-packets? uint32 +--ro last-sent-seq? uint32 +--ro last-rcv-seq? uint32 Figure 7: YANG Tree Diagram. Civil, et al. Expires January 3, 2019 [Page 18] Internet-Draft TWAMP YANG Data Model July 2018 5.2. YANG Module This section presents the YANG module for the TWAMP data model defined in this document. The module imports definitions from Common YANG Data Types [RFC6991], and references NTPv4 Specification [RFC5905], Framework for IP Performance Metrics [RFC2330], Randomness Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP [RFC5357], More Features for TWAMP [RFC5618], Individual Session Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size Features [RFC6038], Advances Stream and Sampling Framework [RFC7312], IKEv2-Derived Shared Secret Key for OWAMP and TWAMP [RFC7717], and OWAMP and TWAMP Well-Known Port Assignments [I-D.ietf-ippm-port-twamp-test]. file "ietf-twamp@2018-07-02.yang" module ietf-twamp { yang-version 1.1; namespace urn:ietf:params:xml:ns:yang:ietf-twamp; prefix ietf-twamp; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Types."; } organization "IETF IPPM (IP Performance Metrics) Working Group"; contact "WG Web: http://tools.ietf.org/wg/ippm/ WG List: ippm@ietf.org Editor: Ruth Civil gcivil@ciena.com Editor: Al Morton acmorton@att.com Editor: Reshad Rehman rrahman@cisco.com Editor: Mahesh Jethanandani mjethanandani@gmail.com Editor: Kostas Pentikousis k.pentikousis@travelping.com"; description "This YANG module specifies a vendor-independent data Civil, et al. Expires January 3, 2019 [Page 19] Internet-Draft TWAMP YANG Data Model July 2018 model for the Two-Way Active Measurement Protocol (TWAMP). The data model covers four TWAMP logical entities, namely, Control-Client, Server, Session-Sender, and Session-Reflector, as illustrated in the annotated TWAMP logical model (Fig. 1 of RFC XXXX). This YANG module uses features to indicate which of the four logical entities are supported by a TWAMP implementation. Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-07-02 { description "Initial Revision. Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and draft-ietf-ippm-metric-registry"; reference "RFC XXXX: TWAMP YANG Data Model."; } /* * Typedefs */ typedef twamp-modes { type bits { bit unauthenticated { position 0; description "Unauthenticated mode, in which no encryption or authentication is applied in TWAMP-Control and TWAMP-Test. KeyID, Token, and Client-IV are not used in the Set-Up-Response message. See Section 3.1 of RFC 4656."; Civil, et al. Expires January 3, 2019 [Page 20] Internet-Draft TWAMP YANG Data Model July 2018 reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; } bit authenticated { position 1; description "Authenticated mode, in which the Control-Client and Server possess a shared secret thus prohibiting 'theft of service'. As per Section 6 of RFC 4656, in 'authenticated mode, the timestamp is in the clear and is not protected cryptographically in any way, while the rest of the message has the same protection as in encrypted mode. This mode allows one to trade off cryptographic protection against accuracy of timestamps.'"; reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; } bit encrypted { position 2; description "Encrypted mode 'makes it impossible to alter timestamps undetectably' [Section 6 of RFC 4656]. See also Section 4 of RFC 7717."; reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP)"; } bit unauth-test-encrpyt-control { position 3; description "When using the Mixed Security Mode, the TWAMP-Test protocol follows the Unauthenticated mode and the TWAMP-Control protocol the Encrypted mode."; reference "RFC 5618: Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)"; } bit individual-session-control { position 4; description "This mode enables individual test sessions using Session Identifiers."; reference "RFC 5938: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)"; Civil, et al. Expires January 3, 2019 [Page 21] Internet-Draft TWAMP YANG Data Model July 2018 } bit reflect-octets { position 5; description "This mode indicates the reflect octets capability."; reference "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features"; } bit symmetrical-size { position 6; description "This mode indicates support for the symmetrical size sender test packet format."; reference "RFC 6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features"; } bit IKEv2Derived { position 7; description "In this mode the the shared key is derived from an IKEv2 security association (SA)."; reference "RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"; } } description "Specifies the configurable TWAMP-Modes supported during a TWAMP-Control Connection setup between a Control-Client and a Server. Section 7 of RFC 7717 summarizes the TWAMP-Modes registry and points to their formal specification."; } typedef control-client-connection-state { type enumeration { enum active { description "Indicates an active TWAMP-Control connection to Server."; } enum idle { description "Indicates an idle TWAMP-Control connection to Server."; } Civil, et al. Expires January 3, 2019 [Page 22] Internet-Draft TWAMP YANG Data Model July 2018 } description "Indicates the Control-Client TWAMP-Control connection state."; } typedef test-session-state { type enumeration { enum accepted { value 0; description "Indicates an accepted TWAMP-Test session request."; } enum failed { value 1; description "Indicates a TWAMP-Test session failure due to some unspecified reason (catch-all)."; } enum internal-error { value 2; description "Indicates a TWAMP-Test session failure due to an internal error."; } enum not-supported { value 3; description "Indicates a TWAMP-Test session failure because some aspect of the TWAMP-Test session request is not supported."; } enum permanent-resource-limit { value 4; description "Indicates a TWAMP-Test session failure due to permanent resource limitations."; } enum temp-resource-limit { value 5; description "Indicates a TWAMP-Test session failure due to temporary resource limitations."; } } description "Indicates the Control-Client TWAMP-Test session state."; } Civil, et al. Expires January 3, 2019 [Page 23] Internet-Draft TWAMP YANG Data Model July 2018 typedef server-ctrl-connection-state { type enumeration { enum active { description "Indicates an active TWAMP-Control connection to the Control-Client."; } enum servwait { description "Indicates that the TWAMP-Control connection to the Control-Client is in SERVWAIT as per the definition of Section 3.1 of RFC 5357."; } } description "Indicates the Server TWAMP-Control connection state."; } typedef sender-session-state { type enumeration { enum active { description "Indicates that the TWAMP-Test session is active."; } enum failure { description "Indicates that the TWAMP-Test session has failed."; } } description "Indicates the Session-Sender TWAMP-Test session state."; } typedef padding-fill-mode { type enumeration { enum zero { description "TWAMP-Test packets are padded with all zeros."; } enum random { description "TWAMP-Test packets are padded with pseudo-random numbers."; } } description "Indicates what type of packet padding is used in the TWAMP-Test packets."; Civil, et al. Expires January 3, 2019 [Page 24] Internet-Draft TWAMP YANG Data Model July 2018 } typedef dynamic-port-number { type inet:port-number { range 49152..65535; } description "Dynamic range for port numbers."; } /* * Features */ feature control-client { description "Indicates that the device supports configuration of the TWAMP Control-Client logical entity."; } feature server { description "Indicates that the device supports configuration of the TWAMP Server logical entity."; } feature session-sender { description "Indicates that the device supports configuration of the TWAMP Session-Sender logical entity."; } feature session-reflector { description "Indicates that the device supports configuration of the TWAMP Session-Reflector logical entity."; } /* * Reusable node groups */ grouping key-management { list key-chain { key key-id; leaf key-id { type string { length 1..80; Civil, et al. Expires January 3, 2019 [Page 25] Internet-Draft TWAMP YANG Data Model July 2018 } description "KeyID used for a TWAMP-Control connection. As per Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to 80 octets in length' and is used to select which 'shared shared secret the [Control-Client] wishes to use to authenticate or encrypt'."; } leaf secret-key { type binary; description "The secret key corresponding to the KeyID for this TWAMP-Control connection."; } description "Relates KeyIDs with their respective secret keys in a TWAMP-Control connection."; } description "Used by the Control-Client and Server for TWAMP-Control key management."; } grouping maintenance-statistics { leaf sent-packets { type uint32; config false; description "Indicates the number of packets sent."; } leaf rcv-packets { type uint32; config false; description "Indicates the number of packets received."; } leaf last-sent-seq { type uint32; config false; description "Indicates the last sent sequence number."; } leaf last-rcv-seq { type uint32; config false; Civil, et al. Expires January 3, 2019 [Page 26] Internet-Draft TWAMP YANG Data Model July 2018 description "Indicates the last received sequence number."; } description "Used for TWAMP-Test maintenance statistics."; } grouping count { leaf count { type uint8 { range "10..31"; } default 15; description "Parameter communicated to the Control-Client as part of the Server Greeting message and used for deriving a key from a shared secret as per Section 3.1 of RFC 4656: MUST be a power of 2 and at least 1024. It is configured by providing said power. For example, configuring 20 here means count 2^20 = 1048576. The default is 15, meaning 2^15 = 32768."; } description "Reusable data structure for count, which is used both in the Server and the Control-Client."; } grouping max-count-exponent { leaf max-count-exponent { type uint8 { range 10..31; } default 20; description "This parameter limits the maximum Count value, which MUST be a power of 2 and at least 1024 as per RFC 5357. It is configured by providing said power. For example, configuring 10 here means max count 2^10 = 1024. The default is 20, meaning 2^20 = 1048576. A TWAMP Server uses this configured value in the Server-Greeting message sent to the Control-Client. A TWAMP Control-Client uses this configured value to prevent denial-of-service (DOS) attacks by closing the control connection to the Server if it 'receives a Server-Greeting message with Count greater that its maximum configured value', as per Section 6 of RFC 5357. Civil, et al. Expires January 3, 2019 [Page 27] Internet-Draft TWAMP YANG Data Model July 2018 Further, note that according to Section 6 of RFC 5357: 'If an attacking system sets the maximum value in Count (2**32), then the system under attack would stall for a significant period of time while it attempts to generate keys. TWAMP-compliant systems SHOULD have a configuration control to limit the maximum count value. The default max-count-exponent value SHOULD be 15 which corresponds to a maximum value of 2**15 or 32768.' RFC 5357 does not qualify 'significant period' in terms of time, but it is clear that this depends on the processing capacity available and operators need to pay attention to this security consideration."; } description "Reusable data structure for max-count which is used both at the Control-Client and the Server containers."; } /* * Configuration data nodes */ container twamp { description "TWAMP logical entity configuration grouping of four models which correspond to the four TWAMP logical entities Control-Client, Server, Session-Sender, and Session-Reflector as illustrated in Fig. 1 of RFC XXXX."; container client { if-feature control-client; description "Configuration of the TWAMP Control-Client logical entity."; leaf admin-state { type boolean; default true; description "Indicates whether the device is allowed to operate as a TWAMP Control-Client."; } Civil, et al. Expires January 3, 2019 [Page 28] Internet-Draft TWAMP YANG Data Model July 2018 list mode-preference-chain { key priority; unique mode; leaf priority { type uint16; description "Indicates the Control-Client Mode preference priority expressed as a 16-bit unsigned integer. Values for the priority start with zero, the highest priority, and decreasing priority value is indicated by every increase in value by one."; } leaf mode { type twamp-modes; description "The supported TWAMP Mode matching the corresponding priority."; } description "Indicates the Control-Client preferred order of use of the supported TWAMP Modes. Depending on the Modes available in the TWAMP Server Greeting message (see Fig. 2 of RFC 7717), the Control-Client MUST choose the highest priority Mode from the configured mode-preference-chain list."; } uses key-management; list ctrl-connection { key name; description "List of TWAMP Control-Client control connections. Each item in the list describes a control connection that will be initiated by this Control-Client"; leaf name { type string; description "A unique name used as a key to identify this individual TWAMP-Control connection on the Control-Client device."; } leaf client-ip { type inet:ip-address; description Civil, et al. Expires January 3, 2019 [Page 29] Internet-Draft TWAMP YANG Data Model July 2018 "The IP address of the local Control-Client device, to be placed in the source IP address field of the IP header in TWAMP-Control (TCP) packets belonging to this control connection. If not configured, the device SHALL choose its own source IP address."; } leaf server-ip { type inet:ip-address; mandatory true; description "The IP address of the remote Server device, which the TWAMP-Control connection will be initiated to."; } leaf server-tcp-port { type inet:port-number; default 862; description "This parameter defines the TCP port number that is to be used by this outgoing TWAMP-Control connection. Typically, this is the well-known TWAMP-Control port number (862) as per RFC 5357 However, there are known realizations of TWAMP in the field that were implemented before this well-known port number was allocated. These early implementations allowed the port number to be configured. This parameter is therefore provided for backward compatibility reasons."; } leaf control-packet-dscp { type inet:dscp; default 0; description "The DSCP value to be placed in the IP header of TWAMP-Control (TCP) packets generated by this Control-Client."; } leaf key-id { type string { length 1..80; } description "Indicates the KeyID value selected for this TWAMP-Control connection."; } Civil, et al. Expires January 3, 2019 [Page 30] Internet-Draft TWAMP YANG Data Model July 2018 uses max-count-exponent; leaf client-tcp-port { type inet:port-number; config false; description "Indicates the source TCP port number used in the TWAMP-Control packets belonging to this control connection."; } leaf server-start-time { type uint64; config false; description "Indicates the Start-Time advertised by the Server in the Server-Start message (RFC 4656, Section 3.1), representing the time when the current instantiation of the Server started operating. The timestamp format follows RFC 5905 according to Section 4.1.2 of RFC 4656."; reference "RFC 4656: OWAMP, Section 3.1 and 4.1.2, RFC 5905: NTPv4 Specification."; } leaf repeat-count { type uint64; config false; description "Indicates how many times the test session has been repeated. When a test is running, this value will be greater than 0. If the repeat parameter is non-zero, this value is smaller than or equal to the repeat parameter."; } leaf state { type control-client-connection-state; config false; description "Indicates the current state of the TWAMP-Control connection state."; } leaf selected-mode { type twamp-modes; config false; description Civil, et al. Expires January 3, 2019 [Page 31] Internet-Draft TWAMP YANG Data Model July 2018 "The TWAMP Mode that the Control-Client has chosen for this control connection as set in the Mode field of the Set-Up-Response message"; reference "RFC 4656, Section 3.1."; } leaf token { type binary { length 64; } config false; description "This parameter holds the 64 octets containing the concatenation of a 16-octet Challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication; see also the last paragraph of Section 6 in RFC 4656. If the Mode defined in RFC 7717 is selected (selected-mode), Token is limited to 16 octets."; reference "RFC 4086: Randomness Requirements for Security RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"; } leaf client-iv { type binary { length 16; } config false; description "Indicates the Control-Client Initialization Vector (Client-IV), that is generated randomly by the Control-Client. As per RFC 4656: Client-IV merely needs to be unique (i.e., it MUST never be repeated for different sessions using the same secret key; a simple way to achieve that without the use of cumbersome state is to generate the Client-IV values using a cryptographically secure pseudo-random number source. If the Mode defined in RFC 7717 is selected (selected-mode), Client-IV is limited to 12 octets."; Civil, et al. Expires January 3, 2019 [Page 32] Internet-Draft TWAMP YANG Data Model July 2018 reference "RFC 4656: A One-way Active Measurement Protocol (OWAMP). RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)"; } list test-session-request { key name; description "Information associated with the Control-Client for this test session"; leaf name { type string; description "A unique name to be used for identification of this TWAMP-Test session on the Control-Client."; } leaf sender-ip { type inet:ip-address; description "The IP address of the Session-Sender device, which is to be placed in the source IP address field of the IP header in TWAMP-Test (UDP) packets belonging to this test session. This value will be used to populate the sender address field of the Request-TW-Session message. If not configured, the device SHALL choose its own source IP address."; } leaf sender-udp-port { type union { type dynamic-port-number; type enumeration { enum autoallocate { description "Indicates that the Contol-Client will auto-allocate the TWAMP-Test (UDP) port number from the dynamic port range."; } } } Civil, et al. Expires January 3, 2019 [Page 33] Internet-Draft TWAMP YANG Data Model July 2018 default autoallocate; description "The UDP port number that is to be used by the Session-Sender for this TWAMP-Test session. The number is restricted to the dynamic port range. By default the Control-Client SHALL auto-allocate a UDP port number for this TWAMP-Test session. The configured (or auto-allocated) value is advertised in the Sender Port field of the Request-TW-session message (see Section 3.5 of RFC 5357). Note that in the scenario where a device auto-allocates a UDP port number for a session, and the repeat parameter for that session indicates that it should be repeated, the device is free to auto-allocate a different UDP port number when it negotiates the next (repeated) iteration of this session."; } leaf reflector-ip { type inet:ip-address; mandatory true; description "The IP address belonging to the remote Session-Reflector device to which the TWAMP-Test session will be initiated. This value will be used to populate the receiver address field of the Request-TW-Session message."; } leaf reflector-udp-port { type inet:port-number { range "862 | 49152..65535"; } description "This parameter defines the UDP port number that will be used by the Session-Reflector for this TWAMP-Test session. The default number is within the dynamic port range and is to be placed in the Receiver Port field of the Request-TW-Session message. The well-known port (862) MAY be used."; reference "draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP Well-Known Port Assignments."; } Civil, et al. Expires January 3, 2019 [Page 34] Internet-Draft TWAMP YANG Data Model July 2018 leaf timeout { type uint64; units seconds; default 2; description "The length of time (in seconds) that the Session-Reflector should continue to respond to packets belonging to this TWAMP-Test session after a Stop-Sessions TWAMP-Control message has been received. This value will be placed in the Timeout field of the Request-TW-Session message."; reference "RFC 5357: TWAMP, Section 3.5."; } leaf padding-length { type uint32 { range 64..4096; } description "The number of padding bytes to be added to the TWAMP-Test (UDP) packets generated by the Session-Sender. This value will be placed in the Padding Length field of the Request-TW-Session message."; reference "RFC 4656, Section 3.5."; } leaf test-packet-dscp { type inet:dscp; default 0; description "The DSCP value to be placed in the IP header of TWAMP-Test packets generated by the Session-Sender, and in the UDP header of the TWAMP-Test response packets generated by the Session-Reflector for this test session. This value will be placed in the Type-P Descriptor field of the Request-TW-Session message"; reference "RFC 5357."; } Civil, et al. Expires January 3, 2019 [Page 35] Internet-Draft TWAMP YANG Data Model July 2018 leaf start-time { type uint64; default 0; description "Time when the session is to be started (but not before the TWAMP Start-Sessions command is issued; see Section 3.4 of RFC 5357). The start-time value is placed in the Start Time field of the Request-TW-Session message. The timestamp format follows RFC 5905 as per Section 3.5 of RFC 4656. The default value of 0 indicates that the session will be started as soon as the Start-Sessions message is received."; } leaf repeat { type uint32 { range 0..4294967295; } default 0; description "This value determines if the TWAMP-Test session must be repeated. When a test session has completed, the repeat parameter is checked. The default value of 0 indicates that the session MUST NOT be repeated. If the repeat value is 1 through 4,294,967,294 then the test session SHALL be repeated using the information in repeat-interval parameter, and the parent TWAMP-Control connection for this test session is restarted to negotiate a new instance of this TWAMP-Test session. A value of 4,294,967,295 indicates that the test session SHALL be repeated *forever* using the information in repeat-interval parameter, and SHALL NOT decrement the value."; } leaf repeat-interval { when "../repeat!='0'" { description Civil, et al. Expires January 3, 2019 [Page 36] Internet-Draft TWAMP YANG Data Model July 2018 "This parameter determines the timing of repeated TWAMP-Test sessions when repeat is more than 0. When the value of repeat-interval is 0, the negotiation of a new test session SHALL begin immediately after the previous test session completes. Otherwise, the Control-Client will wait for the number of seconds specified in the repeat-interval parameter before negotiating the new instance of this TWAMP-Test session."; } type uint32; units seconds; default 0; description "Repeat interval (in seconds)."; } list pm-reg-list { key pm-index; leaf pm-index { type uint16; description "Numerical index value of a Registered Metric in the Performance Metric Registry (see ietf-ippm-metric-registry). Output statistics are specified in the corresponding Registry entry."; } description "A list of one or more Performance Metric Registry Index values, which communicate packet stream characteristics along with one or more metrics to be measured. All members of the pm-reg-list MUST have the same stream characteristics, such that they combine to specify all metrics that shall be measured on a single stream."; reference "ietf-ippm-metric-registry: Registry for Performance Metrics"; } leaf state { type test-session-state; config false; description Civil, et al. Expires January 3, 2019 [Page 37] Internet-Draft TWAMP YANG Data Model July 2018 "Indicates the TWAMP-Test session state, accepted or indication of an error."; reference "Section 3.5 of RFC 5357."; } leaf sid { type string; config false; description "The SID allocated by the Server for this TWAMP-Test session, and communicated back to the Control-Client in the SID field of the Accept-Session message"; reference "Section 4.3 of RFC 6038."; } } } } container server { if-feature server; description "Configuration of the TWAMP Server logical entity."; leaf admin-state { type boolean; default true; description "Indicates whether the device is allowed to operate as a TWAMP Server."; } leaf server-tcp-port { type inet:port-number; default 862; description "This parameter defines the well known TCP port number that is used by TWAMP-Control. The Server will listen on this port number for incoming TWAMP-Control connections. Although this is defined as a fixed value (862) in RFC 5357, there are several realizations of TWAMP in the field that were implemented before this well-known port number was allocated. These early implementations allowed the port number to be configured. This parameter is therefore provided for backward compatibility reasons."; } Civil, et al. Expires January 3, 2019 [Page 38] Internet-Draft TWAMP YANG Data Model July 2018 leaf servwait { type uint32 { range 1..604800; } units seconds; default 900; description "TWAMP-Control (TCP) session timeout, in seconds. According to Section 3.1 of RFC 5357, Server MAY discontinue any established control connection when no packet associated with that connection has been received within SERVWAIT seconds."; } leaf control-packet-dscp { type inet:dscp; description "The DSCP value to be placed in the IP header of TWAMP-Control (TCP) packets generated by the Server. Section 3.1 of RFC 5357 specifies that the server SHOULD use the DSCP value from the Control-Clients TCP SYN. However, for practical purposes TWAMP will typically be implemented using a general purpose TCP stack provided by the underlying operating system, and such a stack may not provide this information to the user. Consequently, it is not always possible to implement the behavior described in RFC 5357 in an OS-portable version of TWAMP. The default behavior if this item is not set is to use the DSCP value from the Control-Clients TCP SYN."; reference "Section 3.1 of RFC 5357."; } uses count; uses max-count-exponent; leaf modes { type twamp-modes; description "The bit mask of TWAMP Modes this Server instance is willing to support; see IANA TWAMP Modes Registry."; } Civil, et al. Expires January 3, 2019 [Page 39] Internet-Draft TWAMP YANG Data Model July 2018 uses key-management; list ctrl-connection { key "client-ip client-tcp-port server-ip server-tcp-port"; config false; description "List of all incoming TWAMP-Control (TCP) connections."; leaf client-ip { type inet:ip-address; description "The IP address on the remote Control-Client device, which is the source IP address used in the TWAMP-Control (TCP) packets belonging to this control connection."; } leaf client-tcp-port { type inet:port-number; description "The source TCP port number used in the TWAMP-Control (TCP) packets belonging to this control connection."; } leaf server-ip { type inet:ip-address; description "The IP address of the local Server device, which is the destination IP address used in the TWAMP-Control (TCP) packets belonging to this control connection."; } leaf server-tcp-port { type inet:port-number; description "The destination TCP port number used in the TWAMP-Control (TCP) packets belonging to this control connection. This will usually be the same value as the server-tcp-port configured under twamp/server. However, in the event that the user re-configured server/server-tcp-port after this control connection was initiated, this value will indicate the server-tcp-port that is actually in use for this control connection."; } leaf state { Civil, et al. Expires January 3, 2019 [Page 40] Internet-Draft TWAMP YANG Data Model July 2018 type server-ctrl-connection-state; description "Indicates the Server TWAMP-Control connection state."; } leaf control-packet-dscp { type inet:dscp; description "The DSCP value used in the IP header of the TWAMP-Control (TCP) packets sent by the Server for this control connection. This will usually be the same value as is configured in the control-packet-dscp parameter under the twamp/server container. However, in the event that the user re-configures server/dscp after this control connection is already in progress, this read-only value will show the actual dscp value in use by this TWAMP-Control connection."; } leaf selected-mode { type twamp-modes; description "The Mode that was chosen for this TWAMP-Control connection as set in the Mode field of the Set-Up-Response message."; } leaf key-id { type string { length 1..80; } description "The KeyID value that is in use by this TWAMP-Control connection as selected by Control-Client."; } uses count { description "The count value that is in use by this TWAMP-Control connection. This will usually be the same value as is configured under twamp/server. However, in the event that the user re-configured server/count after this control connection is already in progress, this read-only value will show the actual count that is in use for this TWAMP-Control connection."; } Civil, et al. Expires January 3, 2019 [Page 41] Internet-Draft TWAMP YANG Data Model July 2018 uses max-count-exponent { description "This read-only value indicates the actual max-count in use for this control connection. Usually this would be the same value as configured under twamp/server."; } leaf salt { type binary { length 16; } description "A parameter used in deriving a key from a shared secret as described in Section 3.1 of RFC 4656. It is communicated to the Control-Client as part of the Server Greeting message."; } leaf server-iv { type binary { length 16; } description "The Server Initialization Vector (IV) generated randomly by the Server."; } leaf challenge { type binary { length 16; } description "A random sequence of octets generated by the Server. As described in client/token, Challenge is used by the Control-Client to prove possession of a shared secret."; } } } container session-sender { if-feature session-sender; description "Configuration of the TWAMP Session-Sender logical entity"; leaf admin-state { type boolean; default true; description Civil, et al. Expires January 3, 2019 [Page 42] Internet-Draft TWAMP YANG Data Model July 2018 "Indicates whether the device is allowed to operate as a TWAMP Session-Sender."; } list test-session{ key name; description "List of TWAMP Session-Sender test sessions."; leaf name { type string; description "A unique name for this TWAMP-Test session to be used for identifying this test session by the Session-Sender logical entity."; } leaf ctrl-connection-name { type string; config false; description "The name of the parent TWAMP-Control connection that is responsible for negotiating this TWAMP-Test session."; } leaf fill-mode { type padding-fill-mode; default zero; description "Indicates whether the padding added to the TWAMP-Test (UDP) packets will contain pseudo-random numbers, or whether it should consist of all zeroes, as per Section 4.2.1 of RFC 5357."; } leaf number-of-packets { type uint32; mandatory true; description "The overall number of TWAMP-Test (UDP) packets to be transmitted by the Session-Sender for this test session."; } choice packet-distribution { description "Indicates the distribution to be used for transmitting Civil, et al. Expires January 3, 2019 [Page 43] Internet-Draft TWAMP YANG Data Model July 2018 the TWAMP-Test (UDP) packets."; case periodic { leaf periodic-interval { type decimal64 { fraction-digits 5; } units seconds; mandatory true; description "Indicates the time to wait (in seconds) between the first bits of TWAMP-Test (UDP) packet transmissions for this test session."; reference "RFC 3432: Network performance measurement with periodic streams"; } } case poisson { leaf lambda { type decimal64 { fraction-digits 5; } units seconds; mandatory true; description "Indicates the average time interval (in seconds) between packets in the Poisson distribution. The packet is calculated using the reciprocal of lambda and the TWAMP-Test packet size (which depends on the selected Mode and the packet padding)."; reference "RFC 2330: Framework for IP Performance Metrics"; } leaf max-interval { type decimal64 { fraction-digits 5; } units seconds; description "Indicates the maximum time (in seconds) between packet transmissions."; reference "RFC 7312: Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)"; } } } Civil, et al. Expires January 3, 2019 [Page 44] Internet-Draft TWAMP YANG Data Model July 2018 leaf state { type sender-session-state; config false; description "Indicates the Session-Sender test session state."; } uses maintenance-statistics; } } container session-reflector { if-feature session-reflector; description "Configuration of the TWAMP Session-Reflector logical entity"; leaf admin-state { type boolean; default true; description "Indicates whether the device is allowed to operate as a TWAMP Session-Reflector."; } leaf refwait { type uint32 { range 1..604800; } units seconds; default 900; description "The Session-Reflector MAY discontinue any session that has been started when no packet associated with that session has been received for REFWAIT seconds. As per Section 3.1 of RFC 5357, this timeout allows a Session-Reflector to free up resources in case of failure."; } list test-session { key "sender-ip sender-udp-port reflector-ip reflector-udp-port"; config false; description "TWAMP Session-Reflectortest sessions."; Civil, et al. Expires January 3, 2019 [Page 45] Internet-Draft TWAMP YANG Data Model July 2018 leaf sid { type string; description "An auto-allocated identifier for this TWAMP-Test session that is unique within the context of this Server/Session-Reflector device only. This value is communicated to the Control-Client that requested the test session in the SID field of the Accept-Session message."; } leaf sender-ip { type inet:ip-address; description "The IP address on the remote device, which is the source IP address used in the TWAMP-Test (UDP) packets belonging to this test session."; } leaf sender-udp-port { type dynamic-port-number; description "The source UDP port used in the TWAMP-Test packets belonging to this test session."; } leaf reflector-ip { type inet:ip-address; description "The IP address of the local Session-Reflector device, which is the destination IP address used in the TWAMP-Test (UDP) packets belonging to this test session."; } leaf reflector-udp-port { type inet:port-number { range "862 | 49152..65535"; } description "The destination UDP port number used in the TWAMP-Test (UDP) test packets belonging to this test session."; } leaf parent-connection-client-ip { type inet:ip-address; description Civil, et al. Expires January 3, 2019 [Page 46] Internet-Draft TWAMP YANG Data Model July 2018 "The IP address on the Control-Client device, which is the source IP address used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf parent-connection-client-tcp-port { type inet:port-number; description "The source TCP port number used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf parent-connection-server-ip { type inet:ip-address; description "The IP address of the Server device, which is the destination IP address used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf parent-connection-server-tcp-port { type inet:port-number; description "The destination TCP port number used in the TWAMP-Control (TCP) packets belonging to the parent control connection that negotiated this test session."; } leaf test-packet-dscp { type inet:dscp; description "The DSCP value present in the IP header of TWAMP-Test (UDP) packets belonging to this session."; } uses maintenance-statistics; } } } } Civil, et al. Expires January 3, 2019 [Page 47] Internet-Draft TWAMP YANG Data Model July 2018 6. Data Model Examples This section presents a simple but complete example of configuring all four entities in Figure 1, based on the YANG module specified in Section 5. The example is illustrative in nature, but aims to be self-contained, i.e. were it to be executed in a real TWAMP implementation it would lead to a correctly configured test session. For completeness, examples are provided for both IPv4 and IPv6. A more elaborated example, which also includes authentication parameters, is provided in Appendix A. 6.1. Control-Client Figure 8 shows a configuration example for a Control-Client with client/admin-state enabled. In a real implementation following Figure 2 this would permit the initiation of TWAMP-Control connections and TWAMP-Test sessions. true Figure 8: XML instance enabling Control-Client operation. The following example shows a Control-Client with two instances of client/ctrl-connection, one called "RouterA" and another called "RouterB". Each TWAMP-Control connection is to a different Server. The control connection named "RouterA" has two test session requests. The TWAMP-Control connection named "RouterB" has no TWAMP-Test session requests. true RouterA 203.0.113.1 203.0.113.2 Civil, et al. Expires January 3, 2019 [Page 48] Internet-Draft TWAMP YANG Data Model July 2018 Test1 203.0.113.3 54001 203.0.113.4 50001 0 Test2 203.0.113.1 54001 203.0.113.2 50001 0 RouterB 203.0.113.1 203.0.113.3 true RouterA 2001:DB8:203:0:113::1 2001:DB8:203:0:113::2 Test1 2001:DB8:203:1:113::3 54000 2001:DB8:203:1:113::4 55000 0 Test2 2001:DB8:203:0:113::1 54001 2001:DB8:203:0:113::2 55001 Civil, et al. Expires January 3, 2019 [Page 49] Internet-Draft TWAMP YANG Data Model July 2018 0 RouterB 2001:DB8:203:0:113::1 2001:DB8:203:0:113::3 6.2. Server Figure 9 shows a configuration example for a Server with server/ admin-state enabled, which permits a device following Figure 2 to respond to TWAMP-Control connections and TWAMP-Test sessions. true Figure 9: XML instance enabling Server operation. The following example presents a Server with the TWAMP-Control connection corresponding to the control connection name (client/ctrl- connection/name) "RouterA" presented in Section 6.1. Civil, et al. Expires January 3, 2019 [Page 50] Internet-Draft TWAMP YANG Data Model July 2018 true 203.0.113.1 16341 203.0.113.2 862 active true 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 862 active 6.3. Session-Sender Figure 10 shows a configuration example for a Session-Sender with session-sender/admin-state enabled, which permits a device following Figure 2 to initiate TWAMP-Test sessions. Civil, et al. Expires January 3, 2019 [Page 51] Internet-Draft TWAMP YANG Data Model July 2018 true Figure 10: XML instance enabling Session-Sender operation. The following configuration example shows a Session-Sender with the two TWAMP-Test sessions presented in Section 6.1. true Test1 RouterA 900 1 Test2 RouterA 900 1 2 6.4. Session-Reflector This configuration example shows a Session-Reflector with session- reflector/admin-state enabled, which permits a device following Figure 2 to respond to TWAMP-Test sessions. Civil, et al. Expires January 3, 2019 [Page 52] Internet-Draft TWAMP YANG Data Model July 2018 true Figure 11: XML instance enabling Session-Reflector operation. The following example shows the two Session-Reflector TWAMP-Test sessions corresponding to the test sessions presented in Section 6.3. [note: '\' line wrapping is for formatting only] true 203.0.113.3 54000 203.0.113.4 50001 1232 203.0.113.1 16341 203.0.113.2 862 2 2 1 1 203.0.113.1 54001 192.0.2.2 50001 178943 203.0.113.1 16341 203.0.113.2 862 21 21 20 20 [note: '\' line wrapping is for formatting only] true 203.0.113.3 54000 203.0.113.4 54001 1232 203.0.113.1 16341 203.0.113.2 862 2 2 1 1 203.0.113.1 54001 192.0.2.2 55001 178943 Civil, et al. Expires January 3, 2019 [Page 54] Internet-Draft TWAMP YANG Data Model July 2018 203.0.113.1 16341 203.0.113.2 862 21 21 20 20 7. Security Considerations Virtually all existing measurement systems using TWAMP [RFC5357] are administered by the same network operator. Attacks on the measurement infrastructure could be launched by third-parties to commandeer the packet generation capability, corrupt the measurements, or other examples of nefarious acts. The YANG module specified in Section 5 of this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF [RFC6241] layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- implement secure transport is TLS [RFC5246]. The NETCONF Access Control Module (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of nodes defined in this YANG module which are writeable. These data nodes may be considered sensitive and vulnerable to attacks in some network environments. Ability to write into these nodes without proper protection can have a negative effect on the devices that support this feature. If written, the 'admin-state' node can cause unintended test sessions to be created. If the node 'number-of-packets' that dictates how many packets are sent in any particular test session is written with Civil, et al. Expires January 3, 2019 [Page 55] Internet-Draft TWAMP YANG Data Model July 2018 a large value, it can cause a test session to run longer than expected. Nodes that are particularly vulnerable include several timeout values put in the protocol to protect against sessions that are not active but are consuming resources. These are the REFWAIT timeout parameter which determine whether to discontinue the session if no packets are received, and nodes 'count' and 'max-count- exponent' which can cause a long time to be spent on PBKDF2 iterations. In addition, 'dscp' node marked with different DSCP markings, can cause the test traffic on the network to be skewed, and the result manipulated. Finally, nodes within 'mode-preference- chain' which specify the 'mode' and 'priority' values and indicate the preferred order of use by an operator, can be manipulated to send unauthenticated or non-encrypted traffic, enabling a MITM attack. Limiting access to these nodes will limit the ability to launch an attack in network environments. The 'token' node defined in the model, containing a concatenation of a Challenge, AES Session-key used for encryption, and HMAC-SHA1 Session-key used for authentication, is sensitive from a privacy perspective, and can be used to disrupt a test session. The ability to read the field should be limited to the administrator of the test network. 8. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in IETF XML Registry [RFC3688], the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-twamp Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry YANG [RFC6020]. name: ietf-twamp namespace: urn:ietf:params:xml:ns:yang:ietf-twamp prefix: twamp reference: RFC XXXX Civil, et al. Expires January 3, 2019 [Page 56] Internet-Draft TWAMP YANG Data Model July 2018 9. Acknowledgements We thank Fred Baker, Kevin D'Souza, Gregory Mirsky, Brian Trammell, Robert Sherman, and Marius Georgescu for their thorough and constructive reviews, comments and text suggestions. Haoxing Shen contributed to the definition of the YANG module in Section 5. Jan Lindblad and Ladislav Lhokta did thorough reviews of the YANG module and the examples in Appendix A. Kostas Pentikousis was partially supported by FP7 UNIFY (http://fp7-unify.eu), a research project partially funded by the European Community under the Seventh Framework Program (grant agreement no. 619609). The views expressed here are those of the authors only. The European Commission is not liable for any use that may be made of the information in this document. 10. Contributors Lianshu Zheng. 11. References 11.1. Normative References [I-D.ietf-ippm-metric-registry] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, "Registry for Performance Metrics", draft-ietf- ippm-metric-registry-14 (work in progress), March 2018. [I-D.ietf-ippm-port-twamp-test] Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port Assignments", draft-ietf-ippm-port-twamp-test-01 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, . Civil, et al. Expires January 3, 2019 [Page 57] Internet-Draft TWAMP YANG Data Model July 2018 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, "IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7717, DOI 10.17487/RFC7717, December 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Civil, et al. Expires January 3, 2019 [Page 58] Internet-Draft TWAMP YANG Data Model July 2018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [UML] ISO/IEC, "Information technology - Open Distributed Processing - Unified Modeling Language", April 2005. 11.2. Informative References [NSC] John, W., Pentikousis, K., et al., "Research directions in network service chaining", Proc. SDN for Future Networks and Services (SDN4FNS), Trento, Italy IEEE, November 2013. [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, DOI 10.17487/RFC5618, August 2009, . [RFC5938] Morton, A. and M. Chiba, "Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, . Civil, et al. Expires January 3, 2019 [Page 59] Internet-Draft TWAMP YANG Data Model July 2018 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5: Password-Based Cryptography Specification Version 2.1", RFC 8018, DOI 10.17487/RFC8018, January 2017, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Appendix A. Detailed Data Model Examples This appendix extends the example presented in Section 6 by configuring more fields such as authentication parameters, DSCP values and so on. A.1. Control-Client true 0 authenticated 1 Civil, et al. Expires January 3, 2019 [Page 60] Internet-Draft TWAMP YANG Data Model July 2018 unauthenticated KeyClient1ToRouterA c2VjcmV0MQ== KeyForRouterB c2VjcmV0Mg0K RouterA 203.0.113.1 203.0.113.2 32 KeyClient1ToRouterA Test1 203.0.113.3 54000 203.0.113.4 55000 64 0 Test2 203.0.113.1 54001 203.0.113.2 55001 128 0 true 0 authenticated Civil, et al. Expires January 3, 2019 [Page 61] Internet-Draft TWAMP YANG Data Model July 2018 1 unauthenticated KeyClient1ToRouterA c2VjcmV0MQ== KeyForRouterB c2VjcmV0Mg0K RouterA 2001:DB8:203:0:113::1 2001:DB8:203:0:113::2 32 KeyClient1ToRouterA Test1 2001:DB8:10:1:1::1 54000 2001:DB8:10:1:1::2 55000 64 0 Test2 2001:DB8:203:0:113::1 54001 2001:DB8:203:0:113::2 55001 128 0 A.2. Server Civil, et al. Expires January 3, 2019 [Page 62] Internet-Draft TWAMP YANG Data Model July 2018 true 1800 32 authenticated unauthenticated 15 KeyClient1ToRouterA c2VjcmV0MQ== KeyClient10ToRouterA c2VjcmV0MTANCg== 203.0.113.1 16341 203.0.113.2 862 32 unauthenticated KeyClient1ToRouterA 15 true 1800 32 authenticated unauthenticated 15 KeyClient1ToRouterA c2VjcmV0MQ== KeyClient10ToRouterA c2VjcmV0MTANCg== 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 Civil, et al. Expires January 3, 2019 [Page 63] Internet-Draft TWAMP YANG Data Model July 2018 862 32 unauthenticated KeyClient1ToRouterA 15 A.3. Session-Sender true Test1 RouterA zero 900 1 2 2 1 1 Test2 RouterA random 900 1 2 21 21 20 20 Civil, et al. Expires January 3, 2019 [Page 64] Internet-Draft TWAMP YANG Data Model July 2018 A.4. Session-Reflector [note: '\' line wrapping is for formatting only] true 203.0.113.3 54000 203.0.113.4 55000 1232 203.0.113.1 16341 203.0.113.2 862 32 2 2 1 1 203.0.113.1 54001 192.0.2.2 55001 178943 203.0.113.1 16341 203.0.113.2 862 32 21 21 20 20 Civil, et al. Expires January 3, 2019 [Page 65] Internet-Draft TWAMP YANG Data Model July 2018 [note: '\' line wrapping is for formatting only] true 2001:DB8:10:1:1::1 54000 2001:DB8:10:1:1::2 55000 1232 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 862 32 2 2 1 1 2001:DB8:203:0:113::1 54001 2001:DB8:192:68::2 55001 178943 2001:DB8:203:0:113::1 16341 2001:DB8:203:0:113::2 862 32 21 Civil, et al. Expires January 3, 2019 [Page 66] Internet-Draft TWAMP YANG Data Model July 2018 21 20 20 Appendix B. TWAMP Operational Commands TWAMP operational commands could be performed programmatically or manually, e.g. using a command-line interface (CLI). With respect to programmability, YANG can be used to define NETCONF Remote Procedure Calls (RPC), therefore it would be, in principle, possible to define TWAMP RPC operations for actions such as starting or stopping control connections or test sessions or groups of sessions; retrieving results; clearing stored results, and so on. However, TWAMP [RFC5357] does not attempt to describe such operational actions. Refer also to Section 2 and the unlabeled links in Figure 1. In actual deployments different TWAMP implementations may support different sets of operational commands, with different restrictions. Therefore, this document considers it the responsibility of the individual implementation to define its corresponding TWAMP operational commands data model. Authors' Addresses Ruth Civil Ciena Corporation 307 Legget Drive Kanata, ON K2K 3C8 Canada Email: gcivil@ciena.com URI: www.ciena.com Civil, et al. Expires January 3, 2019 [Page 67] Internet-Draft TWAMP YANG Data Model July 2018 Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com Reshad Rahman Cisco Systems 2000 Innovation Drive Kanata, ON K2K 3E8 Canada Email: rrahman@cisco.com Mahesh Jethanandani Xoriant Corporation 1248 Reamswood Drive Sunnyvale, CA 94089 USA Email: mjethanandani@gmail.com Kostas Pentikousis (editor) Travelping Siemensdamm 50 Berlin 13629 Germany Email: k.pentikousis@travelping.com Civil, et al. Expires January 3, 2019 [Page 68] ./draft-ietf-bfd-vxlan-16.txt0000644000764400076440000005215513745635616015270 0ustar iustyiusty BFD S. Pallagatti, Ed. Internet-Draft VMware Intended status: Informational G. Mirsky, Ed. Expires: April 29, 2021 ZTE Corp. S. Paragiri Individual Contributor V. Govindan M. Mudigonda Cisco October 26, 2020 BFD for VXLAN draft-ietf-bfd-vxlan-16 Abstract This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels used to form an overlay network. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Pallagatti, et al. Expires April 29, 2021 [Page 1] Internet-Draft BFD for VXLAN October 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use of the Management VNI . . . . . . . . . . . . . . . . . . 5 5. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6 6. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 8 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informational References . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an encapsulation scheme that allows building an overlay network by decoupling the address space of the attached virtual hosts from that of the network. One use of VXLAN is in data centers interconnecting virtual machines (VMs) of a tenant. VXLAN addresses requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VMs in a multi-tenant environment by providing a Layer 2 overlay scheme on a Layer 3 network [RFC7348]. Another use is as an encapsulation for Ethernet VPN [RFC8365]. This document is written assuming the use of VXLAN for virtualized hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in hypervisors. However, the concepts are equally applicable to non- virtualized hosts attached to VTEPs in switches. In the absence of a router in the overlay, a VM can communicate with another VM only if they are on the same VXLAN segment. VMs are unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. Pallagatti, et al. Expires April 29, 2021 [Page 2] Internet-Draft BFD for VXLAN October 2020 VTEPs are responsible for encapsulating and decapsulating frames exchanged among VMs. The ability to monitor path continuity, i.e., perform proactive continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is important. The asynchronous mode of BFD, as defined in [RFC5880], is used to monitor a p2p VXLAN tunnel. In the case where a Multicast Service Node (MSN) (as described in Section 3.3 of [RFC8293]) participates in VXLAN, the mechanisms described in this document apply and can, therefore, be used to test the continuity of the path between the source NVE and the MSN. This document describes the use of Bidirectional Forwarding Detection (BFD) protocol to enable monitoring continuity of the path between VXLAN VTEPs that are performing as Network Virtualization Endpoints, and/or between the source NVE and a replicator MSN using a Management VNI (Section 4). All other uses of the specification to test toward other VXLAN endpoints are out of the scope. 2. Conventions Used in this Document 2.1. Acronyms BFD Bidirectional Forwarding Detection CC Continuity Check p2p Point-to-point MSN Multicast Service Node NVE Network Virtualization Endpoint VFI Virtual Forwarding Instance VM Virtual Machine VNI VXLAN Network Identifier (or VXLAN Segment ID) VTEP VXLAN Tunnel End Point VXLAN Virtual eXtensible Local Area Network Pallagatti, et al. Expires April 29, 2021 [Page 3] Internet-Draft BFD for VXLAN October 2020 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Deployment Figure 1 illustrates the scenario with two servers, each of them hosting two VMs. The servers host VTEPs that terminate two VXLAN tunnels with VXLAN Network Identifier (VNI) number 100 and 200 respectively. Separate BFD sessions can be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200). Using a BFD session to monitor a set of VXLAN VNIs between the same pair of VTEPs might help to detect and localize problems caused by misconfiguration. An implementation that supports this specification MUST be able to control the number of BFD sessions that can be created between the same pair of VTEPs. This method is applicable whether the VTEP is a virtual or physical device. Pallagatti, et al. Expires April 29, 2021 [Page 4] Internet-Draft BFD for VXLAN October 2020 +------------+-------------+ | Server 1 | | +----+----+ +----+----+ | | |VM1-1 | |VM1-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | VTEP (IP1) | +--------------------------+ | | +-------------+ | | Layer 3 | +---| Network | +-------------+ | +-----------+ | +------------+-------------+ | VTEP (IP2) | | +----+----+ +----+----+ | | |VM2-1 | |VM2-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | Server 2 | +--------------------------+ Figure 1: Reference VXLAN Domain At the same time, a service layer BFD session may be used between the tenants of VTEPs IP1 and IP2 to provide end-to-end fault management (this use case is outside the scope of this document). In such a case, for VTEPs, the BFD Control packets of that session are indistinguishable from data packets. For BFD Control packets encapsulated in VXLAN (Figure 2), the inner destination IP address SHOULD be set to one of the loopback addresses from 127/8 range for IPv4 or to one of IPv4-mapped IPv6 loopback addresses from ::ffff:127.0.0.0/104 range for IPv6. 4. Use of the Management VNI In most cases, a single BFD session is sufficient for the given VTEP to monitor the reachability of a remote VTEP, regardless of the number of VNIs. BFD control messages MUST be sent using the Management VNI which acts as the as control and management channel between VTEPs. An implementation MAY support operating BFD on Pallagatti, et al. Expires April 29, 2021 [Page 5] Internet-Draft BFD for VXLAN October 2020 another (non-Management) VNI although the implications of this are outside the scope of this document. The selection of the VNI number of the Management VNI MUST be controlled through a management plane. An implementation MAY use VNI number 1 as the default value for the Management VNI. All VXLAN packets received on the Management VNI MUST be processed locally and MUST NOT be forwarded to a tenant. 5. BFD Packet Transmission over VXLAN Tunnel BFD packets MUST be encapsulated and sent to a remote VTEP as explained in this section. Implementations SHOULD ensure that the BFD packets follow the same forwarding path as VXLAN data packets within the sender system. BFD packets are encapsulated in VXLAN as described below. The VXLAN packet format is defined in Section 5 of [RFC7348]. The value in the VNI field of the VXLAN header MUST be set to the value selected as the Management VNI. The Outer IP/UDP and VXLAN headers MUST be encoded by the sender as defined in [RFC7348]. Pallagatti, et al. Expires April 29, 2021 [Page 6] Internet-Draft BFD for VXLAN October 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Outer Ethernet Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Outer IPvX Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Outer UDP Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ VXLAN Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Inner Ethernet Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Inner IPvX Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Inner UDP Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ BFD Control Packet ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Ethernet FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: VXLAN Encapsulation of BFD Control Packet The BFD packet MUST be carried inside the inner Ethernet frame of the VXLAN packet. The choice of Destination MAC and Destination IP addresses for the inner Ethernet frame MUST ensure that the BFD Control packet is not forwarded to a tenant but is processed locally at the remote VTEP. The inner Ethernet frame carrying the BFD Control packet- has the following format: Ethernet Header: Pallagatti, et al. Expires April 29, 2021 [Page 7] Internet-Draft BFD for VXLAN October 2020 Destination MAC: A Management VNI, which does not have any tenants, will have no dedicated MAC address for decapsulated traffic. The value (TBD1) SHOULD be used in this field. Source MAC: MAC address associated with the originating VTEP. Ethertype: is set to 0x0800 if the inner IP header is IPv4, and is set to 0x86DD if the inner IP header is IPv6. IP header: Destination IP: IP address MUST NOT be of one of tenant's IP addresses. The IP address SHOULD be selected from the range 127/8 for IPv4, for IPv6 - from the range ::ffff:127.0.0.0/104. Alternatively, the destination IP address MAY be set to VTEP's IP address. Source IP: IP address of the originating VTEP. TTL or Hop Limit: MUST be set to 255 in accordance with [RFC5881]. The fields of the UDP header and the BFD Control packet are encoded as specified in [RFC5881]. 6. Reception of BFD Packet from VXLAN Tunnel Once a packet is received, the VTEP MUST validate the packet. If the packet is received on the management VNI and is identified as BFD control packet addressed to the VTEP, and then the packet can be processed further. Processing of BFD control packets received on non-management VNI is outside the scope of this specification. The received packet's inner IP payload is then validated according to Sections 4 and 5 in [RFC5881]. 7. Echo BFD Support for echo BFD is outside the scope of this document. 8. IANA Considerations IANA is requested to assign a single MAC address to the value TBD1 from the "IANA Unicast 48-bit MAC Address" registry from the "Unassigned (small allocations)" block. The Usage field will be "BFD for VXLAN" with a Reference field of this document. Pallagatti, et al. Expires April 29, 2021 [Page 8] Internet-Draft BFD for VXLAN October 2020 9. Security Considerations Security issues discussed in [RFC5880], [RFC5881], and [RFC7348] apply to this document. This document recommends using an address from the Internal host loopback addresses 127/8 range for IPv4 or an IP4-mapped IPv6 loopback address from ::ffff:127.0.0.0/104 range for IPv6 as the destination IP address in the inner IP header. Using such an address prevents the forwarding of the encapsulated BFD control message by a transient node in case the VXLAN tunnel is broken as according to [RFC1812]. A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks. The use of IPv4-mapped IPv6 addresses has the same property as using the IPv4 network 127/8, moreover, the IPv4-mapped IPv6 addresses prefix is not advertised in any routing protocol. If the implementation supports establishing multiple BFD sessions between the same pair of VTEPs, there SHOULD be a mechanism to control the maximum number of such sessions that can be active at the same time. 10. Contributors Reshad Rahman rrahman@cisco.com Cisco 11. Acknowledgments Authors would like to thank Jeff Haas of Juniper Networks for his reviews and feedback on this material. Authors would also like to thank Nobo Akiya, Marc Binderberger, Shahram Davari, Donald E. Eastlake 3rd, Anoop Ghanwani, Dinesh Dutt, Joel Halpern, and Carlos Pignataro for the extensive reviews and the most detailed and constructive comments. Pallagatti, et al. Expires April 29, 2021 [Page 9] Internet-Draft BFD for VXLAN October 2020 12. References 12.1. Normative References [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informational References [RFC8293] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. Krishnan, "A Framework for Multicast in Network Virtualization over Layer 3", RFC 8293, DOI 10.17487/RFC8293, January 2018, . [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, . Pallagatti, et al. Expires April 29, 2021 [Page 10] Internet-Draft BFD for VXLAN October 2020 Authors' Addresses Santosh Pallagatti (editor) VMware Email: santosh.pallagatti@gmail.com Greg Mirsky (editor) ZTE Corp. Email: gregimirsky@gmail.com Sudarsan Paragiri Individual Contributor Email: sudarsan.225@gmail.com Vengada Prasad Govindan Cisco Email: venggovi@cisco.com Mallik Mudigonda Cisco Email: mmudigon@cisco.com Pallagatti, et al. Expires April 29, 2021 [Page 11] ./draft-ietf-isis-mpls-elc-13.txt0000644000764400076440000003701213663733564016060 0ustar iustyiusty LSR Working Group X. Xu Internet-Draft Alibaba Inc Intended status: Standards Track S. Kini Expires: November 29, 2020 P. Psenak C. Filsfils S. Litkowski Cisco Systems, Inc. M. Bocci Nokia May 28, 2020 Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS draft-ietf-isis-mpls-elc-13 Abstract Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using IS-IS and BGP-LS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 29, 2020. Xu, et al. Expires November 29, 2020 [Page 1] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Advertising ELC Using IS-IS . . . . . . . . . . . . . . . . . 3 4. Advertising ERLD Using IS-IS . . . . . . . . . . . . . . . . 4 5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction [RFC6790] describes a method to load-balance Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels (EL). It also introduces the concept of Entropy Label Capability (ELC) and defines the signaling of this capability via MPLS signaling protocols. Recently, mechanisms have been defined to signal labels via link- state Interior Gateway Protocols (IGP) such as IS-IS [RFC8667]. This draft defines a mechanism to signal the ELC using IS-IS. In cases where Segment Routing (SR) is used with the MPLS Data Plane (e.g., SR-MPLS [RFC8660]), it would be useful for ingress LSRs to know each intermediate LSR's capability of reading the maximum label stack depth and performing EL-based load-balancing. This capability, referred to as Entropy Readable Label Depth (ERLD) as defined in [RFC8662], may be used by ingress LSRs to determine the position of the EL label in the stack, and whether it's necessary to insert Xu, et al. Expires November 29, 2020 [Page 2] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 multiple ELs at different positions in the label stack. This document defines a mechanism to signal the ERLD using IS-IS. 2. Terminology This memo makes use of the terms defined in [RFC6790], and [RFC8662]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Advertising ELC Using IS-IS Even though ELC is a property of the node, in some cases it is advantageous to associate and advertise the ELC with a prefix. In a multi-area network, routers may not know the identity of the prefix originator in a remote area, or may not know the capabilities of such originator. Similarly, in a multi-domain network, the identity of the prefix originator and its capabilities may not be known to the ingress LSR. Bit 3 in the Prefix Attribute Flags [RFC7794] is used as the ELC Flag (E-flag), as shown in Figure 1. If a router has multiple interfaces, the router MUST NOT announce the ELC for any local host prefixes unless all of its interfaces are capable of processing ELs. If a router supports ELs on all of its interfaces, it SHOULD set the ELC for every local host prefix it advertises in IS-IS. 0 1 2 3 4 5 6 7... +-+-+-+-+-+-+-+-+... |X|R|N|E| ... +-+-+-+-+-+-+-+-+... Figure 1: Prefix Attribute Flags E-flag: ELC Flag (Bit 3) - Set for local host prefix of the originating node if it supports ELC on all interfaces. The ELC signaling MUST be preserved when a router propagates a prefix between ISIS levels [RFC5302]. When redistributing a prefix between two IS-IS protocol instances or redistributing from another protocol to an IS-IS protocol instance, a router SHOULD preserve the ELC signaling for that prefix if it exists. The exact mechanism used to exchange ELC between protocol instances running on an Autonomous System Boundary Router is outside of the scope of this document. Xu, et al. Expires November 29, 2020 [Page 3] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 4. Advertising ERLD Using IS-IS A new MSD-Type [RFC8491], called ERLD-MSD, is defined to advertise the ERLD [RFC8662] of a given router. A MSD-Type code 2 has been assigned by IANA for ERLD-MSD. The MSD-Value field is set to the ERLD in the range between 0 to 255. The scope of the advertisement depends on the application. If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest value found across all its interfaces. The absence of ERLD-MSD advertisements indicates only that the advertising node does not support advertisement of this capability. The considerations for advertising the ERLD are specified in [RFC8662]. If the ERLD-MSD Type is received in the Link MSD Sub-TLV, it MUST be ignored. 5. Signaling ELC and ERLD in BGP-LS The IS-IS extensions defined in this document can be advertised via BGP-LS (Distribution of Link-State and TE Information Using BGP) [RFC7752] using existing BGP-LS TLVs. The ELC is advertised using the Prefix Attribute Flags TLV as defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The ERLD-MSD is advertised using the Node MSD TLV as defined in [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 6. IANA Considerations Early allocation has been done by IANA for this document as follows: - Bit 3 in the Bit Values for Prefix Attribute Flags Sub-TLV registry has been assigned to the ELC Flag. IANA is asked to update the registry to reflect the name used in this document: ELC Flag (E-flag). - Type 2 in the IGP MSD-Types registry has been assigned for the ERLD-MSD. IANA is asked to update the registry to reflect the name used in this document: ERLD-MSD. Xu, et al. Expires November 29, 2020 [Page 4] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 7. Security Considerations This document specifies the ability to advertise additional node capabilities using IS-IS and BGP-LS. As such, the security considerations as described in [RFC7981], [RFC7752], [RFC7794], [RFC8491], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this document. Incorrectly setting the E flag during origination, propagation or redistribution may lead to poor or no load-balancing of the MPLS traffic or black-holing of the MPLS traffic on the egress node. Incorrectly setting of the ERLD value may lead to poor or no load- balancing of the MPLS traffic. 8. Contributors The following people contributed to the content of this document and should be considered as co-authors: Gunter Van de Velde (editor) Nokia Antwerp BE Email: gunter.van_de_velde@nokia.com Wim Henderickx Nokia Belgium Email: wim.henderickx@nokia.com Keyur Patel Arrcus USA Email: keyur@arrcus.com Xu, et al. Expires November 29, 2020 [Page 5] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 9. Acknowledgements The authors would like to thank Yimin Shen, George Swallow, Acee Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura, Bruno Decraene Carlos Pignataro, Wim Hendrickx, and Gunter Van De Velde for their valuable comments. 10. References 10.1. Normative References [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 (work in progress), June 2019. [I-D.ietf-idr-bgp-ls-segment-routing-msd] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State", draft-ietf- idr-bgp-ls-segment-routing-msd-18 (work in progress), May 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, DOI 10.17487/RFC5302, October 2008, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . Xu, et al. Expires November 29, 2020 [Page 6] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, . [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels", RFC 8662, DOI 10.17487/RFC8662, December 2019, . 10.2. Informative References [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . Authors' Addresses Xiaohu Xu Alibaba Inc Email: xiaohu.xxh@alibaba-inc.com Xu, et al. Expires November 29, 2020 [Page 7] Internet-Draft Signaling ELC and ERLD using IS-IS May 2020 Sriganesh Kini Email: sriganeshkini@gmail.com Peter Psenak Cisco Systems, Inc. Eurovea Centre, Central 3 Pribinova Street 10 Bratislava 81109 Slovakia Email: ppsenak@cisco.com Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Stephane Litkowski Cisco Systems, Inc. La Rigourdiere Cesson Sevigne France Email: slitkows@cisco.com Matthew Bocci Nokia Shoppenhangers Road Maidenhead, Berks UK Email: matthew.bocci@nokia.com Xu, et al. Expires November 29, 2020 [Page 8] ./draft-ietf-bfd-yang-17.txt0000644000764400076440000043360113330605404015054 0ustar iustyiusty Network Working Group R. Rahman, Ed. Internet-Draft Cisco Systems Intended status: Standards Track L. Zheng, Ed. Expires: February 2, 2019 Huawei Technologies M. Jethanandani, Ed. Xoriant Corporation S. Pallagatti Rtbrick G. Mirsky ZTE Corporation August 1, 2018 YANG Data Model for Bidirectional Forwarding Detection (BFD) draft-ietf-bfd-yang-17 Abstract This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 2, 2019. Copyright Notice Copyright (c) 2018 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 Rahman, et al. Expires February 2, 2019 [Page 1] Internet-Draft BFD YANG August 2018 (https://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 2.1. Design of Configuration Model . . . . . . . . . . . . . . 5 2.1.1. Common BFD configuration parameters . . . . . . . . . 6 2.1.2. Single-hop IP . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Multihop IP . . . . . . . . . . . . . . . . . . . . . 7 2.1.4. MPLS Traffic Engineering Tunnels . . . . . . . . . . 8 2.1.5. MPLS Label Switched Paths . . . . . . . . . . . . . . 9 2.1.6. Link Aggregation Groups . . . . . . . . . . . . . . . 9 2.2. Design of Operational State Model . . . . . . . . . . . . 9 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 2.4. RPC Operations . . . . . . . . . . . . . . . . . . . . . 10 2.5. BFD top level hierarchy . . . . . . . . . . . . . . . . . 10 2.6. BFD IP single-hop hierarchy . . . . . . . . . . . . . . . 10 2.7. BFD IP multihop hierarchy . . . . . . . . . . . . . . . . 12 2.8. BFD over LAG hierarchy . . . . . . . . . . . . . . . . . 14 2.9. BFD over MPLS LSPs hierarchy . . . . . . . . . . . . . . 18 2.10. BFD over MPLS-TE hierarchy . . . . . . . . . . . . . . . 20 2.11. Interaction with other YANG modules . . . . . . . . . . . 22 2.11.1. Module ietf-interfaces . . . . . . . . . . . . . . . 22 2.11.2. Module ietf-ip . . . . . . . . . . . . . . . . . . . 22 2.11.3. Module ietf-mpls . . . . . . . . . . . . . . . . . . 23 2.11.4. Module ietf-te . . . . . . . . . . . . . . . . . . . 23 2.12. IANA BFD YANG Module . . . . . . . . . . . . . . . . . . 23 2.13. BFD types YANG Module . . . . . . . . . . . . . . . . . . 26 2.14. BFD top-level YANG Module . . . . . . . . . . . . . . . . 39 2.15. BFD IP single-hop YANG Module . . . . . . . . . . . . . . 41 2.16. BFD IP multihop YANG Module . . . . . . . . . . . . . . . 44 2.17. BFD over LAG YANG Module . . . . . . . . . . . . . . . . 47 2.18. BFD over MPLS YANG Module . . . . . . . . . . . . . . . . 51 2.19. BFD over MPLS-TE YANG Module . . . . . . . . . . . . . . 55 3. Data Model examples . . . . . . . . . . . . . . . . . . . . . 58 3.1. IP single-hop . . . . . . . . . . . . . . . . . . . . . . 58 3.2. IP multihop . . . . . . . . . . . . . . . . . . . . . . . 59 3.3. LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.4. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Rahman, et al. Expires February 2, 2019 [Page 2] Internet-Draft BFD YANG August 2018 4. Security Considerations . . . . . . . . . . . . . . . . . . . 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 5.1. IANA-Maintained iana-bfd-types module . . . . . . . . . . 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 70 7.2. Informative References . . . . . . . . . . . . . . . . . 73 Appendix A. Echo function configuration example . . . . . . . . 73 A.1. Example YANG module for BFD echo function configuration . 74 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 76 B.1. Changes between versions -16 and -17 . . . . . . . . . . 76 B.2. Changes between versions -15 and -16 . . . . . . . . . . 76 B.3. Changes between versions -14 and -15 . . . . . . . . . . 76 B.4. Changes between versions -13 and -14 . . . . . . . . . . 76 B.5. Changes between versions -12 and -13 . . . . . . . . . . 76 B.6. Changes between versions -11 and -12 . . . . . . . . . . 76 B.7. Changes between versions -10 and -11 . . . . . . . . . . 76 B.8. Changes between versions -09 and -10 . . . . . . . . . . 77 B.9. Changes between versions -08 and -09 . . . . . . . . . . 77 B.10. Changes between versions -07 and -08 . . . . . . . . . . 77 B.11. Changes between versions -06 and -07 . . . . . . . . . . 77 B.12. Changes between versions -05 and -06 . . . . . . . . . . 77 B.13. Changes between versions -04 and -05 . . . . . . . . . . 78 B.14. Changes between versions -03 and -04 . . . . . . . . . . 78 B.15. Changes between versions -02 and -03 . . . . . . . . . . 78 B.16. Changes between versions -01 and -02 . . . . . . . . . . 78 B.17. Changes between versions -00 and -01 . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 1. Introduction This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD) [RFC5880]. BFD is a network protocol which is used for liveness detection of arbitrary paths between systems. Some examples of different types of paths over which we have BFD: 1) Two systems directly connected via IP. This is known as BFD over single-hop IP, a.k.a. BFD for IPv4 and IPv6 [RFC5881] 2) Two systems connected via multiple hops as described in BFD for Multiple Hops. [RFC5883] 3) Two systems connected via MPLS Label Switched Paths (LSPs) as described in BFD for MPLS LSP [RFC5884] 4) Two systems connected via a Link Aggregation Group (LAG) interface as described in BFD on LAG Interfaces [RFC7130] Rahman, et al. Expires February 2, 2019 [Page 3] Internet-Draft BFD YANG August 2018 5) Two systems connected via pseudowires (PWs), this is known as Virtual Circuit Connectivity Verification (VCCV) as described in BFD for PW VCCV [RFC5885]. This is not addressed in this document. BFD typically does not operate on its own. Various control protocols, also known as BFD clients, use the services provided by BFD for their own operation as described in Generic Application of BFD [RFC5882]. The obvious candidates which use BFD are those which do not have "hellos" to detect failures, e.g. static routes, and routing protocols whose "hellos" do not support sub-second failure detection, e.g. OSPF and IS-IS. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) [RFC8342]. This means that the data models do not have separate top-level or sibling containers for configuration and operational state data. 1.1. Requirements Language 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Tree Diagrams This document uses the graphical representation of data models defined in [RFC8340]. 2. Design of the Data Model Since BFD is used for liveliness detection of various forwarding paths, there is no uniform key to identify a BFD session, and so the BFD data model is split in multiple YANG modules where each module corresponds to one type of forwarding path. For example, BFD for IP single-hop is in one YANG module and BFD for MPLS-TE is in another YANG module. The main difference between these modules is how a BFD session is uniquely identified, i.e the key for the list containing the BFD sessions for that forwarding path. To avoid duplication of BFD definitions, we have common types and groupings which are used by all the modules. A new control-plane protocol "bfdv1" is defined and a "bfd" container is created under control-plane-protocol as specified in "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349]. This new "bfd" container is augmented by all the YANG modules for their respective specific information: Rahman, et al. Expires February 2, 2019 [Page 4] Internet-Draft BFD YANG August 2018 1. ietf-bfd-ip-sh.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "ip-sh" container for BFD sessions over IP single-hop. 2. ietf-bfd-ip-mh.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "ip-mh" container for BFD sessions over IP multi-hop. 3. ietf-bfd-lag.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "lag" container for BFD sessions over LAG. 4. ietf-bfd-mpls.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "mpls" container for BFD over MPLS LSPs. 5. ietf-bfd-mpls-te.yang augments "/routing/control-plane-protocols/ control-plane-protocol/bfd/" with the "mpls-te" container for BFD over MPLS-TE. BFD can operate in the following contexts: 1. At the network device level 2. In Logical Network Elements as described in YANG Logical Network Element [I-D.ietf-rtgwg-lne-model] 3. In Network Instances as described in YANG Logical Network Element [I-D.ietf-rtgwg-ni-model] When used at the network device level, the BFD YANG model is used "as-is". When the BFD YANG model is used in a Logical Network Element or in a Network Instance, then the BFD YANG model augments the mounted routing model for the Logical Network Element or the Network Instance. 2.1. Design of Configuration Model The configuration model consists mainly of the parameters specified in BFD [RFC5880]. Some examples are desired minimum transmit interval, required minimum receive interval, detection multiplier, etc BFD clients are applications that use BFD for fast detection of failures. Some implementations have BFD session configuration under the BFD clients. For example, BFD session configuration under routing applications such as OSPF, IS-IS, BGP etc. Other Rahman, et al. Expires February 2, 2019 [Page 5] Internet-Draft BFD YANG August 2018 implementations have BFD session configuration centralized under BFD, i.e. outside the multiple BFD clients. The BFD parameters of interest to a BFD client are mainly the multiplier and interval(s) since those parameters impact the convergence time of the BFD clients when a failure occurs. Other parameters such as BFD authentication are not specific to the requirements of the BFD client. Ideally all configuration should be centralized under BFD. However, this is a problem for clients of BFD which auto-discover their peers. For example, IGPs do not have the peer address configured, instead the IGP is enabled on an interface and the IGP peers are auto-discovered. So for an operator to configure BFD to an IGP peer, the operator would first have to determine the peer addresses. And when a new peer is discovered, BFD configuration would need to be added. To avoid this issue, we define grouping client-cfg-parms in Section 2.13 for BFD clients to configure BFD: this allows BFD clients such as the IGPs to have configuration (multiplier and intervals) for the BFD sessions they need. For example, when a new IGP peer is discovered, the IGP would create a BFD session to the newly discovered peer and similarly when an IGP peer goes away, the IGP would remove the BFD session to that peer. The mechanism how the BFD sessions are created and removed by the BFD clients is outside the scope of this document, but typically this would be done by use of an API implemented by the BFD module on the system. For BFD clients which create BFD sessions via their own configuration, authentication parameters (if required) are still specified in BFD. 2.1.1. Common BFD configuration parameters The basic BFD configuration parameters are: local-multiplier This is the detection time multiplier as defined in BFD [RFC5880]. desired-min-tx-interval This is the Desired Min TX Interval as defined in BFD [RFC5880]. required-min-rx-interval This is the Required Min RX Interval as defined in BFD [RFC5880]. Although BFD [RFC5880] allows for different values for transmit and receive intervals, some implementations allow users to specify just one interval which is used for both transmit and receive intervals or separate values for transmit and receive intervals. The BFD YANG Rahman, et al. Expires February 2, 2019 [Page 6] Internet-Draft BFD YANG August 2018 model supports this: there is a choice between "min-interval", used for both transmit and receive intervals, and "desired-min-tx- interval" and "required-min-rx-interval". This is supported via a grouping which is used by the YANG modules for the various forwarding paths. For BFD authentication we have: key-chain This is a reference to key-chain defined in YANG Data Model for Key Chains [RFC8177]. The keys, cryptographic algorithms, key lifetime etc are all defined in the key-chain model. meticulous This enables meticulous mode as per BFD [RFC5880]. 2.1.2. Single-hop IP For single-hop IP, there is an augment of the "bfd" data node in Section 2. The "ip-sh" node contains a list of IP single-hop sessions where each session is uniquely identified by the interface and destination address pair. For the configuration parameters we use what is defined in Section 2.1.1. The "ip-sh" node also contains a list of interfaces, this is used to specify authentication parameters for BFD sessions which are created by BFD clients, see Section 2.1. [RFC5880] and [RFC5881] do not specify whether echo function is continuous or on demand. Therefore the mechanism used to start and stop echo function is implementation specific and should be done by augmentation: 1) Configuration. This is suitable for continuous echo function. An example is provided in Appendix A. 2) RPC. This is suitable for on-demand echo function. 2.1.3. Multihop IP For multihop IP, there is an augment of the "bfd" data node in Section 2. Because of multiple paths, there could be multiple multihop IP sessions between a source and a destination address. We identify this as a "session-group". The key for each "session-group" consists of: Rahman, et al. Expires February 2, 2019 [Page 7] Internet-Draft BFD YANG August 2018 source address Address belonging to the local system as per BFD for Multiple Hops [RFC5883] destination address Address belonging to the remote system as per BFD for Multiple Hops [RFC5883] For the configuration parameters we use what is defined in Section 2.1.1 Here are some extra parameters: tx-ttl TTL of outgoing BFD control packets. rx-ttl Minimum TTL of incoming BFD control packets. 2.1.4. MPLS Traffic Engineering Tunnels For MPLS-TE tunnels, BFD is configured under the MPLS-TE tunnel since the desired failure detection parameters are a property of the MPLS- TE tunnel. This is achieved by augmenting the MPLS-TE data model in YANG Data Model for TE Topologies [I-D.ietf-teas-yang-te]. For BFD parameters which are specific to the TE application, e.g. whether to tear down the tunnel in the event of a BFD session failure, these parameters will be defined in the YANG model of the MPLS-TE application. On top of the usual BFD parameters, we have the following per MPLS-TE tunnel: encap Encapsulation for the BFD packets: choice between IP, G-ACh and IP with G-ACh as per MPLS Generic Associated Channel [RFC5586] For general MPLS-TE data, "mpls-te" data node is added under the "bfd" node in Section 2. Since some MPLS-TE tunnels are uni- directional there is no MPLS-TE configuration for these tunnels on the egress node (note that this does not apply to bi-directional MPLS-TP tunnels). The BFD parameters for the egress node are added under "mpls-te". Rahman, et al. Expires February 2, 2019 [Page 8] Internet-Draft BFD YANG August 2018 2.1.5. MPLS Label Switched Paths Here we address MPLS LSPs whose FEC is an IP address. The "bfd" node in Section 2 is augmented with "mpls" which contains a list of sessions uniquely identified by an IP prefix. Because of multiple paths, there could be multiple MPLS sessions to an MPLS FEC. We identify this as a "session-group". Since these LSPs are uni-directional there is no LSP configuration on the egress node. The BFD parameters for the egress node are added under "mpls". 2.1.6. Link Aggregation Groups Per BFD on LAG Interfaces [RFC7130], configuring BFD on LAG consists of having micro-BFD sessions on each LAG member link. Since the BFD parameters are an attribute of the LAG, they should be under the LAG. However there is no LAG YANG model which we can augment. So a "lag" data node is added to the "bfd" node in Section 2, the configuration is per-LAG: we have a list of LAGs. The destination IP address of the micro-BFD sessions is configured per-LAG and per address-family (IPv4 and IPv6) 2.2. Design of Operational State Model The operational state model contains both the overall statistics of BFD sessions running on the device and the per session operational information. The overall statistics of BFD sessions consist of number of BFD sessions, number of BFD sessions up etc. This information is available globally (i.e. for all BFD sessions) under the "bfd" node in Section 2 and also per type of forwarding path. For each BFD session, mainly three categories of operational state data are shown. The fundamental information of a BFD session such as the local discriminator, remote discriminator and the capability of supporting demand detect mode are shown in the first category. The second category includes a BFD session running information, e.g. the remote BFD state and the diagnostic code received. Another example is the actual transmit interval between the control packets, which may be different from the desired minimum transmit interval configured, is shown in this category. Similar examples are actual received interval between the control packets and the actual transmit interval between the echo packets. The third category contains the detailed statistics of the session, e.g. when the session transitioned up/down and how long it has been in that state. Rahman, et al. Expires February 2, 2019 [Page 9] Internet-Draft BFD YANG August 2018 For some path types, there may be more than 1 session on the virtual path to the destination. For example, with IP multihop and MPLS LSPs, there could be multiple BFD sessions from the source to the same destination to test the various paths (ECMP) to the destination. This is represented by having multiple "sessions" under each "session-group". 2.3. Notifications This YANG model defines notifications to inform end-users of important events detected during the protocol operation. Pair of local and remote discriminator identifies a BFD session on local system. Notifications also give more important details about BFD sessions; e.g. new state, time in previous state, network-instance and the reason that the BFD session state changed. The notifications are defined for each type of forwarding path but use groupings for common information. 2.4. RPC Operations None. 2.5. BFD top level hierarchy At the "bfd" node under control-plane-protocol, there is no configuration data, only operational state data. The operational state data consist of overall BFD session statistics, i.e. for BFD on all types of forwarding paths. module: ietf-bfd augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw bfd +--ro summary +--ro number-of-sessions? yang:gauge32 +--ro number-of-sessions-up? yang:gauge32 +--ro number-of-sessions-down? yang:gauge32 +--ro number-of-sessions-admin-down? yang:gauge32 2.6. BFD IP single-hop hierarchy An "ip-sh" node is added under "bfd" node in control-plane-protocol. The configuration and operational state data for each BFD IP single- hop session is under this "ip-sh" node. module: ietf-bfd-ip-sh Rahman, et al. Expires February 2, 2019 [Page 10] Internet-Draft BFD YANG August 2018 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw ip-sh +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw sessions | +--rw session* [interface dest-addr] | +--rw interface if:interface-ref | +--rw dest-addr inet:ip-address | +--rw source-addr? inet:ip-address | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw demand-enabled? boolean | | {demand-mode}? | +--rw admin-down? boolean | +--rw authentication! {authentication}? | | +--rw key-chain? kc:key-chain-ref | | +--rw meticulous? boolean | +--ro path-type? identityref | +--ro ip-encapsulation? boolean | +--ro local-discriminator? discriminator | +--ro remote-discriminator? discriminator | +--ro remote-multiplier? multiplier | +--ro demand-capability? boolean | | {demand-mode}? | +--ro source-port? inet:port-number | +--ro dest-port? inet:port-number | +--ro session-running | | +--ro session-index? uint32 | | +--ro local-state? state | | +--ro remote-state? state | | +--ro local-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-authenticated? boolean | | +--ro remote-authentication-type? | | | iana-bfd-types:auth-type {authentication}? | | +--ro detection-mode? enumeration | | +--ro negotiated-tx-interval? uint32 Rahman, et al. Expires February 2, 2019 [Page 11] Internet-Draft BFD YANG August 2018 | | +--ro negotiated-rx-interval? uint32 | | +--ro detection-time? uint32 | | +--ro echo-tx-interval-in-use? uint32 | | {echo-mode}? | +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? yang:counter32 | +--ro admin-down-count? yang:counter32 | +--ro receive-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64 +--rw interfaces* [interface] +--rw interface if:interface-ref +--rw authentication! {authentication}? +--rw key-chain? kc:key-chain-ref +--rw meticulous? boolean notifications: +---n singlehop-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro interface? if:interface-ref +--ro echo-enabled? boolean 2.7. BFD IP multihop hierarchy An "ip-mh" node is added under the "bfd" node in cntrol-plane- protocol. The configuration and operational state data for each BFD IP multihop session is under this "ip-mh" node. In the operational state model we support multiple BFD multihop sessions per remote address (ECMP), the local discriminator is used as key. module: ietf-bfd-ip-mh Rahman, et al. Expires February 2, 2019 [Page 12] Internet-Draft BFD YANG August 2018 augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw ip-mh +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw session-groups +--rw session-group* [source-addr dest-addr] +--rw source-addr inet:ip-address +--rw dest-addr inet:ip-address +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw tx-ttl? bfd-types:hops +--rw rx-ttl bfd-types:hops +--ro sessions* [] +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type {authentication}? | +--ro detection-mode? enumeration Rahman, et al. Expires February 2, 2019 [Page 13] Internet-Draft BFD YANG August 2018 | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics +--ro create-time? | yang:date-and-time +--ro last-down-time? | yang:date-and-time +--ro last-up-time? | yang:date-and-time +--ro down-count? | yang:counter32 +--ro admin-down-count? | yang:counter32 +--ro receive-packet-count? | yang:counter64 +--ro send-packet-count? | yang:counter64 +--ro receive-invalid-packet-count? | yang:counter64 +--ro send-failed-packet-count? yang:counter64 notifications: +---n multihop-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref 2.8. BFD over LAG hierarchy A "lag" node is added under the "bfd" node in control-plane-protocol. The configuration and operational state data for each BFD LAG session is under this "lag" node. module: ietf-bfd-lag augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw lag Rahman, et al. Expires February 2, 2019 [Page 14] Internet-Draft BFD YANG August 2018 +--rw micro-bfd-ipv4-session-statistics | +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw micro-bfd-ipv6-session-statistics | +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw sessions +--rw session* [lag-name] +--rw lag-name if:interface-ref +--rw ipv4-dest-addr? | inet:ipv4-address +--rw ipv6-dest-addr? | inet:ipv6-address +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw use-ipv4? boolean +--rw use-ipv6? boolean +--ro member-links* [member-link] +--ro member-link if:interface-ref +--ro micro-bfd-ipv4 | +--ro path-type? identityref | +--ro ip-encapsulation? boolean | +--ro local-discriminator? discriminator | +--ro remote-discriminator? discriminator | +--ro remote-multiplier? multiplier | +--ro demand-capability? boolean | | {demand-mode}? | +--ro source-port? inet:port-number | +--ro dest-port? inet:port-number | +--ro session-running | | +--ro session-index? uint32 Rahman, et al. Expires February 2, 2019 [Page 15] Internet-Draft BFD YANG August 2018 | | +--ro local-state? state | | +--ro remote-state? state | | +--ro local-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-authenticated? boolean | | +--ro remote-authentication-type? | | | iana-bfd-types:auth-type | | | {authentication}? | | +--ro detection-mode? enumeration | | +--ro negotiated-tx-interval? uint32 | | +--ro negotiated-rx-interval? uint32 | | +--ro detection-time? uint32 | | +--ro echo-tx-interval-in-use? uint32 | | {echo-mode}? | +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? | | yang:counter32 | +--ro admin-down-count? | | yang:counter32 | +--ro receive-packet-count? | | yang:counter64 | +--ro send-packet-count? | | yang:counter64 | +--ro receive-invalid-packet-count? | | yang:counter64 | +--ro send-failed-packet-count? | yang:counter64 +--ro micro-bfd-ipv6 +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean | {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state Rahman, et al. Expires February 2, 2019 [Page 16] Internet-Draft BFD YANG August 2018 | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type | | {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics +--ro create-time? | yang:date-and-time +--ro last-down-time? | yang:date-and-time +--ro last-up-time? | yang:date-and-time +--ro down-count? | yang:counter32 +--ro admin-down-count? | yang:counter32 +--ro receive-packet-count? | yang:counter64 +--ro send-packet-count? | yang:counter64 +--ro receive-invalid-packet-count? | yang:counter64 +--ro send-failed-packet-count? yang:counter64 notifications: +---n lag-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro lag-name? if:interface-ref +--ro member-link? if:interface-ref Rahman, et al. Expires February 2, 2019 [Page 17] Internet-Draft BFD YANG August 2018 2.9. BFD over MPLS LSPs hierarchy An "mpls" node is added under the "bfd" node in control-plane- protocol. The configuration is per MPLS FEC under this "mpls" node. In the operational state model we support multiple BFD sessions per MPLS FEC (ECMP), the local discriminator is used as key. The "mpls" node can be used in a network device (top-level), or mounted in an LNE or in a network instance. module: ietf-bfd-mpls augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw mpls +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw egress | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw session-groups +--rw session-group* [mpls-fec] +--rw mpls-fec inet:ip-prefix +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--ro sessions* [] Rahman, et al. Expires February 2, 2019 [Page 18] Internet-Draft BFD YANG August 2018 +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? | | yang:counter32 | +--ro admin-down-count? | | yang:counter32 | +--ro receive-packet-count? | | yang:counter64 | +--ro send-packet-count? | | yang:counter64 | +--ro receive-invalid-packet-count? | | yang:counter64 | +--ro send-failed-packet-count? | yang:counter64 +--ro mpls-dest-address? inet:ip-address notifications: +---n mpls-notification Rahman, et al. Expires February 2, 2019 [Page 19] Internet-Draft BFD YANG August 2018 +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro mpls-dest-address? inet:ip-address 2.10. BFD over MPLS-TE hierarchy YANG Data Model for TE Topologies [I-D.ietf-teas-yang-te] is augmented. BFD is configured per MPLS-TE tunnel, and BFD session operational state data is provided per MPLS-TE LSP. module: ietf-bfd-mpls-te augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw mpls-te +--rw egress | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--ro summary +--ro number-of-sessions? yang:gauge32 +--ro number-of-sessions-up? yang:gauge32 +--ro number-of-sessions-down? yang:gauge32 +--ro number-of-sessions-admin-down? yang:gauge32 augment /te:te/te:tunnels/te:tunnel: +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean {demand-mode}? Rahman, et al. Expires February 2, 2019 [Page 20] Internet-Draft BFD YANG August 2018 +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? kc:key-chain-ref | +--rw meticulous? boolean +--rw encap? identityref augment /te:te/te:lsps-state/te:lsp: +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? iana-bfd-types:diagnostic | +--ro remote-diagnostic? iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? iana-bfd-types:auth-type | | {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 {echo-mode}? +--ro session-statistics | +--ro create-time? yang:date-and-time | +--ro last-down-time? yang:date-and-time | +--ro last-up-time? yang:date-and-time | +--ro down-count? yang:counter32 | +--ro admin-down-count? yang:counter32 | +--ro receive-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64 +--ro mpls-dest-address? inet:ip-address notifications: +---n mpls-te-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address Rahman, et al. Expires February 2, 2019 [Page 21] Internet-Draft BFD YANG August 2018 +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro mpls-dest-address? inet:ip-address +--ro tunnel-name? string 2.11. Interaction with other YANG modules Generic YANG Data Model for Connectionless OAM protocols [I-D.ietf-lime-yang-connectionless-oam] describes how the LIME connectionless OAM model could be extended to support BFD. Also, the operation of the BFD data model depends on configuration parameters that are defined in other YANG modules. 2.11.1. Module ietf-interfaces The following boolean configuration is defined in A YANG Data Model for Interface Management [RFC8343]: /if:interfaces/if:interface/if:enabled If this configuration is set to "false", no BFD packets can be transmitted or received on that interface. 2.11.2. Module ietf-ip The following boolean configuration is defined in A YANG Data Model for IP Management [RFC8344]: /if:interfaces/if:interface/ip:ipv4/ip:enabled If this configuration is set to "false", no BFD IPv4 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv4/ip:forwarding If this configuration is set to "false", no BFD IPv4 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv6/ip:enabled If this configuration is set to "false", no BFD IPv6 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv6/ip:forwarding If this configuration is set to "false", no BFD IPv6 packets can be transmitted or received on that interface. Rahman, et al. Expires February 2, 2019 [Page 22] Internet-Draft BFD YANG August 2018 2.11.3. Module ietf-mpls The following boolean configuration is defined in A YANG Data Model for MPLS Base [I-D.ietf-mpls-base-yang]: /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled If this configuration is set to "false", no BFD MPLS packets can be transmitted or received on that interface. 2.11.4. Module ietf-te The following configuration is defined in the "ietf-te" YANG module YANG Data Model for TE Topology [I-D.ietf-teas-yang-te]: /ietf-te:te/ietf-te:tunnels/ietf-te:tunnel/ietf-te:config/ietf- te:admin-status If this configuration is not set to "state-up", no BFD MPLS packets can be transmitted or received on that tunnel. 2.12. IANA BFD YANG Module file "iana-bfd-types@2018-08-01.yang" module iana-bfd-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types"; prefix "iana-bfd-types"; organization "IANA"; contact " Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 823 9358 "; description "This module defines YANG data types for IANA-registered BFD parameters. Rahman, et al. Expires February 2, 2019 [Page 23] Internet-Draft BFD YANG August 2018 This YANG module is maintained by IANA and reflects the 'BFD Diagnostic Codes' and 'BFD Authentication Types' registries. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove // this note reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: IANA BFD YANG Data Types."; } /* * Type Definitions */ typedef diagnostic { type enumeration { enum none { value 0; description "None"; } enum control-expiry { value 1; description "Control timer expiry"; } enum echo-failed { value 2; description "Echo failure"; } enum neighbor-down { value 3; description "Neighbor down"; } enum forwarding-reset { Rahman, et al. Expires February 2, 2019 [Page 24] Internet-Draft BFD YANG August 2018 value 4; description "Forwarding reset"; } enum path-down { value 5; description "Path down"; } enum concatenated-path-down { value 6; description "Concatenated path down"; } enum admin-down { value 7; description "Admin down"; } enum reverse-concatenated-path-down { value 8; description "Reverse concatenated path down"; } enum mis-connectivity-defect { value 9; description "Mis-connectivity defect as specified in RFC6428"; } } description "BFD diagnostic as defined in RFC 5880, values are maintained in the 'BFD Diagnostic Codes' IANA registry. Range is 0 to 31."; } typedef auth-type { type enumeration { enum reserved { value 0; description "Reserved"; } enum simple-password { value 1; description "Simple password"; } enum keyed-md5 { value 2; description "Keyed MD5"; } enum meticulous-keyed-md5 { value 3; description "Meticulous keyed MD5"; } enum keyed-sha1 { Rahman, et al. Expires February 2, 2019 [Page 25] Internet-Draft BFD YANG August 2018 value 4; description "Keyed SHA1"; } enum meticulous-keyed-sha1 { value 5; description "Meticulous keyed SHA1"; } } description "BFD authentication type as defined in RFC 5880, values are maintained in the 'BFD Authentication Types' IANA registry. Range is 0 to 255."; } } 2.13. BFD types YANG Module This YANG module imports typedefs from [RFC6991], [RFC8177] and the "control-plane-protocol" identity from [RFC8349]. file "ietf-bfd-types@2018-08-01.yang" module ietf-bfd-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types"; prefix "bfd-types"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import iana-bfd-types { prefix "iana-bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; Rahman, et al. Expires February 2, 2019 [Page 26] Internet-Draft BFD YANG August 2018 } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } import ietf-key-chain { prefix "kc"; reference "RFC 8177: YANG Data Model for Key Chains"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains a collection of BFD specific YANG data type definitions, as per RFC 5880, and also groupings which are common to other BFD YANG modules. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for BFD"; } Rahman, et al. Expires February 2, 2019 [Page 27] Internet-Draft BFD YANG August 2018 /* * Feature definitions */ feature single-minimum-interval { description "This feature indicates that the server supports configuration of one minimum interval value which is used for both transmit and receive minimum intervals."; } feature authentication { description "This feature indicates that the server supports BFD authentication."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), section 6.7."; } feature demand-mode { description "This feature indicates that the server supports BFD demand mode."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), section 6.6."; } feature echo-mode { description "This feature indicates that the server supports BFD echo mode."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), section 6.4."; } /* * Identity definitions */ identity bfdv1 { base "rt:control-plane-protocol"; description "BFD protocol version 1."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)."; } identity path-type { Rahman, et al. Expires February 2, 2019 [Page 28] Internet-Draft BFD YANG August 2018 description "Base identity for BFD path type. The path type indicates the type of path on which BFD is running."; } identity path-ip-sh { base path-type; description "BFD on IP single hop."; reference "RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)."; } identity path-ip-mh { base path-type; description "BFD on IP multihop paths."; reference "RFC 5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths."; } identity path-mpls-te { base path-type; description "BFD on MPLS Traffic Engineering."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)."; } identity path-mpls-lsp { base path-type; description "BFD on MPLS Label Switched Path."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)."; } identity path-lag { base path-type; description "Micro-BFD on LAG member links."; reference "RFC 7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces."; } identity encap-type { description "Base identity for BFD encapsulation type."; } identity encap-ip { Rahman, et al. Expires February 2, 2019 [Page 29] Internet-Draft BFD YANG August 2018 base encap-type; description "BFD with IP encapsulation."; } /* * Type Definitions */ typedef discriminator { type uint32; description "BFD discriminator as described in RFC 5880."; } typedef state { type enumeration { enum adminDown { value 0; description "admindown"; } enum down { value 1; description "down"; } enum init { value 2; description "init"; } enum up { value 3; description "up"; } } description "BFD state as defined in RFC 5880."; } typedef multiplier { type uint8 { range 1..255; } description "BFD multiplier as described in RFC 5880."; } typedef hops { type uint8 { range 1..255; } description "This corresponds to Time To Live for IPv4 and corresponds to hop limit for IPv6."; Rahman, et al. Expires February 2, 2019 [Page 30] Internet-Draft BFD YANG August 2018 } /* * Groupings */ grouping auth-parms { description "Grouping for BFD authentication parameters (see section 6.7 of RFC 5880)."; container authentication { if-feature authentication; presence "Enables BFD authentication (see section 6.7 of RFC 5880)."; description "Parameters for BFD authentication."; leaf key-chain { type kc:key-chain-ref; description "Name of the key-chain as per RFC 8177."; } leaf meticulous { type boolean; description "Enables meticulous mode as described in section 6.7 " + "of RFC 5880."; } } } grouping base-cfg-parms { description "BFD grouping for base config parameters."; leaf local-multiplier { type multiplier; default 3; description "Multiplier transmitted by local system."; } choice interval-config-type { description "Two interval values or one value used for both transmit and receive."; case tx-rx-intervals { leaf desired-min-tx-interval { type uint32; units microseconds; default 1000000; description "Desired minimum transmit interval of control packets."; Rahman, et al. Expires February 2, 2019 [Page 31] Internet-Draft BFD YANG August 2018 } leaf required-min-rx-interval { type uint32; units microseconds; default 1000000; description "Required minimum receive interval of control packets."; } } case single-interval { if-feature single-minimum-interval; leaf min-interval { type uint32; units microseconds; default 1000000; description "Desired minimum transmit interval and required " + "minimum receive interval of control packets."; } } } } grouping client-cfg-parms { description "BFD grouping for configuration parameters used by clients of BFD, e.g. IGP or MPLS."; leaf enable { type boolean; default false; description "Indicates whether the BFD is enabled."; } uses base-cfg-parms; } grouping common-cfg-parms { description "BFD grouping for common configuration parameters."; uses base-cfg-parms; leaf demand-enabled { if-feature demand-mode; type boolean; Rahman, et al. Expires February 2, 2019 [Page 32] Internet-Draft BFD YANG August 2018 default false; description "To enable demand mode."; } leaf admin-down { type boolean; default false; description "Is the BFD session administratively down."; } uses auth-parms; } grouping all-session { description "BFD session operational information"; leaf path-type { type identityref { base path-type; } config "false"; description "BFD path type, this indicates the path type that BFD is running on."; } leaf ip-encapsulation { type boolean; config "false"; description "Whether BFD encapsulation uses IP."; } leaf local-discriminator { type discriminator; config "false"; description "Local discriminator."; } leaf remote-discriminator { type discriminator; config "false"; description "Remote discriminator."; } leaf remote-multiplier { type multiplier; config "false"; description "Remote multiplier."; } leaf demand-capability { if-feature demand-mode; type boolean; Rahman, et al. Expires February 2, 2019 [Page 33] Internet-Draft BFD YANG August 2018 config "false"; description "Local demand mode capability."; } leaf source-port { when "../ip-encapsulation = 'true'" { description "Source port valid only when IP encapsulation is used."; } type inet:port-number; config "false"; description "Source UDP port"; } leaf dest-port { when "../ip-encapsulation = 'true'" { description "Destination port valid only when IP encapsulation is used."; } type inet:port-number; config "false"; description "Destination UDP port."; } container session-running { config "false"; description "BFD session running information."; leaf session-index { type uint32; description "An index used to uniquely identify BFD sessions."; } leaf local-state { type state; description "Local state."; } leaf remote-state { type state; description "Remote state."; } leaf local-diagnostic { type iana-bfd-types:diagnostic; description "Local diagnostic."; } leaf remote-diagnostic { type iana-bfd-types:diagnostic; description "Remote diagnostic."; } leaf remote-authenticated { type boolean; Rahman, et al. Expires February 2, 2019 [Page 34] Internet-Draft BFD YANG August 2018 description "Indicates whether incoming BFD control packets are authenticated."; } leaf remote-authentication-type { when "../remote-authenticated = 'true'" { description "Only valid when incoming BFD control packets are authenticated."; } if-feature authentication; type iana-bfd-types:auth-type; description "Authentication type of incoming BFD control packets."; } leaf detection-mode { type enumeration { enum async-with-echo { value "1"; description "Async with echo."; } enum async-without-echo { value "2"; description "Async without echo."; } enum demand-with-echo { value "3"; description "Demand with echo."; } enum demand-without-echo { value "4"; description "Demand without echo."; } } description "Detection mode."; } leaf negotiated-tx-interval { type uint32; units microseconds; description "Negotiated transmit interval."; } leaf negotiated-rx-interval { type uint32; units microseconds; description "Negotiated receive interval."; } leaf detection-time { type uint32; Rahman, et al. Expires February 2, 2019 [Page 35] Internet-Draft BFD YANG August 2018 units microseconds; description "Detection time."; } leaf echo-tx-interval-in-use { when "../../path-type = 'bfd-types:path-ip-sh'" { description "Echo is supported for IP single-hop only."; } if-feature echo-mode; type uint32; units microseconds; description "Echo transmit interval in use."; } } container session-statistics { config "false"; description "BFD per-session statistics."; leaf create-time { type yang:date-and-time; description "Time and date when this session was created."; } leaf last-down-time { type yang:date-and-time; description "Time and date of last time this session went down."; } leaf last-up-time { type yang:date-and-time; description "Time and date of last time this session went up."; } leaf down-count { type yang:counter32; description "The number of times this session has transitioned in the down state."; } leaf admin-down-count { type yang:counter32; description "The number of times this session has transitioned in the admin-down state."; } leaf receive-packet-count { type yang:counter64; Rahman, et al. Expires February 2, 2019 [Page 36] Internet-Draft BFD YANG August 2018 description "Count of received packets in this session. This includes valid and invalid received packets."; } leaf send-packet-count { type yang:counter64; description "Count of sent packets in this session."; } leaf receive-invalid-packet-count { type yang:counter64; description "Count of invalid received packets in this session."; } leaf send-failed-packet-count { type yang:counter64; description "Count of packets which failed to be sent in this session."; } } } grouping session-statistics-summary { description "Grouping for session statistics summary."; container summary { config false; description "BFD session statistics summary."; leaf number-of-sessions { type yang:gauge32; description "Number of BFD sessions."; } leaf number-of-sessions-up { type yang:gauge32; description "Number of BFD sessions currently in up state (as defined in RFC 5880)."; } leaf number-of-sessions-down { type yang:gauge32; description "Number of BFD sessions currently in down or init state but not admin-down (as defined in RFC 5880)."; } leaf number-of-sessions-admin-down { type yang:gauge32; description "Number of BFD sessions currently in admin-down state (as defined in RFC 5880)."; } Rahman, et al. Expires February 2, 2019 [Page 37] Internet-Draft BFD YANG August 2018 } } grouping notification-parms { description "This group describes common parameters that will be sent " + "as part of BFD notification."; leaf local-discr { type discriminator; description "BFD local discriminator."; } leaf remote-discr { type discriminator; description "BFD remote discriminator."; } leaf new-state { type state; description "Current BFD state."; } leaf state-change-reason { type iana-bfd-types:diagnostic; description "BFD state change reason."; } leaf time-of-last-state-change { type yang:date-and-time; description "Calendar time of previous state change."; } leaf dest-addr { type inet:ip-address; description "BFD peer address."; } leaf source-addr { type inet:ip-address; description "BFD local address."; } leaf session-index { type uint32; description "An index used to uniquely identify BFD sessions."; } Rahman, et al. Expires February 2, 2019 [Page 38] Internet-Draft BFD YANG August 2018 leaf path-type { type identityref { base path-type; } description "BFD path type."; } } } 2.14. BFD top-level YANG Module This YANG module imports and augments "/routing/control-plane- protocols/control-plane-protocol" from [RFC8349]. file "ietf-bfd@2018-08-01.yang" module ietf-bfd { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd"; prefix "bfd"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Rahman, et al. Expires February 2, 2019 [Page 39] Internet-Draft BFD YANG August 2018 Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD parameters as per RFC 5880. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for BFD"; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" { description "This augmentation is only valid for a control-plane protocol instance of BFD (type 'bfdv1')."; } description "BFD augmentation."; container bfd { description "BFD top level container."; uses bfd-types:session-statistics-summary; } } } Rahman, et al. Expires February 2, 2019 [Page 40] Internet-Draft BFD YANG August 2018 2.15. BFD IP single-hop YANG Module This YANG module imports "interface-ref" from [RFC8343], typedefs from [RFC6991] and augments "/routing/control-plane-protocols/ control-plane-protocol" from [RFC8349]. file "ietf-bfd-ip-sh@2018-08-01.yang" module ietf-bfd-ip-sh { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"; prefix "bfd-ip-sh"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; Rahman, et al. Expires February 2, 2019 [Page 41] Internet-Draft BFD YANG August 2018 contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD IP single-hop as per RFC 5881. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD IP single-hop"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for IP single-hop"; container ip-sh { description "BFD IP single-hop top level container"; uses bfd-types:session-statistics-summary; container sessions { description "BFD IP single-hop sessions."; list session { key "interface dest-addr"; Rahman, et al. Expires February 2, 2019 [Page 42] Internet-Draft BFD YANG August 2018 description "List of IP single-hop sessions."; leaf interface { type if:interface-ref; description "Interface on which the BFD session is running."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } leaf source-addr { type inet:ip-address; description "Local IP address."; } uses bfd-types:common-cfg-parms; uses bfd-types:all-session; } } list interfaces { key "interface"; description "List of interfaces."; leaf interface { type if:interface-ref; description "BFD information for this interface."; } uses bfd-types:auth-parms; } } } /* * Notifications */ notification singlehop-notification { description "Notification for BFD single-hop session state change. An " + "implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; leaf interface { type if:interface-ref; description "Interface to which this BFD session belongs to."; Rahman, et al. Expires February 2, 2019 [Page 43] Internet-Draft BFD YANG August 2018 } leaf echo-enabled { type boolean; description "Was echo enabled for BFD."; } } } 2.16. BFD IP multihop YANG Module This YANG module imports typedefs from [RFC6991] and augments "/routing/control-plane-protocols/control-plane-protocol" from [RFC8349]. file "ietf-bfd-ip-mh@2018-08-01.yang" module ietf-bfd-ip-mh { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh"; prefix "bfd-ip-mh"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; Rahman, et al. Expires February 2, 2019 [Page 44] Internet-Draft BFD YANG August 2018 reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD IP multi-hop as per RFC 5883. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD IP multihop."; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for IP multihop."; container ip-mh { description "BFD IP multihop top level container."; Rahman, et al. Expires February 2, 2019 [Page 45] Internet-Draft BFD YANG August 2018 uses bfd-types:session-statistics-summary; container session-groups { description "BFD IP multi-hop session groups."; list session-group { key "source-addr dest-addr"; description "Group of BFD IP multi-hop sessions (for ECMP). A " + "group of sessions is between 1 source and 1 " + "destination, each session has a different field " + "in UDP/IP hdr for ECMP."; leaf source-addr { type inet:ip-address; description "Local IP address."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } uses bfd-types:common-cfg-parms; leaf tx-ttl { type bfd-types:hops; default 255; description "Hop count of outgoing BFD control packets."; } leaf rx-ttl { type bfd-types:hops; mandatory true; description "Minimum allowed hop count value for incoming BFD control packets. Control packets whose hop count is lower than this value are dropped."; } list sessions { config false; description "The multiple BFD sessions between a source and a " + "destination."; uses bfd-types:all-session; } } } } Rahman, et al. Expires February 2, 2019 [Page 46] Internet-Draft BFD YANG August 2018 } /* * Notifications */ notification multihop-notification { description "Notification for BFD multi-hop session state change. An " + "implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; } } 2.17. BFD over LAG YANG Module This YANG module imports "interface-ref" from [RFC8343], typedefs from [RFC6991] and augments "/routing/control-plane-protocols/ control-plane-protocol" from [RFC8349]. file "ietf-bfd-lag@2018-08-01.yang" module ietf-bfd-lag { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag"; prefix "bfd-lag"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-interfaces { prefix "if"; Rahman, et al. Expires February 2, 2019 [Page 47] Internet-Draft BFD YANG August 2018 reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD over LAG interfaces as per RFC7130. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD over LAG"; Rahman, et al. Expires February 2, 2019 [Page 48] Internet-Draft BFD YANG August 2018 } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for LAG"; container lag { description "BFD over LAG top level container"; container micro-bfd-ipv4-session-statistics { description "Micro-BFD IPv4 session counters."; uses bfd-types:session-statistics-summary; } container micro-bfd-ipv6-session-statistics { description "Micro-BFD IPv6 session counters."; uses bfd-types:session-statistics-summary; } container sessions { description "BFD over LAG sessions"; list session { key "lag-name"; description "List of BFD over LAG sessions."; leaf lag-name { type if:interface-ref ; description "Name of the LAG"; } leaf ipv4-dest-addr { type inet:ipv4-address; description "IPv4 address of the peer, for IPv4 micro-BFD."; } leaf ipv6-dest-addr { type inet:ipv6-address; description "IPv6 address of the peer, for IPv6 micro-BFD."; } uses bfd-types:common-cfg-parms; leaf use-ipv4 { type boolean; description "Using IPv4 micro-BFD."; } leaf use-ipv6 { type boolean; Rahman, et al. Expires February 2, 2019 [Page 49] Internet-Draft BFD YANG August 2018 description "Using IPv6 micro-BFD."; } list member-links { key "member-link"; config false; description "Micro-BFD over LAG. This represents one member link."; leaf member-link { type if:interface-ref; description "Member link on which micro-BFD is running."; } container micro-bfd-ipv4 { when "../../use-ipv4 = 'true'" { description "Needed only if IPv4 is used."; } description "Micro-BFD IPv4 session state on member link."; uses bfd-types:all-session; } container micro-bfd-ipv6 { when "../../use-ipv6 = 'true'" { description "Needed only if IPv6 is used."; } description "Micro-BFD IPv6 session state on member link."; uses bfd-types:all-session; } } } } } } /* * Notifications */ notification lag-notification { description "Notification for BFD over LAG session state change. " + "An implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; leaf lag-name { Rahman, et al. Expires February 2, 2019 [Page 50] Internet-Draft BFD YANG August 2018 type if:interface-ref; description "LAG interface name."; } leaf member-link { type if:interface-ref; description "Member link on which BFD is running."; } } } 2.18. BFD over MPLS YANG Module This YANG module imports typedefs from [RFC6991] and augments "/routing/control-plane-protocols/control-plane-protocol" from [RFC8349]. file "ietf-bfd-mpls@2018-08-01.yang" module ietf-bfd-mpls { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls"; prefix "bfd-mpls"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { Rahman, et al. Expires February 2, 2019 [Page 51] Internet-Draft BFD YANG August 2018 prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD parameters for MPLS LSPs as per RFC 5884. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD over MPLS LSPs"; } /* * Identity definitions */ identity encap-gach { base bfd-types:encap-type; description "BFD with G-ACh encapsulation as per RFC 5586."; } Rahman, et al. Expires February 2, 2019 [Page 52] Internet-Draft BFD YANG August 2018 identity encap-ip-gach { base bfd-types:encap-type; description "BFD with IP and G-ACh encapsulation as per RFC 5586."; } /* * Groupings */ grouping encap-cfg { description "Configuration for BFD encapsulation"; leaf encap { type identityref { base bfd-types:encap-type; } default bfd-types:encap-ip; description "BFD encapsulation"; } } grouping mpls-dest-address { description "Destination address as per RFC 5884."; leaf mpls-dest-address { type inet:ip-address; config "false"; description "Destination address as per RFC 5884. Needed if IP encapsulation is used."; } } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for MPLS."; container mpls { description "BFD MPLS top level container."; uses bfd-types:session-statistics-summary; container egress { description "Egress configuration."; uses bfd-types:client-cfg-parms; Rahman, et al. Expires February 2, 2019 [Page 53] Internet-Draft BFD YANG August 2018 uses bfd-types:auth-parms; } container session-groups { description "BFD over MPLS session groups."; list session-group { key "mpls-fec"; description "Group of BFD MPLS sessions (for ECMP). A group of " + "sessions is for 1 FEC, each session has a different " + "field in UDP/IP hdr for ECMP."; leaf mpls-fec { type inet:ip-prefix; description "MPLS FEC."; } uses bfd-types:common-cfg-parms; list sessions { config false; description "The BFD sessions for an MPLS FEC. Local " + "discriminator is unique for each session in the " + "group."; uses bfd-types:all-session; uses bfd-mpls:mpls-dest-address; } } } } } /* * Notifications */ notification mpls-notification { description "Notification for BFD over MPLS FEC session state change. " + "An implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; leaf mpls-dest-address { type inet:ip-address; description Rahman, et al. Expires February 2, 2019 [Page 54] Internet-Draft BFD YANG August 2018 "Destination address as per RFC 5884. Needed if IP encapsulation is used."; } } } 2.19. BFD over MPLS-TE YANG Module This YANG module imports and augments "/te/tunnels/tunnel" from [I-D.ietf-teas-yang-te]. file "ietf-bfd-mpls-te@2018-08-01.yang" module ietf-bfd-mpls-te { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te"; prefix "bfd-mpls-te"; // RFC Ed.: replace occurences of XXXX with actual RFC number and // remove this note import ietf-bfd-types { prefix "bfd-types"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd { prefix "bfd"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-bfd-mpls { prefix "bfd-mpls"; reference "RFC XXXX: YANG Data Model for BFD"; } import ietf-te { prefix "te"; // RFC Ed.: replace YYYY with actual RFC number of // draft-ietf-teas-yang-te and remove this note. reference "RFC YYYY: A YANG Data Model for Traffic Engineering Tunnels and Interfaces"; Rahman, et al. Expires February 2, 2019 [Page 55] Internet-Draft BFD YANG August 2018 } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains the YANG definition for BFD parameters for MPLS Traffic Engineering as per RFC 5884. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model for BFD over MPLS-TE"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { Rahman, et al. Expires February 2, 2019 [Page 56] Internet-Draft BFD YANG August 2018 description "BFD augmentation for MPLS-TE."; container mpls-te { description "BFD MPLS-TE top level container."; container egress { description "Egress configuration."; uses bfd-types:client-cfg-parms; uses bfd-types:auth-parms; } uses bfd-types:session-statistics-summary; } } augment "/te:te/te:tunnels/te:tunnel" { description "BFD configuration on MPLS-TE tunnel."; uses bfd-types:common-cfg-parms; uses bfd-mpls:encap-cfg; } augment "/te:te/te:lsps-state/te:lsp" { when "/te:te/te:lsps-state/te:lsp/te:origin-type != 'transit'" { description "BFD information not needed at transit points."; } description "BFD state information on MPLS-TE LSP."; uses bfd-types:all-session; uses bfd-mpls:mpls-dest-address; } /* * Notifications */ notification mpls-te-notification { description "Notification for BFD over MPLS-TE session state change. " + "An implementation may rate-limit notifications, e.g. when a " + "session is continuously changing state."; uses bfd-types:notification-parms; uses bfd-mpls:mpls-dest-address; Rahman, et al. Expires February 2, 2019 [Page 57] Internet-Draft BFD YANG August 2018 leaf tunnel-name { type string; description "MPLS-TE tunnel on which BFD was running."; } } } 3. Data Model examples This section presents some simple and illustrative examples on how to configure BFD. 3.1. IP single-hop The following is an example configuration for a BFD IP single-hop session. The desired transmit interval and the required receive interval are both set to 10ms. Rahman, et al. Expires February 2, 2019 [Page 58] Internet-Draft BFD YANG August 2018 eth0 ianaift:ethernetCsmacd bfd-types:bfdv1 name:BFD eth0 2001:db8:0:113::101 10000 10000 3.2. IP multihop The following is an example configuration for a BFD IP multihop session group. The desired transmit interval and the required receive interval are both set to 150ms. Rahman, et al. Expires February 2, 2019 [Page 59] Internet-Draft BFD YANG August 2018 bfd-types:bfdv1 name:BFD 2001:db8:0:113::103 2001:db8:0:114::100 150000 150000 240 3.3. LAG The following is an example of BFD configuration for a LAG session. In this case, an interface named "Bundle-Ether1" of interface type "ieee802eadLag" has a desired transmit and required receive interval set to 10ms. Rahman, et al. Expires February 2, 2019 [Page 60] Internet-Draft BFD YANG August 2018 Bundle-Ether1 ianaift:ieee8023adLag bfd-types:bfdv1 name:BFD Bundle-Ether1 2001:db8:112::16 100000 100000 true 3.4. MPLS The following is an example of BFD configured for an MPLS LSP. In this case, the desired transmit and required receive interval set to 250ms. Rahman, et al. Expires February 2, 2019 [Page 61] Internet-Draft BFD YANG August 2018 bfd-types:bfdv1 name:BFD 2001:db8:114::/116 250000 250000 4. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the Rahman, et al. Expires February 2, 2019 [Page 62] Internet-Draft BFD YANG August 2018 default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ sessions: the list specifies the IP single-hop BFD sessions. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ sessions: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD IP single-hop session. The source-addr and dest-addr data nodes can be used to send BFD packets to unwitting recipients, [RFC5880] describes how BFD mitigates against such threats. Authentication data nodes key-chain and meticulous impact the security of the BFD IP single-hop session. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-group: the list specifies the IP multi-hop BFD session groups. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-group: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD IP multi-hop session. The source-addr and dest-addr data nodes can be used to send BFD packets to unwitting recipients, [RFC5880] describes how BFD mitigates against such threats. Authentication data nodes key-chain and meticulous impact the security of the BFD IP multi-hop session. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ sessions: the list specifies the BFD sessions over LAG. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ sessions: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD over LAG session. The ipv4-dest-addr and ipv6-dest-addr data nodes can be used to send BFD packets to unwitting recipients, [RFC5880] describes how BFD mitigates against such threats. Authentication data nodes key-chain and meticulous impact the security of the BFD over LAG session. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-group: the list specifies the session groups for BFD over MPLS. Rahman, et al. Expires February 2, 2019 [Page 63] Internet-Draft BFD YANG August 2018 /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-group: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval, and min-interval all impact the BFD over MPLS LSPs session. Authentication data nodes key-chain and meticulous impact the security of the BFD over MPLS LSPs session. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ egress: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD over MPLS LSPs sessions for which this device is an MPLS LSP egress node. Authentication data nodes key-chain and meticulous impact the security of the BFD over MPLS LSPs sessions for which this device is an MPLS LSP egress node /te/tunnels/tunnel: data nodes local-multiplier, desired-min-tx- interval, required-min-rx-interval and min-interval all impact the BFD session over the MPLS-TE tunnel. Authentication data nodes key- chain and meticulous impact the security of the BFD session over the MPLS-TE tunnel. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/ egress: data nodes local-multiplier, desired-min-tx-interval, required-min-rx-interval and min-interval all impact the BFD over MPLS-TE sessions for which this device is an MPLS-TE egress node. Authentication data nodes key-chain and meticulous impact the security of the BFD over MPLS-TE sessions for which this device is an MPLS-TE egress node. The YANG module has writeable data nodes which can be used for creation of BFD sessions and modification of BFD session parameters. The system should "police" creation of BFD sessions to prevent new sessions from causing existing BFD sessions to fail. For BFD session modification, the BFD protocol has mechanisms in place which allow for in service modification. When BFD clients are used to modify BFD configuration (as described in Section 2.1), the BFD clients need to be included in an analysis of the security properties of the BFD-using system (e.g., when considering the authentication and authorization of control actions). In many cases, BFD is not the most vulnerable portion of such a composite system, since BFD is limited to generating well-defined traffic at a fixed rate on a given path; in the case of an IGP as BFD client, attacking the IGP could cause more broad-scale disruption than (de)configuring a BFD session could cause. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or Rahman, et al. Expires February 2, 2019 [Page 64] Internet-Draft BFD YANG August 2018 notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ summary: access to this information discloses the number of BFD IP single-hop sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane-protocol/bfd/ip- sh/sessions/session/: access to data nodes local-discriminator and remote-discriminator (combined with the data nodes in the authentication container) provides the ability to spoof BFD IP single-hop packets. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ summary: access to this information discloses the number of BFD IP multi-hop sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-groups/session-group/sessions: access to data nodes local- discriminator and remote-discriminator (combined with the data nodes in the session-group's authentication container) provides the ability to spoof BFD IP multi-hop packets. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ micro-bfd-ipv4-session-statistics/summary: access to this information discloses the number of micro BFD IPv4 LAG sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane- protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd- ipv4: access to data nodes local-discriminator and remote- discriminator (combined with the data nodes in the session's authentication container) provides the ability to spoof BFD IPv4 LAG packets. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ micro-bfd-ipv6-session-statistics/summary: access to this information discloses the number of micro BFD IPv6 LAG sessions which are up, down and admin-down. The counters include BFD sessions for which the user does not have read-access. /routing/control-plane-protocols/control-plane- protocol/bfd/lag/sessions/session/member-links/member-link/micro-bfd- ipv6: access to data nodes local-discriminator and remote- discriminator (combined with the data nodes in the session's Rahman, et al. Expires February 2, 2019 [Page 65] Internet-Draft BFD YANG August 2018 authentication container) provides the ability to spoof BFD IPv6 LAG packets. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ summary: access to this information discloses the number of BFD sessions over MPLS LSPs which are up, down and admin-down. The counters include BFD sessions for which the user does not have read- access. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-groups/session-group/sessions: access to data nodes local- discriminator and remote-discriminator (combined with the data nodes in the session-group's authentication container) provides the ability to spoof BFD over MPLS LSPs packets. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls-te/ summary: access to this information discloses the number of BFD sessions over MPLS-TE which are up, down and admin-down. The counters include BFD sessions for which the user does not have read- access. /te/lsps-state/lsp: access to data nodes local-discriminator and remote-discriminator (combined with the data nodes in the tunnel's authentication container) provides the ability to spoof BFD over MPLS-TE packets. 5. IANA Considerations This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:iana-bfd-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-types Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. Rahman, et al. Expires February 2, 2019 [Page 66] Internet-Draft BFD YANG August 2018 -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mh Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lag Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Registrant Contact: The IESG. Rahman, et al. Expires February 2, 2019 [Page 67] Internet-Draft BFD YANG August 2018 XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC6020]: RFC Editor: Replace RFC XXXX with actual RFC number and remove this note. -------------------------------------------------------------------- Name: iana-bfd-types Namespace: urn:ietf:params:xml:ns:yang:iana-bfd-types Prefix: iana-bfd-types Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-types Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-types Prefix: bfd-types Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd Rahman, et al. Expires February 2, 2019 [Page 68] Internet-Draft BFD YANG August 2018 Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd Prefix: bfd Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-ip-sh Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh Prefix: bfd-ip-sh Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-ip-mh Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh Prefix: bfd-ip-mh Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-lag Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-lag Prefix: bfd-lag Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-mpls Rahman, et al. Expires February 2, 2019 [Page 69] Internet-Draft BFD YANG August 2018 Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Prefix: bfd-mpls Reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- Name: ietf-bfd-mpls-te Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te Prefix: bfd-mpls-te Reference: RFC XXXX -------------------------------------------------------------------- 5.1. IANA-Maintained iana-bfd-types module This document defines the initial version of the IANA-maintained iana-bfd-types YANG module. The iana-bfd-types YANG module mirrors the "BFD Diagnostic Codes" registry and "BFD Authentication Types" registry at https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml. Whenever that registry changes, IANA must update the iana-bfd-types YANG module. 6. Acknowledgements We would also like to thank Nobo Akiya and Jeff Haas for their encouragement on this work. We would also like to thank Rakesh Gandhi and Tarek Saad for their help on the MPLS-TE model. We would also like to thank Acee Lindem for his guidance. 7. References 7.1. Normative References [I-D.ietf-mpls-base-yang] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", draft-ietf-mpls-base- yang-06 (work in progress), February 2018. Rahman, et al. Expires February 2, 2019 [Page 70] Internet-Draft BFD YANG August 2018 [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work in progress), July 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, DOI 10.17487/RFC5882, June 2010, . [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . Rahman, et al. Expires February 2, 2019 [Page 71] Internet-Draft BFD YANG August 2018 [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 2014, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . Rahman, et al. Expires February 2, 2019 [Page 72] Internet-Draft BFD YANG August 2018 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . 7.2. Informative References [I-D.ietf-lime-yang-connectionless-oam] Kumar, D., Wang, Z., Wu, Q., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications", draft-ietf-lime-yang- connectionless-oam-18 (work in progress), November 2017. [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", draft- ietf-rtgwg-lne-model-10 (work in progress), March 2018. [I-D.ietf-rtgwg-ni-model] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Network Instances", draft-ietf-rtgwg- ni-model-12 (work in progress), March 2018. [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Appendix A. Echo function configuration example As mentioned in Section 2.1.2, the mechanism to start and stop the echo function, as defined in [RFC5880] and [RFC5881], is implementation specific. In this section we provide an example of how the echo function can be implemented via configuration. Rahman, et al. Expires February 2, 2019 [Page 73] Internet-Draft BFD YANG August 2018 module: example-bfd-echo augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /bfd-ip-sh:sessions: +--rw echo {bfd-types:echo-mode}? +--rw desired-min-echo-tx-interval? uint32 +--rw required-min-echo-rx-interval? uint32 A.1. Example YANG module for BFD echo function configuration module example-bfd-echo { namespace "tag:example.com,2018:example-bfd-echo"; prefix "example-bfd-echo"; import ietf-bfd-types { prefix "bfd-types"; } import ietf-bfd { prefix "bfd"; } import ietf-bfd-ip-sh { prefix "bfd-ip-sh"; } import ietf-routing { prefix "rt"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editors: Reshad Rahman (rrahman@cisco.com), Lianshu Zheng (vero.zheng@huawei.com), Mahesh Jethanandani (mjethanandani@gmail.com)"; description "This module contains an example YANG augmentation for configuration of BFD echo function. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Rahman, et al. Expires February 2, 2019 [Page 74] Internet-Draft BFD YANG August 2018 Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-08-01 { description "Initial revision."; reference "RFC XXXX: A YANG data model example augmentation for BFD echo function"; } // RFC Ed.: replace XXXX with actual RFC number and remove this // note /* * Groupings */ grouping echo-cfg-parms { description "BFD grouping for echo config parameters"; leaf desired-min-echo-tx-interval { type uint32; units microseconds; default 0; description "This is the minimum interval that the local system would like to use when transmitting BFD echo packets. If 0, the echo function as defined in BFD [RFC5880] is disabled."; } leaf required-min-echo-rx-interval { type uint32; units microseconds; default 0; description "This is the Required Min Echo RX Interval as defined in BFD [RFC5880]."; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "bfd-ip-sh:sessions" { Rahman, et al. Expires February 2, 2019 [Page 75] Internet-Draft BFD YANG August 2018 description "Augmentation for BFD echo function."; container echo { if-feature bfd-types:echo-mode; description "BFD echo function container"; uses echo-cfg-parms; } } } Appendix B. Change log RFC Editor: Remove this section upon publication as an RFC. B.1. Changes between versions -16 and -17 o Addressed IESG comments. B.2. Changes between versions -15 and -16 o Added list of modules for YANG module registry. B.3. Changes between versions -14 and -15 o Added missing ietf-bfd-types in XML registry. B.4. Changes between versions -13 and -14 o Addressed missing/incorrect references in import statements. B.5. Changes between versions -12 and -13 o Updated references for drafts which became RFCs recently. B.6. Changes between versions -11 and -12 o Addressed comments from YANG Doctor review of rev11. B.7. Changes between versions -10 and -11 o Added 2 examples. o Added a container around some lists. o Fixed some indentation nits. Rahman, et al. Expires February 2, 2019 [Page 76] Internet-Draft BFD YANG August 2018 B.8. Changes between versions -09 and -10 o Addressed comments from YANG Doctor review. o Addressed comments from WGLC. B.9. Changes between versions -08 and -09 o Mostly cosmetic changes to abide by draft-ietf-netmod-rfc6087bis. o Specified yang-version 1.1. o Added data model examples. o Some minor changes. B.10. Changes between versions -07 and -08 o Timer intervals in client-cfg-parms are not mandatory anymore. o Added list of interfaces under "ip-sh" node for authentication parameters. o Renamed replay-protection to meticulous. B.11. Changes between versions -06 and -07 o New ietf-bfd-types module. o Grouping for BFD clients to have BFD multiplier and interval values. o Change in ietf-bfd-mpls-te since MPLS-TE model changed. o Removed bfd- prefix from many names. B.12. Changes between versions -05 and -06 o Adhere to NMDA-guidelines. o Echo function config moved to appendix as example. o Added IANA YANG modules. o Addressed various comments. Rahman, et al. Expires February 2, 2019 [Page 77] Internet-Draft BFD YANG August 2018 B.13. Changes between versions -04 and -05 o "bfd" node in augment of control-plane-protocol. o Removed augment of network-instance. Replaced by schema-mount. o Added information on interaction with other YANG modules. B.14. Changes between versions -03 and -04 o Updated author information. o Fixed YANG compile error in ietf-bfd-lag.yang which was due to incorrect when statement. B.15. Changes between versions -02 and -03 o Fixed YANG compilation warning due to incorrect revision date in ietf-bfd-ip-sh module. B.16. Changes between versions -01 and -02 o Replace routing-instance with network-instance from YANG Network Instances [I-D.ietf-rtgwg-ni-model] B.17. Changes between versions -00 and -01 o Remove BFD configuration parameters from BFD clients, all BFD configuration parameters in BFD o YANG module split in multiple YANG modules (one per type of forwarding path) o For BFD over MPLS-TE we augment MPLS-TE model o For BFD authentication we now use YANG Data Model for Key Chains [RFC8177] Authors' Addresses Reshad Rahman (editor) Cisco Systems Canada Email: rrahman@cisco.com Rahman, et al. Expires February 2, 2019 [Page 78] Internet-Draft BFD YANG August 2018 Lianshu Zheng (editor) Huawei Technologies China Email: vero.zheng@huawei.com Mahesh Jethanandani (editor) Xoriant Corporation 1248 Reamwood Ave Sunnyvale, California 94089 USA Email: mjethanandani@gmail.com Santosh Pallagatti Rtbrick India Email: santosh.pallagatti@gmail.com Greg Mirsky ZTE Corporation Email: gregimirsky@gmail.com Rahman, et al. Expires February 2, 2019 [Page 79] ./draft-ietf-i2nsf-applicability-18.txt0000644000764400076440000020666513537631242017253 0ustar iustyiusty I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun Expires: March 18, 2020 Myongji University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D September 15, 2019 Applicability of Interfaces to Network Security Functions to Network- Based Security Services draft-ietf-i2nsf-applicability-18 Abstract This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 18, 2020. Copyright Notice Copyright (c) 2019 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 Jeong, et al. Expires March 18, 2020 [Page 1] Internet-Draft I2NSF Applicability September 2019 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5 4. Time-dependent Web Access Control Service . . . . . . . . . . 8 5. Intent-based Security Services . . . . . . . . . . . . . . . 13 6. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 15 7. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 17 7.1. Firewall: Centralized Firewall System . . . . . . . . . . 19 7.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Attack Mitigation: Centralized DDoS-attack Mitigation System . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Changes from draft-ietf-i2nsf-applicability-17 . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Interface to Network Security Functions (I2NSF) defines a framework and interfaces for interacting with Network Security Functions (NSFs). Note that an NSF is defined as software that provides a set of security-related services, such as (i) detecting unwanted activity, (ii) blocking or mitigating the effect of such unwanted activity in order to fulfill service requirements, and (iii) supporting communication stream integrity and confidentiality [i2nsf-terminology]. The I2NSF framework allows heterogeneous NSFs developed by different security solution vendors to be used in the Network Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing the capabilities of such NSFs through I2NSF interfaces such as Customer- Facing Interface [consumer-facing-inf-dm] and NSF-Facing Interface Jeong, et al. Expires March 18, 2020 [Page 2] Internet-Draft I2NSF Applicability September 2019 [nsf-facing-inf-dm]. In the I2NSF framework, each NSF initially registers the profile of its own capabilities with the Security Controller (i.e., network operator management system [RFC8329]) of the I2NSF system via the Registration Interface [registration-inf-dm]. This registration enables an I2NSF User (i.e., network security administrator) to select and use the NSF to enforce a given security policy. Note that Developer's Management System (DMS) is management software that provides a vendor's security service software as a Virtual Network Function (VNF) in an NFV environment (or middlebox in the legacy network) as an NSF, and registers the capabilities of an NSF into Security Controller via Registration Interface for a security service [RFC8329]. Security Controller maintains the mapping between a capability and an NSF, so it can perform to translate a high-level security policy received from I2NSF User to a low-level security policy configured and enforced in an NSF [policy-translation]. Security Controller can monitor the states and security attacks in NSFs through NSF monitoring [nsf-monitoring-dm]. This document illustrates the applicability of the I2NSF framework with five different scenarios: 1. The enforcement of time-dependent web access control. 2. The support of intent-based security services through I2NSF and Security Policy Translator [policy-translation]. 3. The application of I2NSF to a Service Function Chaining (SFC) environment [RFC7665]. 4. The integration of the I2NSF framework with Software-Defined Networking (SDN) [RFC7149] to provide different security functionality such as firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and Distributed Denial of Service (DDoS) attack mitigation. 5. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a supporting technology. The implementation of I2NSF in these scenarios has allowed us to verify the applicability and effectiveness of the I2NSF framework for a variety of use cases. Jeong, et al. Expires March 18, 2020 [Page 3] Internet-Draft I2NSF Applicability September 2019 2. Terminology This document uses the terminology described in [RFC7665], [RFC7149], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ITU-T.X.800], [NFV-Terminology], [RFC8329], and [i2nsf-terminology]. In addition, the following terms are defined below: o Centralized DDoS-attack Mitigation System: A centralized mitigator that can establish and distribute access control policy rules into network resources for efficient DDoS-attack mitigation. o Centralized Firewall System: A centralized firewall that can establish and distribute policy rules into network resources for efficient firewall management. o Centralized VoIP Security System: A centralized security system that handles the security functions required for VoIP and VoLTE services. o Firewall: A service function at the junction of two network segments that inspects some suspicious packets that attempt to cross the boundary. It also rejects any packet that does not satisfy certain criteria for, for example, disallowed port numbers or IP addresses. o Network Function: A functional block within a network infrastructure that has well-defined external interfaces and well- defined functional behavior [NFV-Terminology]. o Network Functions Virtualization (NFV): A principle of separating network functions (or network security functions) from the hardware they run on by using virtual hardware abstraction [NFV-Terminology]. o Network Security Function (NSF): Software that provides a set of security-related services. Examples include detecting unwanted activity and blocking or mitigating the effect of such unwanted activity in order to fulfill service requirements. The NSF can also help in supporting communication stream integrity and confidentiality [i2nsf-terminology]. o Security Policy Translator (SPT): Software that translates a high- level security policy for the Consumer-Facing Interface into a low-level security policy for the NSF-Facing Interface [policy-translation]. The SPT is a core part of the Security Controller in the I2NSF system. Jeong, et al. Expires March 18, 2020 [Page 4] Internet-Draft I2NSF Applicability September 2019 o Service Function Chaining (SFC): The execution of an ordered set of abstract service functions (i.e., network functions) according to ordering constraints that must be applied to packets, frames, and flows selected as a result of classification. The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied [RFC7665]. o Software-Defined Networking (SDN): A set of techniques that enables to directly program, orchestrate, control, and manage network resources, which facilitates the design, delivery and operation of network services in a dynamic and scalable manner [ITU-T.Y.3300]. +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ | NSF-Facing Interface v +----------------+ +---------------+ +-----------------------+ | NSF-1 |-| NSF-2 |...| NSF-n | | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| +----------------+ +---------------+ +-----------------------+ Figure 1: I2NSF Framework 3. I2NSF Framework This section summarizes the I2NSF framework as defined in [RFC8329]. As shown in Figure 1, an I2NSF User can use security functions by delivering high-level security policies, which specify security requirements that the I2NSF user wants to enforce, to the Security Controller via the Consumer-Facing Interface (CFI) [consumer-facing-inf-dm]. The Security Controller receives and analyzes the high-level security policies from an I2NSF User, and identifies what types of security capabilities are required to meet these high-level security policies. The Security Controller then identifies NSFs that have the required security capabilities, and generates low-level security policies for Jeong, et al. Expires March 18, 2020 [Page 5] Internet-Draft I2NSF Applicability September 2019 each of the NSFs so that the high-level security policies are eventually enforced by those NSFs [policy-translation]. Finally, the Security Controller sends the generated low-level security policies to the NSFs via the NSF-Facing Interface (NFI) [nsf-facing-inf-dm]. As shown in Figure 1, with a Developer's Management System (called DMS), developers (or vendors) inform the Security Controller of the capabilities of the NSFs through the Registration Interface (RI) [registration-inf-dm] for registering (or deregistering) the corresponding NSFs. Note that the lifecycle management of NSF code from DMS (e.g., downloading of NSF modules and testing of NSF code) is out of scope for I2NSF. The Consumer-Facing Interface can be implemented with the Consumer- Facing Interface YANG data model [consumer-facing-inf-dm] using RESTCONF [RFC8040] which befits a web-based user interface for an I2NSF User to send a Security Controller a high-level security policy. Data models specified by YANG [RFC6020] describe high-level security policies to be specified by an I2NSF User. The data model defined in [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing Interface. Note that an inside attacker at the I2NSF User can misuse the I2NSF system so that the network system under the I2NSF system is vulnerable to security attacks. To handle this type of threat, the Security Controller needs to monitor the activities of all the I2NSF Users as well as the NSFs through the I2NSF NSF monitoring functionality [nsf-monitoring-dm]. Note that the monitoring of the I2NSF Users is out of scope for I2NSF. The NSF-Facing Interface can be implemented with the NSF-Facing Interface YANG data model [nsf-facing-inf-dm] using NETCONF [RFC6241] which befits a command-line-based remote-procedure call for a Security Controller to configure an NSF with a low-level security policy. Data models specified by YANG [RFC6020] describe low-level security policies for the sake of NSFs, which are translated from the high-level security policies by the Security Controller. The data model defined in [nsf-facing-inf-dm] can be used for the I2NSF NSF- Facing Interface. The Registration Interface can be implemented with the Registration Interface YANG data model [registration-inf-dm] using NETCONF [RFC6241] which befits a command-line-based remote-procedure call for a DMS to send a Security Controller an NSF's capability information. Data models specified by YANG [RFC6020] describe the registration of an NSF's capabilities to enforce security services at the NSF. The data model defined in [registration-inf-dm] can be used for the I2NSF Registration Interface. Jeong, et al. Expires March 18, 2020 [Page 6] Internet-Draft I2NSF Applicability September 2019 The I2NSF framework can chain multiple NSFs to implement low-level security policies with the SFC architecture [RFC7665]. The following sections describe different security service scenarios illustrating the applicability of the I2NSF framework. block_website block_website_during_working_hours 09:00 18:00 Staff_Members'_PCs SNS_Websites drop Figure 2: A High-level Security Policy XML File for Time-based Web Filter Jeong, et al. Expires March 18, 2020 [Page 7] Internet-Draft I2NSF Applicability September 2019 block_website block_website_during_working_hours 09:00 18:00 2001:DB8:10:1::10 2001:DB8:10:1::20 2001:DB8:10:1::30 example1.com example2.com example3.com example4.com drop Figure 3: A Low-level Security Policy XML File for Time-based Web Filter 4. Time-dependent Web Access Control Service This service scenario assumes that an enterprise network administrator wants to control the staff members' access to a particular Internet service (e.g., social networking service (SNS)) during business hours. The following is an example high-level Jeong, et al. Expires March 18, 2020 [Page 8] Internet-Draft I2NSF Applicability September 2019 security policy rule for a web filter that the administrator requests: Block the staff members' access to SNS websites from 9 AM (i.e., 09:00) to 6 PM (i.e., 18:00) by dropping their packets. Figure 2 is a high-level security policy XML code for the web filter that is sent from the I2NSF User to the Security Controller via the Consumer-Facing Interface [consumer-facing-inf-dm]. The security policy name is "block_website" with the tag "policy- name", and the security policy rule name is "block_website_during_working_hours" with the tag "rule-name". The filtering event has the time span where the filtering begin time is the time "09:00" (i.e., 9:00AM) with the tag "begin-time", and the filtering end time is the time "18:00" (i.e., 6:00PM) with the tag "end-time". The filtering condition has the source target of "Staff_Members'_PCs" with the tag "src-target", and the destination target of "SNS_Websites" with the tag "dest-target". Assume that "Staff_Members'_PCs" are 2001:DB8:10:1::10, 2001:DB8:10:1::20, and 2001:DB8:10:1::30, and that "SNS_Websites" are example1.com, example2.com, example3.com, and example4.com, as shown in Figure 3. Note that Figure 3 is a low-level security policy XML code for the web filter that is sent from the Security Controller to an NSF via the NSF-Facing Interface [nsf-facing-inf-dm]. The source target can by translated by the Security Policy Translator (SPT) in the Security Controller to the IP addresses of computers (or mobile devices) used by the staff members. Refer to Section 5 for the detailed description of the SPT. The destination target can also be translated by the SPT to the actual websites corresponding to the symbolic website name "SNS_Websites", and then either each website's URL or the corresponding IP address(es) can be used by both firewall and web filter. The action is to "drop" the packets satisfying the above event and condition with the tag "primary-action". After receiving the high-level security policy, the Security Controller identifies required security capabilities, e.g., IP address and port number inspection capabilities and URL inspection capability. In this scenario, it is assumed that the IP address and port number inspection capabilities are required to check whether a received packet is an HTTP-session packet from a staff member, which is part of an HTTP session generated by the staff member. The URL inspection capability is required to check whether the target URL of a received packet is one of the target websites (i.e., example1.com, example2.com, example3.com, and example4.com) or not. The Security Controller maintains the security capabilities of each active NSF in the I2NSF system, which have been reported by the Developer's Management System via the Registration interface. Based Jeong, et al. Expires March 18, 2020 [Page 9] Internet-Draft I2NSF Applicability September 2019 on this information, the Security Controller identifies NSFs that can perform the IP address and port number inspection and URL inspection through the security policy translation in Section 5. In this scenario, it is assumed that a firewall NSF has the IP address and port number inspection capabilities and a web filter NSF has URL inspection capability. The Security Controller generates a low-level security policy for the NSFs to perform IP address and port number inspection, URL inspection, and time checking, which is shown in Figure 3. Specifically, the Security Controller may interoperate with an access control server in the enterprise network in order to retrieve the information (e.g., IP address in use, company identifier (ID), and role) of each employee that is currently using the network. Based on the retrieved information, the Security Controller generates a low- level security policy to check whether the source IP address of a received packet matches any one being used by a staff member. In addition, the low-level security policy's rule (shortly, low-level security rule) should be able to determine that a received packet uses either the HTTP protocol without Transport Layer Security (TLS) [RFC8446] or the HTTP protocol with TLS as HTTPS. The low-level security rule for web filter checks that the target URL field of a received packet is equal to one of the target SNS websites (i.e., example1.com, example2.com, example3.com, and example4.com), or that the destination IP address of a received packet is an IP address corresponding to one of the SNS websites. Note that if HTTPS is used for an HTTP-session packet, the HTTP protocol header is encrypted, so the URL information may not be seen from the packet for the web filtering. Thus, the IP address(es) corresponding to the target URL needs to be obtained from the certificate in TLS versions prior to 1.3 [RFC8446] or the Server Name Indication (SNI) in a TCP-session packet in TLS versions without the encrypted SNI [tls-esni]. Also, to obtain IP address(es) corresponding to a target URL, the DNS name resolution process can be observed through a packet capturing tool because the DNS name resolution will translate the target URL into IP address(es). The IP addresses obtained through either TLS or DNS can be used by both firewall and web filter for whitelisting or blacklisting the TCP five-tuples of HTTP sessions. Finally, the Security Controller sends the low-level security policy of the IP address and port number inspection to the firewall NSF and the low-level security policy for URL inspection to the web filter NSF. The following describes how the time-dependent web access control service is enforced by the NSFs of firewall and web filter. Jeong, et al. Expires March 18, 2020 [Page 10] Internet-Draft I2NSF Applicability September 2019 1. A staff member tries to access one of the target SNS websites (i.e., example1.com, example2.com, example3.com, and example4.com) during business hours, e.g., 10 AM. 2. The packet is forwarded from the staff member's device to the firewall, and the firewall checks the source IP address and port number. Now the firewall identifies the received packet is an HTTP-session packet from the staff member. 3. The firewall triggers the web filter to further inspect the packet, and the packet is forwarded from the firewall to the web filter. The SFC architecture [RFC7665] can be utilized to support such packet forwarding in the I2NSF framework. 4. The web filter checks the received packet's target URL field or its destination IP address corresponding to the target URL, and detects that the packet is being sent to the server for example1.com. The web filter then checks that the current time is within business hours. If so, the web filter drops the packet, and consequently the staff member's access to one of the SNS websites (i.e., example1.com, example2.com, example3.com, and example4.com) during business hours is blocked. Jeong, et al. Expires March 18, 2020 [Page 11] Internet-Draft I2NSF Applicability September 2019 +------------------------+-------------------------+ | | | I2NSF User | | | +------------------------+-------------------------+ | Consumer-Facing Interface | High-level Security Policy Security | Controller V +------------------------+-------------------------+ | Security Policy | | | Translator | | | +---------------------+----------------------+ | | | | | | | | +-------+--------+ | | | | | Data Extractor | | | | | +-------+--------+ | | | | | Extracted Data from | | | | V High-level Policy | | | | +-------+--------+ +------+ | | | | | Data Converter |<-->|NSF DB| | | | | +-------+--------+ +------+ | | | | | Required Data for | | | | V Target NSFs | | | | +-------+--------+ | | | | |Policy Generator| | | | | +-------+--------+ | | | | | | | | +---------------------+----------------------+ | | | | +------------------------+-------------------------+ | NSF-Facing Interface | Low-level Security Policy | V +------------------------+-------------------------+ | | | NSF(s) | | | +------------------------+-------------------------+ Figure 4: Security Policy Translation and Enforcement in I2NSF System Jeong, et al. Expires March 18, 2020 [Page 12] Internet-Draft I2NSF Applicability September 2019 5. Intent-based Security Services I2NSF aims at providing intent-based security services to configure specific security policies into NSFs with customer-friendly secuirty policies at a high level. For example, when an I2NSF User submits a high-level security policy (e.g., web filtering as shown in Figure 2) to the Security Controller, the Security Policy Tranlator (SPT) in the Security Controller will translate it into the correspondong low- level security policy as shown in Figure 3 [policy-translation]. A security administrator using the I2NSF User can describe a security policy without the knowledge of the detailed information about subjects (e.g., source and destination) and objects (e.g., web traffic) of the security policy's rule(s). Figure 4 shows the security policy translation and enforcement in the I2NSF system [policy-translation]. As shown in Figure 4, an I2NSF User delivers a high-level security policy to the Security Controller using the Consumer-Facing Interface (denoted as CFI). The high-level security policy is translated by the SPT in the Security Controller into the corresponding low-level security policy which is understandable by target NSF(s). The Security Controller delivers the low-level security policy to the appropriate NSF(s) to enforce the policy's rules. The SPT consists of three modules for security policy translations such as Data Extractor, Data Converter, and Policy Generator, as shown in Figure 4. The Data Extractor extracts data from a high- level security policy delivered by the I2NSF User. The data correspond to the leaf nodes in the YANG data model for the Consumer- Facing Interface. In the high-level policy in Figure 2, the data are the tag values of policy-name, rule-name, begin-time, end-time, src- target, dest-target, and primary-action. That is, the tag values are "block_website", "block_website_during_working_hours", "09:00", "18:00", "Staff_Members'_PCs", "SNS_Websites", and "drop." The Data Converter converts the extracted high-level policy data received from the Data Extractor into the corresponding low-level policy data. The low-level policy data have the capability information of NSFs to be selected as target NSFs for the required security service enforcement specified by the high-level security policy. The tag values in the extracted high-level policy data are replaced with the tag values in the low-level policy data, which are the leaf nodes of the YANG data model for the NSF-Facing Interface (denoted as NFI). The value of each leaf node in CFI is translated into the value of the corresponding leaf node in NFI. For example, "block_website" of policy-name in CFI (in Figure 2) is translated into "block_website" of system-policy-name in NFI (in Figure 3). The tag values of rule-name, begin-time, end-time, and primary-action in Jeong, et al. Expires March 18, 2020 [Page 13] Internet-Draft I2NSF Applicability September 2019 CFI are mapped into the same values of rule-name, begin-time, end- time, and egress-action in NFI. However, the tag values of src- target and dest-target in CFI are translated into IP addresses and URLs, respectively, for the sake of NFI. That is, "Staff_Members'_PCs" of CFI is translated into three IPv6 addresses such as "2001:DB8:10:1::10", "2001:DB8:10:1::20", and "2001:DB8:10:1::30" for the sake of NFI. Also, "SNS_Websites" of CFI is translated into four URLs such as "example1.com", "example2.com", "example3.com", and "example4.com" for the sake of NFI. In addition to the data conversion, the Data Converter searches for appropriate NSFs having capabilities corresponding to the leaf nodes of the YANG data model for NFI. For the data conversion and NSF search, an NSF database (denoted as NSF DB) can be consulted, as shown in Figure 4, because the NSF DB has the capability information of NSFs that the DMS(s) registered with the Security Controller using the Registration Interface. The Policy Generator generates a low-level security policy corresponding to the low-level policy data made by the Data Converter per a target NSF. That is, the Policy Generator can build such a low-level security policy XML file like Figure 3 with the NSF DB because the NSF DB has the mapping information between the CFI YANG data model and the NFI YANG data model. Therefore, by allowing the I2NSF User to express its security policy without knowing the detailed information of entities for security policies, the I2NSF can efficiently support the intent-based security services with the help of the security policy translator along with the NSF DB. Jeong, et al. Expires March 18, 2020 [Page 14] Internet-Draft I2NSF Applicability September 2019 +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ | | NSF-Facing Interface | |------------------------- | | | NSF-Facing Interface | +-----v-----------+ +------v-------+ | +-----------+ | ------>| NSF-1 | | |Classifier | | | | (Firewall) | | +-----------+ | | +--------------+ | +-----+ |<-----| +--------------+ | | SFF | | |----->| NSF-2 | | +-----+ | | | (DPI) | +-----------------+ | +--------------+ | . | . | . | +-----------------------+ ------>| NSF-n | |(DDoS-Attack Mitigator)| +-----------------------+ Figure 5: An I2NSF Framework with SFC 6. I2NSF Framework with SFC In the I2NSF architecture, an NSF can trigger an advanced security action (e.g., DPI or DDoS attack mitigation) on a packet based on the result of its own security inspection of the packet. For example, a firewall triggers further inspection of a suspicious packet with DPI. For this advanced security action to be fulfilled, the suspicious packet should be forwarded from the current NSF to the successor NSF. SFC [RFC7665] is a technology that enables this advanced security action by steering a packet with multiple service functions (e.g., NSFs), and this technology can be utilized by the I2NSF architecture to support the advanced security action. Figure 5 shows an I2NSF framework with the support of SFC. As shown in the figure, SFC generally requires classifiers and service function forwarders (SFFs); classifiers are responsible for Jeong, et al. Expires March 18, 2020 [Page 15] Internet-Draft I2NSF Applicability September 2019 determining which service function path (SFP) (i.e., an ordered sequence of service functions) a given packet should pass through, according to pre-configured classification rules, and SFFs perform forwarding the given packet to the next service function (e.g., NSF) on the SFP of the packet by referring to their forwarding tables. In the I2NSF architecture with SFC, the Security Controller can take responsibilities of generating classification rules for classifiers and forwarding tables for SFFs. By analyzing high-level security policies from I2NSF users, the Security Controller can construct SFPs that are required to meet the high-level security policies, generates classification rules of the SFPs, and then configures classifiers with the classification rules over NSF-Facing Interface so that relevant traffic packets can follow the SFPs. Also, based on the global view of NSF instances available in the system, the Security Controller constructs forwarding tables, which are required for SFFs to forward a given packet to the next NSF over the SFP, and configures SFFs with those forwarding tables over NSF-Facing Interface. To trigger an advanced security action in the I2NSF architecture, the current NSF appends metadata describing the security capability required to the suspicious packet via a network service header (NSH) [RFC8300]. It then sends the packet to the classifier. Based on the metadata information, the classifier searches an SFP which includes an NSF with the required security capability, changes the SFP-related information (e.g., service path identifier and service index [RFC8300]) of the packet with the new SFP that has been found, and then forwards the packet to the SFF. When receiving the packet, the SFF checks the SFP-related information such as the service path identifier and service index contained in the packet and forwards the packet to the next NSF on the SFP of the packet, according to its forwarding table. Jeong, et al. Expires March 18, 2020 [Page 16] Internet-Draft I2NSF Applicability September 2019 +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ | | NSF-Facing Interface | v | +----------------+ +---------------+ +-----------------------+ | | NSF-1 |-| NSF-2 |...| NSF-n | | | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| | +----------------+ +---------------+ +-----------------------+ | | | SDN Network +--|----------------------------------------------------------------+ | V NSF-Facing Interface | | +----------------+ | | | SDN Controller | | | +----------------+ | | ^ | | | SDN Southbound Interface | | v | | +--------+ +------------+ +--------+ +--------+ | | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | | | | |(Classifier)| | (SFF) | | | | | +--------+ +------------+ +--------+ +--------+ | +-------------------------------------------------------------------+ Figure 6: An I2NSF Framework with SDN Network 7. I2NSF Framework with SDN This section describes an I2NSF framework with SDN for I2NSF applicability and use cases, such as firewall, deep packet inspection, and DDoS-attack mitigation functions. SDN enables some packet filtering rules to be enforced in network forwarding elements (e.g., switch) by controlling their packet forwarding rules. By taking advantage of this capability of SDN, it is possible to optimize the process of security service enforcement in the I2NSF system. For example, for efficient firewall services, simple packet filtering can be performed by SDN forwarding elements (e.g., switches), and complicated packet filtering based on packet payloads can be performed by a firewall NSF. This optimized firewall using Jeong, et al. Expires March 18, 2020 [Page 17] Internet-Draft I2NSF Applicability September 2019 both SDN forwarding elements and a firewall NSF is more efficient than a firewall where SDN forwarding elements forward all the packets to a firewall NSF for packet filtering. This is because packets to be filtered out can be early dropped by SDN forwarding elements without consuming further network bandwidth due to the forwarding of the packets to the firewall NSF. Figure 6 shows an I2NSF framework [RFC8329] with SDN networks to support network-based security services. In this system, the enforcement of security policy rules is divided into the SDN forwarding elements (e.g., a switch running as either a hardware middle box or a software virtual switch) and NSFs (e.g., a firewall running in a form of a VNF [ETSI-NFV]). Note that NSFs are created or removed by the NFV Management and Orchestration (MANO) [ETSI-NFV-MANO], performing the lifecycle management of NSFs as VNFs. Refer to Section 8 for the detailed discussion of the NSF lifecycle management in the NFV MANO for I2NSF. For security policy enforcement (e.g., packet filtering), the Security Controller instructs the SDN Controller via NSF-Facing Interface so that SDN forwarding elements can perform the required security services with flow tables under the supervision of the SDN Controller. As an example, let us consider two different types of security rules: Rule A is a simple packet filtering rule that checks only the IP address and port number of a given packet, whereas rule B is a time- consuming packet inspection rule for analyzing whether an attached file being transmitted over a flow of packets contains malware. Rule A can be translated into packet forwarding rules of SDN forwarding elements and thus be enforced by these elements. In contrast, rule B cannot be enforced by forwarding elements, but it has to be enforced by NSFs with anti-malware capability. Specifically, a flow of packets is forwarded to and reassembled by an NSF to reconstruct the attached file stored in the flow of packets. The NSF then analyzes the file to check the existence of malware. If the file contains malware, the NSF drops the packets. In an I2NSF framework with SDN, the Security Controller can analyze given security policy rules and automatically determine which of the given security policy rules should be enforced by SDN forwarding elements and which should be enforced by NSFs. If some of the given rules requires security capabilities that can be provided by SDN forwarding elements, then the Security Controller instructs the SDN Controller via NSF-Facing Interface so that SDN forwarding elements can enforce those security policy rules with flow tables under the supervision of the SDN Controller. Or if some rules require security capabilities that cannot be provided by SDN forwarding elements but by NSFs, then the Security Controller instructs relevant NSFs to enforce those rules. Jeong, et al. Expires March 18, 2020 [Page 18] Internet-Draft I2NSF Applicability September 2019 The distinction between software-based SDN forwarding elements and NSFs, which can both run as VNFs, may be necessary for some management purposes in this system. Note that an SDN forwarding element (i.e., switch) is a specific type of VNF rather than an NSF because an NSF is for security services rather than for packet forwarding. For this distinction, we can take advantage of the NFV MANO where there is a subsystem that maintains the descriptions of the capabilities each VNF can offer [ETSI-NFV-MANO]. This subsystem can determine whether a given software element (VNF instance) is an NSF or a virtualized SDN switch. For example, if a VNF instance has anti-malware capability according to the description of the VNF, it could be considered as an NSF. A VNF onboarding system [VNF-ONBOARDING] can be used as such a subsystem that maintains the descriptions of each VNF to tell whether a VNF instance is for an NSF or for a virtualized SDN switch. For the support of SFC in the I2NSF framework with SDN, as shown in Figure 6, network forwarding elements (e.g., switch) can play the role of either SFC Classifier or SFF, which are explained in Section 6. Classifier and SFF have an NSF-Facing Interface with Security Controller. This interface is used to update security service function chaining information for traffic flows. For example, when it needs to update an SFP for a traffic flow in an SDN network, as shown in Figure 6, SFF (denoted as Switch-3) asks Security Controller to update the SFP for the traffic flow (needing another security service as an NSF) via NSF-Facing Interface. This update lets Security Controller ask Classifier (denoted as Switch-2) to update the mapping between the traffic flow and SFP in Classifier via NSF-Facing Interface. The following subsections introduce three use cases from [RFC8192] for cloud-based security services: (i) firewall system, (ii) deep packet inspection system, and (iii) attack mitigation system. 7.1. Firewall: Centralized Firewall System A centralized network firewall can manage each network resource and apply common rules to individual network elements (e.g., switch). The centralized network firewall controls each forwarding element, and firewall rules can be added or deleted dynamically. A time-based firewall can be enforced with packet filtering rules and a time span (e.g., work hours). With this time-based firewall, a time-based security policy can be enforced, as explained in Section 4. For example, employees at a company are allowed to access social networking service websites during lunch time or after work hours. Jeong, et al. Expires March 18, 2020 [Page 19] Internet-Draft I2NSF Applicability September 2019 7.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE flow and manage VoIP/VoLTE security rules, according to the configuration of a VoIP/VoLTE security service called VoIP Intrusion Prevention System (IPS). This centralized VoIP/VoLTE security system controls each switch for the VoIP/VoLTE call flow management by manipulating the rules that can be added, deleted or modified dynamically. The centralized VoIP/VoLTE security system can cooperate with a network firewall to realize VoIP/VoLTE security service. Specifically, a network firewall performs the basic security check of an unknown flow's packet observed by a switch. If the network firewall detects that the packet is an unknown VoIP call flow's packet that exhibits some suspicious patterns, then it triggers the VoIP/VoLTE security system for more specialized security analysis of the suspicious VoIP call packet. 7.3. Attack Mitigation: Centralized DDoS-attack Mitigation System A centralized DDoS-attack mitigation can manage each network resource and configure rules to each switch for DDoS-attack mitigation (called DDoS-attack Mitigator) on a common server. The centralized DDoS- attack mitigation system defends servers against DDoS attacks outside the private network, that is, from public networks [RFC8612][dots-architecture]. Servers are categorized into stateless servers (e.g., DNS servers) and stateful servers (e.g., web servers). For DDoS-attack mitigation, the forwarding of traffic flows in switches can be dynamically configured such that malicious traffic flows are handled by the paths separated from normal traffic flows in order to minimize the impact of those malicious traffic on the servers. This flow path separation can be done by a flow forwarding path management scheme [dots-architecture][AVANT-GUARD]. This management should consider the load balance among the switches for the defense against DDoS attacks. So far this section has described the three use cases for network- based security services using the I2NSF framework with SDN networks. To support these use cases in the proposed data-driven security service framework, YANG data models described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and [registration-inf-dm] can be used as Consumer-Facing Interface, NSF- Facing Interface, and Registration Interface, respectively, along with RESTCONF [RFC8040] and NETCONF [RFC6241]. Jeong, et al. Expires March 18, 2020 [Page 20] Internet-Draft I2NSF Applicability September 2019 +--------------------+ +-------------------------------------------+ | ---------------- | | I2NSF User (OSS/BSS) | | | NFV | | +------+------------------------------------+ | | Orchestrator +-+ | | Consumer-Facing Interface | -----+---------- | | +------|------------------------------------+ | | | | | -----+---------- (a) ----------------- | | ----+----- | | | | Security +-------+ Developer's | | | | | | | | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | | | -----+---------- ----------------- | | | | | | | | NSF-Facing Interface | | ----+----- | | | ----+----- ----+----- ----+----- | | | | | | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | | | ----+----- ----+----- ----+----- | | | | | | | | | | | | | | +------|-------------|-------------|--------+ | | | | | | | | | | | +------+-------------+-------------+--------+ | | | | | NFV Infrastructure (NFVI) | | | | | | ----------- ----------- ----------- | | | | | | | Virtual | | Virtual | | Virtual | | | | | | | | Compute | | Storage | | Network | | | | | | | ----------- ----------- ----------- | | ----+----- | | | +---------------------------------------+ | | | | | | | | Virtualization Layer | +-----+ VIM(s) +------+ | | +---------------------------------------+ | | | | | | +---------------------------------------+ | | ---------- | | | ----------- ----------- ----------- | | | | | | | Compute | | Storage | | Network | | | | | | | | Hardware| | Hardware| | Hardware| | | | | | | ----------- ----------- ----------- | | | | | | Hardware Resources | | | NFV Management | | +---------------------------------------+ | | and Orchestration | | | | (MANO) | +-------------------------------------------+ +--------------------+ (a) = Registration Interface (b) = Ve-Vnfm Interface Figure 7: I2NSF Framework Implementation with respect to the NFV Reference Architectural Framework 8. I2NSF Framework with NFV This section discusses the implementation of the I2NSF framework using Network Functions Virtualization (NFV). NFV is a promising technology for improving the elasticity and efficiency of network resource utilization. In NFV environments, Jeong, et al. Expires March 18, 2020 [Page 21] Internet-Draft I2NSF Applicability September 2019 NSFs can be deployed in the forms of software-based virtual instances rather than physical appliances. Virtualizing NSFs makes it possible to rapidly and flexibly respond to the amount of service requests by dynamically increasing or decreasing the number of NSF instances. Moreover, NFV technology facilitates flexibly including or excluding NSFs from multiple security solution vendors according to the changes on security requirements. In order to take advantages of the NFV technology, the I2NSF framework can be implemented on top of an NFV infrastructure as show in Figure 7. Figure 7 shows an I2NSF framework implementation based on the NFV reference architecture that the European Telecommunications Standards Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as VNFs in Figure 7. The Developer's Management System (DMS) in the I2NSF framework is responsible for registering capability information of NSFs into the Security Controller. However, those NSFs are created or removed by a virtual network function manager (VNFM) in the NFV MANO that performs the lifecycle management of VNFs. Note that the lifecycle management of VNFs is out of scope for I2NSF. The Security Controller controls and monitors the configurations (e.g., function parameters and security policy rules) of VNFs via the NSF-Facing Interface along with the NSF monitoring capability [nsf-facing-inf-dm][nsf-monitoring-dm]. Both the DMS and Security Controller can be implemented as the Element Managements (EMs) in the NFV architecture. Finally, the I2NSF User can be implemented as OSS/ BSS (Operational Support Systems/Business Support Systems) in the NFV architecture that provides interfaces for users in the NFV system. The operation procedure in the I2NSF framework based on the NFV architecture is as follows: 1. The VNFM has a set of virtual machine (VM) images of NSFs, and each VM image can be used to create an NSF instance that provides a set of security capabilities. The DMS initially registers a mapping table of the ID of each VM image and the set of capabilities that can be provided by an NSF instance created from the VM image into the Security Controller. 2. If the Security Controller does not have any instantiated NSF that has the set of capabilities required to meet the security requirements from users, it searches the mapping table (registered by the DMS) for the VM image ID corresponding to the required set of capabilities. 3. The Security Controller requests the DMS to instantiate an NSF with the VM image ID via VNFM. Jeong, et al. Expires March 18, 2020 [Page 22] Internet-Draft I2NSF Applicability September 2019 4. When receiving the instantiation request, the VNFM first asks the NFV orchestrator for the permission required to create the NSF instance, requests the VIM to allocate resources for the NSF instance, and finally creates the NSF instance based on the allocated resources. 5. Once the NSF instance has been created by the VNFM, the DMS performs the initial configurations of the NSF instance and then notifies the Security Controller of the NSF instance. 6. After being notified of the created NSF instance, the Security Controller delivers low-level security policy rules to the NSF instance for policy enforcement. We can conclude that the I2NSF framework can be implemented based on the NFV architecture framework. Note that the registration of the capabilities of NSFs is performed through the Registration Interface and the lifecycle management for NSFs (VNFs) is performed through the Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 7. 9. Security Considerations The same security considerations for the I2NSF framework [RFC8329] are applicable to this document. This document shares all the security issues of SDN that are specified in the "Security Considerations" section of [ITU-T.Y.3300]. The role of the DMS is to provide an I2NSF system with the software packages or images for NSF execution. The DMS must not access NSFs in activated status. An inside attacker or a supply chain attacker at the DMS can seriously weaken the I2NSF system's security. A malicious DMS is relevant to an insider attack, and a compromised DMS is relevant to a supply chain attack. A malicious (or compromised) DMS could register an NSF of its choice in response to a capability request by the Security Controller. As a result, a malicious DMS can attack the I2NSF system by providing malicious NSFs with arbitrary capabilities to include potentially controlling those NSFs in real time. An unwitting DMS could be compromised and the infrastructure of the DMS could be coerced into distributing modified NSFs as well. To deal with these types of threats, an I2NSF system should not use NSFs from an untrusted DMS or without prior testing. The practices by which these packages are downloaded and loaded into the system are out of scope for I2NSF. I2NSF system operators should audit and monitor interactions with DMSs. Additionally, the operators should monitor the running NSFs Jeong, et al. Expires March 18, 2020 [Page 23] Internet-Draft I2NSF Applicability September 2019 through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as part of the I2NSF NSF-Facing Interface. Note that the mechanics for monitoring the DMSs are out of scope for I2NSF. 10. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work has been partially supported by the European Commission under Horizon 2020 grant agreement no. 700199 "Securing against intruders and other threats through a NFV-enabled environment (SHIELD)". This support does not imply endorsement. 11. Contributors I2NSF is a group effort. I2NSF has had a number of contributing authors. The following are considered co-authors: o Hyoungshick Kim (Sungkyunkwan University) o Jinyong Tim Kim (Sungkyunkwan University) o Hyunsik Yang (Soongsil University) o Younghan Kim (Soongsil University) o Jung-Soo Park (ETRI) o Se-Hui Lee (Korea Telecom) o Mohamed Boucadair (Orange) 12. References 12.1. Normative References [AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- GUARD: Scalable and Vigilant Switch Flow Management in Software-Defined Networks", ACM CCS, November 2013. Jeong, et al. Expires March 18, 2020 [Page 24] Internet-Draft I2NSF Applicability September 2019 [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", draft- ietf-i2nsf-consumer-facing-interface-dm-06 (work in progress), July 2019. [dots-architecture] Mortensen, A., Reddy, T., Andreasen, F., Teague, N., and R. Compton, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", draft-ietf-dots- architecture-14 (work in progress), May 2019. [ETSI-NFV] "Network Functions Virtualisation (NFV); Architectural Framework", Available: https://www.etsi.org/deliver/etsi_gs/ nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October 2013. [ITU-T.Y.3300] "Framework of Software-Defined Networking", Available: https://www.itu.int/rec/T-REC-Y.3300-201406-I, June 2014. [NFV-Terminology] "Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV", Available: https://www.etsi.org/deliver/etsi_gs/ NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf, December 2014. [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-07 (work in progress), July 2019. [nsf-monitoring-dm] Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf- nsf-monitoring-data-model-01 (work in progress), July 2019. [ONF-SDN-Architecture] "SDN Architecture (Issue 1.1)", Available: https://www.opennetworking.org/wp- content/uploads/2014/10/TR- 521_SDN_Architecture_issue_1.1.pdf, June 2016. Jeong, et al. Expires March 18, 2020 [Page 25] Internet-Draft I2NSF Applicability September 2019 [registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", draft-ietf-i2nsf- registration-interface-dm-05 (work in progress), July 2019. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014. [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, October 2015. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases", RFC 8192, July 2017. [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service Header (NSH)", RFC 8300, January 2018. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, February 2018. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, May 2019. 12.2. Informative References Jeong, et al. Expires March 18, 2020 [Page 26] Internet-Draft I2NSF Applicability September 2019 [ETSI-NFV-MANO] "Network Functions Virtualisation (NFV); Management and Orchestration", Available: https://www.etsi.org/deliver/etsi_gs/nfv- man/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf, December 2014. [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-08 (work in progress), July 2019. [ITU-T.X.800] "Security Architecture for Open Systems Interconnection for CCITT Applications", March 1991. [opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in Internet Security", draft-ietf-opsawg-firewalls-01 (work in progress), October 2012. [policy-translation] Jeong, J., Yang, J., Chung, C., and J. Kim, "Security Policy Translation in Interface to Network Security Functions", draft-yang-i2nsf-security-policy- translation-04 (work in progress), July 2019. [tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "Encrypted Server Name Indication for TLS 1.3", draft- ietf-tls-esni-04 (work in progress), July 2019. [VNF-ONBOARDING] "VNF Onboarding", Available: https://wiki.opnfv.org/display/mano/VNF+Onboarding, November 2016. Jeong, et al. Expires March 18, 2020 [Page 27] Internet-Draft I2NSF Applicability September 2019 Appendix A. Changes from draft-ietf-i2nsf-applicability-17 The following changes have been made from draft-ietf-i2nsf- applicability-17: o In Section 4, a high-level security policy XML file in Figure 2 and the corresponding low-level security policy XML file Figure 3 are constructed using the Consumer-Facing Interface data model and the NSF-Facing data model, respectively. o For the applicability of I2NSF to the real world, Section 5 is added to support the Intent-based Security Services using I2NSF. This section explains the security policy translation based on an I2NSF User's intents on the required security services. Figure 4 shows the archiecture and procedure of the I2NSF security policy translator. Authors' Addresses Jaehoon Paul Jeong Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 7996 EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Sangwon Hyun Department of Computer Engineering Myongji University 116 Myongji-ro, Cheoin-gu Yongin 17058 Republic of Korea Phone: +82 62 230 7473 EMail: shyun@chosun.ac.kr Jeong, et al. Expires March 18, 2020 [Page 28] Internet-Draft I2NSF Applicability September 2019 Tae-Jin Ahn Korea Telecom 70 Yuseong-Ro, Yuseong-Gu Daejeon 305-811 Republic of Korea Phone: +82 42 870 8409 EMail: taejin.ahn@kt.com Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Phone: +1-734-604-0332 EMail: shares@ndzh.com Diego R. Lopez Telefonica I+D Jose Manuel Lara, 9 Seville 41013 Spain Phone: +34 682 051 091 EMail: diego.r.lopez@telefonica.com Jeong, et al. Expires March 18, 2020 [Page 29] ./draft-ietf-calext-jscalendar-32.txt0000644000764400076440000054474013742234116016762 0ustar iustyiusty Calendaring extensions N. Jenkins Internet-Draft R. Stepanek Intended status: Standards Track Fastmail Expires: April 19, 2021 October 16, 2020 JSCalendar: A JSON representation of calendar data draft-ietf-calext-jscalendar-32 Abstract This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 19, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Jenkins & Stepanek Expires April 19, 2021 [Page 1] Internet-Draft JSCalendar October 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation and Relation to iCalendar and jCal . . . . . . 5 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 6 1.3. Type Signatures . . . . . . . . . . . . . . . . . . . . . 6 1.4. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Id . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.2. Int . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.3. UnsignedInt . . . . . . . . . . . . . . . . . . . . . 8 1.4.4. UTCDateTime . . . . . . . . . . . . . . . . . . . . . 8 1.4.5. LocalDateTime . . . . . . . . . . . . . . . . . . . . 8 1.4.6. Duration . . . . . . . . . . . . . . . . . . . . . . 9 1.4.7. SignedDuration . . . . . . . . . . . . . . . . . . . 10 1.4.8. TimeZoneId . . . . . . . . . . . . . . . . . . . . . 10 1.4.9. PatchObject . . . . . . . . . . . . . . . . . . . . . 11 1.4.10. Relation . . . . . . . . . . . . . . . . . . . . . . 12 1.4.11. Link . . . . . . . . . . . . . . . . . . . . . . . . 12 2. JSCalendar Objects . . . . . . . . . . . . . . . . . . . . . 14 2.1. JSEvent . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. JSTask . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. JSGroup . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Structure of JSCalendar Objects . . . . . . . . . . . . . . . 15 3.1. Object Type . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Normalization and Equivalence . . . . . . . . . . . . . . 15 3.3. Vendor-specific Property Extensions, Values and Types . . 15 4. Common JSCalendar Properties . . . . . . . . . . . . . . . . 16 4.1. Metadata Properties . . . . . . . . . . . . . . . . . . . 16 4.1.1. @type . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. uid . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. relatedTo . . . . . . . . . . . . . . . . . . . . . . 17 4.1.4. prodId . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.5. created . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.6. updated . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.7. sequence . . . . . . . . . . . . . . . . . . . . . . 18 4.1.8. method . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. What and Where Properties . . . . . . . . . . . . . . . . 18 4.2.1. title . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2. description . . . . . . . . . . . . . . . . . . . . . 18 4.2.3. descriptionContentType . . . . . . . . . . . . . . . 18 4.2.4. showWithoutTime . . . . . . . . . . . . . . . . . . . 19 4.2.5. locations . . . . . . . . . . . . . . . . . . . . . . 19 4.2.6. virtualLocations . . . . . . . . . . . . . . . . . . 20 4.2.7. links . . . . . . . . . . . . . . . . . . . . . . . . 21 Jenkins & Stepanek Expires April 19, 2021 [Page 2] Internet-Draft JSCalendar October 2020 4.2.8. locale . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.9. keywords . . . . . . . . . . . . . . . . . . . . . . 22 4.2.10. categories . . . . . . . . . . . . . . . . . . . . . 22 4.2.11. color . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Recurrence Properties . . . . . . . . . . . . . . . . . . 22 4.3.1. recurrenceId . . . . . . . . . . . . . . . . . . . . 23 4.3.2. recurrenceRules . . . . . . . . . . . . . . . . . . . 23 4.3.3. excludedRecurrenceRules . . . . . . . . . . . . . . . 31 4.3.4. recurrenceOverrides . . . . . . . . . . . . . . . . . 32 4.3.5. excluded . . . . . . . . . . . . . . . . . . . . . . 33 4.4. Sharing and Scheduling Properties . . . . . . . . . . . . 33 4.4.1. priority . . . . . . . . . . . . . . . . . . . . . . 33 4.4.2. freeBusyStatus . . . . . . . . . . . . . . . . . . . 33 4.4.3. privacy . . . . . . . . . . . . . . . . . . . . . . . 34 4.4.4. replyTo . . . . . . . . . . . . . . . . . . . . . . . 35 4.4.5. participants . . . . . . . . . . . . . . . . . . . . 35 4.5. Alerts Properties . . . . . . . . . . . . . . . . . . . . 41 4.5.1. useDefaultAlerts . . . . . . . . . . . . . . . . . . 41 4.5.2. alerts . . . . . . . . . . . . . . . . . . . . . . . 41 4.6. Multilingual Properties . . . . . . . . . . . . . . . . . 43 4.6.1. localizations . . . . . . . . . . . . . . . . . . . . 43 4.7. Time Zone Properties . . . . . . . . . . . . . . . . . . 44 4.7.1. timeZone . . . . . . . . . . . . . . . . . . . . . . 44 4.7.2. timeZones . . . . . . . . . . . . . . . . . . . . . . 44 5. Type-specific JSCalendar Properties . . . . . . . . . . . . . 47 5.1. JSEvent Properties . . . . . . . . . . . . . . . . . . . 47 5.1.1. start . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1.2. duration . . . . . . . . . . . . . . . . . . . . . . 47 5.1.3. status . . . . . . . . . . . . . . . . . . . . . . . 47 5.2. JSTask Properties . . . . . . . . . . . . . . . . . . . . 48 5.2.1. due . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.2. start . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.3. estimatedDuration . . . . . . . . . . . . . . . . . . 48 5.2.4. percentComplete . . . . . . . . . . . . . . . . . . . 48 5.2.5. progress . . . . . . . . . . . . . . . . . . . . . . 48 5.2.6. progressUpdated . . . . . . . . . . . . . . . . . . . 49 5.3. JSGroup Properties . . . . . . . . . . . . . . . . . . . 49 5.3.1. entries . . . . . . . . . . . . . . . . . . . . . . . 50 5.3.2. source . . . . . . . . . . . . . . . . . . . . . . . 50 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.1. Simple event . . . . . . . . . . . . . . . . . . . . . . 51 6.2. Simple task . . . . . . . . . . . . . . . . . . . . . . . 51 6.3. Simple group . . . . . . . . . . . . . . . . . . . . . . 51 6.4. All-day event . . . . . . . . . . . . . . . . . . . . . . 52 6.5. Task with a due date . . . . . . . . . . . . . . . . . . 52 6.6. Event with end time zone . . . . . . . . . . . . . . . . 53 6.7. Floating-time event (with recurrence) . . . . . . . . . . 53 6.8. Event with multiple locations and localization . . . . . 54 Jenkins & Stepanek Expires April 19, 2021 [Page 3] Internet-Draft JSCalendar October 2020 6.9. Recurring event with overrides . . . . . . . . . . . . . 55 6.10. Recurring event with participants . . . . . . . . . . . . 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . 58 7.1. Expanding Recurrences . . . . . . . . . . . . . . . . . . 58 7.2. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 59 7.3. URI Values . . . . . . . . . . . . . . . . . . . . . . . 59 7.4. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.5. Duplication . . . . . . . . . . . . . . . . . . . . . . . 60 7.6. Time Zones . . . . . . . . . . . . . . . . . . . . . . . 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 8.1. Media Type Registration . . . . . . . . . . . . . . . . . 61 8.2. Creation of "JSCalendar Properties" Registry . . . . . . 62 8.2.1. Preliminary Community Review . . . . . . . . . . . . 63 8.2.2. Submit Request to IANA . . . . . . . . . . . . . . . 63 8.2.3. Designated Expert Review . . . . . . . . . . . . . . 63 8.2.4. Change Procedures . . . . . . . . . . . . . . . . . . 63 8.2.5. JSCalendar Properties Registry Template . . . . . . . 64 8.2.6. Initial Contents for the JSCalendar Properties Registry . . . . . . . . . . . . . . . . . . . . . . 64 8.3. Creation of "JSCalendar Types" Registry . . . . . . . . . 73 8.3.1. JSCalendar Types Registry Template . . . . . . . . . 73 8.3.2. Initial Contents for the JSCalendar Types Registry . 73 8.4. Creation of "JSCalendar Enum Values" Registry . . . . . . 74 8.4.1. JSCalendar Enum Property Template . . . . . . . . . . 74 8.4.2. JSCalendar Enum Value Template . . . . . . . . . . . 75 8.4.3. Initial Contents for the JSCalendar Enum Values registry . . . . . . . . . . . . . . . . . . . . . . 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 82 10.2. Informative References . . . . . . . . . . . . . . . . . 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 1. Introduction This document defines a data model for calendar event and task objects, or groups of such objects, in electronic calendar applications and systems. The format aims to be unambiguous, extendable and simple to process. The key design considerations for this data model are as follows: o The attributes of the calendar entry represented must be described as simple key-value pairs. Simple events are simple to represent; complex events can be modelled accurately. o Wherever possible, there should be only one way to express the desired semantics, reducing complexity. Jenkins & Stepanek Expires April 19, 2021 [Page 4] Internet-Draft JSCalendar October 2020 o The data model should avoid ambiguities, which often lead to interoperability issues between implementations. o The data model should be generally compatible with the iCalendar data format [RFC5545] [RFC7986] and extensions, but the specification should add new attributes where the iCalendar format currently lacks expressivity, and drop seldom-used, obsolete, or redundant properties. This means translation with no loss of semantics should be easy with most common iCalendar files. o Extensions, such as new properties and components, should not require updates to this document. The representation of this data model is defined in the I-JSON format [RFC7493], which is a strict subset of the JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]. Using JSON is mostly a pragmatic choice: its widespread use makes JSCalendar easier to adopt, and the ready availability of production-ready JSON implementations eliminates a whole category of parser-related interoperability issues, which iCalendar has often suffered from. 1.1. Motivation and Relation to iCalendar and jCal The iCalendar data format [RFC5545], a widely deployed interchange format for calendaring and scheduling data, has served calendaring vendors for a long while, but contains some ambiguities and pitfalls that can not be overcome without backward-incompatible changes. Sources of implementation errors include the following: o iCalendar defines various formats for local times, UTC time, and dates. o iCalendar requires custom time zone definitions within a single calendar component. o iCalendar's definition of recurrence rules is ambiguous and has resulted in differing understandings even between experienced calendar developers. o The iCalendar format itself causes interoperability issues due to misuse of CRLF-terminated strings, line continuations, and subtle differences among iCalendar parsers. In recent years, many new products and services have appeared that wish to use a JSON representation of calendar data within their APIs. The JSON format for iCalendar data, jCal [RFC7265], is a direct mapping between iCalendar and JSON. In its effort to represent full Jenkins & Stepanek Expires April 19, 2021 [Page 5] Internet-Draft JSCalendar October 2020 iCalendar semantics, it inherits all the same pitfalls and uses a complicated JSON structure. As a consequence, since the standardization of jCal, the majority of implementations and service providers either kept using iCalendar, or came up with their own proprietary JSON representations, which are incompatible with each other and often suffer from common pitfalls, such as storing event start times in UTC (which become incorrect if the timezone's rules change in the future). JSCalendar meets the demand for JSON-formatted calendar data that is free of such known problems and provides a standard representation as an alternative to the proprietary formats. 1.2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The underlying format used for this specification is JSON. Consequently, the terms "object" and "array" as well as the four primitive types (strings, numbers, booleans, and null) are to be interpreted as described in Section 1 of [RFC8259]. Some examples in this document contain "partial" JSON documents used for illustrative purposes. In these examples, three periods "..." are used to indicate a portion of the document that has been removed for compactness. 1.3. Type Signatures Type signatures are given for all JSON values in this document. The following conventions are used: o "*" - The type is undefined (the value could be any type, although permitted values may be constrained by the context of this value). o "String" - The JSON string type. o "Number" - The JSON number type. o "Boolean" - The JSON boolean type. o "A[B]" - A JSON object where the keys are all of type "A", and the values are all of type "B". Jenkins & Stepanek Expires April 19, 2021 [Page 6] Internet-Draft JSCalendar October 2020 o "A[]" - An array of values of type "A". o "A|B" - The value is either of type "A" or of type "B". Other types may also be given, with their representations defined elsewhere in this document. 1.4. Data Types In addition to the standard JSON data types, the following data types are used in this specification: 1.4.1. Id Where "Id" is given as a data type, it means a "String" of at least 1 and a maximum of 255 octets in size, and it MUST only contain characters from the "URL and Filename Safe" base64url alphabet, as defined in Section 5 of [RFC4648], excluding the pad character ("="). This means the allowed characters are the ASCII alphanumeric characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). In many places in JSCalendar a JSON map is used where the map keys are of type Id and the map values are all the same type of object. This construction represents an unordered set of objects, with the added advantage that each entry has a name (the corresponding map key). This allows for more concise patching of objects, and, when applicable, for the objects in question to be referenced from other objects within the JSCalendar object. Unless otherwise specified for a particular property, there are no uniqueness constraints on an Id value (other than, of course, the requirement that you cannot have two values with the same key within a single JSON map). For example, two JSEvent objects might use the same Ids in their respective "links" properties. Or within the same JSEvent object the same Id could appear in the "participants" and "alerts" properties. These situations do not imply any semantic connections among the objects. Nevertheless, a UUID [RFC4122] is typically a good choice. 1.4.2. Int Where "Int" is given as a data type, it means an integer in the range -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a floating-point double, represented as a JSON "Number". Jenkins & Stepanek Expires April 19, 2021 [Page 7] Internet-Draft JSCalendar October 2020 1.4.3. UnsignedInt Where "UnsignedInt" is given as a data type, it means an integer in the range 0 <= value <= 2^53-1, represented as a JSON "Number". 1.4.4. UTCDateTime This is a string in [RFC3339] "date-time" format, with the further restrictions that any letters MUST be in uppercase, and the time offset MUST be the character "Z". Fractional second values MUST NOT be included unless non-zero and MUST NOT have trailing zeros, to ensure there is only a single representation for each date-time. For example "2010-10-10T10:10:10.003Z" is conformant, but "2010-10-10T10:10:10.000Z" is invalid and is correctly encoded as "2010-10-10T10:10:10Z". 1.4.5. LocalDateTime This is a date-time string with no time zone/offset information. It is otherwise in the same format as UTCDateTime, including fractional seconds. For example "2006-01-02T15:04:05" and "2006-01-02T15:04:05.003" are both valid. The time zone to associate with the LocalDateTime comes from the "timeZone" property of the JSCalendar object (see Section 4.7.1). If no time zone is specified, the LocalDateTime is "floating". Floating date-times are not tied to any specific time zone. Instead, they occur in each time zone at the given wall-clock time (as opposed to the same instant point in time). A time zone may have a period of discontinuity, for example a change from standard time to daylight-savings time. When converting local date-times that fall in the discontinuity to UTC, the offset before the transition MUST be used. For example, in the America/Los_Angeles time zone, the date-time 2020-11-01T01:30:00 occurs twice: before the DST transition with a UTC offset of -07:00, and again after the transition with an offset of -08:00. When converting to UTC, we therefore use the offset before the transition (-07:00) and so it becomes 2020-11-01T08:30:00Z. Similarly, in the Australia/Melbourne time zone, the date-time 2020-10-04T02:30:00 does not exist: the clocks are moved forward one hour for DST on that day at 02:00. However, such a value may appear during calculations (see duration semantics in Section 1.4.6), or due to a change in time zone rules (so it was valid when the event was first created). Again, it is interpreted as though the offset before Jenkins & Stepanek Expires April 19, 2021 [Page 8] Internet-Draft JSCalendar October 2020 the transition is in effect (+10:00), therefore when converted to UTC we get 2020-10-03T16:30:00Z. 1.4.6. Duration Where Duration is given as a type, it means a length of time represented by a subset of ISO8601 duration format, as specified by the following ABNF [RFC5234]: dur-secfrac = "." 1*DIGIT dur-second = 1*DIGIT [dur-secfrac] "S" dur-minute = 1*DIGIT "M" [dur-second] dur-hour = 1*DIGIT "H" [dur-minute] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-day = 1*DIGIT "D" dur-week = 1*DIGIT "W" dur-cal = (dur-week [dur-day] / dur-day) duration = "P" (dur-cal [dur-time] / dur-time) In addition, the duration MUST NOT include fractional second values unless the fraction is non-zero. Fractional second values MUST NOT have trailing zeros, to ensure there is only a single representation for each duration. A duration specifies an abstract number of weeks, days, hours, minutes, and/or seconds. A duration specified using weeks or days does not always correspond to an exact multiple of 24 hours. The number of hours/minutes/seconds may vary if it overlaps a period of discontinuity in the event's time zone, for example a change from standard time to daylight-savings time. Leap seconds MUST NOT be considered when adding or subtracting a duration to/from a LocalDateTime. To add a duration to a LocalDateTime: 1. Add any week or day components of the duration to the date. A week is always the same as 7 days. 2. If a time zone applies to the LocalDateTime, convert it to a UTCDateTime following the semantics in Section 1.4.5. 3. Add any hour, minute or second components of the duration (in absolute time). 4. Convert the resulting UTCDateTime back to a LocalDateTime in the time zone that applies. Jenkins & Stepanek Expires April 19, 2021 [Page 9] Internet-Draft JSCalendar October 2020 To subtract a duration from a LocalDateTime, the steps apply in reverse: 1. If a time zone applies to the LocalDateTime, convert it to UTC following the semantics in Section 1.4.5. 2. Subtract any hour, minute or second components of the duration (in absolute time). 3. Convert the resulting UTCDateTime back to LocalDateTime in the time zone that applies. 4. Subtract any week or day components of the duration from the date. 5. If the resulting time does not exist on the date due to a discontinuity in the time zone, use the semantics in Section 1.4.5 to convert to UTC and back to get a valid LocalDateTime. These semantics match the iCalendar DURATION value type ([RFC5545], Section 3.3.6). 1.4.7. SignedDuration A SignedDuration represents a length of time that may be positive or negative and is typically used to express the offset of a point in time relative to an associated time. It is represented as a Duration, optionally preceded by a sign character. It is specified by the following ABNF: signed-duration = ["+" / "-"] duration A negative sign indicates a point in time at or before the associated time, a positive or no sign a time at or after the associated time. 1.4.8. TimeZoneId Where "TimeZoneId" is given as a data type, it means a "String" that is either a time zone name in the IANA Time Zone Database [TZDB] or a custom time zone identifier defined in the "timeZones" property (see Section 4.7.2). Where an IANA time zone is specified, the zone rules of the respective zone records apply. Custom time zones are interpreted as described in Section 4.7.2. Jenkins & Stepanek Expires April 19, 2021 [Page 10] Internet-Draft JSCalendar October 2020 1.4.9. PatchObject A PatchObject is of type "String[*]", and represents an unordered set of patches on a JSON object. Each key is a path represented in a subset of JSON pointer format [RFC6901]. The paths have an implicit leading "/", so each key is prefixed with "/" before applying the JSON pointer evaluation algorithm. A patch within a PatchObject is only valid if all of the following conditions apply: 1. The pointer MUST NOT reference inside an array (i.e., you MUST NOT insert/delete from an array; the array MUST be replaced in its entirety instead). 2. All parts prior to the last (i.e., the value after the final slash) MUST already exist on the object being patched. 3. There MUST NOT be two patches in the PatchObject where the pointer of one is the prefix of the pointer of the other, e.g., "alerts/1/offset" and "alerts". 4. The value for the patch MUST be valid for the property being set (of the correct type and obeying any other applicable restrictions), or if null the property MUST be optional. The value associated with each pointer determines how to apply that patch: o If null, remove the property from the patched object. If the key is not present in the parent, this a no-op. o Anything else: The value to set for this property (this may be a replacement or addition to the object being patched). A PatchObject does not define its own "@type" property (see Section 4.1.1). A "@type" property in a patch MUST be handled as any other patched property value. Implementations MUST reject in its entirety a PatchObject if any of its patches is invalid. Implementations MUST NOT apply partial patches. The PatchObject format is used to significantly reduce file size and duplicated content when specifying variations to a common object, such as with recurring events or when translating the data into multiple languages. It can also better preserve semantic intent if only the properties that should differ between the two objects are Jenkins & Stepanek Expires April 19, 2021 [Page 11] Internet-Draft JSCalendar October 2020 patched. For example, if one person is not going to a particular instance of a regularly scheduled event, in iCalendar you would have to duplicate the entire event in the override. In JSCalendar this is a small patch to show the difference. As only this property is patched, if the location of the event is changed, the occurrence will automatically still inherit this. 1.4.10. Relation A Relation object defines the relation to other objects, using a possibly empty set of relation types. The object that defines this relation is the linking object, while the other object is the linked object. A Relation object has the following properties: o @type: "String" (mandatory) Specifies the type of this object. This MUST be "Relation". o relation: "String[Boolean]" (optional, default: empty Object) Describes how the linked object is related to the linking object. The relation is defined as a set of relation types. If empty, the relationship between the two objects is unspecified. Keys in the set MUST be one of the following values, or specified in the property definition where the Relation object is used, or a value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): * "first": The linked object is the first in a series the linking object is part of. * "next": The linked object is the next in a series the linking object is part of. * "child": The linked object is a subpart of the linking object. * "parent": The linking object is a subpart of the linked object. The value for each key in the map MUST be true. 1.4.11. Link A Link object represents an external resource associated with the linking object. It has the following properties: o @type: "String" (mandatory) Jenkins & Stepanek Expires April 19, 2021 [Page 12] Internet-Draft JSCalendar October 2020 Specifies the type of this object. This MUST be "Link". o href: "String" (mandatory) A URI [RFC3986] from which the resource may be fetched. This MAY be a "data:" URL [RFC2397], but it is recommended that the file be hosted on a server to avoid embedding arbitrarily large data in JSCalendar object instances. o cid: "String" (optional) This MUST be a valid "content-id" value according to the definition of Section 2 in [RFC2392]. The value MUST be unique within this Link object but has no meaning beyond that. It MAY be different from the link id for this Link object. o contentType: "String" (optional) The media type [RFC6838] of the resource, if known. o size: "UnsignedInt" (optional) The size, in octets, of the resource when fully decoded (i.e., the number of octets in the file the user would download), if known. Note that this is an informational estimate, and implementations must be prepared to handle the actual size being quite different when the resource is fetched. o rel: "String" (optional) Identifies the relation of the linked resource to the object. If set, the value MUST be a relation type from the IANA registry [LINKRELS], as established in [RFC8288]. o display: "String" (optional) Describes the intended purpose of a link to an image. If set, the "rel" property MUST be set to "icon". The value MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): * "badge": an image meant to be displayed alongside the title of the object. * "graphic": a full image replacement for the object itself. Jenkins & Stepanek Expires April 19, 2021 [Page 13] Internet-Draft JSCalendar October 2020 * "fullsize": an image that is used to enhance the object. * "thumbnail": a smaller variant of "fullsize" to be used when space for the image is constrained. o title: "String" (optional) A human-readable plain-text description of the resource. 2. JSCalendar Objects This section describes the calendar object types specified by JSCalendar. 2.1. JSEvent Media type: "application/jscalendar+json;type=jsevent" A JSEvent represents a scheduled amount of time on a calendar, typically a meeting, appointment, reminder or anniversary. It is required to start at a certain point in time and typically has a non- zero duration. Multiple participants may partake in the event at multiple locations. The @type (Section 4.1.1) property value MUST be "jsevent". 2.2. JSTask Media type: "application/jscalendar+json;type=jstask" A JSTask represents an action-item, assignment, to-do or work item. It may start and be due at certain points in time, may take some estimated time to complete, and may recur, none of which is required. The @type (Section 4.1.1) property value MUST be "jstask". 2.3. JSGroup Media type: "application/jscalendar+json;type=jsgroup" A JSGroup is a collection of JSEvent (Section 2.1) and/or JSTask (Section 2.2) objects. Typically, objects are grouped by topic (e.g., by keywords) or calendar membership. The @type (Section 4.1.1) property value MUST be "jsgroup". Jenkins & Stepanek Expires April 19, 2021 [Page 14] Internet-Draft JSCalendar October 2020 3. Structure of JSCalendar Objects A JSCalendar object is a JSON object [RFC8259], which MUST be valid I-JSON (a stricter subset of JSON) [RFC7493]. Property names and values are case-sensitive. The object has a collection of properties, as specified in the following sections. Properties are specified as being either mandatory or optional. Optional properties may have a default value, if explicitly specified in the property definition. 3.1. Object Type JSCalendar objects MUST name their type in the "@type" property, if not explicitly specified otherwise for the respective object type. A notable exception to this rule is the PatchObject (Section 1.4.9). 3.2. Normalization and Equivalence JSCalendar aims to provide unambiguous definitions for value types and properties, but does not define a general normalization or equivalence method for JSCalendar objects and types. This is because the notion of equivalence might range from byte-level equivalence to semantic equivalence, depending on the respective use case. Normalization of JSCalendar objects is hindered because of the following reasons: o Custom JSCalendar properties may contain arbitrary JSON values, including arrays. However, equivalence of arrays might or might not depend on the order of elements, depending on the respective property definition. o Several JSCalendar property values are defined as URIs and media types, but normalization of these types is inherently protocol- and scheme-specific, depending on the use-case of the equivalence definition (see Section 6 of [RFC3986]). Considering this, the definition of equivalence and normalization is left to client and server implementations and to be negotiated by a calendar exchange protocol or defined elsewhere. 3.3. Vendor-specific Property Extensions, Values and Types Vendors MAY add additional properties to the calendar object to support their custom features. To avoid conflict, the names of these properties MUST be prefixed by a domain name controlled by the vendor followed by a colon, e.g., "example.com:customprop". If the value is Jenkins & Stepanek Expires April 19, 2021 [Page 15] Internet-Draft JSCalendar October 2020 a new JSCalendar object, it either MUST include a "@type" property or it MUST explicitly be specified to not require a type designator. The type name MUST be prefixed with a domain name controlled by the vendor. Some JSCalendar properties allow vendor-specific value extensions. Such vendor-specific values MUST be prefixed by a domain name controlled by the vendor followed by a colon, e.g., "example.com:customrel". Vendors are strongly encouraged to register any new property values or extensions that are useful to other systems as well, rather than use a vendor-specific prefix. 4. Common JSCalendar Properties This section describes the properties that are common to the various JSCalendar object types. Specific JSCalendar object types may only support a subset of these properties. The object type definitions in Section 5 describe the set of supported properties per type. 4.1. Metadata Properties 4.1.1. @type Type: "String" (mandatory). Specifies the type which this object represents. This MUST be one of the following values: o "jsevent": a JSCalendar event (Section 2.1). o "jstask": a JSCalendar task (Section 2.2). o "jsgroup": a JSCalendar group (Section 2.3). 4.1.2. uid Type: "String" (mandatory). A globally unique identifier, used to associate the object as the same across different systems, calendars and views. The value of this property MUST be unique across all JSCalendar objects, even if they are of different type. [RFC4122] describes a range of established algorithms to generate universally unique identifiers (UUID). UUID version 4, described in Section 4.4 of [RFC4122], is RECOMMENDED. Jenkins & Stepanek Expires April 19, 2021 [Page 16] Internet-Draft JSCalendar October 2020 For compatibility with [RFC5545] UIDs, implementations MUST be able to receive and persist values of at least 255 octets for this property, but they MUST NOT truncate values in the middle of a UTF-8 multi-octet sequence. 4.1.3. relatedTo Type: "String[Relation]" (optional). Relates the object to other JSCalendar objects. This is represented as a map of the UIDs of the related objects to information about the relation. If an object is split to make a "this and future" change to a recurrence, the original object MUST be truncated to end at the previous occurrence before this split, and a new object created to represent all the occurrences after the split. A "next" relation MUST be set on the original object's relatedTo property for the UID of the new object. A "first" relation for the UID of the first object in the series MUST be set on the new object. Clients can then follow these UIDs to get the complete set of objects if the user wishes to modify them all at once. 4.1.4. prodId Type: "String" (optional). The identifier for the product that last updated the JSCalendar object. This should be set whenever the data in the object is modified (i.e., whenever the "updated" property is set). The vendor of the implementation MUST ensure that this is a globally unique identifier, using some technique such as an FPI value, as defined in [ISO.9070.1991]. This property SHOULD NOT be used to alter the interpretation of a JSCalendar object beyond the semantics specified in this document. For example, it is not to be used to further the understanding of non-standard properties, a practice that is known to cause long-term interoperability problems. 4.1.5. created Type: "UTCDateTime" (optional). The date and time this object was initially created. Jenkins & Stepanek Expires April 19, 2021 [Page 17] Internet-Draft JSCalendar October 2020 4.1.6. updated Type: "UTCDateTime" (mandatory). The date and time the data in this object was last modified (or its creation date/time if not modified since). 4.1.7. sequence Type: "UnsignedInt" (optional, default: 0). Initially zero, this MUST be incremented by one every time a change is made to the object, except if the change only modifies the "participants" property (see Section 4.4.5). This is used as part of iTIP [RFC5546] to know which version of the object a scheduling message relates to. 4.1.8. method Type: "String" (optional). The iTIP [RFC5546] method, in lowercase. This MUST only be present if the JSCalendar object represents an iTIP scheduling message. 4.2. What and Where Properties 4.2.1. title Type: "String" (optional, default: empty String). A short summary of the object. 4.2.2. description Type: "String" (optional, default: empty String). A longer-form text description of the object. The content is formatted according to the "descriptionContentType" property. 4.2.3. descriptionContentType Type: "String" (optional, default: "text/plain"). Describes the media type [RFC6838] of the contents of the "description" property. Media types MUST be sub-types of type "text", and SHOULD be "text/plain" or "text/html" [MEDIATYPES]. They MAY include parameters and the "charset" parameter value MUST be Jenkins & Stepanek Expires April 19, 2021 [Page 18] Internet-Draft JSCalendar October 2020 "utf-8", if specified. Descriptions of type "text/html" MAY contain "cid" URLs [RFC2392] to reference links in the calendar object by use of the "cid" property of the Link object. 4.2.4. showWithoutTime Type: "Boolean" (optional, default: false). Indicates that the time is not important to display to the user when rendering this calendar object. An example of this is an event that conceptually occurs all day or across multiple days, such as "New Year's Day" or "Italy Vacation". While the time component is important for free-busy calculations and checking for scheduling clashes, calendars may choose to omit displaying it and/or display the object separately to other objects to enhance the user's view of their schedule. Such events are also commonly known as "all-day" events. 4.2.5. locations Type: "Id[Location]" (optional). A map of location ids to Location objects, representing locations associated with the object. A Location object has the following properties. It MUST have at least one property other than the "relativeTo" property. o @type: "String" (mandatory) Specifies the type of this object. This MUST be "Location". o name: "String" (optional) The human-readable name of the location. o description: "String" (optional) Human-readable, plain-text instructions for accessing this location. This may be an address, set of directions, door access code, etc. o locationTypes: "String[Boolean]" (optional) A set of one or more location types that describe this location. All types MUST be from the Location Types Registry [LOCATIONTYPES] as defined in [RFC4589]. The set is represented as a map, with Jenkins & Stepanek Expires April 19, 2021 [Page 19] Internet-Draft JSCalendar October 2020 the keys being the location types. The value for each key in the map MUST be true. o relativeTo: "String" (optional) Specifies the relation between this location and the time of the JSCalendar object. This is primarily to allow events representing travel to specify the location of departure (at the start of the event) and location of arrival (at the end); this is particularly important if these locations are in different time zones, as a client may wish to highlight this information for the user. This MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3). Any value the client or server doesn't understand should be treated the same as if this property is omitted. * "start": The event/task described by this JSCalendar object occurs at this location at the time the event/task starts. * "end": The event/task described by this JSCalendar object occurs at this location at the time the event/task ends. o timeZone: "TimeZoneId" (optional) A time zone for this location. o coordinates: "String" (optional) A "geo:" URI [RFC5870] for the location. o links: "Id[Link]" (optional) A map of link ids to Link objects, representing external resources associated with this location, for example a vCard or image. If there are no links, this MUST be omitted (rather than specified as an empty set). 4.2.6. virtualLocations Type: "Id[VirtualLocation]" (optional). A map of virtual location ids to VirtualLocation objects, representing virtual locations, such as video conferences or chat rooms, associated with the object. A VirtualLocation object has the following properties. Jenkins & Stepanek Expires April 19, 2021 [Page 20] Internet-Draft JSCalendar October 2020 o @type: "String" (mandatory) Specifies the type of this object. This MUST be "VirtualLocation". o name: "String" (optional, default: empty String) The human-readable name of the virtual location. o description: "String" (optional) Human-readable plain-text instructions for accessing this virtual location. This may be a conference access code, etc. o uri: "String" (mandatory) A URI [RFC3986] that represents how to connect to this virtual location. This may be a telephone number (represented using the "tel:" scheme, e.g., "tel:+1-555-555-5555") for a teleconference, a web address for online chat, or any custom URI. 4.2.7. links Type: "Id[Link]" (optional). A map of link ids to Link objects, representing external resources associated with the object. Links with a rel of "enclosure" MUST be considered by the client as attachments for download. Links with a rel of "describedby" MUST be considered by the client to be an alternative representation of the description. Links with a rel of "icon" MUST be considered by the client to be an image that it may use when presenting the calendar data to a user. The "display" property may be set to indicate the purpose of this image. 4.2.8. locale Type: "String" (optional). The language tag as defined in [RFC5646] that best describes the locale used for the text in the calendar object, if known. Jenkins & Stepanek Expires April 19, 2021 [Page 21] Internet-Draft JSCalendar October 2020 4.2.9. keywords Type: "String[Boolean]" (optional). A set of keywords or tags that relate to the object. The set is represented as a map, with the keys being the keywords. The value for each key in the map MUST be true. 4.2.10. categories Type: "String[Boolean]" (optional). A set of categories that relate to the calendar object. The set is represented as a map, with the keys being the categories specified as URIs. The value for each key in the map MUST be true. In contrast to keywords, categories typically are structured. For example, a vendor owning the domain "example.com" might define the categories "http://example.com/categories/sports/american-football" and "http://example.com/categories/music/r-b". 4.2.11. color Type: "String" (optional). A color clients MAY use when displaying this calendar object. The value is a color name taken from the set of names defined in Section 4.3 of CSS Color Module Level 3 [COLORS], or an RGB value in hexadecimal notation, as defined in Section 4.2.1 of CSS Color Module Level 3. 4.3. Recurrence Properties Some events and tasks occur at regular or irregular intervals. Rather than having to copy the data for every occurrence there can be a master event with rules to generate recurrences, and/or overrides that add extra dates or exceptions to the rules. The recurrence set is the complete set of instances for an object. It is generated by considering the following properties in order, all of which are optional: 1. The recurrenceRules property (Section 4.3.2) generates a set of extra date-times on which the object occurs. 2. The excludedRecurrenceRules property (Section 4.3.3) generates a set of date-times that are to be removed from the previously generated set of date-times on which the object occurs. Jenkins & Stepanek Expires April 19, 2021 [Page 22] Internet-Draft JSCalendar October 2020 3. The recurrenceOverrides property (Section 4.3.4) defines date- times which are added or excluded to form the final set. (This property may also contain changes to the object to apply to particular instances.) 4.3.1. recurrenceId Type: "LocalDateTime" (optional). If present, this JSCalendar object represents one occurrence of a recurring JSCalendar object. If present the "recurrenceRules" and "recurrenceOverrides" properties MUST NOT be present. The value is a date-time either produced by the "recurrenceRules" of the master event, or added as a key to the "recurrenceOverrides" property of the master event. 4.3.2. recurrenceRules Type: "RecurrenceRule[]" (optional). Defines a set of recurrence rules (repeating patterns) for recurring calendar objects. A JSEvent recurs by applying the recurrence rules to the "start" date-time. A JSTask recurs by applying the recurrence rules to the "start" date- time, if defined, otherwise it recurs by the "due" date-time, if defined. If the task defines neither a "start" nor "due" date-time, it MUST NOT define a "recurrenceRules" property. If multiple recurrence rules are given, each rule is to be applied and then the union of the results used, ignoring any duplicates. A RecurrenceRule object is a JSON object mapping of a RECUR value type in iCalendar [RFC5545] [RFC7529] and has the same semantics. It has the following properties: o @type: "String" (mandatory) Specifies the type of this object. This MUST be "RecurrenceRule". o frequency: "String" (mandatory) The time span covered by each iteration of this recurrence rule (see Section 4.3.2.1 for full semantics). This MUST be one of the following values: Jenkins & Stepanek Expires April 19, 2021 [Page 23] Internet-Draft JSCalendar October 2020 * "yearly" * "monthly" * "weekly" * "daily" * "hourly" * "minutely" * "secondly" This is the FREQ part from iCalendar, converted to lowercase. o interval: "UnsignedInt" (optional, default: 1) The interval of iteration periods at which the recurrence repeats. If included, it MUST be an integer >= 1. This is the INTERVAL part from iCalendar. o rscale: "String" (optional, default: "gregorian") The calendar system in which this recurrence rule operates, in lowercase. This MUST be either a CLDR-registered calendar system name [CLDR], or a vendor-specific value (see Section 3.3). This is the RSCALE part from iCalendar RSCALE [RFC7529], converted to lowercase. o skip: "String" (optional, default: "omit") The behaviour to use when the expansion of the recurrence produces invalid dates. This property only has an effect if the frequency is "yearly" or "monthly". It MUST be one of the following values: * "omit" * "backward" * "forward" This is the SKIP part from iCalendar RSCALE [RFC7529], converted to lowercase. o firstDayOfWeek: "String" (optional, default: "mo") Jenkins & Stepanek Expires April 19, 2021 [Page 24] Internet-Draft JSCalendar October 2020 The day on which the week is considered to start, represented as a lowercase abbreviated two-letter English day of the week. If included, it MUST be one of the following values: * "mo" * "tu" * "we" * "th" * "fr" * "sa" * "su" This is the WKST part from iCalendar. o byDay: "NDay[]" (optional) Days of the week on which to repeat. An "NDay" object has the following properties: * @type: "String" (mandatory) Specifies the type of this object. This MUST be "NDay". * day: "String" (mandatory) A day of the week on which to repeat; the allowed values are the same as for the "firstDayOfWeek" RecurrenceRule property. This is the day-of-the-week of the BYDAY part in iCalendar, converted to lowercase. * nthOfPeriod: "Int" (optional) If present, rather than representing every occurrence of the weekday defined in the "day" property, it represents only a specific instance within the recurrence period. The value can be positive or negative, but MUST NOT be zero. A negative integer means nth-last of period. This is the ordinal part of the BYDAY value in iCalendar (e.g., 1 or -3). Jenkins & Stepanek Expires April 19, 2021 [Page 25] Internet-Draft JSCalendar October 2020 o byMonthDay: "Int[]" (optional) Days of the month on which to repeat. Valid values are between 1 and the maximum number of days any month may have in the calendar given by the "rscale" property, and the negative values of these numbers. For example, in the Gregorian calendar valid values are 1 to 31 and -31 to -1. Negative values offset from the end of the month. The array MUST have at least one entry if included. This is the BYMONTHDAY part in iCalendar. o byMonth: "String[]" (optional) The months in which to repeat. Each entry is a string representation of a number, starting from "1" for the first month in the calendar (e.g., "1" means January with the Gregorian calendar), with an optional "L" suffix (see [RFC7529]) for leap months (this MUST be uppercase, e.g., "3L"). The array MUST have at least one entry if included. This is the BYMONTH part from iCalendar. o byYearDay: "Int[]" (optional) The days of the year on which to repeat. Valid values are between 1 and the maximum number of days any year may have in the calendar given by the "rscale" property, and the negative values of these numbers. For example, in the Gregorian calendar valid values are 1 to 366 and -366 to -1. Negative values offset from the end of the year. The array MUST have at least one entry if included. This is the BYYEARDAY part from iCalendar. o byWeekNo: "Int[]" (optional) Weeks of the year in which to repeat. Valid values are between 1 and the maximum number of weeks any year may have in the calendar given by the "rscale" property, and the negative values of these numbers. For example, in the Gregorian calendar valid values are 1 to 53 and -53 to -1. The array MUST have at least one entry if included. This is the BYWEEKNO part from iCalendar. o byHour: "UnsignedInt[]" (optional) Jenkins & Stepanek Expires April 19, 2021 [Page 26] Internet-Draft JSCalendar October 2020 The hours of the day in which to repeat. Valid values are 0 to 23. The array MUST have at least one entry if included. This is the BYHOUR part from iCalendar. o byMinute: "UnsignedInt[]" (optional) The minutes of the hour in which to repeat. Valid values are 0 to 59. The array MUST have at least one entry if included. This is the BYMINUTE part from iCalendar. o bySecond: "UnsignedInt[]" (optional) The seconds of the minute in which to repeat. Valid values are 0 to 60. The array MUST have at least one entry if included. This is the BYSECOND part from iCalendar. o bySetPosition: "Int[]" (optional) The occurrences within the recurrence interval to include in the final results. Negative values offset from the end of the list of occurrences. The array MUST have at least one entry if included. This is the BYSETPOS part from iCalendar. o count: "UnsignedInt" (optional) The number of occurrences at which to range-bound the recurrence. This MUST NOT be included if an "until" property is specified. This is the COUNT part from iCalendar. o until: "LocalDateTime" (optional) The date-time at which to finish recurring. The last occurrence is on or before this date-time. This MUST NOT be included if a "count" property is specified. Note: if not specified otherwise for a specific JSCalendar object, this date is to be interpreted in the time zone specified in the JSCalendar object's "timeZone" property. This is the UNTIL part from iCalendar. 4.3.2.1. Interpreting recurrence rules A recurrence rule specifies a set of date-times for recurring calendar objects. A recurrence rule has the following semantics. Note, wherever "year", "month" or "day of month" is used, this is Jenkins & Stepanek Expires April 19, 2021 [Page 27] Internet-Draft JSCalendar October 2020 within the calendar system given by the "rscale" property, which defaults to "gregorian" if omitted. 1. A set of candidates is generated. This is every second within a period defined by the frequency property value: * "yearly": every second from midnight on the 1st day of a year (inclusive) to midnight the 1st day of the following year (exclusive). If skip is not "omit", the calendar system has leap months and there is a byMonth property, generate candidates for the leap months even if they don't occur in this year. If skip is not "omit" and there is a byMonthDay property, presume each month has the maximum number of days any month may have in this calendar system when generating candidates, even if it's more than this month actually has. * "monthly": every second from midnight on the 1st day of a month (inclusive) to midnight on the 1st of the following month (exclusive). If skip is not "omit" and there is a byMonthDay property, presume the month has the maximum number of days any month may have in this calendar system when generating candidates, even if it's more than this month actually has. * "weekly": every second from midnight (inclusive) on the first day of the week (as defined by the firstDayOfWeek property, or Monday if omitted), to midnight 7 days later (exclusive). * "daily": every second from midnight at the start of the day (inclusive) to midnight at the end of the day (exclusive). * "hourly": every second from the beginning of the hour (inclusive) to the beginning of the next hour (exclusive). * "minutely": every second from the beginning of the minute (inclusive) to the beginning of the next minute (exclusive). * "secondly": the second itself, only. 2. Each date-time candidate is compared against all of the byX properties of the rule except bySetPosition. If any property in the rule does not match the date-time, the date-time is eliminated. Each byX property is an array; the date-time matches Jenkins & Stepanek Expires April 19, 2021 [Page 28] Internet-Draft JSCalendar October 2020 the property if it matches any of the values in the array. The properties have the following semantics: * byMonth: the date-time is in the given month. * byWeekNo: the date-time is in the nth week of the year. Negative numbers mean the nth last week of the year. This corresponds to weeks according to week numbering as defined in ISO.8601.2004, with a week defined as a seven day period, starting on the firstDayOfWeek property value or Monday if omitted. Week number one of the calendar year is the first week that contains at least four days in that calendar year. If the date-time is not valid (this may happen when generating candidates with a skip property in effect), it is always eliminated by this property. * byYearDay: the date-time is on the nth day of year. Negative numbers mean the nth last day of the year. If the date-time is not valid (this may happen when generating candidates with a skip property in effect), it is always eliminated by this property. * byMonthDay: the date-time is on the given day of the month. Negative numbers mean the nth last day of the month. * byDay: the date-time is on the given day of the week. If the day is prefixed by a number, it is the nth occurrence of that day of the week within the month (if frequency is monthly) or year (if frequency is yearly). Negative numbers means nth last occurrence within that period. * byHour: the date-time has the given hour value. * byMinute: the date-time has the given minute value. * bySecond: the date-time has the given second value. If a skip property is defined and is not "omit", there may be candidates that do not correspond to valid dates (e.g., 31st February in the Gregorian calendar). In this case, the properties MUST be considered in the order above and: 1. After applying the byMonth filter, if the candidate's month is invalid for the given year, increment it (if skip is "forward") or decrement it (if skip is "backward") until a valid month is found, incrementing/decrementing the year as Jenkins & Stepanek Expires April 19, 2021 [Page 29] Internet-Draft JSCalendar October 2020 well if passing through the beginning/end of the year. This only applies to calendar systems with leap months. 2. After applying the byMonthDay filter, if the day of the month is invalid for the given month and year, change the date to the first day of the next month (if skip is "forward") or the last day of the current month (if skip is "backward"). 3. If any valid date produced after applying the skip is already a candidate, eliminate the duplicate. (For example after adjusting, 30th February and 31st February would both become the same "real" date, so one is eliminated as a duplicate.) 3. If a bySetPosition property is included, this is now applied to the ordered list of remaining dates. This property specifies the indexes of date-times to keep; all others should be eliminated. Negative numbers are indexes from the end of the list, with -1 being the last item. 4. Any date-times before the start date of the event are eliminated (see below for why this might be needed). 5. If a skip property is included and is not "omit", eliminate any date-times that have already been produced by previous iterations of the algorithm. (This is not possible if skip is "omit".) 6. If further dates are required (we have not reached the until date, or count limit) skip the next (interval - 1) sets of candidates, then continue from step 1. When determining the set of occurrence dates for an event or task, the following extra rules must be applied: 1. The initial date-time to which the rule is applied (the "start" date-time for events; the "start" or "due" date-time for tasks) is always the first occurrence in the expansion (and is counted if the recurrence is limited by a "count" property), even if it would normally not match the rule. 2. The first set of candidates to consider is that which would contain the initial date-time. This means the first set may include candidates before the initial date-time; such candidates are eliminated from the results in step (4) as outlined before. 3. The following properties MUST be implicitly added to the rule under the given conditions: Jenkins & Stepanek Expires April 19, 2021 [Page 30] Internet-Draft JSCalendar October 2020 * If frequency is not "secondly" and no bySecond property: Add a bySecond property with the sole value being the seconds value of the initial date-time. * If frequency is not "secondly" or "minutely", and no byMinute property: Add a byMinute property with the sole value being the minutes value of the initial date-time. * If frequency is not "secondly", "minutely" or "hourly" and no byHour property: Add a byHour property with the sole value being the hours value of the initial date-time. * If frequency is "weekly" and no byDay property: Add a byDay property with the sole value being the day-of-the-week of the initial date-time. * If frequency is "monthly" and no byDay property and no byMonthDay property: Add a byMonthDay property with the sole value being the day-of-the-month of the initial date-time. * If frequency is "yearly" and no byYearDay property: + If there are no byMonth or byWeekNo properties, and either there is a byMonthDay property or there is no byDay property: Add a byMonth property with the sole value being the month of the initial date-time. + If there is no byMonthDay, byWeekNo or byDay properties: Add a byMonthDay property with the sole value being the day-of-the-month of the initial date-time. + If there is a byWeekNo property and no byMonthDay or byDay properties: Add a byDay property with the sole value being the day-of-the-week of the initial date-time. 4.3.3. excludedRecurrenceRules Type: "RecurrenceRule[]" (optional). Defines a set of recurrence rules (repeating patterns) for date-times on which the object will not occur. The rules are interpreted the same as for the "recurrenceRules" property (see Section 4.3.2), with the exception that the initial date-time to which the rule is applied (the "start" date-time for events; the "start" or "due" date-time for tasks) is only considered part of the expansion if it matches the rule. The resulting set of date-times are then removed from those generated by the recurrenceRules property, as described in Section 4.3. Jenkins & Stepanek Expires April 19, 2021 [Page 31] Internet-Draft JSCalendar October 2020 4.3.4. recurrenceOverrides Type: "LocalDateTime[PatchObject]" (optional). A map of the recurrence ids (the date-time produced by the recurrence rule) to an object of patches to apply to the generated occurrence object. If the recurrence id does not match a date-time from the recurrence rule (or no rule is specified), it is to be treated as an additional occurrence (like an RDATE from iCalendar). The patch object may often be empty in this case. If the patch object defines the "excluded" property of an occurrence to be true, this occurrence is omitted from the final set of recurrences for the calendar object (like an EXDATE from iCalendar). Such a patch object MUST NOT patch any other property. By default, an occurrence inherits all properties from the main object except the start (or due) date-time, which is shifted to match the recurrence id LocalDateTime. However, individual properties of the occurrence can be modified by a patch, or multiple patches. It is valid to patch the "start" property value, and this patch takes precedence over the value generated from the recurrence id. Both the recurrence id as well as the patched "start" date-time may occur before the original JSCalendar object's "start" or "due" date. A pointer in the PatchObject MUST be ignored if it starts with one of the following prefixes: o @type o excludedRecurrenceRules o method o privacy o prodId o recurrenceId o recurrenceOverrides o recurrenceRules o relatedTo Jenkins & Stepanek Expires April 19, 2021 [Page 32] Internet-Draft JSCalendar October 2020 o replyTo o uid 4.3.5. excluded Type: "Boolean" (optional, default: false). Defines if this object is an overridden, excluded instance of a recurring JSCalendar object (see Section 4.3.4). If this property value is true, this calendar object instance MUST be removed from the occurrence expansion. The absence of this property, or the presence of its default value false, indicates that this instance MUST be included in the occurrence expansion. 4.4. Sharing and Scheduling Properties 4.4.1. priority Type: "Int" (optional, default: 0). Specifies a priority for the calendar object. This may be used as part of scheduling systems to help resolve conflicts for a time period. The priority is specified as an integer in the range 0 to 9. A value of 0 specifies an undefined priority, for which the treatment will vary by situation. A value of 1 is the highest priority. A value of 2 is the second highest priority. Subsequent numbers specify a decreasing ordinal priority. A value of 9 is the lowest priority. Other integer values are reserved for future use. 4.4.2. freeBusyStatus Type: "String" (optional, default: "busy"). Specifies how this calendar object should be treated when calculating free-busy state. This MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): o "free": The object should be ignored when calculating whether the user is busy. o "busy": The object should be included when calculating whether the user is busy. Jenkins & Stepanek Expires April 19, 2021 [Page 33] Internet-Draft JSCalendar October 2020 4.4.3. privacy Type: "String" (optional, default: "public"). Calendar objects are normally collected together and may be shared with other users. The privacy property allows the object owner to indicate that it should not be shared, or should only have the time information shared but the details withheld. Enforcement of the restrictions indicated by this property are up to the API via which this object is accessed. This property MUST NOT affect the information sent to scheduled participants; it is only interpreted by protocols that share the calendar objects belonging to one user with other users. The value MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor- specific value (see Section 3.3). Any value the client or server doesn't understand should be preserved but treated as equivalent to "private". o "public": The full details of the object are visible to those whom the object's calendar is shared with. o "private": The details of the object are hidden; only the basic time and metadata is shared. The following properties MAY be shared, any other properties MUST NOT be shared: * @type * created * due * duration * estimatedDuration * freeBusyStatus * privacy * recurrenceOverrides. Only patches which apply to another permissible property are allowed to be shared. * sequence * showWithoutTime Jenkins & Stepanek Expires April 19, 2021 [Page 34] Internet-Draft JSCalendar October 2020 * start * timeZone * timeZones * uid * updated o "secret": The object is hidden completely (as though it did not exist) when the calendar this object is in is shared. 4.4.4. replyTo Type: "String[String]" (optional). Represents methods by which participants may submit their response to the organizer of the calendar object. The keys in the property value are the available methods and MUST only contain ASCII alphanumeric characters (A-Za-z0-9). The value is a URI for the method specified in the key. Future methods may be defined in future specifications and registered with IANA; a calendar client MUST ignore any method it does not understand, but MUST preserve the method key and URI. This property MUST be omitted if no method is defined (rather than being specified as an empty object). The following methods are defined: o "imip": The organizer accepts an iMIP [RFC6047] response at this email address. The value MUST be a "mailto:" URI. o "web": Opening this URI in a web browser will provide the user with a page where they can submit a reply to the organizer. The value MUST be a URL using the "https:" scheme. o "other": The organizer is identified by this URI but the method for submitting the response is undefined. 4.4.5. participants Type: "Id[Participant]" (optional). A map of participant ids to participants, describing their participation in the calendar object. Jenkins & Stepanek Expires April 19, 2021 [Page 35] Internet-Draft JSCalendar October 2020 If this property is set and any participant has a sendTo property, then the "replyTo" property of this calendar object MUST define at least one reply method. A Participant object has the following properties: o @type: "String" (mandatory) Specifies the type of this object. This MUST be "Participant". o name: "String" (optional) The display name of the participant (e.g., "Joe Bloggs"). o email: "String" (optional) The email address for the participant. o description: "String" (optional). A plain text description of this participant. For example, this may include more information about their role in the event or how best to contact them. o sendTo: "String[String]" (optional) Represents methods by which the participant may receive the invitation and updates to the calendar object. The keys in the property value are the available methods and MUST only contain ASCII alphanumeric characters (A-Za-z0-9). The value is a URI for the method specified in the key. Future methods may be defined in future specifications and registered with IANA; a calendar client MUST ignore any method it does not understand, but MUST preserve the method key and URI. This property MUST be omitted if no method is defined (rather than being specified as an empty object). The following methods are defined: * "imip": The participant accepts an iMIP [RFC6047] request at this email address. The value MUST be a "mailto:" URI. It MAY be different from the value of the participant's "email" property. * "other": The participant is identified by this URI but the method for submitting the invitation is undefined. Jenkins & Stepanek Expires April 19, 2021 [Page 36] Internet-Draft JSCalendar October 2020 o kind: "String" (optional) What kind of entity this participant is, if known. This MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3). Any value the client or server doesn't understand should be treated the same as if this property is omitted. * "individual": a single person * "group": a collection of people invited as a whole * "location": a physical location that needs to be scheduled, e.g., a conference room * "resource": a non-human resource other than a location, such as a projector o roles: "String[Boolean]" (mandatory) A set of roles that this participant fulfills. At least one role MUST be specified for the participant. The keys in the set MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): * "owner": The participant is an owner of the object. This signifies they have permission to make changes to it that affect the other participants. Non-owner participants may only change properties that just affect themselves (for example setting their own alerts or changing their rsvp status). * "attendee": The participant is expected to be present at the event. * "optional": The participant's involvement with the event is optional. This is expected to be primarily combined with the "attendee" role. * "informational": The participant is copied for informational reasons, and is not expected to attend. * "chair": The participant is in charge of the event/task when it occurs. Jenkins & Stepanek Expires April 19, 2021 [Page 37] Internet-Draft JSCalendar October 2020 * "contact": The participant is someone that may be contacted for information about the event. The value for each key in the map MUST be true. It is expected that no more than one of the roles "attendee" and "informational" be present; if more than one are given, "attendee" takes precedence over "informational". Roles that are unknown to the implementation MUST be preserved. o locationId: "String" (optional) The location at which this participant is expected to be attending. If the value does not correspond to any location id in the "locations" property of the JSCalendar object, this MUST be treated the same as if the participant's locationId were omitted. o language: "String" (optional) The language tag as defined in [RFC5646] that best describes the participant's preferred language, if known. o participationStatus: "String" (optional, default: "needs-action") The participation status, if any, of this participant. The value MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): * "needs-action": No status yet set by the participant. * "accepted": The invited participant will participate. * "declined": The invited participant will not participate. * "tentative": The invited participant may participate. * "delegated": The invited participant has delegated their attendance to another participant, as specified in the delegatedTo property. o participationComment: "String" (optional) A note from the participant to explain their participation status. o expectReply: "Boolean" (optional, default: false) Jenkins & Stepanek Expires April 19, 2021 [Page 38] Internet-Draft JSCalendar October 2020 If true, the organizer is expecting the participant to notify them of their participation status. o scheduleAgent: "String" (optional, default: "server") Who is responsible for sending scheduling messages with this calendar object to the participant. The value MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): * "server": The calendar server will send the scheduling messages. * "client": The calendar client will send the scheduling messages. * "none": No scheduling messages are to be sent to this participant. o scheduleForceSend: "Boolean" (optional, default: false) A client may set the property on a participant to true to request that the server send a scheduling message to the participant when it would not normally do so (e.g. if no significant change is made the object or the scheduleAgent is set to client). The property MUST NOT be stored in the JSCalendar object on the server or appear in a scheduling message. o scheduleSequence: "UnsignedInt" (optional, default: 0) The sequence number of the last response from the participant. If defined, this MUST be a non-negative integer. This can be used to determine whether the participant has sent a new response following significant changes to the calendar object, and to determine if future responses are responding to a current or older view of the data. o scheduleStatus: "String[]" (optional) A list of status codes, as defined in Section 3.8.8.3 of [RFC5545], returned from the processing of the most recent scheduling message sent to this participant. Servers MUST only add or change this property when they send a scheduling message to the participant. Clients SHOULD NOT change Jenkins & Stepanek Expires April 19, 2021 [Page 39] Internet-Draft JSCalendar October 2020 or remove this property if it was provided by the server. Clients MAY add, change, or remove the property for participants where the client is handling the scheduling. This property MUST NOT be included in scheduling messages. o scheduleUpdated: "UTCDateTime" (optional) The timestamp for the most recent response from this participant. This is the "updated" property of the last response when using iTIP. It can be compared to the "updated" property in future responses to detect and discard older responses delivered out of order. o invitedBy: "String" (optional) The participant id of the participant who invited this one, if known. o delegatedTo: "String[Boolean]" (optional) A set of participant ids that this participant has delegated their participation to. Each key in the set MUST be the id of a participant. The value for each key in the map MUST be true. If there are no delegates, this MUST be omitted (rather than specified as an empty set). o delegatedFrom: "String[Boolean]" (optional) A set of participant ids that this participant is acting as a delegate for. Each key in the set MUST be the id of a participant. The value for each key in the map MUST be true. If there are no delegators, this MUST be omitted (rather than specified as an empty set). o memberOf: "String[Boolean]" (optional) A set of group participants that were invited to this calendar object, which caused this participant to be invited due to their membership in the group(s). Each key in the set MUST be the id of a participant. The value for each key in the map MUST be true. If there are no groups, this MUST be omitted (rather than specified as an empty set). o links: "Id[Link]" (optional) Jenkins & Stepanek Expires April 19, 2021 [Page 40] Internet-Draft JSCalendar October 2020 A map of link ids to Link objects, representing external resources associated with this participant, for example a vCard or image. If there are no links, this MUST be omitted (rather than specified as an empty set). o progress: "String" (optional; only allowed for participants of a JSTask). Represents the progress of the participant for this task. It MUST NOT be set if the "participationStatus" of this participant is any value other than "accepted". See Section 5.2.5 for allowed values and semantics. o progressUpdated: "UTCDateTime" (optional; only allowed for participants of a JSTask). Specifies the date-time the progress property was last set on this participant. See Section 5.2.6 for allowed values and semantics. o percentComplete: "UnsignedInt" (optional; only allowed for participants of a JSTask). Represents the percent completion of the participant for this task. The property value MUST be a positive integer between 0 and 100. 4.5. Alerts Properties 4.5.1. useDefaultAlerts Type: "Boolean" (optional, default: false). If true, use the user's default alerts and ignore the value of the "alerts" property. Fetching user defaults is dependent on the API from which this JSCalendar object is being fetched, and is not defined in this specification. If an implementation cannot determine the user's default alerts, or none are set, it MUST process the alerts property as if "useDefaultAlerts" is set to false. 4.5.2. alerts Type: "Id[Alert]" (optional). A map of alert ids to Alert objects, representing alerts/reminders to display or send to the user for this calendar object. An Alert Object has the following properties: o @type: "String" (mandatory) Specifies the type of this object. This MUST be "Alert". Jenkins & Stepanek Expires April 19, 2021 [Page 41] Internet-Draft JSCalendar October 2020 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" (mandatory) Defines when to trigger the alert. New types may be defined in future documents. An "OffsetTrigger" object has the following properties: * @type: "String" (mandatory) Specifies the type of this object. This MUST be "OffsetTrigger". * offset: "SignedDuration" (mandatory). Defines the offset at which to trigger the alert relative to the time property defined in the "relativeTo" property of the alert. Negative durations signify alerts before the time property, positive durations signify alerts after. * relativeTo: "String" (optional, default: "start") Specifies the time property that the alert offset is relative to. The value MUST be one of: + "start": triggers the alert relative to the start of the calendar object + "end": triggers the alert relative to the end/due time of the calendar object An "AbsoluteTrigger" object has the following properties: * @type: "String" (mandatory) Specifies the type of this object. This MUST be "AbsoluteTrigger". * when: "UTCDateTime" (mandatory). Defines a specific UTC date-time when the alert is triggered. An "UnknownTrigger" object is an object that contains a "@type" property whose value is not recognized (i.e., not "OffsetTrigger" or "AbsoluteTrigger"), plus zero or more other properties. This is for compatibility with client extensions and future specifications. Implementations SHOULD NOT trigger for trigger types they do not understand, but MUST preserve them. Jenkins & Stepanek Expires April 19, 2021 [Page 42] Internet-Draft JSCalendar October 2020 o acknowledged: "UTCDateTime" (optional) This records when an alert was last acknowledged. This is set when the user has dismissed the alert; other clients that sync this property SHOULD automatically dismiss or suppress duplicate alerts (alerts with the same alert id that triggered on or before this date-time). For a recurring calendar object, setting the "acknowledged" property MUST NOT add a new override to the "recurrenceOverrides" property. If the alert is not already overridden, the acknowledged property MUST be set on the alert in the master event/task. Certain kinds of alert action may not provide feedback as to when the user sees them, for example email based alerts. For those kinds of alerts, this property MUST be set immediately when the alert is triggered and the action successfully carried out. o relatedTo: "String[Relation]" (optional) Relates this alert to other alerts in the same JSCalendar object. If the user wishes to snooze an alert, the application MUST create an alert to trigger after snoozing. This new snooze alert MUST set a parent relation to the identifier of the original alert. o action: "String" (optional, default: "display") Describes how to alert the user. The value MUST be at most one of the following values, a value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): * "display": The alert should be displayed as appropriate for the current device and user context. * "email": The alert should trigger an email sent out to the user, notifying about the alert. This action is typically only appropriate for server implementations. 4.6. Multilingual Properties 4.6.1. localizations Type: "String[PatchObject]" (optional). Jenkins & Stepanek Expires April 19, 2021 [Page 43] Internet-Draft JSCalendar October 2020 A map of language tags [RFC5646] to patch objects, which localize the calendar object into the locale of the respective language tag. See the description of PatchObject (Section 1.4.9) for the structure of the PatchObject. The patches are applied to the top-level calendar object. In addition, the "locale" property of the patched object is set to the language tag. All pointers for patches MUST end with one of the following suffixes; any patch that does not follow this MUST be ignored unless otherwise specified in a future RFC: o title o description o name A patch MUST NOT have the prefix "recurrenceOverrides"; any localization of the override MUST be a patch to the localizations property inside the override instead. For example, a patch to "locations/abcd1234/title" is permissible, but a patch to "uid" or "recurrenceOverrides/2020-01-05T14:00:00/title" is not. Note that this specification does not define how to maintain validity of localized content. For example, a client application changing a JSCalendar object's title property might also need to update any localizations of this property. Client implementations SHOULD provide the means to manage localizations, but how to achieve this is specific to the application's workflow and requirements. 4.7. Time Zone Properties 4.7.1. timeZone Type: "TimeZoneId|null" (optional, default: null). Identifies the time zone the object is scheduled in, or null for floating time. This is either a name from the IANA Time Zone Database [TZDB] or the TimeZoneId of a custom time zone from the "timeZones" property (Section 4.7.2). If omitted, this MUST be presumed to be null (i.e., floating time). 4.7.2. timeZones Type: "TimeZoneId[TimeZone]" (optional). Maps identifiers of custom time zones to their time zone definitions. The following restrictions apply for each key in the map: Jenkins & Stepanek Expires April 19, 2021 [Page 44] Internet-Draft JSCalendar October 2020 o To avoid conflict with names in the IANA Time Zone Database [TZDB], it MUST start with the "/" character. o It MUST be a valid "paramtext" value as specified in Section 3.1. of [RFC5545]. o At least one other property in the same JSCalendar object MUST reference a time zone using this identifier (i.e., orphaned time zones are not allowed). An identifier need only be unique to this JSCalendar object. A JSCalendar object may be part in a hierarchy of other JSCalendar objects (say, a JSEvent is an entry in a JSGroup). In this case, the set of time zones is the sum of the time zone definitions of this object and its parent objects. If multiple time zones with the same identifier exist, then the definition closest to the calendar object in relation to its parents MUST be used. (In context of JSEvent, a time zone definition in its timeZones property has precedence over a definition of the same id in the JSGroup). Time zone definitions in any children of the calendar object MUST be ignored. A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545] and the semantics are as defined there. A valid time zone MUST define at least one transition rule in the "standard" or "daylight" property. Its properties are: o @type: "String" (mandatory) Specifies the type of this object. This MUST be "TimeZone". o tzId: "String" (mandatory). The TZID property from iCalendar. o updated: "UTCDateTime" (optional) The LAST-MODIFIED property from iCalendar. o url: "String" (optional) The TZURL property from iCalendar. o validUntil: "UTCDateTime" (optional) The TZUNTIL property from iCalendar specified in [RFC7808]. o aliases: "String[Boolean]" (optional) Jenkins & Stepanek Expires April 19, 2021 [Page 45] Internet-Draft JSCalendar October 2020 Maps the TZID-ALIAS-OF properties from iCalendar specified in [RFC7808] to a JSON set of aliases. The set is represented as an object, with the keys being the aliases. The value for each key in the map MUST be true. o standard: "TimeZoneRule[]" (optional) The STANDARD sub-components from iCalendar. The order MUST be preserved during conversion. o daylight: "TimeZoneRule[]" (optional). The DAYLIGHT sub-components from iCalendar. The order MUST be preserved during conversion. A TimeZoneRule object maps a STANDARD or DAYLIGHT sub-component from iCalendar, with the restriction that at most one recurrence rule is allowed per rule. It has the following properties: o @type: "String" (mandatory) Specifies the type of this object. This MUST be "TimeZoneRule". o start: "LocalDateTime" (mandatory) The DTSTART property from iCalendar. o offsetFrom: "String" (mandatory) The TZOFFSETFROM property from iCalendar. o offsetTo: "String" (mandatory) The TZOFFSETTO property from iCalendar. o recurrenceRules: "RecurrenceRule[]" (optional) The RRULE property mapped as specified in Section 4.3.2. During recurrence rule evaluation, the "until" property value MUST be interpreted as a local time in the UTC time zone. o recurrenceOverrides: "LocalDateTime[PatchObject]" (optional) Maps the RDATE properties from iCalendar. The set is represented as an object, with the keys being the recurrence dates. The patch object MUST be the empty JSON object ({}). o names: "String[Boolean]" (optional) Jenkins & Stepanek Expires April 19, 2021 [Page 46] Internet-Draft JSCalendar October 2020 Maps the TZNAME properties from iCalendar to a JSON set. The set is represented as an object, with the keys being the names, excluding any "tznparam" component from iCalendar. The value for each key in the map MUST be true. o comments: "String[]" (optional). Maps the COMMENT properties from iCalendar. The order MUST be preserved during conversion. 5. Type-specific JSCalendar Properties 5.1. JSEvent Properties In addition to the common JSCalendar object properties (Section 4) a JSEvent has the following properties: 5.1.1. start Type: "LocalDateTime" (mandatory). The date/time the event starts in the event's time zone (as specified in the "timeZone" property, see Section 4.7.1). 5.1.2. duration Type: "Duration" (optional, default: "PT0S"). The zero or positive duration of the event in the event's start time zone. The end time of an event can be found by adding the duration to the event's start time. A JSEvent MAY involve start and end locations that are in different time zones (e.g., a trans-continental flight). This can be expressed using the "relativeTo" and "timeZone" properties of the JSEvent's Location objects (see Section 4.2.5). 5.1.3. status Type: "String" (optional, default: "confirmed"). The scheduling status (Section 4.4) of a JSEvent. If set, it MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor-specific value (see Section 3.3): o "confirmed": Indicates the event is definitely happening. o "cancelled": Indicates the event has been cancelled. Jenkins & Stepanek Expires April 19, 2021 [Page 47] Internet-Draft JSCalendar October 2020 o "tentative": Indicates the event may happen. 5.2. JSTask Properties In addition to the common JSCalendar object properties (Section 4) a JSTask has the following properties: 5.2.1. due Type: "LocalDateTime" (optional). The date/time the task is due in the task's time zone. 5.2.2. start Type: "LocalDateTime" (optional). The date/time the task should start in the task's time zone. 5.2.3. estimatedDuration Type: "Duration" (optional). Specifies the estimated positive duration of time the task takes to complete. 5.2.4. percentComplete Type: "UnsignedInt" (optional). Represents the percent completion of the task overall. The property value MUST be a positive integer between 0 and 100. 5.2.5. progress Type: "String" (optional). Defines the progress of this task. If omitted, the default progress (Section 4.4) of a JSTask is defined as follows (in order of evaluation): o "completed": if the "progress" property value of all participants is "completed". o "failed": if at least one "progress" property value of a participant is "failed". Jenkins & Stepanek Expires April 19, 2021 [Page 48] Internet-Draft JSCalendar October 2020 o "in-process": if at least one "progress" property value of a participant is "in-process". o "needs-action": If none of the other criteria match. If set, it MUST be one of the following values, another value registered in the IANA JSCalendar Enum Values registry, or a vendor- specific value (see Section 3.3): o "needs-action": Indicates the task needs action. o "in-process": Indicates the task is in process. o "completed": Indicates the task is completed. o "failed": Indicates the task failed. o "cancelled": Indicates the task was cancelled. 5.2.6. progressUpdated Type: "UTCDateTime" (optional). Specifies the date/time the "progress" property of either the task overall (Section 5.2.5) or a specific participant (Section 4.4.5) was last updated. If the task is recurring and has future instances, a client may want to keep track of the last progress update timestamp of a specific task recurrence, but leave other instances unchanged. One way to achieve this is by overriding the progressUpdated property in the task "recurrenceOverrides" property. However, this could produce a long list of timestamps for regularly recurring tasks. An alternative approach is to split the JSTask into a current, single instance of JSTask with this instance progress update time and a future recurring instance. See also Section 4.1.3 on splitting. 5.3. JSGroup Properties JSGroup supports the following common JSCalendar properties (Section 4): o @type o uid o prodId Jenkins & Stepanek Expires April 19, 2021 [Page 49] Internet-Draft JSCalendar October 2020 o created o updated o title o description o descriptionContentType o links o locale o keywords o categories o color o timeZones In addition, the following JSGroup-specific properties are supported: 5.3.1. entries Type: "(JSTask|JSEvent)[]" (mandatory). A collection of group members. Implementations MUST ignore entries of unknown type. 5.3.2. source Type: "String" (optional). The source from which updated versions of this group may be retrieved from. The value MUST be a URI. 6. Examples The following examples illustrate several aspects of the JSCalendar data model and format. The examples may omit mandatory or additional properties, which is indicated by a placeholder property with key "...". While most of the examples use calendar event objects, they are also illustrative for tasks. Jenkins & Stepanek Expires April 19, 2021 [Page 50] Internet-Draft JSCalendar October 2020 6.1. Simple event This example illustrates a simple one-time event. It specifies a one-time event that begins on January 15, 2020 at 1pm New York local time and ends after 1 hour. { "@type": "jsevent", "uid": "a8df6573-0474-496d-8496-033ad45d7fea", "updated": "2020-01-02T18:23:04Z", "title": "Some event", "start": "2020-01-15T13:00:00", "timeZone": "America/New_York", "duration": "PT1H" } 6.2. Simple task This example illustrates a simple task for a plain to-do item. { "@type": "jstask", "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", "updated": "2020-01-09T14:32:01Z", "title": "Do something" } 6.3. Simple group This example illustrates a simple calendar object group that contains an event and a task. Jenkins & Stepanek Expires April 19, 2021 [Page 51] Internet-Draft JSCalendar October 2020 { "@type": "jsgroup", "uid": "bf0ac22b-4989-4caf-9ebd-54301b4ee51a", "updated": "2020-01-15T18:00:00Z", "name": "A simple group", "entries": [{ "@type": "jsevent", "uid": "a8df6573-0474-496d-8496-033ad45d7fea", "updated": "2020-01-02T18:23:04Z", "title": "Some event", "start": "2020-01-15T13:00:00", "timeZone": "America/New_York", "duration": "PT1H" }, { "@type": "jstask", "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", "updated": "2020-01-09T14:32:01Z", "title": "Do something" }] } 6.4. All-day event This example illustrates an event for an international holiday. It specifies an all-day event on April 1 that occurs every year since the year 1900. { "...": "", "title": "April Fool's Day", "showWithoutTime": true, "start": "1900-04-01T00:00:00", "duration": "P1D", "recurrenceRules": [{ "@type": "RecurrenceRule", "frequency": "yearly" }] } 6.5. Task with a due date This example illustrates a task with a due date. It is a reminder to buy groceries before 6pm Vienna local time on January 19, 2020. The calendar user expects to need 1 hour for shopping. Jenkins & Stepanek Expires April 19, 2021 [Page 52] Internet-Draft JSCalendar October 2020 { "...": "", "title": "Buy groceries", "due": "2020-01-19T18:00:00", "timeZone": "Europe/Vienna", "estimatedDuration": "PT1H" } 6.6. Event with end time zone This example illustrates the use of end time zones by use of an international flight. The flight starts on April 1, 2020 at 9am in Berlin local time. The duration of the flight is scheduled at 10 hours 30 minutes. The time at the flight's destination is in the same time zone as Tokyo. Calendar clients could use the end time zone to display the arrival time in Tokyo local time and highlight the time zone difference of the flight. The location names can serve as input for navigation systems. { "...": "", "title": "Flight XY51 to Tokyo", "start": "2020-04-01T09:00:00", "timeZone": "Europe/Berlin", "duration": "PT10H30M", "locations": { "418d0b9b-b656-4b3c-909f-5b149ca779c9": { "@type": "Location", "rel": "start", "name": "Frankfurt Airport (FRA)" }, "c2c7ac67-dc13-411e-a7d4-0780fb61fb08": { "@type": "Location", "rel": "end", "name": "Narita International Airport (NRT)", "timeZone": "Asia/Tokyo" } } } 6.7. Floating-time event (with recurrence) This example illustrates the use of floating time. Since January 1, 2020, a calendar user blocks 30 minutes every day to practice Yoga at 7am local time, in whatever time zone the user is located on that date. Jenkins & Stepanek Expires April 19, 2021 [Page 53] Internet-Draft JSCalendar October 2020 { "...": "", "title": "Yoga", "start": "2020-01-01T07:00:00", "duration": "PT30M", "recurrenceRules": [{ "@type": "RecurrenceRule", "frequency": "daily" }] } 6.8. Event with multiple locations and localization This example illustrates an event that happens at both a physical and a virtual location. Fans can see a live concert on premises or online. The event title and descriptions are localized. { "...": "", "title": "Live from Music Bowl: The Band", "description": "Go see the biggest music event ever!", "locale": "en", "start": "2020-07-04T17:00:00", "timeZone": "America/New_York", "duration": "PT3H", "locations": { "c0503d30-8c50-4372-87b5-7657e8e0fedd": { "@type": "Location", "name": "The Music Bowl", "description": "Music Bowl, Central Park, New York", "coordinates": "geo:40.7829,-73.9654" } }, "virtualLocations": { "1": { "@type": "VirtualLocation", "name": "Free live Stream from Music Bowl", "uri": "https://stream.example.com/the_band_2020" } }, "localizations": { "de": { "title": "Live von der Music Bowl: The Band!", "description": "Schau dir das groesste Musikereignis an!", "virtualLocations/1/name": "Gratis Live-Stream aus der Music Bowl" } } } Jenkins & Stepanek Expires April 19, 2021 [Page 54] Internet-Draft JSCalendar October 2020 6.9. Recurring event with overrides This example illustrates the use of recurrence overrides. A math course at a University is held for the first time on January 8, 2020 at 9am London time and occurs every week until June 24, 2020. Each lecture lasts for one hour and 30 minutes and is located at the Mathematics department. This event has exceptional occurrences: at the last occurrence of the course is an exam, which lasts for 2 hours and starts at 10am. Also, the location of the exam differs from the usual location. On April 1 no course is held. On January 7 at 2pm is an optional introduction course, that occurs before the first regular lecture. Jenkins & Stepanek Expires April 19, 2021 [Page 55] Internet-Draft JSCalendar October 2020 { "...": "", "title": "Calculus I", "start": "2020-01-08T09:00:00", "timeZone": "Europe/London", "duration": "PT1H30M", "locations": { "0dfb8ace-aad1-4734-b3b4-a2fe3d6ae1c5": { "@type": "Location", "title": "Math lab room 1", "description": "Math Lab I, Department of Mathematics" } }, "recurrenceRules": [{ "@type": "RecurrenceRule", "frequency": "weekly", "until": "2020-06-24T09:00:00" }], "recurrenceOverrides": { "2020-01-07T14:00:00": { "title": "Introduction to Calculus I (optional)" }, "2020-04-01T09:00:00": { "excluded": true }, "2020-06-25T09:00:00": { "title": "Calculus I Exam", "start": "2020-06-25T10:00:00", "duration": "PT2H", "locations": { "84d639ca-37ac-4a86-81e5-9bbba8eb4053": { "@type": "Location", "title": "Big Auditorium", "description": "Big Auditorium, Other Road" } } } } } 6.10. Recurring event with participants This example illustrates scheduled events. A team meeting occurs every week since January 8, 2020 at 9am Johannesburg time. The event owner also chairs the event. Participants meet in a virtual meeting room. An attendee has accepted the invitation, but on March 4, 2020 he is unavailable and declined participation for this occurrence. Jenkins & Stepanek Expires April 19, 2021 [Page 56] Internet-Draft JSCalendar October 2020 { "...": "", "title": "FooBar team meeting", "start": "2020-01-08T09:00:00", "timeZone": "Africa/Johannesburg", "duration": "PT1H", "virtualLocations": { "3f41b47b-a5eb-494f-90eb-19d279486d84": { "@type": "VirtualLocation", "name": "ChatMe meeting room", "uri": "https://chatme.example.com?id=1234567&pw=a8a24627b63d396e" } }, "recurrenceRules": [{ "@type": "RecurrenceRule", "frequency": "weekly" }], "replyTo": { "imip": "mailto:f245f875-7f63-4a5e-a2c8@schedule.example.com" }, "participants": { "dG9tQGZvb2Jhci5xlLmNvbQ": { "@type": "Participant", "name": "Tom Tool", "email": "tom@foobar.example.com", "sendTo": { "imip": "mailto:tom@calendar.example.com" }, "participationStatus": "accepted", "roles": { "attendee": true } }, "em9lQGZvb2GFtcGxlLmNvbQ": { "@type": "Participant", "name": "Zoe Zelda", "email": "zoe@foobar.example.com", "sendTo": { "imip": "mailto:zoe@foobar.example.com" }, "participationStatus": "accepted", "roles": { "owner": true, "attendee": true, "chair": true } } }, Jenkins & Stepanek Expires April 19, 2021 [Page 57] Internet-Draft JSCalendar October 2020 "recurrenceOverrides": { "2020-03-04T09:00:00": { "participants/dG9tQGZvb2Jhci5xlLmNvbQ/participationStatus": "declined" } } } 7. Security Considerations Calendaring and scheduling information is very privacy-sensitive. It can reveal the social network of a user; location information of this user and those in their social network; identity and credentials information; and the patterns of behavior of the user in both the physical and cyber realm. Additionally, calendar events and tasks can could influence the physical location of a user or their cyber behavior within a known time window. Its transmission and storage must be done carefully to protect it from possible threats, such as eavesdropping, replay, message insertion, deletion, modification, and on-path attacks. The data being stored and transmitted may be used in systems with real world consequences. For example, a home automation system may turn an alarm on and off. Or a coworking space may charge money to the organiser of an event that books one of their meeting rooms. Such systems must be careful to authenticate all data they receive to prevent them from being subverted, and ensure the change comes from an authorized entity. This document just defines the data format; such considerations are primarily the concern of the API or method of storage and transmission of such files. 7.1. Expanding Recurrences A recurrence rule may produce infinite occurrences of an event. Implementations MUST handle expansions carefully to prevent accidental or deliberate resource exhaustion. Conversely, a recurrence rule may be specified that does not expand to anything. It is not always possible to tell this through static analysis of the rule, so implementations MUST be careful to avoid getting stuck in infinite loops, or otherwise exhausting resources while searching for the next occurrence. Events recur in the event's time zone. If the user is in a different time zone, daylight saving transitions may cause an event that normally occurs at, for example, 9am to suddenly shift an hour Jenkins & Stepanek Expires April 19, 2021 [Page 58] Internet-Draft JSCalendar October 2020 earlier. This may be used in an attempt to cause a participant to miss an important meeting. User agents must be careful to translate date-times correctly between time zones and may wish to call out unexpected changes in the time of a recurring event. 7.2. JSON Parsing The Security Considerations of [RFC8259] apply to the use of JSON as the data interchange format. As for any serialization format, parsers need to thoroughly check the syntax of the supplied data. JSON uses opening and closing tags for several types and structures, and it is possible that the end of the supplied data will be reached when scanning for a matching closing tag; this is an error condition, and implementations need to stop scanning at the end of the supplied data. JSON also uses a string encoding with some escape sequences to encode special characters within a string. Care is needed when processing these escape sequences to ensure that they are fully formed before the special processing is triggered, with special care taken when the escape sequences appear adjacent to other (non-escaped) special characters or adjacent to the end of data (as in the previous paragraph). If parsing JSON into a non-textual structured data format, implementations may need to allocate storage to hold JSON string elements. Since JSON does not use explicit string lengths, the risk of denial of service due to resource exhaustion is small, but implementations may still wish to place limits on the size of allocations they are willing to make in any given context, to avoid untrusted data causing excessive memory allocation. 7.3. URI Values Several JSCalendar properties contain URIs as values, and processing these properties requires extra care. Section 7 of [RFC3986] discusses security risks related to URIs. Fetching remote resources carries inherent risks. Connections must only be allowed on well known ports, using allowed protocols (generally just HTTP/HTTPS on their default ports). The URL must be resolved externally and not allowed to access internal resources. Connecting to an external source reveals IP (and therefore generally location) information. A maliciously constructed JSCalendar object may contain a very large number of URIs. In the case of published calendars with a large Jenkins & Stepanek Expires April 19, 2021 [Page 59] Internet-Draft JSCalendar October 2020 number of subscribers, such objects could be widely distributed. Implementations should be careful to limit the automatic fetching of linked resources to reduce the risk of this being an amplification vector for a denial-of-service attack. 7.4. Spam Calendar systems may receive JSCalendar files from untrusted sources, in particular as attachments to emails. This can be a vector for an attacker to inject spam into a user's calendar. This may confuse, annoy, and mislead users, or overwhelm their calendar with bogus events, preventing them from seeing legitimate ones. Heuristic, statistical or machine-learning-based filters can be effective in filtering out spam. Authentication mechanisms such as DKIM [RFC6376] can help establish the source of messages and associate the data with existing relationships (such as an address book contact). Misclassifications are always possible, however, and providing a mechanism for users to quickly correct this is advised. Confusable unicode characters may be used to trick a user into trusting a JSCalendar file that appears to come from a known contact but is actually from a similar-looking source controlled by an attacker. 7.5. Duplication It is important for calendar systems to maintain the UID of an event when updating it to avoid unexpected duplication of events. Consumers of the data may not remove the previous version of the event if it has a different UID. This can lead to a confusing situation for the user, with many variations of the event and no indication of which one is correct. Care must be taken by consumers of the data to remove old events where possible to avoid an accidental denial-of-service attack due to the volume of data. 7.6. Time Zones Events recur in a particular time zone. When this differs from the user's current time zone, it may unexpectedly cause an occurrence to shift in time for that user due to a daylight savings change in the event's time zone. A maliciously crafted event could attempt to confuse users with such an event to ensure a meeting is missed. Jenkins & Stepanek Expires April 19, 2021 [Page 60] Internet-Draft JSCalendar October 2020 8. IANA Considerations 8.1. Media Type Registration This document defines a media type for use with JSCalendar data formatted in JSON. Type name: application Subtype name: jscalendar+json Required parameters: type The "type" parameter conveys the type of the JSCalendar data in the body part, with the value being one of "jsevent", "jstask", or "jsgroup". The parameter MUST NOT occur more than once. It MUST match the value of the "@type" property of the JSON-formatted JSCalendar object in the body. Optional parameters: none Encoding considerations: Same as encoding considerations of application/json as specified in RFC8529, Section 11 [RFC8259]. Security considerations: See Section 7 of this document. Interoperability considerations: While JSCalendar is designed to avoid ambiguities as much as possible, when converting objects from other calendar formats to/from JSCalendar it is possible that differing representations for the same logical data might arise, or ambiguities in interpretation. The semantic equivalence of two JSCalendar objects may be determined differently by different applications, for example where URL values differ in case between the two objects. Published specification: This specification. Applications that use this media type: Applications that currently make use of the text/calendar and application/calendar+json media types can use this as an alternative. Similarly, applications that use the application/json media type to transfer calendaring data can use this to further specify the content. Fragment identifier considerations: A JSON Pointer fragment identifier may be used, as defined in [RFC6901], Section 6. Additional information: Jenkins & Stepanek Expires April 19, 2021 [Page 61] Internet-Draft JSCalendar October 2020 Magic number(s): N/A File extensions(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: calsify@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: See the "Author's Address" section of this document. Change controller: IETF 8.2. Creation of "JSCalendar Properties" Registry The IANA will create the "JSCalendar Properties" registry to allow interoperability of extensions to JSCalendar objects. This registry follows the Expert Review process ([RFC8126], Section 4.5). If the "intended use" field is "common", sufficient documentation is required to enable interoperability. Preliminary community review for this registry is optional but strongly encouraged. A registration can have an intended use of "common", "reserved", or "obsolete". The IANA will list common-use registrations prominently and separately from those with other intended use values. A "reserved" registration reserves a property name without assigning semantics to avoid name collisions with future extensions or protocol use. An "obsolete" registration denotes a property that is no longer expected to be added by up-to-date systems. A new property has probably been defined covering the obsolete property's semantics. The JSCalendar property registration procedure is not a formal standards process but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. It is designed to encourage vendors to document and register new properties they add for use cases not covered by the original specification, leading to increased interoperability. Jenkins & Stepanek Expires April 19, 2021 [Page 62] Internet-Draft JSCalendar October 2020 8.2.1. Preliminary Community Review Notice of a potential new registration SHOULD be sent to the Calext mailing list for review. This mailing list is appropriate to solicit community feedback on a proposed new property. Properties registrations must be marked with their intended use: "common", "reserved" or "obsolete". The intent of the public posting to this list is to solicit comments and feedback on the choice of the property name, the unambiguity of the specification document, and a review of any interoperability or security considerations. The submitter may submit a revised registration proposal or abandon the registration completely at any time. 8.2.2. Submit Request to IANA Registration requests can be sent to . 8.2.3. Designated Expert Review The primary concern of the designated expert (DE) is preventing name collisions and encouraging the submitter to document security and privacy considerations. For a common-use registration, the DE is expected to confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available to ensure interoperability. That documentation will usually be in an RFC, but simple definitions are likely to use a web/wiki page, and if a sentence or two is deemed sufficient it could be described in the registry itself. The DE should also verify that the property name does not conflict with work that is active or already published within the IETF. A published specification is not required for reserved or obsolete registrations. The DE will either approve or deny the registration request and publish a notice of the decision to the Calext WG mailing list or its successor, as well as inform IANA. A denial notice must be justified by an explanation, and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided. 8.2.4. Change Procedures Once a JSCalendar property has been published by the IANA, the change controller may request a change to its definition. The same procedure that would be appropriate for the original registration request is used to process a change request. Jenkins & Stepanek Expires April 19, 2021 [Page 63] Internet-Draft JSCalendar October 2020 JSCalendar property registrations may not be deleted; properties that are no longer believed appropriate for use can be declared obsolete by a change to their "intended use" field; such properties will be clearly marked in the lists published by the IANA. Significant changes to a JSCalendar property's definition should be requested only when there are serious omissions or errors in the published specification, as such changes may cause interoperability issues. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition. The owner of a JSCalendar property may pass responsibility to another person or agency by informing the IANA; this can be done without discussion or review. 8.2.5. JSCalendar Properties Registry Template o Property Name: The name of the property. The property name MUST NOT already be registered for any of the object types listed in the "Property Context" field of this registration. Other object types MAY already have registered a different property with the same name, however the same name SHOULD only be used when the semantics are analogous. o Property Type: The type of this property, using type signatures as specified in Section 1.3. The property type MUST be registed in the Type Registry. o Property Context: A comma-separated list of JSCalendar object types this property is allowed on. o Reference or Description: A brief description or RFC number and section reference where the property is specified (omitted for "reserved" property names). o Intended Use: Common, reserved, or obsolete. o Change Controller: Who may request a change to this entry's definition ("IETF" for IETF-stream RFCs). 8.2.6. Initial Contents for the JSCalendar Properties Registry The following table lists the initial entries of the JSCalendar Properties registry. All properties are for common-use. All RFC section references are for this document. The change controller for all these properties is "IETF". Jenkins & Stepanek Expires April 19, 2021 [Page 64] Internet-Draft JSCalendar October 2020 +---------------+----------------------------+------------+---------+ | Property Name | Property Type | Property | Referen | | | | Context | ce or D | | | | | escript | | | | | ion | +---------------+----------------------------+------------+---------+ | @type | String | JSEvent, | Section | | | | JSTask, | 4.1.1, | | | | JSGroup, A | Section | | | | bsoluteTri | 4.5.2, | | | | gger, | Section | | | | Alert, | 1.4.11 | | | | Link, | , Secti | | | | Location, | on 4.2. | | | | NDay, Offs | 5, Sect | | | | etTrigger, | ion 4.4 | | | | Participan | .5, Sec | | | | t, Recurre | tion 4. | | | | nceRule, | 3.2, Se | | | | Relation, | ction 4 | | | | TimeZone, | .1.3, S | | | | TimeZoneRu | ection | | | | le, Virtua | 4.7.2, | | | | lLocation | Section | | | | | 4.7.2, | | | | | Section | | | | | 4.2.6 | | | | | | | acknowledged | UTCDateTime | Alert | Section | | | | | 4.5.2 | | | | | | | action | String | Alert | Section | | | | | 4.5.2 | | | | | | | alerts | Id[Alert] | JSEvent, | Section | | | | JSTask | 4.5.2 | | | | | | | aliases | String[Boolean] | TimeZone | Section | | | | | 4.7.2 | | | | | | | byDay | NDay[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | byHour | UnsignedInt[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | byMinute | UnsignedInt[] | Recurrence | Section | | | | Rule | 4.3.2 | Jenkins & Stepanek Expires April 19, 2021 [Page 65] Internet-Draft JSCalendar October 2020 | | | | | | byMonth | String[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | byMonthDay | Int[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | bySecond | UnsignedInt[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | bySetPosition | Int[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | byWeekNo | Int[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | byYearDay | Int[] | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | categories | String[Boolean] | JSEvent, | Section | | | | JSTask, | 4.2.10 | | | | JSGroup | | | | | | | | cid | String | Link | Section | | | | | 1.4.11 | | | | | | | color | String | JSEvent, | Section | | | | JSTask, | 4.2.11 | | | | JSGroup | | | | | | | | comments | String[] | TimeZoneRu | Section | | | | le | 4.7.2 | | | | | | | contentType | String | Link | Section | | | | | 1.4.11 | | | | | | | coordinates | String | Location | Section | | | | | 4.2.5 | | | | | | | count | UnsignedInt | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | created | UTCDateTime | JSEvent, | Section | | | | JSTask, | 4.1.5 | | | | JSGroup | | | | | | | | day | String | NDay | Section | | | | | 4.3.2 | Jenkins & Stepanek Expires April 19, 2021 [Page 66] Internet-Draft JSCalendar October 2020 | | | | | | daylight | TimeZoneRule | TimeZone | Section | | | | | 4.7.2 | | | | | | | delegatedFrom | String[Boolean] | Participan | Section | | | | t | 4.4.5 | | | | | | | delegatedTo | String[Boolean] | Participan | Section | | | | t | 4.4.5 | | | | | | | description | String | JSEvent, | Section | | | | JSTask, | 4.2.2, | | | | Location, | Section | | | | Participan | 4.2.5, | | | | t, Virtual | Section | | | | Location | 4.4.5, | | | | | Section | | | | | 4.2.6 | | | | | | | descriptionCo | String | JSEvent, | Section | | ntentType | | JSTask | 4.2.3 | | | | | | | display | String | Link | Section | | | | | 1.4.11 | | | | | | | due | LocalDateTime | JSTask | Section | | | | | 5.2.1 | | | | | | | duration | Duration | JSEvent | Section | | | | | 5.1.2 | | | | | | | email | String | Participan | Section | | | | t | 4.4.5 | | | | | | | entries | (JSTask|JSEvent)[] | JSGroup | Section | | | | | 5.3.1 | | | | | | | estimatedDura | Duration | JSTask | Section | | tion | | | 5.2.3 | | | | | | | excluded | Boolean | JSEvent, | Section | | | | JSTask | 4.3.5 | | | | | | | excludedRecur | RecurrenceRule[] | JSEvent, | Section | | renceRules | | JSTask | 4.3.3 | | | | | | | expectReply | Boolean | Participan | Section | | | | t | 4.4.5 | Jenkins & Stepanek Expires April 19, 2021 [Page 67] Internet-Draft JSCalendar October 2020 | | | | | | firstDayOfWee | String | Recurrence | Section | | k | | Rule | 4.3.2 | | | | | | | freeBusyStatu | String | JSEvent, | Section | | s | | JSTask | 4.4.2 | | | | | | | frequency | String | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | href | String | Link | Section | | | | | 1.4.11 | | | | | | | interval | UnsignedInt | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | invitedBy | String | Participan | Section | | | | t | 4.4.5 | | | | | | | keywords | String[Boolean] | JSEvent, | Section | | | | JSTask, | 4.2.9 | | | | JSGroup | | | | | | | | kind | String | Participan | Section | | | | t | 4.4.5 | | | | | | | language | String | Participan | Section | | | | t | 4.4.5 | | | | | | | links | Id[Link] | JSGroup, | Section | | | | JSEvent, | 4.2.7, | | | | JSTask, | Section | | | | Location, | 4.2.5, | | | | Participan | Section | | | | t | 4.4.5 | | | | | | | locale | String | JSGroup, | Section | | | | JSEvent, | 4.2.8 | | | | JSTask | | | | | | | | localizations | String[PatchObject] | JSEvent, | Section | | | | JSTask | 4.6.1 | | | | | | | locationId | String | Participan | Section | | | | t | 4.4.5 | | | | | | | locations | Id[Location] | JSEvent, | Section | | | | JSTask | 4.2.5 | Jenkins & Stepanek Expires April 19, 2021 [Page 68] Internet-Draft JSCalendar October 2020 | | | | | | locationTypes | String[Boolean] | Location | Section | | | | | 4.2.5 | | | | | | | memberOf | String[Boolean] | Participan | Section | | | | t | 4.4.5 | | | | | | | method | String | JSEvent, | Section | | | | JSTask | 4.1.8 | | | | | | | name | String | Location, | Section | | | | VirtualLoc | 4.2.5, | | | | ation, Par | Section | | | | ticipant | 4.2.6, | | | | | Section | | | | | 4.4.5 | | | | | | | names | String[Boolean] | TimeZoneRu | Section | | | | le | 4.7.2 | | | | | | | nthOfPeriod | Int | NDay | Section | | | | | 4.3.2 | | | | | | | offset | SignedDuration | OffsetTrig | Section | | | | ger | 4.5.2 | | | | | | | offsetFrom | UTCDateTime | TimeZoneRu | Section | | | | le | 4.7.2 | | | | | | | offsetTo | UTCDateTime | TimeZoneRu | Section | | | | le | 4.7.2 | | | | | | | participants | Id[Participant] | JSEvent, | Section | | | | JSTask | 4.4.5 | | | | | | | participation | String | Participan | Section | | Comment | | t | 4.4.5 | | | | | | | participation | String | Participan | Section | | Status | | t | 4.4.5 | | | | | | | percentComple | UnsignedInt | JSTask, Pa | Section | | te | | rticipant | 5.2.4 | | | | | | | priority | Int | JSEvent, | Section | | | | JSTask | 4.4.1 | | | | | | | privacy | String | JSEvent, | Section | Jenkins & Stepanek Expires April 19, 2021 [Page 69] Internet-Draft JSCalendar October 2020 | | | JSTask | 4.4.3 | | | | | | | prodId | String | JSEvent, | Section | | | | JSTask, | 4.1.4 | | | | JSGroup | | | | | | | | progress | String | JSTask, Pa | Section | | | | rticipant | 5.2.5 | | | | | | | progressUpdat | UTCDateTime | JSTask, Pa | Section | | ed | | rticipant | 5.2.6 | | | | | | | recurrenceId | LocalDateTime | JSEvent, | Section | | | | JSTask | 4.3.1 | | | | | | | recurrenceOve | LocalDateTime[PatchObject] | JSEvent, | Section | | rrides | | JSTask, Ti | 4.3.4, | | | | meZoneRule | Section | | | | | 4.7.2 | | | | | | | recurrenceRul | RecurrenceRule[] | JSEvent, | Section | | es | | JSTask, Ti | 4.3.2, | | | | meZoneRule | Section | | | | | 4.7.2 | | | | | | | rel | String | Link | Section | | | | | 1.4.11 | | | | | | | relatedTo | String[Relation] | JSEvent, | Section | | | | JSTask, | 4.1.3, | | | | Alert | Section | | | | | 4.5.2 | | | | | | | relation | String[Boolean] | Relation | Section | | | | | 1.4.10 | | | | | | | relativeTo | String | OffsetTrig | Section | | | | ger, | 4.5.2, | | | | Location | Section | | | | | 4.2.5 | | | | | | | replyTo | String[String] | JSEvent, | Section | | | | JSTask | 4.4.4 | | | | | | | roles | String[Boolean] | Participan | Section | | | | t | 4.4.5 | | | | | | | rscale | String | Recurrence | Section | Jenkins & Stepanek Expires April 19, 2021 [Page 70] Internet-Draft JSCalendar October 2020 | | | Rule | 4.3.2 | | | | | | | standard | TimeZoneRule | TimeZone | Section | | | | | 4.7.2 | | | | | | | start | LocalDateTime | TimeZoneRu | Section | | | | le | 4.7.2 | | | | | | | scheduleAgent | String | Participan | Section | | | | t | 4.4.5 | | | | | | | scheduleForce | Boolean | Participan | Section | | Send | | t | 4.4.5 | | | | | | | scheduleSeque | UnsignedInt | Participan | Section | | nce | | t | 4.4.5 | | | | | | | scheduleStatu | String[] | Participan | Section | | s | | t | 4.4.5 | | | | | | | scheduleUpdat | UTCDateTime | Participan | Section | | ed | | t | 4.4.5 | | | | | | | sendTo | String[String] | Participan | Section | | | | t | 4.4.5 | | | | | | | sequence | UnsignedInt | JSEvent, | Section | | | | JSTask | 4.1.7 | | | | | | | showWithoutTi | Boolean | JSEvent, | Section | | me | | JSTask | 4.2.4 | | | | | | | size | UnsignedInt | Link | Section | | | | | 1.4.11 | | | | | | | skip | String | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | source | String | JSGroup | Section | | | | | 5.3.2 | | | | | | | start | LocalDateTime | JSEvent, | Section | | | | JSTask | 5.1.1, | | | | | Section | | | | | 5.2.2 | | | | | | | status | String | JSEvent | Section | | | | | 5.1.3 | Jenkins & Stepanek Expires April 19, 2021 [Page 71] Internet-Draft JSCalendar October 2020 | | | | | | timeZone | TimeZoneId|null | JSEvent, | Section | | | | JSTask, | 4.7.1, | | | | Location | Section | | | | | 4.2.5 | | | | | | | timeZones | TimeZoneId[TimeZone] | JSEvent, | Section | | | | JSTask | 4.7.2 | | | | | | | title | String | JSEvent, | Section | | | | JSTask, | 4.2.1 | | | | JSGroup, | | | | | Link | | | | | | | | trigger | OffsetTrigger|AbsoluteTrig | Alert | Section | | | ger|UnknownTrigger | | 4.5.2 | | | | | | | tzId | String | TimeZone | Section | | | | | 4.7.2 | | | | | | | uid | String | JSEvent, | Section | | | | JSTask, | 4.1.2 | | | | JSGroup | | | | | | | | until | LocalDateTime | Recurrence | Section | | | | Rule | 4.3.2 | | | | | | | updated | UTCDateTime | JSEvent, | Section | | | | JSTask, | 4.1.6 | | | | JSGroup | | | | | | | | uri | String | VirtualLoc | Section | | | | ation | 4.2.6 | | | | | | | url | String | TimeZone | Section | | | | | 4.7.2 | | | | | | | useDefaultAle | Boolean | JSEvent, | Section | | rts | | JSTask | 4.5.1 | | | | | | | validUntil | UTCDateTime | TimeZone | Section | | | | | 4.7.2 | | | | | | | virtualLocati | Id[VirtualLocation] | JSEvent, | Section | | ons | | JSTask | 4.2.6 | | | | | | | when | UTCDateTime | AbsoluteTr | Section | | | | igger | 4.5.2 | Jenkins & Stepanek Expires April 19, 2021 [Page 72] Internet-Draft JSCalendar October 2020 +---------------+----------------------------+------------+---------+ Table 1 8.3. Creation of "JSCalendar Types" Registry The IANA will create the "JSCalendar Types" registry to avoid name collisions and provide a complete reference for all data types used for JSCalendar property values. The registration process is the same as for the JSCalendar Properties registry, as defined in Section 8.2. 8.3.1. JSCalendar Types Registry Template o Type Name: The name of the type. o Reference or Description: A brief description or RFC number and section reference where the Type is specified (may be omitted for "reserved" type names). o Intended Use: Common, reserved, or obsolete. o Change Controller: Who may request a change to this entry's definition ("IETF" for IETF-stream RFCs). 8.3.2. Initial Contents for the JSCalendar Types Registry The following table lists the initial entries of the JSCalendar Types registry. All properties are for common-use. All RFC section references are for this document. The change controller for all these properties is "IETF". +-----------------+--------------------------+ | Type Name | Reference or Description | +-----------------+--------------------------+ | Alert | Section 4.5.2 | | | | | Boolean | Section 1.3 | | | | | Duration | Section 1.4.6 | | | | | Id | Section 1.4.1 | | | | | Int | Section 1.4.2 | | | | | LocalDateTime | Section 1.4.5 | | | | | Link | Section 1.4.11 | | | | Jenkins & Stepanek Expires April 19, 2021 [Page 73] Internet-Draft JSCalendar October 2020 | Location | Section 4.2.5 | | | | | NDay | Section 4.3.2 | | | | | Number | Section 1.3 | | | | | Participant | Section 4.4.5 | | | | | PatchObject | Section 1.4.9 | | | | | RecurrenceRule | Section 4.3.2 | | | | | Relation | Section 1.4.10 | | | | | SignedDuration | Section 1.4.7 | | | | | String | Section 1.3 | | | | | TimeZone | Section 4.7.2 | | | | | TimeZoneId | Section 1.4.8 | | | | | TimeZoneRule | Section 4.7.2 | | | | | UnsignedInt | Section 1.4.3 | | | | | UTCDateTime | Section 1.4.4 | | | | | VirtualLocation | Section 4.2.6 | +-----------------+--------------------------+ Table 2 8.4. Creation of "JSCalendar Enum Values" Registry The IANA will create the "JSCalendar Enum Values" registry to allow interoperable extension of semantics for properties with enumerable values. Each such property will have a subregistry of allowed values. The registration process for a new enum value or adding a new enumerable property is the same as for the JSCalendar Properties registry, as defined in Section 8.2. 8.4.1. JSCalendar Enum Property Template This template is for adding a subregistry for a new enumerable property to the JSCalendar Enum registry. Jenkins & Stepanek Expires April 19, 2021 [Page 74] Internet-Draft JSCalendar October 2020 o Property Name: the name(s) of the property or properties where these values may be used. This MUST be registered in the JSCalendar Properties registry. o Context: the list of allowed object types where the property or properties may appear, as registered in the JSCalendar Properties registry. This disambiguates where there may be two distinct properties with the same name in different contexts. o Change Controller: ("IETF" for properties defined in IETF-stream RFCs). o Initial Contents: The initial list of defined values for this enum, using the template defined in Section 8.4.2. A subregistry will be created with these values for this property name/context tuple. 8.4.2. JSCalendar Enum Value Template This template is for adding a new enum value to a subregistry in the JSCalendar Enum registry. o Enum Value: The verbatim value of the enum. o Reference or Description: A brief description or RFC number and section reference for the semantics of this value. 8.4.3. Initial Contents for the JSCalendar Enum Values registry For each subregistry created in this section, all RFC section references are for this document. ------------------------------------------------------------ Property Name: action Context: Alert Change Controller: IETF Initial Contents: Jenkins & Stepanek Expires April 19, 2021 [Page 75] Internet-Draft JSCalendar October 2020 +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | display | Section 4.5.2 | | | | | email | Section 4.5.2 | +------------+--------------------------+ Table 3 ------------------------------------------------------------ Property Name: display Context: Link Change Controller: IETF Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | badge | Section 1.4.11 | | | | | graphic | Section 1.4.11 | | | | | fullsize | Section 1.4.11 | | | | | thumbnail | Section 1.4.11 | +------------+--------------------------+ Table 4 ------------------------------------------------------------ Property Name: freeBusyStatus Context: JSEvent, JSTask Change Controller: IETF Initial Contents: Jenkins & Stepanek Expires April 19, 2021 [Page 76] Internet-Draft JSCalendar October 2020 +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | free | Section 4.4.2 | | | | | busy | Section 4.4.2 | +------------+--------------------------+ Table 5 ------------------------------------------------------------ Property Name: kind Context: Participant Change Controller: IETF Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | individual | Section 4.4.5 | | | | | group | Section 4.4.5 | | | | | resource | Section 4.4.5 | | | | | location | Section 4.4.5 | +------------+--------------------------+ Table 6 ------------------------------------------------------------ Property Name: participationStatus Context: Participant Change Controller: IETF Initial Contents: Jenkins & Stepanek Expires April 19, 2021 [Page 77] Internet-Draft JSCalendar October 2020 +--------------+--------------------------+ | Enum Value | Reference or Description | +--------------+--------------------------+ | needs-action | Section 4.4.5 | | | | | accepted | Section 4.4.5 | | | | | declined | Section 4.4.5 | | | | | tenative | Section 4.4.5 | | | | | delegated | Section 4.4.5 | +--------------+--------------------------+ Table 7 ------------------------------------------------------------ Property Name: privacy Context: JSEvent, JSTask Change Controller: IETF Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | public | Section 4.4.3 | | | | | private | Section 4.4.3 | | | | | secret | Section 4.4.3 | +------------+--------------------------+ Table 8 ------------------------------------------------------------ Property Name: progress Context: JSTask, Participant Change Controller: IETF Initial Contents: Jenkins & Stepanek Expires April 19, 2021 [Page 78] Internet-Draft JSCalendar October 2020 +--------------+--------------------------+ | Enum Value | Reference or Description | +--------------+--------------------------+ | needs-action | Section 5.2.5 | | | | | in-process | Section 5.2.5 | | | | | completed | Section 5.2.5 | | | | | failed | Section 5.2.5 | | | | | cancelled | Section 5.2.5 | +--------------+--------------------------+ Table 9 ------------------------------------------------------------ Property Name: relation Context: Relation Change Controller: IETF Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | first | Section 1.4.10 | | | | | next | Section 1.4.10 | | | | | child | Section 1.4.10 | | | | | parent | Section 1.4.10 | +------------+--------------------------+ Table 10 ------------------------------------------------------------ Property Name: relativeTo Context: OffsetTrigger, Location Change Controller: IETF Jenkins & Stepanek Expires April 19, 2021 [Page 79] Internet-Draft JSCalendar October 2020 Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | start | Section 4.5.2 | | | | | end | Section 4.5.2 | +------------+--------------------------+ Table 11 ------------------------------------------------------------ Property Name: roles Context: Participant Change Controller: IETF Initial Contents: +---------------+--------------------------+ | Enum Value | Reference or Description | +---------------+--------------------------+ | owner | Section 4.4.5 | | | | | attendee | Section 4.4.5 | | | | | optional | Section 4.4.5 | | | | | informational | Section 4.4.5 | | | | | chair | Section 4.4.5 | | | | | contact | Section 4.4.5 | +---------------+--------------------------+ Table 12 ------------------------------------------------------------ Property Name: scheduleAgent Context: Participant Change Controller: IETF Jenkins & Stepanek Expires April 19, 2021 [Page 80] Internet-Draft JSCalendar October 2020 Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | server | Section 4.4.5 | | | | | client | Section 4.4.5 | | | | | none | Section 4.4.5 | +------------+--------------------------+ Table 13 ------------------------------------------------------------ Property Name: status Context: JSEvent Change Controller: IETF Initial Contents: +------------+--------------------------+ | Enum Value | Reference or Description | +------------+--------------------------+ | confirmed | Section 5.1.3 | | | | | cancelled | Section 5.1.3 | | | | | tentative | Section 5.1.3 | +------------+--------------------------+ Table 14 9. Acknowledgments The authors would like to thank the members of CalConnect for their valuable contributions. This specification originated from the work of the API technical committee of CalConnect, the Calendaring and Scheduling Consortium. 10. References Jenkins & Stepanek Expires April 19, 2021 [Page 81] Internet-Draft JSCalendar October 2020 10.1. Normative References [CLDR] "Unicode Common Locale Data Repository", . [COLORS] "CSS Color Module", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, . [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Jenkins & Stepanek Expires April 19, 2021 [Page 82] Internet-Draft JSCalendar October 2020 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, . [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, DOI 10.17487/RFC5546, December 2009, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, . [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, DOI 10.17487/RFC6047, December 2010, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 7529, DOI 10.17487/RFC7529, May 2015, . [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, . Jenkins & Stepanek Expires April 19, 2021 [Page 83] Internet-Draft JSCalendar October 2020 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . [TZDB] "IANA Time Zone Database", . 10.2. Informative References [LINKRELS] "IANA Link Relation Types", . [LOCATIONTYPES] "IANA Location Types Registry", . [MEDIATYPES] "IANA Media Types", . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2014, . Jenkins & Stepanek Expires April 19, 2021 [Page 84] Internet-Draft JSCalendar October 2020 [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, DOI 10.17487/RFC7986, October 2016, . Authors' Addresses Neil Jenkins Fastmail PO Box 234 Collins St West Melbourne VIC 8007 Australia Email: neilj@fastmailteam.com URI: https://www.fastmail.com Robert Stepanek Fastmail PO Box 234 Collins St West Melbourne VIC 8007 Australia Email: rsto@fastmailteam.com URI: https://www.fastmail.com Jenkins & Stepanek Expires April 19, 2021 [Page 85] ./draft-ietf-dots-use-cases-25.txt0000644000764400076440000010222513700504022016211 0ustar iustyiusty DOTS R. Dobbins Internet-Draft Arbor Networks Intended status: Informational D. Migault Expires: January 6, 2021 Ericsson R. Moskowitz HTT Consulting N. Teague Iron Mountain Data Centers L. Xia Huawei K. Nishizuka NTT Communications July 05, 2020 Use cases for DDoS Open Threat Signaling draft-ietf-dots-use-cases-25 Abstract The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2021. Dobbins, et al. Expires January 6, 2021 [Page 1] Internet-Draft DOTS Use Cases July 2020 Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. DDoS Orchestration . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction At the time of writing, distributed denial-of-service (DDoS) attack mitigation solutions are largely based upon siloed, proprietary communications schemes with vendor lock-in as a side-effect. This can result in the configuration, provisioning, operation, and activation of these solutions being a highly manual and often time- consuming process. Additionally, coordinating multiple DDoS mitigation solutions simultaneously is fraught with both technical and process-related hurdles. This greatly increases operational complexity which, in turn, can degrade the efficacy of mitigations that are generally highly dependent on a timely reaction by the system. The DDoS Open Threat Signaling (DOTS) effort is intended to specify protocols that facilitate interoperability between diverse DDoS Dobbins, et al. Expires January 6, 2021 [Page 2] Internet-Draft DOTS Use Cases July 2020 mitigation solutions and ensure greater integration in term of attack detection, mitigation requests, and attack characterization patterns. As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differing DDoS solutions, such as detecting DDoS attacks, initiating/ terminating DDoS mitigation assistance, or requesting the status of a DDoS mitigation. This document provides sample use cases that provided input for the requirements [RFC8612] and design of the DOTS protocols [RFC8782][RFC8783]. The use cases are not exhaustive and future use cases are expected to emerge as DOTS is adopted and evolves. 2. Terminology and Acronyms This document makes use of the same terminology and definitions as [RFC8612]. In addition it uses the terms defined below: o DDoS Mitigation System (DMS): A system that performs DDoS mitigation. The DDoS Mitigation System may be composed of a cluster of hardware and/or software resources, but could also involve an orchestrator that may take decisions such as outsourcing some or all of the mitigation to another DDoS Mitigation System. o DDoS Mitigation: The action performed by the DDoS Mitigation System. o DDoS Mitigation Service: designates a service provided to a customer to mitigate DDoS attacks. Each service subscription usually involve Service Level Agreement (SLA) that has to be met. It is the responsibility of the DDoS Service provider to instantiate the DDoS Mitigation System to meet these SLAs. o DDoS Mitigation Service Provider: designates the administrative entity providing the DDoS Mitigation Service. o Internet Transit Provider (ITP): designates the entity that delivers the traffic to a customer network. It can be an Internet Service Provider (ISP), or an upstream entity delivering the traffic to the ISP. 3. Use Cases Dobbins, et al. Expires January 6, 2021 [Page 3] Internet-Draft DOTS Use Cases July 2020 3.1. Upstream DDoS Mitigation by an Upstream Internet Transit Provider This use case describes how an enterprise or a residential customer network may take advantage of a pre-existing relation with its ITP in order to mitigate a DDoS attack targeting its network. For clarity of discussion, the targeted network is indicated as an enterprise network, but the same scenario applies to any downstream network, including residential and cloud hosting networks. As the ITP provides connectivity to the enterprise network, it is already on the path of the inbound and outbound traffic of the enterprise network and well aware of the networking parameters associated to the enterprise network WAN connectivity. This eases both the configuration and the instantiation of a DDoS Mitigation Service. This section considers two kinds of DDoS Mitigation Service between an enterprise network and an ITP: o The upstream ITP may instantiate a DDoS Mitigation System (DMS) upon receiving a request from the enterprise network. This typically corresponds to the case when the enterprise network is under attack. o On the other hand, the ITP may identify an enterprise network as the source of an attack and send a mitigation request to the enterprise DMS to mitigate this at the source. The two scenarios, though different, have similar interactions between the DOTS client and server. For the sake of simplicity, only the first scenario will be detailed in this section. Nevertheless, the second scenario is also in scope for DOTS. In the first scenario, as depicted in Figure 1, an enterprise network with self-hosted Internet-facing properties such as Web servers, authoritative DNS servers, and VoIP servers has a DMS deployed to protect those servers and applications from DDoS attacks. In addition to on-premise DDoS defense capability, the enterprise has contracted with its ITP for DDoS Mitigation Services when attacks threaten to overwhelm the bandwidth of their WAN link(s). Dobbins, et al. Expires January 6, 2021 [Page 4] Internet-Draft DOTS Use Cases July 2020 +------------------+ +------------------+ | Enterprise | | Upstream | | Network | | Internet Transit | | | | Provider | | +--------+ | | DDoS Attack | | DDoS | | <================================= | | Target | | <================================= | +--------+ | | +------------+ | | | +-------->| DDoS | | | | | |S | Mitigation | | | | | | | System | | | | | | +------------+ | | | | | | | | | | | | | | | | | +------------+ | | | | | | DDoS |<---+ | | | | Mitigation |C | | | | | System | | | | | +------------+ | | | +------------------+ +------------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 1: Upstream Internet Transit Provider DDoS Mitigation The enterprise DMS is configured such that if the incoming Internet traffic volume exceeds 50% of the provisioned upstream Internet WAN link capacity, the DMS will request DDoS mitigation assistance from the upstream transit provider. More sophisticated detection means may be considered as well. The requests to trigger, manage, and finalize a DDoS Mitigation between the enterprise DMS and the ITP is performed using DOTS. The enterprise DMS implements a DOTS client while the ITP implements a DOTS server which is integrated with their DMS in this example. When the enterprise DMS locally detects an inbound DDoS attack targeting its resources (e.g., servers, hosts, or applications), it immediately begins a DDoS Mitigation. During the course of the attack, the inbound traffic volume to the enterprise network exceeds the 50% threshold and the enterprise DMS escalates the DDoS mitigation. The enterprise DMS DOTS client signals to the DOTS server on the upstream ITP to initiate DDoS Mitigation. The DOTS server replies to the DOTS client that it can Dobbins, et al. Expires January 6, 2021 [Page 5] Internet-Draft DOTS Use Cases July 2020 serve this request, and mitigation is initiated on the ITP network by the ITP DMS. Over the course of the attack, the DOTS server of the ITP periodically informs the DOTS client on the mitigation status, statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended, or decreased to a certain level that the enterprise DMS might handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided. The DOTS client on the enterprise DMS then requests the ITP to terminate the DDoS Mitigation. The DOTS server on the ITP receives this request and once the mitigation has ended, confirms the end of upstream DDoS Mitigation to the enterprise DMS DOTS client. The following is an overview of the DOTS communication model for this use-case: 1. A DDoS attack is initiated against resources of a network organization (here, the enterprise) which has deployed a DOTS- capable DMS - typically a DOTS client. 2. The enterprise DMS detects, classifies, and begins the DDoS Mitigation. 3. The enterprise DMS determines that its capacity and/or capability to mitigate the DDoS attack is insufficient, and sends via its DOTS client a DOTS DDoS Mitigation request to one or more DOTS servers residing on the upstream ITP. 4. The DOTS server which receives the DOTS Mitigation request determines that it has been configured to honor requests from the requesting DOTS client, and honors the request by orchestrating its own DMS. 5. While the DDoS Mitigation is active, the DOTS server regularly transmits DOTS DDoS Mitigation status updates to the DOTS client. 6. Informed by the DOTS server status update that the attack has ended or subsided, the DOTS client transmits a DOTS DDoS Mitigation termination request to the DOTS server. 7. The DOTS server terminates DDoS Mitigation, and sends the notification to the DOTS client. Note that communications between the enterprise DOTS client and the upstream ITP DOTS server may take place in-band within the main Dobbins, et al. Expires January 6, 2021 [Page 6] Internet-Draft DOTS Use Cases July 2020 Internet WAN link between the enterprise and the ITP; out-of-band via a separate, dedicated wireline network link utilized solely for DOTS signaling; or out-of-band via some other form of network connectivity such as a third-party wireless 4G network connectivity. Note also that a DOTS client that sends a DOTS Mitigation request may be also triggered by a network admin that manually confirms the request to the upstream ITP, in which case the request may be sent from an application such as a web browser or a dedicated mobile application. Note also that when the enterprise is multihomed and connected to multiple upstream ITPs, each ITP is only able to provide a DDoS Mitigation Service for the traffic it transits. As a result, the enterprise network may be required to coordinate the various DDoS Mitigation Services associated to each link. More multi-homing considerations are discussed in [I-D.ietf-dots-multihoming]. 3.2. DDoS Mitigation by a Third Party DDoS Mitigation Service Provider This use case differs from the previous use case described in Section 3.1 in that the DDoS Mitigation Service is not provided by an upstream ITP. In other words, as represented in Figure 2, the traffic is not forwarded through the DDoS Mitigation Service Provider by default. In order to steer the traffic to the DDoS Mitigation Service Provider, some network configuration changes are required. As such, this use case is likely to apply to large enterprises or large data centers, but as for the other use cases is not exclusively limited to them. Another typical scenario for this use case is for there to be a relationship between DDoS Mitigation Service Providers, forming an overlay of DMS. When a DDoS Mitigation Service Provider mitigating a DDoS attack reaches its resources capacity, it may chose to delegate the DDoS Mitigation to another DDoS Mitigation Service Provider. Dobbins, et al. Expires January 6, 2021 [Page 7] Internet-Draft DOTS Use Cases July 2020 +------------------+ +------------------+ | Enterprise | | Upstream | | Network | | Internet Transit | | | | Provider | | +--------+ | | DDoS Attack | | DDoS | | <================================= | | Target | | <================================= | +--------+ | | | | | | | | | +------------------+ | | | | +------------------+ | | | DDoS Mitigation | | | | Service Provider | | | | | | +------------+ | | +------------+ | | | DDoS |<------------>| DDoS | | | | Mitigation |C | | S| Mitigation | | | | System | | | | System | | | +------------+ | | +------------+ | +------------------+ +------------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 2: DDoS Mitigation between an Enterprise Network and Third Party DDoS Mitigation Service Provider In this scenario, an enterprise network has entered into a pre- arranged DDoS mitigation assistance agreement with one or more third- party DDoS Mitigation Service Providers in order to ensure that sufficient DDoS mitigation capacity and/or capabilities may be activated in the event that a given DDoS attack threatens to overwhelm the ability of the enterprise's or any other given DMS to mitigate the attack on its own. The pre-arrangement typically includes agreement on the mechanisms used to redirect the traffic to the DDoS Mitigation Service Provider, as well as the mechanism to re-inject the traffic back to the Enterprise Network. Redirection to the DDoS Mitigation Service Provider typically involves BGP prefix announcement or DNS redirection, while re-injection of the scrubbed traffic to the enterprise network may be performed via tunneling mechanisms (e.g., GRE). The exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some contexts such changes could be detected and considered as an attack. Dobbins, et al. Expires January 6, 2021 [Page 8] Internet-Draft DOTS Use Cases July 2020 In some cases the communication between the enterprise DOTS client and the DOTS server of the DDoS Mitigation Service Provider may go through the ITP carrying the DDoS attack, which would affect the communication. On the other hand, the communication between the DOTS client and DOTS server may take a path that is not undergoing a DDoS attack. +------------------+ +------------------+ | Enterprise | | Upstream | | Network | | Internet Transit | | | | Provider | | +--------+ | | DDoS Attack | | DDoS | |<----------------+ | ++==== | | Target | | Mitigated | | || ++= | +--------+ | | | | || || | | | | | || || | | +--------|---------+ || || | | | || || | | +--------|---------+ || || | | | DDoS Mitigation | || || | | | Service Provider | || || | | | | | || || | +------------+ | | +------------+ | || || | | DDoS |<------------>| DDoS | | || || | | mitigation |C | |S | mitigation |<===++ || | | system | | | | system |<======++ | +------------+ | | +------------+ | +------------------+ +------------------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 3: Redirection to a DDoS Mitigation Service Provider When the enterprise network is under attack or at least is reaching its capacity or ability to mitigate a given DDoS attack, the DOTS client sends a DOTS request to the DDoS Mitigation Service Provider to initiate network traffic diversion - as represented in Figure 3 - and DDoS mitigation activities. Ongoing attack and mitigation status messages may be passed between the enterprise network and the DDoS Mitigation Service Provider using DOTS. If the DDoS attack has stopped or the severity of the attack has subsided, the DOTS client can request the DDoS Mitigation Service Provider to terminate the DDoS Mitigation. Dobbins, et al. Expires January 6, 2021 [Page 9] Internet-Draft DOTS Use Cases July 2020 3.3. DDoS Orchestration In this use case, one or more DDoS telemetry systems or monitoring devices monitor a network - typically an ISP network, an enterprise network, or a data center. Upon detection of a DDoS attack, these DDoS telemetry systems alert an orchestrator in charge of coordinating the various DMS's within the domain. The DDoS telemetry systems may be configured to provide required information, such as a preliminary analysis of the observation, to the orchestrator. The orchestrator analyses the various sets of information it receives from DDoS telemetry systems, and initiates one or more DDoS mitigation strategies. For example, the orchestrator could select the DDoS mitigation system in the enterprise network or one provided by the ITP. DDoS Mitigation System selection and DDoS Mitigation techniques may depend on the type of the DDoS attack. In some case, a manual confirmation or selection may also be required to choose a proposed strategy to initiate a DDoS Mitigation. The DDoS Mitigation may consist of multiple steps such as configuring the network, or of updating already instantiated DDoS mitigation functions. Eventually, the coordination of the mitigation may involve external DDoS mitigation resources such as a transit provider or a Third Party DDoS Mitigation Service Provider. The communication used to trigger a DDoS Mitigation between the DDoS telemetry and monitoring systems and the orchestrator is performed using DOTS. The DDoS telemetry system implements a DOTS client while the orchestrator implements a DOTS server. The communication between a network administrator and the orchestrator is also performed using DOTS. The network administrator uses, for example, a web interface which interacts with a DOTS client, while the orchestrator implements a DOTS server. The communication between the orchestrator and the DDoS Mitigation Systems is performed using DOTS. The orchestrator implements a DOTS client while the DDoS Mitigation Systems implement a DOTS server. The configuration aspects of each DDoS Mitigation System, as well as the instantiations of DDoS mitigation functions or network configuration is not part of DOTS. Similarly, the discovery of available DDoS mitigation functions is not part of DOTS; and as such is out of scope. Dobbins, et al. Expires January 6, 2021 [Page 10] Internet-Draft DOTS Use Cases July 2020 +----------+ | network |C (Enterprise Network) | adminis |<-+ | trator | | +----------+ | | +----------+ | S+--------------+ +-----------+ |telemetry/| +->| |C S| DDoS |+ |monitoring|<--->| Orchestrator |<--->| mitigation|| |systems |C S| |<-+ | systems || +----------+ +--------------+C | +-----------+| | +----------+ -----------------------------------|----------------- | | (Internet Transit Provider) | | +-----------+ | S| DDoS |+ +->| mitigation|| | systems || +-----------+| * C is for DOTS client functionality +----------+ * S is for DOTS server functionality Figure 4: DDoS Orchestration The DDoS telemetry systems monitor various aspects of the network traffic and perform some measurement tasks. These systems are configured so that when an event or some measurement indicators reach a predefined level their associated DOTS client sends a DOTS mitigation request to the orchestrator DOTS server. The DOTS mitigation request may be associated with some optional mitigation hints to let the orchestrator know what has triggered the request. In particular, it is possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator) Upon receipt of the DOTS mitigation request from the DDoS telemetry system, the orchestrator DOTS server responds with an acknowledgment, to avoid retransmission of the request for mitigation. The orchestrator may begin collecting additional fine-grained and specific information from various DDoS telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the orchestrator may ask for additional information from the DDoS telemetry system; however, the collection of this information is out of scope of DOTS. Dobbins, et al. Expires January 6, 2021 [Page 11] Internet-Draft DOTS Use Cases July 2020 The orchestrator may be configured to start a DDoS Mitigation upon approval from a network administrator. The analysis from the orchestrator is reported to the network administrator via, for example, a web interface. If the network administrator decides to start the mitigation, the network administrator triggers the DDoS mitigation request using, for example, a web interface of a DOTS client communicating to the orchestrator DOTS server. This request is expected to be associated with a context that provides sufficient information to the orchestrator DOTS server to infer, elaborate and coordinate the appropriate DDoS Mitigation. Upon receiving a request to mitigate a DDoS attack aimed at a target, the orchestrator may evaluate the volume of the attack as well as the value that the target represents. The orchestrator may select the DDoS Mitigation Service Provider based on the attack severity. It may also coordinate the DDoS Mitigation performed by the DDoS Mitigation Service Provider with some other tasks such as, for example, moving the target to another network so new sessions will not be impacted. The orchestrator requests a DDoS Mitigation by the selected DDoS mitigation systems via its DOTS client, as described in Section 3.1. The orchestrator DOTS client is notified that the DDoS Mitigation is effective by the selected DDoS mitigation systems. The orchestrator DOTS server returns this information back to the network administrator. Similarly, when the DDoS attack has stopped, the orchestrator DOTS client is notified and the orchestrator's DOTS server indicates to the DDoS telemetry systems as well as to the network administrator the end of the DDoS Mitigation. In addition to the above DDoS Orchestration, the selected DDoS mitigation system can return back a mitigation request to the orchestrator as an offloading. For example, when the DDoS attack becomes severe and the DDoS mitigation system's utilization rate reaches its maximum capacity, the DDoS mitigation system can send mitigation requests with additional hints such as its blocked traffic information to the orchestrator. Then the orchestrator can take further actions such as requesting forwarding nodes such as routers to filter the traffic. In this case, the DDoS mitigation system implements a DOTS client while the orchestrator implements a DOTS server. Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services). These validation checks are part of the mitigation, and are therefore out of the scope of the document. Dobbins, et al. Expires January 6, 2021 [Page 12] Internet-Draft DOTS Use Cases July 2020 4. Security Considerations The document does not describe any protocol, though there are still a few high-level security considerations to discuss. DOTS is at risk from three primary attacks: DOTS agent impersonation, traffic injection, and signaling blocking. Impersonation and traffic injection mitigation can be mitigated through current secure communications best practices including mutual authentication. Preconfigured mitigation steps to take on the loss of keepalive traffic can partially mitigate signal blocking, but in general it is impossible to comprehensively defend against an attacker that can selectively block any or all traffic. Alternate communication paths that are (hopefully) not subject to blocking by the attacker in question is another potential mitigation. Additional details of DOTS security requirements can be found in [RFC8612]. Service disruption may be experienced if inadequate mitigation actions are applied. These considerations are out of the scope of DOTS. 5. IANA Considerations No IANA considerations exist for this document. 6. Acknowledgments The authors would like to thank among others Tirumaleswar Reddy; Andrew Mortensen; Mohamed Boucadair; Artyom Gavrichenkov; Jon Shallow, Yuuhei Hayashi, Elwyn Davies, the DOTS WG chairs, Roman Danyliw and Tobias Gondrom as well as the Security AD Benjamin Kaduk for their valuable feedback. We also would like to thank Stephan Fouant that was part of the initial co-authors of the documents. 7. Informative References [I-D.ietf-dots-multihoming] Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of- Service Open Threat Signaling (DOTS)", draft-ietf-dots- multihoming-04 (work in progress), May 2020. Dobbins, et al. Expires January 6, 2021 [Page 13] Internet-Draft DOTS Use Cases July 2020 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open Threat Signaling (DOTS) Requirements", RFC 8612, DOI 10.17487/RFC8612, May 2019, . [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of- Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, . [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, . Authors' Addresses Roland Dobbins Arbor Networks Singapore EMail: rdobbins@arbor.net Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC 4S 0B6 Canada EMail: daniel.migault@ericsson.com Robert Moskowitz HTT Consulting Oak Park, MI 48237 USA EMail: rgm@labs.htt-consult.com Nik Teague Iron Mountain Data Centers UK EMail: nteague@ironmountain.co.uk Dobbins, et al. Expires January 6, 2021 [Page 14] Internet-Draft DOTS Use Cases July 2020 Liang Xia Huawei No. 101, Software Avenue, Yuhuatai District Nanjing China EMail: Frank.xialiang@huawei.com Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: kaname@nttv6.jp Dobbins, et al. Expires January 6, 2021 [Page 15] ./draft-ietf-capport-architecture-10.txt0000644000764400076440000014736713732737627017544 0ustar iustyiusty Internet Engineering Task Force K. Larose Internet-Draft Agilicus Intended status: Informational D. Dolson Expires: 27 March 2021 H. Liu Google 23 September 2020 Captive Portal Architecture draft-ietf-capport-architecture-10 Abstract This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 March 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Larose, et al. Expires 27 March 2021 [Page 1] Internet-Draft Captive Portal Architecture September 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. User Equipment . . . . . . . . . . . . . . . . . . . . . 6 2.2. Provisioning Service . . . . . . . . . . . . . . . . . . 7 2.2.1. DHCP or Router Advertisements . . . . . . . . . . . . 8 2.2.2. Provisioning Domains . . . . . . . . . . . . . . . . 8 2.3. Captive Portal API Server . . . . . . . . . . . . . . . . 8 2.4. Captive Portal Enforcement Device . . . . . . . . . . . . 9 2.5. Captive Portal Signal . . . . . . . . . . . . . . . . . . 10 2.6. Component Diagram . . . . . . . . . . . . . . . . . . . . 10 3. User Equipment Identity . . . . . . . . . . . . . . . . . . . 12 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Recommended Properties . . . . . . . . . . . . . . . . . 12 3.2.1. Uniquely Identify User Equipment . . . . . . . . . . 13 3.2.2. Hard to Spoof . . . . . . . . . . . . . . . . . . . . 13 3.2.3. Visible to the API Server . . . . . . . . . . . . . . 13 3.2.4. Visible to the Enforcement Device . . . . . . . . . . 14 3.3. Evaluating Types of Identifiers . . . . . . . . . . . . . 14 3.4. Example Identifier Types . . . . . . . . . . . . . . . . 14 3.4.1. Physical Interface . . . . . . . . . . . . . . . . . 14 3.4.2. IP Address . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Media Access Control (MAC) Address . . . . . . . . . 16 3.5. Context-free URI . . . . . . . . . . . . . . . . . . . . 16 4. Solution Workflow . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Initial Connection . . . . . . . . . . . . . . . . . . . 17 4.2. Conditions About to Expire . . . . . . . . . . . . . . . 17 4.3. Handling of Changes in Portal URI . . . . . . . . . . . . 18 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.1. Trusting the Network . . . . . . . . . . . . . . . . . . 19 7.2. Authenticated APIs . . . . . . . . . . . . . . . . . . . 19 7.3. Secure APIs . . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Risks Associated with the Signaling Protocol . . . . . . 20 7.5. User Options . . . . . . . . . . . . . . . . . . . . . . 21 Larose, et al. Expires 27 March 2021 [Page 2] Internet-Draft Captive Portal Architecture September 2020 7.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Existing Captive Portal Detection Implementations . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction In this document, "Captive Portal" is used to describe a network to which a device may be voluntarily attached, such that network access is limited until some requirements have been fulfilled. Typically a user is required to use a web browser to fulfill requirements imposed by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials. Implementations of captive portals generally require a web server, some method to allow/block traffic, and some method to alert the user. Common methods of alerting the user in implementations prior to this work involve modifying HTTP or DNS traffic. This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms. The architecture is guided by these requirements: * Current captive portal solutions typically implement some variations of forging DNS or HTTP responses. Some attempt man-in- the-middle (MITM) proxy of HTTPS in order to forge reponses. Captive Portal Solutions should not have to break any protocols or otherwise act in the manner of an attacker. Therefore, solutions MUST NOT require the forging of responses from DNS or HTTP servers, or any other protocol. * Solutions MUST permit clients to perform DNSSEC validation, which rules out solutions that forge DNS responses. Solutions SHOULD permit clients to detect and avoid TLS man-in-the-middle attacks without requiring a human to perform any kind of "exception" processing. * To maximize universality and adoption, solutions MUST operate at the layer of Internet Protocol (IP) or above, not being specific to any particular access technology such as Cable, WiFi or mobile telecom. * Solutions SHOULD allow a device to query the network to determine whether the device is captive, without the solution being coupled to forging intercepted protocols or requiring the device to make Larose, et al. Expires 27 March 2021 [Page 3] Internet-Draft Captive Portal Architecture September 2020 sacrificial queries to "canary" URIs to check for response tampering (see Appendix A). Current captive portal solutions that work by affecting DNS or HTTP generally only function as intended with browsers, breaking other applications using those protocols; applications using other protocols are not alerted that the network is a captive portal. * The state of captivity SHOULD be explicitly available to devices via a standard protocol, rather than having to infer the state indirectly. * The architecture MUST provide a path of incremental migration, acknowledging the existence of a huge variety of pre-existing portals and end-user device implementations and software versions. This requirement is not to recommend or standardize existing approaches, rather to provide device and portal implementors a path to new standard. A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of captivity. However, this document does not describe a mechanism for such devices to negotiate for unrestricted network access. A future document could provide a solution to devices without user interfaces. This document focuses on devices with user interfaces. The architecture uses the following mechanisms: * Network provisioning protocols provide end-user devices with a Uniform Resource Identifier [RFC3986] (URI) for the API that end- user devices query for information about what is required to escape captivity. DHCP, DHCPv6, and Router-Advertisement options for this purpose are available in [RFC7710bis]. Other protocols (such as RADIUS), Provisioning Domains [I-D.pfister-capport-pvd], or static configuration may also be used to convey this Captive Portal API URI. A device MAY query this API at any time to determine whether the network is holding the device in a captive state. * A Captive Portal can signal User Equipment in response to transmissions by the User Equipment. This signal works in response to any Internet protocol, and is not done by modifying protocols in-band. This signal does not carry the Captive Portal API URI; rather it provides a signal to the User Equipment that it is in a captive state. Larose, et al. Expires 27 March 2021 [Page 4] Internet-Draft Captive Portal Architecture September 2020 * Receipt of a Captive Portal Signal provides a hint that User Equipment could be captive. In response, the device MAY query the provisioned API to obtain information about the network state. The device can take immediate action to satisfy the portal (according to its configuration/policy). The architecture attempts to provide confidentiality, authentication, and safety mechanisms to the extent possible. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Captive Portal: A network which limits communication of attached devices to restricted hosts until the user has satisfied Captive Portal Conditions, after which access is permitted to a wider set of hosts (typically the Internet). Captive Portal Conditions: site-specific requirements that a user or device must satisfy in order to gain access to the wider network. Captive Portal Enforcement Device: The network equipment which enforces the traffic restriction. Also known as Enforcement Device. Captive Portal User Equipment: Also known as User Equipment. A device which has voluntarily joined a network for purposes of communicating beyond the constraints of the Captive Portal. User Portal: The web server providing a user interface for assisting the user in satisfying the conditions to escape captivity. Captive Portal API: Also known as API. An HTTP API allowing User Equipment to query information about its state of captivity within the Captive Portal. This information might include how to obtain full network access (e.g. by visting a URI). Captive Portal API Server: Also known as API Server. A server hosting the Captive Portal API. Captive Portal Signal: A notification from the network used to signal to the User Equipment that the state of its captivity could have changed. Larose, et al. Expires 27 March 2021 [Page 5] Internet-Draft Captive Portal Architecture September 2020 Captive Portal Signaling Protocol: Also known as Signaling Protocol. The protocol for communicating Captive Portal Signals. Captive Portal Session: Also referred to simply as the "session", a Captive Portal Session is the association for a particular User Equipment that starts when it interacts with the Captive Portal and gains open access to the network, and ends when the User Equipment moves back into the original captive state. The Captive Network maintains the state of each active Session, and can limit Sessions based on a length of time or a number of bytes used. The Session is associated with a particular User Equipment using the User Equipment's identifier (see Section 3). 2. Components 2.1. User Equipment The User Equipment is the device that a user desires to be attached to a network with full access to all hosts on the network (e.g., to have Internet access). The User Equipment communication is typically restricted by the Enforcement Device, described in Section 2.4, until site-specific requirements have been met. This document only considers devices with web browsers, with web applications being the means of satisfying Captive Portal Conditions. An example of such User Equipment is a smart phone. The User Equipment: * SHOULD support provisioning of the URI for the Captive Portal API (e.g., by DHCP) * SHOULD distinguish Captive Portal API access per network interface, in the manner of Provisioning Domain Architecture [RFC7556]. * SHOULD have a non-spoofable mechanism for notifying the user of the Captive Portal * SHOULD have a web browser so that the user may navigate to the User Portal. * SHOULD support updates to the Captive Portal API URI from the network provisioning service. * MAY prevent applications from using networks that do not grant full network access. E.g., a device connected to a mobile network may be connecting to a captive WiFi network; the operating system Larose, et al. Expires 27 March 2021 [Page 6] Internet-Draft Captive Portal Architecture September 2020 could avoid updating the default route to a device on captive WiFi network until network access restrictions have been lifted (excepting access to the User Portal) in the new network. This has been termed "make before break". None of the above requirements are mandatory because (a) we do not wish to say users or devices must seek full access to the Captive Portal, (b) the requirements may be fulfilled by manually visiting the captive portal web application, and (c) legacy devices must continue to be supported. If User Equipment supports the Captive Portal API, it MUST validate the API server's TLS certificate (see [RFC2818]) according to the procedures in [RFC6125]. The API server's URI is obtained via a network provisioning protocol, which will typically provide a hostname to be used in TLS server certificate validation, against a DNS-ID in the server certificate. If the API server is identified by IP address, the iPAddress subjectAltName is used to validate the server certificate. An Enforcement Device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of [I-D.ietf-capport-api] for more information. If certificate validation fails, User Equipment MUST NOT make any calls to the API server. The User Equipment can store the last response it received from the Captive Portal API as a cached view of its state within the Captive Portal. This state can be used to determine whether its Captive Portal Session is near expiry. For example, the User Equipment might compare a timestamp indicating when the session expires to the current time. Storing state in this way can reduce the need for communication with the Captive Portal API. However, it could lead to the state becoming stale if the User Equipment's view of the relevant conditions (byte quota, for example) is not consistent with the Captive Portal API's. 2.2. Provisioning Service The Provisioning Service is primarily responsible for providing a Captive Portal API URI to the User Equipment when it connects to the network, and later if the URI changes. The provisioning service could also be the same service which is responsible for provisioning the User Equipment for access to the Captive Portal (e.g., by providing it with an IP address). This section discusses two mechanisms which may be used to provide the Captive Portal API URI to the User Equipment. Larose, et al. Expires 27 March 2021 [Page 7] Internet-Draft Captive Portal Architecture September 2020 2.2.1. DHCP or Router Advertisements A standard for providing a Captive Portal API URI using DHCP or Router Advertisements is described in [RFC7710bis]. The captive portal architecture expects this URI to indicate the API described in Section 2.3. 2.2.2. Provisioning Domains Although still a work in progress, [I-D.pfister-capport-pvd] proposes a mechanism for User Equipment to be provided with PvD Bootstrap Information containing the URI for the API described in Section 2.3. 2.3. Captive Portal API Server The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user. This API thereby removes the need for User Equipment to perform clear-text "canary" (see Appendix A) queries to check for response tampering. The URI of this API will have been provisioned to the User Equipment. (Refer to Section 2.2). This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter. Therefore the API MUST support multiple repeated queries from the same User Equipment and return the state of captivity for the equipment. At minimum, the API MUST provide the state of captivity. Further the API MUST be able to provide a URI for the User Portal. The scheme for the URI MUST be https so that the User Equipment communicates with the User Portal over TLS. If the API receives a request for state that does not correspond to the requesting User Equipment, the API SHOULD deny access. Given that the API might use the User Equipment's identifier for authentication, this requirement motivates Section 3.2.2. A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. For an HTTP-based interaction, such as in [I-D.ietf-capport-api] this might be achieved by using a content type that is unique to the protocol. Larose, et al. Expires 27 March 2021 [Page 8] Internet-Draft Captive Portal Architecture September 2020 When User Equipment receives Captive Portal Signals, the User Equipment MAY query the API to check its state of captivity. The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded. (See Section 7.) The API MUST be extensible to support future use-cases by allowing extensible information elements. The API MUST use TLS to ensure server authentication. The implementation of the API MUST ensure both confidentiality and integrity of any information provided by or required by it. This document does not specify the details of the API. 2.4. Captive Portal Enforcement Device The Enforcement Device component restricts the network access of User Equipment according to site-specific policy. Typically User Equipment is permitted access to a small number of services (according to the policies of the network provider) and is denied general network access until it satisfies the Captive Portal Conditions. The Enforcement Device component: * Allows traffic to pass for User Equipment that is permitted to use the network and has satisfied the Captive Portal Conditions. * Blocks (discards) traffic according to the site-specific policy for User Equipment that has not yet satisfied the Captive Portal Conditions. * Optionally signals User Equipment using the Captive Portal Signaling protocol if certain traffic is blocked. * Permits User Equipment that has not satisfied the Captive Portal Conditions to access necessary APIs and web pages to fulfill requirements for escaping captivity. * Updates allow/block rules per User Equipment in response to operations from the User Portal. Larose, et al. Expires 27 March 2021 [Page 9] Internet-Draft Captive Portal Architecture September 2020 2.5. Captive Portal Signal When User Equipment first connects to a network, or when there are changes in status, the Enforcement Device could generate a signal toward the User Equipment. This signal indicates that the User Equipment might need to contact the API Server to receive updated information. For instance, this signal might be generated when the end of a session is imminent, or when network access was denied. For simplicity, and to reduce the attack surface, all signals SHOULD be considered equivalent by the User Equipment: as a hint to contact the API. If future solutions have multiple signal types, each type SHOULD be rate-limited independently. An Enforcement Device MUST rate-limit any signal generated in response to these conditions. See Section 7.4 for a discussion of risks related to a Captive Portal Signal. 2.6. Component Diagram The following diagram shows the communication between each component in the case where the Captive Portal has a User Portal, and the User Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server. Larose, et al. Expires 27 March 2021 [Page 10] Internet-Draft Captive Portal Architecture September 2020 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o . CAPTIVE PORTAL . . +------------+ Join Network +--------------+ . . | |+--------------------------->| Provisioning | . . | | Provision API URI | Service | . . | |<---------------------------+| | . . | User | +--------------+ . . | Equipment | Query captivity status +-------------+ . . | |+--------------------------->| API | . . | | Captivity status response | Server | . . | |<---------------------------+| | . . | | +------+------+ . . | | | Status . . | | Portal UI page requests +------+------+ . . | |+--------------------------->| | . . | | Portal UI pages | User Portal | . . | |<---------------------------+| | . . +------------+ | | . . ^ ^ | +-------------+ . . | | | Data to/from ext. network | . . | | +-----------------> +---------------+ Allow/Deny . . | +--------------------+| | Rules . . | | Enforcement | | . . | Captive Portal Signal | Device |<----+ . . +-------------------------+---------------+ . . ^ | . . | | . . Data to/from external network . . | | . o . . . . . . . . . . . . . . . . . . .| |. . . . . . . . . . . o | v EXTERNAL NETWORK Figure 1: Captive Portal Architecture Component Diagram In the diagram: * During provisioning (e.g., DHCP), and possibly later, the User Equipment acquires the Captive Portal API URI. * The User Equipment queries the API to learn of its state of captivity. If captive, the User Equipment presents the portal user interface from the User Portal to the user. * Based on user interaction, the User Portal directs the Enforcement Device to either allow or deny external network access for the User Equipment. Larose, et al. Expires 27 March 2021 [Page 11] Internet-Draft Captive Portal Architecture September 2020 * The User Equipment attempts to communicate to the external network through the Enforcement Device. * The Enforcement Device either allows the User Equipment's packets to the external network, or blocks the packets. If blocking traffic and a signal has been implemented, it may respond with a Captive Portal Signal. The Provisioning Service, API Server, and User Portal are described as discrete functions. An implementation might provide the multiple functions within a single entity. Furthermore, these functions, combined or not, as well as the Enforcement Device, could be replicated for redundancy or scale. 3. User Equipment Identity Multiple components in the architecture interact with both the User Equipment and each other. Since the User Equipment is the focus of these interactions, the components must be able to both identify the User Equipment from their interactions with it, and to agree on the identity of the User Equipment when interacting with each other. The methods by which the components interact restrict the type of information that may be used as an identifying characteristics. This section discusses the identifying characteristics. 3.1. Identifiers An Identifier is a characteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific User Equipment is interacting with them. An Identifier can be a field contained in packets sent by the User Equipment to the External Network. Or, an Identifier can be an ephemeral property not contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components. 3.2. Recommended Properties The set of possible identifiers is quite large. However, in order to be considered a good identifier, an identifier SHOULD meet the following criteria. Note that the optimal identifier will likely change depending on the position of the components in the network as well as the information available to them. An identifier SHOULD: * uniquely identify the User Equipment * be hard to spoof Larose, et al. Expires 27 March 2021 [Page 12] Internet-Draft Captive Portal Architecture September 2020 * be visible to the API Server * be visible to the Enforcement Device An identifier might only apply to the current point of network attachment. If the device moves to a different network location its identity could change. 3.2.1. Uniquely Identify User Equipment The Captive Portal MUST associate the User Equipment with an identifier that is unique among the User Equipment that are interacting with the Captive Portal at that time. Over time, the User Equipment assigned to an identifier value MAY change. Allowing the identified device to change over time ensures that the space of possible identifying values need not be overly large. Independent Captive Portals MAY use the same identifying value to identify different User Equipment. Allowing independent captive portals to reuse identifying values allows the identifier to be a property of the local network, expanding the space of possible identifiers. 3.2.2. Hard to Spoof A good identifier does not lend itself to being easily spoofed. At no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time. This property is particularly important when the User Equipment identifier is referenced externally by devices such as billing systems, or where the identity of the User Equipment could imply liability. 3.2.3. Visible to the API Server Since the API Server will need to perform operations which rely on the identity of the User Equipment, such as answering a query about whether the User Equipment is captive, the API Server needs to be able to relate a request to the User Equipment making the request. Larose, et al. Expires 27 March 2021 [Page 13] Internet-Draft Captive Portal Architecture September 2020 3.2.4. Visible to the Enforcement Device The Enforcement Device will decide on a per-packet basis whether the packet should be forwarded to the external network. Since this decision depends on which User Equipment sent the packet, the Enforcement Device requires that it be able to map the packet to its concept of the User Equipment. 3.3. Evaluating Types of Identifiers To evaluate whether a type of identifier is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture. When comparing identifier types, choose the one which best satisfies all of the recommended properties. The architecture does not provide an exact measure of how well an identifier type satisfies a given property; care should be taken in performing the evaluation. 3.4. Example Identifier Types This section provides some example identifier types, along with some evaluation of whether they are suitable types. The list of identifier types is not exhaustive. Other types may be used. An important point to note is that whether a given identifier type is suitable depends heavily on the capabilities of the components and where in the network the components exist. 3.4.1. Physical Interface The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment. This identifier type has the property of being extremely difficult to spoof: the User Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attached to a given physical interface, then the identifier will be unique. If multiple User Equipment is attached to the network on the same physical interface, then this type is not appropriate. Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and the Enforcement Device MUST invalidate their state related to the User Equipment. Larose, et al. Expires 27 March 2021 [Page 14] Internet-Draft Captive Portal Architecture September 2020 The Enforcement Device needs to be aware of the physical interface, which constrains the environment: it must either be part of the device providing physical access (e.g., implemented in firmware), or packets traversing the network must be extended to include information about the source physical interface (e.g. a tunnel). The API Server faces a similar problem, implying that it should co- exist with the Enforcement Device, or that the Enforcement Device should extend requests to it with the identifying information. 3.4.2. IP Address A natural identifier type to consider is the IP address of the User Equipment. At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness. However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor. Consequently, any solution using the IP address SHOULD proactively try to prevent spoofing of the IP address. Similarly, if the mapping of IP address to User Equipment is changed, the components of the architecture MUST remove or update their mapping to prevent spoofing. Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not be sufficient in networks that use broadcast media (such as some wireless networks). Since the IP address may traverse multiple segments of the network, more flexibility is afforded to the Enforcement Device and the API Server: they simply must exist on a segment of the network where the IP address is still unique. However, consider that a NAT may be deployed between the User Equipment and the Enforcement Device. In such cases, it is possible for the components to still uniquely identify the device if they are aware of the port mapping. Larose, et al. Expires 27 March 2021 [Page 15] Internet-Draft Captive Portal Architecture September 2020 In some situations, the User Equipment may have multiple IP addresses (either IPv4, IPv6 or a dual-stack [RFC4213] combination), while still satisfying all of the recommended properties. This raises some challenges to the components of the network. For example, if the User Equipment tries to access the network with multiple IP addresses, should the Enforcement Device and API Server treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber? An implementation MAY do either. Attention should be paid to IPv6 and the fact that it is expected for a device to have multiple IPv6 addresses on a single link. In such cases, identification could be performed by subnet, such as the /64 to which the IP belongs. 3.4.3. Media Access Control (MAC) Address The MAC address of a device is often used as an identifier in existing implementations. This document does not discuss the use of MAC addresses within a captive portal system, but they can be used as an identifier type, subject to the criteria in Section 3.2. 3.5. Context-free URI A Captive Portal API needs to present information to clients that is unique to that client. To do this, some systems use information from the context of a request, such as the source address, to identify the User Equipment. Using information from context rather than information from the URI allows the same URI to be used for different clients. However, it also means that the resource is unable to provide relevant information if the User Equipment makes a request using a different network path. This might happen when User Equipment has multiple network interfaces. It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS [RFC8499]). Accessing the API MAY depend on contextual information. However, the URIs provided in the API SHOULD be unique to the User Equipment and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests using the Captive Portal. For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. Larose, et al. Expires 27 March 2021 [Page 16] Internet-Draft Captive Portal Architecture September 2020 URIs could include some means of identifying the User Equipment in the URIs. However, including unauthenticated User Equipment identifiers in the URI may expose the service to spoofing or replay attacks. 4. Solution Workflow This section aims to improve understanding by describing a possible workflow of solutions adhering to the architecture. Note that the section is not normative: it describes only as subset of possible implementations. 4.1. Initial Connection This section describes a possible workflow when User Equipment initially joins a Captive Portal. 1. The User Equipment joins the Captive Portal by acquiring a DHCP lease, RA, or similar, acquiring provisioning information. 2. The User Equipment learns the URI for the Captive Portal API from the provisioning information (e.g., [RFC7710bis]). 3. The User Equipment accesses the Captive Portal API to receive parameters of the Captive Portal, including User Portal URI. (This step replaces the clear-text query to a canary URI.) 4. If necessary, the User navigates to the User Portal to gain access to the external network. 5. If the User interacted with the User Portal to gain access to the external network in the previous step, the User Portal indicates to the Enforcement Device that the User Equipment is allowed to access the external network. 6. The User Equipment attempts a connection outside the Captive Portal 7. If the requirements have been satisfied, the access is permitted; otherwise the "Expired" behavior occurs. 8. The User Equipment accesses the network until conditions Expire. 4.2. Conditions About to Expire This section describes a possible workflow when access is about to expire. Larose, et al. Expires 27 March 2021 [Page 17] Internet-Draft Captive Portal Architecture September 2020 1. Precondition: the API has provided the User Equipment with a duration over which its access is valid. 2. The User Equipment is communicating with the outside network. 3. The User Equipment detects that the length of time left for its access has fallen below a threshold by comparing its stored expiry time with the current time. 4. The User Equipment visits the API again to validate the expiry time. 5. If expiry is still imminent, the User Equipment prompts the user to access the User Portal URI again. 6. The User accepts the prompt displayed by the User Equipment. 7. The User extends their access through the User Portal via the User Equipment's user interface. 8. The User Equipment's access to the outside network continues uninterrupted. 4.3. Handling of Changes in Portal URI A different Captive Portal API URI could be returned in the following cases: * If DHCP is used, a lease renewal/rebind may return a different Captive Portal API URI. * If RA is used, a new Captive Portal API URI may be specified in a new RA message received by end User Equipment. When the Network Provisioning Service updates the Captive Portal API URI, the User Equipment can retrieve updated state from the URI immediately, or it can wait as it normally would until the expiry conditions it retrieved from the old URI are about to expire. 5. Acknowledgments The authors thank Lorenzo Colitti for providing the majority of the content for the Captive Portal Signal requirements. The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server. Larose, et al. Expires 27 March 2021 [Page 18] Internet-Draft Captive Portal Architecture September 2020 The authors thank Michael Richardson for providing wording requiring DNSSEC and TLS to operate without the user adding exceptions. The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van Dam. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations 7.1. Trusting the Network When joining a network, some trust is placed in the network operator. This is usually considered to be a decision by a user on the basis of the reputation of an organization. However, once a user makes such a decision, protocols can support authenticating that a network is operated by who claims to be operating it. The Provisioning Domain Architecture [RFC7556] provides some discussion on authenticating an operator. The user makes an informed choice to visit and trust the Captive Portal URI. Since the network provides Captive Portal URI to the user equipment, the network SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI. E.g., the DHCPv6 AUTH option can sign this information. If a user decides to incorrectly trust an attacking network, they might be convinced to visit an attacking web page and unwittingly provide credentials to an attacker. Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. Further, the possibility of an on-path attacker in an attacking network introduces some risks. The attacker could redirect traffic to arbitrary destinations. The attacker could analyze the user's traffic leading to loss of confidentiality. Or, the attacker could modify the traffic inline. 7.2. Authenticated APIs The solution described here requires that when the User Equipment needs to access the API server, the User Equipment authenticates the server; see Section 2.1. Larose, et al. Expires 27 March 2021 [Page 19] Internet-Draft Captive Portal Architecture September 2020 The Captive Portal API URI might change during the Captive Portal Session. The User Equipment can apply the same trust mechanisms to the new URI as it did to the URI it received initially from the network provisioning service. 7.3. Secure APIs The solution described here requires that the API be secured using TLS. This is required to allow the User Equipment and API Server to exchange secrets which can be used to validate future interactions. The API MUST ensure the integrity of this information, as well as its confidentiality. An attacker with access to this information might be able to masquerade as a specific User Equipment when interacting with the API, which could then allow them to masquerade as that User Equipment when interacting with the User Portal. This could give them the ability to determine whether the User Equipment has accessed the portal, or deny the User Equipment service by ending their session using mechanisms provided by the User Portal, or consume that User Equipment's quota. An attacker with the ability to modify the information could deny service to the User Equipment, or cause them to appear as a different User Equipment. 7.4. Risks Associated with the Signaling Protocol If a Signaling Protocol is implemented, it may be possible for any user on the Internet to send signals in attempt to cause the receiving equipment to communicate with the Captive Portal API. This has been considered, and implementations may address it in the following ways: * The signal only signals to the User Equipment to query the API. It does not carry any information which may mislead or misdirect the User Equipment. * Even when responding to the signal, the User Equipment securely authenticates with API Servers. * Accesses to the Captive Portal API are rate-limited, reducing the impact of an attack attempting to generate excessive load on either User Equipment or API. Note that because there is only one type of signal and one type of API request in response to the signal, this rate-limiting will not cause loss of signalling information. Larose, et al. Expires 27 March 2021 [Page 20] Internet-Draft Captive Portal Architecture September 2020 7.5. User Options The Captive Portal Signal could signal to the User Equipment that it is being held captive. There is no requirement that the User Equipment do something about this. Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons. However, there would be the trade-off that the user doesn't get notified when network access is restricted. Hence, end- user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. 7.6. Privacy Section 3 describes a mechanism by which all components within the Captive Portal are designed to use the same identifier to uniquely identify the User Equipment. This identifier could be abused to track the user. Implementers and designers of Captive Portals should take care to ensure that identifiers, if stored, are stored securely. Likewise, if any component communicates the identifier over the network, it should ensure the confidentiality of the identifier on the wire by using encryption such as TLS. There are benefits to choosing mutable anonymous identifiers. For example, User Equipment could cycle through multiple identifiers to help prevent long-term tracking. However, if the components of the network use an internal mapping to map the identity to a stable, long-term value in order to deal with changing identifiers, they need to treat that value as sensitive information: an attacker could use it to tie traffic back to the originating User Equipment, despite the User Equipment having changed identifiers. 8. References 8.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, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . Larose, et al. Expires 27 March 2021 [Page 21] Internet-Draft Captive Portal Architecture September 2020 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, . [RFC7710bis] Kumari, W. and E. Kline, "Captive-Portal Identification in DHCP / RA", Work in Progress, Internet-Draft, draft-ietf- capport-rfc7710bis-01, 12 January 2020, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [I-D.ietf-capport-api] Pauly, T. and D. Thakore, "Captive Portal API", Work in Progress, Internet-Draft, draft-ietf-capport-api-06, 31 March 2020, . [I-D.pfister-capport-pvd] Pfister, P. and T. Pauly, "Using Provisioning Domains for Captive Portal Discovery", Work in Progress, Internet- Draft, draft-pfister-capport-pvd-00, 30 June 2018, . [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, . [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, . Larose, et al. Expires 27 March 2021 [Page 22] Internet-Draft Captive Portal Architecture September 2020 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . Appendix A. Existing Captive Portal Detection Implementations Operating systems and user applications may perform various tests when network connectivity is established to determine if the device is attached to a network with a captive portal present. A common method is to attempt to make a HTTP request to a known, vendor-hosted endpoint with a fixed response. Any other response is interpreted as a signal that a captive portal is present. This check is typically not secured with TLS, as a network with a captive portal may intercept the connection, leading to a host name mismatch. This has been referred to as a "canary" request because, like the canary in the coal mine, it can be the first sign that something is wrong. Another test that can be performed is a DNS lookup to a known address with an expected answer. If the answer differs from the expected answer, the equipment detects that a captive portal is present. DNS queries over TCP or HTTPS are less likely to be modified than DNS queries over UDP due to the complexity of implementation. The different tests may produce different conclusions, varying by whether or not the implementation treats both TCP and UDP traffic, and by which types of DNS are intercepted. Malicious or misconfigured networks with a captive portal present may not intercept these canary requests and choose to pass them through or decide to impersonate, leading to the device having a false negative. Authors' Addresses Kyle Larose Agilicus Email: kyle@agilicus.com David Dolson Email: ddolson@acm.org Heng Liu Google Larose, et al. Expires 27 March 2021 [Page 23] Internet-Draft Captive Portal Architecture September 2020 Email: liucougar@google.com Larose, et al. Expires 27 March 2021 [Page 24] ./draft-ietf-cose-hash-algs-09.txt0000644000764400076440000006442613727715723016211 0ustar iustyiusty Network Working Group J. Schaad Internet-Draft August Cellars Intended status: Informational September 14, 2020 Expires: March 18, 2021 CBOR Object Signing and Encryption (COSE): Hash Algorithms draft-ietf-cose-hash-algs-09 Abstract The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. Contributing to this document This note is to be removed before publishing as an RFC. The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ cose-wg/X509 Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 18, 2021. Schaad Expires March 18, 2021 [Page 1] Internet-Draft COSE Hashes September 2020 Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 2. Hash Algorithm Usage . . . . . . . . . . . . . . . . . . . . 3 2.1. Example CBOR hash structure . . . . . . . . . . . . . . . 4 3. Hash Algorithm Identifiers . . . . . . . . . . . . . . . . . 5 3.1. SHA-1 Hash Algorithm . . . . . . . . . . . . . . . . . . 6 3.2. SHA-2 Hash Algorithms . . . . . . . . . . . . . . . . . . 6 3.3. SHAKE Algorithms . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4.1. COSE Algorithm Registry . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . 10 7. Informative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The CBOR Object Signing and Encryption (COSE) syntax does not define any direct methods for the use of hash algorithms. It also does not define a structure syntax that is used to encode a digested object structure along the lines of the DigestedData ASN.1 structure in [CMS]. This omission was intentional, as a structure consisting of just a digest identifier, the content, and a digest value does not, by itself, provide any strong security service. Additionally, an application is going to be better off defining this type of structure so that it can include any additional data that needs to be hashed, as well as methods of obtaining the data. While the above is true, there are some cases where having some standard hash algorithms defined for COSE with a common identifier makes a great deal of sense. Two of the cases where these are going to be used are: Schaad Expires March 18, 2021 [Page 2] Internet-Draft COSE Hashes September 2020 * Indirect signing of content, and * Object identification. Indirect signing of content is a paradigm where the content is not directly signed, but instead a hash of the content is computed and that hash value, along with an identifier for the hash algorithm, is included in the content that will be signed. Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. Rather the signature can be validated on all of the hash values and pointers to the associated contents, then those associated parts can be downloaded, the hash value of that part computed, and then compared to the hash value in the signed content. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device. An example of how this is used can be found in [I-D.ietf-suit-manifest]. The use of hashes to identify objects is something that has been very common. One of the primary things that has been identified by a hash function in a secure message is a certificate. Two examples of this can be found in [ESS] and the COSE equivalents in [I-D.ietf-cose-x509]. 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Hash Algorithm Usage As noted in the previous section, hash functions can be used for a variety of purposes. Some of these purposes require that a hash function be cryptographically strong. These include direct and indirect signatures. That is, using the hash as part of the signature or using the hash as part of the body to be signed. Other uses of hash functions may not require the same level of strength. This document contains some hash functions that are not designed to be used for cryptographic operations. An application that is using a hash function needs to carefully evaluate exactly what hash properties are needed and which hash functions are going to provide them. Applications should also make sure that the ability to change hash functions is part of the base design, as cryptographic advances are sure to reduce the strength of a hash function [BCP201]. Schaad Expires March 18, 2021 [Page 3] Internet-Draft COSE Hashes September 2020 A hash function is a map from one, normally large, bit string to a second, usually smaller, bit string. As the number of possible input values is far greater than the number of possible output values, it is inevitable that there are going to be collisions. The trick is to make sure that it is difficult to find two values that are going to map to the same output value. A "Collision Attack" is one where an attacker can find two different messages that have the same hash value. A hash function that is susceptible to practical collision attacks, SHOULD NOT be used for a cryptographic purpose. The discovery of theoretical collision attacks against a given hash function SHOULD trigger protocol maintainers and users to do a review of the continued suitability of the algorithm if alternatives are available and migration is viable. The only reason why such a hash function is used is when there is absolutely no other choice (e.g. a Hardware Security Module (HSM) that cannot be replaced), and only after looking at the possible security issues. Cryptographic purposes would include the creation of signatures or the use of hashes for indirect signatures. These functions may still be usable for non-cryptographic purposes. An example of a non-cryptographic use of a hash is for filtering from a collection of values to find a set of possible candidates; the candidates can then be checked to see if they can successfully be used. A simple example of this is the classic fingerprint of a certificate. If the fingerprint is used to verify that it is the correct certificate, then that usage is a cryptographic one and is subject to the warning above about collision attack. If, however, the fingerprint is used to sort through a collection of certificates to find those that might be used for the purpose of verifying a signature, a simple filter capability is sufficient. In this case, one still needs to confirm that the public key validates the signature (and the certificate is trusted), and all certificates that don't contain a key that validates the signature can be discarded as false positives. To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and it is not intended for applications which require a cryptographically strong algorithm. 2.1. Example CBOR hash structure [COSE] did not provide a default structure for holding a hash value not only because no separate hash algorithms were defined, but because how the structure is setup is frequently application specific. There are four fields that are often included as part of a hash structure: Schaad Expires March 18, 2021 [Page 4] Internet-Draft COSE Hashes September 2020 * The hash algorithm identifier. * The hash value. * A pointer to the value that was hashed. This could be a pointer to a file, an object that can be obtained from the network, or a pointer to someplace in the message, or something very application specific. * Additional data; this can be something as simple as a random value (i.e. salt) to make finding hash collisions slightly harder (as the payload handed to the application could have been selected to have a collision), or as complicated as a set of processing instructions that are used with the object that is pointed to. The additional data can be dealt with in a number of ways, prepending or appending to the content, but it is strongly suggested that it either be a fixed known size, or the lengths of the pieces being hashed be included. (Encoding as a CBOR array accomplishes this requirement.) An example of a structure which permits all of the above fields to exist would look like the following. COSE_Hash_V = ( 1 : int / tstr, # Algorithm identifier 2 : bstr, # Hash value ? 3 : tstr, # Location of object that was hashed ? 4 : any # object containing other details and things ) Below is an alternative structure that could be used in situations where one is searching a group of objects for a matching hash value. In this case, the location would not be needed and adding extra data to the hash would be counterproductive. This results in a structure that looks like this: COSE_Hash_Find = [ hashAlg : int / tstr, hashValue : bstr ] 3. Hash Algorithm Identifiers Schaad Expires March 18, 2021 [Page 5] Internet-Draft COSE Hashes September 2020 3.1. SHA-1 Hash Algorithm The SHA-1 hash algorithm [RFC3174] was designed by the United States National Security Agency and published in 1995. Since that time a large amount of cryptographic analysis has been applied to this algorithm and a successful collision attack has been created ([SHA-1-collision]). The IETF formally started discouraging the use of SHA-1 with the publishing of [RFC6194]. Despite the above, there are still times where SHA-1 needs to be used and therefore it makes sense to assign a codepoint for the use of this hash algorithm. Some of these situations are with historic HSMs where only SHA-1 is implemented; other situations are where the SHA-1 value is used for the purpose of filtering and thus the collision resistance property is not needed. Because of the known issues for SHA-1 and the fact that it should no longer be used, the algorithm will be registered with the recommendation of "Filter Only". This provides guidance about when the algorithm is safe for use, while discouraging usage where it is not safe. The COSE capabilities for this algorithm is an empty array. +=====+======+=============+==============+===========+=============+ |Name |Value | Description | Capabilities | Reference | Recommended | +=====+======+=============+==============+===========+=============+ |SHA-1| -14 | SHA-1 Hash | [] | [This | Filter Only | | | | | | Document] | | +-----+------+-------------+--------------+-----------+-------------+ Table 1: SHA-1 Hash Algorithm 3.2. SHA-2 Hash Algorithms The family of SHA-2 hash algorithms [FIPS-180-4] was designed by the United States National Security Agency and published in 2001. Since that time some additional algorithms have been added to the original set to deal with length extension attacks and some performance issues. While the SHA-3 hash algorithms have been published since that time, the SHA-2 algorithms are still broadly used. There are a number of different parameters for the SHA-2 hash functions. The set of hash functions which have been chosen for inclusion in this document are based on those different parameters and some of the trade-offs involved. Schaad Expires March 18, 2021 [Page 6] Internet-Draft COSE Hashes September 2020 * *SHA-256/64* provides a truncated hash. The length of the truncation is designed to allow for smaller transmission size. The trade-off is that the odds that a collision will occur increase proportionally. Use of this hash function needs analysis of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. The latter is the case for [I-D.ietf-cose-x509]. The hash value is used to select possible certificates and, if there are multiple choices remaining then, each choice can be tested by using the public key. * *SHA-256* is probably the most common hash function used currently. SHA-256 is an efficient hash algorithm for 32-bit hardware. * *SHA-384* and *SHA-512* hash functions are efficient for 64-bit hardware. * *SHA-512/256* provides a hash function that runs more efficiently on 64-bit hardware, but offers the same security levels as SHA- 256. The COSE capabilities array for these algorithms is empty. Schaad Expires March 18, 2021 [Page 7] Internet-Draft COSE Hashes September 2020 +===========+=====+===========+==============+=========+============+ | Name |Value|Description| Capabilities |Reference|Recommended | +===========+=====+===========+==============+=========+============+ |SHA-256/64 | -15 | SHA-2 | [] | [This |Filter Only | | | | 256-bit | |Document]| | | | | Hash | | | | | | | truncated | | | | | | |to 64-bits | | | | +-----------+-----+-----------+--------------+---------+------------+ | SHA-256 | -16 | SHA-2 | [] | [This | Yes | | | | 256-bit | |Document]| | | | | Hash | | | | +-----------+-----+-----------+--------------+---------+------------+ | SHA-384 | -43 | SHA-2 | [] | [This | Yes | | | | 384-bit | |Document]| | | | | Hash | | | | +-----------+-----+-----------+--------------+---------+------------+ | SHA-512 | -44 | SHA-2 | [] | [This | Yes | | | | 512-bit | |Document]| | | | | Hash | | | | +-----------+-----+-----------+--------------+---------+------------+ |SHA-512/256| -17 | SHA-2 | [] | [This | Yes | | | | 512-bit | |Document]| | | | | Hash | | | | | | | truncated | | | | | | |to 256-bits| | | | +-----------+-----+-----------+--------------+---------+------------+ Table 2: SHA-2 Hash Algorithms 3.3. SHAKE Algorithms The family of SHA-3 hash algorithms [FIPS-202] was the result of a competition run by NIST. The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF. This is the reason for including these algorithms in this document. The SHA-3 hash algorithms have a significantly different structure than the SHA-2 hash algorithms. Unlike the SHA-2 hash functions, no algorithm identifier is created for shorter lengths. The length of the hash value stored is 256-bits for SHAKE-128 and 512-bits for SHAKE-256. The COSE capabilities array for these algorithms is empty. Schaad Expires March 18, 2021 [Page 8] Internet-Draft COSE Hashes September 2020 +========+=====+=============+==============+=========+=============+ | Name |Value| Description | Capabilities |Reference| Recommended | +========+=====+=============+==============+=========+=============+ |SHAKE128| -18 | SHAKE-128 | [] | [This | Yes | | | |256-bit Hash | |Document]| | | | | Value | | | | +--------+-----+-------------+--------------+---------+-------------+ |SHAKE256| -45 | SHAKE-256 | [] | [This | Yes | | | |512-bit Hash | |Document]| | | | | Value | | | | +--------+-----+-------------+--------------+---------+-------------+ Table 3: SHAKE Hash Functions 4. IANA Considerations The IANA actions in [I-D.ietf-cose-rfc8152bis-struct] and [I-D.ietf-cose-rfc8152bis-algs] need to be executed before the actions in this document. Where early allocation of codepoints has been made, these should be preserved. 4.1. COSE Algorithm Registry IANA is requested to register the following algorithms in the "COSE Algorithms" registry. * The SHA-1 hash function found in Table 1. * The set of SHA-2 hash functions found in Table 2. * The set of SHAKE hash functions found in Table 3. Many of the hash values produced are relatively long and as such the use of a two byte algorithm identifier seems reasonable. SHA-1 is tagged as 'Filter Only' and thus a longer algorithm identifier is appropriate even though it is a shorter hash value. IANA is requested to add the value of 'Filter Only' to the set of legal values for the 'Recommended' column. This value is only to be used for hash functions and indicates that it is not to be used for purposes which require collision resistance. IANA is requested to add this document to the reference section for this table due to this addition. Schaad Expires March 18, 2021 [Page 9] Internet-Draft COSE Hashes September 2020 5. Security Considerations Protocols need to perform a careful analysis of the properties of a hash function that are needed and how they map onto the possible attacks. In particular, one needs to distinguish between those uses that need the cryptographic properties, such as collision resistance, and properties that correspond to possible object identification. The different attacks correspond to who or what is being protected: is it the originator that is the attacker or a third party? This is the difference between collision resistance and second pre-image resistance. As a general rule, longer hash values are "better" than short ones, but trade-offs of transmission size, timeliness, and security all need to be included as part of this analysis. In many cases the value being hashed is a public value and, as such, pre- image resistance is not part of this analysis. Algorithm agility needs to be considered a requirement for any use of hash functions [BCP201]. As with any cryptographic function, hash functions are under constant attack and the cryptographic strength of hash algorithms will be reduced over time. 6. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-cose-rfc8152bis-struct] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", Work in Progress, Internet-Draft, draft-ietf-cose-rfc8152bis-struct-12, August 24, 2020, . [FIPS-180-4] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, August 2015. [FIPS-202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, August 2015. Schaad Expires March 18, 2021 [Page 10] Internet-Draft COSE Hashes September 2020 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, . 7. Informative References [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . [ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, . [I-D.ietf-cose-x509] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Work in Progress, Internet-Draft, draft- ietf-cose-x509-06, March 9, 2020, . [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, . [I-D.ietf-cose-rfc8152bis-algs] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", Work in Progress, Internet-Draft, draft-ietf-cose-rfc8152bis-algs-11, July 1, 2020, . [I-D.ietf-suit-manifest] Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, "A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest", Work in Progress, Internet- Draft, draft-ietf-suit-manifest-09, July 13, 2020, . [BCP201] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, November 2015. Schaad Expires March 18, 2021 [Page 11] Internet-Draft COSE Hashes September 2020 [SHA-1-collision] Stevens, M., Bursztein, E., Karpman, P., Albertini, A., and Y. Markov, "The first collision for full SHA-1", February 2017, . [COSE] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . Author's Address Jim Schaad August Cellars Email: ietf@augustcellars.com Schaad Expires March 18, 2021 [Page 12] ./draft-ietf-extra-imap-fetch-preview-10.txt0000644000764400076440000006452313735255037020212 0ustar iustyiusty EXTRA M. Slusarz Internet-Draft Open-Xchange Inc. Intended status: Standards Track September 30, 2020 Expires: April 3, 2021 IMAP4 Extension: Message Preview Generation draft-ietf-extra-imap-fetch-preview-10 Abstract This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated text representation of message data useful as a contextual preview of the entire message. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 3, 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Slusarz Expires April 3, 2021 [Page 1] Internet-Draft IMAP: PREVIEW Extension September 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Preview Text Format . . . . . . . . . . . . . . . . . . . 5 4. LAZY Priority Modifier . . . . . . . . . . . . . . . . . . . 5 4.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Client Implementation Advice . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Change History (To be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Many modern mail clients display small extracts of the body text as an aid to allow a user to quickly decide whether they are interested in viewing the full message contents. Mail clients implementing the Internet Message Access Protocol [RFC3501] would benefit from a standardized, consistent way to generate these brief textual previews of messages. Generation of a preview on the server has several benefits. First, it allows consistent representation of previews across all clients. This standardized display can reduce user confusion when using multiple clients, as abbreviated message representations in clients will show identical message contents. Second, server-side preview generation is more efficient. A client- based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE command in order to determine which MIME [RFC2045] body part(s) should be represented in the preview. Subsequently, at least one FETCH BODY command may be needed to retrieve body data used in preview generation. These FETCH commands cannot be pipelined since the BODYSTRUCTURE query must be parsed on the client before the list of parts to be retrieved via the BODY command(s) can be determined. Slusarz Expires April 3, 2021 [Page 2] Internet-Draft IMAP: PREVIEW Extension September 2020 Additionally, it may be difficult to predict the amount of body data that must be retrieved to adequately represent the part via a preview, therefore requiring inefficient fetching of excessive data in order to account for this uncertainty. For example, a preview algorithm to display data contained in a text/html [RFC2854] part will likely strip the markup tags to obtain textual content. However, without fetching the entire content of the part, there is no way to guarantee that sufficient non-tag content will exist unless either 1) the entire part is retrieved or 2) an additional partial FETCH is executed when the client determines that it does not possess sufficient data from a previous partial FETCH to display an adequate representation of the preview. Finally, server generation allows caching in a centralized location. Using server-generated previews allows global generation once per message, and that preview can be cached for the retention period of the source message. Retrieval of message data may be expensive within a server, for example, so a server can be configured to reduce its storage retrieval load by pre-generating preview data. A server indicates support for this extension via the "PREVIEW" capability name. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. "User" is used to refer to a human user, whereas "client" refers to the software being run by the user. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. As with all IMAP extension documents, the case used in writing IMAP protocol elements herein is chosen for editorial clarity, and implementations must pay attention to the numbered rules at the beginning of [RFC3501] Section 9. Slusarz Expires April 3, 2021 [Page 3] Internet-Draft IMAP: PREVIEW Extension September 2020 3. FETCH Data Item 3.1. Command To retrieve a preview for a message, the "PREVIEW" FETCH attribute is used when issuing a FETCH command. 3.2. Response The server returns a variable-length string that is the generated preview for that message. This string is intended to be viewed by the user as a contextual preview of the entire message, and is not intended to be interpreted in any way by the client software. Example: Retrieving preview information in a SELECTed mailbox C: A1 FETCH 1 (PREVIEW) S: * 1 FETCH (PREVIEW "Preview text!") S: A1 OK FETCH complete. A server SHOULD strive to generate the same string for a given message for each request. However, since previews are understood to be an approximation of the message data and not a canonical view of its contents, a client MUST NOT assume that a message preview is immutable for a given message. This relaxed requirement permits a server to offer previews as an option without requiring potentially burdensome storage and/or processing requirements to guarantee immutability for a use case that does not require this strictness. For example, the underlying IMAP server may change due to a system software upgrade; an account's state information may be retained in the migration but the new server may generate different PREVIEW text than the old server. It is possible that the server has determined that no meaningful preview text can be generated for a particular message. Examples of this involve encrypted messages, content types the server does not support previews of, and other situations where the server is not able to extract information for a preview. In such cases, the server MUST return a zero-length string. Clients SHOULD NOT send another FETCH for a preview for such messages. (As discussed previously, preview data is not immutable so there is chance that at some point in the future the server would be able to generate meaningful text. However, this scenario is expected to be rare so a client should not continually send out requests to try to capture this infrequent occurrence.) If the LAZY modifier is used, the server MAY return NIL for the preview response, indicating that preview generation could not be Slusarz Expires April 3, 2021 [Page 4] Internet-Draft IMAP: PREVIEW Extension September 2020 completed without causing undue delay. A server MUST NOT return NIL to a FETCH PREVIEW request made without the LAZY modifier. 3.3. Preview Text Format The generated preview text MUST be treated as text/plain [RFC2046] media type data by the client. The generated string MUST NOT be content transfer encoded and MUST be encoded in UTF-8 [RFC3629]. The server SHOULD remove any formatting markup and do whatever processing might be useful in rendering the preview as plain text. For purposes of this section, a "preview character" is defined as a single UCS character encoded in UTF-8. Note: a single preview character may compromise multiple octets, so any buffers implemented to conform to the string limitations identified in this document should be sized to prevent possible overflow errors. The server SHOULD limit the length of the preview text to 200 preview characters. This length should provide sufficient data to generally support both various languages (and their different average word lengths) and diverse client display size requirements. The server MUST NOT output preview text longer than 256 preview characters. If the preview is not generated based on the body content of the message, and the LANGUAGE [RFC5255] extension is supported by the server, the preview text SHOULD be generated according to the language rules that apply to human-readable text. For example, a message that consists of a single image MIME part has no human- readable text from which to generate preview information. Instead, the server may wish to output a description that the message contains an image and describe some attributes of the image, such as image format, size, and filename. This descriptive text is not a product of the message body itself but is rather auto-generated data by the server, and should thus use the rules defined for human-readable text described in the LANGUAGE extension (if supported on the server). 4. LAZY Priority Modifier 4.1. LAZY The LAZY modifier directs the server to return the preview representation only if that data can be returned without undue delay to the client. Slusarz Expires April 3, 2021 [Page 5] Internet-Draft IMAP: PREVIEW Extension September 2020 If this modifier is used, and the server is unable to return preview data without undue delay, the server MUST return NIL as the preview response. The LAZY modifier MUST be implemented by any server that supports the PREVIEW extension. 4.2. Client Implementation Advice Upon opening a mailbox, a client generally performs a FETCH of message details in order to create a listing to present to the user (e.g. ENVELOPE data). Using this extension, a client may want to additionally display preview information as part of this listing. Quickly providing the base mailbox listing, with basic message details, is the primary goal of this command as this is required to allow the user to begin interacting with the mailbox. Preview data is likely to be of secondary importance; it provides useful context, but it is not necessary to perform message actions. A client can load unavailable previews in the background and display them asynchronously to the user as the preview data is provided by the server. In this scenario, the client would add the PREVIEW data item, with the LAZY modifier, to the list of FETCH items needed to generate the mailbox listing. This allows the server to advantageously return preview data without blocking the primary goal of quickly returning the basic message details used to generate the mailbox listing. Once this initial FETCH is complete, the client can then issue FETCH requests, without the LAZY modifier, to load the PREVIEW data item for the messages in which preview data was not returned. It is RECOMMENDED that these FETCH requests be issued in small batches, e.g., 50 messages per FETCH command, since preview generation may be expensive and a single large request may exceed server resource limits. See Example 2 for an implementation of this strategy. A client SHOULD NOT continually issue LAZY PREVIEW FETCH commands in a selected mailbox as the server is under no requirement to return preview information for this command, which could lead to an unnecessary waste of system and network resources. 5. Examples Slusarz Expires April 3, 2021 [Page 6] Internet-Draft IMAP: PREVIEW Extension September 2020 Example 1: Requesting PREVIEW without LAZY modifier. C: A1 CAPABILITY S: * CAPABILITY IMAP4rev1 PREVIEW S: A1 OK Capability command completed. [...a mailbox is SELECTed...] C: A2 FETCH 1 (RFC822.SIZE PREVIEW) S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW {200} S: Lorem ipsum dolor sit amet, consectetur adipiscing elit. S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue. S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla S: ligula nullam S: ) S: A2 OK FETCH complete. Example 2: Requesting PREVIEW with LAZY modifier, to obtain previews during initial mailbox listing if readily available; otherwise, load previews in background. C: D1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY)) S: * 1 FETCH (ENVELOPE ("Wed, 23 Sep 2020 15:03:11 +0000" [...]) PREVIEW "Preview text for message 1.") S: * 2 FETCH (PREVIEW "" ENVELOPE ("Thu, 24 Sep 2020 12:17:23 +0000" [...])) S: * 3 FETCH (ENVELOPE ("Fri, 25 Sep 2020 09:13:45 +0000" [...]) PREVIEW NIL) S: * 4 FETCH (ENVELOPE ("Sat, 26 Sep 2020 07:11:18 +0000" [...]) PREVIEW NIL) S: D1 OK FETCH completed. [...Client has preview for message 1 and knows that message 2 has a preview that is empty; only need to request preview of messages 3 & 4 (e.g. in background)...] C: D2 FETCH 3:4 (PREVIEW) S: * 3 FETCH (PREVIEW {30} S: Message data from message 3. S: ) S: * 4 FETCH (PREVIEW "Message 4 preview") S: D2 OK Fetch completed. Slusarz Expires April 3, 2021 [Page 7] Internet-Draft IMAP: PREVIEW Extension September 2020 Example 3: Retrieve preview information for search results within a single mailbox. Use SEARCHRES [RFC5182] extension to save a round- trip. C: E1 CAPABILITY S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES S: E1 OK Capability command completed. [...a mailbox is SELECTed...] C: E2 SEARCH RETURN (SAVE) FROM "FOO" C: E3 FETCH $ (UID PREVIEW (LAZY)) S: E2 OK SEARCH completed. S: * 5 FETCH (UID 13 PREVIEW "Preview!") S: * 9 FETCH (UID 23 PREVIEW NIL) S: E3 OK FETCH completed. [...Retrieve message 9 preview in background...] C: E4 UID FETCH 23 (PREVIEW) S: * 9 FETCH (UID 23 PREVIEW "Another preview!") S: E4 OK FETCH completed. 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in ABNF [RFC5234]. It includes definitions from IMAP [RFC3501]. capability =/ "PREVIEW" fetch-att =/ "PREVIEW" [SP "(" preview-mod *(SP preview-mod) ")"] msg-att-dynamic =/ "PREVIEW" SP nstring preview-mod = "LAZY" 7. IANA Considerations IMAP4 [RFC3501] capabilities are registered by publishing a standards track or IESG-approved experimental RFC. The registry is currently located at: http://www.iana.org/assignments/imap-capabilities This document requests that IANA adds the "PREVIEW" capability to the IMAP4 [RFC3501] capabilities registry. Slusarz Expires April 3, 2021 [Page 8] Internet-Draft IMAP: PREVIEW Extension September 2020 8. Security Considerations Implementation of this extension might enable denial-of-service attacks against server resources, due to excessive memory or CPU usage during preview generation or increased storage usage if preview results are stored on the server after generation. In order to mitigate such attacks, servers SHOULD log the client authentication identity on FETCH PREVIEW operations in order to facilitate tracking of abusive clients. Servers MAY limit the resources that preview generation uses. Such resource limitations might, in an extreme example, cause a server to return a preview that is the empty string for a message that otherwise would have had a non-empty preview. However, it is recommended that at least some preview text be provided in this situation, even if the quality of the preview is degraded. Just as the messages they summarize, preview data may contain sensitive information. If generated preview data is stored on the server, e.g. for caching purposes, these previews MUST be protected with equivalent authorization and confidentiality controls as the source message. 9. References 9.1. Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . Slusarz Expires April 3, 2021 [Page 9] Internet-Draft IMAP: PREVIEW Extension September 2020 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, DOI 10.17487/RFC5255, June 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, DOI 10.17487/RFC2854, June 2000, . [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 2008, . Appendix A. Change History (To be removed by RFC Editor before publication) Changes from draft-slusarz-imap-fetch-snippet-00: o Added standardized language to Section 2 regarding IMAP ABNF conventions o Changed draft name to draft-ietf-extra-imap-fetch-snippet-## Changes from draft-ietf-extra-imap-fetch-snippet-00: o Changed nomenclature from "snippet" to "preview" o Changed draft name to draft-ietf-extra-imap-fetch-preview-## o Update to RFC 8174 boilerplate o Updated length requirements for PREVIEW=FUZZY Slusarz Expires April 3, 2021 [Page 10] Internet-Draft IMAP: PREVIEW Extension September 2020 o Added preview-atom ABNF to limit use of "=" character o UTF-8 is a normative reference o Clarify that characters for purpose of length limitations are defined as UCS characters as encoded by UTF-8 o Fix some incorrect literal lengths in examples Changes from draft-ietf-extra-imap-fetch-preview-00: o Updated postal address o Added example to FETCH response section o Added example on how LANGUAGE extension may influence preview generation o Added recommendation that only one LAZY FETCH be executed for a message per mailbox o Added request to create algorithm and modifier registries o Added requirement that algorithm and modifier names conform to RFC 6648 o Added DoS attack info to security considerations o Distinguish between NIL response and zero-length string o Don't use deprecated "X-" convention in example o Spelling and nits Changes from draft-ietf-extra-imap-fetch-preview-01: o Fix capability ABNF o Removed CAPABILITY string for examples where it did not add valuable context o Altered preview data in examples to cover a variety of potential server return scenarios o Added "SHOULD be registered" language to algorithm names and priority modifiers Changes from draft-ietf-extra-imap-fetch-preview-02: Slusarz Expires April 3, 2021 [Page 11] Internet-Draft IMAP: PREVIEW Extension September 2020 o Move Acknowledgments to un-numbered appendix o Improved abstract text o Consistently use "priority modifiers" instead of "modifiers" o Update example to conform with RFC 3501 UID FETCH requirements Changes from draft-ietf-extra-imap-fetch-preview-03: o Remove preview modifier registry request o Improve instructions for registration of algorithms o Add storage information to security considerations o Clarify parsing of algorithm list in FETCH command o Clarify difference between NIL response and zero-length string o Add normative reference for text/plain o Add warning regarding buffers and multiple octet preview characters o Clarify how to handle preview data return when using an explicit algorithm list o Various editorial fixes Changes from draft-ietf-extra-imap-fetch-preview-04: o Make clear that preview caching is tied to retention period of the source message Changes from draft-ietf-extra-imap-fetch-preview-05: o Clarify "zero-length string" preview data vs. NIL preview data o MIME data -> media type o Capability registration should not include the algorithm name o Give example of how PREVIEW data might change over time Changes from draft-ietf-extra-imap-fetch-preview-06: o Change algorithm names to media types Slusarz Expires April 3, 2021 [Page 12] Internet-Draft IMAP: PREVIEW Extension September 2020 o FUZZY algorithm changed to text/imap-fetch-preview o Remove server broadcast of PREVIEW algorithm extensions from capability o Default, fallback algorithm in absence of client selection now MUST be text/imap-fetch-preview o LAZY modifier should work on default algorithm if no specific algorithm is provided as an argument Changes from draft-ietf-extra-imap-fetch-preview-07: o Remove algorithm selection; PREVIEW always returns text in format defined in Section 3.3 Changes from draft-ietf-extra-imap-fetch-preview-08: o FETCH PREVIEW without LAZY modifier MUST NOT return NIL o Improve client implementation advice for LAZY modifier Changes from draft-ietf-extra-imap-fetch-preview-09: o Clarified that string response is to be interpreted by user, not the client o Give example behavior of resource limitation o Various editorial fixes Acknowledgments The author would like to thank the following people for their comments and contributions to this document: Stephan Bosch, Bron Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba, Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi. Author's Address Michael M. Slusarz Open-Xchange Inc. 530 Lytton Avenue Palo Alto, California 94301 US Email: michael.slusarz@open-xchange.com Slusarz Expires April 3, 2021 [Page 13] ./draft-ietf-cose-rfc8152bis-algs-12.txt0000644000764400076440000037422613733154315017041 0ustar iustyiusty COSE Working Group J. Schaad Internet-Draft August Cellars Obsoletes: 8152 (if approved) 24 September 2020 Intended status: Informational Expires: 28 March 2021 CBOR Object Signing and Encryption (COSE): Initial Algorithms draft-ietf-cose-rfc8152bis-algs-12 Abstract Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. THis document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol RFC XXXX. Contributing to this document This note is to be removed before publishing as an RFC. The source for this draft is being maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ cose-wg/cose-rfc8152bis. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantial issues need to be discussed on the COSE mailing list. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 March 2021. Schaad Expires 28 March 2021 [Page 1] Internet-Draft COSE Algorithms September 2020 Copyright Notice Copyright (c) 2020 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 (https://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 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 4 1.3. Document Terminology . . . . . . . . . . . . . . . . . . 4 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Security Considerations for ECDSA . . . . . . . . . . 7 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) . . . 8 2.2.1. Security Considerations for EdDSA . . . . . . . . . . 9 3. Message Authentication Code (MAC) Algorithms . . . . . . . . 9 3.1. Hash-Based Message Authentication Codes (HMACs) . . . . . 9 3.1.1. Security Considerations for HMAC . . . . . . . . . . 11 3.2. AES Message Authentication Code (AES-CBC-MAC) . . . . . . 11 3.2.1. Security Considerations AES-CBC_MAC . . . . . . . . . 12 4. Content Encryption Algorithms . . . . . . . . . . . . . . . . 12 4.1. AES GCM . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Security Considerations for AES-GCM . . . . . . . . . 13 4.2. AES CCM . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Security Considerations for AES-CCM . . . . . . . . . 17 4.3. ChaCha20 and Poly1305 . . . . . . . . . . . . . . . . . . 18 4.3.1. Security Considerations for ChaCha20/Poly1305 . . . . 19 5. Key Derivation Functions (KDFs) . . . . . . . . . . . . . . . 19 5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Context Information Structure . . . . . . . . . . . . . . 21 6. Content Key Distribution Methods . . . . . . . . . . . . . . 26 6.1. Direct Encryption . . . . . . . . . . . . . . . . . . . . 27 6.1.1. Direct Key . . . . . . . . . . . . . . . . . . . . . 27 6.1.2. Direct Key with KDF . . . . . . . . . . . . . . . . . 28 6.2. Key Wrap . . . . . . . . . . . . . . . . . . . . . . . . 29 Schaad Expires 28 March 2021 [Page 2] Internet-Draft COSE Algorithms September 2020 6.2.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 30 6.3. Direct Key Agreement . . . . . . . . . . . . . . . . . . 31 6.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 31 6.4. Key Agreement with Key Wrap . . . . . . . . . . . . . . . 34 6.4.1. ECDH with Key Wrap . . . . . . . . . . . . . . . . . 35 7. Key Object Parameters . . . . . . . . . . . . . . . . . . . . 37 7.1. Elliptic Curve Keys . . . . . . . . . . . . . . . . . . . 37 7.1.1. Double Coordinate Curves . . . . . . . . . . . . . . 38 7.2. Octet Key Pair . . . . . . . . . . . . . . . . . . . . . 39 7.3. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . 40 8. COSE Capabilities . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Assignments for Existing Algorithms . . . . . . . . . . . 42 8.2. Assignments for Existing Key Types . . . . . . . . . . . 42 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 42 9. CBOR Encoding Restrictions . . . . . . . . . . . . . . . . . 45 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10.1. Changes to "COSE Key Types" registry. . . . . . . . . . 45 10.2. Changes to "COSE Algorithms" registry . . . . . . . . . 46 10.3. Changes to the "COSE Key Type Parameters" registry . . . 46 10.4. Expert Review Instructions . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 12.1. Normative References . . . . . . . . . . . . . . . . . . 49 12.2. Informative References . . . . . . . . . . . . . . . . . 51 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). One of the standards that has come out of this process is "Concise Binary Object Representation (CBOR)" [RFC7049]. CBOR extended the data model of JavaScript Object Notation (JSON) [STD90] by allowing for binary data, among other changes. CBOR is being adopted by several of the IETF working groups dealing with the IoT world as their encoding of data structures. CBOR was designed specifically to be both small in terms of messages transported and implementation size and be a schema-free decoder. A need exists to provide message security services for IoT, and using CBOR as the message-encoding format makes sense. The core COSE specification consists of two documents. [I-D.ietf-cose-rfc8152bis-struct] contains the serialization structures and the procedures for using the different cryptographic algorithms. This document provides an initial set of algorithms for use with those structures. Schaad Expires 28 March 2021 [Page 3] Internet-Draft COSE Algorithms September 2020 1.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Changes from RFC8152 * Extract the sections dealing with specific algorithms into this document. The sections dealing with structure and general processing rules are placed in [I-D.ietf-cose-rfc8152bis-struct]. * Text clarifications and changes in terminology. 1.3. Document Terminology In this document, we use the following terminology: Byte is a synonym for octet. Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252]. Authenticated Encryption (AE) [RFC5116] algorithms are encryption algorithms that provide an authentication check of the contents with the encryption service. An example of an AE algorithm used in COSE is AES Key Wrap [RFC3394]. These algorithms are used for key encryption algorithms, but AEAD algorithms would be preferred. Authenticated Encryption with Associated Data (AEAD) [RFC5116] algorithms provide the same authentication service of the content as AE algorithms do. They also allow for associated data to be included in the authentication service, but which is not part of the encrypted body. An example of an AEAD algorithm used in COSE is AES-GCM [RFC5116]. These algorithms are used for content encryption and can be used for key encryption as well. The term 'byte string' is used for sequences of bytes, while the term 'text string' is used for sequences of characters. The tables for algorithms contain the following columns: * A name for use in documents for the algorithms. * The value used on the wire for the algorithm. One place this is used is the algorithm header parameter of a message. Schaad Expires 28 March 2021 [Page 4] Internet-Draft COSE Algorithms September 2020 * A short description so that the algorithm can be easily identified when scanning the IANA registry. Additional columns may be present in the table depending on the algorithms. 1.4. CBOR Grammar At the time that [RFC8152] was initially published, the CBOR Data Definition Language (CDDL) [RFC8610] had not yet been published. This document uses a variant of CDDL which is described in [I-D.ietf-cose-rfc8152bis-struct]. 1.5. Examples A GitHub project has been created at [GitHub-Examples] that contains a set of testing examples as well. Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used for debugging, and the output of the example. The results are encoded using both hexadecimal and CBOR diagnostic notation format. Some of the examples are designed to test failure case; these are clearly marked as such in the JSON file. If errors in the examples in this document are found, the examples on GitHub will be updated, and a note to that effect will be placed in the JSON file. 2. Signature Algorithms Section 9.1 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of signature algorithms. The document defines signature algorithm identifiers for two signature algorithms. 2.1. ECDSA ECDSA [DSS] defines a signature algorithm using ECC. Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithm allows for systems to avoid relying on random number generators in order to avoid generating the same value of 'k' (the per-message random value). Biased generation of the value 'k' can be attacked, and collisions of this value leads to leaked keys. It additionally allows for doing deterministic tests for the signature algorithm. The use of deterministic ECDSA does not lessen the need to have good random number generation when creating the private key. Schaad Expires 28 March 2021 [Page 5] Internet-Draft COSE Algorithms September 2020 The ECDSA signature algorithm is parameterized with a hash function (h). In the event that the length of the hash function output is greater than the group of the key, the leftmost bytes of the hash output are used. The algorithms defined in this document can be found in Table 1. +=======+=======+=========+==================+ | Name | Value | Hash | Description | +=======+=======+=========+==================+ | ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 | +-------+-------+---------+------------------+ | ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 | +-------+-------+---------+------------------+ | ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 | +-------+-------+---------+------------------+ Table 1: ECDSA Algorithm Values This document defines ECDSA to work only with the curves P-256, P-384, and P-521. This document requires that the curves be encoded using the 'EC2' (two coordinate elliptic curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Future documents may define it to work with other curves and points in the future. In order to promote interoperability, it is suggested that SHA-256 be used only with curve P-256, SHA-384 be used only with curve P-384, and SHA-512 be used with curve P-521. This is aligned with the recommendation in Section 4 of [RFC5480]. The signature algorithm results in a pair of integers (R, S). These integers will be the same length as the length of the key used for the signature process. The signature is encoded by converting the integers into byte strings of the same length as the key size. The length is rounded up to the nearest byte and is left padded with zero bits to get to the correct length. The two integers are then concatenated together to form a byte string that is the resulting signature. Using the function defined in [RFC8017], the signature is: Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) When using a COSE key for this algorithm, the following checks are made: Schaad Expires 28 March 2021 [Page 6] Internet-Draft COSE Algorithms September 2020 * The 'kty' field MUST be present, and it MUST be 'EC2'. * If the 'alg' field is present, it MUST match the ECDSA signature algorithm being used. * If the 'key_ops' field is present, it MUST include 'sign' when creating an ECDSA signature. * If the 'key_ops' field is present, it MUST include 'verify' when verifying an ECDSA signature. 2.1.1. Security Considerations for ECDSA The security strength of the signature is no greater than the minimum of the security strength associated with the bit length of the key and the security strength of the hash function. Note: Use of a deterministic signature technique is a good idea even when good random number generation exists. Doing so both reduces the possibility of having the same value of 'k' in two signature operations and allows for reproducible signature values, which helps testing. There have been recent attacks involving faulting the device in order to extract the key. This can be addressed by combining both randomness and determinism [I-D.mattsson-cfrg-det-sigs-with-noise]. There are two substitution attacks that can theoretically be mounted against the ECDSA signature algorithm. * Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have two messages with the same signature, each computed under a different curve. The only requirement on the new curve is that its order be the same as the old one and it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit curves.) We currently do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used. Schaad Expires 28 March 2021 [Page 7] Internet-Draft COSE Algorithms September 2020 * Change the hash function used to validate the signature: If one either has two different hash functions of the same length or can truncate a hash function, then one could potentially find collisions between the hash functions rather than within a single hash function (for example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value). As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including a signature algorithm identifier in the protected header bucket. 2.2. Edwards-Curve Digital Signature Algorithms (EdDSAs) [RFC8032] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing, and HashEdDSA, where a hash function is applied to the content before signing and the result of that hash function is signed. For EdDSA, the content to be signed (either the message or the pre-hash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. This means that there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE object (with the hash value) and the content as separate items. The algorithms defined in this document can be found in Table 2. A single signature algorithm is defined, which can be used for multiple curves. +=======+=======+=============+ | Name | Value | Description | +=======+=======+=============+ | EdDSA | -8 | EdDSA | +-------+-------+-------------+ Table 2: EdDSA Algorithm Values [RFC8032] describes the method of encoding the signature value. When using a COSE key for this algorithm, the following checks are made: Schaad Expires 28 March 2021 [Page 8] Internet-Draft COSE Algorithms September 2020 * The 'kty' field MUST be present, and it MUST be 'OKP' (Octet Key Pair). * The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm. * If the 'alg' field is present, it MUST match 'EdDSA'. * If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature. * If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature. 2.2.1. Security Considerations for EdDSA How public values are computed is not the same when looking at EdDSA and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public key should not be used with the other algorithm. If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED (Section 8.2 of [RFC8032]). Signing and non-batch signature verification are deterministic operations and do not need random numbers of any kind. 3. Message Authentication Code (MAC) Algorithms Section 9.2 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of MAC algorithms. This section defines the conventions for two MAC algorithms. 3.1. Hash-Based Message Authentication Codes (HMACs) HMAC [RFC2104] [RFC4231] was designed to deal with length extension attacks. The algorithm was also designed to allow for new hash algorithms to be directly plugged in without changes to the hash function. The HMAC design process has been shown as solid since, while the security of hash algorithms such as MD5 has decreased over time; the security of HMAC combined with MD5 has not yet been shown to be compromised [RFC6151]. The HMAC algorithm is parameterized by an inner and outer padding, a hash function (h), and an authentication tag value length. For this specification, the inner and outer padding are fixed to the values set in [RFC2104]. The length of the authentication tag corresponds to the difficulty of producing a forgery. For use in constrained environments, we define one HMAC algorithm that is truncated. There are currently no known issues with truncation; however, the security Schaad Expires 28 March 2021 [Page 9] Internet-Draft COSE Algorithms September 2020 strength of the message tag is correspondingly reduced in strength. When truncating, the leftmost tag length bits are kept and transmitted. The algorithms defined in this document can be found in Table 3. +=============+=======+=========+============+======================+ | Name | Value | Hash | Tag Length | Description | +=============+=======+=========+============+======================+ | HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 | | 256/64 | | | | truncated to 64 bits | +-------------+-------+---------+------------+----------------------+ | HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 | | 256/256 | | | | | +-------------+-------+---------+------------+----------------------+ | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | | 384/384 | | | | | +-------------+-------+---------+------------+----------------------+ | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | | 512/512 | | | | | +-------------+-------+---------+------------+----------------------+ Table 3: HMAC Algorithm Values Some recipient algorithms transport the key, while others derive a key from secret data. For those algorithms that transport the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the output of the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. * If the 'alg' field is present, it MUST match the HMAC algorithm being used. * If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag. * If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. Schaad Expires 28 March 2021 [Page 10] Internet-Draft COSE Algorithms September 2020 3.1.1. Security Considerations for HMAC HMAC has proved to be resistant to attack even when used with weakened hash algorithms. The current best known attack is to brute force the key. This means that key size is going to be directly related to the security of an HMAC operation. 3.2. AES Message Authentication Code (AES-CBC-MAC) AES-CBC-MAC is defined in [MAC]. (Note that this is not the same algorithm as AES Cipher-Based Message Authentication Code (AES-CMAC) [RFC4493].) AES-CBC-MAC is parameterized by the key length, the authentication tag length, and the Initialization Vector (IV) used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key lengths and tag lengths. The algorithms defined in this document are found in Table 4. +=========+=======+============+============+==================+ | Name | Value | Key Length | Tag Length | Description | +=========+=======+============+============+==================+ | AES-MAC | 14 | 128 | 64 | AES-MAC 128-bit | | 128/64 | | | | key, 64-bit tag | +---------+-------+------------+------------+------------------+ | AES-MAC | 15 | 256 | 64 | AES-MAC 256-bit | | 256/64 | | | | key, 64-bit tag | +---------+-------+------------+------------+------------------+ | AES-MAC | 25 | 128 | 128 | AES-MAC 128-bit | | 128/128 | | | | key, 128-bit tag | +---------+-------+------------+------------+------------------+ | AES-MAC | 26 | 256 | 128 | AES-MAC 256-bit | | 256/128 | | | | key, 128-bit tag | +---------+-------+------------+------------+------------------+ Table 4: AES-MAC Algorithm Values Keys may be obtained either from a key structure or from a recipient structure. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. Schaad Expires 28 March 2021 [Page 11] Internet-Draft COSE Algorithms September 2020 * If the 'alg' field is present, it MUST match the AES-MAC algorithm being used. * If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag. * If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag. 3.2.1. Security Considerations AES-CBC_MAC A number of attacks exist against Cipher Block Chaining Message Authentication Code (CBC-MAC) that need to be considered. * A single key must only be used for messages of a fixed or known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for messages of different lengths. The current structure mitigates this problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.) * In cipher Block Chaining (CBC) mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code. * If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros. 4. Content Encryption Algorithms Section 9.3 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of Content Encryption algorithms. This document defines the identifier and usages for three content encryption algorithms. 4.1. AES GCM The Galois/Counter Mode (GCM) mode is a generic AEAD block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher. The GCM mode is parameterized by the size of the authentication tag and the size of the nonce. This document fixes the size of the nonce at 96 bits. The size of the authentication tag is limited to a small set of values. For this document however, the size of the authentication tag is fixed at 128 bits. The set of algorithms defined in this document are in Table 5. Schaad Expires 28 March 2021 [Page 12] Internet-Draft COSE Algorithms September 2020 +=========+=======+==========================================+ | Name | Value | Description | +=========+=======+==========================================+ | A128GCM | 1 | AES-GCM mode w/ 128-bit key, 128-bit tag | +---------+-------+------------------------------------------+ | A192GCM | 2 | AES-GCM mode w/ 192-bit key, 128-bit tag | +---------+-------+------------------------------------------+ | A256GCM | 3 | AES-GCM mode w/ 256-bit key, 128-bit tag | +---------+-------+------------------------------------------+ Table 5: Algorithm Value for AES-GCM Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. * If the 'alg' field is present, it MUST match the AES-GCM algorithm being used. * If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. * If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. 4.1.1. Security Considerations for AES-GCM When using AES-GCM, the following restrictions MUST be enforced: * The key and nonce pair MUST be unique for every message encrypted. * The total number of messages encrypted for a single key MUST NOT exceed 2^32 [SP800-38d]. An explicit check is required only in environments where it is expected that it might be exceeded. * A more recent analysis in [ROBUST] indicates that the the number of failed decryptions needs to be taken into account as part determining when a key roll-over is to be done. Following the recommendation of for DTLS, the number of failed message decryptions should be limited to 2^36. Schaad Expires 28 March 2021 [Page 13] Internet-Draft COSE Algorithms September 2020 Consideration was given to supporting smaller tag values; the constrained community would desire tag sizes in the 64-bit range. Doing so drastically changes both the maximum messages size (generally not an issue) and the number of times that a key can be used. Given that Counter with CBC-MAC (CCM) is the usual mode for constrained environments, restricted modes are not supported. 4.2. AES CCM CCM is a generic authentication encryption block cipher mode defined in [RFC3610]. The CCM mode is combined with the AES block encryption algorithm to define a commonly used content encryption algorithm used in constrained devices. The CCM mode has two parameter choices. The first choice is M, the size of the authentication field. The choice of the value for M involves a trade-off between message growth (from the tag) and the probability that an attacker can undetectably modify a message. The second choice is L, the size of the length field. This value requires a trade-off between the maximum message size and the size of the Nonce. It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunderstandings where AES-CCM-8 is frequently used to refer to a version of CCM mode where the size of the authentication is 64 bits and not 8 bits. These values have traditionally been specified as bit counts rather than byte counts. This document will follow the convention of using bit counts so that it is easier to compare the different algorithms presented in this document. We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient- specific cryptographic operations. This favors smaller values of both L and M. Less-constrained devices will want to be able to use larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M. The following values are used for L: 16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. This is sufficiently long for messages in the constrained world. The nonce length is 13 bytes allowing for 2^104 possible values of the nonce without repeating. 64 bits (8): This limits messages to 2^64 bytes in length. The Schaad Expires 28 March 2021 [Page 14] Internet-Draft COSE Algorithms September 2020 nonce length is 7 bytes allowing for 2^56 possible values of the nonce without repeating. The following values are used for M: 64 bits (8): This produces a 64-bit authentication tag. This implies that there is a 1 in 2^64 chance that a modified message will authenticate. 128 bits (16): This produces a 128-bit authentication tag. This implies that there is a 1 in 2^128 chance that a modified message will authenticate. Schaad Expires 28 March 2021 [Page 15] Internet-Draft COSE Algorithms September 2020 +====================+=======+====+=====+========+===============+ | Name | Value | L | M | Key | Description | | | | | | Length | | +====================+=======+====+=====+========+===============+ | AES-CCM-16-64-128 | 10 | 16 | 64 | 128 | AES-CCM mode | | | | | | | 128-bit key, | | | | | | | 64-bit tag, | | | | | | | 13-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-16-64-256 | 11 | 16 | 64 | 256 | AES-CCM mode | | | | | | | 256-bit key, | | | | | | | 64-bit tag, | | | | | | | 13-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-64-64-128 | 12 | 64 | 64 | 128 | AES-CCM mode | | | | | | | 128-bit key, | | | | | | | 64-bit tag, | | | | | | | 7-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-64-64-256 | 13 | 64 | 64 | 256 | AES-CCM mode | | | | | | | 256-bit key, | | | | | | | 64-bit tag, | | | | | | | 7-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-16-128-128 | 30 | 16 | 128 | 128 | AES-CCM mode | | | | | | | 128-bit key, | | | | | | | 128-bit tag, | | | | | | | 13-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-16-128-256 | 31 | 16 | 128 | 256 | AES-CCM mode | | | | | | | 256-bit key, | | | | | | | 128-bit tag, | | | | | | | 13-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-64-128-128 | 32 | 64 | 128 | 128 | AES-CCM mode | | | | | | | 128-bit key, | | | | | | | 128-bit tag, | | | | | | | 7-byte nonce | +--------------------+-------+----+-----+--------+---------------+ | AES-CCM-64-128-256 | 33 | 64 | 128 | 256 | AES-CCM mode | | | | | | | 256-bit key, | | | | | | | 128-bit tag, | | | | | | | 7-byte nonce | +--------------------+-------+----+-----+--------+---------------+ Table 6: Algorithm Values for AES-CCM Schaad Expires 28 March 2021 [Page 16] Internet-Draft COSE Algorithms September 2020 Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. * If the 'alg' field is present, it MUST match the AES-CCM algorithm being used. * If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. * If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. 4.2.1. Security Considerations for AES-CCM When using AES-CCM, the following restrictions MUST be enforced: * The key and nonce pair MUST be unique for every message encrypted. Note that the value of L influences the number of unique nonces. * The total number of times the AES block cipher is used MUST NOT exceed 2^61 operations. This limitation is the sum of times the block cipher is used in computing the MAC value and in performing stream encryption operations. An explicit check is required only in environments where it is expected that it might be exceeded. * [I-D.ietf-quic-tls] contains an analysis on the use of AES-CCM in that environment. Based on that reommendation, one should restrict the number of messages encrypted to 2^23. If one is using the 64-bit tag, then the limits are signficantly smaller if one wants to keep the same integrity limits. A protocol recommending this needs to analysis what level of integrity is acceptable for the smaller tag size. It may be that to keep the desired integrity one needs to re-key as often as every 2^7 messages. * In addition to the number of messages successfully decrypted, the number of failed decryptions needs to be kept as well. If the number of failed decryptions exceeds 2^23 then a rekeying operation should occur. Schaad Expires 28 March 2021 [Page 17] Internet-Draft COSE Algorithms September 2020 [RFC3610] additionally calls out one other consideration of note. It is possible to do a pre-computation attack against the algorithm in cases where portions of the plaintext are highly predictable. This reduces the security of the key size by half. Ways to deal with this attack include adding a random portion to the nonce value and/or increasing the key size used. Using a portion of the nonce for a random value will decrease the number of messages that a single key can be used for. Increasing the key size may require more resources in the constrained device. See Sections 5 and 10 of [RFC3610] for more information. 4.3. ChaCha20 and Poly1305 ChaCha20 and Poly1305 combined together is an AEAD mode that is defined in [RFC8439]. This is an algorithm defined to be a cipher that is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implementations. The ChaCha20/Poly1305 AEAD construction defined in [RFC8439] has no parameterization. It takes a 256-bit key and a 96-bit nonce, as well as the plaintext and additional data as inputs and produces the ciphertext as an option. We define one algorithm identifier for this algorithm in Table 7. +===================+=======+==========================+ | Name | Value | Description | +===================+=======+==========================+ | ChaCha20/Poly1305 | 24 | ChaCha20/Poly1305 w/ | | | | 256-bit key, 128-bit tag | +-------------------+-------+--------------------------+ Table 7: Algorithm Value for ChaCha20/Poly1305 Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. * If the 'alg' field is present, it MUST match the ChaCha20/Poly1305 algorithm being used. Schaad Expires 28 March 2021 [Page 18] Internet-Draft COSE Algorithms September 2020 * If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. * If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. 4.3.1. Security Considerations for ChaCha20/Poly1305 The key and nonce values MUST be a unique pair for every invocation of the algorithm. Nonce counters are considered to be an acceptable way of ensuring that they are unique. A more recent analysis in [ROBUST] indicates that the the number of failed decryptions needs to be taken into account as part determining when a key roll-over is to be done. Following the recommendation of for DTLS, the number of failed message decryptions should be limited to 2^36. [I-D.ietf-quic-tls] recommends that no more than 2^24.5 messages be encrypted under a single key. 5. Key Derivation Functions (KDFs) Section 9.4 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of Key Derivation Functions. This document defines a single context structure and a single KDF. These elements are used for all of the recipient algorithms defined in this document that require a KDF process. These algorithms are defined in Sections 6.1.2, 6.3.1, and 6.4.1. 5.1. HMAC-Based Extract-and-Expand Key Derivation Function (HKDF) The HKDF key derivation algorithm is defined in [RFC5869][HKDF]. The HKDF algorithm takes these inputs: secret -- a shared value that is secret. Secrets may be either previously shared or derived from operations like a Diffie-Hellman (DH) key agreement. Schaad Expires 28 March 2021 [Page 19] Internet-Draft COSE Algorithms September 2020 salt -- an optional value that is used to change the generation process. The salt value can be either public or private. If the salt is public and carried in the message, then the 'salt' algorithm header parameter defined in Table 9 is used. While [RFC5869] suggests that the length of the salt be the same as the length of the underlying hash value, any positive salt length will improve the security as different key values will be generated. This parameter is protected by being included in the key computation and does not need to be separately authenticated. The salt value does not need to be unique for every message sent. length -- the number of bytes of output that need to be generated. context information -- Information that describes the context in which the resulting value will be used. Making this information specific to the context in which the material is going to be used ensures that the resulting material will always be tied to that usage. The context structure defined in Section 5.2 is used by the KDFs in this document. PRF -- The underlying pseudorandom function to be used in the HKDF algorithm. The PRF is encoded into the HKDF algorithm selection. HKDF is defined to use HMAC as the underlying PRF. However, it is possible to use other functions in the same construct to provide a different KDF that is more appropriate in the constrained world. Specifically, one can use AES-CBC-MAC as the PRF for the expand step, but not for the extract step. When using a good random shared secret of the correct length, the extract step can be skipped. For the AES algorithm versions, the extract step is always skipped. The extract step cannot be skipped if the secret is not uniformly random, for example, if it is the result of an ECDH key agreement step. This implies that the AES HKDF version cannot be used with ECDH. If the extract step is skipped, the 'salt' value is not used as part of the HKDF functionality. The algorithms defined in this document are found in Table 8. Schaad Expires 28 March 2021 [Page 20] Internet-Draft COSE Algorithms September 2020 +==============+===================+========================+ | Name | PRF | Description | +==============+===================+========================+ | HKDF SHA-256 | HMAC with SHA-256 | HKDF using HMAC | | | | SHA-256 as the PRF | +--------------+-------------------+------------------------+ | HKDF SHA-512 | HMAC with SHA-512 | HKDF using HMAC | | | | SHA-512 as the PRF | +--------------+-------------------+------------------------+ | HKDF AES- | AES-CBC-MAC-128 | HKDF using AES-MAC as | | MAC-128 | | the PRF w/ 128-bit key | +--------------+-------------------+------------------------+ | HKDF AES- | AES-CBC-MAC-256 | HKDF using AES-MAC as | | MAC-256 | | the PRF w/ 256-bit key | +--------------+-------------------+------------------------+ Table 8: HKDF Algorithms +======+=======+======+============================+=============+ | Name | Label | Type | Algorithm | Description | +======+=======+======+============================+=============+ | salt | -20 | bstr | direct+HKDF-SHA-256, | Random salt | | | | | direct+HKDF-SHA-512, | | | | | | direct+HKDF-AES-128, | | | | | | direct+HKDF-AES-256, ECDH- | | | | | | ES+HKDF-256, ECDH-ES+HKDF- | | | | | | 512, ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, ECDH- | | | | | | ES+A128KW, ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, ECDH- | | | | | | SS+A128KW, ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +------+-------+------+----------------------------+-------------+ Table 9: HKDF Algorithm Parameters 5.2. Context Information Structure The context information structure is used to ensure that the derived keying material is "bound" to the context of the transaction. The context information structure used here is based on that defined in [SP800-56A]. By using CBOR for the encoding of the context information structure, we automatically get the same type and length separation of fields that is obtained by the use of ASN.1. This means that there is no need to encode the lengths for the base elements, as it is done by the encoding used in JOSE (Section 4.6.2 of [RFC7518]). Schaad Expires 28 March 2021 [Page 21] Internet-Draft COSE Algorithms September 2020 The context information structure refers to PartyU and PartyV as the two parties that are doing the key derivation. Unless the application protocol defines differently, we assign PartyU to the entity that is creating the message and PartyV to the entity that is receiving the message. By doing this association, different keys will be derived for each direction as the context information is different in each direction. The context structure is built from information that is known to both entities. This information can be obtained from a variety of sources: * Fields can be defined by the application. This is commonly used to assign fixed names to parties, but it can be used for other items such as nonces. * Fields can be defined by usage of the output. Examples of this are the algorithm and key size that are being generated. * Fields can be defined by parameters from the message. We define a set of header parameters in Table 10 that can be used to carry the values associated with the context structure. Examples of this are identities and nonce values. These header parameters are designed to be placed in the unprotected bucket of the recipient structure; they do not need to be in the protected bucket since they already are included in the cryptographic computation by virtue of being included in the context structure. +==========+=======+======+===========================+=============+ | Name | Label | Type | Algorithm | Description | +==========+=======+======+===========================+=============+ | PartyU | -21 | bstr | direct+HKDF-SHA-256, | Party U | | identity | | | direct+HKDF-SHA-512, | identity | | | | | direct+HKDF-AES-128, | information | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-512, | | | | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, | | | | | | ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, | | | | | | ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ | PartyU | -22 | bstr | direct+HKDF-SHA-256, | Party U | | nonce | | / | direct+HKDF-SHA-512, | provided | Schaad Expires 28 March 2021 [Page 22] Internet-Draft COSE Algorithms September 2020 | | | int | direct+HKDF-AES-128, | nonce | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-512, | | | | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, | | | | | | ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, | | | | | | ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ | PartyU | -23 | bstr | direct+HKDF-SHA-256, | Party U | | other | | | direct+HKDF-SHA-512, | other | | | | | direct+HKDF-AES-128, | provided | | | | | direct+HKDF-AES-256, | information | | | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-512, | | | | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, | | | | | | ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, | | | | | | ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ | PartyV | -24 | bstr | direct+HKDF-SHA-256, | Party V | | identity | | | direct+HKDF-SHA-512, | identity | | | | | direct+HKDF-AES-128, | information | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-512, | | | | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, | | | | | | ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, | | | | | | ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ | PartyV | -25 | bstr | direct+HKDF-SHA-256, | Party V | | nonce | | / | direct+HKDF-SHA-512, | provided | | | | int | direct+HKDF-AES-128, | nonce | | | | | direct+HKDF-AES-256, | | | | | | ECDH-ES+HKDF-256, | | Schaad Expires 28 March 2021 [Page 23] Internet-Draft COSE Algorithms September 2020 | | | | ECDH-ES+HKDF-512, | | | | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, | | | | | | ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, | | | | | | ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ | PartyV | -26 | bstr | direct+HKDF-SHA-256, | Party V | | other | | | direct+HKDF-SHA-512, | other | | | | | direct+HKDF-AES-128, | provided | | | | | direct+HKDF-AES-256, | information | | | | | ECDH-ES+HKDF-256, | | | | | | ECDH-ES+HKDF-512, | | | | | | ECDH-SS+HKDF-256, | | | | | | ECDH-SS+HKDF-512, | | | | | | ECDH-ES+A128KW, | | | | | | ECDH-ES+A192KW, | | | | | | ECDH-ES+A256KW, | | | | | | ECDH-SS+A128KW, | | | | | | ECDH-SS+A192KW, | | | | | | ECDH-SS+A256KW | | +----------+-------+------+---------------------------+-------------+ Table 10: Context Algorithm Parameters We define a CBOR object to hold the context information. This object is referred to as COSE_KDF_Context. The object is based on a CBOR array type. The fields in the array are: AlgorithmID: This field indicates the algorithm for which the key material will be used. This normally is either a key wrap algorithm identifier or a content encryption algorithm identifier. The values are from the "COSE Algorithms" registry. This field is required to be present. The field exists in the context information so that a different key is generated for each algorithm even of all of the other context information is the same. In practice, this means if algorithm A is broken and thus finding the key is relatively easy, the key derived for algorithm B will not be the same as the key derived for algorithm A. PartyUInfo: This field holds information about party U. The PartyUInfo is encoded as a CBOR array. The elements of PartyUInfo are encoded in the order presented below. The elements of the PartyUInfo array are: Schaad Expires 28 March 2021 [Page 24] Internet-Draft COSE Algorithms September 2020 identity: This contains the identity information for party U. The identities can be assigned in one of two manners. First, a protocol can assign identities based on roles. For example, the roles of "client" and "server" may be assigned to different entities in the protocol. Each entity would then use the correct label for the data they send or receive. The second way for a protocol to assign identities is to use a name based on a naming system (i.e., DNS, X.509 names). We define an algorithm parameter 'PartyU identity' that can be used to carry identity information in the message. However, identity information is often known as part of the protocol and can thus be inferred rather than made explicit. If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information. The identity information does not need to be specified and is set to nil in that case. nonce: This contains a nonce value. The nonce can either be implicit from the protocol or be carried as a value in the unprotected header bucket. We define an algorithm parameter 'PartyU nonce' that can be used to carry this value in the message; however, the nonce value could be determined by the application and the value determined from elsewhere. This option does not need to be specified and is set to nil in that case. other: This contains other information that is defined by the protocol. This option does not need to be specified and is set to nil in that case. PartyVInfo: This field holds information about party V. The content of the structure is the same as for the PartyUInfo but for party V. SuppPubInfo: This field contains public information that is mutually known to both parties. keyDataLength: This is set to the number of bits of the desired output value. This practice means if algorithm A can use two different key lengths, the key derived for longer key size will not contain the key for shorter key size as a prefix. protected: This field contains the protected parameter field. If Schaad Expires 28 March 2021 [Page 25] Internet-Draft COSE Algorithms September 2020 there are no elements in the protected field, then use a zero- length bstr. other: This field is for free form data defined by the application. An example is that an application could define two different byte strings to be placed here to generate different keys for a data stream versus a control stream. This field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included. SuppPrivInfo: This field contains private information that is mutually known private information. An example of this information would be a preexisting shared secret. (This could, for example, be used in combination with an ECDH key agreement to provide a secondary proof of identity.) The field is optional and will only be present if the application defines a structure for this information. Applications that define this SHOULD use CBOR to encode the data so that types and lengths are correctly included. The following CDDL fragment corresponds to the text above. PartyInfo = ( identity : bstr / nil, nonce : bstr / int / nil, other : bstr / nil ) COSE_KDF_Context = [ AlgorithmID : int / tstr, PartyUInfo : [ PartyInfo ], PartyVInfo : [ PartyInfo ], SuppPubInfo : [ keyDataLength : uint, protected : empty_or_serialized_map, ? other : bstr ], ? SuppPrivInfo : bstr ] 6. Content Key Distribution Methods Section 9.5 of [I-D.ietf-cose-rfc8152bis-struct] contains a generic description of content key distribution methods. This document defines the identifiers and usage for a number of content key distribution methods. Schaad Expires 28 March 2021 [Page 26] Internet-Draft COSE Algorithms September 2020 6.1. Direct Encryption Direct encryption algorithm is defined in Section 9.5.1 of [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in the COSE_Recipient structure are detailed there. 6.1.1. Direct Key This recipient algorithm is the simplest; the identified key is directly used as the key for the next layer down in the message. There are no algorithm parameters defined for this algorithm. The algorithm identifier value is assigned in Table 11. When this algorithm is used, the protected field MUST be zero length. The key type MUST be 'Symmetric'. +========+=======+===================+ | Name | Value | Description | +========+=======+===================+ | direct | -6 | Direct use of CEK | +--------+-------+-------------------+ Table 11: Direct Key 6.1.1.1. Security Considerations for Direct Key This recipient algorithm has several potential problems that need to be considered: * These keys need to have some method to be regularly updated over time. All of the content encryption algorithms specified in this document have limits on how many times a key can be used without significant loss of security. * These keys need to be dedicated to a single algorithm. There have been a number of attacks developed over time when a single key is used for multiple different algorithms. One example of this is the use of a single key for both the CBC encryption mode and the CBC-MAC authentication mode. * Breaking one message means all messages are broken. If an adversary succeeds in determining the key for a single message, then the key for all messages is also determined. Schaad Expires 28 March 2021 [Page 27] Internet-Draft COSE Algorithms September 2020 6.1.2. Direct Key with KDF These recipient algorithms take a common shared secret between the two parties and applies the HKDF function (Section 5.1), using the context structure defined in Section 5.2 to transform the shared secret into the CEK. The 'protected' field can be of non-zero length. Either the 'salt' parameter of HKDF or the 'PartyU nonce' parameter of the context structure MUST be present. The salt/nonce parameter can be generated either randomly or deterministically. The requirement is that it be a unique value for the shared secret in question. If the salt/nonce value is generated randomly, then it is suggested that the length of the random value be the same length as the output of the hash function underlying HKDF. While there is no way to guarantee that it will be unique, there is a high probability that it will be unique. If the salt/nonce value is generated deterministically, it can be guaranteed to be unique, and thus there is no length requirement. A new IV must be used for each message if the same key is used. The IV can be modified in a predictable manner, a random manner, or an unpredictable manner (i.e., encrypting a counter). The IV used for a key can also be generated from the same HKDF functionality as the key is generated. If HKDF is used for generating the IV, the algorithm identifier is set to "IV- GENERATION". The set of algorithms defined in this document can be found in Table 12. Schaad Expires 28 March 2021 [Page 28] Internet-Draft COSE Algorithms September 2020 +=====================+=======+==============+=====================+ | Name | Value | KDF | Description | +=====================+=======+==============+=====================+ | direct+HKDF-SHA-256 | -10 | HKDF SHA-256 | Shared secret w/ | | | | | HKDF and SHA-256 | +---------------------+-------+--------------+---------------------+ | direct+HKDF-SHA-512 | -11 | HKDF SHA-512 | Shared secret w/ | | | | | HKDF and SHA-512 | +---------------------+-------+--------------+---------------------+ | direct+HKDF-AES-128 | -12 | HKDF AES- | Shared secret w/ | | | | MAC-128 | AES-MAC 128-bit key | +---------------------+-------+--------------+---------------------+ | direct+HKDF-AES-256 | -13 | HKDF AES- | Shared secret w/ | | | | MAC-256 | AES-MAC 256-bit key | +---------------------+-------+--------------+---------------------+ Table 12: Direct Key with KDF When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. * If the 'alg' field is present, it MUST match the algorithm being used. * If the 'key_ops' field is present, it MUST include 'deriveKey' or 'deriveBits'. 6.1.2.1. Security Considerations for Direct Key with KDF The shared secret needs to have some method to be regularly updated over time. The shared secret forms the basis of trust. Although not used directly, it should still be subject to scheduled rotation. While these methods do not provide for perfect forward secrecy, as the same shared secret is used for all of the keys generated, if the key for any single message is discovered, only the message (or series of messages) using that derived key are compromised. A new key derivation step will generate a new key that requires the same amount of work to get the key. 6.2. Key Wrap Key wrap is defined in Section 9.5.1 of [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in the COSE_Recipient structure is detailed there. Schaad Expires 28 March 2021 [Page 29] Internet-Draft COSE Algorithms September 2020 6.2.1. AES Key Wrap The AES Key Wrap algorithm is defined in [RFC3394]. This algorithm uses an AES key to wrap a value that is a multiple of 64 bits. As such, it can be used to wrap a key for any of the content encryption algorithms defined in this document. The algorithm requires a single fixed parameter, the initial value. This is fixed to the value specified in Section 2.2.3.1 of [RFC3394]. There are no public key parameters that vary on a per-invocation basis. The protected header bucket MUST be empty. Keys may be obtained either from a key structure or from a recipient structure. Implementations encrypting and decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'Symmetric'. * If the 'alg' field is present, it MUST match the AES Key Wrap algorithm being used. * If the 'key_ops' field is present, it MUST include 'encrypt' or 'wrap key' when encrypting. * If the 'key_ops' field is present, it MUST include 'decrypt' or 'unwrap key' when decrypting. +========+=======+==========+=============================+ | Name | Value | Key Size | Description | +========+=======+==========+=============================+ | A128KW | -3 | 128 | AES Key Wrap w/ 128-bit key | +--------+-------+----------+-----------------------------+ | A192KW | -4 | 192 | AES Key Wrap w/ 192-bit key | +--------+-------+----------+-----------------------------+ | A256KW | -5 | 256 | AES Key Wrap w/ 256-bit key | +--------+-------+----------+-----------------------------+ Table 13: AES Key Wrap Algorithm Values 6.2.1.1. Security Considerations for AES-KW The shared secret needs to have some method to be regularly updated over time. The shared secret is the basis of trust. Schaad Expires 28 March 2021 [Page 30] Internet-Draft COSE Algorithms September 2020 6.3. Direct Key Agreement Key Transport is defined in Section 9.5.4 of [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in the COSE_Recipient structure is detailed there. 6.3.1. Direct ECDH The mathematics for ECDH can be found in [RFC6090]. In this document, the algorithm is extended to be used with the two curves defined in [RFC7748]. ECDH is parameterized by the following: * Curve Type/Curve: The curve selected controls not only the size of the shared secret, but the mathematics for computing the shared secret. The curve selected also controls how a point in the curve is represented and what happens for the identity points on the curve. In this specification, we allow for a number of different curves to be used. A set of curves are defined in Table 18. The math used to obtain the computed secret is based on the curve selected and not on the ECDH algorithm. For this reason, a new algorithm does not need to be defined for each of the curves. * Computed Secret to Shared Secret: Once the computed secret is known, the resulting value needs to be converted to a byte string to run the KDF. The x-coordinate is used for all of the curves defined in this document. For curves X25519 and X448, the resulting value is used directly as it is a byte string of a known length. For the P-256, P-384, and P-521 curves, the x-coordinate is run through the I2OSP function defined in [RFC8017], using the same computation for n as is defined in Section 2.1. * Ephemeral-Static or Static-Static: The key agreement process may be done using either a static or an ephemeral key for the sender's side. When using ephemeral keys, the sender MUST generate a new ephemeral key for every key agreement operation. The ephemeral key is placed in the 'ephemeral key' parameter and MUST be present for all algorithm identifiers that use ephemeral keys. When using static keys, the sender MUST either generate a new random value or create a unique value. For the KDFs used, this means either the 'salt' parameter for HKDF (Table 9) or the 'PartyU nonce' parameter for the context structure (Table 10) MUST be present (both can be present if desired). The value in the parameter MUST be unique for the pair of keys being used. It is acceptable to use a global counter that is incremented for every static-static operation and use the resulting value. Care must be taken that Schaad Expires 28 March 2021 [Page 31] Internet-Draft COSE Algorithms September 2020 the counter is saved to permanent storage in a way to avoid reuse of that counter value. When using static keys, the static key should be identified to the recipient. The static key can be identified either by providing the key ('static key') or by providing a key identifier for the static key ('static key id'). Both of these header parameters are defined in Table 15. * Key Derivation Algorithm: The result of an ECDH key agreement process does not provide a uniformly random secret. As such, it needs to be run through a KDF in order to produce a usable key. Processing the secret through a KDF also allows for the introduction of context material: how the key is going to be used and one-time material for static-static key agreement. All of the algorithms defined in this document use one of the HKDF algorithms defined in Section 5.1 with the context structure defined in Section 5.2. * Key Wrap Algorithm: No key wrap algorithm is used. This is represented in Table 14 as 'none'. The key size for the context structure is the content layer encryption algorithm size. COSE does not have an Ephemeral-Ephemeral version defined. The reason for this is that COSE is not an online protocol by itself and thus does not have a method to establish ephemeral secrets on both sides. The expectation is that a protocol would establish the secrets for both sides, and then they would be used as static-static for the purposes of COSE, or that the protocol would generate a shared secret and a direct encryption would be used. The set of direct ECDH algorithms defined in this document are found in Table 14. Schaad Expires 28 March 2021 [Page 32] Internet-Draft COSE Algorithms September 2020 +===========+=======+=========+============+======+=================+ | Name | Value | KDF | Ephemeral- | Key | Description | | | | | Static | Wrap | | +===========+=======+=========+============+======+=================+ | ECDH-ES | -25 | HKDF - | yes | none | ECDH ES w/ HKDF | | + | | SHA-256 | | | - generate key | | HKDF-256 | | | | | directly | +-----------+-------+---------+------------+------+-----------------+ | ECDH-ES | -26 | HKDF - | yes | none | ECDH ES w/ HKDF | | + | | SHA-512 | | | - generate key | | HKDF-512 | | | | | directly | +-----------+-------+---------+------------+------+-----------------+ | ECDH-SS | -27 | HKDF - | no | none | ECDH SS w/ HKDF | | + | | SHA-256 | | | - generate key | | HKDF-256 | | | | | directly | +-----------+-------+---------+------------+------+-----------------+ | ECDH-SS | -28 | HKDF - | no | none | ECDH SS w/ HKDF | | + | | SHA-512 | | | - generate key | | HKDF-512 | | | | | directly | +-----------+-------+---------+------------+------+-----------------+ Table 14: ECDH Algorithm Values +===========+=======+==========+===================+=============+ | Name | Label | Type | Algorithm | Description | +===========+=======+==========+===================+=============+ | ephemeral | -1 | COSE_Key | ECDH-ES+HKDF-256, | Ephemeral | | key | | | ECDH-ES+HKDF-512, | public key | | | | | ECDH-ES+A128KW, | for the | | | | | ECDH-ES+A192KW, | sender | | | | | ECDH-ES+A256KW | | +-----------+-------+----------+-------------------+-------------+ | static | -2 | COSE_Key | ECDH-SS+HKDF-256, | Static | | key | | | ECDH-SS+HKDF-512, | public key | | | | | ECDH-SS+A128KW, | for the | | | | | ECDH-SS+A192KW, | sender | | | | | ECDH-SS+A256KW | | +-----------+-------+----------+-------------------+-------------+ | static | -3 | bstr | ECDH-SS+HKDF-256, | Static | | key id | | | ECDH-SS+HKDF-512, | public key | | | | | ECDH-SS+A128KW, | identifier | | | | | ECDH-SS+A192KW, | for the | | | | | ECDH-SS+A256KW | sender | +-----------+-------+----------+-------------------+-------------+ Table 15: ECDH Algorithm Parameters Schaad Expires 28 March 2021 [Page 33] Internet-Draft COSE Algorithms September 2020 This document defines these algorithms to be used with the curves P-256, P-384, P-521, X25519, and X448. Implementations MUST verify that the key type and curve are correct. Different curves are restricted to different key types. Implementations MUST verify that the curve and algorithm are appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. * If the 'alg' field is present, it MUST match the key agreement algorithm being used. * If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key. * If the 'key_ops' field is present, it MUST be empty for the public key. 6.3.1.1. Security Considerations for ECDH There is a method of checking that points provided from external entities are valid. For the 'EC2' key format, this can be done by checking that the x and y values form a point on the curve. For the 'OKP' format, there is no simple way to do point validation. Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process (as recommended in Section 6.4 of [RFC7748]). This was not done as COSE is used in a store and forward format rather than in online key exchange. In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious. In either case, all security evaporates anyway. A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted (either by the end user or by the entity that is responsible for making trust statements on keys). 6.4. Key Agreement with Key Wrap Key Agreement with Key Wrap is defined in Section 9.5.5 of [I-D.ietf-cose-rfc8152bis-struct]. Information about how to fill in the COSE_Recipient structure are detailed there. Schaad Expires 28 March 2021 [Page 34] Internet-Draft COSE Algorithms September 2020 6.4.1. ECDH with Key Wrap These algorithms are defined in Table 16. ECDH with Key Agreement is parameterized by the same header parameters as for ECDH; see Section 6.3.1, with the following modifications: * Key Wrap Algorithm: Any of the key wrap algorithms defined in Section 6.2 are supported. The size of the key used for the key wrap algorithm is fed into the KDF. The set of identifiers are found in Table 16. Schaad Expires 28 March 2021 [Page 35] Internet-Draft COSE Algorithms September 2020 +=========+=======+=========+============+========+================+ | Name | Value | KDF | Ephemeral- | Key | Description | | | | | Static | Wrap | | +=========+=======+=========+============+========+================+ | ECDH-ES | -29 | HKDF - | yes | A128KW | ECDH ES w/ | | + | | SHA-256 | | | Concat KDF and | | A128KW | | | | | AES Key Wrap | | | | | | | w/ 128-bit key | +---------+-------+---------+------------+--------+----------------+ | ECDH-ES | -30 | HKDF - | yes | A192KW | ECDH ES w/ | | + | | SHA-256 | | | Concat KDF and | | A192KW | | | | | AES Key Wrap | | | | | | | w/ 192-bit key | +---------+-------+---------+------------+--------+----------------+ | ECDH-ES | -31 | HKDF - | yes | A256KW | ECDH ES w/ | | + | | SHA-256 | | | Concat KDF and | | A256KW | | | | | AES Key Wrap | | | | | | | w/ 256-bit key | +---------+-------+---------+------------+--------+----------------+ | ECDH-SS | -32 | HKDF - | no | A128KW | ECDH SS w/ | | + | | SHA-256 | | | Concat KDF and | | A128KW | | | | | AES Key Wrap | | | | | | | w/ 128-bit key | +---------+-------+---------+------------+--------+----------------+ | ECDH-SS | -33 | HKDF - | no | A192KW | ECDH SS w/ | | + | | SHA-256 | | | Concat KDF and | | A192KW | | | | | AES Key Wrap | | | | | | | w/ 192-bit key | +---------+-------+---------+------------+--------+----------------+ | ECDH-SS | -34 | HKDF - | no | A256KW | ECDH SS w/ | | + | | SHA-256 | | | Concat KDF and | | A256KW | | | | | AES Key Wrap | | | | | | | w/ 256-bit key | +---------+-------+---------+------------+--------+----------------+ Table 16: ECDH Algorithm Values with Key Wrap When using a COSE key for this algorithm, the following checks are made: * The 'kty' field MUST be present, and it MUST be 'EC2' or 'OKP'. * If the 'alg' field is present, it MUST match the key agreement algorithm being used. * If the 'key_ops' field is present, it MUST include 'derive key' or 'derive bits' for the private key. Schaad Expires 28 March 2021 [Page 36] Internet-Draft COSE Algorithms September 2020 * If the 'key_ops' field is present, it MUST be empty for the public key. 7. Key Object Parameters The COSE_Key object defines a way to hold a single key object. It is still required that the members of individual key types be defined. This section of the document is where we define an initial set of members for specific key types. For each of the key types, we define both public and private members. The public members are what is transmitted to others for their usage. Private members allow for the archival of keys by individuals. However, there are some circumstances in which private keys may be distributed to entities in a protocol. Examples include: entities that have poor random number generation, centralized key creation for multi-cast type operations, and protocols in which a shared secret is used as a bearer token for authorization purposes. Key types are identified by the 'kty' member of the COSE_Key object. In this document, we define four values for the member: +===========+=======+==========================+ | Name | Value | Description | +===========+=======+==========================+ | OKP | 1 | Octet Key Pair | +-----------+-------+--------------------------+ | EC2 | 2 | Elliptic Curve Keys w/ | | | | x- and y-coordinate pair | +-----------+-------+--------------------------+ | Symmetric | 4 | Symmetric Keys | +-----------+-------+--------------------------+ | Reserved | 0 | This value is reserved | +-----------+-------+--------------------------+ Table 17: Key Type Values 7.1. Elliptic Curve Keys Two different key structures are defined for elliptic curve keys. One version uses both an x-coordinate and a y-coordinate, potentially with point compression ('EC2'). This is the traditional EC point representation that is used in [RFC5480]. The other version uses only the x-coordinate as the y-coordinate is either to be recomputed or not needed for the key agreement operation ('OKP'). Applications MUST check that the curve and the key type are consistent and reject a key if they are not. Schaad Expires 28 March 2021 [Page 37] Internet-Draft COSE Algorithms September 2020 +=========+=======+==========+====================================+ | Name | Value | Key Type | Description | +=========+=======+==========+====================================+ | P-256 | 1 | EC2 | NIST P-256 also known as secp256r1 | +---------+-------+----------+------------------------------------+ | P-384 | 2 | EC2 | NIST P-384 also known as secp384r1 | +---------+-------+----------+------------------------------------+ | P-521 | 3 | EC2 | NIST P-521 also known as secp521r1 | +---------+-------+----------+------------------------------------+ | X25519 | 4 | OKP | X25519 for use w/ ECDH only | +---------+-------+----------+------------------------------------+ | X448 | 5 | OKP | X448 for use w/ ECDH only | +---------+-------+----------+------------------------------------+ | Ed25519 | 6 | OKP | Ed25519 for use w/ EdDSA only | +---------+-------+----------+------------------------------------+ | Ed448 | 7 | OKP | Ed448 for use w/ EdDSA only | +---------+-------+----------+------------------------------------+ Table 18: Elliptic Curves 7.1.1. Double Coordinate Curves The traditional way of sending ECs has been to send either both the x-coordinate and y-coordinate or the x-coordinate and a sign bit for the y-coordinate. The latter encoding has not been recommended in the IETF due to potential IPR issues. However, for operations in constrained environments, the ability to shrink a message by not sending the y-coordinate is potentially useful. For EC keys with both coordinates, the 'kty' member is set to 2 (EC2). The key parameters defined in this section are summarized in Table 19. The members that are defined for this key type are: crv: This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 18. Other curves may be registered in the future, and private curves can be used as well. x: This contains the x-coordinate for the EC point. The integer is converted to a byte string as defined in [SEC1]. Leading zero octets MUST be preserved. y: This contains either the sign bit or the value of the y-coordinate for the EC point. When encoding the value y, the integer is converted to an byte string (as defined in [SEC1]) and encoded as a CBOR bstr. Leading zero octets MUST be preserved. The compressed point encoding is also supported. Compute the sign bit as laid out in the Elliptic-Curve-Point-to- Schaad Expires 28 March 2021 [Page 38] Internet-Draft COSE Algorithms September 2020 Octet-String Conversion function of [SEC1]. If the sign bit is zero, then encode y as a CBOR false value; otherwise, encode y as a CBOR true value. The encoding of the infinity point is not supported. d: This contains the private key. For public keys, it is REQUIRED that 'crv', 'x', and 'y' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' and 'y' also be present, but they can be recomputed from the required elements and omitting them saves on space. +======+======+=======+========+=================================+ | Key | Name | Label | CBOR | Description | | Type | | | Type | | +======+======+=======+========+=================================+ | 2 | crv | -1 | int / | EC identifier - Taken from the | | | | | tstr | "COSE Elliptic Curves" registry | +------+------+-------+--------+---------------------------------+ | 2 | x | -2 | bstr | x-coordinate | +------+------+-------+--------+---------------------------------+ | 2 | y | -3 | bstr / | y-coordinate | | | | | bool | | +------+------+-------+--------+---------------------------------+ | 2 | d | -4 | bstr | Private key | +------+------+-------+--------+---------------------------------+ Table 19: EC Key Parameters 7.2. Octet Key Pair A new key type is defined for Octet Key Pairs (OKP). Do not assume that keys using this type are elliptic curves. This key type could be used for other curve types (for example, mathematics based on hyper-elliptic surfaces). The key parameters defined in this section are summarized in Table 20. The members that are defined for this key type are: crv: This contains an identifier of the curve to be used with the key. The curves defined in this document for this key type can be found in Table 18. Other curves may be registered in the future and private curves can be used as well. x: This contains the public key. The byte string contains the public key as defined by the algorithm. (For X25519, internally it is a little-endian integer.) Schaad Expires 28 March 2021 [Page 39] Internet-Draft COSE Algorithms September 2020 d: This contains the private key. For public keys, it is REQUIRED that 'crv' and 'x' be present in the structure. For private keys, it is REQUIRED that 'crv' and 'd' be present in the structure. For private keys, it is RECOMMENDED that 'x' also be present, but it can be recomputed from the required elements and omitting it saves on space. +======+==========+=======+=======+=================================+ | Name | Key | Label | Type | Description | | | Type | | | | +======+==========+=======+=======+=================================+ | crv | 1 | -1 | int / | EC identifier - Taken from the | | | | | tstr | "COSE Elliptic Curves" registry | +------+----------+-------+-------+---------------------------------+ | x | 1 | -2 | bstr | Public Key | +------+----------+-------+-------+---------------------------------+ | d | 1 | -4 | bstr | Private key | +------+----------+-------+-------+---------------------------------+ Table 20: Octet Key Pair Parameters 7.3. Symmetric Keys Occasionally it is required that a symmetric key be transported between entities. This key structure allows for that to happen. For symmetric keys, the 'kty' member is set to 4 ('Symmetric'). The member that is defined for this key type is: k: This contains the value of the key. This key structure does not have a form that contains only public members. As it is expected that this key structure is going to be transmitted, care must be taken that it is never transmitted accidentally or insecurely. For symmetric keys, it is REQUIRED that 'k' be present in the structure. +======+==========+=======+======+=============+ | Name | Key Type | Label | Type | Description | +======+==========+=======+======+=============+ | k | 4 | -1 | bstr | Key Value | +------+----------+-------+------+-------------+ Table 21: Symmetric Key Parameters Schaad Expires 28 March 2021 [Page 40] Internet-Draft COSE Algorithms September 2020 8. COSE Capabilities There are some situations that have been identified where identification of capabilities of an algorithm or a key type need to be specified. One example of this is in [I-D.ietf-core-oscore-groupcomm] where the capabilities of the counter signature algorithm are mixed into the traffic key derivation process. This has a counterpart in the S/MIME specifications where SMIMECapabilities is defined in Section 2.5a.2 of [RFC8551]. This document defines the same concept for COSE. The algorithm identifier is not included in the capabilities data as it should be encoded elsewhere in the message. The key type identifier is included in the capabilities data as it is not expected to be encoded elsewhere. Two different types of capabilities are defined: capabilities for algorithms and capabilities for key type. Once defined by registration with IANA, the list of capabilities for an algorithm or key type is immutable. If it is later found that a new capability is needed for a key type or an algorithm, it will require that a new code point be assigned to deal with that. As a general rule, the capabilities are going to map to algorithm-specific header parameters or key parameters, but they do not need to do so. An example of this is the HSS-LMS key capabilities defined below where the hash algorithm used is included. The capability structure is an array of values, the values included in the structure are dependent on a specific algorithm or key type. For algorithm capabilities, the first element should always be a key type value if applicable, but the items that are specific to a key (for example a curve) should not be included in the algorithm capabilities. This means that if one wishes to enumerate all of the capabilities for a device which implements ECDH, it requires that all of the combinations of algorithms and key pairs to be specified. The last example of Section 8.3 provides a case where this is done by allowing for a cross product to be specified between an array of algorithm capabilities and key type capabilities (see ECDH-ES+A25KW element). For a key, the first element should be the key type value. While this means that the key type value will be duplicated if both an algorithm and key capability are used, the key type is needed in order to understand the rest of the values. Schaad Expires 28 March 2021 [Page 41] Internet-Draft COSE Algorithms September 2020 8.1. Assignments for Existing Algorithms For the current set of algorithms in the registry, those in this document as well as those in [RFC8230] and [I-D.ietf-cose-hash-sig], the capabilities list is an array with one element, the key type (from the "COSE Key Types" Registry). It is expected that future registered algorithms could have zero, one, or multiple elements. 8.2. Assignments for Existing Key Types There are a number of pre-existing key types, the following deals with creating the capability definition for those structures: * OKP, EC2: The list of capabilities is: - The key type value. (1 for OKP or 2 for EC2.) - One curve for that key type from the "COSE Elliptic Curve" registry. * RSA: The list of capabilities is: - The key type value (3). * Symmetric: The list of capabilities is: - The key type value (4). * HSS-LMS: The list of capabilities is: - The key type value (5), - Algorithm identifier for the underlying hash function from the "COSE Algorithms" registry. 8.3. Examples Capabilities can be use in a key derivation process to make sure that both sides are using the same parameters. This is the approach that is being used by the group communication KDF in [I-D.ietf-core-oscore-groupcomm]. The three examples below show different ways that one might include things: * Just an algorithm capability: This is useful if the protocol wants to require a specific algorithm such as ECDSA, but it is agnostic about which curve is being used. This does require that the algorithm identifier be specified in the protocol. See the first example. Schaad Expires 28 March 2021 [Page 42] Internet-Draft COSE Algorithms September 2020 * Just a key type capability: This is useful if the protccol wants to require a specific a specific key type and curve, such as P-256, but will accept any algorithm using that curve (e.g. both ECDSA and ECDH). See the second example. * Both an algorithm and a key type capability: This is used if the protocol needs to nail down all of the options surrounding an algorithm E.g. EdDSA with the curve X25519. As with the first example, the algorithm identifier needs to be specified in the protocol. See the third example which just concatenates the two capabilities together. Algorithm ECDSA 0x8102 / [2 \ EC2 \ ] / Key type EC2 with P-256 curve: 0x820201 / [2 \ EC2 \, 1 \ P-256 \] / ECDH-ES + A256KW with an X25519 curve: 0x8101820104 / [1 \ OKP \],[1 \ OKP \, 4 \ X25519 \] / The capabilities can also be used by and entity to advertise what it is capabable of doing. The decoded example below is one of many encoding that could be used for that purpose. Each array element includes three fields: the algorithm identifier, one or more algorithm capabilities, and one or more key type capabilities. Schaad Expires 28 March 2021 [Page 43] Internet-Draft COSE Algorithms September 2020 [ [-8 / EdDSA /, [1 / OKP key type /], [ [1 / OKP /, 6 / Ed25519 / ], [1 /OKP/, 7 /Ed448 /] ] ], [-7 / ECDSA with SHA-256/, [2 /EC2 key type/], [ [2 /EC2/, 1 /P-256/], [2 /EC2/, 3 /P-521/] ] ], [ -31 / ECDH-ES+A256KW/, [ [ 2 /EC2/], [1 /OKP/ ] ], [ [2 /EC2/, 1 /P-256/], [1 /OKP/, 4 / X25519/ ] ] ], [ 1 / A128GCM /, [ 4 / Symmetric / ], [ 4 / Symmetric /] ] ] Examining the above: * The first element indicates that the entity supports EdDSA with curves Ed25519 and Ed448. * The second element indicates that the entity supports ECDSA with curves P-256 and P-521. * The third element indicates that the entity support ephemeral- static ECDH using AES256 key wrap. The entity can support the P-256 curve with an EC2 key type and the X25519 curve with an OKP key type. * The last element indicates that the entity supports AES-GCM of 128 bits for content encryption. The entity does not advertise that it supports any MAC algorithms. Schaad Expires 28 March 2021 [Page 44] Internet-Draft COSE Algorithms September 2020 9. CBOR Encoding Restrictions This document limits the restrictions it imposes on how the CBOR Encoder needs to work. It has been narrowed down to the following restrictions: * The restriction applies to the encoding of the COSE_KDF_Context. * Encoding MUST be done using definite lengths and the length of the MUST be the minimum possible length. This means that the integer 1 is encoded as "0x01" and not "0x1801". * Applications MUST NOT generate messages with the same label used twice as a key in a single map. Applications MUST NOT parse and process messages with the same label used twice as a key in a single map. Applications can enforce the parse and process requirement by using parsers that will fail the parse step or by using parsers that will pass all keys to the application, and the application can perform the check for duplicate keys. 10. IANA Considerations IANA is requested to updte ll COSE registeries except for "COSE Header Parmeters" and "COSE Key Common Parameters" from [RFC8152] to [[This document]]. 10.1. Changes to "COSE Key Types" registry. IANA is requested to create a new column in the "COSE Key Types" registry. The new column is to be labeled "Capabilities". The new column is to be populated according the entries in Table 22. +=======+===========+==========================+ | Value | Name | Capabilities | +=======+===========+==========================+ | 1 | OKP | [kty(1), crv] | +-------+-----------+--------------------------+ | 2 | EC2 | [kty(2), crv] | +-------+-----------+--------------------------+ | 3 | RSA | [kty(3)] | +-------+-----------+--------------------------+ | 4 | Symmetric | [kty(4)] | +-------+-----------+--------------------------+ | 5 | HSS-LMS | [kty(5), hash algorithm] | +-------+-----------+--------------------------+ Table 22: Key Type Capabilities Schaad Expires 28 March 2021 [Page 45] Internet-Draft COSE Algorithms September 2020 10.2. Changes to "COSE Algorithms" registry IANA is requested to create a new column in the "COSE Algorithms" registry. The new column is to be labeled "Capabilities". The new column is populated with "[kty]" for all current, non-provisional, registrations. It is expected that the documents which define those algorithms will be expanded to include this registration. If this is not done then the Designated Expert should be consulted before final registration for this document is done. IANA is requested to update the reference column in the "COSE Algorithms" registry to include [[This Document]] as a reference for all rows where it is not already present. IANA is requested to add a new row to the "COSE Algorithms" registry. +==========+===============+=============+============+=============+ |Name | Value |Description | Reference | Recommended | +==========+===============+=============+============+=============+ |IV | IV-GENERATION |For doing IV | [[THIS | No | |Generation| |generation | DOCUMENT]] | | | | |for symmetric| | | | | |algorithms. | | | +----------+---------------+-------------+------------+-------------+ Table 23 The capabilities column for this registration is to be empty. 10.3. Changes to the "COSE Key Type Parameters" registry IANA is requested to modify the description to "Public Key" for the line with "Key Type" of 2 and the "Name" of "x". See Table 20 which has been modified with this change. 10.4. Expert Review Instructions All of the IANA registries established by [RFC8152] are, at least in part, defined as expert review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude. Expert reviewers should take into consideration the following points: * Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already Schaad Expires 28 March 2021 [Page 46] Internet-Draft COSE Algorithms September 2020 registered, and that the point is likely to be used in deployments. The zones tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing. * Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. * Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. * When algorithms are registered, vanity registrations should be discouraged. One way to do this is to require registrations to provide additional documentation on security analysis of the algorithm. Another thing that should be considered is requesting an opinion on the algorithm from the Crypto Forum Research Group (CFRG). Algorithms that do not meet the security requirements of the community and the messages structures should not be registered. 11. Security Considerations There are a number of security considerations that need to be taken into account by implementers of this specification. The security considerations that are specific to an individual algorithm are placed next to the description of the algorithm. While some considerations have been highlighted here, additional considerations may be found in the documents listed in the references. Implementations need to protect the private key material for any individuals. There are some cases in this document that need to be highlighted on this issue. Schaad Expires 28 March 2021 [Page 47] Internet-Draft COSE Algorithms September 2020 * Using the same key for two different algorithms can leak information about the key. It is therefore recommended that keys be restricted to a single algorithm. * Use of 'direct' as a recipient algorithm combined with a second recipient algorithm exposes the direct key to the second recipient. * Several of the algorithms in this document have limits on the number of times that a key can be used without leaking information about the key. The use of ECDH and direct plus KDF (with no key wrap) will not directly lead to the private key being leaked; the one way function of the KDF will prevent that. There is, however, a different issue that needs to be addressed. Having two recipients requires that the CEK be shared between two recipients. The second recipient therefore has a CEK that was derived from material that can be used for the weak proof of origin. The second recipient could create a message using the same CEK and send it to the first recipient; the first recipient would, for either static-static ECDH or direct plus KDF, make an assumption that the CEK could be used for proof of origin even though it is from the wrong entity. If the key wrap step is added, then no proof of origin is implied and this is not an issue. Although it has been mentioned before, the use of a single key for multiple algorithms has been demonstrated in some cases to leak information about a key, provide the opportunity for attackers to forge integrity tags, or gain information about encrypted content. Binding a key to a single algorithm prevents these problems. Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure. In addition to checking that algorithms are correct, the key form needs to be checked as well. Do not use an 'EC2' key where an 'OKP' key is expected. Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made. Is the data or action something that the entity associated with the key has a right to see or a right to request? A number of factors are associated with this trust decision. Some of the ones that are highlighted here are: * What are the permissions associated with the key owner? * Is the cryptographic algorithm acceptable in the current context? Schaad Expires 28 March 2021 [Page 48] Internet-Draft COSE Algorithms September 2020 * Have the restrictions associated with the key, such as algorithm or freshness, been checked and are they correct? * Is the request something that is reasonable, given the current state of the application? * Have any security considerations that are part of the message been enforced (as specified by the application or 'crit' parameter)? There are a large number of algorithms presented in this document that use nonce values. For all of the nonces defined in this document, there is some type of restriction on the nonce being a unique value either for a key or for some other conditions. In all of these cases, there is no known requirement on the nonce being both unique and unpredictable; under these circumstances, it's reasonable to use a counter for creation of the nonce. In cases where one wants the pattern of the nonce to be unpredictable as well as unique, one can use a key created for that purpose and encrypt the counter to produce the nonce value. One area that has been getting exposure is traffic analysis of encrypted messages based on the length of the message. This specification does not provide for a uniform method of providing padding as part of the message structure. An observer can distinguish between two different messages (for example, 'YES' and 'NO') based on the length for all of the content encryption algorithms that are defined in this document. This means that it is up to the applications to document how content padding is to be done in order to prevent or discourage such analysis. (For example, the text strings could be defined as 'YES' and 'NO '.) The analsys done in [I-D.ietf-quic-tls] is based on the number of records/packets that are sent. This should map well to the number of messages sent when use COSE so that analysis should hold here as well. It needs to be noted that the limits are based on the number of messages, but QUIC and DTLS are always pair-wise based endpoints, [I-D.ietf-core-oscore-groupcomm] use COSE in a group communication. Under these circumstances it may be that no one single entity will see all of the messages that are encrypted an therefore no single entity can trigger the rekey operation. 12. References 12.1. Normative References [I-D.ietf-cose-rfc8152bis-struct] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", Work in Progress, Internet-Draft, Schaad Expires 28 March 2021 [Page 49] Internet-Draft COSE Algorithms September 2020 draft-ietf-cose-rfc8152bis-struct-13, 4 September 2020, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002, . [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, . [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . Schaad Expires 28 March 2021 [Page 50] Internet-Draft COSE Algorithms September 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [AES-GCM] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", DOI 10.6028/NIST.SP.800-38D, NIST Special Publication 800-38D, November 2007, . [DSS] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, FIPS PUB 186-4, July 2013, . [MAC] Menees, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", 1996. [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", May 2009, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, . 12.2. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . Schaad Expires 28 March 2021 [Page 51] Internet-Draft COSE Algorithms September 2020 [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, DOI 10.17487/RFC4231, December 2005, . [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, . [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, . [STD90] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . Schaad Expires 28 March 2021 [Page 52] Internet-Draft COSE Algorithms September 2020 [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages", RFC 8230, DOI 10.17487/RFC8230, September 2017, . [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, Internet-Draft, draft-ietf-core-oscore- groupcomm-09, 23 June 2020, . [I-D.ietf-cose-hash-sig] Housley, R., "Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)", Work in Progress, Internet-Draft, draft-ietf-cose-hash- sig-09, 11 December 2019, . [SP800-38d] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D , November 2007, . [SP800-56A] Barker, E., Chen, L., Roginsky, A., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", DOI 10.6028/NIST.SP.800-56Ar2, NIST Special Publication 800-56A, Revision 2, May 2013, . [GitHub-Examples] "GitHub Examples of COSE", . [I-D.mattsson-cfrg-det-sigs-with-noise] Mattsson, J., Thormarker, E., and S. Ruohomaa, "Deterministic ECDSA and EdDSA Signatures with Additional Randomness", Work in Progress, Internet-Draft, draft- mattsson-cfrg-det-sigs-with-noise-02, 11 March 2020, . Schaad Expires 28 March 2021 [Page 53] Internet-Draft COSE Algorithms September 2020 [HKDF] Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", 2010, . [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS", February 2020, . [I-D.ietf-quic-tls] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-tls-30, 9 September 2020, . Acknowledgments This document is a product of the COSE working group of the IETF. The following individuals are to blame for getting me started on this project in the first place: Richard Barnes, Matt Miller, and Martin Thomson. The initial version of the specification was based to some degree on the outputs of the JOSE and S/MIME working groups. The following individuals provided input into the final form of the document: Carsten Bormann, John Bradley, Brain Campbell, Michael B. Jones, Ilari Liusvaara, Francesca Palombini, Ludwig Seitz, and Göran Selander. Author's Address Jim Schaad August Cellars Email: ietf@augustcellars.com Schaad Expires 28 March 2021 [Page 54] ./draft-ietf-detnet-ip-07.txt0000644000764400076440000016110113677660032015262 0ustar iustyiusty DetNet B. Varga, Ed. Internet-Draft J. Farkas Intended status: Standards Track Ericsson Expires: January 4, 2021 L. Berger D. Fedyk LabN Consulting, L.L.C. S. Bryant Futurewei Technologies July 3, 2020 DetNet Data Plane: IP draft-ietf-detnet-ip-07 Abstract This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet Architecture and Data Plane Framework. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of Varga, et al. Expires January 4, 2021 [Page 1] Internet-Draft DetNet IP July 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. DetNet IP Data Plane Overview . . . . . . . . . . . . . . . . 4 4. DetNet IP Data Plane Considerations . . . . . . . . . . . . . 7 4.1. End System Specific Considerations . . . . . . . . . . . 8 4.2. DetNet Domain-Specific Considerations . . . . . . . . . . 8 4.3. Forwarding Sub-Layer Considerations . . . . . . . . . . . 11 4.3.1. Class of Service . . . . . . . . . . . . . . . . . . 11 4.3.2. Quality of Service . . . . . . . . . . . . . . . . . 11 4.3.3. Path Selection . . . . . . . . . . . . . . . . . . . 12 4.4. DetNet Flow Aggregation . . . . . . . . . . . . . . . . . 12 4.5. Bidirectional Traffic . . . . . . . . . . . . . . . . . . 13 5. DetNet IP Data Plane Procedures . . . . . . . . . . . . . . . 13 5.1. DetNet IP Flow Identification Procedures . . . . . . . . 14 5.1.1. IP Header Information . . . . . . . . . . . . . . . . 14 5.1.2. Other Protocol Header Information . . . . . . . . . . 15 5.2. Forwarding Procedures . . . . . . . . . . . . . . . . . . 17 5.3. DetNet IP Traffic Treatment Procedures . . . . . . . . . 17 6. Management and Control Information Summary . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative references . . . . . . . . . . . . . . . . . . 20 11.2. Informative references . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides these flows with extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in the DetNet Architecture [RFC8655]. Varga, et al. Expires January 4, 2021 [Page 2] Internet-Draft DetNet IP July 2020 This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead the existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery. Common data plane procedures and control information for all DetNet data planes can be found in [I-D.ietf-detnet-data-plane-framework]. The DetNet Architecture models the DetNet related data plane functions as two sub-layers: a service sub-layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service protection (e.g., by packet replication and packet elimination functions) and reordering. The forwarding sub-layer is used to provide congestion protection (low loss, assured latency, and limited out-of-order delivery). The service sub-layer generally requires additional header fields to provide its service; for example see [I-D.ietf-detnet-mpls]. Since no DetNet-specific fields are added to support DetNet IP flows, only the forwarding sub-layer functions are supported using the DetNet IP defined by this document. Service protection can be provided on a per sub-net basis using technologies such as MPLS [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified in the IEEE 802.1 TSN (Time-Sensitive Networking) task group (referred to in this document simply as IEEE802.1 TSN). This document provides an overview of the DetNet IP data plane in Section 3, and considerations that apply to providing DetNet services via the DetNet IP data plane in Section 4. Section 5 provides the procedures for hosts and routers that support IP-based DetNet services. Section 6 summarizes the set of information that is needed to identify an individual DetNet flow. 2. Terminology 2.1. Terms Used In This Document This document uses the terminology and concepts established in the DetNet architecture [RFC8655], and the reader is assumed to be familiar with that document and its terminology. 2.2. Abbreviations The following abbreviations used in this document: CoS Class of Service DetNet Deterministic Networking DN DetNet Varga, et al. Expires January 4, 2021 [Page 3] Internet-Draft DetNet IP July 2020 DiffServ Differentiated Services DSCP Differentiated Services Code Point L2 Layer-2 L3 Layer-3 LSP Label-switched path MPLS Multiprotocol Label Switching PREOF Packet Replication, Elimination and Ordering Function QoS Quality of Service TSN Time-Sensitive Networking, TSN is a Task Group of the IEEE 802.1 Working Group. 2.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. DetNet IP Data Plane Overview This document describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service using an IP data plane. From a data plane perspective, an end-to-end IP model is followed. As mentioned above, existing IP and higher layer protocol header information is used to support flow identification and DetNet service delivery. Common data plane procedures and control information for all DetNet data planes can be found in [I-D.ietf-detnet-data-plane-framework]. The DetNet IP data plane primarily uses 6-tuple based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. The 6-tuple referred to in this document is the same as that defined in [RFC3290]. Specifically 6-tuple is destination address, source address, IP protocol, source port, destination port, and differentiated services (DiffServ) code point (DSCP). General background on the use of IP headers, and 5-tuples, to identify flows and support Quality of Service (QoS) can be found in [RFC3670]. [RFC7657] also provides useful background on the delivery of DiffServ and "tuple" based flow identification. Note Varga, et al. Expires January 4, 2021 [Page 4] Internet-Draft DetNet IP July 2020 that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP component. For some of the protocols 5-tuples and 6-tuples cannot be used because the port information is not available (e.g., ICMP, IPSec ESP). This is also the case for flow aggregates. In such cases, using fewer fields is appropriate, e.g., a 3-tuple (2 IP addresses, IP protocol) or even a 2-tuple (all IP traffic between two IP addresses). The DetNet IP data plane also allows for optional matching on the IPv6 flow label field, as defined in [RFC8200]. Non-DetNet and DetNet IP packets have the same protocol header format on the wire. Generally the fields used in flow identification are forwarded unmodified. However, standard modification of the DSCP field [RFC2474] is not precluded. DetNet flow aggregation may be enabled via the use of wildcards, masks, lists, prefixes and ranges. IP tunnels may also be used to support flow aggregation. In these cases, it is expected that DetNet-aware intermediate nodes will provide DetNet service on the aggregate through resource allocation and congestion control mechanisms. The specific procedures that are required to be implemented by a DetNet node supporting this document can be found in Section 5. The DetNet controller plane, as defined in [RFC8655], is responsible for providing each node with the information needed to identify and handle each DetNet flow. Varga, et al. Expires January 4, 2021 [Page 5] Internet-Draft DetNet IP July 2020 DetNet IP Relay Relay DetNet IP End System Node Node End System +----------+ +----------+ | Appl. |<------------ End to End Service ----------->| Appl. | +----------+ ............ ........... +----------+ | Service |<-: Service :-- DetNet flow --: Service :->| Service | +----------+ +----------+ +----------+ +----------+ |Forwarding| |Forwarding| |Forwarding| |Forwarding| +--------.-+ +-.------.-+ +-.---.----+ +-------.--+ : Link : \ ,-----. / \ ,-----. / +......+ +----[ Sub ]----+ +-[ Sub ]-+ [Network] [Network] `-----' `-----' |<--------------------- DetNet IP --------------------->| Figure 1: A Simple DetNet (DN) Enabled IP Network Figure 1 illustrates a DetNet enabled IP network. The DetNet enabled end systems originate IP encapsulated traffic that is identified within the DetNet domain as DetNet flows based on IP header information. Relay nodes understand the forwarding requirements of the DetNet flow and ensure that node, interface and sub-network resources are allocated to ensure DetNet service requirements. The dotted line around the Service component of the Relay Nodes indicates that the transit routers are DetNet service aware but do not perform any DetNet service sub-layer function, e.g., PREOF (Packet Replication, Elimination and Ordering Function). Note: The sub-network can represent a TSN, MPLS network or other network technology that can carry DetNet IP traffic. Varga, et al. Expires January 4, 2021 [Page 6] Internet-Draft DetNet IP July 2020 IP Edge Edge IP End System Node Node End System +----------+ +.........+ +.........+ +----------+ | Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. | +----------+ +.........+ +.........+ +----------+ | IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP | +----------+ +---+ +---+ +---+ +---+ +----------+ |Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding| +--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+ : Link : \ ,-----. / / ,-----. \ +.......+ +----[ Sub ]----+ +--[ Sub ]--+ [Network] [Network] `-----' `-----' |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->| Figure 2: Non-DetNet-aware IP end systems with DetNet IP Domain Figure 2 illustrates a variant of Figure 1 where the end systems are not DetNet aware. In this case, edge nodes sit at the boundary of the DetNet domain and provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows. The existing header information or an approach such as described in Section 4.4 can be used to support DetNet flow identification. Note that Figure 1 and Figure 2 can be collapsed, so IP DetNet End Systems can communicate over a DetNet IP network with IP End Systems. As non-DetNet and DetNet IP packets have the same protocol header format on the wire, from a data plane perspective, the only difference is that there is flow-associated DetNet information on each DetNet node that defines the flow related characteristics and required forwarding behavior. As shown above, edge nodes provide a Service Proxy function that "associates" one or more IP flows with the appropriate DetNet flow-specific information and ensures that the flow receives the proper traffic treatment within the domain. Note: The operation of IEEE802.1 TSN end systems over DetNet enabled IP networks is not described in this document. TSN over MPLS is described in [I-D.ietf-detnet-tsn-vpn-over-mpls]. 4. DetNet IP Data Plane Considerations This section provides considerations related to providing DetNet service to flows which are identified based on their header information. Varga, et al. Expires January 4, 2021 [Page 7] Internet-Draft DetNet IP July 2020 4.1. End System Specific Considerations Data-flows requiring DetNet service are generated and terminated on end systems. This document deals only with IP end systems. The protocols used by an IP end system are specific to an application, and end systems peer with other end systems. DetNet's use of 6-tuple IP flow identification means that DetNet must be aware of not only the format of the IP header, but also of the next protocol value carried within an IP packet (see Section 5.1.1.3). For DetNet unaware IP end systems service-level proxy functions are needed inside the DetNet domain. When IP end systems are DetNet-aware, no application-level or service-level proxy functions are needed inside the DetNet domain. End systems need to ensure that DetNet service requirements are met when processing packets associated to a DetNet flow. When sending packets, this means that packets are appropriately shaped on transmission and receive appropriate traffic treatment on the connected sub-network; see Section 4.3.2 and Section 4.2 for more details. When receiving packets, this means that there are appropriate local node resources, e.g., buffers, to receive and process the packets of that DetNet flow. An important additional consideration for DetNet-aware end systems is avoiding IP fragmentation. Full 6-tuple flow identification is not possible on IP fragments as fragments don't include the transport headers or their port information. As such, it is important that applications and/or end-systems use an IP packet size that will avoid fragmentation within the network when sending DetNet flows. The maximum size can be learned via path MTU discovery, [RFC1192] and [RFC8201], or via the controller plane. Note that path MTU discovery relies on ICMP, which may not follow the same path as an individual DetNet flow. In order to maximize reuse of existing mechanisms, DetNet-aware applications and end systems SHOULD NOT mix DetNet and non-DetNet traffic within a single 5-tuple. 4.2. DetNet Domain-Specific Considerations As a general rule, DetNet IP domains need to be able to forward any DetNet flow identified by the IP 6-tuple. Doing otherwise would limit the number of 6-tuple flow ID combinations that could be used by the end systems. From a practical standpoint this means that all nodes along the end-to-end path of DetNet flows need to agree on what fields are used for flow identification. Possible consequences of not having such an agreement include some flows interfering with Varga, et al. Expires January 4, 2021 [Page 8] Internet-Draft DetNet IP July 2020 other flows, and the traffic treatment expected for a service not being provided. From a connection type perspective two scenarios are identified: 1. DN attached: the end system is directly connected to an edge node, or the end system is behind a sub-network (See ES1 and ES2 in figure below) 2. DN integrated: the end system is part of the DetNet domain. (See ES3 in figure below) L3 (IP) end systems may use any of these connection types. A DetNet domain allows communication between any end systems using the same encapsulation format, independent of their connection type and DetNet capability. DN attached end systems have no knowledge about the DetNet domain and its encapsulation format. See Figure 3 for L3 end system connection examples. ____+----+ +----+ _____ / | ES3| | ES1|____ / \__/ +----+___ +----+ \ / \ + | ____ \ _/ +----+ __/ \ +__ DetNet IP domain / | ES2|____/ L2/L3 |___/ \ __ __/ +----+ \_______/ \_______/ \___/ Figure 3: Connection types of L3 end systems Within a DetNet domain, the DetNet-enabled IP Routers are interconnected by links and sub-networks to support end-to-end delivery of DetNet flows. From a DetNet architecture perspective, these routers are DetNet relays, as they must be DetNet service aware. Such routers identify DetNet flows based on the IP 6-tuple, and ensure that the DetNet service required traffic treatment is provided both on the node and on any attached sub-network. This solution provides DetNet functions end-to-end, but does so on a per link and sub-network basis. Congestion protection and latency control and the resource allocation (queuing, policing, shaping) are supported using the underlying link/sub-network specific mechanisms. However, service protection (packet replication and packet elimination functions) is not provided at the DetNet layer end-to- Varga, et al. Expires January 4, 2021 [Page 9] Internet-Draft DetNet IP July 2020 end. Instead service protection can be provided on a per underlying L2 link and sub-network basis. The DetNet Service Flow is mapped to the link/sub-network specific resources using an underlying system-specific means. This implies each DetNet-aware node on path looks into the forwarded DetNet Service Flow packet and utilize e.g., a 6-tuple to find out the required mapping within a node. As noted earlier, service protection must be implemented within each link/sub-network independently, using the domain specific mechanisms. This is due to the lack of unified end-to-end sequencing information that could be used by the intermediate nodes. Therefore, service protection (if enabled) cannot be provided end-to-end, only within sub-networks. This is shown for a three sub-network scenario in Figure 4, where each sub-network can provide service protection between its borders. "R" and "E" denote replication and elimination points within the sub-network. <-------------------- DenNet IP ------------------------> ______ ____ / \__ ____ / \__/ \___ ______ +----+ __/ +====+ +==+ \ +----+ |src |__/ SubN1 ) | | \ SubN3 \____| dst| +----+ \_______/ \ Sub-Network2 | \______/ +----+ \_ _/ \ __ __/ \_______/ \___/ +---+ +---------E--------+ +-----+ +----+ | | | | | | | +----+ |src |----R E--------R +---+ E------R E------+ dst| +----+ | | | | | | | +----+ +---+ +-----R------------+ +-----+ Figure 4: Replication and elimination in sub-networks for DetNet IP networks If end-to-end service protection is desired, it can be implemented, for example, by the DetNet end systems using Layer-4 (L4) transport protocols or application protocols. However, these protocols are out of scope of this document. Varga, et al. Expires January 4, 2021 [Page 10] Internet-Draft DetNet IP July 2020 Note that not mixing DetNet and non-DetNet traffic within a single 5-tuple, as described above, enables simpler 5-tuple filters to be used (or re-used) at the edges of a DetNet network to prevent non- congestion-responsive DetNet traffic from escaping the DetNet domain. 4.3. Forwarding Sub-Layer Considerations 4.3.1. Class of Service Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is provided using the standard differentiated services (DSCP) field [RFC2474] and related mechanisms. One additional consideration for DetNet nodes which support CoS services is that they must ensure that the CoS service classes do not impact the congestion protection and latency control mechanisms used to provide DetNet QoS. This requirement is similar to the requirement for MPLS LSRs that CoS LSPs cannot impact the resources allocated to TE LSPs [RFC3473]. 4.3.2. Quality of Service Quality of Service (QoS) for DetNet service flows carried in IP must be provided locally by the DetNet-aware hosts and routers supporting DetNet flows. Such support leverages the underlying network layer such as 802.1 TSN. The node-internal traffic control mechanisms used to deliver QoS for IP encapsulated DetNet flows are outside the scope of this document. From an encapsulation perspective, the combination of the 6-tuple (the typical 5-tuple enhanced with the DSCP) and optionally the flow label uniquely identifies a DetNet IP flow. Packets that are identified as part of a DetNet IP flow but that have not been the subject of a completed reservation can disrupt the QoS offered to properly reserved DetNet flows by using resources allocated to the reserved flows. Therefore, the network nodes of a DetNet network MUST ensure that no DetNet allocated resources, e.g., queue or shaper, is used by such flows. There are multiple methods that may be used by an implementation to defend service delivery to reserved DetNet flows, including but not limited to: o Treating packets associated with an incomplete reservation as non- DetNet traffic. o Discarding packets associated with an incomplete reservation. o Re-marking packets associated with an incomplete reservation. Re- marking can be accomplished by changing the value of the DSCP Varga, et al. Expires January 4, 2021 [Page 11] Internet-Draft DetNet IP July 2020 field to a value that results in the packet no longer matching any other reserved DetNet IP flow. 4.3.3. Path Selection While path selection algorithms and mechanisms are out of scope of the DetNet data plane definition, it is important to highlight the implications of DetNet IP flow identification on path selection and next hops. As mentioned above, the DetNet IP data plane identifies flows using "6-tuple" header information as well as the optional (flow label) header field. DetNet generally allows for both flow- specific traffic treatment and flow-specific next-hops. In non-DetNet IP forwarding, it is generally assumed that the same series of next hops, i.e., the same path, will be used for a particular 5-tuple or, in some cases, e.g., [RFC5120], for a particular 6-tuple. Using different next hops for different 5-tuples does not take any special consideration for DetNet-aware applications. Care should be taken when using different next hops for the same 5-tuple. As discussed in [RFC7657], unexpected behavior can occur when a single 5-tuple application flow experiences reordering due to being split across multiple next hops. Understanding of the application and transport protocol impact of using different next hops for the same 5-tuple is required. Again, this impacts path selection for DetNet flows and this document only indirectly. 4.4. DetNet Flow Aggregation As described in [I-D.ietf-detnet-data-plane-framework], the ability to aggregate individual flows, and their associated resource control, into a larger aggregate is an important technique for improving scaling by reducing the state per hop. DetNet IP data plane aggregation can take place within a single node, when that node maintains state about both the aggregated and individual flows. It can also take place between nodes, where one node maintains state about only flow aggregates while the other node maintains state on all or a portion of the component flows. In either case, the management or control function that provisions the aggregate flows must ensure that adequate resources are allocated and configured to provide combined service requirements of the individual flows. As DetNet is concerned about latency and jitter, more than just bandwidth needs to be considered. From a single node perspective, the aggregation of IP flows impacts DetNet IP data plane flow identification and resource allocation. As discussed above, IP flow identification uses the IP "6-tuple" for Varga, et al. Expires January 4, 2021 [Page 12] Internet-Draft DetNet IP July 2020 flow identification. DetNet IP flows can be aggregated using any of the 6-tuple fields and optionally also by the flow label. The use of prefixes, wildcards, lists, and value ranges allows a DetNet node to identify aggregate DetNet flows. From a resource allocation perspective, DetNet nodes ought to provide service to an aggregate rather than on a component flow basis. It is the responsibility of the DetNet controller plane to properly provision the use of these aggregation mechanisms. This includes ensuring that aggregated flows have compatible (e.g., the same or very similar) QoS and/or CoS characteristics, see Section 4.3.2. It also includes ensuring that per component-flow service requirements are satisfied by the aggregate, see Section 5.3. The DetNet controller plane MUST ensure that non-congestion- responsive DetNet traffic is not forwarded outside a DetNet domain. 4.5. Bidirectional Traffic While the DetNet IP data plane must support bidirectional DetNet flows, there are no special bidirectional features within the data plane. The special case of co-routed bidirectional DetNet flows are solely represented at the management and control plane levels, without specific support or knowledge within the DetNet data plane. Fate sharing and associated or co-routed bidirectional flows can be managed at the control level. Control and management mechanisms need to support bidirectional flows, but the specification of such mechanisms are out of scope of this document. An example control plane solution for MPLS can be found in [RFC7551]. 5. DetNet IP Data Plane Procedures This section provides DetNet IP data plane procedures. These procedures have been divided into the following areas: flow identification, forwarding and traffic treatment. Flow identification includes those procedures related to matching IP and higher layer protocol header information to DetNet flow (state) information and service requirements. Flow identification is also sometimes called Traffic classification; for example see [RFC5777]. Forwarding includes those procedures related to next hop selection and delivery. Traffic treatment includes those procedures related to providing an identified flow with the required DetNet service. DetNet IP data plane establishment and operational procedures also have requirements on the control and management systems for DetNet flows and these are referred to in this section. Specifically this Varga, et al. Expires January 4, 2021 [Page 13] Internet-Draft DetNet IP July 2020 section identifies a number of information elements that require support via the management and control interfaces supported by a DetNet node. The specific mechanism used for such support is out of the scope of this document. A summary of the requirements for management and control related information is included. Conformance language is not used in the summary since it applies to future mechanisms such as those that may be provided in YANG models [I-D.ietf-detnet-yang]. 5.1. DetNet IP Flow Identification Procedures IP and higher layer protocol header information is used to identify DetNet flows. All DetNet implementations that support this document MUST identify individual DetNet flows based on the set of information identified in this section. Note that additional flow identification requirements, e.g., to support other higher layer protocols, may be defined in the future. The configuration and control information used to identify an individual DetNet flow MUST be ordered by an implementation. Implementations MUST support a fixed order when identifying flows, and MUST identify a DetNet flow by the first set of matching flow information. Implementations of this document MUST support DetNet flow identification when the implementation is acting as a DetNet end systems, a relay node, or as an edge node. 5.1.1. IP Header Information Implementations of this document MUST support DetNet flow identification based on IP header information. The IPv4 header is defined in [RFC0791] and the IPv6 is defined in [RFC8200]. 5.1.1.1. Source Address Field Implementations of this document MUST support DetNet flow identification based on the Source Address field of an IP packet. Implementations SHOULD support longest prefix matching for this field (see [RFC1812] and [RFC7608].) Note that a prefix length of zero (0) effectively means that the field is ignored. 5.1.1.2. Destination Address Field Implementations of this document MUST support DetNet flow identification based on the Destination Address field of an IP packet. Implementations SHOULD support longest prefix matching for Varga, et al. Expires January 4, 2021 [Page 14] Internet-Draft DetNet IP July 2020 this field (see [RFC1812] and [RFC7608].) Note that a prefix length of zero (0) effectively means that the field is ignored. Note: Any IP address value is allowed, including an IP multicast destination address. 5.1.1.3. IPv4 Protocol and IPv6 Next Header Fields Implementations of this document MUST support DetNet flow identification based on the IPv4 Protocol field when processing IPv4 packets, and the IPv6 Next Header Field when processing IPv6 packets. This includes the next protocol values defined in Section 5.1.2 and any other value, including zero. Implementations SHOULD allow for these fields to be ignored for a specific DetNet flow. 5.1.1.4. IPv4 Type of Service and IPv6 Traffic Class Fields These fields are used to support Differentiated Services [RFC2474] [RFC2475]. Implementations of this document MUST support DetNet flow identification based on the DSCP field in the IPv4 Type of Service field when processing IPv4 packets, and the DSCP field in the IPv6 Traffic Class Field when processing IPv6 packets. Implementations MUST support list-based matching of DSCP values, where the list is composed of possible field values that are to be considered when identifying a specific DetNet flow. Implementations SHOULD allow for this field to be ignored for a specific DetNet flow. 5.1.1.5. IPv6 Flow Label Field Implementations of this document SHOULD support identification of DetNet flows based on the IPv6 Flow Label field. Implementations that support matching based on this field MUST allow for it to be ignored for a specific DetNet flow. When this field is used to identify a specific DetNet flow, implementations MAY exclude the IPv6 Next Header field and next header information as part of DetNet flow identification. 5.1.2. Other Protocol Header Information Implementations of this document MUST support DetNet flow identification based on header information identified in this section. Support for TCP, UDP, ICMP and IPsec flows is defined. Future documents are expected to define support for other protocols. Varga, et al. Expires January 4, 2021 [Page 15] Internet-Draft DetNet IP July 2020 5.1.2.1. TCP and UDP DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is achieved based on the Source and Destination Port fields carried in each protocol's header. These fields share a common format and common DetNet flow identification procedures. The rules defined in this section only apply when the IPv4 Protocol or IPv6 Next Header Field contains the IANA defined value for UDP or TCP. 5.1.2.1.1. Source Port Field Implementations of this document MUST support DetNet flow identification based on the Source Port field of a TCP or UDP packet. Implementations MUST support flow identification based on a particular value carried in the field, i.e., an exact value. Implementations SHOULD support range-based port matching. Implementation MUST also allow for the field to be ignored for a specific DetNet flow. 5.1.2.1.2. Destination Port Field Implementations of this document MUST support DetNet flow identification based on the Destination Port field of a TCP or UDP packet. Implementations MUST support flow identification based on a particular value carried in the field, i.e., an exact value. Implementations SHOULD support range-based port matching. Implementation MUST also allow for the field to be ignored for a specific DetNet flow. 5.1.2.2. ICMP DetNet flow identification for ICMP [RFC0792] is achieved based on the protocol number in the IP header. Note that ICMP type is not included in the flow definition. 5.1.2.3. IPsec AH and ESP IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] share a common format for the Security Parameters Index (SPI) field. Implementations MUST support flow identification based on a particular value carried in the field, i.e., an exact value. Implementation SHOULD also allow for the field to be ignored for a specific DetNet flow. Varga, et al. Expires January 4, 2021 [Page 16] Internet-Draft DetNet IP July 2020 The rules defined in this section only apply when the IPv4 Protocol or IPv6 Next Header Field contains the IANA defined value for AH or ESP. 5.2. Forwarding Procedures General requirements for IP nodes are defined in [RFC1122], [RFC1812] and [RFC8504], and are not modified by this document. The typical next-hop selection process is impacted by DetNet. Specifically, implementations of this document SHALL use management and control information to select the one or more outgoing interfaces and next hops to be used for a packet associated with a DetNet flow. Specific management and control information will be defined in future documents, e.g., [I-D.ietf-detnet-yang]. The use of multiple paths or links, e.g., ECMP, to support a single DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows within a DetNet domain. The above implies that management and control functions will be defined to support this requirement, e.g., see [I-D.ietf-detnet-yang]. 5.3. DetNet IP Traffic Treatment Procedures Implementations of this document must ensure that a DetNet flow receives the traffic treatment that is provisioned for it via configuration or the controller plane, e.g., via [I-D.ietf-detnet-yang]. General information on DetNet service can be found in [I-D.ietf-detnet-flow-information-model]. Typical mechanisms used to provide different treatment to different flows includes the allocation of system resources (such as queues and buffers) and provisioning of related parameters (such as shaping, and policing). Support can also be provided via an underlying network technology such as MPLS [I-D.ietf-detnet-ip-over-mpls] or IEEE802.1 TSN [I-D.ietf-detnet-ip-over-tsn]. Other mechanisms than the ones used in the TSN case are outside the scope of this document. 6. Management and Control Information Summary The following summarizes the set of information that is needed to identify individual and aggregated DetNet flows: o IPv4 and IPv6 source address field. o IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored. Varga, et al. Expires January 4, 2021 [Page 17] Internet-Draft DetNet IP July 2020 o IPv4 and IPv6 destination address field. o IPv4 and IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored. o IPv4 protocol field. A limited set of values is allowed, and the ability to ignore this field is desirable. o IPv6 next header field. A limited set of values is allowed, and the ability to ignore this field is desirable. o For the IPv4 Type of Service and IPv6 Traffic Class Fields: * Whether or not the DSCP field is used in flow identification. Use of the DSCP field for flow identification is optional. * If the DSCP field is used to identify a flow, then the flow identification information (for that flow) includes a list of DSCPs used by that flow. o IPv6 flow label field. This field can be optionally used for matching. When used, this field can be used instead of matching against the Next Header field. o TCP and UDP Source Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used. o TCP and UDP Destination Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used. o IPsec Header SPI field. Exact matching is required. Support for wildcard matching is recommended. o For end systems, an optional maximum IP packet size that should be used for that outgoing DetNet IP flow. This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller or management plane. An implementation MUST support ordering of the set of information information used to identify an individual DetNet flow. This can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific Varga, et al. Expires January 4, 2021 [Page 18] Internet-Draft DetNet IP July 2020 resources needed to provided the traffic treatment needed to meet each flow's service requirements. This applies for aggregated and individual flows. 7. Security Considerations Detailed security considerations for DetNet are cataloged in [I-D.ietf-detnet-security], and more general security considerations are described in [RFC8655]. This section considers exclusively security considerations which are specific to the DetNet IP data plane. Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. Achieving such loss rates and bounded latency may not be possible in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 that can arbitrarily drop or delay any or all traffic. In order to present meaningful security considerations, we consider a somewhat weaker attacker who does not control the physical links of the DetNet domain, but may have the ability to control a network node within the boundary of the DetNet domain. The primary consideration for the DetNet data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Since no DetNet-specific fields are available in the DetNet IP data plane, the integrity and confidentiality of application flows can be protected through whatever means are provided by the underlying technology. For example, encryption may be used, such as that provided by IPSec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for IP over Ethernet (Layer-2) flows. From a data plane perspective this document does not add or modify any header information. At the management and control level DetNet flows are identified on a per-flow basis, which may provide controller plane attackers with additional information about the data flows (when compared to controller planes that do not include per-flow identification). This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet service, provisions can be made against DOS attacks and delay attacks. To protect against DOS attacks, excess traffic due to malicious or Varga, et al. Expires January 4, 2021 [Page 19] Internet-Draft DetNet IP July 2020 malfunctioning devices can be prevented or mitigated, for example through the use of existing mechanism such as policing and shaping applied at the input of a DetNet domain or within an edge IEEE802.1 TSN domain. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of Man-In-The-Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. 8. IANA Considerations This document does not require an action from IANA. 9. Acknowledgements The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their various contributions to this work. David Black served as technical advisor to the DetNet working group during the development of this document and provided many valuable comments. IESG comments were provided by Murray Kucherawy, Roman Danyliw, Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Erik Vyncke. 10. Contributors RFC7322 limits the number of authors listed on the front page of a draft to a maximum of 5. The editor wishes to thank and acknowledge the follow authors for contributing text to this draft. Jouni Korhonen Email: jouni.nospam@gmail.com Andrew G. Malis Malis Consulting Email: agmalis@gmail.com 11. References 11.1. Normative references [I-D.ietf-detnet-data-plane-framework] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane Framework", draft-ietf-detnet- data-plane-framework-06 (work in progress), May 2020. Varga, et al. Expires January 4, 2021 [Page 20] Internet-Draft DetNet IP July 2020 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, . Varga, et al. Expires January 4, 2021 [Page 21] Internet-Draft DetNet IP July 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 11.2. Informative references [I-D.ietf-detnet-dp-sol-mpls] Korhonen, J. and B. Varga, "DetNet MPLS Data Plane Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in progress), March 2019. [I-D.ietf-detnet-flow-information-model] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- flow-information-model-10 (work in progress), May 2020. [I-D.ietf-detnet-ip-over-mpls] Varga, B., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over MPLS", draft-ietf- detnet-ip-over-mpls-06 (work in progress), May 2020. [I-D.ietf-detnet-ip-over-tsn] Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)", draft-ietf-detnet-ip-over-tsn-03 (work in progress), June 2020. [I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf- detnet-mpls-07 (work in progress), June 2020. [I-D.ietf-detnet-security] Mizrahi, T. and E. Grossman, "Deterministic Networking (DetNet) Security Considerations", draft-ietf-detnet- security-10 (work in progress), May 2020. Varga, et al. Expires January 4, 2021 [Page 22] Internet-Draft DetNet IP July 2020 [I-D.ietf-detnet-tsn-vpn-over-mpls] Varga, B., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- mpls-03 (work in progress), June 2020. [I-D.ietf-detnet-yang] Geng, X., Chen, M., Ryoo, Y., Li, Z., Rahman, R., and D. Fedyk, "Deterministic Networking (DetNet) Configuration YANG Model", draft-ietf-detnet-yang-06 (work in progress), June 2020. [IEEE802.1AE-2018] IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC Security (MACsec)", 2018, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1192] Kahin, B., "Commercialization of the Internet summary report", RFC 1192, DOI 10.17487/RFC1192, November 1990, . [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, . [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, DOI 10.17487/RFC3290, May 2002, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, January 2004, . Varga, et al. Expires January 4, 2021 [Page 23] Internet-Draft DetNet IP July 2020 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, . [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . Authors' Addresses Balazs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com Varga, et al. Expires January 4, 2021 [Page 24] Internet-Draft DetNet IP July 2020 Janos Farkas Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: janos.farkas@ericsson.com Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Don Fedyk LabN Consulting, L.L.C. Email: dfedyk@labn.net Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Varga, et al. Expires January 4, 2021 [Page 25] ./queue2.xml0000644000764400076440000025560313761027561012322 0ustar iustyiusty
draft-ietf-rtcweb-data-channel-13.txt 2015-01-08 AUTH48*R http://www.rfc-editor.org/auth48/rfc8831 draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE R. Jesup, S. Loreto, M. Tuexen WebRTC Data Channels 36549 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-data-protocol-09.txt 2015-01-08 AUTH48*R http://www.rfc-editor.org/auth48/rfc8832 draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE R. Jesup, S. Loreto, M. Tuexen WebRTC Data Channel Establishment Protocol 28411 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-rtp-usage-26.txt 2015-07-01 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8834 draft-ietf-avtcore-multi-media-rtp-session IN-QUEUE draft-ietf-avtcore-rtp-multi-stream-optimisation IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-rtcweb-fec IN-QUEUE draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE C. Perkins, M. Westerlund, J. Ott Web Real-Time Communication (WebRTC): Media Transport and Use of RTP 123242 Real-Time Communication in WEB-browsers yes draft-ietf-bfcpbis-rfc4582bis-16.txt 2015-11-23 AUTH48*R http://www.rfc-editor.org/auth48/rfc8855 draft-ietf-bfcpbis-rfc4583bis IN-QUEUE G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel The Binary Floor Control Protocol (BFCP) 225320 Binary Floor Control Protocol Bis yes draft-ietf-avtcore-multi-media-rtp-session-13.txt 2015-12-28 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8860 draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE M. Westerlund, C. Perkins, J. Lennox Sending Multiple Types of Media in a Single RTP Session 38919 Audio/Video Transport Core Maintenance yes draft-ietf-clue-framework-25.txt 2016-01-14 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8845 draft-ietf-clue-datachannel IN-QUEUE draft-ietf-clue-data-model-schema IN-QUEUE draft-ietf-clue-protocol IN-QUEUE draft-ietf-clue-signaling IN-QUEUE M. Duckworth, Ed., A. Pepperell, S. Wenger Framework for Telepresence Multi-Streams 186803 ControLling mUltiple streams for tElepresence yes draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt 2016-03-09 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8861 draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE J. Lennox, M. Westerlund, Q. Wu, C. Perkins Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback 46256 Audio/Video Transport Core Maintenance yes draft-ietf-rtcweb-alpn-04.txt 2016-05-12 AUTH48*R http://www.rfc-editor.org/auth48/rfc8833 draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE M. Thomson Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) 15355 Real-Time Communication in WEB-browsers yes draft-ietf-mmusic-msid-17.txt 2016-07-12 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8830 draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE H. Alvestrand WebRTC MediaStream Identification in the Session Description Protocol 35897 Multiparty Multimedia Session Control yes draft-ietf-mmusic-mux-exclusive-12.txt 2016-08-09 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8858 draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE C. Holmberg Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP 25385 Multiparty Multimedia Session Control yes draft-ietf-clue-data-model-schema-17.txt 2016-08-15 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8846 draft-ietf-clue-datachannel IN-QUEUE draft-ietf-clue-framework IN-QUEUE draft-ietf-clue-protocol IN-QUEUE R. Presta, S. Pietro Romano An XML Schema for the CLUE data model 151635 ControLling mUltiple streams for tElepresence yes draft-ietf-tsvwg-rtcweb-qos-18.txt 2016-08-22 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8837 draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-transports IN-QUEUE P. Jones, S. Dhesikan, C. Jennings, D. Druta DSCP Packet Markings for WebRTC QoS 26177 Transport Area Working Group yes draft-ietf-avtext-rid-09.txt 2016-10-19 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8852 draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE A.B. Roach, S. Nandakumar, P. Thatcher RTP Stream Identifier Source Description (SDES) 19604 Audio/Video Transport Extensions yes draft-ietf-rtcweb-transports-17.txt 2016-10-27 AUTH48*R http://www.rfc-editor.org/auth48/rfc8835 draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-rmcat-cc-requirements IN-QUEUE draft-ietf-rtcweb-alpn IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-tsvwg-rtcweb-qos IN-QUEUE H. Alvestrand Transports for WebRTC 41832 Real-Time Communication in WEB-browsers yes draft-ietf-mmusic-sdp-mux-attributes-19.txt 2016-12-20 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8859 draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE S. Nandakumar A Framework for Session Description Protocol (SDP) Attributes When Multiplexing 234454 Multiparty Multimedia Session Control yes draft-ietf-bfcpbis-bfcp-websocket-15.txt 2017-02-13 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8857 draft-ietf-bfcpbis-rfc4582bis IN-QUEUE draft-ietf-bfcpbis-rfc4583bis IN-QUEUE V. Pascual, A. Roman, S. Cazeaux, G. Salgueiro, R. Ravindranath The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) 30505 Binary Floor Control Protocol Bis yes draft-ietf-clue-rtp-mapping-14.txt 2017-02-27 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8849 draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-clue-data-model-schema IN-QUEUE draft-ietf-clue-framework IN-QUEUE R. Even, J. Lennox Mapping RTP streams to CLUE Media Captures 32763 ControLling mUltiple streams for tElepresence yes draft-ietf-mmusic-sctp-sdp-26.txt 2017-03-20 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8841 draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE C. Holmberg, R. Shpount, S. Loreto, G. Camarillo Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. 54708 Multiparty Multimedia Session Control yes draft-ietf-avtext-lrr-07.txt 2017-07-07 MISSREF*R(1G) draft-ietf-avtext-framemarking NOT-RECEIVED J. Lennox, D. Hong, J. Uberti, S. Holmer, M. Flodman The Layer Refresh Request (LRR) RTCP Feedback Message 31966 Audio/Video Transport Extensions yes draft-ietf-anima-grasp-15.txt 2017-07-19 REF*R draft-ietf-anima-autonomic-control-plane IN-QUEUE C. Bormann, B. Carpenter, Ed., B. Liu, Ed. A Generic Autonomic Signaling Protocol (GRASP) 181149 Autonomic Networking Integrated Model and Approach yes draft-ietf-ospf-encapsulation-cap-09.txt 2017-10-24 MISSREF*R(1G) draft-ietf-idr-tunnel-encaps NOT-RECEIVED X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil The Tunnel Encapsulations OSPF Router Information 22330 Open Shortest Path First IGP yes draft-ietf-mmusic-dtls-sdp-32.txt 2017-11-02 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8842 draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE C. Holmberg, R. Shpount Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) 58022 Multiparty Multimedia Session Control yes draft-ietf-rtcweb-overview-19.txt 2017-11-12 AUTH48*R http://www.rfc-editor.org/auth48/rfc8825 draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-transports IN-QUEUE H. Alvestrand Overview: Real Time Protocols for Browser-based Applications 53526 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-jsep-26.txt 2018-03-01 AUTH48*R http://www.rfc-editor.org/auth48/rfc8829 draft-ietf-avtext-rid IN-QUEUE draft-ietf-ice-trickle IN-QUEUE draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-mmusic-msid IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-rid IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-sdp-simulcast IN-QUEUE draft-ietf-rtcweb-fec IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE J. Uberti, C. Jennings, E. Rescorla, Ed. JavaScript Session Establishment Protocol 256248 Real-Time Communication in WEB-browsers yes draft-ietf-bess-dci-evpn-overlay-10.txt 2018-03-05 MISSREF*R(1G) draft-ietf-idr-tunnel-encaps NOT-RECEIVED J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake Interconnect Solution for EVPN Overlay networks 67427 BGP Enabled Services yes draft-ietf-trill-ecn-support-07.txt 2018-03-12 MISSREF*R(1G) draft-ietf-tsvwg-ecn-encap-guidelines NOT-RECEIVED draft-ietf-tsvwg-ecn-l4s-id NOT-RECEIVED D. Eastlake 3rd, B. Briscoe TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support 33826 Transparent Interconnection of Lots of Links yes draft-ietf-netmod-syslog-model-26.txt 2018-03-16 MISSREF*R(1G) draft-ietf-netconf-keystore NOT-RECEIVED draft-ietf-netconf-tls-client-server NOT-RECEIVED C. Wildes, Ed., K. Koushik, Ed. A YANG Data Model for Syslog Configuration 65515 Network Modeling yes draft-ietf-mmusic-rid-15.txt 2018-05-16 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8851 draft-ietf-avtext-rid IN-QUEUE A.B. Roach, Ed. RTP Payload Format Restrictions 61967 Multiparty Multimedia Session Control yes draft-ietf-pim-yang-17.txt 2018-05-16 MISSREF*R(2G) draft-ietf-bfd-yang IN-QUEUE X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu A YANG Data Model for Protocol Independent Multicast (PIM) 206487 Protocols for IP Multicast yes draft-ietf-ice-trickle-21.txt 2018-05-22 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8838 E. Ivov, J. Uberti, P. Saint-Andre Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol 74390 Interactive Connectivity Establishment yes draft-ietf-bess-evpn-prefix-advertisement-11.txt 2018-05-24 MISSREF*R(1G) draft-ietf-bess-evpn-inter-subnet-forwarding NOT-RECEIVED J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi IP Prefix Advertisement in EVPN 83101 BGP Enabled Services yes draft-ietf-mmusic-sdp-bundle-negotiation-54.txt 2018-06-18 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8843 draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE draft-ietf-mmusic-trickle-ice-sip IN-QUEUE C. Holmberg, H. Alvestrand, C. Jennings Negotiating Media Multiplexing Using the Session Description Protocol (SDP) 147171 Multiparty Multimedia Session Control yes draft-ietf-mmusic-trickle-ice-sip-18.txt 2018-07-02 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8840 draft-ietf-ice-trickle IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE draft-ietf-mmusic-mux-exclusive IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE E. Ivov, T. Stach, E. Marocco, C. Holmberg A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) 101829 Multiparty Multimedia Session Control yes draft-ietf-mmusic-sdp-simulcast-14.txt 2018-07-10 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8853 draft-ietf-avtext-rid IN-QUEUE draft-ietf-mmusic-rid IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty Using Simulcast in SDP and RTP Sessions 94865 Multiparty Multimedia Session Control yes draft-ietf-ippm-twamp-yang-13.txt 2018-07-11 AUTH48*R http://www.rfc-editor.org/auth48/rfc8913 draft-ietf-ippm-metric-registry IN-QUEUE R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed. Two-Way Active Measurement Protocol (TWAMP) Data Model 136989 IP Performance Measurement yes draft-ietf-bfd-yang-17.txt 2018-08-06 MISSREF*R(1G) draft-ietf-mpls-base-yang IN-QUEUE draft-ietf-teas-yang-te NOT-RECEIVED R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky YANG Data Model for Bidirectional Forwarding Detection (BFD) 145281 Bidirectional Forwarding Detection yes draft-ietf-homenet-babel-profile-07.txt 2018-09-10 MISSREF*R(1G) draft-ietf-babel-source-specific NOT-RECEIVED draft-ietf-babel-rfc6126bis IN-QUEUE J. Chroboczek Homenet profile of the Babel routing protocol 19874 Home Networking yes draft-ietf-bfcpbis-rfc4583bis-27.txt 2018-12-21 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8856 draft-ietf-bfcpbis-rfc4582bis IN-QUEUE draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-mmusic-ice-sip-sdp IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE G. Camarillo, T. Kristensen, C. Holmberg Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams 48918 Binary Floor Control Protocol Bis yes draft-ietf-lisp-rfc8113bis-03.txt 2019-01-28 MISSREF*R(1G) draft-ietf-lisp-rfc6833bis NOT-RECEIVED M. Boucadair, C. Jacquenet Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations 10277 Locator/ID Separation Protocol yes draft-ietf-idr-bgpls-segment-routing-epe-19.txt 2019-05-20 MISSREF*R(2G) draft-ietf-idr-bgp-ls-segment-routing-ext IN-QUEUE S. Previdi, K. Talaulikar, C. Filsfils, K. Patel, S. Ray, J. Dong BGP-LS extensions for Segment Routing BGP Egress Peer Engineering 38137 Inter-Domain Routing yes draft-ietf-mmusic-data-channel-sdpneg-28.txt 2019-05-21 AUTH48*R http://www.rfc-editor.org/auth48/rfc8864 draft-ietf-mmusic-rfc4566bis IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed. SDP-based Data Channel Negotiation 91932 Multiparty Multimedia Session Control yes draft-ietf-perc-private-media-framework-12.txt 2019-06-11 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8871 draft-ietf-perc-srtp-ekt-diet IN-QUEUE P. Jones, D. Benham, C. Groves A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC) 68797 Privacy Enhanced RTP Conferencing yes draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt 2019-07-04 MISSREF*R(1G) draft-ietf-lsr-ospf-prefix-originator NOT-RECEIVED S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen BGP Link-State extensions for Segment Routing 70095 Inter-Domain Routing yes draft-ietf-roll-efficient-npdao-18.txt 2019-07-11 MISSREF*R(1G) draft-ietf-roll-unaware-leaves NOT-RECEIVED R. Jadhav, Ed., P. Thubert, R. Sahoo, Z. Cao Efficient Route Invalidation 55789 Routing Over Low power and Lossy networks yes draft-ietf-rtcweb-ip-handling-12.txt 2019-07-12 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8828 draft-ietf-rtcweb-security-arch IN-QUEUE J. Uberti WebRTC IP Address Handling Requirements 26488 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-security-12.txt 2019-07-12 AUTH48*R http://www.rfc-editor.org/auth48/rfc8826 draft-ietf-rtcweb-security-arch IN-QUEUE E. Rescorla Security Considerations for WebRTC 65610 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-fec-10.txt 2019-07-16 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8854 J. Uberti WebRTC Forward Error Correction Requirements 27189 Real-Time Communication in WEB-browsers yes draft-ietf-rtcweb-security-arch-20.txt 2019-07-22 AUTH48*R http://www.rfc-editor.org/auth48/rfc8827 draft-ietf-mmusic-sdp-uks IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE E. Rescorla WebRTC Security Architecture 102483 Real-Time Communication in WEB-browsers yes draft-ietf-mmusic-sdp-uks-07.txt 2019-08-13 AUTH48*R http://www.rfc-editor.org/auth48/rfc8844 draft-ietf-mmusic-dtls-sdp IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE M. Thomson, E. Rescorla Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP) 47406 Multiparty Multimedia Session Control yes draft-ietf-mmusic-ice-sip-sdp-39.txt 2019-08-14 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8839 draft-ietf-ice-trickle IN-QUEUE M. Petit-Huguenin, S. Nandakumar, C. Holmberg, A. Keränen, R. Shpount Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) 94766 Multiparty Multimedia Session Control yes draft-ietf-mmusic-rfc4566bis-37.txt 2019-08-20 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8866 draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE A. Begen, P. Kyzivat, C. Perkins, M. Handley SDP: Session Description Protocol 133368 Multiparty Multimedia Session Control yes draft-ietf-ospf-yang-29.txt 2019-08-26 MISSREF*R(2G) draft-ietf-bfd-yang IN-QUEUE D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem YANG Data Model for OSPF Protocol 234221 Link State Routing yes draft-ietf-6lo-deadline-time-05.txt 2019-10-10 MISSREF*R(2G) draft-ietf-6tisch-architecture IN-QUEUE L. Thomas, S. Anamalamudi, S. Anand, M. Hegde, C. Perkins Packet Delivery Deadline time in 6LoWPAN Routing Header 47643 IPv6 over Networks of Resource-constrained Nodes yes draft-ietf-isis-yang-isis-cfg-42.txt 2019-10-17 MISSREF*R(2G) draft-ietf-bfd-yang IN-QUEUE S. Litkowski, D. Yeung, A. Lindem, J. Zhang, L. Lhotka YANG Data Model for IS-IS Protocol 211538 Link State Routing yes draft-ietf-6tisch-minimal-security-15.txt 2019-12-11 MISSREF*R(2G) draft-ietf-6tisch-architecture IN-QUEUE draft-ietf-core-stateless IN-QUEUE M. Vucinic, Ed., J. Simon, K. Pister, M. Richardson Constrained Join Protocol (CoJP) for 6TiSCH 132046 IPv6 over the TSCH mode of IEEE 802.15.4e yes draft-ietf-tls-certificate-compression-10.txt 2019-12-23 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8879 draft-kucherawy-rfc8478bis IN-QUEUE A. Ghedini, V. Vasiliev TLS Certificate Compression 17410 Transport Layer Security yes draft-ietf-ace-coap-est-18.txt 2020-01-16 MISSREF*R(1G) draft-ietf-tls-dtls13 NOT-RECEIVED P. van der Stok, P. Kampanakis, M. Richardson, S. Raza EST over secure CoAP (EST-coaps) 109546 Authentication and Authorization for Constrained Environments yes draft-ietf-ippm-initial-registry-16.txt 2020-03-13 AUTH48*R http://www.rfc-editor.org/auth48/rfc8912 draft-ietf-ippm-metric-registry IN-QUEUE A. Morton, M. Bagnulo, P. Eardley, K. D'Souza Initial Performance Metrics Registry Entries 156719 IP Performance Measurement yes draft-ietf-netmod-module-tags-10.txt 2020-03-17 AUTH48 http://www.rfc-editor.org/auth48/rfc8819 C. Hopps, L. Berger, D. Bogdanovic YANG Module Tags 37221 Network Modeling yes draft-ietf-6tisch-enrollment-enhanced-beacon-14.txt 2020-03-18 MISSREF*R(3G) draft-ietf-6tisch-minimal-security IN-QUEUE D. Dujovne, M. Richardson IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information 27832 IPv6 over the TSCH mode of IEEE 802.15.4e yes draft-ietf-mpls-ldp-yang-09.txt 2020-03-23 MISSREF*R(1G) draft-ietf-rtgwg-policy-model NOT-RECEIVED K. Raza, Ed., R. Asati, X. Liu, S. Esale, X. Chen, H. Shah YANG Data Model for MPLS LDP 176852 Multiprotocol Label Switching yes draft-ietf-uta-tls-for-email-05.txt 2020-03-24 MISSREF*R(1G) draft-ietf-tls-oldversions-deprecate NOT-RECEIVED L. Velvindron, S. Farrell Deprecation of use of TLS 1.1 for Email Submission and Access 10383 Using TLS in Applications yes draft-ietf-anima-bootstrapping-keyinfra-45.txt 2020-04-09 EDIT*R draft-ietf-anima-autonomic-control-plane IN-QUEUE draft-ietf-anima-grasp IN-QUEUE M. Pritikin, M. Richardson, T.T.E. Eckert, M.H. Behringer, K.W. Watsen Bootstrapping Remote Secure Key Infrastructures (BRSKI) 300799 Autonomic Networking Integrated Model and Approach yes draft-ietf-mmusic-t140-usage-data-channel-14.txt 2020-04-10 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8865 draft-ietf-mmusic-rfc4566bis IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE C. Holmberg, G. Hellstrom T.140 Real-time Text Conversation over WebRTC Data Channels 46048 Multiparty Multimedia Session Control yes draft-ietf-ice-pac-06.txt 2020-04-27 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8863 draft-ietf-ice-trickle IN-QUEUE C. Holmberg, J. Uberti Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) 16203 Interactive Connectivity Establishment yes draft-ietf-idr-rfc5575bis-27.txt 2020-05-21 EDIT*R draft-ietf-idr-flow-spec-v6 IN-QUEUE C. Loibl, S. Hares, R. Raszuk, D. McPherson, M. Bacher Dissemination of Flow Specification Rules 90137 Inter-Domain Routing yes draft-ietf-isis-mpls-elc-13.txt 2020-06-01 MISSREF*R(2G) draft-ietf-idr-bgp-ls-segment-routing-ext IN-QUEUE X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS 15882 Link State Routing yes draft-ietf-ospf-mpls-elc-15.txt 2020-06-01 MISSREF*R(2G) draft-ietf-idr-bgp-ls-segment-routing-ext IN-QUEUE draft-ietf-isis-mpls-elc IN-QUEUE X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF 18504 Link State Routing yes draft-ietf-perc-srtp-ekt-diet-13.txt 2020-06-23 AUTH48 http://www.rfc-editor.org/auth48/rfc8870 C. Jennings, J. Mattsson, D. McGrew, D. Wing, F. Andreasen Encrypted Key Transport for DTLS and Secure RTP 57495 Privacy Enhanced RTP Conferencing yes draft-ietf-secevent-http-push-14.txt 2020-06-29 AUTH48 http://www.rfc-editor.org/auth48/rfc8935 A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin Push-Based Security Event Token (SET) Delivery Using HTTP 50322 Security Events yes draft-ietf-secevent-http-poll-12.txt 2020-06-29 AUTH48*R http://www.rfc-editor.org/auth48/rfc8936 draft-ietf-secevent-http-push IN-QUEUE A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin Poll-Based Security Event Token (SET) Delivery Using HTTP 43756 Security Events yes draft-ietf-dots-signal-filter-control-07.txt 2020-06-29 MISSREF*R(1G) draft-ietf-dots-rfc8782-bis NOT-RECEIVED K. Nishizuka, M. Boucadair, T. Reddy, T. Nagata Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel 50010 DDoS Open Threat Signaling yes draft-ietf-httpbis-header-structure-19.txt 2020-07-10 AUTH48 http://www.rfc-editor.org/auth48/rfc8941 M. Nottingham, P. Kamp Structured Field Values for HTTP 78342 HTTP yes draft-ietf-dnsop-rfc2845bis-09.txt 2020-07-10 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8945 F. Dupont, S. Morris, P. Vixie, D. Eastlake 3rd, O. Gudmundsson, B. Wellington Secret Key Transaction Authentication for DNS (TSIG) 66569 Domain Name System Operations yes draft-ietf-detnet-ip-07.txt 2020-07-10 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8939 draft-ietf-detnet-data-plane-framework IN-QUEUE B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant DetNet Data Plane: IP 57921 Deterministic Networking yes draft-ietf-stir-passport-divert-09.txt 2020-07-24 AUTH48 http://www.rfc-editor.org/auth48/rfc8946 J. Peterson PASSporT Extension for Diverted Calls 49925 Secure Telephone Identity Revisited yes draft-ietf-lisp-gpe-19.txt 2020-08-11 MISSREF*R(1G) draft-ietf-lisp-rfc6830bis NOT-RECEIVED F. Maino, Ed., J. Lemon, P. Agarwal, D. Lewis, M. Smith LISP Generic Protocol Extension 36206 Locator/ID Separation Protocol yes draft-ietf-mmusic-msrp-usage-data-channel-24.txt 2020-08-17 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8873 draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE JM. Recio, Ed., C. Holmberg MSRP over Data Channels 59893 Multiparty Multimedia Session Control yes draft-ietf-ippm-route-10.txt 2020-08-20 MISSREF*R(1G) draft-ietf-ippm-ioam-data NOT-RECEIVED J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib Advanced Unidirectional Route Assessment (AURA) 64546 IP Performance Measurement yes draft-ietf-oauth-jwsreq-30.txt 2020-08-21 IESG*A N. Sakimura, J. Bradley, M. Jones The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) 72482 Web Authorization Protocol yes draft-ietf-pim-igmp-mld-snooping-yang-18.txt 2020-08-25 MISSREF*R(1G) draft-ietf-bess-l2vpn-yang NOT-RECEIVED H. Zhao, X. Liu, Y. Liu, M. Sivakumar, A. Peter A Yang Data Model for IGMP and MLD Snooping 82199 Protocols for IP Multicast yes draft-ietf-bess-nsh-bgp-control-plane-18.txt 2020-08-27 MISSREF*R(1G) draft-ietf-idr-rfc5575bis IN-QUEUE draft-ietf-idr-tunnel-encaps NOT-RECEIVED A. Farrel, J. Drake, E. Rosen, J. Uttaro, L. Jalil BGP Control Plane for the Network Service Header in Service Function Chaining 166204 BGP Enabled Services yes draft-ietf-babel-dtls-10.txt 2020-09-03 AUTH48*R http://www.rfc-editor.org/auth48/rfc8968 draft-ietf-babel-rfc6126bis IN-QUEUE A. Décimo, D. Schinazi, J. Chroboczek Babel Routing Protocol over Datagram Transport Layer Security 23203 Babel routing protocol yes draft-ietf-babel-rfc6126bis-20.txt 2020-09-03 AUTH48*R http://www.rfc-editor.org/auth48/rfc8966 draft-ietf-babel-hmac IN-QUEUE J. Chroboczek, D. Schinazi The Babel Routing Protocol 161068 Babel routing protocol yes draft-ietf-dhc-mac-assign-09.txt 2020-09-04 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8947 draft-ietf-dhc-slap-quadrant IN-QUEUE B. Volz, T. Mrugalski, C. Bernardos Link-Layer Addresses Assignment Mechanism for DHCPv6 48378 Dynamic Host Configuration yes draft-ietf-babel-hmac-12.txt 2020-09-08 AUTH48*R http://www.rfc-editor.org/auth48/rfc8967 draft-ietf-babel-rfc6126bis IN-QUEUE C. Do, W. Kolodziejak, J. Chroboczek MAC authentication for the Babel routing protocol 49752 Babel routing protocol yes draft-ietf-6tisch-msf-18.txt 2020-09-14 MISSREF*R(2G) draft-ietf-6tisch-minimal-security IN-QUEUE draft-ietf-6tisch-enrollment-enhanced-beacon IN-QUEUE draft-ietf-6tisch-architecture IN-QUEUE T. Chang, Ed., M. Vucinic, X. Vilajosana, S. Duquennoy, D. Dujovne 6TiSCH Minimal Scheduling Function (MSF) 51386 IPv6 over the TSCH mode of IEEE 802.15.4e yes draft-ietf-cbor-7049bis-16.txt 2020-09-30 AUTH48 http://www.rfc-editor.org/auth48/rfc8949 C. Bormann, P. Hoffman Concise Binary Object Representation (CBOR) 198332 Concise Binary Object Representation Maintenance and Extensions yes draft-ietf-dhc-slap-quadrant-12.txt 2020-10-13 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8948 draft-ietf-dhc-mac-assign IN-QUEUE CJ. Bernardos, A. Mourad SLAP quadrant selection option for DHCPv6 44893 Dynamic Host Configuration yes draft-ietf-mpls-base-yang-17.txt 2020-10-26 AUTH48 http://www.rfc-editor.org/auth48/rfc8960 T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram A YANG Data Model for MPLS Base 52010 Multiprotocol Label Switching yes draft-ietf-detnet-mpls-13.txt 2020-10-27 RFC-EDITOR*R draft-ietf-detnet-data-plane-framework IN-QUEUE B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant, J. Korhonen DetNet Data Plane: MPLS 76435 Deterministic Networking yes draft-ietf-detnet-ip-over-mpls-09.txt 2020-10-27 MISSREF*R(1G) draft-ietf-detnet-data-plane-framework IN-QUEUE draft-ietf-detnet-ip IN-QUEUE draft-ietf-detnet-mpls IN-QUEUE draft-ietf-detnet-security NOT-RECEIVED B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen DetNet Data Plane: IP over MPLS 27523 Deterministic Networking yes draft-ietf-mpls-sfl-framework-11.txt 2020-10-28 AUTH48 http://www.rfc-editor.org/auth48/rfc8957 S. Bryant, M. Chen, G. Swallow, S. Sivabalan, G. Mirsky Synonymous Flow Label Framework 22797 Multiprotocol Label Switching yes draft-ietf-anima-autonomic-control-plane-30.txt 2020-11-02 EDIT*R draft-ietf-anima-bootstrapping-keyinfra IN-QUEUE draft-ietf-anima-grasp IN-QUEUE T. Eckert, Ed., M. Behringer, Ed., S. Bjarnason An Autonomic Control Plane (ACP) 461005 Autonomic Networking Integrated Model and Approach yes draft-ietf-pce-pcep-flowspec-12.txt 2020-11-02 MISSREF*R(1G) draft-ietf-idr-flow-spec-v6 IN-QUEUE draft-ietf-idr-flowspec-l2vpn NOT-RECEIVED draft-ietf-idr-rfc5575bis IN-QUEUE D. Dhody, A. Farrel, Z. Li PCEP Extension for Flow Specification 81648 Path Computation Element yes draft-ietf-nfsv4-rpc-tls-11.txt 2020-11-03 MISSREF*R(1G) draft-ietf-kitten-tls-channel-bindings-for-tls13 NOT-RECEIVED draft-ietf-tls-dtls-connection-id NOT-RECEIVED draft-ietf-tls-dtls13 NOT-RECEIVED T. Myklebust, C. Lever, Ed. Towards Remote Procedure Call Encryption By Default 60923 Network File System Version 4 yes draft-ietf-ippm-stamp-option-tlv-10.txt 2020-11-15 EDIT G. Mirsky, X. Min, H. Nydell, R. Foote, A. Masputra, E. Ruffini Simple Two-way Active Measurement Protocol Optional Extensions 77415 IP Performance Measurement yes draft-ietf-dots-server-discovery-15.txt 2020-11-16 EDIT M. Boucadair, T. Reddy.K Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent Discovery 57831 DDoS Open Threat Signaling yes draft-ietf-extra-imap-fetch-preview-10.txt 2020-11-18 EDIT*A M. Slusarz IMAP4 Extension: Message Preview Generation 26963 Email mailstore and eXtensions To Revise or Amend yes draft-ietf-avtcore-cc-feedback-message-09.txt 2020-11-18 EDIT*R draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-mmusic-sdp-mux-attributes IN-QUEUE Z. Sarker, C. Perkins, V. Singh, M. Ramalho RTP Control Protocol (RTCP) Feedback for Congestion Control 39795 Audio/Video Transport Core Maintenance yes draft-ietf-dnsop-dns-zone-digest-14.txt 2020-11-19 EDIT D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker Message Digest for DNS Zones 84724 Domain Name System Operations yes draft-ietf-core-stateless-08.txt 2020-11-19 EDIT K. Hartke, M. Richardson Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) 51598 Constrained RESTful Environments yes draft-ietf-calext-jscalendar-32.txt 2020-11-19 EDIT*A N. Jenkins, R. Stepanek JSCalendar: A JSON representation of calendar data 182752 Calendaring Extensions yes draft-ietf-idr-flow-spec-v6-21.txt 2020-11-25 EDIT*A*R draft-ietf-idr-rfc5575bis IN-QUEUE C. Loibl, Ed., R. Raszuk, Ed., S. Hares, Ed. Dissemination of Flow Specification Rules for IPv6 37518 Inter-Domain Routing yes
draft-ietf-rmcat-cc-requirements-09.txt 2014-12-12 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8836 draft-ietf-rtcweb-overview IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-rtcweb-data-protocol IN-QUEUE draft-ietf-rtcweb-jsep IN-QUEUE draft-ietf-rtcweb-rtp-usage IN-QUEUE draft-ietf-rtcweb-security IN-QUEUE draft-ietf-rtcweb-security-arch IN-QUEUE R. Jesup, Z. Sarker, Ed. Congestion Control Requirements for Interactive Real-Time Media 27484 RTP Media Congestion Avoidance Techniques yes draft-ietf-lisp-introduction-13.txt 2015-04-23 MISSREF*R(1G) draft-ietf-lisp-sec NOT-RECEIVED A. Cabellos-Aparicio, D. Saucez, Ed. An Architectural Introduction to the Locator/ID Separation Protocol (LISP) 66992 Locator/ID Separation Protocol yes draft-ietf-lwig-cellular-06.txt 2016-01-04 MISSREF*R(1G) draft-ietf-core-resource-directory NOT-RECEIVED J. Arkko, A. Eriksson, A. Keränen Building Power-Efficient CoAP Devices for Cellular Networks 39751 Light-Weight Implementation Guidance yes draft-ietf-anima-prefix-management-07.txt 2017-12-19 EDIT*R draft-ietf-anima-autonomic-control-plane IN-QUEUE draft-ietf-anima-bootstrapping-keyinfra IN-QUEUE draft-ietf-anima-grasp IN-QUEUE S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun Autonomic IPv6 Edge Prefix Management in Large-scale Networks 52556 Autonomic Networking Integrated Model and Approach yes draft-ietf-spring-segment-routing-central-epe-10.txt 2017-12-21 MISSREF*R(3G) draft-ietf-idr-bgpls-segment-routing-epe IN-QUEUE C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev Segment Routing Centralized BGP Egress Peer Engineering 35539 Source Packet Routing in Networking yes draft-ietf-anima-reference-model-10.txt 2018-11-24 EDIT*R draft-ietf-anima-autonomic-control-plane IN-QUEUE draft-ietf-anima-bootstrapping-keyinfra IN-QUEUE draft-ietf-anima-grasp IN-QUEUE M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre A Reference Model for Autonomic Networking 72222 Autonomic Networking Integrated Model and Approach yes draft-ietf-httpbis-expect-ct-08.txt 2018-12-21 MISSREF*R(1G) draft-ietf-trans-rfc6962-bis NOT-RECEIVED E. Stark Expect-CT Extension for HTTP 51380 HTTP yes draft-ietf-hip-rfc4423-bis-20.txt 2019-03-23 MISSREF*R(1G) draft-ietf-hip-dex NOT-RECEIVED draft-ietf-hip-native-nat-traversal IN-QUEUE R. Moskowitz, Ed., M. Komu Host Identity Protocol Architecture 133290 Host Identity Protocol yes draft-ietf-clue-datachannel-18.txt 2019-04-17 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8850 draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE C. Holmberg CLUE Protocol data channel 29058 ControLling mUltiple streams for tElepresence yes draft-ietf-sipbrandy-rtpsec-08.txt 2019-05-14 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8862 draft-ietf-mmusic-trickle-ice-sip IN-QUEUE J. Peterson, R. Barnes, R. Housley Best Practices for Securing RTP Media Signaled with SIP 35321 SIP Best-practice Recommendations Against Network Dangers to privacY yes draft-ietf-rmcat-eval-test-10.txt 2019-05-30 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8867 draft-ietf-rmcat-cc-requirements IN-QUEUE draft-ietf-rmcat-eval-criteria IN-QUEUE draft-ietf-rmcat-wireless-tests IN-QUEUE Z. Sarker, V. Singh, X. Zhu, M. Ramalho Test Cases for Evaluating RMCAT Proposals 68718 RTP Media Congestion Avoidance Techniques yes draft-ietf-6tisch-architecture-29.txt 2019-10-30 MISSREF*R(1G) draft-ietf-6tisch-minimal-security IN-QUEUE draft-ietf-roll-useofrplinfo NOT-RECEIVED draft-ietf-roll-unaware-leaves NOT-RECEIVED draft-ietf-6tisch-enrollment-enhanced-beacon IN-QUEUE draft-ietf-6tisch-msf IN-QUEUE P. Thubert An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 177561 IPv6 over the TSCH mode of IEEE 802.15.4e yes draft-ietf-clue-signaling-15.txt 2019-12-11 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8848 draft-ietf-clue-data-model-schema IN-QUEUE draft-ietf-clue-datachannel IN-QUEUE draft-ietf-clue-framework IN-QUEUE draft-ietf-clue-protocol IN-QUEUE draft-ietf-clue-rtp-mapping IN-QUEUE draft-ietf-mmusic-data-channel-sdpneg IN-QUEUE draft-ietf-mmusic-sctp-sdp IN-QUEUE draft-ietf-mmusic-sdp-bundle-negotiation IN-QUEUE draft-ietf-rtcweb-data-channel IN-QUEUE R. Hanton, P. Kyzivat, L. Xiao, C. Groves Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) 98889 ControLling mUltiple streams for tElepresence yes draft-ietf-clue-protocol-19.txt 2019-12-11 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8847 draft-ietf-clue-data-model-schema IN-QUEUE draft-ietf-clue-datachannel IN-QUEUE draft-ietf-clue-framework IN-QUEUE draft-ietf-clue-signaling IN-QUEUE R. Presta, S P. Romano Protocol for Controlling Multiple Streams for Telepresence (CLUE) 146848 ControLling mUltiple streams for tElepresence yes draft-ietf-i2nsf-applicability-18.txt 2019-12-16 MISSREF*R(1G) draft-ietf-i2nsf-consumer-facing-interface-dm NOT-RECEIVED draft-ietf-i2nsf-nsf-facing-interface-dm NOT-RECEIVED draft-ietf-i2nsf-nsf-monitoring-data-model NOT-RECEIVED draft-ietf-i2nsf-registration-interface-dm NOT-RECEIVED J. Jeong, S. Hyun, T. Ahn, S. Hares, D. Lopez Applicability of Interfaces to Network Security Functions to Network-Based Security Services 69045 Interface to Network Security Functions yes draft-ietf-stir-oob-07.txt 2020-03-10 AUTH48 http://www.rfc-editor.org/auth48/rfc8816 E. Rescorla, J. Peterson STIR Out-of-Band Architecture and Use Cases 74592 Secure Telephone Identity Revisited yes draft-ietf-ippm-metric-registry-24.txt 2020-03-13 AUTH48 http://www.rfc-editor.org/auth48/rfc8911 M. Bagnulo, B. Claise, P. Eardley, A. Morton, A. Akhter Registry for Performance Metrics 86075 IP Performance Measurement yes draft-ietf-rmcat-wireless-tests-11.txt 2020-03-13 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8869 draft-ietf-rmcat-eval-criteria IN-QUEUE draft-ietf-rmcat-eval-test IN-QUEUE Z. Sarker, X. Zhu, J. Fu Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks 50652 RTP Media Congestion Avoidance Techniques yes draft-ietf-rmcat-eval-criteria-14.txt 2020-03-25 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8868 draft-ietf-rmcat-cc-requirements IN-QUEUE V. Singh, J. Ott, S. Holmer Evaluating Congestion Control for Interactive Real-time Media 37167 RTP Media Congestion Avoidance Techniques yes draft-ietf-detnet-data-plane-framework-06.txt 2020-06-11 AUTH48-DONE http://www.rfc-editor.org/auth48/rfc8938 B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant DetNet Data Plane Framework 63399 Deterministic Networking yes draft-ietf-avtcore-multiplex-guidelines-12.txt 2020-06-22 AUTH48-DONE*R http://www.rfc-editor.org/auth48/rfc8872 draft-ietf-perc-srtp-ekt-diet IN-QUEUE M. Westerlund, B. Burman, C. Perkins, H. Alvestrand, R. Even Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams 108104 Audio/Video Transport Core Maintenance yes draft-ietf-httpbis-client-hints-15.txt 2020-07-10 AUTH48*R http://www.rfc-editor.org/auth48/rfc8942 draft-ietf-httpbis-header-structure IN-QUEUE I. Grigorik, Y. Weiss HTTP Client Hints 29771 HTTP yes draft-ietf-dots-use-cases-25.txt 2020-07-13 AUTH48 http://www.rfc-editor.org/auth48/rfc8903 R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka Use cases for DDoS Open Threat Signaling 33941 DDoS Open Threat Signaling yes draft-ietf-cose-rfc8152bis-algs-12.txt 2020-07-30 MISSREF*A*R(1G) draft-ietf-cose-rfc8152bis-struct NOT-RECEIVED J. Schaad CBOR Object Signing and Encryption (COSE): Initial Algorithms 130126 CBOR Object Signing and Encryption yes draft-ietf-hip-native-nat-traversal-33.txt 2020-08-04 MISSREF*R(2G) draft-ietf-hip-rfc4423-bis IN-QUEUE A. Keränen, J. Melen, M. Komu, Ed. Native NAT Traversal Mode for the Host Identity Protocol 179965 Host Identity Protocol yes draft-ietf-babel-applicability-10.txt 2020-09-03 AUTH48*R http://www.rfc-editor.org/auth48/rfc8965 draft-ietf-babel-rfc6126bis IN-QUEUE J. Chroboczek Applicability of the Babel routing protocol 24454 Babel routing protocol yes draft-ietf-cose-hash-algs-09.txt 2020-09-14 MISSREF*A*R(1G) draft-ietf-cose-rfc8152bis-struct NOT-RECEIVED J. Schaad CBOR Object Signing and Encryption (COSE): Hash Algorithms 26902 CBOR Object Signing and Encryption yes draft-ietf-capport-architecture-10.txt 2020-09-24 AUTH48 http://www.rfc-editor.org/auth48/rfc8952 K. Larose, D. Dolson, H. Liu Captive Portal Architecture 52983 Captive Portal Interaction yes draft-ietf-opsawg-model-automation-framework-10.txt 2020-10-26 RFC-EDITOR Q. Wu, Ed., M. Boucadair, Ed., D. Lopez, C. Xie, L. Geng A Framework for Automating Service and Network Management with YANG 107250 Operations and Management Area Working Group yes draft-ietf-bfd-vxlan-16.txt 2020-10-29 RFC-EDITOR S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda BFD for VXLAN 21613 Bidirectional Forwarding Detection yes
draft-kucherawy-rfc8478bis-05.txt 2020-04-23 IESG Y. Collet, M. Kucherawy, Ed. Zstandard Compression and the application/zstd Media Type 110649 IETF - NON WORKING GROUP yes draft-hardie-dispatch-rfc3405-update-04.txt 2020-10-15 AUTH48 http://www.rfc-editor.org/auth48/rfc8958 T. Hardie Updated registration rules for URI.ARPA 6002 IETF - NON WORKING GROUP yes draft-nottingham-how-did-that-get-into-the-repo-02.txt 2020-10-21 AUTH48 http://www.rfc-editor.org/auth48/rfc8959 M. Nottingham The secret-token URI Scheme 10817 IETF - NON WORKING GROUP yes
draft-ribose-asciirfc-08.txt 2018-04-19 AUTH R. Tse, N. Nicholas, J. Lau, P. Brasolin draft-ribose-asciirfc-08 287041 INDEPENDENT N/A draft-moriarty-caris2-04.txt 2020-10-13 AUTH48 http://www.rfc-editor.org/auth48/rfc8953 K. Moriarty Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report 37116 INDEPENDENT N/A draft-huitema-rfc-eval-project-07.txt 2020-11-09 EDIT C. Huitema Evaluation of a Sample of RFC Produced in 2018 113945 INDEPENDENT N/A
./draft-ietf-detnet-data-plane-framework-06.txt0000644000764400076440000017364713654525551020675 0ustar iustyiusty DetNet B. Varga, Ed. Internet-Draft J. Farkas Intended status: Informational Ericsson Expires: November 7, 2020 L. Berger LabN Consulting, L.L.C. A. Malis Malis Consulting S. Bryant Futurewei Technologies May 6, 2020 DetNet Data Plane Framework draft-ietf-detnet-data-plane-framework-06 Abstract This document provides an overall framework for the DetNet data plane. It covers concepts and considerations that are generally common to any Deterministic Networking data plane specification. It describes related controller plane considerations as well. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 7, 2020. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Varga, et al. Expires November 7, 2020 [Page 1] Internet-Draft DetNet Data Plane Framework May 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 3. DetNet Data Plane Overview . . . . . . . . . . . . . . . . . 4 3.1. Data Plane Characteristics . . . . . . . . . . . . . . . 6 3.1.1. Data Plane Technology . . . . . . . . . . . . . . . . 6 3.1.2. Encapsulation . . . . . . . . . . . . . . . . . . . . 6 3.2. DetNet-specific Metadata . . . . . . . . . . . . . . . . 7 3.3. DetNet IP Data Plane . . . . . . . . . . . . . . . . . . 8 3.4. DetNet MPLS Data Plane . . . . . . . . . . . . . . . . . 8 3.5. Further DetNet Data Plane Considerations . . . . . . . . 9 3.5.1. Per Flow Related Functions . . . . . . . . . . . . . 9 3.5.2. Service Protection . . . . . . . . . . . . . . . . . 11 3.5.3. Aggregation Considerations . . . . . . . . . . . . . 13 3.5.4. End-System-Specific Considerations . . . . . . . . . 14 3.5.5. Sub-Network Considerations . . . . . . . . . . . . . 15 4. Controller Plane (Management and Control) Considerations . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. DetNet Controller Plane Requirements . . . . . . . . . . 15 4.2. Generic Controller Plane Considerations . . . . . . . . . 17 4.2.1. Flow Aggregation Control . . . . . . . . . . . . . . 17 4.2.2. Explicit Routes . . . . . . . . . . . . . . . . . . . 18 4.2.3. Contention Loss and Jitter Reduction . . . . . . . . 19 4.2.4. Bidirectional Traffic . . . . . . . . . . . . . . . . 19 4.3. Packet Replication, Elimination, and Ordering (PREOF) . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction DetNet (Deterministic Networking) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low packet loss rates and assured maximum end-to-end Varga, et al. Expires November 7, 2020 [Page 2] Internet-Draft DetNet Data Plane Framework May 2020 delivery latency. A description of the general background and concepts of DetNet can be found in [RFC8655]. This document describes the concepts needed by any DetNet data plane specification (i.e., the DetNet-specific use of packet header fields) and provides considerations for any corresponding implementation. It covers the building blocks that provide the DetNet service, the DetNet service sub-layer and the DetNet forwarding sub-layer functions as described in the DetNet Architecture. The DetNet Architecture models the DetNet related data plane functions as being decomposed into two sub-layers: a service sub- layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service protection and reordering. The forwarding sub-layer leverages Traffic Engineering mechanisms and provides congestion protection (low loss, assured latency, and limited out-of- order delivery). A particular forwarding sub-layer may have capabilities that are not available on other forwarding-sub layers. DetNet makes use of the existing forwarding sub-layers with their respective capabilities and does not require 1:1 equivalence between different forwarding sub-layer capabilities. As part of the service sub-layer functions, this document describes typical DetNet node data plane operation. It describes the functionality and operation of the Packet Replication (PRF), Packet Elimination (PEF), and the Packet Ordering (POF) functions within the service sub-layer. Furthermore, it describes the forwarding sub- layer. As defined in [RFC8655], DetNet flows may be carried over network technologies that can provide the DetNet required service characteristics. For example, DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive Network (TSN) [IEEE802.1TSNTG] sub- networks. However, IEEE 802.1 TSN support is not required in DetNet. TSN frame preemption is an example of a forwarding layer capability that is typically not replicated in other forwarding technologies. Most of DetNet benefits can be gained by running over a data link layer that has not been specifically enhanced to support all TSN capabilities but for such networks and traffic mixes delay and jitter performance may vary due to the forwarding sub-layer intrinsic properties. Different application flows, such as Ethernet or IP, can be mapped on top of DetNet. DetNet can optionally reuse header information provided by, or shared with, applications. An example of shared header fields can be found in [I-D.ietf-detnet-ip]. Varga, et al. Expires November 7, 2020 [Page 3] Internet-Draft DetNet Data Plane Framework May 2020 This document also covers basic concepts related to the controller plane and Operations, Administration, and Maintenance (OAM). Data plane OAM specifics are out of scope for this document. 2. Terminology 2.1. Terms Used in This Document This document uses the terminology established in the DetNet architecture [RFC8655], and the reader is assumed to be familiar with that document and its terminology. 2.2. Abbreviations The following abbreviations are used in this document: BGP Border Gateway Protocol. d-CW DetNet Control Word. DetNet Deterministic Networking. DN DetNet. GMPLS Generalized Multiprotocol Label Switching. GRE Generic Routing Encapsulation. IPSec IP Security. L2 Layer 2. LSP Label Switched Path. MPLS Multiprotocol Label Switching. OAM Operations, Administration, and Maintenance. PCEP Path Computation Element Communication Protocol. PEF Packet Elimination Function. PRF Packet Replication Function. PREOF Packet Replication, Elimination and Ordering Functions. POF Packet Ordering Function. PSN Packet Switched Network. QoS Quality of Service. S-Label DetNet "service" label. TDM Time-Division Multiplexing. TSN Time-Sensitive Network. YANG Yet Another Next Generation. 3. DetNet Data Plane Overview This document describes how application flows, or app-flows, are carried over DetNet networks. The DetNet Architecture [RFC8655] models the DetNet-related data plane functions as decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer. Figure 1, reproduced from [RFC8655], shows a logical DetNet service with the two sub-layers. Varga, et al. Expires November 7, 2020 [Page 4] Internet-Draft DetNet Data Plane Framework May 2020 | packets going | ^ packets coming ^ v down the stack v | up the stack | +-----------------------+ +-----------------------+ | Source | | Destination | +-----------------------+ +-----------------------+ | Service sub-layer: | | Service sub-layer: | | Packet sequencing | | Duplicate elimination | | Flow replication | | Flow merging | | Packet encoding | | Packet decoding | +-----------------------+ +-----------------------+ | Forwarding sub-layer: | | Forwarding sub-layer: | | Resource allocation | | Resource allocation | | Explicit routes | | Explicit routes | +-----------------------+ +-----------------------+ | Lower layers | | Lower layers | +-----------------------+ +-----------------------+ v ^ \_________________________/ Figure 1: DetNet data plane protocol stack The DetNet forwarding sub-layer may be directly provided by the DetNet service sub-layer, for example by IP tunnels or MPLS. Alternatively, an overlay approach may be used in which the packet is natively carried between key nodes within the DetNet network (say between PREOF nodes) and a sub-layer is used to provide the information needed to reach the next hop in the overlay. The forwarding sub-layer provides the QoS related functions needed by the DetNet flow. It may do this directly through the use of queuing techniques and traffic engineering methods, or it may do this through the assistance of its underlying connectivity. For example it may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN [IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for packet queuing, as well as reservation and allocation of bandwidth capacity resources. The service sub-layer provides additional support beyond the connectivity function of the forwarding sub-layer. See Section 4.3 as an example for Packet Replication, Elimination, and Ordering functions. The ordering function (POF) uses sequence numbers added to packets enabling a range of packet order protection from simple ordering and dropping out-of-order packets to more complex reordering of a fixed number of out-of-order, minimally delayed packets. Reordering requires buffer resources and has impact on the delay and jitter of packets in the DetNet flow. Varga, et al. Expires November 7, 2020 [Page 5] Internet-Draft DetNet Data Plane Framework May 2020 The method of instantiating each of the layers is specific to the particular DetNet data plane method, and more than one approach may be applicable to a given network type. 3.1. Data Plane Characteristics There are two major characteristics to the data plane: the technology and the encapsulation, as discussed below. 3.1.1. Data Plane Technology The DetNet data plane is provided by the DetNet service and forwarding sub layers. The DetNet service sub-layer generally provides its functions for the DetNet application flows by using or applying existing standardized headers and/or encapsulations. The Detnet forwarding sub-layer may provide capabilities leveraging that same header or encapsulation technology (e.g., DN IP or DN MPLS) or it may be achieved by other technologies as shown in Figure 2. DetNet is currently defined for operation over packet-switched (IP) networks or label-switched (MPLS) networks. 3.1.2. Encapsulation DetNet encodes specific flow attributes (flow identity and sequence number) in packets. For example, in DetNet IP, zero encapsulation is used and no sequence number is available, and in DetNet MPLS, DetNet- specific information may be added explicitly to the packets in the form of S-label and d-CW [I-D.ietf-detnet-mpls] . The encapsulation of a DetNet flow allows it to be sent over a data plane technology other than its native type. DetNet uses header information to perform traffic classification, i.e., identify DetNet flows, and provide DetNet service and forwarding functions. As mentioned above, DetNet may add headers, as is the case for DN MPLS, or may use headers that are already present, as is the case in DN IP. Figure 2 illustrates some relationships between the components. +-----+ | TSN | +-------+ +-+-----+-+ | DN IP | | DN MPLS | +--+--+----+----+ +-+---+-----+-+ | TSN | DN MPLS | | TSN | DN IP | +-----+---------+ +-----+-------+ Figure 2: DetNet Service Examples Varga, et al. Expires November 7, 2020 [Page 6] Internet-Draft DetNet Data Plane Framework May 2020 The use of encapsulation is also required if additional information (metadata) is needed by the DetNet data plane and there is either no ability to include it in the client data packet, or the specification of the client data plane does not permit the modification of the packet to include additional data. An example of such metadata is the inclusion of a sequence number required by the PREOF function. Encapsulation may also be used to carry or aggregate flows for equipment with limited DetNet capability. 3.2. DetNet-specific Metadata The DetNet data plane can provide or carry the following metadata: 1. Flow-ID 2. Sequence Number The DetNet data plane framework supports a Flow-ID (for identification of the flow or aggregate flow) and/or a Sequence Number (for PREOF) for each DetNet flow. The Flow-ID is used by both the service and forwarding sub-layers, but the sequence number is only used by the service layer. Metadata can also be used for OAM indications and instrumentation of DetNet data plane operation. Metadata inclusion can be implicit or explicit. Explicit inclusions involve a dedicated header field that is used to include metadata in a DetNet packet. In the implicit method, part of an already existing header field is used to encode the metadata. Explicit inclusion of metadata is possible through the use of IP options or IP extension headers. New IP options are almost impossible to get standardized or to deploy in an operational network and will not be discussed further in this text. IPv6 extensions headers are finding popularity in current IPv6 development work, particularly in connection with Segment Routing of IPv6 (SRv6) and IP OAM. The design of a new IPv6 extension header or the modification of an existing one is a technique available in the tool box of the DetNet IP data plane designer. Explicit inclusion of metadata in an IP packet is also possible through the inclusion of an MPLS label stack and the MPLS DetNet Control Word using one of the methods for carrying MPLS over IP [I-D.ietf-detnet-mpls-over-udp-ip]. This is described in more detail in Section 3.5.5. Implicit metadata in IP can be included through the use of the network programming paradigm Varga, et al. Expires November 7, 2020 [Page 7] Internet-Draft DetNet Data Plane Framework May 2020 [I-D.ietf-spring-srv6-network-programming] in which the suffix of an IPv6 address is used to encode additional information for use by the network of the receiving host. An MPLS example of explicit metadata is the sequence number used by the PREOF function, or even the case where all the essential information being included into the DetNet over MPLS label stack (the DetNet Control Word and the DetNet Service label). 3.3. DetNet IP Data Plane An IP data plane may operate natively or through the use of an encapsulation. Many types of IP encapsulation can satisfy DetNet requirements and it is anticipated that more than one encapsulation may be deployed, for example GRE, IPSec. One method of operating an IP DetNet data plane without encapsulation is to use "6-tuple" based flow identification, where "6-tuple" refers to information carried in IP and higher layer protocol headers. General background on the use of IP headers, and "6-tuples", to identify flows and support Quality of Service (QoS) can be found in [RFC3670]. [RFC7657] provides useful background on differentiated services (DiffServ) and "tuple" based flow identification. DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes and ranges. The operation of this method is described in detail in [I-D.ietf-detnet-ip]. The DetNet forwarding plane may use explicit route capabilities and traffic engineering capabilities to provide a forwarding sub-layer that is responsible for providing resource allocation and explicit routes. It is possible to include such information in a native IP packet explicitly, or implicitly. 3.4. DetNet MPLS Data Plane MPLS provides a forwarding sub-layer for traffic over implicit and explicit paths to the point in the network where the next DetNet service sub-layer action needs to take place. It does this through the use of a stack of one or more labels with various forwarding semantics. MPLS also provides the ability to identify a service instance that is used to process the packet through the use of a label that maps the packet to a service instance. In cases where metadata is needed to process an MPLS encapsulated packet at the service sub-layer, the d-CW [I-D.ietf-detnet-mpls], [RFC4385] can be used. Although such d-CWs are frequently 32 bits Varga, et al. Expires November 7, 2020 [Page 8] Internet-Draft DetNet Data Plane Framework May 2020 long, there is no architectural constraint on the size of this structure, only the requirement that it is fully understood by all parties operating on it in the DetNet service sub-layer. The operation of this method is described in detail in [I-D.ietf-detnet-mpls]. 3.5. Further DetNet Data Plane Considerations This section provides informative considerations related to providing DetNet service to flows which are identified based on their header information. 3.5.1. Per Flow Related Functions At a high level, the following functions are provided on a per flow basis. 3.5.1.1. Reservation and Allocation of resources Resources might be reserved in order to make them available for allocation to specific DetNet flows. This can eliminate packet contention and packet loss for DetNet traffic. This also can reduce jitter for DetNet traffic. Resources allocated to a DetNet flow protect it from other traffic flows. On the other hand, DetNet flows are assumed to behave with respect to the reserved traffic profile. It must be possible to detect misbehaving DetNet flows and to ensure that they do not compromise QoS of other flows. Queuing, policing, and shaping policies can be used to ensure that the allocation of resources reserved for DetNet is met. 3.5.1.2. Explicit routes A flow can be routed over a specific, pre-computed path. This allows control of the network delay by steering the packet with the ability to influence the physical path. Explicit routes complement reservation by ensuring that a consistent path can be associated with its resources for the duration of that path. Coupled with the traffic mechanism, this limits misordering and bounds latency. Explicit route computation can encompass a wide set of constraints and can optimize the path for a certain characteristic, e.g., highest bandwidth or lowest jitter. In these cases the "best" path for any set of characteristics may not be a shortest path. The selection of path can take into account multiple network metrics. Some of these metrics are measured and distributed by the routing system as traffic engineering metrics. Varga, et al. Expires November 7, 2020 [Page 9] Internet-Draft DetNet Data Plane Framework May 2020 3.5.1.3. Service protection Service protection involves use of multiple packet streams using multiple paths, for example 1+1 or 1:1 linear protection. For DetNet, this primarily relates to packet replication and elimination capabilities. MPLS offers a number of protection schemes. MPLS hitless protection can be used to switch traffic to an already established path in order to restore delivery rapidly after a failure. Path changes, even in the case of failure recovery, can lead to the out of order delivery of data requiring packet ordering functions either within the DetNet service or at a high layer in the application traffic. Establishment of new paths after a failure is out of scope for DetNet services. 3.5.1.4. Network Coding Network Coding [nwcrg], not to be confused with network programming, comprises several techniques where multiple data flows are encoded. These resulting flows can then be sent on different paths. The encoding operation can combine flows and error recovery information. When the encoded flows are decoded and recombined the original flows can be recovered. Note that Network coding uses an alternative to packet by packet PREOF. Therefore, for certain network topologies and traffic loads, Network Coding can be used to improve a network's throughput, efficiency, latency, and scalability, as well as resilience to partition, attacks, and eavesdropping, as compared to traditional methods. DetNet could use Network coding as an alternative to other protection means. Network coding is often applied in wireless networks and is being explored for other network types. 3.5.1.5. Load sharing Use of packet-by-packet load sharing of the same DetNet flow over multiple paths is not recommended except for the cases listed above where PREOF is utilized to improve protection of traffic and maintain order. Packet-by-packet load sharing, e.g., via ECMP or UCMP, impacts ordering and possibly jitter. 3.5.1.6. Troubleshooting Detnet leverages many different forwarding sub-layers, each of which supports various tools to troubleshoot connectivity, for example identification of misbehaving flows. The DetNet Service layer can leverage existing mechanisms to troubleshoot or monitor flows, such as those in use by IP and MPLS networks. At the Application layer a client of a DetNet service can use existing techniques to detect and monitor delay and loss. Varga, et al. Expires November 7, 2020 [Page 10] Internet-Draft DetNet Data Plane Framework May 2020 3.5.1.7. Flow recognition for analytics Network analytics can be inherited from the technologies of the Service and Forwarding sub-layers. At the DetNet service edge, packet and bit counters (e.g. sent, received, dropped, and out-of- sequence) can be maintained. 3.5.1.8. Correlation of events with flows The provider of a DetNet service may provide other capabilities to monitor flows, such as more detailed loss statistics and time stamping of events. The details of these capabilities are out of scope for this document. 3.5.2. Service Protection Service protection allows DetNet services to increase reliability and maintain a DetNet Service Assurance in the case of network congestion or network failure. Detnet relies on the underlying technology capabilities for various protection schemes. Protection schemes enable partial or complete coverage of the network paths and active protection with combinations of PRF, PEF, and POF. 3.5.2.1. Linear Service Protection An example DetNet MPLS network fragment and packet flow is illustrated in Figure 3. 1 1.1 1.1 1.2.1 1.2.1 1.2.2 CE1----EN1--------R1-------R2-------R3--------EN2-----CE2 \ 1.2.1 / / \1.2 /-----+ / +------R4------------------------+ 1.2.2 Figure 3: Example Packet Flow in DetNet Protected Network In Figure 3 the numbers are used to identify the instance of a packet. Packet 1 is the original packet, and packets 1.1, and 1.2 are two first generation copies of packet 1. Packet 1.2.1 is a second generation copy of packet 1.2, etc. Note that these numbers never appear in the packet, and are not to be confused with sequence numbers, labels or any other identifier that appears in the packet. They simply indicate the generation number of the original packet so that its passage through the network fragment can be identified to the reader. Varga, et al. Expires November 7, 2020 [Page 11] Internet-Draft DetNet Data Plane Framework May 2020 Customer Equipment CE1 sends a packet into the DetNet enabled network. This is packet (1). Edge Node EN1 encapsulates the packet as a DetNet packet and sends it to Relay node R1 (packet 1.1). EN1 makes a copy of the packet (1.2), encapsulates it and sends this copy to Relay node R4. Note that along the path from EN1 to R1 there may be zero or more nodes which, for clarity, are not shown. The same is true for any other path between two DetNet entities shown in Figure 3. Relay node R4 has been configured to send one copy of the packet to Relay Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 1.2.2). R2 receives packet copy 1.2.1 before packet copy 1.1 arrives, and, having been configured to perform packet elimination on this DetNet flow, forwards packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of no further use and so is discarded by R2. Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives packet copy 1.2.1 from R2 via relay Node R3. EN2 therefore strips any DetNet encapsulation from packet copy 1.2.2 and forwards the packet to CE2. When EN2 receives the later packet copy 1.2.1 this is discarded. The above is of course illustrative of many network scenarios that can be configured. This example also illustrates 1:1 protection scheme meaning there is traffic over each segment of the end-to-end path. Local DetNet relay nodes determine which packets are eliminated and which packets are forwarded. A 1+1 scheme where only one path is used for traffic at a time could use the same topology. In this case there is no PRF function and traffic is switched upon detection of failure. An OAM scheme that monitors the paths to detect the loss of path or traffic is required to initiate the switch. A POF may still be used in this case to prevent misordering of packets. In both cases the protection paths are established and maintained for the duration of the DetNet service. 3.5.2.2. Path Differential Delay In the preceding example, proper working of duplicate elimination and reordering of packets are dependent on the number of out-of-order packets that can be buffered and the delay difference of arriving packets. DetNet uses flow-specific requirements (e.g., maximum number of out-of-order packets, maximum latency of the flow) for configuration of POF-related buffers. If the differential delay Varga, et al. Expires November 7, 2020 [Page 12] Internet-Draft DetNet Data Plane Framework May 2020 between paths is excessively large or there is excessive mis-ordering of the packets, then packets may be dropped instead of being reordered. Likewise, PEF uses the sequence number to identify duplicate packets, and large differential delays combined with high numbers of packets may exceed the ability of the PEF to work properly. 3.5.2.3. Ring Service Protection Ring protection may also be supported if the underlying technology supports it. Many of the same concepts apply, however rings are normally 1+1 protection for data efficiency reasons. [RFC8227] is an example of MPLS-TP data plane that supports Ring protection. 3.5.3. Aggregation Considerations The DetNet data plane also allows for the aggregation of DetNet flows, which can improve scalability by reducing the per-hop state. How this is accomplished is data plane or control plane dependent. When DetNet flows are aggregated, transit nodes provide service to the aggregate and not on a per-DetNet flow basis. When aggregating DetNet flows, the flows should be compatible, i.e., the same or very similar QoS and CoS characteristics. In this case, nodes performing aggregation will ensure that per-flow service requirements are achieved. If bandwidth reservations are used, the reservation should be the sum of all the individual reservations; in other words, the reservations should not add up to an over-subscription of bandwidth reservation. If maximum delay bounds are used, the system should ensure that the aggregate does not exceed the delay bounds of the individual flows. When an encapsulation is used, the choice of reserving a maximum resource level and then tracking the services in the aggregated service or adjusting the aggregated resources as the services are added is implementation and technology specific. DetNet flows at edges must be able to handle rejection to an aggregation group due to lack of resources as well as conditions where requirements are not satisfied. 3.5.3.1. IP Aggregation IP aggregation has both data plane and controller plane aspects. For the data plane, flows may be aggregated for treatment based on shared characteristics such as 6-tuple [I-D.ietf-detnet-ip]. Alternatively, an IP encapsulation may be used to tunnel an aggregate number of DetNet Flows between relay nodes. Varga, et al. Expires November 7, 2020 [Page 13] Internet-Draft DetNet Data Plane Framework May 2020 3.5.3.2. MPLS Aggregation MPLS aggregation also has data plane and controller plane aspects. MPLS flows are often tunneled in a forwarding sub-layer, under the reservation associated with that MPLS tunnel. 3.5.4. End-System-Specific Considerations Data-flows requiring DetNet service are generated and terminated on end-systems. Encapsulation depends on the application and its preferences. For example, in a DetNet MPLS domain the sub-layer functions use the d-CWs, S-Labels and F-Labels to provide DetNet services. However, an application may exchange further flow related parameters (e.g., time-stamp), which are not provided by DetNet functions. As a general rule, DetNet domains are capable of forwarding any DetNet flows and the DetNet domain does not mandate the end-system or edge node encapsulation format. Unless there is a proxy of some form present, end-systems peer with similar end-systems using the same application encapsulation format. For example, as shown in Figure 4, IP applications peer with IP applications and Ethernet applications peer with Ethernet applications. +-----+ | X | +-----+ +-----+ | X | | Eth | ________ +-----+ +-----+ _____ / \ | Eth | \ / \__/ \___ +-----+ \ / \ / 0======== tunnel-1 ========0_ | \ \ | 0========= tunnel-2 =========0 / \ __/ \ +-----+ \__ DetNet MPLS domain / \ | X | \ __ / +-----+ +-----+ \_______/ \_____/ | X | | IP | +-----+ +-----+ | IP | +-----+ Figure 4: End-Systems and The DetNet MPLS Domain Varga, et al. Expires November 7, 2020 [Page 14] Internet-Draft DetNet Data Plane Framework May 2020 3.5.5. Sub-Network Considerations Any of the DetNet service types may be transported by another DetNet service. MPLS nodes may be interconnected by different sub-network technologies, which may include point-to-point links. Each of these sub-network technologies needs to provide appropriate service to DetNet flows. In some cases, e.g., on dedicated point-to-point links or TDM technologies, all that is required is for a DetNet node to appropriately queue its output traffic. In other cases, DetNet nodes will need to map DetNet flows to the flow semantics (i.e., identifiers) and mechanisms used by an underlying sub-network technology. Figure 5 shows several examples of header formats that can be used to carry DetNet MPLS flows over different sub-network technologies. L2 represents a generic layer-2 encapsulation that might be used on a point-to-point link. TSN represents the encapsulation used on an IEEE 802.1 TSN network, as described in [I-D.ietf-detnet-mpls-over-tsn]. UDP/IP represents the encapsulation used on a DetNet IP PSN, as described in [I-D.ietf-detnet-mpls-over-udp-ip]. +------+ +------+ +------+ App-Flow | X | | X | | X | +-----+======+--+======+--+======+-----+ DetNet-MPLS | d-CW | | d-CW | | d-CW | +------+ +------+ +------+ |Labels| |Labels| |Labels| +-----+======+--+======+--+======+-----+ Sub-Network | L2 | | TSN | | UDP | +------+ +------+ +------+ | IP | +------+ | L2 | +------+ Figure 5: Example DetNet MPLS Sub-Network Formats 4. Controller Plane (Management and Control) Considerations 4.1. DetNet Controller Plane Requirements The Controller Plane corresponds to the aggregation of the Control and Management Planes discussed in [RFC7426] and [RFC8655]. While more details of any DetNet controller plane are out of the scope of this document, there are particular considerations and requirements for such that result from the unique characteristics of the DetNet architecture and data plane as defined herein. Varga, et al. Expires November 7, 2020 [Page 15] Internet-Draft DetNet Data Plane Framework May 2020 The primary requirements of the DetNet controller plane are that it must be able to: o Instantiate DetNet flows in a DetNet domain (which may include some or all of explicit path determination, link bandwidth reservations, restricting flows to IEEE 802.1 TSN links, node buffer and other resource reservations, specification of required queuing disciplines along the path, ability to manage bidirectional flows, etc.) as needed for a flow. o In the case of MPLS, manage DetNet S-Label and F-Label allocation and distribution, where the DetNet MPLS encapsulation is in use see [I-D.ietf-detnet-mpls]. o Support DetNet flow aggregation. o Advertise static and dynamic node and link resources such as capabilities and adjacencies to other network nodes (for dynamic signaling approaches) or to network controllers (for centralized approaches). o Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning). o Provision flow identification information at each of the nodes along the path. Flow identification may differ depending on the location in the network and the DetNet functionality (e.g. transit node vs. relay node). These requirements, as stated earlier, could be satisfied using distributed control protocol signaling (such as RSVP-TE), centralized network management provisioning mechanisms (such as BGP, PCEP, YANG [I-D.ietf-detnet-flow-information-model], etc.) or hybrid combinations of the two, and could also make use of MPLS-based segment routing. In the abstract, the results of either distributed signaling or centralized provisioning are equivalent from a DetNet data plane perspective - flows are instantiated, explicit routes are determined, resources are reserved, and packets are forwarded through the domain using the DetNet data plane. However, from a practical and implementation standpoint, controller plane alternatives are not equivalent at all. Some approaches are more scalable than others in terms of signaling load on the network. Some alternatives can take advantage of global tracking of resources in the DetNet domain for better overall network resource optimization. Some solutions are more resilient than others if link, Varga, et al. Expires November 7, 2020 [Page 16] Internet-Draft DetNet Data Plane Framework May 2020 node, or management equipment failures occur. While a detailed analysis of the control plane alternatives is out of the scope of this document, the requirements from this document can be used as the basis of a later analysis of the alternatives. 4.2. Generic Controller Plane Considerations This section covers control plane considerations that are independent of the data plane technology used for DetNet service delivery. While the management plane and control planes are traditionally considered separately, from the data plane perspective there is no practical difference based on the origin of flow provisioning information, and the DetNet architecture [RFC8655] refers to these collectively as the 'Controller Plane'. This document therefore does not distinguish between information provided by distributed control plane protocols, e.g., RSVP-TE [RFC3209] and [RFC3473], or by centralized network management mechanisms, e.g., RestConf [RFC8040], YANG [RFC7950], and the Path Computation Element Communication Protocol (PCEP) [I-D.ietf-pce-pcep-extension-for-pce-controller] or any combination thereof. Specific considerations and requirements for the DetNet Controller Plane are discussed in Section 4.1. Each respective data plane document also covers the control plane considerations for that technology. For example, [I-D.ietf-detnet-ip] covers IP control plane normative considerations and [I-D.ietf-detnet-mpls] covers MPLS control plane normative considerations. 4.2.1. Flow Aggregation Control Flow aggregation means that multiple app-flows are served by a single new DetNet flow. There are many techniques to achieve aggregation. For example, in the case of IP, IP flows that share 6-tuple attributes or flow identifiers at the DetNet sub-layer can be grouped. Another example includes aggregation accomplished through the use of hierarchical LSPs in MPLS and tunnels. Control of aggregation involves a set of procedures listed here. Aggregation may use some or all of these capabilities and the order may vary: o Traffic engineering resource collection and distribution: Available resources are tracked through control plane or management plane databases and distributed amongst controllers or nodes that can manage resources. Varga, et al. Expires November 7, 2020 [Page 17] Internet-Draft DetNet Data Plane Framework May 2020 o Path computation and resource allocation: When DetNet services are provisioned or requested, one or more paths meeting the requirements are selected and the resources verified and recorded. o Resource assignment and data plane co-ordination: The assignment of resources along the path depends on the technology and includes assignment of specific links, coordination of queueing, and other traffic management capabilities such as policing and shaping. o Assigned Resource recording and updating: Depending on the specific technology, the assigned resources are updated and distributed in the databases, preventing over- subscription. 4.2.2. Explicit Routes Explicit routes are used to ensure that packets are routed through the resources that have been reserved for them, and hence provide the DetNet application with the required service. A requirement for the DetNet Controller Plane will be the ability to assign a particular identified DetNet IP flow to a path through the DetNet domain that has been assigned the required per-node resources. This provides the appropriate traffic treatment for the flow and also includes particular links as a part of the path that are able to support the DetNet flow. For example, by using IEEE 802.1 TSN links (as discussed in [I-D.ietf-detnet-mpls-over-tsn] ) DetNet parameters can be maintained. Further considerations and requirements for the DetNet Controller Plane are discussed in Section 4.1. Whether configuring, calculating and instantiating these routes is a single-stage or multi-stage process, or in a centralized or distributed manner, is out of scope of this document. There are several approaches that could be used to provide explicit routes and resource allocation in the DetNet forwarding sub-layer. For example: o The path could be explicitly set up by a controller which calculates the path and explicitly configures each node along that path with the appropriate forwarding and resource allocation information. Varga, et al. Expires November 7, 2020 [Page 18] Internet-Draft DetNet Data Plane Framework May 2020 o The path could use a distributed control plane such as RSVP [RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP flows. o The path could be implemented using IPv6-based segment routing when extended to support resource allocation. See Section 4.1 for further discussion of these alternatives. In addition, [RFC2386] contains useful background information on QoS- based routing, and [RFC5575] (being updated by [I-D.ietf-idr-rfc5575bis]) discusses a specific mechanism used by BGP for traffic flow specification and policy-based routing. 4.2.3. Contention Loss and Jitter Reduction As discussed in Section 1, this document does not specify the mechanisms needed to eliminate packet contention, packet loss or reduce jitter for DetNet flows at the DetNet forwarding sub-layer. The ability to manage node and link resources to be able to provide these functions is a necessary part of the DetNet controller plane. It is also necessary to be able to control the required queuing mechanisms used to provide these functions along a flow's path through the network. See [I-D.ietf-detnet-ip] and Section 4.1 for further discussion of these requirements. Some forms of protection may minimize packet loss or change jitter characteristics in the cases where packets are reordered when out-of-order packets are received at the service sub-layer. 4.2.4. Bidirectional Traffic In many cases DetNet flows can be considered unidirectional and independent. However, there are cases where the DetNet service requires bidirectional traffic from a DetNet application service perspective. IP and MPLS typically treat each direction separately and do not force interdependence of each direction. MPLS has considered bidirectional traffic requirements and the MPLS definitions from [RFC5654] are useful to illustrate terms such as associated bidirectional flows and co-routed bidirectional flows. MPLS defines a point-to-point associated bidirectional LSP as consisting of two unidirectional point-to-point LSPs, one from A to B and the other from B to A, which are regarded as providing a single logical bidirectional forwarding path. This is analogous to standard IP routing. MPLS defines a point-to-point co-routed bidirectional LSP as an associated bidirectional LSP which satisfies the additional constraint that its two unidirectional component LSPs follow the same path (in terms of both nodes and links) in both directions. An important property of co-routed bidirectional LSPs is that their unidirectional component LSPs share fate. In both types of Varga, et al. Expires November 7, 2020 [Page 19] Internet-Draft DetNet Data Plane Framework May 2020 bidirectional LSPs, resource reservations may differ in each direction. The concepts of associated bidirectional flows and co- routed bidirectional flows can also be applied to DetNet IP flows. While the DetNet IP data plane must support bidirectional DetNet flows, there are no special bidirectional features with respect to the data plane other than the need for the two directions of a co- routed bidirectional flow to take the same path. That is to say that bidirectional DetNet flows are solely represented at the management and control plane levels, without specific support or knowledge within the DetNet data plane. Fate sharing and associated or co- routed bidirectional flows, can be managed at the control level. DetNet's use of PREOF may increase the complexity of using co-routing bidirectional flows, since if PREOF is used, then the replication points in one direction would have to match the elimination points in the other direction, and vice versa. In such cases the optimal points for these functions in one direction may not match the optimal points in the other, due to network and traffic constraints. Furthermore, due to the per packet service protection nature, bidirectional forwarding per packet may not be ensured. The first packet of received member flows is selected by the elimination function independently of which path it has taken through the network. Control and management mechanisms need to support bidirectional flows, but the specification of such mechanisms are out of scope of this document. Example control plane solutions for MPLS can be found in [RFC3473] , [RFC6387] and [RFC7551]. These requirements are included in Section 4.1. 4.3. Packet Replication, Elimination, and Ordering (PREOF) The controller plane protocol solution required for managing the PREOF processing is outside the scope of this document. That said, it should be noted that the ability to determine, for a particular flow, optimal packet replication and elimination points in the DetNet domain requires explicit support. There may be existing capabilities that can be used, or extended, for example GMPLS end-to-end recovery [RFC4872] and GMPLS segment recovery [RFC4873]. 5. Security Considerations Security considerations for DetNet are described in detail in [I-D.ietf-detnet-security]. General security considerations for DetNet architecture are described in [RFC8655]. This section considers architecture-level DetNet security considerations applicable to all data planes. Varga, et al. Expires November 7, 2020 [Page 20] Internet-Draft DetNet Data Plane Framework May 2020 Part of what makes DetNet unique is its ability to provide specific and reliable quality of service (delivering data flows with extremely low packet loss rates and bounded end-to-end delivery latency), and the security-related aspects of protecting that quality of service are similarly unique. As for all communications protocols, the primary consideration for the data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means is provided by the underlying technology. For example, encryption may be used, such as that provided by IPSec [RFC4301] for IP flows and/or by an underlying sub-net using MACSec [IEEE802.1AE-2018] for Ethernet (Layer-2) flows. At the management and control level DetNet flows are identified on a per-flow basis, which may provide controller plane attackers with additional information about the data flows (when compared to controller planes that do not include per-flow identification). This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet service, provisions can be made against DOS attacks and delay attacks. To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices can be prevented or mitigated, for example through the use of existing mechanisms such as policing and shaping applied at the input of a DetNet domain. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of Man-In-The- Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. In order to prevent or mitigate DetNet attacks on other networks via flow escape, edge devices can for example use existing mechanism such as policing and shaping applied at the output of a DetNet domain. 6. IANA Considerations This document makes no IANA requests. 7. Acknowledgements The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J. Bernardos for their various contributions to this work. Varga, et al. Expires November 7, 2020 [Page 21] Internet-Draft DetNet Data Plane Framework May 2020 8. Contributors The following people contributed substantially to the content of this document: Don Fedyk Jouni Korhonen 9. References 9.1. Normative References [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . 9.2. Informative References [I-D.ietf-detnet-flow-information-model] Farkas, J., Varga, B., Cummings, R., Jiang, Y., and D. Fedyk, "DetNet Flow Information Model", draft-ietf-detnet- flow-information-model-07 (work in progress), March 2020. [I-D.ietf-detnet-ip] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- ip-05 (work in progress), February 2020. [I-D.ietf-detnet-mpls] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", draft-ietf-detnet-mpls-05 (work in progress), February 2020. [I-D.ietf-detnet-mpls-over-tsn] Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over-tsn-02 (work in progress), March 2020. [I-D.ietf-detnet-mpls-over-udp-ip] Varga, B., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over UDP/IP", draft-ietf- detnet-mpls-over-udp-ip-05 (work in progress), February 2020. Varga, et al. Expires November 7, 2020 [Page 22] Internet-Draft DetNet Data Plane Framework May 2020 [I-D.ietf-detnet-security] Mizrahi, T. and E. Grossman, "Deterministic Networking (DetNet) Security Considerations", draft-ietf-detnet- security-09 (work in progress), March 2020. [I-D.ietf-idr-rfc5575bis] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", draft-ietf-idr-rfc5575bis-24 (work in progress), April 2020. [I-D.ietf-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- extension-for-pce-controller-04 (work in progress), March 2020. [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-ietf-spring-srv6-network-programming-15 (work in progress), March 2020. [IEEE802.1AE-2018] IEEE Standards Association, "IEEE Std 802.1AE-2018 MAC Security (MACsec)", 2018, . [IEEE802.1TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networking Task Group", . [nwcrg] IRTF, "Coding for efficient NetWork Communications Research Group (nwcrg)", . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . [RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, DOI 10.17487/RFC2386, August 1998, . Varga, et al. Expires November 7, 2020 [Page 23] Internet-Draft DetNet Data Plane Framework May 2020 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, . [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, January 2004, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, . [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, . [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, . Varga, et al. Expires November 7, 2020 [Page 24] Internet-Draft DetNet Data Plane Framework May 2020 [RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, September 2011, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 2017, . Authors' Addresses Balazs Varga (editor) Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: balazs.a.varga@ericsson.com Varga, et al. Expires November 7, 2020 [Page 25] Internet-Draft DetNet Data Plane Framework May 2020 Janos Farkas Ericsson Magyar Tudosok krt. 11. Budapest 1117 Hungary Email: janos.farkas@ericsson.com Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Andrew G. Malis Malis Consulting Email: agmalis@gmail.com Stewart Bryant Futurewei Technologies Email: stewart.bryant@gmail.com Varga, et al. Expires November 7, 2020 [Page 26] ./draft-ietf-isis-yang-isis-cfg-42.txt0000644000764400076440000063512213551431773017005 0ustar iustyiusty IS-IS Working Group S. Litkowski Internet-Draft Cisco Systems Intended status: Standards Track D. Yeung Expires: April 17, 2020 Arrcus, Inc A. Lindem Cisco Systems J. Zhang Juniper Networks L. Lhotka CZ.NIC October 15, 2019 YANG Data Model for IS-IS Protocol draft-ietf-isis-yang-isis-cfg-42 Abstract This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 17, 2020. Litkowski, et al. Expires April 17, 2020 [Page 1] Internet-Draft isis-cfg October 2019 Copyright Notice Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 2.1. IS-IS Configuration . . . . . . . . . . . . . . . . . . . 9 2.2. Multi-topology Parameters . . . . . . . . . . . . . . . . 10 2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10 2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 12 2.5. Authentication Parameters . . . . . . . . . . . . . . . . 19 2.6. IGP/LDP synchronization . . . . . . . . . . . . . . . . . 19 2.7. ISO parameters . . . . . . . . . . . . . . . . . . . . . 20 2.8. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.9. Operational States . . . . . . . . . . . . . . . . . . . 20 3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 21 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Interaction with Other YANG Modules . . . . . . . . . . . . . 22 6. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 108 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 110 11.2. Informative References . . . . . . . . . . . . . . . . . 115 Appendix A. Example of IS-IS configuration in XML . . . . . . . 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 1. Introduction This document defines a YANG [RFC7950] data model for IS-IS routing protocol. Litkowski, et al. Expires April 17, 2020 [Page 2] Internet-Draft isis-cfg October 2019 The data model covers configuration of an IS-IS routing protocol instance, as well as, the retrieval of IS-IS operational states. A simplified tree representation of the data model is presented in Section 2. Tree diagrams used in this document follow the notation defined in [RFC8340]. The module is designed as per the NMDA (Network Management Datastore Architecture) [RFC8342]. 2. Design of the Data Model The IS-IS YANG module augments the "control-plane-protocol" list in the ietf-routing module [RFC8349] with specific IS-IS parameters. The figure below describes the overall structure of the ietf-isis YANG module: module: ietf-isis augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: +--ro metric? uint32 +--ro tag* uint64 +--ro route-type? enumeration augment /if:interfaces/if:interface: +--rw clns-mtu? uint16 {osi-interface}? augment /rt:routing/rt:control-plane-protocols/rt: control-plane-protocol: +--rw isis +--rw enable? boolean {admin-control}? +--rw level-type? level +--rw system-id? system-id +--rw maximum-area-addresses? uint8 {maximum-area-addresses}? +--rw area-address* area-address +--rw lsp-mtu? uint16 +--rw lsp-lifetime? uint16 +--rw lsp-refresh? rt-types:timer-value-seconds16 | {lsp-refresh}? +--rw poi-tlv? boolean {poi-tlv}? +--rw graceful-restart {graceful-restart}? | +--rw enable? boolean | +--rw restart-interval? rt-types:timer-value-seconds16 | +--rw helper-enable? boolean +--rw nsr {nsr}? | +--rw enable? boolean +--rw node-tags {node-tag}? | +--rw node-tag* [tag] | ... Litkowski, et al. Expires April 17, 2020 [Page 3] Internet-Draft isis-cfg October 2019 +--rw metric-type | +--rw value? enumeration | +--rw level-1 | | ... | +--rw level-2 | ... +--rw default-metric | +--rw value? wide-metric | +--rw level-1 | | ... | +--rw level-2 | ... +--rw auto-cost {auto-cost}? | +--rw enable? boolean | +--rw reference-bandwidth? uint32 +--rw authentication | +--rw (authentication-type)? | | ... | +--rw level-1 | | ... | +--rw level-2 | ... +--rw address-families {nlpid-control}? | +--rw address-family-list* [address-family] | ... +--rw mpls | +--rw te-rid {te-rid}? | | ... | +--rw ldp | ... +--rw spf-control | +--rw paths? uint16 {max-ecmp}? | +--rw ietf-spf-delay {ietf-spf-delay}? | ... +--rw fast-reroute {fast-reroute}? | +--rw lfa {lfa}? +--rw preference | +--rw (granularity)? | ... +--rw overload | +--rw status? boolean +--rw overload-max-metric {overload-max-metric}? | +--rw timeout? rt-types:timer-value-seconds16 +--ro spf-log | +--ro event* [id] | ... +--ro lsp-log | +--ro event* [id] Litkowski, et al. Expires April 17, 2020 [Page 4] Internet-Draft isis-cfg October 2019 | ... +--ro hostnames | +--ro hostname* [system-id] | ... +--ro database | +--ro levels* [level] | ... +--ro local-rib | +--ro route* [prefix] | ... +--ro system-counters | +--ro level* [level] | ... +--ro protected-routes | +--ro address-family-stats* [address-family prefix alternate] | ... +--ro unprotected-routes | +--ro prefixes* [address-family prefix] | ... +--ro protection-statistics* [frr-protection-method] | +--ro frr-protection-method identityref | +--ro address-family-stats* [address-family] | ... +--rw discontinuity-time? yang:date-and-time +--rw topologies {multi-topology}? | +--rw topology* [name] | ... +--rw interfaces +--rw interface* [name] ... rpcs: +---x clear-adjacency | +---w input | +---w routing-protocol-instance-name -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +---w level? level | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-instance-name -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +---w level? level notifications: +---n database-overload Litkowski, et al. Expires April 17, 2020 [Page 5] Internet-Draft isis-cfg October 2019 | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro overload? enumeration +---n lsp-too-large | +--ro routing-protocol-name? -> /rt:routing/ | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-size? uint32 | +--ro lsp-id? lsp-id +---n if-state-change | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro state? if-state-type +---n corrupted-lsp-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n attempt-to-exceed-max-sequence | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n id-len-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-field-len? uint8 | +--ro raw-pdu? binary +---n max-area-addresses-mismatch | +--ro routing-protocol-name? -> /rt:routing/ Litkowski, et al. Expires April 17, 2020 [Page 6] Internet-Draft isis-cfg October 2019 | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro max-area-addresses? uint8 | +--ro raw-pdu? binary +---n own-lsp-purge | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n sequence-number-skipped | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n authentication-type-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n authentication-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n version-skew | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name Litkowski, et al. Expires April 17, 2020 [Page 7] Internet-Draft isis-cfg October 2019 | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro protocol-version? uint8 | +--ro raw-pdu? binary +---n area-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n rejected-adjacency | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro reason? string +---n protocols-supported-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro protocols* uint8 +---n lsp-error-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro raw-pdu? binary | +--ro error-offset? uint32 | +--ro tlv-type? uint8 +---n adjacency-state-change Litkowski, et al. Expires April 17, 2020 [Page 8] Internet-Draft isis-cfg October 2019 | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro neighbor? string | +--ro neighbor-system-id? system-id | +--ro state? adj-state-type | +--ro reason? string +---n lsp-received | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro sequence? uint32 | +--ro received-timestamp? yang:timestamp | +--ro neighbor-system-id? system-id +---n lsp-generation +--ro routing-protocol-name? -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +--ro isis-level? level +--ro lsp-id? lsp-id +--ro sequence? uint32 +--ro send-timestamp? yang:timestamp 2.1. IS-IS Configuration The IS-IS configuration is divided into: o Global parameters. o Per-interface configuration (see Section 2.4). Additional modules may be created to support additional parameters. These additional modules MUST augment the ietf-isis module. The model includes optional features, for which the corresponding configuration data nodes are also optional. As an example, the ability to control the administrative state of a particular IS-IS instance is optional. By advertising the feature "admin-control", a Litkowski, et al. Expires April 17, 2020 [Page 9] Internet-Draft isis-cfg October 2019 device communicates to the client that it supports the ability to shutdown a particular IS-IS instance. The global configuration contains usual IS-IS parameters, such as, lsp-mtu, lsp-lifetime, lsp-refresh, default-metric, etc. 2.2. Multi-topology Parameters The model supports multi-topology (MT) IS-IS as defined in [RFC5120]. The "topologies" container is used to enable support of the MT extensions. The "name" used in the topology list should refer to an existing Routing Information Base (RIB) defined for the device [RFC8349]. Some specific parameters can be defined on a per-topology basis, both at the global level and at the interface level: for example, an interface metric can be defined per topology. Multiple address families (such as, IPv4 or IPv6) can also be enabled within the default topology. This can be achieved using the address- families container (requiring the "nlpid-control" feature to be supported). 2.3. Per-Level Parameters Some parameters allow a per-level configuration. For such parameters, the parameter is modeled as a container with three configuration locations: o a Top-level container: Corresponds to level-1-2, so the configuration applies to both levels. o a Level-1 container: Corresponds to level-1 specific parameters. o a Level-2 container: Corresponds to level-2 specific parameters. +--rw priority | +--rw value? uint8 | +--rw level-1 | | +--rw value? uint8 | +--rw level-2 | +--rw value? uint8 Example: Litkowski, et al. Expires April 17, 2020 [Page 10] Internet-Draft isis-cfg October 2019 250 100 An implementation MUST prefer a level-specific parameter over a top- level parameter. For example, if the priority is 100 for the level-1 and 250 for the top-level configuration, the implementation must use 100 for the level-1 priority and 250 for the level-2 priority. Some parameters, such as, "overload bit" and "route preference", are not modeled to support a per-level configuration. If an implementation supports per-level configuration for such parameter, this implementation MUST augment the current model by adding both level-1 and level-2 containers and MUST reuse existing configuration groupings. Example of augmentation: augment "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol"+ "/isis:isis/isis:overload" { when "rt:type = 'isis:isis'" { description "This augment IS-IS routing protocol when used"; } description "This augments IS-IS overload configuration with per-level configuration."; container level-1 { uses isis:overload-global-cfg; description "Level 1 configuration."; } container level-2 { uses isis:overload-global-cfg; description "Level 2 configuration."; } } If an implementation does not support per-level configuration for a parameter modeled with per-level configuration, the implementation should advertise a deviation to announce the non-support of the level-1 and level-2 containers. Litkowski, et al. Expires April 17, 2020 [Page 11] Internet-Draft isis-cfg October 2019 Finally, if an implementation supports per-level configuration but does not support the level-1-2 configuration, it should also advertise a deviation. 2.4. Per-Interface Parameters The per-interface section of the IS-IS instance describes the interface-specific parameters. The interface is modeled as a reference to an existing interface defined in the "ietf-interfaces" YANG model ([RFC8343]. Each interface has some interface-specific parameters that may have a different per-level value as described in the previous section. An interface-specific parameter MUST be preferred over an IS-IS global parameter. Some parameters, such as, hello-padding are defined as containers to allow easy extension by vendor-specific modules. +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw enable? boolean {admin-control}? +--rw level-type? level +--rw lsp-pacing-interval? rt-types: | timer-value-milliseconds +--rw lsp-retransmit-interval? rt-types: | timer-value-seconds16 +--rw passive? boolean +--rw csnp-interval? rt-types: | timer-value-seconds16 +--rw hello-padding | +--rw enable? boolean +--rw mesh-group-enable? mesh-group-state +--rw mesh-group? uint8 +--rw interface-type? interface-type +--rw tag* uint32 {prefix-tag}? +--rw tag64* uint64 {prefix-tag64}? +--rw node-flag? boolean {node-flag}? +--rw hello-authentication | +--rw (authentication-type)? | | +--:(key-chain) {key-chain}? | | | +--rw key-chain? key-chain:key-chain-ref | | +--:(password) | | +--rw key? string | | +--rw crypto-algorithm? identityref | +--rw level-1 Litkowski, et al. Expires April 17, 2020 [Page 12] Internet-Draft isis-cfg October 2019 | | +--rw (authentication-type)? | | +--:(key-chain) {key-chain}? | | | +--rw key-chain? key-chain:key-chain-ref | | +--:(password) | | +--rw key? string | | +--rw crypto-algorithm? identityref | +--rw level-2 | +--rw (authentication-type)? | +--:(key-chain) {key-chain}? | | +--rw key-chain? key-chain:key-chain-ref | +--:(password) | +--rw key? string | +--rw crypto-algorithm? identityref +--rw hello-interval | +--rw value? rt-types:timer-value-seconds16 | +--rw level-1 | | +--rw value? rt-types:timer-value-seconds16 | +--rw level-2 | +--rw value? rt-types:timer-value-seconds16 +--rw hello-multiplier | +--rw value? uint16 | +--rw level-1 | | +--rw value? uint16 | +--rw level-2 | +--rw value? uint16 +--rw priority | +--rw value? uint8 | +--rw level-1 | | +--rw value? uint8 | +--rw level-2 | +--rw value? uint8 +--rw metric | +--rw value? wide-metric | +--rw level-1 | | +--rw value? wide-metric | +--rw level-2 | +--rw value? wide-metric +--rw bfd {bfd}? | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw address-families {nlpid-control}? | +--rw address-family-list* [address-family] Litkowski, et al. Expires April 17, 2020 [Page 13] Internet-Draft isis-cfg October 2019 | +--rw address-family iana-rt-types:address-family +--rw mpls | +--rw ldp | +--rw igp-sync? boolean {ldp-igp-sync}? +--rw fast-reroute {fast-reroute}? | +--rw lfa {lfa}? | +--rw candidate-enable? boolean | +--rw enable? boolean | +--rw remote-lfa {remote-lfa}? | | +--rw enable? boolean | +--rw level-1 | | +--rw candidate-enable? boolean | | +--rw enable? boolean | | +--rw remote-lfa {remote-lfa}? | | +--rw enable? boolean | +--rw level-2 | +--rw candidate-enable? boolean | +--rw enable? boolean | +--rw remote-lfa {remote-lfa}? | +--rw enable? boolean +--ro adjacencies | +--ro adjacency* [] | +--ro neighbor-sys-type? level | +--ro neighbor-sysid? system-id | +--ro neighbor-extended-circuit-id? extended-circuit-id | +--ro neighbor-snpa? snpa | +--ro usage? level | +--ro hold-timer? rt-types: | | timer-value-seconds16 | +--ro neighbor-priority? uint8 | +--ro lastuptime? yang:timestamp | +--ro state? adj-state-type +--ro event-counters | +--ro adjacency-changes? uint32 | +--ro adjacency-number? uint32 | +--ro init-fails? uint32 | +--ro adjacency-rejects? uint32 | +--ro id-len-mismatch? uint32 | +--ro max-area-addresses-mismatch? uint32 | +--ro authentication-type-fails? uint32 | +--ro authentication-fails? uint32 | +--ro lan-dis-changes? uint32 +--ro packet-counters | +--ro level* [level] | +--ro level level-number | +--ro iih | | +--ro in? uint32 | | +--ro out? uint32 Litkowski, et al. Expires April 17, 2020 [Page 14] Internet-Draft isis-cfg October 2019 | +--ro ish | | +--ro in? uint32 | | +--ro out? uint32 | +--ro esh | | +--ro in? uint32 | | +--ro out? uint32 | +--ro lsp | | +--ro in? uint32 | | +--ro out? uint32 | +--ro psnp | | +--ro in? uint32 | | +--ro out? uint32 | +--ro csnp | | +--ro in? uint32 | | +--ro out? uint32 | +--ro unknown | +--ro in? uint32 +--rw discontinuity-time? yang:date-and-time +--rw topologies {multi-topology}? +--rw topology* [name] +--rw name -> | ../../../../../../../../rt:ribs/rib/name +--rw metric +--rw value? wide-metric +--rw level-1 | +--rw value? wide-metric +--rw level-2 +--rw value? wide-metric rpcs: +---x clear-adjacency | +---w input | +---w routing-protocol-instance-name -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +---w level? level | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-instance-name -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +---w level? level notifications: +---n database-overload | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ Litkowski, et al. Expires April 17, 2020 [Page 15] Internet-Draft isis-cfg October 2019 | | control-plane-protocol/name | +--ro isis-level? level | +--ro overload? enumeration +---n lsp-too-large | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-size? uint32 | +--ro lsp-id? lsp-id +---n if-state-change | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro state? if-state-type +---n corrupted-lsp-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n attempt-to-exceed-max-sequence | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro lsp-id? lsp-id +---n id-len-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro pdu-field-len? uint8 | +--ro raw-pdu? binary +---n max-area-addresses-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name Litkowski, et al. Expires April 17, 2020 [Page 16] Internet-Draft isis-cfg October 2019 | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro max-area-addresses? uint8 | +--ro raw-pdu? binary +---n own-lsp-purge | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n sequence-number-skipped | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id +---n authentication-type-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n authentication-failure | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n version-skew | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref Litkowski, et al. Expires April 17, 2020 [Page 17] Internet-Draft isis-cfg October 2019 | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro protocol-version? uint8 | +--ro raw-pdu? binary +---n area-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary +---n rejected-adjacency | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro reason? string +---n protocols-supported-mismatch | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro raw-pdu? binary | +--ro protocols* uint8 +---n lsp-error-detected | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro raw-pdu? binary | +--ro error-offset? uint32 | +--ro tlv-type? uint8 +---n adjacency-state-change | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ Litkowski, et al. Expires April 17, 2020 [Page 18] Internet-Draft isis-cfg October 2019 | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro neighbor? string | +--ro neighbor-system-id? system-id | +--ro state? adj-state-type | +--ro reason? string +---n lsp-received | +--ro routing-protocol-name? -> /rt:routing/ | | control-plane-protocols/ | | control-plane-protocol/name | +--ro isis-level? level | +--ro interface-name? if:interface-ref | +--ro interface-level? level | +--ro extended-circuit-id? extended-circuit-id | +--ro lsp-id? lsp-id | +--ro sequence? uint32 | +--ro received-timestamp? yang:timestamp | +--ro neighbor-system-id? system-id +---n lsp-generation +--ro routing-protocol-name? -> /rt:routing/ | control-plane-protocols/ | control-plane-protocol/name +--ro isis-level? level +--ro lsp-id? lsp-id +--ro sequence? uint32 +--ro send-timestamp? yang:timestamp 2.5. Authentication Parameters The module enables authentication configuration through the IETF key- chain module [RFC8177]. The IS-IS module imports the "ietf-key- chain" module and reuses some groupings to allow global and per- interface configuration of authentication. If global authentication is configured, an implementation SHOULD authenticate PSNPs (Partial Sequence Number Packets), CSNPs (Complete Sequence Number Packets) and LSPs (Link State Packets) with the authentication parameters supplied. The authentication of HELLO PDUs (Protocol Data Units) can be activated on a per-interface basis. 2.6. IGP/LDP synchronization [RFC5443] defines a mechanism where IGP (Interior Gateway Protocol) needs to be synchronized with LDP (Label Distribution Protocol). An "ldp-igp-sync" feature has been defined in the model to support this functionality. The "mpls/ldp/igp-sync" leaf under "interface" allows Litkowski, et al. Expires April 17, 2020 [Page 19] Internet-Draft isis-cfg October 2019 activation of the functionality on a per-interface basis. The "mpls/ldp/igp-sync" container in the global configuration is intentionally empty and is not required for feature activation. The goal of this empty container is to facilitate augmentation with additional parameters, e.g., timers. 2.7. ISO parameters As the IS-IS protocol is based on the ISO protocol suite, some ISO parameters may be required. This module augments interface configuration model to support selected ISO configuration parameters. The clns-mtu can be configured for an interface. 2.8. IP FRR This YANG module supports LFA (Loop Free Alternates) [RFC5286] and remote LFA [RFC7490] as IP Fast Re-Route (FRR) techniques. The "fast-reroute" container may be augmented by other models to support other IP FRR flavors (MRT as defined in [RFC7812], TI-LFA as defined in [I-D.ietf-rtgwg-segment-routing-ti-lfa], etc.). The current version of the model supports activation of LFA and remote LFA at the interface-level only. The global "lfa" container is present but kept empty to allow augmentation with vendor-specific properties, e.g., policies. Remote LFA is considered as an extension of LFA. Remote LFA cannot be enabled if LFA is not enabled. The "candidate-enable" data leaf designates that an interface can be used as a backup. 2.9. Operational States Operational state is defined in module in various containers at various levels: o system-counters: Provides statistical information about the global system. o interface: Provides configuration state information for each interface. o adjacencies: Provides state information about current IS-IS adjacencies. Litkowski, et al. Expires April 17, 2020 [Page 20] Internet-Draft isis-cfg October 2019 o spf-log: Provides information about SPF events for an IS-IS instance. This SHOULD be implemented as a wrapping buffer. o lsp-log: Provides information about LSP events for an IS-IS instance (reception of an LSP or modification of a local LSP). This SHOULD be implemented as a wrapping buffer and the implementation MAY optionally log LSP refreshes. o local-rib: Provides the IS-IS internal routing table. o database: Provides contents of the current Link State Database. o hostnames: Provides the system-id to hostname mappings [RFC5301]. o fast-reroute: Provides IP FRR state information. 3. RPC Operations The "ietf-isis" module defines two RPC operations: o clear-database: Reset the content of a particular IS-IS database and restart database synchronization with all neighbors. o clear-adjacency: Restart a particular set of IS-IS adjacencies. 4. Notifications The "ietf-isis" module defines the following notifications: database-overload: This notification is sent when the IS-IS Node overload condition changes. lsp-too-large: This notification is sent when the system tries to propagate a PDU that is too large. if-state-change: This notification is sent when an interface's state changes. corrupted-lsp-detected: This notification is sent when the IS-IS node discovers that an LSP that was previously stored in the Link State Database, i.e., local memory, has become corrupted. attempt-to-exceed-max-sequence: This notification is sent when the system wraps the 32-bit sequence counter of an LSP. id-len-mismatch: This notification is sent when we receive a PDU with a different value for the System ID length. Litkowski, et al. Expires April 17, 2020 [Page 21] Internet-Draft isis-cfg October 2019 max-area-addresses-mismatch: This notification is sent when we receive a PDU with a different value for the Maximum Area Addresses. own-lsp-purge: This notification is sent when the system receives a PDU with its own system ID and zero age. sequence-number-skipped: This notification is sent when the system receives a PDU with its own system ID and different contents. The system has to reissue the LSP with a higher sequence number. authentication-type-failure: This notification is sent when the system receives a PDU with the wrong authentication type field. authentication-failure: This notification is sent when the system receives a PDU with the wrong authentication information. version-skew: This notification is sent when the system receives a PDU with a different protocol version number. area-mismatch: This notification is sent when the system receives a Hello PDU from an IS that does not share any area address. rejected-adjacency: This notification is sent when the system receives a Hello PDU from an IS but does not establish an adjacency for some reason. protocols-supported-mismatch: This notification is sent when the system receives a non-pseudonode LSP that has no matching protocol supported. lsp-error-detected: This notification is sent when the system receives an LSP with a parse error. adjacency-state-change: This notification is sent when an IS-IS adjacency moves to Up state or to Down state. lsp-received: This notification is sent when an LSP is received. lsp-generation: This notification is sent when an LSP is regenerated. 5. Interaction with Other YANG Modules The "isis" container augments the "/rt:routing/rt:control-plane- protocols/control-plane-protocol" container of the ietf-routing [RFC8349] module with IS-IS-specific parameters. Litkowski, et al. Expires April 17, 2020 [Page 22] Internet-Draft isis-cfg October 2019 The "isis" module augments "/if:interfaces/if:interface" defined by [RFC8343] with ISO specific parameters. The "isis" operational state container augments the "/rt:routing- state/rt:control-plane-protocols/control-plane-protocol" container of the ietf-routing module with IS-IS-specific operational states. Some IS-IS-specific route attributes are added to route objects in the ietf-routing module by augmenting "/rt:routing- state/rt:ribs/rt:rib/rt:routes/rt:route". The modules defined in this document uses some groupings from ietf- keychain [RFC8177]. The module reuses types from [RFC6991] and [RFC8294]. To support BFD for fast detection, the module relies on [I-D.ietf-bfd-yang]. 6. IS-IS YANG Module The following RFCs, drafts and external standards are not referenced in the document text but are referenced in the ietf-isis.yang module: [ISO-10589], [RFC1195], [RFC4090],[RFC5029], [RFC5130], [RFC5302], [RFC5305], [RFC5306], [RFC5307], [RFC5308], [RFC5880], [RFC5881], [RFC6119], [RFC6232], [RFC7794], [RFC7981], [RFC8570], [RFC7917], [RFC8405]. file "ietf-isis@2019-10-15.yang" module ietf-isis { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-isis"; prefix isis; import ietf-routing { prefix "rt"; reference "RFC 8349 - A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-inet-types { prefix inet; reference "RFC 6991 - Common YANG Data Types"; } import ietf-yang-types { Litkowski, et al. Expires April 17, 2020 [Page 23] Internet-Draft isis-cfg October 2019 prefix yang; reference "RFC 6991 - Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC 8343 - A YANG Data Model for Interface Management (NDMA Version)"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177 - YANG Data Model for Key Chains"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294 - Common YANG Data Types for the Routing Area"; } import iana-routing-types { prefix "iana-rt-types"; reference "RFC 8294 - Common YANG Data Types for the Routing Area"; } import ietf-bfd-types { prefix "bfd-types"; reference "RFC YYYY - YANG Data Model for Bidirectional Forwarding Detection (BFD). -- Note to RFC Editor Please replace YYYY with published RFC number for draft-ietf-bfd-yang."; } organization "IETF LSR Working Group"; contact "WG Web: WG List: Editor: Stephane Litkowski Author: Derek Yeung Litkowski, et al. Expires April 17, 2020 [Page 24] Internet-Draft isis-cfg October 2019 Author: Acee Lindem Author: Jeffrey Zhang Author: Ladislav Lhotka "; description "This YANG module defines the generic configuration and operational state for the IS-IS protocol common to all vendor implementations. It is intended that the module will be extended by vendors to define vendor-specific IS-IS configuration parameters and policies, for example, route maps or route policies. This YANG model conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8242. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-10-15 { description "Initial revision."; reference "RFC XXXX"; } /* Identities */ Litkowski, et al. Expires April 17, 2020 [Page 25] Internet-Draft isis-cfg October 2019 identity isis { base rt:routing-protocol; description "Identity for the IS-IS routing protocol."; } identity lsp-log-reason { description "Base identity for an LSP change log reason."; } identity refresh { base lsp-log-reason; description "Identity used when the LSP log reason is a refresh LSP received."; } identity content-change { base lsp-log-reason; description "Identity used when the LSP log reason is a change in the content of the LSP."; } identity frr-protection-method { description "Base identity for a Fast Reroute protection method."; } identity frr-protection-method-lfa { base frr-protection-method; description "Loop Free Alternate as defined in RFC5286."; } identity frr-protection-method-rlfa { base frr-protection-method; description "Remote Loop Free Alternate as defined in RFC7490."; } identity frr-protection-method-rsvpte { base frr-protection-method; description "RSVP-TE as defined in RFC4090."; } identity frr-protection-available-type { description "Base identity for Fast Reroute protection types provided by an alternate path."; } identity frr-protection-available-node-type { base frr-protection-available-type; description "Node protection is provided by the alternate."; } Litkowski, et al. Expires April 17, 2020 [Page 26] Internet-Draft isis-cfg October 2019 identity frr-protection-available-link-type { base frr-protection-available-type; description "Link protection is provided by the alternate."; } identity frr-protection-available-srlg-type { base frr-protection-available-type; description "SRLG protection is provided by the alternate."; } identity frr-protection-available-downstream-type { base frr-protection-available-type; description "The alternate is downstream of node in the path."; } identity frr-protection-available-other-type { base frr-protection-available-type; description "The level of protection is unknown."; } identity frr-alternate-type { description "Base identity for IP Fast Reroute alternate type."; } identity frr-alternate-type-equal-cost { base frr-alternate-type; description "ECMP alternate."; } identity frr-alternate-type-lfa { base frr-alternate-type; description "LFA alternate."; } identity frr-alternate-type-remote-lfa { base frr-alternate-type; description "Remote LFA alternate."; } identity frr-alternate-type-tunnel { base frr-alternate-type; description "Tunnel based alternate (such as, RSVP-TE or GRE)."; } identity frr-alternate-mrt { base frr-alternate-type; description "MRT alternate."; } identity frr-alternate-tilfa { base frr-alternate-type; description "TILFA alternate."; } identity frr-alternate-other { base frr-alternate-type; description "Other alternate."; Litkowski, et al. Expires April 17, 2020 [Page 27] Internet-Draft isis-cfg October 2019 } identity unidirectional-link-delay-subtlv-flag { description "Base identity for unidirectional-link-delay subTLV flags. Flags are defined in RFC8570."; } identity unidirectional-link-delay-subtlv-a-flag { base unidirectional-link-delay-subtlv-flag; description "The A bit represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is clear, the value represents steady-state link performance."; } identity min-max-unidirectional-link-delay-subtlv-flag { description "Base identity for min-max-unidirectional-link-delay subTLV flags. Flags are defined in RFC8570."; } identity min-max-unidirectional-link-delay-subtlv-a-flag { base min-max-unidirectional-link-delay-subtlv-flag; description "The A bit represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is clear, the value represents steady-state link performance."; } identity unidirectional-link-loss-subtlv-flag { description "Base identity for unidirectional-link-loss subTLV flags. Flags are defined in RFC8570."; } identity unidirectional-link-loss-subtlv-a-flag { base unidirectional-link-loss-subtlv-flag; description "The A bit represents the Anomalous (A) bit. The A bit is set when the measured value of this parameter exceeds its configured maximum threshold. Litkowski, et al. Expires April 17, 2020 [Page 28] Internet-Draft isis-cfg October 2019 The A bit is cleared when the measured value falls below its configured reuse threshold. If the A bit is clear, the value represents steady-state link performance."; } identity tlv229-flag { description "Base identity for TLV229 flags. Flags are defined in RFC5120."; } identity tlv229-overload-flag { base tlv229-flag; description "If set, the originator is overloaded, and must be avoided in path calculation."; } identity tlv229-attached-flag { base tlv229-flag; description "If set, the originator is attached to another area using the referred metric."; } identity router-capability-flag { description "Base identity for router capability flags. Flags are defined in RFC7981."; } identity router-capability-flooding-flag { base router-capability-flag; description "Quote from RFC7981: 'If the S bit is set, the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is clear, the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking'."; } identity router-capability-down-flag { base router-capability-flag; description "Quote from RFC7981: 'When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2 in to prevent TLV looping'."; } identity lsp-flag { description "Base identity for LSP attributes. Litkowski, et al. Expires April 17, 2020 [Page 29] Internet-Draft isis-cfg October 2019 Attributes are defined in ISO 10589"; } identity lsp-partitioned-flag { base lsp-flag; description "Originator partition repair supported"; } identity lsp-attached-error-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the error metric."; } identity lsp-attached-delay-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the delay metric."; } identity lsp-attached-expense-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the expense metric."; } identity lsp-attached-default-metric-flag { base lsp-flag; description "Set when originator is attached to another area using the default metric."; } identity lsp-overload-flag { base lsp-flag; description "If set, the originator is overloaded, and must be avoided in path calculation."; } identity lsp-l1system-flag { base lsp-flag; description "Set when the Intermediate System has an L1 type."; } identity lsp-l2system-flag { base lsp-flag; description "Set when the Intermediate System has an L2 type."; } /* Feature definitions */ feature osi-interface { description "Support of OSI specific parameters on an Litkowski, et al. Expires April 17, 2020 [Page 30] Internet-Draft isis-cfg October 2019 interface."; } feature poi-tlv { description "Support of Purge Originator Identification."; reference "RFC 6232 - Purge Originator Identification TLV for IS-IS"; } feature ietf-spf-delay { description "Support for IETF SPF delay algorithm."; reference "RFC 8405 - SPF Back-off algorithm for link state IGPs"; } feature bfd { description "Support for BFD detection of IS-IS neighbor reachability."; reference "RFC 5880 - Bidirectional Forwarding Detection (BFD) RFC 5881 - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"; } feature key-chain { description "Support of keychain for authentication."; reference "RFC8177 - YANG Data Model for Key Chains"; } feature node-flag { description "Support for node-flag for IS-IS prefixes."; reference "RFC7794 - IS-IS Prefix Attributes for Extended IP and IPv6 Reachability"; } feature node-tag { description "Support for node admin tag for IS-IS routing instances."; reference "RFC7917 - Advertising Node Administrative Tags in IS-IS"; } feature ldp-igp-sync { description "Support for LDP IGP synchronization."; reference "RFC5443 - LDP IGP Synchronization."; } feature fast-reroute { description "Support for IP Fast Reroute (IP-FRR)."; } feature nsr { description Litkowski, et al. Expires April 17, 2020 [Page 31] Internet-Draft isis-cfg October 2019 "Support for Non-Stop-Routing (NSR). The IS-IS NSR feature allows a router with redundant control-plane capability (e.g., dual Route-Processor (RP) cards) to maintain its state and adjacencies during planned and unplanned IS-IS instance restarts. It differs from graceful-restart or Non-Stop Forwarding (NSF) in that no protocol signaling or assistance from adjacent IS-IS neighbors is required to recover control-plane state."; } feature lfa { description "Support for Loop-Free Alternates (LFAs)."; reference "RFC5286 - Basic Specification of IP Fast-Reroute: Loop-free Alternates"; } feature remote-lfa { description "Support for Remote Loop-Free Alternates (R-LFAs)."; reference "RFC7490 - Remote Loop-Free Alternate Fast Reroute"; } feature overload-max-metric { description "Support of overload by setting all links to max metric. In IS-IS, the overload bit is usually used to signal that a node cannot be used as a transit. The overload-max-metric feature brings a similar behavior leveraging on setting all the link metrics to MAX_METRIC."; } feature prefix-tag { description "Support for 32-bit prefix tags"; reference "RFC5130 - A Policy Control Mechanism in IS-IS Using Administrative Tags"; } feature prefix-tag64 { description "Support for 64-bit prefix tags"; reference "RFC5130 - A Policy Control Mechanism in IS-IS Using Administrative Tags"; } feature auto-cost { description "Support for IS-IS interface metric computation according to a reference bandwidth."; } feature te-rid { Litkowski, et al. Expires April 17, 2020 [Page 32] Internet-Draft isis-cfg October 2019 description "Traffic-Engineering Router-ID."; reference "RFC5305 - IS-IS Extensions for Traffic Engineering RFC6119 - IPv6 Traffic Engineering in IS-IS"; } feature max-ecmp { description "Setting maximum number of ECMP paths."; } feature multi-topology { description "Support for Multiple-Topology Routing (MTR)."; reference "RFC5120 - M-IS-IS: Multi Topology Routing in IS-IS"; } feature nlpid-control { description "Support for the advertisement of a Network Layer Protocol Identifier within IS-IS configuration."; } feature graceful-restart { description "IS-IS Graceful restart support."; reference "RFC5306 - Restart Signaling in IS-IS"; } feature lsp-refresh { description "Configuration of LSP refresh interval."; } feature maximum-area-addresses { description "Support for maximum-area-addresses configuration."; } feature admin-control { description "Administrative control of the protocol state."; } /* Type definitions */ typedef circuit-id { type uint8; description "This type defines the circuit ID associated with an interface."; Litkowski, et al. Expires April 17, 2020 [Page 33] Internet-Draft isis-cfg October 2019 } typedef extended-circuit-id { type uint32; description "This type defines the extended circuit ID associated with an interface."; } typedef interface-type { type enumeration { enum broadcast { description "Broadcast interface type."; } enum point-to-point { description "Point-to-point interface type."; } } description "This type defines the type of adjacency to be established for the interface. The interface-type determines the type of hello message that is used."; } typedef level { type enumeration { enum "level-1" { description "This enum indicates L1-only capability."; } enum "level-2" { description "This enum indicates L2-only capability."; } enum "level-all" { description "This enum indicates capability for both levels."; } } default "level-all"; description "This type defines IS-IS level of an object."; } Litkowski, et al. Expires April 17, 2020 [Page 34] Internet-Draft isis-cfg October 2019 typedef adj-state-type { type enumeration { enum "up" { description "State indicates the adjacency is established."; } enum "down" { description "State indicates the adjacency is NOT established."; } enum "init" { description "State indicates the adjacency is establishing."; } enum "failed" { description "State indicates the adjacency is failed."; } } description "This type defines states of an adjacency"; } typedef if-state-type { type enumeration { enum "up" { description "Up state."; } enum "down" { description "Down state"; } } description "This type defines the state of an interface"; } typedef level-number { type uint8 { range "1 .. 2"; } description "This type defines the current IS-IS level."; } typedef lsp-id { type string { pattern Litkowski, et al. Expires April 17, 2020 [Page 35] Internet-Draft isis-cfg October 2019 '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]' +'{4}\.[0-9][0-9]-[0-9][0-9]'; } description "This type defines the IS-IS LSP ID format using a pattern. An example LSP ID is 0143.0438.AEF0.02-01"; } typedef area-address { type string { pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; } description "This type defines the area address format."; } typedef snpa { type string { length "0 .. 20"; } description "This type defines the Subnetwork Point of Attachment (SNPA) format. The SNPA should be encoded according to the rules specified for the particular type of subnetwork being used. As an example, for an ethernet subnetwork, the SNPA is encoded as a MAC address, such as, '00aa.bbcc.ddee'."; } typedef system-id { type string { pattern '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; } description "This type defines IS-IS system-id using pattern, An example system-id is 0143.0438.AEF0"; } typedef extended-system-id { type string { pattern '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.' +'[0-9][0-9]'; } description "This type defines IS-IS system-id using pattern. The extended system-id contains the pseudonode number in addition to the Litkowski, et al. Expires April 17, 2020 [Page 36] Internet-Draft isis-cfg October 2019 system-id. An example system-id is 0143.0438.AEF0.00"; } typedef wide-metric { type uint32 { range "0 .. 16777215"; } description "This type defines wide style format of IS-IS metric."; } typedef std-metric { type uint8 { range "0 .. 63"; } description "This type defines old style format of IS-IS metric."; } typedef mesh-group-state { type enumeration { enum "mesh-inactive" { description "Interface is not part of a mesh group."; } enum "mesh-set" { description "Interface is part of a mesh group."; } enum "mesh-blocked" { description "LSPs must not be flooded over this interface."; } } description "This type describes mesh group state of an interface"; } /* Grouping for notifications */ grouping notification-instance-hdr { description "Instance specific IS-IS notification data grouping"; leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; Litkowski, et al. Expires April 17, 2020 [Page 37] Internet-Draft isis-cfg October 2019 } description "Name of the IS-IS instance."; } leaf isis-level { type level; description "IS-IS level of the instance."; } } grouping notification-interface-hdr { description "Interface specific IS-IS notification data grouping"; leaf interface-name { type if:interface-ref; description "IS-IS interface name"; } leaf interface-level { type level; description "IS-IS level of the interface."; } leaf extended-circuit-id { type extended-circuit-id; description "Extended circuit-id of the interface."; } } /* Groupings for IP Fast Reroute */ grouping instance-fast-reroute-config { description "This group defines global configuration of IP Fast ReRoute (FRR)."; container fast-reroute { if-feature fast-reroute; description "This container may be augmented with global parameters for IP-FRR."; container lfa { if-feature lfa; description "This container may be augmented with global parameters for Loop-Free Alternatives (LFA). Container creation has no effect on LFA activation."; } } } Litkowski, et al. Expires April 17, 2020 [Page 38] Internet-Draft isis-cfg October 2019 grouping interface-lfa-config { leaf candidate-enable { type boolean; default "true"; description "Enable the interface to be used as backup."; } leaf enable { type boolean; default false; description "Activates LFA - Per-prefix LFA computation is assumed."; } container remote-lfa { if-feature remote-lfa; leaf enable { type boolean; default false; description "Activates Remote LFA (R-LFA)."; } description "Remote LFA configuration."; } description "Grouping for LFA interface configuration"; } grouping interface-fast-reroute-config { description "This group defines interface configuration of IP-FRR."; container fast-reroute { if-feature fast-reroute; container lfa { if-feature lfa; uses interface-lfa-config; container level-1 { uses interface-lfa-config; description "LFA level 1 config"; } container level-2 { uses interface-lfa-config; description "LFA level 2 config"; } description "LFA configuration."; } Litkowski, et al. Expires April 17, 2020 [Page 39] Internet-Draft isis-cfg October 2019 description "Interface IP Fast-reroute configuration."; } } grouping instance-fast-reroute-state { description "IPFRR state data grouping"; container protected-routes { config false; list address-family-stats { key "address-family prefix alternate"; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf prefix { type inet:ip-prefix; description "Protected prefix."; } leaf alternate { type inet:ip-address; description "Alternate next hop for the prefix."; } leaf alternate-type { type identityref { base frr-alternate-type; } description "Type of alternate."; } leaf best { type boolean; description "Is set when the alternate is the preferred one, is clear otherwise."; } leaf non-best-reason { type string { length "1..255"; } description "Information field to describe why the alternate is not best. The length should be limited to 255 unicode characters. The expected format is a single line text."; Litkowski, et al. Expires April 17, 2020 [Page 40] Internet-Draft isis-cfg October 2019 } container protection-available { leaf-list protection-types { type identityref { base frr-protection-available-type; } description "This list contains a set of protection types defined as identities. An identity must be added for each type of protection provided by the alternate. As an example, if an alternate provides SRLG, node and link protection, three identities must be added in this list: one for SRLG protection, one for node protection, one for link protection."; } description "Protection types provided by the alternate."; } leaf alternate-metric1 { type uint32; description "Metric from Point of Local Repair (PLR) to destination through the alternate path."; } leaf alternate-metric2 { type uint32; description "Metric from PLR to the alternate node"; } leaf alternate-metric3 { type uint32; description "Metric from alternate node to the destination"; } description "Per-AF protected prefix statistics."; } description "List of prefixes that are protected."; } container unprotected-routes { config false; list prefixes { key "address-family prefix"; leaf address-family { type iana-rt-types:address-family; Litkowski, et al. Expires April 17, 2020 [Page 41] Internet-Draft isis-cfg October 2019 description "Address-family"; } leaf prefix { type inet:ip-prefix; description "Unprotected prefix."; } description "Per-AF unprotected prefix statistics."; } description "List of prefixes that are not protected."; } list protection-statistics { key frr-protection-method; config false; leaf frr-protection-method { type identityref { base frr-protection-method; } description "Protection method used."; } list address-family-stats { key address-family; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf total-routes { type yang:gauge32; description "Total prefixes."; } leaf unprotected-routes { type yang:gauge32; description "Total prefixes that are not protected."; } leaf protected-routes { type yang:gauge32; description "Total prefixes that are protected."; } leaf link-protected-routes { type yang:gauge32; description "Total prefixes that are link protected."; Litkowski, et al. Expires April 17, 2020 [Page 42] Internet-Draft isis-cfg October 2019 } leaf node-protected-routes { type yang:gauge32; description "Total prefixes that are node protected."; } description "Per-AF protected prefix statistics."; } description "Global protection statistics."; } } /* Route table and local RIB groupings */ grouping local-rib { description "Local-rib - RIB for Routes computed by the local IS-IS routing instance."; container local-rib { config false; description "Local-rib."; list route { key "prefix"; description "Routes"; leaf prefix { type inet:ip-prefix; description "Destination prefix."; } container next-hops { description "Next hops for the route."; list next-hop { key "next-hop"; description "List of next hops for the route"; leaf outgoing-interface { type if:interface-ref; description "Name of the outgoing interface."; } leaf next-hop { type inet:ip-address; description "Next hop address."; } } } leaf metric { type uint32; description "Metric for this route."; Litkowski, et al. Expires April 17, 2020 [Page 43] Internet-Draft isis-cfg October 2019 } leaf level { type level-number; description "Level number for this route."; } leaf route-tag { type uint32; description "Route tag for this route."; } } } } grouping route-content { description "IS-IS protocol-specific route properties grouping."; leaf metric { type uint32; description "IS-IS metric of a route."; } leaf-list tag { type uint64; description "List of tags associated with the route. This list provides a consolidated view of both 32-bit and 64-bit tags (RFC5130) available for the prefix."; } leaf route-type { type enumeration { enum l2-intra-area { description "Level 2 internal route. As per RFC5302, the prefix is directly connected to the advertising router. It cannot be distinguished from an L1->L2 inter-area route."; } enum l1-intra-area { description "Level 1 internal route. As per RFC5302, the prefix is directly connected to the advertising router."; } enum l2-external { description "Level 2 external route. As per RFC5302, such a route is learned from other IGPs. It cannot be distinguished from an L1->L2 inter-area external route."; } enum l1-external { Litkowski, et al. Expires April 17, 2020 [Page 44] Internet-Draft isis-cfg October 2019 description "Level 1 external route. As per RFC5302, such a route is learned from other IGPs."; } enum l1-inter-area { description "These prefixes are learned via L2 routing."; } enum l1-inter-area-external { description "These prefixes are learned via L2 routing towards an l2-external route."; } } description "IS-IS route type."; } } /* Grouping definitions for configuration and ops state */ grouping adjacency-state { container adjacencies { config false; list adjacency { leaf neighbor-sys-type { type level; description "Level capability of neighboring system"; } leaf neighbor-sysid { type system-id; description "The system-id of the neighbor"; } leaf neighbor-extended-circuit-id { type extended-circuit-id; description "Circuit ID of the neighbor"; } leaf neighbor-snpa { type snpa; description "SNPA of the neighbor"; } leaf usage { type level; description "Define the level(s) activated for the adjacency. On a p2p link this might be level 1 and 2, Litkowski, et al. Expires April 17, 2020 [Page 45] Internet-Draft isis-cfg October 2019 but on a LAN, the usage will be level 1 between neighbors at level 1 or level 2 between neighbors at level 2."; } leaf hold-timer { type rt-types:timer-value-seconds16; units seconds; description "The holding time in seconds for this adjacency. This value is based on received hello PDUs and the elapsed time since receipt."; } leaf neighbor-priority { type uint8 { range "0 .. 127"; } description "Priority of the neighboring IS for becoming the DIS."; } leaf lastuptime { type yang:timestamp; description "When the adjacency most recently entered state 'up', measured in hundredths of a second since the last reinitialization of the network management subsystem. The value is 0 if the adjacency has never been in state 'up'."; } leaf state { type adj-state-type; description "This leaf describes the state of the interface."; } description "List of operational adjacencies."; } description "This container lists the adjacencies of the local node."; } description "Adjacency state"; } Litkowski, et al. Expires April 17, 2020 [Page 46] Internet-Draft isis-cfg October 2019 grouping admin-control { leaf enable { if-feature admin-control; type boolean; default "true"; description "Enable/Disable the protocol."; } description "Grouping for admin control."; } grouping ietf-spf-delay { leaf initial-delay { type rt-types:timer-value-milliseconds; units msec; description "Delay used while in QUIET state (milliseconds)."; } leaf short-delay { type rt-types:timer-value-milliseconds; units msec; description "Delay used while in SHORT_WAIT state (milliseconds)."; } leaf long-delay { type rt-types:timer-value-milliseconds; units msec; description "Delay used while in LONG_WAIT state (milliseconds)."; } leaf hold-down { type rt-types:timer-value-milliseconds; units msec; description "Timer used to consider an IGP stability period (milliseconds)."; } leaf time-to-learn { type rt-types:timer-value-milliseconds; units msec; description "Duration used to learn all the IGP events related to a single component failure (milliseconds)."; } leaf current-state { type enumeration { Litkowski, et al. Expires April 17, 2020 [Page 47] Internet-Draft isis-cfg October 2019 enum "quiet" { description "QUIET state"; } enum "short-wait" { description "SHORT_WAIT state"; } enum "long-wait" { description "LONG_WAIT state"; } } config false; description "Current SPF back-off algorithm state."; } leaf remaining-time-to-learn { type rt-types:timer-value-milliseconds; units "msec"; config false; description "Remaining time until time-to-learn timer fires."; } leaf remaining-hold-down { type rt-types:timer-value-milliseconds; units "msec"; config false; description "Remaining time until hold-down timer fires."; } leaf last-event-received { type yang:timestamp; config false; description "Time of last IGP event received"; } leaf next-spf-time { type yang:timestamp; config false; description "Time when next SPF has been scheduled."; } leaf last-spf-time { type yang:timestamp; config false; description "Time of last SPF computation."; } description "Grouping for IETF SPF delay configuration and state."; Litkowski, et al. Expires April 17, 2020 [Page 48] Internet-Draft isis-cfg October 2019 } grouping node-tag-config { description "IS-IS node tag config state."; container node-tags { if-feature node-tag; list node-tag { key tag; leaf tag { type uint32; description "Node tag value."; } description "List of tags."; } description "Container for node admin tags."; } } grouping authentication-global-cfg { choice authentication-type { case key-chain { if-feature key-chain; leaf key-chain { type key-chain:key-chain-ref; description "Reference to a key-chain."; } } case password { leaf key { type string; description "This leaf specifies the authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; Litkowski, et al. Expires April 17, 2020 [Page 49] Internet-Draft isis-cfg October 2019 } } description "Choice of authentication."; } description "Grouping for global authentication config."; } grouping metric-type-global-cfg { leaf value { type enumeration { enum wide-only { description "Advertise new metric style only (RFC5305)"; } enum old-only { description "Advertise old metric style only (RFC1195)"; } enum both { description "Advertise both metric styles"; } } description "Type of metric to be generated: - wide-only means only new metric style is generated, - old-only means that only old-style metric is generated, - both means that both are advertised. This leaf is only affecting IPv4 metrics."; } description "Grouping for global metric style config."; } grouping metric-type-global-cfg-with-default { leaf value { type enumeration { enum wide-only { description "Advertise new metric style only (RFC5305)"; } enum old-only { description "Advertise old metric style only (RFC1195)"; } enum both { description "Advertise both metric styles"; Litkowski, et al. Expires April 17, 2020 [Page 50] Internet-Draft isis-cfg October 2019 } } default wide-only; description "Type of metric to be generated: - wide-only means only new metric style is generated, - old-only means that only old-style metric is generated, - both means that both are advertised. This leaf is only affecting IPv4 metrics."; } description "Grouping for global metric style config."; } grouping default-metric-global-cfg { leaf value { type wide-metric; description "Value of the metric"; } description "Global default metric config grouping."; } grouping default-metric-global-cfg-with-default { leaf value { type wide-metric; default "10"; description "Value of the metric"; } description "Global default metric config grouping."; } grouping overload-global-cfg { leaf status { type boolean; default false; description "This leaf specifies the overload status."; } description "Grouping for overload bit config."; } grouping overload-max-metric-global-cfg { leaf timeout { type rt-types:timer-value-seconds16; Litkowski, et al. Expires April 17, 2020 [Page 51] Internet-Draft isis-cfg October 2019 units "seconds"; description "Timeout (in seconds) of the overload condition."; } description "Overload maximum metric configuration grouping"; } grouping route-preference-global-cfg { choice granularity { case detail { leaf internal { type uint8; description "Protocol preference for internal routes."; } leaf external { type uint8; description "Protocol preference for external routes."; } } case coarse { leaf default { type uint8; description "Protocol preference for all IS-IS routes."; } } description "Choice for implementation of route preference."; } description "Global route preference grouping"; } grouping hello-authentication-cfg { choice authentication-type { case key-chain { if-feature key-chain; leaf key-chain { type key-chain:key-chain-ref; description "Reference to a key-chain."; } } case password { leaf key { type string; Litkowski, et al. Expires April 17, 2020 [Page 52] Internet-Draft isis-cfg October 2019 description "Authentication key specification - The length of the key may be dependent on the cryptographic algorithm."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } description "Choice of authentication."; } description "Grouping for hello authentication."; } grouping hello-interval-cfg { leaf value { type rt-types:timer-value-seconds16; units "seconds"; description "Interval (in seconds) between successive hello messages."; } description "Interval between hello messages."; } grouping hello-interval-cfg-with-default { leaf value { type rt-types:timer-value-seconds16; units "seconds"; default 10; description "Interval (in seconds) between successive hello messages."; } description "Interval between hello messages."; } grouping hello-multiplier-cfg { leaf value { type uint16; description "Number of missed hello messages prior to declaring the adjacency down."; } Litkowski, et al. Expires April 17, 2020 [Page 53] Internet-Draft isis-cfg October 2019 description "Number of missed hello messages prior to adjacency down grouping."; } grouping hello-multiplier-cfg-with-default { leaf value { type uint16; default 3; description "Number of missed hello messages prior to declaring the adjacency down."; } description "Number of missed hello messages prior to adjacency down grouping."; } grouping priority-cfg { leaf value { type uint8 { range "0 .. 127"; } description "Priority of interface for DIS election."; } description "Interface DIS election priority grouping"; } grouping priority-cfg-with-default { leaf value { type uint8 { range "0 .. 127"; } default 64; description "Priority of interface for DIS election."; } description "Interface DIS election priority grouping"; } grouping metric-cfg { leaf value { type wide-metric; description "Metric value."; } description "Interface metric grouping"; } Litkowski, et al. Expires April 17, 2020 [Page 54] Internet-Draft isis-cfg October 2019 grouping metric-cfg-with-default { leaf value { type wide-metric; default "10"; description "Metric value."; } description "Interface metric grouping"; } grouping metric-parameters { container metric-type { uses metric-type-global-cfg-with-default; container level-1 { uses metric-type-global-cfg; description "level-1 specific configuration"; } container level-2 { uses metric-type-global-cfg; description "level-2 specific configuration"; } description "Metric style global configuration"; } container default-metric { uses default-metric-global-cfg-with-default; container level-1 { uses default-metric-global-cfg; description "level-1 specific configuration"; } container level-2 { uses default-metric-global-cfg; description "level-2 specific configuration"; } description "Default metric global configuration"; } container auto-cost { if-feature auto-cost; description "Interface Auto-cost configuration state."; leaf enable { type boolean; description "Enable/Disable interface auto-cost."; } leaf reference-bandwidth { when "../enable = 'true'" { description "Only when auto cost is enabled"; Litkowski, et al. Expires April 17, 2020 [Page 55] Internet-Draft isis-cfg October 2019 } type uint32 { range "1..4294967"; } units Mbits; description "Configure reference bandwidth used to automatically determine interface cost (Mbits). The cost is the reference bandwidth divided by the interface speed with 1 being the minimum cost."; } } description "Grouping for global metric parameters."; } grouping high-availability-parameters { container graceful-restart { if-feature graceful-restart; leaf enable { type boolean; default false; description "Enable graceful restart."; } leaf restart-interval { type rt-types:timer-value-seconds16; units "seconds"; description "Interval (in seconds) to attempt graceful restart prior to failure."; } leaf helper-enable { type boolean; default "true"; description "Enable local IS-IS router as graceful restart helper."; } description "Graceful-Restart Configuration."; } container nsr { if-feature nsr; description "Non-Stop Routing (NSR) configuration."; leaf enable { type boolean; default false; description "Enable/Disable Non-Stop Routing (NSR)."; } } Litkowski, et al. Expires April 17, 2020 [Page 56] Internet-Draft isis-cfg October 2019 description "Grouping for High Availability parameters."; } grouping authentication-parameters { container authentication { uses authentication-global-cfg; container level-1 { uses authentication-global-cfg; description "level-1 specific configuration"; } container level-2 { uses authentication-global-cfg; description "level-2 specific configuration"; } description "Authentication global configuration for both LSPs and SNPs."; } description "Grouping for authentication parameters"; } grouping address-family-parameters { container address-families { if-feature nlpid-control; list address-family-list { key address-family; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf enable { type boolean; description "Activate the address family."; } description "List of address families and whether or not they are activated."; } description "Address Family configuration"; } description "Grouping for address family parameters."; } grouping mpls-parameters { container mpls { container te-rid { if-feature te-rid; description "Stable ISIS Router IP Address used for Traffic Litkowski, et al. Expires April 17, 2020 [Page 57] Internet-Draft isis-cfg October 2019 Engineering"; leaf ipv4-router-id { type inet:ipv4-address; description "Router ID value that would be used in TLV 134."; } leaf ipv6-router-id { type inet:ipv6-address; description "Router ID value that would be used in TLV 140."; } } container ldp { container igp-sync { if-feature ldp-igp-sync; description "This container may be augmented with global parameters for igp-ldp-sync."; } description "LDP configuration."; } description "MPLS configuration"; } description "Grouping for MPLS global parameters."; } grouping lsp-parameters { leaf lsp-mtu { type uint16; units "bytes"; default 1492; description "Maximum size of an LSP PDU in bytes."; } leaf lsp-lifetime { type uint16 { range "1..65535"; } units "seconds"; description "Lifetime of the router's LSPs in seconds."; } leaf lsp-refresh { if-feature lsp-refresh; type rt-types:timer-value-seconds16; units "seconds"; description "Refresh interval of the router's LSPs in seconds."; Litkowski, et al. Expires April 17, 2020 [Page 58] Internet-Draft isis-cfg October 2019 } leaf poi-tlv { if-feature poi-tlv; type boolean; default false; description "Enable advertisement of IS-IS Purge Originator Identification TLV."; } description "Grouping for LSP global parameters."; } grouping spf-parameters { container spf-control { leaf paths { if-feature max-ecmp; type uint16 { range "1..65535"; } description "Maximum number of Equal-Cost Multi-Path (ECMP) paths."; } container ietf-spf-delay { if-feature ietf-spf-delay; uses ietf-spf-delay; description "IETF SPF delay algorithm configuration."; } description "SPF calculation control."; } description "Grouping for SPF global parameters."; } grouping instance-config { description "IS-IS global configuration grouping"; uses admin-control; leaf level-type { type level; default "level-all"; description "Level of an IS-IS node - can be level-1, level-2 or level-all."; } leaf system-id { type system-id; description "system-id of the node."; } Litkowski, et al. Expires April 17, 2020 [Page 59] Internet-Draft isis-cfg October 2019 leaf maximum-area-addresses { if-feature maximum-area-addresses; type uint8; default 3; description "Maximum areas supported."; } leaf-list area-address { type area-address; description "List of areas supported by the protocol instance."; } uses lsp-parameters; uses high-availability-parameters; uses node-tag-config; uses metric-parameters; uses authentication-parameters; uses address-family-parameters; uses mpls-parameters; uses spf-parameters; uses instance-fast-reroute-config; container preference { uses route-preference-global-cfg; description "Router preference configuration for IS-IS protocol instance route installation"; } container overload { uses overload-global-cfg; description "Router protocol instance overload state configuration"; } container overload-max-metric { if-feature overload-max-metric; uses overload-max-metric-global-cfg; description "Router protocol instance overload maximum metric advertisement configuration."; } } grouping instance-state { description "IS-IS instance operational state."; uses spf-log; Litkowski, et al. Expires April 17, 2020 [Page 60] Internet-Draft isis-cfg October 2019 uses lsp-log; uses hostname-db; uses lsdb; uses local-rib; uses system-counters; uses instance-fast-reroute-state; leaf discontinuity-time { type yang:date-and-time; description "The time of the most recent occasion at which any one or more of this IS-IS instance's counters suffered a discontinuity. If no such discontinuities have occurred since the IS-IS instance was last re-initialized, then this node contains the time the IS-IS instance was re-initialized which normally occurs when it was created."; } } grouping multi-topology-config { description "Per-topology configuration"; container default-metric { uses default-metric-global-cfg; container level-1 { uses default-metric-global-cfg; description "level-1 specific configuration"; } container level-2 { uses default-metric-global-cfg; description "level-2 specific configuration"; } description "Default metric per-topology configuration"; } uses node-tag-config; } grouping interface-config { description "Interface configuration grouping"; uses admin-control; leaf level-type { type level; default "level-all"; description "IS-IS level of the interface."; } leaf lsp-pacing-interval { type rt-types:timer-value-milliseconds; Litkowski, et al. Expires April 17, 2020 [Page 61] Internet-Draft isis-cfg October 2019 units "milliseconds"; default 33; description "Interval (in milli-seconds) between LSP transmissions."; } leaf lsp-retransmit-interval { type rt-types:timer-value-seconds16; units "seconds"; description "Interval (in seconds) between LSP retransmissions."; } leaf passive { type boolean; default "false"; description "Indicates whether the interface is in passive mode (IS-IS not running but network is advertised)."; } leaf csnp-interval { type rt-types:timer-value-seconds16; units "seconds"; default 10; description "Interval (in seconds) between CSNP messages."; } container hello-padding { leaf enable { type boolean; default "true"; description "IS-IS Hello-padding activation - enabled by default."; } description "IS-IS hello padding configuration."; } leaf mesh-group-enable { type mesh-group-state; description "IS-IS interface mesh-group state"; } leaf mesh-group { when "../mesh-group-enable = 'mesh-set'" { description "Only valid when mesh-group-enable equals mesh-set"; } type uint8; description "IS-IS interface mesh-group ID."; } Litkowski, et al. Expires April 17, 2020 [Page 62] Internet-Draft isis-cfg October 2019 leaf interface-type { type interface-type; default "broadcast"; description "Type of adjacency to be established for the interface. This dictates the type of hello messages that are used."; } leaf-list tag { if-feature prefix-tag; type uint32; description "List of tags associated with the interface."; } leaf-list tag64 { if-feature prefix-tag64; type uint64; description "List of 64-bit tags associated with the interface."; } leaf node-flag { if-feature node-flag; type boolean; default false; description "Set prefix as a node representative prefix."; } container hello-authentication { uses hello-authentication-cfg; container level-1 { uses hello-authentication-cfg; description "level-1 specific configuration"; } container level-2 { uses hello-authentication-cfg; description "level-2 specific configuration"; } description "Authentication type to be used in hello messages."; } container hello-interval { uses hello-interval-cfg-with-default; container level-1 { uses hello-interval-cfg; description "level-1 specific configuration"; } container level-2 { uses hello-interval-cfg; Litkowski, et al. Expires April 17, 2020 [Page 63] Internet-Draft isis-cfg October 2019 description "level-2 specific configuration"; } description "Interval between hello messages."; } container hello-multiplier { uses hello-multiplier-cfg-with-default; container level-1 { uses hello-multiplier-cfg; description "level-1 specific configuration"; } container level-2 { uses hello-multiplier-cfg; description "level-2 specific configuration"; } description "Hello multiplier configuration."; } container priority { must '../interface-type = "broadcast"' { error-message "Priority only applies to broadcast interfaces."; description "Check for broadcast interface."; } uses priority-cfg-with-default; container level-1 { uses priority-cfg; description "level-1 specific configuration"; } container level-2 { uses priority-cfg; description "level-2 specific configuration"; } description "Priority for DIS election."; } container metric { uses metric-cfg-with-default; container level-1 { uses metric-cfg; description "level-1 specific configuration"; } container level-2 { uses metric-cfg; description "level-2 specific configuration"; } description "Metric configuration."; } container bfd { if-feature bfd; description "BFD Client Configuration."; Litkowski, et al. Expires April 17, 2020 [Page 64] Internet-Draft isis-cfg October 2019 uses bfd-types:client-cfg-parms; reference "RFC YYYY - YANG Data Model for Bidirectional Forwarding Detection (BFD). -- Note to RFC Editor Please replace YYYY with published FC number for draft-ietf-bfd-yang."; } container address-families { if-feature nlpid-control; list address-family-list { key address-family; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } description "List of AFs."; } description "Interface address-families"; } container mpls { container ldp { leaf igp-sync { if-feature ldp-igp-sync; type boolean; default false; description "Enables IGP/LDP synchronization"; } description "LDP protocol related configuration."; } description "MPLS configuration for IS-IS interfaces"; } uses interface-fast-reroute-config; } grouping multi-topology-interface-config { description "IS-IS interface topology configuration."; container metric { uses metric-cfg; container level-1 { uses metric-cfg; description "level-1 specific configuration"; } container level-2 { uses metric-cfg; description "level-2 specific configuration"; } Litkowski, et al. Expires April 17, 2020 [Page 65] Internet-Draft isis-cfg October 2019 description "Metric IS-IS interface configuration."; } } grouping interface-state { description "IS-IS interface operational state."; uses adjacency-state; uses event-counters; uses packet-counters; leaf discontinuity-time { type yang:date-and-time; description "The time of the most recent occasion at which any one or more of this IS-IS interface's counters suffered a discontinuity. If no such discontinuities have occurred since the IS-IS interface was last re-initialized, then this node contains the time the IS-IS interface was re-initialized which normally occurs when it was created."; } } /* Grouping for the hostname database */ grouping hostname-db { container hostnames { config false; list hostname { key system-id; leaf system-id { type system-id; description "system-id associated with the hostname."; } leaf hostname { type string { length "1..255"; } description "Hostname associated with the system-id as defined in RFC5301."; } description "List of system-id/hostname associations."; } description "Hostname to system-id mapping database."; } Litkowski, et al. Expires April 17, 2020 [Page 66] Internet-Draft isis-cfg October 2019 description "Grouping for hostname to system-id mapping database."; } /* Groupings for counters */ grouping system-counters { container system-counters { config false; list level { key level; leaf level { type level-number; description "IS-IS level."; } leaf corrupted-lsps { type uint32; description "Number of corrupted in-memory LSPs detected. LSPs received from the wire with a bad checksum are silently dropped and not counted. LSPs received from the wire with parse errors are counted by lsp-errors."; } leaf authentication-type-fails { type uint32; description "Number of authentication type mismatches."; } leaf authentication-fails { type uint32; description "Number of authentication key failures."; } leaf database-overload { type uint32; description "Number of times the database has become overloaded."; } leaf own-lsp-purge { type uint32; description "Number of times a zero-aged copy of the system's own LSP is received from some other IS-IS node."; } leaf manual-address-drop-from-area { Litkowski, et al. Expires April 17, 2020 [Page 67] Internet-Draft isis-cfg October 2019 type uint32; description "Number of times a manual address has been dropped from the area."; } leaf max-sequence { type uint32; description "Number of times the system has attempted to exceed the maximum sequence number."; } leaf sequence-number-skipped { type uint32; description "Number of times a sequence number skip has occurred."; } leaf id-len-mismatch { type uint32; description "Number of times a PDU is received with a different value for the ID field length than that of the receiving system."; } leaf partition-changes { type uint32; description "Number of partition changes detected."; } leaf lsp-errors { type uint32; description "Number of LSPs with errors we have received."; } leaf spf-runs { type uint32; description "Number of times we ran SPF at this level."; } description "List of supported levels."; } description "List counters for the IS-IS protocol instance"; } description "Grouping for IS-IS system counters"; } Litkowski, et al. Expires April 17, 2020 [Page 68] Internet-Draft isis-cfg October 2019 grouping event-counters { container event-counters { config false; leaf adjacency-changes { type uint32; description "The number of times an adjacency state change has occurred on this interface."; } leaf adjacency-number { type uint32; description "The number of adjacencies on this interface."; } leaf init-fails { type uint32; description "The number of times initialization of this interface has failed. This counts events such as PPP NCP failures. Failures to form an adjacency are counted by adjacency-rejects."; } leaf adjacency-rejects { type uint32; description "The number of times an adjacency has been rejected on this interface."; } leaf id-len-mismatch { type uint32; description "The number of times an IS-IS PDU with an ID field length different from that for this system has been received on this interface."; } leaf max-area-addresses-mismatch { type uint32; description "The number of times an IS-IS PDU has been received on this interface with the max area address field differing from that of this system."; } leaf authentication-type-fails { type uint32; description "Number of authentication type mismatches."; } Litkowski, et al. Expires April 17, 2020 [Page 69] Internet-Draft isis-cfg October 2019 leaf authentication-fails { type uint32; description "Number of authentication key failures."; } leaf lan-dis-changes { type uint32; description "The number of times the DIS has changed on this interface at this level. If the interface type is point-to-point, the count is zero."; } description "IS-IS interface event counters."; } description "Grouping for IS-IS interface event counters"; } grouping packet-counters { container packet-counters { config false; list level { key level; leaf level { type level-number; description "IS-IS level."; } container iih { leaf in { type uint32; description "Received IIH PDUs."; } leaf out { type uint32; description "Sent IIH PDUs."; } description "Number of IIH PDUs received/sent."; } container ish { leaf in { type uint32; description "Received ISH PDUs."; } leaf out { type uint32; description "Sent ISH PDUs."; } Litkowski, et al. Expires April 17, 2020 [Page 70] Internet-Draft isis-cfg October 2019 description "ISH PDUs received/sent."; } container esh { leaf in { type uint32; description "Received ESH PDUs."; } leaf out { type uint32; description "Sent ESH PDUs."; } description "Number of ESH PDUs received/sent."; } container lsp { leaf in { type uint32; description "Received LSP PDUs."; } leaf out { type uint32; description "Sent LSP PDUs."; } description "Number of LSP PDUs received/sent."; } container psnp { leaf in { type uint32; description "Received PSNP PDUs."; } leaf out { type uint32; description "Sent PSNP PDUs."; } description "Number of PSNP PDUs received/sent."; } container csnp { leaf in { type uint32; description "Received CSNP PDUs."; } leaf out { type uint32; description "Sent CSNP PDUs."; } description "Number of CSNP PDUs received/sent."; } container unknown { Litkowski, et al. Expires April 17, 2020 [Page 71] Internet-Draft isis-cfg October 2019 leaf in { type uint32; description "Received unknown PDUs."; } description "Number of unknown PDUs received/sent."; } description "List of packet counter for supported levels."; } description "Packet counters per IS-IS level."; } description "Grouping for per IS-IS Level packet counters."; } /* Groupings for various log buffers */ grouping spf-log { container spf-log { config false; list event { key id; leaf id { type yang:counter32; description "Event identifier - purely internal value. It is expected the most recent events to have the bigger id number."; } leaf spf-type { type enumeration { enum full { description "Full SPF computation."; } enum route-only { description "Route reachability only SPF computation"; } } description "Type of SPF computation performed."; } leaf level { type level-number; description "IS-IS level number for SPF computation"; } leaf schedule-timestamp { type yang:timestamp; Litkowski, et al. Expires April 17, 2020 [Page 72] Internet-Draft isis-cfg October 2019 description "Timestamp of when the SPF computation was scheduled."; } leaf start-timestamp { type yang:timestamp; description "Timestamp of when the SPF computation started."; } leaf end-timestamp { type yang:timestamp; description "Timestamp of when the SPF computation ended."; } list trigger-lsp { key "lsp"; leaf lsp { type lsp-id; description "LSP ID of the LSP triggering SPF computation."; } leaf sequence { type uint32; description "Sequence number of the LSP triggering SPF computation"; } description "This list includes the LSPs that triggered the SPF computation."; } description "List of computation events - implemented as a wrapping buffer."; } description "This container lists the SPF computation events."; } description "Grouping for spf-log events."; } grouping lsp-log { container lsp-log { config false; list event { key id; Litkowski, et al. Expires April 17, 2020 [Page 73] Internet-Draft isis-cfg October 2019 leaf id { type yang:counter32; description "Event identifier - purely internal value. It is expected the most recent events to have the bigger id number."; } leaf level { type level-number; description "IS-IS level number for LSP"; } container lsp { leaf lsp { type lsp-id; description "LSP ID of the LSP."; } leaf sequence { type uint32; description "Sequence number of the LSP."; } description "LSP identification container - either the received LSP or the locally generated LSP."; } leaf received-timestamp { type yang:timestamp; description "This is the timestamp when the LSA was received. In case of local LSA update, the timestamp refers to the LSA origination time."; } leaf reason { type identityref { base lsp-log-reason; } description "Type of LSP change."; } description "List of LSP events - implemented as a wrapping buffer."; } Litkowski, et al. Expires April 17, 2020 [Page 74] Internet-Draft isis-cfg October 2019 description "This container lists the LSP log. Local LSP modifications are also included in the list."; } description "Grouping for LSP log."; } /* Groupings for the LSDB description */ /* Unknown TLV and sub-TLV description */ grouping tlv { description "Type-Length-Value (TLV)"; leaf type { type uint16; description "TLV type."; } leaf length { type uint16; description "TLV length (octets)."; } leaf value { type yang:hex-string; description "TLV value."; } } grouping unknown-tlvs { description "Unknown TLVs grouping - Used for unknown TLVs or unknown sub-TLVs."; container unknown-tlvs { description "All unknown TLVs."; list unknown-tlv { description "Unknown TLV."; uses tlv; } } } /* TLVs and sub-TLVs for prefixes */ grouping prefix-reachability-attributes { description "Grouping for extended reachability attributes of an Litkowski, et al. Expires April 17, 2020 [Page 75] Internet-Draft isis-cfg October 2019 IPv4 or IPv6 prefix."; leaf external-prefix-flag { type boolean; description "External prefix flag."; } leaf readvertisement-flag { type boolean; description "Re-advertisement flag."; } leaf node-flag { type boolean; description "Node flag."; } } grouping prefix-ipv4-source-router-id { description "Grouping for the IPv4 source router ID of a prefix advertisement."; leaf ipv4-source-router-id { type inet:ipv4-address; description "IPv4 Source router ID address."; } } grouping prefix-ipv6-source-router-id { description "Grouping for the IPv6 source router ID of a prefix advertisement."; leaf ipv6-source-router-id { type inet:ipv6-address; description "IPv6 Source router ID address."; } } grouping prefix-attributes-extension { description "Prefix extended attributes as defined in RFC7794."; uses prefix-reachability-attributes; uses prefix-ipv4-source-router-id; uses prefix-ipv6-source-router-id; } grouping prefix-ipv4-std { Litkowski, et al. Expires April 17, 2020 [Page 76] Internet-Draft isis-cfg October 2019 description "Grouping for attributes of an IPv4 standard prefix as defined in RFC1195."; leaf ip-prefix { type inet:ipv4-address; description "IPv4 prefix address"; } leaf prefix-len { type uint8; description "IPv4 prefix length (in bits)"; } leaf i-e { type boolean; description "Internal or External (I/E) Metric bit value. Set to 'false' to indicate an internal metric."; } container default-metric { leaf metric { type std-metric; description "Default IS-IS metric for IPv4 prefix"; } description "IS-IS default metric container."; } container delay-metric { leaf metric { type std-metric; description "IS-IS delay metric for IPv4 prefix"; } leaf supported { type boolean; default "false"; description "Indicates whether IS-IS delay metric is supported."; } description "IS-IS delay metric container."; } container expense-metric { leaf metric { type std-metric; description "IS-IS expense metric for IPv4 prefix"; } leaf supported { type boolean; default "false"; description "Indicates whether IS-IS expense metric is supported."; } Litkowski, et al. Expires April 17, 2020 [Page 77] Internet-Draft isis-cfg October 2019 description "IS-IS expense metric container."; } container error-metric { leaf metric { type std-metric; description "This leaf describes the IS-IS error metric value"; } leaf supported { type boolean; default "false"; description "Indicates whether IS-IS error metric is supported."; } description "IS-IS error metric container."; } } grouping prefix-ipv4-extended { description "Grouping for attributes of an IPv4 extended prefix as defined in RFC5305."; leaf up-down { type boolean; description "Value of up/down bit. Set to true when the prefix has been advertised down the hierarchy."; } leaf ip-prefix { type inet:ipv4-address; description "IPv4 prefix address"; } leaf prefix-len { type uint8; description "IPv4 prefix length (in bits)"; } leaf metric { type wide-metric; description "IS-IS wide metric value"; } leaf-list tag { type uint32; description "List of 32-bit tags associated with the IPv4 prefix."; } leaf-list tag64 { type uint64; description Litkowski, et al. Expires April 17, 2020 [Page 78] Internet-Draft isis-cfg October 2019 "List of 64-bit tags associated with the IPv4 prefix."; } uses prefix-attributes-extension; } grouping prefix-ipv6-extended { description "Grouping for attributes of an IPv6 prefix as defined in RFC5308."; leaf up-down { type boolean; description "Value of up/down bit. Set to true when the prefix has been advertised down the hierarchy."; } leaf ip-prefix { type inet:ipv6-address; description "IPv6 prefix address"; } leaf prefix-len { type uint8; description "IPv6 prefix length (in bits)"; } leaf metric { type wide-metric; description "IS-IS wide metric value"; } leaf-list tag { type uint32; description "List of 32-bit tags associated with the IPv4 prefix."; } leaf-list tag64 { type uint64; description "List of 64-bit tags associated with the IPv4 prefix."; } uses prefix-attributes-extension; } /* TLVs and sub-TLVs for neighbors */ grouping neighbor-link-attributes { description "Grouping for link attributes as defined in RFC5029"; leaf link-attributes-flags { type uint16; description Litkowski, et al. Expires April 17, 2020 [Page 79] Internet-Draft isis-cfg October 2019 "Flags for the link attributes"; } } grouping neighbor-gmpls-extensions { description "Grouping for GMPLS attributes of a neighbor as defined in RFC5307"; leaf link-local-id { type uint32; description "Local identifier of the link."; } leaf remote-local-id { type uint32; description "Remote identifier of the link."; } leaf protection-capability { type uint8; description "Describes the protection capabilities of the link. This is the value of the first octet of the sub-TLV type 20 value."; } container interface-switching-capability { description "Interface switching capabilities of the link."; leaf switching-capability { type uint8; description "Switching capability of the link."; } leaf encoding { type uint8; description "Type of encoding of the LSP being used."; } container max-lsp-bandwidths { description "Per-priority max LSP bandwidths."; list max-lsp-bandwidth { leaf priority { type uint8 { range "0 .. 7"; } description "Priority from 0 to 7."; } leaf bandwidth { type rt-types:bandwidth-ieee-float32; Litkowski, et al. Expires April 17, 2020 [Page 80] Internet-Draft isis-cfg October 2019 description "max LSP bandwidth."; } description "List of max LSP bandwidths for different priorities."; } } container tdm-specific { when "../switching-capability = 100"; description "Switching Capability-specific information applicable when switching type is TDM."; leaf minimum-lsp-bandwidth { type rt-types:bandwidth-ieee-float32; description "minimum LSP bandwidth."; } leaf indication { type uint8; description "The indication whether the interface supports Standard or Arbitrary SONET/SDH."; } } container psc-specific { when "../switching-capability >= 1 and ../switching-capability <= 4"; description "Switching Capability-specific information applicable when switching type is PSC1,PSC2,PSC3 or PSC4."; leaf minimum-lsp-bandwidth { type rt-types:bandwidth-ieee-float32; description "minimum LSP bandwidth."; } leaf mtu { type uint16; units bytes; description "Interface MTU"; } } } } grouping neighbor-extended-te-extensions { description "Grouping for TE attributes of a neighbor as defined Litkowski, et al. Expires April 17, 2020 [Page 81] Internet-Draft isis-cfg October 2019 in RFC8570"; container unidirectional-link-delay { description "Container for the average delay from the local neighbor to the remote one."; container flags { leaf-list unidirectional-link-delay-subtlv-flags { type identityref { base unidirectional-link-delay-subtlv-flag; } description "This list contains identities for the bits which are set."; } description "unidirectional-link-delay subTLV flags."; } leaf value { type uint32; units usec; description "Delay value expressed in microseconds."; } } container min-max-unidirectional-link-delay { description "Container for the min and max delay from the local neighbor to the remote one."; container flags { leaf-list min-max-unidirectional-link-delay-subtlv-flags { type identityref { base min-max-unidirectional-link-delay-subtlv-flag; } description "This list contains identities for the bits which are set."; } description "min-max-unidirectional-link-delay subTLV flags."; } leaf min-value { type uint32; units usec; description "Minimum delay value expressed in microseconds."; } leaf max-value { Litkowski, et al. Expires April 17, 2020 [Page 82] Internet-Draft isis-cfg October 2019 type uint32; units usec; description "Maximum delay value expressed in microseconds."; } } container unidirectional-link-delay-variation { description "Container for the average delay variation from the local neighbor to the remote one."; leaf value { type uint32; units usec; description "Delay variation value expressed in microseconds."; } } container unidirectional-link-loss { description "Container for the packet loss from the local neighbor to the remote one."; container flags { leaf-list unidirectional-link-loss-subtlv-flags { type identityref { base unidirectional-link-loss-subtlv-flag; } description "This list contains identities for the bits which are set."; } description "unidirectional-link-loss subTLV flags."; } leaf value { type uint32; units percent; description "Link packet loss expressed as a percentage of the total traffic sent over a configurable interval."; } } container unidirectional-link-residual-bandwidth { description "Container for the residual bandwidth from the local neighbor to the remote one."; leaf value { type rt-types:bandwidth-ieee-float32; units Bps; Litkowski, et al. Expires April 17, 2020 [Page 83] Internet-Draft isis-cfg October 2019 description "Residual bandwidth."; } } container unidirectional-link-available-bandwidth { description "Container for the available bandwidth from the local neighbor to the remote one."; leaf value { type rt-types:bandwidth-ieee-float32; units Bps; description "Available bandwidth."; } } container unidirectional-link-utilized-bandwidth { description "Container for the utilized bandwidth from the local neighbor to the remote one."; leaf value { type rt-types:bandwidth-ieee-float32; units Bps; description "Utilized bandwidth."; } } } grouping neighbor-te-extensions { description "Grouping for TE attributes of a neighbor as defined in RFC5305"; leaf admin-group { type uint32; description "Administrative group/Resource Class/Color."; } container local-if-ipv4-addrs { description "All local interface IPv4 addresses."; leaf-list local-if-ipv4-addr { type inet:ipv4-address; description "List of local interface IPv4 addresses."; } } container remote-if-ipv4-addrs { description "All remote interface IPv4 addresses."; leaf-list remote-if-ipv4-addr { Litkowski, et al. Expires April 17, 2020 [Page 84] Internet-Draft isis-cfg October 2019 type inet:ipv4-address; description "List of remote interface IPv4 addresses."; } } leaf te-metric { type uint32; description "TE metric."; } leaf max-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum bandwidth."; } leaf max-reservable-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum reservable bandwidth."; } container unreserved-bandwidths { description "All unreserved bandwidths."; list unreserved-bandwidth { leaf priority { type uint8 { range "0 .. 7"; } description "Priority from 0 to 7."; } leaf unreserved-bandwidth { type rt-types:bandwidth-ieee-float32; description "Unreserved bandwidth."; } description "List of unreserved bandwidths for different priorities."; } } } grouping neighbor-extended { description "Grouping for attributes of an IS-IS extended neighbor."; leaf neighbor-id { type extended-system-id; description "system-id of the extended neighbor."; } container instances { description "List of all adjacencies between the local system and the neighbor system-id."; list instance { Litkowski, et al. Expires April 17, 2020 [Page 85] Internet-Draft isis-cfg October 2019 key id; leaf id { type uint32; description "Unique identifier of an instance of a particular neighbor."; } leaf metric { type wide-metric; description "IS-IS wide metric for extended neighbor"; } uses neighbor-gmpls-extensions; uses neighbor-te-extensions; uses neighbor-extended-te-extensions; uses neighbor-link-attributes; uses unknown-tlvs; description "Instance of a particular adjacency."; } } } grouping neighbor { description "IS-IS standard neighbor grouping."; leaf neighbor-id { type extended-system-id; description "IS-IS neighbor system-id"; } container instances { description "List of all adjacencies between the local system and the neighbor system-id."; list instance { key id; leaf id { type uint32; description "Unique identifier of an instance of a particular neighbor."; } leaf i-e { type boolean; description "Internal or External (I/E) Metric bit value. Set to 'false' to indicate an internal metric."; } container default-metric { leaf metric { type std-metric; description "IS-IS default metric value"; Litkowski, et al. Expires April 17, 2020 [Page 86] Internet-Draft isis-cfg October 2019 } description "IS-IS default metric container"; } container delay-metric { leaf metric { type std-metric; description "IS-IS delay metric value"; } leaf supported { type boolean; default "false"; description "IS-IS delay metric supported"; } description "IS-IS delay metric container"; } container expense-metric { leaf metric { type std-metric; description "IS-IS expense metric value"; } leaf supported { type boolean; default "false"; description "IS-IS expense metric supported"; } description "IS-IS expense metric container"; } container error-metric { leaf metric { type std-metric; description "IS-IS error metric value"; } leaf supported { type boolean; default "false"; description "IS-IS error metric supported"; } description "IS-IS error metric container"; } description "Instance of a particular adjacency as defined in ISO10589."; } } } /* Top-level TLVs */ grouping tlv132-ipv4-addresses { Litkowski, et al. Expires April 17, 2020 [Page 87] Internet-Draft isis-cfg October 2019 leaf-list ipv4-addresses { type inet:ipv4-address; description "List of IPv4 addresses of the IS-IS node - IS-IS reference is TLV 132."; } description "Grouping for TLV132."; } grouping tlv232-ipv6-addresses { leaf-list ipv6-addresses { type inet:ipv6-address; description "List of IPv6 addresses of the IS-IS node - IS-IS reference is TLV 232."; } description "Grouping for TLV232."; } grouping tlv134-ipv4-te-rid { leaf ipv4-te-routerid { type inet:ipv4-address; description "IPv4 Traffic Engineering router ID of the IS-IS node - IS-IS reference is TLV 134."; } description "Grouping for TLV134."; } grouping tlv140-ipv6-te-rid { leaf ipv6-te-routerid { type inet:ipv6-address; description "IPv6 Traffic Engineering router ID of the IS-IS node - IS-IS reference is TLV 140."; } description "Grouping for TLV140."; } grouping tlv129-protocols { leaf-list protocol-supported { type uint8; description "List of supported protocols of the IS-IS node - IS-IS reference is TLV 129."; } description "Grouping for TLV129."; } grouping tlv137-hostname { leaf dynamic-hostname { type string; description Litkowski, et al. Expires April 17, 2020 [Page 88] Internet-Draft isis-cfg October 2019 "Host Name of the IS-IS node - IS-IS reference is TLV 137."; } description "Grouping for TLV137."; } grouping tlv10-authentication { container authentication { leaf authentication-type { type identityref { base key-chain:crypto-algorithm; } description "Authentication type to be used with IS-IS node."; } leaf authentication-key { type string; description "Authentication key to be used. For security reasons, the authentication key MUST NOT be presented in a clear text format in response to any request (e.g., via get, get-config)."; } description "IS-IS node authentication information container - IS-IS reference is TLV 10."; } description "Grouping for TLV10."; } grouping tlv229-mt { container mt-entries { list topology { description "List of topologies supported"; leaf mt-id { type uint16 { range "0 .. 4095"; } description "Multi-Topology identifier of topology."; } container attributes { leaf-list flags { type identityref { base tlv229-flag; } description "This list contains identities for the bits which are Litkowski, et al. Expires April 17, 2020 [Page 89] Internet-Draft isis-cfg October 2019 set."; } description "TLV 229 flags."; } } description "IS-IS node topology information container - IS-IS reference is TLV 229."; } description "Grouping for TLV229."; } grouping tlv242-router-capabilities { container router-capabilities { list router-capability { container flags { leaf-list router-capability-flags { type identityref { base router-capability-flag; } description "This list contains identities for the bits which are set."; } description "Router capability flags."; } container node-tags { if-feature node-tag; list node-tag { leaf tag { type uint32; description "Node tag value."; } description "List of tags."; } description "Container for node admin tags"; } uses unknown-tlvs; description "IS-IS node capabilities. This list element may be extended with detailed information - IS-IS reference is TLV 242."; } description "List of router capability TLVs."; Litkowski, et al. Expires April 17, 2020 [Page 90] Internet-Draft isis-cfg October 2019 } description "Grouping for TLV242."; } grouping tlv138-srlg { description "Grouping for TLV138."; container links-srlgs { list links { leaf neighbor-id { type extended-system-id; description "system-id of the extended neighbor."; } leaf flags { type uint8; description "Flags associated with the link."; } leaf link-local-id { type union { type inet:ip-address; type uint32; } description "Local identifier of the link. It could be an IPv4 address or a local identifier."; } leaf link-remote-id { type union { type inet:ip-address; type uint32; } description "Remote identifier of the link. It could be an IPv4 address or a remotely learned identifier."; } container srlgs { description "List of SRLGs."; leaf-list srlg { type uint32; description "SRLG value of the link."; } } description "SRLG attribute of a link."; } Litkowski, et al. Expires April 17, 2020 [Page 91] Internet-Draft isis-cfg October 2019 description "List of links with SRLGs"; } } /* Grouping for LSDB description */ grouping lsp-entry { description "IS-IS LSP database entry grouping"; leaf decoded-completed { type boolean; description "IS-IS LSP body fully decoded."; } leaf raw-data { type yang:hex-string; description "The hexadecimal representation of the complete LSP in network-byte order (NBO) as received or originated."; } leaf lsp-id { type lsp-id; description "LSP ID of the LSP"; } leaf checksum { type uint16; description "LSP checksum"; } leaf remaining-lifetime { type uint16; units "seconds"; description "Remaining lifetime (in seconds) until LSP expiration."; } leaf sequence { type uint32; description "This leaf describes the sequence number of the LSP."; } container attributes { leaf-list lsp-flags { type identityref { base lsp-flag; } description "This list contains identities for the bits which are set."; } Litkowski, et al. Expires April 17, 2020 [Page 92] Internet-Draft isis-cfg October 2019 description "LSP attributes."; } uses tlv132-ipv4-addresses; uses tlv232-ipv6-addresses; uses tlv134-ipv4-te-rid; uses tlv140-ipv6-te-rid; uses tlv129-protocols; uses tlv137-hostname; uses tlv10-authentication; uses tlv229-mt; uses tlv242-router-capabilities; uses tlv138-srlg; uses unknown-tlvs; container is-neighbor { list neighbor { key neighbor-id; uses neighbor; description "List of neighbors."; } description "Standard IS neighbors container - IS-IS reference is TLV 2."; } container extended-is-neighbor { list neighbor { key neighbor-id; uses neighbor-extended; description "List of extended IS neighbors"; } description "Standard IS extended neighbors container - IS-IS reference is TLV 22"; } container ipv4-internal-reachability { list prefixes { uses prefix-ipv4-std; description "List of prefixes."; } description "IPv4 internal reachability information container - IS-IS reference is TLV 128."; Litkowski, et al. Expires April 17, 2020 [Page 93] Internet-Draft isis-cfg October 2019 } container ipv4-external-reachability { list prefixes { uses prefix-ipv4-std; description "List of prefixes."; } description "IPv4 external reachability information container - IS-IS reference is TLV 130."; } container extended-ipv4-reachability { list prefixes { uses prefix-ipv4-extended; uses unknown-tlvs; description "List of prefixes."; } description "IPv4 extended reachability information container - IS-IS reference is TLV 135."; } container mt-is-neighbor { list neighbor { leaf mt-id { type uint16 { range "0 .. 4095"; } description "Multi-topology (MT) identifier"; } uses neighbor-extended; description "List of neighbors."; } description "IS-IS multi-topology neighbor container - IS-IS reference is TLV 223."; } container mt-extended-ipv4-reachability { list prefixes { leaf mt-id { type uint16 { range "0 .. 4095"; } description "Multi-topology (MT) identifier"; } uses prefix-ipv4-extended; Litkowski, et al. Expires April 17, 2020 [Page 94] Internet-Draft isis-cfg October 2019 uses unknown-tlvs; description "List of extended prefixes."; } description "IPv4 multi-topology (MT) extended reachability information container - IS-IS reference is TLV 235."; } container mt-ipv6-reachability { list prefixes { leaf MT-ID { type uint16 { range "0 .. 4095"; } description "Multi-topology (MT) identifier"; } uses prefix-ipv6-extended; uses unknown-tlvs; description "List of IPv6 extended prefixes."; } description "IPv6 multi-topology (MT) extended reachability information container - IS-IS reference is TLV 237."; } container ipv6-reachability { list prefixes { uses prefix-ipv6-extended; uses unknown-tlvs; description "List of IPv6 prefixes."; } description "IPv6 reachability information container - IS-IS reference is TLV 236."; } } grouping lsdb { description "Link State Database (LSDB) grouping"; container database { config false; list levels { key level; leaf level { type level-number; description "LSDB level number (1 or 2)"; } Litkowski, et al. Expires April 17, 2020 [Page 95] Internet-Draft isis-cfg October 2019 list lsp { key lsp-id; uses lsp-entry; description "List of LSPs in LSDB"; } description "List of LSPs for the LSDB level container"; } description "IS-IS Link State database container"; } } /* Augmentations */ augment "/rt:routing/" +"rt:ribs/rt:rib/rt:routes/rt:route" { when "rt:source-protocol = 'isis:isis'" { description "IS-IS-specific route attributes."; } uses route-content; description "This augments route object in RIB with IS-IS-specific attributes."; } augment "/if:interfaces/if:interface" { leaf clns-mtu { if-feature osi-interface; type uint16; description "CLNS MTU of the interface"; } description "ISO specific interface parameters."; } augment "/rt:routing/rt:control-plane-protocols/" +"rt:control-plane-protocol" { when "rt:type = 'isis:isis'" { description "This augment is only valid when routing protocol instance type is 'isis'"; } description "This augments a routing protocol instance with IS-IS specific parameters."; container isis { Litkowski, et al. Expires April 17, 2020 [Page 96] Internet-Draft isis-cfg October 2019 must "count(area-address) > 0" { error-message "At least one area-address must be configured."; description "Enforce configuration of at least one area."; } uses instance-config; uses instance-state; container topologies { if-feature multi-topology; list topology { key "name"; leaf enable { type boolean; description "Topology enable configuration"; } leaf name { type leafref { path "../../../../../../rt:ribs/rt:rib/rt:name"; } description "Routing Information Base (RIB) corresponding to topology."; } uses multi-topology-config; description "List of topologies"; } description "Multi-topology container"; } container interfaces { list interface { key "name"; leaf name { type if:interface-ref; description "Reference to the interface within the routing-instance."; } uses interface-config; uses interface-state; container topologies { if-feature multi-topology; list topology { Litkowski, et al. Expires April 17, 2020 [Page 97] Internet-Draft isis-cfg October 2019 key name; leaf name { type leafref { path "../../../../../../../../"+ "rt:ribs/rt:rib/rt:name"; } description "Routing Information Base (RIB) corresponding to topology."; } uses multi-topology-interface-config; description "List of interface topologies"; } description "Multi-topology container"; } description "List of IS-IS interfaces."; } description "IS-IS interface specific configuration container"; } description "IS-IS configuration/state top-level container"; } } /* RPC methods */ rpc clear-adjacency { description "This RPC request clears a particular set of IS-IS adjacencies. If the operation fails due to an internal reason, then the error-tag and error-app-tag should be set indicating the reason for the failure."; input { leaf routing-protocol-instance-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "Name of the IS-IS protocol instance whose IS-IS adjacency is being cleared. Litkowski, et al. Expires April 17, 2020 [Page 98] Internet-Draft isis-cfg October 2019 If the corresponding IS-IS instance doesn't exist, then the operation will fail with an error-tag of 'data-missing' and an error-app-tag of 'routing-protocol-instance-not-found'."; } leaf level { type level; description "IS-IS level of the adjacency to be cleared. If the IS-IS level is level-1-2, both level 1 and level 2 adjacencies would be cleared. If the value provided is different from the one authorized in the enum type, then the operation SHALL fail with an error-tag of 'data-missing' and an error-app-tag of 'bad-isis-level'."; } leaf interface { type if:interface-ref; description "IS-IS interface name. If the corresponding IS-IS interface doesn't exist, then the operation SHALL fail with an error-tag of 'data-missing' and an error-app-tag of 'isis-interface-not-found'."; } } } rpc clear-database { description "This RPC request clears a particular IS-IS database. If the operation fails for an IS-IS internal reason, then the error-tag and error-app-tag should be set indicating the reason for the failure."; input { leaf routing-protocol-instance-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "Name of the IS-IS protocol instance whose IS-IS database(s) is/are being cleared. If the corresponding IS-IS instance doesn't exist, Litkowski, et al. Expires April 17, 2020 [Page 99] Internet-Draft isis-cfg October 2019 then the operation will fail with an error-tag of 'data-missing' and an error-app-tag of 'routing-protocol-instance-not-found'."; } leaf level { type level; description "IS-IS level of the adjacency to be cleared. If the IS-IS level is level-1-2, both level 1 and level 2 databases would be cleared. If the value provided is different from the one authorized in the enum type, then the operation SHALL fail with an error-tag of 'data-missing' and an error-app-tag of 'bad-isis-level'."; } } } /* Notifications */ notification database-overload { uses notification-instance-hdr; leaf overload { type enumeration { enum off { description "Indicates IS-IS instance has left overload state"; } enum on { description "Indicates IS-IS instance has entered overload state"; } } description "New overload state of the IS-IS instance"; } description "This notification is sent when an IS-IS instance overload state changes."; } notification lsp-too-large { uses notification-instance-hdr; uses notification-interface-hdr; Litkowski, et al. Expires April 17, 2020 [Page 100] Internet-Draft isis-cfg October 2019 leaf pdu-size { type uint32; description "Size of the LSP PDU"; } leaf lsp-id { type lsp-id; description "LSP ID"; } description "This notification is sent when we attempt to propagate an LSP that is larger than the dataLinkBlockSize (ISO10589) for the circuit. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification if-state-change { uses notification-instance-hdr; uses notification-interface-hdr; leaf state { type if-state-type; description "Interface state."; } description "This notification is sent when an interface state change is detected."; } notification corrupted-lsp-detected { uses notification-instance-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } description "This notification is sent when we find that an LSP that was stored in memory has become corrupted."; } notification attempt-to-exceed-max-sequence { uses notification-instance-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } description Litkowski, et al. Expires April 17, 2020 [Page 101] Internet-Draft isis-cfg October 2019 "This notification is sent when the system wraps the 32-bit sequence counter of an LSP."; } notification id-len-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf pdu-field-len { type uint8; description "Size of the ID length in the received PDU"; } leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when we receive a PDU with a different value for the system-id length. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification max-area-addresses-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf max-area-addresses { type uint8; description "Received number of supported areas"; } leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when we receive a PDU with a different value for the Maximum Area Addresses. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification own-lsp-purge { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { Litkowski, et al. Expires April 17, 2020 [Page 102] Internet-Draft isis-cfg October 2019 type lsp-id; description "LSP ID"; } description "This notification is sent when the system receives a PDU with its own system-id and zero age."; } notification sequence-number-skipped { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } description "This notification is sent when the system receives a PDU with its own system-id and different contents. The system has to originate the LSP with a higher sequence number."; } notification authentication-type-failure { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a PDU with the wrong authentication type field. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification authentication-failure { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a PDU with the wrong authentication information. The notification generation must be throttled Litkowski, et al. Expires April 17, 2020 [Page 103] Internet-Draft isis-cfg October 2019 with at least 5 seconds between successive notifications."; } notification version-skew { uses notification-instance-hdr; uses notification-interface-hdr; leaf protocol-version { type uint8; description "Protocol version received in the PDU."; } leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a PDU with a different protocol version number. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification area-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } description "This notification is sent when the system receives a Hello PDU from an IS that does not share any area address. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification rejected-adjacency { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } leaf reason { type string { Litkowski, et al. Expires April 17, 2020 [Page 104] Internet-Draft isis-cfg October 2019 length "0..255"; } description "The system may provide a reason to reject the adjacency. If the reason is not available, the reason string will not be returned. The expected format is a single line text."; } description "This notification is sent when the system receives a Hello PDU from an IS but does not establish an adjacency for some reason. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification protocols-supported-mismatch { uses notification-instance-hdr; uses notification-interface-hdr; leaf raw-pdu { type binary; description "Received raw PDU."; } leaf-list protocols { type uint8; description "List of protocols supported by the remote system."; } description "This notification is sent when the system receives a non-pseudonode LSP that has no matching protocols supported. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification lsp-error-detected { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { type lsp-id; description "LSP ID."; } leaf raw-pdu { type binary; description "Received raw PDU."; } Litkowski, et al. Expires April 17, 2020 [Page 105] Internet-Draft isis-cfg October 2019 leaf error-offset { type uint32; description "If the problem is a malformed TLV, the error-offset points to the start of the TLV. If the problem is with the LSP header, the error-offset points to the errant byte"; } leaf tlv-type { type uint8; description "If the problem is a malformed TLV, the tlv-type is set to the type value of the suspicious TLV. Otherwise, this leaf is not present."; } description "This notification is sent when the system receives an LSP with a parse error. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification adjacency-state-change { uses notification-instance-hdr; uses notification-interface-hdr; leaf neighbor { type string { length "1..255"; } description "Name of the neighbor. It corresponds to the hostname associated with the system-id of the neighbor in the mapping database (RFC5301). If the name of the neighbor is not available, it is not returned."; } leaf neighbor-system-id { type system-id; description "Neighbor system-id"; } leaf state { type adj-state-type; description "New state of the IS-IS adjacency."; } leaf reason { type string { Litkowski, et al. Expires April 17, 2020 [Page 106] Internet-Draft isis-cfg October 2019 length "1..255"; } description "If the adjacency is going to DOWN, this leaf provides a reason for the adjacency going down. The reason is provided as a text. If the adjacency is going to UP, no reason is provided. The expected format is a single line text."; } description "This notification is sent when an IS-IS adjacency moves to Up state or to Down state."; } notification lsp-received { uses notification-instance-hdr; uses notification-interface-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } leaf sequence { type uint32; description "Sequence number of the received LSP."; } leaf received-timestamp { type yang:timestamp; description "Timestamp when the LSP was received."; } leaf neighbor-system-id { type system-id; description "Neighbor system-id of LSP sender"; } description "This notification is sent when an LSP is received. The notification generation must be throttled with at least 5 seconds between successive notifications."; } notification lsp-generation { uses notification-instance-hdr; leaf lsp-id { type lsp-id; description "LSP ID"; } Litkowski, et al. Expires April 17, 2020 [Page 107] Internet-Draft isis-cfg October 2019 leaf sequence { type uint32; description "Sequence number of the received LSP."; } leaf send-timestamp { type yang:timestamp; description "Timestamp when our LSP was regenerated."; } description "This notification is sent when an LSP is regenerated. The notification generation must be throttled with at least 5 seconds between successive notifications."; } } 7. Security Considerations The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre- configured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in ietf-isis.yang module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Writable data node represent configuration of each instance and interface. These correspond to the following schema nodes: /isis /isis/interfaces/interface[name] For IS-IS, the ability to modify IS-IS configuration will allow the entire IS-IS domain to be compromised including forming adjacencies with unauthorized routers to misroute traffic or mount a massive Litkowski, et al. Expires April 17, 2020 [Page 108] Internet-Draft isis-cfg October 2019 Denial-of-Service (DoS) attack. For example, adding IS-IS on any unprotected interface could allow an IS-IS adjacency to be formed with an unauthorized and malicious neighbor. Once an adjacency is formed, traffic could be hijacked. As a simpler example, a Denial- Of-Service attack could be mounted by changing the cost of an IS-IS interface to be asymmetric such that a hard routing loop ensues. In general, unauthorized modification of most IS-IS features will pose their own set of security risks and the "Security Considerations" in the respective reference RFCs should be consulted. Some of the readable data nodes in the ietf-isis.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The exposure of the Link State Database (LSDB) will expose the detailed topology of the network. Similarly, the IS-IS local RIB exposes the reachable prefixes in the IS-IS routing domain. The Link State Database (LSDB) and local RIB are represented by the following schema nodes: /isis/database /isis/local-rib Exposure of the Link State Database and local RIB include information beyond the scope of the IS-IS router and this may be undesirable since exposure may facilitate other attacks. Additionally, the complete IP network topology and, if deployed, the traffic engineering topology of the IS-IS domain can be reconstructed from the Link State Database. Though not as straightforward, the IS-IS local RIB can also be discover topological information. Network operators may consider their topologies to be sensitive confidential data. For IS-IS authentication, configuration is supported via the specification of key-chain [RFC8177] or the direct specification of key and authentication algorithm. Hence, authentication configuration using the "auth-table-trailer" case in the "authentication" container inherits the security considerations of [RFC8177]. This includes the considerations with respect to the local storage and handling of authentication keys. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. The IS-IS YANG module support the "clear-adjacency" and "clear-database" RPCs. If access to either of these is compromised, they can result in temporary network outages be employed to mount DoS attacks. Litkowski, et al. Expires April 17, 2020 [Page 109] Internet-Draft isis-cfg October 2019 The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties; compromise of the key data would allow an attacker to forge IS-IS traffic that would be accepted as authentic, potentially compromising the entirety IS-IS domain. The model describes several notifications, implementations must rate- limit the generation of these notifications to avoid creating significant notification load. Otherwise, this notification load may have some side effects on the system stability and may be exploited as an attack vector. 8. Contributors The authors would like to thank Kiran Agrahara Sreenivasa, Dean Bogdanovic, Yingzhen Qu, Yi Yang, Jeff Tanstura for their major contributions to the draft. 9. Acknowledgements The authors would like to thank Tom Petch, Alvaro Retana, Stewart Bryant, Barry Leiba, Benjamin Kaduk and Adam Roach, and Roman Danyliw for their review and comments. 10. IANA Considerations The IANA is requested to assign two new URIs from the IETF XML registry [RFC3688]. Authors are suggesting the following URI: URI: urn:ietf:params:xml:ns:yang:ietf-isis Registrant Contact: The IESG XML: N/A, the requested URI is an XML namespace This document also requests one new YANG module name in the YANG Module Names registry [RFC6020] with the following suggestion: name: ietf-isis namespace: urn:ietf:params:xml:ns:yang:ietf-isis prefix: isis reference: RFC XXXX 11. References 11.1. Normative References Litkowski, et al. Expires April 17, 2020 [Page 110] Internet-Draft isis-cfg October 2019 [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. [ISO-10589] "Intermediate System to Intermediate System intra- domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589: 2002, Second Edition, 2002. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, . [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, September 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, . Litkowski, et al. Expires April 17, 2020 [Page 111] Internet-Draft isis-cfg October 2019 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, . [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, . [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, DOI 10.17487/RFC5302, October 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, . [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Litkowski, et al. Expires April 17, 2020 [Page 112] Internet-Draft isis-cfg October 2019 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, . [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., and B. Decraene, "Advertising Node Administrative Tags in IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . Litkowski, et al. Expires April 17, 2020 [Page 113] Internet-Draft isis-cfg October 2019 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, DOI 10.17487/RFC8405, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Litkowski, et al. Expires April 17, 2020 [Page 114] Internet-Draft isis-cfg October 2019 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, . 11.2. Informative References [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", draft-ietf-rtgwg-segment-routing-ti- lfa-01 (work in progress), March 2019. [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . Appendix A. Example of IS-IS configuration in XML This section gives an example of configuration of an IS-IS instance on a device. The example is written in XML. SLI 192.0.2.1 ISIS-example isis:isis true level-2 87FC.FCDF.4432 49.0001 Litkowski, et al. Expires April 17, 2020 [Page 115] Internet-Draft isis-cfg October 2019 192.0.2.1 65535 65000 wide-only 111111 ipv4 true ipv6 true Loopback0 200 0 true Eth1 level-2 point-to-point 167890 Loopback0 Litkowski, et al. Expires April 17, 2020 [Page 116] Internet-Draft isis-cfg October 2019 ianaift:softwareLoopback enabled
192.0.2.1 32
2001:DB8::1 128
Eth1 ianaift:ethernetCsmacd enabled
198.51.100.1 30
2001:DB8:0:0:FF::1 64
Authors' Addresses Stephane Litkowski Cisco Systems Email: slitkows.ietf@gmail.com Litkowski, et al. Expires April 17, 2020 [Page 117] Internet-Draft isis-cfg October 2019 Derek Yeung Arrcus, Inc Email: derek@arrcus.com Acee Lindem Cisco Systems Email: acee@cisco.com Jeffrey Zhang Juniper Networks Email: zzhang@juniper.net Ladislav Lhotka CZ.NIC Email: lhotka@nic.cz Litkowski, et al. Expires April 17, 2020 [Page 118] ./draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt0000644000764400076440000021071713505177025021257 0ustar iustyiusty Inter-Domain Routing S. Previdi Internet-Draft Huawei Technologies Intended status: Standards Track K. Talaulikar, Ed. Expires: December 29, 2019 C. Filsfils Cisco Systems, Inc. H. Gredler RtBrick Inc. M. Chen Huawei Technologies June 27, 2019 BGP Link-State extensions for Segment Routing draft-ietf-idr-bgp-ls-segment-routing-ext-16 Abstract Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. This document defines extensions to the BGP Link-state address-family in order to carry segment routing information via BGP. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Previdi, et al. Expires December 29, 2019 [Page 1] Internet-Draft BGP LS extensions for Segment Routing June 2019 This Internet-Draft will expire on December 29, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 5 2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5 2.1.1. SID/Label TLV . . . . . . . . . . . . . . . . . . . . 5 2.1.2. SR Capabilities TLV . . . . . . . . . . . . . . . . . 6 2.1.3. SR Algorithm TLV . . . . . . . . . . . . . . . . . . 8 2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8 2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 10 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 11 2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 11 2.2.2. LAN Adjacency SID TLV . . . . . . . . . . . . . . . . 12 2.2.3. L2 Bundle Member Attribute TLV . . . . . . . . . . . 14 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 16 2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 17 2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 18 2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 19 2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 19 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 21 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 22 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 3.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 25 4. Manageability Considerations . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Previdi, et al. Expires December 29, 2019 [Page 2] Internet-Draft BGP LS extensions for Segment Routing June 2019 1. Introduction Segment Routing (SR) allows for a flexible definition of end-to-end paths by combining sub-paths called "segments". A segment can represent any instruction: topological or service-based. A segment can have a local semantic to an SR node or global semantic within a domain. Within IGP topologies, an SR path is encoded as a sequence of topological sub-paths, called "IGP segments". These segments are advertised by the link-state routing protocols (IS-IS, OSPFv2 and OSPFv3). [RFC8402] defines the Link-State IGP segments - Prefix, Node, Anycast and Adjacency segments. Prefix segments, by default, represent an ECMP-aware shortest-path to a prefix, as per the state of the IGP topology. Adjacency segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one-hop path. Node and anycast segments are variations of the prefix segment with their specific characteristics. When Segment Routing is enabled in an IGP domain, segments are advertised in the form of Segment Identifiers (SIDs). The IGP link- state routing protocols have been extended to advertise SIDs and other SR-related information. IGP extensions are described for: IS- IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these extensions, Segment Routing can be enabled within an IGP domain. Segment Routing (SR) allows advertisement of single or multi-hop paths. The flooding scope for the IGP extensions for Segment routing is IGP area-wide. Consequently, the contents of a Link State Database (LSDB) or a Traffic Engineering Database (TED) has the scope of an IGP area and therefore, by using the IGP alone it is not enough to construct segments across multiple IGP Area or AS boundaries. In order to address the need for applications that require topological visibility across IGP areas, or even across Autonomous Systems (AS), the BGP-LS address-family/sub-address-family have been defined to allow BGP to carry Link-State information. The BGP Network Layer Reachability Information (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are defined in [RFC7752]. The identifying key of each Link-State object, namely a node, link, or prefix, is encoded in the NLRI and the properties of the object are encoded in the BGP-LS attribute. Previdi, et al. Expires December 29, 2019 [Page 3] Internet-Draft BGP LS extensions for Segment Routing June 2019 +------------+ | Consumer | +------------+ ^ | v +-------------------+ | BGP Speaker | +-----------+ | (Route-Reflector) | | Consumer | +-------------------+ +-----------+ ^ ^ ^ ^ | | | | +---------------+ | +-------------------+ | | | | | v v v v +-----------+ +-----------+ +-----------+ | BGP | | BGP | | BGP | | Speaker | | Speaker | . . . | Speaker | +-----------+ +-----------+ +-----------+ ^ ^ ^ | | | IGP IGP IGP Figure 1: Link State info collection Figure 1 denotes a typical deployment scenario. In each IGP area, one or more nodes are configured with BGP-LS. These BGP speakers form an IBGP mesh by connecting to one or more route-reflectors. This way, all BGP speakers (specifically the route-reflectors) obtain Link-State information from all IGP areas (and from other ASes from EBGP peers). An external component connects to the route-reflector to obtain this information (perhaps moderated by a policy regarding what information is or isn't advertised to the external component) as described in [RFC7752]. This document describes extensions to BGP-LS to advertise the SR information. An external component (e.g., a controller) can collect SR information from across an SR domain (as described in [RFC8402]) and construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end- to-end forwarding. SR operates within a trusted domain consisting of a single or multiple ASes managed by the same administrative entity e.g. within a single provider network. Previdi, et al. Expires December 29, 2019 [Page 4] Internet-Draft BGP LS extensions for Segment Routing June 2019 2. BGP-LS Extensions for Segment Routing This document defines SR extensions to BGP-LS and specifies the TLVs and sub-TLVs for advertising SR information within the BGP-LS Attribute. Section 2.4 and Section 2.5 lists the equivalent TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link NLRI or a Prefix NLRI. BGP-LS [RFC7752] defines the TLVs that map link-state information to BGP-LS NLRI within the BGP-LS Attribute. This document adds additional BGP-LS Attribute TLVs in order to encode SR information. It does not introduce any changes to the encoding of the BGP-LS NLRIs. 2.1. Node Attributes TLVs The following Node Attribute TLVs are defined: +------+-----------------+---------------+ | Type | Description | Section | +------+-----------------+---------------+ | 1161 | SID/Label | Section 2.1.1 | | 1034 | SR Capabilities | Section 2.1.2 | | 1035 | SR Algorithm | Section 2.1.3 | | 1036 | SR Local Block | Section 2.1.4 | | 1037 | SRMS Preference | Section 2.1.5 | +------+-----------------+---------------+ Table 1: Node Attribute TLVs These TLVs should only be added to the BGP-LS Attribute associated with the Node NLRI describing the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. 2.1.1. SID/Label TLV The SID/Label TLV is used as a sub-TLV by the SR Capabilities (Section 2.1.2) and Segment Routing Local Block (SRLB) (Section 2.1.4) TLVs. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SID/Label sub-TLV in section 2.3 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SID/Label sub-TLV in section 2.1 of [I-D.ietf-ospf-segment-routing-extensions] and section 3.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Previdi, et al. Expires December 29, 2019 [Page 5] Internet-Draft BGP LS extensions for Segment Routing June 2019 The TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SID/Label TLV Format Where: Type: 1161 Length: Variable. Either 3 or 4 depending whether the value is encoded as a label or as an index/SID. SID/Label: If length is set to 3, then the 20 rightmost bits represent a label (the total TLV size is 7) and the 4 leftmost bits are set to 0. If length is set to 4, then the value represents a 32 bit SID (the total TLV size is 8). 2.1.2. SR Capabilities TLV The SR Capabilities TLV is used in order to advertise the node's SR Capabilities including its Segment Routing Global Base (SRGB) range(s). In the case of IS-IS, the capabilities also include the IPv4 and IPv6 support for the SR-MPLS forwarding plane. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SR Capabilities sub-TLV in section 3.1 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in section 3.2 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SR Capabilities TLV has the following format: Previdi, et al. Expires December 29, 2019 [Page 6] Internet-Draft BGP LS extensions for Segment Routing June 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV N // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SR Capabilities TLV Format Where: Type: 1034 Length: Variable. Minimum length is 12. Flags: 1 octet of flags as defined in section 3.1 of [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. Reserved: 1 octet that MUST be set to 0 and ignored on receipt. One or more entries, each of which have the following format: Range Size: 3 octet with a non-zero value indicating the number of labels in the range. SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV which encodes the first label in the range. Since the SID/ Label TLV is used to indicate the first label of the SRGB range, only label encoding is valid under the SR Capabilities TLV. Previdi, et al. Expires December 29, 2019 [Page 7] Internet-Draft BGP LS extensions for Segment Routing June 2019 2.1.3. SR Algorithm TLV The SR Algorithm TLV is used in order to advertise the SR Algorithms supported by the node. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SR-Algorithm sub-TLV in section 3.2 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in section 3.1 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SR Algorithm TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm... | Algorithm N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: SR Algorithm TLV Format Where: Type: 1035 Length: Variable. Minimum length is 1 and maximum can be 256. Algorithm: One or more fields of 1 octet each identifying the algorithm. 2.1.4. SR Local Block TLV The SR Local Block (SRLB) TLV contains the range(s) of labels the node has reserved for local SIDs. Local SIDs are used, e.g., in IGP (IS-IS, OSPF) for Adjacency-SIDs, and may also be allocated by components other than IGP protocols. As an example, an application or a controller may instruct a node to allocate a specific local SID. Therefore, in order for such applications or controllers to know the range of local SIDs available, it is required that the node advertises its SRLB. This information is derived from the protocol specific advertisements. Previdi, et al. Expires December 29, 2019 [Page 8] Internet-Draft BGP LS extensions for Segment Routing June 2019 o IS-IS, as defined by the SR Local Block sub-TLV in section 3.3 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SR Local Block TLV in section 3.3. of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SRLB TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Range Size 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Range Size N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label sub-TLV N // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: SRLB TLV Format Where: Type: 1036 Length: Variable. Minimum length is 12. Flags: 1 octet of flags. The flags are as defined in section 3.3 of [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. Reserved: 1 octet that MUST be set to 0 and ignored on receipt. Previdi, et al. Expires December 29, 2019 [Page 9] Internet-Draft BGP LS extensions for Segment Routing June 2019 One or more entries corresponding to sub-range(s), each of which have the following format: Range Size: 3 octet value indicating the number of labels in the range. SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV which encodes the first label in the sub-range. Since the SID/ Label TLV is used to indicate the first label of the SRLB sub- range, only label encoding is valid under the SR Local Block TLV. 2.1.5. SRMS Preference TLV The Segment Routing Mapping Server (SRMS) Preference TLV is used in order to associate a preference with SRMS advertisements from a particular source. [I-D.ietf-spring-segment-routing-ldp-interop] specifies the SRMS functionality along with SRMS preference of the node advertising the SRMS Prefix-to-SID Mapping ranges. This information is derived from the protocol specific advertisements. o IS-IS, as defined by the SRMS Preference sub-TLV in section 3.4 of [I-D.ietf-isis-segment-routing-extensions]. o OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in section 3.4 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the same TLV as defined for OSPFv2. The SRMS Preference TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | +-+-+-+-+-+-+-+-+ Figure 6: SRMS Preference TLV Format Where: Type: 1037 Length: 1. Previdi, et al. Expires December 29, 2019 [Page 10] Internet-Draft BGP LS extensions for Segment Routing June 2019 Preference: 1 octet carrying an unsigned 8 bit SRMS preference. 2.2. Link Attribute TLVs The following Link Attribute TLVs are are defined: +------+-----------------------+---------------+ | Type | Description | Section | +------+-----------------------+---------------+ | 1099 | Adjacency SID TLV | Section 2.2.1 | | 1100 | LAN Adjacency SID TLV | Section 2.2.2 | | 1172 | L2 Bundle Member TLV | Section 2.2.3 | +------+-----------------------+---------------+ Table 2: Link Attribute TLVs These TLVs should only be added to the BGP-LS Attribute associated with the Link NLRI describing the link of the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. 2.2.1. Adjacency SID TLV The Adjacency SID TLV is used in order to advertise information related to an Adjacency SID. This information is derived from Adj- SID sub-TLV of IS-IS (section 2.2.1 of [I-D.ietf-isis-segment-routing-extensions]), OSPFv2 (section 6.1 of [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 7.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The Adjacency SID TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) // +---------------------------------------------------------------+ Figure 7: Adjacency SID TLV Format Where: Type: 1099 Previdi, et al. Expires December 29, 2019 [Page 11] Internet-Draft BGP LS extensions for Segment Routing June 2019 Length: Variable. Either 7 or 8 depending on Label or Index encoding of the SID Flags. 1 octet value which should be set as: * IS-IS Adj-SID flags are defined in section 2.2.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 Adj-SID flags are defined in section 6.1 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 Adj-SID flags are defined in section 7.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Weight: 1 octet carrying the weight used for load-balancing purposes. The use of weight is described in section 3.4 of [RFC8402]. Reserved: 2 octets that MUST be set to 0 and ignored on receipt. SID/Index/Label: * IS-IS: Label or index value as defined in section 2.2.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2: Label or index value as defined in section 6.1 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3: Label or index value as defined in section 7.1 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification for parsing these fields. 2.2.2. LAN Adjacency SID TLV For a LAN, normally a node only announces its adjacency to the IS-IS pseudo-node (or the equivalent OSPF Designated and Backup Designated Routers). The LAN Adjacency Segment TLV allows a node to announce adjacencies to all other nodes attached to the LAN in a single instance of the BGP-LS Link NLRI. Without this TLV, the corresponding BGP-LS link NLRI would need to be originated for each additional adjacency in order to advertise the SR TLVs for these neighbor adjacencies. Previdi, et al. Expires December 29, 2019 [Page 12] Internet-Draft BGP LS extensions for Segment Routing June 2019 This information is derived from LAN-Adj-SID sub-TLV of IS-IS (section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]) and LAN Adj-SID sub-TLV of OSPFv2 (section 6.2 of [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 7.2 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The LAN Adjacency SID TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Neighbor ID / IS-IS System-ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) // +---------------------------------------------------------------+ Figure 8: LAN Adjacency SID TLV Format Where: Type: 1100 Length: Variable. For IS-IS it would be 13 or 14 depending on Label or Index encoding of the SID. For OSPF it would be 11 or 12 depending on Label or Index encoding of the SID. Flags. 1 octet value which should be set as: * IS-IS LAN Adj-SID flags are defined in section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 LAN Adj-SID flags are defined in section 6.2 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 LAN Adj-SID flags are defined in section 7.2 of [I-D.ietf-ospf-segment-routing-extensions]. Previdi, et al. Expires December 29, 2019 [Page 13] Internet-Draft BGP LS extensions for Segment Routing June 2019 Weight: 1 octet carrying the weight used for load-balancing purposes. The use of weight is described in section 3.4 of [RFC8402]. Reserved: 2 octets that MUST be set to 0 and ignored on receipt. Neighbor ID: 6 octets for IS-IS for the System-ID and 4 octets for OSPF for the OSPF Router-ID of the neighbor. SID/Index/Label: * IS-IS: Label or index value as defined in section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2: Label or index value as defined in section 6.2 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3: Label or index value as defined in section 7.2 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Neighbor ID, Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification for parsing these fields. 2.2.3. L2 Bundle Member Attribute TLV The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member link which in turn is associated with a parent L3 link. The L3 link is described by the Link NLRI defined in [RFC7752] and the L2 Bundle Member Attribute TLV is associated with the Link NLRI. The TLV MAY include sub-TLVs which describe attributes associated with the bundle member. The identified bundle member represents a unidirectional path from the originating router to the neighbor specified in the parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be associated with a Link NLRI. This information is derived from L2 Bundle Member Attributes TLV of IS-IS (section 2 of [I-D.ietf-isis-l2bundles]). The equivalent functionality has not been specified as yet for OSPF. The L2 Bundle Member Attribute TLV has the following format: Previdi, et al. Expires December 29, 2019 [Page 14] Internet-Draft BGP LS extensions for Segment Routing June 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 Bundle Member Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link attribute sub-TLVs(variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: L2 Bundle Member Attributes TLV Format Where: Type: 1172 Length: Variable. L2 Bundle Member Descriptor: 4 octets field that carries a Link Local Identifier as defined in [RFC4202]. Link attributes for L2 Bundle Member Links are advertised as sub-TLVs of the L2 Bundle Member Attribute TLV. The sub-TLVs are identical to existing BGP-LS TLVs as identified in the table below. Previdi, et al. Expires December 29, 2019 [Page 15] Internet-Draft BGP LS extensions for Segment Routing June 2019 +-------------+------------------------------------+----------------+ | TLV Code | Description | Reference | | Point | | Document | +-------------+------------------------------------+----------------+ | 1088 | Administrative group (color) | [RFC7752] | | 1089 | Maximum link bandwidth | [RFC7752] | | 1090 | Max. reservable link bandwidth | [RFC7752] | | 1091 | Unreserved bandwidth | [RFC7752] | | 1092 | TE default metric | [RFC7752] | | 1093 | Link protection type | [RFC7752] | | 1099 | Adjacency Segment Identifier (Adj- | Section 2.2.1 | | | SID) TLV | | | 1100 | LAN Adjacency Segment Identifier | Section 2.2.2 | | | (Adj-SID) TLV | | | 1114 | Unidirectional link delay | [RFC8571] | | 1115 | Min/Max Unidirectional link delay | [RFC8571] | | 1116 | Unidirectional Delay Variation | [RFC8571] | | 1117 | Unidirectional packet loss | [RFC8571] | | 1118 | Unidirectional residual bandwidth | [RFC8571] | | 1119 | Unidirectional available bandwidth | [RFC8571] | | 1120 | Unidirectional bandwidth | [RFC8571] | | | utilization | | +-------------+------------------------------------+----------------+ Table 3: BGP-LS Attribute TLVs also used as sub-TLVs of L2 Bundle Member Attribute TLV 2.3. Prefix Attribute TLVs The following Prefix Attribute TLVs are defined: +------+------------------------+---------------+ | Type | Description | Section | +------+------------------------+---------------+ | 1158 | Prefix SID | Section 2.3.1 | | 1159 | Range | Section 2.3.4 | | 1170 | Prefix Attribute Flags | Section 2.3.2 | | 1171 | Source Router-ID | Section 2.3.3 | +------+------------------------+---------------+ Table 4: Prefix Attribute TLVs These TLVs should only be added to the BGP-LS Attribute associated with the Prefix NLRI describing the prefix of the IGP node that is originating the corresponding IGP TLV/sub-TLV described below. Previdi, et al. Expires December 29, 2019 [Page 16] Internet-Draft BGP LS extensions for Segment Routing June 2019 2.3.1. Prefix SID TLV The Prefix SID TLV is used in order to advertise information related to a Prefix SID. This information is derived from Prefix-SID sub-TLV of IS-IS (section 2.1 of [I-D.ietf-isis-segment-routing-extensions]) and the Prefix SID sub-TLV of OSPFv2 (section 5 of [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 6 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). The Prefix SID TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Prefix SID TLV Format Where: Type: 1158 Length: Variable. 7 or 8 depending on Label or Index encoding of the SID Flags: 1 octet value which should be set as: * IS-IS Prefix SID flags are defined in section 2.1.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 Prefix SID flags are defined in section 5 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 Prefix SID flags are defined in section 6 of [I-D.ietf-ospf-segment-routing-extensions]. Algorithm: 1 octet value identify the algorithm. The semantics of algorithm are described in section 3.1.1 of [RFC8402]. Reserved: 2 octets that MUST be set to 0 and ignored on receipt. SID/Index/Label: Previdi, et al. Expires December 29, 2019 [Page 17] Internet-Draft BGP LS extensions for Segment Routing June 2019 * IS-IS: Label or index value as defined in section 2.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2: Label or index value as defined in section 5 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3: Label or index value as defined in section 6 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing these fields. 2.3.2. Prefix Attribute Flags TLV The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute flags information. These flags are defined for OSPFv2 in section 2.1 of [RFC7684], for OSPFv3 in section A.4.1.1 of [RFC5340] and for IS- IS in section 2.1 of [RFC7794]. The Prefix Attribute Flags TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Prefix Attribute Flags TLV Format Where: Type: 1170 Length: Variable. Flags: a variable length flag field (according to the length field). Flags are routing protocol specific and are to be set as below: * IS-IS flags correspond to the IPv4/IPv6 Extended Reachability Attribute Flags defined in section 2.1 of [RFC7794] Previdi, et al. Expires December 29, 2019 [Page 18] Internet-Draft BGP LS extensions for Segment Routing June 2019 * OSPFv2 flags correspond to the Flags field of the OSPFv2 Extended Prefix TLV defined in section 2.1 of [RFC7684] * OSPFv3 flags map to the Prefix Options field defined in section A.4.1.1 of [RFC5340] and extended in section 3.1 of [RFC8362] The Flags field of this TLV is interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing this field. 2.3.3. Source Router Identifier (Source Router-ID) TLV The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the originator of the Prefix. For the IS-IS protocol this is derived from the IPv4/IPv6 Source Router ID sub-TLV as defined in section 2.2 of [RFC7794]. For the OSPF protocol, this is derived from the Prefix Source Router-ID sub-TLV as defined in section 4 of [I-D.ietf-lsr-ospf-prefix-originator]. The Source Router-ID TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 or 16 octet Router-ID // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Source Router-ID TLV Format Where: Type: 1171 Length: Variable. 4 or 16 in case of IS-IS and 4 in case of OSPF. Router-ID: the IPv4 or IPv6 Router-ID in case of IS-IS and the OSPF Router-ID in the case of OSPF. 2.3.4. Range TLV The Range TLV is used in order to advertise a range of prefix-to-SID mappings as part of the Segment Routing Mapping Server (SRMS) functionality [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the respective underlying IGP SR extensions Previdi, et al. Expires December 29, 2019 [Page 19] Internet-Draft BGP LS extensions for Segment Routing June 2019 [I-D.ietf-ospf-segment-routing-extensions] (section 4), [I-D.ietf-ospf-ospfv3-segment-routing-extensions] (section 5) and [I-D.ietf-isis-segment-routing-extensions] (section 2.4). The information advertised in the Range TLV is derived from the SID/Label Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3 Extended Prefix Range TLV in the case of OSPFv2/OSPFv3. A Prefix NLRI, that been advertised with a Range TLV, is considered a normal routing prefix (i.e. prefix reachability) only when there is also an IGP metric TLV (TLV 1095) associated it. Otherwise, it is considered only as the first prefix in the range for prefix-to-SID mapping advertisement. The format of the Range TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Range TLV Format Where: Type: 1159 Length: Variable. 11 or 12 depending on Label or Index encoding of the SID Flags: 1 octet value which should be set as: * IS-IS SID/Label Binding TLV flags are defined in section 2.4.1 of [I-D.ietf-isis-segment-routing-extensions]. * OSPFv2 OSPF Extended Prefix Range TLV flags are defined in section 4 of [I-D.ietf-ospf-segment-routing-extensions]. * OSPFv3 Extended Prefix Range TLV flags are defined in section 5 of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Reserved: 1 octet that MUST be set to 0 and ignored on receipt. Previdi, et al. Expires December 29, 2019 [Page 20] Internet-Draft BGP LS extensions for Segment Routing June 2019 Range Size: 2 octets that carry the number of prefixes that are covered by the advertisement.. The Flags field of this TLV is interpreted according to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing this field. The prefix-to-SID mappings are advertised using sub-TLVs as below: IS-IS: SID/Label Range TLV Prefix-SID sub-TLV OSPFv2/OSPFv3: OSPFv2/OSPFv3 Extended Prefix Range TLV Prefix SID sub-TLV BGP-LS: Range TLV Prefix-SID TLV (used as a sub-TLV in this context) The prefix-to-SID mapping information for the BGP-LS Prefix-SID TLV (used as sub-TLV in this context) is encoded as described in Section 2.3.1. 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs This section illustrate the IS-IS Segment Routing Extensions TLVs and sub-TLVs mapped to the ones defined in this document. The following table, illustrates for each BGP-LS TLV, its equivalence in IS-IS. Previdi, et al. Expires December 29, 2019 [Page 21] Internet-Draft BGP LS extensions for Segment Routing June 2019 +------------+---------------+--------------------------------------+ | Descriptio | IS-IS TLV | Reference | | n | /sub-TLV | | +------------+---------------+--------------------------------------+ | SR Capabil | SR- | [I-D.ietf-isis-segment-routing-exten | | ities | Capabilities | sions] | | | sub-TLV (2) | | | SR | SR-Algorithm | [I-D.ietf-isis-segment-routing-exten | | Algorithm | sub-TLV (19) | sions] | | SR Local | SR Local | [I-D.ietf-isis-segment-routing-exten | | Block | Block sub-TLV | sions] | | | (22) | | | SRMS | SRMS | [I-D.ietf-isis-segment-routing-exten | | Preference | Preference | sions] | | | sub-TLV (19) | | | Adjacency | Adj-SID sub- | [I-D.ietf-isis-segment-routing-exten | | SID | TLV (31) | sions] | | LAN | LAN-Adj-SID | [I-D.ietf-isis-segment-routing-exten | | Adjacency | sub-TLV (32) | sions] | | SID | | | | Prefix SID | Prefix-SID | [I-D.ietf-isis-segment-routing-exten | | | sub-TLV (3) | sions] | | Range | SID/Label | [I-D.ietf-isis-segment-routing-exten | | | Binding TLV | sions] | | | (149) | | | SID/Label | SID/Label | [I-D.ietf-isis-segment-routing-exten | | | sub-TLV (1) | sions] | | Prefix | Prefix | [RFC7794] | | Attribute | Attributes | | | Flags | Flags sub-TLV | | | | (4) | | | Source | IPv4/IPv6 | [RFC7794] | | Router-ID | Source Router | | | | ID sub-TLV | | | | (11/12) | | | L2 Bundle | L2 Bundle | [I-D.ietf-isis-l2bundles] | | Member | Member | | | Attributes | Attributes | | | | TLV (25) | | +------------+---------------+--------------------------------------+ Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs This section illustrate the OSPFv2 and OSPFv3 Segment Routing Extensions TLVs and sub-TLVs mapped to the ones defined in this document. Previdi, et al. Expires December 29, 2019 [Page 22] Internet-Draft BGP LS extensions for Segment Routing June 2019 The following table, illustrates for each BGP-LS TLV, its equivalence in OSPFv2 and OSPFv3. +------------+-------------+----------------------------------------+ | Descriptio | OSPFv2 TLV | Reference | | n | /sub-TLV | | +------------+-------------+----------------------------------------+ | SR Capabil | SID/Label | [I-D.ietf-ospf-segment-routing-extensi | | ities | Range TLV | ons] | | | (9) | | | SR | SR- | [I-D.ietf-ospf-segment-routing-extensi | | Algorithm | Algorithm | ons] | | | TLV (8) | | | SR Local | SR Local | [I-D.ietf-ospf-segment-routing-extensi | | Block | Block TLV | ons] | | | (14) | | | SRMS | SRMS | [I-D.ietf-ospf-segment-routing-extensi | | Preference | Preference | ons] | | | TLV (15) | | | Adjacency | Adj-SID | [I-D.ietf-ospf-segment-routing-extensi | | SID | sub-TLV (2) | ons] | | LAN | LAN Adj-SID | [I-D.ietf-ospf-segment-routing-extensi | | Adjacency | sub-TLV (3) | ons] | | SID | | | | Prefix SID | Prefix SID | [I-D.ietf-ospf-segment-routing-extensi | | | sub-TLV (2) | ons] | | Range | OSPF | [I-D.ietf-ospf-segment-routing-extensi | | | Extended | ons] | | | Prefix | | | | Range TLV | | | | (2) | | | SID/Label | SID/Label | [I-D.ietf-ospf-segment-routing-extensi | | | sub-TLV (1) | ons] | | Prefix | Flags of | [RFC7684] | | Attribute | OSPFv2 | | | Flags | Extended | | | | Prefix TLV | | | | (1) | | | Source | Prefix | [I-D.ietf-lsr-ospf-prefix-originator] | | Router-ID | Source | | | | Router-ID | | | | sub-TLV | | | | (TBD) | | +------------+-------------+----------------------------------------+ Table 6: OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs Previdi, et al. Expires December 29, 2019 [Page 23] Internet-Draft BGP LS extensions for Segment Routing June 2019 +-----------+------------+------------------------------------------+ | Descripti | OSPFv3 TLV | Reference | | on | /sub-TLV | | +-----------+------------+------------------------------------------+ | SR Capabi | SID/Label | [I-D.ietf-ospf-segment-routing-extension | | lities | Range TLV | s] | | | (9) | | | SR | SR- | [I-D.ietf-ospf-segment-routing-extension | | Algorithm | Algorithm | s] | | | TLV (8) | | | SR Local | SR Local | [I-D.ietf-ospf-segment-routing-extension | | Block | Block TLV | s] | | | (14) | | | SRMS Pref | SRMS | [I-D.ietf-ospf-segment-routing-extension | | erence | Preference | s] | | | TLV (15) | | | Adjacency | Adj-SID | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | SID | sub-TLV | tensions] | | | (5) | | | LAN | LAN Adj- | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | Adjacency | SID sub- | tensions] | | SID | TLV (6) | | | Prefix | Prefix SID | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | SID | sub-TLV | tensions] | | | (4) | | | Range | OSPFv3 | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | | Extended | tensions] | | | Prefix | | | | Range TLV | | | | (9) | | | SID/Label | SID/Label | [I-D.ietf-ospf-ospfv3-segment-routing-ex | | | sub-TLV | tensions] | | | (7) | | | Prefix | Prefix | [RFC8362] | | Attribute | Option | | | Flags | Fields of | | | | Prefix TLV | | | | types | | | | 3,5,6 | | | Source | Prefix | [I-D.ietf-lsr-ospf-prefix-originator] | | Router-ID | Source | | | | Router-ID | | | | sub-TLV | | | | (TBD) | | +-----------+------------+------------------------------------------+ Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs Previdi, et al. Expires December 29, 2019 [Page 24] Internet-Draft BGP LS extensions for Segment Routing June 2019 3. IANA Considerations Early allocation of codepoints has been done by IANA for this document from the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" under the "BGP-LS Parameters" registry based on Table 8. The column "IS-IS TLV/Sub-TLV" defined in the registry does not require any value and should be left empty. 3.1. TLV/Sub-TLV Code Points Summary This section contains the global table of all TLVs/sub-TLVs defined in this document. +----------------+-----------------------------+---------------+ | TLV Code Point | Description | Reference | +----------------+-----------------------------+---------------+ | 1034 | SR Capabilities | Section 2.1.2 | | 1035 | SR Algorithm | Section 2.1.3 | | 1036 | SR Local Block | Section 2.1.4 | | 1037 | SRMS Preference | Section 2.1.5 | | 1099 | Adjacency SID | Section 2.2.1 | | 1100 | LAN Adjacency SID | Section 2.2.2 | | 1158 | Prefix SID | Section 2.3.1 | | 1159 | Range | Section 2.3.4 | | 1161 | SID/Label | Section 2.1.1 | | 1170 | Prefix Attribute Flags | Section 2.3.2 | | 1171 | Source Router-ID | Section 2.3.3 | | 1172 | L2 Bundle Member Attributes | Section 2.2.3 | +----------------+-----------------------------+---------------+ Table 8: Summary Table of TLV/Sub-TLV Codepoints 4. Manageability Considerations This section is structured as recommended in [RFC5706]. The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via [RFC7752]. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in the Manageability Considerations section of [RFC7752]. Specifically, the malformed attribute tests for syntactic checks in the Fault Management section of [RFC7752] now encompass the new BGP- LS Attribute TLVs defined in this document. The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their BGP-LS Attribute is left to the consumer of the BGP-LS information (e.g. an application or a controller) and not the BGP protocol. Previdi, et al. Expires December 29, 2019 [Page 25] Internet-Draft BGP LS extensions for Segment Routing June 2019 A consumer of the BGP-LS information retrieves this information over a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. This document only introduces new Attribute TLVs and any syntactic error in them would result in only that specific attribute being discarded with an error log. The SR information introduced in BGP-LS by this specification, may be used by BGP-LS consumer applications like a SR path computation engine (PCE) to learn the SR capabilities of the nodes in the topology and the mapping of SR segments to those nodes. This can enable the SR PCE to perform path computations based on SR for traffic engineering use-cases and to steer traffic on paths different from the underlying IGP based distributed best path computation. Errors in the encoding or decoding of the SR information may result in the unavailability of such information to the SR PCE or incorrect information being made available to it. This may result in the SR PCE not being able to perform the desired SR based optimization functionality or to perform it in an unexpected or inconsistent manner. The handling of such errors by applications like SR PCE may be implementation specific and out of scope of this document. The extensions, specified in this document, do not introduce any new configuration or monitoring aspects in BGP or BGP-LS other than as discussed in [RFC7752]. The manageability aspects of the underlying SR features are covered by [I-D.ietf-spring-sr-yang], [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. 5. Security Considerations The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via [RFC7752]. The advertisement of the SR link attribute information defined in this document presents similar risk as associated with the existing set of link attribute information as described in [RFC7752]. The Security Considerations section of [RFC7752] also applies to these extensions. The procedures and new TLVs defined in this document, by themselves, do not affect the BGP-LS security model discussed in [RFC7752]. The TLVs introduced in this document are used to propagate IGP defined information ([I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs represent the SR information associated with the IGP node, link and prefix. The IGP instances originating these TLVs are assumed to Previdi, et al. Expires December 29, 2019 [Page 26] Internet-Draft BGP LS extensions for Segment Routing June 2019 support all the required security and authentication mechanisms (as described in [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]) in order to prevent any security issue when propagating the TLVs into BGP-LS. BGP-LS SR extensions enable traffic engineering use-cases within the Segment Routing domain. SR operates within a trusted domain [RFC8402] and its security considerations also apply to BGP-LS sessions when carrying SR information. The SR traffic engineering policies using the SIDs advertised via BGP-LS are expected to be used entirely within this trusted SR domain (e.g. between multiple AS/ domains within a single provider network). Therefore, precaution is necessary to ensure that the link-state information (including SR information) advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain. BGP peering sessions for address-families other than Link-State may be setup to routers outside the SR domain. The isolation of BGP-LS peering sessions is recommended to ensure that BGP-LS topology information (including the newly added SR information) is not advertised to an external BGP peering session outside the SR domain. 6. Contributors The following people have substantially contributed to the editing of this document: Peter Psenak Cisco Systems Email: ppsenak@cisco.com Les Ginsberg Cisco Systems Email: ginsberg@cisco.com Acee Lindem Cisco Systems Email: acee@cisco.com Saikat Ray Individual Email: raysaikat@gmail.com Jeff Tantsura Apstra Inc. Email: jefftant.ietf@gmail.com Previdi, et al. Expires December 29, 2019 [Page 27] Internet-Draft BGP LS extensions for Segment Routing June 2019 7. Acknowledgements The authors would like to thank Jeffrey Haas, Aijun Wang, Robert Raszuk and Susan Hares for their review of this document and their comments. The authors would also like to thank Alvaro Retana for his extensive review and comments which helped correct issues and improve the document. 8. References 8.1. Normative References [I-D.ietf-isis-l2bundles] Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and E. Aries, "Advertising L2 Bundle Member Link Attributes in IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), May 2017. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-25 (work in progress), May 2019. [I-D.ietf-lsr-ospf-prefix-originator] Wang, A., Lindem, A., Dong, J., Talaulikar, K., and P. Psenak, "OSPF Extension for Prefix Originator", draft- ietf-lsr-ospf-prefix-originator-00 (work in progress), February 2019. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-23 (work in progress), January 2019. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-27 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Previdi, et al. Expires December 29, 2019 [Page 28] Internet-Draft BGP LS extensions for Segment Routing June 2019 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, . Previdi, et al. Expires December 29, 2019 [Page 29] Internet-Draft BGP LS extensions for Segment Routing June 2019 8.2. Informative References [I-D.ietf-isis-sr-yang] Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J. Tantsura, "YANG Data Model for IS-IS Segment Routing", draft-ietf-isis-sr-yang-05 (work in progress), March 2019. [I-D.ietf-ospf-sr-yang] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for OSPF SR (Segment Routing) Protocol", draft-ietf-ospf-sr-yang-07 (work in progress), March 2019. [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.ietf-spring-sr-yang] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", draft- ietf-spring-sr-yang-12 (work in progress), February 2019. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, . Authors' Addresses Stefano Previdi Huawei Technologies Rome Italy Email: stefano@previdi.net Ketan Talaulikar (editor) Cisco Systems, Inc. India Email: ketant@cisco.com Previdi, et al. Expires December 29, 2019 [Page 30] Internet-Draft BGP LS extensions for Segment Routing June 2019 Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Mach(Guoyi) Chen Huawei Technologies Huawei Building, No. 156 Beiqing Rd. Beijing 100095 China Email: mach.chen@huawei.com Previdi, et al. Expires December 29, 2019 [Page 31] ./draft-ietf-idr-bgpls-segment-routing-epe-19.txt0000644000764400076440000011237113467223140021150 0ustar iustyiusty Inter-Domain Routing S. Previdi Internet-Draft Individual Intended status: Standards Track K. Talaulikar, Ed. Expires: November 17, 2019 C. Filsfils Cisco Systems, Inc. K. Patel Arrcus, Inc. S. Ray Individual Contributor J. Dong Huawei Technologies May 16, 2019 BGP-LS extensions for Segment Routing BGP Egress Peer Engineering draft-ietf-idr-bgpls-segment-routing-epe-19 Abstract Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. This document describes an extension to BGP Link-State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Previdi, et al. Expires November 17, 2019 [Page 1] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 17, 2019. Copyright Notice Copyright (c) 2019 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 (https://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. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 4 3. BGP-LS NLRI Advertisement for BGP Protocol . . . . . . . . . 5 3.1. BGP Router-ID and Member AS Number . . . . . . . . . . . 6 3.2. Mandatory BGP Node Descriptors . . . . . . . . . . . . . 6 3.3. Optional BGP Node Descriptors . . . . . . . . . . . . . . 7 4. BGP-LS Attributes for BGP Peering Segments . . . . . . . . . 7 4.1. Advertisement of the PeerNode SID . . . . . . . . . . . . 10 4.2. Advertisement of the PeerAdj SID . . . . . . . . . . . . 11 4.3. Advertisement of the PeerSet SID . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.1. New BGP-LS Protocol-ID . . . . . . . . . . . . . . . . . 13 5.2. Node Descriptors and Link Attribute TLVs . . . . . . . . 13 6. Manageability Considerations . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Previdi, et al. Expires November 17, 2019 [Page 2] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 1. Introduction Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header with segment identifiers (SID). A SID can represent any instruction, topological or service- based. SR segments allows to enforce a flow through any topological path or service function while maintaining per-flow state only at the ingress node of the SR domain. The SR architecture [RFC8402] defines three types of BGP Peering Segments that may be instantiated at a BGP node: o Peer Node Segment (PeerNode SID) : instruction to steer to a specific peer node o Peer Adjacency Segment (PeerAdj SID) : instruction to steer over a specific local interface towards a specific peer node o Peer Set Segment (PeerSet SID) : instruction to load-balance to a set of specific peer nodes SR can be directly applied to either to an MPLS dataplane (SR/MPLS) with no change on the forwarding plane or to a modified IPv6 forwarding plane (SRv6). This document describes extensions to the BGP Link-State NLRI (BGP-LS NLRI) and the BGP-LS Attribute defined for BGP-LS [RFC7752] for advertising BGP peering segments from a BGP node along with its peering topology information (i.e., its peers, interfaces, and peering ASs) to enable computation of efficient BGP Egress Peer Engineering (BGP-EPE) policies and strategies using the SR/MPLS dataplane. The corresponding extensions for SRv6 are specified in [I-D.dawra-idr-bgpls-srv6-ext]. [I-D.ietf-spring-segment-routing-central-epe] illustrates a centralized controller-based BGP Egress Peer Engineering solution involving SR path computation using the BGP Peering Segments. This use case comprises a centralized controller that learns the BGP Peering SIDs via BGP-LS and then uses this information to program a BGP-EPE policy at any node in the domain to perform traffic steering via a specific BGP egress node to a specific EBGP peer(s) optionally also over a specific interface. The BGP-EPE policy can be realized using the SR Policy framework [I-D.ietf-spring-segment-routing-policy]. This document introduces a new BGP-LS Protocol-ID for BGP and defines new BGP-LS Node and Link Descriptor TLVs to facilitate advertising Previdi, et al. Expires November 17, 2019 [Page 3] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 BGP-LS Link NLRI to represent the BGP peering topology. Further, it specifies the BGP-LS Attribute TLVs for advertisement of the BGP Peering Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) to be advertised in the same BGP-LS Link NLRI. 2. BGP Peering Segments As described in [RFC8402], a BGP-EPE enabled Egress PE node instantiates SR Segments corresponding to its attached peers. These segments are called BGP Peering Segments or BGP Peering SIDs. In case of EBGP, they enable the expression of source-routed inter- domain paths. An ingress border router of an AS may compose a list of SIDs to steer a flow along a selected path within the AS, towards a selected egress border router C of the AS, and to a specific EBGP peer. At minimum, a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID of the chosen egress PE and then the BGP Peering SID for the chosen egress PE peer or peering interface. Each BGP session MUST be described by a PeerNode SID. The description of the BGP session MAY be augmented by additional PeerAdj SIDs. Finally, multiple PeerNode SIDs or PeerAdj SIDs MAY be part of the same group/set in order to group EPE resources under a common PeerSet SID. These BGP Peering SIDs and their encoding are described in detail in Section 4. The following BGP Peering SIDs need to be instantiated on a BGP router for each of its BGP peer sessions that are enabled for Egress Peer Engineering: o One PeerNode SID MUST be instantiated to describe the BGP peer session. o One or more PeerAdj SID MAY be instantiated corresponding to the underlying link(s) to the directly connected BGP peer session. o A PeerSet SID MAY be instantiated and additionally associated and shared between one or more PeerNode SIDs or PeerAdj SIDs. While an egress point in a topology usually refers to EBGP sessions between external peers, there's nothing in the extensions defined in this document that would prevent the use of these extensions in the context of IBGP sessions. However, unlike EBGP sessions which are generally between directly connected BGP routers which are also along the traffic forwarding path, IBGP peer sessions may be setup to BGP routers which are not in the forwarding path. As such, when the IBGP design includes sessions with route-reflectors, a BGP router SHOULD Previdi, et al. Expires November 17, 2019 [Page 4] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 NOT instantiate a BGP Peering SID for those sessions to peer nodes which are not in the forwarding path since the purpose of BGP Peering SID is to steer traffic to that specific peers. Thus, the applicability for IBGP peering may be limited to only those deployments where the IBGP peer is also along the forwarding data path. Any BGP Peering SIDs instantiated on the node are advertised via BGP- LS Link NLRI type as described in the sections below. An illustration of the BGP Peering SIDs' allocations in a reference BGP peering topology along with the information carried in the BGP-LS Link NLRI and its corresponding BGP-LS Attribute are described in [I-D.ietf-spring-segment-routing-central-epe]. 3. BGP-LS NLRI Advertisement for BGP Protocol This section describes the BGP-LS NLRI encodings that describe the BGP peering and link connectivity between BGP routers. This document specifies the advertisement of BGP peering topology information via BGP-LS Link NLRI type which requires use of a new BGP-LS Protocol-ID. +-------------+----------------------------------+ | Protocol-ID | NLRI information source protocol | +-------------+----------------------------------+ | 7 | BGP | +-------------+----------------------------------+ Table 1: BGP-LS Protocol Identifier for BGP The use of a new Protocol-ID allows separation and differentiation between the BGP-LS NLRIs carrying BGP information from the BGP-LS NLRIs carrying IGP link-state information defined in [RFC7752]. The BGP Peering information along with their Peering Segments are advertised using BGP-LS Link NLRI type with the Protocol-ID set to BGP. The BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS Attribute TLVs as defined in [RFC7752]. In order to correctly describe BGP nodes, new TLVs are defined in this section. [RFC7752] defines Link NLRI Type is as follows: Previdi, et al. Expires November 17, 2019 [Page 5] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Protocol-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | | (64 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Local Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Remote Node Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Link Descriptors // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: BGP-LS Link NLRI Node Descriptors and Link Descriptors are defined in [RFC7752]. 3.1. BGP Router-ID and Member AS Number Two new Node Descriptors TLVs are defined in this document: o BGP Router Identifier (BGP Router-ID): Type: 516 Length: 4 octets Value: 4 octet unsigned non-zero integer representing the BGP Identifier as defined in [RFC6286]. o Member-AS Number (Member-ASN) Type: 517 Length: 4 octets Value: 4 octet unsigned non-zero integer representing the Member-AS Number [RFC5065]. 3.2. Mandatory BGP Node Descriptors The following Node Descriptors TLVs MUST be included in BGP-LS NLRI as Local Node Descriptors when distributing BGP information: o BGP Router-ID (TLV 516), which contains a valid BGP Identifier of the local BGP node. Previdi, et al. Expires November 17, 2019 [Page 6] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 o Autonomous System Number (TLV 512) [RFC7752], which contains the ASN or AS Confederation Identifier (ASN) [RFC5065], if confederations are used, of the local BGP node. Note that [RFC6286] (section 2.1) requires the BGP identifier (Router-ID) to be unique within an Autonomous System and non-zero. Therefore, the tuple is globally unique. Their use in the Node Descriptor helps map Link-State NLRIs with BGP protocol-ID to a unique BGP router in the administrative domain where BGP-LS is enabled. The following Node Descriptors TLVs MUST be included in BGP-LS Link NLRI as Remote Node Descriptors when distributing BGP information: o BGP Router-ID (TLV 516), which contains the valid BGP Identifier of the peer BGP node. o Autonomous System Number (TLV 512) [RFC7752], which contains the ASN or the AS Confederation Identifier (ASN) [RFC5065], if confederations are used, of the peer BGP node. 3.3. Optional BGP Node Descriptors The following Node Descriptors TLVs MAY be included in BGP-LS NLRI as Local Node Descriptors when distributing BGP information: o Member-ASN (TLV 517), which contains the ASN of the confederation member (i.e., Member-AS Number), if BGP confederations are used, of the local BGP node. o Node Descriptors as defined in [RFC7752]. The following Node Descriptors TLVs MAY be included in BGP-LS Link NLRI as Remote Node Descriptors when distributing BGP information: o Member-ASN (TLV 517), which contains the ASN of the confederation member (i.e., Member-AS Number), if BGP confederations are used, of the peer BGP node. o Node Descriptors as defined in [RFC7752]. 4. BGP-LS Attributes for BGP Peering Segments This section defines the BGP-LS Attributes corresponding to the following BGP Peer Segment SIDs: Peer Node Segment Identifier (PeerNode SID) Previdi, et al. Expires November 17, 2019 [Page 7] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Peer Adjacency Segment Identifier (PeerAdj SID) Peer Set Segment Identifier (PeerSet SID) The following new BGP-LS Link attributes TLVs are defined for use with BGP-LS Link NLRI for advertising BGP Peering SIDs: +----------+---------------------------+ | TLV Code | Description | | Point | | +----------+---------------------------+ | 1101 | PeerNode SID | | 1102 | PeerAdj SID | | 1103 | PeerSet SID | +----------+---------------------------+ Figure 2: BGP-LS TLV code points for BGP-EPE PeerNode SID, PeerAdj SID, and PeerSet SID have all the same format defined here below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: BGP Peering SIDs TLV Format o Type: 1101, 1102 or 1103 as listed in Figure 2. o Length: variable. Valid values are either 7 or 8 based on the whether the encoding is done as a SID Index or a label. o Flags: one octet of flags with the following definition: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L|B|P| Rsvd | +-+-+-+-+-+-+-+-+ Figure 4: Peering SID TLV Flags Format Previdi, et al. Expires November 17, 2019 [Page 8] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 * V-Flag: Value flag. If set, then the SID carries a label value. By default the flag is SET. * L-Flag: Local Flag. If set, then the value/index carried by the SID has local significance. By default the flag is SET. * B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection using fast re-route (FRR). The computation of the backup forwarding path and its association with the BGP Peering SID forwarding entry is implementation specific. [I-D.ietf-spring-segment-routing-central-epe] section 3.6 discusses some of the possible ways of identifying backup paths for BGP Peering SIDs. * P-Flag: Persistent Flag: If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap. * Rsvd bits: Reserved for future use and MUST be zero when originated and ignored when received. o Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing. An example use of the weight is described in [RFC8402]. o SID/Index/Label. According to the TLV length and to the V and L flags settings, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V and L flags MUST be SET. * A 4 octet index defining the offset in the Segment Routing Global Block (SRGB) [RFC8402] advertised by this router. In this case, the SRGB MUST be advertised using the extensions defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs SHOULD be persistent across router restart. When enabled for Egress Peer Engineering, the BGP router MUST include the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI corresponding to its BGP peering sessions. The PeerAdj SID and PeerSet SID TLVs MAY be included in the BGP-LS Attribute for the BGP- LS Link NLRI. Additional BGP-LS Link Attribute TLVs, as defined in [RFC7752] MAY be included with the BGP-LS Link NLRI in order to advertise the Previdi, et al. Expires November 17, 2019 [Page 9] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 characteristics of the peering link. E.g., one or more interface addresses (TLV 259 or TLV 261) of the underlying link(s) over which a multi-hop BGP peering session is setup may be included in the BGP-LS Attribute along with the PeerNode SID TLV. 4.1. Advertisement of the PeerNode SID The PeerNode SID TLV includes a SID associated with the BGP peer node that is described by a BGP-LS Link NLRI as specified in Section 3. The PeerNode SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]): o SR operation: NEXT. o Next-Hop: the connected peering node to which the segment is associated. The PeerNode SID is advertised with a BGP-LS Link NLRI, where: o Local Node Descriptors include: * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. * Local ASN (TLV 512). o Remote Node Descriptors include: * Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the BGP session) * Peer ASN (TLV 512). o Link Descriptors include the addresses used by the BGP session encoded using TLVs as defined in [RFC7752]: * IPv4 Interface Address (TLV 259) contains the BGP session IPv4 local address. * IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4 peer address. * IPv6 Interface Address (TLV 261) contains the BGP session IPv6 local address. * IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6 peer address. Previdi, et al. Expires November 17, 2019 [Page 10] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 o Link Attribute TLVs include the PeerNode SID TLV as defined in Figure 3. 4.2. Advertisement of the PeerAdj SID The PeerAdj SID TLV includes a SID associated with the underlying link to the BGP peer node that is described by a BGP-LS Link NLRI as specified in Section 3. The PeerAdj SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]): o SR operation: NEXT. o Next-Hop: the interface peer address. The PeerAdj SID is advertised with a BGP-LS Link NLRI, where: o Local Node Descriptors include: * Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress PE. * Local ASN (TLV 512). o Remote Node Descriptors include: * Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the BGP session). * Peer ASN (TLV 512). o Link Descriptors MUST include the following TLV, as defined in [RFC7752]: * Link Local/Remote Identifiers (TLV 258) contains the 4-octet Link Local Identifier followed by the 4-octet Link Remote Identifier. The value 0 is used by default when the link remote identifier is unknown. o Additional Link Descriptors TLVs, as defined in [RFC7752], MAY also be included to describe the addresses corresponding to the link between the BGP routers: * IPv4 Interface Address (Sub-TLV 259) contains the address of the local interface through which the BGP session is established. Previdi, et al. Expires November 17, 2019 [Page 11] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 * IPv6 Interface Address (Sub-TLV 261) contains the address of the local interface through which the BGP session is established. * IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address of the peer interface used by the BGP session. * IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address of the peer interface used by the BGP session. o Link Attribute TLVs include the PeerAdj SID TLV as defined in Figure 3. 4.3. Advertisement of the PeerSet SID The PeerSet SID TLV includes a SID that is shared amongst BGP peer nodes or the underlying links that are described by BGP-LS Link NLRI as specified in Section 3. The PeerSet SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]): o SR operation: NEXT. o Next-Hop: load balance across any connected interface to any peer in the associated peer set. The PeerSet SID TLV containing the same SID value (encoded as defined in Figure 3) is included in the BGP-LS Attribute for all of the BGP- LS Link NLRI corresponding to the PeerNode or PeerAdj segments associated with the peer set. 5. IANA Considerations This document defines: A new Protocol-ID: BGP. The codepoint is from the "BGP-LS Protocol-IDs" registry. Two new TLVs: BGP-Router-ID and BGP Confederation Member. The codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID and PeerSet SID. The codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. Previdi, et al. Expires November 17, 2019 [Page 12] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 5.1. New BGP-LS Protocol-ID This document defines a new value in the registry "BGP-LS Protocol- IDs": +------------------------------------------------------+ | Codepoint | Description | Status | +------------------------------------------------------+ | 7 | BGP | Early Allocation by IANA | +------------------------------------------------------+ Figure 5: BGP Protocol Codepoint 5.2. Node Descriptors and Link Attribute TLVs This document defines 5 new TLVs in the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": o Two new node descriptor TLVs o Three new link attribute TLVs All the new 5 codepoints are in the same registry: "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". The following new Node Descriptors TLVs are defined: +-------------------------------------------------------------------+ | Codepoint | Description | Status | +-------------------------------------------------------------------+ | 516 | BGP Router-ID | Early Allocation by IANA | | 517 | BGP Confederation Member | Early Allocation by IANA | +------------+------------------------------------------------------+ Figure 6: BGP-LS Descriptor TLVs Codepoints The following new Link Attribute TLVs are defined: +-------------------------------------------------------------------+ | Codepoint | Description | Status | +-------------------------------------------------------------------+ | 1101 | PeerNode SID | Early Allocation by IANA | | 1102 | PeerAdj SID | Early Allocation by IANA | | 1103 | PeerSet SID | Early Allocation by IANA | +------------+------------------------------------------------------+ Figure 7: BGP-LS Attribute TLVs Codepoints Previdi, et al. Expires November 17, 2019 [Page 13] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 6. Manageability Considerations The new protocol extensions introduced in this document augment the existing IGP topology information BGP-LS distribution [RFC7752] by adding support for distribution of BGP peering topology information. As such, the Manageability Considerations section of [RFC7752] applies to these new extensions as well. Specifically, the malformed Link-State NLRI and BGP-LS Attribute tests for syntactic checks in the Fault Management section of [RFC7752] now apply to the TLVs defined in this document. The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their associated BGP-LS Attributes is left to the consumer of the BGP-LS information (e.g., an application or a controller) and not the BGP protocol. A consumer of the BGP-LS information retrieves this information from a BGP Speaker, over a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. It may be expected that an error detected in the NLRI descriptor TLVs would result in that specific NLRI update being unusable and hence its update to be discarded along with an error log. While an error in Attribute TLVs would result in only that specific attribute being discarded with an error log. The operator MUST be provided with the options of configuring, enabling, and disabling the advertisement of each of the PeerNode SID, PeerAdj SID, and PeerSet SID as well as control of which information is advertised to which internal or external peer. This is not different from what is required by a BGP speaker in terms of information origination and advertisement. BGP Peering Segments are associated with the normal BGP routing peering sessions. However, the BGP peering information along with these Peering Segments themselves are advertised via a distinct BGP- LS peering session. It is expected that this isolation as described in [RFC7752] is followed when advertising BGP peering topology information via BGP-LS. BGP-EPE functionality enables the capability for instantiation of an SR path for traffic engineering a flow via an egress BGP router to a specific peer, bypassing the normal BGP best path routing for that flow and any routing policies implemented in BGP on that egress BGP router. As with any traffic engineering solution, the controller or application implementing the policy needs to ensure that there is no looping or mis-routing of traffic. Traffic counters corresponding to Previdi, et al. Expires November 17, 2019 [Page 14] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 the MPLS label of the BGP Peering SID on the router would indicate the traffic being forwarded based on the specific EPE path. Monitoring these counters and the flows hitting the corresponding MPLS forwarding entry would help identify issues, if any, with traffic engineering over the EPE paths. Errors in the encoding or decoding of the SR information in the TLVs defined in this document may result in the unavailability of such information to a Centralized EPE Controller or incorrect information being made available to it. This may result in the controller not being able to perform the desired SR based optimization functionality or to perform it in an unexpected or inconsistent manner. The handling of such errors by applications like such a controller may be implementation specific and out of scope of this document. 7. Security Considerations [RFC7752] defines BGP-LS NLRI to which the extensions defined in this document apply. The Security Considerations section of [RFC7752] also applies to these extensions. The procedures and new TLVs defined in this document, by themselves, do not affect the BGP-LS security model discussed in [RFC7752]. BGP-EPE enables engineering of traffic when leaving the administrative domain via an egress BGP router. Therefore precaution is necessary to ensure that the BGP peering information collected via BGP-LS is limited to specific consumers in a secure manner. Segment Routing operates within a trusted domain [RFC8402] and its security considerations also apply to BGP Peering Segments. The BGP-EPE policies are expected to be used entirely within this trusted SR domain (e.g., between multiple AS/domains within a single provider network). The isolation of BGP-LS peering sessions is also required to ensure that BGP-LS topology information (including the newly added BGP peering topology) is not advertised to an external BGP peering session outside an administrative domain. 8. Contributors Mach (Guoyi) Chen Huawei Technologies China Email: mach.chen@huawei.com Previdi, et al. Expires November 17, 2019 [Page 15] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Acee Lindem Cisco Systems Inc. US Email: acee@cisco.com 9. Acknowledgements The authors would like to thank Jakob Heitz, Howard Yang, Hannes Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their feedback and comments. Susan Hares helped in improving the clarity of the document with her substantial contributions during her shepherd's review. The authors would also like to thank Alvaro Retana for his extensive review and comments which helped correct issues and improve the document. 10. References 10.1. Normative References [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-14 (work in progress), May 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, . [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . Previdi, et al. Expires November 17, 2019 [Page 16] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 10.2. Informative References [I-D.dawra-idr-bgpls-srv6-ext] Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and H. Elmalky, "BGP Link State Extensions for SRv6", draft- dawra-idr-bgpls-srv6-ext-06 (work in progress), March 2019. [I-D.ietf-spring-segment-routing-central-epe] Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", draft-ietf-spring-segment-routing-central- epe-10 (work in progress), December 2017. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-03 (work in progress), May 2019. Authors' Addresses Stefano Previdi Individual Email: stefano@previdi.net Ketan Talaulikar (editor) Cisco Systems, Inc. India Email: ketant@cisco.com Previdi, et al. Expires November 17, 2019 [Page 17] Internet-Draft Segment Routing EPE BGP-LS Extensions May 2019 Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Keyur Patel Arrcus, Inc. Email: Keyur@arrcus.com Saikat Ray Individual Contributor Email: raysaikat@gmail.com Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Previdi, et al. Expires November 17, 2019 [Page 18] ./draft-ietf-ippm-initial-registry-16.txt0000644000764400076440000046205713631527063017645 0ustar iustyiusty Network Working Group A. Morton Internet-Draft AT&T Labs Intended status: Standards Track M. Bagnulo Expires: September 10, 2020 UC3M P. Eardley BT K. D'Souza AT&T Labs March 9, 2020 Initial Performance Metrics Registry Entries draft-ietf-ippm-initial-registry-16 Abstract This memo defines the set of Initial Entries for the IANA Performance Metrics Registry. The set includes: UDP Round-trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP Round-trip Latency and Loss, and TCP round-trip Latency and Loss. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2020. Morton, et al. Expires September 10, 2020 [Page 1] Internet-Draft Initial Registry March 2020 Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Registry Categories and Columns . . . . . . . . . . . . . . . 7 4. UDP Round-trip Latency and Loss Registry Entries . . . . . . 8 4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 9 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.4. Description . . . . . . . . . . . . . . . . . . . . . 9 4.1.5. Change Controller . . . . . . . . . . . . . . . . . . 9 4.1.6. Version (of Registry Format) . . . . . . . . . . . . 9 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 10 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 10 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 11 4.3.1. Reference Method . . . . . . . . . . . . . . . . . . 11 4.3.2. Packet Stream Generation . . . . . . . . . . . . . . 12 4.3.3. Traffic Filtering (observation) Details . . . . . . . 13 4.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 13 4.3.5. Run-time Parameters and Data Format . . . . . . . . . 13 4.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4.2. Reference Definition . . . . . . . . . . . . . . . . 14 4.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 15 4.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 15 4.5. Administrative items . . . . . . . . . . . . . . . . . . 16 4.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 16 4.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 16 Morton, et al. Expires September 10, 2020 [Page 2] Internet-Draft Initial Registry March 2020 4.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 5. Packet Delay Variation Registry Entry . . . . . . . . . . . . 16 5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 16 5.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 5.1.5. Change Controller . . . . . . . . . . . . . . . . . . 17 5.1.6. Version (of Registry Format) . . . . . . . . . . . . 17 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 19 5.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 5.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 5.3.3. Traffic Filtering (observation) Details . . . . . . . 20 5.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 5.3.5. Run-time Parameters and Data Format . . . . . . . . . 20 5.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4.2. Reference Definition . . . . . . . . . . . . . . . . 21 5.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22 5.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 5.5. Administrative items . . . . . . . . . . . . . . . . . . 23 5.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 5.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 23 5.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 5.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 5.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 6. DNS Response Latency and Loss Registry Entries . . . . . . . 23 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 24 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.4. Description . . . . . . . . . . . . . . . . . . . . . 24 6.1.5. Change Controller . . . . . . . . . . . . . . . . . . 24 6.1.6. Version (of Registry Format) . . . . . . . . . . . . 24 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 24 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 24 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 25 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 27 6.3.1. Reference Method . . . . . . . . . . . . . . . . . . 27 6.3.2. Packet Stream Generation . . . . . . . . . . . . . . 28 6.3.3. Traffic Filtering (observation) Details . . . . . . . 29 6.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 29 6.3.5. Run-time Parameters and Data Format . . . . . . . . . 29 6.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 30 Morton, et al. Expires September 10, 2020 [Page 3] Internet-Draft Initial Registry March 2020 6.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 30 6.4.2. Reference Definition . . . . . . . . . . . . . . . . 31 6.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 31 6.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 31 6.5. Administrative items . . . . . . . . . . . . . . . . . . 32 6.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 32 6.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 32 6.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 32 6.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 32 6.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 32 7. UDP Poisson One-way Delay and Loss Registry Entries . . . . . 32 7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 33 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 33 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 34 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 34 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 35 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 36 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 36 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 36 7.3.3. Traffic Filtering (observation) Details . . . . . . . 37 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 37 7.3.5. Run-time Parameters and Data Format . . . . . . . . . 37 7.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 38 7.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 38 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 38 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 38 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 41 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 41 7.5. Administrative items . . . . . . . . . . . . . . . . . . 42 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 42 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 42 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 42 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 43 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 43 8. UDP Periodic One-way Delay and Loss Registry Entries . . . . 43 8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 43 8.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.1.4. Description . . . . . . . . . . . . . . . . . . . . . 44 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 44 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 44 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 45 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 46 Morton, et al. Expires September 10, 2020 [Page 4] Internet-Draft Initial Registry March 2020 8.3.1. Reference Method . . . . . . . . . . . . . . . . . . 46 8.3.2. Packet Stream Generation . . . . . . . . . . . . . . 47 8.3.3. Traffic Filtering (observation) Details . . . . . . . 48 8.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 48 8.3.5. Run-time Parameters and Data Format . . . . . . . . . 48 8.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 48 8.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 49 8.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 49 8.4.2. Reference Definition . . . . . . . . . . . . . . . . 49 8.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 52 8.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 52 8.5. Administrative items . . . . . . . . . . . . . . . . . . 53 8.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 53 8.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 53 8.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 53 8.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 53 8.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 54 9. ICMP Round-trip Latency and Loss Registry Entries . . . . . . 54 9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . . 54 9.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.1.4. Description . . . . . . . . . . . . . . . . . . . . . 55 9.1.5. Change Controller . . . . . . . . . . . . . . . . . . 55 9.1.6. Version (of Registry Format) . . . . . . . . . . . . 55 9.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 55 9.2.1. Reference Definition . . . . . . . . . . . . . . . . 55 9.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 56 9.3. Method of Measurement . . . . . . . . . . . . . . . . . . 57 9.3.1. Reference Method . . . . . . . . . . . . . . . . . . 57 9.3.2. Packet Stream Generation . . . . . . . . . . . . . . 58 9.3.3. Traffic Filtering (observation) Details . . . . . . . 59 9.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 59 9.3.5. Run-time Parameters and Data Format . . . . . . . . . 59 9.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 59 9.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 60 9.4.2. Reference Definition . . . . . . . . . . . . . . . . 60 9.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 62 9.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 62 9.5. Administrative items . . . . . . . . . . . . . . . . . . 62 9.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 62 9.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 63 9.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 63 9.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 63 9.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 63 10. TCP Round-Trip Delay and Loss Registry Entries . . . . . . . 63 10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 63 Morton, et al. Expires September 10, 2020 [Page 5] Internet-Draft Initial Registry March 2020 10.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 63 10.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 63 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 64 10.1.4. Description . . . . . . . . . . . . . . . . . . . . 64 10.1.5. Change Controller . . . . . . . . . . . . . . . . . 64 10.1.6. Version (of Registry Format) . . . . . . . . . . . . 64 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 65 10.2.1. Reference Definitions . . . . . . . . . . . . . . . 65 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 67 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 68 10.3.1. Reference Methods . . . . . . . . . . . . . . . . . 68 10.3.2. Packet Stream Generation . . . . . . . . . . . . . . 70 10.3.3. Traffic Filtering (observation) Details . . . . . . 70 10.3.4. Sampling Distribution . . . . . . . . . . . . . . . 70 10.3.5. Run-time Parameters and Data Format . . . . . . . . 70 10.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 71 10.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 71 10.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 71 10.4.2. Reference Definition . . . . . . . . . . . . . . . . 71 10.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 73 10.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 73 10.5. Administrative items . . . . . . . . . . . . . . . . . . 73 10.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 73 10.5.2. Requester . . . . . . . . . . . . . . . . . . . . . 73 10.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 74 10.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 74 10.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 75 14.1. Normative References . . . . . . . . . . . . . . . . . . 75 14.2. Informative References . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 1. Introduction This memo proposes an initial set of entries for the Performance Metrics Registry. It uses terms and definitions from the IPPM literature, primarily [RFC2330]. Although there are several standard templates for organizing specifications of performance metrics (see [RFC7679] for an example of the traditional IPPM template, based to large extent on the Benchmarking Methodology Working Group's traditional template in [RFC1242], and see [RFC6390] for a similar template), none of these templates were intended to become the basis for the columns of an IETF-wide registry of metrics. While examining aspects of metric Morton, et al. Expires September 10, 2020 [Page 6] Internet-Draft Initial Registry March 2020 specifications which need to be registered, it became clear that none of the existing metric templates fully satisfies the particular needs of a registry. Therefore, [I-D.ietf-ippm-metric-registry] defines the overall format for a Performance Metrics Registry. Section 5 of [I-D.ietf-ippm-metric-registry] also gives guidelines for those requesting registration of a Metric, that is the creation of entry(s) in the Performance Metrics Registry: "In essence, there needs to be evidence that a candidate Registered Performance Metric has significant industry interest, or has seen deployment, and there is agreement that the candidate Registered Performance Metric serves its intended purpose." The process in [I-D.ietf-ippm-metric-registry] also requires that new entries are administered by IANA through Specification Required policy, which will ensure that the metrics are tightly defined. 2. Scope This document defines a set of initial Performance Metrics Registry entries. Most are Active Performance Metrics, which are based on RFCs prepared in the IPPM working group of the IETF, according to their framework [RFC2330] and its updates. 3. Registry Categories and Columns This memo uses the terminology defined in [I-D.ietf-ippm-metric-registry]. This section provides the categories and columns of the registry, for easy reference. An entry (row) therefore gives a complete description of a Registered Metric. Morton, et al. Expires September 10, 2020 [Page 7] Internet-Draft Initial Registry March 2020 Legend: Registry Categories and Columns, shown as Category ------------------ Column | Column | Summary ------------------------------------------------------------------------ Identifier | Name | URI | Desc. | Reference | Change Controller | Ver | Metric Definition ----------------------------------------- Reference Definition | Fixed Parameters | Method of Measurement --------------------------------------------------------------------- Reference | Packet | Traffic | Sampling | Run-time | Role | Method | Stream | Filter | Distribution | Parameters | | | Generation | Output ----------------------------------------- Type | Reference | Units | Calibration | | Definition | | | Administrative Information ------------------------------------ Status |Requester | Rev | Rev.Date | Comments and Remarks -------------------- 4. UDP Round-trip Latency and Loss Registry Entries This section specifies an initial registry entry for the UDP Round- trip Latency, and another entry for UDP Round-trip Loss Ratio. Note: Each Registry entry only produces a "raw" output or a statistical summary. To describe both "raw" and one or more statistics efficiently, the Identifier, Name, and Output Categories can be split and a single section can specify two or more closely- related metrics. For example, this section specifies two Registry entries with many common columns. See Section 7 for an example specifying multiple Registry entries with many common columns. All column entries beside the ID, Name, Description, and Output Reference Method categories are the same, thus this section proposes Morton, et al. Expires September 10, 2020 [Page 8] Internet-Draft Initial Registry March 2020 two closely-related registry entries. As a result, IANA is also asked to assign a corresponding URL to each Named Metric. 4.1. Summary This category includes multiple indexes to the registry entry: the element ID and metric name. 4.1.1. ID (Identifier) IANA is asked to assign different numeric identifiers to each of the two Named Metrics. 4.1.2. Name RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio 4.1.3. URI URL: https://www.iana.org/ ... 4.1.4. Description RTDelay: This metric assesses the delay of a stream of packets exchanged between two hosts (which are the two measurement points), and the Output is the Round-trip delay for all successfully exchanged packets expressed as the 95th percentile of their conditional delay distribution. RTLoss: This metric assesses the loss ratio of a stream of packets exchanged between two hosts (which are the two measurement points), and the Output is the Round-trip loss ratio for all successfully exchanged packets expressed as a percentage. 4.1.5. Change Controller IETF 4.1.6. Version (of Registry Format) 1.0 Morton, et al. Expires September 10, 2020 [Page 9] Internet-Draft Initial Registry March 2020 4.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 4.2.1. Reference Definition Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) Round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. Note that although the [RFC2681] definition of "Round-trip-Delay between Src and Dst" is directionally ambiguous in the text, this metric tightens the definition further to recognize that the host in the "Src" role will send the first packet to "Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). Finally, note that the variable "dT" is used in [RFC2681] to refer to the value of Round-trip delay in metric definitions and methods. The variable "dT" has been re-used in other IPPM literature to refer to different quantities, and cannot be used as a global variable name. Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. [RFC6673] Both delay and loss metrics employ a maximum waiting time for received packets, so the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 4.2.2. Fixed Parameters Type-P as defined in Section 13 of [RFC2330]: o IPv4 header values: * DSCP: set to 0 Morton, et al. Expires September 10, 2020 [Page 10] Internet-Draft Initial Registry March 2020 * TTL: set to 255 * Protocol: set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 17 (UDP) * Flow Label: set to zero * Extension Headers: none o UDP header values: * Checksum: the checksum MUST be calculated and the non-zero checksum included in the header o UDP Payload * total of 100 bytes Other measurement parameters: o Tmax: a loss threshold waiting time * 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 4.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 4.3.1. Reference Method The methodology for this metric is defined as Type-P-Round-trip- Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under Fixed Parameters. However, the Periodic stream will be generated according to [RFC3432]. Morton, et al. Expires September 10, 2020 [Page 11] Internet-Draft Initial Registry March 2020 The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay, and counted for the RTLoss metric. The calculations on the delay (RTT) SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process which calculates the RTT value MUST enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully-arriving packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to disambiguate packet reordering if it occurs. If a standard measurement protocol is employed, then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The chosen measurement protocol will dictate the format of sequence numbers and time-stamps, if they are conveyed in the packet payload. Refer to Section 4.4 of [RFC6673] for expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of [RFC6673] presents additional requirements which MUST be included in the method of measurement for this metric. 4.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. Section 3 of [RFC3432] prescribes the method for generating Periodic streams using associated parameters. incT the nominal duration of inter-packet interval, first bit to first bit, with value 0.0200, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see Morton, et al. Expires September 10, 2020 [Page 12] Internet-Draft Initial Registry March 2020 section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). dT the duration of the interval for allowed sample start times, with value 1.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). NOTE: an initiation process with a number of control exchanges resulting in unpredictable start times (within a time interval) may be sufficient to avoid synchronization of periodic streams, and therefore a valid replacement for selecting a start time at random from a fixed interval. The T0 parameter will be reported as a measured parameter. Parameters incT and dT are Fixed Parameters. 4.3.3. Traffic Filtering (observation) Details NA 4.3.4. Sampling Distribution NA 4.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the Dst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Tf a time, the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of Morton, et al. Expires September 10, 2020 [Page 13] Internet-Draft Initial Registry March 2020 [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf is interpreted as the Duration of the measurement interval. 4.3.6. Roles Src launches each packet and waits for return transmissions from Dst. Dst waits for each packet from Src and sends a return packet to Src. 4.4. Output This category specifies all details of the Output of measurements using the metric. 4.4.1. Type Percentile -- for the conditional distribution of all packets with a valid value of Round-trip delay (undefined delays are excluded), a single value corresponding to the 95th percentile, as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of Round-trip delay for which the Empirical Distribution Function (EDF), F(95Percentile) >= 95% of the singleton Round-trip delay values in the conditional distribution. See section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF. LossRatio -- the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 4.4.2. Reference Definition For all outputs --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of Morton, et al. Expires September 10, 2020 [Page 14] Internet-Draft Initial Registry March 2020 [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. TotalPkts the count of packets sent by the Src to Dst during the measurement interval. For RTDelay_Active_IP-UDP-Periodic_RFCXXXXsec4_Seconds_95Percentile: 95Percentile The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns). For RTLoss_Active_IP-UDP-Periodic_RFCXXXXsec4_Percent_LossRatio: Percentile The numeric value of the result is expressed in units of lost packets to total packets times 100%, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.0000000001. 4.4.3. Metric Units The 95th Percentile of Round-trip Delay is expressed in seconds. The Round-trip Loss Ratio is expressed as a percentage of lost packets to total packets sent. 4.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback at the Source host that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized this way. When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement with additional indication that it is a calibration result. Morton, et al. Expires September 10, 2020 [Page 15] Internet-Draft Initial Registry March 2020 Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the Output result resolution which is the result of system noise, and thus inaccurate. 4.5. Administrative items 4.5.1. Status Current 4.5.2. Requester This RFC number 4.5.3. Revision 1.0 4.5.4. Revision Date YYYY-MM-DD 4.6. Comments and Remarks None. 5. Packet Delay Variation Registry Entry This section gives an initial registry entry for a Packet Delay Variation metric. 5.1. Summary This category includes multiple indexes to the registry entries, the element ID and metric name. 5.1.1. ID (Identifier) 5.1.2. Name OWPDV_Active_IP-UDP-Periodic_RFCXXXXsec5_Seconds_95Percentile Morton, et al. Expires September 10, 2020 [Page 16] Internet-Draft Initial Registry March 2020 5.1.3. URI URL: https://www.iana.org/ ... 5.1.4. Description An assessment of packet delay variation with respect to the minimum delay observed on the periodic stream, and the Output is expressed as the 95th percentile of the packet delay variation distribution. 5.1.5. Change Controller IETF 5.1.6. Version (of Registry Format) 1.0 5.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 5.2.1. Reference Definition Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2330] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC3393] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, March 2009. [RFC5481] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC5905] See sections 2.4 and 3.4 of [RFC3393]. Singleton delay differences measured are referred to by the variable name "ddT" (applicable to all forms of delay variation). However, this metric entry specifies the PDV form defined in section 4.2 of [RFC5481], where the singleton PDV for packet i is referred to by the variable name "PDV(i)". Morton, et al. Expires September 10, 2020 [Page 17] Internet-Draft Initial Registry March 2020 5.2.2. Fixed Parameters o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 17 (UDP) * Flow Label: set to zero * Extension Headers: none o UDP header values: * Checksum: the checksum MUST be calculated and the non-zero checksum included in the header o UDP Payload * total of 200 bytes Other measurement parameters: Tmax: a loss threshold waiting time with value 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. F a selection function unambiguously defining the packets from the stream selected for the metric. See section 4.2 of [RFC5481] for the PDV form. See the Packet Stream generation category for two additional Fixed Parameters. Morton, et al. Expires September 10, 2020 [Page 18] Internet-Draft Initial Registry March 2020 5.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 5.3.1. Reference Method See section 2.6 and 3.6 of [RFC3393] for general singleton element calculations. This metric entry requires implementation of the PDV form defined in section 4.2 of [RFC5481]. Also see measurement considerations in section 8 of [RFC5481]. The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay. The calculations on the one-way delay SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process which calculates the one-way delay value MUST enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully-arriving packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to disambiguate packet reordering if it occurs. If a standard measurement protocol is employed, then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The chosen measurement protocol will dictate the format of sequence numbers and time-stamps, if they are conveyed in the packet payload. 5.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. Morton, et al. Expires September 10, 2020 [Page 19] Internet-Draft Initial Registry March 2020 Section 3 of [RFC3432] prescribes the method for generating Periodic streams using associated parameters. incT the nominal duration of inter-packet interval, first bit to first bit, with value 0.0200, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). dT the duration of the interval for allowed sample start times, with value 1.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). NOTE: an initiation process with a number of control exchanges resulting in unpredictable start times (within a time interval) may be sufficient to avoid synchronization of periodic streams, and therefore a valid replacement for selecting a start time at random from a fixed interval. The T0 parameter will be reported as a measured parameter. Parameters incT and dT are Fixed Parameters. 5.3.3. Traffic Filtering (observation) Details NA 5.3.4. Sampling Distribution NA 5.3.5. Run-time Parameters and Data Format Src the IP address of the host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the Dst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Morton, et al. Expires September 10, 2020 [Page 20] Internet-Draft Initial Registry March 2020 Tf a time, the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf is interpreted as the Duration of the measurement interval. 5.3.6. Roles Src launches each packet and waits for return transmissions from Dst. Dst waits for each packet from Src and sends a return packet to Src. 5.4. Output This category specifies all details of the Output of measurements using the metric. 5.4.1. Type Percentile -- for the conditional distribution of all packets with a valid value of one-way delay (undefined delays are excluded), a single value corresponding to the 95th percentile, as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of one-way PDV for which the Empirical Distribution Function (EDF), F(95Percentile) >= 95% of the singleton one-way PDV values in the conditional distribution. See section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF. 5.4.2. Reference Definition T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Morton, et al. Expires September 10, 2020 [Page 21] Internet-Draft Initial Registry March 2020 95Percentile The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 5.4.3. Metric Units The 95th Percentile of one-way PDV is expressed in seconds. 5.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized this way. For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets [RFC5905] of clocks at both the source and destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets are smoothed, thus the random variation is not usually represented in the results). time_offset The time value of the result is expressed in units of seconds, as a signed value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement with additional indication that it is a calibration result. In any measurement, the measurement function SHOULD report its current estimate of time offset [RFC5905] as an indicator of the degree of synchronization. Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the Output result resolution which is the result of system noise, and thus inaccurate. Morton, et al. Expires September 10, 2020 [Page 22] Internet-Draft Initial Registry March 2020 5.5. Administrative items 5.5.1. Status Current 5.5.2. Requester This RFC number 5.5.3. Revision 1.0 5.5.4. Revision Date YYYY-MM-DD 5.6. Comments and Remarks Lost packets represent a challenge for delay variation metrics. See section 4.1 of [RFC3393] and the delay variation applicability statement[RFC5481] for extensive analysis and comparison of PDV and an alternate metric, IPDV. 6. DNS Response Latency and Loss Registry Entries This section gives initial registry entries for DNS Response Latency and Loss from a network user's perspective, for a specific named resource. The metric can be measured repeatedly using different names. RFC 2681 [RFC2681] defines a Round-trip delay metric. We build on that metric by specifying several of the input parameters to precisely define two metrics for measuring DNS latency and loss. Note to IANA: Each Registry "Name" below specifies a single registry entry, whose output format varies in accordance with the name. All column entries beside the ID, Name, Description, and Output Reference Method categories are the same, thus this section proposes two closely-related registry entries. As a result, IANA is also asked to assign corresponding URLs to each Named Metric. 6.1. Summary This category includes multiple indexes to the registry entries, the element ID and metric name. Morton, et al. Expires September 10, 2020 [Page 23] Internet-Draft Initial Registry March 2020 6.1.1. ID (Identifier) IANA is asked to assign different numeric identifiers to each of the two Named Metrics. 6.1.2. Name RTDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Seconds_Raw RLDNS_Active_IP-UDP-Poisson_RFCXXXXsec6_Logical_Raw 6.1.3. URI URL: https://www.iana.org/ ... 6.1.4. Description This is a metric for DNS Response performance from a network user's perspective, for a specific named resource. The metric can be measured repeatedly using different resource names. RTDNS: This metric assesses the response time, the interval from the query transmission to the response. RLDNS: This metric indicates that the response was deemed lost. In other words, the response time exceeded the maximum waiting time. 6.1.5. Change Controller IETF 6.1.6. Version (of Registry Format) 1.0 6.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 6.2.1. Reference Definition Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. (and updates) Morton, et al. Expires September 10, 2020 [Page 24] Internet-Draft Initial Registry March 2020 [RFC1035] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) Round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. For DNS Response Latency, the entities in [RFC1035] must be mapped to [RFC2681]. The Local Host with its User Program and Resolver take the role of "Src", and the Foreign Name Server takes the role of "Dst". Note that although the [RFC2681] definition of "Round-trip-Delay between Src and Dst at T" is directionally ambiguous in the text, this metric tightens the definition further to recognize that the host in the "Src" role will send the first packet to "Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. [RFC6673] Both response time and loss metrics employ a maximum waiting time for received responses, so the count of lost packets to total packets sent is the basis for the loss determination as per Section 4.3 of [RFC6673]. 6.2.2. Fixed Parameters Type-P as defined in Section 13 of [RFC2330]: o IPv4 header values: * DSCP: set to 0 * TTL set to 255 * Protocol: set to 17 (UDP) o IPv6 header values: Morton, et al. Expires September 10, 2020 [Page 25] Internet-Draft Initial Registry March 2020 * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 17 (UDP) * Flow Label: set to zero * Extension Headers: none o UDP header values: * Source port: 53 * Destination port: 53 * Checksum: the checksum must be calculated and the non-zero checksum included in the header o Payload: The payload contains a DNS message as defined in RFC 1035 [RFC1035] with the following values: * The DNS header section contains: + Identification (see the Run-time column) + QR: set to 0 (Query) + OPCODE: set to 0 (standard query) + AA: not set + TC: not set + RD: set to one (recursion desired) + RA: not set + RCODE: not set + QDCOUNT: set to one (only one entry) + ANCOUNT: not set + NSCOUNT: not set + ARCOUNT: not set Morton, et al. Expires September 10, 2020 [Page 26] Internet-Draft Initial Registry March 2020 * The Question section contains: + QNAME: the Fully Qualified Domain Name (FQDN) provided as input for the test, see the Run-time column + QTYPE: the query type provided as input for the test, see the Run-time column + QCLASS: set to 1 for IN * The other sections do not contain any Resource Records. Other measurement parameters: o Tmax: a loss threshold waiting time (and to help disambiguate queries) * 5.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. Observation: reply packets will contain a DNS response and may contain RRs. 6.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 6.3.1. Reference Method The methodology for this metric is defined as Type-P-Round-trip- Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 3.6 of RFC 2681 [RFC2681] using the Type-P and Timeout defined under Fixed Parameters. The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a response packet lost. Lost packets SHALL be designated as having undefined delay and counted for the RLDNS metric. The calculations on the delay (RTT) SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process Morton, et al. Expires September 10, 2020 [Page 27] Internet-Draft Initial Registry March 2020 which calculates the RTT value MUST enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully-arriving reply. DNS Messages bearing Queries provide for random ID Numbers in the Identification header field, so more than one query may be launched while a previous request is outstanding when the ID Number is used. Therefore, the ID Number MUST be retained at the Src and included with each response packet to disambiguate packet reordering if it occurs. IF a DNS response does not arrive within Tmax, the response time RTDNS is undefined, and RLDNS = 1. The Message ID SHALL be used to disambiguate the successive queries that are otherwise identical. Since the ID Number field is only 16 bits in length, it places a limit on the number of simultaneous outstanding DNS queries during a stress test from a single Src address. Refer to Section 4.4 of [RFC6673] for expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of RFC 2681 [RFC2681]. However, the DNS Server is expected to perform all required functions to prepare and send a response, so the response time will include processing time and network delay. Section 8 of [RFC6673] presents additional requirements which SHALL be included in the method of measurement for this metric. In addition to operations described in [RFC2681], the Src MUST parse the DNS headers of the reply and prepare the query response information for subsequent reporting as a measured result, along with the Round-Trip Delay. 6.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. Morton, et al. Expires September 10, 2020 [Page 28] Internet-Draft Initial Registry March 2020 Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to generate Poisson sampling intervals. The reciprocal of lambda is the average packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/lambda, in seconds. Method 3 is used, where given a start time (Run-time Parameter), the subsequent send times are all computed prior to measurement by computing the pseudo-random distribution of inter-packet send times, (truncating the distribution as specified in the Run-time Parameters), and the Src sends each packet at the computed times. Note that Trunc is the upper limit on inter-packet times in the Poisson distribution. A random value greater than Trunc is set equal to Trunc instead. 6.3.3. Traffic Filtering (observation) Details NA 6.3.4. Sampling Distribution NA 6.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the Dst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Tf a time, the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of Morton, et al. Expires September 10, 2020 [Page 29] Internet-Draft Initial Registry March 2020 [RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf is interpreted as the Duration of the measurement interval. Reciprocal_lambda average packet interval for Poisson Streams expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. Trunc Upper limit on Poisson distribution expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905] (values above this limit will be clipped and set to the limit value). ID The 16-bit identifier assigned by the program that generates the query, and which must vary in successive queries (a list of IDs is needed), see Section 4.1.1 of [RFC1035]. This identifier is copied into the corresponding reply and can be used by the requester (Src) to match-up replies to outstanding queries. QNAME The domain name of the Query, formatted as specified in section 4 of [RFC6991]. QTYPE The Query Type, which will correspond to the IP address family of the query (decimal 1 for IPv4 or 28 for IPv6, formatted as a uint16, as per section 9.2 of [RFC6020]. 6.3.6. Roles Src launches each packet and waits for return transmissions from Dst. Dst waits for each packet from Src and sends a return packet to Src. 6.4. Output This category specifies all details of the Output of measurements using the metric. 6.4.1. Type Raw -- for each DNS Query packet sent, sets of values as defined in the next column, including the status of the response, only assigning delay values to successful query-response pairs. Morton, et al. Expires September 10, 2020 [Page 30] Internet-Draft Initial Registry March 2020 6.4.2. Reference Definition For all outputs: T the time the DNS Query was sent during the measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. dT The time value of the round-trip delay to receive the DNS response, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905]. This value is undefined when the response packet is not received at Src within waiting time Tmax seconds. Rcode The value of the Rcode field in the DNS response header, expressed as a uint64 as specified in section 9.2 of [RFC6020]. Non-zero values convey errors in the response, and such replies must be analyzed separately from successful requests. 6.4.3. Metric Units RTDNS: Round-trip Delay, dT, is expressed in seconds. RTLDNS: the Logical value, where 1 = Lost and 0 = Received. 6.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback at the Source host that includes as much of the measurement system as possible, performs address and payload manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send- receive interface contention. Some portion of the random and systematic error can be characterized this way. When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement with additional indication that it is a calibration result. Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the Morton, et al. Expires September 10, 2020 [Page 31] Internet-Draft Initial Registry March 2020 portion of the Output result resolution which is the result of system noise, and thus inaccurate. 6.5. Administrative items 6.5.1. Status Current 6.5.2. Requester This RFC number 6.5.3. Revision 1.0 6.5.4. Revision Date YYYY-MM-DD 6.6. Comments and Remarks None 7. UDP Poisson One-way Delay and Loss Registry Entries This section specifies five initial registry entries for the UDP Poisson One-way Delay, and one for UDP Poisson One-way Loss. IANA Note: Registry "Name" below specifies multiple registry entries, whose output format varies according to the element of the name that specifies one form of statistical summary. There is an additional metric name for the Loss metric. All column entries beside the ID, Name, Description, and Output Reference Method categories are the same, thus this section proposes six closely-related registry entries. As a result, IANA is also asked to assign corresponding URLs to each Named Metric. 7.1. Summary This category includes multiple indexes to the registry entries, the element ID and metric name. Morton, et al. Expires September 10, 2020 [Page 32] Internet-Draft Initial Registry March 2020 7.1.1. ID (Identifier) IANA is asked to assign different numeric identifiers to each of the six Metrics. 7.1.2. Name OWDelay_Active_IP-UDP-Poisson- Payload250B_RFCXXXXsec7_Seconds_ where is one of: o 95Percentile o Mean o Min o Max o StdDev OWLoss_Active_IP-UDP-Poisson- Payload250B_RFCXXXXsec7_Percent_LossRatio 7.1.3. URI URL: https://www.iana.org/ ... 7.1.4. Description OWDelay: This metric assesses the delay of a stream of packets exchanged between two hosts (or measurement points), and reports the One-way delay for all successfully exchanged packets based on their conditional delay distribution. where is one of: o 95Percentile o Mean o Min o Max o StdDev Morton, et al. Expires September 10, 2020 [Page 33] Internet-Draft Initial Registry March 2020 OWLoss: This metric assesses the loss ratio of a stream of packets exchanged between two hosts (which are the two measurement points), and the Output is the One-way loss ratio for all successfully received packets expressed as a percentage. 7.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 7.2.1. Reference Definition For Delay: Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . [RFC7679] Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 6049, January 2011. [RFC6049] Section 3.4 of [RFC7679] provides the reference definition of the singleton (single value) One-way delay metric. Section 4.4 of [RFC7679] provides the reference definition expanded to cover a multi-value sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. Only successful packet transfers with finite delay are included in the sample, as prescribed in section 4.1.2 of [RFC6049]. For loss: Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 10.17487/RFC7680, January 2016, . Section 2.4 of [RFC7680] provides the reference definition of the singleton (single value) one-way loss metric. Section 3.4 of [RFC7680] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. Morton, et al. Expires September 10, 2020 [Page 34] Internet-Draft Initial Registry March 2020 7.2.2. Fixed Parameters Type-P: o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: Set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 17 (UDP) * Flow Label: set to zero * Extension Headers: none o UDP header values: * Checksum: the checksum MUST be calculated and the non-zero checksum included in the header o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] * Security features in use influence the number of Padding octets. * 250 octets total, including the TWAMP format type, which MUST be reported. Other measurement parameters: Tmax: a loss threshold waiting time with value 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. See the Packet Stream generation category for two additional Fixed Parameters. Morton, et al. Expires September 10, 2020 [Page 35] Internet-Draft Initial Registry March 2020 7.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 7.3.1. Reference Method The methodology for this metric is defined as Type-P-One-way-Delay- Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay, and counted for the OWLoss metric. The calculations on the one-way delay SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process which calculates the one-way delay value MUST enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully-arriving packet. Since a standard measurement protocol is employed [RFC5357], then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The measurement protocol dictates the format of sequence numbers and time-stamps conveyed in the TWAMP-Test packet payload. 7.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. Section 11.1.3 of RFC 2681 [RFC2330] provides three methods to generate Poisson sampling intervals. The reciprocal of lambda is the Morton, et al. Expires September 10, 2020 [Page 36] Internet-Draft Initial Registry March 2020 average packet spacing, thus the Run-time Parameter is Reciprocal_lambda = 1/lambda, in seconds. Method 3 SHALL be used, where given a start time (Run-time Parameter), the subsequent send times are all computed prior to measurement by computing the pseudo-random distribution of inter- packet send times, (truncating the distribution as specified in the Parameter Trunc), and the Src sends each packet at the computed times. Note that Trunc is the upper limit on inter-packet times in the Poisson distribution. A random value greater than Trunc is set equal to Trunc instead. Reciprocal_lambda average packet interval for Poisson Streams expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. Reciprocal_lambda = 1 second. Trunc Upper limit on Poisson distribution expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) with resolution of 0.0001 seconds (0.1 ms), and with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905] (values above this limit will be clipped and set to the limit value). Trunc = 30.0000 seconds. 7.3.3. Traffic Filtering (observation) Details NA 7.3.4. Sampling Distribution NA 7.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Morton, et al. Expires September 10, 2020 [Page 37] Internet-Draft Initial Registry March 2020 Dst the IP address of the host in the Dst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Tf a time, the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf is interpreted as the Duration of the measurement interval. 7.3.6. Roles Src launches each packet and waits for return transmissions from Dst. This is the TWAMP Session-Sender. Dst waits for each packet from Src and sends a return packet to Src. This is the TWAMP Session-Reflector. 7.4. Output This category specifies all details of the Output of measurements using the metric. 7.4.1. Type See subsection titles below for Types. 7.4.2. Reference Definition For all output types --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Morton, et al. Expires September 10, 2020 [Page 38] Internet-Draft Initial Registry March 2020 For LossRatio -- the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 4.1 of [RFC7680]. For each , one of the following sub-sections apply: 7.4.2.1. Percentile95 The 95th percentile SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3 of [RFC3393] for details on the percentile statistic (where Round-trip delay should be substituted for "ipdv"). The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of one-way delay for which the Empirical Distribution Function (EDF), F(95Percentile) >= 95% of the singleton one-way delay values in the conditional distribution. See section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF. 95Percentile The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 7.4.2.2. Mean The mean SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.2.2 of [RFC6049] for details on calculating this statistic, and 4.2.3 of [RFC6049]. Mean The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 Morton, et al. Expires September 10, 2020 [Page 39] Internet-Draft Initial Registry March 2020 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 7.4.2.3. Min The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for details on calculating this statistic, and 4.3.3 of [RFC6049]. Min The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 7.4.2.4. Max The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic, and 4.3.3 of [RFC6049]. The formula is as follows: Max = (FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n Max The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] Morton, et al. Expires September 10, 2020 [Page 40] Internet-Draft Initial Registry March 2020 7.4.2.5. Std_Dev The Std_Dev SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 6.1.4 of [RFC6049] for a closely related method for calculating this statistic. The formula is the classic calculation for standard deviation of a population. Define Population Std_Dev_Delay as follows: (where all packets n = 1 through N have a value for Delay[n], and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the Square Root function: _ _ | N | | --- | | 1 \ 2 | Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) | | (N) / | | --- | | n = 1 | |_ _| Std_Dev The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 7.4.3. Metric Units The of One-way Delay is expressed in seconds. The One-way Loss Ratio is expressed as a percentage of lost packets to total packets sent. 7.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., Morton, et al. Expires September 10, 2020 [Page 41] Internet-Draft Initial Registry March 2020 deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized this way. For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets [RFC5905] of clocks at both the source and destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets [RFC5905] are smoothed, thus the random variation is not usually represented in the results). time_offset The time value of the result is expressed in units of seconds, as a signed value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement with additional indication that it is a calibration result. In any measurement, the measurement function SHOULD report its current estimate of time offset [RFC5905] as an indicator of the degree of synchronization. Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the Output result resolution which is the result of system noise, and thus inaccurate. 7.5. Administrative items 7.5.1. Status Current 7.5.2. Requester This RFC number 7.5.3. Revision 1.0 Morton, et al. Expires September 10, 2020 [Page 42] Internet-Draft Initial Registry March 2020 7.5.4. Revision Date YYYY-MM-DD 7.6. Comments and Remarks None 8. UDP Periodic One-way Delay and Loss Registry Entries This section specifies five initial registry entries for the UDP Periodic One-way Delay, and one for UDP Periodic One-way Loss. IANA Note: Registry "Name" below specifies multiple registry entries, whose output format varies according to the element of the name that specifies one form of statistical summary. There is an additional metric name for the Loss metric. All column entries beside the ID, Name, Description, and Output Reference Method categories are the same, thus this section proposes six closely-related registry entries. As a result, IANA is also asked to assign corresponding URLs to each Named Metric. 8.1. Summary This category includes multiple indexes to the registry entries, the element ID and metric name. 8.1.1. ID (Identifier) IANA is asked to assign a different numeric identifiers to each of the six Metrics. 8.1.2. Name OWDelay_Active_IP-UDP-Periodic20m- Payload142B_RFCXXXXsec8_Seconds_ where is one of: o 95Percentile o Mean o Min o Max Morton, et al. Expires September 10, 2020 [Page 43] Internet-Draft Initial Registry March 2020 o StdDev OWLoss_Active_IP-UDP-Periodic- Payload142B_RFCXXXXsec8_Percent_LossRatio 8.1.3. URI URL: https://www.iana.org/ ... 8.1.4. Description OWDelay: This metric assesses the delay of a stream of packets exchanged between two hosts (or measurement points), and reports the One-way delay for all successfully exchanged packets based on their conditional delay distribution. where is one of: o 95Percentile o Mean o Min o Max o StdDev OWLoss: This metric assesses the loss ratio of a stream of packets exchanged between two hosts (which are the two measurement points), and the Output is the One-way loss ratio for all successfully received packets expressed as a percentage. 8.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 8.2.1. Reference Definition For Delay: Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One- Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . Morton, et al. Expires September 10, 2020 [Page 44] Internet-Draft Initial Registry March 2020 [RFC7679] Morton, A., and Stephan, E., "Spatial Composition of Metrics", RFC 6049, January 2011. [RFC6049] Section 3.4 of [RFC7679] provides the reference definition of the singleton (single value) One-way delay metric. Section 4.4 of [RFC7679] provides the reference definition expanded to cover a multi-value sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. Only successful packet transfers with finite delay are included in the sample, as prescribed in section 4.1.2 of [RFC6049]. For loss: Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., "A One- Way Loss Metric for IP Performance Metrics (IPPM)", RFC 7680, DOI 10.17487/RFC7680, January 2016, . Section 2.4 of [RFC7680] provides the reference definition of the singleton (single value) one-way loss metric. Section 3.4 of [RFC7680] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. 8.2.2. Fixed Parameters Type-P: o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: Set to 17 (UDP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 17 (UDP) Morton, et al. Expires September 10, 2020 [Page 45] Internet-Draft Initial Registry March 2020 * Flow Label: set to zero * Extension Headers: none o UDP header values: * Checksum: the checksum MUST be calculated and the non-zero checksum included in the header o UDP Payload: TWAMP Test Packet Formats, Section 4.1.2 of [RFC5357] * Security features in use influence the number of Padding octets. * 142 octets total, including the TWAMP format (and format type MUST be reported, if used) Other measurement parameters: Tmax: a loss threshold waiting time with value 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. See the Packet Stream generation category for two additional Fixed Parameters. 8.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 8.3.1. Reference Method The methodology for this metric is defined as Type-P-One-way-Delay- Poisson-Stream in section 3.6 of [RFC7679] and section 4.6 of [RFC7679] using the Type-P and Tmax defined under Fixed Parameters. However, a Periodic stream is used, as defined in [RFC3432]. The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay, and counted for the OWLoss metric. Morton, et al. Expires September 10, 2020 [Page 46] Internet-Draft Initial Registry March 2020 The calculations on the one-way delay SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process which calculates the one-way delay value MUST enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully-arriving packet. Since a standard measurement protocol is employed [RFC5357], then the measurement process will determine the sequence numbers or timestamps applied to test packets after the Fixed and Runtime parameters are passed to that process. The measurement protocol dictates the format of sequence numbers and time-stamps conveyed in the TWAMP-Test packet payload. 8.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. Section 3 of [RFC3432] prescribes the method for generating Periodic streams using associated parameters. incT the nominal duration of inter-packet interval, first bit to first bit, with value 0.0200 expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. dT the duration of the interval for allowed sample start times, with value 1.0000, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. T0 the actual start time of the periodic stream, determined from T0 and dT. Morton, et al. Expires September 10, 2020 [Page 47] Internet-Draft Initial Registry March 2020 NOTE: an initiation process with a number of control exchanges resulting in unpredictable start times (within a time interval) may be sufficient to avoid synchronization of periodic streams, and therefore a valid replacement for selecting a start time at random from a fixed interval. These stream parameters will be specified as Run-time parameters. 8.3.3. Traffic Filtering (observation) Details NA 8.3.4. Sampling Distribution NA 8.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the Dst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Tf a time, the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a end time date is ignored and Tf is interpreted as the Duration of the measurement interval. 8.3.6. Roles Src launches each packet and waits for return transmissions from Dst. This is the TWAMP Session-Sender. Morton, et al. Expires September 10, 2020 [Page 48] Internet-Draft Initial Registry March 2020 Dst waits for each packet from Src and sends a return packet to Src. This is the TWAMP Session-Reflector. 8.4. Output This category specifies all details of the Output of measurements using the metric. 8.4.1. Type See subsection titles in Reference Definition for Latency Types. 8.4.2. Reference Definition For all output types --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. For LossRatio -- the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 4.1 of [RFC7680]. For each , one of the following sub-sections apply: 8.4.2.1. Percentile95 The 95th percentile SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3 of [RFC3393] for details on the percentile statistic (where Round-trip delay should be substituted for "ipdv"). The percentile = 95, meaning that the reported delay, "95Percentile", is the smallest value of one-way delay for which the Empirical Distribution Function (EDF), F(95Percentile) >= 95% of the singleton Morton, et al. Expires September 10, 2020 [Page 49] Internet-Draft Initial Registry March 2020 one-way delay values in the conditional distribution. See section 11.3 of [RFC2330] for the definition of the percentile statistic using the EDF. 95Percentile The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 8.4.2.2. Mean The mean SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.2.2 of [RFC6049] for details on calculating this statistic, and 4.2.3 of [RFC6049]. Mean The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 8.4.2.3. Min The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for details on calculating this statistic, and 4.3.3 of [RFC6049]. Min The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] Morton, et al. Expires September 10, 2020 [Page 50] Internet-Draft Initial Registry March 2020 8.4.2.4. Max The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic, and 4.3.3 of [RFC6049]. The formula is as follows: Max = (FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n Max The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 8.4.2.5. Std_Dev The Std_Dev SHALL be calculated using the conditional distribution of all packets with a finite value of One-way delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic, and 4.3.3 of [RFC6049]. The formula is the classic calculation for standard deviation of a population. Morton, et al. Expires September 10, 2020 [Page 51] Internet-Draft Initial Registry March 2020 Define Population Std_Dev_Delay as follows: (where all packets n = 1 through N have a value for Delay[n], and MeanDelay calculated as in 7.4.2.2), and SQRT[] is the Square Root function: _ _ | N | | --- | | 1 \ 2 | Std_Dev = SQRT | ------- > (Delay[n] - MeanDelay) | | (N) / | | --- | | n = 1 | |_ _| Std_Dev The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 8.4.3. Metric Units The of One-way Delay is expressed in seconds, where is one of: o 95Percentile o Mean o Min o Max o StdDev The One-way Loss Ratio is expressed as a percentage of lost packets to total packets sent. 8.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized this way. Morton, et al. Expires September 10, 2020 [Page 52] Internet-Draft Initial Registry March 2020 For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets [RFC5905] of clocks at both the source and destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets [RFC5905] are smoothed, thus the random variation is not usually represented in the results). time_offset The time value of the result is expressed in units of seconds, as a signed value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement with additional indication that it is a calibration result. In any measurement, the measurement function SHOULD report its current estimate of time offset [RFC5905] as an indicator of the degree of synchronization. Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the Output result resolution which is the result of system noise, and thus inaccurate. 8.5. Administrative items 8.5.1. Status Current 8.5.2. Requester This RFC number 8.5.3. Revision 1.0 8.5.4. Revision Date YYYY-MM-DD Morton, et al. Expires September 10, 2020 [Page 53] Internet-Draft Initial Registry March 2020 8.6. Comments and Remarks None. 9. ICMP Round-trip Latency and Loss Registry Entries This section specifies three initial registry entries for the ICMP Round-trip Latency, and another entry for ICMP Round-trip Loss Ratio. IANA Note: Registry "Name" below specifies multiple registry entries, whose output format varies according to the element of the name that specifies one form of statistical summary. There is an additional metric name for the Loss metric. All column entries beside the ID, Name, Description, and Output Reference Method categories are the same, thus this section proposes two closely-related registry entries. As a result, IANA is also asked to assign corresponding URLs to each Named Metric. 9.1. Summary This category includes multiple indexes to the registry entry: the element ID and metric name. 9.1.1. ID (Identifier) IANA is asked to assign different numeric identifiers to each of the four Named Metrics. 9.1.2. Name RTDelay_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Seconds_ where is one of: o Mean o Min o Max RTLoss_Active_IP-ICMP-SendOnRcv_RFCXXXXsec9_Percent_LossRatio 9.1.3. URI URL: https://www.iana.org/ ... Morton, et al. Expires September 10, 2020 [Page 54] Internet-Draft Initial Registry March 2020 9.1.4. Description RTDelay: This metric assesses the delay of a stream of ICMP packets exchanged between two hosts (which are the two measurement points), and the Output is the Round-trip delay for all successfully exchanged packets expressed as the of their conditional delay distribution, where is one of: o Mean o Min o Max RTLoss: This metric assesses the loss ratio of a stream of ICMP packets exchanged between two hosts (which are the two measurement points), and the Output is the Round-trip loss ratio for all successfully exchanged packets expressed as a percentage. 9.1.5. Change Controller IETF 9.1.6. Version (of Registry Format) 1.0 9.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 9.2.1. Reference Definition Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) Round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample. Note that terms such as singleton and sample are defined in Section 11 of [RFC2330]. Note that although the [RFC2681] definition of "Round-trip-Delay between Src and Dst" is directionally ambiguous in the text, this Morton, et al. Expires September 10, 2020 [Page 55] Internet-Draft Initial Registry March 2020 metric tightens the definition further to recognize that the host in the "Src" role will send the first packet to "Dst", and ultimately receive the corresponding return packet from "Dst" (when neither are lost). Finally, note that the variable "dT" is used in [RFC2681] to refer to the value of Round-trip delay in metric definitions and methods. The variable "dT" has been re-used in other IPPM literature to refer to different quantities, and cannot be used as a global variable name. Morton, A., "Round-trip Packet Loss Metrics", RFC 6673, August 2012. [RFC6673] Both delay and loss metrics employ a maximum waiting time for received packets, so the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 9.2.2. Fixed Parameters Type-P as defined in Section 13 of [RFC2330]: o IPv4 header values: * DSCP: set to 0 * TTL: set to 255 * Protocol: Set to 01 (ICMP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 128 decimal (ICMP) * Flow Label: set to zero * Extension Headers: none o ICMP header values: * Type: 8 (Echo Request) * Code: 0 Morton, et al. Expires September 10, 2020 [Page 56] Internet-Draft Initial Registry March 2020 * Checksum: the checksum MUST be calculated and the non-zero checksum included in the header * (Identifier and Sequence Number set at Run-Time) o ICMP Payload * total of 32 bytes of random info, constant per test. Other measurement parameters: o Tmax: a loss threshold waiting time * 3.0, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms), with lossless conversion to/from the 32-bit NTP timestamp as per section 6 of [RFC5905]. 9.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 9.3.1. Reference Method The methodology for this metric is defined as Type-P-Round-trip- Delay-Poisson-Stream in section 2.6 of RFC 2681 [RFC2681] and section 3.6 of RFC 2681 [RFC2681] using the Type-P and Tmax defined under Fixed Parameters. The reference method distinguishes between long-delayed packets and lost packets by implementing a maximum waiting time for packet arrival. Tmax is the waiting time used as the threshold to declare a packet lost. Lost packets SHALL be designated as having undefined delay, and counted for the RTLoss metric. The calculations on the delay (RTD) SHALL be performed on the conditional distribution, conditioned on successful packet arrival within Tmax. Also, when all packet delays are stored, the process which calculates the RTD value MUST enforce the Tmax threshold on stored values before calculations. See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. Morton, et al. Expires September 10, 2020 [Page 57] Internet-Draft Initial Registry March 2020 The reference method requires some way to distinguish between different packets in a stream to establish correspondence between sending times and receiving times for each successfully-arriving packet. Sequence numbers or other send-order identification MUST be retained at the Src or included with each packet to disambiguate packet reordering if it occurs. The measurement process will determine the sequence numbers applied to test packets after the Fixed and Runtime parameters are passed to that process. The ICMP measurement process and protocol will dictate the format of sequence numbers and other identifiers. Refer to Section 4.4 of [RFC6673] for expanded discussion of the instruction to "send a Type-P packet back to the Src as quickly as possible" in Section 2.6 of RFC 2681 [RFC2681]. Section 8 of [RFC6673] presents additional requirements which MUST be included in the method of measurement for this metric. 9.3.2. Packet Stream Generation This section gives the details of the packet traffic which is the basis for measurement. In IPPM metrics, this is called the Stream, and can easily be described by providing the list of stream parameters. The ICMP metrics use a sending discipline called "SendOnRcv" or Send On Receive. This is a modification of Section 3 of [RFC3432], which prescribes the method for generating Periodic streams using associated parameters as defined below for this description: incT the nominal duration of inter-packet interval, first bit to first bit dT the duration of the interval for allowed sample start times The incT stream parameter will be specified as a Run-time parameter, and dT is not used in SendOnRcv. A SendOnRcv sender behaves exactly like a Periodic stream generator while all reply packets arrive with RTD < incT, and the inter-packet interval will be constant. If a reply packet arrives with RTD >= incT, then the inter-packet interval for the next sending time is nominally RTD. If a reply packet fails to arrive within Tmax, then the inter-packet interval for the next sending time is nominally Tmax. Morton, et al. Expires September 10, 2020 [Page 58] Internet-Draft Initial Registry March 2020 If an immediate send on reply arrival is desired, then set incT=0. 9.3.3. Traffic Filtering (observation) Details NA 9.3.4. Sampling Distribution NA 9.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the Src Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the Dst Role (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) incT the nominal duration of inter-packet interval, first bit to first bit, expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 4 (see section 9.3 of [RFC6020]) and with resolution of 0.0001 seconds (0.1 ms). T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Tf is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Count The total count of ICMP Echo Requests to send, formatted as a uint16, as per section 9.2 of [RFC6020]. (see the Packet Stream Generation section for additional Run-time parameters) 9.3.6. Roles Src launches each packet and waits for return transmissions from Dst. Dst waits for each packet from Src and sends a return packet to Src. Morton, et al. Expires September 10, 2020 [Page 59] Internet-Draft Initial Registry March 2020 9.4. Output This category specifies all details of the Output of measurements using the metric. 9.4.1. Type See subsection titles in Reference Definition for Latency Types. LossRatio -- the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 6.1 of [RFC6673]. 9.4.2. Reference Definition For all output types --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. TotalCount the count of packets actually sent by the Src to Dst during the measurement interval. For LossRatio -- the count of lost packets to total packets sent is the basis for the loss ratio calculation as per Section 4.1 of [RFC7680]. For each , one of the following sub-sections apply: 9.4.2.1. Mean The mean SHALL be calculated using the conditional distribution of all packets with a finite value of Round-trip delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.2.2 of [RFC6049] for details on calculating this statistic, and 4.2.3 of [RFC6049]. Morton, et al. Expires September 10, 2020 [Page 60] Internet-Draft Initial Registry March 2020 Mean The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 9.4.2.2. Min The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of Round-trip delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for details on calculating this statistic, and 4.3.3 of [RFC6049]. Min The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 9.4.2.3. Max The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of Round-trip delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic, and 4.3.3 of [RFC6049]. The formula is as follows: Max = (FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n Max The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 Morton, et al. Expires September 10, 2020 [Page 61] Internet-Draft Initial Registry March 2020 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 9.4.3. Metric Units The of Round-trip Delay is expressed in seconds, where is one of: o Mean o Min o Max The Round-trip Loss Ratio is expressed as a percentage of lost packets to total packets sent. 9.4.4. Calibration Section 3.7.3 of [RFC7679] provides a means to quantify the systematic and random errors of a time measurement. In-situ calibration could be enabled with an internal loopback at the Source host that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized this way. When a measurement controller requests a calibration measurement, the loopback is applied and the result is output in the same format as a normal measurement with additional indication that it is a calibration result. Both internal loopback calibration and clock synchronization can be used to estimate the available accuracy of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the Output result resolution which is the result of system noise, and thus inaccurate. 9.5. Administrative items 9.5.1. Status Current Morton, et al. Expires September 10, 2020 [Page 62] Internet-Draft Initial Registry March 2020 9.5.2. Requester This RFC number 9.5.3. Revision 1.0 9.5.4. Revision Date YYYY-MM-DD 9.6. Comments and Remarks None 10. TCP Round-Trip Delay and Loss Registry Entries This section specifies three initial registry entries for the Passive assessment of TCP Round-Trip Delay (RTD) and another entry for TCP Round-trip Loss Count. IANA Note: Registry "Name" below specifies multiple registry entries, whose output format varies according to the element of the name that specifies one form of statistical summary. There are two additional metric names for Singleton RT Delay and Packet Count metrics. All column entries beside the ID, Name, Description, and Output Reference Method categories are the same, thus this section proposes four closely-related registry entries. As a result, IANA is also asked to assign corresponding URLs to each Named Metric. 10.1. Summary This category includes multiple indexes to the registry entry: the element ID and metric name. 10.1.1. ID (Identifier) IANA is asked to assign different numeric identifiers to each of the four Named Metrics. 10.1.2. Name RTDelay_Passive_IP-TCP_RFCXXXXsec10_Seconds_ where is one of: Morton, et al. Expires September 10, 2020 [Page 63] Internet-Draft Initial Registry March 2020 o Mean o Min o Max RTDelay_Passive_IP-TCP-HS_RFCXXXXsec10_Seconds_Singleton Note that a mid-point observer only has the opportunity to compose a single RTDelay on the TCP Hand Shake. RTLoss_Passive_IP-TCP_RFCXXXXsec10_Packet_Count 10.1.3. URI URL: https://www.iana.org/ ... 10.1.4. Description RTDelay: This metric assesses the round-trip delay of TCP packets constituting a single connection, exchanged between two hosts. We consider the measurement of round-trip delay based on a single Observation Point [RFC7011] somewhere in the network. The Output is the Round-trip delay for all successfully exchanged packets expressed as the of their conditional delay distribution, where is one of: o Mean o Min o Max RTLoss: This metric assesses the estimated loss count for TCP packets constituting a single connection, exchanged between two hosts. We consider the measurement of round-trip delay based on a single Observation Point [RFC7011] somewhere in the network. The Output is the estimated Loss Count for the measurement interval. 10.1.5. Change Controller IETF 10.1.6. Version (of Registry Format) 1.0 Morton, et al. Expires September 10, 2020 [Page 64] Internet-Draft Initial Registry March 2020 10.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. 10.2.1. Reference Definitions Although there is no RFC that describes passive measurement of Round- Trip Delay, the parallel definition for Active measurement is: Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC2681] This metric definition uses the terms singleton and sample as defined in Section 11 of [RFC2330]. (Section 2.4 of [RFC2681] provides the reference definition of the singleton (single value) Round-trip delay metric. Section 3.4 of [RFC2681] provides the reference definition expanded to cover a multi-singleton sample.) With the Observation Point [RFC7011] (OP) typically located between the hosts participating in the TCP connection, the Round-trip Delay metric requires two individual measurements between the OP and each host, such that the Spatial Composition [RFC6049]of the measurements yields a Round-trip Delay singleton (we are extending the composition of one-way subpath delays to subpath round-trip delay). Using the direction of TCP SYN transmission to anchor the nomenclature, host A sends the SYN and host B replies with SYN-ACK during connection establishment. The direction of SYN transfer is considered the Forward direction of transmission, from A through OP to B (Reverse is B through OP to A). Traffic filters reduce the packet stream at the OP to a Qualified bidirectional flow of packets. In the definitions below, Corresponding Packets are transferred in different directions and convey a common value in a TCP header field that establishes correspondence (to the extent possible). Examples may be found in the TCP timestamp fields. For a real number, RTD_fwd, >> the Round-trip Delay in the Forward direction from OP to host B at time T' is RTD_fwd << it is REQUIRED that OP observed a Qualified Packet to host B at wire-time T', that host B received that packet and sent a Corresponding Packet back to Morton, et al. Expires September 10, 2020 [Page 65] Internet-Draft Initial Registry March 2020 host A, and OP observed the Corresponding Packet at wire-time T' + RTD_fwd. For a real number, RTD_rev, >> the Round-trip Delay in the Reverse direction from OP to host A at time T'' is RTD_rev << it is REQUIRED that OP observed a Qualified Packet to host A at wire-time T'', that host A received that packet and sent a Corresponding Packet back to host B, and that OP observed the Corresponding Packet at wire-time T'' + RTD_rev. Ideally, the packet sent from host B to host A in both definitions above SHOULD be the same packet (or, when measuring RTD_rev first, the packet from host A to host B in both definitions should be the same). The REQUIRED Composition Function for a singleton of Round-trip Delay at time T (where T is the earliest of T' and T'' above) is: RTDelay = RTD_fwd + RTD_rev Note that when OP is located at host A or host B, one of the terms composing RTDelay will be zero or negligible. When the Qualified and Corresponding Packets are a TCP-SYN and a TCP- SYN-ACK, then RTD_fwd == RTD_HS_fwd. When the Qualified and Corresponding Packets are a TCP-SYN-ACK and a TCP-ACK, then RTD_rev == RTD_HS_rev. The REQUIRED Composition Function for a singleton of Round-trip Delay for the connection Hand Shake: RTDelay_HS = RTD_HS_fwd + RTD_HS_rev The definition of Round-trip Loss Count uses the nomenclature developed above, based on observation of the TCP header sequence numbers and storing the sequence number gaps observed. Packet Losses can be inferred from: o Out-of-order segments: TCP segments are transmitted with monotonically increasing sequence numbers, but these segments may be received out of order. Section 3 of [RFC4737] describes the notion of "next expected" sequence numbers which can be adapted to TCP segments (for the purpose of detecting reordered packets). Observation of out-of-order segments indicates loss on the path prior to the OP, and creates a gap. Morton, et al. Expires September 10, 2020 [Page 66] Internet-Draft Initial Registry March 2020 o Duplicate segments: Section 2 of [RFC5560] defines identical packets and is suitable for evaluation of TCP packets to detect duplication. Observation of duplicate segments *without a corresponding gap* indicates loss on the path following the OP (because they overlap part of the delivered sequence numbers already observed at OP). Each observation of an out-of-order or duplicate infers a singleton of loss, but composition of Round-trip Loss Counts will be conducted over a measurement interval which is synonymous with a single TCP connection. With the above observations in the Forward direction over a measurement interval, the count of out-of-order and duplicate segments is defined as RTL_fwd. Comparable observations in the Reverse direction are defined as RTL_rev. For a measurement interval (corresponding to a single TCP connection), T0 to Tf, the REQUIRED Composition Function for a the two single-direction counts of inferred loss is: RTLoss = RTL_fwd + RTL_rev 10.2.2. Fixed Parameters Traffic Filters: o IPv4 header values: * DSCP: set to 0 * Protocol: Set to 06 (TCP) o IPv6 header values: * DSCP: set to 0 * Hop Count: set to 255 * Next Header: set to 6 (TCP) * Flow Label: set to zero * Extension Headers: none o TCP header values: * Flags: ACK, SYN, FIN, set as required Morton, et al. Expires September 10, 2020 [Page 67] Internet-Draft Initial Registry March 2020 * Timestamp Option (TSopt): Set + Section 3.2 of [RFC7323] 10.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 10.3.1. Reference Methods The foundation methodology for this metric is defined in Section 4 of [RFC7323] using the Timestamp Option with modifications that allow application at a mid-path Observation Point (OP) [RFC7011]. Further details and applicable heuristics were derived from [Strowes] and [Trammell-14]. The Traffic Filter at the OP is configured to observe a single TCP connection. When the SYN, SYN-ACK, ACK handshake occurs, it offers the first opportunity to measure both RTD_fwd (on the SYN to SYN-ACK pair) and RTD_rev (on the SYN-ACK to ACK pair). Label this singleton of RTDelay as RTDelay_HS (composed using the forward and reverse measurement pair). RTDelay_HS SHALL be treated separately from other RTDelays on data-bearing packets and their ACKs. The RTDelay_HS value MAY be used as a sanity check on other Composed values of RTDelay. For payload bearing packets, the OP measures the time interval between observation of a packet with Sequence Number s, and the corresponding ACK with same Sequence number. When the payload is transferred from host A to host B, the observed interval is RTD_fwd. Because many data transfers are unidirectional (say, in the Forward direction from host A to host B), it is necessary to use pure ACK packets with Timestamp (TSval) and their Timestamp value echo to perform a RTD_rev measurement. The time interval between observation of the ACK from B to A, and the corresponding packet with Timestamp echo (TSecr) is the RTD_rev. Delay Measurement Filtering Heuristics: If Data payloads were transferred in both Forward and Reverse directions, then the Round-Trip Time Measurement Rule in Section 4.1 of [RFC7323] could be applied. This rule essentially excludes any measurement using a packet unless it makes progress in the transfer (advances the left edge of the send window, consistent with [Strowes]). Morton, et al. Expires September 10, 2020 [Page 68] Internet-Draft Initial Registry March 2020 A different heuristic from [Trammell-14] is to exclude any RTD_rev that is larger than previously observed values. This would tend to exclude Reverse measurements taken when the Application has no data ready to send, because considerable time could be added to RTD_rev from this source of error. Note that the above Heuristic assumes that host A is sending data. Host A expecting a download would mean that this heuristic should be applied to RTD_fwd. The statistic calculations to summarize the delay (RTDelay) SHALL be performed on the conditional distribution, conditioned on successful Forward and Reverse measurements which follow the Heuristics. Method for Inferring Loss: The OP tracks sequence numbers and stores gaps for each direction of transmission, as well as the next-expected sequence number as in [Trammell-14] and [RFC4737]. Loss is inferred from Out-of-order segments and Duplicate segments. Loss Measurement Filtering Heuristics: [Trammell-14] adds a window of evaluation based on the RTDelay. Distinguish Re-ordered from OOO due to loss, because sequence number gap is filled during the same RTDelay window. Segments detected as re-ordered according to [RFC4737] MUST reduce the Loss Count inferred from Out-of-order segments. Spurious (unneeded) retransmissions (observed as duplicates) can also be reduced this way, as described in [Trammell-14]. Sources of Error: The principal source of RTDelay error is the host processing time to return a packet that defines the termination of a time interval. The heuristics above intend to mitigate these errors by excluding measurements where host processing time is a significant part of RTD_fwd or RTD_rev. A key source of RTLoss error is observation loss, described in section 3 of [Trammell-14]. Morton, et al. Expires September 10, 2020 [Page 69] Internet-Draft Initial Registry March 2020 10.3.2. Packet Stream Generation NA 10.3.3. Traffic Filtering (observation) Details The Fixed Parameters above give a portion of the Traffic Filter. Other aspects will be supplied as Run-time Parameters (below). 10.3.4. Sampling Distribution This metric requires a complete sample of all packets that qualify according to the Traffic Filter criteria. 10.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. Src the IP address of the host in the host A Role (format ipv4- address-no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see Section 4 of [RFC6991]) Dst the IP address of the host in the host B (format ipv4-address- no-zone value for IPv4, or ipv6-address-no-zone value for IPv6, see section 4 of [RFC6991]) T0 a time, the start of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. When T0 is "all-zeros", a start time is unspecified and Td is to be interpreted as the Duration of the measurement interval. The start time is controlled through other means. Td Optionally, the end of a measurement interval, (format "date-and- time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]), or the duration (see T0). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Alternatively, the end of the measurement interval MAY be controlled by the measured connection, where the second pair of FIN and ACK packets exchanged between host A and B effectively ends the interval. TTL or Hop Limit Set at desired value. Morton, et al. Expires September 10, 2020 [Page 70] Internet-Draft Initial Registry March 2020 10.3.6. Roles host A launches the SYN packet to open the connection, and synonymous with an IP address. host B replies with the SYN-ACK packet to open the connection, and synonymous with an IP address. 10.4. Output This category specifies all details of the Output of measurements using the metric. 10.4.1. Type See subsection titles in Reference Definition for RTDelay Types. For RTLoss -- the count of lost packets. 10.4.2. Reference Definition For all output types --- T0 the start of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. Tf the end of a measurement interval, (format "date-and-time" as specified in Section 5.6 of [RFC3339], see also Section 3 of [RFC6991]). The UTC Time Zone is required by Section 6.1 of [RFC2330]. The end of the measurement interval MAY be controlled by the measured connection, where the second pair of FIN and ACK packets exchanged between host A and B effectively ends the interval. ... ... For RTDelay_HS -- the Round trip delay of the Handshake. For RTLoss -- the count of lost packets. For each , one of the following sub-sections apply: Morton, et al. Expires September 10, 2020 [Page 71] Internet-Draft Initial Registry March 2020 10.4.2.1. Mean The mean SHALL be calculated using the conditional distribution of all packets with a finite value of Round-trip delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.2.2 of [RFC6049] for details on calculating this statistic, and 4.2.3 of [RFC6049]. Mean The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 10.4.2.2. Min The minimum SHALL be calculated using the conditional distribution of all packets with a finite value of Round-trip delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. See section 4.3.2 of [RFC6049] for details on calculating this statistic, and 4.3.3 of [RFC6049]. Min The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 10.4.2.3. Max The maximum SHALL be calculated using the conditional distribution of all packets with a finite value of Round-trip delay (undefined delays are excluded), a single value as follows: See section 4.1 of [RFC3393] for details on the conditional distribution to exclude undefined values of delay, and Section 5 of [RFC6703] for background on this analysis choice. Morton, et al. Expires September 10, 2020 [Page 72] Internet-Draft Initial Registry March 2020 See section 4.3.2 of [RFC6049] for a closely related method for calculating this statistic, and 4.3.3 of [RFC6049]. The formula is as follows: Max = (FiniteDelay [j]) such that for some index, j, where 1 <= j <= N FiniteDelay[j] >= FiniteDelay[n] for all n Max The time value of the result is expressed in units of seconds, as a positive value of type decimal64 with fraction digits = 9 (see section 9.3 of [RFC6020]) with resolution of 0.000000001 seconds (1.0 ns), and with lossless conversion to/from the 64-bit NTP timestamp as per section 6 of RFC [RFC5905] 10.4.3. Metric Units The of Round-trip Delay is expressed in seconds, where is one of: o Mean o Min o Max The Round-trip Delay of the Hand Shake is expressed in seconds. The Round-trip Loss Count is expressed as a number of packets. 10.4.4. Calibration Passive measurements at an OP could be calibrated against an active measurement (with loss emulation) at host A or B, where the active measurement represents the ground-truth. 10.5. Administrative items 10.5.1. Status Current 10.5.2. Requester This RFC number Morton, et al. Expires September 10, 2020 [Page 73] Internet-Draft Initial Registry March 2020 10.5.3. Revision 1.0 10.5.4. Revision Date YYYY-MM-DD 10.6. Comments and Remarks None. 11. Security Considerations These registry entries represent no known implications for Internet Security. Each RFC referenced above contains a Security Considerations section. Further, the LMAP Framework [RFC7594] provides both security and privacy considerations for measurements. There are potential privacy considerations for observed traffic, particularly for passive metrics in section 10. An attacker that knows that its TCP connection is being measured can modify its behavior to skew the measurement results. 12. IANA Considerations IANA is requested to populate The Performance Metrics Registry defined in [I-D.ietf-ippm-metric-registry] with the values defined in sections 4 through 10. See the IANA Considerations section of [I-D.ietf-ippm-metric-registry] for additional requests and considerations. 13. Acknowledgements The authors thank Brian Trammell for suggesting the term "Run-time Parameters", which led to the distinction between run-time and fixed parameters implemented in this memo, for identifying the IPFIX metric with Flow Key as an example, for suggesting the Passive TCP RTD metric and supporting references, and for many other productive suggestions. Thanks to Peter Koch, who provided several useful suggestions for disambiguating successive DNS Queries in the DNS Response time metric. The authors also acknowledge the constructive reviews and helpful suggestions from Barbara Stark, Juergen Schoenwaelder, Tim Carey, Yaakov Stein, and participants in the LMAP working group. Thanks to Morton, et al. Expires September 10, 2020 [Page 74] Internet-Draft Initial Registry March 2020 Michelle Cotton for her early IANA reviews, and to Amanda Barber for answering questions related to the presentation of the registry and accessibility of the complete template via URL. 14. References 14.1. Normative References [I-D.ietf-ippm-metric-registry] Bagnulo, M., Claise, B., Eardley, P., and A. Morton, "Registry for Performance Metrics", Internet Draft (work in progress) draft-ietf-ippm-metric-registry, 2019. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, . [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, . Morton, et al. Expires September 10, 2020 [Page 75] Internet-Draft Initial Registry March 2020 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, . [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, DOI 10.17487/RFC5560, May 2009, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, . [RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . Morton, et al. Expires September 10, 2020 [Page 76] Internet-Draft Initial Registry March 2020 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, . [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [Strowes] Strowes, S., "Passively Measuring TCP Round Trip Times, Communications of the ACM, Vol. 56 No. 10, Pages 57-64", September 2013. [Trammell-14] Trammell, B., "Inline Data Integrity Signals for Passive Measurement, In: Dainotti A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in Computer Science, vol 8406. Springer, Berlin, Heidelberg https://link.springer.com/ chapter/10.1007/978-3-642-54999-1_2", March 2014. 14.2. Informative References [RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, . [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, . [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting IP Network Performance Metrics: Different Points of View", RFC 6703, DOI 10.17487/RFC6703, August 2012, . Morton, et al. Expires September 10, 2020 [Page 77] Internet-Draft Initial Registry March 2020 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, . Authors' Addresses Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Philip Eardley BT Adastral Park, Martlesham Heath Ipswich ENGLAND Email: philip.eardley@bt.com Kevin D'Souza AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 xxxx Email: kld@att.com Morton, et al. Expires September 10, 2020 [Page 78] ./draft-ietf-ippm-metric-registry-24.txt0000644000764400076440000025007313631526003017460 0ustar iustyiusty Network Working Group M. Bagnulo Internet-Draft UC3M Intended status: Standards Track B. Claise Expires: September 10, 2020 Cisco Systems, Inc. P. Eardley BT A. Morton AT&T Labs A. Akhter Consultant March 9, 2020 Registry for Performance Metrics draft-ietf-ippm-metric-registry-24 Abstract This document defines the format for the IANA Performance Metrics Registry. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2020. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Bagnulo, et al. Expires September 10, 2020 [Page 1] Internet-Draft Registry for Performance Metrics March 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Motivation for a Performance Metrics Registry . . . . . . . . 8 4.1. Interoperability . . . . . . . . . . . . . . . . . . . . 8 4.2. Single point of reference for Performance Metrics . . . . 9 4.3. Side benefits . . . . . . . . . . . . . . . . . . . . . . 9 5. Criteria for Performance Metrics Registration . . . . . . . . 9 6. Performance Metric Registry: Prior attempt . . . . . . . . . 10 6.1. Why this Attempt Should Succeed . . . . . . . . . . . . . 11 7. Definition of the Performance Metric Registry . . . . . . . . 11 7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 13 7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 13 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 7.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 17 7.1.6. Change Controller . . . . . . . . . . . . . . . . . . 17 7.1.7. Version (of Registry Format) . . . . . . . . . . . . 18 7.2. Metric Definition Category . . . . . . . . . . . . . . . 18 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 18 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 7.3. Method of Measurement Category . . . . . . . . . . . . . 19 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 20 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 21 7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 22 7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 22 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 23 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 23 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23 7.5. Administrative information . . . . . . . . . . . . . . . 24 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 24 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 24 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 24 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 24 Bagnulo, et al. Expires September 10, 2020 [Page 2] Internet-Draft Registry for Performance Metrics March 2020 8. Processes for Managing the Performance Metric Registry Group 24 8.1. Adding new Performance Metrics to the Performance Metrics Registry . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Revising Registered Performance Metrics . . . . . . . . . 26 8.3. Deprecating Registered Performance Metrics . . . . . . . 28 9. Security considerations . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.1. Registry Group . . . . . . . . . . . . . . . . . . . . . 29 10.2. Performance Metric Name Elements . . . . . . . . . . . . 29 10.3. New Performance Metrics Registry . . . . . . . . . . . . 30 11. Blank Registry Template . . . . . . . . . . . . . . . . . . . 32 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 32 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 32 11.1.4. Description . . . . . . . . . . . . . . . . . . . . 32 11.1.5. Change Controller . . . . . . . . . . . . . . . . . 32 11.1.6. Version (of Registry Format) . . . . . . . . . . . . 32 11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 32 11.2.1. Reference Definition . . . . . . . . . . . . . . . . 32 11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 32 11.3. Method of Measurement . . . . . . . . . . . . . . . . . 33 11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 33 11.3.2. Packet Stream Generation . . . . . . . . . . . . . . 33 11.3.3. Traffic Filtering (observation) Details . . . . . . 33 11.3.4. Sampling Distribution . . . . . . . . . . . . . . . 33 11.3.5. Run-time Parameters and Data Format . . . . . . . . 33 11.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 33 11.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 34 11.4.2. Reference Definition . . . . . . . . . . . . . . . . 34 11.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 34 11.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 34 11.5. Administrative items . . . . . . . . . . . . . . . . . . 34 11.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 34 11.5.2. Requester . . . . . . . . . . . . . . . . . . . . . 34 11.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 34 11.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 34 11.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 34 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 35 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Bagnulo, et al. Expires September 10, 2020 [Page 3] Internet-Draft Registry for Performance Metrics March 2020 1. Introduction The IETF specifies and uses Performance Metrics of protocols and applications transported over its protocols. Performance metrics are important part of network operations using IETF protocols, and [RFC6390] specifies guidelines for their development. The definition and use of Performance Metrics in the IETF has been fostered in various working groups (WG), most notably: The "IP Performance Metrics" (IPPM) WG is the WG primarily focusing on Performance Metrics definition at the IETF. The "Benchmarking Methodology" WG (BMWG) defines many Performance Metrics for use in laboratory benchmarking of inter-networking technologies. The "Metric Blocks for use with RTCP's Extended Report Framework" (XRBLOCK) WG (concluded) specified many Performance Metrics related to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], which establishes a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in "RTP: A Transport Protocol for Real-Time Applications", [RFC3550]. The "IP Flow Information eXport" (IPFIX) concluded WG specified an IANA process for new Information Elements. Some Performance Metrics related Information Elements are proposed on regular basis. The "Performance Metrics for Other Layers" (PMOL) a concluded WG defined some Performance Metrics related to Session Initiation Protocol (SIP) voice quality [RFC6035]. It is expected that more Performance Metrics will be defined in the future, not only IP-based metrics, but also metrics which are protocol-specific and application-specific. Despite the importance of Performance Metrics, there are two related problems for the industry. First, ensuring that when one party requests another party to measure (or report or in some way act on) a particular Performance Metric, then both parties have exactly the same understanding of what Performance Metric is being referred to. Second, discovering which Performance Metrics have been specified, to avoid developing a new Performance Metric that is very similar, but not quite inter-operable. These problems can be addressed by creating a registry of performance metrics. The usual way in which the IETF organizes registries is with Internet Assigned Numbers Bagnulo, et al. Expires September 10, 2020 [Page 4] Internet-Draft Registry for Performance Metrics March 2020 Authority (IANA), and there is currently no Performance Metrics Registry maintained by the IANA. This document requests that IANA create and maintain a Performance Metrics Registry, according to the maintenance procedures and the Performance Metrics Registry format defined in this memo. The resulting Performance Metrics Registry is for use by the IETF and others. Although the Registry formatting specifications herein are primarily for registry creation by IANA, any other organization that wishes to create a performance metrics registry may use the same formatting specifications for their purposes. The authors make no guarantee of the registry format's applicability to any possible set of Performance Metrics envisaged by other organizations, but encourage others to apply it. In the remainder of this document, unless we explicitly say otherwise, we will refer to the IANA- maintained Performance Metrics Registry as simply the Performance Metrics Registry. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Performance Metric: A Performance Metric is a quantitative measure of performance, targeted to an IETF-specified protocol or targeted to an application transported over an IETF-specified protocol. Examples of Performance Metrics are the FTP response time for a complete file download, the DNS response time to resolve the IP address(es), a database logging time, etc. This definition is consistent with the definition of metric in [RFC2330] and broader than the definition of performance metric in [RFC6390]. Registered Performance Metric: A Registered Performance Metric is a Performance Metric expressed as an entry in the Performance Metrics Registry, administered by IANA. Such a performance metric has met all the registry review criteria defined in this document in order to be included in the registry. Performance Metrics Registry: The IANA registry containing Registered Performance Metrics. Proprietary Registry: A set of metrics that are registered in a proprietary registry, as opposed to Performance Metrics Registry. Bagnulo, et al. Expires September 10, 2020 [Page 5] Internet-Draft Registry for Performance Metrics March 2020 Performance Metrics Experts: The Performance Metrics Experts is a group of designated experts [RFC8126] selected by the IESG to validate the Performance Metrics before updating the Performance Metrics Registry. The Performance Metrics Experts work closely with IANA. Parameter: A Parameter is an input factor defined as a variable in the definition of a Performance Metric. A Parameter is a numerical or other specified factor forming one of a set that defines a metric or sets the conditions of its operation. All Parameters must be known in order to make a measurement using a metric and interpret the results. There are two types of Parameters: Fixed and Run-time parameters. For the Fixed Parameters, the value of the variable is specified in the Performance Metrics Registry entry and different Fixed Parameter values results in different Registered Performance Metrics. For the Run-time Parameters, the value of the variable is defined when the metric measurement method is executed and a given Registered Performance Metric supports multiple values for the parameter. Although Run-time Parameters do not change the fundamental nature of the Performance Metric's definition, some have substantial influence on the network property being assessed and interpretation of the results. Note: Consider the case of packet loss in the following two Active Measurement Method cases. The first case is packet loss as background loss where the Run-time Parameter set includes a very sparse Poisson stream, and only characterizes the times when packets were lost. Actual user streams likely see much higher loss at these times, due to tail drop or radio errors. The second case is packet loss as inverse of throughput where the Run-time Parameter set includes a very dense, bursty stream, and characterizes the loss experienced by a stream that approximates a user stream. These are both "loss metrics", but the difference in interpretation of the results is highly dependent on the Run-time Parameters (at least), to the extreme where we are actually using loss to infer its compliment: delivered throughput. Active Measurement Method: Methods of Measurement conducted on traffic which serves only the purpose of measurement and is generated for that reason alone, and whose traffic characteristics are known a priori. The complete definition of Active Methods is specified in section 3.4 of[RFC7799]. Examples of Active Measurement Methods are the measurement methods for the One way delay metric defined in [RFC7679] and the one for round trip delay defined in [RFC2681]. Bagnulo, et al. Expires September 10, 2020 [Page 6] Internet-Draft Registry for Performance Metrics March 2020 Passive Measurement Method: Methods of Measurement conducted on network traffic, generated either from the end users or from network elements that would exist regardless whether the measurement was being conducted or not. The complete definition of Passive Methods is specified in section 3.6 of [RFC7799]. One characteristic of Passive Measurement Methods is that sensitive information may be observed, and as a consequence, stored in the measurement system. Hybrid Measurement Method: Hybrid Methods are Methods of Measurement that use a combination of Active Methods and Passive Methods, to assess Active Metrics, Passive Metrics, or new metrics derived from the a priori knowledge and observations of the stream of interest. The complete definition of Hybrid Methods is specified in section 3.8 of [RFC7799]. 3. Scope This document is intended for two different audiences: 1. For those defining new Registered Performance Metrics, it provides specifications and best practices to be used in deciding which Registered Performance Metrics are useful for a measurement study, instructions for writing the text for each column of the Registered Performance Metrics, and information on the supporting documentation required for the new Performance Metrics Registry entry (up to and including the publication of one or more immutable documents such as an RFC). 2. For the appointed Performance Metrics Experts and for IANA personnel administering the new IANA Performance Metrics Registry, it defines a set of acceptance criteria against which these proposed Registered Performance Metrics should be evaluated. In addition, this document may be useful for other organizations who are defining a Performance Metric registry of their own, and may re- use the features of the Performance Metrics Registry defined in this document. This Performance Metrics Registry is applicable to Performance Metrics issued from Active Measurement, Passive Measurement, and any other form of Performance Metric. This registry is designed to encompass Performance Metrics developed throughout the IETF and especially for the technologies specified in the following working groups: IPPM, XRBLOCK, IPFIX, and BMWG. This document analyzes a prior attempt to set up a Performance Metrics Registry, and the reasons why this design was inadequate [RFC6248]. Finally, this Bagnulo, et al. Expires September 10, 2020 [Page 7] Internet-Draft Registry for Performance Metrics March 2020 document gives a set of guidelines for requesters and expert reviewers of candidate Registered Performance Metrics. This document makes no attempt to populate the Performance Metrics Registry with initial entries; the related memo [I-D.ietf-ippm-initial-registry] proposes the initial set of regsitry entries. 4. Motivation for a Performance Metrics Registry In this section, we detail several motivations for the Performance Metrics Registry. 4.1. Interoperability As with any IETF registry, the primary intention is to manage registration of identifiers for use within one or more protocols. In the particular case of the Performance Metrics Registry, there are two types of protocols that will use the Performance Metrics in the Performance Metrics Registry during their operation (by referring to the Index values): o Control protocol: This type of protocol used to allow one entity to request another entity to perform a measurement using a specific metric defined by the Performance Metrics Registry. One particular example is the LMAP framework [RFC7594]. Using the LMAP terminology, the Performance Metrics Registry is used in the LMAP Control protocol to allow a Controller to schedule a measurement task for one or more Measurement Agents. In order to enable this use case, the entries of the Performance Metrics Registry must be sufficiently defined to allow a Measurement Agent implementation to trigger a specific measurement task upon the reception of a control protocol message. This requirement heavily constrains the type of entries that are acceptable for the Performance Metrics Registry. o Report protocol: This type of protocol is used to allow an entity to report measurement results to another entity. By referencing to a specific Performance Metrics Registry, it is possible to properly characterize the measurement result data being reported. Using the LMAP terminology, the Performance Metrics Registry is used in the Report protocol to allow a Measurement Agent to report measurement results to a Collector. It should be noted that the LMAP framework explicitly allows for using not only the IANA-maintained Performance Metrics Registry but also other registries containing Performance Metrics, either defined by other organizations or private ones. However, others who are Bagnulo, et al. Expires September 10, 2020 [Page 8] Internet-Draft Registry for Performance Metrics March 2020 creating Registries to be used in the context of an LMAP framework are encouraged to use the Registry format defined in this document, because this makes it easier for developers of LMAP Measurement Agents (MAs) to programmatically use information found in those other Registries' entries. 4.2. Single point of reference for Performance Metrics A Performance Metrics Registry serves as a single point of reference for Performance Metrics defined in different working groups in the IETF. As we mentioned earlier, there are several WGs that define Performance Metrics in the IETF and it is hard to keep track of all them. This results in multiple definitions of similar Performance Metrics that attempt to measure the same phenomena but in slightly different (and incompatible) ways. Having a registry would allow the IETF community and others to have a single list of relevant Performance Metrics defined by the IETF (and others, where appropriate). The single list is also an essential aspect of communication about Performance Metrics, where different entities that request measurements, execute measurements, and report the results can benefit from a common understanding of the referenced Performance Metric. 4.3. Side benefits There are a couple of side benefits of having such a registry. First, the Performance Metrics Registry could serve as an inventory of useful and used Performance Metrics, that are normally supported by different implementations of measurement agents. Second, the results of measurements using the Performance Metrics should be comparable even if they are performed by different implementations and in different networks, as the Performance Metric is properly defined. BCP 176 [RFC6576] examines whether the results produced by independent implementations are equivalent in the context of evaluating the completeness and clarity of metric specifications. This BCP defines the standards track advancement testing for (active) IPPM metrics, and the same process will likely suffice to determine whether Registered Performance Metrics are sufficiently well specified to result in comparable (or equivalent) results. Registered Performance Metrics which have undergone such testing SHOULD be noted, with a reference to the test results. 5. Criteria for Performance Metrics Registration It is neither possible nor desirable to populate the Performance Metrics Registry with all combinations of Parameters of all Performance Metrics. The Registered Performance Metrics SHOULD be: Bagnulo, et al. Expires September 10, 2020 [Page 9] Internet-Draft Registry for Performance Metrics March 2020 1. interpretable by the user. 2. implementable by the software or hardware designer, 3. deployable by network operators, 4. accurate in terms of producing equivalent results, and for interoperability and deployment across vendors, 5. Operationally useful, so that it has significant industry interest and/or has seen deployment, 6. Sufficiently tightly defined, so that different values for the Run-time Parameters does not change the fundamental nature of the measurement, nor change the practicality of its implementation. In essence, there needs to be evidence that a candidate Registered Performance Metric has significant industry interest, or has seen deployment, and there is agreement that the candidate Registered Performance Metric serves its intended purpose. 6. Performance Metric Registry: Prior attempt There was a previous attempt to define a metric registry RFC 4148 [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because it was "found to be insufficiently detailed to uniquely identify IPPM metrics... [there was too much] variability possible when characterizing a metric exactly" which led to the RFC4148 registry having "very few users, if any". A couple of interesting additional quotes from RFC 6248 [RFC6248] might help to understand the issues related to that registry. 1. "It is not believed to be feasible or even useful to register every possible combination of Type P, metric parameters, and Stream parameters using the current structure of the IPPM Metrics Registry." 2. "The registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics." 3. "Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010." The current approach learns from this by tightly defining each Registered Performance Metric with only a few variable (Run-time) Parameters to be specified by the measurement designer, if any. The Bagnulo, et al. Expires September 10, 2020 [Page 10] Internet-Draft Registry for Performance Metrics March 2020 idea is that entries in the Performance Metrics Registry stem from different measurement methods which require input (Run-time) parameters to set factors like source and destination addresses (which do not change the fundamental nature of the measurement). The downside of this approach is that it could result in a large number of entries in the Performance Metrics Registry. There is agreement that less is more in this context - it is better to have a reduced set of useful metrics rather than a large set of metrics, some with with questionable usefulness. 6.1. Why this Attempt Should Succeed As mentioned in the previous section, one of the main issues with the previous registry was that the metrics contained in the registry were too generic to be useful. This document specifies stricter criteria for performance metric registration (see section 5), and imposes a group of Performance Metrics Experts that will provide guidelines to assess if a Performance Metric is properly specified. Another key difference between this attempt and the previous one is that in this case there is at least one clear user for the Performance Metrics Registry: the LMAP framework and protocol. Because the LMAP protocol will use the Performance Metrics Registry values in its operation, this actually helps to determine if a metric is properly defined. In particular, since we expect that the LMAP control protocol will enable a controller to request a measurement agent to perform a measurement using a given metric by embedding the Performance Metrics Registry identifier in the protocol. Such a metric and method are properly specified if they are defined well- enough so that it is possible (and practical) to implement them in the measurement agent. This was the failure of the previous attempt: a registry entry with an undefined Type-P (section 13 of RFC 2330 [RFC2330]) allows implementation to be ambiguous. 7. Definition of the Performance Metric Registry This Performance Metrics Registry is applicable to Performance Metrics used for Active Measurement, Passive Measurement, and any other form of Performance Measurement. Each category of measurement has unique properties, so some of the columns defined below are not applicable for a given metric category. In this case, the column(s) SHOULD be populated with the "NA" value (Non Applicable). However, the "NA" value MUST NOT be used by any metric in the following columns: Identifier, Name, URI, Status, Requester, Revision, Revision Date, Description. In the future, a new category of metrics could require additional columns, and adding new columns is a recognized form of registry extension. The specification defining the new Bagnulo, et al. Expires September 10, 2020 [Page 11] Internet-Draft Registry for Performance Metrics March 2020 column(s) MUST give general guidelines for populating the new column(s) for existing entries. The columns of the Performance Metrics Registry are defined below. The columns are grouped into "Categories" to facilitate the use of the registry. Categories are described at the 7.x heading level, and columns are at the 7.x.y heading level. The Figure below illustrates this organization. An entry (row) therefore gives a complete description of a Registered Performance Metric. Each column serves as a check-list item and helps to avoid omissions during registration and expert review. ======================================================================= Legend: Registry Categories and Columns are shown below as: Category ------------------... Column | Column |... ======================================================================= Summary ------------------------------------------------------------------------ Identifier | Name | URI | Desc. | Reference | Change Controller | Ver | Metric Definition ----------------------------------------- Reference Definition | Fixed Parameters | Method of Measurement --------------------------------------------------------------------- Reference | Packet | Traffic | Sampling | Run-time | Role | Method | Stream | Filter | Distribution | Parameters | | | Generation | Output ----------------------------------------- Type | Reference | Units | Calibration | | Definition | | | Administrative Information ------------------------------------ Status |Requester | Rev | Rev.Date | Comments and Remarks -------------------- There is a blank template of the Registry template provided in Section 11 of this memo. Bagnulo, et al. Expires September 10, 2020 [Page 12] Internet-Draft Registry for Performance Metrics March 2020 7.1. Summary Category 7.1.1. Identifier A numeric identifier for the Registered Performance Metric. This identifier MUST be unique within the Performance Metrics Registry. The Registered Performance Metric unique identifier is an unbounded integer (range 0 to infinity). The Identifier 0 should be Reserved. The Identifier values from 64512 to 65536 are reserved for private or experimental use, and the user may encounter overlapping uses. When adding newly Registered Performance Metrics to the Performance Metrics Registry, IANA SHOULD assign the lowest available identifier to the new Registered Performance Metric. If a Performance Metrics Expert providing review determines that there is a reason to assign a specific numeric identifier, possibly leaving a temporary gap in the numbering, then the Performance Expert SHALL inform IANA of this decision. 7.1.2. Name As the name of a Registered Performance Metric is the first thing a potential human implementor will use when determining whether it is suitable for their measurement study, it is important to be as precise and descriptive as possible. In future, users will review the names to determine if the metric they want to measure has already been registered, or if a similar entry is available as a basis for creating a new entry. Names are composed of the following elements, separated by an underscore character "_": MetricType_Method_SubTypeMethod_... Spec_Units_Output o MetricType: a combination of the directional properties and the metric measured, such as and not limited to: RTDelay (Round Trip Delay) RTDNS (Response Time Domain Name Service) RLDNS (Response Loss Domain Name Service) OWDelay (One Way Delay) Bagnulo, et al. Expires September 10, 2020 [Page 13] Internet-Draft Registry for Performance Metrics March 2020 RTLoss (Round Trip Loss) OWLoss (One Way Loss) OWPDV (One Way Packet Delay Variation) OWIPDV (One Way Inter-Packet Delay Variation) OWReorder (One Way Packet Reordering) OWDuplic (One Way Packet Duplication) OWBTC (One Way Bulk Transport Capacity) OWMBM (One Way Model Based Metric) SPMonitor (Single Point Monitor) MPMonitor (Multi-Point Monitor) o Method: One of the methods defined in [RFC7799], such as and not limited to: Active (depends on a dedicated measurement packet stream and observations of the stream) Passive (depends *solely* on observation of one or more existing packet streams) HybridType1 (observations on one stream that combine both active and passive methods) HybridType2 (observations on two or more streams that combine both active and passive methods) Spatial (Spatial Metric of RFC5644) o SubTypeMethod: One or more sub-types to further describe the features of the entry, such as and not limited to: ICMP (Internet Control Message Protocol) IP (Internet Protocol) DSCPxx (where xx is replaced by a Diffserv code point) UDP (User Datagram Protocol) Bagnulo, et al. Expires September 10, 2020 [Page 14] Internet-Draft Registry for Performance Metrics March 2020 TCP (Transport Control Protocol) QUIC (QUIC transport protocol) HS (Hand-Shake, such as TCP's 3-way HS) Poisson (Packet generation using Poisson distribution) Periodic (Periodic packet generation) SendOnRcv (Sender keeps one packet in-transit by sending when previous packet arrives) PayloadxxxxB (where xxxx is replaced by an integer, the number of octets in the Payload)) SustainedBurst (Capacity test, worst case) StandingQueue (test of bottleneck queue behavior) SubTypeMethod values are separated by a hyphen "-" character, which indicates that they belong to this element, and that their order is unimportant when considering name uniqueness. o Spec: An immutable document identifier combined with a document section identifier. For RFCs, this consists of the RFC number and major section number that specifies this Registry entry in the form RFCXXXXsecY, such as RFC7799sec3. Note: the RFC number is not the Primary Reference specification for the metric definition, such as [RFC7679] for One-way Delay; it will contain the placeholder "RFCXXXXsecY" until the RFC number is assigned to the specifying document, and would remain blank in private registry entries without a corresponding RFC. Anticipating the "RFC10K" problem, the number of the RFC continues to replace RFCXXXX regardless of the number of digits in the RFC number. Anticipating Registry Entries from other standards bodies, the form of this Name Element MUST be proposed and reviewed for consistency and uniqueness by the Expert Reviewer. o Units: The units of measurement for the output, such as and not limited to: Seconds Ratio (unitless) Bagnulo, et al. Expires September 10, 2020 [Page 15] Internet-Draft Registry for Performance Metrics March 2020 Percent (value multiplied by 100%) Logical (1 or 0) Packets BPS (Bits per Second) PPS (Packets per Second) EventTotal (for unit-less counts) Multiple (more than one type of unit) Enumerated (a list of outcomes) Unitless o Output: The type of output resulting from measurement, such as and not limited to: Singleton Raw (multiple Singletons) Count Minimum Maximum Median Mean 95Percentile (95th Percentile) 99Percentile (99th Percentile) StdDev (Standard Deviation) Variance PFI (Pass, Fail, Inconclusive) FlowRecords (descriptions of flows observed) LossRatio (lost packets to total packets, <=1) Bagnulo, et al. Expires September 10, 2020 [Page 16] Internet-Draft Registry for Performance Metrics March 2020 An example is: RTDelay_Active_IP-UDP-Periodic_RFCXXXXsecY_Seconds_95Percentile as described in section 4 of [I-D.ietf-ippm-initial-registry]. Note that private registries following the format described here SHOULD use the prefix "Priv_" on any name to avoid unintended conflicts (further considerations are described in section 10). Private registry entries usually have no specifying RFC, thus the Spec: element has no clear interpretation. 7.1.3. URI The URIs column MUST contain a URL [RFC3986] that uniquely identifies and locates the metric entry so it is accessible through the Internet. The URL points to a file containing all the human-readable information for one registry entry. The URL SHALL reference a target file that is preferably HTML-formatted and contains URLs to referenced sections of HTML-ized RFCs, or other reference specifications. These target files for different entries can be more easily edited and re-used when preparing new entries. The exact form of the URL for each target file, and the target file itself, will be determined by IANA and reside on "iana.org". The major sections of [I-D.ietf-ippm-initial-registry] provide an example of a target file in HTML form (sections 4 and higher). 7.1.4. Description A Registered Performance Metric description is a written representation of a particular Performance Metrics Registry entry. It supplements the Registered Performance Metric name to help Performance Metrics Registry users select relevant Registered Performance Metrics. 7.1.5. Reference This entry gives the specification containing the candidate registry entry which was reviewed and agreed, if such an RFC or other specification exists. 7.1.6. Change Controller This entry names the entity responsible for approving revisions to the registry entry, and SHALL provide contact information (for an individual, where appropriate). Bagnulo, et al. Expires September 10, 2020 [Page 17] Internet-Draft Registry for Performance Metrics March 2020 7.1.7. Version (of Registry Format) This entry gives the version number for the registry format used. Formats complying with this memo MUST use 1.0. The version number SHALL NOT change unless a new RFC is published that changes the registry format. The version number of registry entries SHALL NOT change unless the registry entry is updated (following procedures in section 8). 7.2. Metric Definition Category This category includes columns to prompt all necessary details related to the metric definition, including the immutable document reference and values of input factors, called fixed parameters, which are left open in the immutable document, but have a particular value defined by the performance metric. 7.2.1. Reference Definition This entry provides a reference (or references) to the relevant section(s) of the document(s) that define the metric, as well as any supplemental information needed to ensure an unambiguous definition for implementations. The reference needs to be an immutable document, such as an RFC; for other standards bodies, it is likely to be necessary to reference a specific, dated version of a specification. 7.2.2. Fixed Parameters Fixed Parameters are Parameters whose value must be specified in the Performance Metrics Registry. The measurement system uses these values. Where referenced metrics supply a list of Parameters as part of their descriptive template, a sub-set of the Parameters will be designated as Fixed Parameters. As an example for active metrics, Fixed Parameters determine most or all of the IPPM Framework convention "packets of Type-P" as described in [RFC2330], such as transport protocol, payload length, TTL, etc. An example for passive metrics is for RTP packet loss calculation that relies on the validation of a packet as RTP which is a multi-packet validation controlled by MIN_SEQUENTIAL as defined by [RFC3550]. Varying MIN_SEQUENTIAL values can alter the loss report and this value could be set as a Fixed Parameter. Parameters MUST have well-defined names. For human readers, the hanging indent style is preferred, and any Parameter names and Bagnulo, et al. Expires September 10, 2020 [Page 18] Internet-Draft Registry for Performance Metrics March 2020 definitions that do not appear in the Reference Method Specification MUST appear in this column (or Run-time Parameters column). Parameters MUST have a well-specified data format. A Parameter which is a Fixed Parameter for one Performance Metrics Registry entry may be designated as a Run-time Parameter for another Performance Metrics Registry entry. 7.3. Method of Measurement Category This category includes columns for references to relevant sections of the immutable document(s) and any supplemental information needed to ensure an unambiguous method for implementations. 7.3.1. Reference Method This entry provides references to relevant sections of immutable documents, such as RFC(s) (for other standards bodies, it is likely to be necessary to reference a specific, dated version of a specification) describing the method of measurement, as well as any supplemental information needed to ensure unambiguous interpretation for implementations referring to the immutable document text. Specifically, this section should include pointers to pseudocode or actual code that could be used for an unambiguous implementation. 7.3.2. Packet Stream Generation This column applies to Performance Metrics that generate traffic as part of their Measurement Method, including but not necessarily limited to Active metrics. The generated traffic is referred as a stream and this column describes its characteristics. Each entry for this column contains the following information: o Value: The name of the packet stream scheduling discipline o Reference: the specification where the parameters of the stream are defined The packet generation stream may require parameters such as the average packet rate and distribution truncation value for streams with Poisson-distributed inter-packet sending times. In case such parameters are needed, they should be included either in the Fixed parameter column or in the run time parameter column, depending on whether they will be fixed or will be an input for the metric. Bagnulo, et al. Expires September 10, 2020 [Page 19] Internet-Draft Registry for Performance Metrics March 2020 The simplest example of stream specification is Singleton scheduling (see [RFC2330]), where a single atomic measurement is conducted. Each atomic measurement could consist of sending a single packet (such as a DNS request) or sending several packets (for example, to request a webpage). Other streams support a series of atomic measurements in a "sample", with a schedule defining the timing between each transmitted packet and subsequent measurement. Principally, two different streams are used in IPPM metrics, Poisson distributed as described in [RFC2330] and Periodic as described in [RFC3432]. Both Poisson and Periodic have their own unique parameters, and the relevant set of parameters names and values should be included either in the Fixed Parameters column or in the Run-time parameter column. 7.3.3. Traffic Filter This column applies to Performance Metrics that observe packets flowing through (the device with) the measurement agent i.e. that is not necessarily addressed to the measurement agent. This includes but is not limited to Passive Metrics. The filter specifies the traffic that is measured. This includes protocol field values/ ranges, such as address ranges, and flow or session identifiers. The traffic filter itself depends on needs of the metric itself and a balance of an operator's measurement needs and a user's need for privacy. Mechanics for conveying the filter criteria might be the BPF (Berkley Packet Filter) or PSAMP [RFC5475] Property Match Filtering which reuses IPFIX [RFC7012]. An example BPF string for matching TCP/80 traffic to remote destination net 192.0.2.0/24 would be "dst net 192.0.2.0/24 and tcp dst port 80". More complex filter engines might be supported by the implementation that might allow for matching using Deep Packet Inspection (DPI) technology. The traffic filter includes the following information: Type: the type of traffic filter used, e.g. BPF, PSAMP, OpenFlow rule, etc. as defined by a normative reference Value: the actual set of rules expressed 7.3.4. Sampling Distribution The sampling distribution defines out of all the packets that match the traffic filter, which one of those are actually used for the measurement. One possibility is "all" which implies that all packets matching the Traffic filter are considered, but there may be other sampling strategies. It includes the following information: Bagnulo, et al. Expires September 10, 2020 [Page 20] Internet-Draft Registry for Performance Metrics March 2020 Value: the name of the sampling distribution Reference definition: pointer to the specification where the sampling distribution is properly defined. The sampling distribution may require parameters. In case such parameters are needed, they should be included either in the Fixed parameter column or in the run time parameter column, depending on whether they will be fixed or will be an input for the metric. Sampling and Filtering Techniques for IP Packet Selection are documented in the PSAMP (Packet Sampling) [RFC5475], while the Framework for Packet Selection and Reporting, [RFC5474] provides more background information. The sampling distribution parameters might be expressed in terms of the Information Model for Packet Sampling Exports, [RFC5477], and the Flow Selection Techniques, [RFC7014]. 7.3.5. Run-time Parameters Run-Time Parameters are Parameters that must be determined, configured into the measurement system, and reported with the results for the context to be complete. However, the values of these parameters is not specified in the Performance Metrics Registry (like the Fixed Parameters), rather these parameters are listed as an aid to the measurement system implementer or user (they must be left as variables, and supplied on execution). Where metrics supply a list of Parameters as part of their descriptive template, a sub-set of the Parameters will be designated as Run-Time Parameters. Parameters MUST have well defined names. For human readers, the hanging indent style is preferred, and the names and definitions that do not appear in the Reference Method Specification MUST appear in this column. A Data Format for each Run-time Parameter MUST be specified in this column, to simplify the control and implementation of measurement devices. For example, parameters that include an IPv4 address can be encoded as a 32 bit integer (i.e. binary base64 encoded value) or ip- address as defined in [RFC6991]. The actual encoding(s) used must be explicitly defined for each Run-time parameter. IPv6 addresses and options MUST be accommodated, allowing Registered Metrics to be used in that address family. Other address families are permissable. Examples of Run-time Parameters include IP addresses, measurement point designations, start times and end times for measurement, and other information essential to the method of measurement. Bagnulo, et al. Expires September 10, 2020 [Page 21] Internet-Draft Registry for Performance Metrics March 2020 7.3.6. Role In some methods of measurement, there may be several roles defined, e.g., for a one-way packet delay active measurement there is one measurement agent that generates the packets and another agent that receives the packets. This column contains the name of the Role(s) for this particular entry. In the one-way delay example above, there should be two entries in the Role registry column, one for each Role (Source and Destination). When a measurement agent is instructed to perform the "Source" Role for one-way delay metric, the agent knows that it is required to generate packets. The values for this field are defined in the reference method of measurement (and this frequently results in abbreviated role names such as "Src"). When the Role column of a registry entry defines more than one Role, then the Role SHALL be treated as a Run-time Parameter and supplied for execution. It should be noted that the LMAP framework [RFC7594] distinguishes the Role from other Run-time Parameters, and defines a special parameter "Roles" inside the registry-grouping function list in the LMAP YANG model[RFC8194]. 7.4. Output Category For entries which involve a stream and many singleton measurements, a statistic may be specified in this column to summarize the results to a single value. If the complete set of measured singletons is output, this will be specified here. Some metrics embed one specific statistic in the reference metric definition, while others allow several output types or statistics. 7.4.1. Type This column contains the name of the output type. The output type defines a single type of result that the metric produces. It can be the raw results (packet send times and singleton metrics), or it can be a summary statistic. The specification of the output type MUST define the format of the output. In some systems, format specifications will simplify both measurement implementation and collection/storage tasks. Note that if two different statistics are required from a single measurement (for example, both "Xth percentile mean" and "Raw"), then a new output type must be defined ("Xth percentile mean AND Raw"). See the Naming section above for a list of Output Types. Bagnulo, et al. Expires September 10, 2020 [Page 22] Internet-Draft Registry for Performance Metrics March 2020 7.4.2. Reference Definition This column contains a pointer to the specification(s) where the output type and format are defined. 7.4.3. Metric Units The measured results must be expressed using some standard dimension or units of measure. This column provides the units. When a sample of singletons (see Section 11 of[RFC2330] for definitions of these terms) is collected, this entry will specify the units for each measured value. 7.4.4. Calibration Some specifications for Methods of Measurement include the possibility to perform an error calibration. Section 3.7.3 of [RFC7679] is one example. In the registry entry, this field will identify a method of calibration for the metric, and when available, the measurement system SHOULD perform the calibration when requested and produce the output with an indication that it is the result of a calibration method. In-situ calibration could be enabled with an internal loopback that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized this way. For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets of clocks at both the source and destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets are smoothed, thus the random variation is not usually represented in the results). Both internal loopback calibration and clock synchronization can be used to estimate the *available accuracy* of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the Output result resolution which is the result of system noise, and thus inaccurate. Bagnulo, et al. Expires September 10, 2020 [Page 23] Internet-Draft Registry for Performance Metrics March 2020 7.5. Administrative information 7.5.1. Status The status of the specification of this Registered Performance Metric. Allowed values are 'current' and 'deprecated'. All newly defined Information Elements have 'current' status. 7.5.2. Requester The requester for the Registered Performance Metric. The requester MAY be a document, such as RFC, or person. 7.5.3. Revision The revision number of a Registered Performance Metric, starting at 0 for Registered Performance Metrics at time of definition and incremented by one for each revision. 7.5.4. Revision Date The date of acceptance or the most recent revision for the Registered Performance Metric. The date SHALL be determined by IANA and the reviewing Performance Metrics Expert. 7.6. Comments and Remarks Besides providing additional details which do not appear in other categories, this open Category (single column) allows for unforeseen issues to be addressed by simply updating this informational entry. 8. Processes for Managing the Performance Metric Registry Group Once a Performance Metric or set of Performance Metrics has been identified for a given application, candidate Performance Metrics Registry entry specifications prepared in accordance with Section 7 should be submitted to IANA to follow the process for review by the Performance Metric Experts, as defined below. This process is also used for other changes to the Performance Metrics Registry, such as deprecation or revision, as described later in this section. It is desirable that the author(s) of a candidate Performance Metrics Registry entry seek review in the relevant IETF working group, or offer the opportunity for review on the working group mailing list. Bagnulo, et al. Expires September 10, 2020 [Page 24] Internet-Draft Registry for Performance Metrics March 2020 8.1. Adding new Performance Metrics to the Performance Metrics Registry Requests to add Registered Performance Metrics in the Performance Metrics Registry SHALL be submitted to IANA, which forwards the request to a designated group of experts (Performance Metric Experts) appointed by the IESG; these are the reviewers called for by the Specification Required [RFC8126] policy defined for the Performance Metrics Registry. The Performance Metric Experts review the request for such things as compliance with this document, compliance with other applicable Performance Metric-related RFCs, and consistency with the currently defined set of Registered Performance Metrics. The most efficient path for submission begins with preparation of an Internet Draft containing the proposed Performance Metrics Registry entry using the template in Section 11, so that the submission formatting will benefit from the normal IETF Internet Draft submission processing (including HTML-ization). Submission to IANA may be during IESG review (leading to IETF Standards Action), where an Internet Draft proposes one or more Registered Performance Metrics to be added to the Performance Metrics Registry, including the text of the proposed Registered Performance Metric(s). If an RFC-to-be includes a Performance Metric and a proposed Performance Metrics Registry entry, but the Performance Metric Expert review determines that one or more of the Section 5 criteria have not been met, then the proposed Performance Metrics Registry entry MUST be removed from the text. Once evidence exists that the Performance Metric meets the criteria in section 5, the proposed Performance Metrics Registry entry SHOULD be submitted to IANA to be evaluated in consultation with the Performance Metric Experts for registration at that time. Authors of proposed Registered Performance Metrics SHOULD review compliance with the specifications in this document to check their submissions before sending them to IANA. At least one Performance Metric Expert should endeavor to complete referred reviews in a timely manner. If the request is acceptable, the Performance Metric Experts signify their approval to IANA, and IANA updates the Performance Metrics Registry. If the request is not acceptable, the Performance Metric Experts MAY coordinate with the requester to change the request to be compliant, otherwise IANA SHALL coordinate resolution of issues on behalf of the expert. The Performance Metric Experts MAY choose to reject clearly frivolous or inappropriate change requests outright, but such exceptional circumstances should be rare. Bagnulo, et al. Expires September 10, 2020 [Page 25] Internet-Draft Registry for Performance Metrics March 2020 This process should not in any way be construed as allowing the Performance Metric Experts to overrule IETF consensus. Specifically, any Registered Performance Metrics that were added to the Performance Metrics Registry with IETF consensus require IETF consensus for revision or deprecation. Decisions by the Performance Metric Experts may be appealed as in Section 7 of [RFC8126]. 8.2. Revising Registered Performance Metrics A request for Revision is only permitted when the requested changes maintain backward-compatibility with implementations of the prior Performance Metrics Registry entry describing a Registered Performance Metric (entries with lower revision numbers, but the same Identifier and Name). The purpose of the Status field in the Performance Metrics Registry is to indicate whether the entry for a Registered Performance Metric is 'current' or 'deprecated'. In addition, no policy is defined for revising the Performance Metric entries in the IANA Registry or addressing errors therein. To be clear, changes and deprecations within the Performance Metrics Registry are not encouraged, and should be avoided to the extent possible. However, in recognition that change is inevitable, the provisions of this section address the need for revisions. Revisions are initiated by sending a candidate Registered Performance Metric definition to IANA, as in Section 8.1, identifying the existing Performance Metrics Registry entry, and explaining how and why the existing entry should be revised. The primary requirement in the definition of procedures for managing changes to existing Registered Performance Metrics is avoidance of measurement interoperability problems; the Performance Metric Experts must work to maintain interoperability above all else. Changes to Registered Performance Metrics may only be done in an interoperable way; necessary changes that cannot be done in a way to allow interoperability with unchanged implementations MUST result in the creation of a new Registered Performance Metric (with a new Name, replacing the RFCXXXXsecY portion of the name) and possibly the deprecation of the earlier metric. A change to a Registered Performance Metric SHALL be determined to be backward-compatible when: Bagnulo, et al. Expires September 10, 2020 [Page 26] Internet-Draft Registry for Performance Metrics March 2020 1. it involves the correction of an error that is obviously only editorial; or 2. it corrects an ambiguity in the Registered Performance Metric's definition, which itself leads to issues severe enough to prevent the Registered Performance Metric's usage as originally defined; or 3. it corrects missing information in the metric definition without changing its meaning (e.g., the explicit definition of 'quantity' semantics for numeric fields without a Data Type Semantics value); or 4. it harmonizes with an external reference that was itself corrected. If a Performance Metric revision is deemed permissible and backward- compatible by the Performance Metric Experts, according to the rules in this document, IANA SHOULD execute the change(s) in the Performance Metrics Registry. The requester of the change is appended to the original requester in the Performance Metrics Registry. The Name of the revised Registered Performance Metric, including the RFCXXXXsecY portion of the name, SHALL remain unchanged (even when the change is the result of IETF Standards Action; the revised registry entry SHOULD reference the new immutable document, such as an RFC or for other standards bodies, it is likely to be necessary to reference a specific, dated version of a specification, in an appropriate category and column). Each Registered Performance Metric in the Performance Metrics Registry has a revision number, starting at zero. Each change to a Registered Performance Metric following this process increments the revision number by one. When a revised Registered Performance Metric is accepted into the Performance Metrics Registry, the date of acceptance of the most recent revision is placed into the revision Date column of the registry for that Registered Performance Metric. Where applicable, additions to Registered Performance Metrics in the form of text Comments or Remarks should include the date, but such additions may not constitute a revision according to this process. Older version(s) of the updated metric entries are kept in the registry for archival purposes. The older entries are kept with all fields unmodified (version, revision date) except for the status field that SHALL be changed to "Deprecated". Bagnulo, et al. Expires September 10, 2020 [Page 27] Internet-Draft Registry for Performance Metrics March 2020 8.3. Deprecating Registered Performance Metrics Changes that are not permissible by the above criteria for Registered Performance Metric's revision may only be handled by deprecation. A Registered Performance Metric MAY be deprecated and replaced when: 1. the Registered Performance Metric definition has an error or shortcoming that cannot be permissibly changed as in Section 8.2 Revising Registered Performance Metrics; or 2. the deprecation harmonizes with an external reference that was itself deprecated through that reference's accepted deprecation method. A request for deprecation is sent to IANA, which passes it to the Performance Metric Experts for review. When deprecating an Performance Metric, the Performance Metric description in the Performance Metrics Registry must be updated to explain the deprecation, as well as to refer to any new Performance Metrics created to replace the deprecated Performance Metric. The revision number of a Registered Performance Metric is incremented upon deprecation, and the revision Date updated, as with any revision. The intentional use of deprecated Registered Performance Metrics should result in a log entry or human-readable warning by the respective application. Names and Metric IDs of deprecated Registered Performance Metrics must not be reused. The deprecated entries are kept with all fields unmodified, except the version, revision date, and the status field (changed to "Deprecated"). 9. Security considerations This draft defines a registry structure, and does not itself introduce any new security considerations for the Internet. The definition of Performance Metrics for this registry may introduce some security concerns, but the mandatory references should have their own considerations for security, and such definitions should be reviewed with security in mind if the security considerations are not covered by one or more reference standards. The aggregated results of the performance metrics described in this registry might reveal network topology information that may be Bagnulo, et al. Expires September 10, 2020 [Page 28] Internet-Draft Registry for Performance Metrics March 2020 considered sensitive. If such cases are found, then access control mechanisms should be applied. 10. IANA Considerations With the background and processes described in earlier sections, this document requests the following IANA Actions. Editor's Note: Mock-ups of the implementation of this set of requests have been prepared with IANA's help during development of this memo, and have been captured in the Proceedings of IPPM working group sessions. IANA is currently preparing a mock-up. A recent version is available here: http://encrypted.net/IETFMetricsRegistry-106.html 10.1. Registry Group The new registry group SHALL be named, "PERFORMANCE METRICS Group". Registration Procedure: Specification Required Reference: Experts: Performance Metrics Experts Note: TBD 10.2. Performance Metric Name Elements This document specifies the procedure for Performance Metrics Name Element Registry setup. IANA is requested to create a new set of registries for Performance Metric Name Elements called "Registered Performance Metric Name Elements". Each Registry, whose names are listed below: MetricType: Method: SubTypeMethod: Spec: Units: Output: will contain the current set of possibilities for Performance Metrics Registry Entry Names. Bagnulo, et al. Expires September 10, 2020 [Page 29] Internet-Draft Registry for Performance Metrics March 2020 To populate the Registered Performance Metric Name Elements at creation, the IANA is asked to use the lists of values for each name element listed in Section 7.1.2. The Name Elements in each registry are case-sensitive. When preparing a Metric entry for Registration, the developer SHOULD choose Name elements from among the registered elements. However, if the proposed metric is unique in a significant way, it may be necessary to propose a new Name element to properly describe the metric, as described below. A candidate Metric Entry RFC or immutable document for IANA and Expert Review would propose one or more new element values required to describe the unique entry, and the new name element(s) would be reviewed along with the metric entry. New assignments for Registered Performance Metric Name Elements will be administered by IANA through Specification Required policy (which includes Expert Review) [RFC8126], i.e., review by one of a group of experts, the Performance Metric Experts, who are appointed by the IESG upon recommendation of the Transport Area Directors. 10.3. New Performance Metrics Registry This document specifies the procedure for Performance Metrics Registry setup. IANA is requested to create a new registry for Performance Metrics called "Performance Metrics Registry". This Registry will contain the following Summary columns: Identifier: Name: URI: Description: Reference: Change Controller: Version: Descriptions of these columns and additional information found in the template for registry entries (categories and columns) are further defined in section Section 7. The Identifier 0 should be Reserved. The Registered Performance Metric unique identifier is an unbounded integer (range 0 to Bagnulo, et al. Expires September 10, 2020 [Page 30] Internet-Draft Registry for Performance Metrics March 2020 infinity). The Identifier values from 64512 to 65536 are reserved for private or experimental use, and the user may encounter overlapping uses. When adding newly Registered Performance Metrics to the Performance Metrics Registry, IANA SHOULD assign the lowest available identifier to the new Registered Performance Metric. If a Performance Metrics Expert providing review determines that there is a reason to assign a specific numeric identifier, possibly leaving a temporary gap in the numbering, then the Performance Expert SHALL inform IANA of this decision. Names starting with the prefix Priv_ are reserved for private use, and are not considered for registration. The "Name" column entries are further defined in section Section 7. The "URI" column will have a URL to the full template of each registry entry. The Registry Entry text SHALL be HTML-ized to aid the reader, with links to reference RFCs (similar to the way that Internet Drafts are HTML-ized, the same tool can perform the function) or immutable document. The "Reference" column will include an RFC number, an approved specification designator from another standards body, or other immutable document. New assignments for Performance Metrics Registry will be administered by IANA through Specification Required policty (which includes Expert Review) [RFC8126], i.e., review by one of a group of experts, the Performance Metric Experts, who are appointed by the IESG upon recommendation of the Transport Area Directors, or by Standards Action. The experts can be initially drawn from the Working Group Chairs, document editors, and members of the Performance Metrics Directorate, among other sources of experts. Extensions of the Performance Metrics Registry require IETF Standards Action. Only one form of registry extension is envisaged: 1. Adding columns, or both categories and columns, to accommodate unanticipated aspects of new measurements and metric categories. If the Performance Metrics Registry is extended in this way, the Version number of future entries complying with the extension SHALL be incremented (either in the unit or tenths digit, depending on the degree of extension. Bagnulo, et al. Expires September 10, 2020 [Page 31] Internet-Draft Registry for Performance Metrics March 2020 11. Blank Registry Template This section provides a blank template to help IANA and registry entry writers. 11.1. Summary This category includes multiple indexes to the registry entry: the element ID and metric name. 11.1.1. ID (Identifier) 11.1.2. Name 11.1.3. URI URL: https://www.iana.org/ ... 11.1.4. Description 11.1.5. Change Controller 11.1.6. Version (of Registry Format) 11.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the immutable document reference and values of input factors, called fixed parameters. 11.2.1. Reference Definition 11.2.2. Fixed Parameters Bagnulo, et al. Expires September 10, 2020 [Page 32] Internet-Draft Registry for Performance Metrics March 2020 11.3. Method of Measurement This category includes columns for references to relevant sections of the immutable documents(s) and any supplemental information needed to ensure an unambiguous methods for implementations. 11.3.1. Reference Method 11.3.2. Packet Stream Generation 11.3.3. Traffic Filtering (observation) Details The measured results based on a filtered version of the packets observed, and this section provides the filter details (when present).
. 11.3.4. Sampling Distribution 11.3.5. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. 11.3.6. Roles 11.4. Output This category specifies all details of the Output of measurements using the metric. Bagnulo, et al. Expires September 10, 2020 [Page 33] Internet-Draft Registry for Performance Metrics March 2020 11.4.1. Type 11.4.2. Reference Definition 11.4.3. Metric Units . 11.4.4. Calibration 11.5. Administrative items 11.5.1. Status 11.5.2. Requester 11.5.3. Revision <1.0> 11.5.4. Revision Date 11.6. Comments and Remarks 12. Acknowledgments Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading some brainstorming sessions on this topic. Thanks to Barbara Stark and Juergen Schoenwaelder for the detailed feedback and suggestions. Thanks to Andrew McGregor for suggestions on metric naming. Thanks to Michelle Cotton for her early IANA review, and to Amanda Barber for answering questions related to the presentation of the registry and accessibility of the complete template via URL. Thanks to Roni Bagnulo, et al. Expires September 10, 2020 [Page 34] Internet-Draft Registry for Performance Metrics March 2020 Even for his review and suggestions to generalize the procedures. Thanks to ~all the Area Directors for their reviews. 13. References 13.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, . [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, . [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, . [RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Bagnulo, et al. Expires September 10, 2020 [Page 35] Internet-Draft Registry for Performance Metrics March 2020 13.2. Informative References [I-D.ietf-ippm-initial-registry] Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, "Initial Performance Metrics Registry Entries", draft- ietf-ippm-initial-registry-15 (work in progress), December 2019. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2005, . [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, March 2009, . [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, . [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, . Bagnulo, et al. Expires September 10, 2020 [Page 36] Internet-Draft Registry for Performance Metrics March 2020 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, DOI 10.17487/RFC6035, November 2010, . [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, DOI 10.17487/RFC6248, April 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, September 2013, . [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, . [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, August 2017, . Authors' Addresses Bagnulo, et al. Expires September 10, 2020 [Page 37] Internet-Draft Registry for Performance Metrics March 2020 Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Email: bclaise@cisco.com Philip Eardley BT Adastral Park, Martlesham Heath Ipswich ENGLAND Email: philip.eardley@bt.com Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ USA Email: acmorton@att.com Aamer Akhter Consultant 118 Timber Hitch Cary, NC USA Email: aakhter@gmail.com Bagnulo, et al. Expires September 10, 2020 [Page 38] ./draft-ietf-ippm-stamp-option-tlv-10.txt0000644000764400076440000022714713754307334017577 0ustar iustyiusty Network Working Group G. Mirsky Internet-Draft X. Min Updates: 8762 (if approved) ZTE Corp. Intended status: Standards Track H. Nydell Expires: May 19, 2021 Accedian Networks R. Foote Nokia A. Masputra Apple Inc. E. Ruffini OutSys November 15, 2020 Simple Two-way Active Measurement Protocol Optional Extensions draft-ietf-ippm-stamp-option-tlv-10 Abstract This document describes optional extensions to Simple Two-way Active Measurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 19, 2021. Copyright Notice Copyright (c) 2020 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 Mirsky, et al. Expires May 19, 2021 [Page 1] Internet-Draft STAMP Extensions November 2020 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. STAMP Test Session Identifier . . . . . . . . . . . . . . . . 4 4. TLV Extensions to STAMP . . . . . . . . . . . . . . . . . . . 8 4.1. Extra Padding TLV . . . . . . . . . . . . . . . . . . . . 11 4.2. Location TLV . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Location Sub-TLVs . . . . . . . . . . . . . . . . . . 13 4.2.2. Theory of Operation of Location TLV . . . . . . . . . 14 4.3. Timestamp Information TLV . . . . . . . . . . . . . . . . 16 4.4. Class of Service TLV . . . . . . . . . . . . . . . . . . 17 4.5. Direct Measurement TLV . . . . . . . . . . . . . . . . . 18 4.6. Access Report TLV . . . . . . . . . . . . . . . . . . . . 20 4.7. Follow-up Telemetry TLV . . . . . . . . . . . . . . . . . 21 4.8. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 23 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 5.1. STAMP TLV Registry . . . . . . . . . . . . . . . . . . . 24 5.2. STAMP TLV Flags Sub-registry . . . . . . . . . . . . . . 25 5.3. Sub-TLV Type Sub-registry . . . . . . . . . . . . . . . . 26 5.4. Synchronization Source Sub-registry . . . . . . . . . . . 26 5.5. Timestamping Method Sub-registry . . . . . . . . . . . . 27 5.6. Return Code Sub-registry . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defined the STAMP base functionalities. This document specifies the use of optional extensions that use Type-Length-Value (TLV) encoding. Such extensions enhance the STAMP base functions, such as measurement of one-way and round-trip delay, latency, packet loss, packet Mirsky, et al. Expires May 19, 2021 [Page 2] Internet-Draft STAMP Extensions November 2020 duplication, and out-of-order delivery of test packets. This specification defines optional STAMP extensions, their formats, and the theory of operation. Also, a STAMP Test Session Identifier is defined as an update of the base STAMP specification [RFC8762]. 2. Conventions Used in This Document 2.1. Acronyms BDS BeiDou Navigation Satellite System BITS Building Integrated Timing Supply CoS Class of Service DSCP Differentiated Services Code Point ECN Explicit Congestion Notification GLONASS Global Orbiting Navigation Satellite System GPS Global Positioning System [GPS] HMAC Hashed Message Authentication Code LORAN-C Long Range Navigation System Version C MBZ Must Be Zero NTP Network Time Protocol [RFC5905] PMF Performance Measurement Function PTP Precision Time Protocol [IEEE.1588.2008] TLV Type-Length-Value SSID STAMP Session Identifier SSU Synchronization Supply Unit STAMP Simple Two-way Active Measurement Protocol 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP Mirsky, et al. Expires May 19, 2021 [Page 3] Internet-Draft STAMP Extensions November 2020 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. STAMP Test Session Identifier The STAMP Session-Sender transmits test packets to the STAMP Session- Reflector. The STAMP Session-Reflector receives the Session-Sender's packet and acts according to the configuration and optional control information communicated in the Session-Sender's test packet. STAMP defines two different test packet formats, one for packets transmitted by the STAMP Session-Sender and one for packets transmitted by the STAMP Session-Reflector. STAMP supports two modes: unauthenticated and authenticated. Unauthenticated STAMP test packets are compatible on the wire with unauthenticated TWAMP-Test [RFC5357] packets. By default, STAMP uses symmetrical packets, i.e., the size of the packet transmitted by the Session-Reflector equals the size of the packet received by the Session-Reflector. A STAMP Session is identified by the 4-tuple (source and destination IP addresses, source and destination UDP port numbers). A STAMP Session-Sender MAY generate a locally unique STAMP Session Identifier (SSID). The SSID is a two-octet-long non-zero unsigned integer. SSID generation policy is implementation-specific. [I-D.gont-numeric-ids-generation] thoroughly analyzes common algorithms for identifier generation and their vulnerabilities. For example, an implementation can use algorithms described in Section 7.1 of [I-D.gont-numeric-ids-generation]. An implementation MUST NOT assign the same identifier to different STAMP test sessions. A Session-Sender MAY use the SSID to identify a STAMP test session. If the SSID is used, it MUST be present in each test packet of the given test session. In the unauthenticated mode, the SSID is located as displayed in Figure 1. Mirsky, et al. Expires May 19, 2021 [Page 4] Internet-Draft STAMP Extensions November 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | SSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | MBZ (28 octets) | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The format of an extended STAMP Session-Sender test packet in unauthenticated mode An implementation of the STAMP Session-Reflector that supports this specification MUST identify a STAMP Session using the SSID in combination with elements of the usual 4-tuple for the session. Before a test session commences, a Session-Reflector MUST be provisioned with all the elements that identify the STAMP Session. A STAMP Session-Reflector MUST discard non-matching STAMP test packet(s). The means of provisioning the STAMP Session identification is outside the scope of this specification. A conforming implementation of STAMP Session-Reflector MUST copy the SSID value from the received test packet and put it into the reflected packet, as displayed in Figure 2. Mirsky, et al. Expires May 19, 2021 [Page 5] Internet-Draft STAMP Extensions November 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | SSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ses-Sender TTL | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The format of an extended STAMP Session-Reflector test packet in unauthenticated mode A STAMP Session-Reflector that does not support this specification will return the zeroed SSID field in the reflected STAMP test packet. The Session-Sender MAY stop the session if it receives a zeroed SSID field. An implementation of a Session-Sender MUST support control of its behavior in such a scenario. If the test session is not stopped, the Session-Sender, can, for example, send a base STAMP packet [RFC8762] or continue transmitting STAMP test packets with the SSID. Location of the SSID field in the authenticated mode is shown in Figure 3 and Figure 4. Mirsky, et al. Expires May 19, 2021 [Page 6] Internet-Draft STAMP Extensions November 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MBZ (12 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | SSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | MBZ (68 octets) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Base STAMP Session-Sender test packet format in authenticated mode 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (12 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | SSID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mirsky, et al. Expires May 19, 2021 [Page 7] Internet-Draft STAMP Extensions November 2020 | MBZ (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (12 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ses-Sender TTL | | +-+-+-+-+-+-+-+-+ + | | | MBZ (15 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC (16 octets) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Base STAMP Session-Reflector test packet format in authenticated mode 4. TLV Extensions to STAMP The Type-Length-Value (TLV) encoding scheme provides a flexible extension mechanism for optional informational elements. TLV is an optional field in the STAMP test packet. Multiple TLVs MAY be placed in a STAMP test packet. Additional TLVs may be enclosed within a given TLV, subject to the semantics of the (outer) TLV in question. TLVs have a one-octet-long STAMP TLV Flags field, a one-octet-long Type field, and a two-octet-long Length field that is equal to the length of the Value field in octets. If a Type value for TLV or sub- TLV is in the range for Vendor Private Use, the Length MUST be at least 4, and the first four octets MUST be that vendor's Structure of Management Information (SMI) Private Enterprise Code, as recorded in IANA's SMI Private Enterprise Codes sub-registry, in network octet Mirsky, et al. Expires May 19, 2021 [Page 8] Internet-Draft STAMP Extensions November 2020 order. The rest of the Value field is private to the vendor. The following sections describe the use of TLVs for STAMP that extend the STAMP capability beyond its base specification. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: TLV Format in a STAMP Extended Packet where fields are defined as the following: o STAMP TLV Flags - eight-bit-long field. Detailed format and interpretation of flags defined in this specification is below. o Type - one-octet-long field that characterizes the interpretation of the Value field. It is allocated by IANA, as specified in Section 5.1. o Length - two-octet-long field equal to the length of the Value field in octets. o Value - a variable-length field. Its interpretation and encoding is determined by the value of the Type field. All multibyte fields in TLVs defined in this specification are in network byte order. The format of the STAMP TLV Flags displayed in Figure 6 and the location of flags is according to Section 5.2. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |U|M|I|R|R|R|R|R| +-+-+-+-+-+-+-+-+ Figure 6: STAMP TLV Flags Format where fields are defined as the following: o U (Unrecognized) is a one-bit flag. A Session-Sender MUST set the U flag to 1 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the U flag to 1 if the Session- Mirsky, et al. Expires May 19, 2021 [Page 9] Internet-Draft STAMP Extensions November 2020 Reflector has not understood the TLV. Otherwise, the Session- Reflector MUST set the U flag in the reflected packet to 0. o M (Malformed) is a one-bit flag. A Session-Sender MUST set the M flag to 0 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the M flag to 1 if the Session- Reflector determined the TLV is malformed, i.e., the Length field value is not valid for the particular type, or the remaining length of the extended STAMP packet is less than the size of the TLV. Otherwise, the Session-Reflector MUST set the M flag in the reflected packet to 0. o I (Integrity) is a one-bit flag. A Session-Sender MUST set the I flag to 0 before transmitting an extended STAMP test packet. A Session-Reflector MUST set the I flag to 1 if the STAMP extensions have failed HMAC verification (Section 4.8). Otherwise, the Session-Reflector MUST set the I flag in the reflected packet to 0. o R - reserved flags for future use. These flags MUST be zeroed on transmit and ignored on receipt. A STAMP node, whether Session-Sender or Session-Reflector, receiving a test packet MUST determine whether the packet is a base STAMP packet or includes one or more TLVs. The node MUST compare the value in the Length field of the UDP header and the length of the base STAMP test packet in the mode, unauthenticated or authenticated based on the configuration of the particular STAMP test session. If the difference between the two values is larger than the length of the UDP header, then the test packet includes one or more STAMP TLVs that immediately follow the base STAMP test packet. A Session-Reflector that does not support STAMP extensions will not process but copy them into the reflected packet, as defined in Section 4.3 [RFC8762]. A Session-Reflector that supports TLVs will indicate specific TLVs that it did not process by setting the U flag to 1 in those TLVs. A STAMP Session-Sender that has received a reflected STAMP test packet with extension TLVs MUST validate each TLV: If the U flag is set, the STAMP system MUST skip the processing of the TLV. If the M flag is set, the STAMP system MUST stop processing the remainder of the extended STAMP packet. If the I flag is set, the STAMP system MUST discard all TLVs and MUST stop processing the remainder of the extended STAMP packet. Mirsky, et al. Expires May 19, 2021 [Page 10] Internet-Draft STAMP Extensions November 2020 If an implementation of a Session-Reflector does not recognize the Type field value, it MUST include a copy of the TLV into the reflected STAMP packet. The Session-Reflector MUST set the U flag to 1. The Session-Reflector MUST skip the processing of the unrecognized TLV. If a TLV is malformed, the processing of extension TLVs MUST be stopped. The Session-Reflector MUST copy the remainder of the received extended STAMP packet into the reflected STAMP packet. The Session-Reflector MUST set the M flag to 1. 4.1. Extra Padding TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags|Extra Pad Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Extra Padding ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Extra Padding TLV where fields are defined as the following: o STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Figure 6. o Extra Padding Type - is a one-octet-long field, value TBA1 allocated by IANA Section 5.1. o Length - two-octet-long field equal to the length of the Extra Padding field in octets. o Extra Padding - SHOULD be filled by a sequence of a pseudo-random numbers. The field MAY be filled with all zeros. An implementation MUST control the type of filling of the Extra Padding field. The Extra Padding TLV is similar to the Packet Padding field in a TWAMP-Test packet [RFC5357]. The use of the Extra Padding TLV is RECOMMENDED to perform a STAMP test using test packets of larger size than the base STAMP packet [RFC8762]. The length of the base STAMP packet is 44 octets in the unauthenticated mode or 112 octets in the authenticated mode. The Extra Padding TLV MAY be present more than one time in an extended STAMP test packet. Mirsky, et al. Expires May 19, 2021 [Page 11] Internet-Draft STAMP Extensions November 2020 4.2. Location TLV STAMP Session-Senders MAY include the variable-size Location TLV to query location information from the Session-Reflector. The Session- Sender MUST NOT fill any information fields except for STAMP TLV Flags, Type, and Length. The Session-Reflector MUST verify that the TLV is well-formed. If it is not, the Session-Reflector follows the procedure defined in Section 4 for a malformed TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Location Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Port | Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Location TLV where fields are defined as the following: o STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Figure 6. o Location Type - is a one-octet-long field, value TBA2 allocated by IANA Section 5.1. o Length - two-octet-long field equal to the length of the Value field in octets. o Destination Port - two-octet-long UDP destination port number of the received STAMP packet. o Source Port - two-octet-long UDP source port number of the received STAMP packet. o Sub-TLVs - a sequence of sub-TLVs, as defined further in this section. The sub-TLVs are used by the Session-Sender to request location information with generic sub-TLV types, and the Session- Reflector responds with the corresponding more-specific sub-TLVs for the type of address (e.g., IPv4 or IPv6) used at the Session- Reflector. Note that all fields not filled by either a Session-Sender or Session-Reflector are transmitted with all bits set to zero. Mirsky, et al. Expires May 19, 2021 [Page 12] Internet-Draft STAMP Extensions November 2020 4.2.1. Location Sub-TLVs A sub-TLV in the Location TLV uses the format displayed in Figure 5. Handling of the U and M flags in the sub-TLV is as defined in Section 4. The I flag MUST be set by a Session-Sender and Session- Reflector to 0 before transmission and its value ignored on receipt. The following types of sub-TLV for the Location TLV are defined in this specification (type values are assigned according to Table 5): o Source MAC Address sub-TLV - is a 12-octet-long sub-TLV. The Type value is TBA9. The value of the Length field MUST equal to 8. The Value field is an 8-octet-long MBZ field that MUST be zeroed on transmission and ignored on receipt. o Source EUI-48 Address sub-TLV - is a 12-octet-long sub-TLV that includes the EUI-48 source MAC address. The Type value is TBA10. The value of the Length field MUST equal to 8. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EUI-48 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: The Value Field of the Source EUI-48 Address sub-TLV The Value field consists of the following fields (Figure 9): * The EUI-48 is a six-octet-long field. * Two-octet-ling MBZ field MUST be zeroed on transmission and ignored on receipt. o Source EUI-64 Address sub-TLV - is a 12-octet-long sub-TLV that includes the EUI-64 source MAC address. The Type value is TBA11. The value of the Length field MUST equal to 8. The Value field consists of an eight-octet-long EUI-64 field. o Destination IP Address sub-TLV - is a 20-octet-long sub-TLV. The Type value is TBA12. The value of the Length field MUST equal to 16. The Value field consists of a 16-octet-long MBZ field that MUST be zeroed on transmit and ignored on receipt o Destination IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that includes IPv4 destination address. The Type value is TBA13. The value of the Length field MUST equal to 16. Mirsky, et al. Expires May 19, 2021 [Page 13] Internet-Draft STAMP Extensions November 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ MBZ (12 octets) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: IPv4 Address in a Sub-TLV's Value Field The Value field consists of the following fields (Figure 10): * The IPv4 Address is a four-octet-long field. * 12-octet-long MBZ field MUST be zeroed on transmit and ignored on receipt. o Destination IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that includes IPv6 destination address. The Type value is TBA14. The value of the Length field MUST equal to 16. The Value field is a 16-octet-long IP v6 Address field. o Source IP Address sub-TLV - is a 20-octet-long sub-TLV. The Type value is TBA15. The value of the Length field MUST equal to 16. The Value field is a 16-octet-long MBZ field that MUST be zeroed on transmit and ignored on receipt o Source IPv4 Address sub-TLV - is a 20-octet-long sub-TLV that includes IPv4 source address. The Type value is TBA16. The value of the Length field MUST equal to 16. The Value field consists of the following fields (Figure 10): * The IPv4 Address is a four-octet-long field. * 12-octet-long MBZ field that MUST be zeroed on transmit and ignored on receipt. o Source IPv6 Address sub-TLV - is a 20-octet-long sub-TLV that includes IPv6 source address. The Type value is TBA17. The value of the Length field MUST equal to 16. The Value field is a 16- octet-long IPv6 Address field. 4.2.2. Theory of Operation of Location TLV The Session-Reflector that received an extended STAMP packet with the Location TLV MUST include the Location TLV of the size equal to the size of Location TLV in the received packet in the reflected packet. Mirsky, et al. Expires May 19, 2021 [Page 14] Internet-Draft STAMP Extensions November 2020 Based on the local policy, the Session-Reflector MAY leave some fields unreported by filling them with zeroes. An implementation of the stateful Session-Reflector MUST provide control for managing such policies. A Session-Sender MAY include the Source MAC Address sub-TLV in the Location TLV. If the Session-Reflector receives the Location TLV that includes the Source MAC Address sub-TLV, it MUST include the Source EUI-48 Address sub-TLV if the source MAC address of the received extended test packet is in EUI-48 format. And the Session- Reflector MUST copy the value of the source MAC address in the EUI-48 field. Otherwise, the Session-Reflector MUST use the Source EUI-64 Address sub-TLV and MUST copy the value of the Source MAC address from the received packet into the EUI-64 field. If the received extended STAMP test packet does not have the Source MAC address, the Session-Reflector MUST zero the EUI-64 field before transmitting the reflected packet. A Session-Sender MAY include the Destination IP Address sub-TLV in the Location TLV. If the Session-Reflector receives the Location TLV that includes the Destination IP Address sub-TLV, it MUST include the Destination IPv4 Address sub-TLV if the source IP address of the received extended test packet is of IPv4 address family. And the Session-Reflector MUST copy the value of the destination IP address in the IPv4 Address field. Otherwise, the Session-Reflector MUST use the Destination IPv6 Address sub-TLV and MUST copy the value of the destination IP address from the received packet into the IPv6 Address field. A Session-Sender MAY include the Source IP Address sub-TLV in the Location TLV. If the Session-Reflector receives the Location TLV that includes the Source IP Address sub-TLV, it MUST include the Source IPv4 Address sub-TLV if the source IP address of the received extended test packet is of IPv4 address family. And the Session- Reflector MUST copy the value of the source IP address in the IPv4 Address field. Otherwise, the Session-Reflector MUST use the Source IPv6 Address sub-TLV and MUST copy the value of the source IP address from the received packet into the IPv6 Address field. The Location TLV MAY be used to determine the last-hop IP addresses, ports, and last-hop MAC address for STAMP packets. The MAC address can indicate a path switch on the last hop. The IP addresses and UDP ports will indicate if there is a NAT router on the path. It allows the Session-Sender to identify the IP address of the Session- Reflector behind the NAT, and detect changes in the NAT mapping that could cause sending the STAMP packets to the wrong Session-Reflector. Mirsky, et al. Expires May 19, 2021 [Page 15] Internet-Draft STAMP Extensions November 2020 4.3. Timestamp Information TLV The STAMP Session-Sender MAY include the Timestamp Information TLV to request information from the Session-Reflector. The Session-Sender MUST NOT fill any information fields except for STAMP TLV Flags, Type, and Length. All other fields MUST be filled with zeroes. The Session-Reflector MUST validate the Length value of the TLV. If the value of the Length field is invalid, the Session-Reflector follows the procedure defined in Section 4 for a malformed TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags|Times Info Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sync. Src In | Timestamp In | Sync. Src Out | Timestamp Out | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Timestamp Information TLV where fields are defined as the following: o STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Figure 6. o Timestamp Information Type - is a one-octet-long field, value TBA3 allocated by IANA Section 5.1. o Length - two-octet-long field, set equal to the length of the Value field in octets (Figure 5). o Sync Src In - one-octet-long field that characterizes the source of clock synchronization at the ingress of a Session-Reflector. There are several methods to synchronize the clock, e.g., Network Time Protocol (NTP) [RFC5905]. The value is one of those listed in Table 7. o Timestamp In - one-octet-long field that characterizes the method by which the ingress of the Session-Reflector obtained the timestamp T2. A timestamp may be obtained with hardware assistance, via software API from a local wall clock, or from a remote clock (the latter is referred to as "control plane"). The value is one of those listed in Table 9. Mirsky, et al. Expires May 19, 2021 [Page 16] Internet-Draft STAMP Extensions November 2020 o Sync Src Out - one-octet-long field that characterizes the source of clock synchronization at the egress of the Session-Reflector. The value is one of those listed in Table 7. o Timestamp Out - one-octet-long field that characterizes the method by which the egress of the Session-Reflector obtained the timestamp T3. The value is one of those listed in Table 9. o Optional sub-TLVs - optional variable-length field. 4.4. Class of Service TLV The STAMP Session-Sender MAY include a Class of Service (CoS) TLV in the STAMP test packet. The format of the CoS TLV is presented in Figure 12. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| CoS Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP1 | DSCP2 |ECN| RP| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Class of Service TLV where fields are defined as the following: o STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Figure 6. o CoS (Class of Service) Type - is a one-octet-long field, value TBA4 allocated by IANA Section 5.1. o Length - two-octet-long field, set equal to the value 4. o DSCP1 - The Differentiated Services Code Point (DSCP) intended by the Session-Sender to be used as the DSCP value of the reflected test packet. o DSCP2 - The received value in the DSCP field at the ingress of the Session-Reflector. o ECN - The received value in the ECN field at the ingress of the Session-Reflector. o RP (Reverse Path) - is a two-bit-long field. A Session-Sender MUST set the value of the RP field to 0 on transmission. Mirsky, et al. Expires May 19, 2021 [Page 17] Internet-Draft STAMP Extensions November 2020 o Reserved - 16-bit-long field, MUST be zeroed on transmission and ignored on receipt. A STAMP Session-Reflector that receives a test packet with the CoS TLV MUST include the CoS TLV in the reflected test packet. Also, the Session-Reflector MUST copy the value of the DSCP and ECN fields of the IP header of the received STAMP test packet into the DSCP2 field in the reflected test packet. Finally, the Session-Reflector MUST use the local policy to verify whether the CoS corresponding to the value of the DSCP1 field is permitted in the domain. If it is, the Session-Reflectorset MUST set the DSCP field's value in the IP header of the reflected test packet equal to the value of the DSCP1 field of the received test packet. Otherwise, the Session-Reflector MUST use the DSCP value of the received STAMP packet and set the value of the RP field to 1. Upon receiving the reflected packet, if the value of the RP field is 0, the Session-Sender will save the DSCP and ECN values for analysis of the CoS in the reverse direction. If the value of the RP field in the received reflected packet is 1, only CoS in the forward direction can be analyzed. Re-mapping of CoS can be used to provide multiple services (e,g., 2G, 3G, LTE in mobile backhaul networks) over the same network. But if it is misconfigured, then it is often difficult to diagnose the root cause of excessive packet drops of higher-level service while packet drops for lower service packets are at a normal level. Using a CoS TLV in STAMP testing helps to troubleshoot the existing problem and also verify whether DiffServ policies are processing CoS as required by the configuration. 4.5. Direct Measurement TLV The Direct Measurement TLV enables collection of the number of in- profile packets, i.e., packets that form a specific data flow, that had been transmitted and received by the Session-Sender and Session- Reflector, respectively. The definition of "in-profile packet" is outside the scope of this document and is left to the test operators to determine. Mirsky, et al. Expires May 19, 2021 [Page 18] Internet-Draft STAMP Extensions November 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Direct Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Tx counter (S_TxC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Reflector Rx counter (R_RxC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Reflector Tx counter (R_TxC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Direct Measurement TLV where fields are defined as the following: o STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Figure 6. o Direct (Measurement) Type - is a one-octet-long field, value TBA5 allocated by IANA Section 5.1. o Length - two-octet-long field equals the length of the Value field in octets. The Length field value MUST equal 12 octets. o Session-Sender Tx counter (S_TxC) is a four-octet-long field. The Session-Sender MUST set its value equal to the number of the transmitted in-profile packets. o Session-Reflector Rx counter (R_RxC) is a four-octet-long field. MUST be zeroed by the Session-Sender on transmit and ignored by the Session-Reflector on receipt. The Session-Reflector MUST fill it with the value of in-profile packets received. o Session-Reflector Tx counter (R_TxC) is a four-octet-long field. MUST be zeroed by the Session-Sender and ignored by the Session- Reflector on receipt. The Session-Reflector MUST fill it with the value of the transmitted in-profile packets. A Session-Sender MAY include the Direct Measurement TLV in a STAMP test packet. If the received STAMP test packet includes the Direct Measurement TLV, the Session-Reflector MUST include it in the reflected test packet. The Session-Reflector MUST copy the value from the S_TxC field of the received test packet into the same field of the reflected packet before its transmission. Mirsky, et al. Expires May 19, 2021 [Page 19] Internet-Draft STAMP Extensions November 2020 4.6. Access Report TLV A STAMP Session-Sender MAY include an Access Report TLV (Figure 14) to indicate changes to the access network status to the Session- Reflector. The definition of an access network is outside the scope of this document. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags|Acc Report Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | Resv | Return Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Access Report TLV where fields are defined as follows: o STAMP TLV Flags - is an eight-bit-long field. Its format presented in Figure 6. o Access Report Type - is a one-octet-long field, value TBA6 allocated by IANA Section 5.1. o Length - two-octet-long field, set equal to the value 4. o ID (Access ID) - four-bit-long field that identifies the access network, e.g., 3GPP (Radio Access Technologies specified by 3GPP) or Non-3GPP (accesses that are not specified by 3GPP) [TS23501]. The value is one of those listed below: * 1 - 3GPP Network * 2 - Non-3GPP Network All other values are invalid and the TLV that contains it MUST be discarded. o Resv - four-bit-long field, MUST be zeroed on transmission and ignored on receipt. o Return Code - one-octet-long field that identifies the report signal, e.g., available or unavailable. The value is supplied to the STAMP end-point through some mechanism that is outside the scope of this document. The value is one of those listed in Section 5.6. Mirsky, et al. Expires May 19, 2021 [Page 20] Internet-Draft STAMP Extensions November 2020 o Reserved - two-octet-long field, MUST be zeroed on transmission and ignored on receipt. The STAMP Session-Sender that includes the Access Report TLV sets the value of the Access ID field according to the type of access network it reports on. Also, the Session-Sender sets the value of the Return Code field to reflect the operational state of the access network. The mechanism to determine the state of the access network is outside the scope of this specification. A STAMP Session-Reflector that received the test packet with the Access Report TLV MUST include the Access Report TLV in the reflected test packet. The Session- Reflector MUST set the value of the Access ID and Return Code fields equal to the values of the corresponding fields from the test packet it has received. The Session-Sender MUST also arm a retransmission timer after sending a test packet that includes the Access Report TLV. This timer MUST be disarmed upon reception of the reflected STAMP test packet that includes the Access Report TLV. In the event the timer expires before such a packet is received, the Session-Sender MUST retransmit the STAMP test packet that contains the Access Report TLV. This retransmission SHOULD be repeated up to four times before the procedure is aborted. Setting the value for the retransmission timer is based on local policies and network environment. The default value of the retransmission timer for the Access Report TLV SHOULD be three seconds. An implementation MUST provide control of the retransmission timer value and the number of retransmissions. The Access Report TLV is used by the Performance Measurement Function (PMF) components of the Access Steering, Switching and Splitting feature for 5G networks [TS23501]. The PMF component in the User Equipment acts as the STAMP Session-Sender, and the PMF component in the User Plane Function acts as the STAMP Session-Reflector. 4.7. Follow-up Telemetry TLV A Session-Reflector might be able to put in the Timestamp field only an "SW Local" (see Table 9) timestamp. But the hosting system might provide a timestamp closer to the start of the actual packet transmission even though it is not possible to deliver the information to the Session-Sender in time for the packet itself. This timestamp might nevertheless be important for the Session- Sender, as it improves the accuracy of measuring network delay by minimizing the impact of egress queuing delays on the measurement. A STAMP Session-Sender MAY include the Follow-up Telemetry TLV to request information from the Session-Reflector. The Session-Sender MUST set the Follow-up Telemetry Type and Length fields to their Mirsky, et al. Expires May 19, 2021 [Page 21] Internet-Draft STAMP Extensions November 2020 appropriate values. The Sequence Number and Timestamp fields MUST be zeroed on transmission by the Session-Sender and ignored by the Session-Reflector upon receipt of the STAMP test packet that includes the Follow-up Telemetry TLV. The Session-Reflector MUST validate the Length value of the STAMP test packet. If the value of the Length field is invalid, the Session-Reflector MUST zero the Sequence Number and Timestamp fields and set the M flag in the STAMP TLV Flags field in the reflected packet. If the Session-Reflector is in stateless mode (defined in Section 4.2 [RFC8762]), it MUST zero the Sequence Number and Timestamp fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Follow-up Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Follow-up Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp M | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Follow-up Telemetry TLV where fields are defined as follows: o STAMP TLV Flags - is an eight-bit-long field. Its format presented in Figure 6. o Follow-up (Telemetry) Type - is a one-octet-long field, value TBA7 allocated by IANA Section 5.1. o Length - two-octet-long field, set equal to the value 16 octets. o Sequence Number - four-octet-long field indicating the sequence number of the last packet reflected in the same STAMP-test session. Since the Session-Reflector runs in the stateful mode (defined in Section 4.2 [RFC8762]), it is the Session-Reflector's Sequence Number of the previous reflected packet. o Follow-up Timestamp - eight-octet-long field, with the format indicated by the Z flag of the Error Estimate field of the STAMP base packet, which is contained in this reflected test packet transmitted by a Session-Reflector, as described in Section 4.2.1 [RFC8762]. It carries the timestamp when the reflected packet with the specified sequence number was sent. Mirsky, et al. Expires May 19, 2021 [Page 22] Internet-Draft STAMP Extensions November 2020 o Timestamp M(ode) - one-octet-long field that characterizes the method by which the entity that transmits a reflected STAMP packet obtained the Follow-up Timestamp. The value is one of those listed in Table 9. o Reserved - three-octet-long field. Its value MUST be zeroed on transmission and ignored on receipt. 4.8. HMAC TLV The STAMP authenticated mode protects the integrity of data collected in the STAMP base packet. STAMP extensions are designed to provide valuable information about the condition of a network, and protecting the integrity of that data is also essential. All authenticated STAMP base packets (per Section 4.2.2 and Section 4.3.2 [RFC8762]) compatible with this specification MUST additionally authenticate the option TLVs by including the keyed Hashed Message Authentication Code (HMAC) TLV, with the sole exception of when there is only one TLV present, and it is the Extended Padding TLV. The HMAC TLV MUST follow all TLVs included in a STAMP test packet, except for the Extra Padding TLV. If the HMAC TLV appears in any other position in a STAMP extended test packet, then the situation MUST be processed as HMAC verification failure, as defined in this section, further below. The HMAC TLV MAY be used to protect the integrity of STAMP extensions in STAMP unauthenticated mode. An implementation of STAMP extensions MUST provide controls to enable the integrity protection of STAMP extensions in STAMP unauthenticated mode. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| HMAC Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: HMAC TLV where fields are defined as follows: o STAMP TLV Flags - is an eight-bit-long field. Its format is presented in Figure 6. o HMAC Type - is a one-octet-long field, value TBA8 allocated by IANA Section 5.1. Mirsky, et al. Expires May 19, 2021 [Page 23] Internet-Draft STAMP Extensions November 2020 o Length - two-octet-long field, set equal to 16 octets. o HMAC - is a 16-octet-long field that carries HMAC digest of the text of all preceding TLVs. As defined in [RFC8762], STAMP uses HMAC-SHA-256 truncated to 128 bits ([RFC4868]). All considerations regarding using the key listed in Section 4.4 of [RFC8762] are fully applicable to the use of the HMAC TLV. Key management and the mechanisms to distribute the HMAC key are outside the scope of this specification. HMAC TLV is anticipated to track updates in the base STAMP protocol [RFC8762], including the use of more advanced cryptographic algorithms. HMAC is calculated as defined in [RFC2104] over text as the concatenation of the Sequence Number field of the base STAMP packet and all preceding TLVs. The digest then MUST be truncated to 128 bits and written into the HMAC field. If the HMAC TLV is present in the extended STAMP test packet, e.g., in the authenticated mode, HMAC MUST be verified before using any data in the included STAMP TLVs. If HMAC verification by the Session-Reflector fails, then the Session- Reflector MUST stop processing the received extended STAMP test packet. The Session-Reflector MUST copy the TLVs from the received STAMP test packet into the reflected packet. The Session-Reflector MUST set the I flag in each TLV copied over into the reflected packet to 1 before transmitting the reflected test packet. If the Session- Sender receives the extended STAMP test packet with I flag set to 1, then the Session-Sender MUST stop processing TLVs in the reflected test packet. If HMAC verification by the Session-Sender fails, then the Session-Sender MUST stop processing TLVs in the reflected extended STAMP packet. 5. IANA Considerations 5.1. STAMP TLV Registry IANA is requested to create the STAMP TLV Type registry. All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. The remaining code points are allocated according to Table 1: Mirsky, et al. Expires May 19, 2021 [Page 24] Internet-Draft STAMP Extensions November 2020 +-----------+--------------+---------------+ | Value | Description | Reference | +-----------+--------------+---------------+ | 0 | Reserved | This document | | 1- 175 | Unassigned | This document | | 176 - 239 | Unassigned | This document | | 240 - 251 | Experimental | This document | | 252 - 254 | Private Use | This document | | 255 | Reserved | This document | +-----------+--------------+---------------+ Table 1: STAMP TLV Type Registry This document defines the following new values in the IETF Review range of the STAMP TLV Type registry: +-------+-----------------------+---------------+ | Value | Description | Reference | +-------+-----------------------+---------------+ | TBA1 | Extra Padding | This document | | TBA2 | Location | This document | | TBA3 | Timestamp Information | This document | | TBA4 | Class of Service | This document | | TBA5 | Direct Measurement | This document | | TBA6 | Access Report | This document | | TBA7 | Follow-up Telemetry | This document | | TBA8 | HMAC | This document | +-------+-----------------------+---------------+ Table 2: STAMP TLV Types 5.2. STAMP TLV Flags Sub-registry IANA is requested to create the STAMP TLV Flags sub-registry as part of the STAMP TLV Type registry. The registration procedure is "IETF Review" [RFC8126]. Flags are 8 bits. This document defines the following bit positions in the STAMP TLV Flags sub-registry: +--------------+--------+------------------------+---------------+ | Bit position | Symbol | Description | Reference | +--------------+--------+------------------------+---------------+ | 0 | U | Unrecognized TLV | This document | | 1 | M | Malformed TLV | This document | | 2 | I | Integrity check failed | This document | +--------------+--------+------------------------+---------------+ Table 3: STAMP TLV Flags Mirsky, et al. Expires May 19, 2021 [Page 25] Internet-Draft STAMP Extensions November 2020 5.3. Sub-TLV Type Sub-registry IANA is requested to create the sub-TLV Type sub-registry as part of the STAMP TLV Type registry. All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. The remaining code points are allocated according to Table 4: +-----------+--------------+---------------+ | Value | Description | Reference | +-----------+--------------+---------------+ | 0 | Reserved | This document | | 1- 175 | Unassigned | This document | | 176 - 239 | Unassigned | This document | | 240 - 251 | Experimental | This document | | 252 - 254 | Private Use | This document | | 255 | Reserved | This document | +-----------+--------------+---------------+ Table 4: Location Sub-TLV Type Sub-registry This document defines the following new values in the IETF Review range of the Location sub-TLV Type sub-registry: +-------+--------------------------+----------+---------------+ | Value | Description | TLV Used | Reference | +-------+--------------------------+----------+---------------+ | TBA9 | Source MAC Address | Location | This document | | TBA10 | Source EUI-48 Address | Location | This document | | TBA11 | Source EUI-64 Address | Location | This document | | TBA12 | Destination IP Address | Location | This document | | TBA13 | Destination IPv4 Address | Location | This document | | TBA14 | Destination IPv6 Address | Location | This document | | TBA15 | Source IP Address | Location | This document | | TBA16 | Source IPv4 Address | Location | This document | | TBA17 | Source IPv6 Address | Location | This document | +-------+--------------------------+----------+---------------+ Table 5: STAMP sub-TLV Types 5.4. Synchronization Source Sub-registry IANA is requested to create the Synchronization Source sub-registry as part of the STAMP TLV Type registry. All code points in the range 1 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in Mirsky, et al. Expires May 19, 2021 [Page 26] Internet-Draft STAMP Extensions November 2020 the range 128 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 6: +-----------+--------------+---------------+ | Value | Description | Reference | +-----------+--------------+---------------+ | 0 | Reserved | This document | | 1- 127 | Unassigned | This document | | 128 - 239 | Unassigned | This document | | 240 - 249 | Experimental | This document | | 250 - 254 | Private Use | This document | | 255 | Reserved | This document | +-----------+--------------+---------------+ Table 6: Synchronization Source Sub-registry This document defines the following new values in the Synchronization Source sub-registry: +-------+---------------------------------+---------------+ | Value | Description | Reference | +-------+---------------------------------+---------------+ | 1 | NTP | This document | | 2 | PTP | This document | | 3 | SSU/BITS | This document | | 4 | GPS/GLONASS/LORAN-C/BDS/Galileo | This document | | 5 | Local free-running | This document | +-------+---------------------------------+---------------+ Table 7: Synchronization Sources 5.5. Timestamping Method Sub-registry IANA is requested to create the Timestamping Method sub-registry as part of the STAMP TLV Type registry. All code points in the range 1 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 128 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 8: Mirsky, et al. Expires May 19, 2021 [Page 27] Internet-Draft STAMP Extensions November 2020 +-----------+--------------+---------------+ | Value | Description | Reference | +-----------+--------------+---------------+ | 0 | Reserved | This document | | 1- 127 | Unassigned | This document | | 128 - 239 | Unassigned | This document | | 240 - 249 | Experimental | This document | | 250 - 254 | Private Use | This document | | 255 | Reserved | This document | +-----------+--------------+---------------+ Table 8: Timestamping Method Sub-registry This document defines the following new values in the Timestamping Methods sub-registry: +-------+---------------+---------------+ | Value | Description | Reference | +-------+---------------+---------------+ | 1 | HW Assist | This document | | 2 | SW local | This document | | 3 | Control plane | This document | +-------+---------------+---------------+ Table 9: Timestamping Methods 5.6. Return Code Sub-registry IANA is requested to create the Return Code sub-registry as part of the STAMP TLV Type registry. All code points in the range 1 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 128 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 10: +-----------+--------------+---------------+ | Value | Description | Reference | +-----------+--------------+---------------+ | 0 | Reserved | This document | | 1- 127 | Unassigned | This document | | 128 - 239 | Unassigned | This document | | 240 - 249 | Experimental | This document | | 250 - 254 | Private Use | This document | | 255 | Reserved | This document | +-----------+--------------+---------------+ Table 10: Return Code Sub-registry Mirsky, et al. Expires May 19, 2021 [Page 28] Internet-Draft STAMP Extensions November 2020 This document defines the following new values in the Return Code sub-registry: +-------+---------------------+---------------+ | Value | Description | Reference | +-------+---------------------+---------------+ | 1 | Network available | This document | | 2 | Network unavailable | This document | +-------+---------------------+---------------+ Table 11: Return Codes 6. Security Considerations This document defines extensions to STAMP [RFC8762] and inherits all the security considerations applicable to the base protocol. Additionally, the HMAC TLV is defined in this document. Though the HMAC TLV protects the integrity of STAMP extensions; it does not protect against a replay attack. The use of HMAC TLV is discussed in detail in Section 4.8. To protect against a malformed TLV an implementation of a Session- Sender and Session-Reflector MUST: o check the setting of the M flag; o validate the Length field value. As this specification defined the mechanism to test DSCP mapping, this document inherits all the security considerations discussed in [RFC2474]. Monitoring and optional control of DSCP using the CoS TLV may be used across the Internet so that the Session-Sender and the Session-Reflector are located in domains that use different CoS profiles. Thus, it is essential that an operator verifies the set of CoS values that are used in the Session-Reflector's domain. Also, an implementation of a Session-Reflector SHOULD support a local policy to confirm whether the value sent by the Session-Sender can be used as the value of the DSCP field. Section 4.4 defines the use of that local policy. 7. Acknowledgments Authors much appreciate the thorough review and thoughtful comments received from Tianran Zhou, Rakesh Gandhi, Yuezhong Song and Yali Wang. The authors express their gratitude to Al Morton for his comments and the most valuable suggestions. The authors greatly appreciate comments and thoughtful suggestions received from Martin Duke. Mirsky, et al. Expires May 19, 2021 [Page 29] Internet-Draft STAMP Extensions November 2020 8. Contributors The following people contributed text to this document: Guo Jun ZTE Corporation 68# Zijinghua Road Nanjing, Jiangsu 210012 P.R.China Phone: +86 18105183663 Email: guo.jun2@zte.com.cn 9. References 9.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . 9.2. Informative References [GPS] "Global Positioning System (GPS) Standard Positioning Service (SPS) Performance Standard", GPS SPS 5th Edition, April 2020. Mirsky, et al. Expires May 19, 2021 [Page 30] Internet-Draft STAMP Extensions November 2020 [I-D.gont-numeric-ids-generation] Gont, F. and I. Arce, "On the Generation of Transient Numeric Identifiers", draft-gont-numeric-ids-generation-04 (work in progress), July 2019. [IEEE.1588.2008] "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, March 2008. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [TS23501] 3GPP (3rd Generation Partnership Project), "Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", 3GPP TS23501, 2019. Authors' Addresses Greg Mirsky ZTE Corp. Email: gregimirsky@gmail.com Xiao Min ZTE Corp. Email: xiao.min2@zte.com.cn Mirsky, et al. Expires May 19, 2021 [Page 31] Internet-Draft STAMP Extensions November 2020 Henrik Nydell Accedian Networks Email: hnydell@accedian.com Richard Foote Nokia Email: footer.foote@nokia.com Adi Masputra Apple Inc. One Apple Park Way Cupertino, CA 95014 USA Email: adi@apple.com Ernesto Ruffini OutSys via Caracciolo, 65 Milano 20155 Italy Email: eruffini@outsys.org Mirsky, et al. Expires May 19, 2021 [Page 32] ./draft-ietf-lisp-gpe-19.txt0000644000764400076440000010655613707460056015127 0ustar iustyiusty Internet Engineering Task Force F. Maino, Ed. Internet-Draft Cisco Intended status: Standards Track J. Lemon Expires: January 27, 2021 Broadcom P. Agarwal Innovium D. Lewis M. Smith Cisco July 26, 2020 LISP Generic Protocol Extension draft-ietf-lisp-gpe-19 Abstract This document describes extensions to the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-protocol encapsulation and allow to introduce new protocol capabilities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 27, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Maino, et al. Expires January 27, 2021 [Page 1] Internet-Draft LISP Generic Protocol Extension July 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 4. Implementation and Deployment Considerations . . . . . . . . 6 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6 4.2. Congestion Control Functionality . . . . . . . . . . . . 7 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It specifies an encapsulation format that carries IPv4 or IPv6 packets (henceforth jointly referred to as IP) in a LISP header and outer UDP/IP transport. The LISP Data-Plane header does not specify the protocol being encapsulated and therefore is currently limited to encapsulating only IP packet payloads. Other protocols, most notably Virtual eXtensible Local Area Network (VXLAN) [RFC7348] (which defines a similar header format to LISP), are used to encapsulate Layer-2 (L2) protocols such as Ethernet. This document defines an extension for the LISP header, as defined in [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling the encapsulation of Ethernet, IP or any other desired protocol all the while ensuring compatibility with existing LISP deployments. Maino, et al. Expires January 27, 2021 [Page 2] Internet-Draft LISP Generic Protocol Extension July 2020 A flag in the LISP header, called the P-bit, is used to signal the presence of the 8-bit Next Protocol field. The Next Protocol field, when present, uses 8 bits of the field that was allocated to the echo-noncing and map-versioning features in [I-D.ietf-lisp-rfc6830bis]. Those two features are no longer available when the P-bit is used. However, appropriate LISP-GPE (LISP Generic Protocol Extension) shim headers can be defined to specify capabilities that are equivalent to echo-noncing and/or map- versioning. Since all of the reserved bits of the LISP Data-Plane header have been allocated, LISP-GPE can also be used to extend the LISP Data- Plane header by defining Next Protocol "shim" headers that implements new data plane functions not supported in the LISP header. For example, the use of the Group-Based Policy (GBP) header [I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations, Administration, and Maintenance (IOAM) header [I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered an extension to add support in the Data-Plane for Group-Based Policy functionalities or IOAM metadata. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Definition of Terms This document uses terms already defined in [I-D.ietf-lisp-rfc6830bis]. 2. LISP Header Without Protocol Extensions As described in Section 1, the LISP header has no protocol identifier that indicates the type of payload being carried. Because of this, LISP is limited to carrying IP payloads. The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags (some defined, some reserved), a Nonce/Map-version field and an instance ID/Locator-status-bit field. The flags provide flexibility to define how the various fields are encoded. Notably, Flag bit 5 is the last reserved bit in the LISP header. Maino, et al. Expires January 27, 2021 [Page 3] Internet-Draft LISP Generic Protocol Extension July 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Nonce/Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LISP Header 3. Generic Protocol Extension for LISP (LISP-GPE) This document defines two changes to the LISP header in order to support multi-protocol encapsulation: the introduction of the P-bit and the definition of a Next Protocol field. This document specifies the protocol behavior when the P-bit is set to 1, no changes are introduced when the P-bit is set to 0. The LISP-GPE header is shown in Figure 2 and described below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: LISP-GPE Header P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is set to 1 to indicate the presence of the 8 bit Next Protocol field. If the P-bit is clear (0) the LISP header is bit-by-bit equivalent to the definition in [I-D.ietf-lisp-rfc6830bis]. When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the 'Nonce/Map-Version/Next Protocol' field MUST be set to zero on transmission and MUST be ignored on receipt. Features equivalent to those that were implemented with bits N,E and V in [I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map- versioning, can be implemented by defining appropriate LISP-GPE shim headers. When the P-bit is set to 1, the LISP-GPE header is encoded as: Maino, et al. Expires January 27, 2021 [Page 4] Internet-Draft LISP Generic Protocol Extension July 2020 0 x 0 0 x 1 x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|P|K|K| 0x0000 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: LISP-GPE with P-bit set to 1 Next Protocol: When the P-bit is set to 1, the lower 8 bits of the first 32-bit word are used to carry a Next Protocol. This Next Protocol field contains the protocol of the encapsulated payload packet. This document defines the following Next Protocol values: 0x00 : Reserved 0x01 : IPv4 0x02 : IPv6 0x03 : Ethernet 0x04 : Network Service Header (NSH) [RFC8300] 0x05 to 0x7D: Unassigned 0x7E, 0x7F: Experimentation and testing 0x80 to 0xFD: Unassigned (shim headers) 0xFE, 0xFF: Experimentation and testing (shim headers) The values are tracked in the IANA LISP-GPE Next Protocol Registry as described in Section 6.1. Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for experimentation and testing as per [RFC3692]. Next protocol values from Ox80 to 0xFD are assigned to protocols encoded as generic "shim" headers. All shim protocols MUST use the header structure in Figure 4, which includes a Next Protocol field. When shim headers are used with other protocols identified by next Maino, et al. Expires January 27, 2021 [Page 5] Internet-Draft LISP Generic Protocol Extension July 2020 protocol values from 0x00 to 0x7F, all the shim headers MUST come first. Shim headers can be used to incrementally deploy new GPE features, keeping the processing of shim headers known to a given xTR implementation in the 'fast' path (typically an ASIC), while punting the processing of the remaining new GPE features to the 'slow' path. Shim protocols MUST have the first 32 bits defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Protocol Specific Fields ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Shim Header Where: Type: This field identifies the different messages of this protocol. Length: The length, in 4-octet units, of this protocol message not including the first 4 octets. Reserved: The use of this field is reserved to the protocol defined in this message. Next Protocol Field: The next protocol field contains the protocol of the encapsulated payload. The values are tracked in the IANA LISP-GPE Next Protocol Registry as described in Section 6.1. 4. Implementation and Deployment Considerations 4.1. Applicability Statement LISP-GPE conforms, as an UDP-based encapsulation protocol, to the UDP usage guidelines as specified in [RFC8085]. The applicability of these guidelines are dependent on the underlay IP network and the nature of the encapsulated payload. [RFC8085] outlines two applicability scenarios for UDP applications, 1) general Internet and 2) controlled environment. The controlled environment means a single administrative domain or adjacent set of Maino, et al. Expires January 27, 2021 [Page 6] Internet-Draft LISP Generic Protocol Extension July 2020 cooperating domains. A network in a controlled environment can be managed to operate under certain conditions whereas in general Internet this cannot be done. Hence requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements of general internet. LISP-GPE scope of applicability is the same set of use cases covered by[I-D.ietf-lisp-rfc6830bis] for the LISP dataplane protocol. The common property of these use cases is a large set of cooperating entities seeking to communicate over the public Internet or other large underlay IP infrastructures, while keeping the addressing and topology of the cooperating entities separate from the underlay and Internet topology, routing, and addressing. LISP-GPE is meant to be deployed in network environments operated by a single operator or adjacent set of cooperating network operators that fits with the definition of controlled environments in [RFC8085]. For the purpose of this document, a traffic-managed controlled environment (TMCE), outlined in [RFC8086], is defined as an IP network that is traffic-engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion. Significant portions of text in this Section are based on [RFC8086]. It is the responsibility of the network operators to ensure that the guidelines/requirements in this section are followed as applicable to their LISP-GPE deployments 4.2. Congestion Control Functionality LISP-GPE does not natively provide congestion control functionality and relies on the payload protocol traffic for congestion control. As such LISP-GPE MUST be used with congestion controlled traffic or within a network that is traffic managed to avoid congestion (TMCE). An operator of a traffic managed network (TMCE) may avoid congestion by careful provisioning of their networks, rate-limiting of user data traffic and traffic engineering according to path capacity. Keeping in mind the reccomendation above, new encapsulated payloads, when registered with LISP-GPE, MUST be accompained by a set of guidelines derived from [I-D.ietf-lisp-rfc6830bis]. Such new protocols should be designed for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). By following the guidelines in [I-D.ietf-tsvwg-ecn-encap-guidelines], subnetwork designers can Maino, et al. Expires January 27, 2021 [Page 7] Internet-Draft LISP Generic Protocol Extension July 2020 enable a layer-2 protocol to participate in congestion control without dropping packets via propagation of explicit congestion notification (ECN [RFC3168] ) to receivers. 4.3. UDP Checksum For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies how to handle UDP Checksums encouraging implementors to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when it is desirable to protect UDP and LISP headers against corruption. In order to provide integrity of LISP-GPE headers, options and payload, for example to avoid mis-delivery of payload to different tenant systems in case of data corruption, outer UDP checksum SHOULD be used with LISP-GPE when transported over IPv4. The UDP checksum provides a statistical guarantee that a payload was not corrupted in transit. These integrity checks are not strong from a coding or cryptographic perspective and are not designed to detect physical- layer errors or malicious modification of the datagram (see Section 3.4 of [RFC8085]). In deployments where such a risk exists, an operator SHOULD use additional data integrity mechanisms such as offered by IPSec. An operator MAY choose to disable UDP checksum and use zero checksum if LISP-GPE packet integrity is provided by other data integrity mechanisms such as IPsec or additional checksums or if one of the conditions in Section 4.3.1 a, b, c are met. 4.3.1. UDP Zero Checksum Handling with IPv6 By default, UDP checksum MUST be used when LISP-GPE is transported over IPv6. A tunnel endpoint MAY be configured for use with zero UDP checksum if additional requirements described in this section are met. When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 headers, UDP headers and LISP-GPE headers and payload from potential data corruption. As such by default LISP-GPE MUST use UDP checksum when transported over IPv6. An operator MAY choose to configure to operate with zero UDP checksum if operating in a traffic managed controlled environment as stated in Section 4.1 if one of the following conditions are met: a. It is known that the packet corruption is exceptionally unlikely (perhaps based on knowledge of equipment types in their underlay network) and the operator is willing to take a risk of undetected packet corruption Maino, et al. Expires January 27, 2021 [Page 8] Internet-Draft LISP Generic Protocol Extension July 2020 b. It is judged through observational measurements (perhaps through historic or current traffic flows that use non zero checksum) that the level of packet corruption is tolerably low and where the operator is willing to take the risk of undetected corruption c. LISP-GPE payload is carrying applications that are tolerant of misdelivered or corrupted packets (perhaps through higher layer checksum validation and/or reliability through retransmission) In addition LISP-GPE tunnel implementations using Zero UDP checksum MUST meet the following requirements: 1. Use of UDP checksum over IPv6 MUST be the default configuration for all LISP-GPE tunnels 2. If LISP-GPE is used with zero UDP checksum over IPv6 then such xTR implementation MUST meet all the requirements specified in section 4 of [RFC6936] and requirements 1 as specified in section 5 of [RFC6936] 3. The ETR that decapsulates the packet SHOULD check the source and destination IPv6 addresses are valid for the LISP-GPE tunnel that is configured to receive Zero UDP checksum and discard other packets for which such check fails 4. The ITR that encapsulates the packet MAY use different IPv6 source addresses for each LISP-GPE tunnel that uses Zero UDP checksum mode in order to strengthen the decapsulator's check of the IPv6 source address (i.e the same IPv6 source address is not to be used with more than one IPv6 destination address, irrespective of whether that destination address is a unicast or multicast address). When this is not possible, it is RECOMMENDED to use each source address for as few LISP-GPE tunnels that use zero UDP checksum as is feasible 5. Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 with zero UDP checksum from escaping into the general Internet. Examples of such measures include employing packet filters at the PETR and/or keeping logical or physical separation of LISP network from networks carrying General Internet The above requirements do not change either the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC6936]. The requirement to check the source IPv6 address in addition to the destination IPv6 address, plus the recommendation against reuse of source IPv6 addresses among LISP-GPE tunnels collectively provide Maino, et al. Expires January 27, 2021 [Page 9] Internet-Draft LISP Generic Protocol Extension July 2020 some mitigation for the absence of UDP checksum coverage of the IPv6 header. A traffic-managed controlled environment that satisfies at least one of three conditions listed at the beginning of this section provides additional assurance. 4.4. DSCP, ECN, TTL, and 802.1Q When encapsulating IP (including over Ethernet) packets [RFC2983] provides guidance for mapping DSCP between inner and outer IP headers. The Pipe model typically fits better Network virtualization. The DSCP value on the tunnel header is set based on a policy (which may be a fixed value, one based on the inner traffic class, or some other mechanism for grouping traffic). Some aspects of the Uniform model (which treats the inner and outer DSCP value as a single field by copying on ingress and egress) may also apply, such as the ability to remark the inner header on tunnel egress based on transit marking. However, the Uniform model is not conceptually consistent with network virtualization, which seeks to provide strong isolation between encapsulated traffic and the physical network. [RFC6040] describes the mechanism for exposing ECN capabilities on IP tunnels and propagating congestion markers to the inner packets. This behavior MUST be followed for IP packets encapsulated in LISP- GPE. Though Uniform or Pipe models could be used for TTL (or Hop Limit in case of IPv6) handling when tunneling IP packets, Pipe model is more aligned with network virtualization. [RFC2003] provides guidance on handling TTL between inner IP header and outer IP tunnels; this model is more aligned with the Pipe model and is recommended for use with LISP-GPE for network virtualization applications. When a LISP-GPE router performs Ethernet encapsulation, the inner 802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY be mapped from the encapsulated frame to the DSCP codepoint of the DS field defined in [RFC2474]. When a LISP-GPE router performs Ethernet encapsulation, the inner header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped to, or used to determine the LISP Instance IDentifier (IID) field. Refer to Section 7 for consideration about the use of integrity protection for deployments, such as the public Internet, concerned with on-path attackers. Maino, et al. Expires January 27, 2021 [Page 10] Internet-Draft LISP Generic Protocol Extension July 2020 5. Backward Compatibility LISP-GPE uses the same UDP destination port (4341) allocated to LISP. When encapsulating IP packets to a non LISP-GPE capable router the P-bit MUST be set to 0. That is, the encapsulation format defined in this document MUST NOT be sent to a router that has not indicated that it supports this specification because such a router would ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so would misinterpret the other LISP header fields possibly causing significant errors. 5.1. Detection of ETR Capabilities The discovery of xTR capabilities to support LISP-GPE is out of the scope of this document. Given that the applicability domain of LISP- GPE is a traffic-managed controlled environment, ITR/ETR (xTR) configuration mechanisms may be used for this purpose. 6. IANA Considerations 6.1. LISP-GPE Next Protocol Registry IANA is requested to set up a registry of LISP-GPE "Next Protocol". These are 8-bit values. Next Protocol values in the table below are defined in this document. New values are assigned under the Specification Required policy [RFC8126]. The protocols that are being assigned values do not themselves need to be IETF standards track protocols. Maino, et al. Expires January 27, 2021 [Page 11] Internet-Draft LISP Generic Protocol Extension July 2020 +--------------+-------------------------------------+--------------+ | Next | Description | Reference | | Protocol | | | +--------------+-------------------------------------+--------------+ | 0x0 | Reserved | This | | | | Document | | 0x1 | IPv4 | This | | | | Document | | 0x2 | IPv6 | This | | | | Document | | 0x3 | Ethernet | This | | | | Document | | 0x4 | NSH | This | | | | Document | | 0x05..0x7D | Unassigned | | | 0x7E..0x7F | Experimentation and testing | This | | | | Document | | 0x80..0xFD | Unassigned (shim headers) | | | 0x8E..0x8F | Experimentation and testing (shim | This | | | headers) | Document | +--------------+-------------------------------------+--------------+ 7. Security Considerations LISP-GPE security considerations are similar to the LISP security considerations and mitigation techniques documented in [RFC7835]. LISP-GPE, as many encapsulations that use optional extensions, is subject to on-path adversaries that can make arbitrary modifications to the packet (including the P-Bit) to change or remove any part of the payload, or claim to encapsulate any protocol payload type. Typical integrity protection mechanisms (such as IPsec) SHOULD be used in combination with LISP-GPE by those protocol extensions that want to protect from on-path attackers. With LISP-GPE, issues such as data-plane spoofing, flooding, and traffic redirection may depend on the particular protocol payload encapsulated. 8. Acknowledgements and Contributors A special thank you goes to Dino Farinacci for his guidance and detailed review. Thanks to Tom Herbert for the suggestion to assign codepoints for experimentations and testing. This Working Group (WG) document originated as draft-lewis-lisp-gpe; the following are its coauthors and contributors along with their respective affiliations at the time of WG adoption. The editor of Maino, et al. Expires January 27, 2021 [Page 12] Internet-Draft LISP Generic Protocol Extension July 2020 this document would like to thank and recognize them and their contributions. These coauthors and contributors provided invaluable concepts and content for this document's creation. o Darrel Lewis, Cisco Systems, Inc. o Fabio Maino, Cisco Systems, Inc. o Paul Quinn, Cisco Systems, Inc. o Michael Smith, Cisco Systems, Inc. o Navindra Yadav, Cisco Systems, Inc. o Larry Kreeger o Jennifer Lemon, Broadcom o Puneet Agarwal, Innovium 9. References 9.1. Normative References [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress), March 2020. [IEEE.802.1Q_2014] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, December 2014, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . Maino, et al. Expires January 27, 2021 [Page 13] Internet-Draft LISP Generic Protocol Extension July 2020 9.2. Informative References [I-D.brockners-ippm-ioam-vxlan-gpe] Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE Encapsulation for In-situ OAM Data", draft-brockners-ippm- ioam-vxlan-gpe-03 (work in progress), November 2019. [I-D.ietf-tsvwg-ecn-encap-guidelines] Briscoe, B., Kaippallimalil, J., and P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- encap-guidelines-13 (work in progress), May 2019. [I-D.lemon-vxlan-lisp-gpe-gbp] Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 10.17487/RFC2003, October 1996, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . Maino, et al. Expires January 27, 2021 [Page 14] Internet-Draft LISP Generic Protocol Extension July 2020 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . Maino, et al. Expires January 27, 2021 [Page 15] Internet-Draft LISP Generic Protocol Extension July 2020 Authors' Addresses Fabio Maino (editor) Cisco Systems San Jose, CA 95134 USA Email: fmaino@cisco.com Jennifer Lemon Broadcom 270 Innovation Drive San Jose, CA 95134 USA Email: jennifer.lemon@broadcom.com Puneet Agarwal Innovium USA Email: puneet@acm.org Darrel Lewis Cisco Systems San Jose, CA 95134 USA Email: darlewis@cisco.com Michael Smith Cisco Systems San Jose, CA 95134 USA Email: michsmit@cisco.com Maino, et al. Expires January 27, 2021 [Page 16] ./draft-ietf-lisp-introduction-13.txt0000644000764400076440000020266012507232506017052 0ustar iustyiusty Network Working Group A. Cabellos Internet-Draft UPC-BarcelonaTech Intended status: Informational D. Saucez (Ed.) Expires: October 4, 2015 INRIA April 02, 2015 An Architectural Introduction to the Locator/ID Separation Protocol (LISP) draft-ietf-lisp-introduction-13.txt Abstract This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 4, 2015. Copyright Notice Copyright (c) 2015 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 Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 1] Internet-Draft LISP Introduction April 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 3.2. Overview of the Architecture . . . . . . . . . . . . . . 5 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. A Brief History of Location/Identity Separation . . 25 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction This document introduces the Locator/ID Separation Protocol (LISP) [RFC6830] architecture, its main operational mechanisms and its design rationale. Fundamentally, LISP is built following a well- known architectural idea: decoupling the IP address overloaded semantics. Indeed and as pointed out by Noel Chiappa [RFC4984], Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 2] Internet-Draft LISP Introduction April 2015 currently IP addresses both identify the topological location of a network attachment point as well as the node's identity. However, nodes and routing have fundamentally different requirements, routing systems require that addresses are aggregatable and have topological meaning, while nodes require to be identified independently of their current location [RFC4984]. LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are syntactically identical to the current IPv4 and IPv6 addresses. EIDs are used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. RLOCs are assigned topologically to network attachment points and are typically routed inter-domain. With LISP, the edge of the Internet (where the nodes are connected) and the core (where inter-domain routing occurs) can be logically separated and interconnected by LISP-capable routers. LISP also introduces a database, called the Mapping System, to store and retrieve mappings between identity and location. LISP-capable routers exchange packets over the Internet core by encapsulating them to the appropriate location. In summary: o RLOCs have meaning only in the underlay network, that is the underlying core routing system. o EIDs have meaning only in the overlay network, which is the encapsulation relationship between LISP-capable routers. o The LISP edge maps EIDs to RLOCs o Within the underlay network, RLOCs have both locator and identifier semantics o An EID within a LISP site carries both identifier and locator semantics to other nodes within that site o An EID within a LISP site carries identifier and limited locator semantics to nodes at other LISP sites (i.e., enough locator information to tell that the EID is external to the site) The relationship described above is not unique to LISP but it is common to other overlay technologies. The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP were to be completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System. In Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 3] Internet-Draft LISP Introduction April 2015 such scenario RLOCs are quasi-static (i.e., low churn), hence making the routing system scalable [Quoitin], while EIDs can roam anywhere with no churn to the underlying routing system. [RFC7215] discusses the impact of LISP on the global routing system during the transition period. However, the separation between location and identity that LISP offers makes it suitable for use in additional scenarios such as Traffic Engineering (TE), multihoming, and mobility among others. This document describes the LISP architecture and its main operational mechanisms as well as its design rationale. It is important to note that this document does not specify or complement the LISP protocol. The interested reader should refer to the main LISP specifications [RFC6830] and the complementary documents [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the protocol specifications along with the LISP deployment guidelines [RFC7215]. 2. Definition of Terms Endpoint IDentifier (EID): EIDs are addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. Routing LOcator (RLOC): RLOCs are addresses assigned topologically to network attachment points and typically routed inter-domain. Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates packets from a LISP site towards the core network. Egress Tunnel Router (ETR): A LISP-capable router that decapsulates packets from the core of the network towards a LISP site. xTR: A router that implements both ITR and ETR functionalities. Map-Request: A LISP signaling message used to request an EID-to-RLOC mapping. Map-Reply: A LISP signaling message sent in response to a Map- Request that contains a resolved EID-to-RLOC mapping. Map-Register: A LISP signaling message used to register an EID-to- RLOC mapping. Map-Notify: A LISP signaling message sent in response of a Map- Register to acknowledge the correct reception of an EID-to-RLOC mapping. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 4] Internet-Draft LISP Introduction April 2015 This document describes the LISP architecture and does not introduce any new term. The reader is referred to [RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052], [RFC7215] for the complete definition of terms. 3. LISP Architecture This section presents the LISP architecture, it first details the design principles of LISP and then it proceeds to describe its main aspects: data-plane, control-plane, and internetworking mechanisms. 3.1. Design Principles The LISP architecture is built on top of four basic design principles: o Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale. Devices are assigned with relatively opaque topologically meaningful addresses that are independent of their topological location. o Overlay architecture: Overlays route packets over the current Internet, allowing deployment of new protocols without changing the current infrastructure hence, resulting into a low deployment cost. o Decoupled data and control-plane: Separating the data-plane from the control-plane allows them to scale independently and use different architectural approaches. This is important given that they typically have different requirements and allows for other data-planes to be added. While decoupled, data and control-plane are not completely isolated because the LISP data-plane may trigger control-plane activity. o Incremental deployability: This principle ensures that the protocol interoperates with the legacy Internet while providing some of the targeted benefits to early adopters. 3.2. Overview of the Architecture LISP splits architecturally the core from the edge of the Internet by creating two separate namespaces: Endpoint Identifiers (EIDs) and Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6 addresses that uniquely identify communication end-hosts and are assigned and configured by the same mechanisms that exist at the time Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 5] Internet-Draft LISP Introduction April 2015 of this writing. EIDs do not contain inter-domain topological information and because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 for discussion of LISP site internetworking with non-LISP sites and domains in the Internet. LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the core of the Internet using tunnels between the LISP-capable routers. When packets originated from a LISP site are flowing towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When packets flow from the core network to a LISP site, they egress from an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a router which can perform both ITR and ETR operations. In this context ITRs encapsulate packets while ETRs decapsulate them, hence LISP operates as an overlay on top of the current Internet core. /-----------------\ --- | Mapping | | . System | | Control -| |`, | Plane ,' \-----------------/ . | / | --- ,.., - _,....,, | ,.., | / ` ,' ,-` `', | / ` | / \ +-----+ ,' `, +-----+ / \ | | EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data | Space |-| |--| Space |--| |-| Space | | Plane \ / +-----+ . / +-----+ \ / | `. .' `. ,' `. .' | `'-` `., ,.' `'-` --- ``'''`` LISP Site (Edge) Core LISP Site (Edge) Figure 1.- A schema of the LISP Architecture With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6 address assigned to an Internet-facing network interface of an ITR or ETR. Typically RLOCs are numbered from topologically aggregatable blocks assigned to a site at each point to which it attaches to the global Internet, the topology is defined by the connectivity of networks. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 6] Internet-Draft LISP Introduction April 2015 A database which is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. Such mappings relate the identity of the devices attached to LISP sites (EIDs) to the set of RLOCs configured at the LISP-capable routers servicing the site. Furthermore, the mappings also include traffic engineering policies and can be configured to achieve multihoming and load balancing. The LISP Mapping System is conceptually similar to the DNS where it is organized as a distributed multi-organization network database. With LISP, ETRs register mappings while ITRs retrieve them. Finally, the LISP architecture emphasizes incremental deployment. Given that LISP represents an overlay to the current Internet architecture, endhosts as well as intra and inter-domain routers remain unchanged, and the only required changes to the existing infrastructure are to routers connecting the EID with the RLOC space. Additionally, LISP requires the deployment of an independent Mapping System, such distributed database is a new network entity. The following describes a simplified packet flow sequence between two nodes that are attached to LISP sites. Please note that typical LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants to send a packet to server HostB. /----------------\ | Mapping | | System | .| |- ` \----------------/ `. ,` \ / `. ,' _,..-..,, ', / -` `-, \ .' ,' \ `, ` ' \ ' +-----+ | | RLOC_B1+-----+ HostA | | | RLOC |-------| | HostB EID_A--|ITR_A|----| Space | |ETR_B|--EID_B | | RLOC_A1 |-------| | +-----+ | | RLOC_B2+-----+ , / \ / `', ,-` ``''-''`` Figure 2.- Packet flow sequence in LISP Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 7] Internet-Draft LISP Introduction April 2015 1. HostA retrieves the EID_B of HostB, typically querying the DNS and obtaining an A or AAAA record. Then it generates an IP packet as in the Internet, the packet has source address EID_A and destination address EID_B. 2. The packet is routed towards ITR_A in the LISP site using standard intra-domain mechanisms. 3. ITR_A upon receiving the packet queries the Mapping System to retrieve the locator of ETR_B that is servicing HostB's EID_B. In order to do so it uses a LISP control message called Map- Request, the message contains EID_B as the lookup key. In turn it receives another LISP control message called Map-Reply, the message contains two locators: RLOC_B1 and RLOC_B2 along with traffic engineering policies: priority and weight per locator. Note that a Map-Reply can contain more locators if needed. ITR_A also stores the mapping in a local cache to speed-up forwarding of subsequent packets. 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according to the priorities/weights specified in the mapping). The packet contains two IP headers, the outer header has RLOC_A1 as source and RLOC_B1 as destination, the inner original header has EID_A as source and EID_B as destination. Furthermore ITR_A adds a LISP header, more details about LISP encapsulation can be found in Section 3.3.1. 5. The encapsulated packet is forwarded by the Internet core as a normal IP packet, making the EID invisible from the Internet core. 6. Upon reception of the encapsulated packet by ETR_B, it decapsulates the packet and forwards it to HostB. 3.3. Data-Plane This section provides a high-level description of the LISP data- plane, which is specified in detail in [RFC6830]. The LISP data- plane is responsible for encapsulating and decapsulating data packets and caching the appropriate forwarding state. It includes two main entities, the ITR and the ETR, both are LISP capable routers that connect the EID with the RLOC space (ITR) and vice versa (ETR). 3.3.1. LISP Encapsulation ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 8] Internet-Draft LISP Introduction April 2015 be consistent in case of multi-path solutions such as ECMP [RFC2992]) and ignored on reception. LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that is not verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. By omitting the additional outer UDP encapsulation checksum, xTRs can forward packets more efficiently. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing. LISP-encapsulated packets also include a LISP header (after the UDP header and before the original IP header). The LISP header is prepended by ITRs and striped by ETRs. It carries reachability information (see more details in Section 4.2) and the Instance ID field. The Instance ID field is used to distinguish traffic to/from different tenant address spaces at the LISP site and that may use overlapped but logically separated EID addressing. Overall, LISP works on 4 headers, the inner header the source constructed, and the 3 headers a LISP encapsulator prepends ("outer" to "inner"): 1. Outer IP header containing RLOCs as source and destination addresses. This header is originated by ITRs and stripped by ETRs. 2. UDP header (port 4341) with zero checksum. This header is originated by ITRs and stripped by ETRs. 3. LISP header that contains various forwarding-plane features (such as reachability) and an Instance ID field. This header is originated by ITRs and stripped by ETRs. 4. Inner IP header containing EIDs as source and destination addresses. This header is created by the source end-host and is left unchanged by LISP data plane processing on the ITR and ETR. Finally, in some scenarios Re-encapsulating and/or Recursive tunnels are useful to choose a specified path in the underlay network, for instance to avoid congestion or failure. Re-encapsulating tunnels are consecutive LISP tunnels and occur when a decapsulator (an ETR action) removes a LISP header and then acts as an encapsultor (an ITR action) to prepend another one. On the other hand, Recursive tunnels are nested tunnels and are implemented by using multiple LISP encapsulations on a packet. Such functions are implemented by Reencapsulating Tunnel Routers (RTRs). An RTR can be thought of as a router that first acts as an ETR by decapsulating packets and then as Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 9] Internet-Draft LISP Introduction April 2015 an ITR by encapsulating them towards another locator, more information can be found at [RFC6830]. 3.3.2. LISP Forwarding State In the LISP architecture, ITRs keep just enough information to route traffic flowing through them. Meaning that, ITRs retrieve from the LISP Mapping System mappings between EID-prefixes (blocks of EIDs) and RLOCs that are used to encapsulate packets. Such mappings are stored in a local cache called the Map-Cache for subsequent packets addressed to the same EID prefix. Note that, in case of overlapping EID-prefixes, following a single request, the ITR may receive a set of mappings, covering the requested EID-prefix and all more-specifics (cf., Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) TTL (set by the ETR). More details about the Map-Cache management can be found in Section 4.1. 3.4. Control-Plane The LISP control-plane, specified in [RFC6833], provides a standard interface to register and request mappings. The LISP Mapping System is a database that stores such mappings. The following first describes the mappings, then the standard interface to the Mapping System, and finally its architecture. 3.4.1. LISP Mappings Each mapping includes the bindings between EID prefix(es) and set of RLOCs as well as traffic engineering policies, in the form of priorities and weights for the RLOCs. Priorities allow the ETR to configure active/backup policies while weights are used to load- balance traffic among the RLOCs (on a per-flow basis). Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC3232]. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. With such a general syntax for address encoding in place, LISP aims to provide flexibility to current and future applications. For instance LCAFs could support MAC addresses, geo-coordinates, ASCII names and application specific data. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 10] Internet-Draft LISP Introduction April 2015 3.4.2. Mapping System Interface LISP defines a standard interface between data and control planes. The interface is specified in [RFC6833] and defines two entities: Map-Server: A network infrastructure component that learns mappings from ETRs and publishes them into the LISP Mapping System. Typically Map-Servers are not authoritative to reply to queries and hence, they forward them to the ETR. However they can also operate in proxy-mode, where the ETRs delegate replying to queries to Map-Servers. This setup is useful when the ETR has limited resources (i.e., CPU or power). Map-Resolver: A network infrastructure component that interfaces ITRs with the Mapping System by proxying queries and in some cases responses. The interface defines four LISP control messages which are sent as UDP datagrams (port 4342): Map-Register: This message is used by ETRs to register mappings in the Mapping System and it is authenticated using a shared key between the ETR and the Map-Server. Map-Notify: When requested by the ETR, this message is sent by the Map-Server in response to a Map-Register to acknowledge the correct reception of the mapping and convey the latest Map-Server state on the EID to RLOC mapping. In some cases a Map-Notify can be sent to the previous RLOCs when an EID is registered by a new set of RLOCs. Map-Request: This message is used by ITRs or Map-Resolvers to resolve the mapping of a given EID. Map-Reply: This message is sent by Map-Servers or ETRs in response to a Map-Request and contains the resolved mapping. Please note that a Map-Reply may contain a negative reply if, for example, the queried EID is not part of the LISP EID space. In such cases the ITR typically forwards the traffic natively (non encapsulated) to the public Internet, this behavior is defined to support incremental deployment of LISP. 3.4.3. Mapping System LISP architecturally decouples control and data-plane by means of a standard interface. This interface glues the data-plane, routers responsible for forwarding data-packets, with the LISP Mapping System, a database responsible for storing mappings. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 11] Internet-Draft LISP Introduction April 2015 With this separation in place the data and control-plane can use different architectures if needed and scale independently. Typically the data-plane is optimized to route packets according to hierarchical IP addresses. However the control-plane may have different requirements, for instance and by taking advantage of the LCAFs, the Mapping System may be used to store non-hierarchical keys (such as MAC addresses), requiring different architectural approaches for scalability. Another important difference between the LISP control and data-planes is that, and as a result of the local mapping cache available at ITR, the Mapping System does not need to operate at line-rate. Many of the existing mechanisms to create distributed systems have been explored and considered for the Mapping System architecture: graph-based databases in the form of LISP+ALT [RFC6836], hierarchical databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in the form of LISP-NERD [RFC6837], flat databases in the form of LISP-DHT [I-D.cheng-lisp-shdht],[Mathy] and, a multicast- based database [I-D.curran-lisp-emacs]. Furthermore it is worth noting that, in some scenarios such as private deployments, the Mapping System can operate as logically centralized. In such cases it is typically composed of a single Map-Server/Map-Resolver. The following focuses on the two mapping systems that have been implemented and deployed (LISP-ALT and LISP+DDT). 3.4.3.1. LISP+ALT The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first Mapping System proposed, developed and deployed on the LISP pilot network. It is based on a distributed BGP overlay participated by Map-Servers and Map-Resolvers. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-prefixes registered by the serviced ETRs, making the EID routable on the ALT topology. When an ITR needs a mapping it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible for the mapping. Upon reception the Map- Server forwards the request to the ETR that in turn, replies directly to the ITR using the native Internet core. 3.4.3.2. LISP-DDT LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a hierarchical directory whose internal structure mirrors the hierarchical nature of the EID address space. The DDT hierarchy is composed of DDT nodes forming a tree structure, the leafs of the tree Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 12] Internet-Draft LISP Introduction April 2015 are Map-Servers. On top of the structure there is the DDT root node [DDT-ROOT], which is a particular instance of a DDT node and that matches the entire address space. As in the case of DNS, DDT supports multiple redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers are the clients of the DDT hierarchy and can query either the DDT root and/or other DDT nodes. /---------\ | | | DDT Root| | /0 | ,.\---------/-, ,-'` | `'., -'` | `- /-------\ /-------\ /-------\ | DDT | | DDT | | DDT | | Node | | Node | | Note | ... | 0/8 | | 1/8 | | 2/8 | \-------/ \-------/ \-------/ _. _. . -..,,,_ -` -` \ ````''-- +------------+ +------------+ +------------+ +------------+ | Map-Server | | Map-Server | | Map-Server | | Map-Server | | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| +------------+ +------------+ +------------+ +------------+ Figure 3.- A schematic representation of the DDT tree structure, please note that the prefixes and the structure depicted should be only considered as an example. The DDT structure does not actually index EID-prefixes but eXtended EID-prefixes (XEID). An XEID-prefix is just the concatenation of the following fields (from most significant bit to less significant bit): Database-ID, Instance ID, Address Family Identifier and the actual EID-prefix. The Database-ID is provided for possible future requirements of higher levels in the hierarchy and to enable the creation of multiple and separate database trees. In order to resolve a query LISP-DDT operates in a similar way to the DNS but only supports iterative lookups. DDT clients (usually Map- Resolvers) generate Map-Requests to the DDT root node. In response they receive a newly introduced LISP-control message: a Map-Referral. A Map-Referral provides the list of RLOCs of the set of DDT nodes matching a configured XEID delegation. That is, the information contained in the Map-Referral points to the child of the queried DDT node that has more specific information about the queried XEID- prefix. This process is repeated until the DDT client walks the tree Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 13] Internet-Draft LISP Introduction April 2015 structure (downwards) and discovers the Map-Server servicing the queried XEID. At this point the client sends a Map-Request and receives a Map-Reply containing the mappings. It is important to note that DDT clients can also cache the information contained in Map-Referrals, that is, they cache the DDT structure. This is used to reduce the mapping retrieving latency[Jakab]. The DDT Mapping System relies on manual configuration. That is Map- Resolvers are manually configured with the set of available DDT root nodes while DDT nodes are manually configured with the appropriate XEID delegations. Configuration changes in the DDT nodes are only required when the tree structure changes itself, but it doesn't depend on EID dynamics (RLOC allocation or traffic engineering policy changes). 3.5. Internetworking Mechanisms EIDs are typically identical to either IPv4 or IPv6 addresses and they are stored in the LISP Mapping System, however they are usually not announced in the Internet global routing system. As a result LISP requires an internetworking mechanism to allow LISP sites to speak with non-LISP sites and vice versa. LISP internetworking mechanisms are specified in [RFC6832]. LISP defines two entities to provide internetworking: Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from the legacy Internet to LISP sites. PITRs announce in the global routing system blocks of EID prefixes (aggregating when possible) to attract traffic. For each incoming packet from a source not in a LISP site (a non-EID), the PITR LISP-encapsulates it towards the RLOC(s) of the appropriate LISP site. The impact of PITRs in the routing table size of the Default-Free Zone (DFZ) is, in the worst-case, similar to the case in which LISP is not deployed. EID-prefixes will be aggregated as much as possible both by the PITR and by the global routing system. Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from LISP sites to the legacy Internet. In some scenarios, LISP sites may be unable to send encapsulated packets with a local EID address as a source to the legacy Internet. For instance when Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge routers, or when an intermediate network between a LISP site and a non-LISP site does not support the desired version of IP (IPv4 or IPv6). In both cases the PETR overcomes such limitations by encapsulating packets over the network. There is no specified provision for the distribution of PETR RLOC addresses to the ITRs. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 14] Internet-Draft LISP Introduction April 2015 Additionally, LISP also defines mechanisms to operate with private EIDs [RFC1918] by means of LISP-NAT [RFC6832]. In this case the xTR replaces a private EID source address with a routable one. At the time of this writing, work is ongoing to define NAT-traversal capabilities, that is xTRs behind a NAT using non-routable RLOCs. PITRs, PETRs and, LISP-NAT enable incremental deployment of LISP, by providing significant flexibility in the placement of the boundaries between the LISP and non-LISP portions of the network, and making it easy to change those boundaries over time. 4. LISP Operational Mechanisms This section details the main operational mechanisms defined in LISP. 4.1. Cache Management LISP's decoupled control and data-plane, where mappings are stored in the control-plane and used for forwarding in the data plane, requires a local cache in ITRs to reduce signaling overhead (Map-Request/Map- Reply) and increase forwarding speed. The local cache available at the ITRs, called Map-Cache, is used by the router to LISP-encapsulate packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and contains basically the set of RLOCs with the associated traffic engineering policies (priorities and weights). The Map-Cache, as any other cache, requires cache coherence mechanisms to maintain up-to-date information. LISP defines three main mechanisms for cache coherence: Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR can't use the mapping until it is refreshed by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. Solicit-Map-Request (SMR): SMR is an explicit mechanism to update mapping information. In particular a special type of Map-Request can be sent on demand by ETRs to request refreshing a mapping. Upon reception of a SMR message, the ITR must refresh the bindings by sending a Map-Request to the Mapping System. Further uses of SMRs are documented in [RFC6830]. Map-Versioning: This optional mechanism piggybacks in the LISP header of data-packets the version number of the mappings used by an xTR. This way, when an xTR receives a LISP-encapsulated packet from a remote xTR, it can check whether its own Map-Cache or the one of the remote xTR is outdated. If its Map-Cache is outdated, it sends a Map-Request for the remote EID so to obtain the newest Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 15] Internet-Draft LISP Introduction April 2015 mappings. On the contrary, if it detects that the remote xTR Map- Cache is outdated, it sends a SMR to notify it that a new mapping is available. Finally it is worth noting that in some cases an entry in the map- cache can be proactively refreshed using the mechanisms described in the section below. 4.2. RLOC Reachability In most cases LISP operates with a pull-based Mapping System (e.g., DDT), this results in an edge to edge pull architecture. In such scenario the network state is stored in the control-plane while the data-plane pulls it on demand. This has consequences concerning the propagation of xTRs reachability/liveness information since pull architectures require explicit mechanisms to propagate this information. As a result LISP defines a set of mechanisms to inform ITRs and PITRS about the reachability of the cached RLOCs: Locator Status Bits (LSB): LSB is a passive technique, the LSB field is carried by data-packets in the LISP header and can be set by a ETRs to specify which RLOCs of the ETR site are up/down. This information can be used by the ITRs as a hint about the reachability to perform additional checks. Also note that LSB does not provide path reachability status, only hints on the status of RLOCs. Echo-nonce: This is also a passive technique, that can only operate effectively when data flows bi-directionally between two communicating xTRs. Basically, an ITR piggybacks a random number (called nonce) in LISP data packets, if the path and the probed locator are up, the ETR will piggyback the same random number on the next data-packet, if this is not the case the ITR can set the locator as unreachable. When traffic flow is unidirectional or when the ETR receiving the traffic is not the same as the ITR that transmits it back, additional mechanisms are required. RLOC-probing: This is an active probing algorithm where ITRs send probes to specific locators, this effectively probes both the locator and the path. In particular this is done by sending a Map-Request (with certain flags activated) on the data-plane (RLOC space) and waiting in return a Map-Reply, also sent on the data-plane. The active nature of RLOC-probing provides an effective mechanism to determine reachability and, in case of failure, switching to a different locator. Furthermore the mechanism also provides useful RTT estimates of the delay of the path that can be used by other network algorithms. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 16] Internet-Draft LISP Introduction April 2015 It is worth noting that RLOC probing and Echo-nonce can work together. Specifically if a nonce is not echoed, an ITR could RLOC- probe to determine if the path is up when it cannot tell the difference between a failed bidirectional path or the return path is not used (a unidirectional path). Additionally, LISP also recommends inferring reachability of locators by using information provided by the underlay, in particular: ICMP signaling: The LISP underlay -the current Internet- uses the ICMP protocol to signal unreachability (among other things). LISP can take advantage of this and the reception of a ICMP Network Unreachable or ICMP Host Unreachable message can be seen as a hint that a locator might be unreachable, this should lead to perform additional checks. Underlay routing: Both BGP and IBGP carry reachability information, LISP-capable routers that have access to underlay routing information can use it to determine if a given locator or path are reachable. 4.3. ETR Synchronization All the ETRs that are authoritative to a particular EID-prefix must announce the same mapping to the requesters, this means that ETRs must be aware of the status of the RLOCs of the remaining ETRs. This is known as ETR synchronization. At the time of this writing LISP does not specify a mechanism to achieve ETR synchronization. Although many well-known techniques could be applied to solve this issue it is still under research, as a result operators must rely on coherent manual configuration 4.4. MTU Handling Since LISP encapsulates packets it requires dealing with packets that exceed the MTU of the path between the ITR and the ETR. Specifically LISP defines two mechanisms: Stateless: With this mechanism the effective MTU is assumed from the ITR's perspective. If a payload packet is too big for the effective MTU, and can be fragmented, the payload packet is fragmented on the ITR, such that reassembly is performed at the destination host. Stateful: With this mechanism ITRs keep track of the MTU of the paths towards the destination locators by parsing the ICMP Too Big packets sent by intermediate routers. ITRs will send ICMP Too Big messages to inform the sources about the effective MTU. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 17] Internet-Draft LISP Introduction April 2015 Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or PLPMTUD [RFC4821] to keep track of the MTU towards the locators. In both cases if the packet cannot be fragmented (IPv4 with DF=1 or IPv6) then the ITR drops it and replies with a ICMP Too Big message to the source. 5. Mobility The separation between locators and identifiers in LISP is suitable for traffic engineering purpose where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. In this context, the border routers operate the xTR functionality and endpoints are not aware of the existence of LISP. This functionality is similar to Network Mobility [RFC3963]. However, this mode of operation does not allow seamless mobility of endpoints between different LISP sites as the EID address might not be routable in a visited site. Nevertheless, LISP can be used to enable seamless IP mobility when LISP is directly implemented in the endpoint or when the endpoint roams to an attached xTR. Each endpoint is then an xTR and the EID address is the one presented to the network stack used by applications while the RLOC is the address gathered from the network when it is visited. This functionality is similar to Mobile IP ([RFC5944] and [RFC6275]). Whenever the device changes of RLOC, the xTR updates the RLOC of its local mapping and registers it to its Map-Server, typically with a low TTL value (1min). To avoid the need of a home gateway, the ITR also indicates the RLOC change to all remote devices that have ongoing communications with the device that moved. The combination of both methods ensures the scalability of the system as signaling is strictly limited the Map-Server and to hosts with which communications are ongoing. In the mobility case the EID-prefix can be as small as a full /32 or /128 (IPv4 or IPv6 respectively) depending on the specific use-case (e.g., subnet mobility vs single VM/Mobile node mobility). The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions. 6. Multicast LISP also supports transporting IP multicast packets sent from the EID space, the operational changes required to the multicast protocols are documented in [RFC6831]. In such scenarios, LISP may create multicast state both at the core and at the sites (both source and receiver). When signaling is used Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 18] Internet-Draft LISP Introduction April 2015 to create multicast state at the sites, LISP routers unicast encapsulate PIM Join/Prune messages from receiver to source sites. At the core, ETRs build a new PIM Join/Prune message addressed to the RLOC of the ITR servicing the source. An simplified sequence is shown below 1. An end-host willing to join a multicast channel sends an IGMP report. Multicast PIM routers at the LISP site propagate PIM Join/Prune messages (S-EID, G) towards the ETR. 2. The join message flows to the ETR, upon reception the ETR builds two join messages, the first one unicast LISP-encapsulates the original join message towards the RLOC of the ITR servicing the source. This message creates (S-EID, G) multicast state at the source site. The second join message contains as destination address the RLOC of the ITR servicing the source (S-RLOC, G) and creates multicast state at the core. 3. Multicast data packets originated by the source (S-EID, G) flow from the source to the ITR. The ITR LISP-encapsulates the multicast packets, the outter header includes its own RLOC as the source (S-RLOC) and the original multicast group address (G) as the destination. Please note that multicast group address are logical and are not resolved by the mapping system. Then the multicast packet is transmitted through the core towards the receiving ETRs that decapsulates the packets and sends them using the receiver's site multicast state. Please note that the inner and outer multicast addresses are in general different, unless in specific cases where the underlay provider implements a tight control on the overlay. LISP specifications already support all PIM modes [RFC6831]. Additionally, LISP can support as well non-PIM mechanisms in order to maintain multicast state. 7. Use Cases 7.1. Traffic Engineering A LISP site can strictly impose via which ETRs the traffic must enter the the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. This fine control is implemented with the mappings. When a remote site is willing to send traffic to a LISP site, it retrieves the mapping associated to the destination EID via the mapping system. The mapping is sent directly by an authoritative ETR of the EID and is not altered by any intermediate network. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 19] Internet-Draft LISP Introduction April 2015 A mapping associates a list of RLOCs to an EID prefix. Each RLOC corresponds to an interface of an ETR (or set of ETRs) that is able to correctly forward packets to EIDs in the prefix. Each RLOC is tagged with a priority and a weight in the mapping. The priority is used to indicates which RLOCs should be preferred to send packets (the least preferred ones being provided for backup purpose). The weight permits to balance the load between the RLOCs with the same priority, proportionally to the weight value. As mappings are directly issued by the authoritative ETR of the EID and are not altered while transmitted to the remote site, it offers highly flexible incoming inter-domain traffic engineering with even the possibility for a site to support a different mapping policy for each remote site. routing policies. 7.2. LISP for IPv6 Co-existence LISP encapsulations allows to transport packets using EIDs from a given address family (e.g., IPv6) with packets from other address families (e.g., IPv4). The absence of correlation between the address family of RLOCs and EIDs makes LISP a candidate to allow, e.g., IPv6 to be deployed when all of the core network may not have IPv6 enabled. For example, two IPv6-only data centers could be interconnected via the legacy IPv4 Internet. If their border routers are LISP capable, sending packets between the data center is done without any form of translation as the native IPv6 packets (in the EID space) will be LISP encapsulated and transmitted over the IPv4 legacy Internet by the mean of IPv4 RLOCs. 7.3. LISP for Virtual Private Networks It is common to operate several virtual networks over the same physical infrastructure. In such virtual private networks, it is essential to distinguish which virtual network a packet belongs and tags or labels are used for that purpose. When using LISP, the distinction can be made with the Instance ID field. When an ITR encapsulates a packet from a particular virtual network (e.g., known via the VRF or VLAN), it tags the encapsulated packet with the Instance ID corresponding to the virtual network of the packet. When an ETR receives a packet tagged with an Instance ID it uses the Instance ID to determine how to treat the packet. The main usage of LISP for virtual private networks does not introduce additional requirements on the underlying network, as long as it is running IP. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 20] Internet-Draft LISP Introduction April 2015 7.4. LISP for Virtual Machine Mobility in Data Centers A way to enable seamless virtual machine mobility in data center is to conceive the datacenter backbone as the RLOC space and the subnet where servers are hosted as forming the EID space. A LISP router is placed at the border between the backbone and each subnet. When a virtual machine is moved to another subnet, it can keep (temporarily) the address it had before the move so to continue without a transport layer connection reset. When an xTR detects a source address received on a subnet to be an address not assigned to the subnet, it registers the address to the Mapping System. To inform the other LISP routers that the machine moved and where, and then to avoid detours via the initial subnetwork, mechanisms such as the Solicit-Map-Request messages are used. 8. Security Considerations This section describes the security considerations associated to the LISP protocol. While in a push mapping system, the state necessary to forward packets is learned independently of the traffic itself, with a pull architecture, the system becomes reactive and data-plane events (e.g., the arrival of a packet for an unknown destination) may trigger control-plane events. This on-demand learning of mappings provides many advantages as discussed above but may also affect the way security is enforced. Usually, the data-plane is implemented in the fast path of routers to provide high performance forwarding capabilities while the control- plane features are implemented in the slow path to offer high flexibility and a performance gap of several order of magnitude can be observed between the slow and the fast paths. As a consequence, the way data-plane events are notified to the control-plane must be thought carefully so to not overload the slow path and rate limiting should be used as specified in [RFC6830]. Care must also be taken so to not overload the mapping system (i.e., the control plane infrastructure) as the operations to be performed by the mapping system may be more complex than those on the data- plane, for that reason [RFC6830] recommends to rate limit the sending of messages to the mapping system. To improve resiliency and reduce the overall number of messages exchanged, LISP offers the possibility to leak information, such as reachabilty of locators, directly into data plane packets. In Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 21] Internet-Draft LISP Introduction April 2015 environments that are not fully trusted, control information gleaned from data-plane packets should be verified before using them. Mappings are the centrepiece of LISP and all precautions must be taken to avoid them to be manipulated or misused by malicious entities. Using trustable Map-Servers that strictly respect [RFC6833] and the lightweight authentication mechanism proposed by LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the mapping integrity. In more critical environments, secure measures may be needed. The way security is implemented for a given mapping system strongly depends on the architecture of the mapping system itself and the threat model assumed for the deployment. Thus, the mapping system security has to be discussed in the relevant documents proposing the mapping system architecture. As with any other tunneling mechanism, middleboxes on the path between an ITR (or PITR) and an ETR (or PETR) must implement mechanisms to strip the LISP encapsulation to correctly inspect the content of LISP encapsulated packets. Like other map-and-encap mechanisms, LISP enables triangular routing (i.e., packets of a flow cross different border routers depending on their direction). This means that intermediate boxes may have incomplete view on the traffic they inspect or manipulate. Moreover, LISP-encapsulated packets are routed based on the outer IP address (i.e., the RLOC), and can be delivered to an ETR that is not responsible of the destination EID of the packet or even to a network element that is not an ETR. The mitigation consists in applying appropriate filtering techniques on the network elements that can potentially receive un-expected LISP-encapsulated packets More details about security implications of LISP are discussed in [I-D.ietf-lisp-threats]. 9. IANA Considerations This memo includes no request to IANA. 10. Acknowledgements This document was initiated by Noel Chiappa and much of the core philosophy came from him. The authors acknowledge the important contributions he has made to this work and thank him for his past efforts. The authors would also like to thank Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 22] Internet-Draft LISP Introduction April 2015 Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black as well as every people acknowledged in [RFC6830]. 11. References 11.1. Normative References [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in progress), October 2014. [I-D.ietf-lisp-lcaf] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in progress), December 2014. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 (work in progress), October 2014. [I-D.ietf-lisp-threats] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", draft-ietf-lisp-threats-12 (work in progress), March 2015. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 23] Internet-Draft LISP Introduction April 2015 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, January 2013. [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 24] Internet-Draft LISP Introduction April 2015 [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, October 2013. [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, April 2014. 11.2. Informative References [DDT-ROOT] LISP DDT ROOT, , "http://ddt-root.org/", August 2013. [I-D.cheng-lisp-shdht] Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping Overlay", draft-cheng-lisp-shdht-04 (work in progress), July 2013. [I-D.curran-lisp-emacs] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Mappings Multicast Across Cooperating Systems for LISP", draft-curran-lisp-emacs-00 (work in progress), November 2007. [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System, IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343", October 2010. [Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: Towards a DHT to map identifiers onto locators. The ACM ReArch, Re-Architecting the Internet. Madrid (Spain)", December 2008. [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, ""Evaluating the Benefits of the Locator/Identifier Separation" in Proceedings of 2Nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture", 2007. Appendix A. A Brief History of Location/Identity Separation The LISP architecture for separation of location and identity resulted from the discussions of this topic at the Amsterdam IAB Routing and Addressing Workshop, which took place in October 2006 [RFC4984]. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 25] Internet-Draft LISP Introduction April 2015 A small group of like-minded personnel spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on various mailing lists. The first Internet-Draft on LISP appeared in January, 2007. Trial implementations started at that time, with initial trial deployments underway since June 2007; the results of early experience have been fed back into the design in a continuous, ongoing process over several years. LISP at this point represents a moderately mature system, having undergone a long organic series of changes and updates. LISP transitioned from an IRTF activity to an IETF WG in March 2009, and after numerous revisions, the basic specifications moved to becoming RFCs at the start of 2013 (although work to expand and improve it, and find new uses for it, continues, and undoubtly will for a long time to come). A.1. Old LISP Models LISP, as initially conceived, had a number of potential operating modes, named 'models'. Although they are no used anymore, one occasionally sees mention of them, so they are briefly described here. LISP 1: EIDs all appear in the normal routing and forwarding tables of the network (i.e. they are 'routable');this property is used to 'bootstrap' operation, by using this to load EID->RLOC mappings. Packets were sent with the EID as the destination in the outer wrapper; when an ETR saw such a packet, it would send a Map-Reply to the source ITR, giving the full mapping. LISP 1.5: Similar to LISP 1, but the routability of EIDs happens on a separate network. LISP 2: EIDs are not routable; EID->RLOC mappings are available from the DNS. LISP 3: EIDs are not routable; and have to be looked up in in a new EID->RLOC mapping database (in the initial concept, a system using Distributed Hash Tables). Two variants were possible: a 'push' system, in which all mappings were distributed to all ITRs, and a 'pull' system in which ITRs load the mappings they need, as needed. Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 26] Internet-Draft LISP Introduction April 2015 Authors' Addresses Albert Cabellos UPC-BarcelonaTech c/ Jordi Girona 1-3 Barcelona, Catalonia 08034 Spain Email: acabello@ac.upc.edu Damien Saucez (Ed.) INRIA 2004 route des Lucioles BP 93 Sophia Antipolis Cedex 06902 France Email: damien.saucez@inria.fr Cabellos & Saucez (Ed.) Expires October 4, 2015 [Page 27] ./draft-ietf-lisp-rfc8113bis-03.txt0000644000764400076440000002404513422536530016115 0ustar iustyiusty LISP M. Boucadair Internet-Draft C. Jacquenet Obsoletes: 8113 (if approved) Orange Intended status: Standards Track January 25, 2019 Expires: July 29, 2019 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations draft-ietf-lisp-rfc8113bis-03 Abstract This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 29, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Boucadair & Jacquenet Expires July 29, 2019 [Page 1] Internet-Draft LISP Packet Type Allocations January 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. LISP Shared Extension Message Type . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5.1. LISP Packet Types . . . . . . . . . . . . . . . . . . . . 3 5.2. Sub-Types . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Changes from RFC 8113 . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Locator/ID Separation Protocol (LISP) base specification, [I-D.ietf-lisp-rfc6833bis], defines a set of primitives that are identified with a packet type code. Several extensions have been proposed to add more LISP functionalities. It is expected that additional LISP extensions will be proposed in the future. The "LISP Packet Types" IANA registry (see Section 5) is used to ease the tracking of LISP message types. Because of the limited type space [I-D.ietf-lisp-rfc6833bis] and the need to conduct experiments to assess new LISP extensions, this document specifies a shared LISP extension message type and describes a procedure for registering LISP shared extension sub-types (see Section 3). Concretely, one single LISP message type code is dedicated to future LISP extensions; sub-types are used to uniquely identify a given LISP extension making use of the shared LISP extension message type. These identifiers are selected by the author(s) of the corresponding LISP specification that introduces a new LISP extension message type. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Boucadair & Jacquenet Expires July 29, 2019 [Page 2] Internet-Draft LISP Packet Type Allocations January 2019 3. LISP Shared Extension Message Type Figure 1 depicts the common format of the LISP shared extension message. The type field MUST be set to 15 (see Section 5). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=15| Sub-type | extension-specific | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // extension-specific // // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: LISP Shared Extension Message Type The "Sub-type" field conveys a unique identifier that MUST be registered with IANA (see Section 5.2). The exact structure of the 'extension-specific' portion of the message is specified in the corresponding specification document. 4. Security Considerations This document does not introduce any additional security issues other than those discussed in [I-D.ietf-lisp-rfc6833bis]. 5. IANA Considerations 5.1. LISP Packet Types IANA has created a protocol registry for LISP Packet Types, numbered 0-15. Values can be assigned via Standards Action [RFC8126]. Documents that request for a new LISP packet type may indicate a preferred value in the corresponding IANA sections. IANA is requested to replace the reference to RFC8113 with the RFC number to be assigned to this document. Also, IANA is requested to update the table as follows: Boucadair & Jacquenet Expires July 29, 2019 [Page 3] Internet-Draft LISP Packet Type Allocations January 2019 OLD: Message Code Reference ================================= ==== =============== LISP Shared Extension Message 15 [RFC8113] NEW: Message Code Reference ================================= ==== =============== LISP Shared Extension Message 15 [ThisDocument] 5.2. Sub-Types IANA has created the "LISP Shared Extension Message Type Sub-types" registry. IANA is requested to update that registry by replacing the reference to RFC8113 with the RFC number to be assigned to this document. The values in the range 0-1023 are assigned via Standards Action. This range is provisioned to anticipate, in particular, the exhaustion of the LISP Packet types. The values in the range 1024-4095 are assigned on a First Come, First Served (FCFS) basis. The registration procedure should provide IANA with the desired codepoint and a point of contact; providing a short description (together with an acronym, if relevant) of the foreseen usage of the extension message is also encouraged. 6. Changes from RFC 8113 The following changes were made from RFC 8113: o Change the status from Experimental to Standard track. o Indicate explicitly that the shared extension is used for two purposes: extend the type space and conduct experiments to assess new LISP extensions. o Delete pointers to some examples illustrating how the shared extension message is used to extend the LISP protocol. o Request IANA to update the "IANA LISP Packet Types" and "LISP Shared Extension Message Type Sub-types" registries to point to this document instead of RFC8113. Boucadair & Jacquenet Expires July 29, 2019 [Page 4] Internet-Draft LISP Packet Type Allocations January 2019 7. Acknowledgments This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 009-X. Many thanks to Luigi Iannone, Dino Farinacci, and Alvaro Retana for the review. Thanks to Geoff Huston, Brian Carpenter, Barry Leiba, and Suresh Krishnan for the review. 8. Normative References [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-23 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Mohamed Boucadair Orange Rennes 35000 France EMail: mohamed.boucadair@orange.com Boucadair & Jacquenet Expires July 29, 2019 [Page 5] Internet-Draft LISP Packet Type Allocations January 2019 Christian Jacquenet Orange Rennes 35000 France EMail: christian.jacquenet@orange.com Boucadair & Jacquenet Expires July 29, 2019 [Page 6] ./draft-ietf-lwig-cellular-06.txt0000644000764400076440000011550712642451747016146 0ustar iustyiusty Network Working Group J. Arkko Internet-Draft A. Eriksson Intended status: Informational A. Keranen Expires: July 7, 2016 Ericsson January 4, 2016 Building Power-Efficient CoAP Devices for Cellular Networks draft-ietf-lwig-cellular-06 Abstract This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 7, 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 Arkko, et al. Expires July 7, 2016 [Page 1] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Goals for Low-Power Operation . . . . . . . . . . . . . . . . 3 3. Link-Layer Assumptions . . . . . . . . . . . . . . . . . . . 5 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Discovery and Registration . . . . . . . . . . . . . . . . . 8 6. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Real-Time Reachable Devices . . . . . . . . . . . . . . . . . 10 8. Sleepy Devices . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Implementation Considerations . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This memo discusses the use of the Constrained Application Protocol (CoAP) protocol [RFC7252] in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. CoAP has many advantages, including being simple to implement; a thousand lines for the entire software above IP layer is plenty for a CoAP-based sensor, for instance. However, while many of these advantages are obvious and easily obtained, optimizing power consumption remains challenging and requires careful design [I-D.arkko-core-sleepy-sensors]. The memo targets primarily 3GPP cellular networks in their 2G, 3G, and LTE variants and their future enhancements, including possible power efficiency improvements at the radio and link layers. The exact standards or details of the link layer or radios are not relevant for our purposes, however. To be more precise, the material in this memo is suitable for any large-scale, public network that employs point-to-point communications model and radio technology for the devices in the network. Our focus is devices that need to be optimized for power usage, and on devices that employ CoAP. As a general technology, CoAP is similar to HTTP. It can be used in various ways and network entities Arkko, et al. Expires July 7, 2016 [Page 2] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 may take on different roles. This freedom allows the technology to be used in efficient and less efficient ways. Some guidance is needed to understand what communication models over CoAP are recommended when low power usage is a critical goal. The recommendations in this memo should be taken as complementary to device hardware optimization, microelectronics improvements, and further evolution of the underlying link and radio layers. Further gains in power efficiency can certainly be gained on several fronts; the approach that we take in this memo is to do what can be done at the IP, transport, and application layers to provide the best possible power efficiency. Application implementors generally have to use the current generation microelectronics, currently available radio networks and standards, and so on. This focus in our memo should by no means be taken as an indication that further evolution in these other areas is unnecessary. Such evolution is useful, is ongoing, and is generally complementary to the techniques presented in this memo. The evolution of underlying technologies may change what techniques described here are useful for a particular application, however. The rest of this memo is structured as follows. Section 2 discusses the need and goals for low-power devices. Section 3 outlines our expectations for the low layer communications model. Section 4 describes the two scenarios that we address, and Section 5, Section 6, Section 7 and Section 8 give guidelines for use of CoAP in these scenarios. 2. Goals for Low-Power Operation There are many situations where power usage optimization is unnecessary. Optimization may not be necessary on devices that can run on power feed over wired communications media, such as in Power- over-Ethernet (PoE) solutions. These devices may require a rudimentary level of power optimization techniques just to keep overall energy costs and aggregate power feed sizes at a reasonable level, but more extreme techniques necessary for battery powered devices are not required. The situation is similar with devices that can easily be connected to mains power. Other types of devices may get an occasional charge of power from energy harvesting techniques. For instance, some environmental sensors can run on solar cells. Typically, these devices still have to regulate their power usage in a strict manner, for instance to be able to use as small and inexpensive solar cells as possible. In battery operated devices the power usage is even more important. For instance, one of the authors employs over a hundred different sensor devices in his home network. A majority of these devices are Arkko, et al. Expires July 7, 2016 [Page 3] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 wired and run on PoE, but in most environments this would be impractical because the necessary wires do not exist. The future is in wireless solutions that can cover buildings and other environments without assuming a pre-existing wired infrastructure. In addition, in many cases it is impractical to provide a mains power source. Often there are no power sockets easily available in the locations that the devices need to be in, and even if there were, setting up the wires and power adapters would be more complicated than installing a standalone device without any wires. Yet, with a large number of devices the battery lifetimes become critical. Cost and practical limits dictate that devices can be largely just bought and left on their own. For instance, with hundred devices, even a ten-year battery lifetime results in a monthly battery change for one device within the network. This may be impractical in many environments. In addition, some devices may be physically difficult to reach for a battery change. Or, a large group of devices -- such as utility meters or environmental sensors -- cannot be economically serviced too often, even if in theory the batteries could be changed. Many of these situations lead to a requirement for minimizing power usage and/or maximizing battery lifetimes. Using the power usage strategies described in [RFC7228], mains-powered sensor-type devices can use the Always-on strategy whereas battery or energy harvesting devices need to adjust behavior based on the communication interval. For intervals in the order of seconds, Low-power strategy is appropriate. For intervals ranging from minutes to hours either Low- power or Normally-off strategies are suitable. Finally, for intervals lasting days and longer, Normally-off is usually the best choice. Unfortunately, much of our current technology has been built with different objectives in mind. Networked devices that are "always on", gadgets that require humans to recharge them every couple of days, and protocols that have been optimized to maximize throughput rather than conserve resources. Long battery lifetimes are required for many applications, however. In some cases these lifetimes should be in the order of years or even a decade or longer. Some communication devices already reach multi- year lifetimes, and continuous improvement in low-power electronics and advances in radio technology keep pushing these lifetimes longer. However, it is perhaps fair to say that battery lifetimes are generally too short at present time. Power usage can not be evaluated solely based on lower layer communications. The entire system, including upper layer protocols and applications is responsible for the power consumption as a whole. The lower communication layers have already adopted many techniques Arkko, et al. Expires July 7, 2016 [Page 4] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 that can be used to reduce power usage, such as scheduling device wake-up times. Further reductions will likely need some co-operation from the upper layers so that unnecessary communications, denial-of- service attacks on power consumption, and other power drains are eliminated. Of course, application requirements ultimately determine what kinds of communications are necessary. For instance, some applications require more data to be sent than others. The purpose of the guidelines in this memo is not to prefer one or the other application, but to provide guidance on how to minimize the amount of communications overhead that is not directly required by the application. While such optimization is generally useful, it is relatively speaking most noticeable in applications that transfer only a small amount of data, or operate only infrequently. 3. Link-Layer Assumptions We assume that the underlying communications network can be any large-scale, public network that employs point-to-point communications model and radio technology. 2G, 3G, and LTE networks are examples of such networks, but not the only possible networks with these characteristics. In the following we look at some of these characteristics and their implications. Note that in most cases these characteristics are not properties of the specific networks but rather inherent in the concept of public networks. Public networks Using a public network service implies that applications can be deployed without having to build a network to go with them. For economic reasons, only the largest users (such as utility companies) could afford to build their own network, and even they would not be able to provide a world-wide coverage. This means that applications where coverage is important can be built. For instance, most transport sector applications require national or even world-wide coverage to work. But there are other implications, as well. By definition, the network is not tailored for this application and with some exceptions, the traffic passes through the Internet. One implication of this is that there are generally no application- specific network configurations or discovery support. For instance, the public network helps devices to get on the Internet, set up default routers, configure DNS servers, and so on, but does nothing for configuring possible higher-layer functions, such as Arkko, et al. Expires July 7, 2016 [Page 5] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 servers the device might need to contact to perform its application functions. Public networks often provide web proxies and other functionality that can in some cases make a significant improvement for delays and cost of communication over the wireless link. For instance, resolving server DNS names in a proxy instead of the user's device may cut down on the general chattiness of the communications, therefore reducing overall delay in completing the entire transaction. Likewise, a CoAP proxy or pub/sub broker [I-D.koster-core-coap-pubsub] can assist a CoAP device in communication. However, unlike HTTP web proxies, CoAP proxies and brokers are not yet widely deployed in public networks. Similarly, given the lack of available IPv4 addresses, the chances are that many devices are behind a network address translation (NAT) device. This means that they are not easily reachable as servers. Alternatively, the devices may be directly on the global Internet (either on IPv4 or IPv6) and easily reachable as servers. Unfortunately, this may mean that they also receive unwanted traffic, which may have implications for both power consumption and service costs. Point-to-point link model This is a common link model in cellular networks. One implication of this model is that there will be no other nodes on the same link, except maybe for the service provider's router. As a result, multicast discovery can not be reasonably used for any local discovery purposes. While the configuration of the service provider's router for specific users is theoretically possible, in practice this is difficult to achieve, at least for any small user that can not afford a network-wide contract for a private APN (Access Point Name). The public network access service has little per-user tailoring. Radio technology The use of radio technology means that power is needed to operate the radios. Transmission generally requires more power than reception. However, radio protocols have generally been designed so that a device checks periodically whether it has messages. In a situation where messages arrive seldom or not at all, this checking consumes energy. Research has shown that these periodic checks (such as LTE paging message reception) are often a far bigger contributor to energy consumption than message transmission. Arkko, et al. Expires July 7, 2016 [Page 6] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 Note that for situations where there are several applications on the same device wishing to communicate with the Internet in some manner, bundling those applications together so that they can communicate at the same time can be very useful. Some guidance for these techniques in the smartphone context can be found in [Android-Bundle]. Naturally, each device has a freedom to decide when it sends messages. In addition, we assume that there is some way for the devices to control when or how often it wants to receive messages. Specific methods for doing this depend on the specific network being used and also tend to change as improvements in the design of these networks are incorporated. The reception control methods generally come in two variants, fine grained mechanisms that deal with how often the device needs to wake-up for paging messages, and more crude mechanisms where the device simply disconnects from the network for a period of time. There are associated costs and benefits to each method, but those are not relevant for this memo, as long as some control method exists. Furthermore, devices could use Delay-Tolerant Networking (DTN) [RFC4838] mechanisms to relax the requirements for timeliness of connectivity and message delivery. 4. Scenarios Not all applications or situations are equal. They may require different solutions or communication models. This memo focuses on two common scenarios at cellular networks: Real-Time Reachable Devices This scenario involves all communication that requires real-time or near real-time communications with a device. That is, a network entity must be able to reach the device with a small time lag at any time, and no pre-agreed wake-up schedule can be arranged. By "real-time" we mean any reasonable end-to-end communications latency, be it measured in milliseconds or seconds. However, unpredictable sleep states are not expected. Examples of devices in this category include sensors that must be measurable from a remote source at any instant in time, such as process automation sensors and actuators that require immediate action, such as light bulbs or door locks. Sleepy Devices This scenario involves freedom to choose when device communicates. The device is often expected to be able to be in a sleep state for Arkko, et al. Expires July 7, 2016 [Page 7] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 much of its time. The device itself can choose when it communicates, or it lets the network assist in this task. Examples of devices in this category include sensors that track slowly changing values, such as temperature sensors and actuators that control a relatively slow process, such as heating systems. Note that there may be hard real-time requirements, but they are expressed in terms of how fast the device can communicate, not in terms of how fast it can respond to a network stimuli. For instance, a fire detector can be classified as a sleepy device as long as it can internally quickly wake up on detecting fire and initiate the necessary communications without delay. 5. Discovery and Registration In both scenarios the device will be attached to a public network. Without special arrangements, the device will also get a dynamically assigned IP address or an IPv6 prefix. At least one but typically several router hops separate the device from its communicating peers such as application servers. As a result, the address or even the existence of the device is typically not immediately obvious to the other nodes participating in the application. As discussed earlier, multicast discovery has limited value in public networks; network nodes cannot practically discover individual devices in a large public network. And the devices can not discover who they need to talk, as the public network offers just basic Internet connectivity. Our recommendation is to initiate a discovery and registration process. This allows each device to inform its peers that it has connected to the network and that it is reachable at a given IP address. Registration also facilitates low-power operation since a device can delegate part of the discovery signaling and reachability requirements to another node. The registration part is easy e.g., with a resource directory. The device should perform the necessary registration with these devices, for instance, as specified in [I-D.ietf-core-resource-directory]. In order to do this registration, the device needs to know its CoRE Link Format description, as specified in [RFC6690]. In essence, the registration process involves performing a GET on .well-known/ core/?rt=core-rd at the address of the resource directory, and then doing a POST on the path of the discovered resource. Other mechanisms enabling device discovery and delegation of functionality to a non-sleepy node include [I-D.vial-core-mirror-proxy] and [I-D.koster-core-coap-pubsub]. Arkko, et al. Expires July 7, 2016 [Page 8] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 However, current CoAP specifications provide only limited support for discovering the resource directory or other registration services. Local multicast discovery only works in LAN-type networks, but not in these public cellular networks. Our recommended alternate methods for discovery are the following: Manual Configuration The DNS name of the resource directory is manually configured. This approach is suitable in situations where the owner of the devices has the resources and capabilities to do the configuration. For instance, a utility company can typically program its metering devices to point to the company servers. Manufacturer Server The DNS name of the directory or proxy is hardwired to the software by the manufacturer, and the directory or proxy is actually run by the manufacturer. This approach is suitable in many consumer usage scenarios, where it would be unreasonable to assume that the consumer runs any specific network services. The manufacturer's web interface and the directory/proxy servers can co-operate to provide the desired functionality to the end user. For instance, the end user can register a device identity in the manufacturer's web interface and ask specific actions to be taken when the device does something. Delegating Manufacturer Server The DNS name of the directory or proxy is hardwired to the software by the manufacturer, but this directory or proxy merely redirects the request to a directory or proxy run by the whoever bought the device. This approach is suitable in many enterprise environments, as it allows the enterprise to be in charge of actual data collection and device registries; only the initial bootstrap goes through the manufacturer. In many cases there are even legal requirements (such as EU privacy laws) that prevent providing unnecessary information to third parties. Common Global Resolution Infrastructure The delegating manufacturer server model could be generalized into a reverse-DNS -like discovery infrastructure that could answer the question "this is device with identity ID, where is my home registration server?". However, at present no such resolution system exists. (Note: The EPCGlobal system for RFID resolution is reminiscent of this approach.) Arkko, et al. Expires July 7, 2016 [Page 9] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 Besides manual configuration, these alternate mechanisms are mostly suitable for large manufacturers and deployments. Good automated mechanism for discovery of devices that are manufactured and deployed in small quantities are still needed. 6. Data Formats A variety of data formats exist for passing around data. These data formats include XML, JavaScript Object Notation (JSON) [RFC7159], Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text formats. Message lengths can have a significant effect on the amount of energy required for the communications, and such it is highly desirable to keep message lengths minimal. At the same time, extreme optimization can affect flexibility and ease of programming. The authors recommend [I-D.jennings-core-senml] as a compact, yet easily processed and extendable textual format. 7. Real-Time Reachable Devices These devices are often best modeled as CoAP servers. The device will have limited control on when it receives messages, and it will have to listen actively for messages, up to the limits of the underlying link layer. If the device acts also in client role in some phase of its operation, it can control how many transmissions it makes on its own behalf. The packet reception checks should be tailored according to the requirements of the application. If sub-second response time is not needed, a more infrequent checking process may save some power. For sensor-type devices, the CoAP Observe extension [RFC7641] may be supported. This allows the sensor to track changes to the sensed value, and make an immediate observation response upon a change. This may reduce the amount of polling needed to be done by the client. Unfortunately, it does not reduce the time that the device needs to be listening for requests. Subscription requests from other clients than the currently registered one may come at any time, the current client may change its request, and the device still needs to respond to normal queries as a server. As a result, the sensor can not rely having to communicate only on its own choice of observation interval. In order to act as a server, the device needs to be placed in a public IPv4 address, be reachable over IPv6, or hosted in a private network. If the the device is hosted on a private network, then all other nodes need to access this device also need to reside in the same private network. There are multiple ways to provide private networks over public cellular networks. One approach is to dedicate Arkko, et al. Expires July 7, 2016 [Page 10] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 a special APN for the private network. Corporate access via cellular networks has often been arranged in this manner, for instance. Another approach is to use Virtual Private Networking (VPN) technology, for instance IPsec-based VPNs. Power consumption from unwanted traffic is problematic in these devices, unless placed in a private network or protected by a operator-provided firewall service. Devices on an IPv6 network will have some protection through the nature of the 2^64 address allocation for a single terminal in a 3GPP cellular network; the attackers will be unable to guess the full IP address of the device. However, this protects only the device from processing a packet, but since the network will still deliver the packet to any of the addresses within the assigned 64-bit prefix, packet reception costs are still incurred. Note that the the VPN approach can not prevent unwanted traffic received at the tunnel endpoint address, and may require keep-alive traffic. Special APNs can solve this issue, but require explicit arrangement with the service provider. 8. Sleepy Devices These devices are best modeled as devices that can delegate queries to some other node. For instance, as mirror proxy [I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe [I-D.koster-core-coap-pubsub] clients. When the device initializes itself, it makes a registration of itself in a proxy as described above in Section 5 and then continues to send periodic updates of sensor values. As a result, the device acts only as a client, not a server, and can shut down all communication channels while it is during its sleeping period. The length of the sleeping period depends on power and application requirements. Some environmental sensors might use a day or a week as the period, while other devices may use a smaller values ranging from minutes to hours. Other approaches for delegation include CoAP-options described in [I-D.castellani-core-alive] [I-D.fossati-core-publish-monitor-options]. In this memo we use mirror proxies as an example, because of their ability to work with both HTTP and CoAP implementations; but the concepts are similar and the IETF work is still in progress so the final protocol details are yet to be decided. The ability to shut down communications and act as only a client has four impacts: Arkko, et al. Expires July 7, 2016 [Page 11] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 o Radio transmission and reception can be turned off during the sleeping period, reducing power consumption significantly. o However, some power and time is consumed by having to re-attach to the network after the end of a sleep period. o The window of opportunity for unwanted traffic to arrive is much smaller, as the device is listening for traffic only part of the time. Note that networks may cache packets for some time though. On the other hand, stateful firewalls can effectively remove much of unwanted traffic for client type devices. o The device may exist behind a NAT or a firewall without being impacted. Note that "Simple Security" basic IPv6 firewall capability [RFC6092] blocks inbound UDP traffic by default, so just moving to IPv6 is not direct solution to this problem. For sleepy devices that represent actuators, it is also possible to use the mirror proxy model. The device can make periodic polls to the proxy to determine if a variable has changed. 8.1. Implementation Considerations There are several challenges in implementing sleepy devices. They need hardware that can be put to an appropriate sleep mode but yet awakened when it is time to do something again. This is not always easy in all hardware platforms. It is important to be able to shut down as much of the hardware as possible, preferably down to everything else except a clock circuit. The platform also needs to support re-awakening at suitable time scales, as otherwise the device needs to be powered up too frequently. Most commercial cellular modem platforms do not allow applications to suspend the state of the communications stack. Hence, after a power- off period they need to re-establish communications, which takes some amount of time and extra energy. Implementations should have a coordinated understanding of the state and sleeping schedule. For instance, it makes no sense to keep a CPU powered up, waiting for a message when the lower layer has been told that the next possible paging opportunity is some time away. The cellular networks have a number of adjustable configuration parameters, such as the maximum used paging interval. Proper setting of these values has an impact on the power consumption of the device, but with the current business practices, such settings are rarely negotiated when the user's subscription is provisioned. Arkko, et al. Expires July 7, 2016 [Page 12] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 9. Security Considerations There are no particular security aspects with what has been discussed in this memo, except for the ability to delegate queries for a resource to another node. Depending on how this is done, there are obvious security issues which have largely NOT yet been addressed in the relevant Internet Drafts [I-D.vial-core-mirror-proxy] [I-D.castellani-core-alive] [I-D.fossati-core-publish-monitor-options]. However, we point out that in general, security issues in delegation can be solved either through reliance on your local network support nodes (which may be quite reasonable in many environments) or explicit end-to-end security. Explicit end-to-end security through nodes that are awake at different times means in practice end-to-end data object security. We have implemented one such mechanism for sleepy nodes as described in [I-D.aks-lwig-crypto-sensors]. The security considerations relating to CoAP [RFC7252] and the relevant link layers should apply. Note that cellular networks universally employ per-device authentication, integrity protection, and for most of the world, encryption of all their communications. Additional protection of transport sessions is possible through mechanisms described in [RFC7252] or data objects. 10. IANA Considerations There are no IANA impacts in this memo. 11. References 11.1. Normative References [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . Arkko, et al. Expires July 7, 2016 [Page 13] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory", draft-ietf-core-resource-directory-05 (work in progress), October 2015. [W3C.REC-exi-20110310] Kamiya, T. and J. Schneider, "Efficient XML Interchange (EXI) Format 1.0", World Wide Web Consortium Recommendation REC- exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310, March 2011. [I-D.jennings-core-senml] Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, "Media Types for Sensor Markup Language (SENML)", draft- jennings-core-senml-02 (work in progress), October 2015. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . 11.2. Informative References [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, . [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, . [I-D.arkko-core-sleepy-sensors] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- sleepy-sensors-01 (work in progress), July 2011. Arkko, et al. Expires July 7, 2016 [Page 14] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 [I-D.aks-lwig-crypto-sensors] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", draft-aks-lwig-crypto-sensors-00 (work in progress), October 2015. [I-D.castellani-core-alive] Castellani, A. and S. Loreto, "CoAP Alive Message", draft- castellani-core-alive-00 (work in progress), March 2012. [I-D.fossati-core-publish-monitor-options] Fossati, T., Giacomin, P., and S. Loreto, "Publish and Monitor Options for CoAP", draft-fossati-core-publish- monitor-options-01 (work in progress), March 2012. [I-D.vial-core-mirror-proxy] Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- proxy-01 (work in progress), July 2012. [I-D.koster-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-koster-core-coap-pubsub-04 (work in progress), November 2015. [Android-Bundle] "Optimizing Downloads for Efficient Network Access", Android developer note http://developer.android.com/training/efficient-downloads/ efficient-network-access.html, February 2013. Appendix A. Acknowledgments The authors would like to thank Zach Shelby, Jan Holler, Salvatore Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes Tschofenig, and Anna Larmo for interesting discussions in this problem space. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Arkko, et al. Expires July 7, 2016 [Page 15] Internet-Draft Power-Efficient Cellular CoAP devices January 2016 Anders Eriksson Ericsson Stockholm 164 83 Sweden Email: anders.e.eriksson@ericsson.com Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Arkko, et al. Expires July 7, 2016 [Page 16] ./draft-ietf-mmusic-data-channel-sdpneg-28.txt0000644000764400076440000026343413465726550020503 0ustar iustyiusty MMUSIC K. Drage Internet-Draft Unaffiliated Intended status: Standards Track M. Makaraju Expires: November 12, 2019 Nokia R. Ejzak J. Marcon Unaffiliated R. Even, Ed. Huawei May 11, 2019 SDP-based Data Channel Negotiation draft-ietf-mmusic-data-channel-sdpneg-28 Abstract Data channel setup can be done using either the in-band Data Channel Establishment Protocol (DCEP) or using some out-of-band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 12, 2019. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Drage, et al. Expires November 12, 2019 [Page 1] Internet-Draft SDP-based Data Channel Negotiation May 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 5. SDP Data Channel Attributes . . . . . . . . . . . . . . . . . 6 5.1. SDP DCMAP Attribute . . . . . . . . . . . . . . . . . . . 6 5.1.1. DCMAP Attribute Syntax . . . . . . . . . . . . . . . 6 5.1.2. Dcmap-stream-id Parameter . . . . . . . . . . . . . . 8 5.1.3. Label Parameter . . . . . . . . . . . . . . . . . . . 8 5.1.4. Subprotocol Parameter . . . . . . . . . . . . . . . . 8 5.1.5. Max-retr Parameter . . . . . . . . . . . . . . . . . 9 5.1.6. Max-time Parameter . . . . . . . . . . . . . . . . . 9 5.1.7. Ordered Parameter . . . . . . . . . . . . . . . . . . 9 5.1.8. Priority Parameter . . . . . . . . . . . . . . . . . 10 5.1.9. DCMAP Multiplexing Category . . . . . . . . . . . . . 10 5.2. SDP DCSA Attribute . . . . . . . . . . . . . . . . . . . 10 5.2.1. DCSA Syntax . . . . . . . . . . . . . . . . . . . . . 11 5.2.2. DCSA Multiplexing Category . . . . . . . . . . . . . 12 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 13 6.1. Managing Stream Identifiers . . . . . . . . . . . . . . . 13 6.2. Negotiating Data Channel Parameters . . . . . . . . . . . 13 6.3. Generating the Initial Offer for A Data Channel . . . . . 14 6.4. Generating SDP Answer . . . . . . . . . . . . . . . . . . 14 6.5. Offerer Processing of the SDP Answer . . . . . . . . . . 15 6.6. Modifying the Session . . . . . . . . . . . . . . . . . . 15 6.6.1. Closing a Data Channel . . . . . . . . . . . . . . . 16 6.7. Various SDP Offer/Answer Considerations . . . . . . . . . 16 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.1. Subprotocol Identifiers . . . . . . . . . . . . . . . . . 20 9.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 20 9.2.1. dcmap . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. dcsa . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. CHANGE LOG . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-15' . . . . . . . . . . . . . . . . . . . . . . . 22 Drage, et al. Expires November 12, 2019 [Page 2] Internet-Draft SDP-based Data Channel Negotiation May 2019 12.2. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-14' . . . . . . . . . . . . . . . . . . . . . . . 22 12.3. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-12' . . . . . . . . . . . . . . . . . . . . . . . 22 12.4. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-11' . . . . . . . . . . . . . . . . . . . . . . . 22 12.5. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-10' . . . . . . . . . . . . . . . . . . . . . . . 22 12.6. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-09' . . . . . . . . . . . . . . . . . . . . . . . 22 12.7. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-08' . . . . . . . . . . . . . . . . . . . . . . . 23 12.8. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-07' . . . . . . . . . . . . . . . . . . . . . . . 24 12.9. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-06' . . . . . . . . . . . . . . . . . . . . . . . 24 12.10. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-05' . . . . . . . . . . . . . . . . . . . . . . . 24 12.11. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-04' . . . . . . . . . . . . . . . . . . . . . . . 25 12.12. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-03' . . . . . . . . . . . . . . . . . . . . . . . 26 12.13. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 27 12.14. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-01' . . . . . . . . . . . . . . . . . . . . . . . 28 12.15. Changes against 'draft-ietf-mmusic-data-channel- sdpneg-00' . . . . . . . . . . . . . . . . . . . . . . . 30 12.16. Changes against 'draft-ejzak-mmusic-data-channel- sdpneg-02' . . . . . . . . . . . . . . . . . . . . . . . 33 12.17. Changes against '-01' . . . . . . . . . . . . . . . . . 34 12.18. Changes against '-00' . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Generic Data Channel Negotiation Aspects When Not Using DCEP . . . . . . . . . . . . . . . . . . . . . 36 A.1. Stream Identifier Numbering . . . . . . . . . . . . . . . 37 A.2. Generic Data Channel Negotiation Not Using DCEP . . . . . 38 A.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 38 A.2.2. Opening a Data Channel . . . . . . . . . . . . . . . 38 A.2.3. Closing a Data Channel . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Drage, et al. Expires November 12, 2019 [Page 3] Internet-Draft SDP-based Data Channel Negotiation May 2019 1. Introduction The concept of establishing a bi-directional data channel running on top of the Stream Control Transmission Protocol (SCTP) is in [I-D.ietf-rtcweb-data-channel] allowing applications to use data channels. An in-band Data Channel Establishment Protocol (DCEP) is in [I-D.ietf-rtcweb-data-protocol], however other in-band or out-of- band protocols may be used for establishing data channels. Each data channel consists of paired SCTP streams sharing the same SCTP Stream Identifier. Data channels are created by endpoint applications using the WebRTC API (Application Programming Interface), or other protocols like CLUE [I-D.ietf-clue-datachannel]. The protocols can be signaled by the data channel "subprotocol" parameter, conceptually similar to the WebSocket [RFC5234] "subprotocol". However, apart from the "subprotocol" value transmitted to the peer, an endpoint application can agree on how to instantiate a given subprotocol on a data channel, and whether it is signaled in-band using DCEP or out- of-band using a non-DCEP protocol (or both). This document defines SDP offer/answer [RFC3264] procedures that enable out-of-band negotiation for establishing data channels for transport of well-defined subprotocols. These procedures are based on generic SDP offer/answer negotiation rules for SCTP based media transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. This document uses MSRP (Message Session Relay Protocol) [RFC4975] and BFCP (Binary Floor Control Protocol) [RFC4582] in many of the examples. It does not provide a complete specification of how to negotiate the use of a data channel to transport MSRP. Procedures specific to each subprotocol would have to be documented elsewhere. For MSRP they are documented in [I-D.ietf-mmusic-msrp-usage-data-channel] . The use of MSRP in some examples is only to show how the generic procedures described herein might apply to a specific subprotocol. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Drage, et al. Expires November 12, 2019 [Page 4] Internet-Draft SDP-based Data Channel Negotiation May 2019 3. Terminology This document uses the following terms: Data channel: A WebRTC data channel as specified in [I-D.ietf-rtcweb-data-channel]. Data channel stack: An entity which, upon application request, runs the data channel protocol to keep track of states, sending and receiving data. If the application is a browser based JavaScript application then this stack resides in the browser. If the application is a native application then this stack resides in the application and is accessible via some sort of APIs. Data channel properties: Fixed properties assigned to a data channel at the time of its creation. Some of these properties determine the way the data channel stack transmits data on this channel (e.g., stream identifier, reliability, order of delivery, etc.). Data channel subprotocol: The application protocol which is transported over a single data channel. Data channel subprotocol messages are sent as data channel payload over an established data channel. SDP offer/answer exchange can be used as specified in this document to negotiate the establishment of data channels, corresponding data channel properties, associated data channel subprotocols and data channel subprotocol properties. In this case the data channel subprotocols may be identified by the values of the "subprotocol" parameters of the SDP "a=dcmap" attribute as described in Section 5.1.4. Within this document the term "data channel subprotocol" is often abbreviated as just "subprotocol". DCEP: Data Channel Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol]. In-band: Transmission through the peer-to-peer SCTP association. Out-of-band: Transmission through the application signaling path. Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDP offerer. SCTP Stream Sequence Number (SSN): the SCTP stream sequence number as specified in [RFC4960]. Drage, et al. Expires November 12, 2019 [Page 5] Internet-Draft SDP-based Data Channel Negotiation May 2019 Stream identifier: The identifier of the outbound and inbound SCTP streams composing a data channel. 4. Applicability Statement The mechanism in this document only applies to the Session Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope for this document, and is thus undefined. 5. SDP Data Channel Attributes This section defines two new SDP media-level attributes that can be used together with the SDP Offer/Answer mechanism to negotiate data channel-specific and subprotocol-specific parameters without the usage of DCEP [I-D.ietf-rtcweb-data-protocol]. The first attribute provides for negotiation of channel-specific parameters. The second attribute provides for negotiation of subprotocol-specific parameters. Note: Appendix A provides information how data channels work in general and especially summarizes some key aspects, which should be considered for the negotiation of data channels if DCEP is not used. 5.1. SDP DCMAP Attribute This section defines a new media level attribute "a=dcmap:" that defines the data channel parameters for each data channel to be negotiated. The attribute is used to create bi-directional SCTP data channels having the same set of attributes. The data channel properties (reliable/partially reliable, ordered/unordered) need to be suitable per the subprotocol transport requirements. 5.1.1. DCMAP Attribute Syntax "a=dcmap:" is a media level attribute having the following ABNF (Augmented Backus-Naur Form, [RFC5234]) syntax. Formal Syntax: Name: dcmap Value: dcmap-value Usage Level: media Drage, et al. Expires November 12, 2019 [Page 6] Internet-Draft SDP-based Data Channel Negotiation May 2019 Charset Dependent: no Syntax: dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ] dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt / priority-opt ; maxretr-opt and maxtime-opt are mutually exclusive ; dcmap-stream-id = 1*5DIGIT ordering-opt = "ordered=" ordering-value ordering-value = "true" / "false" subprotocol-opt = "subprotocol=" quoted-string label-opt = "label=" quoted-string maxretr-opt = "max-retr=" maxretr-value maxretr-value = "0" / integer ; number of retransmissions, ; less than 2^32, ; derived from 'Reliability Parameter' of ; [I-D.ietf-rtcweb-data-protocol] maxtime-opt = "max-time=" maxtime-value maxtime-value = "0" / integer ; milliseconds, ; less than 2^32, ; derived from 'Reliability Parameter' of ; [I-D.ietf-rtcweb-data-protocol] priority-opt = "priority=" priority-value priority-value = "0" / integer ; unsigned integer value indicating the priority of ; the data channel, ; less than 2^16, ; derived from 'Priority' of ; [I-D.ietf-rtcweb-data-protocol] quoted-string = DQUOTE *(quoted-char / escaped-char) DQUOTE quoted-char = SP / quoted-visible quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % escaped-char = "%" HEXDIG HEXDIG DQUOTE = integer = Examples: a=dcmap:0 a=dcmap:1 subprotocol="bfcp";max-time=60000;priority=512 a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" Drage, et al. Expires November 12, 2019 [Page 7] Internet-Draft SDP-based Data Channel Negotiation May 2019 a=dcmap:3 label="Label 1";ordered=false;max-retr=5;priority=128 a=dcmap:4 label="foo%09bar";ordered=true;max-time=15000 Note: The last example (a=dcmap:4) shows a 'label' parameter value which contains one non-printable 'escaped-char' character (the tabulator character). Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter may be present. Both MUST NOT be present. 5.1.2. Dcmap-stream-id Parameter The 'dcmap-stream-id' parameter indicates the SCTP stream identifier within the SCTP association used to form the data channel. 5.1.3. Label Parameter The 'label' parameter indicates the name of the channel. It represents a label that can be used to distinguish, in the context of the WebRTC API [WebRtcAPI], an RTCDataChannel object from other RTCDataChannel objects. This parameter maps to the 'Label' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. In order to communicate with WEbRTC API the label attribute should: o Serialize the WebRTC label as a UTF-8 string [RFC3629]. o Treat the UTF-8 serialization as a series of bytes o For each byte in the serialization: * If the byte can be expressed as a `quoted-char`, do so * Otherwise, express the byte as an `escaped-char`. Note: The empty string MAY also be explicitly used as a 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Label' value to be an empty string. 5.1.4. Subprotocol Parameter The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. Drage, et al. Expires November 12, 2019 [Page 8] Internet-Draft SDP-based Data Channel Negotiation May 2019 Section 9.1 specifies how new subprotocol parameter values are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to an empty string. Note: The empty string MAY also be explicitly used as 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Subprotocol' value to be an empty string. 5.1.5. Max-retr Parameter This parameter indicates that the data channel is partially reliable. The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted. The max-retr parameter is optional. If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. This parameter maps to the 'Number of RTX' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 5.1.6. Max-time Parameter This parameter indicates that the data channel is partially reliable. A user message will no longer be transmitted or retransmitted after a specified life-time given in milliseconds in the 'max-time' parameter. The life-time starts when providing the user message to the protocol stack. The max-time parameter is optional. If the max- retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960]. This parameter maps to the 'Lifetime in ms' parameter defined in [I-D.ietf-rtcweb-data-protocol]. 5.1.7. Ordered Parameter The 'ordered' parameter with value "true" indicates that the receiver will dispatch DATA chunks in the data channel to the upper layer while preserving the order. The ordered parameter is optional and takes two values: "true" for ordered and "false" for unordered delivery with "true" as the default value. Any other value is ignored and default "ordered=true" is assumed. In the absence of this parameter "ordered=true" is assumed. This parameter maps to the ordered or unordered data channel types as defined in [I-D.ietf-rtcweb-data-protocol]. Drage, et al. Expires November 12, 2019 [Page 9] Internet-Draft SDP-based Data Channel Negotiation May 2019 5.1.8. Priority Parameter The 'priority' parameter indicates the data channel's priority relative to the priorities of other data channels, which may additionally exist over the same SCTP association. The 'priority' parameter maps to the 'Priority' parameter defined in [I-D.ietf-rtcweb-data-protocol]. The 'priority' parameter is optional. In the absence of this parameter "priority=256" is assumed. 5.1.9. DCMAP Multiplexing Category The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] of the "a=dcmap:" attribute is SPECIAL. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no "a=dcmap:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS association, or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcmap:" attribute need to be defined as well, for instance in an extension of this SDP offer/answer based data channel negotiation specification. 5.2. SDP DCSA Attribute In the SDP media description, each data channel declaration MAY also be followed by other media level SDP attributes, which are either specifically defined for or applied to the subprotocol in use. Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub)protocol in another IETF document. Subprotocol specific attributes MAY also be defined for exclusive use with data channel transport, but MUST use the same syntax described here for other subprotocol related attributes. Each SDP attribute, related to the subprotocol, that would normally be used to negotiate the subprotocol using SDP offer/answer is replaced with an attribute of the form "a=dcsa:stream-id original- attribute", where dcsa stands for "data channel subprotocol attribute", stream-id is the SCTP stream identifier assigned to this subprotocol instance, and original-attribute represents the contents of the subprotocol related attribute to be included. The same syntax applies to any other SDP attribute required for negotiation of this instance of the subprotocol. Drage, et al. Expires November 12, 2019 [Page 10] Internet-Draft SDP-based Data Channel Negotiation May 2019 The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA registration procedures for the WebSocket Subprotocol Name Registry (Section 9.1) do not strictly require a specification of the offer/ answer procedures for the sub-protocol when used with dcsa. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise- negotiable and applicable sub-protocol parameters. 5.2.1. DCSA Syntax Formal Syntax: Name: dcsa Value: dcsa-value Usage Level: media Charset Dependent: no Syntax: dcsa-value = stream-id SP attribute stream-id = 1*5DIGIT attribute = Example: a=dcmap:2 subprotocol="msrp";ordered=true;label="msrp" a=dcsa:2 accept-types:text/plain Note that the reference to [I-D.ietf-mmusic-rfc4566bis] defines where the attribute definition can be found; it does not provide any limitation on support of attributes defined in other documents in accordance with this attribute definition. Note however that not all SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA (Internet Assigned Numbers Authority) registered session and media level or media level only SDP attributes. Drage, et al. Expires November 12, 2019 [Page 11] Internet-Draft SDP-based Data Channel Negotiation May 2019 Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of the MSRP subprotocol being transported on the SCTP association using the data channel with stream id 2 accepts plain text files. As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answer negotiation following the procedures defined in the subprotocol specific documents. It is assumed that in general the usages of subprotocol related media level attributes are independent from the subprotocol's transport protocol. Such transport protocol independent subprotocol related attributes are used in the same way as defined in the original subprotocol specification, also if the subprotocol is transported over a data channel and if the attribute is correspondingly embedded in a "a=dcsa" attribute. There may be cases, where the usage of a subprotocol related media level attribute depends on the subprotocol's transport protocol. In such cases the subprotocol related usage of the attribute is expected to be described for the data channel transport. A data channel specific usage of a subprotocol attribute is expected to be specified in the same document that registers the subprotocol's identifier for data channel usage as described in Section 9.1. SDP attributes that are only defined for use at the dcsa usage level, SHALL use the dcsa usage level when registering the attribute. If existing media attributes are used in a datachannel subprotocol specific way, then a new dcsa usage level MUST be defined for the existing media attribute. Where the SDP attribute is applicable to a particular subprotocol/s this SHALL also be registered by indicating the applicable subprotocol identifiers (see /[I-D.ietf-mmusic-rfc4566bis] section-8.5) along with the dcsa usage level. 5.2.2. DCSA Multiplexing Category The multiplexing category of the "a=dcsa:" attribute is SPECIAL. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no "a=dcsa:" attribute multiplexing rules are specified for the UDP/DTLS/SCTP and TCP/DTLS/SCTP proto values. If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to negotiate multiplexing of multiple SCTP associations on top of a single DTLS association, or how to add multiple SCTP associations to one BUNDLE group, then multiplexing rules for the "a=dcsa:" attribute need to be defined as Drage, et al. Expires November 12, 2019 [Page 12] Internet-Draft SDP-based Data Channel Negotiation May 2019 well, for instance in an extension of this SDP based data channel negotiation specification. 6. SDP Offer/Answer Procedures This section defines how data channels can be negotiated using the SDP offer/answer mechanism. A given media description can describe multiple data channels (each represented by a separate SDP dcmap attribute) that can be created, modified and closed using different offer/answer exchanges. The procedures in this section apply for a given data channel. The generic offer/answer procedures for negotiating the SCTP association used to realize data channels are defined in [I-D.ietf-mmusic-sctp-sdp]. This section only defines the data channel specific procedures. "Initial offer" refers to the offer in which a data channel is opened. It can be the initial offer, or a subsequent offer, of the associated SDP session. The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol see Section 5.2. 6.1. Managing Stream Identifiers In order to avoid SCTP Stream identifier collisions, in alignment with [I-D.ietf-rtcweb-data-protocol], the endpoint acting as DTLS client (for the SCTP association used to realize data channels) MUST use even identifier values, and the endpoint acting as DTLS server MUST use odd identifier values. SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers. 6.2. Negotiating Data Channel Parameters The data channel types defined in [I-D.ietf-rtcweb-data-protocol] are mapped to the dcmap SDP attribute parameters in the following manner where "ordered=true" is the default and may be omitted: Drage, et al. Expires November 12, 2019 [Page 13] Internet-Draft SDP-based Data Channel Negotiation May 2019 DATA_CHANNEL_RELIABLE ordered=true DATA_CHANNEL_RELIABLE_UNORDERED ordered=false DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT ordered=true;max-retr= DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED ordered=false;max-retr= DATA_CHANNEL_PARTIAL_RELIABLE_TIMED ordered=true;max-time= DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED ordered=false;max-time= By definition max-retr and max-time are mutually exclusive, so both MUST NOT be present in the "a=dcmap:" attribute line. If an SDP offer contains both of these parameters then the receiver of such an SDP offer MUST reject the SDP offer. If an SDP answer contains both of these parameters then the offerer MUST treat the associated SDP offer/answer as failed. 6.3. Generating the Initial Offer for A Data Channel When an offerer sends an initial offer, in order to negotiate an SCTP stream for a data channel, the offerer: o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel; and o MAY include one or more SDP dcsa attributes (Section 5.2) associated with the data channel. The value of the stream-id part of each attribute SHALL match the dcmap-stream-id value of the dcmap attribute. 6.4. Generating SDP Answer When an answerer receives an offer that includes an "m=" section for an SCTP association, that describes an SCTP stream for a data channel, if the answerer accepts the data channel it: o SHALL include an SDP dcmap attribute (Section 5 and Section 6.2) associated with the data channel in the "m=" section representing the SCTP association used to realize the data channel. The value Drage, et al. Expires November 12, 2019 [Page 14] Internet-Draft SDP-based Data Channel Negotiation May 2019 of the dcmap-stream-id, max-retr and max-time values of the dcmap attribute SHALL be identical to the value used for the data channel in the offer; and o MAY include one or more SDP dcsa attributes (Section 5.2) associated with the data channel. 6.5. Offerer Processing of the SDP Answer An offerer receiving an SDP answer performs the following: o SHALL close any created data channels as described in Section 6.6.1 for which the expected "a=dcmap:" attributes are not present in the SDP answer. If the SDP answer has no "a=dcmap" attribute either the peer does not support "a=dcmap:" attributes or it rejected all the data channels. In either case the offerer closes all the SDP offered data channels that were open at the time of offer. The DTLS association and SCTP association will still be setup. At this point the offerer may use DCEP negotiation [I-D.ietf-rtcweb-data-protocol] to open data channels Each agent application MUST wait to send data until it has confirmation that the data channel at the peer is instantiated. For WebRTC, this is when both data channel stacks have channel parameters instantiated. This occurs: o At both peers when a data channel is created without a previously established SCTP association, as soon as the SCTP association is successfully established. o At the agent receiving an SDP offer for which there is an established SCTP association, as soon as it creates the negotiated data channel based on information signaled in the SDP offer. o At the agent sending an SDP offer to create a new data channel for which there is an established SCTP association, when it receives the SDP answer confirming acceptance of the data channel or when it begins to receive data on the data channel from the peer, whichever occurs first. 6.6. Modifying the Session When an offer sends a subsequent offer, that includes information for a previously negotiated data channel, unless the offerer intends to close the data channel (Section 6.6.1), the offerer SHALL include the previously negotiated SDP attributes and attribute values associated with the data channel. The answerer may reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. Drage, et al. Expires November 12, 2019 [Page 15] Internet-Draft SDP-based Data Channel Negotiation May 2019 The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer [RFC3264]. 6.6.1. Closing a Data Channel In order to close a data channel, the endpoint that wants to close SHALL send the SCTP SSN reset message [RFC6525], following the procedures in section 6.7 of [I-D.ietf-rtcweb-data-channel]. In addition, if the closed data channel was negotiated using the offer/ answer mechanism Section 6.3, the endpoint that closed the data channel SHALL send a subsequent offer in which it either: o removes the SDP dcmap attribute and SDP dcsa attributes associated with the closed data channel. Once the endpoint receives a successful answer, the SCTP stream identifier value can later be used for a new data channel (negotiated using DCTP or using the offer/answer mechanism); or o after a reset has been performed re-uses the SCTP stream used for the closed data channel for a new data channel, using the procedures in Section 6.3. The offerer SHALL use a different SDP dcmap attribute value for the data channel using the same SCTP stream. 6.7. Various SDP Offer/Answer Considerations An SDP offer or answer has no "a=dcmap:" attributes but has "a=dcsa:" attributes. * This is considered an error case. In this case the receiver of such an SDP offer or answer MUST discard this "a=dcsa:" attributes. SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is unknown. * The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line. SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose subprotocol attribute semantic is not known for the data channel transport case. * The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line. Drage, et al. Expires November 12, 2019 [Page 16] Internet-Draft SDP-based Data Channel Negotiation May 2019 7. Examples SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:0 subprotocol="bfcp";label="bfcp" SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::1 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 Figure 1: Example 1 In the example in Figure 1 the SDP answerer rejected the data channel with stream id 0 either for explicit reasons or because it does not understand the "a=dcmap:" attribute. As a result the offerer will close the data channel created with the SDP offer/answer negotiation option. The SCTP association will still be setup over DTLS. At this point the offerer or the answerer may use DCEP negotiation to open data channels. Drage, et al. Expires November 12, 2019 [Page 17] Internet-Draft SDP-based Data Channel Negotiation May 2019 SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:0 subprotocol="bfcp";label="bfcp" a=dcmap:2 subprotocol="msrp";label="msrp" a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 path:msrp://alice.example.com:10001/2s93i93idj;dc SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.2 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 a=dcmap:2 subprotocol="msrp";label="msrp" a=dcsa:2 accept-types:message/cpim text/plain a=dcsa:2 path:msrp://bob.example.com:10002/si438dsaodes;dc Figure 2: Example 2 In the example in Figure 2 the SDP offer contains data channels for BFCP (Binary Floor Control Protocol) and MSRP subprotocols. The SDP answer rejected BFCP and accepted MSRP. So, the offerer closes the data channel for BFCP and both offerer and answerer may start using the MSRP data channel (after the SCTP association is set up). The data channel with stream id 0 is free and can be used for future DCEP or SDP offer/answer negotiation. Continuing the example in Figure 2. Drage, et al. Expires November 12, 2019 [Page 18] Internet-Draft SDP-based Data Channel Negotiation May 2019 Subsequent SDP offer: m=application 10001 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=tls-id:abc3de65cddef001be82 a=dcmap:4 subprotocol="msrp";label="msrp" a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 path:msrp://alice.example.com:10001/2s93i93idj;dc Subsequent SDP answer: m=application 10002 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.2 a=max-message-size:100000 a=sctp-port:5002 a=setup:passive a=fingerprint:SHA-1 \ 5B:AD:67:B1:3E:82:AC:3B:90:02:B1:DF:12:5D:CA:6B:3F:E5:54:FA a=tls-id:dcb3ae65cddef0532d42 a=dcmap:4 subprotocol="msrp";label="msrp" a=dcsa:4 accept-types:message/cpim text/plain a=dcsa:4 path:msrp://bob.example.com:10002/si438dsaodes;dc Figure 3: Example 3 The example in Figure 3 is a continuation of the example in Figure 2. The SDP offerer now removes the MSRP data channel with stream id 2, but opens a new MSRP data channel with stream id 4. The answerer accepts the entire offer. As a result the offerer closes the earlier negotiated MSRP related data channel and both offerer and answerer may start using new the MSRP related data channel. 8. Security Considerations This document specifies new SDP attributes used in the negotiation of the DATA channel parameters. These parameter are negotiated as part of opening a SCTP channel over DTLS as specified in [I-D.ietf-mmusic-sctp-sdp]. Each subprotocol may come with it's own security considerations that need to be documented as part of the subprotocol definition. Otherwise this document does not add any security considerations to the ones specified in [I-D.ietf-mmusic-sctp-sdp] Drage, et al. Expires November 12, 2019 [Page 19] Internet-Draft SDP-based Data Channel Negotiation May 2019 Error cases like the use of unknown parameter values or violation the odd/even rule MUST be handled by closing the corresponding Data Channel. 9. IANA Considerations 9.1. Subprotocol Identifiers Registration of new subprotocol identifiers is performed using the existing IANA "WebSocket Subprotocol Name Registry" table. The following text should be added following the title of the table. "This table also includes subprotocol identifiers specified for usage within a WebRTC data channel." The following reference should be added to under the heading reference: "RFC XXXX". This document assigns no new values to this table. A subprotocol may simultaneously be defined for data channel transport and for Websocket transport. In such a case the "Subprotocol Definition" and "Reference" cells in the subprotocol's row of the IANA "WebSocket Subprotocol Name Registry" table should contain two entries. One entry in each of these cells should refer to the Websocket related subprotocol specification, and the other entry should refer to the data channel related subprotocol specification. NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. 9.2. New SDP Attributes 9.2.1. dcmap NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "a=dcmap:" as follows: Drage, et al. Expires November 12, 2019 [Page 20] Internet-Draft SDP-based Data Channel Negotiation May 2019 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | dcmap | | Attribute syntax: | As per Section 5.1.1 | | Attribute semantics: | As per Section 5.1.1 | | Usage level: | media | | Charset dependent: | No | | Purpose: | Define data channel specific parameters | | Appropriate values: | As per Section 5.1.1 | | O/A procedures: | As per Section 6 | | Mux category: | SPECIAL. See Section 5.1.9 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 9.2.2. dcsa NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC. This document defines a new SDP media-level attribute "a=dcsa:" as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | dcsa | | Attribute syntax: | As per Section 5.2.1 | | Attribute semantics: | As per Section 5.2.1 | | Usage level: | media | | Charset dependent: | No | | Purpose: | Define data channel subprotocol specific | | | attributes | | Appropriate values: | As per Section 5.2.1 | | O/A procedures: | As per Section 6 | | Mux category: | SPECIAL. See Section 5.2.2 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 10. Contributors Juergen Stoetzer-Bradler co-authored this document. 11. Acknowledgments The authors wish to acknowledge the borrowing of ideas from other internet drafts by Salvatore Loreto, Gonzalo Camarillo, Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Drage, et al. Expires November 12, 2019 [Page 21] Internet-Draft SDP-based Data Channel Negotiation May 2019 Groves, Gunnar Hellstrom, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach and Roman Shpount for their invaluable comments. Special thanks to Christer Holmberg for helping finish the document and cleaning the SDP offer/answer section. 12. CHANGE LOG 12.1. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-15' o Editorial changes separate sections for offer/answer procedures. o Update security section. 12.2. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-14' o Change "dtls-id" to "tls-id" and assign 20 octet long values o Remove of RFC4566bis draft from list of normative references. 12.3. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-12' o Modification of Keith's address information. 12.4. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-11' o dcmap-stream-id syntax change to limit size to 5 digits. o Add missing 'x' prefix to quoted-visible syntax. o Align SDP offerer and answerer handling when both max-retr and max-time are present. o Use of TEST-NET-1 ip addresses in examples. o Add missing a=dtls-id in one example. 12.5. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-10' o Removal of the "a=connection" attribute lines from all SDP examples. 12.6. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-09' o In the introduction: * Replacement of the sentence "The RTCWeb working group has defined the concept of bi-directional data channels running on Drage, et al. Expires November 12, 2019 [Page 22] Internet-Draft SDP-based Data Channel Negotiation May 2019 top of SCTP/DTLS (SCTP over the Datagram Transport Layer Security protocol)" with "The RTCWeb working group has defined the concept of bi-directional data channels running on top of the Stream Control Transmission Protocol (SCTP)". * Addition of following sentences to the second paragraph: "These procedures are based on generic SDP offer/answer negotiation rules for SCTP based media transport as specified in [I-D.ietf-mmusic-sctp-sdp] for the SDP "m" line proto values UDP/DTLS/SCTP and TCP/DTLS/SCTP. In the future, data channels could be defined over other SCTP based protocols, such as SCTP over IP. However, corresponding potential other "m" line proto values are not considered in this document." o Replacement of "DTLS connection" with "DTLS association" throughout the document. o In sections Section 5.1.9 and Section 5.2.2 removal of the sentences "This document also does not specify multiplexing rules for this attribute for SCTP or SCTP/DTLS proto values". o In the text related to "Subsequent SDP answer" in section Section 6.7 replacement of "The DTLS/SCTP association remains open ..." with "The SCTP association remains open ...". o In the text after the second SDP answer in section Section 7 replacement of "... (after SCTP/DTLS association is setup)" with "... (after the SCTP association is set up)". o Addition of draft-ietf-mmusic-dtls-sdp to the list of informative references. o Addition of "a=dtls-id" attribute lines to the SDP offer/answer examples in Section 7. 12.7. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-08' o Addition of definition of "data channel subprotocol" to Section 3 as proposed on the MMUSIC list, https://www.ietf.org/mail- archive/web/mmusic/current/msg15827.html. o Addition of RFC4566bis draft to list of normative references. o Updates of tables in Section 9.2.1 and Section 9.2.2 as per section 8.2.4 of RFC4566bis draft. o Addition of new "new-usage-level">. Drage, et al. Expires November 12, 2019 [Page 23] Internet-Draft SDP-based Data Channel Negotiation May 2019 12.8. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-07' o Addition of two new paragraphs to Section 5.2.1 regarding subprotocol attribute relationship with transport protocol. o Addition of a note to Section 9.1 regarding subprotocols simultaneously defined for data channel and Websocket usage. o Addition of two further SDP offer/answer considerations to Section 6.7 regarding unknown subprotocol attributes and known subprotocol attributes with unknown data channel transport related semantic. 12.9. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-06' o Changes addressing Christian Groves's WGLC review comments raised in http://www.ietf.org/mail-archive/web/mmusic/current/ msg15357.html and http://www.ietf.org/mail- archive/web/mmusic/current/msg15359.html. 12.10. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-05' o In IANA registration Section 9.2.1 and Section 9.2.2 replacement of contact name and e-mail address with "MMUSIC Chairs" and "mmusic-chairs@ietf.org". o In Section 5.2.1 replacement of "Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented by the attribute line "a=dcsa:2 accept-types:text/ plain", which specifies that this instance of MSRP being transported on the SCTP association using the data channel with stream id 2 accepts plain text files." with "... which specifies that this instance of the MSRP subprotocol being transported ...". o The last paragraph of Section 5.2.1 started with "Note: This document does not provide a complete specification ...". Removal of "Note:" and move of this paragraph to the introduction in Section 1 as last paragraph. o Section 5.2's headline was "Subprotocol Specific Attributes". Change of this headline to "Other Media Level Attributes" and adaptations of the first paragraph of this section and the first paragraph of Section 5.2.1 in order to clarify that not only those attributes may be encapsulated in a "dcsa" attribute, which are specifically defined for the subprotocol, but that also other attributes may be encapsulated if they are related to the specific subprotocol instance. Drage, et al. Expires November 12, 2019 [Page 24] Internet-Draft SDP-based Data Channel Negotiation May 2019 o Move of the last but one paragraph of Section 5.2.1 starting with "The same syntax applies to ..." right in front of the formal syntax definition of the "dcsa" attribute. o Modifications of the text in Section 5.1.9 and Section 5.2.2 in order not to explicitly restrict usage of the "a=dcmap:" and "a=dcsa:" attributes to "m" lines with proto values "UDP/DTLS/ SCTP" or "TCP/DTLS/SCTP". 12.11. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-04' o In Section 5.1.4 the first (and only) paragraph was "The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string." Replacement of this paragraph with following two paragraphs: * The 'subprotocol' parameter indicates which protocol the client expects to exchange via the channel. This parameter maps to the 'Protocol' parameter defined in [I-D.ietf-rtcweb-data-protocol]. Section 9.1 specifies how new subprotocol parameter values are registered. 'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string. * Note: The empty string MAY also be explicitly used as 'subprotocol' value, such that 'subprotocol=""' is equivalent to the 'subprotocol' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'subprotocol' value to be an empty string. o Addition of [I-D.ietf-mmusic-sdp-mux-attributes] to list the of normative references. o Addition of dcmap attribute specific IANA registration Section 9.2.1. o Addition of dcsa attribute specific IANA registration Section 9.2.2. o Addition of new Section 5.1.9 describing the mux category of the dcmap SDP attribute. This section and the new "a=dcsa:" attribute related mux category section are similar to the "Mux Category" sections of the "a=sctp-port:" and "a=max-message-size:" attributes in [I-D.ietf-mmusic-sctp-sdp]. Drage, et al. Expires November 12, 2019 [Page 25] Internet-Draft SDP-based Data Channel Negotiation May 2019 o Addition of new Section 5.2.2 describing the mux category of the dcsa SDP attribute. 12.12. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-03' o In Section 1 replacement of "RTCWeb leaves it open for other applications to use data channels and its in-band DCEP or out-of- band non-DCEP protocols for creating them" with "... to use data channels and its in-band DCEP or other in-band or out-of-band protocols for creating them". Additionally replacement of "In particular, the SDP offer generated by the application includes no channel-specific information" with "... generated by the RTCweb data channel stack includes no channel-specific information". o Move of former section 5 ("Data Channels") to new Appendix A and removal of JavaScript API specific discussions from this moved text (like mentioning of data channel stack specific states). Therefore former section 6 ("SDP Offer/Answer Negotiation") is now Section 5. o In Section 5: * Relacement of Section 5's first paragraph "This section defines a method of non-DCEP negotiation by which two clients can negotiate data channel-specific and subprotocol-specific parameters, using the out-of-band SDP offer/answer exchange. This SDP extension can only be used with the SDP offer/answer model." with "This section defines an SDP extension by which two clients can negotiate data channel-specific and subprotocol-specific parameters without using DCEP [I-D.ietf-rtcweb-data-protocol]. This SDP extension only defines usage in the context of SDP offer/answer." * Addition of new paragraph: "Appendix A provides information how data channels work in general and especially summarizes some key aspects, which should be considered for the negotiation of data channels if DCEP is not used." o In Section 5.1 replacement of "The intention of exchanging these attributes is to create data channels on both the peers with the same set of attributes without actually using the DCEP [I-D.ietf-rtcweb-data-protocol]" with "The intention in exchanging these attributes is to create, on two peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely directed data channels having the same set of attributes". o In Section 5.1.5 replacement of "The 'max-retr' parameter indicates the maximal number a user message will be retransmitted" Drage, et al. Expires November 12, 2019 [Page 26] Internet-Draft SDP-based Data Channel Negotiation May 2019 with "The 'max-retr' parameter indicates the maximal number of times a user message will be retransmitted". o In Section 6.1 replacement of "However, an SDP offer/answer exchange MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP" with "However, an SCTP stream MUST NOT be referenced in a dcmap or dcsa attribute of an SDP offer/ answer exchange if the associated SCTP stream has already been negotiated via DCEP". o In the examples in Section 7 addition of the previously missing colons to the "a=sctp-port" attribute lines. 12.13. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-02' o Move of reference draft-ietf-rtcweb-jsep from the list of normative references to the list of informative references. Remover in -07 since not referenced o Addition of IANA SDP parameters to the list of informative references and addition of following two sentences to the first paragraph after the ABNF definition: "Note however that not all SDP attributes are suitable as "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA registered session and media level or media level only SDP attributes." o In the introduction replacement of last sentence "This document defines SDP-based out-of-band negotiation procedures to establish data channels for transport of well-defined subprotocols" with "This document defines SDP offer/answer negotiation procedures to establish data channels for transport of well-defined subprotocols, to enable out-of-band negotiation". o Throughout the document replacement of "external negotiation" with "SDP offer/answer negotiation" and removal of term "external negotiation" from the terminology list in Section 3. o Throughout the document replacement of "internal negotiation" with "DCEP" and removal of terms "internal negotiation" and "in-band negotiation" from the terminology list in Section 3. o Addition of "SCTP Stream Sequence Number (SSN)" to the list of terms. o In Section 6.1 replacement of sentence "However, a single stream is managed using one method at a time." with "However, an SDP offer/answer exchange MUST NOT be initiated if the associated SCTP stream is already negotiated via DCEP". Drage, et al. Expires November 12, 2019 [Page 27] Internet-Draft SDP-based Data Channel Negotiation May 2019 o In Section 6.2 replacement of sentence "By definition max-retr and max-time are mutually exclusive, so only one of them can be present in a=dcmap" with "By definition max-retr and max-time are mutually exclusive, so aBoth MUST NOT be present in a=dcmap". o Move of reference [WebRtcAPI] from list of normative references to list of informative references. o Removal of almost all text parts, which discussed JavaScript or other API specific aspects. Such API specific aspects were mainly discussed in sub-sections of Section 5 and Section 5 of draft- ietf-mmusic-data-channel-sdpneg-02. 12.14. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-01' o New Section 4 regarding applicability to SDP offer/answer only. o Addition of new Section 9.1 "Subprotocol identifiers" as subsection of the "IANA Considerations" related Section 9. Also removal of the temporary note "To be completed. As [I-D.ietf- rtcweb-data-protocol] this document should refer to IANA's WebSocket Subprotocol Name Registry defined in [RFC6455]" o In Section 6.2: * In the first paragraph replacement of the sentence "If an SDP offer contains both of these parameters then such an SDP offer will be rejected." with "If an SDP offer contains both of these parameters then the receiver of such an SDP offer MUST reject the SDP offer." * In the second paragraph capitalization of "shall" and "may" such that both sentences now read: "The SDP answer SHALL echo the same subprotocol, max-retr, max-time, ordered parameters, if those were present in the offer, and MAY include a label parameter. They MAY appear in any order, which could be different from the SDP offer, in the SDP answer." * In the third paragraph replacement of the sentence "The same information MUST be replicated without changes in any subsequent offer or answer, as long as the data channel is still opened at the time of offer or answer generation." with "When sending a subsequent offer or an answer, and for as long as the data channel is still open, the sender MUST replicate the same information.". o In Section 6.2 the mapping of data channel types defined in [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute Drage, et al. Expires November 12, 2019 [Page 28] Internet-Draft SDP-based Data Channel Negotiation May 2019 parameters were illustrated using example "a=dcmap" attribute lines. Replacement of these example "a=dcmap" attribute lines with just the "a=dcmap" attribute parameters being relevant for the channel type. o In Section 6.7 the description of bullet point "SDP offer has no a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer: No data channel negotiated yet." Replacement of this description with "Initial SDP offer: No data channel is negotiated yet. The DTLS connection and SCTP association is negotiated and, if agreed, established as per [I-D.ietf-mmusic-sctp-sdp]." o In Section 6.7 in both bullet points related to "Subsequent SDP offer" and "Subsequent SDP answer" replacement of "All the externally negotiated data channels must be closed now." with "All the externally negotiated data channels are expected to be closed now.". o In Appendix A.2.2's sixth paragraph replacement of the two occurrences of "must" with "MUST". o In Section 5.1.1 in the definition of the ABNF rule "dcmap-opt" there was a comment saying that "Only maxretr-opt or maxtime-opt is present. Both MUST NOT be present." Removal of the second normative sentence and instead addition of following new paragraph to the end of this section: "Within an 'a=dcmap' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter is present. Both MUST NOT be present." o In Section 5.1.7 replacement of the first sentence "The 'ordered' parameter with value "true" indicates that DATA chunks in the channel MUST be dispatched to the upper layer by the receiver while preserving the order." with "The 'ordered' parameter with value "true" indicates that the receiver MUST dispatch DATA chunks in the data channel to the upper layer while preserving the order.". o In Section 6.3's first paragraph replacement of the one occurrence of "must" with "..., it MUST wait until ...". o In Section 6.6.1: * In the second paragraph replacement of "must" with "... whether this closing MUST in addition ..." * In the third paragraph replacement of the sentence "The port value for the "m" line SHOULD NOT be changed (e.g., to zero) when closing a data channel ..." with "The offerer SHOULD NOT Drage, et al. Expires November 12, 2019 [Page 29] Internet-Draft SDP-based Data Channel Negotiation May 2019 change the port value for the "m" line (e.g., to zero) when closing a data channel ...". * In the last but two paragraph replacement of the sentence "... then an SDP offer which excludes this closed data channel SHOULD be generated." with "... then the client SHOULD generate an SDP offer which excludes this closed data channel.". * In the last but one paragraph replacement of "must" with "The application MUST also close...". o In Section 5.2 addition of following note after the formal definition of the 'a=dcsa' attribute: "Note that the above reference to RFC 4566 defines were the attribute definition can be found; it does not provide any limitation on support of attributes defined in other documents in accordance with this attribute definition." 12.15. Changes against 'draft-ietf-mmusic-data-channel-sdpneg-00' o In Section 3 "WebRTC data channel" was defined as "A bidirectional channel consisting of paired SCTP outbound and inbound streams." Replacement of this definition with "Data channel: A WebRTC data channel as specified in [I-D.ietf-rtcweb-data-channel]", and consistent usage of "data channel" in the remainder of the document including the document's headline." o In Section 5 removal of following note: 'OPEN ISSUE: The syntax in [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses. In particular we expect "webrtc-datachannel" to become a more general term.' o Consistent usage of '"m" line' in whole document as per RFC4566. o In Section 5.1 removal of the example dcmap attribute line 'a=dcmap:2 subprotocol="bfcp";label="channel 2' as there are already four examples right after the ABNF rules in Section 5.1.1. Corresponding removal of following related note: "Note: This document does not provide a complete specification of how to negotiate the use of a WebRTC data channel to transport BFCP. Procedures specific to each subprotocol such as BFCP will be documented elsewhere. The use of BFCP is only an example of how the generic procedures described herein might apply to a specific subprotocol." o In Section 5.1 removal of following note: "Note: This attribute is derived from attribute "webrtc-DataChannel", which was defined in old version 03 of the following draft, but which was removed along Drage, et al. Expires November 12, 2019 [Page 30] Internet-Draft SDP-based Data Channel Negotiation May 2019 with any support for SDP external negotiation in subsequent versions: [I-D.ietf-mmusic-sctp-sdp]." o Insertion of following new sentence to the beginning of Section 5.1.1: "dcmap is a media level attribute having following ABNF syntax:" o Insertion of new Section 5.1.2 containing the dcmap-stream-id specifying sentence, which previously was placed right before the formal ABNF rules. Removal of the sentence 'Stream is a mandatory parameter and is noted directly after the "a=dcmap:" attribute's colon' as this information is part of the ABNF specification. o In Section 5.1.1 modification of the 'ordering-value' values from "0" or "1" to "true" or "false". Corresponding text modifications in Section 5.1.7. o In Section 5.1.1 the ABNF definition of "quoted-string" referred to rule name "escaped-char", which was not defined. Instead a rule with name "escaped" was defined. Renamed that rule's name to "escaped-char". o Insertion of a dedicated note right after the "a=dcmap:4" attribute example in Section 5.1.1 regarding the non-printable "escaped-char" character within the "label" value. o In Section 5.2's second paragraph replacement of "sctp stream identifier" with "SCTP stream identifier". o In first paragraph of Section 6.1 replacement of first two sentences 'For the SDP-based external negotiation described in this document, the initial offerer based "SCTP over DTLS" owns by convention the even stream identifiers whereas the initial answerer owns the odd stream identifiers. This ownership is invariant for the whole lifetime of the signaling session, e.g. it does not change if the initial answerer sends a new offer to the initial offerer.' with 'If an SDP offer/answer exchange (could be the initial or a subsequent one) results in a UDP/DTLS/SCTP or TCP/DTLS/SCTP based media description being accepted, and if this SDP offer/answer exchange results in the establishment of a new SCTP association, then the SDP offerer owns the even SCTP stream ids of this new SCTP association and the answerer owns the odd SCTP stream identifiers. If this "m" line is removed from the signaling session (its port number set to zero), and if usage of this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is renegotiated later on, then the even and odd SCTP stream identifier ownership is redetermined as well as described above.' Drage, et al. Expires November 12, 2019 [Page 31] Internet-Draft SDP-based Data Channel Negotiation May 2019 o In Section 6.3 the first action of an SDP answerer, when receiving an SDP offer, was described as "Applies the SDP offer. Note that the browser ignores data channel specific attributes in the SDP." Replacement of these two sentences with "Parses and applies the SDP offer. Note that the typical parser normally ignores unknown SDP attributes, which includes data channel related attributes." o In Section 6.3 the second sentence of the third SDP answerer action was "Note that the browser is asked to create data channels with stream identifiers not "owned" by the agent.". Replacement of this sentence with "Note that the agent is asked to create data channels with SCTP stream identifiers contained in the SDP offer if the SDP offer is accepted." o In Section 6.6.1 the third paragraph began with "A data channel can be closed by sending a new SDP offer which excludes the dcmap and dcsa attribute lines for the data channel. The port value for the m line SHOULD NOT be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST also exclude the corresponding attribute lines in the answer. ..." Replacement of this part with "The intention to close a data channel can be signaled by sending a new SDP offer which excludes the "a=dcmap:" and "a=dcsa:" attribute lines for the data channel. The port value for the "m" line SHOULD NOT be changed (e.g., to zero) when closing a data channel (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. If the answerer accepts the SDP offer then it MUST close those data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were excluded from the received SDP offer, unless those data channels were already closed, and it MUST also exclude the corresponding attribute lines in the answer." o In Section 6.6.1 the hanging text after the third paragraph was "This delayed close is to handle cases where a successful SDP answer is not received, in which case the state of session should be kept per the last successful SDP offer/answer." Replacement of this sentence with "This delayed closure is RECOMMENDED in order to handle cases where a successful SDP answer is not received, in which case the state of the session SHOULD be kept per the last successful SDP offer/answer." o Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects Section 5.1 contained already procedural descriptions related to data channel reliability negotiation. Creation of new Section 6.2 Drage, et al. Expires November 12, 2019 [Page 32] Internet-Draft SDP-based Data Channel Negotiation May 2019 and moval of reliability negotiation related text to this new section. 12.16. Changes against 'draft-ejzak-mmusic-data-channel-sdpneg-02' o Removal of note "ACTION ITEM" from section "subprotocol parameter". As [I-D.ietf-rtcweb-data-protocol] this document should refer to IANA's WebSocket Subprotocol Name Registry defined in [RFC6455] o In whole document, replacement of "unreliable" with "partially reliable", which is used in [I-D.ietf-rtcweb-data-channel] and in [I-D.ietf-rtcweb-data-protocol] in most places. o Clarification of the semantic if the "max-retr" parameter is not present in an "a=dcmap" attribute line. In section "max-retr parameter" the sentence "The max-retr parameter is optional with default value unbounded" was replaced with "The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in [RFC4960]". o Clarification of the semantic if the "max-time" parameter is not present in an "a=dcmap" attribute line. In section "max-time parameter" the sentence "The max-time parameter is optional with default value unbounded" was replaced with "The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in [RFC4960]". o In section "label parameter" the sentence "Label is a mandatory parameter." was removed and following new sentences (including the note) were added: "The 'label' parameter is optional. If it is not present, then its value defaults to the empty string. Note: The empty string may also be explicitly used as 'label' value, such that 'label=""' is equivalent to the 'label' parameter not being present at all. [I-D.ietf-rtcweb-data-protocol] allows the DATA_CHANNEL_OPEN message's 'Label' value to be an empty string." o In section "subprotocol parameter" the sentence "subprotocol is a mandatory parameter." was replaced with "'subprotocol' is an optional parameter. If the 'subprotocol' parameter is not present, then its value defaults to the empty string." o In the "Examples" section, in the first two SDP offer examples in the "a=dcmap" attribute lines 'label="BGCP"' was replaced with 'label="bfcp"'. Drage, et al. Expires November 12, 2019 [Page 33] Internet-Draft SDP-based Data Channel Negotiation May 2019 o In all examples, the "m" line proto value "DTLS/SCTP" was replaced with "UDP/DTLS/SCTP" and the "a=fmtp" attribute lines were replaced with "a=max-message-size" attribute lines, as per draft- ietf-mmusic-sctp-sdp-12. 12.17. Changes against '-01' o Formal syntax for dcmap and dcsa attribute lines. o Making subprotocol as an optional parameter in dcmap. o Specifying disallowed parameter combinations for max-time and max- retr. o Clarifications on WebRTC data channel close procedures. 12.18. Changes against '-00' o Revisions to identify difference between internal and external negotiation and their usage. o Introduction of more generic terminology, e.g. "application" instead of "browser". o Clarification of how "max-retr and max-time affect the usage of unreliable and reliable WebRTC data channels. o Updates of examples to take into account the SDP syntax changes introduced with draft-ietf-mmusic-sctp-sdp-07. o Removal of the SCTP port number from the "a=dcmap" and "a=dcsa" attributes as this is now contained in the a=sctp-port attribute, and as draft-ietf-mmusic-sctp-sdp-07 supports only one SCTP association on top of the DTLS connection. 13. References 13.1. Normative References [I-D.ietf-mmusic-rfc4566bis] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", draft-ietf-mmusic- rfc4566bis-32 (work in progress), December 2018. Drage, et al. Expires November 12, 2019 [Page 34] Internet-Draft SDP-based Data Channel Negotiation May 2019 [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Drage, et al. Expires November 12, 2019 [Page 35] Internet-Draft SDP-based Data Channel Negotiation May 2019 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf- clue-datachannel-18 (work in progress), April 2019. [I-D.ietf-mmusic-msrp-usage-data-channel] Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Marcon, J., and J. Recio, "MSRP over Data Channels", draft-ietf-mmusic-msrp-usage-data-channel-10 (work in progress), April 2019. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, DOI 10.17487/RFC4582, November 2006, . [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [WebRtcAPI] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium CR CR-webrtc-20180927, September 2018, . Appendix A. Generic Data Channel Negotiation Aspects When Not Using DCEP This appendix summarizes how data channels work in general and discusses some key aspects, which should be considered for the out- of-band negotiation of data channels if DCEP is not used. Drage, et al. Expires November 12, 2019 [Page 36] Internet-Draft SDP-based Data Channel Negotiation May 2019 A WebRTC application creates a data channel by providing a number of setup parameters (subprotocol, label, maximal number of retransmissions, maximal retransmission time, order of delivery, priority). The application also specifies if it wants to make use of the negotiation using the DCEP [I-D.ietf-rtcweb-data-protocol], or if the application intends to negotiate data channels using the SDP offer/answer protocol. In any case, the SDP offer generated by the application is per [I-D.ietf-mmusic-sctp-sdp]. In brief, it contains one "m" line for the SCTP association on top of which data channels will run: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.1 a=max-message-size:100000 a=sctp-port:5000 a=tls-id:abc3de65cddef001be82 a=setup:actpass a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB Note: A WebRTC application will only use "m" line format "webrtc- datachannel", and will not use other formats in the "m" line for other protocols such as t38. [I-D.ietf-mmusic-sctp-sdp] supports only one SCTP association to be established on top of a DTLS association. Note: The above SDP media description does not contain any channel- specific information. A.1. Stream Identifier Numbering Independently from the requested type of negotiation, the application creating a data channel can either pass the stream identifier to the data channel stack to assign to the data channel or else let the data channel stack pick one identifier from the unused ones. To avoid glare situations [RFC3264], each endpoint can moreover own an exclusive set of stream identifiers, in which case an endpoint can only create a data channel with a stream identifier it owns. Which set of stream identifiers is owned by which endpoint is determined by convention or other means. Note:For data channels negotiated with the DCEP, one endpoint owns by convention the even stream identifiers, whereas the other owns the odd stream identifiers, as defined in [I-D.ietf-rtcweb-data-protocol]. Drage, et al. Expires November 12, 2019 [Page 37] Internet-Draft SDP-based Data Channel Negotiation May 2019 Note:For data channels negotiated via different protocol from DCEP, no convention is defined by default. A.2. Generic Data Channel Negotiation Not Using DCEP A.2.1. Overview DCEP negotiation only provides for negotiation of data channel transport parameters and does not provide for negotiation of subprotocol specific parameters. DCEP-less data channel negotiation can be defined to allow negotiation of parameters beyond those handled by DCEP, e.g., parameters specific to the subprotocol instantiated on a particular data channel. The following procedures are common to all methods of data channel negotiation not using DCEP, whether in-band (communicated using proprietary means on an already established data channel) or out-of- band (using SDP offer/answer or some other protocol associated with the signaling channel). A.2.2. Opening a Data Channel In the case of DCEP-less negotiation, the endpoint application has the option to fully control the stream identifier assignments. However these assignments have to coexist with the assignments controlled by the data channel stack for the DCEP negotiated data channels (if any). It is the responsibility of the application to ensure consistent assignment of stream identifiers. When the application requests the creation of a new data channel to be set up via DCEP-less negotiation, the data channel stack creates the data channel locally without sending any DATA_CHANNEL_OPEN message in-band. However, even if the ICE (Interactive Connectivity Establishment), DTLS and SCTP procedures were already successfully completed, the application can't send data on this data channel until the negotiation is complete with the peer. This is because the peer needs to be aware of and accept the usage of this data channel. The peer, after accepting the data channel offer, can start sending data immediately. This implies that the offerer may receive data channel subprotocol messages before the negotiation is complete and the application should be ready to handle it. If the peer rejects the data channel part of the offer then it doesn't have to do anything as the data channel was not created using the stack. The offerer on the other hand needs to close the data channel that was opened by invoking relevant data channel stack API procedures. Drage, et al. Expires November 12, 2019 [Page 38] Internet-Draft SDP-based Data Channel Negotiation May 2019 It is also worth noting that a data channel stack implementation may not provide any API to create and close data channels; instead the data channels may be used on the fly as needed just by communicating via non-DCEP means or by even having some local configuration/ assumptions on both the peers. The application then negotiates the data channel properties and subprotocol properties with the peer's application using a mechanism different from DCEP. The peer then symmetrically creates a data channel with these negotiated data channel properties. This is the only way for the peer's data channel stack to know which properties to apply when transmitting data on this channel. The data channel stack must allow data channel creation with any non-conflicting stream identifier so that both peers can create the data channel with the same stream identifier. A.2.3. Closing a Data Channel When the application requests the closing of a data channel negotiated without DCEP, the data channel stack always performs an SCTP SSN reset for this channel. Depending upon the method used for DCEP-less negotiation and the subprotocol associated with the data channel, the closing might in addition be signaled to the peer via SDP offer/answer negotiation. Authors' Addresses Keith Drage Unaffiliated Email: drageke@ntlworld.com Maridi R. Makaraju (Raju) Nokia 2000 Lucent Lane Naperville, Illinois US Email: Raju.Makaraju@nokia.com Drage, et al. Expires November 12, 2019 [Page 39] Internet-Draft SDP-based Data Channel Negotiation May 2019 Richard Ejzak Unaffiliated Email: richard.ejzak@gmail.com Jerome Marcon Unaffiliated Email: jeromee.marcon@free.fr Roni Even (editor) Huawei Email: roni.even@huawei.com Drage, et al. Expires November 12, 2019 [Page 40] ./draft-ietf-mmusic-dtls-sdp-32.txt0000644000764400076440000016124613175541414016421 0ustar iustyiusty Network Working Group C. Holmberg Internet-Draft Ericsson Updates: 5763,7345 (if approved) R. Shpount Intended status: Standards Track TurboBridge Expires: May 2, 2018 October 29, 2017 Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) draft-ietf-mmusic-dtls-sdp-32.txt Abstract This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFC 4145 and RFC 8122. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 2, 2018. Holmberg & Shpount Expires May 2, 2018 [Page 1] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Copyright Notice Copyright (c) 2017 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 (https://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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Establishing a new DTLS Association . . . . . . . . . . . . . 4 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Change of Local Transport Parameters . . . . . . . . . . 5 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5 4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 10 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 9.2.1. Update to section 1 . . . . . . . . . . . . . . . . . 14 9.2.2. Update to section 5 . . . . . . . . . . . . . . . . . 15 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 Holmberg & Shpount Expires May 2, 2018 [Page 2] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction [RFC5763] defines Session Description Protocol (SDP) offer/answer procedures for Secure Realtime Transport Protocol Using Datagram Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/ answer procedures for UDP Transport Layer over Datagram Transport Layer Security (UDPTL-DTLS). This specification defines general offer/answer procedures for DTLS, based on the procedures in [RFC5763]. Other specifications, defining specific DTLS usages, can then reference this specification, in order to ensure that the DTLS aspects are common among all usages. Having common procedures is essential when multiple usages share the same DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. The document updates [RFC5763] and [RFC7345], by replacing common SDP offer/answer procedures with a reference to this specification. NOTE: Since the publication of [RFC5763], [RFC4474] has been obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the references (and the associated procedures) within [RFC5763] is outside the scope of this document. However, implementers of [RFC5763] applications are encouraged to implement [I-D.ietf-stir-rfc4474bis] instead of [RFC4474]. As defined in [RFC5763], a new DTLS association MUST be established when transport parameters are changed. Transport parameter change is not well defined when Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change, but the ufrag value is changed both when ICE is negotiated and when ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not always require a new DTLS association to be established, but previously there was no way to explicitly indicate in an SDP offer or answer whether a new DTLS association is required. To solve that problem, this document defines a new SDP attribute, 'tls-id'. The pair of SDP 'tls-id' attribute values (the attribute values of the offerer and the answerer) uniquely identifies the DTLS association. Providing a new value of the 'tls-id' attribute in an SDP offer or answers can be used to indicate whether a new DTLS association is to be established. The SDP 'tls-id' attribute can be specified when negotiating a Transport Layer Security (TLS) connection, using the procedures in this document in conjunction with the procedures in [RFC5763] and Holmberg & Shpount Expires May 2, 2018 [Page 3] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 [RFC8122]. The unique combination of SDP 'tls-id' attribute values can be used to identity the negotiated TLS connection. The unique value can be used, for example, within TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/answer exchanges. The TLS specific considerations are described in Section 7. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Establishing a new DTLS Association 3.1. General A new DTLS association must be established between two endpoints after a successful SDP offer/answer exchange in the following cases: o The negotiated DTLS setup roles change; or o One or more fingerprint values are modified, added or removed in either an SDP offer or answer; or o The intent to establish a new DTLS association is explicitly signaled using SDP, by changing the value of the SDP 'tls-id' attribute defined in this document; NOTE: The first two items above are based on the procedures in [RFC5763]. This specification adds the support for explicit signaling using the SDP 'tls-id' attribute. A new DTLS association can only be established as a result of the successful SDP offer/answer exchange. Whenever an entity determines that a new DTLS association is required, the entity MUST initiate an SDP offer/answer exchange, following the procedures in Section 5. The sections below describe typical cases where a new DTLS association needs to be established. In this document, a "new DTLS association" between two endpoints refers to either an initial DTLS association (when no DTLS association is currently established between the endpoints) or an DTLS association replacing a previously established DTLS association. Holmberg & Shpount Expires May 2, 2018 [Page 4] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 3.2. Change of Local Transport Parameters If an endpoint modifies its local transport parameters (address and/ or port), and if the modification requires a new DTLS association, the endpoint MUST change its local SDP 'tls-id' attribute value (see Section 4). If the underlying transport protocol prohibits a DTLS association from spanning multiple 5-tuples (transport/source address/source port/destination address/destination port), and if the 5-tuple is changed, the endpoint MUST change its local SDP 'tls-id' attribute value (see Section 4). An example of such a case is when DTLS is carried over the Stream Control Transmission Protocol (SCTP), as described in [RFC6083]. 3.3. Change of ICE ufrag value If an endpoint uses ICE, and modifies a local ufrag value, and if the modification requires a new DTLS association, the endpoint MUST change its local SDP 'tls-id' attribute value (see Section 4). 4. SDP tls-id Attribute The pair of SDP 'tls-id' attribute values (the attribute values of the offerer and the answerer) uniquely identifies the DTLS association or TLS connection. Holmberg & Shpount Expires May 2, 2018 [Page 5] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Name: tls-id Value: tls-id-value Usage Level: media Charset Dependent: no Default Value: N/A Syntax: tls-id-value = 20*255(tls-id-char) tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" Example: a=tls-id:abc3de65cddef001be82 Every time an endpoint requests to establish a new DTLS association, the endpoint MUST generate a new local 'tls-id' attribute value. A non-changed local 'tls-id' attribute value, in combination with non- changed fingerprints, indicates that the endpoint intends to reuse the existing DTLS association. The 'tls-id' attribute value MUST be generated using a strong random function and include at least 120 bits of randomness. No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters Holmberg & Shpount Expires May 2, 2018 [Page 6] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 NOTE: A modification of the ufrag value is not treated as an indication that an endpoint wants to establish a new DTLS assocation. In order to indicate that a new DTLS association is to be established, one or more of the characteristics listed above have to be modified. The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value applies to all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], in order to avoid duplication the attribute is only associated with the "m=" line representing the offerer/answerer BUNDLE-tag. For RTP-based media, the 'tls-id' attribute applies to the whole associated media description. The attribute MUST NOT be defined per source (using the SDP 'ssrc' attribute [RFC5576]). The SDP offer/answer [RFC3264] procedures associated with the attribute are defined in Section 5. 5. SDP Offer/Answer Procedures 5.1. General This section defines the generic SDP offer/answer procedures for negotiating a DTLS association. Additional procedures (e.g., regarding usage of specific SDP attributes etc.) for individual DTLS usages (e.g., DTLS-SRTP) are outside the scope of this specification, and need to be specified in a usage specific specification. NOTE: The procedures in this section are generalizations of procedures first specified in DTLS-SRTP [RFC5763], with the addition of usage of the SDP 'tls-id' attribute. That document is herein updated to make use of these new procedures. The procedures in this section apply to an SDP media description ("m=" line) associated with DTLS-protected media/data. When an offerer or answerer indicates that it wants to establish a new DTLS association, it needs to make sure that media packets associated with any previously established DTLS association and the new DTLS association can be de-multiplexed. In case of an ordered transport (e.g., SCTP) this can be done simply by sending packets for the new DTLS association after all packets associated with a previously established DTLS association has been sent. In case of an unordered transport, such as UDP, packets associated with a previously established DTLS association can arrive after the answer Holmberg & Shpount Expires May 2, 2018 [Page 7] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 SDP was received and after the first packets associated with the new DTLS association were received. The only way to de-multiplex packets associated with with a previously established DTLS association and the new DTLS association is on the basis of the 5-tuple. Because of this, if an unordered transport is used for the DTLS association, a new 3-tuple (transport/source address/source port) MUST be allocated by at least one of the endpoints so that DTLS packets can be de- multiplexed. When an offerer needs to establish a new DTLS association, and if an unordered transport (e.g., UDP) is used, the offerer MUST allocate a new 3-tuple for the offer in such a way that the offerer can disambiguate any packets associated with the new DTLS association from any packets associated with any other DTLS association. This typically means using a local address and/or port, or a set of ICE candidates (see Section 6), which were not recently used for any other DTLS association. When an answerer needs to establish a new DTLS association, if an unordered transport is used, and if the offerer did not allocate a new 3-tuple, the answerer MUST allocate a new 3-tuple for the answer in such a way that it can disambiguate any packets associated with the new DTLS association from any packets associated with any other DTLS association. This typically means using a local address and/or port, or a set of ICE candidates (see Section 6), which were not recently used for any other DTLS association. In order to negotiate a DTLS association, the following SDP attributes are used: o The SDP 'setup' attribute, defined in [RFC4145], is used to negotiate the DTLS roles; o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to provide one or more fingerprint values; and o The SDP 'tls-id' attribute, defined in this specification, is used to identity the DTLS association. This specification does not define the usage of the SDP 'connection' attribute [RFC4145] for negotiating a DTLS association. However, the attribute MAY be used if the DTLS association is used together with another protocol (e.g., SCTP or TCP) for which the usage of the attribute has been defined. Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP 'setup' attribute 'holdconn' value when negotiating a DTLS association. Holmberg & Shpount Expires May 2, 2018 [Page 8] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Endpoints MUST support the hash functions as defined in [RFC8122]. The certificate received during the DTLS handshake [RFC6347] MUST match a certificate fingerprint received in SDP 'fingerprint' attributes according to the procedures defined in [RFC8122]. If fingerprints do not match the hashed certificate, then an endpoint MUST tear down the media session immediately (see [RFC8122]). SDP offerers and answerers might reuse certificates across multiple DTLS associations, and provide identical fingerprint values for each DTLS association. The combination of the SDP 'tls-id' attribute values of the SDP offerer and answerer identifies each individual DTLS association. NOTE: There are cases where the SDP 'tls-id' attribute value generated by the offerer will end up being used for multiple DTLS associations. For that reason the combination of the attribute values of the offerer and answerer is needed in order to identity a DTLS association. An example of such case is where the offerer sends an updated offer (Section 5.5), without modifying its attribute value, but the answerer determines that a new DTLS association is to be created. The answerer will generate a new local attribute value for the new DTLS association (Section 5.3), while the offerer will use the same attribute value that it used for the current association. Another example is when the Session Initiation Protocol (SIP) [RFC3261] is used for signalling, and an offer is forked to multiple answerers. The attribute value generated by the offerer will be used for DTLS associations established by each answerer. 5.2. Generating the Initial SDP Offer When an offerer sends the initial offer, the offerer MUST insert an SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique attribute value. As the offerer inserts the SDP 'setup' attribute with an 'actpass' attribute value, the offerer MUST be prepared to receive a DTLS ClientHello message [RFC6347] (if a new DTLS association is established by the answerer) from the answerer before the offerer receives the SDP answer. If the offerer receives a DTLS ClientHello message, and a DTLS association is established, before the offerer receives the SDP Answer carrying the fingerprint associated with the DTLS association, any data received on the DTLS association before the fingerprint MUST be considered coming from an unverified source. The processing of Holmberg & Shpount Expires May 2, 2018 [Page 9] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 such data, and sending of data by the offerer to the unverified source, is outside the scope of this document. 5.3. Generating the Answer When an answerer sends an answer, the answerer MUST insert in the answer an SDP 'setup' attribute according to the procedures in [RFC4145], and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. If the answerer determines, based on the criteria specified in Section 3.1, that a new DTLS association is to be established, the answerer MUST insert in the associated answer an SDP 'tls-id' attribute with a new unique attribute value. Note that the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association. If the answerer receives an offer that requires establishment of a new DTLS association, and if the answerer does not accept the establishment of a new DTLS association, the answerer MUST reject the "m=" lines associated with the suggested DTLS association [RFC3264]. If an answerer receives an offer that does not require the establishment of a new DTLS association, and if the answerer determines that a new DTLS association is not to be established, the answerer MUST insert an SDP 'tls-id' attribute with the previously assigned attribute value in the associated answer. In addition, the answerer MUST insert an SDP 'setup' attribute with an attribute value that does not change the previously negotiated DTLS roles, and one or more SDP 'fingerprint' attributes values that do not change the previously sent fingerprint set, in the associated answer. If the answerer receives an offer that does not contain an SDP 'tls- id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in the answer. If a new DTLS association is to be established, and if the answerer inserts an SDP 'setup' attribute with an 'active' attribute value in the answer, the answerer MUST initiate a DTLS handshake [RFC6347]) by sending a DTLS ClientHello message towards the offerer. Even though an offerer is required to insert an 'SDP' setup attribute with an 'actpass' attribute value in initial offers (Section 5.2) and subsequent offers (Section 5.5), the answerer MUST be able to receive initial and subsequent offers with other attribute values, in order to be backward compatible with older implementations that might insert other attribute values in initial and subsequent offers. Holmberg & Shpount Expires May 2, 2018 [Page 10] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 5.4. Offerer Processing of the SDP Answer When an offerer receives an answer that establishes a new DTLS association based on criteria defined in Section 3.1, and if the offerer becomes DTLS client (based on the value of the SDP 'setup' attribute value [RFC4145]), the offerer MUST establish a DTLS association. If the offerer becomes DTLS server, it MUST wait for the answerer to establish the DTLS association. If the offerer indicated a desire to reuse an existing DTLS association and the answerer does not request the establishment of a new DTLS association, the offerer will continue to use the previously established DTLS association. A new DTLS association can be established based on changes in either an SDP offer or answer. When communicating with legacy endpoints, an offerer can receive an answer that includes the same fingerprint set and setup role. A new DTLS association will still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association, as the transport parameters would have been changed in the offer. 5.5. Modifying the Session When an offerer sends a subsequent offer, and if the offerer wants to establish a new DTLS association, the offerer MUST insert an SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, and one or more SDP 'fingerprint' attributes according to the procedures in [RFC8122]. In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a new unique attribute value. When an offerer sends a subsequent offer, and the offerer does not want to establish a new DTLS association, and if a previously established DTLS association exists, the offerer MUST insert an SDP 'setup' attribute with an 'actpass' attribute value, and one or more SDP 'fingerprint' attributes with attribute values that do not change the previously sent fingerprint set, in the offer. In addition, the offerer MUST insert an SDP 'tls-id' attribute with the previously assigned attribute value in the offer. NOTE: When a new DTLS association is being established, each endpoint needs to be prepared to receive data on both the new and old DTLS associations as long as both are alive. Holmberg & Shpount Expires May 2, 2018 [Page 11] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 6. ICE Considerations When the Interactive Connectivity Establishment (ICE) mechanism [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. NOTE: Aggressive nomination has been deprecated from ICE, but must still be supported for backwards compatibility reasons [I-D.ietf-ice-rfc5245bis]. When a new DTLS association is established over an unordered transport, in order to disambiguate any packets associated with the newly established DTLS association, at least one of the endpoints MUST allocate a completely new set of ICE candidates which were not recently used for any other DTLS association. This means the answerer cannot initiate a new DTLS association unless the offerer initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer wants to initiate a new DTLS association, it needs to initiate an ICE restart and a new offer/answer exchange on its own. However, an ICE restart does not by default require a new DTLS association to be established. NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets are sent directly over UDP, not over DTLS. [RFC7983] describes how to demultiplex STUN packets from DTLS packets and SRTP packets. Each ICE candidate associated with a component is treated as being part of the same DTLS association. Therefore, from a DTLS perspective it is not considered a change of local transport parameters when an endpoint switches between those ICE candidates. 7. TLS Considerations The procedures in this document can also be used for negotiating and establishing a TLS connection, with the restriction described below. As specified in [RFC4145], the SDP 'connection' attribute is used to indicate whether to establish a new TLS connection. An offerer and answerer MUST ensure that the 'connection' attribute value and the 'tls-id' attribute value does not cause a conflict regarding whether a new TLS connection is to be established or not. NOTE: Even though the SDP 'connection' attribute can be used to indicate whether a new TLS connection is to be established, the unique combination of SDP 'tls-id' attribute values can be used to identity a TLS connection. The unique value can be used e.g., within Holmberg & Shpount Expires May 2, 2018 [Page 12] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/ answer exchanges. One such extension is defined in [I-D.ietf-mmusic-sdp-uks]. If an offerer or answerer inserts an SDP 'connection' attribute with a 'new' value in the offer/answer and also inserts an SDP 'tls-id' attribute, the value of tls-id' attribute MUST be new and unique. If an offerer or answerer inserts an SDP 'connection' attribute with a 'existing' value in the offer/answer, if a previously established TLS connection exists, and if the offerer/answerer previously inserted an SDP 'tls-id' attribute associated with the same TLS connection in an offer/answer, the offerer/answerer MUST also insert an SDP 'tls-id' attribute with the previously assigned value in the offer/answer. If an offerer or answerer receives an offer/answer with conflicting attribute values, the offerer/answerer MUST process the offer/answer as misformed. An endpoint MUST NOT make assumptions regarding the support of the SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, both offerers and answerers MUST always use the 'connection' attribute in conjunction with the 'tls-id' attribute. NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is not explicitly present, the implicit default value is 'new'. The SDP example below is based on the example in section 3.4 of [RFC8122], with the addition of the SDP 'tls-id' attribute. m=image 54111 TCP/TLS t38 c=IN IP4 192.0.2.2 a=tls-id:abc3de65cddef001be82 a=setup:passive a=connection:new a=fingerprint:SHA-256 \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 3E:5D:49:6B:19:E5:7C:AB:4A:AD a=fingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB Holmberg & Shpount Expires May 2, 2018 [Page 13] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 8. SIP Considerations When the Session Initiation Protocol (SIP) [RFC3261] is used as the signal protocol for establishing a multimedia session, dialogs [RFC3261] might be established between the caller and multiple callees. This is referred to as forking. If forking occurs, separate DTLS associations will be established between the caller and each callee. When forking occurs, an SDP offerer can receive DTLS ClientHello messages and SDP answerers from multiple remote locations. Because of this, the offerer might have to wait for multiple SDP answers (from different remote locations) until it receives a certificate fingerprint that matches the certificate associated with a specific DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch until it determines that it will not receive SDP answers from any additional remote locations. It is possible to send an INVITE request which does not contain an SDP offer. Such an INVITE request is often referred to as an 'empty INVITE', or an 'offer-less INVITE'. The receiving endpoint will include the SDP offer in a response to the request. When the endpoint generates such SDP offer, if a previously established DTLS association exists, the offerer MUST insert an SDP 'tls-id' attribute, and one or more SDP 'fingerprint' attributes, with previously assigned attribute values. If a previously established DTLS association did not exist, the offer MUST be generated based on the same rules as a new offer (see Section 5.2). Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145]. Furthermore, if ICE is used, according to the third party call control considerations described in [I-D.ietf-mmusic-ice-sip-sdp], ICE restart MUST be initiated. 9. RFC Updates 9.1. General This section updates specifications that use DTLS-protected media, in order to reflect the procedures defined in this specification. 9.2. Update to RFC 5763 9.2.1. Update to section 1 The reference to [RFC4572] is replaced with a reference to [RFC8122]. Holmberg & Shpount Expires May 2, 2018 [Page 14] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 9.2.2. Update to section 5 The text in section 5 (Establishing a Secure Channel) is modified by replacing generic SDP offer/answer procedures for DTLS with a reference to this specification: NEW TEXT: The two endpoints in the exchange present their identities as part of the DTLS handshake procedure using certificates. This document uses certificates in the same style as described in "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC8122]. If self-signed certificates are used, the content of the subjectAltName attribute inside the certificate MAY use the uniform resource identifier (URI) of the user. This is useful for debugging purposes only and is not required to bind the certificate to one of the communication endpoints. The integrity of the certificate is ensured through the fingerprint attribute in the SDP. The generation of public/private key pairs is relatively expensive. Endpoints are not required to generate certificates for each session. The offer/answer model, defined in [RFC3264], is used by protocols like the Session Initiation Protocol (SIP) [RFC3261] to set up multimedia sessions. When an endpoint wishes to set up a secure media session with another endpoint, it sends an offer in a SIP message to the other endpoint. This offer includes, as part of the SDP payload, a fingerprint of a certificate that the endpoint wants to use. The endpoint SHOULD send the SIP message containing the offer to the offerer's SIP proxy over an integrity protected channel. The proxy SHOULD add an Identity header field according to the procedures outlined in [RFC4474]. When the far endpoint receives the SIP message, it can verify the identity of the sender using the Identity header field. Since the Identity header field is a digital signature across several SIP header fields, in addition to the body of the SIP message, the receiver can also be certain that the message has not been tampered with after the digital signature was applied and added to the SIP message. The far endpoint (answerer) may now establish a DTLS association with the offerer. Alternately, it can indicate in its answer that the offerer is to initiate the DTLS association. In either case, mutual DTLS certificate-based authentication will be used. After completing Holmberg & Shpount Expires May 2, 2018 [Page 15] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 the DTLS handshake, information about the authenticated identities, including the certificates, are made available to the endpoint application. The answerer is then able to verify that the offerer's certificate used for authentication in the DTLS handshake can be associated to a certificate fingerprint contained in the offer in the SDP. At this point, the answerer may indicate to the end user that the media is secured. The offerer may only tentatively accept the answerer's certificate since it may not yet have the answerer's certificate fingerprint. When the answerer accepts the offer, it provides an answer back to the offerer containing the answerer's certificate fingerprint. At this point, the offerer can accept or reject the peer's certificate and the offerer can indicate to the end user that the media is secured. Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is only used to verify the peers' certificate fingerprints. The offerer and answerer MUST follow the SDP offer/answer procedures defined in [RFCXXXX]. 9.2.3. Update to section 6.6 The text in section 6.6 (Session Modification) is modified by replacing generic SDP offer/answer procedures for DTLS with a reference to this specification: NEW TEXT: Once an answer is provided to the offerer, either endpoint MAY request a session modification that MAY include an updated offer. This session modification can be carried in either an INVITE or UPDATE request. The peers can reuse an existing DTLS association, or establish a new one, following the procedures in [RFCXXXX]. 9.2.4. Update to section 6.7.1 The text in section 6.7.1 (ICE Interaction) is modified by replacing the ICE procedures with a reference to this specification: Holmberg & Shpount Expires May 2, 2018 [Page 16] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 NEW TEXT: The Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media are described in [RFCXXXX]. 9.3. Update to RFC 7345 9.3.1. Update to section 4 The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer Procedures) are removed, and replaced with the new text below: NEW TEXT: An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each UDPTL-over-DTLS media stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the "proto" field of the "m=" line. The offerer and answerer MUST follow the SDP offer/answer procedures defined in [RFCXXXX] in order to negotiate the DTLS association associated with the UDPTL-over-DTLS media stream. In addition, the offerer and answerer MUST use the SDP attributes defined for UDPTL over UDP, as defined in [ITU.T38.2010]. 9.3.2. Update to section 5.2.1 The text in section 5.2.1 (ICE Usage) is modified by replacing the ICE procedures with a reference to this specification: NEW TEXT: The Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media are described in [RFCXXXX]. [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX with the RFC number of this document.] Holmberg & Shpount Expires May 2, 2018 [Page 17] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 9.3.3. Update to section 10.1 A reference to [RFC8122] is added to section 10.1 (Normative References): NEW TEXT: [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . 10. Security Considerations This specification does not modify the security considerations associated with DTLS, or the SDP offer/answer mechanism. In addition to the introduction of the SDP 'tls-id' attribute, the specification simply clarifies the procedures for negotiating and establishing a DTLS association. This specification does not modify the actual TLS connection setup procedures. The SDP 'tls-is' attribute as such cannot be used to correlate an SDP Offer/Answer exchange with a TLS connection setup. Thus, this draft does not introduce new security considerations related to correlating an SDP Offer/Answer exchange with a TLS connection setup. 11. IANA Considerations This document updates the "Session Description Protocol Parameters" registry as specified in Section 8.2.2 of [RFC4566]. Specifically, it adds the SDP 'tls-id' attribute to the table for SDP media level attributes. Attribute name: tls-id Type of attribute: media-level Subject to charset: no Purpose: Indicates whether a new DTLS association or TLS connection is to be established/re-established. Appropriate Values: see Section 4 Contact name: Christer Holmberg Mux Category: IDENTICAL Holmberg & Shpount Expires May 2, 2018 [Page 18] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 12. Acknowledgements Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing comments and suggestions on the document. Ben Campbell performed an AD review. Paul Kyzivat performed a gen-art review. 13. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sdp-dtls-31 o Changes based on IESG comments from Eric R Changes from draft-ietf-mmusic-sdp-dtls-30 o Changes based on IESG comments from Mirja K Changes from draft-ietf-mmusic-sdp-dtls-29 o Removal of ufrag value change as a trigger for a new DTLS association Changes from draft-ietf-mmusic-sdp-dtls-28 o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey Melnikov and Mirja Kuhlewind: o - Document title changed o - Transport Protocol Considerations section removed o - Additional text to Security Considerations section o - Editorial changes Changes from draft-ietf-mmusic-sdp-dtls-27 o Reference fixes based on Gen-ART review by Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-26 o Editorial fixes based on Gen-ART review by Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-25 o Minor editorial nits. Holmberg & Shpount Expires May 2, 2018 [Page 19] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Changes from draft-ietf-mmusic-sdp-dtls-24 o Changes based on 2nd WGLC comments from Roman S and Martin T: o - RFC update structure shortened (old text removed). o - Guidance regarding receiving ClientHello before SDP answer added. o - Additional SIP considerations regarding forking. o - SDP setup attribute value restriction in initial and subsequent offers based on comment from Ekr. Changes from draft-ietf-mmusic-sdp-dtls-23 o Editorial change to make it clear that the document does not modify the procedures in RFC 8122. Changes from draft-ietf-mmusic-sdp-dtls-22 o Support for TLS added. o Editorial changes based on sec-dir review by Rich Salz. o Editorial changes based on gen-art review by Paul Kyzivat. o Editorial changes based on ops-dir review by Carlos Pignataro. Changes from draft-ietf-mmusic-sdp-dtls-21 o Changes based on AD review by Ben Campbell. o (https://www.ietf.org/mail-archive/web/mmusic/current/ msg17707.html) Changes from draft-ietf-mmusic-sdp-dtls-20 o Change to length and randomness of tls-id attribute value. Changes from draft-ietf-mmusic-sdp-dtls-19 o Change based on comment from Roman. Changes from draft-ietf-mmusic-sdp-dtls-18 o Changes based on comments from Flemming. Holmberg & Shpount Expires May 2, 2018 [Page 20] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 o - Change in tls-id value definition. o - Editorial fixes. Changes from draft-ietf-mmusic-sdp-dtls-17 o Reference fix. Changes from draft-ietf-mmusic-sdp-dtls-16 o Editorial changes based on 2nd WGLC comments from Christian Groves and Nevenka Biondic. Changes from draft-ietf-mmusic-sdp-dtls-15 o tls-id attribute value made globally unique Changes from draft-ietf-mmusic-sdp-dtls-14 o Changes based on comments from Flemming: o - Additional dtls-is clarifications o - Editorial fixes Changes from draft-ietf-mmusic-sdp-dtls-13 o Text about the updated RFCs added to Abstract and Introduction o Reference to RFC 5763 removed from section 6 (ICE Considerations) o Reference to RFC 5763 removed from section 8 (SIP Considerations) Changes from draft-ietf-mmusic-sdp-dtls-12 o "unreliable" changed to "unordered" Changes from draft-ietf-mmusic-sdp-dtls-11 o Attribute name changed to tls-id o Additional text based on comments from Roman Shpount. Changes from draft-ietf-mmusic-sdp-dtls-10 o Modified document to use tls-id instead of dtls-connection Holmberg & Shpount Expires May 2, 2018 [Page 21] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 o Changes are based on comments from Eric Rescorla, Justin Uberti, and Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-08 o Offer/Answer section modified in order to allow sending of multiple SDP 'fingerprint' attributes. o Terminology made consistent: 'DTLS connection' replaced with 'DTLS association'. o Editorial changes based on comments from Paul Kyzivat. Changes from draft-ietf-mmusic-sdp-dtls-07 o Reference to RFC 7315 replaced with reference to RFC 7345. Changes from draft-ietf-mmusic-sdp-dtls-06 o Text on restrictions regarding spanning a DTLS association over multiple transports added. o Mux category added to IANA Considerations. o Normative text regarding mux category and source-specific applicability added. o Reference to RFC 7315 added. o Clarified that offerer/answerer that has not been updated to support this specification will not include the tls-id attribute in offers and answers. o Editorial corrections based on WGLC comments from Charles Eckel. Changes from draft-ietf-mmusic-sdp-dtls-05 o Text on handling offer/answer error conditions added. Changes from draft-ietf-mmusic-sdp-dtls-04 o Editorial nits fixed based on comments from Paul Kyzivat: Changes from draft-ietf-mmusic-sdp-dtls-03 o Changes based on comments from Paul Kyzivat: o - Modification of tls-id attribute section. Holmberg & Shpount Expires May 2, 2018 [Page 22] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 o - Removal of IANA considerations subsection. o - Making note into normative text in o/a section. o Changes based on comments from Martin Thompson: o - Abbreviations section removed. o - Clarify that a new DTLS association requires a new o/a transaction. Changes from draft-ietf-mmusic-sdp-dtls-02 o - Updated RFCs added to boilerplate. Changes from draft-ietf-mmusic-sdp-dtls-01 o - Annex regarding 'tls-id-id' attribute removed. o - Additional SDP offer/answer procedures, related to certificates, added. o - Updates to RFC 5763 and RFC 7345 added. o - Transport protocol considerations added. Changes from draft-ietf-mmusic-sdp-dtls-00 o - SDP 'connection' attribute replaced with new 'tls-id' attribute. o - IANA Considerations added. o - E-mail regarding 'tls-id-id' attribute added as Annex. Changes from draft-holmberg-mmusic-sdp-dtls-01 o - draft-ietf-mmusic version of draft submitted. o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision with another expired draft. o - Clarify that if ufrag in offer is unchanged, it must be unchanged in associated answer. o - SIP Considerations section added. o - Section about multiple SDP fingerprint attributes added. Holmberg & Shpount Expires May 2, 2018 [Page 23] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Changes from draft-holmberg-mmusic-sdp-dtls-00 o - Editorial changes and clarifications. 14. References 14.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, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August 2014, . Holmberg & Shpount Expires May 2, 2018 [Page 24] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-13 (work in progress), October 2017. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-39 (work in progress), August 2017. 14.2. Informative References [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, . [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/RFC4572, July 2006, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . Holmberg & Shpount Expires May 2, 2018 [Page 25] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, . [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, . [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 (work in progress), February 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in progress), October 2017. [I-D.ietf-mmusic-sdp-uks] Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00 (work in progress), August 2017. [ITU.T38.2010] International Telecommunications Union, "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, September 2010. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg & Shpount Expires May 2, 2018 [Page 26] Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017 Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Holmberg & Shpount Expires May 2, 2018 [Page 27] ./draft-ietf-mmusic-ice-sip-sdp-39.txt0000644000764400076440000027105613524656112017014 0ustar iustyiusty MMUSIC M. Petit-Huguenin Internet-Draft Impedance Mismatch Obsoletes: 5245 (if approved) S. Nandakumar Intended status: Standards Track Cisco Systems Expires: February 14, 2020 C. Holmberg A. Keranen Ericsson R. Shpount TurboBridge August 13, 2019 Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE) draft-ietf-mmusic-ice-sip-sdp-39 Abstract This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFC 5245. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 14, 2020. Copyright Notice Copyright (c) 2019 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 Petit-Huguenin, et al. Expires February 14, 2020 [Page 1] Internet-Draft ICE SDP Usage August 2019 (https://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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 5 4.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 4.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 4.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 4.2.5. Verifying ICE Support Procedures . . . . . . . . . . 7 4.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 8 4.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 4.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 4.3.2. Sending the Initial Answer . . . . . . . . . . . . . 9 4.3.3. Receiving the Initial Answer . . . . . . . . . . . . 10 4.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10 4.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 11 4.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 11 4.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 14 4.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 16 5. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 18 5.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 20 5.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 21 5.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 21 Petit-Huguenin, et al. Expires February 14, 2020 [Page 2] Internet-Draft ICE SDP Usage August 2019 5.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22 5.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 22 6. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23 7.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 24 7.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 25 7.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25 7.3. Interactions with Forking . . . . . . . . . . . . . . . . 25 7.4. Interactions with Preconditions . . . . . . . . . . . . . 25 7.5. Interactions with Third Party Call Control . . . . . . . 26 8. Interactions with Application Layer Gateways and SIP . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.1. IP Address Privacy . . . . . . . . . . . . . . . . . . . 28 9.2. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 28 9.3. The Voice Hammer Attack . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 29 10.1.1. candidate Attribute . . . . . . . . . . . . . . . . 29 10.1.2. remote-candidates Attribute . . . . . . . . . . . . 29 10.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 30 10.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30 10.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 31 10.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 31 10.1.7. ice-options Attribute . . . . . . . . . . . . . . . 32 10.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32 10.2. Interactive Connectivity Establishment (ICE) Options Registry . . . . . . . . . . . . . . . . . . . . . . . . 33 10.3. Candidate Attribute Extension Subregistry Establishment 33 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 12. Changes from RFC 5245 . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 39 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 40 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 41 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer [RFC3264]. The ICE specification [RFC8445] describes procedures that are common to all usages of ICE and this document gives the additional details needed to use ICE with SDP offer/answer. Petit-Huguenin, et al. Expires February 14, 2020 [Page 3] Internet-Draft ICE SDP Usage August 2019 This document obsoletes RFC 5245. NOTE: Previously both the common ICE procedures, and the SDP offer/ answer specific details, were described in[RFC5245]. [RFC8445] obsoleted [RFC5245], and the SDP offer/answer specific details were removed from the document. Section 12 describes the changes to the SDP offer/answer specific details specified in this document. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology Readers should be familiar with the terminology defined in [RFC3264], in [RFC8445] and the following: Default Destination/Candidate: The default destination for a component of a data stream is the transport address that would be used by an agent that is not ICE aware. A default candidate for a component is one whose transport address matches the default destination for that component. For the RTP component, the default connection address is in the "c=" line of the SDP, and the port and transport protocol are in the "m=" line. For the RTCP component, the address and port are indicated using the "a=rtcp" attribute defined in [RFC3605], if present; otherwise, the RTCP component address is the same as the address of the RTP component, and its port is one greater than the port of the RTP component. 4. SDP Offer/Answer Procedures 4.1. Introduction [RFC8445] defines ICE candidate exchange as the process for ICE agents (Initiator and Responder) to exchange their candidate information required for ICE processing at the agents. For the purposes of this specification, the candidate exchange process corresponds to the [RFC3264] Offer/Answer protocol and the terms "offerer" and "answerer" correspond to the initiator and responder roles from [RFC8445] respectively. Once the initiating agent has gathered, pruned, and prioritized its set of candidates [RFC8445], the candidate exchange with the peer agent begins. Petit-Huguenin, et al. Expires February 14, 2020 [Page 4] Internet-Draft ICE SDP Usage August 2019 4.2. Generic Procedures 4.2.1. Encoding Section 5 provides detailed rules for constructing various SDP attributes defined in this specification. 4.2.1.1. Data Streams Each data stream [RFC8445] is represented by an SDP media description ("m=" section). 4.2.1.2. Candidates Within an "m=" section, each candidate (including the default candidate) associated with the data stream is represented by an SDP candidate attribute. Prior to nomination, the "c=" line associated with an "m=" section contains the connection address of the default candidate, while the "m=" line contains the port and transport protocol of the default candidate for that "m=" section. After nomination, the "c=" line for a given "m=" section contains the connection address of the nominated candidate (the local candidate of the nominated candidate pair) and the "m=" line contains the port and transport protocol corresponding to the nominated candidate for that "m=" section. 4.2.1.3. Username and Password The ICE username is represented by an SDP ice-ufrag attribute and the ICE password is represented by an SDP ice-pwd attribute. 4.2.1.4. Lite Implementations An ICE lite implementation [RFC8445] MUST include an SDP ice-lite attribute. A full implementation MUST NOT include that attribute. 4.2.1.5. ICE Extensions An agent uses the SDP ice-options attribute to indicate support of ICE extensions. An agent compliant to this specification MUST include an SDP ice- options attribute with an "ice2" attribute value [RFC8445]. If an agent receives an SDP offer or answer that indicates ICE support, but that does not contain an SDP ice-options attribute with an "ice2" Petit-Huguenin, et al. Expires February 14, 2020 [Page 5] Internet-Draft ICE SDP Usage August 2019 attribute value, the agent can assume that the peer is compliant to [RFC5245]. 4.2.1.6. Inactive and Disabled Data Streams If an "m=" section is marked as inactive [RFC4566], or has a bandwidth value of zero [RFC4566], the agent MUST still include ICE- related SDP attributes. If the port value associated with an "m=" section is set to zero (implying a disabled stream) as defined in section 8.2 of [RFC3264], the agent SHOULD NOT include ICE-related SDP candidate attributes in that "m=" section, unless an SDP extension specifying otherwise is used. 4.2.2. RTP/RTCP Considerations If an agent utilizes both RTP and RTCP, and separate ports are used for RTP and RTCP, the agent MUST include SDP candidate attributes for both the RTP and RTCP components. The agent includes an SDP rtcp attribute following the procedures in [RFC3605]. Hence, in the cases where the RTCP port value is one higher than the RTP port value and the RTCP component address the same as the address of the RTP component, the SDP rtcp attribute might be omitted. NOTE: [RFC5245] required that an agent always includes the SDP rtcp attribute, even if the RTCP port value was one higher than the RTP port value. This specification aligns the rtcp attribute procedures with [RFC3605]. If the agent does not utilize RTCP, it indicates that by including b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. 4.2.3. Determining Role The offerer acts as the Initiating agent. The answerer acts as the Responding agent. The ICE roles (controlling and controlled) are determined using the procedures in [RFC8445]. 4.2.4. STUN Considerations Once an agent has provided its local candidates to its peer in an SDP offer or answer, the agent MUST be prepared to receive STUN connectivity check Binding requests on those candidates. Petit-Huguenin, et al. Expires February 14, 2020 [Page 6] Internet-Draft ICE SDP Usage August 2019 4.2.5. Verifying ICE Support Procedures An ICE agent is considered to indicate support of ICE by including at least the SDP ice-pwd and ice-ufrag attributes in an offer or answer. An ICE agent compliant with this specification MUST also include an SDP ice-options attribute with an "ice2" attribute value. The agents will proceed with the ICE procedures defined in [RFC8445] and this specification if, for each data stream in the SDP it received, the default destination for each component of that data stream appears in a candidate attribute. For example, in the case of RTP, the connection address, port, and transport protocol in the "c=" and "m=" lines, respectively, appear in a candidate attribute and the value in the rtcp attribute appears in a candidate attribute. This specification provides no guidance on how an agent should proceed in the cases where the above condition is not met with the few exceptions noted below: 1. The presence of certain application layer gateways might modify the transport address information as described in Section 8. The behavior of the responding agent in such a situation is implementation dependent. Informally, the responding agent might consider the mismatched transport address information as a plausible new candidate learnt from the peer and continue its ICE processing with that transport address included. Alternatively, the responding agent MAY include an "a=ice-mismatch" attribute in its answer for such data streams. If an agent chooses to include an "a=ice-mismatch" attribute in its answer for a data stream, then it MUST also omit "a=candidate" attributes, MUST terminate the usage of ICE procedures and [RFC3264] procedures MUST be used instead for this data stream. 2. The transport address from the peer for the default destination is set to IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9". This MUST NOT be considered as a ICE failure by the peer agent and the ICE processing MUST continue as usual. 3. In some cases, the controlling/initiator agent may receive the SDP answer that may omit "a=candidate" attributes for the data stream, and instead include a media level "a=ice-mismatch" attribute. This signals to the offerer that the answerer supports ICE, but that ICE processing was not used for this data stream. In this case, ICE processing MUST be terminated for this data stream and [RFC3264] procedures MUST be followed instead. 4. The transport address from the peer for the default destination is an FQDN. Regardless of the procedures used to resolve FQDN or Petit-Huguenin, et al. Expires February 14, 2020 [Page 7] Internet-Draft ICE SDP Usage August 2019 the resolution result, this MUST NOT be considered as a ICE failure by the peer agent and the ICE processing MUST continue as usual. 4.2.6. SDP Example The following is an example SDP message that includes ICE attributes (lines folded for readability): v=0 o=jdoe 2890844526 2890842807 IN IP4 203.0.113.141 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998 4.3. Initial Offer/Answer Exchange 4.3.1. Sending the Initial Offer When an offerer generates the initial offer, in each "m=" section it MUST include SDP candidate attributes for each available candidate associated with the "m=" section. In addition, the offerer MUST include an SDP ice-ufrag attribute, an SDP ice-pwd attribute and an SDP ice-options attribute with an "ice2" attribute value in the offer. If the offerer is a full ICE implementation, it SHOULD include an ice-pacing attribute in the offer (if not included, the default value will apply). A lite ICE implementation MUST NOT included the ice-pacing attribute in the offer (as it will not perform connectivity checks). It is valid for an offer "m=" line to include no SDP candidate attributes and with default destination set to the IP address values "0.0.0.0"/"::" and port value of "9". This implies that the offering agent is only going to use peer reflexive candidates or that additional candidates would be provided in subsequent signaling messages. Petit-Huguenin, et al. Expires February 14, 2020 [Page 8] Internet-Draft ICE SDP Usage August 2019 Note: Within the scope of this document, "Initial Offer" refers to the first SDP offer that is sent in order to negotiate usage of ICE. It might, or might not, be the initial SDP offer of the SDP session. Note: The procedures in this document only consider "m=" sections associated with data streams where ICE is used. 4.3.2. Sending the Initial Answer When an answerer receives an initial offer that indicates that the offerer supports ICE, and if the answerer accepts the offer and the usage of ICE, in each "m=" section within the answer, it MUST include SDP candidate attributes for each available candidate associated with the "m=" section. In addition, the answerer MUST include an SDP ice- ufrag attribute, an SDP ice-pwd attribute and an SDP ice-options attribute with an "ice2" attribute value in the answer. If the answerer is a full ICE implementation, it SHOULD include an ice- pacing attribute in the answerer (if not included, the default value will apply). A lite ICE implementation MUST NOT included the ice- pacing attribute in the answer (as it will not perform connectivity chekcks). In each "m=" line, the answerer MUST use the same transport protocol as was used in the offer "m=" line. If none of the candidates in the "m=" line in the answer use the same transport protocol as indicated in the offer "m=" line, then, in order to avoid ICE mismatch, the default destination MUST be set to IP address values "0.0.0.0"/"::" and port value of "9". It is also valid for an answer "m=" line to include no SDP candidate attributes and with default destination set to the IP address values "0.0.0.0"/"::" and port value of "9". This implies that the answering agent is only going to use peer reflexive candidates or that additional candidates would be provided in subsequent signaling messages. Once the answerer has sent the answer, it can start performing connectivity checks towards the peer candidates that were provided in the offer. If the offer does not indicate support of ICE Section 4.2.5, the answerer MUST NOT accept the usage of ICE. If the answerer still accepts the offer, the answerer MUST NOT include any ICE-related SDP attributes in the answer. Instead the answerer will generate the answer according to normal offer/answer procedures [RFC3264]. Petit-Huguenin, et al. Expires February 14, 2020 [Page 9] Internet-Draft ICE SDP Usage August 2019 If the answerer detects a possibility of an ICE mismatch, procedures described in Section 4.2.5 are followed. 4.3.3. Receiving the Initial Answer When an offerer receives an initial answer that indicates that the answerer supports ICE, it can start performing connectivity checks towards the peer candidates that were provided in the answer. If the answer does not indicate that the answerer supports ICE, or if the answerer included "a=ice-mismatch" attributes for all the active data streams in the answer, the offerer MUST terminate the usage of ICE for the entire session and [RFC3264] procedures MUST be followed instead. On the other hand, if the answer indicates support for ICE but includes "a=ice-mismatch" in certain active data streams, then the offerer MUST terminate the usage of ICE procedures and [RFC3264] procedures MUST be used instead for only these data streams. Also, ICE procedures MUST be used for data streams where an "a=ice- mismatch" attribute was not included. If the offerer detects an ICE mismatch for one or more data streams in the answer, as described in Section 4.2.5, the offerer MUST terminate the usage of ICE for the entire session. The subsequent actions taken by the offerer are implementation dependent and are out of the scope of this specification. 4.3.4. Concluding ICE Once the agent has successfully nominated a pair [RFC8445], the state of the checklist associated with the pair is set to Completed. Once the state of each checklist is set to either Completed or Failed, for each Completed checklist the agent checks whether the nominated pair matches the default candidate pair. If there are one or more pairs that do not match, and the peer did not indicate support for the 'ice2' ice-option, the controlling agent MUST generate a subsequent offer, in which the connection address, port and transport protocol in the "c=" and "m=" lines associated with each data stream match the corresponding local information of the nominated pair for that data stream (Section 4.4.1.2.2). If the peer did indicate support for the 'ice2' ice-option, the controlling agent does not immediately need to generate an updated offer in order to align a connection address, port and protocol with a nominated pair. However, later in the session, whenever the controlling agent does sent a subsequent offer, it MUST do the alignment as described above. Petit-Huguenin, et al. Expires February 14, 2020 [Page 10] Internet-Draft ICE SDP Usage August 2019 If there are one or more checklists with the state set to Failed, the controlling agent MUST generate a subsequent offer in order to remove the associated data streams by setting the port value of the data streams to zero (Section 4.4.1.1.2), even if the peer did indicate support for the 'ice2' ice-option. If needed, such offer is used to align the connection address, port and transport protocol, as described above. As described in [RFC8445], once the controlling agent has nominated a candidate pair for a checklist, the agent MUST NOT nominate another pair for that checklist during the lifetime of the ICE session (i.e. until ICE is restarted). [draft-ietf-ice-pac] provides a mechanism for allowing the ICE process to run long enough in order to find working candidate pairs, by waiting for potential peer-reflexive candidates, even though no candidate pairs were received from the peer or all current candidate pairs associated with a checklist have either failed or been discarded. It is OPTIONAL for an ICE agent to support the mechanism. 4.4. Subsequent Offer/Answer Exchanges Either agent MAY generate a subsequent offer at any time allowed by [RFC3264]. This section defines rules for construction of subsequent offers and answers. Should a subsequent offer fail, ICE processing continues as if the subsequent offer had never been made. 4.4.1. Sending Subsequent Offer 4.4.1.1. Procedures for All Implementations 4.4.1.1.1. ICE Restart An agent MAY restart ICE processing for an existing data stream [RFC8445]. The rules governing the ICE restart imply that setting the connection address in the "c=" line to "0.0.0.0" (for IPv4)/ "::" (for IPv6) will cause an ICE restart. Consequently, ICE implementations MUST NOT utilize this mechanism for call hold, and instead MUST use "a=inactive" and "a=sendonly" as described in [RFC3264]. To restart ICE, an agent MUST change both the ice-pwd and the ice- ufrag for the data stream in an offer. However, it is permissible to use a session-level attribute in one offer, but to provide the same Petit-Huguenin, et al. Expires February 14, 2020 [Page 11] Internet-Draft ICE SDP Usage August 2019 ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This MUST NOT be considered as ICE restart. An agent sets the rest of the ICE-related fields in the SDP for this data stream as it would in an initial offer of this data stream (Section 4.2.1). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that data stream and MAY include a totally new set of candidates. The agent MAY modify the attribute values of the SDP ice-options and SDP ice-pacing attributes, and it MAY change its role using the SDP ice-lite attribute. The agent MUST NOT modify the SDP ice-options, ice-pacing and ice-lite attributes in a subsequent offer unless the offer is sent in order to request an ICE restart. 4.4.1.1.2. Removing a Data Stream If an agent removes a data stream by setting its port to zero, it MUST NOT include any candidate attributes for that data stream and SHOULD NOT include any other ICE-related attributes defined in Section 5 for that data stream. 4.4.1.1.3. Adding a Data Stream If an agent wishes to add a new data stream, it sets the fields in the SDP for this data stream as if this were an initial offer for that data stream (Section 4.2.1). This will cause ICE processing to begin for this data stream. 4.4.1.2. Procedures for Full Implementations This section describes additional procedures for full implementations, covering existing data streams. 4.4.1.2.1. Before Nomination When an offerer sends a subsequent offer; in each "m=" section for which a candidate pair has not yet been nominated, the offer MUST include the same set of ICE-related information that the offerer included in the previous offer or answer. The agent MAY include additional candidates it did not offer previously, but which it has gathered since the last offer/answer exchange, including peer reflexive candidates. The agent MAY change the default destination for media. As with initial offers, there MUST be a set of candidate attributes in the offer matching this default destination. Petit-Huguenin, et al. Expires February 14, 2020 [Page 12] Internet-Draft ICE SDP Usage August 2019 4.4.1.2.2. After Nomination Once a candidate pair has been nominated for a data stream, the connection address, port and transport protocol in each "c=" and "m=" line associated with that data stream MUST match the data associated with the nominated pair for that data stream. In addition, the offerer only includes SDP candidates (one per component) representing the local candidates of the nominated candidate pair. The offerer MUST NOT include any other SDP candidate attributes in the subsequent offer. In addition, if the agent is controlling, it MUST include the "a=remote-candidates" attribute for each data stream whose checklist is in the Completed state. The attribute contains the remote candidates corresponding to the nominated pair in the valid list for each component of that data stream. It is needed to avoid a race condition whereby the controlling agent chooses its pairs, but the updated offer beats the connectivity checks to the controlled agent, which doesn't even know these pairs are valid, let alone selected. See Appendix B for elaboration on this race condition. 4.4.1.3. Procedures for Lite Implementations If the ICE state is Running, a lite implementation MUST include all of its candidates for each component of each data stream in "a=candidate" attributes in any subsequent offer. The candidates are formed identically to the procedures for initial offers. A lite implementation MUST NOT add additional host candidates in a subsequent offer, and MUST NOT modify the username fragments and passwords. If an agent needs to offer additional candidates, or modify the username fragments and passwords, it MUST request an ICE restart (Section 4.4.1.1.1) for that data stream. If ICE has completed for a data stream and if the agent is controlled, the default destination for that data stream MUST be set to the remote candidate of the candidate pair for that component in the valid list. For a lite implementation, there is always just a single candidate pair in the valid list for each component of a data stream. Additionally, the agent MUST include a candidate attribute for each default destination. If the ICE state is Completed and if the agent is controlling (which only happens when both agents are lite), the agent MUST include the "a=remote-candidates" attribute for each data stream. The attribute contains the remote candidates from the candidate pairs in the valid list (one pair for each component of each data stream). Petit-Huguenin, et al. Expires February 14, 2020 [Page 13] Internet-Draft ICE SDP Usage August 2019 4.4.2. Sending Subsequent Answer If ICE is Completed for a data stream, and the offer for that data stream lacked the "a=remote-candidates" attribute, the rules for construction of the answer are identical to those for the offerer, except that the answerer MUST NOT include the "a=remote-candidates" attribute in the answer. A controlled agent will receive an offer with the "a=remote- candidates" attribute for a data stream when its peer has concluded ICE processing for that data stream. This attribute is present in the offer to deal with a race condition between the receipt of the offer, and the receipt of the Binding Response that tells the answerer the candidate that will be selected by ICE. See Appendix B for an explanation of this race condition. Consequently, processing of an offer with this attribute depends on the winner of the race. The agent forms a candidate pair for each component of the data stream by: o Setting the remote candidate equal to the offerer's default destination for that component (i.e. the contents of the "m=" and "c=" lines for RTP, and the "a=rtcp" attribute for RTCP) o Setting the local candidate equal to the transport address for that same component in the "a=remote-candidates" attribute in the offer. The agent then sees if each of these candidate pairs is present in the valid list. If a particular pair is not in the valid list, the check has "lost" the race. Call such a pair a "losing pair". The agent finds all the pairs in the checklist whose remote candidates equal the remote candidate in the losing pair: o If none of the pairs are In-Progress, and at least one is Failed, it is most likely that a network failure, such as a network partition or serious packet loss, has occurred. The agent SHOULD generate an answer for this data stream as if the remote- candidates attribute had not been present, and then restart ICE for this stream. o If at least one of the pairs is In-Progress, the agent SHOULD wait for those checks to complete, and as each completes, redo the processing in this section until there are no losing pairs. Once there are no losing pairs, the agent can generate the answer. It MUST set the default destination for media to the candidates in Petit-Huguenin, et al. Expires February 14, 2020 [Page 14] Internet-Draft ICE SDP Usage August 2019 the remote-candidates attribute from the offer (each of which will now be the local candidate of a candidate pair in the valid list). It MUST include a candidate attribute in the answer for each candidate in the remote-candidates attribute in the offer. 4.4.2.1. ICE Restart If the offerer in a subsequent offer requested an ICE restart (Section 4.4.1.1.1) for a data stream, and if the answerer accepts the offer, the answerer follows the procedures for generating an initial answer. For a given data stream, the answerer MAY include the same candidates that were used in the previous ICE session, but it MUST change the SDP ice-pwd and ice-ufrag attribute values. The answerer MAY modify the attribute values of the SDP ice-options and SDP ice-pacing attributes, and it MAY change its role using the SDP ice-lite attribute. The answerer MUST NOT modify the SDP ice- options, ice-pacing and ice-lite attributes in a subsequent answer unless the answer is sent for an offer that was used to request an ICE restart (Section 4.4.1.1.1). If any of the SDP attributes have been modified in a subsequent offer that is not used to request an ICE restart, the answerer MUST reject the offer. 4.4.2.2. Lite Implementation specific procedures If the received offer contains the remote-candidates attribute for a data stream, the agent forms a candidate pair for each component of the data stream by: o Setting the remote candidate equal to the offerer's default destination for that component (i.e., the contents of the "m=" and "c=" lines for RTP, and the "a=rtcp" attribute for RTCP). o Setting the local candidate equal to the transport address for that same component in the "a=remote-candidates" attribute in the offer. The state of the checklist associated with that data stream is set to Completed. Furthermore, if the agent believed it was controlling, but the offer contained the "a=remote-candidates" attribute, both agents believe they are controlling. In this case, both would have sent updated offers around the same time. Petit-Huguenin, et al. Expires February 14, 2020 [Page 15] Internet-Draft ICE SDP Usage August 2019 However, the signaling protocol carrying the offer/answer exchanges will have resolved this glare condition, so that one agent is always the 'winner' by having its offer received before its peer has sent an offer. The winner takes the role of controlling, so that the loser (the answerer under consideration in this section) MUST change its role to controlled. Consequently, if the agent was going to send an updated offer since, based on the rules in section 8.2 of [RFC8445], it was controlling, it no longer needs to. Besides the potential role change, change in the Valid list, and state changes, the construction of the answer is performed identically to the construction of an offer. 4.4.3. Receiving Answer for a Subsequent Offer 4.4.3.1. Procedures for Full Implementations There may be certain situations where the offerer receives an SDP answer that lacks ICE candidates although the initial answer included them. One example of such an "unexpected" answer might be happen when an ICE-unaware Back-to-Back User Agent (B2BUA) introduces a media server during call hold using 3rd party call-control procedures [RFC3725]. Omitting further details how this is done, this could result in an answer being received at the holding UA that was constructed by the B2BUA. With the B2BUA being ICE-unaware, that answer would not include ICE candidates. Receiving an answer without ICE attributes in this situation might be unexpected, but would not necessarily impair the user experience. When the offerer receives an answer indicating support for ICE, the offer performs one of the following actions: o If the offer was a restart, the agent MUST perform ICE restart procedures as specified in Section 4.4.3.1.1 o If the offer/answer exchange removed a data stream, or an answer rejected an offered data stream, an agent MUST flush the Valid list for that data stream. It MUST also terminate any STUN transactions in progress for that data stream. o If the offer/answer exchange added a new data stream, the agent MUST create a new checklist for it (and an empty Valid list to start of course) which in turn triggers the candidate processing procedures [RFC8445]. Petit-Huguenin, et al. Expires February 14, 2020 [Page 16] Internet-Draft ICE SDP Usage August 2019 o If the checklist state associated with a data stream is Running, the agent recomputes the checklist. If a pair on the new checklist was also on the previous checklist, its candidate pair state is copied over. Otherwise, its candidate pair state is set to Frozen. If none of the checklists are active (meaning that the candidate pair states in each checklist are Frozen), appropriate procedures in [RFC8445] are performed to move candidate pair(s) to the Waiting state to further continue ICE processing. o If the ICE state is Completed and the SDP answer conforms to Section 4.4.2, the agent MUST remain in the Completed ICE state. However, if the ICE support is no longer indicated in the SDP answer, the agent MUST fall-back to [RFC3264] procedures and SHOULD NOT drop the dialog because of the missing ICE support or unexpected answer. Once the agent sends a new offer later on, it MUST perform an ICE restart. 4.4.3.1.1. ICE Restarts The agent MUST remember the nominated pair in the Valid list for each component of the data stream, called the "previous selected pair", prior to the restart. The agent will continue to send media using this pair, as described in section 12 of [RFC8445]. Once these destinations are noted, the agent MUST flush the Valid lists and checklists, and then recompute the checklist and its states, thus triggering the candidate processing procedures [RFC8445] 4.4.3.2. Procedures for Lite Implementations If ICE is restarting for a data stream, the agent MUST create a new Valid list for that data stream. It MUST remember the nominated pair in the previous Valid list for each component of the data stream, called the "previous selected pairs", and continue to send media there as described in section 12 of [RFC8445]. The state of each checklist for each data stream MUST change to Running, and the ICE state MUST be set to Running. 5. Grammar This specification defines eight new SDP attributes -- the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice-pwd", "ice-pacing", and "ice-options" attributes. This section also provides non-normative examples of the attributes defined. Petit-Huguenin, et al. Expires February 14, 2020 [Page 17] Internet-Draft ICE SDP Usage August 2019 The syntax for the attributes follow Augmented BNF as defined in [RFC5234]. 5.1. "candidate" Attribute The candidate attribute is a media-level attribute only. It contains a transport address for a candidate that can be used for connectivity checks. candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] *(SP cand-extension) foundation = 1*32ice-char component-id = 1*3DIGIT transport = "UDP" / transport-extension transport-extension = token ; from RFC 3261 priority = 1*10DIGIT cand-type = "typ" SP candidate-types candidate-types = "host" / "srflx" / "prflx" / "relay" / token rel-addr = "raddr" SP connection-address rel-port = "rport" SP port cand-extension = extension-att-name SP extension-att-value extension-att-name = token extension-att-value = *VCHAR ice-char = ALPHA / DIGIT / "+" / "/" This grammar encodes the primary information about a candidate: its IP address, port and transport protocol, and its properties: the foundation, component ID, priority, type, and related transport address: : is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent generating local candidates MUST NOT use FQDN addresses. An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized. The procedures for generation and handling of FQDN candidates, as well Petit-Huguenin, et al. Expires February 14, 2020 [Page 18] Internet-Draft ICE SDP Usage August 2019 as, how agents indicate support for such procedures, need to be specified in an extension specification. : is also taken from RFC 4566 [RFC4566]. It is the port of the candidate. : indicates the transport protocol for the candidate. This specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE by extending the sub-registry "ICE Transport Protocols" under "Interactive Connectivity Establishment (ICE)" registry. : is composed of 1 to 32 s. It is an identifier that is equivalent for two candidates that are of the same type, share the same base, and come from the same STUN server. The foundation is used to optimize ICE performance in the Frozen algorithm as described in [RFC8445] : is a positive integer between 1 and 256 (inclusive) that identifies the specific component of the data stream for which this is a candidate. It MUST start at 1 and MUST increment by 1 for each component of a particular candidate. For data streams based on RTP, candidates for the actual RTP media MUST have a component ID of 1, and candidates for RTCP MUST have a component ID of 2. See section 13 in [RFC8445] for additional discussion on extending ICE to new data streams. : is a positive integer between 1 and (2**31 - 1) inclusive. The procedures for computing candidate's priority is described in section 5.1.2 of [RFC8445]. : encodes the type of candidate. This specification defines the values "host", "srflx", "prflx", and "relay" for host, server reflexive, peer reflexive, and relayed candidates, respectively. Specifications for new candidate types MUST define how, if at all, various steps in the ICE processing differ from the ones defined by this specification. and : convey transport addresses related to the candidate, useful for diagnostics and other purposes. and MUST be present for server reflexive, peer reflexive, and relayed candidates. If a candidate is server or peer reflexive, and are equal to the base for that server or peer reflexive candidate. If the candidate is relayed, and are equal to the mapped address in the Allocate response that provided the client with that relayed candidate (see Appendix B.3 of [RFC8445] for a discussion Petit-Huguenin, et al. Expires February 14, 2020 [Page 19] Internet-Draft ICE SDP Usage August 2019 of its purpose). If the candidate is a host candidate, and MUST be omitted. In some cases, e.g., for privacy reasons, an agent may not want to reveal the related address and port. In this case the address MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 candidates) and the port to '9'. The candidate attribute can itself be extended. The grammar allows for new name/value pairs to be added at the end of the attribute. Such extensions MUST be made through IETF Review or IESG Approval [RFC8126] and the assignments MUST contain the specific extension and a reference to the document defining the usage of the extension. An implementation MUST ignore any name/value pairs it doesn't understand. Example: SDP line for UDP server reflexive candidate attribute for the RTP component a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998 5.2. "remote-candidates" Attribute The syntax of the "remote-candidates" attribute is defined using Augmented BNF as defined in [RFC5234]. The remote-candidates attribute is a media-level attribute only. remote-candidate-att = "remote-candidates:" remote-candidate 0*(SP remote-candidate) remote-candidate = component-ID SP connection-address SP port The attribute contains a connection-address and port for each component. The ordering of components is irrelevant. However, a value MUST be present for each component of a data stream. This attribute MUST be included in an offer by a controlling agent for a data stream that is Completed, and MUST NOT be included in any other case. Example: Remote candidates SDP lines for the RTP and RTCP components: a=remote-candidates:1 192.0.2.3 45664 a=remote-candidates:2 192.0.2.3 45665 Petit-Huguenin, et al. Expires February 14, 2020 [Page 20] Internet-Draft ICE SDP Usage August 2019 5.3. "ice-lite" and "ice-mismatch" Attributes The syntax of the "ice-lite" and "ice-mismatch" attributes, both of which are flags, is: ice-lite = "ice-lite" ice-mismatch = "ice-mismatch" "ice-lite" is a session-level attribute only, and indicates that an agent is a lite implementation. "ice-mismatch" is a media-level attribute and only reported in the answer. It indicates that the offer arrived with a default destination for a media component that didn't have a corresponding candidate attribute. Inclusion of "a=ice-mismatch" attribute for a given data stream implies that even though both agents support ICE, ICE procedures MUST NOT be used for this data stream and [RFC3264] procedures MUST be used instead. 5.4. "ice-ufrag" and "ice-pwd" Attributes The "ice-ufrag" and "ice-pwd" attributes convey the username fragment and password used by ICE for message integrity. Their syntax is: ice-pwd-att = "ice-pwd:" password ice-ufrag-att = "ice-ufrag:" ufrag password = 22*256ice-char ufrag = 4*256ice-char The "ice-pwd" and "ice-ufrag" attributes can appear at either the session-level or media-level. When present in both, the value in the media-level takes precedence. Thus, the value at the session-level is effectively a default that applies to all data streams, unless overridden by a media-level value. Whether present at the session or media-level, there MUST be an ice-pwd and ice-ufrag attribute for each data stream. If two data streams have identical ice-ufrag's, they MUST have identical ice-pwd's. The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the beginning of a session (the same applies when ICE is restarting for an agent). [RFC8445] requires the ice-ufrag attribute to contain at least 24 bits of randomness, and the ice-pwd attribute to contain at least 128 bits of randomness. This means that the ice-ufrag attribute will be at least 4 characters long, and the ice-pwd at least 22 characters long, since the grammar for these attributes allows for 6 bits of information per character. The attributes MAY be longer than 4 and 22 characters, respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large Petit-Huguenin, et al. Expires February 14, 2020 [Page 21] Internet-Draft ICE SDP Usage August 2019 upper limit allows for increased amounts of randomness to be added over time. For compatibility with the 512 character limitation for the STUN username attribute value and for bandwidth conservation considerations, the ice-ufrag attribute MUST NOT be longer than 32 characters when sending, but an implementation MUST accept up to 256 characters when receiving. Example shows sample ice-ufrag and ice-pwd SDP lines: a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY 5.5. "ice-pacing" Attribute The "ice-pacing" is a session level attribute that indicates the desired connectivity check pacing (Ta interval), in milliseconds, that the sender wishes to use. See section 14.2 of [RFC8445] for more information regarding selecting a pacing value. The syntax is: ice-pacing-att = "ice-pacing:" pacing-value pacing-value = 1*10DIGIT If absent in an offer or answer the default value of the attribute is 50 ms, which is the recommended value specified in [RFC8445]. Once both agents have indicated the pacing value they with to use, both agents MUST use the larger of the indicated values. Example shows an ice-pacing SDP line with value '50': a=ice-pacing:50 5.6. "ice-options" Attribute The "ice-options" attribute is a session- and media-level attribute. It contains a series of tokens that identify the options supported by the agent. Its grammar is: ice-options = "ice-options:" ice-option-tag *(SP ice-option-tag) ice-option-tag = 1*ice-char The existence of an ice-option in an offer indicates that a certain extension is supported by the agent and it is willing to use it, if the peer agent also includes the same extension in the answer. There might be further extension specific negotiation needed between the agents that determine how the extension gets used in a given session. The details of the negotiation procedures, if present, MUST be defined by the specification defining the extension (Section 10.2). Petit-Huguenin, et al. Expires February 14, 2020 [Page 22] Internet-Draft ICE SDP Usage August 2019 Example shows an ice-options SDP line with 'ice2' and 'rtp+ecn' [RFC6679] values: a=ice-options:ice2 rtp+ecn 6. Keepalives All the ICE agents MUST follow the procedures defined in section 11 of [RFC8445] for sending keepalives. The keepalives MUST be sent regardless of whether the data stream is currently inactive, sendonly, recvonly, or sendrecv, and regardless of the presence or value of the bandwidth attribute. An agent can determine that its peer supports ICE by the presence of "a=candidate" attributes for each media session. 7. SIP Considerations Note that ICE is not intended for NAT traversal for SIP signaling, which is assumed to be provided via another mechanism [RFC5626]. When ICE is used with SIP, forking may result in a single offer generating a multiplicity of answers. In that case, ICE proceeds completely in parallel and independently for each answer, treating the combination of its offer and each answer as an independent offer/ answer exchange, with its own set of local candidates, pairs, checklists, states, and so on. 7.1. Latency Guidelines ICE requires a series of STUN-based connectivity checks to take place between endpoints. These checks start from the answerer on generation of its answer, and start from the offerer when it receives the answer. These checks can take time to complete, and as such, the selection of messages to use with offers and answers can affect perceived user latency. Two latency figures are of particular interest. These are the post-pickup delay and the post-dial delay. The post-pickup delay refers to the time between when a user "answers the phone" and when any speech they utter can be delivered to the caller. The post-dial delay refers to the time between when a user enters the destination address for the user and ringback begins as a consequence of having successfully started alerting the called user agent. Two cases can be considered -- one where the offer is present in the initial INVITE and one where it is in a response. Petit-Huguenin, et al. Expires February 14, 2020 [Page 23] Internet-Draft ICE SDP Usage August 2019 7.1.1. Offer in INVITE To reduce post-dial delays, it is RECOMMENDED that the caller begin gathering candidates prior to actually sending its initial INVITE, so that the candidates can be provided in the INVITE. This can be started upon user interface cues that a call is pending, such as activity on a keypad or the phone going off-hook. On the receipt of the offer, the answerer SHOULD generate an answer in a provisional response as soon as it has completed gathering the candidates. ICE requires that a provisional response with an SDP be transmitted reliably. This can be done through the existing Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or through an ICE specific optimization, wherein, the agent retransmits the provisional response with the exponential backoff timers described in [RFC3262]. Such retransmissions MUST cease on receipt of a STUN Binding request with the transport address matching the candidate address for one of the data streams signaled in that SDP or on transmission of the answer in a 2xx response. If no Binding request is received prior to the last retransmit, the agent does not consider the session terminated. For the ICE lite peers, the agent MUST cease retransmitting the 18x after sending it four times since there will be no Binding request sent and the number four is arbitrarily chosen to limit the number of 18x retransmits. Once the answer has been sent, the agent SHOULD begin its connectivity checks. Once candidate pairs for each component of a data stream enter the valid list, the answerer can begin sending media on that data stream. However, prior to this point, any media that needs to be sent towards the caller (such as SIP early media [RFC3960]) MUST NOT be transmitted. For this reason, implementations SHOULD delay alerting the called party until candidates for each component of each data stream have entered the valid list. In the case of a PSTN gateway, this would mean that the setup message into the PSTN is delayed until this point. Doing this increases the post-dial delay, but has the effect of eliminating 'ghost rings'. Ghost rings are cases where the called party hears the phone ring, picks up, but hears nothing and cannot be heard. This technique works without requiring support for, or usage of, preconditions [RFC3312]. It also has the benefit of guaranteeing that not a single packet of media will get clipped, so that post-pickup delay is zero. If an agent chooses to delay local alerting in this way, it SHOULD generate a 180 response once alerting begins. Petit-Huguenin, et al. Expires February 14, 2020 [Page 24] Internet-Draft ICE SDP Usage August 2019 7.1.2. Offer in Response In addition to uses where the offer is in an INVITE, and the answer is in the provisional and/or 200 OK response, ICE works with cases where the offer appears in the response. In such cases, which are common in third party call control [RFC3725], ICE agents SHOULD generate their offers in a reliable provisional response (which MUST utilize [RFC3262]), and not alert the user on receipt of the INVITE. The answer will arrive in a PRACK. This allows for ICE processing to take place prior to alerting, so that there is no post-pickup delay, at the expense of increased call setup delays. Once ICE completes, the callee can alert the user and then generate a 200 OK when they answer. The 200 OK would contain no SDP, since the offer/answer exchange has completed. Alternatively, agents MAY place the offer in a 2xx instead (in which case the answer comes in the ACK). When this happens, the callee will alert the user on receipt of the INVITE, and the ICE exchanges will take place only after the user answers. This has the effect of reducing call setup delay, but can cause substantial post-pickup delays and media clipping. 7.2. SIP Option Tags and Media Feature Tags [RFC5768] specifies a SIP option tag and media feature tag for usage with ICE. ICE implementations using SIP SHOULD support this specification, which uses a feature tag in registrations to facilitate interoperability through signaling intermediaries. 7.3. Interactions with Forking ICE interacts very well with forking. Indeed, ICE fixes some of the problems associated with forking. Without ICE, when a call forks and the caller receives multiple incoming data streams, it cannot determine which data stream corresponds to which callee. With ICE, this problem is resolved. The connectivity checks which occur prior to transmission of media carry username fragments, which in turn are correlated to a specific callee. Subsequent media packets that arrive on the same candidate pair as the connectivity check will be associated with that same callee. Thus, the caller can perform this correlation as long as it has received an answer. 7.4. Interactions with Preconditions Quality of Service (QoS) preconditions, which are defined in [RFC3312] and [RFC4032], apply only to the transport addresses listed as the default targets for media in an offer/answer. If ICE changes Petit-Huguenin, et al. Expires February 14, 2020 [Page 25] Internet-Draft ICE SDP Usage August 2019 the transport address where media is received, this change is reflected in an updated offer that changes the default destination for media to match ICE's selection. As such, it appears like any other re-INVITE would, and is fully treated in RFCs 3312 and 4032, which apply without regard to the fact that the destination for media is changing due to ICE negotiations occurring "in the background". Indeed, an agent SHOULD NOT indicate that QoS preconditions have been met until the checks have completed and selected the candidate pairs to be used for media. ICE also has (purposeful) interactions with connectivity preconditions [RFC5898]. Those interactions are described there. Note that the procedures described in Section 7.1 describe their own type of "preconditions", albeit with less functionality than those provided by the explicit preconditions in [RFC5898]. 7.5. Interactions with Third Party Call Control ICE works with Flows I, III, and IV as described in [RFC3725]. Flow I works without the controller supporting or being aware of ICE. Flow IV will work as long as the controller passes along the ICE attributes without alteration. Flow II is fundamentally incompatible with ICE; each agent will believe itself to be the answerer and thus never generate a re-INVITE. The flows for continued operation, as described in Section 7 of [RFC3725], require additional behavior of ICE implementations to support. In particular, if an agent receives a mid-dialog re-INVITE that contains no offer, it MUST restart ICE for each data stream and go through the process of gathering new candidates. Furthermore, that list of candidates SHOULD include the ones currently being used for media. 8. Interactions with Application Layer Gateways and SIP Application Layer Gateways (ALGs) are functions present in a Network Address Translation (NAT) device that inspect the contents of packets and modify them, in order to facilitate NAT traversal for application protocols. Session Border Controllers (SBCs) are close cousins of ALGs, but are less transparent since they actually exist as application-layer SIP intermediaries. ICE has interactions with SBCs and ALGs. If an ALG is SIP aware but not ICE aware, ICE will work through it as long as the ALG correctly modifies the SDP. A correct ALG implementation behaves as follows: Petit-Huguenin, et al. Expires February 14, 2020 [Page 26] Internet-Draft ICE SDP Usage August 2019 o The ALG does not modify the "m=" and "c=" lines or the rtcp attribute if they contain external addresses. o If the "m=" and "c=" lines contain internal addresses, the modification depends on the state of the ALG: * If the ALG already has a binding established that maps an external port to an internal connection address and port matching the values in the "m=" and "c=" lines or rtcp attribute, the ALG uses that binding instead of creating a new one. * If the ALG does not already have a binding, it creates a new one and modifies the SDP, rewriting the "m=" and "c=" lines and rtcp attribute. Unfortunately, many ALGs are known to work poorly in these corner cases. ICE does not try to work around broken ALGs, as this is outside the scope of its functionality. ICE can help diagnose these conditions, which often show up as a mismatch between the set of candidates and the "m=" and "c=" lines and rtcp attributes. The ice- mismatch attribute is used for this purpose. ICE works best through ALGs when the signaling is run over TLS. This prevents the ALG from manipulating the SDP messages and interfering with ICE operation. Implementations that are expected to be deployed behind ALGs SHOULD provide for TLS transport of the SDP. If an SBC is SIP aware but not ICE aware, the result depends on the behavior of the SBC. If it is acting as a proper Back-to-Back User Agent (B2BUA), the SBC will remove any SDP attributes it doesn't understand, including the ICE attributes. Consequently, the call will appear to both endpoints as if the other side doesn't support ICE. This will result in ICE being disabled, and media flowing through the SBC, if the SBC has requested it. If, however, the SBC passes the ICE attributes without modification, yet modifies the default destination for media (contained in the "m=" and "c=" lines and rtcp attribute), this will be detected as an ICE mismatch, and ICE processing is aborted for the call. It is outside of the scope of ICE for it to act as a tool for "working around" SBCs. If one is present, ICE will not be used and the SBC techniques take precedence. 9. Security Considerations The generic ICE security considerations are defined in [RFC8445], and the generic SDP offer/answer security considerations are defined in [RFC3264]. These security considerations also apply to implementations of this document. Petit-Huguenin, et al. Expires February 14, 2020 [Page 27] Internet-Draft ICE SDP Usage August 2019 9.1. IP Address Privacy In some cases, e.g., for privacy reasons, an agent may not want to reveal the related address and port. In this case the address MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 candidates) and the port to '9'. 9.2. Attacks on the Offer/Answer Exchanges An attacker that can modify or disrupt the offer/answer exchanges themselves can readily launch a variety of attacks with ICE. They could direct media to a target of a DoS attack, they could insert themselves into the data stream, and so on. These are similar to the general security considerations for offer/answer exchanges, and the security considerations in [RFC3264] apply. These require techniques for message integrity and encryption for offers and answers, which are satisfied by the TLS mechanism [RFC3261] when SIP is used. As such, the usage of TLS with ICE is RECOMMENDED. 9.3. The Voice Hammer Attack The voice hammer attack is an amplification attack, and can be triggered even if the attacker is an authenticated and valid participant in a session. In this attack, the attacker initiates sessions to other agents, and maliciously includes the connection address and port of a DoS target as the destination for media traffic signaled in the SDP. This causes substantial amplification; a single offer/answer exchange can create a continuing flood of media packets, possibly at high rates (consider video sources). The use of ICE can help to prevent against this attack. Specifically, if ICE is used, the agent receiving the malicious SDP will first perform connectivity checks to the target of media before sending media there. If this target is a third-party host, the checks will not succeed, and media is never sent. Unfortunately, ICE doesn't help if it's not used, in which case an attacker could simply send the offer without the ICE parameters. However, in environments where the set of clients is known, and is limited to ones that support ICE, the server can reject any offers or answers that don't indicate ICE support. SIP User Agents (UA) [RFC3261] that are not willing to receive non- ICE answers MUST include an "ice" Option Tag [RFC5768] in the SIP Require Header Field in their offer. UAs that reject non-ICE offers will generally use a 421 response code, together with an Option Tag "ice" in the Require Header Field in the response. Petit-Huguenin, et al. Expires February 14, 2020 [Page 28] Internet-Draft ICE SDP Usage August 2019 10. IANA Considerations 10.1. SDP Attributes The original ICE specification defined seven new SDP attributes per the procedures of Section 8.2.4 of [RFC4566]. The registration information from the original specification is included here with modifications to include Mux Category and also defines a new SDP attribute 'ice-pacing'. 10.1.1. candidate Attribute Attribute Name: candidate Type of Attribute: media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides one of many possible candidate addresses for communication. These addresses are validated with an end-to-end connectivity check using Session Traversal Utilities for NAT (STUN). Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact Email: iesg@ietf.org Reference: RFCXXXX Mux Category: TRANSPORT 10.1.2. remote-candidates Attribute Attribute Name: remote-candidates Type of Attribute: media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the identity of the remote candidates that the offerer wishes the answerer to use in its answer. Appropriate Values: See Section 5 of RFC XXXX. Petit-Huguenin, et al. Expires February 14, 2020 [Page 29] Internet-Draft ICE SDP Usage August 2019 Contact Name: IESG Contact Email: iesg@ietf.org Reference: RFCXXXX Mux Category: TRANSPORT 10.1.3. ice-lite Attribute Attribute Name: ice-lite Type of Attribute: session-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent has the minimum functionality required to support ICE inter-operation with a peer that has a full implementation. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact Email: iesg@ietf.org Reference: RFCXXXX Mux Category: NORMAL 10.1.4. ice-mismatch Attribute Attribute Name: ice-mismatch Type of Attribute: media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates that an agent is ICE capable, but did not proceed with ICE due to a mismatch of candidates with the default destination for media signaled in the SDP. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Petit-Huguenin, et al. Expires February 14, 2020 [Page 30] Internet-Draft ICE SDP Usage August 2019 Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux Category: NORMAL 10.1.5. ice-pwd Attribute Attribute Name: ice-pwd Type of Attribute: session- or media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the password used to protect STUN connectivity checks. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux Category: TRANSPORT 10.1.6. ice-ufrag Attribute Attribute Name: ice-ufrag Type of Attribute: session- or media-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and provides the fragments used to construct the username in STUN connectivity checks. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Petit-Huguenin, et al. Expires February 14, 2020 [Page 31] Internet-Draft ICE SDP Usage August 2019 Mux Category: TRANSPORT 10.1.7. ice-options Attribute Attribute Name: ice-options Long Form: ice-options Type of Attribute: session-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE), and indicates the ICE options or extensions used by the agent. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux Category: NORMAL 10.1.8. ice-pacing Attribute This specification also defines a new SDP attribute, "ice-pacing" according to the following data: Attribute Name: ice-pacing Type of Attribute: session-level Subject to charset: No Purpose: This attribute is used with Interactive Connectivity Establishment (ICE) to indicate desired connectivity check pacing values. Appropriate Values: See Section 5 of RFC XXXX. Contact Name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Petit-Huguenin, et al. Expires February 14, 2020 [Page 32] Internet-Draft ICE SDP Usage August 2019 Mux Category: NORMAL 10.2. Interactive Connectivity Establishment (ICE) Options Registry IANA maintains a registry for ice-options identifiers under the Specification Required policy as defined in "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC8126]. ICE options are of unlimited length according to the syntax in Section 5.6; however, they are RECOMMENDED to be no longer than 20 characters. This is to reduce message sizes and allow for efficient parsing. ICE options are defined at the session level. A registration request MUST include the following information: o The ICE option identifier to be registered o Short description of the ICE extension to which the option relates o Reference(s) to the specification defining the ICE option and the related extensions 10.3. Candidate Attribute Extension Subregistry Establishment This section creates a new sub-registry, "Candidate Attribute Extensions", under the sdp-parameters registry: http://www.iana.org/assignments/sdp-parameters. The purpose of the sub-registry is to register SDP candidate attribute extensions. When a candidate extension is registered in the sub-registry, it needs to meet the "Specification Required" policies defined in [RFC8126]. Candidate attribute extensions MUST follow the 'cand-extension' syntax. The attribute extension name MUST follow the 'extension-att- name' syntax, and the attribute extension value MUST follow the 'extension-att-value' syntax. A registration request MUST include the following information: o The name of the attribute extension. o A short description of the attribute extension. o A reference to a specification that describes the semantics, usage and possible values of the attribute extension. Petit-Huguenin, et al. Expires February 14, 2020 [Page 33] Internet-Draft ICE SDP Usage August 2019 11. Acknowledgments A large part of the text in this document was taken from [RFC5245], authored by Jonathan Rosenberg. Some of the text in this document was taken from [RFC6336], authored by Magnus Westerlund and Colin Perkins. Many thanks to Flemming Andreasen for shepherd review feedback. Thanks to following experts for their reviews and constructive feedback: Thomas Stach, Adam Roach, Peter Saint-Andre, Roman Danyliw, Alissa Cooper, Benjamin Kaduk, Mirja Kuhlewind, Alexey Melnikov, Eric Vyncke for their detailed reviews. 12. Changes from RFC 5245 [RFC8445] describes the changes that were done to the common SIP procedures, including removal of aggressive nomination, modifying the procedures for calculating candidate pair states and scheduling connectivity checks and the calculation of timer values. This document defines the following SDP offer/answer specific changes: o SDP offer/answer realization and usage of of 'ice2' option. o Definition and usage of SDP 'ice-pacing' attribute. o Explicit text that an ICE agent must not generate candidates with FQDNs, and must discard such candidates if received from the peer agent. o Relax requirement to include SDP 'rtcp' attribute. o Generic clarifications of SDP offer/answer procedures. 13. References 13.1. Normative References [draft-ietf-ice-pac] Holmberg, C. and J. Uberti, "Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)", draft-ietf-ice-pac-02 (work in progress), July 2019, . Petit-Huguenin, et al. Expires February 14, 2020 [Page 34] Internet-Draft ICE SDP Usage August 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October 2002, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, DOI 10.17487/RFC4032, March 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . Petit-Huguenin, et al. Expires February 14, 2020 [Page 35] Internet-Draft ICE SDP Usage August 2019 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5768] Rosenberg, J., "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April 2010, . [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, DOI 10.17487/RFC6336, July 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 13.2. Informative References [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . Petit-Huguenin, et al. Expires February 14, 2020 [Page 36] Internet-Draft ICE SDP Usage August 2019 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, . [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, "Connectivity Preconditions for Session Description Protocol (SDP) Media Streams", RFC 5898, DOI 10.17487/RFC5898, July 2010, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Appendix A. Examples For the example shown in section 15 of [RFC8445] the resulting offer (message 5) encoded in SDP looks like: v=0 o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP s= c=IN IP6 $NAT-PUB-1.IP t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio $NAT-PUB-1.PORT RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT The offer, with the variables replaced with their values, will look like (lines folded for clarity): Petit-Huguenin, et al. Expires February 14, 2020 [Page 37] Internet-Draft ICE SDP Usage August 2019 v=0 o=jdoe 2890844526 2890842807 IN IP6 fe80::6676:baff:fe9c:ee4a s= c=IN IP6 2001:db8:8101:3a55:4858:a2a9:22ff:99b9 t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 fe80::6676:baff:fe9c:ee4a 8998 typ host a=candidate:2 1 UDP 1694498815 2001:db8:8101:3a55:4858:a2a9:22ff:99b9 45664 typ srflx raddr fe80::6676:baff:fe9c:ee4a rport 8998 The resulting answer looks like: v=0 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP s= c=IN IP4 $R-PUB-1.IP t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=audio $R-PUB-1.PORT RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host With the variables filled in: Petit-Huguenin, et al. Expires February 14, 2020 [Page 38] Internet-Draft ICE SDP Usage August 2019 v=0 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 a=ice-options:ice2 a=ice-pacing:50 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-ufrag:9uB6 m=audio 3478 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host Appendix B. The remote-candidates Attribute The "a=remote-candidates" attribute exists to eliminate a race condition between the updated offer and the response to the STUN Binding request that moved a candidate into the Valid list. This race condition is shown in Figure 1. On receipt of message 4, agent L adds a candidate pair to the valid list. If there was only a single data stream with a single component, agent L could now send an updated offer. However, the check from agent R has not yet generated a response, and agent R receives the updated offer (message 7) before getting the response (message 9). Thus, it does not yet know that this particular pair is valid. To eliminate this condition, the actual candidates at R that were selected by the offerer (the remote candidates) are included in the offer itself, and the answerer delays its answer until those pairs validate. Petit-Huguenin, et al. Expires February 14, 2020 [Page 39] Internet-Draft ICE SDP Usage August 2019 Agent L Network Agent R |(1) Offer | | |------------------------------------------>| |(2) Answer | | |<------------------------------------------| |(3) STUN Req. | | |------------------------------------------>| |(4) STUN Res. | | |<------------------------------------------| |(5) STUN Req. | | |<------------------------------------------| |(6) STUN Res. | | |-------------------->| | | |Lost | |(7) Offer | | |------------------------------------------>| |(8) STUN Req. | | |<------------------------------------------| |(9) STUN Res. | | |------------------------------------------>| |(10) Answer | | |<------------------------------------------| Figure 1: Race Condition Flow Appendix C. Why Is the Conflict Resolution Mechanism Needed? When ICE runs between two peers, one agent acts as controlled, and the other as controlling. Rules are defined as a function of implementation type and offerer/answerer to determine who is controlling and who is controlled. However, the specification mentions that, in some cases, both sides might believe they are controlling, or both sides might believe they are controlled. How can this happen? The condition when both agents believe they are controlled shows up in third party call control cases. Consider the following flow: Petit-Huguenin, et al. Expires February 14, 2020 [Page 40] Internet-Draft ICE SDP Usage August 2019 A Controller B |(1) INV() | | |<-------------| | |(2) 200(SDP1) | | |------------->| | | |(3) INV() | | |------------->| | |(4) 200(SDP2) | | |<-------------| |(5) ACK(SDP2) | | |<-------------| | | |(6) ACK(SDP1) | | |------------->| Figure 2: Role Conflict Flow This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact, it works better than flow III since it produces fewer messages. In this flow, the controller sends an offerless INVITE to agent A, which responds with its offer, SDP1. The agent then sends an offerless INVITE to agent B, which it responds to with its offer, SDP2. The controller then uses the offer from each agent to generate the answers. When this flow is used, ICE will run between agents A and B, but both will believe they are in the controlling role. With the role conflict resolution procedures, this flow will function properly when ICE is used. At this time, there are no documented flows that can result in the case where both agents believe they are controlled. However, the conflict resolution procedures allow for this case, should a flow arise that would fit into this category. Appendix D. Why Send an Updated Offer? Section 11.1 describes rules for sending media. Both agents can send media once ICE checks complete, without waiting for an updated offer. Indeed, the only purpose of the updated offer is to "correct" the SDP so that the default destination for media matches where media is being sent based on ICE procedures (which will be the highest- priority nominated candidate pair). This raises the question -- why is the updated offer/answer exchange needed at all? Indeed, in a pure offer/answer environment, it would not be. The offerer and answerer will agree on the candidates to use through ICE, and then can begin using them. As far as the agents themselves are concerned, the updated offer/answer provides no new information. However, in practice, numerous components along the signaling path look at the SDP information. These include entities Petit-Huguenin, et al. Expires February 14, 2020 [Page 41] Internet-Draft ICE SDP Usage August 2019 performing off-path QoS reservations, NAT traversal components such as ALGs and Session Border Controllers (SBCs), and diagnostic tools that passively monitor the network. For these tools to continue to function without change, the core property of SDP -- that the existing, pre-ICE definitions of the addresses used for media -- the "m=" and "c=" lines and the rtcp attribute -- must be retained. For this reason, an updated offer must be sent. Appendix E. Contributors Following experts have contributed textual and structural improvements for this work 1. Thomas Stach * thomass.stach@gmail.com Authors' Addresses Marc Petit-Huguenin Impedance Mismatch Email: marc@petit-huguenin.org Suhas Nandakumar Cisco Systems 707 Tasman Dr Milpitas, CA 95035 USA Email: snandaku@cisco.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Petit-Huguenin, et al. Expires February 14, 2020 [Page 42] Internet-Draft ICE SDP Usage August 2019 Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Petit-Huguenin, et al. Expires February 14, 2020 [Page 43] ./draft-ietf-mmusic-msid-17.txt0000644000764400076440000011224513404421776015624 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track December 13, 2018 Expires: June 16, 2019 WebRTC MediaStream Identification in the Session Description Protocol draft-ietf-mmusic-msid-17 Abstract This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams. This mechanism is used to signal the association between the SDP concept of "media description" and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. Requirements Language 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 RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 16, 2019. Alvestrand Expires June 16, 2019 [Page 1] Internet-Draft MSID in SDP December 2018 Copyright Notice Copyright (c) 2018 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Structure Of This Document . . . . . . . . . . . . . . . 3 1.3. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 4 1.4. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 9 3.2.1. Generating the initial offer . . . . . . . . . . . . 9 3.2.2. Answerer processing of the Offer . . . . . . . . . . 9 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 10 3.2.4. Offerer processing of the answer . . . . . . . . . . 10 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 10 3.3. Example SDP description . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.1. Attribute registration in existing registries . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Design considerations, rejected alternatives . . . . 14 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16 Alvestrand Expires June 16, 2019 [Page 2] Internet-Draft MSID in SDP December 2018 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 17 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 18 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 18 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 18 B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 18 B.22. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19 B.23. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. Terminology This document uses terminology from [I-D.ietf-rtcweb-overview]. In addition, the following terms are used as described below: RTP stream Defined in [RFC7656] as a stream of RTP packets containing media data. MediaStream Defined in [W3C.CR-mediacapture-streams-20160519]as an assembly of MediaStreamTracks. One MediaStream can contain multiple MediaStreamTracks, of the same or different types. MediaStreamTrack Defined in [W3C.CR-mediacapture-streams-20160519]as an unidirectional flow of media data (either audio or video, but not both). Corresponds to the [RFC7656] term "Source Stream". One MediaStreamTrack can be present in zero, one or multiple MediaStreams. Media description Defined in [RFC4566] as a set of fields starting with an "m=" field and terminated by eitehr the next "m=" field or by the end of the session description. 1.2. Structure Of This Document This document adds a new Session Description Protocol (SDP) [RFC4566] mechanism that can attach identifiers to the RTP streams and attaching identifiers to the groupings they form. It is designed for use with WebRTC[I-D.ietf-rtcweb-overview] . Alvestrand Expires June 16, 2019 [Page 3] Internet-Draft MSID in SDP December 2018 Section 1.3 gives the background on why a new mechanism is needed. Section 2 gives the definition of the new mechanism. Section 3 gives the necessary semantic information and procedures for using the msid attribute to signal the association of MediaStreamTracks to MediaStreams in support of the WebRTC API [W3C.WD-webrtc-20160531]. 1.3. Why A New Mechanism Is Needed When media is carried by RTP [RFC3550], each RTP stream is distinguished inside an RTP session by its SSRC; each RTP session is distinguished from all other RTP sessions by being on a different transport association (strictly speaking, 2 transport associations, one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing [RFC5761] is used). SDP [RFC4566] gives a format for describing an SDP session that can contain multiple media descriptions. According to the model used in [I-D.ietf-rtcweb-jsep], each media description describes exactly one media source, and if multiple media sources are carried in an RTP session, this is signalled using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each media source is carried in its own RTP session. The SDP grouping framework [RFC5888] can be used to group media descriptions. However, for the use case of WebRTC, there is the need for an application to specify some application-level information about the association between the media description and the group. This is not possible using the SDP grouping framework. 1.4. The WEBRTC MediaStream The W3C WebRTC API specification [W3C.WD-webrtc-20160531] specifies that communication between WebRTC entities is done via MediaStreams, which contain MediaStreamTracks. A MediaStreamTrack is generally carried using a single SSRC in an RTP session (forming an RTP stream. The collision of terminology is unfortunate.) There might possibly be additional SSRCs, possibly within additional RTP sessions, in order to support functionality like forward error correction or simulcast. These additional SSRCs are not affected by this specification. MediaStreamTracks are unidirectional; they carry media on one direction only. Alvestrand Expires June 16, 2019 [Page 4] Internet-Draft MSID in SDP December 2018 In the RTP specification, RTP streams are identified using the SSRC field. Streams are grouped into RTP Sessions, and also carry a CNAME. Neither CNAME nor RTP session correspond to a MediaStream. Therefore, the association of an RTP stream to MediaStreams need to be explicitly signaled. WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where one SDP media description is used to describe each MediaStreamTrack, and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group MediaStreamTracks into RTP sessions. Therefore, the need is to specify the ID of a MediaStreamTrack and its associated MediaStream for each media description, which can be accomplished with a media-level SDP attribute. This usage is described in Section 3. 2. The Msid Mechanism This document defines a new SDP [RFC4566] media-level "msid" attribute. This new attribute allows endpoints to associate RTP streams that are described in different media descriptions with the same MediaStreams as defined in [W3C.WD-webrtc-20160531], and to carry an identifier for each MediaStreamTrack in its "appdata" field. The value of the "msid" attribute consists of an identifier and an optional "appdata" field. The name of the attribute is "msid". The value of the attribute is specified by the following ABNF [RFC5234] grammar: msid-value = msid-id [ SP msid-appdata ] msid-id = 1*64token-char ; see RFC 4566 msid-appdata = 1*64token-char ; see RFC 4566 An example msid value for a group with the identifier "examplefoo" and application data "examplebar" might look like this: msid:examplefoo examplebar The identifier is a string of ASCII characters that are legal in a "token", consisting of between 1 and 64 characters. Application data (msid-appdata) is carried on the same line as the identifier, separated from the identifier by a space. Alvestrand Expires June 16, 2019 [Page 5] Internet-Draft MSID in SDP December 2018 The identifier (msid-id) uniquely identifies a group within the scope of an SDP description. There may be multiple msid attributes in a single media description. This represents the case where a single MediaStreamTrack is present in multiple MediaStreams; the value of "msid-appdata" MUST be identical for all occurences. Multiple media descriptions with the same value for msid-id and msid- appdata are not permitted. Endpoints can update the associations between RTP streams as expressed by msid attributes at any time. The msid attributes depend on the association of RTP streams with media descriptions, but does not depend on the association of RTP streams with RTP transports; therefore, its mux category (as defined in [I-D.ietf-mmusic-sdp-mux-attributes]) is NORMAL - the process of deciding on MSID attributes doesn't have to take into consideration whether the RTP streams are bundled or not. 3. Procedures This section describes the procedures for associating media descriptions representing MediaStreamTracks within MediaStreams as defined in [W3C.WD-webrtc-20160531]. In the Javascript API described in that specification, each MediaStream and MediaStreamTrack has an "id" attribute, which is a DOMString. The value of the "msid-id" field in the msid consists of the "id" attribute of a MediaStream, as defined in the MediaStream's WebIDL specification. The special value "-" indicates "no MediaStream". The value of the "msid-appdata" field in the msid, if present, consists of the "id" attribute of a MediaStreamTrack, as defined in the MediaStreamTrack's WebIDL specification. When an SDP session description is updated, a specific "msid-id" value continues to refer to the same MediaStream, and a specific "msid-appdata" to the same MediaStreamTrack. There is no memory apart from the currently valid SDP descriptions; if an msid "identifier" value disappears from the SDP and appears in a later negotiation, it will be taken to refer to a new MediaStream. If the MSID attribute does not conform to the ABNF given here, it SHOULD be ignored. Alvestrand Expires June 16, 2019 [Page 6] Internet-Draft MSID in SDP December 2018 The following is a high level description of the rules for handling SDP updates. Detailed procedures are in Section 3.2. o When a new msid "identifier" value occurs in a session description, and it is not "-", the recipient can signal to its application that a new MediaStream has been added. o When a session description is updated to have media descriptions with an msid "identifier" value, with one or more different "appdata" values, the recipient can signal to its application that new MediaStreamTracks have been added, and which MediaStream it has been added to. This is done for each different msid "identifier" value, including the special value "-", which indicates that a MediaStreamTrack has been added with no corresponding MediaStream. o If an msid "identifier" value with no "appdata" value appears, it means that the sender did not inform the recipient of the desired identifier of the MediaStreamTrack, and the recipient will assign the "id" value of the created MediaStreamTrack on its own. All msid in a media section that do not have an "appdata" value are assumed to refer to the same MediaStreamTrack. o When a session description is updated to no longer list any msid attribute on a specific media description, the recipient can signal to its application that the corresponding MediaStreamTrack has ended. In addition to signaling that the track is ended when its msid attribute disappears from the SDP, the track will also be signaled as being ended when all associated SSRCs have disappeared by the rules of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), or when the corresponding media description is disabled by setting the port number to zero. Changing the direction of the media description (by setting "sendonly", "recvonly" or "inactive" attributes) will not end the MediaStreamTrack. The association between SSRCs and media descriptions is specified in [I-D.ietf-rtcweb-jsep]. 3.1. Handling of non-signalled tracks Entities that do not use msid will not send msid. This means that there will be some incoming RTP packets that the recipient has no predefined MediaStream id value for. Note that this handling is triggered by incoming RTP packets, not by SDP negotiation. Alvestrand Expires June 16, 2019 [Page 7] Internet-Draft MSID in SDP December 2018 When MSID is used, the only time this can happen is when, after the initial negotiation, a negotiation is performed where the answerer adds a MediaStreamTrack to an already established connection and starts sending data before the answer is received by the offerer. For initial negotiation, packets won't flow until the ICE candidates and fingerprints have been exchanged, so this is not an issue. The recipient of those packets will perform the following steps: o When RTP packets are initially received, it will create an appropriate MediaStreamTrack based on the type of the media (carried in PayloadType), and use the MID RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate the RTP packets with a specific media section. o If the connection is not in the RTCSignalingState "stable", it will wait at this point. o When the connection is in the RTCSignalingState "stable", it will assign ID values. The following steps are performed to assign ID values: o If there is an msid attribute, it will use that attribute to populate the "id" field of the MediaStreamTrack and associated MediaStreams, as described above. o If there is no msid attribute, the identifier of the MediaStreamTrack will be set to a randomly generated string, and it will be signalled as being part of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream". o After deciding on the "id" field to be applied to the MediaStreamTrack, the track will be signalled to the user. The process above may involve a considerable amount of buffering before the stable state is entered. If the implementation wishes to limit this buffering, it MUST signal to the user that media has been discarded. It follows from the above that MediaStreamTracks in the "default" MediaStream cannot be closed by removing the msid attribute; the application must instead signal these as closed when the SSRC disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 or by disabling the media description by setting its port to zero. Alvestrand Expires June 16, 2019 [Page 8] Internet-Draft MSID in SDP December 2018 3.2. Detailed Offer/Answer Procedures These procedures are given in terms of RFC 3264-recommended sections. They describe the actions to be taken in terms of MediaStreams and MediaStreamTracks; they do not include event signalling inside the application, which is described in JSEP. 3.2.1. Generating the initial offer For each media description in the offer, if there is an associated outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to the section for each MediaStream with which the MediaStreamTrack is associated. The "identifier" field of the attribute is set to the WebIDL "id" attribute of the MediaStream. If the sender wishes to signal identifiers for the MediaStreamTracks, the "appdata" field is set to the WebIDL "id" attribute of the MediaStreamTrack; otherwise it is omitted. 3.2.2. Answerer processing of the Offer For each media description in the offer, and for each "a=msid" attribute in the media description, the receiver of the offer will perform the following steps: o Extract the "appdata" field of the "a=msid" attribute, if present. o If the "appdata" field exists: Check if a MediaStreamTrack with the same WebIDL "id" attribute as the "appdata" field already exists, and is not in the "ended" state. If it is not found, create it. o If the "appdata" field does not exist, and a MediaStreamTrack is not associated with this media section, create one and associate it with this media section for future use. o Extract the "identifier" field of the "a=msid" attribte. o Check if a MediaStream with the same WebIDL "id" attribute already exists. If not, create it. o Add the MediaStreamTrack to the MediaStream o Signal to the user that a new MediaStreamTrack is available. Alvestrand Expires June 16, 2019 [Page 9] Internet-Draft MSID in SDP December 2018 3.2.3. Generating the answer The answer is generated in exactly the same manner as the offer. "a=msid" values in the offer do not influence the answer. 3.2.4. Offerer processing of the answer The answer is processed in exactly the same manner as the offer. 3.2.5. Modifying the session On subsequent exchanges, precisely the same procedure as for the initial offer/answer is followed, but with one additional step in the parsing of the offer and answer: o For each MediaStreamTrack that has been created as a result of previous offer/answer exchanges, and is not in the "ended" state, check to see if there is still an "a=msid" attribute in the present SDP whose "appdata" field is the same as the WebIDL "id" attribute of the track. o If no such attribute is found, stop the MediaStreamTrack. This will set its state to "ended". 3.3. Example SDP description The following SDP description shows the representation of a WebRTC PeerConnection with two MediaStreams, each of which has one audio and one video track. Only the parts relevant to the MSID are shown. Line wrapping, empty lines and comments are added for clarity. They are not part of the SDP. Alvestrand Expires June 16, 2019 [Page 10] Internet-Draft MSID in SDP December 2018 # First MediaStream - id is 4701... m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 a=msid:47017fee-b6c1-4162-929c-a25110252400 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 a=msid:47017fee-b6c1-4162-929c-a25110252400 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 # Second MediaStream - id is 6131.... m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae b94006c5-cade-4e0a-9ed9-d3e6747be7d9 m=video 56504 UDP/TLS/RTP/SAVPF 100 101 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae f30bdb4a-1497-49b5-3198-e0c9a23172e0 4. IANA Considerations 4.1. Attribute registration in existing registries This document requests IANA to register the "msid" attribute in the "att-field (media level only)" registry within the SDP parameters registry, according to the procedures of [RFC4566] The required information for "msid" is: o Contact name, email: IETF, contacted via mmusic@ietf.org, or a successor address designated by IESG o Attribute name: msid o Long-form attribute name: MediaStream group Identifier o Subject to charset: The attribute value contains only ASCII characters, and is therefore not subject to the charset attribute. o Purpose: The attribute can be used to signal the relationship between a WebRTC MediaStream and a set of media descriptions. o Appropriate values: The details of appropriate values are given in RFC XXXX. o MUX category: NORMAL Alvestrand Expires June 16, 2019 [Page 11] Internet-Draft MSID in SDP December 2018 The MUX category is defined in [I-D.ietf-mmusic-sdp-mux-attributes]. 5. Security Considerations An adversary with the ability to modify SDP descriptions has the ability to switch around tracks between MediaStreams. This is a special case of the general security consideration that modification of SDP descriptions needs to be confined to entities trusted by the application. If implementing buffering as mentioned in Section 3.1, the amount of buffering should be limited to avoid memory exhaustion attacks. Careless generation of identifiers can leak privacy-sensitive information. [W3C.CR-mediacapture-streams-20160519] recommends that identifiers are generated using UUID class 3 or 4 as a basis, which avoids such leakage. No other attacks have been identified that depend on this mechanism. 6. Acknowledgements This note is based on sketches from, among others, Justin Uberti and Cullen Jennings. Special thanks to Flemming Andreassen, Ben Campbell, Miguel Garcia, Martin Thomson, Ted Hardie, Adam Roach, Magnus Westerlund, Alissa Cooper, Sue Hares and Paul Kyzivat for their work in reviewing this draft, with many specific language suggestions. 7. References 7.1. Normative References [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 (work in progress), January 2016. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-14 (work in progress), March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . Alvestrand Expires June 16, 2019 [Page 12] Internet-Draft MSID in SDP December 2018 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [W3C.CR-mediacapture-streams-20160519] Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A., and B. Aboba, "Media Capture and Streams", World Wide Web Consortium CR CR-mediacapture-streams-20160519, May 2016, . [W3C.WD-webrtc-20160531] Wilson, C. and J. Kalliokoski, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20160531, May 2016, . 7.2. Informative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-29 (work in progress), April 2016. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-15 (work in progress), January 2016. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/ RFC5761, April 2010, . Alvestrand Expires June 16, 2019 [Page 13] Internet-Draft MSID in SDP December 2018 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . Appendix A. Design considerations, rejected alternatives One suggested mechanism has been to use CNAME instead of a new attribute. This was abandoned because CNAME identifies a synchronization context; one can imagine both wanting to have tracks from the same synchronization context in multiple MediaStreams and wanting to have tracks from multiple synchronization contexts within one MediaStream (but the latter is impossible, since a MediaStream is defined to impose synchronization on its members). Another suggestion has been to put the msid value within an attribute of RTCP SR (sender report) packets. This doesn't offer the ability to know that you have seen all the tracks currently configured for a MediaStream. A suggestion that survived for a number of drafts was to define "msid" as a generic mechanism, where the particular semantics of this usage of the mechanism would be defined by an "a=wms-semantic" attribute. This was removed in April 2015. Appendix B. Change log This appendix should be deleted before publication as an RFC. B.1. Changes from alvestrand-rtcweb-msid-00 to -01 Added track identifier. Added inclusion-by-reference of draft-lennox-mmusic-source-selection for track muting. Some rewording. Alvestrand Expires June 16, 2019 [Page 14] Internet-Draft MSID in SDP December 2018 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 Split document into sections describing a generic grouping mechanism and sections describing the application of this grouping mechanism to the WebRTC MediaStream concept. Removed the mechanism for muting tracks, since this is not central to the MSID mechanism. B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 Changed the draft name according to the wishes of the MMUSIC group chairs. Added text indicting cases where it's appropriate to have the same appdata for multiple SSRCs. Minor textual updates. B.4. Changes from alvestrand-mmusic-msid-00 to -01 Increased the amount of explanatory text, much based on a review by Miguel Garcia. Removed references to BUNDLE, since that spec is under active discussion. Removed distinguished values of the MSID identifier. B.5. Changes from alvestrand-mmusic-msid-01 to -02 Changed the order of the "msid-semantic: " attribute's value fields and allowed multiple identifiers. This makes the attribute useful as a marker for "I understand this semantic". Changed the syntax for "identifier" and "appdata" to be "token". Changed the registry for the "msid-semantic" attribute values to be a new registry, based on advice given in Atlanta. B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 Updated terminology to refer to m-lines rather than RTP sessions when discussing SDP formats and the ability of other linking mechanisms to refer to SSRCs. Changed the "default" mechanism to return independent streams after considering the synchronization problem. Alvestrand Expires June 16, 2019 [Page 15] Internet-Draft MSID in SDP December 2018 Removed the space from between "msid-semantic" and its value, to be consistent with RFC 5576. B.7. Changes from mmusic-msid-00 to -01 Reworked msid mechanism to be a per-m-line attribute, to align with draft-roach-mmusic-unified-plan. B.8. Changes from mmusic-msid-01 to -02 Corrected several missed cases where the word "ssrc" was not changed to "M-line". Added pointer to unified-plan (which should be moved to point to -jsep) Removed suggestion that ssrc-group attributes can be used with "msid- semantic", it is now only the msid-semantic registry. B.9. Changes from mmusic-msid-02 to -03 Corrected even more cases where the word "ssrc" was not changed to "M-line". Added the functionality of using an asterisk (*) in the msid-semantic line, in order to remove the need for listing all msids in the msid- semantic line whne only one msid-semantic is in use. Removed some now-unnecessary text. B.10. Changes from mmusic-msid-03 to -04 Changed title to reflect focus on WebRTC MediaStreams Added a section on receiver-side media stream control, using the "msid-control" attribute. B.11. Changes from -04 to -05 Removed the msid-control section after WG discussion. Removed some text that seemed only to pertain to resolved issues. B.12. Changes from -05 to -06 Addressed issues found in Fleming Andreassen's review Referenced JSEP rather than unified-plan for the M-line mapping model Alvestrand Expires June 16, 2019 [Page 16] Internet-Draft MSID in SDP December 2018 Relaxed MSID definition to allow "token-char" in values rather than a-z 0-9 hyphen; tightened ABNF by adding length description to it. Deleted discussion of abandoned alternatives, as part of preparing for publication. Added a "detailed procedures" section to the WMS semantics description. Added IANA registration of the "msid-semantic" attribute. B.13. Changes from -06 to -07 Changed terminology from referring to "WebRTC device" to referring to "entities that implement the WMS semantic". Changed names for ABNF constructions based on a proposal by Paul Kyzivat. Included a section on generic offer/answer semantics. B.14. Changes from -07 to -08 Removed Appendix B that described the (now obsolete) ssrc-specific usage of MSID. Adopted a restructuring of the IANA section based on a suggestion from Martin Thomson. A number of text and ABNF clarifications based on suggestions from Ted Hardie, Paul Kyzivat and Adam Roach. Changed the "non-signalled track handling" to create a single stream with multiple tracks again, according to discussions at TPAC in November 2014 B.15. Changes from -08 to -09 Removed "wms-semantic" and all mention of multiple semantics for msid, as agreed at the Dallas IETF, March 2015. Addressed a number of review comments from Fleming Andresen and others. Changed the term "m-line" to "media description", since that is the term used in RFC 4566. Alvestrand Expires June 16, 2019 [Page 17] Internet-Draft MSID in SDP December 2018 Tried to make sure this document does not describe the API to the application. B.16. Changes from -09 to -10 Addressed review comments from Paul Kyzivat. B.17. Changes from -10 to -11 Defined the semantics of multiple MSIDs in a media section to be a MediaStreamTrack present in multiple MediaStreams. Made an explicit note that MediaStreamTracks are unidirectional. Disallowed the option of sending multiple media sections with the same msid (id and appdata identical). B.18. Changes from -11 to -12 Added mux-category to the IANA considerations section. B.19. Changes from -12 to -13 Modified registration description to delete dependency on -4566-bis B.20. Changes from -13 to -14 Addressed nits found in Gen-ART review B.21. Changes from -14 to -15 Added the terminology section. Switched from "(RTP) media stream" to "RTP stream" per RFC 7656. Added a mention of random ID generation to the security considerations section. Moved definition pointers for MediaStream and MediaStreamTrack to the "mediacapture-streams" document. Added note that syntactically invalid MSID fields SHOULD be ignored. Various small changes based on review feedback during IESG processing. Alvestrand Expires June 16, 2019 [Page 18] Internet-Draft MSID in SDP December 2018 B.22. Changes from -15 to -16 Added the special "-" value that means "no MediaStream". Changed instances of a MediaStreamTrack being "closed" to saying it's "ended", in accordance with WebRTC terminology. B.23. Changes from -16 to -17 Added text to allow omitting track identifiers, per JSEP PR #850 Author's Address Harald Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Alvestrand Expires June 16, 2019 [Page 19] ./draft-ietf-mmusic-msrp-usage-data-channel-24.txt0000644000764400076440000013427613717047500021272 0ustar iustyiusty MMUSIC J. Recio, Ed. Internet-Draft Unaffiliated Updates: 4975 (if approved) C. Holmberg Intended status: Standards Track Ericsson Expires: February 19, 2021 August 18, 2020 MSRP over Data Channels draft-ietf-mmusic-msrp-usage-data-channel-24 Abstract This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the Message Session Relay Protocol (MSRP) and how the Session Description Protocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel. Two network configurations are supported: connecting two MSRP data channel endpoints; and a gateway configuration, connecting an MSRP data channel endpoint with an MSRP over TCP or TLS endpoint. This document updates RFC4975. This document updates RFC4975. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 19, 2021. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Recio & Holmberg Expires February 19, 2021 [Page 1] Internet-Draft MSRP over Data Channels August 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4 3.1. MSRP Data Channel . . . . . . . . . . . . . . . . . . . . 4 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 4.1. MSRP URI . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. msrp-scheme . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Use of the dcmap Attribute . . . . . . . . . . . . . . . 5 4.4. Use of the dcsa Attribute . . . . . . . . . . . . . . . . 5 4.5. Use of the dcsa embedded setup Attribute . . . . . . . . 6 4.6. Session Closing . . . . . . . . . . . . . . . . . . . . . 7 4.7. Support for MSRP File Transfer Function . . . . . . . . . 7 4.8. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. MSRP Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. Session Mapping . . . . . . . . . . . . . . . . . . . . . 9 5.2. Session Opening . . . . . . . . . . . . . . . . . . . . . 9 5.3. Session Closing . . . . . . . . . . . . . . . . . . . . . 9 5.4. Data Framing . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Data Sending, Receiving and Reporting . . . . . . . . . . 9 5.6. Support for MSRP File Transfer Function . . . . . . . . . 10 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 10 7. Updates to RFC4975 . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.1. msrps URI scheme . . . . . . . . . . . . . . . . . . . . 11 9.2. Subprotocol Identifier MSRP . . . . . . . . . . . . . . . 12 9.3. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The Message Session Relay Protocol (MSRP) [RFC4975] is a protocol for transmitting a series of related instant messages in the context of a session. In addition to instant messaging, MSRP can also be used for image sharing or file transfer. MSRP was initially defined in Recio & Holmberg Expires February 19, 2021 [Page 2] Internet-Draft MSRP over Data Channels August 2020 [RFC4975] to work over TCP and TLS connections, and over a WebSocket subprotocol specified by [RFC7977]. This document specifies how a Web Real-Time Communication (WebRTC) data channel [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism for MSRP, without the TCP and TLS layers, and how the Session Description Protocol (SDP) offer/answer mechanism for data channels [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such a data channel. In this document, an MSRP data channel refers to a WebRTC data channel for which the instantiated subprotocol is "msrp" and where the data channel is negotiated using the SDP offer/answer mechanism [I-D.ietf-mmusic-data-channel-sdpneg]. Defining MSRP as a data channel subprotocol has many benefits: o provides to applications a proven protocol enabling instant messaging, file transfer, image sharing o integrates those features with other WebRTC voice, video and data features o leverages the SDP-based negotiation already defined for MSRP o allows the interworking with MSRP endpoints running on a TCP or TLS connection Compared to WebSockets, which provide a message passing protocol to applications with no direct access to TCP or TLS sockets, data channels provide a low latency transport, leverage NAT-aware connectivity and security features of WebRTC. Considering an MSRP endpoint as an MSRP application that uses a WebRTC data channel, this document describes two configurations where the other endpoint is respectively either another MSRP over data channel endpoint (e.g., a WebRTC application) or an MSRP endpoint using either TCP or TLS transport. This document updates [RFC4975] as described in Section 7. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Recio & Holmberg Expires February 19, 2021 [Page 3] Internet-Draft MSRP over Data Channels August 2020 3. WebRTC Data Channel Considerations 3.1. MSRP Data Channel The following WebRTC data channel property values [I-D.ietf-rtcweb-data-channel] apply to an MSRP data channel: +--------------------------+------------------+ | Property | Value | +--------------------------+------------------+ | Subprotocol Identifier | msrp | | Transmission reliability | reliable | | Transmission order | in-order | | Label | See Section 4.3 | +--------------------------+------------------+ 4. SDP Considerations The generic SDP considerations, including the SDP offer/answer procedures [RFC3264], for negotiating a WebRTC data channel are defined in [I-D.ietf-mmusic-data-channel-sdpneg]. This section, and its subsections, define the SDP considerations that are specific to an MSRP data channel, identified by the 'subprotocol' attribute parameter, with a "msrp" parameter value, in the 'dcmap' attribute. 4.1. MSRP URI This document extends the MSRP URI syntax [RFC4975] by defining the new transport parameter value "dc" (an abbreviation of data channel): transport /= "dc" ; Add "dc" to existing transports per Section 9 of [RFC4975] MSRP design provides for new transport bindings (see Section 6 of [RFC4975]). MSRP implementations are expected to allow unrecognized transports for which there is no need to establish a connection to the resource described by the URI, as it's the case of data channels (Section 4.4). 4.2. msrp-scheme The msrp-scheme portion of the MSRP-URI that represents an MSRP data channel endpoint (used in the SDP path attribute and in the MSRP message headers) is always "msrps", which indicates that the MSRP data channel is always secured using DTLS as described in [I-D.ietf-rtcweb-data-channel]. Recio & Holmberg Expires February 19, 2021 [Page 4] Internet-Draft MSRP over Data Channels August 2020 4.3. Use of the dcmap Attribute An offerer and answerer SHALL, in each offer and answer, include a 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP media description (m= section) [RFC4566] describing the SCTP association [RFC4960] used to realize the MSRP data channel. The attribute includes the following data channel parameters: o "label=" labelstring o "subprotocol=" "msrp" The labelstring is set by the MSRP application according to [I-D.ietf-mmusic-data-channel-sdpneg]. The offerer and answerer SHALL NOT include the 'max-retr' and the 'max-time' attribute parameters in the 'dcmap' attribute. The offerer and answerer MAY include the 'ordered' attribute parameter in the 'dcmap' attribute. If included, the attribute parameter value SHALL be set to "true". Below is an example of a 'dcmap' attribute for an MSRP session to be negotiated with stream-id=2 and label="chat": a=dcmap:2 label="chat";subprotocol="msrp" 4.4. Use of the dcsa Attribute An offerer and answerer can, in each offer and answer, include one or more 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in the m= section describing the SCTP association used to realize the MSPR data channel. An SDP attribute included in a 'dcsa' attribute is referred to as a dcsa embedded attribute. If an offerer or answerer receives a 'dcsa' attribute that contains an SDP attribute which usage has not been defined for an MSRP data channel, the offerer or answerer should ignore the 'dcsa' attribute, following the rules in Section 6.7 of [I-D.ietf-mmusic-data-channel-sdpneg]. An offerer and answerer SHALL include a 'dcsa' attribute for each of the following MSRP-specific SDP attributes: o defined in [RFC4975]: "path". o defined in [RFC6714]: "msrp-cema". Recio & Holmberg Expires February 19, 2021 [Page 5] Internet-Draft MSRP over Data Channels August 2020 o defined in [RFC6135]: "setup". See Section 4.5 It is considered a protocol error if one or more of the dcsa embedded attributes listed above are not included in an offer or answer. An offerer and answerer MAY include a 'dcsa' attribute for any of the following MSRP-specific SDP attributes, following the procedures defined for each attribute: o defined in [RFC4975]: "accept-types", "accept-wrapped-types" and "max-size" o defined in [RFC4566]: "sendonly", "recvonly", "inactive" and "sendrecv" o defined in [RFC5547]: all the parameters related to MSRP file transfer. See Section 4.7. A subsequent offer or answer MAY update the previously negotiated MSRP subprotocol attributes while keeping the 'dcmap' attribute associated with the MSRP data channel unchanged. The semantics for newly negotiated MSRP subprotocol attributes are per [RFC4975]. When MSRP messages are transported on a data channel, the 'path' attribute is not used for routing of the messages. The MSRP data channel is established using the SDP offer/answer procedures defined in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are then transported on that data channel. This is different from legacy MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. Because of this, a dcsa embedded 'msrp-cema' attribute is mandated for MSRP sessions over data channels. However, when an endpoint receives an MSRP message over a data channel, it MUST still perform the MSRP-URI comparison procedures defined in [RFC4975]. 4.5. Use of the dcsa embedded setup Attribute As described in Section 4.4, the usage of a dsca embedded 'setup' attribute is mandated for MSRP sessions over data channels. It is used to negotiate which MSRP session endpoint assumes the active role as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]. It has no relationship with the DTLS connection establishment roles [I-D.ietf-mmusic-sctp-sdp]. The dcsa embedded setup attribute is of the form "a=dcsa:x setup:", with x being the data channel's SCTP stream identifier, so that such attribute is explicitly associated with an MSRP session over a specific data channel. Recio & Holmberg Expires February 19, 2021 [Page 6] Internet-Draft MSRP over Data Channels August 2020 4.6. Session Closing An MSRP session is closed by closing the associated data channel, following the procedures in [I-D.ietf-mmusic-data-channel-sdpneg]. The port value for the "m=" line SHOULD NOT be changed (e.g. to zero) when closing an MSRP session (unless all data channels are being closed and the SCTP association is no longer needed), since this would close the SCTP association and impact all of the data channels. In all cases in [RFC4975] where the procedure calls for setting the port to zero for the MSRP "m=" line in an SDP offer for TCP transport, the SDP offerer of an MSRP session with data channel transport SHALL remove the corresponding dcmap and dcsa attributes. 4.7. Support for MSRP File Transfer Function SDP attributes specified in [RFC5547] for a file transfer "m=" line are embedded as subprotocol-specific attributes using the syntax defined in [I-D.ietf-mmusic-data-channel-sdpneg]. 4.8. Example Below is an example of an offer and an answer that include the attributes needed to establish two MSRP sessions: one for chat and one for file transfer. The example is derived from a combination of examples in [RFC4975] and [RFC5547]. Offer: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:100000 a=sctp-port:5000 a=setup:actpass a=fingerprint:SHA-256 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:\ 82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD a=tls-id:4a756565cddef001be82 a=dcmap:0 label="chat";subprotocol="msrp" a=dcsa:0 msrp-cema a=dcsa:0 setup:active a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 path:msrps://2001:db8::3:54111/si438dsaodes;dc a=dcmap:2 label="file transfer";subprotocol="msrp" a=dcsa:2 sendonly a=dcsa:2 msrp-cema a=dcsa:2 setup:active a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-wrapped-types:* Recio & Holmberg Expires February 19, 2021 [Page 7] Internet-Draft MSRP over Data Channels August 2020 a=dcsa:2 path:msrps://2001:db8::3:54111/jshA7we;dc a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ size:1463440 hash:sha-256:7C:DF:3E:5D:49:6B:19:E5:12:AB:4A:AD: \ 4A:B1:3F:82:3E:3B:54:12:02:5D:18:DF:49:6B:19:E5:7C:AB:B9:AD a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep a=dcsa:2 file-disposition:attachment a=dcsa:2 file-date:creation:"Tue, 11 Aug 2020 19:05:30 +0200" a=dcsa:2 file-icon:cid:id2@bob.example.com a=dcsa:2 file-range:1-1463440 Answer: m=application 51444 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 IP6 2001:db8::1 a=max-message-size:100000 a=sctp-port:6000 a=setup:passive a=fingerprint:SHA-256 5D:02:3E:AD:49:6B:19:E5:7C:AB:4A:AD:B9:B1: \ 3F:82:18:3B:54:DF:12:6B:3E:5D:49:DF:19:E5:7C:AB:4A:5D a=tls-id:65cd4a7565debe82f100 a=dcmap:0 label="chat";subprotocol="msrp" a=dcsa:0 msrp-cema a=dcsa:0 setup:passive a=dcsa:0 accept-types:message/cpim text/plain a=dcsa:0 path:msrps://2001:db8::1:51444/di551fsaodes;dc a=dcmap:2 label="file transfer";subprotocol="msrp" a=dcsa:2 recvonly a=dcsa:2 msrp-cema a=dcsa:2 setup:passive a=dcsa:2 accept-types:message/cpim a=dcsa:2 accept-wrapped-types:* a=dcsa:2 path:msrps://2001:db8::1:51444/jksh7Bwc;dc a=dcsa:2 file-selector:name:"picture1.jpg" type:image/jpeg \ size:1463440 a=dcsa:2 file-transfer-id:rjEtHAcYVZ7xKwGYpGGwyn5gqsSaU7Ep a=dcsa:2 file-range:1-1463440 Note that due to RFC formatting conventions, this document splits SDP across lines whose content would exceed 72 characters. A backslash character marks where this line folding has taken place. This backslash and its trailing CRLF and whitespace would not appear in actual SDP content. Recio & Holmberg Expires February 19, 2021 [Page 8] Internet-Draft MSRP over Data Channels August 2020 5. MSRP Considerations The procedures specified in [RFC4975] apply except when this document specifies otherwise. This section describes the MSRP considerations specific to an MSRP data channel. 5.1. Session Mapping In this document, each MSRP session maps to one data channel exactly. 5.2. Session Opening Section 4.5 describes how the active MSRP session endpoint role is negotiated. The active MSRP session endpoint uses the data channel established for this MSRP session by the generic data channel opening procedure defined in [I-D.ietf-mmusic-data-channel-sdpneg]. As soon as the WebRTC data channel is opened, the MSRP session is actually opened by the active MSRP session endpoint. In order to do this the active MSRP endpoint sends an MSRP SEND message (empty or not) to the peer (passive) MSRP endpoint. 5.3. Session Closing The closure of an MSRP session SHALL be signaled via SDP following the requirements in Section 4.6 If the data channel used to transport the MSRP session fails and gets torn down, the endpoints SHALL consider the MSRP session failed. An MSRP endpoint MAY, based on local policy, try to negotiate a new MSRP data channel. 5.4. Data Framing Each text-based MSRP message is sent on the corresponding data channel using standard MSRP framing and chunking procedures, as defined in [RFC4975], with each MSRP chunk delivered in a single SCTP user message. Therefore all sent MSRP chunks SHALL have lengths of less than or equal to the value of the peer's "max-message-size" attribute [I-D.ietf-mmusic-sctp-sdp] associated with the SCTP association. 5.5. Data Sending, Receiving and Reporting Data sending, receiving and reporting procedures SHALL conform to [RFC4975]. Recio & Holmberg Expires February 19, 2021 [Page 9] Internet-Draft MSRP over Data Channels August 2020 5.6. Support for MSRP File Transfer Function [RFC5547] defines an end-to-end file transfer method based on MSRP and the SDP offer/answer mechanism. This file transfer method is also usable by MSRP endpoints using data channels, with the following considerations: o As an MSRP session maps to one data channel, a file transfer session maps also to one data channel. o SDP attributes are negotiated as specified in Section 4.7. o Once the file transfer is complete, the same data channel MAY be reused for another file transfer. 6. Gateway Considerations This section describes the network configuration where one MSRP endpoint uses an MSRP data channel as MSRP transport, the other MSRP endpoint uses TLS/TCP connections as MSRP transport, and the two MSRP endpoints interwork via a gateway. Specifically, a gateway can be configured to interwork an MSRP session over a data channel with a peer that does not support data channel transport in one of two ways. In one model, the gateway performs as an MSRP Back-to-Back User Agent (B2BUA) to interwork all the procedures as necessary between the endpoints. No further specification is needed for this model. Alternately, the gateway can provide transport level interworking between MSRP endpoints using different transport protocols. In accordance with Section 4.4, path attributes SHALL NOT be used for transport level interworking. When the gateway performs transport level interworking between MSRP endpoints, all of the procedures in Section 5 and Section 4 apply to each peer, with the following additions: o The gateway SHALL use the MSRP CEMA mechanism [RFC6714] towards the non-data channel endpoint. o If the non-data channel endpoint does not support MSRP CEMA, transport level interworking mode is not possible, the gateway needs to act as an MSRP B2BUA. o The gateway SHALL NOT modify the path attribute received from data channel or from non-data channel endpoints. Recio & Holmberg Expires February 19, 2021 [Page 10] Internet-Draft MSRP over Data Channels August 2020 o The gateway SHALL NOT modify the setup value received from data channel or from non-data channel endpoints. o The endpoint establishing an MSRP session using data channel transport SHALL NOT request inclusion of any relays, although it MAY interoperate with a peer that signals the use of relays. 7. Updates to RFC4975 This document updates [RFC4975], by allowing the usage of the "msrps" scheme when the underlying connection is protected with DTLS. 8. Security Considerations MSRP traffic over data channels is secured, including confidentiality, integrity and source authentication, as specified by by [I-D.ietf-rtcweb-data-channel]. However, [RFC4975] allows transport of MSRP traffic over non-secured TCP connections, and does not provide a mechanism to guarantee usage of TLS end-to-end. As described in [RFC4975], even if TLS is used between some hops TCP might still be used between other hops. Operators need to ensure that proper policies are established in order to ensure that the MSRP traffic is protected between endpoints. [RFC5547] specifies security considerations related to the usage of MSRP for file transfer. [RFC7092] specifies security considerations related to B2BUAs. Note that discussion in Section 14.5 of [RFC4975] on MSRP message attribution to remote identities applies to data channel transport. If the Session Initiation Protocol (SIP) [RFC3261] is used to implement the offer/answer transactions for establishing the MSRP data channel, the SIP security considerations specified in [RFC3261] apply. 9. IANA Considerations NOTE to RFC Editor: Please replace all instances of all instances of RFCXXXX with the number of this RFC. 9.1. msrps URI scheme This document modifies the usage of the msrps URI scheme, registered by [RFC4975], adding DTLS as a protected transport indicated by the URI scheme. Recio & Holmberg Expires February 19, 2021 [Page 11] Internet-Draft MSRP over Data Channels August 2020 A reference to RFCXXXX is added to the URI scheme "msrps" in the Uniform Resource Identifier (URI) Schemes Registry. 9.2. Subprotocol Identifier MSRP A reference to RFCXXXX is added to the subprotocol identifier "msrp" in the "WebSocket Subprotocol Name Registry" 9.3. SDP Attributes This document modifies the usage of a set of SDP attributes, if any of those attributes is included in an SDP 'dsca' attribute associated with an MSRP data channel. The modified usage of the SDP 'setup' attribute is described in Section 4.5. The usage of the other SDP attributes is described in Section 4.4. o "path" o "msrp-cema" o "accept-types" o "accept-wrapped-types" o "max-size" o "sendonly" o "recvonly" o "inactive" o "sendrecv" o "file-selector" o "file-transfer-id" o "file-disposition" o "file-date" o "file-icon" o "file-range" Recio & Holmberg Expires February 19, 2021 [Page 12] Internet-Draft MSRP over Data Channels August 2020 The usage level "dcsa(msrp)" is added to the registration of the SDP 'setup' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | setup | | Usage level: | dcsa(msrp) | | Purpose: | Negotiate the active role of an MSRP | | | session over a data channel as per | | | Section 4.5 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'path' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | path | | Usage level: | dcsa(msrp) | | Purpose: | Indicate an endpoint, but not used for | | | routing, as described in Section 4.4 | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'msrp-cema' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | msrp-cema | | Usage level: | dcsa(msrp) | | Purpose: | Indicate that the routing of MSRP | | | messages transported on a data channel is | | | more similar to the MSRP CEMA mechanism | | | than the legacy MSRP routing mechanism. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'accept-types' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: Recio & Holmberg Expires February 19, 2021 [Page 13] Internet-Draft MSRP over Data Channels August 2020 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | accept-types | | Usage level: | dcsa(msrp) | | Purpose: | Contain the list of media types that the | | | endpoint is willing to receive. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'accept-wrapped-types' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | accept-wrapped-types | | Usage level: | dcsa(msrp) | | Purpose: | Contain the list of media types that the | | | endpoint is willing to receive in an MSRP | | | message with multipart content. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'max-size' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | max-size | | Usage level: | dcsa(msrp) | | Purpose: | Indicate the largest message an MSRP | | | endpoint wishes to accept. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'sendonly' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: Recio & Holmberg Expires February 19, 2021 [Page 14] Internet-Draft MSRP over Data Channels August 2020 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | sendonly | | Usage level: | dcsa(msrp) | | Purpose: | Negotiate the direction of the media flow | | | on an MSRP data channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'recvonly' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | recvonly | | Usage level: | dcsa(msrp) | | Purpose: | Negotiate the direction of the media flow | | | on an MSRP data channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'inactive' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | inactive | | Usage level: | dcsa(msrp) | | Purpose: | Negotiate the direction of the media flow | | | on an MSRP data channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'sendrecv' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: Recio & Holmberg Expires February 19, 2021 [Page 15] Internet-Draft MSRP over Data Channels August 2020 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | sendrecv | | Usage level: | dcsa(msrp) | | Purpose: | Negotiate the direction of the media flow | | | on an MSRP data channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-selector' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-selector | | Usage level: | dcsa(msrp) | | Purpose: | Indicate a file in an MSRP file transfer | | | negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-transfer-id' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-transfer-id | | Usage level: | dcsa(msrp) | | Purpose: | Indicate a unique identifier of the file | | | transfer operation in an MSRP file | | | transfer negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-disposition' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: Recio & Holmberg Expires February 19, 2021 [Page 16] Internet-Draft MSRP over Data Channels August 2020 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-disposition | | Usage level: | dcsa(msrp) | | Purpose: | Provide a suggestion to the other | | | endpoint about the intended disposition | | | of the file in an MSRP file transfer | | | negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-date' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-date | | Usage level: | dcsa(msrp) | | Purpose: | Indicate one or more dates related to the | | | file in an MSRP file transfer | | | negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-icon' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-icon | | Usage level: | dcsa(msrp) | | Purpose: | Contain a pointer to a small preview icon | | | representing the contents of the file in | | | an MSRP file transfer negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(msrp)" is added to the registration of the SDP 'file-range' attribute in the Session Description Protocol (SDP) Parameters "att-field" sub-registry as follows: Recio & Holmberg Expires February 19, 2021 [Page 17] Internet-Draft MSRP over Data Channels August 2020 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | file-range | | Usage level: | dcsa(msrp) | | Purpose: | Contain the range of transferred octets | | | of the file in an MSRP file transfer | | | negotiation. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 10. Acknowledgments The authors wish to acknowledge the borrowing of ideas from another internet draft by Peter Dunkley and Gavin Llewellyn, and to thank Flemming Andreasen, Christian Groves, Paul Kyzivat, Jonathan Lennox, Uwe Rauschenbach, Albrecht Schwarz, and Keith Drage for their invaluable comments. Richard Ejzak, Keith Drage and Juergen Stoetzer-Bradler contributed an earlier version, before the draft was re-adopted. Julien Maisonneuve helped with the re-adoption of the draft, and Maridi R. Makaraju (Raju) contributed valuable comments after the draft was re-adopted. 11. References 11.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, . [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, "SDP-based Data Channel Negotiation", draft-ietf- mmusic-data-channel-sdpneg-28 (work in progress), May 2019. Recio & Holmberg Expires February 19, 2021 [Page 18] Internet-Draft MSRP over Data Channels August 2020 [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, . [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, DOI 10.17487/RFC5547, May 2009, . [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 2011, . [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/RFC6714, August 2012, . [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., and R. Ravindranath, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", RFC 7977, DOI 10.17487/RFC7977, September 2016, . Recio & Holmberg Expires February 19, 2021 [Page 19] Internet-Draft MSRP over Data Channels August 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, . Authors' Addresses Jose M. Recio (editor) Unaffiliated Email: jose@ch3m4.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Recio & Holmberg Expires February 19, 2021 [Page 20] ./draft-ietf-mmusic-mux-exclusive-12.txt0000644000764400076440000006221313103102012017447 0ustar iustyiusty Network Working Group C. Holmberg Internet-Draft Ericsson Updates: 5761 (if approved) May 5, 2017 Intended status: Standards Track Expires: November 6, 2017 Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP draft-ietf-mmusic-mux-exclusive-12.txt Abstract This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 6, 2017. Copyright Notice Copyright (c) 2017 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 Holmberg Expires November 6, 2017 [Page 1] Internet-Draft Exclusive RTP/RTCP Mux May 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SDP rtcp-mux-only Attribute . . . . . . . . . . . . . . . . . 3 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 4.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 5. Update to RFC 5761 . . . . . . . . . . . . . . . . . . . . . 7 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Update to 4th paragraph of section 5.1.1 . . . . . . . . 7 5.3. Update to 2nd paragraph of section 5.1.3 . . . . . . . . 8 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction [RFC5761] defines how to multiplex RTP and RTCP on a single IP address and port, referred to as RTP/RTCP multiplexing. [RFC5761] also defines an Session Description Protocol (SDP) [RFC4566] attribute, 'rtcp-mux' that can be used by entities to indicate support, and negotiate usage of, RTP/RTCP multiplexing. As defined in [RFC5761], if the peer endpoint does not support RTP/ RTCP multiplexing, both endpoints should use separate ports for sending and receiving of RTCP (referred to as fallback to usage of separate ports for RTP and RTCP). Some newer applications that do not require backward compatibility with peers that cannot multiplex RTCP might choose to not implement separation of RTP and RTCP. Examples of such applications are W3C WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required to interoperate with non-WEBRTC clients. For such applications, this document defines an SDP attribute to signal intent to require multiplexing. The use of this attribute in SDP offers [RFC3264] by Holmberg Expires November 6, 2017 [Page 2] Internet-Draft Exclusive RTP/RTCP Mux May 2017 entities that ever need to interoperate with peers that do not support RTC/RTCP multiplexing may harm interoperability. Also, while the SDP answerer [RFC3264] might support, and prefer usage of, fallback to non-multiplex, the attribute indicates that fallback to non-multiplex cannot be enabled. One example of where non-multiplex is preferred is where an endpoint is connected to a radio interface, and wants to use different bearers (possibly with different quality characteristics) for RTP and RTCP. Another example is where the one endpoint is acting as a gateway to a network where RTP/RTCP multiplexing cannot be used. In such case there endpoint may prefer non-multiplexing also towards the other network. Otherwise the endpoint would have to perform de-multiplexing of RTP and RTCP. This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates [RFC5761], by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The document also describes the Interactive Connectivity Establishment (ICE) [RFC5245] considerations when indicating exclusive support of RTP/RTCP multiplexing. 2. Conventions 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]. 3. SDP rtcp-mux-only Attribute This section defines a new SDP media-level attribute, 'rtcp-mux- only'. Holmberg Expires November 6, 2017 [Page 3] Internet-Draft Exclusive RTP/RTCP Mux May 2017 Name: rtcp-mux-only Value: N/A Usage Level: media Charset Dependent: no Syntax: rtcp-mux-only Example: a=rtcp-mux-only In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to indicate exclusive support of RTP/RTCP multiplexing for the RTP- based media associated with the SDP media description ("m=" line). In an SDP answer, the 'rtcp-mux' attribute [RFC5761] indicates that the answerer supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-based media associated with the SDP media description ("m=" line). The usage of the 'rtcp-mux-only' attribute in an SDP answer is forbidden. The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based media. The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- mux-only' attribute is 'IDENTICAL', which means that the attribute, if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. The 'rtcp-mux-only' attribute applies to the whole associated media description. The attribute MUST NOT be defined per source (using the SDP 'ssrc' attribute [RFC5576]). The SDP offer/answer [RFC3264] procedures associated with the attribute are defined in Section 4 Holmberg Expires November 6, 2017 [Page 4] Internet-Draft Exclusive RTP/RTCP Mux May 2017 4. SDP Offer/Answer Procedures 4.1. General This section defines the SDP offer/answer [RFC3264] procedures for indicating exclusive support of, and negotiating usage of, RTP/RTCP multiplexing. The procedures in this section apply to individual RTP-based SDP media descriptions ("m=" lines). 4.2. Generating the Initial SDP Offer When an offerer sends the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate an SDP 'rtcp-mux-only' attribute with the associated SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line, the offerer MUST also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761]. If the offerer associates an SDP 'rtcp' attribute [RFC3605] with an SDP media description ("m=" line), and if the offerer also associates an SDP 'rtcp-mux-only' attribute with the same SDP media description ("m=" line), the address and port values of the SDP 'rtcp' attribute MUST match the corresponding values for RTP. NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing. 4.3. Generating the Answer When an answerer receives an offer that contains an SDP 'rtcp-mux- only' attribute, associated with an RTP-based SDP media description ("m=" line), if the answerer accepts the usage of RTP/RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux' attribute with the corresponding SDP media description ("m=") in the associated answer, following the procedures in [RFC5761]. If the answerer does not accept the usage of RTP/RTCP multiplexing, the answerer MUST either reject the SDP media description ("m=") by setting the port value to zero in the associated answer, or reject the whole offer, following the procedures in [RFC3264]. The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer. Holmberg Expires November 6, 2017 [Page 5] Internet-Draft Exclusive RTP/RTCP Mux May 2017 4.4. Offerer Processing of the SDP Answer If an offerer associated an SDP 'rtcp-mux-only' attribute with an RTP-based SDP media description ("m=" line) in an offer, and if the corresponding SDP media description ("m=" line) in the associated answer contains an SDP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP multiplexing procedures [RFC5761] to the associated RTP- based media. If the corresponding SDP media description ("m=" line) in the associated answer does not contain an SDP 'rtcp-mux' attribute, the offerer MUST either take appropriate actions in order to disable the associated RTP-based media, e.g., send a new offer with a zero port value associated with the SDP media description ("m=" line), or send a new offer without associating an SDP 'rtcp- mux-only' attribute with the SDP media description ("m=" line). NOTE: This document does not mandate specific actions on how to terminate the RTP media. The offerer might e.g. send a new offer where the port value of the SDP media description is set to zero in order to terminate the RTP media. 4.5. Modifying the Session When an offerer sends a subsequent offer, if the offerer and answerer have previously negotiated usage of exclusive RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer SHOULD associate an SDP 'rtcp-mux-only' with the corresponding SDP media description ("m=" line). In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line), the offerer MUST also associate an SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following the procedures in [RFC5761]. If the offerer does not associate the attributes with the corresponding SDP media description ("m=" line) it is an indication that the offerer no longer wants to use RTP/RTCP multiplexing, and instead MUST fallback to usage of separate ports for RTP and RTCP once the offer has been accepted by the answerer. When an offerer sends a subsequent offer, if the offerer and answerer have not previously negotiated usage of RTP/RTCP multiplexing for the media associated with an RTP-based SDP media description ("m=" line), the offerer MAY indicate exclusive support of RTP/RTCP multiplexing, following the procedures in Section 4.2. The offerer MUST process the associated answer following the procedures in Section 4.4. Holmberg Expires November 6, 2017 [Page 6] Internet-Draft Exclusive RTP/RTCP Mux May 2017 It is RECOMMENDED to not switch between usage of RTP/RTCP multiplexing and usage of separate ports for RTP and RTCP in a subsequent offer, unless there is a use-case that mandates it. 5. Update to RFC 5761 5.1. General This section updates sections 5.1.1 and 5.1.3 of [RFC5761], by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports, and that the offerer shall terminate the affected streams if the answerer does not indicate support of RTP/RTCP multiplexing. It also clarifies that, when the offerer is not able to send and receive RTCP on separate ports, the offerer will not provide an SDP 'candidate' attribute for RTCP, nor will the offerer provide a fallback port for RTCP (using the SDP 'rtcp' attribute). 5.2. Update to 4th paragraph of section 5.1.1 NOTE: [RFC8035] also updates section 5.1.1 of [RFC5761]. While the paragraph updated in this document is not updated by [RFC8035], the location of the paragraph within section 5.1.1 is moved. Holmberg Expires November 6, 2017 [Page 7] Internet-Draft Exclusive RTP/RTCP Mux May 2017 OLD TEXT: If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute. NEW TEXT: If the answer does not contain an "a=rtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=rtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=rtcp-mux" attribute. However, if the offerer indicated in the offer that it is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. 5.3. Update to 2nd paragraph of section 5.1.3 Holmberg Expires November 6, 2017 [Page 8] Internet-Draft Exclusive RTP/RTCP Mux May 2017 OLD TEXT: If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired. NEW TEXT: If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offer MUST contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" lines for both RTP and RTCP along with an "a=rtcp:" line indicating a fallback port for RTCP in the case that the answerer does not support RTP and RTCP multiplexing. This MUST be done for each media where RTP and RTCP multiplexing is desired. However, if the offerer indicates in the offer that it is not able to send and receive RTCP on a separate port, the offerer MUST NOT include "a=candidate:" lines for RTCP, and the offerer MUST NOT provide a fallback port for RTCP using the "a=rtcp:" line. 6. ICE Considerations As defined in [RFC5245], if an entity is aware that the remote peer supports, and is willing to use, RTP/RTCP multiplexing, the entity will only provide RTP candidates (component ID 1). However, only providing RTP candidates does not as such imply exclusive support of RTP/RTCP multiplexing. RTCP candidates would not be provided also in cases where RTCP is not supported at all. Therefore, additional information is needed in order to indicate support of exclusive RTP/ RTCP multiplexing. This document defines such mechanism using the SDP 'rtcp-mux-only' attributes. 7. Security Considerations This document does not introduce new security considerations in additions to those specified in [RFC3605] and [RFC5761]. 8. IANA Considerations This document updates the "Session Description Protocol Parameters" registry as specified in Section 8.2.2 of [RFC4566]. Specifically, Holmberg Expires November 6, 2017 [Page 9] Internet-Draft Exclusive RTP/RTCP Mux May 2017 it adds the SDP 'rtcp-mux-only' attribute to the table for SDP media level attributes. Attribute name: rtcp-mux-only Type of attribute: media-level Subject to charset: no Purpose: Indicate exclusive support of RTP/RTCP multiplexing Appropriate Values: N/A Contact name: Christer Holmberg (christer.holmberg@ericsson.com) Mux Category: IDENTICAL 9. Acknowledgments Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas Frankkila and Martin Thomson for their comments and input on the document. Thanks to Francis Dupont for the genart review. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-rtcp-mux-exclusive-11 o Clarification note added to RFF 5761 update section. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-10 o Changes based on comments from Ekr: o - 'rtcp-mux-only' attribute only defined for SDP offers Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09 o Changes based on IESG review comments from Alexey Melnikov and Mirja Kuhlewind: o - References to draft-mux-attributes and draft-sdp-bundle made normative. o - Text added regarding cases where entities might want to use non- multiplexed RTP and RTCP. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08 o Editorial changes based on genart comments from Francis Dupont. Holmberg Expires November 6, 2017 [Page 10] Internet-Draft Exclusive RTP/RTCP Mux May 2017 Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07 o Comments from Ben Campbell. o - Additional text regarding applications for which the mechanism is suitable. o - Removal of pre-RFC5378 disclaimer. o - Editorial fixes. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06 o - Editorial fix. o - Addition of pre-RFC5378 disclaimer. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05 o Editorial fix. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04 o Changes based on comments from Flemming Andreasen. o - Attribute mux category changed to IDENTICAL. o - Reference to draft-5245bis changed to RFC 5245. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03 o Editorial changes based on comments from Martin Thomson. o Change of attribute name. o RFC 5761 updates added. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02 o Minor editorial fix. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01 o Mux category and source-specific applicability added. Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00 o Defined new SDP attribute for indicating rtcp-mux-exclusive. Holmberg Expires November 6, 2017 [Page 11] Internet-Draft Exclusive RTP/RTCP Mux May 2017 o Updates to RFC 5761 removed. o IANA considerations added. Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03 o Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00. Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02 o Intended status changed to "Standards track". Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01 o Clarified that the SDP rtcp attribute may contain the optional IP address part. Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00 o Additional updates to Section 5.1.1 of RFC 5761. o ICE considerations added. 11. References 11.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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . Holmberg Expires November 6, 2017 [Page 12] Internet-Draft Exclusive RTP/RTCP Mux May 2017 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC8035] Holmberg, C., "Session Description Protocol (SDP) Offer/ Answer Clarifications for RTP/RTCP Multiplexing", RFC 8035, DOI 10.17487/RFC8035, November 2016, . [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-36 (work in progress), October 2016. 11.2. Informative References [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [W3C.WD-webrtc-20120209] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20120209, February 2012, . Author's Address Holmberg Expires November 6, 2017 [Page 13] Internet-Draft Exclusive RTP/RTCP Mux May 2017 Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires November 6, 2017 [Page 14] ./draft-ietf-mmusic-rfc4566bis-37.txt0000644000764400076440000040437013523361001016454 0ustar iustyiusty Network Working Group A. Begen Internet-Draft Networked Media Obsoletes: 4566 (if approved) P. Kyzivat Intended status: Standards Track Expires: February 10, 2020 C. Perkins University of Glasgow M. Handley UCL August 9, 2019 SDP: Session Description Protocol draft-ietf-mmusic-rfc4566bis-37 Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 10, 2020. Copyright Notice Copyright (c) 2019 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 (https://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 Begen, et al. Expires February 10, 2020 [Page 1] Internet-Draft SDP August 2019 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples of SDP Usage . . . . . . . . . . . . . . . . . . . . 5 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 3.2. Streaming Media . . . . . . . . . . . . . . . . . . . . . 5 3.3. Email and the World Wide Web . . . . . . . . . . . . . . 5 3.4. Multicast Session Announcement . . . . . . . . . . . . . 5 4. Requirements and Recommendations . . . . . . . . . . . . . . 6 4.1. Media and Transport Information . . . . . . . . . . . . . 7 4.2. Timing Information . . . . . . . . . . . . . . . . . . . 7 4.3. Obtaining Further Information about a Session . . . . . . 8 4.4. Internationalization . . . . . . . . . . . . . . . . . . 8 5. SDP Specification . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 12 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 26 Begen, et al. Expires February 10, 2020 [Page 2] Internet-Draft SDP August 2019 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 26 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 27 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 28 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 30 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 31 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 32 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 40 8.2. Registration of SDP Parameters with IANA . . . . . . . . 42 8.2.1. Registration Procedure . . . . . . . . . . . . . . . 42 8.2.2. Media Types ("media") . . . . . . . . . . . . . . . . 43 8.2.3. Transport Protocols ("proto") . . . . . . . . . . . . 43 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 48 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 48 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 49 8.3. Encryption Key Access Methods (OBSOLETE) . . . . . . . . 50 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 12.1. Normative References . . . . . . . . . . . . . . . . . . 57 12.2. Informative References . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 1. Introduction When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description -- it does not incorporate a transport Begen, et al. Expires February 10, 2020 [Page 3] Internet-Draft SDP August 2019 protocol, and it is intended to use different transport protocols as appropriate, including the Session Announcement Protocol (SAP) [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real Time Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using the MIME extensions [RFC2045], and the Hypertext Transport Protocol (HTTP) [RFC7230]. SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description. This memo obsoletes [RFC4566]. The changes relative to [RFC4566] are outlined in Section 10 of this memo. 2. Glossary of Terms The following terms are used in this document and have specific meaning within the context of this document. Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session. Media Description: A Media Description contains the information needed for one party to establish an application layer network protocol connection to another party. It starts with an "m=" line and is terminated by either the next "m=" line or by the end of the session description. Session-level Section: This refers to the parts that are not media descriptions, whereas the session description refers to the whole body that includes the session-level section and the media description(s). The terms "multimedia conference" and "multimedia session" are used in this document as defined in [RFC7656]. The terms "session" and "multimedia session" are used interchangeably in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Begen, et al. Expires February 10, 2020 [Page 4] Internet-Draft SDP August 2019 3. Examples of SDP Usage 3.1. Session Initiation The Session Initiation Protocol (SIP) [RFC3261] is an application- layer control protocol for creating, modifying, and terminating sessions such as Internet multimedia conferences, Internet telephone calls, and multimedia distribution. The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types [RFC6838]. These session descriptions are commonly formatted using SDP. When used with SIP, the offer/answer model [RFC3264] provides a limited framework for negotiation using SDP. 3.2. Streaming Media The Real Time Streaming Protocol (RTSP) [RFC7826], is an application- level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters. 3.3. Email and the World Wide Web Alternative means of conveying session descriptions include electronic mail and the World Wide Web (WWW). For both email and WWW distribution, the media type "application/sdp" is used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner. Note that descriptions of multicast sessions sent only via email or the WWW do not have the property that the receiver of a session description can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope. 3.4. Multicast Session Announcement In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically sends packets containing a description of the session to a well-known multicast group. These advertisements are received by other session directories such that potential remote Begen, et al. Expires February 10, 2020 [Page 5] Internet-Draft SDP August 2019 participants can use the session description to start the tools required to participate in the session. One protocol used to implement such a distributed directory is the SAP [RFC2974]. SDP provides the recommended session description format for such session announcements. 4. Requirements and Recommendations The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use with Internet protocols, although it is sufficiently general that it can describe multimedia conferences in other network environments. Media streams can be many-to-many. Sessions need not be continually active. Thus far, multicast-based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and it is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant. An SDP description includes the following: o Session name and purpose o Time(s) the session is active o The media comprising the session o Information needed to receive those media (addresses, ports, formats, etc.) As resources necessary to participate in a session may be limited, some additional information may also be desirable: o Information about the bandwidth to be used by the session o Contact information for the person responsible for the session In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to any non- participants that may need to know. (This latter feature is Begen, et al. Expires February 10, 2020 [Page 6] Internet-Draft SDP August 2019 primarily useful when SDP is used with a multicast session announcement protocol.) 4.1. Media and Transport Information An SDP description includes the following media information: o The type of media (video, audio, etc.) o The media transport protocol (RTP/UDP/IP, H.320, etc.) o The format of the media (H.261 video, MPEG video, etc.) In addition to media format and transport protocol, SDP conveys address and port details. For an IP multicast session, these comprise: o The multicast group address for media o The transport port for media This address and port are the destination address and destination port of the multicast stream, whether being sent, received, or both. For unicast IP sessions, the following are conveyed: o The remote address for media o The remote transport port for media The semantics of the address and port depend on context. Typically, this SHOULD be the remote address and remote port to which media is to be sent or received. Details may differ based on the network type, address type, protocol and media specified, and whether the SDP is being distributed as an advertisement or negotiated in an offer/ answer [RFC3264] exchange. (E.g., Some address types or protocols may not have a notion of port.) Deviating from typical behavior should be done cautiously since this complicates implementations (including middleboxes that must parse the addresses to open Network Address Translation (NAT) or firewall pinholes). 4.2. Timing Information Sessions may be either bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey: o An arbitrary list of start and stop times bounding the session Begen, et al. Expires February 10, 2020 [Page 7] Internet-Draft SDP August 2019 o For each bound, repeat times such as "every Wednesday at 10am for one hour" This timing information is globally consistent, irrespective of local time zone or daylight saving time (see Section 5.9). 4.3. Obtaining Further Information about a Session A session description could convey enough information to decide whether or not to participate in a session. SDP may include additional pointers in the form of Uniform Resource Identifiers (URIs) [RFC3986] for more information about the session. (Note that use of URIs to indicate remote resources is subject to the security considerations from [RFC3986].) 4.4. Internationalization The SDP specification recommends the use of the ISO 10646 character set in the UTF-8 encoding [RFC3629] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as [ISO.8859-1.1998] to be used when desired. Internationalization only applies to free-text sub-fields (session name and background information), and not to SDP as a whole. 5. SDP Specification An SDP description is denoted by the media type "application/sdp" (See Section 8). An SDP description is entirely textual. SDP field names and attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but textual fields and attribute values MAY use the full ISO 10646 character set in UTF-8 encoding, or some other character set defined by the "a=charset:" attribute. Field and attribute values that use the full UTF-8 character set are never directly compared, hence there is no requirement for UTF-8 normalization. The textual form, as opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance portability, to enable a variety of transports to be used, and to allow flexible, text-based toolkits to be used to generate and process session descriptions. However, since SDP may be used in environments where the maximum permissible size of a session description is limited, the encoding is deliberately compact. Also, since descriptions may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed session descriptions that could be detected easily and discarded. Begen, et al. Expires February 10, 2020 [Page 8] Internet-Draft SDP August 2019 An SDP description consists of a number of lines of text of the form: = where is exactly one case-significant character and is structured text whose format depends on . In general, is either a number of sub-fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace separators are not used on either side of the "=" sign, however, the value can contain a leading whitespace as part of its syntax, i.e., that whitespace is part of the value. An SDP description MUST conform to the syntax defined in Section 9. The following is an overview of the syntax: An SDP description consists of a session-level section followed by zero or more media descriptions. The session-level section starts with a "v=" line and continues to the first media description (or the end of the whole description, whichever comes first). Each media description starts with an "m=" line and continues to the next media description or the end of the whole session description, whichever comes first. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Some lines in each description are required and some are optional, but when present must appear in exactly the order given here. (The fixed order greatly enhances error detection and allows for a simple parser). In the following overview optional items are marked with a "*". Begen, et al. Expires February 10, 2020 [Page 9] Internet-Draft SDP August 2019 Session description v= (protocol version) o= (originator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information -- not required if included in all media descriptions) b=* (zero or more bandwidth information lines) One or more time descriptions: ("t=", "r=" and "z=" lines; see below) k=* (obsolete) a=* (zero or more session attribute lines) Zero or more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times) z=* (optional time zone offset line) Media description, if present m= (media name and transport address) i=* (media title) c=* (connection information -- optional if included at session level) b=* (zero or more bandwidth information lines) k=* (obsolete) a=* (zero or more media attribute lines) The set of type letters is deliberately small and not intended to be extensible -- an SDP parser MUST completely ignore or reject any session description that contains a type letter that it does not understand. The attribute mechanism ("a=" described below) is the primary means for extending SDP and tailoring it to particular applications or media. Some attributes (the ones listed in Section 6 of this memo) have a defined meaning, but others may be added on a media- or session-specific basis. (Attribute scopes in addition to media-specific and session-specific may also be defined in extensions to this document. E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) An SDP parser MUST ignore any attribute it doesn't understand. An SDP description may contain URIs that reference external content in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in some cases, making the session description non-self-contained. Begen, et al. Expires February 10, 2020 [Page 10] Internet-Draft SDP August 2019 The connection ("c=") information in the session-level section applies to all the media descriptions of that session unless overridden by connection information in the media description. For instance, in the example below, each audio media description behaves as if it were given a "c=IN IP4 198.51.100.1". An example SDP description is: v=0 o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 s=Call to John Smith i=SDP Offer #1 u=http://www.jdoe.example.com/home.html e=Jane Doe p=+1 617 555-6011 c=IN IP4 198.51.100.1 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 c=IN IP6 2001:db8::2 a=rtpmap:99 h263-1998/90000 Text-containing fields such as the session-name-field and information-field are octet strings that may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a line, although parsers SHOULD be tolerant and also accept lines terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding. When the "a=charset" attribute is present the session-name-field, information-field, and some attribute fields are interpreted according to the selected character set. A session description can contain domain names in the "o=", "u=", "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply with [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or any other encoding (this requirement is for compatibility with [RFC2327] and other early SDP-related standards, which predate the development of internationalized domain names). Begen, et al. Expires February 10, 2020 [Page 11] Internet-Draft SDP August 2019 5.1. Protocol Version ("v=") v=0 The "v=" line (version-field) gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. 5.2. Origin ("o=") o= The "o=" line (origin-field) gives the originator of the session (her username and the address of the user's host) plus a session identifier and version number: is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user IDs. The MUST NOT contain spaces. is a numeric string such that the tuple of , , , , and forms a globally unique identifier for the session. The method of allocation is up to the creating tool, but a timestamp, in seconds since January 1, 1900 UTC, is recommended to ensure uniqueness. is a version number for this session description. Its usage is up to the creating tool, so long as is increased when a modification is made to the session description. Again, as with it is RECOMMENDED that a timestamp be used. is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 8). is an address of the machine from which the session was created. For an address type of IP4, this is either a fully qualified domain name of the machine or the dotted-decimal representation of an IP version 4 address of the machine. For an address type of IP6, this is either a fully qualified domain name of the machine or the address of the machine represented as Begen, et al. Expires February 10, 2020 [Page 12] Internet-Draft SDP August 2019 specified in Section 4 of [RFC5952]. For both IP4 and IP6, the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case a globally unique address MAY be substituted. In general, the "o=" line serves as a globally unique identifier for this version of the session description, and the sub-fields excepting the version, taken together identify the session irrespective of any modifications. For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary and private MAY be chosen to populate the "o=" line, provided that these are selected in a manner that does not affect the global uniqueness of the field. 5.3. Session Name ("s=") s= The "s=" line (session-name-field) is the textual session name. There MUST be one and only one "s=" line per session description. The "s=" line MUST NOT be empty. If a session has no meaningful name, then "s= " or "s=-" (i.e., a single space or dash as the session name) is RECOMMENDED. If a session-level "a=charset" attribute is present, it specifies the character set used in the "s=" field. If a session-level "a=charset" attribute is not present, the "s=" field MUST contain ISO 10646 characters in UTF-8 encoding. 5.4. Session Information ("i=") i= The "i=" line (information-field) provides textual information about the session. There can be at most one session-level "i=" line per session description, and at most one "i=" line in each media description. Unless a media-level "i=" line is provided, the session-level "i=" line applies to that media description. If the "a=charset" attribute is present, it specifies the character set used in the "i=" line. If the "a=charset" attribute is not present, the "i=" line MUST contain ISO 10646 characters in UTF-8 encoding. At most one "i=" line can be used for each media description. In media definitions, "i=" lines are primarily intended for labelling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions. Begen, et al. Expires February 10, 2020 [Page 13] Internet-Draft SDP August 2019 The "i=" line is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata. 5.5. URI ("u=") u= The "u=" line (uri-field) provides a URI (Uniform Resource Identifier) [RFC3986]. The URI should be a pointer to additional human readable information about the session. This line is OPTIONAL. No more than one "u=" line is allowed per session description. 5.6. Email Address and Phone Number ("e=" and "p=") e= p= The "e=" line (email-field) and "p=" line (phone-field) specify contact information for the person responsible for the session. This is not necessarily the same person that created the session description. Inclusion of an email address or phone number is OPTIONAL. If an email address or phone number is present, it MUST be specified before the first media description. More than one email or phone line can be given for a session description. Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164 [E164]) preceded by a "+". Spaces and hyphens may be used to split up a phone-field to aid readability if desired. For example: p=+1 617 555-6011 Both email addresses and phone numbers can have an OPTIONAL free text string associated with them, normally giving the name of the person who may be contacted. This MUST be enclosed in parentheses if it is present. For example: e=j.doe@example.com (Jane Doe) The alternative [RFC5322] name quoting convention is also allowed for both email addresses and phone numbers. For example: e=Jane Doe Begen, et al. Expires February 10, 2020 [Page 14] Internet-Draft SDP August 2019 The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate session-level "a=charset" attribute is set. 5.7. Connection Information ("c=") c= The "c=" line (connection-field) contains information necessary to establish a network connection. A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media- level "c=" line(s) per-media-description, in which case the media- level values override the session-level settings for the respective media. The first sub-field ("") is the network type, which is a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). The second sub-field ("") is the address type. This allows SDP to be used for sessions that are not IP based. This memo only defines IP4 and IP6, but other values MAY be registered in the future (see Section 8). The third sub-field ("") is the connection address. Additional sub-fields MAY be added after the connection address depending on the value of the sub-field. When the is IP4 or IP6, the connection address is defined as follows: o If the session is multicast, the connection address will be an IP multicast group address. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source, data relay or data sink as determined by additional attribute-fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited. o Sessions using an IP4 multicast connection address MUST also have a time to live (TTL) value present in addition to the multicast address. The TTL and the address together define the scope with which multicast packets sent in this session will be sent. TTL Begen, et al. Expires February 10, 2020 [Page 15] Internet-Draft SDP August 2019 values MUST be in the range 0-255. Although the TTL MUST be specified, its use to scope multicast traffic is deprecated; applications SHOULD use an administratively scoped address instead. The TTL for the session is appended to the address using a slash as a separator. An example is: c=IN IP4 233.252.0.1/127 IP6 multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for IP6 multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of multimedia conferences. Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality (and hence bandwidth) by only subscribing to a subset of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. For applications requiring multiple multicast groups, we allow the following notation to be used for the connection address: [/]/ If the number of addresses is not given, it is assumed to be one. Multicast addresses so assigned are contiguously allocated above the base address, so that, for example: c=IN IP4 233.252.0.1/127/3 would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 are to be used with a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description: c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.2/127 c=IN IP4 233.252.0.3/127 Similarly, an IPv6 example would be: c=IN IP6 ff00::db8:0:101/3 which is semantically equivalent to: Begen, et al. Expires February 10, 2020 [Page 16] Internet-Draft SDP August 2019 c=IN IP6 ff00::db8:0:101 c=IN IP6 ff00::db8:0:102 c=IN IP6 ff00::db8:0:103 (remembering that the TTL sub-field is not present in IP6 multicast). Multiple addresses or "c=" lines MAY be specified on a per media description basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. Multiple addresses or "c=" lines MUST NOT be specified at session level. The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses. 5.8. Bandwidth Information ("b=") b=: The OPTIONAL "b=" line (bandwidth-field) denotes the proposed bandwidth to be used by the session or media description. The is an alphanumeric modifier giving the meaning of the figure. Two values are defined in this specification, but other values MAY be registered in the future (see Section 8 and [RFC3556], [RFC3890]): CT If the bandwidth of a session is different from the bandwidth implicit from the scope, a "b=CT:..." line SHOULD be supplied for the session giving the proposed upper limit to the bandwidth used (the "conference total" bandwidth). Similarly, if the bandwidth of bundled media streams [I-D.ietf-mmusic-sdp-bundle-negotiation] in an "m=" line is different from the implicit value from the scope, a "b=CT:..." line SHOULD be supplied in the media level. The primary purpose of this is to give an approximate idea as to whether two or more sessions (or bundled media streams) can coexist simultaneously. Note that CT gives a total bandwidth figure for all the media at all endpoints. The Mux Category for CT is NORMAL. This is discussed in [I-D.ietf-mmusic-sdp-mux-attributes]. AS The bandwidth is interpreted to be application specific (it will be the application's concept of maximum bandwidth). Normally, this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP-based applications, AS gives the RTP "session bandwidth" as defined in Section 6.2 of [RFC3550]. Note that AS gives a bandwidth figure for a single Begen, et al. Expires February 10, 2020 [Page 17] Internet-Draft SDP August 2019 media at a single endpoint, although there may be many endpoints sending simultaneously. The Mux Category for AS is SUM. This is discussed in [I-D.ietf-mmusic-sdp-mux-attributes]. [RFC4566] defined an "X-" prefix for names. This was intended for experimental purposes only. For example: b=X-YZ:128 Use of the "X-" prefix is NOT RECOMMENDED. Instead new (non "X-" prefix) names SHOULD be defined, and then MUST be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth-fields with unknown names. The names MUST be alphanumeric and, although no length limit is given, it is recommended that they be short. The is interpreted as kilobits per second by default (including the transport and network-layer but not the link-layer overhead). The definition of a new modifier MAY specify that the bandwidth is to be interpreted in some alternative unit (the "CT" and "AS" modifiers defined in this memo use the default units). 5.9. Time Active ("t=") t= A "t=" line (time-field) begins a time description that specifies the start and stop times for a session. Multiple time descriptions MAY be used if a session is active at multiple irregularly spaced times; each additional time description specifies additional periods of time for which the session will be active. If the session is active at regular repeat times, a repeat description, begun by an "r=" line (see below) can be included following the time-field -- in which case the time-field specifies the start and stop times of the entire repeat sequence. The following example specifies two active intervals: t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC The first and second sub-fields of the time-field give the start and stop times, respectively, for the session. These are the decimal representation of time values in seconds since January 1, 1900 UTC. To convert these values to UNIX time (UTC), subtract decimal 2208988800. Begen, et al. Expires February 10, 2020 [Page 18] Internet-Draft SDP August 2019 Some time representations will wrap in the year 2036. Because SDP uses an arbitrary length decimal representation, it does not have this issue. Implementations of SDP need to be prepared to handle these larger values. If the is set to zero, then the session is not bounded, though it will not become active until after the . If the is also zero, the session is regarded as permanent. User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult. The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time or the session start time, whichever is the later. If behavior other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end. Permanent sessions may be shown to the user as never being active unless there are associated repeat times that state precisely when the session will be active. 5.10. Repeat Times ("r=") r= An"r=" line (repeat-field) specifies repeat times for a session. If needed to express complex schedules, multiple repeat-fields may be included. For example, if a session is active at 10am on Monday and 11am on Tuesday for one hour each week for three months, then the in the corresponding "t=" line would be the representation of 10am on the first Monday, the would be 1 week, the would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" line stop time would be the representation of the end of the last session three months later. By default, all sub-fields are in seconds, so the "r=" and "t=" lines might be the following: t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC ; Tues 20-Mar-2018 12:00 UTC r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours To make the description more compact, times may also be given in units of days, hours, or minutes. The syntax for these is a number Begen, et al. Expires February 10, 2020 [Page 19] Internet-Draft SDP August 2019 immediately followed by a single case-sensitive character. Fractional units are not allowed -- a smaller unit should be used instead. The following unit specification characters are allowed: d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness) Thus, the above repeat-field could also have been written: r=7d 1h 0 25h Monthly and yearly repeats cannot be directly specified with a single SDP repeat time; instead, separate time-descriptions should be used to explicitly list the session times. 5.11. Time Zone Adjustment ("z=") z= .... A "z=" line (zone-field) is an optional modifier to the repeat-fields it immediately follows. It does not apply to any other fields. To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify offsets from the base time. This is required because different time zones change time at different times of day, different countries change to or from daylight saving time on different dates, and some countries do not have daylight saving time at all. Thus, in order to schedule a session that is at the same time winter and summer, it must be possible to specify unambiguously by whose time zone a session is scheduled. To simplify this task for receivers, we allow the sender to specify the time (represented as seconds since January 1, 1900 UTC) that a time zone adjustment happens and the offset from the time when the session was first scheduled. The "z=" line allows the sender to specify a list of these adjustment times and offsets from the base time. An example might be the following: Begen, et al. Expires February 10, 2020 [Page 20] Internet-Draft SDP August 2019 t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC ; Tues 18-Dec-2018 12:00 UTC r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, ; offset 1 hour, ; Sun 28-Oct-2018 2:00 UTC, ; no offset This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the onset of British Summer Time) the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer Time) the session's original time base is restored. Adjustments are always relative to the specified start time -- they are not cumulative. If a session is likely to last several years, it is expected that the session description will be modified periodically rather than transmit several years' worth of adjustments in one session description. 5.12. Encryption Keys ("k=") k= k=: The "k=" line (key-field) is obsolete and MUST NOT be used. It is included in this document for legacy reasons. One MUST NOT include a "k=" line in an SDP, and MUST discard it if it is received in an SDP. 5.13. Attributes ("a=") a= a=: Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. (Attribute scopes in addition to media- and session- level may also be defined in extensions to this document. E.g., [RFC5576], [I-D.ietf-mmusic-data-channel-sdpneg].) A media description may contain any number of "a=" lines (attribute- fields) that are media description specific. These are referred to as "media-level" attributes and add information about the media description. Attribute-fields can also be added before the first media description; these "session-level" attributes convey additional information that applies to the session as a whole rather than to individual media descriptions. Begen, et al. Expires February 10, 2020 [Page 21] Internet-Draft SDP August 2019 Attribute-fields may be of two forms: o A property attribute is simply of the form "a=". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly". o A value attribute is of the form "a=:". For example, a whiteboard could have the value attribute "a=orient:landscape" Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular. Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are to be interpreted as in ISO-10646 character set with UTF-8 encoding. Unlike other text fields, attribute values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be charset dependent, in which case its value should be interpreted in the session charset rather than in ISO-10646. Attributes MUST be registered with IANA (see Section 8). If an attribute is received that is not understood, it MUST be ignored by the receiver. 5.14. Media Descriptions ("m=") m= ... A session description may contain a number of media descriptions. Each media description starts with an "m=" line (media-field) and is terminated by either the next "m=" line or by the end of the session description. A media-field has several sub-fields: is the media type. This document defines the values "audio", "video", "text", "application", and "message". This list is extended by other memos and may be further extended by additional memos registering media types in the future (see Section 8). For example, [RFC6466] defined the "image" media type. Begen, et al. Expires February 10, 2020 [Page 22] Internet-Draft SDP August 2019 is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" line, and on the transport protocol defined in the sub-field of the media-field. Other ports used by the media application (such as the RTP Control Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example, "a=rtcp:" as defined in [RFC3605]). If non-contiguous ports are used or if they don't follow the parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" attribute MUST be used. Applications that are requested to send media to a that is odd and where the "a=rtcp:" is present MUST NOT subtract 1 from the RTP port: that is, they MUST send the RTP to the port indicated in and send the RTCP to the port indicated in the "a=rtcp" attribute. For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" line: m= / ... In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session, and the denoting the number of RTP sessions. For example: m=video 49170/2 RTP/AVP 31 would specify that ports 49170 and 49171 form one RTP/RTCP pair and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). This document does not include a mechanism for declaring hierarchically encoded streams using non-contiguous ports. (There is currently no attribute defined that can accomplish this. The "a=rtcp:" defined in [RFC3605] does not handle hierarchical encoding.) If a need arises to declare non-contiguous ports then it will be necessary to define a new attribute to do so. If multiple addresses are specified in the "c=" line and multiple ports are specified in the "m=" line, a one-to-one mapping from port to the corresponding address is implied. For example: Begen, et al. Expires February 10, 2020 [Page 23] Internet-Draft SDP August 2019 m=video 49170/2 RTP/AVP 31 c=IN IP4 233.252.0.1/127/2 would imply that address 233.252.0.1 is used with ports 49170 and 49171, and address 233.252.0.2 is used with ports 49172 and 49173. The mapping is similar if multiple addresses are specified using multiple "c=" lines. For example: m=video 49170/2 RTP/AVP 31 c=IN IP6 ff00::db8:0:101 c=IN IP6 ff00::db8:0:102 would imply that address ff00::db8:0:101 is used with ports 49170 and 49171, and address ff00::db8:0:102 is used with ports 49172 and 49173. This document gives no meaning to assigning the same media address to multiple media-descriptions. Doing so does not implicitly group those media-descriptions in any way. An explicit grouping framework (for example, [RFC5888]) should instead be used to express the intended semantics. For instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. is the transport protocol. The meaning of the transport protocol is dependent on the address type sub-field in the relevant "c=" line. Thus a "c=" line with an address type of IP4 indicates that the transport protocol runs over IPv4. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 8): * udp: denotes that the data is transported directly in UDP with no additional framing. * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] running over UDP. * RTP/SAVP: denotes the Secure Real-time Transport Protocol [RFC3711] running over UDP. The main reason to specify the transport protocol in addition to the media format is that the same standard media formats may be carried over different transport protocols even when the network protocol is the same -- a historical example is VAT (MBone's popular multimedia audio tool) Pulse Code Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP PCM audio. In Begen, et al. Expires February 10, 2020 [Page 24] Internet-Draft SDP August 2019 addition, relays and monitoring tools that are transport-protocol- specific but format-independent are possible. is a media format description. The fourth and any subsequent sub-fields describe the format of the media. The interpretation of the media format depends on the value of the sub-field. If the sub-field is "RTP/AVP" or "RTP/SAVP" the sub- fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session. For dynamic payload type assignments the "a=rtpmap:" attribute (see Section 6) SHOULD be used to map from an RTP payload type number to a media encoding name that identifies the payload format. The "a=fmtp:" attribute MAY be used to specify format parameters (see Section 6). If the sub-field is "udp" the sub-fields MUST reference a media type describing the format under the "audio", "video", "text", "application", or "message" top-level media types. The media type registration SHOULD define the packet format for use with UDP transport. For media using other transport protocols, the sub-field is protocol specific. Rules for interpretation of the sub- field MUST be defined when registering new protocols (see Section 8.2.2). Section 3 of [RFC4855] states that the payload format (encoding) names defined in the RTP Profile are commonly shown in upper case, while media subtype names are commonly shown in lower case. It also states that both of these names are case-insensitive in both places, similar to parameter names which are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute. 6. SDP Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4. Syntax is provided using ABNF [RFC7405] with some of the rules defined further in Section 9. Begen, et al. Expires February 10, 2020 [Page 25] Internet-Draft SDP August 2019 6.1. cat (category) Name: cat Value: cat-value Usage Level: session Charset Dependent: no Syntax: cat-value = category category = non-ws-string Example: a=cat:foo.bar This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received. 6.2. keywds (keywords) Name: keywds Value: keywds-value Usage Level: session Charset Dependent: yes Syntax: keywds-value = keywords keywords = text Example: a=keywds:SDP session description protocol Like the cat attribute, this was intended to assist identifying wanted sessions at the receiver. This allows a receiver to select interesting sessions based on keywords describing the purpose of the session; there is no central registry of keywords. Its value should Begen, et al. Expires February 10, 2020 [Page 26] Internet-Draft SDP August 2019 be interpreted in the charset specified for the session description if one is specified, or by default in ISO 10646/UTF-8. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received. 6.3. tool Name: tool Value: tool-value Usage Level: session Charset Dependent: no Syntax: tool-value = tool-name-and-version tool-name-and-version = text Example: a=tool:foobar V3.2 This gives the name and version number of the tool used to create the session description. 6.4. ptime (packet time) Name: ptime Value: ptime-value Usage Level: media Charset Dependent: no Syntax: ptime-value = non-zero-int-or-real Example: a=ptime:20 This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It should Begen, et al. Expires February 10, 2020 [Page 27] Internet-Draft SDP August 2019 not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetization of audio. 6.5. maxptime (maximum packet time) Name: maxptime Value: maxptime-value Usage Level: media Charset Dependent: no Syntax: maxptime-value = non-zero-int-or-real Example: a=maxptime:20 This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. For frame-based codecs, the time SHOULD be an integer multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. Note that this attribute was introduced after [RFC2327], and non-updated implementations will ignore this attribute. 6.6. rtpmap Name: rtpmap Value: rtpmap-value Usage Level: media Charset Dependent: no Begen, et al. Expires February 10, 2020 [Page 28] Internet-Draft SDP August 2019 Syntax: rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = zero-based-integer encoding-name = token clock-rate = integer encoding-params = channels channels = integer This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. It also provides information on the clock rate and encoding parameters. Note that the payload type number is indicated in a 7-bit field, limiting the values to inclusively between 0 and 127. Although an RTP profile can make static assignments of payload type numbers to payload formats, it is more common for that assignment to be done dynamically using "a=rtpmap:" attributes. As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. This is completely defined in the RTP Audio/Video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as: m=audio 49232 RTP/AVP 0 An example of a dynamic payload type is 16-bit linear encoded stereo audio sampled at 16 kHz. If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it: m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 Up to one rtpmap attribute can be defined for each media format specified. Thus, we might have the following: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 RTP profiles that specify the use of dynamic payload types MUST define the set of valid encoding names and/or a means to register encoding names if that profile is to be used with SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for encoding names, under Begen, et al. Expires February 10, 2020 [Page 29] Internet-Draft SDP August 2019 the top-level media type denoted in the "m=" line. In the example above, the media types are "audio/L8" and "audio/L16". For audio streams, encoding-params indicates the number of audio channels. This parameter is OPTIONAL and may be omitted if the number of channels is one, provided that no additional parameters are needed. For video streams, no encoding parameters are currently specified. Additional encoding parameters MAY be defined in the future, but codec-specific parameters SHOULD NOT be added. Parameters added to an "a=rtpmap:" attribute SHOULD only be those required for a session directory to make the choice of appropriate media to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:"). Note: RTP audio formats typically do not include information about the number of samples per packet. If a non-default (as defined in the RTP Audio/Video Profile [RFC3551]) packetization is required, the "ptime" attribute is used as given above. 6.7. Media Direction Attributes At most one occurrence of recvonly, sendrecv, sendonly, or inactive MAY appear at session level, and at most one MAY appear in each media description. If any one of these appears in a media description then it applies for that media description. If none appear in a media description then the one from session level, if any, applies to that media description. If none of the media direction attributes is present at either session level or media level, "sendrecv" SHOULD be assumed as the default. Within the following SDP example, the "sendrecv" attribute applies to the first audio media and the "inactive" attribute applies to the others. Begen, et al. Expires February 10, 2020 [Page 30] Internet-Draft SDP August 2019 v=0 o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 s=- c=IN IP6 2001:db8::1 t=0 0 a=inactive m=audio 49170 RTP/AVP 0 a=sendrecv m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 6.7.1. recvonly (receive-only) Name: recvonly Value: Usage Level: session, media Charset Dependent: no Example: a=recvonly This specifies that the tools should be started in receive-only mode where applicable. Note that recvonly applies to the media only, not to any associated control protocol. An RTP-based system in recvonly mode MUST still send RTCP packets as described in [RFC3550] Section 6. 6.7.2. sendrecv (send-receive) Name: sendrecv Value: Usage Level: session, media Charset Dependent: no Example: a=sendrecv Begen, et al. Expires February 10, 2020 [Page 31] Internet-Draft SDP August 2019 This specifies that the tools should be started in send and receive mode. This is necessary for interactive multimedia conferences with tools that default to receive-only mode. 6.7.3. sendonly (send-only) Name: sendonly Value: Usage Level: session, media Charset Dependent: no Example: a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. 6.7.4. inactive Name: inactive Value: Usage Level: session, media Charset Dependent: no Example: a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive multimedia conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system MUST still send RTCP (if RTCP is used), even if started inactive. Begen, et al. Expires February 10, 2020 [Page 32] Internet-Draft SDP August 2019 6.8. orient (orientation) Name: orient Value: orient-value Usage Level: media Charset Dependent: no Syntax: orient-value = portrait / landscape / seascape portrait = %s"portrait" landscape = %s"landscape" seascape = %s"seascape" ; NOTE: These names are case-sensitive. Example: a=orient:portrait Normally this is only used for a whiteboard or presentation tool. It specifies the orientation of the workspace on the screen. Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape). 6.9. type (conference type) Name: type Value: type-value Usage Level: session Charset Dependent: no Syntax: type-value = conference-type conference-type = broadcast / meeting / moderated / test / H332 broadcast = %s"broadcast" meeting = %s"meeting" moderated = %s"moderated" test = %s"test" H332 = %s"H332" ; NOTE: These names are case-sensitive. Begen, et al. Expires February 10, 2020 [Page 33] Internet-Draft SDP August 2019 Example: a=type:moderated This specifies the type of the multimedia conference. Allowed values are "broadcast", "meeting", "moderated", "test", and "H332". These values have implications for other options that are likely to be appropriate: o When "a=type:broadcast" is specified, "a=recvonly" is probably appropriate for those connecting. o When "a=type:meeting" is specified, "a=sendrecv" is likely to be appropriate. o "a=type:moderated" suggests the use of a floor control tool and that the media tools be started so as to mute new sites joining the multimedia conference. o Specifying "a=type:H332" indicates that this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [ITU.H332.1998]. Media tools should be started using "a=recvonly". o Specifying "a=type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users. 6.10. charset (character set) Name: charset Value: charset-value Usage Level: session Charset Dependent: no Syntax: charset-value = This specifies the character set to be used to display the session name and information data. By default, the ISO-10646 character set in UTF-8 encoding is used. If a more compact representation is required, other character sets may be used. For example, the ISO 8859-1 is specified with the following SDP attribute: Begen, et al. Expires February 10, 2020 [Page 34] Internet-Draft SDP August 2019 a=charset:ISO-8859-1 The charset specified MUST be one of those registered in the IANA Character Sets registry (http://www.iana.org/assignments/character- sets), such as ISO-8859-1. The character set identifier is a string that MUST be compared against identifiers from the "Name" or "Preferred MIME Name" field of the registry using a case-insensitive comparison. If the identifier is not recognized or not supported, all strings that are affected by it SHOULD be regarded as octet strings. Charset-dependent fields MUST contain only sequences of bytes that are valid according to the definition of the selected character set. Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). 6.11. sdplang (SDP language) Name: sdplang Value: sdplang-value Usage Level: session, media Charset Dependent: no Syntax: sdplang-value = Language-Tag ; Language-Tag defined in RFC5646 Example: a=sdplang:fr Multiple sdplang attributes can be provided either at session or media level if the session description or media use multiple languages. As a session-level attribute, it specifies the language for the session description (not the language of the media). As a media- level attribute, it specifies the language for any media-level SDP information-field associated with that media (again not the language of the media), overriding any sdplang attributes specified at session level. In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple sesssion descriptions Begen, et al. Expires February 10, 2020 [Page 35] Internet-Draft SDP August 2019 SHOULD be sent describing the session, one in each language. However, this is not possible with all transport mechanisms, and so multiple sdplang attributes are allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single [RFC5646] language tag. An "sdplang" attribute SHOULD be specified when a session is distributed with sufficient scope to cross geographic boundaries, where the language of recipients cannot be assumed, or where the session is in a different language from the locally assumed norm. 6.12. lang (language) Name: lang Value: lang-value Usage Level: session, media Charset Dependent: no Syntax: lang-value = Language-Tag ; Language-Tag defined in RFC5646 Example: a=lang:de Multiple lang attributes can be provided either at session or media level if the session or media has capabilities in more than one language, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. As a session-level attribute, lang specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified. The "lang" attribute value must be a single [RFC5646] language tag. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of participants cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm. The "lang" attribute is supposed to be used for setting the initial language(s) used in the session. Events during the session may Begen, et al. Expires February 10, 2020 [Page 36] Internet-Draft SDP August 2019 influence which language(s) are used, and the participants are not strictly bound to only use the declared languages. Most real-time use cases start with just one language used, while other cases involve a range of languages, e.g. an interpreted or subtitled session. When more than one 'lang' attribute is specified, the "lang" attribute itself does not provide any information about multiple languages being intended to be used during the session, or if the intention is to only select one of the languages. If needed, a new attribute can be defined and used to indicate such intentions. Without such semantics, it is assumed that for a negotiated session one of the declared languages will be selected and used. 6.13. framerate (frame rate) Name: framerate Value: framerate-value Usage Level: media Charset Dependent: no Syntax: framerate-value = non-zero-int-or-real Example: a=framerate:60 This gives the maximum video frame rate in frames/sec. It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values are allowed. It is defined only for video media. 6.14. quality Name: quality Value: quality-value Usage Level: media Charset Dependent: no Begen, et al. Expires February 10, 2020 [Page 37] Internet-Draft SDP August 2019 Syntax: quality-value = zero-based-integer Example: a=quality:10 This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value is in the range 0 to 10, with the following suggested meaning: 10 - the best still-image quality the compression scheme can give. 5 - the default behavior given no quality suggestion. 0 - the worst still-image quality the codec designer thinks is still usable. 6.15. fmtp (format parameters) Name: fmtp Value: fmtp-value Usage Level: media Charset Dependent: no Syntax: fmtp-value = fmt SP format-specific-params format-specific-params = byte-string ; Notes: ; - The format parameters are media type parameters and ; need to reflect their syntax. Example: a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. The format must be one of the formats specified for the media. Format-specific parameters, semicolon separated, may be any set of parameters required to be conveyed by SDP and given unchanged to the Begen, et al. Expires February 10, 2020 [Page 38] Internet-Draft SDP August 2019 media tool that will use this format. At most one instance of this attribute is allowed for each format. The fmtp attribute may be used to specify parameters for any protocol and format that defines use of such parameters. 7. Security Considerations SDP is frequently used with the Session Initiation Protocol [RFC3261] using the offer/answer model [RFC3264] to agree on parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply. SDP is a session description format that describes multimedia sessions. Entities receiving and acting upon an SDP message SHOULD be aware that a session description cannot be trusted unless it has been obtained by an authenticated and integrity-protected transport protocol from a known and trusted source. Many different transport protocols may be used to distribute session descriptions, and the nature of the authentication and integrity-protection will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint SHOULD exercise care because, among other attacks, the media sessions received may not be the intended ones, the destination where media is sent to may not be the expected one, any of the parameters of the session may be incorrect, or the media security may be compromised. It is up to the endpoint to make a sensible decision taking into account the security risks of the application and the user preferences - the endpoint may decide to ask the user whether or not to accept the session. On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session description should take a few precautions. Similar concerns apply if integrity protection is not in place. Session descriptions contain information required to start software on the receiver's system. Software that parses a session description MUST NOT be able to start other software except that which is specifically configured as appropriate software to participate in multimedia sessions. It is normally considered inappropriate for software parsing a session description to start, on a user's system, software that is appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving the user's consent. Thus, a session description arriving by session announcement, email, session invitation, or WWW page MUST NOT deliver the user into an interactive multimedia session unless the user has explicitly pre-authorized such action. As it is not always simple to tell whether or not a session is interactive, applications that are Begen, et al. Expires February 10, 2020 [Page 39] Internet-Draft SDP August 2019 unsure should assume sessions are interactive. Software processing URLs contained in session descriptions should also heed the security considerations identified in [RFC3986]. In this specification, there are no attributes that would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done, an application parsing a session description containing such attributes SHOULD either ignore them or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behavior for an unknown attribute is to ignore it. In certain environments, it has become common for intermediary systems to intercept and analyze session descriptions contained within other signaling protocols. This is done for a range of purposes, including but not limited to opening holes in firewalls to allow media streams to pass, or to mark, prioritize, or block traffic selectively. In some cases, such intermediary systems may modify the session description, for example, to have the contents of the session description match NAT bindings dynamically created. These behaviors are NOT RECOMMENDED unless the session description is conveyed in such a manner that allows the intermediary system to conduct proper checks to establish the authenticity of the session description, and the authority of its source to establish such communication sessions. SDP by itself does not include sufficient information to enable these checks: they depend on the encapsulating protocol (e.g., SIP or RTSP). Use of some procedures and SDP extensions (e.g., ICE [RFC8445] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid the need for intermediaries to modify SDP. SDP MUST NOT be used to convey keying material (e.g., using "a=crypto" [RFC4568]) unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 8. IANA Considerations 8.1. The "application/sdp" Media Type One media type registration from [RFC4566] is to be updated, as defined below. To: ietf-types@iana.org Subject: Registration of media type "application/sdp" Type name: application Begen, et al. Expires February 10, 2020 [Page 40] Internet-Draft SDP August 2019 Subtype name: sdp Required parameters: None. Optional parameters: None. Encoding considerations: 8-bit text. SDP files are primarily UTF-8 format text. The "a=charset:" attribute may be used to signal the presence of other character sets in certain parts of an SDP file (see Section 6 of RFC XXXX). Arbitrary binary content cannot be directly represented in SDP. Security considerations: See Section 7 of RFC XXXX. Interoperability considerations: See RFC XXXX. Published specification: See RFC XXXX. Applications which use this media type: Voice over IP, video teleconferencing, streaming media, instant messaging, among others. See also Section 3 of RFC XXXX. Fragment identifier considerations: None Additional information: Deprecated alias names for this type: N/A Magic number(s): None. File extension(s): The extension ".sdp" is commonly used. Macintosh File Type Code(s): "sdp " Person & email address to contact for further information: IETF MMUSIC working group Intended usage: COMMON Restrictions on usage: None Author/Change controller: Authors of RFC XXXX IETF MMUSIC working group delegated from the IESG Begen, et al. Expires February 10, 2020 [Page 41] Internet-Draft SDP August 2019 8.2. Registration of SDP Parameters with IANA This document specifies IANA parameter registries for six named SDP sub-fields. Using the terminology in the SDP specification Augmented Backus-Naur Form (ABNF), they are "media", "proto", "att-field", "bwtype", "nettype", and "addrtype". This document also replaces and updates the definitions of all those parameters previously defined by [RFC4566]. IANA: Please change all references to RFC4566 in these registries to instead refer to this document. The contact name and email address for all parameters registered in this document is: The IETF MMUSIC working group or its successor as designated by the IESG. All of these registries have a common format: ---------------------------------------------------- | Type | SDP Name | [other fields] | Reference | ---------------------------------------------------- 8.2.1. Registration Procedure A specification document that defines values for SDP "media", "proto", "att-field", "bwtype", "nettype", and "addrtype" parameters MUST include the following information: o contact name; o contact email address; o name being defined (as it will appear in SDP); o type of name ("media", "proto", "bwtype", "nettype", or "addrtype"); o a description of the purpose of the defined name; o a stable reference to the document containing this information and the definition of the value. (This will typically be an RFC number.) Begen, et al. Expires February 10, 2020 [Page 42] Internet-Draft SDP August 2019 The subsections below specify what other information (if any) must be specified for particular parameters, and what other fields are to be included in the registry. 8.2.2. Media Types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level media types, and where possible the same name should be registered for SDP as for MIME. For media other than existing top-level media types, a Standards Track RFC MUST be produced for a new top-level media type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of [RFC8126]). This memo registers the media types "audio", "video", "text", "application", and "message". Note: The media types "control" and "data" were listed as valid in an early version of this specification (RFC 2327); however, their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent as defined in [RFC3840]. If these media types are considered useful in the future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by [RFC3840]). Also note that [RFC6466] defined the "image" media type. 8.2.3. Transport Protocols ("proto") The "proto" sub-field describes the transport protocol used. The registration procedure for this registry is "RFC Required". This document registers two values: o "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] running over UDP/IP, o "UDP" indicates direct use of the UDP protocol. New transport protocols MAY be defined, and MUST be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable that it be Standards Track. The RFC defining a new Begen, et al. Expires February 10, 2020 [Page 43] Internet-Draft SDP August 2019 protocol MUST define the rules by which the "fmt" (see below) namespace is managed. "proto" names starting with "RTP/" MUST only be used for defining transport protocols that are profiles of the RTP protocol. For example, a profile whose short name is "XYZ" would be denoted by a "proto" sub-field of "RTP/XYZ". Each transport protocol, defined by the "proto" sub-field, has an associated "fmt" namespace that describes the media formats that may be conveyed by that protocol. Formats cover all the possible encodings that could be transported in a multimedia session. RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned by this session description, an additional "rtpmap" attribute MUST be included to specify the format name and parameters as defined by the media type registration for the payload format. It is RECOMMENDED that other RTP profiles that are registered (in combination with RTP) as SDP transport protocols specify the same rules for the "fmt" namespace. For the "UDP" protocol, allowed "fmt" values are media subtypes from the IANA Media Types registry. The media type and subtype combination / specifies the format of the body of UDP packets. Use of an existing media subtype for the format is encouraged. If no suitable media subtype exists, it is RECOMMENDED that a new one be registered through the IETF process [RFC6838] by production of, or reference to, a standards-track RFC that defines the format. For other protocols, formats MAY be registered according to the rules of the associated "proto" specification. Registrations of new formats MUST specify which transport protocols they apply to. 8.2.4. Attribute Names ("att-field") Attribute-field names ("att-field") MUST be registered with IANA and documented, to avoid any issues due to conflicting attribute definitions under the same name. (While unknown attributes in SDP are simply ignored, conflicting ones that fragment the protocol are a serious problem.) The format of the attribute registry is: Begen, et al. Expires February 10, 2020 [Page 44] Internet-Draft SDP August 2019 ---------------------------------------------------------------------- | | | | Mux | | | Type | SDP Name | Usage Level | Category | Reference | ---------------------------------------------------------------------- For example, the attribute "setup" which is defined for both session and media level, will be listed in the new registry as follows: ---------------------------------------------------------------------- | | | | Mux | | | Type | SDP Name | Usage Level | Category | Reference | |----------|------------|----------------|----------|----------------| |attribute |setup | session,media, |IDENTICAL | [RFC4145] | | | | dcsa,dcsa(msrp)| | [RFC6135] | | | | | | [I-D.mmusic- | | | | | | msrp-usage- | | | | | | data-channel] | ---------------------------------------------------------------------- This one registry combines all of the previous usage-level-specific "att-field" registries, including updates made by [I-D.ietf-mmusic-sdp-mux-attributes]. IANA is requested to do the necessary reformatting. Section 6 of this document replaces the initial set of attribute definitions made by [RFC4566]. IANA is requested to update the registry accordingly. Documents can define new attributes and can also extend the definitions of previously defined attributes: 8.2.4.1. New Attributes New attribute registrations are accepted according to the "Specification Required" policy of [RFC8126], provided that the specification includes the following information: o Contact Name. o Contact Email Address. o Attribute Name: The name of the attribute that will appear in SDP). This MUST conform to the definition of . o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF definition of the attribute value syntax (see Section 9) MUST be provided. The syntax MUST follow the rule form as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define Begen, et al. Expires February 10, 2020 [Page 45] Internet-Draft SDP August 2019 the allowable values that the attribute might take. It MAY also define an extension method for the addition of future values. For a property attribute, the ABNF definition is omitted as the property attribute takes no values. o Attribute Semantics: For a value attribute, a semantic description of the values that the attribute might take MUST be provided. The usage of a property attribute is described under purpose below. o Attribute Value: The name of an ABNF syntax rule defining the syntax of the value. Absence of a rule name indicates that the attribute takes no values. Enclosing the rule name in "[" and "]" indicates that a value is optional. o Usage Level: Usage level(s) of the attribute. This MUST be one or more of the following: session, media, source, dcsa and dcsa(subprotocol). For a definition of source level attributes, see [RFC5576]. For a definition of dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg]. o Charset Dependent: This MUST be "Yes" or "No" depending on whether the attribute value is subject to the charset attribute. o Purpose: An explanation of the purpose and usage of the attribute. o O/A Procedures: Offer/Answer procedures as explained in [RFC3264]. o Mux Category: This MUST indicate one of the following categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by [I-D.ietf-mmusic- sdp-mux-attributes]. o Reference: A reference to the specification defining the attribute. The above is the minimum that IANA will accept. Attributes that are expected to see widespread use and interoperability SHOULD be documented with a standards-track RFC that specifies the attribute more precisely. Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability. Submitters of registrations should also carefully choose the attribute usage level. They should not choose only "session" when Begen, et al. Expires February 10, 2020 [Page 46] Internet-Draft SDP August 2019 the attribute can have different values when media is disaggregated, i.e., when each m= section has its own IP address on a different endpoint. In that case the attribute type chosen should be "session, media" or "media" (depending on desired semantics). The default rule is that for all new SDP attributes that can occur both in session and media level, the media level overrides the session level. When this is not the case for a new SDP attribute, it MUST be explicitly stated. IANA has registered the initial set of attribute names ("att-field" values) with definitions as in Section 6 of this memo (these definitions replace those in [RFC4566]). 8.2.4.2. Updates to Existing Attributes Updated attribute registrations are accepted according to the "Specification Required" policy of [RFC8126]. The Designated Expert reviewing the update is requested to evaluate whether the update is compatible with the prior intent and use of the attribute, and whether the new document is of sufficient maturity and authority in relation to the prior document. The specification updating the attribute (for example, by adding a new value) MUST update registration information items from Section 8.2.4.1 according to the following constraints: o Contact Name: A name for an entity responsible for the update MUST be provided. o Contact Email Address: An email address for an entity responsible for the update MUST be provided. o Attribute Name: MUST be provided and MUST NOT be changed. Otherwise it is a new attribute. o Attribute Syntax: The existing rule syntax with the syntax extensions MUST be provided if there is a change to the syntax. A revision to an existing attribute usage MAY extend the syntax of an attribute, but MUST be backward compatible. o Attribute Semantics: A semantic description of new additional attribute values or a semantic extension of existing values. Existing attribute values semantics MUST only be extended in a backward compatible manner. o Usage Level: Updates MAY only add additional levels. Begen, et al. Expires February 10, 2020 [Page 47] Internet-Draft SDP August 2019 o Charset Dependent: MUST NOT be changed. o Purpose: MAY be extended according to the updated usage. o O/A Procedures: MAY be updated in a backward compatible manner and/or it applies to a new usage level only. o Mux Category: No change unless from "TBD" to another value (see [I-D.ietf-mmusic-sdp-mux-attributes]. It MAY also change if 'media' level is being added to the definition of an attribute that previously did not include it. o Reference: A new (additional or replacement) reference MUST be provided. Items SHOULD be omitted if there is no impact to them as a result of the attribute update. 8.2.5. Bandwidth Specifiers ("bwtype") A proliferation of bandwidth specifiers is strongly discouraged. New bandwidth specifiers ( sub-field values) MUST be registered with IANA. The submission MUST reference a standards- track RFC specifying the semantics of the bandwidth specifier precisely, and indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice. The RFC MUST specify the Mux Category for this value as defined by [I-D.ietf-mmusic-sdp-mux-attributes]. The format of the "bwtype" registry is: -------------------------------------------------- | Type | SDP Name | Mux Category | Reference | -------------------------------------------------- IANA is requested to update the "bwtype" registry entries for the bandwidth specifiers "CT" and "AS" with the definitions in Section 5.8 of this memo (these definitions replace those in [RFC4566]). 8.2.6. Network Types ("nettype") Network type "IN", representing the Internet, is defined in Section 5.2 and Section 5.7 of this memo. (This definition replaces that in [RFC4566].) Begen, et al. Expires February 10, 2020 [Page 48] Internet-Draft SDP August 2019 To enable SDP to reference a new non-Internet environment a new network type ( sub-field value) MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. Although non-Internet environments are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non-Internet application, such as when gatewaying an Internet telephone call into the Public Switched Telephone Network (PSTN). The number of network types should be small and should be rarely extended. A new network type registration MUST reference an RFC that gives details of the network type and the address type(s) that may be used with it. The format of the "nettype" registry is: -------------------------------------------------------------------- |Type | SDP Name | Usable addrtype Values | Reference | -------------------------------------------------------------------- IANA is requested to update the "nettype" registry to this new format. The following is the updated content of th registry: -------------------------------------------------------------------- |Type | SDP Name | Usable addrtype Values | Reference | -------------------------------------------------------------------- |nettype | IN | IP4, IP6 | [RFCXXXX] | |nettype | TN | RFC2543 | [RFC2848] | |nettype | ATM | NSAP, GWID, E164 | [RFC3108] | |nettype | PSTN | E164 | [RFC7195] | -------------------------------------------------------------------- Note that both [RFC7195] and [RFC3108] registered "E164" as an address type, although [RFC7195] mentions that the "E164" address type has a different context for ATM and PSTN networks. 8.2.7. Address Types ("addrtype") New address types ("addrtype") MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. A new address type registration MUST reference an RFC giving details of the syntax of the address type. Address types are not expected to be registered frequently. Section 5.7 of this document gives new definitions of address types "IP4" and "IP6". Begen, et al. Expires February 10, 2020 [Page 49] Internet-Draft SDP August 2019 8.3. Encryption Key Access Methods (OBSOLETE) The IANA previously maintained a table of SDP encryption key access method ("enckey") names. This table is obsolete, since the "k=" line is not extensible. New registrations MUST NOT be accepted. 9. SDP Grammar This section provides an Augmented BNF grammar for SDP. ABNF is defined in [RFC5234] and [RFC7405]. ; SDP Syntax session-description = version-field origin-field session-name-field [information-field] [uri-field] *email-field *phone-field [connection-field] *bandwidth-field 1*time-description [key-field] *attribute-field *media-description version-field = %s"v" "=" 1*DIGIT CRLF ;this memo describes version 0 origin-field = %s"o" "=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF session-name-field = %s"s" "=" text CRLF information-field = %s"i" "=" text CRLF uri-field = %s"u" "=" uri CRLF email-field = %s"e" "=" email-address CRLF phone-field = %s"p" "=" phone-number CRLF connection-field = %s"c" "=" nettype SP addrtype SP connection-address CRLF ;a connection field must be present ;in every media description or at the ;session level Begen, et al. Expires February 10, 2020 [Page 50] Internet-Draft SDP August 2019 bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF time-description = time-field [repeat-description] repeat-description = 1*repeat-field [zone-field] time-field = %s"t" "=" start-time SP stop-time CRLF repeat-field = %s"r" "=" repeat-interval SP typed-time 1*(SP typed-time) CRLF zone-field = %s"z" "=" time SP ["-"] typed-time *(SP time SP ["-"] typed-time) CRLF key-field = %s"k" "=" key-type CRLF attribute-field = %s"a" "=" attribute CRLF media-description = media-field [information-field] *connection-field *bandwidth-field [key-field] *attribute-field media-field = %s"m" "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF ; sub-rules of 'o=' username = non-ws-string ;pretty wide definition, but doesn't ;include space sess-id = 1*DIGIT ;should be unique for this username/host sess-version = 1*DIGIT nettype = token ;typically "IN" addrtype = token ;typically "IP4" or "IP6" ; sub-rules of 'u=' uri = URI-reference Begen, et al. Expires February 10, 2020 [Page 51] Internet-Draft SDP August 2019 ; see RFC 3986 ; sub-rules of 'e=', see RFC 5322 for definitions email-address = address-and-comment / dispname-and-address / addr-spec address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) ; sub-rules of 'c=' connection-address = multicast-address / unicast-address ; sub-rules of 'b=' bwtype = token bandwidth = 1*DIGIT ; sub-rules of 't=' start-time = time / "0" stop-time = time / "0" time = POS-DIGIT 9*DIGIT ; Decimal representation of time in ; seconds since January 1, 1900 UTC. ; The representation is an unbounded ; length field containing at least ; 10 digits. Unlike some representations ; used elsewhere, time in SDP does not ; wrap in the year 2036. ; sub-rules of 'r=' and 'z=' repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit] fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" ; NOTE: These units are case-sensitive. ; sub-rules of 'k=' key-type = %s"prompt" / %s"clear:" text / Begen, et al. Expires February 10, 2020 [Page 52] Internet-Draft SDP August 2019 %s"base64:" base64 / %s"uri:" uri ; NOTE: These names are case-sensitive. base64 = *base64-unit [base64-pad] base64-unit = 4base64-char base64-pad = 2base64-char "==" / 3base64-char "=" base64-char = ALPHA / DIGIT / "+" / "/" ; sub-rules of 'a=' attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string ; sub-rules of 'm=' media = token ;typically "audio", "video", "text", "image" ;or "application" fmt = token ;typically an RTP payload type for audio ;and video media proto = token *("/" token) ;typically "RTP/AVP" or "udp" port = 1*DIGIT ; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast / FQDN / extn-addr IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" numaddr ] ; IP4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = IP6-address [ "/" numaddr ] ; IP6 address starting with FF numaddr = integer Begen, et al. Expires February 10, 2020 [Page 53] Internet-Draft SDP August 2019 ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC 1035 (and updates) IP4-address = b1 3("." decimal-uchar) b1 = decimal-uchar ; less than "224" IP6-address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" h16 = 1*4HEXDIG ls32 = ( h16 ":" h16 ) / IP4-address ; Generic for other address families extn-addr = non-ws-string ; generic sub-rules: datatypes text = byte-string ;default is to interpret this as UTF8 text. ;ISO 8859-1 requires "a=charset:ISO-8859-1" ;session-level attribute to be used byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR, or LF non-ws-string = 1*(VCHAR/%x80-FF) ;string of visible characters token-char = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" ; (single quote) / "*" / "+" / "-" / "." / "^" / "_" / "`" ; (Grave accent) / "{" / "|" / "}" / "~" token = 1*(token-char) Begen, et al. Expires February 10, 2020 [Page 54] Internet-Draft SDP August 2019 email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;any byte except NUL, CR, LF, or the quoting ;characters ()<> integer = POS-DIGIT *DIGIT zero-based-integer = "0" / integer non-zero-int-or-real = integer / non-zero-real non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) ; external references: ALPHA = DIGIT = CRLF = HEXDIG = SP = VCHAR = URI-reference = addr-spec = 10. Summary of Changes from RFC 4566 o Generally clarified and refined terminology. o Identified now-obsolete items: "a=cat", "a=keywds", "k=". o Updated normative and informative references, and added references to additional relevant related RFCs. o Reformatted the SDP Attributes section for readability. The syntax of attribute values is now given in ABNF. o Made mandatory the sending of RTCP with inactive media streams. Begen, et al. Expires February 10, 2020 [Page 55] Internet-Draft SDP August 2019 o Removed the section "Private Sessions". That section dates back to a time when the primary use of SDP was with SAP (Session Announcement Protocol). That has fallen out of use. Now the vast majority of uses of SDP is for establishment of private sessions. The considerations for that are covered in Section 7. o Expanded and clarified the specification of the "lang" and "sdplang" attributes. o Removed some references to SAP because it is no longer in widespread use. o Changed the way values for UDP transport are registered. o Changed the mechanism and documentation required for registering new attributes. o Tightened up IANA registration procedures for extensions. Removed phone number and long-form name. o Expanded the IANA nettype registry to identify valid addrtypes. o Reorganized the several IANA att-type registries into a single registry o Revised ABNF syntax for clarity. Backward compatibility is maintained with a few exceptions: * Revised the syntax of time descriptions ("t=", "r=", "z=") to remove ambiguities. Clarified that "z=" only modifies the immediately preceding "r=" lines. Made "z=" without a preceding "r=" a syntax error. (This is incompatible with certain aberrant usage.) * Updated the "IP6-address" and "IP6-multicast" rules, consistent with the syntax in RFC3986. (This mirrors a bug fix made to RFC3261 by RFC5964.) Removed rules that were unused as a result of this change. o Revised normative statements that were redundant with ABNF syntax, making the text non-normative. o Revised IPv4 unicast and multicast addresses in the example SDP descriptions per RFCs 5735 and 5771. o Changed some examples to use IPv6 addresses, and added additional examples using IPv6. Begen, et al. Expires February 10, 2020 [Page 56] Internet-Draft SDP August 2019 o Incorporated case-insensitivity rules from RFC 4855. o Revised sections that incorrectly referenced NTP. o Clarified the explanation of the impact and use of a=charset. o Revised the description of a=type to remove implication that it sometimes changes the default media direction to something other than sendrecv. 11. Acknowledgements Many people in the IETF Multiparty Multimedia Session Control (MMUSIC) working group have made comments and suggestions contributing to this document. In particular, we would like to thank the following people who contributed to the creation of this document or one of its predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, Gonzalo Camarillo, Joerg Ott, John Elwell, Jon Peterson, Jonathan Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier, Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve Hanna, Van Jacobson. 12. References 12.1. Normative References [E164] International Telecommunication Union, "E.164 : The international public telecommunication numbering plan", ITU Recommendation E.164, November 2010. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, "SDP-based Data Channel Negotiation", draft-ietf- mmusic-data-channel-sdpneg-28 (work in progress), May 2019. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. Begen, et al. Expires February 10, 2020 [Page 57] Internet-Draft SDP August 2019 [ISO.8859-1.1998] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO/IEC Standard 8859-1, 1998. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, DOI 10.17487/RFC2848, June 2000, . [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, . [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . Begen, et al. Expires February 10, 2020 [Page 58] Internet-Draft SDP August 2019 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6135] Holmberg, C. and S. Blau, "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)", RFC 6135, DOI 10.17487/RFC6135, February 2011, . [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", RFC 7195, DOI 10.17487/RFC7195, May 2014, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Begen, et al. Expires February 10, 2020 [Page 59] Internet-Draft SDP August 2019 12.2. Informative References [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., Keranen, A., Shpount, R., and C. Holmberg, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-38 (work in progress), August 2019. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [ITU.H332.1998] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, . [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . Begen, et al. Expires February 10, 2020 [Page 60] Internet-Draft SDP August 2019 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, . [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . Begen, et al. Expires February 10, 2020 [Page 61] Internet-Draft SDP August 2019 [RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [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, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . Authors' Addresses Ali Begen Networked Media Konya Turkey EMail: ali.begen@networked.media Begen, et al. Expires February 10, 2020 [Page 62] Internet-Draft SDP August 2019 Paul Kyzivat USA EMail: pkyzivat@alum.mit.edu Colin Perkins University of Glasgow School of Computing Science University of Glasgow Glasgow G12 8QQ UK EMail: csp@csperkins.org Mark Handley University College London Department of Computer Science London WC1E 6BT UK EMail: M.Handley@cs.ucl.ac.uk Begen, et al. Expires February 10, 2020 [Page 63] ./draft-ietf-mmusic-rid-15.txt0000644000764400076440000017101713276676425015460 0ustar iustyiusty Network Working Group A. Roach (Editor) Internet-Draft Mozilla Updates: 4855 (if approved) May 15, 2018 Intended status: Standards Track Expires: November 16, 2018 RTP Payload Format Restrictions draft-ietf-mmusic-rid-15 Abstract In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP Streams within an RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 16, 2018. Copyright Notice Copyright (c) 2018 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 Roach (Editor) Expires November 16, 2018 [Page 1] Internet-Draft RTP Restrictions May 2018 (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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 5. "a=rid" restrictions . . . . . . . . . . . . . . . . . . . . 6 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 8 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 9 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 9 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 13 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 13 8. Interaction with Other Techniques . . . . . . . . . . . . . . 13 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 14 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 14 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 14 8.2. Interaction with H.264 Format Parameters . . . . . . . . 15 8.2.1. profile-level-id and max-recv-level - Negotiated Sub- Profile . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 16 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks . . . . . . . . . . . . . . . . . . . . . 16 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 17 8.3. Redundancy Formats and Payload Type Restrictions . . . . 17 9. Format Parameters for Future Payloads . . . . . . . . . . . . 18 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 18 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 20 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 Roach (Editor) Expires November 16, 2018 [Page 2] Internet-Draft RTP Restrictions May 2018 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 15.1. Normative References . . . . . . . . . . . . . . . . . . 25 15.2. Informative References . . . . . . . . . . . . . . . . . 26 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Terminology The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP Stream" are used as defined in [RFC7656]. [RFC4566] and [RFC3264] terminology is also used where appropriate. 2. Introduction The Payload Type (PT) field in RTP provides a mapping between the RTP payload format and the associated SDP media description. The SDP rtpmap and/or fmtp attributes are used, for a given PT, to describe the properties of the media that is carried in the RTP payload. Recent advances in standards have given rise to rich multimedia applications requiring support for multiple RTP Streams within an RTP session [I-D.ietf-mmusic-sdp-bundle-negotiation], [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number of codecs. These demands have unearthed challenges inherent with: o The restricted RTP PT space in specifying the various payload configurations, o The codec-specific constructs for the payload formats in SDP, o Missing or underspecified payload format parameters, o Overloading of PTs to indicate not just codec configurations, but individual streams within an RTP session. To expand on these points: [RFC3550] assigns 7 bits for the PT in the RTP header. However, the assignment of static mapping of RTP payload type numbers to payload formats and multiplexing of RTP with other protocols (such as RTCP) could result in a limited number of payload type numbers available for application usage. In scenarios where the number of possible RTP payload configurations exceeds the available PT space within an RTP Session, there is a need for a way to represent the additional restrictions on payload configurations and to effectively map an RTP Stream to its corresponding restrictions. This issue is exacerbated by the increase in techniques - such as simulcast and layered codecs - which introduce additional streams into RTP Sessions. Roach (Editor) Expires November 16, 2018 [Page 3] Internet-Draft RTP Restrictions May 2018 This specification defines a new SDP framework for restricting Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes to restrict payload formats in a codec-agnostic way. This framework can be thought of as a complementary extension to the way the media format parameters are specified in SDP today, via the "a=fmtp" attribute. The additional restrictions on individual streams are indicated with a new "a=rid" ("restriction identifier") SDP attribute. Note that the restrictions communicated via this attribute only serve to further restrict the parameters that are established on a PT format. They do not relax any restrictions imposed by other mechanisms. This specification makes use of the RTP Stream Identifier Source Description (SDES) RTCP item defined in [I-D.ietf-avtext-rid] to provide correlation between the RTP Packets and their format specification in the SDP. As described in Section 6.2.1, this mechanism achieves backwards compatibility via the normal SDP processing rules, which require unknown a= lines to be ignored. This means that implementations need to be prepared to handle successful offers and answers from other implementations that neither indicate nor honor the restrictions requested by this mechanism. Further, as described in Section 6 and its subsections, this mechanism achieves extensibility by: (a) having offerers include all supported restrictions in their offer, and (b) having answerers ignore "a=rid" lines that specify unknown restrictions. 3. Key Words for Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. SDP "a=rid" Media Level Attribute This section defines new SDP media-level attribute [RFC4566], "a=rid", used to communicate a set of restrictions to be applied to an identified RTP Stream. Roughly speaking, this attribute takes the following form (see Section 10 for a formal definition). a=rid: [pt=;]=... Roach (Editor) Expires November 16, 2018 [Page 4] Internet-Draft RTP Restrictions May 2018 An "a=rid" SDP media attribute specifies restrictions defining a unique RTP payload configuration identified via the "rid-id" field. This value binds the restriction to the RTP Stream identified by its RTP Stream Identifier Source Description (SDES) item [I-D.ietf-avtext-rid]. Implementations that use the "a=rid" parameter in SDP MUST support the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such implementations MUST send that SDES item for all streams in an SDP media description ("m=") that have "a=rid" lines remaining after applying the rules in Section 6 and its subsections. Implementations that use the "a=rid" parameter in SDP and that make use of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or FEC [RFC5109], for any of the source RTP streams that have "a=rid" lines remaining after applying the rules in Section 6 and its subsections, MUST support the RepairedRtpStreamId SDES item described in [I-D.ietf-avtext-rid] for those redundancy RTP streams. RepairedRtpStreamId MUST be used for redundancy RTP streams to which it can be applied. Use of RepairedRtpStreamId is not applicable for redundancy formats that directly associate RTP streams through shared SSRCs (for example [I-D.ietf-payload-flexible-fec-scheme]) or other cases that RepairedRtpStreamId cannot support, such as referencing multiple source streams. RepairedRtpStreamId is used to provide the binding between the redundancy RTP stream and its source RTP stream, by setting the RepairedRtpStreamId value for the redundancy RTP stream to the RtpStreamId value of the source RTP stream. The redundancy RTP stream MAY (but need not) have an "a=rid" line of its own, in which case the RtpStreamId SDES item value will be different from the corresponding source RTP stream. It is important to note that this indirection may result in the temporary inability to correctly associate source and redundancy data when the SSRC associated with the RtpStreamId or RepairedRtpStreamId is dynamically changed during the RTP session. This can be avoided if all RTP packets, source and repair, after the change include their RtpStreamId or RepairedRtpStreamId, respectively. To maximize the probability of reception and utility of redundancy information after such a change, all the source packets referenced by the first several repair packets SHOULD include such information. It is RECOMMENDED that the number of such packets is large enough to give a high probability of actual updated association. Section 4.1.1 of [RFC8285] provides relevant guidance for RTP header extension transmission considerations. Alternatively, to avoid this issue, redundancy mechanisms that directly reference its source data may be used, such as [I-D.ietf-payload-flexible-fec-scheme]. Roach (Editor) Expires November 16, 2018 [Page 5] Internet-Draft RTP Restrictions May 2018 The "direction" field identifies the direction of the RTP Stream packets to which the indicated restrictions are applied. It may be either "send" or "recv". Note that these restriction directions are expressed independently of any "inactive", "sendonly", "recvonly", or "sendrecv" attributes associated with the media section. It is, for example, valid to indicate "recv" restrictions on a "sendonly" stream; those restrictions would apply if, at a future point in time, the stream were changed to "sendrecv" or "recvonly". The optional "pt=" lists one or more PT values that can be used in the associated RTP Stream. If the "a=rid" attribute contains no "pt", then any of the PT values specified in the corresponding "m=" line may be used. The list of zero or more codec-agnostic restrictions (Section 5) describe the restrictions that the corresponding RTP Stream will conform to. This framework MAY be used in combination with the "a=fmtp" SDP attribute for describing the media format parameters for a given RTP Payload Type. In such scenarios, the "a=rid" restrictions (Section 5) further restrict the equivalent "a=fmtp" attributes. A given SDP media description MAY have zero or more "a=rid" lines describing various possible RTP payload configurations. A given "rid-id" MUST NOT be repeated in a given media description ("m=" section). The "a=rid" media attribute MAY be used for any RTP-based media transport. It is not defined for other transports, although other documents may extend its semantics for such transports. Though the restrictions specified by the "rid" restrictions follow a syntax similar to session-level and media-level parameters, they are defined independently. All "rid" restrictions MUST be registered with IANA, using the registry defined in Section 12. Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "rid" attribute. The "a=rid" media attribute is not dependent on charset. 5. "a=rid" restrictions This section defines the "a=rid" restrictions that can be used to restrict the RTP payload encoding format in a codec-agnostic way. The following restrictions are intended to apply to video codecs in a codec-independent fashion. Roach (Editor) Expires November 16, 2018 [Page 6] Internet-Draft RTP Restrictions May 2018 o max-width, for spatial resolution in pixels. In the case that stream orientation signaling is used to modify the intended display orientation, this attribute refers to the width of the stream when a rotation of zero degrees is encoded. o max-height, for spatial resolution in pixels. In the case that stream orientation signaling is used to modify the intended display orientation, this attribute refers to the height of the stream when a rotation of zero degrees is encoded. o max-fps, for frame rate in frames per second. For encoders that do not use a fixed framerate for encoding, this value is used to restrict the minimum amount of time between frames: the time between any two consecutive frames SHOULD NOT be less than 1/max- fps seconds. o max-fs, for frame size in pixels per frame. This is the product of frame width and frame height, in pixels, for rectangular frames. o max-br, for bit rate in bits per second. The restriction applies to the media payload only, and does not include overhead introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The exact means of keeping within this limit are left up to the implementation, and instantaneous excursions outside the limit are permissible. For any given one-second sliding window, however, the total number of bits in the payload portion of RTP SHOULD NOT exceed the value specified in "max-br." o max-pps, for pixel rate in pixels per second. This value SHOULD be handled identically to max-fps, after performing the following conversion: max-fps = max-pps / (width * height). If the stream resolution changes, this value is recalculated. Due to this recalculation, excursions outside the specified maximum are possible near resolution change boundaries. o max-bpp, for maximum number of bits per pixel, calculated as an average of all samples of any given coded picture. This is expressed as a floating point value, with an allowed range of 0.0001 to 48.0. These values MUST NOT be encoded with more than four digits to the right of the decimal point. o depend, to identify other streams that the stream depends on. The value is a comma-separated list of rid-ids. These rid-ids identify RTP streams that this stream depends on in order to allow for proper interpretation. The mechanism defined in this document allows for such dependencies to be expressed only when the streams are in the same media section. Roach (Editor) Expires November 16, 2018 [Page 7] Internet-Draft RTP Restrictions May 2018 All the restrictions are optional and are subject to negotiation based on the SDP Offer/Answer rules described in Section 6. This list is intended to be an initial set of restrictions. Future documents may define additional restrictions; see Section 12.2. While this document does not define restrictions for audio codecs or any media types other than video, there is no reason such restrictions should be precluded from definition and registration by other documents. Section 10 provides formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the "a=rid" restrictions defined in this section. 6. SDP Offer/Answer Procedures This section describes the SDP Offer/Answer [RFC3264] procedures when using this framework. Note that "rid-id" values are only required to be unique within a media section ("m-line"); they do not necessarily need to be unique within an entire RTP session. In traditional usage, each media section is sent on its own unique 5-tuple (that is: combination of sending address, sending port, receiving address, receiving port, and transport protocol), which provides an unambiguous scope. Similarly, when using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP streams uniquely to a single media description. When RID is used with the BUNDLE mechanism, streams will be associated with both MID and RID SDES items. 6.1. Generating the Initial SDP Offer For each RTP media description in the offer, the offerer MAY choose to include one or more "a=rid" lines to specify a configuration profile for the given set of RTP Payload Types. In order to construct a given "a=rid" line, the offerer must follow these steps: 1. It MUST generate a "rid-id" that is unique within a media description 2. It MUST set the direction for the "rid-id" to one of "send" or "recv" 3. It MAY include a listing of SDP media formats (usually corresponding to RTP payload types) allowed to appear in the RTP Stream. Any Payload Types chosen MUST be a valid payload type Roach (Editor) Expires November 16, 2018 [Page 8] Internet-Draft RTP Restrictions May 2018 for the media section (that is, it must be listed on the "m=" line). The order of the listed formats is significant; the alternatives are listed from (left) most preferred to (right) least preferred. When using RID, this preference overrides the normal codec preference as expressed by format type ordering on the "m="-line, using regular SDP rules. 4. The Offerer then chooses zero or more "a=rid" restrictions (Section 5) to be applied to the RTP Stream, and adds them to the "a=rid" line. 5. If the offerer wishes the answerer to have the ability to specify a restriction, but does not wish to set a value itself, it includes the name of the restriction in the "a=rid" line, but without any indicated value. Note: If an "a=fmtp" attribute is also used to provide media-format- specific parameters, then the "a=rid" restrictions will further restrict the equivalent "a=fmtp" parameters for the given Payload Type for the specified RTP Stream. If a given codec would require an "a=fmtp" line when used without "a=rid" then the offer MUST include a valid corresponding "a=fmtp" line even when using "a=rid". 6.2. Answerer processing the SDP Offer 6.2.1. "a=rid"-unaware Answerer If the receiver doesn't support the framework defined in this specification, the entire "a=rid" line is ignored following the standard [RFC3264] Offer/Answer rules. Section 6.1 requires the offer to include a valid "a=fmtp" line for any media formats that otherwise require it (in other words, the "a=rid" line cannot be used to replace "a=fmtp" configuration). As a result, ignoring the "a=rid" line is always guaranteed to result in a valid session description. 6.2.2. "a=rid"-aware Answerer If the answerer supports the "a=rid" attribute, the following verification steps are executed, in order, for each "a=rid" line in a received offer: 1. The answerer ensures that the "a=rid" line is syntactically well formed. In the case of a syntax error, the "a=rid" line is discarded. Roach (Editor) Expires November 16, 2018 [Page 9] Internet-Draft RTP Restrictions May 2018 2. The answerer extracts the rid-id from the "a=rid" line and verifies its uniqueness within a media section. In the case of a duplicate, the entire "a=rid" line, and all "a=rid" lines with rid-ids that duplicate this line, are discarded and MUST NOT be included in the SDP Answer. 3. If the "a=rid" line contains a "pt=", the list of payload types is verified against the list of valid payload types for the media section (that is, those listed on the "m=" line). Any PT missing from the "m=" line is discarded from the set of values in the "pt=". If no values are left in the "pt=" parameter after this processing, then the "a=rid" line is discarded. 4. If the "direction" field is "recv", the answerer ensures that the specified "a=rid" restrictions are supported. In the case of an unsupported restriction, the "a=rid" line is discarded. 5. If the "depend" restriction is included, the answerer MUST make sure that the listed rid-ids unambiguously match the rid-ids in the media description. Any "depend" "a=rid" lines that do not are discarded. 6. The answerer verifies that the restrictions are consistent with at least one of the codecs to be used with the RTP Stream. If the "a=rid" line contains a "pt=", it contains the list of such codecs; otherwise, the list of such codecs is taken from the associated "m=" line. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties for all codecs, then the "a=rid" line is discarded. Note that the answerer does not need to understand every restriction present in a "send" line: if a stream sender restricts the stream in a way that the receiver does not understand, this causes no issues with interoperability. 6.3. Generating the SDP Answer Having performed verification of the SDP offer as described in Section 6.2.2, the answerer shall perform the following steps to generate the SDP answer. For each "a=rid" line that has not been discarded by previous processing: 1. The value of the "direction" field is reversed: "send" is changed to "recv", and "recv" is changed to "send". Roach (Editor) Expires November 16, 2018 [Page 10] Internet-Draft RTP Restrictions May 2018 2. The answerer MAY choose to modify specific "a=rid" restriction values in the answer SDP. In such a case, the modified value MUST be more restrictive than the ones specified in the offer. The answer MUST NOT include any restrictions that were not present in the offer. 3. The answerer MUST NOT modify the "rid-id" present in the offer. 4. If the "a=rid" line contains a "pt=", the answerer is allowed to discard one or more media formats from a given "a=rid" line. If the answerer chooses to discard all the media formats from an "a=rid" line, the answerer MUST discard the entire "a=rid" line. If the offer did not contain a "pt=" for a given "a=rid" line, then the answer MUST NOT contain a "pt=" in the corresponding line. 5. In cases where the answerer is unable to support the payload configuration specified in a given "a=rid" line with a direction of "recv" in the offer, the answerer MUST discard the corresponding "a=rid" line. This includes situations in which the answerer does not understand one or more of the restrictions in an "a=rid" line with a direction of "recv". Note: in the case that the answerer uses different PT values to represent a codec than the offerer did, the "a=rid" values in the answer use the PT values that are present in its answer. 6.4. Offerer Processing of the SDP Answer The offerer SHALL follow these steps when processing the answer: 1. The offerer matches the "a=rid" line in the answer to the "a=rid" line in the offer using the "rid-id". If no matching line can be located in the offer, the "a=rid" line is ignored. 2. If the answer contains any restrictions that were not present in the offer, then the offerer SHALL discard the "a=rid" line. 3. If the restrictions have been changed between the offer and the answer, the offerer MUST ensure that the modifications are more restrictive than they were in the original offer, and that they can be supported; if not, the offerer SHALL discard the "a=rid" line. 4. If the "a=rid" line in the answer contains a "pt=" but the offer did not, the offerer SHALL discard the "a=rid" line. Roach (Editor) Expires November 16, 2018 [Page 11] Internet-Draft RTP Restrictions May 2018 5. If the "a=rid" line in the answer contains a "pt=" and the offer did as well, the offerer verifies that the list of payload types is a subset of those sent in the corresponding "a=rid" line in the offer. Note that this matching must be performed semantically rather than on literal PT values, as the remote end may not be using symmetric PTs. For the purpose of this comparison: for each PT listed on the "a=rid" line in the answer, the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" lines in the answer. It then searches the list of "pt=" values indicated in the offer, and attempts to find one with an equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If all PTs in the answer can be matched, then the "pt=" values pass validation; otherwise, it fails. If this validation fails, the offerer SHALL discard the "a=rid" line. Note that this semantic comparison necessarily requires an understanding of the meaning of codec parameters, rather than a rote byte-wise comparison of their values. 6. If the "a=rid" line contains a "pt=", the offerer verifies that the attribute values provided in the "a=rid" attributes are consistent with the corresponding codecs and their other parameters. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties, then the offerer SHALL discard the "a=rid" line. 7. The offerer verifies that the restrictions are consistent with at least one of the codecs to be used with the RTP Stream. If the "a=rid" line contains a "pt=", it contains the list of such codecs; otherwise, the list of such codecs is taken from the associated "m=" line. See Section 8 for more detail. If the "a=rid" restrictions are incompatible with the other codec properties for all codecs, then the offerer SHALL discard the "a=rid" line. Any "a=rid" line present in the offer that was not matched by step 1 above has been discarded by the answerer, and does not form part of the negotiated restrictions on an RTP Stream. The offerer MAY still apply any restrictions it indicated in an "a=rid" line with a direction field of "send", but it is not required to do so. It is important to note that there are several ways in which an offer can contain a media section with "a=rid" lines, but the corresponding media section in the response does not. This includes situations in which the answerer does not support "a=rid" at all, or does not support the indicated restrictions. Under such circumstances, the offerer MUST be prepared to receive a media stream to which no restrictions have been applied. Roach (Editor) Expires November 16, 2018 [Page 12] Internet-Draft RTP Restrictions May 2018 6.5. Modifying the Session Offers and answers inside an existing session follow the rules for initial session negotiation. Such an offer MAY propose a change in the number of RIDs in use. To avoid race conditions with media, any RIDs with proposed changes SHOULD use a new ID, rather than re-using one from the previous offer/answer exchange. RIDs without proposed changes SHOULD re-use the ID from the previous exchange. 7. Use with Declarative SDP This document does not define the use of RID in declarative SDP. If concrete use cases for RID in declarative SDP use are identified in the future, we expect that additional specifications will address such use. 8. Interaction with Other Techniques Historically, a number of other approaches have been defined that allow restricting media streams via SDP. These include: o Codec-specific configuration set via format parameters ("a=fmtp"); for example, the H.264 "max-fs" format parameter [RFC6184] o Size restrictions imposed by image attribute attributes ("a=imageattr") [RFC6236] When the mechanism described in this document is used in conjunction with these other restricting mechanisms, it is intended to impose additional restrictions beyond those communicated in other techniques. In an offer, this means that "a=rid" lines, when combined with other restrictions on the media stream, are expected to result in a non- empty intersection. For example, if image attributes are used to indicate that a PT has a minimum width of 640, then specification of "max-width=320" in an "a=rid" line that is then applied to that PT is nonsensical. According to the rules of Section 6.2.2, this will result in the corresponding "a=rid" line being ignored by the recipient. In an answer, the "a=rid" lines, when combined with the other restrictions on the media stream, are also expected to result in a non-empty intersection. If the implementation generating an answer wishes to restrict a property of the stream below that which would be allowed by other parameters (e.g., those specified in "a=fmtp" or "a=imageattr"), its only recourse is to discard the "a=rid" line altogether, as described in Section 6.3. If it instead attempts to Roach (Editor) Expires November 16, 2018 [Page 13] Internet-Draft RTP Restrictions May 2018 restrict the stream beyond what is allowed by other mechanisms, then the offerer will ignore the corresponding "a=rid" line, as described in Section 6.4. The following subsections demonstrate these interactions using commonly-used video codecs. These descriptions are illustrative of the interaction principles outlined above, and are not normative. 8.1. Interaction with VP8 Format Parameters [RFC7741] defines two format parameters for the VP8 codec. Both correspond to restrictions on receiver capabilities, and never indicate sending restrictions. 8.1.1. max-fr - Maximum Framerate The VP8 "max-fr" format parameter corresponds to the "max-fps" restriction defined in this specification. If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fps" parameter, then the sent stream will conform to the smaller of the two values. 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks The VP8 "max-fs" format parameter corresponds to the "max-fs" restriction defined in this document, by way of a conversion factor of the number of pixels per macroblock (typically 256). If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fs" parameter, then the sent stream will conform to the smaller of the two values; that is, the number of pixels per frame will not exceed: min(rid_max_fs, fmtp_max_fs * macroblock_size) This fmtp parameter also has bearing on the max-height and max-width parameters. Section 6.1 of [RFC7741] requires that the width and height of the frame in macroblocks are also required to be less than int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a transmitted stream will be limited to: min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) Similarly, the stream's height will be limited to: min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) Roach (Editor) Expires November 16, 2018 [Page 14] Internet-Draft RTP Restrictions May 2018 8.2. Interaction with H.264 Format Parameters [RFC6184] defines format parameters for the H.264 video codec. The majority of these parameters do not correspond to codec-independent restrictions: o deint-buf-cap o in-band-parameter-sets o level-asymmetry-allowed o max-rcmd-nalu-size o max-cpb o max-dpb o packetization-mode o redundant-pic-cap o sar-supported o sar-understood o sprop-deint-buf-req o sprop-init-buf-time o sprop-interleaving-depth o sprop-level-parameter-sets o sprop-max-don-diff o sprop-parameter-sets o use-level-src-parameter-sets Note that the max-cpb and max-dpb format parameters for H.264 correspond to restrictions on the stream, but they are specific to the way the H.264 codec operates, and do not have codec-independent equivalents. The [RFC6184] codec format parameters covered in the following sections correspond to restrictions on receiver capabilities, and never indicate sending restrictions. Roach (Editor) Expires November 16, 2018 [Page 15] Internet-Draft RTP Restrictions May 2018 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile These parameters include a "level" indicator, which acts as an index into Table A-1 of [H264]. This table contains a number of parameters, several of which correspond to the restrictions defined in this document. [RFC6184] also defines format parameters for the H.264 codec that may increase the maximum values indicated by the negotiated level. The following sections describe the interaction between these parameters and the restrictions defined by this document. In all cases, the H.264 parameters being discussed are the maximum of those indicated by [H264] Table A-1 and those indicated in the corresponding "a=fmtp" line. 8.2.2. max-br / MaxBR - Maximum Video Bitrate The H.264 "MaxBR" parameter (and its equivalent "max-br" format parameter) corresponds to the "max-bps" restriction defined in this specification, by way of a conversion factor of 1000 or 1200; see [RFC6184] for details regarding which factor gets used under differing circumstances. If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fps" parameter, then the sent stream will conform to the smaller of the two values - that is: min(rid_max_br, h264_MaxBR * conversion_factor) 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks The H.264 "MaxFs" parameter (and its equivalent "max-fs" format parameter) corresponds roughly to the "max-fs" restriction defined in this document, by way of a conversion factor of 256 (the number of pixels per macroblock). If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-fs" parameter, then the sent stream will conform to the smaller of the two values - that is: min(rid_max_fs, h264_MaxFs * 256) 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format parameter) corresponds roughly to the "max-pps" restriction defined in this document, by way of a conversion factor of 256 (the number of pixels per macroblock). Roach (Editor) Expires November 16, 2018 [Page 16] Internet-Draft RTP Restrictions May 2018 If an RTP sender is generating a stream using a format defined with this format parameter, and the sending restrictions defined via "a=rid" include a "max-pps" parameter, then the sent stream will conform to the smaller of the two values - that is: min(rid_max_pps, h264_MaxMBPS * 256) 8.2.5. max-smbps - Maximum Decoded Picture Buffer The H.264 "max-smbps" format parameter operates the same way as the "max-mpbs" format parameter, under the hypothetical assumption that all macroblocks are static macroblocks. It is handled by applying the conversion factor described in Section 8.1 of [RFC6184], and the result of this conversion is applied as described in Section 8.2.4. 8.3. Redundancy Formats and Payload Type Restrictions Section 4 specifies that redundancy formats using redundancy RTP streams bind the redundancy RTP stream to the source RTP stream with either the RepairedRtpStreamId SDES item, or other mechanisms. However, there exist redundancy RTP payload formats that result in the redundancy being included in the source RTP stream. An example of this is "RTP Payload for Redundant Audio Data" [RFC2198], which encapsulates one source stream with one or more redundancy streams in the same RTP payload. Formats defining the source and redundancy encodings as regular RTP payload types require some consideration for how the "a=rid" restrictions are defined. The "a=rid" line "pt=" parameter can be used to indicate whether the redundancy RTP payload type and/or the individual source RTP payload type(s) are part of the restriction. Example (SDP Excerpt): Roach (Editor) Expires November 16, 2018 [Page 17] Internet-Draft RTP Restrictions May 2018 m=audio 49200 RTP/AVP 97 98 99 100 101 102 a=mid:foo a=rtpmap:97 G711/8000 a=rtpmap:98 LPC/8000 a=rtpmap:99 OPUS/48000/1 a=rtpmap:100 RED/8000/1 a=rtpmap:101 CN/8000 a=rtpmap:102 telephone-event/8000 a=fmtp:99 useinbandfec=1; usedtx=0 a=fmtp:100 97/98 a=fmtp:102 0-15 a=ptime:20 a=maxptime:40 a=rid:5 send pt=99,102;max-br=64000 a=rid:6 send pt=100,97,101,102 The RID with ID=6 restricts the payload types for this RID to 100 (the redundancy format), 97 (G.711), 101 (Comfort Noise) and 102 (DTMF tones). This means that RID 6 can either contain the RED format, encapsulating encodings of the source media stream using payload type 97 and 98, 97 without RED encapsulation, Comfort noise, or DTMF tones. Payload type 98 is not included in the RID, and can thus not be sent except as redundancy information in RED encapsulation. If 97 were to be excluded from the pt parameter, it would instead mean that payload types 97 and 98 are only allowed via RED encapsulation. 9. Format Parameters for Future Payloads Registrations of future RTP payload format specifications that define media types that have parameters matching the RID restrictions specified in this memo SHOULD name those parameters in a manner that matches the names of those RID restrictions, and SHOULD explicitly state what media type parameters are restricted by what RID restrictions. 10. Formal Grammar This section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar, with the case-sensitive extensions described in [RFC7405], for each of the new media and "a=rid" attributes defined in this document. rid-syntax = %s"a=rid:" rid-id SP rid-dir [ rid-pt-param-list / rid-param-list ] rid-id = 1*(alpha-numeric / "-" / "_") Roach (Editor) Expires November 16, 2018 [Page 18] Internet-Draft RTP Restrictions May 2018 alpha-numeric = < as defined in {{RFC4566}} > rid-dir = %s"send" / %s"recv" rid-pt-param-list = SP rid-fmt-list *(";" rid-param) rid-param-list = SP rid-param *(";" rid-param) rid-fmt-list = %s"pt=" fmt *( "," fmt ) fmt = < as defined in {{RFC4566}} > rid-param = rid-width-param / rid-height-param / rid-fps-param / rid-fs-param / rid-br-param / rid-pps-param / rid-bpp-param / rid-depend-param / rid-param-other rid-width-param = %s"max-width" [ "=" int-param-val ] rid-height-param = %s"max-height" [ "=" int-param-val ] rid-fps-param = %s"max-fps" [ "=" int-param-val ] rid-fs-param = %s"max-fs" [ "=" int-param-val ] rid-br-param = %s"max-br" [ "=" int-param-val ] rid-pps-param = %s"max-pps" [ "=" int-param-val ] rid-bpp-param = %s"max-bpp" [ "=" float-param-val ] rid-depend-param = %s"depend=" rid-list rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-list = rid-id *( "," rid-id ) int-param-val = 1*DIGIT float-param-val = 1*DIGIT "." 1*DIGIT param-val = *( %x20-58 / %x60-7E ) ; Any printable character except semicolon Roach (Editor) Expires November 16, 2018 [Page 19] Internet-Draft RTP Restrictions May 2018 11. SDP Examples Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in simulcast scenarios. 11.1. Many Bundled Streams using Many Codecs In this scenario, the offerer supports the Opus, G.722, G.711 and DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send 1 and receive 7 video streams) by offering 7 video media sections (1 sendrecv at max resolution and 6 recvonly at smaller resolutions), all bundled on the same port, using 3 different resolutions. The resolutions include: o 1 receive stream of 720p resolution is offered for the active speaker. o 2 receive streams of 360p resolution are offered for the prior 2 active speakers. o 4 receive streams of 180p resolution are offered for others in the call. NOTE: The SDP given below skips a few lines to keep the example short and focused, as indicated by either the "..." or the comments inserted. The offer for this scenario is shown below. ... m=audio 10000 RTP/SAVPF 96 9 8 0 123 a=rtpmap:96 OPUS/48000 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:123 telephone-event/8000 a=mid:a1 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtpmap:98 VP8/90000 a=fmtp:98 max-fs=3600; max-fr=30 a=rtpmap:99 VP9/90000 a=fmtp:99 max-fs=3600; max-fr=30 a=rtpmap:100 H264/90000 a=fmtp:100 profile-level-id=42401f; packetization-mode=0 a=rtpmap:101 H264/90000 Roach (Editor) Expires November 16, 2018 [Page 20] Internet-Draft RTP Restrictions May 2018 a=fmtp:101 profile-level-id=42401f; packetization-mode=1 a=rtpmap:102 H264/90000 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 a=rtpmap:103 H264/90000 a=fmtp:103 profile-level-id=640c1f; packetization-mode=1 a=rtpmap:104 H264-SVC/90000 a=fmtp:104 profile-level-id=530c1f a=rtpmap:105 H264-SVC/90000 a=fmtp:105 profile-level-id=560c1f a=rtpmap:106 H265/90000 a=fmtp:106 profile-id=1; level-id=93 a=rtpmap:107 H265/90000 a=fmtp:107 profile-id=2; level-id=93 a=sendrecv a=mid:v1 (max resolution) a=rid:1 send max-width=1280;max-height=720;max-fps=30 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v2 (medium resolution) a=rid:3 recv max-width=640;max-height=360;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v3 (medium resolution) a=rid:3 recv max-width=640;max-height=360;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... a=recvonly a=mid:v4 (small resolution) a=rid:4 recv max-width=320;max-height=180;max-fps=15 ... m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id ...same rtpmap/fmtp as above... ...same rid:4 as above for mid:v5,v6,v7 (small resolution)... ... Roach (Editor) Expires November 16, 2018 [Page 21] Internet-Draft RTP Restrictions May 2018 11.2. Scalable Layers Adding scalable layers to a session within a multiparty conference gives a selective forwarding unit (SFU) further flexibility to selectively forward packets from a source that best match the bandwidth and capabilities of diverse receivers. Scalable encodings have dependencies between layers, unlike independent simulcast streams. RIDs can be used to express these dependencies using the "depend" restriction. In the example below, the highest resolution is offered to be sent as 2 scalable temporal layers (using MRST). See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about simulcast usage. Offer: ... m=audio ...same as previous example ... ... m=video ...same as previous example ... ...same rtpmap/fmtp as previous example ... a=sendrecv a=mid:v1 (max resolution) a=rid:0 send max-width=1280;max-height=720;max-fps=15 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 a=rid:2 recv max-width=1280;max-height=720;max-fps=30 a=rid:5 send max-width=640;max-height=360;max-fps=15 a=rid:6 send max-width=320;max-height=180;max-fps=15 a=simulcast: send rid=0;1;5;6 recv rid=2 ... ...same m=video sections as previous example for mid:v2-v7... ... 12. IANA Considerations This specification updates [RFC4855] to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to RID restrictions. 12.1. New SDP Media-Level attribute This document defines "rid" as SDP media-level attribute. This attribute must be registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)". The "rid" attribute is used to identify properties of RTP stream with in an RTP Session. Its format is defined in Section 10. The formal registration information for this attribute follows. Roach (Editor) Expires November 16, 2018 [Page 22] Internet-Draft RTP Restrictions May 2018 Contact name, email address, and telephone number IETF MMUSIC Working Group mmusic@ietf.org +1 510 492 4080 Attribute name (as it will appear in SDP) rid Long-form attribute name in English Restriction Identifier Type of attribute (session level, media level, or both) Media Level Whether the attribute value is subject to the charset attribute The attribute is not dependent on charset. A one-paragraph explanation of the purpose of the attribute The "rid" SDP attribute is used to to unambiguously identify the RTP Streams within an RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. A specification of appropriate attribute values for this attribute Valid values are defined by the ABNF in [RFCXXXXX] Multiplexing (Mux) Category SPECIAL 12.2. Registry for RID-Level Parameters This specification creates a new IANA registry named "rid attribute parameters" within the SDP parameters registry. The "a=rid" restrictions MUST be registered with IANA and documented under the same rules as for SDP session-level and media-level attributes as specified in [RFC4566]. Parameters for "a=rid" lines that modify the nature of encoded media MUST be of the form that the result of applying the modification to the stream results in a stream that still complies with the other Roach (Editor) Expires November 16, 2018 [Page 23] Internet-Draft RTP Restrictions May 2018 parameters that affect the media. In other words, restrictions always have to restrict the definition to be a subset of what is otherwise allowable, and never expand it. New restriction registrations are accepted according to the "Specification Required" policy of [RFC5226]. The registration MUST contain the RID parameter name and a reference to the corresponding specification. The specification itself must contain the following information (not all of which appears in the registry): o restriction name (as it will appear in SDP) o an explanation of the purpose of the restriction o a specification of appropriate attribute values for this restriction o an ABNF definition of the restriction The initial set of "a=rid" restriction names, with definitions in Section 5 of this document, is given below: RID Parameter Name Reference ------------------ --------- max-width [RFCXXXX] max-height [RFCXXXX] max-fps [RFCXXXX] max-fs [RFCXXXX] max-br [RFCXXXX] max-pps [RFCXXXX] max-bpp [RFCXXXX] depend [RFCXXXX] It is conceivable that a future document wants to define a RID-level restrictions that contain string values. These extensions need to take care to conform to the ABNF defined for rid-param-other. In particular, this means that such extensions will need to define escaping mechanisms if they want to allow semicolons, unprintable characters, or byte values greater than 127 in the string. 13. Security Considerations As with most SDP parameters, a failure to provide integrity protection over the "a=rid" attributes provides attackers a way to modify the session in potentially unwanted ways. This could result in an implementation sending greater amounts of data than a recipient Roach (Editor) Expires November 16, 2018 [Page 24] Internet-Draft RTP Restrictions May 2018 wishes to receive. In general, however, since the "a=rid" attribute can only restrict a stream to be a subset of what is otherwise allowable, modification of the value cannot result in a stream that is of higher bandwidth than would be sent to an implementation that does not support this mechanism. The actual identifiers used for RIDs are expected to be opaque. As such, they are not expected to contain information that would be sensitive, were it observed by third-parties. 14. Acknowledgements Many thanks to review from Cullen Jennings, Magnus Westerlund, and Paul Kyzivat. Thanks to Colin Perkins for input on future payload type handing. 15. References 15.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, . Roach (Editor) Expires November 16, 2018 [Page 25] Internet-Draft RTP Restrictions May 2018 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References [H264] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services (V9)", February 2014, . [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-51 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-simulcast] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", draft-ietf- mmusic-sdp-simulcast-12 (work in progress), April 2018. [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in progress), March 2018. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . Roach (Editor) Expires November 16, 2018 [Page 26] Internet-Draft RTP Restrictions May 2018 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ RFC6184, May 2011, . [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . Appendix A. Contributors The following individuals have contributed significant text to this document. Roach (Editor) Expires November 16, 2018 [Page 27] Internet-Draft RTP Restrictions May 2018 Peter Thatcher Google Email: pthatcher@google.com Mo Zanaty Cisco Systems Email: mzanaty@cisco.com Suhas Nandakumar Cisco Systems Email: snandaku@cisco.com Bo Burman Ericsson Email: bo.burman@ericsson.com Byron Campen Mozilla Email: bcampen@mozilla.com Author's Address Adam Roach Mozilla Email: adam@nostrum.com Roach (Editor) Expires November 16, 2018 [Page 28] ./draft-ietf-mmusic-sctp-sdp-26.txt0000644000764400076440000015300113076144361016415 0ustar iustyiusty MMUSIC C. Holmberg Internet-Draft Ericsson Intended status: Standards Track R. Shpount Expires: October 22, 2017 TurboBridge S. Loreto G. Camarillo Ericsson April 20, 2017 Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. draft-ietf-mmusic-sctp-sdp-26 Abstract The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 22, 2017. Holmberg, et al. Expires October 22, 2017 [Page 1] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Copyright Notice Copyright (c) 2017 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. SCTP Terminology . . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Media Descriptions . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Protocol Identifiers . . . . . . . . . . . . . . . . . . 5 4.3. Media Format Management . . . . . . . . . . . . . . . . . 5 4.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.2. SDP Media Description values . . . . . . . . . . . . 6 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 7 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 8 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 9 7. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 9 8. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 10 9. Association And Connection Management . . . . . . . . . . . . 10 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute . . . . 10 9.3. SCTP Association . . . . . . . . . . . . . . . . . . . . 10 9.4. DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP) . . . 11 9.5. TCP Connection (TCP/DTLS/SCTP) . . . . . . . . . . . . . 12 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Generating the Initial SDP Offer . . . . . . . . . . . . 13 10.3. Generating the SDP Answer . . . . . . . . . . . . . . . 13 Holmberg, et al. Expires October 22, 2017 [Page 2] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 10.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 10.5. Modifying the Session . . . . . . . . . . . . . . . . . 15 11. Multihoming Considerations . . . . . . . . . . . . . . . . . 16 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 16 12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 16 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 17 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15.1. New SDP proto values . . . . . . . . . . . . . . . . . . 19 15.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 19 15.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 19 15.2.2. max-message-size . . . . . . . . . . . . . . . . . . 19 15.3. association-usage Name Registry . . . . . . . . . . . . 19 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 18.1. Normative References . . . . . . . . . . . . . . . . . . 23 18.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction SDP (Session Description Protocol) [RFC4566] provides a general- purpose format for describing multimedia sessions in announcements or invitations. TCP-Based Media Transport in the Session Description Protocol (SDP) [RFC4145] specifies a general mechanism for describing and establishing TCP [RFC0793] streams. Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in SDP [RFC8122] extends RFC4145 [RFC4145] for describing TCP-based media streams that are protected using TLS. The Stream Control Transmission Protocol (SCTP) [RFC4960] is a reliable transport protocol used to transport data between two endpoints using SCTP associations. [I-D.ietf-tsvwg-sctp-dtls-encaps] specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) [RFC4566] protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. Holmberg, et al. Expires October 22, 2017 [Page 3] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: Due to the characteristics of TCP, while multiple SCTP streams can still be used, usage of 'TCP/DTLS/SCTP' will always force ordered and reliable delivery of the SCTP packets, which limits the usage of the SCTP options. Therefore, it is RECOMMENDED that TCP is only used in situations where UDP traffic is blocked. 2. Conventions 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]. 3. SCTP Terminology SCTP Association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. SCTP Stream: A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. SCTP-over-DTLS: SCTP used on top of DTLS, as specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. 4. SDP Media Descriptions 4.1. General This section defines the following new SDP Media Description (m- line) protocol identifiers (proto values) for describing an SCTP association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section also describes how an m- line, associated with the proto values, is created. The following is the format for an m- line, as specified in RFC4566 [RFC4566]: m= ... The 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are similar to both the 'UDP' and 'TCP' proto values in that they only describe the transport-layer protocol and not the upper-layer protocol. Holmberg, et al. Expires October 22, 2017 [Page 4] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are used, the underlying transport protocol is respectively UDP and TCP; SCTP is carried on top of DTLS which is on top of those transport- layer protocols. 4.2. Protocol Identifiers The new proto values are defined as below: o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on top of a DTLS association on top of UDP, as defined in Section 7. o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on top of a DTLS association on top of TCP, as defined in Section 8. 4.3. Media Format Management [RFC4566] defines that specifications defining new proto values must define the rules by which their media format (fmt) namespace is managed. An m- line with a proto value of 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' always describes a single SCTP association. In addition, such m- line MUST further indicate the application-layer protocol using an 'fmt' identifier. There MUST be exactly one fmt value per m- line associated with the proto values defined in this specification. The 'fmt' namespace associated with those proto values describes the generic application usage of the entire SCTP association, including the associated SCTP streams. When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, the m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. Section 15.3 defines the IANA registry for the media format namespace. NOTE: A mechanism on how to describe, and manage, individual SCTP streams within an SCTP association, is outside the scope of this specification. [I-D.ietf-mmusic-data-channel-sdpneg] defines a mechanism for negotiating individual SCTP streams used to realize WebRTC data channels [I-D.ietf-rtcweb-data-channel]. 4.4. Syntax Holmberg, et al. Expires October 22, 2017 [Page 5] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 4.4.1. General This section defines the values that can be used within an SDP media description ("m=" line) associated with an SCTP-over-DTLS association. This specification creates an IANA registry for 'association-usage' values. 4.4.2. SDP Media Description values m= line parameter parameter value(s) ------------------------------------------------------------------ : 'application' : 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' : UDP port number (for 'UDP/DTLS/SCTP') TCP port number (for 'TCP/DTLS/SCTP') : a string denoting the association-usage, limited to the syntax of a 'token' as defined in RFC4566. 4.5. Example m=application 12345 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port:5000 a=max-message-size:100000 NOTE: 'webrtc-datachannel' indicates the WebRTC Data Channel Establishment Protocol defined in [I-D.ietf-rtcweb-data-protocol]. 5. SDP 'sctp-port' Attribute 5.1. General This section defines a new SDP media-level attribute, 'sctp-port'. The attribute can be associated with an SDP media description (m- line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value. In that case the m- line port value indicates the port of the underlying transport layer protocol (UDP or TCP), and the 'sctp-port' value indicates the SCTP port. No default value is defined for the SDP sctp-port attribute. Therefore, if the attribute is not present, the associated m- line MUST be considered invalid. Holmberg, et al. Expires October 22, 2017 [Page 6] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: This specification only defines the usage of the SDP 'sctp- port' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. 5.2. Syntax [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] The definition of the SDP 'sctp-port' attribute is: Attribute name: sctp-port Type of attribute: media Mux category: CAUTION Subject to charset: No Purpose: Indicate the SCTP port value associated with the SDP Media Description. Appropriate values: Integer Contact name: Christer Holmberg Contact e-mail: christer.holmberg@ericsson.com Reference: RFCXXXX Syntax: sctp-port-value = 1*5 The SCTP port range is between 0 and 65535 (both included). Leading zeroes MUST NOT be used. Example: a=sctp-port:5000 5.3. Mux Category The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the SDP 'sctp-port' attribute is CAUTION. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. Future extensions, that define how to negotiate multiplexing of multiple SCTP associations of top of a single DTLS association, need to also define the mux rules for the attribute. Holmberg, et al. Expires October 22, 2017 [Page 7] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 6. SDP 'max-message-size' Attribute 6.1. General This section defines a new SDP media-level attribute, 'max-message- size'. The attribute can be associated with an m- line to indicate the maximum SCTP user message size (indicated in bytes) that an SCTP endpoint is willing to receive on the SCTP association associated with the m- line. Different attribute values can be used in each direction. An SCTP endpoint MUST NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer, as it cannot be assumed that the peer would accept such message. If the SDP 'max-message-size' attribute contains a maximum message size value of zero, it indicates the SCTP endpoint will handle messages of any size, subject to memory capacity etc. If the SDP 'max-message-size' attribute is not present, the default value is 64K. NOTE: This specification only defines the usage of the SDP 'max- message-size' attribute when associated with an m- line containing one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ SCTP'. Usage of the attribute with other proto values needs to be defined in a separate specification. 6.2. Syntax [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] The definition of the SDP 'max-message-size' attribute is: Holmberg, et al. Expires October 22, 2017 [Page 8] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Attribute name: max-message-size Type of attribute: media Mux category: CAUTION Subject to charset: No Purpose: Indicate the maximum message size (indicated in bytes) that an SCTP endpoint is willing to receive on the SCTP association associated with the SDP Media Description. Appropriate values: Integer Contact name: Christer Holmberg Contact e-mail: christer.holmberg@ericsson.com Reference: RFCXXXX Syntax: max-message-size-value = 1* Leading zeroes MUST NOT be used. Example: a=max-message-size:100000 6.3. Mux Category The mux category for the SDP 'max-message-size' attribute is CAUTION. As the usage of multiple SCTP associations on top of a single DTLS association is outside the scope of this specification, no mux rules are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values. 7. UDP/DTLS/SCTP Transport Realization The UDP/DTLS/SCTP transport is realized as described below: o SCTP on top of DTLS is realized according to the procedures defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and o DTLS on top of UDP is realized according to the procedures in defined in [RFC6347]. NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association. Holmberg, et al. Expires October 22, 2017 [Page 9] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 8. TCP/DTLS/SCTP Transport Realization The TCP/DTLS/SCTP transport is realized as described below: o SCTP on top of DTLS is realized according to the procedures defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and o DTLS on top of TCP is realized using the framing method defined in [RFC4571], with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in [RFC4571], so that length field defined in [RFC4571] precedes each DTLS message, and SDP signaling according to the procedures defined in this specification. NOTE: TLS on top of TCP, without using the framing method defined in [RFC4571] is outside the scope of this specification. A separate proto value would need to be registered for such transport realization. 9. Association And Connection Management 9.1. General This section describes how to manage an SCTP association, DTLS association and TCP connection using SDP attributes. The SCTP association, the DTLS association and the TCP connection are managed independently from each other. Each can be established and closed without impacting others. The detailed SDP Offer/Answer [RFC3264] procedures for the SDP attributes are described in Section 10. 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute This specification does not define semantics for the SDP direction attributes [RFC4566]. Unless semantics of these attributes for an SCTP association usage have been defined, SDP direction attributes MUST be ignored if present. 9.3. SCTP Association When an SCTP association is established, both SCTP endpoints MUST initiate the SCTP association (i.e. both SCTP endpoints take the 'active' role), and MUST use the same SCTP port as client port and server port (in order to prevent two separate SCTP associations from being established). Holmberg, et al. Expires October 22, 2017 [Page 10] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 As both SCTP endpoints take the 'active' role, the SDP 'setup' attribute [RFC4145] does not apply to SCTP association establishment. However the 'setup' attribute does apply to establishment of the underlying DTLS association and TCP connection. NOTE: The procedure above is different from TCP, where one endpoint takes the 'active' role, the other endpoint takes the 'passive' role, and only the 'active' endpoint initiates the TCP connection [RFC4145]. NOTE: When the SCTP association is established it is assumed that any NAT traversal procedures for the underlying transport protocol (UDP or TCP) have successfully been performed. The SDP 'connection' attribute [RFC4145] does not apply to the SCTP association. In order to trigger the closure of an existing SCTP association, and establishment of a new SCTP association, the SDP 'sctp-port' attribute [Section 5] is used to indicate a new (different than the ones currently used) SCTP port. The existing SCTP association is closed, and the new SCTP association is established, if one or both endpoints signal a new SCTP port. The 'connection' attribute does apply to establishment of underlying TCP connections. Alternatively, an SCTP association can be closed using the SDP 'sctp- port' attribute with a zero attribute value. Later, a new SCTP association can be established using the procedures in this section for establishing an SCTP association. SCTP associations might be closed without SDP signalling, e.g, in case of a failure. The procedures in this section MUST be followed to establish a new SCTP association. This requires a new SDP Offer/ Answer exchange. New (different than the ones currently used) SCTP ports MUST be used by both endpoints. NOTE: Closing and establishing a new SCTP association using the SDP 'sctp-port' attribute will not affect the state of the underlying DTLS association. 9.4. DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP) A DTLS association is managed according to the procedures in [I-D.ietf-mmusic-dtls-sdp]. Hence, the SDP 'setup' attribute is used to negotiate the (D)TLS roles ('client' and 'server') [RFC8122]. NOTE: The SDP 'setup' attribute is used to negotiate both the DTLS roles and the TCP roles (Section 9.5). Holmberg, et al. Expires October 22, 2017 [Page 11] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 NOTE: As described in [RFC5245], if the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used, all ICE candidates associated with a DTLS association are considered part of the same DTLS association. Thus, a switch from one candidate pair to another candidate pair will not trigger the establishment of a new DTLS association. 9.5. TCP Connection (TCP/DTLS/SCTP) The TCP connection is managed according to the procedures in [RFC4145]. Hence, the SDP 'setup' attribute is used to negotiate the TCP roles ('active' and 'passive'), and the SDP 'connection' attribute is used to indicate whether to use an existing TCP connection, or create a new one. The SDP 'setup' attribute 'holdconn' value MUST NOT be used. NOTE: A change of the TCP roles will also trigger a closure of the DTLS association, and establishment of a new DTLS association, according to the procedures in [I-D.ietf-mmusic-dtls-sdp]. NOTE: As specified in [I-D.ietf-mmusic-dtls-sdp], usage of the SDP 'setup' attribute 'holdconn' value is not allowed. Therefore this specification also forbids usage of the attribute value for TCP, as DTLS is transported on top of TCP. 10. SDP Offer/Answer Procedures 10.1. General This section defines the SDP Offer/Answer [RFC3264] procedures for negotiating and establishing an SCTP-over-DTLS association. Unless explicitly stated, the procedures apply to both the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' m- line proto values. Each endpoint MUST associate one or more certificate fingerprints, using the SDP 'fingerprint' attribute with the m- line, following the procedures in [RFC8122]. The authentication certificates are interpreted and validated as defined in [RFC8122]. Self-signed certificates can be used securely, provided that the integrity of the SDP description is assured as defined in [RFC8122]. Each endpoint MUST associate an SDP 'tls-id' attribute with the m- line, following the procedures in [I-D.ietf-mmusic-dtls-sdp]. Holmberg, et al. Expires October 22, 2017 [Page 12] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 10.2. Generating the Initial SDP Offer When the offerer creates an initial offer, the offerer: o MUST associate an SDP setup attribute with the m- line; o MUST associate an SDP 'sctp-port' attribute with the m- line; o MUST, in the case of TCP/DTLS/SCTP, associate an SDP 'connection' attribute, with a 'new' attribute value, with the m- line; and o MAY associate an SDP 'max-message-size' attribute [Section 6] with the m- line. 10.3. Generating the SDP Answer When the answerer receives an offer, which contains an m- line describing an SCTP-over-DTLS association, if the answerer accepts the association, the answerer: o MUST insert a corresponding m- line in the answer, with an m- line proto value [RFC3264] identical to the value in the offer; o MUST associate an SDP 'setup' attribute with the m- line; o MUST associate an SDP 'sctp-port' attribute with the m- line. If the offer contained a new (different than the one currently used) SCTP port value the answerer MUST also associate a new SCTP port value. If the offer contained a zero SCTP port value, or if the answerer does not accept the SCTP association, the answerer MUST also associate a zero SCTP port value; and o MAY associate an SDP 'max-message-size' attribute [Section 6] with the m- line. The attribute value in the answer is independent from the value (if present) in the corresponding m- line of the offer. Once the answerer has sent the answer the answerer: o MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been established, or if an existing TCP connection is to be closed and replaced by a new TCP connection, follow the procedures in [RFC4145] for closing and establishing a TCP connection; o MUST, if a DTLS association has not yet been established, or if an existing DTLS association is to be closed and replaced by a new DTLS association, follow the procedures in Holmberg, et al. Expires October 22, 2017 [Page 13] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 [I-D.ietf-mmusic-dtls-sdp] for closing the currently used, and establishing a new, DTLS association; and o MUST, if an SCTP association has not yet been established, or if an existing SCTP association is to be closed and replaced by a new SCTP association, initiate the closing of the existing SCTP association (if applicable) and establishment of the SCTP association. If the SDP 'sctp-port' attribute in the answer contains a zero attribute value, the answerer MUST NOT establish an SCTP association. If an SCTP association exists, the offerer MUST close it. If the answerer does not accept the m- line in the offer, it MUST assign a zero port value to the corresponding m- line in the answer, following the procedures in [RFC3264]. In addition, the answerer MUST NOT initiate the establishment of a TCP connection, a DTLS association or a DTLS association associated with the m- line. 10.4. Offerer Processing of the SDP Answer Once the offerer has received the answer the offerer: o MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not yet been established, or if an existing TCP connection is to be closed and replaced by a new TCP connection, follow the procedures in [RFC4145] for closing and establishing a TCP connection; o MUST, if a DTLS association has not yet been established, or if an existing DTLS association is to be closed and replaced by a new DTLS association, follow the procedures in [I-D.ietf-mmusic-dtls-sdp] for closing and establishing a DTLS association; and o MUST, if an SCTP association has not yet been established, or if an existing SCTP association is to be closed and replaced by a new SCTP association, initiate the closing of the existing SCTP association (if applicable) and establishment of the SCTP association. If the SDP 'sctp-port' attribute in the answer contains a zero attribute value, the offerer MUST NOT establish an SCTP association. If an SCTP association exists in that case, the offerer MUST close it. If the m- line in the answer contains a zero port value, the offerer MUST NOT initiate the establishment a TCP connection, a DTLS association or an SCTP association associated with the m- line. If a Holmberg, et al. Expires October 22, 2017 [Page 14] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 TCP connection, or a DTLS association or an SCTP association exists in that case, the offerer MUST close it. 10.5. Modifying the Session When an offerer sends an updated offer, in order to modify a previously established SCTP association, it follows the procedures in Section 10.2, with the following exceptions: o If the offerer wants to close an SCTP association, and immediately establish a new SCTP association, the offerer MUST associate an SDP 'sctp-port' attribute with a new (different than the one currently used) attribute value. This will not impact the underlying DTLS association (and TCP connection in case of TCP/DTLS/SCTP). o If the offerer wants to close an SCTP association, without immediately establishing a new SCTP association, the offerer MUST associate an SDP 'sctp-port' attribute with a zero attribute value. This will not impact the underlying DTLS association (and TCP connection in case of TCP/DTLS/SCTP). o If the offerer wants to establish an SCTP association, and another SCTP association was previously closed, the offerer MUST associate an SDP 'sctp-port' attribute with a new attribute value (different than the value associated with the previous SCTP association). If the previous SCTP association was closed successfully following use of an SDP 'sctp-port' attribute with a zero attribute value, the offerer MAY use the same attribute value for the new SCTP association that was used with the previous SCTP association before it was closed. This will not impact the underlying DTLS association (and TCP connection in case of TCP/DTLS/SCTP). o If the offerer wants to close an existing SCTP association, and the underlying DTLS association (and the underlying TCP connection in case of TCP/DTLS/SCTP) it MUST assign a zero port value to the m- line associated with the SCTP and DTLS associations (and TCP connection in case of TCP/DTLS/SCTP), following the procedures in [RFC3264]. o NOTE: This specification does not define a mechanism for explicitly closing a DTLS association while maintaining the overlying SCTP association. However, if a DTLS association is closed and replaced with a new DTLS association, as a result of some other action [I-D.ietf-mmusic-dtls-sdp], the state of the SCTP association is not affected. Holmberg, et al. Expires October 22, 2017 [Page 15] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 The offer follows the procedures in [I-D.ietf-mmusic-dtls-sdp] regarding the DTLS association impacts when modifying a session. In the case of TCP/DTLS/SCTP, the offerer follows the procedures in [RFC4145] regarding the TCP connection impacts when modifying a session. 11. Multihoming Considerations Multihoming is not supported when sending SCTP on top of DTLS, as DTLS does not expose address management of the underlying transport protocols (UDP or TCP) to its upper layer. 12. NAT Considerations 12.1. General When SCTP-over-DTLS is used in NAT environment, it relies on the NAT traversal procedures for the underlying transport protocol (UDP or TCP). 12.2. ICE Considerations When SCTP-over-DTLS is used with UDP based ICE candidates [RFC5245] then the procedures for UDP/DTLS/SCTP [Section 7] are used. When SCTP-over-DTLS is used with TCP based ICE candidates [RFC6544] then the procedures for TCP/DTLS/SCTP [Section 8] are used. In ICE environments, during the nomination process, endpoints go through multiple ICE candidate pairs, until the most preferred candidate pair is found. During the nomination process, data can be sent as soon as the first working candidate pair is found, but the nomination process still continues and selected candidate pairs can still change while data is sent. Furthermore, if endpoints roam between networks, for instance when mobile endpoint switches from mobile connection to WiFi, endpoints will initiate an ICE restart, which will trigger a new nomination process between the new set of candidates and likely result in the new nominated candidate pair. Implementations MUST treat all ICE candidate pairs associated with an SCTP association on top of a DTLS association as part of the same DTLS association. Thus, there will only be one SCTP handshake and one DTLS handshake even if there are multiple valid candidate pairs, and shifting from one candidate pair to another, including switching between UDP to TCP candidate pairs, will not impact the SCTP or DTLS associations. If new candidates are added, they will also be part of the same SCTP and DTLS associations. When transitioning between Holmberg, et al. Expires October 22, 2017 [Page 16] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 candidate pairs, different candidate pairs can be currently active in different directions and implementations MUST be ready to receive data on any of the candidates, even if this means sending and receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at the same time in different directions. In order to maximize the likelihood of interoperability between the endpoints, all ICE enabled SCTP-over-DTLS endpoints SHOULD implement support for UDP/DTLS/SCTP. When an SDP offer or answer is sent with multiple ICE candidates during initial connection negotiation or after ICE restart, UDP based candidates SHOULD be included and default candidate SHOULD be chosen from one of those UDP candidates. The proto value MUST match the transport protocol associated with the default candidate. If UDP transport is used for the default candidate, then 'UDP/DTLS/SCTP' proto value MUST be used. If TCP transport is used for the default candidate, then 'TCP/DTLS/SCTP' proto value MUST be used. Note that under normal circumstances the proto value for offers and answers sent during ICE nomination SHOULD be 'UDP/DTLS/SCTP'. When a subsequent SDP offer or answer is sent after ICE nomination is complete, and does not initiate ICE restart, it will contain only the nominated ICE candidate pair. In this case, the proto value MUST match the transport protocol associated with the nominated ICE candidate pair. If UDP transport is used for the nominated pair, then 'UDP/DTLS/SCTP' proto value MUST be used. If TCP transport is used for the nominated pair, then 'TCP/DTLS/SCTP' proto value MUST be used. Please note that if an endpoint switches between TCP-based and UDP-based candidates during the nomination process the endpoint is not required to send an SDP offer for the sole purpose of keeping the proto value of the associated m- line in sync. NOTE: The text in the paragraph above only applies when the usage of ICE has been negotiated. If ICE is not used, the proto value MUST always reflect the transport protocol used at any given time. 13. Examples 13.1. Establishment of UDP/DTLS/SCTP association Holmberg, et al. Expires October 22, 2017 [Page 17] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 SDP Offer: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:DB8::A8FD a=tls-id:abc3de65cddef001be82 a=setup:actpass a=sctp-port:5000 a=max-message-size:100000 - The offerer indicates that the usage of the UDP/DTLS/SCTP association will be as defined for the 'webrtc-datachannel' format value. - The offerer UDP port value is 54111. - The offerer SCTP port value is 5000. - The offerer indicates that it can take either the client or the server DTLS role. SDP Answer: m=application 64300 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:DB8::001D a=tls-id:dbc8de77cddef001be90 a=setup:passive a=sctp-port:6000 a=max-message-size:100000 - The answerer UDP port value is 64300. - The answerer SCTP port value is 6000. - The answerer takes the server DTLS role. 14. Security Considerations [RFC4566] defines general SDP security considerations, while [RFC3264], [RFC4145] and [RFC8122] define security considerations when using the SDP offer/answer mechanism to negotiate media streams. [RFC4960] defines general SCTP security considerations and [I-D.ietf-tsvwg-sctp-dtls-encaps] defines security considerations when using SCTP on top of DTLS. This specification does not introduce new security considerations in addition to those defined in the specifications listed above. Holmberg, et al. Expires October 22, 2017 [Page 18] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 15. IANA Considerations 15.1. New SDP proto values [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document updates the "Session Description Protocol (SDP) Parameters" registry, following the procedures in [RFC4566], by adding the following values to the table in the SDP "proto" field registry: +-------+---------------+-----------+ | Type | SDP Name | Reference | +-------+---------------+-----------+ | proto | UDP/DTLS/SCTP | [RFCXXXX] | | proto | TCP/DTLS/SCTP | [RFCXXXX] | +-------+---------------+-----------+ Table 1: SDP "proto" field values 15.2. New SDP Attributes 15.2.1. sctp-port This document defines a new SDP media-level attribute,'sctp-port'. The details of the attribute are defined in Section 5.2. 15.2.2. max-message-size This document defines a new SDP media-level attribute,'max-message- size'. The details of the attribute are defined in Section 6.2. 15.3. association-usage Name Registry [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This specification creates a new IANA registry, following the procedures in [RFC5226], for the namespace associated with the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol identifiers. Each fmt value describes the usage of an entire SCTP association, including all SCTP streams associated with the SCTP association. NOTE: Usage indication of individual SCTP streams is outside the scope of this specification. Holmberg, et al. Expires October 22, 2017 [Page 19] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 The fmt value, "association-usage", used with these "proto" values is required. It is defined in Section 4. As part of this registry, IANA maintains the following information: association-usage name: The identifier of the subprotocol, as will be used as the fmt value. association-usage reference: A reference to the document in which the association-usage is defined. association-usage names are to be subject to the "First Come First Served" IANA registration policy [RFC5226]. IANA is asked to add initial values to the registry. |----------------------------------------------------------| | name | Reference | |----------------------------------------------------------| | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx, | | | RFCXXX | |----------------------------------------------------------| [RFC EDITOR NOTE: Please hold the publication of this draft until draft-ietf-rtcweb-data-protocol has been published as an RFC. Then, replace the reference to draft-ietf-rtcweb-data-protocol with the RFC number.] [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] Figure 1 16. Acknowledgments The authors wish to thank Harald Alvestrand, Randell Jesup, Paul Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen and Ari Keranen for their comments and useful feedback. Ben Campbell provided comments as part of his AD review. Brian Carpenter performed the Gen-ART review. 17. [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sctp-sdp-25 Holmberg, et al. Expires October 22, 2017 [Page 20] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 o SDP 'dtls-id' attribute re-named to 'tls-id'. Changes from draft-ietf-mmusic-sctp-sdp-24 o Minor editorial fix by Roman. Changes from draft-ietf-mmusic-sctp-sdp-23 o Changes based on IESG review. o - Proto value clarifications. Changes from draft-ietf-mmusic-sctp-sdp-22 o Changes based on Gen-ART review by Brian Carpenter. Changes from draft-ietf-mmusic-sctp-sdp-21 o Changes based on AD review by Ben Campbell. Changes from draft-ietf-mmusic-sctp-sdp-20 o Informative reference to draft-ietf-rtcweb-data-protocol added. Changes from draft-ietf-mmusic-sctp-sdp-19 o Changes based on WG chair comments from Flemming Andreasen. Changes from draft-ietf-mmusic-sctp-sdp-18 o Changes based on WGLC comments from Paul Kyzivat. Changes from draft-ietf-mmusic-sctp-sdp-17 o Removal of 'SCTP'. o Document title changed. o Disallow usage of SDP 'setup' attribute 'holdconn' value. o Roman Shpount added as co-editor. Changes from draft-ietf-mmusic-sctp-sdp-15 o Chapter about SCTP, DTLS and TCP association/connection management modified. o Removal of SCTP/DTLS. Holmberg, et al. Expires October 22, 2017 [Page 21] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Changes from draft-ietf-mmusic-sctp-sdp-14 o Changes based on WGLC comments from Magnus Westerlund. o - ABNF clarification that token and port are defined in RFC4566. o - Specify 40 as maximum digit character length for the SDP max- message-size value. o - Editorial clarification. o Changes based on discussions at IETF#92. o - Specify that all ICE candidate pairs belong to the same DTLS association. Changes from draft-ietf-mmusic-sctp-sdp-13 o Changes based on comments from Paul Kyzivat. o - Text preventing usage of well-known ports removed. o - Editorial clarification. Changes from draft-ietf-mmusic-sctp-sdp-12 o Mux category rules added for new SDP attributes. o Reference to draft-ietf-mmusic-sdp-mux-attributes added. o Changes based on comments from Roman Shpount: o - Specify that fingerprint or setup roles must not be modified, unless underlying transport protocol is also modified. o Changes based on comments from Ari Keranen: o - Editorial corrections. o Changes based on comments from Flemming Andreasen: o - Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used, the DTLS association is established before the SCTP association. o - Clarify that max-message-size value is given in bytes, and that different values can be used per direction. o - Section on fmtp attribute removed. Holmberg, et al. Expires October 22, 2017 [Page 22] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 o - Editorial corrections. Changes from draft-ietf-mmusic-sctp-sdp-11 o Example added. Changes from draft-ietf-mmusic-sctp-sdp-10 o SDP max-message-size attribute added to IANA considerations. o Changes based on comments from Paul Kyzivat: o - Text about max message size removed from fmtp attribute section. Changes from draft-ietf-mmusic-sctp-sdp-09 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP transports added. Changes from draft-ietf-mmusic-sctp-sdp-08 o Default SCTP port removed: o - Usage of SDP sctp-port attribute mandatory. o SDP max-message-size attribute defined: o - Attribute definition. o - SDP Offer/Answer procedures. o Text about SDP direction attributes added. o Text about TLS role determination added. 18. References 18.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . Holmberg, et al. Expires October 22, 2017 [Page 23] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . Holmberg, et al. Expires October 22, 2017 [Page 24] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-24 (work in progress), April 2017. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-09 (work in progress), January 2015. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 2016. 18.2. Informative References [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., and J. Marcon, "SDP-based Data Channel Negotiation", draft-ietf-mmusic-data-channel-sdpneg-12 (work in progress), March 2017. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg, et al. Expires October 22, 2017 [Page 25] Internet-Draft SDP Offer/Answer For SCTP Over DTLS April 2017 Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Gonzalo.Camarillo@ericsson.com Holmberg, et al. Expires October 22, 2017 [Page 26] ./draft-ietf-mmusic-sdp-bundle-negotiation-54.txt0000644000764400076440000043254113405035207021237 0ustar iustyiusty MMUSIC Working Group C. Holmberg Internet-Draft Ericsson Updates: 3264,5888,7941 (if approved) H. Alvestrand Intended status: Standards Track Google Expires: June 18, 2019 C. Jennings Cisco December 15, 2018 Negotiating Media Multiplexing Using the Session Description Protocol (SDP) draft-ietf-mmusic-sdp-bundle-negotiation-54.txt Abstract This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification updates RFC 3264, to also allow assigning a zero port value to a "m=" section in cases where the media described by the "m=" section is not disabled or rejected. This specification updates RFC 5888, to also allow an SDP 'group' attribute to contain an identification-tag that identifies a "m=" section with the port set to zero. This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that can be used to correlate bundled RTP/RTCP packets with their appropriate "m=" section. This specification updates RFC 7941, by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Holmberg, et al. Expires June 18, 2019 [Page 1] Internet-Draft Bundled media December 2018 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 18, 2019. Copyright Notice Copyright (c) 2018 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 Holmberg, et al. Expires June 18, 2019 [Page 2] Internet-Draft Bundled media December 2018 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10 7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10 7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11 7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14 7.3.1. Answerer Selection of tagged 'm=' sections . . . . . 16 7.3.2. Moving A Media Description Out Of A BUNDLE Group . . 16 7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 17 7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 18 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24 9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description . . . . . . . . . . . . . . . . . . . . . . . 24 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 30 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 36 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 36 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888 . . . . . . . . . . . . . . . . . . . . . . . . . . 36 15. RTP/RTCP extensions for identification-tag transport . . . . 36 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 38 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 Holmberg, et al. Expires June 18, 2019 [Page 3] Internet-Draft Bundled media December 2018 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 39 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 40 17. Security Considerations . . . . . . . . . . . . . . . . . . . 40 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 18.1. Example: Tagged m= Section Selections . . . . . . . . . 41 18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 43 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 18.5. Example: Offerer Disables a Media Description Within a BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 21.1. Normative References . . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . 64 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 65 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 1. Introduction 1.1. Background When the SDP offer/answer mechanism [RFC3264] is used to negotiate the establishment of multimedia communication sessions, if separate transports (5-tuples) are negotiated for each individual media stream, each transport consumes additional resources (especially when Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is attractive to use a single transport for multiple media streams. 1.2. BUNDLE Mechanism This specification defines a way to use a single transport (BUNDLE transport) for sending and receiving media (bundled media) described by multiple SDP media descriptions ("m=" sections). The address:port combination used by an endpoint for sending and receiving bundled media is referred to as the BUNDLE address:port. The set of SDP attributes that are applied to each "m=" section within a BUNDLE group is referred to as BUNDLE attributes. The same BUNDLE transport Holmberg, et al. Expires June 18, 2019 [Page 4] Internet-Draft Bundled media December 2018 is used for sending and receiving bundled media, which means that the symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is always used for RTP-based bundled media. This specification defines a new SDP Grouping Framework [RFC5888] extension called 'BUNDLE'. The extension can be used with the Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate which "m=" sections will become part of a BUNDLE group. In addition, the offerer and answerer [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUNDLE address:port) and the set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that will be applied to each "m=" section within the BUNDLE group. The use of a BUNDLE transport allows the usage of a single set of Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. A given BUNDLE address:port MUST only be associated with a single BUNDLE group. If an SDP offer or answer contains multiple BUNDLE groups, the procedures in this specification apply to each group independently. All RTP-based bundled media associated with a given BUNDLE group belong to a single RTP session [RFC3550]. The BUNDLE extension is backward compatible. Endpoints that do not support the extension are expected to generate offers and answers without an SDP 'group:BUNDLE' attribute, and are expected to assign a unique address:port to each "m=" section within an offer and answer, according to the procedures in [RFC4566] and [RFC3264]. 1.3. Protocol Extensions In addition to defining the new SDP Grouping Framework extension, this specification defines the following protocol extensions and RFC updates: o The specification defines a new SDP attribute, 'bundle-only', which can be used to request that a specific "m=" section (and the associated media) is used only used if kept within a BUNDLE group. o The specification updates RFC 3264 [RFC3264], to also allow assigning a zero port value to a "m=" section in cases where the media described by the "m=" section is not disabled or rejected. o The specification defines a new RTP Control Protocol (RTCP) [RFC3550] source description (SDES) item, 'MID', and a new RTP SDES header extension that can be used to associate RTP streams with "m=" sections. Holmberg, et al. Expires June 18, 2019 [Page 5] Internet-Draft Bundled media December 2018 o The specification updates [RFC7941], by adding an exception, for the MID RTP header extension, to the requirement regarding protection of an SDES RTP header extension carrying an SDES item for the MID RTP header extension. 2. Terminology o "m=" section: SDP bodies contain one or more media descriptions, referred to as "m=" sections. Each "m=" section is represented by an SDP "m=" line, and zero or more SDP attributes associated with the "m=" line. A local address:port combination is assigned to each "m=" section. o 5-tuple: A collection of the following values: source address, source port, destination address, destination port, and transport- layer protocol. o Unique address:port: An address:port combination that is assigned to only one "m=" section in an offer or answer. o Offerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an offer. o Answerer BUNDLE-tag: The first identification-tag in a given SDP 'group:BUNDLE' attribute identification-tag list in an answer. o Suggested offerer tagged "m=" section: The bundled "m=" section identified by the offerer BUNDLE-tag in an initial BUNDLE offer, before a BUNDLE group has been negotiated. o Offerer tagged "m=" section: The bundled "m=" section identified by the offerer BUNDLE-tag in a subsequent offer. The "m=" section contains characteristics (offerer BUNDLE address:port and offerer BUNDLE attributes) applied to each "m=" section within the BUNDLE group. o Answerer tagged "m=" section: The bundled "m=" section identified by the answerer BUNDLE-tag in an answer (initial BUNDLE answer or subsequent). The "m=" section contains characteristics (answerer BUNDLE address:port and answerer BUNDLE attributes) applied to each "m=" section within the BUNDLE group. o BUNDLE address:port: An address:port combination that an endpoint uses for sending and receiving bundled media. o Offerer BUNDLE address:port: the address:port combination used by the offerer for sending and receiving media. Holmberg, et al. Expires June 18, 2019 [Page 6] Internet-Draft Bundled media December 2018 o Answerer BUNDLE address:port: the address:port combination used by the answerer for sending and receiving media. o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes. Once a BUNDLE group has been created, the attribute values apply to each bundled "m=" section within the BUNDLE group. o Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the offerer tagged "m=" section. o Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP attributes included in the answerer tagged "m=" section. o BUNDLE transport: The transport (5-tuple) used by all media described by the "m=" sections within a BUNDLE group. o BUNDLE group: A set of bundled "m=" sections, created using an SDP Offer/Answer exchange, which uses a single BUNDLE transport, and a single set of BUNDLE attributes, for sending and receiving all media (bundled media) described by the set of "m=" sections. The same BUNDLE transport is used for sending and receiving bundled media. o Bundled "m=" section: An "m=" section, whose identification-tag is placed in an SDP 'group:BUNDLE' attribute identification-tag list in an offer or answer. o Bundle-only "m=" section: A bundled "m=" section that contains an SDP 'bundle-only' attribute. o Bundled media: All media associated with a given BUNDLE group. o Initial BUNDLE offer: The first offer, within an SDP session (e.g. a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer indicates that it wants to negotiate a given BUNDLE group. o Initial BUNDLE answer: The answer to an initial BUNDLE offer in which the offerer indicates that it wants to negotiate a BUNDLE group, and where the answerer accepts the creation of the BUNDLE group. The BUNDLE group is created once the answerer sends the initial BUNDLE answer. o Subsequent offer: An offer which contains a BUNDLE group that has been created as part of a previous offer/answer exchange. Holmberg, et al. Expires June 18, 2019 [Page 7] Internet-Draft Bundled media December 2018 o Subsequent answer: An answer to a subsequent offer. o Identification-tag: A unique token value that is used to identify an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section carries the unique identification-tag assigned to that "m=" section. The session-level SDP 'group' attribute [RFC5888] carries a list of identification-tags, identifying the "m=" sections associated with that particular 'group' attribute. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Applicability Statement The mechanism in this specification only applies to the Session Description Protocol (SDP) [RFC4566], when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope of this document, and is thus undefined. 5. SDP Grouping Framework BUNDLE Extension This section defines a new SDP Grouping Framework [RFC5888] extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP Offer/Answer mechanism to negotiate a set of "m=" sections that will become part of a BUNDLE group. Within a BUNDLE group, each "m=" section uses a BUNDLE transport for sending and receiving bundled media. Each endpoint uses a single address:port combination for sending and receiving the bundled media. The BUNDLE extension is indicated using an SDP 'group' attribute with a semantics value [RFC5888] of "BUNDLE". An identification-tag is assigned to each bundled "m=" section, and each identification-tag is listed in the SDP 'group:BUNDLE' attribute identification-tag list. Each "m=" section whose identification-tag is listed in the identification-tag list is associated with a given BUNDLE group. SDP bodies can contain multiple BUNDLE groups. Any given bundled "m=" section MUST NOT be associated with more than one BUNDLE group at any given time. NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' attribute identification-tag list does not have to be the same as the order in which the "m=" sections occur in the SDP. Holmberg, et al. Expires June 18, 2019 [Page 8] Internet-Draft Bundled media December 2018 The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'group:BUNDLE' attribute is 'NORMAL'. Section 7 defines the detailed SDP Offer/Answer procedures for the BUNDLE extension. 6. SDP 'bundle-only' Attribute This section defines a new SDP media-level attribute [RFC4566], 'bundle-only'. 'bundle-only' is a property attribute [RFC4566], and hence has no value. In order to ensure that an answerer that does not support the BUNDLE extension always rejects a bundled "m=" section in an offer, the offerer can assign a zero port value to the "m=" section. According to [RFC3264] an answerer will reject such an "m=" section. By including an SDP 'bundle-only' attribute in a bundled "m=" section, the offerer can request that the answerer accepts the "m=" section only if the answerer supports the BUNDLE extension, and if the answerer keeps the "m=" section within the associated BUNDLE group. Name: bundle-only Value: N/A Usage Level: media Charset Dependent: no Example: a=bundle-only Once the offerer tagged "m=" section and the answerer tagged "m=" section have been selected, an offerer and answerer will include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section. The usage of the 'bundle-only' attribute is only defined for a bundled "m=" section with a zero port value. Other usage is unspecified. Section 7 defines the detailed SDP Offer/Answer procedures for the 'bundle-only' attribute. Holmberg, et al. Expires June 18, 2019 [Page 9] Internet-Draft Bundled media December 2018 7. SDP Offer/Answer Procedures This section describes the SDP Offer/Answer [RFC3264] procedures for: o Negotiating a BUNDLE group; and o Suggesting and selecting the tagged "m=" sections (offerer tagged "m=" section and answerer tagged "m=" section); and o Adding an "m=" section to a BUNDLE group; and o Moving an "m=" section out of a BUNDLE group; and o Disabling an "m=" section within a BUNDLE group. The generic rules and procedures defined in [RFC3264] and [RFC5888] also apply to the BUNDLE extension. For example, if an offer is rejected by the answerer, the previously negotiated addresses:ports, SDP parameters and characteristics (including those associated with a BUNDLE group) apply. Hence, if an offerer generates an offer in order to negotiate a BUNDLE group, and the answerer rejects the offer, the BUNDLE group is not created. The procedures in this section are independent of the media type or "m=" line proto value assigned to a bundled "m=" section. Section 9 defines additional considerations for RTP based media. Section 6 defines additional considerations for the usage of the SDP 'bundle- only' attribute. Section 10 defines additional considerations for the usage of Interactive Connectivity Establishment (ICE) [I-D.ietf-ice-rfc5245bis] mechanism. Offers and answers can contain multiple BUNDLE groups. The procedures in this section apply independently to a given BUNDLE group. 7.1. Generic SDP Considerations This section describes generic restrictions associated with the usage of SDP parameters within a BUNDLE group. It also describes how to calculate a value for the whole BUNDLE group, when parameter and attribute values have been assigned to each bundled "m=" section. 7.1.1. Connection Data (c=) The "c=" line nettype value [RFC4566] associated with a bundled "m=" section MUST be 'IN'. Holmberg, et al. Expires June 18, 2019 [Page 10] Internet-Draft Bundled media December 2018 The "c=" line addrtype value [RFC4566] associated with a bundled "m=" section MUST be 'IP4' or 'IP6'. The same value MUST be associated with each "m=" section. NOTE: Extensions to this specification can specify usage of the BUNDLE mechanism for other nettype and addrtype values than the ones listed above. 7.1.2. Bandwidth (b=) An offerer and answerer MUST use the rules and restrictions defined in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP bandwidth (b=) line with bundled "m=" sections. 7.1.3. Attributes (a=) An offerer and answerer MUST include SDP attributes in every bundled "m=" section where applicable, following the normal offer/answer procedures for each attribute, with the following exceptions: o In the initial BUNDLE offer, the offerer MUST NOT include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) in bundle-only "m=" sections. The offerer MUST include such attributes in all other bundled "m=" sections. In the initial BUNDLE offer each bundled "m=" line can contain a different set of BUNDLE attributes, and attribute values. Once the offerer tagged "m=" section has been selected, the BUNDLE attributes contained in the offerer tagged "m=" section will apply to each bundled "m=" section within the BUNDLE group. o In a subsequent offer, or in an answer (initial of subsequent), the offerer and answerer MUST include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) only in the tagged "m=" section (offerer tagged "m=" section or answerer tagged "m=" section). The offerer and answerer MUST NOT include such attributes in any other bundled "m=" section. The BUNDLE attributes contained in the tagged "m=" section will apply to each bundled "m=" section within the BUNDLE group. o In an offer (initial BUNDLE offer or subsequent), or in an answer (initial BUNDLE answer or subsequent), the offerer and answerer MUST include SDP attributes of other categories than IDENTICAL and TRANSPORT in each bundled "m=" section that a given attribute applies to. Each bundled "m=" line can contain a different set of such attributes, and attribute values, as such attributes only apply to the given bundled "m=" section in which they are included. Holmberg, et al. Expires June 18, 2019 [Page 11] Internet-Draft Bundled media December 2018 NOTE: A consequence of the rules above is that media-specific IDENTICAL and TRANSPORT multiplexing category SDP attributes which are applicable only to some of the bundled "m=" sections within the BUNDLE group might appear in the tagged "m=" section for which they are not applicable. For instance, the tagged "m=" section might contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section does not describe RTP-based media (but another bundled "m=" section within the BUNDLE group does describe RTP-based media). 7.2. Generating the Initial SDP Offer The procedures in this section apply to the first offer, within an SDP session (e.g. a SIP dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer indicates that it wants to negotiate a given BUNDLE group. This could occur in the initial offer, or in a subsequent offer, of the SDP session. When an offerer generates an initial BUNDLE offer, in order to negotiate a BUNDLE group, it MUST: o Assign a unique address:port to each bundled "m=" section, following the procedures in [RFC3264], excluding any bundle-only "m=" sections (see below); and o Pick a bundled "m=" section as the suggested offerer tagged "m=" section [Section 7.2.1]; and o Include SDP attributes in the bundled "m=" sections following the rules in [Section 7.1.3]; and o Include an SDP 'group:BUNDLE' attribute in the offer; and o Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the suggested offerer tagged "m=" section. NOTE: When the offerer assigns unique addresses:ports to multiple bundled "m=" sections, the offerer needs to be prepared to receive bundled media on each unique address:port, until it receives the associated answer and finds out which bundled "m=" section (and associated address:port combination) the answerer has selected as the offerer tagged "m=" section. If the offerer wants to request that the answerer accepts a given bundled "m=" section only if the answerer keeps the "m=" section within the negotiated BUNDLE group, the offerer MUST: Holmberg, et al. Expires June 18, 2019 [Page 12] Internet-Draft Bundled media December 2018 o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" section; and o Assign a zero port value to the "m=" section. NOTE: If the offerer assigns a zero port value to a bundled "m=" section, but does not include an SDP 'bundle-only' attribute in the "m=" section, it is an indication that the offerer wants to disable the "m=" section [Section 7.5.3]. [Section 7.2.2] and [Section 18.1] show an example of an initial BUNDLE offer. 7.2.1. Suggesting the Offerer tagged 'm=' section In the initial BUNDLE offer, the bundled "m=" section indicated by the offerer BUNDLE-tag is the suggested offerer tagged "m=" section. The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled media if the answerer selects the "m=" section as the offerer tagged "m=" section [Section 7.3.1]. In addition, if the answerer selects the "m=" section as the offerer tagged "m=" section, the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group. The offerer MUST NOT suggest a bundle-only "m=" section as the offerer tagged "m=" section. It is RECOMMENDED that the suggested offerer tagged "m=" section is a bundled "m=" section that the offerer believes it is unlikely that the answerer will reject, or move out of the BUNDLE group. How such assumption is made is outside the scope of this document. 7.2.2. Example: Initial SDP Offer The example shows an initial BUNDLE offer. The offer includes two "m=" sections in the offer, and suggests that both "m=" sections are included in a BUNDLE group. The audio "m=" section is the suggested offerer tagged "m=" section, indicated by placing the identification- tag associated with the "m=" section (offerer BUNDLE-tag) first in the SDP group:BUNDLE attribute identification-id list. Holmberg, et al. Expires June 18, 2019 [Page 13] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 7.3. Generating the SDP Answer When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group the following general SDP grouping framework restrictions, defined in [RFC5888], also apply to the BUNDLE group: o The answerer is only allowed to include a BUNDLE group in an initial BUNDLE answer if the offerer requested the BUNDLE group to be created in the corresponding initial BUNDLE offer; and o The answerer is only allowed to include a BUNDLE group in a subsequent answer if the corresponding subsequent offer contains a previously negotiated BUNDLE group; and o The answerer is only allowed to include a bundled "m=" section in an answer if the "m=" section was indicated as bundled in the corresponding offer; and Holmberg, et al. Expires June 18, 2019 [Page 14] Internet-Draft Bundled media December 2018 o The answerer is only allowed to include a bundled "m=" section in the same BUNDLE group as the bundled "m=" line in the corresponding offer. In addition, when an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, the answerer MUST: o In case of an initial BUNDLE answer, select the offerer tagged "m=" section using the procedures in Section 7.3.1. In case of a subsequent answer, the offerer tagged "m=" section is indicated in the corresponding subsequent offer, and MUST NOT be changed by the answerer; and o Select the answerer tagged "m=" section [Section 7.3.1]; and o Assign the answerer BUNDLE address:port to the answerer tagged "m=" section; and o Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section within the BUNDLE group; and o Include SDP attributes in the bundled "m=" sections following the rules in [Section 7.1.3]; and o Include an SDP 'group:BUNDLE' attribute in the answer; and o Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag indicates the answerer tagged "m=" section [Section 7.3.1]. If the answerer does not want to keep an "m=" section within a BUNDLE group, it MUST: o Move the "m=" section out of the BUNDLE group [Section 7.3.2]; or o Reject the "m=" section [Section 7.3.3]. The answerer can modify the answerer BUNDLE address:port, add and remove SDP attributes, or modify SDP attribute values, in a subsequent answer. Changes to the answerer BUNDLE address:port and the answerer BUNDLE attributes will be applied to each bundled "m=" section within the BUNDLE group. NOTE: If a bundled "m=" section in an offer contains a zero port value, but the "m=" section does not contain an SDP 'bundle-only' Holmberg, et al. Expires June 18, 2019 [Page 15] Internet-Draft Bundled media December 2018 attribute, it is an indication that the offerer wants to disable the "m=" section [Section 7.5.3]. 7.3.1. Answerer Selection of tagged 'm=' sections When the answerer selects the offerer tagged "m=" section, it first checks the suggested offerer tagged "m=" section [Section 7.2.1]. The answerer MUST check whether the "m=" section fulfils the following criteria: o The answerer will not move the "m=" section out of the BUNDLE group [Section 7.3.2]; and o The answerer will not reject the "m=" section [Section 7.3.3]; and o The "m=" section does not contain a zero port value. If all of the criteria above are fulfilled, the answerer MUST select the "m=" section as the offerer tagged "m=" section, and MUST also mark the corresponding "m=" section in the answer as the answerer tagged "m=" section. In the answer the answerer BUNDLE-tag indicates the answerer tagged "m=" section. If one or more of the criteria are not fulfilled, the answerer MUST pick the next identification-tag in the identification-tag list in the offer, and perform the same criteria check for the "m=" section indicated by that identification-tag. If there are no more identification-tags in the identification-tag list, the answerer MUST NOT create the BUNDLE group. Unless the answerer rejects the whole offer, the answerer MUST apply the answerer procedures for moving an "m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an "m=" section within a BUNDLE group [Section 7.3.3] to every bundled "m=" section in the offer when creating the answer. [Section 18.1] shows an example of an offerer BUNDLE address:port selection. [Section 7.3.4] and [Section 18.1] show an example of an answerer tagged "m=" section selection. 7.3.2. Moving A Media Description Out Of A BUNDLE Group When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of the negotiated BUNDLE group, the answerer MUST first check the following criteria: o In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group; and Holmberg, et al. Expires June 18, 2019 [Page 16] Internet-Draft Bundled media December 2018 o In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute. If either criterium above is fulfilled the answerer can not move the "m=" section out of the BUNDLE group in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group [Section 7.3.3], or keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section can not be moved out of the BUNDLE group in an answer. Instead an offer is needed. When the answerer generates an answer, in which it moves a bundled "m=" section out of a BUNDLE group, the answerer: o MUST assign a unique address:port to the "m=" section; and o MUST include any applicable SDP attribute in the "m=" section, using the normal offer/answer procedures for the each Attributes; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group. o MUST NOT include an SDP 'bundle-only' attribute to the "m=" section; and Because an answerer is not allowed to move an "m=" section from one BUNDLE group to another within an answer [Section 7.3], if the answerer wants to move an "m=" section from one BUNDLE group to another it MUST first move the "m=" section out of the current BUNDLE group, and then generate an offer where the "m=" section is added to another BUNDLE group [Section 7.5.1]. 7.3.3. Rejecting a Media Description in a BUNDLE Group When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check the following criterion: o In the corresponding offer, the "m=" section is the offerer tagged "m=" section. If the criterium above is fulfilled the answerer can not reject the "m=" section in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or Holmberg, et al. Expires June 18, 2019 [Page 17] Internet-Draft Bundled media December 2018 keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is disabled within the BUNDLE group [Section 7.5.3]. When an answerer generates an answer, in which it rejects a bundled "m=" section, the answerer: o MUST assign a zero port value to the "m=" section, according to the procedures in [RFC3264]; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and o MUST NOT include an SDP 'bundle-only' attribute in the "m=" section. 7.3.4. Example: SDP Answer The example below shows an answer, based on the corresponding offer in [Section 7.2.2]. The answerer accepts both bundled "m=" sections within the created BUNDLE group. The audio "m=" section is the answerer tagged "m=" section, indicated by placing the identification-tag associated with the "m=" section (answerer BUNDLE- tag) first in the SDP group;BUNDLE attribute identification-id list. The answerer includes an SDP 'bundle-only' attribute in, and assigns a zero port value to, the video "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 18] Internet-Draft Bundled media December 2018 SDP Answer v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 7.4. Offerer Processing of the SDP Answer When an offerer receives an answer, if the answer contains a BUNDLE group, the offerer MUST check that any bundled "m=" section in the answer was indicated as bundled in the corresponding offer. If there is no mismatch, the offerer MUST apply the properties (BUNDLE address:port, BUNDLE attributes etc) of the offerer tagged "m=" section (selected by the answerer [Section 7.3.1]) to each bundled "m=" section within the BUNDLE group. NOTE: As the answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer, or move a bundled "m=" section out of a BUNDLE group, a given bundled "m=" section in the offer might not be indicated as bundled in the corresponding answer. If the answer does not contain a BUNDLE group, the offerer MUST process the answer as a normal answer. 7.5. Modifying the Session When a BUNDLE group has previously been negotiated, and an offerer generates a subsequent offer, the offerer MUST: Holmberg, et al. Expires June 18, 2019 [Page 19] Internet-Draft Bundled media December 2018 o Pick one bundled "m=" section as the offerer tagged "m=" section. The offerer can either pick the "m=" section that was previously selected by the answerer as the offerer tagged "m=" section, or pick another bundled "m=" section within the BUNDLE group; and o Assign a BUNDLE address:port (previously negotiated or newly suggest) to the offerer tagged "m=" section; and o Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every other bundled "m=" section within the BUNDLE group; and o Include SDP attributes in the bundled "m=" sections following the rules in [Section 7.1.3]; and o Include an SDP 'group:BUNDLE' attribute in the offer; and o Place the identification-tag of each bundled "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag indicates the offerer tagged "m=" section. The offerer MUST NOT pick a given bundled "m=" section as the offerer tagged "m=" section if: o The offerer wants to move the "m=" section out of the BUNDLE group [Section 7.5.2]; or o The offerer wants to disable the "m=" section [Section 7.5.3]. The offerer can modify the offerer BUNDLE address:port, add and remove SDP attributes, or modify SDP attribute values, in the subsequent offer. Changes to the offerer BUNDLE address:port and the offerer BUNDLE attributes will (if the offer is accepted by the answerer) be applied to each bundled "m=" section within the BUNDLE group. 7.5.1. Adding a Media Description to a BUNDLE group When an offerer generates a subsequent offer, in which it wants to add a bundled "m=" section to a previously negotiated BUNDLE group, the offerer follows the procedures in Section 7.5. The offerer either picks the added "m=" section, or an "m=" section previously added to the BUNDLE group, as the offerer tagged "m=" section. NOTE: As described in Section 7.3.2, the answerer can not move the added "m=" section out of the BUNDLE group in its answer. If the answer wants to move the "m=" section out of the BUNDLE group, it will have to first accept it into the BUNDLE group in the answer, and Holmberg, et al. Expires June 18, 2019 [Page 20] Internet-Draft Bundled media December 2018 then send a subsequent offer where the "m=" section is moved out of the BUNDLE group [Section 7.5.2]. 7.5.2. Moving a Media Description Out of a BUNDLE Group When an offerer generates a subsequent offer, in which it want to remove a bundled "m=" section from a BUNDLE group, the offerer: o MUST assign a unique address:port to the "m=" section; and o MUST include SDP attributes in the "m=" section following the normal offer/answer rules for each attribute; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" section. For the other bundled "m=" sections within the BUNDLE group, the offerer follows the procedures in [Section 7.5]. An offerer MUST NOT move an "m=" section from one BUNDLE group to another within a single offer. If the offerer wants to move an "m=" section from one BUNDLE group to another it MUST first move the BUNDLE group out of the current BUNDLE group, and then generate a second offer where the "m=" section is added to another BUNDLE group [Section 7.5.1]. [Section 18.4] shows an example of an offer for moving an "m=" section out of a BUNDLE group. 7.5.3. Disabling a Media Description in a BUNDLE Group When an offerer generates a subsequent offer, in which it want to disable a bundled "m=" section from a BUNDLE group, the offerer: o MUST assign a zero port value to the "m=" section, following the procedures in [RFC4566]; and o MUST NOT place the identification-tag associated with the "m=" section in the SDP 'group:BUNDLE' attribute identification-tag list associated with the BUNDLE group; and o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 21] Internet-Draft Bundled media December 2018 For the other bundled "m=" sections within the BUNDLE group, the offerer follows the procedures in [Section 7.5]. [Section 18.5] shows an example of an offer and answer for disabling an "m=" section within a BUNDLE group. 8. Protocol Identification Each "m=" section within a BUNDLE group MUST use the same transport- layer protocol. If bundled "m=" sections use different upper-layer protocols on top of the transport-layer protocol, there MUST exist a publicly available specification which describes a mechanism how to associate received data with the correct protocol for this particular protocol combination. In addition, if received data can be associated with more than one bundled "m=" section, there MUST exist a publicly available specification which describes a mechanism for associating the received data with the correct "m=" section. This document describes a mechanism to identify the protocol of received data among the STUN, DTLS and SRTP protocols (in any combination), when UDP is used as transport-layer protocol, but it does not describe how to identify different protocols transported on DTLS. While the mechanism is generally applicable to other protocols and transport-layer protocols, any such use requires further specification around how to multiplex multiple protocols on a given transport-layer protocol, and how to associate received data with the correct protocols. 8.1. STUN, DTLS, SRTP Section 5.1.2 of [RFC5764] describes a mechanism to identify the protocol of a received packet among the STUN, DTLS and SRTP protocols (in any combination). If an offer or answer includes a bundled "m=" section that represents these protocols, the offerer or answerer MUST support the mechanism described in [RFC5764], and no explicit negotiation is required in order to indicate support and usage of the mechanism. [RFC5764] does not describe how to identify different protocols transported on DTLS, only how to identify the DTLS protocol itself. If multiple protocols are transported on DTLS, there MUST exist a specification describing a mechanism for identifying each individual protocol. In addition, if a received DTLS packet can be associated with more than one "m=" section, there MUST exist a specification which describes a mechanism for associating the received DTLS packets with the correct "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 22] Internet-Draft Bundled media December 2018 [Section 9.2] describes how to associate the packets in a received SRTP stream with the correct "m=" section. 9. RTP Considerations 9.1. Single RTP Session All RTP-based media within a single BUNDLE group belong to a single RTP session [RFC3550]. Since a single BUNDLE transport is used for sending and receiving bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for RTP-based bundled media. Since a single RTP session is used for each BUNDLE group, all "m=" sections representing RTP-based media within a BUNDLE group will share a single SSRC numbering space [RFC3550]. The following rules and restrictions apply for a single RTP session: o A specific payload type value can be used in multiple bundled "m=" sections only if each codec associated with the payload type number shares an identical codec configuration [Section 9.1.1]. o The proto value in each bundled RTP-based "m=" section MUST be identical (e.g., RTP/AVPF). o The RTP MID header extension MUST be enabled, by including an SDP 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section in every offer and answer. o A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled "m=" sections. NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC. If transmission of multiple media types are done with time overlap, RTP and RTCP fail to function. Even if done in proper sequence this causes RTP Timestamp rate switching issues [RFC7160]. However, once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC can be reused by another source (possibly associated with a different bundled "m=" section) after a delay of 5 RTCP reporting intervals (the delay is to ensure the SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). Holmberg, et al. Expires June 18, 2019 [Page 23] Internet-Draft Bundled media December 2018 [RFC7657] defines Differentiated Services (Diffserv) considerations for RTP-based bundled media sent using a mixture of Diffserv Codepoints. 9.1.1. Payload Type (PT) Value Reuse Multiple bundled "m=" sections might describe RTP based media. As all RTP based media associated with a BUNDLE group belong to the same RTP session, in order for a given payload type value to be used inside more than one bundled "m=" section, all codecs associated with the payload type number MUST share an identical codec configuration. This means that the codecs MUST share the same media type, encoding name, clock rate and any parameter that can affect the codec configuration and packetization. [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose attribute values are required to be identical for all codecs that use the same payload type value. 9.2. Associating RTP/RTCP Streams with the Correct SDP Media Description As described in [RFC3550], RTP packets are associated with RTP streams [RFC7656]. Each RTP stream is identified by an SSRC value, and each RTP packet includes an SSRC field that is used to associate the packet with the correct RTP stream. RTCP packets also use SSRCs to identify which RTP streams the packet relates to. However, a RTCP packet can contain multiple SSRC fields, in the course of providing feedback or reports on different RTP streams, and therefore can be associated with multiple such streams. In order to be able to process received RTP/RTCP packets correctly, it MUST be possible to associate an RTP stream with the correct "m=" section, as the "m=" section and SDP attributes associated with the "m=" section contains information needed to process the packets. As all RTP streams associated with a BUNDLE group use the same transport for sending and receiving RTP/RTCP packets, the local address:port combination part of the transport cannot be used to associate an RTP stream with the correct "m=" section. In addition, multiple RTP streams might be associated with the same "m=" section. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute [RFC5576]. However, an offerer will not know which SSRC values the answerer will use until the offerer has received the answer providing that information. Due to this, before the offerer has received the answer, the offerer will not be able to associate an RTP stream with the correct "m=" section using the SSRC value associated with the RTP Holmberg, et al. Expires June 18, 2019 [Page 24] Internet-Draft Bundled media December 2018 stream. In addition, the offerer and answerer may start using new SSRC values mid-session, without informing each other using the SDP 'ssrc' attribute. In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" section, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 15, where the offerer and answerer insert the identification- tag associated with an "m=" section (provided by the remote peer) into RTP and RTCP packets associated with a BUNDLE group. When using this mechanism, the mapping from an SSRC to an identification-tag is carried in RTP header extensions or RTCP SDES packets, as specified in Section 15. Since a compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, a single RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables used for routing that are updated each time an RTP/ RTCP packet contains new information that affects how packets are to be routed. However, some legacy implementations may not include this identification-tag in their RTP and RTCP traffic when using the BUNDLE mechanism, and instead use a payload type based mechanism to associate RTP streams with SDP "m=" sections. In this situation, each "m=" section needs to use unique payload type values, in order for the payload type to be a reliable indicator of the relevant "m=" section for the RTP stream. If an implementation fails to ensure unique payload type values it will be impossible to associate the RTP stream using that payload type value to a particular "m=" section. Note that when using the payload type to associate RTP streams with "m=" sections an RTP stream, identified by its SSRC, will be mapped to an "m=" section when the first packet of that RTP stream is received, and the mapping will not be changed even if the payload type used by that RTP stream changes. In other words, the SSRC cannot "move" to a different "m=" section simply by changing the payload type. Applications can implement RTP stacks in many different ways. The algorithm below details one way that RTP streams can be associated with "m=" sections, but is not meant to be prescriptive about exactly how an RTP stack needs to be implemented. Applications MAY use any algorithm that achieves equivalent results to those described in the algorithm below. To prepare to associate RTP streams with the correct "m=" section, the following steps MUST be followed for each BUNDLE group: Holmberg, et al. Expires June 18, 2019 [Page 25] Internet-Draft Bundled media December 2018 Construct a table mapping MID to "m=" section for each "m=" section in this BUNDLE group. Note that an "m=" section may only have one MID. Construct a table mapping SSRCs of incoming RTP streams to "m=" section for each "m=" section in this BUNDLE group and for each SSRC configured for receiving in that "m=" section. Construct a table mapping the SSRC of each outgoing RTP stream to "m=" section for each "m=" section in this BUNDLE group and for each SSRC configured for sending in that "m=" section. Construct a table mapping payload type to "m=" section for each "m=" section in the BUNDLE group and for each payload type configured for receiving in that "m=" section. If any payload type is configured for receiving in more than one "m=" section in the BUNDLE group, do not include it in the table, as it cannot be used to uniquely identify an "m=" section. Note that for each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps. As "m=" sections are added or removed from the BUNDLE groups, or their configurations are changed, the tables above MUST also be updated. When an RTP packet is received, it MUST be delivered to the RTP stream corresponding to its SSRC. That RTP stream MUST then be associated with the correct "m=" section within a BUNDLE group, for additional processing, according to the following steps: If the MID associated with the RTP stream is not in the table mapping MID to "m=" section, then the RTP stream is not decoded and the payload data is discarded. If the packet has a MID, and the packet's extended sequence number is greater than that of the last MID update, as discussed in [RFC7941], Section 4.2.6, update the MID associated with the RTP stream to match the MID carried in the RTP packet, then update the mapping tables to include an entry that maps the SSRC of that RTP stream to the "m=" section for that MID. If the SSRC of the RTP stream is in the incoming SSRC mapping table, check that the payload type used by the RTP stream matches a payload type included on the matching "m=" section. If so, associate the RTP stream with that "m=" section. Otherwise, the RTP stream is not decoded and the payload data is discarded. Holmberg, et al. Expires June 18, 2019 [Page 26] Internet-Draft Bundled media December 2018 If the payload type used by the RTP stream is in the payload type table, update the incoming SSRC mapping table to include an entry that maps the RTP stream's SSRC to the "m=" section for that payload type. Associate the RTP stream with the corresponding "m=" section. Otherwise, mark the RTP stream as not for decoding and discard the payload. If the RTP packet contains one or more contributing source (CSRC) identifiers, then each CSRC is looked up in the incoming SSRC table and a copy of the RTP packet is associated with the corresponding "m=" section for additional processing. For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the packet is processed as usual by the RTP layer, then associated with the appropriate "m=" sections, and processed for the RTP streams represented by those "m=" sections. This routing is type-dependent, as each kind of RTCP packet has its own mechanism for associating it with the relevant RTP streams. RTCP packets that cannot be associated with an appropriate "m=" section MUST still be processed as usual by the RTP layer, updating the metadata associated with the corresponding RTP streams. This situation can occur with certain multiparty RTP topologies, or when RTCP packets are sent containing a subset of the SDES information. Additional rules for processing various types of RTCP packets are explained below. If the RTCP packet is of type SDES, for each chunk in the packet whose SSRC is found in the incoming SSRC table, deliver a copy of the SDES packet to the "m=" section associated with that SSRC. In addition, for any SDES MID items contained in these chunks, if the MID is found in the table mapping MID to "m=" section, update the incoming SSRC table to include an entry that maps the RTP stream associated with the chunk's SSRC to the "m=" section associated with that MID, unless the packet is older than the packet that most recently updated the mapping for this SSRC, as discussed in [RFC7941], Section 4.2.6. Note that if an SDES packet is received as part of a compound RTCP packet, the SSRC to "m=" section mapping might not exist until the SDES packet is handled (e.g., in the case where RTCP for a source is received before any RTP packets). Therefore, it can be beneficial for an implementation to delay RTCP packet routing, such that it either prioritizes processing of the SDES item to generate or update the mapping, or buffers the RTCP information Holmberg, et al. Expires June 18, 2019 [Page 27] Internet-Draft Bundled media December 2018 that needs to be routed until the SDES item(s) has been processed. If the implementation is unable to follow this recommendation, the consequence could be that some RTCP information from this particular RTCP compound packet is not provided to higher layers. The impact from this is likely minor, when this information relates to a future incoming RTP stream. If the RTCP packet is of type BYE, it indicates that the RTP streams referenced in the packet are ending. Therefore, for each SSRC indicated in the packet that is found in the incoming SSRC table, first deliver a copy of the BYE packet to the "m=" section associated with that SSRC, then remove the entry for that SSRC from the incoming SSRC table after an appropriate delay to account for "straggler packets", as specified in [RFC3550], Section 6.2.1. If the RTCP packet is of type SR or RR, for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the SR or RR packet to the "m=" section associated with that SSRC. In addition, if the packet is of type SR, and the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the SR packet to the "m=" section associated with that SSRC. If the implementation supports RTCP XR and the packet is of type XR, as defined in [RFC3611], for each report block in the report whose "SSRC of source" is found in the outgoing SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC. In addition, if the sender SSRC for the packet is found in the incoming SSRC table, deliver a copy of the XR packet to the "m=" section associated with that SSRC. If the RTCP packet is a feedback message of type RTPFB or PSFB, as defined in [RFC4585], it will contain a media source SSRC, and this SSRC is used for routing certain subtypes of feedback messages. However, several subtypes of PSFB and RTPFB messages include target SSRC(s) in a section called Feedback Control Information (FCI). For these messages, the target SSRC(s) are used for routing. If the RTCP packet is a feedback packet that does not include target SSRCs in its FCI section, and the media source SSRC is found in the outgoing SSRC table, deliver the feedback packet to the "m=" section associated with that SSRC. RTPFB and PSFB types that are handled in this way include: Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). Holmberg, et al. Expires June 18, 2019 [Page 28] Internet-Draft Bundled media December 2018 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). Reference Picture Selection Indication (RPSI): [RFC4585] (PT=PSFB, FMT=3). If the RTCP packet is a feedback message that does include target SSRC(s) in its FCI section, it can either be a request or a notification. Requests reference a RTP stream that is being sent by the message recipient, whereas notifications are responses to an earlier request, and therefore reference a RTP stream that is being received by the message recipient. If the RTCP packet is a feedback request that includes target SSRC(s), for each target SSRC that is found in the outgoing SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with that SSRC. PSFB and RTPFB types that are handled in this way include: Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, FMT=5). H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, FMT=7). Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] (PT=RTPFB, FMT=3). Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, FMT=10). If the RTCP packet is a feedback notification that includes target SSRC(s), for each target SSRC that is found in the incoming SSRC table, deliver a copy of the RTCP packet to the "m=" section associated with the RTP stream with matching SSRC. PSFB and RTPFB types that are handled in this way include: Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] (PT=PSFB, FMT=6). This message is a notification in response to a prior TSTR. Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] (PT=RTPFB, FMT=4). This message is a notification in response to a prior TMMBR, but can also be sent unsolicited. Holmberg, et al. Expires June 18, 2019 [Page 29] Internet-Draft Bundled media December 2018 If the RTCP packet is of type APP, then it is handled in an application specific manner. If the application does not recognise the APP packet, then it MUST be discarded. 9.3. RTP/RTCP Multiplexing Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP multiplexing [RFC5761] for the RTP-based bundled media (i.e., the same transport will be used for both RTP packets and RTCP packets). In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- only' attribute [I-D.ietf-mmusic-mux-exclusive]. 9.3.1. SDP Offer/Answer Procedures This section describes how an offerer and answerer use the SDP 'rtcp- mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. RTP/RTCP multiplexing only applies to RTP-based media. However, as described in Section 7.1.3, within an offer or answer the SDP 'rtcp- mux' and SDP 'rtcp-mux-only' attributes might be included in a bundled "m=" section for non-RTP-based media (if such "m=" section is the offerer tagged "m=" section or answerer tagged "m=" section). 9.3.1.1. Generating the Initial SDP BUNDLE Offer When an offerer generates an initial BUNDLE offer, if the offer contains one or more bundled "m=" sections for RTP-based media (or, if there is a chance that "m=" sections for RTP-based media will later be added to the BUNDLE group), the offerer MUST include an SDP 'rtcp-mux' attribute [RFC5761] in each bundled "m=" section (excluding any bundle-only "m=" sections). In addition, the offerer MAY include an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in one or more bundled "m=" sections for RTP-based media. NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute depends on whether the offerer supports fallback to usage of a separate port for RTCP in case the answerer moves one or more "m=" sections for RTP-based media out of the BUNDLE group in the answer. NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' attribute, the offerer can also include an SDP 'rtcp' attribute [RFC3605] in one or more RTP-based bundled "m=" sections in order to provide a fallback port for RTCP, as described in [RFC5761]. However, the fallback port will only be applied to "m=" sections for Holmberg, et al. Expires June 18, 2019 [Page 30] Internet-Draft Bundled media December 2018 RTP-based media that are moved out of the BUNDLE group by the answerer. In the initial BUNDLE offer, the address:port combination for RTCP MUST be unique in each bundled "m=" section for RTP-based media (excluding a bundle-only "m=" section), similar to RTP. 9.3.1.2. Generating the SDP Answer When an answerer generates an answer, if the answerer supports RTP- based media, and if a bundled "m=" section in the corresponding offer contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP multiplexing, even if there currently are no bundled "m=" sections for RTP-based media within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" section, following the procedures for BUNDLE attributes [Section 7.1.3]. In addition, if the "m=" section that is selected as the offerer tagged "m=" section contained an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute in the answerer tagged "m=" section. In an initial BUNDLE offer, if the suggested offerer tagged "m=" section contained an SDP 'rtcp-mux-only' attribute, the "m=" section was for RTP-based media, and the answerer does not accept the "m=" section in the created BUNDLE group, the answerer MUST either move the "m=" section out of the BUNDLE group [Section 7.3.2], include the attribute in the moved "m=" section and enable RTP/RTCP multiplexing for the media associated with the "m=" section, or reject the "m=" section [Section 7.3.3]. The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled "m=" section in the answer. The answerer will use the port value of the tagged offerer "m=" section sending RTP and RTCP packets associated with RTP-based bundled media towards the offerer. If the usage of RTP/RTCP multiplexing within a BUNDLE group has been negotiated in a previous offer/answer exchange, the answerer MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m=" section . It is not possible to disable RTP/RTCP multiplexing within a BUNDLE group. 9.3.1.3. Offerer Processing of the SDP Answer When an offerer receives an answer, if the answerer has accepted the usage of RTP/RTCP multiplexing [Section 9.3.1.2], the answerer follows the procedures for RTP/RTCP multiplexing defined in [RFC5761]. The offerer will use the port value of the answerer Holmberg, et al. Expires June 18, 2019 [Page 31] Internet-Draft Bundled media December 2018 tagged "m=" section for sending RTP and RTCP packets associated with RTP-based bundled media towards the answerer. NOTE: It is considered a protocol error if the answerer has not accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" sections that the answerer included in the BUNDLE group. 9.3.1.4. Modifying the Session When an offerer generates a subsequent offer, the offerer MUST include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" section, following the procedures for IDENTICAL multiplexing category attributes in Section 7.1.3. 10. ICE Considerations This section describes how to use the BUNDLE grouping extension together with the Interactive Connectivity Establishment (ICE) mechanism [I-D.ietf-ice-rfc5245bis]. The generic procedures for negotiating usage of ICE using SDP, defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE with BUNDLE, with the following exceptions: o When the BUNDLE transport has been established, ICE connectivity checks and keep-alives only need to be performed for the BUNDLE transport, instead of per individual bundled "m=" section within the BUNDLE group. o The generic SDP attribute offer/answer considerations [Section 7.1.3] also apply to ICE-related attributes. Therefore, when an offer sends an initial BUNDLE offer (in order to negotiate a BUNDLE group) the offerer include ICE-related media-level attributes in each bundled "m=" section (excluding any bundle-only "m=" section), and each "m=" section MUST contain unique ICE properties. When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, and when an offerer sends a subsequent offer that contains a BUNDLE group, ICE-related media-level attributes are only included in the tagged "m=" section (suggested offerer tagged "m=" section or answerer tagged "m=" section), and the ICE properties are applied to each bundled "m=" section within the BUNDLE group. NOTE: Most ICE-related media-level SDP attributes belong to the TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes], and the generic SDP attribute offer/answer considerations for TRANSPORT multiplexing category apply to the attributes. However, in the case of ICE-related attributes, the same considerations also Holmberg, et al. Expires June 18, 2019 [Page 32] Internet-Draft Bundled media December 2018 apply to ICE-related media-level attributes that belong to other multiplexing categories. NOTE: The following ICE-related media-level SDP attributes are defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- pacing'. Initially, before ICE has produced selected candidate pairs that will be used for media, there might be multiple transports established (if multiple candidate pairs are tested). Once ICE has selected candidate pairs, they form the BUNDLE transport. Support and usage of ICE mechanism together with the BUNDLE extension is OPTIONAL, and the procedures in this section only apply when the ICE mechanism is used. Note that applications might mandate usage of the ICE mechanism even if the BUNDLE extension is not used. NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] is used, an offerer and answerer might assign a port value of '9', and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" sections in the initial BUNDLE offer. The offerer and answerer will follow the normal procedures for generating the offers and answers, including picking a bundled "m=" section as the suggested offerer tagged "m=" section, selecting the tagged "m=" sections etc. The only difference is that media can not be sent until one or more candidates have been provided. Once a BUNDLE group has been negotiated, trickled candidates associated with a bundled "m=" section will be applied to all bundled "m=" sections within the BUNDLE group. 11. DTLS Considerations One or more media streams within a BUNDLE group might use the Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order to encrypt the data, or to negotiate encryption keys if another encryption mechanism is used to encrypt media. When DTLS is used within a BUNDLE group, the following rules apply: o There can only be one DTLS association [RFC6347] associated with the BUNDLE group; and o Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for determining which endpoints (the offerer or answerer) become DTLS client and DTLS server; and Holmberg, et al. Expires June 18, 2019 [Page 33] Internet-Draft Bundled media December 2018 o Each usage of the DTLS association within the BUNDLE group MUST use the same mechanism for determining whether an offer or answer will trigger the establishment of a new DTLS association, or whether an existing DTLS association will be used; and o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message [RFC5764]. The client MUST include the extension even if the usage of DTLS-SRTP is not negotiated as part of the multimedia session (e.g., SIP session [RFC3261]). NOTE: The inclusion of the 'use_srtp' extension during the initial DTLS handshake ensures that a DTLS renegotiation will not be required in order to include the extension, in case DTLS-SRTP encrypted media is added to the BUNDLE group later during the multimedia session. 12. RTP Header Extensions Consideration When [RFC8285] RTP header extensions are used in the context of this specification, the identifier used for a given extension MUST identify the same extension across all the bundled media descriptions. 13. Update to RFC 3264 This section updates RFC 3264, in order to allow extensions to define the usage of a zero port value in offers and answers for other purposes than removing or disabling media streams. The following sections of RFC 3264 are updated: o Section 5.1 (Unicast Streams). o Section 8.4 (Putting a Unicast Media Stream on Hold). 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream Holmberg, et al. Expires June 18, 2019 [Page 34] Internet-Draft Bundled media December 2018 (Section 6). Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero indicates that the media stream is not wanted. 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer by default indicates that the stream is offered but MUST NOT be used, but an extension mechanism might specify different semantics for the usage of a zero port value. Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero by default indicates that the media stream is not wanted. 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP is to be sent to the peer. 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, if it would specify that the stream has been disabled. However, an extension mechanism might specify different Holmberg, et al. Expires June 18, 2019 [Page 35] Internet-Draft Bundled media December 2018 semantics of the zero port number usage. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP is to be sent to the peer. 14. Update to RFC 5888 This section updates RFC 5888 [RFC5888]), in order to allow extensions to allow an SDP 'group' attribute containing an identification-tag that identifies a "m=" section with the port set to zero Section 9.2 (Group Value in Answers) of RFC 5888 is updated. 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero. 14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888 SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero, but an extension mechanism might specify different semantics for including identification-tags that correspond to such "m=" lines. 15. RTP/RTCP extensions for identification-tag transport SDP Offerers and Answerers [RFC3264] can associate identification- tags with "m=" sections within SDP Offers and Answers, using the procedures in [RFC5888]. Each identification-tag uniquely represents an "m=" section. This section defines a new RTCP SDES item [RFC3550], 'MID', which is used to carry identification-tags within RTCP SDES packets. This section also defines a new RTP SDES header extension [RFC7941], which is used to carry the 'MID' RTCP SDES item in RTP packets. The SDES item and RTP SDES header extension make it possible for a receiver to associate each RTP stream with a specific "m=" section, with which the receiver has associated an identification-tag, even if those "m=" sections are part of the same RTP session. The RTP SDES header extension also ensures that the media recipient gets the identification-tag upon receipt of the first decodable media and is able to associate the media with the correct application. A media recipient informs the media sender about the identification- tag associated with an "m=" section through the use of an 'mid' Holmberg, et al. Expires June 18, 2019 [Page 36] Internet-Draft Bundled media December 2018 attribute [RFC5888]. The media sender then inserts the identification-tag in RTCP and RTP packets sent to the media recipient. NOTE: This text above defines how identification-tags are carried in SDP Offers and Answers. The usage of other signaling protocols for carrying identification-tags is not prevented, but the usage of such protocols is outside the scope of this document. [RFC3550] defines general procedures regarding the RTCP transmission interval. The RTCP MID SDES item SHOULD be sent in the first few RTCP packets sent after joining the session, and SHOULD be sent regularly thereafter. The exact number of RTCP packets in which this SDES item is sent is intentionally not specified here, as it will depend on the expected packet loss rate, the RTCP reporting interval, and the allowable overhead. The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD be included in some RTP packets at the start of the session and whenever the SSRC changes. It might also be useful to include the header extension in RTP packets that comprise access points in the media (e.g., with video I-frames). The exact number of RTP packets in which this header extension is sent is intentionally not specified here, as it will depend on expected packet loss rate and loss patterns, the overhead the application can tolerate, and the importance of immediate receipt of the identification-tag. For robustness, endpoints need to be prepared for situations where the reception of the identification-tag is delayed, and SHOULD NOT terminate sessions in such cases, as the identification-tag is likely to arrive soon. 15.1. RTCP MID SDES Item 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MID=TBD | length | identification-tag ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. The identification-tag is not zero terminated. [RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value.] Holmberg, et al. Expires June 18, 2019 [Page 37] Internet-Draft Bundled media December 2018 15.2. RTP SDES Header Extension For MID The payload, containing the identification-tag, of the RTP SDES header extension element can be encoded using either the one-byte or two-byte header [RFC7941]. The identification-tag payload is UTF-8 encoded, as in SDP. The identification-tag is not zero terminated. Note, that the set of header extensions included in the packet needs to be padded to the next 32-bit boundary using zero bytes [RFC8285]. As the identification-tag is included in either an RTCP SDES item or an RTP SDES header extension, or both, there needs to be some consideration about the packet expansion caused by the identification-tag. To avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the header extension's size needs to be taken into account when encoding the media. It is recommended that the identification-tag is kept short. Due to the properties of the RTP header extension mechanism, when using the one-byte header, a tag that is 1-3 bytes will result in a minimal number of 32-bit words used for the RTP SDES header extension, in case no other header extensions are included at the same time. Note, do take into account that some single characters when UTF-8 encoded will result in multiple octets. The identification-tag MUST NOT contain any user information, and applications SHALL avoid generating the identification-tag using a pattern that enables user- or application identification. 16. IANA Considerations 16.1. New SDES item [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] [RFC EDITOR NOTE: Please replace TBD with the assigned SDES identifier value.] This document adds the MID SDES item to the IANA "RTP SDES item types" registry as follows: Value: TBD Abbrev.: MID Name: Media Identification Reference: RFCXXXX Holmberg, et al. Expires June 18, 2019 [Page 38] Internet-Draft Bundled media December 2018 16.2. New RTP SDES Header Extension URI [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document defines a new extension URI in the RTP SDES Compact Header Extensions sub-registry of the RTP Compact Header Extensions registry sub-registry, according to the following data: Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Description: Media identification Contact: IESG (iesg@ietf.org) Reference: RFCXXXX The SDES item does not reveal privacy information about the users. It is simply used to associate RTP-based media with the correct SDP media description ("m=" section) in the SDP used to negotiate the media. The purpose of the extension is for the offerer to be able to associate received multiplexed RTP-based media before the offerer receives the associated SDP answer. 16.3. New SDP Attribute [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document defines a new SDP media-level attribute, 'bundle-only', according to the following data: Attribute name: bundle-only Type of attribute: media Subject to charset: No Purpose: Request a media description to be accepted in the answer only if kept within a BUNDLE group by the answerer. Appropriate values: N/A Contact name: IESG Contact e-mail: iesg@ietf.org Reference: RFCXXXX Mux category: NORMAL Holmberg, et al. Expires June 18, 2019 [Page 39] Internet-Draft Bundled media December 2018 16.4. New SDP Group Semantics [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] This document registers the following semantics with IANA in the "Semantics for the "group" SDP Attribute" subregistry (under the "Session Description Protocol (SDP) Parameters" registry: Semantics Token Reference ------------------------------------- ------ --------- Media bundling BUNDLE [RFCXXXX] Mux category: NORMAL 17. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g., RTP streams, flows over the network, with the exception of the usage of the MID SDES item as discussed below. Primarily it changes which addresses and ports, and thus in which (RTP) sessions the information is flowing. This affects the security contexts being used and can cause previously separated information flows to share the same security context. This has very little impact on the performance of the security mechanism of the RTP sessions. In cases where one would have applied different security policies on the different RTP streams being bundled, or where the parties having access to the security contexts would have differed between the RTP streams, additional analysis of the implications are needed before selecting to apply BUNDLE. The identification-tag, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-bundle group counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension. Note that if implementations use different methods for generating identification-tags this could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identification-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header Holmberg, et al. Expires June 18, 2019 [Page 40] Internet-Draft Bundled media December 2018 extensions. As the identification-tag is also used to route the media stream to the right application functionality it is important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Existing SRTP configurations and other security mechanisms protecting the whole RTP/RTCP packets will provide the necessary protection. When the BUNDLE extension is used, the set of configurations of the security mechanism used in all the bundled media descriptions will need to be compatible so that they can be used simultaneously, at least per direction or endpoint. When using SRTP this will be the case, at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their classification in [I-D.ietf-mmusic-sdp-mux-attributes]. The security considerations of "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] requires that when RTCP is confidentiality protected, then any SDES RTP header extension carrying an SDES item, such as the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed, there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Therefore, this specification updates RFC 7941 by adding the exception that this requirement MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. 18. Examples 18.1. Example: Tagged m= Section Selections The example below shows: o An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group, and indicates the audio m= section as the suggested offerer tagged "m=" section. o An initial BUNDLE answer, in which the answerer accepts the creation of the BUNDLE group, selects the audio m= section in the offer as the offerer tagged "m=" section, selects the audio "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 41] Internet-Draft Bundled media December 2018 SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 Holmberg, et al. Expires June 18, 2019 [Page 42] Internet-Draft Bundled media December 2018 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 18.2. Example: BUNDLE Group Rejected The example below shows: o An initial BUNDLE offer, in which the offerer wants to negotiate a BUNDLE group, and indicates the audio m= section as the suggested offerer tagged "m=" section. o An initial BUNDLE answer, in which the answerer rejects the creation of the BUNDLE group, generates a normal answer and assigns a unique address:port to each "m=" section in the answer. Holmberg, et al. Expires June 18, 2019 [Page 43] Internet-Draft Bundled media December 2018 SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10002 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 m=audio 20000 RTP/AVP 0 b=AS:200 a=rtcp-mux a=rtpmap:0 PCMU/8000 m=video 30000 RTP/AVP 32 b=AS:1000 a=rtcp-mux a=rtpmap:32 MPV/90000 Holmberg, et al. Expires June 18, 2019 [Page 44] Internet-Draft Bundled media December 2018 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group The example below shows: o A subsequent offer, in which the offerer adds a new bundled "m=" section (video), indicated by the "zen" identification-tag, to a previously negotiated BUNDLE group, indicates the new "m=" section as the offerer tagged "m=" section and assigns the offerer BUNDLE address:port to that "m=" section. o A subsequent answer, in which the answerer indicates the new video "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE zen foo bar m=audio 0 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=bundle-only a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Holmberg, et al. Expires June 18, 2019 [Page 45] Internet-Draft Bundled media December 2018 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE zen foo bar m=audio 0 RTP/AVP 0 b=AS:200 a=mid:foo a=bundle-only a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 20000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group The example below shows: o A subsequent offer, in which the offerer removes a "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group, indicates one of the bundled "m=" sections (audio) remaining in the BUNDLE group as the offerer tagged "m=" section and assigns the offerer BUNDLE address:port to that "m=" section. o A subsequent answer, in which the answerer removes the "m=" section from the BUNDLE group, indicates the audio "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. Holmberg, et al. Expires June 18, 2019 [Page 46] Internet-Draft Bundled media December 2018 SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= c=IN IP6 2001:db8::3 t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 31 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 50000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= c=IN IP6 2001:db8::1 t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Holmberg, et al. Expires June 18, 2019 [Page 47] Internet-Draft Bundled media December 2018 m=video 0 RTP/AVP 32 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 60000 RTP/AVP 66 b=AS:1000 a=mid:zen a=rtcp-mux a=rtpmap:66 H261/90000 18.5. Example: Offerer Disables a Media Description Within a BUNDLE Group The example below shows: o A subsequent offer, in which the offerer disables (by assigning a zero port value) a "m=" section (video), indicated by the "zen" identification-tag, from a previously negotiated BUNDLE group, indicates one of the bundled "m=" sections (audio) remaining active in the BUNDLE group as the offerer tagged "m=" section and assigns the offerer BUNDLE address:port to that "m=" section. o A subsequent answer, in which the answerer disables the "m=" section, indicates the audio "m=" section in the answer as the answerer tagged "m=" section and assigns the answerer BUNDLE address:port to that "m=" section. SDP Offer (1) v=0 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 s= t=0 0 a=group:BUNDLE foo bar m=audio 10000 RTP/AVP 0 8 97 c=IN IP6 2001:db8::3 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 Holmberg, et al. Expires June 18, 2019 [Page 48] Internet-Draft Bundled media December 2018 a=rtpmap:97 iLBC/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 31 32 c=IN IP6 2001:db8::3 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 66 a=mid:zen a=rtpmap:66 H261/90000 SDP Answer (2) v=0 o=bob 2808844564 2808844564 IN IP6 2001:db8::1 s= t=0 0 a=group:BUNDLE foo bar m=audio 20000 RTP/AVP 0 c=IN IP6 2001:db8::1 b=AS:200 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 32 c=IN IP6 2001:db8::1 b=AS:1000 a=mid:bar a=bundle-only a=rtpmap:32 MPV/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 0 RTP/AVP 66 a=mid:zen a=rtpmap:66 H261/90000 Holmberg, et al. Expires June 18, 2019 [Page 49] Internet-Draft Bundled media December 2018 19. Acknowledgements The usage of the SDP grouping extension for negotiating bundled media is based on similar alternatives proposed by Harald Alvestrand and Cullen Jennings. The BUNDLE extension described in this document is based on the different alternative proposals, and text (e.g., SDP examples) have been borrowed (and, in some cases, modified) from those alternative proposals. The SDP examples are also modified versions from the ones in the Alvestrand proposal. Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for reading the text, and providing useful feedback. Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus Westerlund for providing the text for the section on RTP/RTCP stream association. Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for providing help and text on the RTP/RTCP procedures. Thanks to Charlie Kaufman for performing the Sec-Dir review. Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Spotify for providing music for the countless hours of document editing. 20. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51 o Changes based on IESG reviews. o - Clarification of 'initial offer' terminology. o - Merging of tagged m- section selection sections. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 o Changes based on IESG reviews. Holmberg, et al. Expires June 18, 2019 [Page 50] Internet-Draft Bundled media December 2018 o - Adding of tagged m- section concept. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 o Changes based on IESG reviews. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 o Changes based on Sec-Dir review by Charlie Kaufman. o - s/unique address/unique address:port o Changes based on Gen-ART review by Linda Dunbar. o Mux category for group:BUNDLE attribute added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 o Changes based on AD review by Ben Campbell. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 o Pre-RFC5378 disclaimer removed put back. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 o Mux category for SDP 'group:BUNDLE' attribute added. o https://github.com/cdh4u/draft-sdp-bundle/pull/54 o Pre-RFC5378 disclaimer removed. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-44 o Minor editorial nits based on pull request by Colin P. o https://github.com/cdh4u/draft-sdp-bundle/pull/53 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-43 o Changes based on WG chairs review. o Text added in order to close GitHub issues by Taylor B. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-42 o Changes based on final WG review. Holmberg, et al. Expires June 18, 2019 [Page 51] Internet-Draft Bundled media December 2018 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-41 o Update to section 6 o RFC 3264: o https://github.com/cdh4u/draft-sdp-bundle/pull/47 o Editorial clarification on BUNDLE address selection: o https://github.com/cdh4u/draft-sdp-bundle/pull/46 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 o Editorial changes and technical restrictions in order to make the specification more understandable: o https://github.com/cdh4u/draft-sdp-bundle/pull/45 o - BUNDLE address is only assigned to m- section indicated by BUNDLE-tag. o - bundle-only attribute also used in answers and subsequent offers. o - Answerer cannot reject, or remove, the bundled m- section that contains the BUNDLE address. o - ICE Offer/Answer sections removed, due to duplicated information. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39 o Editorial terminology changes. o RFC 5285 reference replaced by reference to RFC 8285. o https://github.com/cdh4u/draft-sdp-bundle/pull/44 o - Clarify that an m- section can not be moved between BUNDLE groups without first moving the m- section out of a BUNDLE group. o https://github.com/cdh4u/draft-sdp-bundle/pull/41 o - Addition of BUNDLE transport concept. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 o Changes to RTP streaming mapping section based on text from Colin Perkins. Holmberg, et al. Expires June 18, 2019 [Page 52] Internet-Draft Bundled media December 2018 o The following GitHub pull requests were merged: o https://github.com/cdh4u/draft-sdp-bundle/pull/34 o - Proposed updates to RTP processing o https://github.com/cdh4u/draft-sdp-bundle/pull/35 o - fixed reference to receiver-id section Changes from draft-ietf-mmusic-sdp-bundle-negotiation-37 o The following GitHub pull request was merged: o https://github.com/cdh4u/draft-sdp-bundle/pull/33 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36 o The following GitHub pull requests were merged: o https://github.com/cdh4u/draft-sdp-bundle/pull/32 o - extmap handling in BUNDLE. o https://github.com/cdh4u/draft-sdp-bundle/pull/31 o - Additional Acknowledgement text added. o https://github.com/cdh4u/draft-sdp-bundle/pull/30 o - MID SDES item security procedures updated o https://github.com/cdh4u/draft-sdp-bundle/pull/29 o - Appendix B of JSEP moved into BUNDLE. o - Associating RTP/RTCP packets with SDP m- lines. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 o Editorial changes on RTP streaming mapping section based on comments from Colin Perkins. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 o RTP streams, instead of RTP packets, are associated with m- lines. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 Holmberg, et al. Expires June 18, 2019 [Page 53] Internet-Draft Bundled media December 2018 o Editorial changes based on comments from Eric Rescorla and Cullen Jennings: o - Changes regarding usage of RTP/RTCP multiplexing attributes. o - Additional text regarding associating RTP/RTCP packets with SDP m- lines. o - Reference correction. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-32 o Editorial changes based on comments from Eric Rescorla and Cullen Jennings: o - Justification for mechanism added to Introduction. o - Clarify that the order of m- lines in the group:BUNDLE attribute does not have to be the same as the order in which the m- lines are listed in the SDP. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-31 o Editorial changes based on GitHub Pull requests by Martin Thomson: o - https://github.com/cdh4u/draft-sdp-bundle/pull/2 o - https://github.com/cdh4u/draft-sdp-bundle/pull/1 o Editorial change based on comment from Diederick Huijbers (9th July 2016). o Changes based on comments from Flemming Andreasen (21st June 2016): o - Mux category for SDP bundle-only attribute added. o - Mux category considerations editorial clarification. o - Editorial changes. o RTP SDES extension according to draft-ietf-avtext-sdes-hdr-ext. o Note whether Design Considerations appendix is to be kept removed: o - Appendix is kept within document. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-30 Holmberg, et al. Expires June 18, 2019 [Page 54] Internet-Draft Bundled media December 2018 o Indicating in the Abstract and Introduction that the document updates RFC 3264. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-29 o Change based on WGLC comment from Colin Perkins. o - Clarify that SSRC can be reused by another source after a delay of 5 RTCP reporting intervals. o Change based on WGLC comment from Alissa Cooper. o - IANA registry name fix. o - Additional IANA registration information added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-28 o - Alignment with exclusive mux procedures. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 o - Yet another terminology change. o - Mux category considerations added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 o - ICE considerations modified: ICE-related SDP attributes only added to the bundled m- line representing the selected BUNDLE address. o - Reference to draft-ietf-mmusic-ice-sip-sdp added. o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- rfc5245bis. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux considerations. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 o - Reference and procedures associated with exclusive RTP/RTCP mux added Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 Holmberg, et al. Expires June 18, 2019 [Page 55] Internet-Draft Bundled media December 2018 o - RTCP-MUX mandatory for bundled RTP m- lines o - Editorial fixes based on comments from Flemming Andreasen Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 o - Correction of Ari's family name o - Editorial fixes based on comments from Thomas Stach o - RTP/RTCP correction based on comment from Magnus Westerlund o -- http://www.ietf.org/mail-archive/web/mmusic/current/ msg14861.html Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 o - Correct based on comment from Paul Kyzivat o -- 'received packets' replaced with 'received data' Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 o - Clarification based on comment from James Guballa o - Clarification based on comment from Flemming Andreasen Changes from draft-ietf-mmusic-sdp-bundle-negotiation-19 o - DTLS Considerations section added. o - BUNDLE semantics added to the IANA Considerations o - Changes based on WGLC comments from Adam Roach o -- http://www.ietf.org/mail-archive/web/mmusic/current/ msg14673.html Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 o - Changes based on agreements at IETF#92 o -- BAS Offer removed, based on agreement at IETF#92. o -- Procedures regarding usage of SDP "b=" line is replaced with a reference to to draft-ietf-mmusic-sdp-mux-attributes. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 Holmberg, et al. Expires June 18, 2019 [Page 56] Internet-Draft Bundled media December 2018 o - Editorial changes based on comments from Magnus Westerlund. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 o - Modification of RTP/RTCP multiplexing section, based on comments from Magnus Westerlund. o - Reference updates. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 o - Editorial fix. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 o - Editorial changes. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 o Changes to allow a newly suggested offerer BUNDLE address to be assigned to each bundled m- line. o Changes based on WGLC comments from Paul Kyzivat o - Editorial fixes Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 o Usage of SDP 'extmap' attribute added o SDP 'bundle-only' attribute scoped with "m=" lines with a zero port value o Changes based on WGLC comments from Thomas Stach o - ICE candidates not assigned to bundle-only m- lines with a zero port value o - Editorial changes o Changes based on WGLC comments from Colin Perkins o - Editorial changes: o -- "RTP SDES item" -> "RTCP SDES item" o -- "RTP MID SDES item" -> "RTCP MID SDES item" Holmberg, et al. Expires June 18, 2019 [Page 57] Internet-Draft Bundled media December 2018 o - Changes in section 10.1.1: o -- "SHOULD NOT" -> "MUST NOT" o -- Additional text added to the Note o - Change to section 13.2: o -- Clarify that mid value is not zero terminated o - Change to section 13.3: o -- Clarify that mid value is not zero terminated o -- Clarify padding o Changes based on WGLC comments from Paul Kyzivat o - Editorial changes: o Changes based on WGLC comments from Jonathan Lennox o - Editorial changes: o - Defintion of SDP bundle-only attribute alligned with structure in 4566bis draft Changes from draft-ietf-mmusic-sdp-bundle-negotiation-11 o Editorial corrections based on comments from Harald Alvestrand. o Editorial corrections based on comments from Cullen Jennings. o Reference update (RFC 7160). o Clarification about RTCP packet sending when RTP/RTCP multiplexing is not used (http://www.ietf.org/mail-archive/web/mmusic/current/ msg13765.html). o Additional text added to the Security Considerations. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-10 o SDP bundle-only attribute added to IANA Considerations. o SDES item and RTP header extension added to Abstract and Introduction. Holmberg, et al. Expires June 18, 2019 [Page 58] Internet-Draft Bundled media December 2018 o Modification to text updating section 8.2 of RFC 3264. o Reference corrections. o Editorial corrections. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-09 o Terminology change: "bundle-only attribute assigned to m= line" to "bundle-only attribute associated with m= line". o Editorial corrections. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-08 o Editorial corrections. o - "of"->"if" (8.3.2.5). o - "optional"->"OPTIONAL" (9.1). o - Syntax/ABNF for 'bundle-only' attribute added. o - SDP Offer/Answer sections merged. o - 'Request new offerer BUNDLE address' section added Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 o OPEN ISSUE regarding Receiver-ID closed. o - RTP MID SDES Item. o - RTP MID Header Extension. o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers closed. o - Indicating that, when rtcp-mux is used, the answerer MUST NOT include an 'rtcp' attribute in the answer, based on the procedures in section 5.1.3 of RFC 5761. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 o Draft title changed. o Added "SDP" to section names containing "Offer" or "Answer". Holmberg, et al. Expires June 18, 2019 [Page 59] Internet-Draft Bundled media December 2018 o Editorial fixes based on comments from Paul Kyzivat (http://www.ietf.org/mail-archive/web/mmusic/current/ msg13314.html). o Editorial fixed based on comments from Colin Perkins (http://www.ietf.org/mail-archive/web/mmusic/current/ msg13318.html). o - Removed text about extending BUNDLE to allow multiple RTP sessions within a BUNDLE group. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-05 o Major re-structure of SDP Offer/Answer sections, to align with RFC 3264 structure. o Additional definitions added. o - Shared address. o - Bundled "m=" line. o - Bundle-only "m=" line. o - Offerer suggested BUNDLE mid. o - Answerer selected BUNDLE mid. o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address to multiple "m=" lines until it has received an SDP Answer indicating support of the BUNDLE extension. o Q8 Closed (IETF#88): An Offerer can, before it knows whether the Answerer supports the BUNDLE extension, assign a zero port value to a 'bundle-only' "m=" line. o SDP 'bundle-only' attribute section added. o Connection data nettype/addrtype restrictions added. o RFC 3264 update section added. o Indicating that a specific payload type value can be used in multiple "m=" lines, if the value represents the same codec configuration in each "m=" line. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-04 Holmberg, et al. Expires June 18, 2019 [Page 60] Internet-Draft Bundled media December 2018 o Updated Offerer procedures (http://www.ietf.org/mail- archive/web/mmusic/current/msg12293.html). o Updated Answerer procedures (http://www.ietf.org/mail- archive/web/mmusic/current/msg12333.html). o Usage of SDP 'bundle-only' attribute added. o Reference to Trickle ICE document added. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-02 o Mechanism modified, to be based on usage of SDP Offers with both different and identical port number values, depending on whether it is known if the remote endpoint supports the extension. o Cullen Jennings added as co-author. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-01 o No changes. New version due to expiration. Changes from draft-ietf-mmusic-sdp-bundle-negotiation-00 o No changes. New version due to expiration. Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00 o Draft name changed. o Harald Alvestrand added as co-author. o "Multiplex" terminology changed to "bundle". o Added text about single versus multiple RTP Sessions. o Added reference to RFC 3550. 21. References 21.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, . Holmberg, et al. Expires June 18, 2019 [Page 61] Internet-Draft Bundled media December 2018 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . Holmberg, et al. Expires June 18, 2019 [Page 62] Internet-Draft Bundled media December 2018 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-20 (work in progress), March 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 (work in progress), December 2016. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-12 (work in progress), May 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in progress), April 2018. [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Trickle ICE", draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), February 2018. Holmberg, et al. Expires June 18, 2019 [Page 63] Internet-Draft Bundled media December 2018 21.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . Holmberg, et al. Expires June 18, 2019 [Page 64] Internet-Draft Bundled media December 2018 [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. [I-D.ietf-avtext-lrr] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Message", draft-ietf-avtext-lrr-07 (work in progress), July 2017. Appendix A. Design Considerations One of the main issues regarding the BUNDLE grouping extensions has been whether, in SDP Offers and SDP Answers, the same port value can be inserted in "m=" lines associated with a BUNDLE group, as the purpose of the extension is to negotiate the usage of a single transport for media specified by the "m=" sections. Issues with both approaches, discussed in the Appendix have been raised. The outcome was to specify a mechanism which uses SDP Offers with both different and identical port values. Below are the primary issues that have been considered when defining the "BUNDLE" grouping extension: o 1) Interoperability with existing UAs. o 2) Interoperability with intermediary Back to Back User Agent (B2BUA) and proxy entities. o 3) Time to gather, and the number of, ICE candidates. o 4) Different error scenarios, and when they occur. o 5) SDP Offer/Answer impacts, including usage of port number value zero. A.1. UA Interoperability Consider the following SDP Offer/Answer exchange, where Alice sends an SDP Offer to Bob: Holmberg, et al. Expires June 18, 2019 [Page 65] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 10000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 10002 RTP/AVP 97 a=rtpmap:97 H261/90000 SDP Answer v=0 o=bob 2808844564 2808844564 IN IP4 biloxi.example.com s= c=IN IP4 biloxi.example.com t=0 0 m=audio 20000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 20002 RTP/AVP 97 a=rtpmap:97 H261/90000 RFC 4961 specifies a way of doing symmetric RTP but that is a later extension to RTP and Bob can not assume that Alice supports RFC 4961. This means that Alice may be sending RTP from a different port than 10000 or 10002 - some implementations simply send the RTP from an ephemeral port. When Bob's endpoint receives an RTP packet, the only way that Bob knows if the packet is to be passed to the video or audio codec is by looking at the port it was received on. This led some SDP implementations to use the fact that each "m=" section had a different port number to use that port number as an index to find the correct m line in the SDP. As a result, some implementations that do support symmetric RTP and ICE still use an SDP data structure where SDP with "m=" sections with the same port such as: Holmberg, et al. Expires June 18, 2019 [Page 66] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 10000 RTP/AVP 97 a=rtpmap:97 iLBC/8000 m=video 10000 RTP/AVP 98 a=rtpmap:98 H261/90000 will result in the second "m=" section being considered an SDP error because it has the same port as the first line. A.2. Usage of Port Number Value Zero In an SDP Offer or SDP Answer, the media specified by an "m=" section can be disabled/rejected by setting the port number value to zero. This is different from e.g., using the SDP direction attributes, where RTCP traffic will continue even if the SDP "inactive" attribute is indicated for the associated "m=" section. If each "m=" section associated with a BUNDLE group would contain different port values, and one of those port values would be used for a BUNDLE address:port associated with the BUNDLE group, problems would occur if an endpoint wants to disable/reject the "m=" section associated with that port, by setting the port value to zero. After that, no "m=" section would contain the port value which is used for the BUNDLE address:port. In addition, it is unclear what would happen to the ICE candidates associated with the "m=" section, as they are also used for the BUNDLE address:port. A.3. B2BUA And Proxy Interoperability Some back to back user agents may be configured in a mode where if the incoming call leg contains an SDP attribute the B2BUA does not understand, the B2BUA still generates that SDP attribute in the Offer for the outgoing call leg. Consider a B2BUA that did not understand the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. Further assume that the B2BUA was configured to tear down any call where it did not see any RTCP for 5 minutes. In this case, if the B2BUA received an Offer like: Holmberg, et al. Expires June 18, 2019 [Page 67] Internet-Draft Bundled media December 2018 SDP Offer v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtcp:53020 It would be looking for RTCP on port 49171 but would not see any because the RTCP would be on port 53020 and after five minutes, it would tear down the call. Similarly, a B2BUA that did not understand BUNDLE yet put BUNDLE in its offer may be looking for media on the wrong port and tear down the call. It is worth noting that a B2BUA that generated an Offer with capabilities it does not understand is not compliant with the specifications. A.3.1. Traffic Policing Sometimes intermediaries do not act as B2BUAs, in the sense that they don't modify SDP bodies, nor do they terminate SIP dialogs. Still, however, they may use SDP information (e.g., IP address and port) in order to control traffic gating functions, and to set traffic policing rules. There might be rules which will trigger a session to be terminated in case media is not sent or received on the ports retrieved from the SDP. This typically occurs once the session is already established and ongoing. A.3.2. Bandwidth Allocation Sometimes intermediaries do not act as B2BUAs, in the sense that they don't modify SDP bodies, nor do they terminate SIP dialogs. Still, however, they may use SDP information (e.g., codecs and media types) in order to control bandwidth allocation functions. The bandwidth allocation is done per "m=" section, which means that it might not be enough if media specified by all "m=" sections try to use that bandwidth. That may either simply lead to bad user experience, or to termination of the call. A.4. Candidate Gathering When using ICE, a candidate needs to be gathered for each port. This takes approximately 20 ms extra for each extra "m=" section due to the NAT pacing requirements. All of this gathering can be overlapped Holmberg, et al. Expires June 18, 2019 [Page 68] Internet-Draft Bundled media December 2018 with other things while e.g., a web-page is loading to minimize the impact. If the client only wants to generate TURN or STUN ICE candidates for one of the "m=" lines and then use trickle ICE [I-D.ietf-ice-trickle] to get the non host ICE candidates for the rest of the "m=" sections, it MAY do that and will not need any additional gathering time. Some people have suggested a TURN extension to get a bunch of TURN allocations at once. This would only provide a single STUN result so in cases where the other end did not support BUNDLE, it may cause more use of the TURN server but would be quick in the cases where both sides supported BUNDLE and would fall back to a successful call in the other cases. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Harald Tveit Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Cullen Jennings Cisco 400 3rd Avenue SW, Suite 350 Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Holmberg, et al. Expires June 18, 2019 [Page 69] ./draft-ietf-mmusic-sdp-mux-attributes-19.txt0000644000764400076440000071047513722077230020457 0ustar iustyiusty Network Working Group S. Nandakumar Internet-Draft Cisco Intended status: Standards Track August 27, 2020 Expires: February 28, 2021 A Framework for SDP Attributes when Multiplexing draft-ietf-mmusic-sdp-mux-attributes-19 Abstract The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session Description Protocol (SDP) attributes when SDP is used to negotiate the usage of single 5-tuple for sending and receiving media associated with multiple media descriptions. This specification also categorizes the existing SDP attributes based on the framework described herein. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 28, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Nandakumar Expires February 28, 2021 [Page 1] Internet-Draft SDP Attribute Multiplexing August 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SDP Attribute Analysis Framework . . . . . . . . . . . . . . 6 4.1. Category: NORMAL . . . . . . . . . . . . . . . . . . . . 7 4.2. Category: CAUTION . . . . . . . . . . . . . . . . . . . . 7 4.3. Category: IDENTICAL . . . . . . . . . . . . . . . . . . . 8 4.4. Category: SUM . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Category: TRANSPORT . . . . . . . . . . . . . . . . . . . 9 4.6. Category: INHERIT . . . . . . . . . . . . . . . . . . . . 10 4.7. Category: IDENTICAL-PER-PT . . . . . . . . . . . . . . . 11 4.8. Category: SPECIAL . . . . . . . . . . . . . . . . . . . . 12 4.9. Category: TBD . . . . . . . . . . . . . . . . . . . . . . 12 5. Analysis of Existing Attributes . . . . . . . . . . . . . . . 12 5.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 13 5.2. RFC4585: RTP/AVPF . . . . . . . . . . . . . . . . . . . . 14 5.3. RFC5761: Multiplexing RTP and RTCP . . . . . . . . . . . 15 5.4. RFC3312: Integration of Resource Management and SIP . . . 15 5.5. RFC4574: SDP Label Attribute . . . . . . . . . . . . . . 16 5.6. RFC5432: QOS Mechanism Selection in SDP . . . . . . . . . 16 5.7. RFC4568: SDP Security Descriptions . . . . . . . . . . . 17 5.8. RFC5762: RTP over DCCP . . . . . . . . . . . . . . . . . 17 5.9. RFC6773: DCCP-UDP Encapsulation . . . . . . . . . . . . . 18 5.10. RFC5506: Reduced-Size RTCP in RTP Profile . . . . . . . . 19 5.11. RFC6787: Media Resource Control Protocol Version 2 . . . 19 5.12. RFC5245: ICE . . . . . . . . . . . . . . . . . . . . . . 20 5.13. RFC5285: RTP Header Extensions . . . . . . . . . . . . . 21 5.14. RFC3605: RTCP attribute in SDP . . . . . . . . . . . . . 22 5.15. RFC5576: Source-Specific SDP Attributes . . . . . . . . . 22 5.16. RFC7273: RTP Clock Source Signalling . . . . . . . . . . 23 5.17. RFC6236: Image Attributes in SDP . . . . . . . . . . . . 24 5.18. RFC7197: Duplication Delay Attribute in SDP . . . . . . . 25 5.19. RFC7266: RTCP XR Blocks for MOS Metric Reporting . . . . 25 5.20. RFC6285: Rapid Acquisition of Multicast RTP Sessions . . 25 5.21. RFC6230: Media Control Channel Framework . . . . . . . . 26 5.22. RFC6364: SDP Elements for FEC Framework . . . . . . . . . 26 5.23. RFC4796: Content Attribute . . . . . . . . . . . . . . . 27 5.24. RFC3407: SDP Simple Capability Declaration . . . . . . . 27 5.25. RFC6284: Port Mapping between Unicast and Multicast RTP Sessions . . . . . . . . . . . . . . . . . . . . . . . . 28 5.26. RFC6714: MSRP-CEMA . . . . . . . . . . . . . . . . . . . 29 5.27. RFC4583: SDP Format for BFCP Streams . . . . . . . . . . 29 Nandakumar Expires February 28, 2021 [Page 2] Internet-Draft SDP Attribute Multiplexing August 2020 5.28. RFC5547: SDP Offer/Answer for File Transfer . . . . . . . 30 5.29. RFC6849: SDP and RTP Media Loopback Extension . . . . . . 30 5.30. RFC5760: RTCP with Unicast Feedback . . . . . . . . . . . 31 5.31. RFC3611: RTCP XR . . . . . . . . . . . . . . . . . . . . 31 5.32. RFC5939: SDP Capability Negotiation . . . . . . . . . . . 32 5.33. RFC6871: SDP Media Capabilities Negotiation . . . . . . . 32 5.34. RFC7006: Miscellaneous Capabilities Negotiation SDP . . . 33 5.35. RFC4567: Key Management Extensions for SDP and RTSP . . . 34 5.36. RFC4572: Comedia over TLS in SDP . . . . . . . . . . . . 35 5.37. RFC4570: SDP Source Filters . . . . . . . . . . . . . . . 35 5.38. RFC6128: RTCP Port for Multicast Sessions . . . . . . . . 36 5.39. RFC6189: ZRTP . . . . . . . . . . . . . . . . . . . . . . 36 5.40. RFC4145: Connection-Oriented Media . . . . . . . . . . . 37 5.41. RFC6947: The SDP altc Attribute . . . . . . . . . . . . . 37 5.42. RFC7195: SDP Extension for Circuit Switched Bearers in PSTN . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.43. RFC7272: IDMS Using the RTP Control Protocol (RTCP) . . . 38 5.44. RFC5159: Open Mobile Alliance (OMA) Broadcast (BCAST) SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 39 5.45. RFC6193: Media Description for IKE in SDP . . . . . . . . 39 5.46. RFC2326: Real Time Streaming Protocol . . . . . . . . . . 40 5.47. RFC6064: SDP and RTSP Extensions for 3GPP . . . . . . . . 41 5.48. RFC3108: ATM SDP . . . . . . . . . . . . . . . . . . . . 43 5.49. 3GPP TS 26.114 . . . . . . . . . . . . . . . . . . . . . 45 5.50. 3GPP TS 183.063 . . . . . . . . . . . . . . . . . . . . . 46 5.51. 3GPP TS 24.229 . . . . . . . . . . . . . . . . . . . . . 46 5.52. ITU T.38 . . . . . . . . . . . . . . . . . . . . . . . . 47 5.53. ITU-T Q.1970 . . . . . . . . . . . . . . . . . . . . . . 49 5.54. ITU-T H.248.15 . . . . . . . . . . . . . . . . . . . . . 49 5.55. RFC4975: The Message Session Relay Protocol . . . . . . . 50 5.56. Historical Attributes . . . . . . . . . . . . . . . . . . 51 6. bwtype Attribute Analysis . . . . . . . . . . . . . . . . . . 51 6.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 52 6.2. RFC3556: SDP Bandwidth Modifiers for RTCP Bandwidth . . . 52 6.3. RFC3890: Bandwidth Modifier for SDP . . . . . . . . . . . 53 7. rtcp-fb Attribute Analysis . . . . . . . . . . . . . . . . . 53 7.1. RFC4585: RTP/AVPF . . . . . . . . . . . . . . . . . . . . 53 7.2. RFC5104: Codec Control Messages in AVPF . . . . . . . . . 54 7.3. RFC6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . . . . . . . . . . . . . . . . 55 7.4. RFC6679: ECN for RTP over UDP/IP . . . . . . . . . . . . 55 7.5. RFC6642: Third-Party Loss Report . . . . . . . . . . . . 56 7.6. RFC5104: Codec Control Messages in AVPF . . . . . . . . . 57 8. group Attribute Analysis . . . . . . . . . . . . . . . . . . 57 8.1. RFC5888: SDP Grouping Framework . . . . . . . . . . . . . 57 8.2. RFC3524: Mapping Media Streams to Resource Reservation Flows . . . . . . . . . . . . . . . . . . . . 58 8.3. RFC4091: ANAT Semantics . . . . . . . . . . . . . . . . . 58 Nandakumar Expires February 28, 2021 [Page 3] Internet-Draft SDP Attribute Multiplexing August 2020 8.4. RFC5956: FEC Grouping Semantics in SDP . . . . . . . . . 58 8.5. RFC5583: Signaling Media Decoding Dependency in SDP . . . 59 8.6. RFC7104: Duplication Grouping Semantics in the SDP . . . 59 9. ssrc-group Attribute Analysis . . . . . . . . . . . . . . . . 60 9.1. RFC5576: Source-Specific SDP Attributes . . . . . . . . . 60 9.2. RFC7104: Duplication Grouping Semantics in the SDP . . . 60 10. QoS Mechanism Token Analysis . . . . . . . . . . . . . . . . 61 10.1. RFC5432: QoS Mechanism Selection in SDP . . . . . . . . 61 11. k= Attribute Analysis . . . . . . . . . . . . . . . . . . . . 61 11.1. RFC4566: SDP . . . . . . . . . . . . . . . . . . . . . . 62 12. content Attribute Analysis . . . . . . . . . . . . . . . . . 62 12.1. RFC4796 . . . . . . . . . . . . . . . . . . . . . . . . 62 12.2. 3GPP TS 24.182 . . . . . . . . . . . . . . . . . . . . . 63 12.3. 3GPP TS 24.183 . . . . . . . . . . . . . . . . . . . . . 63 13. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 63 13.1. RFC5109: RTP Payload Format for Generic FEC . . . . . . 63 14. Multiplexing Considerations for Encapsulating Attributes . . 64 14.1. RFC3407: cpar Attribute Analysis . . . . . . . . . . . . 64 14.2. RFC5939 Analysis . . . . . . . . . . . . . . . . . . . . 65 14.2.1. Recommendation: Procedures for Potential Configuration Pairing . . . . . . . . . . . . . . . 66 14.2.1.1. Example: Transport Capability Multiplexing . . . 67 14.2.1.2. Example: Attribute Capability Multiplexing . . . 68 14.3. RFC6871 Analysis . . . . . . . . . . . . . . . . . . . . 68 14.3.1. Recommendation: Dealing with Payload Type Numbers . 68 14.3.1.1. Example: Attribute Capability Under Shared Payload Type . . . . . . . . . . . . . . . . . . 69 14.3.2. Recommendation: Dealing with Latent Configurations . 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 15.1. New 'Multiplexing Categories' subregistry . . . . . . . 70 15.2. 'Mux Category' column for subregistries . . . . . . . . 71 15.2.1. Table: SDP bwtype . . . . . . . . . . . . . . . . . 72 15.2.2. Table: att-field (session level) . . . . . . . . . . 72 15.2.3. Table: att-field (both session and media level) . . 73 15.2.4. Table: att-field (media level only) . . . . . . . . 75 15.2.5. Table: att-field (source level) . . . . . . . . . . 78 15.2.6. Table: content SDP Parameters . . . . . . . . . . . 79 15.2.7. Table: Semantics for the 'group' SDP Attribute . . . 79 15.2.8. Table: 'rtcp-fb' Attribute Values . . . . . . . . . 79 15.2.9. Table: 'ack' and 'nack' Attribute Values . . . . . . 80 15.2.10. Table: 'depend' SDP Attribute Values . . . . . . . . 80 15.2.11. Table: 'cs-correlation' Attribute Values . . . . . . 81 15.2.12. Table: Semantics for the 'ssrc-group' SDP Attribute 81 15.2.13. Table: SDP/RTSP key management protocol identifiers 81 15.2.14. Table: Codec Control Messages . . . . . . . . . . . 82 15.2.15. Table: QoS Mechanism Tokens . . . . . . . . . . . . 82 15.2.16. Table: SDP Capability Negotiation Option Tags . . . 82 15.2.17. Table: Timestamp Reference Clock Source Parameters . 83 Nandakumar Expires February 28, 2021 [Page 4] Internet-Draft SDP Attribute Multiplexing August 2020 15.2.18. Table: Media Clock Source Parameters . . . . . . . . 83 16. Security Considerations . . . . . . . . . . . . . . . . . . . 83 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 84 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 19.1. Normative References . . . . . . . . . . . . . . . . . . 88 19.2. Informative References . . . . . . . . . . . . . . . . . 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 96 1. Introduction SDP defines several attributes for capturing characteristics that apply to the individual media descriptions (described by "m=" lines") and the overall multimedia session. Typically different media types (audio, video, etc.) described using different media descriptions represent separate RTP sessions that are carried over individual transport layer flows. However [I-D.ietf-mmusic-sdp-bundle-negotiation] defines a way to use a single address:port combination (BUNDLE address) for receiving media associated with multiple SDP media descriptions. This would, for example allow the usage of a single set of Interactive Connectivity Establishment (ICE) [RFC5245] candidates for multiple media descriptions. This in turn has made it necessary to understand the interpretation and usage of the SDP attributes defined for the multiplexed media descriptions. Given the number of SDP attributes registered with the [IANA] and possibility of new attributes being defined in the future, there is need for a framework to analyze these attributes for their applicability in the transport multiplexing use-cases. The document starts with providing the motivation for requiring such a framework. This is followed by introduction to the SDP attribute analysis framework/procedures, following which several sections apply the framework to the SDP attributes registered with the [IANA]. 2. Terminology 5-tuple: A collection of the following values: source address, source port, destination address, destination port, and transport-layer protocol. 3GPP: Third Generation Partnership Project; see http://www.3gpp.org for more information about this organization. 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]. Nandakumar Expires February 28, 2021 [Page 5] Internet-Draft SDP Attribute Multiplexing August 2020 3. Motivation The time and complications of setting up ICE [RFC5245] and Datagram Transport Layer Security (DTLS) based Secure Real-time Transport Protocol (SRTP) [RFC5763] transports for use by RTP, reasons to conserve ports bindings on the Network Address Translators (NAT), forms a requirement to try and reduce the number of transport level flows needed. This has resulted in the definition of ways, such as [I-D.ietf-mmusic-sdp-bundle-negotiation] to multiplex RTP over a single transport flow in order to preserve network resources such as port numbers. This imposes further restrictions on applicability of the SDP attributes as they are defined today. The specific problem is that there are attribute combinations which make sense when specified on independent "m=" lines -- as with classical SDP -- that do not make sense when those "m=" lines are then multiplexed over the same transport. To give an obvious example, ICE permits each "m=" line to have an independently specified ice-ufrag attribute. However, if the media from multiple "m=" lines is multiplexed over the same ICE component, then the meaning of media-level ice-ufrag attributes becomes muddled. At the time of writing this document there are close to 250 SDP attributes registered with the [IANA] and more will be added in the future. There is no clearly defined procedure to establish the validity/applicability of these attributes when used with transport multiplexing. 4. SDP Attribute Analysis Framework Attributes in an SDP session description can be defined at the session-level or media-level or source-level. Informally, there are various semantic groupings for these attributes. One such grouping could be notes as below: o Attributes related to media content such as media type, encoding schemes and payload types. o Attributes specifying media transport characteristics like RTP/RTP Control Protocol (RTCP) port numbers, network addresses and QOS. o Metadata description attributes capturing session timing and origin information. o Attributes establishing relationships between media descriptions such as grouping framework [RFC5888] Nandakumar Expires February 28, 2021 [Page 6] Internet-Draft SDP Attribute Multiplexing August 2020 The proposed framework analyzes the SDP attributes usage under multiplexing and assigns each SDP attribute to an appropriate multiplexing category. Since the multiplexing categories defined in this specification are independent of any informal semantic groupings of the SDP attributes, the categorizations assigned are normative. 4.1. Category: NORMAL The attributes in the NORMAL category can be independently specified when multiplexed and they retain their original semantics. In the example given below, the direction and label attributes are independently specified for audio and video "m=" lines. These attributes are not impacted by multiplexing these media streams over a single transport layer flow. v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49172 RTP/AVP 99 a=sendonly a=label:1 a=rtpmap:99 iLBC/8000 m=video 49172 RTP/AVP 31 a=recvonly a=label:2 a=rtpmap:31 H261/90000 4.2. Category: CAUTION The attributes in the CAUTION category are advised against multiplexing since their usage under multiplexing might lead to incorrect behavior. Example: Multiplexing media descriptions over a single Datagram Congestion Control Protocol (DCCP) transport [RFC5762] is not recommended since DCCP being a connection oriented protocol doesn't allow multiple connections on the same 5-tuple. Nandakumar Expires February 28, 2021 [Page 7] Internet-Draft SDP Attribute Multiplexing August 2020 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=video 5004 DCCP/RTP/AVP 99 a=rtpmap:99 h261/9000 a=dccp-service-code:SC=x52545056 a=setup:passive a=connection:new m=video 5004 DCCP/RTP/AVP 100 a=rtpmap:100 h261/9000 a=dccp-service-code:SC=x5254504f a=setup:passive a=connection:new 4.3. Category: IDENTICAL The attributes and their associated values (if any) in the IDENTICAL category MUST be repeated across all the media descriptions under multiplexing. Attributes such as rtcp-mux fall into this category. Since RTCP reporting is done per RTP session, RTCP Multiplexing MUST be enabled for both the audio and video "m=" lines if they are transported over a single 5-tuple. v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s= c=IN IP4 client.biloxi.example.com t=0 0 m=audio 34567 RTP/AVP 97 a=rtcp-mux m=video 34567 RTP/AVP 31 a=rtpmap:31 H261/90000 a=rtcp-mux Note: Eventhough IDENTICAL attributes must be repeated across all media descriptions under multiplexing, they might not always be explicitly encoded across all media descriptions. [I-D.ietf-mmusic-sdp-bundle-negotiation] defines rules for when attributes and their values are implicitly applied to media description. Nandakumar Expires February 28, 2021 [Page 8] Internet-Draft SDP Attribute Multiplexing August 2020 4.4. Category: SUM The attributes in the SUM category can be set as they are normally used but software using them in the multiplexing scenario MUST apply the sum of all the attributes being multiplexed instead of trying to use them independently. This is typically used for bandwidth or other rate limiting attributes to the underlying transport. The software parsing the SDP sample below, should use the aggregate Application Specific (AS) bandwidth value from the individual media descriptions to determine the AS value for the multiplexed session. Thus the calculated AS value would be 256+64 kilobits per second for the given example. v=0 o=test 2890844526 2890842807 IN IP4 client.biloxi.example.com c=IN IP4 client.biloxi.example.com t=0 0 m=audio 49170 RTP/AVP 0 b=AS:64 m=video 51372 RTP/AVP 31 b=AS:256 4.5. Category: TRANSPORT The attributes in the TRANSPORT category can be set normally for multiple items in a multiplexed group but the software MUST pick the one that's associated with the "m=" line whose information is used for setting up the underlying transport. In the example below, "a=crypto" attribute is defined for both the audio and the video "m=" lines. The video media line's a=crypto attribute is chosen since its mid value (bar) appears first in the a=group:BUNDLE line. This is due to BUNDLE grouping semantic [I-D.ietf-mmusic-sdp-bundle-negotiation] which mandates the values from "m=" line corresponding to the mid appearing first on the a=group:BUNDLE line to be considered for setting up the RTP Transport. Nandakumar Expires February 28, 2021 [Page 9] Internet-Draft SDP Attribute Multiplexing August 2020 v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=group:BUNDLE bar foo m=audio 49172 RTP/AVP 99 a=mid:foo a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 a=rtpmap:99 iLBC/8000 m=video 51374 RTP/AVP 31 a=mid:bar a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:EcGZiNWpFJhQXdspcl1ekcmVCNWpVLcfHAwJSoj|2^20|1:32 a=rtpmap:96 H261/90000 4.6. Category: INHERIT The attributes in the INHERIT category encapsulate other SDP attributes or parameters. These attributes inherit their multiplexing characteristics from the attributes or parameters they encapsulate. Such attributes are defined in [RFC3407], [RFC5939] and [RFC6871] as part of a generic framework for indicating and negotiating transport, media, and media format related capabilities in the SDP. The inheritance manifests itself when the encapsulated attribute or parameter is being leveraged. In the case of SDP Capability Negotiation [RFC5939] for example, this occurs when a capability (encapsulating attribute) is used as part of a configuration; the configuration inherits the multiplexing category of each of its constituent (encapsulated) attributes and parameters. The inherited attributes MUST be coherent in order to form a valid configuration from a multiplexing point of view (see Section 14 for further details). Nandakumar Expires February 28, 2021 [Page 10] Internet-Draft SDP Attribute Multiplexing August 2020 v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=video 3456 RTP/AVP 100 a=rtpmap:100 VP8/90000 a=fmtp:100 max-fr=30;max-fs=8040 a=sqn: 0 a=cdsc: 1 video RTP/AVP 100 a=cpar: a=rtcp-mux m=video 3456 RTP/AVP 101 a=rtpmap:101 VP8/90000 a=fmtp:100 max-fr=15;max-fs=1200 a=cdsc: 2 video RTP/AVP 101 a=cpar: a=rtcp-mux In the above example, the category IDENTICAL is inherited by the cpar encapsulated rtcp-mux attribute. 4.7. Category: IDENTICAL-PER-PT The attributes in the IDENTICAL-PER-PT category define the RTP payload configuration on per Payload Type basis and MUST have identical values across all the media descriptions for a given RTP Payload Type when repeated. These Payload Types identify the same codec configuration as defined in the Section 10.1.2 of [I-D.ietf-mmusic-sdp-bundle-negotiation] under this context. In the SDP example below, Payload Types 96 and 97 are repeated across all the video "m=" lines and all the payload specific parameters (ex: rtpmap, fmtp) are identical (Note: some line breaks included are due to formatting only). Nandakumar Expires February 28, 2021 [Page 11] Internet-Draft SDP Attribute Multiplexing August 2020 v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=group:BUNDLE cam1 cam2 m=video 96 97 a=mid:cam1 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42400d; max-fs=3600; max-fps=3000; max-mbps=108000; max-br=1000 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42400a; max-fs=240; max-fps=3000; max-mbps=7200; max-br=200 m=video 96 97 a=mid:cam2 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42400d; max-fs=3600; max-fps=3000; max-mbps=108000; max-br=1000 a=rtpmap:97 H264/90000 a=fmtp:97 profile-level-id=42400a; max-fs=240; max-fps=3000; max-mbps=7200; max-br=200 4.8. Category: SPECIAL For the attributes in the SPECIAL category, the text in the specification defining the attribute MUST be consulted for further handling when multiplexed. As an exampe, for the attribute extmap [RFC5285], the specification defining the extension needs to be referred to understand the multiplexing implications. 4.9. Category: TBD The attributes in the TBD category have not been analyzed under the proposed multiplexing framework and SHOULD NOT be multiplexed. 5. Analysis of Existing Attributes This section analyzes attributes listed in [IANA], grouped under the IETF document that defines them. The "Level" column indicates whether the attribute is currently specified as: o S -- Session level Nandakumar Expires February 28, 2021 [Page 12] Internet-Draft SDP Attribute Multiplexing August 2020 o M -- Media level o B -- Both (Implies either a session level or a media level attribute) o SR -- Source-level (for a single SSRC) [RFC5576] The "Mux Category" column identifies multiplexing category assigned per attribute and the "Notes" column captures additional informative details regarding the assigned category, wherever necessary. 5.1. RFC4566: SDP [RFC4566] defines SDP that is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. +----------------+-----------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +----------------+-----------------------+-------+------------------+ | sendrecv | Not impacted | B | NORMAL | | | | | | | sendonly | Not impacted | B | NORMAL | | | | | | | recvonly | Not impacted | B | NORMAL | | | | | | | inactive | Not impacted | B | NORMAL | | | | | | | cat | Not impacted | S | NORMAL | | | | | | | ptime | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | maxptime | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | orient | Not Impacted | M | NORMAL | | | | | | | framerate | The attribute value | M | IDENTICAL-PER- | | | MUST be same for a | | PT | | | given codec | | | | | configuration | | | | | | | | | quality | Not Impacted | M | NORMAL | Nandakumar Expires February 28, 2021 [Page 13] Internet-Draft SDP Attribute Multiplexing August 2020 | | | | | | rtpmap | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | fmtp | The attribute value | M | IDENTICAL-PER-PT | | | MUST be same for a | | | | | given codec | | | | | configuration | | | | | | | | | keywds | Not impacted | S | NORMAL | | | | | | | type | Not Impacted | S | NORMAL | | | | | | | type:broadcast | Not Impacted | S | NORMAL | | | | | | | type:H332 | Not Impacted | S | NORMAL | | | | | | | type:meeting | Not Impacted | S | NORMAL | | | | | | | type:moderated | Not Impacted | S | NORMAL | | | | | | | type:test | Not Impacted | S | NORMAL | | | | | | | tool | Not Impacted | S | NORMAL | | | | | | | charset | Not Impacted | S | NORMAL | | | | | | | sdplang | Not Impacted | B | NORMAL | | | | | | | lang | Not Impacted | B | NORMAL | | | | | | +----------------+-----------------------+-------+------------------+ 5.1 RFC4566 Attribute Analysis 5.2. RFC4585: RTP/AVPF [RFC4585] defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. Nandakumar Expires February 28, 2021 [Page 14] Internet-Draft SDP Attribute Multiplexing August 2020 +---------+------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------+------------------------------+-------+------------------+ | rtcp- | Since RTCP feedback | M | IDENTICAL-PER- | | fb | attributes are Payload Type | | PT | | | (PT) scoped, their values | | | | | MUST be identical for a | | | | | given PT across the | | | | | multiplexed "m=" lines. | | | | | | | | +---------+------------------------------+-------+------------------+ 5.2 RFC4585 Attribute Analysis 5.3. RFC5761: Multiplexing RTP and RTCP [RFC5761] discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It describes when such multiplexing is and is not appropriate, and it explains how the SDP can be used to signal multiplexed sessions. +----------+------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +----------+------------------------------------+-------+-----------+ | rtcp- | RTP and RTCP Multiplexing affects | M | IDENTICAL | | mux | the entire RTP session | | | | | | | | +----------+------------------------------------+-------+-----------+ 5.3 RFC5761 Attribute Analysis 5.4. RFC3312: Integration of Resource Management and SIP [RFC3312] defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. Nandakumar Expires February 28, 2021 [Page 15] Internet-Draft SDP Attribute Multiplexing August 2020 +-------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------+-----------------------+-------+--------------+ | des | Refer to notes below | M | CAUTION | | | | | | | conf | Refer to notes below | M | CAUTION | | | | | | | curr | Refer to notes below | M | CAUTION | | | | | | +-------+-----------------------+-------+--------------+ 5.4 RFC3312 Attribute Analysis NOTE: A mismatched set of preconditions across media descriptions results in Session establishment failures due to inability to meet right resource reservations requested. 5.5. RFC4574: SDP Label Attribute [RFC4574] defines a new SDP media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. +--------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------+---------------+-------+--------------+ | label | Not Impacted | M | NORMAL | | | | | | +--------+---------------+-------+--------------+ 5.5 RFC4574 Attribute Analysis 5.6. RFC5432: QOS Mechanism Selection in SDP [RFC5432] defines procedures to negotiate QOS mechanisms using the SDP offer/answer model. Nandakumar Expires February 28, 2021 [Page 16] Internet-Draft SDP Attribute Multiplexing August 2020 +----------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------------+-----------------------+-------+--------------+ | qos-mech-send | Refer to Section 10 | B | TRANSPORT | | | | | | | qos-mech-recv | Refer to Section 10 | B | TRANSPORT | | | | | | +----------------+-----------------------+-------+--------------+ 5.6 RFC5432 Attribute Analysis 5.7. RFC4568: SDP Security Descriptions [RFC4568] defines a SDP cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. +--------+--------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +--------+--------------------------------------+-------+-----------+ | crypto | crypto attribute MUST be the one | M | TRANSPORT | | | that corresponds to the "m=" line | | | | | chosen for setting up the underlying | | | | | transport flow | | | | | | | | +--------+--------------------------------------+-------+-----------+ 5.7 RFC4568 Attribute Analysis 5.8. RFC5762: RTP over DCCP RTP is a widely used transport for real-time multimedia on IP networks. DCCP is a transport protocol that provides desirable services for real-time applications. [RFC5762] specifies a mapping of RTP onto DCCP, along with associated signaling, such that real- time applications can make use of the services provided by DCCP. Nandakumar Expires February 28, 2021 [Page 17] Internet-Draft SDP Attribute Multiplexing August 2020 +-------------------+--------------------------+---------+----------+ | Name | Notes | Current | Mux | | | | | Category | +-------------------+--------------------------+---------+----------+ | dccp-service- | If RFC6773 is not being | M | CAUTION | | code | used in addition to | | | | | RFC5762, the port in the | | | | | "m=" line is a DCCP | | | | | port. DCCP being a | | | | | connection oriented | | | | | protocol does not allow | | | | | multiple connections on | | | | | the same 5-tuple | | | | | | | | +-------------------+--------------------------+---------+----------+ 5.8 RFC5762 Attribute Analysis NOTE: If RFC6773 is being used in addition to RFC5762 and provided that DCCP-in-UDP layer has additional demultiplexing, then it can be possible to use different DCCP service codes for each DCCP flow, given each uses a different DCCP port. Although doing so might conflict with the media type of the "m=" line. None of this is standardized yet and it wouldn't work as explained. Hence performing multiplexing is not recommended even in this alternate scenario. 5.9. RFC6773: DCCP-UDP Encapsulation [RFC6773] specifies an alternative encapsulation of DCCP, referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middle boxes without modification of those middle boxes. +-----------+------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+------------------------------------+-------+----------+ | dccp- | Multiplexing is not recommended | M | CAUTION | | port | due to potential conflict between | | | | | the port used for DCCP | | | | | en/decapsulation and the RTP | | | | | | | | +-----------+------------------------------------+-------+----------+ 5.9 RFC6773 Attribute Analysis NOTE: RFC6773 is about tunneling DCCP in UDP, with the UDP port being the port of the DCCP en-/de-capsulation service. This encapsulation Nandakumar Expires February 28, 2021 [Page 18] Internet-Draft SDP Attribute Multiplexing August 2020 allows arbitrary DCCP packets to be encapsulated and the DCCP port chosen can conflict with the port chosen for the RTP traffic. For multiplexing several DCCP-in-UDP encapsulations on the same UDP port with no RTP traffic on the same port implies collapsing several DCCP port spaces together. This can or cannot work depending on the nature of DCCP encapsulation and ports choices thus rendering it to be very application dependent. 5.10. RFC5506: Reduced-Size RTCP in RTP Profile [RFC5506] discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. +------------+----------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +------------+----------------------------------+-------+-----------+ | rtcp- | Reduced size RTCP affects the | M | IDENTICAL | | rsize | entire RTP session | | | | | | | | +------------+----------------------------------+-------+-----------+ 5.10 RFC5506 Attribute Analysis 5.11. RFC6787: Media Resource Control Protocol Version 2 The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the SIP, to coordinate MRCPv2 clients and servers, and manage session between them, and SDP to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [RFC6787] defines attributes for this purpose. Nandakumar Expires February 28, 2021 [Page 19] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------+---------------+-------+--------------+ | resource | Not Impacted | M | NORMAL | | | | | | | channel | Not Impacted | M | NORMAL | | | | | | | cmid | Not Impacted | M | NORMAL | | | | | | +-----------+---------------+-------+--------------+ 5.11 RFC6787 Attribute Analysis 5.12. RFC5245: ICE [RFC5245] describes a protocol for NAT traversal for UDP-based multimedia sessions established with the offer/answer model. ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the SIP. Nandakumar Expires February 28, 2021 [Page 20] Internet-Draft SDP Attribute Multiplexing August 2020 +-------------------+---------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-------------------+---------------------------+-------+-----------+ | ice-lite | Not Impacted | S | NORMAL | | | | | | | ice-options | Not Impacted | S | NORMAL | | | | | | | ice-mismatch | Not Impacted | S | NORMAL | | | | | | | ice-pwd | ice-pwd MUST be the one | B | TRANSPORT | | | that corresponds to the | | | | | "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | ice-ufrag | ice-ufrag MUST be the one | B | TRANSPORT | | | that corresponds to the | | | | | "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | candidate | ice candidate MUST be the | M | TRANSPORT | | | one that corresponds to | | | | | the "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | remote- | ice remote candidate MUST | M | TRANSPORT | | candidates | be the one that | | | | | corresponds to the "m=" | | | | | line chosen for setting | | | | | up the underlying | | | | | transport flow | | | | | | | | +-------------------+---------------------------+-------+-----------+ 5.12 RFC5245 Attribute Analysis 5.13. RFC5285: RTP Header Extensions [RFC5285] provides a general mechanism to use the header extension feature of RTP. It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. Nandakumar Expires February 28, 2021 [Page 21] Internet-Draft SDP Attribute Multiplexing August 2020 +--------+---------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +--------+---------------------------------------+-------+----------+ | extmap | Refer to the document defining the | B | SPECIAL | | | specific RTP Extension | | | | | | | | +--------+---------------------------------------+-------+----------+ 5.13 RFC5285 Attribute Analysis 5.14. RFC3605: RTCP attribute in SDP Originally, SDP assumed that RTP and RTCP were carried on consecutive ports. However, this is not always true when NATs are involved. [RFC3605] specifies an early mechanism to indicate the RTCP port. +------+----------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +------+----------------------------------------+-------+-----------+ | rtcp | RTCP Port MUST be the one that | M | TRANSPORT | | | corresponds to the "m=" line chosen | | | | | for setting up the underlying | | | | | transport flow. | | | | | | | | +------+----------------------------------------+-------+-----------+ 5.14 RFC3605 Attribute Analysis 5.15. RFC5576: Source-Specific SDP Attributes [RFC5576] defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. Nandakumar Expires February 28, 2021 [Page 22] Internet-Draft SDP Attribute Multiplexing August 2020 +---------------+------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------------+------------------------+-------+------------------+ | ssrc | Refer to Notes below | M | NORMAL | | | | | | | ssrc-group | Refer to Section 9 for | M | NORMAL | | | specific analysis of | | | | | the grouping | | | | | semantics | | | | | | | | | cname | Not Impacted | SR | NORMAL | | | | | | | previous- | Refer to notes below | SR | NORMAL | | ssrc | | | | | | | | | | fmtp | The attribute value | SR | IDENTICAL-PER- | | | MUST be same for a | | PT | | | given codec | | | | | configuration | | | | | | | | +---------------+------------------------+-------+------------------+ 5.15 RFC5576 Attribute Analysis NOTE: If SSRCs are repeated across "m=" lines being multiplexed, they MUST all represent the same underlying RTP Source. 5.16. RFC7273: RTP Clock Source Signalling [RFC7273] specifies SDP signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session. Nandakumar Expires February 28, 2021 [Page 23] Internet-Draft SDP Attribute Multiplexing August 2020 +--------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+---------------+-------+--------------+ | ts-refclk | Not Impacted | B | NORMAL | | | | | | | mediaclk | Not Impacted | B | NORMAL | | | | | | | ts-refclk:ntp | Not Impacted | B | NORMAL | | | | | | | ts-refclk:ptp | Not Impacted | B | NORMAL | | | | | | | ts-refclk:gps | Not Impacted | B | NORMAL | | | | | | | ts-refclk:gal | Not Impacted | B | NORMAL | | | | | | | ts-refclk:glonass | Not Impacted | B | NORMAL | | | | | | | ts-refclk:local | Not Impacted | B | NORMAL | | | | | | | ts-refclk:private | Not Impacted | B | NORMAL | | | | | | | mediaclk:sender | Not Impacted | B | NORMAL | | | | | | | mediaclk:direct | Not Impacted | B | NORMAL | | | | | | | mediaclk:IEEE1722 | Not Impacted | B | NORMAL | | | | | | +--------------------+---------------+-------+--------------+ 5.16 RFC7273 Attribute Analysis 5.17. RFC6236: Image Attributes in SDP [RFC6236] proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. Nandakumar Expires February 28, 2021 [Page 24] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------+----------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +-----------+----------------------------+-------+------------------+ | imageattr | The attribute value MUST | M | IDENTICAL-PER- | | | be same for a given codec | | PT | | | configuration | | | | | | | | +-----------+----------------------------+-------+------------------+ 5.17 RFC6236 Attribute Analysis 5.18. RFC7197: Duplication Delay Attribute in SDP [RFC7197] defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in SDP. +--------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+---------------+-------+--------------+ | duplication-delay | Not Impacted | B | NORMAL | | | | | | +--------------------+---------------+-------+--------------+ 5.18 RFC7197 Attribute Analysis 5.19. RFC7266: RTCP XR Blocks for MOS Metric Reporting [RFC7266] defines an RTCP Extended Report (XR) Block including two new segment types and associated SDP parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications. +-------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------+---------------+-------+--------------+ | calgextmap | Not Impacted | B | NORMAL | | | | | | +-------------+---------------+-------+--------------+ 5.19 RFC7266 Attribute Analysis 5.20. RFC6285: Rapid Acquisition of Multicast RTP Sessions [RFC6285] describes a method using the existing RTP and RTCP machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate Nandakumar Expires February 28, 2021 [Page 25] Internet-Draft SDP Attribute Multiplexing August 2020 to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. +---------------+------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------------+------------------+-------+--------------+ | rams-updates | Not recommended | M | CAUTION | | | | | | +---------------+------------------+-------+--------------+ 5.20 RFC6285 Attribute Analysis 5.21. RFC6230: Media Control Channel Framework [RFC6230] describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses SIP to establish an application-level control mechanism between application servers and associated external servers such as media servers. +---------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------+---------------+-------+--------------+ | cfw-id | Not Impacted | M | NORMAL | | | | | | +---------+---------------+-------+--------------+ 5.21 RFC6230 Attribute Analysis 5.22. RFC6364: SDP Elements for FEC Framework [RFC6364] specifies the use of SDP to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. Nandakumar Expires February 28, 2021 [Page 26] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------------+------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+------------------------------+-------+----------+ | fec-source- | Refer to the document | M | SPECIAL | | flow | defining specific FEC | | | | | Scheme | | | | | | | | | fec-repair- | Refer to the document | M | SPECIAL | | flow | defining specific FEC | | | | | Scheme | | | | | | | | | repair-window | Refer to the document | M | SPECIAL | | | defining specific FEC | | | | | Scheme | | | | | | | | +-----------------+------------------------------+-------+----------+ 5.22 RFC6364 Attribute Analysis 5.23. RFC4796: Content Attribute [RFC4796] defines a new SDP media-level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. +----------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+---------------+-------+--------------+ | content | Not Impacted | M | NORMAL | | | | | | +----------+---------------+-------+--------------+ 5.23 RFC4796 Attribute Analysis 5.24. RFC3407: SDP Simple Capability Declaration [RFC3407] defines a set of SDP attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Nandakumar Expires February 28, 2021 [Page 27] Internet-Draft SDP Attribute Multiplexing August 2020 +----------+------------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+------------------------+-------+--------------+ | sqn | Not Impacted | B | NORMAL | | | | | | | cdsc | Not Impacted. | B | NORMAL | | | | | | | cpar | Refer to Section 14 | B | INHERIT | | | | | | | cparmin | Refer to notes below | B | SPECIAL | | | | | | | cparmax | Refer to notes below | B | SPECIAL | | | | | | +----------+------------------------+-------+--------------+ 5.24 RFC3407 Attribute Analysis NOTE: The attributes (a=cparmin and a=cparmax) define minimum and maximum numerical values associated with the attributes described in a=cpar. Since the cpar attribute can either define a 'b=' attribute or any 'a=' attribute, the multiplexing category depends on actual attribute being encapsulated and the implications of the numerical values assigned. Hence it is recommended to consult the specification defining attributes (cparmin/cparmax) to further analyze their behavior under multiplexing. 5.25. RFC6284: Port Mapping between Unicast and Multicast RTP Sessions [RFC6284] presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. +-----------------+------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+------------------------------+-------+----------+ | portmapping- | Not recommended, if port | M | CAUTION | | req | mapping is required by the | | | | | application | | | | | | | | +-----------------+------------------------------+-------+----------+ 5.25 RFC6284 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 28] Internet-Draft SDP Attribute Multiplexing August 2020 5.26. RFC6714: MSRP-CEMA [RFC6714] defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is optional. The extension allows middle boxes to anchor the MSRP connection, without the need for middle boxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middle boxes are deployed. This document also defines a SDP attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. +------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+-----------------------+-------+--------------+ | msrp-cema | Refer to notes below | M | TBD | | | | | | +------------+-----------------------+-------+--------------+ 5.26 RFC6714 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing MRSP flows over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for the attributes in this section could be revisited. 5.27. RFC4583: SDP Format for BFCP Streams [RFC4583] document specifies how to describe Binary Floor Control Protocol (BFCP) streams in SDP descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. +------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+-----------------------+-------+--------------+ | floorctrl | Refer to notes below | M | TBD | | | | | | | confid | Not Impacted | M | NORMAL | | | | | | | userid | Not Impacted | M | NORMAL | | | | | | | floorid | Not Impacted | M | NORMAL | | | | | | +------------+-----------------------+-------+--------------+ 5.27 RFC4583 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 29] Internet-Draft SDP Attribute Multiplexing August 2020 NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing BFCP streams over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for the attributes in this section could be revisited. 5.28. RFC5547: SDP Offer/Answer for File Transfer [RFC5547] provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the SDP offer/answer model specified in [RFC3264]. +-------------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------------+-----------------------+-------+--------------+ | file-selector | Refer to notes below | M | TBD | | | | | | | file-transfer-id | Refer to notes below | M | TBD | | | | | | | file-disposition | Refer to notes below | M | TBD | | | | | | | file-date | Refer to notes below | M | TBD | | | | | | | file-icon | Refer to notes below | M | TBD | | | | | | | file-range | Refer to notes below | M | TBD | | | | | | +-------------------+-----------------------+-------+--------------+ 5.28 RFC5547 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing MRSP flows over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for attributes in this section could be revisited. 5.29. RFC6849: SDP and RTP Media Loopback Extension [RFC6849] adds new SDP media types and attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced Voice over IP (VoIP), Real-time Text, and Video over IP performance metrics. Nandakumar Expires February 28, 2021 [Page 30] Internet-Draft SDP Attribute Multiplexing August 2020 +--------------------+-------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +--------------------+-------------------+-------+------------------+ | loopback rtp-pkt- | The attribute | M | IDENTICAL-PER- | | loopback | value MUST be | | PT | | | same for a given | | | | | codec | | | | | configuration | | | | | | | | | loopback rtp- | The attribute | M | IDENTICAL-PER- | | media-loopback | value MUST be | | PT | | | same for a given | | | | | codec | | | | | configuration | | | | | | | | | loopback-source | Not Impacted | M | NORMAL | | | | | | | loopback-mirror | Not Impacted | M | NORMAL | | | | | | +--------------------+-------------------+-------+------------------+ 5.29 RFC6849 Analysis 5.30. RFC5760: RTCP with Unicast Feedback [RFC5760] specifies an extension to RTCP to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. +--------------+--------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +--------------+--------------------------------+-------+-----------+ | rtcp- | The attribute MUST be reported | M | IDENTICAL | | unicast | across all "m=" lines | | | | | multiplexed | | | | | | | | +--------------+--------------------------------+-------+-----------+ 5.30 RFC5760 Attribute Analysis 5.31. RFC3611: RTCP XR [RFC3611] defines the Extended Report (XR) packet type for RTCP, and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). Nandakumar Expires February 28, 2021 [Page 31] Internet-Draft SDP Attribute Multiplexing August 2020 +----------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+---------------+-------+--------------+ | rtcp-xr | Not Impacted | B | NORMAL | | | | | | +----------+---------------+-------+--------------+ 5.31 RFC3611 Attribute Analysis 5.32. RFC5939: SDP Capability Negotiation [RFC5939] defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. +---------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------+-----------------------+-------+--------------+ | pcfg | Refer to Section 14 | M | SPECIAL | | | | | | | acfg | Refer to Section 14 | M | SPECIAL | | | | | | | csup | Not Impacted | B | NORMAL | | | | | | | creq | Not Impacted | B | NORMAL | | | | | | | acap | Refer to Section 14 | B | INHERIT | | | | | | | tcap | Refer to Section 14 | B | INHERIT | | | | | | | cap-v0 | Not Impacted | B | NORMAL | | | | | | +---------+-----------------------+-------+--------------+ 5.32 RFC5939 Attribute Analysis 5.33. RFC6871: SDP Media Capabilities Negotiation SDP capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. [RFC6871] extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. Nandakumar Expires February 28, 2021 [Page 32] Internet-Draft SDP Attribute Multiplexing August 2020 +---------+-----------------------+-------+-------------------+ | Name | Notes | Level | Mux Category | +---------+-----------------------+-------+-------------------+ | rmcap | Refer to Section 14 | B | IDENTICAL-PER-PT | | | | | | | omcap | Not Impacted | B | NORMAL | | | | | | | mfcap | Refer to Section 14 | B | IDENTICAL-PER-PT | | | | | | | mscap | Refer to Section 14 | B | INHERIT | | | | | | | lcfg | Refer to Section 14 | B | SPECIAL | | | | | | | sescap | Refer to notes below | S | CAUTION | | | | | | | med-v0 | Not Impacted | S | NORMAL | | | | | | +---------+-----------------------+-------+-------------------+ 5.33 RFC6871 - Attribute Analysis NOTE: The "sescap" attribute is not recommended for use with multiplexing. The reason is that it requires the use of unique configuration numbers across the entire SDP (per [RFC6871]) as opposed to within a media description only (per [RFC5939]). As described in Section 14, the use of identical configuration numbers between multiplexed (bundled) media descriptions is the default way of indicating compatible configurations in a bundle. 5.34. RFC7006: Miscellaneous Capabilities Negotiation SDP [RFC7006] extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media). Nandakumar Expires February 28, 2021 [Page 33] Internet-Draft SDP Attribute Multiplexing August 2020 +---------+-------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +---------+-------------------------------------+-------+-----------+ | bcap | Inherit the category SUM as | B | INHERIT | | | applicable to b= attribute | | | | | | | | | bcap-v0 | Not Impacted | B | NORMAL | | | | | | | ccap | The connection address type MUST be | B | IDENTICAL | | | identical across all the | | | | | multiplexed "m=" lines | | | | | | | | | ccap-v0 | Not Impacted | B | NORMAL | | | | | | | icap | Not Impacted | B | NORMAL | | | | | | | icap-v0 | Not Impacted | B | NORMAL | | | | | | +---------+-------------------------------------+-------+-----------+ 5.34 RFC7006 - Attribute Analysis 5.35. RFC4567: Key Management Extensions for SDP and RTSP [RFC4567] defines general extensions for SDP and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. +----------+------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +----------+------------------------------------+-------+-----------+ | key- | Key management protocol MUST be | B | IDENTICAL | | mgmt | identical across all the "m=" | | | | | lines | | | | | | | | | mikey | Key management protocol MUST be | B | IDENTICAL | | | identical across all the "m=" | | | | | lines | | | | | | | | +----------+------------------------------------+-------+-----------+ 5.35 RFC4567 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 34] Internet-Draft SDP Attribute Multiplexing August 2020 5.36. RFC4572: Comedia over TLS in SDP [RFC4572] specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using SDP. It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. +-------------+---------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-------------+---------------------------------+-------+-----------+ | fingerprint | fingerprint value MUST be the | B | TRANSPORT | | | one that corresponds to the | | | | | "m=" line chosen for setting up | | | | | the underlying transport flow | | | | | | | | +-------------+---------------------------------+-------+-----------+ 5.36 RFC4572 Attribute Analysis 5.37. RFC4570: SDP Source Filters [RFC4570] describes how to adapt SDP to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source- filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. +---------------+-------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +---------------+-------------------------------+-------+-----------+ | source- | The attribute MUST be | B | IDENTICAL | | filter | repeated across all "m=" | | | | | lines multiplexed | | | | | | | | +---------------+-------------------------------+-------+-----------+ 5.37 RFC4570 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 35] Internet-Draft SDP Attribute Multiplexing August 2020 5.38. RFC6128: RTCP Port for Multicast Sessions SDP has an attribute that allows RTP applications to specify an address and a port associated with the RTCP traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. [RFC6128] removes this restriction by introducing a new SDP attribute. +----------------+------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +----------------+------------------------------+-------+-----------+ | multicast- | Multicast RTCP port MUST be | B | IDENTICAL | | rtcp | identical across all the | | | | | "m=" lines | | | | | | | | +----------------+------------------------------+-------+-----------+ 5.38 RFC6128 Attribute Analysis 5.39. RFC6189: ZRTP [RFC6189] defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast SRTP sessions for (VoIP applications. +-----------+-----------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+-----------------------------------+-------+-----------+ | zrtp- | zrtp-hash attribute MUST be the | M | TRANSPORT | | hash | one that corresponds to the "m=" | | | | | line chosen for setting up the | | | | | underlying transport flow | | | | | | | | +-----------+-----------------------------------+-------+-----------+ 5.39 RFC6189 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 36] Internet-Draft SDP Attribute Multiplexing August 2020 5.40. RFC4145: Connection-Oriented Media [RFC4145] describes how to express media transport over TCP using SDP. It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. +------------+----------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +------------+----------------------------------+-------+-----------+ | setup | The setup attribute MUST be the | B | TRANSPORT | | | one that corresponds to the "m=" | | | | | line chosen for setting up the | | | | | underlying transport flow. | | | | | | | | | connection | The connection attribute MUST be | B | TRANSPORT | | | the one that corresponds to the | | | | | "m=" line chosen for setting up | | | | | the underlying transport flow. | | | | | | | | +------------+----------------------------------+-------+-----------+ 5.40 RFC4145 Attribute Analysis 5.41. RFC6947: The SDP altc Attribute [RFC6947] proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax. +------+----------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +------+----------------------------------------+-------+-----------+ | altc | The IP Address and port MUST be the | M | TRANSPORT | | | one that corresponds to the "m=" line | | | | | chosen for setting up the underlying | | | | | transport flow | | | | | | | | +------+----------------------------------------+-------+-----------+ 5.41 RFC6947 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 37] Internet-Draft SDP Attribute Multiplexing August 2020 5.42. RFC7195: SDP Extension for Circuit Switched Bearers in PSTN [RFC7195] describes use cases, requirements, and protocol extensions for using SDP offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). +-------------------------+-------------------+-------+-------------+ | Name | Notes | Level | Mux | | | | | Category | +-------------------------+-------------------+-------+-------------+ | cs- | Refer to notes | M | TBD | | correlation:callerid | below | | | | | | | | | cs-correlation:uuie | Refer to notes | M | TBD | | | below | | | | | | | | | cs-correlation:dtmf | Refer to notes | M | TBD | | | below | | | | | | | | | cs- | Refer to notes | M | TBD | | correlation:external | below | | | | | | | | +-------------------------+-------------------+-------+-------------+ 5.42 RFC7195 Attribute Analysis NOTE: [RFC7195] defines SDP attributes for establishing audio and video media streams over circuit-switched bearers by defining a new nettype value "PSTN". However, section 7.2 of [I-D.ietf-mmusic-sdp-bundle-negotiation] requires the "c=" line nettype value of "IN". If in future there exists a specification that defines procedures to multiplex media streams over nettype "PSTN", the multiplexing categories for attributes in this section could be revisited. 5.43. RFC7272: IDMS Using the RTP Control Protocol (RTCP) [RFC7272] defines a new RTCP Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). Nandakumar Expires February 28, 2021 [Page 38] Internet-Draft SDP Attribute Multiplexing August 2020 +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | rtcp-idms | Not Impacted | M | NORMAL | | | | | | +------------+---------------+-------+--------------+ 5.43 RFC7272 Attribute Analysis 5.44. RFC5159: Open Mobile Alliance (OMA) Broadcast (BCAST) SDP Attributes [RFC5159] provides descriptions of SDP attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. +--------------------+-----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+-----------------------+-------+--------------+ | bcastversion | Not Impacted | S | NORMAL | | | | | | | stkmstream | Not Impacted | B | NORMAL | | | | | | | SRTPAuthentication | Needs further | M | TBD | | | analysis | | | | | | | | | SRTPROCTxRate | Needs further | M | TBD | | | analysis | | | | | | | | +--------------------+-----------------------+-------+--------------+ 5.44 RFC5159 Attribute Analysis 5.45. RFC6193: Media Description for IKE in SDP [RFC6193] specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of SDP so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. Nandakumar Expires February 28, 2021 [Page 39] Internet-Draft SDP Attribute Multiplexing August 2020 +------------------+-----------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------------------+-----------------------------+-------+----------+ | ike-setup | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | | psk-fingerprint | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | | ike-esp | Unlikely to use IKE in the | B | CAUTION | | | context of multiplexing | | | | | | | | | ike-esp- | Unlikely to use IKE in the | B | CAUTION | | udpencap | context of multiplexing | | | | | | | | +------------------+-----------------------------+-------+----------+ 5.45 RFC6193 Attribute Analysis 5.46. RFC2326: Real Time Streaming Protocol The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. +---------+-------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +---------+-------------------------------------+-------+-----------+ | etag | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | | range | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | | control | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | | mtag | RTSP is not supported for RTP | B | CAUTION | | | Stream multiplexing | | | | | | | | +---------+-------------------------------------+-------+-----------+ 5.46 RFC2326 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 40] Internet-Draft SDP Attribute Multiplexing August 2020 NOTE: [RFC2326] defines SDP attributes that are applicable in the declarative usage of SDP alone. For purposes of this document, only the Offer/Answer usage of SDP is considered as mandated by [I-D.ietf-mmusic-sdp-bundle-negotiation]. 5.47. RFC6064: SDP and RTSP Extensions for 3GPP The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. [RFC6064] provides information about these extensions and registers the RTSP and SDP extensions with IANA. +--------------------------------+---------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +--------------------------------+---------------+-------+----------+ | X-predecbufsize | Refer to | M | CAUTION | | | notes below | | | | | | | | | X-initpredecbufperiod | Refer to | M | CAUTION | | | notes below | | | | | | | | | X-initpostdecbufperiod | Refer to | M | CAUTION | | | notes below | | | | | | | | | X-decbyterate | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3gpp-videopostdecbufsize | Refer to | M | CAUTION | | | notes below | | | | | | | | | framesize | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3GPP-Integrity-Key | Refer to | S | CAUTION | | | notes below | | | | | | | | | 3GPP-SDP-Auth | Refer to | S | CAUTION | | | notes below | | | | | | | | | 3GPP-SRTP-Config | Refer to | M | CAUTION | | | notes below | | | | | | | | | alt | Refer to | M | CAUTION | | | notes below | | | | | | | | | alt-default-id | Refer to | M | CAUTION | | | notes below | | | Nandakumar Expires February 28, 2021 [Page 41] Internet-Draft SDP Attribute Multiplexing August 2020 | | | | | | alt-group | Refer to | S | CAUTION | | | notes below | | | | | | | | | 3GPP-Adaptation-Support | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3GPP-Asset-Information | Refer to | B | CAUTION | | | notes below | | | | | | | | | mbms-mode | Refer to | B | CAUTION | | | notes below | | | | | | | | | mbms-flowid | Refer to | M | CAUTION | | | notes below | | | | | | | | | mbms-repair | Refer to | B | CAUTION | | | notes below | | | | | | | | | 3GPP-QoE-Metrics | Refer to | M | CAUTION | | | notes below | | | | | | | | | 3GPP-QoE-Metrics:Corruption | Refer to | M | CAUTION | | duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Rebuffering | Refer to | M | CAUTION | | duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Initial | Refer to | M | CAUTION | | buffering duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Successive | Refer to | M | CAUTION | | loss of RTP packets | notes below | | | | | | | | | 3GPP-QoE-Metrics:Frame rate | Refer to | M | CAUTION | | deviation | notes below | | | | | | | | | 3GPP-QoE-Metrics:Jitter | Refer to | M | CAUTION | | duration | notes below | | | | | | | | | 3GPP-QoE-Metrics:Content | Refer to | B | CAUTION | | Switch Time | notes below | | | | | | | | | 3GPP-QoE-Metrics:Average Codec | Refer to | M | CAUTION | | Bitrate | notes below | | | | | | | | | 3GPP-QoE-Metrics:Codec | Refer to | M | CAUTION | | Information | notes below | | | Nandakumar Expires February 28, 2021 [Page 42] Internet-Draft SDP Attribute Multiplexing August 2020 | | | | | | 3GPP-QoE-Metrics:Buffer | Refer to | M | CAUTION | | Status | notes below | | | | | | | | +--------------------------------+---------------+-------+----------+ 5.47 RFC6064 Attribute Analysis NOTE: [RFC6064] defines SDP attributes that are applicable in the declarative usage of SDP alone. For purposes of this document, only the Offer/Answer usage of SDP is considered as mandated by [I-D.ietf-mmusic-sdp-bundle-negotiation]. 5.48. RFC3108: ATM SDP [RFC3108] describes conventions for using SDP described for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). +-----------------------+--------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------------------+--------------------+-------+--------------+ | aalType | Refer to notes | B | CAUTION | | | below | | | | eecid | Refer to notes | B | CAUTION | | | below | | | | capability | Refer to notes | B | CAUTION | | | below | | | | qosClass | Refer to notes | B | CAUTION | | | below | | | | bcob | Refer to notes | B | CAUTION | | | below | | | | stc | Refer to notes | B | CAUTION | | | below | | | | upcc | Refer to notes | B | CAUTION | | | below | | | | atmQOSparms | Refer to notes | B | CAUTION | | | below | | | | atmTrfcDesc | Refer to notes | B | CAUTION | | | below | | | | abrParms | Refer to notes | B | CAUTION | | | below | | | | abrSetup | Refer to notes | B | CAUTION | | | below | | | | bearerType | Refer to notes | B | CAUTION | | | below | | | | lij | Refer to notes | B | CAUTION | | | below | | | Nandakumar Expires February 28, 2021 [Page 43] Internet-Draft SDP Attribute Multiplexing August 2020 | anycast | Refer to notes | B | CAUTION | | | below | | | | cache | Refer to notes | B | CAUTION | | | below | | | | bearerSigIE | Refer to notes | B | CAUTION | | | below | | | | aalApp | Refer to notes | B | CAUTION | | | below | | | | cbrRate | Refer to notes | B | CAUTION | | | below | | | | sbc | Refer to notes | B | CAUTION | | | below | | | | clkrec | Refer to notes | B | CAUTION | | | below | | | | fec | Refer to notes | B | CAUTION | | | below | | | | prtfl | Refer to notes | B | CAUTION | | | below | | | | structure | Refer to notes | B | CAUTION | | | below | | | | cpsSDUsize | Refer to notes | B | CAUTION | | | below | | | | aal2CPS | Refer to notes | B | CAUTION | | | below | | | | aal2CPSSDUrate | Refer to notes | B | CAUTION | | | below | | | | aal2sscs3661unassured | Refer to notes | B | CAUTION | | | below | | | | aal2sscs3661assured | Refer to notes | B | CAUTION | | | below | | | | aal2sscs3662 | Refer to notes | B | CAUTION | | | below | | | | aal5sscop | Refer to notes | B | CAUTION | | | below | | | | atmmap | Refer to notes | B | CAUTION | | | below | | | | silenceSupp | Refer to notes | B | CAUTION | | | below | | | | ecan | Refer to notes | B | CAUTION | | | below | | | | gc | Refer to notes | B | CAUTION | | | below | | | | profileDesc | Refer to notes | B | CAUTION | | | below | | | | vsel | Refer to notes | B | CAUTION | | | below | | | | dsel | Refer to notes | B | CAUTION | | | below | | | Nandakumar Expires February 28, 2021 [Page 44] Internet-Draft SDP Attribute Multiplexing August 2020 | fsel | Refer to notes | B | CAUTION | | | below | | | | onewaySel | Refer to notes | B | CAUTION | | | below | | | | codecconfig | Refer to notes | B | CAUTION | | | below | | | | isup_usi | Refer to notes | B | CAUTION | | | below | | | | uiLayer1_Prot | Refer to notes | B | CAUTION | | | below | | | | chain | Refer to notes | B | CAUTION | | | below | | | | | | | | +-----------------------+--------------------+-------+--------------+ 5.48 RFC3108 Attribute Analysis NOTE: RFC3108 describes conventions for using SDP for characterizing ATM bearer connections using an AAL1, AAL2 or AAL5 adaptation layers. For AAL1, AAL2 and AAL5, bearer connections can be used to transport single media streams. In addition, for AAL1 and AAL2, multiple media streams can be multiplexed into a bearer connection. For all adaptation types (AAL1, AAL2 and AAL5), bearer connections can be bundled into a single media group. In all cases addressed by RFC3108, a real-time media stream (voice, video, voiceband data, pseudo-wire, and others) or a multiplex of media streams is mapped directly into an ATM connection. RFC3108 does not address cases where ATM serves as a low-level transport pipe for IP packets which in turn can carry one or more real-time (e.g. VoIP) media sessions with a life-cycle different from that of the underlying ATM transport. 5.49. 3GPP TS 26.114 [R3GPPTS26.114] specifies IP multimedia subsystem: Media handling and interaction Nandakumar Expires February 28, 2021 [Page 45] Internet-Draft SDP Attribute Multiplexing August 2020 +---------------------+--------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +---------------------+--------------------------+-------+----------+ | 3gpp_sync_info | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem | | | | | | | | | 3gpp_MaxRecvSDUSize | Usage defined for the IP | M | NORMAL | | | Multimedia Subsystem | | | | | | | | +---------------------+--------------------------+-------+----------+ 5.49 3GPP TS 26.114 Attribute Analysis 5.50. 3GPP TS 183.063 [R3GPPTS183.063] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); +---------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------------------+---------------+-------+--------------+ | PSCid | Not Impacted | S | NORMAL | | | | | | | bc_service | Not Impacted | S | NORMAL | | | | | | | bc_program | Not Impacted | S | NORMAL | | | | | | | bc_service_package | Not Impacted | S | NORMAL | | | | | | +---------------------+---------------+-------+--------------+ 5.50 3GPP TS 183.063 Attribute Analysis 5.51. 3GPP TS 24.229 [R3GPPTS24.229] specifies IP multimedia call control protocol based on Session Initial protocol and Session Description Protocol. Nandakumar Expires February 28, 2021 [Page 46] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------------+-----------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+-----------------------------+-------+-----------+ | secondary- | secondary-realm MUST be | M | TRANSPORT | | realm | the one that corresponds to | | | | | the "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | visited-realm | visited-realm MUST be the | M | TRANSPORT | | | one that corresponds to the | | | | | "m=" line chosen for | | | | | setting up the underlying | | | | | transport flow | | | | | | | | | omr-m-cksum | Not Impacted | M | NORMAL | | | | | | | omr-s-cksum | Not Impacted | M | NORMAL | | | | | | | omr-m-att | Not Impacted | M | NORMAL | | | | | | | omr-s-att | Not Impacted | M | NORMAL | | | | | | | omr-m-bw | Not Impacted | M | NORMAL | | | | | | | omr-s-bw | Not Impacted | M | NORMAL | | | | | | | omr-codecs | Not Impacted | M | NORMAL | | | | | | +-----------------+-----------------------------+-------+-----------+ 5.53 3GPP TS 24.229 Attribute Analysis 5.52. ITU T.38 [T.38] defines procedures for real-time Group 3 facsimile communications over IP networks. Nandakumar Expires February 28, 2021 [Page 47] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------------------+--------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------------------+--------------------+-------+--------------+ | T38FaxVersion | Refer to notes | M | TBD | | | below | | | | | | | | | T38MaxBitRate | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxFillBitRemoval | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxTranscodingMMR | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxTranscodingJBIG | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxRateManagement | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxMaxBuffer | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxMaxDatagram | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxUdpEC | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxMaxIFP | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxUdpECDepth | Refer to notes | M | TBD | | | below | | | | | | | | | T38FaxUdpFECMaxSpan | Refer to notes | M | TBD | | | below | | | | | | | | | T38ModemType | Refer to notes | M | TBD | | | below | | | | | | | | | T38VendorInfo | Refer to notes | M | TBD | | | below | | | | | | | | +-----------------------+--------------------+-------+--------------+ 5.54 ITU T.38 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 48] Internet-Draft SDP Attribute Multiplexing August 2020 NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing fax protocols flows over a single 5-tuple. Once such a specification is available, the multiplexing category assignments for the attributes in this section could be revisited. 5.53. ITU-T Q.1970 [Q.1970] defines Bearer Independent Call Control (BICC) IP bearer control protocol. +-------+----------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-------+----------------------------------------+-------+----------+ | ipbcp | ipbcp version identifies type of IP | S | SPECIAL | | | bearer control protocol (IPBCP) | | | | | message used in BICC (ITU-T Q.1901) | | | | | environment which are limited to | | | | | single media payload. Refer to the | | | | | pertinent ITU-T specifications while | | | | | multiplexing | | | | | | | | +-------+----------------------------------------+-------+----------+ 5.55 ITU-T Q.1970 Attribute Analysis 5.54. ITU-T H.248.15 ITU-T H.248.15 [H.248.15] defines Gateway Control Protocol SDP H.248 package attribute Nandakumar Expires February 28, 2021 [Page 49] Internet-Draft SDP Attribute Multiplexing August 2020 +----------+-------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +----------+-------------------------------------+-------+----------+ | h248item | It is only applicable for signaling | B | SPECIAL | | | the inclusion of H.248 extension | | | | | packages to a gateway via the local | | | | | and remote descriptors. The | | | | | attribute itself is unaffected by | | | | | multiplexing, but the packaged | | | | | referenced in a specific use of the | | | | | attribute can be impacted. Further | | | | | analysis of each package is needed | | | | | to determine if there is an issue. | | | | | This is only a concern in | | | | | environments using a decomposed | | | | | server/gateway with H.248 signaled | | | | | between them. The ITU-T will need | | | | | to do further analysis of various | | | | | packages when they specify how to | | | | | signal the use of multiplexing to a | | | | | gateway | | | | | | | | +----------+-------------------------------------+-------+----------+ 5.56 ITU-T H.248.15 Attribute Analysis 5.55. RFC4975: The Message Session Relay Protocol [RFC4975] the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. Nandakumar Expires February 28, 2021 [Page 50] Internet-Draft SDP Attribute Multiplexing August 2020 +----------------------+---------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------------------+---------------------+-------+--------------+ | accept-types | Refer to notes | M | TBD | | | below | | | | | | | | | accept-wrapped- | Refer to notes | M | TBD | | types | below | | | | | | | | | max-size | Refer to notes | M | TBD | | | below | | | | | | | | | path | Refer to notes | M | TBD | | | below | | | | | | | | +----------------------+---------------------+-------+--------------+ 5.57 RFC4975 Attribute Analysis NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation], there exists no publicly available specification that defines procedures for multiplexing/demultiplexing MRSP flows over a single 5-tuple. Once such a specification is available, the multiplexing categories assignments for the attributes in this section could be revisited. 5.56. Historical Attributes This section specifies analysis for the attributes that are included for historic usage alone by the [IANA]. +----------+----------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +----------+----------------------+-------+--------------+ | rtpred1 | Historic attributes | M | CAUTION | | | | | | | rtpred2 | Historic attributes | M | CAUTION | | | | | | +----------+----------------------+-------+--------------+ 5.58 Historical Attribute Analysis 6. bwtype Attribute Analysis This section specifies handling of specific bandwidth attributes when used in multiplexing scenarios. Nandakumar Expires February 28, 2021 [Page 51] Internet-Draft SDP Attribute Multiplexing August 2020 6.1. RFC4566: SDP [RFC4566] defines SDP that is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. +-----------+------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+------------------------------------+-------+----------+ | bwtype:CT | Not Impacted | S | NORMAL | | | | | | | bwtype:AS | For the media level usage, the | B | SUM | | | aggregate of individual bandwidth | | | | | values is considered | | | | | | | | +-----------+------------------------------------+-------+----------+ 6.1 RFC4566 bwtype Analysis 6.2. RFC3556: SDP Bandwidth Modifiers for RTCP Bandwidth [RFC3556] defines an extension to SDP to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTCP packets in a RTP session. +-----------+------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------+------------------------------------+-------+----------+ | bwtype:RS | Session level usage represents | B | SUM | | | session aggregate and media level | | | | | usage indicates SUM of the | | | | | individual values while | | | | | multiplexing | | | | | | | | | bwtype:RR | Session level usage represents | B | SUM | | | session aggregate and media level | | | | | usage indicates SUM of the | | | | | individual values while | | | | | multiplexing | | | | | | | | +-----------+------------------------------------+-------+----------+ 6.2 RFC3556 bwtype Analysis Nandakumar Expires February 28, 2021 [Page 52] Internet-Draft SDP Attribute Multiplexing August 2020 6.3. RFC3890: Bandwidth Modifier for SDP [RFC3890] defines SDP Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. +-------------+----------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +-------------+----------------------------------+-------+----------+ | bwtype:TIAS | The usage of TIAS is not defined | B | SPECIAL | | | under Offer/Answer usage. | | | | | | | | | maxprate | The usage of TIAS and maxprate | B | SPECIAL | | | is not well defined under | | | | | multiplexing | | | | | | | | +-------------+----------------------------------+-------+----------+ 6.3 RFC3890 bwtype Analysis NOTE: The intention of TIAS is that the media level bit-rate is multiplied with the known per-packet overhead for the selected transport and the maxprate value to determine the worst case bit-rate from the transport to more accurately capture the required usage. Summing TIAS values independently across "m=" lines and multiplying the computed sum with maxprate and the per-packet overhead would inflate the value significantly. Instead performing multiplication and adding the individual values is a more appropriate usage. 7. rtcp-fb Attribute Analysis This section analyzes rtcp-fb SDP attributes. 7.1. RFC4585: RTP/AVPF [RFC4585] defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. Nandakumar Expires February 28, 2021 [Page 53] Internet-Draft SDP Attribute Multiplexing August 2020 +---------+------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------+------------------------------+-------+------------------+ | ack | The attribute value MUST be | M | IDENTICAL-PER- | | rpsi | same for a given codec | | PT | | | configuration | | | | | | | | | ack | Feedback parameters MUST be | M | SPECIAL | | app | handled in the app specific | | | | | way when multiplexed | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | pli | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | sli | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | rpsi | same for a given codec | | PT | | | configuration | | | | | | | | | nack | Feedback parameters MUST be | M | SPECIAL | | app | handled in the app specific | | | | | way when multiplexed | | | | | | | | | trr- | The attribute value MUST be | M | IDENTICAL-PER- | | int | same for a given codec | | PT | | | configuration | | | | | | | | +---------+------------------------------+-------+------------------+ 7.1 RFC4585 Attribute Analysis 7.2. RFC5104: Codec Control Messages in AVPF [RFC5104] specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. Nandakumar Expires February 28, 2021 [Page 54] Internet-Draft SDP Attribute Multiplexing August 2020 +------+---------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +------+---------------------------------+-------+------------------+ | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | | same for a given codec | | PT | | | configuration | | | | | | | | +------+---------------------------------+-------+------------------+ 7.2 RFC5104 Attribute Analysis 7.3. RFC6285: Unicast-Based Rapid Acquisition of Multicast RTP Sessions (RAMS) [RFC6285] describes a method using the existing RTP and RTCP machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. +--------+-------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +--------+-------------------------------+-------+------------------+ | nack | The attribute value MUST be | M | IDENTICAL-PER- | | rai | same for a given codec | | PT | | | configuration | | | | | | | | +--------+-------------------------------+-------+------------------+ 7.3 RFC6285 Attribute Analysis 7.4. RFC6679: ECN for RTP over UDP/IP [RFC6679] specifies how Explicit Congestion Notification (ECN) can be used with the RTP running over UDP, using the RTCP as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a STUN extension used in the optional initialization method using ICE. Nandakumar Expires February 28, 2021 [Page 55] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------------+-----------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +-----------------+-----------------------------+-------+-----------+ | ecn-capable- | ECN markup are enabled at | M | IDENTICAL | | rtp | the RTP session level | | | | | | | | | nack ecn | This attribute enables ECN | M | IDENTICAL | | | at the RTP session level | | | | | | | | +-----------------+-----------------------------+-------+-----------+ 7.4 RFC6679 Attribute Analysis 7.5. RFC6642: Third-Party Loss Report In a large RTP session using the RTCP feedback mechanism defined in [RFC4585], a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. [RFC6642] memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signaling is also defined. +---------+------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +---------+------------------------------+-------+------------------+ | nack | The attribute value MUST be | M | IDENTICAL-PER- | | tllei | same for a given codec | | PT | | | configuration | | | | | | | | | nack | The attribute value MUST be | M | IDENTICAL-PER- | | pslei | same for a given codec | | PT | | | configuration | | | | | | | | +---------+------------------------------+-------+------------------+ 7.5 RFC6642 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 56] Internet-Draft SDP Attribute Multiplexing August 2020 7.6. RFC5104: Codec Control Messages in AVPF [RFC5104] specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. +--------+-------------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +--------+-------------------------------+-------+------------------+ | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | fir | same for a given codec | | PT | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | tmmbr | same for a given codec | | PT | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | tstr | same for a given codec | | PT | | | configuration | | | | | | | | | ccm | The attribute value MUST be | M | IDENTICAL-PER- | | vbcm | same for a given codec | | PT | | | configuration | | | | | | | | +--------+-------------------------------+-------+------------------+ 7.6 RFC5104 Attribute Analysis 8. group Attribute Analysis This section analyzes SDP "group" attribute semantics [RFC5888]. 8.1. RFC5888: SDP Grouping Framework [RFC5888] defines a framework to group "m" lines in SDP for different purposes. Nandakumar Expires February 28, 2021 [Page 57] Internet-Draft SDP Attribute Multiplexing August 2020 +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | group:LS | Not Impacted | S | NORMAL | | | | | | | group:FID | Not Impacted | S | NORMAL | | | | | | +------------+---------------+-------+--------------+ 8.1 RFC5888 Attribute Analysis 8.2. RFC3524: Mapping Media Streams to Resource Reservation Flows [RFC3524] defines an extension to the SDP grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | group:SRF | Not Impacted | S | NORMAL | | | | | | +------------+---------------+-------+--------------+ 8.2 RFC3524 Attribute Analysis 8.3. RFC4091: ANAT Semantics [RFC4091] defines ANAT semantics for the SDP grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. +-------------+------------------------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------+------------------------------+-------+--------------+ | group:ANAT | ANAT semantics is obsoleted | S | CAUTION | | | | | | +-------------+------------------------------+-------+--------------+ 8.3 RFC4091 Attribute Analysis 8.4. RFC5956: FEC Grouping Semantics in SDP [RFC5956] defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in SDP. The semantics defined in the document are to be used with the SDP Grouping Framework [RFC5888]. These semantics allow the description Nandakumar Expires February 28, 2021 [Page 58] Internet-Draft SDP Attribute Multiplexing August 2020 of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC- level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. +---------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +---------------+---------------+-------+--------------+ | group:FEC-FR | Not Impacted | S | NORMAL | | | | | | +---------------+---------------+-------+--------------+ 8.4 RFC5956 Attribute Analysis 8.5. RFC5583: Signaling Media Decoding Dependency in SDP [RFC5583] defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in SDP. This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. +-----------+----------------------------+-------+------------------+ | Name | Notes | Level | Mux Category | +-----------+----------------------------+-------+------------------+ | group:DDP | Not Impacted | S | NORMAL | | | | | | | depend | The attribute value MUST | M | IDENTICAL-PER- | | lay | be same for a given codec | | PT | | | configuration | | | | | | | | | depend | The attribute value MUST | M | IDENTICAL-PER- | | mdc | be same for a given codec | | PT | | | configuration | | | | | | | | +-----------+----------------------------+-------+------------------+ 8.5 RFC5583 Attribute Analysis 8.6. RFC7104: Duplication Grouping Semantics in the SDP [RFC7104] defines the semantics for grouping redundant streams in SDP, The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the SSRC)level are also defined in this document for RTP streams using SSRC multiplexing. Nandakumar Expires February 28, 2021 [Page 59] Internet-Draft SDP Attribute Multiplexing August 2020 +------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------+---------------+-------+--------------+ | group:DUP | Not Impacted | S | NORMAL | | | | | | +------------+---------------+-------+--------------+ 8.6 RFC7104 Attribute Analysis 9. ssrc-group Attribute Analysis This section analyzes "ssrc-group" semantics. 9.1. RFC5576: Source-Specific SDP Attributes [RFC5576] defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. +--------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +--------------------+---------------+-------+--------------+ | ssrc-group:FID | Not Impacted | SR | NORMAL | | | | | | | ssrc-group:FEC | Not Impacted | SR | NORMAL | | | | | | | ssrc-group:FEC-FR | Not Impacted | SR | NORMAL | | | | | | +--------------------+---------------+-------+--------------+ 9.1 RFC5576 Attribute Analysis 9.2. RFC7104: Duplication Grouping Semantics in the SDP [RFC7104] defines the semantics for grouping redundant streams in SDP. The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing. Nandakumar Expires February 28, 2021 [Page 60] Internet-Draft SDP Attribute Multiplexing August 2020 +-----------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-----------------+---------------+-------+--------------+ | ssrc-group:DUP | Not Impacted | SR | NORMAL | | | | | | +-----------------+---------------+-------+--------------+ 9.2 RFC7104 Attribute Analysis 10. QoS Mechanism Token Analysis This section analyzes QoS tokes specified with SDP. 10.1. RFC5432: QoS Mechanism Selection in SDP [RFC5432] defines procedures to negotiate QOS mechanisms using the SDP offer/answer model. +------+----------------------------------------+-------+-----------+ | Name | Notes | Level | Mux | | | | | Category | +------+----------------------------------------+-------+-----------+ | rsvp | rsvp attribute MUST be the one that | B | TRANSPORT | | | corresponds to the "m=" line chosen | | | | | for setting up the underlying | | | | | transport flow | | | | | | | | | nsis | rsvp attribute MUST be the one that | B | TRANSPORT | | | corresponds to the "m=" line chosen | | | | | for setting up the underlying | | | | | transport | | | | | | | | +------+----------------------------------------+-------+-----------+ 10.1 RFC5432 Attribute Analysis NOTE: A single Differentiated Services Code Point (DSCP) code point per flow being multiplexed doesn't impact multiplexing since QOS mechanisms are signaled/scoped per flow. For scenarios that involve having different DSCP code points for packets being transmitted over the same 5-tuple, issues as discussed in [RFC7657] need to be taken into consideration. 11. k= Attribute Analysis Nandakumar Expires February 28, 2021 [Page 61] Internet-Draft SDP Attribute Multiplexing August 2020 11.1. RFC4566: SDP [RFC4566] defines SDP that is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. +------+-----------------------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +------+-----------------------------------------+-------+----------+ | k= | It is not recommended to use this | S | CAUTION | | | attribute under multiplexing | | | | | | | | +------+-----------------------------------------+-------+----------+ 11.1 RFC4566 Attribute Analysis 12. content Attribute Analysis 12.1. RFC4796 [RFC4796] defines a new SDP media-level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. +------------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +------------------+---------------+-------+--------------+ | content:slides | Not Impacted | M | NORMAL | | | | | | | content:speaker | Not Impacted | M | NORMAL | | | | | | | content:main | Not Impacted | M | NORMAL | | | | | | | content:sl | Not Impacted | M | NORMAL | | | | | | | content:alt | Not Impacted | M | NORMAL | | | | | | +------------------+---------------+-------+--------------+ 12.1 RFC4796 Attribute Analysis Nandakumar Expires February 28, 2021 [Page 62] Internet-Draft SDP Attribute Multiplexing August 2020 12.2. 3GPP TS 24.182 [R3GPPTS24.182] specifies IP multimedia subsystem Custom Alerting tones +-------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------+---------------+-------+--------------+ | g.3gpp.cat | Not Impacted | M | NORMAL | | | | | | +-------------+---------------+-------+--------------+ 12.2 3GPP TS 24.182 Attribute Analysis 12.3. 3GPP TS 24.183 [R3GPPTS24.183] specifies IP multimedia subsystem Custom Ringing Signal +-------------+---------------+-------+--------------+ | Name | Notes | Level | Mux Category | +-------------+---------------+-------+--------------+ | g.3gpp.crs | Not Impacted | M | NORMAL | | | | | | +-------------+---------------+-------+--------------+ 12.3 3GPP TS 24.183 Attribute Analysis 13. Payload Formats 13.1. RFC5109: RTP Payload Format for Generic FEC [RFC5109] describes a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. Nandakumar Expires February 28, 2021 [Page 63] Internet-Draft SDP Attribute Multiplexing August 2020 +--------------------+---------------------------+-------+----------+ | Name | Notes | Level | Mux | | | | | Category | +--------------------+---------------------------+-------+----------+ | audio/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to reuse | | | | | of SSRCs | | | | | | | | | video/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to reuse | | | | | of SSRCs | | | | | | | | | text/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to reuse | | | | | of SSRCs | | | | | | | | | application/ulpfec | Not recommended for | M | CAUTION | | | multiplexing due to reuse | | | | | of SSRCs | | | | | | | | +--------------------+---------------------------+-------+----------+ 13.1 RFC5109 Payload Format Analysis 14. Multiplexing Considerations for Encapsulating Attributes This sections deals with recommendations for defining the multiplexing characteristics of the SDP attributes that encapsulate other SDP attributes/parameters. Such attributes as of today, for example, are defined in [RFC3407], [RFC5939] and [RFC6871] as part of a generic framework for indicating and negotiating transport, media, and media format related capabilities in the SDP. The behavior of such attributes under multiplexing is in turn defined by the multiplexing behavior of the attributes they encapsulate which are made known once the Offer/Answer negotiation process is completed. 14.1. RFC3407: cpar Attribute Analysis [RFC3407] capability parameter attribute (a=cpar) encapsulates b= (bandwidth) or an a= attribute. For bandwidth attribute encapsulation, the category SUM is inherited. For the case of a= attribute, the category corresponding to the SDP attribute being encapsulated is inherited. Nandakumar Expires February 28, 2021 [Page 64] Internet-Draft SDP Attribute Multiplexing August 2020 v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=video 3456 RTP/AVP 100 a=rtpmap:100 VP8/90000 a=sqn: 0 a=cdsc: 1 video RTP/AVP 100 a=cpar: a=rtcp-mux m=video 3456 RTP/AVP 101 a=rtpmap:101 VP8/90000 a=fmtp:100 max-fr=15;max-fs=1200 a=cdsc: 2 video RTP/AVP 101 a=cpar: a=rtcp-mux In the above example,the category IDENTICAL is inherited for the cpar encapsulated rtcp-mux attribute. 14.2. RFC5939 Analysis [RFC5939] defines a general SDP capability negotiation framework. It also specifies how to provide transport protocols and SDP attributes as capabilities and negotiate them using the framework. For this purpose, [RFC5939] defines the following o A set of capabilities for the session and its associated media stream components, supported by each side. The attribute ("a=acap") defines how to list an attribute name and its associated value (if any) as a capability. The attribute ("a=tcap") defines how to list transport protocols (e.g., "RTP/ AVP") as capabilities. o A set of potential configurations ("a=pcfg") provided by the offerer to indicate which combinations of those capabilities can be used for the session and its associated media stream components. Potential configurations are not ready for use until fully negotiated. They provide an alternative that MAY be used, subject to SDP capability negotiation procedures. In particular the answerer MAY choose one of the potential configurations for use as part of the current Offer/Answer exchange. o An actual configuration ("a=acfg") for the session and its associated media stream components. The actual configuration identifies the potential configuration that was negotiated for use. Use of an actual configuration does not require any further negotiation. Nandakumar Expires February 28, 2021 [Page 65] Internet-Draft SDP Attribute Multiplexing August 2020 o A negotiation process that takes the current actual and the set of potential configurations (combinations of capabilities) as input and provides the negotiated actual configurations as output. In [RFC5939] the negotiation process is done independently for each media description. 14.2.1. Recommendation: Procedures for Potential Configuration Pairing This section provides recommendations for entities generating and processing SDP under the generic capability negotiation framework as defined in [RFC5939] under the context of media stream multiplexing. These recommendations are provided for the purposes of enabling the Offerer to make sure that the generated potential configurations between the multiplexed streams can (easily) be negotiated to be consistent between those streams. In particular, the procedures aim to simplify Answerer's procedure to choose potential configurations that are consistent across all the multiplexed media descriptions. A potential configuration selects a set of attributes and parameters that become part of the media description when negotiated. When multiplexing media descriptions with potential configurations specified, there MAY be a need for coordinating this selection between multiplexed media descriptions to ensure the right multiplexing behavior. Although it is possible to analyze the various potential configurations in multiplexed media descriptions to find combinations that satisfy such constraints, it can quickly become complicated to do so. The procedures defined in [RFC5939] state that each potential configuration in the SDP has a unique configuration number, however the scope of uniqueness is limited to each media description. To make it simple for the answerer to chose valid combinations of potential configurations across media descriptions in a given bundle group, we provide a simple rule for constructing potential configurations o Let m-bundle be the set of media descriptions that form a given bundle . o Let m-bundle-pcfg be the set of media descriptions in m-bundle that include one or more potential configurations. o Each media description in m-bundle-pcfg MUST have at least one potential configuration with the same configuration number (e.g. "1"). Nandakumar Expires February 28, 2021 [Page 66] Internet-Draft SDP Attribute Multiplexing August 2020 o For each potential configuration with configuration number x in m- bundle-pcfg, the offerer MUST ensure that if the answerer chooses configuration number x in each of the media descriptions in m- bundle-pcfg, then the resulting SDP will have all multiplexing constraints satisfied for those media descriptions. o Since it is nearly impossible to define a generic mechanism for various capability extensions, this document does't provide procedures for dealing with the capability extension attributes. However, Section 14.3 provide analysis of media capability extension attributes as defined in [RFC6871]. The above allows the answerer to easily find multiplexing compatible combinations of potential configurations: The answerer simply choses a potential configuration (number) that is present in all of the media descriptions with potential configurations in the bundle. Note that it is still possible for the offerer to provide additional potential configurations with independent configuration numbers. The answerer will have to perform more complicated analysis to determine valid multiplexed combinations of those. 14.2.1.1. Example: Transport Capability Multiplexing v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=tcap:1 RTP/SAVPF a=tcap:2 RTP/SAVP a=group:BUNDLE audio video m=audio a=mid:audio a=pcfg:1 t=1 a=pcfg:2 m=video a=mid:video a=pcfg:1 t=1 a=pcfg:2 t=2 In the example above, the potential configurations that offer transport protocol capability of RTP/SAVPF has the same configuration number "1" in both the audio and video media descriptions. Nandakumar Expires February 28, 2021 [Page 67] Internet-Draft SDP Attribute Multiplexing August 2020 14.2.1.2. Example: Attribute Capability Multiplexing v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 a=acap:1 a=rtcp-mux a=acap:2 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:EcGZiNWpFJhQXdspcl1ekcmVCNWpVLcfHAwJSoj|2^20|1:32 a=group:BUNDLE audio video m=audio 49172 RTP/AVP 99 a=mid:audio a=pcfg:1 a=1 a=pcfg:2 m=video 560024 RTP/AVP 100 a=mid:video a=pcfg:1 a=1 a=pcfg:2 a=2 In the example above, the potential configuration number "1" is repeated while referring to attribute capability a=rtcp-mux, since the behavior is IDENTICAL for the attribute a=rtcp-mux under multiplexing. 14.3. RFC6871 Analysis [RFC6871] extends the capability negotiation framework described in [RFC5939] by defining media capabilities that can be used to indicate and negotiate media types and their associated format parameters. It also allows indication of latent configurations and session capabilities. 14.3.1. Recommendation: Dealing with Payload Type Numbers [RFC6871] defines a new payload type ("pt") parameter to be used with the potential, actual, and latent configuration parameters. The parameter associates RTP payload type numbers with the referenced RTP-based media format capabilities ("a=rmcap") defined in [RFC6871] and is appropriate only when the transport protocol uses RTP. This means that the same payload type number can be assigned as part of potential or actual configurations in different media descriptions in a bundle. There are rules for the usage of identical Payload Type values across multiplexed "m=" lines as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], which must be followed here as well. As described in Section 14.2.1, the use of identical configuration numbers for compatible configurations in different Nandakumar Expires February 28, 2021 [Page 68] Internet-Draft SDP Attribute Multiplexing August 2020 media descriptions that are part of the bundle provides a way to ensure that the answerer can easily pick compatible configurations here as well. 14.3.1.1. Example: Attribute Capability Under Shared Payload Type The attributes (a=rmcap, a=mfcap) follow the above recommendations under multiplexing. v=0 o=- 25678 753849 IN IP4 192.0.2.1 s= c=IN IP4 192.0.2.1 t=0 0 a=creq:med-v0 m=audio 54322 RTP/AVP 96 a=rtpmap:96 AMR-WB/16000/1 a=fmtp:96 mode-change-capability=1; max-red=220; mode-set=0,2,4,7 a=rmcap:1,3 audio AMR-WB/16000/1 a=rmcap:2 audio AMR/8000/1 a=mfcap:1,2 mode-change-capability=1 a=mfcap:3 mode-change-capability=2 a=pcfg:1 m=1 pt=1:96 a=pcfg:2 m=2 pt=2:97 a=pcfg:3 m=3 pt=3:98 m=audio 54322 RTP/AVP 96 a=rtpmap:96 AMR-WB/16000/1 a=fmtp:96 mode-change-capability=1; max-red=220; mode-set=0,2,4,7 a=rmcap:4 audio AMR/8000/1 a=rmcap:5 audio OPUS/48000/2 a=mfcap:5 minptime=40 a=mfcap:4 mode-change-capability=1 a=pcfg:1 m=4 pt=4:97 a=pcfg:4 m=5 pt=5:101 In the example above, the potential configuration number "1" is repeated when referring to media and media format capability used for the Payload Type 96. This implies that both the media capability 2 and 4 along with their media format capabilities MUST refer to the same codec configuration, as per the definition of IDENTICAL-PER-PT. Nandakumar Expires February 28, 2021 [Page 69] Internet-Draft SDP Attribute Multiplexing August 2020 14.3.2. Recommendation: Dealing with Latent Configurations [RFC6871] adds the notion of a latent configurations, which provides configuration information that may be used to guide a subsequent offer/exchange, e.g. by adding another media stream or use alternative codec combinations not currently offered. Latent configurations have configuration numbers which cannot overlap with the potential configuration numbers [RFC6871]. Supported combinations of potential and latent configurations are indicated by use of the "a=sescap" attribute, however use of this attribute is not recommended with multiplexed media, since it requires the use of unique configuration numbers across the SDP. Taken together, this means there is no well-defined way to indicate supported combinations of latent configurations, or combinations of latent and potential configurations with multiplexed media. It is still allowed to use the latent configuration attribute, however the limitations above will apply. To determine valid combinations, actual negotiation will have to be attempted subsequently instead. 15. IANA Considerations [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] Section 15.1 defines a new subregistry to be added by the IANA for identifying the initial registrations for various multiplexing categories applicable, as proposed in this document. IANA is also requested to add a new column named "Mux Category" to several of the subregistries in the "Session Description Protocol (SDP) Parameters" registry. The tables in Section 15.2 identify name of an entry in the existing subregistry and specify the value to be put in the new "Mux Category" column of the associated IANA registry. 15.1. New 'Multiplexing Categories' subregistry A new sub-registry needs to be defined called the "Multiplexing Categories", with the following registrations created initially: "NORMAL", "CAUTION", "IDENTICAL", "TRANSPORT", "SUM", "INHERIT", "IDENTICAL-PER-PT", "SPECIAL" and "TBD" as defined in this document. Initial value registration for "Multiplexing Categories". Nandakumar Expires February 28, 2021 [Page 70] Internet-Draft SDP Attribute Multiplexing August 2020 +-------------------------+-----------+ | Multiplexing Categories | Reference | +-------------------------+-----------+ | NORMAL | RFCXXXX | | CAUTION | RFCXXXX | | IDENTICAL | RFCXXXX | | TRANSPORT | RFCXXXX | | SUM | RFCXXXX | | INHERIT | RFCXXXX | | IDENTICAL-PER-PT | RFCXXXX | | SPECIAL | RFCXXXX | | TBD | RFCXXXX | +-------------------------+-----------+ Further entries can be registered using Standard Actions policies outlined in [RFC5226], which requires IESG review and approval and standards-track IETF RFC publication. Each registration needs to indicate the multiplexing category value to be added to the "Multiplexing Categories" subregistry as defined in this section. Such a registration MUST also indicate the applicability of the newly defined multiplexing category value to various subregistries defined at the "Session Description Protocol (SDP) Parameters" registry. 15.2. 'Mux Category' column for subregistries Each sub-section identifies a subregistry in the "Session Description Protocol (SDP) Parameters" registry. The tables list the column that identifies the SDP attribute name/Token/Value from the corresponding subregistries and the values to be used for the new "Mux Category" column to be added. For the entries in the existing subregistries, under the "Session Description Protocol (SDP) Parameters" registry, that lack a value for the "Mux Category" in this specification will get a value of "TBD". The registration policy for updates to the 'Mux Category' column values for existing parameters, or when registering new parameters, are beyond the scope of this document. The registration policy for the affected table is defined in [I-D.ietf-mmusic-rfc4566bis]. Nandakumar Expires February 28, 2021 [Page 71] Internet-Draft SDP Attribute Multiplexing August 2020 15.2.1. Table: SDP bwtype The following values are to be added to the 'SDP bwtype' subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +----------+--------------+ | SDP Name | Mux Category | +----------+--------------+ | CT | NORMAL | | AS | SUM | | RS | SUM | | RR | SUM | | TIAS | SPECIAL | +----------+--------------+ 15.2.2. Table: att-field (session level) The following values are to be added to the "att-field (session level)" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. Nandakumar Expires February 28, 2021 [Page 72] Internet-Draft SDP Attribute Multiplexing August 2020 +---------------------+--------------+ | SDP Name | Mux Category | +---------------------+--------------+ | cat | NORMAL | | keywds | NORMAL | | type | NORMAL | | type:broadcast | NORMAL | | type:H332 | NORMAL | | type:meeting | NORMAL | | type:moderated | NORMAL | | type:test | NORMAL | | charset | NORMAL | | charset:iso8895-1 | NORMAL | | tool | NORMAL | | ipbcp | SPECIAL | | group | NORMAL | | ice-lite | NORMAL | | ice-options | NORMAL | | bcastversion | NORMAL | | 3GPP-Integrity-Key | CAUTION | | 3GPP-SDP-Auth | CAUTION | | alt-group | CAUTION | | PSCid | NORMAL | | bc_service | NORMAL | | bc_program | NORMAL | | bc_service_package | NORMAL | | sescap | CAUTION | | rtsp-ice-d-m | TBD | +---------------------+--------------+ 15.2.3. Table: att-field (both session and media level) The following values are to be added to the "att-field (both session and media level)" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. NOTE: The attributes from draft-ietf-rmt-flute-sdp ('flute-tsi', 'flute-ch', 'FEC-declaration', 'FEC-OTI-extension', 'content-desc') were not analyzed for their multiplexing behavior due to the expired status of the draft. For purposes of this specification, the multiplexing category of 'TBD' is assigned. +-------------------------+-------------------+ | SDP Name | Mux Category | +-------------------------+-------------------+ | recvonly | NORMAL | | sendrecv | NORMAL | Nandakumar Expires February 28, 2021 [Page 73] Internet-Draft SDP Attribute Multiplexing August 2020 | sendonly | NORMAL | | sdplang | NORMAL | | lang | NORMAL | | h248item | SPECIAL | | sqn | NORMAL | | cdsc | NORMAL | | cpar | INHERIT | | cparmin | SPECIAL | | cparmax | SPECIAL | | rtcp-xr | NORMAL | | maxprate | SPECIAL | | setup | TRANSPORT | | connection | TRANSPORT | | key-mgmt | IDENTICAL | | source-filter | IDENTICAL | | inactive | NORMAL | | fingerprint | TRANSPORT | | flute-tsi | TBD | | flute-ch | TBD | | FEC-declaration | TBD | | FEC-OTI-extension | TBD | | content-desc | TBD | | ice-pwd | TRANSPORT | | ice-ufrag | TRANSPORT | | stkmstream | NORMAL | | extmap | SPECIAL | | qos-mech-send | TRANSPORT | | qos-mech-recv | TRANSPORT | | csup | NORMAL | | creq | NORMAL | | acap | INHERIT | | tcap | INHERIT | | 3GPP-QoE-Metrics | CAUTION | | 3GPP-Asset-Information | CAUTION | | mbms-mode | CAUTION | | mbms-repair | CAUTION | | ike-setup | IDENTICAL | | psk-fingerprint | IDENTICAL | | multicast-rtcp | IDENTICAL | | rmcap | IDENTICAL-PER-PT | | omcap | NORMAL | | mfcap | IDENTICAL-PER-PT | | mscap | INHERIT | | 3gpp.iut.replication | TBD | | bcap | INHERIT | | ccap | IDENTICAL | | icap | NORMAL | | 3gpp_sync_info | NORMAL | Nandakumar Expires February 28, 2021 [Page 74] Internet-Draft SDP Attribute Multiplexing August 2020 | 3gpp_MaxRecvSDUSize | NORMAL | | etag | CAUTION | | duplication-delay | NORMAL | | range | CAUTION | | control | CAUTION | | mtag | CAUTION | | ts-refclk | NORMAL | | mediaclk | NORMAL | | calgextmap | NORMAL | +-------------------------+-------------------+ 15.2.4. Table: att-field (media level only) The following values are to be added to the "att-field (media level only)" registry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------------------------+-------------------+ | SDP Name | Mux Category | +---------------------------+-------------------+ | ptime | IDENTICAL-PER-PT | | orient | NORMAL | | orient:portrait | NORMAL | | orient:landscape | NORMAL | | orient:seascape | NORMAL | | framerate | IDENTICAL-PER-PT | | quality | NORMAL | | rtpmap | IDENTICAL-PER-PT | | fmtp | IDENTICAL-PER-PT | | rtpred1 | CAUTION | | rtpred2 | CAUTION | | T38FaxVersion | TBD | | T38MaxBitRate | TBD | | T38FaxFillBitRemoval | TBD | | T38FaxTranscodingMMR | TBD | | T38FaxTranscodingJBIG | TBD | | T38FaxRateManagement | TBD | | T38FaxMaxBuffer | TBD | | T38FaxMaxDatagram | TBD | | T38FaxUdpEC | TBD | | maxptime | IDENTICAL-PER-PT | | des | CAUTION | | curr | CAUTION | | conf | CAUTION | | mid | NORMAL | | rtcp | TRANSPORT | | rtcp-fb | IDENTICAL-PER-PT | Nandakumar Expires February 28, 2021 [Page 75] Internet-Draft SDP Attribute Multiplexing August 2020 | label | NORMAL | | T38VendorInfo | TBD | | crypto | TRANSPORT | | eecid | CAUTION | | aalType | CAUTION | | capability | CAUTION | | qosClass | CAUTION | | bcob | CAUTION | | stc | CAUTION | | upcc | CAUTION | | atmQOSparms | CAUTION | | atmTrfcDesc | CAUTION | | abrParms | CAUTION | | abrSetup | CAUTION | | bearerType | CAUTION | | lij | CAUTION | | anycast | CAUTION | | cache | CAUTION | | bearerSigIE | CAUTION | | aalApp | CAUTION | | cbrRate | CAUTION | | sbc | CAUTION | | clkrec | CAUTION | | fec | CAUTION | | prtfl | CAUTION | | structure | CAUTION | | cpsSDUsize | CAUTION | | all2CPS | CAUTION | | all2CPSSDUrate | CAUTION | | aal2sscs3661unassured | CAUTION | | aal2sscs3661assured | CAUTION | | aal2sscs3662 | CAUTION | | aal5sscop | CAUTION | | atmmap | CAUTION | | silenceSupp | CAUTION | | ecan | CAUTION | | gc | CAUTION | | profileDesc | CAUTION | | vsel | CAUTION | | dsel | CAUTION | | fsel | CAUTION | | onewaySel | CAUTION | | codecconfig | CAUTION | | isup_usi | CAUTION | | uiLayer1_Prot | CAUTION | | chain | CAUTION | | floorctrl | TBD | | confid | NORMAL | Nandakumar Expires February 28, 2021 [Page 76] Internet-Draft SDP Attribute Multiplexing August 2020 | userid | NORMAL | | floorid | NORMAL | | FEC | NORMAL | | accept-types | TBD | | accept-wrapped-types | TBD | | max-size | TBD | | path | TBD | | dccp-service-code | CAUTION | | rtcp-mux | IDENTICAL | | candidate | TRANSPORT | | ice-mismatch | NORMAL | | remote-candidates | TRANSPORT | | SRTPAuthentication | TBD | | SRTPROCTxRate | TBD | | rtcp-rsize | IDENTICAL | | file-selector | TBD | | file-transfer-id | TBD | | file-disposition | TBD | | file-date | TBD | | file-icon | TBD | | file-range | TBD | | depend | IDENTICAL-PER-PT | | ssrc | NORMAL | | ssrc-group | NORMAL | | rtcp-unicast | IDENTICAL | | pcfg | SPECIAL | | acfg | SPECIAL | | zrtp-hash | TRANSPORT | | X-predecbufsize | CAUTION | | X-initpredecbufperiod | CAUTION | | X-initpostdecbufperiod | CAUTION | | X-decbyterate | CAUTION | | 3gpp-videopostdecbufsize | CAUTION | | framesize | CAUTION | | 3GPP-SRTP-Config | CAUTION | | alt | CAUTION | | alt-default-id | CAUTION | | 3GPP-Adaption-Support | CAUTION | | mbms-flowid | CAUTION | | fec-source-flow | SPECIAL | | fec-repair-flow | SPECIAL | | repair-window | SPECIAL | | rams-updates | CAUTION | | imageattr | IDENTICAL-PER-PT | | cfw-id | NORMAL | | portmapping-req | CAUTION | | ecn-capable-rtp | IDENTICAL | | visited-realm | TRANSPORT | Nandakumar Expires February 28, 2021 [Page 77] Internet-Draft SDP Attribute Multiplexing August 2020 | secondary-realm | TRANSPORT | | omr-s-cksum | NORMAL | | omr-m-cksum | NORMAL | | omr-codecs | NORMAL | | omr-m-att | NORMAL | | omr-s-att | NORMAL | | omr-m-bw | NORMAL | | omr-s-bw | NORMAL | | msrp-cema | TBD | | dccp-port | CAUTION | | resource | NORMAL | | channel | NORMAL | | cmid | NORMAL | | content | NORMAL | | lcfg | SPECIAL | | loopback | NORMAL | | loopback-source | NORMAL | | loopback-mirror | NORMAL | | chatroom | TBD | | altc | TRANSPORT | | T38FaxMaxIFP | TBD | | T38FaxUdpECDepth | TBD | | T38FaxUdpFECMaxSpan | TBD | | T38ModemType | TBD | | cs-correlation | TBD | | rtcp-idms | NORMAL | +---------------------------+-------------------+ 15.2.5. Table: att-field (source level) The following values are to be added to the "att-field (source level)" registry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +----------------+-------------------+ | SDP Name | Mux Category | +----------------+-------------------+ | cname | NORMAL | | previous-ssrc | NORMAL | | fmtp | IDENTICAL-PER-PT | | ts-refclk | NORMAL | | mediaclk | NORMAL | +----------------+-------------------+ Nandakumar Expires February 28, 2021 [Page 78] Internet-Draft SDP Attribute Multiplexing August 2020 15.2.6. Table: content SDP Parameters The following values are to be added to the "content SDP Parameters" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +-------------+--------------+ | SDP Name | Mux Category | +-------------+--------------+ | slides | NORMAL | | speaker | NORMAL | | sl | NORMAL | | main | NORMAL | | alt | NORMAL | | g.3gpp.cat | NORMAL | | g.3gpp.crs | NORMAL | +-------------+--------------+ 15.2.7. Table: Semantics for the 'group' SDP Attribute The following values are to be added to the "Semantics for the "group" SDP Attribute" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------+--------------+ | Token | Mux Category | +---------+--------------+ | LS | NORMAL | | FID | NORMAL | | SRF | NORMAL | | ANAT | CAUTION | | FEC | NORMAL | | FEC-FR | NORMAL | | CS | NORMAL | | DDP | NORMAL | | DUP | NORMAL | +---------+--------------+ 15.2.8. Table: 'rtcp-fb' Attribute Values The following values are to be added to the " 'rtcp-fb' Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. Nandakumar Expires February 28, 2021 [Page 79] Internet-Draft SDP Attribute Multiplexing August 2020 +------------+-------------------+ | Value Name | Mux Category | +------------+-------------------+ | ack | IDENTICAL-PER-PT | | app | SPECIAL | | ccm | IDENTICAL-PER-PT | | nack | IDENTICAL-PER-PT | | trr-int | IDENTICAL-PER-PT | +------------+-------------------+ 15.2.9. Table: 'ack' and 'nack' Attribute Values The following values are to be added to the " 'ack' and 'nack' Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+-------------------+ | Value Name | Mux Category | +------------+-------------------+ | sli | IDENTICAL-PER-PT | | pli | IDENTICAL-PER-PT | | rpsi | IDENTICAL-PER-PT | | app | SPECIAL | | rai | IDENTICAL-PER-PT | | tllei | IDENTICAL-PER-PT | | pslei | IDENTICAL-PER-PT | | ecn | IDENTICAL | +------------+-------------------+ 15.2.10. Table: 'depend' SDP Attribute Values The following values are to be added to the " 'depend' SDP Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +-------+-------------------+ | Token | Mux Category | +-------+-------------------+ | lay | IDENTICAL-PER-PT | | mdc | IDENTICAL-PER-PT | +-------+-------------------+ Nandakumar Expires February 28, 2021 [Page 80] Internet-Draft SDP Attribute Multiplexing August 2020 15.2.11. Table: 'cs-correlation' Attribute Values The following values are to be added to the " "cs-correlation" Attribute Values" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +-----------+--------------+ | Value | Mux Category | +-----------+--------------+ | callerid | TBD | | uuie | TBD | | dtmf | TBD | | external | TBD | +-----------+--------------+ 15.2.12. Table: Semantics for the 'ssrc-group' SDP Attribute The following values are to be added to the Semantics for the "Semantics for the "ssrc-group" SDP Attribute" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------+--------------+ | Token | Mux Category | +---------+--------------+ | FID | NORMAL | | FEC | NORMAL | | FEC-FR | NORMAL | | DUP | NORMAL | +---------+--------------+ 15.2.13. Table: SDP/RTSP key management protocol identifiers The following values are to be added to the "SDP/RTSP key management protocol identifiers" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+--------------+ | Value Name | Mux Category | +------------+--------------+ | mikey | IDENTICAL | +------------+--------------+ Nandakumar Expires February 28, 2021 [Page 81] Internet-Draft SDP Attribute Multiplexing August 2020 15.2.14. Table: Codec Control Messages The following values are to be added to the "Codec Control Messages" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+-------------------+ | Value Name | Mux Category | +------------+-------------------+ | fir | IDENTICAL-PER-PT | | tmmbr | IDENTICAL-PER-PT | | tstr | IDENTICAL-PER-PT | | vbcm | IDENTICAL-PER-PT | +------------+-------------------+ 15.2.15. Table: QoS Mechanism Tokens The following values are to be added to the "QoS Mechanism Tokens" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +---------------+--------------+ | QoS Mechanism | Mux Category | +---------------+--------------+ | rsvp | TRANSPORT | | nsis | TRANSPORT | +---------------+--------------+ 15.2.16. Table: SDP Capability Negotiation Option Tags The following values are to be added to the "SDP Capability Negotiation Option Tags" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +------------+--------------+ | Option Tag | Mux Category | +------------+--------------+ | cap-v0 | NORMAL | | med-v0 | NORMAL | | bcap-v0 | NORMAL | | ccap-v0 | NORMAL | | icap-v0 | NORMAL | +------------+--------------+ Nandakumar Expires February 28, 2021 [Page 82] Internet-Draft SDP Attribute Multiplexing August 2020 15.2.17. Table: Timestamp Reference Clock Source Parameters The following values are to be added to the "Timestamp Reference Clock Source Parameters" subregistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +----------+--------------+ | Name | Mux Category | +----------+--------------+ | ntp | NORMAL | | ptp | NORMAL | | gps | NORMAL | | gal | NORMAL | | glonass | NORMAL | | local | NORMAL | | private | NORMAL | +----------+--------------+ 15.2.18. Table: Media Clock Source Parameters The following values are to be added to the "Media Clock Source Parameters" subegistry in the "Session Description Protocol (SDP) Parameters" registry. The references should be updated to point at this RFC as well as the previous references. +-----------+--------------+ | Name | Mux Category | +-----------+--------------+ | sender | NORMAL | | direct | NORMAL | | IEEE1722 | NORMAL | +-----------+--------------+ 16. Security Considerations The primary security for RTP including the way it is used here is described in [RFC3550] and [RFC3711]. When multiplexing SDP attributes with the category "CAUTION", the implementations should be aware of possible issues as described in this specification. 17. Acknowledgments I would like to thank Cullen Jennings, Flemming Andreasen for suggesting the categories, contributing text and reviewing the draft. I would also link to thank Magnus Westerlund, Christer Holmberg, Nandakumar Expires February 28, 2021 [Page 83] Internet-Draft SDP Attribute Multiplexing August 2020 Jonathan Lennox, Bo Burman, Ari Keranen, and Dan Wing on suggesting structural changes helping improve the document readability. I would like also to thank following experts on their inputs and reviews as listed - Flemming Andreasen(5.24,5.32,5.33,14), Rohan Mahy(5.57), Eric Burger(5.26),Christian Huitema(5.14), Christer Holmberg(5.21,5.26,5.51,5.52), Richard Ejzak (5.44,5.53,5.54), Colin Perkins(5.7,5.8,5.9,5.58), Magnus Westerlund(5.2,5.3,5.9,5.27,5.47,6.1,6.2,6.3,8.3,7), Roni Evens(5.12,5.27,8.4), Subha Dhesikan(5.6,10), Dan Wing(5.7,5.12,5.35,5.39,5.45), Cullen Jennings (5.40), Ali C Begen(5.1,5.20,5.22,5.25,5.38,7.3,8.2,8.4,8.6,9.2,13.1), Bo Burman (7.2,7.6), Charles Eckel(5.15,5.27,5.28,9.1,8.5), Paul Kyzivat(5.24), Ian Johansson(5.15), Saravanan Shanmugham(5.11), Paul E Jones(5.30), Rajesh Kumar(5.48), Jonathan Lennox(5.36,5,15,9.1,11.1), Mo Zanaty(5.4,5.5,5.23,8.1,8.3,8.5,12.1), Christian Huitema (5.14), Qin Wu (5.47 PM-Dir review), Hans Stokking(5.43,5.16), Christian Groves (5.48,5.55), Thomas Stach. I would like to thank Chris Lonvick for the SECDIR review, Dan Romascanu for th Gen-ART review and Sabrina Tanamal for the IANA review. Thanks to Ben Campbell for AD review suggestions. Thanks to Spencer Dawkins, Stephen Farrel, Alissa Cooper, Mirja Kuehlewind and the entire IESG experts for their reviews. 18. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes draft-ietf-mmusic-sdp-mux-attributes-16 o Added a clarification note on when to encode IDENTICAL attributes as suggested by Christer. Changes draft-ietf-mmusic-sdp-mux-attributes-15 o Updated Mux category for floorctrl to TBD Changes draft-ietf-mmusic-sdp-mux-attributes-14 o Incorporated Comments from IESG review : * Updated security considerations section to fix the incositencies (Spencer's review) Nandakumar Expires February 28, 2021 [Page 84] Internet-Draft SDP Attribute Multiplexing August 2020 * Updated section 5.36 to align the text with 5.39 (Stephen's review) * Updated IANA registration section to make RFC4566bis a informative dependency (IETF 98 followup) * Updated Section 5 to expand 'B' level SDP attributes (Dan's review) Changes from draft-ietf-mmusic-sdp-mux-attributes-10 - draft-ietf- mmusic-sdp-mux-attributes-13 o Incorporated Comments from WGLC review and AD Evaluation Changes from draft-ietf-mmusic-sdp-mux-attributes-10 o Incorporated Comments from Bo Burman for publication request Changes from draft-ietf-mmusic-sdp-mux-attributes-08 to draft-ietf- mmusic-sdp-mux-attributes-10 o Minor nits and version update to advert expiration Changes from draft-ietf-mmusic-sdp-mux-attributes-06 to draft-ietf- mmusic-sdp-mux-attributes-08 o Assigned TBD category to all the attributes for whom there exists no specification on multiplexing behavior over the underlying transport protocol today. o Incorporated comments from Flemming and Ari (post last call) Changes from draft-ietf-mmusic-sdp-mux-attributes-06 o Incorporated last call review comments from Thomas Stach and Ari Keranen. o Fixed more nits to prep for the LastCall. Changes from draft-ietf-mmusic-sdp-mux-attributes-05 o Incorporated review comments from Christian Grooves and Ari Keranen. o Fixed more nits to prep for the LastCall. Changes from draft-ietf-mmusic-sdp-mux-attributes-04 Nandakumar Expires February 28, 2021 [Page 85] Internet-Draft SDP Attribute Multiplexing August 2020 o Fixed minor nits overall. o Updated Acknowledgement Sections o Last Call Version. Changes from draft-ietf-mmusic-sdp-mux-attributes-03 o More re-work on the IANA section. o Clean ups preparing for the last call. Changes from draft-ietf-mmusic-sdp-mux-attributes-02 o Incorporated suggestions from Flemming on Capability Negotiation. o Closed open issues from IETF90 o Added IANA section to list the categories for all the SDP attributes anlayzed o Lots of cleanup o Reformatted Refernces section to use short-form notation Changes from draft-ietf-mmusic-sdp-mux-attributes-01 o Updated section 15 to provide detailed recommendation on dealing with encapsulating attributes. Also updated sections 5.20, 5.28, 5.29 to refer to Section 15. o Added new categories IDENTICAL-PER-PT and INHERIT o Updated Sections 16 to add the new categories. o Updated Sections 5.1, 5.14, 5.15, 5.38, 8.5 to reflect the category IDENTICAL-PER-PT. o Reformatted section 4 to add individual categories to their own sections. Changes from draft-ietf-mmusic-sdp-mux-attributes-00 o Added Section 15 to provide recommendations on multiplexing SDP encapsulating attributes. Also updated sections 5.20, 5.28, 5.29 to refer to Section 15. Nandakumar Expires February 28, 2021 [Page 86] Internet-Draft SDP Attribute Multiplexing August 2020 o Updated Section 5.38 to incorporate PM-dir review inputs from Qin Wu o Updated Sections 5.2,5.14,8.5 to refer to BUNDLE draft for more clarity. o Fixed few nits regarding sentence clarity and fill-in the NOTES section where information was lacking. Changes from draft-nandakumar-mmusic-mux-attributes-05 o Renamed the document to be a WG document. o Added Section 14. o Updated Open Issues based on IETF88 discussions. Changes from draft-nandakumar-mmusic-mux-attributes-04 o Added few OPEN ISSUES that needs to be discussed. o Updated sections 5.10,5.23,5,24,5,25,7.2,9.1,5.12,5.27,8.4, 5.44,5.11,5.4,5.19,10.1,10.5,5.21,10.4,15.1 o Updated Table Column name Current to Level and improved TRANSPORT category explanation on suggestions form Dan Wing. o Grouped all the rtcp-fb attribute analysis under a single section as suggested by Magnus/ Changes from draft-nandakumar-mmusic-mux-attributes-03 o Maintenance change to clean up grammatical nits and wordings. Changes from draft-nandakumar-mmusic-mux-attributes-02 o Updated Sections 5.3,5.5,5.6,5.7,5.9,5.8,5.11,5.13,5.22,5.34, 5.37,5.40,5.41,5.42,5.43,5.44,5.45,6.1,6.2,6.3,8,3,12.1 based on the inputs from the respective RFC Authors. Changes from draft-nandakumar-mmusic-mux-attributes-01 o Replaced Category BAD with NOT-RECOMMENDED. o Added Category TBD. o Updated IANA Consideration Section. Nandakumar Expires February 28, 2021 [Page 87] Internet-Draft SDP Attribute Multiplexing August 2020 Changes from draft-nandakumar-mmusic-mux-attributes-00 o Added new section for dealing with FEC payload types. 19. References 19.1. Normative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . 19.2. Informative References [H.248.15] "Gateway control protocol: SDP H.248 package attribute", . [I-D.ietf-mmusic-rfc4566bis] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", draft-ietf-mmusic- rfc4566bis-37 (work in progress), August 2019. [IANA] "Session Description Protocol (SDP) Parameters", . [Q.1970] "Q.1970 : BICC IP bearer control protocol", . Nandakumar Expires February 28, 2021 [Page 88] Internet-Draft SDP Attribute Multiplexing August 2020 [R3GPPTS183.063] "TISPAN - IMS based ITPV Stage 3 specification.", . [R3GPPTS24.182] "IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol specification", . [R3GPPTS24.183] "IP Multimedia Subsystem (IMS) Customized Ringing Signal (CRS); Protocol specification", . [R3GPPTS24.229] "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);", . [R3GPPTS26.114] "IP multimedia Subsystem : Media Handling and interaction", . [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, . [RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October 2002, . Nandakumar Expires February 28, 2021 [Page 89] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, DOI 10.17487/RFC3407, October 2002, . [RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, DOI 10.17487/RFC3524, April 2003, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, . [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, DOI 10.17487/RFC4091, June 2005, . Nandakumar Expires February 28, 2021 [Page 90] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July 2006, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, DOI 10.17487/RFC4570, July 2006, . [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, DOI 10.17487/RFC4572, July 2006, . [RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, . [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, DOI 10.17487/RFC4583, November 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, DOI 10.17487/RFC4796, February 2007, . Nandakumar Expires February 28, 2021 [Page 91] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5159] Dondeti, L., Ed. and A. Jerichow, "Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection", RFC 5159, DOI 10.17487/RFC5159, March 2008, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5432] Polk, J., Dhesikan, S., and G. Camarillo, "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", RFC 5432, DOI 10.17487/RFC5432, March 2009, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, DOI 10.17487/RFC5547, May 2009, . Nandakumar Expires February 28, 2021 [Page 92] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, . [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April 2010, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC5939] Andreasen, F., "Session Description Protocol (SDP) Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, September 2010, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . Nandakumar Expires February 28, 2021 [Page 93] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service", RFC 6064, DOI 10.17487/RFC6064, January 2011, . [RFC6128] Begen, A., "RTP Control Protocol (RTCP) Port for Source- Specific Multicast (SSM) Sessions", RFC 6128, DOI 10.17487/RFC6128, February 2011, . [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, . [RFC6193] Saito, M., Wing, D., and M. Toyama, "Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP)", RFC 6193, DOI 10.17487/RFC6193, April 2011, . [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", RFC 6230, DOI 10.17487/RFC6230, May 2011, . [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, . [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, June 2011, . [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, DOI 10.17487/RFC6285, June 2011, . [RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, DOI 10.17487/RFC6364, October 2011, . Nandakumar Expires February 28, 2021 [Page 94] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC6642] Wu, Q., Ed., Xia, F., and R. Even, "RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report", RFC 6642, DOI 10.17487/RFC6642, June 2012, . [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . [RFC6714] Holmberg, C., Blau, S., and E. Burger, "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", RFC 6714, DOI 10.17487/RFC6714, August 2012, . [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 2012, . [RFC6787] Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)", RFC 6787, DOI 10.17487/RFC6787, November 2012, . [RFC6849] Kaplan, H., Ed., Hedayat, K., Venna, N., Jones, P., and N. Stratton, "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", RFC 6849, DOI 10.17487/RFC6849, February 2013, . [RFC6871] Gilman, R., Even, R., and F. Andreasen, "Session Description Protocol (SDP) Media Capabilities Negotiation", RFC 6871, DOI 10.17487/RFC6871, February 2013, . [RFC6947] Boucadair, M., Kaplan, H., Gilman, R., and S. Veikkolainen, "The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", RFC 6947, DOI 10.17487/RFC6947, May 2013, . [RFC7006] Garcia-Martin, M., Veikkolainen, S., and R. Gilman, "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", RFC 7006, DOI 10.17487/RFC7006, September 2013, . Nandakumar Expires February 28, 2021 [Page 95] Internet-Draft SDP Attribute Multiplexing August 2020 [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, DOI 10.17487/RFC7104, January 2014, . [RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", RFC 7195, DOI 10.17487/RFC7195, May 2014, . [RFC7197] Begen, A., Cai, Y., and H. Ou, "Duplication Delay Attribute in the Session Description Protocol", RFC 7197, DOI 10.17487/RFC7197, April 2014, . [RFC7266] Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting", RFC 7266, DOI 10.17487/RFC7266, June 2014, . [RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O., Boronat, F., Montagud, M., and K. Gross, "Inter- Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272, June 2014, . [RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [T.38] "Procedures for real-time Group 3 facsimile communication over IP networks", . Author's Address Nandakumar Expires February 28, 2021 [Page 96] Internet-Draft SDP Attribute Multiplexing August 2020 Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Nandakumar Expires February 28, 2021 [Page 97] ./draft-ietf-mmusic-sdp-simulcast-14.txt0000644000764400076440000027150513437433163017461 0ustar iustyiusty Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Standards Track Ericsson Expires: September 6, 2019 S. Nandakumar M. Zanaty Cisco March 5, 2019 Using Simulcast in SDP and RTP Sessions draft-ietf-mmusic-sdp-simulcast-14 Abstract In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Burman, et al. Expires September 6, 2019 [Page 1] Internet-Draft Simulcast March 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 6 3.2. Application Specific Media Source Handling . . . . . . . 7 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13 5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14 5.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 5.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 15 5.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 21 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 23 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 23 6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 24 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 26 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 27 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 28 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 Burman, et al. Expires September 6, 2019 [Page 2] Internet-Draft Simulcast March 2019 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 35 B.1. Modifications Between WG Version -13 and -14 . . . . . . 35 B.2. Modifications Between WG Version -12 and -13 . . . . . . 36 B.3. Modifications Between WG Version -11 and -12 . . . . . . 36 B.4. Modifications Between WG Version -10 and -11 . . . . . . 36 B.5. Modifications Between WG Version -09 and -10 . . . . . . 37 B.6. Modifications Between WG Version -08 and -09 . . . . . . 37 B.7. Modifications Between WG Version -07 and -08 . . . . . . 37 B.8. Modifications Between WG Version -06 and -07 . . . . . . 38 B.9. Modifications Between WG Version -05 and -06 . . . . . . 38 B.10. Modifications Between WG Version -04 and -05 . . . . . . 38 B.11. Modifications Between WG Version -03 and -04 . . . . . . 39 B.12. Modifications Between WG Version -02 and -03 . . . . . . 39 B.13. Modifications Between WG Version -01 and -02 . . . . . . 40 B.14. Modifications Between WG Version -00 and -01 . . . . . . 40 B.15. Modifications Between Individual Version -00 and WG Version -00 . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction Most of today's multiparty video conference solutions make use of centralized servers to reduce the bandwidth and CPU consumption in the endpoints. Those servers receive RTP streams from each participant and send some suitable set of possibly modified RTP streams to the rest of the participants, which usually have heterogeneous capabilities (screen size, CPU, bandwidth, codec, etc). One of the biggest issues is how to perform RTP stream adaptation to different participants' constraints with the minimum possible impact on both video quality and server performance. Simulcast is defined in this memo as the act of simultaneously sending multiple different encoded streams of the same media source, e.g. the same video source encoded with different video encoder types or image resolutions. This can be done in several ways and for different purposes. This document focuses on the case where it is desirable to provide a media source as multiple encoded streams over RTP [RFC3550] towards an intermediary so that the intermediary can provide the wanted functionality by selecting which RTP stream(s) to forward to other participants in the session, and more specifically how the identification and grouping of the involved RTP streams are done. Burman, et al. Expires September 6, 2019 [Page 3] Internet-Draft Simulcast March 2019 The intended scope of the defined mechanism is to support negotiation and usage of simulcast when using SDP offer/answer and media transport over RTP. The media transport topologies considered are point to point RTP sessions as well as centralized multi-party RTP sessions, where a media sender will provide the simulcasted streams to an RTP middlebox or endpoint, and middleboxes may further distribute the simulcast streams to other middleboxes or endpoints. Simulcast could, as part of a distributed multi-party scenario, be used point-to-point between middleboxes. Usage of multicast or broadcast transport is out of scope and left for future extensions. This document describes a few scenarios that motivate the use of simulcast, and also defines the needed RTP/RTCP and SDP signaling for it. 2. Definitions 2.1. Terminology This document makes use of the terminology defined in RTP Taxonomy [RFC7656], and RTP Topologies [RFC7667]. The following terms are especially noted or here defined: RTP Mixer: An RTP middle node, defined in [RFC7667] (Section 3.6 to 3.9). RTP Session: An association among a group of participants communicating with RTP, as defined in [RFC3550] and amended by [RFC7656]. RTP Stream: A stream of RTP packets containing media data, as defined in [RFC7656]. RTP Switch: A common short term for the terms "switching RTP mixer", "source projecting middlebox", and "video switching MCU" as discussed in [RFC7667]. Simulcast Stream: One encoded stream or dependent stream from a set of concurrently transmitted encoded streams and optional dependent streams, all sharing a common media source, as defined in [RFC7656]. For example, HD and thumbnail video simulcast versions of a single media source sent concurrently as separate RTP Streams. Simulcast Format: Different formats of a simulcast stream serve the same purpose as alternative RTP payload types in non-simulcast SDP: to allow multiple alternative media formats for a given RTP stream. As for multiple RTP payload types on the m-line in offer/ Burman, et al. Expires September 6, 2019 [Page 4] Internet-Draft Simulcast March 2019 answer [RFC3264], any one of the negotiated alternative formats can be used in a single RTP stream at a given point in time, but not more than one (based on RTP timestamp). What format is used can change dynamically from one RTP packet to another. 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Use Cases The use cases of simulcast described in this document relate to a multi-party communication session where one or more central nodes are used to adapt the view of the communication session towards individual participants, and facilitate the media transport between participants. Thus, these cases target the RTP Mixer type of topology. There are two principal approaches for an RTP Mixer to provide this adapted view of the communication session to each receiving participant: o Transcoding (decoding and re-encoding) received RTP streams with characteristics adapted to each receiving participant. This often include mixing or composition of media sources from multiple participants into a mixed media source originated by the RTP Mixer. The main advantage of this approach is that it achieves close to optimal adaptation to individual receiving participants. The main disadvantages are that it can be very computationally expensive to the RTP Mixer, typically degrades media Quality of Experience (QoE) such as end-to-end delay for the receiving participants, and requires RTP Mixer access to media content. o Switching a subset of all received RTP streams or sub-streams to each receiving participant, where the used subset is typically specific to each receiving participant. The main advantages of this approach are that it is computationally cheap to the RTP Mixer, has very limited impact on media QoE, and does not require RTP Mixer (full) access to media content. The main disadvantage is that it can be difficult to combine a subset of received RTP streams into a perfect fit to the resource situation of a receiving participant. It is also a disadvantage that sending multiple RTP streams consumes more network resources from the sending participant to the RTP Mixer. Burman, et al. Expires September 6, 2019 [Page 5] Internet-Draft Simulcast March 2019 The use of simulcast relates to the latter approach, where it is more important to reduce the load on the RTP Mixer and/or minimize QoE impact than to achieve an optimal adaptation of resource usage. 3.1. Reaching a Diverse Set of Receivers The media sources provided by a sending participant potentially need to reach several receiving participants that differ in terms of available resources. The receiver resources that typically differ include, but are not limited to: Codec: This includes codec type (such as RTP payload format MIME type) and can include codec configuration. A couple of codec resources that differ only in codec configuration will be "different" if they are somehow not "compatible", like if they differ in video codec profile, or the transport packetization configuration. Sampling: This relates to how the media source is sampled, in spatial as well as in temporal domain. For video streams, spatial sampling affects image resolution and temporal sampling affects video frame rate. For audio, spatial sampling relates to the number of audio channels and temporal sampling affects audio bandwidth. This may be used to suit different rendering capabilities or needs at the receiving endpoints. Bitrate: This relates to the number of bits sent per second to transmit the media source as an RTP stream, which typically also affects the QoE for the receiving user. Letting the sending participant create a simulcast of a few differently configured RTP streams per media source can be a good tradeoff when using an RTP switch as middlebox, instead of sending a single RTP stream and using an RTP mixer to create individual transcodings to each receiving participant. This requires that the receiving participants can be categorized in terms of available resources and that the sending participant can choose a matching configuration for a single RTP stream per category and media source. For example, a set of receiving participants differ only in screen resolution; some are able to display video with at most 360p resolution and some support 720p resolution. A sending participant can then reach all receivers with best possible resolution by creating a simulcast of RTP streams with 360p and 720p resolution for each sent video media source. Burman, et al. Expires September 6, 2019 [Page 6] Internet-Draft Simulcast March 2019 The maximum number of simulcasted RTP streams that can be sent is mainly limited by the amount of processing and uplink network resources available to the sending participant. 3.2. Application Specific Media Source Handling The application logic that controls the communication session may include special handling of some media sources. It is, for example, commonly the case that the media from a sending participant is not sent back to itself. It is also common that a currently active speaker participant is shown in larger size or higher quality than other participants (the sampling or bitrate aspects of Section 3.1) in a receiving client. Many conferencing systems do not send the active speaker's media back to the sender itself, which means there is some other participant's media that instead is forwarded to the active speaker; typically the previous active speaker. This way, the previously active speaker is needed both in larger size (to current active speaker) and in small size (to the rest of the participants), which can be solved with a simulcast from the previously active speaker to the RTP switch. 3.3. Receiver Media Source Preferences The application logic that controls the communication session may allow receiving participants to state preferences on the characteristics of the RTP stream they like to receive, for example in terms of the aspects listed in Section 3.1. Sending a simulcast of RTP streams is one way of accommodating receivers with conflicting or otherwise incompatible preferences. 4. Overview This memo defines SDP [RFC4566] signaling that covers the above described simulcast use cases and functionalities. A number of requirements for such signaling are elaborated in Appendix A. The RID mechanism, as defined in [I-D.ietf-mmusic-rid], enables an SDP offerer or answerer to specify a number of different RTP stream restrictions for a rid-id by using the "a=rid" line. Examples of such restrictions are maximum bitrate, maximum spatial video resolution (width and height), maximum video framerate, etc. Each rid-id may also be restricted to use only a subset of the RTP payload types in the associated SDP media description. Those RTP payload types can have their own configurations and parameters affecting what can be sent or received, using the "a=fmtp" line as well as other SDP attributes. Burman, et al. Expires September 6, 2019 [Page 7] Internet-Draft Simulcast March 2019 A new SDP media level attribute "a=simulcast" is defined. The attribute describes, independently for send and receive directions, the number of simulcast RTP streams as well as potential alternative formats for each simulcast RTP stream. Each simulcast RTP stream, including alternatives, is identified using the RID identifier (rid- id), defined in [I-D.ietf-mmusic-rid]. a=simulcast:send 1;2,3 recv 4 If the above line is included in an SDP offer, the "send" part indicates the offerer's capability and proposal to send two simulcast RTP streams. Each simulcast stream is described by one or more RTP stream identifiers (rid-id), each group of rid-ids for a simulcast stream is separated by a semicolon (";"). When a simulcast stream has multiple rid-ids that are separated by a comma (","), they describe alternative representations for that particular simulcast RTP stream. Thus, the above "send" part is interpreted as an intention to send two simulcast RTP streams. The first simulcast RTP stream is identified and restricted according to rid-id 1. The second simulcast RTP stream can be sent as two alternatives, identified and restricted according to rid-ids 2 and 3. The "recv" part of the above line indicates that the offerer desires to receive a single RTP stream (no simulcast) according to rid-id 4. A more complete example SDP offer media description is provided below: m=video 49300 RTP/AVP 97 98 99 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=rtpmap:99 VP8/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=fmtp:99 max-fs=240; max-fr=30 a=rid:1 send pt=97;max-width=1280;max-height=720 a=rid:2 send pt=98;max-width=320;max-height=180 a=rid:3 send pt=99;max-width=320;max-height=180 a=rid:4 recv pt=97 a=simulcast:send 1;2,3 recv 4 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 1: Example Simulcast Media Description in Offer The above SDP media description can be interpreted at a high level to say that the offerer is capable of sending two simulcast RTP streams, one H.264 encoded stream in up to 720p resolution, and one additional stream encoded as either H.264 or VP8 with a maximum resolution of Burman, et al. Expires September 6, 2019 [Page 8] Internet-Draft Simulcast March 2019 320x180 pixels. The offerer can receive one H.264 stream with maximum 720p resolution. The receiver of this SDP offer can generate an SDP answer that indicates what it accepts. It uses the "a=simulcast" attribute to indicate simulcast capability and specify what simulcast RTP streams and alternatives to receive and/or send. An example of such answering "a=simulcast" attribute, corresponding to the above offer, is: a=simulcast:recv 1;2 send 4 With this SDP answer, the answerer indicates in the "recv" part that it wants to receive the two simulcast RTP streams. It has removed an alternative that it doesn't support (rid-id 3). The send part confirms to the offerer that it will receive one stream for this media source according to rid-id 4. The corresponding, more complete example SDP answer media description could look like: m=video 49674 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=rid:1 recv pt=97;max-width=1280;max-height=720 a=rid:2 recv pt=98;max-width=320;max-height=180 a=rid:4 send pt=97 a=simulcast:recv 1;2 send 4 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 2: Example Simulcast Media Description in Answer It is assumed that a single SDP media description is used to describe a single media source. This is aligned with the concepts defined in [RFC7656] and will work in a WebRTC context, both with and without BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media descriptions. To summarize, the "a=simulcast" line describes send and receive direction simulcast streams separately. Each direction can in turn describe one or more simulcast streams, separated by semicolon. The identifiers describing simulcast streams on the "a=simulcast" line are rid-id, as defined by "a=rid" lines in [I-D.ietf-mmusic-rid]. Each simulcast stream can be offered as a list of alternative rid-id, with each alternative separated by comma (not in the examples above). A detailed specification can be found in Section 5 and more detailed examples are outlined in Section 5.6. Burman, et al. Expires September 6, 2019 [Page 9] Internet-Draft Simulcast March 2019 5. Detailed Description This section further details the overview above (Section 4). First, formal syntax is provided (Section 5.1), followed by the rest of the SDP attribute definition in Section 5.2. Relating Simulcast Streams (Section 5.5) provides the definition of the RTP/RTCP mechanisms used. The section is concluded with a number of examples. 5.1. Simulcast Attribute This document defines a new SDP media-level "a=simulcast" attribute, with value according to the following ABNF [RFC5234] syntax and its update for Case-Sensitive String Support in ABNF [RFC7405]: sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] ) sc-send = %s"send" SP sc-str-list sc-recv = %s"recv" SP sc-str-list sc-str-list = sc-alt-list *( ";" sc-alt-list ) sc-alt-list = sc-id *( "," sc-id ) sc-id-paused = "~" sc-id = [sc-id-paused] rid-id ; SP defined in [RFC5234] ; rid-id defined in [I-D.ietf-mmusic-rid] Figure 3: ABNF for Simulcast Value Note to RFC Editor: Replace "I-D.ietf-mmusic-rid" in the above figure with RFC number of draft-ietf-mmusic-rid before publication of this document. The "a=simulcast" attribute has a parameter in the form of one or two simulcast stream descriptions, each consisting of a direction ("send" or "recv"), followed by a list of one or more simulcast streams. Each simulcast stream consists of one or more alternative simulcast formats. Each simulcast format is identified by a simulcast stream identifier (rid-id). The rid-id MUST have the form of an RTP stream identifier, as described by RTP Payload Format Restrictions [I-D.ietf-mmusic-rid]. In the list of simulcast streams, each simulcast stream is separated by a semicolon (";"). Each simulcast stream can in turn be offered in one or more alternative formats, represented by rid-ids, separated by a comma (","). Each rid-id can also be specified as initially paused [RFC7728], indicated by prepending a "~" to the rid-id. The reason to allow separate initial pause states for each rid-id is that pause capability can be specified individually for each RTP payload type referenced by an rid-id. Since pause capability specified via the "a=rtcp-fb" attribute applies only to specified payload types and Burman, et al. Expires September 6, 2019 [Page 10] Internet-Draft Simulcast March 2019 rid-id specified by "a=rid" can refer to multiple different payload types, it is unfeasible to pause streams with rid-id where any of the related RTP payload type(s) do not have pause capability. 5.2. Simulcast Capability Simulcast capability is expressed through a new media level SDP attribute, "a=simulcast" (Section 5.1). The use of this attribute at the session level is undefined. Implementations of this specification MUST NOT use it at the session level and MUST ignore it if received at the session level. Extensions to this specification may define such session level usage. Each SDP media description MUST contain at most one "a=simulcast" line. There are separate and independent sets of simulcast streams in send and receive directions. When listing multiple directions, each direction MUST NOT occur more than once on the same line. Simulcast streams using undefined rid-id MUST NOT be used as valid simulcast streams by an RTP stream receiver. The direction for an rid-id MUST be aligned with the direction specified for the corresponding RTP stream identifier on the "a=rid" line. The listed number of simulcast streams for a direction sets a limit to the number of supported simulcast streams in that direction. The order of the listed simulcast streams in the "send" direction suggests a proposed order of preference, in decreasing order: the rid-id listed first is the most preferred and subsequent streams have progressively lower preference. The order of the listed rid-id in the "recv" direction expresses which simulcast streams that are preferred, with the leftmost being most preferred. This can be of importance if the number of actually sent simulcast streams have to be reduced for some reason. rid-id that have explicit dependencies [RFC5583] [I-D.ietf-mmusic-rid] to other rid-id (even in the same media description) MAY be used. Use of more than a single, alternative simulcast format for a simulcast stream MAY be specified as part of the attribute parameters by expressing the simulcast stream as a comma-separated list of alternative rid-id. The order of the rid-id alternatives within a simulcast stream is significant; the rid-id alternatives are listed from (left) most preferred to (right) least preferred. For the use of simulcast, this overrides the normal codec preference as expressed by format type ordering on the "m=" line, using regular SDP rules. This is to enable a separation of general codec preferences and simulcast stream configuration preferences. However, the choice of Burman, et al. Expires September 6, 2019 [Page 11] Internet-Draft Simulcast March 2019 which alternative to use per simulcast stream is independent, and there is currently no mechanism to align the choice between alternative rid-ids between different simulcast streams. A simulcast stream can use a codec defined such that the same RTP SSRC can change RTP payload type multiple times during a session, possibly even on a per-packet basis. A typical example can be a speech codec that makes use of Comfort Noise [RFC3389] and/or DTMF [RFC4733] formats. If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be prefixed by a "~" character to indicate that the corresponding simulcast stream is initially paused already from start of the RTP session. In this case, support for RTP stream pause/resume MUST also be included under the same "m=" line where "a=simulcast" is included. All RTP payload types related to such an initially paused simulcast stream MUST be listed in the SDP as pause/resume capable as specified by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb". An initially paused simulcast stream in "send" direction for the endpoint sending the SDP MUST be considered equivalent to an unsolicited locally paused stream, and be handled accordingly. Initially paused simulcast streams are resumed as described by the RTP pause/resume specification. An RTP stream receiver that wishes to resume an unsolicited locally paused stream needs to know the SSRC of that stream. The SSRC of an initially paused simulcast stream can be obtained from an RTP stream sender RTCP Sender Report (SR) including both the desired SSRC as "SSRC of sender", and the rid-id value in an RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. If the endpoint sending the SDP includes an "recv" direction simulcast stream that is initially paused, then the remote RTP sender receiving the SDP SHOULD put its RTP stream in a unsolicited locally paused state. The simulcast stream sender does not put the stream in the locally paused state if there are other RTP stream receivers in the session that do not mark the simulcast stream as initially paused. However, in centralized conferencing the RTP sender usually does not see the SDP signalling from RTP receivers and cannot make this determination. The reason to require an initially paused "recv" stream to be considered locally paused by the remote RTP sender, instead of making it equivalent to implicitly sending a pause request, is because the pausing RTP sender cannot know which receiving SSRC owns the restriction when Temporary Maximum Media Stream Bit Rate Request (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification (TMMBN) are used for pause/resume signaling (Section 5.6 of [RFC7728]) since the RTP receiver's SSRC in send direction is sometimes not yet known. Burman, et al. Expires September 6, 2019 [Page 12] Internet-Draft Simulcast March 2019 Use of the redundant audio data [RFC2198] format could be seen as a form of simulcast for loss protection purposes, but is not considered conflicting with the mechanisms described in this memo and MAY therefore be used as any other format. In this case the "red" format, rather than the carried formats, SHOULD be the one to list as a simulcast stream on the "a=simulcast" line. The media formats and corresponding characteristics of simulcast streams SHOULD be chosen such that they are different, e.g. as different SDP formats with differing "a=rtpmap" and/or "a=fmtp" lines, or as differently defined RTP payload format restrictions. If this difference is not required, it is RECOMMENDED to use RTP duplication [RFC7104] procedures instead of simulcast. To avoid complications in implementations, a single rid-id MUST NOT occur more than once per "a=simulcast" line. Note that this does not eliminate use of simulcast as an RTP duplication mechanism, since it is possible to define multiple different rid-id that are effectively equivalent. 5.3. Offer/Answer Use Note: The inclusion of "a=simulcast" or the use of simulcast does not change any of the interpretation or Offer/Answer procedures for other SDP attributes, like "a=fmtp" or "a=rid". 5.3.1. Generating the Initial SDP Offer An offerer wanting to use simulcast for a media description SHALL include one "a=simulcast" attribute in that media description in the offer. An offerer listing a set of receive simulcast streams and/or alternative formats as rid-id in the offer MUST be prepared to receive RTP streams for any of those simulcast streams and/or alternative formats from the answerer. 5.3.2. Creating the SDP Answer An answerer that does not understand the concept of simulcast will also not know the attribute and will remove it in the SDP answer, as defined in existing SDP Offer/Answer [RFC3264] procedures. Since SDP session level simulcast is undefined in this memo, an answerer that receives an offer with the "a=simulcast" attribute on SDP session level SHALL remove it in the answer. An answerer that understands the attribute but receives multiple "a=simulcast" attributes in the same media description SHALL disable use of simulcast by removing all "a=simulcast" lines for that media description in the answer. An answerer that does understand the attribute and that wants to support simulcast in an indicated direction SHALL reverse Burman, et al. Expires September 6, 2019 [Page 13] Internet-Draft Simulcast March 2019 directionality of the unidirectional direction parameters; "send" becomes "recv" and vice versa, and include it in the answer. An answerer that receives an offer with simulcast containing an "a=simulcast" attribute listing alternative rid-id MAY keep all the alternative rid-id in the answer, but it MAY also choose to remove any non-desirable alternative rid-id in the answer. The answerer MUST NOT add any alternative rid-id in send direction in the answer that were not present in the offer receive direction. The answerer MUST be prepared to receive any of the receive direction rid-id alternatives and MAY send any of the send direction alternatives that are part of the answer. An answerer that receives an offer with simulcast that lists a number of simulcast streams, MAY reduce the number of simulcast streams in the answer, but MUST NOT add simulcast streams. An answerer that receives an offer without RTP stream pause/resume capability MUST NOT mark any simulcast streams as initially paused in the answer. An RTP stream pause/resume capable answerer that receives an offer with RTP stream pause/resume capability MAY mark any rid-id that refer to pause/resume capable formats as initially paused in the answer. An answerer that receives indication in an offer of an rid-id being initially paused SHOULD mark that rid-id as initially paused also in the answer, regardless of direction, unless it has good reason for the rid-id not being initially paused. One reason to remove an initial pause in the answer compared to the offer could, for example, be that all receive direction simulcast streams for a media source the answerer accepts in the answer would otherwise be paused. 5.3.3. Offerer Processing the SDP Answer An offerer that receives an answer without "a=simulcast" MUST NOT use simulcast towards the answerer. An offerer that receives an answer with "a=simulcast" without any rid-id in a specified direction MUST NOT use simulcast in that direction. An offerer that receives an answer where some rid-id alternatives are kept MUST be prepared to receive any of the kept send direction rid- id alternatives, and MAY send any of the kept receive direction rid- id alternatives. An offerer that receives an answer where some of the rid-id are removed compared to the offer MAY release the corresponding resources Burman, et al. Expires September 6, 2019 [Page 14] Internet-Draft Simulcast March 2019 (codec, transport, etc) in its receive direction and MUST NOT send any RTP packets corresponding to the removed rid-id. An offerer that offered some of its rid-id as initially paused and that receives an answer that does not indicate RTP stream pause/ resume capability, MUST NOT initially pause any simulcast streams. An offerer with RTP stream pause/resume capability that receives an answer where some rid-id are marked as initially paused, SHOULD initially pause those RTP streams regardless if they were marked as initially paused also in the offer, unless it has good reason for those RTP streams not being initially paused. One such reason could, for example, be that the answerer would otherwise initially not receive any media of that type at all. 5.3.4. Modifying the Session Offers inside an existing session follow the same rules as for initial SDP offer, with these additions: 1. rid-id marked as initially paused in the offerer's send direction SHALL reflect the offerer's opinion of the current pause state at the time of creating the offer. This is purely informational, and RTP stream pause/resume [RFC7728] signaling in the ongoing session SHALL take precedence in case of any conflict or ambiguity. 2. rid-id marked as initially paused in the offerer's receive direction SHALL (as in an initial offer) reflect the offerer's desired rid-id pause state. Except for the case where the offerer already paused the corresponding RTP stream through RTP stream pause/resume [RFC7728] signaling , this is identical to the conditions at an initial offer. Creation of SDP answers and processing of SDP answers inside an existing session follow the same rules as described above for initial SDP offer/answer. Session modification restrictions in section 6.5 of RTP payload format restrictions [I-D.ietf-mmusic-rid] also apply. 5.4. Use with Declarative SDP This document does not define the use of "a=simulcast" in declarative SDP, partly motivated by use of the simulcast format identification [I-D.ietf-mmusic-rid] not being defined for use in declarative SDP. If concrete use cases for simulcast in declarative SDP are identified Burman, et al. Expires September 6, 2019 [Page 15] Internet-Draft Simulcast March 2019 in the future, the authors of this memo expect that additional specifications will address such use. 5.5. Relating Simulcast Streams Simulcast RTP streams MUST be related on RTP level through RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP "a=simulcast" attribute (Section 5.2) parameters. This is sufficient as long as there is only a single media source per SDP media description. When using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media descriptions jointly specify a single RTP session, the SDES MID identification mechanism in BUNDLE allows relating RTP streams back to individual media descriptions, after which the above described RtpStreamId relations can be used. Use of the RTP header extension [RFC8285] for both MID and RtpStreamId identifications can be important to ensure rapid initial reception, required to correctly interpret and process the RTP streams. Implementers of this specification MUST support the RTCP source description (SDES) item method and SHOULD support RTP header extension method to signal RtpStreamId on RTP level. NOTE: For the case where it is clear from SDP that RTP PT uniquely maps to corresponding RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. This can sometimes enable decoding even in advance to receiving RtpStreamId information in RTCP SDES and/or RTP header extensions. RTP streams MUST only use a single alternative rid-id at a time (based on RTP timestamps), but MAY change format (and rid-id) on a per-RTP packet basis. This corresponds to the existing (non- simulcast) SDP offer/answer case when multiple formats are included on the "m=" line in the SDP answer, enabling per-RTP packet change of RTP payload type. 5.6. Signaling Examples These examples describe a client to video conference service, using a centralized media topology with an RTP mixer. Burman, et al. Expires September 6, 2019 [Page 16] Internet-Draft Simulcast March 2019 +---+ +-----------+ +---+ | A |<---->| |<---->| B | +---+ | | +---+ | Mixer | +---+ | | +---+ | F |<---->| |<---->| J | +---+ +-----------+ +---+ Figure 4: Four-party Mixer-based Conference 5.6.1. Single-Source Client Alice is calling in to the mixer with a simulcast-enabled client capable of a single media source per media type. The client can send a simulcast of 2 video resolutions and frame rates: HD 1280x720p 30fps and thumbnail 320x180p 15fps. This is defined below using the "imageattr" [RFC6236]. In this example, only the "pt" "a=rid" parameter is used, effectively achieving a 1:1 mapping between RtpStreamId and media formats (RTP payload types), to describe simulcast stream formats. Alice's Offer: v=0 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 s=Simulcast Enabled Client c=IN IP4 192.0.2.156 t=0 0 m=audio 49200 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49300 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 send pt=97 a=rid:2 send pt=98 a=rid:3 recv pt=97 a=simulcast:send 1;2 recv 3 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 5: Single-Source Simulcast Offer The only thing in the SDP that indicates simulcast capability is the line in the video media description containing the "simulcast" attribute. The included "a=fmtp" and "a=imageattr" parameters indicates that sent simulcast streams can differ in video resolution. The RTP header extension for RtpStreamId is offered to avoid issues Burman, et al. Expires September 6, 2019 [Page 17] Internet-Draft Simulcast March 2019 with the initial binding between RTP streams (SSRCs) and the RtpStreamId identifying the simulcast stream and its format. The Answer from the server indicates that it too is simulcast capable. Should it not have been simulcast capable, the "a=simulcast" line would not have been present and communication would have started with the media negotiated in the SDP. Also the usage of the RtpStreamId RTP header extension is accepted. v=0 o=server 823479283 1209384938 IN IP4 192.0.2.2 s=Answer to Simulcast Enabled Client c=IN IP4 192.0.2.43 t=0 0 m=audio 49672 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 49674 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 recv pt=97 a=rid:2 recv pt=98 a=rid:3 send pt=97 a=simulcast:recv 1;2 send 3 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Figure 6: Single-Source Simulcast Answer Since the server is the simulcast media receiver, it reverses the direction of the "simulcast" and "rid" attribute parameters. 5.6.2. Multi-Source Client Fred is calling in to the same conference as in the example above with a two-camera, two-display system, thus capable of handling two separate media sources in each direction, where each media source is simulcast-enabled in the send direction. Fred's client is restricted to a single media source per media description. The first two simulcast streams for the first media source use different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two simulcast streams also have a temporal dependency. Two different video codecs, VP8 [RFC7741] and H264, are offered as alternatives for the third simulcast stream for the first media source. Only the Burman, et al. Expires September 6, 2019 [Page 18] Internet-Draft Simulcast March 2019 highest fidelity simulcast stream is sent from start, the lower fidelity streams being initially paused. The second media source is offered with three different simulcast streams. All video streams of this second media source are loss protected by RTP retransmission [RFC4588]. Also here, all but the highest fidelity simulcast stream are initially paused. Note that the lower resolution is more prioritized than the medium resolution simulcast stream. Fred's client is also using BUNDLE to send all RTP streams from all media descriptions in the same RTP session on a single media transport. Although using many different simulcast streams in this example, the use of RtpStreamId as simulcast stream identification enables use of a low number of RTP payload types. Note that the use of both BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and "a=rid" [I-D.ietf-mmusic-rid] recommends using the RTP header extension [RFC8285] for carrying these RTP stream identification fields, which is consequently also included in the SDP. Note also that for "a=rid", the corresponding RtpStreamId SDES attribute RTP header extension is named rtp-stream-id [I-D.ietf-avtext-rid]. Burman, et al. Expires September 6, 2019 [Page 19] Internet-Draft Simulcast March 2019 v=0 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d s=Offer from Simulcast Enabled Multi-Source Client c=IN IP6 2001:db8::c000:27d t=0 0 a=group:BUNDLE foo bar zen m=audio 49200 RTP/AVP 99 a=mid:foo a=rtpmap:99 G722/8000 m=video 49600 RTP/AVPF 100 101 103 a=mid:bar a=rtpmap:100 H264-SVC/90000 a=rtpmap:101 H264/90000 a=rtpmap:103 VP8/90000 a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \ mst-mode=NI-TC a=fmtp:101 profile-level-id=42c00d;max-fs=3600;max-mbps=108000 a=fmtp:103 max-fs=900; max-fr=30 a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2 a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=101;max-width=640;max-height=360 a=rid:4 send pt=103;max-width=640;max-height=360 a=depend:100 lay bar:101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:* ccm pause nowait a=simulcast:send 1;2;~4,3 m=video 49602 RTP/AVPF 96 104 a=mid:zen a=rtpmap:96 VP8/90000 a=fmtp:96 max-fs=3600; max-fr=30 a=rtpmap:104 rtx/90000 a=fmtp:104 apt=96;rtx-time=200 a=rid:1 send max-fs=921600;max-fps=30 a=rid:2 send max-fs=614400;max-fps=15 a=rid:3 send max-fs=230400;max-fps=30 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=rtcp-fb:* ccm pause nowait a=simulcast:send 1;~3;~2 Figure 7: Fred's Multi-Source Simulcast Offer Burman, et al. Expires September 6, 2019 [Page 20] Internet-Draft Simulcast March 2019 5.6.3. Simulcast and Redundancy The example in this section looks at applying simulcast with audio and video redundancy formats. The audio media description uses codec and bitrate restrictions, combining it with RTP Payload for Redundant Audio Data [RFC2198] for enhanced packet loss resilience. The video media description applies both resolution and bitrate restrictions, combining it with FEC in the form of Flexible FEC [I-D.ietf-payload-flexible-fec-scheme] and RTP Retransmission [RFC4588]. The audio source is offered to be sent as two simulcast streams. The first simulcast stream is encoded with Opus, restricted to 50 kbps (rid-id=5), and the second simulcast stream is encoded either with G.711 (rid-id=7) or with G.711 combined with LPC for redundancy (rid- id=6). In this example, stand-alone LPC is not offered as an possible payload type for the second simulcast stream's RID, which could e.g. be motivated by not providing sufficient quality. The video source is offered to be sent as two simulcast streams, both with two alternative simulcast formats. Redundancy and repair are offered in the form of both Flexible FEC and RTP Retransmission. The Flexible FEC is not bound to any particular RTP streams and is therefore possible to use across all RTP streams that are being sent as part of this media description. Burman, et al. Expires September 6, 2019 [Page 21] Internet-Draft Simulcast March 2019 v=0 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d s=Offer from Simulcast Enabled Client using Redundancy c=IN IP6 2001:db8::c000:27d t=0 0 a=group:BUNDLE foo bar m=audio 49200 RTP/AVP 97 98 99 100 101 102 a=mid:foo a=rtpmap:97 G711/8000 a=rtpmap:98 LPC/8000 a=rtpmap:99 OPUS/48000/1 a=rtpmap:100 RED/8000/1 a=rtpmap:101 CN/8000 a=rtpmap:102 telephone-event/8000 a=fmtp:99 useinbandfec=1;usedtx=0 a=fmtp:100 97/98 a=fmtp:102 0-15 a=ptime:20 a=maxptime:40 a=rid:1 send pt=99,102;max-br=64000 a=rid:2 send pt=100,97,101,102 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=simulcast:send 1;2 m=video 49600 RTP/AVPF 103 104 105 106 107 a=mid:bar a=rtpmap:103 H264/90000 a=rtpmap:104 VP8/90000 a=rtpmap:105 rtx/90000 a=rtpmap:106 rtx/90000 a=rtpmap:107 flexfec/90000 a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000 a=fmtp:104 max-fs=3600; max-fr=30 a=fmtp:105 apt=103;rtx-time=200 a=fmtp:106 apt=104;rtx-time=200 a=fmtp:107 repair-window=2000 a=rid:1 send pt=103;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104;max-width=1280;max-height=720;max-fps=30 a=rid:3 send pt=103;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104;max-width=640;max-height=360;max-br=300000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=rtcp-fb:* ccm pause nowait a=simulcast:send 1,2;3,4 Figure 8: Simulcast and Redundancy Example Burman, et al. Expires September 6, 2019 [Page 22] Internet-Draft Simulcast March 2019 6. RTP Aspects This section discusses what the different entities in a simulcast media path can expect to happen on RTP level. This is explored from source to sink by starting in an endpoint with a media source that is simulcasted to an RTP middlebox. That RTP middlebox sends media sources both to other RTP middleboxes (cascaded middleboxes), as well as selecting some simulcast format of the media source and sending it to receiving endpoints. Different types of RTP middleboxes and their usage of the different simulcast formats results in several different behaviors. 6.1. Outgoing from Endpoint with Media Source The most straightforward simulcast case is the RTP streams being emitted from the endpoint that originates a media source. When simulcast has been negotiated in the sending direction, the endpoint can transmit up to the number of RTP streams needed for the negotiated simulcast streams for that media source. Each RTP stream (SSRC) is identified by associating (Section 5.5) it with an RtpStreamId SDES item, transmitted in RTCP and possibly also as an RTP header extension. In cases where multiple media sources have been negotiated for the same RTP session and thus BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] is used, also the MID SDES item will be sent similarly to the RtpStreamId. Each RTP stream might not be continuously transmitted due to any of the following reasons; temporarily paused using Pause/Resume [RFC7728], sender side application logic temporarily pausing it, or lack of network resources to transmit this simulcast stream. However, all simulcast streams that have been negotiated have active and maintained SSRC (at least in regular RTCP reports), even if no RTP packets are currently transmitted. The relation between an RTP Stream (SSRC) and a particular simulcast stream is not expected to change, except in exceptional situations such as SSRC collisions. At SSRC changes, the usage of MID and RtpStreamId should enable the receiver to correctly identify the RTP streams even after an SSRC change. 6.2. RTP Middlebox to Receiver RTP streams in a multi-party RTP session can be used in multiple different ways, when the session utilizes simulcast at least on the media source to middlebox legs. This is to a large degree due to the different RTP middlebox behaviors, but also the needs of the application. This text assumes that the RTP middlebox will select a media source and choose which simulcast stream for that media source to deliver to a specific receiver. In many cases, at most one Burman, et al. Expires September 6, 2019 [Page 23] Internet-Draft Simulcast March 2019 simulcast stream per media source will be forwarded to a particular receiver at any instant in time, even if the selected simulcast stream may vary. For cases where this does not hold due to application needs, then the RTP stream aspects will fall under the middlebox to middlebox case Section 6.3. The selection of which simulcast streams to forward towards the receiver, is application specific. However, in conferencing applications, active speaker selection is common. In case the number of media sources possible to forward, N, is less than the total amount of media sources available in an multi-media session, the current and previous speakers (up to N in total) are often the ones forwarded. To avoid the need for media specific processing to determine the current speaker(s) in the RTP middlebox, the endpoint providing a media source may include meta data, such as the RTP Header Extension for Client-to-Mixer Audio Level Indication [RFC6464]. The possibilities for stream switching are media type specific, but for media types with significant interframe dependencies in the encoding, like most video coding, the switching needs to be made at suitable switching points in the media stream that breaks or otherwise deals with the dependency structure. Even if switching points can be included periodically, it is common to use mechanisms like Full Intra Requests [RFC5104] to request switching points from the endpoint performing the encoding of the media source. Inclusion of the RtpStreamId SDES item for an SSRC in the middlebox to receiver direction should only occur when use of RtpStreamId has been negotiated in that direction. It is worth noting that one can signal multiple RtpStreamIds when simulcast signalling indicates only a single simulcast stream, allowing one to use all of the RtpStreamIds as alternatives for that simulcast stream. One reason for including the RtpStreamId in the middlebox to receiver direction for an RTP stream is to let the receiver know which restrictions apply to the currently delivered RTP stream. In case the RtpStreamId is negotiated to be used, it is important to remember that the used identifiers will be specific to each signalling session. Even if the central entity can attempt to coordinate, it is likely that the RtpStreamIds need to be translated to the leg specific values. The below cases will have as base line that RtpStreamId is not used in the mixer to receiver direction. 6.2.1. Media-Switching Mixer This section discusses the behavior in cases where the RTP middlebox behaves like the Media-Switching Mixer (Section 3.6.2) in RTP Topologies [RFC7667]. The fundamental aspect here is that the media Burman, et al. Expires September 6, 2019 [Page 24] Internet-Draft Simulcast March 2019 sources delivered from the middlebox will be the mixer's conceptual or functional ones. For example, one media source may be the main speaker in high resolution video, while a number of other media sources are thumbnails of each participant. The above results in that the RTP stream produced by the mixer is one that switches between a number of received incoming RTP streams for different media sources and in different simulcast versions. The mixer selects the media source to be sent as one of the RTP streams, and then selects among the available simulcast streams for the most appropriate one. The selection criteria include available bandwidth on the mixer to receiver path and restrictions based on the functional usage of the RTP stream delivered to the receiver. As an example of the latter, it is unnecessary to forward a full HD video to a receiver if the display area is just a thumbnail. Thus, restrictions may exist to not allow some simulcast streams to be forwarded for some of the mixer's media sources. This will result in a single RTP stream being used for each of the RTP mixer's media sources. This RTP stream is at any point in time a selection of one particular RTP stream arriving to the mixer, where the RTP header field values are rewritten to provide a consistent, single RTP stream. If the RTP mixer doesn't receive any incoming stream matched to this media source, the SSRC will not transmit, but be kept alive using RTCP. The SSRC and thus RTP stream for the mixer's media source is expected to be long term stable. It will only be changed by signalling or other disruptive events. Note that although the above talks about a single RTP stream, there can in some cases be multiple RTP streams carrying the selected simulcast stream for the originating media source, including redundancy or other auxiliary RTP streams. The mixer may communicate the identity of the originating media source to the receiver by including the CSRC field with the originating media source's SSRC value. Note that due to the possibility that the RTP mixer switches between simulcast versions of the media source, the CSRC value may change, even if the media source is kept the same. It is important to note that any MID SDES item from the originating media source needs to be removed and not be associated with the RTP stream's SSRC. That is, there is nothing in the signalling between the mixer and the receiver that is structured around the originating media sources, only the mixer's media sources. If they would be associated with the SSRC, the receiver would likely believe that there has been an SSRC collision, and that the RTP stream is spurious as it doesn't carry the identifiers used to relate it to the correct context. However, this is not true for CSRC values, as long as they Burman, et al. Expires September 6, 2019 [Page 25] Internet-Draft Simulcast March 2019 are never used as SSRC. In these cases one could provide CNAME and MID as SDES items. A receiver could use this to determine which CSRC values that are associated with the same originating media source. If RtpStreamIds are used in the scenario described by this section, it should be noted that the RtpStreamId on a particular SSRC will change based on the actual simulcast stream selected for switching. These RtpStreamId identifiers will be local to this leg's signalling context. In addition, the defined RtpStreamIds and their parameters need to cover all the media sources and simulcast streams received by the RTP mixer that can be switched into this media source, sent by the RTP mixer. 6.2.2. Selective Forwarding Middlebox This section discusses the behavior in cases where the RTP middlebox behaves like the Selective Forwarding Middlebox (Section 3.7) in RTP Topologies [RFC7667]. Applications for this type of RTP middlebox results in that each originating media source will have a corresponding media source on the leg between the middlebox and the receiver. A Selective Forwarding Middlebox (SFM) could go as far as exposing all the simulcast streams for an media source, however this section will focus on having a single simulcast stream that can contain any of the simulcast formats. This section will assume that the SFM projection mechanism works on media source level, and maps one of the media source's simulcast streams onto one RTP stream from the SFM to the receiver. This usage will result in that the individual RTP stream(s) for one media source can switch between being active to paused, based on the subset of media sources the SFM wants to provide the receiver for the moment. With SFMs there exist no reasons to use CSRC to indicate the originating stream, as there is a one to one media source mapping. If the application requires knowing the simulcast version received to function well, then RtpStreamId should be negotiated on the SFM to receiver leg. Which simulcast stream that is being forwarded is not made explicit unless RtpStreamId is used on the leg. Any MID SDES items being sent by the SFM to the receiver are only those agreed between the SFM and the receiver, and no MID values from the originating side of the SFM are to be forwarded. A SFM could expose corresponding RTP streams for all the media sources and their simulcast streams, and then for any media source that is to be provided forward one selected simulcast stream. However, this is not recommended as it would unnecessarily increase the number of RTP streams and require the receiver to timely detect switching between simulcast streams. The above usage requires the Burman, et al. Expires September 6, 2019 [Page 26] Internet-Draft Simulcast March 2019 same SFM functionality for switching, while avoiding the uncertainties of timely detecting that a RTP stream ends. The benefit would be that the received simulcast stream would be implicitly provided by which RTP stream would be active for a media source. However, using RtpStreamId to make this explicit also exposes which alternative format is used. The conclusion is that using one RTP stream per simulcast stream is unnecessary. The issue with timely detecting end of streams, independent if they are stopped temporarily or long term, is that there is no explicit indication that the transmission has intentionally been stopped. The RTCP based Pause and Resume mechanism [RFC7728] includes a PAUSED indication that provides the last RTP sequence number transmitted prior to the pause. Due to usage, the timeliness of this solution depends on when delivery using RTCP can occur in relation to the transmission of the last RTP packet. If no explicit information is provided at all, then detection based on non increasing RTCP SR field values and timers need to be used to determine pause in RTP packet delivery. This results in that one can usually not determine when the last RTP packet arrives (if it arrives) that this will be the last. That it was the last is something that one learns later. 6.3. RTP Middlebox to RTP Middlebox This relates to the transmission of simulcast streams between RTP middleboxes or other usages where one wants to enable the delivery of multiple simultaneous simulcast streams per media source, but the transmitting entity is not the originating endpoint. For a particular direction between middlebox A and B, this looks very similar to the originating to middlebox case on a media source basis. However, in this case there is usually multiple media sources, originating from multiple endpoints. This can create situations where limitations in the number of simultaneously received media streams can arise, for example due to limitation in network bandwidth. In this case, a subset of not only the simulcast streams, but also media sources can be selected. This results in that individual RTP streams can be become paused at any point and later being resumed based on various criteria. The MIDs used between A and B are the ones agreed between these two identities in signalling. The RtpStreamId values will also be provided to ensure explicit information about which simulcast stream they are. The RTP stream to MID and RtpStreamId associations should here be long term stable. Burman, et al. Expires September 6, 2019 [Page 27] Internet-Draft Simulcast March 2019 7. Network Aspects Simulcast is in this memo defined as the act of sending multiple alternative encoded streams of the same underlying media source. When transmitting multiple independent streams that originate from the same source, it could potentially be done in several different ways using RTP. A general discussion on considerations for use of the different RTP multiplexing alternatives can be found in Guidelines for Multiplexing in RTP [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and clarification on how to handle multiple streams in an RTP session can be found in [RFC8108]. The network aspects that are relevant for simulcast are: Quality of Service: When using simulcast it might be of interest to prioritize a particular simulcast stream, rather than applying equal treatment to all streams. For example, lower bitrate streams may be prioritized over higher bitrate streams to minimize congestion or packet losses in the low bitrate streams. Thus, there is a benefit to use a simulcast solution with good QoS support. NAT/FW Traversal: Using multiple RTP sessions incurs more cost for NAT/FW traversal unless they can re-use the same transport flow, which can be achieved by Multiplexing Negotiation Using SDP Port Numbers [I-D.ietf-mmusic-sdp-bundle-negotiation]. 7.1. Bitrate Adaptation Use of multiple simulcast streams can require a significant amount of network resources. The aggregate bandwidth for all simulcast streams for a media source (and thus SDP media description) is bounded by any SDP "b=" line applicable to that media source. It is assumed that a suitable congestion control mechanism is used by the application to ensure that it doesn't cause persistent congestion. If the amount of available network resources varies during an RTP session such that it does not match what is negotiated in SDP, the bitrate used by the different simulcast streams may have to be reduced dynamically. When a simulcasting media source uses a single media transport for all of the simulcast streams, it is likely that a joint congestion control across all simulcast streams is used for that media source. What simulcast streams to prioritize when allocating available bitrate among the simulcast streams in such adaptation SHOULD be taken from the simulcast stream order on the "a=simulcast" line and ordering of alternative simulcast formats Section 5.2. Simulcast streams that have pause/resume capability and that would be given such low bitrate Burman, et al. Expires September 6, 2019 [Page 28] Internet-Draft Simulcast March 2019 by the adaptation process that they are considered not really useful can be temporarily paused until the limiting condition clears. 8. Limitation The chosen approach has a limitation that relates to the use of a single RTP session for all simulcast formats of a media source, which comes from sending all simulcast streams related to a media source under the same SDP media description. It is not possible to use different simulcast streams on different media transports, limiting the possibilities to apply different QoS to different simulcast streams. When using unicast, QoS mechanisms based on individual packet marking are feasible, since they do not require separation of simulcast streams into different RTP sessions to apply different QoS. It is also not possible to separate different simulcast streams into different multicast groups to allow a multicast receiver to pick the stream it wants, rather than receive all of them. In this case, the only reasonable implementation is to use different RTP sessions for each multicast group so that reporting and other RTCP functions operate as intended. Such simulcast usage in multicast context is out of scope for the current document and would require additional specification. 9. IANA Considerations This document requests to register a new media-level SDP attribute, "simulcast", in the "att-field (media level only)" registry within the SDP parameters registry, according to the procedures of [RFC4566] and [I-D.ietf-mmusic-sdp-mux-attributes]. Contact name, email: The IESG (iesg@ietf.org) Attribute name: simulcast Long-form attribute name: Simulcast stream description Charset dependent: No Attribute value: sc-value; see Section 5.1 of RFC XXXX. Purpose: Signals simulcast capability for a set of RTP streams MUX category: NORMAL Burman, et al. Expires September 6, 2019 [Page 29] Internet-Draft Simulcast March 2019 Note to RFC Editor: Please replace "RFC XXXX" with the assigned number of this RFC. 10. Security Considerations The simulcast capability, configuration attributes, and parameters are vulnerable to attacks in signaling. A false inclusion of the "a=simulcast" attribute may result in simultaneous transmission of multiple RTP streams that would otherwise not be generated. The impact is limited by the media description joint bandwidth, shared by all simulcast streams irrespective of their number. There may however be a large number of unwanted RTP streams that will impact the share of bandwidth allocated for the originally wanted RTP stream. A hostile removal of the "a=simulcast" attribute will result in simulcast not being used. Neither of the above will likely have any major consequences and can be mitigated by signaling that is at least integrity and source authenticated to prevent an attacker to change it. Security considerations related to the use of "a=rid" and the RtpStreamId SDES item is covered in [I-D.ietf-mmusic-rid] and [I-D.ietf-avtext-rid]. There are no additional security concerns related to their use in this specification. 11. Contributors Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have contributed with important material to the first versions of this document. Robert Hansen and Cullen Jennings, from Cisco, Peter Thatcher, from Google, and Adam Roach, from Mozilla, contributed significantly to subsequent versions. 12. Acknowledgements The authors would like to thank Bernard Aboba, Thomas Belling, Roni Even, Adam Roach, Inaki Baz Castillo, Paul Kyzivat, and Arun Arunachalam for the feedback they provided during the development of this document. 13. References Burman, et al. Expires September 6, 2019 [Page 30] Internet-Draft Simulcast March 2019 13.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [I-D.ietf-mmusic-rid] Roach, A., "RTP Payload Format Restrictions", draft-ietf- mmusic-rid-15 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . [RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, February 2016, . Burman, et al. Expires September 6, 2019 [Page 31] Internet-Draft Simulcast March 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., and R. Even, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft- ietf-avtcore-multiplex-guidelines-08 (work in progress), December 2018. [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-17 (work in progress), February 2019. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . Burman, et al. Expires September 6, 2019 [Page 32] Internet-Draft Simulcast March 2019 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, . [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, . [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, . [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, . [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping Semantics in the Session Description Protocol", RFC 7104, DOI 10.17487/RFC7104, January 2014, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . Burman, et al. Expires September 6, 2019 [Page 33] Internet-Draft Simulcast March 2019 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . Appendix A. Requirements The following requirements are met by the defined solution to support the use cases (Section 3): REQ-1: Identification: REQ-1.1: It must be possible to identify a set of simulcasted RTP streams as originating from the same media source in SDP signaling. REQ-1.2: An RTP endpoint must be capable of identifying the simulcast stream a received RTP stream is associated with, knowing the content of the SDP signalling. REQ-2: Transport usage. The solution must work when using: REQ-2.1: Legacy SDP with separate media transports per SDP media description. REQ-2.2: Bundled [I-D.ietf-mmusic-sdp-bundle-negotiation] SDP media descriptions. REQ-3: Capability negotiation. It must be possible that: REQ-3.1: Sender can express capability of sending simulcast. REQ-3.2: Receiver can express capability of receiving simulcast. REQ-3.3: Sender can express maximum number of simulcast streams that can be provided. Burman, et al. Expires September 6, 2019 [Page 34] Internet-Draft Simulcast March 2019 REQ-3.4: Receiver can express maximum number of simulcast streams that can be received. REQ-3.5: Sender can detail the characteristics of the simulcast streams that can be provided. REQ-3.6: Receiver can detail the characteristics of the simulcast streams that it prefers to receive. REQ-4: Distinguishing features. It must be possible to have different simulcast streams use different codec parameters, as can be expressed by SDP format values and RTP payload types. REQ-5: Compatibility. It must be possible to use simulcast in combination with other RTP mechanisms that generate additional RTP streams: REQ-5.1: RTP Retransmission [RFC4588]. REQ-5.2: RTP Forward Error Correction [RFC5109]. REQ-5.3: Related payload types such as audio Comfort Noise and/or DTMF. REQ-5.4: A single simulcast stream can consist of multiple RTP streams, to support codecs where a dependent stream is dependent on a set of encoded and dependent streams, each potentially carried in their own RTP stream. REQ-6: Interoperability. The solution must be possible to use in: REQ-6.1: Interworking with non-simulcast legacy clients using a single media source per media type. REQ-6.2: WebRTC environment with a single media source per SDP media description. Appendix B. Changes From Earlier Versions NOTE TO RFC EDITOR: Please remove this section prior to publication. B.1. Modifications Between WG Version -13 and -14 o c= and t= line order corrected in SDP examples Burman, et al. Expires September 6, 2019 [Page 35] Internet-Draft Simulcast March 2019 B.2. Modifications Between WG Version -12 and -13 o Examples corrected to follow RID ABNF o Example Figure 7 now comments on priority for second media source. o Clarified a SHOULD limitation. o Added urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id in examples with RTX. o ABNF now uses RFC 7405 to indicate case sensitivity o Various minor editorials and nits. B.3. Modifications Between WG Version -11 and -12 o Modified Normative statement regarding RTP stream duplication in Section 5.2. o Clarified assumption about use of congestion control by applications. o Changed to use RFC 8174 boilerplate instead of RFC 2119. o Clarified explanation of syntax for simulcast attribute in Section 4. o Editorial clarification in Section 5.2 and 5.3.2. o Various minor editorials and nits. B.4. Modifications Between WG Version -10 and -11 o Added new SDP example section on Simulcast and Redundancy, including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft- ietf-payload-flexible-fec-scheme). o Removed restriction that "related" payload formats in an RTP stream (such as CN and DTMF) must not have their own rid-id, since there is no reason to forbid this and corresponding clarification is made in draft-ietf-mmusic-rid. o Removed any mention of source-specific signaling and the reference to RFC5576, since draft-ietf-mmusic-rid is not defined for source- specific signaling. Burman, et al. Expires September 6, 2019 [Page 36] Internet-Draft Simulcast March 2019 o Changed some SDP examples to use a=rid restrictions instead of a=imageattr. o Changed reference from the obsoleted RFC 5285 to RFC 8285. B.5. Modifications Between WG Version -09 and -10 o Amended overview section with a bit more explanation on the examples, and added an rid-id alternative for one of the streams. o Removed SCID also from the Terminology section, which was forgotten in -09 when changing SCID to rid-id. B.6. Modifications Between WG Version -08 and -09 o Changed SCID to rid-id, to align with ietf-draft-mmusic-rid naming. o Changed Overview to be based on examples and shortened it. o Changed semantics of initially paused rid-id in modified SDP offers from requiring it to follow actual RFC 7728 pause state to an informational offerer's opinion at the time of offer creation, not in any way overriding or amending RFC 7728 signaling. o Replaced text on ignoring all but the first of multiple "a=simulcast" lines in a media description with mandating that at most one "a=simulcast" line is included. o Clarified with a note that, for the case it is clear from the SDP that RTP PT uniquely maps to RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. o Moved Section 4 Requirements to become Appendix A. o Editorial corrections and clarifications. B.7. Modifications Between WG Version -07 and -08 o Correcting syntax of SDP examples in section 6.6.1, as found by Inaki Baz Castillo. o Changing ABNF to only define the sc-value, not the SDP attribute itself, as suggested by Paul Kyzivat. o Changing I-D reference to newly published RFC 8108. o Adding list of modifications between -06 and -07. Burman, et al. Expires September 6, 2019 [Page 37] Internet-Draft Simulcast March 2019 B.8. Modifications Between WG Version -06 and -07 o A scope clarification, as result of the discussion with Roni Even. o A reformulation of the identification requirements for simulcast stream. o Correcting the statement related to source specific signalling (RFC 5576) to address Roni Even's comment. o Update of the last paragraph in Section 6.2 regarding simulcast stream differences as well as forbidding multiple instances of the same SCID within a single a=simulcast line. o Removal of note in Section 6.4 as result of issue raised by Roni Even. o Use of "m=" has been changed to media description and a few other editorial improvements and clarifications. B.9. Modifications Between WG Version -05 and -06 o Added section on RTP Aspects o Added a requirement (5-4) on that capability exchange must be capable of handling multi RTP stream cases. o Added extmap attribute also on first signalling example as it is a recommended to use mechanism. o Clarified the definition of the simulcast attribute and how simulcast streams relates to simulcast formats and SCIDs. o Updated References list and moved around some references between informative and normative categories. o Editorial improvements and corrections. B.10. Modifications Between WG Version -04 and -05 o Aligned with recent changes in draft-ietf-mmusic-rid and draft- ietf-avtext-rid. o Modified the SDP offer/answer section to follow the generally accepted structure, also adding a brief text on modifying the session that is aligned with draft-ietf-mmusic-rid. Burman, et al. Expires September 6, 2019 [Page 38] Internet-Draft Simulcast March 2019 o Improved text around simulcast stream identification (as opposed to the simulcast stream itself) to consistently use the acronym SCID and defined that in the Terminology section. o Changed references for RTP-level pause/resume and VP8 payload format that are now published as RFC. o Improved IANA registration text. o Removed unused reference to draft-ietf-payload-flexible-fec- scheme. o Editorial improvements and corrections. B.11. Modifications Between WG Version -03 and -04 o Changed to only use RID identification, as was consensus during IETF 94. o ABNF improvements. o Clarified offer-answer rules for initially paused streams. o Changed references for RTP topologies and RTP taxonomy documents that are now published as RFC. o Added reference to the new RID draft in AVTEXT. o Re-structured section 6 to provide an easy reference by the updated IANA section. o Added a sub-section 7.1 with a discussion of bitrate adaptation. o Editorial improvements. B.12. Modifications Between WG Version -02 and -03 o Removed text on multicast / broadcast from use cases, since it is not supported by the solution. o Removed explicit references to unified plan draft. o Added possibility to initiate simulcast streams in paused mode. o Enabled an offerer to offer multiple stream identification (pt or rid) methods and have the answerer choose which to use. o Added a preference indication also in send direction offers. Burman, et al. Expires September 6, 2019 [Page 39] Internet-Draft Simulcast March 2019 o Added a section on limitations of the current proposal, including identification method specific limitations. B.13. Modifications Between WG Version -01 and -02 o Relying on the new RID solution for codec constraints and configuration identification. This has resulted in changes in syntax to identify if pt or RID is used to describe the simulcast stream. o Renamed simulcast version and simulcast version alternative to simulcast stream and simulcast format respectively, and improved definitions for them. o Clarification that it is possible to switch between simulcast version alternatives, but that only a single one be used at any point in time. o Changed the definition so that ordering of simulcast formats for a specific simulcast stream do have a preference order. B.14. Modifications Between WG Version -00 and -01 o No changes. Only preventing expiry. B.15. Modifications Between Individual Version -00 and WG Version -00 o Added this appendix. Authors' Addresses Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Stockholm Sweden Email: bo.burman@ericsson.com Magnus Westerlund Ericsson Torshamnsgatan 23 SE-164 83 Stockholm Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Burman, et al. Expires September 6, 2019 [Page 40] Internet-Draft Simulcast March 2019 Suhas Nandakumar Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: snandaku@cisco.com Mo Zanaty Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: mzanaty@cisco.com Burman, et al. Expires September 6, 2019 [Page 41] ./draft-ietf-mmusic-sdp-uks-07.txt0000644000764400076440000013445613523403303016251 0ustar iustyiusty Network Working Group M. Thomson Internet-Draft E. Rescorla Updates: 8122 (if approved) Mozilla Intended status: Standards Track August 09, 2019 Expires: February 10, 2020 Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP) draft-ietf-mmusic-sdp-uks-07 Abstract This document describes unknown key-share attacks on the use of Datagram Transport Layer Security for the Secure Real-Time Transport Protocol (DTLS-SRTP). Similar attacks are described on the use of DTLS-SRTP with the identity bindings used in Web Real-Time Communications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be mislead about the identity of a communicating peer. Mitigation techniques are defined that implementations of RFC 8122 are encouraged to deploy. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 10, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Thomson & Rescorla Expires February 10, 2020 [Page 1] Internet-Draft SDP UKS August 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Unknown Key-Share Attack . . . . . . . . . . . . . . . . . . 3 2.1. Limits on Attack Feasibility . . . . . . . . . . . . . . 4 2.2. Interactions with Key Continuity . . . . . . . . . . . . 5 2.3. Third-Party Call Control . . . . . . . . . . . . . . . . 5 3. Unknown Key-Share with Identity Bindings . . . . . . . . . . 6 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. The external_id_hash TLS Extension . . . . . . . . . . . 8 3.2.1. Calculating external_id_hash for WebRTC Identity . . 9 3.2.2. Calculating external_id_hash for PASSPoRT . . . . . . 10 4. Unknown Key-Share with Fingerprints . . . . . . . . . . . . . 10 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Unique Session Identity Solution . . . . . . . . . . . . 12 4.3. The external_session_id TLS Extension . . . . . . . . . . 13 5. Session Concatenation . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The use of Transport Layer Security (TLS) [TLS13] with the Session Description Protocol (SDP) [SDP] is defined in [FINGERPRINT]. Further use with Datagram Transport Layer Security (DTLS) [DTLS] and the Secure Real-time Transport Protocol (SRTP) [SRTP] is defined as DTLS-SRTP [DTLS-SRTP]. In these specifications, key agreement is performed using TLS or DTLS, with authentication being tied back to the session description (or SDP) through the use of certificate fingerprints. Communication peers check that a hash, or fingerprint, provided in the SDP matches the certificate that is used in the TLS or DTLS handshake. WebRTC identity (see Section 7 of [WEBRTC-SEC]) and SIP identity [SIP-ID] both provide a mechanism that binds an external identity to the certificate fingerprints from a session description. However, Thomson & Rescorla Expires February 10, 2020 [Page 2] Internet-Draft SDP UKS August 2019 this binding is not integrity-protected and therefore vulnerable to an identity misbinding attack - or unknown key-share (UKS) attack - where the attacker binds their identity to the fingerprint of another entity. A successful attack leads to the creation of sessions where peers are confused about the identity of the participants. This document describes a TLS extension that can be used in combination with these identity bindings to prevent this attack. A similar attack is possible with the use of certificate fingerprints alone. Though attacks in this setting are likely infeasible in existing deployments due to the narrow conditions necessary (see Section 2.1), this document also describes mitigations for this attack. The mechanisms defined in this document are intended to strengthen the protocol by preventing the use of unknown key shares in combination with other protocol or implementation vulnerabilities. RFC 8122 [FINGERPRINT] is updated by this document to recommend the use of these mechanisms. This document assumes that signaling is integrity protected. However, as Section 7 of [FINGERPRINT] explains, many deployments that use SDP do not guarantee integrity of session signaling and so are vulnerable to other attacks. [FINGERPRINT] offers key continuity mechanisms as a potential means of reducing exposure to attack in the absence of integrity protection. Section 2.2 provides some analysis of the effect of key continuity in relation to the described attacks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Unknown Key-Share Attack In an unknown key-share attack [UKS], a malicious participant in a protocol claims to control a key that is in reality controlled by some other actor. This arises when the identity associated with a key is not properly bound to the key. An endpoint that can acquire the certificate fingerprint of another entity can advertise that fingerprint as their own in SDP. An attacker can use a copy of that fingerprint to cause a victim to communicate with another unaware victim, even though it believes that it is communicating with the attacker. Thomson & Rescorla Expires February 10, 2020 [Page 3] Internet-Draft SDP UKS August 2019 When the identity of communicating peers is established by higher- layer signaling constructs, such as those in SIP identity [SIP-ID] or WebRTC [WEBRTC-SEC], this allows an attacker to bind their own identity to a session with any other entity. The attacker obtains an identity assertion for an identity it controls, but binds that to the fingerprint of one peer. The attacker is then able to cause a TLS connection to be established where two victim endpoints communicate. The victim that has its fingerprint copied by the attack correctly believes that it is communicating with the other victim; however, the other victim incorrectly believes that it is communicating with the attacker. An unknown key-share attack does not result in the attacker having access to any confidential information exchanged between victims. However, the failure in mutual authentication can enable other attacks. A victim might send information to the wrong entity as a result. Where information is interpreted in context, misrepresenting that context could lead to the information being misinterpreted. A similar attack can be mounted based solely on the SDP "fingerprint" attribute [FINGERPRINT] without compromising the integrity of the signaling channel. This attack is an aspect of SDP-based protocols that the technique known as third-party call control (3PCC) [RFC3725] relies on. 3PCC exploits the potential for the identity of a signaling peer to be different than the media peer, allowing the media peer to be selected by the signaling peer. Section 2.3 describes the consequences of the mitigations described here for systems that use 3PCC. 2.1. Limits on Attack Feasibility The use of TLS with SDP depends on the integrity of session signaling. Assuming signaling integrity limits the capabilities of an attacker in several ways. In particular: 1. An attacker can only modify the parts of the session signaling that they are responsible for producing, namely their own offers and answers. 2. No entity will successfully establish a session with a peer unless they are willing to participate in a session with that peer. The combination of these two constraints make the spectrum of possible attacks quite limited. An attacker is only able to switch its own certificate fingerprint for a valid certificate that is Thomson & Rescorla Expires February 10, 2020 [Page 4] Internet-Draft SDP UKS August 2019 acceptable to its peer. Attacks therefore rely on joining two separate sessions into a single session. Section 4 describes an attack on SDP signaling under these constraints. Systems that rely on strong identity bindings, such as those defined in [WEBRTC] or [SIP-ID], have a different threat model, which admits the possibility of attack by an entity with access to the signaling channel. Attacks under these conditions are more feasible as an attacker is assumed to be able to both observe and modify signaling messages. Section 3 describes an attack that assumes this threat model. 2.2. Interactions with Key Continuity Systems that use key continuity (as defined in Section 15.1 of [ZRTP] or as recommended in Section 7 of [FINGERPRINT]) might be able to detect an unknown key-share attack if a session with either the attacker or the genuine peer (i.e., the victim whose fingerprint was copied by an attacker) was established in the past. Whether this is possible depends on how key continuity is implemented. Implementations that maintain a single database of identities with an index on peer keys could discover that the identity saved for the peer key does not match the claimed identity. Such an implementation could notice the disparity between the actual keys (those copied from a victim) and the expected keys (those of the attacker). In comparison, implementations that first match based on peer identity could treat an unknown key-share attack as though their peer had used a newly-configured device. The apparent addition of a new device could generate user-visible notices (e.g., "Mallory appears to have a new device"). However, such an event is not always considered alarming; some implementations might silently save a new key. 2.3. Third-Party Call Control Third-party call control (3PCC) [RFC3725] is a technique where a signaling peer establishes a call that is terminated by a different entity. An unknown key-share attack is very similar in effect to some 3PCC practices, so use of 3PCC could appear to be an attack. However, 3PCC that follows RFC 3725 guidance is unaffected, and peers that are aware of changes made by a 3PCC controller can correctly distinguish actions of a 3PCC controller from attack. 3PCC as described in RFC 3725 is incompatible with SIP identity [SIP-ID] as SIP Identity relies on creating a binding between SIP requests and SDP. The controller is the only entity that generates SIP requests in RFC 3725. Therefore, in a 3PCC context, only the use Thomson & Rescorla Expires February 10, 2020 [Page 5] Internet-Draft SDP UKS August 2019 of the "fingerprint" attribute without additional bindings or WebRTC identity [WEBRTC-SEC] is possible. The attack mitigation mechanisms described in this document will prevent the use of 3PCC if peers have different views of the involved identities, or the value of SDP "tls-id" attributes. For 3PCC to work with the proposed mechanisms, TLS peers need to be aware of the signaling so that they can correctly generate and check the TLS extensions. For a connection to be successfully established, a 3PCC controller needs to either forward SDP without modification, or to avoid modifications to "fingerprint", "tls-id", and "identity" attributes. A controller that follows the best practices in RFC 3725 is expected to forward SDP without modification, thus ensuring the integrity of these attributes. 3. Unknown Key-Share with Identity Bindings The identity assertions used for WebRTC (Section 7 of [WEBRTC-SEC]) and the SIP PASSPoRT used in SIP identity ([SIP-ID], [PASSPoRT]) are bound to the certificate fingerprint of an endpoint. An attacker can cause an identity binding to be created that binds an identity they control to the fingerprint of a first victim. An attacker can thereby cause a second victim to believe that they are communicating with an attacker-controlled identity, when they are really talking to the first victim. The attacker does this by creating an identity assertion that covers a certificate fingerprint of the first victim. A variation on the same technique can be used to cause both victims to both believe they are talking to the attacker when they are talking to each other. In this case, the attacker performs the identity misbinding once for each victim. The problem might appear to be caused by the fact that the authority that certifies the identity binding is not required to verify that the entity requesting the binding controls the keys associated with the fingerprints. SIP and WebRTC identity providers are not required to perform this validation. However, validation of keys by the identity provider is not relevant because verifying control of the associated keys is not a necessary condition for a secure protocol, nor would it be sufficient to prevent attack [SIGMA]. A simple solution to this problem is suggested by [SIGMA]. The identity of endpoints is included under a message authentication code (MAC) during the cryptographic handshake. Endpoints then validate that their peer has provided an identity that matches their Thomson & Rescorla Expires February 10, 2020 [Page 6] Internet-Draft SDP UKS August 2019 expectations. In TLS, the Finished message provides a MAC over the entire handshake, so that including the identity in a TLS extension is sufficient to implement this solution. Rather than include a complete identity binding - which could be sizeable - a collision- and pre-image-resistant hash of the binding is included in a TLS extension as described in Section 3.2. Endpoints then need only validate that the extension contains a hash of the identity binding they received in signaling. If the identity binding is successfully validated, the identity of a peer is verified and bound to the session. This form of unknown key-share attack is possible without compromising signaling integrity, unless the defenses described in Section 4 are used. In order to prevent both forms of attack, endpoints MUST use the "external_session_id" extension (see Section 4.3) in addition to the "external_id_hash" (Section 3.2) so that two calls between the same parties can't be altered by an attacker. 3.1. Example In the example shown in Figure 1, it is assumed that the attacker also controls the signaling channel. Mallory (the attacker) presents two victims, Norma and Patsy, with two separate sessions. In the first session, Norma is presented with the option to communicate with Mallory; a second session with Norma is presented to Patsy. Norma Mallory Patsy (fp=N) ----- (fp=P) | | | |<---- Signaling1 ------>| | | Norma=N Mallory=P | | | |<---- Signaling2 ------>| | | Norma=N Patsy=P | | | |<=================DTLS (fp=N,P)=================>| | | (peer = Mallory!) (peer = Norma) Figure 1: Example Attack on Identity Bindings The attack requires that Mallory obtain an identity binding for her own identity with the fingerprints presented by Patsy (P), which Mallory might have obtained previously. This false binding is then presented to Norma (Signaling1 in the figure). Thomson & Rescorla Expires February 10, 2020 [Page 7] Internet-Draft SDP UKS August 2019 Patsy could be similarly duped, but in this example, a correct binding between Norma's identity and fingerprint (N) is faithfully presented by Mallory. This session (Signaling2 in the figure) can be entirely legitimate. A DTLS session is established directly between Norma and Patsy. In order for this to happen Mallory can substitute transport-level information in both sessions to facilitate this, though this is not necessary if Mallory is on the network path between Norma and Patsy. As a result, Patsy correctly believes that she is communicating with Norma. However, Norma incorrectly believes she is talking to Mallory. As stated in Section 2, Mallory cannot access media, but Norma might send information to Patsy that is Norma might not intend or that Patsy might misinterpret. 3.2. The external_id_hash TLS Extension The "external_id_hash" TLS extension carries a hash of the identity assertion that the endpoint sending the extension has asserted to its peer. Both peers include a hash of their own identity assertion. The "extension_data" for the "external_id_hash" extension contains a "ExternalIdentityHash" struct, described below using the syntax defined in Section 3 of [TLS13]: struct { opaque binding_hash<0..32>; } ExternalIdentityHash; Where an identity assertion has been asserted by a peer, this extension includes a SHA-256 hash of the assertion. An empty value is used to indicate support for the extension. Note: For both types of identity assertion, if SHA-256 should prove to be inadequate at some point in the future (see [AGILITY]), a new TLS extension can be defined that uses a different hash function. Identity bindings might be provided by only one peer. An endpoint that does not produce an identity binding MUST generate an empty "external_id_hash" extension in its ClientHello or - if a client provides the extension - in ServerHello or EncryptedExtensions. An empty extension has a zero-length binding_hash field. A peer that receives an "external_id_hash" extension that does not match the value of the identity binding from its peer MUST immediately fail the TLS handshake with a illegal_parameter alert. Thomson & Rescorla Expires February 10, 2020 [Page 8] Internet-Draft SDP UKS August 2019 The absence of an identity binding does not relax this requirement; if a peer provided no identity binding, a zero-length extension MUST be present to be considered valid. Implementations written prior to the definition of the extensions in this document will not support this extension for some time. A peer that receives an identity binding but does not receive an "external_id_hash" extension MAY accept a TLS connection rather than fail a connection where the extension is absent. Any validation performed of the "external_id_hash" extension is done in addition to the validation required by [FINGERPRINT] and any identity assertion definition. An "external_id_hash" extension that is any length other than 0 or 32 is invalid and MUST cause the receiving endpoint to generate a fatal "decode_error" alert. In TLS 1.3, an "external_id_hash" extension sent by a server MUST be sent in the EncryptedExtensions message. 3.2.1. Calculating external_id_hash for WebRTC Identity A WebRTC identity assertion (Section 7 of [WEBRTC-SEC]) is provided as a JSON [JSON] object that is encoded into a JSON text. The JSON text is encoded using UTF-8 [UTF8] as described by Section 8.1 of [JSON]. The content of the "external_id_hash" extension is produced by hashing the resulting octets with SHA-256 [SHA]. This produces the 32 octets of the "binding_hash" parameter, which is the sole contents of the extension. The SDP "identity" attribute includes the base64 [BASE64] encoding of the UTF-8 encoding of the same JSON text. The "external_id_hash" extension is validated by performing base64 decoding on the value of the SDP "identity" attribute, hashing the resulting octets using SHA- 256, and comparing the results with the content of the extension. In pseudocode form, using the "identity-assertion-value" field from the "identity" attribute grammar as defined in [WEBRTC-SEC]: "external_id_hash = SHA-256(b64decode(identity-assertion-value)) " Note: The base64 of the SDP "identity" attribute is decoded to avoid capturing variations in padding. The base64-decoded identity assertion could include leading or trailing whitespace octets. WebRTC identity assertions are not canonicalized; all octets are hashed. Thomson & Rescorla Expires February 10, 2020 [Page 9] Internet-Draft SDP UKS August 2019 3.2.2. Calculating external_id_hash for PASSPoRT Where the compact form of PASSPoRT [PASSPoRT] is used, it MUST be expanded into the full form. The base64 encoding used in the SIP Identity (or 'y') header field MUST be decoded then used as input to SHA-256. This produces the 32 octet "binding_hash" value used for creating or validating the extension. In pseudocode, using the "signed-identity-digest" field from the "Identity" grammar defined [SIP-ID]: "external_id_hash = SHA-256(b64decode(signed-identity-digest)) " 4. Unknown Key-Share with Fingerprints An attack on DTLS-SRTP is possible because the identity of peers involved is not established prior to establishing the call. Endpoints use certificate fingerprints as a proxy for authentication, but as long as fingerprints are used in multiple calls, they are vulnerable to attack. Even if the integrity of session signaling can be relied upon, an attacker might still be able to create a session where there is confusion about the communicating endpoints by substituting the fingerprint of a communicating endpoint. An endpoint that is configured to reuse a certificate can be attacked if it is willing to initiate two calls at the same time, one of which is with an attacker. The attacker can arrange for the victim to incorrectly believe that it is calling the attacker when it is in fact calling a second party. The second party correctly believes that it is talking to the victim. As with the attack on identity bindings, this can be used to cause two victims to both believe they are talking to the attacker when they are talking to each other. 4.1. Example To mount this attack, two sessions need to be created with the same endpoint at almost precisely the same time. One of those sessions is initiated with the attacker, the second session is created toward another honest endpoint. The attacker convinces the first endpoint that their session with the attacker has been successfully established, but media is exchanged with the other honest endpoint. The attacker permits the session with the other honest endpoint to complete only to the extent necessary to convince the other honest endpoint to participate in the attacked session. Thomson & Rescorla Expires February 10, 2020 [Page 10] Internet-Draft SDP UKS August 2019 In addition to the constraints described in Section 2.1, the attacker in this example also needs the ability to view and drop packets between victims. That is, the attacker is on-path for media. The attack shown in Figure 2 depends on a somewhat implausible set of conditions. It is intended to demonstrate what sort of attack is possible and what conditions are necessary to exploit this weakness in the protocol. Norma Mallory Patsy (fp=N) ----- (fp=P) | | | +---Signaling1 (fp=N)--->| | +-----Signaling2 (fp=N)------------------------>| |<-------------------------Signaling2 (fp=P)----+ |<---Signaling1 (fp=P)---+ | | | | |=======DTLS1=======>(Forward)======DTLS1======>| |<======DTLS2========(Forward)<=====DTLS2=======| |=======Media1======>(Forward)======Media1=====>| |<======Media2=======(Forward)<=====Media2======| | | | |=======DTLS2========>(Drop) | | | | Figure 2: Example Attack Scenario using Fingerprints In this scenario, there are two sessions initiated at the same time by Norma. Signaling is shown with single lines ('-'), DTLS and media with double lines ('='). The first session is established with Mallory, who falsely uses Patsy's certificate fingerprint (denoted with 'fp=P'). A second session is initiated between Norma and Patsy. Signaling for both sessions is permitted to complete. Once signaling is complete on the first session, a DTLS connection is established. Ostensibly, this connection is between Mallory and Norma but Mallory forwards DTLS and media packets sent to her by Norma to Patsy. These packets are denoted 'DTLS1' because Norma associates these with the first signaling session ('signaling1'). Mallory also intercepts packets from Patsy and forwards those to Norma at the transport address that Norma associates with Mallory. These packets are denoted 'DTLS2' to indicate that Patsy associates these with the second signaling session ('signaling2'), however Norma will interpret these as being associated with the first signaling session ('signaling1'). Thomson & Rescorla Expires February 10, 2020 [Page 11] Internet-Draft SDP UKS August 2019 The second signaling exchange - 'signaling2', between Norma and Patsy - is permitted to continue to the point where Patsy believes that it has succeeded. This ensures that Patsy believes that she is communicating with Norma. In the end, Norma believes that she is communicating with Mallory, when she is really communicating with Patsy. Just like the example in Section 3.1, Mallory cannot access media, but Norma might send information to Patsy that is Norma might not intend or that Patsy might misinterpret. Though Patsy needs to believe that the second signaling session has been successfully established, Mallory has no real interest in seeing that session also be established. Mallory only needs to ensure that Patsy maintains the active session and does not abandon the session prematurely. For this reason, it might be necessary to permit the signaling from Patsy to reach Norma to allow Patsy to receive a call setup completion signal, such as a SIP ACK. Once the second session is established, Mallory might cause DTLS packets sent by Norma to Patsy to be dropped. However, if Mallory allows DTLS packets to pass, it is likely that Patsy will discard them as Patsy will already have a successful DTLS connection established. For the attacked session to be sustained beyond the point that Norma detects errors in the second session, Mallory also needs to block any signaling that Norma might send to Patsy asking for the call to be abandoned. Otherwise, Patsy might receive a notice that the call is failed and thereby abort the call. This attack creates an asymmetry in the beliefs about the identity of peers. However, this attack is only possible if the victim (Norma) is willing to conduct two sessions nearly simultaneously, if the attacker (Mallory) is on the network path between the victims, and if the same certificate - and therefore SDP "fingerprint" attribute value - is used by Norma for both sessions. Where ICE [ICE] is used, Mallory also needs to ensure that connectivity checks between Patsy and Norma succeed, either by forwarding checks or answering and generating the necessary messages. 4.2. Unique Session Identity Solution The solution to this problem is to assign a new identifier to communicating peers. Each endpoint assigns their peer a unique identifier during call signaling. The peer echoes that identifier in the TLS handshake, binding that identity into the session. Including this new identity in the TLS handshake means that it will be covered by the TLS Finished message, which is necessary to authenticate it (see [SIGMA]). Thomson & Rescorla Expires February 10, 2020 [Page 12] Internet-Draft SDP UKS August 2019 Successful validation that the identifier matches the expected value means that the connection corresponds to the signaled session and is therefore established between the correct two endpoints. This solution relies on the unique identifier given to DTLS sessions using the SDP "tls-id" attribute [DTLS-SDP]. This field is already required to be unique. Thus, no two offers or answers from the same client will have the same value. A new "external_session_id" extension is added to the TLS or DTLS handshake for connections that are established as part of the same call or real-time session. This carries the value of the "tls-id" attribute and provides integrity protection for its exchange as part of the TLS or DTLS handshake. 4.3. The external_session_id TLS Extension The "external_session_id" TLS extension carries the unique identifier that an endpoint selects. When used with SDP, the value MUST include the "tls-id" attribute from the SDP that the endpoint generated when negotiating the session. This document only defines use of this extension for SDP; other methods of external session negotiation can use this extension to include a unique session identifier. The "extension_data" for the "external_session_id" extension contains an ExternalSessionId struct, described below using the syntax defined in [TLS13]: struct { opaque session_id<20..255>; } ExternalSessionId; For SDP, the "session_id" field of the extension includes the value of the "tls-id" SDP attribute as defined in [DTLS-SDP] (that is, the "tls-id-value" ABNF production). The value of the "tls-id" attribute is encoded using ASCII [ASCII]. Where RTP and RTCP [RTP] are not multiplexed, it is possible that the two separate DTLS connections carrying RTP and RTCP can be switched. This is considered benign since these protocols are designed to be distinguishable as SRTP [SRTP] provides key separation. Using RTP/ RTCP multiplexing [RTCP-MUX] further avoids this problem. The "external_session_id" extension is included in a ClientHello and - if the extension is present in the ClientHello - either ServerHello (for TLS and DTLS versions less than 1.3) or EncryptedExtensions (for TLS 1.3). Thomson & Rescorla Expires February 10, 2020 [Page 13] Internet-Draft SDP UKS August 2019 Endpoints MUST check that the "session_id" parameter in the extension that they receive includes the "tls-id" attribute value that they received in their peer's session description. Endpoints can perform string comparison by ASCII decoding the TLS extension value and comparing it to the SDP attribute value, or compare the encoded TLS extension octets with the encoded SDP attribute value. An endpoint that receives a "external_session_id" extension that is not identical to the value that it expects MUST abort the connection with a fatal "illegal_parameter" alert. Any validation performed of the "external_session_id" extension is done in addition to the validation required by [FINGERPRINT]. An endpoint that is communicating with a peer that does not support this extension will receive a ClientHello, ServerHello or EncryptedExtensions that does not include this extension. An endpoint MAY choose to continue a session without this extension in order to interoperate with peers that do not implement this specification. In TLS 1.3, an "external_session_id" extension sent by a server MUST be sent in the EncryptedExtensions message. This defense is not effective if an attacker can rewrite "tls-id" values in signaling. Only the mechanism in "external_id_hash" is able to defend against an attacker that can compromise session integrity. 5. Session Concatenation Use of session identifiers does not prevent an attacker from establishing two concurrent sessions with different peers and forwarding signaling from those peers to each other. Concatenating two signaling sessions in this way creates two signaling sessions, with two session identifiers, but only the TLS connections from a single session are established as a result. In doing so, the attacker creates a situation where both peers believe that they are talking to the attacker when they are talking to each other. In the absence of any higher-level concept of peer identity, the use of session identifiers does not prevent session concatenation if the attacker is able to copy the session identifier from one signaling session to another. This kind of attack is prevented by systems that enable peer authentication such as WebRTC identity [WEBRTC-SEC] or SIP identity [SIP-ID]. However, session concatenation remains possible at higher layers: an attacker can establish two independent sessions and simply forward any data it receives from one into the other. Thomson & Rescorla Expires February 10, 2020 [Page 14] Internet-Draft SDP UKS August 2019 Use of the "external_session_id" does not guarantee that the identity of the peer at the TLS layer is the same as the identity of the signaling peer. The advantage an attacker gains by concatenating sessions is limited unless data is exchanged on the assumption that signaling and TLS peers are the same. If a secondary protocol uses the signaling channel with the assumption that the signaling and TLS peers are the same then that protocol is vulnerable to attack. A signaling system that can defend against session concatenation, while out of scope for this document, requires that the signaling layer is authenticated and bound to any TLS connections. It is important to note that multiple connections can be created within the same signaling session. An attacker might concatenate only part of a session, choosing to terminate some connections (and optionally forward data) while arranging to have peers interact directly for other connections. It is even possible to have different peers interact for each connection. This means that the actual identity of the peer for one connection might differ from the peer on another connection. Critically, information about the identity of TLS peers provides no assurances about the identity of signaling peers and do not transfer between TLS connections in the same session. Information extracted from a TLS connection therefore MUST NOT be used in a secondary protocol outside of that connection if that protocol assumes that the signaling protocol has the same peers. Similarly, security-sensitive information from one TLS connection MUST NOT be used in other TLS connections even if they are established as a result of the same signaling session. 6. Security Considerations The mitigations in this document, when combined with identity assertions, ensure that there is no opportunity to misrepresent the identity of TLS peers. This assurance is provided even if an attacker can modify signaling messages. Without identity assertions, the mitigations in this document prevent the session splicing attack described in Section 4. Defense against session concatenation (Section 5) additionally requires protocol peers are not able to claim the certificate fingerprints of other entities. 7. IANA Considerations This document registers two extensions in the TLS "ExtensionType Values" registry established in [TLS13]: Thomson & Rescorla Expires February 10, 2020 [Page 15] Internet-Draft SDP UKS August 2019 o The "external_id_hash" extension defined in Section 3.2 has been assigned a code point of TBD; it is recommended and is marked as "CH, EE" in TLS 1.3. o The "external_session_id" extension defined in Section 4.3 has been assigned a code point of TBD; it is recommended and is marked as "CH, EE" in TLS 1.3. 8. References 8.1. Normative References [ASCII] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, . [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [DTLS-SDP] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 2017. [DTLS-SRTP] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [FINGERPRINT] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . Thomson & Rescorla Expires February 10, 2020 [Page 16] Internet-Draft SDP UKS August 2019 [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [PASSPoRT] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [SHA] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [SIP-ID] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . Thomson & Rescorla Expires February 10, 2020 [Page 17] Internet-Draft SDP UKS August 2019 [WEBRTC-SEC] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-20 (work in progress), July 2019. 8.2. Informative References [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [ICE] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RTCP-MUX] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc'approach to authenticated Diffie-Hellman and its use in the IKE protocols", Annual International Cryptology Conference, Springer, pp. 400-425 , 2003. [UKS] Blake-Wilson, S. and A. Menezes, "Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol", Lecture Notes in Computer Science 1560, Springer, pp. 154-170 , 1999. [WEBRTC] Bergkvist, A., Burnett, D., Narayanan, A., Jennings, C., Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Editor's Draft , November 2018. Thomson & Rescorla Expires February 10, 2020 [Page 18] Internet-Draft SDP UKS August 2019 [ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, . Appendix A. Acknowledgements This problem would not have been discovered if it weren't for discussions with Sam Scott, Hugo Krawczyk, and Richard Barnes. A solution similar to the one presented here was first proposed by Karthik Bhargavan who provided valuable input on this document. Thyla van der Merwe assisted with a formal model of the solution. Adam Roach and Paul E. Jones provided significant review and input. Authors' Addresses Martin Thomson Mozilla Email: mt@lowentropy.net Eric Rescorla Mozilla Email: ekr@rftm.com Thomson & Rescorla Expires February 10, 2020 [Page 19] ./draft-ietf-mmusic-t140-usage-data-channel-14.txt0000644000764400076440000013174213644152776021006 0ustar iustyiusty MMUSIC Working Group C. Holmberg Internet-Draft Ericsson Updates: 8373 (if approved) G. Hellstrom Intended status: Standards TrackGunnar Hellstrom Accessible Communicatio Expires: October 12, 2020 April 10, 2020 T.140 Real-time Text Conversation over WebRTC Data Channels draft-ietf-mmusic-t140-usage-data-channel-14 Abstract This document specifies how a WebRTC data channel can be used as a transport mechanism for Real-time text using the ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140), and how the SDP offer/answer mechanism can be used to negotiate such data channel, referred to as T.140 data channel. This document updates RFC 8373 to specify its use with WebRTC data channels. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 12, 2020. Copyright Notice Copyright (c) 2020 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 Holmberg & Hellstrom Expires October 12, 2020 [Page 1] Internet-Draft T.140 Data Channel April 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. WebRTC Data Channel Considerations . . . . . . . . . . . . . 4 4. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 4 4.1. Use of dcmap Attribute . . . . . . . . . . . . . . . . . 4 4.2. Use of dcsa Attribute . . . . . . . . . . . . . . . . . . 5 4.2.1. Maximum Character Transmission Rate . . . . . . . . . 5 4.2.2. Real-time Text Conversation Languages . . . . . . . . 6 4.2.3. Real-time Text Direction . . . . . . . . . . . . . . 7 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 5. T.140 Considerations . . . . . . . . . . . . . . . . . . . . 10 5.1. Session Layer Functions . . . . . . . . . . . . . . . . . 10 5.2. Data Encoding and Sending . . . . . . . . . . . . . . . . 11 5.3. Data Buffering . . . . . . . . . . . . . . . . . . . . . 11 5.4. Loss of T140blocks . . . . . . . . . . . . . . . . . . . 11 5.5. Multi-party Considerations . . . . . . . . . . . . . . . 12 6. Gateway Considerations . . . . . . . . . . . . . . . . . . . 12 7. Update to RFC 8373 . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 9.1. Subprotocol Identifier t140 . . . . . . . . . . . . . . . 14 9.2. SDP fmtp Attribute . . . . . . . . . . . . . . . . . . . 15 9.3. SDP Language Attributes . . . . . . . . . . . . . . . . . 15 9.4. SDP Media Direction Attributes . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The ITU-T Protocol for multimedia application text conversation (Recommendation ITU-T T.140) [T140] defines a protocol for text conversation, also known as real-time text. The transport used for IP networks is the "RTP Payload for Text Conversation" [RFC4103] mechanism, based on the Real-time Transport Protocol (RTP) [RFC3550]. This document specifies how a WebRTC data channel [I-D.ietf-rtcweb-data-channel] can be used as a transport mechanism for T.140, and how the SDP offer/answer mechanism for data channels Holmberg & Hellstrom Expires October 12, 2020 [Page 2] Internet-Draft T.140 Data Channel April 2020 [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such a data channel. In this document, a T.140 data channel refers to a WebRTC data channel for which the instantiated sub-protocol is "t140", and where the channel is negotiated using the SDP-based external negotiation method [I-D.ietf-mmusic-data-channel-sdpneg]. NOTE: The decision to transport real-time text using a WebRTC data channel, instead of using RTP based transport [RFC4103], is motivated by use-case "U-C 5: Real-time text chat during an audio and/or video call with an individual or with multiple people in a conference", see Section 3.2 of [I-D.ietf-rtcweb-data-channel]. The brief notation "T.140" is used as a name for the text conversation protocol according to [T140]. Real-time text is intended to be entered by human users from a keyboard, handwriting recognition, voice recognition or any other input method. The rate of character entry is usually at a level of a few characters per second or less. Section 3 defines the generic data channel properties for a T.140 data channel, and Section 4 defines how they are conveyed in an SDP dcmap attribute. While this document defines how to establish a T.140 data channel using the SDP-based external negotiation method [I-D.ietf-mmusic-data-channel-sdpneg], the generic T.140 and gateway considerations defined in Section 3, Section 5 and Section 6 of this document can also be applied when a T.140 data channel is established using another mechanism (e.g., the mechanism defined in [I-D.ietf-rtcweb-data-protocol]). Section 5 of [I-D.ietf-mmusic-data-channel-sdpneg] defines the mapping between the SDP dcmap attribute parameters and the protocol parameters used in [I-D.ietf-rtcweb-data-protocol]. This document updates [RFC8373], by defining how the SDP hlang-send and hlang-recv attributes are used for the "application/webrtc- datachannel" media type. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Holmberg & Hellstrom Expires October 12, 2020 [Page 3] Internet-Draft T.140 Data Channel April 2020 3. WebRTC Data Channel Considerations The following WebRTC data channel property values [I-D.ietf-rtcweb-data-channel] apply to a T.140 data channel: +--------------------------+-------------------------------+ | Subprotocol Identifier | t140 | | Transmission reliability | reliable | | Transmission order | in-order | | Label | See Section 4.1 and Section 6 | +--------------------------+-------------------------------+ NOTE: T.140 requires the transport channel to provide transmission of real-time text without duplication and in original order. Therefore, T.140 does not specify reliable and ordered transmission of T.140 data on the application layer. Instead, when RTP based transport is used, the RTP sequence number is used to detect packet loss and out- of-order packets, and a redundancy mechanism is used to achieve reliable delivery of T.140 data. By using the WebRTC data channel reliable and in-order transmission features [I-D.ietf-rtcweb-data-channel] for the T.140 data channel, there is no need for a redundancy mechanism or a mechanism to detect data loss and out-of-order delivery at the application level. The latency characteristics of the T.140 data channel is also regarded to be sufficient to meet the application requirements of T.140. 4. SDP Considerations The generic SDP considerations, including the SDP Offer/Answer procedures [RFC3264], for negotiating a WebRTC data channel are defined in [I-D.ietf-mmusic-data-channel-sdpneg]. This section, and its subsections, define the SDP considerations that are specific to a T.140 data channel, identified by an SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] with a "t140" attribute parameter value. 4.1. Use of dcmap Attribute An offerer and answerer MUST, in each offer and answer, include an SDP 'dcmap' attribute [I-D.ietf-mmusic-data-channel-sdpneg] in the SDP media description (m= section) [I-D.ietf-mmusic-rfc4566bis] describing the SCTP association [RFC4960] used to realize the T.140 data channel. The offerer and answerer MUST include the subprotocol attribute parameter, with a "t140" parameter value, in the 'dcmap' attribute value. Holmberg & Hellstrom Expires October 12, 2020 [Page 4] Internet-Draft T.140 Data Channel April 2020 The offerer and answerer MAY include the priority attribute parameter and the label attribute parameter in the 'dcmap' attribute value, as specified in [I-D.ietf-mmusic-data-channel-sdpneg]. NOTE: As specified in [I-D.ietf-rtcweb-data-channel], when a data channel is negotiated using the mechanism defined in [I-D.ietf-rtcweb-data-protocol], the label attribute parameter value has to be the same in both directions. That rule also applies to data channels negotiated using the mechanism defined in this document. The offerer and answerer MUST NOT include the max-retr or the max- time attribute parameters in the 'dcmap' attribute. If either of those attribute parameters is received in an offer, the answerer MUST reject the offer. If either of those attribute parameters is received in an answer the offerer MUST NOT accept the answer. Instead, the answerer MUST take appropriate actions, e.g., by sending a new offer without a T.140 data channel, or by terminating the session. If the ordered attribute parameter is included in the 'dcmap' attribute, it MUST be assigned the value 'true'. Below is an example of the 'dcmap' attribute for a T.140 data channel with stream id=3 and without any label: a=dcmap:3 subprotocol="t140" 4.2. Use of dcsa Attribute An offerer and answerer can, in each offer and answer, include one or more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in the m= section describing the SCTP association used to realize the T.140 data channel. If an offerer or answerer receives a 'dcsa' attribute that contains an SDP attribute which usage has not been defined for a T.140 data channel, the offerer or answerer should ignore the 'dcsa' attribute, following the rules in Section 6.7 of [I-D.ietf-mmusic-data-channel-sdpneg]. 4.2.1. Maximum Character Transmission Rate A 'dcsa' attribute can contain the SDP 'fmtp' attribute used to indicate a maximum character transmission rate [RFC4103]. The 'cps' attribute parameter is used to indicate the maximum character transmission rate that the endpoint that includes the attribute is Holmberg & Hellstrom Expires October 12, 2020 [Page 5] Internet-Draft T.140 Data Channel April 2020 able to receive, and the value is used as a mean value in characters per second over any 10-second interval. If the 'fmtp' attribute is included, the 'format' attribute parameter MUST be set to "t140". If no 'fmtp' attribute with a 'cps' attribute parameter is included, the default value of 30 applies [RFC4103]. The offerer and answerer MAY modify the 'cps' attribute parameter value in subsequent offers and answers. This document does not define any other usage of the 'fmtp' attribute for a T.140 channel. If an offerer or answerer receives a 'dcsa' attribute that contains an 'fmtp' attribute that is not according to the procedure above, the offerer or answerer MUST ignore the 'dcsa' attribute. NOTE: The 'cps' attribute parameter is especially useful when a T.140 data channel endpoint is acting as a gateway (Section 6) and is interworking with a T.140 transport mechanism that have restrictions on how many characters can be sent per second. If an endpoint receives text at a higher rate than it can handle, e.g., because the sending endpoint does not support the 'cps' attribute parameter, it SHOULD either indicate to the sending endpoint that it is not willing to receive more text, using the direction attributes (Section 4.2.3), or use a flow control mechanism to reduce the rate. However, in certain applications, e.g. emergency services, it is important to regain human interaction as soon as possible, and it might therefore be more appropriate to simply discard the received overflow, insert a mark for loss [T140ad1], and continue to process the received text as soon as possible. NOTE: At the time of writing this specification, the standardized API for WebRTC data channels does not support flow control. Should such be available at some point, a receiving endpoint might use it in order to slow down the rate of text received from the sending endpoint. 4.2.2. Real-time Text Conversation Languages 'dcsa' attributes can contain the SDP 'hlang-send' and 'hlang-recv' attributes [RFC8373] to negotiate the language to be used for the real-time text conversation. For a T.140 data channel, the modality is "written" [RFC8373]. Holmberg & Hellstrom Expires October 12, 2020 [Page 6] Internet-Draft T.140 Data Channel April 2020 4.2.3. Real-time Text Direction 'dcsa' attributes can contain the SDP 'sendonly', 'recvonly', 'sendrecv' and 'inactive' attributes [I-D.ietf-mmusic-rfc4566bis] to negotiate the direction in which text can be transmitted in a real- time text conversation. NOTE: A WebRTC data channel is always bi-directional. The usage of the 'dcsa' attribute only affects the direction in which implementations are allowed to transmit text on a T.140 data channel. The offer/answer rules for the direction attributes are based on the rules for unicast streams defined in [RFC3264], as described below. Note that the rules only apply to the direction attributes. Session-level direction attributes [I-D.ietf-mmusic-rfc4566bis] have no impact on a T.140 data channel. 4.2.3.1. Generating an Offer If the offerer wishes to both send and receive text on a T.140 data channel, it SHOULD mark the data channel as sendrecv with a 'sendrecv' attribute inside a 'dcsa' attribute. If the offerer does not explicitly mark the data channel, an implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default. If the offerer wishes to only send text on a T.140 data channel, it MUST mark the data channel as sendonly with a 'sendonly' attribute inside a 'dcsa' attribute. If the offerer wishes to only receive text on a T.140 data channel, it MUST mark the data channel as recvonly with a 'recvonly' attribute inside a 'dcsa' attribute. If the offerer wishes to neither send nor receive text on a T.140 data channel, it MUST mark the data channel as inactive with an 'inactive' attribute inside a 'dcsa' attribute. If the offerer has marked a data channel as sendrecv (or if the offerer did not explicitly mark the data channel) or recvonly, it MUST be prepared to receive T.140 data as soon as the state of the T.140 data channel allows it. 4.2.3.2. Generating an Answer When the answerer accepts an offer, and marks the direction of the text in the corresponding answer, the direction is based on the marking (or the lack of explicit marking) in the offer. Holmberg & Hellstrom Expires October 12, 2020 [Page 7] Internet-Draft T.140 Data Channel April 2020 If the offerer explicitly marked the data channel as sendrecv, or if the offerer did not mark the data channel, the answerer SHOULD mark the data channel as sendrecv, sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 'recvonly' or 'inactive' attribute respectively inside a 'dcsa' attribute. If the answerer does not explicitly mark the data channel, an implicit 'sendrecv' attribute inside a 'dcsa' attribute is applied by default. If the offerer marked the data channel as sendonly, the answerer MUST mark the data channel as recvonly or inactive with a 'recvonly' or 'inactive' attribute respectively inside a 'dcsa' attribute. If the offerer marked the data channel as recvonly, the answerer MUST mark the data channel as sendonly or inactive with a 'sendonly' or 'inactive' attribute respectively inside a 'dcsa' attribute. If the offerer marked the data channel as inactive, the answerer MUST mark the data channel as inactive with an 'inactive' attribute inside a 'dcsa' attribute. If the answerer has marked a data channel as sendrecv or recvonly, it MUST be prepared to receive data as soon as the state of the T.140 data channel allows transmission of data. 4.2.3.3. Offerer Receiving an Answer When the offerer receives an answer to the offer and the answerer has marked a data channel as sendrecv (or the answerer did not mark the data channel) or recvonly in the answer, the offerer can start sending T.140 data as soon as the state of the T.140 data channel allows it. If the answerer has marked the data channel as inactive or sendonly, the offerer MUST NOT send any T.140 data. If the answerer has not marked the direction of a T.140 data channel in accordance with the procedures above, it is RECOMMENDED that the offerer does not process that as an error situation, but rather assume that the answerer might both send and receive T.140 data on the data channel. 4.2.3.4. Modify Text Direction If an endpoint wishes to modify a previously negotiated text direction in an ongoing session, it MUST initiate an offer that indicates the new direction, following the rules in Section 4.2.3.1. If the answerer accepts the offer it follows the procedures in Section 4.2.3.2. Holmberg & Hellstrom Expires October 12, 2020 [Page 8] Internet-Draft T.140 Data Channel April 2020 4.3. Examples Below is an example of an m= section of an offer for a T.140 data channel offering real-time text conversation in Spanish and Esperanto, and an m= section in the associated answer accepting Esperanto. The maximum character transmission rate is set to 20. As the offerer and answerer have not explicitly indicated the real-time text direction, the default direction "sendrecv" applies. Offer: m=application 911 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:1000 a=sctp-port 5000 a=setup:actpass a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcsa:2 fmtp:t140 cps=20 a=dcsa:2 hlang-send:es eo a=dcsa:2 hlang-recv:es eo Answer: m=application 2004 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::1 a=max-message-size:1000 a=sctp-port 6000 a=setup:passive a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcsa:2 fmtp:t140 cps=20 a=dcsa:2 hlang-send:eo a=dcsa:2 hlang-recv:eo Below is an example of an m= section of an offer for a T.140 data channel where the offerer wishes to only receive real-time text, and an m= section in the associated answer indicating that the answerer will only send real-time text. No maximum character transmission rate is indicated. No preference for the language to be used for the real-time text conversation is indicated. Holmberg & Hellstrom Expires October 12, 2020 [Page 9] Internet-Draft T.140 Data Channel April 2020 Offer: m=application 1400 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::3 a=max-message-size:1000 a=sctp-port 5000 a=setup:actpass a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcsa:2 recvonly Answer: m=application 2400 UDP/DTLS/SCTP webrtc-datachannel c=IN IP6 2001:db8::1 a=max-message-size:1000 a=sctp-port 6000 a=setup:passive a=dcmap:2 label="ACME customer service";subprotocol="t140" a=dcsa:2 sendonly 5. T.140 Considerations 5.1. Session Layer Functions Section 6.1 of [T140] describes the generic T.140 session control functions at a high-level in a signalling protocol independent manner. The list below describes how the functions are realized when using a T.140 data channel. o Prepare session: An endpoint can indicate its support of T.140 data channels using signalling specific means (e.g., using SIP OPTIONS [RFC3261]), or by indicating the support in an offer or answer (Section 4) o Initiate session: An offer used to request the establishment of a T.140 data channel (Section 4) o Accept session: An answer used to accept a request to establish a T.140 data channel (Section 4) o Deny session: An answer used to reject a request to establish a T.140 data channel, using the generic procedures for rejecting a data channel [I-D.ietf-mmusic-data-channel-sdpneg] o Disconnect session: An offer or answer used to disable a previously established T.140 data channel, using the generic procedures for closing a data channel [I-D.ietf-mmusic-data-channel-sdpneg] o Data: Data sent on an established T.140 data channel (Section 5.2) Holmberg & Hellstrom Expires October 12, 2020 [Page 10] Internet-Draft T.140 Data Channel April 2020 5.2. Data Encoding and Sending T.140 text is encoded and framed as T140blocks [RFC4103]. Each T140block is sent on the SCTP stream [RFC4960] used to realize the T.140 data channel using standard T.140 transmission procedures [T140]. One or more T140blocks can be sent in a single SCTP user message [RFC4960]. Unlike RTP based transport for real-time text [RFC4103], T.140 data channels do not use redundant transmission of text. The reason for this is that the T.140 data channel achieves robust transmission by using the "reliable" mode of the data channel. Data sending procedures conform to [T140]. See Section 8 of [T140] for coding details. NOTE: The T.140 coding details contain information on optional control codes for controlling the presentation which may not be supported by the presentation level of the receiving application. The receiving application is expected to handle reception of such T.140 control codes appropriately (e.g. ignore and skip them) even if their effect on the presentation is not supported. 5.3. Data Buffering As described in [T140], buffering can be used to reduce overhead, with the maximum assigned transmission interval of T140blocks from the buffer being 500 ms as long as there is text to send. Buffering MAY also be used for staying within the maximum character transmission rate (Section 4.2). An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a transmission interval. It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers might also use lower values for specific applications requiring low latency, taking the increased overhead in consideration. 5.4. Loss of T140blocks In case of network failure or congestion, T.140 data channels might fail and get torn down. If this happens but the session sustains, it is RECOMMENDED that implementations try to reestablish the T.140 data channels. As a T.140 data channel does not provide a mechanism for the receiver to identify retransmitted T140blocks after channel reestablishment, the sending endpoint MUST NOT retransmit T140blocks. Holmberg & Hellstrom Expires October 12, 2020 [Page 11] Internet-Draft T.140 Data Channel April 2020 Similarly, a receiver SHOULD indicate to the user that there has been a channel reestablishment, and that text might have been lost. This MAY be done by inserting the missing text markers [T140ad1] or in any other way evident to the user. NOTE: If the SCTP association [RFC4960] used to realize the T.140 data channel fails and gets torn down, it needs to be re-established before the T.140 data channel can be reestablished. The procedures after the reestablishment of the T.140 data channel defined in this section apply no matter if only the T.140 data channel, or the whole SCTP association, got torn down. 5.5. Multi-party Considerations If an implementation needs to support multi-party scenarios, the implementation needs to support multiple simultaneous T.140 data channels, one for each remote party. At the time of writing this document, this is true even in scenarios where each participant communicates via a centralized conference server. The reason is that, unlike RTP media, WebRTC data channels and the T.140 protocol do not support the indication of the source of T.140 data. The SDP 'dcmap' attribute label attribute parameter (Section 4.1) can be used by the offerer to provide additional information about each T.140 data channel, and help implementations to distinguish between them. NOTE: Future extensions to T.140, or to the T140block, might allow indicating the source of T.140 data, in which case it might be possible to use a single T.140 data channel to transport data from multiple remote sources. The usage of a single T.140 data channel, without any protocol extensions, would require the conference server to only forward real-time text from one source at any given time, and e.g., include human readable text labels in the real-time text stream that indicate the source whenever the conference server switches the source. This would allow the receiver to present real-time text from different sources separately. The procedures of such mechanism are outside the scope of this document. 6. Gateway Considerations A number of real-time text transports and protocols have been defined for both packet-switched and circuit-switched networks. Many are based on the ITU-T T.140 protocol on application and presentation level [T140]. At the time of writing this document, some mechanisms are no longer used, as the technologies they use have been obsoleted, while others are still in use. When performing interworking between T.140 data channels and real- time text in other transports and protocols, a number of factors need Holmberg & Hellstrom Expires October 12, 2020 [Page 12] Internet-Draft T.140 Data Channel April 2020 to be considered. At the time of writing this document, the most common IP-based real-time text transport is the RTP based mechanism defined in [RFC4103]. While this document does not define a complete interworking solution, this list below provides some guidance and considerations to take into account when designing a gateway for interworking between T.140 data channels and RTP-based T.140 transport: o For each T.140 data channel there is an RTP stream for real-time text [RFC4103]. Redundancy is by default declared and used on the RTP stream. There is no redundancy on the T.140 data channel, but the reliable property [I-D.ietf-mmusic-data-channel-sdpneg] is set on it. o During a normal text flow, T140blocks received from one network are forwarded towards the other network. Keep-alive traffic is handled by lower layers on the T.140 data channel. A gateway might have to extract keep-alives from incoming RTP streams, and MAY generate keep-alives on outgoing RTP streams. o If the gateway detects or suspects loss of data on the RTP stream, and the lost data has not been retrieved using a redundancy mechanism, the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel. o If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing RTP stream if it detects or suspects that data sent by the remote T.140 data channel endpoint was lost. o If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel if it detects or suspects that data sent or to be sent on the T.140 data channel was lost during the failure. o The gateway MUST indicate the same text transmission direction (Section 4.2.3) on the T.140 data channel and the RTP stream. NOTE: In order for the gateway to insert a missing text marker, or to perform other actions that require that the gateway has access to the T.140 data, the T.140 data cannot be encrypted end-to-end between the T.140 data channel endpoint and the RTP endpoint. At the time of writing this document, no mechanism to provide such end-to-end encryption is defined. 7. Update to RFC 8373 This document updates RFC 8373 [RFC8373], by defining how the SDP hlang-send and hlang-recv attributes are used for the "application/ webrtc-datachannel" media type. Holmberg & Hellstrom Expires October 12, 2020 [Page 13] Internet-Draft T.140 Data Channel April 2020 SDP offerers and answerers MUST NOT include the attributes directly in the m= section associated with the 'application/webrtc- datachannel' media type. Instead, the attributes MUST be associated with individual data channels, using the SDP 'dcsa' attribute. A specification that defines a subprotocol that uses the attributes MUST specify the modality for that subprotocol, or how to retrieve the modality if the subprotocol supports multiple modalities. The subprotocol is indicated using the SDP 'dcmap' attribute. 8. Security Considerations The generic WebRTC security considerations are defined in [I-D.ietf-rtcweb-security-arch] and [I-D.ietf-rtcweb-security]. The generic security considerations for WebRTC data channels are defined in [I-D.ietf-rtcweb-data-channel]. As data channels are always encrypted by design, the T.140 data channels will also be encrypted. The generic security considerations for the SDP-based external negotiation method are defined in [I-D.ietf-mmusic-data-channel-sdpneg]. There are no additional T.140 data channel specific security considerations. When performing interworking between T.140 data channels and real- time text and the RTP based mechanism defined in [RFC4103], in order for a gateway to insert a missing text marker, or to perform other actions that require that the gateway has access to the T.140 data, the T.140 data cannot be encrypted end-to-end between the T.140 data channel endpoint and the RTP endpoint. 9. IANA considerations [RFC EDITOR NOTE: Please replace all instances of RFCXXXX with the RFC number of this document.] 9.1. Subprotocol Identifier t140 This document adds the subprotocol identifier "t140" to the "WebSocket Subprotocol Name Registry" as follows: +--------------------------+----------------------------+ | Subprotocol Identifier: | t140 | | Subprotocol Common Name: | ITU-T T.140 Real-Time Text | | Subprotocol Definition: | RFCXXXX | | Reference: | RFCXXXX | +--------------------------+----------------------------+ Holmberg & Hellstrom Expires October 12, 2020 [Page 14] Internet-Draft T.140 Data Channel April 2020 9.2. SDP fmtp Attribute This document defines the usage of the SDP 'fmtp' attribute, if this attribute is included in an SDP 'dcsa' attribute and associated with an T.140 real-time text session over a WebRTC data channel. The usage is defined in Section 4.2.1. The usage level "dcsa(t140)" is added to the registration of the SDP 'fmtp' attribute in the Session Description Protocol (SDP) Parameters registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | fmtp | | Usage level: | dcsa(t140) | | Purpose: | Indicate format parameters for a T.140 | | | data channel, such as maximum character | | | transmission rates. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 9.3. SDP Language Attributes This document modifies the usage of the SDP 'hlang-send' and 'hlang- recv' attributes, if these attributes are included in SDP 'dcsa' attributes associated with an T.140 data channel. The modified usage is described in Section 4.2.2. The usage level "dcsa(t140)" is added to the registration of the SDP 'hland-send' attribute in the Session Description Protocol (SDP) Parameters registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | hlang-send | | Usage level: | dcsa(t140) | | Purpose: | Negotiate the language to be used on a | | | T.140 data channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(t140)" is added to the registration of the SDP 'hland-recv' attribute in the Session Description Protocol (SDP) Parameters registry as follows: Holmberg & Hellstrom Expires October 12, 2020 [Page 15] Internet-Draft T.140 Data Channel April 2020 +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | hlang-recv | | Usage level: | dcsa(t140) | | Purpose: | Negotiate the language to be used on a | | | T.140 data channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 9.4. SDP Media Direction Attributes This document modifies the usage of the SDP 'sendonly', 'recvonly', 'sendrecv' and 'inactive' attributes, if these attributes are included in SDP 'dcsa' attributes associated T.140 data channel. The modified usage is described in Section 4.2.3. The usage level "dcsa(t140)" is added to the registration of the SDP 'sendonly' attribute in the Session Description Protocol (SDP) Parameters registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | sendonly | | Usage level: | dcsa(t140) | | Purpose: | Negotiate the direction in which real- | | | time text can be sent on a T.140 data | | | channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(t140)" is added to the registration of the SDP 'recvonly' attribute in the Session Description Protocol (SDP) Parameters registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | recvonly | | Usage level: | dcsa(t140) | | Purpose: | Negotiate the direction in which real- | | | time text can be sent on a T.140 data | | | channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ Holmberg & Hellstrom Expires October 12, 2020 [Page 16] Internet-Draft T.140 Data Channel April 2020 The usage level "dcsa(t140)" is added to the registration of the SDP 'sendrecv' attribute in the Session Description Protocol (SDP) Parameters registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | sendrecv | | Usage level: | dcsa(t140) | | Purpose: | Negotiate the direction in which real- | | | time text can be sent on a T.140 data | | | channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ The usage level "dcsa(t140)" is added to the registration of the SDP 'inactive' attribute in the Session Description Protocol (SDP) Parameters registry as follows: +-----------------------+-------------------------------------------+ | Contact name: | IESG | | Contact email: | iesg@ietf.org | | Attribute name: | inactive | | Usage level: | dcsa(t140) | | Purpose: | Negotiate the direction in which real- | | | time text can be sent on a T.140 data | | | channel. | | Reference: | RFCXXXX | +-----------------------+-------------------------------------------+ 10. Acknowledgements This document is based on an earlier Internet draft edited by Keith Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz. Thomas Belling provided useful comments on the initial (pre- submission) version of the draft. Paul Kyzivat and Bernard Aboba provided comments on the draft. 11. References 11.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, . Holmberg & Hellstrom Expires October 12, 2020 [Page 17] Internet-Draft T.140 Data Channel April 2020 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, . [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8373] Gellens, R., "Negotiating Human Language in Real-Time Communications", RFC 8373, DOI 10.17487/RFC8373, May 2018, . [I-D.ietf-mmusic-rfc4566bis] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: Session Description Protocol", draft-ietf-mmusic- rfc4566bis-37 (work in progress), August 2019. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-mmusic-data-channel-sdpneg] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, "SDP-based Data Channel Negotiation", draft-ietf- mmusic-data-channel-sdpneg-28 (work in progress), May 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-20 (work in progress), July 2019. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-12 (work in progress), July 2019. [T140] ITU-T, "Recommendation ITU-T T.140 (02/1998), Protocol for multimedia application text conversation", February 1998. Holmberg & Hellstrom Expires October 12, 2020 [Page 18] Internet-Draft T.140 Data Channel April 2020 [T140ad1] ITU-T, "Recommendation ITU-T.140 Addendum 1 - (02/2000), Protocol for multimedia application text conversation", February 2000. 11.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Gunnar Hellstrom Gunnar Hellstrom Accessible Communication Esplanaden 30 Vendelso 136 70 Sweden Email: gunnar.hellstrom@ghaccess.se Holmberg & Hellstrom Expires October 12, 2020 [Page 19] ./draft-ietf-mmusic-trickle-ice-sip-18.txt0000644000764400076440000030670513313411660017651 0ustar iustyiusty Network Working Group E. Ivov Internet-Draft Jitsi Intended status: Standards Track T. Stach Expires: December 24, 2018 Unaffiliated E. Marocco Telecom Italia C. Holmberg Ericsson June 22, 2018 A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) draft-ietf-mmusic-trickle-ice-sip-18 Abstract The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new SDP 'end-of- candidates' attribute and a new SIP Option Tag 'trickle-ice' are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Ivov, et al. Expires December 24, 2018 [Page 1] Internet-Draft Trickle ICE for SIP June 2018 This Internet-Draft will expire on December 24, 2018. Copyright Notice Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9 4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9 4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery . . . . . . . . . . . . . . . . 11 4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery . . . . . . . . . . . . . . . . 12 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 16 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 20 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 20 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 23 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 28 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 29 Ivov, et al. Expires December 24, 2018 [Page 2] Internet-Draft Trickle ICE for SIP June 2018 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 29 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 29 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 34 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 10.10. Info Package Security Considerations . . . . . . . . . . 35 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 16.1. Normative References . . . . . . . . . . . . . . . . . . 43 16.2. Informative References . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction The Interactive Connectivity Establishment (ICE) protocol [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address Translator (NAT) traversal that consists of three main phases. During the first phase an agent gathers a set of candidate transport addresses (source IP address, port and transport protocol). This is followed by a second phase where these candidates are sent to a remote agent within the Session Description Protocol (SDP) body of a SIP message. At the remote agent the gathering procedure is repeated and candidates are sent to the first agent. Once the candidate information is available, a third phase starts in parallel where connectivity between all candidates in both sets is checked (connectivity checks). Once these phases have been completed, and only then, both agents can begin communication. According to [I-D.ietf-ice-rfc5245bis] the three phases above happen consecutively, in a blocking way, which can introduce undesirable setup delay during session establishment. The Trickle ICE extension Ivov, et al. Expires December 24, 2018 [Page 3] Internet-Draft Trickle ICE for SIP June 2018 [I-D.ietf-ice-trickle] defines generic semantics required for these ICE phases to happen in a parallel, non-blocking way and hence speed up session establishment. This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates are to be exchanged incrementally using SIP INFO requests [RFC6086] and how the Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) depending on their expectations for support of Trickle ICE by a remote agent. This document defines a new Info Package as specified in [RFC6086] for use with Trickle ICE together with the corresponding media type, SDP attribute and SIP option tag. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification makes use of terminology defined by the protocol for Interactive Connectivity Establishment in [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar with the terminology from both documents. [I-D.ietf-ice-rfc5245bis] also describes how ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its extension Traversal Using Relay NAT (TURN) [RFC5766]. 3. Protocol Overview When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE candidates are exchanged solely via SDP Offer/Answer as per [RFC3264]. This specification defines an additional mechanism where candidates can be exchanged using SIP INFO messages and a newly defined Info Package [RFC6086]. This allows ICE candidates also to be sent in parallel to an ongoing Offer/Answer negotiation and/or after the completion of the Offer/Answer negotiation. Typically, in cases where Trickle ICE is fully supported, the Offerer sends an INVITE request containing a subset of candidates. Once an early dialog is established the Offerer can continue sending candidates in INFO requests within that dialog. Ivov, et al. Expires December 24, 2018 [Page 4] Internet-Draft Trickle ICE for SIP June 2018 Similarly, an Answerer can send ICE candidates using INFO requests within the dialog established by its 18x provisional response. Figure 1 shows such a sample exchange: STUN/Turn STUN/TURN Servers Alice Bob Servers | | | | | STUN Bi.Req. | INVITE (Offer) | | |<--------------|------------------------>| | | | 183 (Answer) | TURN Alloc Req | | STUN Bi.Resp. |<------------------------|--------------->| |-------------->| INFO/OK (SRFLX Cand.) | | | |------------------------>| TURN Alloc Resp| | | INFO/OK (Relay Cand.) |<---------------| | |<------------------------| | | | | | | | More Cands & ConnChecks| | | |<=======================>| | | | | | | | 200 OK | | | |<------------------------| | | | ACK | | | |------------------------>| | | | | | | |<===== MEDIA FLOWS =====>| | | | | | Note: SRFLX denotes server-reflexive candidates Figure 1: Sample Trickle ICE scenario with SIP 3.1. Discovery issues In order to benefit from Trickle ICE's full potential and reduce session establishment latency to a minimum, Trickle ICE agents need to generate SDP Offers and Answers that contain incomplete, potentially empty sets of candidates. Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before using it. Contrary to other protocols, where "in advance" capability discovery is widely implemented, the mechanisms that allow this for SIP (i.e., a combination of UA Capabilities [RFC3840] and Globally Routable User Agent URIs (GRUU) [RFC5627]) have only seen low levels of adoption. This presents an issue for Trickle ICE implementations as SIP UAs do not have an obvious means of verifying that their peer will support incremental candidate provisioning. Ivov, et al. Expires December 24, 2018 [Page 5] Internet-Draft Trickle ICE for SIP June 2018 The Half Trickle mode of operation defined in the Trickle ICE specification [I-D.ietf-ice-trickle] provides one way around this, by requiring the first Offer to contain a complete set of local ICE candidates and only using incremental provisioning of remote candidates for the rest of the session. While using Half Trickle does provide a working solution it also comes at the price of increased latency. Section 5 therefore makes several alternative suggestions that enable SIP UAs to engage in Full Trickle right from their first Offer: Section 5.1 discusses the use of on-line provisioning as a means of allowing use of Trickle ICE for all endpoints in controlled environments. Section 5.2 describes anticipatory discovery for implementations that actually do support GRUU and UA Capabilities and Section 5.3 discusses the implementation and use of Half Trickle by SIP UAs where none of the above are an option. 3.2. Relationship with the Offer/Answer Model From the perspective of SIP middle boxes and proxies the Offer/Answer exchange for Trickle ICE looks partly similar to the Offer/Answer exchange for regular ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to be considered as well. Ivov, et al. Expires December 24, 2018 [Page 6] Internet-Draft Trickle ICE for SIP June 2018 +-------------------------------+ +-------------------------------+ | Alice +--------------+ | | +--------------+ Bob | | | Offer/Answer | | | | Offer/Answer | | | +--------+ | Module | | | | Module | +--------+ | | | ICE | +--------------+ | | +--------------+ | ICE | | | | Module | | | | | | Module | | | +--------+ | | | | +--------+ | +-------------------------------+ +-------------------------------+ | | | | | | INVITE (Offer) | | | |--------------------->| | | | 183 (Answer) | | | |<---------------------| | | | | | | | | SIP INFO (more candidates) | |----------------------------------------------------->| | SIP INFO (more candidates) | |<-----------------------------------------------------| | | | STUN Binding Requests/Responses | |----------------------------------------------------->| | STUN Binding Requests/Responses | |<-----------------------------------------------------| | | Figure 2: Distinguishing between Trickle ICE and traditional signaling. From an architectural viewpoint, as displayed in Figure 2, exchanging candidates through SIP INFO requests could be represented as signaling between ICE modules and not between Offer/Answer modules of SIP User Agents. Then, such INFO requests do not impact the state of the Offer/Answer transaction other than providing additional candidates. Consequently, INFO requests are not considered Offers or Answers. Nevertheless, candidates that have been exchanged using INFO requests SHALL be included in subsequent Offers or Answers. The version number in the "o=" line of that subsequent Offer needs to be incremented by 1 per the rules in [RFC3264]. 4. Incremental Signaling of ICE candidates Trickle ICE Agents will exchange ICE descriptions compliant to [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO request bodies. This requires the following SIP-specific extensions: Ivov, et al. Expires December 24, 2018 [Page 7] Internet-Draft Trickle ICE for SIP June 2018 1. Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag 'trickle-ice' in a SIP Supported: header field within all SIP INVITE requests and responses. 2. Trickle ICE Agents MUST indicate support for Trickle ICE by including the ice-option 'trickle' within all SDP Offers and Answers in accordance to [I-D.ietf-ice-trickle]. 3. Trickle ICE Agents MAY include any number of ICE candidates, i.e. from zero to the complete set of candidates, in their initial Offer or Answer. If the complete candidate set is included already in the initial Offer, this is called Half-Trickle. 4. Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests within an existing INVITE dialog usage (including an early dialog) as specified in [RFC6086]. The INFO requests carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be prepared to receive INFO requests within that same dialog usage, containing additional candidates and/or an indication that trickling of such candidates has ended. 5. Trickle ICE Agents MAY exchange additional ICE candidates before the Answerer has sent the Answer provided that an invite dialog usage is established at both Trickle ICE Agents. Note that in case of forking multiple early dialogs may exist. The following sections provide further details on how Trickle ICE Agents perform the initial Offer/Answer exchange (Section 4.1), perform subsequent Offer/Answer exchanges (Section 4.2) and establish the INVITE dialog usage (Section 4.3) such that they can incrementally trickle candidates (Section 4.4). 4.1. Initial Offer/Answer Exchange 4.1.1. Sending the Initial Offer If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. If the Offerer wants to send its initial Offer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value '9' for these media descriptions. If the Offerer does not want to include the host IP address in the corresponding c-line, e.g. due to privacy reasons, it SHOULD include a default address in the c-line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent ::. Ivov, et al. Expires December 24, 2018 [Page 8] Internet-Draft Trickle ICE for SIP June 2018 In this case, the Offerer obviously cannot know the RTCP transport address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. If the Offerer wants to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in the initial Offer. In any case, the Offerer MUST include the attribute "a=ice- options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST include in each "m="-line a "a=mid:" attribute in accordance to [RFC5888]. The "a=mid:" attribute identifies the "m="-line to which a candidate belongs and helps in case of multiple "m="-lines, when candidates gathering could occur in a order different from the order of the "m="-lines. 4.1.2. Receiving the Initial Offer If the initial Offer included candidates, the Answerer uses these candidates to start ICE processing as specified in [I-D.ietf-ice-trickle]. If the initial Offer included the attribute a=ice-options:trickle, the Answerer MUST be prepared for receiving trickled candidates later on. In case of a "m/c=" line with default values none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]). 4.1.3. Sending the Initial Answer If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp]. If the Answerer wants to send its initial Answer before knowing any candidate for one or more media descriptions, it MUST set the port to the default value '9' for these media descriptions. If the Answerer does not want to include the host IP address in the corresponding c-line, e.g. due to privacy reasons, it SHOULD include a default address in the c-line, which is set to the IPv4 address 0.0.0.0 or to the IPv6 equivalent ::. Ivov, et al. Expires December 24, 2018 [Page 9] Internet-Draft Trickle ICE for SIP June 2018 In this case, the Answerer obviously cannot know the RTCP transport address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will include the "a=rtcp-mux" attribute in the initial Answer. In any case, the Answerer MUST include the attribute "a=ice- options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST include in each "m="-line a "a=mid:" attribute in accordance to [RFC5888]. 4.1.4. Receiving the Initial Answer If the initial Answer included candidates, the Offerer uses these candidates to start ICE processing as specified in [I-D.ietf-ice-trickle]. In case of a "m/c=" line with default values none of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]). 4.2. Subsequent Offer/Answer Exchanges Subsequent Offer/Answer exchanges are handled as for regular ICE (see section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). If an Offer or Answer needs to be sent while the ICE agents are in the middle of trickling section 3.2 of [I-D.ietf-mmusic-ice-sip-sdp]) applies. This means that an ICE agent includes candidate attributes for all local candidates it had trickled previously for a specific media stream. [RFC EDITOR NOTE: The section 3.2 in above sentence is correct for version 20 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] 4.3. Establishing the Dialog In order to be able to start trickling, the following two conditions need to be satisfied at the SIP UAs: o Trickle ICE support at the peer agent MUST be confirmed. o A dialog MUST have been created between the peers. Ivov, et al. Expires December 24, 2018 [Page 10] Internet-Draft Trickle ICE for SIP June 2018 Section 5 discusses in detail the various options for satisfying the first of the above conditions. Regardless of those mechanisms, however, agents are certain to have a clear understanding of whether their peers support trickle ICE once an Offer and an Answer have been exchanged, which also allows for ICE processing to commence (see Figure 3). 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (Answer) | |<------------------------| | PRACK/OK | |------------------------>| | | +----------------------------------------+ |Alice and Bob know that both can trickle| |and know that the dialog is in the early| |state. Send INFO! | +----------------------------------------+ | | | INFO/OK (+SRFLX Cand.) | |------------------------>| | INFO/OK (+SRFLX Cand.) | |<------------------------| | | Note: SRFLX denotes server-reflexive candidates Figure 3: SIP Offerer can freely trickle as soon as it receives an Answer. As shown in Figure 3 satisfying both conditions is relatively trivial for ICE Agents that have sent an Offer in an INVITE and that have received an Answer in a reliable provisional response. It is guaranteed to have confirmed support for Trickle ICE at the Answerer (or lack thereof) and to have fully initialized the SIP dialog at both ends. Offerers and Answerers (after receipt of the PRACK request) in the above situation can therefore freely commence trickling within the newly established dialog. Ivov, et al. Expires December 24, 2018 [Page 11] Internet-Draft Trickle ICE for SIP June 2018 4.3.2. Establishing Dialog State through Unreliable Offer/Answer Delivery The situation is a bit more delicate for agents that have received an Offer in an INVITE request and have sent an Answer in an unreliable provisional response because, once the response has been sent, the Answerer does not know when or if it has been received (Figure 4). Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (Answer) | |<------------------------| | | | +----------------------+ | |Bob: I don't know if | | |Alice got my 183 or if| | |her dialog is already | | |in the early state. | | | Can I send INFO??? | | +----------------------+ | | Figure 4: A SIP UA that sent an Answer in an unreliable provisional response does not know if it was received and if the dialog at the side of the Offerer has entered the early state In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the provisional response with the exponential back-off timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request carrying a 'trickle-ice' Info Package body, on receipt of any other in-dialog request from the offerer or on transmission of the Answer in a 2xx response. The offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. Using the INFO request for dialog confirmation is similar to the procedure described in section 6.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is replaced by the INFO request. [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] The Offerer MUST send a Trickle ICE INFO request as soon as it receives an SDP Answer in an unreliable provisional response. This INFO request MUST repeat the candidates that were already provided in Ivov, et al. Expires December 24, 2018 [Page 12] Internet-Draft Trickle ICE for SIP June 2018 the Offer (as would be the case when Half Trickle is performed or when new candidates have not been learned since then). The first case could happen when Half Trickle is used and all candidate are already in the initial offer. The second case could happen when Full Trickle is used and the offerer is currently gathering additional candidates, but did not yet get them. Also, if the initial Offer did not contain any candidates, depending on how the Offerer gathers its candidates and how long it takes to do so, this INFO could still contain no candidates. When Full Trickle is used and if newly learned candidates are available, the Offerer SHOULD also deliver these candidates in said INFO request, unless it wants to hold back some candidates in reserve, e.g. in case that these candidates are expensive to use and would only be trickled if all other candidates failed. The Offerer SHOULD include an end-of-candidates attribute in case candidate discovery has ended in the mean time and no further candidates are to be trickled. As soon as an Answerer has received such an INFO request, the Answerer has an indication that a dialog is established at both ends and can begin trickling (Figure 5). Note: The +SRFLX in Figure 5 indicates that additionally newly learned server-reflexive candidates are included. Ivov, et al. Expires December 24, 2018 [Page 13] Internet-Draft Trickle ICE for SIP June 2018 Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (Answer) | |<------------------------| | INFO/OK (+SRFLX Cand.) | |------------------------>| | | | +----------------------+ | |Bob: Now I know Alice| | | is ready. Send INFO! | | +----------------------+ | INFO/OK (+SRFLX Cand.) | |<------------------------| | | | 200/ACK (Answer) | |<------------------------| Note: SRFLX denotes server-reflexive candidates Figure 5: A SIP UA that received an INFO request after sending an unreliable provisional response knows that the dialog at the side of the receiver has entered the early state When sending the Answer in the 200 OK response to the INVITE request, the Answerer needs to repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in [RFC3264]. Thus, the Offerer needs to be prepared for receiving a different number of candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response. 4.3.3. Initiating Trickle ICE without an SDP Answer The ability to convey arbitrary candidates in INFO message bodies allows ICE Agents to initiate trickling without actually sending an Answer. Trickle ICE Agents can therefore respond to an INVITE request with provisional responses without an SDP Answer [RFC3261]. Such provisional responses serve for establishing an early dialog. Agents that choose to establish the dialog in this way, MUST retransmit these responses with the exponential back-off timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request carrying a 'trickle-ice' Info Package body, on receipt any in-dialog request from the offerer or on transmission of Ivov, et al. Expires December 24, 2018 [Page 14] Internet-Draft Trickle ICE for SIP June 2018 the Answer in a 2xx response. The offerer cannot send in-dialog requests until it receives a response, so the arrival of such a request proves that the response has arrived. This is again similar to the procedure described in section 6.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet provided. [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] Note: The +SRFLX in Figure 6 indicates that additionally newly learned server-reflexive candidates are included. Alice Bob | | | INVITE (Offer) | |------------------------>| | 183 (-) | |<------------------------| | INFO/OK (SRFLX Cand.) | |------------------------>| | | | +----------------------+ | |Bob: Now I know again| | | that Alice is ready. | | | Send INFO! | | +----------------------+ | INFO/OK (SRFLX Cand.) | |<------------------------| | 183 (Answer) opt. | |<------------------------| | INFO/OK (SRFLX Cand.) | |<------------------------| | 200/ACK (Answer) | |<------------------------| Note: SRFLX denotes server-reflexive candidates Figure 6: A SIP UA sends an unreliable provisional response without an Answer for establishing an early dialog When sending the Answer, the agent MUST repeat all currently known and used candidates, if any, and MAY include all newly gathered candidates since the last INFO request was sent. However, if that Answer was already sent in a unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response Ivov, et al. Expires December 24, 2018 [Page 15] Internet-Draft Trickle ICE for SIP June 2018 to the INVITE request in order to fulfill the corresponding requirements in [RFC3264]. In case that trickling continued, an Offerer needs to be prepared for receiving fewer candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response. 4.4. Delivering Candidates in INFO Requests Whenever new ICE candidates become available for sending, agents encode them in "a=candidate:" attributes as described by [I-D.ietf-mmusic-ice-sip-sdp]. For example: a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host The use of SIP INFO requests happens within the context of the Info Package as defined Section 10. The Media Type [RFC6838] for their payload MUST be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. The Info request body adheres to the grammar as specified in Section 9.2. Since neither the "a=candidate:" nor the "a=end-of-candidates" attributes contain information that would allow correlating them to a specific "m=" line, this is handled through the use of pseudo "m=" lines. Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in [RFC4566] and are linked to the corresponding "m=" line in the SDP Offer or Answer via the identification tag in a "a=mid:" attribute [RFC5888]. A pseudo "m=" line does not provide semantics other than indicating to which "m=" line a candidate belongs. Consequently, the receiving agent MUST ignore any remaining content of the pseudo "m=" line, which is not defined in this document. This guarantees that the 'application/trickle-ice-sdpfrag' bodies do not interfere with the Offer/Answer procedures as specified in [RFC3264]. When sending the INFO request, the agent MAY, if already known to the agent, include the same content into the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer. However, since Trickle-ICE might be decoupled from the Offer/Answer negotiation this content might be unknown to the agent. In this case, the agent MUST include the following default values. o The media field is set to 'audio'. o The port value is set to '9'. Ivov, et al. Expires December 24, 2018 [Page 16] Internet-Draft Trickle ICE for SIP June 2018 o The proto value is set to 'RTP/AVP'. o The fmt field MUST appear only once and is set to '0' Agents MUST include a pseudo "m=" line and an identification tag in a "a=mid:" attribute for every "m=" line whose candidate list they intend to update. Such "a=mid:" attributes MUST immediately precede the list of candidates for that specific "m=" line. All "a=candidate:" or "a=end-of-candidates" attributes following an "a=mid:" attribute, up until (and excluding) the next occurrence of a pseudo "m=" line, pertain to the "m=" line identified by that identification tag. Note, that there is no requirement that the Info request body contains as many pseudo m= lines as the Offer/Answer contains m=lines, nor that the pseudo m= lines be in the same order as the m=lines that they pertain to. The correspondence can be made via the "a=mid:" attributes since candidates are grouped in sections headed by "pseudo" m=lines. These sections contain "a=mid:" attribute values which point back to the true m=line. An "a=end-of-candidates" attribute, preceding the first pseudo "m=" line, indicates the end of all trickling from that agent, as opposed to end of trickling for a specific "m=" line, which would be indicated by a media level "a=end-of-candidates" attribute. Refer to Figure 7 for an example of the INFO request content. The use of pseudo "m=" lines allows for a structure similar to the one in SDP Offers and Answers where separate media-level and session- level sections can be distinguished. In the current case, lines preceding the first pseudo "m=" line are considered to be session- level. Lines appearing in between or after pseudo "m=" lines will be interpreted as media-level. Note that while this specification uses the "a=mid:" attribute from [RFC5888], it does not define any grouping semantics. All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" attributes that allow mapping them to a specific ICE generation. An agent MUST discard any received INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not match those of the current ICE Negotiation Session. The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also Ivov, et al. Expires December 24, 2018 [Page 17] Internet-Draft Trickle ICE for SIP June 2018 appear at the beginning of all INFO request payloads, i.e. preceding the first pseudo "m=" line. If they were originally exchanged as media level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines. Note that [I-D.ietf-ice-trickle] requires that when candidates are trickled, each candidate must be delivered to the receiving Trickle ICE implementation not more than once and in the same order as it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. This requirement is fulfilled as follows. Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer it MUST include all currently known and used local candidates in every INFO request. I.e. the agent MUST repeat in the INFO request body all candidates that were previously sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in the same order as they were sent before. In other words, the sequence of a previously sent list of candidates MUST NOT change in subsequent INFO requests and newly gathered candidates MUST be added at the end of that list. Although repeating all candidates creates some overhead, it also allows easier handling of problems that could arise from unreliable transports, like e.g. loss of messages and reordering, which can be detected through the CSeq: header field in the INFO request. In addition, an ICE agent needs to adhere to section 17 of [I-D.ietf-ice-trickle] on preserving candidate order while trickling. When receiving INFO requests carrying any candidates, agents MUST therefore first identify and discard the attribute lines containing candidates they have already received in previous INFO requests or in the Offer/Answer exchange preceding them. Such candidates are considered to be equal if their IP address port, transport and component ID are the same. After identifying and discarding the known candidates, the agents MUST forward the actually new candidates to the ICE Agents in the same order as they were received in the INFO request body. The ICE Agents will then process the new candidates according to the rules described in [I-D.ietf-ice-trickle]. Receiving an "a=end-of-candidates" attribute in an INFO request body - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - is an indication from the peer agent that it will not send any further candidates. When included at session level, i.e. before any pseudo "m=" line, this indication applies to Ivov, et al. Expires December 24, 2018 [Page 18] Internet-Draft Trickle ICE for SIP June 2018 the whole session; when included at media level the indication applies only to the corresponding "m=" line. Handling of such end- of-candidates indications is defined in [I-D.ietf-ice-trickle]. The example in Figure 7 shows the content of a candidate delivering INFO request. In the example the "a=end-of-candidates" attributes indicate that the candidate gathering is finished and that no further INFO requests follow. INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 862 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:1 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx raddr 192.0.2.1 rport 8998 a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx raddr 192.0.2.1 rport 8998 a=end-of-candidates m=audio 9 RTP/AVP 0 a=mid:2 a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx raddr 192.0.2.1 rport 9998 a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx raddr 192.0.2.1 rport 9998 a=end-of-candidates Note: In a real INFO request there will be no line breaks in the a=candidate: attributes Figure 7: An Example for the Content of an INFO Request Ivov, et al. Expires December 24, 2018 [Page 19] Internet-Draft Trickle ICE for SIP June 2018 5. Initial Discovery of Trickle ICE Support SIP User Agents (UAs) that support and intend to use trickle ICE are required by [I-D.ietf-ice-trickle] to indicate that in their Offers and Answers using the attribute "a=ice-options:trickle" and MUST include the SIP option-tag "trickle-ice" in a SIP Supported: or Require: header field. This makes discovery fairly straightforward for Answerers or for cases where Offers need to be generated within existing dialogs (i.e., when sending UPDATE or re-INVITE requests). In both scenarios prior SDP bodies will have provided the necessary information. Obviously, such information is not available at the time a first Offer is being constructed and it is therefore impossible for ICE Agents to determine support for incremental provisioning that way. The following options are suggested as ways of addressing this issue. 5.1. Provisioning Support for Trickle ICE In certain situations it may be possible for integrators deploying Trickle ICE to know in advance that some or all endpoints reachable from within the deployment will support Trickle ICE. This is the case, for example, if Session Border Controllers (SBC) with support for this specification are used to connect to UAs that do not support Trickle ICE. While the exact mechanism for allowing such provisioning is out of scope here, this specification encourages trickle ICE implementations to allow the option in the way they find most appropriate. However, an Offerer assuming Trickle ICE support MUST include a SIP Require: trickle-ice header field. That way, if the provisioned assumption of Trickle ICE support ends up being incorrect, the failure is (a) operationally easy to track down, and (b) recoverable by the client, i.e., they can re-send the request without the SIP Require: header field and without the assumption of Trickle ICE support. 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU) [RFC3840] provides a way for SIP User Agents to query for support of specific capabilities using, among others, OPTIONS requests. Support for GRUU according to [RFC5627] on the other hand allows SIP requests to be addressed to specific UAs (as opposed to arbitrary instances of an address of record). Combining the two and using the "trickle-ice" option tag defined in Section 10.6 provides SIP UAs with a way of learning the capabilities of specific SIP UA instances and then Ivov, et al. Expires December 24, 2018 [Page 20] Internet-Draft Trickle ICE for SIP June 2018 addressing them directly with INVITE requests that require Trickle ICE support. Such learning of capabilities may happen in different ways. One option for a SIP UA is to learn the GRUU instance ID of a peer through presence and then to query its capabilities with an OPTIONS request. Alternatively, it can also just send an OPTIONS request to the Address of Record (AOR) it intends to contact and then inspect the returned response(s) for support of both GRUU and Trickle ICE (Figure 8). It is noted that using the GRUU means that the INVITE request can go only to that particular device. This prevents the use of forking for that request. Alice Bob | | | OPTIONS sip:b1@example.com SIP/2.0 | |-------------------------------------------------->| | | | 200 OK | | Contact: sip:b1@example.com;gr=hha9s8d-999a | | ;audio;video|;trickle-ice;... | |<--------------------------------------------------| | | | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | | Supported: trickle-ice | | (Offer) | |-------------------------------------------------->| | | | 183 (Answer) | |<--------------------------------------------------| | INFO/OK (Trickling) | |<------------------------------------------------->| | | | ... | | | Figure 8: Trickle ICE support discovery with OPTIONS and GRUU Confirming support for Trickle ICE through [RFC3840] gives SIP UAs the options to engage in Full Trickle negotiation (as opposed to the more lengthy Half Trickle) from the very first Offer they send. 5.3. Fall-back to Half Trickle In cases where none of the other mechanisms in this section are acceptable, SIP UAs should use the Half Trickle mode defined in [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions Ivov, et al. Expires December 24, 2018 [Page 21] Internet-Draft Trickle ICE for SIP June 2018 the same way they would when using ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually sending an Offer, agents first gather ICE candidates in a blocking way and then send them all in that Offer. The blocking nature of the process implies that some amount of latency will be accumulated and it is advised that agents try to anticipate it where possible, for example, when user actions indicate a high likelihood for an imminent call (e.g., activity on a keypad or a phone going off-hook). Using Half Trickle results in Offers that are compatible with both ICE SIP endpoints and legacy [RFC3264] endpoints. Ivov, et al. Expires December 24, 2018 [Page 22] Internet-Draft Trickle ICE for SIP June 2018 STUN/Turn STUN/TURN Servers Alice Bob Servers | | | | |<--------------| | | | | | | | | | | | Candidate | | | | | | | | | | | | Discovery | | | | | | | | | | | |-------------->| INVITE (Offer) | | | |---------------------------->| | | | 183 (Answer) |-------------->| | |<----------------------------| | | | INFO (repeated candidates) | | | |---------------------------->| | | | | | | | INFO (more candidates) | Candidate | | |<----------------------------| | | | Connectivity Checks | | | |<===========================>| Discovery | | | INFO (more candidates) | | | |<----------------------------| | | | Connectivity Checks |<--------------| | |<===========================>| | | | | | | | 200 OK | | | |<----------------------------| | | | | | | |<======= MEDIA FLOWS =======>| | | | | | Figure 9: Example - A typical (Half) Trickle ICE exchange with SIP It is worth reminding that once a single Offer or Answer had been exchanged within a specific dialog, support for Trickle ICE will have been determined. No further use of Half Trickle will therefore be necessary within that same dialog and all subsequent exchanges can use the Full Trickle mode of operation. 6. Considerations for RTP and RTCP Multiplexing The following consideration describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing RTCP candidates. Ivov, et al. Expires December 24, 2018 [Page 23] Internet-Draft Trickle ICE for SIP June 2018 Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing [RFC5761] is already considered in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in [RFC5761] itself. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing. [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct for version 17 of said I-D. Authors need to cross-check during Auth48 since it could have have changed in the meantime.] If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" and the "a=rtcp-mux" attributes. While a Half Trickle Offerer has to send an Offer compliant to [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for all components, the flexibility of a Full Trickle Offerer allows to send only RTP candidates (component 1) in the initial Offer assuming that RTCP multiplexing is supported by the Answerer. A Full Trickle Offerer would need to start gathering and trickling RTCP candidates (component 2) only after having received an indication in the Answer that the Answerer unexpectedly does not support RTCP multiplexing. A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in the application/trickle-ice-sdpfrag body if it supports and uses RTP and RTCP multiplexing. The Trickle Answerer needs to follow the guidance on the usage of the "a=rtcp" attribute as given in [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use this information e.g. for stopping gathering of RTCP candidates and/or for freeing corresponding resources. This behavior is illustrated by the following example Offer that indicates support for RTP and RTCP multiplexing. Ivov, et al. Expires December 24, 2018 [Page 24] Internet-Draft Trickle ICE for SIP June 2018 v=0 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com s= c=IN IP6 2001:db8:a0b:12f0::3 t=0 0 a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-ufrag:Yhh8 m=audio 5000 RTP/AVP 0 a=mid:1 a=rtcp-mux a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host Once the dialog is established as described in section Section 4.3 the Answerer sends the following INFO request. INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 161 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:1 a=rtcp-mux a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host This INFO request indicates that the Answerer supports and uses RTP and RTCP multiplexing as well. It allows the Offerer to omit gathering of RTCP candidates or releasing already gathered RTCP candidates. If the INFO request did not contain the a=rtcp-mux attribute, the Offerer has to gather RTCP candidates unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for RTP and RTCP multiplexing. In case the Offerer had sent RTCP candidates in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even in case that support for RTCP multiplexing was confirmed by the Answerer and the Offerer has released its RTCP candidates. Ivov, et al. Expires December 24, 2018 [Page 25] Internet-Draft Trickle ICE for SIP June 2018 7. Considerations for Media Multiplexing The following considerations describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing candidates in case of Media Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed that the reader is familiar with [I-D.ietf-mmusic-sdp-bundle-negotiation]. ICE candidate exchange is already considered in section 11 of [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange, especially in Full Trickle mode. Except for bundle-only "m=" lines, a Half Trickle Offerer has to send an Offer with candidates for all bundled "m=" lines. The additional flexibility, however, allows a Full Trickle Offerer to initially send only candidates for the "m=" line with the suggested Offerer BUNDLE address. On receipt of the Answer, the Offerer will detect if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected. In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle. However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining "m=" lines as necessary. If the Answerer selects an Offerer BUNDLE address different from the suggested Offerer BUNDLE address, the Full Trickle Offerer needs to gather and trickle candidates for the "m=" line that carries the selected Offerer BUNDLE address. A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute [I-D.ietf-mmusic-sdp-bundle-negotiation] at session level in the application/trickle-ice-sdpfrag body if it supports and uses bundling. When doing so, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer. Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses bundling. The Offerer can use this information e.g. for stopping the gathering of candidates for the remaining "m=" lines in a bundle and/or for freeing corresponding resources. This behaviour is illustrated by the following example Offer that indicates support for Media Multiplexing. Ivov, et al. Expires December 24, 2018 [Page 26] Internet-Draft Trickle ICE for SIP June 2018 In case the Offerer had sent already candidates for "m="-lines in a bundle in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even in case that support for bundling was confirmed by the Answerer and the Offerer has released no longer needed candidates. v=0 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com s= c=IN IP6 2001:db8:a0b:12f0::3 t=0 0 a=group:BUNDLE foo bar a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-ufrag:Yhh8 m=audio 10000 RTP/AVP 0 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host m=video 10002 RTP/AVP 31 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid The example Offer indicates support for RTP and RTCP multiplexing and contains a "a=candidate:" attribute only for the "m="-line with the suggested Offerer bundle address. Once the dialog is established as described in Section 4.3 the Answerer sends the following INFO request. Ivov, et al. Expires December 24, 2018 [Page 27] Internet-Draft Trickle ICE for SIP June 2018 INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 219 a=group:BUNDLE foo bar a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:foo a=rtcp-mux a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host This INFO request indicates that the Answerer supports and uses Media Multiplexing as well. Note that the Answerer only includes a single pseudo "m="-line since candidates matching those from the second "m="-line in the offer are not needed from the Answerer. The INFO request also indicates that the Answerer accepted the suggested Offerer Bundle Address. This allows the Offerer to omit gathering of RTP and RTCP candidates for the other "m=" lines or releasing already gathered candidates. If the INFO request did not contain the a=group:BUNDLE attribute, the Offerer has to gather RTP and RTCP candidates for the other "m=" lines unless it wants to wait until receipt of an Answer that eventually confirms support or non- support for Media Multiplexing. Independent of using Full Trickle or Half Trickle mode, the rules from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and Answerer, when putting attributes as specified in Section 9.2 in the application/trickle-ice-sdpfrag body. 8. SDP 'end-of-candidates' Attribute 8.1. Definition This section defines a new SDP media-level and session-level attribute [RFC4566] 'end-of-candidates'. 'end-of-candidates' is a property attribute [RFC4566], and hence has no value. By including this attribute in an Offer or Answer the sending agent indicates that it will not trickle further candidates. When included at session level this indication applies to the whole session, when included at media level the indication applies only to the corresponding media description. Ivov, et al. Expires December 24, 2018 [Page 28] Internet-Draft Trickle ICE for SIP June 2018 Name: end-of-candidates Value: N/A Usage Level: media and session-level Charset Dependent: no Mux Category: IDENTICAL Example: a=end-of-candidates 8.2. Offer/Answer Procedures The Offerer or Answerer MAY include an "a=end-of-candidates" attribute in case candidate discovery has ended and no further candidates are to be trickled. The Offerer or Answerer MUST provide the "a=end-of-candidates" attribute together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the current ICE generation as required by [I-D.ietf-ice-trickle]. When included at session level this indication applies to the whole session; when included at media level the indication applies only to the corresponding media description. Receipt of an "a=end-of-candidates" attribute at an Offerer or Answerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - indicates that gathering of candidates has ended at the peer, either for the session or only for the corresponding media description as specified above. The receiving agent forwards an end-of-candidates indication to the ICE Agent, which in turn acts as specified in [I-D.ietf-ice-trickle]. 9. Content Type 'application/trickle-ice-sdpfrag' 9.1. Overall Description A application/trickle-ice-sdpfrag body is used exclusively by the 'trickle-ice' Info Package. Other SDP related applications need to define their own media type. The INFO request body uses a subset of the possible SDP lines as defined by the grammar defined in [RFC4566]. A valid body uses only pseudo "m=" lines and certain attributes that are needed and/or useful for trickling candidates. The content adheres to the following grammar. 9.2. Grammar The grammar of an 'application/trickle-ice-sdpfrag' body is based on the following ABNF [RFC5234]. It specifies the subset of existing SDP attributes, that is needed or useful for trickling candidates. Ivov, et al. Expires December 24, 2018 [Page 29] Internet-Draft Trickle ICE for SIP June 2018 The grammar uses the indicator for case-sensitivity %s as defined in [RFC7405], but also imports grammars for other SDP attributes that precede the production of [RFC7405]. A sender SHOULD use lower-case for attributes from such earlier grammars, but a receiver MUST treat them case-insensitively. Ivov, et al. Expires December 24, 2018 [Page 30] Internet-Draft Trickle ICE for SIP June 2018 ; Syntax trickle-ice-sdpfrag = session-level-fields pseudo-media-descriptions session-level-fields = *(session-level-field CRLF) session-level-field = ice-lite-attribute / ice-pwd-attribute / ice-ufrag-attribute / ice-options-attribute / ice-pacing-attribute / end-of-candidates-attribute / bundle-group-attribute / extension-attribute-fields ; for future extensions ice-lite-attribute = %s"a" "=" ice-lite ice-pwd-attribute = %s"a" "=" ice-pwd-att ice-ufrag-attribute = %s"a" "=" ice-ufrag-att ice-pacing-attribute = %s"a" "=" ice-pacing-att ice-options-attribute = %s"a" "=" ice-options end-of-candidates-attribute = %s"a" "=" end-of-candidates end-of-candidates = %s"end-of-candidates" bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics *(SP identification-tag) bundle-semantics = "BUNDLE" extension-attribute-fields = attribute-fields pseudo-media-descriptions = *( media-field trickle-ice-attribute-fields ) trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF) trickle-ice-attribute-field = mid-attribute / candidate-attributes / ice-pwd-attribute / ice-ufrag-attribute / remote-candidate-attribute / end-of-candidates-attribute / rtcp-attribute / rtcp-mux-attribute / rtcp-mux-only-attribute / extension-attribute-fields ; for future extensions rtcp-attribute = %s"a" "=" %s"rtcp" rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux" rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only" candidate-attributes = %s"a" "=" candidate-attribute remote-candidate-attribute = %s"a" "=" remote-candidate-att Ivov, et al. Expires December 24, 2018 [Page 31] Internet-Draft Trickle ICE for SIP June 2018 with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- pacing-att, ice-options, candidate-attribute remote-candidate-att from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal grammar in their corresponding RFC and are reproduced here. The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also appear at the beginning of all INFO request payloads, i.e. preceding all pseudo "m=" lines. If they were originally exchanged as media level attributes, potentially overriding session-level values, then they will also be included in INFO request payloads following the corresponding pseudo "m=" lines. An Agent MUST ignore any received unknown extension-attribute-fields. 10. Info Package 10.1. Rationale - Why INFO? The decision to use SIP INFO requests as a candidate transport method is based primarily on their lightweight nature. Once a dialog has been established, INFO requests can be exchanged both ways with no restrictions on timing and frequency and no risk of collision. A critical fact is that the sending of Trickle ICE candidates in one direction is entirely uncoupled from sending candidates in the other direction. Thus, the sending of candidates in each direction can be done by a stream of INFO requests that is not correlated with the stream of INFO requests in the other direction. And since each INFO request cumulatively includes the contents of all previous INFO requests in that direction, ordering between INFO requests need not be preserved. All of this permits using largely-independent INFO requests. Contrarily, UPDATE or other offer/answer mechanisms assume that the messages in each direction are tightly coupled with messages in the other direction. Using Offer/Answer and UPDATE requests [RFC3311] would introduce the following complications: Blocking of messages: [RFC3264] defines Offer/Answer as a strictly sequential mechanism. There can only be a maximum of one active exchange at any point of time. Both sides cannot simultaneously send Offers nor can they generate multiple Offers prior to Ivov, et al. Expires December 24, 2018 [Page 32] Internet-Draft Trickle ICE for SIP June 2018 receiving an Answer. Using UPDATE requests for candidate transport would therefore imply the implementation of a candidate pool at every agent where candidates can be stored until it is once again that agent's "turn" to emit an Answer or a new Offer. Such an approach would introduce non-negligible complexity for no additional value. Elevated risk of glare: The sequential nature of Offer/Answer also makes it impossible for both sides to send Offers simultaneously. What's worse is that there are no mechanisms in SIP to actually prevent that. [RFC3261], where the situation of Offers crossing on the wire is described as "glare", only defines a procedure for addressing the issue after it has occurred. According to that procedure both Offers are invalidated and both sides need to retry the negotiation after a period between 0 and 4 seconds. The high likelihood for glare to occur and the average two second back-off intervals implies that the duration of Trickle ICE processing would not only fail to improve but actually exceed those of regular ICE. INFO messages decouple the exchange of candidates from the Offer/ Answer negotiation and are subject to none of the glare issues described above, which makes them a very convenient and lightweight mechanism for asynchronous delivery of candidates. Using in-dialog INFO messages also provides a way of guaranteeing that candidates are delivered end-to-end, between the same entities that are actually in the process of initiating a session. Out-of- dialog alternatives would have implied requiring support for Globally Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low adoption levels, would have constituted too strong of a constraint to the adoption of Trickle ICE. 10.2. Overall Description This specification defines an Info Package for use by SIP User Agents implementing Trickle ICE. INFO requests carry ICE candidates discovered after the peer user agents have confirmed mutual support for Trickle ICE. 10.3. Applicability The purpose of the ICE protocol is to establish a media path in the presence of NAT and firewalls. The candidates are transported in INFO requests and are part of this establishment. Candidates sent by a Trickle ICE Agent after the Offer, follow the same signaling path and reach the same entity as the Offer itself. Ivov, et al. Expires December 24, 2018 [Page 33] Internet-Draft Trickle ICE for SIP June 2018 While it is true that GRUUs can be used to achieve this, one of the goals of this specification is to allow operation of Trickle ICE in as many environments as possible including those without GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not satisfy this goal. 10.4. Info Package Name This document defines a SIP Info Package as per [RFC6086]. The Info Package token name for this package is "trickle-ice" 10.5. Info Package Parameters This document does not define any Info Package parameters. 10.6. SIP Option Tags [RFC6086] allows Info Package specifications to define SIP option- tags. This specification extends the option-tag construct of the SIP grammar as follows: option-tag /= "trickle-ice" SIP entities that support this specification MUST place the 'trickle- ice' option-tag in a SIP Supported: or Require: header field within all SIP INVITE requests and responses. When responding to, or generating a SIP OPTIONS request a SIP entity MUST also include the 'trickle-ice' option-tag in a SIP Supported: or Require: header field. 10.7. Info Request Body Parts Entities implementing this specification MUST include a payload of type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in SIP INFO requests. The payload is used to convey SDP-encoded ICE candidates. 10.8. Info Package Usage Restrictions This document does not define any Info Package Usage Restrictions. 10.9. Rate of INFO Requests Given that IP addresses may be gathered rapidly a Trickle ICE Agent with many network interfaces might create a high rate of INFO requests if every newly detected candidate is trickled individually without aggregation. An implementation MUST aggregate ICE candidates Ivov, et al. Expires December 24, 2018 [Page 34] Internet-Draft Trickle ICE for SIP June 2018 in case that an unreliable transport protocol such as UDP is used. A Trickle ICE agent MUST NOT have more than one INFO request pending at any one time. When INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in [RFC3261] section 17.1.2.1." If the INFO requests are sent on top of TCP, which is probably the standard way, this is not an issue for the network anymore, but it can remain one for SIP proxies and other intermediaries forwarding the SIP INFO messages. Also, an endpoint may not be able to tell that it has congestion controlled transport all the way. 10.10. Info Package Security Considerations See Section 13 11. Deployment Considerations Trickle ICE uses two mechanisms for exchange of candidate information. This imposes new requirements to certain middleboxes that are used in some networks, e.g. for monitoring purposes. While the first mechanism, SDP Offers and Answers, is already used by regular ICE and is assumed to be supported, the second mechanism, INFO request bodies, needs to be considered by such middleboxes as well when trickle ICE is used. Such middleboxes need to make sure that they remain in the signaling path of the INFO requests and need to understand the INFO request body. 12. IANA Considerations [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. ] 12.1. SDP 'end-of-candidates' Attribute This section defines a new SDP media-level and session-level attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a property attribute [RFC4566] , and hence has no value. Ivov, et al. Expires December 24, 2018 [Page 35] Internet-Draft Trickle ICE for SIP June 2018 Name: end-of-candidates Value: N/A Usage Level: media and session Charset Dependent: no Purpose: The sender indicates that it will not trickle further ICE candidates. O/A Procedures: RFCXXX defines the detailed SDP Offer/Answer procedures for the 'end-of-candidates' attribute. Mux Category: IDENTICAL Reference: RFCXXXX Example: a=end-of-candidates 12.2. Media Type 'application/trickle-ice-sdpfrag' This document defines a new Media Type 'application/trickle-ice- sdpfrag' in accordance with [RFC6838]. Type name: application Subtype name: trickle-ice-sdpfrag Required parameters: None. Optional parameters: None. Encoding considerations: The media contents follow the same rules as SDP, except as noted in this document. The media contents are text, with the grammar specified in Section 9.2. Although the initially defined content of a trickle-ice-sdpfrag body does only include ASCII characters, UTF-8 encoded content might be introduced via extension attributes. The "a=charset:" Ivov, et al. Expires December 24, 2018 [Page 36] Internet-Draft Trickle ICE for SIP June 2018 attribute may be used to signal the presence of other character sets in certain parts of a trickle-ice-sdpfrag body (see [RFC4566]). Arbitrary binary content cannot be directly represented in SDP or a trickle-ice-sdpfrag body. Security considerations: See [RFC4566] and RFCXXXX Interoperability considerations: See RFCXXXX Published specification: See RFCXXXX Applications which use this Media Type: Trickle-ICE Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh File Type Code(s): N/A Person and email address to contact for further information: The IESG (iesg@ietf.org) Ivov, et al. Expires December 24, 2018 [Page 37] Internet-Draft Trickle ICE for SIP June 2018 Intended usage: Trickle-ICE for SIP as specified in RFCXXXX. Restrictions on usage: N/A Author/Change controller: The IESG (iesg@ietf.org) Provisional registration? (standards tree only): N/A 12.3. SIP Info Package 'trickle-ice' This document defines a new SIP Info Package named 'trickle-ice' and updates the Info Packages Registry with the following entry. +-------------+-----------+ | Name | Reference | +-------------+-----------+ | trickle-ice | [RFCXXXX] | | | | +-------------+-----------+ 12.4. SIP Option Tag 'trickle-ice' This specification registers a new SIP option tag 'trickle-ice' as per the guidelines in Section 27.1 of [RFC3261] and updates the "Option Tags" section of the SIP Parameter Registry with the following entry: +-------------+-------------------------------------+-----------+ | Name | Description | Reference | +-------------+-------------------------------------+-----------+ | trickle-ice | This option tag is used to indicate | [RFCXXXX] | | | that a UA supports and understands | | | | Trickle-ICE. | | +-------------+-------------------------------------+-----------+ 13. Security Considerations The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies Ivov, et al. Expires December 24, 2018 [Page 38] Internet-Draft Trickle ICE for SIP June 2018 how the above specifications are used together for trickling candidates and does not create additional security risks. The new Info Package 'trickle-ice' and the new Media Type 'application/trickle-ice-sdpfrag' do not introduce additional security considerations when used in the context of Trickle ICE. Both are not intended to be used for other applications, so any security considerations for its use in other contexts is out of the scope of this document 14. Acknowledgements The authors like to thank Flemming Andreasen, Ayush Jain, Paul Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin Thomson for reviewing and/or making various suggestions for improvements and optimizations. The authors also like to thank Flemming Andreasen for shepherding this document and Ben Campbell for his AD review and suggestions. In addition, the author like to thank Benjamin Kaduk, Adam Roach, Mirja Kuehlewind and Eric Rescorla for their comments and/or text proposals for improving the document during IESG review. Many thanks to Dale Worley for Gen-Art review and proposed enhancements for several sections. Many thanks to Joerg Ott for TSV-Art review and suggested improvements. The authors thank Shawn Emery for Security Directorate review. 15. Change Log [RFC EDITOR NOTE: Please remove this section when publishing]. Changes from draft-ietf-mmusic-trickle-ice-sip-01 o Editorial Clean up o IANA Consideration added o Security Consideration added o RTCP and BUNDLE Consideration added with rules for including "a=rtcp-mux" and "a=group: BUNDLLE" attributes o 3PCC Consideration added Ivov, et al. Expires December 24, 2018 [Page 39] Internet-Draft Trickle ICE for SIP June 2018 o Clarified that 18x w/o answer is sufficient to create a dialog that allows for trickling to start o Added remaining Info Package definition sections as outlined in section 10 of [RFC6086] o Added definition of application/sdpfrag making draft-ivov-mmusic- sdpfrag obsolete o Added pseudo m-lines as additional separator in sdpfrag bodies for Trickle ICE o Added ABNF for sdp-frag bodies and Trickle-ICE package Changes from draft-ietf-mmusic-trickle-ice-sip-02 o Removed definition of application/sdpfrag o Replaced with new type application/trickle-ice-sdpfrag o RTCP and BUNDLE Consideration enhanced with some examples o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to normative reference o Removed reference to 4566bis o Addressed review comment from Simon Perreault Changes from draft-ietf-mmusic-trickle-ice-sip-03 o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and draft-ietf-mmusic-ice-sip-sdp o Corrected Figure 10, credits to Ayush Jain for finding the bug o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- ice-sip-sdp o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the application/trickle-ice-sdpfrag body Changes from draft-ietf-mmusic-trickle-ice-sip-04 o considered comments from Christer Holmberg Ivov, et al. Expires December 24, 2018 [Page 40] Internet-Draft Trickle ICE for SIP June 2018 o corrected grammar for INFO package, such that ice-ufrag/pwd are also allowed on media-level as specified in [I-D.ietf-mmusic-ice-sip-sdp] o Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp] o Added formal definition for the end-of-candidates attribute Changes from draft-ietf-mmusic-trickle-ice-sip-05 o considered further comments from Christer Holmberg o editorial comments on section 3 addressed o moved section 3.1 to section 10.1 and applied some edits o replaced the term "previously sent candidates" with "currently known and used candidates". Changes from draft-ietf-mmusic-trickle-ice-sip-06 o editorial fixes o additional text on the content of the INFO messages. o recommendation on what to do if a previously sent candidate is unexpectedly missing in a subsequent INFO o terminology alignment with draft-ietf-ice-trickle-07 Changes from draft-ietf-mmusic-trickle-ice-sip-07 o editorial fixes o clarification on ordering of candidates for alignment with draft- ietf-ice-trickle-12 o O/A procedures for end-of-candidates attribute described here after corresponding procedures have been removed from draft-ietf- ice-trickle-11 o using IPv6 addresses in examples Changes from draft-ietf-mmusic-trickle-ice-sip-08 o editorial fixes/clarification based on Flemmings review Ivov, et al. Expires December 24, 2018 [Page 41] Internet-Draft Trickle ICE for SIP June 2018 o Description of Trickle specifics in O/A procedures for initial O/A exchange and specification of ICE mismatch exception Changes from draft-ietf-mmusic-trickle-ice-sip-09 o editorial fixes/correction of references o adding missing Ref to RFC3605 in section 6, 5th para o replaced remaining IPv4 adresses with IPv6 o Added text for handling a=rtcp in case of default RTP address 0.0.0.0:9 based on comment from Roman Shpount. Changes from draft-ietf-mmusic-trickle-ice-sip-10 o editorial fixes due to idnits output Changes from draft-ietf-mmusic-trickle-ice-sip-11 o addressing comments from Ben Campell's AD review and Christer's review o Numerous editorial improvements/corrections o Added [RFC8174] boiler plate and adapted usage of normative language o Clarified terminology ICE modules .vs. ICE agent o Added more detailed OA procedures o Corrected default values in m-line and usage of "a=mid:" attribute explicitly mentioned for offer/answer o Removed explicit mentioning of XMPP o Added Deployment Considerations section o Fixed ref for rfc5245bis Changes from draft-ietf-mmusic-trickle-ice-sip-12 o addressing comments from Gen-Art review, TSV-Art review and Security Directorate review o Numerous editorial improvements/corrections/clarifications Ivov, et al. Expires December 24, 2018 [Page 42] Internet-Draft Trickle ICE for SIP June 2018 Changes from draft-ietf-mmusic-trickle-ice-sip-13 o added expansions for SDP,GRUU, AOR, STUN, TURN o some editorial corrections Changes from draft-ietf-mmusic-trickle-ice-sip-14 Addressing comments from IESG review o Clarification/enhancement in section 5 and Fig. 10 based on comments from Benjamin Kaduk o Clarification on sequence for sending candidates, definition of pseudo m-lines, usage of a=mid attribute, usage of INFO as ACK for receipt of 18x based on comments from Eric Rescorla o Removal of 3PCC Section 3.4, removal of NATted IPv6 addresses, adding more flexibility to in the grammar, explicit mentioning of Require: header field, usage of Require: header field in case of provisioning, text on repetition of candidates in case of RTCP mux and Bundle, various other editorial improvements/corrections based on comments from Adam Roach o Modified text on rate limitation of INFO requests based on comments of Mirja Kuehlewind, Adam Roach and Roman Shpount o some editorial corrections Changes from draft-ietf-mmusic-trickle-ice-sip-15 o Corrections in section 7 on Media Multiplexing Changes from draft-ietf-mmusic-trickle-ice-sip-16 o some editorial corrections Changes from draft-ietf-mmusic-trickle-ice-sip-16 o Changed IPv6 candidate example from srflx to host 16. References 16.1. Normative References Ivov, et al. Expires December 24, 2018 [Page 43] Internet-Draft Trickle ICE for SIP June 2018 [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-20 (work in progress), March 2018. [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in progress), April 2018. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-12 (work in progress), May 2017. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-52 (work in progress), May 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . Ivov, et al. Expires December 24, 2018 [Page 44] Internet-Draft Trickle ICE for SIP June 2018 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, . Ivov, et al. Expires December 24, 2018 [Page 45] Internet-Draft Trickle ICE for SIP June 2018 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 16.2. Informative References [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, . [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, . [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, . [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, . Authors' Addresses Ivov, et al. Expires December 24, 2018 [Page 46] Internet-Draft Trickle ICE for SIP June 2018 Emil Ivov Jitsi Strasbourg 67000 France Phone: +33 6 72 81 15 55 Email: emcho@jitsi.org Thomas Stach Unaffiliated Vienna 1130 Austria Email: thomass.stach@gmail.com Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy Email: enrico.marocco@telecomitalia.it Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Ivov, et al. Expires December 24, 2018 [Page 47] ./draft-ietf-mpls-base-yang-17.txt0000644000764400076440000014545213745606430016222 0ustar iustyiusty MPLS Working Group T. Saad Internet-Draft Juniper Networks Intended status: Standards Track K. Raza Expires: April 29, 2021 R. Gandhi Cisco Systems Inc X. Liu Volta Networks V. Beeram Juniper Networks October 26, 2020 A YANG Data Model for MPLS Base draft-ietf-mpls-base-yang-17 Abstract This document contains a specification of the MPLS base YANG data model. The MPLS base YANG data model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS- enabled router. It is expected that other MPLS YANG data models (e.g. MPLS Label Switched Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS base YANG data model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2021. Copyright Notice Copyright (c) 2020 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 Saad, et al. Expires April 29, 2021 [Page 1] Internet-Draft MPLS Base YANG Data Model October 2020 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 2. MPLS Base Model . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 4 2.2. Model Organization . . . . . . . . . . . . . . . . . . . 4 2.3. Model Design . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Model Tree Diagram . . . . . . . . . . . . . . . . . . . 8 2.5. Model YANG Module . . . . . . . . . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 6. Appendix A. Data Tree Instance Example . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction A core routing YANG data model is defined in [RFC8349], and it provides a basis for the development of routing data models for specific Address Families (AFs). Specifically, [RFC8349] defines a model for a generic Routing Information Base (RIB) that is Address- Family (AF) agnostic. [RFC8349] also defines two instances of RIBs based on the generic RIB model for IPv4 and IPv6 AFs. The MPLS base model that is defined in this document augments the generic RIB model defined in [RFC8349] with additional data that enables MPLS forwarding for the specific destination prefix(es) present in the AF RIB(s) as described in the MPLS architecture document [RFC3031]. The MPLS base model also defines a new instance of the generic RIB YANG data model as defined in [RFC8349] to store native MPLS routes. The native MPLS RIB instance stores route(s) that are not associated with other AF instance RIBs (such as IPv4, or IPv6 instance RIB(s)), Saad, et al. Expires April 29, 2021 [Page 2] Internet-Draft MPLS Base YANG Data Model October 2020 but are enabled for MPLS forwarding. Examples of such native MPLS routes are routes programmed by RSVP on transit MPLS router(s) along the path of a Label Switched Path (LSP). Other example(s) are MPLS routes that cross-connect to specific Layer-2 adjacencies, such as Layer-2 Attachment Circuit(s) (ACs)), or Layer-3 adjacencies, such as Segment-Routing (SR) Adjacency Segments (Adj-SIDs) described in [RFC8402]. The MPLS base YANG data model serves as a basis for future development of MPLS YANG data models covering more-sophisticated MPLS feature(s) and sub-system(s). The main purpose is to provide essential building blocks for other YANG data models involving different control-plane protocols, and MPLS functions. To this end, it is expected that the MPLS base data model will be augmented by a number of other YANG modules developed at IETF (e.g. by TEAS and MPLS working groups). The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. 1.1. Terminology The terminology for describing YANG data models is found in [RFC7950]. 1.2. Acronyms and Abbreviations MPLS: Multiprotocol Label Switching RIB: Routing Information Base LSP: Label Switched Path LSR: Label Switching Router LER: Label Edge Router FEC: Forwarding Equivalence Class NHLFE: Next Hop Label Forwarding Entry ILM: Incoming Label Map Saad, et al. Expires April 29, 2021 [Page 3] Internet-Draft MPLS Base YANG Data Model October 2020 2. MPLS Base Model This document describes the 'ietf-mpls' YANG module that provides base components of the MPLS data model. It is expected that other MPLS YANG modules will augment 'ietf-mpls' YANG module for other MPLS extension to provision Label Switched Paths (LSPs) (e.g. MPLS Static, MPLS LDP or MPLS RSVP-TE LSP(s)). 2.1. Model Overview This document models MPLS labeled routes as an augmentation of the generic routing RIB data model as defined in [RFC8349]. For example, IP prefix routes (e.g. routes stored in IPv4 or IPv6 RIBs) are augmented to carry additional data to enable it for MPLS forwarding. This document also defines a new instance of the generic RIB defined in [RFC8349] to store native MPLS route(s) (described further in Section 2.3) by extending the identity 'address-family' defined in [RFC8349] with a new "mpls" identity as suggested in Section 3 of [RFC8349]. 2.2. Model Organization Routing +---------------+ v: import YANG module | ietf-routing | o: augment +---------------+ o | v MPLS base +-----------+ v: import YANG module | ietf-mpls | o: augment +-----------+ o o------+ | \ v v +-------------------+ +---------------------+ MPLS Static | ietf-mpls-static@ | | ietf-mpls-ldp.yang@ | . . LSP YANG +-------------------+ +---------------------+ module @: not in this document, shown for illustration only Figure 1: Relationship between MPLS modules The 'ietf-mpls' YANG module defines the following identities: mpls: Saad, et al. Expires April 29, 2021 [Page 4] Internet-Draft MPLS Base YANG Data Model October 2020 This identity extends the 'address-family' identity for RIB instance(s) identity as defined in [RFC8349] to represent the native MPLS RIB instance. label-block-alloc-mode: A base YANG identity for supported label block allocation mode(s). The 'ietf-mpls' YANG module contains the following high-level types and groupings: mpls-operations-type: An enumeration type that represents support for possible MPLS operation types (impose-and-forward, pop-and-forward, pop-impose- and-forward, and pop-and-lookup) nhlfe-role: An enumeration type that represents the role of the NHLFE entry. nhlfe-single-contents: A YANG grouping that describes single Next Hop Label Forwarding Entry (NHLFE) and its associated parameters as described in the MPLS architecture document [RFC3031]. This grouping is specific to the case when a single next-hop is associated with the route. The NHLFE is used when forwarding labeled packet. It contains the following information: 1. the packet's next hop. For 'nhlfe-single-contents' only a single next hop is expected, while for 'nhlfe-multiple-contents' multiple next hops are possible. 2. the operation to perform on the packet's label stack; this can be one of the following operations: a) replace the label at the top of the label stack with one or more specified new label b) pop the label stack c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack. d) push one or more label(s) on an unlabeled packet It may also contain: Saad, et al. Expires April 29, 2021 [Page 5] Internet-Draft MPLS Base YANG Data Model October 2020 d) the data link encapsulation to use when transmitting the packet e) the way to encode the label stack when transmitting the packet f) any other information needed in order to properly dispose of the packet. nhlfe-multiple-contents: A YANG grouping that describes a set of NHLFE(s) and their associated parameters as described in the MPLS architecture document [RFC3031]. This grouping is used when multiple next-hops are associated with the route. interfaces-mpls: A YANG grouping that describes the list of MPLS enabled interfaces on a device. label-blocks: A YANG grouping that describes the list of assigned MPLS label blocks and their properties. rib-mpls-properties: A YANG grouping for the augmentation of the generic RIB with MPLS label forwarding data as defined in [RFC3031]. rib-active-route-mpls-input: A YANG grouping for the augmentation to the 'active-route' RPC that is specific to the MPLS RIB instance. 2.3. Model Design The MPLS routing model is based on the core routing data model defined in [RFC8349]. Figure 2 shows the extensions introduced by the MPLS base model on defined RIB(s). Saad, et al. Expires April 29, 2021 [Page 6] Internet-Draft MPLS Base YANG Data Model October 2020 +-----------------+ | MPLS base model | +-----------------+ ____/ | |_____ |________ / | \ \ / | \ \ o o o + +---------+ +---------+ +--------+ +-----------+ | RIB(v4) | | RIB(v6) | | RIB(x) | | RIB(mpls) | +---------+ +---------+ +--------+ +-----------+ +: created by the MPLS base model o: augmented by the MPLS base model Figure 2: Relationship between MPLS model and RIB instances As shown in Figure 2, the MPLS base YANG data model augments defined instance(s) of AF RIB(s) with additional data that enables MPLS forwarding for destination prefix(es) store in such RIB(s). For example, an IPv4 prefix stored in RIB(v4) is augmented to carry a MPLS local label and per next-hop remote label(s) to enable MPLS forwarding for such prefix. The MPLS base model also creates a separate instance of the generic RIB model defined in [RFC8349] to store MPLS native route(s) that are enabled for MPLS forwarding, but not stored in other AF RIB(s). Some examples of such native MPLS routes are: o routes programmed by RSVP on Label Switched Router(s) (LSRs) along the path of a Label Switched Path (LSP), o routes that cross-connect an MPLS local label to a Layer-2, or Layer-3 VRF, o routes that cross-connect an MPLS local label to a specific Layer-2 adjacency or interface, such as Layer-2 Attachment Circuit(s) (ACs), or o routes that cross-connect an MPLS local label to a Layer-3 adjacency or interface - such as MPLS Segment-Routing (SR) Adjacency Segments (Adj-SIDs), SR MPLS Binding SIDs, etc. as defined in [RFC8402]. Saad, et al. Expires April 29, 2021 [Page 7] Internet-Draft MPLS Base YANG Data Model October 2020 2.4. Model Tree Diagram The MPLS base tree diagram that follows the notation defined in [RFC8340] is shown in Figure 3. module: ietf-mpls augment /rt:routing: +--rw mpls +--rw ttl-propagate? boolean +--rw mpls-label-blocks | +--rw mpls-label-block* [index] | +--rw index string | +--rw start-label? rt-types:mpls-label | +--rw end-label? rt-types:mpls-label | +--rw block-allocation-mode? identityref | +--ro inuse-labels-count? yang:gauge32 +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw mpls-enabled? boolean +--rw maximum-labeled-packet? uint32 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: +--ro mpls-enabled? boolean +--ro mpls-local-label? rt-types:mpls-label +--ro destination-prefix? -> ../mpls-local-label +--ro route-context? string augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop /rt:next-hop-options/rt:simple-next-hop: +--ro mpls-label-stack +--ro entry* [id] +--ro id uint8 +--ro label? rt-types:mpls-label +--ro ttl? uint8 +--ro traffic-class? uint8 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop /rt:next-hop-options/rt:next-hop-list/rt:next-hop-list /rt:next-hop: +--ro index? string +--ro backup-index? string +--ro loadshare? uint16 +--ro role? nhlfe-role +--ro mpls-label-stack +--ro entry* [id] +--ro id uint8 +--ro label? rt-types:mpls-label +--ro ttl? uint8 +--ro traffic-class? uint8 augment /rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input: Saad, et al. Expires April 29, 2021 [Page 8] Internet-Draft MPLS Base YANG Data Model October 2020 +---w destination-address? -> ../mpls-local-label +---w mpls-local-label? rt-types:mpls-label augment /rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output /rt:route/rt:next-hop/rt:next-hop-options /rt:simple-next-hop: +-- mpls-label-stack +-- entry* [id] +-- id uint8 +-- label? rt-types:mpls-label +-- ttl? uint8 +-- traffic-class? uint8 augment /rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output /rt:route/rt:next-hop/rt:next-hop-options /rt:next-hop-list/rt:next-hop-list/rt:next-hop: +-- index? string +-- backup-index? string +-- loadshare? uint16 +-- role? nhlfe-role +-- mpls-label-stack +-- entry* [id] +-- id uint8 +-- label? rt-types:mpls-label +-- ttl? uint8 +-- traffic-class? uint8 Figure 3: MPLS Base tree diagram 2.5. Model YANG Module This section describes the 'ietf-mpls' YANG module that provides base components of the MPLS data model. Other YANG module(s) may import and augment the base MPLS module to add feature specific data. The ietf-mpls YANG module imports the following YANG modules: o ietf-routing defined in [RFC8349] o ietf-routing-types defined in [RFC8294] o ietf-interfaces defined in [RFC8343] This YANG module also references the following RFCs in defining the types and YANG grouping of the YANG module: [RFC3032], [RFC3031], and [RFC7424]. file "ietf-mpls@2020-10-26.yang" module ietf-mpls { yang-version 1.1; Saad, et al. Expires April 29, 2021 [Page 9] Internet-Draft MPLS Base YANG Data Model October 2020 namespace "urn:ietf:params:xml:ns:yang:ietf-mpls"; /* Replace with IANA when assigned */ prefix mpls; import ietf-routing { prefix rt; reference "RFC8349: A YANG Data Model for Routing Management"; } import ietf-routing-types { prefix rt-types; reference "RFC8294:Common YANG Data Types for the Routing Area"; } import ietf-yang-types { prefix yang; reference "RFC6991: Common YANG Data Types"; } import ietf-interfaces { prefix if; reference "RFC8343: A YANG Data Model for Interface Management"; } organization "IETF MPLS Working Group"; contact "WG Web: WG List: Editor: Tarek Saad Editor: Kamran Raza Editor: Rakesh Gandhi Editor: Xufeng Liu Editor: Vishnu Pavan Beeram "; Saad, et al. Expires April 29, 2021 [Page 10] Internet-Draft MPLS Base YANG Data Model October 2020 description "This YANG module defines the essential components for the management of the MPLS subsystem. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2020-10-26 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for base MPLS"; } /* Identities */ identity mpls { base rt:address-family; description "This identity represents the MPLS address family."; } identity mpls-unicast { base mpls:mpls; description "This identity represents the MPLS unicast address family."; } identity label-block-alloc-mode { description "Base identity for label-block allocation mode."; } Saad, et al. Expires April 29, 2021 [Page 11] Internet-Draft MPLS Base YANG Data Model October 2020 identity label-block-alloc-mode-manager { base label-block-alloc-mode; description "Label block allocation on reserved block is managed by label manager."; } identity label-block-alloc-mode-application { base label-block-alloc-mode; description "Label block allocation on reserved block is managed by application."; } /** * Typedefs */ typedef mpls-operations-type { type enumeration { enum impose-and-forward { description "Operation impose outgoing label(s) and forward to next-hop."; } enum pop-and-forward { description "Operation pop incoming label and forward to next-hop."; } enum pop-impose-and-forward { description "Operation pop incoming label, impose one or more outgoing label(s) and forward to next-hop."; } enum swap-and-forward { description "Operation swap incoming label, with outgoing label and forward to next-hop."; } enum pop-and-lookup { description "Operation pop incoming label and perform a lookup."; } } description "MPLS operations types."; } Saad, et al. Expires April 29, 2021 [Page 12] Internet-Draft MPLS Base YANG Data Model October 2020 typedef nhlfe-role { type enumeration { enum primary { description "Next-hop acts as primary for carrying traffic."; } enum backup { description "Next-hop acts as backup."; } enum primary-and-backup { description "Next-hop acts as primary and backup simultaneously for carry traffic."; } } description "The next-hop role."; } grouping nhlfe-single-contents { description "A grouping that describes single Next Hop Label Forwarding Entry (NHLFE) and its associated parameters as described in the MPLS architecture. This grouping is specific to the case when a single next-hop is associated with the route."; uses rt-types:mpls-label-stack; } grouping nhlfe-multiple-contents { description "A grouping that describes a set of NHLFE(s) and their associated parameters as described in the MPLS architecture. This grouping is used when multiple next-hops are associated with the route."; leaf index { type string; description "A user-specified identifier utilised to uniquely reference the next-hop entry in the next-hop list. The value of this index has no semantic meaning other than for referencing the entry."; } leaf backup-index { type string; description "A user-specified identifier utilised to uniquely reference the backup next-hop entry in the NHLFE list. Saad, et al. Expires April 29, 2021 [Page 13] Internet-Draft MPLS Base YANG Data Model October 2020 The value of this index has no semantic meaning other than for referencing the entry."; reference "RFC4090 and RFC5714"; } leaf loadshare { type uint16; default "1"; description "This value is used to compute a loadshare to perform un-equal load balancing when multiple outgoing next-hop(s) are specified. A share is computed as a ratio of this number to the total under all next-hops(s)."; reference "RFC7424, section 5.4, RFC3031, section 3.11 and 3.12."; } leaf role { type nhlfe-role; description "NHLFE role."; } uses nhlfe-single-contents; } grouping interfaces-mpls { description "List of MPLS interfaces."; container interfaces { description "List of MPLS enabled interaces."; list interface { key "name"; description "MPLS enabled interface entry."; leaf name { type if:interface-ref; description "A reference to the name of a interface in the system that is to be enabled for MPLS."; } leaf mpls-enabled { type boolean; default "false"; description "'true' if mpls encapsulation is enabled on the interface. 'false' if mpls encapsulation is disabled on the interface."; Saad, et al. Expires April 29, 2021 [Page 14] Internet-Draft MPLS Base YANG Data Model October 2020 } leaf maximum-labeled-packet { type uint32; units "octets"; description "Maximum labeled packet size."; reference "RFC3032, section 3.2."; } } } } grouping globals { description "MPLS global configuration grouping."; leaf ttl-propagate { type boolean; default "true"; description "Propagate TTL between IP and MPLS."; } } grouping label-blocks { description "Label-block allocation grouping."; container mpls-label-blocks { description "Label-block allocation container."; list mpls-label-block { key "index"; description "List of MPLS label-blocks."; leaf index { type string; description "A user-specified identifier utilised to uniquely reference an MPLS label block."; } leaf start-label { type rt-types:mpls-label; must '. <= ../end-label' { error-message "The start-label must be less than or equal " + "to end-label"; } description Saad, et al. Expires April 29, 2021 [Page 15] Internet-Draft MPLS Base YANG Data Model October 2020 "Label-block start."; } leaf end-label { type rt-types:mpls-label; must '. >= ../start-label' { error-message "The end-label must be greater than or equal " + "to start-label"; } description "Label-block end."; } leaf block-allocation-mode { type identityref { base label-block-alloc-mode; } description "Label-block allocation mode."; } leaf inuse-labels-count { when "derived-from-or-self(../block-allocation-mode, " + "'mpls:label-block-alloc-mode-manager')"; type yang:gauge32; config false; description "Label-block inuse labels count."; } } } } grouping rib-mpls-properties { description "A grouping of native MPLS RIB properties."; leaf destination-prefix { type leafref { path "../mpls-local-label"; } description "MPLS destination prefix."; } leaf route-context { type string; description "A context associated with the native MPLS route."; } } Saad, et al. Expires April 29, 2021 [Page 16] Internet-Draft MPLS Base YANG Data Model October 2020 grouping rib-active-route-mpls-input { description "A grouping applicable to native MPLS RIB 'active-route' RPC input augmentation."; leaf destination-address { type leafref { path "../mpls-local-label"; } description "MPLS native active route destination."; } leaf mpls-local-label { type rt-types:mpls-label; description "MPLS local label."; } } augment "/rt:routing" { description "MPLS augmentation."; container mpls { description "MPLS container, to be used as an augmentation target node other MPLS sub-features config, e.g. MPLS static LSP, MPLS LDP LSPs, and Trafic Engineering MPLS LSP Tunnels, etc."; uses globals; uses label-blocks; uses interfaces-mpls; } } /* MPLS routes augmentation */ augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { description "This augmentation is applicable to all MPLS routes."; leaf mpls-enabled { type boolean; default "false"; description "Indicates whether MPLS is enabled for this route."; } leaf mpls-local-label { when "../mpls-enabled = 'true'"; type rt-types:mpls-label; description "MPLS local label associated with the route."; Saad, et al. Expires April 29, 2021 [Page 17] Internet-Draft MPLS Base YANG Data Model October 2020 } uses rib-mpls-properties { /* MPLS AF augmentation to native MPLS RIB */ when "derived-from-or-self(../../rt:address-family, " + "'mpls:mpls')" { description "This augment is valid only for routes of native MPLS RIB."; } } } /* MPLS simple-next-hop augmentation */ augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { description "Augment 'simple-next-hop' case in IP unicast routes."; uses nhlfe-single-contents { when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" + "/mpls:mpls-enabled = 'true'"; } } /* MPLS next-hop-list augmentation */ augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop-list/rt:next-hop" { description "This leaf augments the 'next-hop-list' case of IP unicast routes."; uses nhlfe-multiple-contents { when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" + "/mpls:mpls-enabled = 'true'"; } } /* MPLS RPC input augmentation */ augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { description "Input MPLS augmentation for the 'active-route' action statement."; uses rib-active-route-mpls-input { /* MPLS AF augmentation to native MPLS RIB */ when "derived-from-or-self(../rt:address-family, " + "'mpls:mpls')" { Saad, et al. Expires April 29, 2021 [Page 18] Internet-Draft MPLS Base YANG Data Model October 2020 description "This augment is valid only for routes of native MPLS RIB."; } } } /* MPLS RPC output augmentation */ augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" + "rt:output/rt:route/" + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { description "Output MPLS augmentation for the 'active-route' action statement."; uses nhlfe-single-contents; } augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" + "rt:output/rt:route/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop-list/rt:next-hop" { description "Output MPLS augmentation for the 'active-route' action statement."; uses nhlfe-multiple-contents; } } Figure 4: MPLS base YANG module. 3. IANA Considerations This document registers the following URIs in the 'ns' sub-registry of the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-mpls Registrant Contact: The MPLS WG of the IETF. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. Saad, et al. Expires April 29, 2021 [Page 19] Internet-Draft MPLS Base YANG Data Model October 2020 name: ietf-mpls namespace: urn:ietf:params:xml:ns:yang:ietf-mpls prefix: mpls // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFCXXXX 4. Security Considerations The YANG module specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: "/rt:routing/mpls:mpls/mpls:label-blocks": there are data nodes under this path that are writeable such as 'start-label' and 'end-label'. Write operations to those data npdes may cause disruptive action to existing traffic. Some of the readable data nodes in these YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next- hop-options/rt:next-hop-list/rt:next-hop-list/rt:next-hop" and "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route/ rt:next-hop/rt:next-hop-options/rt:simple-next-hop": these two paths are augmented by additional MPLS leaf(s) defined in this model. Access to this information may disclose the next-hop or path per prefix and/or other information. Saad, et al. Expires April 29, 2021 [Page 20] Internet-Draft MPLS Base YANG Data Model October 2020 Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" and "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route": these two paths are augmented by additional MPLS data node(s) that are defined in this model. Access to those path(s) may may disclose information about per prefix route and/or other information and that may be further used for further attack(s). The security considerations spelled out in [RFC3031] and [RFC3032] apply for this document as well. 5. Acknowledgement The authors would like to thank Xia Chen for her contributions to the early revisions of this document. 6. Appendix A. Data Tree Instance Example A simple network setup is shown in Figure 5. R1 runs the ISIS routing protocol, and learns reachability about two IPv4 prefixes: P1: 198.51.100.1/32 and P2: 198.51.100.1/32, and two IPv6 prefixes P3: 2001:db8:0:10::1/64 and P4: 2001:db8:0:10::1/64. We also assume that R1 learns about local and remote MPLS label bindings for each prefix using ISIS (e.g. using Segment-Routing (SR) extensions). Saad, et al. Expires April 29, 2021 [Page 21] Internet-Draft MPLS Base YANG Data Model October 2020 State on R1: ============ IPv4 Prefix MPLS Label P1: 198.51.100.1/32 16001 P2: 198.51.100.2/32 16002 IPv6 Prefix MPLS Label P3: 2001:db8:0:10::1/64 16003 P4: 2001:db8:0:10::2/64 16004 RSVP MPLS LSPv4-Tunnel: Source: 198.51.100.3 Destination: 198.51.100.4 Tunnel-ID: 10 LSP-ID: 1 192.0.2.5/30 2001:db8:0:1::1/64 eth0 +--- / +-----+ | R1 | +-----+ \ +--- eth1 192.0.2.13/30 2001:db8:0:2::1/64 Figure 5: Example of network configuration. The instance data tree could then be as follows: { "ietf-routing:routing":{ "ribs":{ "rib":[ { "name":"RIB-V4", "address-family": "ietf-ipv4-unicast-routing:v4ur:ipv4-unicast", "routes":{ "route":[ { "next-hop":{ "outgoing-interface":"eth0", "ietf-mpls:mpls-label-stack":{ Saad, et al. Expires April 29, 2021 [Page 22] Internet-Draft MPLS Base YANG Data Model October 2020 "entry":[ { "id":1, "label":16001, "ttl":255 } ] }, "ietf-ipv4-unicast-routing:next-hop-address": "192.0.2.5" }, "source-protocol":"isis:isis", "ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-local-label":16001, "ietf-ipv4-unicast-routing:destination-prefix": "198.51.100.1/32", "ietf-mpls:route-context":"SID-IDX:1" }, { "next-hop":{ "next-hop-list":{ "next-hop":[ { "outgoing-interface":"eth0", "ietf-mpls:index":"1", "ietf-mpls:backup-index":"2", "ietf-mpls:role":"primary-and-backup", "ietf-mpls:mpls-label-stack":{ "entry":[ { "id":1, "label":16002, "ttl":255 } ] }, "ietf-ipv4-unicast-routing:address":"192.0.2.5" }, { "outgoing-interface":"eth1", "ietf-mpls:index":"2", "ietf-mpls:backup-index":"1", "ietf-mpls:role":"primary-and-backup", "ietf-mpls:mpls-label-stack":{ "entry":[ { "id":1, "label":16002, Saad, et al. Expires April 29, 2021 [Page 23] Internet-Draft MPLS Base YANG Data Model October 2020 "ttl":255 } ] }, "ietf-ipv4-unicast-routing:address":"192.0.2.13" } ] } }, "source-protocol":"isis:isis", "ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-local-label":16002, "ietf-ipv4-unicast-routing:destination-prefix": "198.51.100.2/32", "ietf-mpls:route-context":"SID-IDX:2" } ] } }, { "name":"RIB-V6", "address-family": "ietf-ipv6-unicast-routing:v6ur:ipv6-unicast", "routes":{ "route":[ { "next-hop":{ "outgoing-interface":"eth0", "ietf-mpls:mpls-label-stack":{ "entry":[ { "id":1, "label":16003, "ttl":255 } ] }, "ietf-ipv6-unicast-routing:next-hop-address": "2001:db8:0:1::1" }, "source-protocol":"isis:isis", "ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-local-label":16001, "ietf-ipv6-unicast-routing:destination-prefix": "2001:db8:0:10::1/6", "ietf-mpls:route-context":"SID-IDX:1" }, { Saad, et al. Expires April 29, 2021 [Page 24] Internet-Draft MPLS Base YANG Data Model October 2020 "next-hop":{ "next-hop-list":{ "next-hop":[ { "outgoing-interface":"eth0", "ietf-mpls:index":"1", "ietf-mpls:backup-index":"2", "ietf-mpls:role":"primary-and-backup", "ietf-mpls:mpls-label-stack":{ "entry":[ { "id":1, "label":16004, "ttl":255 } ] }, "ietf-ipv6-unicast-routing:address": "2001:db8:0:1::1" }, { "outgoing-interface":"eth1", "ietf-mpls:index":"2", "ietf-mpls:backup-index":"1", "ietf-mpls:role":"primary-and-backup", "ietf-mpls:mpls-label-stack":{ "entry":[ { "id":1, "label":16004, "ttl":255 } ] }, "ietf-ipv6-unicast-routing:address": "2001:db8:0:2::1" } ] } }, "source-protocol":"isis:isis", "ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-local-label":16004, "ietf-ipv6-unicast-routing:destination-prefix": "2001:db8:0:10::2/64", "ietf-mpls:route-context":"SID-IDX:2" } ] Saad, et al. Expires April 29, 2021 [Page 25] Internet-Draft MPLS Base YANG Data Model October 2020 } }, { "name":"RIB-MPLS", "address-family":"ietf-mpls:mpls:mpls", "routes":{ "route":[ { "next-hop":{ "outgoing-interface":"eth0", "ietf-mpls:mpls-label-stack":{ "entry":[ { "id":1, "label":24002, "ttl":255 } ] }, "ietf-ipv4-unicast-routing:next-hop-address": "192.0.2.5" }, "source-protocol":"rsvp:rsvp", "ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-local-label":24001, "ietf-mpls:destination-prefix":"24001", "ietf-mpls:route-context": "RSVP Src:198.51.100.3,Dst:198.51.100.4,T:10,L:1" } } } } ] }, "ietf-mpls:mpls":{ "mpls-label-blocks":{ "mpls-label-block":[ { "index":"mpls-srgb-label-block", "start-label":16000, "end-label":16500, "block-allocation-mode":"mpls:label-block-alloc-mode-manager" } ] }, "interfaces":{ "interface":[ { Saad, et al. Expires April 29, 2021 [Page 26] Internet-Draft MPLS Base YANG Data Model October 2020 "name":"eth0", "mpls-enabled":true, "maximum-labeled-packet":1488 }, { "name":"eth1", "mpls-enabled":true, "maximum-labeled-packet":1488 } ] } } } } Figure 6: Foo bar. 7. Contributors Igor Bryskin Huawei Technologies email: i_bryskin@yahoo.com Himanshu Shah Ciena email: hshah@ciena.com 8. References 8.1. Normative References [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Saad, et al. Expires April 29, 2021 [Page 27] Internet-Draft MPLS Base YANG Data Model October 2020 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . Saad, et al. Expires April 29, 2021 [Page 28] Internet-Draft MPLS Base YANG Data Model October 2020 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 8.2. Informative References [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B. Khasnabish, "Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424, January 2015, . Authors' Addresses Tarek Saad Juniper Networks Email: tsaad@juniper.net Kamran Raza Cisco Systems Inc Email: skraza@cisco.com Rakesh Gandhi Cisco Systems Inc Email: rgandhi@cisco.com Xufeng Liu Volta Networks Email: xufeng.liu.ietf@gmail.com Saad, et al. Expires April 29, 2021 [Page 29] Internet-Draft MPLS Base YANG Data Model October 2020 Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net Saad, et al. Expires April 29, 2021 [Page 30] ./draft-ietf-mpls-ldp-yang-09.txt0000644000764400076440000053132413635234461016064 0ustar iustyiustyMPLS Working Group K. Raza, Ed. Internet-Draft R. Asati Intended status: Standards Track Cisco Systems Expires: September 21, 2020 X. Liu Volta Networks S. Esale Juniper Networks X. Chen Huawei Technologies H. Shah Ciena Corporation March 20, 2020 YANG Data Model for MPLS LDP draft-ietf-mpls-ldp-yang-09 Abstract This document describes a YANG data model for Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define Multipoint LDP (mLDP) model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 21, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Raza, et al. Expires September 21, 2020 [Page 1] Internet-Draft YANG Data Model for MPLS LDP March 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 1.1. Base and Extended . . . . . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Complete Tree . . . . . . . . . . . . . . . . . . . . . . 7 5. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Configuration Hierarchy . . . . . . . . . . . . . . . . . 19 5.1.1. Global parameters . . . . . . . . . . . . . . . . . . 20 5.1.2. Capabilities parameters . . . . . . . . . . . . . . . 20 5.1.3. Per-Address-Family parameters . . . . . . . . . . . . 20 5.1.4. Hello Discovery parameters . . . . . . . . . . . . . 20 5.1.5. Peer parameters . . . . . . . . . . . . . . . . . . . 21 5.1.6. Forwarding parameters . . . . . . . . . . . . . . . . 21 6. Operational State . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Adjacency state . . . . . . . . . . . . . . . . . . . . . 22 6.2. Peer state . . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Bindings state . . . . . . . . . . . . . . . . . . . . . 24 6.4. Capabilities state . . . . . . . . . . . . . . . . . . . 26 7. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. YANG Specification . . . . . . . . . . . . . . . . . . . . . 27 9.1. Base . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Extended . . . . . . . . . . . . . . . . . . . . . . . . 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 80 10.1. YANG model . . . . . . . . . . . . . . . . . . . . . . . 80 10.1.1. Writable nodes . . . . . . . . . . . . . . . . . . . 81 10.1.2. Readable nodes . . . . . . . . . . . . . . . . . . . 81 10.1.3. RPC operations . . . . . . . . . . . . . . . . . . . 82 10.1.4. Notifications . . . . . . . . . . . . . . . . . . . 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 84 14. Normative References . . . . . . . . . . . . . . . . . . . . 84 15. Informative References . . . . . . . . . . . . . . . . . . . 87 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 Raza, et al. Expires September 21, 2020 [Page 2] Internet-Draft YANG Data Model for MPLS LDP March 2020 1. Introduction The Network Configuration Protocol (NETCONF) [RFC6241] is one of the network management protocols that defines mechanisms to manage network devices. YANG [RFC6020] [RFC7950] is a modular language that represents data structures in an XML tree format, and is used as a data modelling language for the NETCONF. This document introduces a YANG data model for MPLS Label Distribution Protocol (LDP) [RFC5036]. This model also covers LDP IPv6 [RFC7552] and LDP capabilities [RFC5561] specifications. The data model is defined for the following constructs that are used for managing the protocol: * Configuration * Operational State * Executables (Actions) * Notifications This document is organized to define the data model for each of the above constructs in the sequence as listed above. 1.1. Base and Extended The configuration and state items are divided into the following two broad categories: * Base * Extended The "base" category contains the basic and fundamental features that are covered in LDP base specification [RFC5036] and constitute the minimum requirements for a typical base LDP deployment. Whereas, the "extended" category contains other non-base features. All the items in a base category are mandatory and hence no "if-feature" is allowed under the "base" category. The base and extended categories are defined in their own modules as described later. The example of base feature includes the configuration of LDP lsr-id, enabling LDP interfaces, setting password for LDP session etc., whereas the examples of extended feature include inbound/outbound label policies, igp sync [RFC5443], downstream-on-demand etc. It is Raza, et al. Expires September 21, 2020 [Page 3] Internet-Draft YANG Data Model for MPLS LDP March 2020 worth highlighting that LDP IPv6 [RFC7552] is also categorized as an extended feature. While "base" model support will suffice for small deployments, it is expected that large deployments will require both the "base" and "extended" models support from the vendors. 2. Specification of Requirements In this document, the word "IP" is used to refer to both IPv4 and IPv6, unless otherwise explicitly stated. For example, "IP address family" should be read as "IPv4 and/or IPv6 address family". 3. Overview This document defines two new modules for LDP YANG support: * "ietf-mpls-ldp" module that specifies the base LDP features and augments /rt:routing/rt:control-plane-protocols/rt:control-plane- protocol defined in [RFC8349]. We define new identity 'mpls-ldp' for LDP and the model allows only a single instance of 'mpls-ldp'. * "ietf-mpls-ldp-extended" module that specifies the extended LDP features and augments the base LDP module. It is to be noted that mLDP YANG model [I-D.ietf-mpls-mldp-yang] augments LDP base and extended modules to specify the mLDP specific base and extended features. There are four types of containers in our module(s): * Read-Write parameters for configuration (Section 5) * Read-only parameters for operational state (Section 6) * Notifications for events (Section 7) * RPCs for executing commands to perform some action (Section 8) The modules in this document conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407]. When protocol states are retrieved from the NMDA operational state datastore, the returned states cover all "config true" (rw) and "config false" (ro) nodes defined in the schema. Raza, et al. Expires September 21, 2020 [Page 4] Internet-Draft YANG Data Model for MPLS LDP March 2020 Following diagram depicts high level LDP YANG tree organization and hierarchy: +-- rw routing +-- rw control-plane-protocols +-- rw control-plane-protocol +-- rw mpls-ldp +-- rw ... +-- rw ... // base | +-- rw ... | +-- ro ... | +-- +-- ro ... | +-- ro ... | +-- ro ... | +-- +-- rw ldp-ext: .... // extended | +-- rw ... | +-- ro ... | +-- +-- ro ... +-- ro ... +-- ro ... rpcs: +-- x mpls-ldp-some_action +-- x . . . . . notifications: +--- n mpls-ldp-some_event +--- n ... Figure 1: LDP YANG tree organization Before going into data model details, it is important to take note of the following points: * This model aims to address only the core LDP parameters as per RFC specification, as well as well-known and widely deployed manageability controls (such as label filtering policies to apply filtering rules on the assignment, advertisement, and acceptance for label bindings). Any vendor specific feature should be defined in a vendor-specific augmentation of this model. * Multi-topology LDP [RFC7307] is beyond the scope of this document. Raza, et al. Expires September 21, 2020 [Page 5] Internet-Draft YANG Data Model for MPLS LDP March 2020 * This model does not cover any applications running on top of LDP, nor does it cover any OAM procedures for LDP. * This model is a VPN Routing and Forwarding (VRF)-centric model. It is important to note that [RFC4364] defines VRF tables and default forwarding tables as different, however from a YANG modelling perspective this introduces unnecessary complications, hence we are treating the default forwarding table as just another VRF. * A "network-instance", as defined in [RFC8529], refers to a VRF instance (both default and non-default) within the scope of this model. * This model supports two address-families, namely "ipv4" and "ipv6". * This model assumes platform-wide label space (i.e. label space Id of zero). However, when Upstream Label assignment [RFC6389] is in use, an upstream assigned label is looked up in a Context-Specific label space as defined in [RFC5331]. * The label and peer policies (including filters) are defined using prefix-set and neighbor-set respectively as defined in routing- policy model [I-D.ietf-rtgwg-policy-model]. * This model uses the terms LDP "neighbor"/"adjacency", "session", and "peer" with the following semantics: - Neighbor/Adjacency: An LDP enabled LSR that is discovered through LDP discovery mechanisms. - Session: An LDP neighbor with whom a TCP connection has been established. - Peer: An LDP session which has successfully progressed beyond its initialization phase and is either already exchanging the bindings or is ready to do so. It is to be noted that LDP Graceful Restart (GR) mechanisms defined in [RFC3478] allow keeping the exchanged bindings for some time after a session goes down with a peer. We call such a state belonging to a "stale" peer -- i.e. keeping peer bindings from a peer with whom currently there is either no connection established or connection is established but GR session is in recovery state. When used in this document, the above terms will refer strictly to the semantics and definitions defined for them. Raza, et al. Expires September 21, 2020 [Page 6] Internet-Draft YANG Data Model for MPLS LDP March 2020 A simplified graphical tree representation of base and extended LDP YANG data model is presented in Figure 2. The meaning of the symbols in these tree diagrams is defined in [RFC8340]. The actual YANG specification for base and extended modules is captured in Section 9. While presenting the YANG tree view and actual specification, this document assumes readers' familiarity with the concepts of YANG modeling, its presentation and its compilation. 4. The Complete Tree Following is a complete tree representation of configuration, state, notification, and RPC items under LDP base and extended modules. module: ietf-mpls-ldp augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw mpls-ldp +--rw global | +--rw capability | | +--rw ldp-ext:end-of-lib {capability-end-of-lib}? | | | +--rw ldp-ext:enabled? boolean | | +--rw ldp-ext:typed-wildcard-fec | | | {capability-typed-wildcard-fec}? | | | +--rw ldp-ext:enabled? boolean | | +--rw ldp-ext:upstream-label-assignment | | {capability-upstream-label-assignment}? | | +--rw ldp-ext:enabled? boolean | +--rw graceful-restart | | +--rw enabled? boolean | | +--rw reconnect-time? uint16 | | +--rw recovery-time? uint16 | | +--rw forwarding-holdtime? uint16 | | +--rw ldp-ext:helper-enabled? boolean | | {graceful-restart-helper-mode}? | +--rw lsr-id? | | rt-types:router-id | +--rw address-families | | +--rw ipv4! | | | +--rw enabled? boolean | | | +--ro label-distribution-control-mode? enumeration | | | +--ro bindings | | | | +--ro address* [address] | | | | | +--ro address inet:ipv4-address | | | | | +--ro advertisement-type? advertised-received | | | | | +--ro peer Raza, et al. Expires September 21, 2020 [Page 7] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | | | | +--ro lsr-id? leafref | | | | | +--ro label-space-id? leafref | | | | +--ro fec-label* [fec] | | | | +--ro fec inet:ipv4-prefix | | | | +--ro peer* | | | | [lsr-id label-space-id advertisement-type] | | | | +--ro lsr-id leafref | | | | +--ro label-space-id leafref | | | | +--ro advertisement-type | | | | | advertised-received | | | | +--ro label? | | | | | rt-types:mpls-label | | | | +--ro used-in-forwarding? boolean | | | +--rw ldp-ext:label-policy | | | | +--rw ldp-ext:advertise | | | | | +--rw ldp-ext:egress-explicit-null | | | | | | +--rw ldp-ext:enabled? boolean | | | | | +--rw ldp-ext:prefix-list? | | | | | prefix-list-ref | | | | +--rw ldp-ext:accept | | | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | | | +--rw ldp-ext:assign | | | | {policy-label-assignment-config}? | | | | +--rw ldp-ext:independent-mode | | | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | | | +--rw ldp-ext:ordered-mode | | | | {policy-ordered-label-config}? | | | | +--rw ldp-ext:egress-prefix-list? | | | | prefix-list-ref | | | +--rw ldp-ext:transport-address? | | | inet:ipv4-address | | +--rw ldp-ext:ipv6! | | +--rw ldp-ext:enabled? | | | boolean | | +--rw ldp-ext:label-policy | | | +--rw ldp-ext:advertise | | | | +--rw ldp-ext:egress-explicit-null | | | | | +--rw ldp-ext:enabled? boolean | | | | +--rw ldp-ext:prefix-list? | | | | prefix-list-ref | | | +--rw ldp-ext:accept | | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | | +--rw ldp-ext:assign | | | {policy-label-assignment-config}? | | | +--rw ldp-ext:independent-mode | | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | | +--rw ldp-ext:ordered-mode | | | {policy-ordered-label-config}? Raza, et al. Expires September 21, 2020 [Page 8] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | | +--rw ldp-ext:egress-prefix-list? | | | prefix-list-ref | | +--rw ldp-ext:transport-address | | | inet:ipv6-address | | +--ro ldp-ext:label-distribution-control-mode? | | | enumeration | | +--ro ldp-ext:bindings | | +--ro ldp-ext:address* [address] | | | +--ro ldp-ext:address | | | | inet:ipv6-address | | | +--ro ldp-ext:advertisement-type? | | | | advertised-received | | | +--ro ldp-ext:peer | | | +--ro ldp-ext:lsr-id? leafref | | | +--ro ldp-ext:label-space-id? leafref | | +--ro ldp-ext:fec-label* [fec] | | +--ro ldp-ext:fec inet:ipv6-prefix | | +--ro ldp-ext:peer* | | [lsr-id label-space-id advertisement-type] | | +--ro ldp-ext:lsr-id leafref | | +--ro ldp-ext:label-space-id leafref | | +--ro ldp-ext:advertisement-type | | | advertised-received | | +--ro ldp-ext:label? | | | rt-types:mpls-label | | +--ro ldp-ext:used-in-forwarding? boolean | +--rw ldp-ext:forwarding-nexthop | | {forwarding-nexthop-config}? | | +--rw ldp-ext:interfaces | | +--rw ldp-ext:interface* [name] | | +--rw ldp-ext:name if:interface-ref | | +--rw ldp-ext:address-family* [afi] | | +--rw ldp-ext:afi identityref | | +--rw ldp-ext:ldp-disable? boolean | +--rw ldp-ext:igp-synchronization-delay? uint16 +--rw discovery | +--rw interfaces | | +--rw hello-holdtime? uint16 | | +--rw hello-interval? uint16 | | +--rw interface* [name] | | +--rw name | | | if:interface-ref | | +--ro next-hello? uint16 | | +--rw address-families | | | +--rw ipv4! | | | | +--rw enabled? boolean | | | | +--ro hello-adjacencies | | | | | +--ro hello-adjacency* [adjacent-address] Raza, et al. Expires September 21, 2020 [Page 9] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | | | | +--ro adjacent-address | | | | | | inet:ipv4-address | | | | | +--ro flag* identityref | | | | | +--ro hello-holdtime | | | | | | +--ro adjacent? uint16 | | | | | | +--ro negotiated? uint16 | | | | | | +--ro remaining? uint16 | | | | | +--ro next-hello? uint16 | | | | | +--ro statistics | | | | | | +--ro discontinuity-time | | | | | | | yang:date-and-time | | | | | | +--ro hello-received? | | | | | | | yang:counter64 | | | | | | +--ro hello-dropped? | | | | | | yang:counter64 | | | | | +--ro peer | | | | | +--ro lsr-id? leafref | | | | | +--ro label-space-id? leafref | | | | +--rw ldp-ext:transport-address? union | | | +--rw ldp-ext:ipv6! | | | +--rw ldp-ext:enabled? boolean | | | +--ro ldp-ext:hello-adjacencies | | | | +--ro ldp-ext:hello-adjacency* | | | | [adjacent-address] | | | | +--ro ldp-ext:adjacent-address | | | | | inet:ipv6-address | | | | +--ro ldp-ext:flag* | | | | | identityref | | | | +--ro ldp-ext:hello-holdtime | | | | | +--ro ldp-ext:adjacent? uint16 | | | | | +--ro ldp-ext:negotiated? uint16 | | | | | +--ro ldp-ext:remaining? uint16 | | | | +--ro ldp-ext:next-hello? uint16 | | | | +--ro ldp-ext:statistics | | | | | +--ro ldp-ext:discontinuity-time | | | | | | yang:date-and-time | | | | | +--ro ldp-ext:hello-received? | | | | | | yang:counter64 | | | | | +--ro ldp-ext:hello-dropped? | | | | | yang:counter64 | | | | +--ro ldp-ext:peer | | | | +--ro ldp-ext:lsr-id? leafref | | | | +--ro ldp-ext:label-space-id? leafref | | | +--rw ldp-ext:transport-address? union | | +--rw ldp-ext:hello-holdtime? uint16 | | | {per-interface-timer-config}? | | +--rw ldp-ext:hello-interval? uint16 | | | {per-interface-timer-config}? Raza, et al. Expires September 21, 2020 [Page 10] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | +--rw ldp-ext:igp-synchronization-delay? uint16 | | {per-interface-timer-config}? | +--rw targeted | +--rw hello-holdtime? uint16 | +--rw hello-interval? uint16 | +--rw hello-accept | | +--rw enabled? boolean | | +--rw ldp-ext:neighbor-list? neighbor-list-ref | | {policy-targeted-discovery-config}? | +--rw address-families | +--rw ipv4! | | +--ro hello-adjacencies | | | +--ro hello-adjacency* | | | [local-address adjacent-address] | | | +--ro local-address inet:ipv4-address | | | +--ro adjacent-address inet:ipv4-address | | | +--ro flag* identityref | | | +--ro hello-holdtime | | | | +--ro adjacent? uint16 | | | | +--ro negotiated? uint16 | | | | +--ro remaining? uint16 | | | +--ro next-hello? uint16 | | | +--ro statistics | | | | +--ro discontinuity-time | | | | | yang:date-and-time | | | | +--ro hello-received? | | | | | yang:counter64 | | | | +--ro hello-dropped? | | | | yang:counter64 | | | +--ro peer | | | +--ro lsr-id? leafref | | | +--ro label-space-id? leafref | | +--rw target* [adjacent-address] | | +--rw adjacent-address inet:ipv4-address | | +--rw enabled? boolean | | +--rw local-address? inet:ipv4-address | +--rw ldp-ext:ipv6! | +--ro ldp-ext:hello-adjacencies | | +--ro ldp-ext:hello-adjacency* | | [local-address adjacent-address] | | +--ro ldp-ext:local-address | | | inet:ipv6-address | | +--ro ldp-ext:adjacent-address | | | inet:ipv6-address | | +--ro ldp-ext:flag* | | | identityref | | +--ro ldp-ext:hello-holdtime | | | +--ro ldp-ext:adjacent? uint16 Raza, et al. Expires September 21, 2020 [Page 11] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | | +--ro ldp-ext:negotiated? uint16 | | | +--ro ldp-ext:remaining? uint16 | | +--ro ldp-ext:next-hello? uint16 | | +--ro ldp-ext:statistics | | | +--ro ldp-ext:discontinuity-time | | | | yang:date-and-time | | | +--ro ldp-ext:hello-received? | | | | yang:counter64 | | | +--ro ldp-ext:hello-dropped? | | | yang:counter64 | | +--ro ldp-ext:peer | | +--ro ldp-ext:lsr-id? leafref | | +--ro ldp-ext:label-space-id? leafref | +--rw ldp-ext:target* [adjacent-address] | +--rw ldp-ext:adjacent-address | | inet:ipv6-address | +--rw ldp-ext:enabled? boolean | +--rw ldp-ext:local-address? | inet:ipv6-address +--rw peers +--rw authentication | +--rw (authentication-type)? | +--:(password) | | +--rw key? string | | +--rw crypto-algorithm? identityref | +--:(ldp-ext:key-chain) {key-chain}? | +--rw ldp-ext:key-chain? key-chain:key-chain-ref +--rw session-ka-holdtime? uint16 +--rw session-ka-interval? uint16 +--rw peer* [lsr-id label-space-id] | +--rw lsr-id rt-types:router-id | +--rw label-space-id uint16 | +--rw authentication | | +--rw (authentication-type)? | | +--:(password) | | | +--rw key? string | | | +--rw crypto-algorithm? identityref | | +--:(ldp-ext:key-chain) {key-chain}? | | +--rw ldp-ext:key-chain? | | key-chain:key-chain-ref | +--rw address-families | | +--rw ipv4! | | | +--ro hello-adjacencies | | | | +--ro hello-adjacency* | | | | [local-address adjacent-address] | | | | +--ro local-address inet:ipv4-address | | | | +--ro adjacent-address inet:ipv4-address | | | | +--ro flag* identityref Raza, et al. Expires September 21, 2020 [Page 12] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | | | +--ro hello-holdtime | | | | | +--ro adjacent? uint16 | | | | | +--ro negotiated? uint16 | | | | | +--ro remaining? uint16 | | | | +--ro next-hello? uint16 | | | | +--ro statistics | | | | | +--ro discontinuity-time | | | | | | yang:date-and-time | | | | | +--ro hello-received? | | | | | | yang:counter64 | | | | | +--ro hello-dropped? | | | | | yang:counter64 | | | | +--ro interface? if:interface-ref | | | +--rw ldp-ext:label-policy | | | +--rw ldp-ext:advertise | | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | | +--rw ldp-ext:accept | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | +--rw ldp-ext:ipv6! | | +--ro ldp-ext:hello-adjacencies | | | +--ro ldp-ext:hello-adjacency* | | | [local-address adjacent-address] | | | +--ro ldp-ext:local-address | | | | inet:ipv6-address | | | +--ro ldp-ext:adjacent-address | | | | inet:ipv6-address | | | +--ro ldp-ext:flag* | | | | identityref | | | +--ro ldp-ext:hello-holdtime | | | | +--ro ldp-ext:adjacent? uint16 | | | | +--ro ldp-ext:negotiated? uint16 | | | | +--ro ldp-ext:remaining? uint16 | | | +--ro ldp-ext:next-hello? uint16 | | | +--ro ldp-ext:statistics | | | | +--ro ldp-ext:discontinuity-time | | | | | yang:date-and-time | | | | +--ro ldp-ext:hello-received? | | | | | yang:counter64 | | | | +--ro ldp-ext:hello-dropped? | | | | yang:counter64 | | | +--ro ldp-ext:interface? | | | if:interface-ref | | +--rw ldp-ext:label-policy | | +--rw ldp-ext:advertise | | | +--rw ldp-ext:prefix-list? prefix-list-ref | | +--rw ldp-ext:accept | | +--rw ldp-ext:prefix-list? prefix-list-ref | +--ro label-advertisement-mode Raza, et al. Expires September 21, 2020 [Page 13] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | +--ro local? label-adv-mode | | +--ro peer? label-adv-mode | | +--ro negotiated? label-adv-mode | +--ro next-keep-alive? uint16 | +--ro received-peer-state | | +--ro graceful-restart | | | +--ro enabled? boolean | | | +--ro reconnect-time? uint16 | | | +--ro recovery-time? uint16 | | +--ro capability | | +--ro end-of-lib | | | +--ro enabled? boolean | | +--ro typed-wildcard-fec | | | +--ro enabled? boolean | | +--ro upstream-label-assignment | | +--ro enabled? boolean | +--ro session-holdtime | | +--ro peer? uint16 | | +--ro negotiated? uint16 | | +--ro remaining? uint16 | +--ro session-state? enumeration | +--ro tcp-connection | | +--ro local-address? inet:ip-address | | +--ro local-port? inet:port-number | | +--ro remote-address? inet:ip-address | | +--ro remote-port? inet:port-number | +--ro up-time? | | rt-types:timeticks64 | +--ro statistics | | +--ro discontinuity-time yang:date-and-time | | +--ro received | | | +--ro total-octets? yang:counter64 | | | +--ro total-messages? yang:counter64 | | | +--ro address? yang:counter64 | | | +--ro address-withdraw? yang:counter64 | | | +--ro initialization? yang:counter64 | | | +--ro keepalive? yang:counter64 | | | +--ro label-abort-request? yang:counter64 | | | +--ro label-mapping? yang:counter64 | | | +--ro label-release? yang:counter64 | | | +--ro label-request? yang:counter64 | | | +--ro label-withdraw? yang:counter64 | | | +--ro notification? yang:counter64 | | +--ro sent | | | +--ro total-octets? yang:counter64 | | | +--ro total-messages? yang:counter64 | | | +--ro address? yang:counter64 | | | +--ro address-withdraw? yang:counter64 Raza, et al. Expires September 21, 2020 [Page 14] Internet-Draft YANG Data Model for MPLS LDP March 2020 | | | +--ro initialization? yang:counter64 | | | +--ro keepalive? yang:counter64 | | | +--ro label-abort-request? yang:counter64 | | | +--ro label-mapping? yang:counter64 | | | +--ro label-release? yang:counter64 | | | +--ro label-request? yang:counter64 | | | +--ro label-withdraw? yang:counter64 | | | +--ro notification? yang:counter64 | | +--ro total-addresses? uint32 | | +--ro total-labels? uint32 | | +--ro total-fec-label-bindings? uint32 | +--rw ldp-ext:admin-down? boolean | | {per-peer-admin-down}? | +--rw ldp-ext:graceful-restart | | {per-peer-graceful-restart-config}? | | +--rw ldp-ext:enabled? boolean | | +--rw ldp-ext:reconnect-time? uint16 | | +--rw ldp-ext:recovery-time? uint16 | +--rw ldp-ext:session-ka-holdtime? uint16 | | {per-peer-session-attributes-config}? | +--rw ldp-ext:session-ka-interval? uint16 | {per-peer-session-attributes-config}? +--rw ldp-ext:session-downstream-on-demand | {session-downstream-on-demand-config}? | +--rw ldp-ext:enabled? boolean | +--rw ldp-ext:peer-list? peer-list-ref +--rw ldp-ext:dual-stack-transport-preference {peers-dual-stack-transport-preference}? +--rw ldp-ext:max-wait? uint16 +--rw ldp-ext:prefer-ipv4! +--rw ldp-ext:peer-list? peer-list-ref rpcs: +---x mpls-ldp-clear-peer | +---w input | +---w protocol-name? leafref | +---w lsr-id? leafref | +---w label-space-id? leafref +---x mpls-ldp-clear-hello-adjacency | +---w input | +---w hello-adjacency | +---w protocol-name? leafref | +---w (hello-adjacency-type)? | +--:(targeted) | | +---w targeted! | | +---w target-address? inet:ip-address | +--:(link) | +---w link! Raza, et al. Expires September 21, 2020 [Page 15] Internet-Draft YANG Data Model for MPLS LDP March 2020 | +---w next-hop-interface? leafref | +---w next-hop-address? inet:ip-address +---x mpls-ldp-clear-peer-statistics +---w input +---w protocol-name? leafref +---w lsr-id? leafref +---w label-space-id? leafref notifications: +---n mpls-ldp-peer-event | +--ro event-type? oper-status-event-type | +--ro peer | +--ro protocol-name? leafref | +--ro lsr-id? leafref | +--ro label-space-id? leafref +---n mpls-ldp-hello-adjacency-event | +--ro event-type? oper-status-event-type | +--ro protocol-name? leafref | +--ro (hello-adjacency-type)? | +--:(targeted) | | +--ro targeted | | +--ro target-address? inet:ip-address | +--:(link) | +--ro link | +--ro next-hop-interface? if:interface-ref | +--ro next-hop-address? inet:ip-address +---n mpls-ldp-fec-event +--ro event-type? oper-status-event-type +--ro protocol-name? leafref +--ro fec? inet:ip-prefix Figure 2: Complete Tree 5. Configuration This specification defines the configuration parameters for base LDP as specified in [RFC5036] and LDP IPv6 [RFC7552]. Moreover, it incorporates provisions to enable LDP Capabilities [RFC5561], and defines some of the most significant and commonly used capabilities such as Typed Wildcard FEC [RFC5918], End-of-LIB [RFC5919], and LDP Upstream Label Assignment [RFC6389]. This model augments /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol that is defined in [RFC8349] and follows NMDA as mentioned earlier. Raza, et al. Expires September 21, 2020 [Page 16] Internet-Draft YANG Data Model for MPLS LDP March 2020 Following is the high-level configuration organization for base LDP module: augment /rt:routing/rt:control-plane-protocols: /rt:control-plane-protocol: +-- mpls-ldp +-- global | +-- ... | +-- ... | +-- address-families | | +-- ipv4 | | +-- . . . | | +-- . . . | +-- capability | +-- ... | +-- ... +-- discovery | +-- interfaces | | +-- ... | | +-- ... | | +-- interface* [interface] | | +-- ... | | +-- address-families | | +-- ipv4 | | +-- ... | | +-- ... | +-- targeted | +-- ... | +-- address-families | +-- ipv4 | +- target* [adjacent-address] | +- ... | +- ... +-- peers +-- ... +-- ... +-- peer* [lsr-id label-space-id] +-- ... +-- ... Figure 3: Base Configuration organization Following is the high-level configuration organization for extended LDP: Raza, et al. Expires September 21, 2020 [Page 17] Internet-Draft YANG Data Model for MPLS LDP March 2020 augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol +-- mpls-ldp +-- global | +-- ... | +-- ... | +-- address-families | | +-- ipv4 | | | +-- . . . | | | +-- . . . | | | +-- label-policy | | | +-- ... | | | +-- ... | | +-- ipv6 | | +-- . . . | | +-- . . . | | +-- label-policy | | +-- ... | | +-- ... | +-- capability | | +-- ... | | +-- ... | +-- discovery | +-- interfaces | | +-- ... | | +-- ... | | +-- interface* [interface] | | +-- ... | | +-- address-families | | +-- ipv4 | | | +-- ... | | | +-- ... | | +-- ipv6 | | +-- ... | | +-- ... | +-- targeteted | +-- ... | +-- address-families | +-- ipv6 | +- target* [adjacent-address] | +- ... | +- ... +-- forwarding-nexthop | +-- ... | +-- ... +-- peers +-- ... +-- ... +-- peer* Raza, et al. Expires September 21, 2020 [Page 18] Internet-Draft YANG Data Model for MPLS LDP March 2020 +-- ... +-- ... +-- label-policy | +-- .. +-- address-families +-- ipv4 | +-- ... +-- ipv6 +-- ... Figure 4: Extended Configuration organization Given the configuration hierarchy, the model allows inheritance such that an item in a child tree is able to derive value from a similar or related item in one of the parents. For instance, hello holdtime can be configured per-VRF or per-VRF-interface, thus allowing inheritance as well flexibility to override with a different value at any child level. 5.1. Configuration Hierarchy LDP module resides under a network-instance and the scope of any LDP configuration defined under this tree is per network-instance (per- VRF). This configuration is further divided into sub categories as follows. * Global parameters * Per-address-family parameters * LDP Capabilities parameters * Hello Discovery parameters - interfaces o Global o Per-interface: Global o Per-interface: Per-address-family - targeted o Global Raza, et al. Expires September 21, 2020 [Page 19] Internet-Draft YANG Data Model for MPLS LDP March 2020 o Per-address-family: Per-target * Peer parameters - Global - Per-peer: Global - Per-peer: Per-address-family * Forwarding parameters Following subsections briefly explain these configuration areas. 5.1.1. Global parameters There are configuration items that are available directly under a VRF instance and do not fall under any other sub tree. Example of such a parameter is LDP LSR Id that is typically configured per VRF. To keep legacy LDP features and applications working in an LDP IPv4 networks with this model, this document recommends an operator to pick a routable IPv4 unicast address (within a routing domain) as an LSR Id. 5.1.2. Capabilities parameters This container falls under the global tree and holds the LDP capabilities that are to be enabled for certain features. By default, an LDP capability is disabled unless explicitly enabled. These capabilities are typically used to negotiate with LDP peer(s) the support/non-support related to a feature and its parameters. The scope of a capability enabled under this container applies to all LDP peers in the given VRF instance. There is also a peer level capability container that is provided to override a capability that is enabled/specified at VRF level. 5.1.3. Per-Address-Family parameters Any LDP configuration parameter related to IP address family (AF) whose scope is VRF wide is configured under this tree. The examples of per-AF parameters include enabling LDP for an address family, prefix-list based label policies, and LDP transport address. 5.1.4. Hello Discovery parameters This container is used to hold LDP configuration related to Hello and discovery process for both basic (link) and extended (targeted) discovery. Raza, et al. Expires September 21, 2020 [Page 20] Internet-Draft YANG Data Model for MPLS LDP March 2020 The "interfaces" is a container to configure parameters related to VRF interfaces. There are parameters that apply to all interfaces (such as hello timers), as well as parameters that can be configured per-interface. Hence, an interface list is defined under "interfaces" container. The model defines parameters to configure per-interface non AF related items, as well as per-interface per-AF items. The example of the former is interface hello timers, and example of the latter is enabling hellos for a given AF under an interface. The "targeted" container under a VRF instance allows to configure LDP targeted discovery related parameters. Within this container, the "target" list provides a means to configure multiple target addresses to perform extended discovery to a specific destination target, as well as to fine-tune the per-target parameters. 5.1.5. Peer parameters This container is used to hold LDP configuration related to LDP sessions and peers under a VRF instance. This container allows to configure parameters that either apply on VRF's all peers or a subset (peer-list) of VRF peers. The example of such parameters include authentication password, session KA timers etc. Moreover, the model also allows per-peer parameter tuning by specifying a "peer" list under the "peers" container. A peer is uniquely identified by its LSR Id. Like per-interface parameters, some per-peer parameters are AF- agnostic (i.e. either non AF related or apply to both IP address families), and some that belong to an AF. The example of the former is per-peer session password configuration, whereas the example of the latter is prefix-list based label policies (inbound and outbound) that apply to a given peer. 5.1.6. Forwarding parameters This container is used to hold configuration used to control LDP forwarding behavior under a VRF instance. One example of a configuration under this container is when a user wishes to enable neighbor discovery on an interface but wishes to disable use of the same interface as forwarding nexthop. This example configuration makes sense only when there are more than one LDP enabled interfaces towards the neighbor. Raza, et al. Expires September 21, 2020 [Page 21] Internet-Draft YANG Data Model for MPLS LDP March 2020 6. Operational State Operational state of LDP can be queried and obtained from read-only state containers that fall under the same tree (/rt:routing/ rt:control-plane-protocols/rt:control-plane-protocol) as the configuration. Following are main areas for which LDP operational state is defined: * Neighbor Adjacencies * Peer * Bindings (FEC-label and address) * Capabilities 6.1. Adjacency state Neighbor adjacencies are per address-family hello adjacencies that are formed with neighbors as result of LDP basic or extended discovery. In terms of organization, there is a source of discovery (e.g. interface or target address) along with its associated parameters and one or more discovered neighbors along with neighbor discovery related parameters. For the basic discovery, there could be more than one discovered neighbor for a given source (interface), whereas there is at most one discovered neighbor for an extended discovery source (local-address and target-address). It is also to be noted that the reason for a targeted neighbor adjacency could be either an active source (locally configured targeted) or passive source (to allow any incoming extended/targeted hellos). A neighbor/ adjacency record also contains session-state that helps highlight whether a given adjacency has progressed to subsequent session level or to eventual peer level. Following captures high level tree hierarchy for neighbor adjacency state. The tree is shown for ipv4 address-family only; a similar tree exists for ipv6 address-family as well. Raza, et al. Expires September 21, 2020 [Page 22] Internet-Draft YANG Data Model for MPLS LDP March 2020 +--rw mpls-ldp! +--rw discovery +--rw interfaces | +--rw interface* [interface] | +--rw address-families | +--rw ipv4 | +--ro hello-adjacencies | +--ro hello-adjacencies* [adjacent-address] | +--ro adjacent-address | . . . . | . . . . +--rw targeted +--rw address-families +--rw ipv4 +--ro hello-adjacencies +--ro hello-adjacencies* | [local-address adjacent-address] +--ro local-address +--ro adjacent-address . . . . . . . . Figure 5: Adjacency state 6.2. Peer state Peer related state is presented under peers tree. This is one of the core state that provides info on the session related parameters (mode, authentication, KA timeout etc.), TCP connection info, hello adjacencies for the peer, statistics related to messages and bindings, and capabilities exchange info. Following captures high level tree hierarchy for peer state. The peer's hello adjacencies tree is shown for ipv4 address-family only; a similar tree exists for ipv6 address-family as well. Raza, et al. Expires September 21, 2020 [Page 23] Internet-Draft YANG Data Model for MPLS LDP March 2020 +--rw mpls-ldp! +--rw peers +--rw peer* [lsr-id label-space-id] +--rw lsr-id +--rw label-space-id +--ro label-advertisement-mode +--ro session-state +--ro tcp-connection +--ro session-holdtime? +--ro up-time +-- . . . . +--ro address-families | +--ro ipv4 | +--ro hello-adjacencies | +--ro hello-adjacencies* | [local-address adjacent-address] | . . . . | . . . . +--ro received-peer-state | +--ro . . . . | +--ro capability | +--ro . . . . +--ro statistics +-- . . . . +-- received | +-- ... +-- sent +-- ... Figure 6: Peer state 6.3. Bindings state Binding state provides information on LDP FEC-label bindings as well as address binding for both inbound (received) as well as outbound (advertised) direction. FEC-label bindings are presented as a FEC- centric view, and address bindings are presented as an address- centric view: Raza, et al. Expires September 21, 2020 [Page 24] Internet-Draft YANG Data Model for MPLS LDP March 2020 FEC-Label bindings: FEC 203.0.113.1/32: advertised: local-label 16000 peer 192.0.2.1:0 peer 192.0.2.2:0 peer 192.0.2.3:0 received: peer 192.0.2.1:0, label 16002, used-in-forwarding=Yes peer 192.0.2.2:0, label 17002, used-in-forwarding=No FEC 203.0.113.2/32: . . . . FEC 198.51.100.0/24: . . . . FEC 2001:db8:0:2:: . . . . FEC 2001:db8:0:3:: . . . . Address bindings: Addr 192.0.2.10: advertised Addr 2001:db8:0:10:: advertised Addr 192.0.2.1: received, peer 192.0.2.1:0 Addr 192.0.2.2: received, peer 192.0.2.2:0 Addr 192.0.2.3: received, peer 192.0.2.3:0 Addr 2001:db8:0:2:: received, peer 192.0.2.2:0 Addr 2001:db8:0:3:: received, peer 192.0.2.3:0 Figure 7: Example Bindings Note that all local addresses are advertised to all peers and hence no need to provide per-peer information for local address advertisement. Furthermore, note that it is easy to derive a peer- centric view for the bindings from the information already provided in this model. Following captures high level tree hierarchy for bindings state. The tree shown below is for ipv4 address-family only; a similar tree exists for ipv6 address-family as well. Raza, et al. Expires September 21, 2020 [Page 25] Internet-Draft YANG Data Model for MPLS LDP March 2020 +--rw mpls-ldp! +--rw global +--rw address-families +--rw ipv4 +--ro bindings +--ro address* [address] | +--ro address (ipv4-address or ipv6-address) | +--ro advertisement-type? advertised-received | +--ro peer? leafref +--ro fec-label* [fec] +--ro fec (ipv4-prefix or ipv6-prefix) +--ro peer* [peer advertisement-type] +--ro peer leafref +--ro advertisement-type? advertised-received +--ro label? mpls:mpls-label +--ro used-in-forwarding? boolean Figure 8: Bindings state 6.4. Capabilities state LDP capabilities state comprise two types of information - global information (such as timer etc.), and per-peer information. Following captures high level tree hierarchy for LDP capabilities state. +--rw mpls-ldp! +--rw peers +--rw peer* [lsr-id label-space-id] +--rw lsr-id yang:dotted-quad +--rw label-space-id +--ro received-peer-state +--ro capability +--ro . . . . +--ro . . . . Figure 9: Capabilities state Raza, et al. Expires September 21, 2020 [Page 26] Internet-Draft YANG Data Model for MPLS LDP March 2020 7. Notifications This model defines a list of notifications to inform client of important events detected during the protocol operation. These events include events related to changes in the operational state of an LDP peer, hello adjacency, and FEC etc. It is to be noted that an LDP FEC is treated as operational (up) as long as it has at least 1 NHLFE (Next Hop Label Forwarding Entry) with outgoing label. A simplified graphical representation of the data model for LDP notifications is shown in Figure 2. 8. Action This model defines a list of rpcs that allow performing an action or executing a command on the protocol. For example, it allows to clear (reset) LDP peers, hello-adjacencies, and statistics. The model makes an effort to provide different level of control so that a user is able to either clear all, or clear all for a given type, or clear a specific entity. A simplified graphical representation of the data model for LDP actions is shown in Figure 2. 9. YANG Specification Following sections specify the actual YANG (module) specification for LDP constructs defined earlier in the document. 9.1. Base This YANG module imports types defined in [RFC6991], [RFC8349], [RFC8294], [RFC8343], and [RFC8344]. file "ietf-mpls-ldp@2020-02-25.yang" // RFC Editor: replace the above date 2020-02-25 with the date of // publication and remove this note. module ietf-mpls-ldp { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-ldp"; prefix "ldp"; import ietf-inet-types { Raza, et al. Expires September 21, 2020 [Page 27] Internet-Draft YANG Data Model for MPLS LDP March 2020 prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-ip { prefix "ip"; reference "RFC 7277: A YANG Data Model for IP Management"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177: YANG Data Model for Key Chains"; } organization "IETF MPLS Working Group"; contact "WG Web: WG List: Editor: Kamran Raza Editor: Rajiv Asati Raza, et al. Expires September 21, 2020 [Page 28] Internet-Draft YANG Data Model for MPLS LDP March 2020 Editor: Xufeng Liu Editor: Santosh Esale Editor: Xia Chen Editor: Himanshu Shah "; description "This YANG module defines the essential components for the management of Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). It is also the base model to be augmented for Multipoint LDP (mLDP). Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Editor: replace XXXX with actual RFC number and remove // this note revision 2020-02-25 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for MPLS LDP."; // RFC Editor: replace XXXX with actual RFC number and remove // this note } /* * Typedefs */ typedef advertised-received { type enumeration { Raza, et al. Expires September 21, 2020 [Page 29] Internet-Draft YANG Data Model for MPLS LDP March 2020 enum advertised { description "Advertised information."; } enum received { description "Received information."; } } description "Received or advertised."; } typedef downstream-upstream { type enumeration { enum downstream { description "Downstream information."; } enum upstream { description "Upstream information."; } } description "Downstream or upstream."; } typedef label-adv-mode { type enumeration { enum downstream-unsolicited { description "Downstream Unsolicited."; } enum downstream-on-demand { description "Downstream on Demand."; } } description "Label Advertisement Mode."; } typedef oper-status-event-type { type enumeration { enum up { value 1; description "Operational status changed to up."; } enum down { value 2; description "Operational status changed to down."; Raza, et al. Expires September 21, 2020 [Page 30] Internet-Draft YANG Data Model for MPLS LDP March 2020 } } description "Operational status event type for notifications."; } /* * Identities */ identity mpls-ldp { base rt:control-plane-protocol; description "LDP protocol."; reference "RFC 5036: LDP Specification"; } identity adjacency-flag-base { description "Base type for adjacency flags."; } identity adjacency-flag-active { base adjacency-flag-base; description "This adjacency is configured and actively created."; } identity adjacency-flag-passive { base adjacency-flag-base; description "This adjacency is not configured and passively accepted."; } /* * Groupings */ grouping adjacency-state-attributes { description "The operational state attributes of an LDP Hello adjacency, which can used for basic and extended discoveris, in IPv4 and IPv6 address families."; leaf-list flag { type identityref { base adjacency-flag-base; } description "On or more flags to indicate whether the adjacency is Raza, et al. Expires September 21, 2020 [Page 31] Internet-Draft YANG Data Model for MPLS LDP March 2020 actively created, passively accepted, or both."; } container hello-holdtime { description "Containing Hello holdtime state information."; leaf adjacent { type uint16; units seconds; description "The holdtime value learned from the adjacent LSR."; } leaf negotiated { type uint16; units seconds; description "The holdtime negotiated between this LSR and the adjacent LSR."; } leaf remaining { type uint16; units seconds; description "The time remaining until the holdtime timer expires."; } } leaf next-hello { type uint16; units seconds; description "The time when the next Hello message will be sent."; } container statistics { description "Statistics objects."; leaf discontinuity-time { type yang:date-and-time; mandatory true; description "The time on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } Raza, et al. Expires September 21, 2020 [Page 32] Internet-Draft YANG Data Model for MPLS LDP March 2020 leaf hello-received { type yang:counter64; description "The number of Hello messages received."; } leaf hello-dropped { type yang:counter64; description "The number of Hello messages dropped."; } } // statistics } // adjacency-state-attributes grouping basic-discovery-timers { description "The timer attributes for basic discovery, used in the per-interface setting and in the all-interface setting."; leaf hello-holdtime { type uint16 { range 15..3600; } units seconds; description "The time interval for which a LDP link Hello adjacency is maintained in the absence of link Hello messages from the LDP neighbor. This leaf may be configured at the per-interface level or the global level, with precedence given to the value at the per-interface level. If the leaf is not configured at either level, the default value at the global level is used."; } leaf hello-interval { type uint16 { range 5..1200; } units seconds; description "The interval between consecutive LDP link Hello messages used in basic LDP discovery. This leaf may be configured at the per-interface level or the global level, with precedence given to the value at the per-interface level. If the leaf is not configured at either level, the default value at the global level is used."; } } // basic-discovery-timers Raza, et al. Expires September 21, 2020 [Page 33] Internet-Draft YANG Data Model for MPLS LDP March 2020 grouping binding-address-state-attributes { description "Operational state attributes of an address binding, used in IPv4 and IPv6 address families."; leaf advertisement-type { type advertised-received; description "Received or advertised."; } container peer { when "../advertisement-type = 'received'" { description "Applicable for received address."; } description "LDP peer from which this address is received."; uses ldp-peer-ref-from-binding; } } // binding-address-state-attributes grouping binding-label-state-attributes { description "Operational state attributes for a FEC-label binding, used in IPv4 and IPv6 address families."; list peer { key "lsr-id label-space-id advertisement-type"; description "List of advertised and received peers."; uses ldp-peer-ref-from-binding { description "The LDP peer from which this binding is received, or to which this binding is advertised. The peer is identified by its LDP ID, which consists of the LSR ID and the Label Space ID."; } leaf advertisement-type { type advertised-received; description "Received or advertised."; } leaf label { type rt-types:mpls-label; description "Advertised (outbound) or received (inbound) label."; } Raza, et al. Expires September 21, 2020 [Page 34] Internet-Draft YANG Data Model for MPLS LDP March 2020 leaf used-in-forwarding { type boolean; description "'true' if the label is used in forwarding."; } } // peer } // binding-label-state-attributes grouping graceful-restart-attributes-per-peer { description "Per peer graceful restart attributes. On the local side, these attributes are configuration and operational state data. One the peer side, these attributes are operational state data received from the peer."; container graceful-restart { description "Attributes for graceful restart."; leaf enabled { type boolean; description "Enable or disable graceful restart. This leaf may be configured at the per-peer level or the global level, with precedence given to the value at the per-peer level. If the leaf is not configured at either level, the default value at the global level is used."; } leaf reconnect-time { type uint16 { range 10..1800; } units seconds; description "Specifies the time interval that the remote LDP peer must wait for the local LDP peer to reconnect after the remote peer detects the LDP communication failure. This leaf may be configured at the per-peer level or the global level, with precedence given to the value at the per-peer level. If the leaf is not configured at either level, the default value at the global level is used."; } leaf recovery-time { type uint16 { range 30..3600; } units seconds; description "Specifies the time interval, in seconds, that the remote Raza, et al. Expires September 21, 2020 [Page 35] Internet-Draft YANG Data Model for MPLS LDP March 2020 LDP peer preserves its MPLS forwarding state after receiving the Initialization message from the restarted local LDP peer. This leaf may be configured at the per-peer level or the global level, with precedence given to the value at the per-peer level. If the leaf is not configured at either level, the default value at the global level is used."; } } // graceful-restart } // graceful-restart-attributes-per-peer grouping ldp-interface-ref { description "Defining a reference to LDP interface."; leaf name { type if:interface-ref; must "(/if:interfaces/if:interface[if:name=current()]/ip:ipv4)" + " or " + "(/if:interfaces/if:interface[if:name=current()]/ip:ipv6)" { description "Interface is IPv4 or IPv6."; } description "The name of an LDP interface."; } } grouping ldp-peer-ref-absolute { description "An absolute reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; leaf protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } description "The name of the LDP protocol instance."; } leaf lsr-id { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" + "[rt:name=current()/../protocol-name]/" + "ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:lsr-id"; } Raza, et al. Expires September 21, 2020 [Page 36] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "The LSR ID of the peer, as a portion of the peer LDP ID."; } leaf label-space-id { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" + "[rt:name=current()/../protocol-name]/" + "ldp:mpls-ldp/ldp:peers/" + "ldp:peer[ldp:lsr-id=current()/../lsr-id]/" + "ldp:label-space-id"; } description "The Label Space ID of the peer, as a portion of the peer LDP ID."; } } // ldp-peer-ref-absolute grouping ldp-peer-ref-from-binding { description "A relative reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; leaf lsr-id { type leafref { path "../../../../../../../ldp:peers/ldp:peer/ldp:lsr-id"; } description "The LSR ID of the peer, as a portion of the peer LDP ID."; } leaf label-space-id { type leafref { path "../../../../../../../ldp:peers/" + "ldp:peer[ldp:lsr-id=current()/../lsr-id]/" + "ldp:label-space-id"; } description "The Label Space ID of the peer, as a portion of the peer LDP ID."; } } // ldp-peer-ref-from-binding grouping ldp-peer-ref-from-interface { description "A relative reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; container peer { Raza, et al. Expires September 21, 2020 [Page 37] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; leaf lsr-id { type leafref { path "../../../../../../../../../ldp:peers/ldp:peer/" + "ldp:lsr-id"; } description "The LSR ID of the peer, as a portion of the peer LDP ID."; } leaf label-space-id { type leafref { path "../../../../../../../../../ldp:peers/" + "ldp:peer[ldp:lsr-id=current()/../lsr-id]/" + "ldp:label-space-id"; } description "The Label Space ID of the peer, as a portion of the peer LDP ID."; } } // peer } // ldp-peer-ref-from-interface grouping ldp-peer-ref-from-target { description "A relative reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; container peer { description "Reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; leaf lsr-id { type leafref { path "../../../../../../../../ldp:peers/ldp:peer/" + "ldp:lsr-id"; } description "The LSR ID of the peer, as a portion of the peer LDP ID."; } leaf label-space-id { type leafref { path "../../../../../../../../ldp:peers/" + "ldp:peer[ldp:lsr-id=current()/../lsr-id]/" + "ldp:label-space-id"; } description Raza, et al. Expires September 21, 2020 [Page 38] Internet-Draft YANG Data Model for MPLS LDP March 2020 "The Label Space ID of the peer, as a portion of the peer LDP ID."; } } // peer } // ldp-peer-ref-from-target grouping peer-attributes { description "Peer configuration attributes, used in the per-peer setting can in the all-peer setting."; leaf session-ka-holdtime { type uint16 { range 45..3600; } units seconds; description "The time interval after which an inactive LDP session terminates and the corresponding TCP session closes. Inactivity is defined as not receiving LDP packets from the peer. This leaf may be configured at the per-peer level or the global level, with precedence given to the value at the per-peer level. If the leaf is not configured at either level, the default value at the global level is used."; } leaf session-ka-interval { type uint16 { range 15..1200; } units seconds; description "The interval between successive transmissions of keepalive packets. Keepalive packets are only sent in the absence of other LDP packets transmitted over the LDP session. This leaf may be configured at the per-peer level or the global level, with precedence given to the value at the per-peer level. If the leaf is not configured at either level, the default value at the global level is used."; } } // peer-attributes grouping peer-authentication { description "Peer authentication container, used in the per-peer setting can in the all-peer setting."; container authentication { Raza, et al. Expires September 21, 2020 [Page 39] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Containing authentication information."; choice authentication-type { description "Choice of authentication."; case password { leaf key { type string; description "This leaf specifies the authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } } } // peer-authentication grouping peer-state-derived { description "The peer state information derived from the LDP protocol operations."; container label-advertisement-mode { config false; description "Label advertisement mode state."; leaf local { type label-adv-mode; description "Local Label Advertisement Mode."; } leaf peer { type label-adv-mode; description "Peer Label Advertisement Mode."; } leaf negotiated { type label-adv-mode; description "Negotiated Label Advertisement Mode."; } Raza, et al. Expires September 21, 2020 [Page 40] Internet-Draft YANG Data Model for MPLS LDP March 2020 } leaf next-keep-alive { type uint16; units seconds; config false; description "Time duration from now until sending the next KeepAlive message."; } container received-peer-state { config false; description "Operational state information learned from the peer."; uses graceful-restart-attributes-per-peer; container capability { description "Peer capability information."; container end-of-lib { description "Peer's end-of-lib capability."; leaf enabled { type boolean; description "'true' if peer's end-of-lib capability is enabled."; } } container typed-wildcard-fec { description "Peer's typed-wildcard-fec capability."; leaf enabled { type boolean; description "'true' if peer's typed-wildcard-fec capability is enabled."; } } container upstream-label-assignment { description "Peer's upstream label assignment capability."; leaf enabled { type boolean; description "'true' if peer's upstream label assignment is enabled."; } } Raza, et al. Expires September 21, 2020 [Page 41] Internet-Draft YANG Data Model for MPLS LDP March 2020 } // capability } // received-peer-state container session-holdtime { config false; description "Session holdtime state."; leaf peer { type uint16; units seconds; description "Peer holdtime."; } leaf negotiated { type uint16; units seconds; description "Negotiated holdtime."; } leaf remaining { type uint16; units seconds; description "Remaining holdtime."; } } // session-holdtime leaf session-state { type enumeration { enum non-existent { description "NON EXISTENT state. Transport disconnected."; } enum initialized { description "INITIALIZED state."; } enum openrec { description "OPENREC state."; } enum opensent { description "OPENSENT state."; } enum operational { description "OPERATIONAL state."; } } config false; description "Representing the operational status of the LDP session."; reference "RFC5036, Sec. 2.5.4."; } Raza, et al. Expires September 21, 2020 [Page 42] Internet-Draft YANG Data Model for MPLS LDP March 2020 container tcp-connection { config false; description "TCP connection state."; leaf local-address { type inet:ip-address; description "Local address."; } leaf local-port { type inet:port-number; description "Local port number."; } leaf remote-address { type inet:ip-address; description "Remote address."; } leaf remote-port { type inet:port-number; description "Remote port number."; } } // tcp-connection leaf up-time { type rt-types:timeticks64; config false; description "The number of time ticks (hundredths of a second) since the the state of the session with the peer changed to OPERATIONAL."; } container statistics { config false; description "Statistics objects."; leaf discontinuity-time { type yang:date-and-time; mandatory true; description "The time on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container received { Raza, et al. Expires September 21, 2020 [Page 43] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Inbound statistics."; uses statistics-peer-received-sent; } container sent { description "Outbound statistics."; uses statistics-peer-received-sent; } leaf total-addresses { type uint32; description "The number of learned addresses."; } leaf total-labels { type uint32; description "The number of learned labels."; } leaf total-fec-label-bindings { type uint32; description "The number of learned label-address bindings."; } } // statistics } // peer-state-derived grouping statistics-peer-received-sent { description "Inbound and outbound statistic counters."; leaf total-octets { type yang:counter64; description "The total number of octets sent or received."; } leaf total-messages { type yang:counter64; description "The number of messages sent or received."; } leaf address { type yang:counter64; description "The number of address messages sent or received."; } leaf address-withdraw { type yang:counter64; description "The number of address-withdraw messages sent or received."; Raza, et al. Expires September 21, 2020 [Page 44] Internet-Draft YANG Data Model for MPLS LDP March 2020 } leaf initialization { type yang:counter64; description "The number of initialization messages sent or received."; } leaf keepalive { type yang:counter64; description "The number of keepalive messages sent or received."; } leaf label-abort-request { type yang:counter64; description "The number of label-abort-request messages sent or received."; } leaf label-mapping { type yang:counter64; description "The number of label-mapping messages sent or received."; } leaf label-release { type yang:counter64; description "The number of label-release messages sent or received."; } leaf label-request { type yang:counter64; description "The number of label-request messages sent or received."; } leaf label-withdraw { type yang:counter64; description "The number of label-withdraw messages sent or received."; } leaf notification { type yang:counter64; description "The number of notification messages sent or received."; } } // statistics-peer-received-sent /* * Configuration data and operational state data nodes */ Raza, et al. Expires September 21, 2020 [Page 45] Internet-Draft YANG Data Model for MPLS LDP March 2020 augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'ldp:mpls-ldp')" { description "This augmentation is only valid for a control-plane protocol instance of LDP (type 'mpls-ldp')."; } description "LDP augmentation to routing control-plane protocol configuration and state."; container mpls-ldp { must "not (../../rt:control-plane-protocol" + "[derived-from-or-self(rt:type, 'ldp:mpls-ldp')]" + "[rt:name!=current()/../rt:name])" { description "Only one LDP instance is allowed."; } description "Containing configuration and operational data for the LDP protocol."; container global { description "Global attributes for LDP."; container capability { description "Containing the LDP capability data. The container is used for augmentations."; reference "RFC5036: Sec. 1.5."; } container graceful-restart { description "Attributes for graceful restart."; leaf enabled { type boolean; default false; description "Enable or disable graceful restart."; } leaf reconnect-time { type uint16 { range 10..1800; } Raza, et al. Expires September 21, 2020 [Page 46] Internet-Draft YANG Data Model for MPLS LDP March 2020 units seconds; default 120; description "Specifies the time interval that the remote LDP peer must wait for the local LDP peer to reconnect after the remote peer detects the LDP communication failure."; } leaf recovery-time { type uint16 { range 30..3600; } units seconds; default 120; description "Specifies the time interval, in seconds, that the remote LDP peer preserves its MPLS forwarding state after receiving the Initialization message from the restarted local LDP peer."; } leaf forwarding-holdtime { type uint16 { range 30..3600; } units seconds; default 180; description "Specifies the time interval, in seconds, before the termination of the recovery phase."; } } // graceful-restart leaf lsr-id { type rt-types:router-id; description "Specify the value to act as the LDP LSR ID. If this attribute is not specified, LDP uses the router ID as determined by the system."; } container address-families { description "Per address family confgiration and operational state. The address family can be either IPv4 or IPv6."; container ipv4 { presence "Present if IPv4 is enabled, unless the 'enabled' leaf is set to 'false'"; Raza, et al. Expires September 21, 2020 [Page 47] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Containing data related to the IPv4 address family."; leaf enabled { type boolean; default true; description "'false' to disable the address family."; } leaf label-distribution-control-mode { type enumeration { enum independent { description "Independent label distribution control."; } enum ordered { description "Ordered label distribution control."; } } config false; description "Label distribution control mode."; reference "RFC5036: LDP Specification. Sec 2.6."; } // ipv4 bindings container bindings { config false; description "LDP address and label binding information."; list address { key "address"; description "List of address bindings learned by LDP."; leaf address { type inet:ipv4-address; description "The IPv4 address learned from an Address message received from or advertised to a peer."; } uses binding-address-state-attributes; } list fec-label { key "fec"; Raza, et al. Expires September 21, 2020 [Page 48] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "List of FEC-label bindings learned by LDP."; leaf fec { type inet:ipv4-prefix; description "The prefix FEC value in the FEC-label binding, learned in a Label Mapping message received from or advertised to a peer."; } uses binding-label-state-attributes; } } // bindings } // ipv4 } // address-families } // global container discovery { description "Neighbor discovery configuration and operational state."; container interfaces { description "A list of interfaces for LDP Basic Discovery."; reference "RFC5036: LDP Specification. Sec 2.4.1."; uses basic-discovery-timers { refine "hello-holdtime" { default 15; } refine "hello-interval" { default 5; } } list interface { key "name"; description "List of LDP interfaces used for LDP Basic Discovery."; uses ldp-interface-ref; leaf next-hello { type uint16; units seconds; config false; description "Time to send the next Hello message."; } container address-families { Raza, et al. Expires September 21, 2020 [Page 49] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Container for address families."; container ipv4 { presence "Present if IPv4 is enabled, unless the 'enabled' leaf is set to 'false'"; description "IPv4 address family."; leaf enabled { type boolean; default true; description "Set to false to disable the address family on the interface."; } container hello-adjacencies { config false; description "Containing a list of Hello adjacencies."; list hello-adjacency { key "adjacent-address"; config false; description "List of Hello adjacencies."; leaf adjacent-address { type inet:ipv4-address; description "Neighbor address of the Hello adjacency."; } uses adjacency-state-attributes; uses ldp-peer-ref-from-interface; } } } // ipv4 } // address-families } // interface } // interfaces container targeted { description "A list of targeted neighbors for extended discovery."; leaf hello-holdtime { Raza, et al. Expires September 21, 2020 [Page 50] Internet-Draft YANG Data Model for MPLS LDP March 2020 type uint16 { range 15..3600; } units seconds; default 45; description "The time interval for which LDP targeted Hello adjacency is maintained in the absence of targeted Hello messages from an LDP neighbor."; } leaf hello-interval { type uint16 { range 5..3600; } units seconds; default 15; description "The interval between consecutive LDP targeted Hello messages used in extended LDP discovery."; } container hello-accept { description "LDP policy to control the acceptance of extended neighbor discovery Hello messages."; leaf enabled { type boolean; default false; description "'true' to accept; 'false' to deny."; } } container address-families { description "Container for address families."; container ipv4 { presence "Present if IPv4 is enabled."; description "IPv4 address family."; container hello-adjacencies { config false; description "Containing a list of Hello adjacencies."; Raza, et al. Expires September 21, 2020 [Page 51] Internet-Draft YANG Data Model for MPLS LDP March 2020 list hello-adjacency { key "local-address adjacent-address"; description "List of Hello adjacencies."; leaf local-address { type inet:ipv4-address; description "Local address of the Hello adjacency."; } leaf adjacent-address { type inet:ipv4-address; description "Neighbor address of the Hello adjacency."; } uses adjacency-state-attributes; uses ldp-peer-ref-from-target; } } list target { key "adjacent-address"; description "Targeted discovery params."; leaf adjacent-address { type inet:ipv4-address; description "Configures a remote LDP neighbor for the extended LDP discovery."; } leaf enabled { type boolean; default true; description "'true' to enable the target."; } leaf local-address { type inet:ipv4-address; description "The local address used as the source address to send targeted Hello messages. If the value is not specified, the transport-address is used as the source address."; } } // target Raza, et al. Expires September 21, 2020 [Page 52] Internet-Draft YANG Data Model for MPLS LDP March 2020 } // ipv4 } // address-families } // targeted } // discovery container peers { description "Peers configuration attributes."; uses peer-authentication; uses peer-attributes { refine session-ka-holdtime { default 180; } refine session-ka-interval { default 60; } } list peer { key "lsr-id label-space-id"; description "List of peers."; leaf lsr-id { type rt-types:router-id; description "The LSR ID of the peer, to identify the globally unique LSR. This is the first four octets of the LDP ID. This leaf is used together with the leaf 'label-space-id' to form the LDP ID."; reference "RFC5036. Sec 2.2.2."; } leaf label-space-id { type uint16; description "The Label Space ID of the peer, to identify a specific label space within the LSR. This is the last two octets of the LDP ID. This leaf is used together with the leaf 'lsr-id' to form the LDP ID."; reference "RFC5036. Sec 2.2.2."; } uses peer-authentication; container address-families { Raza, et al. Expires September 21, 2020 [Page 53] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Per-vrf per-af params."; container ipv4 { presence "Present if IPv4 is enabled."; description "IPv4 address family."; container hello-adjacencies { config false; description "Containing a list of Hello adjacencies."; list hello-adjacency { key "local-address adjacent-address"; description "List of Hello adjacencies."; leaf local-address { type inet:ipv4-address; description "Local address of the Hello adjacency."; } leaf adjacent-address { type inet:ipv4-address; description "Neighbor address of the Hello adjacency."; } uses adjacency-state-attributes; leaf interface { type if:interface-ref; description "Interface for this adjacency."; } } } } // ipv4 } // address-families uses peer-state-derived; } // list peer } // peers } // container mpls-ldp } /* * RPCs */ Raza, et al. Expires September 21, 2020 [Page 54] Internet-Draft YANG Data Model for MPLS LDP March 2020 rpc mpls-ldp-clear-peer { description "Clears the session to the peer."; input { uses ldp-peer-ref-absolute { description "The LDP peer to be cleared. If this is not provided then all peers are cleared. The peer is identified by its LDP ID, which consists of the LSR ID and the Label Space ID."; } } } rpc mpls-ldp-clear-hello-adjacency { description "Clears the hello adjacency"; input { container hello-adjacency { description "Link adjacency or targettted adjacency. If this is not provided then all Hello adjacencies are cleared"; leaf protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } description "The name of the LDP protocol instance."; } choice hello-adjacency-type { description "Adjacency type."; case targeted { container targeted { presence "Present to clear targeted adjacencies."; description "Clear targeted adjacencies."; leaf target-address { type inet:ip-address; description "The target address. If this is not provided then all targeted adjacencies are cleared"; } } } case link { container link { presence "Present to clear link adjacencies."; Raza, et al. Expires September 21, 2020 [Page 55] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Clear link adjacencies."; leaf next-hop-interface { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/mpls-ldp/discovery/" + "interfaces/interface/name"; } description "Interface connecting to next-hop. If this is not provided then all link adjacencies are cleared."; } leaf next-hop-address { type inet:ip-address; must "../next-hop-interface" { description "Applicable when interface is specified."; } description "IP address of next-hop. If this is not provided then adjacencies to all next-hops on the given interface are cleared."; } } } } // hello-adjacency-type } // hello-adjacency } // input } // mpls-ldp-clear-hello-adjacency rpc mpls-ldp-clear-peer-statistics { description "Clears protocol statistics (e.g. sent and received counters)."; input { uses ldp-peer-ref-absolute { description "The LDP peer whose statistics are to be cleared. If this is not provided then all peers' statistics are cleared. The peer is identified by its LDP ID, which consists of the LSR ID and the Label Space ID."; } } } /* * Notifications Raza, et al. Expires September 21, 2020 [Page 56] Internet-Draft YANG Data Model for MPLS LDP March 2020 */ notification mpls-ldp-peer-event { description "Notification event for a change of LDP peer operational status."; leaf event-type { type oper-status-event-type; description "Event type."; } container peer { description "Reference to an LDP peer, by the LDP ID, which consists of the LSR ID and the Label Space ID."; uses ldp-peer-ref-absolute; } } notification mpls-ldp-hello-adjacency-event { description "Notification event for a change of LDP adjacency operational status."; leaf event-type { type oper-status-event-type; description "Event type."; } leaf protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } description "The name of the LDP protocol instance."; } choice hello-adjacency-type { description "Interface or targeted adjacency."; case targeted { container targeted { description "Targeted adjacency through LDP extended discovery."; leaf target-address { type inet:ip-address; description "The target adjacent address learned."; } } } Raza, et al. Expires September 21, 2020 [Page 57] Internet-Draft YANG Data Model for MPLS LDP March 2020 case link { container link { description "Link adjacency through LDP basic discovery."; leaf next-hop-interface { type if:interface-ref; description "The interface connecting to the adjacent next hop."; } leaf next-hop-address { type inet:ip-address; must "../next-hop-interface" { description "Applicable when interface is specified."; } description "IP address of the next hop. This can be IPv4 or IPv6 address."; } } } } // hello-adjacency-type } // mpls-ldp-hello-adjacency-event notification mpls-ldp-fec-event { description "Notification event for a change of FEC status."; leaf event-type { type oper-status-event-type; description "Event type."; } leaf protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } description "The name of the LDP protocol instance."; } leaf fec { type inet:ip-prefix; description "The address prefix element of the FEC whose status has changed."; } } } Raza, et al. Expires September 21, 2020 [Page 58] Internet-Draft YANG Data Model for MPLS LDP March 2020 Figure 10: LDP base module 9.2. Extended This YANG module imports types defined in [RFC6991], [RFC8349], [RFC8177], and [RFC8343]. file "ietf-mpls-ldp-extended@2020-02-25.yang" // RFC Editor: replace the above date 2020-02-25 with the date of // publication and remove this note. module ietf-mpls-ldp-extended { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-ldp-extended"; prefix "ldp-ext"; import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA version)"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177: YANG Data Model for Key Chains"; } import ietf-mpls-ldp { prefix "ldp"; reference "RFC XXXX: YANG Data Model for MPLS LDP"; // RFC Editor: replace XXXX with actual RFC number and remove // this note } Raza, et al. Expires September 21, 2020 [Page 59] Internet-Draft YANG Data Model for MPLS LDP March 2020 import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-routing-policy { prefix rt-pol; reference "I-D.ietf-rtgwg-policy-model: A YANG Data Model for Routing Policy Management"; } organization "IETF MPLS Working Group"; contact "WG Web: WG List: Editor: Kamran Raza Editor: Rajiv Asati Editor: Xufeng Liu Editor: Santosh Esale Editor: Xia Chen Editor: Himanshu Shah "; description "This YANG module defines the extended components for the management of Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). It is also the model to be augmented for extended Multipoint LDP (mLDP). Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set Raza, et al. Expires September 21, 2020 [Page 60] Internet-Draft YANG Data Model for MPLS LDP March 2020 forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Editor: replace XXXX with actual RFC number and remove // this note revision 2020-02-25 { description "Initial revision."; reference "RFC XXXX: YANG Data Model for MPLS LDP."; // RFC Editor: replace XXXX with actual RFC number and remove // this note } /* * Features */ feature capability-end-of-lib { description "This feature indicates that the system allows to configure LDP end-of-lib capability."; } feature capability-typed-wildcard-fec { description "This feature indicates that the system allows to configure LDP typed-wildcard-fec capability."; } feature capability-upstream-label-assignment { description "This feature indicates that the system allows to configure LDP upstream label assignment capability."; } feature forwarding-nexthop-config { description "This feature indicates that the system allows to configure forwarding nexthop on interfaces."; } feature graceful-restart-helper-mode { Raza, et al. Expires September 21, 2020 [Page 61] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "This feature indicates that the system supports graceful restart helper mode. We call an LSR to be operating in GR helper mode when it advertises 0 as its FT Reconnect Timeout in the FT Session TLV. Please refer RFC3478 section 2 for details."; } feature key-chain { description "This feature indicates that the system supports keychain for authentication."; } feature peers-dual-stack-transport-preference { description "This feature indicates that the system allows to configure the transport connection preference in a dual-stack setup for peers."; } feature per-interface-timer-config { description "This feature indicates that the system allows to configure interface Hello timers at the per-interface level."; } feature per-peer-admin-down { description "This feature indicates that the system allows to administratively disable a peer."; } feature per-peer-graceful-restart-config { description "This feature indicates that the system allows to configure graceful restart at the per-peer level."; } feature per-peer-session-attributes-config { description "This feature indicates that the system allows to configure session attributes at the per-peer level."; } feature policy-label-assignment-config { description "This feature indicates that the system allows to configure Raza, et al. Expires September 21, 2020 [Page 62] Internet-Draft YANG Data Model for MPLS LDP March 2020 policies to assign labels according to certain prefixes."; } feature policy-ordered-label-config { description "This feature indicates that the system allows to configure ordered label policies."; } feature policy-targeted-discovery-config { description "This feature indicates that the system allows to configure policies to control the acceptance of targeted neighbor discovery Hello messages."; } feature session-downstream-on-demand-config { description "This feature indicates that the system allows to configure session downstream-on-demand"; } /* * Typedefs */ typedef neighbor-list-ref { type leafref { path "/rt-pol:routing-policy/rt-pol:defined-sets/" + "rt-pol:neighbor-sets/rt-pol:neighbor-set/rt-pol:name"; } description "A type for a reference to a neighbor address list. The string value is the name identifier for uniquely identifying the referenced address list, which contains a list of addresses that a routing policy can applied."; reference "I-D.ietf-rtgwg-policy-model: A YANG Data Model for Routing Policy Management"; } typedef prefix-list-ref { type leafref { path "/rt-pol:routing-policy/rt-pol:defined-sets/" + "rt-pol:prefix-sets/rt-pol:prefix-set/rt-pol:name"; } description "A type for a reference to a prefix list. The string value is the name identifier for uniquely Raza, et al. Expires September 21, 2020 [Page 63] Internet-Draft YANG Data Model for MPLS LDP March 2020 identifying the referenced prefix set, which contains a list of prefixes that a routing policy can applied."; reference "I-D.ietf-rtgwg-policy-model: A YANG Data Model for Routing Policy Management"; } typedef peer-list-ref { type leafref { path "/rt-pol:routing-policy/rt-pol:defined-sets/" + "rt-pol:neighbor-sets/rt-pol:neighbor-set/rt-pol:name"; } description "A type for a reference to a peer address list. The string value is the name identifier for uniquely identifying the referenced address list, which contains a list of addresses that a routing policy can applied."; reference "I-D.ietf-rtgwg-policy-model: A YANG Data Model for Routing Policy Management"; } /* * Identities */ /* * Groupings */ grouping address-family-ipv4-augment { description "Augmentation to address family IPv4."; uses policy-container; leaf transport-address { type inet:ipv4-address; description "The transport address advertised in LDP Hello messages. If this value is not specified, the LDP LSR ID is used as the transport address."; reference "RFC5036. Sec. 3.5.2."; } } grouping authentication-keychain-augment { description "Augmentation to authentication to add keychain."; Raza, et al. Expires September 21, 2020 [Page 64] Internet-Draft YANG Data Model for MPLS LDP March 2020 leaf key-chain { type key-chain:key-chain-ref; description "key-chain name. If not specified, no key chain is used."; } } grouping capability-augment { description "Augmentation to capability."; container end-of-lib { if-feature capability-end-of-lib; description "Configure end-of-lib capability."; leaf enabled { type boolean; default false; description "'true' to enable end-of-lib capability."; } } container typed-wildcard-fec { if-feature capability-typed-wildcard-fec; description "Configure typed-wildcard-fec capability."; leaf enabled { type boolean; default false; description "'true' to enable typed-wildcard-fec capability."; } } container upstream-label-assignment { if-feature capability-upstream-label-assignment; description "Configure upstream label assignment capability."; leaf enabled { type boolean; default false; description "'true' to enable upstream label assignment."; } } } // capability-augment grouping global-augment { description "Augmentation to global attributes."; Raza, et al. Expires September 21, 2020 [Page 65] Internet-Draft YANG Data Model for MPLS LDP March 2020 leaf igp-synchronization-delay { type uint16 { range "0 | 3..300"; } units seconds; default 0; description "Sets the interval that the LDP waits before notifying the Interior Gateway Protocol (IGP) that label exchange is completed so that IGP can start advertising the normal metric for the link. If the value is not specified, there is no delay."; } } grouping global-forwarding-nexthop-augment { description "Augmentation to global forwarding nexthop interfaces."; container forwarding-nexthop { if-feature forwarding-nexthop-config; description "Configuration for forwarding nexthop."; container interfaces { description "Containing a list of interfaces on which forwarding can be disabled."; list interface { key "name"; description "List of LDP interfaces on which forwarding can be disabled."; uses ldp:ldp-interface-ref; list address-family { key "afi"; description "Per-vrf per-af params."; leaf afi { type identityref { base rt:address-family; } description "Address family type value."; } leaf ldp-disable { type boolean; Raza, et al. Expires September 21, 2020 [Page 66] Internet-Draft YANG Data Model for MPLS LDP March 2020 default false; description "'true' to disable LDP forwarding on the interface."; } } } // interface } // interfaces } // forwarding-nexthop } // global-forwarding-nexthop-augment grouping graceful-restart-augment { description "Augmentation to graceful restart."; leaf helper-enabled { if-feature graceful-restart-helper-mode; type boolean; default false; description "Enable or disable graceful restart helper mode."; } } grouping interface-address-family-ipv4-augment { description "Augmentation to interface address family IPv4."; leaf transport-address { type union { type enumeration { enum "use-global-transport-address" { description "Use the transport address set at the global level common for all interfaces for this address family."; } enum "use-interface-address" { description "Use interface address as the transport address."; } } type inet:ipv4-address; } default "use-global-transport-address"; description "IP address to be advertised as the LDP transport address."; } } grouping interface-address-family-ipv6-augment { description "Augmentation to interface address family IPv6."; Raza, et al. Expires September 21, 2020 [Page 67] Internet-Draft YANG Data Model for MPLS LDP March 2020 leaf transport-address { type union { type enumeration { enum "use-global-transport-address" { description "Use the transport address set at the global level common for all interfaces for this address family."; } enum "use-interface-address" { description "Use interface address as the transport address."; } } type inet:ipv6-address; } default "use-global-transport-address"; description "IP address to be advertised as the LDP transport address."; } } grouping interface-augment { description "Augmentation to interface."; uses ldp:basic-discovery-timers { if-feature per-interface-timer-config; } leaf igp-synchronization-delay { if-feature per-interface-timer-config; type uint16 { range "0 | 3..300"; } units seconds; description "Sets the interval that the LDP waits before notifying the Interior Gateway Protocol (IGP) that label exchange is completed so that IGP can start advertising the normal metric for the link. This leaf may be configured at the per-interface level or the global level, with precedence given to the value at the per-interface level. If the leaf is not configured at either level, the default value at the global level is used."; } } grouping peer-af-policy-container { description Raza, et al. Expires September 21, 2020 [Page 68] Internet-Draft YANG Data Model for MPLS LDP March 2020 "LDP policy attribute container under peer address-family."; container label-policy { description "Label policy attributes."; container advertise { description "Label advertising policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to filter outgoing label advertisements. If the value is not specified, no prefix filter is applied."; } } container accept { description "Label advertisement acceptance policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to filer incoming label advertisements. If the value is not specified, no prefix filter is applied."; } } } } // peer-af-policy-container grouping peer-augment { description "Augmentation to each peer list entry."; leaf admin-down { if-feature per-peer-admin-down; type boolean; default false; description "'true' to disable the peer."; } uses ldp:graceful-restart-attributes-per-peer { if-feature per-peer-graceful-restart-config; } uses ldp:peer-attributes { if-feature per-peer-session-attributes-config; Raza, et al. Expires September 21, 2020 [Page 69] Internet-Draft YANG Data Model for MPLS LDP March 2020 } } grouping peers-augment { description "Augmentation to peers container."; container session-downstream-on-demand { if-feature session-downstream-on-demand-config; description "Session downstream-on-demand attributes."; leaf enabled { type boolean; default false; description "'true' if session downstream-on-demand is enabled."; } leaf peer-list { type peer-list-ref; description "The name of a peer ACL, to be applied to the downstream-on-demand sessions. If this value is not specified, no filter is applied to any downstream-on-demand sessions."; } } container dual-stack-transport-preference { if-feature peers-dual-stack-transport-preference; description "The settings of peers to establish TCP connection in a dual-stack setup."; leaf max-wait { type uint16 { range "0..60"; } default 30; description "The maximum wait time in seconds for preferred transport connection establishment. 0 indicates no preference."; } container prefer-ipv4 { presence "Present if IPv4 is prefered for transport connection establishment, subject to the 'peer-list' in this container."; description "Uses IPv4 as the prefered address family for transport connection establishment, subject to the 'peer-list' in this container. Raza, et al. Expires September 21, 2020 [Page 70] Internet-Draft YANG Data Model for MPLS LDP March 2020 If this container is not present, as a default, IPv6 is the prefered address family for transport connection establishment."; leaf peer-list { type peer-list-ref; description "The name of a peer ACL, to be applied to the IPv4 transport connections. If this value is not specified, no filter is applied, and the IPv4 is prefered for all peers."; } } } } // peers-augment grouping policy-container { description "LDP policy attributes."; container label-policy { description "Label policy attributes."; container advertise { description "Label advertising policies."; container egress-explicit-null { description "Enables an egress router to advertise an explicit null label (value 0) in place of an implicit null label (value 3) to the penultimate hop router."; leaf enabled { type boolean; default false; description "'true' to enable explicit null."; } } leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to filter outgoing label advertisements. If the value is not specified, no prefix filter is applied."; } } container accept { description Raza, et al. Expires September 21, 2020 [Page 71] Internet-Draft YANG Data Model for MPLS LDP March 2020 "Label advertisement acceptance policies."; leaf prefix-list { type prefix-list-ref; description "Applies the prefix list to filter incoming label advertisements. If the value is not specified, no prefix filter is applied."; } } container assign { if-feature policy-label-assignment-config; description "Label assignment policies"; container independent-mode { description "Independent label policy attributes."; leaf prefix-list { type prefix-list-ref; description "Assign labels according to certain prefixes. If the value is not specified, no prefix filter is applied (labels are assigned to all learned routes)."; } } container ordered-mode { if-feature policy-ordered-label-config; description "Ordered label policy attributes."; leaf egress-prefix-list { type prefix-list-ref; description "Assign labels according to certain prefixes for egress LSR."; } } } // assign } // label-policy } // policy-container /* * Configuration and state data nodes */ // Forwarding nexthop augmentation to the global tree augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:global" { Raza, et al. Expires September 21, 2020 [Page 72] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Forwarding nexthop augmentation."; uses global-forwarding-nexthop-augment; } // global/address-families/ipv6 augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:global/" + "ldp:address-families" { description "Global IPv6 augmentation."; container ipv6 { presence "Present if IPv6 is enabled, unless the 'enabled' leaf is set to 'false'"; description "Containing data related to the IPv6 address family."; leaf enabled { type boolean; default true; description "'false' to disable the address family."; } uses policy-container; leaf transport-address { type inet:ipv6-address; mandatory true; description "The transport address advertised in LDP Hello messages."; } leaf label-distribution-control-mode { type enumeration { enum independent { description "Independent label distribution control."; } enum ordered { description "Ordered label distribution control."; } } config false; description "Label distribution control mode."; reference Raza, et al. Expires September 21, 2020 [Page 73] Internet-Draft YANG Data Model for MPLS LDP March 2020 "RFC5036: LDP Specification. Sec 2.6."; } // ipv6 bindings container bindings { config false; description "LDP address and label binding information."; list address { key "address"; description "List of address bindings learned by LDP."; leaf address { type inet:ipv6-address; description "The IPv6 address learned from an Address message received from or advertised to a peer."; } uses ldp:binding-address-state-attributes; } list fec-label { key "fec"; description "List of FEC-label bindings learned by LDP."; leaf fec { type inet:ipv6-prefix; description "The prefix FEC value in the FEC-label binding, learned in a Label Mapping message received from or advertised to a peer."; } uses ldp:binding-label-state-attributes; } } // bindings } // ipv6 } // discovery/interfaces/interface/address-families/ipv6 augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:discovery/" + "ldp:interfaces/ldp:interface/" + "ldp:address-families" { description "Interface IPv6 augmentation."; container ipv6 { presence "Present if IPv6 is enabled, unless the 'enabled' Raza, et al. Expires September 21, 2020 [Page 74] Internet-Draft YANG Data Model for MPLS LDP March 2020 leaf is set to 'false'"; description "IPv6 address family."; leaf enabled { type boolean; default true; description "'false' to disable the address family on the interface."; } container hello-adjacencies { config false; description "Containing a list of Hello adjacencies."; list hello-adjacency { key "adjacent-address"; config false; description "List of Hello adjacencies."; leaf adjacent-address { type inet:ipv6-address; description "Neighbor address of the Hello adjacency."; } uses ldp:adjacency-state-attributes; uses ldp:ldp-peer-ref-from-interface; } } } // ipv6 } // discovery/targeted/address-families/ipv6 augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:discovery/" + "ldp:targeted/ldp:address-families" { description "Targeted discovery IPv6 augmentation."; container ipv6 { presence "Present if IPv6 is enabled."; description "IPv6 address family."; container hello-adjacencies { config false; Raza, et al. Expires September 21, 2020 [Page 75] Internet-Draft YANG Data Model for MPLS LDP March 2020 description "Containing a list of Hello adjacencies."; list hello-adjacency { key "local-address adjacent-address"; config false; description "List of Hello adjacencies."; leaf local-address { type inet:ipv6-address; description "Local address of the Hello adjacency."; } leaf adjacent-address { type inet:ipv6-address; description "Neighbor address of the Hello adjacency."; } uses ldp:adjacency-state-attributes; uses ldp:ldp-peer-ref-from-target; } } list target { key "adjacent-address"; description "Targeted discovery params."; leaf adjacent-address { type inet:ipv6-address; description "Configures a remote LDP neighbor for the extended LDP discovery."; } leaf enabled { type boolean; default true; description "'true' to enable the target."; } leaf local-address { type inet:ipv6-address; description "The local address used as the source address to send targeted Hello messages. If the value is not specified, the transport-address is used as the source address."; Raza, et al. Expires September 21, 2020 [Page 76] Internet-Draft YANG Data Model for MPLS LDP March 2020 } } // target } // ipv6 } // /peers/peer/state/address-families/ipv6 augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers/" + "ldp:peer/ldp:address-families" { description "Peer state IPv6 augmentation."; container ipv6 { presence "Present if IPv6 is enabled."; description "IPv6 address family."; container hello-adjacencies { config false; description "Containing a list of Hello adjacencies."; list hello-adjacency { key "local-address adjacent-address"; description "List of Hello adjacencies."; leaf local-address { type inet:ipv6-address; description "Local address of the Hello adjacency."; } leaf adjacent-address { type inet:ipv6-address; description "Neighbor address of the Hello adjacency."; } uses ldp:adjacency-state-attributes; leaf interface { type if:interface-ref; description "Interface for this adjacency."; } } } } // ipv6 } Raza, et al. Expires September 21, 2020 [Page 77] Internet-Draft YANG Data Model for MPLS LDP March 2020 /* * Configuration data and operational state data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:global" { description "Graceful restart augmentation."; uses global-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:global/" + "ldp:capability" { description "Capability augmentation."; uses capability-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:global/" + "ldp:graceful-restart" { description "Graceful restart augmentation."; uses graceful-restart-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:global/" + "ldp:address-families/ldp:ipv4" { description "Address family IPv4 augmentation."; uses address-family-ipv4-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:discovery/" + "ldp:interfaces/ldp:interface" { description "Interface augmentation."; uses interface-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:discovery/" + "ldp:interfaces/ldp:interface/ldp:address-families/" + "ldp:ipv4" { description "Interface address family IPv4 augmentation."; uses interface-address-family-ipv4-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:discovery/" + "ldp:interfaces/ldp:interface/ldp:address-families/" Raza, et al. Expires September 21, 2020 [Page 78] Internet-Draft YANG Data Model for MPLS LDP March 2020 + "ldp-ext:ipv6" { description "Interface address family IPv6 augmentation."; uses interface-address-family-ipv6-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:discovery/" + "ldp:targeted/ldp:hello-accept" { description "Targeted discovery augmentation."; leaf neighbor-list { if-feature policy-targeted-discovery-config; type neighbor-list-ref; description "The name of a neighbor ACL, to accept Hello messages from LDP peers as permitted by the neighbor-list policy. If this value is not specified, targeted Hello messages from any source are accepted."; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers" { description "Peers augmentation."; uses peers-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers/" + "ldp:authentication/ldp:authentication-type" { if-feature key-chain; description "Peers authentication augmentation."; case key-chain { uses authentication-keychain-augment; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers/ldp:peer" { description "Peer list entry augmentation."; uses peer-augment; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers/ldp:peer/" + "ldp:authentication/ldp:authentication-type" { if-feature key-chain; description "Peer list entry authentication augmentation."; case key-chain { Raza, et al. Expires September 21, 2020 [Page 79] Internet-Draft YANG Data Model for MPLS LDP March 2020 uses authentication-keychain-augment; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers/ldp:peer/" + "ldp:address-families/ldp:ipv4" { description "Peer list entry IPv4 augmentation."; uses peer-af-policy-container; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ldp:mpls-ldp/ldp:peers/ldp:peer/" + "ldp:address-families/ldp-ext:ipv6" { description "Peer list entry IPv6 augmentation."; uses peer-af-policy-container; } } Figure 11: LDP extended module 10. Security Considerations This specification inherits the security considerations captured in [RFC5920] and the LDP protocol specification documents, namely base LDP [RFC5036], LDP IPv6 [RFC7552], LDP Capabilities [RFC5561], Typed Wildcard FEC [RFC5918], LDP End-of-LIB [RFC5919], and LDP Upstream Label Assignment [RFC6389]. 10.1. YANG model The YANG modules specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or Raza, et al. Expires September 21, 2020 [Page 80] Internet-Draft YANG Data Model for MPLS LDP March 2020 RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. 10.1.1. Writable nodes There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. For LDP, the ability to modify MPLS LDP configuration may allow the entire MPLS LDP domain to be compromised including forming LDP adjacencies and/or peer sessions with unauthorized routers to mount a massive Denial-of-Service (DoS) attack. In particular, folling are the subtrees and data nodes that are sensitivite and vulnerable: * /mpls-ldp/discovery/interfaces/interface: Adding LDP on any unprotected interface could allow an LDP hello adjacency to be formed with an unauthorized and malicious neighbor. Once an hello adjacency is formed, a peer session could progress with this neighbor. * /mpls-ldp/discovery/targeted/hello-accept: Allowing acceptance of targeted-hellos could open LDP to DoS attacks related to incoming targeted hellos from malicious sources. * /mpls-ldp/peers/authentication: Allowing a peer session establishement is typically controlled via LDP authentication where a proper and secure authentication password/key management is warranted. * /mpls-ldp/peers/peer/authentication: Same as above. 10.1.2. Readable nodes Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: The exposure of LDP databases (such as hello adjacencies, peers, address bindings, and fec-label bindings) beyond the scope of the LDP admin domain may be undesirable. The relevant subtrees and data nodes are as follows: Raza, et al. Expires September 21, 2020 [Page 81] Internet-Draft YANG Data Model for MPLS LDP March 2020 * /mpls-ldp/global/address-families/ipv4/bindings/address * /mpls-ldp/global/address-families/ipv6/bindings/address * /mpls-ldp/global/address-families/ipv4/bindings/fec-label * /mpls-ldp/global/address-families/ipv6/bindings/fec-label * /mpls-ldp/discovery/interfaces/interface/address-families/ipv4/ hello-adjacencies * /mpls-ldp/discovery/interfaces/interface/address-families/ipv6/ hello-adjacencies * /mpls-ldp/discovery/targeted/address-families/ipv4/hello- adjacencies * /mpls-ldp/discovery/targeted/address-families/ipv6/hello- adjacencies * /mpls-ldp/peers The configuration for LDP peer authentication is supported via the specification of key-chain [RFC8040], or via direct specification of a key associated with a crypto algorithm (such as MD5). The relevant subtrees and data nodes are as follows: * /mpls-ldp/peers/authentication * /mpls-ldp/peers/peer/authentication The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties. For key-chain based authentication, this model inherits the security considerations of [RFC8040] (that includes the considerations with respect to the local storage and handling of authentication keys). A similar procedure for storage and access to direct key is warranted. 10.1.3. RPC operations Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations otherwise control plane flaps, network outages, and DoS attacks are possible. The RPC operations are: * mpls-ldp-clear-peer Raza, et al. Expires September 21, 2020 [Page 82] Internet-Draft YANG Data Model for MPLS LDP March 2020 * mpls-ldp-clear-hello-adjacency 10.1.4. Notifications The model describes several notifications. The implementations must rate-limit the generation of these notifications to avoid creating significant notification load and possible side effects on the system stability. 11. IANA Considerations This document requests the registration of the following URIs in the IETF "XML registry" [RFC3688]: +----------------------------------------------------+----------+---+ | URI |Registrant|XML| +====================================================+==========+===+ | urn:ietf:params:xml:ns:yang:ietf-mpls-ldp | The IESG |N/A| +----------------------------------------------------+----------+---+ | urn:ietf:params:xml:ns:yang:ietf-mpls-ldp-extended | The IESG |N/A| +----------------------------------------------------+----------+---+ Table 1: URIs This document requests the registration of the following YANG modules in the "YANG Module Names" registry [RFC6020]: +----------------------+---------------------------+------+---------+ | Name | Namespace |Prefix|Reference| +======================+===========================+======+=========+ |ietf-mpls-ldp |urn:ietf:params:xml:ns:yang| ldp | This | | |:ietf-mpls-ldp | | document| +----------------------+---------------------------+------+---------+ |ietf-mpls-ldp-extended|urn:ietf:params:xml:ns:yang| ldp- | This | | |:ietf-mpls-ldp-extended | ext | document| +----------------------+---------------------------+------+---------+ Table 2: YANG Modules -- RFC Editor: Replace "this document" with the document RFC number at time of publication, and remove this note. 12. Acknowledgments The authors would like to acknowledge Eddie Chami, Nagendra Kumar, Mannan Venkatesan, and Pavan Beeram for their contribution to this document. Raza, et al. Expires September 21, 2020 [Page 83] Internet-Draft YANG Data Model for MPLS LDP March 2020 We also acknowledge Ladislav Lhotka, Jan Lindblad, Tom Petch, Yingzhen Qu, and Benjamin Kaduk for their detailed review of the model during WG and IESG. 13. Contributors Danial Johari Cisco Systems Email: dajohari@cisco.com Loa Andersson Huawei Technologies Email: loa@pi.nu Jeff Tantsura Apstra Email: jefftant.ietf@gmail.com Matthew Bocci Nokia Email: matthew.bocci@nokia.com Reshad Rahman Cisco Systems Email: rrahman@cisco.com Stephane Litkowski Cisco Systems Email: slitkows@cisco.com 14. Normative References [I-D.ietf-rtgwg-policy-model] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data Model for Routing Policy Management", Work in Progress, Internet-Draft, draft-ietf-rtgwg-policy-model-09, 4 March 2020, . [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, DOI 10.17487/RFC3478, February 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, Raza, et al. Expires September 21, 2020 [Page 84] Internet-Draft YANG Data Model for MPLS LDP March 2020 DOI 10.17487/RFC3688, January 2004, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, . [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, . [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, . [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, DOI 10.17487/RFC5918, August 2010, . [RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, DOI 10.17487/RFC5919, August 2010, . [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . Raza, et al. Expires September 21, 2020 [Page 85] Internet-Draft YANG Data Model for MPLS LDP March 2020 [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, . [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. Papneja, "Updates to LDP for IPv6", RFC 7552, DOI 10.17487/RFC7552, June 2015, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . Raza, et al. Expires September 21, 2020 [Page 86] Internet-Draft YANG Data Model for MPLS LDP March 2020 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, . 15. Informative References [I-D.ietf-mpls-mldp-yang] Raza, K., Liu, X., Esale, S., Andersson, L., Tantsura, J., and S. Krishnaswamy, "YANG Data Model for MPLS mLDP", Work in Progress, Internet-Draft, draft-ietf-mpls-mldp-yang-06, 31 May 2019, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. King, "LDP Extensions for Multi-Topology", RFC 7307, DOI 10.17487/RFC7307, July 2014, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . Raza, et al. Expires September 21, 2020 [Page 87] Internet-Draft YANG Data Model for MPLS LDP March 2020 Appendix A. Data Tree Example This section contains an example of an instance data tree in the JSON encoding [RFC7951], containing both configuration and state data. +---------------------+ | | | Router 203.0.113.1 | | | +----------+----------+ |eth1 |2001:db8:0:1::1/64 | | |2001:db8:0:1::2/64 +----------+----------+ | | | | Another Router +---------| 2001:db8:0:2::/64 | | | +---------------------+ Figure 12: Example topology The configuration instance data tree for Router 203.0.113.1 in the above figure could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1", "description": "An interface with LDP enabled.", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:1::1", "prefix-length": 64 } ], "forwarding": true } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.1", "control-plane-protocols": { Raza, et al. Expires September 21, 2020 [Page 88] Internet-Draft YANG Data Model for MPLS LDP March 2020 "control-plane-protocol": [ { "type": "ietf-mpls-ldp:mpls-ldp", "name": "ldp-1", "ietf-mpls-ldp:mpls-ldp": { "global": { "address-families": { "ietf-mpls-ldp-extended:ipv6": { "enabled": true, "transport-address": "2001:db8:0:1::1" } } }, "discovery": { "interfaces": { "interface": [ { "name": "eth1", "address-families": { "ietf-mpls-ldp-extended:ipv6": { "enabled": true } } } ] } } } } ] } } } Figure 13: Example Configuration data in JSON The corresponding operational state data for Router 203.0.113.1 could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1", "description": "An interface with LDP enabled.", "type": "iana-if-type:ethernetCsmacd", "phys-address": "00:00:5e:00:53:01", Raza, et al. Expires September 21, 2020 [Page 89] Internet-Draft YANG Data Model for MPLS LDP March 2020 "oper-status": "up", "statistics": { "discontinuity-time": "2018-09-10T15:16:27-05:00" }, "ietf-ip:ipv6": { "forwarding": true, "mtu": 1500, "address": [ { "ip": "2001:db8:0:1::1", "prefix-length": 64, "origin": "static", "status": "preferred" }, { "ip": "fe80::200:5eff:fe00:5301", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ { "ip": "2001:db8:0:1::2", "link-layer-address": "00:00:5e:00:53:02", "origin": "dynamic", "is-router": [null], "state": "reachable" }, { "ip": "fe80::200:5eff:fe00:5302", "link-layer-address": "00:00:5e:00:53:02", "origin": "dynamic", "is-router": [null], "state": "reachable" } ] } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.1", "interfaces": { "interface": [ "eth1" ] }, Raza, et al. Expires September 21, 2020 [Page 90] Internet-Draft YANG Data Model for MPLS LDP March 2020 "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-mpls-ldp:mpls-ldp", "name": "ldp-1", "ietf-mpls-ldp:mpls-ldp": { "global": { "address-families": { "ietf-mpls-ldp-extended:ipv6": { "enabled": true, "transport-address": "2001:db8:0:1::1" } } }, "discovery": { "interfaces": { "interface": [ { "name": "eth1", "address-families": { "ietf-mpls-ldp-extended:ipv6": { "enabled": true, "hello-adjacencies": { "hello-adjacency": [ { "adjacent-address": "fe80::200:5eff:fe00:5302", "flag": ["adjacency-flag-active"], "hello-holdtime": { "adjacent": 15, "negotiated": 15, "remaining": 9 }, "next-hello": 3, "statistics": { "discontinuity-time": "2018-09-10T15:16:27-05:00" }, "peer": { "lsr-id": "203.0.113.2", "label-space-id": 0 } } ] } } } } Raza, et al. Expires September 21, 2020 [Page 91] Internet-Draft YANG Data Model for MPLS LDP March 2020 ] } }, "peers": { "peer": [ { "lsr-id": "203.0.113.2", "label-space-id": 0, "label-advertisement-mode": { "local": "downstream-unsolicited", "peer": "downstream-unsolicited", "negotiated": "downstream-unsolicited" }, "next-keep-alive": 5, "session-holdtime": { "peer": 180, "negotiated": 180, "remaining": 78 }, "session-state": "operational", "tcp-connection": { "local-address": "fe80::200:5eff:fe00:5301", "local-port": 646, "remote-address": "fe80::200:5eff:fe00:5302", "remote-port": 646 }, "up-time": 3438100, "statistics": { "discontinuity-time": "2018-09-10T15:16:27-05:00" } } ] } } } ] } } } Figure 14: Example Operational data in JSON Authors' Addresses Kamran Raza (editor) Cisco Systems Raza, et al. Expires September 21, 2020 [Page 92] Internet-Draft YANG Data Model for MPLS LDP March 2020 Canada Email: skraza@cisco.com Rajiv Asati Cisco Systems United States of America Email: rajiva@cisco.com Xufeng Liu Volta Networks United States of America Email: xufeng.liu.ietf@gmail.com Santosh Esale Juniper Networks United States of America Email: sesale@juniper.net Xia Chen Huawei Technologies China Email: jescia.chenxia@huawei.com Himanshu Shah Ciena Corporation United States of America Email: hshah@ciena.com Raza, et al. Expires September 21, 2020 [Page 93] ./draft-ietf-mpls-sfl-framework-11.txt0000644000764400076440000005441513735675262017133 0ustar iustyiusty MPLS Working Group S. Bryant Internet-Draft Futurewei Technologies Inc Intended status: Standards Track M. Chen Expires: April 5, 2021 Huawei G. Swallow Southend Technical Center S. Sivabalan Ciena Corporation G. Mirsky ZTE Corp. October 02, 2020 Synonymous Flow Label Framework draft-ietf-mpls-sfl-framework-11 Abstract RFC 8372 (MPLS Flow Identification Considerations) describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called Synonymous Flow Labels in which labels which mimic the behaviour of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 5, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Bryant, et al. Expires April 5, 2021 [Page 1] Internet-Draft MPLS FL October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Synonymous Flow Labels . . . . . . . . . . . . . . . . . . . 3 4. User Service Traffic in the Data Plane . . . . . . . . . . . 4 4.1. Application Label Present . . . . . . . . . . . . . . . . 4 4.1.1. Setting TTL and the Traffic Class Bits . . . . . . . 5 4.2. Single Label Stack . . . . . . . . . . . . . . . . . . . 5 4.2.1. Setting TTL and the Traffic Class Bits . . . . . . . 6 4.3. Aggregation of SFL Actions . . . . . . . . . . . . . . . 6 5. Equal Cost Multipath Considerations . . . . . . . . . . . . . 7 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [RFC8372] (MPLS Flow Identification Considerations) describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of providing the required identification by using a technique called Synonymous Flow Labels (SFL) in which labels which mimic the behaviour of other MPLS labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP Bryant, et al. Expires April 5, 2021 [Page 2] Internet-Draft MPLS FL October 2020 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Synonymous Flow Labels An SFL is defined to be a label that causes exactly the same behaviour at the egress Label Edge Router (LER) as the label it replaces, except that it also causes one or more additional actions that have been previously agreed between the peer LERs to be executed on the packet. There are many possible additional actions such as the measurement of the number of received packets in a flow, triggering an IP Flow Information Export (IPFIX) [RFC7011] capture, triggering other types of Deep Packet Inspection, or identification of the packet source. In, for example, a Performance Monitoring (PM) application, the agreed action could be the recording of the receipt of the packet by incrementing a packet counter. This is a natural action in many MPLS implementations, and where supported this permits the implementation of high quality packet loss measurement without any change to the packet forwarding system. To illustrate the use of this technology, we start by considering the case where there is an "application" label in the MPLS label stack. As a first example, let us consider a pseudowire (PW) [RFC3985] on which it is desired to make packet loss measurements. Two labels, synonymous with the PW labels, are obtained from the egress terminating provider edge (T-PE). By alternating between these SFLs and using them in place of the PW label, the PW packets may be batched for counting without any impact on the PW forwarding behavior [RFC8321] (note that strictly only one SFL is needed in this application, but that is an optimization that is a matter for the implementor). The method of obtaining these additional labels is outside the scope of this text, however, one control protocol that provides a method of obtaining SFLs is described in [I-D.bryant-mpls-sfl-control]. Now consider an MPLS application that is multi-point to point such as a VPN. Here it is necessary to identify a packet batch from a specific source. This is achieved by making the SFLs source specific, so that batches from one source are marked differently from batches from another source. The sources all operate independently and asynchronously from each other, independently coordinating with the destination. Each ingress LER is thus able to establish its own SFL to identify the sub-flow and thus enable PM per flow. Finally we need to consider the case where there is no MPLS application label such as occurs when sending IP over an LSP, i.e. there is a single label in the MPLS label stack. In this case introducing an SFL that was synonymous with the LSP label would Bryant, et al. Expires April 5, 2021 [Page 3] Internet-Draft MPLS FL October 2020 introduce network-wide forwarding state. This would not be acceptable for scaling reasons. We therefore have no choice but to introduce an additional label. Where penultimate hop popping (PHP) is in use, the semantics of this additional label can be similar to the LSP label. Where PHP is not in use, the semantics are similar to an MPLS explicit NULL [RFC3032]. In both of these cases the label has the additional semantics of the SFL. Note that to achieve the goals set out above, SFLs need to be allocated from the platform label table. 4. User Service Traffic in the Data Plane As noted in Section 3 it is necessary to consider two cases: 1. Application label is present 2. Single label stack 4.1. Application Label Present Figure 1 shows the case in which both an LSP label and an application label are present in the MPLS label stack. Traffic with no SFL function present runs over the "normal" stack, and SFL-enabled flows run over the SFL stack with the SFL used to indicate the packet batch. +-----------------+ +-----------------+ | LSP | | LSP | | Label | | Label | | (May be PHPed) | | (May be PHPed) | +-----------------+ +-----------------+ | | | | | Application | | Synonymous Flow | | Label | | Label | +-----------------+ <= BoS +-----------------+ <= Bottom of stack | | | | | Payload | | Payload | | | | | +-----------------+ +-----------------+ "Normal" Label Stack Label Stack with SFL Figure 1: Use of Synonymous Labels In A Two Label MPLS Label Stack Bryant, et al. Expires April 5, 2021 [Page 4] Internet-Draft MPLS FL October 2020 At the egress LER the LSP label is popped (if present). Then the SFL is processed executing both the synonymous function and the corresponding application function. 4.1.1. Setting TTL and the Traffic Class Bits The TTL and the Traffic Class bits [RFC5462] in the SFL label stack entry (LSE) would normally be set to the same value as would have been set in the label that the SFL is synonymous with. However, it is recognized that if there is an application need these fields in the SFL Label Stack Entry (LSE) MAY be set these to some other value. An example would be where it was desired to cause the SFL to trigger an action in the TTL expiry exception path as part of the label action. 4.2. Single Label Stack Figure 2 shows the case in which only an LSP label is present in the MPLS label stack. Traffic with no SFL function present runs over the "normal" stack and SFL-enabled flows run over the SFL stack with the SFL used to indicate the packet batch. However in this case it is necessary for the ingress Label Edge Router (LER) to first push the SFL and then to push the LSP label. +-----------------+ | LSP | | Label | | (May be PHPed) | +-----------------+ +-----------------+ | LSP | | | <= Synonymous with | Label | | Synonymous Flow | Explicit NULL | (May be PHPed) | | Label | +-----------------+ <= BoS +-----------------+ <= Bottom of stack | | | | | Payload | | Payload | | | | | +-----------------+ +-----------------+ "Normal" Label Stack Label Stack with SFL Figure 2: Use of Synonymous Labels In A Single Label MPLS Label Stack At the receiving Label Switching Router (LSR) it is necessary to consider two cases: 1. Where the LSP label is still present Bryant, et al. Expires April 5, 2021 [Page 5] Internet-Draft MPLS FL October 2020 2. Where the LSP label is penultimate hop popped If the LSP label is present, it is processed exactly as it would normally processed and then it is popped. This reveals the SFL, which, in the case of [RFC6374] measurements, is simply counted and then discarded. In this respect the processing of the SFL is synonymous with an MPLS Explicit NULL. As the SFL is the bottom of stack, the IP packet that follows is processed as normal. If the LSP label is not present due to PHP action in the upstream LSR, two almost equivalent processing actions can take place. Either the SFL can be treated as an LSP label that was not PHPed and the additional associated SFL action is taken when the label is processed. Alternatively, it can be treated as an MPLS Explicit NULL with associated SFL actions. From the perspective of the measurement system described in this document the behaviour of the two approaches is indistinguishable and thus either may be implemented. 4.2.1. Setting TTL and the Traffic Class Bits The TTL and the Traffic Class considerations described in Section 4.1.1 apply. 4.3. Aggregation of SFL Actions There are cases where it is desirable to aggregate an SFL action against a number of labels. For example, where it is desirable to have one counter record the number of packets received over a group of application labels, or where the number of labels used by a single application is large, and the resultant increase in the number of allocated labels needed to support the SFL actions may becomes too large to be viable. In these circumstances it would be necessary to introduce an additional label in the stack to act as an aggregate instruction. This is not strictly a synonymous action in that the SFL is not replacing an existing label, but is somewhat similar to the single label case shown in Section 4.2, and the same signalling, management and configuration tools would be applicable. Bryant, et al. Expires April 5, 2021 [Page 6] Internet-Draft MPLS FL October 2020 +-----------------+ | LSP | | Label | | (May be PHPed) | +-----------------+ +-----------------+ | LSP | | | | Label | | Aggregate | | (May be PHPed) | | SFL | +-----------------+ +-----------------+ | | | | | Application | | Application | | Label | | Label | +-----------------+ <=BoS +-----------------+ <= Bottom of stack | | | | | Payload | | Payload | | | | | +-----------------+ +-----------------+ "Normal" Label Stack Label Stack with SFL Figure 3: Aggregate SFL Actions The Aggregate SFL is shown in the label stack depicted in Figure 3 as preceding the application label, however the choice of position before, or after, the application label will be application specific. In the case described in Section 4.1, by definition the SFL has the full application context. In this case the positioning will depend on whether the SFL action needs the full context of the application to perform its action and whether the complexity of the application will be increased by finding an SFL following the application label. 5. Equal Cost Multipath Considerations The introduction of an SFL to an existing flow may cause that flow to take a different path through the network under conditions of Equal Cost Multi-path (ECMP). This in turn may invalidate certain uses of the SFL such as performance measurement applications. Where this is a problem there are two solutions worthy of consideration: 1. The operator MAY elect to always run with the SFL in place in the MPLS label stack. 2. The operator can elect to use [RFC6790] Entropy Labels in a network that fully supports this type of ECMP. If this approach is adopted, the intervening MPLS network MUST NOT load balance on any packet field other than the entropy label. Note that this is stricter than the text in Section 4.3 of [RFC6790]. Bryant, et al. Expires April 5, 2021 [Page 7] Internet-Draft MPLS FL October 2020 6. Privacy Considerations IETF concerns on pervasive monitoring are described in [RFC7258]. The inclusion of originating and/or flow information in a packet provides more identity information and hence potentially degrades the privacy of the communication to an attacker in a position to observe the added identifier. Whilst the inclusion of the additional granularity does allow greater insight into the flow characteristics it does not specifically identify which node originated the packet unless the attacker can inspect the network at the point of ingress, or inspection of the control protocol packets. This privacy threat may be mitigated by encrypting the control protocol packets, by regularly changing the synonymous labels or by concurrently using a number of such labels, including the use of a combination of those methods. Minimizing the scope of the identity indication can be useful in minimizing the observability of the flow characteristics. Whenever IPFIX or other DPI technique is used, their relavent privacy considerations apply. 7. Security Considerations There are no new security issues associated with the MPLS data plane. Any control protocol used to request SFLs will need to ensure the legitimacy of the request, i.e. that the requesting node is authorized to make that SFL request by the network operator. 8. IANA Considerations This draft makes no IANA requests. 9. Contributing Authors Zhenbin Li Huawei Email: lizhenbin@huawei.com 10. References 10.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, . Bryant, et al. Expires April 5, 2021 [Page 8] Internet-Draft MPLS FL October 2020 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [I-D.bryant-mpls-sfl-control] Bryant, S., Swallow, G., and S. Sivabalan, "A Simple Control Protocol for MPLS SFLs", draft-bryant-mpls-sfl- control-08 (work in progress), June 2020. [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . Bryant, et al. Expires April 5, 2021 [Page 9] Internet-Draft MPLS FL October 2020 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, . [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. Mirsky, "MPLS Flow Identification Considerations", RFC 8372, DOI 10.17487/RFC8372, May 2018, . Authors' Addresses Stewart Bryant Futurewei Technologies Inc Email: sb@stewartbryant.com Mach Chen Huawei Email: mach.chen@huawei.com George Swallow Southend Technical Center Email: swallow.ietf@gmail.com Siva Sivabalan Ciena Corporation Email: ssivabal@ciena.com Gregory Mirsky ZTE Corp. Email: gregimirsky@gmail.com Bryant, et al. Expires April 5, 2021 [Page 10] ./draft-ietf-netmod-module-tags-10.txt0000644000764400076440000011054513626620541017071 0ustar iustyiusty Network Working Group C. Hopps Internet-Draft LabN Consulting, L.L.C. Updates: 8407 (if approved) L. Berger Intended status: Standards Track LabN Consulting, LLC. Expires: September 1, 2020 D. Bogdanovic Volta Networks February 29, 2020 YANG Module Tags draft-ietf-netmod-module-tags-10 Abstract This document provides for the association of tags with YANG modules. The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading and writing a modules tags is provided. Tags may be registered and assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC8407. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 1, 2020. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Hopps, et al. Expires September 1, 2020 [Page 1] Internet-Draft YANG Module Tags February 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Some possible use cases for YANG module tags . . . . . . 3 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 2. Tag Values . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. IETF Tags . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Vendor Tags . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. User Tags . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Reserved Tags . . . . . . . . . . . . . . . . . . . . . . 5 3. Tag Management . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Module Definition Tagging . . . . . . . . . . . . . . . . 5 3.2. Implementation Tagging . . . . . . . . . . . . . . . . . 5 3.3. User Tagging . . . . . . . . . . . . . . . . . . . . . . 5 4. Tags Module Structure . . . . . . . . . . . . . . . . . . . . 6 4.1. Tags Module Tree . . . . . . . . . . . . . . . . . . . . 6 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 5. Other Classifications . . . . . . . . . . . . . . . . . . . . 9 6. Guidelines to Model Writers . . . . . . . . . . . . . . . . . 9 6.1. Define Standard Tags . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.1. YANG Module Tag Prefixes Registry . . . . . . . . . . . . 9 7.2. IETF YANG Module Tags Registry . . . . . . . . . . . . . 10 7.3. Updates to the IETF XML Registry . . . . . . . . . . . . 12 7.4. Updates to the YANG Module Names Registry . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix C. Non-NMDA State Module. . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The use of tags for classification and organization is fairly ubiquitous not only within IETF protocols, but in the internet itself (e.g., "#hashtags"). One benefit of using tags for organization over a rigid structure is that it is more flexible and can more easily adapt over time as technologies evolve. Tags can be usefully registered, but they can also serve as a non-registered mechanism Hopps, et al. Expires September 1, 2020 [Page 2] Internet-Draft YANG Module Tags February 2020 available for users to define themselves. This document provides a mechanism to define tags and associate them with YANG modules in a flexible manner. In particular, tags may be registered as well as assigned during module definition; assigned by implementations; or dynamically defined and set by users. This document defines a YANG module [RFC7950] which provides a list of module entries to allow for adding or removing of tags as well as viewing the set of tags associated with a module. This document defines an extension statement to be used to indicate tags that SHOULD be added by the module implementation automatically (i.e., outside of configuration). This document also defines an IANA registry for tag prefixes as well as a set of globally assigned tags. Section 6 provides guidelines for authors of YANG data models. This document updates [RFC8407]. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in [RFC8342]. 1.1. Some possible use cases for YANG module tags During this documents's development there were requests for example uses of module tags. The following are a few example use cases for tags. This list is certainly not exhaustive. One example use of tags would be to help filter different discrete categories of YANG modules supported by a device. For example, if modules are suitably tagged, then an XPath query can be used to list all of the vendor modules supported by a device. Tags can also be used to help coordination when multiple semi- independent clients are interacting with the same devices. For example, one management client could mark that some modules should not be used because they have not been verified to behave correctly, so that other management clients avoid querying the data associated with those modules. Tag classification is useful for users searching module repositories (e.g., YANG catalog). A query restricted to the 'ietf:routing' module tag could be used to return only the IETF YANG modules associated with routing. Without tags, a user would need to know the name of all the IETF routing protocol YANG modules. Hopps, et al. Expires September 1, 2020 [Page 3] Internet-Draft YANG Module Tags February 2020 Future management protocol extensions could allow for filtering queries of configuration or operational state on a server based on tags. For example, return all operational state related to system- management. 1.2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Tag Values All tags SHOULD begin with a prefix indicating who owns their definition. An IANA registry (Section 7.1) is used to support registering tag prefixes. Currently 3 prefixes are defined. No further structure is imposed by this document on the value following the registered prefix, and the value can contain any YANG type 'string' characters except carriage-returns, newlines and tabs. Again, except for the conflict-avoiding prefix, this document is not specifying any structure on (i.e., restricting) the tag values on purpose. The intent is to avoid arbitrarily restricting the values that designers, implementers and users can use. As a result of this choice, designers, implementers, and users are free to add or not add any structure they may require to their own tag values. 2.1. IETF Tags An IETF tag is a tag that has the prefix "ietf:". All IETF tags are registered with IANA in a registry defined later in this document (Section 7.2). 2.2. Vendor Tags A vendor tag is a tag that has the prefix "vendor:". These tags are defined by the vendor that implements the module, and are not registered; however, it is RECOMMENDED that the vendor include extra identification in the tag to avoid collisions such as using the enterpise or organization name following the "vendor:" prefix (e.g., vendor:example.com:vendor-defined-classifier). Hopps, et al. Expires September 1, 2020 [Page 4] Internet-Draft YANG Module Tags February 2020 2.3. User Tags A user tag is any tag that has the prefix "user:". These tags are defined by the user/administrator and are not meant to be registered. Users are not required to use the "user:" prefix; however, doing so is RECOMMENDED as it helps avoid collisions. 2.4. Reserved Tags Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is reserved for future use. These tag values are not invalid, but simply reserved in the context of specifications (e.g., RFCs). 3. Tag Management Tags can become associated with a module in a number of ways. Tags may be defined and associated at module design time, at implementation time, or via user administrative control. As the main consumer of tags are users, users may also remove any tag, no matter how the tag became associated with a module. 3.1. Module Definition Tagging A module definition MAY indicate a set of tags to be added by the module implementer. These design time tags are indicated using the module-tag extension statement. If the module is defined in an IETF standards track document, the tags MUST be IETF Tags (2.1). Thus, new modules can drive the addition of new IETF tags to the IANA registry defined in Section 7.2, and the IANA registry can serve as a check against duplication. 3.2. Implementation Tagging An implementation MAY include additional tags associated with a module. These tags SHOULD be IETF Tags (i.e., registered) or vendor specific tags. 3.3. User Tagging Tags of any kind, with or without a prefix, can be assigned and removed by the user using normal configuration mechanisms. In order to remove a tag from the operational datastore the user adds a matching "masked-tag" entry for a given module. Hopps, et al. Expires September 1, 2020 [Page 5] Internet-Draft YANG Module Tags February 2020 4. Tags Module Structure 4.1. Tags Module Tree The tree associated with the "ietf-module-tags" module follows. The meaning of the symbols can be found in [RFC8340]. module: ietf-module-tags +--rw module-tags +--rw module* [name] +--rw name yang:yang-identifier +--rw tag* tag +--rw masked-tag* tag Figure 1: YANG Module Tags Tree Diagram 4.2. YANG Module file "ietf-module-tags@2020-02-29.yang" module ietf-module-tags { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; prefix tags; import ietf-yang-types { prefix yang; } organization "IETF NetMod Working Group (NetMod)"; contact "WG Web: WG List: Author: Christian Hopps Author: Lou Berger Author: Dean Bogdanovic "; // RFC Ed.: replace XXXX with actual RFC number and // remove this note. description "This module describes a mechanism associating tags with YANG Hopps, et al. Expires September 1, 2020 [Page 6] Internet-Draft YANG Module Tags February 2020 modules. Tags may be IANA assigned or privately defined. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; // RFC Ed.: update the date below with the date of RFC publication // and RFC number and remove this note. revision 2020-02-29 { description "Initial revision."; reference "RFC XXXX: YANG Module Tags"; } typedef tag { type string { length "1..max"; pattern '[\S ]+'; } description "A tag is a type 'string' value that does not include carriage return, newline or tab characters. It SHOULD begin with a registered prefix; however, tags without a registered prefix SHOULD NOT be treated as invalid."; } extension module-tag { argument tag; description "The argument 'tag' is of type 'tag'. This extension statement is used by module authors to indicate the tags that SHOULD be Hopps, et al. Expires September 1, 2020 [Page 7] Internet-Draft YANG Module Tags February 2020 added automatically by the system. As such the origin of the value for the pre-defined tags should be set to 'system' [RFC8342]."; } container module-tags { description "Contains the list of modules and their associated tags"; list module { key "name"; description "A list of modules and their associated tags"; leaf name { type yang:yang-identifier; mandatory true; description "The YANG module name."; } leaf-list tag { type tag; description "Tags associated with the module. See the IANA 'YANG Module Tag Prefixes' registry for reserved prefixes and the IANA 'IETF YANG Module Tags' registry for IETF tags. The 'operational' state [RFC8342] view of this list is constructed using the following steps: 1) System tags (i.e., tags of 'system' origin) are added. 2) User configured tags (i.e., tags of 'intended' origin) are added. 3) Any tag that is equal to a masked-tag is removed."; } leaf-list masked-tag { type tag; description "The list of tags that should not be associated with this module. The user can remove (mask) tags from the operational state datastore [RFC8342] by adding them to this list. It is not an error to add tags to this list that are not associated with the module, but they have no operational effect."; } } } } Hopps, et al. Expires September 1, 2020 [Page 8] Internet-Draft YANG Module Tags February 2020 Figure 2: Module Tags Module 5. Other Classifications It is worth noting that a different YANG module classification document exists [RFC8199]. That document only classifies modules in a logical manner and does not define tagging or any other mechanisms. It divides YANG modules into two categories (service or element) and then into one of three origins: standard, vendor or user. It does provide a good way to discuss and identify modules in general. This document defines IETF tags to support [RFC8199] style classification. 6. Guidelines to Model Writers This section updates [RFC8407]. 6.1. Define Standard Tags A module MAY indicate, using module-tag extension statements, a set of tags that are to be automatically associated with it (i.e., not added through configuration). module example-module { //... import module-tags { prefix tags; } tags:module-tag "ietf:some-new-tag"; tags:module-tag "ietf:some-other-tag"; // ... } The module writer can use existing standard tags, or use new tags defined in the model definition, as appropriate. For IETF standardized modules new tags MUST be assigned in the IANA registry defined below, see Section 7.2. 7. IANA Considerations 7.1. YANG Module Tag Prefixes Registry IANA is asked to create a new registry "YANG Module Tag Prefixes" grouped under a new "Protocol" category named "YANG Module Tags". This registry allocates tag prefixes. All YANG module tags SHOULD begin with one of the prefixes in this registry. Prefix entries in this registry should be short strings consisting of lowercase ASCII alpha-numeric characters and a final ":" character. Hopps, et al. Expires September 1, 2020 [Page 9] Internet-Draft YANG Module Tags February 2020 The allocation policy for this registry is Specification Required [RFC8126]. The Reference and Assignee values should be sufficient to identify and contact the organization that has been allocated the prefix. The initial values for this registry are as follows. +---------+----------------------------------+-----------+----------+ | Prefix | Description | Reference | Assignee | +---------+----------------------------------+-----------+----------+ | ietf: | IETF Tags allocated in the IANA | [This | IETF | | | IETF YANG Module Tags registry. | document] | | | | | | | | vendor: | Non-registered tags allocated by | [This | IETF | | | the module implementer. | document] | | | | | | | | user: | Non-registered tags allocated by | [This | IETF | | | and for the user. | document] | | +---------+----------------------------------+-----------+----------+ Other standards organizations (SDOs) wishing to allocate their own set of tags should allocate a prefix from this registry. 7.2. IETF YANG Module Tags Registry IANA is asked to create a new registry "IETF YANG Module Tags" grouped under a new "Protocol" category "IETF YANG Module Tags". This registry should be included below "YANG Module Tag Prefixes" when listed on the same page. This registry allocates tags that have the registered prefix "ietf:". New values should be well considered and not achievable through a combination of already existing IETF tags. IANA assigned tags must conform to Net-Unicode as defined in [RFC5198] and they shall not need normalization. The allocation policy for this registry is IETF Review [RFC8126]. The initial values for this registry are as follows. +----------------------------+--------------------------+-----------+ | Tag | Description | Reference | +----------------------------+--------------------------+-----------+ | ietf:network-element-class | [RFC8199] network | [RFC8199] | | | element. | | | | | | | ietf:network-service-class | [RFC8199] network | [RFC8199] | | | service. | | Hopps, et al. Expires September 1, 2020 [Page 10] Internet-Draft YANG Module Tags February 2020 | | | | | ietf:sdo-defined-class | Module is defined by a | [RFC8199] | | | standards organization. | | | | | | | ietf:vendor-defined-class | Module is defined by a | [RFC8199] | | | vendor. | | | | | | | ietf:user-defined-class | Module is defined by the | [RFC8199] | | | user. | | | | | | | ietf:hardware | Relates to hardware | [This | | | (e.g., inventory). | document] | | | | | | ietf:software | Relates to software | [This | | | (e.g., installed OS). | document] | | | | | | ietf:protocol | Represents a protocol | [This | | | (often combined with | document] | | | another tag to refine). | | | | | | | ietf:qos | Relates to quality of | [This | | | service. | document] | | | | | | ietf:network-service-app | Relates to a network | [This | | | service application | document] | | | (e.g., an NTP server, | | | | DNS server, DHCP server, | | | | etc). | | | | | | | ietf:system-management | Relates to system | [This | | | management (e.g., a | document] | | | system management | | | | protocol such as syslog, | | | | TACAC+, SNMP, netconf, | | | | ...). | | | | | | | ietf:oam | Relates to Operations, | [This | | | Administration, and | document] | | | Maintenance (e.g., BFD). | | | | | | | ietf:routing | Relates to routing. | [This | | | | document] | | | | | | ietf:security | Related to security. | [This | | | | document] | | | | | | ietf:signaling | Relates to control plane | [This | | | signaling. | document] | Hopps, et al. Expires September 1, 2020 [Page 11] Internet-Draft YANG Module Tags February 2020 | | | | | ietf:link-management | Relates to link | [This | | | management. | document] | +----------------------------+--------------------------+-----------+ 7.3. Updates to the IETF XML Registry This document registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in [RFC3688], the following registrations have been made: URI: urn:ietf:params:xml:ns:yang:ietf-module-tags Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-module-tags-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. 7.4. Updates to the YANG Module Names Registry This document registers two YANG modules in the "YANG Module Names" registry [RFC6020]. Following the format in [RFC6020], the following registration have been made: name: ietf-module-tags namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags prefix: tags reference: RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove this note.) Hopps, et al. Expires September 1, 2020 [Page 12] Internet-Draft YANG Module Tags February 2020 name: ietf-module-tags-state namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags-state prefix: tags reference: RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove this note.) 8. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. This document adds the ability to associate tag meta-data with YANG modules. This document does not define any actions based on these associations, and none are yet defined, and therefore it does not by itself introduce any new security considerations directly. Users of the tag-meta data may define various actions to be taken based on the tag meta-data. These actions and their definitions are outside the scope of this document. Users will need to consider the security implications of any actions they choose to define, including the potential for a tag to get 'masked' by another user. 9. References 9.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, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Hopps, et al. Expires September 1, 2020 [Page 13] Internet-Draft YANG Module Tags February 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, . 9.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . Hopps, et al. Expires September 1, 2020 [Page 14] Internet-Draft YANG Module Tags February 2020 Appendix A. Examples The following is a fictional NETCONF example result from a query of the module tags list. For the sake of brevity only a few module results are imagined. ietf-bfd ietf:network-element-class ietf:oam ietf:protocol ietf:sdo-defined-class ietf-isis ietf:network-element-class ietf:protocol ietf:sdo-defined-class ietf:routing ietf-ssh-server ietf:network-element-class ietf:protocol ietf:sdo-defined-class ietf:system-management Figure 3: Example NETCONF Query Output Appendix B. Acknowledgements Special thanks to Robert Wilton for his help improving the introduction and providing the example use cases, as well as generating the non-NMDA module. Appendix C. Non-NMDA State Module. As per [RFC8407] the following is a non-NMDA module to support viewing the operational state for non-NMDA compliant servers. file "ietf-module-tags-state@2020-02-29.yang" module ietf-module-tags-state { yang-version 1.1; Hopps, et al. Expires September 1, 2020 [Page 15] Internet-Draft YANG Module Tags February 2020 namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state"; prefix tags-s; import ietf-yang-types { prefix yang; } import ietf-module-tags { prefix tags; } organization "IETF NetMod Working Group (NetMod)"; contact "WG Web: WG List: Author: Christian Hopps Author: Lou Berger Author: Dean Bogdanovic "; // RFC Ed.: replace XXXX with actual RFC number and // remove this note. description "This module describes a mechanism associating tags with YANG modules. Tags may be IANA assigned or privately defined. This is a temporary non-NMDA module that is for use by implementations that don't yet support NMDA. Copyright (c) 2019 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. Hopps, et al. Expires September 1, 2020 [Page 16] Internet-Draft YANG Module Tags February 2020 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; // RFC Ed.: update the date below with the date of RFC publication // and RFC number and remove this note. revision 2020-02-29 { description "Initial revision."; reference "RFC XXXX: YANG Module Tags"; } container module-tags-state { config false; status deprecated; description "Contains the list of modules and their associated tags"; list module { key "name"; status deprecated; description "A list of modules and their associated tags"; leaf name { type yang:yang-identifier; mandatory true; status deprecated; description "The YANG module name."; } leaf-list tag { type tags:tag; status deprecated; description "Tags associated with the module. See the IANA 'YANG Module Tag Prefixes' registry for reserved prefixes and the IANA 'IETF YANG Module Tags' registry for IETF tags. The contents of this list is constructed using the following steps: 1) System tags (i.e., tags of added by the system) are added. 2) User configured tags (i.e., tags added by configuration) are added. 3) Any tag that is equal to a masked-tag present in the Hopps, et al. Expires September 1, 2020 [Page 17] Internet-Draft YANG Module Tags February 2020 corresponding ietf-module-tags:module-tags:module-tag leaf list for this module is removed."; } } } } Figure 4: Non-NMDA Module Tags State Module Authors' Addresses Christian Hopps LabN Consulting, L.L.C. Email: chopps@chopps.org Lou Berger LabN Consulting, LLC. Email: lberger@labn.net Dean Bogdanovic Volta Networks Email: ivandean@gmail.com Hopps, et al. Expires September 1, 2020 [Page 18] ./draft-ietf-netmod-syslog-model-26.txt0000644000764400076440000017775313252706170017311 0ustar iustyiusty NETMOD WG C. Wildes, Ed. Internet-Draft Cisco Systems Inc. Intended status: Standards Track K. Koushik, Ed. Expires: September 14, 2018 Verizon Wireless March 15, 2018 A YANG Data Model for Syslog Configuration draft-ietf-netmod-syslog-model-26 Abstract This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2018. Copyright Notice Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. NDMA Compliance . . . . . . . . . . . . . . . . . . . . . 3 Wildes & Koushik Expires September 14, 2018 [Page 1] Internet-Draft Syslog Management March 2018 1.4. Editorial Note (To be removed by RFC Editor) . . . . . . . 3 2. Design of the Syslog Model . . . . . . . . . . . . . . . . . . 3 2.1. Syslog Module . . . . . . . . . . . . . . . . . . . . . . 5 3. Syslog YANG Module . . . . . . . . . . . . . . . . . . . . . . 7 3.1. The ietf-syslog Module . . . . . . . . . . . . . . . . . . 8 4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 26 6.2. The YANG Module Names Registry . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Implementer Guidelines . . . . . . . . . . . . . . . . 29 Appendix A.1. Extending Facilities . . . . . . . . . . . . . . 29 Appendix A.2. Syslog Terminal Output . . . . . . . . . . . . . 30 Appendix A.3. Syslog File Naming Convention . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document defines a YANG [RFC7950] configuration data model that may be used to configure the syslog feature running on a system. YANG models can be used with network management protocols such as NETCONF [RFC6241] to install, manipulate, and delete the configuration of network devices. The data model makes use of the YANG "feature" construct which allows implementations to support only those syslog features that lie within their capabilities. This module can be used to configure the syslog application conceptual layers as implemented on the target system. Essentially, a syslog process receives messages (from the kernel, processes, applications or other syslog processes) and processes them. The processing may involve logging to a local file, and/or displaying on console, and/or relaying to syslog processes on other machines. The processing is determined by the "facility" that originated the message and the "severity" assigned to the message by the facility. Such definitions of syslog protocol are defined in [RFC5424], and are used in this RFC. The YANG model in this document conforms to the Network Management Datastore Architecture defined in [draft-ietf-netmod-revised- datastores]. 1.1. Requirements Language Wildes & Koushik Expires September 14, 2018 [Page 2] Internet-Draft Syslog Management March 2018 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The term "originator" is defined in [RFC5424]: an "originator" generates syslog content to be carried in a message. The term "relay" is defined in [RFC5424]: a "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays The term "collectors" is defined in [RFC5424]: a "collector" gathers syslog content for further analysis. The term "action" refers to the processing that takes place for each syslog message received. 1.3. NDMA Compliance The YANG model in this document conforms to the Network Management Datastore Architecture defined in I-D.ietf-netmod-revised-datastores [I-D.ietf-netmod-revised-datastores]. 1.4. Editorial Note (To be removed by RFC Editor) This document contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft- ietf-netconf-keystore o "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value for draft-ietf-netconf-tls-client-server o "zzzz" --> the assigned RFC value for this draft o I-D.ietf-netmod-revised-datastores --> the assigned RFC value for draft-ietf-netmod-revised-datastores 2. Design of the Syslog Model The syslog model was designed by comparing various syslog features Wildes & Koushik Expires September 14, 2018 [Page 3] Internet-Draft Syslog Management March 2018 implemented by various vendors' in different implementations. This document addresses the common leafs between implementations and creates a common model, which can be augmented with proprietary features, if necessary. This model is designed to be very simple for maximum flexibility. Some optional features are defined in this document to specify functionality that is present in specific vendor configurations. Syslog consists of originators and collectors. The following diagram shows syslog messages flowing from originators, to collectors where filtering can take place. Originators +-------------+ +-------------+ +-------------+ +-------------+ | Various | | OS | | | | Remote | | Components | | Kernel | | Line Cards | | Servers | +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ | SNMP | | Interface | | Standby | | Syslog | | Events | | Events | | Supervisor | | Itself | +-------------+ +-------------+ +-------------+ +-------------+ | | +----------------------------------------------------------------+ | | | | +-------------+--------------+ | | | v v v Collectors +----------+ +----------+ +----------------+ | | | Log | |Remote Relay(s)/| | Console | | File(s) | |Collector(s) | +----------+ +----------+ +----------------+ Figure 1. Syslog Processing Flow Collectors are configured using the leaves in the syslog model "actions" container which correspond to each message collector: console log file(s) remote relay(s)/collector(s) Wildes & Koushik Expires September 14, 2018 [Page 4] Internet-Draft Syslog Management March 2018 Within each action, a selector is used to filter syslog messages. A selector consists of a list of one or more filters specified by facility-severity pairs, and, if supported via the select-match feature, an optional regular expression pattern match that is performed on the [RFC5424] field. A syslog message is processed if: There is an element of facility-list (F, S) where the message facility matches F and the message severity matches S and/or the message text matches the regex pattern (if it is present) The facility is one of a specific syslog-facility, or all facilities. The severity is one of type syslog-severity, all severities, or none. None is a special case that can be used to disable a filter. When filtering severity, the default comparison is that messages of the specified severity and higher are selected to be logged. This is shown in the model as "default equals-or-higher". This behavior can be altered if the select-adv-compare feature is enabled to specify a compare operation and an action. Compare operations are: "equals" to select messages with this single severity, or "equals-or-higher" to select messages of the specified severity and higher. Actions are used to log the message or block the message from being logged. Many vendors extend the list of facilities available for logging in their implementation. An example is included in Extending Facilities (Appendix A.1). 2.1. Syslog Module A simplified graphical representation of the data model is used in this document. Please see [I-D.ietf-netmod-yang-tree-diagrams] for tree diagram notation. Wildes & Koushik Expires September 14, 2018 [Page 5] Internet-Draft Syslog Management March 2018 module: ietf-syslog +--rw syslog! +--rw actions +--rw console! {console-action}? | +--rw facility-filter | | +--rw facility-list* [facility severity] | | +--rw facility union | | +--rw severity union | | +--rw advanced-compare {select-adv-compare}? | | +--rw compare? enumeration | | +--rw action? enumeration | +--rw pattern-match? string {select-match}? +--rw file {file-action}? | +--rw log-file* [name] | +--rw name inet:uri | +--rw facility-filter | | +--rw facility-list* [facility severity] | | +--rw facility union | | +--rw severity union | | +--rw advanced-compare {select-adv-compare}? | | +--rw compare? enumeration | | +--rw action? enumeration | +--rw pattern-match? string {select-match}? | +--rw structured-data? boolean {structured-data}? | +--rw file-rotation | +--rw number-of-files? uint32 {file-limit-size}? | +--rw max-file-size? uint32 {file-limit-size}? | +--rw rollover? uint32 | | {file-limit-duration}? | +--rw retention? uint32 | {file-limit-duration}? +--rw remote {remote-action}? +--rw destination* [name] +--rw name string +--rw (transport) | +--:(udp) | | +--rw udp | | +--rw address? inet:host | | +--rw port? inet:port-number | +--:(tls) | +--rw tls | +--rw address? inet:host | +--rw port? inet:port-number | +--rw client-auth | | +--rw (auth-type)? | | +--:(certificate) | | +--rw certificate? leafref | +--rw server-auth | | +--rw pinned-ca-certs? leafref | | +--rw pinned-server-certs? leafref | +--rw hello-params | {tls-client-hello-params-config}? | +--rw tls-versions Wildes & Koushik Expires September 14, 2018 [Page 6] Internet-Draft Syslog Management March 2018 | | +--rw tls-version* identityref | +--rw cipher-suites | +--rw cipher-suite* identityref +--rw facility-filter | +--rw facility-list* [facility severity] | +--rw facility union | +--rw severity union | +--rw advanced-compare {select-adv-compare}? | +--rw compare? enumeration | +--rw action? enumeration +--rw pattern-match? string {select-match}? +--rw structured-data? boolean {structured-data}? +--rw facility-override? identityref +--rw source-interface? if:interface-ref | {remote-source-interface}? +--rw signing! {signed-messages}? +--rw cert-signers +--rw cert-signer* [name] | +--rw name string | +--rw cert | | +--rw algorithm? | | | identityref | | +--rw private-key? | | | union | | +--rw public-key? | | | binary | | +---x generate-private-key | | | +---w input | | | +---w algorithm? | | | identityref | | +--rw certificates | | | +--rw certificate* [name] | | | +--rw name string | | | +--rw value? binary | | +---x generate-certificate-signing-request | | +---w input | | | +---w subject binary | | | +---w attributes? binary | | +--ro output | | +--ro certificate-signing-request | | binary | +--rw hash-algorithm? enumeration +--rw cert-initial-repeat? uint32 +--rw cert-resend-delay? uint32 +--rw cert-resend-count? uint32 +--rw sig-max-delay? uint32 +--rw sig-number-resends? uint32 +--rw sig-resend-delay? uint32 +--rw sig-resend-count? uint32 Figure 2. ietf-syslog Module Tree 3. Syslog YANG Module Wildes & Koushik Expires September 14, 2018 [Page 7] Internet-Draft Syslog Management March 2018 3.1. The ietf-syslog Module This module imports typedefs from [RFC6991], [I-D.ietf-netmod-rfc7223bis], groupings from [I-D.ietf-netconf-keystore], and [I-D.ietf-netconf-tls-client-server], and it references [RFC5424], [RFC5425], [RFC5426], [RFC5848], [RFC8089], [RFC8174], and [Std-1003.1-2008]. Wildes & Koushik Expires September 14, 2018 [Page 8] Internet-Draft Syslog Management March 2018 file "ietf-syslog@2018-03-15.yang" module ietf-syslog { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-syslog"; prefix syslog; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix if; reference "I-D.ietf-netmod-rfc7223bis: A YANG Data Model for Interface Management"; } import ietf-tls-client { prefix tlsc; reference "I-D.ietf-netconf-tls-client-server: YANG Groupings for TLS Clients and TLS Servers"; } import ietf-keystore { prefix ks; reference "I-D.ietf-netconf-keystore: YANG Data Model for a Keystore Mechanism"; } organization "IETF NETMOD (Network Modeling) Working Group"; contact "WG Web: WG List: Editor: Kiran Agrahara Sreenivasa Editor: Clyde Wildes "; description "This module contains a collection of YANG definitions for syslog configuration. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Wildes & Koushik Expires September 14, 2018 [Page 9] Internet-Draft Syslog Management March 2018 Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119 (http://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC zzzz (http://tools.ietf.org/html/rfczzzz); see the RFC itself for full legal notices."; revision 2018-03-15 { description "Initial Revision"; reference "RFC zzzz: Syslog YANG Model"; } feature console-action { description "This feature indicates that the local console action is supported."; } feature file-action { description "This feature indicates that the local file action is supported."; } feature file-limit-size { description "This feature indicates that file logging resources are managed using size and number limits."; } feature file-limit-duration { description "This feature indicates that file logging resources are managed using time based limits."; } feature remote-action { description "This feature indicates that the remote server action is supported."; } Wildes & Koushik Expires September 14, 2018 [Page 10] Internet-Draft Syslog Management March 2018 feature remote-source-interface { description "This feature indicates that source-interface is supported supported for the remote-action."; } feature select-adv-compare { description "This feature represents the ability to select messages using the additional comparison operators when comparing the syslog message severity."; } feature select-match { description "This feature represents the ability to select messages based on a Posix 1003.2 regular expression pattern match."; } feature structured-data { description "This feature represents the ability to log messages in structured-data format."; reference "RFC 5424: The Syslog Protocol"; } feature signed-messages { description "This feature represents the ability to configure signed syslog messages."; reference "RFC 5848: Signed Syslog Messages"; } typedef syslog-severity { type enumeration { enum "emergency" { value 0; description "The severity level 'Emergency' indicating that the system is unusable."; } enum "alert" { value 1; description "The severity level 'Alert' indicating that an action must be taken immediately."; } enum "critical" { value 2; description "The severity level 'Critical' indicating a critical condition."; Wildes & Koushik Expires September 14, 2018 [Page 11] Internet-Draft Syslog Management March 2018 } enum "error" { value 3; description "The severity level 'Error' indicating an error condition."; } enum "warning" { value 4; description "The severity level 'Warning' indicating a warning condition."; } enum "notice" { value 5; description "The severity level 'Notice' indicating a normal but significant condition."; } enum "info" { value 6; description "The severity level 'Info' indicating an informational message."; } enum "debug" { value 7; description "The severity level 'Debug' indicating a debug-level message."; } } description "The definitions for Syslog message severity. Note that a lower value is a higher severity. Comparisons of equal-or-higher severity mean equal or lower numeric value"; reference "RFC 5424: The Syslog Protocol"; } identity syslog-facility { description "This identity is used as a base for all syslog facilities."; reference "RFC 5424: The Syslog Protocol"; } identity kern { base syslog-facility; description "The facility for kernel messages (0)."; reference "RFC 5424: The Syslog Protocol"; } Wildes & Koushik Expires September 14, 2018 [Page 12] Internet-Draft Syslog Management March 2018 identity user { base syslog-facility; description "The facility for user-level messages (1)."; reference "RFC 5424: The Syslog Protocol"; } identity mail { base syslog-facility; description "The facility for the mail system (2)."; reference "RFC 5424: The Syslog Protocol"; } identity daemon { base syslog-facility; description "The facility for the system daemons (3)."; reference "RFC 5424: The Syslog Protocol"; } identity auth { base syslog-facility; description "The facility for security/authorization messages (4)."; reference "RFC 5424: The Syslog Protocol"; } identity syslog { base syslog-facility; description "The facility for messages generated internally by syslogd facility (5)."; reference "RFC 5424: The Syslog Protocol"; } identity lpr { base syslog-facility; description "The facility for the line printer subsystem (6)."; reference "RFC 5424: The Syslog Protocol"; } identity news { base syslog-facility; description "The facility for the network news subsystem (7)."; Wildes & Koushik Expires September 14, 2018 [Page 13] Internet-Draft Syslog Management March 2018 reference "RFC 5424: The Syslog Protocol"; } identity uucp { base syslog-facility; description "The facility for the UUCP subsystem (8)."; reference "RFC 5424: The Syslog Protocol"; } identity cron { base syslog-facility; description "The facility for the clock daemon (9)."; reference "RFC 5424: The Syslog Protocol"; } identity authpriv { base syslog-facility; description "The facility for privileged security/authorization messages (10)."; reference "RFC 5424: The Syslog Protocol"; } identity ftp { base syslog-facility; description "The facility for the FTP daemon (11)."; reference "RFC 5424: The Syslog Protocol"; } identity ntp { base syslog-facility; description "The facility for the NTP subsystem (12)."; reference "RFC 5424: The Syslog Protocol"; } identity audit { base syslog-facility; description "The facility for log audit messages (13)."; reference "RFC 5424: The Syslog Protocol"; } identity console { Wildes & Koushik Expires September 14, 2018 [Page 14] Internet-Draft Syslog Management March 2018 base syslog-facility; description "The facility for log alert messages (14)."; reference "RFC 5424: The Syslog Protocol"; } identity cron2 { base syslog-facility; description "The facility for the second clock daemon (15)."; reference "RFC 5424: The Syslog Protocol"; } identity local0 { base syslog-facility; description "The facility for local use 0 messages (16)."; reference "RFC 5424: The Syslog Protocol"; } identity local1 { base syslog-facility; description "The facility for local use 1 messages (17)."; reference "RFC 5424: The Syslog Protocol"; } identity local2 { base syslog-facility; description "The facility for local use 2 messages (18)."; reference "RFC 5424: The Syslog Protocol"; } identity local3 { base syslog-facility; description "The facility for local use 3 messages (19)."; reference "RFC 5424: The Syslog Protocol"; } identity local4 { base syslog-facility; description "The facility for local use 4 messages (20)."; reference "RFC 5424: The Syslog Protocol"; } Wildes & Koushik Expires September 14, 2018 [Page 15] Internet-Draft Syslog Management March 2018 identity local5 { base syslog-facility; description "The facility for local use 5 messages (21)."; reference "RFC 5424: The Syslog Protocol"; } identity local6 { base syslog-facility; description "The facility for local use 6 messages (22)."; reference "RFC 5424: The Syslog Protocol"; } identity local7 { base syslog-facility; description "The facility for local use 7 messages (23)."; reference "RFC 5424: The Syslog Protocol"; } grouping severity-filter { description "This grouping defines the processing used to select log messages by comparing syslog message severity using the following processing rules: - if 'none', do not match. - if 'all', match. - else compare message severity with the specified severity according to the default compare rule (all messages of the specified severity and greater match) or if the select-adv-compare feature is present, use the advance-compare rule."; leaf severity { type union { type syslog-severity; type enumeration { enum none { value 2147483647; description "This enum describes the case where no severities are selected."; } enum all { value -2147483648; description "This enum describes the case where all severities are selected."; } } Wildes & Koushik Expires September 14, 2018 [Page 16] Internet-Draft Syslog Management March 2018 } mandatory true; description "This leaf specifies the syslog message severity."; } container advanced-compare { when '../severity != "all" and ../severity != "none"' { description "The advanced compare container is not applicable for severity 'all' or severity 'none'"; } if-feature select-adv-compare; leaf compare { type enumeration { enum equals { description "This enum specifies that the severity comparison operation will be equals."; } enum equals-or-higher { description "This enum specifies that the severity comparison operation will be equals or higher."; } } default equals-or-higher; description "The compare can be used to specify the comparison operator that should be used to compare the syslog message severity with the specified severity."; } leaf action { type enumeration { enum log { description "This enum specifies that if the compare operation is true the message will be logged."; } enum block { description "This enum specifies that if the compare operation is true the message will not be logged."; } } default log; description "The action can be used to specify if the message should be logged or blocked based on the outcome of the compare operation."; } description "This container describes additional severity compare operations that can be used in place of the default Wildes & Koushik Expires September 14, 2018 [Page 17] Internet-Draft Syslog Management March 2018 severity comparison. The compare leaf specifies the type of the compare that is done and the action leaf specifies the intended result. Example: compare->equals and action->block means messages that have a severity that are equal to the specified severity will not be logged."; } } grouping selector { description "This grouping defines a syslog selector which is used to select log messages for the log-actions (console, file, remote, etc.). Choose one or both of the following: facility [ ...] pattern-match regular-expression-match-string If both facility and pattern-match are specified, both must match in order for a log message to be selected."; container facility-filter { description "This container describes the syslog filter parameters."; list facility-list { key "facility severity"; ordered-by user; description "This list describes a collection of syslog facilities and severities."; leaf facility { type union { type identityref { base syslog-facility; } type enumeration { enum all { description "This enum describes the case where all facilities are requested."; } } } description "The leaf uniquely identifies a syslog facility."; } uses severity-filter; } } leaf pattern-match { if-feature select-match; type string; description "This leaf describes a Posix 1003.2 regular expression string that can be used to select a syslog message for logging. The match is performed on the SYSLOG-MSG field."; reference Wildes & Koushik Expires September 14, 2018 [Page 18] Internet-Draft Syslog Management March 2018 "RFC 5424: The Syslog Protocol Std-1003.1-2008 Regular Expressions"; } } grouping structured-data { description "This grouping defines the syslog structured data option which is used to select the format used to write log messages."; leaf structured-data { if-feature structured-data; type boolean; default false; description "This leaf describes how log messages are written. If true, messages will be written with one or more STRUCTURED-DATA elements; if false, messages will be written with STRUCTURED-DATA = NILVALUE."; reference "RFC 5424: The Syslog Protocol"; } } container syslog { presence "Enables logging."; description "This container describes the configuration parameters for syslog."; container actions { description "This container describes the log-action parameters for syslog."; container console { if-feature console-action; presence "Enables logging to the console"; description "This container describes the configuration parameters for console logging."; uses selector; } container file { if-feature file-action; description "This container describes the configuration parameters for file logging. If file-archive limits are not supplied, it is assumed that the local implementation defined limits will be used."; list log-file { key "name"; description "This list describes a collection of local logging files."; leaf name { Wildes & Koushik Expires September 14, 2018 [Page 19] Internet-Draft Syslog Management March 2018 type inet:uri { pattern 'file:.*'; } description "This leaf specifies the name of the log file which MUST use the uri scheme file:."; reference "RFC 8089: The file URI Scheme"; } uses selector; uses structured-data; container file-rotation { description "This container describes the configuration parameters for log file rotation."; leaf number-of-files { if-feature file-limit-size; type uint32; default 1; description "This leaf specifies the maximum number of log files retained. Specify 1 for implementations that only support one log file."; } leaf max-file-size { if-feature file-limit-size; type uint32; units "megabytes"; description "This leaf specifies the maximum log file size."; } leaf rollover { if-feature file-limit-duration; type uint32; units "minutes"; description "This leaf specifies the length of time that log events should be written to a specific log file. Log events that arrive after the rollover period cause the current log file to be closed and a new log file to be opened."; } leaf retention { if-feature file-limit-duration; type uint32; units "minutes"; description "This leaf specifies the length of time that completed/closed log event files should be stored in the file system before they are removed."; } } } } Wildes & Koushik Expires September 14, 2018 [Page 20] Internet-Draft Syslog Management March 2018 container remote { if-feature remote-action; description "This container describes the configuration parameters for forwarding syslog messages to remote relays or collectors."; list destination { key "name"; description "This list describes a collection of remote logging destinations."; leaf name { type string; description "An arbitrary name for the endpoint to connect to."; } choice transport { mandatory true; description "This choice describes the transport option."; case udp { container udp { description "This container describes the UDP transport options."; reference "RFC 5426: Transmission of Syslog Messages over UDP"; leaf address { type inet:host; description "The leaf uniquely specifies the address of the remote host. One of the following must be specified: an ipv4 address, an ipv6 address, or a host name."; } leaf port { type inet:port-number; default 514; description "This leaf specifies the port number used to deliver messages to the remote server."; } } } case tls { container tls { description "This container describes the TLS transport options."; reference "RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog "; leaf address { Wildes & Koushik Expires September 14, 2018 [Page 21] Internet-Draft Syslog Management March 2018 type inet:host; description "The leaf uniquely specifies the address of the remote host. One of the following must be specified: an ipv4 address, an ipv6 address, or a host name."; } leaf port { type inet:port-number; default 6514; description "TCP port 6514 has been allocated as the default port for syslog over TLS."; } uses tlsc:tls-client-grouping; } } } uses selector; uses structured-data; leaf facility-override { type identityref { base syslog-facility; } description "If specified, this leaf specifies the facility used to override the facility in messages delivered to the remote server."; } leaf source-interface { if-feature remote-source-interface; type if:interface-ref; description "This leaf sets the source interface to be used to send messages to the remote syslog server. If not set, messages can be sent on any interface."; } container signing { if-feature signed-messages; presence "If present, syslog-signing options is activated."; description "This container describes the configuration parameters for signed syslog messages."; reference "RFC 5848: Signed Syslog Messages"; container cert-signers { description "This container describes the signing certificate configuration for Signature Group 0 which covers the case for administrators who want all Signature Blocks to be sent to a single destination."; list cert-signer { key "name"; Wildes & Koushik Expires September 14, 2018 [Page 22] Internet-Draft Syslog Management March 2018 description "This list describes a collection of syslog message signers."; leaf name { type string; description "This leaf specifies the name of the syslog message signer."; } container cert { uses ks:private-key-grouping; uses ks:certificate-grouping; description "This is the certificate that is periodically sent to the remote receiver. Selection of the certificate also implicitly selects the private key used to sign the syslog messages."; } leaf hash-algorithm { type enumeration { enum SHA1 { value 1; description "This enum describes the SHA1 algorithm."; } enum SHA256 { value 2; description "This enum describes the SHA256 algorithm."; } } description "This leaf describes the syslog signer hash algorithm used."; } } leaf cert-initial-repeat { type uint32; default 3; description "This leaf specifies the number of times each Certificate Block should be sent before the first message is sent."; } leaf cert-resend-delay { type uint32; units "seconds"; default 3600; description "This leaf specifies the maximum time delay in seconds until resending the Certificate Block."; } leaf cert-resend-count { type uint32; Wildes & Koushik Expires September 14, 2018 [Page 23] Internet-Draft Syslog Management March 2018 default 0; description "This leaf specifies the maximum number of other syslog messages to send until resending the Certificate Block."; } leaf sig-max-delay { type uint32; units "seconds"; default 60; description "This leaf specifies when to generate a new Signature Block. If this many seconds have elapsed since the message with the first message number of the Signature Block was sent, a new Signature Block should be generated."; } leaf sig-number-resends { type uint32; default 0; description "This leaf specifies the number of times a Signature Block is resent. (It is recommended to select a value of greater than 0 in particular when the UDP transport RFC 5426 is used.)."; } leaf sig-resend-delay { type uint32; units "seconds"; default 5; description "This leaf specifies when to send the next Signature Block transmission based on time. If this many seconds have elapsed since the previous sending of this Signature Block, resend it."; } leaf sig-resend-count { type uint32; default 0; description "This leaf specifies when to send the next Signature Block transmission based on a count. If this many other syslog messages have been sent since the previous sending of this Signature Block, resend it. A value of 0 means that you don't resend based on the number of messages."; } } } } } } } Wildes & Koushik Expires September 14, 2018 [Page 24] Internet-Draft Syslog Management March 2018 } Figure 3. ietf-syslog Module 4. Usage Examples Requirement: Enable console logging of syslogs of severity critical all critical Enable remote logging of syslogs to udp destination foo.example.com for facility auth, severity error remote1
foo.example.com
auth error
Figure 4. ietf-syslog Examples 5. Acknowledgements The authors wish to thank the following who commented on this proposal: Wildes & Koushik Expires September 14, 2018 [Page 25] Internet-Draft Syslog Management March 2018 Andy Bierman, Martin Bjorklund, Alex Campbell, Alex Clemm, Francis Dupont, Jim Gibson, Jeffrey Haas, Bob Harold, John Heasley, Giles Heron, Lisa Huang, Mahesh Jethanandani, Warren Kumari, Jeffrey K Lange, Jan Lindblad, Chris Lonvick, Alexey Melnikov, Kathleen Moriarty, Tom Petch, Adam Roach, Juergen Schoenwaelder, Phil Shafer, Yaron Sheffer, Jason Sterne, Peter Van Horne, Kent Watsen, Bert Wijnen, Dale R Worley, and Aleksandr Zhdankin. 6. IANA Considerations 6.1. The IETF XML Registry This document registers one URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested: URI: urn:ietf:params:xml:ns:yang:ietf-syslog Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 6.2. The YANG Module Names Registry This document registers one YANG module in the YANG Module Names registry [RFC7895]. Following the format in [RFC7950], the following registration is requested: name: ietf-syslog namespace: urn:ietf:params:xml:ns:yang:ietf-syslog prefix: ietf-syslog reference: RFC zzzz 7. Security Considerations The YANG module defined in this document is designed to be accessed via YANG based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. Both of these protocols have mandatory-to- implement secure transport layers (e.g., SSH, TLS) with mutual authentication. The NETCONF access control model (NACM) [RFC6536] provides the means to restrict access for particular users to a pre-configured subset of all available protocol operations and content. Wildes & Koushik Expires September 14, 2018 [Page 26] Internet-Draft Syslog Management March 2018 There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes should be considered sensitive or vulnerable in all network environments. Logging in particular is used to assess the state of systems and can be used to indicate a network compromise. If logging were to be disabled through malicious means, attacks may not be readily detectable. Therefore write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations and on network security. In addition there are data nodes that require careful analysis and review. These are the subtrees and data nodes and their sensitivity/ vulnerability: facility-filter/pattern-match: When writing this node, implementations MUST ensure that the regular expression pattern match is not constructed to cause a regular expression denial of service attack due to a pattern that causes the regular expression implementation to work very slowly (exponentially related to input size). remote/destination/signing/cert-signer: When writing this subtree, implementations MUST NOT specify a private key that is used for any other purpose. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: remote/destination/transport: This subtree contains information about other hosts in the network, and the TLS transport certificate properties if TLS is selected as the transport protocol. remote/destination/signing: This subtree contains information about the syslog message signing properties including signing certificate information. There are no RPC operations defined in this YANG module. 8. References 8.1. Normative References [I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keystore" Mechanism", Internet-Draft draft-ietf-netconf-keystore-04, October 2017. [I-D.ietf-netconf-tls-client-server] Wildes & Koushik Expires September 14, 2018 [Page 27] Internet-Draft Syslog Management March 2018 Watsen, K. and G. Wu, "YANG Groupings for TLS Clients and TLS Servers", Internet-Draft draft-ietf-netconf-tls- client-server-05, October 2017. [I-D.ietf-netmod-rfc7223bis] Bjorklund, M., "A YANG Data Model for Interface Management", Internet-Draft draft-ietf-netmod- rfc7223bis-03, January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . [RFC5425] Miao, F., Ed., Ma, Y.Ed., and J. Salowey, Ed., "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, DOI 10.17487/RFC5425, March 2009, . [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, DOI 10.17487/RFC5426, March 2009, . [RFC5848] Kelsey, J., Callas, J. and A. Clemm, "Signed Syslog Messages", RFC 5848, DOI 10.17487/RFC5848, May 2010, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7895] Bierman, A., Bjorklund, M. and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [Std-1003.1-2008] Wildes & Koushik Expires September 14, 2018 [Page 28] Internet-Draft Syslog Management March 2018 The Open Group, ""Chapter 9: Regular Expressions". The Open Group Base Specifications Issue 6, IEEE Std 1003.1-2008, 2016 Edition.", September 2016, . 8.2. Informative References [I-D.ietf-netmod-revised-datastores] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K. and R. Wilton, "Network Management Datastore Architecture", Internet-Draft draft-ietf-netmod-revised- datastores-10, January 2018. [I-D.ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", Internet-Draft draft-ietf-netmod-yang-tree-diagrams-06, February 2018. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J.Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC8040] Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Appendix A. Implementer Guidelines Appendix A.1. Extending Facilities Many vendors extend the list of facilities available for logging in their implementation. Additional facilities may not work with the syslog protocol as defined in [RFC5424] and hence such facilities apply for local syslog-like logging functionality. The following is an example that shows how additional facilities could be added to the list of available facilities (in this example two facilities are added): Wildes & Koushik Expires September 14, 2018 [Page 29] Internet-Draft Syslog Management March 2018 module example-vendor-syslog-types { namespace "http://example.com/ns/vendor-syslog-types"; prefix vendor-syslogtypes; import ietf-syslog { prefix syslogtypes; } organization "Example, Inc."; contact "Example, Inc. Customer Service E-mail: syslog-yang@example.com"; description "This module contains a collection of vendor-specific YANG type definitions for SYSLOG."; revision 2017-08-11 { description "Version 1.0"; reference "Vendor SYSLOG Types: SYSLOG YANG Model"; } identity vendor_specific_type_1 { base syslogtypes:syslog-facility; description "Adding vendor specific type 1 to syslog-facility"; } identity vendor_specific_type_2 { base syslogtypes:syslog-facility; description "Adding vendor specific type 2 to syslog-facility"; } } Appendix A.2. Syslog Terminal Output Terminal output with requirements more complex than the console subtree currently provides, are expected to be supported via vendor extensions rather than handled via the file subtree. Appendix A.3. Syslog File Naming Convention The syslog/file/log-file/file-rotation container contains configuration parameters for syslog file rotation. This section describes how these fields might be used by an implementer to name syslog files in a rotation process. This information is offered as an informative guide only. Wildes & Koushik Expires September 14, 2018 [Page 30] Internet-Draft Syslog Management March 2018 When an active syslog file with a name specified by log-file/name, reaches log-file/max-file-size and/or syslog events arrive after the period specified by log-file/rollover, the logging system can close the file, can compress it, and can name the archive file .0.gz. The logging system can then open a new active syslog file . When the new syslog file reaches either of the size limits referenced above, .0.gz can be renamed .1.gz and the new syslog file can be closed, compressed and renamed .0.gz. Each time that a new syslog file is closed, each of the prior syslog archive files named ..gz can be renamed to ..gz. Removal of archive log files could occur when either or both: - log-file/number-of-files specified - the logging system can create up to log-file/number-of-files syslog archive files after which, the contents of the oldest archived file could be overwritten. - log-file/retention specified - the logging system can remove those syslog archive files whose file expiration time (file creation time plus the specified log-file/retention time) is prior to the current time. Authors' Addresses Clyde Wildes, editor Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 US Phone: +1 408 527-2672 Email: cwildes@cisco.com Kiran Koushik, editor Verizon Wireless 500 W Dove Rd. Southlake, TX 76092 US Phone: +1 512 650-0210 Email: kirankoushik.agraharasreenivasa@verizonwireless.com Wildes & Koushik Expires September 14, 2018 [Page 31] ./draft-ietf-nfsv4-rpc-tls-11.txt0000644000764400076440000016774413756750117016033 0ustar iustyiusty Network File System Version 4 T. Myklebust Internet-Draft Hammerspace Updates: 5531 (if approved) C. Lever, Ed. Intended status: Standards Track Oracle Expires: 27 May 2021 23 November 2020 Towards Remote Procedure Call Encryption By Default draft-ietf-nfsv4-rpc-tls-11 Abstract This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in-transit. The proposed mechanism interoperates with ONC RPC implementations that do not support it. This document updates RFC 5531. Note Discussion of this draft takes place on the NFSv4 working group mailing list (nfsv4@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group information can be found at https://datatracker.ietf.org/wg/nfsv4/ about/. This note is to be removed before publishing as an RFC. The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/chucklever/i-d-rpc-tls. Instructions are on that page as well. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Myklebust & Lever Expires 27 May 2021 [Page 1] Internet-Draft RPC-Over-TLS November 2020 This Internet-Draft will expire on 27 May 2021. Copyright Notice Copyright (c) 2020 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. RPC-Over-TLS in Operation . . . . . . . . . . . . . . . . . . 5 4.1. Discovering Server-side TLS Support . . . . . . . . . . . 6 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Using TLS with RPCSEC GSS . . . . . . . . . . . . . . 8 5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Base Transport Considerations . . . . . . . . . . . . . . 9 5.1.1. Protected Operation on TCP . . . . . . . . . . . . . 10 5.1.2. Protected Operation on UDP . . . . . . . . . . . . . 10 5.1.3. Protected Operation on Other Transports . . . . . . . 11 5.2. TLS Peer Authentication . . . . . . . . . . . . . . . . . 12 5.2.1. X.509 Certificates Using PKIX Trust . . . . . . . . . 12 5.2.2. Pre-Shared Keys . . . . . . . . . . . . . . . . . . . 14 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 6.1. DESY NFS server . . . . . . . . . . . . . . . . . . . . . 14 6.2. Hammerspace NFS server . . . . . . . . . . . . . . . . . 15 6.3. Linux NFS server and client . . . . . . . . . . . . . . . 15 6.4. FreeBSD NFS server and client . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1. The Limitations of Opportunistic Security . . . . . . . . 16 7.1.1. STRIPTLS Attacks . . . . . . . . . . . . . . . . . . 17 7.1.2. Privacy Leakage Before Session Establishment . . . . 17 7.2. TLS Identity Management on Clients . . . . . . . . . . . 18 7.3. Security Considerations for AUTH_SYS on TLS . . . . . . . 18 7.4. Best Security Policy Practices . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. RPC Authentication Flavor . . . . . . . . . . . . . . . . 19 8.2. ALPN Identifier for SUNRPC . . . . . . . . . . . . . . . 20 Myklebust & Lever Expires 27 May 2021 [Page 2] Internet-Draft RPC-Over-TLS November 2020 8.3. Object Identifier for PKIX Extended Key Usage . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction In 2014 the IETF published a document entitled "Pervasive Monitoring Is an Attack" [RFC7258], which recognized that unauthorized observation of network traffic had become widespread and was a subversive threat to all who make use of the Internet at large. It strongly recommended that newly defined Internet protocols should make a genuine effort to mitigate monitoring attacks. Typically this mitigation includes encrypting data in transit. The Remote Procedure Call version 2 protocol has been a Proposed Standard for three decades (see [RFC5531] and its antecedents). Over twenty years ago, Eisler et al. first introduced RPCSEC GSS as an in- transit encryption mechanism for RPC [RFC2203]. However, experience has shown that RPCSEC GSS with in-transit encryption can be challenging to use in practice: * Parts of each RPC header remain in clear-text, constituting a loss of metadata confidentiality. * Offloading the GSS privacy service is not practical in large multi-user deployments since each message is encrypted using a key based on the issuing RPC user. However strong GSS-provided confidentiality is, it cannot provide any security if the challenges of using it result in choosing not to deploy it at all. Moreover, the use of AUTH_SYS remains common despite the adverse effects that acceptance of UIDs and GIDs from unauthenticated clients brings with it. Continued use is in part because: * Per-client deployment and administrative costs for the only well- defined alternative to AUTH_SYS are expensive at scale. For instance, administrators must provide keying material for each RPC client, including transient clients. Myklebust & Lever Expires 27 May 2021 [Page 3] Internet-Draft RPC-Over-TLS November 2020 * GSS host identity management and user identity management typically must be enforced in the same security realm. However, cloud providers, for instance, might prefer to remain authoritative for host identity but allow tenants to manage user identities within their private networks. In view of the challenges with the currently available mechanisms for authenticating and protecting the confidentiality of RPC transactions, this document specifies a transport-layer security mechanism that complements the existing ones. The Transport Layer Security [RFC8446] (TLS) and Datagram Transport Layer Security [I-D.ietf-tls-dtls13] (DTLS) protocols are a well-established Internet building blocks that protect many standard Internet protocols such as the Hypertext Transport Protocol (HTTP) [RFC2818]. Encrypting at the RPC transport layer accords several significant benefits: Encryption By Default: Transport encryption can be enabled without additional administrative tasks such as identifying client systems to a trust authority and providing each with keying material. Encryption Offload: Hardware support for the GSS privacy service has not appeared in the marketplace. However, the use of a well- established transport encryption mechanism that is employed by other ubiquitous network protocols makes it more likely that encryption offload for RPC is practicable. Securing AUTH_SYS: Most critically, transport encryption can significantly reduce several security issues inherent in the current widespread use of AUTH_SYS (i.e., acceptance of UIDs and GIDs generated by an unauthenticated client). Decoupled User and Host Identities: TLS can be used to authenticate peer hosts while other security mechanisms can handle user authentication. Compatibility: The imposition of encryption at the transport layer protects any upper-layer protocol that employs RPC, without alteration of the upper-layer protocol. Further, Section 7 of the current document defines policies in line with [RFC7435] which enable RPC-over-TLS to be deployed opportunistically in environments that contain RPC implementations that do not support TLS. However, specifications for RPC-based upper-layer protocols should choose to require even stricter policies that guarantee encryption and host authentication is used for all RPC transactions to mitigate against pervasive monitoring attacks Myklebust & Lever Expires 27 May 2021 [Page 4] Internet-Draft RPC-Over-TLS November 2020 [RFC7258]. Enforcing the use of RPC-over-TLS is of particular importance for existing upper-layer protocols whose security infrastructure is weak. The protocol specification in the current document assumes that support for ONC RPC [RFC5531], TLS [RFC8446], PKIX [RFC5280], DNSSEC/ DANE [RFC6698], and optionally RPCSEC_GSS [RFC2203] is available within the platform where RPC-over-TLS support is to be added. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology This document adopts the terminology introduced in Section 3 of [RFC6973] and assumes a working knowledge of the Remote Procedure Call (RPC) version 2 protocol [RFC5531] and the Transport Layer Security (TLS) version 1.3 protocol [RFC8446]. Note also that the NFS community long ago adopted the use of the term "privacy" from documents such as [RFC2203]. In the current document, the authors use the term "privacy" only when referring specifically to the historic GSS privacy service defined in [RFC2203]. Otherwise, the authors use the term "confidentiality", following the practices of contemporary security communities. We adhere to the convention that a "client" is a network host that actively initiates an association, and a "server" is a network host that passively accepts an association request. RPC documentation historically refers to the authentication of a connecting host as "machine authentication" or "host authentication". TLS documentation refers to the same as "peer authentication". In the current document there is little distinction between these terms. The term "user authentication" in the current document refers specifically to the RPC caller's credential, provided in the "cred" and "verf" fields in each RPC Call. 4. RPC-Over-TLS in Operation Myklebust & Lever Expires 27 May 2021 [Page 5] Internet-Draft RPC-Over-TLS November 2020 4.1. Discovering Server-side TLS Support The mechanism described in the current document interoperates fully with RPC implementations that do not support RPC-over-TLS. When an RPC-over-TLS-enabled peer encounters a peer that does not support RPC-over-TLS, policy settings on the RPC-over-TLS-enabled peer determine whether RPC operation continues without the use of TLS, or RPC operation is not permitted. To achieve this interoperability, we introduce a new RPC authentication flavor called AUTH_TLS. The AUTH_TLS authentication flavor signals that the client wants to initiate TLS negotiation if the server supports it. Except for the modifications described in this section, the RPC protocol is unaware of security encapsulation at the transport layer. The value of AUTH_TLS is defined in Section 8.1. An RPC client begins its communication with an RPC server by selecting a transport and destination port. The choice of transport and port is typically based on the RPC program that is to be used. The RPC client might query the RPC server's RPCBIND service to make this selection (The RPCBIND service is described in [RFC1833]). The mechanism described in the current document does not support RPC transports other than TCP and UDP. In all cases, an RPC server MUST listen on the same ports for (D)TLS-protected RPC programs as the ports used when (D)TLS is not available. To protect RPC traffic to a TCP port, the RPC client opens a TCP connection to that port and sends a NULL RPC procedure with an auth_flavor of AUTH_TLS on that connection. To protect RPC traffic to a UDP port, the RPC client sends a UDP datagram to that port containing a NULL RPC procedure with an auth_flavor of AUTH_TLS. The client constructs this RPC procedure as follows: * The length of the opaque data constituting the credential sent in the RPC Call message MUST be zero. * The verifier accompanying the credential MUST be an AUTH_NONE verifier of length zero. * The flavor value of the verifier in the RPC Reply message received from the server MUST be AUTH_NONE. * The length of the verifier's body field is eight. * The bytes of the verifier's body field encode the ASCII characters "STARTTLS" as a fixed-length opaque. Myklebust & Lever Expires 27 May 2021 [Page 6] Internet-Draft RPC-Over-TLS November 2020 The RPC server signals its corresponding support for RPC-over-TLS by replying with a reply_stat of MSG_ACCEPTED and an AUTH_NONE verifier containing the "STARTTLS" token. The client SHOULD proceed with TLS session establishment, even if the Reply's accept_stat is not SUCCESS. If the AUTH_TLS probe was done via TCP, the RPC client MUST send the "ClientHello" message on the same connection. If the AUTH_TLS probe was done via UDP, the RPC client MUST send the "ClientHello" message to the same UDP destination port. Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its verifier flavor is not AUTH_NONE, or if its verifier does not contain the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello" message. RPC operation may continue, depending on local policy, but without confidentiality, integrity, or peer authentication protection from (D)TLS. If, after a successful RPC AUTH_TLS probe, the subsequent (D)TLS handshake should fail for any reason, the RPC client reports this failure to the upper-layer application the same way it reports an AUTH_ERROR rejection from the RPC server. If an RPC client uses the AUTH_TLS authentication flavor on any procedure other than the NULL procedure, or an RPC client sends an RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server MUST reject that RPC Call by returning a reply_stat of MSG_DENIED with a reject_stat of AUTH_ERROR and an auth_stat of AUTH_BADCRED. Once the TLS session handshake is complete, the RPC client and server have established a secure channel for exchanging RPC transactions. A successful AUTH_TLS probe on one particular port/transport tuple does not imply that RPC-over-TLS is available on that same server using a different port/transport tuple, nor does it imply that RPC-over-TLS will be available in the future using the successfully probed port. 4.2. Authentication There is some overlap between the authentication capabilities of RPC and TLS. The goal of interoperability with implementations that do not support TLS requires limiting the combinations that are allowed and precisely specifying the role that each layer plays. Each RPC server that supports RPC-over-TLS MUST possess a unique global identity (e.g., a certificate that is signed by a well-known trust anchor). Such an RPC server MUST request a TLS peer identity from each client upon first contact. There are two different modes of client deployment: Myklebust & Lever Expires 27 May 2021 [Page 7] Internet-Draft RPC-Over-TLS November 2020 Server-only Host Authentication In this type of deployment, the client can authenticate the server host using the presented server peer TLS identity, but the server cannot authenticate the client. In this situation, RPC-over-TLS clients are anonymous. They present no globally unique identifier to the server peer. Mutual Host Authentication In this type of deployment, the client possesses an identity that is backed by a trusted entity (e.g. a pre-shared key or a certificate validated with a certification path). As part of the TLS handshake, both peers authenticate using the presented TLS identities. If authentication of either peer fails, or if authorization based on those identities blocks access to the server, the peers MUST reject the association. Further explanation appears in Section 5.2. In either of these modes, RPC user authentication is not affected by the use of transport layer security. When a client presents a TLS peer identity to an RPC server, the protocol extension described in the current document provides no way for the server to know whether that identity represents one RPC user on that client, or is shared amongst many RPC users. Therefore, a server implementation cannot utilize the remote TLS peer identity to authenticate RPC users. 4.2.1. Using TLS with RPCSEC GSS To use GSS, an RPC server has to possess a GSS service principal. On a TLS session, GSS mutual (peer) authentication occurs as usual, but only after a TLS session has been established for communication. Authentication of RPCSEC GSS users is unchanged by the use of TLS. RPCSEC GSS can also perform per-request integrity or confidentiality protection. When operating over a TLS session, these GSS services become largely redundant. An RPC implementation capable of concurrently using TLS and RPCSEC GSS MUST use GSS-API channel binding, as defined in [RFC5056], to determine when an underlying transport provides a sufficient degree of confidentiality. RPC-over- TLS implementations MUST provide the "tls-exporter" channel binding type, as defined in [I-D.ietf-kitten-tls-channel-bindings-for-tls13]. 5. TLS Requirements When peers negotiate a TLS session that is to transport RPC, the following restrictions apply: Myklebust & Lever Expires 27 May 2021 [Page 8] Internet-Draft RPC-Over-TLS November 2020 * Implementations MUST NOT negotiate TLS versions prior to v1.3 (for TLS [RFC8446] or DTLS [I-D.ietf-tls-dtls13] respectively). Support for mandatory-to-implement ciphersuites for the negotiated TLS version is REQUIRED. * Implementations MUST conform to the recommendations for TLS usage specified in BCP 195 [RFC7525]. Although RFC 7525 permits the use of TLS v1.2, the requirement to use TLS v1.3 or later for RPC- over-TLS takes precedence. Further, because TLS v1.3 ciphers are qualitatively different than cipher suites in previous versions of TLS and RFC 7525 predates TLS v1.3, the cipher suite recommendations in RFC 7525 do not apply to RPC-over-(D)TLS. A strict TLS mode for RPC-over-TLS that protects against STRIPTLS attacks is discussed in detail in Section 7.1.1. * Implementations MUST support certificate-based mutual authentication. Support for PSK mutual authentication is OPTIONAL; see Section 5.2.2 for further details. * Negotiation of a ciphersuite providing confidentiality as well as integrity protection is REQUIRED. Client implementations MUST include the "application_layer_protocol_negotiation(16)" extension [RFC7301] in their "ClientHello" message and MUST include the protocol identifier defined in Section 8.2 in that message's ProtocolNameList value. Similarly, in response to the "ClientHello" message, server implementations MUST include the "application_layer_protocol_negotiation(16)" extension [RFC7301] in their "ServerHello" message and MUST include only the protocol identifier defined in Section 8.2 in that message's ProtocolNameList value. If the server responds incorrectly (for instance, if the "ServerHello" message does not conform to the above requirements), the client MUST NOT establish a TLS session for use with RPC on this connection. See [RFC7301] for further details about how to form these messages properly. 5.1. Base Transport Considerations There is traditionally a strong association between an RPC program and a destination port number. The use of TLS or DTLS does not change that association. Thus it is frequently -- though not always -- the case that a single TLS session carries traffic for only one RPC program. Myklebust & Lever Expires 27 May 2021 [Page 9] Internet-Draft RPC-Over-TLS November 2020 5.1.1. Protected Operation on TCP The use of the Transport Layer Security (TLS) protocol [RFC8446] protects RPC on TCP connections. Typically, once an RPC client completes the TCP handshake, it uses the mechanism described in Section 4.1 to discover RPC-over-TLS support for that RPC program on that connection. Until an AUTH_TLS probe is done on a connection, the RPC server treats all traffic as RPC messages. If spurious traffic appears on a TCP connection between the initial clear-text AUTH_TLS probe and the TLS session handshake, receivers MUST discard that data without response and then SHOULD drop the connection. The protocol convention specified in the current document assumes there can be no more than one concurrent TLS session per TCP connection. This is true of current generations of TLS, but might be different in a future version of TLS. Once a TLS session is established on a TCP connection, no further clear-text communication can occur on that connection until the session is terminated. The use of TLS does not alter RPC record framing used on TCP transports. Furthermore, if an RPC server responds with PROG_UNAVAIL to an RPC Call within an established TLS session, that does not imply that RPC server will subsequently reject the same RPC program on a different TCP connection. Reverse-direction operation occurs only on connected transports such as TCP (see Section 2 of [RFC8167]). To protect reverse-direction RPC operations, the RPC server does not establish a separate TLS session on the TCP connection, but instead uses the existing TLS session on that connection to protect these operations. When operation is complete, an RPC peer terminates a TLS session by sending a TLS Closure Alert. It may then close the TCP connection. 5.1.2. Protected Operation on UDP RFC Editor: In the following section, please replace TBD with the connection_id extension number that is to be assigned in [I-D.ietf-tls-dtls-connection-id]. And, please remove this Editor's Note before this document is published. The use of the Datagram Transport Layer Security (DTLS) protocol [I-D.ietf-tls-dtls13] protects RPC carried in UDP datagrams. As soon as a client initializes a UDP socket for use with an RPC service, it uses the mechanism described in Section 4.1 to discover RPC-over-DTLS support for that RPC program on that port. If spurious traffic Myklebust & Lever Expires 27 May 2021 [Page 10] Internet-Draft RPC-Over-TLS November 2020 appears on a 5-tuple between the initial clear-text AUTH_TLS probe and the DTLS association handshake, receivers MUST discard that traffic without response. Using DTLS does not introduce reliable or in-order semantics to RPC on UDP. The use of DTLS record replay protection is REQUIRED when transporting RPC traffic. Each RPC message MUST fit in a single DTLS record. DTLS encapsulation has overhead, which reduces the Packetization Layer Path MTU (PLPMTU) and thus the maximum RPC payload size. A possible PLPMTU discovery mechanism is offered in [RFC8899]. The current document does not specify a mechanism that enables a server to distinguish between DTLS traffic and unprotected RPC traffic directed to the same port. To make this distinction, each peer matches ingress datagrams that appear to be DTLS traffic to existing DTLS session state. A peer treats any datagram that fails the matching process as an RPC message. Multi-homed RPC clients and servers may send protected RPC messages via network interfaces that were not involved in the handshake that established the DTLS session. Therefore, when protecting RPC traffic, each DTLS handshake MUST include the "connection_id(TBD)" extension described in Section 9 of [I-D.ietf-tls-dtls13], and RPC- over-DTLS peer endpoints MUST provide a ConnectionID with a non-zero length. Endpoints implementing RPC programs that expect a significant number of concurrent clients SHOULD employ ConnectionIDs of at least 4 bytes in length. Sending a TLS Closure Alert terminates a DTLS session. Because neither DTLS nor UDP provide in-order delivery, after session closure there can be ambiguity as to whether a datagram should be interpreted as DTLS protected or not. Therefore receivers MUST discard datagrams exchanged using the same 5-tuple that just terminated the DTLS session for a sufficient length of time to ensure that retransmissions have ceased and packets already in the network have been delivered. In the absence of more specific data, a period of 60 seconds is expected to suffice. 5.1.3. Protected Operation on Other Transports Transports that provide intrinsic TLS-level security (e.g., QUIC) need to be addressed separately from the current document. In such cases, the use of TLS is not opportunistic as it can be for TCP or UDP. Myklebust & Lever Expires 27 May 2021 [Page 11] Internet-Draft RPC-Over-TLS November 2020 RPC-over-RDMA can make use of transport layer security below the RDMA transport layer [RFC8166]. The exact mechanism is not within the scope of the current document. Because there might not be other provisions to exchange client and server certificates, authentication material exchange needs to be provided by facilities within a future version of the RPC-over-RDMA transport protocol. 5.2. TLS Peer Authentication TLS can perform peer authentication using any of the following mechanisms. 5.2.1. X.509 Certificates Using PKIX Trust X.509 certificates are specified in [X.509]. [RFC5280] provides a profile of Internet PKI X.509 public key infrastructure. RPC-over- TLS implementations are REQUIRED to support the PKIX mechanism described in [RFC5280]. The rules and guidelines defined in [RFC6125] apply to RPC-over-TLS certificates with the following considerations: * The DNS-ID identifier type is a subjectAltName extension that contains a dNSName, as defined in Section 4.2.1.6 of [RFC5280]. Support for the DNS-ID identifier type is REQUIRED in RPC-over-TLS client and server implementations. Certification authorities that issue such certificates MUST support the DNS-ID identifier type. * To specify the identity of an RPC peer as a domain name, the certificate MUST contain a subjectAltName extension that contains a dNSName. DNS domain names in RPC-over-TLS certificates MUST NOT contain the wildcard character '*' within the identifier. * To specify the identity of an RPC peer as a network identifier (netid) or a universal network address (uaddr), the certificate MUST contain a subjectAltName extension that contains an iPAddress. When validating a server certificate, an RPC-over-TLS client implementation takes the following into account: * Certificate validation MUST include the verification rules as per Section 6 of [RFC5280] and Section 6 of [RFC6125]. * Server certificate validation MUST include a check on whether the locally configured expected DNS-ID or iPAddress subjectAltName of the server that is contacted matches its presented certificate. Myklebust & Lever Expires 27 May 2021 [Page 12] Internet-Draft RPC-Over-TLS November 2020 * For RPC services accessed by their network identifiers (netids) and universal network addresses (uaddr), the iPAddress subjectAltName MUST be present in the certificate and MUST exactly match the address represented by the universal network address. An RPC client's domain name and IP address are often assigned dynamically, thus RPC servers cannot rely on those to verify client certificates. Therefore, when an RPC-over-TLS client presents a certificate to an RPC-over-TLS server, the server takes the following into account: * The server MUST use a procedure conformant to Section 6 of [RFC5280]) to validate the client certificate's certification path. * The tuple (serial number of the presented certificate; Issuer) uniquely identifies the RPC client. The meaning and syntax of these fields is defined in Section 4 of [RFC5280]). RPC-over-TLS implementations MAY allow the configuration of a set of additional properties of the certificate to check for a peer's authorization to communicate (e.g., a set of allowed values in subjectAltName:URI, a set of allowed X.509v3 Certificate Policies, or a set of extended key usages). When the configured set of trust anchors changes (e.g., removal of a CA from the list of trusted CAs; issuance of a new CRL for a given CA), implementations SHOULD reevaluate the certificate originally presented in the context of the new configuration and terminate the TLS session if the certificate is no longer trustworthy. 5.2.1.1. Extended Key Usage Values Section 4.2.1.12 of [RFC5280] specifies the extended key usage X.509 certificate extension. This extension, which may appear in end- entity certificates, indicates one or more purposes for which the certified public key may be used in addition to or in place of the basic purposes indicated in the key usage extension. The current document defines two new KeyPurposeId values: one that identifies the RPC-over-TLS peer as an RPC client, and one that identifies the RPC-over-TLS peer as an RPC server. The inclusion of the RPC server value (id-kp-rpcTLSServer) indicates that the certificate has been issued for allowing the holder to process RPC transactions. Myklebust & Lever Expires 27 May 2021 [Page 13] Internet-Draft RPC-Over-TLS November 2020 The inclusion of the RPC client value (id-kp-rpcTLSClient) indicates that the certificate has been issued for allowing the holder to request RPC transactions. 5.2.2. Pre-Shared Keys This mechanism is OPTIONAL to implement. In this mode, the RPC peer can be uniquely identified by keying material that has been shared out-of-band (see Section 2.2 of [RFC8446]). The PSK Identifier SHOULD be exposed at the RPC layer. 6. Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. 6.1. DESY NFS server Organization: DESY URL: https://desy.de Maturity: Implementation will be based on mature versions of the current document. Coverage: The bulk of this specification is implemented including DTLS. Licensing: LGPL Implementation experience: The implementer has read and commented on the current document. Myklebust & Lever Expires 27 May 2021 [Page 14] Internet-Draft RPC-Over-TLS November 2020 6.2. Hammerspace NFS server Organization: Hammerspace URL: https://hammerspace.com Maturity: Prototype software based on early versions of the current document. Coverage: The bulk of this specification is implemented. The use of DTLS functionality is not implemented. Licensing: Proprietary Implementation experience: No comments from implementors. 6.3. Linux NFS server and client Organization: The Linux Foundation URL: https://www.kernel.org Maturity: Not complete. Coverage: The bulk of this specification has yet to be implemented. The use of DTLS functionality is not planned. Licensing: GPLv2 Implementation experience: A Linux in-kernel prototype is underway, but implementation delays have resulted from the challenges of handling a TLS handshake in a kernel environment. Those issues stem from the architecture of TLS and the kernel, not from the design of the RPC-over- TLS protocol. 6.4. FreeBSD NFS server and client Organization: The FreeBSD Project URL: https://www.freebsd.org Maturity: Prototype software based on early versions of the current document. Coverage: The bulk of this specification is implemented. The use of DTLS functionality is not planned. Myklebust & Lever Expires 27 May 2021 [Page 15] Internet-Draft RPC-Over-TLS November 2020 Licensing: BSD Implementation experience: Implementers have read and commented on the current document. 7. Security Considerations One purpose of the mechanism described in the current document is to protect RPC-based applications against threats to the confidentiality of RPC transactions and RPC user identities. A taxonomy of these threats appears in Section 5 of [RFC6973]. Also, Section 6 of [RFC7525] contains a detailed discussion of technologies used in conjunction with TLS. Section 8 of [RFC5280] covers important considerations about handling certificate material securely. Implementers should familiarize themselves with these materials. Once a TLS session is established, the RPC payload carried on TLS version 1.3 is forward-secure. However, implementers need to be aware that replay attacks can occur during session establishment. Remedies for such attacks are discussed in detail in Section 8 of [RFC8446]. Further, the current document does not provide a profile that defines the use of 0-RTT data (see Appendix E.5 of [RFC8446]). Therefore, RPC-over-TLS implementations MUST NOT use 0-RTT data. 7.1. The Limitations of Opportunistic Security Readers can find the definition of Opportunistic Security in [RFC7435]. A discussion of its underlying principals appears in Section 3 of that document. The purpose of using an explicitly opportunistic approach is to enable interoperation with implementations that do not support RPC- over-TLS. A range of options is allowed by this approach, from "no peer authentication or encryption" to "server-only authentication with encryption" to "mutual authentication with encryption". The actual security level may indeed be selected based on policy and without user intervention. In environments where interoperability is a priority, the security benefits of TLS are partially or entirely waived. Implementations of the mechanism described in the current document must take care to accurately represent to all RPC consumers the level of security that is actually in effect, and are REQUIRED to provide an audit log of RPC-over-TLS security mode selection. Myklebust & Lever Expires 27 May 2021 [Page 16] Internet-Draft RPC-Over-TLS November 2020 In all other cases, the adoption, implementation, and deployment of RPC-based upper-layer protocols that enforce the use of TLS authentication and encryption (when similar RPCSEC GSS services are not in use) is strongly encouraged. 7.1.1. STRIPTLS Attacks A classic form of attack on network protocols that initiate an association in plain-text to discover support for TLS is a man-in- the-middle that alters the plain-text handshake to make it appear as though TLS support is not available on one or both peers. Client implementers can choose from the following to mitigate STRIPTLS attacks: * A TLSA record [RFC6698] can alert clients that TLS is expected to work, and provide a binding of hostname to X.509 identity. If TLS cannot be negotiated or authentication fails, the client disconnects and reports the problem. When an opportunistic security policy is in place, a client SHOULD check for the existence of a TLSA record for the target server before initiating an RPC-over-TLS association. * Client security policy can require that a TLS session is established on every connection. If an attacker spoofs the handshake, the client disconnects and reports the problem. This policy prevents an attacker from causing the client to silently fall back to plaintext. If TLSA records are not available, this approach is strongly encouraged. 7.1.2. Privacy Leakage Before Session Establishment As mentioned earlier, communication between an RPC client and server appears in the clear on the network prior to the establishment of a TLS session. This clear-text information usually includes transport connection handshake exchanges, the RPC NULL procedure probing support for TLS, and the initial parts of TLS session establishment. Appendix C of [RFC8446] discusses precautions that can mitigate exposure during the exchange of connection handshake information and TLS certificate material that might enable attackers to track the RPC client. Note that when PSK authentication is used, the PSK identifier is exposed during the TLS handshake, and can be used to track the RPC client. Any RPC traffic that appears on the network before a TLS session has been established is vulnerable to monitoring or undetected modification. A secure client implementation limits or prevents any RPC exchanges that are not protected. Myklebust & Lever Expires 27 May 2021 [Page 17] Internet-Draft RPC-Over-TLS November 2020 The exception to this edict is the initial RPC NULL procedure that acts as a STARTTLS message, which cannot be protected. This RPC NULL procedure contains no arguments or results, and the AUTH_TLS authentication flavor it uses does not contain user information, so there is negligible privacy impact from this exception. 7.2. TLS Identity Management on Clients The goal of the RPC-over-TLS protocol extension is to hide the content of RPC requests while they are in transit. The RPC-over-TLS protocol by itself cannot protect against exposure of a user's RPC requests to other users on the same client. Moreover, client implementations are free to transmit RPC requests for more than one RPC user using the same TLS session. Depending on the details of the client RPC implementation, this means that the client's TLS credentials are potentially visible to every RPC user that shares a TLS session. Privileged users may also be able to access this TLS identity. As a result, client implementations need to carefully segregate TLS credentials so that local access to it is restricted to only the local users that are authorized to perform operations on the remote RPC server. 7.3. Security Considerations for AUTH_SYS on TLS Using a TLS-protected transport when the AUTH_SYS authentication flavor is in use addresses several longstanding weaknesses in AUTH_SYS (as detailed in Appendix A). TLS augments AUTH_SYS by providing both integrity protection and confidentiality that AUTH_SYS lacks. TLS protects data payloads, RPC headers, and user identities against monitoring and alteration while in transit. TLS guards against in-transit insertion and deletion of RPC messages, thus ensuring the integrity of the message stream between RPC client and server. DTLS does not provide full message stream protection, but it does enable receivers to reject non-participant messages. In particular, transport layer encryption plus peer authentication protects receiving XDR decoders from deserializing untrusted data, a common coding vulnerability. However, these decoders would still be exposed to untrusted input in the case of the compromise of a trusted peer or Certificate Authority. The use of TLS enables strong authentication of the communicating RPC peers, providing a degree of non-repudiation. When AUTH_SYS is used with TLS, but the RPC client is unauthenticated, the RPC server still acts on RPC requests for which there is no trustworthy Myklebust & Lever Expires 27 May 2021 [Page 18] Internet-Draft RPC-Over-TLS November 2020 authentication. In-transit traffic is protected, but the RPC client itself can still misrepresent user identity without server detection. TLS without authentication is an improvement from AUTH_SYS without encryption, but it leaves a critical security exposure. In light of the above, when AUTH_SYS is used, the use of a TLS mutual authentication mechanism is RECOMMENDED to prove that the RPC client is known to the RPC server. The server can then determine whether the UIDs and GIDs in AUTH_SYS requests from that client can be accepted, based on the authenticated identity of the client. The use of TLS does not enable RPC clients to detect compromise that leads to the impersonation of RPC users. Also, there continues to be a requirement that the mapping of 32-bit user and group ID values to user identities is the same on both the RPC client and server. 7.4. Best Security Policy Practices RPC-over-TLS implementations and deployments are strongly encouraged to adhere to the following policies to achieve the strongest possible security with RPC-over-TLS. * When using AUTH_NULL or AUTH_SYS, both peers are RECOMMENDED to have DNSSEC TLSA records, keys with which to perform mutual peer authentication using one of the methods described in Section 5.2, and a security policy that requires mutual peer authentication and rejection of a connection when host authentication fails. * RPCSEC GSS provides integrity and privacy services which are largely redundant when TLS is in use. These services SHOULD be disabled in that case. 8. IANA Considerations RFC Editor: In the following subsections, please replace RFC-TBD with the RFC number assigned to this document. And, please remove this Editor's Note before this document is published. 8.1. RPC Authentication Flavor Following Appendix B of [RFC5531], the authors request a single new entry in the RPC Authentication Flavor Numbers registry. The purpose of the new authentication flavor is to signal the use of TLS with RPC. This new flavor is not a pseudo-flavor. The fields in the new entry are assigned as follows: Identifier String: AUTH_TLS Myklebust & Lever Expires 27 May 2021 [Page 19] Internet-Draft RPC-Over-TLS November 2020 Flavor Name: TLS Value: 7 (to be confirmed by IANA) Description: Indicates support for RPC-over-TLS. Reference: RFC-TBD 8.2. ALPN Identifier for SUNRPC Following Section 6 of [RFC7301], the authors request the allocation of the following value in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry. The "sunrpc" string identifies SunRPC when used over TLS. Protocol: SunRPC Identification Sequence: 0x73 0x75 0x6e 0x72 0x70 0x63 ("sunrpc") Reference: RFC-TBD 8.3. Object Identifier for PKIX Extended Key Usage RFC Editor: In the following subsection, please replace XXX and YYY with the IANA numbers assigned to these new entries. And, please remove this Editor's Note before this document is published. Per the Specification Required policy as defined in Section 4.6 of [RFC8126], the authors request the reservation of the following new values: * The RPC-over-TLS ASN.1 module in the "SMI Security for PKIX Extended Key Purpose" registry (1.3.6.1.5.5.7.3) (see Section 5.2.1.1 and Appendix B. * The RPC-over-TLS client certificate extended key usage (1.3.6.1.5.5.7.3.XXX). The description of this new entry should be "id-kp-rpcTLSClient". * The RPC-over-TLS server certificate extended key usage (1.3.6.1.5.5.7.3.YYY). The description of this new entry should be "id-kp-rpcTLSServer". IANA should use the current document (RFC-TBD) as the reference for the new entries. 9. References Myklebust & Lever Expires 27 May 2021 [Page 20] Internet-Draft RPC-Over-TLS November 2020 9.1. Normative References [I-D.ietf-kitten-tls-channel-bindings-for-tls13] Whited, S., "Channel Bindings for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-kitten-tls-channel- bindings-for-tls13-00, 11 June 2020, . [I-D.ietf-tls-dtls-connection-id] Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Identifiers for DTLS 1.2", Work in Progress, Internet- Draft, draft-ietf-tls-dtls-connection-id-07, 21 October 2019, . [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- dtls13-38, 29 May 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . Myklebust & Lever Expires 27 May 2021 [Page 21] Internet-Draft RPC-Over-TLS November 2020 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [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, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [X.509] International Telephone and Telegraph Consultative Committee, "ITU-T X.509 - Information technology - The Directory: Public-key and attribute certificate frameworks.", ISO/IEC 9594-8, CCITT Recommendation X.509, October 2019. 9.2. Informative References [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, DOI 10.17487/RFC1833, August 1995, . [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, DOI 10.17487/RFC2203, September 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . Myklebust & Lever Expires 27 May 2021 [Page 22] Internet-Draft RPC-Over-TLS November 2020 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . [RFC8166] Lever, C., Ed., Simpson, W., and T. Talpey, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", RFC 8166, DOI 10.17487/RFC8166, June 2017, . [RFC8167] Lever, C., "Bidirectional Remote Procedure Call on RPC- over-RDMA Transports", RFC 8167, DOI 10.17487/RFC8167, June 2017, . [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, . Appendix A. Known Weaknesses of the AUTH_SYS Authentication Flavor The ONC RPC protocol, as specified in [RFC5531], provides several modes of security, traditionally referred to as "authentication flavors". Some of these flavors provide much more than an authentication service. We refer to these as authentication flavors, security flavors, or simply, flavors. One of the earliest and most basic flavors is AUTH_SYS, also known as AUTH_UNIX. Appendix A of [RFC5531] specifies AUTH_SYS. AUTH_SYS assumes that the RPC client and server both use POSIX-style user and group identifiers (each user and group can be distinctly represented as a 32-bit unsigned integer). It also assumes that the client and server both use the same mapping of user and group to an integer. One user ID, one primary group ID, and up to 16 Myklebust & Lever Expires 27 May 2021 [Page 23] Internet-Draft RPC-Over-TLS November 2020 supplemental group IDs are associated with each RPC request. The combination of these identifies the entity on the client that is making the request. A string identifies peers (hosts) in each RPC request. [RFC5531] does not specify any requirements for this string other than that is no longer than 255 octets. It does not have to be the same from request to request. Also, it does not have to match the DNS hostname of the sending host. For these reasons, even though most implementations fill in their hostname in this field, receivers typically ignore its content. Appendix A of [RFC5531] contains a brief explanation of security considerations: | It should be noted that use of this flavor of authentication does | not guarantee any security for the users or providers of a | service, in itself. The authentication provided by this scheme | can be considered legitimate only when applications using this | scheme and the network can be secured externally, and privileged | transport addresses are used for the communicating end-points (an | example of this is the use of privileged TCP/UDP ports in UNIX | systems -- note that not all systems enforce privileged transport | address mechanisms). It should be clear, therefore, that AUTH_SYS by itself (i.e., without strong client authentication) offers little to no communication security: 1. It does not protect the confidentiality or integrity of RPC requests, users, or payloads, relying instead on "external" security. 2. It does not provide authentication of RPC peer machines, other than inclusion of an unprotected domain name. 3. The use of 32-bit unsigned integers as user and group identifiers is problematic because these data types are not cryptographically signed or otherwise verified by any authority. In addition, the mapping of these integers to users and groups has to be consistent amongst a server and its cohort of clients. 4. Because the user and group ID fields are not integrity-protected, AUTH_SYS does not provide non-repudiation. Myklebust & Lever Expires 27 May 2021 [Page 24] Internet-Draft RPC-Over-TLS November 2020 Appendix B. ASN.1 Module RFC Editor: In the following section, please replace XXX and YYY with the IANA numbers assigned to these new entries. And, please remove this Editor's Note before this document is published. -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- Extended Key Usage Values id-kp-rpcTLSClient OBJECT IDENTIFIER ::= { id-kp XXX } id-kp-rpcTLSServer OBJECT IDENTIFIER ::= { id-kp YYY } Acknowledgments Special mention goes to Charles Fisher, author of "Encrypting NFSv4 with Stunnel TLS" (https://www.linuxjournal.com/content/encrypting- nfsv4-stunnel-tls). His article inspired the mechanism described in the current document. Many thanks to Tigran Mkrtchyan and Rick Macklem for their work on prototype implementations and feedback on the current document. Thanks to Derrell Piper for numerous suggestions that improved both this simple mechanism and the current document's security-related discussion. Many thanks to Transport Area Director Magnus Westerlund for his sharp questions and careful reading of the final revisions of the current document. The text of Section 5.1.2 is mostly his contribution. Also, thanks to Benjamin Kaduk for his expert guidance on the use of PKIX and TLS. In addition, the authors thank the other members of the IESG for their astute review comments. These contributors made this a significantly better document. The authors are additionally grateful to Bill Baker, David Black, Alan DeKok, Lars Eggert, Olga Kornievskaia, Greg Marsden, Alex McDonald, Justin Mazzola Paluska, Tom Talpey, Martin Thomson, and Nico Williams, for their input and support of this work. Myklebust & Lever Expires 27 May 2021 [Page 25] Internet-Draft RPC-Over-TLS November 2020 Finally, special thanks to NFSV4 Working Group Chair and document shepherd David Noveck, NFSV4 Working Group Chairs Spencer Shepler and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their guidance and oversight. Authors' Addresses Trond Myklebust Hammerspace Inc 4300 El Camino Real Ste 105 Los Altos, CA 94022 United States of America Email: trond.myklebust@hammerspace.com Charles Lever (editor) Oracle Corporation United States of America Email: chuck.lever@oracle.com Myklebust & Lever Expires 27 May 2021 [Page 26] ./draft-ietf-oauth-jwsreq-30.txt0000644000764400076440000021573213726544653016035 0ustar iustyiusty OAuth Working Group N. Sakimura Internet-Draft NAT.Consulting Intended status: Standards Track J. Bradley Expires: March 14, 2021 Yubico M. Jones Microsoft September 10, 2020 The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) draft-ietf-oauth-jwsreq-30 Abstract The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 14, 2021. Sakimura, et al. Expires March 14, 2021 [Page 1] Internet-Draft OAuth JAR September 2020 Copyright Notice Copyright (c) 2020 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 (https://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 6 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6 3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6 4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 7 5. Authorization Request . . . . . . . . . . . . . . . . . . . . 9 5.1. Passing a Request Object by Value . . . . . . . . . . . . 10 5.2. Passing a Request Object by Reference . . . . . . . . . . 10 5.2.1. URI Referencing the Request Object . . . . . . . . . 11 5.2.2. Request using the "request_uri" Request Parameter . . 12 5.2.3. Authorization Server Fetches Request Object . . . . . 12 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 13 6.1. JWE Encrypted Request Object . . . . . . . . . . . . . . 13 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13 6.3. Request Parameter Assembly and Validation . . . . . . . . 14 7. Authorization Server Response . . . . . . . . . . . . . . . . 14 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 9.1. OAuth Parameters Registration . . . . . . . . . . . . . . 15 9.2. OAuth Authorization Server Metadata Registry . . . . . . 16 9.3. OAuth Dynamic Client Registration Metadata Registry . . . 16 9.4. Media Type Registration . . . . . . . . . . . . . . . . . 17 9.4.1. Registry Contents . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 18 10.2. Request Source Authentication . . . . . . . . . . . . . 18 10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 19 10.4. Risks Associated with request_uri . . . . . . . . . . . 19 10.4.1. DDoS Attack on the Authorization Server . . . . . . 20 Sakimura, et al. Expires March 14, 2021 [Page 2] Internet-Draft OAuth JAR September 2020 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 20 10.5. Downgrade Attack . . . . . . . . . . . . . . . . . . . . 20 10.6. TLS Security Considerations . . . . . . . . . . . . . . 21 10.7. Parameter Mismatches . . . . . . . . . . . . . . . . . . 21 10.8. Cross-JWT Confusion . . . . . . . . . . . . . . . . . . 21 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 11.1. Collection limitation . . . . . . . . . . . . . . . . . 22 11.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 23 11.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 23 11.2.2. Tracking using Request Object URI . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction The Authorization Request in OAuth 2.0 [RFC6749] utilizes query parameter serialization and is typically sent through user agents such as web browsers. For example, the parameters "response_type", "client_id", "state", and "redirect_uri" are encoded in the URI of the request: GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 Host: server.example.com While it is easy to implement, the encoding in the URI does not allow application layer security to be used to provide confidentiality and integrity protection. While TLS is used to offer communication security between the Client and the user-agent as well as the user- agent and the Authorization Server, TLS sessions are terminated in the user-agent. In addition, TLS sessions may be terminated prematurely at some middlebox (such as a load balancer). As the result, the Authorization Request of [RFC6749] has shortcomings in that: (a) the communication through the user agents is not integrity protected and thus the parameters can be tainted (integrity protection failure) (b) the source of the communication is not authenticated (source authentication failure) Sakimura, et al. Expires March 14, 2021 [Page 3] Internet-Draft OAuth JAR September 2020 (c) the communication through the user agents can be monitored (containment / confidentiality failure). Due to these inherent weaknesses, several attacks against the protocol, such as Redirection URI rewriting and Mix-up attack [FETT], have been identified. The use of application layer security mitigates these issues. The use of application layer security allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection. Furthermore, passing the request by reference allows the reduction of over-the-wire overhead. The JWT [RFC7519] encoding has been chosen because of (1) its close relationship with JSON, which is used as OAuth's response format (2) its developer friendliness due to its textual nature (3) its relative compactness compared to XML (4) its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516] (5) the relative ease of JWS and JWE compared to XML Signature and Encryption. The parameters "request" and "request_uri" are introduced as additional authorization request parameters for the OAuth 2.0 [RFC6749] flows. The "request" parameter is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters. Note that, in contrast to RFC 7519, the elements of the Claims Set are encoded OAuth Request Parameters [IANA.OAuth.Parameters], supplemented with only a few of the IANA-managed JSON Web Token Claims [IANA.JWT.Claims] - in particular "iss" and "aud". The JWT in the "request" parameter is integrity protected and source authenticated using JWS. The JWT [RFC7519] can be passed to the authorization endpoint by reference, in which case the parameter "request_uri" is used instead of the "request". Sakimura, et al. Expires March 14, 2021 [Page 4] Internet-Draft OAuth JAR September 2020 Using JWT [RFC7519] as the request encoding instead of query parameters has several advantages: (a) (integrity protection) The request can be signed so that the integrity of the request can be checked. (b) (source authentication) The request can be signed so that the signer can be authenticated. (c) (confidentiality protection) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another (including at and before user-agents). (d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and signed by that third party. The authorization server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances. There are a few cases that request by reference is useful such as: 1. When it is desirable to reduce the size of transmitted request. The use of application layer security increases the size of the request, particularly when public key cryptography is used. 2. When the client does not want to do the application level cryptography. The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the Client so that the Client is authenticated and the channel is TLS protected. This capability is in use by OpenID Connect [OpenID.Core]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Sakimura, et al. Expires March 14, 2021 [Page 5] Internet-Draft OAuth JAR September 2020 2. Terminology For the purposes of this specification, the following terms and definitions in addition to what is defined in OAuth 2.0 Framework [RFC6749], JSON Web Signature [RFC7515], and JSON Web Encryption [RFC7519] apply. 2.1. Request Object JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0 authorization request parameters. 2.2. Request Object URI Absolute URI that references the set of parameters comprising an OAuth 2.0 authorization request. The contents of the resource referenced by the URI are a Request Object (Section 2.1), unless the URI was provided to the client by the same Authorization Server, in which case the content is an implementation detail at the discretion the Authorization Server. The former is to ensure interoperability in cases where the provider of the request_uri is a separate entity from the consumer, such as when a client provides a URI referencing a Request Object stored on the client's backend service and made accessible via HTTPS. In the latter case where the Authorization Server is both provider and consumer of the URI, such as when it offers an endpoint that provides a URI in exchange for a Request Object, this interoperability concern does not apply. 3. Symbols and abbreviated terms The following abbreviations are common to this specification. JSON JavaScript Object Notation JWT JSON Web Token JWS JSON Web Signature JWE JSON Web Encryption URI Uniform Resource Identifier URL Uniform Resource Locator Sakimura, et al. Expires March 14, 2021 [Page 6] Internet-Draft OAuth JAR September 2020 4. Request Object A Request Object (Section 2.1) is used to provide authorization request parameters for an OAuth 2.0 authorization request. It MUST contain all the parameters (including extension parameters) used to process the OAuth 2.0 [RFC6749] authorization request except the "request" and "request_uri" parameters that are defined in this document. The parameters are represented as the JWT claims of the object. Parameter names and string values MUST be included as JSON strings. Since Request Objects are handled across domains and potentially outside of a closed ecosystem, per section 8.1 of [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629]. Numerical values MUST be included as JSON numbers. It MAY include any extension parameters. This JSON [RFC7159] object constitutes the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is then signed or signed and encrypted. To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a JWS signed JWT [RFC7519]. If signed, the Authorization Request Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as members, with their semantics being the same as defined in the JWT [RFC7519] specification. The value of "aud" should be the value of the Authorization Server (AS) "issuer" as defined in RFC8414 [RFC8414]. To encrypt, JWE [RFC7516] is used. When both signature and encryption are being applied, the JWT MUST be signed then encrypted as described in Section 11.2 of [RFC7519]. The result is a Nested JWT, as defined in [RFC7519]. The client determines the algorithms used to sign and encrypt Request Objects. The algorithms chosen need to be supported by both the client and the authorization server. The client can inform the authorization server of the algorithms that it supports in its dynamic client registration metadata [RFC7591], specifically, the metadata values "request_object_signing_alg", "request_object_encryption_alg", and "request_object_encryption_enc". Likewise, the authorization server can inform the client of the algorithms that it supports in its authorization server metadata [RFC8414], specifically, the metadata values "request_object_signing_alg_values_supported", "request_object_encryption_alg_values_supported", and "request_object_encryption_enc_values_supported". The Request Object MAY be sent by value as described in Section 5.1 or by reference as described in Section 5.2. "request" and "request_uri" parameters MUST NOT be included in Request Objects. Sakimura, et al. Expires March 14, 2021 [Page 7] Internet-Draft OAuth JAR September 2020 A Request Object (Section 2.1) has the "mime-type" "application/ oauth-authz-req+jwt". Note that some existing deployments may alternatively be using the type "application/jwt". The following is an example of the Claims in a Request Object before base64url encoding and signing. Note that it includes the extension parameters "nonce" and "max_age". { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type": "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } Signing it with the "RS256" algorithm results in this Request Object value (with line wraps within values for display purposes only): eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g Sakimura, et al. Expires March 14, 2021 [Page 8] Internet-Draft OAuth JAR September 2020 The following RSA public key, represented in JWK format, can be used to validate the Request Object signature in this and subsequent Request Object examples (with line wraps within values for display purposes only): { "kty":"RSA", "kid":"k2bdc", "n":"x5RbkAZkmpRxia65qRQ1wwSMSxQUnS7gcpVTV_cdHmfmG2ltd2yabEO9XadD8 pJNZubINPpmgHh3J1aD9WRwS05ucmFq3CfFsluLt13_7oX5yDRSKX7poXmT_5 ko8k4NJZPMAO8fPToDTH7kHYbONSE2FYa5GZ60CUsFhSonI-dcMDJ0Ary9lxI w5k2z4TAdARVWcS7sD07VhlMMshrwsPHBQgTatlkxyIHXbYdtak8fqvNAwr7O lVEvM_Ipf5OfmdB8Sd-wjzaBsyP4VhJKoi_qdgSzpC694XZeYPq45Sw-q51iF UlcOlTCI7z6jltUtnR6ySn6XDGFnzH5Fe5ypw", "e":"AQAB" } 5. Authorization Request The client constructs the authorization request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format: request REQUIRED unless "request_uri" is specified. The Request Object (Section 2.1) that holds authorization request parameters stated in section 4 of OAuth 2.0 [RFC6749]. If this parameter is present in the authorization request, "request_uri" MUST NOT be present. request_uri REQUIRED unless "request" is specified. The absolute URI as defined by RFC3986 [RFC3986] that is the Request Object URI (Section 2.2) referencing the authorization request parameters stated in section 4 of OAuth 2.0 [RFC6749]. If this parameter is present in the authorization request, "request" MUST NOT be present. client_id REQUIRED. OAuth 2.0 [RFC6749] "client_id". The value MUST match the "request" or "request_uri" Request Object's (Section 2.1) "client_id". The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent. For example, the client directs the end user's user-agent to make the following HTTPS request: Sakimura, et al. Expires March 14, 2021 [Page 9] Internet-Draft OAuth JAR September 2020 GET /authz?client_id=s6BhdRkqt3&request=eyJhbG..AlMGzw HTTP/1.1 Host: server.example.com The value for the request parameter is abbreviated for brevity. The authorization request object MUST be one of the following: (a) JWS signed (b) JWS signed and JWE encrypted The client MAY send the parameters included in the request object duplicated in the query parameters as well for the backward compatibility etc. However, the authorization server supporting this specification MUST only use the parameters included in the request object. 5.1. Passing a Request Object by Value The Client sends the Authorization Request as a Request Object to the Authorization Endpoint as the "request" parameter value. The following is an example of an Authorization Request using the "request" parameter (with line wraps within values for display purposes only): https://server.example.com/authorize?client_id=s6BhdRkqt3& request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6 ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6 ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC 0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W 9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3 j1i7tLR_5Nz-g 5.2. Passing a Request Object by Reference The "request_uri" Authorization Request parameter enables OAuth authorization requests to be passed by reference, rather than by value. This parameter is used identically to the "request" parameter, other than that the Request Object value is retrieved from Sakimura, et al. Expires March 14, 2021 [Page 10] Internet-Draft OAuth JAR September 2020 the resource identified by the specified URI rather than passed by value. The entire Request URI MUST NOT exceed 512 ASCII characters. There are three reasons for this restriction. 1. Many phones in the market as of this writing still do not accept large payloads. The restriction is typically either 512 or 1024 ASCII characters. 2. On a slow connection such as 2G mobile connection, a large URL would cause the slow response and therefore the use of such is not advisable from the user experience point of view. The contents of the resource referenced by the "request_uri" MUST be a Request Object and MUST be reachable by the Authorization Server unless the URI was provided to the client by the Authorization Server. In the first case, the "request_uri" MUST be an "https" URI, as specified in Section 2.7.2 of RFC7230 [RFC7230]. In the second case, it MUST be a URN, as specified in RFC8141 [RFC8141]. The following is an example of the contents of a Request Object resource that can be referenced by a "request_uri" (with line wraps within values for display purposes only): eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g 5.2.1. URI Referencing the Request Object The Client stores the Request Object resource either locally or remotely at a URI the Authorization Server can access. Such facility may be provided by the authorization server or a third party. For example, the authorization server may provide a URL to which the client POSTs the request object and obtains the Request URI. This URI is the Request Object URI, "request_uri". Sakimura, et al. Expires March 14, 2021 [Page 11] Internet-Draft OAuth JAR September 2020 It is possible for the Request Object to include values that are to be revealed only to the Authorization Server. As such, the "request_uri" MUST have appropriate entropy for its lifetime so that the URI is not guessable if publicly retrievable. For the guidance, refer to 5.1.4.2.2 of [RFC6819] and Good Practices for Capability URLs [CapURLs]. It is RECOMMENDED that it be removed after a reasonable timeout unless access control measures are taken. The following is an example of a Request Object URI value (with line wraps within values for display purposes only). In this example, a third-party Trust Framework Provider (TFP) hosts the Request Object. https://tfp.example.org/request.jwt/ GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 5.2.2. Request using the "request_uri" Request Parameter The Client sends the Authorization Request to the Authorization Endpoint. The following is an example of an Authorization Request using the "request_uri" parameter (with line wraps within values for display purposes only): https://server.example.com/authorize? client_id=s6BhdRkqt3 &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM 5.2.3. Authorization Server Fetches Request Object Upon receipt of the Request, the Authorization Server MUST send an HTTP "GET" request to the "request_uri" to retrieve the referenced Request Object, unless it is stored in a way so that it can retrieve it through other mechanism securely, and parse it to recreate the Authorization Request parameters. The following is an example of this fetch process. In this example, a third-party Trust Framework Provider (TFP) hosts the Request Object. GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1 Host: tfp.example.org Sakimura, et al. Expires March 14, 2021 [Page 12] Internet-Draft OAuth JAR September 2020 The following is an example of the fetch response: HTTP/1.1 200 OK Date: Thu, 20 Aug 2020 23:52:39 GMT Server: Apache/2.4.43 (tfp.example.org) Content-type: application/oauth-authz-req+jwt Content-Length: 797 Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g 6. Validating JWT-Based Requests 6.1. JWE Encrypted Request Object If the request object is encrypted, the Authorization Server MUST decrypt the JWT in accordance with the JSON Web Encryption [RFC7516] specification. The result is a signed request object. If decryption fails, the Authorization Server MUST return an "invalid_request_object" error. 6.2. JWS Signed Request Object The Authorization Server MUST validate the signature of the JSON Web Signature [RFC7515] signed Request Object. The signature MUST be validated using the key for that "client_id" and the algorithm specified in the "alg" Header Parameter. If signature validation fails, the Authorization Server MUST return an "invalid_request_object" error. Sakimura, et al. Expires March 14, 2021 [Page 13] Internet-Draft OAuth JAR September 2020 6.3. Request Parameter Assembly and Validation The Authorization Server MUST extract the set of Authorization Request parameters from the Request Object value. The Authorization Server MUST only use the parameters in the Request Object even if the same parameter is provided in the query parameter. The Client ID values in the "client_id" request parameter and in the Request Object "client_id" claim MUST be identical. The Authorization Server then validates the request as specified in OAuth 2.0 [RFC6749]. If the validation fails, then the Authorization Server MUST return an error as specified in OAuth 2.0 [RFC6749]. 7. Authorization Server Response Authorization Server Response is created and sent to the client as in Section 4 of OAuth 2.0 [RFC6749]. In addition, this document uses these additional error values: invalid_request_uri The "request_uri" in the Authorization Request returns an error or contains invalid data. invalid_request_object The request parameter contains an invalid Request Object. request_not_supported The Authorization Server does not support the use of the "request" parameter. request_uri_not_supported The Authorization Server does not support the use of the "request_uri" parameter. 8. TLS Requirements Client implementations supporting the Request Object URI method MUST support TLS following Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [BCP195]. To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a cipher suite that provides confidentiality and integrity protection. HTTP clients MUST also verify the TLS server certificate, using DNS- ID [RFC6125], to avoid man-in-the-middle attacks. The rules and Sakimura, et al. Expires March 14, 2021 [Page 14] Internet-Draft OAuth JAR September 2020 guidelines defined in [RFC6125] apply here, with the following considerations: o Support for DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED. Certification authorities which issue server certificates MUST support the DNS- ID identifier type, and the DNS-ID identifier type MUST be present in server certificates. o DNS names in server certificates MAY contain the wildcard character "*". o Clients MUST NOT use CN-ID identifiers; a CN field may be present in the server certificate's subject name, but MUST NOT be used for authentication within the rules described in [BCP195]. o SRV-ID and URI-ID as described in Section 6.5 of [RFC6125] MUST NOT be used for comparison. 9. IANA Considerations 9.1. OAuth Parameters Registration Since the request object is a JWT, the core JWT claims cannot be used for any purpose in the request object other than for what JWT dictates. Thus, they need to be registered as OAuth Authorization Request parameters to avoid future OAuth extensions using them with different meanings. This specification adds the following values to the "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749]. o Name: "iss" o Parameter Usage Location: authorization request o Change Controller: IETF o Specification Document(s): Section 4.1.1 of [RFC7519] and this document. o Name: "sub" o Parameter Usage Location: authorization request o Change Controller: IETF o Specification Document(s): Section 4.1.2 of [RFC7519] and this document. o Name: "aud" o Parameter Usage Location: authorization request o Change Controller: IETF Sakimura, et al. Expires March 14, 2021 [Page 15] Internet-Draft OAuth JAR September 2020 o Specification Document(s): Section 4.1.3 of [RFC7519] and this document. o Name: "exp" o Parameter Usage Location: authorization request o Change Controller: IETF o Specification Document(s): Section 4.1.4 of [RFC7519] and this document. o Name: "nbf" o Parameter Usage Location: authorization request o Change Controller: IETF o Specification Document(s): Section 4.1.5 of [RFC7519] and this document. o Name: "iat" o Parameter Usage Location: authorization request o Change Controller: IETF o Specification Document(s): Section 4.1.6 of [RFC7519] and this document. o Name: "jti" o Parameter Usage Location: authorization request o Change Controller: IETF o Specification Document(s): Section 4.1.7 of [RFC7519] and this document. 9.2. OAuth Authorization Server Metadata Registry This specification adds the following values to the "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414]. o Metadata Name: "require_signed_request_object" o Metadata Description: Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter". o Change Controller: IETF o Specification Document(s): Section 10.5 of this document. 9.3. OAuth Dynamic Client Registration Metadata Registry This specification adds the following values to the "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Parameters] established by [RFC7591]. o Metadata Name: "require_signed_request_object" Sakimura, et al. Expires March 14, 2021 [Page 16] Internet-Draft OAuth JAR September 2020 o Metadata Description: Indicates where authorization request needs to be protected as Request Object and provided through either "request" or "request_uri parameter". o Change Controller: IETF o Specification Document(s): Section 10.5 of this document. 9.4. Media Type Registration 9.4.1. Registry Contents This section registers the "application/oauth-authz-req+jwt" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838], which can be used to indicate that the content is a JWT containing Request Object claims. o Type name: application o Subtype name: oauth-authz-req+jwt o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: binary; A Request Object is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. o Security considerations: See Section 10 of [[ this specification ]] o Interoperability considerations: n/a o Published specification: Section 4 of [[ this specification ]] o Applications that use this media type: Applications that use Request Objects to make an OAuth 2.0 Authorization Request o Fragment identifier considerations: n/a o Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a o Person & email address to contact for further information: Nat Sakimura, nat@nat.consulting o Intended usage: COMMON o Restrictions on usage: none o Author: Nat Sakimura, nat@nat.consulting o Change controller: IETF o Provisional registration? No Sakimura, et al. Expires March 14, 2021 [Page 17] Internet-Draft OAuth JAR September 2020 10. Security Considerations In addition to the all the security considerations discussed in OAuth 2.0 [RFC6819], the security considerations in [RFC7515], [RFC7516], [RFC7518], and [RFC8725] need to be considered. Also, there are several academic papers such as [BASIN] that provide useful insight into the security properties of protocols like OAuth. In consideration of the above, this document advises taking the following security considerations into account. 10.1. Choice of Algorithms When sending the authorization request object through "request" parameter, it MUST either be signed using JWS [RFC7515] or signed then encrypted using JWS [RFC7515] and JWE [RFC7516] respectively, with then considered appropriate algorithms. 10.2. Request Source Authentication The source of the Authorization Request MUST always be verified. There are several ways to do it: (a) Verifying the JWS Signature of the Request Object. (b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. (c) Verifying the TLS Server Identity of the Request Object URI. In this case, the Authorization Server MUST know out-of-band that the Client uses Request Object URI and only the Client is covered by the TLS certificate. In general, it is not a reliable method. (d) When an Authorization Server implements a service that returns a Request Object URI in exchange for a Request Object, the Authorization Server MUST perform Client Authentication to accept the Request Object and bind the Client Identifier to the Request Object URI it is providing. It MUST validate the signature, per (a). Since Request Object URI can be replayed, the lifetime of the Request Object URI MUST be short and preferably one-time use. The entropy of the Request Object URI MUST be sufficiently large. The adequate shortness of the validity and the entropy of the Request Object URI depends on the risk calculation based on the value of the resource being protected. A general guidance for the validity time would be less than a minute and the Request Object URI is to include a Sakimura, et al. Expires March 14, 2021 [Page 18] Internet-Draft OAuth JAR September 2020 cryptographic random value of 128bit or more at the time of the writing of this specification. (e) When a third party, such as a Trust Framework Provider(TFP), implements a service that returns a Request Object URI in exchange for a Request Object, it MUST validate the signature, per (a). In addition, the Authorization Server MUST be a member of the trust framework and MUST know out-of-band that the client also uses the trust framework. 10.3. Explicit Endpoints Although this specification does not require them, research such as [BASIN] points out that it is a good practice to explicitly state the intended interaction endpoints and the message position in the sequence in a tamper evident manner so that the intent of the initiator is unambiguous. The following endpoints defined in [RFC6749], [RFC6750], and [RFC8414] are RECOMMENDED by this specification to use this practice : (a) Protected Resources ("protected_resources") (b) Authorization Endpoint ("authorization_endpoint") (c) Redirection URI ("redirect_uri") (d) Token Endpoint ("token_endpoint") Further, if dynamic discovery is used, then this practice also applies to the discovery related endpoints. In [RFC6749], while Redirection URI is included in the Authorization Request, others are not. As a result, the same applies to Authorization Request Object. The lack of linkage among those endpoints is cited as the cause of the Cross-Phase Attacks described in [FETT]. An extension specification could be created providing this linkage as a means to address the risks. 10.4. Risks Associated with request_uri The introduction of "request_uri" introduces several attack possibilities. Consult the security considerations in Section 7 of RFC3986 [RFC3986] for more information regarding risks associated with URIs. Sakimura, et al. Expires March 14, 2021 [Page 19] Internet-Draft OAuth JAR September 2020 10.4.1. DDoS Attack on the Authorization Server A set of malicious client can launch a DoS attack to the authorization server by pointing the "request_uri" to a URI that returns extremely large content or extremely slow to respond. Under such an attack, the server may use up its resource and start failing. Similarly, a malicious client can specify the "request_uri" value that itself points to an authorization request URI that uses "request_uri" to cause the recursive lookup. To prevent such attack to succeed, the server should (a) check that the value of "request_uri" parameter does not point to an unexpected location, (b) check the content type of the response is "application/ oauth-authz-req+jwt", (c) implement a time-out for obtaining the content of "request_uri", and (d) not perform recursive GET on the "request_uri". 10.4.2. Request URI Rewrite The value of "request_uri" is not signed thus it can be tampered by Man-in-the-browser attacker. Several attack possibilities rise because of this, e.g., (a) attacker may create another file that the rewritten URI points to making it possible to request extra scope (b) attacker launches a DoS attack to a victim site by setting the value of "request_uri" to be that of the victim. To prevent such attack to succeed, the server should (a) check that the value of "request_uri" parameter does not point to an unexpected location, (b) check the content type of the response is "application/ oauth-authz-req+jwt", and (c) implement a time-out for obtaining the content of "request_uri". 10.5. Downgrade Attack Unless the protocol used by client and the server is locked down to use OAuth JAR, it is possible for an attacker to use RFC6749 requests to bypass all the protection provided by this specification. To prevent it, this specification defines a new client metadata and server metadata "require_signed_request_object" whose value is a boolean. When the value of it as a client metadata is "true", then the server MUST reject the authorization request from the client that does not conform to this specification. It MUST also reject the request if the request object uses "alg":"none". If omitted, the default value is "false". Sakimura, et al. Expires March 14, 2021 [Page 20] Internet-Draft OAuth JAR September 2020 When the value of it as a server metadata is "true", then the server MUST reject the authorization request from any client that does not conform to this specification. It MUST also reject the request if the request object uses "alg":"none". If omitted, the default value is "false". 10.6. TLS Security Considerations Current security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version recommendations in OAuth 2.0 [RFC6749]. 10.7. Parameter Mismatches Given that OAuth parameter values are being sent in two different places, as normal OAuth parameters and as Request Object claims, implementations must guard against attacks that could use mismatching parameter values to obtain unintended outcomes. That is the reason that the two Client ID values MUST match, the reason that only the parameter values from the Request Object are to be used, and the reason that neither "request" nor "request_uri" can appear in a Request Object. 10.8. Cross-JWT Confusion As described in Section 2.8 of [RFC8725], attackers may attempt to use a JWT issued for one purpose in a context that it was not intended for. The mitigations described for these attacks can be applied to Request Objects. One way that an attacker might attempt to repurpose a Request Object is to try to use it as a client authentication JWT, as described in Section 2.2 of [RFC7523]. A simple way to prevent this is to never use the Client ID as the "sub" value in a Request Object. Another way to prevent cross-JWT confusion is to use explicit typing, as described in Section 3.11 of [RFC8725]. One would explicitly type a Request Object by including a "typ" Header Parameter with the value "oauth-authz-req+jwt" (which is registered in Section 9.4.1. Note however, that requiring explicitly typed Requests Objects at existing authorization servers will break most existing deployments, as existing clients are already commonly using untyped Request Objects, especially with OpenID Connect [OpenID.Core]. However, requiring explicit typing would be a good idea for new OAuth deployment profiles where compatibility with existing deployments is not a consideration. Sakimura, et al. Expires March 14, 2021 [Page 21] Internet-Draft OAuth JAR September 2020 11. Privacy Considerations When the Client is being granted access to a protected resource containing personal data, both the Client and the Authorization Server need to adhere to Privacy Principles. RFC 6973 Privacy Considerations for Internet Protocols [RFC6973] gives excellent guidance on the enhancement of protocol design and implementation. The provision listed in it should be followed. Most of the provision would apply to The OAuth 2.0 Authorization Framework [RFC6749] and The OAuth 2.0 Authorization Framework: Bearer Token Usage [RFC6750] and are not specific to this specification. In what follows, only the specific provisions to this specification are noted. 11.1. Collection limitation When the Client is being granted access to a protected resource containing personal data, the Client SHOULD limit the collection of personal data to that which is within the bounds of applicable law and strictly necessary for the specified purpose(s). It is often hard for the user to find out if the personal data asked for is strictly necessary. A Trust Framework Provider can help the user by examining the Client request and comparing to the proposed processing by the Client and certifying the request. After the certification, the Client, when making an Authorization Request, can submit Authorization Request to the Trust Framework Provider to obtain the Request Object URI. This process is two steps: (1) (Certification Process) The TFP examines the business process of the client and determines what claims they need: This is the certification process. Once the client is certified, then they are issued a client credential to authenticate against to push request objects to the TFP to get the "request_uri". (2) (Translation Process) The client uses the client credential that it got to push the request object to the TFP to get the "request_uri". The TFP also verifies that the Request Object is consistent with the claims that the client is eligible for, per prior step. Upon receiving such Request Object URI in the Authorization Request, the Authorization Server first verifies that the authority portion of the Request Object URI is a legitimate one for the Trust Framework Provider. Then, the Authorization Server issues HTTP GET request to the Request Object URI. Upon connecting, the Authorization Server MUST verify the server identity represented in the TLS certificate is Sakimura, et al. Expires March 14, 2021 [Page 22] Internet-Draft OAuth JAR September 2020 legitimate for the Request Object URI. Then, the Authorization Server can obtain the Request Object, which includes the "client_id" representing the Client. The Consent screen MUST indicate the Client and SHOULD indicate that the request has been vetted by the Trust Framework Operator for the adherence to the Collection Limitation principle. 11.2. Disclosure Limitation 11.2.1. Request Disclosure This specification allows extension parameters. These may include potentially sensitive information. Since URI query parameter may leak through various means but most notably through referrer and browser history, if the authorization request contains a potentially sensitive parameter, the Client SHOULD JWE [RFC7516] encrypt the request object. Where Request Object URI method is being used, if the request object contains personally identifiable or sensitive information, the "request_uri" SHOULD be used only once, have a short validity period, and MUST have large enough entropy deemed necessary with applicable security policy unless the Request Object itself is JWE [RFC7516] Encrypted. The adequate shortness of the validity and the entropy of the Request Object URI depends on the risk calculation based on the value of the resource being protected. A general guidance for the validity time would be less than a minute and the Request Object URI is to include a cryptographic random value of 128bit or more at the time of the writing of this specification. 11.2.2. Tracking using Request Object URI Even if the protected resource does not include a personally identifiable information, it is sometimes possible to identify the user through the Request Object URI if persistent static per-user Request Object URIs are used. A third party may observe it through browser history etc. and start correlating the user's activity using it. In a way, it is a data disclosure as well and should be avoided. Therefore, per-user persistent Request Object URIs should be avoided. Single-use Request Object URIs are one alternative. 12. Acknowledgements The following people contributed to the creation of this document in the OAuth working group and other IETF roles. (Affiliations at the time of the contribution are used.) Sakimura, et al. Expires March 14, 2021 [Page 23] Internet-Draft OAuth JAR September 2020 Annabelle Backman (Amazon), Sergey Beryozkin, Ben Campbell (as AD), Brian Campbell (Ping Identity), Roman Danyliw (as AD), Vladimir Dzhuvinov (Connect2id), Joel Halpern (as GENART), Benjamin Kaduk (as AD), Stephen Kent (as SECDIR), Murray Kucherawy (as AD), Warren Kumari (as OPSDIR), Torsten Lodderstedt (yes.com), Jim Manico, Axel Nennker (Deutsche Telecom), Hannes Tschofenig (ARM), Dirk Balfanz (Google), James H. Manger (Telstra), Kathleen Moriarty (as AD), John Panzer (Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke Shepard (Facebook), Filip Skokan (Auth0), Eric Vyncke (as AD), and Robert Wilton (as AD). The following people contributed to creating this document through the OpenID Connect Core 1.0 [OpenID.Core]. Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou (Mixi), Edmund Jay (Illumila), Breno de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE). 13. Revision History Note to the RFC Editor: Please remove this section from the final RFC. -30 o Changed the MIME Type from "oauth.authz.req+jwt" to "oauth-authz- req+jwt", per advice from the designated experts. -29 o Uniformly use the Change Controller "IETF". -28 o Removed unused references, as suggested by Roman Danyliw. -27 o Edits by Mike Jones to address IESG and working group review comments, including: o Added Security Considerations text saying not to use the Client ID as the "sub" value to prevent Cross-JWT Confusion. o Added Security Considerations text about using explicit typing to prevent Cross-JWT Confusion. o Addressed Eric Vyncke's review comments. Sakimura, et al. Expires March 14, 2021 [Page 24] Internet-Draft OAuth JAR September 2020 o Addressed Robert Wilton's review comments. o Addressed Murray Kucherawy's review comments. o Addressed Benjamin Kaduk's review comments. o Applied spelling and grammar corrections. -20 o BK comments o Section 3 Removed WAP o Section 4. Clarified authorization request object parameters, removed extension parameters from examples o Section 4. Specifies application/oauth.authz.req+jwt as mime-type fore request objects o Section 5.2.1 Added reference to Capability URLs o Section 5.2.3. Added entropy fragment to example request o Section 8. Replaced "subjectAltName dnsName" with "DNS-ID" o Section 9. Registers authorization request parameters in JWT Claims Registry. o Section 9. Registers application/oauth.authz.req in IANA mime- types registry o Section 10.1. Clarified encrypted request objects are "signed then encrypted" to maintain consistency o Section 10.2. Clarifies trust between AS and TFP o Section 10.3. Clarified endpoints subject to the practice o Section 10.4 Replaced "redirect_uri" to "request_uri" o Section 10.4. Added reference to RFC 3986 for risks o Section 10.4.1.d Deleted "do" to maintain grammar flow o Section 10.4.1, 10.4.2 Replaced "application/jose" to "application/jwt" Sakimura, et al. Expires March 14, 2021 [Page 25] Internet-Draft OAuth JAR September 2020 o Section 12.1. Extended description for submitting authorization request to TFP to obtain request object o Section 12.2.2. Replaced per-user Request Object URI with static per-user Request URIs o Section 13. Combined OAuth WG contributors together o Section Whole doc Replaced application/jwt with application/ oauth.authz.req+jwt -19 o AD comments o Section 5.2.1. s/Requiest URI/Request URI/ o Section 8 s/[BCP195] ./[BCP195]./ o Section 10.3. s/sited/cited/ o Section 11. Typo. s/Curent/Current/ -17 o #78 Typos in content-type -16 o Treated remaining Ben Campbell comments. -15 o Removed further duplication -14 o #71 Reiterate dynamic params are included. o #70 Made clear that AS must return error. o #69 Inconsistency of the need to sign. o Fixed Mimetype. o #67 Inconsistence in requiring HTTPS in request URI. o #66 Dropped ISO 29100 reference. Sakimura, et al. Expires March 14, 2021 [Page 26] Internet-Draft OAuth JAR September 2020 o #25 Removed Encrypt only option. o #59 Same with #25. -13 o add TLS Security Consideration section o replace RFC7525 reference with BCP195 o moved front tag in FETT reference to fix XML structure o changes reference from SoK to FETT -12 o fixes #62 - Alexey Melnikov Discuss o fixes #48 - OPSDIR Review : General - delete semicolons after list items o fixes #58 - DP Comments for the Last Call o fixes #57 - GENART - Remove "non-normative ... " from examples. o fixes #45 - OPSDIR Review : Introduction - are attacks discovered or already opened o fixes #49 - OPSDIR Review : Introduction - Inconsistent colons after initial sentence of list items. o fixes #53 - OPSDIR Review : 6.2 JWS Signed Request Object - Clarify JOSE Header o fixes #42 - OPSDIR Review : Introduction - readability of 'and' is confusing o fixes #50 - OPSDIR Review : Section 4 Request Object - Clarify 'signed, encrypted, or signed and encrypted' o fixes #39 - OPSDIR Review : Abstract - Explain/Clarify JWS and JWE o fixed #50 - OPSDIR Review : Section 4 Request Object - Clarify 'signed, encrypted, or signed and encrypted' o fixes #43 - OPSDIR Review : Introduction - 'properties' sounds awkward and are not exactly 'properties' Sakimura, et al. Expires March 14, 2021 [Page 27] Internet-Draft OAuth JAR September 2020 o fixes #56 - OPSDIR Review : 12 Acknowledgements - 'contribution is' => 'contribution are' o fixes #55 - OPSDIR Review : 11.2.2 Privacy Considerations - ' It is in a way' => 'In a way, it is' o fixes #54 - OPSDIR Review : 11 Privacy Considerations - 'and not specific' => 'and are not specific' o fixes #51 - OPSDIR Review : Section 4 Request Object - 'It is fine' => 'It is recommended' o fixes #47 - OPSDIR Review : Introduction - 'over- the- wire' => 'over-the-wire' o fixes #46 - OPSDIR Review : Introduction - 'It allows' => 'The use of application security' for o fixes #44 - OPSDIR Review : Introduction - 'has' => 'have' o fixes #41 - OPSDIR Review : Introduction - missing 'is' before 'typically sent' o fixes #38 - OPSDIR Review : Section 11 - Delete 'freely accessible' regarding ISO 29100 -11 o s/bing/being/ o Added history for -10 -10 o #20: KM1 -- some wording that is awkward in the TLS section. o #21: KM2 - the additional attacks against OAuth 2.0 should also have a pointer o #22: KM3 -- Nit: in the first line of 10.4: o #23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100 o #24: SECDIR review: Section 4 -- Confusing requirements for sign+encrypt o #25: SECDIR review: Section 6 -- authentication and integrity need not be provided if the requestor encrypts the token? Sakimura, et al. Expires March 14, 2021 [Page 28] Internet-Draft OAuth JAR September 2020 o #26: SECDIR Review: Section 10 -- why no reference for JWS algorithms? o #27: SECDIR Review: Section 10.2 - how to do the agreement between client and server "a priori"? o #28: SECDIR Review: Section 10.3 - Indication on "large entropy" and "short lifetime" should be indicated o #29: SECDIR Review: Section 10.3 - Typo o #30: SECDIR Review: Section 10.4 - typos and missing articles o #31: SECDIR Review: Section 10.4 - Clearer statement on the lack of endpoint identifiers needed o #32: SECDIR Review: Section 11 - ISO29100 needs to be moved to normative reference o #33: SECDIR Review: Section 11 - Better English and Entropy language needed o #34: Section 4: Typo o #35: More Acknowledgment o #36: DP - More precise qualification on Encryption needed. -09 o Minor Editorial Nits. o Section 10.4 added. o Explicit reference to Security consideration (10.2) added in section 5 and section 5.2. o , (add yourself) removed from the acknowledgment. -08 o Applied changes proposed by Hannes on 2016-06-29 on IETF OAuth list recorded as https://bitbucket.org/Nat/oauth-jwsreq/ issues/12/. o TLS requirements added. o Security Consideration reinforced. Sakimura, et al. Expires March 14, 2021 [Page 29] Internet-Draft OAuth JAR September 2020 o Privacy Consideration added. o Introduction improved. -07 o Changed the abbrev to OAuth JAR from oauth-jar. o Clarified sig and enc methods. o Better English. o Removed claims from one of the example. o Re-worded the URI construction. o Changed the example to use request instead of request_uri. o Clarified that Request Object parameters take precedence regardless of request or request_uri parameters were used. o Generalized the language in 4.2.1 to convey the intent more clearly. o Changed "Server" to "Authorization Server" as a clarification. o Stopped talking about request_object_signing_alg. o IANA considerations now reflect the current status. o Added Brian Campbell to the contributors list. Made the lists alphabetic order based on the last names. Clarified that the affiliation is at the time of the contribution. o Added "older versions of " to the reference to IE URI length limitations. o Stopped talking about signed or unsigned JWS etc. o 1.Introduction improved. -06 o Added explanation on the 512 chars URL restriction. o Updated Acknowledgements. -05 Sakimura, et al. Expires March 14, 2021 [Page 30] Internet-Draft OAuth JAR September 2020 o More alignment with OpenID Connect. -04 o Fixed typos in examples. (request_url -> request_uri, cliend_id -> client_id) o Aligned the error messages with the OAuth IANA registry. o Added another rationale for having request object. -03 o Fixed the non-normative description about the advantage of static signature. o Changed the requirement for the parameter values in the request itself and the request object from 'MUST MATCH" to 'Req Obj takes precedence. -02 o Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. -01 o Copy Edits. 14. References 14.1. Normative References [BCP195] 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, May 2015. [IANA.MediaTypes] IANA, "Media Types", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Sakimura, et al. Expires March 14, 2021 [Page 31] Internet-Draft OAuth JAR September 2020 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [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, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . Sakimura, et al. Expires March 14, 2021 [Page 32] Internet-Draft OAuth JAR September 2020 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . 14.2. Informative References [BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication", Journal of Computer Security - Security and Trust Principles Volume 21 Issue 6, Pages 817-846, November 2013, . [CapURLs] Tennison, J., "Good Practices for Capability URLs", W3C Working Draft, February 2014, . [FETT] Fett, D., Kusters, R., and G. Schmitz, "A Comprehensive Formal Security Analysis of OAuth 2.0", CCS '16 Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security Pages 1204-1215 , October 2016, . [IANA.JWT.Claims] IANA, "JSON Web Token Claims", . Sakimura, et al. Expires March 14, 2021 [Page 33] Internet-Draft OAuth JAR September 2020 [IANA.OAuth.Parameters] IANA, "OAuth Parameters", . [OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", OpenID Foundation Standards, February 2014, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . Sakimura, et al. Expires March 14, 2021 [Page 34] Internet-Draft OAuth JAR September 2020 Authors' Addresses Nat Sakimura NAT.Consulting 2-22-17 Naka Kunitachi, Tokyo 186-0004 Japan Phone: +81-42-580-7401 Email: nat@nat.consulting URI: http://nat.sakimura.org/ John Bradley Yubico Casilla 177, Sucursal Talagante Talagante, RM Chile Phone: +1.202.630.5272 Email: ve7jtb@ve7jtb.com URI: http://www.thread-safe.com/ Michael B. Jones Microsoft One Microsoft Way Redmond, Washington 98052 United States of America Email: mbj@microsoft.com URI: https://self-issued.info/ Sakimura, et al. Expires March 14, 2021 [Page 35] ./draft-ietf-opsawg-model-automation-framework-10.txt0000644000764400076440000032136213745466120022137 0ustar iustyiusty OPSAWG Q. Wu, Ed. Internet-Draft Huawei Intended status: Informational M. Boucadair, Ed. Expires: April 28, 2021 Orange D. Lopez Telefonica I+D C. Xie China Telecom L. Geng China Mobile October 25, 2020 A Framework for Automating Service and Network Management with YANG draft-ietf-opsawg-model-automation-framework-10 Abstract Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle, such as service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance. Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; it can thus accommodate YANG modules that are developed outside the IETF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Wu, et al. Expires April 28, 2021 [Page 1] Internet-Draft Service and Network Management Automation October 2020 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 28, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 and Acronyms . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Architectural Concepts and Goals . . . . . . . . . . . . . . 7 3.1. Data Models: Layering and Representation . . . . . . . . 7 3.2. Automation of Service Delivery Procedures . . . . . . . . 12 3.3. Service Fulfillment Automation . . . . . . . . . . . . . 13 3.4. YANG Modules Integration . . . . . . . . . . . . . . . . 13 4. Functional Blocks and Interactions . . . . . . . . . . . . . 14 4.1. Service Lifecycle Management Procedure . . . . . . . . . 15 4.1.1. Service Exposure . . . . . . . . . . . . . . . . . . 15 4.1.2. Service Creation/Modification . . . . . . . . . . . . 15 4.1.3. Service Assurance . . . . . . . . . . . . . . . . . . 16 4.1.4. Service Optimization . . . . . . . . . . . . . . . . 16 4.1.5. Service Diagnosis . . . . . . . . . . . . . . . . . . 16 4.1.6. Service Decommission . . . . . . . . . . . . . . . . 17 4.2. Service Fullfillment Management Procedure . . . . . . . . 17 4.2.1. Intended Configuration Provision . . . . . . . . . . 17 4.2.2. Configuration Validation . . . . . . . . . . . . . . 18 4.2.3. Performance Monitoring . . . . . . . . . . . . . . . 18 4.2.4. Fault Diagnostic . . . . . . . . . . . . . . . . . . 19 4.3. Multi-Layer/Multi-Domain Service Mapping . . . . . . . . 19 4.4. Service Decomposition . . . . . . . . . . . . . . . . . . 19 5. YANG Data Model Integration Examples . . . . . . . . . . . . 20 5.1. L2VPN/L3VPN Service Delivery . . . . . . . . . . . . . . 20 Wu, et al. Expires April 28, 2021 [Page 2] Internet-Draft Service and Network Management Automation October 2020 5.2. VN Lifecycle Management . . . . . . . . . . . . . . . . . 22 5.3. Event-based Telemetry in the Device Self Management . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6.1. Service Level . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 26 6.3. Device Level . . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Layered YANG Modules Examples Overview . . . . . . . 37 A.1. Service Models: Definition and Samples . . . . . . . . . 37 A.2. Schema Mount . . . . . . . . . . . . . . . . . . . . . . 38 A.3. Network Models: Samples . . . . . . . . . . . . . . . . . 38 A.4. Device Models: Samples . . . . . . . . . . . . . . . . . 41 A.4.1. Model Composition . . . . . . . . . . . . . . . . . . 43 A.4.2. Device Management . . . . . . . . . . . . . . . . . . 43 A.4.3. Interface Management . . . . . . . . . . . . . . . . 43 A.4.4. Some Device Model Examples . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction Service management systems usually comprise service activation/ provision and service operation. Current service delivery procedures, from the processing of customer requirements and orders to service delivery and operation, typically assume the manipulation of data sequentially into multiple Operations Support System (OSS) or Business Support System (BSS) applications that may be managed by different departments within the service provider's organization (e.g., billing factory, design factory, network operation center). Many of these applications have been developed in-house over the years and operate in a silo mode: o The lack of standard data input/output (i.e., data model) raises many challenges in system integration and often results in manual configuration tasks. o Service fulfillment systems might have a limited visibility on the network state and therefore have slow response to network changes. Software Defined Networking (SDN) becomes crucial to address these challenges. SDN techniques are meant to automate the overall service delivery procedures and typically rely upon standard data models. These models are used to not only reflect service providers' savoir- faire, but also to dynamically instantiate and enforce a set of Wu, et al. Expires April 28, 2021 [Page 3] Internet-Draft Service and Network Management Automation October 2020 service-inferred policies that best accommodate what has been defined and possibly negotiated with the customer. [RFC7149] provides a first tentative attempt to rationalize that service provider's view on the SDN space by identifying concrete technical domains that need to be considered and for which solutions can be provided: o Techniques for the dynamic discovery of topology, devices, and capabilities, along with relevant information and data models that are meant to precisely document such topology, devices, and their capabilities. o Techniques for exposing network services [RFC8309] and their characteristics. o Techniques used by service-derived dynamic resource allocation and policy enforcement schemes, so that networks can be programmed accordingly. o Dynamic feedback mechanisms that are meant to assess how efficiently a given policy (or a set thereof) is enforced from a service fulfillment and assurance perspectives. Models are key for each of the aforementioned four technical items. Service and network management automation is an important step to improve the agility of network operations. Models are also important to ease integrating multi-vendor solutions. YANG [RFC7950] module developers have taken both top-down and bottom- up approaches to develop modules [RFC8199] and to establish a mapping between a network technology and customer requirements at the top or abstracting common constructs from various network technologies at the bottom. At the time of writing this document (2020), there are many YANG data models including configuration and service models that have been specified or are being specified by the IETF. They cover many of the networking protocols and techniques. However, how these models work together to configure a function, manage a set of devices involved in a service, or provide a service is something that is not currently documented either within the IETF or other Standards Development Organizations (SDOs). Many of the YANG modules listed in this document are used to exchange data between NETCONF/RESTCONF clients and servers [RFC6241][RFC8040]. Nevertheless, YANG is a transport-independent data modeling language. It can thus be used independently of NETCONF/RESTONF. For example, YANG can be used to define abstract data structures [RFC8791] that can be manipulated by other protocols (e.g., [I-D.ietf-dots-rfc8782-bis]). Wu, et al. Expires April 28, 2021 [Page 4] Internet-Draft Service and Network Management Automation October 2020 This document describes an architectural framework for service and network management automation (Section 3) that takes advantage of YANG modeling technologies and investigates how YANG data models at different layers interact with each other (e.g., service mapping, model composition) in the context of service delivery and fulfillment (Section 4). Concretely, the following benefits can be provided: o Allow for vendor-agnostic interfaces to manage a service and the underlying network. o Move from deployment schemes where vendor-specific network managers are required to a scheme where the entities that are responsible for orchestrating and controlling services and network resources provided by multi-vendor devices are unified. o Ease data inheritance and reusability among the various architecture layers thus promoting a network-wise provisioning instead of device-specific configuration. o Dynamically feed a decision-making process (e.g., Controllers, Orchestrators) with notifications that will trigger appropriate actions, allowing that decision-making process to continuously adjust a network (and thus, the involved resources) to deliver the service that conforms to the intended parameters (service objectives). This framework is drawn from a network operator perspective irrespective of the origin of a data model; it can also accommodate YANG modules that are developed outside the IETF. The document covers service models that are used by an operator to expose its services and capture service requirements from the customers (including other operators). Nevertheless, the document does not elaborate on the communication protocol(s) that makes use of these service models in order to request and deliver a service. Such considerations are out of scope. The document identifies a list of use cases to exemplify the proposed approach (Section 5), but it does not claim nor aim to be exhaustive. Appendix A lists some examples to illustrate the layered YANG modules view. 2. Terminology and Acronyms 2.1. Terminology The following terms are defined in [RFC8309][RFC8199] and are not redefined here: Wu, et al. Expires April 28, 2021 [Page 5] Internet-Draft Service and Network Management Automation October 2020 o Network Operator o Customer o Service o Data Model o Service Model o Network Element Module In addition, the document makes use of the following terms: Network Model: Describes a network level abstraction (or a subset of aspects of a network infrastructure), including devices and their subsystems, and relevant protocols operating at the link and network layers across multiple devices. This model corresponds to the network configuration model discussed in [RFC8309]. It can be used by a network operator to allocate resources (e.g., tunnel resource, topology resource) for the service or schedule resources to meet the service requirements defined in a service model. Network Domain: Refers to a network partitioning that is usually followed by network operators to delimit parts of their network. "access network" and "core network" are examples of network domains. Device Model: Refers to the Network Element YANG data model described in [RFC8199] or the device configuration model discussed in [RFC8309]. Device models are also used to refer to model a function embedded in a device (e.g., Network Address Translation (NAT) [RFC8512], Access Control Lists (ACLs) [RFC8519]). Pipe: Refers to a communication scope where only one-to-one (1:1) communications are allowed. The scope can be identified between ingress and egress nodes, two service sites, etc. Hose: Refers to a communication scope where one-to-many (1:N) communications are allowed (e.g., one site to multiple sites). Funnel: Refers to a communication scope where many-to-one (N:1) communications are allowed. Wu, et al. Expires April 28, 2021 [Page 6] Internet-Draft Service and Network Management Automation October 2020 2.2. Acronyms The following acronyms are used in the document: ACL Access Control List AS Autonomous System AP Access Point CE Customer Edge DBE Data Border Element E2E End-to-End ECA Event Condition Action L2VPN Layer 2 Virtual Private Network L3VPN Layer 3 Virtual Private Network L3SM L3VPN Service Model L3NM L3VPN Network Model NAT Network Address Translation OAM Operations, Administration, and Maintenance OWD One-Way Delay PE Provider Edge PM Performance Monitoring QoS Quality of Service RD Route Distinguisher RT Route Target SBE Session Border Element SDN Software Defined Networking SP Service Provider TE Traffic Engineering VN Virtual Network VPN Virtual Private Network VRF Virtual Routing and Forwarding 3. Architectural Concepts and Goals 3.1. Data Models: Layering and Representation As described in Section 2 of [RFC8199], layering of modules allows for better reusability of lower-layer modules by higher-level modules while limiting duplication of features across layers. Data models in the context of network management can be classified into service, network, and device models. Different service models may rely on the same set of network and/or device models. Service models traditionally follow a top-down approach and are mostly customer-facing YANG modules providing a common model construct for higher level network services (e.g., Layer 3 Virtual Private Network (L3VPN)). Such modules can be mapped to network technology-specific modules at lower layers (e.g., tunnel, routing, Wu, et al. Expires April 28, 2021 [Page 7] Internet-Draft Service and Network Management Automation October 2020 Quality of Service (QoS), security). For example, service models can be used to characterise the network service(s) to be ensured between service nodes (ingress/egress) such as: o the communication scope (pipe, hose, funnel, ...), o the directionality (inbound/outbound), o the traffic performance guarantees expressed using metrics such as One-Way Delay (OWD) [RFC7679] or One-Way Loss [RFC7680]; a summary of performance metrics maintained by IANA can be found in [IPPM], o link capacity [RFC5136] [I-D.ietf-ippm-capacity-metric-method], o etc. Figure 1 depicts the example of a VoIP service that relies upon connectivity services offered by a network operator. In this example, the VoIP service is offered to the network operator's customers by Service Provider (SP1). In order to provide global VoIP reachability, SP1 service site interconnects with other Service Providers service sites typically by interconnecting Session Border Elements (SBEs) and Data Border Elements (DBEs) [RFC5486][RFC6406]. For other VoIP destinations, sessions are forwarded over the Internet. These connectivity services can be captured in a YANG service model that reflects the service attributes that are shown in Figure 2. This example follows the IP Connectivity Provisioning Profile template defined in [RFC7297]. In reference to Figure 2, "Full traffic performance guarantees class" refers to a service class where all traffic performance metrics included in the service model (OWD, loss, delay variation) are guaranteed, while "Delay traffic performance guarantees class" refers to a service class where only OWD is guaranteed. Wu, et al. Expires April 28, 2021 [Page 8] Internet-Draft Service and Network Management Automation October 2020 ,--,--,--. ,--,--,--. ,-' SP1 `-. ,-' SP2 `-. ( Service Site ) ( Service Site ) `-. ,-' `-. ,-' `--'--'--' `--'--'--' x | o * * | (2)x | o * * | ,x-,--o-*-. (1) ,--,*-,--. ,-' x o * * * * * * * * * `-. ( x o +----( Internet ) User---(x x x o o o o o o o o o o o o o o o o o o `-. ,-' `-. ,-' (3) `--'--'--' `--'--'--' Network Operator **** (1) Inter-SP connectivity xxxx (2) Customer to SP connectivity oooo (3) SP to any destination connectivity Figure 1: An Example of Service Connectivity Components Connectivity: Scope and Guarantees (1) Inter-SP connectivity - Pipe scope from the local to the remote SBE/DBE - Full traffic performance guarantees class (2) Customer to SP connectivity - Hose/Funnel scope connecting the local SBE/DBE to the customer access points - Full traffic performance guarantees class (3) SP to any destination connectivity - Hose/Funnel scope from the local SBE/DBE to the Internet gateway - Delay traffic performance guarantees class Flow Identification * Destination IP address (SBE, DBE) * DSCP marking Traffic Isolation * VPN Routing & Forwarding * Routing rule to exclude some ASes from the inter-domain paths Notifications (including feedback) * Statistics on aggregate traffic to adjust capacity * Failures * Planned maintenance operations * Triggered by thresholds Figure 2: Sample Attributes Captured in a Service Model Wu, et al. Expires April 28, 2021 [Page 9] Internet-Draft Service and Network Management Automation October 2020 Network models are mainly network resource-facing modules; they describe various aspects of a network infrastructure, including devices and their subsystems, and relevant protocols operating at the link and network layers across multiple devices (e.g., network topology and traffic-engineering tunnel modules). Device (and function) models usually follow a bottom-up approach and are mostly technology-specific modules used to realize a service (e.g., BGP, ACL). Each level maintains a view of the supported YANG modules provided by lower levels (see for example, Appendix A). Mechanisms such as YANG library [RFC8525] can be used to expose which YANG modules are supported by nodes in lower levels. Figure 3 illustrates the overall layering model. The reader may refer to Section 4 of [RFC8309] for an overview of "Orchestrator" and "Controller" elements. All these elements (i.e., Orchestrator(s), Controller(s), device(s)) are under the responsibility of the same operator. Wu, et al. Expires April 28, 2021 [Page 10] Internet-Draft Service and Network Management Automation October 2020 +-----------------------------------------------------------------+ | Hierarchy Abstraction | | | | +-----------------------+ Service Model | | | Orchestrator | (Customer Oriented) | | |+---------------------+| Scope: "1:1" Pipe model | | || Service Modeling || | | |+---------------------+| | | | | Bidirectional | | |+---------------------+| +-+ Capacity, OWD +-+ | | ||Service Orchestration|| | +----------------+ | | | |+---------------------+| +-+ +-+ | | +-----------------------+ Ingress Egress | | | | | | +-----------------------+ Network Model | | | Controller | (Operator Oriented) | | |+---------------------+| +-+ +--+ +---+ +-+ | | || Network Modeling || | | | | | | | | | | |+---------------------+| | o----o--o----o---o---o | | | | | +-+ +--+ +---+ +-+ | | |+---------------------+| src dst | | ||Network Orchestration|| L3VPN over TE | | |+---------------------+| Instance Name/Access Interface | | +-----------------------+ Protocol Type/Capacity/RD/RT/... | | | | | | +-----------------------+ Device Model | | | Device | | | |+--------------------+ | | | || Device Modeling | | Interface add, BGP Peer, | | |+--------------------+ | Tunnel ID, QoS/TE, ... | | +-----------------------+ | +-----------------------------------------------------------------+ Figure 3: Layering and Representation Within a Network Operator A composite service offered by a network operator may rely on services from other operators. In such case, the network operator acts as a customer to request services from other networks. The operators providing these services will then follow the layering depicted in Figure 3. The mapping between a composite service and a third-party service is maintained at the orchestration level. From a data plane perspective, appropriate traffic steering policies (e.g., Service Function Chaining [RFC7665]) are managed by the network controllers to guide how/when a third party service is invoked for flows bound to a composite service. Wu, et al. Expires April 28, 2021 [Page 11] Internet-Draft Service and Network Management Automation October 2020 The layering model depicted in Figure 3 does not make any assumption about the location of the various entities (e.g., controller, orchestrator) within the network. As such, the architecture does not preclude deployments where, for example, the controller is embedded on a device that hosts other functions that are controlled via YANG modules. In order to ease the mapping between layers and data reuse, this document focuses on service models that are modelled using YANG. Nevertheless, fully compliant with Section 3 of [RFC8309], Figure 3 does not preclude service models to be modelled using other data modelling languages than YANG. 3.2. Automation of Service Delivery Procedures Service models can be used by a network operator to expose its services to its customers. Exposing such models allows to automate the activation of service orders and thus the service delivery. One or more monolithic service models can be used in the context of a composite service activation request (e.g., delivery of a caching infrastructure over a VPN). Such models are used to feed a decision- making intelligence to adequately accommodate customer's needs. Also, such models may be used jointly with services that require dynamic invocation. An example is provided by the service modules defined by the DOTS WG to dynamically trigger requests to handle Distributed Denial-of-Service (DDoS) attacks [RFC8783]. The service filtering request modelled using [RFC8783] will be translated into device-specific filtering (e.g., ACLs defined in [RFC8519]) that fulfils the service request. Network models can be derived from service models and used to provision, monitor, instantiate the service, and provide lifecycle management of network resources. Doing so is meant to: o expose network resources to customers (including other network operators) to provide service fulfillment and assurance. o allow customers (or network operators) to dynamically adjust the network resources based on service requirements as described in service models (e.g., Figure 2) and the current network performance information described in the telemetry modules. Note that it is out of the scope of this document to elaborate on the communication protocols that are used to implement the interface between the service ordering (customer) and service order handling (provider). Wu, et al. Expires April 28, 2021 [Page 12] Internet-Draft Service and Network Management Automation October 2020 3.3. Service Fulfillment Automation To operate a service, the settings of the parameters in the device models are derived from service models and/or network models and are used to: o Provision each involved network function/device with the proper configuration information. o Operate the network based on service requirements as described in the service model(s) and local operational guidelines. In addition, the operational state including configuration that is in effect together with statistics should be exposed to upper layers to provide better network visibility and assess to what extent the derived low level modules are consistent with the upper level inputs. Filters are enforced on the notifications that are communicated to Service layers. The type and frequency of notifications may be agreed in the service model. Note that it is important to correlate telemetry data with configuration data to be used for closed loops at the different stages of service delivery, from resource allocation to service operation, in particular. 3.4. YANG Modules Integration To support top-down service delivery, YANG modules at different levels or at the same level need to be integrated together for proper service delivery (including, proper network setup). For example, the service parameters captured in service models need to be decomposed into a set of configuration/notification parameters that may be specific to one or more technologies; these technology-specific parameters are grouped together to define technology-specific device level models or network level models. In addition, these technology-specific device or network models can be further integrated with each other using the schema mount mechanism [RFC8528] to provision each involved network function/ device or each involved network domain to support newly added modules or features. A collection of device models integrated together can be loaded and validated during implementation. High-level policies can be defined at service or network models (e.g., "Autonomous System Number (ASN) Exclude" in the example depicted in Figure 2). Device models will be tweaked accordingly to provide policy-based management. Policies can also be used for Wu, et al. Expires April 28, 2021 [Page 13] Internet-Draft Service and Network Management Automation October 2020 telemetry automation, e.g., policies that contain conditions to trigger the generation and pushing of new telemetry data. 4. Functional Blocks and Interactions The architectural considerations described in Section 3 lead to the lifecycle management architecture illustrated in Figure 4 and described in the following subsections. +------------------+ ................. | | Service level | | V | E2E E2E E2E E2E Service --> Service ---------> Service ------------> Service Exposure Creation ^ Optimization ^ Diagnosis /Modification | | | ^ | |Diff | | E2E | | | E2E | | Service ----+ | | Service | | Decommission | +------ Assurance --+ | | ^ | Multi-layer | | | Multi-domain | | | Service Mapping| | | ................. |<-----------------+ | | Network level | | +-------+ v V | | Specific Specific Specific | Service Service --------> Service <--+ | Diagnosis Creation ^ Optimization | | | /Modification | | | | | |Diff | | | | | Specific --+ | | Service | | Service | | Decomposition | +----- Assurance ----+ | | ^ | ................. | | Aggregation | Device level | +------------+ | V | | Service Intent | v Fulfillment Config ----> Config ----> Performance ----> Fault Provision Validation Monitoring Diagnostic Figure 4: Service and Network Lifecycle Management Wu, et al. Expires April 28, 2021 [Page 14] Internet-Draft Service and Network Management Automation October 2020 4.1. Service Lifecycle Management Procedure Service lifecycle management includes end-to-end service lifecycle management at the service level and technology specific network lifecycle management at the network level. The end-to-end service lifecycle management is technology-independent service management and spans across multiple network domains and/or multiple layers while technology specific service lifecycle management is technology domain specific or layer specific service lifecycle management. 4.1.1. Service Exposure A service in the context of this document (sometimes called, Network Service) is some form of connectivity between customer sites and the Internet or between customer sites across the operator's network and across the Internet. Service exposure is used to capture services offered to customers (ordering and order handling). One example is that a customer can use a L3VPN Service Model (L3SM) to request L3VPN service by providing the abstract technical characterization of the intended service between customer sites. Service model catalogs can be created along to expose the various services and the information needed to invoke/order a given service. 4.1.2. Service Creation/Modification A customer is usually unaware of the technology that the network operator has available to deliver the service, so the customer does not make requests specific to the underlying technology but is limited to making requests specific to the service that is to be delivered. This service request can be filled using a service model. Upon receiving a service request, and assuming that appropriate authentication and authorization checks have been made with success, the service orchestrator/management system should verify whether the service requirements in the service request can be met (i.e., whether there are sufficient resources that can be allocated with the requested guarantees). If the request is accepted, the service orchestrator/management system maps such service request to its view. This view can be described as a technology specific network model or a set of technology specific device models and this mapping may include a Wu, et al. Expires April 28, 2021 [Page 15] Internet-Draft Service and Network Management Automation October 2020 choice of which networks and technologies to use depending on which service features have been requested. In addition, a customer may require to change the underlying network infrastructure to adapt to new customer's needs and service requirements (e.g., service a new customer site, add a new access link, provide disjoint paths). This service modification can be issued following the same service model used by the service request. Withdrawing a service is discussed in Section 4.1.6. 4.1.3. Service Assurance The performance measurement telemetry (Section 4.2) can be used to provide service assurance at Service and/or Network levels. Performance measurement telemetry model can tie with service or network models to monitor network performance or Service Level Agreement. 4.1.4. Service Optimization Service optimization is a technique that gets the configuration of the network updated due to network changes, incident mitigation, or new service requirements. One example is once a tunnel or a VPN is setup, Performance monitoring information or telemetry information per tunnel (or per VPN) can be collected and fed into the management system. If the network performance doesn't meet the service requirements, the management system can create new VPN policies capturing network service requirements and populate them into the network. Both network performance information and policies can be modelled using YANG. With Policy-based management, self-configuration and self-optimization behavior can be specified and implemented. The overall service optimization is managed at the service level, while the network level is responsible for the optimization of the specific network services it provides. 4.1.5. Service Diagnosis Operations, Administration, and Maintenance (OAM) are important networking functions for service diagnosis that allow network operators to: o monitor network communications (i.e., reachability verification and Continuity Check) Wu, et al. Expires April 28, 2021 [Page 16] Internet-Draft Service and Network Management Automation October 2020 o troubleshoot failures (i.e., fault verification and localization) o monitor service-level agreements and performance (i.e., performance management) When the network is down, service diagnosis should be in place to pinpoint the problem and provide recommendations (or instructions) for the network recovery. The service diagnosis information can be modelled as technology- independent Remote Procedure Call (RPC) operations for OAM protocols and technology-independent abstraction of key OAM constructs for OAM protocols [RFC8531][RFC8533]. These models can be used to provide consistent configuration, reporting, and presentation for the OAM mechanisms used to manage the network. Refer to Section 4.2.4 for the device-specific side. 4.1.6. Service Decommission Service decommission allows a customer to stop the service by removing the service from active status and thus releasing the network resources that were allocated to the service. Customers can also use the service model to withdraw the subscription to a service. 4.2. Service Fullfillment Management Procedure 4.2.1. Intended Configuration Provision Intended configuration at the device level is derived from network models at the network level or service model at the service level and represents the configuration that the system attempts to apply. Take L3SM as a service model example to deliver a L3VPN service, there is a need to map the L3VPN service view defined in the service model into a detailed intended configuration view defined by specific configuration models for network elements; the configuration information includes: o Virtual Routing and Forwarding (VRF) definition, including VPN policy expression o Physical Interface(s) o IP layer (IPv4, IPv6) o QoS features such as classification, profiles, etc. Wu, et al. Expires April 28, 2021 [Page 17] Internet-Draft Service and Network Management Automation October 2020 o Routing protocols: support of configuration of all protocols listed in a service request, as well as routing policies associated with those protocols. o Multicast support o Address sharing o Security (e.g., access control, authentication, encryption) These specific configuration models can be used to configure Provider Edge (PE) and Customer Edge (CE) devices within a site, e.g., a BGP policy model can be used to establish VPN membership between sites and VPN Service Topology. Note that in networks with legacy devices (that support proprietary modules or do not support YANG at all), an adaptation layer is likely to be required at the network level so that these devices can be involved in the delivery of the network services. This interface is also used to handle service withdrawal (Section 4.1.6). 4.2.2. Configuration Validation Configuration validation is used to validate intended configuration and ensure the configuration take effect. For example, if a customer creates an interface "eth-0/0/0" but the interface does not physically exist at this point, then configuration data appears in the status but does not appear in the datastore. More details about and datastores can be found in Section 5.1 of [RFC8342]. 4.2.3. Performance Monitoring When a configuration is in effect in a device, datastore holds the complete operational state of the device including learned, system, default configuration, and system state. However, the configurations and state of a particular device does not have the visibility on the whole network or how packets are going to be forwarded through the entire network. Therefore, it becomes more difficult to operate the entire network without understanding the current status of the network. The management system should subscribe to updates of a YANG datastore in all the network devices for performance monitoring purposes and Wu, et al. Expires April 28, 2021 [Page 18] Internet-Draft Service and Network Management Automation October 2020 build a full topological visibility of the network by aggregating (and filtering) these operational state from different sources. 4.2.4. Fault Diagnostic When configuration is in effect in a device, some devices may be mis- configured (e.g., device links are not consistent in both sides of the network connection) or network resources might be mis-allocated. Therefore, services may be negatively affected without knowing the root cause in the network. Technology-dependent nodes and RPC commands are defined in technology-specific YANG data models which can use and extend the base model described in Section 4.1.5 to deal with these issues. These RPC commands received in the technology-dependent node can be used to trigger technology-specific OAM message exchanges for fault verification and fault isolation. For example, TRILL Multicast Tree Verification (MTV) RPC command [I-D.ietf-trill-yang-oam] can be used to trigger Multi-Destination Tree Verification Message defined in [RFC7455] to verify TRILL distribution tree integrity. 4.3. Multi-Layer/Multi-Domain Service Mapping Multi-layer/Multi-domain Service Mapping allows to map an end-to-end abstract view of the service segmented at different layers and/or different network domains into domain-specific views. One example is to map service parameters in the L3SM into configuration parameters such as Route Distinguisher (RD), Route Target (RT), and VRF in the L3VPN Network Model (L3NM). Another example is to map service parameters in the L3SM into Traffic Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE model and Virtual Network (VN) parameters (e.g., Access Point (AP) list, VN members) in the YANG data model for VN operation [I-D.ietf-teas-actn-vn-yang]. 4.4. Service Decomposition Service Decomposition allows to decompose service models at the service level or network models at the network level into a set of device models at the device level. These device models may be tied to specific device types or classified into a collection of related YANG modules based on service types and features offered, and load at the implementation time before configuration is loaded and validated. Wu, et al. Expires April 28, 2021 [Page 19] Internet-Draft Service and Network Management Automation October 2020 5. YANG Data Model Integration Examples The following subsections provide some YANG data models integration examples. 5.1. L2VPN/L3VPN Service Delivery In reference to Figure 5, the following steps are performed to deliver the L3VPN service within the network management automation architecture defined in Section 4: 1. The Customer requests to create two sites (as per Service Creation in Section 4.2.1) relying upon L3SM with each site having one network access connectivity, for example: * Site A: network-access A, link-capacity = 20 Mbps, class "foo", guaranteed-capacity-percent = 10, average-one-way-delay = 70 ms. * Site B: network-access B, link-capacity = 30 Mbps, class "foo1", guaranteed-capacity-percent = 15, average-one-way- delay = 60 ms. 2. The Orchestrator extracts the service parameters from the L3SM. Then, it uses them as input to the Service Mapping in Section 4.3 to translate them into an orchestrated configuration parameters (e.g., RD, RT, VRF) that are part of the L3NM specified in [I-D.ietf-opsawg-l3sm-l3nm]. 3. The Controller takes the orchestrated configuration parameters in the L3NM and translates them into orchestrated (Service Decomposition in Section 4.4) configuration of network elements that are part of, e.g., BGP, QoS, Network Instance, IP management, and interface models. [I-D.ogondio-opsawg-uni-topology] can be used for representing, managing, and controlling the User Network Interface (UNI) topology. Wu, et al. Expires April 28, 2021 [Page 20] Internet-Draft Service and Network Management Automation October 2020 L3SM | Service | Model | +------------------------+------------------------+ | +--------V--------+ | | | Service Mapping | | | +--------+--------+ | | Orchestrator | | +------------------------+------------------------+ L3NM | ^ UNI Topology Model Network | | Model | | +------------------------+------------------------+ | +-----------V-----------+ | | | Service Decomposition | | | +--++---------------++--+ | | || || | | Controller || || | +---------------++---------------++---------------+ || || || BGP, || || QoS, || || Interface, || +------------+| NI, |+------------+ | | IP | | +--+--+ +--+--+ +--+--+ +--+--+ | CE1 +-------+ PE1 | | PE2 +-------+ CE2 | +-----+ +-----+ +-----+ +-----+ Figure 5: L3VPN Service Delivery Example (Current) L3NM inherits some of data elements from the L3SM. Nevertheless, the L3NM as currently designed in [I-D.ietf-opsawg-l3sm-l3nm] does not expose some information to the above layer such as the capabilities of an underlying network (which can be used to drive service order handling) or notifications (to notify subscribers about specific events or degradations as per agreed SLAs). Some of this information can be provided using, e.g., [I-D.www-opsawg-yang-vpn-service-pm]. A target overall model is depicted in Figure 6. Wu, et al. Expires April 28, 2021 [Page 21] Internet-Draft Service and Network Management Automation October 2020 L3SM | ^ Service | | Notifications Model | | +------------------------+------------------------+ | +--------V--------+ | | | Service Mapping | | | +--------+--------+ | | Orchestrator | | +------------------------+------------------------+ L3NM | ^ UNI Topology Model Network| | L3NM Notifications Model | | L3NM Capabilities +------------------------+------------------------+ | +-----------V-----------+ | | | Service Decomposition | | | +--++---------------++--+ | | || || | | Controller || || | +---------------++---------------++---------------+ || || || BGP, || || QoS, || || Interface, || +------------+| NI, |+------------+ | | IP | | +--+--+ +--+--+ +--+--+ +--+--+ | CE1 +-------+ PE1 | | PE2 +-------+ CE2 | +-----+ +-----+ +-----+ +-----+ Figure 6: L3VPN Service Delivery Example (Target) Note that a similar analysis can be performed for Layer 2 VPNs (L2VPNs). A L2VPN Service Model (L2SM) is defined in [RFC8466], while the L2VPN Network YANG Model (L2NM) is specified in [I-D.ietf-opsawg-l2nm]. 5.2. VN Lifecycle Management In reference to Figure 7, the following steps are performed to deliver the VN service within the network management automation architecture defined in Section 4: 1. A customer makes a request (Service Exposure in Section 4.1.1) to create a VN. The association between the VN, APs, and VN members is defined in the VN YANG module [I-D.ietf-teas-actn-vn-yang]. 2. The Orchestrator creates the single abstract node topology based on the information captured in the request. Wu, et al. Expires April 28, 2021 [Page 22] Internet-Draft Service and Network Management Automation October 2020 3. The customer exchanges with the Orchestrator the connectivity matrix on the abstract node topology and explicit paths using the TE topology model [RFC8795]. This information can be used to instantiate the VN and setup tunnels between source and destination endpoints (Service Creation in Section 4.1.2). 4. In order to provide service assurance (Service Optimization in Section 4.1.4), the telemetry model which augments the VN model and corresponding TE tunnel model can be used by the Orchestrator to subscribe to performance measurement data. The Controller will then notify the Orchestrator with all the parameter changes and network performance changes related to the VN topology and the tunnels [I-D.ietf-teas-actn-pm-telemetry-autonomics]. | VN | Service | Model | +----------------------|--------------------------+ | Orchestrator | | | +--------V--------+ | | | Service Mapping | | | +-----------------+ | +----------------------+--------------------^-----+ TE | Telemetry | Tunnel | Model | Model | | +----------------------V--------------------+-----+ | Controller | | | +-------------------------------------------------+ +-----+ +-----+ +-----+ +-----+ | CE1 +------+ PE1 | | PE2 +------+ CE2 | +-----+ +-----+ +-----+ +-----+ Figure 7: A VN Service Delivery Example 5.3. Event-based Telemetry in the Device Self Management In reference to Figure 8, the following steps are performed to monitor state changes of managed resources in a network device and provide device self-management within the network management automation architecture defined in Section 4: 1. To control which state a network device should be in or is allowed to be in at any given time, a set of conditions and actions are defined and correlated with network events (e.g., Wu, et al. Expires April 28, 2021 [Page 23] Internet-Draft Service and Network Management Automation October 2020 allow the NETCONF server to send updates only when the value exceeds a certain threshold for the first time, but not again until the threshold is cleared), which constitute an Event/Condition/Action (ECA) policy or an event-driven policy control logic that can be executed on the device (e.g., [I-D.wwx-netmod-event-yang]). 2. To provide rapid autonomic response that can exhibit self- management properties, the Controller pushes the ECA policy to the network device and delegates the network control logic to the network device. 3. The network device uses the ECA model to subscribe to the event source, e.g., an event stream or datastore state data conveyed to the server via YANG Push subscription [RFC8641], monitors state parameters, and takes simple and instant actions when an associated event condition on state parameters is met. ECA notifications can be generated as the result of actions based on event stream subscription or datastore subscription (model-driven telemetry operation discussed in Section 4.2.3). +----------------+ | <----+ | Controller | | +-------+--------+ | | | | | ECA | | ECA Model | | Notification | | | | +------------V-------------+-----+ |Device | | | +-------+ +---------+ +--+---+ | | | Event +-> Event +->Event | | | | Source| |Condition| |Action| | | +-------+ +---------+ +------+ | +--------------------------------+ Figure 8: Event-based Telemetry 6. Security Considerations Many of the YANG modules cited in this document define schema for data that are designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) Wu, et al. Expires April 28, 2021 [Page 24] Internet-Draft Service and Network Management Automation October 2020 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Security considerations specific to each of the technologies and protocols listed in the document are discussed in the specification documents of each of these protocols. In order to prevent leaking sensitive information and the "confused deputy" problem [Hardy] in general, special care should be considered when translating between the various layers in Section 4 or when aggregating data retrieved from various sources. Authorization and authentication checks should be performed to ensure that a data is available to an authorized entity. The network operator must enforce means to protect privacy-related information included in customer- facing models. To detect misalignment between layers that might be induced by misbehaving nodes, upper layers should continuously monitor the perceived service (Section 4.1.4) and should proceed with checks to assess that the provided service complies with the expected service and that the data reported by an underlying layer is matching the perceived service by the above layer. Such checks are the responsibility of the service diagnosis (Section 4.1.5). When a YANG module includes security-related parameters, it is recommended to include the relevant information as part of the service assurance to track the correct functioning of the security mechanisms. Additional considerations are discussed in the following subsections. 6.1. Service Level A provider may rely on services offered by other providers to build composite services. Appropriate mechanisms should be enabled by the provider to monitor and detect a service disruption from these providers. The characterization of a service disruption (including, mean time between failures, mean time to repair), the escalation procedure, and penalties are usually documented in contractual agreements (e.g., as described in Section 2.1 of [RFC4176]). Misbehaving peer providers will thus be identified and appropriate countermeasures will be applied. Wu, et al. Expires April 28, 2021 [Page 25] Internet-Draft Service and Network Management Automation October 2020 The communication protocols that make use of a service model between a customer and an operator are out of scope. Relevant security considerations should be discussed in the specification documents of these protocols. 6.2. Network Level Security considerations specific to the network level are listed below: o A controller may create forwarding loops by mis-configuring the underlying network nodes. It is recommended to proceed with tests to check the status of forwarding paths regularly or whenever changes are made to routing or forwarding processes. Such checks may be triggered from the service level owing to the means discussed in Section 4.1.5. o Some service models may include a traffic isolation clause that is passed down to the network level so that appropriate technology- specific actions must be enforced at the underlying network (and thus involved network devices) to avoid that such traffic is accessible to non-authorized parties. In particular, network models may indicate whether encryption is enabled and if so, expose a list of supported encryption schemes and parameters. Refer for example to the encryption feature defined in [I-D.ietf-opsawg-vpn-common] and its use in [I-D.ietf-opsawg-l3sm-l3nm]. 6.3. Device Level Network operators should monitor and audit their networks to detect misbehaving nodes and abnormal behaviors. For example, OAM discussed in Section 4.1.5 can be used for that purpose. Access to some data requires specific access privilege levels. Devices must check that a required access privilege is provided before granting access to specific data or performing specific actions. 7. IANA Considerations There are no IANA requests or assignments included in this document. 8. Acknowledgements Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter, Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and Olivier Augizeau for the review. Wu, et al. Expires April 28, 2021 [Page 26] Internet-Draft Service and Network Management Automation October 2020 Many thanks to Robert Wilton for the detailed AD review. Thanks to Eric Vyncke, Roman Danyliw, Erik Kline, and Benjamin Kaduk for the IESG review. 9. Contributors Christian Jacquenet Orange Rennes, 35000 France Email: Christian.jacquenet@orange.com Luis Miguel Contreras Murillo Telifonica Email: luismiguel.contrerasmurillo@telefonica.com Oscar Gonzalez de Dios Telefonica Madrid ES Email: oscar.gonzalezdedios@telefonica.com Weiqiang Cheng China Mobile Email: chengweiqiang@chinamobile.com Young Lee Sung Kyun Kwan University Email: younglee.tx@gmail.com 10. References 10.1. Normative References [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . Wu, et al. Expires April 28, 2021 [Page 27] Internet-Draft Service and Network Management Automation October 2020 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 10.2. Informative References [Hardy] Hardy, N., "The Confused Deputy: (or why capabilities might have been invented)", October 1988, . [I-D.clacla-netmod-model-catalog] Clarke, J. and B. Claise, "YANG module for yangcatalog.org", draft-clacla-netmod-model-catalog-03 (work in progress), April 2018. [I-D.ietf-bess-evpn-yang] Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- bess-evpn-yang-07 (work in progress), March 2019. [I-D.ietf-bess-l2vpn-yang] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-based L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), July 2019. [I-D.ietf-bess-l3vpn-yang] Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work in progress), October 2018. Wu, et al. Expires April 28, 2021 [Page 28] Internet-Draft Service and Network Management Automation October 2020 [I-D.ietf-bess-mvpn-yang] Liu, Y., Guo, F., Litkowski, S., Liu, X., Kebler, R., and M. Sivakumar, "Yang Data Model for Multicast in MPLS/BGP IP VPNs", draft-ietf-bess-mvpn-yang-04 (work in progress), June 2020. [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. [I-D.ietf-dots-rfc8782-bis] Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", draft-ietf-dots-rfc8782-bis-01 (work in progress), September 2020. [I-D.ietf-i2rs-yang-l2-network-topology] Dong, J., Wei, X., WU, Q., Boucadair, M., and A. Liu, "A YANG Data Model for Layer 2 Network Topologies", draft- ietf-i2rs-yang-l2-network-topology-18 (work in progress), September 2020. [I-D.ietf-idr-bgp-model] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP YANG Model for Service Provider Networks", draft-ietf-idr- bgp-model-09 (work in progress), June 2020. [I-D.ietf-ippm-capacity-metric-method] Morton, A., Geib, R., and L. Ciavattone, "Metrics and Methods for One-way IP Capacity", draft-ietf-ippm- capacity-metric-method-04 (work in progress), September 2020. [I-D.ietf-ippm-stamp-yang] Mirsky, G., Min, X., and W. Luo, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", draft-ietf-ippm- stamp-yang-06 (work in progress), October 2020. [I-D.ietf-ippm-twamp-yang] Civil, R., Morton, A., Rahman, R., Jethanandani, M., and K. Pentikousis, "Two-Way Active Measurement Protocol (TWAMP) Data Model", draft-ietf-ippm-twamp-yang-13 (work in progress), July 2018. Wu, et al. Expires April 28, 2021 [Page 29] Internet-Draft Service and Network Management Automation October 2020 [I-D.ietf-mpls-base-yang] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", draft-ietf-mpls-base- yang-16 (work in progress), October 2020. [I-D.ietf-netmod-module-tags] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module Tags", draft-ietf-netmod-module-tags-10 (work in progress), February 2020. [I-D.ietf-opsawg-l2nm] barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- ietf-opsawg-l2nm-00 (work in progress), July 2020. [I-D.ietf-opsawg-l3sm-l3nm] barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- opsawg-l3sm-l3nm-05 (work in progress), October 2020. [I-D.ietf-opsawg-vpn-common] barguil, s., Dios, O., Boucadair, M., and Q. WU, "A Layer 2/3 VPN Common YANG Model", draft-ietf-opsawg-vpn- common-01 (work in progress), September 2020. [I-D.ietf-pim-igmp-mld-snooping-yang] Zhao, H., Liu, X., Liu, Y., Sivakumar, M., and A. Peter, "A Yang Data Model for IGMP and MLD Snooping", draft-ietf- pim-igmp-mld-snooping-yang-18 (work in progress), August 2020. [I-D.ietf-pim-yang] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, Y., and f. hu, "A YANG Data Model for Protocol Independent Multicast (PIM)", draft-ietf-pim-yang-17 (work in progress), May 2018. [I-D.ietf-rtgwg-policy-model] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data Model for Routing Policy Management", draft-ietf-rtgwg- policy-model-26 (work in progress), October 2020. [I-D.ietf-rtgwg-qos-model] Choudhary, A., Jethanandani, M., Strahle, N., Aries, E., and I. Chen, "YANG Model for QoS", draft-ietf-rtgwg-qos- model-02 (work in progress), July 2020. Wu, et al. Expires April 28, 2021 [Page 30] Internet-Draft Service and Network Management Automation October 2020 [I-D.ietf-spring-sr-yang] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", draft- ietf-spring-sr-yang-22 (work in progress), August 2020. [I-D.ietf-teas-actn-pm-telemetry-autonomics] Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., and D. Ceccarelli, "YANG models for VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", draft-ietf-teas-actn-pm-telemetry-autonomics-03 (work in progress), July 2020. [I-D.ietf-teas-actn-vn-yang] Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Yoon, "A YANG Data Model for VN Operation", draft-ietf- teas-actn-vn-yang-09 (work in progress), July 2020. [I-D.ietf-teas-yang-path-computation] Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, "Yang model for requesting Path Computation", draft-ietf- teas-yang-path-computation-10 (work in progress), July 2020. [I-D.ietf-teas-yang-rsvp-te] Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I., and H. Shah, "A YANG Data Model for RSVP-TE Protocol", draft-ietf-teas-yang-rsvp-te-08 (work in progress), March 2020. [I-D.ietf-teas-yang-te] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 (work in progress), July 2020. [I-D.ietf-trill-yang-oam] Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L., and H. Weiguo, "YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)", draft-ietf-trill- yang-oam-05 (work in progress), March 2017. [I-D.ogondio-opsawg-uni-topology] Dios, O., barguil, s., WU, Q., and M. Boucadair, "A YANG Model for User-Network Interface (UNI) Topologies", draft- ogondio-opsawg-uni-topology-01 (work in progress), April 2020. Wu, et al. Expires April 28, 2021 [Page 31] Internet-Draft Service and Network Management Automation October 2020 [I-D.www-opsawg-yang-vpn-service-pm] Bo, W., WU, Q., Boucadair, M., Dios, O., Wen, B., Liu, C., and H. Xu, "A YANG Model for Network and VPN Service Performance Monitoring", draft-www-opsawg-yang-vpn- service-pm-01 (work in progress), July 2020. [I-D.wwx-netmod-event-yang] Bierman, A., WU, Q., Bryskin, I., Birkholz, H., Liu, X., and B. Claise, "A YANG Data model for ECA Policy Management", draft-wwx-netmod-event-yang-09 (work in progress), July 2020. [IPPM] IANA, "Performance Metrics", March 2020, . [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, . [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, . [RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, . Wu, et al. Expires April 28, 2021 [Page 32] Internet-Draft Service and Network Management Automation October 2020 [RFC5486] Malas, D., Ed. and D. Meyer, Ed., "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, DOI 10.17487/RFC5486, March 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture", RFC 6406, DOI 10.17487/RFC6406, November 2011, . [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, . [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 7224, DOI 10.17487/RFC7224, May 2014, . [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, . [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . Wu, et al. Expires April 28, 2021 [Page 33] Internet-Draft Service and Network Management Automation October 2020 [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, . [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, . [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, . [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, August 2017, . [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module Classification", RFC 8199, DOI 10.17487/RFC8199, July 2017, . [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018, . [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . Wu, et al. Expires April 28, 2021 [Page 34] Internet-Draft Service and Network Management Automation October 2020 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, March 2018, . [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, . [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., Vinapamula, S., and Q. Wu, "A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, . [RFC8513] Boucadair, M., Jacquenet, C., and S. Sivakumar, "A YANG Data Model for Dual-Stack Lite (DS-Lite)", RFC 8513, DOI 10.17487/RFC8513, January 2019, . [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, . [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, . [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, . Wu, et al. Expires April 28, 2021 [Page 35] Internet-Draft Service and Network Management Automation October 2020 [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, . [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", RFC 8530, DOI 10.17487/RFC8530, March 2019, . [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019, . [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, . [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, "A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8533, DOI 10.17487/RFC8533, April 2019, . [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. Peter, "A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November 2019, . [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data Model for Tunnel Interface Types", RFC 8675, DOI 10.17487/RFC8675, November 2019, . Wu, et al. Expires April 28, 2021 [Page 36] Internet-Draft Service and Network Management Automation October 2020 [RFC8676] Farrer, I., Ed. and M. Boucadair, Ed., "YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires", RFC 8676, DOI 10.17487/RFC8676, November 2019, . [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, . [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, . [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, . Appendix A. Layered YANG Modules Examples Overview This appendix lists a set of YANG data models that can be used for the delivery of connectivity services. These models can be classified as service, network, or device models. It is not the intent of this appendix to provide an inventory of tools and mechanisms used in specific network and service management domains; such inventory can be found in documents such as [RFC7276]. The reader may refer to the YANG Catalog () or the public Github YANG repository () to query existing YANG models. The YANG Catalog includes some metadata to indicate the module type ('module-classification') [I-D.clacla-netmod-model-catalog]. Note that the mechanism defined in [I-D.ietf-netmod-module-tags] allows to associate tags with YANG modules in order to help classifying the modules. A.1. Service Models: Definition and Samples As described in [RFC8309], the service is "some form of connectivity between customer sites and the Internet and/or between customer sites across the network operator's network and across the Internet". More concretely, an IP connectivity service can be defined as the IP transfer capability characterized by a (Source Nets, Destination Nets, Guarantees, Scope) tuple where "Source Nets" is a group of unicast IP addresses, "Destination Nets" is a group of IP unicast Wu, et al. Expires April 28, 2021 [Page 37] Internet-Draft Service and Network Management Automation October 2020 and/or multicast addresses, and "Guarantees" reflects the guarantees (expressed in terms of QoS, performance, and availability, for example) to properly forward traffic to the said "Destination" [RFC7297]. For example: o The L3SM [RFC8299] defines the L3VPN service ordered by a customer from a network operator. o The L2SM [RFC8466] defines the L2VPN service ordered by a customer from a network operator. o The Virtual Network (VN) model [I-D.ietf-teas-actn-vn-yang] provides a YANG data model applicable to any mode of VN operation. L2SM and L3SM are customer service models as per [RFC8309]. A.2. Schema Mount Modularity and extensibility were among the leading design principles of the YANG data modeling language. As a result, the same YANG module can be combined with various sets of other modules and thus form a data model that is tailored to meet the requirements of a specific use case. [RFC8528] defines a mechanism, denoted schema mount, that allows for mounting one data model consisting of any number of YANG modules at a specified location of another (parent) schema. A.3. Network Models: Samples L2NM [I-D.ietf-opsawg-l2nm] and L3NM [I-D.ietf-opsawg-l3sm-l3nm] are examples of YANG network models. Figure 9 depicts a set of additional network models such as topology and tunnel models: Wu, et al. Expires April 28, 2021 [Page 38] Internet-Draft Service and Network Management Automation October 2020 +-------------------------------+-------------------------------+ | Topology YANG modules | Tunnel YANG modules | +-------------------------------+-------------------------------+ | +------------------+ | | | |Network Topologies| | +------+ +-----------+ | | | Model | | |Other | | TE Tunnel | | | +--------+---------+ | |Tunnel| +----+------+ | | | +---------+ | +------+ | | | +---+Service | | +----------+---------+ | | | |Topology | | | | | | | | +---------+ | | | | | | | +---------+ |+----+---+ +----+---+ +---+---+| | +---+Layer 3 | ||MPLS-TE | |RSVP-TE | | SR-TE || | | |Topology | || Tunnel | | Tunnel | |Tunnel || | | +---------+ |+--------+ +--------+ +-------+| | | +---------+ | | | +---+TE | | | | | |Topology | | | | | +---------+ | | | | +---------+ | | | +---+Layer 3 | | | | |Topology | | | | +---------+ | | +-------------------------------+-------------------------------+ Figure 9: Sample Resource Facing Network Models Examples of topology YANG modules are listed below: o Network Topologies Model: [RFC8345] defines a base model for network topology and inventories. Network topology data include link, node, and terminate-point resources. o TE Topology Model: [RFC8795] defines a YANG data model for representing and manipulating TE topologies. This module is extended from network topology model defined in [RFC8345] with TE topologies related content. This model contains technology-agnostic TE Topology building blocks that can be augmented and used by other technology-specific TE topology models. o Layer 3 Topology Model: [RFC8346] defines a YANG data model for representing and manipulating Layer 3 topologies. This model is extended from the network topology model defined in [RFC8345] with Layer 3 topologies specifics. Wu, et al. Expires April 28, 2021 [Page 39] Internet-Draft Service and Network Management Automation October 2020 o Layer 2 Topology Model: [I-D.ietf-i2rs-yang-l2-network-topology] defines a YANG data model for representing and manipulating Layer 2 topologies. This model is extended from the network topology model defined in [RFC8345] with Layer 2 topology specifics. Examples of tunnel YANG modules are provided below: o Tunnel identities: [RFC8675] defines a collection of YANG identities used as interface types for tunnel interfaces. o TE Tunnel Model: [I-D.ietf-teas-yang-te] defines a YANG module for the configuration and management of TE interfaces, tunnels, and LSPs. o Segment Routing (SR) Traffic Engineering (TE) Tunnel Model: [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE model(s) and defines a YANG module for SR-TE specific data. o MPLS-TE Model: [I-D.ietf-teas-yang-te] augments the TE generic and MPLS-TE model(s) and defines a YANG module for MPLS-TE configurations, state, RPC and notifications. o RSVP-TE MPLS Model: [I-D.ietf-teas-yang-rsvp-te] augments the RSVP-TE generic module with parameters to configure and manage signaling of MPLS RSVP-TE LSPs. Other sample network models are listed hereafter: o Path Computation API Model: [I-D.ietf-teas-yang-path-computation] YANG module for a stateless RPC which complements the stateful solution defined in [I-D.ietf-teas-yang-te]. o OAM Models (including Fault Management (FM) and Performance Monitoring): [RFC8532] defines a base YANG module for the management of OAM protocols that use Connectionless Communications. [RFC8533] defines a retrieval method YANG module for connectionless OAM Wu, et al. Expires April 28, 2021 [Page 40] Internet-Draft Service and Network Management Automation October 2020 protocols. [RFC8531] defines a base YANG module for connection oriented OAM protocols. These three models are intended to provide consistent reporting, configuration, and representation for connection-less OAM and Connection oriented OAM separately. Alarm monitoring is a fundamental part of monitoring the network. Raw alarms from devices do not always tell the status of the network services or necessarily point to the root cause. [RFC8632] defines a YANG module for alarm management. A.4. Device Models: Samples Network Element models (listed in Figure 10) are used to describe how a service can be implemented by activating and tweaking a set of functions (enabled in one or multiple devices, or hosted in cloud infrastructures) that are involved in the service delivery. For example, the L3VPN service will involve many PEs and require manipulating the following modules: o Routing management [RFC8349] o BGP [I-D.ietf-idr-bgp-model] o PIM [I-D.ietf-pim-yang] o NAT management [RFC8512] o QoS management [I-D.ietf-rtgwg-qos-model] o ACLs [RFC8519] Figure 10 uses IETF-defined data models as an example. Wu, et al. Expires April 28, 2021 [Page 41] Internet-Draft Service and Network Management Automation October 2020 +------------------------+ +-+ Device Model | | +------------------------+ | +------------------------+ +---------------+ | | Logical Network | | | +-+ Element Model | | Architecture | | +------------------------+ | | | +------------------------+ +-------+-------+ +-+ Network Instance Model | | | +------------------------+ | | +------------------------+ | +-+ Routing Type Model | | +------------------------+ +-------+----------+----+------+------------+-----------+------+ | | | | | | | +-+-+ +---+---+ +----+----+ +--+--+ +----+----+ +--+--+ | |ACL| |Routing| |Transport| | OAM | |Multicast| | PM | Others +---+ +-+-----+ +----+----+ +--+--+ +-----+---+ +--+--+ | +-------+ | +------+ | +--------+ | +-----+ | +-----+ +-+Core | +-+ MPLS | +-+ BFD | +-+IGMP | +-+TWAMP| | |Routing| | | Base | | +--------+ | |/MLD | | +-----+ | +-------+ | +------+ | +--------+ | +-----+ | +-----+ | +-------+ | +------+ +-+LSP Ping| | +-----+ +-+OWAMP| +-+ BGP | +-+ MPLS | | +--------+ +-+ PIM | | +-----+ | +-------+ | | LDP | | +--------+ | +-----+ | +-----+ | +-------+ | +------+ +-+MPLS-TP | | +-----+ +-+LMAP | +-+ ISIS | | +------+ +--------+ +-+ MVPN| +-----+ | +-------+ +-+ MPLS | +-----+ | +-------+ |Static| +-+ OSPF | +------+ | +-------+ | +-------+ +-+ RIP | | +-------+ | +-------+ +-+ VRRP | | +-------+ | +-------+ +-+SR/SRv6| | +-------+ | +-------+ +-+ISIS-SR| | +-------+ | +-------+ +-+OSPF-SR| +-------+ Figure 10: Network Element Modules Overview Wu, et al. Expires April 28, 2021 [Page 42] Internet-Draft Service and Network Management Automation October 2020 A.4.1. Model Composition o Logical Network Element Model [RFC8530] defines a logical network element module which can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are Logical Systems or Logical Routers. o Network Instance Model [RFC8529] defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VRF instances and Virtual Switch Instances (VSIs). A.4.2. Device Management The following list enumerates some YANG modules that can be used for device management: o [RFC8348]: defines a YANG module for the management of hardware. o [RFC7317]: defines the "ietf-system" YANG module that provides many features such as the configuration and the monitoring of system or system control operations (e.g., shutdown, restart, setting time) identification. o [RFC8341]: defines a network configuration access control YANG module. A.4.3. Interface Management The following provides some YANG modules that can be used for interface management: o [RFC7224]: defines a YANG module for interface type definitions. o [RFC8343]: defines a YANG module for the management of network interfaces. A.4.4. Some Device Model Examples The following provides an overview of some device models that can be used within a network. This list is not comprehensive. Wu, et al. Expires April 28, 2021 [Page 43] Internet-Draft Service and Network Management Automation October 2020 L2VPN: [I-D.ietf-bess-l2vpn-yang] defines a YANG module for MPLS based Layer 2 VPN services (L2VPN) [RFC4664] and includes switching between the local attachment circuits. The L2VPN model covers point-to-point VPWS and Multipoint VPLS services. These services use signaling of Pseudowires across MPLS networks using LDP [RFC8077][RFC4762] or BGP [RFC4761]. EVPN: [I-D.ietf-bess-evpn-yang] defines a YANG module for Ethernet VPN services. The model is agnostic of the underlay. It applies to MPLS as well as to VxLAN encapsulation. The module is also agnostic to the services, including E-LAN, E-LINE, and E-TREE services. L3VPN: [I-D.ietf-bess-l3vpn-yang] defines a YANG module that can be used to configure and manage BGP L3VPNs [RFC4364]. It contains VRF specific parameters as well as BGP specific parameters applicable for L3VPNs. Core Routing: [RFC8349] defines the core routing YANG data model, which is intended as a basis for future data model development covering more-sophisticated routing systems. It is expected that other Routing technology YANG modules (e.g., VRRP, RIP, ISIS, OSPF models) will augment the Core Routing base YANG module. MPLS: [I-D.ietf-mpls-base-yang] defines a base model for MPLS which serves as a base framework for configuring and managing an MPLS switching subsystem. It is expected that other MPLS technology YANG modules (e.g., MPLS LSP Static, LDP, or RSVP-TE models) will augment the MPLS base YANG module. BGP: [I-D.ietf-idr-bgp-model] defines a YANG module for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier, and content provider operational requirements. Routing Policy: [I-D.ietf-rtgwg-policy-model] defines a YANG module for configuring and managing routing policies based on operational practice. The module provides a generic policy framework which can be augmented with protocol- specific policy configuration. SR/SRv6: [I-D.ietf-spring-sr-yang] a YANG module for segment routing configuration and operation. Wu, et al. Expires April 28, 2021 [Page 44] Internet-Draft Service and Network Management Automation October 2020 BFD: Bidirectional Forwarding Detection (BFD) [RFC5880] is a network protocol which is used for liveness detection of arbitrary paths between systems. [I-D.ietf-bfd-yang] defines a YANG module that can be used to configure and manage BFD. Multicast: [I-D.ietf-pim-yang] defines a YANG module that can be used to configure and manage Protocol Independent Multicast (PIM) devices. [RFC8652] defines a YANG module that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices. [I-D.ietf-pim-igmp-mld-snooping-yang] defines a YANG module that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. [I-D.ietf-bess-mvpn-yang] defines a YANG data model to configure and manage Multicast in MPLS/BGP IP VPNs (MVPNs). PM: [I-D.ietf-ippm-twamp-yang] defines a YANG data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). [I-D.ietf-ippm-stamp-yang] defines the data model for implementations of Session-Sender and Session-Reflector for Simple Two-way Active Measurement Protocol (STAMP) mode using YANG. [RFC8194] defines a YANG data model for Large-Scale Measurement Platforms (LMAPs). ACL: Access Control List (ACL) is one of the basic elements used to configure device forwarding behavior. It is used in many networking technologies such as Policy Based Routing, firewalls, etc. [RFC8519] describes a YANG data model of ACL basic building blocks. QoS: [I-D.ietf-rtgwg-qos-model] describes a YANG module of Differentiated Services for configuration and operations. NAT: For the sake of network automation and the need for programming Network Address Translation (NAT) function in particular, a YANG data model for configuring and managing the NAT is essential. Wu, et al. Expires April 28, 2021 [Page 45] Internet-Draft Service and Network Management Automation October 2020 [RFC8512] defines a YANG module for the NAT function covering a variety of NAT flavors such as Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT. [RFC8513] specifies a DS-Lite YANG module. Stateless Address Sharing: [RFC8676] specifies a YANG module for A+P address sharing, including Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms. Authors' Addresses Qin Wu (editor) Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com Mohamed Boucadair (editor) Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Diego R. Lopez Telefonica I+D Spain Email: diego.r.lopez@telefonica.com Wu, et al. Expires April 28, 2021 [Page 46] Internet-Draft Service and Network Management Automation October 2020 Chongfeng Xie China Telecom Beijing China Email: xiechf@chinatelecom.cn Liang Geng China Mobile Email: gengliang@chinamobile.com Wu, et al. Expires April 28, 2021 [Page 47] ./draft-ietf-ospf-encapsulation-cap-09.txt0000644000764400076440000005347213167133542017754 0ustar iustyiusty OSPF Working Group X. Xu, Ed. Internet-Draft Huawei Intended status: Standards Track B. Decraene, Ed. Expires: April 12, 2018 Orange R. Raszuk Bloomberg LP L. Contreras Telefonica I+D L. Jalil Verizon October 9, 2017 The Tunnel Encapsulations OSPF Router Information draft-ietf-ospf-encapsulation-cap-09 Abstract Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the tunnel encapsulator router needs to select a type of tunnel which is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisement (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. Requirements Language 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 RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 12, 2018. Xu, et al. Expires April 12, 2018 [Page 1] Internet-Draft Tunnel Encapsulations RI October 2017 Copyright Notice Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Tunnel Encapsulations TLV . . . . . . . . . . . . . . . . . . 3 4. Tunnel Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 3 5. Tunnel Parameter Sub-TLVs . . . . . . . . . . . . . . . . . . 4 5.1. Encapsulation Sub-TLV . . . . . . . . . . . . . . . . . . 5 5.2. Protocol Type Sub-TLV . . . . . . . . . . . . . . . . . . 5 5.3. Endpoint Sub-TLV . . . . . . . . . . . . . . . . . . . . 5 5.4. Color Sub-TLV . . . . . . . . . . . . . . . . . . . . . . 6 5.5. Load-Balancing Block Sub-TLV . . . . . . . . . . . . . . 6 5.6. IP QoS Field . . . . . . . . . . . . . . . . . . . . . . 6 5.7. UDP Destination Port . . . . . . . . . . . . . . . . . . 7 6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. OSPF Router Information . . . . . . . . . . . . . . . . . 7 7.2. Tunnel Parameter Sub-TLVs Registry . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Networks use tunnels for a variety of reasons, such as: o Partial deployment of IPv6 in IPv4 networks or IPv4 in IPv6 networks as described in [RFC5565], where IPvx tunnels are used between IPvx-enabled routers so as to traverse non-IPvx routers. Xu, et al. Expires April 12, 2018 [Page 2] Internet-Draft Tunnel Encapsulations RI October 2017 o Remote Loop-Free Alternate (RLFA) repair tunnels as described in [RFC7490], where tunnels are used between the Point of Local Repair and the selected PQ node. The tunnel encapsulator router needs to select a type of tunnel which is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF Router Information Link State Advertisement (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. In this document, OSPF refers to both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 2. Terminology This memo makes use of the terms defined in [RFC7770]. 3. Tunnel Encapsulations TLV Routers advertise their supported tunnel encapsulation type(s) by advertising a new TLV of the OSPF Router Information (RI) Opaque LSA [RFC7770], referred to as the Tunnel Encapsulations TLV. This TLV is applicable to both OSPFv2 and OSPFv3. The Type code of the Tunnel Encapsulations is TBD1, the Length value is variable, and the Value field contains one or more Tunnel Sub-TLVs as defined in Section 4. Each Tunnel Sub-TLV indicates a particular encapsulation format that the advertising router supports along with the parameters corresponding to the tunnel type. The Tunnel Encapsulations TLV MAY appear more than once within a given OSPF Router Information (RI) Opaque LSA. If the Tunnel Encapsulations TLV appears more than once in an OSPF Router Information LSA, the set of all Tunnel Sub-TLVs from all Tunnel Encapsulations TLV SHOULD be considered. The scope of the advertisement depends on the application but it is recommended that it SHOULD be domain-wide. 4. Tunnel Sub-TLV The Tunnel Sub-TLV is structured as follows: Xu, et al. Expires April 12, 2018 [Page 3] Internet-Draft Tunnel Encapsulations RI October 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Type (2 Octets) | Length (2 Octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Tunnel Parameter Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Tunnel Sub-TLV Tunnel Type (2 octets): Identifies the type of tunneling technology signaled. Tunnel types are shared with the BGP extension [I-D.ietf-idr-tunnel-encaps] and hence are defined in the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types". Unknown Tunnel types are to be ignored upon receipt. Length (2 octets): Unsigned 16-bit integer indicating the total number of octets of the value field. Value (variable): Zero or more Tunnel Parameter Sub-TLVs as defined in Section 5. If a Tunnel Sub-TLV is invalid, it MUST be ignored and skipped. However, other Tunnel Sub-TLVs MUST be considered 5. Tunnel Parameter Sub-TLVs A Tunnel Parameter Sub-TLV is structured as follows: +---------------------------------------------+ | Tunnel Parameter Sub-Type (2 Octets) | +---------------------------------------------+ | Tunnel Parameter Length (2 Octets) | +---------------------------------------------+ | Tunnel Parameter Value (Variable) | | | +---------------------------------------------+ Figure 2: Tunnel Parameter Sub-TLV Tunnel Parameter Sub-Type (2 octets): Each sub-type defines a parameter of the Tunnel Sub-TLV. Sub-Types are registered in the IANA registry "OSPF Tunnel Parameter Sub-TLVs" Section 7.2. Xu, et al. Expires April 12, 2018 [Page 4] Internet-Draft Tunnel Encapsulations RI October 2017 Tunnel Parameter Length (2 octets): Unsigned 16-bit integer indicating the total number of octets of the Tunnel Parameter Value field. Tunnel Parameter Value (variable): Encodings of the value field depend on the Sub-TLV type as enumerated above. The following sub-sections define the encoding in detail. Any unknown Tunnel Parameter Sub-Type MUST be ignored and skipped upon receipt. When a reserved value (See Section 7.2) is seen in an LSA, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Parameter Value has an incorrect syntax or semantic, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its Tunnel Sub-TLV MUST be ignored. However, other Tunnel Sub-TLVs MUST be considered. 5.1. Encapsulation Sub-TLV This Sub-TLV type is 1. The syntax, semantic, and usage of its value field are defined in Section 3.2 "Encapsulation Sub-TLVs for Particular Tunnel Types" of [I-D.ietf-idr-tunnel-encaps]. 5.2. Protocol Type Sub-TLV This Sub-TLV type is 2. The syntax, semantic, and usage of its value field are defined in Section 3.4.1 "Protocol Type sub-TLV" of [I-D.ietf-idr-tunnel-encaps]. 5.3. Endpoint Sub-TLV This Sub-TLV type is 3. It MUST be present once and only once in a given Tunnel Sub-TLV. The value field contain two sub-fields: a two-octet Address Family sub-field an Address sub-field, whose length depends upon the Address Family. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ (Variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Endpoint Sub-TLV Xu, et al. Expires April 12, 2018 [Page 5] Internet-Draft Tunnel Encapsulations RI October 2017 The Address Family subfield contains a value from IANA's "Address Family Numbers" registry. In this document, we assume that the Address Family is either IPv4 or IPv6; use of other address families is outside the scope of this document. If the Address Family subfield contains the value for IPv4, the address subfield MUST contain an IPv4 address (a /32 IPv4 prefix). In this case, the length field of Remote Endpoint sub-TLV MUST contain the value 6. If the Address Family subfield contains the value for IPv6, the address sub-field MUST contain an IPv6 address (a /128 IPv6 prefix). In this case, the length field of Remote Endpoint sub-TLV MUST contain the value 18 (0x12). IPv6 link local addresses are not valid values of the IP address field. 5.4. Color Sub-TLV This Sub-TLV type is 4. It may appear zero or more time in a given Tunnel Sub-TLV. The value field is a 4-octet opaque unsigned integer. The color value is user-defined and configured locally on the advertising routers. It may be used by service providers to define policies on the tunnel encapsulator routers, for example, to control the selection of the tunnel to use. This color value can be referenced by BGP routes carrying Color Extended Community [I-D.ietf-idr-tunnel-encaps]. If the tunnel is used to reach the BGP Next-Hop of BGP routes, then attaching a Color Extended Community to those routes express the willingness of the BGP speaker to use a tunnel of the same color. 5.5. Load-Balancing Block Sub-TLV This Sub-TLV type is 5. The syntax, semantic, and usage of its value field are defined in [RFC5640]. 5.6. IP QoS Field This Sub-TLV type is 6. The syntax, semantic, and usage of its value field are defined in Section 3.3.1 "IPv4 DS Field" of [I-D.ietf-idr-tunnel-encaps]. Xu, et al. Expires April 12, 2018 [Page 6] Internet-Draft Tunnel Encapsulations RI October 2017 5.7. UDP Destination Port This Sub-TLV type is 7. The syntax, semantic, and usage of its value field are defined in Section 3.3.2 "UDP Destination Port" of [I-D.ietf-idr-tunnel-encaps]. 6. Operation The advertisement of a Tunnel Encapsulations Sub-TLV indicates that the advertising router supports a particular tunnel decapsulation along with the parameters to be used for the tunnel. The decision to use that tunnel is driven by the capability of the tunnel encapsulator router to support the encapsulation type and the policy on the tunnel encapsulator router. The Color Sub-TLV (See Section 5.4) may be used as an input to this policy. Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used to transit data. A tunnel MUST NOT be used if there is no route toward the IP address specified in the Endpoint Sub-TLV (See Section 5.3) or if the route is not advertised in the same OSPF domain. 7. IANA Considerations 7.1. OSPF Router Information This document requests IANA to allocate a new code point from the OSPF Router Information (RI) registry. Value TLV Name Reference ----- ---------------------- ------------- TBD1 Tunnel Encapsulations This document Figure 4: Tunnel Encapsulation Router Information 7.2. Tunnel Parameter Sub-TLVs Registry This document requests IANA to create, under "Open Shortest Path First (OSPF) Parameters", a new registry "OSPF Tunnel Parameter Sub- TLVs" with the following registration procedure: The values in the range 1-34999 are to be allocated using the "Standards Action" registration procedure as defined in [RFC8126]. The values in the range 35000-65499 are to be allocated using the "First Come, First Served" registration procedure. Xu, et al. Expires April 12, 2018 [Page 7] Internet-Draft Tunnel Encapsulations RI October 2017 Registry Name: OSPF Tunnel Parameter Sub-TLVs Value Name Reference ----------- -------------------- ------------------------------ 0 Reserved This document 1 Encapsulation This document & [I-D.ietf-idr-tunnel-encaps] 2 Protocol Type This document & [I-D.ietf-idr-tunnel-encaps] 3 Endpoint This document 4 Color This document 5 Load-Balancing Block This document & [RFC5640] 6 IP QoS This document & [I-D.ietf-idr-tunnel-encaps] 7 UDP Destination Port This document & [I-D.ietf-idr-tunnel-encaps] 8-65499 Unassigned 65500-65534 Experimental This document 65535 Reserved This document Figure 5: OSPF Tunnel Parameter Sub-TLVs Registry 8. Security Considerations Security considerations applicable to softwires can be found in the mesh framework [RFC5565]. In general, security issues of the tunnel protocols signaled through this OSPF capability extension are inherited. If a third-party is able to modify any of the information that is used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type, user data packets may end up getting misrouted, mis-delivered, and/or dropped. However, since an OSPF routing domain is usually a well-controlled network under a single administrative domain, the possibility of the above attack is very low. We note that the last paragraph of Section 6 forbid the establishment of a tunnel toward arbitrary destinations. It prohibits a destination outside of the OSPF domain. This avoid that a third- party gaining access to an OSPF router be able to send the traffic to other destinations, e.g., for inspection purposes. Security considerations for the base OSPF protocol are covered in [RFC2328] and [RFC5340]. Xu, et al. Expires April 12, 2018 [Page 8] Internet-Draft Tunnel Encapsulations RI October 2017 9. Contributors Uma Chunduri Huawei Email: uma.chunduri@gmail.com 10. Acknowledgements This document is partially inspired by [RFC5512]. The authors would like to thank Greg Mirsky, John E Drake, Carlos Pignataro and Karsten Thomann for their valuable comments on this document. Special thanks should be given to Acee Lindem for his multiple detailed reviews of this document and help. The authors would like to thank Pete Resnick, Joe Touch, David Mandelberg, Sabrina Tanamal, Tim Wicinski, Amanda Baber for their Last Call reviews and thank Spencer Dawkins, Mirja Kuehlewind, Ben Campbell, Benoit Claise, Alvaro Retana, Adam Roach and Suresh Krishnan for their AD reviews. 11. References 11.1. Normative References [I-D.ietf-idr-tunnel-encaps] Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 (work in progress), July 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- Balancing for Mesh Softwires", RFC 5640, DOI 10.17487/RFC5640, August 2009, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Xu, et al. Expires April 12, 2018 [Page 9] Internet-Draft Tunnel Encapsulations RI October 2017 11.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, DOI 10.17487/RFC5512, April 2009, . [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, DOI 10.17487/RFC5565, June 2009, . [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . Authors' Addresses Xiaohu Xu (editor) Huawei Email: xuxiaohu@huawei.com Bruno Decraene (editor) Orange Email: bruno.decraene@orange.com Robert Raszuk Bloomberg LP Email: robert@raszuk.net Xu, et al. Expires April 12, 2018 [Page 10] Internet-Draft Tunnel Encapsulations RI October 2017 Luis M. Contreras Telefonica I+D Email: luismiguel.contrerasmurillo@telefonica.com Luay Jalil Verizon Email: luay.jalil@verizon.com Xu, et al. Expires April 12, 2018 [Page 11] ./draft-ietf-ospf-mpls-elc-15.txt0000644000764400076440000004411013665136642016053 0ustar iustyiusty LSR Working Group X. Xu Internet-Draft Alibaba Inc Intended status: Standards Track S. Kini Expires: December 3, 2020 P. Psenak C. Filsfils S. Litkowski Cisco Systems, Inc. M. Bocci Nokia June 1, 2020 Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF draft-ietf-ospf-mpls-elc-15 Abstract Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities using OSPFv2 and OSPFv3 and BGP-LS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 3, 2020. Xu, et al. Expires December 3, 2020 [Page 1] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Advertising ELC Using OSPF . . . . . . . . . . . . . . . . . 3 3.1. Advertising ELC Using OSPFv2 . . . . . . . . . . . . . . 3 3.2. Advertising ELC Using OSPFv3 . . . . . . . . . . . . . . 4 4. Advertising ERLD Using OSPF . . . . . . . . . . . . . . . . . 4 5. Signaling ELC and ERLD in BGP-LS . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [RFC6790] describes a method to load-balance Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels (EL). It also introduces the concept of Entropy Label Capability (ELC) and defines the signaling of this capability via MPLS signaling protocols. Recently, mechanisms have been defined to signal labels via link- state Interior Gateway Protocols (IGP) such as OSPFv2 [RFC8665] and OSPFv3 [RFC8666]. This draft defines a mechanism to signal the ELC using OSPFv2 and OSPFv3. In cases where Segment Routing (SR) is used with the MPLS Data Plane (e.g., SR-MPLS [RFC8660]), it would be useful for ingress LSRs to know each intermediate LSR's capability of reading the maximum label stack depth and performing EL-based load-balancing. This capability, Xu, et al. Expires December 3, 2020 [Page 2] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 referred to as Entropy Readable Label Depth (ERLD) as defined in [RFC8662], may be used by ingress LSRs to determine the position of the EL label in the stack, and whether it is necessary to insert multiple ELs at different positions in the label stack. This document defines a mechanism to signal the ERLD using OSPFv2 and OSPFv3. 2. Terminology This memo makes use of the terms defined in [RFC6790], and [RFC8662]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The key word OSPF is used throughout the document to refer to both OSPFv2 and OSPFv3. 3. Advertising ELC Using OSPF Even though ELC is a property of the node, in some cases it is advantageous to associate and advertise the ELC with a prefix. In multi-area networks, routers may not know the identity of the prefix originator in a remote area, or may not know the capabilities of such originator. Similarly, in a multi domain network, the identity of the prefix originator and its capabilities may not be known to the ingress LSR. If a router has multiple interfaces, the router MUST NOT announce ELC unless all of its interfaces are capable of processing ELs. If the router supports ELs on all of its interfaces, it SHOULD advertise the ELC with every local host prefix it advertises in OSPF. 3.1. Advertising ELC Using OSPFv2 [RFC7684] defines the OSPFv2 Extended Prefix TLV to advertise additional attributes associated with a prefix. The OSPFv2 Extended Prefix TLV includes a one-octet Flags field. A new flag in the Flags field is used to signal the ELC for the prefix: 0x20 - E-Flag (ELC Flag): Set by the advertising router to indicate that the prefix originator is capable of processing ELs. The ELC signaling MUST be preserved when an OSPF Area Border Router (ABR) distributes information between areas. To do so, an ABR MUST Xu, et al. Expires December 3, 2020 [Page 3] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 originate an OSPFv2 Extended Prefix Opaque LSA [RFC7684] including the received ELC setting. When an OSPF Autonomous System Boundary Router (ASBR) redistributes a prefix from another instance of OSPF or from some other protocol, it SHOULD preserve the ELC signaling for the prefix if it exists. To do so, an ASBR SHOULD originate an Extended Prefix Opaque LSA [RFC7684] including the ELC setting of the redistributed prefix. The flooding scope of the Extended Prefix Opaque LSA MUST match the flooding scope of the LSA that an ASBR originates as a result of the redistribution. The exact mechanism used to exchange ELC between protocol instances on an ASBR is outside of the scope of this document. 3.2. Advertising ELC Using OSPFv3 [RFC5340] defines the OSPFv3 PrefixOptions field to indicate capabilities associated with a prefix. A new bit in the OSPFv3 PrefixOptions is used to signal the ELC for the prefix: 0x40 - E-Flag (ELC Flag): Set by the advertising router to indicate that the prefix originator is capable of processing ELs. The ELC signaling MUST be preserved when an OSPFv3 Area Border Router (ABR) distributes information between areas. The setting of the ELC Flag in the Inter-Area-Prefix-LSA [RFC5340] or in the Inter-Area-Prefix TLV [RFC8362], generated by an ABR, MUST be the same as the value the ELC Flag associated with the prefix in the source area. When an OSPFv3 Autonomous System Boundary Router (ASBR) redistributes a prefix from another instance of OSPFv3 or from some other protocol, it SHOULD preserve the ELC signaling for the prefix if it exists. The setting of the ELC Flag in the AS- External-LSA, NSSA-LSA [RFC5340] or in the External-Prefix TLV [RFC8362], generated by an ASBR, MUST be the same as the value of the ELC Flag associated with the prefix in the source domain. The exact mechanism used to exchange ELC between protocol instances on the ASBR is outside of the scope of this document. 4. Advertising ERLD Using OSPF The ERLD is advertised in a Node MSD TLV [RFC8476] using the ERLD-MSD type defined in [I-D.ietf-isis-mpls-elc]. If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest value found across all of its interfaces. Xu, et al. Expires December 3, 2020 [Page 4] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 The absence of ERLD-MSD advertisements indicates only that the advertising node does not support advertisement of this capability. When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored. The considerations for advertising the ERLD are specified in [RFC8662]. 5. Signaling ELC and ERLD in BGP-LS The OSPF extensions defined in this document can be advertised via BGP-LS (Distribution of Link-State and TE Information Using BGP) [RFC7752] using existing BGP-LS TLVs. The ELC is advertised using the Prefix Attribute Flags TLV as defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext]. The ERLD-MSD is advertised using the Node MSD TLV as defined in [I-D.ietf-idr-bgp-ls-segment-routing-msd]. 6. IANA Considerations Early allocation has been done by IANA for this document as follows: - Flag 0x20 in the OSPFv2 Extended Prefix TLV Flags registry has been allocated by IANA to the E-Flag (ELC Flag). - Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been allocated by IANA to the E-Flag (ELC Flag). 7. Security Considerations This document specifies the ability to advertise additional node capabilities using OSPF and BGP-LS. As such, the security considerations as described in [RFC5340], [RFC7770], [RFC7752], [RFC7684], [RFC8476], [RFC8662], [I-D.ietf-idr-bgp-ls-segment-routing-ext] and [I-D.ietf-idr-bgp-ls-segment-routing-msd] are applicable to this document. Incorrectly setting the E flag during origination, propagation or redistribution may lead to poor or no load-balancing of the MPLS traffic or black-holing of the MPLS traffic on the egress node. Incorrectly setting of the ERLD value may lead to poor or no load- balancing of the MPLS traffic. Xu, et al. Expires December 3, 2020 [Page 5] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 8. Contributors The following people contributed to the content of this document and should be considered as co-authors: Gunter Van de Velde (editor) Nokia Antwerp BE Email: gunter.van_de_velde@nokia.com Wim Henderickx Nokia Belgium Email: wim.henderickx@nokia.com Keyur Patel Arrcus USA Email: keyur@arrcus.com 9. Acknowledgements The authors would like to thank Yimin Shen, George Swallow, Acee Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno Decraene and Carlos Pignataro for their valuable comments. 10. References 10.1. Normative References [I-D.ietf-idr-bgp-ls-segment-routing-ext] Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "BGP Link-State extensions for Segment Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 (work in progress), June 2019. Xu, et al. Expires December 3, 2020 [Page 6] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 [I-D.ietf-idr-bgp-ls-segment-routing-msd] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State", draft-ietf- idr-bgp-ls-segment-routing-msd-18 (work in progress), May 2020. [I-D.ietf-isis-mpls-elc] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS", draft-ietf- isis-mpls-elc-13 (work in progress), May 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Xu, et al. Expires December 3, 2020 [Page 7] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, . [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels", RFC 8662, DOI 10.17487/RFC8662, December 2019, . 10.2. Informative References [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, . Authors' Addresses Xiaohu Xu Alibaba Inc Email: xiaohu.xxh@alibaba-inc.com Sriganesh Kini Email: sriganeshkini@gmail.com Xu, et al. Expires December 3, 2020 [Page 8] Internet-Draft Signaling ELC and ERLD using OSPF June 2020 Peter Psenak Cisco Systems, Inc. Eurovea Centre, Central 3 Pribinova Street 10 Bratislava 81109 Slovakia Email: ppsenak@cisco.com Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com Stephane Litkowski Cisco Systems, Inc. La Rigourdiere Cesson Sevigne France Email: slitkows@cisco.com Matthew Bocci Nokia Shoppenhangers Road Maidenhead, Berks UK Email: matthew.bocci@nokia.com Xu, et al. Expires December 3, 2020 [Page 9] ./draft-ietf-ospf-yang-29.txt0000644000764400076440000071133513552116300015274 0ustar iustyiusty Internet D. Yeung Internet-Draft Arrcus Intended status: Standards Track Y. Qu Expires: April 19, 2020 Futurewei J. Zhang Juniper Networks I. Chen The MITRE Corporation A. Lindem Cisco Systems October 17, 2019 YANG Data Model for OSPF Protocol draft-ietf-ospf-yang-29 Abstract This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 19, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of Yeung, et al. Expires April 19, 2020 [Page 1] Internet-Draft OSPF YANG Data Model October 2019 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3 2.1. OSPF Operational State . . . . . . . . . . . . . . . . . 3 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5 2.4. Optional Features . . . . . . . . . . . . . . . . . . . . 5 2.5. OSPF Router Configuration/Operational State . . . . . . . 7 2.6. OSPF Area Configuration/Operational State . . . . . . . . 10 2.7. OSPF Interface Configuration/Operational State . . . . . 16 2.8. OSPF Notifications . . . . . . . . . . . . . . . . . . . 19 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 23 3. OSPF YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 4. Security Considerations . . . . . . . . . . . . . . . . . . . 120 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 123 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.1. Normative References . . . . . . . . . . . . . . . . . . 124 7.2. Informative References . . . . . . . . . . . . . . . . . 129 Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131 1. Overview YANG [RFC6020][RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241], RESTCONF [RFC8040], and other Network Management protocols. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic APIs. This document defines a YANG data model that can be used to configure and manage OSPF and it is an augmentation to the core routing data model. It fully conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. A core routing data model is defined in [RFC8349], and it provides the basis for the development of data models for routing protocols. The interface data model is defined in [RFC8343] and is used for referencing interfaces from the routing Yeung, et al. Expires April 19, 2020 [Page 2] Internet-Draft OSPF YANG Data Model October 2019 protocol. The key-chain data model used for OSPF authentication is defined in [RFC8177] and provides both a reference to configured key- chains and an enumeration of cryptographic algorithms. Both OSPFv2 [RFC2328] and OSPFv3 [RFC5340] are supported. In addition to the core OSPF protocol, features described in other OSPF RFCs are also supported. These includes demand circuit [RFC1793], traffic engineering [RFC3630], multiple address family [RFC5838], graceful restart [RFC3623] [RFC5187], NSSA [RFC3101], and OSPFv2 or OSPFv3 as a PE-CE Protocol [RFC4577], [RFC6565]. These non-core features are optional in the OSPF data model. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Tree Diagrams This document uses the graphical representation of data models defined in [RFC8340]. 2. Design of Data Model Although the basis of OSPF configuration elements like routers, areas, and interfaces remains the same, the detailed configuration model varies among router vendors. Differences are observed in terms of how the protocol instance is tied to the routing domain and how multiple protocol instances are be instantiated among others. The goal of this document is to define a data model that provides a common user interface to the OSPFv2 and OSPFv3 protocols. There is very little information that is designated as "mandatory", providing freedom for vendors to adapt this data model to their respective product implementations. 2.1. OSPF Operational State The OSPF operational state is included in the same tree as OSPF configuration consistent with the Network Management Datastore Architecture [RFC8342]. Consequently, only the routing container in the ietf-routing model [RFC8349] is augmented. The routing-state container is not augmented. Yeung, et al. Expires April 19, 2020 [Page 3] Internet-Draft OSPF YANG Data Model October 2019 2.2. Overview The OSPF YANG module defined in this document has all the common building blocks for the OSPF protocol. The OSPF YANG module augments the /routing/control-plane-protocols/ control-plane-protocol path defined in the ietf-routing module. The ietf-ospf model defines a single instance of OSPF which may be instantiated as an OSPFv2 or OSPFv3 instance. Multiple instances are instantiated as multiple control-plane protocols instances. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw af? identityref . . +--rw areas | +--rw area* [area-id] | +--rw area-id area-id-type | . | . | +--rw virtual-links | | +--rw virtual-link* [transit-area-id router-id] | | . | | . | +--rw sham-links {pe-ce-protocol}? | | +--rw sham-link* [local-id remote-id] | | . | | . | +--rw interfaces | +--rw interface* [name] | . | . +--rw topologies {multi-topology}? +--rw topology* [name] . . The ospf container includes one OSPF protocol instance. The instance includes OSPF router level configuration and operational state. Each OSPF instance maps to a control-plane-protcol instance as defined in [RFC8349]. Yeung, et al. Expires April 19, 2020 [Page 4] Internet-Draft OSPF YANG Data Model October 2019 The area and area/interface containers define the OSPF configuration and operational state for OSPF areas and interfaces respectively. The topologies container defines the OSPF configuration and operational state for OSPF topologies when the multi-topology feature is supported. 2.3. OSPFv2 and OSPFv3 The data model defined herein supports both OSPFv2 and OSPFv3. The field 'version' is used to indicate the OSPF version and is mandatory. Based on the configured version, the data model varies to accommodate the differences between OSPFv2 and OSPFv3. 2.4. Optional Features Optional features are beyond the basic OSPF configuration and it is the responsibility of each vendor to decide whether to support a given feature on a particular device. This model defines the following optional features: 1. multi-topology: Support Multi-Topology Routing (MTR) [RFC4915]. 2. multi-area-adj: Support OSPF multi-area adjacency [RFC5185]. 3. explicit-router-id: Support explicit per-instance Router-ID specification. 4. demand-circuit: Support OSPF demand circuits [RFC1793]. 5. mtu-ignore: Support disabling OSPF Database Description packet MTU mismatch checking specified in section 10.6 of [RFC2328]. 6. lls: Support OSPF link-local signaling (LLS) [RFC5613]. 7. prefix-suppression: Support OSPF prefix advertisement suppression [RFC6860]. 8. ttl-security: Support OSPF Time to Live (TTL) security check support [RFC5082]. 9. nsr: Support OSPF Non-Stop Routing (NSR). The OSPF NSR feature allows a router with redundant control-plane capability (e.g., dual Route-Processor (RP) cards) to maintain its state and adjacencies during planned and unplanned control-plane processing restarts. It differs from graceful-restart or Non- Yeung, et al. Expires April 19, 2020 [Page 5] Internet-Draft OSPF YANG Data Model October 2019 Stop Forwarding (NSF) in that no protocol signaling or assistance from adjacent OSPF neighbors is required to recover control-plane state. 10. graceful-restart: Support Graceful OSPF Restart [RFC3623], [RFC5187]. 11. auto-cost: Support OSPF interface cost calculation according to reference bandwidth [RFC2328]. 12. max-ecmp: Support configuration of the maximum number of Equal- Cost Multi-Path (ECMP) paths. 13. max-lsa: Support configuration of the maximum number of LSAs the OSPF instance will accept [RFC1765]. 14. te-rid: Support configuration of the Traffic Engineering (TE) Router-ID, i.e., the Router Address described in Section 2.4.1 of [RFC3630] or the Router IPv6 Address TLV described in Section 3 of [RFC5329]. 15. ldp-igp-sync: Support LDP IGP synchronization [RFC5443]. 16. ospfv2-authentication-trailer: Support OSPFv2 Authentication trailer as specified in [RFC5709] or [RFC7474]. 17. ospfv3-authentication-ipsec: Support IPsec for OSPFv3 authentication [RFC4552]. 18. ospfv3-authentication-trailer: Support OSPFv3 Authentication trailer as specified in [RFC7166]. 19. fast-reroute: Support IP Fast Reroute (IP-FRR) [RFC5714]. 20. node-flag: Support node-flag for OSPF prefixes. [RFC7684]. 21. node-tag: Support node admin tag for OSPF instances [RFC7777]. 22. lfa: Support Loop-Free Alternates (LFAs) [RFC5286]. 23. remote-lfa: Support Remote Loop-Free Alternates (R-LFA) [RFC7490]. 24. stub-router: Support RFC 6987 OSPF Stub Router advertisement [RFC6987]. 25. pe-ce-protocol: Support OSPF as a PE-CE protocol [RFC4577], [RFC6565]. Yeung, et al. Expires April 19, 2020 [Page 6] Internet-Draft OSPF YANG Data Model October 2019 26. ietf-spf-delay: Support IETF SPF delay algorithm [RFC8405]. 27. bfd: Support BFD detection of OSPF neighbor reachability [RFC5880], [RFC5881], and [I-D.ietf-bfd-yang]. 28. hybrid-interface: Support OSPF Hybrid Broadcast and Point-to- Point Interfaces [RFC6845]. It is expected that vendors will support additional features through vendor-specific augmentations. 2.5. OSPF Router Configuration/Operational State The ospf container is the top-level container in this data model. It represents an OSPF protocol instance and contains the router level configuration and operational state. The operational state includes the instance statistics, IETF SPF delay statistics, AS-Scoped Link State Database, local RIB, SPF Log, and the LSA log. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw af iana-rt-types:address-family +--rw enable? boolean +--rw explicit-router-id? rt-types:router-id | {explicit-router-id}? +--rw preference | +--rw (scope)? | +--:(single-value) | | +--rw all? uint8 | +--:(multi-values) | +--rw (granularity)? | | +--:(detail) | | | +--rw intra-area? uint8 | | | +--rw inter-area? uint8 | | +--:(coarse) | | +--rw internal? uint8 | +--rw external? uint8 +--rw nsr {nsr}? | +--rw enable? boolean +--rw graceful-restart {graceful-restart}? | +--rw enable? boolean | +--rw helper-enable? boolean | +--rw restart-interval? uint16 | +--rw helper-strict-lsa-checking? boolean Yeung, et al. Expires April 19, 2020 [Page 7] Internet-Draft OSPF YANG Data Model October 2019 +--rw auto-cost {auto-cost}? | +--rw enable? boolean | +--rw reference-bandwidth? uint32 +--rw spf-control | +--rw paths? uint16 {max-ecmp}? | +--rw ietf-spf-delay {ietf-spf-delay}? | +--rw initial-delay? uint16 | +--rw short-delay? uint16 | +--rw long-delay? uint16 | +--rw hold-down? uint16 | +--rw time-to-learn? uint16 | +--ro current-state? enumeration | +--ro remaining-time-to-learn? uint16 | +--ro remaining-hold-down? uint16 | +--ro last-event-received? yang:timestamp | +--ro next-spf-time? yang:timestamp | +--ro last-spf-time? yang:timestamp +--rw database-control | +--rw max-lsa? uint32 {max-lsa}? +--rw stub-router {stub-router}? | +--rw (trigger)? | +--:(always) | +--rw always! +--rw mpls | +--rw te-rid {te-rid}? | | +--rw ipv4-router-id? inet:ipv4-address | | +--rw ipv6-router-id? inet:ipv6-address | +--rw ldp | +--rw igp-sync? boolean {ldp-igp-sync}? +--rw fast-reroute {fast-reroute}? | +--rw lfa {lfa}? +--ro protected-routes | +--ro af-stats* [af prefix alternate] | +--ro af iana-rt-types:address-family | +--ro prefix string | +--ro alternate string | +--ro alternate-type? enumeration | +--ro best? boolean | +--ro non-best-reason? string | +--ro protection-available? bits | +--ro alternate-metric1? uint32 | +--ro alternate-metric2? uint32 | +--ro alternate-metric3? uint32 +--ro unprotected-routes | +--ro af-stats* [af prefix] | +--ro af iana-rt-types:address-family | +--ro prefix string +--ro protection-statistics* [frr-protection-method] Yeung, et al. Expires April 19, 2020 [Page 8] Internet-Draft OSPF YANG Data Model October 2019 | +--ro frr-protection-method string | +--ro af-stats* [af] | +--ro af iana-rt-types:address-family | +--ro total-routes? uint32 | +--ro unprotected-routes? uint32 | +--ro protected-routes? uint32 | +--ro linkprotected-routes? uint32 | +--ro nodeprotected-routes? uint32 +--rw node-tags {node-tag}? | +--rw node-tag* [tag] | +--rw tag uint32 +--ro router-id? +--ro local-rib | +--ro route* [prefix] | +--ro prefix inet:ip-prefix | +--ro next-hops | | +--ro next-hop* [next-hop] | | +--ro outgoing-interface? if:interface-ref | | +--ro next-hop inet:ip-address | +--ro metric? uint32 | +--ro route-type? route-type | +--ro route-tag? uint32 +--ro statistics | +--ro discontinuity-time yang:date-and-time | +--ro originate-new-lsa-count? yang:counter32 | +--ro rx-new-lsas-count? yang:counter32 | +--ro as-scope-lsa-count? yang:gauge32 | +--ro as-scope-lsa-chksum-sum? uint32 | +--ro database | +--ro as-scope-lsa-type* | +--ro lsa-type? uint16 | +--ro lsa-count? yang:gauge32 | +--ro lsa-cksum-sum? int32 +--ro database | +--ro as-scope-lsa-type* [lsa-type] | +--ro as-scope-lsas | +--ro as-scope-lsa* [lsa-id adv-router] | +--ro lsa-id union | +--ro adv-router inet:ipv4-address | +--ro decoded-completed? boolean | +--ro raw-data? yang:hex-string | +--ro (version)? | +--:(ospfv2) | | +--ro ospfv2 . . . . | +--:(ospfv3) | +--ro ospfv3 Yeung, et al. Expires April 19, 2020 [Page 9] Internet-Draft OSPF YANG Data Model October 2019 . . +--ro spf-log | +--ro event* [id] | +--ro id uint32 | +--ro spf-type? enumeration | +--ro schedule-timestamp? yang:timestamp | +--ro start-timestamp? yang:timestamp +--ro end-timestamp? yang:timestamp | +--ro trigger-lsa* | +--ro area-id? area-id-type | +--ro link-id? union | +--ro type? uint16 | +--ro lsa-id? yang:dotted-quad | +--ro adv-router? yang:dotted-quad | +--ro seq-num? uint32 +--ro lsa-log | +--ro event* [id] | +--ro id uint32 | +--ro lsa | | +--ro area-id? area-id-type | | +--ro link-id? union | | +--ro type? uint16 | | +--ro lsa-id? yang:dotted-quad | | +--ro adv-router? yang:dotted-quad | | +--ro seq-num? uint32 | +--ro received-timestamp? yang:timestamp | +--ro reason? identityref . . 2.6. OSPF Area Configuration/Operational State The area container contains OSPF area configuration and the list of interface containers representing all the OSPF interfaces in the area. The area operational state includes the area statistics and the Area Link State Database (LSDB). module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw areas | +--rw area* [area-id] | +--rw area-id area-id-type | +--rw area-type? identityref Yeung, et al. Expires April 19, 2020 [Page 10] Internet-Draft OSPF YANG Data Model October 2019 | +--rw summary? boolean | +--rw default-cost? uint32 | +--rw ranges | | +--rw range* [prefix] | | +--rw prefix inet:ip-prefix | | +--rw advertise? boolean | | +--rw cost? uint24 | +--rw topologies {ospf:multi-topology}? | | +--rw topology* [name] | | +--rw name -> ../../../../../../../../ | | ../../../rt:ribs/rib/name | | +--rw summary? boolean | | +--rw default-cost? ospf-metric | | +--rw ranges | | +--rw range* [prefix] | | +--rw prefix inet:ip-prefix | | +--rw advertise? boolean | | +--rw cost? ospf-metric | +--ro statistics | | +--ro discontinuity-time yang:date-and-time | | +--ro spf-runs-count? yang:counter32 | | +--ro abr-count? yang:gauge32 | | +--ro asbr-count? yang:gauge32 | | +--ro ar-nssa-translator-event-count? | | yang:counter32 | | +--ro area-scope-lsa-count? yang:gauge32 | | +--ro area-scope-lsa-cksum-sum? int32 | | +--ro database | | +--ro area-scope-lsa-type* | | +--ro lsa-type? uint16 | | +--ro lsa-count? yang:gauge32 | | +--ro lsa-cksum-sum? int32 | +--ro database | | +--ro area-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro area-scope-lsas | | +--ro area-scope-lsa* [lsa-id adv-router] | | +--ro lsa-id union . . . . . . | | +--ro (version)? | | +--:(ospfv2) | | | +--ro ospfv2 | | | +--ro header . . . . . . . . | | | +--ro body | | | +--ro router Yeung, et al. Expires April 19, 2020 [Page 11] Internet-Draft OSPF YANG Data Model October 2019 . . . . . . . . | | | +--ro network . . . . . . . . | | | +--ro summary . . . . . . . . | | | +--ro external . . . . . . . . | | | +--ro opaque . . . . . . . . | | +--:(ospfv3) | | +--ro ospfv3 | | +--ro header . . . . . . | | +--ro body | | +--ro router . . . . . . | | +--ro network . . . . . . | | +--ro inter-area-prefix . . . . . . | | +--ro inter-area-router . . . . . . | | +--ro as-external . . . . . . | | +--ro nssa . . . . . . | | +--ro link . . . . . . | | +--ro intra-area-prefix . . . . . . | | +--ro router-information . . . . . . | +--rw virtual-links Yeung, et al. Expires April 19, 2020 [Page 12] Internet-Draft OSPF YANG Data Model October 2019 | | +--rw virtual-link* [transit-area-id router-id] | | +--rw transit-area-id -> ../../../../ | | area/area-id | | +--rw router-id rt-types:router-id | | +--rw hello-interval? uint16 | | +--rw dead-interval? uint32 | | +--rw retransmit-interval? uint16 | | +--rw transmit-delay? uint16 | | +--rw lls? boolean {lls}? | | +--rw ttl-security {ttl-security}? | | | +--rw enable? boolean | | | +--rw hops? uint8 | | +--rw enable? boolean | | +--rw authentication | | | +--rw (auth-type-selection)? | | | +--:(ospfv2-auth) | | | | +--rw ospfv2-auth-trailer-rfc? | | | | | ospfv2-auth-trailer-rfc-version | | | | | {ospfv2-authentication-trailer}? | | | | +--rw (ospfv2-auth-specification)? | | | | +--:(auth-key-chain) {key-chain}? | | | | | +--rw ospfv2-key-chain? | | | | | key-chain:key-chain-ref | | | | +--:(auth-key-explicit) | | | | +--rw ospfv2-key-id? uint32 | | | | +--rw ospfv2-key? string | | | | +--rw ospfv2-crypto-algorithm? | | | | identityref | | | +--:(ospfv3-auth-ipsec) | | | | {ospfv3-authentication-ipsec}? | | | | +--rw sa? string | | | +--:(ospfv3-auth-trailer) | | | | {ospfv3-authentication-trailer}? | | | +--rw (ospfv3-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv3-key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw ospfv3-sa-id? uint16 | | | +--rw ospfv3-key? string | | | +--rw ospfv3-crypto-algorithm? | | | identityref | | +--ro cost? uint16 | | +--ro state? if-state-type | | +--ro hello-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro wait-timer? rt-types: | | | rtimer-value-seconds16 Yeung, et al. Expires April 19, 2020 [Page 13] Internet-Draft OSPF YANG Data Model October 2019 | | +--ro dr-router-id? rt-types:router-id | | +--ro dr-ip-addr? inet:ip-address | | +--ro bdr-router-id? rt-types:router-id | | +--ro bdr-ip-addr? inet:ip-address | | +--ro statistics | | | +--ro discontinuity-time yang:date-and-time | | | +--ro if-event-count? yang:counter32 | | | +--ro link-scope-lsa-count? yang:gauge32 | | | +--ro link-scope-lsa-cksum-sum? | | | uint32 | | | +--ro database | | | +--ro link-scope-lsa-type* | | | +--ro lsa-type? uint16 | | | +--ro lsa-count? yang:gauge32 | | | +--ro lsa-cksum-sum? int32 | | +--ro neighbors | | | +--ro neighbor* [neighbor-router-id] | | | +--ro neighbor-router-id | | | rt-types:router-id | | | +--ro address? inet:ip-address | | | +--ro dr-router-id? rt-types:router-id | | | +--ro dr-ip-addr? inet:ip-address | | | +--ro bdr-router-id? rt-types:router-id | | | +--ro bdr-ip-addr? inet:ip-address | | | +--ro state? nbr-state-type | | | +--ro dead-timer? rt-types: | | | | rtimer-value-seconds16 | | | +--ro statistics | | | +--ro discontinuity-time | | | yang:date-and-time | | | +--ro nbr-event-count? | | | yang:counter32 | | | +--ro nbr-retrans-qlen? | | | yang:gauge32 | | +--ro database | | +--ro link-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro link-scope-lsas . . . . | +--rw sham-links {pe-ce-protocol}? | | +--rw sham-link* [local-id remote-id] | | +--rw local-id inet:ip-address | | +--rw remote-id inet:ip-address | | +--rw hello-interval? uint16 | | +--rw dead-interval? uint32 | | +--rw retransmit-interval? uint16 | | +--rw transmit-delay? uint16 Yeung, et al. Expires April 19, 2020 [Page 14] Internet-Draft OSPF YANG Data Model October 2019 | | +--rw lls? boolean {lls}? | | +--rw ttl-security {ttl-security}? | | | +--rw enable? boolean | | | +--rw hops? uint8 | | +--rw enable? boolean | | +--rw authentication | | | +--rw (auth-type-selection)? | | | +--:(ospfv2-auth) | | | | +--rw ospfv2-auth-trailer-rfc? | | | | | ospfv2-auth-trailer-rfc-version | | | | | {ospfv2-authentication-trailer}? | | | | +--rw (ospfv2-auth-specification)? | | | | +--:(auth-key-chain) {key-chain}? | | | | | +--rw ospfv2-key-chain? | | | | | key-chain:key-chain-ref | | | | +--:(auth-key-explicit) | | | | +--rw ospfv2-key-id? uint32 | | | | +--rw ospfv2-key? string | | | | +--rw ospfv2-crypto-algorithm? | | | | identityref | | | +--:(ospfv3-auth-ipsec) | | | | {ospfv3-authentication-ipsec}? | | | | +--rw sa? string | | | +--:(ospfv3-auth-trailer) | | | | {ospfv3-authentication-trailer}? | | | +--rw (ospfv3-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv3-key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw ospfv3-sa-id? uint16 | | | +--rw ospfv3-key? string | | | +--rw ospfv3-crypto-algorithm? | | | identityref | | +--rw cost? uint16 | | +--rw mtu-ignore? boolean | | {mtu-ignore}? | | +--rw prefix-suppression? boolean | | {prefix-suppression}? | | +--ro state? if-state-type | | +--ro hello-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro wait-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro dr-router-id? rt-types:router-id | | +--ro dr-ip-addr? inet:ip-address | | +--ro bdr-router-id? rt-types:router-id | | +--ro bdr-ip-addr? inet:ip-address Yeung, et al. Expires April 19, 2020 [Page 15] Internet-Draft OSPF YANG Data Model October 2019 | | +--ro statistics | | | +--ro discontinuity-time yang:date-and-time | | | +--ro if-event-count? yang:counter32 | | | +--ro link-scope-lsa-count? yang:gauge32 | | | +--ro link-scope-lsa-cksum-sum? | | | uint32 | | | +--ro database | | | +--ro link-scope-lsa-type* | | | +--ro lsa-type? uint16 | | | +--ro lsa-count? yang:gauge32 | | | +--ro lsa-cksum-sum? int32 | | +--ro neighbors | | | +--ro neighbor* [neighbor-router-id] | | | +--ro neighbor-router-id | | | rt-types:router-id | | | +--ro address? inet:ip-address | | | +--ro dr-router-id? rt-types:router-id | | | +--ro dr-ip-addr? inet:ip-address | | | +--ro bdr-router-id? rt-types:router-id | | | +--ro bdr-ip-addr? inet:ip-address | | | +--ro state? nbr-state-type | | | +--ro cost? uint32 | | | +--ro dead-timer? rt-types: | | | | rtimer-value-seconds16 | | | +--ro statistics | | | +--ro nbr-event-count? | | | yang:counter32 | | | +--ro nbr-retrans-qlen? | | | yang:gauge32 | | +--ro database | | +--ro link-scope-lsa-type* [lsa-type] | | +--ro lsa-type uint16 | | +--ro link-scope-lsas . . . . 2.7. OSPF Interface Configuration/Operational State The interface container contains OSPF interface configuration and operational state. The interface operational state includes the statistics, list of neighbors, and Link-Local Link State Database (LSDB). module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . Yeung, et al. Expires April 19, 2020 [Page 16] Internet-Draft OSPF YANG Data Model October 2019 . +--rw areas | +--rw area* [area-id] | . | . | +--rw interfaces | +--rw interface* [name] | +--rw name if:interface-ref | +--rw interface-type? enumeration | +--rw passive? boolean | +--rw demand-circuit? boolean | {demand-circuit}? | +--rw priority? uint8 | +--rw multi-areas {multi-area-adj}? | | +--rw multi-area* [multi-area-id] | | +--rw multi-area-id area-id-type | | +--rw cost? uint16 | +--rw static-neighbors | | +--rw neighbor* [identifier] | | +--rw identifier inet:ip-address | | +--rw cost? uint16 | | +--rw poll-interval? uint16 | | +--rw priority? uint8 | +--rw node-flag? boolean | {node-flag}? | +--rw bfd {bfd}? | | +--rw enable? boolean | +--rw fast-reroute {fast-reroute}? | | +--rw lfa {lfa}? | | +--rw candidate-enable? boolean | | +--rw enable? boolean | | +--rw remote-lfa {remote-lfa}? | | +--rw enable? boolean | +--rw hello-interval? uint16 | +--rw dead-interval? uint32 | +--rw retransmit-interval? uint16 | +--rw transmit-delay? uint16 | +--rw lls? boolean {lls}? | +--rw ttl-security {ttl-security}? | | +--rw enable? boolean | | +--rw hops? uint8 | +--rw enable? boolean | +--rw authentication | | +--rw (auth-type-selection)? | | +--:(ospfv2-auth) | | | +--rw ospfv2-auth-trailer-rfc? | | | | ospfv2-auth-trailer-rfc-version | | | | {ospfv2-authentication-trailer}? Yeung, et al. Expires April 19, 2020 [Page 17] Internet-Draft OSPF YANG Data Model October 2019 | | | +--rw (ospfv2-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv2-key-chain? | | | | key-chain:key-chain-ref | | | +--:(auth-key-explicit) | | | +--rw ospfv2-key-id? uint32 | | | +--rw ospfv2-key? string | | | +--rw ospfv2-crypto-algorithm? | | | identityref | | +--:(ospfv3-auth-ipsec) | | | {ospfv3-authentication-ipsec}? | | | +--rw sa? string | | +--:(ospfv3-auth-trailer) | | | {ospfv3-authentication-trailer}? | | +--rw (ospfv3-auth-specification)? | | +--:(auth-key-chain) {key-chain}? | | | +--rw ospfv3-key-chain? | | | key-chain:key-chain-ref | | +--:(auth-key-explicit) | | +--rw ospfv3-sa-id? uint16 | | +--rw ospfv3-key? string | | +--rw ospfv3-crypto-algorithm? | | identityref | +--rw cost? uint16 | +--rw mtu-ignore? boolean | | {mtu-ignore}? | +--rw prefix-suppression? boolean | | {prefix-suppression}? | +--ro state? if-state-type | +--ro hello-timer? rt-types: | | rtimer-value-seconds16 | +--ro wait-timer? rt-types: | | rtimer-value-seconds16 | +--ro dr-router-id? rt-types:router-id | +--ro dr-ip-addr? inet:ip-address | +--ro bdr-router-id? rt-types:router-id | +--ro bdr-ip-addr? inet:ip-address | +--ro statistics | | +--ro if-event-count? yang:counter32 | | +--ro link-scope-lsa-count? yang:gauge32 | | +--ro link-scope-lsa-cksum-sum? | | uint32 | | +--ro database | | +--ro link-scope-lsa-type* | | +--ro lsa-type? uint16 | | +--ro lsa-count? yang:gauge32 | | +--ro lsa-cksum-sum? int32 | +--ro neighbors Yeung, et al. Expires April 19, 2020 [Page 18] Internet-Draft OSPF YANG Data Model October 2019 | | +--ro neighbor* [neighbor-router-id] | | +--ro neighbor-router-id | | rt-types:router-id | | +--ro address? inet:ip-address | | +--ro dr-router-id? rt-types:router-id | | +--ro dr-ip-addr? inet:ip-address | | +--ro bdr-router-id? rt-types:router-id | | +--ro bdr-ip-addr? inet:ip-address | | +--ro state? nbr-state-type | | +--ro dead-timer? rt-types: | | | rtimer-value-seconds16 | | +--ro statistics | | +--ro nbr-event-count? | | yang:counter32 | | +--ro nbr-retrans-qlen? | | yang:gauge32 | +--ro database | . +--ro link-scope-lsa-type* [lsa-type] | . +--ro lsa-type uint16 | . +--ro link-scope-lsas . . . . | +--rw topologies {ospf:multi-topology}? | | +--rw topology* [name] | | +--rw name -> ../../../../../../../../ | | ../../../rt:ribs/rib/name | | +--rw cost? uint32 | +--rw instance-id? uint8 . . 2.8. OSPF Notifications This YANG model defines a list of notifications that inform YANG clients of important events detected during protocol operation. The defined notifications cover the common set of traps from the OSPFv2 MIB [RFC4750] and OSPFv3 MIB [RFC5643]. notifications: +---n if-state-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af Yeung, et al. Expires April 19, 2020 [Page 19] Internet-Draft OSPF YANG Data Model October 2019 | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro state? if-state-type +---n if-config-error | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro packet-source? yang:dotted-quad | +--ro packet-type? packet-type | +--ro error? enumeration +---n nbr-state-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af Yeung, et al. Expires April 19, 2020 [Page 20] Internet-Draft OSPF YANG Data Model October 2019 | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro neighbor-router-id? rt-types:router-id | +--ro neighbor-ip-addr? yang:dotted-quad | +--ro state? nbr-state-type +---n nbr-restart-helper-status-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro neighbor-router-id? rt-types:router-id | +--ro neighbor-ip-addr? yang:dotted-quad | +--ro status? restart-helper-status-type | +--ro age? uint32 | +--ro exit-reason? restart-exit-reason-type +---n if-rx-bad-packet | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? Yeung, et al. Expires April 19, 2020 [Page 21] Internet-Draft OSPF YANG Data Model October 2019 | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro (if-link-type-selection)? | | +--:(interface) | | | +--ro interface | | | +--ro interface? if:interface-ref | | +--:(virtual-link) | | | +--ro virtual-link | | | +--ro transit-area-id? area-id-type | | | +--ro neighbor-router-id? rt-types:router-id | | +--:(sham-link) | | +--ro sham-link | | +--ro area-id? area-id-type | | +--ro local-ip-addr? inet:ip-address | | +--ro remote-ip-addr? inet:ip-address | +--ro packet-source? yang:dotted-quad | +--ro packet-type? packet-type +---n lsdb-approaching-overflow | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro ext-lsdb-limit? uint32 +---n lsdb-overflow | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af | +--ro ext-lsdb-limit? uint32 +---n nssa-translator-status-change | +--ro routing-protocol-name? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +--ro af? | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol | + [rt:name=current()/../routing-protocol-name]/ | + ospf:ospf/af Yeung, et al. Expires April 19, 2020 [Page 22] Internet-Draft OSPF YANG Data Model October 2019 | +--ro area-id? area-id-type | +--ro status? nssa-translator-state-type +---n restart-status-change +--ro routing-protocol-name? + -> /rt:routing/control-plane-protocols/ + control-plane-protocol/name +--ro af? + -> /rt:routing/control-plane-protocols/ + control-plane-protocol + [rt:name=current()/../routing-protocol-name]/ + ospf:ospf/af +--ro status? restart-status-type +--ro restart-interval? uint16 +--ro exit-reason? restart-exit-reason-type 2.9. OSPF RPC Operations The "ietf-ospf" module defines two RPC operations: o clear-database: reset the content of a particular OSPF Link State Database. o clear-neighbor: Reset a particular OSPF neighbor or group of neighbors associated with an OSPF interface. rpcs: +---x clear-neighbor | +---w input | +---w routing-protocol-name | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +---w interface? if:interface-ref +---x clear-database +---w input +---w routing-protocol-name -> /rt:routing/control-plane-protocols/ control-plane-protocol/name 3. OSPF YANG Module The following RFCs and drafts are not referenced in the document text but are referenced in the ietf-ospf.yang module: [RFC0905], [RFC4576], [RFC4973], [RFC5250], [RFC5309], [RFC5642], [RFC5881], [RFC6991], [RFC7770], [RFC7884], [RFC8294], and [RFC8476]. file "ietf-ospf@2019-10-17.yang" module ietf-ospf { yang-version 1.1; Yeung, et al. Expires April 19, 2020 [Page 23] Internet-Draft OSPF YANG Data Model October 2019 namespace "urn:ietf:params:xml:ns:yang:ietf-ospf"; prefix ospf; import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management (NMDA Version)"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import iana-routing-types { prefix "iana-rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177: YANG Data Model for Key Chains"; } import ietf-bfd-types { prefix "bfd-types"; reference "RFC YYYY: YANG Data Model for Bidirectional Forwarding Detection (BFD). Please replace YYYY with published RFC number for draft-ietf-bfd-yang."; Yeung, et al. Expires April 19, 2020 [Page 24] Internet-Draft OSPF YANG Data Model October 2019 } organization "IETF LSR - Link State Routing Working Group"; contact "WG Web: WG List: Editor: Derek Yeung Author: Acee Lindem Author: Yingzhen Qu Author: Salih K A Author: Ing-Wher Chen "; description "This YANG module defines the generic configuration and operational state for the OSPF protocol common to all vendor implementations. It is intended that the module will be extended by vendors to define vendor-specific OSPF configuration parameters and policies, for example, route maps or route policies. This YANG model conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8242. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as Yeung, et al. Expires April 19, 2020 [Page 25] Internet-Draft OSPF YANG Data Model October 2019 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2019-10-17 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for OSPF."; } feature multi-topology { description "Support Multiple-Topology Routing (MTR)."; reference "RFC 4915: Multi-Topology Routing"; } feature multi-area-adj { description "OSPF multi-area adjacency support as in RFC 5185."; reference "RFC 5185: Multi-Area Adjacency"; } feature explicit-router-id { description "Set Router-ID per instance explicitly."; } feature demand-circuit { description "OSPF demand circuit support as in RFC 1793."; reference "RFC 1793: OSPF Demand Circuits"; } feature mtu-ignore { description "Disable OSPF Database Description packet MTU mismatch checking specified in the OSPF protocol specification."; reference "RFC 2328: OSPF Version 2, section 10.6"; } feature lls { description "OSPF link-local signaling (LLS) as in RFC 5613."; reference "RFC 5613: OSPF Link-Local Signaling"; } Yeung, et al. Expires April 19, 2020 [Page 26] Internet-Draft OSPF YANG Data Model October 2019 feature prefix-suppression { description "OSPF prefix suppression support as in RFC 6860."; reference "RFC 6860: Hide Transit-Only Networks in OSPF"; } feature ttl-security { description "OSPF Time to Live (TTL) security check support."; reference "RFC 5082: The Generalized TTL Security Mechanism (GTSM)"; } feature nsr { description "Non-Stop-Routing (NSR) support. The OSPF NSR feature allows a router with redundant control-plane capability (e.g., dual Route-Processor (RP) cards) to maintain its state and adjacencies during planned and unplanned OSPF instance restarts. It differs from graceful-restart or Non-Stop Forwarding (NSF) in that no protocol signaling or assistance from adjacent OSPF neighbors is required to recover control-plane state."; } feature graceful-restart { description "Graceful OSPF Restart as defined in RFC 3623 and RFC 5187."; reference "RFC 3623: Graceful OSPF Restart RFC 5187: OSPFv3 Graceful Restart"; } feature auto-cost { description "Calculate OSPF interface cost according to reference bandwidth."; reference "RFC 2328: OSPF Version 2"; } feature max-ecmp { description "Setting maximum number of ECMP paths."; } feature max-lsa { description "Setting the maximum number of LSAs the OSPF instance Yeung, et al. Expires April 19, 2020 [Page 27] Internet-Draft OSPF YANG Data Model October 2019 will accept."; reference "RFC 1765: OSPF Database Overload"; } feature te-rid { description "Support configuration of the Traffic Engineering (TE) Router-ID, i.e., the Router Address described in Section 2.4.1 of RFC3630 or the Router IPv6 Address TLV described in Section 3 of RFC5329."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5329: Traffic Engineering (TE) Extensions to OSPF Version 3"; } feature ldp-igp-sync { description "LDP IGP synchronization."; reference "RFC 5443: LDP IGP Synchronization"; } feature ospfv2-authentication-trailer { description "Support OSPFv2 authentication trailer for OSPFv2 authentication."; reference "RFC 5709: Supporting Authentication Trailer for OSPFv2 RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management"; } feature ospfv3-authentication-ipsec { description "Support IPsec for OSPFv3 authentication."; reference "RFC 4552: Authentication/Confidentiality for OSPFv3"; } feature ospfv3-authentication-trailer { description "Support OSPFv3 authentication trailer for OSPFv3 authentication."; reference "RFC 7166: Supporting Authentication Trailer for OSPFv3"; } feature fast-reroute { Yeung, et al. Expires April 19, 2020 [Page 28] Internet-Draft OSPF YANG Data Model October 2019 description "Support for IP Fast Reroute (IP-FRR)."; reference "RFC 5714: IP Fast Reroute Framework"; } feature key-chain { description "Support of keychain for authentication."; reference "RFC8177: YANG Data Model for Key Chains"; } feature node-flag { description "Support for node-flag for OSPF prefixes."; reference "RFC 7684: OSPFv2 Prefix/Link Advertisement"; } feature node-tag { description "Support for node admin tag for OSPF routing instances."; reference "RFC 7777: Advertising Node Administrative Tags in OSPF"; } feature lfa { description "Support for Loop-Free Alternates (LFAs)."; reference "RFC 5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates"; } feature remote-lfa { description "Support for Remote Loop-Free Alternates (R-LFA)."; reference "RFC 7490: Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)"; } feature stub-router { description "Support for RFC 6987 OSPF Stub Router Advertisement."; reference "RFC 6987: OSPF Stub Router Advertisement"; } feature pe-ce-protocol { description "Support for OSPF as a PE-CE protocol"; reference "RFC 4577: OSPF as the Provider/Customer Edge Yeung, et al. Expires April 19, 2020 [Page 29] Internet-Draft OSPF YANG Data Model October 2019 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol"; } feature ietf-spf-delay { description "Support for IETF SPF delay algorithm."; reference "RFC 8405: SPF Back-off algorithm for link state IGPs"; } feature bfd { description "Support for BFD detection of OSPF neighbor reachability."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD) RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"; } feature hybrid-interface { description "Support for OSPF Hybrid interface type."; reference "RFC 6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type"; } identity ospf { base "rt:routing-protocol"; description "Any OSPF protocol version"; } identity ospfv2 { base "ospf"; description "OSPFv2 protocol"; } identity ospfv3 { base "ospf"; description "OSPFv3 protocol"; } identity area-type { description "Base identity for OSPF area type."; } identity normal-area { Yeung, et al. Expires April 19, 2020 [Page 30] Internet-Draft OSPF YANG Data Model October 2019 base area-type; description "OSPF normal area."; } identity stub-nssa-area { base area-type; description "OSPF stub or NSSA area."; } identity stub-area { base stub-nssa-area; description "OSPF stub area."; } identity nssa-area { base stub-nssa-area; description "OSPF Not-So-Stubby Area (NSSA)."; reference "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option"; } identity ospf-lsa-type { description "Base identity for OSPFv2 and OSPFv3 Link State Advertisement (LSA) types"; } identity ospfv2-lsa-type { base ospf-lsa-type; description "OSPFv2 LSA types"; } identity ospfv2-router-lsa { base ospfv2-lsa-type; description "OSPFv2 Router LSA - Type 1"; } identity ospfv2-network-lsa { base ospfv2-lsa-type; description "OSPFv2 Network LSA - Type 2"; } identity ospfv2-summary-lsa-type { base ospfv2-lsa-type; description Yeung, et al. Expires April 19, 2020 [Page 31] Internet-Draft OSPF YANG Data Model October 2019 "OSPFv2 Summary LSA types"; } identity ospfv2-network-summary-lsa { base ospfv2-summary-lsa-type; description "OSPFv2 Network Summary LSA - Type 3"; } identity ospfv2-asbr-summary-lsa { base ospfv2-summary-lsa-type; description "OSPFv2 AS Boundary Router (ASBR) Summary LSA - Type 4"; } identity ospfv2-external-lsa-type { base ospfv2-lsa-type; description "OSPFv2 External LSA types"; } identity ospfv2-as-external-lsa { base ospfv2-external-lsa-type; description "OSPFv2 AS External LSA - Type 5"; } identity ospfv2-nssa-lsa { base ospfv2-external-lsa-type; description "OSPFv2 Not-So-Stubby-Area (NSSA) LSA - Type 7"; } identity ospfv2-opaque-lsa-type { base ospfv2-lsa-type; description "OSPFv2 Opaque LSA types"; } identity ospfv2-link-scope-opaque-lsa { base ospfv2-opaque-lsa-type; description "OSPFv2 Link-Scoped Opaque LSA - Type 9"; } identity ospfv2-area-scope-opaque-lsa { base ospfv2-opaque-lsa-type; description Yeung, et al. Expires April 19, 2020 [Page 32] Internet-Draft OSPF YANG Data Model October 2019 "OSPFv2 Area-Scoped Opaque LSA - Type 10"; } identity ospfv2-as-scope-opaque-lsa { base ospfv2-opaque-lsa-type; description "OSPFv2 AS-Scoped Opaque LSA - Type 11"; } identity ospfv2-unknown-lsa-type { base ospfv2-lsa-type; description "OSPFv2 Unknown LSA type"; } identity ospfv3-lsa-type { base ospf-lsa-type; description "OSPFv3 LSA types."; } identity ospfv3-router-lsa { base ospfv3-lsa-type; description "OSPFv3 Router LSA - Type 0x2001"; } identity ospfv3-network-lsa { base ospfv3-lsa-type; description "OSPFv3 Network LSA - Type 0x2002"; } identity ospfv3-summary-lsa-type { base ospfv3-lsa-type; description "OSPFv3 Summary LSA types"; } identity ospfv3-inter-area-prefix-lsa { base ospfv3-summary-lsa-type; description "OSPFv3 Inter-area Prefix LSA - Type 0x2003"; } identity ospfv3-inter-area-router-lsa { base ospfv3-summary-lsa-type; description Yeung, et al. Expires April 19, 2020 [Page 33] Internet-Draft OSPF YANG Data Model October 2019 "OSPFv3 Inter-area Router LSA - Type 0x2004"; } identity ospfv3-external-lsa-type { base ospfv3-lsa-type; description "OSPFv3 External LSA types"; } identity ospfv3-as-external-lsa { base ospfv3-external-lsa-type; description "OSPFv3 AS-External LSA - Type 0x4005"; } identity ospfv3-nssa-lsa { base ospfv3-external-lsa-type; description "OSPFv3 Not-So-Stubby-Area (NSSA) LSA - Type 0x2007"; } identity ospfv3-link-lsa { base ospfv3-lsa-type; description "OSPFv3 Link LSA - Type 0x0008"; } identity ospfv3-intra-area-prefix-lsa { base ospfv3-lsa-type; description "OSPFv3 Intra-area Prefix LSA - Type 0x2009"; } identity ospfv3-router-information-lsa { base ospfv3-lsa-type; description "OSPFv3 Router Information LSA - Types 0x800C, 0xA00C, and 0xC00C"; } identity ospfv3-unknown-lsa-type { base ospfv3-lsa-type; description "OSPFv3 Unknown LSA type"; } identity lsa-log-reason { description Yeung, et al. Expires April 19, 2020 [Page 34] Internet-Draft OSPF YANG Data Model October 2019 "Base identity for an LSA log reason."; } identity lsa-refresh { base lsa-log-reason; description "Identity used when the LSA is logged as a result of receiving a refresh LSA."; } identity lsa-content-change { base lsa-log-reason; description "Identity used when the LSA is logged as a result of a change in the content of the LSA."; } identity lsa-purge { base lsa-log-reason; description "Identity used when the LSA is logged as a result of being purged."; } identity informational-capability { description "Base identity for router informational capabilities."; } identity graceful-restart { base informational-capability; description "When set, the router is capable of restarting gracefully."; reference "RFC 3623: Graceful OSPF Restart RFC 5187: OSPFv3 Graceful Restart"; } identity graceful-restart-helper { base informational-capability; description "When set, the router is capable of acting as a graceful restart helper."; reference "RFC 3623: Graceful OSPF Restart RFC 5187: OSPFv3 Graceful Restart"; } Yeung, et al. Expires April 19, 2020 [Page 35] Internet-Draft OSPF YANG Data Model October 2019 identity stub-router { base informational-capability; description "When set, the router is capable of acting as an OSPF Stub Router."; reference "RFC 6987: OSPF Stub Router Advertisement"; } identity traffic-engineering { base informational-capability; description "When set, the router is capable of OSPF traffic engineering."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5329: Traffic Engineering (TE) Extensions to OSPF Version 3"; } identity p2p-over-lan { base informational-capability; description "When set, the router is capable of OSPF Point-to-Point over LAN."; reference "RFC 5309: Point-to-Point Operation over LAN in Link State Routing Protocols"; } identity experimental-te { base informational-capability; description "When set, the router is capable of OSPF experimental traffic engineering."; reference "RFC 4973: OSPF-xTE OSPF Experimental Traffic Engineering"; } identity router-lsa-bit { description "Base identity for Router-LSA bits."; } identity vlink-end-bit { base router-lsa-bit; description "V bit, when set, the router is an endpoint of one or more virtual links."; Yeung, et al. Expires April 19, 2020 [Page 36] Internet-Draft OSPF YANG Data Model October 2019 } identity asbr-bit { base router-lsa-bit; description "E bit, when set, the router is an AS Boundary Router (ASBR)."; } identity abr-bit { base router-lsa-bit; description "B bit, when set, the router is an Area Border Router (ABR)."; } identity nssa-bit { base router-lsa-bit; description "Nt bit, when set, the router is an NSSA border router that is unconditionally translating NSSA LSAs into AS-external LSAs."; } identity ospfv3-lsa-option { description "Base identity for OSPF LSA options flags."; } identity af-bit { base ospfv3-lsa-option; description "AF bit, when set, the router supports OSPFv3 Address Families as in RFC5838."; } identity dc-bit { base ospfv3-lsa-option; description "DC bit, when set, the router supports demand circuits."; } identity r-bit { base ospfv3-lsa-option; description "R bit, when set, the originator is an active router."; } Yeung, et al. Expires April 19, 2020 [Page 37] Internet-Draft OSPF YANG Data Model October 2019 identity n-bit { base ospfv3-lsa-option; description "N bit, when set, the router is attached to an NSSA"; } identity e-bit { base ospfv3-lsa-option; description "E bit, this bit describes the way AS-external LSAs are flooded"; } identity v6-bit { base ospfv3-lsa-option; description "V6 bit, if clear, the router/link should be excluded from IPv6 routing calculation"; } identity ospfv3-prefix-option { description "Base identity for OSPFv3 Prefix Options."; } identity nu-bit { base ospfv3-prefix-option; description "NU Bit, when set, the prefix should be excluded from IPv6 unicast calculations."; } identity la-bit { base ospfv3-prefix-option; description "LA bit, when set, the prefix is actually an IPv6 interface address of the Advertising Router."; } identity p-bit { base ospfv3-prefix-option; description "P bit, when set, the NSSA area prefix should be translated to an AS External LSA and advertised by the translating NSSA Border Router."; } identity dn-bit { Yeung, et al. Expires April 19, 2020 [Page 38] Internet-Draft OSPF YANG Data Model October 2019 base ospfv3-prefix-option; description "DN bit, when set, the inter-area-prefix LSA or AS-external LSA prefix has been advertised as an L3VPN prefix."; } identity ospfv2-lsa-option { description "Base identity for OSPFv2 LSA option flags."; } identity mt-bit { base ospfv2-lsa-option; description "MT bit, When set, the router supports multi-topology as in RFC 4915."; } identity v2-dc-bit { base ospfv2-lsa-option; description "DC bit, When set, the router supports demand circuits."; } identity v2-p-bit { base ospfv2-lsa-option; description "P bit, wnly used in type-7 LSA. When set, an NSSA border router should translate the type-7 LSA to a type-5 LSA."; } identity mc-flag { base ospfv2-lsa-option; description "MC Bit, when set, the router supports MOSPF."; } identity v2-e-flag { base ospfv2-lsa-option; description "E Bit, this bit describes the way AS-external LSAs are flooded."; } identity o-bit { base ospfv2-lsa-option; Yeung, et al. Expires April 19, 2020 [Page 39] Internet-Draft OSPF YANG Data Model October 2019 description "O bit, when set, the router is opaque-capable as in RFC 5250."; } identity v2-dn-bit { base ospfv2-lsa-option; description "DN bit, when a type 3, 5 or 7 LSA is sent from a PE to a CE, the DN bit must be set. See RFC 4576."; } identity ospfv2-extended-prefix-flag { description "Base identity for extended prefix TLV flag."; } identity a-flag { base ospfv2-extended-prefix-flag; description "Attach flag, when set it indicates that the prefix corresponds and a route what is directly connected to the advertising router.."; } identity node-flag { base ospfv2-extended-prefix-flag; description "Node flag, when set, it indicates that the prefix is used to represent the advertising node, e.g., a loopback address."; } typedef ospf-metric { type uint32 { range "0 .. 16777215"; } description "OSPF Metric - 24-bit unsigned integer."; } typedef ospf-link-metric { type uint16 { range "0 .. 65535"; } description "OSPF Link Metric - 16-bit unsigned integer."; } Yeung, et al. Expires April 19, 2020 [Page 40] Internet-Draft OSPF YANG Data Model October 2019 typedef opaque-id { type uint32 { range "0 .. 16777215"; } description "Opaque ID - 24-bit unsigned integer."; } typedef area-id-type { type yang:dotted-quad; description "Area ID type."; } typedef route-type { type enumeration { enum intra-area { description "OSPF intra-area route."; } enum inter-area { description "OSPF inter-area route."; } enum external-1 { description "OSPF type 1 external route."; } enum external-2 { description "OSPF type 2 external route."; } enum nssa-1 { description "OSPF type 1 NSSA route."; } enum nssa-2 { description "OSPF type 2 NSSA route."; } } description "OSPF route type."; } typedef if-state-type { type enumeration { enum down { value "1"; description "Interface down state."; } enum loopback { value "2"; description Yeung, et al. Expires April 19, 2020 [Page 41] Internet-Draft OSPF YANG Data Model October 2019 "Interface loopback state."; } enum waiting { value "3"; description "Interface waiting state."; } enum point-to-point { value "4"; description "Interface point-to-point state."; } enum dr { value "5"; description "Interface Designated Router (DR) state."; } enum bdr { value "6"; description "Interface Backup Designated Router (BDR) state."; } enum dr-other { value "7"; description "Interface Other Designated Router state."; } } description "OSPF interface state type."; } typedef router-link-type { type enumeration { enum point-to-point-link { value "1"; description "Point-to-Point link to Router"; } enum transit-network-link { value "2"; description "Link to transit network identified by Designated-Router (DR)"; } enum stub-network-link { value "3"; description Yeung, et al. Expires April 19, 2020 [Page 42] Internet-Draft OSPF YANG Data Model October 2019 "Link to stub network identified by subnet"; } enum virtual-link { value "4"; description "Virtual link across transit area"; } } description "OSPF Router Link Type."; } typedef nbr-state-type { type enumeration { enum down { value "1"; description "Neighbor down state."; } enum attempt { value "2"; description "Neighbor attempt state."; } enum init { value "3"; description "Neighbor init state."; } enum 2-way { value "4"; description "Neighbor 2-Way state."; } enum exstart { value "5"; description "Neighbor exchange start state."; } enum exchange { value "6"; description "Neighbor exchange state."; } enum loading { value "7"; description "Neighbor loading state."; Yeung, et al. Expires April 19, 2020 [Page 43] Internet-Draft OSPF YANG Data Model October 2019 } enum full { value "8"; description "Neighbor full state."; } } description "OSPF neighbor state type."; } typedef restart-helper-status-type { type enumeration { enum not-helping { value "1"; description "Restart helper status not helping."; } enum helping { value "2"; description "Restart helper status helping."; } } description "Restart helper status type."; } typedef restart-exit-reason-type { type enumeration { enum none { value "1"; description "Restart not attempted."; } enum in-progress { value "2"; description "Restart in progress."; } enum completed { value "3"; description "Restart successfully completed."; } enum timed-out { value "4"; description Yeung, et al. Expires April 19, 2020 [Page 44] Internet-Draft OSPF YANG Data Model October 2019 "Restart timed out."; } enum topology-changed { value "5"; description "Restart aborted due to topology change."; } } description "Describes the outcome of the last attempt at a graceful restart, either by itself or acting as a helper."; } typedef packet-type { type enumeration { enum hello { value "1"; description "OSPF Hello packet."; } enum database-description { value "2"; description "OSPF Database Description packet."; } enum link-state-request { value "3"; description "OSPF Link State Request packet."; } enum link-state-update { value "4"; description "OSPF Link State Update packet."; } enum link-state-ack { value "5"; description "OSPF Link State Acknowledgement packet."; } } description "OSPF packet type."; } typedef nssa-translator-state-type { type enumeration { Yeung, et al. Expires April 19, 2020 [Page 45] Internet-Draft OSPF YANG Data Model October 2019 enum enabled { value "1"; description "NSSA translator enabled state."; } enum elected { value "2"; description "NSSA translator elected state."; } enum disabled { value "3"; description "NSSA translator disabled state."; } } description "OSPF NSSA translator state type."; } typedef restart-status-type { type enumeration { enum not-restarting { value "1"; description "Router is not restarting."; } enum planned-restart { value "2"; description "Router is going through planned restart."; } enum unplanned-restart { value "3"; description "Router is going through unplanned restart."; } } description "OSPF graceful restart status type."; } typedef fletcher-checksum16-type { type string { pattern '(0x)?[0-9a-fA-F]{4}'; } description "Fletcher 16-bit checksum in hex-string format 0xXXXX."; Yeung, et al. Expires April 19, 2020 [Page 46] Internet-Draft OSPF YANG Data Model October 2019 reference "RFC 905: ISO Transport Protocol specification ISO DP 8073"; } typedef ospfv2-auth-trailer-rfc-version { type enumeration { enum rfc5709 { description "Support OSPF Authentication Trailer as described in RFC 5709"; reference "RFC 5709: OSPFv2 HMAC-SHA Cryptographic Authentication"; } enum rfc7474 { description "Support OSPF Authentication Trailer as described in RFC 7474"; reference "RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management Authentication"; } } description "OSPFv2 Authentication Trailer Support"; } grouping tlv { description "Type-Length-Value (TLV)"; leaf type { type uint16; description "TLV type."; } leaf length { type uint16; description "TLV length (octets)."; } leaf value { type yang:hex-string; description "TLV value."; } } grouping unknown-tlvs { description "Unknown TLVs grouping - Used for unknown TLVs or Yeung, et al. Expires April 19, 2020 [Page 47] Internet-Draft OSPF YANG Data Model October 2019 unknown sub-TLVs."; container unknown-tlvs { description "All unknown TLVs."; list unknown-tlv { description "Unknown TLV."; uses tlv; } } } grouping node-tag-tlv { description "OSPF Node Admin Tag TLV grouping."; list node-tag { leaf tag { type uint32; description "Node admin tag value."; } description "List of tags."; } } grouping router-capabilities-tlv { description "OSPF Router Capabilities TLV grouping."; reference "RFC 7770: OSPF Router Capabilities"; container router-informational-capabilities { leaf-list informational-capabilities { type identityref { base informational-capability; } description "Informational capability list. This list will contains the identities for the informational capabilities supported by router."; } description "OSPF Router Informational Flag Definitions."; } list informational-capabilities-flags { leaf informational-flag { type uint32; description "Individual informational capability flag."; } description "List of informational capability flags. This will return all the 32-bit informational flags irrespective Yeung, et al. Expires April 19, 2020 [Page 48] Internet-Draft OSPF YANG Data Model October 2019 of whether or not they are known to the device."; } list functional-capabilities { leaf functional-flag { type uint32; description "Individual functional capability flag."; } description "List of functional capability flags. This will return all the 32-bit functional flags irrespective of whether or not they are known to the device."; } } grouping dynamic-hostname-tlv { description "Dynamic Hostname TLV"; reference "RFC 5642: Dynamic Hostnames for OSPF"; leaf hostname { type string { length "1..255"; } description "Dynamic Hostname"; } } grouping sbfd-discriminator-tlv { description "Seamless BFD Discriminator TLV"; reference "RFC 7884: S-BFD Discriminators in OSPF"; list sbfd-discriminators { leaf sbfd-discriminator { type uint32; description "Individual S-BFD Discriminator."; } description "List of S-BFD Discriminators"; } } grouping maximum-sid-depth-tlv { description "Maximum SID Depth (MSD) TLV"; reference "RFC 8476: Signaling Maximum Segment Depth (MSD) using OSPF"; list msd-type { leaf msd-type { type uint8; description "Maximum Segment Depth (MSD) type"; Yeung, et al. Expires April 19, 2020 [Page 49] Internet-Draft OSPF YANG Data Model October 2019 } leaf msd-value { type uint8; description "Maximum Segment Depth (MSD) value for the type"; } description "List of Maximum Segment Depth (MSD) tuples"; } } grouping ospf-router-lsa-bits { container router-bits { leaf-list rtr-lsa-bits { type identityref { base router-lsa-bit; } description "Router LSA bits list. This list will contain identities for the bits which are set in the Router-LSA bits."; } description "Router LSA Bits."; } description "Router LSA Bits - Currently common for OSPFv2 and OSPFv3 but it may diverge with future augmentations."; } grouping ospfv2-router-link { description "OSPFv2 router link."; leaf link-id { type union { type inet:ipv4-address; type yang:dotted-quad; } description "Router-LSA Link ID"; } leaf link-data { type union { type inet:ipv4-address; type uint32; } description "Router-LSA Link data."; } leaf type { type router-link-type; description "Router-LSA Link type."; Yeung, et al. Expires April 19, 2020 [Page 50] Internet-Draft OSPF YANG Data Model October 2019 } } grouping ospfv2-lsa-body { description "OSPFv2 LSA body."; container router { when "derived-from-or-self(../../header/type, " + "'ospfv2-router-lsa')" { description "Only applies to Router-LSAs."; } description "Router LSA."; uses ospf-router-lsa-bits; leaf num-of-links { type uint16; description "Number of links in Router LSA."; } container links { description "All router Links."; list link { description "Router LSA link."; uses ospfv2-router-link; container topologies { description "All topologies for the link."; list topology { description "Topology specific information."; leaf mt-id { type uint8; description "The MT-ID for the topology enabled on the link."; } leaf metric { type uint16; description "Metric for the topology."; } } } } } } container network { when "derived-from-or-self(../../header/type, " + "'ospfv2-network-lsa')" { description "Only applies to Network LSAs."; Yeung, et al. Expires April 19, 2020 [Page 51] Internet-Draft OSPF YANG Data Model October 2019 } description "Network LSA."; leaf network-mask { type yang:dotted-quad; description "The IP address mask for the network."; } container attached-routers { description "All attached routers."; leaf-list attached-router { type inet:ipv4-address; description "List of the routers attached to the network."; } } } container summary { when "derived-from(../../header/type, " + "'ospfv2-summary-lsa-type')" { description "Only applies to Summary LSAs."; } description "Summary LSA."; leaf network-mask { type inet:ipv4-address; description "The IP address mask for the network"; } container topologies { description "All topologies for the summary LSA."; list topology { description "Topology specific information."; leaf mt-id { type uint8; description "The MT-ID for the topology enabled for the summary."; } leaf metric { type ospf-metric; description "Metric for the topology."; } } } } Yeung, et al. Expires April 19, 2020 [Page 52] Internet-Draft OSPF YANG Data Model October 2019 container external { when "derived-from(../../header/type, " + "'ospfv2-external-lsa-type')" { description "Only applies to AS-external LSAs and NSSA LSAs."; } description "External LSA."; leaf network-mask { type inet:ipv4-address; description "The IP address mask for the network"; } container topologies { description "All topologies for the external."; list topology { description "Topology specific information."; leaf mt-id { type uint8; description "The MT-ID for the topology enabled for the external or NSSA prefix."; } leaf flags { type bits { bit E { description "When set, the metric specified is a Type 2 external metric."; } } description "Flags."; } leaf metric { type ospf-metric; description "Metric for the topology."; } leaf forwarding-address { type inet:ipv4-address; description "Forwarding address."; } leaf external-route-tag { type uint32; description "Route tag for the topology."; } Yeung, et al. Expires April 19, 2020 [Page 53] Internet-Draft OSPF YANG Data Model October 2019 } } } container opaque { when "derived-from(../../header/type, " + "'ospfv2-opaque-lsa-type')" { description "Only applies to Opaque LSAs."; } description "Opaque LSA."; container ri-opaque { description "OSPF Router Information (RI) opaque LSA."; reference "RFC 7770: OSPF Router Capabilities"; container router-capabilities-tlv { description "Informational and functional router capabilities"; uses router-capabilities-tlv; } container node-tag-tlvs { description "All node tag TLVs."; list node-tag-tlv { description "Node tag TLV."; uses node-tag-tlv; } } container dynamic-hostname-tlv { description "OSPF Dynamic Hostname"; uses dynamic-hostname-tlv; } container sbfd-discriminator-tlv { description "OSPF S-BFD Discriminators"; uses sbfd-discriminator-tlv; } container maximum-sid-depth-tlv { description "OSPF Maximum SID Depth (MSD) values"; uses maximum-sid-depth-tlv; } uses unknown-tlvs; } Yeung, et al. Expires April 19, 2020 [Page 54] Internet-Draft OSPF YANG Data Model October 2019 container te-opaque { description "OSPFv2 Traffic Engineering (TE) opaque LSA."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPFv2"; container router-address-tlv { description "Router address TLV."; leaf router-address { type inet:ipv4-address; description "Router address."; } } container link-tlv { description "Describes a single link, and it is constructed of a set of Sub-TLVs."; leaf link-type { type router-link-type; mandatory true; description "Link type."; } leaf link-id { type union { type inet:ipv4-address; type yang:dotted-quad; } mandatory true; description "Link ID."; } container local-if-ipv4-addrs { description "All local interface IPv4 addresses."; leaf-list local-if-ipv4-addr { type inet:ipv4-address; description "List of local interface IPv4 addresses."; } } container remote-if-ipv4-addrs { description "All remote interface IPv4 addresses."; leaf-list remote-if-ipv4-addr { type inet:ipv4-address; description "List of remote interface IPv4 addresses."; } } leaf te-metric { Yeung, et al. Expires April 19, 2020 [Page 55] Internet-Draft OSPF YANG Data Model October 2019 type uint32; description "TE metric."; } leaf max-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum bandwidth."; } leaf max-reservable-bandwidth { type rt-types:bandwidth-ieee-float32; description "Maximum reservable bandwidth."; } container unreserved-bandwidths { description "All unreserved bandwidths."; list unreserved-bandwidth { leaf priority { type uint8 { range "0 .. 7"; } description "Priority from 0 to 7."; } leaf unreserved-bandwidth { type rt-types:bandwidth-ieee-float32; description "Unreserved bandwidth."; } description "List of unreserved bandwidths for different priorities."; } } leaf admin-group { type uint32; description "Administrative group/Resource Class/Color."; } uses unknown-tlvs; } } container extended-prefix-opaque { description "All extended prefix TLVs in the LSA."; list extended-prefix-tlv { description "Extended prefix TLV."; leaf route-type { type enumeration { enum unspecified { value "0"; description "Unspecified."; } Yeung, et al. Expires April 19, 2020 [Page 56] Internet-Draft OSPF YANG Data Model October 2019 enum intra-area { value "1"; description "OSPF intra-area route."; } enum inter-area { value "3"; description "OSPF inter-area route."; } enum external { value "5"; description "OSPF External route."; } enum nssa { value "7"; description "OSPF NSSA external route."; } } description "Route type."; } container flags { leaf-list extended-prefix-flags { type identityref { base ospfv2-extended-prefix-flag; } description "Extended prefix TLV flags list. This list will contain identities for the prefix flags that are set in the extended prefix flags."; } description "Prefix Flags."; } leaf prefix { type inet:ip-prefix; description "Address prefix."; } uses unknown-tlvs; } } container extended-link-opaque { description "All extended link TLVs in the LSA."; container extended-link-tlv { description "Extended link TLV."; uses ospfv2-router-link; container maximum-sid-depth-tlv { description "OSPF Maximum SID Depth (MSD) values"; uses maximum-sid-depth-tlv; } Yeung, et al. Expires April 19, 2020 [Page 57] Internet-Draft OSPF YANG Data Model October 2019 uses unknown-tlvs; } } } } grouping ospfv3-lsa-options { description "OSPFv3 LSA options"; container lsa-options { leaf-list lsa-options { type identityref { base ospfv3-lsa-option; } description "OSPFv3 LSA Option flags list. This list will contain the identities for the OSPFv3 LSA options that are set for the LSA."; } description "OSPFv3 LSA options."; } } grouping ospfv3-lsa-prefix { description "OSPFv3 LSA prefix."; leaf prefix { type inet:ip-prefix; description "LSA Prefix."; } container prefix-options { leaf-list prefix-options { type identityref { base ospfv3-prefix-option; } description "OSPFv3 prefix option flag list. This list will contain the identities for the OSPFv3 options that are set for the OSPFv3 prefix."; } description "Prefix options."; } } grouping ospfv3-lsa-external { description "AS-External and NSSA LSA."; Yeung, et al. Expires April 19, 2020 [Page 58] Internet-Draft OSPF YANG Data Model October 2019 leaf metric { type ospf-metric; description "Metric"; } leaf flags { type bits { bit E { description "When set, the metric specified is a Type 2 external metric."; } bit F { description "When set, a Forwarding Address is included in the LSA."; } bit T { description "When set, an External Route Tag is included in the LSA."; } } description "Flags."; } leaf referenced-ls-type { type identityref { base ospfv3-lsa-type; } description "Referenced Link State type."; } leaf unknown-referenced-ls-type { type uint16; description "Value for an unknown Referenced Link State type."; } uses ospfv3-lsa-prefix; leaf forwarding-address { type inet:ipv6-address; description "Forwarding address."; } leaf external-route-tag { type uint32; description Yeung, et al. Expires April 19, 2020 [Page 59] Internet-Draft OSPF YANG Data Model October 2019 "Route tag."; } leaf referenced-link-state-id { type uint32; description "Referenced Link State ID."; } } grouping ospfv3-lsa-body { description "OSPFv3 LSA body."; container router { when "derived-from-or-self(../../header/type, " + "'ospfv3-router-lsa')" { description "Only applies to Router LSAs."; } description "Router LSA."; uses ospf-router-lsa-bits; uses ospfv3-lsa-options; container links { description "All router link."; list link { description "Router LSA link."; leaf interface-id { type uint32; description "Interface ID for link."; } leaf neighbor-interface-id { type uint32; description "Neighbor's Interface ID for link."; } leaf neighbor-router-id { type rt-types:router-id; description "Neighbor's Router ID for link."; } leaf type { type router-link-type; description "Link type: 1 - Point-to-Point Link 2 - Transit Network Link 3 - Stub Network Link 4 - Virtual Link"; } leaf metric { type uint16; description "Link Metric."; } Yeung, et al. Expires April 19, 2020 [Page 60] Internet-Draft OSPF YANG Data Model October 2019 } } } container network { when "derived-from-or-self(../../header/type, " + "'ospfv3-network-lsa')" { description "Only applies to Network LSAs."; } description "Network LSA."; uses ospfv3-lsa-options; container attached-routers { description "All attached routers."; leaf-list attached-router { type rt-types:router-id; description "List of the routers attached to the network."; } } } container inter-area-prefix { when "derived-from-or-self(../../header/type, " + "'ospfv3-inter-area-prefix-lsa')" { description "Only applies to Inter-Area-Prefix LSAs."; } leaf metric { type ospf-metric; description "Inter-Area Prefix Metric"; } uses ospfv3-lsa-prefix; description "Prefix LSA."; } container inter-area-router { when "derived-from-or-self(../../header/type, " + "'ospfv3-inter-area-router-lsa')" { description "Only applies to Inter-Area-Router LSAs."; } uses ospfv3-lsa-options; leaf metric { type ospf-metric; description "AS Boundary Router (ASBR) Metric."; } leaf destination-router-id { type rt-types:router-id; Yeung, et al. Expires April 19, 2020 [Page 61] Internet-Draft OSPF YANG Data Model October 2019 description "The Router ID of the ASBR described by the LSA."; } description "Inter-Area-Router LSA."; } container as-external { when "derived-from-or-self(../../header/type, " + "'ospfv3-as-external-lsa')" { description "Only applies to AS-external LSAs."; } uses ospfv3-lsa-external; description "AS-External LSA."; } container nssa { when "derived-from-or-self(../../header/type, " + "'ospfv3-nssa-lsa')" { description "Only applies to NSSA LSAs."; } uses ospfv3-lsa-external; description "NSSA LSA."; } container link { when "derived-from-or-self(../../header/type, " + "'ospfv3-link-lsa')" { description "Only applies to Link LSAs."; } leaf rtr-priority { type uint8; description "Router priority for DR election. A router with a higher priority will be preferred in the election and a value of 0 indicates the router is not eligible to become Designated Router or Backup Designated Router (BDR)."; } uses ospfv3-lsa-options; leaf link-local-interface-address { type inet:ipv6-address; description "The originating router's link-local interface address for the link."; Yeung, et al. Expires April 19, 2020 [Page 62] Internet-Draft OSPF YANG Data Model October 2019 } leaf num-of-prefixes { type uint32; description "Number of prefixes."; } container prefixes { description "All prefixes for the link."; list prefix { description "List of prefixes associated with the link."; uses ospfv3-lsa-prefix; } } description "Link LSA."; } container intra-area-prefix { when "derived-from-or-self(../../header/type, " + "'ospfv3-intra-area-prefix-lsa')" { description "Only applies to Intra-Area-Prefix LSAs."; } description "Intra-Area-Prefix LSA."; leaf referenced-ls-type { type identityref { base ospfv3-lsa-type; } description "Referenced Link State type."; } leaf unknown-referenced-ls-type { type uint16; description "Value for an unknown Referenced Link State type."; } leaf referenced-link-state-id { type uint32; description "Referenced Link State ID."; } leaf referenced-adv-router { type rt-types:router-id; description "Referenced Advertising Router."; } leaf num-of-prefixes { Yeung, et al. Expires April 19, 2020 [Page 63] Internet-Draft OSPF YANG Data Model October 2019 type uint16; description "Number of prefixes."; } container prefixes { description "All prefixes in this LSA."; list prefix { description "List of prefixes in this LSA."; uses ospfv3-lsa-prefix; leaf metric { type ospf-metric; description "Prefix Metric."; } } } } container router-information { when "derived-from-or-self(../../header/type, " + "'ospfv3-router-information-lsa')" { description "Only applies to Router Information LSAs (RFC7770)."; } container router-capabilities-tlv { description "Informational and functional router capabilities"; uses router-capabilities-tlv; } container node-tag-tlvs { description "All node tag tlvs."; list node-tag-tlv { description "Node tag tlv."; uses node-tag-tlv; } } container dynamic-hostname-tlv { description "OSPF Dynamic Hostname"; uses dynamic-hostname-tlv; } container sbfd-discriminator-tlv { description "OSPF S-BFD Discriminators"; uses sbfd-discriminator-tlv; } description "Router Information LSA."; reference "RFC 7770: Extensions for Advertising Router Capabilities"; } } Yeung, et al. Expires April 19, 2020 [Page 64] Internet-Draft OSPF YANG Data Model October 2019 grouping lsa-header { description "Common LSA for OSPFv2 and OSPFv3"; leaf age { type uint16; mandatory true; description "LSA age."; } leaf type { type identityref { base ospf-lsa-type; } mandatory true; description "LSA type"; } leaf adv-router { type rt-types:router-id; mandatory true; description "LSA advertising router."; } leaf seq-num { type uint32; mandatory true; description "LSA sequence number."; } leaf checksum { type fletcher-checksum16-type; mandatory true; description "LSA checksum."; } leaf length { type uint16; mandatory true; description "LSA length including the header."; } } grouping ospfv2-lsa { description "OSPFv2 LSA - LSAs are uniquely identified by the tuple with the sequence number differentiating LSA instances."; container header { must "(derived-from(type, " + "'ospfv2-opaque-lsa-type') and " + "opaque-id and opaque-type) or " + "(not(derived-from(type, " Yeung, et al. Expires April 19, 2020 [Page 65] Internet-Draft OSPF YANG Data Model October 2019 + "'ospfv2-opaque-lsa-type')) " + "and not(opaque-id) and not(opaque-type))" { description "Opaque type and ID only apply to Opaque LSAs."; } description "Decoded OSPFv2 LSA header data."; container lsa-options { leaf-list lsa-options { type identityref { base ospfv2-lsa-option; } description "LSA option flags list. This list will contain the identities for the identities for the OSPFv2 LSA options that are set."; } description "LSA options."; } leaf lsa-id { type yang:dotted-quad; mandatory true; description "Link-State ID."; } leaf opaque-type { type uint8; description "Opaque type."; } leaf opaque-id { type opaque-id; description "Opaque ID."; } uses lsa-header; } container body { description "Decoded OSPFv2 LSA body data."; uses ospfv2-lsa-body; } } grouping ospfv3-lsa { Yeung, et al. Expires April 19, 2020 [Page 66] Internet-Draft OSPF YANG Data Model October 2019 description "Decoded OSPFv3 LSA."; container header { description "Decoded OSPFv3 LSA header data."; leaf lsa-id { type uint32; mandatory true; description "OSPFv3 LSA ID."; } uses lsa-header; } container body { description "Decoded OSPF LSA body data."; uses ospfv3-lsa-body; } } grouping lsa-common { description "Common fields for OSPF LSA representation."; leaf decode-completed { type boolean; description "The OSPF LSA body was successfully decoded other than unknown TLVs. Unknown LSAs types and OSPFv2 unknown opaque LSA types are not decoded. Additionally, malformed LSAs are generally not accepted and will not be in the Link State Database."; } leaf raw-data { type yang:hex-string; description "The complete LSA in network byte order hexadecimal as received or originated."; } } grouping lsa { description "OSPF LSA."; uses lsa-common; choice version { description "OSPFv2 or OSPFv3 LSA body."; container ospfv2 { description "OSPFv2 LSA"; uses ospfv2-lsa; Yeung, et al. Expires April 19, 2020 [Page 67] Internet-Draft OSPF YANG Data Model October 2019 } container ospfv3 { description "OSPFv3 LSA"; uses ospfv3-lsa; } } } grouping lsa-key { description "OSPF LSA key - the database key for each LSA of a given type in the Link State DataBase (LSDB)."; leaf lsa-id { type union { type yang:dotted-quad; type uint32; } description "Link-State ID."; } leaf adv-router { type rt-types:router-id; description "Advertising router."; } } grouping instance-stat { description "Per-instance statistics"; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF instance's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF instance was last re-initialized, then this node contains the time the OSPF instance was re-initialized which normally occurs when it was created."; } leaf originate-new-lsa-count { type yang:counter32; description "The number of new LSAs originated. Discontinuities in the value of this counter can occur when the OSPF instance is re-initialized."; } leaf rx-new-lsas-count { Yeung, et al. Expires April 19, 2020 [Page 68] Internet-Draft OSPF YANG Data Model October 2019 type yang:counter32; description "The number of new LSAs received. Discontinuities in the value of this counter can occur when the OSPF instance is re-initialized."; } leaf as-scope-lsa-count { type yang:gauge32; description "The number of AS-scope LSAs."; } leaf as-scope-lsa-chksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for AS-scope LSAs. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } container database { description "Container for per AS-scope LSA statistics."; list as-scope-lsa-type { description "List of AS-scope LSA statistics"; leaf lsa-type { type uint16; description "AS-Scope LSA type."; } leaf lsa-count { type yang:gauge32; description "The number of LSAs of the LSA type."; } leaf lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for the LSAs of this type. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } } } uses instance-fast-reroute-state; Yeung, et al. Expires April 19, 2020 [Page 69] Internet-Draft OSPF YANG Data Model October 2019 } grouping area-stat { description "Per-area statistics."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF area's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF area was last re-initialized, then this node contains the time the OSPF area was re-initialized which normally occurs when it was created."; } leaf spf-runs-count { type yang:counter32; description "The number of times the intra-area SPF has run. Discontinuities in the value of this counter can occur when the OSPF area is re-initialized."; } leaf abr-count { type yang:gauge32; description "The total number of Area Border Routers (ABRs) reachable within this area."; } leaf asbr-count { type yang:gauge32; description "The total number of AS Boundary Routers (ASBRs)."; } leaf ar-nssa-translator-event-count { type yang:counter32; description "The number of NSSA translator-state changes. Discontinuities in the value of this counter can occur when the OSPF area is re-initialized."; } leaf area-scope-lsa-count { type yang:gauge32; description "The number of area-scope LSAs in the area."; } leaf area-scope-lsa-cksum-sum { type uint32; description Yeung, et al. Expires April 19, 2020 [Page 70] Internet-Draft OSPF YANG Data Model October 2019 "The module 2**32 sum of the LSA checksums for area-scope LSAs. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } container database { description "Container for area-scope LSA type statistics."; list area-scope-lsa-type { description "List of area-scope LSA statistics"; leaf lsa-type { type uint16; description "Area-scope LSA type."; } leaf lsa-count { type yang:gauge32; description "The number of LSAs of the LSA type."; } leaf lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for the LSAs of this type. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } } } } grouping interface-stat { description "Per-interface statistics"; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF interface's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF interface was last re-initialized, then this node contains the time the OSPF interface was re-initialized which normally occurs when it was created."; Yeung, et al. Expires April 19, 2020 [Page 71] Internet-Draft OSPF YANG Data Model October 2019 } leaf if-event-count { type yang:counter32; description "The number of times this interface has changed its state or an error has occurred. Discontinuities in the value of this counter can occur when the OSPF interface is re-initialized."; } leaf link-scope-lsa-count { type yang:gauge32; description "The number of link-scope LSAs."; } leaf link-scope-lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for link-scope LSAs. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } container database { description "Container for link-scope LSA type statistics."; list link-scope-lsa-type { description "List of link-scope LSA statistics"; leaf lsa-type { type uint16; description "Link scope LSA type."; } leaf lsa-count { type yang:gauge32; description "The number of LSAs of the LSA type."; } leaf lsa-cksum-sum { type uint32; description "The module 2**32 sum of the LSA checksums for the LSAs of this type. The value should be treated as unsigned when comparing two sums of checksums. While differing checksums indicate a different combination of LSAs, equivalent checksums don't guarantee that the LSAs are the same given that multiple combinations of LSAs can result in the same checksum."; } Yeung, et al. Expires April 19, 2020 [Page 72] Internet-Draft OSPF YANG Data Model October 2019 } } } grouping neighbor-stat { description "Per-neighbor statistics."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of this OSPF neighbor's counters suffered a discontinuity. If no such discontinuities have occurred since the OSPF neighbor was last re-initialized, then this node contains the time the OSPF neighbor was re-initialized which normally occurs when the neighbor is dynamically discovered andcreated."; } leaf nbr-event-count { type yang:counter32; description "The number of times this neighbor has changed state or an error has occurred. Discontinuities in the value of this counter can occur when the OSPF neighbor is re-initialized."; } leaf nbr-retrans-qlen { type yang:gauge32; description "The current length of the retransmission queue."; } } grouping instance-fast-reroute-config { description "This group defines global configuration of IP Fast ReRoute (FRR)."; container fast-reroute { if-feature fast-reroute; description "This container may be augmented with global parameters for IP-FRR."; container lfa { if-feature lfa; description "This container may be augmented with global parameters for Loop-Free Alternatives (LFA). Container creation has no effect on LFA activation."; } Yeung, et al. Expires April 19, 2020 [Page 73] Internet-Draft OSPF YANG Data Model October 2019 } } grouping instance-fast-reroute-state { description "IP-FRR state data grouping"; container protected-routes { if-feature fast-reroute; config false; description "Instance protection statistics"; list address-family-stats { key "address-family prefix alternate"; description "Per Address Family protected prefix information"; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf prefix { type inet:ip-prefix; description "Protected prefix."; } leaf alternate { type inet:ip-address; description "Alternate next hop for the prefix."; } leaf alternate-type { type enumeration { enum equal-cost { description "ECMP alternate."; } enum lfa { description "LFA alternate."; } enum remote-lfa { description "Remote LFA alternate."; } enum tunnel { description "Tunnel based alternate Yeung, et al. Expires April 19, 2020 [Page 74] Internet-Draft OSPF YANG Data Model October 2019 (like RSVP-TE or GRE)."; } enum ti-lfa { description "TI-LFA alternate."; } enum mrt { description "MRT alternate."; } enum other { description "Unknown alternate type."; } } description "Type of alternate."; } leaf best { type boolean; description "Indicates that this alternate is preferred."; } leaf non-best-reason { type string { length "1..255"; } description "Information field to describe why the alternate is not best."; } leaf protection-available { type bits { bit node-protect { position 0; description "Node protection available."; } bit link-protect { position 1; description "Link protection available."; } bit srlg-protect { position 2; description "SRLG protection available."; } Yeung, et al. Expires April 19, 2020 [Page 75] Internet-Draft OSPF YANG Data Model October 2019 bit downstream-protect { position 3; description "Downstream protection available."; } bit other { position 4; description "Other protection available."; } } description "Protection provided by the alternate."; } leaf alternate-metric1 { type uint32; description "Metric from Point of Local Repair (PLR) to destination through the alternate path."; } leaf alternate-metric2 { type uint32; description "Metric from PLR to the alternate node"; } leaf alternate-metric3 { type uint32; description "Metric from alternate node to the destination"; } } } container unprotected-routes { if-feature fast-reroute; config false; description "List of prefixes that are not protected"; list address-family-stats { key "address-family prefix"; description "Per Address Family (AF) unprotected prefix statistics."; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf prefix { type inet:ip-prefix; Yeung, et al. Expires April 19, 2020 [Page 76] Internet-Draft OSPF YANG Data Model October 2019 description "Unprotected prefix."; } } } list protection-statistics { key frr-protection-method; config false; description "List protection method statistics"; leaf frr-protection-method { type string; description "Protection method used."; } list address-family-stats { key address-family; description "Per Address Family protection statistics."; leaf address-family { type iana-rt-types:address-family; description "Address-family"; } leaf total-routes { type uint32; description "Total prefixes."; } leaf unprotected-routes { type uint32; description "Total prefixes that are not protected."; } leaf protected-routes { type uint32; description "Total prefixes that are protected."; } leaf linkprotected-routes { type uint32; description "Total prefixes that are link protected."; } leaf nodeprotected-routes { type uint32; description "Total prefixes that are node protected."; } } } Yeung, et al. Expires April 19, 2020 [Page 77] Internet-Draft OSPF YANG Data Model October 2019 } grouping interface-fast-reroute-config { description "This group defines interface configuration of IP-FRR."; container fast-reroute { if-feature fast-reroute; container lfa { if-feature lfa; leaf candidate-enable { type boolean; default true; description "Enable the interface to be used as backup."; } leaf enable { type boolean; default false; description "Activates LFA - Per-prefix LFA computation is assumed."; } container remote-lfa { if-feature remote-lfa; leaf enable { type boolean; default false; description "Activates Remote LFA (R-LFA)."; } description "Remote LFA configuration."; } description "LFA configuration."; } description "Interface IP Fast-reroute configuration."; } } grouping interface-physical-link-config { description "Interface cost configuration that only applies to physical interfaces (non-virtual) and sham links."; leaf cost { type ospf-link-metric; description Yeung, et al. Expires April 19, 2020 [Page 78] Internet-Draft OSPF YANG Data Model October 2019 "Interface cost."; } leaf mtu-ignore { if-feature mtu-ignore; type boolean; description "Enable/Disable bypassing the MTU mismatch check in Database Description packets specified in RFC 2328, section 10.6."; } leaf prefix-suppression { if-feature prefix-suppression; type boolean; description "Suppress advertisement of the prefixes associated with the interface."; } } grouping interface-common-config { description "Common configuration for all types of interfaces, including virtual links and sham links."; leaf hello-interval { type uint16; units seconds; description "Interval between hello packets (seconds). It must be the same for all routers on the same network. Different networks, implementations, and deployments will use different hello-intervals. A sample value for a LAN network would be 10 seconds."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf dead-interval { type uint16; units seconds; must "../dead-interval > ../hello-interval" { error-message "The dead interval must be " + "larger than the hello interval"; description "The value must be greater than the 'hello-interval'."; } description "Interval after which a neighbor is declared down (seconds) if hello packets are not received. It is Yeung, et al. Expires April 19, 2020 [Page 79] Internet-Draft OSPF YANG Data Model October 2019 typically 3 or 4 times the hello-interval. A typical value for LAN networks is 40 seconds."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf retransmit-interval { type uint16 { range "1..3600"; } units seconds; description "Interval between retransmitting unacknowledged Link State Advertisements (LSAs) (seconds). This should be well over the round-trip transmit delay for any two routers on the network. A sample value would be 5 seconds."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf transmit-delay { type uint16; units seconds; description "Estimated time needed to transmit Link State Update (LSU) packets on the interface (seconds). LSAs have their age incremented by this amount when advertised on the interface. A sample value would be 1 second."; reference "RFC 2328: OSPF Version 2, Appendix C.3"; } leaf lls { if-feature lls; type boolean; description "Enable/Disable link-local signaling (LLS) support."; } container ttl-security { if-feature ttl-security; description "Time to Live (TTL) security check."; leaf enable { type boolean; description "Enable/Disable TTL security check."; } leaf hops { type uint8 { range "1..254"; Yeung, et al. Expires April 19, 2020 [Page 80] Internet-Draft OSPF YANG Data Model October 2019 } default 1; description "Maximum number of hops that an OSPF packet may have traversed before reception."; } } leaf enable { type boolean; default true; description "Enable/disable OSPF protocol on the interface."; } container authentication { description "Authentication configuration."; choice auth-type-selection { description "Options for OSPFv2/OSPFv3 authentication configuration."; case ospfv2-auth { when "derived-from-or-self(../../../../../../rt:type, " + "'ospfv2')" { description "Applied to OSPFv2 only."; } leaf ospfv2-auth-trailer-rfc { if-feature ospfv2-authentication-trailer; type ospfv2-auth-trailer-rfc-version; description "Version of OSFPv2 authentication trailer support - RFC 5709 or RFC 7474"; } choice ospfv2-auth-specification { description "Key chain or explicit key parameter specification"; case auth-key-chain { if-feature key-chain; leaf ospfv2-key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key-explicit { leaf ospfv2-key-id { type uint32; description "Key Identifier"; Yeung, et al. Expires April 19, 2020 [Page 81] Internet-Draft OSPF YANG Data Model October 2019 } leaf ospfv2-key { type string; description "OSPFv2 authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf ospfv2-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } } case ospfv3-auth-ipsec { when "derived-from-or-self(../../../../../../rt:type, " + "'ospfv3')" { description "Applied to OSPFv3 only."; } if-feature ospfv3-authentication-ipsec; leaf sa { type string; description "Security Association (SA) name."; } } case ospfv3-auth-trailer { when "derived-from-or-self(../../../../../../rt:type, " + "'ospfv3')" { description "Applied to OSPFv3 only."; } if-feature ospfv3-authentication-trailer; choice ospfv3-auth-specification { description "Key chain or explicit key parameter specification"; case auth-key-chain { if-feature key-chain; leaf ospfv3-key-chain { type key-chain:key-chain-ref; description "key-chain name."; } } case auth-key-explicit { Yeung, et al. Expires April 19, 2020 [Page 82] Internet-Draft OSPF YANG Data Model October 2019 leaf ospfv3-sa-id { type uint16; description "Security Association (SA) Identifier"; } leaf ospfv3-key { type string; description "OSPFv3 authentication key. The length of the key may be dependent on the cryptographic algorithm."; } leaf ospfv3-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } } } } } grouping interface-config { description "Configuration for real interfaces."; leaf interface-type { type enumeration { enum "broadcast" { description "Specify OSPF broadcast multi-access network."; } enum "non-broadcast" { description "Specify OSPF Non-Broadcast Multi-Access (NBMA) network."; } enum "point-to-multipoint" { description "Specify OSPF point-to-multipoint network."; } enum "point-to-point" { description "Specify OSPF point-to-point network."; } Yeung, et al. Expires April 19, 2020 [Page 83] Internet-Draft OSPF YANG Data Model October 2019 enum "hybrid" { if-feature hybrid-interface; description "Specify OSPF hybrid broadcast/P2MP network."; } } description "Interface type."; } leaf passive { type boolean; description "Enable/Disable passive interface - a passive interface's prefix will be advertised but no neighbor adjacencies will be formed on the interface."; } leaf demand-circuit { if-feature demand-circuit; type boolean; description "Enable/Disable demand circuit."; } leaf priority { type uint8; description "Configure OSPF router priority. On multi-access network this value is for Designated Router (DR) election. The priority is ignored on other interface types. A router with a higher priority will be preferred in the election and a value of 0 indicates the router is not eligible to become Designated Router or Backup Designated Router (BDR)."; } container multi-areas { if-feature multi-area-adj; description "Container for multi-area config."; list multi-area { key multi-area-id; description "Configure OSPF multi-area adjacency."; leaf multi-area-id { type area-id-type; description "Multi-area adjacency area ID."; Yeung, et al. Expires April 19, 2020 [Page 84] Internet-Draft OSPF YANG Data Model October 2019 } leaf cost { type ospf-link-metric; description "Interface cost for multi-area adjacency."; } } } container static-neighbors { description "Statically configured neighbors."; list neighbor { key "identifier"; description "Specify a static OSPF neighbor."; leaf identifier { type inet:ip-address; description "Neighbor Router ID, IPv4 address, or IPv6 address."; } leaf cost { type ospf-link-metric; description "Neighbor cost. Different implementations have different default costs with some defaulting to a cost inversely proportional to the interface speed. Others will default to 1 equating the cost to a hop count." ; } leaf poll-interval { type uint16; units seconds; description "Neighbor poll interval (seconds) for sending OSPF hello packets to discover the neighbor on NBMA networks. This interval dictates the granularity for discovery of new neighbors. A sample would be 120 seconds (2 minutes) for a legacy Packet Data Network (PDN) X.25 network."; reference "RFC 2328: OSPF Version 2, Appendix C.5"; } leaf priority { type uint8; description "Neighbor priority for DR election. A router with a higher priority will be preferred in the election Yeung, et al. Expires April 19, 2020 [Page 85] Internet-Draft OSPF YANG Data Model October 2019 and a value of 0 indicates the router is not eligible to become Designated Router or Backup Designated Router (BDR)."; } } } leaf node-flag { if-feature node-flag; type boolean; default false; description "Set prefix as identifying the advertising router."; reference "RFC 7684: OSPFv2 Prefix/Link Attribute Advertisement"; } container bfd { if-feature bfd; description "BFD Client Configuration."; uses bfd-types:client-cfg-parms; reference "RFC YYYY: YANG Data Model for Bidirectional Forwarding Detection (BFD). Please replace YYYY with published RFC number for draft-ietf-bfd-yang."; } uses interface-fast-reroute-config; uses interface-common-config; uses interface-physical-link-config; } grouping neighbor-state { description "OSPF neighbor operational state."; leaf address { type inet:ip-address; config false; description "Neighbor address."; } leaf dr-router-id { type rt-types:router-id; config false; description "Neighbor's Designated Router (DR) Router ID."; } leaf dr-ip-addr { Yeung, et al. Expires April 19, 2020 [Page 86] Internet-Draft OSPF YANG Data Model October 2019 type inet:ip-address; config false; description "Neighbor's Designated Router (DR) IP address."; } leaf bdr-router-id { type rt-types:router-id; config false; description "Neighbor's Backup Designated Router (BDR) Router ID."; } leaf bdr-ip-addr { type inet:ip-address; config false; description "Neighbor's Backup Designated Router (BDR) IP Address."; } leaf state { type nbr-state-type; config false; description "OSPF neighbor state."; } leaf cost { type ospf-link-metric; config false; description "Cost to reach neighbor for Point-to-Multipoint and Hybrid networks"; } leaf dead-timer { type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the neighbor is declared dead."; } container statistics { config false; description "Per-neighbor statistics"; uses neighbor-stat; } } grouping interface-common-state { description "OSPF interface common operational state."; reference "RFC2328 Section 9: OSPF Version2 - The Interface Data Structure"; Yeung, et al. Expires April 19, 2020 [Page 87] Internet-Draft OSPF YANG Data Model October 2019 leaf state { type if-state-type; config false; description "Interface state."; } leaf hello-timer { type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the next hello packet is sent on the interface."; } leaf wait-timer { type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the interface exits the Waiting state."; } leaf dr-router-id { type rt-types:router-id; config false; description "Designated Router (DR) Router ID."; } leaf dr-ip-addr { type inet:ip-address; config false; description "Designated Router (DR) IP address."; } leaf bdr-router-id { type rt-types:router-id; config false; description "Backup Designated Router (BDR) Router ID."; } leaf bdr-ip-addr { type inet:ip-address; config false; description "Backup Designated Router (BDR) IP Address."; } container statistics { config false; description "Per-interface statistics"; Yeung, et al. Expires April 19, 2020 [Page 88] Internet-Draft OSPF YANG Data Model October 2019 uses interface-stat; } container neighbors { config false; description "All neighbors for the interface."; list neighbor { key "neighbor-router-id"; description "List of interface OSPF neighbors."; leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } uses neighbor-state; } } container database { config false; description "Link-scope Link State Database."; list link-scope-lsa-type { key "lsa-type"; description "List OSPF link-scope LSAs."; leaf lsa-type { type uint16; description "OSPF link-scope LSA type."; } container link-scope-lsas { description "All link-scope LSAs of this LSA type."; list link-scope-lsa { key "lsa-id adv-router"; description "List of OSPF link-scope LSAs"; uses lsa-key; uses lsa { refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../../../../../" + "rt:type, 'ospfv2')" { description "OSPFv2 LSA."; } } refine "version/ospfv3/ospfv3" { must "derived-from-or-self( " + "../../../../../../../../../../" + "rt:type, 'ospfv3')" { Yeung, et al. Expires April 19, 2020 [Page 89] Internet-Draft OSPF YANG Data Model October 2019 description "OSPFv3 LSA."; } } } } } } } } grouping interface-state { description "OSPF interface operational state."; reference "RFC2328 Section 9: OSPF Version2 - The Interface Data Structure"; uses interface-common-state; } grouping virtual-link-config { description "OSPF virtual link configuration state."; uses interface-common-config; } grouping virtual-link-state { description "OSPF virtual link operational state."; leaf cost { type ospf-link-metric; config false; description "Virtual link interface cost."; } uses interface-common-state; } grouping sham-link-config { description "OSPF sham link configuration state."; uses interface-common-config; uses interface-physical-link-config; } grouping sham-link-state { Yeung, et al. Expires April 19, 2020 [Page 90] Internet-Draft OSPF YANG Data Model October 2019 description "OSPF sham link operational state."; uses interface-common-state; } grouping address-family-area-config { description "OSPF address-family specific area config state."; container ranges { description "Container for summary ranges"; list range { key "prefix"; description "Summarize routes matching address/mask - Applicable to Area Border Routers (ABRs) only."; leaf prefix { type inet:ip-prefix; description "IPv4 or IPv6 prefix"; } leaf advertise { type boolean; description "Advertise or hide."; } leaf cost { type ospf-metric; description "Advertised cost of summary route."; } } } } grouping area-common-config { description "OSPF area common configuration state."; leaf summary { when "derived-from(../area-type,'stub-nssa-area')" { description "Summary advertisement into the stub/NSSA area."; } type boolean; description "Enable/Disable summary advertisement into the stub or Yeung, et al. Expires April 19, 2020 [Page 91] Internet-Draft OSPF YANG Data Model October 2019 NSSA area."; } leaf default-cost { when "derived-from(../area-type,'stub-nssa-area')" { description "Cost for LSA default route advertised into the stub or NSSA area."; } type ospf-metric; description "Set the summary default route cost for a stub or NSSA area."; } } grouping area-config { description "OSPF area configuration state."; leaf area-type { type identityref { base area-type; } default normal-area; description "Area type."; } uses area-common-config; uses address-family-area-config; } grouping area-state { description "OSPF area operational state."; container statistics { config false; description "Per-area statistics"; uses area-stat; } container database { config false; description "Area-scope Link State Database."; list area-scope-lsa-type { key "lsa-type"; description "List OSPF area-scope LSAs."; Yeung, et al. Expires April 19, 2020 [Page 92] Internet-Draft OSPF YANG Data Model October 2019 leaf lsa-type { type uint16; description "OSPF area-scope LSA type."; } container area-scope-lsas { description "All area-scope LSAs of an area-scope LSA type."; list area-scope-lsa { key "lsa-id adv-router"; description "List of OSPF area-scope LSAs"; uses lsa-key; uses lsa { refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../../../" + "rt:type, 'ospfv2')" { description "OSPFv2 LSA."; } } refine "version/ospfv3/ospfv3" { must "derived-from-or-self( " + "../../../../../../../../" + "rt:type, 'ospfv3')" { description "OSPFv3 LSA."; } } } } } } } } grouping local-rib { description "Local-rib - RIB for Routes computed by the local OSPF routing instance."; container local-rib { config false; description "Local-rib."; list route { key "prefix"; description "Routes"; leaf prefix { type inet:ip-prefix; description "Destination prefix."; } container next-hops { Yeung, et al. Expires April 19, 2020 [Page 93] Internet-Draft OSPF YANG Data Model October 2019 description "Next hops for the route."; list next-hop { key "next-hop"; description "List of next hops for the route"; leaf outgoing-interface { type if:interface-ref; description "Name of the outgoing interface."; } leaf next-hop { type inet:ip-address; description "Next hop address."; } } } leaf metric { type uint32; description "Metric for this route."; } leaf route-type { type route-type; description "Route type for this route."; } leaf route-tag { type uint32; description "Route tag for this route."; } } } } grouping ietf-spf-delay { leaf initial-delay { type uint32; units milliseconds; description "Delay used while in QUIET state (milliseconds)."; } leaf short-delay { type uint32; units milliseconds; description "Delay used while in SHORT_WAIT state (milliseconds)."; } leaf long-delay { type uint32; units milliseconds; description Yeung, et al. Expires April 19, 2020 [Page 94] Internet-Draft OSPF YANG Data Model October 2019 "Delay used while in LONG_WAIT state (milliseconds)."; } leaf hold-down { type uint32; units milliseconds; description "Timer used to consider an IGP stability period (milliseconds)."; } leaf time-to-learn { type uint32; units milliseconds; description "Duration used to learn all the IGP events related to a single component failure (milliseconds)."; } leaf current-state { type enumeration { enum "quiet" { description "QUIET state"; } enum "short-wait" { description "SHORT_WAIT state"; } enum "long-wait" { description "LONG_WAIT state"; } } config false; description "Current SPF back-off algorithm state."; } leaf remaining-time-to-learn { type rt-types:timer-value-milliseconds; config false; description "Remaining time until time-to-learn timer fires."; } leaf remaining-hold-down { type rt-types:timer-value-milliseconds; config false; description "Remaining time until hold-down timer fires."; } leaf last-event-received { type yang:timestamp; config false; description Yeung, et al. Expires April 19, 2020 [Page 95] Internet-Draft OSPF YANG Data Model October 2019 "Time of last SPF triggering event."; } leaf next-spf-time { type yang:timestamp; config false; description "Time when next SPF has been scheduled."; } leaf last-spf-time { type yang:timestamp; config false; description "Time of last SPF computation."; } description "Grouping for IETF SPF delay configuration and state"; } grouping node-tag-config { description "OSPF node tag config state."; container node-tags { if-feature node-tag; list node-tag { key tag; leaf tag { type uint32; description "Node tag value."; } description "List of tags."; } description "Container for node admin tags."; } } grouping instance-config { description "OSPF instance config state."; leaf enable { type boolean; default true; description "Enable/Disable the protocol."; } Yeung, et al. Expires April 19, 2020 [Page 96] Internet-Draft OSPF YANG Data Model October 2019 leaf explicit-router-id { if-feature explicit-router-id; type rt-types:router-id; description "Defined in RFC 2328. A 32-bit number that uniquely identifies the router."; } container preference { description "Route preference configuration. In many implementations, preference is referred to as administrative distance."; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; choice scope { description "Options for expressing preference as single or multiple values."; case single-value { leaf all { type uint8; description "Preference for intra-area, inter-area, and external routes."; } } case multi-values { choice granularity { description "Options for expressing preference for intra-area and inter-area routes."; case detail { leaf intra-area { type uint8; description "Preference for intra-area routes."; } leaf inter-area { type uint8; description "Preference for inter-area routes."; } } case coarse { leaf internal { type uint8; Yeung, et al. Expires April 19, 2020 [Page 97] Internet-Draft OSPF YANG Data Model October 2019 description "Preference for both intra-area and inter-area routes."; } } } leaf external { type uint8; description "Preference for AS external routes."; } } } } container nsr { if-feature nsr; description "Non-Stop Routing (NSR) config state."; leaf enable { type boolean; description "Enable/Disable NSR."; } } container graceful-restart { if-feature graceful-restart; description "Graceful restart config state."; reference "RFC 3623: OSPF Graceful Restart RFC 5187: OSPFv3 Graceful Restart"; leaf enable { type boolean; description "Enable/Disable graceful restart as defined in RFC 3623 for OSPFv2 and RFC 5187 for OSPFv3."; } leaf helper-enable { type boolean; description "Enable graceful restart helper support for restarting routers (RFC 3623 Section 3)."; } leaf restart-interval { type uint16 { range "1..1800"; } Yeung, et al. Expires April 19, 2020 [Page 98] Internet-Draft OSPF YANG Data Model October 2019 units seconds; default "120"; description "Interval to attempt graceful restart prior to failing (RFC 3623 Section B.1) (seconds)"; } leaf helper-strict-lsa-checking { type boolean; description "Terminate graceful restart when an LSA topology change is detected (RFC 3623 Section B.2)."; } } container auto-cost { if-feature auto-cost; description "Interface Auto-cost configuration state."; leaf enable { type boolean; description "Enable/Disable interface auto-cost."; } leaf reference-bandwidth { when "../enable = 'true'" { description "Only when auto cost is enabled"; } type uint32 { range "1..4294967"; } units Mbits; description "Configure reference bandwidth used to automatically determine interface cost (Mbits). The cost is the reference bandwidth divided by the interface speed with 1 being the minimum cost."; } } container spf-control { leaf paths { if-feature max-ecmp; type uint16 { range "1..65535"; } description "Maximum number of Equal-Cost Multi-Path (ECMP) paths."; } Yeung, et al. Expires April 19, 2020 [Page 99] Internet-Draft OSPF YANG Data Model October 2019 container ietf-spf-delay { if-feature ietf-spf-delay; uses ietf-spf-delay; description "IETF SPF delay algorithm configuration."; } description "SPF calculation control."; } container database-control { leaf max-lsa { if-feature max-lsa; type uint32 { range "1..4294967294"; } description "Maximum number of LSAs OSPF the router will accept."; } description "Database maintenance control."; } container stub-router { if-feature stub-router; description "Set maximum metric configuration"; choice trigger { description "Specific triggers which will enable stub router state."; container always { presence "Enables unconditional stub router support"; description "Unconditional stub router state (advertise transit links with MaxLinkMetric"; reference "RFC 6987: OSPF Stub Router Advertisement"; } } } container mpls { description "OSPF MPLS config state."; container te-rid { if-feature te-rid; description "Stable OSPF Router IP Address used for Traffic Yeung, et al. Expires April 19, 2020 [Page 100] Internet-Draft OSPF YANG Data Model October 2019 Engineering (TE)"; leaf ipv4-router-id { type inet:ipv4-address; description "Explicitly configure the TE IPv4 Router ID."; } leaf ipv6-router-id { type inet:ipv6-address; description "Explicitly configure the TE IPv6 Router ID."; } } container ldp { description "OSPF MPLS LDP config state."; leaf igp-sync { if-feature ldp-igp-sync; type boolean; description "Enable LDP IGP synchronization."; } } } uses instance-fast-reroute-config; uses node-tag-config; } grouping instance-state { description "OSPF instance operational state."; leaf router-id { type rt-types:router-id; config false; description "Defined in RFC 2328. A 32-bit number that uniquely identifies the router."; } uses local-rib; container statistics { config false; description "Per-instance statistics"; uses instance-stat; } container database { Yeung, et al. Expires April 19, 2020 [Page 101] Internet-Draft OSPF YANG Data Model October 2019 config false; description "AS-scope Link State Database."; list as-scope-lsa-type { key "lsa-type"; description "List OSPF AS-scope LSAs."; leaf lsa-type { type uint16; description "OSPF AS scope LSA type."; } container as-scope-lsas { description "All AS-scope of LSA of this LSA type."; list as-scope-lsa { key "lsa-id adv-router"; description "List of OSPF AS-scope LSAs"; uses lsa-key; uses lsa { refine "version/ospfv2/ospfv2" { must "derived-from-or-self( " + "../../../../../../" + "rt:type, 'ospfv2')" { description "OSPFv2 LSA."; } } refine "version/ospfv3/ospfv3" { must "derived-from-or-self( " + "../../../../../../" + "rt:type, 'ospfv3')" { description "OSPFv3 LSA."; } } } } } } } uses spf-log; uses lsa-log; } grouping multi-topology-area-common-config { description "OSPF multi-topology area common configuration state."; leaf summary { when "derived-from(../../../area-type, 'stub-nssa-area')" { description "Summary advertisement into the stub/NSSA area."; } type boolean; Yeung, et al. Expires April 19, 2020 [Page 102] Internet-Draft OSPF YANG Data Model October 2019 description "Enable/Disable summary advertisement into the topology in the stub or NSSA area."; } leaf default-cost { when "derived-from(../../../area-type, 'stub-nssa-area')" { description "Cost for LSA default route advertised into the topology into the stub or NSSA area."; } type ospf-metric; description "Set the summary default route cost for a stub or NSSA area."; } } grouping multi-topology-area-config { description "OSPF multi-topology area configuration state."; uses multi-topology-area-common-config; uses address-family-area-config; } grouping multi-topology-state { description "OSPF multi-topology operational state."; uses local-rib; } grouping multi-topology-interface-config { description "OSPF multi-topology configuration state."; leaf cost { type ospf-link-metric; description "Interface cost for this topology."; } } grouping ospfv3-interface-config { description "OSPFv3 interface specific configuration state."; leaf instance-id { Yeung, et al. Expires April 19, 2020 [Page 103] Internet-Draft OSPF YANG Data Model October 2019 type uint8 { range "0 .. 31"; } description "OSPFv3 instance ID."; } } grouping ospfv3-interface-state { description "OSPFv3 interface specific operational state."; leaf interface-id { type uint16; config false; description "OSPFv3 interface ID."; } } grouping lsa-identifiers { description "The parameters that uniquely identify an LSA."; leaf area-id { type area-id-type; description "Area ID"; } leaf type { type uint16; description "LSA type."; } leaf lsa-id { type union { type inet:ipv4-address; type yang:dotted-quad; } description "Link-State ID."; } leaf adv-router { type rt-types:router-id; description "LSA advertising router."; } leaf seq-num { type uint32; description Yeung, et al. Expires April 19, 2020 [Page 104] Internet-Draft OSPF YANG Data Model October 2019 "LSA sequence number."; } } grouping spf-log { description "Grouping for SPF log."; container spf-log { config false; description "This container lists the SPF log."; list event { key id; description "List of SPF log entries represented as a wrapping buffer in chronological order with the oldest entry returned first."; leaf id { type uint32; description "Event identifier - Purely internal value."; } leaf spf-type { type enumeration { enum full { description "SPF computation was a Full SPF."; } enum intra { description "SPF computation was only for intra-area routes."; } enum inter { description "SPF computation was only for inter-area summary routes."; } enum external { description "SPF computation was only for AS external routes."; } } description "The SPF computation type for the SPF log entry."; } leaf schedule-timestamp { type yang:timestamp; Yeung, et al. Expires April 19, 2020 [Page 105] Internet-Draft OSPF YANG Data Model October 2019 description "This is the timestamp when the computation was scheduled."; } leaf start-timestamp { type yang:timestamp; description "This is the timestamp when the computation was started."; } leaf end-timestamp { type yang:timestamp; description "This the timestamp when the computation was completed."; } list trigger-lsa { description "The list of LSAs that triggered the computation."; uses lsa-identifiers; } } } } grouping lsa-log { description "Grouping for the LSA log."; container lsa-log { config false; description "This container lists the LSA log. Local LSA modifications are also included in the list."; list event { key id; description "List of LSA log entries represented as a wrapping buffer in chronological order with the oldest entries returned first."; leaf id { type uint32; description "Event identifier - purely internal value."; } container lsa { description "This container describes the logged LSA."; Yeung, et al. Expires April 19, 2020 [Page 106] Internet-Draft OSPF YANG Data Model October 2019 uses lsa-identifiers; } leaf received-timestamp { type yang:timestamp; description "This is the timestamp when the LSA was received. In case of local LSA update, the timestamp refers to the LSA origination time."; } leaf reason { type identityref { base lsa-log-reason; } description "This reason for the LSA log entry."; } } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from(rt:type, 'ospf')" { description "This augmentation is only valid for a routing protocol instance of OSPF (type 'ospfv2' or 'ospfv3')."; } description "OSPF protocol ietf-routing module control-plane-protocol augmentation."; container ospf { description "OSPF protocol Instance"; leaf address-family { type iana-rt-types:address-family; description "Address-family of the instance."; } uses instance-config; uses instance-state; container areas { description "All areas."; list area { key "area-id"; description Yeung, et al. Expires April 19, 2020 [Page 107] Internet-Draft OSPF YANG Data Model October 2019 "List of OSPF areas"; leaf area-id { type area-id-type; description "Area ID"; } uses area-config; uses area-state; container virtual-links { when "derived-from-or-self(../area-type, 'normal-area') " + "and ../area-id = '0.0.0.0'" { description "Virtual links must be in backbone area."; } description "All virtual links."; list virtual-link { key "transit-area-id router-id"; description "OSPF virtual link"; leaf transit-area-id { type leafref { path "../../../../area/area-id"; } must "derived-from-or-self(" + "../../../../area[area-id=current()]/area-type, " + "'normal-area') and " + "../../../../area[area-id=current()]/area-id != " + "'0.0.0.0'" { error-message "Virtual link transit area must " + "be non-zero."; description "Virtual-link transit area must be non-zero area."; } description "Virtual link transit area ID."; } leaf router-id { type rt-types:router-id; description "Virtual Link remote endpoint Router ID."; } uses virtual-link-config; uses virtual-link-state; } Yeung, et al. Expires April 19, 2020 [Page 108] Internet-Draft OSPF YANG Data Model October 2019 } container sham-links { if-feature pe-ce-protocol; description "All sham links."; list sham-link { key "local-id remote-id"; description "OSPF sham link"; leaf local-id { type inet:ip-address; description "Address of the local sham Link endpoint."; } leaf remote-id { type inet:ip-address; description "Address of the remote sham Link endpoint."; } uses sham-link-config; uses sham-link-state; } } container interfaces { description "All interfaces."; list interface { key "name"; description "List of OSPF interfaces."; leaf name { type if:interface-ref; description "Interface name reference."; } uses interface-config; uses interface-state; } } } } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf" { when "derived-from(../rt:type, 'ospf')" { description "This augmentation is only valid for OSPF (type 'ospfv2' or 'ospfv3')."; Yeung, et al. Expires April 19, 2020 [Page 109] Internet-Draft OSPF YANG Data Model October 2019 } if-feature multi-topology; description "OSPF multi-topology instance configuration state augmentation."; container topologies { description "All topologies."; list topology { key "name"; description "OSPF topology - The OSPF topology address-family must coincide with the routing-instance address-family."; leaf name { type leafref { path "../../../../../../rt:ribs/rt:rib/rt:name"; } description "RIB name corresponding to the OSPF topology."; } uses multi-topology-state; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf/" + "areas/area" { when "derived-from-or-self(../../../rt:type, " + "'ospfv2')" { description "This augmentation is only valid for OSPFv2."; } if-feature multi-topology; description "OSPF multi-topology area configuration state augmentation."; container topologies { description "All topologies for the area."; list topology { key "name"; description "OSPF area topology."; leaf name { type leafref { path "../../../../../../../../" + "rt:ribs/rt:rib/rt:name"; } Yeung, et al. Expires April 19, 2020 [Page 110] Internet-Draft OSPF YANG Data Model October 2019 description "Single topology enabled for this area."; } uses multi-topology-area-config; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf/" + "areas/area/interfaces/interface" { when "derived-from-or-self(../../../../../rt:type, " + "'ospfv2')" { description "This augmentation is only valid for OSPFv2."; } if-feature multi-topology; description "OSPF multi-topology interface configuration state augmentation."; container topologies { description "All topologies for the interface."; list topology { key "name"; description "OSPF interface topology."; leaf name { type leafref { path "../../../../../../../../../../" + "rt:ribs/rt:rib/rt:name"; } description "Single topology enabled on this interface."; } uses multi-topology-interface-config; } } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/ospf/" + "areas/area/interfaces/interface" { when "derived-from-or-self(../../../../../rt:type, " + "'ospfv3')" { description "This augmentation is only valid for OSPFv3."; } Yeung, et al. Expires April 19, 2020 [Page 111] Internet-Draft OSPF YANG Data Model October 2019 description "OSPFv3 interface specific configuration state augmentation."; uses ospfv3-interface-config; uses ospfv3-interface-state; } grouping route-content { description "This grouping defines OSPF-specific route attributes."; leaf metric { type uint32; description "OSPF route metric."; } leaf tag { type uint32; default "0"; description "OSPF route tag."; } leaf route-type { type route-type; description "OSPF route type"; } } augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { when "derived-from(rt:source-protocol, 'ospf')" { description "This augmentation is only valid for routes whose source protocol is OSPF."; } description "OSPF-specific route attributes."; uses route-content; } /* * RPCs */ rpc clear-neighbor { description "This RPC request clears a particular set of OSPF neighbors. If the operation fails for OSPF internal reason, then error-tag and error-app-tag should be set to a meaningful value."; input { leaf routing-protocol-name { Yeung, et al. Expires April 19, 2020 [Page 112] Internet-Draft OSPF YANG Data Model October 2019 type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "OSPF protocol instance which information for neighbors are to be cleared. If the referenced OSPF instance doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'routing-protocol-instance-not-found'."; } leaf interface { type if:interface-ref; description "Name of the OSPF interface for which neighbors are to be cleared. If the referenced OSPF interface doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'ospf-interface-not-found'."; } } } rpc clear-database { description "This RPC request clears a particular OSPF Link State Database. If the operation fails for OSPF internal reason, then error-tag and error-app-tag should be set to a meaningful value."; input { leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } mandatory "true"; description "OSPF protocol instance whose Link State Database is to be cleared. If the referenced OSPF instance doesn't exist, then this operation SHALL fail with error-tag 'data-missing' Yeung, et al. Expires April 19, 2020 [Page 113] Internet-Draft OSPF YANG Data Model October 2019 and error-app-tag 'routing-protocol-instance-not-found'."; } } } /* * Notifications */ grouping notification-instance-hdr { description "This grouping describes common instance specific data for OSPF notifications."; leaf routing-protocol-name { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/rt:name"; } must "derived-from( " + "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol[rt:name=current()]/" + "rt:type, 'ospf')"; description "OSPF routing protocol instance name."; } leaf address-family { type leafref { path "/rt:routing/" + "rt:control-plane-protocols/rt:control-plane-protocol" + "[rt:name=current()/../routing-protocol-name]/" + "ospf/address-family"; } description "Address family of the OSPF instance."; } } grouping notification-interface { description "This grouping provides interface information for the OSPF interface specific notification."; choice if-link-type-selection { description "Options for link type."; Yeung, et al. Expires April 19, 2020 [Page 114] Internet-Draft OSPF YANG Data Model October 2019 container interface { description "Normal interface."; leaf interface { type if:interface-ref; description "Interface."; } } container virtual-link { description "virtual-link."; leaf transit-area-id { type area-id-type; description "Area ID."; } leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } } container sham-link { description "sham link."; leaf area-id { type area-id-type; description "Area ID."; } leaf local-ip-addr { type inet:ip-address; description "Sham link local address."; } leaf remote-ip-addr { type inet:ip-address; description "Sham link remote address."; } } } } grouping notification-neighbor { description "This grouping provides the neighbor information for neighbor specific notifications."; leaf neighbor-router-id { type rt-types:router-id; description "Neighbor Router ID."; } leaf neighbor-ip-addr { type inet:ip-address; Yeung, et al. Expires April 19, 2020 [Page 115] Internet-Draft OSPF YANG Data Model October 2019 description "Neighbor address."; } } notification if-state-change { uses notification-instance-hdr; uses notification-interface; leaf state { type if-state-type; description "Interface state."; } description "This notification is sent when an interface state change is detected."; } notification if-config-error { uses notification-instance-hdr; uses notification-interface; leaf packet-source { type inet:ip-address; description "Source address."; } leaf packet-type { type packet-type; description "OSPF packet type."; } leaf error { type enumeration { enum "bad-version" { description "Bad version."; } enum "area-mismatch" { description "Area mismatch."; } enum "unknown-nbma-nbr" { description "Unknown NBMA neighbor."; } enum "unknown-virtual-nbr" { description "Unknown virtual link neighbor."; } enum "auth-type-mismatch" { description "Auth type mismatch."; } Yeung, et al. Expires April 19, 2020 [Page 116] Internet-Draft OSPF YANG Data Model October 2019 enum "auth-failure" { description "Auth failure."; } enum "net-mask-mismatch" { description "Network mask mismatch."; } enum "hello-interval-mismatch" { description "Hello interval mismatch."; } enum "dead-interval-mismatch" { description "Dead interval mismatch."; } enum "option-mismatch" { description "Option mismatch."; } enum "mtu-mismatch" { description "MTU mismatch."; } enum "duplicate-router-id" { description "Duplicate Router ID."; } enum "no-error" { description "No error."; } } description "Error code."; } description "This notification is sent when an interface config error is detected."; } notification nbr-state-change { uses notification-instance-hdr; uses notification-interface; uses notification-neighbor; leaf state { type nbr-state-type; description "Neighbor state."; } description "This notification is sent when a neighbor state change is detected."; } notification nbr-restart-helper-status-change { Yeung, et al. Expires April 19, 2020 [Page 117] Internet-Draft OSPF YANG Data Model October 2019 uses notification-instance-hdr; uses notification-interface; uses notification-neighbor; leaf status { type restart-helper-status-type; description "Restart helper status."; } leaf age { type rt-types:timer-value-seconds16; description "Remaining time in current OSPF graceful restart interval when the router is acting as a restart helper for the neighbor."; } leaf exit-reason { type restart-exit-reason-type; description "Restart helper exit reason."; } description "This notification is sent when a neighbor restart helper status change is detected."; } notification if-rx-bad-packet { uses notification-instance-hdr; uses notification-interface; leaf packet-source { type inet:ip-address; description "Source address."; } leaf packet-type { type packet-type; description "OSPF packet type."; } description "This notification is sent when an OSPF packet that cannot be parsed is received on an OSPF interface."; } notification lsdb-approaching-overflow { uses notification-instance-hdr; Yeung, et al. Expires April 19, 2020 [Page 118] Internet-Draft OSPF YANG Data Model October 2019 leaf ext-lsdb-limit { type uint32; description "The maximum number of non-default AS-external LSAs entries that can be stored in the Link State Database."; } description "This notification is sent when the number of LSAs in the router's Link State Database has exceeded ninety percent of the AS-external limit (ext-lsdb-limit)."; } notification lsdb-overflow { uses notification-instance-hdr; leaf ext-lsdb-limit { type uint32; description "The maximum number of non-default AS-external LSAs entries that can be stored in the Link State Database."; } description "This notification is sent when the number of LSAs in the router's Link State Database has exceeded the AS-external limit (ext-lsdb-limit)."; } notification nssa-translator-status-change { uses notification-instance-hdr; leaf area-id { type area-id-type; description "Area ID."; } leaf status { type nssa-translator-state-type; description "NSSA translator status."; } description "This notification is sent when there is a change in the router's role in translating OSPF NSSA LSAs to OSPF AS-External LSAs."; } Yeung, et al. Expires April 19, 2020 [Page 119] Internet-Draft OSPF YANG Data Model October 2019 notification restart-status-change { uses notification-instance-hdr; leaf status { type restart-status-type; description "Restart status."; } leaf restart-interval { type uint16 { range 1..1800; } units seconds; default "120"; description "Restart interval."; } leaf exit-reason { type restart-exit-reason-type; description "Restart exit reason."; } description "This notification is sent when the graceful restart state for the router has changed."; } } 4. Security Considerations The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a pre- configured subset of all available NETCONF or RESTCONF protocol operations and content. Yeung, et al. Expires April 19, 2020 [Page 120] Internet-Draft OSPF YANG Data Model October 2019 There are a number of data nodes defined in ietf-ospf.yang module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Writable data node represent configuration of each instance, area, virtual link, sham-link, and interface. These correspond to the following schema nodes: /ospf /ospf/areas/ /ospf/areas/area[area-id] /ospf/virtual-links/ /ospf/virtual-links/virtual-link[transit-area-id router-id] /ospf/areas/area[area-id]/interfaces /ospf/areas/area[area-id]/interfaces/interface[name] /ospf/area/area[area-id]/sham-links /ospf/area/area[area-id]/sham-links/sham-link[local-id remote-id] For OSPF, the ability to modify OSPF configuration will allow the entire OSPF domain to be compromised including peering with unauthorized routers to misroute traffic or mount a massive Denial- of-Service (DoS) attack. For example, adding OSPF on any unprotected interface could allow an OSPF adjacency to be formed with an unauthorized and malicious neighbor. Once an adjacency is formed, traffic could be hijacked. As a simpler example, a Denial-of-Service attack could be mounted by changing the cost of an OSPF interface to be asymmetric such that a hard routing loop ensues. In general, unauthorized modification of most OSPF features will pose there own set of security risks and the "Security Considerations" in the respective reference RFCs should be consulted. Some of the readable data nodes in the ietf-ospf.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The exposure of the Link State Database (LSDB) will expose the detailed topology of the network. There is a separate Link State Database for each instance, area, virtual link, sham-link, and interface. These correspond to the following schema nodes: Yeung, et al. Expires April 19, 2020 [Page 121] Internet-Draft OSPF YANG Data Model October 2019 /ospf/database /ospf/areas/area[area-id]/database /ospf/virtual-links/virtual-link[transit-area-id router- id]/database /ospf/areas/area[area-id]/interfaces/interface[name]/database /ospf/area/area[area-id]/sham-links/sham-link[local-id remote- id]/database Exposure of the Link State Database includes information beyond the scope of the OSPF router and this may be undesirable since exposure may facilitate other attacks. Additionally, in the case of an area LSDB, the complete IP network topology and, if deployed, the traffic engineering topology of the OSPF area can be reconstucted. Network operators may consider their topologies to be sensitive confidential data. For OSPF authentication, configuration is supported via the specification of key-chains [RFC8177] or the direct specification of key and authentication algorithm. Hence, authentication configuration using the "auth-table-trailer" case in the "authentication" container inherits the security considerations of [RFC8177]. This includes the considerations with respect to the local storage and handling of authentication keys. Additionally, local specification of OSPF authentication keys and the associated authentication algorithm is supported for legacy implementations that do not support key-chains [RFC8177] It is RECOMMENDED that implementations migrate to key-chains due the seamless support of key and algorithm rollover, as well as, the hexadecimal key specification affording more key entropy, and encryption of keys using the Advanced Encryption Standard (AES) Key Wrap Padding Algorithm [RFC5649]. Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. The OSPF YANG module supports the "clear-neighbor" and "clear-database" RPCs. If access to either of these is compromised, they can result in temporary network outages be employed to mount DoS attacks. The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties; compromise of the key data would allow an Yeung, et al. Expires April 19, 2020 [Page 122] Internet-Draft OSPF YANG Data Model October 2019 attacker to forge OSPF traffic that would be accepted as authentic, potentially compromising the entirety OSPF domain. 5. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-ospf Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-ospf namespace: urn:ietf:params:xml:ns:yang:ietf-ospf prefix: ospf reference: RFC XXXX 6. Acknowledgements The authors wish to thank Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta, Michael Darwish, and Alan Davey for their thorough reviews and helpful comments. Thanks to Tom Petch for last call review and improvement of the document organization. Thanks to Alvaro Retana for AD comments. Thanks to Benjamin Kaduk, Suresh Krishnan, and Roman Dannyliw for IESG review comments. This document was produced using Marshall Rose's xml2rfc tool. Author affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed. MITRE has approved this document for Public Release, Distribution Unlimited, with Public Release Case Number 18-3194. Yeung, et al. Expires April 19, 2020 [Page 123] Internet-Draft OSPF YANG Data Model October 2019 7. References 7.1. Normative References [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, DOI 10.17487/RFC1765, March 1995, . [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, DOI 10.17487/RFC1793, April 1995, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, . [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . Yeung, et al. Expires April 19, 2020 [Page 124] Internet-Draft OSPF YANG Data Model October 2019 [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, DOI 10.17487/RFC4576, June 2006, . [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC4973] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering", RFC 4973, DOI 10.17487/RFC4973, July 2007, . [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, . [RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal, "OSPF Multi-Area Adjacency", RFC 5185, DOI 10.17487/RFC5185, May 2008, . [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful Restart", RFC 5187, DOI 10.17487/RFC5187, June 2008, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, . [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, . Yeung, et al. Expires April 19, 2020 [Page 125] Internet-Draft OSPF YANG Data Model October 2019 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, . [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, DOI 10.17487/RFC5642, August 2009, . [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, . [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, . [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . Yeung, et al. Expires April 19, 2020 [Page 126] Internet-Draft OSPF YANG Data Model October 2019 [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, June 2012, . [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, . [RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January 2013, . [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . Yeung, et al. Expires April 19, 2020 [Page 127] Internet-Draft OSPF YANG Data Model October 2019 [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. Decraene, "Advertising Node Administrative Tags in OSPF", RFC 7777, DOI 10.17487/RFC7777, March 2016, . [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, "OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators", RFC 7884, DOI 10.17487/RFC7884, July 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Yeung, et al. Expires April 19, 2020 [Page 128] Internet-Draft OSPF YANG Data Model October 2019 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, DOI 10.17487/RFC8405, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, . 7.2. Informative References [RFC0905] "ISO Transport Protocol specification ISO DP 8073", RFC 905, DOI 10.17487/RFC0905, April 1984, . [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, DOI 10.17487/RFC4750, December 2006, . [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, . [RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August 2009, . [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, . Yeung, et al. Expires April 19, 2020 [Page 129] Internet-Draft OSPF YANG Data Model October 2019 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . Yeung, et al. Expires April 19, 2020 [Page 130] Internet-Draft OSPF YANG Data Model October 2019 Appendix A. Contributors' Addresses Dean Bogdanovic Volta Networks, Inc. EMail: dean@voltanet.io Kiran Koushik Agrahara Sreenivasa Verizon 500 W Dove Rd Southlake, TX 76092 USA EMail: kk@employees.org Authors' Addresses Derek Yeung Arrcus EMail: derek@arrcus.com Yingzhen Qu Futurewei 2330 Central Expressway Santa Clara, CA 95050 USA EMail: yingzhen.qu@futurewei.com Jeffrey Zhang Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA EMail: zzhang@juniper.net Ing-Wher Chen The MITRE Corporation EMail: ingwherchen@mitre.org Yeung, et al. Expires April 19, 2020 [Page 131] Internet-Draft OSPF YANG Data Model October 2019 Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 EMail: acee@cisco.com Yeung, et al. Expires April 19, 2020 [Page 132] ./draft-ietf-pce-pcep-flowspec-12.txt0000644000764400076440000023736013747166632016721 0ustar iustyiusty Network Working Group D. Dhody Internet-Draft Huawei Technologies Intended status: Standards Track A. Farrel Expires: May 3, 2021 Old Dog Consulting Z. Li Huawei Technologies October 30, 2020 PCEP Extension for Flow Specification draft-ietf-pce-pcep-flowspec-12 Abstract The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering network. These paths may be supplied in response to requests for computation, or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC XXXX defines the Flow Specification and describes how Flow Specification Components are used to describe traffic flows. RFC XXXX also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP, and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation. RFC Editor Note: Please replace XXXX in the Abstract with the RFC number assigned to draft-ietf-idr-rfc5575bis when it is published. Please remove this note. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Dhody, et al. Expires May 3, 2021 [Page 1] Internet-Draft PCEP-FlowSpec October 2020 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Procedures for PCE Use of Flow Specifications . . . . . . . . 6 3.1. Context for PCE Use of Flow Specifications . . . . . . . 6 3.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 7 3.2.1. Capability Advertisement . . . . . . . . . . . . . . 7 3.2.2. Dissemination Procedures . . . . . . . . . . . . . . 8 3.2.3. Flow Specification Synchronization . . . . . . . . . 9 4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 10 5. PCEP FLOWSPEC Object . . . . . . . . . . . . . . . . . . . . 10 6. Flow Filter TLV and L2 Flow Filter TLV . . . . . . . . . . . 13 7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 13 7.1. L2 Flow Specification TLVs . . . . . . . . . . . . . . . 17 8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 18 8.1. Default Behavior and Backward Compatibility . . . . . . . 18 8.2. Composite Flow Specifications . . . . . . . . . . . . . . 19 8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 19 8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 19 8.5. Adding and Removing Flow Specifications . . . . . . . . . 20 Dhody, et al. Expires May 3, 2021 [Page 2] Internet-Draft PCEP-FlowSpec October 2020 8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 20 8.7. Priorities and Overlapping Flow Specifications . . . . . 20 9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 24 10.1.1. PCEP FLOWSPEC Object Flag Field . . . . . . . . . . 24 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 25 10.3. Flow Specification TLV Type Indicators . . . . . . . . . 25 10.4. L2 Flow Specification TLV Type Indicators . . . . . . . 26 10.5. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 27 10.6. PCE Capability Flag . . . . . . . . . . . . . . . . . . 27 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Manageability Considerations . . . . . . . . . . . . . . . . 29 13.1. Management of Multiple Flow Specifications . . . . . . . 29 13.2. Control of Function through Configuration and Policy . . 30 13.3. Information and Data Models . . . . . . . . . . . . . . 30 13.4. Liveness Detection and Monitoring . . . . . . . . . . . 31 13.5. Verifying Correct Operation . . . . . . . . . . . . . . 31 13.6. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . 31 13.7. Impact on Network Operation . . . . . . . . . . . . . . 31 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 15.1. Normative References . . . . . . . . . . . . . . . . . . 32 15.2. Informative References . . . . . . . . . . . . . . . . . 33 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction [RFC4655] defines the Path Computation Element (PCE), a functional component capable of computing paths for use in traffic engineering networks. PCE was originally conceived for use in Multiprotocol Label Switching (MPLS) for Traffic Engineering (TE) networks to derive the routes of Label Switched Paths (LSPs). However, the scope of PCE was quickly extended to make it applicable to Generalized MPLS (GMPLS)-controlled networks, and more recent work has brought other traffic engineering technologies and planning applications into scope (for example, Segment Routing (SR) [RFC8664]). [RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP defines the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, enabling computation of path for MPLS-TE LSPs. Stateful PCE [RFC8231] specifies a set of extensions to PCEP to enable control of TE-LSPs by a PCE that retains state about the LSPs Dhody, et al. Expires May 3, 2021 [Page 3] Internet-Draft PCEP-FlowSpec October 2020 provisioned in the network (a stateful PCE). [RFC8281] describes the setup, maintenance, and teardown of LSPs initiated by a stateful PCE without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled. [RFC8283] introduces the architecture for PCE as a central controller and describes how PCE can be viewed as a component that performs computation to place 'flows' within the network and decide how these flows are routed. The description of traffic flows by the combination of multiple Flow Specification Components and their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in [I-D.ietf-idr-rfc5575bis]. In BGP, a Flow Specification is comprised of traffic filtering rules and is associated with actions to perform on the packets that match the Flow Specification. The BGP routers that receive a Flow Specification can classify received packets according to the traffic filtering rules and can direct packets based on the associated actions. When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what traffic to place on each tunnel. The data flows intended for a tunnel can be described using Flow Specification Components. When PCEP is in use for tunnel initiation it makes sense for that same protocol to be used to distribute the Flow Specification Components that describe what data is to flow on those tunnels. This document specifies a set of extensions to PCEP to support dissemination of Flow Specification Components. We term the description of a traffic flow using Flow Specification Components as a "Flow Specification". This term is conceptually the same as the term used in [I-D.ietf-idr-rfc5575bis], however, no mechanism is provided to distribute an action associated with the Flow Specification because there is only one action that is applicable in the PCEP context (that is, directing the matching traffic to the identified LSP). The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP, and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation. Flow Specifications are carried in TLVs within a new object called the FLOWSPEC object defined in this document. The flow filtering Dhody, et al. Expires May 3, 2021 [Page 4] Internet-Draft PCEP-FlowSpec October 2020 rules indicated by the Flow Specifications are mainly defined by BGP Flow Specifications. Note that PCEP-installed Flow Specifications are intended to be installed only at the head-end of the LSP to which they direct traffic. It is acceptable (and potentially desirable) that other routers in the network have Flow Specifications installed that match the same traffic, but direct it onto different routes or to different LSPs. Those other Flow Specifications may be installed using the PCEP extensions defined in this document, may be distributed using BGP per [I-D.ietf-idr-rfc5575bis], or may be configured using manual operations. Since this document is about PCEP-installed Flow Specifications, those other Flow Specifications at other routers are out of scope. In this context, however, it is worth noting that changes to the wider routing system (such as the distribution and installation of BGP Flow Specifications, or fluctuations in the IGP link state database) might mean that traffic matching the PCEP Flow Specification never reaches the head end of the LSP at which the PCEP Flow Specification has been installed. This may or may not be desirable according to the operator's traffic engineering and routing policies, and is particularly applicable at LSPs that do not have their head ends at the ingress-edge of the network, but it is not an effect that this document seeks to address. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer. The following term from [I-D.ietf-idr-rfc5575bis] is used frequently throughout this document: A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. A given IP packet is said to match the defined Flow Specification if it matches all the specified criteria. [I-D.ietf-idr-rfc5575bis] also states that "A given Flow Specification may be associated with a set of attributes," and that, "...attributes can be used to encode a set of predetermined actions." However, in the context of this document, no action is explicitly specified associated with the Flow Specification since the action "forward all matching traffic onto the associated path" is implicit. How an implementation decides how to filter traffic that matches a Flow Specification does not form part of this specification, but a flag is provided to indicate whether the sender of a PCEP message Dhody, et al. Expires May 3, 2021 [Page 5] Internet-Draft PCEP-FlowSpec October 2020 that includes a Flow Specification intends it to be installed as a Longest Prefix Match route or as a Flow Specification policy. This document uses the terms "stateful PCE" and "active PCE" as advocated in [RFC7399]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Procedures for PCE Use of Flow Specifications 3.1. Context for PCE Use of Flow Specifications In the PCE architecture there are five steps in the setup and use of LSPs: 1. Decide which LSPs to set up. The decision may be made by a user, by a PCC, or by the PCE. There can be a number of triggers for this including user intervention and dynamic response to changes in traffic demands. 2. Decide what properties to assign to an LSP. This can include bandwidth reservations, priorities, and DSCP (i.e., MPLS Traffic Class field). This function is also determined by user configuration or in response to predicted or observed traffic demands. 3. Decide what traffic to put on the LSP. This is effectively determining which traffic flows to assign to which LSPs, and practically, this is closely linked to the first two decisions listed above. 4. Cause the LSP to be set up and modified to have the right characteristics. This will usually involve the PCE advising or instructing the PCC at the head end of the LSP, and the PCC will then signal the LSP across the network. 5. Tell the head end of the LSP what traffic to put on the LSP. This may happen after or at the same time as the LSP is set up. This step is the subject of this document. Dhody, et al. Expires May 3, 2021 [Page 6] Internet-Draft PCEP-FlowSpec October 2020 3.2. Elements of Procedure There are three elements of procedure: o A PCE and a PCC must be able to indicate whether or not they support the use of Flow Specifications. o A PCE or PCC must be able to include Flow Specifications in PCEP messages with clear understanding of the applicability of those Flow Specifications in each case. This includes whether the use of such information is mandatory, constrained, or optional, and how overlapping Flow Specifications will be resolved. o Flow Specification information/state must be synchronized between PCEP peers so that, on recovery, the peers have the same understanding of which Flow Specifications apply just as is required in the case of stateful PCE and LSP delegation (see Section 5.6 of [RFC8231]). The following subsections describe these points. 3.2.1. Capability Advertisement As with most PCEP capability advertisements, the ability to support Flow Specifications can be indicated in the PCEP OPEN message or in IGP PCE capability advertisements. 3.2.1.1. PCEP OPEN Message During PCEP session establishment, a PCC or PCE that supports the procedures described in this document announces this fact by including the "PCE FlowSpec Capability" TLV (described in Section 4) in the OPEN Object carried in the PCEP Open message. The presence of the PCE FlowSpec Capability TLV in the OPEN Object in a PCE's OPEN message indicates that the PCE can distribute FlowSpecs to PCCs and can receive FlowSpecs in messages from PCCs. The presence of the PCE FlowSpec Capability TLV in the OPEN Object in a PCC's OPEN message indicates that the PCC supports the FlowSpec functionality described in this document. If either one of a pair of PCEP peers does not include the PCE FlowSpec Capability TLV in the OPEN Object in its OPEN message, then the other peer MUST NOT include a FLOWSPEC object in any PCEP message sent to the peer. If a FLOWSPEC object is received when support has not been indicated, the receiver will respond with a PCErr message reporting the objects containing the FlowSpec as described in Dhody, et al. Expires May 3, 2021 [Page 7] Internet-Draft PCEP-FlowSpec October 2020 [RFC5440]: that is, it will use 'Unknown Object' if it does not support this specification, and 'Not supported object' if it supports this specification but has not chosen to support FLOWSPEC objects on this PCEP session. 3.2.1.2. IGP PCE Capabilities Advertisement The ability to advertise support for PCEP and PCE features in IGP advertisements is provided for OSPF in [RFC5088] and for IS-IS in [RFC5089]. The mechanism uses the PCE Discovery TLV which has a PCE- CAP-FLAGS sub-TLV containing bit-flags each of which indicates support for a different feature. This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSpec Capable flag (bit number TBD1). Setting the bit indicates that an advertising PCE supports the procedures defined in this document. Note that while PCE FlowSpec Capability may be advertised during discovery, PCEP speakers that wish to use Flow Specification in PCEP MUST negotiate PCE FlowSpec Capability during PCEP session setup, as specified in Section 3.2.1.1. A PCC MAY initiate PCE FlowSpec Capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisement, and a PCEP peer that advertised support for FlowSpec in the IGP is not obliged to support these procedures on any given PCEP session. 3.2.2. Dissemination Procedures This section describes the procedures to support Flow Specifications in PCEP messages. The primary purpose of distributing Flow Specification information is to allow a PCE to indicate to a PCC what traffic it should place on a path (such as an LSP or an SR path). This means that the Flow Specification may be included in: o PCInitiate messages so that an active PCE can indicate the traffic to place on a path at the time that the PCE instantiates the path. o PCUpd messages so that an active PCE can indicate or change the traffic to place on a path that has already been set up. o PCRpt messages so that a PCC can report the traffic that the PCC will place on the path. o PCReq messages so that a PCC can indicate what traffic it plans to place on a path at the time it requests the PCE to perform a computation in case that information aids the PCE in its work. Dhody, et al. Expires May 3, 2021 [Page 8] Internet-Draft PCEP-FlowSpec October 2020 o PCRep messages so that a PCE that has been asked to compute a path can suggest which traffic could be placed on a path that a PCC may be about to set up. o PCErr messages so that issues related to paths and the traffic they carry can be reported to the PCE by the PCC, and so that problems with other PCEP messages that carry Flow Specifications can be reported. To carry Flow Specifications in PCEP messages, this document defines a new PCEP object called the PCEP FLOWSPEC object. The object is OPTIONAL in the messages described above and MAY appear more than once in each message. To describe a traffic flow, the PCEP FLOWSPEC object carries one of the following combinations of TLVs: o zero or one Flow Filter TLV o one L2 Flow Filter TLV o both a Flow Filter TLV and an L2 Flow Filter TLV The inclusion of multiple PCEP FLOWSPEC objects allows multiple traffic flows to be placed on a single path. Once a PCE and PCC have established that they can both support the use of Flow Specifications in PCEP messages, such information may be exchanged at any time for new or existing paths. The application and prioritization of Flow Specifications is described in Section 8.7. As per [RFC8231], any attributes of the path received from a PCE are subject to PCC's local policy. This holds good for the Flow Specifications as well. 3.2.3. Flow Specification Synchronization The Flow Specifications are carried along with the LSP State information as per [RFC8231] making the Flow Specifications part of the LSP database (LSP-DB). Thus, the synchronization of the Flow Specification information is done as part of LSP-DB synchronization. This may be achieved using normal state synchronization procedures as described in [RFC8231] or enhanced state synchronization procedures as defined in [RFC8232]. Dhody, et al. Expires May 3, 2021 [Page 9] Internet-Draft PCEP-FlowSpec October 2020 The approach selected will be implementation and deployment specific and will depend on issues such as how the databases are constructed and what level of synchronization support is needed. 4. PCE FlowSpec Capability TLV The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be carried in the OPEN Object [RFC5440] to exchange PCE FlowSpec capabilities of the PCEP speakers. The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD2 | Length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value=0 | Padding | +---------------------------------------------------------------+ Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format The type of the PCE-FLOWSPEC-CAPABILITY TLV is TBD2 and it has a fixed length of 2 octets. The Value field MUST be set to 0 and MUST be ignored on receipt. The two bytes of padding MUST be set to zero and ignored on receipt. The inclusion of this TLV in an OPEN object indicates that the sender can perform FlowSpec handling as defined in this document. 5. PCEP FLOWSPEC Object The PCEP FLOWSPEC object defined in this document is compliant with the PCEP object format defined in [RFC5440]. It is OPTIONAL in the PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be present zero, one, or more times. Each instance of the object specifies a separate traffic flow. The PCEP FLOWSPEC object carries a FlowSpec filter rule encoded in a TLV (a Flow Filter TLV, a single L2 Flow Filter TLV, or both) as defined in Section 6). The FLOWSPEC Object-Class is TBD3 (to be assigned by IANA). The FLOWSPEC Object-Type is 1. Dhody, et al. Expires May 3, 2021 [Page 10] Internet-Draft PCEP-FlowSpec October 2020 The format of the body of the PCEP FLOWSPEC object is shown in Figure 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FS-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | Reserved | Flags |L|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PCEP FLOWSPEC Object Body Format FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec information. A PCE or PCC creates an FS-ID for each FlowSpec that it originates, and the value is unique within the scope of that PCE or PCC and is constant for the lifetime of a PCEP session. All subsequent PCEP messages can identify the FlowSpec using the FS-ID. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Note that [I-D.gont-numeric-ids-sec-considerations] gives advice on assigning transient numeric identifiers such as the FS-ID so as to minimise security risks. AFI (16-bits): Address Family Identifier as used in BGP [RFC4760] (AFI=1 for IPv4 or VPNv4, AFI=2 for IPv6 and VPNv6 as per as per [I-D.ietf-idr-flow-spec-v6]). Reserved (8-bits): MUST be set to zero on transmission and ignored on receipt. Flags (8-bits): Two flags are currently assigned - R bit: The Remove bit is set when a PCEP FLOWSPEC object is included in a PCEP message to indicate removal of the Flow Specification from the associated tunnel. If the bit is clear, the Flow Specification is being added or modified. L bit: The Longest Prefix Match (LPM) bit is set to indicate that the Flow Specification is to be installed as a route subject to longest prefix match forwarding. If the bit is clear, the Flow Specification described by the Flow Filter TLV (see Section 6) is to be installed as a Flow Specification. If the bit is set, only Dhody, et al. Expires May 3, 2021 [Page 11] Internet-Draft PCEP-FlowSpec October 2020 Flow Specifications that describe IPv4 or IPv6 destinations are meaningful in the Flow Filter TLV and others are ignored. If the L is set and the receiver does not support the use of Flow Specifications that are present in the Flow Filter TLV for the installation of a route subject to longest prefix match forwarding, then the PCEP peer MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error) and error-value 5 (Unsupported LPM Route). Unassigned bits MUST be set to zero on transmission and ignored on receipt. If the PCEP speaker receives a message with R bit set in the FLOWSPEC object and the Flow Specification identified with a FS-ID does not exist, it MUST generate a PCErr with Error-type TBD8 (FlowSpec Error), error-value 4 (Unknown FlowSpec). If the PCEP speaker does not understand or support the AFI in the FLOWSPEC message, the PCEP peer MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). The following TLVs can be used in the FLOWSPEC object: o Speaker Entity Identifier TLV: As specified in [RFC8232], the SPEAKER-ENTITY-ID TLV encodes a unique identifier for the node that does not change during the lifetime of the PCEP speaker. This is used to uniquely identify the FlowSpec originator and thus used in conjunction with FS-ID to uniquely identify the FlowSpec information. This TLV MUST be included. If the TLV is missing, the PCEP peer MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). If more than one instance of this TLV is present, the first MUST be processed and subsequence instances MUST be ignored. o Flow Filter TLV (variable): One TLV MAY be included. The Flow Filter TLV is OPTIONAL when the R bit is set. o L2 Flow Filter TLV (variable): One TLV MAY be included. The L2 Flow Filter TLV is OPTIONAL when the R bit is set. At least one Flow Filter TLV or one L2 Flow Filter TLV MUST be present when the R bit is clear. If both TLVs are missing when the R bit is clear, the PCEP peer MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error) and error-value 2 (Malformed FlowSpec). A Flow Filter TLV and a L2 Flow Filter TLV MAY both be present when filtering is based on both L3 and L2 fields. Dhody, et al. Expires May 3, 2021 [Page 12] Internet-Draft PCEP-FlowSpec October 2020 6. Flow Filter TLV and L2 Flow Filter TLV Two new PCEP TLVs are defined to convey Flow Specification filtering rules that specify what traffic is carried on a path. The TLVs follow the format of all PCEP TLVs as defined in [RFC5440]. The Type field values come from the codepoint space for PCEP TLVs and has the value TBD4 for Flow Filter TLV and TBD9 for L2 Flow Filter TLV. The Value fields of the TLVs contain one or more sub-TLVs (the Flow Specification TLVs or L2 Flow Specification TLVs) as defined in Section 7, and they represent the complete definition of a Flow Specification for traffic to be placed on the tunnel. This tunnel is indicated by the PCEP message in which the PCEP FLOWSPEC object is carried. The set of Flow Specification TLVs and L2 Flow Filter TLVs in a single instance of a Flow Filter TLV are combined to indicate the specific Flow Specification. Note that the PCEP FLOWSPEC object can include just one Flow Filter TLV, just one L2 Flow Filter TLV, or one of each TLV. Further Flow Specifications can be included in a PCEP message by including additional FLOWSPEC objects. 7. Flow Specification TLVs The Flow Filter TLV carries one or more Flow Specification TLVs. The Flow Specification TLV follows the format of all PCEP TLVs as defined in [RFC5440]. However, the Type values are selected from a separate IANA registry (see Section 10.3) rather than from the common PCEP TLV registry. Type values are chosen so that there can be commonality with Flow Specifications defined for use with BGP [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6]. This is possible because the BGP Flow Spec encoding uses a single octet to encode the type where as PCEP uses two octets. Thus the space of values for the Type field is partitioned as shown in Figure 3. Dhody, et al. Expires May 3, 2021 [Page 13] Internet-Draft PCEP-FlowSpec October 2020 Range | ---------------+--------------------------------------------------- 0 .. 255 | Per BGP registry defined by | [I-D.ietf-idr-rfc5575bis] and | [I-D.ietf-idr-flow-spec-v6]. | Not to be allocated in this registry. | 256 .. 65535 | New PCEP Flow Specifications allocated according | to the registry defined in this document. Figure 3: Flow Specification TLV Type Ranges [I-D.ietf-idr-rfc5575bis] is the reference for the registry "Flow Spec Component Types" and defines the allocations it contains. [I-D.ietf-idr-flow-spec-v6] requested for another registry "Flow Spec IPv6 Component Types" and requested initial allocations in it. If the AFI (in the FLOWSPEC object) is set to IPv4, the range 0..255 is as per "Flow Spec Component Types" [I-D.ietf-idr-rfc5575bis]; if the AFI is set to IPv6, the range 0..255 is as per "Flow Spec IPv6 Component Types" [I-D.ietf-idr-flow-spec-v6]. The content of the Value field in each TLV is specific to the type/ AFI and describes the parameters of the Flow Specification. The definition of the format of many of these Value fields is inherited from BGP specifications. Specifically, the inheritance is from [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6], but may also be inherited from future BGP specifications. When multiple Flow Specification TLVs are present in a single Flow Filter TLV they are combined to produce a more detailed specification of a flow. For examples and rules about how this is achieved, see [I-D.ietf-idr-rfc5575bis]. As described in [I-D.ietf-idr-rfc5575bis] where it says "A given component type MAY (exactly once) be present in the Flow Specification," a Flow Filter TLV MUST NOT contain more than one Flow Specification TLV of the same type: an implementation that receives a PCEP message with a Flow Flter TLV that contains more than one Flow Specification TLV of the same type MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec) and MUST NOT install the Flow Specification. An implementation that receives a PCEP message carrying a Flow Specification TLV with a type value that it does not recognize or does not support MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST NOT install the Flow Specification. Dhody, et al. Expires May 3, 2021 [Page 14] Internet-Draft PCEP-FlowSpec October 2020 When used in other protocols (such as BGP), these Flow Specifications are also associated with actions to indicate how traffic matching the Flow Specification should be treated. In PCEP, however, the only action is to associate the traffic with a tunnel and to forward matching traffic onto that path, so no encoding of an action is needed. Section 8.7 describes how overlapping Flow Specifications are prioritized and handled. All Flow Specification TLVs with Types in the range 0 to 255 have Values defined for use in BGP (for example, in [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6]) and are set using the BGP encoding, but without the type octet (the relevant information is in the Type field of the TLV). The Value field is padded with trailing zeros to achieve 4-byte alignment. This document defines the following new types: +-------+-------------------------+-----------------------------+ | Type | Description | Value defined in | | | | | +-------+-------------------------+-----------------------------+ | TBD5 | Route Distinguisher | [This.I-D] | +-------+-------------------------+-----------------------------+ | TBD6 | IPv4 Multicast Flow | [This.I-D] | +-------+-------------------------+-----------------------------+ | TBD7 | IPv6 Multicast Flow | [This.I-D] | +-------+-------------------------+-----------------------------+ Figure 4: Table of Flow Specification TLV Types defined in this document To allow identification of a VPN in PCEP via a Route Distinguisher (RD) [RFC4364], a new TLV - ROUTE-DISTINGUISHER TLV is defined in this document. A Flow Specification TLV with Type TBD5 (ROUTE- DISTINGUISHER TLV) carries an RD Value, used to identify that other flow filter information (for example, an IPv4 destination prefix) is associated with a specific VPN identified by the RD. See Section 8.6 for further discussion of VPN identification. Dhody, et al. Expires May 3, 2021 [Page 15] Internet-Draft PCEP-FlowSpec October 2020 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=[TBD5] | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The Format of the ROUTE-DISTINGUISHER TLV The format of RD is as per [RFC4364]. Although it may be possible to describe a multicast Flow Specification from the combination of other Flow Specification TLVs with specific values, it is more convenient to use a dedicated Flow Specification TLV. Flow Specification TLVs with Type values TBD6 and TBD7 are used to identify a multicast flow for IPv4 and IPv6 respectively. The Value field is encoded as shown in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |S|G| Src Mask Len | Grp Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Source Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Group multicast Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Multicast Flow Specification TLV Encoding The address fields and address mask lengths of the two Multicast Flow Specification TLVs contain source and group prefixes for matching against packet flows noting that the two address fields are 32 bits for an IPv4 Multicast Flow and 128 bits for an IPv6 Multicast Flow. The Reserved field MUST be set to zero and ignored on receipt. Two bit flags (S and G) are defined to describe the multicast wildcarding in use. If the S bit is set, then source wildcarding is in use and the values in the Source Mask Length and Source Address fields MUST be ignored. If the G bit is set, then group wildcarding is in use and the values in the Group Mask Length and Group multicast Address fields MUST be ignored. The G bit MUST NOT be set unless the Dhody, et al. Expires May 3, 2021 [Page 16] Internet-Draft PCEP-FlowSpec October 2020 S bit is also set: if a Multicast Flow Specification TLV is received with S bit = 0 and G bit = 1 the receiver MUST respond with a PCErr with Error-type TBD8 (FlowSpec Error) and error-value 2 (Malformed FlowSpec). The three multicast mappings may be achieved as follows: (S, G) - S bit = 0, G bit = 0, the Source Address and Group multicast Address prefixes are both used to define the multicast flow. (*, G) - S bit = 1, G bit = 0, the Group multicast Address prefix is used to define the multicast flow, but the Source Address prefix is ignored. (*, *) = S bit = 1, G bit = 1, the Source Address and Group multicast Address prefixes are both ignored. 7.1. L2 Flow Specification TLVs The L2 Flow Filter TLV carries one or more L2 Flow Specification TLV. The L2 Flow Specification TLV follows the format of all PCEP TLVs as defined in [RFC5440]. However, the Type values are selected from a separate IANA registry (see Section 10.4) rather than from the common PCEP TLV registry. Type values are chosen so that there can be commonality with L2 Flow Specifications defined for use with BGP [I-D.ietf-idr-flowspec-l2vpn]. This is possible because the BGP Flow Spec encoding uses a single octet to encode the type where as PCEP uses two octets. Thus the space of values for the Type field is partitioned as shown in Figure 7. Range | ---------------+------------------------------------------------- 0 .. 255 | Per BGP registry defined by | [I-D.ietf-idr-flowspec-l2vpn]. | Not to be allocated in this registry. | 256 .. 65535 | New PCEP Flow Specifications allocated according | to the registry defined in this document. Figure 7: L2 Flow Specification TLV Type Ranges [I-D.ietf-idr-flowspec-l2vpn] is the reference for the registry "L2 Flow Spec Component Types" and defines the allocations it contains. Dhody, et al. Expires May 3, 2021 [Page 17] Internet-Draft PCEP-FlowSpec October 2020 The content of the Value field in each TLV is specific to the type and describes the parameters of the Flow Specification. The definition of the format of many of these Value fields is inherited from BGP specifications. Specifically, the inheritance is from [I-D.ietf-idr-flowspec-l2vpn], but may also be inherited from future BGP specifications. When multiple L2 Flow Specification TLVs are present in a single L2 Flow Filter TLV they are combined to produce a more detailed specification of a flow. Similarly, when both Flow Filter TLV and L2 Flow Filter TLV are present, they are combined to produce a more detailed specification of a flow. An implementation that receives a PCEP message carrying a L2 Flow Specification TLV with a type value that it does not recognize or does not support MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST NOT install the Flow Specification. All L2 Flow Specification TLVs with Types in the range 0 to 255 have their Values interpretted as defined for use in BGP (for example, in [I-D.ietf-idr-flowspec-l2vpn]) and are set using the BGP encoding, but without the type octet (the relevant information is in the Type field of the TLV). The Value field is padded with trailing zeros to achieve 4-byte alignment. This document defines no new types. In the rest of the document when the Flow Specification is mentioned, it includes the L2 Flow Specifications as well. 8. Detailed Procedures This section outlines some specific detailed procedures for using the protocol extensions defined in this document. 8.1. Default Behavior and Backward Compatibility The default behavior is that no Flow Specification is applied to a tunnel. That is, the default is that the FLOWSPEC object is not used as is the case in all systems before the implementation of this specification. In this case, it is a local matter (such as through configuration) how tunnel head ends are instructed what traffic to place on a tunnel. Dhody, et al. Expires May 3, 2021 [Page 18] Internet-Draft PCEP-FlowSpec October 2020 [RFC5440] describes how receivers respond when they see unknown PCEP objects. 8.2. Composite Flow Specifications Flow Specifications may be represented by a single Flow Specification TLV or may require a more complex description using multiple Flow Specification TLVs. For example, a flow indicated by a source- destination pair of IPv6 addresses would be described by the combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow Specification TLVs. 8.3. Modifying Flow Specifications A PCE may want to modify a Flow Specification associated with a tunnel, or a PCC may want to report a change to the Flow Specification it is using with a tunnel. It is important that the specific Flow Specification is identified so that it is clear that this is a modification of an existing flow and not the addition of a new flow as described in Section 8.4. The FS- ID field of the PCEP FLOWSPEC object is used to identify a specific Flow Specification in the context of the content of the Speaker Entity Identifier TLV. When modifying a Flow Specification, all Flow Specification TLVs for the intended specification of the flow MUST be included in the PCEP FLOWSPEC object. the FS-ID MUST be retained from the previous description of the flow, and the same Speaker Entity Identity TLV MUST be used. 8.4. Multiple Flow Specifications It is possible that traffic from multiple flows will be placed on a single tunnel. In some cases it is possible to define these within a single PCEP FLOWSPEC object by widening the scope of a Flow Specification TLV: for example, traffic to two destination IPv4 prefixes might be captured by a single Flow Specification TLV with type 'Destination' with a suitably adjusted prefix. However, this is unlikely to be possible in most scenarios, and it must be recalled that it is not permitted to include two Flow Specification TLVs of the same type within one Flow Filter TLV. The normal procedure, therefore, is to carry each Flow Specification in its own PCEP FLOWSPEC object. Multiple objects may be present on a single PCEP message, or multiple PCEP messages may be used. Dhody, et al. Expires May 3, 2021 [Page 19] Internet-Draft PCEP-FlowSpec October 2020 8.5. Adding and Removing Flow Specifications The Remove bit in the PCEP FLOWSPEC object is left clear when a Flow Specification is being added or modified. To remove a Flow Specification, a PCEP FLOWSPEC object is included with the FS-ID matching the one being removed, and the R bit set to indicate removal. In this case it is not necessary to include any Flow Specification TLVs. If the R bit is set and Flow Specification TLVs are present, an implementation MAY ignore them. If the implementation checks the Flow Specification TLVs against those recorded for the FS-ID and Speaker Entity Identity of the Flow Specification being removed and finds a mismatch, the Flow Specification matching the FS-ID MUST still be removed and the implementation SHOULD record a local exception or log. 8.6. VPN Identifiers VPN instances are identified in BGP using Route Distinguishers (RDs) [RFC4364]. These values are not normally considered to have any meaning outside of the network, and they are not encoded in data packets belonging to the VPNs. However, RDs provide a useful way of identifying VPN instances and are often manually or automatically assigned to VPNs as they are provisioned. Thus the RD provides a useful way to indicate that traffic for a particular VPN should be placed on a given tunnel. The tunnel head end will need to interpret this Flow Specification not as a filter on the fields of data packets, but using the other mechanisms that it already uses to identify VPN traffic. This could be based on the incoming port (for port-based VPNs) or may leverage knowledge of the VRF that is in use for the traffic. 8.7. Priorities and Overlapping Flow Specifications Flow specifications can overlap. For example, two different flow specifications may be identical except for the length of the prefix in the destination address. In these cases the PCC must determine how to prioritize the flow specifications so as to know to which path to assign packets that match both flow specifications. That is, the PCC must assign a precedence to the flow specifications so that it checks each incoming packet for a match in a predictable order. The processing of BGP Flow Specifications is described in [I-D.ietf-idr-rfc5575bis]. Section 5.1 of that document explains the Dhody, et al. Expires May 3, 2021 [Page 20] Internet-Draft PCEP-FlowSpec October 2020 order of traffic filtering rules to be executed by an implementation of that specification. PCCs MUST apply the same ordering rules as defined in [I-D.ietf-idr-rfc5575bis]. Furthermore, it is possible that Flow Specifications will be distributed by BGP as well as by PCEP as described in this document. In such cases implementations supporting both approaches MUST apply the prioritization and ordering rules as set out in [I-D.ietf-idr-rfc5575bis] regardless of which protocol distributed the Flow Specifications. However, implementations MAY provide a configuration control to allow one protocol to take precedence over the other as this may be particularly useful if the Flow Specifications make identical matches on traffic, but have different actions. It is RECOMMENDED that when two Flow Specifications distributed by different protocols overlap, and especially when one acts to replace another, that a message be logged for the operator to understand the behaviour. Section 13.1 of this document covers manageability considerations relevant to the prioritized ordering of flow specifications. An implementation that receives a PCEP message carrying a Flow Specification that it cannot resolve against other Flow Specifications already installed (for example, because the new Flow Specification has irresolvable conflicts with other Flow Specifications that are already installed) MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable Conflict) and MUST NOT install the Flow Specification. 9. PCEP Messages This section describes the format of messages that contain FLOWSPEC objects. The only difference to previous message formats is the inclusion of that object. The figures in this section use the notation defined in [RFC5511]. The FLOWSPEC object is OPTIONAL and MAY be carried in the PCEP messages. The PCInitiate message is defined in [RFC8281] and updated as below: Dhody, et al. Expires May 3, 2021 [Page 21] Internet-Draft PCEP-FlowSpec October 2020 ::= Where: ::= [] ::= ( | ) ::= [] [] [] Where: ::= [] The PCUpd message is defined in [RFC8231] and updated as below: ::= Where: ::= [] ::= [] Where: ::= ::= [] The PCRpt message is defined in [RFC8231] and updated as below: Dhody, et al. Expires May 3, 2021 [Page 22] Internet-Draft PCEP-FlowSpec October 2020 ::= Where: ::= [] ::= [] [] Where: ::= [] ::= [] The PCReq message is defined in [RFC5440] and updated in [RFC8231], it is further updated below for flow specification: ::= [] Where: ::= [] ::= [] ::= [] [] [] [] [[]] [] [] [] Where: ::= [] Dhody, et al. Expires May 3, 2021 [Page 23] Internet-Draft PCEP-FlowSpec October 2020 The PCRep message is defined in [RFC5440] and updated in [RFC8231], it is further updated below for flow specification: ::= Where: ::=[] ::= [] [] [] [] [] Where: ::= [] 10. IANA Considerations IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry. This document requests IANA actions to allocate code points for the protocol elements defined in this document. 10.1. PCEP Objects Each PCEP object has an Object-Class and an Object-Type. IANA maintains a subregistry called "PCEP Objects". IANA is requested to make an assignment from this subregistry as follows: Object-Class | Value Name | Object-Type | Reference -------------+-------------+------------------------+---------------- TBD3 | FLOWSPEC | 0: Reserved | [This.I-D] | | 1: Flow Specification | [This.I-D] 10.1.1. PCEP FLOWSPEC Object Flag Field This document requests that a new sub-registry, named "FLOWSPEC Object Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the FLOWSPEC object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: Dhody, et al. Expires May 3, 2021 [Page 24] Internet-Draft PCEP-FlowSpec October 2020 o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The initial population of this registry is as follows: Bit | Description | Reference -----+--------------------+------------- 0-5 | Unnassigned | 6 | LPM (L bit) | [This.I-D] 7 | Remove (R bit) | [This.I-D] 10.2. PCEP TLV Type Indicators IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA is requested to make an assignment from this subregistry as follows: Value | Meaning | Reference --------+------------------------------+------------- TBD2 | PCE-FLOWSPEC-CAPABILITY TLV | [This.I-D] TBD4 | FLOW FILTER TLV | [This.I-D] TBD9 | L2 FLOW FILTER TLV | [This.I-D] 10.3. Flow Specification TLV Type Indicators IANA is requested to create a new subregistry call the "PCEP Flow Specification TLV Type Indicators" registry. Allocations from this registry are to be made according to the following assignment policies [RFC8126]: Dhody, et al. Expires May 3, 2021 [Page 25] Internet-Draft PCEP-FlowSpec October 2020 Range | Assignment policy ---------------+--------------------------------------------------- 0 .. 255 | Reserved - must not be allocated. | Usage mirrors the BGP FlowSpec registry | [I-D.ietf-idr-rfc5575bis] and | [I-D.ietf-idr-flow-spec-v6]. | 256 .. 64506 | Specification Required | 64507 .. 65531 | First Come First Served | 65532 .. 65535 | Experimental IANA is requested to pre-populate this registry with values defined in this document as follows, taking the new values from the range 256 to 64506: Value | Meaning -------+------------------------ TBD5 | Route Distinguisher TBD6 | IPv4 Multicast TBD7 | IPv6 Multicast 10.4. L2 Flow Specification TLV Type Indicators IANA is requested to create a new subregistry called the "PCEP L2 Flow Specification TLV Type Indicators" registry. Allocations from this registry are to be made according to the following assignment policies [RFC8126]: Range | Assignment policy ---------------+--------------------------------------------------- 0 .. 255 | Reserved - must not be allocated. | Usage mirrors the BGP L2 FlowSpec registry | [I-D.ietf-idr-flowspec-l2vpn]. | 256 .. 64506 | Specification Required | 64507 .. 65531 | First Come First Served | 65532 .. 65535 | Experimental Dhody, et al. Expires May 3, 2021 [Page 26] Internet-Draft PCEP-FlowSpec October 2020 10.5. PCEP Error Codes IANA maintains a subregistry called "PCEP-ERROR Object Error Types and Values". Entries in this subregistry are described by Error-Type and Error-value. IANA is requested to make the following assignment from this subregistry: Error-| Meaning | Error-value | Reference Type | | | -------+--------------------+----------------------------+----------- TBD8 | FlowSpec error | 0: Unassigned | [This.I-D] | | 1: Unsupported FlowSpec | [This.I-D] | | 2: Malformed FlowSpec | [This.I-D] | | 3: Unresolvable Conflict | [This.I-D] | | 4: Unknown FlowSpec | [This.I-D] | | 5: Unsupported LPM Route | [This.I-D] | | 6-255: Unassigned | [This.I-D] 10.6. PCE Capability Flag IANA maintains a subregistry called "Open Shortest Path First v2 (OSPFv2) Parameters" with a sub-registry called "Path Computation Element (PCE) Capability Flags". IANA is requested to assign a new capability bit from this registry as follows: Bit | Capability Description | Reference -------+-------------------------------+------------ TBD1 | FlowSpec | [This.I-D] 11. Implementation Status [NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942 is to be removed before publication as an RFC] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their Dhody, et al. Expires May 3, 2021 [Page 27] Internet-Draft PCEP-FlowSpec October 2020 features. Readers are advised to note that other implementations may exist. According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". At the time of posting the -12 version of this document, there are no known implementations of this mechanism. It is believed that two vendors are considering prototype implementations, but these plans are too vague to make any further assertions. 12. Security Considerations We may assume that a system that utilizes a remote PCE is subject to a number of vulnerabilities that could allow spurious LSPs or SR paths to be established or that could result in existing paths being modified or torn down. Such systems, therefore, apply security considerations as described in [RFC5440], Section 2.5 of [RFC6952], [RFC8253], and [I-D.ietf-idr-rfc5575bis]. The description of Flow Specifications associated with paths set up or controlled by a PCE add a further detail that could be attacked without tearing down LSPs or SR paths, but causing traffic to be misrouted within the network. Therefore, the use of the security mechanisms for PCEP referenced above is important. Visibility into the information carried in PCEP does not have direct privacy concerns for end-users' data, however, knowledge of how data is routed in a network may make that data more vulnerable. Of course, the ability to interfere with the way data is routed also makes the data more vulnerable. Furthermore, knowledge of the connected end-points (such as multicast receivers or VPN sites) is usually considered private customer information. Therefore, implementations or deployments concerned with protecting privacy MUST apply the mechanisms described in the documents referenced above: in particular to secure the PCEP session using IPSec per Sections 10.4 to 10.6 of [RFC5440] or TLS per [RFC8253]. Note that TCP-MD5 security as originally suggested in [RFC5440] does not provide sufficient security or privacy guarantees, and SHOULD NOT be relied upon. Experience with Flow Specifications in BGP systems indicates that they can become complex and that the overlap of Flow Specifications installed in different orders can lead to unexpected results. Dhody, et al. Expires May 3, 2021 [Page 28] Internet-Draft PCEP-FlowSpec October 2020 Although this is not directly a security issue per se, the confusion and unexpected forwarding behavior may be engineered or exploited by an attacker. Furthermore, this complexity might give rise to a situation where the forwarding behaviors might create gaps in the monitoring and inspection of particular traffic or provide a path that avoids expected mitigations. Therefore, implementers and operators SHOULD pay careful attention to the Manageability Considerations described in Section 13 and familiarize themselves with the careful explanations in [I-D.ietf-idr-rfc5575bis]. 13. Manageability Considerations The feature introduced by this document enables operational manageability of networks operated in conjunction with a PCE and using PCEP. Without this feature, but in the case of a stateful active PCE or with PCE-initiated services, additional manual configuration is needed to tell the head-ends what traffic to place on the network services (LSPs, SR paths, etc.). This section follows the advice and guidance of [RFC6123]. 13.1. Management of Multiple Flow Specifications Experience with flow specification in BGP suggests that there can be a lot of complexity when two or more flow specifications overlap. This can arise, for example, with addresses indicated using prefixes, and could cause confusion about what traffic should be placed on which path. Unlike the behavior in a distributed routing system, it is not important to the routing stablity and consistency of the network that each head-end implementation applies the same rules to disambiguate overlapping Flow Specifications, but it is important that: o A network operator can easily find out what traffic is being placed on which path and why. This will facilitate analysis of the network and diagnosis of faults. o A PCE is able to correctly predict the effect of instructions it gives to a PCC. This will ensure that traffic is correctly placed on the network without causing congestion or other network inefficiencies, and that traffic is correctly delivered. To that end, a PCC MUST enable an operator to view the the Flow Specifications that it has installed, and these MUST be presented in order of precedence such that when two Flow Specifications overlap, the one that will be serviced with higher precedence is presented to the operator first. Dhody, et al. Expires May 3, 2021 [Page 29] Internet-Draft PCEP-FlowSpec October 2020 A discussion of precedence ordering for flow specifications is found in Section 8.7. 13.2. Control of Function through Configuration and Policy Support for the function described in this document implies that a functional element that is capable of requesting a PCE to compute and control a path is also able to configure the specification of what traffic should be placed on that path. Where there is a human involved in this action, configuration of the Flow Specification must be available through an interface (such as a graphical user interface or a command line interface). Where a distinct software component (i.e., one not co-implemented with the PCE) is used, a protocol mechanism will be required that could be PCEP itself or could be a data model such as extensions to the YANG model for requesting path computation [I-D.ietf-teas-yang-path-computation]. Implementations MAY be constructed with a configurable switch to say whether they support the functions defined in this document. Otherwise, such implementations MUST indicate that they support the function as described in Section 4. If an implementation supports configurable support of this function, that support MAY be configurable per peer or once for the whole implementation. As mentioned in Section 13.1, a PCE implementation SHOULD provide a mechanism to configure variations in the precedence ordering of Flow Specifications per PCC. 13.3. Information and Data Models The YANG model in [I-D.ietf-pce-pcep-yang] can be used to model and monitor PCEP states and messages. To make that YANG model useful for the extensions described in this document, it would need to be augmented to cover the new protocol elements. Similarly, as noted in Section 13.2, the YANG model defined in [I-D.ietf-teas-yang-path-computation] could be extended to allow specification of Flow Specifications. Finally, as mentioned in Section 13.1, a PCC implementation SHOULD provide a mechanism to allow an operator to read the Flow Specifications from a PCC and to understand in what order they will be executed. This could be achieved using a new YANG model. Dhody, et al. Expires May 3, 2021 [Page 30] Internet-Draft PCEP-FlowSpec October 2020 13.4. Liveness Detection and Monitoring The extensions defined in this document do not require any additional liveness detection and monitoring support. See [RFC5440] and [RFC5886] for more information. 13.5. Verifying Correct Operation The chief element of operation that needs to be verified (in addition to the operation of the protocol elements as described in [RFC5440]) is the installation, precedence, and correct operation of the Flow Specifications at a PCC. In addition to the YANG model for reading Flow Specifications described in Section 13.3, tools may be needed to inject Operations and Management (OAM) traffic at the PCC that matches specific criteria so that it can be monitored as traveling along the desired path. Such tools are outside the scope of this document. 13.6. Requirements on Other Protocols and Functional Components This document places no requirements on other protocols or components. 13.7. Impact on Network Operation The use of the features described in this document clearly have an important impact on network traffic since they cause traffic to be routed on specific paths in the network. However, in practice, these changes make no direct changes to the network operation because traffic is already placed on those paths using some pre-existing configuration mechanism. Thus, the significant change is the reduction in mechanisms that have to be applied, rather than a change to how the traffic is passed through the network. 14. Acknowledgements Thanks to Julian Lucek, Sudhir Cheruathur, Olivier Dugeon, Jayant Agarwal, Jeffrey Zhang, Acee Lindem, Vishnu Pavan Beeram, Julien Meuric, Deborah Brungard, Eric Vyncke, Erik Kline, Benjamin Kaduk, Martin Duke, Roman Danyliw, and Alvaro Retana for useful discussions and comments. 15. References Dhody, et al. Expires May 3, 2021 [Page 31] Internet-Draft PCEP-FlowSpec October 2020 15.1. Normative References [I-D.ietf-idr-flow-spec-v6] Loibl, C., Raszuk, R., and S. Hares, "Dissemination of Flow Specification Rules for IPv6", draft-ietf-idr-flow- spec-v6-17 (work in progress), October 2020. [I-D.ietf-idr-flowspec-l2vpn] Weiguo, H., Eastlake, D., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", draft- ietf-idr-flowspec-l2vpn-15 (work in progress), May 2020. [I-D.ietf-idr-rfc5575bis] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", draft-ietf-idr-rfc5575bis-27 (work in progress), October 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Dhody, et al. Expires May 3, 2021 [Page 32] Internet-Draft PCEP-FlowSpec October 2020 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, . [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . 15.2. Informative References [I-D.gont-numeric-ids-sec-considerations] Gont, F. and I. Arce, "Security Considerations for Transient Numeric Identifiers Employed in Network Protocols", draft-gont-numeric-ids-sec-considerations-05 (work in progress), July 2020. [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", draft-ietf-pce-pcep- yang-14 (work in progress), July 2020. [I-D.ietf-teas-yang-path-computation] Busi, I., Belotti, S., Lopez, V., Sharma, A., and Y. Shi, "Yang model for requesting Path Computation", draft-ietf- teas-yang-path-computation-10 (work in progress), July 2020. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . Dhody, et al. Expires May 3, 2021 [Page 33] Internet-Draft PCEP-FlowSpec October 2020 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, . [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, . [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, . [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, DOI 10.17487/RFC6123, February 2011, . [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, . [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, . Dhody, et al. Expires May 3, 2021 [Page 34] Internet-Draft PCEP-FlowSpec October 2020 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . Appendix A. Contributors Shankara Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: shankara@huawei.com Qiandeng Liang Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing 210012 China Email: liangqiandeng@huawei.com Cyril Margaria Juniper Networks 200 Somerset Corporate Boulevard, Suite 4001 Bridgewater, NJ 08807 USA Email: cmargaria@juniper.net Colby Barth Juniper Networks 200 Somerset Corporate Boulevard, Suite 4001 Bridgewater, NJ 08807 USA Email: cbarth@juniper.net Xia Chen Dhody, et al. Expires May 3, 2021 [Page 35] Internet-Draft PCEP-FlowSpec October 2020 Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jescia.chenxia@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Cheng Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: c.l@huawei.com Authors' Addresses Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Dhody, et al. Expires May 3, 2021 [Page 36] Internet-Draft PCEP-FlowSpec October 2020 Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Dhody, et al. Expires May 3, 2021 [Page 37] ./draft-ietf-perc-private-media-framework-12.txt0000644000764400076440000020627513476041557021054 0ustar iustyiusty Network Working Group P. Jones Internet-Draft Cisco Intended status: Standards Track D. Benham Expires: December 7, 2019 C. Groves Independent June 5, 2019 A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC) draft-ietf-perc-private-media-framework-12 Abstract This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the real-time transport protocol (RTP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 7, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Jones, et al. Expires December 7, 2019 [Page 1] Internet-Draft Private Media Framework June 2019 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. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. PERC Entities and Trust Model . . . . . . . . . . . . . . . . 5 3.1. Untrusted Entities . . . . . . . . . . . . . . . . . . . 5 3.1.1. Media Distributor . . . . . . . . . . . . . . . . . . 6 3.1.2. Call Processing . . . . . . . . . . . . . . . . . . . 7 3.2. Trusted Entities . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Endpoint . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Key Distributor . . . . . . . . . . . . . . . . . . . 7 4. Framework for PERC . . . . . . . . . . . . . . . . . . . . . 8 4.1. End-to-End and Hop-by-Hop Authenticated Encryption . . . 8 4.2. E2E Key Confidentiality . . . . . . . . . . . . . . . . . 9 4.3. E2E Keys and Endpoint Operations . . . . . . . . . . . . 10 4.4. HBH Keys and Per-hop Operations . . . . . . . . . . . . . 10 4.5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 11 4.5.1. Initial Key Exchange and Key Distributor . . . . . . 11 4.5.2. Key Exchange during a Conference . . . . . . . . . . 13 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Identity Assertions . . . . . . . . . . . . . . . . . . . 14 5.2. Certificate Fingerprints in Session Signaling . . . . . . 14 5.3. Conference Identification . . . . . . . . . . . . . . . . 15 6. PERC Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Key Inventory and Management Considerations . . . . . . . 15 6.2. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 16 6.3. The Key Distributor Transmits the KEK (EKT Key) . . . . . 17 6.4. Endpoints fabricate an SRTP Master Key . . . . . . . . . 18 6.5. Summary of Key Types and Entity Possession . . . . . . . 18 7. Encrypted Media Packet Format . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 20 8.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 21 8.2.1. Denial of service . . . . . . . . . . . . . . . . . . 21 8.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 22 8.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 22 8.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 23 8.2.5. RTCP Attacks . . . . . . . . . . . . . . . . . . . . 23 8.3. Key Distributor Attacks . . . . . . . . . . . . . . . . . 23 8.4. Endpoint Attacks . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 Jones, et al. Expires December 7, 2019 [Page 2] Internet-Draft Private Media Framework June 2019 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction Switched conferencing is an increasingly popular model for multimedia conferences with multiple participants using a combination of audio, video, text, and other media types. With this model, real-time media flows from conference participants are not mixed, transcoded, transrated, recomposed, or otherwise manipulated by a Media Distributor, as might be the case with a traditional media server or multipoint control unit (MCU). Instead, media flows transmitted by conference participants are simply forwarded by Media Distributors to each of the other participants. Media Distributors often forward only a subset of flows based on voice activity detection or other criteria. In some instances, Media Distributors may make limited modifications to RTP [RFC3550] headers, for example, but the actual media content (e.g., voice or video data) is unaltered. An advantage of switched conferencing is that Media Distributors can be more easily deployed on general-purpose computing hardware, including virtualized environments in private and public clouds. Virtualized public cloud environments have been viewed as less secure since resources are not always physically controlled by those who use them. This document defines improved security so as to lower the barrier to taking advantage of those environments. This document defines a solution framework wherein media privacy is ensured by making it impossible for a Media Distributor to gain access to keys needed to decrypt or authenticate the actual media content sent between conference participants. At the same time, the framework allows for the Media Distributors to modify certain RTP headers; add, remove, encrypt, or decrypt RTP header extensions; and encrypt and decrypt RTP Control Protocol (RTCP) [RFC3550] packets. The framework also prevents replay attacks by authenticating each packet transmitted between a given participant and the Media Distributor using a unique key per Endpoint that is independent from the key for media encryption and authentication. This solution framework provides for enhanced privacy in RTP-based conferencing environments while utilizing existing security procedures defined for RTP with minimal enhancements. Jones, et al. Expires December 7, 2019 [Page 3] Internet-Draft Private Media Framework June 2019 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Additionally, this solution framework uses the following terms and acronyms: End-to-End (E2E): Communications from one Endpoint through one or more Media Distributors to the Endpoint at the other end. Hop-by-Hop (HBH): Communications between an Endpoint and a Media Distributor or between Media Distributors. Trusted Endpoint (or simply Endpoint): An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption. This may include embedded user conferencing equipment or browsers on computers, media gateways, MCUs, media recording devices and more that are in the trusted domain for a given deployment. In the context of WebRTC [W3C.CR-webrtc-20180927], where control of a session is divided between a JavaScript application and a browser, the browser acts as the Trusted Endpoint for purposes of this framework (just as it acts as the endpoint for DTLS-SRTP [RFC5764] in one-to-one calls). Media Distributor (MD): An RTP middlebox that forwards Endpoint media content (e.g., voice or video data) unaltered, either a subset or all of the flows at any given time, and is never allowed to have access to E2E encryption keys. It operates according to the Selective Forwarding Middlebox RTP topologies [RFC7667] per the constraints defined by the PERC system, which includes, but is not limited to, having no access to RTP media plaintext and having limits on what RTP header field it can alter. The header fields that may be modified by a Media Distributor are enumerated in Section 4 of the Double cryptographic transform specification [I-D.ietf-perc-double] and chosen with respect to utility and the security considerations outlined in this document. Key Distributor: An entity that is a logical function which distributes keying material and related information to Trusted Endpoints and Media Distributor(s), only that which is appropriate for each. The Key Distributor might be co-resident with another entity trusted with E2E keying material. Jones, et al. Expires December 7, 2019 [Page 4] Internet-Draft Private Media Framework June 2019 Conference: Two or more participants communicating via Trusted Endpoints to exchange RTP flows through one or more Media Distributor. Call Processing: All Trusted Endpoints in the conference connect to it by a call processing dialog, such as with the Focus defined in the Framework for Conferencing with SIP [RFC4353]. Third Party: Any entity that is not an Endpoint, Media Distributor, Key Distributor or Call Processing entity as described in this document. 3. PERC Entities and Trust Model The following figure depicts the trust relationships, direct or indirect, between entities described in the subsequent sub-sections. Note that these entities may be co-located or further divided into multiple, separate physical devices. Please note that some entities classified as untrusted in the simple, general deployment scenario used most commonly in this document might be considered trusted in other deployments. This document does not preclude such scenarios, but keeps the definitions and examples focused by only using the simple, most general deployment scenario. | +----------+ | +-----------------+ | Endpoint | | | Call Processing | +----------+ | +-----------------+ | | +----------------+ | +--------------------+ | Key Distributor| | | Media Distributor | +----------------+ | +--------------------+ | Trusted | Untrusted Entities | Entities | Figure 1: Trusted and Untrusted Entities in PERC 3.1. Untrusted Entities The architecture described in this framework document enables conferencing infrastructure to be hosted in domains, such as in a cloud conferencing provider's facilities, where the trustworthiness is below the level needed to assume the privacy of participant's Jones, et al. Expires December 7, 2019 [Page 5] Internet-Draft Private Media Framework June 2019 media is not compromised. The conferencing infrastructure in such a domain is still trusted with reliably connecting the participants together in a conference, but not trusted with keying material needed to decrypt any of the participant's media. Entities in such lower trustworthiness domains are referred to as untrusted entities from this point forward. It is important to understand that untrusted in this document does not mean an entity is not expected to function properly. Rather, it means only that the entity does not have access to the E2E media encryption keys. 3.1.1. Media Distributor A Media Distributor forwards RTP flows between Endpoints in the conference while performing per-hop authentication of each RTP packet. The Media Distributor may need access to one or more RTP headers or header extensions, potentially adding or modifying a certain subset. The Media Distributor also relays secured messaging between the Endpoints and the Key Distributor and acquires per-hop key information from the Key Distributor. The actual media content must not be decryptable by a Media Distributor, as it is untrusted to have access to the E2E media encryption keys. The key exchange mechanisms specified in this framework prevent the Media Distributor from gaining access to the E2E media encryption keys. An Endpoint's ability to connect to a conference serviced by a Media Distributor does imply that the Endpoint is authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an Endpoint is authorized. Instead, the Key Distributor is responsible for authenticating the Endpoint (e.g., using WebRTC Identity [I-D.ietf-rtcweb-security-arch]) and determining its authorization to receive E2E and HBH media encryption keys. A Media Distributor must perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects of denial of service attacks (refer to Section 8) to a level equal to or better than traditional conferencing (non-PERC) deployments. A Media Distributor or associated conferencing infrastructure may also initiate or terminate various conference control related messaging, which is outside the scope of this framework document. Jones, et al. Expires December 7, 2019 [Page 6] Internet-Draft Private Media Framework June 2019 3.1.2. Call Processing The call processing function is untrusted in the simple, general deployment scenario. When a physical subset of the call processing function resides in facilities outside the trusted domain, it should not be trusted to have access to E2E key information. The call processing function may include the processing of call signaling messages, as well as the signing of those messages. It may also authenticate the Endpoints for the purpose of call signaling and subsequently joining of a conference hosted through one or more Media Distributors. Call processing may optionally ensure the privacy of call signaling messages between itself, the Endpoint, and other entities. 3.2. Trusted Entities From the PERC model system perspective, entities considered trusted (refer to Figure 1) can be in possession of the E2E media encryption keys for one or more conferences. 3.2.1. Endpoint An Endpoint is considered trusted and has access to E2E key information. While it is possible for an Endpoint to be compromised, subsequently performing in undesired ways, defining Endpoint resistance to compromise is outside the scope of this document. Endpoints take measures to mitigate the adverse effects of denial of service attacks (refer to Section 8) from other entities, including from other Endpoints, to a level equal to or better than traditional conference (non-PERC) deployments. 3.2.2. Key Distributor The Key Distributor, which may be colocated with an Endpoint or exist standalone, is responsible for providing key information to Endpoints for both end-to-end (E2E) and hop-by-hop (HBH) security and for providing key information to Media Distributors for the hop-by-hop security. Interaction between the Key Distributor and the call processing function is necessary for proper conference-to-Endpoint mappings. This is described in Section 5.3. The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of the Key Distributor puts the security of the conference at risk. Jones, et al. Expires December 7, 2019 [Page 7] Internet-Draft Private Media Framework June 2019 They Key Distributor needs to know which Endpoints and which Media Distributors are authorized to participate in the conference. How the Key Distributor obtains this information is outside the scope of this document. However, Key Distributors MUST reject DTLS associations with any unauthorized Endpoint or Media Distributor. 4. Framework for PERC The purpose for this framework is to define a means through which media privacy is ensured when communicating within a conferencing environment consisting of one or more Media Distributors that only switch, hence not terminate, media. It does not otherwise attempt to hide the fact that a conference between Endpoints is taking place. This framework reuses several specified RTP security technologies, including Secure Real-time Transport Protocol (SRTP) [RFC3711], Encrypted Key Transport (EKT) [I-D.ietf-perc-srtp-ekt-diet], and DTLS-SRTP. 4.1. End-to-End and Hop-by-Hop Authenticated Encryption This solution framework focuses on the end-to-end privacy and integrity of the participant's media by limiting access to only trusted entities to the E2E key used for authenticated end-to-end encryption. However, this framework does give a Media Distributor access to RTP headers fields and header extensions, as well as the ability to modify a certain subset of the header fields and to add or change header extensions. Packets received by a Media Distributor or an Endpoint are authenticated hop-by-hop. To enable all of the above, this framework defines the use of two security contexts and two associated encryption keys: an "inner" key (an E2E key distinct for each transmitted media flow) for authenticated encryption of RTP media between Endpoints and an "outer" key (HBH key) known only to Media Distributor or the adjacent Endpoint for the hop between an Endpoint and a Media Distributor or peer Endpoint. An Endpoint will receive one or more E2E keys from every other Endpoint in the conference that correspond to the media flows transmitted by those other Endpoints, while HBH keys are derived from the DTLS-SRTP association with the Key Distributor. Two communicating Media Distributors use DTLS-SRTP associations directly with each other to obtain the HBH keys they will use. See Section 4.5 for more details on key exchange. Jones, et al. Expires December 7, 2019 [Page 8] Internet-Draft Private Media Framework June 2019 +-------------+ +-------------+ | |################################| | | Media |------------------------ *----->| Media | | Distributor |<----------------------*-|------| Distributor | | X |#####################*#|#|######| Y | | | | | | | | +-------------+ | | | +-------------+ # ^ | # HBH Key (XY) -+ | | # ^ | # # | | # E2E Key (B) ---+ | # | | # # | | # E2E Key (A) -----+ # | | # # | | # # | | # # | | # # | | # # | | *---- HBH Key (AX) HBH Key (YB) ----* | | # # | | # # | | # # *--------- E2E Key (A) E2E Key (A) ---------* # # | *------- E2E Key (B) E2E Key (B) -------* | # # | | # # | | # # | v # # | v # +-------------+ +-------------+ | Endpoint A | | Endpoint B | +-------------+ +-------------+ Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets The Double transform [I-D.ietf-perc-double] enables Endpoints to perform encryption using both the end-to-end and hop-by-hop contexts while still preserving the same overall interface as other SRTP transforms. The Media Distributor simply uses the corresponding normal (single) AES-GCM transform, keyed with the appropriate HBH keys. See Section 6.1 for a description of the keys used in PERC and Section 7 for diagram of how encrypted RTP packets appear on the wire. RTCP is only encrypted hop-by-hop, not end-to-end. This framework introduces no additional step for RTCP authenticated encryption, so the procedures needed are specified in [RFC3711] and use the same outer, hop-by-hop cryptographic context chosen in the Double operation described above. For this reason, Endpoints MUST NOT send confidential information via RTCP. 4.2. E2E Key Confidentiality To ensure the confidentiality of E2E keys shared between Endpoints, Endpoints use a common Key Encryption Key (KEK) that is known only by the trusted entities in a conference. That KEK, defined in the EKT specification [I-D.ietf-perc-srtp-ekt-diet] as the EKT Key, is used to subsequently encrypt the SRTP master key used for E2E Jones, et al. Expires December 7, 2019 [Page 9] Internet-Draft Private Media Framework June 2019 authenticated encryption of media sent by a given Endpoint. Each Endpoint in the conference creates an SRTP master key for E2E authenticated encryption and keep track of the E2E keys received via the Full EKT Tag for each distinct synchronization source (SSRC) in the conference so that it can properly decrypt received media. An Endpoint may change its E2E key at any time and advertise that new key to the conference as specified in [I-D.ietf-perc-srtp-ekt-diet]. 4.3. E2E Keys and Endpoint Operations Any given RTP media flow is identified by its SSRC, and an Endpoint might send more than one at a time and change the mix of media flows transmitted during the life of a conference. Thus, an Endpoint MUST maintain a list of SSRCs from received RTP flows and each SSRC's associated E2E key information. An Endpoint MUST discard old E2E keys no later than when it leaves the conference (see Section 4.5.2). If the packet is to contain RTP header extensions, it should be noted that those are only encrypted HBH per [I-D.ietf-perc-double]. For this reason, Endpoints MUST NOT transmit confidential information via RTP header extensions. 4.4. HBH Keys and Per-hop Operations To ensure the integrity of transmitted media packets, it is REQUIRED that every packet be authenticated hop-by-hop between an Endpoint and a Media Distributor, as well between Media Distributors. The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the respective hop. Each HBH key is distinct per hop and no two hops ever use the same SRTP master key. While Endpoints also perform HBH authentication, the ability of the Endpoints to reconstruct the original RTP header also enables the Endpoints to authenticate RTP packets E2E. This design yields flexibility to the Media Distributor to change certain RTP header values as packets are forwarded. Which values the Media Distributor can change in the RTP header are defined in [I-D.ietf-perc-double]. RTCP can only be encrypted hop-by-hop, giving the Media Distributor the flexibility to forward RTCP content unchanged, transmit compound RTCP packets or to initiate RTCP packets for reporting statistics or conveying other information. Performing hop-by-hop authentication for all RTP and RTCP packets also helps provide replay protection (see Section 8). The use of the replay protection mechanism specified in Section 3.3.2 of [RFC3711] is REQUIRED at each hop. Jones, et al. Expires December 7, 2019 [Page 10] Internet-Draft Private Media Framework June 2019 If there is a need to encrypt one or more RTP header extensions hop- by-hop, the Endpoint derives an encryption key from the HBH SRTP master key to encrypt header extensions as per [RFC6904]. This still gives the Media Distributor visibility into header extensions, such as the one used to determine audio level [RFC6464] of conference participants. Note that when RTP header extensions are encrypted, all hops need to decrypt and re-encrypt these encrypted header extensions. Please refer to Sections 5.1 through 5.3 of [I-D.ietf-perc-double] for procedures to perform RTP header extension encryption and decryption. 4.5. Key Exchange In brief, the keys used by any given Endpoints are determined in the following way: o The HBH keys that the Endpoint uses to send and receive SRTP media are derived from a DTLS handshake that the Endpoint performs with the Key Distributor (following normal DTLS-SRTP procedures). o The E2E key that an Endpoint uses to send SRTP media can either be set from the DTLS-SRTP association with the Key Distributor or chosen by the Endpoint. It is then distributed to other Endpoints in a Full EKT Tag, encrypted under an EKT Key provided to the client by the Key Distributor within the DTLS channel they negotiated. Note that an Endpoint MAY create a different E2E key per media flow, where a media flow is identified by its SSRC value. o Each E2E key that an Endpoint uses to receive SRTP media is set by receiving a Full EKT Tag from another Endpoint. o The HBH keys used between two Media Distributors is derived from DTLS-SRTP procedures employed directly between them. 4.5.1. Initial Key Exchange and Key Distributor The Media Distributor maintains a tunnel with the Key Distributor (e.g., using [I-D.ietf-perc-dtls-tunnel]), making it possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each Endpoint and the Key Distributor as shown the following figure. The DTLS association between Endpoints and the Key Distributor enables each Endpoint to generate E2E and HBH keys and receive the KEK. At the same time, the Key Distributor securely provides the HBH key information to the Media Distributor. The key information summarized here may include the SRTP master key, SRTP master salt, and the negotiated cryptographic transform. Jones, et al. Expires December 7, 2019 [Page 11] Internet-Draft Private Media Framework June 2019 +-----------+ KEK info | Key | HBH Key info to to Endpoints |Distributor| Endpoints & Media Distributor +-----------+ # ^ ^ # # | | #--- Tunnel # | | # +-----------+ +-----------+ +-----------+ | Endpoint | DTLS | Media | DTLS | Endpoint | | KEK |<------------|Distributor|------------>| KEK | | HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key | +-----------+ +-----------+ +-----------+ Figure 3: Exchanging Key Information Between Entities In addition to the secure tunnel between the Media Distributor and the Key Distributor, there are two additional types of security associations utilized as a part of the key exchange as discussed in the following paragraphs. One is a DTLS-SRTP association between an Endpoint and the Key Distributor (with packets passing through the Media Distributor) and the other is a DTLS-SRTP association between peer Media Distributors. Endpoints establish a DTLS-SRTP association over the RTP session with the Media Distributor and its media ports for the purposes of key information exchange with the Key Distributor. The Media Distributor does not terminate the DTLS signaling, but instead forwards DTLS packets received from an Endpoint on to the Key Distributor (and vice versa) via a tunnel established between Media Distributor and the Key Distributor. In establishing the DTLS association between Endpoints and the Key Distributor, the Endpoint MUST act as the DTLS client and the Key Distributor MUST act as the DTLS server. The KEK is conveyed by the Key Distributor over the DTLS association to Endpoints via procedures defined in EKT [I-D.ietf-perc-srtp-ekt-diet] via the EKTKey message. The Key Distributor MUST NOT establish DTLS-SRTP associations with Endpoints without first authenticating the Media Distributor tunneling the DTLS-SRTP packets from the Endpoint. Note that following DTLS-SRTP procedures for the [I-D.ietf-perc-double] cipher, the Endpoint generates both E2E and HBH encryption keys and salt values. Endpoints MUST either use the DTLS-SRTP generated E2E key for transmission or generate a fresh E2E key. In either case, the generated SRTP master salt for E2E encryption MUST be replaced with the salt value provided by the Key Jones, et al. Expires December 7, 2019 [Page 12] Internet-Draft Private Media Framework June 2019 Distributor via the EKTKey message. That is because every Endpoint in the conference uses the same SRTP master salt. The Endpoint only transmits the SRTP master key (not the salt) used for E2E encryption to other Endpoints in RTP/RTCP packets per [I-D.ietf-perc-srtp-ekt-diet]. Media Distributors use DTLS-SRTP directly with a peer Media Distributor to establish the HBH key for transmitting RTP and RTCP packets to that peer Media Distributor. The Key Distributor does not facilitate establishing a HBH key for use between Media Distributors. 4.5.2. Key Exchange during a Conference Following the initial key information exchange with the Key Distributor, an Endpoint is able to encrypt media end-to-end with an E2E key, sending that E2E key to other Endpoints encrypted with the KEK, and is able to encrypt and authenticate RTP packets using a HBH key. The procedures defined do not allow the Media Distributor to gain access to the KEK information, preventing it from gaining access to any Endpoint's E2E key and subsequently decrypting media. The KEK may need to change from time-to-time during the life of a conference, such as when a new participant joins or leaves a conference. Dictating if, when or how often a conference is to be re-keyed is outside the scope of this document, but this framework does accommodate re-keying during the life of a conference. When a Key Distributor decides to re-key a conference, it transmits a new EKTKey message containing the new EKT Key to each of the conference participants. Upon receipt of the new EKT Key, the Endpoint MUST create a new SRTP master key and prepare to send that key inside a Full EKT Field using the new EKT Key as per Section 4.5 of [I-D.ietf-perc-srtp-ekt-diet]. In order to allow time for all Endpoints in the conference to receive the new keys, the sender should follow the recommendations in Section 4.7 of [I-D.ietf-perc- srtp-ekt-diet]. On receiving a new EKT Key, Endpoints MUST be prepared to decrypt EKT tags using the new key. The EKT SPI field is used to differentiate between tags encrypted with the old and new keys. After re-keying, an Endpoint SHOULD retain prior SRTP master keys and EKT Key for a period of time sufficient for the purpose of ensuring it can decrypt late-arriving or out-of-order packets or packets sent by other Endpoints that used the prior keys for a period of time after re-keying began. An Endpoint MAY retain old keys until the end of the conference. Jones, et al. Expires December 7, 2019 [Page 13] Internet-Draft Private Media Framework June 2019 Endpoints MAY follow the procedures in section 5.2 of [RFC5764] to renegotiate HBH keys as desired. If new HBH keys are generated, the new keys are also delivered to the Media Distributor following the procedures defined in [I-D.ietf-perc-dtls-tunnel] as one possible method. Endpoints MAY change the E2E encryption key used at any time. An Endpoint MUST generate a new E2E encryption key whenever it receives a new EKT Key. After switching to a new key, the new key is conveyed to other Endpoints in the conference in RTP/RTCP packets per [I-D.ietf-perc-srtp-ekt-diet]. 5. Authentication It is important to this solution framework that the entities can validate the authenticity of other entities, especially the Key Distributor and Endpoints. The details of this are outside the scope of specification but a few possibilities are discussed in the following sections. The critical requirements are that an Endpoint can verify it is connected to the correct Key Distributor for the conference and the Key Distributor can verify the Endpoint is the correct Endpoint for the conference. Two possible approaches to solve this are Identity Assertions and Certificate Fingerprints. 5.1. Identity Assertions WebRTC Identity assertion [I-D.ietf-rtcweb-security-arch] is used to bind the identity of the user of the Endpoint to the fingerprint of the DTLS-SRTP certificate used for the call. This certificate is unique for a given call and a conference. This allows the Key Distributor to ensure that only authorized users participate in the conference. Similarly the Key Distributor can create a WebRTC Identity assertion to bind the fingerprint of the unique certificate used by the Key Distributor for this conference so that the Endpoint can validate it is talking to the correct Key Distributor. Such a setup requires an Identity Provider (Idp) trusted by the Endpoints and the Key Distributor. 5.2. Certificate Fingerprints in Session Signaling Entities managing session signaling are generally assumed to be untrusted in the PERC framework. However, there are some deployment scenarios where parts of the session signaling may be assumed trustworthy for the purposes of exchanging, in a manner that can be authenticated, the fingerprint of an entity's certificate. Jones, et al. Expires December 7, 2019 [Page 14] Internet-Draft Private Media Framework June 2019 As a concrete example, SIP [RFC3261] and Session Description Protocol (SDP) [RFC4566] can be used to convey the fingerprint information per [RFC5763]. An Endpoint's SIP User Agent would send an INVITE message containing SDP for the media session along with the Endpoint's certificate fingerprint, which can be signed using the procedures described in [RFC8224] for the benefit of forwarding the message to other entities by the Focus [RFC4353]. Other entities can verify the fingerprints match the certificates found in the DTLS-SRTP connections to find the identity of the far end of the DTLS-SRTP connection and verify that is the authorized entity. Ultimately, if using session signaling, an Endpoint's certificate fingerprint would need to be securely mapped to a user and conveyed to the Key Distributor so that it can check that that user is authorized. Similarly, the Key Distributor's certificate fingerprint can be conveyed to an Endpoint in a manner that can be authenticated as being an authorized Key Distributor for this conference. 5.3. Conference Identification The Key Distributor needs to know what Endpoints are being added to a given conference. Thus, the Key Distributor and the Media Distributor need to know Endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier defined in [I-D.ietf-perc-dtls-tunnel]. How this unique identifier is assigned is outside the scope of this document. 6. PERC Keys This section describes the various keys employed by PERC. 6.1. Key Inventory and Management Considerations This section summarizes the several different keys used in the PERC framework, how they are generated, and what purpose they serve. The keys are described in the order in which they would typically be acquired. The various keys used in PERC are shown in Figure 4 below. Jones, et al. Expires December 7, 2019 [Page 15] Internet-Draft Private Media Framework June 2019 +-----------+----------------------------------------------------+ | Key | Description | +-----------+----------------------------------------------------+ | HBH Key | SRTP master key used to encrypt media hop-by-hop. | +-----------+----------------------------------------------------+ | KEK | Key shared by all Endpoints and used to encrypt | | (EKT Key) | each Endpoint's E2E SRTP master key so receiving | | | Endpoints can decrypt media. | +-----------+----------------------------------------------------+ | E2E Key | SRTP master key used to encrypt media end-to-end. | +-----------+----------------------------------------------------+ Figure 4: Key Inventory While the number of key types is very small, it should be understood that the actual number of distinct keys can be large as the conference grows in size. As an example, with 1,000 participants in a conference, there would be at least 1,000 distinct SRTP master keys, all of which share the same master salt. Each of those keys are passed through the KDF defined in [RFC3711] to produce the actual encryption and authentication keys. Complicating key management is the fact that the KEK can change and, when it does, the Endpoints generate new SRTP master keys that are associated with a new EKT SPI. Endpoints might retain old keys for a period of time to ensure they can properly decrypt late-arriving or out-of-order packets, which means the number of keys held during that period of time might substantially more. A more detailed explanation of each of the keys follows. 6.2. DTLS-SRTP Exchange Yields HBH Keys The first set of keys acquired are for hop-by-hop encryption and decryption. Per the Double [I-D.ietf-perc-double] procedures, the Endpoint performs DTLS-SRTP exchange with the Key Distributor and receives a key that is, in fact, "double" the size that is needed. The end-to-end part is the first half of the key, so the Endpoint discards that information when generating its own key. The second half of the key material is for hop-by-hop operations, so that half of the key (corresponding to the least significant bits) is assigned internally as the HBH key. The Key Distributor informs the Media Distributor of the HBH key. Specifically, the Key Distributor sends the least significant bits corresponding to the half of the keying material determined through Jones, et al. Expires December 7, 2019 [Page 16] Internet-Draft Private Media Framework June 2019 DTLS-SRTP with the Endpoint to the Media Distributor. A salt value is generated along with the HBH key. The salt is also longer than needed for hop-by-hop operations, thus only the least significant bits of the required length (half of the generated salt material) are sent to the Media Distributor. One way to transmit this key and salt information is via the tunnel protocol defined in [I-D.ietf-perc-dtls-tunnel]. No two Endpoints have the same HBH key, thus the Media Distributor MUST keep track each distinct HBH key (and the corresponding salt) and use it only for the specified hop. The HBH key is also used for hop-by-hop encryption of RTCP. RTCP is not end-to-end encrypted in PERC. 6.3. The Key Distributor Transmits the KEK (EKT Key) Via the aforementioned DTLS-SRTP association, the Key Distributor sends the Endpoint the KEK (EKT Key per [I-D.ietf-perc-srtp-ekt-diet]). This key is known only to the Key Distributor and Endpoints. This key is the most important to protect since having knowledge of this key (and the SRTP master salt transmitted as a part of the same message) allows an entity to decrypt any media packet in the conference. Note that the Key Distributor can send any number of EKT Keys to Endpoints. This is used to re-key the entire conference. Each key is identified by a "Security Parameter Index" (SPI) value. Endpoints MUST expect that a conference might be re-keyed when a new participant joins a conference or when a participant leaves a conference in order to protect the confidentiality of the conversation before and after such events. The SRTP master salt to be used by the Endpoint is transmitted along with the EKT Key. All Endpoints in the conference utilize the same SRTP master salt that corresponds with a given EKT Key. The Full EKT Tag in media packets is encrypted using a cipher specified via the EKTKey message (e.g., AES Key Wrap with a 128-bit key). This cipher is different than the cipher used to protect media and is only used to encrypt the Endpoint's SRTP master key (and other EKT Tag data as per [I-D.ietf-perc-srtp-ekt-diet]). The Media Distributor is not given the KEK. Jones, et al. Expires December 7, 2019 [Page 17] Internet-Draft Private Media Framework June 2019 6.4. Endpoints fabricate an SRTP Master Key As stated earlier, the E2E key determined via DTLS-SRTP MAY be discarded in favor of a locally-generated E2E SRTP master key. While the DTLS-SRTP-derived SRTP master key can be used initially, the Endpoint might choose to change the SRTP master key periodically and MUST change the SRTP master key as a result of the EKT key changing. A locally-generated SRTP master key is used along with the master salt transmitted to the Endpoint from the Key Distributor via the EKTKey message to encrypt media end-to-end. Since the Media Distributor is not involved in E2E functions, it does not create this key nor have access to any Endpoint's E2E key. Note, too, that even the Key Distributor is unaware of the locally- generated E2E keys used by each Endpoint. The Endpoint transmits its E2E key to other Endpoints in the conference by periodically including it in SRTP packets in a Full EKT Tag. When placed in the Full EKT Tag, it is encrypted using the EKT Key provided by the Key Distributor. The master salt is not transmitted, though, since all Endpoints receive the same master salt via the EKTKey message from the Key Distributor. The recommended frequency with which an Endpoint transmits its SRTP master key is specified in [I-D.ietf-perc-srtp-ekt-diet]. 6.5. Summary of Key Types and Entity Possession All Endpoints have knowledge of the KEK. Every HBH key is distinct for a given Endpoint, thus Endpoint A and Endpoint B do not have knowledge of the other's HBH key. Since HBH keys are derived from a DTLS-SRTP association, there is at most one HBH key per Endpoint, (The only exception is where the DTLS-SRTP association might be rekeyed per Section 5.2 of [RFC5764] and a new key is created to replace the former key.) Each Endpoint generates its own E2E key (SRTP master key), thus there is a distinct E2E key per endpoint. This key is transmitted (encrypted) via the Full EKT Tag to other Endpoints. Endpoints that receive media from a given transmitting Endpoint gain knowledge of the transmitter's E2E key via the Full EKT Tag. To summarize the various keys and which entity is in possession of a given key, refer to Figure 5. Jones, et al. Expires December 7, 2019 [Page 18] Internet-Draft Private Media Framework June 2019 +----------------------+------------+-------+-------+------------+ | Key / Entity | Endpoint A | MD X | MD Y | Endpoint B | +----------------------+------------+-------+-------+------------+ | KEK (EKT Key) | Yes | No | No | Yes | +----------------------+------------+-------+-------+------------+ | E2E Key (A and B) | Yes | No | No | Yes | +----------------------+------------+-------+-------+------------+ | HBH Key (A<=>MD X) | Yes | Yes | No | No | +----------------------+------------+-------+-------+------------+ | HBH Key (B<=>MD Y) | No | No | Yes | Yes | +----------------------+------------+---------------+------------+ | HBH Key (MD X<=>MD Y)| No | Yes | Yes | No | +----------------------+------------+---------------+------------+ Figure 5: Keys Types and Entity Possession 7. Encrypted Media Packet Format Figure 6 presents a complete picture of what an encrypted media packet per this framework looks like when transmitted over the wire. The packet format shown is encrypted using the Double cryptographic transform with an EKT Tag appended to the end. Jones, et al. Expires December 7, 2019 [Page 19] Internet-Draft Private Media Framework June 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ |V=2|P|X| CC |M| PT | sequence number | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | timestamp | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | synchronization source (SSRC) identifier | IO +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO | contributing source (CSRC) identifiers | IO | .... | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O | RTP extension (OPTIONAL) ... | |O +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O I | payload ... | IO O I | +-------------------------------+ IO O I | | RTP padding | RTP pad count | IO O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O | | E2E authentication tag | |O O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O O | | OHB ... | |O +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ | | | HBH authentication tag | || | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | | | EKT Tag ... | R || | | +-+-+-+-+-+-+-+-+-+ | || | | +- Neither encrypted nor authenticated; || | | appended after Double is performed || | | || | | || | +- E2E Encrypted Portion E2E Authenticated Portion ---+| | | +--- HBH Encrypted Portion HBH Authenticated Portion ----+ I = Inner (E2E) encryption / authentication O = Outer (HBH) encryption / authentication Figure 6: Encrypted Media Packet Format 8. Security Considerations 8.1. Third Party Attacks Third party attacks are attacks attempted by an adversary that is not supposed to have access to keying material or is otherwise not an authorized participant in the conference. Jones, et al. Expires December 7, 2019 [Page 20] Internet-Draft Private Media Framework June 2019 On-path attacks are mitigated by hop-by-hop integrity protection and encryption. The integrity protection mitigates packet modification and encryption makes selective blocking of packets harder, but not impossible. Off-path attackers could try connecting to different PERC entities to send specifically crafted packets with an aim of forcing the receiver to forward or render bogus media packets. Endpoints and Media Distributors mitigate such an attack by performing hop-by-hop authentication and discarding packets that fail authentication. Another attack vector is a third party claiming to be a Media Distributor, fooling Endpoints into sending packets to the false Media Distributor instead of the correct one. The deceived sending Endpoints could incorrectly assume their packets have been delivered to Endpoints when they in fact have not. While this attack is possible, the result is a simple denial of service with no leakage of confidential information, since the false Media Distributor would not have access to either HBH or E2E encryption keys. A third party could cause a denial-of-service by transmitting many bogus or replayed packets toward receiving devices that ultimately degrade conference or device performance. Therefore, implementations might wish to devise mechanisms to safeguard against such illegitimate packets, such as utilizing rate-limiting or performing basic sanity-checks on packets (e.g., looking at packet length or expected sequence number ranges) before performing more expensive decryption operations. Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps to prevent a denial-of-service attack by preventing a false Endpoint or false Media Distributor from successfully participating as a perceived valid media sender that could otherwise carry out an on-path attack. When mutual authentication fails, a receiving Endpoint would know that it could safely discard media packets received from the Endpoint without inspection. 8.2. Media Distributor Attacks A malicious or compromised Media Distributor can attack the session in a number of possible ways. 8.2.1. Denial of service A simple form of attack is discarding received packets that should be forwarded. This solution framework does not introduce any mitigation for Media Distributors that fail to forward media packets. Jones, et al. Expires December 7, 2019 [Page 21] Internet-Draft Private Media Framework June 2019 Another form of attack is modifying received packets before forwarding. With this solution framework, any modification of the end-to-end authenticated data results in the receiving Endpoint getting an integrity failure when performing authentication on the received packet. The Media Distributor can also attempt to perform resource consumption attacks on the receiving Endpoint. One such attack would be to insert random SSRC/CSRC values in any RTP packet along with a Full EKT Tag. Since such a message would trigger the receiver to form a new cryptographic context, the Media Distributor can attempt to consume the receiving Endpoint's resources. While E2E authentication would fail and the cryptographic context would be destroyed, the key derivation operation would nonetheless consume some computational resources. While resource consumption attacks cannot be mitigated entirely, rate-limiting packets might help reduce the impact of such attacks. 8.2.2. Replay Attack A replay attack is when an already received packet from a previous point in the RTP stream is replayed as new packet. This could, for example, allow a Media Distributor to transmit a sequence of packets identified as a user saying "yes", instead of the "no" the user actually said. A replay attack is mitigated by the requirement to implement replay protection as described in Section 3.3.2 of [RFC3711]. End-to-end replay protection MUST be provided for the duration of the conference. 8.2.3. Delayed Playout Attack A delayed playout attack is one where media is received and held by a Media Distributor and then forwarded to Endpoints at a later point in time. This attack is possible even if E2E replay protection is in place. Because the Media Distributor is allowed to select a subset of streams and not forward the rest to a receiver, such as in forwarding only the most active speakers, the receiver has to accept gaps in the E2E packet sequence. The issue with this is that a Media Distributor can select to not deliver a particular stream for a while. While the Media Distributor can purposely stop forwarding media flows, it can also select an arbitrary starting point to resume forwarding those media flow, perhaps forwarding old packets rather than current packets. As a consequence, what the media source sent Jones, et al. Expires December 7, 2019 [Page 22] Internet-Draft Private Media Framework June 2019 can be substantially delayed at the receiver with the receiver believing that newly arriving packets are delayed only by transport delay when the packets may actually be minutes or hours old. While this attack cannot be eliminated entirely, its effectiveness can be reduced by re-keying the conference periodically since significantly-delayed media encrypted with expired keys would not be decrypted by Endpoints. 8.2.4. Splicing Attack A splicing attack is an attack where a Media Distributor receiving multiple media sources splices one media stream into the other. If the Media Distributor were able to change the SSRC without the receiver having any method for verifying the original source ID, then the Media Distributor could first deliver stream A and then later forward stream B under the same SSRC as stream A was previously using. By including the SSRC in the integrity check for each packet, both HBH and E2E, PERC prevents splicing attacks. 8.2.5. RTCP Attacks PERC does not provide end-to-end protection of RTCP messages. This allows a compromised Media Distributor to impact any message that might be transmitted via RTCP, including media statistics, picture requests, or loss indication. It is also possible for a compromised Media Distributor to forge requests, such as requests to the Endpoint to send a new picture. Such requests can consume significant bandwidth and impair conference performance. 8.3. Key Distributor Attacks As stated in Section 3.2.2, the Key Distributor needs to be secured since exploiting the Key Server can allow an adversary to gain access to the keying material for one or more conferences. Having access to that keying material would then allow the adversary to decrypt media sent from any Endpoint in the conference. As a first line of defense, the Key Distributor authenticates every security association, both associations with Endpoints and Media Distributors. The Key Distributor knows which entities are authorized to have access to which keys and inspection of certificates will substantially reduce the risk of providing keys to an adversary. Both physical and network access to the Key Distributor should be severely restricted. This may be more difficult to achieve when the Key Distributor is embedded within and Endpoint, for example. Jones, et al. Expires December 7, 2019 [Page 23] Internet-Draft Private Media Framework June 2019 Nonetheless, consideration should be given to shielding the Key Distributor from unauthorized access or any access that is not strictly necessary for the support of an ongoing conference. Consideration should be given to whether access to the keying material will be needed beyond the conclusion of a conference. If not needed, the Key Distributor's policy should be to destroy the keying material once the conference concludes or when keying material changes during the course of the conference. If keying material is needed beyond the lifetime of the conference, further consideration should be given to protecting keying material from future exposure. While it might be obvious, it is worth stating to avoid any doubt that if an adversary were to record the media packets transmitted during a conference and then gain unauthorized access to the keying material left unsecured on the Key Distributor even years later, the adversary could decrypt the content every packet transmitted during the conference. 8.4. Endpoint Attacks A Trusted Endpoint is so named because conference confidentiality relies heavily on the security and integrity of the Endpoint. If an adversary successfully exploits a vulnerability in an Endpoint, it might be possible for the adversary to obtain all of the keying material used in the conference. With that keying material, an adversary could decrypt any of the media flows received from any other Endpoint, either in real-time or at a later point in time (assuming the adversary makes a copy of the media packets). Additionally, if an adversary successfully exploits an Endpoint, the adversary could inject media into the conference. One way an adversary could do that is by manipulating the RTP or SRTP software to transmit whatever media the adversary wishes to send. This could involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing endpoint. This is made possible since all conference participants share the same KEK. Only a single SRTP cipher suite defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet (namely, TESLA [RFC4383]), and its usage is presently not defined for PERC. The suite defined in PERC only allows an Endpoint to determine that whoever sent a packet had received the KEK. However, attacks on the endpoint are not limited to the PERC-specific software within the Endpoint. An attacker could inject media or record media by manipulating the software that sits between the PERC- enabled application and the hardware microphone of video camera, for example. Likewise, an attacker could potentially access confidential Jones, et al. Expires December 7, 2019 [Page 24] Internet-Draft Private Media Framework June 2019 media by accessing memory, cache, disk storage, etc. if the endpoint is no secured. 9. IANA Considerations There are no IANA considerations for this document. 10. Acknowledgments The authors would like to thank Mo Zanaty, Christian Oien, and Richard Barnes for invaluable input on this document. Also, we would like to acknowledge Nermeen Ismail for serving on the initial versions of this document as a co-author. We would also like to acknowledge John Mattsson, Mats Naslund, and Magnus Westerlund for providing some of the text in the document, including much of the original text in the security considerations section. 11. References 11.1. Normative References [I-D.ietf-perc-double] Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Double Encryption Procedures", draft-ietf-perc-double-10 (work in progress), October 2018. [I-D.ietf-perc-srtp-ekt-diet] Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for DTLS and Secure RTP", draft-ietf-perc-srtp-ekt-diet-09 (work in progress), October 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . Jones, et al. Expires December 7, 2019 [Page 25] Internet-Draft Private Media Framework June 2019 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.ietf-perc-dtls-tunnel] Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-05 (work in progress), April 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, DOI 10.17487/RFC4383, February 2006, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . Jones, et al. Expires December 7, 2019 [Page 26] Internet-Draft Private Media Framework June 2019 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [W3C.CR-webrtc-20180927] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium CR CR-webrtc-20180927, September 2018, . Authors' Addresses Paul E. Jones Cisco 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com David Benham Independent Email: dabenham@gmail.com Jones, et al. Expires December 7, 2019 [Page 27] Internet-Draft Private Media Framework June 2019 Christian Groves Independent Melbourne Australia Email: cngroves.std@gmail.com Jones, et al. Expires December 7, 2019 [Page 28] ./draft-ietf-perc-srtp-ekt-diet-13.txt0000644000764400076440000016022713674410174017016 0ustar iustyiusty Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Standards Track J. Mattsson Expires: December 25, 2020 Ericsson AB D. McGrew Cisco Systems D. Wing Citrix Systems, Inc. F. Andreason Cisco Systems June 23, 2020 Encrypted Key Transport for DTLS and Secure RTP draft-ietf-perc-srtp-ekt-diet-13 Abstract Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 25, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Jennings, et al. Expires December 25, 2020 [Page 1] Internet-Draft EKT SRTP June 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conventions Used In This Document . . . . . . . . . . . . . . 4 4. Encrypted Key Transport . . . . . . . . . . . . . . . . . . . 4 4.1. EKTField Formats . . . . . . . . . . . . . . . . . . . . 5 4.2. SPIs and EKT Parameter Sets . . . . . . . . . . . . . . . 8 4.3. Packet Processing and State Machine . . . . . . . . . . . 8 4.3.1. Outbound Processing . . . . . . . . . . . . . . . . . 9 4.3.2. Inbound Processing . . . . . . . . . . . . . . . . . 10 4.4. Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Defining New EKT Ciphers . . . . . . . . . . . . . . 13 4.5. Synchronizing Operation . . . . . . . . . . . . . . . . . 13 4.6. Timing and Reliability Consideration . . . . . . . . . . 13 5. Use of EKT with DTLS-SRTP . . . . . . . . . . . . . . . . . . 15 5.1. DTLS-SRTP Recap . . . . . . . . . . . . . . . . . . . . . 15 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP . . . . . 15 5.2.1. Negotiating an EKTCipher . . . . . . . . . . . . . . 17 5.2.2. Establishing an EKT Key . . . . . . . . . . . . . . . 17 5.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 19 5.4. Sending the DTLS EKTKey Reliably . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. EKT Message Types . . . . . . . . . . . . . . . . . . . . 21 7.2. EKT Ciphers . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . 22 7.4. TLS Handshake Type . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Jennings, et al. Expires December 25, 2020 [Page 2] Internet-Draft EKT SRTP June 2020 1. Introduction Real-time Transport Protocol (RTP) is designed to allow decentralized groups with minimal control to establish sessions, such as for multimedia conferences. Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many minimal-control scenarios, because it requires that synchronization source (SSRC) values and other data be coordinated among all of the participants in a session. For example, if a participant joins a session that is already in progress, that participant needs to be told the SRTP keys along with the SSRC, rollover counter (ROC) and other details of the other SRTP sources. The inability of SRTP to work in the absence of central control was well understood during the design of the protocol; the omission was considered less important than optimizations such as bandwidth conservation. Additionally, in many situations SRTP is used in conjunction with a signaling system that can provide the central control needed by SRTP. However, there are several cases in which conventional signaling systems cannot easily provide all of the coordination required. This document defines Encrypted Key Transport (EKT) for SRTP and reduces the amount of external signaling control that is needed in a SRTP session with multiple receivers. EKT securely distributes the SRTP master key and other information for each SRTP source. With this method, SRTP entities are free to choose SSRC values as they see fit, and to start up new SRTP sources with new SRTP master keys within a session without coordinating with other entities via external signaling or other external means. EKT extends DTLS and SRTP to enable a common key encryption key (called an EKTKey) to be distributed to all endpoints, so that each endpoint can securely send its SRTP master key and current SRTP rollover counter to the other participants in the session. This data furnishes the information needed by the receiver to instantiate an SRTP receiver context. EKT can be used in conferences where the central media distributor or conference bridge cannot decrypt the media, such as the type defined for [I-D.ietf-perc-private-media-framework]. It can also be used for large scale conferences where the conference bridge or media distributor can decrypt all the media but wishes to encrypt the media it is sending just once and then send the same encrypted media to a large number of participants. This reduces the amount of CPU time needed for encryption and can be used for some optimization to media sending that use source specific multicast. Jennings, et al. Expires December 25, 2020 [Page 3] Internet-Draft EKT SRTP June 2020 EKT does not control the manner in which the SSRC is generated. It is only concerned with distributing the security parameters that an endpoint needs to associate with a given SSRC in order to decrypt SRTP packets from that sender. EKT is not intended to replace external key establishment mechanisms. Instead, it is used in conjunction with those methods, and it relieves those methods of the burden to deliver the context for each SRTP source to every SRTP participant. This document defines how EKT works with the DTLS-SRTP approach to key establishment, by using keys derived from the DTLS-SRTP handshake to encipher the EKTKey in addition to the SRTP media. 2. Overview This specification defines a way for the server in a DTLS-SRTP negotiation, see Section 5, to provide an EKTKey to the client during the DTLS handshake. The EKTKey thus obtained can be used to encrypt the SRTP master key that is used to encrypt the media sent by the endpoint. This specification also defines a way to send the encrypted SRTP master key (with the EKTKey) along with the SRTP packet, see Section 4. Endpoints that receive this and know the EKTKey can use the EKTKey to decrypt the SRTP master key which can then be used to decrypt the SRTP packet. One way to use this is described in the architecture defined by [I-D.ietf-perc-private-media-framework]. Each participant in the conference forms a DTLS-SRTP connection to a common key distributor that distributes the same EKTKey to all the endpoints. Then each endpoint picks its own SRTP master key for the media they send. When sending media, the endpoint also includes the SRTP master key encrypted with the EKTKey in the SRTP packet. This allows all the endpoints to decrypt the media. 3. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Encrypted Key Transport EKT defines a new method of providing SRTP master keys to an endpoint. In order to convey the ciphertext corresponding to the SRTP master key, and other additional information, an additional field, called EKTField, is added to the SRTP packets. The EKTField Jennings, et al. Expires December 25, 2020 [Page 4] Internet-Draft EKT SRTP June 2020 appears at the end of the SRTP packet. It appears after the optional authentication tag if one is present, otherwise the EKTField appears after the ciphertext portion of the packet. EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key Identifier) or with SRTP's [RFC3711], as those SRTP features duplicate some of the functions of EKT. Senders MUST NOT include MKI when using EKT. Receivers SHOULD simply ignore any MKI field received if EKT is in use. This document defines the use of EKT with SRTP. Its use with SRTCP would be similar, but is reserved for a future specification. SRTP is preferred for transmitting key material because it shares fate with the transmitted media, because SRTP rekeying can occur without concern for RTCP transmission limits, and because it avoids the need for SRTCP compound packets with RTP translators and mixers. 4.1. EKTField Formats The EKTField uses the format defined in Figure 1 for the FullEKTField and ShortEKTField. The EKTField appended to an SRTP packet can be referred to as an "EKT tag". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : EKT Ciphertext : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: FullEKTField format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+ Figure 2: ShortEKTField format The following shows the syntax of the EKTField expressed in ABNF [RFC5234]. The EKTField is added to the end of an SRTP packet. The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order. The EKTCiphertext is Jennings, et al. Expires December 25, 2020 [Page 5] Internet-Draft EKT SRTP June 2020 computed by encrypting the EKTPlaintext using the EKTKey. Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. BYTE = %x00-FF EKTMsgTypeFull = %x02 EKTMsgTypeShort = %x00 EKTMsgTypeExtension = %x03-FF ; Message type %x01 is reserved, due to ; usage by legacy implementations. EKTMsgLength = 2BYTE; SRTPMasterKeyLength = BYTE SRTPMasterKey = 1*242BYTE SSRC = 4BYTE; SSRC from RTP ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC EKTPlaintext = SRTPMasterKeyLength SRTPMasterKey SSRC ROC EKTCiphertext = 1*251BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) Epoch = 2BYTE SPI = 2BYTE FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull ShortEKTField = EKTMsgTypeShort ExtensionData = 1*1024BYTE ExtensionEKTField = ExtensionData EKTMsgLength EKTMsgTypeExtension EKTField = FullEKTField / ShortEKTField / ExtensionEKTField Figure 3: EKTField Syntax These fields and data elements are defined as follows: EKTPlaintext: The data that is input to the EKT encryption operation. This data never appears on the wire, and is used only in computations internal to EKT. This is the concatenation of the SRTP Master Key and its length, the SSRC, and the ROC. EKTCiphertext: The data that is output from the EKT encryption operation, described in Section 4.4. This field is included in SRTP packets when EKT is in use. The length of EKTCiphertext can be larger than the length of the EKTPlaintext that was encrypted. Jennings, et al. Expires December 25, 2020 [Page 6] Internet-Draft EKT SRTP June 2020 SRTPMasterKey: On the sender side, the SRTP Master Key associated with the indicated SSRC. SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This depends on the cipher suite negotiated for SRTP using SDP Offer/ Answer [RFC3264] for the SRTP. SSRC: On the sender side, this is the SSRC for this SRTP source. The length of this field is 32 bits. The SSRC value in the EKT tag MUST be the same as the one in the header of the SRTP packet to which the tag is appended. Rollover Counter (ROC): On the sender side, this is set to the current value of the SRTP rollover counter in the SRTP context associated with the SSRC in the SRTP packet. The length of this field is 32 bits. Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing the packet, within a given conference. The length of this field is 16 bits, representing a two-byte integer in network byte order. The parameters identified by this field are: o The EKT cipher used to process the packet. o The EKTKey used to process the packet. o The SRTP Master Salt associated with any master key encrypted with this EKT Key. The master salt is communicated separately, via signaling, typically along with the EKTKey. (Recall that the SRTP master salt is used in the formation of IVs / nonces.) Epoch: This field indicates how many SRTP keys have been sent for this SSRC under the current EKTKey, prior to the current key, as a two-byte integer in network byte order. It starts at zero at the beginning of a session and resets to zero whenever the EKTKey is changed (i.e., when a new SPI appears). The epoch for an SSRC increments by one every time the sender transmits a new key. The recipient of a FullEKTField MUST reject any future FullEKTField for this SPI and SSRC that has an equal or lower epoch value to an epoch already seen. Together, these data elements are called an EKT parameter set. Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. EKTMsgLength: All EKT messages types other than the ShortEKTField have a length as second from the last element. This is the length in Jennings, et al. Expires December 25, 2020 [Page 7] Internet-Draft EKT SRTP June 2020 octets (in network byte order) of either the FullEKTField/ ExtensionEKTField including this length field and the following EKT Message Type. Message Type: The last byte is used to indicate the type of the EKTField. This MUST be 2 for the FullEKTField format and 0 in ShortEKTField format. If a received EKT tag has an unknown message type, then the receiver MUST discard the whole EKT tag. 4.2. SPIs and EKT Parameter Sets The SPI field identifies the parameters for how the EKT tag should be processed: o The EKTKey and EKT cipher used to process the packet. o The SRTP Master Salt associated with any master key encrypted with this EKT Key. The master salt is communicated separately, via signaling, typically along with the EKTKey. Together, these data elements are called an "EKT parameter set". Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. The association of a given parameter set with a given SPI value is configured by some other protocol, e.g., the DTLS-SRTP extension defined in Section 5. 4.3. Packet Processing and State Machine At any given time, each SRTP source has associated with it a single EKT parameter set. This parameter set is used to process all outbound packets, and is called the outbound parameter set for that SSRC. There may be other EKT parameter sets that are used by other SRTP sources in the same session, including other SRTP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint each with their own EKT parameter set). All of the received EKT parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in processing inbound SRTP traffic. If a participant deletes an EKT parameter set (e.g., because of space limitations, then it will be unable to process Full EKT Tags containing updated media keys, and thus unable to receive media from a particpant that has changed its media key. Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets. The decision on which to send when is specified in Section 4.6. Jennings, et al. Expires December 25, 2020 [Page 8] Internet-Draft EKT SRTP June 2020 4.3.1. Outbound Processing See Section 4.6 which describes when to send an SRTP packet with a FullEKTField. If a FullEKTField is not being sent, then a ShortEKTField is sent so the receiver can correctly determine how to process the packet. When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created as follows, or uses an equivalent set of steps. 1. The Security Parameter Index (SPI) field is set to the value of the Security Parameter Index that is associated with the outbound parameter set. 2. The EKTPlaintext field is computed from the SRTP Master Key, SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP Master Key, and SSRC used in EKT processing MUST be the same as the one used in the SRTP processing. 3. The EKTCiphertext field is set to the ciphertext created by encrypting the EKTPlaintext with the EKTCipher using the EKTKey as the encryption key. The encryption process is detailed in Section 4.4. 4. Then the FullEKTField is formed using the EKTCiphertext and the SPI associated with the EKTKey used above. Also appended are the Length and Message Type using the FullEKTField format. * Note: the value of the EKTCiphertext field is identical in successive packets protected by the same EKTKey and SRTP master key. This value MAY be cached by an SRTP sender to minimize computational effort. The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload. When a packet is sent with the ShortEKTField, the ShortEKFField is simply appended to the packet. Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms after sending any new key in a FullEKTField value. This gives all the receivers in the system time to get the new key before they start receiving media encrypted with the new key. (The specific value of 250ms is chosen to represent a reasonable upper bound on the amount of latency and jitter that is tolerable in a real-time context.) Jennings, et al. Expires December 25, 2020 [Page 9] Internet-Draft EKT SRTP June 2020 4.3.2. Inbound Processing When receiving a packet on a RTP stream, the following steps are applied for each SRTP received packet. 1. The final byte is checked to determine which EKT format is in use. When an SRTP packet contains a ShortEKTField, the ShortEKTField is removed from the packet then normal SRTP processing occurs. If the packet contains a FullEKTField, then processing continues as described below. The reason for using the last byte of the packet to indicate the type is that the length of the SRTP part is not known until the decryption has occurred. At this point in the processing, there is no easy way to know where the EKTField would start. However, the whole UDP packet has been received, so instead of the starting at the front of the packet, the parsing works backwards at the end of the packet and thus the type is placed at the very end of the packet. 2. The Security Parameter Index (SPI) field is used to find the right EKT parameter set to be used for processing the packet. If there is no matching SPI, then the verification function MUST return an indication of authentication failure, and the steps described below are not performed. The EKT parameter set contains the EKTKey, EKTCipher, and the SRTP Master Salt. 3. The EKTCiphertext is authenticated and decrypted, as described in Section 4.4, using the EKTKey and EKTCipher found in the previous step. If the EKT decryption operation returns an authentication failure, then EKT processing MUST be aborted. The receiver SHOULD discard the whole UDP packet. 4. The resulting EKTPlaintext is parsed as described in Section 4.1, to recover the SRTP Master Key, SSRC, and ROC fields. The SRTP Master Salt that is associated with the EKTKey is also retrieved. If the value of the srtp_master_salt sent as part of the EKTkey is longer than needed by SRTP, then it is truncated by taking the first N bytes from the srtp_master_salt field. 5. If the SSRC in the EKTPlaintext does not match the SSRC of the SRTP packet received, then this FullEKTField MUST be discarded and the following steps in this list skipped. After stripping the FullEKTField, the remainder of the SRTP packet MAY be processed as normal. 6. The SRTP Master Key, ROC, and SRTP Master Salt from the previous steps are saved in a map indexed by the SSRC found in the EKTPlaintext and can be used for any future crypto operations on the inbound packets with that SSRC. Jennings, et al. Expires December 25, 2020 [Page 10] Internet-Draft EKT SRTP June 2020 * Unless the transform specifies other acceptable key lengths, the length of the SRTP Master Key MUST be the same as the master key length for the SRTP transform in use. If this is not the case, then the receiver MUST abort EKT processing and SHOULD discared the whole UDP packet. * If the length of the SRTP Master Key is less than the master key length for the SRTP transform in use, and the transform specifies that this length is acceptable, then the SRTP Master Key value is used to replace the first bytes in the existing master key. The other bytes remain the same as in the old key. For example, the Double GCM transform [I-D.ietf-perc-double] allows replacement of the first, "end to end" half of the master key. 7. At this point, EKT processing has successfully completed, and the normal SRTP processing takes place. The value of the EKTCiphertext field is identical in successive packets protected by the same EKT parameter set and the same SRTP master key, and ROC. SRTP senders and receivers MAY cache an EKTCiphertext value to optimize processing in cases where the master key hasn't changed. Instead of encrypting and decrypting, senders can simply copy the pre-computed value and receivers can compare a received EKTCiphertext to the known value. Section 4.3.1 recommends that SRTP senders continue using an old key for some time after sending a new key in an EKT tag. Receivers that wish to avoid packet loss due to decryption failures MAY perform trial decryption with both the old key and the new key, keeping the result of whichever decryption succeeds. Note that this approach is only compatible with SRTP transforms that include integrity protection. When receiving a new EKTKey, implementations need to use the ekt_ttl field (see Section 5.2.2) to create a time after which this key cannot be used and they also need to create a counter that keeps track of how many times the key has been used to encrypt data to ensure it does not exceed the T value for that cipher (see Section 4.4). If either of these limits are exceeded, the key can no longer be used for encryption. At this point implementation need to either use the call signaling to renegotiate a new session or need to terminate the existing session. Terminating the session is a reasonable implementation choice because these limits should not be exceeded except under an attack or error condition. Jennings, et al. Expires December 25, 2020 [Page 11] Internet-Draft EKT SRTP June 2020 4.4. Ciphers EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. This specification defines the interface to the cipher, in order to abstract the interface away from the details of that function. This specification also defines the default cipher that is used in EKT. The default cipher described in Section 4.4.1 MUST be implemented, but another cipher that conforms to this interface MAY be used. The cipher used for a given EKTCiphertext value is negotiated using the supported_ekt_ciphers and indicated with the SPI value in the FullEKTField. An EKTCipher consists of an encryption function and a decryption function. The encryption function E(K, P) takes the following inputs: o a secret key K with a length of L bytes, and o a plaintext value P with a length of M bytes. The encryption function returns a ciphertext value C whose length is N bytes, where N may be larger than M. The decryption function D(K, C) takes the following inputs: o a secret key K with a length of L bytes, and o a ciphertext value C with a length of N bytes. The decryption function returns a plaintext value P that is M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = P for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used for encryption more that T times. Note that if the same FullEKTField is retransmitted 3 times, that only counts as 1 encryption. Security requirements for EKT ciphers are discussed in Section 6. 4.4.1. AES Key Wrap The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N = M + (M mod 8) + 8 octets. Jennings, et al. Expires December 25, 2020 [Page 12] Internet-Draft EKT SRTP June 2020 It can be used with key sizes of L = 16, and L = 32 octets, and its use with those key sizes is indicated as AESKW128, or AESKW256, respectively. The key size determines the length of the AES key used by the Key Wrap algorithm. With this cipher, T=2^48. +----------+----+------+ | Cipher | L | T | +----------+----+------+ | AESKW128 | 16 | 2^48 | | AESKW256 | 32 | 2^48 | +----------+----+------+ Table 1: EKT Ciphers As AES-128 is the mandatory to implement transform in SRTP, AESKW128 MUST be implemented for EKT and AESKW256 MAY be implemented. 4.4.2. Defining New EKT Ciphers Other specifications may extend this document by defining other EKTCiphers as described in Section 7. This section defines how those ciphers interact with this specification. An EKTCipher determines how the EKTCiphertext field is written, and how it is processed when it is read. This field is opaque to the other aspects of EKT processing. EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input. The values of the parameters L, and T MUST be defined by each EKTCipher. The cipher MUST provide integrity protection. 4.5. Synchronizing Operation If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a new FullEKTField and eventually begin encrypting with it, as defined in Section 4.3.1. This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey. 4.6. Timing and Reliability Consideration A system using EKT learns the SRTP master keys distributed with the FullEKTField sent with the SRTP, rather than with call signaling. A receiver can immediately decrypt an SRTP packet, provided the SRTP packet contains a FullEKTField. Jennings, et al. Expires December 25, 2020 [Page 13] Internet-Draft EKT SRTP June 2020 This section describes how to reliably and expediently deliver new SRTP master keys to receivers. There are three cases to consider. The first case is a new sender joining a session, which needs to communicate its SRTP master key to all the receivers. The second case is a sender changing its SRTP master key which needs to be communicated to all the receivers. The third case is a new receiver joining a session already in progress which needs to know the sender's SRTP master key. The three cases are: New sender: A new sender SHOULD send a packet containing the FullEKTField as soon as possible, always before or coincident with sending its initial SRTP packet. To accommodate packet loss, it is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets. If the sender does not send a FullEKTField in its initial packets and receivers have not otherwise been provisioned with a decryption key, then decryption will fail and SRTP packets will be dropped until the receiver receives a FullEKTField from the sender. Rekey: By sending EKT tag over SRTP, the rekeying event shares fate with the SRTP packets protected with that new SRTP master key. To accommodate packet loss, it is RECOMMENDED that three consecutive packets contain the FullEKTField be transmitted. New receiver: When a new receiver joins a session it does not need to communicate its sending SRTP master key (because it is a receiver). When a new receiver joins a session, the sender is generally unaware of the receiver joining the session. Thus, senders SHOULD periodically transmit the FullEKTField. That interval depends on how frequently new receivers join the session, the acceptable delay before those receivers can start processing SRTP packets, and the acceptable overhead of sending the FullEKTField. If sending audio and video, the RECOMMENDED frequency is the same as the rate of intra coded video frames. If only sending audio, the RECOMMENDED frequency is every 100ms. In general, sending EKT tags less frequently will consume less bandwidth, but increase the time it takes for a join or rekey to take effect. Applications should schedule the sending of EKT tags in a way that makes sense for their bandwidth and latency requirements. Jennings, et al. Expires December 25, 2020 [Page 14] Internet-Draft EKT SRTP June 2020 5. Use of EKT with DTLS-SRTP This document defines an extension to DTLS-SRTP called SRTP EKTKey Transport which enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to the client. This allows those peers to process EKT keying material in SRTP and retrieve the embedded SRTP keying material. This combination of protocols is valuable because it combines the advantages of DTLS, which has strong authentication of the endpoint and flexibility, along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can allow EKT keys to be tunneled through an untrusted relay such as a centralized conference bridge. For more details, see [I-D.ietf-perc-private-media-framework]. 5.1. DTLS-SRTP Recap DTLS-SRTP [RFC5764] uses an extended DTLS exchange between two peers to exchange keying material, algorithms, and parameters for SRTP. The SRTP flow operates over the same transport as the DTLS-SRTP exchange (i.e., the same 5-tuple). DTLS-SRTP combines the performance and encryption flexibility benefits of SRTP with the flexibility and convenience of DTLS-integrated key and association management. DTLS-SRTP can be viewed in two equivalent ways: as a new key management method for SRTP, and a new RTP-specific data format for DTLS. 5.2. SRTP EKT Key Transport Extensions to DTLS-SRTP This document defines a new TLS negotiated extension supported_ekt_ciphers and a new TLS handshake message type ekt_key. The extension negotiates the cipher to be used in encrypting and decrypting EKTCiphertext values, and the handshake message carries the corresponding key. Figure 4 shows a message flow of DTLS 1.3 client and server using EKT configured using the DTLS extensions described in this section. (The initial cookie exchange and other normal DTLS messages are omitted.) To be clear, EKT can be used with versions of DTLS prior to 1.3. The only difference is that in a pre-1.3 TLS stacks will not have built- in support for generating and processing ACK messages. Jennings, et al. Expires December 25, 2020 [Page 15] Internet-Draft EKT SRTP June 2020 Client Server ClientHello + use_srtp + supported_ekt_ciphers --------> ServerHello {EncryptedExtensions} + use_srtp + supported_ekt_ciphers {... Finished} <-------- {... Finished} --------> [ACK] <-------- [EKTKey] [ACK] --------> |SRTP packets| <-------> |SRTP packets| + + {} Messages protected using DTLS handshake keys [] Messages protected using DTLS application traffic keys <> Messages protected using the EKTKey and EKT cipher || Messages protected using the SRTP Master Key sent in a Full EKT Tag Figure 4 In the context of a multi-party SRTP session in which each endpoint performs a DTLS handshake as a client with a central DTLS server, the extensions defined in this document allow the DTLS server to set a common EKTKey for all participants. Each endpoint can then use EKT tags encrypted with that common key to inform other endpoint of the keys it uses to protect SRTP packets. This avoids the need for many individual DTLS handshakes among the endpoints, at the cost of preventing endpoints from directly authenticating one another. Jennings, et al. Expires December 25, 2020 [Page 16] Internet-Draft EKT SRTP June 2020 Client A Server Client B <----DTLS Handshake----> <--------EKTKey--------- <----DTLS Handshake----> ---------EKTKey--------> -------------SRTP Packet + EKT Tag-------------> <------------SRTP Packet + EKT Tag-------------- 5.2.1. Negotiating an EKTCipher To indicate its support for EKT, a DTLS-SRTP client includes in its ClientHello an extension of type supported_ekt_ciphers listing the ciphers used for EKT by the client supports in preference order, with the most preferred version first. If the server agrees to use EKT, then it includes a supported_ekt_ciphers extension in its ServerHello containing a cipher selected from among those advertised by the client. The extension_data field of this extension contains an "EKTCipher" value, encoded using the syntax defined in [RFC8446]: enum { reserved(0), aeskw_128(1), aeskw_256(2), } EKTCipherType; struct { select (Handshake.msg_type) { case client_hello: EKTCipherType supported_ciphers<1..255>; case server_hello: EKTCipherType selected_cipher; }; } EKTCipher; 5.2.2. Establishing an EKT Key Once a client and server have concluded a handshake that negotiated an EKTCipher, the server MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext values. EKTKeys are sent in encrypted handshake records, using handshake type ekt_key(TBD). The body of the handshake message contains an EKTKey structure: Jennings, et al. Expires December 25, 2020 [Page 17] Internet-Draft EKT SRTP June 2020 [[ NOTE: RFC Editor, please replace "TBD" above with the code point assigned by IANA ]] struct { opaque ekt_key_value<1..256>; opaque srtp_master_salt<1..256>; uint16 ekt_spi; uint24 ekt_ttl; } EKTKey; The contents of the fields in this message are as follows: ekt_key_value The EKTKey that the recipient should use when generating EKTCiphertext values srtp_master_salt The SRTP Master Salt to be used with any Master Key encrypted with this EKT Key ekt_spi The SPI value to be used to reference this EKTKey and SRTP Master Salt in EKT tags (along with the EKT cipher negotiated in the handshake) ekt_ttl The maximum amount of time, in seconds, that this EKTKey can be used. The ekt_key_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires. If the server did not provide a supported_ekt_ciphers extension in its ServerHello, then EKTKey messages MUST NOT be sent by the client or the server. When an EKTKey is received and processed successfully, the recipient MUST respond with an ACK message as described in Section 7 of [I-D.ietf-tls-dtls13]. The EKTKey message and ACK MUST be retransmitted following the rules of the negotiated version of DTLS. EKT MAY be used with versions of DTLS prior to 1.3. In such cases, the ACK message is still used to provide reliability. Thus, DTLS implementations supporting EKT with DTLS pre-1.3 will need to have explicit affordances for sending the ACK message in response to an EKTKey message, and for verifying that an ACK message was received. The retransmission rules for both sides are otherwise defined by the negotiated version of DTLS. Jennings, et al. Expires December 25, 2020 [Page 18] Internet-Draft EKT SRTP June 2020 If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. 5.3. Offer/Answer Considerations When using EKT with DTLS-SRTP, the negotiation to use EKT is done at the DTLS handshake level and does not change the [RFC3264] Offer / Answer messaging. 5.4. Sending the DTLS EKTKey Reliably The DTLS EKTKey message is sent using the retransmissions specified in Section 4.2.4. of DTLS [RFC6347]. Retransmission is finished with an ACK message or an alert is received. 6. Security Considerations EKT inherits the security properties of the the key management protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP extension defined in this document. With EKT, each SRTP sender and receiver MUST generate distinct SRTP master keys. This property avoids any security concern over the re- use of keys, by empowering the SRTP layer to create keys on demand. Note that the inputs of EKT are the same as for SRTP with key- sharing: a single key is provided to protect an entire SRTP session. However, EKT remains secure even when SSRC values collide. SRTP master keys MUST be randomly generated, and [RFC4086] offers some guidance about random number generation. SRTP master keys MUST NOT be re-used for any other purpose, and SRTP master keys MUST NOT be derived from other SRTP master keys. The EKT Cipher includes its own authentication/integrity check. For an attacker to successfully forge a FullEKTField, it would need to defeat the authentication mechanisms of the EKT Cipher authentication mechanism. The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another SRTP stream. This mitigates the impact of the cut-and-paste attacks that arise due to the lack of a cryptographic binding between the EKT tag and the rest of the SRTP packet. SRTP tags can only be cut-and- pasted within the stream of packets sent by a given RTP endpoint; an attacker cannot "cross the streams" and use an EKT tag from one SSRC to reset the key for another SSRC. The epoch field in the FullEKTField also prevents an attacker from rolling back to a previous key. Jennings, et al. Expires December 25, 2020 [Page 19] Internet-Draft EKT SRTP June 2020 An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system by causing the receiving system to decrypt the EKT ciphertext and detect an authentication failure. In some cases, caching the previous values of the Ciphertext as described in Section 4.3.2 helps mitigate this issue. In a similar vein, EKT has no replay protection, so an attacker could implant improper keys in receivers by capturing EKTCiphertext values encrypted with a given EKTKey and replaying them in a different context, e.g., from a different sender. When the underlying SRTP transform provides integrity protection, this attack will just result in packet loss. If it does not, then it will result in random data being fed to RTP payload processing. An attacker that is in a position to mount these attacks, however, could achieve the same effects more easily without attacking EKT. The key encryption keys distributed with EKTKey messages are group shared symmetric keys, which means they do not provide protection within the group. Group members can impersonate each other; for example, any group member can generate an EKT tag for any SSRC. The entity that distributes EKTKeys can decrypt any keys distributed using EKT, and thus any media protected with those keys. Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 5.2. The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher and at least as strong as the DTLS-SRTP ciphers. Part of the EKTPlaintext is known, or easily guessable to an attacker. Thus, the EKT Cipher MUST resist known plaintext attacks. In practice, this requirement does not impose any restrictions on our choices, since the ciphers in use provide high security even when much plaintext is known. An EKT cipher MUST resist attacks in which both ciphertexts and plaintexts can be adaptively chosen and adversaries that can query both the encryption and decryption functions adaptively. In some systems, when a member of a conference leaves the conferences, the conferences is rekeyed so that member no longer has the key. When changing to a new EKTKey, it is possible that the attacker could block the EKTKey message getting to a particular Jennings, et al. Expires December 25, 2020 [Page 20] Internet-Draft EKT SRTP June 2020 endpoint and that endpoint would keep sending media encrypted using the old key. To mitigate that risk, the lifetime of the EKTKey MUST be limited using the ekt_ttl. 7. IANA Considerations 7.1. EKT Message Types IANA is requested to create a new table for "EKT Messages Types" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are: +--------------+-------+---------------+ | Message Type | Value | Specification | +--------------+-------+---------------+ | Short | 0 | RFCAAAA | | Full | 2 | RFCAAAA | | Unallocated | 3-254 | RFCAAAA | | Reserved | 255 | RFCAAAA | +--------------+-------+---------------+ Table 2: EKT Messages Types Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. New entries to this table can be added via "Specification Required" as defined in [RFC8126]. IANA SHOULD prefer allocation of even values over odd ones until the even code points are consumed to avoid conflicts with pre standard versions of EKT that have been deployed. Allocated values MUST be in the range of 0 to 254. All new EKT messages MUST be defined to have a length as second from the last element, as specified. 7.2. EKT Ciphers IANA is requested to create a new table for "EKT Ciphers" in the "Real-Time Transport Protocol (RTP) Parameters" registry. The initial values in this registry are: Jennings, et al. Expires December 25, 2020 [Page 21] Internet-Draft EKT SRTP June 2020 +-------------+-------+---------------+ | Name | Value | Specification | +-------------+-------+---------------+ | AESKW128 | 0 | RFCAAAA | | AESKW256 | 1 | RFCAAAA | | Unallocated | 2-254 | | | Reserved | 255 | RFCAAAA | +-------------+-------+---------------+ Table 3: EKT Cipher Types Note to RFC Editor: Please replace RFCAAAA with the RFC number for this specification. New entries to this table can be added via "Specification Required" as defined in [RFC8126]. The expert SHOULD ensure the specification defines the values for L and T as required in Section 4.4 of RFCAAAA. Allocated values MUST be in the range of 0 to 254. 7.3. TLS Extensions IANA is requested to add supported_ekt_ciphers as a new extension name to the "TLS ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry: Value: [TBD-at-Registration] Extension Name: supported_ekt_ciphers TLS 1.3: CH, SH Recommended: Y Reference: RFCAAAA [[ Note to RFC Editor: TBD will be allocated by IANA. ]] 7.4. TLS Handshake Type IANA is requested to add ekt_key as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry: Value: [TBD-at-Registration] Description: ekt_key DTLS-OK: Y Reference: RFCAAAA Comment: [[ Note to RFC Editor: TBD will be allocated by IANA. ]] Jennings, et al. Expires December 25, 2020 [Page 22] Internet-Draft EKT SRTP June 2020 8. Acknowledgements Thank you to Russ Housley provided detailed review and significant help with crafting text for this document. Thanks to David Benham, Yi Cheng, Lakshminath Dondeti, Kai Fischer, Nermeen Ismail, Paul Jones, Eddy Lem, Jonathan Lennox, Michael Peck, Rob Raymond, Sean Turner, Magnus Westerlund, and Felix Wyss for fruitful discussions, comments, and contributions to this document. 9. References 9.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, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, DOI 10.17487/RFC5649, September 2009, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Jennings, et al. Expires December 25, 2020 [Page 23] Internet-Draft EKT SRTP June 2020 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 9.2. Informative References [I-D.ietf-perc-double] Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP Double Encryption Procedures", draft-ietf-perc-double-12 (work in progress), August 2019. [I-D.ietf-perc-private-media-framework] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC)", draft-ietf-perc-private-media- framework-12 (work in progress), June 2019. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 2020. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . Authors' Addresses Cullen Jennings Cisco Systems Email: fluffy@iii.ca Jennings, et al. Expires December 25, 2020 [Page 24] Internet-Draft EKT SRTP June 2020 John Mattsson Ericsson AB Email: john.mattsson@ericsson.com David A. McGrew Cisco Systems Email: mcgrew@cisco.com Dan Wing Citrix Systems, Inc. Email: dwing-ietf@fuggles.com Flemming Andreason Cisco Systems Email: fandreas@cisco.com Jennings, et al. Expires December 25, 2020 [Page 25] ./draft-ietf-pim-igmp-mld-snooping-yang-18.txt0000644000764400076440000024042713715657533020470 0ustar iustyiustyPIM Working Group H. Zhao Internet Draft Ericsson Intended status: Standards Track X. Liu Expires: February 14, 2021 Volta Networks Y. Liu China Mobile M. Sivakumar Juniper A. Peter Individual August 15, 2020 A Yang Data Model for IGMP and MLD Snooping draft-ietf-pim-igmp-mld-snooping-yang-18.txt Abstract This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices. The YANG module in this document conforms to Network Management Datastore Architecture (NMDA). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 14, 2021. Zhao & Liu, etc Expires February 14, 2021 [Page 1] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 Copyright Notice Copyright (c) 2020 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 1.1. Terminology...............................................3 1.2. Tree Diagrams.............................................3 1.3. Prefixes in Data Node Names...............................4 2. Design of Data Model...........................................4 2.1. Overview..................................................5 2.2. Optional Capabilities.....................................5 2.3. Position of Address Family in Hierarchy...................6 3. Module Structure...............................................6 3.1. IGMP Snooping Instances...................................7 3.2. MLD Snooping Instances....................................9 3.3. Using IGMP and MLD Snooping Instances....................11 3.4. IGMP and MLD Snooping Actions............................12 4. IGMP and MLD Snooping YANG Module.............................12 5. Security Considerations.......................................34 6. IANA Considerations...........................................36 6.1. XML Registry.............................................36 6.2. YANG Module Names Registry...............................36 7. References....................................................37 7.1. Normative References.....................................37 7.2. Informative References...................................39 Appendix A. Data Tree Example...................................40 A.1 Bridge service............................................40 A.2 L2VPN service.............................................43 Authors' Addresses...............................................47 Zhao & Liu, etc Expires February 14, 2021 [Page 2] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 1. Introduction This document defines a YANG [RFC7950] data model for the management of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping [RFC4541] devices. The YANG module in this document conforms to the Network Management Datastore Architecture defined in [RFC8342]. The "Network Management Datastore Architecture" (NMDA) adds the ability to inspect the current operational values for configuration, allowing clients to use identical paths for retrieving the configured values and the operational values. 1.1. Terminology The terminology for describing YANG data models is found in [RFC6020] and [RFC7950], including: * augment * data model * data node * identity * module The following terminologies are used in this document: * mrouter: multicast router, which is a router that has multicast routing enabled [RFC4286]. * mrouter interfaces: snooping switch ports where multicast routers are attached [RFC4541]. The following abbreviations are used in this document and defined model: IGMP: Internet Group Management Protocol [RFC3376]. MLD: Multicast Listener Discovery [RFC3810]. AC: Attachment Circuit [RFC3916]. PW: Pseudo Wire [RFC3916]. 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in Zhao & Liu, etc Expires February 14, 2021 [Page 3] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 [RFC8340]. 1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +----------+-----------------------+---------------------------------+ | Prefix | YANG module | Reference | +==========+=======================+=================================+ | inet | ietf-inet-types | [RFC6991] | +----------+-----------------------+---------------------------------+ | yang | ietf-yang-types | [RFC6991] | +----------+-----------------------+---------------------------------+ | if | ietf-interfaces | [RFC8343] | +----------+-----------------------+---------------------------------+ | rt | ietf-routing | [RFC8349] | +----------+-----------------------+---------------------------------+ | rt-types | ietf-routing-types | [RFC8294] | +----------+-----------------------+---------------------------------+ | ni | ietf-network-instance | [RFC8529] | +----------+-----------------------+---------------------------------+ | pw | ietf-pseudowires | [draft-ietf-bess-l2vpn-yang] | +----------+-----------------------+---------------------------------+ | l2vpn | ietf-l2vpn | [draft-ietf-bess-l2vpn-yang] | +----------+-----------------------+---------------------------------+ | dot1q | ieee802-dot1q-bridge | [dot1Qcp] | +----------+-----------------------+---------------------------------+ Table 1: Prefixes and Corresponding YANG Modules 2. Design of Data Model An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and sets up forwarding tables for multicast traffic. If a switch does not run IGMP/MLD snooping, multicast traffic will be flooded in the broadcast domain. If a switch runs IGMP/MLD snooping, multicast traffic will be forwarded based on the forwarding tables to avoid wasting bandwidth. The IGMP/MLD snooping switch does not need to run any of the IGMP/MLD Zhao & Liu, etc Expires February 14, 2021 [Page 4] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD protocols, the data model defined in this document does not augment, or even require, the IGMP/MLD data model defined in [RFC8652]. The model covers considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches [RFC4541]. IGMP and MLD snooping switches do not adhere to the conceptual model that provides the strict separation of functionality between different communications layers in the ISO model, and instead utilize information in the upper level protocol headers as factors to be considered in processing at the lower levels [RFC4541]. IGMP Snooping switches utilize IGMP, and could support IGMPv1 [RFC1112], IGMPv2 [RFC2236], and IGMPv3 [RFC3376]. MLD Snooping switches utilize MLD, and could support MLDv1 [RFC2710] and MLDv2 [RFC3810]. The goal of this document is to define a data model that provides a common user interface to IGMP and MLD Snooping. 2.1. Overview The IGMP and MLD Snooping YANG module defined in this document has all the common building blocks for the IGMP and MLD Snooping switches. The YANG module includes IGMP and MLD Snooping instance definition, using instance in the L2 service type of BRIDGE [dot1Qcp] and L2VPN [draft-ietf-bess-l2vpn-yang]. The module also includes actions for clearing IGMP and MLD Snooping group tables. 2.2. Optional Capabilities This model is designed to represent the basic capability subsets of IGMP and MLD Snooping. The main design goals of this document are that the basic capabilities described in the model are supported by any major now-existing implementation, and that the configuration of all implementations meeting the specifications is easy to express through some combination of the optional features in the model and simple vendor augmentations. There is also value in widely supported features being standardized, to provide a standardized way to access these features, to save work for individual vendors, and so that mapping between different vendors' configuration is not needlessly complicated. Therefore, this model declares a number of features representing capabilities that not all deployed devices support. The extensive use of feature declarations should also substantially simplify the capability negotiation process for a vendor's IGMP and MLD Snooping implementations. Zhao & Liu, etc Expires February 14, 2021 [Page 5] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 On the other hand, operational state parameters are not so widely designated as features, as there are many cases where the defaulting of an operational state parameter would not cause any harm to the system, and it is much more likely that an implementation without native support for a piece of operational state would be able to derive a suitable value for a state variable that is not natively supported. 2.3. Position of Address Family in Hierarchy IGMP Snooping only supports IPv4, while MLD Snooping only supports IPv6. The data model defined in this document can be used for both IPv4 and IPv6 address families. This document defines IGMP Snooping and MLD Snooping as separate schema branches in the structure. The benefits are: * The model can support IGMP Snooping (IPv4), MLD Snooping (IPv6), or both optionally and independently. Such flexibility cannot be achieved cleanly with a combined branch. * The structure is consistent with other YANG data models such as [RFC8652], which uses separate branches for IPv4 and IPv6. * Having separate branches for IGMP Snooping and MLD Snooping allows minor differences in their behavior to be modelled more simply and cleanly. The two branches can better support different features and node types. 3. Module Structure This model augments the core routing data model specified in [RFC8349]. +--rw routing +--rw router-id? +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw type | +--rw name | +--rw igmp-snooping-instance <= Augmented by this Model ... | +--rw mld-snooping-instance <= Augmented by this Model ... The "igmp-snooping-instance" container instantiates an IGMP Snooping Instance. The "mld-snooping-instance" container instantiates an MLD Snooping Instance. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [RFC8407]. Zhao & Liu, etc Expires February 14, 2021 [Page 6] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 3.1. IGMP Snooping Instances The YANG module ietf-igmp-mld-snooping augments /rt:routing/rt:control- plane-protocols/rt:control-plane-protocol to add the igmp-snooping- instance container. All the IGMP Snooping related attributes have been defined in the igmp- snooping-instance. The read-write attributes represent configurable data. The read-only attributes represent state data. One igmp-snooping-instance could be used in one BRIDGE [dot1Qcp] instance or L2VPN [draft-ietf-bess-l2vpn-yang] instance. One igmp- snooping-instance corresponds to one BRIDGE instance or one L2VPN instance. The value of l2-service-type in igmp-snooping-instance is bridge or l2vpn. When it is bridge, igmp-snooping-instance will be used in the BRIDGE service. When it is l2vpn, igmp-snooping-instance will be used in the L2VPN service. The values of bridge-mrouter-interface, l2vpn-mrouter-interface-ac, l2vpn-mrouter-interface-pw are filled by the snooping device dynamically. They are different from static-bridge-mrouter-interface, static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-interface-pw which are configured. The attributes under the interfaces show the statistics of IGMP Snooping related packets. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw igmp-snooping-instance {igmp-snooping}? +--rw l2-service-type? l2-service-type +--rw enable? boolean +--rw forwarding-table-type? enumeration +--rw explicit-tracking? boolean | {explicit-tracking}? +--rw lite-exclude-filter? empty | {lite-exclude-filter}? +--rw send-query? boolean +--rw immediate-leave? empty | {immediate-leave}? +--rw last-member-query-interval? uint16 +--rw query-interval? uint16 +--rw query-max-response-time? uint16 +--rw require-router-alert? boolean | {require-router-alert}? +--rw robustness-variable? uint8 +--rw static-bridge-mrouter-interface* if:interface-ref | {static-mrouter-interface}? +--rw static-l2vpn-mrouter-interface-ac* if:interface-ref | {static-mrouter-interface}? Zhao & Liu, etc Expires February 14, 2021 [Page 7] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 +--rw static-l2vpn-mrouter-interface-pw* pw:pseudowire-ref | {static-mrouter-interface}? +--rw igmp-version? uint8 +--rw querier-source? inet:ipv4-address +--rw static-l2-multicast-group* [group source-addr] | {static-l2-multicast-group}? | +--rw group | | rt-types:ipv4-multicast-group-address | +--rw source-addr | | rt-types:ipv4-multicast-source-address | +--rw bridge-outgoing-interface* if:interface-ref | +--rw l2vpn-outgoing-ac* if:interface-ref | +--rw l2vpn-outgoing-pw* pw:pseudowire-ref +--ro entries-count? yang:gauge32 +--ro bridge-mrouter-interface* if:interface-ref +--ro l2vpn-mrouter-interface-ac* if:interface-ref +--ro l2vpn-mrouter-interface-pw* pw:pseudowire-ref +--ro group* [address] | +--ro address | | rt-types:ipv4-multicast-group-address | +--ro mac-address? yang:phys-address | +--ro expire? rt-types:timer-value-seconds16 | +--ro up-time uint32 | +--ro last-reporter? inet:ipv4-address | +--ro source* [address] | +--ro address | | rt-types:ipv4-multicast-source-address | +--ro bridge-outgoing-interface* if:interface-ref | +--ro l2vpn-outgoing-ac* if:interface-ref | +--ro l2vpn-outgoing-pw* pw:pseudowire-ref | +--ro up-time uint32 | +--ro expire? | | rt-types:timer-value-seconds16 | +--ro host-count? yang:gauge32 | | {explicit-tracking}? | +--ro last-reporter? inet:ipv4-address | +--ro host* [host-address] {explicit-tracking}? | +--ro host-address inet:ipv4-address | +--ro host-filter-mode filter-mode-type +--ro interfaces +--ro interface* [name] +--ro name if:interface-ref +--ro statistics +--ro discontinuity-time? yang:date-and-time +--ro received | +--ro query-count? yang:counter64 | +--ro membership-report-v1-count? yang:counter64 | +--ro membership-report-v2-count? yang:counter64 | +--ro membership-report-v3-count? yang:counter64 | +--ro leave-count? yang:counter64 | +--ro pim-hello-count? yang:counter64 +--ro sent Zhao & Liu, etc Expires February 14, 2021 [Page 8] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 +--ro query-count? yang:counter64 +--ro membership-report-v1-count? yang:counter64 +--ro membership-report-v2-count? yang:counter64 +--ro membership-report-v3-count? yang:counter64 +--ro leave-count? yang:counter64 +--ro pim-hello-count? yang:counter64 3.2. MLD Snooping Instances The YANG module ietf-igmp-mld-snooping augments /rt:routing/rt:control- plane-protocols/rt:control-plane-protocol to add the mld-snooping- instance container. The mld-snooping-instance could be used in the BRIDGE [dot1Qcp] or L2VPN [draft-ietf-bess-l2vpn-yang] service to enable MLD Snooping. All the MLD Snooping related attributes have been defined in the mld- snooping-instance. The read-write attributes represent configurable data. The read-only attributes represent state data. The mld-snooping-instance has similar structure as IGMP snooping. Some of leaves are protocol related. The mld-snooping-instance uses IPv6 addresses and mld-version, while igmp-snooping-instance uses IPv4 addresses and igmp-version. Statistic counters in each of the above snooping instances are also tailored to the specific protocol type. One mld-snooping-instance could be used in one BRIDGE instance or L2VPN instance. One mld-snooping-instance corresponds to one BRIDGE instance or L2VPN instance. The value of l2-service-type in mld-snooping-instance is bridge or l2vpn. When it is bridge, mld-snooping-instance will be used in the BRIDGE service. When it is l2vpn, mld-snooping-instance will be used in the L2VPN service. The values of bridge-mrouter-interface, l2vpn-mrouter-interface-ac, l2vpn-mrouter-interface-pw are filled by the snooping device dynamically. They are different from static-bridge-mrouter-interface, static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-interface-pw which are configured. The attributes under the interfaces show the statistics of MLD Snooping related packets. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw mld-snooping-instance {mld-snooping}? +--rw l2-service-type? l2-service-type +--rw enable? boolean +--rw forwarding-table-type? enumeration +--rw explicit-tracking? boolean | {explicit-tracking}? +--rw lite-exclude-filter? empty Zhao & Liu, etc Expires February 14, 2021 [Page 9] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 | {lite-exclude-filter}? +--rw send-query? boolean +--rw immediate-leave? empty | {immediate-leave}? +--rw last-member-query-interval? uint16 +--rw query-interval? uint16 +--rw query-max-response-time? uint16 +--rw require-router-alert? boolean | {require-router-alert}? +--rw robustness-variable? uint8 +--rw static-bridge-mrouter-interface* if:interface-ref | {static-mrouter-interface}? +--rw static-l2vpn-mrouter-interface-ac* if:interface-ref | {static-mrouter-interface}? +--rw static-l2vpn-mrouter-interface-pw* pw:pseudowire-ref | {static-mrouter-interface}? +--rw mld-version? uint8 +--rw querier-source? inet:ipv6-address +--rw static-l2-multicast-group* [group source-addr] | {static-l2-multicast-group}? | +--rw group | | rt-types:ipv6-multicast-group-address | +--rw source-addr | | rt-types:ipv6-multicast-source-address | +--rw bridge-outgoing-interface* if:interface-ref | +--rw l2vpn-outgoing-ac* if:interface-ref | +--rw l2vpn-outgoing-pw* pw:pseudowire-ref +--ro entries-count? yang:gauge32 +--ro bridge-mrouter-interface* if:interface-ref +--ro l2vpn-mrouter-interface-ac* if:interface-ref +--ro l2vpn-mrouter-interface-pw* pw:pseudowire-ref +--ro group* [address] | +--ro address | | rt-types:ipv6-multicast-group-address | +--ro mac-address? yang:phys-address | +--ro expire? rt-types:timer-value-seconds16 | +--ro up-time uint32 | +--ro last-reporter? inet:ipv6-address | +--ro source* [address] | +--ro address | | rt-types:ipv6-multicast-source-address | +--ro bridge-outgoing-interface* if:interface-ref | +--ro l2vpn-outgoing-ac* if:interface-ref | +--ro l2vpn-outgoing-pw* pw:pseudowire-ref | +--ro up-time uint32 | +--ro expire? | | rt-types:timer-value-seconds16 | +--ro host-count? yang:gauge32 | | {explicit-tracking}? | +--ro last-reporter? inet:ipv6-address | +--ro host* [host-address] {explicit-tracking}? | +--ro host-address inet:ipv6-address Zhao & Liu, etc Expires February 14, 2021 [Page 10] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 | +--ro host-filter-mode filter-mode-type +--ro interfaces +--ro interface* [name] +--ro name if:interface-ref +--ro statistics +--ro discontinuity-time? yang:date-and-time +--ro received | +--ro query-count? yang:counter64 | +--ro report-v1-count? yang:counter64 | +--ro report-v2-count? yang:counter64 | +--ro done-count? yang:counter64 | +--ro pim-hello-count? yang:counter64 +--ro sent +--ro query-count? yang:counter64 +--ro report-v1-count? yang:counter64 +--ro report-v2-count? yang:counter64 +--ro done-count? yang:counter64 +--ro pim-hello-count? yang:counter64 3.3. Using IGMP and MLD Snooping Instances The igmp-snooping-instance could be used in the service of BRIDGE [dot1Qcp] or L2VPN [draft-ietf-bess-l2vpn-yang] to configure the IGMP Snooping. For the BRIDGE service this model augments /dot1q:bridges/dot1q:bridge to use igmp-snooping-instance. It means IGMP Snooping is enabled in the whole bridge. It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/ dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means IGMP Snooping is enabled in the specified VLAN on the bridge. augment /dot1q:bridges/dot1q:bridge: +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref augment /dot1q:bridges/dot1q:bridge/dot1q:component /dot1q:bridge-vlan/dot1q:vlan: +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref For the L2VPN service this model augments /ni:network-instances/ ni:network-instance/ni:ni-type/l2vpn:l2vpn [RFC8529] to use igmp- snooping-instance. It means IGMP Snooping is enabled in the specified l2vpn instance. Zhao & Liu, etc Expires February 14, 2021 [Page 11] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 augment /ni:network-instances/ni:network-instance/ni:ni-type /l2vpn:l2vpn: +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref The mld-snooping-instance could be used in concurrence with igmp- snooping-instance to configure the MLD Snooping. 3.4. IGMP and MLD Snooping Actions IGMP and MLD Snooping actions clear the specified IGMP and MLD Snooping group tables. If both source X and group Y are specified, only source X from group Y in that specific instance will be cleared. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw igmp-snooping-instance {igmp-snooping}? +---x clear-igmp-snooping-groups {action-clear-groups}? +---w input +---w group union +---w source rt-types:ipv4-multicast-source-address augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw mld-snooping-instance {mld-snooping}? +---x clear-mld-snooping-groups {action-clear-groups}? +---w input +---w group union +---w source rt-types:ipv6-multicast-source-address 4. IGMP and MLD Snooping YANG Module This module references [RFC1112],[RFC2236],[RFC2710],[RFC3376], [RFC3810],[RFC4541],[RFC5790],[RFC6636],[RFC6991],[RFC7761], [RFC8343],[RFC8529],[dot1Qcp], and [draft-ietf-bess-l2vpn-yang]. file ietf-igmp-mld-snooping@2020-08-07.yang module ietf-igmp-mld-snooping { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping"; prefix ims; import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } Zhao & Liu, etc Expires February 14, 2021 [Page 12] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-routing-types { prefix "rt-types"; reference "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-l2vpn { prefix "l2vpn"; reference "draft-ietf-bess-l2vpn-yang: YANG Data Model for MPLS-based L2VPN"; } import ietf-network-instance { prefix "ni"; reference "RFC 8529: YANG Data Model for Network Instances"; } import ietf-pseudowires { prefix "pw"; reference "draft-ietf-bess-l2vpn-yang: YANG Data Model for MPLS-based L2VPN"; } import ieee802-dot1q-bridge { prefix "dot1q"; reference "dot1Qcp: IEEE 802.1Qcp-2018 Bridges and Bridged Networks - Amendment: YANG Data Model"; } Zhao & Liu, etc Expires February 14, 2021 [Page 13] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 organization "IETF PIM Working Group"; contact "WG Web: WG List: Editors: Hongji Zhao Xufeng Liu Yisong Liu Anish Peter Mahesh Sivakumar "; description "The module defines a collection of YANG definitions common for all devices that implement Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping which is described in RFC 4541. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2020-08-07 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for IGMP and MLD Snooping"; } Zhao & Liu, etc Expires February 14, 2021 [Page 14] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 /* * Features */ feature igmp-snooping { description "Support IGMP snooping."; reference "RFC 4541"; } feature mld-snooping { description "Support MLD snooping."; reference "RFC 4541"; } feature immediate-leave { description "Support configuration of fast leave. The fast leave feature does not send last member query messages to hosts."; reference "RFC 3376"; } feature static-l2-multicast-group { description "Support configuration of L2 multicast static-group."; } feature static-mrouter-interface { description "Support multicast router interface explicitly configured by management"; reference "RFC 4541"; } feature action-clear-groups { description "Support clearing statistics by action for IGMP & MLD snooping."; } feature require-router-alert { description "Support configuration of require-router-alert."; reference "RFC 3376"; } feature lite-exclude-filter { Zhao & Liu, etc Expires February 14, 2021 [Page 15] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 description "Enable the support of the simplified EXCLUDE filter."; reference "RFC 5790"; } feature explicit-tracking { description "Support configuration of per instance explicit-tracking."; reference "RFC 6636"; } /* identities */ identity l2-service-type { description "Base identity for L2 service type in IGMP & MLD snooping"; } identity bridge { base l2-service-type; description "This identity represents BRIDGE service."; } identity l2vpn { base l2-service-type; description "This identity represents L2VPN service."; } identity filter-mode { description "Base identity for filter mode in IGMP & MLD snooping"; } identity include { base filter-mode; description "This identity represents include mode."; } identity exclude { base filter-mode; description "This identity represents exclude mode."; } identity igmp-snooping { base rt:control-plane-protocol; description Zhao & Liu, etc Expires February 14, 2021 [Page 16] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 "IGMP snooping"; } identity mld-snooping { base rt:control-plane-protocol; description "MLD snooping"; } /* * Typedefs */ typedef l2-service-type { type identityref { base "l2-service-type"; } description "The L2 service type used with IGMP & MLD snooping "; } typedef filter-mode-type { type identityref { base "filter-mode"; } description "The host filter mode"; } typedef igmp-mld-snooping-instance-ref { type leafref { path "/rt:routing/rt:control-plane-protocols"+ "/rt:control-plane-protocol/rt:name"; } description "This type is used by data models which need to reference IGMP & MLD snooping instance."; } /* * Groupings */ grouping instance-config-attributes-igmp-mld-snooping { description "IGMP and MLD snooping configuration of each VLAN."; leaf enable { type boolean; default false; description "Set the value to true to enable IGMP & MLD snooping."; } Zhao & Liu, etc Expires February 14, 2021 [Page 17] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 leaf forwarding-table-type { type enumeration { enum "mac" { description "MAC-based lookup mode"; } enum "ip" { description "IP-based lookup mode"; } } default "ip"; description "The default forwarding table type is ip"; } leaf explicit-tracking { if-feature explicit-tracking; type boolean; default false; description "Track the IGMPv3 and MLDv2 snooping membership reports from individual hosts. It contributes to saving network resources and shortening leave latency."; } leaf lite-exclude-filter { if-feature lite-exclude-filter; type empty; description "For IGMP Snooping, the presence of this leaf enables the support of the simplified EXCLUDE filter in the Lightweight IGMPv3 protocol, which simplifies the standard versions of IGMPv3. For MLD Snooping, the presence of this leaf enables the support of the simplified EXCLUDE filter in the Lightweight MLDv2 protocol, which simplifies the standard versions of MLDv2."; reference "RFC 5790"; } leaf send-query { type boolean; default false; description "Enable quick response for topology changes. To support IGMP snooping in a VLAN where PIM and IGMP are not configured. It cooperates with parameter querier-source."; } leaf immediate-leave { Zhao & Liu, etc Expires February 14, 2021 [Page 18] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 if-feature immediate-leave; type empty; description "When immediate leave is enabled, the IGMP software assumes that no more than one host is present on each VLAN port."; } leaf last-member-query-interval { type uint16 { range "10..10230"; } units deciseconds; default 10; description "Last Member Query Interval, which may be tuned to modify the leave latency of the network. It is represented in units of 1/10 second."; reference "RFC 3376. Sec. 8.8."; } leaf query-interval { type uint16; units seconds; default 125; description "The Query Interval is the interval between General Queries sent by the Querier."; reference "RFC 3376. Sec. 4.1.7, 8.2, 8.14.2."; } leaf query-max-response-time { type uint16; units deciseconds; default 100; description "Query maximum response time specifies the maximum time allowed before sending a responding report. It is represented in units of 1/10 second."; reference "RFC 3376. Sec. 4.1.1, 8.3, 8.14.3."; } leaf require-router-alert { if-feature require-router-alert; type boolean; default false; description "When the value is true, router alert should exist in the IP header of IGMP or MLD packet."; } leaf robustness-variable { type uint8 { Zhao & Liu, etc Expires February 14, 2021 [Page 19] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 range "1..7"; } default 2; description "Querier's Robustness Variable allows tuning for the expected packet loss on a network."; reference "RFC 3376. Sec. 4.1.6, 8.1, 8.14.1."; } leaf-list static-bridge-mrouter-interface { when 'derived-from-or-self(../l2-service-type,"ims:bridge")'; if-feature static-mrouter-interface; type if:interface-ref; description "static mrouter interface in BRIDGE forwarding"; } leaf-list static-l2vpn-mrouter-interface-ac { when 'derived-from-or-self(../l2-service-type,"ims:l2vpn")'; if-feature static-mrouter-interface; type if:interface-ref; description "static mrouter interface whose type is interface in L2VPN forwarding"; } leaf-list static-l2vpn-mrouter-interface-pw { when 'derived-from-or-self(../l2-service-type,"ims:l2vpn")'; if-feature static-mrouter-interface; type pw:pseudowire-ref; description "static mrouter interface whose type is PW in L2VPN forwarding"; } } // instance-config-attributes-igmp-mld-snooping grouping instance-state-group-attributes-igmp-mld-snooping { description "Attributes for both IGMP and MLD snooping groups."; leaf mac-address { type yang:phys-address; description "Destination MAC address for L2 multicast."; } leaf expire { type rt-types:timer-value-seconds16; units seconds; description "The time left before multicast group timeout."; } leaf up-time { Zhao & Liu, etc Expires February 14, 2021 [Page 20] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 type uint32; units seconds; mandatory true; description "The time elapsed since L2 multicast record created."; } } // instance-state-group-attributes-igmp-mld-snooping grouping instance-state-attributes-igmp-mld-snooping { description "State attributes for IGMP & MLD snooping instance."; leaf entries-count { type yang:gauge32; config false; description "The number of L2 multicast entries in IGMP & MLD snooping"; } leaf-list bridge-mrouter-interface { when 'derived-from-or-self(../l2-service-type,"ims:bridge")'; type if:interface-ref; config false; description "Indicates a list of mrouter interfaces dynamicly learned in a bridge. When this switch receives IGMP/MLD queries from a multicast router on an interface, the interface will become mrouter interface for IGMP/MLD snooping."; } leaf-list l2vpn-mrouter-interface-ac { when 'derived-from-or-self(../l2-service-type,"ims:l2vpn")'; type if:interface-ref; config false; description "The mrouter interface whose type is interface in L2VPN forwarding. When switch receives IGMP/MLD queries from multicast router on an interface, this interface will become mrouter interface for IGMP/MLD snooping."; } leaf-list l2vpn-mrouter-interface-pw { when 'derived-from-or-self(../l2-service-type,"ims:l2vpn")'; type pw:pseudowire-ref; config false; description "The mrouter interface whose type is PW in L2VPN forwarding. When switch receives IGMP/MLD queries from multicast router on a PW, this PW will become mrouter interface for IGMP/MLD snooping."; } Zhao & Liu, etc Expires February 14, 2021 [Page 21] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 } // instance-config-attributes-igmp-mld-snooping grouping instance-state-source-attributes-igmp-mld-snooping { description "State attributes for IGMP & MLD snooping instance."; leaf-list bridge-outgoing-interface { when 'derived-from-or-self(../../../l2-service- type,"ims:bridge")'; type if:interface-ref; description "Outgoing interface in BRIDGE forwarding"; } leaf-list l2vpn-outgoing-ac { when 'derived-from-or-self(../../../l2-service-type,"ims:l2vpn")'; type if:interface-ref; description "Outgoing Attachment Circuit (AC) in L2VPN"; } leaf-list l2vpn-outgoing-pw { when 'derived-from-or-self(../../../l2-service-type,"ims:l2vpn")'; type pw:pseudowire-ref; description "Outgoing Pseudo Wire (PW) in L2VPN"; } leaf up-time { type uint32; units seconds; mandatory true; description "The time elapsed since L2 multicast record created"; } leaf expire { type rt-types:timer-value-seconds16; units seconds; description "The time left before multicast group timeout."; } leaf host-count { if-feature explicit-tracking; type yang:gauge32; description "The number of host addresses."; } } // instance-state-source-attributes-igmp-mld-snooping grouping igmp-snooping-statistics { description "The statistics attributes for IGMP snooping."; Zhao & Liu, etc Expires February 14, 2021 [Page 22] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 leaf query-count { type yang:counter64; description "The number of Membership Query messages."; reference "RFC 2236"; } leaf membership-report-v1-count { type yang:counter64; description "The number of Version 1 Membership Report messages."; reference "RFC 1112"; } leaf membership-report-v2-count { type yang:counter64; description "The number of Version 2 Membership Report messages."; reference "RFC 2236"; } leaf membership-report-v3-count { type yang:counter64; description "The number of Version 3 Membership Report messages."; reference "RFC 3376"; } leaf leave-count { type yang:counter64; description "The number of Leave Group messages."; reference "RFC 2236"; } leaf pim-hello-count { type yang:counter64; description "The number of PIM hello messages."; reference "RFC 7761"; } } // igmp-snooping-statistics grouping mld-snooping-statistics { description "The statistics attributes for MLD snooping."; leaf query-count { type yang:counter64; description Zhao & Liu, etc Expires February 14, 2021 [Page 23] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 "The number of Multicast Listener Query messages."; reference "RFC 3810"; } leaf report-v1-count { type yang:counter64; description "The number of Version 1 Multicast Listener Report."; reference "RFC 2710"; } leaf report-v2-count { type yang:counter64; description "The number of Version 2 Multicast Listener Report."; reference "RFC 3810"; } leaf done-count { type yang:counter64; description "The number of Version 1 Multicast Listener Done."; reference "RFC 2710"; } leaf pim-hello-count { type yang:counter64; description "The number of PIM hello messages."; reference "RFC 7761"; } } // mld-snooping-statistics augment "/rt:routing/rt:control-plane-protocols"+ "/rt:control-plane-protocol" { when 'derived-from-or-self(rt:type, "ims:igmp-snooping")' { description "This container is only valid for IGMP snooping."; } description "IGMP snooping augmentation to control plane protocol configuration and state."; container igmp-snooping-instance { if-feature igmp-snooping; description "IGMP snooping instance to configure igmp-snooping."; leaf l2-service-type { type l2-service-type; default bridge; Zhao & Liu, etc Expires February 14, 2021 [Page 24] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 description "The l2-service-type indicates BRIDGE or L2VPN."; } uses instance-config-attributes-igmp-mld-snooping; leaf igmp-version { type uint8 { range "1..3"; } default 2; description "IGMP version."; } leaf querier-source { type inet:ipv4-address; description "Use the IGMP snooping querier to support IGMP snooping in a VLAN where PIM and IGMP are not configured. The IPv4 address is used as source address in messages."; } list static-l2-multicast-group { if-feature static-l2-multicast-group; key "group source-addr"; description "A static multicast route, (*,G) or (S,G)."; leaf group { type rt-types:ipv4-multicast-group-address; description "Multicast group IPv4 address"; } leaf source-addr { type rt-types:ipv4-multicast-source-address; description "Multicast source IPv4 address."; } leaf-list bridge-outgoing-interface { when 'derived-from-or-self(../../l2-service- type,"ims:bridge")'; type if:interface-ref; description "Outgoing interface in BRIDGE forwarding"; } leaf-list l2vpn-outgoing-ac { when 'derived-from-or-self(../../l2-service- type,"ims:l2vpn")'; type if:interface-ref; description "Outgoing Attachment Circuit (AC) in L2VPN"; Zhao & Liu, etc Expires February 14, 2021 [Page 25] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 } leaf-list l2vpn-outgoing-pw { when 'derived-from-or-self(../../l2-service- type,"ims:l2vpn")'; type pw:pseudowire-ref; description "Outgoing Pseudo Wire (PW) in L2VPN"; } } // static-l2-multicast-group uses instance-state-attributes-igmp-mld-snooping; list group { key "address"; config false; description "IGMP snooping information"; leaf address { type rt-types:ipv4-multicast-group-address; description "Multicast group IPv4 address"; } uses instance-state-group-attributes-igmp-mld-snooping; leaf last-reporter { type inet:ipv4-address; description "Address of the last host which has sent report to join the multicast group."; } list source { key "address"; description "Source IPv4 address for multicast stream"; leaf address { type rt-types:ipv4-multicast-source-address; description "Source IPv4 address for multicast stream"; } uses instance-state-source-attributes-igmp-mld-snooping; leaf last-reporter { type inet:ipv4-address; description "Address of the last host which has sent report to join the multicast group."; } Zhao & Liu, etc Expires February 14, 2021 [Page 26] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 list host { if-feature explicit-tracking; key "host-address"; description "List of multicast membership hosts of the specific multicast source-group."; leaf host-address { type inet:ipv4-address; description "Multicast membership host address."; } leaf host-filter-mode { type filter-mode-type; mandatory true; description "Filter mode for a multicast membership host may be either include or exclude."; } }// list host } // list source } // list group container interfaces { config false; description "Contains the interfaces associated with the IGMP snooping instance"; list interface { key "name"; description "A list of interfaces associated with the IGMP snooping instance"; leaf name { type if:interface-ref; description "The name of interface"; } container statistics { description "The interface statistics for IGMP snooping"; leaf discontinuity-time { type yang:date-and-time; Zhao & Liu, etc Expires February 14, 2021 [Page 27] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container received { description "Number of received snooped IGMP packets"; uses igmp-snooping-statistics; } container sent { description "Number of sent snooped IGMP packets"; uses igmp-snooping-statistics; } } } } action clear-igmp-snooping-groups { if-feature action-clear-groups; description "Clear IGMP snooping cache tables."; input { leaf group { type union { type enumeration { enum 'all-groups' { description "All multicast group addresses."; } } type rt-types:ipv4-multicast-group-address; } mandatory true; description "Multicast group IPv4 address. If value 'all-groups' is specified, all IGMP snooping group entries are cleared for specified source address."; } leaf source { type rt-types:ipv4-multicast-source-address; mandatory true; description "Multicast source IPv4 address. If value '*' is specified, Zhao & Liu, etc Expires February 14, 2021 [Page 28] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 all IGMP snooping source-group tables are cleared."; } } } // action clear-igmp-snooping-groups } // igmp-snooping-instance } // augment augment "/rt:routing/rt:control-plane-protocols"+ "/rt:control-plane-protocol" { when 'derived-from-or-self(rt:type, "ims:mld-snooping")' { description "This container is only valid for MLD snooping."; } description "MLD snooping augmentation to control plane protocol configuration and state."; container mld-snooping-instance { if-feature mld-snooping; description "MLD snooping instance to configure mld-snooping."; leaf l2-service-type { type l2-service-type; default bridge; description "The l2-service-type indicates BRIDGE or L2VPN."; } uses instance-config-attributes-igmp-mld-snooping; leaf mld-version { type uint8 { range "1..2"; } default 2; description "MLD version."; } leaf querier-source { type inet:ipv6-address; description "Use the MLD snooping querier to support MLD snooping where PIM and MLD are not configured. The IPv6 address is used as the source address in messages."; } list static-l2-multicast-group { if-feature static-l2-multicast-group; key "group source-addr"; description "A static multicast route, (*,G) or (S,G)."; Zhao & Liu, etc Expires February 14, 2021 [Page 29] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 leaf group { type rt-types:ipv6-multicast-group-address; description "Multicast group IPv6 address"; } leaf source-addr { type rt-types:ipv6-multicast-source-address; description "Multicast source IPv6 address."; } leaf-list bridge-outgoing-interface { when 'derived-from-or-self(../../l2-service- type,"ims:bridge")'; type if:interface-ref; description "Outgoing interface in BRIDGE forwarding"; } leaf-list l2vpn-outgoing-ac { when 'derived-from-or-self(../../l2-service- type,"ims:l2vpn")'; type if:interface-ref; description "Outgoing Attachment Circuit (AC) in L2VPN"; } leaf-list l2vpn-outgoing-pw { when 'derived-from-or-self(../../l2-service- type,"ims:l2vpn")'; type pw:pseudowire-ref; description "Outgoing Pseudo Wire (PW) in L2VPN"; } } // static-l2-multicast-group uses instance-state-attributes-igmp-mld-snooping; list group { key "address"; config false; description "MLD snooping statistics information"; leaf address { type rt-types:ipv6-multicast-group-address; description "Multicast group IPv6 address"; } uses instance-state-group-attributes-igmp-mld-snooping; leaf last-reporter { type inet:ipv6-address; Zhao & Liu, etc Expires February 14, 2021 [Page 30] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 description "Address of the last host which has sent report to join the multicast group."; } list source { key "address"; description "Source IPv6 address for multicast stream"; leaf address { type rt-types:ipv6-multicast-source-address; description "Source IPv6 address for multicast stream"; } uses instance-state-source-attributes-igmp-mld-snooping; leaf last-reporter { type inet:ipv6-address; description "Address of the last host which has sent report to join the multicast group."; } list host { if-feature explicit-tracking; key "host-address"; description "List of multicast membership hosts of the specific multicast source-group."; leaf host-address { type inet:ipv6-address; description "Multicast membership host address."; } leaf host-filter-mode { type filter-mode-type; mandatory true; description "Filter mode for a multicast membership host may be either include or exclude."; } }// list host } // list source } // list group container interfaces { config false; description "Contains the interfaces associated with the MLD snooping instance"; Zhao & Liu, etc Expires February 14, 2021 [Page 31] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 list interface { key "name"; description "A list of interfaces associated with the MLD snooping instance"; leaf name { type if:interface-ref; description "The name of interface"; } container statistics { description "The interface statistics for MLD snooping"; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container received { description "Number of received snooped MLD packets"; uses mld-snooping-statistics; } container sent { description "Number of sent snooped MLD packets"; uses mld-snooping-statistics; } } } } action clear-mld-snooping-groups { if-feature action-clear-groups; description "Clear MLD snooping cache tables."; input { Zhao & Liu, etc Expires February 14, 2021 [Page 32] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 leaf group { type union { type enumeration { enum 'all-groups' { description "All multicast group addresses."; } } type rt-types:ipv6-multicast-group-address; } mandatory true; description "Multicast group IPv6 address. If value 'all-groups' is specified, all MLD snooping group entries are cleared for specified source address."; } leaf source { type rt-types:ipv6-multicast-source-address; mandatory true; description "Multicast source IPv6 address. If value '*' is specified, all MLD snooping source-group tables are cleared."; } } } // action clear-mld-snooping-groups }// mld-snooping-instance } // augment augment "/dot1q:bridges/dot1q:bridge" { description "Use IGMP & MLD snooping instance in BRIDGE."; leaf igmp-snooping-instance { type igmp-mld-snooping-instance-ref; description "Configure IGMP snooping instance under bridge view"; } leaf mld-snooping-instance { type igmp-mld-snooping-instance-ref; description "Configure MLD snooping instance under bridge view"; } } augment "/dot1q:bridges/dot1q:bridge"+ "/dot1q:component/dot1q:bridge-vlan/dot1q:vlan" { description "Use IGMP & MLD snooping instance in certain VLAN of BRIDGE"; leaf igmp-snooping-instance { type igmp-mld-snooping-instance-ref; Zhao & Liu, etc Expires February 14, 2021 [Page 33] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 description "Configure IGMP snooping instance under VLAN view"; } leaf mld-snooping-instance { type igmp-mld-snooping-instance-ref; description "Configure MLD snooping instance under VLAN view"; } } augment "/ni:network-instances/ni:network-instance"+ "/ni:ni-type/l2vpn:l2vpn" { description "Use IGMP & MLD snooping instance in L2VPN."; leaf igmp-snooping-instance { type igmp-mld-snooping-instance-ref; description "Configure IGMP snooping instance in L2VPN."; } leaf mld-snooping-instance { type igmp-mld-snooping-instance-ref; description "Configure MLD snooping instance in L2VPN."; } } } 5. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network Zhao & Liu, etc Expires February 14, 2021 [Page 34] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ ims:igmp-snooping-instance ims:mld-snooping-instance The subtrees under /dot1q:bridges/dot1q:bridge ims:igmp-snooping-instance ims:mld-snooping-instance The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component /dot1q:bridge-vlan/dot1q:vlan ims:igmp-snooping-instance ims:mld-snooping-instance Unauthorized access to any data node of these subtrees can adversely affect the IGMP & MLD Snooping subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ ims:igmp-snooping-instance ims:mld-snooping-instance Unauthorized access to any data node of these subtrees can disclose the operational state information of IGMP & MLD Snooping on this device. The group/source/host information may expose multicast group memberships, and transitively the associations between the user on the host and the contents from the source which could be privately sensitive. Some of the action operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: Zhao & Liu, etc Expires February 14, 2021 [Page 35] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ ims:igmp-snooping-instance/ims:clear-igmp-snooping-groups ims:mld-snooping-instance/ims:clear-mld-snooping-groups Some of the actions in this YANG module may be considered sensitive or vulnerable in some network environments. The IGMP & MLD Snooping YANG module supports the "clear-igmp-snooping-groups" and "clear-mld- snooping-groups" actions. If unauthorized action is invoked, the IGMP and MLD Snooping group tables will be cleared unexpectedly. Especially when using wildcard, all the multicast traffic will be flooded in the broadcast domain. The devices that use this YANG module should heed the Security Considerations in [RFC4541]. 6. IANA Considerations RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number (and remove this note). 6.1. XML Registry This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping Registrant Contact: The IETF. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- 6.2. YANG Module Names Registry This document registers the following YANG modules in the YANG Module Names registry [RFC7950]: -------------------------------------------------------------------- name: ietf-igmp-mld-snooping namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping prefix: ims reference: RFC XXXX -------------------------------------------------------------------- Zhao & Liu, etc Expires February 14, 2021 [Page 36] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 7. References 7.1. Normative References [dot1Qcp] IEEE, "Standard for Local and metropolitan area networks-- Bridges and Bridged Networks--Amendment 30: YANG Data Model", IEEE Std 802.1Qcp-2018 (Revision of IEEE Std 802.1Q-2014), September 2018, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4286] B. Haberman and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005. [RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC5790] H. Liu, W. Cao, H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. Zhao & Liu, etc Expires February 14, 2021 [Page 37] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 [RFC6636] H. Asaeda, H. Liu, Q. Wu, "Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks", RFC 6636, May 2012. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, July 2013. [RFC7761] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, Z. Zhang, L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 7761, March 2016. [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, December 2017. [RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC 8340, March 2018. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", RFC 8341, March 2018. [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management Datastore Architecture (NMDA)", RFC 8342, March 2018. [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", RFC 8343, March 2018. [RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, March 2018. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [RFC8529] L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu, "YANG Data Model for Network Instances", RFC 8529, March 2019. [draft-ietf-bess-l2vpn-yang] Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model for MPLS-basedL2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress), July 2019. Zhao & Liu, etc Expires February 14, 2021 [Page 38] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 7.2. Informative References [RFC3916] X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC 7951, August 2016. [RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", RFC 8407, October 2018. [RFC8652] X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter, "A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, November 2019. Zhao & Liu, etc Expires February 14, 2021 [Page 39] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 Appendix A. Data Tree Example A.1 Bridge service This section contains an example for bridge service in the JSON encoding [RFC7951], containing both configuration and state data. +-----------+ + Source + +-----+-----+ | -----------------+---------------------------- |eth1/1 +---+---+ + R1 + +-+---+-+ eth1/2 | \ eth1/3 | \ | \ | \ | \ eth2/1 | \ eth3/1 +---+---+ +--+---+ + R2 + + R3 + +---+---+ +--+---+ eth2/2 | | eth3/2 | | ---------------+----------+------------------- | | | | +--------+--+ +---+--------+ + Receiver1 + + Receiver2 + +-----------+ +------------+ The configuration data for R1 in the above figure could be as follows: { "ietf-interfaces:interfaces":{ "interface":[ { "name":"eth1/1", "type":"iana-if-type:ethernetCsmacd" } ] }, "ietf-routing:routing":{ "control-plane-protocols":{ "control-plane-protocol":[ { "type":"ietf-igmp-mld-snooping:igmp-snooping", "name":"bis1", "ietf-igmp-mld-snooping:igmp-snooping-instance":{ Zhao & Liu, etc Expires February 14, 2021 [Page 40] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 "l2-service-type":"ietf-igmp-mld-snooping:bridge", "enable":true } } ] } }, "ieee802-dot1q-bridge:bridges":{ "bridge":[ { "name":"isp1", "address":"00-23-ef-a5-77-12", "bridge-type":"ieee802-dot1q-bridge:customer-vlan-bridge", "component":[ { "name":"comp1", "type":"ieee802-dot1q-bridge:c-vlan-component", "bridge-vlan":{ "vlan":[ { "vid":101, "ietf-igmp-mld-snooping:igmp-snooping-instance":"bis1" } ] } } ] } ] } } The corresponding operational state data for R1 could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "eth1/1", "type": "iana-if-type:ethernetCsmacd", "oper-status": "up", "statistics": { "discontinuity-time": "2018-05-23T12:34:56-05:00" } } ] }, "ietf-routing:routing": { "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-igmp-mld-snooping:igmp-snooping", Zhao & Liu, etc Expires February 14, 2021 [Page 41] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 "name": "bis1", "ietf-igmp-mld-snooping:igmp-snooping-instance": { "l2-service-type": "ietf-igmp-mld-snooping:bridge", "enable": true } } ] } }, "ieee802-dot1q-bridge:bridges": { "bridge": [ { "name": "isp1", "address": "00-23-ef-a5-77-12", "bridge-type": "ieee802-dot1q-bridge:customer-vlan-bridge", "component": [ { "name": "comp1", "type": "ieee802-dot1q-bridge:c-vlan-component", "bridge-vlan": { "vlan": [ { "vid": 101, "ietf-igmp-mld-snooping:igmp-snooping-instance": "bis1" } ] } } ] } ] } } The following action is to clear all the entries whose group address is 225.1.1.1 for igmp-snooping-instance bis1. POST /restconf/operations/ietf-routing:routing/control-plane-protocols/\ control-plane-protocol=ietf-igmp-mld-snooping:igmp-snooping,bis1/\ ietf-igmp-mld-snooping:igmp-snooping-instance/\ clear-igmp-snooping-groups HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "ietf-igmp-mld-snooping:input" : { "group": "225.1.1.1", "source": "*" } } Zhao & Liu, etc Expires February 14, 2021 [Page 42] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 A.2 L2VPN service This section contains an example for L2VPN service in the JSON encoding [RFC7951], containing both configuration and state data. +-----------+ + Source + +-----+-----+ | -----------------+---------------------------- |eth1/1 +---+---+ + R1 + +-+---+-+ eth1/2 | \ eth1/3 | \ | \ | \ | \ eth2/1 | \ eth3/1 +---+---+ +-+---+ + R2 +----+ R3 + +---+---+ +-+---+ eth2/2 | | eth3/2 | | ---------------+----------+------------------- | | | | +--------+--+ +---+--------+ + Receiver1 + + Receiver2 + +-----------+ +------------+ The configuration data for R1 in the above figure could be as follows: { "ietf-interfaces:interfaces":{ "interface":[ { "name":"eth1/1", "type":"iana-if-type:ethernetCsmacd" } ] }, "ietf-pseudowires:pseudowires": { "pseudowire": [ { "name": "pw2" }, { "name": "pw3" Zhao & Liu, etc Expires February 14, 2021 [Page 43] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 } ] }, "ietf-network-instance:network-instances": { "network-instance": [ { "name": "vpls1", "ietf-igmp-mld-snooping:igmp-snooping-instance": "vis1", "ietf-l2vpn:type": "ietf-l2vpn:vpls-instance-type", "ietf-l2vpn:signaling-type": "ietf-l2vpn:ldp-signaling", "ietf-l2vpn:endpoint": [ { "name": "acs", "ac": [ { "name": "eth1/1" } ] }, { "name": "pws", "pw": [ { "name": "pw2" }, { "name": "pw3" } ] } ] } ] }, "ietf-routing:routing": { "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-igmp-mld-snooping:igmp-snooping", "name": "vis1", "ietf-igmp-mld-snooping:igmp-snooping-instance": { "l2-service-type": "ietf-igmp-mld-snooping:l2vpn", "enable": true } } ] } } } Zhao & Liu, etc Expires February 14, 2021 [Page 44] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 The corresponding operational state data for R1 could be as follows: { "ietf-interfaces:interfaces":{ "interface":[ { "name":"eth1/1", "type":"iana-if-type:ethernetCsmacd", "oper-status": "up", "statistics": { "discontinuity-time": "2018-05-23T12:34:56-05:00" } } ] }, "ietf-pseudowires:pseudowires": { "pseudowire": [ { "name": "pw2" }, { "name": "pw3" } ] }, "ietf-network-instance:network-instances": { "network-instance": [ { "name": "vpls1", "ietf-igmp-mld-snooping:igmp-snooping-instance": "vis1", "ietf-l2vpn:type": "ietf-l2vpn:vpls-instance-type", "ietf-l2vpn:signaling-type": "ietf-l2vpn:ldp-signaling", "ietf-l2vpn:endpoint": [ { "name": "acs", "ac": [ { "name": "eth1/1" } ] }, { "name": "pws", "pw": [ { "name": "pw2" }, { "name": "pw3" } ] } Zhao & Liu, etc Expires February 14, 2021 [Page 45] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 ] } ] }, "ietf-routing:routing": { "control-plane-protocols": { "control-plane-protocol": [ { "type": "ietf-igmp-mld-snooping:igmp-snooping", "name": "vis1", "ietf-igmp-mld-snooping:igmp-snooping-instance": { "l2-service-type": "ietf-igmp-mld-snooping:l2vpn", "enable": true } } ] } } } Zhao & Liu, etc Expires February 14, 2021 [Page 46] Internet-Draft IGMP & MLD Snooping Yang Module August 15, 2020 Authors' Addresses Hongji Zhao Ericsson (China) Communications Company Ltd. Ericsson Tower, No. 5 Lize East Street, Chaoyang District Beijing 100102, P.R. China Email: hongji.zhao@ericsson.com Xufeng Liu Volta Networks USA EMail: xufeng.liu.ietf@gmail.com Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Anish Peter Individual EMail: anish.ietf@gmail.com Mahesh Sivakumar Juniper Networks 1133 Innovation Way Sunnyvale, California USA EMail: sivakumar.mahesh@gmail.com Zhao & Liu, etc Expires February 14, 2021 [Page 47] ./draft-ietf-pim-yang-17.txt0000644000764400076440000060776413300110563015115 0ustar iustyiusty PIM Working Group X. Liu Internet-Draft Volta Networks Intended status: Standards Track P. McAllister Expires: November 20, 2018 Metaswitch Networks A. Peter Individual M. Sivakumar Juniper Networks Y. Liu Huawei Technologies F. Hu ZTE Corporation May 19, 2018 A YANG Data Model for Protocol Independent Multicast (PIM) draft-ietf-pim-yang-17 Abstract This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). The model covers the PIM protocol configuration, operational state, and event notifications data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 20, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires November 20, 2018 [Page 1] Internet-Draft PIM YANG May 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 6 2.2. Optional Capabilities . . . . . . . . . . . . . . . . . . 6 2.3. Datastore Applicability . . . . . . . . . . . . . . . . . 7 2.4. Module and Hierarchy Organization . . . . . . . . . . . . 7 2.5. Position of Address Family in Hierarchy . . . . . . . . . 7 3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 8 3.1. PIM Base Module . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. High-Level Structure . . . . . . . . . . . . . . . . 8 3.1.2. Global Data . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Per Address Family Data . . . . . . . . . . . . . . . 9 3.1.4. PIM Interface Modeling . . . . . . . . . . . . . . . 11 3.1.5. Neighbor Modeling . . . . . . . . . . . . . . . . . . 12 3.1.6. Notifications . . . . . . . . . . . . . . . . . . . . 12 3.2. PIM RP Module . . . . . . . . . . . . . . . . . . . . . . 13 3.2.1. Static RP . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. BSR . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.3. RP State Data . . . . . . . . . . . . . . . . . . . . 15 3.2.4. RP to Group Mappings . . . . . . . . . . . . . . . . 16 3.2.5. Notifications . . . . . . . . . . . . . . . . . . . . 16 3.3. PIM-SM Module . . . . . . . . . . . . . . . . . . . . . . 17 3.4. PIM-DM Module . . . . . . . . . . . . . . . . . . . . . . 18 3.5. PIM-BIDIR Module . . . . . . . . . . . . . . . . . . . . 18 4. Complete Tree Structure . . . . . . . . . . . . . . . . . . . 20 4.1. PIM Base Module . . . . . . . . . . . . . . . . . . . . . 20 4.2. PIM RP Module . . . . . . . . . . . . . . . . . . . . . . 25 4.3. PIM-SM Module . . . . . . . . . . . . . . . . . . . . . . 26 4.4. PIM-DM Module . . . . . . . . . . . . . . . . . . . . . . 27 4.5. PIM-BIDIR Module . . . . . . . . . . . . . . . . . . . . 28 5. Relationship to the PIM-STD-MIB . . . . . . . . . . . . . . . 29 5.1. pimInterfaceTable . . . . . . . . . . . . . . . . . . . . 29 5.2. pimNeighborTable . . . . . . . . . . . . . . . . . . . . 30 Liu, et al. Expires November 20, 2018 [Page 2] Internet-Draft PIM YANG May 2018 5.3. pimStarGTable . . . . . . . . . . . . . . . . . . . . . . 31 5.4. pimSGTable . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. pimSGRptTable . . . . . . . . . . . . . . . . . . . . . . 32 5.6. pimBidirDFElectionTable . . . . . . . . . . . . . . . . . 33 5.7. pimStaticRPTable . . . . . . . . . . . . . . . . . . . . 33 5.8. pimAnycastRPSetTable . . . . . . . . . . . . . . . . . . 34 5.9. pimGroupMappingTable . . . . . . . . . . . . . . . . . . 34 6. PIM YANG Modules . . . . . . . . . . . . . . . . . . . . . . 35 6.1. PIM base module . . . . . . . . . . . . . . . . . . . . . 35 6.2. PIM RP Module . . . . . . . . . . . . . . . . . . . . . . 58 6.3. PIM-SM Module . . . . . . . . . . . . . . . . . . . . . . 73 6.4. PIM-DM Module . . . . . . . . . . . . . . . . . . . . . . 79 6.5. PIM-BIDIR Module . . . . . . . . . . . . . . . . . . . . 81 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 93 11.2. Informative References . . . . . . . . . . . . . . . . . 96 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 1. Introduction YANG [RFC7950] is a data modeling language that was introduced to model the configuration and operational state of a device managed using network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. YANG is now also being used as a component of other management interfaces, such as CLIs. This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). This model supports the core PIM protocol, as well as many other features described in Section 2.1. Non-core features are defined as optional in the provided data model. 1.1. Terminology The terminology for describing YANG data models is found in [RFC7950]. The following abbreviations are used in this document and the defined model: ASM: Any-Source Multicast service model [RFC3569] [RFC4607]. Liu, et al. Expires November 20, 2018 [Page 3] Internet-Draft PIM YANG May 2018 BFD: Bidirectional Forwarding Detection [RFC5880]. BSR: Bootstrap Router [RFC5059]. DF: Designated Forwarder [RFC5015]. DR: Designated Router [RFC7761]. IGMP: Internet Group Management Protocol [RFC3376]. MLD: Multicast Listener Discovery [RFC3810]. MSDP: Multicast Source Discovery Protocol [RFC3618]. mLDP: Multipoint extensions for LDP [RFC6388]. MRIB: Multicast Routing Information Base [RFC3973] [RFC5015] [RFC7761]. mVPN: Multicast VPN. PIM: Protocol Independent Multicast. [RFC3973] [RFC5015] [RFC7761]. PIM-BIDIR: Protocol Independent Multicast - Bidirectional Mode [RFC5015]. PIM-DM: Protocol Independent Multicast - Dense Mode [RFC3973]. PIM-SM: Protocol Independent Multicast - Sparse Mode [RFC7761]. RP: Rendezvous Point. [RFC7761]. RPA: Rendezvous Point Address. [RFC5015]. Liu, et al. Expires November 20, 2018 [Page 4] Internet-Draft PIM YANG May 2018 RPF: Reverse Path Forwarding. [RFC3973] [RFC5015] [RFC7761]. RPT: Rendezvous-Point Tree. [RFC7761]. SPT: Shortest Path Tree. [RFC7761]. SSM: Source-Specific Multicast service model [RFC3569] [RFC4607]. VRF: Virtual Routing and Forwarding. 1.2. Tree Diagrams Tree diagrams used in this document follow the notation defined in [RFC8340]. In addition, the following notation is used as a placeholder at the location of the name of a tree node, to represent a section of nodes: 1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model objects are often used without a prefix, as long as it is clear from the context in which YANG module each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1. +-----------+--------------------+---------------------+ | Prefix | YANG module | Reference | +-----------+--------------------+---------------------+ | yang | ietf-yang-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] | | if | ietf-interfaces | [RFC8343] | | rt | ietf-routing | [RFC8349] | | rt-types | ietf-routing-types | [RFC8294] | | bfd-types | ietf-bfd-types | [I-D.ietf-bfd-yang] | +-----------+--------------------+---------------------+ Table 1: Prefixes and Corresponding YANG Modules Liu, et al. Expires November 20, 2018 [Page 5] Internet-Draft PIM YANG May 2018 2. Design of Data Model 2.1. Scope of Model The model covers PIM Sparse Mode [RFC7761], including the Source- Specific subset [RFC3569] [RFC4607], Dense Mode [RFC3973], and Bi- directional PIM [RFC5015]. The PIM extensions represented in the model include BSR [RFC5059] and Anycast-RP [RFC4610]. The data model can be used to configure and manage these protocol features. The operational state data and statistics can be retrieved by this model. The protocol specific notifications are also defined in the model. This model does not cover other multicast protocols such as IGMP/MLD, MSDP, mVPN, or mLDP in-band signalling. It does not cover any configuration required to generate the MRIB. These will be specified in separate documents. 2.2. Optional Capabilities This model is designed to represent the capabilities of devices supporting PIM with various specifications, including some with basic subsets of the PIM protocol. The main design goals of this document are that any major now-existing implementation may be said to support the base model, and that the configuration of all implementations meeting the specification is easy to express through some combination of the features in the base model and simple vendor augmentations. There is also value in widely-supported features being standardized, to save work for individual vendors, and so that mapping between different vendors' configuration is not needlessly complicated. Therefore, these modules declare a number of features representing capabilities that not all deployed devices support. The extensive use of feature declarations should also substantially simplify the capability negotiation process for a vendor's PIM implementation. On the other hand, operational state parameters are not so widely designated as features, as there are many cases where the defaulting of an operational state parameter would not cause any harm to the system, and it is much more likely that an implementation without native support for a piece of operational state would be able to derive a suitable value for a state variable that is not natively supported. Liu, et al. Expires November 20, 2018 [Page 6] Internet-Draft PIM YANG May 2018 For the same reason, wide constant ranges (for example, timer maxima and minima) are used in the model. It is expected that vendors will augment the model with any specific extensions and restrictions needed to adapt it to their vendor-specific implementation. 2.3. Datastore Applicability This model conforms to the Network Management Datastore Architecture (NMDA) [RFC8342]. The operational state data is combined with the associated configuration data in the same hierarchy [I-D.ietf-netmod-rfc6087bis]. 2.4. Module and Hierarchy Organization This model defines several separate modules for modelling PIM configuration, defined below. Again, this separation makes it easier to express the specific capabilities of a PIM device. The module organization, along with the usage of the YANG extensible features such as identity, allows the model to be easily augmented for new capabilities. The hierarchy of PIM configuration is designed so that objects that are only relevant for one situation or feature are collected in a container for that feature. For example, the configuration for PIM- SM that is not relevant for an SSM-only implementation is collected in an ASM container. Where fields are not genuinely essential to protocol operation, they are marked as optional. Some fields are essential but have a default specified, so they need not be explicitly configured. This module structure also applies, where applicable, to the operational state and notifications of the model. 2.5. Position of Address Family in Hierarchy This document contains address-family as a node in the hierarchy multiple times: both under the interface list, and under the PIM instance. The reasoning for this is to make it easier for implementations in which configuration options are not supported for specific address families. For these implementations, the restriction that interface configuration must be address-family independent may either be expressed as a vendor augmentation of an address-family-independent Liu, et al. Expires November 20, 2018 [Page 7] Internet-Draft PIM YANG May 2018 parameter above the address-family level, or by a constraint on the base model objects of a form similar to: deviation "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { deviate add { must "(address-family = 'rt:ipv4' and dr-priority = " + "../address-family[address-family = 'rt:ipv6']/" + "dr-priority) or " + "(address-family = 'rt:ipv6' and dr-priority = " + "../address-family[address-family = 'rt:ipv4']/" + "dr-priority)" { error-message "Error: IPv6 DR priority must match IPv4 DR priority."; error-app-tag "dr-priority-mismatch"; } } } 3. Module Structure 3.1. PIM Base Module The PIM base module defines the base framework not specific to any PIM mode, and is imported by the other modules. The base module by itself does not provide sufficient data for any PIM mode to operate. Other mode specific and feature specific modules need to be implemented in addition to this module, depending on the feature set required by the implementation. This model augments the core routing data model "ietf-routing" specified in [RFC8349]. The PIM base model augments "/rt:routing/ rt:control-plane-protocols" as opposed to augmenting "/rt:routing/ rt:control-plane-protocols/rt:control-plane-protocol", as the latter would allow multiple protocol instances, while the PIM protocol is designed to be enabled or disabled as a single protocol instance on a network instance or a logical network element. 3.1.1. High-Level Structure The high-level structure of the model is shown below: Liu, et al. Expires November 20, 2018 [Page 8] Internet-Draft PIM YANG May 2018 module: ietf-pim-base augment /rt:routing/rt:control-plane-protocols: +--rw pim! +--rw +--ro +--rw address-family* [address-family] | +--rw address-family identityref | +--rw | +--ro +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw address-family* [address-family] +--rw address-family identityref +--rw +--ro +--ro neighbors +--ro ipv4-neighbor* [address] | +--ro address inet:ipv4-address | +--ro +--ro ipv6-neighbor* [address] +--ro address inet:ipv6-address +--ro The presence of the top-level container "pim" enables the PIM protocols. 3.1.2. Global Data The global configuration and operational state data covers the support for graceful restart in the PIM base model. Additional features can be added by augmentation if required by an implementation. 3.1.3. Per Address Family Data The support for per address family data is shown below: Liu, et al. Expires November 20, 2018 [Page 9] Internet-Draft PIM YANG May 2018 +--rw pim! +--rw address-family* [address-family] | +--rw address-family identityref | +--rw graceful-restart ... | +--ro statistics | | +--ro discontinuity-time? yang:date-and-time | | +--ro error | | | +--ro assert? yang:counter32 ... | | +--ro queue | | | +--ro size? uint32 | | | +--ro overflow? yang:counter32 | | +--ro received | | | +--ro assert? yang:counter32 ... | | +--ro sent | | +--ro assert? yang:counter32 ... | +--ro topology-tree-info | | +--ro ipv4-route* [group source-address is-rpt] | | | +--ro group | | | | rt-types:ipv4-multicast-group-address | | | +--ro source-address | | | | rt-types:ipv4-multicast-source-address | | | +--ro is-rpt boolean | | +--ro ipv6-route* [group source-address is-rpt] | | +--ro group | | | rt-types:ipv6-multicast-group-address | | +--ro source-address | | | rt-types:ipv6-multicast-source-address | | +--ro is-rpt boolean ... | | +--ro incoming-interface? if:interface-ref ... | | +--ro outgoing-interface* [name] | | +--ro name if:interface-ref | | +--ro expiration? rt-types:timer-value-seconds16 | | +--ro up-time? rt-types:timeticks64 | | +--ro jp-state? enumeration This is the location that most of the PIM RP module (ietf-pim-rp) augments. Each of the mode specific modules also augments this schema tree. Liu, et al. Expires November 20, 2018 [Page 10] Internet-Draft PIM YANG May 2018 3.1.4. PIM Interface Modeling The configuration and operational state data of PIM interfaces is modeled as below: +--rw pim! +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw address-family* [address-family] +--rw address-family identityref +--rw bfd {bfd}? ... +--rw dr-priority? uint32 {intf-dr-priority}? +--rw hello-interval? rt-types:timer-value-seconds16 | {intf-hello-interval}? +--rw (hello-holdtime-or-multiplier)? | +--:(holdtime) {intf-hello-holdtime}? | | +--rw hello-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-hello-multiplier}? | +--rw hello-multiplier? | rt-types:timer-multiplier +--rw jp-interval? rt-types:timer-value-seconds16 | {intf-jp-interval}? +--rw (jp-holdtime-or-multiplier)? | +--:(holdtime) {intf-jp-holdtime}? | | +--rw jp-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-jp-multiplier}? | +--rw jp-multiplier? | rt-types:timer-multiplier +--rw override-interval? uint16 | {intf-override-interval}? +--rw propagation-delay? uint16 | {intf-propagation-delay}? +--ro oper-status? enumeration +--ro gen-id? uint32 +--ro hello-expiration? rt-types:timer-value-seconds16 +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 | +--ro address* inet:ipv6-address | +--ro dr-address? inet:ipv6-address Liu, et al. Expires November 20, 2018 [Page 11] Internet-Draft PIM YANG May 2018 The support for bfd is achieved by using a grouping provided by an external module ietf-bfd-types, defined in [I-D.ietf-bfd-yang]. 3.1.5. Neighbor Modeling For each PIM interface, there can be a list of neighbors, which contain operational state data. To model such data, the following structure is specified: +--rw pim! +--rw interfaces +--rw interface* [name] +--rw address-family* [address-family] +--ro neighbors +--ro ipv4-neighbor* [address] | +--ro address inet:ipv4-address | +--ro bfd-status? enumeration | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro dr-priority? uint32 | +--ro gen-id? uint32 | +--ro lan-prune-delay | | +--ro present? boolean | | +--ro override-interval? uint16 | | +--ro propagation-delay? uint16 | | +--ro t-bit? boolean | +--ro up-time? rt-types:timeticks64 +--ro ipv6-neighbor* [address] +--ro address inet:ipv6-address +--ro bfd-status? enumeration +--ro expiration? | rt-types:timer-value-seconds16 +--ro dr-priority? uint32 +--ro gen-id? uint32 +--ro lan-prune-delay | +--ro present? boolean | +--ro override-interval? uint16 | +--ro propagation-delay? uint16 | +--ro t-bit? boolean +--ro up-time? rt-types:timeticks64 3.1.6. Notifications The PIM base module also defines the notifications for PIM interface and neighbor events, as shown below: Liu, et al. Expires November 20, 2018 [Page 12] Internet-Draft PIM YANG May 2018 notifications: +---n pim-neighbor-event | +--ro event-type? neighbor-event-type | +--ro interface-ref? leafref | +--ro interface-af-ref? leafref | +--ro neighbor-ipv4-ref? leafref | +--ro neighbor-ipv6-ref? leafref | +--ro up-time? rt-types:timeticks64 +---n pim-interface-event +--ro event-type? interface-event-type +--ro interface-ref? leafref +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 +--ro address* inet:ipv6-address +--ro dr-address? inet:ipv6-address 3.2. PIM RP Module The PIM RP module augments the PIM base module to define the configuration and operational state information scoped to RP related features: module: ietf-pim-rp augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw rp +--rw static-rp ... +--rw bsr {bsr}? ... +--ro rp-list ... +--ro rp-mappings ... This module is shared by the PIM-SM mode and the PIM-BIDIR mode, but not by the PIM-DM mode. PIM-SM module and PIM-BIDIR module augment this module to cover mode specific data. The following sections describe the features and capabilities covered in this module. Liu, et al. Expires November 20, 2018 [Page 13] Internet-Draft PIM YANG May 2018 3.2.1. Static RP Static RPs can be configured by using the following portion of the module: +--rw rp +--rw static-rp | +--rw ipv4-rp* [rp-address] | | +--rw rp-address inet:ipv4-address | +--rw ipv6-rp* [rp-address] | +--rw rp-address inet:ipv6-address 3.2.2. BSR The support for BSR includes both configuration data and operational state data, as shown below: Liu, et al. Expires November 20, 2018 [Page 14] Internet-Draft PIM YANG May 2018 +--rw rp +--rw bsr {bsr}? | +--rw bsr-candidate! | | +--rw (interface-or-address)? | | | +--:(interface) {candidate-interface}? | | | | +--rw interface if:interface-ref | | | +--:(ipv4-address) {candidate-ipv4}? | | | | +--rw ipv4-address inet:ipv4-address | | | +--:(ipv6-address) {candidate-ipv6}? | | | +--rw ipv6-address inet:ipv6-address | | +--rw hash-mask-length uint8 | | +--rw priority? uint8 | +--rw rp-candidate | | +--rw interface* [name] {candidate-interface}? | | | +--rw name if:interface-ref | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv4-address* [address] {candidate-ipv4}? | | | +--rw address inet:ipv4-address | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv6-address* [address] {candidate-ipv6}? | | +--rw address inet:ipv6-address | | +--rw policy-name? string | | +--rw mode? identityref | +--ro bsr | | +--ro address? inet:ip-address | | +--ro hash-mask-length? uint8 | | +--ro priority? uint8 | | +--ro up-time? rt-types:timeticks64 | +--ro (election-state)? {bsr-election-state}? | | +--:(candidate) | | | +--ro candidate-bsr-state? enumeration | | +--:(non-candidate) | | +--ro non-candidate-bsr-state? enumeration | +--ro bsr-next-bootstrap? uint16 | +--ro rp | | +--ro rp-address? inet:ip-address | | +--ro policy-name? string | | +--ro up-time? rt-types:timeticks64 | +--ro rp-candidate-next-advertisement? uint16 3.2.3. RP State Data This portion of the model provides the operational state information for all RPs on the router, including the statically configured RPs and the BSR elected RPs. Liu, et al. Expires November 20, 2018 [Page 15] Internet-Draft PIM YANG May 2018 +--rw rp +--ro rp-list | +--ro ipv4-rp* [rp-address mode] | | +--ro rp-address inet:ipv4-address | | +--ro mode identityref | | +--ro info-source-address? inet:ipv4-address | | +--ro info-source-type? identityref | | +--ro up-time? rt-types:timeticks64 | | +--ro expiration? rt-types:timer-value-seconds16 | +--ro ipv6-rp* [rp-address mode] | +--ro rp-address inet:ipv6-address | +--ro mode identityref | +--ro info-source-address? inet:ipv6-address | +--ro info-source-type? identityref | +--ro up-time? rt-types:timeticks64 | +--ro expiration? rt-types:timer-value-seconds16 3.2.4. RP to Group Mappings The operational state data of the mappings between RPs and multicast groups is modeled as follows: +--rw rp +--ro rp-mappings +--ro ipv4-rp* [group rp-address] | +--ro group inet:ipv4-prefix | +--ro rp-address inet:ipv4-address | +--ro up-time? rt-types:timeticks64 | +--ro expiration? rt-types:timer-value-seconds16 +--ro ipv6-rp* [group rp-address] +--ro group inet:ipv6-prefix +--ro rp-address inet:ipv6-address +--ro up-time? rt-types:timeticks64 +--ro expiration? rt-types:timer-value-seconds16 3.2.5. Notifications The PIM RP module also defines the notifications for RP related events, as shown below: Liu, et al. Expires November 20, 2018 [Page 16] Internet-Draft PIM YANG May 2018 notifications: +---n pim-rp-event +--ro event-type? rp-event-type +--ro instance-af-ref? leafref +--ro group? rt-types:ip-multicast-group-address +--ro rp-address? inet:ip-address +--ro is-rpt? boolean +--ro mode? pim-base:pim-mode +--ro message-origin? inet:ip-address 3.3. PIM-SM Module The PIM-SM module covers Sparse Mode modeling, including PIM-ASM and PIM-SSM. This module has dependencies on PIM base module and PIM RP module, both of which are augmented by this module. The augmentation to the address-family branch of the PIM base module is shown below: module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw sm +--rw asm | +--rw anycast-rp! | | +--rw ipv4-anycast-rp* [anycast-address rp-address] | | | +--rw anycast-address inet:ipv4-address | | | +--rw rp-address inet:ipv4-address | | +--rw ipv6-anycast-rp* [anycast-address rp-address] | | +--rw anycast-address inet:ipv6-address | | +--rw rp-address inet:ipv6-address | +--rw spt-switch | +--rw infinity! {spt-switch-infinity}? | +--rw policy-name? string {spt-switch-policy}? +--rw ssm! +--rw range-policy? string To support SM mode on an interface, this module augments the interface branch of the PIM base module, as follows: Liu, et al. Expires November 20, 2018 [Page 17] Internet-Draft PIM YANG May 2018 module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family: +--rw sm! +--rw passive? empty This module also augments the PIM RP module to allow an RP to be configured in the PIM-SM mode: module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv4-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv6-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? 3.4. PIM-DM Module The PIM-DM module covers Dense Mode modeling. This module augments the PIM base module, but it has no dependency on the PIM RP module. module: ietf-pim-dm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw dm! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw dm! 3.5. PIM-BIDIR Module The PIM-BIDIR module covers Bidirectional PIM modeling. Like PIM-SM, this module augments both PIM base module and PIM RP module. The followings are the augmentations to the PIM base module, on the address-family, the interface, and the neighbor branches: Liu, et al. Expires November 20, 2018 [Page 18] Internet-Draft PIM YANG May 2018 module: ietf-pim-bidir augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw bidir! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family: +--rw bidir! +--rw df-election {intf-df-election}? +--rw offer-interval? uint16 +--rw backoff-interval? uint16 +--rw offer-multiplier? uint8 augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family /pim-base:neighbors/pim-base:ipv4-neighbor: +--ro bidir-capable? boolean augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface/pim-base:address-family /pim-base:neighbors/pim-base:ipv6-neighbor: +--ro bidir-capable? boolean This module also augments the PIM RP module to extend the capabilities of RP for the PIM-BIDIR mode: Liu, et al. Expires November 20, 2018 [Page 19] Internet-Draft PIM YANG May 2018 module: ietf-pim-bidir augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv4-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp/pim-rp:ipv6-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp: +--ro bidir +--ro df-election | +--ro ipv4-rp* [rp-address] | | +--ro rp-address inet:ipv4-address | +--ro ipv6-rp* [rp-address] | +--ro rp-address inet:ipv6-address +--ro interface-df-election +--ro ipv4-rp* [rp-address interface-name] | +--ro rp-address inet:ipv4-address | +--ro interface-name if:interface-ref | +--ro df-address? inet:ipv4-address | +--ro interface-state? identityref | +--ro up-time? rt-types:timeticks64 | +--ro winner-metric? uint32 | +--ro winner-metric-preference? uint32 +--ro ipv6-rp* [rp-address interface-name] +--ro rp-address inet:ipv6-address +--ro interface-name if:interface-ref +--ro df-address? inet:ipv6-address +--ro interface-state? identityref +--ro up-time? rt-types:timeticks64 +--ro winner-metric? uint32 +--ro winner-metric-preference? uint32 4. Complete Tree Structure 4.1. PIM Base Module module: ietf-pim-base augment /rt:routing/rt:control-plane-protocols: +--rw pim! Liu, et al. Expires November 20, 2018 [Page 20] Internet-Draft PIM YANG May 2018 +--rw graceful-restart | +--rw enabled? boolean | +--rw duration? uint16 +--rw address-family* [address-family] | +--rw address-family identityref | +--rw graceful-restart | | +--rw enabled? boolean | | +--rw duration? uint16 | +--ro statistics | | +--ro discontinuity-time? yang:date-and-time | | +--ro error | | | +--ro assert? yang:counter64 | | | +--ro bsr? yang:counter64 | | | +--ro candidate-rp-advertisement? yang:counter64 | | | +--ro df-election? yang:counter64 | | | +--ro graft? yang:counter64 | | | +--ro graft-ack? yang:counter64 | | | +--ro hello? yang:counter64 | | | +--ro join-prune? yang:counter64 | | | +--ro register? yang:counter64 | | | +--ro register-stop? yang:counter64 | | | +--ro state-refresh? yang:counter64 | | | +--ro checksum? yang:counter64 | | | +--ro format? yang:counter64 | | +--ro queue | | | +--ro size? uint32 | | | +--ro overflow? yang:counter32 | | +--ro received | | | +--ro assert? yang:counter64 | | | +--ro bsr? yang:counter64 | | | +--ro candidate-rp-advertisement? yang:counter64 | | | +--ro df-election? yang:counter64 | | | +--ro graft? yang:counter64 | | | +--ro graft-ack? yang:counter64 | | | +--ro hello? yang:counter64 | | | +--ro join-prune? yang:counter64 | | | +--ro register? yang:counter64 | | | +--ro register-stop? yang:counter64 | | | +--ro state-refresh? yang:counter64 | | +--ro sent | | +--ro assert? yang:counter64 | | +--ro bsr? yang:counter64 | | +--ro candidate-rp-advertisement? yang:counter64 | | +--ro df-election? yang:counter64 | | +--ro graft? yang:counter64 | | +--ro graft-ack? yang:counter64 | | +--ro hello? yang:counter64 | | +--ro join-prune? yang:counter64 Liu, et al. Expires November 20, 2018 [Page 21] Internet-Draft PIM YANG May 2018 | | +--ro register? yang:counter64 | | +--ro register-stop? yang:counter64 | | +--ro state-refresh? yang:counter64 | +--ro topology-tree-info | +--ro ipv4-route* [group source-address is-rpt] | | +--ro group | | | rt-types:ipv4-multicast-group-address | | +--ro source-address | | | rt-types:ipv4-multicast-source-address | | +--ro is-rpt boolean | | +--ro expiration? | | | rt-types:timer-value-seconds16 | | +--ro incoming-interface? if:interface-ref | | +--ro is-spt? boolean | | +--ro mode? identityref | | +--ro msdp-learned? boolean | | +--ro rp-address? inet:ip-address | | +--ro rpf-neighbor? inet:ip-address | | +--ro up-time? rt-types:timeticks64 | | +--ro outgoing-interface* [name] | | +--ro name if:interface-ref | | +--ro expiration? rt-types:timer-value-seconds16 | | +--ro up-time? rt-types:timeticks64 | | +--ro jp-state? enumeration | +--ro ipv6-route* [group source-address is-rpt] | +--ro group | | rt-types:ipv6-multicast-group-address | +--ro source-address | | rt-types:ipv6-multicast-source-address | +--ro is-rpt boolean | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro incoming-interface? if:interface-ref | +--ro is-spt? boolean | +--ro mode? identityref | +--ro msdp-learned? boolean | +--ro rp-address? inet:ip-address | +--ro rpf-neighbor? inet:ip-address | +--ro up-time? rt-types:timeticks64 | +--ro outgoing-interface* [name] | +--ro name if:interface-ref | +--ro expiration? rt-types:timer-value-seconds16 | +--ro up-time? rt-types:timeticks64 | +--ro jp-state? enumeration +--rw interfaces +--rw interface* [name] +--rw name if:interface-ref +--rw address-family* [address-family] Liu, et al. Expires November 20, 2018 [Page 22] Internet-Draft PIM YANG May 2018 +--rw address-family identityref +--rw bfd {bfd}? | +--rw enable? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval uint32 | | +--rw required-min-rx-interval uint32 | +--:(single-interval) | +--rw min-interval uint32 +--rw dr-priority? uint32 | {intf-dr-priority}? +--rw hello-interval? | rt-types:timer-value-seconds16 | {intf-hello-interval}? +--rw (hello-holdtime-or-multiplier)? | +--:(holdtime) {intf-hello-holdtime}? | | +--rw hello-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-hello-multiplier}? | +--rw hello-multiplier? | rt-types:timer-multiplier +--rw jp-interval? | rt-types:timer-value-seconds16 | {intf-jp-interval}? +--rw (jp-holdtime-or-multiplier)? | +--:(holdtime) {intf-jp-holdtime}? | | +--rw jp-holdtime? | | rt-types:timer-value-seconds16 | +--:(multiplier) {intf-jp-multiplier}? | +--rw jp-multiplier? | rt-types:timer-multiplier +--rw override-interval? uint16 | {intf-override-interval}? +--rw propagation-delay? uint16 | {intf-propagation-delay}? +--ro oper-status? enumeration +--ro gen-id? uint32 +--ro hello-expiration? | rt-types:timer-value-seconds16 +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 | +--ro address* inet:ipv6-address | +--ro dr-address? inet:ipv6-address +--ro neighbors +--ro ipv4-neighbor* [address] Liu, et al. Expires November 20, 2018 [Page 23] Internet-Draft PIM YANG May 2018 | +--ro address inet:ipv4-address | +--ro bfd-state? bfd-types:state | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro dr-priority? uint32 | +--ro gen-id? uint32 | +--ro lan-prune-delay | | +--ro present? boolean | | +--ro override-interval? uint16 | | +--ro propagation-delay? uint16 | | +--ro t-bit? boolean | +--ro up-time? rt-types:timeticks64 +--ro ipv6-neighbor* [address] +--ro address inet:ipv6-address +--ro bfd-state? bfd-types:state +--ro expiration? | rt-types:timer-value-seconds16 +--ro dr-priority? uint32 +--ro gen-id? uint32 +--ro lan-prune-delay | +--ro present? boolean | +--ro override-interval? uint16 | +--ro propagation-delay? uint16 | +--ro t-bit? boolean +--ro up-time? rt-types:timeticks64 notifications: +---n pim-neighbor-event | +--ro event-type? neighbor-event-type | +--ro interface-ref? leafref | +--ro interface-af-ref? leafref | +--ro neighbor-ipv4-ref? leafref | +--ro neighbor-ipv6-ref? leafref | +--ro up-time? rt-types:timeticks64 +---n pim-interface-event +--ro event-type? interface-event-type +--ro interface-ref? leafref +--ro ipv4 | +--ro address* inet:ipv4-address | +--ro dr-address? inet:ipv4-address +--ro ipv6 +--ro address* inet:ipv6-address +--ro dr-address? inet:ipv6-address Liu, et al. Expires November 20, 2018 [Page 24] Internet-Draft PIM YANG May 2018 4.2. PIM RP Module module: ietf-pim-rp augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw rp +--rw static-rp | +--rw ipv4-rp* [rp-address] | | +--rw rp-address inet:ipv4-address | +--rw ipv6-rp* [rp-address] | +--rw rp-address inet:ipv6-address +--rw bsr {bsr}? | +--rw bsr-candidate! | | +--rw (interface-or-address)? | | | +--:(interface) {candidate-interface}? | | | | +--rw interface if:interface-ref | | | +--:(ipv4-address) {candidate-ipv4}? | | | | +--rw ipv4-address inet:ipv4-address | | | +--:(ipv6-address) {candidate-ipv6}? | | | +--rw ipv6-address inet:ipv6-address | | +--rw hash-mask-length uint8 | | +--rw priority? uint8 | +--rw rp-candidate | | +--rw interface* [name] {candidate-interface}? | | | +--rw name if:interface-ref | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv4-address* [address] {candidate-ipv4}? | | | +--rw address inet:ipv4-address | | | +--rw policy-name? string | | | +--rw mode? identityref | | +--rw ipv6-address* [address] {candidate-ipv6}? | | +--rw address inet:ipv6-address | | +--rw policy-name? string | | +--rw mode? identityref | +--ro bsr | | +--ro address? inet:ip-address | | +--ro hash-mask-length? uint8 | | +--ro priority? uint8 | | +--ro up-time? rt-types:timeticks64 | +--ro (election-state)? {bsr-election-state}? | | +--:(candidate) | | | +--ro candidate-bsr-state? enumeration | | +--:(non-candidate) | | +--ro non-candidate-bsr-state? enumeration | +--ro bsr-next-bootstrap? uint16 | +--ro rp Liu, et al. Expires November 20, 2018 [Page 25] Internet-Draft PIM YANG May 2018 | | +--ro rp-address? inet:ip-address | | +--ro policy-name? string | | +--ro up-time? rt-types:timeticks64 | +--ro rp-candidate-next-advertisement? uint16 +--ro rp-list | +--ro ipv4-rp* [rp-address mode] | | +--ro rp-address inet:ipv4-address | | +--ro mode identityref | | +--ro info-source-address? inet:ipv4-address | | +--ro info-source-type? identityref | | +--ro up-time? rt-types:timeticks64 | | +--ro expiration? | | rt-types:timer-value-seconds16 | +--ro ipv6-rp* [rp-address mode] | +--ro rp-address inet:ipv6-address | +--ro mode identityref | +--ro info-source-address? inet:ipv6-address | +--ro info-source-type? identityref | +--ro up-time? rt-types:timeticks64 | +--ro expiration? | rt-types:timer-value-seconds16 +--ro rp-mappings +--ro ipv4-rp* [group-range rp-address] | +--ro group-range inet:ipv4-prefix | +--ro rp-address inet:ipv4-address | +--ro up-time? rt-types:timeticks64 | +--ro expiration? rt-types:timer-value-seconds16 +--ro ipv6-rp* [group-range rp-address] +--ro group-range inet:ipv6-prefix +--ro rp-address inet:ipv6-address +--ro up-time? rt-types:timeticks64 +--ro expiration? rt-types:timer-value-seconds16 notifications: +---n pim-rp-event +--ro event-type? rp-event-type +--ro instance-af-ref? leafref +--ro group? rt-types:ip-multicast-group-address +--ro rp-address? inet:ip-address +--ro is-rpt? boolean +--ro mode? identityref +--ro message-origin? inet:ip-address 4.3. PIM-SM Module Liu, et al. Expires November 20, 2018 [Page 26] Internet-Draft PIM YANG May 2018 module: ietf-pim-sm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw sm +--rw asm | +--rw anycast-rp! | | +--rw ipv4-anycast-rp* [anycast-address rp-address] | | | +--rw anycast-address inet:ipv4-address | | | +--rw rp-address inet:ipv4-address | | +--rw ipv6-anycast-rp* [anycast-address rp-address] | | +--rw anycast-address inet:ipv6-address | | +--rw rp-address inet:ipv6-address | +--rw spt-switch | +--rw infinity! {spt-switch-infinity}? | +--rw policy-name? string {spt-switch-policy}? +--rw ssm! +--rw range-policy? string augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw sm! +--rw passive? empty augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv4-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv6-rp: +--rw sm! +--rw policy-name? string +--rw override? boolean {static-rp-override}? 4.4. PIM-DM Module module: ietf-pim-dm augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw dm! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw dm! Liu, et al. Expires November 20, 2018 [Page 27] Internet-Draft PIM YANG May 2018 4.5. PIM-BIDIR Module module: ietf-pim-bidir augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family: +--rw bidir! augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family: +--rw bidir! +--rw df-election {intf-df-election}? +--rw offer-interval? uint16 +--rw backoff-interval? uint16 +--rw offer-multiplier? uint8 augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv4-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp/pim-rp:static-rp /pim-rp:ipv6-rp: +--rw bidir! +--rw policy-name? string +--rw override? boolean {static-rp-override}? augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:address-family/pim-rp:rp: +--ro bidir +--ro df-election | +--ro ipv4-rp* [rp-address] | | +--ro rp-address inet:ipv4-address | +--ro ipv6-rp* [rp-address] | +--ro rp-address inet:ipv6-address +--ro interface-df-election +--ro ipv4-rp* [rp-address interface-name] | +--ro rp-address inet:ipv4-address | +--ro interface-name if:interface-ref | +--ro df-address? inet:ipv4-address | +--ro interface-state? identityref | +--ro up-time? rt-types:timeticks64 | +--ro winner-metric? uint32 | +--ro winner-metric-preference? uint32 +--ro ipv6-rp* [rp-address interface-name] +--ro rp-address inet:ipv6-address +--ro interface-name if:interface-ref +--ro df-address? inet:ipv6-address Liu, et al. Expires November 20, 2018 [Page 28] Internet-Draft PIM YANG May 2018 +--ro interface-state? identityref +--ro up-time? rt-types:timeticks64 +--ro winner-metric? uint32 +--ro winner-metric-preference? uint32 augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family/pim-base:neighbors /pim-base:ipv4-neighbor: +--ro bidir-capable? boolean augment /rt:routing/rt:control-plane-protocols/pim-base:pim /pim-base:interfaces/pim-base:interface /pim-base:address-family/pim-base:neighbors /pim-base:ipv6-neighbor: +--ro bidir-capable? boolean 5. Relationship to the PIM-STD-MIB The following sections describe the mappings between the objects in the PIM-STD-MIB defined in [RFC5060] and the YANG data nodes defined in this document. 5.1. pimInterfaceTable pimInterfaceTable is mapped to pim/interfaces/interface. The key of pimInterfaceTable is pimInterfaceIfIndex and pimInterfaceIPVersion, while the key of the "interface" list in YANG is the node "name". For each value of pimInterfaceIPVersion, the "interface" list contains a corresponding sublist whose key is the node "address- family". The following table lists the YANG data nodes with corresponding objects of pimInterfaceTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 29] Internet-Draft PIM YANG May 2018 +------------------------+----------------------------------+ | YANG node | PIM-STD-MIB object | +------------------------+----------------------------------+ | address-family | pimInterfaceAddressType | | ipv4/address | pimInterfaceAddress | | ipv6/address | | | gen-id | pimInterfaceGenerationIDValue | | ipv4/dr-address | pimInterfaceDR | | ipv6/dr-address | | | dr-priority | pimInterfaceDRPriority | | hello-interval | pimInterfaceHelloInterval | | hello-holdtime | pimInterfaceHelloHoldtime | | jp-interval | pimInterfaceJoinPruneInterval | | jp-holdtime | pimInterfaceJoinPruneHoldtime | | bidir/offer-multiplier | pimInterfaceDFElectionRobustness | | propagation-delay | pimInterfacePropagationDelay | | override-interval | pimInterfaceOverrideInterval | +------------------------+----------------------------------+ Table 2: YANG Nodes and pimInterfaceTable Objects 5.2. pimNeighborTable pimNeighborTable is mapped to pim/interfaces/interface/neighbors/ ipv4-neighbor and pim/interfaces/interface/neighbors/ipv6-neighbor. The following table lists the YANG data nodes with corresponding objects of pimNeighborTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 30] Internet-Draft PIM YANG May 2018 +------------------------------+---------------------------------+ | YANG node | PIM-STD-MIB object | +------------------------------+---------------------------------+ | ipv4-neighbor | pimNeighborAddressType | | ipv6-neighbor | | | address | pimNeighborAddress | | gen-id | pimNeighborGenerationIDValue | | up-time | pimNeighborUpTime | | expiration | pimNeighborExpiryTime | | dr-priority | pimNeighborDRPriority | | lan-prune-delay/present | pimNeighborLanPruneDelayPresent | | lan-prune-delay/t-bit | pimNeighborTBit | | lan-prune-delay/ | pimNeighborPropagationDelay | | propagation-delay | | | lan-prune-delay/ | pimNeighborOverrideInterval | | override-interval | | | ietf-pim-bidir:bidir-capable | pimNeighborBidirCapable | +------------------------------+---------------------------------+ Table 3: YANG Nodes and pimNeighborTable Objects 5.3. pimStarGTable pimStarGTable is mapped to pim/address-family/topology-tree-info/ ipv4-route and pim/address-family/topology-tree-info/ipv6-route, when the value of source-address leaf is "ietf-routing-types:*" and the value of is-rpt leaf is "false". The following table lists the YANG data nodes with corresponding objects of pimStarGTable in the PIM-STD-MIB. +--------------------+------------------------------+ | YANG node | PIM-STD-MIB object | +--------------------+------------------------------+ | ipv4-route | pimStarGAddressType | | ipv6-route | | | group | pimStarGGrpAddress | | up-time | pimStarGUpTime | | mode | pimStarGPimMode | | rp-address | pimStarGRPAddressType | | rp-address | pimStarGRPAddress | | rpf-neighbor | pimStarGUpstreamNeighborType | | rpf-neighbor | pimStarGUpstreamNeighbor | | incoming-interface | pimStarGRPFIfIndex | +--------------------+------------------------------+ Table 4: YANG Nodes and pimStarGTable Objects Liu, et al. Expires November 20, 2018 [Page 31] Internet-Draft PIM YANG May 2018 In addtion, the object pimStarGPimModeOrigin in pimStarGTable is mapped to the node rp/rp-list/ipv4-rp/info-source-type or the node rp/rp-list/ipv6-rp/info-source-type in the YANG module ietf-pim-rp. 5.4. pimSGTable pimSGTable is mapped to pim/address-family/topology-tree-info/ ipv4-route and pim/address-family/topology-tree-info/ipv6-route, when the value of source-address leaf is not "ietf-routing-types:*" and the value of is-rpt leaf is "false". The following table lists the YANG data nodes with corresponding objects of pimSGTable in the PIM-STD-MIB. +--------------------+--------------------------+ | YANG node | PIM-STD-MIB object | +--------------------+--------------------------+ | ipv4-route | pimSGAddressType | | ipv6-route | | | group | pimSGGrpAddress | | source-address | pimSGSrcAddress | | up-time | pimSGUpTime | | mode | pimSGPimMode | | rpf-neighbor | pimStarGUpstreamNeighbor | | incoming-interface | pimStarGRPFIfIndex | | is-spt | pimSGSPTBit | | expiration | pimSGKeepaliveTimer | +--------------------+--------------------------+ Table 5: YANG Nodes and pimSGTable Objects 5.5. pimSGRptTable pimSGRptTable is mapped to pim/address-family/topology-tree-info/ ipv4-route and pim/address-family/topology-tree-info/ipv6-route, when the value of is-rpt leaf is "true". The following table lists the YANG data nodes with corresponding objects of pimSGRptTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 32] Internet-Draft PIM YANG May 2018 +----------------+---------------------+ | YANG node | PIM-STD-MIB object | +----------------+---------------------+ | ipv4-route | pimStarGAddressType | | ipv6-route | | | group | pimStarGGrpAddress | | source-address | pimSGRptSrcAddress | | up-time | pimSGRptUpTime | +----------------+---------------------+ Table 6: YANG Nodes and pimSGRptTable Objects 5.6. pimBidirDFElectionTable pimBidirDFElectionTable is mapped to pim/address-family/rp/bidir/ interface-df-election/ipv4-rp and pim/address-family/rp/bidir/ interface-df-election/ipv6-rp. The key of pimBidirDFElectionTable includes pimBidirDFElectionIfIndex whose type is InterfaceIndex, while the YANG lists use a node "name" with the type string instead. The following table lists the YANG data nodes with corresponding objects of pimBidirDFElectionTable in the PIM-STD-MIB. +--------------------------+-------------------------------------+ | YANG node | PIM-STD-MIB object | +--------------------------+-------------------------------------+ | ipv4-rp | pimBidirDFElectionAddressType | | ipv6-rp | | | rp-address | pimBidirDFElectionRPAddress | | df-address | pimBidirDFElectionWinnerAddressType | | | pimBidirDFElectionWinnerAddress | | up-time | pimBidirDFElectionWinnerUpTime | | winner-metric-preference | pimBidirDFElectionWinnerMetricPref | | winner-metric-preference | pimBidirDFElectionWinnerMetric | | interface-state | pimBidirDFElectionState | +--------------------------+-------------------------------------+ Table 7: YANG Nodes and pimBidirDFElectionTable Objects 5.7. pimStaticRPTable pimStaticRPTable is mapped to pim/address-family/rp/static-rp/ipv4-rp and pim/address-family/rp/static-rp/ipv6-rp. The following table lists the YANG data nodes with corresponding objects of pimStaticRPTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 33] Internet-Draft PIM YANG May 2018 +----------------+----------------------------+ | YANG node | PIM-STD-MIB object | +----------------+----------------------------+ | ipv4-rp | pimStaticRPAddressType | | ipv6-rp | | | rp-address | pimStaticRPRPAddress | | bidir | pimStaticRPPimMode | | sm | | | bidir/override | pimStaticRPOverrideDynamic | | sm/override | | +----------------+----------------------------+ Table 8: YANG Nodes and pimStaticRPTable Objects 5.8. pimAnycastRPSetTable pimAnycastRPSetTable is mapped to pim/address-family/sm/asm/anycast- rp/ipv4-anycast-rp and pim/address-family/sm/asm/anycast-rp/ipv6- anycast-rp. The following table lists the YANG data nodes with corresponding objects of pimAnycastRPSetTable in the PIM-STD-MIB. +-----------------+-------------------------------+ | YANG node | PIM-STD-MIB object | +-----------------+-------------------------------+ | ipv4-anycast-rp | pimAnycastRPSetAddressType | | ipv6-anycast-rp | | | anycast-address | pimAnycastRPSetAnycastAddress | | rp-address | pimAnycastRPSetRouterAddress | +-----------------+-------------------------------+ Table 9: YANG Nodes and pimAnycastRPSetTable Objects 5.9. pimGroupMappingTable pimGroupMappingTable is mapped to pim/address-family/rp/rp-mappings/ ipv4-rp and pim/address-family/rp/rp-mappings/ipv6-rp. The following table lists the YANG data nodes with corresponding objects of pimGroupMappingTable in the PIM-STD-MIB. Liu, et al. Expires November 20, 2018 [Page 34] Internet-Draft PIM YANG May 2018 +------------+--------------------------------+ | YANG node | PIM-STD-MIB object | +------------+--------------------------------+ | ipv4-rp | pimGroupMappingAddressType | | ipv6-rp | | | group | pimGroupMappingGrpAddress | | | pimGroupMappingGrpPrefixLength | | ipv4-rp | pimGroupMappingRPAddressType | | ipv6-rp | | | rp-address | pimGroupMappingRPAddress | | | pimGroupMappingPimMode | +------------+--------------------------------+ Table 10: YANG Nodes and pimGroupMappingTable Objects In addtion, the object pimGroupMappingPimMode in pimGroupMappingTable is mapped to the node rp/rp-list/ipv4-rp/mode or the node rp/rp-list/ipv6-rp/mode in the YANG module ietf-pim-rp. 6. PIM YANG Modules 6.1. PIM base module This module references [RFC3973], [RFC5015], [RFC5306], [RFC5880], and [RFC7761]. file "ietf-pim-base@2018-04-16.yang" module ietf-pim-base { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-base"; prefix pim-base; import ietf-inet-types { prefix "inet"; } import ietf-yang-types { prefix "yang"; } import ietf-routing-types { prefix "rt-types"; } import ietf-interfaces { prefix "if"; } Liu, et al. Expires November 20, 2018 [Page 35] Internet-Draft PIM YANG May 2018 import ietf-routing { prefix "rt"; } import ietf-bfd-types { prefix "bfd-types"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The module defines a collection of YANG definitions common for all PIM (Protocol Independent Multicast) modes. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the Liu, et al. Expires November 20, 2018 [Page 36] Internet-Draft PIM YANG May 2018 RFC itself for full legal notices."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature bfd { description "Support BFD (Bidirectional Forwarding Detection)."; reference "RFC5880: Bidirectional Forwarding Detection (BFD)"; } feature global-graceful-restart { description "Global configuration for graceful restart support as per RFC5306."; } feature intf-dr-priority { description "Support configuration of interface DR (Designated Router) priority."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.3.2."; } feature intf-hello-holdtime { description "Support configuration of interface hello holdtime."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.3.3. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-hello-interval { description "Support configuration of interface hello interval."; reference Liu, et al. Expires November 20, 2018 [Page 37] Internet-Draft PIM YANG May 2018 "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-hello-multiplier { description "Support configuration of interface hello multiplier."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-jp-interval { description "Support configuration of interface join prune interval."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-jp-holdtime { description "Support configuration of interface join prune holdtime."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-jp-multiplier { description "Support configuration of interface join prune multiplier."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature intf-propagation-delay { description Liu, et al. Expires November 20, 2018 [Page 38] Internet-Draft PIM YANG May 2018 "Support configuration of interface propagation delay."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.3.5. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.3.3."; } feature intf-override-interval { description "Support configuration of interface override interval."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.3.3. RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM). Sec. 3.6. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } feature per-af-graceful-restart { description "Per address family configuration for graceful restart support as per RFC5306."; } /* * Typedefs */ typedef interface-event-type { type enumeration { enum up { description "Neighbor status changed to up."; } enum down { description "Neighbor status changed to down."; } enum new-dr { description "A new DR (Designated Router) was elected on the connected network."; } enum new-df { description "A new DF (Designated Forwarder) was elected on the connected network."; Liu, et al. Expires November 20, 2018 [Page 39] Internet-Draft PIM YANG May 2018 } } description "Operational status event type for notifications."; } typedef neighbor-event-type { type enumeration { enum up { description "Neighbor status changed to up."; } enum down { description "Neighbor status changed to down."; } } description "Operational status event type for notifications."; } /* * Identities */ identity pim-mode { description "The PIM mode in which a group is operating."; } identity pim-none { base pim-mode; description "PIM is not operating."; } identity pim-bidir { base pim-mode; description "PIM operates in the Bidirectional Mode."; } identity pim-dm { base pim-mode; description "PIM operates in the Dense Mode (DM)."; } identity pim-sm { base pim-mode; description "PIM operates in the Sparse Mode (SM)."; } identity pim-asm { base pim-sm; Liu, et al. Expires November 20, 2018 [Page 40] Internet-Draft PIM YANG May 2018 description "PIM operates in the Sparse Mode with Any Source Multicast (ASM)."; } identity pim-ssm { base pim-sm; description "PIM operates in the Sparse Mode with Source-Specific Multicast (SSM)."; } /* * Groupings */ grouping graceful-restart-container { description "A grouping defining a container of graceful restart attributes."; container graceful-restart { leaf enabled { type boolean; default false; description "Enable or disable graceful restart."; } leaf duration { type uint16; units seconds; default 60; description "Maximum time for graceful restart to finish."; } description "Container of graceful restart attributes."; } } // graceful-restart-container grouping multicast-route-attributes { description "A grouping defining multicast route attributes."; leaf expiration { type rt-types:timer-value-seconds16; description "When the route will expire."; } leaf incoming-interface { type if:interface-ref; description Liu, et al. Expires November 20, 2018 [Page 41] Internet-Draft PIM YANG May 2018 "Reference to an entry in the global interface list."; } leaf is-spt { type boolean; description "'true' if SPT (Shortest Path Tree) bit is set to indicate forwarding is taking place on the (S,G) Shortest Path Tree (SPT)."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.1.3."; } leaf mode { type identityref { base pim-mode; } description "PIM mode."; } leaf msdp-learned { type boolean; description "'true' if route is learned from MSDP (Multicast Source Discovery Protocol)."; } leaf rp-address { type inet:ip-address; description "RP (Rendezvous Point) address."; } leaf rpf-neighbor { type inet:ip-address; description "RPF (Reverse Path Forwarding) neighbor address."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the route last transitioned into the active state."; } list outgoing-interface { key "name"; description "A list of outgoing interfaces."; leaf name { type if:interface-ref; description "Interface name."; Liu, et al. Expires November 20, 2018 [Page 42] Internet-Draft PIM YANG May 2018 } leaf expiration { type rt-types:timer-value-seconds16; description "Expiring time."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the oper-status of the interface was last changed to 'up'."; } leaf jp-state { type enumeration { enum "no-info" { description "The interface has no (*,G) Join state and no timers running."; } enum "join" { description "The interface has Join state."; } enum "prune-pending" { description "The router has received a Prune on this interface from a downstream neighbor and is waiting to see whether the prune will be overridden by another downstream router. For forwarding purposes, the Prune-Pending state functions exactly like the Join state."; } } description "Join-prune state."; } } } // multicast-route-attributes grouping neighbor-state-af-attributes { description "A grouping defining neighbor per address family attributes."; leaf bfd-state { type bfd-types:state; description "BFD (Bidirectional Forwarding Detection) status."; } leaf expiration { Liu, et al. Expires November 20, 2018 [Page 43] Internet-Draft PIM YANG May 2018 type rt-types:timer-value-seconds16; description "Neighbor expiring time."; } leaf dr-priority { type uint32; description "DR (Designated Router) priority as the preference in the DR election process."; } leaf gen-id { type uint32; description "The value of the Generation ID in the last Hello message from the neighbor."; } container lan-prune-delay { description "The information of the LAN Prune Delay option in the Hello message from the neighbor."; leaf present { type boolean; description "'true' if the LAN Prune Delay option is present in the last Hello message from the neighbor."; } leaf override-interval { when "../present = 'true'" { description "Available only when the leaf present is 'true'."; } type uint16; units milliseconds; description "The value of the Override_Interval field of the LAN Prune Delay option in the last Hello message from the neighbor. The neighbor uses this value to indicate a short period after a Join or Prune to allow other routers on the LAN to override the Join or Prune."; } leaf propagation-delay { when "../present = 'true'" { description "Available only when the leaf present is 'true'."; } type uint16; units milliseconds; description "The value of the Propagation_Delay field of the LAN Prune Liu, et al. Expires November 20, 2018 [Page 44] Internet-Draft PIM YANG May 2018 Delay option in the last Hello message from the neighbor. The value is the propagation delay over the local link expected by the neighbor."; } leaf t-bit { when "../present = 'true'" { description "Available only when the leaf present is 'true'."; } type boolean; description "'true' if the T bit is set in the LAN Prune Delay option in the last Hello message from the neighbor. This flag indicates the neighbor's capability to disable Join message suppression."; } } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the neighbor relationship has been formed as reachable without beeing timed out."; } } // neighbor-state-af-attributes grouping pim-instance-af-state-ref { description "An absolute reference to a PIM instance address family."; leaf instance-af-ref { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/" + "pim-base:address-family"; } description "Reference to a PIM instance address family."; } } // pim-instance-af-state-ref grouping pim-interface-state-ref { description "An absolute reference to a PIM interface state."; leaf interface-ref { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:name"; Liu, et al. Expires November 20, 2018 [Page 45] Internet-Draft PIM YANG May 2018 } description "Reference to a PIM interface."; } } // pim-interface-state-ref grouping statistics-sent-received { description "A grouping defining sent and received statistics on PIM messages."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.7.1. RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM). Sec. 3.7. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.9."; leaf assert { type yang:counter64; description "The number of Assert messages, with the message Type of 5 in RFC3973 and RFC7761."; } leaf bsr { type yang:counter64; description "The number of Bootstrap messages, with the message Type of 4 in RFC3973 and RFC7761."; } leaf candidate-rp-advertisement { type yang:counter64; description "The number of Candidate RP Advertisement messages, with the message Type of 8 in RFC3973 and RFC7761."; } leaf df-election { type yang:counter64; description "The number of DF (Designated Forwarder) Election messages, with the message Type of 10 in RFC5015."; } leaf graft { type yang:counter64; description "The number of Graft messages, with the message Type of 6 in RFC3973 and RFC7761."; } leaf graft-ack { Liu, et al. Expires November 20, 2018 [Page 46] Internet-Draft PIM YANG May 2018 type yang:counter64; description "The number of Graft-Ack messages, with the message Type of 7 in RFC3973 and RFC7761."; } leaf hello { type yang:counter64; description "The number of Hello messages, with the message Type of 0 in RFC3973 and RFC7761."; } leaf join-prune { type yang:counter64; description "The number of Join/Prune messages, with the message Type of 3 in RFC3973 and RFC7761."; } leaf register { type yang:counter64; description "The number of Register messages, with the message Type of 1 in RFC3973 and RFC7761."; } leaf register-stop { type yang:counter64; description "The number of Register Stop messages, with the message Type of 2 in RFC3973 and RFC7761."; } leaf state-refresh { type yang:counter64; description "The number of State Refresh messages, with the message Type of 9 in RFC3973."; } } // statistics-sent-received /* * Data nodes */ augment "/rt:routing/rt:control-plane-protocols" { description "PIM augmentation to the routing instance model."; container pim { presence "Enables the PIM protocol."; Liu, et al. Expires November 20, 2018 [Page 47] Internet-Draft PIM YANG May 2018 description "PIM configuration and operational data."; uses graceful-restart-container { if-feature global-graceful-restart; } list address-family { key "address-family"; description "Each list entry for one address family."; uses rt:address-family; uses graceful-restart-container { if-feature per-af-graceful-restart; } container statistics { config false; description "A container defining statistics attributes."; leaf discontinuity-time { type yang:date-and-time; description "The time on the most recent occasion at which any one or more of the statistic counters suffered a discontinuity. If no such discontinuities have occurred since the last re-initialization of the local management subsystem, then this node contains the time the local management subsystem re-initialized itself."; } container error { description "Containing error statistics."; uses statistics-sent-received { description "Statistic counters on the PIM messages per PIM message Type. Each leaf attribute counts the number of PIM messages that were of a particular Type (such as Hello) and contained errors preventing them from being processed by PIM. Such messages are also counted by the corresponding counter of the same Type (such as Hello) in the 'received' container."; } leaf checksum { type yang:counter64; description "The number of PIM messages that were passed to PIM Liu, et al. Expires November 20, 2018 [Page 48] Internet-Draft PIM YANG May 2018 and contained checksum errors."; } leaf format { type yang:counter64; description "The number of PIM messages that passed checksum validation but contained format errors, including the errors such as PIM Version, Type, and message length."; } } container queue { description "Containing queue statistics."; leaf size { type uint32; description "The size of the input queue."; } leaf overflow { type yang:counter32; description "The number of the input queue overflows."; } } container received { description "Containing statistics of received messages."; uses statistics-sent-received; } container sent { description "Containing statistics of sent messages."; uses statistics-sent-received; } } container topology-tree-info { config false; description "Containing topology tree information."; list ipv4-route { when "../../address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "group source-address is-rpt"; description "A list of IPv4 routes."; leaf group { type rt-types:ipv4-multicast-group-address; Liu, et al. Expires November 20, 2018 [Page 49] Internet-Draft PIM YANG May 2018 description "Group address."; } leaf source-address { type rt-types:ipv4-multicast-source-address; description "Source address."; } leaf is-rpt { type boolean; description "'true' if the tree is RPT (Rendezvous-Point Tree)."; } uses multicast-route-attributes; } // ipv4-route list ipv6-route { when "../../address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "group source-address is-rpt"; description "A list of IPv6 routes."; leaf group { type rt-types:ipv6-multicast-group-address; description "Group address."; } leaf source-address { type rt-types:ipv6-multicast-source-address; description "Source address."; } leaf is-rpt { type boolean; description "'true' if the tree is RPT (Rendezvous-Point Tree)."; } uses multicast-route-attributes; } // ipv6-route } // topology-tree-info } // address-family container interfaces { description "Containing a list of interfaces."; list interface { key "name"; description "List of pim interfaces."; Liu, et al. Expires November 20, 2018 [Page 50] Internet-Draft PIM YANG May 2018 leaf name { type if:interface-ref; description "Reference to an entry in the global interface list."; } list address-family { key "address-family"; description "Each list entry for one address family."; uses rt:address-family; container bfd { if-feature bfd; description "BFD (Bidirectional Forwarding Detection) operation."; uses bfd-types:client-cfg-parms; } leaf dr-priority { if-feature intf-dr-priority; type uint32; default 1; description "DR (Designated Router) priority as the preference in the DR election process."; } leaf hello-interval { if-feature intf-hello-interval; type rt-types:timer-value-seconds16; default 30; description "Periodic interval for Hello messages. If 'infinity' or 'not-set' is used, no periodic Hello messages are sent."; reference "RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised). Sec. 4.8. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.11."; } choice hello-holdtime-or-multiplier { description "Holdtime is timer value to time out the neighbor state when the timer expires. The holdtime value can be specified either by the Liu, et al. Expires November 20, 2018 [Page 51] Internet-Draft PIM YANG May 2018 given holdtime value or by the calculation of the hello-interval multiplied by the given value of the multiplier."; case holdtime { if-feature intf-hello-holdtime; leaf hello-holdtime { type rt-types:timer-value-seconds16; default 105; description "Hello holdtime is the amount of time to keep the neighbor reachable until a new Hello message is received."; } } case multiplier { if-feature intf-hello-multiplier; leaf hello-multiplier { type rt-types:timer-multiplier; default 3; description "Hello multiplier is the number by which the hello interval is multplied to obtain the Hello holdtime. The value of the Hello holdtime is calculated as: hello-holdtime = (multiplier + 0.5) * (hello-interval)"; } } } leaf jp-interval { if-feature intf-jp-interval; type rt-types:timer-value-seconds16; default 60; description "Periodic interval between Join/Prune messages. If 'infinity' or 'not-set' is used, no periodic Join/Prune messages are sent."; } choice jp-holdtime-or-multiplier { description "Join/Prune holdtime is the amount of time a receiver must keep the Join/Prune state alive. The holdtime value can be specified either by the given holdtime value or by the calculation of the jp-interval multiplied by the given value of the multiplier."; case holdtime { Liu, et al. Expires November 20, 2018 [Page 52] Internet-Draft PIM YANG May 2018 if-feature intf-jp-holdtime; leaf jp-holdtime { type rt-types:timer-value-seconds16; default 210; description "Join/Prune holdtime is the amount of time a receiver must keep the Join/Prune state alive."; } } case multiplier { if-feature intf-jp-multiplier; leaf jp-multiplier { type rt-types:timer-multiplier; default 3; description "Join prune multiplier is the number by which the join prune interval is multplied to obtain the Join/Prune holdtime. The value of the Join/Prune holdtime is calculated as: jp-holdtime = (multiplier + 0.5) * (jp-interval)"; } } } leaf override-interval { if-feature intf-override-interval; type uint16; units milliseconds; default 2500; description "A short period after a Join or Prune to allow other routers on the LAN to override the Join or Prune."; } leaf propagation-delay { if-feature intf-propagation-delay; type uint16; units milliseconds; default 500; description "Expected propagation delay over the local link."; } // Interface state attributes leaf oper-status { type enumeration { enum up { description Liu, et al. Expires November 20, 2018 [Page 53] Internet-Draft PIM YANG May 2018 "The interface is ready to pass PIM messages."; } enum down { description "The interface does not pass PIM messages."; } } config false; description "PIM operational status on the interface. This status is PIM specific and separate from the operational status of the underlying interface."; } leaf gen-id { type uint32; config false; description "The value of the Generation ID this router uses to insert in the PIM Hello message sent on this interface."; } leaf hello-expiration { type rt-types:timer-value-seconds16; config false; description "Hello interval expiration time."; } container ipv4 { when "../address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } config false; description "Interface state attributes for IPv4."; leaf-list address { type inet:ipv4-address; description "List of addresses on which PIM is operating."; } leaf dr-address { type inet:ipv4-address; description "DR (Designated Router) address."; } } container ipv6 { when "../address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } Liu, et al. Expires November 20, 2018 [Page 54] Internet-Draft PIM YANG May 2018 config false; description "Interface state attributes for IPv6."; leaf-list address { type inet:ipv6-address; description "List of addresses on which PIM is operating."; } leaf dr-address { type inet:ipv6-address; description "DR (Designated Router) address."; } } container neighbors { config false; description "Information learned from neighbors through this interface."; list ipv4-neighbor { when "../../address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "address"; description "Neighbor state information."; leaf address { type inet:ipv4-address; description "Neighbor address."; } uses neighbor-state-af-attributes; } // list ipv4-neighbor list ipv6-neighbor { when "../../address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "address"; description "Neighbor state information."; leaf address { type inet:ipv6-address; description "Neighbor address."; } uses neighbor-state-af-attributes; } // list ipv6-neighbor } // neighbors } // address-family } // interface } // interfaces } // pim Liu, et al. Expires November 20, 2018 [Page 55] Internet-Draft PIM YANG May 2018 } // augment /* * Notifications */ notification pim-neighbor-event { description "Notification event for neighbor."; leaf event-type { type neighbor-event-type; description "Event type."; } uses pim-interface-state-ref; leaf interface-af-ref { type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface" + "[pim-base:name = current()/../interface-ref]/" + "pim-base:address-family/pim-base:address-family"; } description "Reference to a PIM interface address family."; } leaf neighbor-ipv4-ref { when "../interface-af-ref = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface" + "[pim-base:name = current()/../interface-ref]/" + "pim-base:address-family" + "[pim-base:address-family = " + "current()/../interface-af-ref]/" + "pim-base:neighbors/pim-base:ipv4-neighbor/" + "pim-base:address"; } description "Reference to a PIM IPv4 neighbor."; } leaf neighbor-ipv6-ref { when "../interface-af-ref = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } type leafref { path "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface" + "[pim-base:name = current()/../interface-ref]/" + "pim-base:address-family" Liu, et al. Expires November 20, 2018 [Page 56] Internet-Draft PIM YANG May 2018 + "[pim-base:address-family = " + "current()/../interface-af-ref]/" + "pim-base:neighbors/pim-base:ipv6-neighbor/" + "pim-base:address"; } description "Reference to a PIM IPv6 neighbor."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the neighbor relationship has been formed as reachable without beeing timed out."; } } notification pim-interface-event { description "Notification event for interface."; leaf event-type { type interface-event-type; description "Event type."; } uses pim-interface-state-ref; container ipv4 { description "Containing IPv4 information."; leaf-list address { type inet:ipv4-address; description "List of addresses."; } leaf dr-address { type inet:ipv4-address; description "DR (Designated Router) address."; } } container ipv6 { description "Containing IPv6 information."; leaf-list address { type inet:ipv6-address; description "List of addresses."; } leaf dr-address { type inet:ipv6-address; description "DR (Designated Router) address."; } } } } Liu, et al. Expires November 20, 2018 [Page 57] Internet-Draft PIM YANG May 2018 6.2. PIM RP Module This module references [RFC5059] and [RFC7761]. file "ietf-pim-rp@2018-04-16.yang" module ietf-pim-rp { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-rp"; prefix pim-rp; import ietf-inet-types { prefix "inet"; } import ietf-routing-types { prefix "rt-types"; } import ietf-interfaces { prefix "if"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Editor: Mahesh Sivakumar Liu, et al. Expires November 20, 2018 [Page 58] Internet-Draft PIM YANG May 2018 Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) RP (Rendezvous Point) model. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature bsr { description "This feature indicates that the system supports BSR (Bootstrap Router)."; reference "RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)."; } feature bsr-election-state { if-feature bsr; description "This feature indicates that the system supports providing Liu, et al. Expires November 20, 2018 [Page 59] Internet-Draft PIM YANG May 2018 BSR election state."; reference "RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)."; } feature static-rp-override { description "This feature indicates that the system supports configuration of static RP (Rendezvous Point) override."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 3.7."; } feature candidate-interface { description "This feature indicates that the system supports using an interface to configure a BSR or RP candidate."; } feature candidate-ipv4 { description "This feature indicates that the system supports using an IPv4 address to configure a BSR or RP candidate."; } feature candidate-ipv6 { description "This feature indicates that the system supports using an IPv6 address to configure a BSR or RP candidate."; } /* * Typedefs */ typedef rp-event-type { type enumeration { enum invalid-jp { description "An invalid JP (Join/Prune) message has been received."; } enum invalid-register { description "An invalid register message has been received."; } enum mapping-created { Liu, et al. Expires November 20, 2018 [Page 60] Internet-Draft PIM YANG May 2018 description "A new mapping has been created."; } enum mapping-deleted { description "A mapping has been deleted."; } } description "Operational status event type for notifications."; } /* * Identities */ identity rp-mode { description "The mode of an RP, which can be SM (Sparse Mode) or BIDIR (bi-directional)."; } identity rp-info-source-type { description "The information source of an RP."; } identity static { base rp-info-source-type; description "The RP is statically configured."; } identity bootstrap { base rp-info-source-type; description "The RP is learned from bootstrap."; } /* * Groupings */ grouping rp-mapping-state-attributes { description "Grouping of RP mapping attributes."; leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the RP mapping or the RP became actively available."; } leaf expiration { Liu, et al. Expires November 20, 2018 [Page 61] Internet-Draft PIM YANG May 2018 type rt-types:timer-value-seconds16; description "Expiration time."; } } // rp-mapping-state-attributes grouping rp-state-attributes { description "Grouping of RP state attributes."; leaf info-source-type { type identityref { base rp-info-source-type; } description "The information source of an RP."; } // info-source-type leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the RP became actively available."; } leaf expiration { type rt-types:timer-value-seconds16; description "Expiration time."; } } // rp-state-attributes grouping static-rp-attributes { description "Grouping of static RP attributes, used in augmenting modules."; leaf policy-name { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to determine which multicast group addresses are mapped to this statically configured RP address. If a policy is not specified, the entire multicast address space is mapped. The definition of such a policy is outside the scope of this document."; } leaf override { if-feature static-rp-override; type boolean; default false; description "When there is a conflict between static RP and dynamic Liu, et al. Expires November 20, 2018 [Page 62] Internet-Draft PIM YANG May 2018 RP, setting this attribute to 'true' will ask the system to use static RP."; } } // static-rp-attributes grouping rp-candidate-attributes { description "Grouping of RP candidate attributes."; leaf policy-name { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. If a policy is not specified, the entire multicast address space is accepted. The definition of such a policy is outside the scope of this document."; } leaf mode { type identityref { base rp-mode; } description "The mode of an RP, which can be SM (Sparse Mode) or BIDIR (bi-directional), each of them is defined in a saparate YNAG module. If a system supports an RP mode, the corresponding YANG module is implemented. When the value of this leaf is not specified, the default value is the supported mode if only one mode is implemented, or the default value is SM (Sparce Mode) if both SM and BIDIR are implemented."; } } // rp-candidate-attributes /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM RP augmentation."; container rp { description "PIM RP configuration data."; container static-rp { Liu, et al. Expires November 20, 2018 [Page 63] Internet-Draft PIM YANG May 2018 description "Containing static RP attributes."; list ipv4-rp { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "Specifies a static RP address."; } } list ipv6-rp { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; description "Specifies a static RP address."; } } } // static-rp container bsr { if-feature bsr; description "Containing BSR (BootStrap Router) attributes."; container bsr-candidate { presence "Present to serve as a BSR candidate"; description "BSR candidate attributes."; choice interface-or-address { description "Use either interface or ip-address."; case interface { if-feature candidate-interface; Liu, et al. Expires November 20, 2018 [Page 64] Internet-Draft PIM YANG May 2018 leaf interface { type if:interface-ref; mandatory true; description "Interface to be used by BSR."; } } case ipv4-address { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } if-feature candidate-ipv4; leaf ipv4-address { type inet:ipv4-address; mandatory true; description "IP address to be used by BSR."; } } case ipv6-address { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } if-feature candidate-ipv6; leaf ipv6-address { type inet:ipv6-address; mandatory true; description "IP address to be used by BSR."; } } } leaf hash-mask-length{ type uint8 { range "0..128"; } mandatory true; description "Value contained in BSR messages used by all routers to hash (map) to an RP."; } leaf priority { type uint8 { range "0..255"; Liu, et al. Expires November 20, 2018 [Page 65] Internet-Draft PIM YANG May 2018 } default 64; description "BSR election priority among different candidate BSRs. A larger value has a higher priority over a smaller value."; } } // bsr-candidate container rp-candidate { description "Containing RP candidate attributes."; list interface { if-feature candidate-interface; key "name"; description "A list of RP candidates"; leaf name { type if:interface-ref; description "Interface that the RP candidate uses."; } uses rp-candidate-attributes; } list ipv4-address { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } if-feature candidate-ipv4; key "address"; description "A list of RP candidate addresses."; leaf address { type inet:ipv4-address; description "IPv4 address that the RP candidate uses."; } uses rp-candidate-attributes; } list ipv6-address { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } if-feature candidate-ipv6; Liu, et al. Expires November 20, 2018 [Page 66] Internet-Draft PIM YANG May 2018 key "address"; description "A list of RP candidate addresses."; leaf address { type inet:ipv6-address; description "IPv6 address that the RP candidate uses."; } uses rp-candidate-attributes; } } // BSR state attributes. container bsr { config false; description "BSR information."; leaf address { type inet:ip-address; description "BSR address"; } leaf hash-mask-length { type uint8 { range "0..128"; } description "Hash mask length."; } leaf priority { type uint8 { range "0..255"; } description "Priority."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the BSR became up."; } } choice election-state { if-feature bsr-election-state; config false; description "BSR election state."; case candidate { leaf candidate-bsr-state { type enumeration { enum "candidate" { Liu, et al. Expires November 20, 2018 [Page 67] Internet-Draft PIM YANG May 2018 description "The router is a candidate to be the BSR for the scope zone, but currently another router is the preferred BSR."; } enum "pending" { description "The router is a candidate to be the BSR for the scope zone. Currently, no other router is the preferred BSR, but this router is not yet the elected BSR. This is a temporary state that prevents rapid thrashing of the choice of BSR during BSR election."; } enum "elected" { description "The router is the elected BSR for the scope zone and it must perform all the BSR functions."; } } description "Candidate-BSR state."; reference "RFC5059, Section 3.1.1."; } } case "non-candidate" { leaf non-candidate-bsr-state { type enumeration { enum "no-info" { description "The router has no information about this scope zone."; } enum "accept-any" { description "The router does not know of an active BSR, and will accept the first Bootstrap message it sees as giving the new BSR's identity and the RP-Set."; } enum "accept" { description "The router knows the identity of the current BSR, and is using the RP-Set provided by that BSR. Only Bootstrap messages from that BSR or from a Candidate-BSR (C-BSR) with higher weight than the current BSR will be accepted."; Liu, et al. Expires November 20, 2018 [Page 68] Internet-Draft PIM YANG May 2018 } } description "Non-candidate-BSR state."; reference "RFC5059, Section 3.1.2."; } } } // election-state leaf bsr-next-bootstrap { type uint16; units seconds; config false; description "The remaining time interval in seconds until the next bootstrap will be sent."; } container rp { config false; description "State information of the RP."; leaf rp-address { type inet:ip-address; description "RP address."; } leaf policy-name { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. If a policy is not specified, the entire multicast address space is accepted. The definition of such a policy is outside the scope of this document."; } leaf up-time { type rt-types:timeticks64; description "The number of time ticks (hundredths of a second) since the RP became actively available."; } } leaf rp-candidate-next-advertisement { type uint16; units seconds; config false; Liu, et al. Expires November 20, 2018 [Page 69] Internet-Draft PIM YANG May 2018 description "The remaining time interval in seconds until the next RP candidate advertisement will be sent."; } } // bsr container rp-list { config false; description "Containing a list of RPs."; list ipv4-rp { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address mode"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "RP address."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } leaf info-source-address { type inet:ipv4-address; description "The address where RP information is learned."; } uses rp-state-attributes; } list ipv6-rp { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address mode"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; Liu, et al. Expires November 20, 2018 [Page 70] Internet-Draft PIM YANG May 2018 description "RP address."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } leaf info-source-address { type inet:ipv6-address; description "The address where RP information is learned."; } uses rp-state-attributes; } } // rp-list container rp-mappings { config false; description "Containing a list of group-to-RP mappings."; list ipv4-rp { when "../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "group-range rp-address"; description "A list of group-to-RP mappings."; leaf group-range { type inet:ipv4-prefix; description "Group range presented in the format of prefix."; } leaf rp-address { type inet:ipv4-address; description "RP address."; } uses rp-mapping-state-attributes; } list ipv6-rp { when "../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; Liu, et al. Expires November 20, 2018 [Page 71] Internet-Draft PIM YANG May 2018 } key "group-range rp-address"; description "A list of IPv6 RP addresses."; leaf group-range { type inet:ipv6-prefix; description "Group range presented in the format of prefix."; } leaf rp-address { type inet:ipv6-address; description "RP address."; } uses rp-mapping-state-attributes; } } // rp-mappings } // rp } // augment /* * Notifications */ notification pim-rp-event { description "Notification event for RP."; leaf event-type { type rp-event-type; description "Event type."; } uses pim-base:pim-instance-af-state-ref; leaf group { type rt-types:ip-multicast-group-address; description "Group address."; } leaf rp-address { type inet:ip-address; description "RP address."; } leaf is-rpt { type boolean; description "'true' if the tree is RPT (RP-Tree)."; } leaf mode { type identityref { base pim-base:pim-mode; } description "PIM mode."; } Liu, et al. Expires November 20, 2018 [Page 72] Internet-Draft PIM YANG May 2018 leaf message-origin { type inet:ip-address; description "Where the message is originated."; } } } 6.3. PIM-SM Module This module references [RFC4607] and [RFC7761]. file "ietf-pim-sm@2018-04-16.yang" module ietf-pim-sm { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-sm"; prefix pim-sm; import ietf-inet-types { prefix "inet"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } import ietf-pim-rp { prefix "pim-rp"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Liu, et al. Expires November 20, 2018 [Page 73] Internet-Draft PIM YANG May 2018 Editor: Anish Peter Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) SM (Sparse Mode) model. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM. RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.2."; } /* * Features */ feature spt-switch-infinity { description "This feature indicates that the system supports configuration choice whether to trigger the switchover from the RPT (Rendezvous Point Tree) to the SPT (Shortest Path Tree)."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode Liu, et al. Expires November 20, 2018 [Page 74] Internet-Draft PIM YANG May 2018 (PIM-SM): Protocol Specification (Revised). Sec. 4.2."; } feature spt-switch-policy { description "This feature indicates that the system supports configuring policy for the switchover from the RPT to the SPT."; reference "RFC7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). Sec. 4.2."; } /* * Identities */ identity rp-sm { base pim-rp:rp-mode; description "SM (Sparse Mode)."; } /* * Groupings */ grouping static-rp-sm-container { description "Grouping that contains SM attributes for static RP."; container sm { presence "Indicate the support of sparse mode."; description "PIM SM configuration data."; uses pim-rp:static-rp-attributes; } // sm } // static-rp-sm-container /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM SM augmentation."; container sm { description "PIM SM configuration data."; Liu, et al. Expires November 20, 2018 [Page 75] Internet-Draft PIM YANG May 2018 container asm { description "ASM (Any Source Multicast) attributes."; container anycast-rp { presence "Present to enable anycast RP (Rendezvous Point)."; description "Anycast RP attributes."; list ipv4-anycast-rp { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "anycast-address rp-address"; description "A list of IPv4 anycast RP settings, only applicable when pim-base:address-family is IPv4."; leaf anycast-address { type inet:ipv4-address; description "IP address of the anycast RP set. This IP address is used by the multicast groups or sources to join or register."; } leaf rp-address { type inet:ipv4-address; description "IP address of the router configured with anycast RP. This is the IP address where the Register messages are forwarded."; } } list ipv6-anycast-rp { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "anycast-address rp-address"; description "A list of IPv6 anycast RP settings, only applicable when pim-base:address-family is IPv6."; leaf anycast-address { type inet:ipv6-address; description "IP address of the anycast RP set. This IP address Liu, et al. Expires November 20, 2018 [Page 76] Internet-Draft PIM YANG May 2018 is used by the multicast groups or sources to join or register."; } leaf rp-address { type inet:ipv6-address; description "IP address of the router configured with anycast RP. This is the IP address where the Register messages are forwarded."; } } } container spt-switch { description "SPT (Shortest Path Tree) switching attributes."; container infinity { if-feature spt-switch-infinity; presence "Present if SPT switchover threshold is set to infinity, according to the policy specified below."; description "The receiver's DR (Designated Router) never triggers the switchover from the RPT to the SPT."; leaf policy-name { if-feature spt-switch-policy; type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. The groups accepted by this policy have the SPT switchover threshold set to infinity, meaning that they will stay on the shared tree forever. If a policy is not specified, the entire multicast address space is accepted. The definition of such a policy is outside the scope of this document."; } } // infinity } } // asm container ssm { presence "Present to enable SSM (Source-Specific Multicast)."; description Liu, et al. Expires November 20, 2018 [Page 77] Internet-Draft PIM YANG May 2018 "SSM (Source-Specific Multicast) attributes."; leaf range-policy { type string; description "The string value is the name to uniquely identify a policy that contains one or more policy rules used to accept or reject certain multicast groups. The groups accepted by this policy define the multicast group rang used by SSM. If a policy is not specified, the default SSM multicast group rang is used. The default SSM multicast group range is 232.0.0.0/8 for IPv4 and ff3x::/96 for IPv6 where x reprents any valid scope identifier. The definition of such a policy is outside the scope of this document."; reference "RFC4607: Source-Specific Multicast for IP."; } } // ssm } // sm } // augment augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { description "PIM SM augmentation."; container sm { presence "Present to enable sparse-mode."; description "PIM SM configuration data."; leaf passive { type empty; description "Specifies that no PIM messages are sent or accepted on this PIM interface, but the interface can be included in a multicast forwarding entry."; } } // sm } // augment augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv4-rp" { description "PIM SM augmentation."; Liu, et al. Expires November 20, 2018 [Page 78] Internet-Draft PIM YANG May 2018 uses static-rp-sm-container; } // augment augment "/rt:routing/rt:control-plane-protocols/pim-base:pim/" + "pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv6-rp" { description "PIM SM augmentation."; uses static-rp-sm-container; } // augment } 6.4. PIM-DM Module This module references [RFC3973]. file "ietf-pim-dm@2018-04-16.yang" module ietf-pim-dm { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-dm"; prefix pim-dm; import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Liu, et al. Expires November 20, 2018 [Page 79] Internet-Draft PIM YANG May 2018 Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) DM (Dense Mode) model. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-04-16 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM. RFC 3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)."; } /* * Configuration data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family" { description "PIM DM (Dense Mode) augmentation."; container dm { presence "Present to enable dense-mode."; description "PIM DM configuration data."; } // Dm Liu, et al. Expires November 20, 2018 [Page 80] Internet-Draft PIM YANG May 2018 } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { description "PIM DM augmentation to PIM base interface."; container dm { presence "Present to enable dense-mode."; description "PIM DM configuration data."; } // sm } // augment } 6.5. PIM-BIDIR Module This module references [RFC5015]. file "ietf-pim-bidir@2018-04-16.yang" module ietf-pim-bidir { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-pim-bidir"; prefix pim-bidir; import ietf-inet-types { prefix "inet"; } import ietf-routing-types { prefix "rt-types"; } import ietf-interfaces { prefix "if"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } Liu, et al. Expires November 20, 2018 [Page 81] Internet-Draft PIM YANG May 2018 import ietf-pim-rp { prefix "pim-rp"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Editor: Xufeng Liu Editor: Pete McAllister Editor: Anish Peter Editor: Mahesh Sivakumar Editor: Yisong Liu Editor: Fangwei Hu "; description "The YANG module defines a PIM (Protocol Independent Multicast) BIDIR (Bidirectional) mode model. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2018-04-16 { description Liu, et al. Expires November 20, 2018 [Page 82] Internet-Draft PIM YANG May 2018 "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM. RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM)."; } /* * Features */ feature intf-df-election { description "Support configuration of interface DF election."; reference "RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM). Sec. 3.5."; } /* * Identities */ identity rp-bidir { base pim-rp:rp-mode; description "BIDIR (Bidirectional) mode."; } identity df-state { description "DF (Designated Forwarder) election state type."; reference "RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM)."; } identity df-state-offer { base df-state; description "Initial election state. When in the Offer state, a router thinks it can eventually become the winner and periodically generates Offer messages."; } identity df-state-lose { base df-state; description "There either is a different election winner or that no Liu, et al. Expires November 20, 2018 [Page 83] Internet-Draft PIM YANG May 2018 router on the link has a path to the RPA (Rendezvous-Point Address)."; } identity df-state-win { base df-state; description "The router is the acting DF without any contest."; } identity df-state-backoff { base df-state; description "The router is the acting DF but another router has made a bid to take over."; } /* * Groupings */ grouping static-rp-bidir-container { description "Grouping that contains BIDIR (Bidirectional) attributes for static RP (Rendezvous-Point)."; container bidir { presence "Indicate the support of BIDIR mode."; description "PIM BIDIR configuration data."; uses pim-rp:static-rp-attributes; } // bidir } // static-rp-bidir-container grouping interface-df-election-state-attributes { description "Grouping that contains the state attributes of a DF election on an interface."; leaf interface-state { type identityref { base df-state; } description "Interface state with respect to the DF election."; } leaf up-time { type rt-types:timeticks64; description Liu, et al. Expires November 20, 2018 [Page 84] Internet-Draft PIM YANG May 2018 "The number of time ticks (hundredths of a second) since the current DF has been elected as the winner."; } leaf winner-metric { type uint32; description "The unicast routing metric used by the DF to reach the RP. The value is announced by the DF."; } leaf winner-metric-preference { type uint32; description "The preference value assigned to the unicast routing protocol that the DF used to obtain the route to the RP. The value is announced by the DF."; } } // interface-df-election-state-attributes /* * Configuration data and operational state date nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family" { description "PIM BIDIR (Bidirectional) augmentation."; container bidir { presence "Present to enable BIDIR mode."; description "PIM BIDIR configuration data."; } // bidir } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family" { description "PIM BIDIR augmentation."; container bidir { presence "Present to enable BIDIR mode."; description "PIM BIDIR configuration data."; container df-election { if-feature intf-df-election; description "DF election attributes."; leaf offer-interval { type uint16; Liu, et al. Expires November 20, 2018 [Page 85] Internet-Draft PIM YANG May 2018 units milliseconds; default 100; description "Offer interval specifies the interval between repeated DF election messages."; } leaf backoff-interval { type uint16; units milliseconds; default 1000; description "This is the interval that the acting DF waits between receiving a better DF Offer and sending the Pass message to transfer DF responsibility"; } leaf offer-multiplier { type uint8; default 3; description "This is number of transmission attempts for DF election messages. When a DF election Offer or Winner message fails to be received, the message is retransmitted. The offer-multiplier sets the minimum number of DF election messages that must fail to be received for DF election to fail. If a router receives from a neighbor a better offer than its own, the router stops participating in the election for a period of offer-multiplier * offer-interval. Eventually, all routers except the best candidate stop sending Offer messages."; } } // df-election } // bidir } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv4-rp" { description "PIM BIDIR augmentation."; uses static-rp-bidir-container; } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/pim-rp:rp/" + "pim-rp:static-rp/pim-rp:ipv6-rp" { description "PIM BIDIR augmentation."; Liu, et al. Expires November 20, 2018 [Page 86] Internet-Draft PIM YANG May 2018 uses static-rp-bidir-container; } // augment /* * Operational state data nodes */ augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:address-family/pim-rp:rp" { description "PIM BIDIR augmentation to RP state data."; container bidir { config false; description "PIM BIDIR state data."; container df-election { description "DF election data."; list ipv4-rp { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "The address of the RP."; } } // ipv4-rp list ipv6-rp { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; description "The address of the RP."; } } // ipv6-rp } // df-election Liu, et al. Expires November 20, 2018 [Page 87] Internet-Draft PIM YANG May 2018 container interface-df-election { description "Interface DF election data."; list ipv4-rp { when "../../../../pim-base:address-family = 'rt:ipv4'" { description "Only applicable to IPv4 address family."; } key "rp-address interface-name"; description "A list of IPv4 RP addresses."; leaf rp-address { type inet:ipv4-address; description "The address of the RP."; } leaf interface-name { type if:interface-ref; description "The name of the interface for which the DF state is being maintained."; } leaf df-address { type inet:ipv4-address; description "The address of the elected DF, which is the winner of the DF Election process."; } uses interface-df-election-state-attributes; } // ipv4-rp list ipv6-rp { when "../../../../pim-base:address-family = 'rt:ipv6'" { description "Only applicable to IPv6 address family."; } key "rp-address interface-name"; description "A list of IPv6 RP addresses."; leaf rp-address { type inet:ipv6-address; description "The address of the RP."; } leaf interface-name { type if:interface-ref; description "The address of the RP."; } Liu, et al. Expires November 20, 2018 [Page 88] Internet-Draft PIM YANG May 2018 leaf df-address { type inet:ipv6-address; description "DF address."; } uses interface-df-election-state-attributes; } // ipv6-rp } // interface-df-election } } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family/pim-base:neighbors/" + "pim-base:ipv4-neighbor" { description "PIM BIDIR augmentation to the IPv4 neighbor state data."; leaf bidir-capable { type boolean; description "'true' if the neighbor is using the Bidirectional Capable option in the last Hello message."; } } // augment augment "/rt:routing/rt:control-plane-protocols/" + "pim-base:pim/pim-base:interfaces/pim-base:interface/" + "pim-base:address-family/pim-base:neighbors/" + "pim-base:ipv6-neighbor" { description "PIM BIDIR augmentation to the IPv6 neighbor state data."; leaf bidir-capable { type boolean; description "'true' if the neighbor is using the Bidirectional Capable option in the last Hello message."; } } // augment } 7. Implementation Status This section to be removed by the RFC editor. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Liu, et al. Expires November 20, 2018 [Page 89] Internet-Draft PIM YANG May 2018 Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". This document is the work result of the PIM working group's YANG multicast design team. The following wiki page contains the information on the design team members, the meeting discussions, lists of modeled features, and which features are supported by which existing implementations: https://trac.ietf.org/trac/pim/wiki/yang 8. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: Liu, et al. Expires November 20, 2018 [Page 90] Internet-Draft PIM YANG May 2018 pim-base:graceful-restart This subtree specifies the configuration for the PIM graceful restart at the global level on a device. Modifying the configuration can cause temporary interruption to the multicast routing during restart. pim-base:address-family/pim-base:graceful-restart This subtree specifies the per address family configuration for the PIM graceful restart on a device. Modifying the configuration can cause temporary interruption to the multicast routing during restart. pim-base:address-family/pim-rp:pim-rp:rp This subtree specifies the configuration for the PIM Rendezvous Point (RP) on a device. Modifying the configuration can cause RP malfunctions. pim-base:address-family/pim-sm:sm This subtree specifies the configuration for the PIM Sparse Mode (PIM-SM) on a device. Modifying the configuration can cause multicast traffic disabled or rerouted in PIM-SM. pim-base:address-family/pim-dm:dm This subtree specifies the configuration for the PIM Dense Mode (PIM-DM) on a device. Modifying the configuration can cause multicast traffic disabled or rerouted in PIM-DM. pim-base:address-family/pim-bidir:bidir This subtree specifies the configuration for the PIM Bidirectional Mode (PIM-BIDIR) on a device. Modifying the configuration can cause multicast traffic disabled or rerouted in PIM-BIDIR. pim-base:interfaces This subtree specifies the configuration for the PIM interfaces on a device. Modifying the configuration can cause the PIM protocol to get insufficient or incorrect information. These subtrees are all nnder /rt:routing/rt:control-plane-protocols/ pim-base:pim. Unauthorized access to any data node of these subtrees can adversely affect the multicast routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or Liu, et al. Expires November 20, 2018 [Page 91] Internet-Draft PIM YANG May 2018 notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /rt:routing/rt:control-plane-protocols/pim-base:pim Unauthorized access to any data node of the above subtree can disclose the operational state information of PIM on this device. 9. IANA Considerations RFC Ed.: In this section, replace all occurrences of 'XXXX' with the actual RFC number (and remove this note). This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-base Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-bidir Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-dm Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-rp Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-pim-sm Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. -------------------------------------------------------------------- This document registers the following YANG modules in the YANG Module Names registry [RFC7950]: Liu, et al. Expires November 20, 2018 [Page 92] Internet-Draft PIM YANG May 2018 -------------------------------------------------------------------- name: ietf-pim-base namespace: urn:ietf:params:xml:ns:yang:ietf-pim-base prefix: pim-base reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-bidir namespace: urn:ietf:params:xml:ns:yang:ietf-pim-bidir prefix: pim-bidir reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-dm namespace: urn:ietf:params:xml:ns:yang:ietf-pim-dm prefix: pim-dm reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-rp namespace: urn:ietf:params:xml:ns:yang:ietf-pim-rp prefix: pim-rp reference: RFC XXXX -------------------------------------------------------------------- -------------------------------------------------------------------- name: ietf-pim-sm namespace: urn:ietf:params:xml:ns:yang:ietf-pim-sm prefix: pim-sm reference: RFC XXXX -------------------------------------------------------------------- 10. Acknowledgements The authors would like to thank Steve Baillargeon, Guo Feng, Robert Kebler, Tanmoy Kundu, and Stig Venaas for their valuable contributions. 11. References 11.1. Normative References [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, . Liu, et al. Expires November 20, 2018 [Page 93] Internet-Draft PIM YANG May 2018 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10.17487/RFC4610, August 2006, . [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, . [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2008, . [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, DOI 10.17487/RFC5060, January 2008, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . Liu, et al. Expires November 20, 2018 [Page 94] Internet-Draft PIM YANG May 2018 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-13 (work in progress), March 2018. Liu, et al. Expires November 20, 2018 [Page 95] Internet-Draft PIM YANG May 2018 11.2. Informative References [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10.17487/RFC3618, October 2003, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", draft-ietf-netmod-rfc6087bis-20 (work in progress), March 2018. Liu, et al. Expires November 20, 2018 [Page 96] Internet-Draft PIM YANG May 2018 Appendix A. Data Tree Example This section contains an example of an instance data tree in the JSON encoding [RFC7951], containing both configuration and state data. lo0: 2001:db8:0:200::1 (RP address) | +-------+ | | | Router| | eth21 +---+ R2 +---+ eth23 | | (RP) | | | +-------+ | lo0: 2001:db8:0:300::1 | +-------+ | | +-------+ | | | Router| | | | Router| | eth10 +--+ R1 +---+ eth12 eth32 +---+ R3 +--+ eth30 | | | | | | | | | +-------+ | +-------+ | +-------+ | | +-------+ | +-------+ | | | | | Router| | | | | | +--+ +---+ R4 +---+ +-------+ +--+ | | | | | | | | | Router| | | | +-------+ | | +-------+ +---+ R5 | | +-------+ Source | | | Receiver | +-------+ The configuration instance data tree for Router R3 in the above figure could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "lo0", "description": "R3 loopback interface.", "type": "iana-if-type:softwareLoopback", "ietf-ip:ipv6": { "address": [ { "ip": "2001:db8:0:300::1", "prefix-length": 64 } ] } }, { "name": "eth30", "description": "An interface connected to the receiver.", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv6": { Liu, et al. Expires November 20, 2018 [Page 97] Internet-Draft PIM YANG May 2018 "forwarding": true } }, { "name": "eth32", "description": "An interface connected to RP (R2).", "type": "iana-if-type:ethernetCsmacd", "ietf-ip:ipv6": { "forwarding": true } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.3", "control-plane-protocols": { "ietf-pim-base:pim": { "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-rp:rp": { "static-rp": { "ipv6-rp": [ { "rp-address": "2001:db8:0:200::1", "ietf-pim-sm:sm": { } } ] } } } ], "interfaces": { "interface": [ { "name": "lo0", "address-family": [ { "address-family": "ietf-routing:ipv6", "hello-interval": "infinity", "ietf-pim-sm:sm": { } } ] }, { "name": "eth30", Liu, et al. Expires November 20, 2018 [Page 98] Internet-Draft PIM YANG May 2018 "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { } } ] }, { "name": "eth32", "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { } } ] } ] } } } } } The corresponding operational state data for Router R3 could be as follows: { "ietf-interfaces:interfaces": { "interface": [ { "name": "lo0", "description": "R3 loopback interface.", "type": "iana-if-type:softwareLoopback", "phys-address": "00:00:5e:00:53:03", "oper-status": "up", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "ietf-ip:ipv6": { "mtu": 1500, "address": [ { "ip": "2001:db8:0:300::1", "prefix-length": 64, "origin": "static", "status": "preferred" Liu, et al. Expires November 20, 2018 [Page 99] Internet-Draft PIM YANG May 2018 }, { "ip": "fe80::200:5eff:fe00:5303", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ ] } }, { "name": "eth30", "description": "An interface connected to the receiver.", "type": "iana-if-type:ethernetCsmacd", "phys-address": "00:00:5e:00:53:30", "oper-status": "up", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "ietf-ip:ipv6": { "forwarding": true, "mtu": 1500, "address": [ { "ip": "fe80::200:5eff:fe00:5330", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ ] } }, { "name": "eth32", "description": "An interface connected to RP (R2).", "type": "iana-if-type:ethernetCsmacd", "phys-address": "00:00:5e:00:53:32", "oper-status": "up", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "ietf-ip:ipv6": { "forwarding": true, "mtu": 1500, Liu, et al. Expires November 20, 2018 [Page 100] Internet-Draft PIM YANG May 2018 "address": [ { "ip": "fe80::200:5eff:fe00:5332", "prefix-length": 64, "origin": "link-layer", "status": "preferred" } ], "neighbor": [ { "ip": "fe80::200:5eff:fe00:5323", "link-layer-address": "00:00:5e:00:53:23", "origin": "dynamic", "is-router": [null], "state": "reachable" } ] } } ] }, "ietf-routing:routing": { "router-id": "203.0.113.1", "interfaces": { "interface": [ "lo0", "eth30", "eth32" ] }, "control-plane-protocols": { "ietf-pim-base:pim": { "address-family": [ { "address-family": "ietf-routing:ipv6", "statistics": { "discontinuity-time": "2018-01-23T12:34:56-05:00" }, "topology-tree-info": { "ipv6-route": [ { "group": "ff06::1", "source-address": "*", "is-rpt": true, "expiration": 16, "incoming-interface": "eth32", "is-spt": false, "mode": "pim-asm", Liu, et al. Expires November 20, 2018 [Page 101] Internet-Draft PIM YANG May 2018 "msdp-learned": false, "rp-address": "2001:db8:0:200::1", "rpf-neighbor": "fe80::200:5eff:fe00:5323", "up-time": 123400, "outgoing-interface": [ { "name": "eth30", "expiration": 36, "up-time": 223400, "jp-state": "join" } ] }, { "group": "ff06::1", "source-address": "2001:db8:1:1::100", "is-rpt": false, "expiration": 8, "incoming-interface": "eth32", "is-spt": true, "mode": "pim-asm", "msdp-learned": false, "rp-address": "2001:db8:0:200::1", "rpf-neighbor": "fe80::200:5eff:fe00:5323", "up-time": 5200, "outgoing-interface": [ { "name": "eth30", "expiration": 6, "up-time": 5600, "jp-state": "join" } ] } ] }, "ietf-pim-rp:rp": { "static-rp": { "ipv6-rp": [ { "rp-address": "2001:db8:0:200::1", "ietf-pim-sm:sm": { } } ] }, "rp-list": { "ipv6-rp": [ Liu, et al. Expires November 20, 2018 [Page 102] Internet-Draft PIM YANG May 2018 { "rp-address": "2001:db8:0:200::1", "mode": "ietf-pim-sm:rp-sm", "info-source-type": "static", "up-time": 323400, "expiration": "not-set" } ] }, "rp-mappings": { "ipv6-rp": [ { "group-range": "ff06::1/128", "rp-address": "2001:db8:0:200::1", "up-time": 123400, "expiration": "36" } ] } } } ], "interfaces": { "interface": [ { "name": "lo0", "address-family": [ { "address-family": "ietf-routing:ipv6", "hello-interval": "infinity", "ietf-pim-sm:sm": { }, "oper-status": "up", "gen-id": 103689, "hello-expiration": "infinity", "ipv6": { "address": [ "fe80::200:5eff:fe00:5303" ], "dr-address": "fe80::200:5eff:fe00:5303" }, "neighbors": { "ipv6-neighbor": [ ] } } ] }, Liu, et al. Expires November 20, 2018 [Page 103] Internet-Draft PIM YANG May 2018 { "name": "eth30", "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { }, "oper-status": "up", "gen-id": 203689, "hello-expiration": 18, "ipv6": { "address": [ "fe80::200:5eff:fe00:5330" ], "dr-address": "fe80::200:5eff:fe00:5330" }, "neighbors": { "ipv6-neighbor": [ ] } } ] }, { "name": "eth32", "address-family": [ { "address-family": "ietf-routing:ipv6", "ietf-pim-sm:sm": { }, "oper-status": "up", "gen-id": 303689, "hello-expiration": 21, "ipv6": { "address": [ "fe80::200:5eff:fe00:5332" ], "dr-address": "fe80::200:5eff:fe00:5332" }, "neighbors": { "ipv6-neighbor": [ { "address": "fe80::200:5eff:fe00:5323", "expiration": 28, "dr-priority": 1, "gen-id": 102, "lan-prune-delay": { "present": false Liu, et al. Expires November 20, 2018 [Page 104] Internet-Draft PIM YANG May 2018 }, "up-time": 323500 } ] } } ] } ] } } } } } Authors' Addresses Xufeng Liu Volta Networks EMail: xufeng.liu.ietf@gmail.com Pete McAllister Metaswitch Networks 100 Church Street Enfield EN2 6BQ UK EMail: pete.mcallister@metaswitch.com Anish Peter Individual EMail: anish.ietf@gmail.com Mahesh Sivakumar Juniper Networks 1133 Innovation Way Sunnyvale, California USA EMail: sivakumar.mahesh@gmail.com Liu, et al. Expires November 20, 2018 [Page 105] Internet-Draft PIM YANG May 2018 Yisong Liu Huawei Technologies Huawei Administration Building Longgang, Guangdong 518129 China EMail: liuyisong@huawei.com Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai, Shanghai 201203 China EMail: hu.fangwei@zte.com.cn Liu, et al. Expires November 20, 2018 [Page 106] ./draft-ietf-rmcat-cc-requirements-09.txt0000644000764400076440000007113312442534420017600 0ustar iustyiusty Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Informational Z. Sarker, Ed. Expires: June 15, 2015 Ericsson December 12, 2014 Congestion Control Requirements for Interactive Real-Time Media draft-ietf-rmcat-cc-requirements-09 Abstract Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for real-time media congestion avoidance technique. Requirements Language 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 RFC 2119 [RFC2119]. The terms are presented in many cases using lowercase for readability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Jesup & Sarker Expires June 15, 2015 [Page 1] Internet-Draft RTP Media Congestion Control Requirements December 2014 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 15, 2015. Copyright Notice Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Deficiencies of existing mechanisms . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Most of today's TCP congestion control schemes were developed with a focus on an use of the Internet for reliable bulk transfer of non- time-critical data, such as transfer of large files. They have also been used successfully to govern the reliable transfer of smaller chunks of data in as short a time as possible, such as when fetching Web pages. These algorithms have also been used for transfer of media streams that are viewed in a non-interactive manner, such as "streaming" video, where having the data ready when the viewer wants it is important, but the exact timing of the delivery is not. Jesup & Sarker Expires June 15, 2015 [Page 2] Internet-Draft RTP Media Congestion Control Requirements December 2014 When doing real-time interactive media, the requirements are different; one needs to provide the data continuously, within a very limited time window (no more than 100s of milliseconds end-to-end delay), the sources of data may be able to adapt the amount of data that needs sending within fairly wide margins but can be rate limited by the application- even not always have data to send, and may tolerate some amount of packet loss, but since the data is generated in real-time, sending "future" data is impossible, and since it's consumed in real-time, data delivered late is commonly useless. While the requirements for real-time interactive media differ from the requirements for the other flow types, these other flow types will be present in the network. The congestion control algorithm for real-time interactive media must work properly when these other flow types are present as cross traffic on the network. One particular protocol portfolio being developed for this use case is WebRTC [I-D.ietf-rtcweb-overview], where one envisions sending multiple flows using the Real-time Transport Protocol (RTP) [RFC3550] between two peers, in conjunction with data flows, all at the same time, without having special arrangements with the intervening service providers. As RTP does not provide any congestion control mechanism; a set of circuit breakers, such as [I-D.ietf-avtcore-rtp-circuit-breakers], are required to protect the network from excessive congestion caused by the non-congestion controlled flows. When the real-time interactive media is congestion controlled, it is recommended that the congestion control mechanism operates within the constraints defined by these circuit breakers when circuit breaker is present and that it should not cause congestion collapse when circuit breaker is not implemented. Given that this use case is the focus of this document, use cases involving non-interactive media such as video streaming, and use cases using multicast/broadcast-type technologies, are out of scope. The terminology defined in [I-D.ietf-rtcweb-overview] is used in this memo. 2. Requirements 1. The congestion control algorithm must attempt to provide as-low- as-possible-delay transit for interactive real-time traffic while still providing a useful amount of bandwidth. There may be lower limits on the amount of bandwidth that is useful, but this is largely application-specific and the application may be able to modify or remove flows in order allow some useful flows to get enough bandwidth. (Example: not enough bandwidth for low-latency video+audio, but enough for audio-only.) Jesup & Sarker Expires June 15, 2015 [Page 3] Internet-Draft RTP Media Congestion Control Requirements December 2014 A. Jitter (variation in the bitrate over short time scales) also is relevant, though moderate amounts of jitter will be absorbed by jitter buffers. Transit delay should be considered to track the short-term maximums of delay including jitter. B. It should provide this as-low-as-possible-delay transit and minimize self-induced latency even when faced with intermediate bottlenecks and competing flows. Competing flows may limit what's possible to achieve. C. It should be resilience to the effects of the events, such as routing changes, which may alter or remove bottlenecks or change the bandwidth available especially if there is a reduction in available bandwidth or increase in observed delay. It is expected that the mechanism reacts quickly to the such events to avoid delay buildup. In the context of this memo, a 'quick' reaction is on the order of a few RTTs, subject to the constraints of the media codec, but is likely within a second. Reaction on the next RTT is explicitly not required, since many codecs cannot adapt their sending rate that quickly, but equally response cannot be arbitrarily delayed. D. It should react quickly to handle both local and remote interface changes (WLAN to 3G data, etc) which may radically change the bandwidth available or bottlenecks, especially if there is a reduction in available bandwidth or increase in bottleneck delay. It is assumed that an interface change can generate a notification to the algorithm. E. The real-time interactive media applications can be rate limited. This means the offered loads can be less than the available bandwidth at any given moment, and may vary dramatically over time, including dropping to no load and then resuming a high load, such as in a mute/unmute operation. Hence, the algorithm must be designed to handle such behavior from media source or application. Note that the reaction time between a change in the bandwidth available from the algorithm and a change in the offered load is variable, and may be different when increasing versus decreasing. F. The algorithm requires to avoid building up queues when competing with short-term bursts of traffic (for example, traffic generated by web-browsing) which can quickly saturate a local-bottleneck router or link, but also clear quickly. The algorithm should also react quickly to regain Jesup & Sarker Expires June 15, 2015 [Page 4] Internet-Draft RTP Media Congestion Control Requirements December 2014 its previous share of the bandwidth when the local- bottleneck or link is cleared. G. Similarly periodic bursty flows such as MPEG DASH [MPEG_DASH] or proprietary media streaming algorithms may compete in bursts with the algorithm, and may not be adaptive within a burst. They are often layered on top of TCP but use TCP in a bursty manner that can interact poorly with competing flows during the bursts. The algorithm must not increase the already existing delay buildup during those bursts. Note that this competing traffic may be on a shared access link, or the traffic burst may cause a shift in the location of the bottleneck for the duration of the burst. 2. The algorithm must be fair to other flows, both real-time flows (such as other instances of itself), and TCP flows, both long- lived and bursts such as the traffic generated by a typical web browsing session. Note that 'fair' is a rather hard-to-define term. It should be fair with itself, giving fair share of the bandwidth to multiple flows with similar RTTs, and if possible to multiple flows with different RTTs. A. Existing flows at a bottleneck must also be fair to new flows to that bottleneck, and must allow new flows to ramp up to a useful share of the bottleneck bandwidth as quickly as possible. A useful share will depend on the media types involved, total bandwidth available and the user experience requirements of a particular service. Note that relative RTTs may affect the rate new flows can ramp up to a reasonable share. 3. The algorithm should not starve competing TCP flows, and should as best as possible avoid starvation by TCP flows. A. The congestion control should prioritise achieving a useful share of the bandwidth depending on the media types and total available bandwidth over achieving as low as possible transit delay, when these two requirements are in conflict. 4. The algorithm should as quickly as possible adapt to initial network conditions at the start of a flow. This should occur both if the initial bandwidth is above or below the bottleneck bandwidth. A. The algorithm should allow different modes of adaptation for example,the startup adaptation may be faster than adaptation later in a flow. It should allow for both slow-start operation (adapt up) and history-based startup (start at a Jesup & Sarker Expires June 15, 2015 [Page 5] Internet-Draft RTP Media Congestion Control Requirements December 2014 point expected to be at or below channel bandwidth from historical information, which may need to adapt down quickly if the initial guess is wrong). Starting too low and/or adapting up too slowly can cause a critical point in a personal communication to be poor ("Hello!"). Starting over-bandwidth causes other problems for user experience, so there's a tension here. Alternative methods to help startup like probing during setup with dummy data may be useful in some applications; in some cases there will be a considerable gap in time between flow creation and the initial flow of data. Again, A flow may need to change adaptation rates due to network conditions or changes in the provided flows (such as un-muting or sending data after a gap). 5. The algorithm should be stable if the RTP streams are halted or discontinuous (for example - Voice Activity Detection). A. After stream resumption, the algorithm should attempt to rapidly regain its previous share of the bandwidth; the aggressiveness with which this is done will decay with the length of the pause. 6. The algorithm should where possible merge information across multiple RTP streams sent between two endpoints, when those RTP streams share a common bottleneck, whether or not those streams are multiplexed onto the same ports, in order to allow congestion control of the set of streams together instead of as multiple independent streams. This allows better overall bandwidth management, faster response to changing conditions, and fairer sharing of bandwidth with other network users. A. The algorithm should also share information and adaptation with other non-RTP flows between the same endpoints, such as a WebRTC DataChannel [I-D.ietf-rtcweb-data-channel], when possible. B. When there are multiple streams across the same 5-tuple coordinating their bandwidth use and congestion control, the algorithm should allow the application to control the relative split of available bandwidth. The most correlated bandwidth usage would be with other flows on the same 5-tuple, but there may be use in coordinating measurement and control of the local link(s). Use of information about previous flows, especially on the same 5-tuple, may be useful input to the algorithm, especially to startup performance of a new flow. Jesup & Sarker Expires June 15, 2015 [Page 6] Internet-Draft RTP Media Congestion Control Requirements December 2014 7. The algorithm should not require any special support from network elements to convey congestion related information to be functional. As much as possible, it should leverage available information about the incoming flow to provide feedback to the sender. Examples of this information are the packet arrival times, acknowledgements and feedback, packet timestamps, and packet losses, Explicit Congestion Notification (ECN) [RFC3168]; all of these can provide information about the state of the path and any bottlenecks. However, the use of available information is algorithm dependent. A. Extra information could be added to the packets to provide more detailed information on actual send times (as opposed to sampling times), but should not be required. 8. Since the assumption here is a set of RTP streams, the backchannel typically should be done via RTCP[RFC3550]; one alternative would be to include it instead in a reverse RTP channel using header extensions. A. In order to react sufficiently quickly when using RTCP for a backchannel, an RTP profile such as RTP/AVPF [RFC4585] or RTP/SAVPF [RFC5124] that allows sufficiently frequent feedback must be used. Note that in some cases, backchannel messages may be delayed until the RTCP channel can be allocated enough bandwidth, even under AVPF rules. This may also imply negotiating a higher maximum percentage for RTCP data or allowing solutions to violate or modify the rules specified for AVPF. B. Bandwidth for the feedback messages should be minimized (such as via RFC 5506 [RFC5506]to allow RTCP without Sender Reports/Receiver Reports) C. Backchannel data should be minimized to avoid taking too much reverse-channel bandwidth (since this will often be used in a bidirectional set of flows). In areas of stability, backchannel data may be sent more infrequently so long as algorithm stability and fairness are maintained. When the channel is unstable or has not yet reached equilibrium after a change, backchannel feedback may be more frequent and use more reverse-channel bandwidth. This is an area with considerable flexibility of design, and different approaches to backchannel messages and frequency are expected to be evaluated. 9. Flows managed by this algorithm and flows competing against at a bottleneck may have different DSCP[RFC5865] markings depending Jesup & Sarker Expires June 15, 2015 [Page 7] Internet-Draft RTP Media Congestion Control Requirements December 2014 on the type of traffic, or may be subject to flow-based QoS. A particular bottleneck or section of the network path may or may not honor DSCP markings. The algorithm should attempt to leverage DSCP markings when they're available. A. In WebRTC, a division of packets into 4 classes is envisioned in order of priority: faster-than-audio, audio, video, best-effort, and bulk-transfer. Typically the flows managed by this algorithm would be audio or video in that hierarchy, and feedback flows would be faster-than-audio. 10. The algorithm should sense the unexpected lack of backchannel information as a possible indication of a channel overuse problem and react accordingly to avoid burst events causing a congestion collapse. 11. The algorithm should be stable and maintain low-delay when faced with Active Queue Management (AQM) algorithms. Also note that these algorithms may apply across multiple queues in the bottleneck, or to a single queue 3. Deficiencies of existing mechanisms Among the existing congestion control mechanisms TCP Friendly Rate Control (TFRC) [RFC5348] is the one which claims to be suitable for real-time interactive media. TFRC is, an equation based, congestion control mechanism which provides reasonably fair share of the bandwidth when competing with TCP flows and offers much lower throughput variations than TCP. This is achieved by a slower response to the available bandwidth change than TCP. TFRC is designed to perform best with applications which has fixed packet size and does not have fixed period between sending packets. TFRC operates on detecting loss events and reacts to loss caused by congestion by reducing its sending rate. It allows applications to increase the sending rate until loss is observed in the flows. As it is noted in IAB/IRTF report [RFC7295] large buffers are available in the network elements which introduces additional delay in the communication, it becomes important to take all possible congestion indications into considerations. Looking at the current Internet deployment, TFRC's only consideration of loss events as congestion indication can be considered as biggest lacking. A typical real-time interactive communication includes live encoded audio and video flow(s). In such a communication scenario an audio source typically needs fixed interval between packets, needs to vary their segment size instead of their packet rate in response to congestion and sends smaller packets, a variant of TFRC , Small- Jesup & Sarker Expires June 15, 2015 [Page 8] Internet-Draft RTP Media Congestion Control Requirements December 2014 Packet TFRC (TFRC-SP) [RFC4828] addresses the issues related to such kind of sources ; a video source generally varies video frame sizes, can produce large frames which need to be further fragmented to fit into path Maximum Transmission Unit (MTU) size, and have almost fixed interval between producing frames under a certain frame rate, TFRC is known to be less optimal when using with such video sources. There are also some mismatches between TFRC's design assumptions and how the media sources in a typical real-time interactive application works. TFRC is design to maintain smooth sending rate however media sources can change rates in steps for both rate increase and rate decrease. TFRC can operate in two modes - i) Bytes per second and ii) packets per second, where typical real-time interactive media sources operates on bit per second. There are also limitations on how quickly the media sources can adapt to specific sending rates. The modern video encoders can operate on a mode where they can vary the output bitrate a lot depending on the way there are configured, the current scene it is encoding and more. Therefore, it is possible that the video source does not always output at a bitrate they are allowed to. TFRC tries to raise its sending rate when transmitting at maximum allowed rate and increases only twice the current transmission rate hence it may create issues when the video source vary their bitrates. Moreover, there are number of studies on TFRC which shows it's limitations which includes TFRC's unfairness on low statistically multiplexed links, oscillatory behavior, performance issue in highly dynamic loss rates conditions and more [CH09]. Looking at all these deficiencies it can be concluded that the requirements of congestion control mechanism for real-time interactive media cannot be met by TFRC as defined in the standard. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations An attacker with the ability to delete, delay or insert messages in the flow can fake congestion signals, unless they are passed on a tamper-proof path. Since some possible algorithms depend on the timing of packet arrival, even a traditional protected channel does not fully mitigate such attacks. Jesup & Sarker Expires June 15, 2015 [Page 9] Internet-Draft RTP Media Congestion Control Requirements December 2014 An attack that reduces bandwidth is not necessarily significant, since an on-path attacker could break the connection by discarding all packets. Attacks that increase the perceived available bandwidth are conceivable, and need to be evaluated. Such attacks could result in starvation of competing flows and permit amplification attacks. Algorithm designers should consider the possibility of malicious on- path attackers. 6. Acknowledgements This document is the result of discussions in various fora of the WebRTC effort, in particular on the rtp-congestion@alvestrand.no mailing list. Many people contributed their thoughts to this. 7. References 7.1. Normative References [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-13 (work in progress), November 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008. 7.2. Informative References [CH09] Choi, S. and M. Handley, "Designing TCP-Friendly Window- based Congestion Control for Real-time Multimedia Applications", PFLDNeT 2009 Workshop , May 2009. Jesup & Sarker Expires June 15, 2015 [Page 10] Internet-Draft RTP Media Congestion Control Requirements December 2014 [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-08 (work in progress), December 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. [MPEG_DASH] "Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", April 2012. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2007. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, April 2009. [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010. [RFC7295] Tschofenig, H., Eggert, L., and Z. Sarker, "Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication", RFC 7295, July 2014. Authors' Addresses Randell Jesup Mozilla USA Email: randell-ietf@jesup.org Jesup & Sarker Expires June 15, 2015 [Page 11] Internet-Draft RTP Media Congestion Control Requirements December 2014 Zaheduzzaman Sarker (editor) Ericsson Sweden Email: zaheduzzaman.sarker@ericsson.com Jesup & Sarker Expires June 15, 2015 [Page 12] ./draft-ietf-rmcat-eval-criteria-14.txt0000644000764400076440000011045713634722753017234 0ustar iustyiusty RMCAT WG V. Singh Internet-Draft callstats.io Intended status: Informational J. Ott Expires: September 20, 2020 Technical University of Munich S. Holmer Google March 19, 2020 Evaluating Congestion Control for Interactive Real-time Media draft-ietf-rmcat-eval-criteria-14 Abstract The Real-time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 20, 2020. Copyright Notice Copyright (c) 2020 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 (https://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 Singh, et al. Expires September 20, 2020 [Page 1] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 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. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. RTP Log Format . . . . . . . . . . . . . . . . . . . . . 5 4. List of Network Parameters . . . . . . . . . . . . . . . . . 6 4.1. One-way Propagation Delay . . . . . . . . . . . . . . . . 6 4.2. End-to-end Loss . . . . . . . . . . . . . . . . . . . . . 6 4.3. Drop Tail Router Queue Length . . . . . . . . . . . . . . 7 4.4. Loss generation model . . . . . . . . . . . . . . . . . . 7 4.5. Jitter models . . . . . . . . . . . . . . . . . . . . . . 7 4.5.1. Random Bounded PDV (RBPDV) . . . . . . . . . . . . . 8 4.5.2. Approximately Random Subject to No-Reordering Bounded PDV (NR-RPVD) . . . . . . . . . . . . . . . . 9 4.5.3. Recommended distribution . . . . . . . . . . . . . . 10 5. Traffic Models . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. TCP traffic model . . . . . . . . . . . . . . . . . . . . 10 5.2. RTP Video model . . . . . . . . . . . . . . . . . . . . . 11 5.3. Background UDP . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 A.1. Changes in draft-ietf-rmcat-eval-criteria-07 . . . . . . 15 A.2. Changes in draft-ietf-rmcat-eval-criteria-06 . . . . . . 15 A.3. Changes in draft-ietf-rmcat-eval-criteria-05 . . . . . . 15 A.4. Changes in draft-ietf-rmcat-eval-criteria-04 . . . . . . 15 A.5. Changes in draft-ietf-rmcat-eval-criteria-03 . . . . . . 15 A.6. Changes in draft-ietf-rmcat-eval-criteria-02 . . . . . . 15 A.7. Changes in draft-ietf-rmcat-eval-criteria-01 . . . . . . 16 A.8. Changes in draft-ietf-rmcat-eval-criteria-00 . . . . . . 16 A.9. Changes in draft-singh-rmcat-cc-eval-04 . . . . . . . . . 16 A.10. Changes in draft-singh-rmcat-cc-eval-03 . . . . . . . . . 16 A.11. Changes in draft-singh-rmcat-cc-eval-02 . . . . . . . . . 16 A.12. Changes in draft-singh-rmcat-cc-eval-01 . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Singh, et al. Expires September 20, 2020 [Page 2] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 1. Introduction This memo describes the guidelines to help with evaluating new congestion control algorithms for interactive point-to-point real time media. The requirements for the congestion control algorithm are outlined in [I-D.ietf-rmcat-cc-requirements]). This document builds upon previous work at the IETF: Specifying New Congestion Control Algorithms [RFC5033] and Metrics for the Evaluation of Congestion Control Algorithms [RFC5166]. The guidelines proposed in the document are intended to help prevent a congestion collapse, promote fair capacity usage and optimize the media flow's throughput. Furthermore, the proposed congestion control algorithms are expected to operate within the envelope of the circuit breakers defined in RFC8083 [RFC8083]. This document only provides the broad set of network parameters and and traffic models for evaluating a new congestion control algorithm. The minimal requirements for congestion control proposals is to produce or present results for the test scenarios described in [I-D.ietf-rmcat-eval-test] (Basic Test Cases), which also defines the specifics for the test cases. Additionally, proponents may produce evaluation results for the wireless test scenarios [I-D.ietf-rmcat-wireless-tests]. This document does not cover application-specific implications of congestion control algorithms and how those could be evaluated. Therefore, no quality metrics are defined for performance evaluation; quality metrics and algorithms to infer those vary between media types. Metrics and algorithms to assess, e.g., quality of experience evolve continuously so that determining suitable choices is left for future work. However, there is consensus that each congestion control algorithm should be able to show that it is useful for interactive video by performing analysis using a real codecs and video sequences and state-of-the-art quality metrics. Beyond optimizing individual metrics, real-time applications may have further options to trade off performance, e.g., across multiple media; refer to the RMCAT requirements [I-D.ietf-rmcat-cc-requirements] document. Such trade-offs may be defined in the future. 2. Terminology The terminology defined in RTP [RFC3550], RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], RTCP Extended Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback Singh, et al. Expires September 20, 2020 [Page 3] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 (RTP/AVPF) [RFC4585] and Support for Reduced-Size RTCP [RFC5506] apply. 3. Metrics This document specifies testing criteria for evaluating congestion control algorithms for RTP media flows. Proposed algorithms are to prove their performance by means of simulation and/or emulation experiments for all the cases described. Each experiment is expected to log every incoming and outgoing packet (the RTP logging format is described in Section 3.1). The logging can be done inside the application or at the endpoints using PCAP (packet capture, e.g., tcpdump [tcpdump], wireshark [wireshark]). The following metrics are calculated based on the information in the packet logs: 1. Sending rate, Receiver rate, Goodput (measured at 200ms intervals) 2. Packets sent, Packets received 3. Bytes sent, bytes received 4. Packet delay 5. Packets lost, Packets discarded (from the playout or de-jitter buffer) 6. If using, retransmission or FEC: post-repair loss 7. Self-Fairness and Fairness with respect to cross traffic: Experiments testing a given congestion control proposal must report on relative ratios of the average throughput (measured at coarser time intervals) obtained by each RTP media stream. In the presence of background cross-traffic such as TCP, the report must also include the relative ratio between average throughput of RTP media streams and cross-traffic streams. During static periods of a test (i.e., when bottleneck bandwidth is constant and no arrival/departure of streams), these report on relative ratios serve as an indicator of how fair the RTP streams share bandwidth amongst themselves and against cross- traffic streams. The throughput measurement interval should be set at a few values (for example, at 1s, 5s, and 20s) in order to measure fairness across different time scales. As a general guideline, the relative ratio between congestion controlled RTP flows with the same priority level and similar Singh, et al. Expires September 20, 2020 [Page 4] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 path RTT should be bounded between (0.333 and 3.) For example, see the test scenarios described in [I-D.ietf-rmcat-eval-test]. 8. Convergence time: The time taken to reach a stable rate at startup, after the available link capacity changes, or when new flows get added to the bottleneck link. 9. Instability or oscillation in the sending rate: The frequency or number of instances when the sending rate oscillates between an high watermark level and a low watermark level, or vice-versa in a defined time window. For example, the watermarks can be set at 4x interval: 500 Kbps, 2 Mbps, and a time window of 500ms. 10. Bandwidth Utilization, defined as ratio of the instantaneous sending rate to the instantaneous bottleneck capacity. This metric is useful only when a congestion controlled RTP flow is by itself or competing with similar cross-traffic. Note that the above metrics are all objective application-independent metrics. Refer to Section 3, in [I-D.ietf-netvc-testing] for objective metrics for evaluating codecs. From the logs the statistical measures (min, max, mean, standard deviation and variance) for the whole duration or any specific part of the session can be calculated. Also the metrics (sending rate, receiver rate, goodput, latency) can be visualized in graphs as variation over time, the measurements in the plot are at 1 second intervals. Additionally, from the logs it is possible to plot the histogram or CDF of packet delay. 3.1. RTP Log Format Having a common log format simplifies running analyses across and comparing different measurements. The log file should be tab or comma separated containing the following details: Send or receive timestamp (Unix): . -- sec.usec decimal RTP payload type -- decimal SSRC -- hexadecimal RTP sequence no -- decimal RTP timestamp -- decimal marker bit 0|1 -- character Payload size -- # bytes, decimal Each line of the log file should be terminated with CRLF, CR, or LF characters. Empty lines are disregarded. Singh, et al. Expires September 20, 2020 [Page 5] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 If the congestion control implements retransmissions or FEC, the evaluation should report both packet loss (before applying error- resilience) and residual packet loss (after applying error- resilience). These data should suffice to compute the media-encoding independent metrics described above. Use of a common log will allow simplified post-processing and analysis across different implementations. 4. List of Network Parameters The implementors initially are encouraged to choose evaluation settings from the following values: 4.1. One-way Propagation Delay Experiments are expected to verify that the congestion control is able to work across a broad range of path characteristics, also including challenging situations, for example over trans-continental and/or satellite links. Tests thus account for the following different latencies: 1. Very low latency: 0-1ms 2. Low latency: 50ms 3. High latency: 150ms 4. Extreme latency: 300ms 4.2. End-to-end Loss Many paths in the Internet today are largely lossless but, with wireless networks and interference, towards remote regions, or in scenarios featuring high/fast mobility, media flows may exhibit substantial packet loss. This variety needs to be reflected appropriately by the tests. To model a wide range of lossy links, the experiments can choose one of the following loss rates, the fractional loss is the ratio of packets lost and packets sent. 1. no loss: 0% 2. 1% 3. 5% Singh, et al. Expires September 20, 2020 [Page 6] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 4. 10% 5. 20% 4.3. Drop Tail Router Queue Length Routers should be configured to use Drop Trail queues in the experiments due to their (still) prevalent nature. Experimentation with AQM schemes is encouraged but not mandatory. The router queue length is measured as the time taken to drain the FIFO queue. It has been noted in various discussions that the queue length in the current deployed Internet varies significantly. While the core backbone network has very short queue length, the home gateways usually have larger queue length. Those various queue lengths can be categorized in the following way: 1. QoS-aware (or short): 70ms 2. Nominal: 300-500ms 3. Buffer-bloated: 1000-2000ms Here the size of the queue is measured in bytes or packets and to convert the queue length measured in seconds to queue length in bytes: QueueSize (in bytes) = QueueSize (in sec) x Throughput (in bps)/8 4.4. Loss generation model Many models for generating packet loss are available, some yield correlated, others independent losses; losses can also be extracted from packet traces. As a (simple) minimum loss model with minimal parameterization (i.e., the loss rate), independent random losses must be used in the evaluation. It is known that independent loss models may reflect reality poorly and hence more sophisticated loss models could be considered. Suitable models for correlated losses includes the Gilbert-Elliot model [gilbert-elliott] and losses generated by modeling a queue including its (different) drop behaviors. 4.5. Jitter models This section defines jitter models for the purposes of this document. When jitter is to be applied to both the congestion controlled RTP flow and any competing flow (such as a TCP competing flow), the Singh, et al. Expires September 20, 2020 [Page 7] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 competing flow will use the jitter definition below that does not allow for re-ordering of packets on the competing flow (see NR-RBPDV definition below). Jitter is an overloaded term in communications. It is typically used to refer to the variation of a metric (e.g., delay) with respect to some reference metric (e.g., average delay or minimum delay). For example, RFC 3550 jitter is computed as the smoothed difference in packet arrival times relative to their respective expected arrival times, which is particularly meaningful if the underlying packet delay variation was caused by a Gaussian random process. Because jitter is an overloaded term, we use the term Packet Delay Variation (PDV) instead to describe the variation of delay of individual packets in the same sense as the IETF IPPM WG has defined PDV in their documents (e.g., RFC 3393) and as the ITU-T SG16 has defined IP Packet Delay Variation (IPDV) in their documents (e.g., Y.1540). Most PDV distributions in packet network systems are one-sided distributions, the measurement of which with a finite number of measurement samples results in one-sided histograms. In the usual packet network transport case, there is typically one packet that transited the network with the minimum delay; a (large) number of packets transit the network within some (smaller) positive variation from this minimum delay, and a (small) number of the packets transit the network with delays higher than the median or average transit time (these are outliers). Although infrequent, outliers can cause significant deleterious operation in adaptive systems and should be considered in rate adaptation designs for RTP congestion control. In this section we define two different bounded PDV characteristics, 1) Random Bounded PDV and 2) Approximately Random Subject to No- Reordering Bounded PDV. The former, 1) Random Bounded PDV is presented for information only, while the latter, 2) Approximately Random Subject to No-Reordering Bounded PDV, must be used in the evaluation. 4.5.1. Random Bounded PDV (RBPDV) The RBPDV probability distribution function (PDF) is specified to be of some mathematically describable function which includes some practical minimum and maximum discrete values suitable for testing. For example, the minimum value, x_min, might be specified as the minimum transit time packet and the maximum value, x_max, might be defined to be two standard deviations higher than the mean. Singh, et al. Expires September 20, 2020 [Page 8] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 Since we are typically interested in the distribution relative to the mean delay packet, we define the zero mean PDV sample, z(n), to be z(n) = x(n) - x_mean, where x(n) is a sample of the RBPDV random variable x and x_mean is the mean of x. We assume here that s(n) is the original source time of packet n and the post-jitter induced emission time, j(n), for packet n is: j(n) = {[z(n) + x_mean] + s(n)}. It follows that the separation in the post-jitter time of packets n and n+1 is {[s(n+1)-s(n)] - [z(n)-z(n+1)]}. Since the first term is always a positive quantity, we note that packet reordering at the receiver is possible whenever the second term is greater than the first. Said another way, whenever the difference in possible zero mean PDV sample delays (i.e., [x_max-x_min]) exceeds the inter- departure time of any two sent packets, we have the possibility of packet re-ordering. There are important use cases in real networks where packets can become re-ordered such as in load balancing topologies and during route changes. However, for the vast majority of cases there is no packet re-ordering because most of the time packets follow the same path. Due to this, if a packet becomes overly delayed, the packets after it on that flow are also delayed. This is especially true for mobile wireless links where there are per-flow queues prior to base station scheduling. Owing to this important use case, we define another PDV profile similar to the above, but one that does not allow for re-ordering within a flow. 4.5.2. Approximately Random Subject to No-Reordering Bounded PDV (NR- RPVD) No Reordering RPDV, NR-RPVD, is defined similarly to the above with one important exception. Let serial(n) be defined as the serialization delay of packet n at the lowest bottleneck link rate (or other appropriate rate) in a given test. Then we produce all the post-jitter values for j(n) for n = 1, 2, ... N, where N is the length of the source sequence s to be offset-ed. The exception can be stated as follows: We revisit all j(n) beginning from index n=2, and if j(n) is determined to be less than [j(n-1)+serial(n-1)], we redefine j(n) to be equal to [j(n-1)+serial(n-1)] and continue for all remaining n (i.e., n = 3, 4, .. N). This models the case where the packet n is sent immediately after packet (n-1) at the bottleneck link rate. Although this is generally the theoretical minimum in that it assumes that no other packets from other flows are in-between packet n and n+1 at the bottleneck link, it is a reasonable assumption for per flow queuing. Singh, et al. Expires September 20, 2020 [Page 9] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 We note that this assumption holds for some important exception cases, such as packets immediately following outliers. There are a multitude of software controlled elements common on end-to-end Internet paths (such as firewalls, ALGs and other middleboxes) which stop processing packets while servicing other functions (e.g., garbage collection). Often these devices do not drop packets, but rather queue them for later processing and cause many of the outliers. Thus NR-RPVD models this particular use case (assuming serial(n+1) is defined appropriately for the device causing the outlier) and thus is believed to be important for adaptation development for congestion controlled RTP streams. 4.5.3. Recommended distribution Whether Random Bounded PDV or Approximately Random Subject to No- Reordering Bounded PDV, it is recommended that z(n) is distributed according to a truncated Gaussian for the above jitter models: z(n) ~ |max(min(N(0, std^2), N_STD * std), -N_STD * std)| where N(0, std^2) is the Gaussian distribution with zero mean and standard deviation std. Recommended values: o std = 5 ms o N_STD = 3 5. Traffic Models 5.1. TCP traffic model Long-lived TCP flows will download data throughout the session and are expected to have infinite amount of data to send or receive. This roughly applies, for example, when downloading software distributions. Each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. Not all short TCP flows start at the same time, i.e., some start in the ON state while others start in the OFF state. The short TCP flows can be modeled as follows: 30 connections start simultaneously fetching small (30-50 KB) amounts of data, evenly distributed. This covers the case where the short TCP flows are fetching web page resources rather than video files. Singh, et al. Expires September 20, 2020 [Page 10] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 The idle period between bursts of starting a group of TCP flows is typically derived from an exponential distribution with the mean value of 10 seconds. [These values were picked based on the data available at http://httparchive.org/interesting.php as of October 2015]. Many different TCP congestion control schemes are deployed today. Therefore, experimentation with a range of different schemes, especially including CUBIC, is encouraged. Experiments must document in detail which congestion control schemes they tested against and which parameters were used. 5.2. RTP Video model [RFC8593] describes two types of video traffic models for evaluating candidate algorithms for RTP congestion control. The first model statistically characterizes the behavior of a video encoder, whereas the second model uses video traces. Sample video test sequences are available at [xiph-seq]. The following two video streams are the recommended minimum for testing: Foreman (CIF sequence) and FourPeople (720p); both come as raw video data to be encoded dynamically. As these video sequences are short (300 and 600 frames, respectively, they shall be stitched together repeatedly until the desired length is reached. 5.3. Background UDP Background UDP flow is modeled as a constant bit rate (CBR) flow. It will download data at a particular CBR rate for the complete session, or will change to particular CBR rate at predefined intervals. The inter packet interval is calculated based on the CBR and the packet size (is typically set to the path MTU size, the default value can be 1500 bytes). Note that new transport protocols such as QUIC may use UDP but, due to their congestion control algorithms, will exhibit behavior conceptually similar in nature to TCP flows above and can thus be subsumed by the above, including the division into short- and long- lived flows. As QUIC evolves independently of TCP congestion control algorithms, its future congestion control should be considered as competing traffic as appropriate. Singh, et al. Expires September 20, 2020 [Page 11] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 6. Security Considerations This document specifies evaluation criteria and parameters for assessing and comparing the performance of congestion control protocols and algorithms for real-time communication. This memo itself is thus not subject to security considerations but the protocols and algorithms evaluated may be. In particular, successful operation under all tests defined in this document may suffice for a comparative evaluation but must not be interpreted that the protocol is free of risks when deployed on the Internet as briefly described in the following by example. Such evaluations are expected to be carried out in controlled environments for limited numbers of parallel flows. As such, these evaluations are by definition limited and will not be able to systematically consider possible interactions or very large groups of communicating nodes under all possible circumstances, so that careful protocol design is advised to avoid incidentally contributing traffic that could lead to unstable networks, e.g., (local) congestion collapse. This specification focuses on assessing the regular operation of the protocols and algorithms under considerations. It does not suggest checks against malicious use of the protocols -- by the sender, the receiver, or intermediate parties, e.g., through faked, dropped, replicated, or modified congestion signals. It is up to the protocol specifications themselves to ensure that authenticity, integrity, and/or plausibility of received signals are checked and the appropriate actions (or non-actions) are taken. 7. IANA Considerations There are no IANA impacts in this memo. 8. Contributors The content and concepts within this document are a product of the discussion carried out in the Design Team. Michael Ramalho provided the text for the Jitter model. 9. Acknowledgments Much of this document is derived from previous work on congestion control at the IETF. The authors would like to thank Harald Alvestrand, Anna Brunstrom, Luca De Cicco, Wesley Eddy, Lars Eggert, Kevin Gross, Vinayak Hegde, Singh, et al. Expires September 20, 2020 [Page 12] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 Randell Jesup, Mirja Kuehlewind, Karen Nielsen, Piers O'Hanlon, Colin Perkins, Michael Ramalho, Zaheduzzaman Sarker, Timothy B. Terriberry, Michael Welzl, Mo Zanaty, and Xiaoqing Zhu for providing valuable feedback on earlier versions of this draft. Additionally, also thank the participants of the design team for their comments and discussion related to the evaluation criteria. 10. References 10.1. Normative References [I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", draft-ietf-rmcat-cc- requirements-09 (work in progress), December 2014. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, . Singh, et al. Expires September 20, 2020 [Page 13] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 [RFC8593] Zhu, X., Mena, S., and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", RFC 8593, DOI 10.17487/RFC8593, May 2019, . 10.2. Informative References [gilbert-elliott] Hasslinger, G. and O. Hohlfeld, "The Gilbert-Elliott Model for Packet Loss in Real Time Services on the Internet", 14th GI/ITG Conference - Measurement, Modelling and Evalutation of Computer and Communication Systems , 3 2008. [I-D.ietf-netvc-testing] Daede, T., Norkin, A., and I. Brailovskiy, "Video Codec Testing and Quality Measurement", draft-ietf-netvc- testing-09 (work in progress), January 2020. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- eval-test-10 (work in progress), May 2019. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Zhu, X., and J. Fu, "Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks", draft-ietf-rmcat-wireless-tests-11 (work in progress), March 2020. [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, . [RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion Control Mechanisms", RFC 5166, DOI 10.17487/RFC5166, March 2008, . [tcpdump] "Homepage of tcpdump and libpcap", https://www.tcpdump.org/index.html . [wireshark] "Homepage of Wireshark", https://www.wireshark.org . [xiph-seq] Daede, T., "Video Test Media Set", https://media.xiph.org/video/derf/ . Singh, et al. Expires September 20, 2020 [Page 14] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 Appendix A. Change Log Note to the RFC-Editor: please remove this section prior to publication as an RFC. A.1. Changes in draft-ietf-rmcat-eval-criteria-07 Updated the draft according to the discussion at IETF-101. o Updated the discussion on fairness. Thanks to Xiaoqing Zhu for providing text. o Fixed a simple loss model and provided pointers to more sophisticated ones. o Fixed the choice of the jitter model. A.2. Changes in draft-ietf-rmcat-eval-criteria-06 o Updated Jitter. A.3. Changes in draft-ietf-rmcat-eval-criteria-05 o Improved text surrounding wireless tests, video sequences, and short-TCP model. A.4. Changes in draft-ietf-rmcat-eval-criteria-04 o Removed the guidelines section, as most of the sections are now covered: wireless tests, video model, etc. o Improved Short TCP model based on the suggestion to use httparchive.org. A.5. Changes in draft-ietf-rmcat-eval-criteria-03 o Keep-alive version. o Moved link parameters and traffic models from eval-test A.6. Changes in draft-ietf-rmcat-eval-criteria-02 o Incorporated fairness test as a working test. o Updated text on mimimum evaluation requirements. Singh, et al. Expires September 20, 2020 [Page 15] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 A.7. Changes in draft-ietf-rmcat-eval-criteria-01 o Removed Appendix B. o Removed Section on Evaluation Parameters. A.8. Changes in draft-ietf-rmcat-eval-criteria-00 o Updated references. o Resubmitted as WG draft. A.9. Changes in draft-singh-rmcat-cc-eval-04 o Incorporate feedback from IETF 87, Berlin. o Clarified metrics: convergence time, bandwidth utilization. o Changed fairness criteria to fairness test. o Added measuring pre- and post-repair loss. o Added open issue of measuring video quality to appendix. o clarified use of DropTail and AQM. o Updated text in "Minimum Requirements for Evaluation" A.10. Changes in draft-singh-rmcat-cc-eval-03 o Incorporate the discussion within the design team. o Added a section on evaluation parameters, it describes the flow and network characteristics. o Added Appendix with self-fairness experiment. o Changed bottleneck parameters from a proposal to an example set. o A.11. Changes in draft-singh-rmcat-cc-eval-02 o Added scenario descriptions. Singh, et al. Expires September 20, 2020 [Page 16] Internet-Draft Evaluating Congestion Control for RMCAT March 2020 A.12. Changes in draft-singh-rmcat-cc-eval-01 o Removed QoE metrics. o Changed stability to steady-state. o Added measuring impact against few and many flows. o Added guideline for idle and data-limited periods. o Added reference to TCP evaluation suite in example evaluation scenarios. Authors' Addresses Varun Singh CALLSTATS I/O Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland Email: varun.singh@iki.fi URI: https://www.callstats.io/about Joerg Ott Technical University of Munich Faculty of Informatics Boltzmannstrasse 3 Garching bei Muenchen, DE 85748 Germany Email: ott@in.tum.de Stefan Holmer Google Kungsbron 2 Stockholm 11122 Sweden Email: holmer@google.com Singh, et al. Expires September 20, 2020 [Page 17] ./draft-ietf-rmcat-eval-test-10.txt0000644000764400076440000020615613471550563016404 0ustar iustyiusty Network Working Group Z. Sarker Internet-Draft Ericsson AB Intended status: Informational V. Singh Expires: November 24, 2019 callstats.io X. Zhu M. Ramalho Cisco Systems May 23, 2019 Test Cases for Evaluating RMCAT Proposals draft-ietf-rmcat-eval-test-10 Abstract The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 24, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Sarker, et al. Expires November 24, 2019 [Page 1] Internet-Draft Test Scenarios for RMCAT May 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Structure of Test cases . . . . . . . . . . . . . . . . . . . 3 4. Recommended Evaluation Settings . . . . . . . . . . . . . . . 8 4.1. Evaluation metrics . . . . . . . . . . . . . . . . . . . 8 4.2. Path characteristics . . . . . . . . . . . . . . . . . . 8 4.3. Media source . . . . . . . . . . . . . . . . . . . . . . 9 5. Basic Test Cases . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Variable Available Capacity with a Single Flow . . . . . 10 5.2. Variable Available Capacity with Multiple Flows . . . . . 13 5.3. Congested Feedback Link with Bi-directional Media Flows . 14 5.4. Competing Media Flows with same Congestion Control Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. Round Trip Time Fairness . . . . . . . . . . . . . . . . 19 5.6. Media Flow Competing with a Long TCP Flow . . . . . . . . 21 5.7. Media Flow Competing with Short TCP Flows . . . . . . . . 23 5.8. Media Pause and Resume . . . . . . . . . . . . . . . . . 25 6. Other potential test cases . . . . . . . . . . . . . . . . . 27 6.1. Media Flows with Priority . . . . . . . . . . . . . . . . 27 6.2. Explicit Congestion Notification Usage . . . . . . . . . 27 6.3. Multiple Bottlenecks . . . . . . . . . . . . . . . . . . 28 7. Wireless Access Links . . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction This memo describes a set of test cases for evaluating congestion control algorithm proposals in controlled environments for real-time interactive media. It is based on the guidelines enumerated in [I-D.ietf-rmcat-eval-criteria] and the requirements discussed in [I-D.ietf-rmcat-cc-requirements]. The test cases cover basic usage scenarios and are described using a common structure, which allows for additional test cases to be added to those described herein to accommodate other topologies and/or the modelling of different path characteristics. The described test cases in this memo should be Sarker, et al. Expires November 24, 2019 [Page 2] Internet-Draft Test Scenarios for RMCAT May 2019 used to evaluate any proposed congestion control algorithm for real- time interactive media. 2. Terminology The terminology defined in RTP [RFC3550], RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], RTCP Extended Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) [RFC4585], and Support for Reduced-Size RTCP [RFC5506] apply. 3. Structure of Test cases All the test cases in this document follow a basic structure allowing implementers to describe a new test scenario without repeatedly explaining common attributes. The structure includes a general description section that describes the test case and its motivation. Additionally the test case defines a set of attributes that characterize the testbed, for example, the network path between communicating peers and the diverse traffic sources. o Define the test case: * General description: describes the motivation and the goals of the test case. * Expected behavior: describes the desired rate adaptation behavior. * Define a list of metrics to evaluate the desired behavior: this indicates the minimum set of metrics (e.g., link utilization, media sending rate) that a proposed algorithm needs to measure to validate the expected rate adaptation behavior. It should also indicate the time granularity (e.g., averaged over 10ms, 100ms, or 1s) for measuring certain metrics. Typical measurement interval is 200ms. o Define testbed topology: every test case needs to define an evaluation testbed topology. Figure 1 shows such an evaluation topology. In this evaluation topology, S1..Sn are traffic sources. These sources generate media traffic and use the congestion control algorithm(s) under investigation. R1..Rn are the corresponding receivers. A test case can have one or more such traffic sources (S) and their corresponding receivers (R). The path from the source to destination is denoted as "forward" and the path from a destination to a source is denoted as "backward". The following basic structure of the test case has been described from the perspective of media generating endpoints Sarker, et al. Expires November 24, 2019 [Page 3] Internet-Draft Test Scenarios for RMCAT May 2019 attached on the left-hand side of Figure 1. In this setup, the media flows are transported in forward direction and corresponding feedback/control messages are transported in the backward direction. However, it is also possible to set up the test with media in both forward and backward directions. In that case, unless otherwise specified by the test case, it is expected that the backward path does not introduce any congestion related impairments and has enough capacity to accommodate both media and feedback/control messages. It should be noted that depending on the test cases it is possible to have different path characteristics in either of the directions. +---+ +---+ |S1 |====== \ Forward --> / =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A |------------------------------>| B |=======|R2 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ (...) // \\ (...) // <-- Backward \\ +---+ // \\ +---+ |Sn |====== / \ ======|Rn | +---+ +---+ Figure 1: Example of A Testbed Topology In a testbed environment with real equipments, there may exist a significant amount of unwanted traffic on the portions of the network path between the endpoints. Some of this traffic may be generated by other processes on the endpoints themselves (e.g., discovery protocols) or by other endpoints not presently under test. Such unwanted traffic should be removed or avoided to the greatest extent possible. o Define testbed attributes: * Duration: defines the duration of the test in seconds. * Path characteristics: defines the end-to-end transport level path characteristics of the testbed for a particular test case. Two sets of attributes describe the path characteristics, one for the forward path and the other for the backward path. The path characteristics for a particular path direction is applicable to all the Sources "S" sending traffic on that path. If only one attribute is specified, it is used for both path Sarker, et al. Expires November 24, 2019 [Page 4] Internet-Draft Test Scenarios for RMCAT May 2019 directions, however, unless specified the reverse path has no capacity restrictions and no path loss. + Path direction: forward or backward. + Minimum bottleneck-link capacity: defines minimum capacity of the end-to-end path + Reference bottleneck capacity: defines a reference value for the bottleneck capacity for test cases with time-varying bottleneck capacities. All bottleneck capacities will be specified as a ratio with respect to the reference capacity value. + One-way propagation delay: describes the end-to-end latency along the path when network queues are empty, i.e., the time it takes for a packet to go from the sender to the receiver without encountering any queuing delay. + Maximum end-to-end jitter: defines the maximum jitter that can be observed along the path. + Bottleneck queue type: for example, "tail drop" [RFC7567], Flow Queue -CoDel (FQ-CoDel)[RFC8290], or Proportional Integral controller Enhanced (PIE)[RFC8033]. + Bottleneck queue size: defines the size of queue in terms of queuing time when the queue is full (in milliseconds). + Path loss ratio: characterizes the non-congested, additive, losses to be generated on the end-to-end path. This must describe the loss pattern or loss model used to generate the losses. * Application-related: defines the traffic source behavior for implementing the test case + Media traffic Source: defines the characteristics of the media sources. When using more than one media source, the different attributes are enumerated separately for each different media source. - Media type: Video/Voice - Media flow direction: forward, backward or both. - Number of media sources: defines the total number of media sources Sarker, et al. Expires November 24, 2019 [Page 5] Internet-Draft Test Scenarios for RMCAT May 2019 - Media codec: Constant Bit Rate (CBR) or Variable Bit Rate (VBR) - Media source behavior: describes the media encoder behavior. It defines the main parameters that affect the adaptation behavior. This may include but is not limited to: o Adaptability: describes the adaptation options. For example, in the case of video it defines the following ranges of adaptation: bit rate, frame rate, video resolution. Similarly, in the case of voice, it defines the range of bit rate adaptation, the sampling rate variation, and the variation in packetization interval. o Output variation : for a VBR encoder it defines the encoder output variation from the average target rate over a particular measurement interval. For example, on average the encoder output may vary between 5% to 15% above or below the average target bit rate when measured over a 100 ms time window. The time interval over which the variation is specified must be provided. o Responsiveness to a new bit rate request: the lag in time between a new bit rate request from the congestion control algorithm and actual rate changes in encoder output. Depending on the encoder, this value may be specified in absolute time (e.g. 10ms to 1000ms) or other appropriate metric (e.g. next frame interval time). More detailed discussions on expected media source behavior, including those from synthetic video traffic sources, is at [I-D.ietf-rmcat-video-traffic-model]. - Media content: describes the chosen video scenario. For example, video test sequences are available at: [xiph-seq] and [HEVC-seq]. Different video scenarios give different distribution of video frames produced by the video encoder. Hence, it is important to specify the media content used in a particular test. If a synthetic video traffic souce [I-D.ietf-rmcat-video-traffic-model] is used, then the synthetic video traffic source needs to configure according to the characteristics of the media content specified. Sarker, et al. Expires November 24, 2019 [Page 6] Internet-Draft Test Scenarios for RMCAT May 2019 - Media timeline: describes the point when the media source is introduced and removed from the testbed. For example, the media source may start transmitting immediately when the test case begins, or after a few seconds. - Startup behavior: the media starts at a defined bit rate, which may be the minimum, maximum bit rate, or a value in between (in Kbps). + Competing traffic source: describes the characteristics of the competing traffic source, the different types of competing flows are enumerated in [I-D.ietf-rmcat-eval-criteria]. - Traffic direction: forward, backward or both. - Type of sources: defines the types of competing traffic sources. Types of competing traffic flows are listed in [I-D.ietf-rmcat-eval-criteria]. For example, the number of TCP flows connected to a web browser, the mean size and distribution of the content downloaded. - Number of sources: defines the total number of competing sources of each media type per traffic direction. - Congestion control: enumerates the congestion control used by each type of competing traffic. - Traffic timeline: describes when the competing traffic starts and ends in the test case. * Additional attributes: describes attributes essential for implementing a test case which are not included in the above structure. These attributes must be well defined, so that the other implementers of that particular test case are able to implement it easily. Any attribute can have a set of values (enclosed within "[]"). Each member value of such a set must be treated as different value for the same attribute. It is desired to run separate tests for each such attribute value. The test cases described in this document follow the above structure. Sarker, et al. Expires November 24, 2019 [Page 7] Internet-Draft Test Scenarios for RMCAT May 2019 4. Recommended Evaluation Settings This section describes recommended test case settings and could be overwritten by the respective test cases. 4.1. Evaluation metrics To evaluate the performance of the candidate algorithms the implementers must log enough information to visualize the following metrics at a fine enough time granularity: 1. Flow level: A. End-to-end delay for the congestion controlled media flow(s). For example - end-to-end delay observed on IP packet level, video frame level. B. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations. C. Packet losses observed at the receiving endpoint. D. Feedback message overhead. E. Convergence time - time to reach steady state for the congestion controlled media flow(s). Each occurrence of convergence during the test period need to be presented. 2. Transport level: A. Bandwidth utilization. B. Queue length (milliseconds at specified path capacity). 4.2. Path characteristics Each path between a sender and receiver as described in Figure 1 have the following characteristics unless otherwise specified in the test case. o Path direction: forward and backward. o Reference bottleneck capacity: 1Mbps. o One-Way propagation delay: 50ms. Implementers are encouraged to run the experiment with additional propagation delays mentioned in [I-D.ietf-rmcat-eval-criteria] Sarker, et al. Expires November 24, 2019 [Page 8] Internet-Draft Test Scenarios for RMCAT May 2019 o Maximum end-to-end jitter: 30ms. Jitter models are described in [I-D.ietf-rmcat-eval-criteria] o Bottleneck queue type: "tail drop". Implementers are encouraged to run the experiment with other AQM schemes, such as FQ-CoDel and PIE. o Bottleneck queue size: 300ms. o Path loss ratio: 0%. Examples of additional network parameters are discussed in [I-D.ietf-rmcat-eval-criteria]. For test cases involving time-varying bottleneck capacity, all capacity values are specified as a ratio with respect to a reference capacity value, so as to allow flexible scaling of capacity values along with media source rate range. There exist two different mechanisms for inducing path capacity variation: a) by explicitly modifying the value of physical link capacity; or b) by introducing background non-adaptive UDP traffic with time-varying traffic rate. Implementers are encouraged to run the experiments with both mechanisms for test cases specified in Section 5.1, Section 5.2, and Section 5.3. 4.3. Media source Unless otherwise specified, each test case will include one or more media sources as described below. o Media type: Video * Media codec: VBR * Media source behavior: + Adaptability: - Bit rate range: 150 Kbps - 1.5 Mbps. In real-life applications the bit rate range can vary a lot depending on the provided service, for example, the maximum bit rate can be up to 4Mbps. However, for running tests to evaluate the congestion control algorithms it is more important to have a look at how they are reacting to certain amount of bandwidth change. Also it is possible that the media traffic generator used in a particular simulator or testbed is not capable of generating higher bit rate. Hence we have selected a suitable bit rate Sarker, et al. Expires November 24, 2019 [Page 9] Internet-Draft Test Scenarios for RMCAT May 2019 range typical of consumer-grade video conferencing applications in designing the test case. If a different bit rate range is used in the test cases, then the end- to-end path capacity values will also need to be scaled accordingly. - Frame resolution: 144p - 720p (or 1080p). This resolution range is selected based on the bit rate range. If a different bit rate range is used in the test cases then the frame resolution range also need to be selected suitably. - Frame rate: 10fps - 30fps. This frame rate range is selected based on the bit rate range. If a different bit rate range is used in the test cases then the frame rate range also need to be adjusted suitably. + Variation from target bit rate: +/-5%. Unless otherwise specified in the test case(s), bit rate variation should be calculated over one (1) second period of time. + Responsiveness to new bit rate request: 100ms * Media content: The media content should represent a typical video conversational scenario with head and shoulder movement. We recommend to use Foreman video sequence[xiph-seq]. * Media startup behavior: 150Kbps. It should be noted that applications can use smart ways to select an optimal startup bit rate value for a certain network condition. In such cases the candidate proposals may show the effectiveness of such smart approach as an additional information for the evaluation process. o Media type: Audio * Media codec: CBR * Media bit rate: 20Kbps 5. Basic Test Cases 5.1. Variable Available Capacity with a Single Flow In this test case the minimum bottleneck-link capacity between the two endpoints varies over time. This test is designed to measure the responsiveness of the candidate algorithm. This test tries to address the requirements in [I-D.ietf-rmcat-cc-requirements], which Sarker, et al. Expires November 24, 2019 [Page 10] Internet-Draft Test Scenarios for RMCAT May 2019 requires the algorithm to adapt the flow(s) and provide lower end-to- end latency when there exists: o an intermediate bottleneck o change in available capacity (e.g., due to interface change, routing change, abrupt arrival/departure of background non- adaptive traffic). o maximum media bit rate is greater than link capacity. In this case, when the application tries to ramp up to its maximum bit rate, since the link capacity is limited to a value lower, the congestion control scheme is expected to stabilize the sending bit rate close to the available bottleneck capacity. It should be noted that the exact variation in available capacity due to any of the above depends on the underlying technologies. Hence, we describe a set of known factors, which may be extended to devise a more specific test case targeting certain behaviors in a certain network environment. Expected behavior: the candidate algorithm is expected to detect the path capacity constraint, converge to the bottleneck link's capacity and adapt the flow to avoid unwanted media rate oscillation when the sending bit rate is approaching the bottleneck link's capacity. Such oscillations might occur when the media flow(s) attempts to reach its maximum bit rate but overshoots the usage of the available bottleneck capacity then to rectify, it reduces the bit rate and starts to ramp up again. Evaluation metrics : as described in Section 4.1. Testbed topology: One media source S1 is connected to the corresponding R1. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Forward --> +---+ +-----+ +-----+ +---+ |S1 |=======| A |------------------------------>| B |=======|R1 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ <-- Backward Figure 2: Testbed Topology for Limited Link Capacity Testbed attributes: Sarker, et al. Expires November 24, 2019 [Page 11] Internet-Draft Test Scenarios for RMCAT May 2019 o Test duration: 100s o Path characteristics: as described in Section 4.2 o Application-related: * Media Traffic: + Media type: Video - Media direction: forward. - Number of media sources: one (1) - Media timeline: o Start time: 0s. o End time: 99s. + Media type: Audio - Media direction: forward. - Number of media sources: one (1) - Media timeline: o Start time: 0s. o End time: 99s. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: * One-way propagation delay: [ 50 ms, 100 ms]. on the forward path direction * This test uses bottleneck path capacity variation as listed in Table 1 * When using background non-adaptive UDP traffic to induce time- varying bottleneck , the physical path capacity remains at 4Mbps and the UDP traffic source rate changes over time as (4 - Sarker, et al. Expires November 24, 2019 [Page 12] Internet-Draft Test Scenarios for RMCAT May 2019 (Y x r)), where r is the Reference bottleneck capacity in Mbps and Y is the path capacity ratio specified in Table 1 +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Forward | 0s | 1.0 | | Two | Forward | 40s | 2.5 | | Three | Forward | 60s | 0.6 | | Four | Forward | 80s | 1.0 | +--------------------+--------------+-----------+-------------------+ Table 1: Path capacity variation pattern for forward direction 5.2. Variable Available Capacity with Multiple Flows This test case is similar to Section 5.1. However in addition this test will also consider persistent network load due to competing traffic. Expected behavior: the candidate algorithm is expected to detect the variation in available capacity and adapt the media stream(s) accordingly. The flows stabilize around their maximum bit rate as the maximum link capacity is large enough to accommodate the flows. When the available capacity drops, the flows adapt by decreasing their sending bit rate, and when congestion disappears, the flows are again expected to ramp up. Evaluation metrics : as described in Section 4.1. Testbed Topology: Two (2) media sources S1 and S2 are connected to their corresponding destinations R1 and R2. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Sarker, et al. Expires November 24, 2019 [Page 13] Internet-Draft Test Scenarios for RMCAT May 2019 +---+ +---+ |S1 |===== \ / =======|R1 | +---+ \\ Forward --> // +---+ \\ // +-----+ +-----+ | A |------------------------------>| B | | |<------------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +---+ // \\ +---+ |S2 |====== / \ ======|R2 | +---+ +---+ Figure 3: Testbed Topology for Variable Available Capacity Testbed attributes: Testbed attributes are similar as described in Section 5.1 except the test specific capacity variation setup. Test Specific Information: This test uses path capacity variation as listed in Table 2 with a corresponding end time of 125 seconds. The reference bottleneck capacity is 2Mbps. When using background non- adaptive UDP traffic to induce time-varying bottleneck for congestion controlled media flows, the physical path capacity is 4Mbps and the UDP traffic source rate changes over time as (4 - (Y x r)), where r is the Reference bottleneck capacity in Mbps and Y is the path capacity ratio specified in Table 2. +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Forward | 0s | 2.0 | | Two | Forward | 25s | 1.0 | | Three | Forward | 50s | 1.75 | | Four | Forward | 75s | 0.5 | | Five | Forward | 100s | 1.0 | +--------------------+--------------+-----------+-------------------+ Table 2: Path capacity variation pattern for forward direction 5.3. Congested Feedback Link with Bi-directional Media Flows Real-time interactive media uses RTP hence it is assumed that RTCP, RTP header extension or such would be used by the congestion control algorithm in the backchannel. Due to the asymmetric nature of the Sarker, et al. Expires November 24, 2019 [Page 14] Internet-Draft Test Scenarios for RMCAT May 2019 link between communicating peers it is possible for a participating peer to not receive such feedback information due to an impaired or congested backchannel (even when the forward channel might not be impaired). This test case is designed to observe the candidate congestion control behavior in such an event. Expected behavior: It is expected that the candidate algorithms are able to cope with the lack of feedback information and adapt to minimize the performance degradation of media flows in the forward channel. It should be noted that for this test case: logs are compared with the reference case, i.e, when the backward channel has no impairments. Evaluation metrics : as described in Section 4.1. Testbed topology: One (1) media source S1 is connected to corresponding R1, but both endpoints are additionally receiving and sending data, respectively. The media traffic (S1->R1) is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Likewise media traffic (S2->R2) is transported over the backward path and corresponding feedback/control traffic is transported over the forward path. +---+ +---+ |S1 |===== \ Forward --> / =======|R1 | +---+ \\ // +---+ \\ // +-----+ +-----+ | A |------------------------------>| B | | |<------------------------------| | +-----+ +-----+ // \\ // <-- Backward \\ +---+ // \\ +---+ |R2 |===== / \ ======|S2 | +---+ +---+ Figure 4: Testbed Topology for Congested Feedback Link Testbed attributes: o Test duration: 100s o Path characteristics: Sarker, et al. Expires November 24, 2019 [Page 15] Internet-Draft Test Scenarios for RMCAT May 2019 * Reference bottleneck capacity: 1Mbps. o Application-related: * Media Source: + Media type: Video - Media direction: forward and backward - Number of media sources: two (2) - Media timeline: o Start time: 0s. o End time: 99s. + Media type: Audio - Media direction: forward and backward - Number of media sources: two (2) - Media timeline: o Start time: 0s. o End time: 99s. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: this test uses path capacity variations to create congested feedback link. Table 3 lists the variation patterns applied to the forward path and Table 4 lists the variation patterns applied to the backward path. When using background non-adaptive UDP traffic to induce time-varying bottleneck for congestion controlled media flows, the physical path capacity is 4Mbps for both directions and the UDP traffic source rate changes over time as (4-x)Mbps in each direction, where x is the bottleneck capacity specified in Table 4. Sarker, et al. Expires November 24, 2019 [Page 16] Internet-Draft Test Scenarios for RMCAT May 2019 +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Forward | 0s | 2.0 | | Two | Forward | 20s | 1.0 | | Three | Forward | 40s | 0.5 | | Four | Forward | 60s | 2.0 | +--------------------+--------------+-----------+-------------------+ Table 3: Path capacity variation pattern for forward direction +--------------------+--------------+-----------+-------------------+ | Variation pattern | Path | Start | Path capacity | | index | direction | time | ratio | +--------------------+--------------+-----------+-------------------+ | One | Backward | 0s | 2.0 | | Two | Backward | 35s | 0.8 | | Three | Backward | 70s | 2.0 | +--------------------+--------------+-----------+-------------------+ Table 4: Path capacity variation pattern for backward direction 5.4. Competing Media Flows with same Congestion Control Algorithm In this test case, more than one media flow share the bottleneck link and each of them uses the same congestion control algorithm. This is a typical scenario where a real-time interactive application sends more than one media flow to the same destination and these flows are multiplexed over the same port. In such a scenario it is likely that the flows will be routed via the same path and need to share the available bandwidth amongst themselves. For the sake of simplicity it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows individually. While this appears to be a variant of the test case defined in Section 5.2, it focuses on the capacity sharing aspect of the candidate algorithm. The previous test case, on the other hand, measures adaptability, stability, and responsiveness of the candidate algorithm. Expected behavior: It is expected that the competing flows will converge to an optimum bit rate to accommodate all the flows with minimum possible latency and loss. Specifically, the test introduces three media flows at different time instances, when the second flow appears there should still be room to accommodate another flow on the bottleneck link. Lastly, when the third flow appears the bottleneck link should be saturated. Sarker, et al. Expires November 24, 2019 [Page 17] Internet-Draft Test Scenarios for RMCAT May 2019 Evaluation metrics : as described in Section 4.1. Testbed topology: Three media sources S1, S2, S3 are connected to R1, R2, R3 respectively. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. +---+ +---+ |S1 |===== \ Forward --> / =======|R1 | +---+ \\ // +---+ \\ // +---+ +-----+ +-----+ +---+ |S2 |=======| A |------------------------------>| B |=======|R2 | +---+ | |<------------------------------| | +---+ +-----+ +-----+ // <-- Backward \\ +---+ // \\ +---+ |S3 |===== / \ ======|R3 | +---+ +---+ Figure 5: Testbed Topology for Multiple congestion controlled media Flows Testbed attributes: o Test duration: 120s o Path characteristics: * Reference bottleneck capacity: 3.5Mbps * Path capacity ratio: 1.0 o Application-related: * Media Source: + Media type: Video - Media direction: forward. - Number of media sources: three (3) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. + Media type: Audio Sarker, et al. Expires November 24, 2019 [Page 18] Internet-Draft Test Scenarios for RMCAT May 2019 - Media direction: forward. - Number of media sources: three (3) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: Table 5 defines the media timeline for both media type. +---------+------------+------------+----------+ | Flow ID | Media type | Start time | End time | +---------+------------+------------+----------+ | 1 | Video | 0s | 119s | | 2 | Video | 20s | 119s | | 3 | Video | 40s | 119s | | 4 | Audio | 0s | 119s | | 5 | Audio | 20s | 119s | | 6 | Audio | 40s | 119s | +---------+------------+------------+----------+ Table 5: Media Timeline for Video and Audio media sources 5.5. Round Trip Time Fairness In this test case, multiple media flows share the bottleneck link, but the one-way propagation delay for each flow is different. For the sake of simplicity it is assumed that there are no other competing traffic sources in the bottleneck link and that there is sufficient capacity to accommodate all the flows. While this appears to be a variant of test case 5.2, it focuses on the capacity sharing aspect of the candidate algorithm under different RTTs. Expected behavior: It is expected that the competing flows will converge to bit rates to accommodate all the flows with minimum possible latency and loss. The effectiveness of the algorithm depends on how fast and fairly the competing flows converge to their steady states irrespective of the RTT observed. Evaluation metrics : as described in Section 4.1. Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected to their corresponding media sinks R1,R2,..,R5. The media traffic is transported over the forward path and corresponding feedback/control Sarker, et al. Expires November 24, 2019 [Page 19] Internet-Draft Test Scenarios for RMCAT May 2019 traffic is transported over the backward path. The topology is the same as in Section 5.4. Testbed attributes: o Test duration: 300s o Path characteristics: * Reference bottleneck capacity: 4Mbps * Path capacity ratio: 1.0 * One-Way propagation delay for each flow: 10ms for S1-R1, 25ms for S2-R2, 50ms for S3-R3, 100ms for S4-R4, and 150ms S5-R5. o Application-related: * Media Source: + Media type: Video - Media direction: forward - Number of media sources: five (5) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. + Media type: Audio - Media direction: forward. - Number of media sources: five (5) - Media timeline: new media flows are added sequentially, at short time intervals. See test specific setup below. * Competing traffic: + Number of sources : zero (0) o Test Specific Information: Table 6 defines the media timeline for both media type. Sarker, et al. Expires November 24, 2019 [Page 20] Internet-Draft Test Scenarios for RMCAT May 2019 +---------+------------+------------+----------+ | Flow IF | Media type | Start time | End time | +---------+------------+------------+----------+ | 1 | Video | 0s | 299s | | 2 | Video | 10s | 299s | | 3 | Video | 20s | 299s | | 4 | Video | 30s | 299s | | 5 | Video | 40s | 299s | | 6 | Audio | 0 | 299s | | 7 | Audio | 10s | 299s | | 8 | Audio | 20s | 299s | | 9 | Audio | 30s | 299s | | 10 | Audio | 40s | 299s | +---------+------------+------------+----------+ Table 6: Media Timeline for Video and Audio media sources 5.6. Media Flow Competing with a Long TCP Flow In this test case, one or more media flows share the bottleneck link with at least one long lived TCP flow. Long lived TCP flows download data throughout the session and are expected to have infinite amount of data to send and receive. This is a scenario where a multimedia application co-exists with a large file download. The test case measures the adaptivity of the candidate algorithm to competing traffic. It addresses the requirement 3 in [I-D.ietf-rmcat-cc-requirements]. Expected behavior: depending on the convergence observed in test case 5.1 and 5.2, the candidate algorithm may be able to avoid congestion collapse. In the worst case, the media stream will fall to the minimum media bit rate. Evaluation metrics : following metrics in addition to as described in Section 4.1. 1. Flow level: A. TCP throughput. B. Loss for the TCP flow Testbed topology: One (1) media source S1 is connected to the corresponding media sink, R1. In addition, there is a long-live TCP flow sharing the same bottleneck link. The media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. The TCP traffic goes Sarker, et al. Expires November 24, 2019 [Page 21] Internet-Draft Test Scenarios for RMCAT May 2019 over the forward path from, S_tcp with acknowledgment packets go over the backward path from, R_tcp. +--+ +--+ |S1|===== \ Forward --> / =====|R1| +--+ \\ // +--+ \\ // +-----+ +-----+ | A |---------------------------->| B | | |<----------------------------| | +-----+ +-----+ // <-- Backward \\ +-----+ // \\ +-----+ |S_tcp|=== / \ ===|R_tcp| +-----+ +-----+ Figure 6: Testbed Topology for TCP vs congestion controlled media Flows Testbed attributes: o Test duration: 120s o Path characteristics: * Reference bottleneck capacity: 2Mbps * Path capacity ratio: 1.0 * Bottleneck queue size: [300ms, 1000ms] o Application-related: * Media Source: + Media type: Video - Media direction: forward - Number of media sources: one (1) - Media timeline: o Start time: 5s. o End time: 119s. + Media type: Audio Sarker, et al. Expires November 24, 2019 [Page 22] Internet-Draft Test Scenarios for RMCAT May 2019 - Media direction: forward - Number of media sources: one (1) - Media timeline: o Start time: 5s. o End time: 119s. * Additionally, implementers are encouraged to run the experiment with multiple media sources. * Competing traffic: + Number and Types of sources : one (1) and long-lived TCP + Traffic direction : forward + Congestion control: default TCP congestion control[RFC5681]. Implementers are also encouraged to run the experiment with alternative TCP congestion control algorithm. + Traffic timeline: - Start time: 0s. - End time: 119s. o Test Specific Information: none 5.7. Media Flow Competing with Short TCP Flows In this test case, one or more congestion controlled media flow shares the bottleneck link with multiple short-lived TCP flows. Short-lived TCP flows resemble the on/off pattern observed in the web traffic, wherein clients (for example, browsers) connect to a server and download a resource (typically a web page, few images, text files, etc.) using several TCP connections. This scenario shows the performance of a multimedia application when several browser windows are active. The test case measures the adaptivity of the candidate algorithm to competing web traffic, it addresses the requirements 1.E in [I-D.ietf-rmcat-cc-requirements]. Depending on the number of short TCP flows, the cross-traffic either appears as a short burst flow or resembles a long TCP flow. The intention of this test is to observe the impact of short-term burst on the behavior of the candidate algorithm. Sarker, et al. Expires November 24, 2019 [Page 23] Internet-Draft Test Scenarios for RMCAT May 2019 Expected behavior: The candidate algorithm is expected to avoid flow starvation during the presence of short and bursty competing TCP flows, streaming at least at the minimum media bit rate. After competing TCP flows terminate, the media streams are expected to be robust enough to eventually recover to previous steady state behavior, and at the very least, avoid persistent starvation. Evaluation metrics : following metrics in addition to as described in Section 4.1. 1. Flow level: A. Variation in the sending rate of the TCP flow. B. TCP throughput. Testbed topology: The topology described here is same as the one described in Figure 6. Testbed attributes: o Test duration: 300s o Path characteristics: * Reference bottleneck capacity: 2.0Mbps * Path capacity ratio: 1.0 o Application-related: * Media source: + Media type: Video - Media direction: forward - Number of media sources: two (2) - Media timeline: o Start time: 5s. o End time: 299s. + Media type: Audio - Media direction: forward Sarker, et al. Expires November 24, 2019 [Page 24] Internet-Draft Test Scenarios for RMCAT May 2019 - Number of media sources: two (2) - Media timeline: o Start time: 5s. o End time: 299s. * Competing traffic: + Number and Types of sources : ten (10), short-lived TCP flows. + Traffic direction : forward + Congestion algorithm: default TCP Congestion control [RFC5681]. Implementers are also encouraged to run the experiment with alternative TCP congestion control algorithm. + Traffic timeline: each short TCP flow is modeled as a sequence of file downloads interleaved with idle periods. Not all short TCP flows start at the same time, 2 of them start in the ON state while rest of the 8 flows start in an OFF state. For description of short TCP flow model see test specific information below. o Test Specific Information: * Short-TCP traffic model: The short TCP model to be used in this test is described in [I-D.ietf-rmcat-eval-criteria]. 5.8. Media Pause and Resume In this test case, more than one real-time interactive media flows share the link bandwidth and all flows reach to a steady state by utilizing the link capacity in an optimum way. At this stage one of the media flows is paused for a moment. This event will result in more available bandwidth for the rest of the flows as they are on a shared link. When the paused media flow resumes it would no longer have the same bandwidth share on the link. It has to make its way through the other existing flows in the link to achieve a fair share of the link capacity. This test case is important specially for real-time interactive media which consists of more than one media flows and can pause/resume media flows at any point of time during the session. This test case directly addresses the requirement number 5 in [I-D.ietf-rmcat-cc-requirements]. One can think it as a variation of test case defined in Section 5.4. However, it is Sarker, et al. Expires November 24, 2019 [Page 25] Internet-Draft Test Scenarios for RMCAT May 2019 different as the candidate algorithms can use different strategies to increase its efficiency, for example in terms of fairness, convergence time, reduce oscillation etc, by capitalizing the fact that they have previous information of the link. Expected behavior: During the period where the third stream is paused, the two remaining flows are expected to increase their rates and reach the maximum media bit rate. When the third stream resumes, all three flows are expected to converge to the same original fair share of rates prior to the media pause/resume event. Evaluation metrics : following metrics in addition to as described in Section 4.1. 1. Flow level: A. Variation in sending bit rate and throughput. Mainly observing the frequency and magnitude of oscillations. Testbed Topology: Same as test case defined in Section 5.4 Testbed attributes: The general description of the testbed parameters are same as Section 5.4 with changes in the test specific setup as below- o Other test specific setup: * Media flow timeline: + Flow ID: one (1) + Start time: 0s + Flow duration: 119s + Pause time: not required + Resume time: not required * Media flow timeline: + Flow ID: two (2) + Start time: 0s + Flow duration: 119s + Pause time: at 40s Sarker, et al. Expires November 24, 2019 [Page 26] Internet-Draft Test Scenarios for RMCAT May 2019 + Resume time: at 60s * Media flow timeline: + Flow ID: three (3) + Start time: 0s + Flow duration:119s + Pause time: not required + Resume time: not required 6. Other potential test cases It has been noticed that there are other interesting test cases besides the basic test cases listed above. In many aspects, these additional test cases can help further evaluation of the candidate algorithm. They are listed as below. 6.1. Media Flows with Priority In this test case media flows will have different priority levels. This will be an extension of Section 5.4 where the same test will be run with different priority levels imposed on each of the media flows. For example, the first flow (S1) is assigned a priority of 2 whereas the remaining two flows (S2 and S3) are assigned a priority of 1. The candidate algorithm must reflect the relative priorities assigned to each media flow. In this case, the first flow (S1) must arrive at a steady-state rate approximately twice of that of the other two flows (S2 and S3). The candidate algorithm can use a coupled congestion control mechanism [I-D.ietf-rmcat-coupled-cc] or use a weighted priority scheduler for the bandwidth distribution according to the respective media flow priority or use. 6.2. Explicit Congestion Notification Usage This test case requires to run all the basic test cases with the availability of Explicit Congestion Notification (ECN) [RFC6679] feature enabled. The goal of this test is to exhibit that the candidate algorithms do not fail when ECN signals are available. With ECN signals enabled the algorithms are expected to perform better than their delay-based variants. Sarker, et al. Expires November 24, 2019 [Page 27] Internet-Draft Test Scenarios for RMCAT May 2019 6.3. Multiple Bottlenecks In this test case one congestion controlled media flow, S1->R1, traverses a path with multiple bottlenecks. As illustrated in Figure 7, the first flow (S1->R1) competes with the second congestion controlled media flow (S2->R2) over the link between A and B which is close to the sender side; again, that flow (S1->R1) competes with the third congestion controlled media flow (S3->R3) over the link between C and D which is close to the receiver side. The goal of this test is to ensure that the candidate algorithms work properly in the presence of multiple bottleneck links on the end to end path. Expected behavior: The candidate algorithm is expected to achieve full utilization at both bottleneck links without starving any of the three congestion controlled media flows and ensuring fair share of the available bandwidth at each bottlenecks. Forward ----> +---+ +---+ +---+ +---+ |S2 | |R2 | |S3 | |R3 | +---+ +---+ +---+ +---+ | | | | | | | | +---+ +-----+ +-----+ +-----+ +-----+ +---+ |S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 | +---+ | |<------| |<-----| |<----| | +---+ +-----+ +-----+ +-----+ +-----+ 1st 2nd Bottleneck (A->B) Bottleneck (C->D) <------ Backward Figure 7: Testbed Topology for Multiple Bottlenecks Testbed topology: Three media sources S1, S2, and S3 are connected to respective destinations R1, R2, and R3. For all three flows the media traffic is transported over the forward path and corresponding feedback/control traffic is transported over the backward path. Testbed attributes: Sarker, et al. Expires November 24, 2019 [Page 28] Internet-Draft Test Scenarios for RMCAT May 2019 o Test duration: 300s o Path characteristics: * Reference bottleneck capacity: 2Mbps. * Path capacity ratio between A and B: 1.0 * Path capacity ratio between B and C: 4.0. * Path capacity ratio between C and D: 0.75. * One-Way propagation delay: 1. Between S1 and R1: 100ms 2. Between S2 and R2: 40ms 3. Between S3 and R3: 40ms o Application-related: * Media Source: + Media type: Video - Media direction: Forward - Number of media sources: Three (3) - Media timeline: o Start time: 0s. o End time: 299s. + Media type: Audio - Media direction: Forward - Number of media sources: Three (3) - Media timeline: o Start time: 0s. o End time: 299s. Sarker, et al. Expires November 24, 2019 [Page 29] Internet-Draft Test Scenarios for RMCAT May 2019 * Competing traffic: + Number of sources : Zero (0) 7. Wireless Access Links Additional wireless network (both cellular network and WiFi network) specific test cases are defined in [I-D.ietf-rmcat-wireless-tests]. 8. Security Considerations The security considerations in [I-D.ietf-rmcat-eval-criteria] and the relevant congestion control algorithms apply. The principles for congestion control are described in [RFC2914], and in particular any new method must implement safeguards to avoid congestion collapse of the Internet. The evaluation of the test cases are intended to be run in a controlled lab environment. Hence, the applications, simulators and network nodes ought to be well-behaved and should not impact the desired results. Moreover, proper measures must be taken to avoid leaking non-responsive traffic from unproven congestion avoidance techniques onto the open Internet. 9. IANA Considerations There are no IANA impacts in this memo. 10. Acknowledgements Much of this document is derived from previous work on congestion control at the IETF. The content and concepts within this document are a product of the discussion carried out in the Design Team. 11. References 11.1. Normative References [I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", draft-ietf-rmcat-cc- requirements-09 (work in progress), December 2014. Sarker, et al. Expires November 24, 2019 [Page 30] Internet-Draft Test Scenarios for RMCAT May 2019 [I-D.ietf-rmcat-eval-criteria] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Control for Interactive Real-time Media", draft-ietf- rmcat-eval-criteria-08 (work in progress), November 2018. [I-D.ietf-rmcat-video-traffic-model] Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models for RTP Congestion Control Evaluations", draft-ietf-rmcat- video-traffic-model-07 (work in progress), February 2019. [I-D.ietf-rmcat-wireless-tests] Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and M. Ramalho, "Evaluation Test Cases for Interactive Real- Time Media over Wireless Networks", draft-ietf-rmcat- wireless-tests-06 (work in progress), December 2018. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . Sarker, et al. Expires November 24, 2019 [Page 31] Internet-Draft Test Scenarios for RMCAT May 2019 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, . 11.2. Informative References [HEVC-seq] HEVC, "Test Sequences", http://www.netlab.tkk.fi/~varun/test_sequences/ . [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-08 (work in progress), January 2019. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, . [RFC8290] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm", RFC 8290, DOI 10.17487/RFC8290, January 2018, . [xiph-seq] Xiph.org, "Video Test Media", http://media.xiph.org/video/derf/ . Authors' Addresses Sarker, et al. Expires November 24, 2019 [Page 32] Internet-Draft Test Scenarios for RMCAT May 2019 Zaheduzzaman Sarker Ericsson AB Torshamnsgatan 23 Stockholm, SE 164 83 Sweden Phone: +46 10 717 37 43 Email: zaheduzzaman.sarker@ericsson.com Varun Singh Nemu Dialogue Systems Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland Email: varun.singh@iki.fi URI: http://www.callstats.io/ Xiaoqing Zhu Cisco Systems 12515 Research Blvd Austing, TX 78759 USA Email: xiaoqzhu@cisco.com Michael A. Ramalho Cisco Systems, Inc. 6310 Watercrest Way Unit 203 Lakewood Ranch, FL 34202-5211 USA Phone: +1 919 476 2038 Email: mramalho@cisco.com Sarker, et al. Expires November 24, 2019 [Page 33] ./draft-ietf-rmcat-wireless-tests-11.txt0000644000764400076440000014273413632754571017503 0ustar iustyiusty Network Working Group Z. Sarker Internet-Draft Ericsson AB Intended status: Informational X. Zhu Expires: September 14, 2020 J. Fu Cisco Systems March 13, 2020 Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks draft-ietf-rmcat-wireless-tests-11 Abstract The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well- functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2020. Copyright Notice Copyright (c) 2020 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 Sarker, et al. Expires September 14, 2020 [Page 1] Internet-Draft RMCAT Wireless Test Cases March 2020 (https://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. Cellular Network Specific Test Cases . . . . . . . . . . . . 3 2.1. Varying Network Load . . . . . . . . . . . . . . . . . . 6 2.1.1. Network Connection . . . . . . . . . . . . . . . . . 6 2.1.2. Simulation Setup . . . . . . . . . . . . . . . . . . 7 2.1.3. Expected behavior . . . . . . . . . . . . . . . . . . 9 2.2. Bad Radio Coverage . . . . . . . . . . . . . . . . . . . 9 2.2.1. Network connection . . . . . . . . . . . . . . . . . 9 2.2.2. Simulation Setup . . . . . . . . . . . . . . . . . . 9 2.2.3. Expected behavior . . . . . . . . . . . . . . . . . . 10 2.3. Desired Evaluation Metrics for cellular test cases . . . 10 3. Wi-Fi Networks Specific Test Cases . . . . . . . . . . . . . 10 3.1. Bottleneck in Wired Network . . . . . . . . . . . . . . . 12 3.1.1. Network topology . . . . . . . . . . . . . . . . . . 12 3.1.2. Test/simulation setup . . . . . . . . . . . . . . . . 13 3.1.3. Typical test scenarios . . . . . . . . . . . . . . . 14 3.1.4. Expected behavior . . . . . . . . . . . . . . . . . . 15 3.2. Bottleneck in Wi-Fi Network . . . . . . . . . . . . . . . 15 3.2.1. Network topology . . . . . . . . . . . . . . . . . . 15 3.2.2. Test/simulation setup . . . . . . . . . . . . . . . . 16 3.2.3. Typical test scenarios . . . . . . . . . . . . . . . 17 3.2.4. Expected behavior . . . . . . . . . . . . . . . . . . 18 3.3. Other Potential Test Cases . . . . . . . . . . . . . . . 19 3.3.1. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . 19 3.3.2. Effect of heterogeneous link rates . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Sarker, et al. Expires September 14, 2020 [Page 2] Internet-Draft RMCAT Wireless Test Cases March 2020 1. Introduction Wireless networks (both cellular and Wi-Fi [IEEE802.11]) are an integral and increasingly more significant part of the Internet. Typical application scenarios for interactive multimedia communication over wireless include from video conferencing calls in a bus or train as well as live media streaming at home. It is well known that the characteristics and technical challenges for supporting multimedia services over wireless are very different from those of providing the same service over a wired network. Although the basic test cases as defined in [I-D.ietf-rmcat-eval-test] have covered many common effects of network impairments for evaluating RTP-based congestion control schemes, they remain to be tested over characteristics and dynamics unique to a given wireless environment. For example, in cellular networks, the base station maintains individual queues per radio bearer per user hence it leads to a different nature of interactions between traffic flows of different users. This contrasts with a typical wired network setting where traffic flows from all users share the same queue at the bottleneck. Furthermore, user mobility patterns in a cellular network differ from those in a Wi-Fi network. Therefore, it is important to evaluate the performance of proposed candidate RTP-based congestion control solutions over cellular mobile networks and over Wi-Fi networks respectively. The draft [I-D.ietf-rmcat-eval-criteria] provides the guideline for evaluating candidate algorithms and recognizes the importance of testing over wireless access networks. However, it does not describe any specific test cases for performance evaluation of candidate algorithms. This document describes test cases specifically targeting cellular and Wi-Fi networks. 2. Cellular Network Specific Test Cases A cellular environment is more complicated than its wireline counterpart since it seeks to provide services in the context of variable available bandwidth, location dependencies and user mobilities at different speeds. In a cellular network, the user may reach the cell edge which may lead to a significant amount of retransmissions to deliver the data from the base station to the destination and vice versa. These radio links will often act as a bottleneck for the rest of the network and will eventually lead to excessive delays or packet drops. An efficient retransmission or link adaptation mechanism can reduce the packet loss probability but there will remain some packet losses and delay variations. Moreover, with increased cell load or handover to a congested cell, congestion in the transport network will become even worse. Besides, there exist certain characteristics that distinguish the cellular network Sarker, et al. Expires September 14, 2020 [Page 3] Internet-Draft RMCAT Wireless Test Cases March 2020 from other wireless access networks such as Wi-Fi. In a cellular network -- o The bottleneck is often a shared link with relatively few users. * The cost per bit over the shared link varies over time and is different for different users. * Leftover/unused resources can be consumed by other greedy users. o Queues are always per radio bearer hence each user can have many such queues. o Users can experience both Inter and Intra Radio Access Technology (RAT) handovers (see [HO-def-3GPP] for the definition of "handover"). o Handover between cells or change of serving cells (as described in [HO-LTE-3GPP] and [HO-UMTS-3GPP]) might cause user plane interruptions which can lead to bursts of packet losses, delay and/or jitter. The exact behavior depends on the type of radio bearer. Typically, the default best-effort bearers do not generate packet loss, instead, packets are queued up and transmitted once the handover is completed. o The network part decides how much the user can transmit. o The cellular network has variable link capacity per user. * It can vary as fast as a period of milliseconds. * It depends on many factors (such as distance, speed, interference, different flows). * It uses complex and smart link adaptation which makes the link behavior ever more dynamic. * The scheduling priority depends on the estimated throughput. o Both Quality of Service (QoS) and non-QoS radio bearers can be used. Hence, a real-time communication application operating over a cellular network needs to cope with a shared bottleneck link and variable link capacity, events like handover, non-congestion related loss, abrupt changes in bandwidth (both short term and long term) due to handover, network load and bad radio coverage. Even though 3GPP Sarker, et al. Expires September 14, 2020 [Page 4] Internet-Draft RMCAT Wireless Test Cases March 2020 has defined QoS bearers [QoS-3GPP] to ensure high-quality user experience, it is still preferable for real-time applications to behave in an adaptive manner. Different mobile operators deploy their own cellular networks with their own set of network functionalities and policies. Usually, a mobile operator network includes a range of radio access technologies such as 3G and 4G/LTE. Looking at the specifications of such radio technologies it is evident that only the more recent radio technologies can support the high bandwidth requirements from real- time interactive video applications. The future real-time interactive application will impose even greater demand on cellular network performance which makes 4G (and beyond) radio technologies more suitable for such genre of application. The key factors in defining test cases for cellular networks are: o Shared and varying link capacity o Mobility o Handover However, these factors are typically highly correlated in a cellular network. Therefore, instead of devising separate test cases for individual important events, we have divided the test case into two categories. It should be noted that the goal of the following test cases is to evaluate the performance of candidate algorithms over the radio interface of the cellular network. Hence it is assumed that the radio interface is the bottleneck link between the communicating peers and that the core network does not introduce any extra congestion along the path. Consequently, this draft has kept as out of scope the combination of multiple access technologies involving both cellular and Wi-Fi users. In this latter case the shared bottleneck is likely at the wired backhaul link. These test cases further assume a typical real-time telephony scenario where one real- time session consists of one voice stream and one video stream. Even though it is possible to carry out tests over operational cellular networks (e.g., LTE/5G), and actually such tests are already available today, these tests cannot in general be carried out in a deterministic fashion to ensure repeatability. The main reason is that these networks are controlled by cellular operators and there exist various amounts of competing traffic in the same cell(s). In practice, it is only in underground mines that one can carry out near deterministic testing. Even there, it is not guaranteed either as workers in the mines may carry with them their personal mobile phones. Furthermore, the underground mining setting may not reflect Sarker, et al. Expires September 14, 2020 [Page 5] Internet-Draft RMCAT Wireless Test Cases March 2020 typical usage patterns in an urban setting. We, therefore, recommend that a cellular network simulator is used for the test cases defined in this document, for example -- the LTE simulator in [NS-3]. 2.1. Varying Network Load The goal of this test is to evaluate the performance of the candidate congestion control algorithm under varying network load. The network load variation is created by adding and removing network users a.k.a. User Equipments (UEs) during the simulation. In this test case, each user/UE in the media session is an endpoint following RTP-based congestion control. User arrivals follow a Poisson distribution proportional to the length of the call, to keep the number of users per cell fairly constant during the evaluation period. At the beginning of the simulation, there should be enough time to warm-up the network. This is to avoid running the evaluation in an empty network where network nodes are having empty buffers, low interference at the beginning of the simulation. This network initialization period should be excluded from the evaluation period. Typically, the evaluation period starts 30 seconds after test initialization. This test case also includes user mobility and some competing traffic. The latter includes both the same types of flows (with same adaptation algorithms) and different types of flows (with different services and congestion control schemes). 2.1.1. Network Connection Each mobile user is connected to a fixed user. The connection between the mobile user and fixed user consists of a cellular radio access, an Evolved Packet Core (EPC) and an Internet connection. The mobile user is connected to the EPC using cellular radio access technology which is further connected to the Internet. At the other end, the fixed user is connected to the Internet via wired connection with sufficiently high bandwidth, for instance, 10 Gbps, so that the system bottleneck is on the cellular radio access interface. The wired connection to in this setup does not introduce any network impairments to the test; it only adds 10 ms of one-way propagation delay. The path from the fixed user to the mobile users is defined as "Downlink" and the path from the mobile users to the fixed user is defined as "Uplink". We assume that only uplink or downlink is congested for mobile users. Hence, we recommend that the uplink and downlink simulations are run separately. Sarker, et al. Expires September 14, 2020 [Page 6] Internet-Draft RMCAT Wireless Test Cases March 2020 uplink ++))) +--------------------------> ++-+ ((o)) | | / \ +-------+ +------+ +---+ +--+ / \----+ +-----+ +----+ | / \ +-------+ +------+ +---+ UE BS EPC Internet fixed <--------------------------+ downlink Figure 1: Simulation Topology 2.1.2. Simulation Setup The values enclosed within "[ ]" for the following simulation attributes follow the same notion as in [I-D.ietf-rmcat-eval-test]. The desired simulation setup is as follows -- 1. Radio environment: A. Deployment and propagation model: 3GPP case 1 (see [HO-deploy-3GPP]) B. Antenna: Multiple-Input and Multiple-Output (MIMO), 2D or 3D antenna pattern. C. Mobility: [3km/h, 30km/h] D. Transmission bandwidth: 10MHz E. Number of cells: multi-cell deployment (3 Cells per Base Station (BS) * 7 BS) = 21 cells F. Cell radius: 166.666 Meters G. Scheduler: Proportional fair with no priority H. Bearer: Default bearer for all traffic. I. Active Queue Management (AQM) settings: AQM [on,off] 2. End-to-end Round Trip Time (RTT): [40ms, 150ms] 3. User arrival model: Poisson arrival model 4. User intensity: Sarker, et al. Expires September 14, 2020 [Page 7] Internet-Draft RMCAT Wireless Test Cases March 2020 * Downlink user intensity: {0.7, 1.4, 2.1, 2.8, 3.5, 4.2, 4.9, 5.6, 6.3, 7.0, 7.7, 8.4, 9,1, 9.8, 10.5} * Uplink user intensity : {0.7, 1.4, 2.1, 2.8, 3.5, 4.2, 4.9, 5.6, 6.3, 7.0} 5. Simulation duration: 91s 6. Evaluation period: 30s-60s 7. Media traffic: 1. Media type: Video a. Media direction: [Uplink, Downlink] b. Number of Media source per user: One (1) c. Media duration per user: 30s d. Media source: same as defined in Section 4.3 of [I-D.ietf-rmcat-eval-test] 2. Media Type: Audio a. Media direction: Uplink and Downlink b. Number of Media source per user: One (1) c. Media duration per user: 30s d. Media codec: Constant Bit Rate (CBR) e. Media bitrate: 20 Kbps f. Adaptation: off 8. Other traffic models: * Downlink simulation: Maximum of 4Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681]) * Unlink simulation: Maximum of 2Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681]) Sarker, et al. Expires September 14, 2020 [Page 8] Internet-Draft RMCAT Wireless Test Cases March 2020 2.1.3. Expected behavior The investigated congestion control algorithms should result in maximum possible network utilization and stability in terms of rate variations, lowest possible end to end frame latency, network latency and Packet Loss Rate (PLR) at different cell load levels. 2.2. Bad Radio Coverage The goal of this test is to evaluate the performance of candidate congestion control algorithm when users visit part of the network with bad radio coverage. The scenario is created by using a larger cell radius than that in the previous test case. In this test case, each user/UE in the media session is an endpoint following RTP-based congestion control. User arrivals follow a Poisson distribution proportional to the length of the call, to keep the number of users per cell fairly constant during the evaluation period. At the beginning of the simulation, there should be enough amount of time to warm-up the network. This is to avoid running the evaluation in an empty network where network nodes are having empty buffers, low interference at the beginning of the simulation. This network initialization period should be excluded from the evaluation period. Typically, the evaluation period starts 30 seconds after test initialization. This test case also includes user mobility and some competing traffic. The latter includes the same kind of flows (with same adaptation algorithms). 2.2.1. Network connection Same as defined in Section 2.1.1 2.2.2. Simulation Setup The desired simulation setup is the same as the Varying Network Load test case defined in Section 2.1 except the following changes: 1. Radio environment: Same as defined in Section 2.1.2 except the following: A. Deployment and propagation model: 3GPP case 3 (see [HO-deploy-3GPP]) B. Cell radius: 577.3333 Meters C. Mobility: 3km/h Sarker, et al. Expires September 14, 2020 [Page 9] Internet-Draft RMCAT Wireless Test Cases March 2020 2. User intensity = {0.7, 1.4, 2.1, 2.8, 3.5, 4.2, 4.9, 5.6, 6.3, 7.0} 3. Media traffic model: Same as defined in Section 2.1.2 4. Other traffic models: * Downlink simulation: Maximum of 2Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681]) * Unlink simulation: Maximum of 1Mbps/cell (web browsing or FTP traffic following default TCP congestion control [RFC5681]) 2.2.3. Expected behavior The investigated congestion control algorithms should result in maximum possible network utilization and stability in terms of rate variations, lowest possible end to end frame latency, network latency and Packet Loss Rate (PLR) at different cell load levels. 2.3. Desired Evaluation Metrics for cellular test cases The evaluation criteria document [I-D.ietf-rmcat-eval-criteria] defines the metrics to be used to evaluate candidate algorithms. Considering the nature and distinction of cellular networks we recommend that at least the following metrics be used to evaluate the performance of the candidate algorithms: o Average cell throughput (for all cells), shows cell utilizations. o Application sending and receiving bitrate, goodput. o Packet Loss Rate (PLR). o End-to-end Media frame delay. For video, this means the delay from capture to display. o Transport delay. o Algorithm stability in terms of rate variation. 3. Wi-Fi Networks Specific Test Cases Given the prevalence of Internet access links over Wi-Fi, it is important to evaluate candidate RTP-based congestion control solutions over test cases that include Wi-Fi access links. Such Sarker, et al. Expires September 14, 2020 [Page 10] Internet-Draft RMCAT Wireless Test Cases March 2020 evaluations should highlight the inherently different characteristics of Wi-Fi networks in contrast to their wired counterparts: o The wireless radio channel is subject to interference from nearby transmitters, multipath fading, and shadowing. These effects lead to fluctuations in the link throughput and sometimes an error- prone communication environment. o Available network bandwidth is not only shared over the air between concurrent users but also between uplink and downlink traffic due to the half-duplex nature of the wireless transmission medium. o Packet transmissions over Wi-Fi are susceptible to contentions and collisions over the air. Consequently, traffic load beyond a certain utilization level over a Wi-Fi network can introduce frequent collisions over the air and significant network overhead, as well as packet drops due to buffer overflow at the transmitters. This, in turn, leads to excessive delay, retransmissions, packet losses and lower effective bandwidth for applications. Note further that the collision-induced delay and loss patterns are qualitatively different from those caused by congestion over a wired connection. o The IEEE 802.11 standard (i.e., Wi-Fi) supports multi-rate transmission capabilities by dynamically choosing the most appropriate modulation and coding scheme (MCS) for the given received signal strength. A different choice in the MCS Index leads to different physical-layer (PHY-layer) link rates and consequently different application-layer throughput. o The presence of legacy devices (e.g., ones operating only in IEEE 802.11b) at a much lower PHY-layer link rate can significantly slow down the rest of a modern Wi-Fi network. As discussed in [Heusse2003], the main reason for such anomaly is that it takes much longer to transmit the same packet over a slower link than over a faster link, thereby consuming a substantial portion of air time. o Handover from one Wi-Fi Access Point (AP) to another may lead to excessive packet delays and losses during the process. o IEEE 802.11e has introduced the Enhanced Distributed Channel Access (EDCA) mechanism to allow different traffic categories to contend for channel access using different random back-off parameters. This mechanism is a mandatory requirement for the Wi- Fi Multimedia (WMM) certification in Wi-Fi Alliance. It allows for prioritization of real-time application traffic such as voice Sarker, et al. Expires September 14, 2020 [Page 11] Internet-Draft RMCAT Wireless Test Cases March 2020 and video over non-urgent data transmissions (e.g., file transfer). In summary, the presence of Wi-Fi access links in different network topologies can exert different impact on the network performance in terms of application-layer effective throughput, packet loss rate, and packet delivery delay. These, in turn, will influence the behavior of end-to-end real-time multimedia congestion control. Unless otherwise mentioned, the test cases in this section choose the PHY- and MAC-layer parameters based on the IEEE 802.11n Standard. Statistics collected from enterprise Wi-Fi networks show that the two dominant physical modes are 802.11n and 802.11ac, accounting for 41% and 58% of connected devices. As Wi-Fi standards evolve over time -- for instance, with the introduction of the emerging Wi-Fi 6 (based on IEEE 802.11ax) products -- the PHY- and MAC-layer test case specifications need to be updated accordingly to reflect such changes. Typically, a Wi-Fi access network connects to a wired infrastructure. Either the wired or the Wi-Fi segment of the network can be the bottleneck. The following sections describe basic test cases for both scenarios separately. The same set of performance metrics as in [I-D.ietf-rmcat-eval-test]) should be collected for each test case. We recommend to carry out the test cases as defined in this document using a simulator, such as [NS-2] or [NS-3]. When feasible, it is encouraged to perform testbed-based evaluations using Wi-Fi access points and endpoints running up-to-date IEEE 802.11 protocols, such as 802.11ac and the emerging Wi-Fi 6, so as to verify the viability of the candidate schemes. 3.1. Bottleneck in Wired Network The test scenarios below are intended to mimic the setup of video conferencing over Wi-Fi connections from the home. Typically, the Wi-Fi home network is not congested and the bottleneck is present over the wired home access link. Although it is expected that test evaluation results from this section are similar to those as in [I-D.ietf-rmcat-eval-test], it is still worthwhile to run through these tests as sanity checks. 3.1.1. Network topology Figure 2 shows the network topology of Wi-Fi test cases. The test contains multiple mobile nodes (MNs) connected to a common Wi-Fi access point (AP) and their corresponding wired clients on fixed nodes (FNs). Each connection carries either a RTP-based media flow Sarker, et al. Expires September 14, 2020 [Page 12] Internet-Draft RMCAT Wireless Test Cases March 2020 or a TCP traffic flow. Directions of the flows can be uplink (i.e., from mobile nodes to fixed nodes), downlink (i.e., from fixed nodes to mobile nodes), or bi-directional. The total number of uplink/downlink/bi-directional flows for RTP-based media traffic and TCP traffic are denoted as N and M, respectively. Uplink +----------------->+ +------+ +------+ | MN_1 |)))) /=====| FN_1 | +------+ )) // +------+ . )) // . . )) // . . )) // . +------+ +----+ +-----+ +------+ | MN_N | ))))))) | | | |========| FN_N | +------+ | | | | +------+ | AP |=========| FN0 | +----------+ | | | | +----------+ | MN_tcp_1 | )))) | | | |======| FN_tcp_1 | +----------+ +----+ +-----+ +----------+ . )) \\ . . )) \\ . . )) \\ . +----------+ )) \\ +----------+ | MN_tcp_M |))) \=====| FN_tcp_M | +----------+ +----------+ +<-----------------+ Downlink Figure 2: Network topology for Wi-Fi test cases 3.1.2. Test/simulation setup o Test duration: 120s o Wi-Fi network characteristics: * Radio propagation model: Log-distance path loss propagation model (see [NS3WiFi]) * PHY- and MAC-layer configuration: IEEE 802.11n * MCS Index at 11: 16-QAM 1/2, Raw Data Rate at 52Mbps o Wired path characteristics: Sarker, et al. Expires September 14, 2020 [Page 13] Internet-Draft RMCAT Wireless Test Cases March 2020 * Path capacity: 1Mbps * One-Way propagation delay: 50ms. * Maximum end-to-end jitter: 30ms * Bottleneck queue type: Drop tail. * Bottleneck queue size: 300ms. * Path loss ratio: 0%. o Application characteristics: * Media Traffic: + Media type: Video + Media direction: See Section 3.1.3 + Number of media sources (N): See Section 3.1.3 + Media timeline: - Start time: 0s. - End time: 119s. * Competing traffic: + Type of sources: long-lived TCP or CBR over UDP + Traffic direction: See Section 3.1.3 + Number of sources (M): See Section 3.1.3 + Congestion control: Default TCP congestion control [RFC5681] or constant-bit-rate (CBR) traffic over UDP. + Traffic timeline: See Section 3.1.3 3.1.3. Typical test scenarios o Single uplink RTP-based media flow: N=1 with uplink direction and M=0. o One pair of bi-directional RTP-based media flows: N=2 (i.e., one uplink flow and one downlink flow); M=0. Sarker, et al. Expires September 14, 2020 [Page 14] Internet-Draft RMCAT Wireless Test Cases March 2020 o One pair of bi-directional RTP-based media flows: N=2; one uplink on-off CBR flow over UDP: M=1 (uplink). The CBR flow has ON time at t=0s-60s and OFF time at t=60s-119s. o One pair of bi-directional RTP-based media flows: N=2; one uplink off-on CBR flow over UDP: M=1 (uplink). The CBR flow has OFF time at t=0s-60s and ON time at t=60s-119s. o One RTP-based media flow competing against one long-live TCP flow in the uplink direction: N=1 (uplink) and M = 1(uplink). The TCP flow has start time at t=0s and end time at t=119s. 3.1.4. Expected behavior o Single uplink RTP-based media flow: the candidate algorithm is expected to detect the path capacity constraint, to converge to the bottleneck link capacity, and to adapt the flow to avoid unwanted oscillations when the sending bit rate is approaching the bottleneck link capacity. No excessive oscillations in the media rate should be present. o Bi-directional RTP-based media flows: the candidate algorithm is expected to converge to the bottleneck capacity of the wired path in both directions despite the presence of measurement noise over the Wi-Fi connection. In the presence of background TCP or CBR over UDP traffic, the rate of RTP-based media flows should adapt promptly to the arrival and departure of background traffic flows. o One RTP-based media flow competing with long-live TCP flow in the uplink direction: the candidate algorithm is expected to avoid congestion collapse and to stabilize at a fair share of the bottleneck link capacity. 3.2. Bottleneck in Wi-Fi Network The test cases in this section assume that the wired segment along the media path is well-provisioned whereas the bottleneck exists over the Wi-Fi access network. This is to mimic the application scenarios typically encountered by users in an enterprise environment or at a coffee house. 3.2.1. Network topology Same as defined in Section 3.1.1 Sarker, et al. Expires September 14, 2020 [Page 15] Internet-Draft RMCAT Wireless Test Cases March 2020 3.2.2. Test/simulation setup o Test duration: 120s o Wi-Fi network characteristics: * Radio propagation model: Log-distance path loss propagation model (see [NS3WiFi]) * PHY- and MAC-layer configuration: IEEE 802.11n * MCS Index at 11: 16-QAM 1/2, Raw Data Rate at 52Mbps o Wired path characteristics: * Path capacity: 100Mbps. * One-Way propagation delay: 50ms. * Maximum end-to-end jitter: 30ms. * Bottleneck queue type: Drop tail. * Bottleneck queue size: 300ms. * Path loss ratio: 0%. o Application characteristics: * Media Traffic: + Media type: Video + Media direction: See Section 3.2.3. + Number of media sources (N): See Section 3.2.3. + Media timeline: - Start time: 0s. - End time: 119s. * Competing traffic: + Type of sources: long-lived TCP or CBR over UDP. + Number of sources (M): See Section 3.2.3. Sarker, et al. Expires September 14, 2020 [Page 16] Internet-Draft RMCAT Wireless Test Cases March 2020 + Traffic direction: See Section 3.2.3. + Congestion control: Default TCP congestion control [RFC5681] or constant-bit-rate (CBR) traffic over UDP. + Traffic timeline: See Section 3.2.3. 3.2.3. Typical test scenarios This section describes a few test scenarios that are deemed as important for understanding the behavior of a candidate RTP-based congestion control scheme over a Wi-Fi network. a. Multiple RTP-based media flows sharing the wireless downlink: N=16 (all downlink); M = 0. This test case is for studying the impact of contention on the multiple concurrent media flows. For an 802.11n network, given the MCS Index of 11 and the corresponding link rate of 52Mbps, the total application-layer throughput (assuming reasonable distance, low interference and infrequent contentions caused by competing streams) is around 20Mbps. A total of N=16 RTP-based media flows (with a maximum rate of 1.5Mbps each) are expected to saturate the wireless interface in this experiment. Evaluation of a given candidate scheme should focus on whether the downlink media flows can stabilize at a fair share of the total application-layer throughput. b. Multiple RTP-based media flows sharing the wireless uplink: N = 16 (all uplink); M = 0. When multiple clients attempt to transmit media packets uplink over the Wi-Fi network, they introduce more frequent contentions and potential collisions. Per-flow throughput is expected to be lower than that in the previous downlink-only scenario. Evaluation of a given candidate scheme should focus on whether the uplink flows can stabilize at a fair share of the total application-layer throughput. c. Multiple bi-directional RTP-based media flows: N = 16 (8 uplink and 8 downlink); M = 0. The goal of this test is to evaluate the performance of the candidate scheme in terms of bandwidth fairness between uplink and downlink flows. d. Multiple bi-directional RTP-based media flows with on-off CBR traffic over UDP: N = 16 (8 uplink and 8 downlink); M = 5 (uplink). The goal of this test is to evaluate the adaptation behavior of the candidate scheme when its available bandwidth changes due to the departure of background traffic. The background traffic consists of several (e.g., M=5) CBR flows Sarker, et al. Expires September 14, 2020 [Page 17] Internet-Draft RMCAT Wireless Test Cases March 2020 transported over UDP. These background flows are ON at time t=0-60s and OFF at time t=61-120s. e. Multiple bi-directional RTP-based media flows with off-on CBR traffic over UDP: N = 16 (8 uplink and 8 downlink); M = 5 (uplink). The goal of this test is to evaluate the adaptation behavior of the candidate scheme when its available bandwidth changes due to the arrival of background traffic. The background traffic consists of several (e.g., M=5) parallel CBR flows transported over UDP. These background flows are OFF at time t=0-60s and ON at times t=61-120s. f. Multiple bi-directional RTP-based media flows in the presence of background TCP traffic: N=16 (8 uplink and 8 downlink); M = 5 (uplink). The goal of this test is to evaluate how RTP-based media flows compete against TCP over a congested Wi-Fi network for a given candidate scheme. TCP flows have start time at t=40s and end time at t=80s. g. Varying number of RTP-based media flows: A series of tests can be carried out for the above test cases with different values of N, e.g., N = [4, 8, 12, 16, 20]. The goal of this test is to evaluate how a candidate scheme responds to varying traffic load/ demand over a congested Wi-Fi network. The start times of the media flows are randomly distributes within a window of t=0-10s; their end times are randomly distributed within a window of t=110-120s. 3.2.4. Expected behavior o Multiple downlink RTP-based media flows: each media flow is expected to get its fair share of the total bottleneck link bandwidth. Overall bandwidth usage should not be significantly lower than that experienced by the same number of concurrent downlink TCP flows. In other words, the behavior of multiple concurrent TCP flows will be used as a performance benchmark for this test scenario. The end-to-end delay and packet loss ratio experienced by each flow should be within an acceptable range for real-time multimedia applications. o Multiple uplink RTP-based media flows: overall bandwidth usage by all media flows should not be significantly lower than that experienced by the same number of concurrent uplink TCP flows. In other words, the behavior of multiple concurrent TCP flows will be used as a performance benchmark for this test scenario. o Multiple bi-directional RTP-based media flows with dynamic background traffic carrying CBR flows over UDP: the media flows Sarker, et al. Expires September 14, 2020 [Page 18] Internet-Draft RMCAT Wireless Test Cases March 2020 are expected to adapt in a timely fashion to the changes in available bandwidth introduced by the arrival/departure of background traffic. o Multiple bi-directional RTP-based media flows with dynamic background traffic over TCP: during the presence of TCP background flows, the overall bandwidth usage by all media flows should not be significantly lower than those achieved by the same number of bi-directional TCP flows. In other words, the behavior of multiple concurrent TCP flows will be used as a performance benchmark for this test scenario. All downlink media flows are expected to obtain similar bandwidth as each other. The throughput of each media flow is expected to decrease upon the arrival of TCP background traffic and, conversely, increase upon their departure. Both reactions should occur in a timely fashion, for example, within 10s of seconds. o Varying number of bi-directional RTP-based media flows: the test results for varying values of N -- while keeping all other parameters constant -- is expected to show steady and stable per- flow throughput for each value of N. The average throughput of all media flows is expected to stay constant around the maximum rate when N is small, then gradually decrease with increasing value of N till it reaches the minimum allowed rate, beyond which the offered load to the Wi-Fi network exceeds its capacity (i.e., with a very large value of N). 3.3. Other Potential Test Cases 3.3.1. EDCA/WMM usage The EDCA/WMM mechanism defines prioritized QoS for four traffic classes (or Access Categories). RTP-based real-time media flows should achieve better performance in terms of lower delay and fewer packet losses with EDCA/WMM enabled when competing against non- interactive background traffic such as file transfers. When most of the traffic over Wi-Fi is dominated by media, however, turning on WMM may degrade performance since all media flows now attempt to access the wireless transmission medium more aggressively, thereby causing more frequent collisions and collision-induced losses. This is a topic worthy of further investigation. 3.3.2. Effect of heterogeneous link rates As discussed in [Heusse2003], the presence of clients operating over slow PHY-layer link rates (e.g., a legacy 802.11b device) connected to a modern network may adversely impact the overall performance of the network. Additional test cases can be devised to evaluate the Sarker, et al. Expires September 14, 2020 [Page 19] Internet-Draft RMCAT Wireless Test Cases March 2020 effect of clients with heterogeneous link rates on the performance of the candidate congestion control algorithm. Such test cases, for instance, can specify that the PHY-layer link rates for all clients span over a wide range (e.g., 2Mbps to 54Mbps) for investigating its effect on the congestion control behavior of the real-time interactive applications. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations The security considerations in [I-D.ietf-rmcat-eval-criteria] and the relevant congestion control algorithms apply. The principles for congestion control are described in [RFC2914], and in particular, any new method must implement safeguards to avoid congestion collapse of the Internet. Given the difficulty of deterministic wireless testing, it is recommended and expected that the tests described in this document would be done via simulations. However, in the case where these test cases are carried out in a testbed setting, the evaluation should take place in a controlled lab environment. In the testbed, the applications, simulators and network nodes ought to be well-behaved and should not impact the desired results. It is important to take appropriate caution to avoid leaking non-responsive traffic with unproven congestion avoidance behavior onto the open Internet. 6. Contributors The following individuals contributed to the design, implementation, and verification of the proposed test cases during earlier stages of this work. They have helped to validate and substantially improve this specification. Ingemar Johansson, of Ericsson AB contributing to the description and validation of cellular test cases during the earlier stage of this draft. Wei-Tian Tan, , of Cisco Systems designed and set up a Wi-Fi testbed for evaluating parallel video conferencing streams, based upon which proposed Wi-Fi test cases are described. He also recommended additional test cases to consider, such as the impact of EDCA/WMM usage. Michael A. Ramalho, of AcousticComms Consulting (previously at Cisco Systems) applied learnings from Cisco's internal Sarker, et al. Expires September 14, 2020 [Page 20] Internet-Draft RMCAT Wireless Test Cases March 2020 experimentation to the early versions of the draft. He also worked on validating the proposed test cases in a VM-based lab setting. 7. Acknowledgments The authors would like to thank Tomas Frankkila, Magnus Westerlund, Kristofer Sandlund, Sergio Mena de la Cruz, and Mirja Kuehlewind for their valuable inputs and review comments regarding this draft. 8. References 8.1. Normative References [HO-deploy-3GPP] TS 25.814, 3GPP., "Physical layer aspects for evolved Universal Terrestrial Radio Access (UTRA)", October 2006, . [I-D.ietf-rmcat-eval-criteria] Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Control for Interactive Real-time Media", draft-ietf- rmcat-eval-criteria-13 (work in progress), March 2020. [I-D.ietf-rmcat-eval-test] Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- eval-test-10 (work in progress), May 2019. [IEEE802.11] IEEE, "Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", 2012. [NS3WiFi] "Wi-Fi Channel Model in ns-3 Simulator", . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Sarker, et al. Expires September 14, 2020 [Page 21] Internet-Draft RMCAT Wireless Test Cases March 2020 8.2. Informative References [Heusse2003] Heusse, M., Rousseau, F., Berger-Sabbatel, G., and A. Duda, "Performance anomaly of 802.11b", in Proc. 23th Annual Joint Conference of the IEEE Computer and Communications Societies, (INFOCOM'03), March 2003. [HO-def-3GPP] TR 21.905, 3GPP., "Vocabulary for 3GPP Specifications", December 2009, . [HO-LTE-3GPP] TS 36.331, 3GPP., "E-UTRA- Radio Resource Control (RRC); Protocol specification", December 2011, . [HO-UMTS-3GPP] TS 25.331, 3GPP., "Radio Resource Control (RRC); Protocol specification", December 2011, . [NS-2] "ns-2", December 2014, . [NS-3] "ns-3 Network Simulator", . [QoS-3GPP] TS 23.203, 3GPP., "Policy and charging control architecture", June 2011, . [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . Authors' Addresses Sarker, et al. Expires September 14, 2020 [Page 22] Internet-Draft RMCAT Wireless Test Cases March 2020 Zaheduzzaman Sarker Ericsson AB Laboratoriegraend 11 Luleae 97753 Sweden Phone: +46 107173743 Email: zaheduzzaman.sarker@ericsson.com Xiaoqing Zhu Cisco Systems 12515 Research Blvd., Building 4 Austin, TX 78759 USA Email: xiaoqzhu@cisco.com Jiantao Fu Cisco Systems 771 Alder Drive Milpitas, CA 95035 USA Email: jianfu@cisco.com Sarker, et al. Expires September 14, 2020 [Page 23] ./draft-ietf-roll-efficient-npdao-18.txt0000644000764400076440000015702113645737117017406 0ustar iustyiusty ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert Expires: October 17, 2020 Cisco R. Sahoo Z. Cao Huawei April 15, 2020 Efficient Route Invalidation draft-ietf-roll-efficient-npdao-18 Abstract This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 17, 2020. Copyright Notice Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jadhav, et al. Expires October 17, 2020 [Page 1] Internet-Draft Efficient Route Invalidation April 2020 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 1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 1.3. Why Is NPDAO Important? . . . . . . . . . . . . . . . . . 5 2. Problems with current NPDAO messaging . . . . . . . . . . . . 6 2.1. Lost NPDAO due to link break to the previous parent . . . 6 2.2. Invalidate Routes of Dependent Nodes . . . . . . . . . . 6 2.3. Possible route downtime caused by asynchronous operation of NPDAO and DAO . . . . . . . . . . . . . . . . . . . . 6 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6 3.1. Req#1: Remove messaging dependency on link to the previous parent . . . . . . . . . . . . . . . . . . . . . 6 3.2. Req#2: Dependent nodes route invalidation on parent switching . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Req#3: Route invalidation should not impact data traffic 7 4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7 4.2. Transit Information Option changes . . . . . . . . . . . 8 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 11 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 13 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 14 4.6.3. Considerations for DCO retry . . . . . . . . . . . . 14 4.6.4. DCO with multiple preferred parents . . . . . . . . . 15 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Registry for the Destination Cleanup Object (DCO) Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 Jadhav, et al. Expires October 17, 2020 [Page 2] Internet-Draft Efficient Route Invalidation April 2020 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 20 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20 A.2. Example DCO Messaging with multiple preferred parents . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction RPL [RFC6550] (Routing Protocol for Low power and lossy networks) specifies a proactive distance-vector based routing scheme. RPL has optional messaging in the form of DAO (Destination Advertisement Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can use to learn a route towards the downstream nodes. In storing mode, DAO messages would result in routing entries being created on all intermediate 6LRs from the node's parent all the way towards the 6LBR. RPL allows the use of No-Path DAO (NPDAO) messaging to invalidate a routing path corresponding to the given target, thus releasing resources utilized on that path. A NPDAO is a DAO message with route lifetime of zero, originates at the target node and always flows upstream towards the 6LBR. This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. The document only caters to the RPL's storing mode of operation (MOP). The non-storing MOP does not require use of NPDAO for route invalidation since routing entries are not maintained on 6LRs. 1.1. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification requires readers to be familiar with all the terms and concepts that are discussed in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550]. Low Power and Lossy Networks (LLN): Network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (batter power). Their Jadhav, et al. Expires October 17, 2020 [Page 3] Internet-Draft Efficient Route Invalidation April 2020 interconnects are characterized by high loss rates, low data rates, and instability. 6LoWPAN Router (6LR): An intermediate router that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets. Directed Acyclic Graph (DAG): A directed graph having the property that all edges are oriented in such a way that no cycles exist. Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root with no outgoing edges. 6LoWPAN Border Router (6LBR): A border router which is a DODAG root and is the edge node for traffic flowing in and out of the 6LoWPAN network. Destination Advertisement Object (DAO): DAO messaging allows downstream routes to the nodes to be established. DODAG Information Object (DIO): DIO messaging allows upstream routes to the 6LBR to be established. DIO messaging is initiated at the DAO root. Common Ancestor node 6LR/6LBR node which is the first common node between two paths of a target node. No-Path DAO (NPDAO): A DAO message which has target with lifetime 0 used for the purpose of route invalidation. Destination Cleanup Object (DCO): A new RPL control message code defined by this document. DCO messaging improves proactive route invalidation in RPL. Regular DAO: A DAO message with non-zero lifetime. Routing adjacencies are created or updated based on this message. Target node: The node switching its parent whose routing adjacencies are updated (created/removed). 1.2. Current NPDAO messaging RPL uses NPDAO messaging in the storing mode so that the node changing its routing adjacencies can invalidate the previous route. This is needed so that nodes along the previous path can release any resources (such as the routing entry) they maintain on behalf of target node. For the rest of this document consider the following topology: Jadhav, et al. Expires October 17, 2020 [Page 4] Internet-Draft Efficient Route Invalidation April 2020 (6LBR) | | | (A) / \ / \ / \ (G) (H) | | | | | | (B) (C) \ ; \ ; \ ; (D) / \ / \ / \ (E) (F) Figure 1: Sample topology Node (D) is connected via preferred parent (B). (D) has an alternate path via (C) towards the 6LBR. Node (A) is the common ancestor for (D) for paths through (B)-(G) and (C)-(H). When (D) switches from (B) to (C), RPL allows sending NPDAO to (B) and regular DAO to (C). 1.3. Why Is NPDAO Important? Nodes in LLNs may be resource constrained. There is limited memory available and routing entry records are one of the primary elements occupying dynamic memory in the nodes. Route invalidation helps 6LR nodes to decide which entries could be discarded to better optimize resource utilization. Thus it becomes necessary to have an efficient route invalidation mechanism. Also note that a single parent switch may result in a "sub-tree" switching from one parent to another. Thus the route invalidation needs to be done on behalf of the sub- tree and not the switching node alone. In the above example, when Node (D) switches parent, the route updates needs to be done for the routing tables entries of (C),(H),(A),(G), and (B) with destination (D),(E) and (F). Without efficient route invalidation, a 6LR may have to hold a lot of stale route entries. Jadhav, et al. Expires October 17, 2020 [Page 5] Internet-Draft Efficient Route Invalidation April 2020 2. Problems with current NPDAO messaging 2.1. Lost NPDAO due to link break to the previous parent When a node switches its parent, the NPDAO is to be sent to its previous parent and a regular DAO to its new parent. In cases where the node switches its parent because of transient or permanent parent link/node failure then the NPDAO message is bound to fail. 2.2. Invalidate Routes of Dependent Nodes RPL does not specify how route invalidation will work for dependent nodes rooted at the switching node, resulting in stale routing entries of the dependent nodes. The only way for 6LR to invalidate the route entries for dependent nodes would be to use route lifetime expiry which could be substantially high for LLNs. In the example topology, when Node (D) switches its parent, Node (D) generates an NPDAO on its behalf. There is no NPDAO generated by the dependent child nodes (E) and (F), through the previous path via (D) to (B) and (G), resulting in stale entries on nodes (B) and (G) for nodes (E) and (F). 2.3. Possible route downtime caused by asynchronous operation of NPDAO and DAO A switching node may generate both an NPDAO and DAO via two different paths at almost the same time. There is a possibility that an NPDAO generated may invalidate the previous route and the regular DAO sent via the new path gets lost on the way. This may result in route downtime impacting downward traffic for the switching node. In the example topology, consider Node (D) switches from parent (B) to (C). An NPDAO sent via the previous route may invalidate the previous route whereas there is no way to determine whether the new DAO has successfully updated the route entries on the new path. 3. Requirements for the NPDAO Optimization 3.1. Req#1: Remove messaging dependency on link to the previous parent When the switching node sends the NPDAO message to the previous parent, it is normal that the link to the previous parent is prone to failure (that's why the node decided to switch). Therefore, it is required that the route invalidation does not depend on the previous link which is prone to failure. The previous link referred here represents the link between the node and its previous parent (from whom the node is now disassociating). Jadhav, et al. Expires October 17, 2020 [Page 6] Internet-Draft Efficient Route Invalidation April 2020 3.2. Req#2: Dependent nodes route invalidation on parent switching It should be possible to do route invalidation for dependent nodes rooted at the switching node. 3.3. Req#3: Route invalidation should not impact data traffic While sending the NPDAO and DAO messages, it is possible that the NPDAO successfully invalidates the previous path, while the newly sent DAO gets lost (new path not set up successfully). This will result in downstream unreachability to the node switching paths. Therefore, it is desirable that the route invalidation is synchronized with the DAO to avoid the risk of route downtime. 4. Changes to RPL signaling 4.1. Change in RPL route invalidation semantics As described in Section 1.2, the NPDAO originates at the node changing to a new parent and traverses upstream towards the root. In order to solve the problems as mentioned in Section 2, the document adds a new proactive route invalidation message called "Destination Cleanup Object" (DCO) that originates at a common ancestor node and flows downstream between the new and old path. The common ancestor node generates a DCO in response to the change in the next-hop on receiving a regular DAO with updated Path Sequence for the target. The 6LRs in the path for DCO take action such as route invalidation based on the DCO information and subsequently send another DCO with the same information downstream to the next hop. This operation is similar to how the DAOs are handled on intermediate 6LRs in storing MOP in [RFC6550]. Just like DAO in storing MOP, the DCO is sent using link-local unicast source and destination IPv6 address. Unlike DAO, which always travels upstream, the DCO always travels downstream. In Figure 1, when node D decides to switch the path from B to C, it sends a regular DAO to node C with reachability information containing the address of D as the target and an incremented Path Sequence. Node C will update the routing table based on the reachability information in the DAO and in turn generate another DAO with the same reachability information and forward it to H. Node H also follows the same procedure as Node C and forwards it to node A. When node A receives the regular DAO, it finds that it already has a routing table entry on behalf of the target address of node D. It finds however that the next hop information for reaching node D has changed i.e., node D has decided to change the paths. In this case, Node A which is the common ancestor node for node D along the two Jadhav, et al. Expires October 17, 2020 [Page 7] Internet-Draft Efficient Route Invalidation April 2020 paths (previous and new), should generate a DCO which traverses downwards in the network. Node A handles normal DAO forwarding to 6LBR as required by [RFC6550]. 4.2. Transit Information Option changes Every RPL message is divided into base message fields and additional Options as described in Section 6 of [RFC6550]. The base fields apply to the message as a whole and options are appended to add message/use-case specific attributes. As an example, a DAO message may be attributed by one or more "RPL Target" options which specify the reachability information for the given targets. Similarly, a Transit Information option may be associated with a set of RPL Target options. This document specifies a change in the Transit Information Option to contain the "Invalidate previous route" (I) flag. This 'I' flag signals the common ancestor node to generate a DCO on behalf of the target node with a RPL Status of 195 indicating that the address has moved. The 'I' flag is carried in the Transit Information Option which augments the reachability information for a given set of RPL Target(s). Transit Information Option with 'I' flag set should be carried in the DAO message when route invalidation is sought for the corresponding target(s). Value 195 represents 'E' and 'A' bit in RPL Status to be set as per Figure 3 of [I-D.ietf-roll-unaware-leaves] with the lower 6 bits with value 3 indicating 'Moved' as per Table 1 of [RFC8505]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 | Option Length |E|I| Flags | Path Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Sequence | Path Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Updated Transit Information Option (New I flag added) I (Invalidate previous route) flag: The 'I' flag is set by the target node to indicate to the common ancestor node that it wishes to invalidate any previous route between the two paths. [RFC6550] allows the parent address to be sent in the Transit Information Option depending on the mode of operation. In case of storing mode of operation the field is usually not needed. In case of DCO, the parent address field MUST NOT be included. Jadhav, et al. Expires October 17, 2020 [Page 8] Internet-Draft Efficient Route Invalidation April 2020 The common ancestor node SHOULD generate a DCO message in response to this 'I' flag when it sees that the routing adjacencies have changed for the target. The 'I' flag is intended to give the target node control over its own route invalidation, serving as a signal to request DCO generation. 4.3. Destination Cleanup Object (DCO) A new ICMPv6 RPL control message code is defined by this specification and is referred to as "Destination Cleanup Object" (DCO), which is used for proactive cleanup of state and routing information held on behalf of the target node by 6LRs. The DCO message always traverses downstream and cleans up route information and other state information associated with the given target. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | RPL Status | DCOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 3: DCO base object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. K: The 'K' flag indicates that the recipient of DCO message is expected to send a DCO-ACK back. If the DCO-ACK is not received even after setting the 'K' flag, an implementation may retry the DCO at a later time. The number of retries are implementation and deployment dependent and are expected to be kept similar with those used in DAO retries in [RFC6550]. Section 4.6.3 specifies the considerations for DCO retry. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition. An example error condition could be that the node sending the DCO-ACK does not find the routing entry for the indicated target. When the sender does not set the 'K' flag it is an indication that the sender does not expect a response, and the sender SHOULD NOT retry the DCO. Jadhav, et al. Expires October 17, 2020 [Page 9] Internet-Draft Efficient Route Invalidation April 2020 D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: The 6 bits remaining unused in the Flags field are reserved for future use. These bits MUST be initialized to zero by the sender and MUST be ignored by the receiver. RPL Status: As defined in [RFC6550] and updated in [I-D.ietf-roll-unaware-leaves]. The root or common parent that generates a DCO is authoritative for setting the status information and the information is unchanged as propagated down the DODAG. This document does not specify a differentiated action based on the RPL status. DCOSequence: 8-bit field incremented at each unique DCO message from a node and echoed in the DCO-ACK message. The initial DCOSequence can be chosen randomly by the node. Section 4.4 explains the handling of the DCOSequence. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present if 'D' flag is not set. DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. 4.3.1. Secure DCO A Secure DCO message follows the format in [RFC6550] Figure 7, where the base message format is the DCO message shown in Figure 3. 4.3.2. DCO Options The DCO message MUST carry at least one RPL Target and the Transit Information Option and MAY carry other valid options. This specification allows for the DCO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor Section 6.7 of [RFC6550] defines all the above mentioned options. The DCO carries an RPL Target Option and an associated Transit Information Option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target. Jadhav, et al. Expires October 17, 2020 [Page 10] Internet-Draft Efficient Route Invalidation April 2020 4.3.3. Path Sequence number in the DCO A DCO message may contain a Path Sequence in the Transit Information Option to identify the freshness of the DCO message. The Path Sequence in the DCO MUST use the same Path Sequence number present in the regular DAO message when the DCO is generated in response to a DAO message. Thus if a DCO is received by a 6LR and subsequently a DAO is received with an old sequence number, then the DAO MUST be ignored. When the DCO is generated in response to a DCO from upstream parent, the Path Sequence MUST be copied from the received DCO. 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) The DCO-ACK message SHOULD be sent as a unicast packet by a DCO recipient in response to a unicast DCO message with 'K' flag set. If 'K' flag is not set then the receiver of the DCO message MAY send a DCO-ACK, especially to report an error condition. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID(optional) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DCO-ACK base object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from the DCOSequence received in the DCO message. Jadhav, et al. Expires October 17, 2020 [Page 11] Internet-Draft Efficient Route Invalidation April 2020 DCO-ACK Status: Indicates the completion. A value of 0 is defined as unqualified acceptance in this specification. A value of 1 is defined as "No routing-entry for the Target found". The remaining status values are reserved as rejection codes. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present when 'D' flag is not set. DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. 4.3.5. Secure DCO-ACK A Secure DCO-ACK message follows the format in [RFC6550] Figure 7, where the base message format is the DCO-ACK message shown in Figure 4. 4.4. DCO Base Rules 1. If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. The DCOSequence counter follows the sequence counter operation as defined in Section 7.2 of [RFC6550]. 2. The RPLInstanceID and DODAGID fields of a DCO message MUST be the same value as that of the DAO message in response to which the DCO is generated on the common ancestor node. 3. A node MAY set the 'K' flag in a unicast DCO message to solicit a unicast DCO-ACK in response in order to confirm the attempt. 4. A node receiving a unicast DCO message with the 'K' flag set SHOULD respond with a DCO-ACK. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition. 5. A node receiving a unicast DCO message MUST verify the stored Path Sequence in context to the given target. If the stored Path Sequence is more fresh, newer than the Path Sequence received in the DCO, then the DCO MUST be dropped. 6. A node that sets the 'K' flag in a unicast DCO message but does not receive DCO-ACK in response MAY reschedule the DCO message transmission for another attempt, up until an implementation specific number of retries. 7. A node receiving a unicast DCO message with its own address in the RPL Target Option MUST strip-off that Target Option. If this Target Option is the only one in the DCO message then the DCO message MUST be dropped. Jadhav, et al. Expires October 17, 2020 [Page 12] Internet-Draft Efficient Route Invalidation April 2020 The scope of DCOSequence values is unique to the node which generates it. 4.5. Unsolicited DCO A 6LR may generate an unsolicited DCO to unilaterally cleanup the path on behalf of the target entry. The 6LR has all the state information, namely, the Target address and the Path Sequence, required for generating DCO in its routing table. The conditions why 6LR may generate an unsolicited DCO are beyond the scope of this document but some possible reasons could be: 1. On route expiry of an entry, a 6LR may decide to graciously cleanup the entry by initiating DCO. 2. 6LR needs to entertain higher priority entries in case the routing table is full, thus resulting in eviction of an existing routing entry. In this case the eviction can be handled graciously using DCO. Note that if the 6LR initiates a unilateral path cleanup using DCO and if it has the latest state for the target then the DCO would finally reach the target node. Thus the target node would be informed of its invalidation. 4.6. Other considerations 4.6.1. Dependent Nodes invalidation Current RPL [RFC6550] does not provide a mechanism for route invalidation for dependent nodes. This document allows the dependent nodes invalidation. Dependent nodes will generate their respective DAOs to update their paths, and the previous route invalidation for those nodes should work in the similar manner described for switching node. The dependent node may set the 'I' flag in the Transit Information Option as part of regular DAO so as to request invalidation of previous route from the common ancestor node. Dependent nodes do not have any indication regarding if any of their parents in turn have decided to switch their parent. Thus for route invalidation the dependent nodes may choose to always set the 'I' flag in all its DAO message's Transit Information Option. Note that setting the 'I' flag is not counterproductive even if there is no previous route to be invalidated. Jadhav, et al. Expires October 17, 2020 [Page 13] Internet-Draft Efficient Route Invalidation April 2020 4.6.2. NPDAO and DCO in the same network The current NPDAO mechanism in [RFC6550] can still be used in the same network where DCO is used. The NPDAO messaging can be used, for example, on route lifetime expiry of the target or when the node simply decides to gracefully terminate the RPL session on graceful node shutdown. Moreover, a deployment can have a mix of nodes supporting the DCO and the existing NPDAO mechanism. It is also possible that the same node supports both the NPDAO and DCO signaling for route invalidation. Section 9.8 of [RFC6550] states, "When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message to that removed DAO parent to invalidate the existing router". This document introduces an alternative and more optimized way of route invalidation but it also allows existing NPDAO messaging to work. Thus an implementation has two choices to make when a route invalidation is to be initiated: 1. Use NPDAO to invalidate the previous route and send regular DAO on the new path. 2. Send regular DAO on the new path with the 'I' flag set in the Transit Information Option such that the common ancestor node initiates the DCO message downstream to invalidate the previous route. This document recommends using option 2 for reasons specified in Section 3 in this document. This document assumes that all the 6LRs in the network support this specification. If there are 6LRs en-route DCO message path which do not support this document, then the route invalidation for corresponding targets may not work or may work partially i.e., only part of the path supporting DCO may be invalidated. Alternatively, a node could generate an NPDAO if it does not receive a DCO with itself as target within specified time limit. The specified time limit is deployment specific and depends upon the maximum depth of the network and per hop average latency. Note that sending NPDAO and DCO for the same operation would not result in unwanted side-effects because the acceptability of NPDAO or DCO depends upon the Path Sequence freshness. 4.6.3. Considerations for DCO retry A DCO message could be retried by a sender if it sets the 'K' flag and does not receive a DCO-ACK. The DCO retry time could be dependent on the maximum depth of the network and average per hop latency. This could range from 2 seconds to 120 seconds depending on Jadhav, et al. Expires October 17, 2020 [Page 14] Internet-Draft Efficient Route Invalidation April 2020 the deployment. In case the latency limits are not known, an implementation MUST NOT retry more than once in 3 seconds and MUST NOT retry more than 3 times. The number of retries could also be set depending on how critical the route invalidation could be for the deployment and the link layer retry configuration. For networks supporting only MP2P and P2MP flows, such as in AMI and telemetry applications, the 6LRs may not be very keen to invalidate routes, unless they are highly memory- constrained. For home and building automation networks which may have substantial P2P traffic, the 6LRs might be keen to invalidate efficiently because it may additionally impact the forwarding efficiency. 4.6.4. DCO with multiple preferred parents [RFC6550] allows a node to select multiple preferred parents for route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs generated at the same time for the same Target MUST be sent with the same Path Sequence in the Transit Information". Subsequently when route invalidation has to be initiated, RPL mentions use of NPDAO which can be initiated with an updated Path Sequence to all the parent nodes through which the route is to be invalidated. With DCO, the Target node itself does not initiate the route invalidation and it is left to the common ancestor node. A common ancestor node when it discovers an updated DAO from a new next-hop, it initiates a DCO. With multiple preferred parents, this handling does not change. But in this case it is recommended that an implementation initiates a DCO after a time period (DelayDCO) such that the common ancestor node may receive updated DAOs from all possible next-hops. This will help to reduce DCO control overhead i.e., the common ancestor can wait for updated DAOs from all possible directions before initiating a DCO for route invalidation. After timeout, the DCO needs to be generated for all the next-hops for whom the route invalidation needs to be done. This document recommends using a DelayDCO timer value of 1sec. This value is inspired by the default DelayDAO value of 1sec in [RFC6550]. Here the hypothesis is that the DAOs from all possible parent sets would be received on the common ancestor within this time period. It is still possible that a DCO is generated before all the updated DAOs from all the paths are received. In this case, the ancestor node would start the invalidation procedure for paths from which the updated DAO is not received. The DCO generated in this case would start invalidating the segments along these paths on which the updated DAOs are not received. But once the DAO reaches these Jadhav, et al. Expires October 17, 2020 [Page 15] Internet-Draft Efficient Route Invalidation April 2020 segments, the routing state would be updated along these segments and should not lead to any inconsistent routing state. Note that there is no requirement for synchronization between DCO and DAOs. The DelayDCO timer simply ensures that the DCO control overhead can be reduced and is only needed when the network contains nodes using multiple preferred parent. 5. Acknowledgments Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulous, Peter Van Der Stok for their review and comments. Alvaro Retana helped shape this document's final version with critical review comments. 6. IANA Considerations IANA is requested to allocate new codes for the DCO and DCO-ACK messages from the RPL Control Codes registry. +------+---------------------------------------------+--------------+ | Code | Description | Reference | +------+---------------------------------------------+--------------+ | TBD1 | Destination Cleanup Object | This | | | | document | | TBD2 | Destination Cleanup Object Acknowledgment | This | | | | document | | TBD3 | Secure Destination Cleanup Object | This | | | | document | | TBD4 | Secure Destination Cleanup Object | This | | | Acknowledgment | document | +------+---------------------------------------------+--------------+ IANA is requested to allocate bit 1 from the Transit Information Option Flags registry for the 'I' flag (Section 4.2) 6.1. New Registry for the Destination Cleanup Object (DCO) Flags IANA is requested to create a registry for the 8-bit Destination Cleanup Object (DCO) Flags field. This registry should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description Jadhav, et al. Expires October 17, 2020 [Page 16] Internet-Draft Efficient Route Invalidation April 2020 o Defining RFC The following bits are currently defined: +------------+------------------------------+---------------+ | Bit number | Description | Reference | +------------+------------------------------+---------------+ | 0 | DCO-ACK request (K) | This document | | 1 | DODAGID field is present (D) | This document | +------------+------------------------------+---------------+ DCO Base Flags 6.2. New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field IANA is requested to create a registry for the 8-bit Destination Cleanup Object Acknowledgment (DCO-ACK) Status field. This registry should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New Status values may be allocated only by an IETF Review. Each value is tracked with the following qualities: o Status Code o Description o Defining RFC The following values are currently defined: +------------+----------------------------------------+-------------+ | Status | Description | Reference | | Code | | | +------------+----------------------------------------+-------------+ | 0 | Unqualified acceptance | This | | | | document | | 1 | No routing-entry for the indicated | This | | | Target found | document | +------------+----------------------------------------+-------------+ DCO-ACK Status Codes 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags IANA is requested to create a registry for the 8-bit Destination Cleanup Object (DCO) Acknowledgment Flags field. This registry Jadhav, et al. Expires October 17, 2020 [Page 17] Internet-Draft Efficient Route Invalidation April 2020 should be located in existing category of "Routing Protocol for Low Power and Lossy Networks (RPL)". New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following bits are currently defined: +------------+------------------------------+---------------+ | Bit number | Description | Reference | +------------+------------------------------+---------------+ | 0 | DODAGID field is present (D) | This document | +------------+------------------------------+---------------+ DCO-ACK Base Flags 7. Security Considerations This document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. The common ancestor node could be directed to do so by the target node using the 'I' flag in DCO's Transit Information Option. However, the common ancestor node is in a position to unilaterally initiate the route invalidation since it possesses all the required state information, namely, the Target address and the corresponding Path Sequence. Thus a rogue common ancestor node could initiate such an invalidation and impact the traffic to the target node. The DCO carries a RPL Status value, which is informative. New Status values may be created over time and a node will ignore an unknown Status value. This enables RPL Status field to be used as a cover channel. But the channel only works once since the message destroys its own medium, that is the existing route that it is removing. This document also introduces an 'I' flag which is set by the target node and used by the ancestor node to initiate a DCO if the ancestor sees an update in the route adjacency. However, this flag could be spoofed by a malicious 6LR in the path and can cause invalidation of an existing active path. Note that invalidation will happen only if the other conditions such as Path Sequence condition is also met. Having said that, such a malicious 6LR may spoof a DAO on behalf of the (sub) child with the 'I' flag set and can cause route invalidation on behalf of the (sub) child node. Note that, using existing mechanisms offered by [RFC6550], a malicious 6LR might also Jadhav, et al. Expires October 17, 2020 [Page 18] Internet-Draft Efficient Route Invalidation April 2020 spoof a DAO with lifetime of zero or otherwise cause denial of service by dropping traffic entirely, so the new mechanism described in this document does not present a substantially increased risk of disruption. This document assumes that the security mechanisms as defined in [RFC6550] are followed, which means that the common ancestor node and all the 6LRs are part of the RPL network because they have the required credentials. A non-secure RPL network needs to take into consideration the risks highlighted in this section as well as those highlighted in [RFC6550]. All RPL messages support a secure version of messages which allows integrity protection using either a MAC or a signature. Optionally, secured RPL messages also have encryption protection for confidentiality. The document adds new messages (DCO, DCO-ACK) which are syntactically similar to existing RPL messages such as DAO, DAO-ACK. Secure versions of DCO and DCO-ACK are added similar to other RPL messages (such as DAO, DAO-ACK). RPL supports three security modes as mentioned in Section 10.1 of [RFC6550]: 1. Unsecured: In this mode, it is expected that the RPL control messages are secured by other security mechanisms, such as link- layer security. In this mode, the RPL control messages, including DCO, DCO-ACK, do not have Security sections. Also note that unsecured mode does not imply that all messages are sent without any protection. 2. Preinstalled: In this mode, RPL uses secure messages. Thus secure versions of DCO, DCO-ACK MUST be used in this mode. 3. Authenticated: In this mode, RPL uses secure messages. Thus secure versions of DCO, DCO-ACK MUST be used in this mode. 8. Normative References [I-D.ietf-roll-unaware-leaves] Thubert, P. and M. Richardson, "Routing for RPL Leaves", draft-ietf-roll-unaware-leaves-14 (work in progress), April 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Jadhav, et al. Expires October 17, 2020 [Page 19] Internet-Draft Efficient Route Invalidation April 2020 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Example Messaging A.1. Example DCO Messaging In Figure 1, node (D) switches its parent from (B) to (C). This example assumes that Node D has already established its own route via Node B-G-A-6LBR using pathseq=x. The example uses DAO and DCO messaging convention and specifies only the required parameters to explain the example namely, the parameter 'tgt', which stands for Target Option and value of this parameter specifies the address of the target node. The parameter 'pathseq', which specifies the Path Sequence value carried in the Transit Information Option. The parameter 'I_flag' specifies the 'I' flag in the Transit Information Option. sequence of actions is as follows: 1. Node D switches its parent from node B to node C 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated path to C 3. C checks for a routing entry on behalf of D, since it cannot find an entry on behalf of D it creates a new routing entry and forwards the reachability information of the target D to H in a DAO(tgt=D,pathseq=x+1,I_flag=1). 4. Similar to C, node H checks for a routing entry on behalf of D, cannot find an entry and hence creates a new routing entry and forwards the reachability information of the target D to A in a DAO(tgt=D,pathseq=x+1,I_flag=1). 5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), and checks for a routing entry on behalf of D. It finds a routing entry but checks that the next hop for target D is different (i.e., Node G). Node A checks the I_flag and generates DCO(tgt=D,pathseq=x+1) to previous next hop for target D which is G. Subsequently, Node A updates the routing entry and forwards the reachability information of target D upstream DAO(tgt=D,pathseq=x+1,I_flag=1). 6. Node G receives the DCO(tgt=D,pathseq=x+1). It checks if the received path sequence is later than the stored path sequence. If it is later, Node G invalidates the routing entry of target D Jadhav, et al. Expires October 17, 2020 [Page 20] Internet-Draft Efficient Route Invalidation April 2020 and forwards the (un)reachability information downstream to B in DCO(tgt=D,pathseq=x+1). 7. Similarly, B processes the DCO(tgt=D,pathseq=x+1) by invalidating the routing entry of target D and forwards the (un)reachability information downstream to D. 8. D ignores the DCO(tgt=D,pathseq=x+1) since the target is itself. 9. The propagation of the DCO will stop at any node where the node does not have an routing information associated with the target. If cached routing information is present and the cached Path Sequence is higher than the value in the DCO, then the DCO is dropped. A.2. Example DCO Messaging with multiple preferred parents (6LBR) | | | (N11) / \ / \ / \ (N21) (N22) / / \ / / \ / / \ (N31) (N32) (N33) : | / : | / : | / (N41) Figure 5: Sample topology 2 In Figure 5, node (N41) selects multiple preferred parents (N32) and (N33). The sequence of actions is as follows: 1. (N41) sends DAO(tgt=N41,PS=x,I_flag=1) to (N32) and (N33). Here I_flag refers to the Invalidation flag and PS refers to Path Sequence in Transit Information option. 2. (N32) sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also sends DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns multiple routes for the same destination (N41) through multiple next-hops. (N22) may receive the DAOs from (N32) and (N33) in any order with the I_flag set. The implementation should use the DelayDCO timer to wait to initiate the DCO. If (N22) receives an updated DAO from all the paths then the DCO need not Jadhav, et al. Expires October 17, 2020 [Page 21] Internet-Draft Efficient Route Invalidation April 2020 be initiated in this case. Thus the route table at N22 should contain (Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }. 3. (N22) sends DAO(tgt=N41,PS=x,I_flag=1) to (N11). 4. (N11) sends DAO(tgt=N41,PS=x,I_flag=1) to (6LBR). Thus the complete path is established. 5. (N41) decides to change preferred parent set from { N32, N33 } to { N31, N32 }. 6. (N41) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N32). (N41) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N31). 7. (N32) sends DAO(tgt=N41,PS=x+1,I_flag=1) to (N22). (N22) has multiple routes to destination (N41). It sees that a new Path Sequence for Target=N41 is received and thus it waits for pre- determined time period (DelayDCO time period) to invalidate another route {(N41),(N33),x}. After time period, (N22) sends DCO(tgt=N41,PS=x+1) to (N33). Also (N22) sends the regular DAO(tgt=N41,PS=x+1,I_flag=1) to (N11). 8. (N33) receives DCO(tgt=N41,PS=x+1). The received Path Sequence is latest and thus it invalidates the entry associated with target (N41). (N33) then sends the DCO(tgt=N41,PS=x+1) to (N41). (N41) sees itself as the target and drops the DCO. 9. From Step 6 above, (N31) receives the DAO(tgt=N41,PS=x+1,I_flag=1). It creates a routing entry and sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N21). Similarly (N21) receives the DAO and subsequently sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N11). 10. (N11) receives DAO(tgt=N41,PS=x+1,I_flag=1) from (N21). It waits for DelayDCO timer since it has multiple routes to (N41). (N41) will receive DAO(tgt=N41,PS=x+1,I_flag=1) from (N22) from Step 7 above. Thus (N11) has received regular DAO(tgt=N41,PS=x+1,I_flag=1) from all paths and thus does not initiate DCO. 11. (N11) forwards the DAO(tgt=N41,PS=x+1,I_flag=1) to 6LBR and the full path is established. Authors' Addresses Rahul Arvind Jadhav (editor) Huawei Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Jadhav, et al. Expires October 17, 2020 [Page 22] Internet-Draft Efficient Route Invalidation April 2020 Pascal Thubert Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis 06254 France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Rabi Narayan Sahoo Huawei Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rabinarayans@huawei.com Zhen Cao Huawei W Chang'an Ave Beijing P.R. China Email: zhencao.ietf@gmail.com Jadhav, et al. Expires October 17, 2020 [Page 23] ./draft-ietf-rtcweb-alpn-04.txt0000644000764400076440000003577312712725447015624 0ustar iustyiusty RTCWEB M. Thomson Internet-Draft Mozilla Intended status: Standards Track May 5, 2016 Expires: November 6, 2016 Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) draft-ietf-rtcweb-alpn-04 Abstract This document specifies two Application Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communications (WebRTC). The "webrtc" label identifies regular WebRTC communications: a DTLS session that is used establish keys for Secure Real-time Transport Protocol (SRTP) or to establish data channels using SCTP over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 6, 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 Thomson Expires November 6, 2016 [Page 1] Internet-Draft ALPN for WebRTC May 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2 2. ALPN Labels for WebRTC . . . . . . . . . . . . . . . . . . . 2 3. Media Confidentiality . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Web Real-Time Communications (WebRTC) [I-D.ietf-rtcweb-overview] uses Datagram Transport Layer Security (DTLS) [RFC6347] to secure all peer-to-peer communications. Identifying WebRTC protocol usage with Application Layer Protocol Negotiation (ALPN) [RFC7301] enables an endpoint to positively identify WebRTC uses and distinguish them from other DTLS uses. Different WebRTC uses can be advertised and behavior can be constrained to what is appropriate to a given use. In particular, this allows for the identification of sessions that require confidentiality protection from the application that manages the signaling for the session. 1.1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. ALPN Labels for WebRTC The following identifiers are defined for use in ALPN: webrtc: The DTLS session is used to establish keys for Secure Real- time Transport Protocol (SRTP) - known as DTLS-SRTP - as described Thomson Expires November 6, 2016 [Page 2] Internet-Draft ALPN for WebRTC May 2016 in [RFC5764]. The DTLS record layer is used for WebRTC data channels [I-D.ietf-rtcweb-data-channel]. c-webrtc: The DTLS session is used for confidential WebRTC communications, where peers agree to maintain the confidentiality of the media, as described in Section 3. The confidentiality protections ensure that media is protected from other applications, but the confidentiality protections do not extend to messages on data channels. Both identifiers describe the same basic protocol: a DTLS session that is used to provide keys for an SRTP session in combination with WebRTC data channels. Either SRTP or data channels could be absent. The data channels send Stream Control Transmission Protocol (SCTP) [RFC4960] over the DTLS record layer, which can be multiplexed with SRTP on the same UDP flow. WebRTC requires the use of Interactive Communication Establishment (ICE) [RFC5245] to establish the UDP flow, but this is not covered by the identifier. A more thorough definition of what WebRTC communications entail is included in [I-D.ietf-rtcweb-transports]. There is no functional difference between the identifiers except that an endpoint negotiating "c-webrtc" makes a promise to preserve the confidentiality of the media it receives. A peer that is not aware of whether it needs to request confidentiality can use either identifier. A peer in the client role MUST offer both identifiers if it is not aware of a need for confidentiality. A peer in the server role SHOULD select "webrtc" if it does not prefer either. An endpoint that requires media confidentiality might negotiate a session with a peer that does not support this specification. Endpoint MUST abort a session if it requires confidentiality but does not successfully negotiate "c-webrtc". A peer that is willing to accept "webrtc" SHOULD assume that a peer that does not support this specification has negotiated "webrtc" unless signaling provides other information; however, a peer MUST NOT assume that "c-webrtc" has been negotiated unless explicitly negotiated. 3. Media Confidentiality Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media [I-D.ietf-rtcweb-security-arch]. In this way, an application can establish a session that is end-to-end confidential, where the ends in question are user agents (or browsers) and not the signaling Thomson Expires November 6, 2016 [Page 3] Internet-Draft ALPN for WebRTC May 2016 application. This allows an application to manage signaling for a session, without having access to the media that is exchanged in the session. Without some form of indication that is securely bound to the session, a WebRTC endpoint is unable to properly distinguish between a session that requires this confidentiality protection and one that does not. The ALPN identifier provides that signal. A browser is required to enforce this confidentiality protection using isolation controls similar to those used in content cross- origin protections (see Section 5.3 [1] of [HTML5]). These protections ensure that media is protected from applications. Applications are not able to read or modify the contents of a protected flow of media. Media that is produced from a session using the "c-webrtc" identifier MUST only be displayed to users. The promise to apply confidentiality protections do not apply to data that is sent using data channels. Confidential data depends on having both data sources and consumers that are exclusively browser- or user-based. No mechanisms currently exist to take advantage of data confidentiality, though some use cases suggest that this could be useful, for example, confidential peer-to-peer file transfer. Alternative labels might be provided in future to support these use cases. This mechanism explicitly does not define a specific authentication method; a WebRTC endpoint that accepts a session with this ALPN identifier MUST respect confidentiality no matter what identity is attributed to a peer. RTP middleboxes and entities that forward media or data cannot promise to maintain confidentiality. Any entity that forwards content, or records content for later access by entities other than the authenticated peer, MUST NOT offer or accept a session with the "c-webrtc" identifier. 4. Security Considerations Confidential communications depends on more than just an agreement from browsers. Information is not confidential if it is displayed to those other than to whom it is intended. Peer authentication [I-D.ietf-rtcweb-security-arch] is necessary to ensure that data is only sent to the intended peer. Thomson Expires November 6, 2016 [Page 4] Internet-Draft ALPN for WebRTC May 2016 This is not a digital rights management mechanism. A user is not prevented from using other mechanisms to record or forward media. This means that (for example) screen recording devices, tape recorders, portable cameras, or a cunning arrangement of mirrors could variously be used to record or redistribute media once delivered. Similarly, if media is visible or audible (or otherwise accessible) to others in the vicinity, there are no technical measures that protect the confidentiality of that media. The only guarantee provided by this mechanism and the browser that implements it is that the media was delivered to the user that was authenticated. Individual users will still need to make a judgment about how their peer intends to respect the confidentiality of any information provided. On a shared computing platform like a browser, other entities with access to that platform (i.e., web applications), might be able to access information that would compromise the confidentiality of communications. Implementations MAY choose to limit concurrent access to input devices during confidential communications sessions. For instance, another application that is able to access a microphone might be able to sample confidential audio that is playing through speakers. This is true even if acoustic echo cancellation, which attempts to prevent this from happening, is used. Similarly, an application with access to a video camera might be able to use reflections to obtain all or part of a confidential video stream. 5. IANA Considerations The following two entries are added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]: webrtc: The "webrtc" label identifies mixed media and data communications using SRTP and data channels: Protocol: WebRTC Media and Data Identification Sequence: 0x77 0x65 0x62 0x72 0x74 0x63 ("webrtc") Specification: This document (RFCXXXX) c-webrtc: Thomson Expires November 6, 2016 [Page 5] Internet-Draft ALPN for WebRTC May 2016 The "c-webrtc" label identifies WebRTC communications with a promise to protect media confidentiality: Protocol: Confidential WebRTC Media and Data Identification Sequence: 0x63 0x2d 0x77 0x65 0x62 0x72 0x74 0x63 ("c-webrtc") Specification: This document (RFCXXXX) 6. References 6.1. Normative References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-11 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . 6.2. Informative References [HTML5] Berjon, R., Leithead, T., Doyle Navara, E., O'Connor, E., and S. Pfeiffer, "HTML 5", CR CR-html5-20121217, August 2010, . Thomson Expires November 6, 2016 [Page 6] Internet-Draft ALPN for WebRTC May 2016 [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-15 (work in progress), January 2016. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-12 (work in progress), March 2016. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . 6.3. URIs [1] http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#origin Author's Address Martin Thomson Mozilla 331 E Evelyn Street Mountain View, CA 94041 US Email: martin.thomson@gmail.com Thomson Expires November 6, 2016 [Page 7] ./draft-ietf-rtcweb-data-channel-13.txt0000644000764400076440000010730512452275625017177 0ustar iustyiusty Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto Expires: July 8, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences January 4, 2015 WebRTC Data Channels draft-ietf-rtcweb-data-channel-13.txt Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2015. Copyright Notice Copyright (c) 2015 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 Jesup, et al. Expires July 8, 2015 [Page 1] Internet-Draft WebRTC Data Channels January 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 4 3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 6 6. The Usage of SCTP for Data Channels . . . . . . . . . . . . . 8 6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8 6.2. SCTP Association Management . . . . . . . . . . . . . . . 9 6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Data Channel Definition . . . . . . . . . . . . . . . . . 10 6.5. Opening a Data Channel . . . . . . . . . . . . . . . . . 10 6.6. Transferring User Data on a Data Channel . . . . . . . . 11 6.7. Closing a Data Channel . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In the WebRTC framework, communication between the parties consists of media (for example audio and video) and non-media data. Media is sent using SRTP, and is not specified further here. Non-media data is handled by using SCTP [RFC4960] encapsulated in DTLS. DTLS 1.0 is defined in [RFC4347] and the present latest version, DTLS 1.2, is defined in [RFC6347]. Jesup, et al. Expires July 8, 2015 [Page 2] Internet-Draft WebRTC Data Channels January 2015 +----------+ | SCTP | +----------+ | DTLS | +----------+ | ICE/UDP | +----------+ Figure 1: Basic stack diagram The encapsulation of SCTP over DTLS (see [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) provides a NAT traversal solution together with confidentiality, source authentication, and integrity protected transfers. This data transport service operates in parallel to the SRTP media transports, and all of them can eventually share a single UDP port number. SCTP as specified in [RFC4960] with the partial reliability extension defined in [RFC3758] and the additional policies defined in [I-D.ietf-tsvwg-sctp-prpolicies] provides multiple streams natively with reliable, and the relevant partially-reliable delivery modes for user messages. Using the reconfiguration extension defined in [RFC6525] allows to increase the number of streams during the lifetime of an SCTP association and to reset individual SCTP streams. Using [I-D.ietf-tsvwg-sctp-ndata] allows to interleave large messages to avoid the monopolization and adds the support of prioritizing of SCTP streams. The remainder of this document is organized as follows: Section 3 and Section 4 provide use cases and requirements for both unreliable and reliable peer to peer data channels; Section 5 discusses SCTP over DTLS over UDP; Section 6 provides the specification of how SCTP should be used by the WebRTC protocol framework for transporting non- media data between WEB-browsers. 2. Conventions 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]. 3. Use Cases This section defines use cases specific to data channels. Please note that this section is informational only. Jesup, et al. Expires July 8, 2015 [Page 3] Internet-Draft WebRTC Data Channels January 2015 3.1. Use Cases for Unreliable Data Channels U-C 1: A real-time game where position and object state information is sent via one or more unreliable data channels. Note that at any time there may be no SRTP media channels, or all SRTP media channels may be inactive, and that there may also be reliable data channels in use. U-C 2: Providing non-critical information to a user about the reason for a state update in a video chat or conference, such as mute state. 3.2. Use Cases for Reliable Data Channels U-C 3: A real-time game where critical state information needs to be transferred, such as control information. Such a game may have no SRTP media channels, or they may be inactive at any given time, or may only be added due to in-game actions. U-C 4: Non-realtime file transfers between people chatting. Note that this may involve a large number of files to transfer sequentially or in parallel, such as when sharing a folder of images or a directory of files. U-C 5: Realtime text chat during an audio and/or video call with an individual or with multiple people in a conference. U-C 6: Renegotiation of the configuration of the PeerConnection. U-C 7: Proxy browsing, where a browser uses data channels of a PeerConnection to send and receive HTTP/HTTPS requests and data, for example to avoid local Internet filtering or monitoring. 4. Requirements This section lists the requirements for P2P data channels between two browsers. Please note that this section is informational only. Req. 1: Multiple simultaneous data channels must be supported. Note that there may be 0 or more SRTP media streams in parallel with the data channels in the same PeerConnection, and the number and state (active/inactive) of these SRTP media streams may change at any time. Req. 2: Both reliable and unreliable data channels must be supported. Jesup, et al. Expires July 8, 2015 [Page 4] Internet-Draft WebRTC Data Channels January 2015 Req. 3: Data channels of a PeerConnection must be congestion controlled; either individually, as a class, or in conjunction with the SRTP media streams of the PeerConnection, to ensure that data channels don't cause congestion problems for these SRTP media streams, and that the WebRTC PeerConnection does not cause excessive problems when run in parallel with TCP connections. Req. 4: The application should be able to provide guidance as to the relative priority of each data channel relative to each other, and relative to the SRTP media streams. This will interact with the congestion control algorithms. Req. 5: Data channels must be secured; allowing for confidentiality, integrity and source authentication. See [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch] for detailed info. Req. 6: Data channels must provide message fragmentation support such that IP-layer fragmentation can be avoided no matter how large a message the JavaScript application passes to be sent. It also must ensure that large data channel transfers don't unduly delay traffic on other data channels. Req. 7: The data channel transport protocol must not encode local IP addresses inside its protocol fields; doing so reveals potentially private information, and leads to failure if the address is depended upon. Req. 8: The data channel transport protocol should support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for such things as image-file- transfer; Implementations might enforce a reasonable message size limit. Req. 9: The data channel transport protocol should avoid IP fragmentation. It must support PMTU (Path MTU) discovery and must not rely on ICMP or ICMPv6 being generated or being passed back, especially for PMTU discovery. Req. 10: It must be possible to implement the protocol stack in the user application space. Jesup, et al. Expires July 8, 2015 [Page 5] Internet-Draft WebRTC Data Channels January 2015 5. SCTP over DTLS over UDP Considerations The important features of SCTP in the WebRTC context are: o Usage of a TCP-friendly congestion control. o The congestion control is modifiable for integration with the SRTP media stream congestion control. o Support of multiple unidirectional streams, each providing its own notion of ordered message delivery. o Support of ordered and out-of-order message delivery. o Supporting arbitrary large user messages by providing fragmentation and reassembly. o Support of PMTU-discovery. o Support of reliable or partially reliable message transport. The WebRTC Data Channel mechanism does not support SCTP multihoming. The SCTP layer will simply act as if it were running on a single- homed host, since that is the abstraction that the DTLS layer (a connection oriented, unreliable datagram service) exposes. The encapsulation of SCTP over DTLS defined in [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source authenticated, and integrity protected transfers. Using DTLS over UDP in combination with ICE enables middlebox traversal in IPv4 and IPv6 based networks. SCTP as specified in [RFC4960] MUST be used in combination with the extension defined in [RFC3758] and provides the following features for transporting non-media data between browsers: o Support of multiple unidirectional streams. o Ordered and unordered delivery of user messages. o Reliable and partial-reliable transport of user messages. Each SCTP user message contains a Payload Protocol Identifier (PPID) that is passed to SCTP by its upper layer on the sending side and provided to its upper layer on the receiving side. The PPID can be used to multiplex/demultiplex multiple upper layers over a single SCTP association. In the WebRTC context, the PPID is used to distinguish between UTF-8 encoded user data, binary encoded userdata and the Data Channel Establishment Protocol defined in Jesup, et al. Expires July 8, 2015 [Page 6] Internet-Draft WebRTC Data Channels January 2015 [I-D.ietf-rtcweb-data-protocol]. Please note that the PPID is not accessible via the Javascript API. The encapsulation of SCTP over DTLS, together with the SCTP features listed above satisfies all the requirements listed in Section 4. The layering of protocols for WebRTC is shown in the following Figure 2. +------+------+------+ | DCEP | UTF-8|Binary| | | data | data | +------+------+------+ | SCTP | +----------------------------------+ | STUN | SRTP | DTLS | +----------------------------------+ | ICE | +----------------------------------+ | UDP1 | UDP2 | UDP3 | ... | +----------------------------------+ Figure 2: WebRTC protocol layers This stack (especially in contrast to DTLS over SCTP [RFC6083] in combination with SCTP over UDP [RFC6951]) has been chosen because it o supports the transmission of arbitrary large user messages. o shares the DTLS connection with the SRTP media channels of the PeerConnection. o provides privacy for the SCTP control information. Considering the protocol stack of Figure 2 the usage of DTLS 1.0 over UDP is specified in [RFC4347] and the usage of DTLS 1.2 over UDP in specified in [RFC6347], while the usage of SCTP on top of DTLS is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done as described in Section 5.1.2 of [RFC5764] and SCTP is the only payload of DTLS. Since DTLS is typically implemented in user application space, the SCTP stack also needs to be a user application space stack. The ICE/UDP layer can handle IP address changes during a session without needing interaction with the DTLS and SCTP layers. However, SCTP SHOULD be notified when an address changes has happened. In this case SCTP SHOULD retest the Path MTU and reset the congestion Jesup, et al. Expires July 8, 2015 [Page 7] Internet-Draft WebRTC Data Channels January 2015 state to the initial state. In case of a window based congestion control like the one specified in [RFC4960], this means setting the congestion window and slow start threshold to its initial values. Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for IPv6. In general, the lower layer interface of an SCTP implementation should be adapted to address the differences between IPv4 and IPv6 (being connection-less) or DTLS (being connection-oriented). When the protocol stack of Figure 2 is used, DTLS protects the complete SCTP packet, so it provides confidentiality, integrity and source authentication of the complete SCTP packet. SCTP provides congestion control on a per-association base. This means that all SCTP streams within a single SCTP association share the same congestion window. Traffic not being sent over SCTP is not covered by the SCTP congestion control. Using a congestion control different from than the standard one might improve the impact on the parallel SRTP media streams. SCTP uses the same port number concept as TCP and UDP do. Therefore an SCTP association uses two port numbers, one at each SCTP end- point. 6. The Usage of SCTP for Data Channels 6.1. SCTP Protocol Considerations The DTLS encapsulation of SCTP packets as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. This SCTP stack and its upper layer MUST support the usage of multiple SCTP streams. A user message can be sent ordered or unordered and with partial or full reliability. The following SCTP protocol extensions are required: o The stream reconfiguration extension defined in [RFC6525] MUST be supported. It is used for closing channels. Jesup, et al. Expires July 8, 2015 [Page 8] Internet-Draft WebRTC Data Channels January 2015 o The dynamic address reconfiguration extension defined in [RFC5061] MUST be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL. o The partial reliability extension defined in [RFC3758] MUST be supported. In addition to the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. Limiting the number of retransmissions to zero combined with unordered delivery provides a UDP-like service where each user message is sent exactly once and delivered in the order received. The support for message interleaving as defined in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used. 6.2. SCTP Association Management In the WebRTC context, the SCTP association will be set up when the two endpoints of the WebRTC PeerConnection agree on opening it, as negotiated by JSEP (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. It will use the DTLS connection selected via ICE; typically this will be shared via BUNDLE or equivalent with DTLS connections used to key the SRTP media streams. The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during the association setup. SCTP supports two ways of terminating an SCTP association. A graceful one, using a procedure which ensures that no messages are lost during the shutdown of the association. The second method is a non-graceful one, where one side can just abort the association. Each SCTP end-point supervises continuously the reachability of its peer by monitoring the number of retransmissions of user messages and test messages. In case of excessive retransmissions, the association is terminated in a non-graceful way. If an SCTP association is closed in a graceful way, all of its data channels are closed. In case of a non-graceful teardown, all data channels are also closed, but an error indication SHOULD be provided if possible. 6.3. SCTP Streams SCTP defines a stream as a unidirectional logical channel existing within an SCTP association to another SCTP endpoint. The streams are used to provide the notion of in-sequence delivery and for Jesup, et al. Expires July 8, 2015 [Page 9] Internet-Draft WebRTC Data Channels January 2015 multiplexing. Each user message is sent on a particular stream, either ordered or unordered. Ordering is preserved only for ordered messages sent on the same stream. 6.4. Data Channel Definition Data channels are defined such that their accompanying application- level API can closely mirror the API for WebSockets, which implies bidirectional streams of data and a textual field called 'label' used to identify the meaning of the data channel. The realization of a data channel is a pair of one incoming stream and one outgoing SCTP stream having the same SCTP stream identifier. How these SCTP stream identifiers are selected is protocol and implementation dependent. This allows a bidirectional communication. Additionally, each data channel has the following properties in each direction: o reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream. o in-order or out-of-order message delivery for message sent. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream. o A priority, which is a 2 byte unsigned integer. These priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per the definition of the corresponding stream scheduler supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high") or 1024 ("extra high"). o an optional label. o an optional protocol. Please note that for a data channel being negotiated with the protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the above properties are the same in both directions. 6.5. Opening a Data Channel Data channels can be opened by using negotiation within the SCTP association, called in-band negotiation, or out-of-band negotiation. Out-of-band negotiation is defined as any method which results in an Jesup, et al. Expires July 8, 2015 [Page 10] Internet-Draft WebRTC Data Channels January 2015 agreement as to the parameters of a channel and the creation thereof. The details are out of scope of this document. Applications using data channels need to use the negotiation methods consistently on both end-points. A simple protocol for in-band negotiation is specified in [I-D.ietf-rtcweb-data-protocol]. When one side wants to open a channel using out-of-band negotiation, it picks a stream. Unless otherwise defined or negotiated, the streams are picked based on the DTLS role (the client picks even stream identifiers, the server odd stream identifiers). However, the application is responsible for avoiding collisions with existing streams. If it attempts to re-use a stream which is part of an existing data channel, the addition MUST fail. In addition to choosing a stream, the application SHOULD also determine the options to use for sending messages. The application MUST ensure in an application-specific manner that the application at the peer will also know the selected stream to be used, and the options for sending data from that side. 6.6. Transferring User Data on a Data Channel All data sent on a data channel in both directions MUST be sent over the underlying stream using the reliability defined when the data channel was opened unless the options are changed, or per-message options are specified by a higher level. The message-orientation of SCTP is used to preserve the message boundaries of user messages. Therefore, senders MUST NOT put more than one application message into an SCTP user message. Unless the deprecated PPID-based fragmentation and reassembly is used, the sender MUST include exactly one application message in each SCTP user message. The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the interpretation of the "Payload data". The following PPIDs MUST be used (see Section 8): WebRTC String: to identify a non-empty JavaScript string encoded in UTF-8. WebRTC String Empty: to identify an empty JavaScript string encoded in UTF-8. WebRTC Binary: to identify a non-empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob). Jesup, et al. Expires July 8, 2015 [Page 11] Internet-Draft WebRTC Data Channels January 2015 WebRTC Binary Empty: to identify an empty JavaScript binary data (ArrayBuffer, ArrayBufferView or Blob). SCTP does not support the sending of empty user messages. Therefore, if an empty message has to be sent, the appropriate PPID (WebRTC String Empty or WebRTC Binary Empty) is used and the SCTP user message of one zero byte is sent. When receiving an SCTP user message with one of these PPIDs, the receiver MUST ignore the SCTP user message and process it as an empty message. The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is deprecated. They were used for a PPID-based fragmentation and reassembly of user messages belonging to reliable and ordered data channels. If a message with an unsupported PPID is received or some error condition related to the received message is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel. This implies in particular that extensions using additional PPIDs can't be used without prior negotiation. The SCTP base protocol specified in [RFC4960] does not support the interleaving of user messages. Therefore sending a large user message can monopolize the SCTP association. To overcome this limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to support message interleaving, which SHOULD be used. As long as message interleaving is not supported, the sender SHOULD limit the maximum message size to 16 KB to avoid monopolization. It is recommended that the message size be kept within certain size bounds as applications will not be able to support arbitrarily-large single messages. This limit has to be negotiated, for example by using [I-D.ietf-mmusic-sctp-sdp]. The sender SHOULD disable the Nagle algorithm (see [RFC1122]) to minimize the latency. 6.7. Closing a Data Channel Closing of a data channel MUST be signaled by resetting the corresponding outgoing streams [RFC6525]. This means that if one side decides to close the data channel, it resets the corresponding outgoing stream. When the peer sees that an incoming stream was reset, it also resets its corresponding outgoing stream. Once this is completed, the data channel is closed. Resetting a stream sets the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a corresponding notification to the application layer that the reset Jesup, et al. Expires July 8, 2015 [Page 12] Internet-Draft WebRTC Data Channels January 2015 has been performed. Streams are available for reuse after a reset has been performed. [RFC6525] also guarantees that all the messages are delivered (or abandoned) before the stream is reset. 7. Security Considerations This document does not add any additional considerations to the ones given in [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. It should be noted that a receiver must be prepared that the sender tries to send arbitrary large messages. 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] This document uses six already registered SCTP Payload Protocol Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC Binary Empty". [RFC4960] creates the registry "SCTP Payload Protocol Identifiers" from which these identifiers were assigned. IANA is requested to update the reference of these six assignments to point to this document and change the names of the first four PPIDs. The corresponding dates should be kept. Therefore these six assignments should be updated to read: +-------------------------------+----------+-----------+------------+ | Value | SCTP | Reference | Date | | | PPID | | | +-------------------------------+----------+-----------+------------+ | WebRTC String | 51 | [RFCXXXX] | 2013-09-20 | | WebRTC Binary Partial | 52 | [RFCXXXX] | 2013-09-20 | | (Deprecated) | | | | | WebRTC Binary | 53 | [RFCXXXX] | 2013-09-20 | | WebRTC String Partial | 54 | [RFCXXXX] | 2013-09-20 | | (Deprecated) | | | | | WebRTC String Empty | 56 | [RFCXXXX] | 2014-08-22 | | WebRTC Binary Empty | 57 | [RFCXXXX] | 2014-08-22 | +-------------------------------+----------+-----------+------------+ Jesup, et al. Expires July 8, 2015 [Page 13] Internet-Draft WebRTC Data Channels January 2015 9. Acknowledgments Many thanks for comments, ideas, and text from Harald Alvestrand, Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer Dawkins, Gunnar Hellstrom, Christer Holmberg, Cullen Jennings, Paul Kyzivat, Eric Rescorla, Adam Roach, Irene Ruengeler, Randall Stewart, Martin Stiemerling, Justin Uberti, and Magnus Westerlund. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. Jesup, et al. Expires July 8, 2015 [Page 14] Internet-Draft WebRTC Data Channels January 2015 [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp- ndata-01 (work in progress), July 2014. [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-08 (work in progress), September 2014. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-07 (work in progress), December 2014. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-10 (work in progress), July 2014. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 (work in progress), October 2014. [I-D.ietf-tsvwg-sctp-prpolicies] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol", draft-ietf- tsvwg-sctp-prpolicies-06 (work in progress), December 2014. [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Loreto, S., and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf- mmusic-sctp-sdp-11 (work in progress), December 2014. 10.2. Informative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. Jesup, et al. Expires July 8, 2015 [Page 15] Internet-Draft WebRTC Data Channels January 2015 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011. [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, May 2013. Authors' Addresses Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 FI Email: salvatore.loreto@ericsson.com Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 DE Email: tuexen@fh-muenster.de Jesup, et al. Expires July 8, 2015 [Page 16] ./draft-ietf-rtcweb-data-protocol-09.txt0000644000764400076440000006737312452275542017445 0ustar iustyiusty Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto Expires: July 8, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences January 4, 2015 WebRTC Data Channel Establishment Protocol draft-ietf-rtcweb-data-protocol-09.txt Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 8, 2015. Copyright Notice Copyright (c) 2015 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 Jesup, et al. Expires July 8, 2015 [Page 1] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 8.2. New Standalone Registry for the DCEP . . . . . . . . . . 9 8.2.1. New Message Type Registry . . . . . . . . . . . . . . 9 8.2.2. New Channel Type Registry . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Data Channel Establishment Protocol (DCEP) is designed to provide, in the WebRTC Data Channel context [I-D.ietf-rtcweb-data-channel], a simple in-band method to open symmetric Data Channels. As discussed in [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transport Layer Security (DTLS) as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already standardized transport and security features. DTLS 1.0 is defined in [RFC4347] and the present latest version, DTLS 1.2, is defined in [RFC6347]. 2. Conventions 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]. Jesup, et al. Expires July 8, 2015 [Page 2] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 3. Terminology This document uses the following terms: Association: An SCTP association. Stream: A unidirectional stream of an SCTP association. It is uniquely identified by an SCTP stream identifier (0-65534). Note: the SCTP stream identifier 65535 is reserved due to SCTP INIT and INIT-ACK chunks only allowing a maximum of 65535 Streams to be negotiated (0-65534). Stream Identifier: The SCTP stream identifier uniquely identifying a Stream. Data Channel: Two Streams with the same Stream Identifier, one in each direction, which are managed together. 4. Protocol Overview The Data Channel Establishment Protocol is a simple, low-overhead way to establish bidirectional Data Channels over an SCTP association with a consistent set of properties. The set of consistent properties includes: o reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used. o in-order or out-of-order message delivery. o the priority of the Data Channel. o an optional label for the Data Channel. o an optional protocol for the Data Channel. o the Streams. This protocol uses a two way handshake to open a Data Channel. The handshake pairs one incoming and one outgoing Stream, both having the same Stream Identifier, into a single bidirectional Data Channel. The peer that initiates opening a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams are unused and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The peer responds with a DATA_CHANNEL_ACK message on its corresponding outgoing Stream. Then the Data Channel is open. Data Channel Establishment Protocol messages are sent on the same Stream Jesup, et al. Expires July 8, 2015 [Page 3] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 as the user messages belonging to the Data Channel. The demultiplexing is based on the SCTP payload protocol identifier (PPID), since the Data Channel Establishment Protocol uses a specific PPID. Note: The opening side MAY send user messages before the DATA_CHANNEL_ACK is received. To avoid collisions where both sides try to open a Data Channel with the same Stream Identifiers, each side MUST use Streams with either even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which side uses odd or even is based on the underlying DTLS connection role: the side acting as the DTLS client MUST use Streams with even Stream Identifiers, the side acting as the DTLS server MUST use Streams with odd Stream Identifiers. Note: There is no attempt to ensure uniqueness for the label; if both sides open a Data Channel labeled "x" at the same time, there will be two Data Channels labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation ("federation") by identifying the user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]), and may be useful for homogeneous applications which may create more than one type of Data Channel. Please note that there is also no attempt to ensure uniqueness for the protocol field. 5. Message Formats Every Data Channel Establishment Protocol message starts with a one byte field called "Message Type" which indicates the type of the message. The corresponding values are managed by IANA (see Section 8.2.1). 5.1. DATA_CHANNEL_OPEN Message This message is sent initially on the Stream used for user messages using the Data Channel. Jesup, et al. Expires July 8, 2015 [Page 4] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Channel Type | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability Parameter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Length | Protocol Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Label | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Protocol | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the DATA_CHANNEL_OPEN message. The value of this field is 0x03 as specified in Section 8.2.1. Channel Type: 1 byte (unsigned integer) This field specifies the type of the Data Channel to be opened and the values are managed by IANA (see Section 8.2.2): DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a reliable in-order bi-directional communication. DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides a reliable unordered bi-directional communication. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel provides a partially-reliable in-order bi-directional communication. User messages will not be retransmitted more times than specified in the Reliability Parameter. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The Data Channel provides a partial reliable unordered bi-directional communication. User messages will not be retransmitted more times than specified in the Reliability Parameter. DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The Data Channel provides a partial reliable in-order bi-directional communication. User messages might not be transmitted or retransmitted after a specified life-time given in milli- Jesup, et al. Expires July 8, 2015 [Page 5] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 seconds in the Reliability Parameter. This life-time starts when providing the user message to the protocol stack. DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The Data Channel provides a partial reliable unordered bi-directional communication. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the protocol stack. Priority: 2 bytes (unsigned integer) The priority of the Data Channel as described in [I-D.ietf-rtcweb-data-channel]. Reliability Parameter: 4 bytes (unsigned integer) For reliable Data Channels this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side. If a partial reliable Data Channel with limited number of retransmissions is used, this field specifies the number of retransmissions. If a partial reliable Data Channel with limited lifetime is used, this field specifies the maximum lifetime in milliseconds. The following table summarizes this: +------------------------------------------------+------------------+ | Channel Type | Reliability | | | Parameter | +------------------------------------------------+------------------+ | DATA_CHANNEL_RELIABLE | Ignored | | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | +------------------------------------------------+------------------+ Label Length: 2 bytes (unsigned integer) The length of the label field in bytes. Protocol Length: 2 bytes (unsigned integer) The length of the protocol field in bytes. Label: Variable Length (sequence of characters) The name of the Data Channel as a UTF-8 encoded string as specified in [RFC3629]. This may be an empty string. Protocol: Variable Length (sequence of characters) If this is an empty string the protocol is unspecified. If it is a non-empty string, it specifies a protocol registered in the Jesup, et al. Expires July 8, 2015 [Page 6] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This string is UTF-8 encoded as specified in [RFC3629]. 5.2. DATA_CHANNEL_ACK Message This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE message on the stream used for user messages using the Data Channel. Reception of this message tells the opener that the Data Channel setup handshake is complete. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the DATA_CHANNEL_ACK message. The value of this field is 0x02 as specified in Section 8.2.1. 6. Procedures All Data Channel Establishment Protocol messages MUST be sent using ordered delivery and reliable transmission. They MUST be sent on the same outgoing Stream as the user messages belonging to the corresponding Data Channel. Multiplexing and demultiplexing is done by using the SCTP payload protocol identifier (PPID). Therefore Data Channel Establishment Protocol message MUST be sent with the assigned PPID for the Data Channel Establishment Protocol (see Section 8.1). Other messages MUST NOT be sent using this PPID. The peer that initiates opening a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams are unused. If the side is the DTLS client, it MUST choose an even Stream Identifier, if the side is the DTLS server, it MUST choose an odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on the chosen Stream. If a DATA_CHANNEL_OPEN message is received on an unused Stream, the Stream Identifier corresponds to the role of the peer and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the Stream with the same Stream Identifier as the one the DATA_CHANNEL_OPEN message was received on. If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance if a DATA_CHANNEL_OPEN message is received on an Jesup, et al. Expires July 8, 2015 [Page 7] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 already used Stream or there are any problems with parameters within the DATA_CHANNEL_OPEN message, the odd/even rule is violated or the DATA_CHANNEL_OPEN message itself is not well-formed, the receiver MUST close the corresponding Data Channel using the procedure described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a DATA_CHANNEL_ACK message in response to the received message. Therefore, receiving an SCTP stream reset request for a Stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the Data Channel setup procedure. After also successfully resetting the corresponding outgoing Stream, which concludes the Data Channel closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be sent on the Stream. After the DATA_CHANNEL_OPEN message has been sent, the sender of the DATA_CHANNEL_OPEN MAY start sending messages containing user data without waiting for the reception of the corresponding DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK message or any other message has been received on a Data Channel, all other messages containing user data and belonging to this Data Channel MUST be sent ordered, no matter whether the Data Channel is ordered or not. After the DATA_CHANNEL_ACK or any other message has been received on the Data Channel, messages containing user data MUST be sent ordered on ordered Data Channels and MUST be sent unordered on unordered Data Channels. Therefore receiving a message containing user data on an unused Stream indicates an error. The corresponding Data Channel MUST be closed as described in [I-D.ietf-rtcweb-data-channel]. 7. Security Considerations The DATA_CHANNEL_OPEN messages contains two variable length fields: the protocol and the label. A receiver must be prepared to receive DATA_CHANNEL_OPEN messages where these field have the maximum length of 65535 bytes. Error cases like the use of inconsistent lengths fields, unknown parameter values or violation the odd/even rule must also be handled by closing the corresponding Data Channel. An end- point must also be prepared that the peer open the maximum number of Data Channels. This protocol does not provide privacy, integrity or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. For general considerations see [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. Jesup, et al. Expires July 8, 2015 [Page 8] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] IANA is asked to update the reference of an already existing SCTP PPID assignment (Section 8.1) and to create a new standalone registry with its own URL for the DCEP (Section 8.2) containing two new registration tables (Section 8.2.1 and Section 8.2.2). 8.1. SCTP Payload Protocol Identifier This document uses one already registered SCTP Payload Protocol Identifier (PPID) named "WebRTC Control". [RFC4960] creates the registry "SCTP Payload Protocol Identifiers" from which this identifier was assigned. IANA is requested to update the reference of this assignment to point to this document and to update the name. The corresponding date should be kept. Therefore this assignment should be updated to read: +-------------+-----------+-----------+------------+ | Value | SCTP PPID | Reference | Date | +-------------+-----------+-----------+------------+ | WebRTC DCEP | 50 | [RFCXXXX] | 2013-09-20 | +-------------+-----------+-----------+------------+ 8.2. New Standalone Registry for the DCEP IANA is requested to create a new standalone registry (aka a webpage) with its own URL for the Data Channel Establishment Protocol (DCEP). The title should be "Data Channel Establishment Protocol (DCEP) Parameters". It will contain the two tables as described in Section 8.2.1 and Section 8.2.2. 8.2.1. New Message Type Registry IANA is requested to create a new registration table "Message Type Registry" for the Data Channel Establishment Protocol (DCEP) to manage the one byte "Message Type" field in DCEP messages (see Section 5). This registration table should be part of the registry described in Section 8.2. Jesup, et al. Expires July 8, 2015 [Page 9] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new message type MUST contain the following information: 1. A name for the new message type; 2. A detailed procedural description of the use of messages with the new type within the operation of the Data Channel Establishment Protocol. Initially the following values need to be registered: +-------------------+-----------+-----------+ | Name | Type | Reference | +-------------------+-----------+-----------+ | Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | | Unassigned | 0x04-0xfe | | | Reserved | 0xff | [RFCXXXX] | +-------------------+-----------+-----------+ Please note that the values 0x00 and 0x01 are reserved to avoid interoperability problems, since they have been used in earlier versions of the document. The value 0xff has been reserved for future extensibility. The range of possible values is from 0x00 to 0xff. 8.2.2. New Channel Type Registry IANA is requested to create a new registration table "Channel Type Registry" for the Data Channel Establishment Protocol to manage the one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). This registration table should be part of the registry described in Section 8.2. The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new Channel Type MUST contain the following information: 1. A name for the new Channel Type; 2. A detailed procedural description of the user message handling for Data Channels using this new Channel Type. Jesup, et al. Expires July 8, 2015 [Page 10] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 Please note that if new Channel Types support ordered and unordered message delivery, the high order bit MUST be used to indicate whether the message delivery is unordered or not. Initially the following values need to be registered: +------------------------------------------------+------+-----------+ | Name | Type | Reference | +------------------------------------------------+------+-----------+ | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] | | Unassigned | rest | | +------------------------------------------------+------+-----------+ Please note that the values 0x7f and 0xff have been reserved for future extensibility. The range of possible values is from 0x00 to 0xff. 9. Acknowledgments The authors wish to thank Harald Alvestrand, Richard Barnes, Adam Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Haekansson, Cullen Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick, Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, Justin Uberti, and many others for their invaluable comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. Jesup, et al. Expires July 8, 2015 [Page 11] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-07 (work in progress), December 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. 10.2. Informational References [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-10 (work in progress), July 2014. Authors' Addresses Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 FI Email: salvatore.loreto@ericsson.com Jesup, et al. Expires July 8, 2015 [Page 12] Internet-Draft WebRTC Data Channel Establishment Protocol January 2015 Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 Steinfurt 48565 DE Email: tuexen@fh-muenster.de Jesup, et al. Expires July 8, 2015 [Page 13] ./draft-ietf-rtcweb-fec-10.txt0000644000764400076440000006506513513404121015400 0ustar iustyiusty Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track Jul 16, 2019 Expires: January 17, 2020 WebRTC Forward Error Correction Requirements draft-ietf-rtcweb-fec-10 Abstract This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 17, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Uberti Expires January 17, 2020 [Page 1] Internet-Draft WebRTC FEC Jul 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Types of FEC . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. Separate FEC Stream . . . . . . . . . . . . . . . . . . . 3 3.2. Redundant Encoding . . . . . . . . . . . . . . . . . . . 3 3.3. Codec-Specific In-band FEC . . . . . . . . . . . . . . . 3 4. FEC for Audio Content . . . . . . . . . . . . . . . . . . . . 4 4.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 4 4.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5 5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5 5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5 5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 6 6. FEC for Application Content . . . . . . . . . . . . . . . . . 6 7. Implementation Requirements . . . . . . . . . . . . . . . . . 7 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction In situations where packet loss is high, or perfect media quality is essential, Forward Error Correction (FEC) can be used to proactively recover from packet losses. This specification provides guidance on which FEC mechanisms to use, and how to use them, for WebRTC implementations. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Types of FEC FEC describes the sending of redundant information in an outgoing packet stream so that information can still be recovered even in the face of packet loss. There are multiple ways this can be Uberti Expires January 17, 2020 [Page 2] Internet-Draft WebRTC FEC Jul 2019 accomplished for RTP media streams [RFC3550]; this section enumerates the various mechanisms available and describes their tradeoffs. 3.1. Separate FEC Stream This approach, as described in [RFC5956], Section 4.3, sends FEC packets as an independent RTP stream with its own synchronization source (SSRC, [RFC3550]) and payload type, multiplexed with the primary encoding. While this approach can protect multiple packets of the primary encoding with a single FEC packet, each FEC packet will have its own IP+UDP+RTP+FEC header, and this overhead can be excessive in some cases, e.g., when protecting each primary packet with a FEC packet. This approach allows for recovery of entire RTP packets, including the full RTP header. 3.2. Redundant Encoding This approach, as described in [RFC2198], allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet. This redundant data may be an exact copy of a previous payload, or for codecs that support variable-bitrate encodings, possibly a smaller, lower-quality representation. In certain cases, the redundant data could include encodings of multiple prior audio frames. Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant data. However, this savings is only realized when the data all fits into a single packet (i.e. the size is less than a MTU). As a result, this approach is generally not useful for video content. As described in [RFC2198], Section 4, this approach cannot recover certain parts of the RTP header, including the marker bit, CSRC information, and header extensions. 3.3. Codec-Specific In-band FEC Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867], support their own in-band FEC mechanism, where redundant data is included in the codec payload. This is similar to the redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient. For Opus, audio frames deemed important are re-encoded at a lower bitrate and appended to the next payload, allowing partial recovery of a lost packet. This scheme is fairly efficient; experiments Uberti Expires January 17, 2020 [Page 3] Internet-Draft WebRTC FEC Jul 2019 performed indicate that when Opus FEC is used, the overhead imposed is only about 20-30%, depending on the amount of protection needed. Note that this mechanism can only carry redundancy information for the immediately preceding audio frame; as such the decoder cannot fully recover multiple consecutive lost packets, which can be a problem on wireless networks. See [RFC6716], Section 2.1.7, and this Opus mailing list post [OpusFEC] for more details. For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames. See [RFC4867], Section 3.7.1 for details on this mechanism. In-band FEC mechanisms cannot recover any of the RTP header. 4. FEC for Audio Content The following section provides guidance on how to best use FEC for transmitting audio data. As indicated in Section 8 below, FEC should only be activated if network conditions warrant it, or upon explicit application request. 4.1. Recommended Mechanism When using variable-bitrate codecs without an internal FEC, redundant encoding (as described in Section 3.2) with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED. This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding. When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against individual losses, with minimal overhead. Note that, as indicated above, the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned redundant encoding with reduced-bitrate Opus encodings SHOULD be used instead. When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism is RECOMMENDED. This provides slightly more efficient protection of the audio stream than redundant encoding. When using constant-bitrate codecs, e.g., PCMU [RFC5391], redundant encoding MAY be used, but this will result in a potentially significant bitrate increase, and suddenly increasing bitrate to deal with losses from congestion may actually make things worse. Uberti Expires January 17, 2020 [Page 4] Internet-Draft WebRTC FEC Jul 2019 Because of the lower packet rate of audio encodings, usually a single packet per frame, use of a separate FEC stream comes with a higher overhead than other mechanisms, and therefore is NOT RECOMMENDED. As mentioned above, the recommended mechanisms do not allow recovery of parts of the RTP header that may be important in certain audio applications, e.g., CSRCs and RTP header extensions like those specified in [RFC6464] and [RFC6465]. Implementations SHOULD account for this and attempt to approximate this information, using an approach similar to those described in [RFC2198], Section 4, and [RFC6464], Section 5. 4.2. Negotiating Support Support for redundant encoding of a given RTP stream SHOULD be indicated by including audio/red [RFC2198] as an additional supported media type for the associated m= section in the SDP offer [RFC3264]. Answerers can reject the use of redundant encoding by not including the audio/red media type in the corresponding m= section in the SDP answer. Support for codec-specific FEC mechanisms are typically indicated via "a=fmtp" parameters. For Opus, a receiver MUST indicate that it is prepared to use incoming FEC data with the "useinbandfec=1" parameter, as specified in [RFC7587]. This parameter is declarative and can be negotiated separately for either media direction. For AMR/AMR-WB, support for redundant encoding, and the maximum supported depth, are controlled by the 'max-red' parameter, as specified in [RFC4867], Section 8.1. Receivers MUST include this parameter, and set it to an appropriate value, as specified in [TS.26114], Table 6.3. 5. FEC for Video Content The following section provides guidance on how to best use FEC for transmitting video data. As indicated in Section 8 below, FEC should only be activated if network conditions warrant it, or upon explicit application request. 5.1. Recommended Mechanism Video frames, due to their size, often require multiple RTP packets. As discussed above, a separate FEC stream can protect multiple packets with a single FEC packet. In addition, the "flexfec" FEC mechanism described in [I-D.ietf-payload-flexible-fec-scheme] is also Uberti Expires January 17, 2020 [Page 5] Internet-Draft WebRTC FEC Jul 2019 capable of protecting multiple RTP streams via a single FEC stream, including all the streams that are part of a BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] group. As a result, for video content, use of a separate FEC stream with the flexfec RTP payload format is RECOMMENDED. To process the incoming FEC stream, the receiver can demultiplex it by SSRC, and then correlate it with the appropriate primary stream(s) via the CSRC(s) present in the RTP header of flexfec repair packets, or the SSRC field present in the FEC header of flexfec retransmission packets. 5.2. Negotiating Support Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1.2, as an additional supported media type for the associated m= section in the SDP offer [RFC3264]. As mentioned above, when BUNDLE is used, only a single flexfec repair stream will be created for each BUNDLE group, even if flexfec is negotiated for each primary stream. Answerers can reject the use of SSRC-multiplexed FEC, by not including the offered FEC formats in the corresponding m= section in the SDP answer. Use of FEC-only m-lines, and grouping using the SDP group mechanism as described in [RFC5956], Section 4.1 is not currently defined for WebRTC, and SHOULD NOT be offered. Answerers SHOULD reject any FEC-only m-lines, unless they specifically know how to handle such a thing in a WebRTC context (perhaps defined by a future version of the WebRTC specifications). 6. FEC for Application Content WebRTC also supports the ability to send generic application data, and provides transport-level retransmission mechanisms to support full and partial (e.g. timed) reliability. See [I-D.ietf-rtcweb-data-channel] for details. Because the application can control exactly what data to send, it has the ability to monitor packet statistics and perform its own application-level FEC, if necessary. As a result, this document makes no recommendations regarding FEC for the underlying data transport. Uberti Expires January 17, 2020 [Page 6] Internet-Draft WebRTC FEC Jul 2019 7. Implementation Requirements To support the functionality recommended above, implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support, as described in Section 4. Use of these formats when sending, as mentioned above, is RECOMMENDED. The general FEC mechanism described in [I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as mentioned in Section 5. Implementations MAY support additional FEC mechanisms if desired, e.g., [RFC5109]. 8. Adaptive Use of FEC Because use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used. This is in contrast to methods like RTX [RFC4588] or flexfec's retransmission mode ( [I-D.ietf-payload-flexible-fec-scheme], Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip and thereby increased media latency. Given this, WebRTC implementations SHOULD prefer using RTX or flexfec retransmissions instead of FEC when the connection RTT is within the application's latency budget, and otherwise SHOULD only transmit the amount of FEC needed to protect against the observed packet loss (which can be determined, e.g., by monitoring transmit packet loss data from RTCP Receiver Reports [RFC3550]), unless the application indicates it is willing to pay a quality penalty to proactively avoid losses. Note that when probing bandwidth, i.e., speculatively sending extra data to determine if additional link capacity exists, FEC data SHOULD be used as the additional data. Given that extra data is going to be sent regardless, it makes sense to have that data protect the primary payload; in addition, FEC can typically be applied in a way that increases bandwidth only modestly, which is necessary when probing. When using FEC with layered codecs, e.g., [RFC6386], where only base layer frames are critical to the decoding of future frames, implementations SHOULD only apply FEC to these base layer frames. Uberti Expires January 17, 2020 [Page 7] Internet-Draft WebRTC FEC Jul 2019 Finally, it should be noted that although applying redundancy is often useful in protecting a stream against packet loss, if the loss is caused by network congestion, the additional bandwidth used by the redundant data may actually make the situation worse, and can lead to significant degradation of the network. 9. Security Considerations In the WebRTC context, FEC is specifically concerned with recovering data from lost packets; any corrupted packets will be discarded by the SRTP [RFC3711] decryption process. Therefore, as described in [RFC3711], Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], which are enumerated in [RFC5764], Section 4.1.2. Additional security considerations for each individual FEC mechanism are enumerated in their respective documents. 10. IANA Considerations This document requires no actions from IANA. 11. Acknowledgements Several people provided significant input into this document, including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 12. References 12.1. Normative References [I-D.ietf-payload-flexible-fec-scheme] Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP Payload Format for Flexible Forward Error Correction (FEC)", draft-ietf-payload-flexible-fec-scheme-20 (work in progress), May 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Uberti Expires January 17, 2020 [Page 8] Internet-Draft WebRTC FEC Jul 2019 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007, . [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in the Session Description Protocol", RFC 5956, DOI 10.17487/RFC5956, September 2010, . [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TS.26114] 3GPP, "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction", 3GPP TS 26.114 15.0.0, September 2017. 12.2. Informative References [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. Uberti Expires January 17, 2020 [Page 9] Internet-Draft WebRTC FEC Jul 2019 [OpusFEC] Terriberry, T., "Opus FEC", January 2013. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, . [RFC5391] Sollaud, A., "RTP Payload Format for ITU-T Recommendation G.711.1", RFC 5391, DOI 10.17487/RFC5391, November 2008, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, . [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . Uberti Expires January 17, 2020 [Page 10] Internet-Draft WebRTC FEC Jul 2019 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- time Transport Protocol (RTP) Header Extension for Mixer- to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . Appendix A. Change log Changes in draft -10: o Additional editorial changes from IETF LC. Changes in draft -09: o Editorial changes from IETF LC. o Added new reference for Opus FEC. Changes in draft -08: o Switch to RFC 8174 boilerplate. Changes in draft -07: o Clarify how bandwidth management interacts with FEC. o Make 3GPP reference normative. Changes in draft -06: o Discuss how multiple streams can be protected by a single FlexFEC stream. o Discuss FEC for bandwidth probing. o Add note about recovery of RTP headers and header extensions. o Add note about FEC/SRTP ordering. o Clarify flexfec demux text, and mention retransmits. o Clarify text regarding offers/answers. o Make RFC2198 support SHOULD strength. Uberti Expires January 17, 2020 [Page 11] Internet-Draft WebRTC FEC Jul 2019 o Clean up references. Changes in draft -05: o No changes. Changes in draft -04: o Discussion of layered codecs. o Discussion of RTX. o Clarified implementation requirements. o FlexFEC MUST -> SHOULD. o Clarified AMR max-red handling. o Updated references. Changes in draft -03: o Added overhead stats for Opus. o Expanded discussion of multi-packet FEC for Opus. o Added discussion of AMR/AMR-WB. o Removed discussion of ssrc-group. o Referenced the data channel doc. o Referenced the RTP/RTCP RFC. o Several small edits based on feedback from Magnus. Changes in draft -02: o Expanded discussion of FEC-only m-lines, and how they should be handled in offers and answers. Changes in draft -01: o Tweaked abstract/intro text that was ambiguously normative. o Removed text on FEC for Opus in CELT mode. Uberti Expires January 17, 2020 [Page 12] Internet-Draft WebRTC FEC Jul 2019 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT RECOMMENDED, based on list feedback. o Explicitly called out application data as something not addressed in this document. o Updated flexible-fec reference. Changes in draft -00: o Initial version, from sidebar conversation at IETF 90. Author's Address Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Email: justin@uberti.name Uberti Expires January 17, 2020 [Page 13] ./draft-ietf-rtcweb-ip-handling-12.txt0000644000764400076440000006357013507015245017046 0ustar iustyiusty Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track July 2, 2019 Expires: January 3, 2020 WebRTC IP Address Handling Requirements draft-ietf-rtcweb-ip-handling-12 Abstract This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Uberti Expires January 3, 2020 [Page 1] Internet-Draft WebRTC IP Handling July 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5 6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 7 6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 7 6.2. Determining Associated Local Addresses . . . . . . . . . 7 7. Application Guidance . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction One of WebRTC's key features is its support of peer-to-peer connections. However, when establishing such a connection, which involves connection attempts from various IP addresses, WebRTC may allow a web application to learn additional information about the user compared to an application that only uses the Hypertext Transfer Protocol (HTTP) [RFC7230]. This may be problematic in certain cases. This document summarizes the concerns, and makes recommendations on how WebRTC implementations should best handle the tradeoff between privacy and media performance. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Problem Statement In order to establish a peer-to-peer connection, WebRTC implementations use Interactive Connectivity Establishment (ICE) [RFC8445], which attempts to discover multiple IP addresses using techniques such as Session Traversal Utilities for NAT (STUN) Uberti Expires January 3, 2020 [Page 2] Internet-Draft WebRTC IP Handling July 2019 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766], and then checks the connectivity of each local-address-remote-address pair in order to select the best one. The addresses that are collected usually consist of an endpoint's private physical or virtual addresses and its public Internet addresses. These addresses are provided to the web application so that they can be communicated to the remote endpoint for its checks. This allows the application to learn more about the local network configuration than it would from a typical HTTP scenario, in which the web server would only see a single public Internet address, i.e., the address from which the HTTP request was sent. The information revealed falls into three categories: 1. If the client is multihomed, additional public IP addresses for the client can be learned. In particular, if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple interfaces (a "split-tunnel" VPN), WebRTC can discover not only the public address for the VPN, but also the ISP public address over which the VPN is running. 2. If the client is behind a Network Address Translator (NAT), the client's private IP addresses, often [RFC1918] addresses, can be learned. 3. If the client is behind a proxy (a client-configured "classical application proxy", as defined in [RFC1919], Section 3), but direct access to the Internet is permitted, WebRTC's STUN checks will bypass the proxy and reveal the public IP address of the client. This concern also applies to the "enterprise TURN server" scenario described in [RFC7478], Section 2.3.5.1, if, as above, direct Internet access is permitted. However, when the term "proxy" is used in this document, it is always in reference to an [RFC1919] proxy server. Of these three concerns, the first is the most significant, because for some users, the purpose of using a VPN is for anonymity. However, different VPN users will have different needs, and some VPN users (e.g., corporate VPN users) may in fact prefer WebRTC to send media traffic directly, i.e., not through the VPN. The second concern is less significant but valid nonetheless. The core issue is that web applications can learn about addresses that are not exposed to the internet; typically these address are IPv4, but they can also be IPv6, as in the case of NAT64 [RFC6146]. While disclosure of the [RFC4941] IPv6 addresses recommended by Uberti Expires January 3, 2020 [Page 3] Internet-Draft WebRTC IP Handling July 2019 [I-D.ietf-rtcweb-transports] is fairly benign due to their intentionally short lifetimes, IPv4 addresses present some challenges. Although private IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a fairly common address), in the worst case, they can contain 24 bits of entropy with an indefinite lifetime. As such, they can be a fairly significant fingerprinting surface. In addition, intranet web sites can be attacked more easily when their IPv4 address range is externally known. Private IP addresses can also act as an identifier that allows web applications running in isolated browsing contexts (e.g., normal and private browsing) to learn that they are running on the same device. This could allow the application sessions to be correlated, defeating some of the privacy protections provided by isolation. It should be noted that private addresses are just one potential mechanism for this correlation and this is an area for further study. The third concern is the least common, as proxy administrators can already control this behavior through organizational firewall policy, and generally, forcing WebRTC traffic through a proxy server will have negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has provided similar functionality since the introduction of Real-Time Media Flow Protocol (RTMFP) support [RFC7016] in 2008. 4. Goals WebRTC's support of secure peer-to-peer connections facilitates deployment of decentralized systems, which can have privacy benefits. As a result, blunt solutions that disable WebRTC or make it significantly harder to use are undesirable. This document takes a more nuanced approach, with the following goals: o Provide a framework for understanding the problem so that controls might be provided to make different tradeoffs regarding performance and privacy concerns with WebRTC. o Using that framework, define settings that enable peer-to-peer communications, each with a different balance between performance and privacy. o Finally, provide recommendations for default settings that provide reasonable performance without also exposing addressing information in a way that might violate user expectations. Uberti Expires January 3, 2020 [Page 4] Internet-Draft WebRTC IP Handling July 2019 5. Detailed Design 5.1. Principles The key principles for our framework are stated below: 1. By default, WebRTC traffic should follow typical IP routing, i.e., WebRTC should use the same interface used for HTTP traffic, and only the system's 'typical' public addresses (or those of an enterprise TURN server, if present) should be visible to the application. However, in the interest of optimal media quality, it should be possible to enable WebRTC to make use of all network interfaces to determine the ideal route. 2. By default, WebRTC should be able to negotiate direct peer-to- peer connections between endpoints (i.e., without traversing a NAT or relay server) when such connections are possible. This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. 3. It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web applications learning such addresses. This document does not require this to be the default state, as there is no currently defined mechanism that can satisfy this requirement as well as the aforementioned requirement to allow direct peer-to-peer connections. 4. By default, WebRTC traffic should not be sent through proxy servers, due to the media quality problems associated with sending WebRTC traffic over TCP, which is almost always used when communicating with such proxies, as well as proxy performance issues that may result from proxying WebRTC's long-lived, high- bandwidth connections. However, it should be possible to force WebRTC to send its traffic through a configured proxy if desired. 5.2. Modes and Recommendations Based on these ideas, we define four specific modes of WebRTC behavior, reflecting different media quality/privacy tradeoffs: Mode 1: Enumerate all addresses: WebRTC MUST use all network interfaces to attempt communication with STUN servers, TURN servers, or peers. This will converge on the best media path, and is ideal when media performance is the highest priority, but it discloses the most information. Uberti Expires January 3, 2020 [Page 5] Internet-Draft WebRTC IP Handling July 2019 Mode 2: Default route + associated local addresses: WebRTC MUST follow the kernel routing table rules, which will typically cause media packets to take the same route as the application's HTTP traffic. If an enterprise TURN server is present, the preferred route MUST be through this TURN server. Once an interface has been chosen, the private IPv4 and IPv6 addresses associated with this interface MUST be discovered and provided to the application as host candidates. This ensures that direct connections can still be established in this mode. Mode 3: Default route only: This is the the same as Mode 2, except that the associated private addresses MUST NOT be provided; the only IP addresses gathered are those discovered via mechanisms like STUN and TURN (on the default route). This may cause traffic to hairpin through a NAT, fall back to an application TURN server, or fail altogether, with resulting quality implications. Mode 4: Force proxy: This is the same as Mode 3, but when the application's HTTP traffic is sent through a proxy, WebRTC media traffic MUST also be proxied. If the proxy does not support UDP (as is the case for all HTTP and most SOCKS [RFC1928] proxies), or the WebRTC implementation does not support UDP proxying, the use of UDP will be disabled, and TCP will be used to send and receive media through the proxy. Use of TCP will result in reduced media quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. Mode 1 MUST NOT be used unless user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia (device permissions) consent, described in [I-D.ietf-rtcweb-security-arch], Section 6.2. Alternatively, implementations can provide a specific mechanism to obtain user consent. In cases where user consent has not been obtained, Mode 2 SHOULD be used. These defaults provide a reasonable tradeoff that permits trusted WebRTC applications to achieve optimal network performance, but gives applications without consent (e.g., 1-way streaming or data channel applications) only the minimum information needed to achieve direct connections, as defined in Mode 2. However, implementations MAY choose stricter modes if desired, e.g., if a user indicates they want all WebRTC traffic to follow the default route. Uberti Expires January 3, 2020 [Page 6] Internet-Draft WebRTC IP Handling July 2019 Future documents may define additional modes and/or update the recommended default modes. Note that the suggested defaults can still be used even for organizations that want all external WebRTC traffic to traverse a proxy or enterprise TURN server, simply by setting an organizational firewall policy that allows WebRTC traffic to only leave through the proxy or TURN server. This provides a way to ensure the proxy or TURN server is used for any external traffic, but still allows direct connections (and, in the proxy case, avoids the performance issues associated with forcing media through said proxy) for intra- organization traffic. 6. Implementation Guidance This section provides guidance to WebRTC implementations on how to implement the policies described above. 6.1. Ensuring Normal Routing When trying to follow typical IP routing, as required by Modes 2 and 3, the simplest approach is to bind() the sockets used for peer-to- peer connections to the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC traffic the same way as it would HTTP traffic. STUN and TURN will work as usual, and host candidates can still be determined as mentioned below. 6.2. Determining Associated Local Addresses When binding to a wildcard address, some extra work is needed to determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same routing treatment). Use of the web application host as a destination ensures the right source address is selected, regardless of where the application resides (e.g., on an intranet). First, the appropriate remote IPv4/IPv6 address is obtained by resolving the host component of the web application URI [RFC3986]. If the client is behind a proxy and cannot resolve these IPs via DNS, the address of the proxy can be used instead. Or, if the web application was loaded from a file:// URI [RFC8089], rather than over the network, the implementation can fall back to a well-known DNS name or IP address. Once a suitable remote IP has been determined, the implementation can create a UDP socket, bind() it to the appropriate wildcard address, and then connect() to the remote IP. Generally, this results in the Uberti Expires January 3, 2020 [Page 7] Internet-Draft WebRTC IP Handling July 2019 socket being assigned a local address based on the kernel routing table, without sending any packets over the network. Finally, the socket can be queried using getsockname() or the equivalent to determine the appropriate local address. 7. Application Guidance The recommendations mentioned in this document may cause certain WebRTC applications to malfunction. In order to be robust in all scenarios, the following guidelines are provided for applications: o Applications SHOULD deploy a TURN server with support for both UDP and TCP connections to the server. This ensures that connectivity can still be established, even when Mode 3 or 4 are in use, assuming the TURN server can be reached. o Applications SHOULD detect when they don't have access to the full set of ICE candidates by checking for the presence of host candidates. If no host candidates are present, Mode 3 or 4 above is in use; this knowledge can be useful for diagnostic purposes. 8. Security Considerations This document describes several potential privacy and security concerns associated with WebRTC peer-to-peer connections, and provides mechanisms and recommendations for WebRTC implementations to address these concerns. 9. IANA Considerations This document requires no actions from IANA. 10. Acknowledgements Several people provided input into this document, including Bernard Aboba, Harald Alvestrand, Youenn Fablet, Ted Hardie, Matthew Kaufmann, Eric Rescorla, Adam Roach, and Martin Thomson. 11. References 11.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, . Uberti Expires January 3, 2020 [Page 8] Internet-Draft WebRTC IP Handling July 2019 [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, . [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, . [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 11.2. Informative References [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-17 (work in progress), October 2016. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, . Uberti Expires January 3, 2020 [Page 9] Internet-Draft WebRTC IP Handling July 2019 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, . [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013, . [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, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . Appendix A. Change log Changes in draft -12: o Editorial updates from IETF LC review. Changes in draft -11: o Editorial updates from AD review. Changes in draft -10: o Incorporate feedback from IETF 102 on the problem space. o Note that future versions of the document may define new modes. Changes in draft -09: o Fixed confusing text regarding enterprise TURN servers. Uberti Expires January 3, 2020 [Page 10] Internet-Draft WebRTC IP Handling July 2019 Changes in draft -08: o Discuss how enterprise TURN servers should be handled. Changes in draft -07: o Clarify consent guidance. Changes in draft -06: o Clarify recommendations. o Split implementation guidance into two sections. Changes in draft -05: o Separated framework definition from implementation techniques. o Removed RETURN references. o Use origin when determining local IPs, rather than a well-known IP. Changes in draft -04: o Rewording and cleanup in abstract, intro, and problem statement. o Added 2119 boilerplate. o Fixed weird reference spacing. o Expanded acronyms on first use. o Removed 8.8.8.8 mention. o Removed mention of future browser considerations. Changes in draft -03: o Clarified when to use which modes. o Added 2119 qualifiers to make normative statements. o Defined 'proxy'. o Mentioned split tunnels in problem statement. Changes in draft -02: Uberti Expires January 3, 2020 [Page 11] Internet-Draft WebRTC IP Handling July 2019 o Recommendations -> Requirements o Updated text regarding consent. Changes in draft -01: o Incorporated feedback from Adam Roach; changes to discussion of cam/mic permission, as well as use of proxies, and various editorial changes. o Added several more references. Changes in draft -00: o Published as WG draft. Author's Address Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Email: justin@uberti.name Uberti Expires January 3, 2020 [Page 12] ./draft-ietf-rtcweb-jsep-26.txt0000644000764400076440000076623213435634761015641 0ustar iustyiusty Network Working Group J. Uberti Internet-Draft Google Intended status: Standards Track C. Jennings Expires: August 31, 2019 Cisco E. Rescorla, Ed. Mozilla February 27, 2019 JavaScript Session Establishment Protocol draft-ietf-rtcweb-jsep-26 Abstract This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 31, 2019. Copyright Notice Copyright (c) 2019 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 (https://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 Uberti, et al. Expires August 31, 2019 [Page 1] Internet-Draft JSEP February 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 7 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 7 3.2. Session Descriptions and State Machine . . . . . . . . . 7 3.3. Session Description Format . . . . . . . . . . . . . . . 11 3.4. Session Description Control . . . . . . . . . . . . . . . 11 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 3.5.5. ICE Versions . . . . . . . . . . . . . . . . . . . . 16 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 20 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 24 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 25 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 25 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 25 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 26 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 27 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 28 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 30 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30 Uberti, et al. Expires August 31, 2019 [Page 2] Internet-Draft JSEP February 2019 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 31 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 34 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 35 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 5.1.2. Profile Names and Interoperability . . . . . . . . . 35 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 37 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 37 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 55 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 56 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 57 5.5. Processing a Local Description . . . . . . . . . . . . . 57 5.6. Processing a Remote Description . . . . . . . . . . . . . 58 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 58 5.8. Parsing a Session Description . . . . . . . . . . . . . . 59 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 60 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 61 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 64 5.9. Applying a Local Description . . . . . . . . . . . . . . 65 5.10. Applying a Remote Description . . . . . . . . . . . . . . 67 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 71 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 74 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 74 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 78 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 96 11.2. Informative References . . . . . . . . . . . . . . . . . 100 Uberti, et al. Expires August 31, 2019 [Page 3] Internet-Draft JSEP February 2019 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 103 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115 1. Introduction This document describes how the W3C WEBRTC RTCPeerConnection interface [W3C.webrtc] is used to control the setup, management and teardown of a multimedia session. 1.1. General Design of JSEP WebRTC call setup has been designed to focus on controlling the media plane, leaving signaling plane behavior up to the application as much as possible. The rationale is that different applications may prefer to use different protocols, such as the existing SIP call signaling protocol, or something custom to the particular application, perhaps for a novel use case. In this approach, the key information that needs to be exchanged is the multimedia session description, which specifies the necessary transport and media configuration information necessary to establish the media plane. With these considerations in mind, this document describes the JavaScript Session Establishment Protocol (JSEP) that allows for full control of the signaling state machine from JavaScript. As described above, JSEP assumes a model in which a JavaScript application executes inside a runtime containing WebRTC APIs (the "JSEP implementation"). The JSEP implementation is almost entirely divorced from the core signaling flow, which is instead handled by the JavaScript making use of two interfaces: (1) passing in local and remote session descriptions and (2) interacting with the ICE state machine. The combination of the JSEP implementation and the JavaScript application is referred to throughout this document as a "JSEP endpoint". In this document, the use of JSEP is described as if it always occurs between two JSEP endpoints. Note though in many cases it will actually be between a JSEP endpoint and some kind of server, such as a gateway or MCU. This distinction is invisible to the JSEP endpoint; it just follows the instructions it is given via the API. JSEP's handling of session descriptions is simple and straightforward. Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API. The application then uses that offer to set up its local config via the setLocalDescription() API. The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., Uberti, et al. Expires August 31, 2019 [Page 4] Internet-Draft JSEP February 2019 WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the initiator over the signaling channel. When the initiator gets that answer, it installs it using the setRemoteDescription() API, and initial setup is complete. This process can be repeated for additional offer/answer exchanges. Regarding ICE [RFC8445], JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain in the JSEP implementation, because only the implementation has the necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport. For instance, in traditional SIP, each offer or answer is self-contained, including both the session descriptions and the transport information. However, [I-D.ietf-mmusic-trickle-ice-sip] allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle], in which the session description can be sent immediately and the transport information can be sent when available. Sending transport information separately can allow for faster ICE and DTLS startup, since ICE checks can start as soon as any transport information is available rather than waiting for all of it. JSEP's decoupling of the ICE and signaling state machines allows it to accommodate either model. Through its abstraction of signaling, the JSEP approach does require the application to be aware of the signaling process. While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; said library would implement a given signaling protocol along with its state machine and serialization code, presenting a higher level call-oriented interface to the application developer. For example, libraries exist to adapt the JSEP API into an API suitable for a SIP or XMPP. Thus, JSEP provides greater control for the experienced developer without forcing any additional complexity on the novice developer. Uberti, et al. Expires August 31, 2019 [Page 5] Internet-Draft JSEP February 2019 1.2. Other Approaches Considered One approach that was considered instead of JSEP was to include a lightweight signaling protocol. Instead of providing session descriptions to the API, the API would produce and consume messages from this protocol. While providing a more high-level API, this put more control of signaling within the JSEP implementation, forcing it to have to understand and handle concepts like signaling glare (see [RFC3264], Section 4). A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component directly. This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented. In addition, these API points could be called in any order, resulting in a more complex set of interactions with the media subsystem than the JSEP approach, which specifies how session descriptions are to be evaluated and applied. One variation on JSEP that was considered was to keep the basic session description-oriented API, but to move the mechanism for generating offers and answers out of the JSEP implementation. Instead of providing createOffer/createAnswer methods within the implementation, this approach would instead expose a getCapabilities API which would provide the application with the information it needed in order to generate its own session descriptions. This increases the amount of work that the application needs to do; it needs to know how to generate session descriptions from capabilities, and especially how to generate the correct answer from an arbitrary offer and the supported capabilities. While this could certainly be addressed by using a library like the one mentioned above, it basically forces the use of said library even for a simple example. Providing createOffer/createAnswer avoids this problem. 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]. Uberti, et al. Expires August 31, 2019 [Page 6] Internet-Draft JSEP February 2019 3. Semantics and Syntax 3.1. Signaling Model JSEP does not specify a particular signaling model or state machine, other than the generic need to exchange session descriptions in the fashion described by [RFC3264] (offer/answer) in order for both sides of the session to know how to conduct the session. JSEP provides mechanisms to create offers and answers, as well as to apply them to a session. However, the JSEP implementation is totally decoupled from the actual mechanism by which these offers and answers are communicated to the remote side, including addressing, retransmission, forking, and glare handling. These issues are left entirely up to the application; the application has complete control over which offers and answers get handed to the implementation, and when. +-----------+ +-----------+ | Web App |<--- App-Specific Signaling -->| Web App | +-----------+ +-----------+ ^ ^ | SDP | SDP V V +-----------+ +-----------+ | JSEP |<----------- Media ------------>| JSEP | | Impl. | | Impl. | +-----------+ +-----------+ Figure 1: JSEP Signaling Model 3.2. Session Descriptions and State Machine In order to establish the media plane, the JSEP implementation needs specific parameters to indicate what to transmit to the remote side, as well as how to handle the media that is received. These parameters are determined by the exchange of session descriptions in offers and answers, and there are certain details to this process that must be handled in the JSEP APIs. Whether a session description applies to the local side or the remote side affects the meaning of that description. For example, the list of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative and the remote side MUST either accept them or reject Uberti, et al. Expires August 31, 2019 [Page 7] Internet-Draft JSEP February 2019 them altogether. An example of such a parameter is the DTLS fingerprints [RFC8122], which are calculated based on the local certificate(s) offered, and are not subject to negotiation. In addition, various RFCs put different conditions on the format of offers versus answers. For example, an offer may propose an arbitrary number of m= sections (i.e., media descriptions as described in [RFC4566], Section 5.14), but an answer must contain the exact same number as the offer. Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, the offerer may receive ICE checks, and possibly media (e.g., in the case of a re-offer after a connection has been established) before it receives an answer. To properly process incoming media in this case, the offerer's media handler must be aware of the details of the offer before the answer arrives. Therefore, in order to handle session descriptions properly, the JSEP implementation needs: 1. To know if a session description pertains to the local or remote side. 2. To know if a session description is an offer or an answer. 3. To allow the offer to be specified independently of the answer. JSEP addresses this by adding both setLocalDescription and setRemoteDescription methods and having session description objects contain a type field indicating the type of session description being supplied. This satisfies the requirements listed above for both the offerer, who first calls setLocalDescription(sdp [offer]) and then later setRemoteDescription(sdp [answer]), as well as for the answerer, who first calls setRemoteDescription(sdp [offer]) and then later setLocalDescription(sdp [answer]). During the offer/answer exchange, the outstanding offer is considered to be "pending" at the offerer and the answerer, as it may either be accepted or rejected. If this is a re-offer, each side will also have "current" local and remote descriptions, which reflect the result of the last offer/answer exchange. Sections Section 4.1.12, Section 4.1.14, Section 4.1.11, and Section 4.1.13, provide more detail on pending and current descriptions. JSEP also allows for an answer to be treated as provisional by the application. Provisional answers provide a way for an answerer to communicate initial session parameters back to the offerer, in order Uberti, et al. Expires August 31, 2019 [Page 8] Internet-Draft JSEP February 2019 to allow the session to begin, while allowing a final answer to be specified later. This concept of a final answer is important to the offer/answer model; when such an answer is received, any extra resources allocated by the caller can be released, now that the exact session configuration is known. These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup. Note that the final answer itself may be different than any received provisional answers. In [RFC3264], the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack level, a new offer can be generated at any point. For example, when using SIP for signaling, if one offer is sent, then cancelled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer. To support this, the JSEP media layer can provide an offer via the createOffer() method whenever the JavaScript application needs one for the signaling. The answerer can send back zero or more provisional answers, and finally end the offer-answer exchange by sending a final answer. The state machine for this is as follows: Uberti, et al. Expires August 31, 2019 [Page 9] Internet-Draft JSEP February 2019 setRemote(OFFER) setLocal(PRANSWER) /-----\ /-----\ | | | | v | v | +---------------+ | +---------------+ | | |----/ | |----/ | have- | setLocal(PRANSWER) | have- | | remote-offer |------------------- >| local-pranswer| | | | | | | | | +---------------+ +---------------+ ^ | | | | setLocal(ANSWER) | setRemote(OFFER) | | | V setLocal(ANSWER) | +---------------+ | | | | | |<---------------------------+ | stable | | |<---------------------------+ | | | +---------------+ setRemote(ANSWER) | ^ | | | | setLocal(OFFER) | setRemote(ANSWER) | | | V | +---------------+ +---------------+ | | | | | have- | setRemote(PRANSWER) |have- | | local-offer |------------------- >|remote-pranswer| | | | | | |----\ | |----\ +---------------+ | +---------------+ | ^ | ^ | | | | | \-----/ \-----/ setLocal(OFFER) setRemote(PRANSWER) Figure 2: JSEP State Machine Aside from these state transitions there is no other difference between the handling of provisional ("pranswer") and final ("answer") answers. Uberti, et al. Expires August 31, 2019 [Page 10] Internet-Draft JSEP February 2019 3.3. Session Description Format JSEP's session descriptions use SDP syntax for their internal representation. While this format is not optimal for manipulation from JavaScript, it is widely accepted, and frequently updated with new features; any alternate encoding of session descriptions would have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP. If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls as opaque blobs; that is, the application will not need to read or change them. 3.4. Session Description Control In order to give the application control over various common session parameters, JSEP provides control surfaces which tell the JSEP implementation how to generate session descriptions. This avoids the need for JavaScript to modify session descriptions in most cases. Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/Answer calls. 3.4.1. RtpTransceivers RtpTransceivers allow the application to control the RTP media associated with one m= section. Each RtpTransceiver has an RtpSender and an RtpReceiver, which an application can use to control the sending and receiving of RTP media. The application may also modify the RtpTransceiver directly, for instance, by stopping it. RtpTransceivers generally have a 1:1 mapping with m= sections, although there may be more RtpTransceivers than m= sections when RtpTransceivers are created but not yet associated with a m= section, or if RtpTransceivers have been stopped and disassociated from m= sections. An RtpTransceiver is said to be associated with an m= section if its mid property is non-null; otherwise it is said to be disassociated. The associated m= section is determined using a mapping between transceivers and m= section indices, formed when creating an offer or applying a remote offer. Uberti, et al. Expires August 31, 2019 [Page 11] Internet-Draft JSEP February 2019 An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. However, in certain cases where a m= section has been rejected, as discussed in Section 5.2.2 below, that m= section will be "recycled" and associated with a new RtpTransceiver with a new mid value. RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds new m= sections. 3.4.2. RtpSenders RtpSenders allow the application to control how RTP media is sent. An RtpSender is conceptually responsible for the outgoing RTP stream(s) described by an m= section. This includes encoding the attached MediaStreamTrack, sending RTP media packets, and generating/ processing RTCP for the outgoing RTP streams(s). 3.4.3. RtpReceivers RtpReceivers allow the application to inspect how RTP media is received. An RtpReceiver is conceptually responsible for the incoming RTP stream(s) described by an m= section. This includes processing received RTP media packets, decoding the incoming stream(s) to produce a remote MediaStreamTrack, and generating/ processing RTCP for the incoming RTP stream(s). 3.5. ICE 3.5.1. ICE Gathering Overview JSEP gathers ICE candidates as needed by the application. Collection of ICE candidates is referred to as a gathering phase, and this is triggered either by the addition of a new or recycled m= section to the local session description, or new ICE credentials in the description, indicating an ICE restart. Use of new ICE credentials can be triggered explicitly by the application, or implicitly by the JSEP implementation in response to changes in the ICE configuration. When the ICE configuration changes in a way that requires a new gathering phase, a 'needs-ice-restart' bit is set. When this bit is set, calls to the createOffer API will generate new ICE credentials. This bit is cleared by a call to the setLocalDescription API with new ICE credentials from either an offer or an answer, i.e., from either a local- or remote-initiated ICE restart. Uberti, et al. Expires August 31, 2019 [Page 12] Internet-Draft JSEP February 2019 When a new gathering phase starts, the ICE agent will notify the application that gathering is occurring through an event. Then, when each new ICE candidate becomes available, the ICE agent will supply it to the application via an additional event; these candidates will also automatically be added to the current and/or pending local session description. Finally, when all candidates have been gathered, an event will be dispatched to signal that the gathering process is complete. Note that gathering phases only gather the candidates needed by new/recycled/restarting m= sections; other m= sections continue to use their existing candidates. Also, if an m= section is bundled (either by a successful bundle negotiation or by being marked as bundle-only), then candidates will be gathered and exchanged for that m= section if and only if its MID is a BUNDLE-tag, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. 3.5.2. ICE Candidate Trickling Candidate trickling is a technique through which a caller may incrementally provide candidates to the callee after the initial offer has been dispatched; the semantics of "Trickle ICE" are defined in [I-D.ietf-ice-trickle]. This process allows the callee to begin acting upon the call and setting up the ICE (and perhaps DTLS) connections immediately, without having to wait for the caller to gather all possible candidates. This results in faster media setup in cases where gathering is not performed prior to initiating the call. JSEP supports optional candidate trickling by providing APIs, as described above, that provide control and feedback on the ICE candidate gathering process. Applications that support candidate trickling can send the initial offer immediately and send individual candidates when they get the notified of a new candidate; applications that do not support this feature can simply wait for the indication that gathering is complete, and then create and send their offer, with all the candidates, at this time. Upon receipt of trickled candidates, the receiving application will supply them to its ICE agent. This triggers the ICE agent to start using the new remote candidates for connectivity checks. 3.5.2.1. ICE Candidate Format In JSEP, ICE candidates are abstracted by an IceCandidate object, and as with session descriptions, SDP syntax is used for the internal representation. Uberti, et al. Expires August 31, 2019 [Page 13] Internet-Draft JSEP February 2019 The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. Note that this field does not contain an "a=" prefix, as indicated in the following example: candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts. If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. The IceCandidate object also contains fields to indicate which m= section it is associated with, which can be identified in one of two ways, either by a m= section index, or a MID. The m= section index is a zero-based index, with index N referring to the N+1th m= section in the session description referenced by this IceCandidate. The MID is a "media stream identification" value, as defined in [RFC5888], Section 4, which provides a more robust way to identify the m= section in the session description, using the MID of the associated RtpTransceiver object (which may have been locally generated by the answerer when interacting with a non-JSEP endpoint that does not support the MID attribute, as discussed in Section 5.10 below). If the MID field is present in a received IceCandidate, it MUST be used for identification; otherwise, the m= section index is used instead. When creating an IceCandidate object, JSEP implementations MUST populate each of the candidate, ufrag, m= section index, and MID fields. Implementations MUST also be prepared to receive objects with some fields missing, as mentioned above. 3.5.3. ICE Candidate Policy Typically, when gathering ICE candidates, the JSEP implementation will gather all possible forms of initial candidates - host, server reflexive, and relay. However, in certain cases, applications may want to have more specific control over the gathering process, due to privacy or related concerns. For example, one may want to only use relay candidates, to leak as little location information as possible (keeping in mind that this choice comes with corresponding operational costs). To accomplish this, JSEP allows the application Uberti, et al. Expires August 31, 2019 [Page 14] Internet-Draft JSEP February 2019 to restrict which ICE candidates are used in a session. Note that this filtering is applied on top of any restrictions the implementation chooses to enforce regarding which IP addresses are permitted for the application, as discussed in [I-D.ietf-rtcweb-ip-handling]. There may also be cases where the application wants to change which types of candidates are used while the session is active. A prime example is where a callee may initially want to use only relay candidates, to avoid leaking location information to an arbitrary caller, but then change to use all candidates (for lower operational cost) once the user has indicated they want to take the call. For this scenario, the JSEP implementation MUST allow the candidate policy to be changed in mid-session, subject to the aforementioned interactions with local policy. To administer the ICE candidate policy, the JSEP implementation will determine the current setting at the start of each gathering phase. Then, during the gathering phase, the implementation MUST NOT expose candidates disallowed by the current policy to the application, use them as the source of connectivity checks, or indirectly expose them via other fields, such as the raddr/rport attributes for other ICE candidates. Later, if a different policy is specified by the application, the application can apply it by kicking off a new gathering phase via an ICE restart. 3.5.4. ICE Candidate Pool JSEP applications typically inform the JSEP implementation to begin ICE gathering via the information supplied to setLocalDescription, as the local description indicates the number of ICE components which will be needed and for which candidates must be gathered. However, to accelerate cases where the application knows the number of ICE components to use ahead of time, it may ask the implementation to gather a pool of potential ICE candidates to help ensure rapid media setup. When setLocalDescription is eventually called, and the JSEP implementation goes to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool. If there are candidates in the pool, they SHOULD be handed to the application immediately via the ICE candidate event. If the pool becomes depleted, either because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual. This only occurs for the first offer/answer exchange, after which the candidate pool is emptied and no longer used. Uberti, et al. Expires August 31, 2019 [Page 15] Internet-Draft JSEP February 2019 One example of where this concept is useful is an application that expects an incoming call at some point in the future, and wants to minimize the time it takes to establish connectivity, to avoid clipping of initial media. By pre-gathering candidates into the pool, it can exchange and start sending connectivity checks from these candidates almost immediately upon receipt of a call. Note though that by holding on to these pre-gathered candidates, which will be kept alive as long as they may be needed, the application will consume resources on the STUN/TURN servers it is using. 3.5.5. ICE Versions While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one. Implementations MUST be able to accept remote descriptions that do not have the "ice2" attribute. 3.6. Video Size Negotiation Video size negotiation is the process through which a receiver can use the "a=imageattr" SDP attribute [RFC6236] to indicate what video frame sizes it is capable of receiving. A receiver may have hard limits on what its video decoder can process, or it may have some maximum set by policy. By specifying these limits in an "a=imageattr" attribute, JSEP endpoints can attempt to ensure that the remote sender transmits video at an acceptable resolution. However, when communicating with a non-JSEP endpoint that does not understand this attribute, any signaled limits may be exceeded, and the JSEP implementation MUST handle this gracefully, e.g., by discarding the video. Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels). JSEP implementations will not transmit non-square pixels, but SHOULD receive and render such video with the correct aspect ratio. However, sample aspect ratio has no impact on the size negotiation described below; all dimensions are measured in pixels, whether square or not. 3.6.1. Creating an imageattr Attribute The receiver will first intersect any known local limits (e.g., hardware decoder capababilities, local policy) to determine the absolute minimum and maximum sizes it can receive. If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. Uberti, et al. Expires August 31, 2019 [Page 16] Internet-Draft JSEP February 2019 If these local limits preclude receiving any video, i.e., the degenerate case of no permitted resolutions, the "a=imageattr" attribute MUST be omitted, and the m= section MUST be marked as sendonly/inactive, as appropriate. Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed from the aforementioned intersection is used to specify its minimum and maximum x= and y= values. The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important. It SHOULD be set to 1.0. The "a=imageattr" field is payload type specific. When all video codecs supported have the same capabilities, use of a single attribute, with the wildcard payload type (*), is RECOMMENDED. However, when the supported video codecs have different limitations, specific "a=imageattr" attributes MUST be inserted for each payload type. As an example, consider a system with a multiformat video decoder, which is capable of decoding any resolution from 48x48 to 720p, In this case, the implementation would generate this attribute: a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] This declaration indicates that the receiver is capable of decoding any image resolution from 48x48 up to 1280x720 pixels. 3.6.2. Interpreting imageattr Attributes [RFC6236] defines "a=imageattr" to be an advisory field. This means that it does not absolutely constrain the video formats that the sender can use, but gives an indication of the preferred values. This specification prescribes more specific behavior. When a MediaStreamTrack, which is producing video of a certain resolution (the "track resolution"), is attached to a RtpSender, which is encoding the track video at the same or lower resolution(s) (the "encoder resolutions"), and a remote description is applied that references the sender and contains valid "a=imageattr recv" attributes, it MUST follow the rules below to ensure the sender does not transmit a resolution that would exceed the size criteria specified in the attributes. These rules MUST be followed as long as the attributes remain present in the remote description, including cases in which the track changes its resolution, or is replaced with a different track. Uberti, et al. Expires August 31, 2019 [Page 17] Internet-Draft JSEP February 2019 Depending on how the RtpSender is configured, it may be producing a single encoding at a certain resolution, or, if simulcast Section 3.7 has been negotiated, multiple encodings, each at their own specific resolution. In addition, depending on the configuration, each encoding may have the flexibility to reduce resolution when needed, or may be locked to a specific output resolution. For each encoding being produced by the RtpSender, the set of "a=imageattr recv" attributes in the corresponding m= section of the remote description is processed to determine what should be transmitted. Only attributes that reference the media format selected for the encoding are considered; each such attribute is evaluated individually, starting with the attribute with the highest "q=" value. If multiple attributes have the same "q=" value, they are evaluated in the order they appear in their containing m= section. Note that while JSEP endpoints will include at most one "a=imageattr recv" attribute per media format, JSEP endpoints may receive session descriptions from non-JSEP endpoints with m= sections that contain multiple such attributes. For each "a=imageattr recv" attribute, the following rules are applied. If this processing is successful, the encoding is transmitted accordingly, and no further attributes are considered for that encoding. Otherwise, the next attribute is evaluated, in the aforementioned order. If none of the supplied attributes can be processed successfully, the encoding MUST NOT be transmitted, and an error SHOULD be raised to the application. o The limits from the attribute are compared to the encoder resolution. Only the specific limits mentioned below are considered; any other values, such as picture aspect ratio, MUST be ignored. When considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used for the checks. This is required regardless of whether the receiver supports performing receive-side rotation (e.g., through CVO [TS26.114]), as it significantly simplifies the matching logic. o If the attribute includes a "sar=" (sample aspect ratio) value set to something other than "1.0", indicating the receiver wants to receive non-square pixels, this cannot be satisfied and the attribute MUST NOT be used. o If the encoder resolution exceeds the maximum size permitted by the attribute, and the encoder is allowed to adjust its resolution, the encoder SHOULD apply downscaling in order to satisfy the limits. Downscaling MUST NOT change the picture aspect ratio of the encoding, ignoring any trivial differences due to rounding. For example, if the encoder resolution is 1280x720, Uberti, et al. Expires August 31, 2019 [Page 18] Internet-Draft JSEP February 2019 and the attribute specified a maximum of 640x480, the expected output resolution would be 640x360. If downscaling cannot be applied, the attribute MUST NOT be used. o If the encoder resolution is less than the minimum size permitted by the attribute, the attribute MUST NOT be used; the encoder MUST NOT apply upscaling. JSEP implementations SHOULD avoid this situation by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. o If the encoder resolution is within the maximum and minimum sizes, no action is needed. 3.7. Simulcast JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding. This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. Applications request support for simulcast by configuring multiple encodings on an RtpSender. Upon generation of an offer or answer, these encodings are indicated via SDP markings on the corresponding m= section, as described below. Receivers that understand simulcast and are willing to receive it will also include SDP markings to indicate their support, and JSEP endpoints will use these markings to determine whether simulcast is permitted for a given RtpSender. If simulcast support is not negotiated, the RtpSender will only use the first configured encoding. Note that the exact simulcast parameters are up to the sending application. While the aforementioned SDP markings are provided to ensure the remote side can receive and demux multiple simulcast encodings, the specific resolutions and bitrates to be used for each encoding are purely a send-side decision in JSEP. JSEP currently does not provide a mechanism to configure receipt of simulcast. This means that if simulcast is offered by the remote endpoint, the answer generated by a JSEP endpoint will not indicate support for receipt of simulcast, and as such the remote endpoint will only send a single encoding per m= section. In addition, JSEP does not provide a mechanism to handle an incoming offer requesting simulcast from the JSEP endpoint. This means that setting up simulcast in the case where the JSEP endpoint receives the Uberti, et al. Expires August 31, 2019 [Page 19] Internet-Draft JSEP February 2019 initial offer requires out-of-band signaling or SDP inspection. However, in the case where the JSEP endpoint sets up simulcast in its in initial offer, any established simulcast streams will continue to work upon receipt of an incoming re-offer. Future versions of this specification may add additional APIs to handle the incoming initial offer scenario. When using JSEP to transmit multiple encodings from a RtpSender, the techniques from [I-D.ietf-mmusic-sdp-simulcast] and [I-D.ietf-mmusic-rid] are used. Specifically, when multiple encodings have been configured for a RtpSender, the m= section for the RtpSender will include an "a=simulcast" attribute, as defined in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2, with a "send" simulcast stream description that lists each desired encoding, and no "recv" simulcast stream description. The m= section will also include an "a=rid" attribute for each encoding, as specified in [I-D.ietf-mmusic-rid], Section 4; the use of RID identifiers allows the individual encodings to be disambiguated even though they are all part of the same m= section. 3.8. Interactions With Forking Some call signaling systems allow various types of forking where an SDP Offer may be provided to more than one device. For example, SIP [RFC3261] defines both a "Parallel Search" and "Sequential Search". Although these are primarily signaling level issues that are outside the scope of JSEP, they do have some impact on the configuration of the media plane that is relevant. When forking happens at the signaling layer, the JavaScript application responsible for the signaling needs to make the decisions about what media should be sent or received at any point of time, as well as which remote endpoint it should communicate with; JSEP is used to make sure the media engine can make the RTP and media perform as required by the application. The basic operations that the applications can have the media engine do are: o Start exchanging media with a given remote peer, but keep all the resources reserved in the offer. o Start exchanging media with a given remote peer, and free any resources in the offer that are not being used. 3.8.1. Sequential Forking Sequential forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, but only one active session ever exists at a time; no mixing of received media is performed. Uberti, et al. Expires August 31, 2019 [Page 20] Internet-Draft JSEP February 2019 JSEP handles sequential forking well, allowing the application to easily control the policy for selecting the desired remote endpoint. When an answer arrives from one of the callees, the application can choose to apply it either as a provisional answer, leaving open the possibility of using a different answer in the future, or apply it as a final answer, ending the setup flow. In a "first-one-wins" situation, the first answer will be applied as a final answer, and the application will reject any subsequent answers. In SIP parlance, this would be ACK + BYE. In a "last-one-wins" situation, all answers would be applied as provisional answers, and any previous call leg will be terminated. At some point, the application will end the setup process, perhaps with a timer; at this point, the application could reapply the pending remote description as a final answer. 3.8.2. Parallel Forking Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple simultaneous active signaling sessions can be established as a result. If multiple callees send media at the same time, the possibilities for handling this are described in [RFC3960], Section 3.1. Most SIP devices today only support exchanging media with a single device at a time, and do not try to mix multiple early media audio sources, as that could result in a confusing situation. For example, consider having a European ringback tone mixed together with the North American ringback tone - the resulting sound would not be like either tone, and would confuse the user. If the signaling application wishes to only exchange media with one of the remote endpoints at a time, then from a media engine point of view, this is exactly like the sequential forking case. In the parallel forking case where the JavaScript application wishes to simultaneously exchange media with multiple peers, the flow is slightly more complex, but the JavaScript application can follow the strategy that [RFC3960] describes using UPDATE. The UPDATE approach allows the signaling to set up a separate media flow for each peer that it wishes to exchange media with. In JSEP, this offer used in the UPDATE would be formed by simply creating a new PeerConnection (see Section 4.1) and making sure that the same local media streams have been added into this new PeerConnection. Then the new PeerConnection object would produce a SDP offer that could be used by the signaling to perform the UPDATE strategy discussed in [RFC3960]. As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote Uberti, et al. Expires August 31, 2019 [Page 21] Internet-Draft JSEP February 2019 description and their own local and remote addresses. The media flow from these sessions can be managed using setDirection (see Section 4.2.3), or the application can choose to play out the media from all sessions mixed together. Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs. 4. Interface This section details the basic operations that must be present to implement JSEP functionality. The actual API exposed in the W3C API may have somewhat different syntax, but should map easily to these concepts. 4.1. PeerConnection 4.1.1. Constructor The PeerConnection constructor allows the application to specify global parameters for the media session, such as the STUN/TURN servers and credentials to use when gathering candidates, as well as the initial ICE candidate policy and pool size, and also the bundle policy to use. If an ICE candidate policy is specified, it functions as described in Section 3.5.3, causing the JSEP implementation to only surface the permitted candidates (including any implementation-internal filtering) to the application, and only use those candidates for connectivity checks. The set of available policies is as follows: all: All candidates permitted by implementation policy will be gathered and used. relay: All candidates except relay candidates will be filtered out. This obfuscates the location information that might be ascertained by the remote peer from the received candidates. Depending on how the application deploys and chooses relay servers, this could obfuscate location to a metro or possibly even global level. The default ICE candidate policy MUST be set to "all" as this is generally the desired policy, and also typically reduces use of application TURN server resources significantly. If a size is specified for the ICE candidate pool, this indicates the number of ICE components to pre-gather candidates for. Because pre- gathering results in utilizing STUN/TURN server resources for Uberti, et al. Expires August 31, 2019 [Page 22] Internet-Draft JSEP February 2019 potentially long periods of time, this must only occur upon application request, and therefore the default candidate pool size MUST be zero. The application can specify its preferred policy regarding use of bundle, the multiplexing mechanism defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the application will always try to negotiate bundle onto a single transport, and will offer a single bundle group across all m= sections; use of this single transport is contingent upon the answerer accepting bundle. However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to bundle media streams together, which affects how it will interoperate with a non-bundle-aware endpoint. When negotiating with a non-bundle-aware endpoint, only the streams not marked as bundle- only streams will be established. The set of available policies is as follows: balanced: The first m= section of each type (audio, video, or application) will contain transport parameters, which will allow an answerer to unbundle that section. The second and any subsequent m= section of each type will be marked bundle-only. The result is that if there are N distinct media types, then candidates will be gathered for for N media streams. This policy balances desire to multiplex with the need to ensure basic audio and video can still be negotiated in legacy cases. When acting as answerer, if there is no bundle group in the offer, the implementation will reject all but the first m= section of each type. max-compat: All m= sections will contain transport parameters; none will be marked as bundle-only. This policy will allow all streams to be received by non-bundle-aware endpoints, but require separate candidates to be gathered for each media stream. max-bundle: Only the first m= section will contain transport parameters; all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. When acting as answerer, the implementation will reject any m= sections other than the first m= section, unless they are in the same bundle group as that m= section. Uberti, et al. Expires August 31, 2019 [Page 23] Internet-Draft JSEP February 2019 As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST be set to "balanced". The application can specify its preferred policy regarding use of RTP/RTCP multiplexing [RFC5761] using one of the following policies: negotiate: The JSEP implementation will gather both RTP and RTCP candidates but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. require: The JSEP implementation will only gather RTP candidates and will insert an "a=rtcp-mux-only" indication into any new m= sections in offers it generates. This halves the number of candidates that the offerer needs to gather. Applying a description with an m= section that does not contain an "a=rtcp- mux" attribute will cause an error to be returned. The default multiplexing policy MUST be set to "require". Implementations MAY choose to reject attempts by the application to set the multiplexing policy to "negotiate". 4.1.2. addTrack The addTrack method adds a MediaStreamTrack to the PeerConnection, using the MediaStream argument to associate the track with other tracks in the same MediaStream, so that they can be added to the same "LS" group when creating an offer or answer. Adding tracks to the same "LS" group indicates that the playback of these tracks should be synchronized for proper lip sync, as described in [RFC5888], Section 7. addTrack attempts to minimize the number of transceivers as follows: If the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver that was created by the most recent call to setRemoteDescription() and does not have a local track. Otherwise, a new transceiver will be created, as described in Section 4.1.4. 4.1.3. removeTrack The removeTrack method removes a MediaStreamTrack from the PeerConnection, using the RtpSender argument to indicate which sender should have its track removed. The sender's track is cleared, and the sender stops sending. Future calls to createOffer will mark the m= section associated with the sender as recvonly (if transceiver.direction is sendrecv) or as inactive (if transceiver.direction is sendonly). Uberti, et al. Expires August 31, 2019 [Page 24] Internet-Draft JSEP February 2019 4.1.4. addTransceiver The addTransceiver method adds a new RtpTransceiver to the PeerConnection. If a MediaStreamTrack argument is provided, then the transceiver will be configured with that media type and the track will be attached to the transceiver. Otherwise, the application MUST explicitly specify the type; this mode is useful for creating recvonly transceivers as well as for creating transceivers to which a track can be attached at some later point. At the time of creation, the application can also specify a transceiver direction attribute, a set of MediaStreams which the transceiver is associated with (allowing LS group assignments), and a set of encodings for the media (used for simulcast as described in Section 3.7). 4.1.5. createDataChannel The createDataChannel method creates a new data channel and attaches it to the PeerConnection. If no data channel currently exists for this PeerConnection, then a new offer/answer exchange is required. All data channels on a given PeerConnection share the same SCTP/DTLS association and therefore the same m= section, so subsequent creation of data channels does not have any impact on the JSEP state. The createDataChannel method also includes a number of arguments which are used by the PeerConnection (e.g., maxPacketLifetime) but are not reflected in the SDP and do not affect the JSEP state. 4.1.6. createOffer The createOffer method generates a blob of SDP that contains a [RFC3264] offer with the supported configurations for the session, including descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent. An options parameter may be supplied to provide additional control over the generated offer. This options parameter allows an application to trigger an ICE restart, for the purpose of reestablishing connectivity. In the initial offer, the generated SDP will contain all desired functionality for the session (functionality that is supported but not desired by default may be omitted); for each SDP line, the generation of the SDP will follow the process defined for generating an initial offer from the document that specifies the given SDP line. The exact handling of initial offer generation is detailed in Section 5.2.1 below. Uberti, et al. Expires August 31, 2019 [Page 25] Internet-Draft JSEP February 2019 In the event createOffer is called after the session is established, createOffer will generate an offer to modify the current session based on any changes that have been made to the session, e.g., adding or stopping RtpTransceivers, or requesting an ICE restart. For each existing stream, the generation of each SDP line must follow the process defined for generating an updated offer from the RFC that specifies the given SDP line. For each new stream, the generation of the SDP must follow the process of generating an initial offer, as mentioned above. If no changes have been made, or for SDP lines that are unaffected by the requested changes, the offer will only contain the parameters negotiated by the last offer-answer exchange. The exact handling of subsequent offer generation is detailed in Section 5.2.2. below. Session descriptions generated by createOffer must be immediately usable by setLocalDescription; if a system has limited resources (e.g. a finite number of decoders), createOffer should return an offer that reflects the current state of the system, so that setLocalDescription will succeed when it attempts to acquire those resources. Calling this method may do things such as generating new ICE credentials, but does not change the PeerConnection state, trigger candidate gathering, or cause media to start or stop flowing. Specifically, the offer is not applied, and does not become the pending local description, until setLocalDescription is called. 4.1.7. createAnswer The createAnswer method generates a blob of SDP that contains a [RFC3264] SDP answer with the supported configuration for the session that is compatible with the parameters supplied in the most recent call to setRemoteDescription, which MUST have been called prior to calling createAnswer. Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any candidates that have been gathered by the ICE agent. An options parameter may be supplied to provide additional control over the generated answer. As an answer, the generated SDP will contain a specific configuration that specifies how the media plane should be established; for each SDP line, the generation of the SDP must follow the process defined for generating an answer from the document that specifies the given SDP line. The exact handling of answer generation is detailed in Section 5.3. below. Uberti, et al. Expires August 31, 2019 [Page 26] Internet-Draft JSEP February 2019 Session descriptions generated by createAnswer must be immediately usable by setLocalDescription; like createOffer, the returned description should reflect the current state of the system. Calling this method may do things such as generating new ICE credentials, but does not change the PeerConnection state, trigger candidate gathering, or or cause a media state change. Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. 4.1.8. SessionDescriptionType Session description objects (RTCSessionDescription) may be of type "offer", "pranswer", "answer" or "rollback". These types provide information as to how the description parameter should be parsed, and how the media state should be changed. "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations. A description used as an "offer" may be applied anytime the PeerConnection is in a stable state, or as an update to a previously supplied but unanswered "offer". "pranswer" indicates that a description should be parsed as an answer, but not a final answer, and so should not result in the freeing of allocated resources. It may result in the start of media transmission, if the answer does not specify an inactive media direction. A description used as a "pranswer" may be applied as a response to an "offer", or an update to a previously sent "pranswer". "answer" indicates that a description should be parsed as an answer, the offer-answer exchange should be considered complete, and any resources (decoders, candidates) that are no longer needed can be released. A description used as an "answer" may be applied as a response to an "offer", or an update to a previously sent "pranswer". The only difference between a provisional and final answer is that the final answer results in the freeing of any unused resources that were allocated as a result of the offer. As such, the application can use some discretion on whether an answer should be applied as provisional or final, and can change the type of the session description as needed. For example, in a serial forking scenario, an application may receive multiple "final" answers, one from each remote endpoint. The application could choose to accept the initial answers as provisional answers, and only apply an answer as final when it receives one that meets its criteria (e.g. a live user instead of voicemail). Uberti, et al. Expires August 31, 2019 [Page 27] Internet-Draft JSEP February 2019 "rollback" is a special session description type implying that the state machine should be rolled back to the previous stable state, as described in Section 4.1.8.2. The contents MUST be empty. 4.1.8.1. Use of Provisional Answers Most applications will not need to create answers using the "pranswer" type. While it is good practice to send an immediate response to an offer, in order to warm up the session transport and prevent media clipping, the preferred handling for a JSEP application is to create and send a "sendonly" final answer with a null MediaStreamTrack immediately after receiving the offer, which will prevent media from being sent by the caller, and allow media to be sent immediately upon answer by the callee. Later, when the callee actually accepts the call, the application can plug in the real MediaStreamTrack and create a new "sendrecv" offer to update the previous offer/answer pair and start bidirectional media flow. While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. As an example, consider a typical JSEP application that wants to set up audio and video as quickly as possible. When the callee receives an offer with audio and video MediaStreamTracks, it will send an immediate answer accepting these tracks as sendonly (meaning that the caller will not send the callee any media yet, and because the callee has not yet added its own MediaStreamTracks, the callee will not send any media either). It will then ask the user to accept the call and acquire the needed local tracks. Upon acceptance by the user, the application will plug in the tracks it has acquired, which, because ICE and DTLS handshaking have likely completed by this point, can start transmitting immediately. The application will also send a new offer to the remote side indicating call acceptance and moving the audio and video to be two-way media. A detailed example flow along these lines is shown in Section 7.3. Of course, some applications may not be able to perform this double offer-answer exchange, particularly ones that are attempting to gateway to legacy signaling protocols. In these cases, pranswer can still provide the application with a mechanism to warm up the transport. 4.1.8.2. Rollback In certain situations it may be desirable to "undo" a change made to setLocalDescription or setRemoteDescription. Consider a case where a call is ongoing, and one side wants to change some of the session Uberti, et al. Expires August 31, 2019 [Page 28] Internet-Draft JSEP February 2019 parameters; that side generates an updated offer and then calls setLocalDescription. However, the remote side, either before or after setRemoteDescription, decides it does not want to accept the new parameters, and sends a reject message back to the offerer. Now, the offerer, and possibly the answerer as well, need to return to a stable state and the previous local/remote description. To support this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the stable state. A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. 4.1.9. setLocalDescription The setLocalDescription method instructs the PeerConnection to apply the supplied session description as its local configuration. The type field indicates whether the description should be processed as an offer, provisional answer, final answer, or rollback; offers and answers are checked differently, using the various rules that exist for each SDP line. This API changes the local media state; among other things, it sets up local resources for receiving and decoding media. In order to successfully handle scenarios where the application wants to offer to change from one media format to a different, incompatible format, the PeerConnection must be able to simultaneously support use of both the current and pending local descriptions (e.g., support the codecs that exist in either description). This dual processing begins when the PeerConnection enters the "have-local-offer" state, and continues until setRemoteDescription is called with either a final answer, at which point the PeerConnection can fully adopt the pending local description, or a rollback, which results in a revert to the current local description. This API indirectly controls the candidate gathering process. When a local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and begin gathering candidates for each transport, using ones from the candidate pool if available. If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. Uberti, et al. Expires August 31, 2019 [Page 29] Internet-Draft JSEP February 2019 4.1.10. setRemoteDescription The setRemoteDescription method instructs the PeerConnection to apply the supplied session description as the desired remote configuration. As in setLocalDescription, the type field of the description indicates how it should be processed. This API changes the local media state; among other things, it sets up local resources for sending and encoding media. If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. 4.1.11. currentLocalDescription The currentLocalDescription method returns the current negotiated local description - i.e., the local description from the last successful offer/answer exchange - in addition to any local candidates that have been generated by the ICE agent since the local description was set. A null object will be returned if an offer/answer exchange has not yet been completed. 4.1.12. pendingLocalDescription The pendingLocalDescription method returns a copy of the local description currently in negotiation - i.e., a local offer set without any corresponding remote answer - in addition to any local candidates that have been generated by the ICE agent since the local description was set. A null object will be returned if the state of the PeerConnection is "stable" or "have-remote-offer". 4.1.13. currentRemoteDescription The currentRemoteDescription method returns a copy of the current negotiated remote description - i.e., the remote description from the last successful offer/answer exchange - in addition to any remote candidates that have been supplied via processIceMessage since the remote description was set. A null object will be returned if an offer/answer exchange has not yet been completed. Uberti, et al. Expires August 31, 2019 [Page 30] Internet-Draft JSEP February 2019 4.1.14. pendingRemoteDescription The pendingRemoteDescription method returns a copy of the remote description currently in negotiation - i.e., a remote offer set without any corresponding local answer - in addition to any remote candidates that have been supplied via processIceMessage since the remote description was set. A null object will be returned if the state of the PeerConnection is "stable" or "have-local-offer". 4.1.15. canTrickleIceCandidates The canTrickleIceCandidates property indicates whether the remote side supports receiving trickled candidates. There are three potential values: null: No SDP has been received from the other side, so it is not known if it can handle trickle. This is the initial value before setRemoteDescription() is called. true: SDP has been received from the other side indicating that it can support trickle. false: SDP has been received from the other side indicating that it cannot support trickle. As described in Section 3.5.2, JSEP implementations always provide candidates to the application individually, consistent with what is needed for Trickle ICE. However, applications can use the canTrickleIceCandidates property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to send an initial offer or answer followed later by candidates as they are gathered. As "true" is the only value that definitively indicates remote Trickle ICE support, an application which compares canTrickleIceCandidates against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE-compatible agent. 4.1.16. setConfiguration The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to be changed during the session. The effects of this method call depend on when it is invoked, and differ depending on which specific parameters are changed: Uberti, et al. Expires August 31, 2019 [Page 31] Internet-Draft JSEP February 2019 o Any changes to the STUN/TURN servers to use affect the next gathering phase. If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit mentioned in Section 3.5.1 will be set. This will cause the next call to createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used. If the ICE candidate pool has a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. o Any change to the ICE candidate policy affects the next gathering phase. If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set. Either way, changes to the policy have no effect on the candidate pool, because pooled candidates are not made available to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. o The ICE candidate pool size MUST NOT be changed after applying a local description. If a local description has not yet been applied, any changes to the ICE candidate pool size take effect immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded. o The bundle and RTCP-multiplexing policies MUST NOT be changed after the construction of the PeerConnection. This call may result in a change to the state of the ICE Agent. 4.1.17. addIceCandidate The addIceCandidate method provides an update to the ICE agent via an IceCandidate object Section 3.5.2.1. If the IceCandidate's candidate field is filled in, the IceCandidate is treated as a new remote ICE candidate, which will be added to the current and/or pending remote description according to the rules defined for Trickle ICE. Otherwise, the IceCandidate is treated as an end-of-candidates indication, as defined in [I-D.ietf-ice-trickle]. In either case, the m= section index, MID, and ufrag fields from the supplied IceCandidate are used to determine which m= section and ICE candidate generation the IceCandidate belongs to, as described in Section 3.5.2.1 above. In the case of an end-of-candidates indication, the absence of both the m= section index and MID fields is interpreted to mean that the indication applies to all m= sections in the specified ICE candidate generation. However, if both fields Uberti, et al. Expires August 31, 2019 [Page 32] Internet-Draft JSEP February 2019 are absent for a new remote candidate, this MUST be treated as an invalid condition, as specified below. If any IceCandidate fields contain invalid values, or an error occurs during the processing of the IceCandidate object, the supplied IceCandidate MUST be ignored and an error MUST be returned. Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate. 4.2. RtpTransceiver 4.2.1. stop The stop method stops an RtpTransceiver. This will cause future calls to createOffer to generate a zero port for the associated m= section. See below for more details. 4.2.2. stopped The stopped property indicates whether the transceiver has been stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated m= section. In either of these cases, it is set to "true", and otherwise will be set to "false". A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP. It cannot be restarted. 4.2.3. setDirection The setDirection method sets the direction of a transceiver, which affects the direction property of the associated m= section on future calls to createOffer and createAnswer. The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", mirroring the identically-named directional attributes defined in [RFC4566], Section 6. When creating offers, the transceiver direction is directly reflected in the output, even for re-offers. When creating answers, the transceiver direction is intersected with the offered direction, as explained in Section 5.3 below. Note that while setDirection sets the direction property of the transceiver immediately ( Section 4.2.4), this property does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive. The direction in effect is represented Uberti, et al. Expires August 31, 2019 [Page 33] Internet-Draft JSEP February 2019 by the currentDirection property, which is only updated when an answer is applied. 4.2.4. direction The direction property indicates the last value passed into setDirection. If setDirection has never been called, it is set to the direction the transceiver was initialized with. 4.2.5. currentDirection The currentDirection property indicates the last negotiated direction for the transceiver's associated m= section. More specifically, it indicates the [RFC3264] directional attribute of the associated m= section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection is set to "sendonly". If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection is set to null. 4.2.6. setCodecPreferences The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and createAnswer. Note that setCodecPreferences does not directly affect which codec the implementation decides to send. It only affects which codecs the implementation indicates that it prefers to receive, via the offer or answer. Even when a codec is excluded by setCodecPreferences, it still may be used to send until the next offer/answer exchange discards it. The codec preferences of an RtpTransceiver can cause codecs to be excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded. The codec preferences cannot add media formats that would otherwise not be present. The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer, in which case the order of the media formats in the associated m= section will follow the specified preferences. Uberti, et al. Expires August 31, 2019 [Page 34] Internet-Draft JSEP February 2019 5. SDP Interaction Procedures This section describes the specific procedures to be followed when creating and parsing SDP objects. 5.1. Requirements Overview JSEP implementations must comply with the specifications listed below that govern the creation and processing of offers and answers. 5.1.1. Usage Requirements All session descriptions handled by JSEP implementations, both local and remote, MUST indicate support for the following specifications. If any of these are absent, this omission MUST be treated as an error. o ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use a Lite implementation; implementations MUST properly handle remote endpoints which do ICE-Lite. o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as appropriate for the media type, as specified in [I-D.ietf-rtcweb-security-arch] The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as discussed in [I-D.ietf-rtcweb-security-arch]. 5.1.2. Profile Names and Interoperability For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the "TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850], and MUST indicate one of these profiles for each media m= line they produce in an offer. For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile, and MUST indicate one of these profiles for each data m= line they produce in an offer. The exact profile to use is determined by the protocol associated with the current default or selected ICE candidate, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Unfortunately, in an attempt at compatibility, some endpoints generate other profile strings even when they mean to support one of these profiles. For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". In order to simplify compatibility with such endpoints, JSEP Uberti, et al. Expires August 31, 2019 [Page 35] Internet-Draft JSEP February 2019 implementations MUST follow the following rules when processing the media m= sections in a received offer: o Any profile in the offer matching one of the following MUST be accepted: * "RTP/AVP" (Defined in [RFC4566], Section 8.2.2) * "RTP/AVPF" (Defined in [RFC4585], Section 9) * "RTP/SAVP" (Defined in [RFC3711], Section 12) * "RTP/SAVPF" (Defined in [RFC5124], Section 6) * "TCP/DTLS/RTP/SAVP" (Defined in [RFC7850], Section 3.4) * "TCP/DTLS/RTP/SAVPF" (Defined in [RFC7850], Section 3.5) * "UDP/TLS/RTP/SAVP" (Defined in [RFC5764], Section 9) * "UDP/TLS/RTP/SAVPF" (Defined in [RFC5764], Section 9) o The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer. o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no effect; support for DTLS-SRTP is determined by the presence of one or more "a=fingerprint" attribute. Note that lack of an "a=fingerprint" attribute will lead to negotiation failure. o The use of AVPF or AVP simply controls the timing rules used for RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute is present, assume AVPF timing, i.e., a default value of "trr- int=0". Otherwise, assume that AVPF is being used in an AVP compatible mode and use a value of "trr-int=4000". o For data m= sections, implementations MUST support receiving the "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards compatibility) profiles. Note that re-offers by JSEP implementations MUST use the correct profile strings even if the initial offer/answer exchange used an (incorrect) older profile string. This simplifies JSEP behavior, with minimal downside, as any remote endpoint that fails to handle such a re-offer will also fail to handle a JSEP endpoint's initial offer. Uberti, et al. Expires August 31, 2019 [Page 36] Internet-Draft JSEP February 2019 5.2. Constructing an Offer When createOffer is called, a new SDP description must be created that includes the functionality specified in [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are explained below. 5.2.1. Initial Offers When createOffer is called for the first time, the result is known as the initial offer. The first step in generating an initial offer is to generate session- level attributes, as specified in [RFC4566], Section 5. Specifically: o The first SDP line MUST be "v=0", as specified in [RFC4566], Section 5.1 o The second SDP line MUST be an "o=" line, as specified in [RFC4566], Section 5.2. The value of the field SHOULD be "-". The sess-id MUST be representable by a 64-bit signed integer, and the value MUST be less than (2**63)-1. It is RECOMMENDED that the sess-id be constructed by generating a 64-bit quantity with the highest bit set to zero and the remaining 63 bits being cryptographically random. The value of the tuple SHOULD be set to a non- meaningful address, such as IN IP4 0.0.0.0, to prevent leaking a local IP address in this field; this problem is discussed in [I-D.ietf-rtcweb-ip-handling]. As mentioned in [RFC4566], the entire o= line needs to be unique, but selecting a random number for is sufficient to accomplish this. o The third SDP line MUST be a "s=" line, as specified in [RFC4566], Section 5.3; to match the "o=" line, a single dash SHOULD be used as the session name, e.g. "s=-". Note that this differs from the advice in [RFC4566] which proposes a single space, but as both "o=" and "s=" are meaningless in JSEP, having the same meaningless value seems clearer. o Session Information ("i="), URI ("u="), Email Address ("e="), Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. o Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included. Uberti, et al. Expires August 31, 2019 [Page 37] Internet-Draft JSEP February 2019 o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; both and SHOULD be set to zero, e.g. "t=0 0". o An "a=ice-options" line with the "trickle" and "ice2" options MUST be added, as specified in [I-D.ietf-ice-trickle], Section 3 and [RFC8445], Section 10. o If WebRTC identity is being used, an "a=identity" line as described in [I-D.ietf-rtcweb-security-arch], Section 5. The next step is to generate m= sections, as specified in [RFC4566], Section 5.14. An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, excluding any stopped RtpTransceivers; this is done in the order the RtpTransceivers were added to the PeerConnection. If there are no such RtpTransceivers, no m= sections are generated; more can be added later, as discussed in [RFC3264], Section 5. For each m= section generated for an RtpTransceiver, establish a mapping between the transceiver and the index of the generated m= section. Each m= section, provided it is not marked as bundle-only, MUST generate a unique set of ICE credentials and gather its own unique set of ICE candidates. Bundle-only m= sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. For DTLS, all m= sections MUST use all the certificate(s) that have been specified for the PeerConnection; as a result, they MUST all have the same [RFC8122] fingerprint value(s), or these value(s) MUST be session-level attributes. Each m= section should be generated as specified in [RFC4566], Section 5.14. For the m= line itself, the following rules MUST be followed: o If the m= section is marked as bundle-only, then the port value MUST be set to 0. Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. o To properly indicate use of DTLS, the field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. Uberti, et al. Expires August 31, 2019 [Page 38] Internet-Draft JSEP February 2019 o If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences. o Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in [RFC7874], Section 3, and [RFC7742], Section 5. The m= line MUST be followed immediately by a "c=" line, as specified in [RFC4566], Section 5.7. Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1. [I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes m= sections for which bundling has been negotiated and is still desired, as well as m= sections marked as bundle-only. The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each m= section: o An "a=mid" line, as specified in [RFC5888], Section 4. All MID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14. Note that this does not set the RtpTransceiver mid property, as that only occurs when the description is applied. The generated MID value can be considered a "proposed" MID at this point. o A direction attribute which is the same as that of the associated transceiver. o For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6, and [RFC3264], Section 5.1. o For each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the payload type of the primary codec, as specified in [RFC4588], Section 8.1. Uberti, et al. Expires August 31, 2019 [Page 39] Internet-Draft JSEP February 2019 o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC mechanisms that MUST be supported are specified in [I-D.ietf-rtcweb-fec], Section 6, and specific usage for each media type is outlined in Sections 4 and 5. o If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in [RFC4566], Section 6. This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. o If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in Section 3.6. o For each supported RTP header extension, an "a=extmap" line, as specified in [RFC5285], Section 5. The list of header extensions that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions that require encryption MUST be specified as indicated in [RFC6904], Section 4. o For each supported RTCP feedback mechanism, an "a=rtcp-fb" line, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. o If the RtpTransceiver has a sendrecv or sendonly direction: * For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2, but omitting the "appdata" field. o If the RtpTransceiver has a sendrecv or sendonly direction, and the application has specified RID values or has specified more than one encoding in the RtpSenders's parameters, an "a=rid" line for each encoding specified. The "a=rid" line is specified in [I-D.ietf-mmusic-rid], and its direction MUST be "send". If the application has chosen a RID value, it MUST be used as the rid- identifier; otherwise a RID value MUST be generated by the implementation. RID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per- PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-avtext-rid], Section 3. If no encodings have been Uberti, et al. Expires August 31, 2019 [Page 40] Internet-Draft JSEP February 2019 specified, or only one encoding is specified but without a RID value, then no "a=rid" lines are generated. o If the RtpTransceiver has a sendrecv or sendonly direction and more than one "a=rid" line has been generated, an "a=simulcast" line, with direction "send", as defined in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2. The list of RIDs MUST include all of the RID identifiers used in the "a=rid" lines for this m= section. o If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. The following attributes, which are of category IDENTICAL or TRANSPORT, MUST appear only in "m=" sections which either have a unique address or which are associated with the bundle-tag. (In initial offers, this means those "m=" sections which do not contain an "a=bundle-only" attribute.) o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. o For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in [RFC8122], Section 5. o An "a=setup" line, as specified in [RFC4145], Section 4, and clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. The role value in the offer MUST be "actpass". o An "a=tls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp], Section 5.2. o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.3. o If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in [I-D.ietf-mmusic-mux-exclusive], Section 4. o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. Uberti, et al. Expires August 31, 2019 [Page 41] Internet-Draft JSEP February 2019 Lastly, if a data channel has been created, a m= section MUST be generated for data. The field MUST be set to "application" and the field MUST be set to "UDP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp]. The "fmt" value MUST be set to "webrtc- datachannel" as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 6.1. As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section either has a unique address or is associated with the bundle-tag (e.g., if it is the only m= section): o "a=ice-ufrag" o "a=ice-pwd" o "a=fingerprint" o "a=setup" o "a=tls-id" Once all m= sections have been generated, a session-level "a=group" attribute MUST be added as specified in [RFC5888]. This attribute MUST have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. The effect of this is that the JSEP implementation offers all m= sections as one bundle group. However, whether the m= sections are bundle-only or not depends on the bundle policy. The next step is to generate session-level lip sync groups as defined in [RFC5888], Section 7. For each MediaStream referenced by more than one RtpTransceiver (by passing those MediaStreams as arguments to the addTrack and addTransceiver methods), a group of type "LS" MUST be added that contains the mid values for each RtpTransceiver. Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical. This assists development and debugging by making it easier to understand individual media sections, especially if one of a set of initially identical attributes is subsequently changed. However, implementations MAY choose to aggregate attributes at the Uberti, et al. Expires August 31, 2019 [Page 42] Internet-Draft JSEP February 2019 session level and JSEP implementations MUST be prepared to receive attributes in either location. Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], and MUST NOT be included: o "a=crypto" o "a=key-mgmt" o "a=ice-lite" Note that when bundle is used, any additional attributes that are added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] on how those attributes interact with bundle. Note that these requirements are in some cases stricter than those of SDP. Implementations MUST be prepared to accept compliant SDP even if it would not conform to the requirements for generating SDP in this specification. 5.2.2. Subsequent Offers When createOffer is called a second (or later) time, or is called after a local description has already been installed, the processing is somewhat different than for an initial offer. If the previous offer was not applied using setLocalDescription, meaning the PeerConnection is still in the "stable" state, the steps for generating an initial offer should be followed, subject to the following restriction: o The fields of the "o=" line MUST stay the same except for the field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment on every call. The value of the generated is independent of the of the current local description; in particular, in the case where the current version is N, an offer is created and applied with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned Uberti, et al. Expires August 31, 2019 [Page 43] Internet-Draft JSEP February 2019 SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the will not have changed. There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique . If the previous offer was applied using setLocalDescription, but a corresponding answer from the remote side has not yet been applied, meaning the PeerConnection is still in the "have-local-offer" state, an offer is generated by following the steps in the "stable" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o If any RtpTransceiver has been added, and there exists an m= section with a zero port in the current local description or the current remote description, that m= section MUST be recycled by generating an m= section for the added RtpTransceiver as if the m= section were being added to the session description (including a new MID value), and placing it at the same index as the m= section with a zero port. o If an RtpTransceiver is stopped and is not associated with an m= section, an m= section MUST NOT be generated for it. This prevents adding back RtpTransceivers whose m= sections were recycled and used for a new RtpTransceiver in a previous offer/ answer exchange, as described above. o If an RtpTransceiver has been stopped and is associated with an m= section, and the m= section is not being recycled as described above, an m= section MUST be generated for it with the port set to zero and all "a=msid" lines removed. o For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same if they are present in the current description, regardless of changes to the transceiver's direction or track. If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial offer. o Each "m=" and c=" line MUST be filled in with the port, relevant RTP profile, and address of the default candidate for the m= section, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2, and clarified in Section 5.1.2. If no RTP candidates have yet been gathered, dummy values MUST still be used, as described above. Uberti, et al. Expires August 31, 2019 [Page 44] Internet-Draft JSEP February 2019 o Each "a=mid" line MUST stay the same. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the ICE configuration has changed (either changes to the supported STUN/TURN servers, or the ICE candidate policy), or the "IceRestart" option ( Section 5.2.3.1 was specified. If the m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. o If the m= section is not bundled into another m= section, its "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate, as indicated in [RFC5761], Section 5.1.3. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial offer section above. o If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If candidate gathering for the section has completed, an "a=end-of- candidates" attribute MUST be added, as described in [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled into another m= section, both "a=candidate" and "a=end-of- candidates" MUST be omitted. o For RtpTransceivers that are still present, the "a=rid" lines MUST stay the same. o For RtpTransceivers that are still present, any "a=simulcast" line MUST stay the same. If the previous offer was applied using setLocalDescription, and a corresponding answer from the remote side has been applied using setRemoteDescription, meaning the PeerConnection is in the "have- remote-pranswer" or "stable" states, an offer is generated based on the negotiated session descriptions by following the steps mentioned for the "have-local-offer" state above. In addition, for each existing, non-recycled, non-rejected m= section in the new offer, the following adjustments are made based on the contents of the corresponding m= section in the current local or remote description, as appropriate: o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST only include media formats which have not been excluded by the codec preferences of the associated transceiver, and MUST include all currently available formats. Media formats that were Uberti, et al. Expires August 31, 2019 [Page 45] Internet-Draft JSEP February 2019 previously offered but are no longer available (e.g., a shared hardware codec) MAY be excluded. o Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the most recent answer. Any media formats that were not present in the most recent answer MUST be added after all existing formats. o The RTP header extensions MUST only include those that are present in the most recent answer. o The RTCP feedback mechanisms MUST only include those that are present in the most recent answer, except for the case of format- specific mechanisms that are referencing a newly-added media format. o The "a=rtcp" line MUST NOT be added if the most recent answer included an "a=rtcp-mux" line. o The "a=rtcp-mux" line MUST be the same as that in the most recent answer. o The "a=rtcp-mux-only" line MUST NOT be added. o The "a=rtcp-rsize" line MUST NOT be added unless present in the most recent answer. o An "a=bundle-only" line MUST NOT be added, as indicated in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 6. Instead, JSEP implementations MUST simply omit parameters in the IDENTICAL and TRANSPORT categories for bundled m= sections, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. o Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux"). This cannot happen in initial offers because in the initial offer JSEP implementations always list media m= sections (if any) before the data m= section (if any), and at least one of those media m= sections will not have the "a=bundle-only" attribute. Therefore, in initial offers, any "a=bundle-only" m= sections will be bundled into a preceding non-bundle-only media m= section. The "a=group:BUNDLE" attribute MUST include the MID identifiers specified in the bundle group in the most recent answer, minus any m= sections that have been marked as rejected, plus any newly added or Uberti, et al. Expires August 31, 2019 [Page 46] Internet-Draft JSEP February 2019 re-enabled m= sections. In other words, the bundle attribute must contain all m= sections that were previously bundled, as long as they are still alive, as well as any new m= sections. "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and MUST contain any previously existing MID identifiers, as long as the identified m= sections still exist and are not rejected, and the group still contains at least two MID identifiers. This ensures that any synchronized "recvonly" m= sections continue to be synchronized in the new offer. 5.2.3. Options Handling The createOffer method takes as a parameter an RTCOfferOptions object. Special processing is performed when generating a SDP description if the following options are present. 5.2.3.1. IceRestart If the "IceRestart" option is specified, with a value of "true", the offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1. If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd are already generated). Similarly, if the ICE configuration has changed, this option has no effect, since new ufrag and pwd attributes will be generated automatically. This option is primarily useful for reestablishing connectivity in cases where failures are detected by the application. 5.2.3.2. VoiceActivityDetection Silence suppression, also known as discontinuous transmission ("DTX"), can reduce the bandwidth used for audio by switching to a special encoding when voice activity is not detected, at the cost of some fidelity. If the "VoiceActivityDetection" option is specified, with a value of "true", the offer MUST indicate support for silence suppression in the audio it receives by including comfort noise ("CN") codecs for each offered audio codec, as specified in [RFC3389], Section 5.1, except for codecs that have their own internal silence suppression support. For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is desired. For example, when using the Opus codec [RFC6716], the Uberti, et al. Expires August 31, 2019 [Page 47] Internet-Draft JSEP February 2019 "usedtx=1" parameter, specified in [RFC7587], would be used in the offer. If the "VoiceActivityDetection" option is specified, with a value of "false", the JSEP implementation MUST NOT emit "CN" codecs. For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired. For example, when using the Opus codec, the "usedtx=0" parameter would be specified in the offer. In addition, the implementation MUST NOT use silence suppression for media it generates, regardless of whether the "CN" codecs or related fmtp parameters appear in the peer's description. The impact of these rules is that silence suppression in JSEP depends on mutual agreement of both sides, which ensures consistent handling regardless of which codec is used. The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer audio level header extension described in [RFC6464], Section 4. 5.3. Generating an Answer When createAnswer is called, a new SDP description must be created that is compatible with the supplied remote description as well as the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are explained below. 5.3.1. Initial Answers When createAnswer is called for the first time after a remote description has been provided, the result is known as the initial answer. If no remote description has been installed, an answer cannot be generated, and an error MUST be returned. Note that the remote description SDP may not have been created by a JSEP endpoint and may not conform to all the requirements listed in Section 5.2. For many cases, this is not a problem. However, if any mandatory SDP attributes are missing, or functionality listed as mandatory-to-use above is not present, this MUST be treated as an error, and MUST cause the affected m= sections to be marked as rejected. The first step in generating an initial answer is to generate session-level attributes. The process here is identical to that indicated in the initial offers section above, except that the "a=ice-options" line, with the "trickle" option as specified in [I-D.ietf-ice-trickle], Section 3, and the "ice2" option as specified Uberti, et al. Expires August 31, 2019 [Page 48] Internet-Draft JSEP February 2019 in [RFC8445], Section 10, is only included if such an option was present in the offer. The next step is to generate session-level lip sync groups, as defined in [RFC5888], Section 7. For each group of type "LS" present in the offer, select the local RtpTransceivers that are referenced by the MID values in the specified group, and determine which of them either reference a common local MediaStream (specified in the calls to addTrack/addTransceiver used to create them), or have no MediaStream to reference because they were not created by addTrack/ addTransceiver. If at least two such RtpTransceivers exist, a group of type "LS" with the mid values of these RtpTransceivers MUST be added. Otherwise the offered "LS" group MUST be ignored and no corresponding group generated in the answer. As a simple example, consider the following offer of a single audio and single video track contained in the same MediaStream. SDP lines not relevant to this example have been removed for clarity. As explained in Section 5.2, a group of type "LS" has been added that references each track's RtpTransceiver. a=group:LS a1 v1 m=audio 10000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=msid:ms1 m=video 10001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=msid:ms1 If the answerer uses a single MediaStream when it adds its tracks, both of its transceivers will reference this stream, and so the subsequent answer will contain a "LS" group identical to that in the offer, as shown below: a=group:LS a1 v1 m=audio 20000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=msid:ms2 m=video 20001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=msid:ms2 Uberti, et al. Expires August 31, 2019 [Page 49] Internet-Draft JSEP February 2019 However, if the answerer groups its tracks into separate MediaStreams, its transceivers will reference different streams, and so the subsequent answer will not contain a "LS" group. m=audio 20000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=msid:ms2a m=video 20001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=msid:ms2b Finally, if the answerer does not add any tracks, its transceivers will not reference any MediaStreams, causing the preferences of the offerer to be maintained, and so the subsequent answer will contain an identical "LS" group. a=group:LS a1 v1 m=audio 20000 UDP/TLS/RTP/SAVPF 0 a=mid:a1 a=recvonly m=video 20001 UDP/TLS/RTP/SAVPF 96 a=mid:v1 a=recvonly The Section 7.2 example later in this document shows a more involved case of "LS" group generation. The next step is to generate m= sections for each m= section that is present in the remote offer, as specified in [RFC3264], Section 6. For the purposes of this discussion, any session-level attributes in the offer that are also valid as media-level attributes are considered to be present in each m= section. Each offered m= section will have an associated RtpTransceiver, as described in Section 5.10. If there are more RtpTransceivers than there are m= sections, the unmatched RtpTransceivers will need to be associated in a subsequent offer. For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in [RFC3264], Section 6, and further processing for this m= section can be skipped: o The associated RtpTransceiver has been stopped. Uberti, et al. Expires August 31, 2019 [Page 50] Internet-Draft JSEP February 2019 o None of the offered media formats are supported and, if applicable, allowed by codec preferences. o The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section. o The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type. o This m= section is in a bundle group, and the group's offerer tagged m= section is being rejected due to one of the above reasons. This requires all m= sections in the bundle group to be rejected, as specified in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 7.3.3. Otherwise, each m= section in the answer should then be generated as specified in [RFC3264], Section 6.1. For the m= line itself, the following rules must be followed: o The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. o The field MUST be set to exactly match the field for the corresponding m= line in the offer. o If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, regardless of what was offered, and MUST exclude any codecs not present in the codec preferences. o Otherwise, the media formats on the m= line MUST be generated in the same order as those offered in the current remote description, excluding any currently unsupported formats. Any currently available media formats that are not present in the current remote description MUST be added after all existing formats. o In either case, the media formats in the answer MUST include at least one format that is present in the offer, but MAY include formats that are locally supported but not present in the offer, as mentioned in [RFC3264], Section 6.1. If no common format exists, the m= section is rejected as described above. The m= line MUST be followed immediately by a "c=" line, as specified in [RFC4566], Section 5.7. Again, as no candidates are available Uberti, et al. Expires August 31, 2019 [Page 51] Internet-Draft JSEP February 2019 yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in [I-D.ietf-ice-trickle], Section 5.1. If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being bundled must use unique ICE credentials and candidates. Each m= section MUST contain the following attributes (which are of attribute types other than IDENTICAL and TRANSPORT): o If and only if present in the offer, an "a=mid" line, as specified in [RFC5888], Section 9.1. The "mid" value MUST match that specified in the offer. o A direction attribute, determined by applying the rules regarding the offered direction specified in [RFC3264], Section 6.1, and then intersecting with the direction of the associated RtpTransceiver. For example, in the case where an m= section is offered as "sendonly", and the local transceiver is set to "sendrecv", the result in the answer is a "recvonly" direction. o For each media format on the m= line, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6, and [RFC3264], Section 6.1. o If "rtx" is present in the offer, for each primary codec where RTP retransmission should be used, a corresponding "a=rtpmap" line indicating "rtx" with the clock rate of the primary codec and an "a=fmtp" line that references the payload type of the primary codec, as specified in [RFC4588], Section 8.1. o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], Section 6. The FEC mechanisms that MUST be supported are specified in [I-D.ietf-rtcweb-fec], Section 6, and specific usage for each media type is outlined in Sections 4 and 5. o If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in Section 5.2. o If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in Section 3.6. o For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in [RFC5285], Section 5. The list of header extensions that SHOULD/MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header Uberti, et al. Expires August 31, 2019 [Page 52] Internet-Draft JSEP February 2019 extensions that require encryption MUST be specified as indicated in [RFC6904], Section 4. o For each supported RTCP feedback mechanism that is present in the offer, an "a=rtcp-fb" line, as specified in [RFC4585], Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. o If the RtpTransceiver has a sendrecv or sendonly direction: * For each MediaStream that was associated with the transceiver when it was created via addTrack or addTransceiver, an "a=msid" line, as specified in [I-D.ietf-mmusic-msid], Section 2, but omitting the "appdata" field. Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT): o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. o For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in [RFC8122], Section 5. o An "a=setup" line, as specified in [RFC4145], Section 4, and clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. The role value in the answer MUST be "active" or "passive". When the offer contains the "actpass" value, as will always be the case with JSEP endpoints, the answerer SHOULD use the "active" role. Offers from non-JSEP endpoints MAY send other values for "a=setup", in which case the answer MUST use a value consistent with the value in the offer. o An "a=tls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp], Section 5.3. o If present in the offer, an "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.3. Otherwise, an "a=rtcp" line, as specified in [RFC3605], Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0" (because no candidates have yet been gathered). o If present in the offer, an "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. Uberti, et al. Expires August 31, 2019 [Page 53] Internet-Draft JSEP February 2019 If a data channel m= section has been offered, a m= section MUST also be generated for data. The field MUST be set to "application" and the and fields MUST be set to exactly match the fields in the offer. Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line referencing the SCTP port number, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 5.1, and, if appropriate, an "a=max-message-size" line, as defined in [I-D.ietf-mmusic-sctp-sdp], Section 6.1. As discussed above, the following attributes of category IDENTICAL or TRANSPORT are included only if the data m= section is not bundled into another m= section: o "a=ice-ufrag" o "a=ice-pwd" o "a=fingerprint" o "a=setup" o "a=tls-id" Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may also appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp-mux"). If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as specified in [RFC5888]. These attributes MUST have semantics "BUNDLE", and MUST include the all mid identifiers from the offered bundle groups that have not been rejected. Note that regardless of the presence of "a=bundle-only" in the offer, no m= sections in the answer should have an "a=bundle-only" line. Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. The attributes prohibited in the creation of offers are also prohibited in the creation of answers. Uberti, et al. Expires August 31, 2019 [Page 54] Internet-Draft JSEP February 2019 5.3.2. Subsequent Answers When createAnswer is called a second (or later) time, or is called after a local description has already been installed, the processing is somewhat different than for an initial answer. If the previous answer was not applied using setLocalDescription, meaning the PeerConnection is still in the "have-remote-offer" state, the steps for generating an initial answer should be followed, subject to the following restriction: o The fields of the "o=" line MUST stay the same except for the field, which MUST increment if the session description changes in any way from the previously generated answer. If any session description was previously supplied to setLocalDescription, an answer is generated by following the steps in the "have-remote-offer" state above, along with these exceptions: o The "s=" and "t=" lines MUST stay the same. o Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.2.1.2. Note that in certain cases, the m= line protocol may not match that of the default candidate, because the m= line protocol value MUST match what was supplied in the offer, as described above. o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1. If the m= section is bundled into another m= section, it still MUST NOT contain any ICE credentials. o Each "a=tls-id" line MUST stay the same unless the offerer's "a=tls-id" line changed, in which case a new "a=tls-id" value MUST be created, as described in [I-D.ietf-mmusic-dtls-sdp], Section 5.2. o Each "a=setup" line MUST use an "active" or "passive" role value consistent with the existing DTLS association, if the association is being continued by the offerer. o RTCP multiplexing must be used, and an "a=rtcp-mux" line inserted if and only if the m= section previously used RTCP multiplexing. Uberti, et al. Expires August 31, 2019 [Page 55] Internet-Draft JSEP February 2019 o If the m= section is not bundled into another m= section and RTCP multiplexing is not active, an "a=rtcp" attribute line MUST be filled in with the port and address of the default RTCP candidate. If no RTCP candidates have yet been gathered, dummy values MUST be used, as described in the initial answer section above. o If the m= section is not bundled into another m= section, for each candidate that has been gathered during the most recent gathering phase (see Section 3.5.1), an "a=candidate" line MUST be added, as defined in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1. If candidate gathering for the section has completed, an "a=end-of- candidates" attribute MUST be added, as described in [I-D.ietf-ice-trickle], Section 9.3. If the m= section is bundled into another m= section, both "a=candidate" and "a=end-of- candidates" MUST be omitted. o For RtpTransceivers that are not stopped, the "a=msid" line(s) MUST stay the same, regardless of changes to the transceiver's direction or track. If no "a=msid" line is present in the current description, "a=msid" line(s) MUST be generated according to the same rules as for an initial answer. 5.3.3. Options Handling The createAnswer method takes as a parameter an RTCAnswerOptions object. The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the IceRestart option is unnecessary, as ICE credentials will automatically be changed for all m= sections where the offerer chose to perform ICE restart. The following options are supported in RTCAnswerOptions. 5.3.3.1. VoiceActivityDetection Silence suppression in the answer is handled as described in Section 5.2.3.2, with one exception: if support for silence suppression was not indicated in the offer, the VoiceActivityDetection parameter has no effect, and the answer should be generated as if VoiceActivityDetection was set to false. This is done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). The impact of this rule is that an answerer will not try to use silence suppression with any endpoint that does not offer it, making silence suppression support bilateral even with non-JSEP endpoints. Uberti, et al. Expires August 31, 2019 [Page 56] Internet-Draft JSEP February 2019 5.4. Modifying an Offer or Answer The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription. If precise control over the SDP is needed, the aforementioned createOffer/createAnswer options or RtpTransceiver APIs MUST be used. After calling setLocalDescription with an offer or answer, the application MAY modify the SDP to reduce its capabilities before sending it to the far side, as long as it follows the rules above that define a valid JSEP offer or answer. Likewise, an application that has received an offer or answer from a peer MAY modify the received SDP, subject to the same constraints, before calling setRemoteDescription. As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the JSEP implementation to the extent of its capabilities. It is an error to assume that all SDP is well-formed; however, one should be able to assume that any implementation of this specification will be able to process, as a remote offer or answer, unmodified SDP coming from any other implementation of this specification. 5.5. Processing a Local Description When a SessionDescription is supplied to setLocalDescription, the following steps MUST be performed: o If the description is of type "rollback", follow the processing defined in Section 5.7 and skip the processing described in the rest of this section. o Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: * If the type is "offer", the PeerConnection state MUST be either "stable" or "have-local-offer". * If the type is "pranswer" or "answer", the PeerConnection state MUST be either "have-remote-offer" or "have-local-pranswer". o If the type is not correct for the current state, processing MUST stop and an error MUST be returned. o The SessionDescription is then checked to ensure that its contents are identical to those generated in the last call to createOffer/ createAnswer, and thus have not been altered, as discussed in Uberti, et al. Expires August 31, 2019 [Page 57] Internet-Draft JSEP February 2019 Section 5.4; otherwise, processing MUST stop and an error MUST be returned. o Next, the SessionDescription is parsed into a data structure, as described in Section 5.8 below. o Finally, the parsed SessionDescription is applied as described in Section 5.9 below. 5.6. Processing a Remote Description When a SessionDescription is supplied to setRemoteDescription, the following steps MUST be performed: o If the description is of type "rollback", follow the processing defined in Section 5.7 and skip the processing described in the rest of this section. o Otherwise, the type of the SessionDescription is checked against the current state of the PeerConnection: * If the type is "offer", the PeerConnection state MUST be either "stable" or "have-remote-offer". * If the type is "pranswer" or "answer", the PeerConnection state MUST be either "have-local-offer" or "have-remote-pranswer". o If the type is not correct for the current state, processing MUST stop and an error MUST be returned. o Next, the SessionDescription is parsed into a data structure, as described in Section 5.8 below. If parsing fails for any reason, processing MUST stop and an error MUST be returned. o Finally, the parsed SessionDescription is applied as described in Section 5.10 below. 5.7. Processing a Rollback A rollback may be performed if the PeerConnection is in any state except for "stable". This means that both offers and provisional answers can be rolled back. Rollback can only be used to cancel proposed changes; there is no support for rolling back from a stable state to a previous stable state. If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned. Note that this implies that once the answerer has performed setLocalDescription with his answer, this cannot be rolled back. Uberti, et al. Expires August 31, 2019 [Page 58] Internet-Draft JSEP February 2019 The effect of rollback MUST be the same regardless of whether setLocalDescription or setRemoteDescription is called. In order to process rollback, a JSEP implementation abandons the current offer/answer transaction, sets the signaling state to "stable", and sets the pending local and/or remote description (see Section 4.1.12 and Section 4.1.14) to null. Any resources or candidates that were allocated by the abandoned local description are discarded; any media that is received is processed according to the previous local and remote descriptions. A rollback disassociates any RtpTransceivers that were associated with m= sections by the application of the rolled-back session description (see Section 5.10 and Section 5.9). This means that some RtpTransceivers that were previously associated will no longer be associated with any m= section; in such cases, the value of the RtpTransceiver's mid property MUST be set to null, and the mapping between the transceiver and its m= section index MUST be discarded. RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be stopped and removed from the PeerConnection. However, a RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method. This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. 5.8. Parsing a Session Description The SDP contained in the session description object consists of a sequence of text lines, each containing a key-value expression, as described in [RFC4566], Section 5. The SDP is read, line-by-line, and converted to a data structure that contains the deserialized information. However, SDP allows many types of lines, not all of which are relevant to JSEP applications. For each line, the implementation will first ensure it is syntactically correct according to its defining ABNF, check that it conforms to [RFC4566] and [RFC3264] semantics, and then either parse and store or discard the provided value, as described below. If any line is not well-formed, or cannot be parsed as described, the parser MUST stop with an error and reject the session description, even if the value is to be discarded. This ensures that implementations do not accidentally misinterpret ambiguous SDP. Uberti, et al. Expires August 31, 2019 [Page 59] Internet-Draft JSEP February 2019 5.8.1. Session-Level Parsing First, the session-level lines are checked and parsed. These lines MUST occur in a specific order, and with a specific syntax, as defined in [RFC4566], Section 5. Note that while the specific line types (e.g. "v=", "c=") MUST occur in the defined order, lines of the same type (typically "a=") can occur in any order. The following non-attribute lines are not meaningful in the JSEP context and MAY be discarded once they have been checked. The "c=" line MUST be checked for syntax but its value is only used for ICE mismatch detection, as defined in [RFC8445], Section 5.4. Note that JSEP implementations should never encounter this condition because ICE is required for WebRTC. The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are not used by this specification; they MUST be checked for syntax but their values are not used. The remaining non-attribute lines are processed as follows: The "v=" line MUST have a version of 0, as specified in [RFC4566], Section 5.1. The "o=" line MUST be parsed as specified in [RFC4566], Section 5.2. The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. Finally, the attribute lines are processed. Specific processing MUST be applied for the following session-level attribute ("a=") lines: o Any "a=group" lines are parsed as specified in [RFC5888], Section 5, and the group's semantics and mids are stored. o If present, a single "a=ice-lite" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.3, and a value indicating the presence of ice-lite is stored. o If present, a single "a=ice-ufrag" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the ufrag value is stored. Uberti, et al. Expires August 31, 2019 [Page 60] Internet-Draft JSEP February 2019 o If present, a single "a=ice-pwd" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the password value is stored. o If present, a single "a=ice-options" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.6, and the set of specified options is stored. o Any "a=fingerprint" lines are parsed as specified in [RFC8122], Section 5, and the set of fingerprint and algorithm values is stored. o If present, a single "a=setup" line is parsed as specified in [RFC4145], Section 4, and the setup value is stored. o If present, a single "a=tls-id" line is parsed as specified in [I-D.ietf-mmusic-dtls-sdp] Section 5, and the tls-id value is stored. o Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified [I-D.ietf-rtcweb-security-arch], Section 5. o Any "a=extmap" lines are parsed as specified in [RFC5285], Section 5, and their values are stored. Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize. As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. Once all the session-level lines have been parsed, processing continues with the lines in m= sections. 5.8.2. Media Section Parsing Like the session-level lines, the media section lines MUST occur in the specific order and with the specific syntax defined in [RFC4566], Section 5. The "m=" line itself MUST be parsed as described in [RFC4566], Section 5.14, and the media, port, proto, and fmt values stored. Following the "m=" line, specific processing MUST be applied for the following non-attribute lines: Uberti, et al. Expires August 31, 2019 [Page 61] Internet-Draft JSEP February 2019 o As with the "c=" line at the session level, the "c=" line MUST be parsed according to [RFC4566], Section 5.7, but its value is not used. o The "b=" line, if present, MUST be parsed as specified in [RFC4566], Section 5.8, and the bwtype and bandwidth values stored. Specific processing MUST also be applied for the following attribute lines: o If present, a single "a=ice-ufrag" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the ufrag value is stored. o If present, a single "a=ice-pwd" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4, and the password value is stored. o If present, a single "a=ice-options" line is parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.6, and the set of specified options is stored. o Any "a=candidate" attributes MUST be parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.1, and their values stored. o Any "a=remote-candidates" attributes MUST be parsed as specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.2, but their values are ignored. o If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and its presence or absence flagged and stored. o Any "a=fingerprint" lines are parsed as specified in [RFC8122], Section 5, and the set of fingerprint and algorithm values is stored. If the "m=" proto value indicates use of RTP, as described in Section 5.1.2 above, the following attribute lines MUST be processed: o The "m=" fmt value MUST be parsed as specified in [RFC4566], Section 5.14, and the individual values stored. o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in [RFC4566], Section 6, and their values stored. Uberti, et al. Expires August 31, 2019 [Page 62] Internet-Draft JSEP February 2019 o If present, a single "a=ptime" line MUST be parsed as described in [RFC4566], Section 6, and its value stored. o If present, a single "a=maxptime" line MUST be parsed as described in [RFC4566], Section 6, and its value stored. o If present, a single direction attribute line (e.g. "a=sendrecv") MUST be parsed as described in [RFC4566], Section 6, and its value stored. o Any "a=ssrc" attributes MUST be parsed as specified in [RFC5576], Section 4.1, and their values stored. o Any "a=extmap" attributes MUST be parsed as specified in [RFC5285], Section 5, and their values stored. o Any "a=rtcp-fb" attributes MUST be parsed as specified in [RFC4585], Section 4.2., and their values stored. o If present, a single "a=rtcp-mux" attribute MUST be parsed as specified in [RFC5761], Section 5.1.3, and its presence or absence flagged and stored. o If present, a single "a=rtcp-mux-only" attribute MUST be parsed as specified in [I-D.ietf-mmusic-mux-exclusive], Section 3, and its presence or absence flagged and stored. o If present, a single "a=rtcp-rsize" attribute MUST be parsed as specified in [RFC5506], Section 5, and its presence or absence flagged and stored. o If present, a single "a=rtcp" attribute MUST be parsed as specified in [RFC3605], Section 2.1, but its value is ignored, as this information is superfluous when using ICE. o If present, "a=msid" attributes MUST be parsed as specified in [I-D.ietf-mmusic-msid], Section 3.2, and their values stored, ignoring any "appdata" field. If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. o Any "a=imageattr" attributes MUST be parsed as specified in [RFC6236], Section 3, and their values stored. o Any "a=rid" lines MUST be parsed as specified in [I-D.ietf-mmusic-rid], Section 10, and their values stored. Uberti, et al. Expires August 31, 2019 [Page 63] Internet-Draft JSEP February 2019 o If present, a single "a=simulcast" line MUST be parsed as specified in [I-D.ietf-mmusic-sdp-simulcast], and its values stored. Otherwise, if the "m=" proto value indicates use of SCTP, the following attribute lines MUST be processed: o The "m=" fmt value MUST be parsed as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.3, and the application protocol value stored. o An "a=sctp-port" attribute MUST be present, and it MUST be parsed as specified in [I-D.ietf-mmusic-sctp-sdp], Section 5.2, and the value stored. o If present, a single "a=max-message-size" attribute MUST be parsed as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the value stored. Otherwise, use the specified default. Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize. As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. 5.8.3. Semantics Verification Assuming parsing completes successfully, the parsed description is then evaluated to ensure internal consistency as well as proper support for mandatory features. Specifically, the following checks are performed: o For each m= section, valid values for each of the mandatory-to-use features enumerated in Section 5.1.1 MUST be present. These values MAY either be present at the media level, or inherited from the session level. * ICE ufrag and password values, which MUST comply with the size limits specified in [I-D.ietf-mmusic-ice-sip-sdp], Section 4.4. * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer or a response to a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. * DTLS setup value, which MUST be set according to the rules specified in [RFC5763], Section 5 and MUST be consistent with Uberti, et al. Expires August 31, 2019 [Page 64] Internet-Draft JSEP February 2019 the selected role of the current DTLS connection, if one exists and is being continued. * DTLS fingerprint values, where at least one fingerprint MUST be present. o All RID values referenced in an "a=simulcast" line MUST exist as "a=rid" lines. o Each m= section is also checked to ensure prohibited features are not used. o If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute. If an m= section contains an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute. o If an m= section was present in the previous answer, the state of RTP/RTCP multiplexing MUST match what was previously negotiated. If this session description is of type "pranswer" or "answer", the following additional checks are applied: o The session description must follow the rules defined in [RFC3264], Section 6, including the requirement that the number of m= sections MUST exactly match the number of m= sections in the associated offer. o For each m= section, the media type and protocol values MUST exactly match the media type and protocol values in the corresponding m= section in the associated offer. If any of the preceding checks failed, processing MUST stop and an error MUST be returned. 5.9. Applying a Local Description The following steps are performed at the media engine level to apply a local description. If an error is returned, the session MUST be restored to the state it was in before performing these steps. First, m= sections are processed. For each m= section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. o If this m= section is new, begin gathering candidates for it, as defined in [RFC8445], Section 5.1.1, unless it is definitively Uberti, et al. Expires August 31, 2019 [Page 65] Internet-Draft JSEP February 2019 being bundled (either this is an offer and the m= section is marked bundle-only, or it is an answer and the m= section is bundled into into another m= section.) o Or, if the ICE ufrag and password values have changed, trigger the ICE agent to start an ICE restart as described in [RFC8445], Section 9, and begin gathering new candidates for the m= section. If this description is an answer, also start checks on that media section. o If the m= section proto value indicates use of RTP: * If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps. Note that this situation will only occur when applying an offer. + Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section indices established when creating the offer. + Set the value of this RtpTransceiver's mid property to the MID of the m= section. * If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in [RFC5761], Section 5.1.3. * For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 6. * If the MID header extension is supported, prepare to demux RTP streams intended for this m= section based on the MID header extension, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 15. * For each specified media format, establish a mapping between the payload type and the actual media format, as described in [RFC3264], Section 6.1. In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. * For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in [RFC4588], Sections 8.6 and 8.7. Uberti, et al. Expires August 31, 2019 [Page 66] Internet-Draft JSEP February 2019 * If the directional attribute is of type "sendrecv" or "recvonly", enable receipt and decoding of media. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11 below. 5.10. Applying a Remote Description The following steps are performed to apply a remote description. If an error is returned, the session MUST be restored to the state it was in before performing these steps. If the answer contains any "a=ice-options" attributes where "trickle" is listed as an attribute, update the PeerConnection canTrickle property to be true. Otherwise, set this property to false. The following steps MUST be performed for attributes at the session level; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. o For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in [RFC4566], Section 5.8. Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between m= sections, respecting any specific limits that have been specified for individual m= sections. o For any specified "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. o Any "AS" bandwidth value MUST be ignored, as the meaning of this construct at the session level is not well defined. For each m= section, the following steps MUST be performed; if any parameters are out of bounds, or cannot be applied, processing MUST stop and an error MUST be returned. o If the ICE ufrag or password changed from the previous remote description: * If the description is of type "offer", the implementation MUST note that an ICE restart is needed, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.1.1.1 * If the description is of type "answer" or "pranswer", then check to see if the current local description is an ICE restart, and if not, generate an error. If the PeerConnection state is "have-remote-pranswer", and the ICE ufrag or password Uberti, et al. Expires August 31, 2019 [Page 67] Internet-Draft JSEP February 2019 changed from the previous provisional answer, then signal the ICE agent to discard any previous ICE check list state for the m= section. Finally, signal the ICE agent to begin checks. o If the current local description indicates an ICE restart, and either the ICE ufrag or password has not changed from the previous remote description, as prescribed by [RFC8445], Section 9, generate an error. o Configure the ICE components associated with this media section to use the supplied ICE remote ufrag and password for their connectivity checks. o Pair any supplied ICE candidates with any gathered local candidates, as described in [RFC8445], Section 6.1.2, and start connectivity checks with the appropriate credentials. o If an "a=end-of-candidates" attribute is present, process the end- of-candidates indication as described in [I-D.ietf-ice-trickle], Section 11. o If the m= section proto value indicates use of RTP: * If the m= section is being recycled (see Section 5.2.2), dissociate the currently associated RtpTransceiver by setting its mid property to null, and discard the mapping between the transceiver and its m= section index. * If the m= section is not associated with any RtpTransceiver (possibly because it was dissociated in the previous step), either find an RtpTransceiver or create one according to the following steps: + If the m= section is sendrecv or recvonly, and there are RtpTransceivers of the same type that were added to the PeerConnection by addTrack and are not associated with any m= section and are not stopped, find the first (according to the canonical order described in Section 5.2.1) such RtpTransceiver. + If no RtpTransceiver was found in the previous step, create one with a recvonly direction. + Associate the found or created RtpTransceiver with the m= section by setting the value of the RtpTransceiver's mid property to the MID of the m= section, and establish a mapping between the transceiver and the index of the m= section. If the m= section does not include a MID (i.e., Uberti, et al. Expires August 31, 2019 [Page 68] Internet-Draft JSEP February 2019 the remote endpoint does not support the MID extension), generate a value for the RtpTransceiver mid property, following the guidance for "a=mid" mentioned in Section 5.2.1. * For each specified media format that is also supported by the local implementation, establish a mapping between the specified payload type and the media format, as described in [RFC3264], Section 6.1. Specifically, this means that the implementation records the payload type to be used in outgoing RTP packets when sending each specified media format, as well as the relative preference for each format that is indicated in their ordering. If any indicated media format is not supported by the local implementation, it MUST be ignored. * For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload type, as described in [RFC4588], Section 4. If any referenced primary payload types are not present, this MUST result in an error. Note that RTX payload types may refer to primary payload types which are not supported by the local media implementation, in which case, the RTX payload type MUST also be ignored. * For each specified fmtp parameter that is supported by the local implementation, enable them on the associated media formats. * For each specified SSRC that is signaled in the m= section, prepare to demux RTP streams intended for this m= section using that SSRC, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. * For each specified RTP header extension that is also supported by the local implementation, establish a mapping between the extension ID and URI, as described in [RFC5285], Section 5. Specifically, this means that the implementation records the extension ID to be used in outgoing RTP packets when sending each specified header extension. If any indicated RTP header extension is not supported by the local implementation, it MUST be ignored. * For each specified RTCP feedback mechanism that is supported by the local implementation, enable them on the associated media formats. * For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending Uberti, et al. Expires August 31, 2019 [Page 69] Internet-Draft JSEP February 2019 media, as specified in [RFC3890]. If a "TIAS" value is not present, but an "AS" value is specified, generate a "TIAS" value using this formula: TIAS = AS * 1000 * 0.95 - (50 * 40 * 8) The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate 5% to RTCP. "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. * For any "RR" or "RS" bandwidth values, handle as specified in [RFC3556], Section 2. * Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. * If the m= section is of type audio: + For each specified "CN" media format, configure silence suppression for all supported media formats with the same clockrate, as described in [RFC3389], Section 5, except for formats that have their own internal silence suppression mechanisms. Silence suppression for such formats (e.g., Opus) is controlled via fmtp parameters, as discussed in Section 5.2.3.2. + For each specified "telephone-event" media format, enable DTMF transmission for all supported media formats with the same clockrate, as described in [RFC4733], Section 2.5.1.2. If there are any supported media formats that do not have a corresponding telephone-event format, disable DTMF transmission for those formats. + For any specified "ptime" value, configure the available media formats to use the specified packet size when sending. If the specified size is not supported for a media format, use the next closest value instead. Finally, if this description is of type "pranswer" or "answer", follow the processing defined in Section 5.11 below. Uberti, et al. Expires August 31, 2019 [Page 70] Internet-Draft JSEP February 2019 5.11. Applying an Answer In addition to the steps mentioned above for processing a local or remote description, the following steps are performed when processing a description of type "pranswer" or "answer". For each m= section, the following steps MUST be performed: o If the m= section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for this section, and, unless a non-rejected m= section is bundled with this m= section, discard any associated ICE components, as described in [I-D.ietf-mmusic-ice-sip-sdp], Section 3.4.3.1. o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. Note that although JSEP requires that answerers change the tls-id value if and only if the offerer does, non-JSEP answerers are permitted to change the tls-id as long as the offer contained an ICE restart. Thus, JSEP implementations which process DTLS data prior to receiving an answer MUST be prepared to receive either a ClientHello or data from the previous DTLS connection. o If no valid DTLS connection exists, prepare to start a DTLS connection, using the specified roles and fingerprints, on any underlying ICE components, once they are active. o If the m= section proto value indicates use of RTP: * If the m= section references RTCP feedback mechanisms that were not present in the corresponding m= section in the offer, this indicates a negotiation problem and MUST result in an error. However, new media formats and new RTP header extension values are permitted in the answer, as described in [RFC3264], Section 7, and [RFC5285], Section 6. * If the m= section has RTCP mux enabled, discard the RTCP ICE component, if one exists, and begin or continue muxing RTCP over the RTP ICE component, as specified in [RFC5761], Section 5.1.3. Otherwise, prepare to transmit RTCP over the Uberti, et al. Expires August 31, 2019 [Page 71] Internet-Draft JSEP February 2019 RTCP ICE component; if no RTCP ICE component exists, because RTCP mux was previously enabled, this MUST result in an error. * If the m= section has reduced-size RTCP enabled, configure the RTCP transmission for this m= section to use reduced-size RTCP, as specified in [RFC5506]. * If the directional attribute in the answer indicates that the JSEP implementation should be sending media ("sendonly" for local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is also locally supported, as discussed in [RFC3264], Sections 6.1 and 7, and start transmitting RTP media using that format once the underlying transport layers have been established. If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one. If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as specified in [RFC7160], Section 3.1. * The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including the payload type for the send media format chosen above. Any RTP header extensions that were negotiated should be included in the outgoing RTP streams, using the extension mapping from the remote description; if the RID header extension has been negotiated, and RID values are specified, include the RID header extension in the outgoing RTP streams, as indicated in [I-D.ietf-mmusic-rid], Section 4. * If the m= section is of type audio, and silence suppression was configured for the send media format as a result of processing the remote description, and is also enabled for that format in the local description, use silence suppression for outgoing media, in accordance with the guidance in Section 5.2.3.2. If these conditions are not met, silence suppression MUST NOT be used for outgoing media. * If simulcast has been negotiated, send the number of Source RTP Streams as specified in [I-D.ietf-mmusic-sdp-simulcast], Section 6.2.2. * If the send media format chosen above has a corresponding "rtx" media format, or a FEC mechanism has been negotiated, establish a Redundancy RTP Stream with a random SSRC for each Source RTP Stream, and start or continue transmitting RTX/FEC packets as needed. Uberti, et al. Expires August 31, 2019 [Page 72] Internet-Draft JSEP February 2019 * If the send media format chosen above has a corresponding "red" media format of the same clockrate, allow redundant encoding using the specified format for resiliency purposes, as discussed in [I-D.ietf-rtcweb-fec], Section 3.2. Note that unlike RTX or FEC media formats, the "red" format is transmitted on the Source RTP Stream, not the Redundancy RTP Stream. * Enable the RTCP feedback mechanisms referenced in the media section for all Source RTP Streams using the specified media formats. Specifically, begin or continue sending the requested feedback types and reacting to received feedback, as specified in [RFC4585], Section 4.2. When sending RTCP feedback, follow the rules and recommendations from [RFC8108] Section 5.4.1, to select which SSRC to use. * If the directional attribute in the answer indicates that the JSEP implementation should not be sending media ("recvonly" for local answers, "sendonly" for remote answers, or "inactive" for either type of answer) stop transmitting all RTP media, but continue sending RTCP, as described in [RFC3264], Section 5.1. o If the m= section proto value indicates use of SCTP: * If an SCTP association exists, and the remote SCTP port has changed, discard the existing SCTP association. This includes the case when the PeerConnection state is "have-remote- pranswer". * If no valid SCTP association exists, prepare to initiate a SCTP association over the associated ICE component and DTLS connection, using the local SCTP port value from the local description, and the remote SCTP port value from the remote description, as described in [I-D.ietf-mmusic-sctp-sdp], Section 10.2. If the answer contains valid bundle groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these m= sections accordingly, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. If the description is of type "answer", and there are still remaining candidates in the ICE candidate pool, discard them. Uberti, et al. Expires August 31, 2019 [Page 73] Internet-Draft JSEP February 2019 6. Processing RTP/RTCP When bundling, associating incoming RTP/RTCP with the proper m= section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. When not bundling, the proper m= section is clear from the ICE component over which the RTP/RTCP is received. Once the proper m= section(s) are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the m= section(s) and further processing of the RTP/RTCP is done at the RtpTransceiver level. This includes using RID [I-D.ietf-mmusic-rid] to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream. 7. Examples Note that this example section shows several SDP fragments. To format in 72 columns, some of the lines in SDP have been split into multiple lines, where leading whitespace indicates that a line is a continuation of the previous line. In addition, some blank lines have been added to improve readability but are not valid in SDP. More examples of SDP for WebRTC call flows, including examples with IPv6 addresses, can be found in [I-D.ietf-rtcweb-sdp]. 7.1. Simple Example This section shows a very simple example that sets up a minimal audio / video call between two JSEP endpoints without using trickle ICE. The example in the following section provides a more detailed example of what could happen in a JSEP session. The code flow below shows Alice's endpoint initiating the session to Bob's endpoint. The messages from the JavaScript application in Alice's browser to the JavaScript in Bob's browser, abbreviated as AliceJS and BobJS respectively, are assumed to flow over some signaling protocol via a web server. The JavaScript on both Alice's side and Bob's side waits for all candidates before sending the offer or answer, so the offers and answers are complete; trickle ICE is not used. The user agents (JSEP implementations) in Alice and Bob's browsers, abbreviated as AliceUA and BobUA respectively, are using the default bundle policy of "balanced", and the default RTCP mux policy of "require". Uberti, et al. Expires August 31, 2019 [Page 74] Internet-Draft JSEP February 2019 // set up local media state AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: createOffer to get offer AliceJS->AliceUA: setLocalDescription with offer AliceUA->AliceJS: multiple onicecandidate events with candidates // wait for ICE gathering to complete AliceUA->AliceJS: onicecandidate event with null candidate AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription // |offer-A1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-A1| WebServer->BobJS: signaling with |offer-A1| // |offer-A1| arrives at Bob BobJS->BobUA: create a PeerConnection BobJS->BobUA: setRemoteDescription with |offer-A1| BobUA->BobJS: ontrack events for audio and video tracks // Bob accepts call BobJS->BobUA: addTrack with local tracks BobJS->BobUA: createAnswer BobJS->BobUA: setLocalDescription with answer BobUA->BobJS: multiple onicecandidate events with candidates // wait for ICE gathering to complete BobUA->BobJS: onicecandidate event with null candidate BobJS->BobUA: get |answer-A1| from currentLocalDescription // |answer-A1| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |answer-A1| WebServer->AliceJS: signaling with |answer-A1| // |answer-A1| arrives at Alice AliceJS->AliceUA: setRemoteDescription with |answer-A1| AliceUA->AliceJS: ontrack events for audio and video tracks // media flows BobUA->AliceUA: media sent from Bob to Alice AliceUA->BobUA: media sent from Alice to Bob The SDP for |offer-A1| looks like: v=0 o=- 4962303333179871722 1 IN IP4 0.0.0.0 Uberti, et al. Expires August 31, 2019 [Page 75] Internet-Draft JSEP February 2019 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 203.0.113.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:47017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ETEn a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10101 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host a=end-of-candidates m=video 10102 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.100 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id Uberti, et al. Expires August 31, 2019 [Page 76] Internet-Draft JSEP February 2019 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:47017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:BGKk a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:91bbf309c0990a6bec11e38ba2933cee a=rtcp:10103 IN IP4 203.0.113.100 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host a=end-of-candidates The SDP for |answer-A1| looks like: v=0 o=- 6729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 203.0.113.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:6sFv a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 Uberti, et al. Expires August 31, 2019 [Page 77] Internet-Draft JSEP February 2019 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=tls-id:eec3392ab83e11ceb6a0990c903fbb19 a=rtcp-mux a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=end-of-candidates m=video 10200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 203.0.113.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 7.2. Detailed Example This section shows a more involved example of a session between two JSEP endpoints. Trickle ICE is used in full trickle mode, with a bundle policy of "max-bundle", an RTCP mux policy of "require", and a single TURN server. Initially, both Alice and Bob establish an audio channel and a data channel. Later, Bob adds two video flows, one for his video feed, and one for screensharing, both supporting FEC, and with the video feed configured for simulcast. Alice accepts these video flows, but does not add video flows of her own, so they are handled as recvonly. Alice also specifies a maximum video decoder resolution. // set up local media state AliceJS->AliceUA: create new PeerConnection AliceJS->AliceUA: addTrack with an audio track AliceJS->AliceUA: createDataChannel to get data channel AliceJS->AliceUA: createOffer to get |offer-B1| AliceJS->AliceUA: setLocalDescription with |offer-B1| Uberti, et al. Expires August 31, 2019 [Page 78] Internet-Draft JSEP February 2019 // |offer-B1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-B1| WebServer->BobJS: signaling with |offer-B1| // |offer-B1| arrives at Bob BobJS->BobUA: create a PeerConnection BobJS->BobUA: setRemoteDescription with |offer-B1| BobUA->BobJS: ontrack with audio track from Alice // candidates are sent to Bob AliceUA->AliceJS: onicecandidate (host) |offer-B1-candidate-1| AliceJS->WebServer: signaling with |offer-B1-candidate-1| AliceUA->AliceJS: onicecandidate (srflx) |offer-B1-candidate-2| AliceJS->WebServer: signaling with |offer-B1-candidate-2| AliceUA->AliceJS: onicecandidate (relay) |offer-B1-candidate-3| AliceJS->WebServer: signaling with |offer-B1-candidate-3| WebServer->BobJS: signaling with |offer-B1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-1| WebServer->BobJS: signaling with |offer-B1-candidate-2| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-2| WebServer->BobJS: signaling with |offer-B1-candidate-3| BobJS->BobUA: addIceCandidate with |offer-B1-candidate-3| // Bob accepts call BobJS->BobUA: addTrack with local audio BobJS->BobUA: createDataChannel to get data channel BobJS->BobUA: createAnswer to get |answer-B1| BobJS->BobUA: setLocalDescription with |answer-B1| // |answer-B1| is sent to Alice BobJS->WebServer: signaling with |answer-B1| WebServer->AliceJS: signaling with |answer-B1| AliceJS->AliceUA: setRemoteDescription with |answer-B1| AliceUA->AliceJS: ontrack event with audio track from Bob // candidates are sent to Alice BobUA->BobJS: onicecandidate (host) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| BobUA->BobJS: onicecandidate (srflx) |answer-B1-candidate-2| BobJS->WebServer: signaling with |answer-B1-candidate-2| BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-3| BobJS->WebServer: signaling with |answer-B1-candidate-3| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-2| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-2| Uberti, et al. Expires August 31, 2019 [Page 79] Internet-Draft JSEP February 2019 WebServer->AliceJS: signaling with |answer-B1-candidate-3| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-3| // data channel opens BobUA->BobJS: ondatachannel event AliceUA->AliceJS: ondatachannel event BobUA->BobJS: onopen AliceUA->AliceJS: onopen // media is flowing between endpoints BobUA->AliceUA: audio+data sent from Bob to Alice AliceUA->BobUA: audio+data sent from Alice to Bob // some time later Bob adds two video streams // note, no candidates exchanged, because of bundle BobJS->BobUA: addTrack with first video stream BobJS->BobUA: addTrack with second video stream BobJS->BobUA: createOffer to get |offer-B2| BobJS->BobUA: setLocalDescription with |offer-B2| // |offer-B2| is sent to Alice BobJS->WebServer: signaling with |offer-B2| WebServer->AliceJS: signaling with |offer-B2| AliceJS->AliceUA: setRemoteDescription with |offer-B2| AliceUA->AliceJS: ontrack event with first video track AliceUA->AliceJS: ontrack event with second video track AliceJS->AliceUA: createAnswer to get |answer-B2| AliceJS->AliceUA: setLocalDescription with |answer-B2| // |answer-B2| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |answer-B2| WebServer->BobJS: signaling with |answer-B2| BobJS->BobUA: setRemoteDescription with |answer-B2| // media is flowing between endpoints BobUA->AliceUA: audio+video+data sent from Bob to Alice AliceUA->BobUA: audio+video+data sent from Alice to Bob The SDP for |offer-B1| looks like: Uberti, et al. Expires August 31, 2019 [Page 80] Internet-Draft JSEP February 2019 v=0 o=- 4962303333179871723 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:actpass a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 0 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 a=bundle-only |offer-B1-candidate-1| looks like: Uberti, et al. Expires August 31, 2019 [Page 81] Internet-Draft JSEP February 2019 ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host |offer-B1-candidate-2| looks like: ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 |offer-B1-candidate-3| looks like: ufrag ATEn index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 The SDP for |answer-B1| looks like: Uberti, et al. Expires August 31, 2019 [Page 82] Internet-Draft JSEP February 2019 v=0 o=- 7729291447651054566 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:active a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 |answer-B1-candidate-1| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host Uberti, et al. Expires August 31, 2019 [Page 83] Internet-Draft JSEP February 2019 |answer-B1-candidate-2| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 |answer-B1-candidate-3| looks like: ufrag 7sFv index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 The SDP for |offer-B2| is shown below. In addition to the new m= sections for video, both of which are offering FEC, and one of which is offering simulcast, note the increment of the version number in the o= line, changes to the c= line, indicating the local candidate that was selected, and the inclusion of gathered candidates as a=candidate lines. v=0 o=- 7729291447651054566 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 v1 v2 a=group:LS a1 v1 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 Uberti, et al. Expires August 31, 2019 [Page 84] Internet-Draft JSEP February 2019 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=ice-ufrag:7sFv a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 a=fingerprint:sha-256 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 a=setup:actpass a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host a=candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx raddr 203.0.113.200 rport 10200 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 198.51.100.200 rport 11200 a=end-of-candidates m=application 12200 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.200 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 c=IN IP4 192.0.2.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=rtpmap:104 flexfec/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae a=rid:1 send a=rid:2 send a=rid:3 send a=simulcast:send 1;2;3 Uberti, et al. Expires August 31, 2019 [Page 85] Internet-Draft JSEP February 2019 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 c=IN IP4 192.0.2.200 a=mid:v2 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=rtpmap:104 flexfec/90000 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae The SDP for |answer-B2| is shown below. In addition to the acceptance of the video m= sections, the use of a=recvonly to indicate one-way video, and the use of a=imageattr to limit the received resolution, note the use of setup:passive to maintain the existing DTLS roles. v=0 o=- 4962303333179871723 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 d1 v1 v2 a=group:LS a1 v1 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid Uberti, et al. Expires August 31, 2019 [Page 86] Internet-Draft JSEP February 2019 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:57017fee-b6c1-4162-929c-a25110252400 a=ice-ufrag:ATEn a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=setup:passive a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100 a=end-of-candidates m=application 12100 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 192.0.2.100 a=mid:d1 a=sctp-port:5000 a=max-message-size:65536 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 a=recvonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v2 a=recvonly a=rtpmap:100 VP8/90000 Uberti, et al. Expires August 31, 2019 [Page 87] Internet-Draft JSEP February 2019 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli 7.3. Early Transport Warmup Example This example demonstrates the early warmup technique described in Section 4.1.8.1. Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call. Bob immediately responds with an answer that accepts the audio/video m= sections, but marks them as sendonly (from his perspective), meaning that Alice will not yet send media. This allows the JSEP implementation to start negotiating ICE and DTLS immediately. Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends a second offer which enables the audio and video m= sections, and thereby bidirectional media transmission. The advantage of such a flow is that as soon as the first answer is received, the implementation can proceed with ICE and DTLS negotiation and establish the session transport. If the transport setup completes before the second offer is sent, then media can be transmitted immediately by the callee immediately upon answering the call, minimizing perceived post-dial-delay. The second offer/answer exchange can also change the preferred codecs or other session parameters. This example also makes use of the "relay" ICE candidate policy described in Section 3.5.3 to minimize the ICE gathering and checking needed. // set up local media state AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy AliceJS->AliceUA: addTrack with two tracks: audio and video AliceJS->AliceUA: createOffer to get |offer-C1| AliceJS->AliceUA: setLocalDescription with |offer-C1| // |offer-C1| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |offer-C1| WebServer->BobJS: signaling with |offer-C1| Uberti, et al. Expires August 31, 2019 [Page 88] Internet-Draft JSEP February 2019 // |offer-C1| arrives at Bob BobJS->BobUA: create new PeerConnection with "relay" ICE policy BobJS->BobUA: setRemoteDescription with |offer-C1| BobUA->BobJS: ontrack events for audio and video // a relay candidate is sent to Bob AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1| AliceJS->WebServer: signaling with |offer-C1-candidate-1| WebServer->BobJS: signaling with |offer-C1-candidate-1| BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1| // Bob prepares an early answer to warmup the transport BobJS->BobUA: addTransceiver with null audio and video tracks BobJS->BobUA: transceiver.setDirection(sendonly) for both BobJS->BobUA: createAnswer BobJS->BobUA: setLocalDescription with answer // |answer-C1| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |answer-C1| WebServer->AliceJS: signaling with |answer-C1| // |answer-C1| (sendonly) arrives at Alice AliceJS->AliceUA: setRemoteDescription with |answer-C1| AliceUA->AliceJS: ontrack events for audio and video // a relay candidate is sent to Alice BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| BobJS->WebServer: signaling with |answer-B1-candidate-1| WebServer->AliceJS: signaling with |answer-B1-candidate-1| AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| // ICE and DTLS establish while call is ringing // Bob accepts call, starts media, and sends new offer BobJS->BobUA: transceiver.setTrack with audio and video tracks BobUA->AliceUA: media sent from Bob to Alice BobJS->BobUA: transceiver.setDirection(sendrecv) for both transceivers BobJS->BobUA: createOffer BobJS->BobUA: setLocalDescription with offer // |offer-C2| is sent over signaling protocol to Alice BobJS->WebServer: signaling with |offer-C2| WebServer->AliceJS: signaling with |offer-C2| // |offer-C2| (sendrecv) arrives at Alice Uberti, et al. Expires August 31, 2019 [Page 89] Internet-Draft JSEP February 2019 AliceJS->AliceUA: setRemoteDescription with |offer-C2| AliceJS->AliceUA: createAnswer AliceJS->AliceUA: setLocalDescription with |answer-C2| AliceUA->BobUA: media sent from Alice to Bob // |answer-C2| is sent over signaling protocol to Bob AliceJS->WebServer: signaling with |answer-C2| WebServer->BobJS: signaling with |answer-C2| BobJS->BobUA: setRemoteDescription with |answer-C2| The SDP for |offer-C1| looks like: v=0 o=- 1070771854436052752 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:actpass a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize Uberti, et al. Expires August 31, 2019 [Page 90] Internet-Draft JSEP February 2019 m=video 0 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=bundle-only |offer-C1-candidate-1| looks like: ufrag 4ZcD index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 0.0.0.0 rport 0 The SDP for |answer-C1| looks like: v=0 o=- 6386516489780559513 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 0.0.0.0 a=mid:a1 a=sendonly a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 Uberti, et al. Expires August 31, 2019 [Page 91] Internet-Draft JSEP February 2019 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:active a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize m=video 9 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 0.0.0.0 a=mid:v1 a=sendonly a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:751f239e-4ae0-c549-aa3d-890de772998b |answer-C1-candidate-1| looks like: ufrag TpaA index 0 mid a1 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 Uberti, et al. Expires August 31, 2019 [Page 92] Internet-Draft JSEP February 2019 The SDP for |offer-C2| looks like: v=0 o=- 6386516489780559513 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.200 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:751f239e-4ae0-c549-aa3d-890de772998b a=ice-ufrag:TpaA a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ a=fingerprint:sha-256 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D a=setup:actpass a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.200 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 Uberti, et al. Expires August 31, 2019 [Page 93] Internet-Draft JSEP February 2019 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:751f239e-4ae0-c549-aa3d-890de772998b The SDP for |answer-C2| looks like: v=0 o=- 1070771854436052752 2 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle ice2 a=group:BUNDLE a1 v1 a=group:LS a1 v1 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 c=IN IP4 192.0.2.100 a=mid:a1 a=sendrecv a=rtpmap:96 opus/48000/2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=rtpmap:98 telephone-event/48000 a=fmtp:97 0-15 a=fmtp:98 0-15 a=maxptime:120 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce a=ice-ufrag:4ZcD a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD a=fingerprint:sha-256 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF a=setup:passive a=tls-id:9e5b948ade9c3d41de6617b68f769e55 a=rtcp-mux a=rtcp-mux-only a=rtcp-rsize a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay Uberti, et al. Expires August 31, 2019 [Page 94] Internet-Draft JSEP February 2019 raddr 0.0.0.0 rport 0 a=end-of-candidates m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 c=IN IP4 192.0.2.100 a=mid:v1 a=sendrecv a=rtpmap:100 VP8/90000 a=rtpmap:101 H264/90000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f a=rtpmap:102 rtx/90000 a=fmtp:102 apt=100 =rtpmap:103 rtx/90000 a=fmtp:103 apt=101 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 8. Security Considerations The IETF has published separate documents [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing the security architecture for WebRTC as a whole. The remainder of this section describes security considerations for this document. While formally the JSEP interface is an API, it is better to think of it as an Internet protocol, with the application JavaScript being untrustworthy from the perspective of the JSEP implementation. Thus, the threat model of [RFC3552] applies. In particular, JavaScript can call the API in any order and with any inputs, including malicious ones. This is particularly relevant when we consider the SDP which is passed to setLocalDescription(). While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior. One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side. Thus, for instance, it is not possible to prevent the remote peer from Uberti, et al. Expires August 31, 2019 [Page 95] Internet-Draft JSEP February 2019 learning your public IP address by removing server reflexive candidates. Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. 9. IANA Considerations This document requires no actions from IANA. 10. Acknowledgements Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter Thatcher provided significant text for this draft. Bernard Aboba, Adam Bergkvist, Dan Burnett, Ben Campbell, Alissa Cooper, Richard Ejzak, Stefan Hakansson, Ted Hardie, Christer Holmberg Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, Sean Turner, and Magnus Westerlund all provided valuable feedback on this proposal. 11. References 11.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-21 (work in progress), April 2018. [I-D.ietf-mmusic-dtls-sdp] Holmberg, C. and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)", draft-ietf-mmusic-dtls-sdp-32 (work in progress), October 2017. [I-D.ietf-mmusic-ice-sip-sdp] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-sip-sdp-24 (work in progress), November 2018. Uberti, et al. Expires August 31, 2019 [Page 96] Internet-Draft JSEP February 2019 [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-17 (work in progress), December 2018. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-12 (work in progress), May 2017. [I-D.ietf-mmusic-rid] Roach, A., "RTP Payload Format Restrictions", draft-ietf- mmusic-rid-15 (work in progress), May 2018. [I-D.ietf-mmusic-sctp-sdp] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, "Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.", draft-ietf-mmusic-sctp-sdp-26 (work in progress), April 2017. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-54 (work in progress), December 2018. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 (work in progress), February 2018. [I-D.ietf-mmusic-sdp-simulcast] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, "Using Simulcast in SDP and RTP Sessions", draft-ietf- mmusic-sdp-simulcast-13 (work in progress), June 2018. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-08 (work in progress), March 2018. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 2016. Uberti, et al. Expires August 31, 2019 [Page 97] Internet-Draft JSEP February 2019 [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-11 (work in progress), February 2019. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, . [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, . Uberti, et al. Expires August 31, 2019 [Page 98] Internet-Draft JSEP February 2019 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, . [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in the Session Description Protocol (SDP)", RFC 6236, DOI 10.17487/RFC6236, May 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, September 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . Uberti, et al. Expires August 31, 2019 [Page 99] Internet-Draft JSEP February 2019 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, . [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, . [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . 11.2. Informative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", draft-ietf- mmusic-trickle-ice-sip-18 (work in progress), June 2018. Uberti, et al. Expires August 31, 2019 [Page 100] Internet-Draft JSEP February 2019 [I-D.ietf-rtcweb-ip-handling] Uberti, J., "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-11 (work in progress), November 2018. [I-D.ietf-rtcweb-sdp] Nandakumar, S. and C. Jennings, "Annotated Example SDP for WebRTC", draft-ietf-rtcweb-sdp-11 (work in progress), October 2018. [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, September 2002, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, DOI 10.17487/RFC3960, December 2004, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, DOI 10.17487/RFC4733, December 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . Uberti, et al. Expires August 31, 2019 [Page 101] Internet-Draft JSEP February 2019 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, . [TS26.114] 3GPP TS 26.114 V12.8.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (Release 12)", December 2014, . [W3C.webrtc] Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Aboba, B., and T. Brandstetter, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20170515, May 2017, . Uberti, et al. Expires August 31, 2019 [Page 102] Internet-Draft JSEP February 2019 Appendix A. Appendix A For the syntax validation performed in Section 5.8, the following list of ABNF definitions is used: Uberti, et al. Expires August 31, 2019 [Page 103] Internet-Draft JSEP February 2019 +------------------------+------------------------------------------+ | Attribute | Reference | +------------------------+------------------------------------------+ | ptime | [RFC4566] Section 9 | | maxptime | [RFC4566] Section 9 | | rtpmap | [RFC4566] Section 9 | | recvonly | [RFC4566] Section 9 | | sendrecv | [RFC4566] Section 9 | | sendonly | [RFC4566] Section 9 | | inactive | [RFC4566] Section 9 | | framerate | [RFC4566] Section 9 | | fmtp | [RFC4566] Section 9 | | quality | [RFC4566] Section 9 | | rtcp | [RFC3605] Section 2.1 | | setup | [RFC4145] Sections 3, 4, and 5 | | connection | [RFC4145] Sections 3, 4, and 5 | | fingerprint | [RFC8122] Section 5 | | rtcp-fb | [RFC4585] Section 4.2 | | extmap | [RFC5285] Section 7 | | mid | [RFC5888] Sections 4 and 5 | | group | [RFC5888] Sections 4 and 5 | | imageattr | [RFC6236] Section 3.1 | | extmap (encrypt | [RFC6904] Section 4 | | option) | | | candidate | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.1 | | remote-candidates | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.2 | | ice-lite | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.3 | | ice-ufrag | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.4 | | ice-pwd | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.4 | | ice-options | [I-D.ietf-mmusic-ice-sip-sdp] Section | | | 4.6 | | msid | [I-D.ietf-mmusic-msid] Section 2 | | rid | [I-D.ietf-mmusic-rid] Section 10 | | simulcast | [I-D.ietf-mmusic-sdp-simulcast] Section | | | 6.1 | | tls-id | [I-D.ietf-mmusic-dtls-sdp] Section 4 | +------------------------+------------------------------------------+ Table 1: SDP ABNF References Uberti, et al. Expires August 31, 2019 [Page 104] Internet-Draft JSEP February 2019 Appendix B. Change log Note to RFC Editor: Please remove this section before publication. Changes in draft-26: o Update guidance on generation of the m= proto value to be consistent with ice-sip-sdp. Changes in draft-25: o Remove MSID track ID from offers and answers. o Add note about rejecting all m= sections in a BUNDLE group. o Update ICE references to RFC 8445 and mention ice2. Changes in draft-24: o Clarify that rounding is permitted when trying to maintain aspect ratio. o Update tls-id handling to match what is specified in dtls-sdp. Changes in draft-23: o Clarify rollback handling, and treat it similarly to other setLocal/setRemote usages. o Adopt a first-fit policy for handling multiple remote a=imageattr attributes. o Clarify that a session description with zero m= sections is legal. Changes in draft-22: o Clarify currentDirection versus direction. o Correct session-id text so that it aligns with RFC 3264. o Clarify that generated ICE candidate objects must have all four fields. o Make rollback work from any state besides stable and regardless of whether setLocalDescription or setRemoteDescription is used. o Allow modifying SDP before sending or after receiving either offers or answers (previously this was forbidden for answers). Uberti, et al. Expires August 31, 2019 [Page 105] Internet-Draft JSEP February 2019 o Provide rationale for several design choices. Changes in draft-21: o Change dtls-id to tls-id to match MMUSIC draft. o Replace regular expression for proto field with a list and clarify that the answer must exactly match the offer. o Remove text about how to error check on setLocal because local descriptions cannot be changed. o Rework silence suppression support to always require that both sides agree to silence suppression or none is used. o Remove instructions to parse "a=ssrc-group". o Allow the addition of new codecs in answers and in subsequent offers. o Clarify imageattr processing. Replace use of [x=0,y=0] with direction indicators. o Document when early media can occur. o Fix ICE default port handling when bundle-only is used. o Forbid duplicating IDENTICAL/TRANSPORT attributes when you are bundling. o Clarify the number of components to gather when bundle is involved. o Explicitly state that PTs and SSRCs are to be used for demuxing. o Update guidance on "a=setup" line. This should now match the MMUSIC draft. o Update guidance on certificate/digest matching to conform to RFC8122. o Update examples. Changes in draft-20: o Remove Appendix-B. Changes in draft-19: Uberti, et al. Expires August 31, 2019 [Page 106] Internet-Draft JSEP February 2019 o Examples are now machine-generated for correctness, and use IETF- approved example IP addresses. o Add early transport warmup example, and add missing attributes to existing examples. o Only send "a=rtcp-mux-only" and "a=bundle-only" on new m= sections. o Update references. o Add coverage of a=identity. o Explain the lipsync group algorithm more thoroughly. o Remove unnecessary list of MTI specs. o Allow codecs which weren't offered to appear in answers and which weren't selected to appear in subsequent offers. o Codec preferences now are applied on both initial and subsequent offers and answers. o Clarify a=msid handling for recvonly m= sections. o Clarify behavior of attributes for bundle-only data channels. o Allow media attributes to appear in data m= sections when all the media m= sections are bundle-only. o Use consistent terminology for JSEP implementations. o Describe how to handle failed API calls. o Some cleanup on routing rules. Changes in draft-18: o Update demux algorithm and move it to an appendix in preparation for merging it into BUNDLE. o Clarify why we can't handle an incoming offer to send simulcast. o Expand IceCandidate object text. o Further document use of ICE candidate pool. o Document removeTrack. Uberti, et al. Expires August 31, 2019 [Page 107] Internet-Draft JSEP February 2019 o Update requirements to only accept the last generated offer/answer as an argument to setLocalDescription. o Allow round pixels. o Fix code around default timing when AVPF is not specified. o Clean up terminology around m= line and m=section. o Provide a more realistic example for minimum decoder capabilities. o Document behavior when rtcp-mux policy is require but rtcp-mux attribute not provided. o Expanded discussion of RtpSender and RtpReceiver. o Add RtpTransceiver.currentDirection and document setDirection. o Require imageattr x=0, y=0 to indicate that there are no valid resolutions. o Require a privacy-preserving MID/RID construction. o Require support for RFC 3556 bandwidth modifiers. o Update maxptime description. o Note that endpoints may encounter extra codecs in answers and subsequent offers from non-JSEP peers. o Update references. Changes in draft-17: o Split createOffer and createAnswer sections to clearly indicate attributes which always appear and which only appear when not bundled into another m= section. o Add descriptions of RtpTransceiver methods. o Describe how to process RTCP feedback attributes. o Clarify transceiver directions and their interaction with 3264. o Describe setCodecPreferences. o Update RTP demux algorithm. Include RTCP. Uberti, et al. Expires August 31, 2019 [Page 108] Internet-Draft JSEP February 2019 o Update requirements for when a=rtcp is included, limiting to cases where it is needed for backward compatibility. o Clarify SAR handling. o Updated addTrack matching algorithm. o Remove a=ssrc requirements. o Handle a=setup in reoffers. o Discuss how RTX/FEC should be handled. o Discuss how telephone-event should be handled. o Discuss how CN/DTX should be handled. o Add missing references to ABNF table. Changes in draft-16: o Update addIceCandidate to indicate ICE generation and allow per-m= section end-of-candidates. o Update fingerprint handling to use draft-ietf-mmusic-4572-update. o Update text around SDP processing of RTP header extensions and payload formats. o Add sections on simulcast, addTransceiver, and createDataChannel. o Clarify text to ensure that the session ID is a positive 63 bit integer. o Clarify SDP processing for direction indication. o Describe SDP processing for rtcp-mux-only. o Specify how SDP session version in o= line. o Require that when doing an re-offer, the capabilities of the new session are mostly required to be a subset of the previously negotiated session. o Clarified ICE restart interaction with bundle-only. o Remove support for changing SDP before calling setLocalDescription. Uberti, et al. Expires August 31, 2019 [Page 109] Internet-Draft JSEP February 2019 o Specify algorithm for demuxing RTP based on MID, PT, and SSRC. o Clarify rules for rejecting m= lines when bundle policy is balanced or max-bundle. Changes in draft-15: o Clarify text around codecs offered in subsequent transactions to refer to what's been negotiated. o Rewrite LS handling text to indicate edge cases and that we're living with them. o Require that answerer reject m= lines when there are no codecs in common. o Enforce max-bundle on offer processing. o Fix TIAS formula to handle bits vs. kilobits. o Describe addTrack algorithm. o Clean up references. Changes in draft-14: o Added discussion of RtpTransceivers + RtpSenders + RtpReceivers, and how they interact with createOffer/createAnswer. o Removed obsolete OfferToReceiveX options. o Explained how addIceCandidate can be used for end-of-candidates. Changes in draft-13: o Clarified which SDP lines can be ignored. o Clarified how to handle various received attributes. o Revised how attributes should be generated for bundled m= lines. o Remove unused references. o Remove text advocating use of unilateral PTs. o Trigger an ICE restart even if the ICE candidate policy is being made more strict. Uberti, et al. Expires August 31, 2019 [Page 110] Internet-Draft JSEP February 2019 o Remove the 'public' ICE candidate policy. o Move open issues into GitHub issues. o Split local/remote description accessors into current/pending. o Clarify a=imageattr handling. o Add more detail on VoiceActivityDetection handling. o Reference draft-shieh-rtcweb-ip-handling. o Make it clear when an ICE restart should occur. o Resolve changes needed in references. o Remove MSID semantics. o ice-options are now at session level. o Default RTCP mux policy is now 'require'. Changes in draft-12: o Filled in sections on applying local and remote descriptions. o Discussed downscaling and upscaling to fulfill imageattr requirements. o Updated what SDP can be modified by the application. o Updated to latest datachannel SDP. o Allowed multiple fingerprint lines. o Switched back to IPv4 for dummy candidates. o Added additional clarity on ICE default candidates. Changes in draft-11: o Clarified handling of RTP CNAMEs. o Updated what SDP lines should be processed or ignored. o Specified how a=imageattr should be used. Changes in draft-10: Uberti, et al. Expires August 31, 2019 [Page 111] Internet-Draft JSEP February 2019 o Described video size negotiation with imageattr. o Clarified rejection of sections that do not have mux-only. o Add handling of LS groups Changes in draft-09: o Don't return null for {local,remote}Description after close(). o Changed TCP/TLS to UDP/DTLS in RTP profile names. o Separate out bundle and mux policy. o Added specific references to FEC mechanisms. o Added canTrickle mechanism. o Added section on subsequent answers and, answer options. o Added text defining set{Local,Remote}Description behavior. Changes in draft-08: o Added new example section and removed old examples in appendix. o Fixed field handling. o Added text describing a=rtcp attribute. o Reworked handling of OfferToReceiveAudio and OfferToReceiveVideo per discussion at IETF 90. o Reworked trickle ICE handling and its impact on m= and c= lines per discussion at interim. o Added max-bundle-and-rtcp-mux policy. o Added description of maxptime handling. o Updated ICE candidate pool default to 0. o Resolved open issues around AppID/receiver-ID. o Reworked and expanded how changes to the ICE configuration are handled. o Some reference updates. Uberti, et al. Expires August 31, 2019 [Page 112] Internet-Draft JSEP February 2019 o Editorial clarification. Changes in draft-07: o Expanded discussion of VAD and Opus DTX. o Added a security considerations section. o Rewrote the section on modifying SDP to require implementations to clearly indicate whether any given modification is allowed. o Clarified impact of IceRestart on CreateOffer in local-offer state. o Guidance on whether attributes should be defined at the media level or the session level. o Renamed "default" bundle policy to "balanced". o Removed default ICE candidate pool size and clarify how it works. o Defined a canonical order for assignment of MSTs to m= lines. o Removed discussion of rehydration. o Added Eric Rescorla as a draft editor. o Cleaned up references. o Editorial cleanup Changes in draft-06: o Reworked handling of m= line recycling. o Added handling of BUNDLE and bundle-only. o Clarified handling of rollback. o Added text describing the ICE Candidate Pool and its behavior. o Allowed OfferToReceiveX to create multiple recvonly m= sections. Changes in draft-05: o Fixed several issues identified in the createOffer/Answer sections during document review. Uberti, et al. Expires August 31, 2019 [Page 113] Internet-Draft JSEP February 2019 o Updated references. Changes in draft-04: o Filled in sections on createOffer and createAnswer. o Added SDP examples. o Fixed references. Changes in draft-03: o Added text describing relationship to W3C specification Changes in draft-02: o Converted from nroff o Removed comparisons to old approaches abandoned by the working group o Removed stuff that has moved to W3C specification o Align SDP handling with W3C draft o Clarified section on forking. Changes in draft-01: o Added diagrams for architecture and state machine. o Added sections on forking and rehydration. o Clarified meaning of "pranswer" and "answer". o Reworked how ICE restarts and media directions are controlled. o Added list of parameters that can be changed in a description. o Updated suggested API and examples to match latest thinking. o Suggested API and examples have been moved to an appendix. Changes in draft -00: o Migrated from draft-uberti-rtcweb-jsep-02. Uberti, et al. Expires August 31, 2019 [Page 114] Internet-Draft JSEP February 2019 Authors' Addresses Justin Uberti Google 747 6th St S Kirkland, WA 98033 USA Email: justin@uberti.name Cullen Jennings Cisco 400 3rd Avenue SW Calgary, AB T2P 4H2 Canada Email: fluffy@iii.ca Eric Rescorla (editor) Mozilla 331 Evelyn Ave Mountain View, CA 94041 USA Email: ekr@rtfm.com Uberti, et al. Expires August 31, 2019 [Page 115] ./draft-ietf-rtcweb-overview-19.txt0000644000764400076440000015042613201762062016523 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track November 12, 2017 Expires: May 16, 2018 Overview: Real Time Protocols for Browser-based Applications draft-ietf-rtcweb-overview-19 Abstract This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 16, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Alvestrand Expires May 16, 2018 [Page 1] Internet-Draft WebRTC Overview November 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Principles and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Goals of this document . . . . . . . . . . . . . . . . . 4 2.2. Relationship between API and protocol . . . . . . . . . . 5 2.3. On interoperability and innovation . . . . . . . . . . . 7 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 3. Architecture and Functionality groups . . . . . . . . . . . . 8 4. Data transport . . . . . . . . . . . . . . . . . . . . . . . 12 5. Data framing and securing . . . . . . . . . . . . . . . . . . 13 6. Data formats . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Connection management . . . . . . . . . . . . . . . . . . . . 13 8. Presentation and control . . . . . . . . . . . . . . . . . . 14 9. Local system support functions . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. Changes from draft-alvestrand-dispatch-01 to draft- alvestrand-rtcweb-overview-00 . . . . . . . . . . . . . . 20 A.3. Changes from draft-alvestrand-rtcweb-00 to -01 . . . . . 20 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to draft-ietf-rtcweb-overview-00 . . . . . . . . . . . . . . 21 A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview . . 21 A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview . . 21 A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview . . 21 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview . . 22 A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview . . 22 A.10. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 22 A.11. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 22 A.12. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 22 A.13. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 22 Alvestrand Expires May 16, 2018 [Page 2] Internet-Draft WebRTC Overview November 2017 A.14. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 22 A.15. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 23 A.16. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 23 A.17. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 23 A.18. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 23 A.19. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 23 A.20. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 23 A.21. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 24 A.22. Changes from -17 to -18 . . . . . . . . . . . . . . . . . 24 A.23. Changes from -18 to -19 . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction The Internet was, from very early in its lifetime, considered a possible vehicle for the deployment of real-time, interactive applications - with the most easily imaginable being audio conversations (aka "Internet telephony") and video conferencing. The first attempts to build this were dependent on special networks, special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure. As the available bandwidth has increased, and as processors and other hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware. Still, there are a number of barriers to the ability to communicate universally - one of these is that there is, as of yet, no single set of communication protocols that all agree should be made available for communication; another is the sheer lack of universal identification systems (such as is served by telephone numbers or email addresses in other communications systems). Development of The Universal Solution has, however, proved hard. The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application". It turns out that as long as the browser platform has the necessary interfaces, it is possible to deliver almost any kind of service on it. Traditionally, these interfaces have been delivered by plugins, which had to be downloaded and installed separately from the browser; in the development of HTML5, application developers see much promise in the possibility of making those interfaces available in a standardized way within the browser. Alvestrand Expires May 16, 2018 [Page 3] Internet-Draft WebRTC Overview November 2017 This memo describes a set of building blocks that can be made accessible and controllable through a Javascript API in a browser, and which together form a sufficient set of functions to allow the use of interactive audio and video in applications that communicate directly between browsers across the Internet. The resulting protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document [RFC7478]. Other efforts, for instance the W3C Web Real-Time Communications, Web Applications Security, and Device and Sensor working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions. This memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media. In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies using application-specific protocols. Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation [RFC3361] or through the transparent insertion of SIP Application Level Gateways (ALGs) -- will not work with such signaling. In the case of networks using cooperative endpoints, the approaches defined in [RFC8155] may serve as a suitable replacement for [RFC3361]. The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones. This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS. Applying the markings described in [I-D.ietf-tsvwg-rtcweb-qos] may be appropriate replacements for such techniques. This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts. 2. Principles and Terminology 2.1. Goals of this document The goal of the WebRTC protocol specification is to specify a set of protocols that, if all are implemented, will allow an implementation to communicate with another implementation using audio, video and data sent along the most direct possible path between the participants. Alvestrand Expires May 16, 2018 [Page 4] Internet-Draft WebRTC Overview November 2017 This document is intended to serve as the roadmap to the WebRTC specifications. It defines terms used by other parts of the WebRTC protocol specifications, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be possible to have all information needed to implement a WebRTC compatible implementation. 2.2. Relationship between API and protocol The total WebRTC effort consists of two major parts, each consisting of multiple documents: o A protocol specification, done in the IETF o A Javascript API specification, defined in a series of W3C documents [W3C.WD-webrtc-20120209][W3C.WD-mediacapture-streams-20120628] Together, these two specifications aim to provide an environment where Javascript embedded in any page, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, as long as the browser supports this specification. The browser environment does not constrain the types of application in which this functionality can be used. The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for interoperation to know whether the entity one is communicating with is a browser or another device implementing this specification. The goal of cooperation between the protocol specification and the API specification is that for all options and features of the protocol specification, it should be clear which API calls to make to exercise that option or feature; similarly, for any sequence of API calls, it should be clear which protocol options and features will be invoked. Both subject to constraints of the implementation, of course. The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here. Not all terms are used in this document. Other terms are used in their commonly used meaning. Agent: Undefined term. See "SDP Agent" and "ICE Agent". Alvestrand Expires May 16, 2018 [Page 5] Internet-Draft WebRTC Overview November 2017 Application Programming Interface (API): A specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics. Browser: Used synonymously with "Interactive User Agent" as defined in the HTML specification [W3C.WD-html5-20110525]. See also "WebRTC User Agent". Data Channel: An abstraction that allows data to be sent between WebRTC endpoints in the form of messages. Two endpoints can have multiple data channels between them. ICE Agent: An implementation of the Interactive Connectivity Establishment (ICE) [RFC5245] protocol. An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle [XEP-0166]). Interactive: Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/ observation is on the order of no more than hundreds of milliseconds. Media: Audio and video content. Not to be confused with "transmission media" such as wires. Media Path: The path that media data follows from one WebRTC endpoint to another. Protocol: A specification of a set of data units, their representation, and rules for their transmission, with their defined semantics. A protocol is usually thought of as going between systems. Real-time Media: Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds). Real-time media can be used to support interactive communication. SDP Agent: The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in [RFC3264] section 3. Signaling: Communication that happens in order to establish, manage and control media paths and data paths. Alvestrand Expires May 16, 2018 [Page 6] Internet-Draft WebRTC Overview November 2017 Signaling Path: The communication channels used between entities participating in signaling to transfer signaling. There may be more entities in the signaling path than in the media path. WebRTC Browser: (also called a WebRTC User Agent or WebRTC UA) Something that conforms to both the protocol specification and the Javascript API cited above. WebRTC non-Browser: Something that conforms to the protocol specification, but does not claim to implement the Javascript API. This can also be called a "WebRTC device" or "WebRTC native application". WebRTC Endpoint: Either a WebRTC browser or a WebRTC non-browser. It conforms to the protocol specification. WebRTC-compatible Endpoint: An endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint. This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others. It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. WebRTC Gateway: A WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities. All WebRTC browsers are WebRTC endpoints, so any requirement on a WebRTC endpoint also applies to a WebRTC browser. A WebRTC non-browser may be capable of hosting applications in a similar way to the way in which a browser can host Javascript applications, typically by offering APIs in other languages. For instance it may be implemented as a library that offers a C++ API intended to be loaded into applications. In this case, similar security considerations as for Javascript may be needed; however, since such APIs are not defined or referenced here, this document cannot give any specific rules for those interfaces. WebRTC gateways are described in a separate document, [I-D.ietf-rtcweb-gateways]. 2.3. On interoperability and innovation The "Mission statement of the IETF" [RFC3935] states that "The benefit of a standard to the Internet is in interoperability - that Alvestrand Expires May 16, 2018 [Page 7] Internet-Draft WebRTC Overview November 2017 multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users." Communication on the Internet frequently occurs in two phases: o Two parties communicate, through some mechanism, what functionality they both are able to support o They use that shared communicative functionality to communicate, or, failing to find anything in common, give up on communication. There are often many choices that can be made for communicative functionality; the history of the Internet is rife with the proposal, standardization, implementation, and success or failure of many types of options, in all sorts of protocols. The goal of having a mandatory to implement function set is to prevent negotiation failure, not to preempt or prevent negotiation. The presence of a mandatory to implement function set serves as a strong changer of the marketplace of deployment - in that it gives a guarantee that, as long as you conform to a specification, and the other party is willing to accept communication at the base level of that specification, you can communicate successfully. The alternative, that is having no mandatory to implement, does not mean that you cannot communicate, it merely means that in order to be part of the communications partnership, you have to implement the standard "and then some". The "and then some" is usually called a profile of some sort; in the version most antithetical to the Internet ethos, that "and then some" consists of having to use a specific vendor's product only. 2.4. 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]. 3. Architecture and Functionality groups For browser-based applications, the model for real-time support does not assume that the browser will contain all the functions needed for an application such as a telephone or a video conference. The vision is that the browser will have the functions needed for a Web application, working in conjunction with its backend servers, to implement these functions. Alvestrand Expires May 16, 2018 [Page 8] Internet-Draft WebRTC Overview November 2017 This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. +------------------------+ On-the-wire | | Protocols | Servers |---------> | | | | +------------------------+ ^ | | | HTTPS/ | WebSockets | | +----------------------------+ | Javascript/HTML/CSS | +----------------------------+ Other ^ ^ RTC APIs | | APIs +---|-----------------|------+ | | | | | +---------+| | | Browser || On-the-wire | Browser | RTC || Protocols | | Function|-----------> | | || | | || | +---------+| +---------------------|------+ | V Native OS Services Figure 1: Browser Model Alvestrand Expires May 16, 2018 [Page 9] Internet-Draft WebRTC Overview November 2017 Note that HTTPS and WebSockets are also offered to the Javascript application through browser APIs. As for all protocol and API specifications, there is no restriction that the protocols can only be used to talk to another browser; since they are fully specified, any endpoint that implements the protocols faithfully should be able to interoperate with the application running in the browser. A commonly imagined model of deployment is the one depicted below. In the figure below JS is Javascript. +-----------+ +-----------+ | Web | | Web | | | Signaling | | | |-------------| | | Server | path | Server | | | | | +-----------+ +-----------+ / \ / \ Application-defined / \ over / \ HTTPS/WebSockets / Application-defined over \ / HTTPS/WebSockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ Figure 2: Browser RTC Trapezoid On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify, translate or manipulate the signals as needed. If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by Alvestrand Expires May 16, 2018 [Page 10] Internet-Draft WebRTC Overview November 2017 standardization or by other means of agreement. Existing protocols (e.g. SIP [RFC3261] or XMPP [RFC6120]) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g. SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server. Similarly, if both operators' servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over WebSockets or BOSH [XEP-0124] or a proprietary signaling mechanism used between the application running in the browser and the web server. The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: o Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: congestion management, bandwidth estimation and so on. o Data framing: RTP, SCTP, DTLS, and other data formats that serve as containers, and their functions for data confidentiality and integrity. o Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems. Audio and video codecs, as well as formats for data and document sharing, belong in this category. In order to make use of data formats, a way to describe them, a session description, is needed. o Connection management: Setting up connections, agreeing on data formats, changing data formats during the duration of a call; SDP, SIP, and Jingle/XMPP belong in this category. o Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner. This can include floor control, screen layout, voice activated image switching and other such functions - where part of the system require the cooperation between parties. XCON and Cisco/ Alvestrand Expires May 16, 2018 [Page 11] Internet-Draft WebRTC Overview November 2017 Tandberg's TIP were some attempts at specifying this kind of functionality; many applications have been built without standardized interfaces to these functions. o Local system support functions: These are things that need not be specified uniformly, because each participant may choose to do these in a way of the participant's choosing, without affecting the bits on the wire in a way that others have to be cognizant of. Examples in this category include echo cancellation (some forms of it), local authentication and authorization mechanisms, OS access control and the ability to do local recording of conversations. Within each functionality group, it is important to preserve both freedom to innovate and the ability for global communication. Freedom to innovate is helped by doing the specification in terms of interfaces, not implementation; any implementation able to communicate according to the interfaces is a valid implementation. Ability to communicate globally is helped both by having core specifications be unencumbered by IPR issues and by having the formats and protocols be fully enough specified to allow for independent implementation. One can think of the three first groups as forming a "media transport infrastructure", and of the three last groups as forming a "media service". In many contexts, it makes sense to use a common specification for the media transport infrastructure, which can be embedded in browsers and accessed using standard interfaces, and "let a thousand flowers bloom" in the "media service" layer; to achieve interoperable services, however, at least the first five of the six groups need to be specified. 4. Data transport Data transport refers to the sending and receiving of data over the network interfaces, the choice of network-layer addresses at each end of the communication, and the interaction with any intermediate entities that handle the data, but do not modify it (such as TURN relays). It includes necessary functions for congestion control, retransmission, and in-order delivery. WebRTC endpoints MUST implement the transport protocols described in [I-D.ietf-rtcweb-transports]. Alvestrand Expires May 16, 2018 [Page 12] Internet-Draft WebRTC Overview November 2017 5. Data framing and securing The format for media transport is RTP [RFC3550]. Implementation of SRTP [RFC3711] is REQUIRED for all implementations. The detailed considerations for usage of functions from RTP and SRTP are given in [I-D.ietf-rtcweb-rtp-usage]. The security considerations for the WebRTC use case are in [I-D.ietf-rtcweb-security], and the resulting security functions are described in [I-D.ietf-rtcweb-security-arch]. Considerations for the transfer of data that is not in RTP format is described in [I-D.ietf-rtcweb-data-channel], and a supporting protocol for establishing individual data channels is described in [I-D.ietf-rtcweb-data-protocol]. WebRTC endpoints MUST implement these two specifications. WebRTC endpoints MUST implement [I-D.ietf-rtcweb-rtp-usage], [I-D.ietf-rtcweb-security], [I-D.ietf-rtcweb-security-arch], and the requirements they include. 6. Data formats The intent of this specification is to allow each communications event to use the data formats that are best suited for that particular instance, where a format is supported by both sides of the connection. However, a minimum standard is greatly helpful in order to ensure that communication can be achieved. This document specifies a minimum baseline that will be supported by all implementations of this specification, and leaves further codecs to be included at the will of the implementor. WebRTC endpoints that support audio and/or video MUST implement the codecs and profiles required in [RFC7874] and [RFC7742]. 7. Connection management The methods, mechanisms and requirements for setting up, negotiating and tearing down connections is a large subject, and one where it is desirable to have both interoperability and freedom to innovate. The following principles apply: 1. The WebRTC media negotiations will be capable of representing the same SDP offer/answer semantics [RFC3264] that are used in SIP, in such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation. Alvestrand Expires May 16, 2018 [Page 13] Internet-Draft WebRTC Overview November 2017 2. It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms, codecs and security mechanisms without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed. 3. When an SDP for a new codec is specified, no other standardization should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and Javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. The particular choices made for WebRTC, and their implications for the API offered by a browser implementing WebRTC, are described in [I-D.ietf-rtcweb-jsep]. WebRTC browsers MUST implement [I-D.ietf-rtcweb-jsep]. WebRTC endpoints MUST implement the functions described in that document that relate to the network layer (e.g. Bundle [I-D.ietf-mmusic-sdp-bundle-negotiation], RTCP-mux [RFC5761] and Trickle ICE [I-D.ietf-ice-trickle]), but do not need to support the API functionality described there. 8. Presentation and control The most important part of control is the user's control over the browser's interaction with input/output devices and communications channels. It is important that the user have some way of figuring out where his audio, video or texting is being sent, for what purported reason, and what guarantees are made by the parties that form part of this control channel. This is largely a local function between the browser, the underlying operating system and the user interface; this is specified in the peer connection API [W3C.WD-webrtc-20120209], and the media capture API [W3C.WD-mediacapture-streams-20120628]. WebRTC browsers MUST implement these two specifications. 9. Local system support functions These are characterized by the fact that the quality of these functions strongly influence the user experience, but the exact algorithm does not need coordination. In some cases (for instance echo cancellation, as described below), the overall system definition Alvestrand Expires May 16, 2018 [Page 14] Internet-Draft WebRTC Overview November 2017 may need to specify that the overall system needs to have some characteristics for which these facilities are useful, without requiring them to be implemented a certain way. Local functions include echo cancellation, volume control, camera management including focus, zoom, pan/tilt controls (if available), and more. One would want to see certain parts of the system conform to certain properties, for instance: o Echo cancellation should be good enough to achieve the suppression of acoustical feedback loops below a perceptually noticeable level. o Privacy concerns MUST be satisfied; for instance, if remote control of camera is offered, the APIs should be available to let the local participant figure out who's controlling the camera, and possibly decide to revoke the permission for camera usage. o Automatic gain control, if present, should normalize a speaking voice into a reasonable dB range. The requirements on WebRTC systems with regard to audio processing are found in [RFC7874] and includes more guidance about echo cancellation and AGC; the proposed API for control of local devices are found in [W3C.WD-mediacapture-streams-20120628]. WebRTC endpoints MUST implement the processing functions in [RFC7874]. (Together with the requirement in Section 6, this means that WebRTC endpoints MUST implement the whole document.) 10. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 11. Security Considerations Security of the web-enabled real time communications comes in several pieces: o Security of the components: The browsers, and other servers involved. The most target-rich environment here is probably the browser; the aim here should be that the introduction of these components introduces no additional vulnerability. Alvestrand Expires May 16, 2018 [Page 15] Internet-Draft WebRTC Overview November 2017 o Security of the communication channels: It should be easy for a participant to reassure himself of the security of his communication - by verifying the crypto parameters of the links he himself participates in, and to get reassurances from the other parties to the communication that they promise that appropriate measures are taken. o Security of the partners' identity: verifying that the participants are who they say they are (when positive identification is appropriate), or that their identity cannot be uncovered (when anonymity is a goal of the application). The security analysis, and the requirements derived from that analysis, is contained in [I-D.ietf-rtcweb-security]. It is also important to read the security sections of [W3C.WD-mediacapture-streams-20120628] and [W3C.WD-webrtc-20120209]. 12. Acknowledgements The number of people who have taken part in the discussions surrounding this draft are too numerous to list, or even to identify. The ones below have made special, identifiable contributions; this does not mean that others' contributions are less important. Thanks to Cary Bran, Cullen Jennings, Colin Perkins, Magnus Westerlund and Joerg Ott, who offered technical contributions on various versions of the draft. Thanks to Jonathan Rosenberg, Matthew Kaufman and others at Skype for the ASCII drawings in section 1. Thanks to Alissa Cooper, Bjoern Hoehrmann, Colin Perkins, Colton Shields, Eric Rescorla, Heath Matlock, Henry Sinnreich, Justin Uberti, Keith Drage, Magnus Westerlund, Olle E. Johansson, Sean Turner and Simon Leinen for document review. 13. References 13.1. Normative References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. Alvestrand Expires May 16, 2018 [Page 16] Internet-Draft WebRTC Overview November 2017 [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-09 (work in progress), January 2015. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "JavaScript Session Establishment Protocol", draft-ietf-rtcweb-jsep-24 (work in progress), October 2017. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-09 (work in progress), October 2017. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-13 (work in progress), October 2017. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-17 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . Alvestrand Expires May 16, 2018 [Page 17] Internet-Draft WebRTC Overview November 2017 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, . [W3C.WD-mediacapture-streams-20120628] Burnett, D. and A. Narayanan, "Media Capture and Streams", World Wide Web Consortium WD WD-mediacapture-streams- 20120628, June 2012, . [W3C.WD-webrtc-20120209] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20120209, February 2012, . 13.2. Informative References [I-D.ietf-ice-trickle] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", draft-ietf-ice-trickle-14 (work in progress), September 2017. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-39 (work in progress), August 2017. [I-D.ietf-rtcweb-gateways] Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways", draft-ietf-rtcweb-gateways-02 (work in progress), January 2016. Alvestrand Expires May 16, 2018 [Page 18] Internet-Draft WebRTC Overview November 2017 [I-D.ietf-tsvwg-rtcweb-qos] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- qos-18 (work in progress), August 2016. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers", RFC 3361, DOI 10.17487/RFC3361, August 2002, . [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays around NAT (TURN) Server Auto Discovery", RFC 8155, DOI 10.17487/RFC8155, April 2017, . [W3C.WD-html5-20110525] Hickson, I., "HTML5", World Wide Web Consortium LastCall WD-html5-20110525, May 2011, . [XEP-0124] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., Stout, L., and W. Tilanus, "BOSH", XSF XEP 0124, November 2016. Alvestrand Expires May 16, 2018 [Page 19] Internet-Draft WebRTC Overview November 2017 [XEP-0166] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, S., and J. Hildebrand, "Jingle", XSF XEP 0166, June 2007. Appendix A. Change log This section may be deleted by the RFC Editor when preparing for publication. A.1. Changes from draft-alvestrand-dispatch-rtcweb-datagram-00 to -01 Added section "On interoperability and innovation" Added data confidentiality and integrity to the "data framing" layer Added congestion management requirements in the "data transport" layer section Changed need for non-media data from "question: do we need this?" to "Open issue: How do we do this?" Strengthened disclaimer that listed codecs are placeholders, not decisions. More details on why the "local system support functions" section is there. A.2. Changes from draft-alvestrand-dispatch-01 to draft-alvestrand- rtcweb-overview-00 Added section on "Relationship between API and protocol" Added terminology section Mentioned congestion management as part of the "data transport" layer in the layer list A.3. Changes from draft-alvestrand-rtcweb-00 to -01 Removed most technical content, and replaced with pointers to drafts as requested and identified by the RTCWEB WG chairs. Added content to acknowledgments section. Added change log. Spell-checked document. Alvestrand Expires May 16, 2018 [Page 20] Internet-Draft WebRTC Overview November 2017 A.4. Changes from draft-alvestrand-rtcweb-overview-01 to draft-ietf- rtcweb-overview-00 Changed draft name and document date. Removed unused references A.5. Changes from -00 to -01 of draft-ietf-rtcweb-overview Added architecture figures to section 2. Changed the description of "echo cancellation" under "local system support functions". Added a few more definitions. A.6. Changes from -01 to -02 of draft-ietf-rtcweb-overview Added pointers to use cases, security and rtp-usage drafts (now WG drafts). Changed description of SRTP from mandatory-to-use to mandatory-to- implement. Added the "3 principles of negotiation" to the connection management section. Added an explicit statement that ICE is required for both NAT and consent-to-receive. A.7. Changes from -02 to -03 of draft-ietf-rtcweb-overview Added references to a number of new drafts. Expanded the description text under the "trapezoid" drawing with some more text discussed on the list. Changed the "Connection management" sentence from "will be done using SDP offer/answer" to "will be capable of representing SDP offer/ answer" - this seems more consistent with JSEP. Added "security mechanisms" to the things a non-gatewayed SIP devices must support in order to not need a media gateway. Added a definition for "browser". Alvestrand Expires May 16, 2018 [Page 21] Internet-Draft WebRTC Overview November 2017 A.8. Changes from -03 to -04 of draft-ietf-rtcweb-overview Made introduction more normative. Several wording changes in response to review comments from EKR Added an appendix to hold references and notes that are not yet in a separate document. A.9. Changes from -04 to -05 of draft-ietf-rtcweb-overview Minor grammatical fixes. This is mainly a "keepalive" refresh. A.10. Changes from -05 to -06 Clarifications in response to Last Call review comments. Inserted reference to draft-ietf-rtcweb-audio. A.11. Changes from -06 to -07 Added a reference to the "unified plan" draft, and updated some references. Otherwise, it's a "keepalive" draft. A.12. Changes from -07 to -08 Removed the appendix that detailed transports, and replaced it with a reference to draft-ietf-rtcweb-transports. Removed now-unused references. A.13. Changes from -08 to -09 Added text to the Abstract indicating that the intended status is an Applicability Statement. A.14. Changes from -09 to -10 Defined "WebRTC Browser" and "WebRTC device" as things that do, or don't, conform to the API. Updated reference to data-protocol draft Updated data formats to reference -rtcweb-audio- and not the expired -cbran draft. Deleted references to -unified-plan Alvestrand Expires May 16, 2018 [Page 22] Internet-Draft WebRTC Overview November 2017 Deleted reference to -generic-idp (draft expired) Added notes on which referenced documents WebRTC browsers or devices MUST conform to. Added pointer to the security section of the API drafts. A.15. Changes from -10 to -11 Added "WebRTC Gateway" as a third class of device, and referenced the doc describing them. Made a number of text clarifications in response to document reviews. A.16. Changes from -11 to -12 Refined entity definitions to define "WebRTC endpoint" and "WebRTC- compatible endpoint". Changed remaining usage of the term "RTCWEB" to "WebRTC", including in the page header. A.17. Changes from -12 to -13 Changed "WebRTC device" to be "WebRTC non-browser", per decision at IETF 91. This led to the need for "WebRTC endpoint" as the common label for both, and the usage of that term in the rest of the document. Added words about WebRTC APIs in languages other than Javascript. Referenced draft-ietf-rtcweb-video for video codecs to support. A.18. Changes from -13 to -14 None. This is a "keepalive" update. A.19. Changes from -14 to -15 Changed "gateways" reference to point to the WG document. A.20. Changes from -15 to -16 None. This is a "keepalive" publication. Alvestrand Expires May 16, 2018 [Page 23] Internet-Draft WebRTC Overview November 2017 A.21. Changes from -16 to -17 Addressed review comments by Olle E. Johansson and Magnus Westerlund A.22. Changes from -17 to -18 Addressed review comments from Sean Turner and Alissa Cooper A.23. Changes from -18 to -19 A number of grammatical issues were fixed. Added note on operational impact of WebRTC. Unified all definitions into the definitions list. Added a reference for BOSH. Changed ICE reference from 5245bis to RFC 5245. Author's Address Harald T. Alvestrand Google Kungsbron 2 Stockholm 11122 Sweden Email: harald@alvestrand.no Alvestrand Expires May 16, 2018 [Page 24] ./draft-ietf-rtcweb-rtp-usage-26.txt0000644000764400076440000036701212672545755016606 0ustar iustyiusty RTCWEB Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: September 18, 2016 Ericsson J. Ott Aalto University March 17, 2016 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP draft-ietf-rtcweb-rtp-usage-26 Abstract The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 18, 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 Perkins, et al. Expires September 18, 2016 [Page 1] Internet-Draft RTP for WebRTC March 2016 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. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 7 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 10 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 12 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12 4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13 5.1. Conferencing Extensions and Topologies . . . . . . . . . 14 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 16 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18 5.2.4. Media Stream Identification . . . . . . . . . . . . . 18 5.2.5. Coordination of Video Orientation . . . . . . . . . . 18 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19 6.1. Negative Acknowledgements and RTP Retransmission . . . . 19 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21 7.2. Congestion Control Interoperability and Legacy Systems . 22 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25 12. RTP Implementation Considerations . . . . . . . . . . . . . . 27 Perkins, et al. Expires September 18, 2016 [Page 2] Internet-Draft RTP for WebRTC March 2016 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27 12.1.1. Use of Multiple Media Sources Within an RTP Session 27 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28 12.1.3. Differentiated Treatment of RTP Streams . . . . . . 33 12.2. Media Source, RTP Streams, and Participant Identification . . . . . . . . . . . . . . . . . . . . . 35 12.2.1. Media Source Identification . . . . . . . . . . . . 35 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36 12.2.3. Media Synchronisation Context . . . . . . . . . . . 37 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] provides a framework for delivery of audio and video teleconferencing data and other real- time media applications. Previous work has defined the RTP protocol, along with numerous profiles, payload formats, and other extensions. When combined with appropriate signalling, these form the basis for many teleconferencing systems. The Web Real-Time communication (WebRTC) framework provides the protocol building blocks to support direct, interactive, real-time communication using audio, video, collaboration, games, etc., between two peers' web-browsers. This memo describes how the RTP framework is to be used in the WebRTC context. It proposes a baseline set of RTP features that are to be implemented by all WebRTC Endpoints, along with suggested extensions for enhanced functionality. This memo specifies a protocol intended for use within the WebRTC framework, but is not restricted to that context. An overview of the WebRTC framework is given in [I-D.ietf-rtcweb-overview]. The structure of this memo is as follows. Section 2 outlines our rationale in preparing this memo and choosing these RTP features. Section 3 defines terminology. Requirements for core RTP protocols are described in Section 4 and suggested RTP extensions are described in Section 5. Section 6 outlines mechanisms that can increase robustness to network problems, while Section 7 describes congestion control and rate adaptation mechanisms. The discussion of mandated RTP mechanisms concludes in Section 8 with a review of performance monitoring and network management tools. Section 9 gives some guidelines for future incorporation of other RTP and RTP Control Perkins, et al. Expires September 18, 2016 [Page 3] Internet-Draft RTP for WebRTC March 2016 Protocol (RTCP) extensions into this framework. Section 10 describes requirements placed on the signalling channel. Section 11 discusses the relationship between features of the RTP framework and the WebRTC application programming interface (API), and Section 12 discusses RTP implementation considerations. The memo concludes with security considerations (Section 13) and IANA considerations (Section 14). 2. Rationale The RTP framework comprises the RTP data transfer protocol, the RTP control protocol, and numerous RTP payload formats, profiles, and extensions. This range of add-ons has allowed RTP to meet various needs that were not envisaged by the original protocol designers, and to support many new media encodings, but raises the question of what extensions are to be supported by new implementations. The development of the WebRTC framework provides an opportunity to review the available RTP features and extensions, and to define a common baseline RTP feature set for all WebRTC Endpoints. This builds on the past 20 years of RTP development to mandate the use of extensions that have shown widespread utility, while still remaining compatible with the wide installed base of RTP implementations where possible. RTP and RTCP extensions that are not discussed in this document can be implemented by WebRTC Endpoints if they are beneficial for new use cases. However, they are not necessary to address the WebRTC use cases and requirements identified in [RFC7478]. While the baseline set of RTP features and extensions defined in this memo is targeted at the requirements of the WebRTC framework, it is expected to be broadly useful for other conferencing-related uses of RTP. In particular, it is likely that this set of RTP features and extensions will be appropriate for other desktop or mobile video conferencing systems, or for room-based high-quality telepresence applications. 3. 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]. The RFC 2119 interpretation of these key words applies only when written in ALL CAPS. Lower- or mixed-case uses of these key words are not to be interpreted as carrying special significance in this memo. We define the following additional terms: Perkins, et al. Expires September 18, 2016 [Page 4] Internet-Draft RTP for WebRTC March 2016 WebRTC MediaStream: The MediaStream concept defined by the W3C in the WebRTC API [W3C.WD-mediacapture-streams-20130903]. A MediaStream consists of zero or more MediaStreamTracks. MediaStreamTrack: Part of the MediaStream concept defined by the W3C in the WebRTC API [W3C.WD-mediacapture-streams-20130903]. A MediaStreamTrack is an individual stream of media from any type of media source like a microphone or a camera, but also conceptual sources, like a audio mix or a video composition, are possible. Transport-layer Flow: A uni-directional flow of transport packets that are identified by having a particular 5-tuple of source IP address, source port, destination IP address, destination port, and transport protocol used. Bi-directional Transport-layer Flow: A bi-directional transport- layer flow is a transport-layer flow that is symmetric. That is, the transport-layer flow in the reverse direction has a 5-tuple where the source and destination address and ports are swapped compared to the forward path transport-layer flow, and the transport protocol is the same. This document uses the terminology from [I-D.ietf-avtext-rtp-grouping-taxonomy] and [I-D.ietf-rtcweb-overview]. Other terms are used according to their definitions from the RTP Specification [RFC3550]. Especially note the following frequently used terms: RTP Stream, RTP Session, and Endpoint. 4. WebRTC Use of RTP: Core Protocols The following sections describe the core features of RTP and RTCP that need to be implemented, along with the mandated RTP profiles. Also described are the core extensions providing essential features that all WebRTC Endpoints need to implement to function effectively on today's networks. 4.1. RTP and RTCP The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be implemented as the media transport protocol for WebRTC. RTP itself comprises two parts: the RTP data transfer protocol, and the RTP control protocol (RTCP). RTCP is a fundamental and integral part of RTP, and MUST be implemented and used in all WebRTC Endpoints. The following RTP and RTCP features are sometimes omitted in limited functionality implementations of RTP, but are REQUIRED in all WebRTC Endpoints: Perkins, et al. Expires September 18, 2016 [Page 5] Internet-Draft RTP for WebRTC March 2016 o Support for use of multiple simultaneous SSRC values in a single RTP session, including support for RTP endpoints that send many SSRC values simultaneously, following [RFC3550] and [I-D.ietf-avtcore-rtp-multi-stream]. The RTCP optimisations for multi-SSRC sessions defined in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] MAY be supported; if supported the usage MUST be signalled. o Random choice of SSRC on joining a session; collision detection and resolution for SSRC values (see also Section 4.8). o Support for reception of RTP data packets containing CSRC lists, as generated by RTP mixers, and RTCP packets relating to CSRCs. o Sending correct synchronisation information in the RTCP Sender Reports, to allow receivers to implement lip-synchronisation; see Section 5.2.1 regarding support for the rapid RTP synchronisation extensions. o Support for multiple synchronisation contexts. Participants that send multiple simultaneous RTP packet streams SHOULD do so as part of a single synchronisation context, using a single RTCP CNAME for all streams and allowing receivers to play the streams out in a synchronised manner. For compatibility with potential future versions of this specification, or for interoperability with non- WebRTC devices through a gateway, receivers MUST support multiple synchronisation contexts, indicated by the use of multiple RTCP CNAMEs in an RTP session. This specification mandates the usage of a single CNAME when sending RTP Streams in some circumstances, see Section 4.9. o Support for sending and receiving RTCP SR, RR, SDES, and BYE packet types. Note that support for other RTCP packet types is OPTIONAL, unless mandated by other parts of this specification. Note that additional RTCP Packet types are used by the RTP/SAVPF Profile (Section 4.2) and the other RTCP extensions (Section 5). WebRTC endpoints that implement the SDP bundle negotiation extension will use the SDP grouping framework 'mid' attribute to identify media streams. Such endpoints MUST implement the RTCP SDES MID item described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. o Support for multiple endpoints in a single RTP session, and for scaling the RTCP transmission interval according to the number of participants in the session; support for randomised RTCP transmission intervals to avoid synchronisation of RTCP reports; support for RTCP timer reconsideration (Section 6.3.6 of Perkins, et al. Expires September 18, 2016 [Page 6] Internet-Draft RTP for WebRTC March 2016 [RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]). o Support for configuring the RTCP bandwidth as a fraction of the media bandwidth, and for configuring the fraction of the RTCP bandwidth allocated to senders, e.g., using the SDP "b=" line [RFC4566][RFC3556]. o Support for the reduced minimum RTCP reporting interval described in Section 6.2 of [RFC3550]. When using the reduced minimum RTCP reporting interval, the fixed (non-reduced) minimum interval MUST be used when calculating the participant timeout interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending the initial compound RTCP packet can be set to zero (see Section 6.2 of [RFC3550] as updated by [I-D.ietf-avtcore-rtp-multi-stream]). o Support for discontinuous transmission. RTP allows endpoints to pause and resume transmission at any time. When resuming, the RTP sequence number will increase by one, as usual, while the increase in the RTP timestamp value will depend on the duration of the pause. Discontinuous transmission is most commonly used with some audio payload formats, but is not audio specific, and can be used with any RTP payload format. o Ignore unknown RTCP packet types and RTP header extensions. This is to ensure robust handling of future extensions, middlebox behaviours, etc., that can result in not signalled RTCP packet types or RTP header extensions being received. If a compound RTCP packet is received that contains a mixture of known and unknown RTCP packet types, the known packets types need to be processed as usual, with only the unknown packet types being discarded. It is known that a significant number of legacy RTP implementations, especially those targeted at VoIP-only systems, do not support all of the above features, and in some cases do not support RTCP at all. Implementers are advised to consider the requirements for graceful degradation when interoperating with legacy implementations. Other implementation considerations are discussed in Section 12. 4.2. Choice of the RTP Profile The complete specification of RTP for a particular application domain requires the choice of an RTP Profile. For WebRTC use, the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF) [RFC5124], as extended by [RFC7007], MUST be implemented. The RTP/SAVPF profile is the combination of basic RTP/AVP profile [RFC3551], the RTP profile Perkins, et al. Expires September 18, 2016 [Page 7] Internet-Draft RTP for WebRTC March 2016 for RTCP-based feedback (RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP) [RFC3711]. The RTCP-based feedback extensions [RFC4585] are needed for the improved RTCP timer model. This allows more flexible transmission of RTCP packets in response to events, rather than strictly according to bandwidth, and is vital for being able to report congestion signals as well as media events. These extensions also allow saving RTCP bandwidth, and an endpoint will commonly only use the full RTCP bandwidth allocation if there are many events that require feedback. The timer rules are also needed to make use of the RTP conferencing extensions discussed in Section 5.1. Note: The enhanced RTCP timer model defined in the RTP/AVPF profile is backwards compatible with legacy systems that implement only the RTP/AVP or RTP/SAVP profile, given some constraints on parameter configuration such as the RTCP bandwidth value and "trr- int" (the most important factor for interworking with RTP/(S)AVP endpoints via a gateway is to set the trr-int parameter to a value representing 4 seconds, see Section 6.1 in [I-D.ietf-avtcore-rtp-multi-stream]). The secure RTP (SRTP) profile extensions [RFC3711] are needed to provide media encryption, integrity protection, replay protection and a limited form of source authentication. WebRTC Endpoints MUST NOT send packets using the basic RTP/AVP profile or the RTP/AVPF profile; they MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP packets that are generated (i.e., implementations MUST use SRTP and SRTCP). The RTP/SAVPF profile MUST be configured using the cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and other parameters described in [I-D.ietf-rtcweb-security-arch]. 4.3. Choice of RTP Payload Formats Mandatory to implement audio codecs and RTP payload formats for WebRTC endpoints are defined in [I-D.ietf-rtcweb-audio]. Mandatory to implement video codecs and RTP payload formats for WebRTC endpoints are defined in [I-D.ietf-rtcweb-video]. WebRTC endpoints MAY additionally implement any other codec for which an RTP payload format and associated signalling has been defined. WebRTC Endpoints cannot assume that the other participants in an RTP session understand any RTP payload format, no matter how common. The mapping between RTP payload type numbers and specific configurations of particular RTP payload formats MUST be agreed before those payload types/formats can be used. In an SDP context, this can be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with an "m=" Perkins, et al. Expires September 18, 2016 [Page 8] Internet-Draft RTP for WebRTC March 2016 line, along with any other SDP attributes needed to configure the RTP payload format. Endpoints can signal support for multiple RTP payload formats, or multiple configurations of a single RTP payload format, as long as each unique RTP payload format configuration uses a different RTP payload type number. As outlined in Section 4.8, the RTP payload type number is sometimes used to associate an RTP packet stream with a signalling context. This association is possible provided unique RTP payload type numbers are used in each context. For example, an RTP packet stream can be associated with an SDP "m=" line by comparing the RTP payload type numbers used by the RTP packet stream with payload types signalled in the "a=rtpmap:" lines in the media sections of the SDP. This leads to the following considerations: If RTP packet streams are being associated with signalling contexts based on the RTP payload type, then the assignment of RTP payload type numbers MUST be unique across signalling contexts. If the same RTP payload format configuration is used in multiple contexts, then a different RTP payload type number has to be assigned in each context to ensure uniqueness. If the RTP payload type number is not being used to associate RTP packet streams with a signalling context, then the same RTP payload type number can be used to indicate the exact same RTP payload format configuration in multiple contexts. A single RTP payload type number MUST NOT be assigned to different RTP payload formats, or different configurations of the same RTP payload format, within a single RTP session (note that the "m=" lines in an SDP bundle group [I-D.ietf-mmusic-sdp-bundle-negotiation] form a single RTP session). An endpoint that has signalled support for multiple RTP payload formats MUST be able to accept data in any of those payload formats at any time, unless it has previously signalled limitations on its decoding capability. This requirement is constrained if several types of media (e.g., audio and video) are sent in the same RTP session. In such a case, a source (SSRC) is restricted to switching only between the RTP payload formats signalled for the type of media that is being sent by that source; see Section 4.4. To support rapid rate adaptation by changing codec, RTP does not require advance signalling for changes between RTP payload formats used by a single SSRC that were signalled during session set-up. If performing changes between two RTP payload types that use different RTP clock rates, an RTP sender MUST follow the Perkins, et al. Expires September 18, 2016 [Page 9] Internet-Draft RTP for WebRTC March 2016 recommendations in Section 4.1 of [RFC7160]. RTP receivers MUST follow the recommendations in Section 4.3 of [RFC7160] in order to support sources that switch between clock rates in an RTP session (these recommendations for receivers are backwards compatible with the case where senders use only a single clock rate). 4.4. Use of RTP Sessions An association amongst a set of endpoints communicating using RTP is known as an RTP session [RFC3550]. An endpoint can be involved in several RTP sessions at the same time. In a multimedia session, each type of media has typically been carried in a separate RTP session (e.g., using one RTP session for the audio, and a separate RTP session using a different transport-layer flow for the video). WebRTC Endpoints are REQUIRED to implement support for multimedia sessions in this way, separating each RTP session using different transport-layer flows for compatibility with legacy systems (this is sometimes called session multiplexing). In modern day networks, however, with the widespread use of network address/port translators (NAT/NAPT) and firewalls, it is desirable to reduce the number of transport-layer flows used by RTP applications. This can be done by sending all the RTP packet streams in a single RTP session, which will comprise a single transport-layer flow (this will prevent the use of some quality-of-service mechanisms, as discussed in Section 12.1.3). Implementations are therefore also REQUIRED to support transport of all RTP packet streams, independent of media type, in a single RTP session using a single transport layer flow, according to [I-D.ietf-avtcore-multi-media-rtp-session] (this is sometimes called SSRC multiplexing). If multiple types of media are to be used in a single RTP session, all participants in that RTP session MUST agree to this usage. In an SDP context, [I-D.ietf-mmusic-sdp-bundle-negotiation] can be used to signal such a bundle of RTP packet streams forming a single RTP session. Further discussion about the suitability of different RTP session structures and multiplexing methods to different scenarios can be found in [I-D.ietf-avtcore-multiplex-guidelines]. 4.5. RTP and RTCP Multiplexing Historically, RTP and RTCP have been run on separate transport layer flows (e.g., two UDP ports for each RTP session, one port for RTP and one port for RTCP). With the increased use of Network Address/Port Translation (NAT/NAPT) this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports need to be opened to allow RTP traffic. To reduce these costs and session set-up times, Perkins, et al. Expires September 18, 2016 [Page 10] Internet-Draft RTP for WebRTC March 2016 implementations are REQUIRED to support multiplexing RTP data packets and RTCP control packets on a single transport-layer flow [RFC5761]. Such RTP and RTCP multiplexing MUST be negotiated in the signalling channel before it is used. If SDP is used for signalling, this negotiation MUST use the mechanism defined in [RFC5761]. Implementations can also support sending RTP and RTCP on separate transport-layer flows, but this is OPTIONAL to implement. If an implementation does not support RTP and RTCP sent on separate transport-layer flows, it MUST indicate that using the mechanism defined in [I-D.ietf-mmusic-mux-exclusive]. Note that the use of RTP and RTCP multiplexed onto a single transport-layer flow ensures that there is occasional traffic sent on that port, even if there is no active media traffic. This can be useful to keep NAT bindings alive [RFC6263]. 4.6. Reduced Size RTCP RTCP packets are usually sent as compound RTCP packets, and [RFC3550] requires that those compound packets start with an Sender Report (SR) or Receiver Report (RR) packet. When using frequent RTCP feedback messages under the RTP/AVPF Profile [RFC4585] these statistics are not needed in every packet, and unnecessarily increase the mean RTCP packet size. This can limit the frequency at which RTCP packets can be sent within the RTCP bandwidth share. To avoid this problem, [RFC5506] specifies how to reduce the mean RTCP message size and allow for more frequent feedback. Frequent feedback, in turn, is essential to make real-time applications quickly aware of changing network conditions, and to allow them to adapt their transmission and encoding behaviour. Implementations MUST support sending and receiving non-compound RTCP feedback packets [RFC5506]. Use of non-compound RTCP packets MUST be negotiated using the signalling channel. If SDP is used for signalling, this negotiation MUST use the attributes defined in [RFC5506]. For backwards compatibility, implementations are also REQUIRED to support the use of compound RTCP feedback packets if the remote endpoint does not agree to the use of non-compound RTCP in the signalling exchange. 4.7. Symmetric RTP/RTCP To ease traversal of NAT and firewall devices, implementations are REQUIRED to implement and use Symmetric RTP [RFC4961]. The reason for using symmetric RTP is primarily to avoid issues with NATs and Firewalls by ensuring that the send and receive RTP packet streams, as well as RTCP, are actually bi-directional transport-layer flows. This will keep alive the NAT and firewall pinholes, and help indicate consent that the receive direction is a transport-layer flow the Perkins, et al. Expires September 18, 2016 [Page 11] Internet-Draft RTP for WebRTC March 2016 intended recipient actually wants. In addition, it saves resources, specifically ports at the endpoints, but also in the network as NAT mappings or firewall state is not unnecessary bloated. The amount of per flow QoS state kept in the network is also reduced. 4.8. Choice of RTP Synchronisation Source (SSRC) Implementations are REQUIRED to support signalled RTP synchronisation source (SSRC) identifiers. If SDP is used, this MUST be done using the "a=ssrc:" SDP attribute defined in Section 4.1 and Section 5 of [RFC5576] and the "previous-ssrc" source attribute defined in Section 6.2 of [RFC5576]; other per-SSRC attributes defined in [RFC5576] MAY be supported. While support for signalled SSRC identifiers is mandated, their use in an RTP session is OPTIONAL. Implementations MUST be prepared to accept RTP and RTCP packets using SSRCs that have not been explicitly signalled ahead of time. Implementations MUST support random SSRC assignment, and MUST support SSRC collision detection and resolution, according to [RFC3550]. When using signalled SSRC values, collision detection MUST be performed as described in Section 5 of [RFC5576]. It is often desirable to associate an RTP packet stream with a non- RTP context. For users of the WebRTC API a mapping between SSRCs and MediaStreamTracks are provided per Section 11. For gateways or other usages it is possible to associate an RTP packet stream with an "m=" line in a session description formatted using SDP. If SSRCs are signalled this is straightforward (in SDP the "a=ssrc:" line will be at the media level, allowing a direct association with an "m=" line). If SSRCs are not signalled, the RTP payload type numbers used in an RTP packet stream are often sufficient to associate that packet stream with a signalling context (e.g., if RTP payload type numbers are assigned as described in Section 4.3 of this memo, the RTP payload types used by an RTP packet stream can be compared with values in SDP "a=rtpmap:" lines, which are at the media level in SDP, and so map to an "m=" line). 4.9. Generation of the RTCP Canonical Name (CNAME) The RTCP Canonical Name (CNAME) provides a persistent transport-level identifier for an RTP endpoint. While the Synchronisation Source (SSRC) identifier for an RTP endpoint can change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged for the duration of a RTCPeerConnection [W3C.WD-webrtc-20130910], so that RTP endpoints can be uniquely identified and associated with their RTP packet streams within a set of related RTP sessions. Perkins, et al. Expires September 18, 2016 [Page 12] Internet-Draft RTP for WebRTC March 2016 Each RTP endpoint MUST have at least one RTCP CNAME, and that RTCP CNAME MUST be unique within the RTCPeerConnection. RTCP CNAMEs identify a particular synchronisation context, i.e., all SSRCs associated with a single RTCP CNAME share a common reference clock. If an endpoint has SSRCs that are associated with several unsynchronised reference clocks, and hence different synchronisation contexts, it will need to use multiple RTCP CNAMEs, one for each synchronisation context. Taking the discussion in Section 11 into account, a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to single RTCPeerConnection (that is, an RTCPeerConnection forms a synchronisation context). RTP middleboxes MAY generate RTP packet streams associated with more than one RTCP CNAME, to allow them to avoid having to resynchronize media from multiple different endpoints part of a multi-party RTP session. The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint (Section 13). Accordingly, a WebRTC Endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a single exception; if explicitly requested at creation an RTCPeerConnection MAY use the same CNAME as as an existing RTCPeerConnection within their common same-origin context. An WebRTC Endpoint MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550] and cannot assume that any CNAME will be chosen according to the form suggested above. 4.10. Handling of Leap Seconds The guidelines regarding handling of leap seconds to limit their impact on RTP media play-out and synchronization given in [RFC7164] SHOULD be followed. 5. WebRTC Use of RTP: Extensions There are a number of RTP extensions that are either needed to obtain full functionality, or extremely useful to improve on the baseline performance, in the WebRTC context. One set of these extensions is related to conferencing, while others are more generic in nature. The following subsections describe the various RTP extensions mandated or suggested for use within WebRTC. Perkins, et al. Expires September 18, 2016 [Page 13] Internet-Draft RTP for WebRTC March 2016 5.1. Conferencing Extensions and Topologies RTP is a protocol that inherently supports group communication. Groups can be implemented by having each endpoint send its RTP packet streams to an RTP middlebox that redistributes the traffic, by using a mesh of unicast RTP packet streams between endpoints, or by using an IP multicast group to distribute the RTP packet streams. These topologies can be implemented in a number of ways as discussed in [I-D.ietf-avtcore-rtp-topologies-update]. While the use of IP multicast groups is popular in IPTV systems, the topologies based on RTP middleboxes are dominant in interactive video conferencing environments. Topologies based on a mesh of unicast transport-layer flows to create a common RTP session have not seen widespread deployment to date. Accordingly, WebRTC Endpoints are not expected to support topologies based on IP multicast groups or to support mesh-based topologies, such as a point-to-multipoint mesh configured as a single RTP session (Topo-Mesh in the terminology of [I-D.ietf-avtcore-rtp-topologies-update]). However, a point-to- multipoint mesh constructed using several RTP sessions, implemented in WebRTC using independent RTCPeerConnections [W3C.WD-webrtc-20130910], can be expected to be used in WebRTC, and needs to be supported. WebRTC Endpoints implemented according to this memo are expected to support all the topologies described in [I-D.ietf-avtcore-rtp-topologies-update] where the RTP endpoints send and receive unicast RTP packet streams to and from some peer device, provided that peer can participate in performing congestion control on the RTP packet streams. The peer device could be another RTP endpoint, or it could be an RTP middlebox that redistributes the RTP packet streams to other RTP endpoints. This limitation means that some of the RTP middlebox-based topologies are not suitable for use in WebRTC. Specifically: o Video switching MCUs (Topo-Video-switch-MCU) SHOULD NOT be used, since they make the use of RTCP for congestion control and quality of service reports problematic (see Section 3.8 of [I-D.ietf-avtcore-rtp-topologies-update]). o The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology SHOULD NOT be used because its safe use requires a congestion control algorithm or RTP circuit breaker that handles point to multipoint, which has not yet been standardised. The following topology can be used, however it has some issues worth noting: Perkins, et al. Expires September 18, 2016 [Page 14] Internet-Draft RTP for WebRTC March 2016 o Content modifying MCUs with RTCP termination (Topo-RTCP- terminating-MCU) MAY be used. Note that in this RTP Topology, RTP loop detection and identification of active senders is the responsibility of the WebRTC application; since the clients are isolated from each other at the RTP layer, RTP cannot assist with these functions (see section 3.9 of [I-D.ietf-avtcore-rtp-topologies-update]). The RTP extensions described in Section 5.1.1 to Section 5.1.6 are designed to be used with centralised conferencing, where an RTP middlebox (e.g., a conference bridge) receives a participant's RTP packet streams and distributes them to the other participants. These extensions are not necessary for interoperability; an RTP endpoint that does not implement these extensions will work correctly, but might offer poor performance. Support for the listed extensions will greatly improve the quality of experience and, to provide a reasonable baseline quality, some of these extensions are mandatory to be supported by WebRTC Endpoints. The RTCP conferencing extensions are defined in Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF) [RFC4585] and the memo on Codec Control Messages (CCM) in RTP/ AVPF [RFC5104]; they are fully usable by the Secure variant of this profile (RTP/SAVPF) [RFC5124]. 5.1.1. Full Intra Request (FIR) The Full Intra Request message is defined in Sections 3.5.1 and 4.3.1 of the Codec Control Messages [RFC5104]. It is used to make the mixer request a new Intra picture from a participant in the session. This is used when switching between sources to ensure that the receivers can decode the video or other predictive media encoding with long prediction chains. WebRTC Endpoints that are sending media MUST understand and react to FIR feedback messages they receive, since this greatly improves the user experience when using centralised mixer-based conferencing. Support for sending FIR messages is OPTIONAL. 5.1.2. Picture Loss Indication (PLI) The Picture Loss Indication message is defined in Section 6.3.1 of the RTP/AVPF profile [RFC4585]. It is used by a receiver to tell the sending encoder that it lost the decoder context and would like to have it repaired somehow. This is semantically different from the Full Intra Request above as there could be multiple ways to fulfil the request. WebRTC Endpoints that are sending media MUST understand and react to PLI feedback messages as a loss tolerance mechanism. Receivers MAY send PLI messages. Perkins, et al. Expires September 18, 2016 [Page 15] Internet-Draft RTP for WebRTC March 2016 5.1.3. Slice Loss Indication (SLI) The Slice Loss Indication message is defined in Section 6.3.2 of the RTP/AVPF profile [RFC4585]. It is used by a receiver to tell the encoder that it has detected the loss or corruption of one or more consecutive macro blocks, and would like to have these repaired somehow. It is RECOMMENDED that receivers generate SLI feedback messages if slices are lost when using a codec that supports the concept of macro blocks. A sender that receives an SLI feedback message SHOULD attempt to repair the lost slice(s). 5.1.4. Reference Picture Selection Indication (RPSI) Reference Picture Selection Indication (RPSI) messages are defined in Section 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video encoding standards allow the use of older reference pictures than the most recent one for predictive coding. If such a codec is in use, and if the encoder has learnt that encoder-decoder synchronisation has been lost, then a known as correct reference picture can be used as a base for future coding. The RPSI message allows this to be signalled. Receivers that detect that encoder-decoder synchronisation has been lost SHOULD generate an RPSI feedback message if codec being used supports reference picture selection. A RTP packet stream sender that receives such an RPSI message SHOULD act on that messages to change the reference picture, if it is possible to do so within the available bandwidth constraints, and with the codec being used. 5.1.5. Temporal-Spatial Trade-off Request (TSTR) The temporal-spatial trade-off request and notification are defined in Sections 3.5.2 and 4.3.2 of [RFC5104]. This request can be used to ask the video encoder to change the trade-off it makes between temporal and spatial resolution, for example to prefer high spatial image quality but low frame rate. Support for TSTR requests and notifications is OPTIONAL. 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of the Codec Control Messages [RFC5104]. This request and its notification message are used by a media receiver to inform the sending party that there is a current limitation on the amount of bandwidth available to this receiver. There can be various reasons for this: for example, an RTP mixer can use this message to limit the media rate of the sender being forwarded by the mixer (without doing media transcoding) to fit the bottlenecks existing towards the other session participants. WebRTC Endpoints that are sending media are REQUIRED to implement support for TMMBR messages, and MUST follow Perkins, et al. Expires September 18, 2016 [Page 16] Internet-Draft RTP for WebRTC March 2016 bandwidth limitations set by a TMMBR message received for their SSRC. The sending of TMMBR requests is OPTIONAL. 5.2. Header Extensions The RTP specification [RFC3550] provides the capability to include RTP header extensions containing in-band data, but the format and semantics of the extensions are poorly specified. The use of header extensions is OPTIONAL in WebRTC, but if they are used, they MUST be formatted and signalled following the general mechanism for RTP header extensions defined in [RFC5285], since this gives well-defined semantics to RTP header extensions. As noted in [RFC5285], the requirement from the RTP specification that header extensions are "designed so that the header extension may be ignored" [RFC3550] stands. To be specific, header extensions MUST only be used for data that can safely be ignored by the recipient without affecting interoperability, and MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that is not compatible with the way the stream is signalled (e.g., as defined by the payload type). Valid examples of RTP header extensions might include metadata that is additional to the usual RTP information, but that can safely be ignored without compromising interoperability. 5.2.1. Rapid Synchronisation Many RTP sessions require synchronisation between audio, video, and other content. This synchronisation is performed by receivers, using information contained in RTCP SR packets, as described in the RTP specification [RFC3550]. This basic mechanism can be slow, however, so it is RECOMMENDED that the rapid RTP synchronisation extensions described in [RFC6051] be implemented in addition to RTCP SR-based synchronisation. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.2. Client-to-Mixer Audio Level The Client to Mixer Audio Level extension [RFC6464] is an RTP header extension used by an endpoint to inform a mixer about the level of audio activity in the packet to which the header is attached. This enables an RTP middlebox to make mixing or selection decisions without decoding or detailed inspection of the payload, reducing the complexity in some types of mixers. It can also save decoding resources in receivers, which can choose to decode only the most relevant RTP packet streams based on audio activity levels. Perkins, et al. Expires September 18, 2016 [Page 17] Internet-Draft RTP for WebRTC March 2016 The Client-to-Mixer Audio Level [RFC6464] header extension MUST be implemented. It is REQUIRED that implementations are capable of encrypting the header extension according to [RFC6904] since the information contained in these header extensions can be considered sensitive. The use of this encryption is RECOMMENDED, however usage of the encryption can be explicitly disabled through API or signalling. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.3. Mixer-to-Client Audio Level The Mixer to Client Audio Level header extension [RFC6465] provides an endpoint with the audio level of the different sources mixed into a common source stream by a RTP mixer. This enables a user interface to indicate the relative activity level of each session participant, rather than just being included or not based on the CSRC field. This is a pure optimisation of non critical functions, and is hence OPTIONAL to implement. If this header extension is implemented, it is REQUIRED that implementations are capable of encrypting the header extension according to [RFC6904] since the information contained in these header extensions can be considered sensitive. It is further RECOMMENDED that this encryption is used, unless the encryption has been explicitly disabled through API or signalling. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.4. Media Stream Identification WebRTC endpoints that implement the SDP bundle negotiation extension will use the SDP grouping framework 'mid' attribute to identify media streams. Such endpoints MUST implement the RTP MID header extension described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. 5.2.5. Coordination of Video Orientation WebRTC endpoints that send or receive video MUST implement the coordination of video orientation (CVO) RTP header extension as described in Section 4 of [I-D.ietf-rtcweb-video]. This header extension uses the [RFC5285] generic header extension framework, and so needs to be negotiated before it can be used. Perkins, et al. Expires September 18, 2016 [Page 18] Internet-Draft RTP for WebRTC March 2016 6. WebRTC Use of RTP: Improving Transport Robustness There are tools that can make RTP packet streams robust against packet loss and reduce the impact of loss on media quality. However, they generally add some overhead compared to a non-robust stream. The overhead needs to be considered, and the aggregate bit-rate MUST be rate controlled to avoid causing network congestion (see Section 7). As a result, improving robustness might require a lower base encoding quality, but has the potential to deliver that quality with fewer errors. The mechanisms described in the following sub- sections can be used to improve tolerance to packet loss. 6.1. Negative Acknowledgements and RTP Retransmission As a consequence of supporting the RTP/SAVPF profile, implementations can send negative acknowledgements (NACKs) for RTP data packets [RFC4585]. This feedback can be used to inform a sender of the loss of particular RTP packets, subject to the capacity limitations of the RTCP feedback channel. A sender can use this information to optimise the user experience by adapting the media encoding to compensate for known lost packets. RTP packet stream senders are REQUIRED to understand the Generic NACK message defined in Section 6.2.1 of [RFC4585], but MAY choose to ignore some or all of this feedback (following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for missing RTP packets. Guidelines on when to send NACKs are provided in [RFC4585]. It is not expected that a receiver will send a NACK for every lost RTP packet, rather it needs to consider the cost of sending NACK feedback, and the importance of the lost packet, to make an informed decision on whether it is worth telling the sender about a packet loss event. The RTP Retransmission Payload Format [RFC4588] offers the ability to retransmit lost packets based on NACK feedback. Retransmission needs to be used with care in interactive real-time applications to ensure that the retransmitted packet arrives in time to be useful, but can be effective in environments with relatively low network RTT (an RTP sender can estimate the RTT to the receivers using the information in RTCP SR and RR packets, as described at the end of Section 6.4.1 of [RFC3550]). The use of retransmissions can also increase the forward RTP bandwidth, and can potentially caused increased packet loss if the original packet loss was caused by network congestion. Note, however, that retransmission of an important lost packet to repair decoder state can have lower cost than sending a full intra frame. It is not appropriate to blindly retransmit RTP packets in response to a NACK. The importance of lost packets and the likelihood of them Perkins, et al. Expires September 18, 2016 [Page 19] Internet-Draft RTP for WebRTC March 2016 arriving in time to be useful needs to be considered before RTP retransmission is used. Receivers are REQUIRED to implement support for RTP retransmission packets [RFC4588] sent using SSRC multiplexing, and MAY also support RTP retransmission packets sent using session multiplexing. Senders MAY send RTP retransmission packets in response to NACKs if support for the RTP retransmission payload format has been negotiated, and if the sender believes it is useful to send a retransmission of the packet(s) referenced in the NACK. Senders do not need to retransmit every NACKed packet. 6.2. Forward Error Correction (FEC) The use of Forward Error Correction (FEC) can provide an effective protection against some degree of packet loss, at the cost of steady bandwidth overhead. There are several FEC schemes that are defined for use with RTP. Some of these schemes are specific to a particular RTP payload format, others operate across RTP packets and can be used with any payload format. It needs to be noted that using redundant encoding or FEC will lead to increased play out delay, which needs to be considered when choosing FEC schemes and their parameters. WebRTC endpoints MUST follow the recommendations for FEC use given in [I-D.ietf-rtcweb-fec]. WebRTC endpoints MAY support other types of FEC, but these MUST be negotiated before they are used. 7. WebRTC Use of RTP: Rate Control and Media Adaptation WebRTC will be used in heterogeneous network environments using a variety of link technologies, including both wired and wireless links, to interconnect potentially large groups of users around the world. As a result, the network paths between users can have widely varying one-way delays, available bit-rates, load levels, and traffic mixtures. Individual endpoints can send one or more RTP packet streams to each participant, and there can be several participants. Each of these RTP packet streams can contain different types of media, and the type of media, bit rate, and number of RTP packet streams as well as transport-layer flows can be highly asymmetric. Non-RTP traffic can share the network paths with RTP transport-layer flows. Since the network environment is not predictable or stable, WebRTC Endpoints MUST ensure that the RTP traffic they generate can adapt to match changes in the available network capacity. The quality of experience for users of WebRTC is very dependent on effective adaptation of the media to the limitations of the network. Endpoints have to be designed so they do not transmit significantly more data than the network path can support, except for very short Perkins, et al. Expires September 18, 2016 [Page 20] Internet-Draft RTP for WebRTC March 2016 time periods, otherwise high levels of network packet loss or delay spikes will occur, causing media quality degradation. The limiting factor on the capacity of the network path might be the link bandwidth, or it might be competition with other traffic on the link (this can be non-WebRTC traffic, traffic due to other WebRTC flows, or even competition with other WebRTC flows in the same session). An effective media congestion control algorithm is therefore an essential part of the WebRTC framework. However, at the time of this writing, there is no standard congestion control algorithm that can be used for interactive media applications such as WebRTC's flows. Some requirements for congestion control algorithms for RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements]. If a standardized congestion control algorithm that satisfies these requirements is developed in the future, this memo will need to be be updated to mandate its use. 7.1. Boundary Conditions and Circuit Breakers WebRTC Endpoints MUST implement the RTP circuit breaker algorithm that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP circuit breaker is designed to enable applications to recognise and react to situations of extreme network congestion. However, since the RTP circuit breaker might not be triggered until congestion becomes extreme, it cannot be considered a substitute for congestion control, and applications MUST also implement congestion control to allow them to adapt to changes in network capacity. The congestion control algorithm will have to be proprietary until a standardized congestion control algorithm is available. Any future RTP congestion control algorithms are expected to operate within the envelope allowed by the circuit breaker. The session establishment signalling will also necessarily establish boundaries to which the media bit-rate will conform. The choice of media codecs provides upper- and lower-bounds on the supported bit- rates that the application can utilise to provide useful quality, and the packetisation choices that exist. In addition, the signalling channel can establish maximum media bit-rate boundaries using, for example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF Temporary Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo). Signalled bandwidth limitations, such as SDP "b=AS:" or "b=CT:" lines received from the peer, MUST be followed when sending RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal its bandwidth limitations. These limitations have to be based on known bandwidth limitations, for example the capacity of the edge links. Perkins, et al. Expires September 18, 2016 [Page 21] Internet-Draft RTP for WebRTC March 2016 7.2. Congestion Control Interoperability and Legacy Systems All endpoints that wish to interwork with WebRTC MUST implement RTCP and provide congestion feedback via the defined RTCP reporting mechanisms. When interworking with legacy implementations that support RTCP using the RTP/AVP profile [RFC3551], congestion feedback is provided in RTCP RR packets every few seconds. Implementations that have to interwork with such endpoints MUST ensure that they keep within the RTP circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers] constraints to limit the congestion they can cause. If a legacy endpoint supports RTP/AVPF, this enables negotiation of important parameters for frequent reporting, such as the "trr-int" parameter, and the possibility that the endpoint supports some useful feedback format for congestion control purpose such as TMMBR [RFC5104]. Implementations that have to interwork with such endpoints MUST ensure that they stay within the RTP circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers] constraints to limit the congestion they can cause, but might find that they can achieve better congestion response depending on the amount of feedback that is available. With proprietary congestion control algorithms issues can arise when different algorithms and implementations interact in a communication session. If the different implementations have made different choices in regards to the type of adaptation, for example one sender based, and one receiver based, then one could end up in situation where one direction is dual controlled, when the other direction is not controlled. This memo cannot mandate behaviour for proprietary congestion control algorithms, but implementations that use such algorithms ought to be aware of this issue, and try to ensure that effective congestion control is negotiated for media flowing in both directions. If the IETF were to standardise both sender- and receiver-based congestion control algorithms for WebRTC traffic in the future, the issues of interoperability, control, and ensuring that both directions of media flow are congestion controlled would also need to be considered. 8. WebRTC Use of RTP: Performance Monitoring As described in Section 4.1, implementations are REQUIRED to generate RTCP Sender Report (SR) and Reception Report (RR) packets relating to the RTP packet streams they send and receive. These RTCP reports can be used for performance monitoring purposes, since they include basic packet loss and jitter statistics. Perkins, et al. Expires September 18, 2016 [Page 22] Internet-Draft RTP for WebRTC March 2016 A large number of additional performance metrics are supported by the RTCP Extended Reports (XR) framework, see [RFC3611][RFC6792]. At the time of this writing, it is not clear what extended metrics are suitable for use in WebRTC, so there is no requirement that implementations generate RTCP XR packets. However, implementations that can use detailed performance monitoring data MAY generate RTCP XR packets as appropriate. The use of RTCP XR packets SHOULD be signalled; implementations MUST ignore RTCP XR packets that are unexpected or not understood. 9. WebRTC Use of RTP: Future Extensions It is possible that the core set of RTP protocols and RTP extensions specified in this memo will prove insufficient for the future needs of WebRTC. In this case, future updates to this memo have to be made following the Guidelines for Writers of RTP Payload Format Specifications [RFC2736], How to Write an RTP Payload Format [I-D.ietf-payload-rtp-howto] and Guidelines for Extending the RTP Control Protocol [RFC5968], and SHOULD take into account any future guidelines for extending RTP and related protocols that have been developed. Authors of future extensions are urged to consider the wide range of environments in which RTP is used when recommending extensions, since extensions that are applicable in some scenarios can be problematic in others. Where possible, the WebRTC framework will adopt RTP extensions that are of general utility, to enable easy implementation of a gateway to other applications using RTP, rather than adopt mechanisms that are narrowly targeted at specific WebRTC use cases. 10. Signalling Considerations RTP is built with the assumption that an external signalling channel exists, and can be used to configure RTP sessions and their features. The basic configuration of an RTP session consists of the following parameters: RTP Profile: The name of the RTP profile to be used in session. The RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate on basic level, as can their secure variants RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. The secure variants of the profiles do not directly interoperate with the non-secure variants, due to the presence of additional header fields for authentication in SRTP packets and cryptographic transformation of the payload. WebRTC requires the use of the RTP/SAVPF profile, and this MUST be signalled. Interworking functions might transform this into the RTP/SAVP profile for a legacy use case, by indicating to the Perkins, et al. Expires September 18, 2016 [Page 23] Internet-Draft RTP for WebRTC March 2016 WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr- int value of 4 seconds. Transport Information: Source and destination IP address(s) and ports for RTP and RTCP MUST be signalled for each RTP session. In WebRTC these transport addresses will be provided by ICE [RFC5245] that signals candidates and arrives at nominated candidate address pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such that a single port, i.e. transport-layer flow, is used for RTP and RTCP flows, this MUST be signalled (see Section 4.5). RTP Payload Types, media formats, and format parameters: The mapping between media type names (and hence the RTP payload formats to be used), and the RTP payload type numbers MUST be signalled. Each media type MAY also have a number of media type parameters that MUST also be signalled to configure the codec and RTP payload format (the "a=fmtp:" line from SDP). Section 4.3 of this memo discusses requirements for uniqueness of payload types. RTP Extensions: The use of any additional RTP header extensions and RTCP packet types, including any necessary parameters, MUST be signalled. This signalling is to ensure that a WebRTC Endpoint's behaviour, especially when sending, of any extensions is predictable and consistent. For robustness, and for compatibility with non-WebRTC systems that might be connected to a WebRTC session via a gateway, implementations are REQUIRED to ignore unknown RTCP packets and RTP header extensions (see also Section 4.1). RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the endpoints will be necessary. This SHALL be done as described in "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or something semantically equivalent. This also ensures that the endpoints have a common view of the RTCP bandwidth. A common view of the RTCP bandwidth among different endpoints is important, to prevent differences in RTCP packet timing and timeout intervals causing interoperability problems. These parameters are often expressed in SDP messages conveyed within an offer/answer exchange. RTP does not depend on SDP or on the offer/answer model, but does require all the necessary parameters to be agreed upon, and provided to the RTP implementation. Note that in WebRTC it will depend on the signalling model and API how these parameters need to be configured but they will be need to either be set in the API or explicitly signalled between the peers. Perkins, et al. Expires September 18, 2016 [Page 24] Internet-Draft RTP for WebRTC March 2016 11. WebRTC API Considerations The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses the concept of a MediaStream that consists of zero or more MediaStreamTracks. A MediaStreamTrack is an individual stream of media from any type of media source like a microphone or a camera, but also conceptual sources, like a audio mix or a video composition, are possible. The MediaStreamTracks within a MediaStream might need to be synchronized during play back. A MediaStreamTrack's realisation in RTP in the context of an RTCPeerConnection consists of a source packet stream identified with an SSRC within an RTP session part of the RTCPeerConnection. The MediaStreamTrack can also result in additional packet streams, and thus SSRCs, in the same RTP session. These can be dependent packet streams from scalable encoding of the source stream associated with the MediaStreamTrack, if such a media encoder is used. They can also be redundancy packet streams, these are created when applying Forward Error Correction (Section 6.2) or RTP retransmission (Section 6.1) to the source packet stream. It is important to note that the same media source can be feeding multiple MediaStreamTracks. As different sets of constraints or other parameters can be applied to the MediaStreamTrack, each MediaStreamTrack instance added to a RTCPeerConnection SHALL result in an independent source packet stream, with its own set of associated packet streams, and thus different SSRC(s). It will depend on applied constraints and parameters if the source stream and the encoding configuration will be identical between different MediaStreamTracks sharing the same media source. If the encoding parameters and constraints are the same, an implementation could choose to use only one encoded stream to create the different RTP packet streams. Note that such optimisations would need to take into account that the constraints for one of the MediaStreamTracks can at any moment change, meaning that the encoding configurations might no longer be identical and two different encoder instances would then be needed. The same MediaStreamTrack can also be included in multiple MediaStreams, thus multiple sets of MediaStreams can implicitly need to use the same synchronisation base. To ensure that this works in all cases, and does not force an endpoint to disrupt the media by changing synchronisation base and CNAME during delivery of any ongoing packet streams, all MediaStreamTracks and their associated SSRCs originating from the same endpoint need to be sent using the same CNAME within one RTCPeerConnection. This is motivating the use of a single CNAME in Section 4.9. Perkins, et al. Expires September 18, 2016 [Page 25] Internet-Draft RTP for WebRTC March 2016 The requirement on using the same CNAME for all SSRCs that originate from the same endpoint, does not require a middlebox that forwards traffic from multiple endpoints to only use a single CNAME. Different CNAMEs normally need to be used for different RTCPeerConnection instances, as specified in Section 4.9. Having two communication sessions with the same CNAME could enable tracking of a user or device across different services (see Section 4.4.1 of [I-D.ietf-rtcweb-security] for details). A web application can request that the CNAMEs used in different RTCPeerConnections (within a same-orign context) be the same, this allows for synchronization of the endpoint's RTP packet streams across the different RTCPeerConnections. Note: this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking within a single origin. The above will currently force a WebRTC Endpoint that receives a MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing on any RTCPeerConnection to perform resynchronisation of the stream. Since the sending party needs to change the CNAME to the one it uses, this implies it has to use a local system clock as timebase for the synchronisation. Thus, the relative relation between the timebase of the incoming stream and the system sending out needs to be defined. This relation also needs monitoring for clock drift and likely adjustments of the synchronisation. The sending entity is also responsible for congestion control for its sent streams. In cases of packet loss the loss of incoming data also needs to be handled. This leads to the observation that the method that is least likely to cause issues or interruptions in the outgoing source packet stream is a model of full decoding, including repair etc., followed by encoding of the media again into the outgoing packet stream. Optimisations of this method are clearly possible and implementation specific. A WebRTC Endpoint MUST support receiving multiple MediaStreamTracks, where each of the different MediaStreamTracks (and their sets of associated packet streams) uses different CNAMEs. However, MediaStreamTracks that are received with different CNAMEs have no defined synchronisation. Note: The motivation for supporting reception of multiple CNAMEs is to allow for forward compatibility with any future changes that enable more efficient stream handling when endpoints relay/forward streams. It also ensures that endpoints can interoperate with certain types of multi-stream middleboxes or endpoints that are not WebRTC. Perkins, et al. Expires September 18, 2016 [Page 26] Internet-Draft RTP for WebRTC March 2016 Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep] specifies that the binding between the WebRTC MediaStreams, MediaStreamTracks and the SSRC is done as specified in "Cross Session Stream Identification in the Session Description Protocol" [I-D.ietf-mmusic-msid]. The MSID document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to map unknown source packet stream SSRCs to MediaStreamTracks and MediaStreams. This later is relevant to handle some cases of legacy interoperability. Commonly the RTP Payload Type of any incoming packets will reveal if the packet stream is a source stream or a redundancy or dependent packet stream. The association to the correct source packet stream depends on the payload format in use for the packet stream. Finally this specification puts a requirement on the WebRTC API to realize a method for determining the CSRC list (Section 4.1) as well as the Mixer-to-Client audio levels (Section 5.2.3) (when supported) and the basic requirements for this is further discussed in Section 12.2.1. 12. RTP Implementation Considerations The following discussion provides some guidance on the implementation of the RTP features described in this memo. The focus is on a WebRTC Endpoint implementation perspective, and while some mention is made of the behaviour of middleboxes, that is not the focus of this memo. 12.1. Configuration and Use of RTP Sessions A WebRTC Endpoint will be a simultaneous participant in one or more RTP sessions. Each RTP session can convey multiple media sources, and can include media data from multiple endpoints. In the following, some ways in which WebRTC Endpoints can configure and use RTP sessions are outlined. 12.1.1. Use of Multiple Media Sources Within an RTP Session RTP is a group communication protocol, and every RTP session can potentially contain multiple RTP packet streams. There are several reasons why this might be desirable: Multiple media types: Outside of WebRTC, it is common to use one RTP session for each type of media source (e.g., one RTP session for audio sources and one for video sources, each sent over different transport layer flows). However, to reduce the number of UDP ports used, the default in WebRTC is to send all types of media in a single RTP session, as described in Section 4.4, using RTP and RTCP multiplexing (Section 4.5) to further reduce the number of UDP ports needed. This RTP session then uses only one bi- Perkins, et al. Expires September 18, 2016 [Page 27] Internet-Draft RTP for WebRTC March 2016 directional transport-layer flow, but will contain multiple RTP packet streams, each containing a different type of media. A common example might be an endpoint with a camera and microphone that sends two RTP packet streams, one video and one audio, into a single RTP session. Multiple Capture Devices: A WebRTC Endpoint might have multiple cameras, microphones, or other media capture devices, and so might want to generate several RTP packet streams of the same media type. Alternatively, it might want to send media from a single capture device in several different formats or quality settings at once. Both can result in a single endpoint sending multiple RTP packet streams of the same media type into a single RTP session at the same time. Associated Repair Data: An endpoint might send a RTP packet stream that is somehow associated with another stream. For example, it might send an RTP packet stream that contains FEC or retransmission data relating to another stream. Some RTP payload formats send this sort of associated repair data as part of the source packet stream, while others send it as a separate packet stream. Layered or Multiple Description Coding: An endpoint can use a layered media codec, for example H.264 SVC, or a multiple description codec, that generates multiple RTP packet streams, each with a distinct RTP SSRC, within a single RTP session. RTP Mixers, Translators, and Other Middleboxes: An RTP session, in the WebRTC context, is a point-to-point association between an endpoint and some other peer device, where those devices share a common SSRC space. The peer device might be another WebRTC Endpoint, or it might be an RTP mixer, translator, or some other form of media processing middlebox. In the latter cases, the middlebox might send mixed or relayed RTP streams from several participants, that the WebRTC Endpoint will need to render. Thus, even though a WebRTC Endpoint might only be a member of a single RTP session, the peer device might be extending that RTP session to incorporate other endpoints. WebRTC is a group communication environment and endpoints need to be capable of receiving, decoding, and playing out multiple RTP packet streams at once, even in a single RTP session. 12.1.2. Use of Multiple RTP Sessions In addition to sending and receiving multiple RTP packet streams within a single RTP session, a WebRTC Endpoint might participate in Perkins, et al. Expires September 18, 2016 [Page 28] Internet-Draft RTP for WebRTC March 2016 multiple RTP sessions. There are several reasons why a WebRTC Endpoint might choose to do this: To interoperate with legacy devices: The common practice in the non- WebRTC world is to send different types of media in separate RTP sessions, for example using one RTP session for audio and another RTP session, on a separate transport layer flow, for video. All WebRTC Endpoints need to support the option of sending different types of media on different RTP sessions, so they can interwork with such legacy devices. This is discussed further in Section 4.4. To provide enhanced quality of service: Some network-based quality of service mechanisms operate on the granularity of transport layer flows. If it is desired to use these mechanisms to provide differentiated quality of service for some RTP packet streams, then those RTP packet streams need to be sent in a separate RTP session using a different transport-layer flow, and with appropriate quality of service marking. This is discussed further in Section 12.1.3. To separate media with different purposes: An endpoint might want to send RTP packet streams that have different purposes on different RTP sessions, to make it easy for the peer device to distinguish them. For example, some centralised multiparty conferencing systems display the active speaker in high resolution, but show low resolution "thumbnails" of other participants. Such systems might configure the endpoints to send simulcast high- and low- resolution versions of their video using separate RTP sessions, to simplify the operation of the RTP middlebox. In the WebRTC context this is currently possible by establishing multiple WebRTC MediaStreamTracks that have the same media source in one (or more) RTCPeerConnection. Each MediaStreamTrack is then configured to deliver a particular media quality and thus media bit-rate, and will produce an independently encoded version with the codec parameters agreed specifically in the context of that RTCPeerConnection. The RTP middlebox can distinguish packets corresponding to the low- and high-resolution streams by inspecting their SSRC, RTP payload type, or some other information contained in RTP payload, RTP header extension or RTCP packets, but it can be easier to distinguish the RTP packet streams if they arrive on separate RTP sessions on separate transport-layer flows. To directly connect with multiple peers: A multi-party conference does not need to use an RTP middlebox. Rather, a multi-unicast mesh can be created, comprising several distinct RTP sessions, with each participant sending RTP traffic over a separate RTP session (that is, using an independent RTCPeerConnection object) Perkins, et al. Expires September 18, 2016 [Page 29] Internet-Draft RTP for WebRTC March 2016 to every other participant, as shown in Figure 1. This topology has the benefit of not requiring an RTP middlebox node that is trusted to access and manipulate the media data. The downside is that it increases the used bandwidth at each sender by requiring one copy of the RTP packet streams for each participant that are part of the same session beyond the sender itself. +---+ +---+ | A |<--->| B | +---+ +---+ ^ ^ \ / \ / v v +---+ | C | +---+ Figure 1: Multi-unicast using several RTP sessions The multi-unicast topology could also be implemented as a single RTP session, spanning multiple peer-to-peer transport layer connections, or as several pairwise RTP sessions, one between each pair of peers. To maintain a coherent mapping of the relationship between RTP sessions and RTCPeerConnection objects it is recommend that this is implemented as several individual RTP sessions. The only downside is that endpoint A will not learn of the quality of any transmission happening between B and C, since it will not see RTCP reports for the RTP session between B and C, whereas it would if all three participants were part of a single RTP session. Experience with the Mbone tools (experimental RTP-based multicast conferencing tools from the late 1990s) has showed that RTCP reception quality reports for third parties can be presented to users in a way that helps them understand asymmetric network problems, and the approach of using separate RTP sessions prevents this. However, an advantage of using separate RTP sessions is that it enables using different media bit-rates and RTP session configurations between the different peers, thus not forcing B to endure the same quality reductions if there are limitations in the transport from A to C as C will. It is believed that these advantages outweigh the limitations in debugging power. To indirectly connect with multiple peers: A common scenario in multi-party conferencing is to create indirect connections to multiple peers, using an RTP mixer, translator, or some other type of RTP middlebox. Figure 2 outlines a simple topology that might be used in a four-person centralised conference. The middlebox Perkins, et al. Expires September 18, 2016 [Page 30] Internet-Draft RTP for WebRTC March 2016 acts to optimise the transmission of RTP packet streams from certain perspectives, either by only sending some of the received RTP packet stream to any given receiver, or by providing a combined RTP packet stream out of a set of contributing streams. +---+ +-------------+ +---+ | A |<---->| |<---->| B | +---+ | RTP mixer, | +---+ | translator, | | or other | +---+ | middlebox | +---+ | C |<---->| |<---->| D | +---+ +-------------+ +---+ Figure 2: RTP mixer with only unicast paths There are various methods of implementation for the middlebox. If implemented as a standard RTP mixer or translator, a single RTP session will extend across the middlebox and encompass all the endpoints in one multi-party session. Other types of middlebox might use separate RTP sessions between each endpoint and the middlebox. A common aspect is that these RTP middleboxes can use a number of tools to control the media encoding provided by a WebRTC Endpoint. This includes functions like requesting the breaking of the encoding chain and have the encoder produce a so called Intra frame. Another is limiting the bit-rate of a given stream to better suit the mixer view of the multiple down-streams. Others are controlling the most suitable frame-rate, picture resolution, the trade-off between frame-rate and spatial quality. The middlebox has the responsibility to correctly perform congestion control, source identification, manage synchronisation while providing the application with suitable media optimisations. The middlebox also has to be a trusted node when it comes to security, since it manipulates either the RTP header or the media itself (or both) received from one endpoint, before sending it on towards the endpoint(s), thus they need to be able to decrypt and then re-encrypt the RTP packet stream before sending it out. RTP Mixers can create a situation where an endpoint experiences a situation in-between a session with only two endpoints and multiple RTP sessions. Mixers are expected to not forward RTCP reports regarding RTP packet streams across themselves. This is due to the difference in the RTP packet streams provided to the different endpoints. The original media source lacks information about a mixer's manipulations prior to sending it the different receivers. This scenario also results in that an endpoint's Perkins, et al. Expires September 18, 2016 [Page 31] Internet-Draft RTP for WebRTC March 2016 feedback or requests go to the mixer. When the mixer can't act on this by itself, it is forced to go to the original media source to fulfil the receivers request. This will not necessarily be explicitly visible to any RTP and RTCP traffic, but the interactions and the time to complete them will indicate such dependencies. Providing source authentication in multi-party scenarios is a challenge. In the mixer-based topologies, endpoints source authentication is based on, firstly, verifying that media comes from the mixer by cryptographic verification and, secondly, trust in the mixer to correctly identify any source towards the endpoint. In RTP sessions where multiple endpoints are directly visible to an endpoint, all endpoints will have knowledge about each others' master keys, and can thus inject packets claimed to come from another endpoint in the session. Any node performing relay can perform non-cryptographic mitigation by preventing forwarding of packets that have SSRC fields that came from other endpoints before. For cryptographic verification of the source, SRTP would require additional security mechanisms, for example TESLA for SRTP [RFC4383], that are not part of the base WebRTC standards. To forward media between multiple peers: It is sometimes desirable for an endpoint that receives an RTP packet stream to be able to forward that RTP packet stream to a third party. The are some obvious security and privacy implications in supporting this, but also potential uses. This is supported in the W3C API by taking the received and decoded media and using it as media source that is re-encoding and transmitted as a new stream. At the RTP layer, media forwarding acts as a back-to-back RTP receiver and RTP sender. The receiving side terminates the RTP session and decodes the media, while the sender side re-encodes and transmits the media using an entirely separate RTP session. The original sender will only see a single receiver of the media, and will not be able to tell that forwarding is happening based on RTP-layer information since the RTP session that is used to send the forwarded media is not connected to the RTP session on which the media was received by the node doing the forwarding. The endpoint that is performing the forwarding is responsible for producing an RTP packet stream suitable for onwards transmission. The outgoing RTP session that is used to send the forwarded media is entirely separate to the RTP session on which the media was received. This will require media transcoding for congestion control purpose to produce a suitable bit-rate for the outgoing RTP session, reducing media quality and forcing the forwarding Perkins, et al. Expires September 18, 2016 [Page 32] Internet-Draft RTP for WebRTC March 2016 endpoint to spend the resource on the transcoding. The media transcoding does result in a separation of the two different legs removing almost all dependencies, and allowing the forwarding endpoint to optimise its media transcoding operation. The cost is greatly increased computational complexity on the forwarding node. Receivers of the forwarded stream will see the forwarding device as the sender of the stream, and will not be able to tell from the RTP layer that they are receiving a forwarded stream rather than an entirely new RTP packet stream generated by the forwarding device. 12.1.3. Differentiated Treatment of RTP Streams There are use cases for differentiated treatment of RTP packet streams. Such differentiation can happen at several places in the system. First of all is the prioritization within the endpoint sending the media, which controls, both which RTP packet streams that will be sent, and their allocation of bit-rate out of the current available aggregate as determined by the congestion control. It is expected that the WebRTC API [W3C.WD-webrtc-20130910] will allow the application to indicate relative priorities for different MediaStreamTracks. These priorities can then be used to influence the local RTP processing, especially when it comes to congestion control response in how to divide the available bandwidth between the RTP packet streams. Any changes in relative priority will also need to be considered for RTP packet streams that are associated with the main RTP packet streams, such as redundant streams for RTP retransmission and FEC. The importance of such redundant RTP packet streams is dependent on the media type and codec used, in regards to how robust that codec is to packet loss. However, a default policy might to be to use the same priority for redundant RTP packet stream as for the source RTP packet stream. Secondly, the network can prioritize transport-layer flows and sub- flows, including RTP packet streams. Typically, differential treatment includes two steps, the first being identifying whether an IP packet belongs to a class that has to be treated differently, the second consisting of the actual mechanism to prioritize packets. Three common methods for classifying IP packets are: DiffServ: The endpoint marks a packet with a DiffServ code point to indicate to the network that the packet belongs to a particular class. Flow based: Packets that need to be given a particular treatment are identified using a combination of IP and port address. Perkins, et al. Expires September 18, 2016 [Page 33] Internet-Draft RTP for WebRTC March 2016 Deep Packet Inspection: A network classifier (DPI) inspects the packet and tries to determine if the packet represents a particular application and type that is to be prioritized. Flow-based differentiation will provide the same treatment to all packets within a transport-layer flow, i.e., relative prioritization is not possible. Moreover, if the resources are limited it might not be possible to provide differential treatment compared to best-effort for all the RTP packet streams used in a WebRTC session. The use of flow-based differentiation needs to be coordinated between the WebRTC system and the network(s). The WebRTC endpoint needs to know that flow-based differentiation might be used to provide the separation of the RTP packet streams onto different UDP flows to enable a more granular usage of flow based differentiation. The used flows, their 5-tuples and prioritization will need to be communicated to the network so that it can identify the flows correctly to enable prioritization. No specific protocol support for this is specified. DiffServ assumes that either the endpoint or a classifier can mark the packets with an appropriate DSCP so that the packets are treated according to that marking. If the endpoint is to mark the traffic two requirements arise in the WebRTC context: 1) The WebRTC Endpoint has to know which DSCP to use and that it can use them on some set of RTP packet streams. 2) The information needs to be propagated to the operating system when transmitting the packet. Details of this process are outside the scope of this memo and are further discussed in "DSCP and other packet markings for RTCWeb QoS" [I-D.ietf-tsvwg-rtcweb-qos]. Deep Packet Inspectors will, despite the SRTP media encryption, still be fairly capable at classifying the RTP streams. The reason is that SRTP leaves the first 12 bytes of the RTP header unencrypted. This enables easy RTP stream identification using the SSRC and provides the classifier with useful information that can be correlated to determine for example the stream's media type. Using packet sizes, reception times, packet inter-spacing, RTP timestamp increments and sequence numbers, fairly reliable classifications are achieved. For packet based marking schemes it might be possible to mark individual RTP packets differently based on the relative priority of the RTP payload. For example video codecs that have I, P, and B pictures could prioritise any payloads carrying only B frames less, as these are less damaging to loose. However, depending on the QoS mechanism and what markings that are applied, this can result in not only different packet drop probabilities but also packet reordering, see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for further discussion. As a default policy all RTP packets related to a RTP packet stream ought to be provided with the same prioritization; Perkins, et al. Expires September 18, 2016 [Page 34] Internet-Draft RTP for WebRTC March 2016 per-packet prioritization is outside the scope of this memo, but might be specified elsewhere in future. It is also important to consider how RTCP packets associated with a particular RTP packet stream need to be marked. RTCP compound packets with Sender Reports (SR), ought to be marked with the same priority as the RTP packet stream itself, so the RTCP-based round- trip time (RTT) measurements are done using the same transport-layer flow priority as the RTP packet stream experiences. RTCP compound packets containing RR packet ought to be sent with the priority used by the majority of the RTP packet streams reported on. RTCP packets containing time-critical feedback packets can use higher priority to improve the timeliness and likelihood of delivery of such feedback. 12.2. Media Source, RTP Streams, and Participant Identification 12.2.1. Media Source Identification Each RTP packet stream is identified by a unique synchronisation source (SSRC) identifier. The SSRC identifier is carried in each of the RTP packets comprising a RTP packet stream, and is also used to identify that stream in the corresponding RTCP reports. The SSRC is chosen as discussed in Section 4.8. The first stage in demultiplexing RTP and RTCP packets received on a single transport layer flow at a WebRTC Endpoint is to separate the RTP packet streams based on their SSRC value; once that is done, additional demultiplexing steps can determine how and where to render the media. RTP allows a mixer, or other RTP-layer middlebox, to combine encoded streams from multiple media sources to form a new encoded stream from a new media source (the mixer). The RTP packets in that new RTP packet stream can include a Contributing Source (CSRC) list, indicating which original SSRCs contributed to the combined source stream. As described in Section 4.1, implementations need to support reception of RTP data packets containing a CSRC list and RTCP packets that relate to sources present in the CSRC list. The CSRC list can change on a packet-by-packet basis, depending on the mixing operation being performed. Knowledge of what media sources contributed to a particular RTP packet can be important if the user interface indicates which participants are active in the session. Changes in the CSRC list included in packets needs to be exposed to the WebRTC application using some API, if the application is to be able to track changes in session participation. It is desirable to map CSRC values back into WebRTC MediaStream identities as they cross this API, to avoid exposing the SSRC/CSRC name space to WebRTC applications. If the mixer-to-client audio level extension [RFC6465] is being used in the session (see Section 5.2.3), the information in the CSRC list Perkins, et al. Expires September 18, 2016 [Page 35] Internet-Draft RTP for WebRTC March 2016 is augmented by audio level information for each contributing source. It is desirable to expose this information to the WebRTC application using some API, after mapping the CSRC values to WebRTC MediaStream identities, so it can be exposed in the user interface. 12.2.2. SSRC Collision Detection The RTP standard requires RTP implementations to have support for detecting and handling SSRC collisions, i.e., resolve the conflict when two different endpoints use the same SSRC value (see section 8.2 of [RFC3550]). This requirement also applies to WebRTC Endpoints. There are several scenarios where SSRC collisions can occur: o In a point-to-point session where each SSRC is associated with either of the two endpoints and where the main media carrying SSRC identifier will be announced in the signalling channel, a collision is less likely to occur due to the information about used SSRCs. If SDP is used, this information is provided by Source-Specific SDP Attributes [RFC5576]. Still, collisions can occur if both endpoints start using a new SSRC identifier prior to having signalled it to the peer and received acknowledgement on the signalling message. The Source-Specific SDP Attributes [RFC5576] contains a mechanism to signal how the endpoint resolved the SSRC collision. o SSRC values that have not been signalled could also appear in an RTP session. This is more likely than it appears, since some RTP functions use extra SSRCs to provide their functionality. For example, retransmission data might be transmitted using a separate RTP packet stream that requires its own SSRC, separate to the SSRC of the source RTP packet stream [RFC4588]. In those cases, an endpoint can create a new SSRC that strictly doesn't need to be announced over the signalling channel to function correctly on both RTP and RTCPeerConnection level. o Multiple endpoints in a multiparty conference can create new sources and signal those towards the RTP middlebox. In cases where the SSRC/CSRC are propagated between the different endpoints from the RTP middlebox collisions can occur. o An RTP middlebox could connect an endpoint's RTCPeerConnection to another RTCPeerConnection from the same endpoint, thus forming a loop where the endpoint will receive its own traffic. While it is clearly considered a bug, it is important that the endpoint is able to recognise and handle the case when it occurs. This case becomes even more problematic when media mixers, and so on, are involved, where the stream received is a different stream but still contains this client's input. Perkins, et al. Expires September 18, 2016 [Page 36] Internet-Draft RTP for WebRTC March 2016 These SSRC/CSRC collisions can only be handled on RTP level as long as the same RTP session is extended across multiple RTCPeerConnections by a RTP middlebox. To resolve the more generic case where multiple RTCPeerConnections are interconnected, identification of the media source(s) part of a MediaStreamTrack being propagated across multiple interconnected RTCPeerConnection needs to be preserved across these interconnections. 12.2.3. Media Synchronisation Context When an endpoint sends media from more than one media source, it needs to consider if (and which of) these media sources are to be synchronized. In RTP/RTCP, synchronisation is provided by having a set of RTP packet streams be indicated as coming from the same synchronisation context and logical endpoint by using the same RTCP CNAME identifier. The next provision is that the internal clocks of all media sources, i.e., what drives the RTP timestamp, can be correlated to a system clock that is provided in RTCP Sender Reports encoded in an NTP format. By correlating all RTP timestamps to a common system clock for all sources, the timing relation of the different RTP packet streams, also across multiple RTP sessions can be derived at the receiver and, if desired, the streams can be synchronized. The requirement is for the media sender to provide the correlation information; it is up to the receiver to use it or not. 13. Security Considerations The overall security architecture for WebRTC is described in [I-D.ietf-rtcweb-security-arch], and security considerations for the WebRTC framework are described in [I-D.ietf-rtcweb-security]. These considerations also apply to this memo. The security considerations of the RTP specification, the RTP/SAVPF profile, and the various RTP/RTCP extensions and RTP payload formats that form the complete protocol suite described in this memo apply. It is not believed there are any new security considerations resulting from the combination of these various protocol extensions. The Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides handling of fundamental issues by offering confidentiality, integrity and partial source authentication. A mandatory to implement and use media security solution is created by combining this secured RTP profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of [I-D.ietf-rtcweb-security-arch]. Perkins, et al. Expires September 18, 2016 [Page 37] Internet-Draft RTP for WebRTC March 2016 RTCP packets convey a Canonical Name (CNAME) identifier that is used to associate RTP packet streams that need to be synchronised across related RTP sessions. Inappropriate choice of CNAME values can be a privacy concern, since long-term persistent CNAME identifiers can be used to track users across multiple WebRTC calls. Section 4.9 of this memo mandates generation of short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in untraceable CNAME values that alleviate this risk. Some potential denial of service attacks exist if the RTCP reporting interval is configured to an inappropriate value. This could be done by configuring the RTCP bandwidth fraction to an excessively large or small value using the SDP "b=RR:" or "b=RS:" lines [RFC3556], or some similar mechanism, or by choosing an excessively large or small value for the RTP/AVPF minimal receiver report interval (if using SDP, this is the "a=rtcp-fb:... trr-int" parameter) [RFC4585]. The risks are as follows: 1. the RTCP bandwidth could be configured to make the regular reporting interval so large that effective congestion control cannot be maintained, potentially leading to denial of service due to congestion caused by the media traffic; 2. the RTCP interval could be configured to a very small value, causing endpoints to generate high rate RTCP traffic, potentially leading to denial of service due to the non-congestion controlled RTCP traffic; and 3. RTCP parameters could be configured differently for each endpoint, with some of the endpoints using a large reporting interval and some using a smaller interval, leading to denial of service due to premature participant timeouts due to mismatched timeout periods which are based on the reporting interval (this is a particular concern if endpoints use a small but non-zero value for the RTP/AVPF minimal receiver report interval (trr-int) [RFC4585], as discussed in Section 6.1 of [I-D.ietf-avtcore-rtp-multi-stream]). Premature participant timeout can be avoided by using the fixed (non- reduced) minimum interval when calculating the participant timeout (see Section 4.1 of this memo and Section 6.1 of [I-D.ietf-avtcore-rtp-multi-stream]). To address the other concerns, endpoints SHOULD ignore parameters that configure the RTCP reporting interval to be significantly longer than the default five second interval specified in [RFC3550] (unless the media data rate is so low that the longer reporting interval roughly corresponds to 5% of the media data rate), or that configure the RTCP reporting interval small enough that the RTCP bandwidth would exceed the media bandwidth. Perkins, et al. Expires September 18, 2016 [Page 38] Internet-Draft RTP for WebRTC March 2016 The guidelines in [RFC6562] apply when using variable bit rate (VBR) audio codecs such as Opus (see Section 4.3 for discussion of mandated audio codecs). The guidelines in [RFC6562] also apply, but are of lesser importance, when using the client-to-mixer audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.3). The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes performing voice activity based source selection or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. If further evidence are produced to show that information leakage is significant from audio level indications, then use of encryption needs to be mandated at that time. In multi-party communication scenarios using RTP Middleboxes, a lot of trust is placed on these middleboxes to preserve the sessions security. The middlebox needs to maintain the confidentiality, integrity and perform source authentication. As discussed in Section 12.1.1 the middlebox can perform checks that prevents any endpoint participating in a conference to impersonate another. Some additional security considerations regarding multi-party topologies can be found in [I-D.ietf-avtcore-rtp-topologies-update]. 14. IANA Considerations This memo makes no request of IANA. Note to RFC Editor: this section is to be removed on publication as an RFC. 15. Acknowledgements The authors would like to thank Bernard Aboba, Harald Alvestrand, Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin Thomson, and the other members of the IETF RTCWEB working group for their valuable feedback. 16. References 16.1. Normative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", draft- ietf-avtcore-multi-media-rtp-session-13 (work in progress), December 2015. Perkins, et al. Expires September 18, 2016 [Page 39] Internet-Draft RTP for WebRTC March 2016 [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Varun, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-13 (work in progress), February 2016. [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), December 2015. [I-D.ietf-avtcore-rtp-multi-stream-optimisation] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback", draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work in progress), March 2016. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- ietf-avtcore-rtp-topologies-update-10 (work in progress), July 2015. [I-D.ietf-mmusic-mux-exclusive] Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", draft-ietf-mmusic-mux- exclusive-03 (work in progress), February 2016. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-27 (work in progress), February 2016. [I-D.ietf-rtcweb-audio] Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Requirements", draft-ietf-rtcweb-audio-10 (work in progress), February 2016. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-02 (work in progress), October 2015. Perkins, et al. Expires September 18, 2016 [Page 40] Internet-Draft RTP for WebRTC March 2016 [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-15 (work in progress), January 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-11 (work in progress), March 2015. [I-D.ietf-rtcweb-video] Roach, A., "WebRTC Video Processing and Codec Requirements", draft-ietf-rtcweb-video-06 (work in progress), June 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, . [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . Perkins, et al. Expires September 18, 2016 [Page 41] Internet-Draft RTP for WebRTC March 2016 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, . [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, . [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, . [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, . [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, . [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, . [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, . [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . Perkins, et al. Expires September 18, 2016 [Page 42] Internet-Draft RTP for WebRTC March 2016 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, . [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, . [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- time Transport Protocol (RTP) Header Extension for Mixer- to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, . [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, . [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, . [RFC7007] Terriberry, T., "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)", RFC 7007, DOI 10.17487/RFC7007, August 2013, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, . [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, DOI 10.17487/RFC7164, March 2014, . Perkins, et al. Expires September 18, 2016 [Page 43] Internet-Draft RTP for WebRTC March 2016 [W3C.WD-mediacapture-streams-20130903] Burnett, D., Bergkvist, A., Jennings, C., and A. Narayanan, "Media Capture and Streams", World Wide Web Consortium WD WD-mediacapture-streams-20130903, September 2013, . [W3C.WD-webrtc-20130910] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc- 20130910, September 2013, . 16.2. Informative References [I-D.ietf-avtcore-multiplex-guidelines] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams", draft-ietf-avtcore- multiplex-guidelines-03 (work in progress), October 2014. [I-D.ietf-avtext-rtp-grouping-taxonomy] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", draft-ietf- avtext-rtp-grouping-taxonomy-08 (work in progress), July 2015. [I-D.ietf-dart-dscp-rtp] Black, D. and P. Jones, "Differentiated Services (DiffServ) and Real-time Communication", draft-ietf-dart- dscp-rtp-10 (work in progress), November 2014. [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", draft-ietf-mmusic-msid-11 (work in progress), October 2015. [I-D.ietf-payload-rtp-howto] Westerlund, M., "How to Write an RTP Payload Format", draft-ietf-payload-rtp-howto-14 (work in progress), May 2015. [I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", draft-ietf-rmcat-cc- requirements-09 (work in progress), December 2014. Perkins, et al. Expires September 18, 2016 [Page 44] Internet-Draft RTP for WebRTC March 2016 [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-13 (work in progress), March 2016. [I-D.ietf-tsvwg-rtcweb-qos] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP and other packet markings for WebRTC QoS", draft-ietf- tsvwg-rtcweb-qos-14 (work in progress), March 2016. [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, . [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, DOI 10.17487/RFC4383, February 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", RFC 5968, DOI 10.17487/RFC5968, September 2010, . [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, . [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, . Perkins, et al. Expires September 18, 2016 [Page 45] Internet-Draft RTP for WebRTC March 2016 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, . Authors' Addresses Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org URI: https://csperkins.org/ Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com Joerg Ott Aalto University School of Electrical Engineering Espoo 02150 Finland Email: jorg.ott@aalto.fi Perkins, et al. Expires September 18, 2016 [Page 46] ./draft-ietf-rtcweb-security-12.txt0000644000764400076440000020011213507676213016514 0ustar iustyiusty RTC-Web E. Rescorla Internet-Draft RTFM, Inc. Intended status: Standards Track July 5, 2019 Expires: January 6, 2020 Security Considerations for WebRTC draft-ietf-rtcweb-security-12 Abstract WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Rescorla Expires January 6, 2020 [Page 1] Internet-Draft WebRTC Security July 2019 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Browser Threat Model . . . . . . . . . . . . . . . . . . 4 3.1. Access to Local Resources . . . . . . . . . . . . . . . . 5 3.2. Same-Origin Policy . . . . . . . . . . . . . . . . . . . 5 3.3. Bypassing SOP: CORS, WebSockets, and consent to communicate . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security for WebRTC Applications . . . . . . . . . . . . . . 7 4.1. Access to Local Devices . . . . . . . . . . . . . . . . . 7 4.1.1. Threats from Screen Sharing . . . . . . . . . . . . . 8 4.1.2. Calling Scenarios and User Expectations . . . . . . . 8 4.1.2.1. Dedicated Calling Services . . . . . . . . . . . 9 4.1.2.2. Calling the Site You're On . . . . . . . . . . . 9 4.1.3. Origin-Based Security . . . . . . . . . . . . . . . . 10 4.1.4. Security Properties of the Calling Page . . . . . . . 11 4.2. Communications Consent Verification . . . . . . . . . . . 12 4.2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. Masking . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 14 4.2.4. IP Location Privacy . . . . . . . . . . . . . . . . . 15 4.3. Communications Security . . . . . . . . . . . . . . . . . 15 4.3.1. Protecting Against Retrospective Compromise . . . . . 16 4.3.2. Protecting Against During-Call Attack . . . . . . . . 17 4.3.2.1. Key Continuity . . . . . . . . . . . . . . . . . 17 4.3.2.2. Short Authentication Strings . . . . . . . . . . 18 4.3.2.3. Third Party Identity . . . . . . . . . . . . . . 19 4.3.2.4. Page Access to Media . . . . . . . . . . . . . . 19 4.3.3. Malicious Peers . . . . . . . . . . . . . . . . . . . 20 4.4. Privacy Considerations . . . . . . . . . . . . . . . . . 20 4.4.1. Correlation of Anonymous Calls . . . . . . . . . . . 21 4.4.2. Browser Fingerprinting . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 Rescorla Expires January 6, 2020 [Page 2] Internet-Draft WebRTC Security July 2019 8. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The Real-Time Communications on the Web (RTCWEB) working group has standardized protocols for real-time communications between Web browsers, generally called "WebRTC" [I-D.ietf-rtcweb-overview]. The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP-based [RFC3261] soft phones) WebRTC communications are directly controlled by some Web server. A simple case is shown below. +----------------+ | | | Web Server | | | +----------------+ ^ ^ / \ HTTP / \ HTTP or / \ or WebSockets / \ WebSockets v v JS API JS API +-----------+ +-----------+ | | Media | | | Browser |<---------->| Browser | | | | | +-----------+ +-----------+ Alice Bob Figure 1: A simple WebRTC system In the system shown in Figure 1, Alice and Bob both have WebRTC- enabled browsers and they visit some Web server which operates a calling service. Each of their browsers exposes standardized JavaScript calling APIs (implemented as browser built-ins) which are used by the Web server to set up a call between Alice and Bob. The Web server also serves as the signaling channel to transport control messages between the browsers. While this system is topologically similar to a conventional SIP-based system (with the Web server acting as the signaling service and browsers acting as softphones), Rescorla Expires January 6, 2020 [Page 3] Internet-Draft WebRTC Security July 2019 control has moved to the central Web server; the browser simply provides API points that are used by the calling service. As with any Web application, the Web server can move logic between the server and JavaScript in the browser, but regardless of where the code is executing, it is ultimately under control of the server. It should be immediately apparent that this type of system poses new security challenges beyond those of a conventional VoIP system. In particular, it needs to contend with malicious calling services. For example, if the calling service can cause the browser to make a call at any time to any callee of its choice, then this facility can be used to bug a user's computer without their knowledge, simply by placing a call to some recording service. More subtly, if the exposed APIs allow the server to instruct the browser to send arbitrary content, then they can be used to bypass firewalls or mount denial of service attacks. Any successful system will need to be resistant to this and other attacks. A companion document [I-D.ietf-rtcweb-security-arch] describes a security architecture intended to address the issues raised in this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The Browser Threat Model The security requirements for WebRTC follow directly from the requirement that the browser's job is to protect the user. Huang et al. [huang-w2sp] summarize the core browser security guarantee as: Users can safely visit arbitrary web sites and execute scripts provided by those sites. It is important to realize that this includes sites hosting arbitrary malicious scripts. The motivation for this requirement is simple: it is trivial for attackers to divert users to sites of their choice. For instance, an attacker can purchase display advertisements which direct the user (either automatically or via user clicking) to their site, at which point the browser will execute the attacker's scripts. Thus, it is important that it be safe to view arbitrarily malicious pages. Of course, browsers inevitably have bugs which cause them to fall short of this goal, but any new WebRTC functionality must be Rescorla Expires January 6, 2020 [Page 4] Internet-Draft WebRTC Security July 2019 designed with the intent to meet this standard. The remainder of this section provides more background on the existing Web security model. In this model, then, the browser acts as a Trusted Coomputing Base (TCB) both from the user's perspective and to some extent from the server's. While HTML and JavaScript (JS) provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below. Conventionally, we refer to either web attackers, who are able to induce you to visit their sites but do not control the network, and network attackers, who are able to control your network. Network attackers correspond to the [RFC3552] "Internet Threat Model". Note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker. 3.1. Access to Local Resources While the browser has access to local resources such as keying material, files, the camera, and the microphone, it strictly limits or forbids web servers from accessing those same resources. For instance, while it is possible to produce an HTML form which will allow file upload, a script cannot do so without user consent and in fact cannot even suggest a specific file (e.g., /etc/passwd); the user must explicitly select the file and consent to its upload. [Note: in many cases browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks", as extensive research [cranor-wolf] shows that users are prone to consent under such circumstances.] Similarly, while Flash programs (SWFs) [SWF] can access the camera and microphone, they explicitly require that the user consent to that access. In addition, some resources simply cannot be accessed from the browser at all. For instance, there is no real way to run specific executables directly from a script (though the user can of course be induced to download executable files and run them). 3.2. Same-Origin Policy Many other resources are accessible but isolated. For instance, while scripts are allowed to make HTTP requests via the XMLHttpRequest() API (see [XmlHttpRequest]) those requests are not Rescorla Expires January 6, 2020 [Page 5] Internet-Draft WebRTC Security July 2019 allowed to be made to any server, but rather solely to the same ORIGIN from whence the script came [RFC6454] (although CORS [CORS] and WebSockets [RFC6455] provide an escape hatch from this restriction, as described below.) This SAME ORIGIN POLICY (SOP) prevents server A from mounting attacks on server B via the user's browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack). More generally, SOP forces scripts from each site to run in their own, isolated, sandboxes. While there are techniques to allow them to interact, those interactions generally must be mutually consensual (by each site) and are limited to certain channels. For instance, multiple pages/browser panes from the same origin can read each other's JS variables, but pages from the different origins--or even iframes from different origins on the same page--cannot. 3.3. Bypassing SOP: CORS, WebSockets, and consent to communicate While SOP serves an important security function, it also makes it inconvenient to write certain classes of applications. In particular, mash-ups, in which a script from origin A uses resources from origin B, can only be achieved via a certain amount of hackery. The W3C Cross-Origin Resource Sharing (CORS) spec [CORS] is a response to this demand. In CORS, when a script from origin A executes what would otherwise be a forbidden cross-origin request, the browser instead contacts the target server to determine whether it is willing to allow cross-origin requests from A. If it is so willing, the browser then allows the request. This consent verification process is designed to safely allow cross-origin requests. While CORS is designed to allow cross-origin HTTP requests, WebSockets [RFC6455] allows cross-origin establishment of transparent channels. Once a WebSockets connection has been established from a script to a site, the script can exchange any traffic it likes without being required to frame it as a series of HTTP request/ response transactions. As with CORS, a WebSockets transaction starts with a consent verification stage to avoid allowing scripts to simply send arbitrary data to another origin. While consent verification is conceptually simple--just do a handshake before you start exchanging the real data--experience has shown that designing a correct consent verification system is difficult. In particular, Huang et al. [huang-w2sp] have shown vulnerabilities in the existing Java and Flash consent verification techniques and in a simplified version of the WebSockets handshake. In particular, it is important to be wary of CROSS-PROTOCOL attacks in which the attacking script generates traffic which is acceptable Rescorla Expires January 6, 2020 [Page 6] Internet-Draft WebRTC Security July 2019 to some non-Web protocol state machine. In order to resist this form of attack, WebSockets incorporates a masking technique intended to randomize the bits on the wire, thus making it more difficult to generate traffic which resembles a given protocol. 4. Security for WebRTC Applications 4.1. Access to Local Devices As discussed in Section 1, allowing arbitrary sites to initiate calls violates the core Web security guarantee; without some access restrictions on local devices, any malicious site could simply bug a user. At minimum, then, it MUST NOT be possible for arbitrary sites to initiate calls to arbitrary locations without user consent. This immediately raises the question, however, of what should be the scope of user consent. In order for the user to make an intelligent decision about whether to allow a call (and hence his camera and microphone input to be routed somewhere), he must understand either who is requesting access, where the media is going, or both. As detailed below, there are two basic conceptual models: 1. You are sending your media to entity A because you want to talk to Entity A (e.g., your mother). 2. Entity A (e.g., a calling service) asks to access the user's devices with the assurance that it will transfer the media to entity B (e.g., your mother) In either case, identity is at the heart of any consent decision. Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C. Similarly, if you authorize A to place a call to B, A can call C instead. In either cases, all the browser is able to do is verify and check authorization for whoever is controlling where the media goes. The target of the media can of course advertise a security/privacy policy, but this is not something that the browser can enforce. Even so, there are a variety of different consent scenarios that motivate different technical consent mechanisms. We discuss these mechanisms in the sections below. It's important to understand that consent to access local devices is largely orthogonal to consent to transmit various kinds of data over the network (see Section 4.2). Consent for device access is largely a matter of protecting the user's privacy from malicious sites. By contrast, consent to send network traffic is about preventing the user's browser from being used to attack its local network. Thus, we Rescorla Expires January 6, 2020 [Page 7] Internet-Draft WebRTC Security July 2019 need to ensure communications consent even if the site is not able to access the camera and microphone at all (hence WebSockets's consent mechanism) and similarly we need to be concerned with the site accessing the user's camera and microphone even if the data is to be sent back to the site via conventional HTTP-based network mechanisms such as HTTP POST. 4.1.1. Threats from Screen Sharing In addition to camera and microphone access, there has been demand for screen and/or application sharing functionality. Unfortunately, the security implications of this functionality are much harder for users to intuitively analyze than for camera and microphone access. (See http://lists.w3.org/Archives/Public/public- webrtc/2013Mar/0024.html for a full analysis.) The most obvious threats are simply those of "oversharing". I.e., the user may believe they are sharing a window when in fact they are sharing an application, or may forget they are sharing their whole screen, icons, notifications, and all. This is already an issue with existing screen sharing technologies and is made somewhat worse if a partially trusted site is responsible for asking for the resource to be shared rather than having the user propose it. A less obvious threat involves the impact of screen sharing on the Web security model. A key part of the Same-Origin Policy is that HTML or JS from site A can reference content from site B and cause the browser to load it, but (unless explicitly permitted) cannot see the result. However, if a web application from a site is screen sharing the browser, then this violates that invariant, with serious security consequences. For example, an attacker site might request screen sharing and then briefly open up a new Window to the user's bank or webmail account, using screen sharing to read the resulting displayed content. A more sophisticated attack would be open up a source view window to a site and use the screen sharing result to view anti cross-site request forgery tokens. These threats suggest that screen/application sharing might need a higher level of user consent than access to the camera or microphone. 4.1.2. Calling Scenarios and User Expectations While a large number of possible calling scenarios are possible, the scenarios discussed in this section illustrate many of the difficulties of identifying the relevant scope of consent. Rescorla Expires January 6, 2020 [Page 8] Internet-Draft WebRTC Security July 2019 4.1.2.1. Dedicated Calling Services The first scenario we consider is a dedicated calling service. In this case, the user has a relationship with a calling site and repeatedly makes calls on it. It is likely that rather than having to give permission for each call that the user will want to give the calling service long-term access to the camera and microphone. This is a natural fit for a long-term consent mechanism (e.g., installing an app store "application" to indicate permission for the calling service.) A variant of the dedicated calling service is a gaming site (e.g., a poker site) which hosts a dedicated calling service to allow players to call each other. With any kind of service where the user may use the same service to talk to many different people, there is a question about whether the user can know who they are talking to. If I grant permission to calling service A to make calls on my behalf, then I am implicitly granting it permission to bug my computer whenever it wants. This suggests another consent model in which a site is authorized to make calls but only to certain target entities (identified via media-plane cryptographic mechanisms as described in Section 4.3.2 and especially Section 4.3.2.3.) Note that the question of consent here is related to but distinct from the question of peer identity: I might be willing to allow a calling site to in general initiate calls on my behalf but still have some calls via that site where I can be sure that the site is not listening in. 4.1.2.2. Calling the Site You're On Another simple scenario is calling the site you're actually visiting. The paradigmatic case here is the "click here to talk to a representative" windows that appear on many shopping sites. In this case, the user's expectation is that they are calling the site they're actually visiting. However, it is unlikely that they want to provide a general consent to such a site; just because I want some information on a car doesn't mean that I want the car manufacturer to be able to activate my microphone whenever they please. Thus, this suggests the need for a second consent mechanism where I only grant consent for the duration of a given call. As described in Section 3.1, great care must be taken in the design of this interface to avoid the users just clicking through. Note also that the user interface chrome, which is the representation through which the user interacts with the user agent itself, must clearly display elements showing that the call is continuing in order to avoid attacks where the calling site just leaves it up indefinitely but shows a Web UI that implies otherwise. Rescorla Expires January 6, 2020 [Page 9] Internet-Draft WebRTC Security July 2019 4.1.3. Origin-Based Security Now that we have described the calling scenarios, we can start to reason about the security requirements. As discussed in Section 3.2, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to origin. Specifically, a script from origin A MUST only be allowed to initiate communications (and hence to access camera and microphone) if the user has specifically authorized access for that origin. It is of course technically possible to have coarser-scoped permissions, but because the Web model is scoped to origin, this creates a difficult mismatch. Arguably, origin is not fine-grained enough. Consider the situation where Alice visits a site and authorizes it to make a single call. If consent is expressed solely in terms of origin, then at any future visit to that site (including one induced via mash-up or ad network), the site can bug Alice's computer, use the computer to place bogus calls, etc. While in principle Alice could grant and then revoke the privilege, in practice privileges accumulate; if we are concerned about this attack, something else is needed. There are a number of potential countermeasures to this sort of issue. Individual Consent Ask the user for permission for each call. Callee-oriented Consent Only allow calls to a given user. Cryptographic Consent Only allow calls to a given set of peer keying material or to a cryptographically established identity. Unfortunately, none of these approaches is satisfactory for all cases. As discussed above, individual consent puts the user's approval in the UI flow for every call. Not only does this quickly become annoying but it can train the user to simply click "OK", at which point the consent becomes useless. Thus, while it may be necessary to have individual consent in some case, this is not a suitable solution for (for instance) the calling service case. Where Rescorla Expires January 6, 2020 [Page 10] Internet-Draft WebRTC Security July 2019 necessary, in-flow user interfaces must be carefully designed to avoid the risk of the user blindly clicking through. The other two options are designed to restrict calls to a given target. Callee-oriented consent provided by the calling site would not work well because a malicious site can claim that the user is calling any user of his choice. One fix for this is to tie calls to a cryptographically-established identity. While not suitable for all cases, this approach may be useful for some. If we consider the case of advertising, it's not particularly convenient to require the advertiser to instantiate an iframe on the hosting site just to get permission; a more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly. We're still tying permissions to origin here, but to the media origin (and- or destination) rather than to the Web origin. [I-D.ietf-rtcweb-security-arch] describes mechanisms which facilitate this sort of consent. Another case where media-level cryptographic identity makes sense is when a user really does not trust the calling site. For instance, I might be worried that the calling service will attempt to bug my computer, but I also want to be able to conveniently call my friends. If consent is tied to particular communications endpoints, then my risk is limited. Naturally, it is somewhat challenging to design UI primitives which express this sort of policy. The problem becomes even more challenging in multi-user calling cases. 4.1.4. Security Properties of the Calling Page Origin-based security is intended to secure against web attackers. However, we must also consider the case of network attackers. Consider the case where I have granted permission to a calling service by an origin that has the HTTP scheme, e.g., http://calling- service.example.com. If I ever use my computer on an unsecured network (e.g., a hotspot or if my own home wireless network is insecure), and browse any HTTP site, then an attacker can bug my computer. The attack proceeds like this: 1. I connect to http://anything.example.org/. Note that this site is unaffiliated with the calling service. 2. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com 3. The attacker forges the response from http://calling- service.example.com/ to inject JS to initiate a call to himself. Rescorla Expires January 6, 2020 [Page 11] Internet-Draft WebRTC Security July 2019 Note that this attack does not depend on the media being insecure. Because the call is to the attacker, it is also encrypted to him. Moreover, it need not be executed immediately; the attacker can "infect" the origin semi-permanently (e.g., with a web worker or a popped-up window that is hidden under the main window.) and thus be able to bug me long after I have left the infected network. This risk is created by allowing calls at all from a page fetched over HTTP. Even if calls are only possible from HTTPS [RFC2818] sites, if those sites include active content (e.g., JavaScript) from an untrusted site, that JavaScript is executed in the security context of the page [finer-grained]. This could lead to compromise of a call even if the parent page is safe. Note: this issue is not restricted to PAGES which contain untrusted content. If any page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. 4.2. Communications Consent Verification As discussed in Section 3.3, allowing web applications unrestricted network access via the browser introduces the risk of using the browser as an attack platform against machines which would not otherwise be accessible to the malicious site, for instance because they are topologically restricted (e.g., behind a firewall or NAT). In order to prevent this form of attack as well as cross-protocol attacks it is important to require that the target of traffic explicitly consent to receiving the traffic in question. Until that consent has been verified for a given endpoint, traffic other than the consent handshake MUST NOT be sent to that endpoint. Note that consent verification is not sufficient to prevent overuse of network resources. Because WebRTC allows for a Web site to create data flows between two browser instances without user consent, it is possible for a malicious site to chew up a significant amount of a user's bandwidth without incurring significant costs to himself by setting up such a channel to another user. However, as a practical matter there are a large number of Web sites which can act as data sources, so an attacker can at least use downlink bandwidth with existing Web APIs. However, this potential DoS vector reinforces the need for adequate congestion control for WebRTC protocols to ensure that they play fair with other demands on the user's bandwidth. Rescorla Expires January 6, 2020 [Page 12] Internet-Draft WebRTC Security July 2019 4.2.1. ICE Verifying receiver consent requires some sort of explicit handshake, but conveniently we already need one in order to do NAT hole- punching. Interactive Connectivity Establishment (ICE) [RFC8445] includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender. It is important to remember here that the site initiating ICE is presumed malicious; in order for the handshake to be secure the receiving element MUST demonstrate receipt/knowledge of some value not available to the site (thus preventing the site from forging responses). In order to achieve this objective with ICE, the STUN transaction IDs must be generated by the browser and MUST NOT be made available to the initiating script, even via a diagnostic interface. Verifying receiver consent also requires verifying the receiver wants to receive traffic from a particular sender, and at this time; for example a malicious site may simply attempt ICE to known servers that are using ICE for other sessions. ICE provides this verification as well, by using the STUN credentials as a form of per-session shared secret. Those credentials are known to the Web application, but would need to also be known and used by the STUN-receiving element to be useful. There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it. Because ICE keepalives are indications, they will not work here. [RFC7675] describes the mechanism for providing consent freshness. 4.2.2. Masking Once consent is verified, there still is some concern about misinterpretation attacks as described by Huang et al.[huang-w2sp]. Where TCP is used the risk is substantial due to the potential presence of transparent proxies and therefore if TCP is to be used, then WebSockets style masking MUST be employed. Since DTLS (with the anti-chosen plaintext mechanisms required by TLS 1.1) does not allow the attacker to generate predictable ciphertext, there is no need for masking of protocols running over DTLS (e.g. SCTP over DTLS, UDP over DTLS, etc.). Note that in principle an attacker could exert some control over SRTP packets by using a combination of the WebAudio API and extremely tight timing control. The primary risk here seems to be carriage of SRTP over TURN TCP. However, as SRTP packets have an extremely characteristic packet header it seems unlikely that any but the most aggressive intermediaries would be confused into thinking that another application layer protocol was in use. Rescorla Expires January 6, 2020 [Page 13] Internet-Draft WebRTC Security July 2019 4.2.3. Backward Compatibility A requirement to use ICE limits compatibility with legacy non-ICE clients. It seems unsafe to completely remove the requirement for some check. All proposed checks have the common feature that the browser sends some message to the candidate traffic recipient and refuses to send other traffic until that message has been replied to. The message/reply pair must be generated in such a way that an attacker who controls the Web application cannot forge them, generally by having the message contain some secret value that must be incorporated (e.g., echoed, hashed into, etc.). Non-ICE candidates for this role (in cases where the legacy endpoint has a public address) include: o STUN checks without using ICE (i.e., the non-RTC-web endpoint sets up a STUN responder.) o Use of RTCP as an implicit reachability check. In the RTCP approach, the WebRTC endpoint is allowed to send a limited number of RTP packets prior to receiving consent. This allows a short window of attack. In addition, some legacy endpoints do not support RTCP, so this is a much more expensive solution for such endpoints, for which it would likely be easier to implement ICE. For these two reasons, an RTCP-based approach does not seem to address the security issue satisfactorily. In the STUN approach, the WebRTC endpoint is able to verify that the recipient is running some kind of STUN endpoint but unless the STUN responder is integrated with the ICE username/password establishment system, the WebRTC endpoint cannot verify that the recipient consents to this particular call. This may be an issue if existing STUN servers are operated at addresses that are not able to handle bandwidth-based attacks. Thus, this approach does not seem satisfactory either. If the systems are tightly integrated (i.e., the STUN endpoint responds with responses authenticated with ICE credentials) then this issue does not exist. However, such a design is very close to an ICE-Lite implementation (indeed, arguably is one). An intermediate approach would be to have a STUN extension that indicated that one was responding to WebRTC checks but not computing integrity checks based on the ICE credentials. This would allow the use of standalone STUN servers without the risk of confusing them with legacy STUN servers. If a non-ICE legacy solution is needed, then this is probably the best choice. Rescorla Expires January 6, 2020 [Page 14] Internet-Draft WebRTC Security July 2019 Once initial consent is verified, we also need to verify continuing consent, in order to avoid attacks where two people briefly share an IP (e.g., behind a NAT in an Internet cafe) and the attacker arranges for a large, unstoppable, traffic flow to the network and then leaves. The appropriate technologies here are fairly similar to those for initial consent, though are perhaps weaker since the threats are less severe. 4.2.4. IP Location Privacy Note that as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. The callee's server reflexive address reveals a lot of information about the callee's location. In order to avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. In addition, either side may wish to hide their location from the other side entirely by forcing all traffic through a TURN server. In ordinary operation, the site learns the browser's IP address, though it may be hidden via mechanisms like Tor [http://www.torproject.org] or a VPN. However, because sites can cause the browser to provide IP addresses, this provides a mechanism for sites to learn about the user's network environment even if the user is behind a VPN that masks their IP address. Implementations may wish to provide settings which suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems such as Tor. See [I-D.ietf-rtcweb-ip-handling] for additional information. 4.3. Communications Security Finally, we consider a problem familiar from the SIP world: communications security. For obvious reasons, it MUST be possible for the communicating parties to establish a channel which is secure against both message recovery and message modification. (See [RFC5479] for more details.) This service must be provided for both data and voice/video. Ideally the same security mechanisms would be used for both types of content. Technology for providing this service (for instance, SRTP [RFC3711], DTLS [RFC6347] and DTLS-SRTP [RFC5763]) is well understood. However, we must examine this technology in the WebRTC context, where the threat model is somewhat different. In general, it is important to understand that unlike a conventional SIP proxy, the calling service (i.e., the Web server) controls not only the channel between the communicating endpoints but also the application running on the user's browser. While in principle it is possible for the browser to cut the calling service out of the loop Rescorla Expires January 6, 2020 [Page 15] Internet-Draft WebRTC Security July 2019 and directly present trusted information (and perhaps get consent), practice in modern browsers is to avoid this whenever possible. "In- flow" modal dialogs which require the user to consent to specific actions are particularly disfavored as human factors research indicates that unless they are made extremely invasive, users simply agree to them without actually consciously giving consent. [abarth-rtcweb]. Thus, nearly all the UI will necessarily be rendered by the browser but under control of the calling service. This likely includes the peer's identity information, which, after all, is only meaningful in the context of some calling service. This limitation does not mean that preventing attack by the calling service is completely hopeless. However, we need to distinguish between two classes of attack: Retrospective compromise of calling service. The calling service is non-malicious during a call but subsequently is compromised and wishes to attack an older call (often called a "passive attack") During-call attack by calling service. The calling service is compromised during the call it wishes to attack (often called an "active attack"). Providing security against the former type of attack is practical using the techniques discussed in Section 4.3.1. However, it is extremely difficult to prevent a trusted but malicious calling service from actively attacking a user's calls, either by mounting a Man-in-the-Middle (MITM) attack or by diverting them entirely. (Note that this attack applies equally to a network attacker if communications to the calling service are not secured.) We discuss some potential approaches and why they are likely to be impractical in Section 4.3.2. 4.3.1. Protecting Against Retrospective Compromise In a retrospective attack, the calling service was uncompromised during the call, but that an attacker subsequently wants to recover the content of the call. We assume that the attacker has access to the protected media stream as well as having full control of the calling service. If the calling service has access to the traffic keying material (as in SDES [RFC4568]), then retrospective attack is trivial. This form Rescorla Expires January 6, 2020 [Page 16] Internet-Draft WebRTC Security July 2019 of attack is particularly serious in the Web context because it is standard practice in Web services to run extensive logging and monitoring. Thus, it is highly likely that if the traffic key is part of any HTTP request it will be logged somewhere and thus subject to subsequent compromise. It is this consideration that makes an automatic, public key-based key exchange mechanism imperative for WebRTC (this is a good idea for any communications security system) and this mechanism SHOULD provide perfect forward secrecy (PFS). The signaling channel/calling service can be used to authenticate this mechanism. In addition, if end-to-end keying is in used, the system MUST NOT provide any APIs to extract either long-term keying material or to directly access any stored traffic keys. Otherwise, an attacker who subsequently compromised the calling service might be able to use those APIs to recover the traffic keys and thus compromise the traffic. 4.3.2. Protecting Against During-Call Attack Protecting against attacks during a call is a more difficult proposition. Even if the calling service cannot directly access keying material (as recommended in the previous section), it can simply mount a man-in-the-middle attack on the connection, telling Alice that she is calling Bob and Bob that he is calling Alice, while in fact the calling service is acting as a calling bridge and capturing all the traffic. Protecting against this form of attack requires positive authentication of the remote endpoint such as explicit out-of-band key verification (e.g., by a fingerprint) or a third-party identity service as described in [I-D.ietf-rtcweb-security-arch]. 4.3.2.1. Key Continuity One natural approach is to use "key continuity". While a malicious calling service can present any identity it chooses to the user, it cannot produce a private key that maps to a given public key. Thus, it is possible for the browser to note a given user's public key and generate an alarm whenever that user's key changes. SSH [RFC4251] uses a similar technique. (Note that the need to avoid explicit user consent on every call precludes the browser requiring an immediate manual check of the peer's key). Unfortunately, this sort of key continuity mechanism is far less useful in the WebRTC context. First, much of the virtue of WebRTC (and any Web application) is that it is not bound to particular piece of client software. Thus, it will be not only possible but routine for a user to use multiple browsers on different computers which will Rescorla Expires January 6, 2020 [Page 17] Internet-Draft WebRTC Security July 2019 of course have different keying material (SACRED [RFC3760] notwithstanding.) Thus, users will frequently be alerted to key mismatches which are in fact completely legitimate, with the result that they are trained to simply click through them. As it is known that users routinely will click through far more dire warnings [cranor-wolf], it seems extremely unlikely that any key continuity mechanism will be effective rather than simply annoying. Moreover, it is trivial to bypass even this kind of mechanism. Recall that unlike the case of SSH, the browser never directly gets the peer's identity from the user. Rather, it is provided by the calling service. Even enabling a mechanism of this type would require an API to allow the calling service to tell the browser "this is a call to user X". All the calling service needs to do to avoid triggering a key continuity warning is to tell the browser that "this is a call to user Y" where Y is confusable with X. Even if the user actually checks the other side's name (which all available evidence indicates is unlikely), this would require (a) the browser to use the trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. 4.3.2.2. Short Authentication Strings ZRTP [RFC6189] uses a "short authentication string" (SAS) which is derived from the key agreement protocol. This SAS is designed to be compared by the users (e.g., read aloud over the voice channel or transmitted via an out of band channel) and if confirmed by both sides precludes MITM attack. The intention is that the SAS is used once and then key continuity (though a different mechanism from that discussed above) is used thereafter. Unfortunately, the SAS does not offer a practical solution to the problem of a compromised calling service. "Voice conversion" systems, which modify voice from one speaker to make it sound like another, are an active area of research. These systems are already good enough to fool both automatic recognition systems [farus-conversion] and humans [kain-conversion] in many cases, and are of course likely to improve in future, especially in an environment where the user just wants to get on with the phone call. Thus, even if SAS is effective today, it is likely not to be so for much longer. Additionally, it is unclear that users will actually use an SAS. As discussed above, the browser UI constraints preclude requiring the SAS exchange prior to completing the call and so it must be voluntary; at most the browser will provide some UI indicator that the SAS has not yet been checked. However, it is well-known that Rescorla Expires January 6, 2020 [Page 18] Internet-Draft WebRTC Security July 2019 when faced with optional security mechanisms, many users simply ignore them [whitten-johnny]. Once users have checked the SAS once, key continuity is required to avoid them needing to check it on every call. However, this is problematic for reasons indicated in Section 4.3.2.1. In principle it is of course possible to render a different UI element to indicate that calls are using an unauthenticated set of keying material (recall that the attacker can just present a slightly different name so that the attack shows the same UI as a call to a new device or to someone you haven't called before) but as a practical matter, users simply ignore such indicators even in the rather more dire case of mixed content warnings. 4.3.2.3. Third Party Identity The conventional approach to providing communications identity has of course been to have some third party identity system (e.g., PKI) to authenticate the endpoints. Such mechanisms have proven to be too cumbersome for use by typical users (and nearly too cumbersome for administrators). However, a new generation of Web-based identity providers (BrowserID, Federated Google Login, Facebook Connect, OAuth [RFC6749], OpenID [OpenID], WebFinger [RFC7033]), has recently been developed and use Web technologies to provide lightweight (from the user's perspective) third-party authenticated transactions. It is possible to use systems of this type to authenticate WebRTC calls, linking them to existing user notions of identity (e.g., Facebook adjacencies). Specifically, the third-party identity system is used to bind the user's identity to cryptographic keying material which is then used to authenticate the calling endpoints. Calls which are authenticated in this fashion are naturally resistant even to active MITM attack by the calling site. Note that there is one special case in which PKI-style certificates do provide a practical solution: calls from end-users to large sites. For instance, if you are making a call to Amazon.com, then Amazon can easily get a certificate to authenticate their media traffic, just as they get one to authenticate their Web traffic. This does not provide additional security value in cases in which the calling site and the media peer are one in the same, but might be useful in cases in which third parties (e.g., ad networks or retailers) arrange for calls but do not participate in them. 4.3.2.4. Page Access to Media Identifying the identity of the far media endpoint is a necessary but not sufficient condition for providing media security. In WebRTC, media flows are rendered into HTML5 MediaStreams which can be Rescorla Expires January 6, 2020 [Page 19] Internet-Draft WebRTC Security July 2019 manipulated by the calling site. Obviously, if the site can modify or view the media, then the user is not getting the level of assurance they would expect from being able to authenticate their peer. In many cases, this is acceptable because the user values site-based special effects over complete security from the site. However, there are also cases where users wish to know that the site cannot interfere. In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams. This verification must be possible both from the local side and the remote side. I.e., users must be able to verify that the person called has engaged a secure media mode (see Section 4.3.3). In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections. It should be noted that the use of this secure media mode is left to the discretion of the site. When such a mode is engaged, the browser will need to provide indicia to the user that the associated media has been authenticated as coming from the identified user. This allows WebRTC services that wish to claim end-to-end security to do so in a way that can be easily verified by the user. This model requires that the remote party's browser be included in the TCB, as described in Section 3. 4.3.3. Malicious Peers One class of attack that we do not generally try to prevent is malicious peers. For instance, no matter what confidentiality measures you employ the person you are talking to might record the call and publish it on the Internet. Similarly, we do not attempt to prevent them from using voice or video processing technology from hiding or changing their appearance. While technologies (DRM, etc.) do exist to attempt to address these issues, they are generally not compatible with open systems and WebRTC does not address them. Similarly, we make no attempt to prevent prank calling or other unwanted calls. In general, this is in the scope of the calling site, though because WebRTC does offer some forms of strong authentication, that may be useful as part of a defense against such attacks. 4.4. Privacy Considerations Rescorla Expires January 6, 2020 [Page 20] Internet-Draft WebRTC Security July 2019 4.4.1. Correlation of Anonymous Calls While persistent endpoint identifiers can be a useful security feature (see Section 4.3.2.1) they can also represent a privacy threat in settings where the user wishes to be anonymous. WebRTC provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to [RFC6222] rather than the privacy preserving mode of [RFC7022]). In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies). Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers. In addition, IP addresses can be a source of call linkage [I-D.ietf-rtcweb-ip-handling]. 4.4.2. Browser Fingerprinting Any new set of API features adds a risk of browser fingerprinting, and WebRTC is no exception. Specifically, sites can use the presence or absence of specific devices as a browser fingerprint. In general, the API needs to be balanced between functionality and the incremental fingerprint risk. See [Fingerprinting]. 5. Security Considerations This entire document is about security. 6. Acknowledgements Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman, Martin Thomson, Magnus Westerlund. 7. IANA Considerations There are no IANA considerations. 8. Changes Since -04 o Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG o Removed discussion of the IFRAMEd advertisement case, since we decided not to treat it specially. o Added a privacy section considerations section. Rescorla Expires January 6, 2020 [Page 21] Internet-Draft WebRTC Security July 2019 o Significant edits to the SAS section to reflect Alan Johnston's comments. o Added some discussion if IP location privacy and Tor. o Updated the "communications consent" section to reflrect draft- ietf. o Added a section about "malicious peers". o Added a section describing screen sharing threats. o Assorted editorial changes. 9. References 9.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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [abarth-rtcweb] Barth, A., "Prompting the user is security failure", RTC- Web Workshop, September 2010. [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", January 2014. [cranor-wolf] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", Proceedings of the 18th USENIX Security Symposium, 2009, August 2009. [farus-conversion] Farrus, M., Erro, D., and J. Hernando, "Speaker Recognition Robustness to Voice Conversion", January 2008. Rescorla Expires January 6, 2020 [Page 22] Internet-Draft WebRTC Security July 2019 [finer-grained] Barth, A. and C. Jackson, "Beware of Finer-Grained Origins", W2SP, 2008, July 2008. [Fingerprinting] "Fingerprinting Guidance for Web Specification Authors (Draft)", November 2013. [huang-w2sp] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", W2SP, 2011, May 2011. [I-D.ietf-rtcweb-ip-handling] Uberti, J., "WebRTC IP Address Handling Requirements", draft-ietf-rtcweb-ip-handling-12 (work in progress), July 2019. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-19 (work in progress), November 2017. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-18 (work in progress), February 2019. [kain-conversion] Kain, A. and M. Macon, "Design and Evaluation of a Voice Conversion Algorithm based on Spectral Envelope Mapping and Residual Prediction", Proceedings of ICASSP, May 2001, May 2001. [OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . Rescorla Expires January 6, 2020 [Page 23] Internet-Draft WebRTC Security July 2019 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC5479] Wing, D., Ed., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, DOI 10.17487/RFC5479, April 2009, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, . [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Rescorla Expires January 6, 2020 [Page 24] Internet-Draft WebRTC Security July 2019 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, . [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [SWF] "SWF File Format Specification Version 19", April 2013. [whitten-johnny] Whitten, A. and J. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", Proceedings of the 8th USENIX Security Symposium, 1999, August 1999. [XmlHttpRequest] van Kesteren, A., "XMLHttpRequesti Level 2", January 2012. Author's Address Rescorla Expires January 6, 2020 [Page 25] Internet-Draft WebRTC Security July 2019 Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 Email: ekr@rtfm.com Rescorla Expires January 6, 2020 [Page 26] ./draft-ietf-rtcweb-security-arch-20.txt0000644000764400076440000031012313515346343017427 0ustar iustyiusty RTCWEB E. Rescorla Internet-Draft RTFM, Inc. Intended status: Standards Track July 21, 2019 Expires: January 22, 2020 WebRTC Security Architecture draft-ietf-rtcweb-security-arch-20 Abstract This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 22, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Rescorla Expires January 22, 2020 [Page 1] Internet-Draft WebRTC Sec. Arch. July 2019 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Authenticated Entities . . . . . . . . . . . . . . . . . 5 3.2. Unauthenticated Entities . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Initial Signaling . . . . . . . . . . . . . . . . . . . . 8 4.2. Media Consent Verification . . . . . . . . . . . . . . . 10 4.3. DTLS Handshake . . . . . . . . . . . . . . . . . . . . . 11 4.4. Communications and Consent Freshness . . . . . . . . . . 11 5. SDP Identity Attribute . . . . . . . . . . . . . . . . . . . 12 5.1. Offer/Answer Considerations . . . . . . . . . . . . . . . 13 5.1.1. Generating the Initial SDP Offer . . . . . . . . . . 13 5.1.2. Generating of SDP Answer . . . . . . . . . . . . . . 14 5.1.3. Processing an SDP Offer or Answer . . . . . . . . . . 14 5.1.4. Modifying the Session . . . . . . . . . . . . . . . . 14 6. Detailed Technical Description . . . . . . . . . . . . . . . 14 6.1. Origin and Web Security Issues . . . . . . . . . . . . . 14 6.2. Device Permissions Model . . . . . . . . . . . . . . . . 15 6.3. Communications Consent . . . . . . . . . . . . . . . . . 17 6.4. IP Location Privacy . . . . . . . . . . . . . . . . . . . 17 6.5. Communications Security . . . . . . . . . . . . . . . . . 18 7. Web-Based Peer Authentication . . . . . . . . . . . . . . . . 20 7.1. Trust Relationships: IdPs, APs, and RPs . . . . . . . . . 21 7.2. Overview of Operation . . . . . . . . . . . . . . . . . . 23 7.3. Items for Standardization . . . . . . . . . . . . . . . . 24 7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions . . . . . . . . . . . . . . . . . . . . . . 24 7.4.1. Carrying Identity Assertions . . . . . . . . . . . . 25 7.5. Determining the IdP URI . . . . . . . . . . . . . . . . . 26 7.5.1. Authenticating Party . . . . . . . . . . . . . . . . 27 7.5.2. Relying Party . . . . . . . . . . . . . . . . . . . . 28 7.6. Requesting Assertions . . . . . . . . . . . . . . . . . . 28 7.7. Managing User Login . . . . . . . . . . . . . . . . . . . 29 Rescorla Expires January 22, 2020 [Page 2] Internet-Draft WebRTC Sec. Arch. July 2019 8. Verifying Assertions . . . . . . . . . . . . . . . . . . . . 29 8.1. Identity Formats . . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9.1. Communications Security . . . . . . . . . . . . . . . . . 31 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33 9.4. IdP Authentication Mechanism . . . . . . . . . . . . . . 34 9.4.1. PeerConnection Origin Check . . . . . . . . . . . . . 34 9.4.2. IdP Well-known URI . . . . . . . . . . . . . . . . . 34 9.4.3. Privacy of IdP-generated identities and the hosting site . . . . . . . . . . . . . . . . . . . . . . . . 35 9.4.4. Security of Third-Party IdPs . . . . . . . . . . . . 35 9.4.4.1. Confusable Characters . . . . . . . . . . . . . . 35 9.4.5. Web Security Feature Interactions . . . . . . . . . . 35 9.4.5.1. Popup Blocking . . . . . . . . . . . . . . . . . 36 9.4.5.2. Third Party Cookies . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 12. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Changes since -15 . . . . . . . . . . . . . . . . . . . 37 12.2. Changes since -11 . . . . . . . . . . . . . . . . . . . 37 12.3. Changes since -10 . . . . . . . . . . . . . . . . . . . 37 12.4. Changes since -06 . . . . . . . . . . . . . . . . . . . 37 12.5. Changes since -05 . . . . . . . . . . . . . . . . . . . 38 12.6. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 12.7. Changes since -03 . . . . . . . . . . . . . . . . . . . 38 12.8. Changes since -02 . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . 42 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The Real-Time Communications on the Web (RTCWEB) working group standardized protocols for real-time communications between Web browsers, generally called "WebRTC" [I-D.ietf-rtcweb-overview]. The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems, (e.g., SIP-based [RFC3261] soft phones) WebRTC communications are directly controlled by some Web server, via a JavaScript (JS) API as shown in Figure 1. Rescorla Expires January 22, 2020 [Page 3] Internet-Draft WebRTC Sec. Arch. July 2019 +----------------+ | | | Web Server | | | +----------------+ ^ ^ / \ HTTP / \ HTTP / \ / \ v v JS API JS API +-----------+ +-----------+ | | Media | | | Browser |<---------->| Browser | | | | | +-----------+ +-----------+ Figure 1: A simple WebRTC system A more complicated system might allow for interdomain calling, as shown in Figure 2. The protocol to be used between the domains is not standardized by WebRTC, but given the installed base and the form of the WebRTC API is likely to be something SDP-based like SIP or something like Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. +--------------+ +--------------+ | | SIP,XMPP,...| | | Web Server |<----------->| Web Server | | | | | +--------------+ +--------------+ ^ ^ | | HTTP | | HTTP | | v v JS API JS API +-----------+ +-----------+ | | Media | | | Browser |<---------------->| Browser | | | | | +-----------+ +-----------+ Figure 2: A multidomain WebRTC system This system presents a number of new security challenges, which are analyzed in [I-D.ietf-rtcweb-security]. This document describes a Rescorla Expires January 22, 2020 [Page 4] Internet-Draft WebRTC Sec. Arch. July 2019 security architecture for WebRTC which addresses the threats and requirements described in that document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Trust Model The basic assumption of this architecture is that network resources exist in a hierarchy of trust, rooted in the browser, which serves as the user's Trusted Computing Base (TCB). Any security property which the user wishes to have enforced must be ultimately guaranteed by the browser (or transitively by some property the browser verifies). Conversely, if the browser is compromised, then no security guarantees are possible. Note that there are cases (e.g., Internet kiosks) where the user can't really trust the browser that much. In these cases, the level of security provided is limited by how much they trust the browser. Optimally, we would not rely on trust in any entities other than the browser. However, this is unfortunately not possible if we wish to have a functional system. Other network elements fall into two categories: those which can be authenticated by the browser and thus can be granted permissions to access sensitive resources, and those which cannot be authenticated and thus are untrusted. 3.1. Authenticated Entities There are two major classes of authenticated entities in the system: o Calling services: Web sites whose origin we can verify (optimally via HTTPS, but in some cases because we are on a topologically restricted network, such as behind a firewall, and can infer authentication from firewall behavior). o Other users: WebRTC peers whose origin we can verify cryptographically (optimally via DTLS-SRTP). Note that merely being authenticated does not make these entities trusted. For instance, just because we can verify that https://www.example.org/ is owned by Dr. Evil does not mean that we can trust Dr. Evil to access our camera and microphone. However, it gives the user an opportunity to determine whether he wishes to trust Rescorla Expires January 22, 2020 [Page 5] Internet-Draft WebRTC Sec. Arch. July 2019 Dr. Evil or not; after all, if he desires to contact Dr. Evil (perhaps to arrange for ransom payment), it's safe to temporarily give him access to the camera and microphone for the purpose of the call, but he doesn't want Dr. Evil to be able to access his camera and microphone other than during the call. The point here is that we must first identify other elements before we can determine whether and how much to trust them. Additionally, sometimes we need to identify the communicating peer before we know what policies to apply. 3.2. Unauthenticated Entities Other than the above entities, we are not generally able to identify other network elements, thus we cannot trust them. This does not mean that it is not possible to have any interaction with them, but it means that we must assume that they will behave maliciously and design a system which is secure even if they do so. 4. Overview This section describes a typical WebRTC session and shows how the various security elements interact and what guarantees are provided to the user. The example in this section is a "best case" scenario in which we provide the maximal amount of user authentication and media privacy with the minimal level of trust in the calling service. Simpler versions with lower levels of security are also possible and are noted in the text where applicable. It's also important to recognize the tension between security (or performance) and privacy. The example shown here is aimed towards settings where we are more concerned about secure calling than about privacy, but as we shall see, there are settings where one might wish to make different tradeoffs--this architecture is still compatible with those settings. For the purposes of this example, we assume the topology shown in the figures below. This topology is derived from the topology shown in Figure 1, but separates Alice and Bob's identities from the process of signaling. Specifically, Alice and Bob have relationships with some Identity Provider (IdP) that supports a protocol (such as OpenID Connect) that can be used to demonstrate their identity to other parties. For instance, Alice might have an account with a social network which she can then use to authenticate to other web sites without explicitly having an account with those sites; this is a fairly conventional pattern on the Web. Section 7.1 provides an overview of Identity Providers and the relevant terminology. Alice and Bob might have relationships with different IdPs as well. This separation of identity provision and signaling isn't particularly important in "closed world" cases where Alice and Bob Rescorla Expires January 22, 2020 [Page 6] Internet-Draft WebRTC Sec. Arch. July 2019 are users on the same social network and have identities based on that domain (Figure 3). However, there are important settings where that is not the case, such as federation (calls from one domain to another; Figure 4) and calling on untrusted sites, such as where two users who have a relationship via a given social network want to call each other on another, untrusted, site, such as a poker site. Note that the servers themselves are also authenticated by an external identity service, the SSL/TLS certificate infrastructure (not shown). As is conventional in the Web, all identities are ultimately rooted in that system. For instance, when an IdP makes an identity assertion, the Relying Party consuming that assertion is able to verify because it is able to connect to the IdP via HTTPS. +----------------+ | | | Signaling | | Server | | | +----------------+ ^ ^ / \ HTTPS / \ HTTPS / \ / \ v v JS API JS API +-----------+ +-----------+ | | Media | | Alice | Browser |<---------->| Browser | Bob | | (DTLS+SRTP)| | +-----------+ +-----------+ ^ ^--+ +--^ ^ | | | | v | | v +-----------+ | | +-----------+ | |<--------+ | | | IdP1 | | | IdP2 | | | +------->| | +-----------+ +-----------+ Figure 3: A call with IdP-based identity Figure 4 shows essentially the same calling scenario but with a call between two separate domains (i.e., a federated case), as in Figure 2. As mentioned above, the domains communicate by some unspecified protocol and providing separate signaling and identity Rescorla Expires January 22, 2020 [Page 7] Internet-Draft WebRTC Sec. Arch. July 2019 allows for calls to be authenticated regardless of the details of the inter-domain protocol. +----------------+ Unspecified +----------------+ | | protocol | | | Signaling |<----------------->| Signaling | | Server | (SIP, XMPP, ...) | Server | | | | | +----------------+ +----------------+ ^ ^ | | HTTPS | | HTTPS | | | | v v JS API JS API +-----------+ +-----------+ | | Media | | Alice | Browser |<--------------------------->| Browser | Bob | | DTLS+SRTP | | +-----------+ +-----------+ ^ ^--+ +--^ ^ | | | | v | | v +-----------+ | | +-----------+ | |<-------------------------+ | | | IdP1 | | | IdP2 | | | +------------------------>| | +-----------+ +-----------+ Figure 4: A federated call with IdP-based identity 4.1. Initial Signaling For simplicity, assume the topology in Figure 3. Alice and Bob are both users of a common calling service; they both have approved the calling service to make calls (we defer the discussion of device access permissions until later). They are both connected to the calling service via HTTPS and so know the origin with some level of confidence. They also have accounts with some identity provider. This sort of identity service is becoming increasingly common in the Web environment (with technologies such as Federated Google Login, Facebook Connect, OAuth, OpenID, WebFinger), and is often provided as a side effect service of a user's ordinary accounts with some service. In this example, we show Alice and Bob using a separate identity service, though the identity service may be the same entity as the calling service or there may be no identity service at all. Rescorla Expires January 22, 2020 [Page 8] Internet-Draft WebRTC Sec. Arch. July 2019 Alice is logged onto the calling service and decides to call Bob. She can see from the calling service that he is online and the calling service presents a JS UI in the form of a button next to Bob's name which says "Call". Alice clicks the button, which initiates a JS callback that instantiates a PeerConnection object. This does not require a security check: JS from any origin is allowed to get this far. Once the PeerConnection is created, the calling service JS needs to set up some media. Because this is an audio/video call, it creates a MediaStream with two MediaStreamTracks, one connected to an audio input and one connected to a video input. At this point the first security check is required: untrusted origins are not allowed to access the camera and microphone, so the browser prompts Alice for permission. In the current W3C API, once some streams have been added, Alice's browser + JS generates a signaling message [I-D.ietf-rtcweb-jsep] containing: o Media channel information o Interactive Connectivity Establishment (ICE) [RFC8445] candidates o A fingerprint attribute binding the communication to a key pair [RFC5763]. Note that this key may simply be ephemerally generated for this call or specific to this domain, and Alice may have a large number of such keys. Prior to sending out the signaling message, the PeerConnection code contacts the identity service and obtains an assertion binding Alice's identity to her fingerprint. The exact details depend on the identity service (though as discussed in Section 7 PeerConnection can be agnostic to them), but for now it's easiest to think of as an OAuth token. The assertion may bind other information to the identity besides the fingerprint, but at minimum it needs to bind the fingerprint. This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455], over TLS [RFC5246]. The signaling server processes the message from Alice's browser, determines that this is a call to Bob and sends a signaling message to Bob's browser (again, the format is currently undefined). The JS on Bob's browser processes it, and alerts Bob to the incoming call and to Alice's identity. In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no specific knowledge of the IdP) to verify the assertion. It is also Rescorla Expires January 22, 2020 [Page 9] Internet-Draft WebRTC Sec. Arch. July 2019 possible to have IdPs with which the browser has a specific trustrelationship, as described in Section 7.1. This allows the browser to display a trusted element in the browser chrome indicating that a call is coming in from Alice. If Alice is in Bob's address book, then this interface might also include her real name, a picture, etc. The calling site will also provide some user interface element (e.g., a button) to allow Bob to answer the call, though this is most likely not part of the trusted UI. If Bob agrees a PeerConnection is instantiated with the message from Alice's side. Then, a similar process occurs as on Alice's browser: Bob's browser prompts him for device permission, the media streams are created, and a return signaling message containing media information, ICE candidates, and a fingerprint is sent back to Alice via the signaling service. If Bob has a relationship with an IdP, the message will also come with an identity assertion. At this point, Alice and Bob each know that the other party wants to have a secure call with them. Based purely on the interface provided by the signaling server, they know that the signaling server claims that the call is from Alice to Bob. This level of security is provided merely by having the fingerprint in the message and having that message received securely from the signaling server. Because the far end sent an identity assertion along with their message, they know that this is verifiable from the IdP as well. Note that if the call is federated, as shown in Figure 4 then Alice is able to verify Bob's identity in a way that is not mediated by either her signaling server or Bob's. Rather, she verifies it directly with Bob's IdP. Of course, the call works perfectly well if either Alice or Bob doesn't have a relationship with an IdP; they just get a lower level of assurance. I.e., they simply have whatever information their calling site claims about the caller/callee's identity. Moreover, Alice might wish to make an anonymous call through an anonymous calling site, in which case she would of course just not provide any identity assertion and the calling site would mask her identity from Bob. 4.2. Media Consent Verification As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media consent verification is provided via ICE. Thus, Alice and Bob perform ICE checks with each other. At the completion of these checks, they are ready to send non-ICE data. At this point, Alice knows that (a) Bob (assuming he is verified via his IdP) or someone else who the signaling service is claiming is Bob is willing to exchange traffic with her and (b) that either Bob is at Rescorla Expires January 22, 2020 [Page 10] Internet-Draft WebRTC Sec. Arch. July 2019 the IP address which she has verified via ICE or there is an attacker who is on-path to that IP address detouring the traffic. Note that it is not possible for an attacker who is on-path between Alice and Bob but not attached to the signaling service to spoof these checks because they do not have the ICE credentials. Bob has the same security guarantees with respect to Alice. 4.3. DTLS Handshake Once the requisite ICE checks have completed, Alice and Bob can set up a secure channel or channels. This is performed via DTLS [RFC6347] and DTLS-SRTP [RFC5763] keying for SRTP [RFC3711] for the media channel and SCTP over DTLS [RFC8261] for data channels. Specifically, Alice and Bob perform a DTLS handshake on every component which has been established by ICE. The total number of channels depends on the amount of muxing; in the most likely case we are using both RTP/RTCP mux and muxing multiple media streams on the same channel, in which case there is only one DTLS handshake. Once the DTLS handshake has completed, the keys are exported [RFC5705] and used to key SRTP for the media channels. At this point, Alice and Bob know that they share a set of secure data and/or media channels with keys which are not known to any third-party attacker. If Alice and Bob authenticated via their IdPs, then they also know that the signaling service is not mounting a man- in-the-middle attack on their traffic. Even if they do not use an IdP, as long as they have minimal trust in the signaling service not to perform a man-in-the-middle attack, they know that their communications are secure against the signaling service as well (i.e., that the signaling service cannot mount a passive attack on the communications). 4.4. Communications and Consent Freshness From a security perspective, everything from here on in is a little anticlimactic: Alice and Bob exchange data protected by the keys negotiated by DTLS. Because of the security guarantees discussed in the previous sections, they know that the communications are encrypted and authenticated. The one remaining security property we need to establish is "consent freshness", i.e., allowing Alice to verify that Bob is still prepared to receive her communications so that Alice does not continue to send large traffic volumes to entities which went abruptly offline. ICE specifies periodic STUN keepalives but only if media is not flowing. Because the consent issue is more difficult here, we require WebRTC implementations to periodically send keepalives. As described in Section 5.3, these keepalives MUST be based on the consent freshness Rescorla Expires January 22, 2020 [Page 11] Internet-Draft WebRTC Sec. Arch. July 2019 mechanism specified in [RFC7675]. If a keepalive fails and no new ICE channels can be established, then the session is terminated. 5. SDP Identity Attribute The SDP 'identity' attribute is a session-level attribute that is used by an endpoint to convey its identity assertion to its peer. The identity assertion value is encoded as Base-64, as described in Section 4 of [RFC4648]. The procedures in this section are based on the assumption that the identity assertion of an endpoint is bound to the fingerprints of the endpoint. This does not preclude the definition of alternative means of binding an assertion to the endpoint, but such means are outside the scope of this specification. The semantics of multiple 'identity' attributes within an offer or answer are undefined. Implementations SHOULD only include a single 'identity' attribute in an offer or answer and relying parties MAY elect to ignore all but the first 'identity' attribute. Name: identity Value: identity-assertion Usage Level: session Charset Dependent: no Default Value: N/A Name: identity Rescorla Expires January 22, 2020 [Page 12] Internet-Draft WebRTC Sec. Arch. July 2019 Syntax: identity-assertion = identity-assertion-value *(SP identity-extension) identity-assertion-value = base64 identity-extension = extension-name [ "=" extension-value ] extension-name = token extension-value = 1*(%x01-09 / %x0b-0c / %x0e-3a / %x3c-ff) ; byte-string from [RFC4566] Example: a=identity:\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\ aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line, the carriage return that follows, and whitespace shall be ignored. This specification does not define any extensions for the attribute. The identity-assertion value is a JSON [RFC8259] encoded string. The JSON object contains two keys: "assertion" and "idp". The "assertion" key value contains an opaque string that is consumed by the IdP. The "idp" key value contains a dictionary with one or two further values that identify the IdP. See Section 7.6 for more details. 5.1. Offer/Answer Considerations This section defines the SDP Offer/Answer [RFC3264] considerations for the SDP 'identity' attribute. Within this section, 'initial offer' refers to the first offer in the SDP session that contains an SDP "identity" attribute. 5.1.1. Generating the Initial SDP Offer When an offerer sends an offer, in order to provide its identity assertion to the peer, it includes an 'identity' attribute in the offer. In addition, the offerer includes one or more SDP Rescorla Expires January 22, 2020 [Page 13] Internet-Draft WebRTC Sec. Arch. July 2019 'fingerprint' attributes. The 'identity' attribute MUST be bound to all the 'fingerprint' attributes in the session description. 5.1.2. Generating of SDP Answer If the answerer elects to include an 'identity' attribute, it follows the same steps as those in Section 5.1.1. The answerer can choose to include or omit an 'identity' attribute independently, regardless of whether the offerer did so. 5.1.3. Processing an SDP Offer or Answer When an endpoint receives an offer or answer that contains an 'identity' attribute, the answerer can use the the attribute information to contact the IdP and verify the identity of the peer. If the identity requires a third-party IdP as described in Section 7.1 then that IdP will need to have been specifically configured. If the identity verification fails, the answerer MUST discard the offer or answer as malformed. 5.1.4. Modifying the Session When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute. In this case, the established identity MUST be applied to existing DTLS connections as well as new connections established using one of those fingerprints. Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. If a new identity attribute is received, then the receiver MUST apply that identity to all existing connections. If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all. Because a change in fingerprints also causes a new DTLS connection to be established, the receiver MUST discard all previously established identities. 6. Detailed Technical Description 6.1. Origin and Web Security Issues The basic unit of permissions for WebRTC is the origin [RFC6454]. Because the security of the origin depends on being able to authenticate content from that origin, the origin can only be securely established if data is transferred over HTTPS [RFC2818]. Thus, clients MUST treat HTTP and HTTPS origins as different permissions domains. Note: this follows directly from the origin security model and is stated here merely for clarity. Rescorla Expires January 22, 2020 [Page 14] Internet-Draft WebRTC Sec. Arch. July 2019 Many web browsers currently forbid by default any active mixed content on HTTPS pages. That is, when JavaScript is loaded from an HTTP origin onto an HTTPS page, an error is displayed and the HTTP content is not executed unless the user overrides the error. Any browser which enforces such a policy will also not permit access to WebRTC functionality from mixed content pages (because they never display mixed content). Browsers which allow active mixed content MUST nevertheless disable WebRTC functionality in mixed content settings. Note that it is possible for a page which was not mixed content to become mixed content during the duration of the call. The major risk here is that the newly arrived insecure JS might redirect media to a location controlled by the attacker. Implementations MUST either choose to terminate the call or display a warning at that point. Also note that the security architecture depends on the keying material not being available to move between origins. But, it is assumed that the identity assertion can be passed to anyone that the page cares to. 6.2. Device Permissions Model Implementations MUST obtain explicit user consent prior to providing access to the camera and/or microphone. Implementations MUST at minimum support the following two permissions models for HTTPS origins. o Requests for one-time camera/microphone access. o Requests for permanent access. Because HTTP origins cannot be securely established against network attackers, implementations MUST refuse all permissions grants for HTTP origins. In addition, they SHOULD support requests for access that promise that media from this grant will be sent to a single communicating peer (obviously there could be other requests for other peers), eE.g., "Call customerservice@example.org". The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. Note that it is unlikely that browsers would have X.509 certificates, but servers might. Browsers servicing such requests SHOULD clearly indicate that identity to the user when asking for permission. The idea behind this type of permissions is that a user might have a Rescorla Expires January 22, 2020 [Page 15] Internet-Draft WebRTC Sec. Arch. July 2019 fairly narrow list of peers he is willing to communicate with, e.g., "my mother" rather than "anyone on Facebook". Narrow permissions grants allow the browser to do that enforcement. API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). Combined with secure authentication of the communicating peer, this allows a user to be sure that the calling site is not accessing or modifying their conversion. UI Requirement: The UI MUST clearly indicate when the user's camera and microphone are in use. This indication MUST NOT be suppressable by the JS and MUST clearly indicate how to terminate device access, and provide a UI means to immediately stop camera/ microphone input without the JS being able to prevent it. UI Requirement: If the UI indication of camera/microphone use are displayed in the browser such that minimizing the browser window would hide the indication, or the JS creating an overlapping window would hide the indication, then the browser SHOULD stop camera and microphone input when the indication is hidden. [Note: this may not be necessary in systems that are non-windows-based but that have good notifications support, such as phones.] o Browsers MUST NOT permit permanent screen or application sharing permissions to be installed as a response to a JS request for permissions. Instead, they must require some other user action such as a permissions setting or an application install experience to grant permission to a site. o Browsers MUST provide a separate dialog request for screen/ application sharing permissions even if the media request is made at the same time as camera and microphone. o The browser MUST indicate any windows which are currently being shared in some unambiguous way. Windows which are not visible MUST NOT be shared even if the application is being shared. If the screen is being shared, then that MUST be indicated. Browsers MAY permit the formation of data channels without any direct user approval. Because sites can always tunnel data through the server, further restrictions on the data channel do not provide any additional security. (See Section 6.3 for a related issue). Implementations which support some form of direct user authentication SHOULD also provide a policy by which a user can authorize calls only to specific communicating peers. Specifically, the implementation SHOULD provide the following interfaces/controls: Rescorla Expires January 22, 2020 [Page 16] Internet-Draft WebRTC Sec. Arch. July 2019 o Allow future calls to this verified user. o Allow future calls to any verified user who is in my system address book (this only works with address book integration, of course). Implementations SHOULD also provide a different user interface indication when calls are in progress to users whose identities are directly verifiable. Section 6.5 provides more on this. 6.3. Communications Consent Browser client implementations of WebRTC MUST implement ICE. Server gateway implementations which operate only at public IP addresses MUST implement either full ICE or ICE-Lite [RFC8445]. Browser implementations MUST verify reachability via ICE prior to sending any non-ICE packets to a given destination. Implementations MUST NOT provide the ICE transaction ID to JavaScript during the lifetime of the transaction (i.e., during the period when the ICE stack would accept a new response for that transaction). The JS MUST NOT be permitted to control the local ufrag and password, though it of course knows it. While continuing consent is required, the ICE [RFC8445]; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient. The current WG consensus is to use ICE Binding Requests for continuing consent freshness. ICE already requires that implementations respond to such requests, so this approach is maximally compatible. A separate document will profile the ICE timers to be used; see [RFC7675]. 6.4. IP Location Privacy A side effect of the default ICE behavior is that the peer learns one's IP address, which leaks large amounts of location information. This has negative privacy consequences in some circumstances. The API requirements in this section are intended to mitigate this issue. Note that these requirements are not intended to protect the user's IP address from a malicious site. In general, the site will learn at least a user's server reflexive address from any HTTP transaction. Rather, these requirements are intended to allow a site to cooperate with the user to hide the user's IP address from the other side of the call. Hiding the user's IP address from the server requires some sort of explicit privacy preserving mechanism on the client (e.g., Tor Browser [https://www.torproject.org/projects/torbrowser.html.en]) and is out of scope for this specification. Rescorla Expires January 22, 2020 [Page 17] Internet-Draft WebRTC Sec. Arch. July 2019 API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. API Requirement: The API MUST provide a mechanism for the calling application JS to indicate that only TURN candidates are to be used. This prevents the peer from learning one's IP address at all. This mechanism MUST also permit suppression of the related address field, since that leaks local addresses. API Requirement: The API MUST provide a mechanism for the calling application to reconfigure an existing call to add non-TURN candidates. Taken together, this and the previous requirement allow ICE negotiation to start immediately on incoming call notification, thus reducing post-dial delay, but also to avoid disclosing the user's IP address until they have decided to answer. They also allow users to completely hide their IP address for the duration of the call. Finally, they allow a mechanism for the user to optimize performance by reconfiguring to allow non- TURN candidates during an active call if the user decides they no longer need to hide their IP address Note that some enterprises may operate proxies and/or NATs designed to hide internal IP addresses from the outside world. WebRTC provides no explicit mechanism to allow this function. Either such enterprises need to proxy the HTTP/HTTPS and modify the SDP and/or the JS, or there needs to be browser support to set the "TURN-only" policy regardless of the site's preferences. 6.5. Communications Security Implementations MUST support SRTP [RFC3711]. Implementations MUST support DTLS [RFC6347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST support SCTP over DTLS [RFC8261]. All media channels MUST be secured via SRTP and SRTCP. Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP MUST be offered for every media channel. WebRTC implementations MUST NOT offer SDP Security Descriptions [RFC4568] or select it if offered. A SRTP MKI MUST NOT be used. All data channels MUST be secured via DTLS. Rescorla Expires January 22, 2020 [Page 18] Internet-Draft WebRTC Sec. Arch. July 2019 All Implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186]. Earlier drafts of this specification required DTLS 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this writing some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Implementations MUST favor cipher suites which support (Perfect Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. Endpoints MUST NOT implement TLS False Start [RFC7918]. API Requirement: The API MUST generate a new authentication key pair for every new call by default. This is intended to allow for unlinkability. API Requirement: The API MUST provide a means to reuse a key pair for calls. This can be used to enable key continuity-based authentication, and could be used to amortize key generation costs. API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) API Requirement: When DTLS-SRTP is used, the API MUST NOT permit the JS to obtain the negotiated keying material. This requirement preserves the end-to-end security of the media. UI Requirements: A user-oriented client MUST provide an "inspector" interface which allows the user to determine the security characteristics of the media. The following properties SHOULD be displayed "up-front" in the browser chrome, i.e., without requiring the user to ask for them: * A client MUST provide a user interface through which a user may determine the security characteristics for currently-displayed audio and video stream(s) Rescorla Expires January 22, 2020 [Page 19] Internet-Draft WebRTC Sec. Arch. July 2019 * A client MUST provide a user interface through which a user may determine the security characteristics for transmissions of their microphone audio and camera video. * If the far endpoint was directly verified, either via a third- party verifiable X.509 certificate or via a Web IdP mechanism (see Section 7) the "security characteristics" MUST include the verified information. X.509 identities and Web IdP identities have similar semantics and should be displayed in a similar way. The following properties are more likely to require some "drill- down" from the user: * The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) * The "security characteristics" MUST indicate whether PFS is provided. * The "security characteristics" MUST include some mechanism to allow an out-of-band verification of the peer, such as a certificate fingerprint or a Short Authentication String (SAS). These are compared by the peers to authenticate one another. 7. Web-Based Peer Authentication In a number of cases, it is desirable for the endpoint (i.e., the browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are connected. For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side. Alternately, they may be making a call on a site which they minimally trust (such as a poker site) but to someone who has an identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed. While the details vary, what these technologies share is that they have a Web-based (i.e., HTTP/HTTPS) identity provider which attests to Alice's identity. For instance, if Alice has an account at example.org, Alice could use the example.org identity provider to prove to others that Alice is alice@example.org. The development of these technologies allows us Rescorla Expires January 22, 2020 [Page 20] Internet-Draft WebRTC Sec. Arch. July 2019 to separate calling from identity provision: Alice could call you on a poker site but identify herself as alice@example.org. Whatever the underlying technology, the general principle is that the party which is being authenticated is NOT the signaling site but rather the user (and their browser). Similarly, the relying party is the browser and not the signaling site. Thus, the browser MUST generate the input to the IdP assertion process and display the results of the verification process to the user in a way which cannot be imitated by the calling site. The mechanisms defined in this document do not require the browser to implement any particular identity protocol or to support any particular IdP. Instead, this document provides a generic interface which any IdP can implement. Thus, new IdPs and protocols can be introduced without change to either the browser or the calling service. This avoids the need to make a commitment to any particular identity protocol, although browsers may opt to directly implement some identity protocols in order to provide superior performance or UI properties. 7.1. Trust Relationships: IdPs, APs, and RPs Any federated identity protocol has three major participants: Authenticating Party (AP): The entity which is trying to establish its identity. Identity Provider (IdP): The entity which is vouching for the AP's identity. Relying Party (RP): The entity which is trying to verify the AP's identity. The AP and the IdP have an account relationship of some kind: the AP registers with the IdP and is able to subsequently authenticate directly to the IdP (e.g., with a password). This means that the browser must somehow know which IdP(s) the user has an account relationship with. This can either be something that the user configures into the browser or that is configured at the calling site and then provided to the PeerConnection by the Web application at the calling site. The use case for having this information configured into the browser is that the user may "log into" the browser to bind it to some identity. This is becoming common in new browsers. Rescorla Expires January 22, 2020 [Page 21] Internet-Draft WebRTC Sec. Arch. July 2019 However, it should also be possible for the IdP information to simply be provided by the calling application. At a high level there are two kinds of IdPs: Authoritative: IdPs which have verifiable control of some section of the identity space. For instance, in the realm of e-mail, the operator of "example.com" has complete control of the namespace ending in "@example.com". Thus, "alice@example.com" is whoever the operator says it is. Examples of systems with authoritative identity providers include DNSSEC, RFC 4474, and Facebook Connect (Facebook identities only make sense within the context of the Facebook system). Third-Party: IdPs which don't have control of their section of the identity space but instead verify user's identities via some unspecified mechanism and then attest to it. Because the IdP doesn't actually control the namespace, RPs need to trust that the IdP is correctly verifying AP identities, and there can potentially be multiple IdPs attesting to the same section of the identity space. Probably the best-known example of a third-party identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. If an AP is authenticating via an authoritative IdP, then the RP does not need to explicitly configure trust in the IdP at all. The identity mechanism can directly verify that the IdP indeed made the relevant identity assertion (a function provided by the mechanisms in this document), and any assertion it makes about an identity for which it is authoritative is directly verifiable. Note that this does not mean that the IdP might not lie, but that is a trustworthiness judgement that the user can make at the time he looks at the identity. By contrast, if an AP is authenticating via a third-party IdP, the RP needs to explicitly trust that IdP (hence the need for an explicit trust anchor list in PKI-based SSL/TLS clients). The list of trustable IdPs needs to be configured directly into the browser, either by the user or potentially by the browser manufacturer. This is a significant advantage of authoritative IdPs and implies that if third-party IdPs are to be supported, the potential number needs to be fairly small. Rescorla Expires January 22, 2020 [Page 22] Internet-Draft WebRTC Sec. Arch. July 2019 7.2. Overview of Operation In order to provide security without trusting the calling site, the PeerConnection component of the browser must interact directly with the IdP. The details of the mechanism are described in the W3C API specification, but the general idea is that the PeerConnection component downloads JS from a specific location on the IdP dictated by the IdP domain name. That JS (the "IdP proxy") runs in an isolated security context within the browser and the PeerConnection talks to it via a secure message passing channel. Note that there are two logically separate functions here: o Identity assertion generation. o Identity assertion verification. The same IdP JS "endpoint" is used for both functions but of course a given IdP might behave differently and load new JS to perform one function or the other. +--------------------------------------+ | Browser | | | | +----------------------------------+ | | | https://calling-site.example.com | | | | | | | | Calling JS Code | | | | ^ | | | +---------------|------------------+ | | | API Calls | | v | | PeerConnection | | ^ | | | API Calls | | +-----------|-------------+ | +---------------+ | | v | | | | | | IdP Proxy |<-------->| Identity | | | | | | Provider | | | https://idp.example.org | | | | | +-------------------------+ | +---------------+ | | +--------------------------------------+ When the PeerConnection object wants to interact with the IdP, the sequence of events is as follows: Rescorla Expires January 22, 2020 [Page 23] Internet-Draft WebRTC Sec. Arch. July 2019 1. The browser (the PeerConnection component) instantiates an IdP proxy. This allows the IdP to load whatever JS is necessary into the proxy. The resulting code runs in the IdP's security context. 2. The IdP registers an object with the browser that conforms to the API defined in [webrtc-api]. 3. The browser invokes methods on the object registered by the IdP proxy to create or verify identity assertions. This approach allows us to decouple the browser from any particular identity provider; the browser need only know how to load the IdP's JavaScript--the location of which is determined based on the IdP's identity--and to call the generic API for requesting and verifying identity assertions. The IdP provides whatever logic is necessary to bridge the generic protocol to the IdP's specific requirements. Thus, a single browser can support any number of identity protocols, including being forward compatible with IdPs which did not exist at the time the browser was written. 7.3. Items for Standardization There are two parts to this work: o The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for carrying assertions in JSEP messages. This is specified in Section 7.4. o The interface to the IdP, which is defined in the companion W3C WebRTC API specification [webrtc-api]. The WebRTC API specification also defines JavaScript interfaces that the calling application can use to specify which IdP to use. That API also provides access to the assertion-generation capability and the status of the validation process. 7.4. Binding Identity Assertions to JSEP Offer/Answer Transactions An identity assertion binds the user's identity (as asserted by the IdP) to the SDP offer/answer exchange and specifically to the media. In order to achieve this, the PeerConnection must provide the DTLS- SRTP fingerprint to be bound to the identity. This is provided as a JavaScript object (also known as a dictionary or hash) with a single "fingerprint" key, as shown below: Rescorla Expires January 22, 2020 [Page 24] Internet-Draft WebRTC Sec. Arch. July 2019 { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] } The "fingerprint" value is an array of objects. Each object in the array contains "algorithm" and "digest" values, which correspond directly to the algorithm and digest values in the "fingerprint" attribute of the SDP [RFC8122]. This object is encoded in a JSON [RFC8259] string for passing to the IdP. The identity assertion returned by the IdP, which is encoded in the "identity" attribute, is a JSON object that is encoded as described in Section 7.4.1. This structure does not need to be interpreted by the IdP or the IdP proxy. It is consumed solely by the RP's browser. The IdP merely treats it as an opaque value to be attested to. Thus, new parameters can be added to the assertion without modifying the IdP. 7.4.1. Carrying Identity Assertions Once an IdP has generated an assertion (see Section 7.6), it is attached to the SDP offer/answer message. This is done by adding a new 'identity' attribute to the SDP. The sole contents of this value is the identity assertion. The identity assertion produced by the IdP is encoded into a UTF-8 JSON text, then Base64-encoded [RFC4648] to produce this string. For example: Rescorla Expires January 22, 2020 [Page 25] Internet-Draft WebRTC Sec. Arch. July 2019 v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=fingerprint:sha-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=identity:\ eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz\ In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc\ IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz\ aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 a=... t=0 0 m=audio 6056 RTP/SAVP 0 a=sendrecv ... Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line, the carriage return that follows, and whitespace shall be ignored. The 'identity' attribute attests to all "fingerprint" attributes in the session description. It is therefore a session-level attribute. Multiple "fingerprint" values can be used to offer alternative certificates for a peer. The "identity" attribute MUST include all fingerprint values that are included in "fingerprint" attributes of the session description. The RP browser MUST verify that the in-use certificate for a DTLS connection is in the set of fingerprints returned from the IdP when verifying an assertion. 7.5. Determining the IdP URI In order to ensure that the IdP is under control of the domain owner rather than someone who merely has an account on the domain owner's server (e.g., in shared hosting scenarios), the IdP JavaScript is hosted at a deterministic location based on the IdP's domain name. Each IdP proxy instance is associated with two values: Authority: The authority [RFC3986] at which the IdP's service is hosted. protocol: The specific IdP protocol which the IdP is using. This is a completely opaque IdP-specific string, but allows an IdP to implement two protocols in parallel. This value may be the empty Rescorla Expires January 22, 2020 [Page 26] Internet-Draft WebRTC Sec. Arch. July 2019 string. If no value for protocol is provided, a value of "default" is used. Each IdP MUST serve its initial entry page (i.e., the one loaded by the IdP proxy) from a well-known URI [RFC5785]. The well-known URI for an IdP proxy is formed from the following URI components: 1. The scheme, "https:". An IdP MUST be loaded using HTTPS [RFC2818]. 2. The authority [RFC3986]. As noted above, the authority MAY contain a non-default port number or userinfo sub-component. Both are removed when determining if an asserted identity matches the name of the IdP. 3. The path, starting with "/.well-known/idp-proxy/" and appended with the IdP protocol. Note that the separator characters '/' (%2F) and '\' (%5C) MUST NOT be permitted in the protocol field, lest an attacker be able to direct requests outside of the controlled "/.well-known/" prefix. Query and fragment values MAY be used by including '?' or '#' characters. For example, for the IdP "identity.example.com" and the protocol "example", the URL would be: https://identity.example.com/.well-known/idp-proxy/example The IdP MAY redirect requests to this URL, but they MUST retain the "https" scheme. This changes the effective origin of the IdP, but not the domain of the identities that the IdP is permitted to assert and validate. I.e., the IdP is still regarded as authoritative for the original domain. 7.5.1. Authenticating Party How an AP determines the appropriate IdP domain is out of scope of this specification. In general, however, the AP has some actual account relationship with the IdP, as this identity is what the IdP is attesting to. Thus, the AP somehow supplies the IdP information to the browser. Some potential mechanisms include: o Provided by the user directly. o Selected from some set of IdPs known to the calling site. E.g., a button that shows "Authenticate via Facebook Connect" Rescorla Expires January 22, 2020 [Page 27] Internet-Draft WebRTC Sec. Arch. July 2019 7.5.2. Relying Party Unlike the AP, the RP need not have any particular relationship with the IdP. Rather, it needs to be able to process whatever assertion is provided by the AP. As the assertion contains the IdP's identity in the "idp" field of the JSON-encoded object (see Section 7.6), the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction. Authoritative assertions need only be verifiable. Third-party assertions also MUST be verified against local policy, as described in Section 8.1. 7.6. Requesting Assertions The input to identity assertion is the JSON-encoded object described in Section 7.4 that contains the set of certificate fingerprints the browser intends to use. This string is treated as opaque from the perspective of the IdP. The browser also identifies the origin that the PeerConnection is run in, which allows the IdP to make decisions based on who is requesting the assertion. An application can optionally provide a user identifier hint when specifying an IdP. This value is a hint that the IdP can use to select amongst multiple identities, or to avoid providing assertions for unwanted identities. The "username" is a string that has no meaning to any entity other than the IdP, it can contain any data the IdP needs in order to correctly generate an assertion. An identity assertion that is successfully provided by the IdP consists of the following information: idp: The domain name of an IdP and the protocol string. This MAY identify a different IdP or protocol from the one that generated the assertion. assertion: An opaque value containing the assertion itself. This is only interpretable by the identified IdP or the IdP code running in the client. Figure 5 shows an example assertion formatted as JSON. In this case, the message has presumably been digitally signed/MACed in some way that the IdP can later verify it, but this is an implementation detail and out of scope of this document. Rescorla Expires January 22, 2020 [Page 28] Internet-Draft WebRTC Sec. Arch. July 2019 { "idp":{ "domain": "example.org", "protocol": "bogus" }, "assertion": "{\"identity\":\"bob@example.org\", \"contents\":\"abcdefghijklmnopqrstuvwyz\", \"signature\":\"010203040506\"}" } Figure 5: Example assertion For use in signaling, the assertion is serialized into JSON, Base64-encoded [RFC4648], and used as the value of the "identity" attribute. IdPs SHOULD ensure that any assertions they generate cannot be interpreted in a different context. E.g., they should use a distinct format or have separate cryptographic keys for assertion generation and other purposes. Line breaks are inserted solely for readability. 7.7. Managing User Login In order to generate an identity assertion, the IdP needs proof of the user's identity. It is common practice to authenticate users (using passwords or multi-factor authentication), then use Cookies [RFC6265] or HTTP authentication [RFC7617] for subsequent exchanges. The IdP proxy is able to access cookies, HTTP authentication or other persistent session data because it operates in the security context of the IdP origin. Therefore, if a user is logged in, the IdP could have all the information needed to generate an assertion. An IdP proxy is unable to generate an assertion if the user is not logged in, or the IdP wants to interact with the user to acquire more information before generating the assertion. If the IdP wants to interact with the user before generating an assertion, the IdP proxy can fail to generate an assertion and instead indicate a URL where login should proceed. The application can then load the provided URL to enable the user to enter credentials. The communication between the application and the IdP is described in [webrtc-api]. 8. Verifying Assertions The input to identity validation is the assertion string taken from a decoded 'identity' attribute. Rescorla Expires January 22, 2020 [Page 29] Internet-Draft WebRTC Sec. Arch. July 2019 The IdP proxy verifies the assertion. Depending on the identity protocol, the proxy might contact the IdP server or other servers. For instance, an OAuth-based protocol will likely require using the IdP as an oracle, whereas with a signature-based scheme might be able to verify the assertion without contacting the IdP, provided that it has cached the relevant public key. Regardless of the mechanism, if verification succeeds, a successful response from the IdP proxy consists of the following information: identity: The identity of the AP from the IdP's perspective. Details of this are provided in Section 8.1. contents: The original unmodified string provided by the AP as input to the assertion generation process. Figure 6 shows an example response, which is JSON-formatted. { "identity": "bob@example.org", "contents": "{\"fingerprint\":[ ... ]}" } Figure 6: Example verification result 8.1. Identity Formats The identity provided from the IdP to the RP browser MUST consist of a string representing the user's identity. This string is in the form "@", where "user" consists of any character, and domain is aninternationalized domain name [RFC5890] encoded as a sequence of U-labels. The PeerConnection API MUST check this string as follows: 1. If the "domain" portion of the string is equal to the domain name of the IdP proxy, then the assertion is valid, as the IdP is authoritative for this domain. Comparison of domain names is done using the label equivalence rule defined in Section 2.3.2.4 of [RFC5890]. 2. If the "domain" portion of the string is not equal to the domain name of the IdP proxy, then the PeerConnection object MUST reject the assertion unless both: 1. the IdP domain is trusted as an acceptable third-party IdP; and Rescorla Expires January 22, 2020 [Page 30] Internet-Draft WebRTC Sec. Arch. July 2019 2. local policy is configured to trust this IdP domain for the domain portion of the identity string. Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in Section 2.1 of [RFC3986]. Characters other than "@" and "%" MUST NOT be percent-encoded. For example, with a "user" of "user@133" and a "domain" of "identity.example.com", the resulting string will be encoded as "user%40133@identity.example.com". Implementations are cautioned to take care when displaying user identities containing escaped "@" characters. If such characters are unescaped prior to display, implementations MUST distinguish between the domain of the IdP proxy and any domain that might be implied by the portion of the "" portion that appears after the escaped "@" sign. 9. Security Considerations Much of the security analysis of this problem is contained in [I-D.ietf-rtcweb-security] or in the discussion of the particular issues above. In order to avoid repetition, this section focuses on (a) residual threats that are not addressed by this document and (b) threats produced by failure/misbehavior of one of the components in the system. 9.1. Communications Security IF HTTPS is not used to secure communications to the signaling server, and the identity mechanism used in Section 7 is not used, then any on-path attacker can replace the DTLS-SRTP fingerprints in the handshake and thus substitute its own identity for that of either endpoint. Even if HTTPS is used, the signaling server can potentially mount a man-in-the-middle attack unless implementations have some mechanism for independently verifying keys. The UI requirements in Section 6.5 are designed to provide such a mechanism for motivated/security conscious users, but are not suitable for general use. The identity service mechanisms in Section 7 are more suitable for general use. Note, however, that a malicious signaling service can strip off any such identity assertions, though it cannot forge new ones. Note that all of the third-party security mechanisms available (whether X.509 certificates or a third-party IdP) rely on the security of the third party--this is of course also true of the user's connection to the Web site itself. Users who wish to assure themselves of security against a malicious identity provider can only do so by verifying Rescorla Expires January 22, 2020 [Page 31] Internet-Draft WebRTC Sec. Arch. July 2019 peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band. In order to protect against malicious content JavaScript, that JavaScript MUST NOT be allowed to have direct access to---or perform computations with---DTLS keys. For instance, if content JS were able to compute digital signatures, then it would be possible for content JS to get an identity assertion for a browser's generated key and then use that assertion plus a signature by the key to authenticate a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the content JS, thus violating the security guarantees otherwise provided by the IdP mechanism. Note that it is not sufficient merely to deny the content JS direct access to the keys, as some have suggested doing with the WebCrypto API [webcrypto]. The JS must also not be allowed to perform operations that would be valid for a DTLS endpoint. By far the safest approach is simply to deny the ability to perform any operations that depend on secret information associated with the key. Operations that depend on public information, such as exporting the public key are of course safe. 9.2. Privacy The requirements in this document are intended to allow: o Users to participate in calls without revealing their location. o Potential callees to avoid revealing their location and even presence status prior to agreeing to answer a call. However, these privacy protections come at a performance cost in terms of using TURN relays and, in the latter case, delaying ICE. Sites SHOULD make users aware of these tradeoffs. Note that the protections provided here assume a non-malicious calling service. As the calling service always knows the users status and (absent the use of a technology like Tor) their IP address, they can violate the users privacy at will. Users who wish privacy against the calling sites they are using must use separate privacy enhancing technologies such as Tor. Combined WebRTC/Tor implementations SHOULD arrange to route the media as well as the signaling through Tor. Currently this will produce very suboptimal performance. Additionally, any identifier which persists across multiple calls is potentially a problem for privacy, especially for anonymous calling services. Such services SHOULD instruct the browser to use separate DTLS keys for each call and also to use TURN throughout the call. Otherwise, the other side will learn linkable information that would Rescorla Expires January 22, 2020 [Page 32] Internet-Draft WebRTC Sec. Arch. July 2019 allow them to correlate the browser across multiple calls. Additionally, browsers SHOULD implement the privacy-preserving CNAME generation mode of [RFC7022]. 9.3. Denial of Service The consent mechanisms described in this document are intended to mitigate denial of service attacks in which an attacker uses clients to send large amounts of traffic to a victim without the consent of the victim. While these mechanisms are sufficient to protect victims who have not implemented WebRTC at all, WebRTC implementations need to be more careful. Consider the case of a call center which accepts calls via WebRTC. An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center. Note that this requires user consent in many cases but because the data channel does not need consent, he can use that directly. Since ICE will complete, browsers can then be induced to send large amounts of data to the victim call center if it supports the data channel at all. Preventing this attack requires that automated WebRTC implementations implement sensible flow control and have the ability to triage out (i.e., stop responding to ICE probes on) calls which are behaving badly, and especially to be prepared to remotely throttle the data channel in the absence of plausible audio and video (which the attacker cannot control). Another related attack is for the signaling service to swap the ICE candidates for the audio and video streams, thus forcing a browser to send video to the sink that the other victim expects will contain audio (perhaps it is only expecting audio!) potentially causing overload. Muxing multiple media flows over a single transport makes it harder to individually suppress a single flow by denying ICE keepalives. Either media-level (RTCP) mechanisms must be used or the implementation must deny responses entirely, thus terminating the call. Yet another attack, suggested by Magnus Westerlund, is for the attacker to cross-connect offers and answers as follows. It induces the victim to make a call and then uses its control of other users browsers to get them to attempt a call to someone. It then translates their offers into apparent answers to the victim, which looks like large-scale parallel forking. The victim still responds to ICE responses and now the browsers all try to send media to the victim. Implementations can defend themselves from this attack by only responding to ICE Binding Requests for a limited number of remote ufrags (this is the reason for the requirement that the JS not be able to control the ufrag and password). Rescorla Expires January 22, 2020 [Page 33] Internet-Draft WebRTC Sec. Arch. July 2019 [I-D.ietf-rtcweb-rtp-usage] Section 13 documents a number of potential RTCP-based DoS attacks and countermeasures. Note that attacks based on confusing one end or the other about consent are possible even in the face of the third-party identity mechanism as long as major parts of the signaling messages are not signed. On the other hand, signing the entire message severely restricts the capabilities of the calling application, so there are difficult tradeoffs here. 9.4. IdP Authentication Mechanism This mechanism relies for its security on the IdP and on the PeerConnection correctly enforcing the security invariants described above. At a high level, the IdP is attesting that the user identified in the assertion wishes to be associated with the assertion. Thus, it must not be possible for arbitrary third parties to get assertions tied to a user or to produce assertions that RPs will accept. 9.4.1. PeerConnection Origin Check Fundamentally, the IdP proxy is just a piece of HTML and JS loaded by the browser, so nothing stops a Web attacker from creating their own IFRAME, loading the IdP proxy HTML/JS, and requesting a signature over his own keys rather than those generated in the browser. However, that proxy would be in the attacker's origin, not the IdP's origin. Only the browser itself can instantiate a context that (a) is in the IdP's origin and (b) exposes the correct API surface. Thus, the IdP proxy on the sender's side MUST ensure that it is running in the IdP's origin prior to issuing assertions. Note that this check only asserts that the browser (or some other entity with access to the user's authentication data) attests to the request and hence to the fingerprint. It does not demonstrate that the browser has access to the associated private key, and therefore an attacker can attach their own identity to another party's keying material, thus making a call which comes from Alice appear to come from the attacker. See [I-D.ietf-mmusic-sdp-uks] for defenses against this form of attack. 9.4.2. IdP Well-known URI As described in Section 7.5 the IdP proxy HTML/JS landing page is located at a well-known URI based on the IdP's domain name. This requirement prevents an attacker who can write some resources at the IdP (e.g., on one's Facebook wall) from being able to impersonate the IdP. Rescorla Expires January 22, 2020 [Page 34] Internet-Draft WebRTC Sec. Arch. July 2019 9.4.3. Privacy of IdP-generated identities and the hosting site Depending on the structure of the IdP's assertions, the calling site may learn the user's identity from the perspective of the IdP. In many cases this is not an issue because the user is authenticating to the site via the IdP in any case, for instance when the user has logged in with Facebook Connect and is then authenticating their call with a Facebook identity. However, in other case, the user may not have already revealed their identity to the site. In general, IdPs SHOULD either verify that the user is willing to have their identity revealed to the site (e.g., through the usual IdP permissions dialog) or arrange that the identity information is only available to known RPs (e.g., social graph adjacencies) but not to the calling site. The "domain" field of the assertion request can be used to check that the user has agreed to disclose their identity to the calling site; because it is supplied by the PeerConnection it can be trusted to be correct. 9.4.4. Security of Third-Party IdPs As discussed above, each third-party IdP represents a new universal trust point and therefore the number of these IdPs needs to be quite limited. Most IdPs, even those which issue unqualified identities such as Facebook, can be recast as authoritative IdPs (e.g., 123456@facebook.com). However, in such cases, the user interface implications are not entirely desirable. One intermediate approach is to have special (potentially user configurable) UI for large authoritative IdPs, thus allowing the user to instantly grasp that the call is being authenticated by Facebook, Google, etc. 9.4.4.1. Confusable Characters Because a broad range of characters are permitted in identity strings, it may be possible for attackers to craft identities which are confusable with other identities (see [RFC6943] for more on this topic). This is a problem with any identifier space of this type (e.g., e-mail addresses). Those minting identifers should avoid mixed scripts and similar confusable characters. Those presenting these identifiers to a user should consider highlighting cases of mixed script usage (see [RFC5890], section 4.4). Other best practices are still in development. 9.4.5. Web Security Feature Interactions A number of optional Web security features have the potential to cause issues for this mechanism, as discussed below. Rescorla Expires January 22, 2020 [Page 35] Internet-Draft WebRTC Sec. Arch. July 2019 9.4.5.1. Popup Blocking When popup blocking is in use, the IdP proxy is unable to generate popup windows, dialogs or any other form of user interactions. This prevents the IdP proxy from being used to circumvent user interaction. The "LOGINNEEDED" message allows the IdP proxy to inform the calling site of a need for user login, providing the information necessary to satisfy this requirement without resorting to direct user interaction from the IdP proxy itself. 9.4.5.2. Third Party Cookies Some browsers allow users to block third party cookies (cookies associated with origins other than the top level page) for privacy reasons. Any IdP which uses cookies to persist logins will be broken by third-party cookie blocking. One option is to accept this as a limitation; another is to have the PeerConnection object disable third-party cookie blocking for the IdP proxy. 10. IANA Considerations This specification defines the "identity" SDP attribute per the procedures of Section 8.2.4 of [RFC4566]. The required information for the registration is included here: Contact Name: IESG (iesg@ietf.org) Attribute Name: identity Long Form: identity Type of Attribute: session-level Charset Considerations: This attribute is not subject to the charset attribute. Purpose: This attribute carries an identity assertion, binding an identity to the transport-level security session. Appropriate Values: See Section 5 of RFCXXXX [[Editor Note: This document.]] Mux Category: NORMAL. This section reqisters the "idp-proxy" well-known URI from [RFC5785]. URI suffix: idp-proxy Rescorla Expires January 22, 2020 [Page 36] Internet-Draft WebRTC Sec. Arch. July 2019 Change controller: IETF 11. Acknowledgements Bernard Aboba, Harald Alvestrand, Richard Barnes, Dan Druta, Cullen Jennings, Hadriel Kaplan, Matthew Kaufman, Jim McEachern, Martin Thomson, Magnus Westerland. Matthew Kaufman provided the UI material in Section 6.5. Christer Holmberg provided the initial version of Section 5.1. 12. Changes [RFC Editor: Please remove this section prior to publication.] 12.1. Changes since -15 Rewrite the Identity section in more conventional offer/answer format. Clarify rules on changing identities. 12.2. Changes since -11 Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority Clean up discussion of how to generate IdP URI. Remove obsolete text about null cipher suites. Remove obsolete appendixes about older IdP systems Require support for ECDSA, PFS, and AEAD 12.3. Changes since -10 Update cipher suite profiles. Rework IdP interaction based on implementation experience in Firefox. 12.4. Changes since -06 Replaced RTCWEB and RTC-Web with WebRTC, except when referring to the IETF WG Forbade use in mixed content as discussed in Orlando. Rescorla Expires January 22, 2020 [Page 37] Internet-Draft WebRTC Sec. Arch. July 2019 Added a requirement to surface NULL ciphers to the top-level. Tried to clarify SRTP versus DTLS-SRTP. Added a section on screen sharing permissions. Assorted editorial work. 12.5. Changes since -05 The following changes have been made since the -05 draft. o Response to comments from Richard Barnes o More explanation of the IdP security properties and the federation use case. o Editorial cleanup. 12.6. Changes since -03 Version -04 was a version control mistake. Please ignore. The following changes have been made since the -04 draft. o Move origin check from IdP to RP per discussion in YVR. o Clarified treatment of X.509-level identities. o Editorial cleanup. 12.7. Changes since -03 12.8. Changes since -02 The following changes have been made since the -02 draft. o Forbid persistent HTTP permissions. o Clarified the text in S 5.4 to clearly refer to requirements on the API to provide functionality to the site. o Fold in the IETF portion of draft-rescorla-rtcweb-generic-idp o Retarget the continuing consent section to assume Binding Requests o Added some more privacy and linkage text in various places. Rescorla Expires January 22, 2020 [Page 38] Internet-Draft WebRTC Sec. Arch. July 2019 o Editorial improvements 13. References 13.1. Normative References [FIPS186] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", NIST PUB 186-4 , July 2013. [I-D.ietf-mmusic-sdp-uks] Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on uses of TLS with the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-06 (work in progress), July 2019. [I-D.ietf-rtcweb-jsep] Uberti, J., Jennings, C., and E. Rescorla, "JavaScript Session Establishment Protocol", draft-ietf-rtcweb-jsep-26 (work in progress), February 2019. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-19 (work in progress), November 2017. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 2016. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-12 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . Rescorla Expires January 22, 2020 [Page 39] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [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, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . Rescorla Expires January 22, 2020 [Page 40] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, . [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, . [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, . [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, . [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 8122, DOI 10.17487/RFC8122, March 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Rescorla Expires January 22, 2020 [Page 41] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [webcrypto] editors, W., "Web Cryptography API", June 2013. Available at http://www.w3.org/TR/WebCryptoAPI/ [webrtc-api] editors, W., "WebRTC 1.0: Real-time Communication Between Browsers", October 2011. Available at http://dev.w3.org/2011/webrtc/editor/ webrtc.html 13.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, . [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, . [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, . [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . Rescorla Expires January 22, 2020 [Page 42] Internet-Draft WebRTC Sec. Arch. July 2019 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . [XmlHttpRequest] van Kesteren, A., "XMLHttpRequest Level 2", January 2012. Author's Address Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA Phone: +1 650 678 2350 Email: ekr@rtfm.com Rescorla Expires January 22, 2020 [Page 43] ./draft-ietf-rtcweb-transports-17.txt0000644000764400076440000012155013004145207017063 0ustar iustyiusty Network Working Group H. Alvestrand Internet-Draft Google Intended status: Standards Track October 26, 2016 Expires: April 29, 2017 Transports for WebRTC draft-ietf-rtcweb-transports-17 Abstract This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2017. 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. Alvestrand Expires April 29, 2017 [Page 1] Internet-Draft WebRTC Transports October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 3. Transport and Middlebox specification . . . . . . . . . . . . 3 3.1. System-provided interfaces . . . . . . . . . . . . . . . 3 3.2. Ability to use IPv4 and IPv6 . . . . . . . . . . . . . . 4 3.3. Usage of temporary IPv6 addresses . . . . . . . . . . . . 4 3.4. Middle box related functions . . . . . . . . . . . . . . 5 3.5. Transport protocols implemented . . . . . . . . . . . . . 6 4. Media Prioritization . . . . . . . . . . . . . . . . . . . . 7 4.1. Local prioritization . . . . . . . . . . . . . . . . . . 8 4.2. Usage of Quality of Service - DSCP and Multiplexing . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 A.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 16 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 16 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 17 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 17 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 17 A.6. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17 A.7. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 18 A.8. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 18 A.9. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 18 A.10. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 A.11. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 A.12. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 19 A.13. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 19 A.14. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 19 A.15. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 19 A.16. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19 A.17. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction WebRTC is a protocol suite aimed at real time multimedia exchange between browsers, and between browsers and other entities. WebRTC is described in the WebRTC overview document, [I-D.ietf-rtcweb-overview], which also defines terminology used in this document, including the terms "WebRTC endpoint" and "WebRTC browser". Alvestrand Expires April 29, 2017 [Page 2] Internet-Draft WebRTC Transports October 2016 Terminology for RTP sources is taken from[RFC7656] . This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. This protocol suite intends to satisfy the security considerations described in the WebRTC security documents, [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. This document describes requirements that apply to all WebRTC endpoints. When there are requirements that apply only to WebRTC browsers, this is called out explicitly. 2. Requirements language 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 RFC 2119 [RFC2119]. 3. Transport and Middlebox specification 3.1. System-provided interfaces The protocol specifications used here assume that the following protocols are available to the implementations of the WebRTC protocols: o UDP [RFC0768]. This is the protocol assumed by most protocol elements described. o TCP [RFC0793]. This is used for HTTP/WebSockets, as well as for TURN/TLS and ICE-TCP. For both protocols, IPv4 and IPv6 support is assumed. For UDP, this specification assumes the ability to set the DSCP code point of the sockets opened on a per-packet basis, in order to achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos] (see Section 4.2) when multiple media types are multiplexed. It does not assume that the DSCP codepoints will be honored, and does assume that they may be zeroed or changed, since this is a local configuration issue. Platforms that do not give access to these interfaces will not be able to support a conforming WebRTC endpoint. Alvestrand Expires April 29, 2017 [Page 3] Internet-Draft WebRTC Transports October 2016 This specification does not assume that the implementation will have access to ICMP or raw IP. The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": o TURN - Traversal Using Relays Around NAT, [RFC5766] o STUN - Session Traversal Utilities for NAT, [RFC5389] o ICE - Interactive Connectivity Establishment, [I-D.ietf-ice-rfc5245bis] o TLS - Transport Layer Security, [RFC5246] o DTLS - Datagram Transport Layer Security, [RFC6347]. 3.2. Ability to use IPv4 and IPv6 Web applications running in a WebRTC browser MUST be able to utilize both IPv4 and IPv6 where available - that is, when two peers have only IPv4 connectivity to each other, or they have only IPv6 connectivity to each other, applications running in the WebRTC browser MUST be able to communicate. When TURN is used, and the TURN server has IPv4 or IPv6 connectivity to the peer or the peer's TURN server, candidates of the appropriate types MUST be supported. The "Happy Eyeballs" specification for ICE [I-D.ietf-mmusic-ice-dualstack-fairness] SHOULD be supported. 3.3. Usage of temporary IPv6 addresses The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses. This is a change from the rules specified by [RFC3484]. For applications that select a single address, this is usually done by the IPV6_PREFER_SRC_TMP preference flag specified in [RFC5014]. However, this rule, which is intended to ensure that privacy-enhanced addresses are used in preference to static addresses, doesn't have the right effect in ICE, where all addresses are gathered and therefore revealed to the application. Therefore, the following rule is applied instead: When a WebRTC endpoint gathers all IPv6 addresses on its host, and both non-deprecated temporary addresses and permanent addresses of the same scope are present, the WebRTC endpoint SHOULD discard the permanent addresses before exposing addresses to the application or Alvestrand Expires April 29, 2017 [Page 4] Internet-Draft WebRTC Transports October 2016 using them in ICE. This is consistent with the default policy described in [RFC6724]. If some of the temporary IPv6 addresses, but not all, are marked deprecated, the WebRTC endpoint SHOULD discard the deprecated addresses, unless they are used by an ongoing connection. In an ICE restart, deprecated addresses that are currently in use MAY be retained. 3.4. Middle box related functions The primary mechanism to deal with middle boxes is ICE, which is an appropriate way to deal with NAT boxes and firewalls that accept traffic from the inside, but only from the outside if it is in response to inside traffic (simple stateful firewalls). ICE [I-D.ietf-ice-rfc5245bis] MUST be supported. The implementation MUST be a full ICE implementation, not ICE-Lite. A full ICE implementation allows interworking with both ICE and ICE-Lite implementations when they are deployed appropriately. In order to deal with situations where both parties are behind NATs of the type that perform endpoint-dependent mapping (as defined in [RFC5128] section 2.4), TURN [RFC5766] MUST be supported. WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. Note that there is other work around STUN and TURN sever discovery and management, including [I-D.ietf-tram-turn-server-discovery] for server discovery, as well as [I-D.ietf-rtcweb-return]. In order to deal with firewalls that block all UDP traffic, the mode of TURN that uses TCP between the WebRTC endpoint and the TURN server MUST be supported, and the mode of TURN that uses TLS over TCP between the WebRTC endpoint and the TURN server MUST be supported. See [RFC5766] section 2.1 for details. In order to deal with situations where one party is on an IPv4 network and the other party is on an IPv6 network, TURN extensions for IPv6 [RFC6156] MUST be supported. TURN TCP candidates, where the connection from the WebRTC endpoint's TURN server to the peer is a TCP connection, [RFC6062] MAY be supported. However, such candidates are not seen as providing any significant benefit, for the following reasons. Alvestrand Expires April 29, 2017 [Page 5] Internet-Draft WebRTC Transports October 2016 First, use of TURN TCP candidates would only be relevant in cases which both peers are required to use TCP to establish a PeerConnection. Second, that use case is supported in a different way by both sides establishing UDP relay candidates using TURN over TCP to connect to their respective relay servers. Third, using TCP between the WebRTC endpoint's TURN server and the peer may result in more performance problems than using UDP, e.g. due to head of line blocking. ICE-TCP candidates [RFC6544] MUST be supported; this may allow applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server. If TCP connections are used, RTP framing according to [RFC4571] MUST be used for all packets. This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets. The ALTERNATE-SERVER mechanism specified in [RFC5389] (STUN) section 11 (300 Try Alternate) MUST be supported. The WebRTC endpoint MAY support accessing the Internet through an HTTP proxy. If it does so, it MUST include the "ALPN" header as specified in [RFC7639], and proxy authentication as described in Section 4.3.6 of [RFC7231] and [RFC7235] MUST also be supported. 3.5. Transport protocols implemented For transport of media, secure RTP is used. The details of the profile of RTP used are described in "RTP Usage" [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker [I-D.ietf-avtcore-rtp-circuit-breakers] and congstion control (see [I-D.ietf-rmcat-cc-requirements] for further guidance). Key exchange MUST be done using DTLS-SRTP, as described in [I-D.ietf-rtcweb-security-arch]. For data transport over the WebRTC data channel [I-D.ietf-rtcweb-data-channel], WebRTC endpoints MUST support SCTP over DTLS over ICE. This encapsulation is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Negotiation of this transport in SDP is defined in [I-D.ietf-mmusic-sctp-sdp]. The SCTP extension for NDATA, [I-D.ietf-tsvwg-sctp-ndata], MUST be supported. The setup protocol for WebRTC data channels described in [I-D.ietf-rtcweb-data-protocol] MUST be supported. Alvestrand Expires April 29, 2017 [Page 6] Internet-Draft WebRTC Transports October 2016 Note: DTLS-SRTP as defined in [RFC5764] section 6.7.1 defines the interaction between DTLS and ICE ( [I-D.ietf-ice-rfc5245bis]). The effect of this specification is that all ICE candidate pairs associated with a single component are part of the same DTLS association. Thus, there will only be one DTLS handshake even if there are multiple valid candidate pairs. WebRTC endpoints MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2, with clarifications in [I-D.ietf-avtcore-rfc5764-mux-fixes]. All application layer protocol payloads over this DTLS connection are SCTP packets. Protocol identification MUST be supplied as part of the DTLS handshake, as specified in [I-D.ietf-rtcweb-alpn]. 4. Media Prioritization The WebRTC prioritization model is that the application tells the WebRTC endpoint about the priority of media and data that is controlled from the API. In this context, a "flow" is used for the units that are given a specific priority through the WebRTC API. For media, a "media flow", which can be an "audio flow" or a "video flow", is what [RFC7656] calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams". This specification does not describe prioritization between the RTP streams that come from a single "media source". All media flows in WebRTC are assumed to be interactive, as defined in [RFC4594]; there is no browser API support for indicating whether media is interactive or non-interactive. A "data flow" is the outgoing data on a single WebRTC data channel. The priority associated with a media flow or data flow is classified as "very-low", "low", "medium or "high". There are only four priority levels at the API. The priority settings affect two pieces of behavior: Packet send sequence decisions and packet markings. Each is described in its own section below. Alvestrand Expires April 29, 2017 [Page 7] Internet-Draft WebRTC Transports October 2016 4.1. Local prioritization Local prioritization is applied at the local node, before the packet is sent. This means that the prioritization has full access to the data about the individual packets, and can choose differing treatment based on the stream a packet belongs to. When an WebRTC endpoint has packets to send on multiple streams that are congestion-controlled under the same congestion control regime, the WebRTC endpoint SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if both have data to send. This prioritization is independent of the media type. The details of which packet to send first are implementation defined. For example: If there is a high priority audio flow sending 100 byte packets, and a low priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. Conversely, if the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes. If there are two high priority audio flows, each will be able to send 4000 bytes in the same period where a low priority video flow is able to send 1000 bytes. Two example implementation strategies are: o When the available bandwidth is known from the congestion control algorithm, configure each codec and each data channel with a target send rate that is appropriate to its share of the available bandwidth. o When congestion control indicates that a specified number of packets can be sent, send packets that are available to send using a weighted round robin scheme across the connections. Alvestrand Expires April 29, 2017 [Page 8] Internet-Draft WebRTC Transports October 2016 Any combination of these, or other schemes that have the same effect, is valid, as long as the distribution of transmission capacity is approximately correct. For media, it is usually inappropriate to use deep queues for sending; it is more useful to, for instance, skip intermediate frames that have no dependencies on them in order to achieve a lower bitrate. For reliable data, queues are useful. Note that this specification doesn't dictate when disparate streams are to be "congestion controlled under the same congestion control regime". The issue of coupling congestion controllers is explored further in [I-D.ietf-rmcat-coupled-cc]. 4.2. Usage of Quality of Service - DSCP and Multiplexing When the packet is sent, the network will make decisions about queueing and/or discarding the packet that can affect the quality of the communication. The sender can attempt to set the DSCP field of the packet to influence these decisions. Implementations SHOULD attempt to set QoS on the packets sent, according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is appropriate to depart from this recommendation when running on platforms where QoS marking is not implemented. The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. Some examples of such behaviors are described in [ANRW16]. The detection of these conditions is implementation dependent. A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed. This is allowed even within a single media flow for video in [I-D.ietf-tsvwg-rtcweb-qos]. Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent. This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Alvestrand Expires April 29, 2017 [Page 9] Internet-Draft WebRTC Transports October 2016 Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCP code points, don't need to change. All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point. The code point used SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the highest priority data channel carried. Note that this means that all data packets, no matter what their relative priority is, will be treated the same by the network. All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. More advice on the use of DSCP code points with RTP and on the relationship between DSCP and congestion control is given in [RFC7657]. There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points. Some of these schemes depend on classifying the traffic into flows based on 5-tuple (source address, source port, protocol, destination address, destination port) or 6-tuple (5-tuple + DSCP code point). Under differing conditions, it may therefore make sense for a sending application to choose any of the configurations: o Each media stream carried on its own 5-tuple o Media streams grouped by media type into 5-tuples (such as carrying all audio on one 5-tuple) o All media sent over a single 5-tuple, with or without differentiation into 6-tuples based on DSCP code points In each of the configurations mentioned, data channels may be carried in its own 5-tuple, or multiplexed together with one of the media flows. More complex configurations, such as sending a high priority video stream on one 5-tuple and sending all other video streams multiplexed together over another 5-tuple, can also be envisioned. More information on mapping media flows to 5-tuples can be found in [I-D.ietf-rtcweb-rtp-usage]. A sending implementation MUST be able to support the following configurations: Alvestrand Expires April 29, 2017 [Page 10] Internet-Draft WebRTC Transports October 2016 o Multiplex all media and data on a single 5-tuple (fully bundled) o Send each media stream on its own 5-tuple and data on its own 5-tuple (fully unbundled) It MAY choose to support other configurations, such as bundling each media type (audio, video or data) into its own 5-tuple (bundling by media type). Sending data channel data over multiple 5-tuples is not supported. A receiving implementation MUST be able to receive media and data in all these configurations. 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations RTCWEB security considerations are enumerated in [I-D.ietf-rtcweb-security]. Security considerations pertaining to the use of DSCP are enumerated in [I-D.ietf-tsvwg-rtcweb-qos]. 7. Acknowledgements This document is based on earlier versions embedded in [I-D.ietf-rtcweb-overview], which were the results of contributions from many RTCWEB WG members. Special thanks for reviews of earlier versions of this draft go to Eduardo Gueiros, Magnus Westerlund, Markus Isomaki and Dan Wing; the contributions from Andrew Hutton also deserve special mention. 8. References 8.1. Normative References Alvestrand Expires April 29, 2017 [Page 11] Internet-Draft WebRTC Transports October 2016 [I-D.ietf-avtcore-rfc5764-mux-fixes] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", draft-ietf-avtcore-rfc5764-mux-fixes-11 (work in progress), September 2016. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-06 (work in progress), July 2014. [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-04 (work in progress), June 2016. [I-D.ietf-mmusic-ice-dualstack-fairness] Martinsen, P., Reddy, T., and P. Patil, "ICE Multihomed and IPv4/IPv6 Dual Stack Fairness", draft-ietf-mmusic-ice- dualstack-fairness-02 (work in progress), September 2015. [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-07 (work in progress), July 2014. [I-D.ietf-rmcat-cc-requirements] Jesup, R., "Congestion Control Requirements For RMCAT", draft-ietf-rmcat-cc-requirements-06 (work in progress), October 2014. [I-D.ietf-rtcweb-alpn] Thomson, M., "Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- alpn-00 (work in progress), July 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-12 (work in progress), September 2014. Alvestrand Expires April 29, 2017 [Page 12] Internet-Draft WebRTC Transports October 2016 [I-D.ietf-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Establishment Protocol", draft-ietf-rtcweb-data- protocol-08 (work in progress), September 2014. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-11 (work in progress), August 2014. [I-D.ietf-rtcweb-rtp-usage] Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-17 (work in progress), August 2014. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-10 (work in progress), July 2014. [I-D.ietf-tsvwg-rtcweb-qos] Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Polk, "DSCP and other packet markings for RTCWeb QoS", draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June 2014. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- dtls-encaps-05 (work in progress), July 2014. [I-D.ietf-tsvwg-sctp-ndata] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and a New Data Chunk for the Stream Control Transmission Protocol", draft-ietf-tsvwg-sctp- ndata-01 (work in progress), July 2014. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Alvestrand Expires April 29, 2017 [Page 13] Internet-Draft WebRTC Transports October 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection- Oriented Transport", RFC 4571, July 2006. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010. [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, March 2012. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. Alvestrand Expires April 29, 2017 [Page 14] Internet-Draft WebRTC Transports October 2016 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. [RFC7639] Hutton, A., Uberti, J., and M. Thomson, "The ALPN HTTP Header Field", RFC 7639, DOI 10.17487/RFC7639, August 2015, . [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, . 8.2. Informative References [ANRW16] Barik, R., Welzl, M., and A. Elmokashfi, "How to say that you're special: Can we use bits in the IPv4 header?", ACM, IRTF, ISOC Applied Networking Research Workshop (ANRW 2016), Berlin , July 2016. [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-03 (work in progress), July 2016. [I-D.ietf-rtcweb-return] Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC", draft- ietf-rtcweb-return-01 (work in progress), January 2016. [I-D.ietf-tram-turn-server-discovery] Patil, P., Reddy, T., and D. Wing, "TURN Server Auto Discovery", draft-ietf-tram-turn-server-discovery-00 (work in progress), July 2014. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008. Alvestrand Expires April 29, 2017 [Page 15] Internet-Draft WebRTC Transports October 2016 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10 .17487/RFC7657, November 2015, . Appendix A. Change log This section should be removed before publication as an RFC. A.1. Changes from -00 to -01 o Clarified DSCP requirements, with reference to -qos- o Clarified "symmetric NAT" -> "NATs which perform endpoint- dependent mapping" o Made support of TURN over TCP mandatory o Made support of TURN over TLS a MAY, and added open question o Added an informative reference to -firewalls- o Called out that we don't make requirements on HTTP proxy interaction (yet A.2. Changes from -01 to -02 o Required support for 300 Alternate Server from STUN. o Separated the ICE-TCP candidate requirement from the TURN-TCP requirement. o Added new sections on using QoS functions, and on multiplexing considerations. o Removed all mention of RTP profiles. Those are the business of the RTP usage draft, not this one. o Required support for TURN IPv6 extensions. o Removed reference to the TURN URI scheme, as it was unnecessary. o Made an explicit statement that multiplexing (or not) is an application matter. . Alvestrand Expires April 29, 2017 [Page 16] Internet-Draft WebRTC Transports October 2016 A.3. Changes from -02 to -03 o Added required support for draft-ietf-tsvwg-sctp-ndata o Removed discussion of multiplexing, since this is present in rtp- usage. o Added RFC 4571 reference for framing RTP packets over TCP. o Downgraded TURN TCP candidates from SHOULD to MAY, and added more language discussing TCP usage. o Added language on IPv6 temporary addresses. o Added language describing multiplexing choices. o Added a separate section detailing what it means when we say that an WebRTC implementation MUST support both IPv4 and IPv6. A.4. Changes from -03 to -04 o Added a section on prioritization, moved the DSCP section into it, and added a section on local prioritization, giving a specific algorithm for interpreting "priority" in local prioritization. o ICE-TCP candidates was changed from MAY to MUST, in recognition of the sense of the room at the London IETF. A.5. Changes from -04 to -05 o Reworded introduction o Removed all references to "WebRTC". It now uses only the term RTCWEB. o Addressed a number of clarity / language comments o Rewrote the prioritization to cover data channels and to describe multiple ways of prioritizing flows o Made explicit reference to "MUST do DTLS-SRTP", and referred to security-arch for details A.6. Changes from -05 to -06 o Changed all references to "RTCWEB" to "WebRTC", except one reference to the working group Alvestrand Expires April 29, 2017 [Page 17] Internet-Draft WebRTC Transports October 2016 o Added reference to the httpbis "connect" protocol (being adopted by HTTPBIS) o Added reference to the ALPN header (being adopted by RTCWEB) o Added reference to the DART RTP document o Said explicitly that SCTP for data channels has a single DSCP codepoint A.7. Changes from -06 to -07 o Updated references o Removed reference to draft-hutton-rtcweb-nat-firewall- considerations A.8. Changes from -07 to -08 o Updated references o Deleted "bundle each media type (audio, video or data) into its own 5-tuple (bundling by media type)" from MUST support configuration, since JSEP does not have a means to negotiate this configuration A.9. Changes from -08 to -09 o Added a clarifying note about DTLS-SRTP and ICE interaction. A.10. Changes from -09 to -10 o Re-added references to proxy authentication lost in 07-08 transition (Bug #5) o Rearranged and rephrased text in section 4 about prioritization to reflect discussions in TSVWG. o Changed the "Connect" header to "ALPN", and updated reference. (Bug #6) A.11. Changes from -10 to -11 o Added a definition of the term "flow" used in the prioritization chapter o Changed the names of the four priority levels to conform to other specs. Alvestrand Expires April 29, 2017 [Page 18] Internet-Draft WebRTC Transports October 2016 A.12. Changes from -11 to -12 o Added a SHOULD NOT about using deprecated temporary IPv6 addresses. o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657 A.13. Changes from -12 to -13 o Clarify that the ALPN header needs to be sent. o Mentioned that RFC 7657 also talks about congestion control A.14. Changes from -13 to -14 o Add note about non-support for marking flows as interactive or non-interactive. A.15. Changes from -14 to -15 o Various text clarifications based on comments in Last Call and IESG review o Clarified that only non-deprecated IPv6 addresses are used o Described handling of downgrading of DSCP markings when blackholes are detected o Expanded acronyms in a new protocol list A.16. Changes from -15 to -16 These changes are done post IESG approval, and address IESG comments and other late comments. Issue numbers refer to https://github.com/ rtcweb-wg/rtcweb-transport/issues. o Moved RFC 4594, 7656 and -overview to normative (issue #28) o Changed the terms "client", "WebRTC implementation" and "WebRTC device" to consistently be "WebRTC endpoint", as defined in -overview. (issue #40) o Added a note mentioning TURN service discovery and RETURN (issue #42) o Added a note mentioning that rtp-usage requires circut breaker and congestion control (issue #43) Alvestrand Expires April 29, 2017 [Page 19] Internet-Draft WebRTC Transports October 2016 o Added mention of the "don't discard temporary IPv6 addresses that are in use" (issue #44) o Added a reference to draft-ietf-rmcat-coupled-cc (issue #46) A.17. Changes from -16 to -17 o Added an informative reference to the "DSCP blackholing" paper o Changed the reference for ICE from RFC 5245 to draft-ietf-ice- rfc5245bis Author's Address Harald Alvestrand Google Email: harald@alvestrand.no Alvestrand Expires April 29, 2017 [Page 20] ./draft-ietf-secevent-http-poll-12.txt0000644000764400076440000012535413675011017017123 0ustar iustyiusty Security Events Working Group A. Backman, Ed. Internet-Draft Amazon Intended status: Standards Track M. Jones, Ed. Expires: December 26, 2020 Microsoft M. Scurtescu Coinbase M. Ansari Cisco A. Nadalin Microsoft June 24, 2020 Poll-Based Security Event Token (SET) Delivery Using HTTP draft-ietf-secevent-http-poll-12 Abstract This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 26, 2020. Copyright Notice Copyright (c) 2020 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 Backman, et al. Expires December 26, 2020 [Page 1] Internet-Draft draft-ietf-secevent-http-poll June 2020 (https://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 and Overview . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Polling Delivery using HTTP . . . . . . . . . . . . . . . 4 2.2. Polling HTTP Request . . . . . . . . . . . . . . . . . . 5 2.3. Polling HTTP Response . . . . . . . . . . . . . . . . . . 6 2.4. Poll Request . . . . . . . . . . . . . . . . . . . . . . 6 2.4.1. Poll-Only Request . . . . . . . . . . . . . . . . . . 7 2.4.2. Acknowledge-Only Request . . . . . . . . . . . . . . 8 2.4.3. Poll with Acknowledgement . . . . . . . . . . . . . . 9 2.4.4. Poll with Acknowledgement and Errors . . . . . . . . 10 2.5. Poll Response . . . . . . . . . . . . . . . . . . . . . . 10 2.5.1. Poll Error Response . . . . . . . . . . . . . . . . . 12 2.6. Error Response Handling . . . . . . . . . . . . . . . . . 12 3. Authentication and Authorization . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.1. Authentication Using Signed SETs . . . . . . . . . . . . 14 4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 14 4.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 14 4.4. Access Token Considerations . . . . . . . . . . . . . . . 14 4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 14 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Unencrypted Transport Considerations . . . . . . . . 18 Appendix B. Other Streaming Specifications . . . . . . . . . . . 18 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction and Overview This specification defines how a stream of Security Event Tokens (SETs) [RFC8417] can be transmitted to an intended SET Recipient using HTTP [RFC7231] over TLS. The specification defines a method to Backman, et al. Expires December 26, 2020 [Page 2] Internet-Draft draft-ietf-secevent-http-poll June 2020 poll for SETs using HTTP POST. This is an alternative SET delivery method to the one defined in [I-D.ietf-secevent-http-push]. Poll-based SET delivery is intended for scenarios where all of the following apply: o The recipient of the SET is capable of making outbound HTTP requests. o The transmitter is capable of hosting a TLS-enabled HTTP endpoint that is accessible to the recipient. o The transmitter and recipient are willing to exchange data with one another. In some scenarios, either push-based or poll-based delivery could be used, and in others, only one of them would be applicable. A mechanism for exchanging configuration metadata such as endpoint URLs, cryptographic keys, and possible implementation constraints such as buffer size limitations between the transmitter and recipient is out of scope for this specification. How SETs are defined and the process by which security events are identified for SET Recipients are specified in [RFC8417]. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Throughout this document, all figures may contain spaces and extra line wrapping for readability and due to space limitations. 1.2. Definitions This specification utilizes terminology defined in [RFC8417] and [I-D.ietf-secevent-http-push]. 2. SET Delivery When a SET is available for a SET Recipient, the SET Transmitter queues the SET in a buffer so that a SET Recipient can poll for SETs using HTTP POST. Backman, et al. Expires December 26, 2020 [Page 3] Internet-Draft draft-ietf-secevent-http-poll June 2020 In poll-based SET delivery using HTTP over TLS, zero or more SETs are delivered in a JSON [RFC8259] document to a SET Recipient in response to an HTTP POST request to the SET Transmitter. Then in a following request, the SET Recipient acknowledges received SETs and can poll for more. All requests and responses are JSON documents and use a "Content-Type" of "application/json", as described in Section 2.1. After successful (acknowledged) SET delivery, SET Transmitters are not required to retain or record SETs for retransmission. Once a SET is acknowledged, the SET Recipient SHALL be responsible for retention, if needed. Transmitters may also discard undelivered SETs under deployment-specific conditions, such as if they have not been polled for over too long a period of time or if an excessive amount of storage is needed to retain them. Upon receiving a SET, the SET Recipient reads the SET and validates it in the manner described in Section 2 of [I-D.ietf-secevent-http-push]. The SET Recipient MUST acknowledge receipt to the SET Transmitter, and SHOULD do so in a timely fashion, as described in Section 2.4. The SET Recipient SHALL NOT use the event acknowledgement mechanism to report event errors other than those relating to the parsing and validation of the SET. 2.1. Polling Delivery using HTTP This method allows a SET Recipient to use HTTP POST (Section 4.3.3 of [RFC7231]) to acknowledge SETs and to check for and receive zero or more SETs. Requests MAY be made at a periodic interval (short polling) or requests MAY wait, pending availability of new SETs using long polling, per Section 2 of [RFC6202]. Note that short polling will result in retrieving zero or more SETs whereas long polling will typically result in retrieving one or more SETs unless a timeout occurs. The delivery of SETs in this method is facilitated by HTTP POST requests initiated by the SET Recipient in which: o The SET Recipient makes a request for available SETs using an HTTP POST to a pre-arranged endpoint provided by the SET Transmitter or, o after validating previously received SETs, the SET Recipient initiates another poll request using HTTP POST that includes acknowledgement of previous SETs and requests the next batch of SETs. The purpose of the acknowledgement is to inform the SET Transmitter that delivery has succeeded and redelivery is no longer required. Backman, et al. Expires December 26, 2020 [Page 4] Internet-Draft draft-ietf-secevent-http-poll June 2020 Before acknowledgement, SET Recipients validate the received SETs and retain them in a manner appropriate to the recipient's requirements. The level and method of retention of SETs by SET Recipients is out of scope of this specification. 2.2. Polling HTTP Request When initiating a poll request, the SET Recipient constructs a JSON document that consists of polling request parameters and SET acknowledgement parameters in the form of JSON objects. When making a request, the HTTP "Content-Type" header field is set to "application/json". The following JSON object members are used in a polling request: Request Processing Parameters maxEvents An OPTIONAL integer value indicating the maximum number of unacknowledged SETs to be returned. The SET Transmitter SHOULD NOT send more SETs than the specified maximum. If more than the maximum number of SETs are available, the SET Transmitter determines which to return first; the oldest SETs available MAY returned first, or another selection algorithm MAY be used, such as prioritizing SETs in some manner that makes sense for the use case. first. A value of "0" MAY be used by SET Recipients that would like to perform an acknowledge-only request. This enables the Recipient to use separate HTTP requests for acknowledgement and reception of SETs. If this parameter is omitted, no limit is placed on the number of SETs to be returned. returnImmediately An OPTIONAL JSON boolean value that indicates the SET Transmitter SHOULD return an immediate response even if no results are available (short polling). The default value is "false", which indicates the request is to be treated as an HTTP Long Poll, per Section 2 of [RFC6202]. The timeout for the request is part of the configuration between the participants, which is out of scope of this specification. SET Acknowledgment Parameters ack A JSON array of strings whose values are the "jti" [RFC7519] values of successfully received SETs that are being acknowledged. If there are no outstanding SETs to acknowledge, Backman, et al. Expires December 26, 2020 [Page 5] Internet-Draft draft-ietf-secevent-http-poll June 2020 this member is omitted or contains an empty array. Once a SET has been acknowledged, the SET Transmitter is released from any obligation to retain the SET. setErrs A JSON object with one or more members whose keys are the "jti" values of invalid SETs received. The values of these objects are themselves JSON objects that describe the errors detected using the "err" and "description" values specified in Section 2.6. If there are no outstanding SETs with errors to report, this member is omitted or contains an empty JSON object. 2.3. Polling HTTP Response In response to a poll request, the SET Transmitter checks for available SETs and responds with a JSON document containing the following JSON object members: sets A JSON object containing zero or more SETs being returned. Each member name is the "jti" of a SET to be delivered and its value is a JSON string representing the corresponding SET. If there are no outstanding SETs to be transmitted, the JSON object SHALL be empty. Note that both SETs being transmitted for the first time and SETs that are being re-transmitted after not having been acknowledged are communicated here. moreAvailable A JSON boolean value that indicates if more unacknowledged SETs are available to be returned. This member MAY be omitted, with the meaning being the same as including it with the boolean value "false". When making a response, the HTTP "Content-Type" header field is set to "application/json". 2.4. Poll Request The SET Recipient performs an HTTP POST (see Section 4.3.4 of [RFC7231]) to a pre-arranged polling endpoint URI to check for SETs that are available. Because the SET Recipient has no prior SETs to acknowledge, the "ack" and "setErrs" request parameters are omitted. After a period of time configured in an out-of-band manner between the SET Transmitter and Recipient, a SET Transmitter MAY redeliver SETs it has previously delivered. The SET Recipient SHOULD accept repeat SETs and acknowledge the SETs regardless of whether the Backman, et al. Expires December 26, 2020 [Page 6] Internet-Draft draft-ietf-secevent-http-poll June 2020 Recipient believes it has already acknowledged the SETs previously. A SET Transmitter MAY limit the number of times it attempts to deliver a SET. If the SET Recipient has received SETs from the SET Transmitter, the SET Recipient parses and validates that received SETs meet its own requirements and SHOULD acknowledge receipt in a timely fashion (e.g., seconds or minutes) so that the SET Transmitter can mark the SETs as received. SET Recipients SHOULD acknowledge receipt before taking any local actions based on the SETs to avoid unnecessary delay in acknowledgement, where possible. Poll requests have three variations: Poll-Only In which a SET Recipient asks for the next set of events where no previous SET deliveries are acknowledged (such as in the initial poll request). Acknowledge-Only In which a SET Recipient sets the "maxEvents" value to "0" along with "ack" and "setErrs" members indicating the SET Recipient is acknowledging previously received SETs and does not want to receive any new SETs in response to the request. Combined Acknowledge and Poll In which a SET Recipient is both acknowledging previously received SETs using the "ack" and "setErrs" members and will wait for the next group of SETs in the SET Transmitters response. 2.4.1. Poll-Only Request In the case where no SETs were received in a previous poll (see Figure 7), the SET Recipient simply polls without acknowledgement parameters ("ack" and "setErrs"). Backman, et al. Expires December 26, 2020 [Page 7] Internet-Draft draft-ietf-secevent-http-poll June 2020 The following is a non-normative example request made by a SET Recipient that has no outstanding SETs to acknowledge and is polling for available SETs at the endpoint "https://notify.idp.example.com/ Events": POST /Events HTTP/1.1 Host: notify.idp.example.com Content-Type: application/json { "returnImmediately": true } Figure 1: Example Initial Poll Request A SET Recipient can poll using default parameter values by passing an empty JSON object. The following is a non-normative example default poll request to the endpoint "https://notify.idp.example.com/Events": POST /Events HTTP/1.1 Host: notify.idp.example.com Content-Type: application/json {} Figure 2: Example Default Poll Request 2.4.2. Acknowledge-Only Request In this variation, the SET Recipient acknowledges previously received SETs and indicates it does not want to receive SETs in response by setting the "maxEvents" value to "0". This variation might be used, for instance, when a SET Recipient needs to acknowledge received SETs independently (e.g., on separate threads) from the process of receiving SETs. If the poll needs to return immediately, then "returnImmediately" MUST also be present with the value "true". If it is "false", then a long poll will still occur until an event is ready to be returned, even though no events will be returned. Backman, et al. Expires December 26, 2020 [Page 8] Internet-Draft draft-ietf-secevent-http-poll June 2020 The following is a non-normative example poll request with acknowledgement of SETs received (for example as shown in Figure 6): POST /Events HTTP/1.1 Host: notify.idp.example.com Content-Type: application/json { "ack": [ "4d3559ec67504aaba65d40b0363faad8", "3d0c3cf797584bd193bd0fb1bd4e7d30" ], "maxEvents": 0, "returnImmediately": true } Figure 3: Example Acknowledge-Only Request 2.4.3. Poll with Acknowledgement This variation allows a recipient thread to simultaneously acknowledge previously received SETs and wait for the next group of SETs in a single request. The following is a non-normative example poll with acknowledgement of the SETs received in Figure 6: POST /Events HTTP/1.1 Host: notify.idp.example.com Content-Type: application/json { "ack": [ "4d3559ec67504aaba65d40b0363faad8", "3d0c3cf797584bd193bd0fb1bd4e7d30" ], "returnImmediately": false } Figure 4: Example Poll with Acknowledgement and No Errors In the above acknowledgement, the SET Recipient has acknowledged receipt of two SETs and has indicated it wants to wait until the next SET is available. Backman, et al. Expires December 26, 2020 [Page 9] Internet-Draft draft-ietf-secevent-http-poll June 2020 2.4.4. Poll with Acknowledgement and Errors In the case where errors were detected in previously delivered SETs, the SET Recipient MAY use the "setErrs" member to communicate the errors in the following poll request. The following is a non-normative example of a response acknowledging one successfully received SET and one SET with an error from the two SETs received in Figure 6: POST /Events HTTP/1.1 Host: notify.idp.example.com Content-Language: en-US Content-Type: application/json { "ack": ["3d0c3cf797584bd193bd0fb1bd4e7d30"], "setErrs": { "4d3559ec67504aaba65d40b0363faad8": { "err": "authentication_failed", "description": "The SET could not be authenticated" } }, "returnImmediately": true } Figure 5: Example Poll Acknowledgement with Error 2.5. Poll Response In response to a valid poll request, the service provider MAY respond immediately if SETs are available to be delivered. If no SETs are available at the time of the request, the SET Transmitter SHALL delay responding until a SET is available or the timeout interval has elapsed unless the poll request parameter "returnImmediately" is present with the value "true". As described in Section 2.3, a JSON document is returned containing members including "sets", which SHALL contain zero or more SETs. Backman, et al. Expires December 26, 2020 [Page 10] Internet-Draft draft-ietf-secevent-http-poll June 2020 The following is a non-normative example response to the request shown in Section 2.4. This example shows two SETs being returned: HTTP/1.1 200 OK Content-Type: application/json { "sets": { "4d3559ec67504aaba65d40b0363faad8": "eyJhbGciOiJub25lIn0. eyJqdGkiOiI0ZDM1NTllYzY3NTA0YWFiYTY1ZDQwYjAzNjNmYWFkOCIsImlhdCI6MTQ 1ODQ5NjQwNCwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbIm h0dHBzOi8vc2NpbS5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M 2I3NzU0IiwiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIx ZDA4NjQxZDc2NzZlZTciXSwiZXZlbnRzIjp7InVybjppZXRmOnBhcmFtczpzY2ltOmV 2ZW50OmNyZWF0ZSI6eyJyZWYiOiJodHRwczovL3NjaW0uZXhhbXBsZS5jb20vVXNlcn MvNDRmNjE0MmRmOTZiZDZhYjYxZTc1MjFkOSIsImF0dHJpYnV0ZXMiOlsiaWQiLCJuY W1lIiwidXNlck5hbWUiLCJwYXNzd29yZCIsImVtYWlscyJdfX19.", "3d0c3cf797584bd193bd0fb1bd4e7d30": "eyJhbGciOiJub25lIn0. eyJqdGkiOiIzZDBjM2NmNzk3NTg0YmQxOTNiZDBmYjFiZDRlN2QzMCIsImlhdCI6MTQ 1ODQ5NjAyNSwiaXNzIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tIiwiYXVkIjpbIm h0dHBzOi8vamh1Yi5leGFtcGxlLmNvbS9GZWVkcy85OGQ1MjQ2MWZhNWJiYzg3OTU5M 2I3NzU0IiwiaHR0cHM6Ly9qaHViLmV4YW1wbGUuY29tL0ZlZWRzLzVkNzYwNDUxNmIx ZDA4NjQxZDc2NzZlZTciXSwic3ViIjoiaHR0cHM6Ly9zY2ltLmV4YW1wbGUuY29tL1V zZXJzLzQ0ZjYxNDJkZjk2YmQ2YWI2MWU3NTIxZDkiLCJldmVudHMiOnsidXJuOmlldG Y6cGFyYW1zOnNjaW06ZXZlbnQ6cGFzc3dvcmRSZXNldCI6eyJpZCI6IjQ0ZjYxNDJkZ jk2YmQ2YWI2MWU3NTIxZDkifSwiaHR0cHM6Ly9leGFtcGxlLmNvbS9zY2ltL2V2ZW50 L3Bhc3N3b3JkUmVzZXRFeHQiOnsicmVzZXRBdHRlbXB0cyI6NX19fQ." } } Figure 6: Example Poll Response In the above example, two SETs whose "jti" values are "4d3559ec67504aaba65d40b0363faad8" and "3d0c3cf797584bd193bd0fb1bd4e7d30" are delivered. Backman, et al. Expires December 26, 2020 [Page 11] Internet-Draft draft-ietf-secevent-http-poll June 2020 The following is a non-normative example response to the request shown in Section 2.4.1, which indicates that no new SETs or unacknowledged SETs are available: HTTP/1.1 200 OK Content-Type: application/json { "sets": {} } Figure 7: Example No SETs Poll Response Upon receiving the JSON document (e.g., as shown in Figure 6), the SET Recipient parses and verifies the received SETs and notifies the SET Transmitter of successfully received SETs and SETs with errors via the next poll request to the SET Transmitter, as described in Section 2.4.3 or Section 2.4.4. 2.5.1. Poll Error Response In the event of a general HTTP error condition in the context of processing a poll request, the service provider responds with the applicable HTTP Response Status Code, as defined in Section 6 of [RFC7231]. Service providers MAY respond to any invalid poll request with an HTTP Response Status Code of 400 (Bad Request) even when a more specific code might apply, for example if the service provider deemed that a more specific code presented an information disclosure risk. When no more specific code might apply, the service provider SHALL respond to an invalid poll request with an HTTP Status Code of 400. The response body for responses to invalid poll requests is left undefined, and its contents SHOULD be ignored. The following is a non-normative example of a response to an invalid poll request: HTTP/1.1 400 Bad Request Example Poll Error Response 2.6. Error Response Handling If a SET is invalid, error codes from the IANA "Security Event Token Delivery Error Codes" registry established by [I-D.ietf-secevent-http-push] are used in error responses. As Backman, et al. Expires December 26, 2020 [Page 12] Internet-Draft draft-ietf-secevent-http-poll June 2020 described in Section 2.3 of [I-D.ietf-secevent-http-push], an error response is a JSON object providing details about the error that includes the following name/value pairs: err A value from the IANA "Security Event Token Delivery Error Codes" registry that identifies the error. description A human-readable string that provides additional diagnostic information. When included as part of a batch of SETs, the above JSON is included as part of the "setErrs" member, as defined in Section 2.2 and Section 2.4.4. When the SET Recipient includes one or more error responses in a request to the SET Transmitter, it must also include in the request a "Content-Language" header field whose value indicates the language of the error descriptions included in the request. The method of language selection in the case when the SET Recipient can provide error messages in multiple languages is out of scope for this specification. 3. Authentication and Authorization The SET delivery method described in this specification is based upon HTTP over TLS [RFC2818] and standard HTTP authentication and authorization schemes, as per [RFC7235]. The TLS server certificate MUST be validated using DNS-ID [RFC6125] and/or DANE [RFC6698]. As per Section 4.1 of [RFC7235], a SET delivery endpoint SHALL indicate supported HTTP authentication schemes via the "WWW-Authenticate" header field when using HTTP authentication. Authorization for the eligibility to provide actionable SETs can be determined by using the identity of the SET Issuer, validating the identity of the SET Transmitter, or via other employed authentication methods. Likewise, the SET Transmitter may choose to validate the identity of the SET Recipient, perhaps using mutual TLS. Because SETs are not commands, SET Recipients are free to ignore SETs that are not of interest after acknowledging their receipt. 4. Security Considerations Backman, et al. Expires December 26, 2020 [Page 13] Internet-Draft draft-ietf-secevent-http-poll June 2020 4.1. Authentication Using Signed SETs JWS signed SETs can be used (see [RFC7515] and Section 5 of [RFC8417]) to enable the SET Recipient to validate that the SET Issuer is authorized to provide actionable SETs. 4.2. HTTP Considerations SET delivery depends on the use of Hypertext Transfer Protocol and is thus subject to the security considerations of HTTP Section 9 of [RFC7230] and its related specifications. 4.3. Confidentiality of SETs SETs may contain sensitive information, including Personally Identifiable Information (PII), or be distributed through third parties. In such cases, SET Transmitters and SET Recipients MUST protect the confidentiality of the SET contents. In some use cases, using TLS to secure the transmitted SETs will be sufficient. In other use cases, encrypting the SET as described in JWE [RFC7516] will also be required. The Event delivery endpoint MUST support at least TLS version 1.2 [RFC5246] and SHOULD support the newest version of TLS that meets its security requirements, which as of the time of this publication is TLS 1.3 [RFC8446]. The client MUST perform a TLS/SSL server certificate check using DNS-ID [RFC6125] and/or DANE [RFC6698]. How a SET Recipient determines the expected service identity to match the SET Transmitter's server certificate against is out of scope for this document. The implementation security considerations for TLS in "Recommendations for Secure Use of TLS and DTLS" [RFC7525] MUST be followed. 4.4. Access Token Considerations If HTTP Authentication is performed using OAuth access tokens [RFC6749], implementers MUST take into account the threats and countermeasures documented in Section 8 of [RFC7521]. 4.4.1. Bearer Token Considerations Transmitting Bearer tokens [RFC6750] using TLS helps prevent their interception. Bearer tokens SHOULD have a limited lifetime that can be determined directly or indirectly (e.g., by checking with a validation service) by the service provider. By expiring tokens, clients are forced to obtain a new token (which usually involves re-authentication) for continued authorized access. For example, in OAuth 2.0, a client MAY use an OAuth refresh token to obtain a new bearer token after Backman, et al. Expires December 26, 2020 [Page 14] Internet-Draft draft-ietf-secevent-http-poll June 2020 authenticating to an authorization server, per Section 6 of [RFC6749]. Implementations supporting OAuth bearer tokens need to factor in security considerations of this authorization method [RFC7521]. Since security is only as good as the weakest link, implementers also need to consider authentication choices coupled with OAuth bearer tokens. The security considerations of the default authentication method for OAuth bearer tokens, HTTP Basic, are well documented in [RFC7617], therefore implementers are encouraged to prefer stronger authentication methods. 5. Privacy Considerations SET Transmitters should attempt to deliver SETs that are targeted to the specific business and protocol needs of subscribers. When sharing personally identifiable information or information that is otherwise considered confidential to affected users, SET Transmitters and Recipients MUST have the appropriate legal agreements and user consent or terms of service in place. Furthermore, data that needs confidentiality protection MUST be encrypted, at least with TLS and sometimes also using JSON Web Encryption (JWE) [RFC7516]. In some cases, subject identifiers themselves may be considered sensitive information, such that their inclusion within a SET may be considered a violation of privacy. SET Issuers and SET Transmitters should consider the ramifications of sharing a particular subject identifier with a SET Recipient (e.g., whether doing so could enable correlation and/or de-anonymization of data) and choose appropriate subject identifiers for their use cases. 6. IANA Considerations This specification requires no IANA actions. 7. References 7.1. Normative References [I-D.ietf-secevent-http-push] Backman, A., Jones, M., Scurtescu, M., Ansari, M., and A. Nadalin, "Push-Based Security Event Token (SET) Delivery Using HTTP", draft-ietf-secevent-http-push-12 (work in progress), June 2020. Backman, et al. Expires December 26, 2020 [Page 15] Internet-Draft draft-ietf-secevent-http-poll June 2020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, . Backman, et al. Expires December 26, 2020 [Page 16] Internet-Draft draft-ietf-secevent-http-poll June 2020 [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 7.2. Informative References [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, DOI 10.17487/RFC6202, April 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [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, . Backman, et al. Expires December 26, 2020 [Page 17] Internet-Draft draft-ietf-secevent-http-poll June 2020 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . Appendix A. Unencrypted Transport Considerations Earlier versions of this specification made the use of TLS optional and described security and privacy considerations resulting from use of unencrypted HTTP as the underlying transport. When the working group decided to mandate usage HTTP over TLS, it also decided to preserve the description of these considerations in a non-normative manner. The considerations for using unencrypted HTTP with this protocol are the same as those described in Appendix A of [I-D.ietf-secevent-http-push], and are therefore not repeated here. Appendix B. Other Streaming Specifications [[ NOTE TO THE RFC EDITOR: This section to be removed prior to publication ]] A number of pub/sub, queuing, and streaming systems were reviewed as possible solutions or as input to the current draft. These are listed in Appendix B of [I-D.ietf-secevent-http-push], and are therefore not repeated here. Appendix C. Acknowledgments The editors would like to thank the members of the SCIM working group, which began discussions of provisioning events starting with draft-hunt-scim-notify-00 in 2015. We would like to thank Phil Hunt and the other the authors of draft-ietf-secevent-delivery-02, upon which this specification is based. We would like to thank the participants in the SecEvents working group for their contributions to this specification. Additionally, we would like to thank the following individuals for their reviews of the specification: Roman Danyliw, Martin Duke, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Warren Kumari, Barry Leiba, Mark Nottingham, Alvaro Retana, Yaron Sheffer, Valery Smyslov, Robert Sparks, Eric Vyncke, and Robert Wilton. Backman, et al. Expires December 26, 2020 [Page 18] Internet-Draft draft-ietf-secevent-http-poll June 2020 Appendix D. Change Log [[ to be removed by the RFC Editor before publication as an RFC ]] Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the following additions: o Renamed to "Poll-Based SET Token Delivery Using HTTP" o Removed references to the HTTP Push delivery method. Draft 01 - mbj: o Addressed problems identified in my 18-Jul-18 review message titled "Issues for both the Push and Poll Specs". o Changes to align terminology with RFC 8417, for instance, by using the already defined term SET Recipient rather than SET Receiver. o Applied editorial and minor normative corrections. o Updated Marius' contact information. o Begun eliminating redundancies between this specification and "Push-Based Security Event Token (SET) Delivery Using HTTP" [I-D.ietf-secevent-http-push], referencing, rather that duplicating common normative text. Draft 02 - mbj: o Removed vestigial language remaining from when the push and poll delivery methods were defined in a common specification. o Replaced remaining uses of the terms Event Transmitter and Event Recipient with the correct terms SET Transmitter and SET Recipient. o Removed uses of the unnecessary term "Event Stream". o Removed dependencies between the semantics of "maxEvents" and "returnImmediately". o Said that PII in SETs is to be encrypted with TLS, JWE, or both. o Corrected grammar and spelling errors. Draft 03 - mbj: Backman, et al. Expires December 26, 2020 [Page 19] Internet-Draft draft-ietf-secevent-http-poll June 2020 o Corrected uses of "attribute" to "member" when describing JSON objects. o Further alignment with the push draft. Draft 04 - AB + mbj o Referenced SET Transmitter definition in http-push. o Removed incorrect normative text regarding SET construction. o Consolidated general out-of-scope items under Introduction. o Removed unnecessary HTTP headers in examples and added Content- Type. o Added Content-Language requirement for error descriptions, aligning with http-push. o Stated that bearer tokens SHOULD have a limited lifetime. o Minor editorial fixes. Draft 05 - AB + mbj o Added normative text defining how to respond to invalid poll requests. o Addressed shepherd comments by Yaron Sheffer. Draft 06 - mbj o Addressed nits identified by the idnits tool. Draft 07 - mbj o Addressed area director review comments by Benjamin Kaduk. Draft 08 - mbj + AB o Corrected editorial nits. Draft 09 - AB o Addressed area director review comments by Benjamin Kaduk: * Added text clarifying that determining the SET Recipient's service identity is out of scope. Backman, et al. Expires December 26, 2020 [Page 20] Internet-Draft draft-ietf-secevent-http-poll June 2020 * Removed unelaborated reference to use of authentication to prevent DoS attacks. Draft 10 - mbj o Addressed SecDir review comments by Valery Smyslov on draft-ietf- secevent-http-push-10 that also applied here. o Addressed IETF last call comments by Mark Nottingham. o Addressed GenArt review comments by Robert Sparks. Draft 11 - mbj o Revised to unambiguously require the use of TLS, while preserving descriptions of precautions needed for non-TLS use in an appendix. Draft 12 - mbj o Addressed IESG comments. Authors' Addresses Annabelle Backman (editor) Amazon Email: richanna@amazon.com Michael B. Jones (editor) Microsoft Email: mbj@microsoft.com URI: https://self-issued.info/ Marius Scurtescu Coinbase Email: marius.scurtescu@coinbase.com Morteza Ansari Cisco Email: morteza.ansari@cisco.com Backman, et al. Expires December 26, 2020 [Page 21] Internet-Draft draft-ietf-secevent-http-poll June 2020 Anthony Nadalin Microsoft Email: tonynad@microsoft.com Backman, et al. Expires December 26, 2020 [Page 22] ./draft-ietf-secevent-http-push-14.txt0000644000764400076440000014222213675531571017143 0ustar iustyiusty Security Events Working Group A. Backman, Ed. Internet-Draft Amazon Intended status: Standards Track M. Jones, Ed. Expires: December 28, 2020 Microsoft M. Scurtescu Coinbase M. Ansari Cisco A. Nadalin Microsoft June 26, 2020 Push-Based Security Event Token (SET) Delivery Using HTTP draft-ietf-secevent-http-push-14 Abstract This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 28, 2020. Copyright Notice Copyright (c) 2020 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 Backman, et al. Expires December 28, 2020 [Page 1] Internet-Draft draft-ietf-secevent-http-push June 2020 (https://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 and Overview . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. SET Delivery . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Transmitting a SET . . . . . . . . . . . . . . . . . . . 5 2.2. Success Response . . . . . . . . . . . . . . . . . . . . 6 2.3. Failure Response . . . . . . . . . . . . . . . . . . . . 6 2.4. Security Event Token Delivery Error Codes . . . . . . . . 8 3. Authentication and Authorization . . . . . . . . . . . . . . 9 4. Delivery Reliability . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. Authentication Using Signed SETs . . . . . . . . . . . . 10 5.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 10 5.3. Confidentiality of SETs . . . . . . . . . . . . . . . . . 10 5.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 5.5. Authenticating Persisted SETs . . . . . . . . . . . . . . 11 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.1. Security Event Token Delivery Error Codes . . . . . . . . 12 7.1.1. Registration Template . . . . . . . . . . . . . . . . 13 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Unencrypted Transport Considerations . . . . . . . . 16 Appendix B. Other Streaming Specifications . . . . . . . . . . . 17 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction and Overview This specification defines a mechanism by which a transmitter of a Security Event Token (SET) [RFC8417] can deliver the SET to an intended SET Recipient via HTTP POST [RFC7231] over TLS. This is an alternative SET delivery method to the one defined in [I-D.ietf-secevent-http-poll]. Backman, et al. Expires December 28, 2020 [Page 2] Internet-Draft draft-ietf-secevent-http-push June 2020 Push-based SET delivery over HTTP POST is intended for scenarios where all of the following apply: o The transmitter of the SET is capable of making outbound HTTP requests. o The recipient is capable of hosting a TLS-enabled HTTP endpoint that is accessible to the transmitter. o The transmitter and recipient are willing to exchange data with one another. In some scenarios, either push-based or poll-based delivery could be used, and in others, only one of them would be applicable. A mechanism for exchanging configuration metadata such as endpoint URLs, cryptographic keys, and possible implementation constraints such as buffer size limitations between the transmitter and recipient is out of scope for this specification. How SETs are defined and the process by which security events are identified for SET Recipients are specified in [RFC8417]. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Throughout this document, all figures may contain spaces and extra line wrapping for readability and due to space limitations. 1.2. Definitions This specification utilizes the following terms defined in [RFC8417]: "Security Event Token (SET)", "SET Issuer", "SET Recipient", and "Event Payload", as well as the term defined below: SET Transmitter An entity that delivers SETs in its possession to one or more SET Recipients. 2. SET Delivery To deliver a SET to a given SET Recipient, the SET Transmitter makes a SET transmission request to the SET Recipient, with the SET itself contained within the request. The SET Recipient replies to this request with a response either acknowledging successful transmission Backman, et al. Expires December 28, 2020 [Page 3] Internet-Draft draft-ietf-secevent-http-push June 2020 of the SET or indicating that an error occurred while receiving, parsing, and/or validating the SET. Upon receipt of a SET, the SET Recipient SHALL validate that all of the following are true: o The SET Recipient can parse the SET. o The SET is authentic (i.e., it was issued by the issuer specified within the SET, and if signed, was signed by a key belonging to the issuer). o The SET Recipient is identified as an intended audience of the SET. o The SET Issuer is recognized as an issuer that the SET Recipient is willing to receive SETs from (e.g., the issuer is listed as allowed by the SET Recipient). o The SET Recipient is willing to accept this SET from this SET Transmitter (e.g., the SET Transmitter is expected to send SETs with the issuer and subject of the SET in question). The mechanisms by which the SET Recipient performs this validation are out of scope for this document. SET parsing, issuer identification, and audience identification are defined in [RFC8417]. The mechanism for validating the authenticity of a SET is deployment specific, and may vary depending on the authentication mechanisms in use, and whether the SET is signed and/or encrypted (See Section 3). SET Transmitters MAY transmit SETs issued by another entity. The SET Recipient may accept or reject (i.e., return an error response such as "access_denied") a SET at its own discretion. The SET Recipient persists the SET in a way that is sufficient to meet the SET Recipient's own reliability requirements. The level and method of retention of SETs by SET Recipients is out of scope of this specification. Once the SET has been validated and persisted, the SET Recipient SHOULD immediately return a response indicating that the SET was successfully delivered. The SET Recipient SHOULD NOT perform further processing of the SET beyond the required validation steps prior to sending this response. Any additional steps SHOULD be executed asynchronously from delivery to minimize the time the SET Transmitter is waiting for a response. The SET Transmitter MAY transmit the same SET to the SET Recipient multiple times, regardless of the response from the SET Recipient. The SET Recipient MUST respond as it would if the SET had not been Backman, et al. Expires December 28, 2020 [Page 4] Internet-Draft draft-ietf-secevent-http-push June 2020 previously received by the SET Recipient. The SET Recipient MUST NOT expect or depend on a SET Transmitter to re-transmit a SET or otherwise make a SET available to the SET Recipient once the SET Recipient acknowledges that it was received successfully. The SET Transmitter should not re-transmit a SET unless the SET Transmitter suspects that previous transmissions may have failed due to potentially recoverable errors (such as network outage or temporary service interruption at either the SET Transmitter or SET Recipient). In all other cases, the SET Transmitter SHOULD NOT re- transmit a SET. The SET Transmitter SHOULD delay retransmission for an appropriate amount of time to avoid overwhelming the SET Recipient (see Section 4). 2.1. Transmitting a SET To transmit a SET to a SET Recipient, the SET Transmitter makes an HTTP POST request to a TLS-enabled HTTP endpoint provided by the SET Recipient. The "Content-Type" header field of this request MUST be "application/secevent+jwt" as defined in Sections 2.3 and 7.2 of [RFC8417], and the "Accept" header field MUST be "application/json". The request body MUST consist of the SET itself, represented as a JWT [RFC7519]. The SET Transmitter MAY include in the request an "Accept-Language" header field to indicate to the SET Recipient the preferred language(s) in which to receive error messages. The mechanisms by which the SET Transmitter determines the HTTP endpoint to use when transmitting a SET to a given SET Recipient are not defined by this specification and are deployment specific. Backman, et al. Expires December 28, 2020 [Page 5] Internet-Draft draft-ietf-secevent-http-push June 2020 The following is a non-normative example of a SET transmission request: POST /Events HTTP/1.1 Host: notify.rp.example.com Accept: application/json Accept-Language: en-US, en;q=0.5 Content-Type: application/secevent+jwt eyJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJIUzI1NiJ9Cg . eyJpc3MiOiJodHRwczovL2lkcC5leGFtcGxlLmNvbS8iLCJqdGkiOiI3NTZFNjk 3MTc1NjUyMDY5NjQ2NTZFNzQ2OTY2Njk2NTcyIiwiaWF0IjoxNTA4MTg0ODQ1LC JhdWQiOiI2MzZDNjk2NTZFNzQ1RjY5NjQiLCJldmVudHMiOnsiaHR0cHM6Ly9zY 2hlbWFzLm9wZW5pZC5uZXQvc2VjZXZlbnQvcmlzYy9ldmVudC10eXBlL2FjY291 bnQtZGlzYWJsZWQiOnsic3ViamVjdCI6eyJzdWJqZWN0X3R5cGUiOiJpc3Mtc3V iIiwiaXNzIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5jb20vIiwic3ViIjoiNzM3NT YyNkE2NTYzNzQifSwicmVhc29uIjoiaGlqYWNraW5nIn19fQ . Y4rXxMD406P2edv00cr9Wf3_XwNtLjB9n-jTqN1_lLc Figure 1: Example SET Transmission Request 2.2. Success Response If the SET is determined to be valid, the SET Recipient SHALL acknowledge successful transmission by responding with HTTP Response Status Code 202 (Accepted) (see Section 6.3.3 of [RFC7231]). The body of the response MUST be empty. The following is a non-normative example of a successful receipt of a SET. HTTP/1.1 202 Accepted Figure 2: Example Successful Delivery Response 2.3. Failure Response In the event of a general HTTP error condition, the SET Recipient responds with the applicable HTTP Status Code, as defined in Section 6 of [RFC7231]. When the SET Recipient detects an error parsing, validating, or authenticating a SET transmitted in a SET Transmission Request, the SET Recipient SHALL respond with an HTTP Response Status Code of 400 (Bad Request). The "Content-Type" header field of this response MUST Backman, et al. Expires December 28, 2020 [Page 6] Internet-Draft draft-ietf-secevent-http-push June 2020 be "application/json", and the body MUST be a UTF-8 encoded JSON [RFC8259] object containing the following name/value pairs: err A Security Event Token Error Code (see Section 2.4). description A UTF-8 string containing a human-readable description of the error that may provide additional diagnostic information. The exact content of this field is implementation specific. The response MUST include a "Content-Language" header field, whose value indicates the language of the error descriptions included in the response body. If the SET Recipient can provide error descriptions in multiple languages, they SHOULD choose the language to use according to the value of the "Accept-Language" header field sent by the SET Transmitter in the transmission request, as described in Section 5.3.5 of [RFC7231]. If the SET Transmitter did not send an "Accept-Language" header field, or if the SET Recipient does not support any of the languages included in the header field, the SET Recipient MUST respond with messages that are understandable by an English-speaking person, as described in Section 4.5 of [RFC2277]. The following is a non-normative example error response indicating that the key used to encrypt the SET has been revoked. HTTP/1.1 400 Bad Request Content-Language: en-US Content-Type: application/json { "err": "invalid_key", "description": "Key ID 12345 has been revoked." } Figure 3: Example Error Response (invalid_key) The following is a non-normative example error response indicating that the access token included in the request is expired. HTTP/1.1 400 Bad Request Content-Language: en-US Content-Type: application/json { "err": "authentication_failed", "description": "Access token has expired." } Figure 4: Example Error Response (authentication_failed) Backman, et al. Expires December 28, 2020 [Page 7] Internet-Draft draft-ietf-secevent-http-push June 2020 The following is a non-normative example error response indicating that the SET Receiver is not willing to accept SETs issued by the specified issuer from this particular SET Transmitter. HTTP/1.1 400 Bad Request Content-Language: en-US Content-Type: application/json { "err": "invalid_issuer", "description": "Not authorized for issuer https://iss.example.com/." } Figure 5: Example Error Response (access_denied) 2.4. Security Event Token Delivery Error Codes Security Event Token Delivery Error Codes are strings that identify a specific category of error that may occur when parsing or validating a SET. Every Security Event Token Delivery Error Code MUST have a unique name registered in the IANA "Security Event Token Delivery Error Codes" registry established by Section 7.1. The following table presents the initial set of Error Codes that are registered in the IANA "Security Event Token Delivery Error Codes" registry: Backman, et al. Expires December 28, 2020 [Page 8] Internet-Draft draft-ietf-secevent-http-push June 2020 +-----------------------+-------------------------------------------+ | Error Code | Description | +-----------------------+-------------------------------------------+ | invalid_request | The request body cannot be parsed as a | | | SET, or the Event Payload within the SET | | | does not conform to the event's | | | definition. | | invalid_key | One or more keys used to encrypt or sign | | | the SET is invalid or otherwise | | | unacceptable to the SET Recipient | | | (expired, revoked, failed certificate | | | validation, etc.). | | invalid_issuer | The SET issuer is invalid for the SET | | | Recipient. | | invalid_audience | The SET audience does not correspond to | | | the SET Recipient. | | authentication_failed | The SET Recipient could not authenticate | | | the SET Transmitter. | | access_denied | The SET Transmitter is not authorized to | | | transmit the SET to the SET Recipient. | +-----------------------+-------------------------------------------+ Table 1: SET Delivery Error Codes Other Error Codes may also be received, as the set of Error Codes is extensible via the IANA "Security Event Token Delivery Error Codes" registry established in Section 7.1. 3. Authentication and Authorization The SET delivery method described in this specification is based upon HTTP over TLS [RFC2818] and standard HTTP authentication and authorization schemes, as per [RFC7235]. The TLS server certificate MUST be validated using DNS-ID [RFC6125] and/or DANE [RFC6698]. Authorization for the eligibility to provide actionable SETs can be determined by using the identity of the SET Issuer, the identity of the SET Transmitter, perhaps using mutual TLS, or via other employed authentication methods. Because SETs are not commands, SET Recipients are free to ignore SETs that are not of interest. 4. Delivery Reliability Delivery reliability requirements may vary depending upon the use cases. This specification defines the response from the SET Recipient in such a way as to provide the SET Transmitter with the information necessary to determine what further action is required, if any, in order to meet their requirements. SET Transmitters with Backman, et al. Expires December 28, 2020 [Page 9] Internet-Draft draft-ietf-secevent-http-push June 2020 high reliability requirements may be tempted to always retry failed transmissions. However, it should be noted that for many types of SET delivery errors, a retry is extremely unlikely to be successful. For example, "invalid_request" indicates a structural error in the content of the request body that is likely to remain when re- transmitting the same SET. Others such as "access_denied" may be transient, for example if the SET Transmitter refreshes expired credentials prior to re-transmission. The SET Transmitter may be unaware of whether or not a SET has been delivered to a SET Recipient. For example, a network interruption could prevent the SET Transmitter from receiving the success response, or a service outage could prevent the SET Transmitter from recording the fact that the SET was delivered. It is left to the implementer to decide how to handle such cases, based on their requirements. For example, it may be appropriate for the SET Transmitter to re-transmit the SET to the SET Recipient, erring on the side of guaranteeing delivery, or it may be appropriate to assume delivery was successful, erring on the side of not spending resources re-transmitting previously delivered SETs. Other options, such as sending the SET to a "dead letter queue" for manual examination may also be appropriate. Implementers SHOULD evaluate the reliability requirements of their use cases and the impact of various retry mechanisms and re- transmission policies on the performance of their systems to determine an appropriate strategy for handling various error conditions. 5. Security Considerations 5.1. Authentication Using Signed SETs JWS signed SETs can be used (see [RFC7515] and Section 5 of [RFC8417]) to enable the SET Recipient to validate that the SET Issuer is authorized to provide actionable SETs. 5.2. HTTP Considerations SET delivery depends on the use of Hypertext Transfer Protocol and is thus subject to the security considerations of HTTP Section 9 of [RFC7230] and its related specifications. 5.3. Confidentiality of SETs SETs may contain sensitive information, including Personally Identifiable Information (PII), or be distributed through third parties. In such cases, SET Transmitters and SET Recipients MUST Backman, et al. Expires December 28, 2020 [Page 10] Internet-Draft draft-ietf-secevent-http-push June 2020 protect the confidentiality of the SET contents. TLS MUST be used to secure the transmitted SETs. In some use cases, encrypting the SET as described in JWE [RFC7516] will also be required. The Event delivery endpoint MUST support at least TLS version 1.2 [RFC5246] and SHOULD support the newest version of TLS that meets its security requirements, which as of the time of this publication is TLS 1.3 [RFC8446]. The client MUST perform a TLS/SSL server certificate check using DNS-ID [RFC6125] and/or DANE [RFC6698]. How a SET Transmitter determines the expected service identity to match the SET Recipient's server certificate against is out of scope for this document. The implementation security considerations for TLS in "Recommendations for Secure Use of TLS and DTLS" [RFC7525] MUST be followed. 5.4. Denial of Service The SET Recipient may be vulnerable to a denial-of-service attack where a malicious party makes a high volume of requests containing invalid SETs, causing the endpoint to expend significant resources on cryptographic operations that are bound to fail. This may be mitigated by authenticating SET Transmitters with a mechanism such as mutual TLS. Rate-limiting problematic transmitters is also a possible means of mitigation. 5.5. Authenticating Persisted SETs At the time of receipt, the SET Recipient can rely upon TLS mechanisms, HTTP authentication methods, and/or other context from the transmission request to authenticate the SET Transmitter and validate the authenticity of the SET. However, this context is typically unavailable to systems to which the SET Recipient forwards the SET, or to systems that retrieve the SET from storage. If the SET Recipient requires the ability to validate SET authenticity outside of the context of the transmission request, then the SET Recipient SHOULD ensure that such SETs have been signed in accordance with [RFC7515]. Needed context could also be stored with the SET and retrieved with it. 6. Privacy Considerations SET Transmitters should attempt to deliver SETs that are targeted to the specific business and protocol needs of subscribers. When sharing personally identifiable information or information that is otherwise considered confidential to affected users, SET Transmitters and Recipients MUST have the appropriate legal agreements and user consent or terms of service in place. Furthermore, data that needs confidentiality protection MUST be Backman, et al. Expires December 28, 2020 [Page 11] Internet-Draft draft-ietf-secevent-http-push June 2020 encrypted, at least with TLS and sometimes also using JSON Web Encryption (JWE) [RFC7516]. In some cases, subject identifiers themselves may be considered sensitive information, such that their inclusion within a SET may be considered a violation of privacy. SET Issuers and SET Transmitters should consider the ramifications of sharing a particular subject identifier with a SET Recipient (e.g., whether doing so could enable correlation and/or de-anonymization of data) and choose appropriate subject identifiers for their use cases. 7. IANA Considerations 7.1. Security Event Token Delivery Error Codes This document defines Security Event Token Delivery Error Codes, for which IANA is asked to create and maintain a new registry titled "Security Event Token Delivery Error Codes". Initial values for the Security Event Token Delivery Error Codes registry are defined in Table 1 and registered below. Future assignments are to be made through the Specification Required registration policy ([RFC8126]) and shall follow the template below. Error Codes are intended to be interpreted by automated systems, and therefore SHOULD identify classes of errors to which an automated system could respond in a meaningfully distinct way (e.g., by refreshing authentication credentials and retrying the request). Error Code names are case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear. It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts. Backman, et al. Expires December 28, 2020 [Page 12] Internet-Draft draft-ietf-secevent-http-push June 2020 7.1.1. Registration Template Error Code The name of the Security Event Token Delivery Error Code, as described in Section 2.4. The name MUST be a case-sensitive ASCII string consisting only of letters, digits, and underscore; these are the characters whose codes fall within the inclusive ranges 0x30-39, 0x41-5A, 0x5F and 0x61-7A. Description A brief human-readable description of the Security Event Token Delivery Error Code. Change Controller For error codes registered by the IETF or its working groups, list "IETF". For all other error codes, list the name of the party responsible for the registration. Contact information such as mailing address, email address, or phone number may also be provided. Defining Document(s) A reference to the document or documents that define the Security Event Token Delivery Error Code. The definition MUST specify the name and description of the error code and explain under what circumstances the error code may be used. URIs that can be used to retrieve copies of each document at no cost SHOULD be included. 7.1.2. Initial Registry Contents Error Code: invalid_request Description: The request body cannot be parsed as a SET or the event payload within the SET does not conform to the event's definition. Change Controller: IETF Defining Document(s): Section 2.4 of [[ this specification ]] Error Code: invalid_key Description: One or more keys used to encrypt or sign the SET is invalid or otherwise unacceptable to the SET Recipient (expired, revoked, failed certificate validation, etc.). Change Controller: IETF Defining Document(s): Section 2.4 of [[ this specification ]] Error Code: invalid_issuer Description: The SET issuer is invalid for the SET Recipient. Change Controller: IETF Defining Document(s): Section 2.4 of [[ this specification ]] Backman, et al. Expires December 28, 2020 [Page 13] Internet-Draft draft-ietf-secevent-http-push June 2020 Error Code: invalid_audience Description: The SET audience does not correspond to the SET Recipient. Change Controller: IETF Defining Document(s): Section 2.4 of [[ this specification ]] Error Code: authentication_failed Description: The SET Recipient could not authenticate the SET Transmitter. Change Controller: IETF Defining Document(s): Section 2.4 of [[ this specification ]] Error Code: access_denied Description: The SET Transmitter is not authorized to transmit the SET to the SET Recipient. Change Controller: IETF Defining Document(s): Section 2.4 of [[ this specification ]] 8. References 8.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, . [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . Backman, et al. Expires December 28, 2020 [Page 14] Internet-Draft draft-ietf-secevent-http-push June 2020 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [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, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Backman, et al. Expires December 28, 2020 [Page 15] Internet-Draft draft-ietf-secevent-http-push June 2020 [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 8.2. Informative References [I-D.ietf-secevent-http-poll] Backman, A., Jones, M., Scurtescu, M., Ansari, M., and A. Nadalin, "Poll-Based Security Event Token (SET) Delivery Using HTTP", draft-ietf-secevent-http-poll-12 (work in progress), June 2020. [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, . Appendix A. Unencrypted Transport Considerations Earlier versions of this specification made the use of TLS optional and described security and privacy considerations resulting from use of unencrypted HTTP as the underlying transport. When the working group decided to mandate usage HTTP over TLS, it also decided to preserve the description of these considerations in this non- normative appendix. SETs may contain sensitive information that is considered Personally Identifiable Information (PII). In such cases, SET Transmitters and SET Recipients MUST protect the confidentiality of the SET contents. When TLS is not used, this means that the SET MUST be encrypted as described in JWE [RFC7516]. If SETs were allowed to be transmitted over unencrypted channels, some privacy-sensitive information about them might leak, even though the SETs themselves are encrypted. For instance, an attacker may be able to determine whether or not a SET was accepted and the reason for its rejection or may be able to derive information from being able to observe the size of the encrypted SET. (Note that even when TLS is utilized, some information leakage is still possible; message padding algorithms to prevent side channels remain an open research topic.) Backman, et al. Expires December 28, 2020 [Page 16] Internet-Draft draft-ietf-secevent-http-push June 2020 Appendix B. Other Streaming Specifications [[ NOTE TO THE RFC EDITOR: This section to be removed prior to publication ]] The following pub/sub, queuing, and streaming systems were reviewed as possible solutions or as input to the current draft: Poll-Based Security Event Token (SET) Delivery Using HTTP In addition to this specification, the WG is defining a polling-based SET delivery protocol. That protocol [I-D.ietf-secevent-http-poll] describes it as: This specification defines how a series of Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance. XMPP Events The WG considered XMPP Events and their ability to provide a single messaging solution without the need for both polling and push modes. The feeling was the size and methodology of XMPP was too far apart from the current capabilities of the SECEVENTs community, which focuses in on HTTP based service delivery and authorization. Amazon Simple Notification Service Simple Notification Service is a pub/sub messaging product from AWS. SNS supports a variety of subscriber types: HTTP/HTTPS endpoints, AWS Lambda functions, email addresses (as JSON or plain text), phone numbers (via SMS), and AWS SQS standard queues. It does not directly support pull, but subscribers can get the pull model by creating an SQS queue and subscribing it to the topic. Note that this puts the cost of pull support back onto the subscriber, just as it is in the push model. It is not clear that one way is strictly better than the other; larger, sophisticated developers may be happy to own message persistence so they can have their own internal delivery guarantees. The long tail of OIDC clients may not care about that or may fail to get it right. Regardless, I think we can learn something from the Delivery Policies supported by SNS, as well as the delivery controls that SQS offers (e.g., Visibility Timeout, Dead-Letter Queues). I am not suggesting that we need all of these things in the spec, but they give an idea of what features people have found useful. Other information: Backman, et al. Expires December 28, 2020 [Page 17] Internet-Draft draft-ietf-secevent-http-push June 2020 o API Reference: http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ APIReference/Welcome.html o Visibility Timeouts: http://docs.aws.amazon.com/AWSSimpleQueueService/latest/ SQSDeveloperGuide/sqs-visibility-timeout.html Apache Kafka Apache Kafka is an Apache open source project based upon TCP for distributed streaming. It prescribes some interesting general- purpose features that seem to extend far beyond the simpler streaming model that SECEVENTs is after. A comment from MS has been that Kafka does an acknowledge with poll combination event which seems to be a performance advantage. See: https://kafka.apache.org/intro Google Pub/Sub The Google Pub Sub system favors a model whereby polling and acknowledgement of events is done with separate endpoints and as separate functions. Information: o Cloud Overview - https://cloud.google.com/pubsub/ o Subscriber Overview - https://cloud.google.com/pubsub/docs/ subscriber o Subscriber Pull(poll) - https://cloud.google.com/pubsub/docs/pull Appendix C. Acknowledgments The editors would like to thank the members of the SCIM working group, which began discussions of provisioning events starting with draft-hunt-scim-notify-00 in 2015. We would like to thank Phil Hunt and the other authors of draft-ietf-secevent-delivery-02, upon which this specification is based. We would like to thank the participants in the SecEvents working group for their contributions to this specification. Additionally, we would like to thank the following individuals for their reviews of the specification: Joe Clarke, Roman Danyliw, Vijay Gurbani, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Barry Leiba, Yaron Sheffer, Robert Sparks, Valery Smyslov, Eric Vyncke, and Robert Wilton. Backman, et al. Expires December 28, 2020 [Page 18] Internet-Draft draft-ietf-secevent-http-push June 2020 Appendix D. Change Log [[ NOTE TO THE RFC EDITOR: This section to be removed prior to publication ]] Draft 00 - AB - Based on draft-ietf-secevent-delivery-02 with the following changes: o Renamed to "Push-Based SET Token Delivery Using HTTP" o Removed references to the HTTP Polling delivery method. o Removed informative reference to RFC6202. Draft 01 - AB: o Fixed area and workgroup to match secevent. o Removed unused definitions and definitions already covered by SET. o Renamed Event Transmitter and Event Receiver to SET Transmitter and SET Receiver, respectively. o Added IANA registry for SET Delivery Error Codes. o Removed enumeration of HTTP authentication methods. o Removed generally applicable guidance for HTTP, authorization tokens, and bearer tokens. o Moved guidance for using authentication methods as DoS protection to Security Considerations. o Removed redundant instruction to use WWW-Authenticate header. o Removed further generally applicable guidance for authorization tokens. o Removed bearer token from example delivery request, and text referencing it. o Broke delivery method description into separate request/response sections. o Added missing empty line between headers and body in example request. o Removed inapplicable notes about example formatting. Backman, et al. Expires December 28, 2020 [Page 19] Internet-Draft draft-ietf-secevent-http-push June 2020 o Removed text about SET creation and handling. o Removed duplication in protocol description. o Added "non-normative example" text to example transmission request. o Fixed inconsistencies in use of Error Code term. Draft 02 - AB: o Rewrote abstract and introduction. o Rewrote definitions for SET Transmitter, SET Receiver. o Renamed Event Delivery section to SET Delivery. o Readability edits to Success Response and Failure Response sections. o Consolidated definition of error response under Failure Response section. o Removed Event Delivery Process section and moved its content to parent section. o Readability edits to SET Delivery section and its subsections. o Added callout that SET Receiver HTTP endpoint configuration is out-of-scope. o Added callout that SET verification mechanisms are out-of-scope. o Added retry guidance, notes regarding delivery reliability requirements. o Added guidance around using JWS and/or JWE to authenticate persisted SETs. Draft 03 - mbj: o Addressed problems identified in my 18-Jul-18 review message titled "Issues for both the Push and Poll Specs". o Changes to align terminology with RFC 8417, for instance, by using the already defined term SET Recipient rather than SET Receiver. o Applied editorial and minor normative corrections. Backman, et al. Expires December 28, 2020 [Page 20] Internet-Draft draft-ietf-secevent-http-push June 2020 o Updated Marius' contact information. Draft 04 - AB: o Replaced Error Codes with smaller set of meaningfully differentiated codes. o Added more error response examples. o Removed un-referenced normative references. o Added normative reference to JSON in error response definition. o Added text clarifying that the value of the "description" attribute in error responses is implementation specific. o Added requirement that error descriptions and responses are UTF-8 encoded. o Added error description language preferences and specification via "Accept-Language" and "Content-Language" headers. o Added "recognized issuer" validation requirement in section 2. o Added timeouts as an acceptable reason to resend a SET in section 2. o Edited text in section 1 to clarify that configuration is out of scope. o Made minor editorial corrections. Draft 05 - AB: o Made minor editorial corrections. o Updated example request with a correct SET header and signature. o Revised TLS guidance to allow implementers to provide confidentiality protection via JWE. o Revised TLS guidance to require *at least* TLS 1.2. o Revised TLS guidance to recommend supporting the newest version of TLS that meets security requirements. o Revised SET Delivery Error Code format to allow the same set of characters as is allowed in error codes in RFC6749. Backman, et al. Expires December 28, 2020 [Page 21] Internet-Draft draft-ietf-secevent-http-push June 2020 o Added mention of HTTP Poll spec to list of other streaming specs in appendix. o Added validation step requiring SET Recipient to verify that the SET is one which the SET Transmitter is expected to send to the SET Recipient. o Changed responding to errors with an appropriate HTTP status code from optional to recommended. o Changed Error Codes registry change policy from Expert Review to First Come First Served; added guidance that error codes are meant to be consumed by automated systems. o Added text making clear that it is up to SET Recipients whether or not they will accept SETs where the SET Issuer is different from the SET Transmitter. o Reworded guidance around signing and/or encrypting SETs for integrity protection. o Renamed TLS "Support Considerations" section to "Confidentiality of SETs". o Reworded guidance around subject identifier selection and privacy concerns. Draft 06 - mbj, MS: o Made minor editorial corrections. o Updated to indicate that failure response should be returned if errors occur in authenticating the SET. o Updated reference for JSON from RFC 7159 to RFC 8259. o Fixed Authentication Using Signed SETs to indicate the SET Transmitter must be authorized to deliver the SET, not the SET Issuer. o Fixed Authenticating Persisted SETs to put the responsibility for ensuring the SET is signed on the SET Recipient. o Fixed error code format definition to match error codes defined in doc. Draft 07 - AB: Backman, et al. Expires December 28, 2020 [Page 22] Internet-Draft draft-ietf-secevent-http-push June 2020 o Made minor editorial corrections. o Removed "SET Recipient" definition and added explicit list of terms used from RFC8417. Draft 08 - mbj o Addressed area director review comments by Benjamin Kaduk. Draft 09 - mbj + AB o Corrected editorial nits. Draft 10 - AB o Addressed area director review comments by Benjamin Kaduk: * Added reference to 8417 as definition document for SETs. * Added text clarifying that determining the SET Recipient's service identity is out of scope. * Added normative recommendation for transmitters to target SETs to specific business needs of subscribers. * Minor editorial corrections. Draft 11 - mbj o Addressed SecDir review comments by Valery Smyslov. o Addressed OpsDir review comments by Joe Clarke. o Addressed GenArt review comments by Vijay Gurbani. Draft 12 - mbj o Revised to unambiguously require the use of TLS, while preserving descriptions of precautions needed for non-TLS use in an appendix. Draft 13 - mbj o Addressed IESG comments. Draft 14 - AB o Revised normative requirements for SET re-transmission to clarify "at least once" delivery expectiations. Backman, et al. Expires December 28, 2020 [Page 23] Internet-Draft draft-ietf-secevent-http-push June 2020 o Added non-normative text to Section 4 - Delivery Reliability describing conditions where re-transmission of successfully delivered SETs may occur. Authors' Addresses Annabelle Backman (editor) Amazon Email: richanna@amazon.com Michael B. Jones (editor) Microsoft Email: mbj@microsoft.com URI: https://self-issued.info/ Marius Scurtescu Coinbase Email: marius.scurtescu@coinbase.com Morteza Ansari Cisco Email: morteza.ansari@cisco.com Anthony Nadalin Microsoft Email: tonynad@microsoft.com Backman, et al. Expires December 28, 2020 [Page 24] ./draft-ietf-sipbrandy-rtpsec-08.txt0000644000764400076440000010477113460440346016667 0ustar iustyiusty Network Working Group J. Peterson Internet-Draft Neustar Intended status: Best Current Practice R. Barnes Expires: October 27, 2019 Cisco R. Housley Vigil Security April 25, 2019 Best Practices for Securing RTP Media Signaled with SIP draft-ietf-sipbrandy-rtpsec-08 Abstract Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 27, 2019. Copyright Notice Copyright (c) 2019 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 Peterson, et al. Expires October 27, 2019 [Page 1] Internet-Draft RTP Security April 2019 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 4. STIR Profile for Endpoint Authentication and Verification Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] includes a suite of security services, including Digest authentication, for authenticating entities with a shared secret, TLS for transport security, and S/MIME (optionally) for body security. SIP is frequently used to establish media sessions, in particular audio or audiovisual sessions, which have their own security mechanisms available, such as Secure RTP [RFC3711]. However, the practices needed to bind security at the media layer to security at the SIP layer, to provide an assurance that protection is in place all the way up the stack, rely on a great many external security mechanisms and practices. This document provides documentation to explain their optimal use as a best practice. Revelations about widespread pervasive monitoring of the Internet have led to a greater desire to protect Internet communications Peterson, et al. Expires October 27, 2019 [Page 2] Internet-Draft RTP Security April 2019 [RFC7258]. In order to maximize the use of security features, especially of media confidentiality, opportunistic measures serve as a stopgap when a full suite of services cannot be negotiated all the way up the stack. Opportunistic media security for SIP is described in [I-D.ietf-sipbrandy-osrtp], which builds on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. With opportunistic encryption, there is an attempt to negotiate the use of encryption, but if the negotiation fails, then cleartext is used. Opportunistic encryption approaches typically have no integrity protection for the keying material. This document contains the SIPBRANDY profile of STIR [RFC8224] for media confidentiality, providing a comprehensive security solution for SIP media that includes integrity protection for keying material and offers application-layer assurance that media confidentiality is place. Various specifications that user agents must implement to support media confidentiality are given in the sections below; a summary of the best current practices appears in Section 8. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Security at the SIP and SDP layer There are two approaches to providing confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in [RFC7435]). This document only addresses comprehensive protection. Comprehensive protection for media sessions established by SIP requires the interaction of three protocols: Session Initiation Protocol (SIP) [RFC3261], the Session Description Protocol (SDP) [RFC4566], and the Real-time Protocol (RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP) [RFC3711]. Broadly, it is the responsibility of SIP to provide integrity protection for the media keying attributes conveyed by SDP, and those attributes will in turn identify the keys used by endpoints in the RTP media session(s) that SDP negotiates. Note that this framework does not apply to keys that also require confidentiality protection in the signaling layer, such as the SDP "k=" line, which MUST NOT be used in conjunction with this profile. Peterson, et al. Expires October 27, 2019 [Page 3] Internet-Draft RTP Security April 2019 In that way, once SIP and SDP have exchanged the necessary information to initiate a session, media endpoints will have a strong assurance that the keys they exchange have not been tampered with by third parties, and that end-to-end confidentiality is available. To establishing the identity of the endpoints of a SIP session, this specification uses STIR [RFC8224]. The STIR Identity header has been designed to prevent a class of impersonation attacks that are commonly used in robocalling, voicemail hacking, and related threats. STIR generates a signature over certain features of SIP requests, including header field values that contain an identity for the originator of the request, such as the From header field or P- Asserted-Identity field, and also over the media keys in SDP if they are present. As currently defined, STIR provides a signature over the "a=fingerprint" attribute, which is a fingerprint of the key used by DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive protection for SIP sessions in concert with SDP and SRTP when DTLS- SRTP is the media security service. The underlying PASSporT [RFC8225] object used by STIR is extensible, however, and it would be possible to provide signatures over other SDP attributes that contain alternate keying material. A profile for using STIR to provide media confidentiality is given in Section 4. 4. STIR Profile for Endpoint Authentication and Verification Services STIR [RFC8224] defines the Identity header field for SIP, which provides a cryptographic attestation of the source of communications. This document includes a profile of STIR, called the SIPBRANDY profile, where the STIR verification service will act in concert with an SRTP media endpoint to ensure that the key fingerprints, as given in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy this condition, the verification service function would in this case be implemented in the SIP User Agent Server (UAS), which would be composed with the media endpoint. If the STIR authentication service or verification service functions are implemented at an intermediary rather than an endpoint, this introduces the possibility that the intermediary could act as a man in the middle, altering key fingerprints. As this attack is not in STIR's core threat model, which focuses on impersonation rather than man-in-the-middle attacks, STIR offers no specific protections against such interference. The SIPBRANDY profile for media confidentiality thus shifts these responsibilities to the endpoints rather than the intermediaries. While intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions, the verification needs to be repeated at the endpoint to obtain end-to-end assurance. Intermediaries supporting this specification MUST NOT block or otherwise redirect calls if they do not trust the signing credential. Peterson, et al. Expires October 27, 2019 [Page 4] Internet-Draft RTP Security April 2019 The SIPBRANDY profile is based on an end-to-end trust model, so it is up to the endpoints to determine if they support signing credentials, not intermediaries. In order to be compliant with best practices for SIP media confidentiality with comprehensive protection, user agent implementations MUST implement both the authentication service and verification service roles described in [RFC8224]. STIR authentication services MUST signal their compliance with this specification by including the "msec" claim defined in this specification to the PASSporT payload. Implementations MUST provide key fingerprints in SDP and the appropriate signatures over them as specified in [RFC8225]. When generating either an offer or an answer [RFC3264], compliant implementations MUST include an "a=fingerprint" attribute containing the fingerprint of an appropriate key (see Section 4.1). 4.1. Credentials In order to implement the authentication service function in the user agent, SIP endpoints will need to acquire the credentials needed to sign for their own identity. That identity is typically carried in the From header field of a SIP request, and either contains a greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone number, which can appear in a variety of ways (e.g. "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] contains guidance for separating the two, and determining what sort of credential is needed to sign for each. To date, few commercial certification authorities (CAs) issue certificates for SIP URIs or telephone numbers; though work is ongoing on systems for this purpose (such as [I-D.ietf-acme-authority-token]) it is not yet mature enough to be recommended as a best practice. This is one reason why STIR permits intermediaries to act as an authentication service on behalf of an entire domain, just as in SIP a proxy server can provide domain-level SIP service. While CAs that offer proof-of-possession certificates similar to those used for email could be offered for SIP, either for greenfield identifiers or for telephone numbers, this specification does not require their use. For users who do not possess such certificates, DTLS-SRTP [RFC5763] permits the use of self-signed public keys. This profile of STIR employs more relaxed authority requirements of [RFC8224] to allow the use of self-signed public keys for authentication services that are composed with user agents, by generating a certificate (per the guidance in [RFC8226]) with a subject corresponding to the user's Peterson, et al. Expires October 27, 2019 [Page 5] Internet-Draft RTP Security April 2019 identity. To obtain comprehensive protection with a self-signed certificate, some out-of-band verification is needed as well. Such a credential could be used for trust on first use (see [RFC7435]) by relying parties. Note that relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates as they will not increase confidence in the certificate. Users who wish to remain anonymous can instead generate self-signed certificates as described in Section 4.2. Generally speaking, without access to out-of-band information about which certificates were issued to whom, it will be very difficult for relying parties to ascertain whether or not the signer of a SIP request is genuinely an "endpoint." Even the term "endpoint" is a problematic one, as SIP user agents can be composed in a variety of architectures and may not be devices under direct user control. While it is possible that techniques based on certificate transparency [RFC6962] or similar practices could help user agents to recognize one another's certificates, those operational systems will need to ramp up with the CAs that issue credentials to end user devices going forward. 4.2. Anonymous Communications In some cases, the identity of the initiator of a SIP session may be withheld due to user or provider policy. Following the recommendations of [RFC3323], this may involve using an identity such as "anonymous@anonymous.invalid" in the identity fields of a SIP request. [RFC8224] does not currently permit authentication services to sign for requests that supply this identity. It does however permit signing for valid domains, such as "anonymous@example.com," as a way of implementation an anonymization service as specified in [RFC3323]. Even for anonymous sessions, providing media confidentiality and partial SDP integrity is still desirable. This specification RECOMMENDS using one-time self-signed certificates for anonymous communications, with a subjectAltName of "sip:anonymous@anonymous.invalid". After a session is terminated, the certificate SHOULD be discarded, and a new one, with fresh keying material, SHOULD be generated before each future anonymous call. As with self-signed certificates, relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for anonymous certificates as they will not increase confidence in the certificate. Peterson, et al. Expires October 27, 2019 [Page 6] Internet-Draft RTP Security April 2019 Note that when using one-time anonymous self-signed certificates, any man in the middle could strip the Identity header and replace it with one signed by its own one-time certificate, changing the "mkey" parameters of PASSporT and any "a=fingerprint" attributes in SDP as it chooses. This signature only provides protection against non- Identity aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header. 4.3. Connected Identity Usage STIR [RFC8224] provides integrity protection for the fingerprint attributes in SIP request bodies, but not SIP responses. When a session is established, therefore, any SDP body carried by a 200 class response in the backwards direction will not be protected by an authentication service and cannot be verified. Thus, sending a secured SDP body in the backwards direction will require an extra RTT, typically a request sent in the backwards direction. The problem of providing "Connected Identity" in [RFC4474], which is obsoleted by STIR, was explored in [RFC4916], which uses a provisional or mid-dialog UPDATE request in the backwards direction to convey an Identity header field for the recipient of an INVITE. The procedures in that specification are largely compatible with the revision of the Identity header in STIR [RFC8224]. However, the following need to be considered: The UPDATE carrying signed SDP with a fingerprint in the backwards direction needs to be sent during dialog establishment, following the receipt of a PRACK after a provisional 1xx response. For use with this SIPBRANDY profile for media confidentiality, the UAS that responds to the INVITE request needs to act as an authentication service for the UPDATE sent in the backwards direction. The text in Section 4.4.1 of [RFC4916] regarding the receipt at a UAC of error codes 428, 436, 437 and 438 in response to a mid- dialog request RECOMMENDS treating the dialog as terminated. However, Section 6.1.1 of [RFC8224] allows the retransmission of requests with repairable error conditions. In particular, an authentication service might retry a mid-dialog rather than treating the dialog as terminated, although only one such retry is permitted. Note that the examples in [RFC4916] are based on the original [RFC4474], and will not match signatures using STIR [RFC8224]. Peterson, et al. Expires October 27, 2019 [Page 7] Internet-Draft RTP Security April 2019 Future work may be done to revise [RFC4916] for STIR; that work should take into account any impacts on the SIPBRANDY profile described in this document. The use of [RFC4916] has some further interactions with ICE; see Section 7. 4.4. Authorization Decisions [RFC8224] grants STIR verification services a great deal of latitude when making authorization decisions based on the presence of the Identity header field. It is largely a matter of local policy whether an endpoint rejects a call based on absence of an Identity header field, or even the presence of a header that fails an integrity check against the request. For this SIPBRANDY profile of STIR, however, a compliant verification service that receives a dialog-forming SIP request containing an Identity header with a PASSporT type of "msec", after validating the request per the steps described in Section 6.2 of [RFC8224], MUST reject the request if there is any failure in that validation process with the appropriate status code per Section 6.2.2. If the request is valid, then if a terminating user accepts the request, it MUST then follow the steps in Section 4.3 to act as an authentication service and send a signed request with the "msec" PASSPorT type in its Identity header as well, in order to enable end-to-end bidirectional confidentiality. For the purposes of this profile, the "msec" PASSporT type can be used by authentication services in one of two ways: as a mandatory request for media security, or as a merely opportunistic request for media security. As any verification service that receives an Identity header field in a SIP request with an unrecognized PASSporT type will simply ignore that Identity header, an authentication service will know whether or not the terminating side supports "msec" based on whether or not its user agent receives a signed request in the backwards direction per Section 4.3. If no such requests are received, the UA may do one or two things: shut down the dialog, if the policy of the UA requires that "msec" be supported by the terminating side for this dialog; or, if policy permits (e.g., an explicit acceptance by the user), allow the dialog to continue without media security. 5. Media Security Protocols As there are several ways to negotiate media security with SDP, any of which might be used with either opportunistic or comprehensive protection, further guidance to implementers is needed. In [I-D.ietf-sipbrandy-osrtp], opportunistic approaches considered Peterson, et al. Expires October 27, 2019 [Page 8] Internet-Draft RTP Security April 2019 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP [RFC6189]. Support for DTLS-SRTP is REQUIRED by this specification. The "mkey" claim of PASSporT provides integrity protection for "a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes appear in the same SDP. 6. Relayed Media and Conferencing Providing end-to-end media confidentiality for SIP is complicated by the presence of many forms of media relays. While many media relays merely proxy media to a destination, others present themselves as media endpoints and terminate security associations before re- originating media to its destination. Centralized conference bridges are one type of entity that typically terminates a media session in order to mux media from multiple sources and then to re-originate the muxed media to conference participants. In many such implementations, only hop-by-hop media confidentiality is possible. Work is ongoing to specify a means to encrypt both the hop-by-hop media between a user agent and a centralized server as well as the end-to-end media between user agents, but is not sufficiently mature at this time to make a recommendation for a best practice here. Those protocols are expected to identify their own best practice recommendations as they mature. Another class of entities that might relay SIP media are back-to-back user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], it may be possible for those devices to act as media relays while still permitting end-to-end confidentiality between user agents. Ultimately, if an endpoint can decrypt media it receives, then that endpoint can forward the decrypted media without the knowledge or consent of the media's originator. No media confidentiality mechanism can protect against these sorts of relayed disclosures, or trusted entities that can decrypt media and then record a copy to be sent elsewhere (see [RFC7245]). 7. ICE and Connected Identity Providing confidentiality for media with comprehensive protection requires careful timing of when media streams should be sent and when a user interface should signify that confidentiality is in place. Peterson, et al. Expires October 27, 2019 [Page 9] Internet-Draft RTP Security April 2019 In order to best enable end-to-end connectivity between user agents, and to avoid media relays as much as possible, implementations of this specification MUST support ICE [RFC8445]. To speed up call establishment, it is RECOMMENDED that implementations support trickle ICE [I-D.ietf-mmusic-trickle-ice-sip]. Note that in the comprehensive protection case, the use of Connected Identity [RFC4916] with ICE entails that the answer containing the key fingerprints, and thus the STIR signature, will come in an UPDATE sent in the backwards direction, a provisional response, and a provisional acknowledgment (PRACK), rather than in any earlier SDP body. Only at such a time as that UPDATE is received will the media keys be considered exchanged in this case. Similarly, in order to prevent, or at least mitigate, the denial-of- service attack described in Section 19.5.1 of [RFC8445], this specification incorporates best practices for ensuring that recipients of media flows have consented to receive such flows. Implementations of this specification MUST implement the STUN usage for consent freshness defined in [RFC7675]. 8. Best Current Practices The following are the best practices for SIP user agents to provide media confidentiality for SIP sessions. Implementations MUST support the STIR endpoint profile given in Section 4, and signal that in PASSporT with the "msec" header element. Implementations MUST follow the authorization decision behavior in Section 4.4. Implementations MUST support DTLS-SRTP for key-management, as described in Section 5. Implementations MUST support the ICE, and the STUN consent freshness mechanism, as specified in Section 7. 9. IANA Considerations This specification defines a new value for the Personal Assertion Token (PASSporT) Extensions registry called "msec," and the IANA is requested to add that entry to the registry with a value pointing to [RFCThis]. Peterson, et al. Expires October 27, 2019 [Page 10] Internet-Draft RTP Security April 2019 10. Security Considerations This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication. 11. Acknowledgments We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell for contributions to this problem statement and framework. We thank Liang Xia and Alissa Cooper for their careful review. 12. References 12.1. Normative References [I-D.ietf-mmusic-trickle-ice-sip] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)", draft-ietf- mmusic-trickle-ice-sip-18 (work in progress), June 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . Peterson, et al. Expires October 27, 2019 [Page 11] Internet-Draft RTP Security April 2019 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, . [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . Peterson, et al. Expires October 27, 2019 [Page 12] Internet-Draft RTP Security April 2019 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 12.2. Informative References [I-D.ietf-acme-authority-token] Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Challenges Using an Authority Token", draft-ietf-acme- authority-token-03 (work in progress), March 2019. [I-D.ietf-sipbrandy-osrtp] Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. Stach, "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-08 (work in progress), March 2019. [I-D.kaplan-mmusic-best-effort-srtp] Audet, F. and H. Kaplan, "Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol", draft-kaplan-mmusic-best- effort-srtp-01 (work in progress), October 2006. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, DOI 10.17487/RFC4474, August 2006, . [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, . Peterson, et al. Expires October 27, 2019 [Page 13] Internet-Draft RTP Security April 2019 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, "An Architecture for Media Recording Using the Session Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 2014, . [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, . Authors' Addresses Jon Peterson Neustar, Inc. Email: jon.peterson@team.neustar Richard Barnes Cisco Email: rlb@ipv.sx Russ Housley Vigil Security, LLC Email: housley@vigilsec.com Peterson, et al. Expires October 27, 2019 [Page 14] ./draft-ietf-spring-segment-routing-central-epe-10.txt0000644000764400076440000010532313216751155022207 0ustar iustyiusty Network Working Group C. Filsfils, Ed. Internet-Draft S. Previdi Intended status: Informational G. Dawra, Ed. Expires: June 24, 2018 Cisco Systems, Inc. E. Aries Juniper Networks D. Afanasiev Yandex December 21, 2017 Segment Routing Centralized BGP Egress Peer Engineering draft-ietf-spring-segment-routing-central-epe-10 Abstract Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction topological or service-based. SR allows to enforce a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software Defined Network, SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. Requirements Language 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 RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Filsfils, et al. Expires June 24, 2018 [Page 1] Internet-Draft Segment Routing Centralized EPE December 2017 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 24, 2018. Copyright Notice Copyright (c) 2017 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 (https://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 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 3. Distribution of Topology and TE Information using BGP-LS . . 6 3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7 3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 7 3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8 3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8 3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 4. BGP-EPE Controller . . . . . . . . . . . . . . . . . . . . . 10 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 5.3. At a Router - BGP Labeled Unicast route (RFC8277) . . . . 14 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15 Filsfils, et al. Expires June 24, 2018 [Page 2] Internet-Draft Segment Routing Centralized EPE December 2017 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction The document is structured as follows: o Section 1 states the BGP-EPE problem statement and provides the key references. o Section 2 defines the different BGP Peering Segments and the semantic associated to them. o Section 3 describes the automated allocation of BGP Peering Segment-IDs (SIDs) by the BGP-EPE enabled egress border router and the automated signaling of the external peering topology and the related BGP Peering SID's to the collector [I-D.ietf-idr-bgpls-segment-routing-epe]. o Section 4 overviews the components of a centralized BGP-EPE controller. The definition of the BGP-EPE controller is outside the scope of this document. o Section 5 overviews the methods that could be used by the centralized BGP-EPE controller to implement a BGP-EPE policy at an ingress border router or at a source host within the domain. The exhaustive definition of all the means to program an BGP-EPE input policy is outside the scope of this document. For editorial reasons, the solution is described with IPv6 addresses and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS SIDs and also to IPv6 with native IPv6 SIDs. 1.1. Problem Statement The BGP-EPE problem statement is defined in [RFC7855]. A centralized controller should be able to instruct an ingress Provider Edge router (PE) or a content source within the domain to Filsfils, et al. Expires June 24, 2018 [Page 3] Internet-Draft Segment Routing Centralized EPE December 2017 use a specific egress PE and a specific external interface/neighbor to reach a particular destination. Let's call this solution "BGP-EPE" for "BGP Egress Peer Engineering". The centralized controller is called the "BGP-EPE Controller". The egress border router where the BGP-EPE traffic steering functionality is implemented is called a BGP-EPE enabled border router. The input policy programmed at an ingress border router or at a source host is called a BGP-EPE policy. The requirements that have motivated the solution described in this document are listed here below: o The solution MUST apply to the Internet use-case where the Internet routes are assumed to use IPv4 unlabeled or IPv6 unlabeled. It is not required to place the Internet routes in a VRF and allocate labels on a per route, or on a per-path basis. o The solution MUST support any deployed iBGP schemes (RRs, confederations or iBGP full meshes). o The solution MUST be applicable to both routers with external and internal peers. o The solution should minimize the need for new BGP capabilities at the ingress PEs. o The solution MUST accommodate an ingress BGP-EPE policy at an ingress PE or directly at a source within the domain. o The solution MAY support automated Fast Reroute (FRR) and fast convergence mechanisms. The following reference diagram is used throughout this document. +---------+ +------+ | | | | | H B------D G | | +---/| AS 2 |\ +------+ | |/ +------+ \ | |---L/8 A AS1 C---+ \| | | |\\ \ +------+ /| AS 4 |---M/8 | | \\ +-E |/ +------+ | X | \\ | K | | +===F AS 3 | +---------+ +------+ Figure 1: Reference Diagram Filsfils, et al. Expires June 24, 2018 [Page 4] Internet-Draft Segment Routing Centralized EPE December 2017 IP addressing: o C's interface to D: 2001:db8:cd::c/64, D's interface: 2001:db8:cd::d/64 o C's interface to E: 2001:db8:ce::c/64, E's interface: 2001:db8:ce::e/64 o C's upper interface to F: 2001:db8:cf1::c/64, F's interface: 2001:db8:cf1::f/64 o C's lower interface to F: 2001:db8:cf2::c/64, F's interface: 2001:db8:cf2::f/64 o BGP router-ID of C: 192.0.2.3 o BGP router-ID of D: 192.0.2.4 o BGP router-ID of E: 192.0.2.5 o BGP router-ID of F: 192.0.2.6 o Loopback of F used for eBGP multi-hop peering to C: 2001:db8:f::f/128 o C's loopback is 2001:db8:c::c/128 with SID 64 C's BGP peering: o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) o Single-hop eBGP peering with neighbor 2001:db8:ce::e (E) o Multi-hop eBGP peering with F on IP address 2001:db8:f::f (F) C's resolution of the multi-hop eBGP session to F: o Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f o Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f C is configured with local policy that defines a BGP PeerSet as the set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F) X is the BGP-EPE controller within AS1 domain. H is a content source within AS1 domain. Filsfils, et al. Expires June 24, 2018 [Page 5] Internet-Draft Segment Routing Centralized EPE December 2017 2. BGP Peering Segments As defined in [I-D.ietf-spring-segment-routing], certain segments are defined by a BGP-EPE capable node and corresponding to its attached peers. These segments are called BGP peering segments or BGP Peering SIDs. They enable the expression of source-routed inter-domain paths. An ingress border router of an AS may compose a list of segments to steer a flow along a selected path within the AS, towards a selected egress border router C of the AS and through a specific peer. At minimum, a BGP Egress Peering Engineering policy applied at an ingress EPE involves two segments: the Node SID of the chosen egress EPE and then the BGP Peering Segment for the chosen egress EPE peer or peering interface. [I-D.ietf-spring-segment-routing] defines three types of BGP peering segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet SID. A Peer Node Segment is a segment describing a peer, including the SID (PeerNode SID) allocated to it. A Peer Adjacency Segment is a segment describing a link, including the SID (PeerAdj SID) allocated to it. A Peer Set Segment is a segment describing a link or a node that is part of the set, including the SID (PeerSet SID) allocated to the set. 3. Distribution of Topology and TE Information using BGP-LS In ships-in-the-night mode with respect to the pre-existing iBGP design, a BGP-LS [RFC7752] session is established between the BGP-EPE enabled border router and the BGP-EPE controller. As a result of its local configuration and according to the behavior described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C allocates the following BGP Peering Segments ([I-D.ietf-spring-segment-routing]): o A PeerNode segment for each of its defined peer (D: 1012, E: 1022 and F: 1052). o A PeerAdj segment for each recursing interface to a multi-hop peer (e.g.: the upper and lower interfaces from C to F in figure 1). Filsfils, et al. Expires June 24, 2018 [Page 6] Internet-Draft Segment Routing Centralized EPE December 2017 o A PeerSet segment to the set of peers (E and F). In this case the PeerSet represents a set of peers (E, F) belonging to the same AS (AS 3). C programs its forwarding table accordingly: Incoming Outgoing Label Operation Interface ------------------------------------ 1012 POP link to D 1022 POP link to E 1032 POP upper link to F 1042 POP lower link to F 1052 POP load balance on any link to F 1060 POP load balance on any link to E or to F C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each such BGP-LS route is described in the following subsections according to the encoding details defined in [I-D.ietf-idr-bgpls-segment-routing-epe]. 3.1. PeerNode SID to D Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cd::c, 2001:db8:cd::d Attributes: o PeerNode SID: 1012 3.2. PeerNode SID to E Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:ce::c, 2001:db8:ce::e Filsfils, et al. Expires June 24, 2018 [Page 7] Internet-Draft Segment Routing Centralized EPE December 2017 Attributes: o PeerNode SID: 1022 o PeerSetSID: 1060 o Link Attributes: see section 3.3.2 of [RFC7752] 3.3. PeerNode SID to F Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:c::c, 2001:db8:f::f Attributes: o PeerNode SID: 1052 o PeerSetSID: 1060 3.4. First PeerAdj to F Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3, AS1, 1000 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf1::c, 2001:db8:cf1::f Attributes: o PeerAdj-SID: 1032 o LinkAttributes: see section 3.3.2 of [RFC7752] Filsfils, et al. Expires June 24, 2018 [Page 8] Internet-Draft Segment Routing Centralized EPE December 2017 3.5. Second PeerAdj to F Descriptors: o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 192.0.2.3 , AS1 o Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf2::c, 2001:db8:cf2::f Attributes: o PeerAdj-SID: 1042 o LinkAttributes: see section 3.3.2 of [RFC7752] 3.6. Fast Reroute (FRR) A BGP-EPE enabled border router MAY allocate a FRR backup entry on a per BGP Peering SID basis. One example is as follows: o PeerNode SID 1. If multi-hop, backup via the remaining PeerADJ SIDs (if available) to the same peer. 2. Else backup via another PeerNode SID to the same AS. 3. Else pop the PeerNode SID and perform an IP lookup. o PeerAdj SID 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs (if available) to the same peer. 2. Else backup via a PeerNode SID to the same AS. 3. Else pop the PeerNode SID and perform an IP lookup. o PeerSet SID 1. Backup via remaining PeerNode SIDs in the same PeerSet. 2. Else pop the PeerNode SID and IP lookup. Filsfils, et al. Expires June 24, 2018 [Page 9] Internet-Draft Segment Routing Centralized EPE December 2017 Let's illustrate different types of possible backups using the reference diagram and considering the Peering SIDs allocated by C. PeerNode SID 1052, allocated by C for peer F: o Upon the failure of the upper connected link CF, C can reroute all the traffic onto the lower CF link to the same peer (F). PeerNode SID 1022, allocated by C for peer E: o Upon the failure of the connected link CE, C can reroute all the traffic onto the link to PeerNode SID 1052 (F). PeerNode SID 1012, allocated by C for peer D: o Upon the failure of the connected link CD, C can pop the PeerNode SID and lookup the IP destination address in its FIB and route accordingly. PeerSet SID 1060, allocated by C for the set of peers E and F: o Upon the failure of a connected link in the group, the traffic to PeerSet SID 1060 is rerouted on any other member of the group. For specific business reasons, the operator might not want the default FRR behavior applied to a PeerNode SID or any of its dependent PeerADJ SID. The operator should be able to associate a specific backup PeerNode SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) which overrules the default behavior which would have preferred F as a backup for E. 4. BGP-EPE Controller In this section, Let's provide a non-exhaustive set of inputs that a BGP-EPE controller would likely collect such as to perform the BGP- EPE policy decision. The exhaustive definition is outside the scope of this document. 4.1. Valid Paths From Peers The BGP-EPE controller should collect all the BGP paths (i.e.: IP destination prefixes) advertised by all the BGP-EPE enabled border router. Filsfils, et al. Expires June 24, 2018 [Page 10] Internet-Draft Segment Routing Centralized EPE December 2017 This could be realized by setting an iBGP session with the BGP-EPE enabled border router, with the router configured to advertise all paths using BGP add-path [RFC7911] and the original next-hop preserved. In this case, C would advertise the following Internet routes to the BGP-EPE controller: o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:cd::d, AS Path {AS 2, 4} * X (i.e.: the BGP-EPE controller) knows that C receives a path to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2. o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:ce::e, AS Path {AS 3, 4} * X knows that C receives a path to 2001:db8:abcd::/48 via neighbor 2001:db8:ce::e of AS2. o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, AS Path {AS 3, 4} * X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 via neighbor 2001:db8:f::f An alternative option would be for a BGP-EPE collector to use BGP Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP- EPE enabled border routers. 4.2. Intra-Domain Topology The BGP-EPE controller should collect the internal topology and the related IGP SIDs. This could be realized by collecting the IGP LSDB of each area or running a BGP-LS session with a node in each IGP area. 4.3. External Topology Thanks to the collected BGP-LS routes described in section 2, the BGP-EPE controller is able to maintain an accurate description of the egress topology of node C. Furthermore, the BGP-EPE controller is able to associate BGP Peering SIDs to the various components of the external topology. Filsfils, et al. Expires June 24, 2018 [Page 11] Internet-Draft Segment Routing Centralized EPE December 2017 4.4. SLA characteristics of each peer The BGP-EPE controller might collect SLA characteristics across peers. This requires an BGP-EPE solution as the SLA probes need to be steered via non-best-path peers. Unidirectional SLA monitoring of the desired path is likely required. This might be possible when the application is controlled at the source and the receiver side. Unidirectional monitoring dissociates the SLA characteristic of the return path (which cannot usually be controlled) from the forward path (the one of interest for pushing content from a source to a consumer and the one which can be controlled). Alternatively, Extended Metrics, as defined in [RFC7810] could also be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]). 4.5. Traffic Matrix The BGP-EPE controller might collect the traffic matrix to its peers or the final destinations. IPFIX [RFC7011] is a likely option. An alternative option consists in collecting the link utilization statistics of each of the internal and external links, also available in the current definition of [RFC7752]. 4.6. Business Policies The BGP-EPE controller should be configured or collect business policies through any desired mechanisms. These mechanisms by which these policies are configured or collected are outside the scope of this document. 4.7. BGP-EPE Policy On the basis of all these inputs (and likely others), the BGP-EPE Controller decides to steer some demands away from their best BGP path. The BGP-EPE policy is likely expressed as a two-entry segment list where the first element is the IGP prefix SID of the selected egress border router and the second element is a BGP Peering SID at the selected egress border router. A few examples are provided hereafter: o Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID of PE C as defined in Section 1.1. Filsfils, et al. Expires June 24, 2018 [Page 12] Internet-Draft Segment Routing Centralized EPE December 2017 o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, {64, 1022}. o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, {64, 1052}. o Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f of multi-hop eBGP peer 2001:db8:f::f, {64, 1042}. o Prefer egress PE C and any interface to any peer in the group 1060: {64, 1060}. Note that the first SID could be replaced by a list of segments. This is useful when an explicit path within the domain is required for traffic engineering purposes. For example, if the Prefix SID of node B is 60 and the BGP-EPE controller would like to steer the traffic from A to C via B then through the external link to peer D then the segment list would be {60, 64, 1012}. 5. Programming an input policy The detailed/exhaustive description of all the means to implement an BGP-EPE policy are outside the scope of this document. A few examples are provided in this section. 5.1. At a Host A static IP/MPLS route can be programmed at the host H. The static route would define a destination prefix, a next-hop and a label stack to push. Assuming a global SRGB, at least on all access routers connecting the hosts, the same policy can be programmed across all hosts, which is convenient. 5.2. At a router - SR Traffic Engineering tunnel The BGP-EPE controller can configure the ingress border router with an SR traffic engineering tunnel T1 and a steering-policy S1 which causes a certain class of traffic to be mapped on the tunnel T1. The tunnel T1 would be configured to push the required segment list. The tunnel and the steering policy could be configured via multiple means. A few examples are given below: o PCEP according to [I-D.ietf-pce-segment-routing] and [I-D.ietf-pce-pce-initiated-lsp]. o Netconf ([RFC6241]). Filsfils, et al. Expires June 24, 2018 [Page 13] Internet-Draft Segment Routing Centralized EPE December 2017 o Other static or ephemeral APIs Example: at router A (Figure 1). Tunnel T1: push {64, 1042} IP route L/8 set next-hop T1 5.3. At a Router - BGP Labeled Unicast route (RFC8277) The BGP-EPE Controller could build a BGP Labeled Unicast route [RFC8277]) route (from scratch) and send it to the ingress router: o NLRI: the destination prefix to engineer: e.g., L/8. o Next-Hop: the selected egress border router: C. o Label: the selected egress peer: 1042. o AS path: reflecting the selected valid AS path. o Some BGP policy to ensure it will be selected as best by the ingress router. Note that as discussed in RFC 8277 section 5, the comparison of labeled and unlabeled unicast BGP route is implementation dependent and hence may require an implementation specific policy on each ingress router. This BGP Labeled unicast route (RFC8277) "overwrites" an equivalent or less-specific "best path". As the best-path is changed, this BGP- EPE input policy option may influence the path propagated to the upstream peer/customers. Indeed, implementations treating the SAFI-1 and SAFI-4 routes for a given prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route to their BGP upstream peers. 5.4. At a Router - VPN policy route The BGP-EPE Controller could build a VPNv4 route (from scratch) and send it to the ingress router: o NLRI: the destination prefix to engineer: e.g., L/8. o Next-Hop: the selected egress border router: C. o Label: the selected egress peer: 1042. o Route-Target: selecting the appropriate VRF at the ingress router. o AS path: reflecting the selected valid AS path. Filsfils, et al. Expires June 24, 2018 [Page 14] Internet-Draft Segment Routing Centralized EPE December 2017 o Some BGP policy to ensure it will be selected as best by the ingress router in the related VRF. The related VRF must be preconfigured. A VRF fallback to the main FIB might be beneficial to avoid replicating all the "normal" Internet paths in each VRF. 6. IPv6 Dataplane The described solution is applicable to IPv6, either with MPLS-based or IPv6-Native segments. In both cases, the same three steps of the solution are applicable: o BGP-LS-based signaling of the external topology and BGP Peering Segments to the BGP-EPE controller. o Collection of various inputs by the BGP-EPE controller to come up with a policy decision. o Programming at an ingress router or source host of the desired BGP-EPE policy which consists in a list of segments to push on a defined traffic class. 7. Benefits The BGP-EPE solutions described in this document have the following benefits: o No assumption on the iBGP design within AS1. o Next-Hop-Self on the Internet routes propagated to the ingress border routers is possible. This is a common design rule to minimize the number of IGP routes and to avoid importing external churn into the internal routing domain. o Consistent support for traffic engineering within the domain and at the external edge of the domain. o Support both host and ingress border router BGP-EPE policy programming. o BGP-EPE functionality is only required on the BGP-EPE enabled egress border router and the BGP-EPE controller: an ingress policy can be programmed at the ingress border router without any new functionality. Filsfils, et al. Expires June 24, 2018 [Page 15] Internet-Draft Segment Routing Centralized EPE December 2017 o Ability to deploy the same input policy across hosts connected to different routers (assuming the global property of IGP prefix SIDs). 8. IANA Considerations This document does not request any IANA allocations. 9. Manageability Considerations The BGP-EPE use-case described in this document requires BGP-LS ([RFC7752]) extensions that are described in [I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions consists of additional BGP-LS descriptors and TLVs that will follow the same. Manageability functions of BGP-LS, described in [RFC7752] also apply to the extensions required by the EPE use-case. Additional Manageability considerations are described in [I-D.ietf-idr-bgpls-segment-routing-epe]. 10. Security Considerations [RFC7752] defines BGP-LS NLRIs and their associated security aspects. [I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS extensions required by the BGP-EPE mechanisms described in this document. BGP-EPE BGP-LS extensions also include the related security. 11. Contributors Daniel Ginsburg substantially contributed to the content of this document. 12. Acknowledgements The authors would like to thank Acee Lindem for his comments and contribution. 13. References 13.1. Normative References [I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls-segment-routing- epe-14 (work in progress), December 2017. Filsfils, et al. Expires June 24, 2018 [Page 16] Internet-Draft Segment Routing Centralized EPE December 2017 [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-14 (work in progress), December 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . 13.2. Informative References [I-D.ietf-idr-te-pm-bgp] Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S., Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions", draft-ietf-idr-te-pm-bgp-08 (work in progress), August 2017. [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-11 (work in progress), October 2017. [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-11 (work in progress), November 2017. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . Filsfils, et al. Expires June 24, 2018 [Page 17] Internet-Draft Segment Routing Centralized EPE December 2017 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, . [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, . [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . Authors' Addresses Clarence Filsfils (editor) Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Stefano Previdi Cisco Systems, Inc. Italy Email: stefano@previdi.net Gaurav Dawra (editor) Cisco Systems, Inc. USA Email: gdawra.ietf@gmail.com Filsfils, et al. Expires June 24, 2018 [Page 18] Internet-Draft Segment Routing Centralized EPE December 2017 Ebben Aries Juniper Networks 1133 Innovation Way Sunnyvale CA 94089 US Email: exa@juniper.net Dmitry Afanasiev Yandex RU Email: fl0w@yandex-team.ru Filsfils, et al. Expires June 24, 2018 [Page 19] ./draft-ietf-stir-oob-07.txt0000644000764400076440000022154013631476017015131 0ustar iustyiusty Network Working Group E. Rescorla Internet-Draft Mozilla Intended status: Informational J. Peterson Expires: September 10, 2020 Neustar March 9, 2020 STIR Out-of-Band Architecture and Use Cases draft-ietf-stir-oob-07 Abstract The PASSporT format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identify of callers. Not all telephone calls use Internet signaling protocols, however, and some calls use them for only part of their signaling path, or cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2020. Copyright Notice Copyright (c) 2020 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 (https://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 Rescorla & Peterson Expires September 10, 2020 [Page 1] Internet-Draft STIR Out-of-Band March 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 7 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 7 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 8 5.5. Case 5: Enterprise Call Center . . . . . . . . . . . . . 9 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 9 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14 7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 16 8. Authentication and Verification Service Behavior for Out-of- Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Authentication Service (AS) . . . . . . . . . . . . . . . 17 8.2. Verification Service (VS) . . . . . . . . . . . . . . . . 18 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 19 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 20 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 16. Informative References . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction The STIR problem statement [RFC7340] describes widespread problems enabled by impersonation in the telephone network, including illegal robocalling, voicemail hacking, and swatting. As telephone services are increasingly migrating onto the Internet, and using Voice over IP (VoIP) protocols such as SIP [RFC3261], it is necessary for these Rescorla & Peterson Expires September 10, 2020 [Page 2] Internet-Draft STIR Out-of-Band March 2020 protocols to support stronger identity mechanisms to prevent impersonation. For example, [RFC8224] defines a SIP Identity header field capable of carrying PASSporT [RFC8225] objects in SIP as a means to cryptographically attest that the originator of a telephone call is authorized to use the calling party number (or, for native SIP cases, SIP URI) associated with the originator of the call. Not all telephone calls use SIP today, however, and even those that do use SIP do not always carry SIP signaling end-to-end. Calls from telephone numbers still routinely traverse the Public Switched Telephone Network (PSTN) at some point. Broadly, calls fall into one of three categories: 1. One or both of the endpoints is actually a PSTN endpoint. 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the call transits the PSTN at some point. 3. Non-PSTN calls which do not transit the PSTN at all (such as native SIP end-to-end calls). The first two categories represent the majority of telephone calls associated with problems like illegal robocalling: many robocalls today originate on the Internet but terminate at PSTN endpoints. However, the core network elements that operate the PSTN are legacy devices that are unlikely to be upgradable at this point to support an in-band authentication system. As such, those devices largely cannot be modified to pass signatures originating on the Internet--or indeed any inband signaling data--intact. Even if fields for tunneling arbitrary data can be found in traditional PSTN signaling, in some cases legacy elements would strip the signatures from those fields; in others, they might damage them to the point where they cannot be verified. For those first two categories above, any in- band authentication scheme does not seem practical in the current environment. While the core network of the PSTN remains fixed, the endpoints of the telephone network are becoming increasingly programmable and sophisticated. Landline "plain old telephone service" deployments, especially in the developed world, are shrinking, and increasingly being replaced by three classes of intelligent devices: smart phones, IP PBXs, and terminal adapters. All three are general purpose computers, and typically all three have Internet access as well as access to the PSTN; they may be used for residential, mobile, or enterprise telephone services. Additionally, various kinds of gateways increasingly front for deployments of legacy PBX and PSTN switches. All of this provides a potential avenue for building an Rescorla & Peterson Expires September 10, 2020 [Page 3] Internet-Draft STIR Out-of-Band March 2020 authentication system that implements stronger identity while leaving PSTN systems intact. This capability also provides an ideal transitional technology while in-band STIR adoption is ramping up. It permits early adopters to use the technology even when intervening network elements are not yet STIR-aware, and through various kinds of gateways, it may allow providers with a significant PSTN investment to still secure their calls with STIR. The techniques described in this document therefore build on the PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a way that a PASSporT object created in the originating network of a call can reach the terminating network even when it cannot be carried end-to-end in-band in the call signaling. This relies on a new service defined in this document called a Call Placement Service (CPS) that permits the PASSporT object to be stored during call processing and retrieved for verification purposes. Potential implementors should note that this document merely defines the operating environments in which this out-of-band STIR mechanism is intended to operate. It provides use cases, gives a broad description of the components and a potential solution architecture. Various environments may have their own security requirements: a public deployment of out-of-band STIR faces far greater challenges than a constrained intranetwork deployment. To flesh out the storage and retrieval of PASSporTs in the CPS within this context, this document includes a strawman protocol suitable for that purpose. Deploying this framework in any given environment would require additional specification outside the scope of the current document. 2. Terminology TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Operating Environments This section describes the environments in which the proposed out-of- band STIR mechanism is intended to operate. In the simplest setting, Alice is calling Bob, and her call is routed through some set of gateways and/or the PSTN which do not support end-to-end delivery of STIR. Both Alice and Bob have smart devices which can access the Internet (perhaps enterprise devices, or even end user ones), but they do not have a clear telephone signaling connection between them: Rescorla & Peterson Expires September 10, 2020 [Page 4] Internet-Draft STIR Out-of-Band March 2020 Alice cannot inject any data into signaling which Bob can read, with the exception of the asserted destination and origination E.164 numbers. The calling party number might originate from her own device or from the network. These numbers are effectively the only data that can be used for coordination between the endpoints. +---------+ / \ +--- +---+ +----------+ / \ +----------+ | | | Gateways | | | | Alice |<----->| and/or |<----->| Bob | | (caller) | | PSTN | | (callee) | +----------+ \ / +----------+ +--- +---+ \ / +---------+ In a more complicated setting, Alice and/or Bob may not have a smart or programmable device, but instead just a traditional telephone. However, one or both of them are behind a STIR-aware gateway that can participate in out-of-band coordination, as shown below: +---------+ / \ +--- +---+ +----------+ +--+ / \ +--+ +----------+ | | | | | Gateways | | | | | | Alice |<-|GW|->| and/or |<-|GW|->| Bob | | (caller) | | | | PSTN | | | | (callee) | +----------+ +--+ \ / +--+ +----------+ +--- +---+ \ / +---------+ In such a case, Alice might have an analog (e.g., PSTN) connection to her gateway/ switch which is responsible for her identity. Similarly, the gateway would verify Alice's identity, generate the right calling party number information and provide that number to Bob using ordinary Plain Ol' Telephone Service (POTS) mechanisms. 4. Dataflows Because in these operating environments endpoints cannot pass cryptographic information to one another directly through signaling, any solution must involve some rendezvous mechanism to allow endpoints to communicate. We call this rendezvous service a "call placement service" (CPS), a service where a record of call placement, Rescorla & Peterson Expires September 10, 2020 [Page 5] Internet-Draft STIR Out-of-Band March 2020 in this case a PASSporT, can be stored for future retrieval. In principle this service could communicate any information, but minimally we expect it to include a full-form PASSporT that attests the caller, callee, and the time of the call. The callee can use the existence of a PASSporT for a given incoming call as rough validation of the asserted origin of that call. (See Section 11 for limitations of this design.) This architecture does not mandate that any particular sort of entity operate a CPS, or mandate any means to discover a CPS. A CPS could be run internally within a network, or made publicly available. One or more CPSes could be run by a carrier, as repositories for PASSporTs for calls sent to its customers, or a CPS could be built-in to an enterprise PBX, or even a smartphone. To the degree possible, it is specified here generically, as an idea that may have applicability to a variety of STIR deployments. There are roughly two plausible dataflow architectures for the CPS: 1. The callee registers with the CPS. When the caller wishes to place a call to the callee, it sends the PASSporT to the CPS, which immediately forwards it to the callee, or, 2. The caller stores the PASSporT with the CPS at the time of call placement. When the callee receives the call, it contacts the CPS and retrieves the PASSporT. While the first architecture is roughly isomorphic to current VoIP protocols, it shares their drawbacks. Specifically, the callee must maintain a full-time connection to the CPS to serve as a notification channel. This comes with the usual networking costs to the callee and is especially problematic for mobile endpoints. Indeed, if the endpoints had the capabilities to implement such an architecture, they could surely just use SIP or some other protocol to set up a secure session; even if the media were going through the traditional PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we focus on the second architecture in which the PSTN incoming call serves as the notification channel and the callee can then contact the CPS to retrieve the PASSporT. In specialized environments, for example a call center that receives a large volume of incoming calls that originated in the PSTN, the notification channel approach might be viable. 5. Use Cases The following are the motivating use cases for this mechanism. Bear in mind that just as in [RFC8224] there may be multiple Identity headers in a single SIP INVITE, so there may be multiple PASSporTs in Rescorla & Peterson Expires September 10, 2020 [Page 6] Internet-Draft STIR Out-of-Band March 2020 this out-of-band mechanism associated with a single call. For example, a SIP user agent might create a PASSporT for a call with an end user credential, and as the call exits the originating administrative domain the network authentication service might create its own PASSporT for the same call. As such, these use cases may overlap in the processing of a single call. 5.1. Case 1: VoIP to PSTN Call A call originates in a SIP environment in a STIR-aware administrative domain. The local authentication service for that administrative domain creates a PASSporT which is carried in band in the call per [RFC8224]. The call is routed out of the originating administrative domain and reaches a gateway to the PSTN. Eventually, the call will terminate on a mobile smartphone that supports this out-of-band mechanism. In this use case, the originating authentication service can store the PASSporT with the appropriate CPS (per the practices of Section 10) for the target telephone number as a fallback in case SIP signaling will not reach end-to-end. When the destination mobile smartphone receives the call over the PSTN, it consults the CPS and discovers a PASSporT from the originating telephone number waiting for it. It uses this PASSporT to verify the calling party number. 5.2. Case 2: Two Smart PSTN endpoints A call originates with an enterprise PBX that has both Internet access and a built-in gateway to the PSTN, which communicates through traditional telephone signaling protocols. The PBX immediately routes the call to the PSTN, but before it does, it provisions a PASSporT on the CPS associated with the target telephone number. After normal PSTN routing, the call lands on a smart mobile handset that supports the STIR out-of-band mechanism. It queries the appropriate CPS over the Internet to determine if a call has been placed to it by a STIR-aware device. It finds the PASSporT provisioned by the enterprise PBX and uses it to verify the calling party number. 5.3. Case 3: PSTN to VoIP Call A call originates with an enterprise PBX that has both Internet access and a built-in gateway to the PSTN. It will immediately route the call to the PSTN, but before it does, it provisions a PASSporT with the CPS associated with the target telephone number. However, it turns out that the call will eventually route through the PSTN to an Internet gateway, which will translate this into a SIP call and Rescorla & Peterson Expires September 10, 2020 [Page 7] Internet-Draft STIR Out-of-Band March 2020 deliver it to an administrative domain with a STIR verification service. In this case, there are two subcases for how the PASSporT might be retrieved. In subcase 1, the Internet gateway that receives the call from the PSTN could query the appropriate CPS to determine if the original caller created and provisioned a PASSporT for this call. If so, it can retrieve the PASSporT and, when it creates a SIP INVITE for this call, add a corresponding Identity header field per [RFC8224]. When the SIP INVITE reaches the destination administrative domain, it will be able to verify the PASSporT normally. Note that to avoid discrepancies with the Date header field value, only full-form PASSporT should be used for this purpose. In subcase 2, the gateway does not retrieve the PASSporT itself, but instead the verification service at the destination administrative domain does so. Subcase 1 would perhaps be valuable for deployments where the destination administrative domain supports in-band STIR but not out-of-band STIR. 5.4. Case 4: Gateway Out-of-band A call originates in the SIP world in a STIR-aware administrative domain. The local authentication service for that administrative domain creates a PASSporT which is carried in band in the call per [RFC8224]. The call is routed out of the originating administrative domain and eventually reaches a gateway to the PSTN. In this case, the originating authentication service does not support the out-of-band mechanism, so instead the gateway to the PSTN extracts the PASSporT from the SIP request and provisions it to the CPS. (When the call reaches the gateway to the PSTN, the gateway might first check the CPS to see if a PASSporT object had already been provisioned for this call, and only provision a PASSporT if none is present). Ultimately, the call may terminate on the PSTN, or be routed back to a SIP environment. In the former case, perhaps the destination endpoint queries the CPS to retrieve the PASSporT provisioned by the first gateway. Or if the call ultimately returns to a SIP environment, it might be the gateway from the PSTN back to the Internet that retrieves the PASSporT from the CPS and attaches it to the new SIP INVITE it creates, or it might be the terminating administrative domain's verification service that checks the CPS when an INVITE arrives with no Identity header field. Either way the PASSporT can survive the gap in SIP coverage caused by the PSTN leg of the call. Rescorla & Peterson Expires September 10, 2020 [Page 8] Internet-Draft STIR Out-of-Band March 2020 5.5. Case 5: Enterprise Call Center A call originates from a mobile user, and a STIR authentication service operated by their carrier creates a PASSporT for the call. As the carrier forwards the call via SIP, it attaches the PASSporT to the SIP call with an Identity header field. As a fallback in case the call will not go end-to-end over SIP, the carrier also stores the PASSporT in a CPS. The call is then routed over SIP for a time, before it transitions to the PSTN and ultimately is handled by a legacy PBX at a high-volume call center. The call center supports the out-of-band service, and has a high-volume interface to a CPS to retrieve PASSporTs for incoming calls; agents at the call center use a general purpose computer to manage inbound calls and can receive STIR notifications through it. When the PASSporT arrives at the CPS, it is sent through a subscription/notification interface to a system that can correlate incoming calls with valid PASSporTs. The call center agent sees that a valid call from the originating number has arrived. 6. Storing and Retrieving PASSporTs The use cases show a variety of entities accessing the CPS to store and retrieve PASSporTs. The question of how the CPS authorizes the storage and retrieval of PASSporT is thus a key design decision in the architecture. The STIR architecture assumes that service providers and in some cases end user devices will have credentials suitable for attesting authority over telephone numbers per [RFC8226]. These credentials provide the most obvious way that a CPS can authorize the storage and retrieval of PASSporTs. However, as use cases 3, 4 and 5 in Section 5 show, it may sometimes make sense for the entity storing or retrieving PASSporTs to be an intermediary rather than a device associated with either the originating or terminating side of a call, and those intermediaries often would not have access to STIR credentials covering the telephone numbers in question. Requiring authorization based on a credential to store PASSporTs is therefore undesirable, though potentially acceptable if sufficient steps are taken to mitigate any privacy risk of leaking data. It is an explicit design goal of this mechanism to minimize the potential privacy exposure of using a CPS. Ideally, the out-of-band mechanism should not result in a worse privacy situation than in-band [RFC8224] STIR: for in-band, we might say that a SIP entity is authorized to receive a PASSporT if it is an intermediate or final target of the routing of a SIP request. As the originator of a call cannot necessarily predict the routing path a call will follow, an Rescorla & Peterson Expires September 10, 2020 [Page 9] Internet-Draft STIR Out-of-Band March 2020 out-of-band mechanism could conceivably even improve on the privacy story. Broadly, the architecture recommended here thus is one focused on permitting any entity to store encrypted PASSporTs at the CPS, indexed under the called number. PASSporTs will be encrypted with a public key associated with the called number, so these PASSporTs may safely be retrieved by any entity, as only holders of the corresponding private key will be able to decrypt the PASSporT. This also prevents the CPS itself from learning the contents of PASSporTs, and thus metadata about calls in progress, which makes the CPS a less attractive target for pervasive monitoring (see [RFC7258]). As a first step, transport-level security can provide confidentiality from eavesdroppers for both the storing and retrieval of PASSporTs. To bolster the privacy story, prevent denial-of-service flooding of the CPS, and to complicate traffic analysis, a few additional mechanisms are also recommended below. 6.1. Storage There are a few dimensions to authorizing the storage of PASSporTs. Encrypting PASSporTs prior to storage entails that a CPS has no way to tell if a PASSporT is valid; it simply conveys encrypted blocks that it cannot access itself, and can make no authorization decision based on the PASSporT contents. There is certainly no prospect for the CPS to verify the PASSporTs itself. Note that this architecture requires clients that store PASSporTs to have access to an encryption key associated with the intended called party to be used to encrypt the PASSporT. Discovering this key requires the existence of a key lookup service (see Section 11); depending on how the CPS is architected, however, some kind of key store or repository could be implemented adjacent to it, and perhaps even incorporated into its operation. Key discovery is made more complicated by the fact that there can potentially be multiple entities that have authority over a telephone number: a carrier, a reseller, an enterprise, and an end user might all have credentials permitting them to attest that they are allowed to originate calls from a number, say. PASSporTs for out-of-band use therefore might need to be encrypted with multiple keys in the hopes that one will be decipherable by the relying party. Again, the most obvious way to authorize storage is to require the originator to authenticate themselves to the CPS with their STIR credential. However, since the call is indexed at the CPS under the called number, this can weaken the privacy story of the architecture, as it reveals to the CPS both the identity of the caller and the callee. Moreover, it does not work for the gateway use cases Rescorla & Peterson Expires September 10, 2020 [Page 10] Internet-Draft STIR Out-of-Band March 2020 described above; to support those use cases, we must effectively allow any entity to store PASSporTs at a CPS. This does not degrade the anti-impersonation security of STIR, because entities who do not possess the necessary credentials to sign the PASSporT will not be able to create PASSporTs that will be treated as valid by verifiers. In this architecture, it does not matter whether the CPS received a PASSporT from the authentication service that created it or from an intermediary gateway downstream in the routing path as in case 4 above. However, if literally anyone can store PASSporTs in the CPS, an attacker could easily flood the CPS with millions of bogus PASSporTs indexed under a calling number, and thereby prevent the called party from finding a valid PASSporT for an incoming call buried in a haystack of fake entries. The solution architecture must therefore include some sort of traffic control system to prevent flooding. Preferably, this should not require authenticating the source, as this will reveal to the CPS both the source and destination of traffic. A potential solution is discussed below in Section 7.5. 6.2. Retrieval For retrieval of PASSporTs, this architecture assumes that clients will contact the CPS through some sort of polling or notification interface to receive all current PASSporTs for calls destined to a particular telephone number, or block of numbers. As PASSporTs stored at the CPS are encrypted with a key belonging to the intended destination, the CPS can safely allow anyone to download PASSporTs for a called number without much fear of compromising private information about calls in progress - provided that the CPS always returns at least one encrypted blob in response to a request, even if there was no call in progress. Otherwise, entities could poll the CPS constantly, or eavesdrop on traffic, to learn whether or not calls were in progress. The CPS MUST generate at least one unique and plausible encrypted response to all retrieval requests, and these dummy encrypted PASSporTs MUST NOT be repeated for later calls. An encryption scheme needs to be carefully chosen to make messages look indistinguishable from random when encrypted, so that information about called party is not discoverable from legitimate encrypted PASSporTs. Because the entity placing a call may discover multiple keys associated with the called party number, multiple valid PASSporTs may be stored in the CPS. A particular called party who retrieves PASSporTs from the CPS may have access to only one of those keys. Thus, the presence of one or more PASSporTs that the called party cannot decrypt - which would be indistinguishable from the "dummy" Rescorla & Peterson Expires September 10, 2020 [Page 11] Internet-Draft STIR Out-of-Band March 2020 PASSporTS created by the CPS when no calls are in progress - does not entail that there is no call in progress. A retriever likely will need to decrypt all PASSporTs retrieved from the CPS, and may find only one that is valid. In order to prevent the CPS from learning the numbers that a callee controls, callees might also request PASSporTs for numbers that they do not own, that they have no hope of decrypting. Implementations could even allow a callee to request PASSporTs for a range or prefix of numbers: a trade-off where that callee is willing to sift through bulk quantities of undecryptable PASSporTs for the sake of hiding from the CPS what numbers it controls. Note that in out-of-band call forwarding cases, special behavior is required to manage the relationship between PASSporTs using the diversion extension [I-D.ietf-stir-passport-divert]. The originating authentication service would encrypt the initial PASSporT with the public encryption key of the intended destination, but once a call is forwarded, it may go to a destination that does not possess the corresponding private key and thus could not decrypt the original PASSporT. This requires the retargeting entity to generate encrypted PASSporTs that show a secure chain of diversion: a retargeting storer SHOULD use the "div-o" PASSporT type, with its "opt" extension, as specified in [I-D.ietf-stir-passport-divert] in order to nest the original PASSporT within the encrypted diversion PASSporT. 7. Solution Architecture In this section, we discuss a high-level architecture for providing the service described in the previous sections. This discussion is deliberately sketchy, focusing on broad concepts and skipping over details. The intent here is merely to provide an overall architecture, not an implementable specification. A more concrete example of how this might be specified is given in Section 9. 7.1. Credentials and Phone Numbers We start from the premise of the STIR problem statement [RFC7340] that phone numbers can be associated with credentials which can be used to attest ownership of numbers. For purposes of exposition, we will assume that ownership is associated with the endpoint (e.g., a smartphone) but it might well be associated with a provider or gateway acting for the endpoint instead. It might be the case that multiple entities are able to act for a given number, provided that they have the appropriate authority. [RFC8226] describes a credential system suitable for this purpose; the question of how an entity is determined to have control of a given number is out of scope for the current document. Rescorla & Peterson Expires September 10, 2020 [Page 12] Internet-Draft STIR Out-of-Band March 2020 7.2. Call Flow An overview of the basic calling and verification process is shown below. In this diagram, we assume that Alice has the number +1.111.555.1111 and Bob has the number +2.222.555.2222. Alice Call Placement Service Bob -------------------------------------------------------------------- Store Encrhypted PASSporT for 2.222.555.2222 -> Call from 1.111.555.1111 ------------------------------------------> <-------------- Request PASSporT(s) for 2.222.555.2222 Obtain Encrypted PASSporT --------> (2.222.555.2222, 1.111.555.1111) [Ring phone with verified callerid = 1.111.555.1111] When Alice wishes to make a call to Bob, she contacts the CPS and stores an encrypted PASSporT on the CPS indexed under Bob's number. The CPS then awaits retrievals for that number. When Alice places the call, Bob's phone would usually ring and display Alice's number (+1.111.555.1111), which is informed by the existing PSTN mechanisms for relaying a calling party number (e.g., the CIN field of the IAM). Instead, Bob's phone transparently contacts the CPS and requests any current PASSporTs for calls to his number. The CPS responds with any such PASSporTs (or dummy PASSporTs if no relevant ones are currently stored). If such a PASSporT exists, and the verification service in Bob's phone decrypts it using his private key, validates it, then Bob's phone can present the calling party number information as valid. Otherwise, the call is unverifiable. Note that this does not necessarily mean that the call is bogus; because we expect incremental deployment, many legitimate calls will be unverifiable. 7.3. Security Analysis The primary attack we seek to prevent is an attacker convincing the callee that a given call is from some other caller C. There are two scenarios to be concerned with: Rescorla & Peterson Expires September 10, 2020 [Page 13] Internet-Draft STIR Out-of-Band March 2020 1. The attacker wishes to impersonate a target when no call from that target is in progress. 2. The attacker wishes to substitute himself for an existing call setup. If an attacker can inject fake PASSporTs into the CPS or in the communication from the CPS to the callee, he can mount either attack. As PASSporTs should be digitally signed by an appropriate authority for the number and verified by the callee (see Section 7.1), this should not arise in ordinary operations. Any attacker who is aware of calls in progress can attempt to mount a race to subtitute themselves as described in Section 7.4. For privacy and robustness reasons, using TLS [RFC8446] on the originating side when storing the PASSporT at the CPS is RECOMMENDED. The entire system depends on the security of the credential infrastructure. If the authentication credentials for a given number are compromised, then an attacker can impersonate calls from that number. However, that is no different from in-band [RFC8224] STIR. A secondary attack we must also prevent is denial-of-service against the CPS, which requires some form of rate control solution that will not degrade the privacy properties of the architecture. 7.4. Substitution Attacks All the receipt of the PASSporT from the CPS proves to the called party is that Alice is trying to call Bob (or at least was as of very recently) - it does not prove that any particular incoming call is from Alice. Consider the scenario in which we have a service which provides an automatic callback to a user-provided number. In that case, the attacker can try to arrange for a false caller-id value, as shown below: Rescorla & Peterson Expires September 10, 2020 [Page 14] Internet-Draft STIR Out-of-Band March 2020 Attacker Callback Service CPS Bob -------------------------------------------------------------------- Place call to Bob ----------> (from 111.555.1111) Store PASSporT for CS:Bob -------------> Call from Attacker (forged CS caller-id info) --------------------> Call from CS ------------------------> X <-- Retrieve PASSporT for CS:Bob PASSporT for CS:Bob ------------------------> [Ring phone with callerid = 111.555.1111] In order to mount this attack, the attacker contacts the Callback Service (CS) and provides it with Bob's number. This causes the CS to initiate a call to Bob. As before, the CS contacts the CPS to insert an appropriate PASSporT and then initiates a call to Bob. Because it is a valid CS injecting the PASSporT, none of the security checks mentioned above help. However, the attacker simultaneously initiates a call to Bob using forged caller-id information corresponding to the CS. If he wins the race with the CS, then Bob's phone will attempt to verify the attacker's call (and succeed since they are indistinguishable) and the CS's call will go to busy/voice mail/call waiting. In order to prevent a passive attacker from using traffic analysis or similar means to learn precisely when a call is placed, it is essential that the connection between the caller and the CPS be encrypted as recommended above. Authentication services could store dummy PASSporTs at the CPS at random intervals in order to make it more difficult for an eavesdropper to use traffic analysis to determine that a call was about to be placed. Note that in a SIP environment, the callee might notice that there were multiple INVITEs and thus detect this attack, but in some PSTN interworking scenarios, or highly intermediated networks, only one call setup attempt will reach the target. Also note that the success of this substitution attack depends on the attacker landing their call within the narrow window that the PASSporT is retained in the CPS, so shortening that window will reduce the opportunity for the attack. Finally, smart endpoints could implement some sort of state Rescorla & Peterson Expires September 10, 2020 [Page 15] Internet-Draft STIR Out-of-Band March 2020 coordination to ensure that both sides believe the call is in progress, though methods of supporting that are outside the scope of this document. 7.5. Rate Control for CPS Storage In order to prevent the flooding of a CPS with bogus PASSporTs, we propose the use of "blind signatures" (see [RFC5636]). A sender will initially authenticate to the CPS using its STIR credentials, and acquire a signed token from the CPS that will be presented later when storing a PASSporT. The flow looks as follows: Sender CPS Authenticate to CPS ---------------------> Blinded(K_temp) -------------------------> <------------- Sign(K_cps, Blinded(K_temp)) [Disconnect] Sign(K_cps, K_temp) Sign(K_temp, E(K_receiver, PASSporT)) ---> At an initial time when no call is yet in progress, a potential client connects to the CPS, authenticates, and sends a blinded version of a freshly generated public key. The CPS returns a signed version of that blinded key. The sender can then unblind the key and gets a signature on K_temp from the CPS. Then later, when a client wants to store a PASSporT, it connects to the CPS anonymously (preferably over a network connection that cannot be correlated with the token acquisition) and sends both the signed K_temp and its own signature over the encrypted PASSporT. The CPS verifies both signatures and if they verify, stores the encrypted passport (discarding the signatures). This design lets the CPS rate limit how many PASSporTs a given sender can store just by counting how many times K_temp appears; perhaps CPS policy might reject storage attempts and require acquisition of a new K_temp after storing more than a certain number of PASSporTs indexed under the same destination number in a short interval. This does not of course allow the CPS to tell when bogus data is being provisioned by an attacker, simply the rate at which data is being provisioned. Potentially, feedback mechanisms could be developed that would allow the called parties to tell the CPS when they are receiving unusual or bogus PASSporTs. Rescorla & Peterson Expires September 10, 2020 [Page 16] Internet-Draft STIR Out-of-Band March 2020 This architecture also assumes that the CPS will age out PASSporTs. A CPS SHOULD NOT keep any stored PASSporT for no longer than a value that might be selected for the verification service policy for freshness of the "iat" value as described in [RFC8224] (i.e. sixty seconds). Any reduction in this window makes substitution attacks (see Section 7.4) harder to mount, but making the window too small might conceivably age PASSporTs out while a heavily redirected call is still alerting. An alternative potential approach to blind signatures would be the use of oblivious pseudorandom functions (VOPRFs, per [I-D.privacy-pass]), which move prove faster. 8. Authentication and Verification Service Behavior for Out-of-Band [RFC8224] defines an authentication service and a verification service as functions that act in the context of SIP requests and responses. This specification thus provides a more generic description of authentication service and verification service behavior that might or might not involve any SIP transactions, but depends only on placing a request for communications from an originating identity to one or more destination identities. 8.1. Authentication Service (AS) Out-of-band authentication services perform steps similar to those defined in [RFC8224] with some exceptions: Step 1: The authentication service MUST determine whether it is authoritative for the identity of the originator of the request, that is, the identity it will populate in the "orig" claim of the PASSporT. It can do so only if it possesses the private key of one or more credentials that can be used to sign for that identity, be it a domain or a telephone number or some other identifier. For example, the authentication service could hold the private key associated with a STIR certificate [RFC8225]. Step 2: The authentication service MUST determine that the originator of communications can claim the originating identity. This is a policy decision made by the authentication service that depends on its relationship to the originator. For an out-of-band application built-in to the calling device, for example, this is the same check performed in Step 1: does the calling device hold a private key, one corresponding to a STIR certificate, that can sign for the originating identity? Step 3: The authentication service MUST acquire the public encryption key of the destination, which will be used to encrypt the PASSporT Rescorla & Peterson Expires September 10, 2020 [Page 17] Internet-Draft STIR Out-of-Band March 2020 (see Section 11). It MUST also discover (see Section 10) the CPS associated with the destination. The authentication service may already have the encryption key and destination CPS cached, or may need to query a service to acquire the key. Note that per Section 7.5 the authentication service may also need to acquire a token for PASSporT storage from the CPS upon CPS discovery. It is anticipated that the discovery mechanism (see Section 10) used to find the appropriate CPS will also find the proper key server for the public key of the destination. In some cases, a destination may have multiple public encryption keys associated with it. In that case, the authentication service MUST collect all of those keys. Step 4: The authentication service MUST create the PASSporT object. This includes acquiring the system time to populate the "iat" claim, and populating the "orig" and "dest" claims as described in [RFC8225]. The authentication service MUST then encrypt the PASSporT. If in Step 3 the authentication service discovered multiple public keys for the destination, it MUST create one encrypted copy for each public key it discovered. Finally, the authentication service stores the encrypted PASSporT(s) at the CPS discovered in Step 3. Only after that is completed should any call be initiated. Note that a call might be initiated over SIP, and the authentication service would place the same PASSporT in the Identity header field value of the SIP request - though SIP would carry a cleartext version rather than an encrypted version sent to the CPS. In that case, out-of-band would serve as a fallback mechanism in case the request was not conveyed over SIP end-to-end. Also, note that the authentication service MAY use a compact form of the PASSporT for a SIP request, whereas the version stored at the CPS MUST always be a full form PASSporT. 8.2. Verification Service (VS) When a call arrives, an out-of-band verification service performs steps similar to those defined in [RFC8224] with some exceptions: Step 1: The verification service contacts the CPS and requests all current PASSporTs for its destination number; or alternatively it may receive PASSporTs through a push interface from the CPS in some deployments. The verification service MUST then decrypt all PASSporTs using its private key. Some PASSporTs may not be decryptable for any number of reasons: they may be intended for a different verification service, or they may be "dummy" values inserted by the CPS for privacy purposes. The next few steps will narrow down the set of PASSporTs that the verification service will examine from that initial decryptable set. Rescorla & Peterson Expires September 10, 2020 [Page 18] Internet-Draft STIR Out-of-Band March 2020 Step 2: The verification service MUST determine if any "ppt" extensions in the PASSporTs are unsupported. It takes only the set of supported PASSporTs and applies the next step to them. Step 3: The verification service MUST determine if there is an overlap between the calling party number presented in call signaling and the "orig" field of any decrypted PASSporTs. It takes the set of matching PASSporTs and applies the next step to them. Step 4: The verification service MUST determine if the credentials that signed each PASSporT are valid, and if the verification service trusts the CA that issued the credentials. It takes the set of trusted PASSporTs to the next step. Step 5: The verification service MUST check the freshness of the "iat" claim of each PASSporT. The exact interval of time that determines freshness is left to local policy. It takes the set of fresh PASSporTs to the next step. Step 6: The verification service MUST check the validity of the signature over each PASSporT, as described in [RFC8225]. Finally, the verification service will end up with one or more valid PASSporTs corresponding to the call it has received. In keeping with baseline STIR, this document does not dictate any particular treatment of calls that have valid PASSporTs associated with them; the handling of the call after the verification process depends on how the verification service is implemented and on local policy. However, it is anticipated that local policies could involve making different forwarding decisions in intermediary implementations, or changing how the user is alerted or how identity is rendered in UA implementations. 8.3. Gateway Placement Services The STIR out-of-band mechanism also supports the presence of gateway placement services, which do not create PASSporTs themselves, but instead take PASSporTs out of signaling protocols and store them at a CPS before gatewaying to a protocol that cannot carry PASSporTs itself. For example, a SIP gateway that sends calls to the PSTN could receive a call with an Identity header field, extract a PASSporT from the Identity header field, and store that PASSporT at a CPS. To place a PASSporT at a CPS, a gateway MUST perform Step 3 of Section 8.1 above: that is, it must discover the CPS and public key associated with the destination of the call, and may need to acquire a PASSporT storage token (see Section 6.1). Per Step 3 of Rescorla & Peterson Expires September 10, 2020 [Page 19] Internet-Draft STIR Out-of-Band March 2020 Section 8.1 this may entail discovering several keys. The gateway then collects the in-band PASSporT(s) from the in-band signaling, encrypts the PASSporT(s), and stores them at the CPS. A similar service could be performed by a gateway that retrieves PASSporTs from a CPS and inserts them into signaling protocols that support carrying PASSporTS in-band. This behavior may be defined by future specifications. 9. Example HTTPS Interface to the CPS As a rough example, we show a Call Placement Service implementation here which uses a REST API to store and retrieve objects at the CPS. The calling party stores the PASSporT at the CPS prior to initiating the call; the PASSporT is stored at a location at the CPS that corresponds to the called number. Note that it is possible for multiple parties to be calling a number at the same time, and that for called numbers such as large call centers, many PASSporTs could legitimately be stored simultaneously, and it might prove difficult to correlate these with incoming calls. Assume that an authentication service has created the following PASSporT for a call to the telephone number 2.222.555.2222 (note that these are dummy values): eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ Through some discovery mechanism (see Section 10), the authentication service discovers the network location of a web service that acts as the CPS for 2.222.555.2222. Through the same mechanism, we will say that it has also discovered one public encryption key for that destination. It uses that encryption key to encrypt the PASSporT, resulting in the encrypted PASSporT: rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j Having concluded the numbered steps in Section 8.1, including acquiring any token (per Section 6.1) needed to store the PASSporT at the CPS, the authentication service then stores the encrypted PASSporT: Rescorla & Peterson Expires September 10, 2020 [Page 20] Internet-Draft STIR Out-of-Band March 2020 POST /cps/2.222.555.2222/ppts HTTP/1.1 Host: cps.example.com Content-Type: application/passport rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j The web service assigns a new location for this encrypted PASSporT in the collection, returning a 201 OK with the location of /cps/2.222.222.2222/ppts/ppt1. Now the authentication service can place the call, which may be signaled by various protocols. Once the call arrives at the terminating side, a verification service contacts its CPS to ask for the set of incoming calls for its telephone number (2.222.222.2222). GET /cps/2.222.555.2222/ppts Host: cps.example.com This returns to the verification service a list of the PASSporTs currently in the collection, which currently consists of only /cps/2.222.222.2222/ppts/ppt1. The verification service then sends a new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields: HTTP/1.1 200 OK Content-Type: application/passport Link: rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j That concludes Step 1 of Section 8.2; the verification service then goes on to the next step, processing that PASSporT through its various checks. A complete protocol description for CPS interactions is left to future work. 10. CPS Discovery In order for the two ends of the out-of-band dataflow to coordinate, they must agree on a way to discover a CPS and retrieve PASSporT objects from it based solely on the rendezvous information available: the calling party number and the called number. Because the storage of PASSporTs in this architecture is indexed by the called party Rescorla & Peterson Expires September 10, 2020 [Page 21] Internet-Draft STIR Out-of-Band March 2020 number, it makes sense to discover a CPS based on the called party number as well. There are a number of potential service discovery mechanisms that could be used for this purpose. The means of service discovery may vary by use case. Although the discussion above is written largely in terms of a single CPS, having a significant fraction of all telephone calls result in storing and retrieving PASSporTs at a single monolithic CPS has obvious scaling problems, and would as well allow the CPS to gather metadata about a very wide set of callers and callees. These issues can be alleviated by operational models with a federated CPS; any service discovery mechanism for out-of-band STIR should enable federation of the CPS function. Likely models include ones where a carrier operates one or more CPS instances on behalf of its customers, enterprises run a CPS instance on behalf of their PBX users, or where third-party service providers offer a CPS as a cloud service. Some service discovery possibilities under consideration include the following: For some deployments in closed (e.g. intranetwork) environments, the CPS location can simply be provisioned in implementations, obviating the need for a discovery protocol. If a credential lookup service is already available (see Section 11), the CPS location can also be recorded in the callee's credentials; an extension to [RFC8226] could for example provide a link to the location of the CPS where PASSporTs should be stored for a destination. There exist a number of common directory systems that might be used to translate telephone numbers into the URIs of a CPS. ENUM [RFC6116] is commonly implemented, though no "golden root" central ENUM administration exists that could be easily reused today to help the endpoints discover a common CPS. Other protocols associated with queries for telephone numbers, such as the TeRI [I-D.ietf-modern-teri] protocol, could also serve for this application. Another possibility is to use a single distributed service for this function. VIPR [I-D.jennings-vipr-overview] proposed a RELOAD [RFC6940] usage for telephone numbers to help direct calls to enterprises on the Internet. It would be possible to describe a similar RELOAD usage to identify the CPS where calls for a particular telephone number should be stored. One advantage that the STIR architecture has over VIPR is that it assumes a credential system that proves authority over telephone numbers; Rescorla & Peterson Expires September 10, 2020 [Page 22] Internet-Draft STIR Out-of-Band March 2020 those credentials could be used to determine whether or not a CPS could legitimately claim to be the proper store for a given telephone number. This document does not prescribe any single way to do service discovery for a CPS; it is envisioned that initial deployments will provision the location of the CPS at the Authentication Service and Verification Service. 11. Encryption Key Lookup In order to encrypt a PASSporT (see Section 6.1), the caller needs access to the callee's public encryption key. Note that because STIR uses ECDSA for signing PASSporTs, the public key used to verify PASSporTs is not suitable for this function, and thus the encryption key must be discovered separately. This requires some sort of directory/lookup system. Some initial STIR deployments have fielded certificate repositories so that verification services can acquire the signing credentials for PASSporTs, which are linked through a URI in the "x5u" element of the PASSporT. These certificate repositories could clearly be repurposed for allowing authentication services to download the public encryption key for the called party - provided they can be discovered by calling parties. This document does not specify any particular discovery scheme, but instead offers some general guidance about potential approaches. It is a desirable property that the public encryption key for a given party be linked to their STIR credential. An ECDH [RFC7748] public- private key pair might be generated for a subcert [I-D.ietf-tls-subcerts] of the STIR credential. That subcert could be looked up along with the STIR credential of the called party. Further details of this subcert, and the exact lookup mechanism involved, are deferred for future protocol work. Obviously, if there is a single central database that the caller and callee each access in real time to download the other's keys, then this represents a real privacy risk, as the central key database learns about each call. A number of mechanisms are potentially available to mitigate this: Have endpoints pre-fetch keys for potential counterparties (e.g., their address book or the entire database). Have caching servers in the user's network that proxy their fetches and thus conceal the relationship between the user and the keys they are fetching. Rescorla & Peterson Expires September 10, 2020 [Page 23] Internet-Draft STIR Out-of-Band March 2020 Clearly, there is a privacy/timeliness tradeoff in that getting up- to-date knowledge about credential validity requires contacting the credential directory in real-time (e.g., via OCSP [RFC2560]). This is somewhat mitigated for the caller's credentials in that he can get short-term credentials right before placing a call which only reveals his calling rate, but not who he is calling. Alternately, the CPS can verify the caller's credentials via OCSP, though of course this requires the callee to trust the CPS's verification. This approach does not work as well for the callee's credentials, but the risk there is more modest since an attacker would need to both have the callee's credentials and regularly poll the database for every potential caller. We consider the exact best point in the tradeoff space to be an open issue. 12. Acknowledgments The ideas in this document come out of discussions with Richard Barnes and Cullen Jennings. We'd also like to thank Russ Housley, Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang, Jonathan Rosenberg and Robert Sparks for helpful suggestions. 13. IANA Considerations This memo includes no request to IANA. 14. Privacy Considerations Delivering PASSporTs out-of-band offers a different set of privacy properties than traditional in-band STIR. In-band operations convey PASSporTs as headers in SIP messages in cleartext, which any forwarding intermediaries can potentially inspect. By contrast, out- of-band STIR stores these PASSporTs at a service after encrypting them as described in Section 6, effectively creating a path between the authentication and verification service in which the CPS is the sole intermediary, but the CPS cannot read the PASSporTs. Potentially, out-of-band PASSporT delivery could thus improve on the privacy story of STIR. The principle actors in the operation of out-of-band are the AS, VS, and CPS. The AS and VS functions differ from baseline [RFC8224] behavior, in that they interact with an CPS over a non-SIP interface, of which the REST interface in Section 9 serves as an example. Some out-of-band deployments may also require a discovery service for the CPS itself (Section 10) and/or encryption keys (Section 11). Even with encrypted PASSporTs, the network interactions by which the AS and VS interact with the CPS, and to a lesser extent any discovery Rescorla & Peterson Expires September 10, 2020 [Page 24] Internet-Draft STIR Out-of-Band March 2020 services, thus create potential opportunities for data leakage about calling and called parties. The process of storing and retrieving PASSporTs at a CPS can itself reveal information about calls being placed. The mechanism takes care not to require that the AS authenticate itself to the CPS, relying instead on a blind signature mechanism for flood control prevention. Section 7.4 discusses the practice of storing "dummy" PASSporTs at random intervals to thwart traffic analysis, and as Section 8.2 notes, a CPS is required to return a dummy PASSporT even if there is no PASSporT indexed for that calling number, which similarly enables the retrieval side to randomly request PASSporTs when there are no calls in progress. These measures can help to mitigiate information disclosure in the system. In implementations that require service discovery (see Section 10), perhaps through key discovery (Section 11), similar measures could be used to make sure that service discovery does not itself disclose information about calls. Ultimately, this document only provides a framework for future implementation of out-of-band systems, and the privacy properties of a given implementation will depend on architectural assumptions made in those environments. More closed systems for intranet operations may adopt a weaker security posture but otherwise mitigate the risks of information disclosure, where more open environment will require careful implementation of the practices described here. For general privacy risks associated with the operations of STIR, also see the Privacy Considerations of [RFC8224]. 15. Security Considerations This entire document is about security, but the detailed security properties will vary depending on how the framework is applied and deployed. General guidance for dealing with the most obvious security challenges posed by this framework is given in Section 7.3 and Section 7.4, along proposed solutions for problems like denial- of-service attacks or traffic analysis against the CPS. Although there are considerable security challenges associated with widespread deployment of a public CPS, those must be weighed against the potential usefulness of a service that delivers a STIR assurance without requiring the passage of end-to-end SIP. Ultimately, the security properties of this mechanism are at least comparable to in- band STIR: the substitution attack documented in Section 7.4 could be implemented by any in-band SIP intermediary or eavesdropper who happened to see the PASSporT in transit, say, and launch its own call Rescorla & Peterson Expires September 10, 2020 [Page 25] Internet-Draft STIR Out-of-Band March 2020 with a copy of that PASSporT to race against the original to the destination. 16. Informative References [I-D.ietf-modern-teri] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", draft-ietf-modern- teri-00 (work in progress), July 2018. [I-D.ietf-stir-passport-divert] Peterson, J., "PASSporT Extension for Diverted Calls", draft-ietf-stir-passport-divert-07 (work in progress), November 2019. [I-D.ietf-tls-subcerts] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS", draft-ietf-tls- subcerts-06 (work in progress), February 2020. [I-D.jennings-vipr-overview] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- Huguenin, "Verification Involving PSTN Reachability: Requirements and Architecture Overview", draft-jennings- vipr-overview-06 (work in progress), December 2013. [I-D.privacy-pass] Davidson, A. and N. Sullivan, "The Privacy Pass Protocol", draft-privacy-pass-00 (work in progress), November 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, DOI 10.17487/RFC2560, June 1999, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . Rescorla & Peterson Expires September 10, 2020 [Page 26] Internet-Draft STIR Out-of-Band March 2020 [RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent, "Traceable Anonymous Certificate", RFC 5636, DOI 10.17487/RFC5636, August 2009, . [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, . [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, January 2014, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . Rescorla & Peterson Expires September 10, 2020 [Page 27] Internet-Draft STIR Out-of-Band March 2020 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Authors' Addresses Eric Rescorla Mozilla Email: ekr@rtfm.com Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@team.neustar Rescorla & Peterson Expires September 10, 2020 [Page 28]./draft-ietf-stir-passport-divert-09.txt0000644000764400076440000014140513703071675017524 0ustar iustyiusty Network Working Group J. Peterson Internet-Draft Neustar Updates: RFC8224 (if approved) July 13, 2020 Intended status: Standards Track Expires: January 14, 2021 PASSporT Extension for Diverted Calls draft-ietf-stir-passport-divert-09 Abstract PASSporT is specified in RFC 8225 to convey cryptographically-signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 14, 2021. Copyright Notice Copyright (c) 2020 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 (https://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 Peterson Expires January 14, 2021 [Page 1] Internet-Draft PASSporT Diverted July 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The 'div' PASSporT Type and Claim . . . . . . . . . . . . . . 4 4. Using 'div' in SIP . . . . . . . . . . . . . . . . . . . . . 6 4.1. Authentication Service Behavior . . . . . . . . . . . . . 6 4.2. Verification Service Behavior . . . . . . . . . . . . . . 8 5. The 'div-o' PASSporT Type . . . . . . . . . . . . . . . . . . 10 5.1. Processing 'div-o' PASSporTs . . . . . . . . . . . . . . 12 6. Definition of 'opt' . . . . . . . . . . . . . . . . . . . . . 13 7. 'div' and Redirection . . . . . . . . . . . . . . . . . . . . 13 8. Extending 'div' to work with Service Logic Tracking . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10.1. JSON Web Token Claims Registrations . . . . . . . . . . 15 10.1.1. 'div' registration . . . . . . . . . . . . . . . . . 15 10.1.2. 'opt' registration . . . . . . . . . . . . . . . . . 16 10.2. PASSporT Type Registrations . . . . . . . . . . . . . . 16 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Appendix A: Keys for Examples . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction A Personal Assertion Token (PASSporT [RFC8225]) is a token format based on the JSON Web Token (JWT [RFC7519]) for conveying cryptographically-signed information about the people involved in personal communications; it is used by the Secure Telephone Identity Revisited (STIR [RFC8224]) protocol to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. Although the STIR problem statement [RFC7340] is focused on preventing the impersonation of the caller's identity, which is a common enabler for threats such as robocalling and voicemail hacking on the telephone network today, it also provides a signature over the Peterson Expires January 14, 2021 [Page 2] Internet-Draft PASSporT Diverted July 2020 called number at the time that the authentication service sees it. As [RFC8224] Section 12.1 describes, this protection over the contents of the To header field is intended to prevent a class of cut-and-paste attacks. If Alice calls Bob, for example, Bob might attempt to cut-and-paste the Identity header field in Alice's INVITE into a new INVITE that Bob sends to Carol, and thus be able to fool Carol into thinking the call came from Alice and not Bob. With the signature over the To header field value, the INVITE Carol sees will clearly have been destined originally for Bob, and thus Carol can view the INVITE as suspect. However, as [RFC8224] Section 12.1.1 points out, it is difficult for Carol to confirm or reject these suspicions based on the information she receives from the baseline PASSporT object. The common "call forwarding" service serves as a good example of the reality that the original called party number is not always the number to which a call is delivered. There are a number of potential ways for intermediaries to indicate that such a forwarding operating has taken place. The address in the To header field value of SIP requests is not supposed to change, according to baseline SIP behavior [RFC3261]; instead, it is the Request-URI that is supposed to be updated when a call is retargeted. Practically speaking, however, many operational environments do alter the To header field. The History-Info header field [RFC7044] was created to store the Request-URIs that are discarded by a call in transit. The SIP Diversion header field [RFC5806], though historic, is still used for this purpose by some operators today. Neither of these header fields provide any cryptographic assurance of secure redirection, and they both record entries for minor syntactical changes in URIs that do not reflect a change to the actual target of a call. This specification therefore extends PASSporT with an explicit indication that the original called number in PASSporT no longer reflects the destination to which a call is intended to be delivered. For this purpose, it specifies a Divert PASSporT type ("div") for use in common SIP retargeting cases; it is expected that in this case, SIP INVITE requests will carry multiple Identity header fields, each containing its own PASSporT. Throughout this document, PASSporTs that contain a "div" element will be referred to as "div" PASSporTs. Verification services and the relying parties who make authorization decisions about communications may use this diversion indication to confirm that a legitimate retargeting of the call has taken place, rather than a cut-and-paste attack. For out-of-band [I-D.ietf-stir-oob] use cases, and other non-SIP applications of PASSporT, a separate "div-o" PASSporT type is also specified, which defines an "opt" PASSporT element for carrying nested PASSporTs within a PASSporT. These shall in turn be referred to in this document as "div-o" PASSporTs. Peterson Expires January 14, 2021 [Page 3] Internet-Draft PASSporT Diverted July 2020 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The 'div' PASSporT Type and Claim This specification defines a PASSporT [RFC8225] type called "div" that may be employed by authentication services located at retargeting entities. All "div" PASSporTs MUST contain a new JSON Web Token "div" claim, also specified in this document, which indicates a previous destination for a call during its routing process. When a retargeting entity receives a call signed with a PASSporT, it may act as an authentication service and create a new PASSporT containing the "div" claim to attach to the call. Note that a new PASSporT is only necessary when the canonical form of the "dest" identifier (per the canonicalization procedures in [RFC8224] Section 8.3) changes due to this retargeting. If the canonical form of the "dest" identifier is not changed during retargeting, then a new PASSporT with a "div" claim MUST NOT be produced. The headers of the new PASSporTs generated by retargeting entities MUST include the "div" PASSporT type, and an "x5u" field pointing to a credential that the retargeting entity controls. "div" PASSporTs MUST use full form instead of compact form. The new PASSporT header will look as follows: { "typ":"passport", "ppt":"div", "alg":"ES256", "x5u":"https://www.example.com/cert.cer" } A "div" PASSporT claims set is populated with elements drawn from the PASSporT(s) received for a call by the retargeting entity: at a high level, the original identifier for the called party in the "dest" object will become the "div" claim in the new PASSporT. If the "dest" object of the original PASSporT contains multiple identifiers, because it contains one or more name/value pairs with an array as its value, the retargeting entity MUST select only one identifier from the value(s) of the "dest" object to occupy the value of the "div" field in the new PASSporT. Moreover, it MUST select an identifier that is within the scope of the credential that the retargeting Peterson Expires January 14, 2021 [Page 4] Internet-Draft PASSporT Diverted July 2020 entity will specify in the "x5u" of the PASSporT header (as described below). The new target for the call selected by the retargeting entity becomes the value of the "dest" object of the new PASSporT. The "orig" object MUST be copied into the new PASSporT from the original PASSporT received by the retargeting entity. The retargeting entity SHOULD retain the "iat" object from the original PASSporT, though if in the underlying signaling protocol (e.g. SIP) the retargeting entity changes the date and time information in the retargeted request, the new PASSporT should instead reflect that date and time. No other claims or extensions are to be copied from the original PASSporT to the "div" PASSporT. So, for an original PASSporT claims set of the form: { "dest":{"tn":["12155551213"]}, "iat":1443208345, "orig":{"tn":"12155551212"} } If the retargeting entity is changing the target from 12155551213 to 12155551214, the claims set of a "div" PASSpoRT generated by the retargeting entity would look as follows: { "dest":{"tn":["12155551214"]}, "div":{"tn":"121555551213"}, "iat":1443208345, "orig":{"tn":"12155551212"} } The combined full form PASSporT (with a signature covered by the ES256 keys given in Appendix A) would look as follows: eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \ oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \ jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \ 0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \ J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \ SqIlk3yCNkg The same "div" PASSporT would result if the "dest" object of the original PASSporT contained an array value, such as {"tn":["12155551213","19995551234"]}, and the retargeting entity chose to retarget from the first telephone number in the array. Every "div" PASSporT is diverting from only one identifier. Note that the "div" element may contain other name/value pairs than just a destination, including a History-Info indicator (see Section 8). After the PASSporT header and claims have been Peterson Expires January 14, 2021 [Page 5] Internet-Draft PASSporT Diverted July 2020 constructed, their signature is generated per the guidance in [RFC8225] - except for the credential required to sign it. While in the ordinary construction of a PASSporT, the credential used to sign will have authority over the identity in the "orig" claim (for example, a certificate with authority over the telephone number in "orig" per [RFC8226]), for all PASSporTs using the "div" type the signature MUST be created with a credential with authority over the identity present in the "div" claim. So for the example above, where the original "dest" is "12155551213", the signer of the new PASSporT object MUST have authority over that telephone number, and need not have any authority over the telephone number present in the "orig" claim. Note that Identity header fields are not ordered in a SIP request, and in a case where there is a multiplicity of Identity header fields in a request, some sorting may be required to match "div" PASSporTs to their originals. PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6) element in their payload. 4. Using 'div' in SIP This section specifies SIP-specific usage for the "div" PASSporT type and its handling in the SIP Identity header field "ppt" parameter value. Other protocols using PASSporT may define behavior specific to their use of the "div" claim. 4.1. Authentication Service Behavior An authentication service only adds an Identity header field value containing the "div" PASSporT type to a SIP request that already contains at least one Identity header field value; it MUST NOT add a "div" PASSporT to an INVITE that contains no Identity header field. The retargeting entity SHOULD act as a verification service and validate the existing Identity header field value(s) in the request before proceeding; in some high-volume environments, it may instead put that burden of validating the chain entirely on the terminating verification service. As the authentication service will be adding a new PASSporT that refers to an original, it MUST NOT remove the original request's Identity header field value before forwarding. As was stated in Section 3, the authentication service MUST sign any "div" PASSporT with a credential that has a scope of authority covering the identity it populates in the "div" element value. Note that this is a significant departure from baseline STIR authentication service behavior, in which the PASSporT is signed by a credential with authority over the "orig" field. The "div" value Peterson Expires January 14, 2021 [Page 6] Internet-Draft PASSporT Diverted July 2020 reflects the URI that caused the call to be routed to the retargeting entity, so in ordinary operations, it would already be the STIR entity holding the appropriate private keying material for calls originating from that identity. A SIP authentication service typically will derive the "dest" element value of a "div" PASSporT from a new Request-URI that is set for the SIP request before it is forwarded. Older values of the Request-URI may appear in header fields like Diversion or History-Info; this document specifies an optional interaction with History-Info below in Section 8. Note as well that because PASSporT operates on canonicalized telephone numbers and normalized URIs, many smaller changes to the syntax of identifiers that might be captured by other mechanisms that record retargeting (like History-Info) will likely not require a "div" PASSporT. When adding an Identity header field with a PASSporT claims set containing a "div" claim, SIP authentication services MUST also add a "ppt" parameter to that Identity header with a value of "div". For the example PASSporT given in Section 3, the new Identity header added after retargeting might look as follows: Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0 \ Ijp7InRuIjpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMT \ MifSwiaWF0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0. \ xBHWipDEEJ8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxm \ ChHhVIiMTSqIlk3yCNkg; \ info=;ppt="div" Note that in some deployments, an authentication service will need to generate "div" PASSporTs for a request that contains multiple non-"div" Identity header field values. For example, a request arriving at a retargeting entity might contain in different Identity header fields a baseline [RFC8224] PASSporT and a PASSporT of type "rph" [RFC8443] signed by a separate authority. Provided that these PASSporTs share the same "orig" and "dest" values, the retargeting entity's authentication service SHOULD generate only one "div" PASSporT. If the "orig" or "dest" of these PASSporTs differ, however, one "div" PASSporT SHOULD be generated for each non-"div" PASSporT. Note that this effectively creates multiple chains of "div" PASSporTs in a single request, which complicates the procedures that need to be performed at verification services. Furthermore, a request may also be retargeted a second time, at which point the subsequent retargeting entity SHOULD generate one "div" Peterson Expires January 14, 2021 [Page 7] Internet-Draft PASSporT Diverted July 2020 PASSporT for each previous "div" PASSporT in the request which contains a "dest" object with the value of the current target - but not for "div" PASSporTs with earlier targets. Ordinarily, the current target will be readily identifiable, as it will be in the last "div" PASSporT in each chain, and in SIP cases it will correspond to the Request-URI received by the retargeting entity. Moreover, the current target will be an identifier that the retargeting entity possesses a credential to sign for, which may not be true for earlier targets. Ultimately, on each retargeting, the number of PASSporTs added to a request will be equal to the number of non-"div" PASSporTs that do not share the same "orig" and "dest" object values. 4.2. Verification Service Behavior [RFC8224] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional or alternative verifier behavior. The job of a SIP verification service handling one or more "div" PASSporTs is very different from that of a traditional verification service. At a high level, the immediate responsibility of the verification service is to extract all PASSporTs from the two or more Identity header fields in a request, identify which are "div" PASSporTs and which are not, and then order and link the "div" PASSporTs to the original PASSporT(s) in order to build one or more chains of retargeting. In order to validate a SIP request using the "div" PASSporT type, a verification service needs to inspect all of the valid Identity header field values associated with a request, as an Identity header field value containing "div" necessarily refers to an earlier PASSporT already in the message. For each "div" PASSporT, the verification service MUST find an earlier PASSporT that contains a "dest" claim with a value equivalent to the "div" claim in each "div" PASSporT. It is possible that this earlier PASSporT will also contain a "div", and that it will in turn chain to a still earlier PASSporT stored in a different Identity header field value. If a complete chain cannot be constructed, the verification service cannot complete "div" validation; it MAY still validate any non-"div" PASSporTs in the request per normal [RFC8224] procedures. If a chain has been successfully constructed, the verification service extracts from the outermost (that is, the most recent) PASSporT in the chain a "dest" field; this will be a "div" PASSporT that no other "div" PASSporT in the SIP request refers to. Its "dest" element value will be referred to in the procedures that follow as the value of the "outermost "dest" field." Ultimately, by looking at this chain of transformations and validating the associated signatures, the verification service will Peterson Expires January 14, 2021 [Page 8] Internet-Draft PASSporT Diverted July 2020 be able to ascertain that the appropriate parties were responsible for the retargeting of the call to its current destination. This can help the verification service to determine that the original PASSporT in the call was not simply used in a cut-and-paste attack and inform any associated authorization decisions in terms of how the call will be treated - though, per [RFC8224] Section 6.2.1, that decision is a matter of local policy and is thus outside the scope of this specification. A verification service parses a chain of PASSporTs as follows: First, the verification service MUST compare the value in the outermost "dest" field to the target of the call. As it is anticipated that SIP authentication services that create "div" PASSporTs will populate the "dest" header from the retargeted Request-URI (see Section 4.1), in ordinary SIP operations, the Request-URI is where verification services will find the latest call target. Note however that after a "div" PASSporT has been added to a SIP request, the Request-URI may have been updated during normal call processing to an identifier that no longer contains the logical destination of a call; in this case, the verification service MAY compare the "dest" field to a provisioned telephone number for the recipient. Second, the verification service MUST validate the signature over the outermost "div" PASSporT, and establish that the credential that signed the "div" PASSporT has the authority to attest for the identifier in the "div" element of the PASSporT (per [RFC8224] Section 6.2 Step 3). Third, the verification service MUST validate that the "orig" field of the innermost PASSporT of the chain (the only PASSporT in the chain which will not be of PASSporT type "div") is equivalent to the "orig" field of the outermost "div" PASSporT; in other words, that the original calling identifier has not been altered by retargeting authentication services. If the "orig" value has changed, the verification service MUST treat the entire PASSporT chain as invalid. The verification service MUST also verify that all other "div" PASSporTs in the chain share the same "orig" value. Then the verification service validates the relationship of the "orig" field to the SIP-level call signaling per the guidance in [RFC8224] Section 6.2 Step 2. Fourth, the verification service MUST check the date freshness in the outermost "div" PASSporT per [RFC8224] Section 6.2 Step 4. It is furthermore RECOMMENDED that the verification service check that the "iat" field of the innermost PASSporT is also within the date freshness interval; otherwise the verification service could Peterson Expires January 14, 2021 [Page 9] Internet-Draft PASSporT Diverted July 2020 allow attackers to replay an old, stale PASSporT embedded in a fresh "div". However, note that in some use cases, including certain ways that call transfers are implemented, it is possible that an established call will be retargeted long after it has originally been placed, and verification services may want to allow a longer window for the freshness of the innermost PASSporT if the call is transferred from a trusted party (as an upper bound, a freshness window on the order of three hours might suffice). Fifth, the verification service MUST inspect and validate the signatures on each and every PASSporT object in the chain between the outermost "div" PASSporT and the innermost PASSporT. Note that (per Section 4.1) a chain may terminate at more than one innermost PASSporT, in cases where a single "div" is used to retarget from multiple innermost PASSporTs. Also note that [RFC8224] Section 6.2 Step 1 applies to the chain validation process: if the innermost PASSporT contains an unsupported "ppt", its chain MUST be ignored. Note that the To header field is not used in the first step above. Optionally, the verification service MAY verify that the To header field value of the received SIP signaling is equal to the "dest" value in the innermost PASSporT; however, as has been observed in some deployments, the original To header field value may be altered by intermediaries to reflect changes of target. Deployments that change the original To header field value to conceal the original destination of the call from the ultimate recipient should note that the original destination of a call may be preserved in the innermost PASSporT. Future work on "div" might explore methods to implement that sort of policy while retaining a secure chain of redirection. 5. The 'div-o' PASSporT Type This specification defines a "div-o" PASSporT type that uses the "div" claim element in conjunction with the "opt" (Section 6) claim element. As is the case with "div" PASSporT type, a "div-o" PASSporT is created by an authentication service acting for a retargeting entity, but instead of generating a separate "div" PASSporT to be conveyed alongside an original PASSporT, the authentication service in this case embeds the original PASSporT inside the "opt" element of the "div-o" PASSporT. The "div-o" extension is designed for use in non-SIP or gatewayed SIP environments where the conveyance of PASSporTs in separate Identity header fields in impossible, such as out-of-band [I-D.ietf-stir-oob] STIR scenarios. The syntax of "div-o" PASSporTs is very similar to "div". A "div-o" PASSporT header object might look as follows: Peterson Expires January 14, 2021 [Page 10] Internet-Draft PASSporT Diverted July 2020 { "typ":"passport", "ppt":"div-o", "alg":"ES256", "x5u":"https://www.example.com/cert.cer" } Whereas a "div" PASSporT claims set contains only the "orig", "dest", "iat", and "div" elements, the "div-o" additionally MUST contain an "opt" element (see Section 6), which encapsulates the full form of the previous PASSporT from which the call was retargeted, triggering the generation of this "div-o". The format of the "opt" element is identical to the encoded PASSporT format given in Appendix A of [RFC8225]. So, for an original PASSporT claims set of the form: { "orig":{"tn":"12155551212"}, "dest":{"tn":["12155551213"]}, "iat":1443208345 } If the retargeting entity is changing the target from 12155551213 to 12155551214, the new PASSporT claims set for "div-o" would look as follows: { "orig":{"tn":"12155551212"}, "dest":{"tn":["12155551214"]}, "iat":1443208345, "div":{"tn":"121555551213"}, "opt":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0c \ HM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuIjpbIj \ EyMTU1NTUxMjEzIl19LCJpYXQiOjE0NDMyMDgzNDUsIm9yaWciOnsidG4iOiIxMj \ E1NTU1MTIxMiJ9fQ.1bEzkzcNbKvgz4QoMx0_DJ2T8qFMDC1sPqHPXl1WvbauzRJ \ RvYlZqQ0qgGTlS8tJ_wXjVe07Z3wvDrdApHhhYw" } While in ordinary operations, it is not expected that SIP would carry a "div-o" PASSporT, it might be possible in some gatewaying scenarios. The resulting full form Identity header field with a "div-o" PASSporT would look as follows: Peterson Expires January 14, 2021 [Page 11] Internet-Draft PASSporT Diverted July 2020 Identity:eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdi1vIiwidHlwIjoicGFzc3Bvc \ nQiLCJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLmNvbS9jZXJ0LmNlciJ9.eyJkZX \ N0Ijp7InRuIjoiMTIxNTU1NTEyMTQifSwiZGl2Ijp7InRuIjoiMTIxNTU1NTUxMjEz \ In0sImlhdCI6MTQ0MzIwODM0NSwib3B0IjoiZXlKaGJHY2lPaUpGVXpJMU5pSXNJbl \ I1Y0NJNkluQmhjM053YjNKMElpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGho \ YlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlEuZXlKa1pYTjBJanA3SW5SdUlqcGJJak \ V5TVRVMU5UVXhNakV6SWwxOUxDSnBZWFFpT2pFME5ETXlNRGd6TkRVc0ltOXlhV2Np \ T25zaWRHNGlPaUl4TWpFMU5UVTFNVEl4TWlKOWZRLjFiRXpremNOYkt2Z3o0UW9NeD \ BfREoyVDhxRk1EQzFzUHFIUFhsMVd2YmF1elJKUnZZbFpxUTBxZ0dUbFM4dEpfd1hq \ VmUwN1ozd3ZEcmRBcEhoaFl3Iiwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19.C \ HeA9wRnthl7paMe6rP0TARpmFCXjmi_vF_HRz2O_oulB_R-G9xZNiLVvmvHv4gk6LI \ LaDV2y2VtHTLIEgmHig; \ info=;ppt="div-o" 5.1. Processing 'div-o' PASSporTs The authentication and verification service procedures required for "div-o" closely follow the guidance given in Section 4.1 and Section 4.2, with the major caveats being first, that they do store or retrieve PASSporTs via the Identity header field values of SIP requests, and second, that they process nested PASSporTs in the "opt" claim element. But transposing the rest of the behaviors described above to creating and validating "div-o" PASSporTs is straightforward. For the "div-o" PASSporT type, retargeting authentication services that handle calls with one or more existing PASSporTs will create a corresponding "div-o" PASSporT for each received PASSporT. Each "div-o" PASSporT MUST contain an "opt" claim set element with the value of the original PASSporT from which the "div-o" was created; and as specified in Section 4.1, the authentication service MUST populate the "div" claim set element of the "div-o" PASSporT with the "dest" field fo the original PASSporT. Each received PASSporT may in turn contain its own "opt" claim set element, if the retargeting authentication service is not the first in its chain. Note that if the retargeting authentication service is handling a call with multiple PASSporTs, which in ordinary SIP operation would result in the construction of multiple "div" chains, it will in effect be generating one "div-o" PASSporT per chain. The job of a verification service is in many ways easier for "div-o" than for "div", as the verification service has no need to correlate the PASSporTs it receives and assemble them into chains, as any chains in "div-o" will be nested through the "opt" element. Nonetheless, the verification services MUST perform the same chain validation described in Section 4.2 to validate that each nested PASSporT shares the same "orig" field as its enclosing PASSporT, and that the "dest" field of each nested PASSporT corresponds to the Peterson Expires January 14, 2021 [Page 12] Internet-Draft PASSporT Diverted July 2020 "div" field of its enclosing PASSporT. The same checks MUST also be performed for freshness, signature validation, and so on. It is similarly OPTIONAL for the verification service to determine that the "dest" claims element of the outermost PASSporT corresponds to the called party indication of receive telephone signaling, where such indication would vary depending on the using protocol. How authentication services or verification services receive or transport PASSporTs for "div-o" is outside the scope of this document, and dependent on the using protocol. 6. Definition of 'opt' The presence of an "Original PASSporT" ("opt") claims set element signifies that a PASSporT encapsulates another entire PASSporT within it, typically a PASSporT that was transformed in some way to create the current PASSporT. Relying parties may need to consult the encapsulated PASSporT in order to validate the identity of a caller. "opt" as defined in this specification may be used by future PASSporT extensions as well as in conjunction with "div-o". "opt" MUST contain a quoted full-form PASSporT as specified by [RFC8225] Appendix A; it MUST NOT contain a compact form PASSporT. For an example of a "div-o" PASSporT containing "opt," see Section 5. 7. 'div' and Redirection The "div" mechanism exists primarily to prevent false negatives at verification services when an arriving SIP request, due to intermediary retargeting, does not appear to be intended for its eventual recipient, because the original PASSporT "dest" value designates a different destination. Any intermediary that assigns a new target to a request can, instead of retargeting and forwarding the request, instead redirect with a 3xx response code. In ordinary operations, a redirection poses no difficulties for the operations of baseline STIR: when the user agent client (UAC) receives the 3xx response, it will initiate a new request to the new target (typically the target carried in the Contact header field value of the 3xx), and the "dest" of the PASSporT created for the new request will match that new target. As no impersonation attack can arise from this case, it creates no new requirements for STIR. However, some UACs record the original target of a call with mechanisms like History-Info [RFC7044] or Diversion [RFC5806], and may want to leverage STIR to demonstrate to the ultimate recipient that the call has been redirected securely: that is, that the Peterson Expires January 14, 2021 [Page 13] Internet-Draft PASSporT Diverted July 2020 original destination was the one that sent the redirection message that led to the recipient receiving the request. The semantics of the PASSporT necessary for that assertion are the same as those for the "div" retargeting cases above. The only wrinkle is that the PASSporT needs to be generated by the redirecting entity and sent back to the originating user agent client within the 3xx response. This introduces more complexity than might immediately be apparent. In the first place, a 3xx response can convey multiple targets through the Contact header field value; to accommodate this, the "div" PASSporT MAY include one "dest" object array value per Contact, but if the retargeting entity wants to keep the Contact list private from targets, it may need to generate one PASSporT per Contact. Bear in mind as well that the original SIP request could have carried multiple Identity header field values that had been added by different authentication services in the request path, so a redirecting entity might need to generate one "div" PASSporT for each PASSporT in the original request. Often, this will mean just one "div" PASSporT, but for some deployment scenarios, it could require an impractical number of combinations. But in very complex call routing scenarios, attestation of source identity would only add limited value anyway. STIR-aware SIP intermediaries that redirect requests MAY therefore convey one or more PASSporTs in the backwards direction within Identity header fields. These redirecting entities will act as authentication services for "div" as described in Section 4.1. This document consequently updates [RFC8224] to permit carrying Identity header fields in SIP 300-class responses. It is left to the originating user agent to determine which Identity header fields should be copied from the 3xx into any new requests resulting from the redirection, if any: use of these Identity header fields by entities receiving a 3xx response is OPTIONAL. Finally, note that if an intermediary in the response path consumes the 3xx and explores new targets itself while performing sequential forking, it will effectively retarget the call on behalf of the redirecting server, and this will create the same need for "div" PASSporTs as any other retargeted call. These intermediaries MAY also copy PASSporTs from the 3xx response and insert them into sequential forking requests, if appropriate. 8. Extending 'div' to work with Service Logic Tracking It is anticipated that "div" may be used in concert with History-Info [RFC7044] in some deployments. It may not be clear from the "orig" and "dest" values which History-Info header a given PASSporT correlates to, especially because some of the target changes tracked Peterson Expires January 14, 2021 [Page 14] Internet-Draft PASSporT Diverted July 2020 by History-Info will not be reflected in a "div" PASSporT (see Section 1). Therefore an "hi" element as defined here may appear in "div" corresponding to the History-Info header field index parameter value. So for a History-Info header field with an index value of "1.2.1", the claims set of the corresponding PASSporT with "div" might look like: { "orig":{"tn":"12155551212"}, "dest":{"tn":["12155551214"]}, "iat":1443208345, "div":{"tn":"121555551213", "hi":"1.2.1"} } Past experience has shown that there may be additional information about the motivation for retargeting that relying parties might consider when making authorization decisions about a call, see for example the "reason" associated with the SIP Diversion header field [RFC5806]. Future extensions to this specification might incorporate reasons into "div". 9. Acknowledgments We would like to thank Ning Zhang, Dave Hancock, Chris Wendt, Sean Turner, Russ Housley, Ben Campbell, Eric Burger, and Robert Sparks for contributions to this document. 10. IANA Considerations This document contains actions for the IANA. 10.1. JSON Web Token Claims Registrations This specification requests that the IANA add two new claims to the JSON Web Token Claims registry as defined in [RFC7519]. 10.1.1. 'div' registration Claim Name: "div" Claim Description: Diverted Target of a Call Change Controller: IESG Specification Document(s): [RFCThis] Peterson Expires January 14, 2021 [Page 15] Internet-Draft PASSporT Diverted July 2020 10.1.2. 'opt' registration Claim Name: "opt" Claim Description: Original PASSporT (in Full Form) Change Controller: IESG Specification Document(s): [RFCThis] 10.2. PASSporT Type Registrations This specification defines two new PASSporT types for the PASSport Extensions Registry defined in [RFC8225], which resides at https://www.iana.org/assignments/passport/passport.xhtml#passport- extensions. They are: "div" as defined in [RFCThis] Section 3. "div-o" as defined in [RFCThis] Section 5. 11. Privacy Considerations There is an inherent trade-off in any mechanism that tracks in SIP signaling how calls are routed through a network, as routing decisions may expose policies set by users for how calls are forwarded, potentially revealing relationships between different identifiers representing the same user. Note however that in ordinary operations, this information is revealed to the user agent service of the called party, not the calling party. It is usually the called party who establishes these forwarding relationships, and if indeed some other party is responsible for calls being forwarded to the called party, many times the called party should likely be entitled to information about why they are receiving these calls. Similarly, a redirecting entity who sends a 3xx in the backwards direction knowingly shares information about service logic with the caller's network. However, as there may be unforeseen circumstances where the revelation of service logic to the called party poses a privacy risk, implementers and users of this or similar diversion- tracking techniques should understand the trade-off. Furthermore, it is a general privacy risk of identity mechanisms overall that they do not interface well with anonymization services; the interaction of STIR with anonymization services is detailed in [RFC8224] Section 11. Any forwarding service that acts as an anonymizing proxy may not be able to provide a secure chain of retargeting due to the obfuscation of the originating identity. Peterson Expires January 14, 2021 [Page 16] Internet-Draft PASSporT Diverted July 2020 Also see [RFC8224] Section 11 for further considerations on the privacy of using PASSporTs in SIP. 12. Security Considerations This specification describes a security feature, and is primarily concerned with increasing security when calls are forwarded. Including information about how calls were retargeted during the routing process can allow downstream entities to infer particulars of the policies used to route calls through the network. However, including this information about forwarding is at the discretion of the retargeting entity, so if there is a requirement to keep an intermediate called number confidential, no PASSporT should be created for that retargeting - the only consequence will be that downstream entities will be unable to correlate an incoming call with the original PASSporT without access to some prior knowledge of the policies that could have caused the retargeting. Any extension that makes PASSporTs larger creates a potential amplification mechanism for SIP-based DDoS attacks. Since diversion PASSporTs are created as a part of normal forwarding activity, this risk arises at the discretion of the retargeting domain: simply using 3xx response redirections rather than retargeting (by supplying a "div" per Section 7) mitigates the potential impact. Under unusual traffic loads, even domains that might ordinarily retarget requests can switch to redirection. SIP has an inherent capability to redirect requests, including forking them to multiple parties -- potentially a very large numbers of parties. The use of the "div" PASSporT type does not grant any additional powers to attackers who hope to place bulk calls; if present, the "div" PASSporT instead identifies the party responsible for the forwarding. As such, senders of bulk unsolicited traffic are unlikely to find the use of "div" attractive. 13. References 13.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, . Peterson Expires January 14, 2021 [Page 17] Internet-Draft PASSporT Diverted July 2020 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and C. Holmberg, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 7044, DOI 10.17487/RFC7044, February 2014, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . 13.2. Informative References [I-D.ietf-stir-oob] Rescorla, E. and J. Peterson, "STIR Out-of-Band Architecture and Use Cases", draft-ietf-stir-oob-07 (work in progress), March 2020. [RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010, . Peterson Expires January 14, 2021 [Page 18] Internet-Draft PASSporT Diverted July 2020 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC8443] Singh, R., Dolly, M., Das, S., and A. Nguyen, "Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization", RFC 8443, DOI 10.17487/RFC8443, August 2018, . Appendix A. Appendix A: Keys for Examples The following EC256 keys are used in the signing examples given in this document. WARNING: Do not use this key pair in production systems. -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4 hUYm9wv5wutLgEd9FsiTy3+4+Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== -----END PUBLIC KEY----- -----BEGIN EC PRIVATE KEY----- MHcCAQEEIFKCsFZ4Wsw3ZpBxgc4Z0sOjaXDdMk07Ny1fKg6OntAkoAoGCCqGSM49 AwEHoUQDQgAEmzGM1VsO+3IqbMF54rQMaYKQftO4hUYm9wv5wutLgEd9FsiTy3+4 +Wa2O7pffOXPC0QzO+yD8hGEXGP/2mZo6w== -----END EC PRIVATE KEY----- Author's Address Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Email: jon.peterson@team.neustar Peterson Expires January 14, 2021 [Page 19]./draft-ietf-tls-certificate-compression-10.txt0000644000764400076440000004206313604711064021001 0ustar iustyiusty TLS A. Ghedini Internet-Draft Cloudflare, Inc. Intended status: Standards Track V. Vasiliev Expires: July 9, 2020 Google January 06, 2020 TLS Certificate Compression draft-ietf-tls-certificate-compression-10 Abstract In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 9, 2020. Copyright Notice Copyright (c) 2020 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 (https://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 Ghedini & Vasiliev Expires July 9, 2020 [Page 1] Internet-Draft TLS Certificate Compression January 2020 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 3. Negotiating Certificate Compression . . . . . . . . . . . . . 2 4. Compressed Certificate Message . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Middlebox Compatibility . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.1. Update of the TLS ExtensionType Registry . . . . . . . . 5 7.2. Update of the TLS HandshakeType Registry . . . . . . . . 6 7.3. Registry for Compression Algorithms . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In order to reduce latency and improve performance it can be useful to reduce the amount of data exchanged during a TLS handshake. [RFC7924] describes a mechanism that allows a client and a server to avoid transmitting certificates already shared in an earlier handshake, but it doesn't help when the client connects to a server for the first time and doesn't already have knowledge of the server's certificate chain. This document describes a mechanism that would allow certificates to be compressed during all handshakes. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Negotiating Certificate Compression This extension is only supported with TLS 1.3 [RFC8446] and newer; if TLS 1.2 [RFC5246] or earlier is negotiated, the peers MUST ignore this extension. Ghedini & Vasiliev Expires July 9, 2020 [Page 2] Internet-Draft TLS Certificate Compression January 2020 This document defines a new extension type (compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension ([RFC8446], Section 4.1.2), it indicates the support for compressed server certificates. Whenever it is sent by the server as a CertificateRequest extension ([RFC8446], Section 4.3.2), it indicates the support for compressed client certificates. By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use for decompression. The "extension_data" field of this extension SHALL contain a CertificateCompressionAlgorithms value: enum { zlib(1), brotli(2), zstd(3), (65535) } CertificateCompressionAlgorithm; struct { CertificateCompressionAlgorithm algorithms<2..2^8-2>; } CertificateCompressionAlgorithms; The compress_certificate extension is a unidirectional indication; no corresponding response extension is needed. 4. Compressed Certificate Message If the peer has indicated that it supports compression, server and client MAY compress their corresponding Certificate messages (Section 4.4.2 of [RFC8446]) and send them in the form of the CompressedCertificate message (replacing the Certificate message). The CompressedCertificate message is formed as follows: struct { CertificateCompressionAlgorithm algorithm; uint24 uncompressed_length; opaque compressed_certificate_message<1..2^24-1>; } CompressedCertificate; algorithm The algorithm used to compress the certificate. The algorithm MUST be one of the algorithms listed in the peer's compress_certificate extension. Ghedini & Vasiliev Expires July 9, 2020 [Page 3] Internet-Draft TLS Certificate Compression January 2020 uncompressed_length The length of the Certificate message once it is uncompressed. If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the connection with the "bad_certificate" alert. The presence of this field allows the receiver to pre- allocate the buffer for the uncompressed Certificate message and to enforce limits on the message size before performing decompression. compressed_certificate_message The result of applying the indicated compression algorithm to the encoded Certificate message that would have been sent if certificate compression was not in use. The compression algorithm defines how the bytes in the compressed_certificate_message field are converted into the Certificate message. If the specified compression algorithm is zlib, then the Certificate message MUST be compressed with the ZLIB compression algorithm, as defined in [RFC1950]. If the specified compression algorithm is brotli, the Certificate message MUST be compressed with the Brotli compression algorithm as defined in [RFC7932]. If the specified compression algorithm is zstd, the Certificate message MUST be compressed with the Zstandard compression algorithm as defined in [I-D.kucherawy-rfc8478bis]. It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio. This document does not define any such algorithms, but additional codepoints may be allocated for such use per the policy in Section 7.3. If the received CompressedCertificate message cannot be decompressed, the connection MUST be terminated with the "bad_certificate" alert. If the format of the Certificate message is altered using the server_certificate_type or client_certificate_type extensions [RFC7250], the resulting altered message is compressed instead. 5. Security Considerations After decompression, the Certificate message MUST be processed as if it were encoded without being compressed. This way, the parsing and the verification have the same security properties as they would have in TLS normally. In order for certificate compression to function correctly, the underlying compression algorithm MUST output the same data that was provided as input by the peer. Ghedini & Vasiliev Expires July 9, 2020 [Page 4] Internet-Draft TLS Certificate Compression January 2020 Since certificate chains are typically presented on a per-server name or per-user basis, a malicious application does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the plaintext. Implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. Implementations MUST limit the size of the resulting decompressed chain to the specified uncompressed length, and they MUST abort the connection if the size of the output of the decompression function exceeds that limit. TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. While the Certificate message in TLS 1.3 is encrypted, third parties can draw inferences from the message length observed on the wire. TLS 1.3 provides a padding mechanism (discussed in Sections 5.4 and E.3 of [RFC8446]) to counteract such analysis. Certificate compression alters the length of the Certificate message, and the change in length is dependent on the actual contents of the certificate. Any padding scheme covering the Certificate message has to address compression within its design, or disable it altogether. 6. Middlebox Compatibility It's been observed that a significant number of middleboxes intercept and try to validate the Certificate message exchanged during a TLS handshake. This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections that adopt certificate compression. Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from intercepting it, that is, TLS version 1.3 [RFC8446] and higher. 7. IANA Considerations 7.1. Update of the TLS ExtensionType Registry Create an entry, compress_certificate(27), in the existing registry for ExtensionType (defined in [RFC8446]), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". Ghedini & Vasiliev Expires July 9, 2020 [Page 5] Internet-Draft TLS Certificate Compression January 2020 7.2. Update of the TLS HandshakeType Registry Create an entry, compressed_certificate(25), in the existing registry for HandshakeType (defined in [RFC8446]), with "DTLS-OK" column value being set to "Yes". 7.3. Registry for Compression Algorithms This document establishes a registry of compression algorithms supported for compressing the Certificate message, titled "Certificate Compression Algorithm IDs", under the existing "Transport Layer Security (TLS) Extensions" heading. The entries in the registry are: +------------------+------------------------------+-----------------+ | Algorithm Number | Description | Reference | +------------------+------------------------------+-----------------+ | 0 | Reserved | | | | | | | 1 | zlib | [this document] | | | | | | 2 | brotli | [this document] | | | | | | 3 | zstd | [this document] | | | | | | 16384 to 65535 | Reserved for Experimental | | | | Use | | +------------------+------------------------------+-----------------+ The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 256, under "Specification Required" policy for values 256-16383, and under "Experimental Use" otherwise (see [RFC8126] for the definition of relevant policies). Experimental Use extensions can be used both on private networks and over the open Internet. The procedures for requesting values in the Specification Required space are specified in Section 17 of [RFC8447]. 8. References 8.1. Normative References [I-D.kucherawy-rfc8478bis] Collet, Y. and M. Kucherawy, "Zstandard Compression and the application/zstd Media Type", draft-kucherawy- rfc8478bis-03 (work in progress), December 2019. Ghedini & Vasiliev Expires July 9, 2020 [Page 6] Internet-Draft TLS Certificate Compression January 2020 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, DOI 10.17487/RFC1950, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, . [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, . 8.2. Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . Ghedini & Vasiliev Expires July 9, 2020 [Page 7] Internet-Draft TLS Certificate Compression January 2020 Appendix A. Acknowledgements Certificate compression was originally introduced in the QUIC Crypto protocol, designed by Adam Langley and Wan-Teh Chang. This document has benefited from contributions and suggestions from David Benjamin, Ryan Hamilton, Christian Huitema, Benjamin Kaduk, Ilari Liusvaara, Piotr Sikora, Ian Swett, Martin Thomson, Sean Turner and many others. Authors' Addresses Alessandro Ghedini Cloudflare, Inc. Email: alessandro@cloudflare.com Victor Vasiliev Google Email: vasilvv@google.com Ghedini & Vasiliev Expires July 9, 2020 [Page 8] ./draft-ietf-trill-ecn-support-07.txt0000644000764400076440000010204213244635507016772 0ustar iustyiusty TRILL Working Group Donald Eastlake INTERNET-DRAFT Huawei Intended status: Proposed Standard Bob Briscoe CableLabs Expires: August 24, 2018 February 25, 2018 TRILL (TRansparent Interconnection of Lots of Links): ECN (Explicit Congestion Notification) Support Abstract Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. This document extends ECN to TRILL (TRansparent Interconnection of Lots of Links) switches, including integration with IP ECN, and provides for ECN marking in the TRILL Header Extension Flags Word (see RFC 7179). Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. D. Eastlake & B. Briscoe [Page 1] INTERNET-DRAFT TRILL ECN Support Table of Contents 1. Introduction............................................3 1.1 Conventions used in this document......................4 2. The ECN Specific Extended Header Flags..................6 3. ECN Support.............................................7 3.1 Ingress ECN Support....................................7 3.2 Transit ECN Support....................................7 3.3 Egress ECN Support.....................................8 3.3.1 Non-ECN Egress RBridges..............................8 3.3.2 ECN Egress RBridges..................................8 4. TRILL Support for ECN Variants.........................11 4.1 Pre-Congestion Notification (PCN).....................11 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......12 5. IANA Considerations....................................13 6. Security Considerations................................14 7. Acknowledgements.......................................14 Normative References......................................15 Informative References....................................16 Appendix A. TRILL Transit RBridge Behavior to Support L4S.17 Authors' Addresses........................................19 D. Eastlake & B. Briscoe [Page 2] INTERNET-DRAFT TRILL ECN Support 1. Introduction Explicit congestion notification (ECN [RFC3168] [RFC8311]) allows a forwarding element (such as a router) to notify downstream devices, including the destination, of the onset of congestion without having to drop packets. This can improve network efficiency through better congestion control without packet drops. The forwarding element can explicitly mark a proportion of packets in an ECN field instead of dropping the packet. For example, a two-bit field is available for ECN marking in IP headers. ............................. . . +---------+ . +------+ | Ingress | . |Source| +->| RBridge | . +----------+ +---+--+ | | RB1 | . |Forwarding| | | +------+--+ +----------+ . | Element | v | . | | Transit | . | Y | +-------+--+ . +---->| RBridges | . +--------+-+ |Forwarding| . | RBn | . ^ | | Element | . +-------+--+ +---------+ | v | X | . | | Egress | | +-----------+ +----------+ . +---->| RBridge +-+ |Destination| . | RB9 | +-----------+ . TRILL +---------+ . campus . ............................. Figure 1. Example Path Forwarding Nodes In [RFC3168], it was recognized that tunnels and lower layer protocols would need to support ECN, and ECN markings would need to be propagated, as headers were encapsulated and decapsulated. [ECNencapGuide] gives guidelines on the addition of ECN to protocols like TRILL (TRansparent Interconnection of Lots of Links) that often encapsulate IP packets, including propagation of ECN from and to IP. In the figure above, assuming IP traffic, RB1 is an encapsulator and RB9 a decapsulator. Traffic from Source to RB1 might or might not get marked as having experienced congestion in forwarding elements, such as X, before being encapsulated at ingress RB1. Any such ECN marking is encapsulated with a TRILL Header [RFC6325]. This document specifies how ECN marking in traffic at the ingress is copied into the TRILL Extension Header Flags Word and requires such copying for IP traffic. It also enables congestion marking by a congested RBridge such as RBn or RB1 above in the TRILL Header Extension Flags Word [RFC7179]. D. Eastlake & B. Briscoe [Page 3] INTERNET-DRAFT TRILL ECN Support At RB9, the TRILL egress, it specifies how any ECN markings in the TRILL Header Flags Word and in the encapsulated traffic are combined so that subsequent forwarding elements, such as Y and the Destination, can see if congestion was experienced at any previous point in the path from Source. A large part of the guidelines for adding ECN to lower layer protocols [ECNencapGuide] concerns safe propagation of congestion notifications in scenarios where some of the nodes do not support or understand ECN. Such ECN ignorance is not a major problem with RBridges using this specification because the method specified assures that, if an egress RBridge is ECN ignorant (so it cannot further propagate ECN) and congestion has been encountered, the egress RBridge will at least drop the packet and this drop will itself indicate congestion to end stations. 1.1 Conventions used in this document The terminology and acronyms defined in [RFC6325] are used herein with the same meaning. In this documents, "IP" refers to both IPv4 and IPv6. 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] [RFC8174] when, and only when, they appear in all capitals, as shown here. Acronyms: AQM - Active Queue Management CCE - Critical Congestion Experienced CE - Congestion Experienced CItE - Critical Ingress-to-Egress ECN - Explicit Congestion Notification ECT - ECN Capable Transport L4S - Low Latency, Low Loss, Scalable throughput NCHbH - Non-Critical Hop-by-Hop NCCE - Non-Critical Congestion Experienced D. Eastlake & B. Briscoe [Page 4] INTERNET-DRAFT TRILL ECN Support Not-ECT - Not ECN-Capable Transport PCN - Pre-Congestion Notification D. Eastlake & B. Briscoe [Page 5] INTERNET-DRAFT TRILL ECN Support 2. The ECN Specific Extended Header Flags The extension header fields for explicit congestion notification (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit Critical Congestion Experienced (CCE) field in the 32-bit TRILL Header Extension Flags Word [RFC7780]. These fields are shown in Figure 2 as "ECN" and "CCE". The TRILL-ECN field consists of bits 12 and 13, which are in the range reserved for non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 26, which is in the range reserved for Critical Ingress-to-Egress (CItE) bits. The CRItE bit is the critical Ingress-to-Egress summary bit and will be one if and only if any of the bits in the CItE range (21-26) are one or there is a critical feature invoked in some further extension of the TRILL Header after the Extension Flags Word. The other bits and fields shown in Figure 2 are not relevant to ECN. See [RFC7780], [RFC7179], and [IANAthFlags] for the meaning of these other bits and fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | |.....|.........|...........|.....|.......|...........|.........| |C|C|C| |C|N| | | | | | | | | |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | |H|I|R| |C|C| | | Hop | | |C|Clr| | |b|t|s| |A|A| | | Cnt | | |E| | | |H|E|v| |F|F| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The TRILL-ECN and CCE TRILL Header Extension Flags Word Fields Table 1 shows the meaning of the codepoints in the TRILL-ECN field. The first three have the same meaning as the corresponding ECN field codepoints in the IP header as defined in [RFC3168]. However, codepoint 0b11 is called Non-Critical Congestion Experienced (NCCE) to distinguish it from Congestion Experienced in IP. Binary Name Meaning ------ ------- ----------------------------------- 00 Not-ECT Not ECN-Capable Transport 01 ECT(1) ECN-Capable Transport (1) 10 ECT(0) ECN-Capable Transport (0) 11 NCCE Non-Critical Congestion Experienced Table 1. TRILL-ECN Field Codepoints D. Eastlake & B. Briscoe [Page 6] INTERNET-DRAFT TRILL ECN Support 3. ECN Support This section specifies interworking between TRILL and the original standardized form of ECN in IP [RFC3168]. The subsections below describe the required behavior to support ECN at TRILL ingress, transit, and egress. The ingress behavior occurs as a native frame is encapsulated with a TRILL Header to produce a TRILL Data packet. The transit behavior occurs in all RBridges where TRILL Data packets are queued, usually at the output port. The egress behavior occurs where a TRILL Data packet is decapsulated and output as a native frame through an RBridge port. An RBridge that supports ECN MUST behave as described in the relevant subsections below, which correspond to the recommended provisions in Section 3 and Sections 5.1-5.4 of [ECNencapGuide]. Nonetheless, the scheme is designed to safely propagate some form of congestion notification even if some RBridges in the path followed by a TRILL Data packet support ECN and others do not. 3.1 Ingress ECN Support The behavior at an ingress RBridge is as follows: o When encapsulating an IP frame, the ingress RBridge MUST: + set the F flag in the main TRILL header [RFC7780]; + create a Flags Word as part of the TRILL Header; + copy the two ECN bits from the IP header into the TRILL-ECN field (Flags Word bits 12 and 13) + ensure the CCE flag is set to zero (Flags Word bit 26). o When encapsulating a frame for a non-IP protocol, where that protocol has a means of indicating ECN that is understood by the ingress RBridge, it MUST follow the guidelines in Section 5.3 of [ECNencapGuide] to add a Flags Word to the TRILL Header. For a non-IP protocol with a similar ECN field to IP, this would be achieved by copying into the TRILL-ECN field from the encapsulated native frame. 3.2 Transit ECN Support The transit behavior, shown below, is required at all RBridges where TRILL Data packets are queued, usually at the output port. o An RBridge that supports ECN MUST implement some form of active D. Eastlake & B. Briscoe [Page 7] INTERNET-DRAFT TRILL ECN Support queue management (AQM) according to the guidelines of [RFC7567]. The RBridge detects congestion either by monitoring its own queue depth or by participating in a link-specific protocol. o If the TRILL Header Flags Word is present, whenever the AQM algorithm decides to indicate congestion on a TRILL Data packet it MUST set the CCE flag (Flags Word bit 26). o If the TRILL header Flags Word is not present, to indicate congestion the RBridge will either drop the packet or it MAY do all of the following instead: + set the F flag in the main TRILL header; + add a Flags Word to the TRILL Header; + set the TRILL-ECN field to Not-ECT (00); + and set the CCE flag and the Ingress-to-Egress critical summary bit (CRIbE). Note that a transit RBridge that supports ECN does not refer to the TRILL-ECN field before signaling CCE in a packet. It signals CCE irrespective of whether the packet indicates that the transport is ECN-capable. The egress/decapsulation behavior (described next) ensures that a CCE indication is converted to a drop if the transport is not ECN-capable. 3.3 Egress ECN Support 3.3.1 Non-ECN Egress RBridges If the egress RBridge does not support ECN, that RBridge will ignore bits 12 and 13 of any Flags Word that is present, because it does not contain any special ECN logic. Nonetheless, if a transit RBridge has set the CCE flag, the egress will drop the packet. This is because drop is the default behavior for an RBridge decapsulating a Critical Ingress-to-Egress flag when it has no specific logic to understand it. Drop is the intended behavior for such a packet, as required by Section 5.4 of [ECNencapGuide]. 3.3.2 ECN Egress RBridges If an RBridge supports ECN, for the two cases of an IP and a non-IP inner packet, the egress behavior is as follows: Decapsulating an inner IP packet: The RBridge sets the ECN field D. Eastlake & B. Briscoe [Page 8] INTERNET-DRAFT TRILL ECN Support of the outgoing native IP packet using Table 3. It MUST set the ECN field of the outgoing IP packet to the codepoint at the intersection of the row for the arriving encapsulated IP packet and the column for 3-bit ECN codepoint in the arriving outer TRILL Data packet TRILL Header. If no TRILL Header Extension Flags Word is present, the 3-bit ECN codepoint is assumed to be all zero bits. The name of the TRILL 3-bit ECN codepoint is defined using the combination of the TRILL-ECN and CCE fields in Table 2. Specifically, the TRILL 3-bit ECN codepoint is called CE if either NCCE or CCE is set in the TRILL Header Extension Flags Word. Otherwise it has the same name as the 2-bit TRILL-ECN codepoint. In the case where the TRILL 3-bit ECN codepoint indicates congestion experienced (CE) but the encapsulated native IP frame indicates a not ECN-capable transport (Not-ECT), it can be seen that the RBridge MUST drop the packet. Such packet dropping is necessary because a transport above the IP layer that is not ECN-capable will have no ECN logic, so it will only understand dropped packets as an indication of congestion. Decapsulating a non-IP protocol frame: If the frame has a means of indicating ECN that is understood by the RBridge, it MUST follow the guidelines in Section 5.4 of [ECNencapGuide] when setting the ECN information in the decapsulated native frame. For a non-IP protocol with a similar ECN field to IP, this would be achieved by combining the information in the TRILL Header Flags Word with the encapsulated non-IP native frame, as specified in Table 3. +------------+-----+---------------------+ | TRILL-ECN | CCE | Arriving TRILL 3-bit| | | | ECN codepoint name | +------------+-----+---------------------+ | Not-ECT 00 | 0 | Not-ECT | | ECT(1) 01 | 0 | ECT(1) | | ECT(0) 10 | 0 | ECT(0) | | NCCE 11 | 0 | CE | | Not-ECT 00 | 1 | CE | | ECT(1) 01 | 1 | CE | | ECT(0) 10 | 1 | CE | | NCCE 11 | 1 | CE | +------------+-----+---------------------+ Table 2. Mapping of TRILL-ECN and CCE Fields to the TRILL 3-bit ECN Codepoint Name D. Eastlake & B. Briscoe [Page 9] INTERNET-DRAFT TRILL ECN Support +---------+----------------------------------------------+ | Inner | Arriving TRILL 3-bit ECN Codepoint Name | | Native +---------+------------+------------+----------+ | Header | Not-ECT | ECT(0) | ECT(1) | CE | +---------+---------+------------+------------+----------+ | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | | CE | CE | CE | CE(*) | CE | +---------+---------+------------+------------+----------+ Table 3. Egress ECN Behavior An asterisk in the above table indicates a combination that is currently unused in all variants of ECN marking (see Section 4) and therefore SHOULD be logged. With one exception, the mappings in Table 3 are consistent with those for IP-in-IP tunnels [RFC6040], which ensures backward compatibility with all current and past variants of ECN marking (see Section 4). It also ensures forward compatibility with any future form of ECN marking that complies with the guidelines in [ECNencapGuide], including cases where ECT(1) represents a second level of marking severity below CE. The one exception is that the drop condition in Table 3 need not be logged because, with TRILL, it is the result of a valid combination of events. D. Eastlake & B. Briscoe [Page 10] INTERNET-DRAFT TRILL ECN Support 4. TRILL Support for ECN Variants This section is informative, not normative; it discusses interworking between TRILL and variants of the standardized form of ECN in IP [RFC3168]. See also [RFC8311]. The ECN wire protocol for TRILL (Section 2) and the ingress (Section 3.1) and egress (Section 3.3) ECN behaviors have been designed to support the other known variants of ECN, as detailed below. New variants of ECN will have to comply with the guidelines for defining alternative ECN semantics [RFC4774]. It is expected that the TRILL ECN wire protocol is generic enough to support such potential future variants. 4.1 Pre-Congestion Notification (PCN) The PCN wire protocol [RFC6660] is recognized by the use of a PCN- compatible Diffserv codepoint in the IP header and a non-zero IP-ECN field. For TRILL or any lower layer protocol, equivalent traffic classification codepoints would have to be defined, but that is outside the scope of the current document. The PCN wire protocol is similar to ECN, except it indicates congestion with two levels of severity. It uses: o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) codepoint o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked (ThM) codepoint. (This difference between ECT(1) and ECT(0) only applies to PCN, not to the classic ECN support specified for TRILL in this document before Section 4.) To implement PCN on a transit RBridge would require a detailed specification. But in brief: o the TRILL Critical Congestion Experienced (CCE) flag would be used for the Excess-Traffic-Marked (ETM) codepoint; o ECT(1) in the TRILL-ECN field would be used for the Threshold- Marked codepoint. Then the ingress and egress behaviors defined in Section 3 would not need to be altered to ensure support for PCN as well as ECN. D. Eastlake & B. Briscoe [Page 11] INTERNET-DRAFT TRILL ECN Support 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) L4S is currently on the IETF's experimental track. An outline of how a transit TRILL RBridge would support L4S [ECNL4S] is given in Appendix A. D. Eastlake & B. Briscoe [Page 12] INTERNET-DRAFT TRILL ECN Support 5. IANA Considerations IANA is requested to update the TRILL Extended Header Flags registry by replacing the lines for bits 9-13 and for bits 21-26 with the following: Bits Purpose Reference ----- ------- --------- 9-11 available non-critical hop-by-hop flags 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 21-25 available critical ingress-to-egress flags 26 Critical Congestion Experienced (CCE) [this doc] D. Eastlake & B. Briscoe [Page 13] INTERNET-DRAFT TRILL ECN Support 6. Security Considerations TRILL support of ECN is a straightforward combination of previously specified ECN and TRILL with no significant new security considerations. For ECN tunneling security considerations, see [RFC6040]. For general TRILL protocol security considerations, see [RFC6325]. 7. Acknowledgements The helpful comments of Loa Andersson and Adam Roach are hereby acknowledged. This document was prepared with basic NROFF. All macros used were defined in the source file. D. Eastlake & B. Briscoe [Page 14] INTERNET-DRAFT TRILL ECN Support 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, . [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, DOI 10.17487/RFC4774, November 2006, . [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, . [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, . [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, . [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, . [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, work in progress. D. Eastlake & B. Briscoe [Page 15] INTERNET-DRAFT TRILL ECN Support Informative References [ECNL4S] - K. De Schepper, B. Briscoe, "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queueing Delay", draft-ietf-tsvwg-ecn-l4s-id, work in progress. [IANAthFlags] - IANA TRILL Extended Header word flags: http://www.iana.org/assignments/trill-parameters/trill- parameters.xhtml#extended-header-flags [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 10.17487/RFC6660, July 2012, . D. Eastlake & B. Briscoe [Page 16] INTERNET-DRAFT TRILL ECN Support Appendix A. TRILL Transit RBridge Behavior to Support L4S The specification of the Low Latency, Low Loss, Scalable throughput (L4S) wire protocol for IP is given in [ECNL4S]. L4S is one example of the ways TRILL ECN handling may evolve [RFC8311]. It is similar to the original ECN wire protocol for IP [RFC3168], except: o An AQM that supports L4S classifies packets with ECT(1) or CE in the IP header into an L4S queue and a "Classic" queue otherwise. o The meaning of CE markings applied by an L4S queue is not the same as the meaning of a drop by a "Classic" queue (contrary to the original requirement for ECN [RFC3168]). Instead, the likelihood that the Classic queue drops packets is defined as the square of the likelihood that the L4S queue marks packets (e.g., when there is a drop probability of 0.0009 (0.09%) the L4S marking probability will be 0.03 (3%)). This seems to present a problem for the way that a transit TRILL RBridge defers the choice between marking and dropping to the egress. Nonetheless, the following pseudocode outlines how a transit TRILL RBridge can implement L4S marking in such a way that the egress behavior already described in Section 3.3 for Classic ECN [RFC3168] will produce the desired outcome. /* p is an internal variable calculated by any L4S AQM * dependent on the delay being experienced in the Classic queue. * bit13 is the least significant bit of the TRILL-ECN field */ % On TRILL transit if (bit13 == 0 ) { % Classic Queue if (p > max(random(), random()) ) mark(CCE) % likelihood: p^2 } else { % L4S Queue if (p > random() ) { if (p > random() ) mark(CCE) % likelihood: p^2 else mark(NCCE) % likelihood: p - p^2 } } With the above transit behavior, an egress that supports ECN (Section 3.3) will drop packets or propagate their ECN markings depending on whether the arriving inner header is from a non-ECN-capable or ECN- capable transport. D. Eastlake & B. Briscoe [Page 17] INTERNET-DRAFT TRILL ECN Support Even if an egress has no L4S-specific logic of its own, it will drop packets with the square of the probability that an egress would if it did support ECN, for the following reasons: o Egress with ECN support: + L4S: propagates both the Critical and Non-Critical CE marks (CCE & NCCE) as a CE mark. Likelihood: p^2 + p - p^2 = p + Classic: Propagates CCE marks as CE or drop, depending on inner. Likelihood: p^2 o Egress without ECN support: + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. Likelihood: p^2 + Classic: drops CCE marks. Likelihood: p^2 D. Eastlake & B. Briscoe [Page 18] INTERNET-DRAFT TRILL ECN Support Authors' Addresses Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Tel: +1-508-333-2270 Email: d3e3e3@gmail.com Bob Briscoe CableLabs UK Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/ D. Eastlake & B. Briscoe [Page 19] INTERNET-DRAFT TRILL ECN Support Copyright and IPR Provisions Copyright (c) 2018 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. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake & B. Briscoe [Page 20] ./draft-ietf-tsvwg-rtcweb-qos-18.txt0000644000764400076440000006310112755720053016626 0ustar iustyiusty Network Working Group P. Jones Internet-Draft S. Dhesikan Intended status: Standards Track C. Jennings Expires: February 20, 2017 Cisco Systems D. Druta AT&T August 19, 2016 DSCP Packet Markings for WebRTC QoS draft-ietf-tsvwg-rtcweb-qos-18 Abstract Many networks, such as service provider and enterprise networks, can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of WebRTC traffic. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 20, 2017. 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 Jones, et al. Expires February 20, 2017 [Page 1] Internet-Draft WebRTC QoS August 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Relation to Other Specifications . . . . . . . . . . . . . . 3 4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Downward References . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Document History . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Differentiated Services Code Point (DSCP) [RFC2474] packet marking can help provide QoS in some environments. This specification provides default packet marking for browsers that support WebRTC applications, but does not change any advice or requirements in other IETF RFCs. The contents of this specification are intended to be a simple set of implementation recommendations based on the previous RFCs. Networks where these DSCP markings are beneficial (likely to improve QoS for WebRTC traffic) include: 1. Private, wide-area networks. Network administrators have control over remarking packets and treatment of packets. 2. Residential Networks. If the congested link is the broadband uplink in a cable or DSL scenario, often residential routers/NAT support preferential treatment based on DSCP. 3. Wireless Networks. If the congested link is a local wireless network, marking may help. There are cases where these DSCP markings do not help, but, aside from possible priority inversion for "less than best effort traffic" Jones, et al. Expires February 20, 2017 [Page 2] Internet-Draft WebRTC QoS August 2016 (see Section 5), they seldom make things worse if packets are marked appropriately. DSCP values are in principle site specific, with each site selecting its own code points for controlling per-hop-behavior to influence the QoS for transport-layer flows. However in the WebRTC use cases, the browsers need to set them to something when there is no site specific information. This document describes a subset of DSCP code point values drawn from existing RFCs and common usage for use with WebRTC applications. These code points are intended to be the default values used by a WebRTC application. While other values could be used, using a non-default value may result in unexpected per-hop behavior. It is RECOMMENDED that WebRTC applications use non-default values only in private networks that are configured to use different values. This specification defines inputs that are provided by the WebRTC application hosted in the browser that aid the browser in determining how to set the various packet markings. The specification also defines the mapping from abstract QoS policies (flow type, priority level) to those packet markings. 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]. The terms "browser" and "non-browser" are defined in [RFC7742] and carry the same meaning in this document. 3. Relation to Other Specifications This document is a complement to [RFC7657], which describes the interaction between DSCP and real-time communications. That RFC covers the implications of using various DSCP values, particularly focusing on Real-time Transport Protocol (RTP) [RFC3550] streams that are multiplexed onto a single transport-layer flow. There are a number of guidelines specified in [RFC7657] that apply to marking traffic sent by WebRTC applications, as it is common for multiple RTP streams to be multiplexed on the same transport-layer flow. Generally, the RTP streams would be marked with a value as appropriate from Table 1. A WebRTC application might also multiplex data channel [I-D.ietf-rtcweb-data-channel] traffic over the same 5-tuple as RTP streams, which would also be marked as per that table. The guidance in [RFC7657] says that all data channel traffic would be marked with a single value that is typically different than the Jones, et al. Expires February 20, 2017 [Page 3] Internet-Draft WebRTC QoS August 2016 value(s) used for RTP streams multiplexed with the data channel traffic over the same 5-tuple, assuming RTP streams are marked with a value other than default forwarding (DF). This is expanded upon further in the next section. This specification does not change or override the advice in any other IETF RFCs about setting packet markings. Rather, it simply selects a subset of DSCP values that is relevant in the WebRTC context. The DSCP value set by the endpoint is not trusted by the network. In addition, the DSCP value may be remarked at any place in the network for a variety of reasons to any other DSCP value, including default forwarding (DF) value to provide basic best effort service. Even so, there is benefit in marking traffic even if it only benefits the first few hops. The implications are discussed in Secton 3.2 of [RFC7657]. Further, a mitigation for such action is through an authorization mechanism. Such an authorization mechanism is outside the scope of this document. 4. Inputs WebRTC applications send and receive two types of flows of significance to this document: o media flows which are RTP streams [I-D.ietf-rtcweb-rtp-usage] o data flows which are data channels [I-D.ietf-rtcweb-data-channel] Each of the RTP streams and distinct data channels consists of all of the packets associated with an independent media entity, so an RTP stream or distinct data channel is not always equivalent to a transport-layer flow defined by a 5-tuple (source address, destination address, source port, destination port, and protocol). There may be multiple RTP streams and data channels multiplexed over the same 5-tuple, with each having a different level of importance to the application and, therefore, potentially marked using different DSCP values than another RTP stream or data channel within the same transport-layer flow. (Note that there are restrictions with respect to marking different data channels carried within the same SCTP association as outlined in Section 5.) The following are the inputs provided by the WebRTC application to the browser: o Flow Type: The application provides this input because it knows if the flow is audio, interactive video [RFC4594] [G.1010] with or without audio, or data. Jones, et al. Expires February 20, 2017 [Page 4] Internet-Draft WebRTC QoS August 2016 o Application Priority: Another input is the relative importance of an RTP stream or data channel. Many applications have multiple flows of the same Flow Type and often some flows are more important than others. For example, in a video conference where there are usually audio and video flows, the audio flow may be more important than the video flow. JavaScript applications can tell the browser whether a particular flow is high, medium, low or very low importance to the application. [I-D.ietf-rtcweb-transports] defines in more detail what an individual flow is within the WebRTC context and priorities for media and data flows. Currently in WebRTC, media sent over RTP is assumed to be interactive [I-D.ietf-rtcweb-transports] and browser APIs do not exist to allow an application to to differentiate between interactive and non- interactive video. 5. DSCP Mappings The DSCP values for each flow type of interest to WebRTC based on application priority are shown in Table 1. These values are based on the framework and recommended values in [RFC4594]. A web browser SHOULD use these values to mark the appropriate media packets. More information on EF can be found in [RFC3246]. More information on AF can be found in [RFC2597]. DF is default forwarding which provides the basic best effort service [RFC2474]. WebRTC use of multiple DSCP values may encounter network blocking of packets with certain DSCP values. See section 4.2 of [I-D.ietf-rtcweb-transports] for further discussion, including how WebRTC implementations establish and maintain connectivity when such blocking is encountered. Jones, et al. Expires February 20, 2017 [Page 5] Internet-Draft WebRTC QoS August 2016 +------------------------+-------+------+-------------+-------------+ | Flow Type | Very | Low | Medium | High | | | Low | | | | +------------------------+-------+------+-------------+-------------+ | Audio | CS1 | DF | EF (46) | EF (46) | | | (8) | (0) | | | | | | | | | | Interactive Video with | CS1 | DF | AF42, AF43 | AF41, AF42 | | or without Audio | (8) | (0) | (36, 38) | (34, 36) | | | | | | | | Non-Interactive Video | CS1 | DF | AF32, AF33 | AF31, AF32 | | with or without Audio | (8) | (0) | (28, 30) | (26, 28) | | | | | | | | Data | CS1 | DF | AF11 | AF21 | | | (8) | (0) | | | +------------------------+-------+------+-------------+-------------+ Table 1: Recommended DSCP Values for WebRTC Applications The application priority, indicated by the columns "very low", "low", "Medium", and "high", signifies the relative importance of the flow within the application. It is an input that the browser receives to assist in selecting the DSCP value and adjusting the network transport behavior. The above table assumes that packets marked with CS1 are treated as "less than best effort", such as the LE behavior described in [RFC3662]. However, the treatment of CS1 is implementation dependent. If an implementation treats CS1 as other than "less than best effort", then the actual priority (or, more precisely, the per- hop-behavior) of the packets may be changed from what is intended. It is common for CS1 to be treated the same as DF, so applications and browsers using CS1 cannot assume that CS1 will be treated differently than DF [RFC7657]. However, it is also possible per [RFC2474] for CS1 traffic to be given better treatment than DF, thus caution should be exercised when electing to use CS1. This is one of the cases where marking packets using these recommendations can make things worse. Implementers should also note that excess EF traffic is dropped. This could mean that a packet marked as EF may not get through, although the same packet marked with a different DSCP value would have gotten through. This is not a flaw, but how excess EF traffic is intended to be treated. The browser SHOULD first select the flow type of the flow. Within the flow type, the relative importance of the flow SHOULD be used to select the appropriate DSCP value. Jones, et al. Expires February 20, 2017 [Page 6] Internet-Draft WebRTC QoS August 2016 Currently, all WebRTC video is assumed to be interactive [I-D.ietf-rtcweb-transports], for which the Interactive Video DSCP values in Table 1 SHOULD be used. Browsers MUST NOT use the AF3x DSCP values (for Non-Interactive Video in Table 1) for WebRTC applications. Non-browser implementations of WebRTC MAY use the AF3x DSCP values for video that is known not to be interactive, e.g., all video in a WebRTC video playback application that is not implemented in a browser. The combination of flow type and application priority provides specificity and helps in selecting the right DSCP value for the flow. All packets within a flow SHOULD have the same application priority. In some cases, the selected application priority cell may have multiple DSCP values, such as AF41 and AF42. These offer different drop precedences. The different drop precedence values provides additional granularity in classifying packets within a flow. For example, in a video conference the video flow may have medium application priority, thus either AF42 or AF43 may be selected. More important video packets (e.g., a video picture or frame encoded without any dependency on any prior pictures or frames) might be marked with AF42 and less important packets (e.g., a video picture or frame encoded based on the content of one or more prior pictures or frames) might be marked with AF43 (e.g., receipt of the more important packets enables a video renderer to continue after one or more packets are lost). It is worth noting that the application priority is utilized by the coupled congestion control mechanism for media flows per [I-D.ietf-rmcat-coupled-cc] and the SCTP scheduler for data channel traffic per [I-D.ietf-rtcweb-data-channel]. For reasons discussed in Section 6 of [RFC7657], if multiple flows are multiplexed using a reliable transport (e.g., TCP) then all of the packets for all flows multiplexed over that transport-layer flow MUST be marked using the same DSCP value. Likewise, all WebRTC data channel packets transmitted over an SCTP association MUST be marked using the same DSCP value, regardless of how many data channels (streams) exist or what kind of traffic is carried over the various SCTP streams. In the event that the browser wishes to change the DSCP value in use for an SCTP association, it MUST reset the SCTP congestion controller after changing values. Frequent changes in the DSCP value used for an SCTP association are discouraged, though, as this would defeat any attempts at effectively managing congestion. It should also be noted that any change in DSCP value that results in a reset of the congestion controller puts the SCTP association back into slow start, which may have undesirable effects on application performance. Jones, et al. Expires February 20, 2017 [Page 7] Internet-Draft WebRTC QoS August 2016 For the data channel traffic multiplexed over an SCTP association, it is RECOMMENDED that the DSCP value selected be the one associated with the highest priority requested for all data channels multiplexed over the SCTP association. Likewise, when multiplexing multiple flows over a TCP connection, the DCSP value selected should be the one associated with the highest priority requested for all multiplexed flows. If a packet enters a network that has no support for a flow type- application priority combination specified in Table 1, then the network node at the edge will remark the DSCP value based on policies. This could result in the flow not getting the network treatment it expects based on the original DSCP value in the packet. Subsequently, if the packet enters a network that supports a larger number of these combinations, there may not be sufficient information in the packet to restore the original markings. Mechanisms for restoring such original DSCP is outside the scope of this document. In summary, DSCP marking provides neither guarantees nor promised levels of service. However, DSCP marking is expected to provide a statistical improvement in real-time service as a whole. The service provided to a packet is dependent upon the network design along the path, as well as the network conditions at every hop. 6. Security Considerations Since the JavaScript application specifies the flow type and application priority that determine the media flow DSCP values used by the browser, the browser could consider application use of a large number of higher priority flows to be suspicious. If the server hosting the JavaScript application is compromised, many browsers within the network might simultaneously transmit flows with the same DSCP marking. The DiffServ architecture requires ingress traffic conditioning for reasons that include protecting the network from this sort of attack. Otherwise, this specification does not add any additional security implications beyond those addressed in the following DSCP-related specifications. For security implications on use of DSCP, please refer to Section 7 of [RFC7657] and Section 6 of [RFC4594]. Please also see [I-D.ietf-rtcweb-security] as an additional reference. 7. IANA Considerations This specification does not require any actions from IANA. Jones, et al. Expires February 20, 2017 [Page 8] Internet-Draft WebRTC QoS August 2016 8. Downward References This specification contains a downwards reference to [RFC4594] and [RFC7657]. However, the parts of the former RFC used by this specification are sufficiently stable for this downward reference. The guidance in the latter RFC is necessary to understand the Diffserv technology used in this document and the motivation for the recommended DSCP values and procedures. 9. Acknowledgements Thanks to David Black, Magnus Westerlund, Paolo Severini, Jim Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tuexen, and Brian Carpenter for their invaluable input. 10. Dedication This document is dedicated to the memory of James Polk, a long-time friend and colleague. James made important contributions to this specification, including serving initially as one of the primary authors. The IETF global community mourns his loss and he will be missed dearly. 11. Document History Note to RFC Editor: Please remove this section. This document was originally an individual submission in RTCWeb WG. The RTCWeb working group selected it to be become a WG document. Later the transport ADs requested that this be moved to the TSVWG WG as that seemed to be a better match. 12. References 12.1. Normative References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", draft-ietf-rtcweb-data-channel-13 (work in progress), January 2015. [I-D.ietf-rtcweb-rtp-usage] Perkins, D., Westerlund, M., and J. Ott, "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 2016. Jones, et al. Expires February 20, 2017 [Page 9] Internet-Draft WebRTC QoS August 2016 [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. [I-D.ietf-rtcweb-transports] Alvestrand, H., "Transports for WebRTC", draft-ietf- rtcweb-transports-15 (work in progress), August 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, . [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, . [RFC7742] Roach, A., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, . 12.2. Informative References [G.1010] International Telecommunications Union, "End-user multimedia QoS categories", Recommendation ITU-T G.1010, November 2001. [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion control for RTP media", draft-ietf-rmcat-coupled-cc-03 (work in progress), July 2016. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/ RFC2597, June 1999, . Jones, et al. Expires February 20, 2017 [Page 10] Internet-Draft WebRTC QoS August 2016 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, . Authors' Addresses Paul E. Jones Cisco Systems Email: paulej@packetizer.com Subha Dhesikan Cisco Systems Email: sdhesika@cisco.com Cullen Jennings Cisco Systems Email: fluffy@cisco.com Dan Druta AT&T Email: dd5826@att.com Jones, et al. Expires February 20, 2017 [Page 11] ./draft-ietf-uta-tls-for-email-05.txt0000644000764400076440000002421713636424537016642 0ustar iustyiusty Network Working Group L. Velvindron Internet-Draft cyberstorm.mu Updates: 8314 (if approved) S. Farrell Intended status: Standards Track Trinity College Dublin Expires: September 25, 2020 March 24, 2020 Deprecation of use of TLS 1.1 for Email Submission and Access draft-ietf-uta-tls-for-email-05 Abstract This specification updates current recommendation for the use of Transport Layer Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFC8314. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 25, 2020. Copyright Notice Copyright (c) 2020 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 (https://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. Velvindron & Farrell Expires September 25, 2020 [Page 1] Internet-Draft TLS For Email March 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 3. Updates to RFC8314 . . . . . . . . . . . . . . . . . . . . . 2 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Normative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction [RFC8314] defines the minimum recommended version for TLS as version 1.1. Due to the deprecation of TLS 1.1 in [I-D.ietf-tls-oldversions-deprecate], this recommendation is no longer valid. Therefore this document updates [RFC8314] so that the minimum version for TLS is TLS 1.2. 2. Conventions Used in This Document 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] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. 3. Updates to RFC8314 OLD: "4.1. Deprecation of Services Using Cleartext and TLS Versions Less Than 1.1" NEW: "4.1. Deprecation of Services Using Cleartext and TLS Versions Less Than 1.2" OLD: "As soon as practicable, MSPs currently supporting Secure Sockets Layer (SSL) 2.x, SSL 3.0, or TLS 1.0 SHOULD transition their users to TLS 1.1 or later and discontinue support for those earlier versions of SSL and TLS." Velvindron & Farrell Expires September 25, 2020 [Page 2] Internet-Draft TLS For Email March 2020 NEW: "As soon as practicable, MSPs currently supporting Secure Sockets Layer (SSL) 2.x, SSL 3.0, TLS 1.0 or TLS 1.1 SHOULD transition their users to TLS 1.2 or later and discontinue support for those earlier versions of SSL and TLS." In Section 4.1, the text should be revised from: OLD: One way is for the server to refuse a ClientHello message from any client sending a ClientHello.version field corresponding to any version of SSL or TLS 1.0. NEW: One way is for the server to refuse a ClientHello message from any client sending a ClientHello.version field corresponding to any version of SSL or TLS earlier than TLS1.2. OLD: "It is RECOMMENDED that new users be required to use TLS version 1.1 or greater from the start. However, an MSP may find it necessary to make exceptions to accommodate some legacy systems that support only earlier versions of TLS or only cleartext." NEW: "It is RECOMMENDED that new users be required to use TLS version 1.2 or greater from the start. However, an MSP may find it necessary to make exceptions to accommodate some legacy systems that support only earlier versions of TLS or only cleartext." OLD: " If, however, an MUA provides such an indication, it MUST NOT indicate confidentiality for any connection that does not at least use TLS 1.1 with certificate verification and also meet the minimum confidentiality requirements associated with that account. " NEW: " If, however, an MUA provides such an indication, it MUST NOT indicate confidentiality for any connection that does not at least use TLS 1.2 with certificate verification and also meet the minimum confidentiality requirements associated with that account. " Velvindron & Farrell Expires September 25, 2020 [Page 3] Internet-Draft TLS For Email March 2020 OLD " MUAs MUST implement TLS 1.2 [RFC5246] or later. Earlier TLS and SSL versions MAY also be supported, so long as the MUA requires at least TLS 1.1 [RFC4346] when accessing accounts that are configured to impose minimum confidentiality requirements. " NEW: " MUAs MUST implement TLS 1.2 [RFC5246] or later e.g TLS 1.3 [RFC8446]. Earlier TLS and SSL versions MAY also be supported, so long as the MUA requires at least TLS 1.2 [RFC5246] when accessing accounts that are configured to impose minimum confidentiality requirements. " OLD: " The default minimum expected level of confidentiality for all new accounts MUST require successful validation of the server's certificate and SHOULD require negotiation of TLS version 1.1 or greater. (Future revisions to this specification may raise these requirements or impose additional requirements to address newly discovered weaknesses in protocols or cryptographic algorithms. " NEW: " The default minimum expected level of confidentiality for all new accounts MUST require successful validation of the server's certificate and SHOULD require negotiation of TLS version 1.2 or greater. (Future revisions to this specification may raise these requirements or impose additional requirements to address newly discovered weaknesses in protocols or cryptographic algorithms. " 4. IANA Considerations None of the proposed measures have an impact on IANA. 5. Security Considerations The purpose of this document is to document updated recommendations for using TLS with Email services. Those recommendations are based on [I-D.ietf-tls-oldversions-deprecate]. 6. Acknowledgement The authors would like to thank Vittorio Bertola and Viktor Dukhovni for their feedback. Velvindron & Farrell Expires September 25, 2020 [Page 4] Internet-Draft TLS For Email March 2020 7. References 7.1. Informative References [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, . 7.2. Normative References [I-D.ietf-tls-oldversions-deprecate] Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and TLSv1.1", draft-ietf-tls-oldversions-deprecate-06 (work in progress), January 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Authors' Addresses Loganaden Velvindron cyberstorm.mu 88 Avenue De Plevitz Roches Brunes Rose Hill 71259 Mauritius Phone: +230 59762817 Email: logan@cyberstorm.mu Velvindron & Farrell Expires September 25, 2020 [Page 5] Internet-Draft TLS For Email March 2020 Stephen Farrell Trinity College Dublin Dublin 2 Ireland Phone: +353-1-896-2354 Email: stephen.farrell@cs.tcd.ie Velvindron & Farrell Expires September 25, 2020 [Page 6] ./draft-kucherawy-rfc8478bis-05.txt0000644000764400076440000033007113650405162016241 0ustar iustyiusty Network Working Group Y. Collet Internet-Draft M. Kucherawy, Ed. Obsoletes: 8478 (if approved) Facebook Intended status: Informational April 23, 2020 Expires: October 25, 2020 Zstandard Compression and the application/zstd Media Type draft-kucherawy-rfc8478bis-05 Abstract Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME). It also registers a corresponding media type, content encoding, and structured syntax suffix. Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document replaces and obsoletes RFC 8478. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 25, 2020. Copyright Notice Copyright (c) 2020 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 Collet & Kucherawy Expires October 25, 2020 [Page 1] Internet-Draft application/zstd April 2020 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. Collet & Kucherawy Expires October 25, 2020 [Page 2] Internet-Draft application/zstd April 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Compression Algorithm . . . . . . . . . . . . . . . . . . . . 5 3.1. Frames . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Zstandard Frames . . . . . . . . . . . . . . . . . . . 6 3.1.1.1. Frame Header . . . . . . . . . . . . . . . . . . . 7 3.1.1.2. Blocks . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1.3. Compressed Blocks . . . . . . . . . . . . . . . . 14 3.1.1.4. Sequence Execution . . . . . . . . . . . . . . . . 27 3.1.1.5. Repeat Offsets . . . . . . . . . . . . . . . . . . 28 3.1.2. Skippable Frames . . . . . . . . . . . . . . . . . . . 28 4. Entropy Encoding . . . . . . . . . . . . . . . . . . . . . . . 29 4.1. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.1. FSE Table Description . . . . . . . . . . . . . . . . 30 4.2. Huffman Coding . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. Huffman Tree Description . . . . . . . . . . . . . . . 33 4.2.1.1. Huffman Tree Header . . . . . . . . . . . . . . . 35 4.2.1.2. FSE Compression of Huffman Weights . . . . . . . . 36 4.2.1.3. Conversion from Weights to Huffman Prefix Codes . 36 4.2.2. Huffman-Coded Streams . . . . . . . . . . . . . . . . 37 5. Dictionary Format . . . . . . . . . . . . . . . . . . . . . . 39 6. Use of Dictionaries . . . . . . . . . . . . . . . . . . . . . 40 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 7.1. The 'application/zstd' Media Type . . . . . . . . . . . . 40 7.2. Content Encoding . . . . . . . . . . . . . . . . . . . . . 41 7.3. Structured Syntax Suffix . . . . . . . . . . . . . . . . . 42 7.4. Dictionaries . . . . . . . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 43 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . . 44 10.2. Informative References . . . . . . . . . . . . . . . . . . 44 Appendix A. Decoding Tables for Predefined Codes . . . . . . . . 45 A.1. Literal Length Code Table . . . . . . . . . . . . . . . . 45 A.2. Match Length Code Table . . . . . . . . . . . . . . . . . 48 A.3. Offset Code Table . . . . . . . . . . . . . . . . . . . . 51 Appendix B. Changes Since RFC8478 . . . . . . . . . . . . . . . . 52 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 Collet & Kucherawy Expires October 25, 2020 [Page 3] Internet-Draft application/zstd April 2020 1. Introduction Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism, akin to gzip [RFC1952]. Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. This document describes the Zstandard format. Also, to enable the transport of a data object compressed with Zstandard, this document registers a media type that can be used to identify such content when it is used in a payload encoded using Multipurpose Internet Mail Extensions (MIME). 2. Definitions Some terms used elsewhere in this document are defined here for clarity. uncompressed: Describes an arbitrary set of bytes in their original form, prior to being subjected to compression. compress, compression: The act of processing a set of bytes via the compression mechanism described here. compressed: Describes the result of passing a set of bytes through this mechanism. The original input has thus been compressed. decompress, decompression: The act of processing a set of bytes through the inverse of the compression mechanism described here, in an attempt to recover the original set of bytes prior to compression. decompressed: Describes the result of passing a set of bytes through the reverse of this mechanism. When this is successful, the decompressed payload and the uncompressed payload are indistinguishable. encode: The process of translating data from one form to another; this may include compression or it may refer to other translations done as part of this specification. decode: The reverse of "encode"; describes a process of reversing a prior encoding to recover the original content. Collet & Kucherawy Expires October 25, 2020 [Page 4] Internet-Draft application/zstd April 2020 frame: Content compressed by Zstandard is transformed into a Zstandard frame. Multiple frames can be appended into a single file or stream. A frame is completely independent, has a defined beginning and end, and has a set of parameters that tells the decoder how to decompress it. block: A frame encapsulates one or multiple blocks. Each block contains arbitrary content, which is described by its header, and has a guaranteed maximum content size that depends upon frame parameters. Unlike frames, each block depends on previous blocks for proper decoding. However, each block can be decompressed without waiting for its successor, allowing streaming operations. natural order: A sequence or ordering of objects or values that is typical of that type of object or value. A set of unique integers, for example, is in "natural order" if when progressing from one element in the set or sequence to the next, there is never a decrease in value. The naming convention for identifiers within the specification is Mixed_Case_With_Underscores. Identifiers inside square brackets indicate that the identifier is optional in the presented context. 3. Compression Algorithm This section describes the Zstandard algorithm. The purpose of this document is to define a lossless compressed data format that is a) independent of the CPU type, operating system, file system, and character set and b) is suitable for file compression and pipe and streaming compression, using the Zstandard algorithm. The text of the specification assumes a basic background in programming at the level of bits and other primitive data representations. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage, and hence can be used in data communications. The format uses the Zstandard compression method, and an optional xxHash-64 checksum method [XXHASH], for detection of data corruption. The data format defined by this specification does not attempt to allow random access to compressed data. Unless otherwise indicated below, a compliant compressor must produce data sets that conform to the specifications presented here. However, it does not need to support all options. Collet & Kucherawy Expires October 25, 2020 [Page 5] Internet-Draft application/zstd April 2020 A compliant decompressor must be able to decompress at least one working set of parameters that conforms to the specifications presented here. It may also ignore informative fields, such as the checksum. Whenever it does not support a parameter defined in the compressed stream, it must produce a non-ambiguous error code and associated error message explaining which parameter is unsupported. This specification is intended for use by implementers of software to compress data into Zstandard format and/or decompress data from Zstandard format. The Zstandard format is supported by an open source reference implementation, written in portable C, and available at [ZSTD]. 3.1. Frames Zstandard compressed data is made up of one or more frames. Each frame is independent and can be decompressed independently of other frames. The decompressed content of multiple concatenated frames is the concatenation of each frame's decompressed content. There are two frame formats defined for Zstandard: Zstandard frames and skippable frames. Zstandard frames contain compressed data, while skippable frames contain custom user metadata. 3.1.1. Zstandard Frames The structure of a single Zstandard frame is as follows: +--------------------+------------+ | Magic_Number | 4 bytes | +--------------------+------------+ | Frame_Header | 2-14 bytes | +--------------------+------------+ | Data_Block | n bytes | +--------------------+------------+ | [More Data_Blocks] | | +--------------------+------------+ | [Content_Checksum] | 4 bytes | +--------------------+------------+ Magic_Number: 4 bytes, little-endian format. Value: 0xFD2FB528. Frame_Header: 2 to 14 bytes, detailed in Section 3.1.1.1. Data_Block: Detailed in Section 3.1.1.2. This is where data appears. Collet & Kucherawy Expires October 25, 2020 [Page 6] Internet-Draft application/zstd April 2020 Content_Checksum: An optional 32-bit checksum, only present if Content_Checksum_Flag is set. The content checksum is the result of the XXH64() hash function [XXHASH] digesting the original (decoded) data as input, and a seed of zero. The low 4 bytes of the checksum are stored in little-endian format. The magic number was selected to be less probable to find at the beginning of an arbitrary file. It avoids trivial patterns (0x00, 0xFF, repeated bytes, increasing bytes, etc.), contains byte values outside of ASCII range, and doesn't map into UTF-8 space, all of which reduce the likelihood of its appearance at the top of a text file. 3.1.1.1. Frame Header The frame header has a variable size, with a minimum of 2 bytes and up to 14 bytes depending on optional parameters. The structure of Frame_Header is as follows: +-------------------------+-----------+ | Frame_Header_Descriptor | 1 byte | +-------------------------+-----------+ | [Window_Descriptor] | 0-1 byte | +-------------------------+-----------+ | [Dictionary_ID] | 0-4 bytes | +-------------------------+-----------+ | [Frame_Content_Size] | 0-8 bytes | +-------------------------+-----------+ 3.1.1.1.1. Frame_Header_Descriptor The first header's byte is called the Frame_Header_Descriptor. It describes which other fields are present. Decoding this byte is enough to tell the size of Frame_Header. Collet & Kucherawy Expires October 25, 2020 [Page 7] Internet-Draft application/zstd April 2020 +------------+-------------------------+ | Bit Number | Field Name | +------------+-------------------------+ | 7-6 | Frame_Content_Size_Flag | +------------+-------------------------+ | 5 | Single_Segment_Flag | +------------+-------------------------+ | 4 | (unused) | +------------+-------------------------+ | 3 | (reserved) | +------------+-------------------------+ | 2 | Content_Checksum_Flag | +------------+-------------------------+ | 1-0 | Dictionary_ID_Flag | +------------+-------------------------+ In this table, bit 7 is the highest bit, while bit 0 is the lowest one. 3.1.1.1.1.1. Frame_Content_Size_Flag This is a 2-bit flag (equivalent to Frame_Header_Descriptor right- shifted 6 bits) specifying whether Frame_Content_Size (the decompressed data size) is provided within the header. Frame_Content_Size_Flag provides FCS_Field_Size, which is the number of bytes used by Frame_Content_Size according to the following table: +-------------------------+--------+---+---+---+ | Frame_Content_Size_Flag | 0 | 1 | 2 | 3 | +-------------------------+--------+---+---+---+ | FCS_Field_Size | 0 or 1 | 2 | 4 | 8 | +-------------------------+--------+---+---+---+ When Frame_Content_Size_Flag is 0, FCS_Field_Size depends on Single_Segment_Flag: If Single_Segment_Flag is set, FCS_Field_Size is 1. Otherwise, FCS_Field_Size is 0; Frame_Content_Size is not provided. 3.1.1.1.1.2. Single_Segment_Flag If this flag is set, data must be regenerated within a single continuous memory segment. In this case, Window_Descriptor byte is skipped, but Frame_Content_Size is necessarily present. As a consequence, the decoder must allocate a memory segment of size equal or larger than Frame_Content_Size. Collet & Kucherawy Expires October 25, 2020 [Page 8] Internet-Draft application/zstd April 2020 In order to protect the decoder from unreasonable memory requirements, a decoder is allowed to reject a compressed frame that requests a memory size beyond the decoder's authorized range. For broader compatibility, decoders are recommended to support memory sizes of at least 8 MB. This is only a recommendation; each decoder is free to support higher or lower limits, depending on local limitations. 3.1.1.1.1.3. Unused Bit A decoder compliant with this specification version shall not interpret this bit. It might be used in a future version, to signal a property that is not mandatory to properly decode the frame. An encoder compliant with this specification must set this bit to zero. 3.1.1.1.1.4. Reserved Bit This bit is reserved for some future feature. Its value must be zero. A decoder compliant with this specification version must ensure it is not set. This bit may be used in a future revision, to signal a feature that must be interpreted to decode the frame correctly. 3.1.1.1.1.5. Content_Checksum_Flag If this flag is set, a 32-bit Content_Checksum will be present at the frame's end. See the description of Content_Checksum above. 3.1.1.1.1.6. Dictionary_ID_Flag This is a 2-bit flag (= Frame_Header_Descriptor & 0x3) indicating whether a dictionary ID is provided within the header. It also specifies the size of this field as DID_Field_Size: +--------------------+---+---+---+---+ | Dictionary_ID_Flag | 0 | 1 | 2 | 3 | +--------------------+---+---+---+---+ | DID_Field_Size | 0 | 1 | 2 | 4 | +--------------------+---+---+---+---+ 3.1.1.1.2. Window Descriptor This provides guarantees about the minimum memory buffer required to decompress a frame. This information is important for decoders to allocate enough memory. The Window_Descriptor byte is optional. When Single_Segment_Flag is Collet & Kucherawy Expires October 25, 2020 [Page 9] Internet-Draft application/zstd April 2020 set, Window_Descriptor is not present. In this case, Window_Size is Frame_Content_Size, which can be any value from 0 to 2^64-1 bytes (16 ExaBytes). +------------+----------+----------+ | Bit Number | 7-3 | 2-0 | +------------+----------+----------+ | Field Name | Exponent | Mantissa | +------------+----------+----------+ The minimum memory buffer size is called Window_Size. It is described by the following formulae: windowLog = 10 + Exponent; windowBase = 1 << windowLog; windowAdd = (windowBase / 8) * Mantissa; Window_Size = windowBase + windowAdd; The minimum Window_Size is 1 KB. The maximum Window_Size is (1<<41) + 7*(1<<38) bytes, which is 3.75 TB. In general, larger Window_Size values tend to improve the compression ratio, but at the cost of increased memory usage. To properly decode compressed data, a decoder will need to allocate a buffer of at least Window_Size bytes. In order to protect decoders from unreasonable memory requirements, a decoder is allowed to reject a compressed frame that requests a memory size beyond decoder's authorized range. For improved interoperability, it's recommended for decoders to support values of Window_Size up to 8 MB and for encoders not to generate frames requiring a Window_Size larger than 8 MB. It's merely a recommendation though, and decoders are free to support larger or lower limits, depending on local limitations. 3.1.1.1.3. Dictionary_ID This is a variable size field, which contains the ID of the dictionary required to properly decode the frame. This field is optional. When it's not present, it's up to the decoder to know which dictionary to use. Dictionary_ID field size is provided by DID_Field_Size. DID_Field_Size is directly derived from the value of Dictionary_ID_Flag. One byte can represent an ID 0-255; 2 bytes can represent an ID 0-65535; 4 bytes can represent an ID 0-4294967295. Collet & Kucherawy Expires October 25, 2020 [Page 10] Internet-Draft application/zstd April 2020 Format is little-endian. It is permitted to represent a small ID (for example, 13) with a large 4-byte dictionary ID, even if it is less efficient. Within private environments, any dictionary ID can be used. However, for frames and dictionaries distributed in public space, Dictionary_ID must be attributed carefully. The following ranges are reserved for use only with dictionaries that have been registered with IANA (see Section 7.4): low range: <= 32767 high range: >= (1 << 31) Any other value for Dictionary_ID can be used by private arrangement between participants. Any payload presented for decompression that references an unregistered reserved dictionary ID results in an error. 3.1.1.1.4. Frame Content Size This is the original (uncompressed) size. This information is optional. Frame_Content_Size uses a variable number of bytes, provided by FCS_Field_Size. FCS_Field_Size is provided by the value of Frame_Content_Size_Flag. FCS_Field_Size can be equal to 0 (not present), 1, 2, 4, or 8 bytes. +----------------+--------------+ | FCS Field Size | Range | +----------------+--------------+ | 0 | unknown | +----------------+--------------+ | 1 | 0 - 255 | +----------------+--------------+ | 2 | 256 - 65791 | +----------------+--------------+ | 4 | 0 - 2^32 - 1 | +----------------+--------------+ | 8 | 0 - 2^64 - 1 | +----------------+--------------+ Frame_Content_Size format is little-endian. When FCS_Field_Size is 1, 4, or 8 bytes, the value is read directly. When FCS_Field_Size is 2, the offset of 256 is added. It's allowed to represent a small size (for example 18) using any compatible variant. Collet & Kucherawy Expires October 25, 2020 [Page 11] Internet-Draft application/zstd April 2020 3.1.1.2. Blocks After Magic_Number and Frame_Header, there are some number of blocks. Each frame must have at least 1 block, but there is no upper limit on the number of blocks per frame. The structure of a block is as follows: +--------------+---------------+ | Block_Header | Block_Content | +--------------+---------------+ | 3 bytes | n bytes | +--------------+---------------+ Block_Header uses 3 bytes, written using little-endian convention. It contains three fields: +------------+------------+------------+ | Last_Block | Block_Type | Block_Size | +------------+------------+------------+ | bit 0 | bits 1-2 | bits 3-23 | +------------+------------+------------+ 3.1.1.2.1. Last_Block The lowest bit (Last_Block) signals whether this block is the last one. The frame will end after this last block. It may be followed by an optional Content_Checksum (see Section 3.1.1). 3.1.1.2.2. Block_Type The next 2 bits represent the Block_Type. There are four block types: +-----------+------------------+ | Value | Block_Type | +-----------+------------------+ | 0 | Raw_Block | +-----------+------------------+ | 1 | RLE_Block | +-----------+------------------+ | 2 | Compressed_Block | +-----------+------------------+ | 3 | Reserved | +-----------+------------------+ Collet & Kucherawy Expires October 25, 2020 [Page 12] Internet-Draft application/zstd April 2020 Raw_Block: This is an uncompressed block. Block_Content contains Block_Size bytes. RLE_Block: This is a single byte, repeated Block_Size times. Block_Content consists of a single byte. On the decompression side, this byte must be repeated Block_Size times. Compressed_Block: This is a compressed block as described in Section 3.1.1.3. Block_Size is the length of Block_Content, namely the compressed data. The decompressed size is not known, but its maximum possible value is guaranteed (see below). Reserved: This is not a block. This value cannot be used with the current specification. If such a value is present, it is considered to be corrupt data, and a compliant decoder must reject it. 3.1.1.2.3. Block_Size The upper 21 bits of Block_Header represent the Block_Size. When Block_Type is Compressed_Block or Raw_Block, Block_Size is the size of Block_Content (hence excluding Block_Header). When Block_Type is RLE_Block, since Block_Content's size is always 1, Block_Size represents the number of times this byte must be repeated. Block_Size is limited by Block_Maximum_Size (see below). 3.1.1.2.4. Block_Content and Block_Maximum_Size The size of Block_Content is limited by Block_Maximum_Size, which is the smallest of: o Window_Size o 128 KB Block_Maximum_Size is constant for a given frame. This maximum is applicable to both the decompressed size and the compressed size of any block in the frame. The reasoning for this limit is that a decoder can read this information at the beginning of a frame and use it to allocate buffers. The guarantees on the size of blocks ensure that the buffers will be large enough for any following block of the valid frame. Collet & Kucherawy Expires October 25, 2020 [Page 13] Internet-Draft application/zstd April 2020 If the compressed block is larger than the uncompressed sending the uncompressed block (i.e., a Raw_Block) is recommended instead. 3.1.1.3. Compressed Blocks To decompress a compressed block, the compressed size must be provided from the Block_Size field within Block_Header. A compressed block consists of two sections: a Literals Section (Section 3.1.1.3.1) and a Sequences_Section (Section 3.1.1.3.2). The results of the two sections are then combined to produce the decompressed data in Sequence Execution (Section 3.1.1.4). To decode a compressed block, the following elements are necessary: o Previous decoded data, up to a distance of Window_Size, or the beginning of the Frame, whichever is smaller. Single_Segment_Flag will be set in the latter case. o List of "recent offsets" from the previous Compressed_Block. o The previous Huffman tree, required by Treeless_Literals_Block type. o Previous Finite State Entropy (FSE) decoding tables, required by Repeat_Mode, for each symbol type (literals lengths, match lengths, offsets). Note that decoding tables are not always from the previous Compressed_Block: o Every decoding table can come from a dictionary. o The Huffman tree comes from the previous Compressed_Literals_Block. 3.1.1.3.1. Literals_Section_Header All literals are regrouped in the first part of the block. They can be decoded first and then copied during Sequence Execution (see Section 3.1.1.4), or they can be decoded on the flow during Sequence Execution. Literals can be stored uncompressed or compressed using Huffman prefix codes. When compressed, an optional tree description can be present, followed by 1 or 4 streams. Collet & Kucherawy Expires October 25, 2020 [Page 14] Internet-Draft application/zstd April 2020 +----------------------------+ | Literals_Section_Header | +----------------------------+ | [Huffman_Tree_Description] | +----------------------------+ | [Jump_Table] | +----------------------------+ | Stream_1 | +----------------------------+ | [Stream_2] | +----------------------------+ | [Stream_3] | +----------------------------+ | [Stream_4] | +----------------------------+ 3.1.1.3.1.1. Literals_Section_Header This field describes how literals are packed. It's a byte-aligned variable-size bit field, ranging from 1 to 5 bytes, using little- endian convention. +---------------------+-----------+ | Literals_Block_Type | 2 bits | +---------------------+-----------+ | Size_Format | 1-2 bits | +---------------------+-----------+ | Regenerated_Size | 5-20 bits | +---------------------+-----------+ | [Compressed_Size] | 0-18 bits | +---------------------+-----------+ In this representation, bits at the top are the lowest bits. The Literals_Block_Type field uses the two lowest bits of the first byte, describing four different block types: +---------------------------+-------+ | Literals_Block_Type | Value | +---------------------------+-------+ | Raw_Literals_Block | 0 | +---------------------------+-------+ | RLE_Literals_Block | 1 | +---------------------------+-------+ | Compressed_Literals_Block | 2 | +---------------------------+-------+ | Treeless_Literals_Block | 3 | +---------------------------+-------+ Collet & Kucherawy Expires October 25, 2020 [Page 15] Internet-Draft application/zstd April 2020 Raw_Literals_Block: Literals are stored uncompressed. Literals_Section_Content is Regenerated_Size. RLE_Literals_Block: Literals consist of a single-byte value repeated Regenerated_Size times. Literals_Section_Content is 1. Compressed_Literals_Block: This is a standard Huffman-compressed block, starting with a Huffman tree description. See details below. Literals_Section_Content is Compressed_Size. Treeless_Literals_Block: This is a Huffman-compressed block, using the Huffman tree from the previous Compressed_Literals_Block, or a dictionary if there is no previous Huffman-compressed literals block. Huffman_Tree_Description will be skipped. Note that if this mode is triggered without any previous Huffman-table in the frame (or dictionary, per Section 5), it should be treated as data corruption. Literals_Section_Content is Compressed_Size. The Size_Format is divided into two families: o For Raw_Literals_Block and RLE_Literals_Block, it's only necessary to decode Regenerated_Size. There is no Compressed_Size field. o For Compressed_Block and Treeless_Literals_Block, it's required to decode both Compressed_Size and Regenerated_Size (the decompressed size). It's also necessary to decode the number of streams (1 or 4). For values spanning several bytes, the convention is little endian. Size_Format for Raw_Literals_Block and RLE_Literals_Block uses 1 or 2 bits. Its value is (Literals_Section_Header[0]>>2) & 0x3. Size_Format == 00 or 10: Size_Format uses 1 bit. Regenerated_Size uses 5 bits (value 0-31). Literals_Section_Header uses 1 byte. Regenerated_Size = Literal_Section_Header[0]>>3. Size_Format == 01: Size_Format uses 2 bits. Regenerated_Size uses 12 bits (values 0-4095). Literals_Section_Header uses 2 bytes. Regenerated_Size = (Literals_Section_Header[0]>>4) + (Literals_Section_Header[1]<<4). Size_Format == 11: Size_Format uses 2 bits. Regenerated_Size uses 20 bits (values 0-1048575). Literals_Section_Header uses 3 bytes. Regenerated_Size = (Literals_Section_Header[0]>>4) + (Literals_Section_Header[1]<<4) + (Literals_Section_Header[2]<<12) Only Stream_1 is present for these cases. Note that it is permitted Collet & Kucherawy Expires October 25, 2020 [Page 16] Internet-Draft application/zstd April 2020 to represent a short value (for example, 13) using a long format, even if it's less efficient. Size_Format for Compressed_Literals_Block and Treeless_Literals_Block always uses 2 bits. Size_Format == 00: A single stream. Both Regenerated_Size and Compressed_Size use 10 bits (values 0-1023). Literals_Section_Header uses 3 bytes. Size_Format == 01: 4 streams. Both Regenerated_Size and Compressed_Size use 10 bits (values 0-1023). Literals_Section_Header uses 3 bytes. Size_Format == 10: 4 streams. Both Regenerated_Size and Compressed_Size use 14 bits (values 0-16383). Literals_Section_Header uses 4 bytes. Size_Format == 11: 4 streams. Both Regenerated_Size and Compressed_Size use 18 bits (values 0-262143). Literals_Section_Header uses 5 bytes. Both the Compressed_Size and Regenerated_Size fields follow little- endian convention. Note that Compressed_Size includes the size of the Huffman_Tree_Description when it is present. 3.1.1.3.1.2. Raw_Literals_Block The data in Stream_1 is Regenerated_Size bytes long. It contains the raw literals data to be used during Sequence Execution (Section 3.1.1.3.2). 3.1.1.3.1.3. RLE_Literals_Block Stream_1 consists of a single byte that should be repeated Regenerated_Size times to generate the decoded literals. 3.1.1.3.1.4. Compressed_Literals_Block and Treeless_Literals_Block Both of these modes contain Huffman-encoded data. For Treeless_Literals_Block, the Huffman table comes from the previously compressed literals block, or from a dictionary; see Section 5. 3.1.1.3.1.5. Huffman_Tree_Description This section is only present when the Literals_Block_Type type is Compressed_Literals_Block (2). The format of Huffman_Tree_Description can be found in Section 4.2.1. The size of Collet & Kucherawy Expires October 25, 2020 [Page 17] Internet-Draft application/zstd April 2020 Huffman_Tree_Description is determined during the decoding process. It must be used to determine where streams begin. Total_Streams_Size = Compressed_Size - Huffman_Tree_Description_Size 3.1.1.3.1.6. Jump_Table The Jump_Table is only present when there are 4 Huffman-coded streams. (Reminder: Huffman-compressed data consists of either 1 or 4 Huffman- coded streams.) If only 1 stream is present, it is a single bitstream occupying the entire remaining portion of the literals block, encoded as described within Section 4.2.2. If there are 4 streams, Literals_Section_Header only provides enough information to know the decompressed and compressed sizes of all 4 streams combined. The decompressed size of each stream is equal to (Regenerated_Size+3)/4, except for the last stream, which may be up to 3 bytes smaller, to reach a total decompressed size as specified in Regenerated_Size. The compressed size of each stream is provided explicitly in the Jump_Table. The Jump_Table is 6 bytes long and consists of three 2-byte little-endian fields, describing the compressed sizes of the first 3 streams. Stream4_Size is computed from Total_Streams_Size minus sizes of other streams. Stream4_Size = Total_Streams_Size - 6 - Stream1_Size - Stream2_Size - Stream3_Size Note that if Stream1_Size + Stream2_Size + Stream3_Size exceeds Total_Streams_Size, the data are considered corrupted. Each of these 4 bitstreams is then decoded independently as a Huffman-Coded stream, as described in Section 4.2.2. 3.1.1.3.2. Sequences_Section A compressed block is a succession of sequences. A sequence is a literal copy command, followed by a match copy command. A literal copy command specifies a length. It is the number of bytes to be copied (or extracted) from the Literals Section. A match copy command specifies an offset and a length. Collet & Kucherawy Expires October 25, 2020 [Page 18] Internet-Draft application/zstd April 2020 When all sequences are decoded, if there are literals left in the literals section, these bytes are added at the end of the block. This is described in more detail in Section 3.1.1.4. The Sequences_Section regroups all symbols required to decode commands. There are three symbol types: literals lengths, offsets, and match lengths. They are encoded together, interleaved, in a single "bitstream". The Sequences_Section starts by a header, followed by optional probability tables for each symbol type, followed by the bitstream. Sequences_Section_Header [Literals_Length_Table] [Offset_Table] [Match_Length_Table] bitStream To decode the Sequences_Section, it's necessary to know its size. This size is deduced from the size of the Literals_Section: Sequences_Section_Size = Block_Size - Literals_Section_Header - Literals_Section_Content 3.1.1.3.2.1. Sequences_Section_Header This header consists of two items: o Number_of_Sequences o Symbol_Compression_Modes Number_of_Sequences is a variable size field using between 1 and 3 bytes. If the first byte is "byte0": o if (byte0 == 0): there are no sequences. The sequence section stops here. Decompressed content is defined entirely as Literals Section content. The FSE tables used in Repeat_Mode are not updated. o if (byte0 < 128): Number_of_Sequences = byte0. Uses 1 byte. o if (byte0 < 255): Number_of_Sequences = ((byte0 - 128) << 8) + byte1. Uses 2 bytes. o if (byte0 == 255): Number_of_Sequences = byte1 + (byte2 << 8) + 0x7F00. Uses 3 bytes. Collet & Kucherawy Expires October 25, 2020 [Page 19] Internet-Draft application/zstd April 2020 Symbol_Compression_Modes is a single byte, defining the compression mode of each symbol type. +-------------+----------------------+ | Bit Number | Field Name | +-------------+----------------------+ | 7-6 | Literal_Lengths_Mode | +-------------+----------------------+ | 5-4 | Offsets_Mode | +-------------+----------------------+ | 3-2 | Match_Lengths_Mode | +-------------+----------------------+ | 1-0 | Reserved | +-------------+----------------------+ The last field, Reserved, must be all zeroes. Literals_Lengths_Mode, Offsets_Mode, and Match_Lengths_Mode define the Compression_Mode of literals lengths, offsets, and match lengths symbols, respectively. They follow the same enumeration: +-------+---------------------+ | Value | Compression_Mode | +-------+---------------------+ | 0 | Predefined_Mode | +-------+---------------------+ | 1 | RLE_Mode | +-------+---------------------+ | 2 | FSE_Compressed_Mode | +-------+---------------------+ | 3 | Repeat_Mode | +-------+---------------------+ Predefined_Mode: A predefined FSE (see Section 4.1) distribution table is used, as defined in Section 3.1.1.3.2.2. No distribution table will be present. RLE_Mode: The table description consists of a single byte, which contains the symbol's value. This symbol will be used for all sequences. FSE_Compressed_Mode: Standard FSE compression. A distribution table will be present. The format of this distribution table is described in Section 4.1.1. Note that the maximum allowed accuracy log for literals length and match length tables is 9, and the maximum accuracy log for the offsets table is 8. This mode must not be used when only one symbol is present; RLE_Mode should be used instead (although any other mode will work). Collet & Kucherawy Expires October 25, 2020 [Page 20] Internet-Draft application/zstd April 2020 Repeat_Mode: The table used in the previous Compressed_Block with Number_Of_Sequences > 0 will be used again, or if this is the first block, the table in the dictionary will be used. Note that this includes RLE_Mode, so if Repeat_Mode follows RLE_Mode, the same symbol will be repeated. It also includes Predefined_Mode, in which case Repeat_Mode will have the same outcome as Predefined_Mode. No distribution table will be present. If this mode is used without any previous sequence table in the frame (or dictionary; see Section 5) to repeat, this should be treated as corruption. 3.1.1.3.2.1.1. Sequence Codes for Lengths and Offsets Each symbol is a code in its own context, which specifies Baseline and Number_of_Bits to add. Codes are FSE compressed and interleaved with raw additional bits in the same bitstream. Literals length codes are values ranging from 0 to 35 inclusive. They define lengths from 0 to 131071 bytes. The literals length is equal to the decoded Baseline plus the result of reading Number_of_Bits bits from the bitstream, as a little-endian value. Collet & Kucherawy Expires October 25, 2020 [Page 21] Internet-Draft application/zstd April 2020 +----------------------+----------+----------------+ | Literals_Length_Code | Baseline | Number_of_Bits | +----------------------+----------+----------------+ | 0-15 | length | 0 | +----------------------+----------+----------------+ | 16 | 16 | 1 | +----------------------+----------+----------------+ | 17 | 18 | 1 | +----------------------+----------+----------------+ | 18 | 20 | 1 | +----------------------+----------+----------------+ | 19 | 22 | 1 | +----------------------+----------+----------------+ | 20 | 24 | 2 | +----------------------+----------+----------------+ | 21 | 28 | 2 | +----------------------+----------+----------------+ | 22 | 32 | 3 | +----------------------+----------+----------------+ | 23 | 40 | 3 | +----------------------+----------+----------------+ | 24 | 48 | 4 | +----------------------+----------+----------------+ | 25 | 64 | 6 | +----------------------+----------+----------------+ | 26 | 128 | 7 | +----------------------+----------+----------------+ | 27 | 256 | 8 | +----------------------+----------+----------------+ | 28 | 512 | 9 | +----------------------+----------+----------------+ | 29 | 1024 | 10 | +----------------------+----------+----------------+ | 30 | 2048 | 11 | +----------------------+----------+----------------+ | 31 | 4096 | 12 | +----------------------+----------+----------------+ | 32 | 8192 | 13 | +----------------------+----------+----------------+ | 33 | 16384 | 14 | +----------------------+----------+----------------+ | 34 | 32768 | 15 | +----------------------+----------+----------------+ | 35 | 65536 | 16 | +----------------------+----------+----------------+ Match length codes are values ranging from 0 to 52 inclusive. They define lengths from 3 to 131074 bytes. The match length is equal to Collet & Kucherawy Expires October 25, 2020 [Page 22] Internet-Draft application/zstd April 2020 the decoded Baseline plus the result of reading Number_of_Bits bits from the bitstream, as a little-endian value. Collet & Kucherawy Expires October 25, 2020 [Page 23] Internet-Draft application/zstd April 2020 +-------------------+-----------------------+----------------+ | Match_Length_Code | Baseline | Number_of_Bits | +-------------------+-----------------------+----------------+ | 0-31 | Match_Length_Code + 3 | 0 | +-------------------+-----------------------+----------------+ | 32 | 35 | 1 | +-------------------+-----------------------+----------------+ | 33 | 37 | 1 | +-------------------+-----------------------+----------------+ | 34 | 39 | 1 | +-------------------+-----------------------+----------------+ | 35 | 41 | 1 | +-------------------+-----------------------+----------------+ | 36 | 43 | 2 | +-------------------+-----------------------+----------------+ | 37 | 47 | 2 | +-------------------+-----------------------+----------------+ | 38 | 51 | 3 | +-------------------+-----------------------+----------------+ | 39 | 59 | 3 | +-------------------+-----------------------+----------------+ | 40 | 67 | 4 | +-------------------+-----------------------+----------------+ | 41 | 83 | 4 | +-------------------+-----------------------+----------------+ | 42 | 99 | 5 | +-------------------+-----------------------+----------------+ | 43 | 131 | 7 | +-------------------+-----------------------+----------------+ | 44 | 259 | 8 | +-------------------+-----------------------+----------------+ | 45 | 515 | 9 | +-------------------+-----------------------+----------------+ | 46 | 1027 | 10 | +-------------------+-----------------------+----------------+ | 47 | 2051 | 11 | +-------------------+-----------------------+----------------+ | 48 | 4099 | 12 | +-------------------+-----------------------+----------------+ | 49 | 8195 | 13 | +-------------------+-----------------------+----------------+ | 50 | 16387 | 14 | +-------------------+-----------------------+----------------+ | 51 | 32771 | 15 | +-------------------+-----------------------+----------------+ | 52 | 65539 | 16 | +-------------------+-----------------------+----------------+ Collet & Kucherawy Expires October 25, 2020 [Page 24] Internet-Draft application/zstd April 2020 Offset codes are values ranging from 0 to N. A decoder is free to limit its maximum supported value for N. Support for values of at least 22 is recommended. At the time of this writing, the reference decoder supports a maximum N value of 31. An offset code is also the number of additional bits to read in little-endian fashion and can be translated into an Offset_Value using the following formulas: Offset_Value = (1 << offsetCode) + readNBits(offsetCode); if (Offset_Value > 3) Offset = Offset_Value - 3; This means that maximum Offset_Value is (2^(N+1))-1, supporting back- reference distance up to (2^(N+1))-4, but it is limited by the maximum back-reference distance (see Section 3.1.1.1.2). Offset_Value from 1 to 3 are special: they define "repeat codes". This is described in more detail in Section 3.1.1.5. 3.1.1.3.2.1.2. Decoding Sequences FSE bitstreams are read in reverse of the direction they are written. In zstd, the compressor writes bits forward into a block, and the decompressor must read the bitstream backwards. To find the start of the bitstream, it is therefore necessary to know the offset of the last byte of the block, which can be found by counting Block_Size bytes after the block header. After writing the last bit containing information, the compressor writes a single 1 bit and then fills the rest of the byte with zero bits. The last byte of the compressed bitstream cannot be zero for that reason. When decompressing, the last byte containing the padding is the first byte to read. The decompressor needs to skip the up to 7 bits of 0-padding as well as the the first 1 bit that occurs. Afterwards, the useful part of the bitstream begins. FSE decoding requires a 'state' to be carried from symbol to symbol. For more explanation on FSE decoding, see Section 4.1. For sequence decoding, a separate state keeps track of each literal lengths, offsets, and match lengths symbols. Some FSE primitives are also used. For more details on the operation of these primitives, see Section 4.1. Collet & Kucherawy Expires October 25, 2020 [Page 25] Internet-Draft application/zstd April 2020 The bitstream starts with initial FSE state values, each using the required number of bits in their respective accuracy, decoded previously from their normalized distribution. It starts with Literals_Length_State, followed by Offset_State, and finally Match_Length_State. Note that all values are read backward, so the 'start' of the bitstream is at the highest position in memory, immediately before the last 1 bit for padding. After decoding the starting states, a single sequence is decoded Number_Of_Sequences times. These sequences are decoded in order from first to last. Since the compressor writes the bitstream in the forward direction, this means the compressor must encode the sequences starting with the last one and ending with the first. For each of the symbol types, the FSE state can be used to determine the appropriate code. The code then defines the Baseline and Number_of_Bits to read for each type. The description of the codes for how to determine these values can be found in Section 3.1.1.3.2.1. Decoding starts by reading the Number_of_Bits required to decode offset. It does the same for Match_Length and then for Literals_Length. This sequence is then used for Sequence Execution (see Section 3.1.1.4). If it is not the last sequence in the block, the next operation is to update states. Using the rules pre-calculated in the decoding tables, Literals_Length_State is updated, followed by Match_Length_State, and then Offset_State. See Section 4.1 for details on how to update states from the bitstream. This operation will be repeated Number_of_Sequences times. At the end, the bitstream shall be entirely consumed; otherwise, the bitstream is considered corrupted. 3.1.1.3.2.2. Default Distributions If Predefined_Mode is selected for a symbol type, its FSE decoding table is generated from a predefined distribution table defined here. For details on how to convert this distribution into a decoding table, see Section 4.1. 3.1.1.3.2.2.1. Literals Length The decoding table uses an accuracy log of 6 bits (64 states). Collet & Kucherawy Expires October 25, 2020 [Page 26] Internet-Draft application/zstd April 2020 short literalsLength_defaultDistribution[36] = { 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 2, 1, 1, 1, 1, 1, -1,-1,-1,-1 }; 3.1.1.3.2.2.2. Match Length The decoding table uses an accuracy log of 6 bits (64 states). short matchLengths_defaultDistribution[53] = { 1, 4, 3, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,-1,-1, -1,-1,-1,-1,-1 }; 3.1.1.3.2.2.3. Offset Codes The decoding table uses an accuracy log of 5 bits (32 states), and supports a maximum N value of 28, allowing offset values up to 536,870,908. If any sequence in the compressed block requires a larger offset than this, it's not possible to use the default distribution to represent it. short offsetCodes_defaultDistribution[29] = { 1, 1, 1, 1, 1, 1, 2, 2, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,-1,-1,-1,-1,-1 }; 3.1.1.4. Sequence Execution Once literals and sequences have been decoded, they are combined to produce the decoded content of a block. Each sequence consists of a tuple of (literals_length, offset_value, match_length), decoded as described in the Sequences_Section (Section 3.1.1.3.2). To execute a sequence, first copy literals_length bytes from the decoded literals to the output. Then, match_length bytes are copied from previous decoded data. The offset to copy from is determined by offset_value: o if Offset_Value > 3, then the offset is Offset_Value - 3; Collet & Kucherawy Expires October 25, 2020 [Page 27] Internet-Draft application/zstd April 2020 o if Offset_Value is from 1-3, the offset is a special repeat offset value. See Section 3.1.1.5 for how the offset is determined in this case. The offset is defined as from the current position (after copying the literals), so an offset of 6 and a match length of 3 means that 3 bytes should be copied from 6 bytes back. Note that all offsets leading to previously decoded data must be smaller than Window_Size defined in Frame_Header_Descriptor (Section 3.1.1.1.1). 3.1.1.5. Repeat Offsets As seen above, the first three values define a repeated offset; we will call them Repeated_Offset1, Repeated_Offset2, and Repeated_Offset3. They are sorted in recency order, with Repeated_Offset1 meaning "most recent one". If offset_value is 1, then the offset used is Repeated_Offset1, etc. There is one exception: When the current sequence's literals_length is 0, repeated offsets are shifted by 1, so an offset_value of 1 means Repeated_Offset2, an offset_value of 2 means Repeated_Offset3, and an offset_value of 3 means Repeated_Offset1 - 1_byte. For the first block, the starting offset history is populated with the following values: Repeated_Offset1 (1), Repeated_Offset2 (4), and Repeated_Offset3 (8), unless a dictionary is used, in which case they come from the dictionary. Then each block gets its starting offset history from the ending values of the most recent Compressed_Block. Note that blocks that are not Compressed_Block are skipped; they do not contribute to offset history. The newest offset takes the lead in offset history, shifting others back (up to its previous place if it was already present). This means that when Repeated_Offset1 (most recent) is used, history is unmodified. When Repeated_Offset2 is used, it is swapped with Repeated_Offset1. If any other offset is used, it becomes Repeated_Offset1, and the rest are shifted back by 1. 3.1.2. Skippable Frames +--------------+------------+-----------+ | Magic_Number | Frame_Size | User_Data | +--------------+------------+-----------+ | 4 bytes | 4 bytes | n bytes | Collet & Kucherawy Expires October 25, 2020 [Page 28] Internet-Draft application/zstd April 2020 +--------------+------------+-----------+ Skippable frames allow the insertion of user-defined metadata into a flow of concatenated frames. Skippable frames defined in this specification are compatible with skippable frames in [LZ4]. From a compliant decoder perspective, skippable frames simply need to be skipped, and their content ignored, resuming decoding after the skippable frame. It should be noted that a skippable frame can be used to watermark a stream of concatenated frames embedding any kind of tracking information (even just a Universally Unique Identifier (UUID)). Users wary of such possibility should scan the stream of concatenated frames in an attempt to detect such frames for analysis or removal. The fields are: Magic_Number: 4 bytes, little-endian format. Value: 0x184D2A5?, which means any value from 0x184D2A50 to 0x184D2A5F. All 16 values are valid to identify a skippable frame. This specification does not detail any specific tagging methods for skippable frames. Frame_Size: This is the size, in bytes, of the following User_Data (without including the magic number nor the size field itself). This field is represented using 4 bytes, little-endian format, unsigned 32 bits. This means User_Data can't be bigger than (2^32-1) bytes. User_Data: This field can be anything. Data will just be skipped by the decoder. 4. Entropy Encoding Two types of entropy encoding are used by the Zstandard format: FSE and Huffman coding. Huffman is used to compress literals, while FSE is used for all other symbols (Literals_Length_Code, Match_Length_Code, and offset codes) and to compress Huffman headers. 4.1. FSE FSE, short for Finite State Entropy, is an entropy codec based on [ANS]. FSE encoding/decoding involves a state that is carried over between symbols, so decoding must be done in the opposite direction as encoding. Therefore, all FSE bitstreams are read from end to Collet & Kucherawy Expires October 25, 2020 [Page 29] Internet-Draft application/zstd April 2020 beginning. Note that the order of the bits in the stream is not reversed; they are simply read in the reverse order from which they were written. For additional details on FSE, see Finite State Entropy [FSE]. FSE decoding involves a decoding table that has a power of 2 size and contains three elements: Symbol, Num_Bits, and Baseline. The base 2 logarithm of the table size is its Accuracy_Log. An FSE state value represents an index in this table. To obtain the initial state value, consume Accuracy_Log bits from the stream as a little-endian value. The next symbol in the stream is the Symbol indicated in the table for that state. To obtain the next state value, the decoder should consume Num_Bits bits from the stream as a little-endian value and add it to Baseline. 4.1.1. FSE Table Description To decode FSE streams, it is necessary to construct the decoding table. The Zstandard format encodes FSE table descriptions as described here. An FSE distribution table describes the probabilities of all symbols from 0 to the last present one (included) on a normalized scale of (1 << Accuracy_Log). Note that there must be two or more symbols with non-zero probability. A bitstream is read forward, in little-endian fashion. It is not necessary to know its exact size, since the size will be discovered and reported by the decoding process. The bitstream starts by reporting on which scale it operates. If low4bits designates the lowest 4 bits of the first byte, then Accuracy_Log = low4bits + 5. This is followed by each symbol value, from 0 to the last present one. The number of bits used by each field is variable and depends on: Remaining probabilities + 1: For example, presuming an Accuracy_Log of 8, and presuming 100 probabilities points have already been distributed, the decoder may read any value from 0 to (256 - 100 + 1) == 157, inclusive. Therefore, it must read log2sup(157) == 8 bits. Value decoded: Small values use 1 fewer bit. For example, presuming values from 0 to 157 (inclusive) are possible, 255 - 157 = 98 values are remaining in an 8-bit field. The first 98 values (hence from 0 to 97) use only 7 bits, and values from 98 to 157 Collet & Kucherawy Expires October 25, 2020 [Page 30] Internet-Draft application/zstd April 2020 use 8 bits. This is achieved through this scheme: +------------+---------------+-----------+ | Value Read | Value Decoded | Bits Used | +------------+---------------+-----------+ | 0 - 97 | 0 - 97 | 7 | +------------+---------------+-----------+ | 98 - 127 | 98 - 127 | 8 | +------------+---------------+-----------+ | 128 - 225 | 0 - 97 | 7 | +------------+---------------+-----------+ | 226 - 255 | 128 - 157 | 8 | +------------+---------------+-----------+ Symbol probabilities are read one by one, in order. The probability is obtained from Value decoded using the formula P = Value - 1. This means the value 0 becomes the negative probability -1. This is a special probability that means "less than 1". Its effect on the distribution table is described below. For the purpose of calculating total allocated probability points, it counts as 1. When a symbol has a probability of zero, it is followed by a 2-bit repeat flag. This repeat flag tells how many probabilities of zeroes follow the current one. It provides a number ranging from 0 to 3. If it is a 3, another 2-bit repeat flag follows, and so on. When the last symbol reaches a cumulated total of (1 << Accuracy_Log), decoding is complete. If the last symbol makes the cumulated total go above (1 << Accuracy_Log), distribution is considered corrupted. Finally, the decoder can tell how many bytes were used in this process and how many symbols are present. The bitstream consumes a round number of bytes. Any remaining bit within the last byte is simply unused. The context in which the table is to be used specifies an expected number of symbols. That expected number of symbols never exceeds 256. If the number of symbols decoded is not equal to the expected, the header should be considered corrupt. The distribution of normalized probabilities is enough to create a unique decoding table. The table has a size of (1 << Accuracy_Log). Each cell describes the symbol decoded and instructions to get the next state. Symbols are scanned in their natural order for "less than 1" probabilities as described above. Symbols with this probability are Collet & Kucherawy Expires October 25, 2020 [Page 31] Internet-Draft application/zstd April 2020 being attributed a single cell, starting from the end of the table and retreating. These symbols define a full state reset, reading Accuracy_Log bits. All remaining symbols are allocated in their natural order. Starting from symbol 0 and table position 0, each symbol gets allocated as many cells as its probability. Cell allocation is spread, not linear; each successor position follows this rule: position += (tableSize >> 1) + (tableSize >> 3) + 3; position &= tableSize - 1; A position is skipped if it is already occupied by a "less than 1" probability symbol. Position does not reset between symbols; it simply iterates through each position in the table, switching to the next symbol when enough states have been allocated to the current one. The result is a list of state values. Each state will decode the current symbol. To get the Number_of_Bits and Baseline required for the next state, it is first necessary to sort all states in their natural order. The lower states will need 1 more bit than higher ones. The process is repeated for each symbol. For example, presuming a symbol has a probability of 5, it receives five state values. States are sorted in natural order. The next power of 2 is 8. The space of probabilities is divided into 8 equal parts. Presuming the Accuracy_Log is 7, this defines 128 states, and each share (divided by 8) is 16 in size. In order to reach 8, 8 - 5 = 3 lowest states will count "double", doubling the number of shares (32 in width), requiring 1 more bit in the process. Baseline is assigned starting from the higher states using fewer bits, and proceeding naturally, then resuming at the first state, each taking its allocated width from Baseline. Collet & Kucherawy Expires October 25, 2020 [Page 32] Internet-Draft application/zstd April 2020 +----------------+-------+-------+--------+------+-------+ | state order | 0 | 1 | 2 | 3 | 4 | +----------------+-------+-------+--------+------+-------+ | width | 32 | 32 | 32 | 16 | 16 | +----------------+-------+-------+--------+------+-------+ | Number_of_Bits | 5 | 5 | 5 | 4 | 4 | +----------------+-------+-------+--------+------+-------+ | range number | 2 | 4 | 6 | 0 | 1 | +----------------+-------+-------+--------+------+-------+ | Baseline | 32 | 64 | 96 | 0 | 16 | +----------------+-------+-------+--------+------+-------+ | range | 32-63 | 64-95 | 96-127 | 0-15 | 16-31 | +----------------+-------+-------+--------+------+-------+ The next state is determined from the current state by reading the required Number_of_Bits and adding the specified Baseline. See Appendix A for the results of this process that are applied to the default distributions. 4.2. Huffman Coding Zstandard Huffman-coded streams are read backwards, similar to the FSE bitstreams. Therefore, to find the start of the bitstream, it is necessary to know the offset of the last byte of the Huffman-coded stream. After writing the last bit containing information, the compressor writes a single 1 bit and then fills the rest of the byte with 0 bits. The last byte of the compressed bitstream cannot be 0 for that reason. When decompressing, the last byte containing the padding is the first byte to read. The decompressor needs to skip the up to 7 bits of 0-padding as well as the first 1 bit that occurs. Afterwards, the useful part of the bitstream begins. The bitstream contains Huffman-coded symbols in little-endian order, with the codes defined by the method below. 4.2.1. Huffman Tree Description Prefix coding represents symbols from an a priori known alphabet by bit sequences (codewords), one codeword for each symbol, in a manner such that different symbols may be represented by bit sequences of different lengths, but a parser can always parse an encoded string unambiguously symbol by symbol. Collet & Kucherawy Expires October 25, 2020 [Page 33] Internet-Draft application/zstd April 2020 Given an alphabet with known symbol frequencies, the Huffman algorithm allows the construction of an optimal prefix code using the fewest bits of any possible prefix codes for that alphabet. The prefix code must not exceed a maximum code length. More bits improve accuracy but yield a larger header size and require more memory or more complex decoding operations. This specification limits the maximum code length to 11 bits. All literal values from zero (included) to the last present one (excluded) are represented by Weight with values from 0 to Max_Number_of_Bits. Transformation from Weight to Number_of_Bits follows this pseudocode: if Weight == 0 Number_of_Bits = 0 else Number_of_Bits = Max_Number_of_Bits + 1 - Weight The last symbol's Weight is deduced from previously decoded ones, by completing to the nearest power of 2. This power of 2 gives Max_Number_of_Bits the depth of the current tree. For example, presume the following Huffman tree must be described: +---------------+----------------+ | Literal Value | Number_of_Bits | +---------------+----------------+ | 0 | 1 | +---------------+----------------+ | 1 | 2 | +---------------+----------------+ | 2 | 3 | +---------------+----------------+ | 3 | 0 | +---------------+----------------+ | 4 | 4 | +---------------+----------------+ | 5 | 4 | +---------------+----------------+ The tree depth is 4, since its longest element uses 4 bits. (The longest elements are those with the smallest frequencies.) Value 5 will not be listed as it can be determined from the values for 0-4, nor will values above 5 as they are all 0. Values from 0 to 4 will be listed using Weight instead of Number_of_Bits. The pseudocode to determine Weight is: Collet & Kucherawy Expires October 25, 2020 [Page 34] Internet-Draft application/zstd April 2020 if Number_of_Bits == 0 Weight = 0 else Weight = Max_Number_of_Bits + 1 - Number_of_Bits It gives the following series of weights: +---------------+--------+ | Literal Value | Weight | +---------------+--------+ | 0 | 4 | +---------------+--------+ | 1 | 3 | +---------------+--------+ | 2 | 2 | +---------------+--------+ | 3 | 0 | +---------------+--------+ | 4 | 1 | +---------------+--------+ The decoder will do the inverse operation: having collected weights of literals from 0 to 4, it knows the last literal, 5, is present with a non-zero Weight. The Weight of 5 can be determined by advancing to the next power of 2. The sum of 2^(Weight-1) (excluding 0's) is 15. The nearest power of 2 is 16. Therefore, Max_Number_of_Bits = 4 and Weight[5] = 16 - 15 = 1. 4.2.1.1. Huffman Tree Header This is a single byte value (0-255), which describes how the series of weights is encoded. headerByte < 128: The series of weights is compressed using FSE (see below). The length of the FSE-compressed series is equal to headerByte (0-127). headerByte >= 128: This is a direct representation, where each Weight is written directly as a 4-bit field (0-15). They are encoded forward, 2 weights to a byte with the first weight taking the top 4 bits and the second taking the bottom 4; for example, the following operations could be used to read the weights: Weight[0] = (Byte[0] >> 4) Weight[1] = (Byte[0] & 0xf), etc. The full representation occupies ceiling(Number_of_Symbols/2) Collet & Kucherawy Expires October 25, 2020 [Page 35] Internet-Draft application/zstd April 2020 bytes, meaning it uses only full bytes even if Number_of_Symbols is odd. Number_of_Symbols = headerByte - 127. Note that maximum Number_of_Symbols is 255 - 127 = 128. If any literal has a value over 128, raw header mode is not possible, and it is necessary to use FSE compression. 4.2.1.2. FSE Compression of Huffman Weights In this case, the series of Huffman weights is compressed using FSE compression. It is a single bitstream with two interleaved states, sharing a single distribution table. To decode an FSE bitstream, it is necessary to know its compressed size. Compressed size is provided by headerByte. It's also necessary to know its maximum possible decompressed size, which is 255, since literal values span from 0 to 255, and the last symbol's Weight is not represented. An FSE bitstream starts by a header, describing probabilities distribution. It will create a decoding table. For a list of Huffman weights, the maximum accuracy log is 6 bits. For more details, see Section 4.1.1. The Huffman header compression uses two states, which share the same FSE distribution table. The first state (State1) encodes the even- numbered index symbols, and the second (State2) encodes the odd- numbered index symbols. State1 is initialized first, and then State2, and they take turns decoding a single symbol and updating their state. For more details on these FSE operations, see Section 4.1. The number of symbols to be decoded is determined by tracking the bitStream overflow condition: If updating state after decoding a symbol would require more bits than remain in the stream, it is assumed that extra bits are zero. Then, symbols for each of the final states are decoded and the process is complete. 4.2.1.3. Conversion from Weights to Huffman Prefix Codes All present symbols will now have a Weight value. It is possible to transform weights into Number_of_Bits, using this formula: if Weight > 0 Number_of_Bits = Max_Number_of_Bits + 1 - Weight else Number_of_Bits = 0 Symbols are sorted by Weight. Within the same Weight, symbols keep Collet & Kucherawy Expires October 25, 2020 [Page 36] Internet-Draft application/zstd April 2020 natural sequential order. Symbols with a Weight of zero are removed. Then, starting from the lowest Weight, prefix codes are distributed in sequential order. For example, assume the following list of weights has been decoded: +---------+--------+ | Literal | Weight | +---------+--------+ | 0 | 4 | +---------+--------+ | 1 | 3 | +---------+--------+ | 2 | 2 | +---------+--------+ | 3 | 0 | +---------+--------+ | 4 | 1 | +---------+--------+ | 5 | 1 | +---------+--------+ Sorting by weight and then the natural sequential order yields the following distribution: +---------+--------+----------------+--------------+ | Literal | Weight | Number_Of_Bits | Prefix Codes | +---------+--------+----------------|--------------+ | 3 | 0 | 0 | N/A | +---------+--------+----------------|--------------+ | 4 | 1 | 4 | 0000 | +---------+--------+----------------|--------------+ | 5 | 1 | 4 | 0001 | +---------+--------+----------------|--------------+ | 2 | 2 | 3 | 001 | +---------+--------+----------------|--------------+ | 1 | 3 | 2 | 01 | +---------+--------+----------------|--------------+ | 0 | 4 | 1 | 1 | +---------+--------+----------------|--------------+ 4.2.2. Huffman-Coded Streams Given a Huffman decoding table, it is possible to decode a Huffman- coded stream. Each bitstream must be read backward, which starts from the end and goes up to the beginning. Therefore, it is necessary to know the Collet & Kucherawy Expires October 25, 2020 [Page 37] Internet-Draft application/zstd April 2020 size of each bitstream. It is also necessary to know exactly which bit is the last. This is detected by a final bit flag: the highest bit of the last byte is a final-bit-flag. Consequently, a last byte of 0 is not possible. And the final-bit-flag itself is not part of the useful bitstream. Hence, the last byte contains between 0 and 7 useful bits. Starting from the end, it is possible to read the bitstream in a little-endian fashion, keeping track of already used bits. Since the bitstream is encoded in reverse order, starting from the end, read symbols in forward order. For example, if the literal sequence "0145" was encoded using the above prefix code, it would be encoded (in reverse order) as: +---------+----------+ | Symbol | Encoding | +---------+----------+ | 5 | 0000 | +---------+----------+ | 4 | 0001 | +---------+----------+ | 1 | 01 | +---------+----------+ | 0 | 1 | +---------+----------+ | Padding | 00001 | +---------+----------+ This results in the following 2-byte bitstream: 00010000 00001101 Here is an alternative representation with the symbol codes separated by underscores: 0001_0000 00001_1_01 Reading the highest Max_Number_of_Bits bits, it's possible to compare the extracted value to the decoding table, determining the symbol to decode and number of bits to discard. The process continues reading up to the required number of symbols per stream. If a bitstream is not entirely and exactly consumed, hence reaching exactly its beginning position with all bits consumed, the decoding process is considered faulty. Collet & Kucherawy Expires October 25, 2020 [Page 38] Internet-Draft application/zstd April 2020 5. Dictionary Format Zstandard is compatible with "raw content" dictionaries, free of any format restriction, except that they must be at least 8 bytes. These dictionaries function as if they were just the content part of a formatted dictionary. However, dictionaries created by "zstd --train" in the reference implementation follow a specific format, described here. Dictionaries are not included in the compressed content but rather are provided out of band. That is, the Dictionary_ID identifies which should be used, but this specification does not describe the mechanism by which the dictionary is obtained prior to use during compression or decompression. A dictionary has a size, defined either by a buffer limit or a file size. The general format is: +--------------+---------------+----------------+---------+ | Magic_Number | Dictionary_ID | Entropy_Tables | Content | +--------------+---------------+----------------+---------+ Magic_Number: 4 bytes ID, value 0xEC30A437, little-endian format. Dictionary_ID: 4 bytes, stored in little-endian format. Dictionary_ID can be any value, except 0 (which means no Dictionary_ID). It is used by decoders to check if they use the correct dictionary. If the frame is going to be distributed in a private environment, any Dictionary_ID can be used. However, for public distribution of compressed frames, the following ranges are reserved and shall not be used: low range: <= 32767 high range: >= (2^31) Entropy_Tables: Follow the same format as the tables in compressed blocks. See the relevant FSE and Huffman sections for how to decode these tables. They are stored in the following order: Huffman table for literals, FSE table for offsets, FSE table for match lengths, and FSE table for literals lengths. These tables populate the Repeat Stats literals mode and Repeat distribution mode for sequence decoding. It is finally followed by 3 offset values, populating repeat offsets (instead of using {1,4,8}), stored in order, 4-bytes little-endian each, for a total of 12 bytes. Each repeat offset must have a value less than the dictionary size. Collet & Kucherawy Expires October 25, 2020 [Page 39] Internet-Draft application/zstd April 2020 Content: The rest of the dictionary is its content. The content acts as a "past" in front of data to be compressed or decompressed, so it can be referenced in sequence commands. As long as the amount of data decoded from this frame is less than or equal to Window_Size, sequence commands may specify offsets longer than the total length of decoded output so far to reference back to the dictionary, even parts of the dictionary with offsets larger than Window_Size. After the total output has surpassed Window_Size, however, this is no longer allowed, and the dictionary is no longer accessible. 6. Use of Dictionaries Provisioning for use of dictionaries with zstd is being explored. See, for example, [DICT-SEC]. The likely outcome will be a registry of well-tested dictionaries optimized for different use cases and identifiers for each, possibly with a private negotiation mechanism for use of unregistered dictionaries. To ensure compatibility with the future specification of use of dictionaries with zstd payloads, especially with MIME, content encoded with the media type registered here should not use a dictionary. The exception to this requirement might be a private dictionary negotiaton, suggested above, which is not part of this specification. 7. IANA Considerations IANA has updated two previously existing registrations and made one new registration as described below. 7.1. The 'application/zstd' Media Type The 'application/zstd' media type identifies a block of data that is compressed using zstd compression. The data is a stream of bytes as described in this document. IANA has added the following to the "Media Types" registry: Type name: application Subtype name: zstd Required parameters: N/A Collet & Kucherawy Expires October 25, 2020 [Page 40] Internet-Draft application/zstd April 2020 Optional parameters: N/A Encoding considerations: binary Security considerations: See Section 8 of [this document] Interoperability considerations: N/A Published specification: [this document] Applications that use this media type: anywhere data size is an issue Fragment identifier considerations: No fragment identifiers are defined for this type. Additional information: Magic number(s): 4 bytes, little-endian format. Value: 0xFD2FB528 File extension(s): zst Macintosh file type code(s): N/A For further information: See [ZSTD] Intended usage: common Restrictions on usage: N/A Author: Murray S. Kucherawy Change Controller: IETF Provisional registration: no 7.2. Content Encoding IANA has added the following entry to the "HTTP Content Coding Registry" within the "Hypertext Transfer Protocol (HTTP) Parameters" registry: Name: zstd Collet & Kucherawy Expires October 25, 2020 [Page 41] Internet-Draft application/zstd April 2020 Description: A stream of bytes compressed using the Zstandard protocol Pointer to specification text: [this document] 7.3. Structured Syntax Suffix IANA is requested to register the following into the Structured Syntax Suffix registry: Name: Zstandard +suffix: +zstd Encoding Considerations: binary Interoperability Considerations: N/A Fragment Identifier Considerations: The syntax and semantics of fragment identifiers specified for +zstd should be as specified for "application/zstd". Security Considerations: See Section 8 of [this document]. Contact: Refer to the author for the application/zstd media type. Author/Change Controller: IETF 7.4. Dictionaries Work in progress includes development of dictionaries that will optimize compression and decompression of particular types of data. Specification of such dictionaries for public use will necessitate registration of a code point from the reserved range described in Section 3.1.1.1.3 and its association with a specific dictionary. However, there are at present no such dictionaries published for public use, so this document makes no immediate request of IANA to create such a registry. 8. Security Considerations Any data compression method involves the reduction of redundancy in the data. Zstandard is no exception, and the usual precautions apply. One should never compress a message whose content must remain secret Collet & Kucherawy Expires October 25, 2020 [Page 42] Internet-Draft application/zstd April 2020 with a message generated by a third party. Such a compression can be used to guess the content of the secret message through analysis of entropy reduction. This was demonstrated in the Compression Ratio Info-leak Made Easy (CRIME) attack [CRIME], for example. A decoder has to demonstrate capabilities to detect and prevent any kind of data tampering in the compressed frame from triggering system faults, such as reading or writing beyond allowed memory ranges. This can be guaranteed by either the implementation language or careful bound checkings. Of particular note is the encoding of Number_of_Sequences values that cause the decoder to read into the block header (and beyond), as well as the indication of a Frame_Content_Size that is smaller than the actual decompressed data, in an attempt to trigger a buffer overflow. It is highly recommended to fuzz-test (i.e., provide invalid, unexpected, or random input and verify safe operation of) decoder implementations to test and harden their capability to detect bad frames and deal with them without any adverse system side effect. An attacker may provide correctly formed compressed frames with unreasonable memory requirements. A decoder must always control memory requirements and enforce some (system-specific) limits in order to protect memory usage from such scenarios. Compression can be optimized by training a dictionary on a variety of related content payloads. This dictionary must then be available at the decoder for decompression of the payload to be possible. While this document does not specify how to acquire a dictionary for a given compressed payload, it is worth noting that third-party dictionaries may interact unexpectedly with a decoder, leading to possible memory or other resource exhaustion attacks. We expect such topics to be discussed in further detail in the Security Considerations section of a forthcoming RFC for dictionary acquisition and transmission, but highlight this issue now out of an abundance of caution. As discussed in Section 3.1.2, it is possible to store arbitrary user metadata in skippable frames. While such frames are ignored during decompression of the data, they can be used as a watermark to track the path of the compressed payload. 9. Implementation Status Source code for a C language implementation of a Zstandard-compliant library is available at [ZSTD-GITHUB]. This implementation is considered to be the reference implementation and is production ready; it implements the full range of the specification. It is Collet & Kucherawy Expires October 25, 2020 [Page 43] Internet-Draft application/zstd April 2020 routinely tested against security hazards and widely deployed within Facebook infrastructure. The reference version is optimized for speed and is highly portable. It has been proven to run safely on multiple architectures (e.g., x86, x64, ARM, MIPS, PowerPC, IA64) featuring 32- or 64-bit addressing schemes, a little- or big-endian storage scheme, a number of different operating systems (e.g., UNIX (including Linux, BSD, OS-X, and Solaris) and Windows), and a number of compilers (e.g., gcc, clang, visual, and icc). A comprehensive and current list of known implementations can be found at [ZSTD]. 10. References 10.1. Normative References [ZSTD] "Zstandard", 2017, . 10.2. Informative References [ANS] Duda, J., "Asymmetric numeral systems: entropy coding combining speed of Huffman coding with compression rate of arithmetic coding", January 2014, . [CRIME] "CRIME", June 2018, . [DICT-SEC] Handte, W., "Security Considerations Regarding Compression Dictionaries", (work in progress) draft-handte-httpbis-dict-sec, October 2019. [FSE] "FiniteStateEntropy", June 2018, . [LZ4] "LZ4 Frame Format Description", January 2018, . [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [XXHASH] "XXHASH Algorithm", 2017, . Collet & Kucherawy Expires October 25, 2020 [Page 44] Internet-Draft application/zstd April 2020 [ZSTD-GITHUB] "zstd", August 2018, . Appendix A. Decoding Tables for Predefined Codes This appendix contains FSE decoding tables for the predefined literal length, match length, and offset codes. The tables have been constructed using the algorithm as given above in Section 4.1.1. The tables here can be used as examples to crosscheck that an implementation has built its decoding tables correctly. A.1. Literal Length Code Table +-------+--------+----------------+------+ | State | Symbol | Number_Of_Bits | Base | +-------+--------+----------------+------+ | 0 | 0 | 0 | 0 | +-------+--------+----------------+------+ | 0 | 0 | 4 | 0 | +-------+--------+----------------+------+ | 1 | 0 | 4 | 16 | +-------+--------+----------------+------+ | 2 | 1 | 5 | 32 | +-------+--------+----------------+------+ | 3 | 3 | 5 | 0 | +-------+--------+----------------+------+ | 4 | 4 | 5 | 0 | +-------+--------+----------------+------+ | 5 | 6 | 5 | 0 | +-------+--------+----------------+------+ | 6 | 7 | 5 | 0 | +-------+--------+----------------+------+ | 7 | 9 | 5 | 0 | +-------+--------+----------------+------+ | 8 | 10 | 5 | 0 | +-------+--------+----------------+------+ | 9 | 12 | 5 | 0 | +-------+--------+----------------+------+ | 10 | 14 | 6 | 0 | +-------+--------+----------------+------+ | 11 | 16 | 5 | 0 | +-------+--------+----------------+------+ | 12 | 18 | 5 | 0 | +-------+--------+----------------+------+ | 13 | 19 | 5 | 0 | +-------+--------+----------------+------+ Collet & Kucherawy Expires October 25, 2020 [Page 45] Internet-Draft application/zstd April 2020 | 14 | 21 | 5 | 0 | +-------+--------+----------------+------+ | 15 | 22 | 5 | 0 | +-------+--------+----------------+------+ | 16 | 24 | 5 | 0 | +-------+--------+----------------+------+ | 17 | 25 | 5 | 32 | +-------+--------+----------------+------+ | 18 | 26 | 5 | 0 | +-------+--------+----------------+------+ | 19 | 27 | 6 | 0 | +-------+--------+----------------+------+ | 20 | 29 | 6 | 0 | +-------+--------+----------------+------+ | 21 | 31 | 6 | 0 | +-------+--------+----------------+------+ | 22 | 0 | 4 | 32 | +-------+--------+----------------+------+ | 23 | 1 | 4 | 0 | +-------+--------+----------------+------+ | 24 | 2 | 5 | 0 | +-------+--------+----------------+------+ | 25 | 4 | 5 | 32 | +-------+--------+----------------+------+ | 26 | 5 | 5 | 0 | +-------+--------+----------------+------+ | 27 | 7 | 5 | 32 | +-------+--------+----------------+------+ | 28 | 8 | 5 | 0 | +-------+--------+----------------+------+ | 29 | 10 | 5 | 32 | +-------+--------+----------------+------+ | 30 | 11 | 5 | 0 | +-------+--------+----------------+------+ | 31 | 13 | 6 | 0 | +-------+--------+----------------+------+ | 32 | 16 | 5 | 32 | +-------+--------+----------------+------+ | 33 | 17 | 5 | 0 | +-------+--------+----------------+------+ | 34 | 19 | 5 | 32 | +-------+--------+----------------+------+ | 35 | 20 | 5 | 0 | +-------+--------+----------------+------+ | 36 | 22 | 5 | 32 | +-------+--------+----------------+------+ | 37 | 23 | 5 | 0 | +-------+--------+----------------+------+ Collet & Kucherawy Expires October 25, 2020 [Page 46] Internet-Draft application/zstd April 2020 | 38 | 25 | 4 | 0 | +-------+--------+----------------+------+ | 39 | 25 | 4 | 16 | +-------+--------+----------------+------+ | 40 | 26 | 5 | 32 | +-------+--------+----------------+------+ | 41 | 28 | 6 | 0 | +-------+--------+----------------+------+ | 42 | 30 | 6 | 0 | +-------+--------+----------------+------+ | 43 | 0 | 4 | 48 | +-------+--------+----------------+------+ | 44 | 1 | 4 | 16 | +-------+--------+----------------+------+ | 45 | 2 | 5 | 32 | +-------+--------+----------------+------+ | 46 | 3 | 5 | 32 | +-------+--------+----------------+------+ | 47 | 5 | 5 | 32 | +-------+--------+----------------+------+ | 48 | 6 | 5 | 32 | +-------+--------+----------------+------+ | 49 | 8 | 5 | 32 | +-------+--------+----------------+------+ | 50 | 9 | 5 | 32 | +-------+--------+----------------+------+ | 51 | 11 | 5 | 32 | +-------+--------+----------------+------+ | 52 | 12 | 5 | 32 | +-------+--------+----------------+------+ | 53 | 15 | 6 | 0 | +-------+--------+----------------+------+ | 54 | 17 | 5 | 32 | +-------+--------+----------------+------+ | 55 | 18 | 5 | 32 | +-------+--------+----------------+------+ | 56 | 20 | 5 | 32 | +-------+--------+----------------+------+ | 57 | 21 | 5 | 32 | +-------+--------+----------------+------+ | 58 | 23 | 5 | 32 | +-------+--------+----------------+------+ | 59 | 24 | 5 | 32 | +-------+--------+----------------+------+ | 60 | 35 | 6 | 0 | +-------+--------+----------------+------+ | 61 | 34 | 6 | 0 | +-------+--------+----------------+------+ Collet & Kucherawy Expires October 25, 2020 [Page 47] Internet-Draft application/zstd April 2020 | 62 | 33 | 6 | 0 | +-------+--------+----------------+------+ | 63 | 32 | 6 | 0 | +-------+--------+----------------+------+ A.2. Match Length Code Table +-------+--------+----------------+------+ | State | Symbol | Number_Of_Bits | Base | +-------+--------+----------------+------+ | 0 | 0 | 0 | 0 | +-------+--------+----------------+------+ | 0 | 0 | 6 | 0 | +-------+--------+----------------+------+ | 1 | 1 | 4 | 0 | +-------+--------+----------------+------+ | 2 | 2 | 5 | 32 | +-------+--------+----------------+------+ | 3 | 3 | 5 | 0 | +-------+--------+----------------+------+ | 4 | 5 | 5 | 0 | +-------+--------+----------------+------+ | 5 | 6 | 5 | 0 | +-------+--------+----------------+------+ | 6 | 8 | 5 | 0 | +-------+--------+----------------+------+ | 7 | 10 | 6 | 0 | +-------+--------+----------------+------+ | 8 | 13 | 6 | 0 | +-------+--------+----------------+------+ | 9 | 16 | 6 | 0 | +-------+--------+----------------+------+ | 10 | 19 | 6 | 0 | +-------+--------+----------------+------+ | 11 | 22 | 6 | 0 | +-------+--------+----------------+------+ | 12 | 25 | 6 | 0 | +-------+--------+----------------+------+ | 13 | 28 | 6 | 0 | +-------+--------+----------------+------+ | 14 | 31 | 6 | 0 | +-------+--------+----------------+------+ | 15 | 33 | 6 | 0 | +-------+--------+----------------+------+ | 16 | 35 | 6 | 0 | +-------+--------+----------------+------+ | 17 | 37 | 6 | 0 | Collet & Kucherawy Expires October 25, 2020 [Page 48] Internet-Draft application/zstd April 2020 +-------+--------+----------------+------+ | 18 | 39 | 6 | 0 | +-------+--------+----------------+------+ | 19 | 41 | 6 | 0 | +-------+--------+----------------+------+ | 20 | 43 | 6 | 0 | +-------+--------+----------------+------+ | 21 | 45 | 6 | 0 | +-------+--------+----------------+------+ | 22 | 1 | 4 | 16 | +-------+--------+----------------+------+ | 23 | 2 | 4 | 0 | +-------+--------+----------------+------+ | 24 | 3 | 5 | 32 | +-------+--------+----------------+------+ | 25 | 4 | 5 | 0 | +-------+--------+----------------+------+ | 26 | 6 | 5 | 32 | +-------+--------+----------------+------+ | 27 | 7 | 5 | 0 | +-------+--------+----------------+------+ | 28 | 9 | 6 | 0 | +-------+--------+----------------+------+ | 29 | 12 | 6 | 0 | +-------+--------+----------------+------+ | 30 | 15 | 6 | 0 | +-------+--------+----------------+------+ | 31 | 18 | 6 | 0 | +-------+--------+----------------+------+ | 32 | 21 | 6 | 0 | +-------+--------+----------------+------+ | 33 | 24 | 6 | 0 | +-------+--------+----------------+------+ | 34 | 27 | 6 | 0 | +-------+--------+----------------+------+ | 35 | 30 | 6 | 0 | +-------+--------+----------------+------+ | 36 | 32 | 6 | 0 | +-------+--------+----------------+------+ | 37 | 34 | 6 | 0 | +-------+--------+----------------+------+ | 38 | 36 | 6 | 0 | +-------+--------+----------------+------+ | 39 | 38 | 6 | 0 | +-------+--------+----------------+------+ | 40 | 40 | 6 | 0 | +-------+--------+----------------+------+ | 41 | 42 | 6 | 0 | Collet & Kucherawy Expires October 25, 2020 [Page 49] Internet-Draft application/zstd April 2020 +-------+--------+----------------+------+ | 42 | 44 | 6 | 0 | +-------+--------+----------------+------+ | 43 | 1 | 4 | 32 | +-------+--------+----------------+------+ | 44 | 1 | 4 | 48 | +-------+--------+----------------+------+ | 45 | 2 | 4 | 16 | +-------+--------+----------------+------+ | 46 | 4 | 5 | 32 | +-------+--------+----------------+------+ | 47 | 5 | 5 | 32 | +-------+--------+----------------+------+ | 48 | 7 | 5 | 32 | +-------+--------+----------------+------+ | 49 | 8 | 5 | 32 | +-------+--------+----------------+------+ | 50 | 11 | 6 | 0 | +-------+--------+----------------+------+ | 51 | 14 | 6 | 0 | +-------+--------+----------------+------+ | 52 | 17 | 6 | 0 | +-------+--------+----------------+------+ | 53 | 20 | 6 | 0 | +-------+--------+----------------+------+ | 54 | 23 | 6 | 0 | +-------+--------+----------------+------+ | 55 | 26 | 6 | 0 | +-------+--------+----------------+------+ | 56 | 29 | 6 | 0 | +-------+--------+----------------+------+ | 57 | 52 | 6 | 0 | +-------+--------+----------------+------+ | 58 | 51 | 6 | 0 | +-------+--------+----------------+------+ | 59 | 50 | 6 | 0 | +-------+--------+----------------+------+ | 60 | 49 | 6 | 0 | +-------+--------+----------------+------+ | 61 | 48 | 6 | 0 | +-------+--------+----------------+------+ | 62 | 47 | 6 | 0 | +-------+--------+----------------+------+ | 63 | 46 | 6 | 0 | +-------+--------+----------------+------+ Collet & Kucherawy Expires October 25, 2020 [Page 50] Internet-Draft application/zstd April 2020 A.3. Offset Code Table +-------+--------+----------------+------+ | State | Symbol | Number_Of_Bits | Base | +-------+--------+----------------+------+ | 0 | 0 | 0 | 0 | +-------+--------+----------------+------+ | 0 | 0 | 5 | 0 | +-------+--------+----------------+------+ | 1 | 6 | 4 | 0 | +-------+--------+----------------+------+ | 2 | 9 | 5 | 0 | +-------+--------+----------------+------+ | 3 | 15 | 5 | 0 | +-------+--------+----------------+------+ | 4 | 21 | 5 | 0 | +-------+--------+----------------+------+ | 5 | 3 | 5 | 0 | +-------+--------+----------------+------+ | 6 | 7 | 4 | 0 | +-------+--------+----------------+------+ | 7 | 12 | 5 | 0 | +-------+--------+----------------+------+ | 8 | 18 | 5 | 0 | +-------+--------+----------------+------+ | 9 | 23 | 5 | 0 | +-------+--------+----------------+------+ | 10 | 5 | 5 | 0 | +-------+--------+----------------+------+ | 11 | 8 | 4 | 0 | +-------+--------+----------------+------+ | 12 | 14 | 5 | 0 | +-------+--------+----------------+------+ | 13 | 20 | 5 | 0 | +-------+--------+----------------+------+ | 14 | 2 | 5 | 0 | +-------+--------+----------------+------+ | 15 | 7 | 4 | 16 | +-------+--------+----------------+------+ | 16 | 11 | 5 | 0 | +-------+--------+----------------+------+ | 17 | 17 | 5 | 0 | +-------+--------+----------------+------+ | 18 | 22 | 5 | 0 | +-------+--------+----------------+------+ | 19 | 4 | 5 | 0 | +-------+--------+----------------+------+ Collet & Kucherawy Expires October 25, 2020 [Page 51] Internet-Draft application/zstd April 2020 | 20 | 8 | 4 | 16 | +-------+--------+----------------+------+ | 21 | 13 | 5 | 0 | +-------+--------+----------------+------+ | 22 | 19 | 5 | 0 | +-------+--------+----------------+------+ | 23 | 1 | 5 | 0 | +-------+--------+----------------+------+ | 24 | 6 | 4 | 16 | +-------+--------+----------------+------+ | 25 | 10 | 5 | 0 | +-------+--------+----------------+------+ | 26 | 16 | 5 | 0 | +-------+--------+----------------+------+ | 27 | 28 | 5 | 0 | +-------+--------+----------------+------+ | 28 | 27 | 5 | 0 | +-------+--------+----------------+------+ | 29 | 26 | 5 | 0 | +-------+--------+----------------+------+ | 30 | 25 | 5 | 0 | +-------+--------+----------------+------+ | 31 | 24 | 5 | 0 | +-------+--------+----------------+------+ Appendix B. Changes Since RFC8478 The following are the changes in this document relative to RFC 8478: o Apply erratum #5786. o Clarify forward compatibility regarding dictionaries. o Clarify application of Block_Maximum_Size. o Add structured media type suffix registration. o Clarify that the content checksum is always 4 bytes. o Clarify handling of reserved and corrupt inputs. o Add fragment identifier considerations to the media type registration. Collet & Kucherawy Expires October 25, 2020 [Page 52] Internet-Draft application/zstd April 2020 Appendix C. Acknowledgments zstd was developed by Yann Collet. Felix Handte and Nick Terrell provided feedback that went into this revision and RFC 8478. RFC 8478 also received contributions from Bobo Bose-Kolanu, Kyle Nekritz, and David Schleimer. Authors' Addresses Yann Collet Facebook 1 Hacker Way Menlo Park, CA 94025 United States of America Email: cyan@fb.com Murray S. Kucherawy (editor) Facebook 1 Hacker Way Menlo Park, CA 94025 United States of America Email: msk@fb.com Collet & Kucherawy Expires October 25, 2020 [Page 53] ./draft-moriarty-caris2-04.txt0000644000764400076440000011037413740061030015456 0ustar iustyiusty Internet Engineering Task Force K. Moriarty Internet-Draft Dell Technologies Intended status: Informational 9 October 2020 Expires: 12 April 2021 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report draft-moriarty-caris2-04 Abstract The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned regional, national, international, and enterprise CSIRTs, operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus for CARIS 2 scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 April 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Moriarty Expires 12 April 2021 [Page 1] Internet-Draft CARIS2 Report October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Accepted Papers . . . . . . . . . . . . . . . . . . . . . . . 3 3. CARIS2 Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Workshop Collaboration . . . . . . . . . . . . . . . . . . . 5 4.1. Breakout 1 Results: Standardization and Adoption . . . . 5 4.1.1. Wide adoption: . . . . . . . . . . . . . . . . . . . 6 4.1.2. Limited Adoption . . . . . . . . . . . . . . . . . . 6 4.2. Breakout 2 Results:Preventative Protocols and Scaling Defense . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Breakout 3 Results: Incident Response Coordination . . . 9 4.4. Breakout 4 Results: Monitoring and Measurement . . . . . 11 4.4.1. IP Address Reputation . . . . . . . . . . . . . . . . 11 4.4.2. Server Name Authentication Reputation C (SNARC) . . . 12 4.4.3. Logging . . . . . . . . . . . . . . . . . . . . . . . 12 4.4.4. Fingerprinting . . . . . . . . . . . . . . . . . . . 12 4.5. Taxonomy and Gaps Session . . . . . . . . . . . . . . . . 13 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Informative References . . . . . . . . . . . . . . . . . 15 10.2. URL References . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop workshop [CARISEvent], sponsored by the Internet Society, took place 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRT), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop [RFC8073], with a focus for CARIS 2 on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption. Considering the related initiative Moriarty Expires 12 April 2021 [Page 2] Internet-Draft CARIS2 Report October 2020 to form a research group [SMART] in the Internet Research Task Force (IRTF) the focus on prevention included consideration of research opportunities to improve protocols and determine if there are ways to improve attack detection devleoped during the protocol design phase that could later influence protocol development in the IETF. This is one way to think about scaling response, through prevention and allowing for new methods to evolve for detection in a post-encrypted world. Although SMART has not progressed, the work to better scale incident response continues through the projects proposed at CARIS2 as well in future CARIS workshops. 2. Accepted Papers Researchers from around the world submitted position and research papers summarizing key aspects of their work to help form the shared content of the workshop. The accepted papers may be found at workshop [CARISEvent], and include: Visualizing Security Automation: Takeshi Takahashi, NICT, Japan Automating Severity Determination: Hideaki Kanehara, NICT, Japan OASIS's OpenC2, Draper and DoD Automated IoT Security (PASC and PAVA): Oscar Garcia-Morchon and Thorsten Dahm Taxonomies and Gaps: Kirsty P., UK NCSC FIRST: Thomas Schreck, Siemens NetSecWarriors: Tim April, Akamai Measured Approaches to IPv6 Address Anonymization and Identity Association: Dave Plonka and Arthur Berger, Akamai The program committee worked to fill in the agenda with meaningful and complementary sessions to round out the theme and encourage collaboration to advance research towards the goals of the workshop. These sessions included: Manufacturer Usage Description (MUD) [RFC8520]: Eliot Lear, Cisco TF-CSIRT: Mirjam Kuhne, RIPE NCC M2M Sharing Revolution, Scott Pinkerton, DoE ANL Moriarty Expires 12 April 2021 [Page 3] Internet-Draft CARIS2 Report October 2020 Comparing OpenC2 with existing efforts, e.g. [I2NSF]: Chris Inacio Alternate Sharing and Mitigation Models: Kathleen Moriarty, DellEMC The presentations provided interesting background to familiarize workshop attendees with current research work, challenges that require addressing for forward progress, and opportunities to collaborate in the desire to better scale attack response and prevention. 3. CARIS2 Goals The goal of each CARIS workshop has been to focus on the challenge of improving the overall security posture. The approach has been to identify intrinsic or built-in protection capabilities for improved defense, automation, and scaling attack response through collaboration and improved architectural patterns. It has been assumed that it is unlikely that additional training will address the lack of information security professionals to fill the job gap. Currently, there is approximately a 3 million person deficit [defecit] for security professionals worldwide and it's only expected to grow. In preparing for the workshop, the chair and programme committee considered that this gap cannot be filled through training, but the gap requires measures to reduce the number of information security professionals needed through new architectures and research towards attack prevention. CARIS 2 was specifically focused on the industry shift towards the increased use of stronger session encryption (TLSv1.3 [RFC8446], QUIC [I-D.ietf-quic-transport], TCPcrypt [RFC8548], etc.) and how prevention and detection can advance in this new paradigm. As such the goals for this workshop included: * Scale attack response, including ways to improve prevention, as the Internet shifts to use of stronger and more ubiquitous encryption. - Determine research opportunities - Consider methods to improve protocols/provide guidance toward goal. For instance, are there ways to build detection of threats into protocols since they cannot be monitored on the wire in the future? * Identify promising research ideas to seed a research agenda to input to the proposed IRTF SMART research group. Moriarty Expires 12 April 2021 [Page 4] Internet-Draft CARIS2 Report October 2020 4. Workshop Collaboration Both CARIS workshops brought together a set of individuals who had not previously collaborated toward the goals of scaling attack response. This is important as the participants span various areas of Internet technology work, research, provide a global perspective, have access to varying data sets and infrastructure, and are influential in their area of expertise. The specific goals of the CARIS 2 workshop, contributions, and the participants were all considered in the design of the breakout sessions to both identify and advance research through collaboration. The breakout sessions varied in format to keep attendees engaged and collaborating, involving the full set of attendees and breakout groups. The Workshop focused in trying to help identify potential areas for collaboration and advance research. To do this, the workshop included 5 different breakout sessions focused on: 1. Standardization and adoption: identify widely adopted and pervasive standard protocols and data formats as well as those that failed. 2. Preventative Protocols and Scaling Defense: identify protocols to address automation at scale. 3. Incident Response Coordination: brainstorm on what potential areas of research or future workshops could be held to improve on the scalability of incident response. 4. Monitoring and Measurement:brainstorm on methods to perform monitoring and measurement with the heightened need and requirement to address privacy. 5. Taxonomy and Gaps: brainstorm on away forward for the proposed SMART group 4.1. Breakout 1 Results: Standardization and Adoption This breakout session considered points raised in the preceding talks on hurdles for automating security controls, detection, and response as the teams presenting noted several challenges they still face today. The breakout worked toward identifying standard protocols and data formats that succeeded in achieving adoption as well as several that failed or only achieved limited adoption. The results from the evaluation were interesting and could aid in achieving greater adoption when new work areas are developed. The results follow: Moriarty Expires 12 April 2021 [Page 5] Internet-Draft CARIS2 Report October 2020 4.1.1. Wide adoption: Secure Sockets Layer (SSL), now replaced by Transport Layer Security (TLS) protocol. Observations: There was a clear need for session encryption at the transport layer to protect application data. eCommerce was a driving force at the time with a downside to those who did not adopt. Other positive attributes that aided adoption were modular design, clean interfaces, and being first to market. Simple Network Management Protocol (SNMP) enables configuration management of devices with extension points for private configuration and management settings. SNMP is widely adopted and is only now after decades being replaced by a newer alternative, YANG (a data modeling language) facilitating configuration management via NETCONF or RESTCONF. The SNMP protocol facilitated an answer to a needed problem set: configuration, telemetry, and network management. It's development considered the connection between the user, vendor, and developers. Challenges did surface for adoption from SNMPv1.1 to 1.2, as there was no compelling reason for adoption. SNMPv3 gained adoption due to its resilience to attacks by providing protection through improved authentication and encryption. IP Flow Information Export (IPFix) was identified as achieving wide adoption for several reasons. The low cost of entry, wide vendor support, diverse user base, and the wide set of use cases spanning multiple technology areas were some of the key drivers cited. X.509 was explored for its success in gaining adoption. The solution being abstract from crypto, open, customizable, and extensible were some of the reasons cited for its successful adoption. The team deemed it a good solution to a good problem and observed that government adoption aided its success. 4.1.2. Limited Adoption Next each team evaluated solutions that have not enjoyed wide adoption. Although STIX and IODEF are somewhat similar in their goals, the standards were selected for evaluation by two separate groups with some common findings. *Structured Threat Information eXpression (STIX)* has had limited adoption by the financial sector, but no single, definitive end user. The standard is still in development with the US government as the primary developer in partnership with OASIS. There is interest in Moriarty Expires 12 April 2021 [Page 6] Internet-Draft CARIS2 Report October 2020 using STIX to manage content, but users don't really care about what technology is used for the exchange. The initial goals may not wind up matching the end result for STIX as managing content may be the primary use case. Incident Object Description Exchange Format (IODEF) was specified by national research and education networks (NREN) and computer security incident response teams (CSIRT) and formalized in the IETF. The user is the security operations center (SOC). While there are several implementations, it is not widely adopted. In terms of exchange, users are more interested in indicators than full event information and this applies to STIX as well. Sharing and trust are additional hurdles as many are not willing to disclose information. DNS-based Authentication of Named Entities (DANE) has DNSsec as a dependency, which is a hurdle towards adoption (too many dependencies). It has a roll-your-own adoption model, which is risky. While there are some large pockets of adoption, there is still much work to do to gain widespread adoption. A regulatory requirement gave rise to partial adoption in Germany, which naturally resulted in production of documentation written in German - possibly giving rise to further adoption in German-speaking countries. There has also been progress made in the Netherlands through the creation of a website, internet.nl. The website allows you you to test your website for a number of standards (IPv6, DNSSEC, DANE etc.). Internet.nl is a collaboration of industry organizations, companies, and the government in the Netherlands, and is available for worldwide use. IP version 6 (IPv6) has struggled and the expense of running a dual stack was one of the highest concerns on the list discussed in the workshop breakout. The end user for IPv6 is everyone and the breakout team considered it too ambiguous. Too many new requirements have been added over its 20 year life. The scope of necessary adoption is large with many peripheral devices. Government requirements for support have helped somewhat with improved interoperability and adoption, but features like NAT being added to IPv4 slowed adoption. With no new features being added to IPv4 and lessons learned, there's still a possibility for success. 4.2. Breakout 2 Results:Preventative Protocols and Scaling Defense This next breakout followed the sessions on MUD, PAVA (Protocol for Automated Vulnerability Assessment), and PASC (Protocol for Automatic Security Configuration) which have themes of automation at scale. MUD was designed for IoT and as such, scaling was a major consideration. The PAVA and PASC work builds off of MUD and maintains some of the same themes. This next breakout was focused on Moriarty Expires 12 April 2021 [Page 7] Internet-Draft CARIS2 Report October 2020 groups brainstorming on preventative measures and enabling vendors to deploy mitigations. One group dove a bit deeper into MUD and layer 2 (L2) discovery. MUD changes sets of filtering control management to the vendor or intermediary MUD vendors for a predictable platform that scales well. While the overall value of MUD is clear, the use of MUD and what traffic is expected for a particular device should be considered sensitive information as it could be used to exploit a device. MUD has an option of using L2 discovery to share MUD files. L2 discovery, like the dynamic host configuration protocol (DHCP) is not encrypted from the local client to the DHCP server at this point in time (there is some interest to correct this, but it hasn't received enough support yet). As a result, it is possible to leak information and reveal data about the devices for which the MUD files would be applied. This could multicast out information such as network characteristics, firmware versions, manufacturer, etc. There was some discussion on the use of 802.11 to improve connections. Several participants from this group planned to research this further and identify options to prevent information leakage while achieving the stated goals of MUD. The next group discussed a proposal one of the participants had already begun developing, namely privacy for rendezvous service. The basic idea was to encrypt SNI using DNS to obtain public keys. The suffix on server IPv6 would be unique to a TLS session (Information missing). The discussion on this proposal was fruitful as the full set of attendees engaged, with special interest from the incident responders to be involved in early review cycles. Incident responders are very interested to understand how protocols will change and to assess the overall impact of changes on privacy and security operations. Even if there are no changes to the protocol proposals stemming from this review, the group discussion landed on this being a valuable exchange to understand early the impacts of changes for incident detection and mitigation, to devise new strategies and to provide assessments on the impact of protocol changes on security in the round. The third group reported back on trust exchanges relying heavily on relationships between individuals. They were concerned with scaling the trust model and finding ways to do that better. The third breakout dove deeper into this topic. The fourth breakout group discussed useful data for incident responders. This built on the first breakout session. The group determined that indicators of compromise (IOCs) are what most organizations and groups are able to successfully exchange. Ideally, these would be fixed and programmable. They discussed developing a Moriarty Expires 12 April 2021 [Page 8] Internet-Draft CARIS2 Report October 2020 richer event threat sharing format. When reporting back to the group, a successful solution used in the EU was mentioned, Malware Information Sharing Platform (MISP) [MISP]. This will be considered in their review of existing efforts to determine if anything new is needed. 4.3. Breakout 3 Results: Incident Response Coordination Incident response coordination currently does not scale. This breakout session focused on brainstorming on incident response and coordination, looking specifically at what works well for teams today, what is holding them back, and what risks loom ahead. Output from this session could be used to generate research and to dive deeper in a dedicated workshop on these topics. Supporting: * Trust between individuals in incident response teams * Volume of strong signals and automated discovery * Need to protect network as a forcing function * Law and legal catalyst, motivator to stay on top * Current efforts supported by profit and company interests, but those may shift * Fear initially results in activity or in terms of the diagram used, a burst of wind, but eventually leads to complacency Creating Drag: * Lack of clear KPIs * Too many standards * Regional border impact data flows * Ease of use for end users * Speed to market without security considerations * Legal framework slow to adapt * Disconnect in actual/perceived risk * Regulatory requirements preventing data sharing Moriarty Expires 12 April 2021 [Page 9] Internet-Draft CARIS2 Report October 2020 * Lack of clarity in shared information * Behind the problem/reactionary * Lack of resources/participation * Monoculture narrows focus Looming problems: * Dynamic threat landscape * Liability * Vocabulary collision * Lack of target/adversary clarity * Bifurcation of Internet * Government regulation * Confusion around metrics * Sensitivity of intelligence (trust) * Lack of skilled analysts * Lack of "fraud loss" data sharing * Stakeholder/leader confusion * Unknown impact of emerging technologies * Over-centralization of the Internet * New technologies and protocols * Changes in application layer configurations (e.g. browser resolvers) Moriarty Expires 12 April 2021 [Page 10] Internet-Draft CARIS2 Report October 2020 4.4. Breakout 4 Results: Monitoring and Measurement The fourth breakout followed Dave Plonka's talk on IPv6 aggregation to provide privacy for IPv6 sessions. Essentially, IPv6 provides additional capabilities for monitoring sessions end-to-end. Dave and his co-author Arthur Berger primarily focus on measurement research, but found a way to aggregate sessions to assist with maintaining user privacy. If you can devise methods to perform management and measurement, or even perform security functions, while accommodating methods to protect privacy, a stronger result is likely. This also precludes the need for additional privacy improvement work to defeat measurement objectives. This breakout was focused on devising methods to perform monitoring and measurement, coupled with advancing privacy considerations. The full group listed out options for protocols to explore and ranked them, with the 4 highest then explored by the breakout groups. Groups agreed to work further on the proposed ideas. 4.4.1. IP Address Reputation There is a need to understand address assignment and configuration for hosts and services, especially with IPv6 [PlonkaBergerCARIS2] in (1) sharing IP address-related information to inform attack response efforts, while still protecting the privacy of victims and possible attackers, and (2) mitigating abuse by altering the treatment, e.g., dropping or rate-limiting, of packets. Currently, there is no database for analysts and researchers can consult to, for instance, determine to lifetimes of IPv6 addresses or the prefix length at which the address is expected to be stable over time. The researchers propose either introduce a new database (compare PeerdingDB) or extending existing databases (e.g., the RIRs'), to contain such information and allowing arbitrary queries. The prefix information would either be provided by networks, who are willing, or based on measurement algorithms that reverse-engineer reasonable values based on Internet measurements [PlonkaBergerKIP]. In the former case, the incentive of networks to provide such information is to so that privacy of their users is respected and to limit collateral damage caused by access control lists affecting more of that network's addresses than necessary, e.g., in the face of abuse. This is an early idea, the lead to contact if interested to help develop this further is Dave Plonka. Moriarty Expires 12 April 2021 [Page 11] Internet-Draft CARIS2 Report October 2020 4.4.2. Server Name Authentication Reputation C (SNARC) SNARC is a mechanism to assign value to trust indicators, used to make decisions about good or bad actors. The mechanism would be able to distinguish between client and server in connections, would be human readable, builds on zero trust networking, and avoids consolidation supporting legitimate new players. The group planned to research visual aspects and underlying principles as they begin work on this idea. SNARC has a similar theme to the IP reputation/ BGP ranking idea mentioned above. An RFC would help customers and design team on existing solutions. They planned to begin work in several stages, researching "trust" indicators, "trust" value calculations, and research actions to apply to "trust". The overarching goal is to address blind trust, one of the challenges identified with information/incident exchanges. If interested to work further with this team, the lead contact is: Trent Adams. 4.4.3. Logging The breakout group presented the possibility of injecting logging capabilities at compile time for applications, resulting in a more consistent set of logs, covering an agreed set of conditions. If the log-injecting compiler were used this would increase logging for those applications and improve the uniformity of logged activity. Increasing logging capabilities at the endpoint is necessary as the shift towards increased use of encrypted transport continues. The lead for contact if interested to develop this further is Nalini Elkins. 4.4.4. Fingerprinting Fingerprinting has been used for numerous applications on the web, including security, and will become of increasing importance with the deployment of stronger encryption. This provides a method to identify traffic without using decryption. The group discussed privacy considerations and balancing how you achieve the security benefits (identifying malicious traffic, information leakage, threat indicators, etc.). They are interested to derive methods to validate the authenticity without identifying the source of traffic. They are also concerned with scaling issues. If interested to work further with this team, the lead contact is: William Weinstein. Moriarty Expires 12 April 2021 [Page 12] Internet-Draft CARIS2 Report October 2020 4.5. Taxonomy and Gaps Session At the start of day 2, Kirsty Paine and Mirjam Kuhne prepared and Kirsty led a workshop style session to discuss taxonomies used in incident response, attacks, and threat detection, comparing solutions and identifying gaps. The primary objective was to determine a path forward selecting language to be used in the proposed SMART group. Several taxonomies were presented for review and discussion. The topic remains open, the following key points were highlighted by participants: * A single taxonomy might not be the way to go, because which taxonomy you use depends on what problem you are trying to solve; e.g. attribution of the attack, mitigation steps, technical features or organizational impact measurements. * A tool to map between taxonomies should be automated as there are requirements within groups or nations to use specific taxonomies. * The level of detail needed for reporting to management and for the analyst investigating the incident can be very different. At the workshop, one attendee mentioned that for management reporting they only use 8 categories to lighten the load on analysts, whereas some of the taxonomies contain 52 categories. * How you plan to use the taxonomy matters and may vary between use cases. Take for instance sharing data with external entities versus internal only. The taxonomy selected depends on what you plan to do with it. Some stated a need for attribute-based dynamic anthologies as opposed to rigid taxonomies used by others. A rigid taxonomy did not work for many from feedback in the session. * [RFC4949] was briefly discussed as a possibility, however there is a clear need to update terminology in this publication around this space in particular. This is likely to be raised in SAAG during open mic, hopefully with proposed new definitions to demonstrate the issue and evolution of terms over time. * Within a taxonomy, prioritization matters to understand the impact of threats or an attack. How do you map that between differing taxonomies? (problem to be solved; possible tooling required) Moriarty Expires 12 April 2021 [Page 13] Internet-Draft CARIS2 Report October 2020 * Attack attribution had varying degrees of interest. Some felt the public sector cared more about attribution; not about individuals, but the possible motivations behind an attack and likely other victims based on these motivations. Understanding if the source was an individual actor, organized crime, or a nation state mattered. The result of this discussion was not to narrow down to one taxonomy, but to think about mappings between taxonomies and the use cases for exchanging or sharing information, eventually giving rise to a common method to discuss threats and attacks. Researchers need a common vocabulary, not necessarily a common taxonomy. 5. Next Steps The next steps from the CARIS2 workshop are twofold. * The research initiatives spawned from the second CARIS require further exploration and development. Fostering this development and creating communities around each proposed project is the first step, with reports back out to the SMART mailing list. * The second initiative will be planning for the next CARIS workshop. 6. Summary Wrapping up the workshop, we reviewed the list of agreed projects to get a feel for actual interest as a follow up. Through the course of the 2-day workshop, a larger set of potential research items had been generated, and this gave participants a chance to reassess commitments to better have them match expected outcomes. The highest ranking projects in terms of interest to drive the ideas forward included the following: * Traffic fingerprinting * SNARC * Attack coordination solutions/automated security * Cryptographic Rendezvous * L2 discovery Moriarty Expires 12 April 2021 [Page 14] Internet-Draft CARIS2 Report October 2020 7. Security Considerations There are no security considerations as this is an informational workshop summary report. 8. IANA Considerations This memo includes no request to IANA. 9. Acknowledgements Thank you to each of the CARIS2 participants who brought their ideas, energy and willingness to collaborate to advance attack response at Internet scale. A big thank you to each member of the program committee for your review of program materials, papers, and guidance on the workshop format: Mat Ford, Internet Society, UK, Jamie Gillespie, APNIC, AU, Chris Inacio, CERT/CC, US, Mirja Kuhlewind, ETH Zurich, CH, Mirjam Kuhne, RIPE NCC, NL, Carlos Martinez, LACNIC, UY, Kathleen M. Moriarty, Dell EMC (Chair), Kirsty Paine, NCSC, UK, and Takeshi Takahashi, NICT, JP. Thank you to Megan Hyland, DellEMC, for her review and guidance on the breakout session format and tools to enable successful collaboration. Thank you to the minute takers, Akashaya Khare and Thinh Nguyen, DellEMC OCTO Cambridge Dojo team. 10. References 10.1. Informative References [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report", RFC 8073, DOI 10.17487/RFC8073, March 2017, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Moriarty Expires 12 April 2021 [Page 15] Internet-Draft CARIS2 Report October 2020 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, . [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, . [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-31, 24 September 2020, . 10.2. URL References [CARISEvent] Internet Society, "CARIS Event Information and Accepted Papers https://www.internetsociety.org/events/caris2", 2019. [I2NSF] IETF, "Interface to Network Security Functions (i2nsf) https://datatracker.ietf.org/wg/i2nsf/about". [defecit] Morgan, S., "Cybersecurity Talent Crunch To Create 3.5 Million Unfilled Jobs Globally By 2021 https://cybersecurityventures.com/jobs/". [MISP] MISP-project.org, "Malware Information Sharing Platform https://www.misp-project.org/", 2019. [SMART] IRTF, "Stopping Malware and Researching Threats https://datatracker.ietf.org/group/smart/about/", 2019. [PlonkaBergerCARIS2] CARIS2, "CARIS2 Paper Submission,", 2019. [PlonkaBergerKIP] Arxiv, "kIP: a Measured Approach to IPv6 Address Anonymization https://arxiv.org/abs/1707.03900", 2017. Author's Address Moriarty Expires 12 April 2021 [Page 16] Internet-Draft CARIS2 Report October 2020 Kathleen M Moriarty Dell Technologies 176 South Street Hopkinton, MA 01748 United States Email: kathleen.moriarty.ietf@gmail.com Moriarty Expires 12 April 2021 [Page 17] ./draft-nottingham-how-did-that-get-into-the-repo-02.txt0000644000764400076440000002510113743157111022333 0ustar iustyiusty Network Working Group M. Nottingham Internet-Draft 19 October 2020 Intended status: Informational Expires: 22 April 2021 The secret-token URI Scheme draft-nottingham-how-did-that-get-into-the-repo-02 Abstract This document registers the "secret-token" URI scheme, to aid in the identification of authentication tokens. Note to Readers _RFC EDITOR: please remove this section before publication_ The issues list for this draft can be found at https://github.com/mnot/I-D/labels/how-did-that-get-into-the-repo (https://github.com/mnot/I-D/labels/how-did-that-get-into-the-repo). The most recent (often, unpublished) draft is at https://mnot.github.io/I-D/how-did-that-get-into-the-repo/ (https://mnot.github.io/I-D/how-did-that-get-into-the-repo/). Recent changes are listed at https://github.com/mnot/I-D/commits/gh- pages/how-did-that-get-into-the-repo (https://github.com/mnot/I- D/commits/gh-pages/how-did-that-get-into-the-repo). See also the draft's current status in the IETF datatracker, at https://datatracker.ietf.org/doc/draft-nottingham-how-did-that-get- into-the-repo/ (https://datatracker.ietf.org/doc/draft-nottingham- how-did-that-get-into-the-repo/). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Nottingham Expires 22 April 2021 [Page 1] Internet-Draft The secret-token URI Scheme October 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 April 2021. Copyright Notice Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. The secret-token URI scheme . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction It has become increasingly common to use bearer tokens as an authentication mechanism in various protocols. A bearer token is a security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession). Unfortunately, the number of security incidents involving accidental disclosure of these tokens has also increased. For example, we now regularly hear about a developer committing an access token to a Nottingham Expires 22 April 2021 [Page 2] Internet-Draft The secret-token URI Scheme October 2020 public source code repository, either because they didn't realise it was included in the committed code, or because they didn't realise the implications of its disclosure. This specification registers the "secret-token" URI scheme to aid prevention of such accidental disclosures. When tokens are easier to unambiguously identify, they can trigger warnings in Continuous Integration systems, or be used in source code repositories themselves. They can also be scanned for separately. For example, if cloud.example.net issues access tokens to its clients for later use, and it does so by formatting them as secret-token URIs, tokens that "leak" into places that they don't belong are easier to identify. This could be through a variety of mechanisms; for example, if repo.example.com can be configured to refuse commits containing secret-token URIs, it helps its customers avoid accidental disclosures. secret-token URIs are intended to aid in identification of generated secrets like API keys and similar tokens. They are not intended for use in controlled situations where ephemeral tokens are used, such as things like Cross-Site Request Forgery (CSRF) tokens. 1.1. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses ABNF [RFC5234]. It also uses the pchar rule from [RFC3986]. 2. The secret-token URI scheme The secret-token URI scheme identifies a token that is intended to be a secret. secret-token-URI = secret-token-scheme ":" token secret-token-scheme = "secret-token" token = 1*pchar See [RFC3986], Section 3.3 for a definition of pchar. Disallowed characters - including non-ASCII characters - MUST be encoded into UTF-8 [RFC3629] and then percent-encoded ([RFC3986], Section 2.1). Nottingham Expires 22 April 2021 [Page 3] Internet-Draft The secret-token URI Scheme October 2020 When a token is both generated and presented for authentication, the entire URI MUST be used, without changes. For example, given the URI: secret-token:E92FB7EB-D882-47A4-A265-A0B6135DC842%20foo This string (character-for-character, case-sensitive) will both be issued by the token authority, and required for later access. Therefore, if the example above were used as a bearer token in [RFC6750], a client might send: GET /authenticated/stuff HTTP/1.1 Host: www.example.com Authorization: Bearer secret-token:E92FB7EB-D882-47A4-A265-A0B6135DC842%20foo 3. IANA Considerations This document registers the following value in the URI Scheme registry: * Scheme name: secret-token * Status: provisional * Applications / protocols that use this scheme: none yet * Contact: iesg@iesg.org * Change Controller: IESG * References: (this document) 4. Security Considerations The token ABNF rule allows tokens as small as one character. This is not recommended practice; applications should evaluate their requirements for entropy and issue tokens correspondingly. See [RFC4086] for more information. This URI scheme is intended to reduce the incidence of accidental disclosure; it cannot prevent intentional disclosure. Nottingham Expires 22 April 2021 [Page 4] Internet-Draft The secret-token URI Scheme October 2020 If it is difficult to correctly handle secret material, or unclear as to what the appropriate handling is, users might choose to obfuscate their secret tokens in order to evade detection (for example, removing the URI scheme for storage). Mitigating this risk is often beyond the reach of the system using the secret-token URI, but they can caution users against such practices, and provide tools to help. 5. References 5.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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 5.2. Informative References [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . Nottingham Expires 22 April 2021 [Page 5] Internet-Draft The secret-token URI Scheme October 2020 Appendix A. Acknowledgements The definition of bearer tokens is from [RFC6750]. Author's Address Mark Nottingham Prahran VIC Australia Email: mnot@mnot.net URI: https://www.mnot.net/ Nottingham Expires 22 April 2021 [Page 6] ./draft-ribose-asciirfc-08.txt0000644000764400076440000106050113265536533015515 0ustar iustyiusty Network Working Group R. Tse Internet-Draft N. Nicholas Intended status: Informational J. Lau Expires: October 20, 2018 P. Brasolin Ribose April 18, 2018 AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc draft-ribose-asciirfc-08 Abstract This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 20, 2018. Tse, et al. Expires October 20, 2018 [Page 1] Internet-Draft AsciiRFC Specifications April 2018 Copyright Notice Copyright (c) 2018 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 (https://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Designed for authoring RFCs and Internet-Drafts . . . . . 3 1.2. Relationship between AsciiRFC, AsciiDoc and Asciidoctor . 4 1.3. Comparison with RFC XML tools based on Markdown variants 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 6 2.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 6 2.2. Wrapping Lines in Documentation Examples . . . . . . . . 6 3. Document Structure and Syntax . . . . . . . . . . . . . . . . 7 3.1. Unsupported features compared with Asciidoctor syntax . . 8 3.2. Mapping To RFC XML syntax . . . . . . . . . . . . . . . . 8 3.3. Example Illustrations . . . . . . . . . . . . . . . . . . 9 3.4. Simple Illustration . . . . . . . . . . . . . . . . . . . 10 4. Header And Document Attributes . . . . . . . . . . . . . . . 28 4.1. Title And Basic Attributes . . . . . . . . . . . . . . . 28 4.2. Detailed Author Information . . . . . . . . . . . . . . . 30 4.3. XML Processing Information . . . . . . . . . . . . . . . 34 4.4. AsciiRFC-specific Document Attributes . . . . . . . . . . 35 5. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6. Sections and Paragraphs . . . . . . . . . . . . . . . . . . . 39 7. Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.1. Basic Lists . . . . . . . . . . . . . . . . . . . . . . . 47 8.2. List Continuation . . . . . . . . . . . . . . . . . . . . 52 9. Blockquotes . . . . . . . . . . . . . . . . . . . . . . . . . 55 10. Notes And Asides . . . . . . . . . . . . . . . . . . . . . . 56 11. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 12. Inline Formatting . . . . . . . . . . . . . . . . . . . . . . 62 12.1. Italics, Boldface, Monospace, Subscripts, Superscripts . 62 12.2. Formatting BCP 14 Keywords . . . . . . . . . . . . . . . 63 12.3. Escaping AsciiRFC Syntax . . . . . . . . . . . . . . . . 64 13. Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 14. Cross-References . . . . . . . . . . . . . . . . . . . . . . 66 14.1. Basic Referencing . . . . . . . . . . . . . . . . . . . 66 14.2. Referencing With Attributes . . . . . . . . . . . . . . 67 Tse, et al. Expires October 20, 2018 [Page 2] Internet-Draft AsciiRFC Specifications April 2018 14.3. Indexing . . . . . . . . . . . . . . . . . . . . . . . . 68 15. Inclusions . . . . . . . . . . . . . . . . . . . . . . . . . 69 16. Encoding and Entities . . . . . . . . . . . . . . . . . . . . 70 17. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 72 17.1. Using Raw RFC XML . . . . . . . . . . . . . . . . . . . 72 17.2. Preprocessing Using "asciidoctor-bibliography" . . . . . 77 18. RFC XML features not supported in Asciidoctor . . . . . . . . 79 19. Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . 79 19.1. Using the "rfc-asciirfc-minimal" template . . . . . . . 80 19.2. Installing AsciiRFC Backend Processors . . . . . . . . . 80 19.3. Iterating AsciiRFC Content . . . . . . . . . . . . . . . 80 20. Security Considerations . . . . . . . . . . . . . . . . . . . 81 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 22.1. Normative References . . . . . . . . . . . . . . . . . . 81 22.2. Informative References . . . . . . . . . . . . . . . . . 81 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 85 A.1. Example 1: "A Minimal Internet-Draft In AsciiRFC" . . . . 85 A.1.1. In AsciiRFC . . . . . . . . . . . . . . . . . . . . . 85 A.1.2. Rendered as RFC XML v3 . . . . . . . . . . . . . . . 93 A.2. Example 2: "The Holy Hand Grenade of Antioch" . . . . . . 98 A.2.1. In AsciiRFC . . . . . . . . . . . . . . . . . . . . . 98 A.2.2. Rendered as RFC XML v3 . . . . . . . . . . . . . . . 115 A.3. Example 3: "An API For Calendar-Based Fortune Heuristics Services" in AsciiRFC . . . . . . . . . . . . . . . . . . 133 A.3.1. In AsciiRFC . . . . . . . . . . . . . . . . . . . . . 134 A.4. Rendered as RFC XML v3 . . . . . . . . . . . . . . . . . 153 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 170 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 170 1. Introduction This document describes a markup language called "AsciiRFC", developed specifically for the purpose of generating RFC XML document, based on Asciidoctor syntax. AsciiRFC can be used to generate compliant RFC XML v2 and v3 documents through the usage of an open source, MIT-licensed Ruby gem called "asciidoctor-rfc" written by the authors [asciidoctor-rfc]. 1.1. Designed for authoring RFCs and Internet-Drafts Internet-Drafts and RFCs intended for publication submission to the IETF can be written in a multitude of formats today, including: o XML: RFC XML v2 [RFC7749] and v3 [RFC7991] o nroff: through [NroffEdit] Tse, et al. Expires October 20, 2018 [Page 3] Internet-Draft AsciiRFC Specifications April 2018 o Microsoft Word: through usage of [RFC5385] o Lyx: through [lyx2rfc] o Pandoc: [RFC7328], through [pandoc2rfc] or [draftr] o Kramdown: through [kramdown-rfc2629] o mmark: through [mmark] Interestingly, the last three are Markdown [RFC7763] variants. As specified in [RFC7990], the IETF intends for the canonical format of RFCs to transition from plain-text ASCII to RFC XML v3 [RFC7991]. While plain-text will continue to be accepted from authors by the IETF, at least in the short- to medium-term, XML will be preferred for submission, and any plain-text submissions will need to be converted to RFC XML v3. While this need is already met for RFC XML v2 [RFC7749] by the tools specified above, the transition to RFC XML v3 [RFC7991] places added onus on authors to generate compliant XML. 1.2. Relationship between AsciiRFC, AsciiDoc and Asciidoctor [AsciiDoc] is a lightweight markup language and an alternative to Markdown, with features that make it attractive as a markup language for RFC with XML output. [Asciidoctor] is an open source, MIT-licensed Ruby implementation of [AsciiDoc] that provides an enhancement of the original AsciiDoc markup language. The variant of AsciiDoc syntax accepted by [Asciidoctor] is hereafter called "Asciidoctor syntax". AsciiRFC, as described in this document, is an AsciiDoc variant developed on Asciidoctor syntax, created for the purpose of generating RFC XML documents. 1.3. Comparison with RFC XML tools based on Markdown variants Section 1.2 of [RFC7764] famously states that "there is no such thing as 'invalid' Markdown, there is no standard demanding adherence to the Markdown syntax, and there is no governing body that guides or impedes its development." While there are contexts where that flexibility is useful, the authoring of RFCs does have a standard and a governing body, and there is such a thing as invalid RFC XML. A Tse, et al. Expires October 20, 2018 [Page 4] Internet-Draft AsciiRFC Specifications April 2018 more rigorous and extensible counterpart to Markdown, which still preserves its basic approach to formatting, can generate RFC XML that encompasses a fuller subset of the specification, and preempts malformed RFC XML output. The proposed markup language and associated Ruby gem has several advantages that we believe make it worth considering as an approach to generating RFC XML. o AsciiDoc was designed from the beginning as a publishing language: it was initially intended as a plain-text alternative to the DocBook XML schema. For that reason, Asciidoctor natively supports the full range of formatting required by RFC XML (including notes, tables, bibliographies, source-code blocks, and definition lists), without resorting to embedded HTML or Markdown "flavours". o AsciiRFC covers the full range of elements in RFC XML v2 and RFC XML v3. o AsciiDoc in its Ruby-based Asciidoctor implementation is extensible, with a well-defined API. (Extensions have been harnessed to deal with bibliographic preprocessing for AsciiRFC.) o AsciiRFC allows granular control of rendering, including user- specified attributes of text blocks. o The Asciidoctor implementation allows document inclusion, for managing large-scale documentation projects. o AsciiRFC allows granular control of permutations of block nesting, such as source code within lists or definition lists within unordered lists. o As a more formal counterpart to Markdown, AsciiDoc is well-suited to generating XML that needs to conform to a specified schema. The asciidoctor-rfc Ruby gem developed around AsciiDoc validates its RFC XML output against the RelaxNG schema defined for RFC XML, and reports any issues to the end user. o The asciidoctor-rfc Ruby gem incorporates validation not only of the XML structure of the standard, but also of the IETF workgroups it mentions against the latest listing online, and the bibliographic entries for RFC and other standards registered on . The gem also dynamically fetches bibliographic entries from the xml2rfc site, and uses them to populate the RFC XML document. As with Markdown, there is a wide range of tools that can render AsciiDoc; so AsciiRFC drafts of RFC documents can be previewed and Tse, et al. Expires October 20, 2018 [Page 5] Internet-Draft AsciiRFC Specifications April 2018 accessed without depending on the RFC tools ecosystem. Our realisation of RFC XML in AsciiRFC has aimed to ensure that, as much as possible, the markup language can be can be processed by generic Asciidoctor tools. The only exception to this as an add-on is the optional bibliography module, which allows bibliographies to be assembled on the fly based on citations in a document: see Section 17.2. 2. Conventions Used in This Document 2.1. Terms and Definitions The following terms and definitions apply to this document: AsciiDoc The AsciiDoc markup language generically, as described in [AsciiDoc]. Asciidoctor syntax The enhanced AsciiDoc syntax implemented by the [Asciidoctor] Ruby gem. AsciiRFC The AsciiDoc syntax developed for the purpose of generating RFC XML document based on Asciidoctor syntax, as described in this document. 2.2. Wrapping Lines in Documentation Examples This document contains a number of examples as fragments of XML. In some cases, the examples contain URLs that are over 72 characters long and so need to be wrapped for presentation in this document even though they would not need to be wrapped in the actual source XML. This document adopts a policy similar to that described in [I-D.wu-netmod-yang-xml-doc-conventions] to denote line wraps. When an XML example contains a URL, that URL is always included in double- quotes. If the URL would extend beyond 72 characters, the line is wrapped and the wrap is indicated with a backslash ("\"). The backslash appears without any additional space before the backslash and with no further characters after the backslash. For example, the following XML... Tse, et al. Expires October 20, 2018 [Page 6] Internet-Draft AsciiRFC Specifications April 2018 ...may be presented as 3. Document Structure and Syntax AsciiRFC consists of a subset of Asciidoctor syntax with the addition of bibliographic macros (Section 17.2). Asciidoctor syntax is presented in the Asciidoctor user manual [Asciidoctor-Manual]. AsciiRFC syntax consists of: o A document header, containing a title, a list of authors, and document attributes in lines prefixed with ":". o An optional document preamble, separated from the document header by a blank line, and not containing any section titles. o A number of sections, set off by a section title (a line prefixed with two or more "=".) A section may contain: o Other sections, whose level of nesting is indicated by the number of "=" in their header. o Blocks of text. Blocks can have metadata (including a title, an anchor for cross-references, and attributes.) Blocks can be: o Paragraphs, which are terminated by blank lines. o Lists. List items are by default paragraphs, but can span over multiple paragraphs. o Delimited blocks (with a line delimiter on either side of them); these include tables, notes, sidebars, source code, block quotes, examples, and unprocessed content (e.g. raw XML). Delimited blocks contain by default one or more paragraphs. o List items can contain other blocks, including both nested lists and delimited blocks. Tse, et al. Expires October 20, 2018 [Page 7] Internet-Draft AsciiRFC Specifications April 2018 o Some delimited blocks can contain other delimited blocks; for example, examples can contain source code as well as discussion in paragraphs. o Blocks of text consist of inline text, which itself can contain markup. Inline markup includes: o Text formatting: Bold, italic, superscript, subscript, monospace. o Markup macros: the "bcp14" and "comment" macros. (Asciidoctor syntax supports custom markup macros.) o URLs, including display text to render. o Inline anchors. o Cross-references to anchors (IDs of blocks or spans of text), including display text to render. o Images: SVG only, as specified in [RFC7996]. o Index terms. 3.1. Unsupported features compared with Asciidoctor syntax Several features from Asciidoctor are not supported within AsciiRFC due to the lack of support within RFC XML, including: o Audio and video files are not supported in AsciiRFC as today's RFC XML structure does not support audio or video. o Equations are not supported as there is no current RFC XML equivalent. Asciidoctor provides native support for [AsciiMathML] and [TeX-LaTeX], via the [MathJax] tool. o Footnotes are not supported in AsciiRFC as there is no equivalent semantic representation in RFC XML. These carved out features can be easily supported by AsciiRFC once RFC XML allows these elements. 3.2. Mapping To RFC XML syntax The Asciidoctor syntax document structure aligns with both the RFC XML v2 and the RFC XML v3 structure. In the following, RFC XML v3 equivalences are given to the basic Asciidoctor structure. Tse, et al. Expires October 20, 2018 [Page 8] Internet-Draft AsciiRFC Specifications April 2018 Header "" attributes, most "front" elements. Preamble "front/abstract" and "front/note". Sections "middle/section" elements. Sections with bibliography style attribute "back/references" elements. Sections with appendix style attribute "back/section" elements. Paragraphs "t" elements. Lists "ul", "ol", "dl" elements. Delimited blocks "artwork", "aside", "blockquote", "figure", "note", "sourcecode", "table". Inline markup "bcp14", "br", "cref", "em", "eref", "iref", "relref", "strong", "sub", "sup", "tt", "xref". Full details of the mapping of AsciiRFC elements to RFC XML v2 and v3 elements, and of how to convert AsciiRFC documents to RFC XML, are given in the documentation of [asciidoctor-rfc]. 3.3. Example Illustrations This document utilizes example documents provided in Appendix A for demonstration of AsciiRFC syntax and usage. The source files and published versions (at the IETF Datatracker) of these example documents are available in Appendix A. o "A Minimal Internet-Draft In AsciiRFC" Appendix A.1.1 o "The Holy Hand Grenade of Antioch" Appendix A.2.1 o "An API For Calendar-Based Fortune Heuristics Services" Appendix A.3.1 Tse, et al. Expires October 20, 2018 [Page 9] Internet-Draft AsciiRFC Specifications April 2018 3.4. Simple Illustration This section gives an overview of how to create an RFC XML document in AsciiRFC, with some pitfalls to be aware of. Illustrations are in RFC XML v3 and RFC XML v2. A sample AsciiRFC document is provided in Figure 1, together with its corresponding rendering in: o RFC XML v3 (Figure 2) o RFC XML v2 (Figure 3) = A Minimal Internet-Draft In AsciiRFC :doctype: internet-draft :name: draft-asciirfc-minimal-02 :abbrev: AsciiRFC Example :status: informational :ipr: trust200902 :submissionType: individual :area: Internet :intended-series: full-standard :revdate: 2018-04-12T00:00:00Z :fullname: Josiah Stinkney Carberry :lastname: Carberry :forename_initials: J. S. :organization: Brown University :phone: +1 401 863 1000 :street: Box K, 69 Brown Street :city: Providence :code: 02912 :country: United States of America :uri: https://www.brown.edu :email: josiah.carberry@ribose.com :fullname_2: Truman Grayson :lastname_2: Grayson :forename_initials_2: T. :organization_2: Brown University :phone_2: +1 401 863 1000 :street_2: Box G, 69 Brown Street :city_2: Providence :code_2: 02912 :country_2: United States of America :uri_2: https://www.brown.edu :email_2: truman.grayson@ribose.com Tse, et al. Expires October 20, 2018 [Page 10] Internet-Draft AsciiRFC Specifications April 2018 [abstract] This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the `asciidoctor-rfc` Ruby gem. [#introduction] == Introduction AsciiRFC <> is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to <>. This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to <> and submittable to the IETF datatracker. [#conventions] == Terms and Definitions The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions: AsciiRFC:: an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in <>. [#symbols] == Symbols And Abbreviations ADRFC:: abbreviated form of AsciiRFC [#security] == Security Considerations Any security considerations should be placed here. As described in <
> (here's how you refer a local anchor), Tse, et al. Expires October 20, 2018 [Page 11] Internet-Draft AsciiRFC Specifications April 2018 local tools have to be installed before the document template can be built. Running of these local tools *MAY* produce unintended side effects that impact security. [#iana] == IANA Considerations This document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here. [bibliography] == Normative References //bibliography::norm[] ++++ Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Tse, et al. Expires October 20, 2018 [Page 12] Internet-Draft AsciiRFC Specifications April 2018 The "xml2rfc" Version 3 Vocabulary This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ++++ [bibliography] == Informative References //bibliography::info[] ++++ IETF Trust Legal Provisions (TLP) IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc Tse, et al. Expires October 20, 2018 [Page 14] Internet-Draft AsciiRFC Specifications April 2018 This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. Rights Contributors Provide to the IETF Trust The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Tse, et al. Expires October 20, 2018 [Page 15] Internet-Draft AsciiRFC Specifications April 2018 The OCB Authenticated-Encryption Algorithm This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG). ++++ [appendix] [#appendix-a] == Examples === Example 1 Here's an example of a properly wrapped code snippet in accordance with rules specified in <>. [source,json] ---- { "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ---- Tse, et al. Expires October 20, 2018 [Page 16] Internet-Draft AsciiRFC Specifications April 2018 [#acknowledgements] == Acknowledgements The authors would like to thank their families. Figure 1: Sample Internet-Draft in AsciiRFC The first block of text, from "= Template For Writing An Internet- Draft In AsciiRFC" through to ":email_2: thomas.kandell@brown.edu", is the document header. It contains a title in the first line, an author attribution ("Josiah Carberry; Thomas Kandell"), and then a set of document attributes, conveying information about the document as well as information about its authors. This information ends up in RFC XML either as attributes of the root "rfc" tag, elements of the "front" tag, or processing instructions. The following blocks of text, up until the first section header ("== Introduction"), are the document preamble. They are treated by the document converter as containing the document abstract ("abstract"), followed by any notes if present. Section headers delimit the sections of the main body of the document, starting with "== Introduction". The document converter treats the first section of the document as the start of the "middle" section in RFC XML. The first section header is followed by a paragraph, and other sections and paragraphs. The number of "=" signs can be one higher than that of the preceding section header, which indicates that they are subsections of that section; so "=== Operators" is a subsection of the preceding "== Symbols And Abbreviations". The paragraphs contain some inline formatting (e.g. boldface: "*MUST*", monospace: "`type`"), and sections can also contain blocks other than normal paragraphs; the section "== Operators", for example, contains a definition list (whose terms are delimited by "::"), and the subsection "=== Example 1" contains a code snippet (delimited by "----", and tagged with the style attribute "[source,json]", indicating that this is a JSON sourcecode listing). The document can also include comments ("//" for inline, "////" for blocks), which are not rendered when the document is processed. The introductory section in this example contains a citation of a reference, which in this version of AsciiRFC is treated identically to a cross-reference ("<>") -- the crossreference being to the references section of the document. Sections and blocks of texts within the document can also be the target of crossreferences; for example, the section header "=== Operators" is preceded by the anchor Tse, et al. Expires October 20, 2018 [Page 17] Internet-Draft AsciiRFC Specifications April 2018 "[#operators]", and that anchor is already referenced in the section "== Security Considerations". The third last and second last section are tagged with the style attribute "[bibliography]", which identifies them as references containers; the document converter accordingly inserts them into the "back" element under RFC XML. The contents of the references sections are in this instance raw XML, delimited as a passthrough block (with "++++"), which the converter does not alter. The final section is tagged with the style attribute "[appendix]", and is treated as such. The RFC XML v3 document generated from this AsciiRFC document is: A Minimal Internet-Draft In AsciiRFC Brown University
Box K, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 josiah.carberry@ribose.com https://www.brown.edu Tse, et al. Expires October 20, 2018 [Page 18] Internet-Draft AsciiRFC Specifications April 2018
Brown University
Box G, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 truman.grayson@ribose.com https://www.brown.edu
Internet This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the asciidoctor-rfc Ruby gem.
IntroductionAsciiRFC is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to . This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to and submittable to the IETF datatracker.
Terms and DefinitionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions:
Tse, et al. Expires October 20, 2018 [Page 19] Internet-Draft AsciiRFC Specifications April 2018
AsciiRFC
an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in .
Symbols And Abbreviations
ADRFC
abbreviated form of AsciiRFC
Main contentThis is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes.
Getting startedThe AsciiRFC and RFC toolchains MUST be available locally to build this document template.
AsciiRFC toolchainYou will need to have:
  • Ruby: for running the AsciiRFC toolchain
  • asciidoctor-rfc gem: for converting AsciiRFC into XML RFC (v2 or v3)
XML RFC toolchainYou will need to have:
  • Python: for running xml2rfc
  • xml2rfc: for converting RFC XML (v2 or v3) into TXT
  • idnits: for submission preflight
Referencing external content
  • This is a published RFC
  • This is an Internet-Draft
  • This is an external reference
Code snippets Code snippets should be wrapped with <CODE BEGINS> and Tse, et al. Expires October 20, 2018 [Page 20] Internet-Draft AsciiRFC Specifications April 2018 <CODE ENDS> blocks, as required by the IETF Trust Legal Provisions (TLP) specified in .
Security ConsiderationsAny security considerations should be placed here. As described in (here’s how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools MAY produce unintended side effects that impact security.
IANA ConsiderationsThis document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here.
Normative References Informative References IETF Trust Legal Provisions (TLP) IETF Tse, et al. Expires October 20, 2018 [Page 21] Internet-Draft AsciiRFC Specifications April 2018 RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
Examples
Example 1Here’s an example of a properly wrapped code snippet in accordance with rules specified in .
{ "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ]]> Tse, et al. Expires October 20, 2018 [Page 22] Internet-Draft AsciiRFC Specifications April 2018
Acknowledgements The authors would like to thank their families.
Figure 2: Sample Internet-Draft In AsciiRFC, Output In RFC XML v3 Format Some default processing instructions have already been prefixed to the XML. Our AsciiRFC converter can also generate RFC XML v2 from the same source AsciiRFC, as shown in Figure 3. Output in RFC XML v2 is not extensively described in this document. ]> Tse, et al. Expires October 20, 2018 [Page 23] Internet-Draft AsciiRFC Specifications April 2018 A Minimal Internet-Draft In AsciiRFC Brown University
Box K, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 josiah.carberry@ribose.com https://www.brown.edu
Brown University
Box G, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 truman.grayson@ribose.com https://www.brown.edu
Internet This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the asciidoctor-rfc Ruby gem.
AsciiRFC is an extremely simple way to author Internet-Drafts and RFCs without needing to manually Tse, et al. Expires October 20, 2018 [Page 24] Internet-Draft AsciiRFC Specifications April 2018 craft RFC XML conforming to . This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to and submittable to the IETF datatracker.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions: an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in .
abbreviated form of AsciiRFC
This is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes.
The AsciiRFC and RFC toolchains MUST be available locally to build this document template.
You will need to have: Tse, et al. Expires October 20, 2018 [Page 25] Internet-Draft AsciiRFC Specifications April 2018 Ruby: for running the AsciiRFC toolchain asciidoctor-rfc gem: for converting AsciiRFC into XML RFC (v2 or v3)
You will need to have: Python: for running xml2rfc xml2rfc: for converting RFC XML (v2 or v3) into TXT idnits: for submission preflight
This is a published RFC This is an Internet-Draft This is an external reference
Code snippets should be wrapped with <CODE BEGINS> and <CODE ENDS> blocks, as required by the IETF Trust Legal Provisions (TLP) specified in .
Any security considerations should be placed here. As described in (here’s how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools MAY produce unintended side effects that impact security.
This document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, Tse, et al. Expires October 20, 2018 [Page 26] Internet-Draft AsciiRFC Specifications April 2018 please include them here.
&RFC2119; &RFC7991; &RFC8174; IETF Trust Legal Provisions (TLP) IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
&I-D.ribose-asciirfc; &RFC5378; &RFC7253;
Here’s an example of a properly wrapped code snippet in accordance with rules specified in .
Tse, et al. Expires October 20, 2018 [Page 27] Internet-Draft AsciiRFC Specifications April 2018 { "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ]]>
The authors would like to thank their families.
Figure 3: Sample Internet-Draft In AsciiRFC, Output In RFC XML v2 Format 4. Header And Document Attributes The header gives the document title, followed by an optional author attribution, and a series of document attributes, with no empty lines. 4.1. Title And Basic Attributes Document attributes are used to populate attributes of the root "rfc" element, "front" elements, and document-level processing instructions. o ":doctype:" determines whether the document will be considered "rfc" or "internet-draft", and interprets other attributes accordingly. o Certain attributes ("workgroup", "area", "keyword") are comma delimited, and result in repeated RFC XML elements. Figure 4 demonstrates how to set the document header in AsciiRFC, with its rendering in RFC XML v3 shown in Figure 5. Tse, et al. Expires October 20, 2018 [Page 28] Internet-Draft AsciiRFC Specifications April 2018 = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :area: General, Operations and Management :keyword: rabbits, grenades, antioch, camelot :ipr: trust200902 :toc-include: true :sort-refs: true :revdate: 2018-04-15T00:00:00Z Figure 4: AsciiRFC Document Header The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot grenades camelot Figure 5: AsciiRFC Document Header Rendered As RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 29] Internet-Draft AsciiRFC Specifications April 2018 4.2. Detailed Author Information The document header can spell out further information about authors, including contact details. The AsciiRFC header is shown in Figure 6 with its rendering in RFC XML v3 shown in Figure 7. = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :area: General, Operations and Management :keyword: rabbits, grenades, antioch, camelot :ipr: trust200902 :toc-include: true :sort-refs: true :revdate: 2018-04-15T00:00:00Z :fullname: Arthur son of Uther Pendragon :forename_initials: A. :lastname: Pendragon :email: arthur.pendragon@ribose.com :organization: Camelot :uri: http://camelot.gov.example :street: Palace\ Camel Lot 1 :city: Camelot :region: England :country: United Kingdom Figure 6: AsciiRFC Document Header With One Author Tse, et al. Expires October 20, 2018 [Page 30] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot England United Kingdom arthur.pendragon@ribose.com http://camelot.gov.example
General Operations and Management rabbits grenades antioch camelot Figure 7: AsciiRFC Document Header With One Author (RFC XML v3) Details of a second, third etc. author, including their organization and contact details, are provided by suffixing the relevant author attributes with "_2", "_3" etc., as shown in Figure 8 and its RFC XML v3 rendering Figure 9. Tse, et al. Expires October 20, 2018 [Page 31] Internet-Draft AsciiRFC Specifications April 2018 = An API For Calendar-Based Fortune Heuristics Services Gabriel Destiny; Charise Luck :doctype: internet-draft :abbrev: Calendar Fortune Heuristics API :name: draft-divination-cfapi-00 :status: informational :ipr: trust200902 :area: Internet :submission-type: independent :intended-series: informational :revdate: 2018-03-23T00:00:00Z :lastname: Destiny :fullname: Gabriel Destiny :forename_initials: G. :organization: Divination Inc. :email: gabriel.destiny@ribose.com :street: 9288 N Divine Street :city: Dunn :code: 28334 :region: NC :country: United States of America :lastname_2: Luck :fullname_2: Charise Luck :forename_initials_2: C. :organization_2: Divination Inc. :email_2: charise.luck@ribose.com :street_2: 9288 N Divine Street :city_2: Dunn :code_2: 28334 :region_2: NC :country_2: United States of America Figure 8 Tse, et al. Expires October 20, 2018 [Page 32] Internet-Draft AsciiRFC Specifications April 2018 An API For Calendar-Based Fortune Heuristics Services Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America gabriel.destiny@ribose.com
Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America charise.luck@ribose.com
Internet Figure 9: AsciiRFC Document Header With Multiple Authors (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 33] Internet-Draft AsciiRFC Specifications April 2018 The initial author attribution in AsciiRFC, e.g. "Gabriel Destiny; Charlise Luck" in the example above, expects a strict format of First Name, zero or more Middle Names, Last name, and cannot process honorifics like "Dr." or suffixes like "Jr.". Name attributes with any degree of complexity should be overriden by using the ":fullname:" and ":lastname:" attributes. The AsciiRFC ":forename_initials:" attribute replaces the built-in Asciidoctor syntax ":initials:" attribute (which includes the surname initial), and is not automatically populated from the name attribution. 4.3. XML Processing Information A document header may also contain attribute headers which are treated as XML processing instructions. An AsciiRFC example is shown in Figure 10 with its rendering in Figure 11. (Note that several processing instructions are included by default in the output of the AsciiRFC processor.) = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :ipr: trust200902 :comments: yes :notedraftinprogress: yes Figure 10: AsciiRFC Document Header With XML Processing Information Tse, et al. Expires October 20, 2018 [Page 34] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot grenades Figure 11: AsciiRFC Document Header With XML Processing Information (RFC XML v3) In the foregoing, values for the processing instructions "strict", "compact", "toc" etc are included by default; but "comments" and "notedraftinprogress" are included as specified in the AsciiRFC document header. The default values provided for processing instructions can in fact be overriden through the AsciiRFC document header. 4.4. AsciiRFC-specific Document Attributes A few document attributes are specific to the operation of the RFC XML document converter: Tse, et al. Expires October 20, 2018 [Page 35] Internet-Draft AsciiRFC Specifications April 2018 :no-rfc-bold-bcp14: false overrides the wrapping by default of boldface uppercase BCP14 [RFC2119] words (e.g. "*MUST NOT*") with the "bcp14" element. :smart-quotes: false overrides Asciidoctor's conversion of straight quotes and apostrophes to smart quotes and apostrophes. :inline-definition-lists: true overrides the RFC XML v2 "idnits" requirement that a blank line be inserted between a definition list term and its definition. = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :status: informational :name: draft-camelot-holy-grenade-00 == Section 1 The specification *MUST NOT* use the word _doesn't_. Figure 12: AsciiRFC Document Header Without RFC-specific Attributes Tse, et al. Expires October 20, 2018 [Page 36] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch
Section 1 The specification MUST NOT use the word doesn’t.
Figure 13: AsciiRFC Document Header Without RFC-specific Attributes (RFC XML v3) = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :status: informational :name: draft-camelot-holy-grenade-00 :no-rfc-bold-bcp14: false :smart-quotes: false == Section 1 The specification *MUST NOT* use the word _doesn't_. Figure 14: AsciiRFC Document Header With Overridden RFC-specific Attributes Tse, et al. Expires October 20, 2018 [Page 37] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch
Section 1 The specification MUST NOT use the word doesn't.
Figure 15: AsciiRFC Document Header With Overridden RFC-specific Attributes (RFC XML v3) 5. Preamble The preamble in AsciiRFC is the text between the end of the document header (which terminates with a blank line) and the first section of text. Any paragraphs of text in the preamble are treated as an abstract, and may optionally be tagged with the "abstract" style attribute. Any notes in the preamble are treated as a "note" element. An example of setting the preamble is given in Figure 16 with its rendering in Figure 17. Tse, et al. Expires October 20, 2018 [Page 38] Internet-Draft AsciiRFC Specifications April 2018 [abstract] The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. [NOTE,remove-in-rfc=false] .Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635. Figure 16: AsciiRFC With Preamble The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635. Figure 17: AsciiRFC With Preamble (RFC XML v3) 6. Sections and Paragraphs Section headers are given with a sequence of "=", where the number of instances of "=" gives the header level. The document itself opens Tse, et al. Expires October 20, 2018 [Page 39] Internet-Draft AsciiRFC Specifications April 2018 with a single "=", and sections within it must be started with a minimum of "==". Section numbering is toggled with the in-document attribute ":sectnums:" (on), ":sectnums!:" (off). The boolean "toc" attribute can also be set on sections, indicating whether the section can be included in the document's table of contents. Figure 18 shows how sections and paragraphs are used in AsciiRFC, and its rendered form is shown in Figure 19. [toc=exclude] :sectnums!: == Terminology The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. :sectnums: == Introduction <> refers to the intended move of RFC formatting to XML2RFC v3 <>, in the following terms: Figure 18: AsciiRFC With Sections Tse, et al. Expires October 20, 2018 [Page 40] Internet-Draft AsciiRFC Specifications April 2018
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Introduction refers to the intended move of RFC formatting to XML2RFC v3 , in the following terms: Figure 19: AsciiRFC With Sections (RFC XML v3) Note that skipped sections, such as defining a section using "====" within a section defined using "==", is not allowed in AsciiRFC syntax. Doing so will trigger an error with the following message: asciidoctor: WARNING: _filename_: line _X_: section title out of sequence: expected level 2, got level 3 7. Figures AsciiRFC examples (corresponding to RFC XML Figures), source code Listings, and Literals (preformatted text) are all delimited blocks. Listings and Literals can occur nested within Examples. An AsciiRFC example with a figure is given in Figure 20, and its rendering in Figure 21. [[killer-bunny]] .A Photo Of The Killer Rabbit of Caerbannog Taken In Secret ==== [alt=The Killer Bunny, in ASCII] .... \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Tse, et al. Expires October 20, 2018 [Page 41] Internet-Draft AsciiRFC Specifications April 2018 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\^^^^^^^^^^^^^^^^^^^^^^\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\<<#MWSHARPMWMWMWTEETHWMWWM>>>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ .... ==== [[killer-source]] .C Code To Lure Killer Rabbit Back To Cave ==== [source,c] ---- /* Locate the Killer Rabbit */ int type; unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); return LOST_CREATURE; } Tse, et al. Expires October 20, 2018 [Page 42] Internet-Draft AsciiRFC Specifications April 2018 /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ---- ==== Figure 20: AsciiRFC With A Figure
A Photo Of The Killer Rabbit of Caerbannog Taken In Secret >>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM Tse, et al. Expires October 20, 2018 [Page 43] Internet-Draft AsciiRFC Specifications April 2018 MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ ]]>
C Code To Lure Killer Rabbit Back To Cave /* Locate the Killer Rabbit */ int type; unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); return LOST_CREATURE; } /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } Tse, et al. Expires October 20, 2018 [Page 44] Internet-Draft AsciiRFC Specifications April 2018 /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ]]>
Figure 21: AsciiRFC With A Figure (RFC XML v3) If an AsciiRFC Listing or Literal occurs outside of an Example (Figure 22), the RFC XML converter will supply the surrounding Figure element (Figure 23). [[hand-grenade-figure]] .The Holy Hand Grenade of Antioch (don't pull the pin) Figure 22: AsciiRFC With ASCII Art Without Figure Wrapping ______ \\/ \/ __\\ /__ || //\ | ||__\\/ __| || | ,---, || |====`\ | || | '---' ,--'*`--, _||#|***|#| _,/.-'#|* *|#`-._ ,,-'#####| |#####`-. ,,'########| |########`, //##########| o |##########\ ||###########| |###########| ||############| o |############| ||------------' '------------| ||o o o o o o o o o o| |-----------------------------| ||###########################| \\#########################/ `..#####################,' ``..###############_,' ``--.._____..--' `''-----''` Tse, et al. Expires October 20, 2018 [Page 45] Internet-Draft AsciiRFC Specifications April 2018
The Holy Hand Grenade of Antioch (don't pull the pin)
Figure 23: AsciiRFC With ASCII Art Without Figure Wrapping (RFC XML v3) 8. Lists Tse, et al. Expires October 20, 2018 [Page 46] Internet-Draft AsciiRFC Specifications April 2018 8.1. Basic Lists AsciiRFC supports ordered, unordered, and definition lists. Indentation of ordered and unordered lists is indicated by repeating the list item prefix ("*" and "." respectively); for definition lists, it is indicated by incrementing the number of definition term delimiters ("::"). List attributes can be used to specify the type of symbol used for ordered lists. An example of an unordered list is shown in Figure 24 (with its rendered version in Figure 25). An example of an ordered list with ordered and unordered sublists is shown in Figure 26 (with its rendered version in Figure 27). An example of a definition list is shown in Figure 28 (with its rendered version in Figure 29). * Killed ** Sir Bors ** Sir Gawain ** Sir Ector * Soiled Himself ** Sir Robin * Panicked ** King Arthur * Employed Ordnance ** The Lector ** Brother Maynard * Scoffed ** Tim the Enchanter Figure 24: AsciiRFC With Unordered lists Tse, et al. Expires October 20, 2018 [Page 47] Internet-Draft AsciiRFC Specifications April 2018
  • Killed
    • Sir Bors
    • Sir Gawain
    • Sir Ector
  • Soiled Himself
    • Sir Robin
  • Panicked
    • King Arthur
  • Employed Ordnance
    • The Lector
    • Brother Maynard
  • Scoffed
    • Tim the Enchanter
Figure 25: AsciiRFC With Unordered Lists (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 48] Internet-Draft AsciiRFC Specifications April 2018 . Preamble: St Attila Benediction . Feast of the People on Sundry Foods ** Lambs ** Sloths ** Carp ** Anchovies ** Orangutangs ** Breakfast Cereals ** Fruit Bats ** _et hoc genus omne_ . Take out the Holy Pin . The Count [upperalpha] .. Count is to Three: no more, no less .. Not Four .. Nor Two, except if the count then proceeds to Three .. Five is Right Out . Lob the Holy Hand Grenade of Antioch towards the Foe . The Foe, being naughty in the *LORD's* sight, [bcp14]#shall# snuff it Figure 26: AsciiRFC With Ordered lists Tse, et al. Expires October 20, 2018 [Page 49] Internet-Draft AsciiRFC Specifications April 2018
  1. Preamble: St Attila Benediction
  2. Feast of the People on Sundry Foods
    • Lambs
    • Sloths
    • Carp
    • Anchovies
    • Orangutangs
    • Breakfast Cereals
    • Fruit Bats
    • et hoc genus omne
  3. Take out the Holy Pin
  4. The Count
    1. Count is to Three: no more, no less
    2. Not Four
    3. Nor Two, except if the count then proceeds to Three
    4. Five is Right Out
  5. Lob the Holy Hand Grenade of Antioch towards the Foe
  6. The Foe, being naughty in the LORD's sight, SHALL snuff it
Figure 27: AsciiRFC With Ordered Lists (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 50] Internet-Draft AsciiRFC Specifications April 2018 Holy Hand Grenade of Antioch:: Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See <>. Holy Spear of Antioch:: A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098. Sovereign's Orb of the United Kingdom:: Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See <>. Figure 28: AsciiRFC With Definition lists
Holy Hand Grenade of Antioch
Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See .
Holy Spear of Antioch
A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098.
Sovereign's Orb of the United Kingdom
Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See .
Figure 29: AsciiRFC With Definition Lists (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 51] Internet-Draft AsciiRFC Specifications April 2018 8.2. List Continuation A list item by default spans a single paragraph. A following paragraph or other block element can be appended to the current list item by prefixing it with "+" in a separate line. See the "List Continuation" section in [Asciidoctor-Manual] for more information. An example of list continuation with text is shown in Figure 30 with its rendered version in Figure 31. Trojan Rabbit:: In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." + The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the French soldiers took the Trojan Rabbit inside the castle. Killer Rabbit of Caerbannog:: Guarding the entrance to the Cave of Caerbannog; see <>. Figure 30: AsciiRFC List With Text Continuation Tse, et al. Expires October 20, 2018 [Page 52] Internet-Draft AsciiRFC Specifications April 2018
Trojan Rabbit
In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the French soldiers took the Trojan Rabbit inside the castle.
Killer Rabbit of Caerbannog
Guarding the entrance to the Cave of Caerbannog; see .
Figure 31: AsciiRFC List With Text Continuation (RFC XML v3) (Multiple paragraphs are not permitted within a list item in RFC XML v2. The RFC XML converter deals with this by converting paragraph breaks into line breaks within a list item.) List continuations can also be embedded to populate a list item with a sequence of blocks as a unit (in an Asciidoctor syntax open block). An example of list continuation with a delimited block is shown in Figure 32 with its rendered version in Figure 33. Tse, et al. Expires October 20, 2018 [Page 53] Internet-Draft AsciiRFC Specifications April 2018 . Take out the Holy Pin . The Count + ---- integer count; for count := 1 step 1 until 3 do say(count) comment Five is Right Out ---- . Lob the Holy Hand Grenade of Antioch towards the Foe . Foe snuffs it Figure 32: AsciiRFC List With Block Continuation
  1. Take out the Holy Pin
  2. The Count
  3. Lob the Holy Hand Grenade of Antioch towards the Foe
  4. Foe snuffs it
Figure 33: AsciiRFC List With Block Continuation (RFC XML v3) AsciiDoc, and thus AsciiRFC, considers paragraphs to be the basic level of blocks, and does not permit lists to be nested within them: any text after a list is considered to be a new paragraph. Therefore, markup as shown in Figure 34 cannot be generated via AsciiRFC. Tse, et al. Expires October 20, 2018 [Page 54] Internet-Draft AsciiRFC Specifications April 2018 This is the start of a paragraph.
  • List Entry 1
  • List Entry 2 Note 2.
And this is the continuation of the paragraph.
Figure 34: This RFC XML v3 Output Cannot Be Generated Using AsciiRFC 9. Blockquotes Asciidoctor syntax supports blockquotes and quotations of verse; its block quotations permit arbitrary levels of quote nesting. RFC XML v3, and thus AsciiRFC, only supports one level of blockquotes. Unlike RFC XML v2, RFC XML v3 does not support line breaks outside of tables, so verse quotations are converted to prose in the v3 converter. An example of using AsciiRFC Blockquotes is given in Figure 35 with its rendered version in Figure 36. [quote,attribution="A. Farrel"] ____ Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence. ____ Figure 35: AsciiRFC Blockquote Usage Tse, et al. Expires October 20, 2018 [Page 55] Internet-Draft AsciiRFC Specifications April 2018
Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence.
Figure 36: AsciiRFC Blockquote Usage (RFC XML v3) 10. Notes And Asides Asciidoctor syntax supports a range of "admonitions", including notes, warnings, and tips. They are indicated by a paragraph prefix (e.g. "WARNING:"), or as a block with an admonition style attribute. All admonitions are conflated in AsciiRFC, being converted to "note" elements in the document preamble, and "cref" elements in the main document. This means that no admonitions will therefore appear in the textual output, unless forced to through the "comments" processing instruction. A sample admonition is shown in Figure 37, with its rendered output in Figure 38. [NOTE,display=true,source=Author] ==== Image courtesy of https://camelot.gov.example/creatures-in-ascii/ ==== Figure 37: An AsciiRFC Adminition Block Tse, et al. Expires October 20, 2018 [Page 56] Internet-Draft AsciiRFC Specifications April 2018 Image courtesy of Figure 38: An AsciiRFC Adminition Block (RFC XML v3) With RFC XML v2, note that no inline formatting is permitted for "cref" elements, and any such formatting is therefore stripped for v2 by the converter. Because paragraphs in AsciiRFC cannot contain any other blocks, a comment at the end of a paragraph is treated as a new block. In the document converter, any such comments are moved inside the preceding RFC XML paragraph; if the comment is at the start of a section, as in the example above, it is wrapped inside a paragraph. The RFC XML v3 converter also supports "asides" (Asciidoctor syntax Sidebars). A sample is shown in Figure 39, with its rendered output in Figure 40. **** While the exchange at the French-occupied castle is one of the more memorable scenes of _Monty Python and the Holy Grail_, the Trojan Rabbit has not reached the same level of cultural resonance as its more murderous counterpart. Reasons for this may include: * Less overall screen-time dedicated to the Trojan Rabbit. * The Trojan Rabbit as projectile has already been anticipated by the Cow as projectile. **** Figure 39: An AsciiRFC Sidebar Block Tse, et al. Expires October 20, 2018 [Page 57] Internet-Draft AsciiRFC Specifications April 2018 Figure 40: An AsciiRFC Sidebar Block Rendered As An Aside (RFC XML v3) Comments given in AsciiDoc syntax (notated with initial "//") are not intended to be shown in the rendered output, and will not appear in the output as XML comments. XML comments can be generated by using the "[comment]#...#" inline formatting macro, or the "[.comment]" role attribute on blocks. A sample is shown in Figure 39 with its rendered output in Figure 40. The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, [comment]#TODO: Will need to verify that claim.# which arguably predates the traditional English enmity with the French. [comment]#Strictly speaking, the Knights are Welsh.# [.comment] -- This document, as it turns out, has a profusion of XML comments. As expected, they are ignored in any rendering of the document. -- Figure 41: AsciiRFC delimited text intended as an XML Comment Tse, et al. Expires October 20, 2018 [Page 58] Internet-Draft AsciiRFC Specifications April 2018 The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, which arguably predates the traditional English enmity with the French. Figure 42: AsciiRFC delimited text Rendered As An XML Comment (RFC XML v3) 11. Tables AsciiRFC tables, like RFC XML v3, support distinct table heads, bodies and feet; cells spanning multiple rows and columns; and horizontal alignment. The larger range of table formatting options available in RFC XML v2 is also supported. A sample of an AsciiRFC table is shown in Figure 43, with its rendered output in Figure 44. Neither version of RFC XML is as expressive in its table structure as Asciidoctor syntax. RFC XML, for example, does not permit blocks within table cells. Tse, et al. Expires October 20, 2018 [Page 59] Internet-Draft AsciiRFC Specifications April 2018 [grid=all,options="footer"] |=== |French Castle | Cave of Caerbannog 2+|King Arthur 2+|Patsy 2+|Sir Bedevere the Wise 2+|Sir Galahad the Pure 2+|Sir Lancelot the Brave 2+|Sir Robin the Not-quite-so-brave-as-Sir-Lancelot |French Guard with Outrageous Accent| Tim the Enchanter |Other French Guards | Brother Maynard | | The Lector .3+^|not yet recruited >|Sir Bors >|Sir Gawain >|Sir Ector |Retinue of sundry knights |Retinue of sundry more knights than at the French Castle |=== Figure 43: An AsciiRFC Table Tse, et al. Expires October 20, 2018 [Page 60] Internet-Draft AsciiRFC Specifications April 2018
French Castle Cave of Caerbannog
King Arthur
Patsy
Sir Bedevere the Wise
Sir Galahad the Pure
Sir Lancelot the Brave
Sir Robin the Not-quite-so-brave-as-Sir-Lancelot
French Guard with Outrageous Accent Tim the Enchanter
Other French Guards Brother Maynard
The Lector
not yet recruited Sir Bors
Sir Gawain
Sir Ector
Retinue of sundry knights Retinue of sundry more knights than at the French Castle
Figure 44: An AsciiRFC Table (RFC XML v3) Tse, et al. Expires October 20, 2018 [Page 61] Internet-Draft AsciiRFC Specifications April 2018 12. Inline Formatting 12.1. Italics, Boldface, Monospace, Subscripts, Superscripts AsciiRFC supports italics, boldface, monospace, subscripts and superscripts, just like RFC XML v3. The inline formatting syntax given in Figure 45 produces the RFC XML v3 output given in Figure 46. The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the _Knights of the Round Table_ and the taunting French soldiers serving under *Guy de Lombard* are, properly speaking, outside the scope of this `menagerie`, being more or less human. Notwithstanding, several^ish^ beasts both animate~d~ and wooden played a significant part in this encounter; most notably: * The Projectile Cow, see <> * The Trojan Rabbit, see <> Figure 45: Inline Formatting In AsciiRFC Tse, et al. Expires October 20, 2018 [Page 62] Internet-Draft AsciiRFC Specifications April 2018 The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the Knights of the Round Table and the taunting French soldiers serving under Guy de Lombard are, properly speaking, outside the scope of this menagerie, being more or less human. Notwithstanding, severalish beasts both animated and wooden played a significant part in this encounter; most notably:
  • The Projectile Cow, see
  • The Trojan Rabbit, see
Figure 46: Inline Formatting In AsciiRFC (RFC XML v3) 12.2. Formatting BCP 14 Keywords RFC XML v3 also supports tagging of BCP14 keywords [RFC2119] [RFC8174]; this is done in AsciiRFC either by tagging them with a custom formatting span (e.g. "MUST NOT"), or by converting any boldface all-caps words recognised as BCP14 words (unless the ":no- rfc-bold-bcp14: false" document attribute is set). Any spans of BCP14 text delimited by inline formatting delimiters need to be contained within a single line of text; in Asciidoctor syntax, formatting spans are broken up across line breaks. This usage is demonstrated in Figure 47 with the rendered output in Figure 48. The instructions in the _Book of Armaments_ on the proper deployment of the Holy Hand Grenade of Antioch [bcp14]#may# be summarized as follows, although this summary *SHALL NOT* be used as a substitute for a reading from the Book of Armaments: Figure 47: BCP14 Keywords In AsciiRFC Tse, et al. Expires October 20, 2018 [Page 63] Internet-Draft AsciiRFC Specifications April 2018 The instructions in the Book of Armaments on the proper deployment of the Holy Hand Grenade of Antioch MAY be summarized as follows, although this summary SHALL NOT be used as a substitute for a reading from the Book of Armaments: Figure 48: BCP14 Keywords In AsciiRFC (RFC XML v3) 12.3. Escaping AsciiRFC Syntax Formatting delimiters like "*" can be escaped with backslash ("\*"); double formatting delimiters, like "**" and "__", need to be escaped with double backslash ("\\**"). Escaping delimiters is not always reliable, and for double delimiters it is preferable to use HTML entities ("**"), or attribute references (references to the value of attributes set in the document header) as shown in Figure 49. :dblast: ** `{dblast}` Figure 49: Escaping AsciiRFC Syntax Using Attributes In extreme circumstances (such as quoting AsciiDoc syntax), you may need to resort to altering the substitutions behaviour within a given block of of AsciiDoc; see the "Applying Substitutions" section of [Asciidoctor-Manual]. 13. Links Common URL formats are recognised automatically as hyperlinks in AsciiRFC, which inherits this excellent feature from AsciiDoc, and are rendered as such. Any hyperlinked text is appended after the hyperlink in square brackets. An example is given in Figure 50 with its rendered version in Figure 51. Tse, et al. Expires October 20, 2018 [Page 64] Internet-Draft AsciiRFC Specifications April 2018 <> of the fearsome beast has been sourced from http://camelot.gov.example/avatars/rabbit[Rabbit-SCII], <> by C code that was used in this accurate depiction of the Killer Rabbit: Figure 50: An AsciiRFC Link The following depiction of the fearsome beast has been sourced from Rabbit-SCII, accompanied by C code that was used in this accurate depiction of the Killer Rabbit: Figure 51: An AsciiRFC Link (RFC XML v3) To prevent hyperlinking of a URL, prefix it with a backslash, as shown in Figure 52 with its rendered version in Figure 53. The screaming move into the twenty-*first* century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like \ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) Figure 52: A Literal AsciiRFC Link Tse, et al. Expires October 20, 2018 [Page 65] Internet-Draft AsciiRFC Specifications April 2018 The screaming move into the twenty-first century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) Figure 53: A Literal AsciiRFC Link (RFC XML v3) 14. Cross-References 14.1. Basic Referencing Anchors for cross-references are notated as "[[...]]" or "[#...]", and can be inserted on their own line in front of most blocks. Asciidoctor syntax supports anchors in a much wider range of contexts than is supported than RFC XML v3 (let alone v2); anchors that are not supported for that version of RFC XML are simply ignored by the converter. Note that anchors in RFC XML are constrained to the format "[A-Za- z_:][[A-Za-z0-9_:.-]*" (i.e. "xsd:ID"). Cross-references to anchors are notated as "<<...>>"; cross- references with custom text as "<>". An example of using cross-references in AsciiRFC is given in Figure 54 with its rendered output in Figure 55. Tse, et al. Expires October 20, 2018 [Page 66] Internet-Draft AsciiRFC Specifications April 2018 The _Cave of Caerbannog_ has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the *Killer Rabbit of Caerbannog* <>. It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the <>), that we recount here through monospace font and multiple spaces. [[killer_rabbit_caerbannog]] === The Killer Rabbit of Caerbannog Figure 54: Setting And Referring To Cross-References In AsciiRFC The Cave of Caerbannog has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the Killer Rabbit of Caerbannog . It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the following section), that we recount here through monospace font and multiple spaces.
The Killer Rabbit of Caerbannog Figure 55: Setting And Referring To Cross-References In AsciiRFC (RFC XML v3) 14.2. Referencing With Attributes While Asciidoctor syntax natively does not support attributes on cross-references, AsciiRFC works around that by embedding formatting information as templated text within cross-references: o "format= x: text" populates the "xref@format" attribute Tse, et al. Expires October 20, 2018 [Page 67] Internet-Draft AsciiRFC Specifications April 2018 o a section number followed by one of the words "of", "parens", "bare", "text" is treated as a "relref" reference to an external document. An example of referencing with attributes is given in Figure 56 with its output in Figure 57. The *Killer Rabbit of Caerbannog*, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, _contra_ the claim made in <>, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as <>, there are few remedies known against its awful lapine powers. Figure 56: Cross-References With Attributes In AsciiRFC The Killer Rabbit of Caerbannog, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, contra the claim made in Ze Vompyre, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as , there are few remedies known against its awful lapine powers. Figure 57: Cross-References With Attributes In AsciiRFC (RFC XML v3) 14.3. Indexing Inline index entries are notated as "((...))". Index entries which do not appear in the text are notated as "(((...)))"; such entries may include a separate sub-entry, separated from the main entry by comma. Tse, et al. Expires October 20, 2018 [Page 68] Internet-Draft AsciiRFC Specifications April 2018 The solution to the impasse at the ((Cave of Caerbannog)) was provided by the successful deployment of the *Holy Hand Grenade of Antioch* (see <>) (((Holy Hand Grenade of Antioch))). Any similarity between the Holy Hand Grenade of Antioch and the mythical _Holy Spear of Antioch_ is purely intentional; (((relics, Christian))) any similarity between the Holy Hand Grenade of Antioch and the _Sovereign's Orb of the United Kingdom_ (see <>) is putatively fortuitous. (((relics, monarchic))) Figure 58: AsciiRFC Index Entries The solution to the impasse at the Cave of Caerbannog was provided by the successful deployment of the Holy Hand Grenade of Antioch (see ) . Any similarity between the Holy Hand Grenade of Antioch and the mythical Holy Spear of Antioch is purely intentional; any similarity between the Holy Hand Grenade of Antioch and the Sovereign's Orb of the United Kingdom (see ) is putatively fortuitous. Figure 59: AsciiRFC Index Entries (RFC XML v3) 15. Inclusions AsciiRFC inherits the Asciidoctor syntax "include" directive [Asciidoctor-Manual] to include external files in a master AsciiRFC document. This directive is capable of sophisticated document merging, including adjusting the heading levels of the included text, selecting text within specified tags or line numbers to be included, and adjusting the indentation of code snippets in merged text. Tse, et al. Expires October 20, 2018 [Page 69] Internet-Draft AsciiRFC Specifications April 2018 Its basic syntax is given in Figure 60. include::path[ leveloffset=_offset_, lines=_ranges_, tag(s)=_name(s)_, indent=_depth_ ] Figure 60: Inclusions In AsciiRFC If a file is included in an AsciiRFC document, ensure it ends with a blank line. An inclusion that results in its final block not being delimited with a blank line from what follows can lead to unpredictable results. 16. Encoding and Entities XML accepts the full range of characters in the world's languages through UTF-8 character encoding, and one of the motivations for the move by the IETF from plain text to RFC XML has been to allow non- ASCII characters to be included in RFCs. However, current RFC XML v2 tools still do not support UTF-8, and alternative tooling support for UTF-8 also remains patchy. Out of an abundance of caution, the RFC XML converter uses US-ASCII for its character encoding, and renders any non-ASCII characters as HTML entities. AsciiRFC accepts HTML entities as input, even though they are not part of the W3C XML specification. HTML entities such as " " feature in examples of RFC XML provided by the IETF. In order to prevent dependence of the XML output from extraneous entity definitions, any such entities are rendered in the XML as decimal character entities. An example of how AsciiRFC renders non-ASCII UTF-8 characters are given in Figure 61 with the output in Figure 62. Tse, et al. Expires October 20, 2018 [Page 70] Internet-Draft AsciiRFC Specifications April 2018 ____ .כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה .מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh." ____ Figure 61: UTF-8 Characters In AsciiRFC
כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh."
Figure 62: UTF-8 Characters In AsciiRFC Rendered As RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 71] Internet-Draft AsciiRFC Specifications April 2018 Note that because initial period is a formatting character in Asciidoctor, we have had to use "." to escape the period at the end of Hebrew sentences (which appears at the start of the line, Hebrew being written Right-to-Left). Asciidoctor is not natively equipped to deal with Right-to-Left languages in its formatting parsing. 17. Bibliography The simple encoding of bibliography syntax provided by AsciiDoc (and Asciidoctor syntax) is inadequate for the complexity of bibliographic markup required by RFC XML. RFC documents overwhelmingly cite other RFC documents, and canonical RFC XML bibliographic entries are available at [IETF-BibXML]; so it would be inefficient to encode those entries natively in AsciiRFC, only to have them converted back to RFC XML. The converter provides two means of incorporating bibliographies into RFC documents authored in AsciiRFC: o using raw RFC XML; and o assembling bibliographies in preprocessing. In either case, the RFC XML needs to be well-formed; missing closing tags can lead to erratic behaviour in the converter. 17.1. Using Raw RFC XML In the first method, bibliographic citations are handled like all other AsciiRFC cross-references. The bibliographic entries for normative and informative references are given in the AsciiRFC as passthrough blocks, which contain the raw RFC XML for all references; document conversion leaves the raw RFC XML in place. This approach requires authors to maintain the normative and informative bibliographies within the document, to update them as citations are added and removed, and to sort them manually. However, if the citation is stored on the IETF's RFC XML citation libraries (see ), AsciiRFC will automatically replace it with an external reference to that citation. So the body of the citation XML can be left out. For example, the AsciiRFC in Figure 63 will generate the corresponding RFC XML v3 output in Figure 64. Tse, et al. Expires October 20, 2018 [Page 72] Internet-Draft AsciiRFC Specifications April 2018 [bibliography] == Normative References ++++ Key words for use in RFCs to Indicate Requirement Levels ++++ [bibliography] == Informative References ++++ Monty Python and the Holy Grail DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) Tse, et al. Expires October 20, 2018 [Page 73] Internet-Draft AsciiRFC Specifications April 2018 RFC Format Framework The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce Tse, et al. Expires October 20, 2018 [Page 74] Internet-Draft AsciiRFC Specifications April 2018 the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ++++ Figure 63: AsciiRFC Inline Bibliography Tse, et al. Expires October 20, 2018 [Page 75] Internet-Draft AsciiRFC Specifications April 2018
Normative References Informative References Monty Python and the Holy Grail Figure 64: AsciiRFC Inline Bibliography Rendered As RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 76] Internet-Draft AsciiRFC Specifications April 2018 17.2. Preprocessing Using "asciidoctor-bibliography" The alternative method is to use a preprocessing tool, [asciidoctor-bibliography], to import citations into the AsciiRFC document from an external file of references. The references file consists of RFC XML reference entries, and still needs to be managed manually; however the bibliographies are assembled from that file, sorted, and inserted into the normative and informative references in preprocessing. Citations in the document itself are given as macros to be interpreted by the preprocessor; this allows them to be split into normative and informative references. (The MMark tool likewise splits reference citations into normative and informative.) Integration with the "asciidoc-bibliography" gem proceeds as follows: 1. Create an RFC XML references file, consisting of a "" element with individual "" elements inserted, as would be done for the informative and normative references normally. The references file will contain all possible references to be used in the file; the bibliography gem will select which references have actually been cited in the document. A. Rather than hand crafting RFC XML references for RFC documents, you should download them from an authoritative source; e.g., "http://xml.resource.org/public/rfc/bibxml/\ reference.RFC.2119.xml". Note that RFC XML references from this link contains the XML document declaration, which needs to be removed before being used in the XML bibliography. B. Unlike the case for RFC XML documents created manually, the references file does not recognise XML entities and will not attempt to download them during processing. Any references to "http://xml.resource.org/public/rfc/bibxml/\ " will need to be downloaded and inserted into the references file. C. The RFC XML in the references file will need to be appropriate to the version of RFC XML used in the main document, as usual. Note that RFC XML v2 references are forward compatible with v3; v3 contains a couple of additional elements. 2. Add to the main document header attributes referencing the references file (":bibliography-database:"), and the bibliography style (":bibliography-style: rfc-v3"). Tse, et al. Expires October 20, 2018 [Page 77] Internet-Draft AsciiRFC Specifications April 2018 3. References to a normative reference are inserted with the macro "cite:norm[id]" instead of "<>", where "id" is the anchor of the reference. 4. References to an informative reference are inserted with the macro "cite:info[id]" instead of "<>", where "id" is the anchor of the reference. 5. Formatted crossreferences and "relref" crossreferences are entered by inserting the expected raw XML in the "text" attribute. Do not use the "{cite}" interpolation of the citation. For example: * "<>" = "cite:norm[id, text="words"]" * "<>" (processed as a formatted cross-reference) = "cite:norm[id, text="words"]" * "<>" (processed as relref) = "cite:norm[id, text=""]" * "<>" (processed as relref with a cross-document internal reference) = "cite:norm[id, text=""]" 6. Normative and Informative References are inserted in the document through a macro, which occurs where the RFC XML references would be inserted, as shown in Figure 65. Tse, et al. Expires October 20, 2018 [Page 78] Internet-Draft AsciiRFC Specifications April 2018 [bibliography] == Normative References ++++ bibliography::norm[] ++++ [bibliography] == Informative References ++++ bibliography::info[] ++++ Figure 65: Using asciidoctor-bibliography For Bibliography Preprocessing 18. RFC XML features not supported in Asciidoctor The following features of RFC XML v3 [RFC7991] and v2 [RFC7749] are not supported by the AsciiRFC converter, and would need to be adjusted manually after RFC XML is generated: +------------------------+--------------------+---------------------+ | RFC XML element | RFC XML v3 | RFC XML v2 | +------------------------+--------------------+---------------------+ | "front/boilerplate" | Not added by the | Not added by the | | | converter | converter | | "iref@primary" | N | N | | "reference" (and all | As Raw XML | As Raw XML | | children) | | | | "table/preamble" | Deprecated | N | | "table/postamble" | Deprecated | N | | "artwork@width" | Only on images | Only on images | | "artwork@height" | Only on images | Only on images | +------------------------+--------------------+---------------------+ 19. Authoring To author an AsciiRFC document, you should first familiarise yourself with the [Asciidoctor-Manual]. The [asciidoctor-rfc] Ruby gem source code distribution also has samples of individual RFC XML features in v2 and v3, and examples of self-standing AsciiRFC documents, along with their RFC XML renderings. (This includes round-tripped RFC XML documents.) Tse, et al. Expires October 20, 2018 [Page 79] Internet-Draft AsciiRFC Specifications April 2018 19.1. Using the "rfc-asciirfc-minimal" template In addition, you can clone the sample "rfc-asciirfc-minimal" repository as a template, and populate it for your AsciiRFC document using the steps shown in Figure 66. $ git clone https://github.com/riboseinc/rfc-asciirfc-minimal Figure 66: Cloning The AsciiRFC Document Template 19.2. Installing AsciiRFC Backend Processors Converting your AsciiRFC to RFC XML is a simple as installing the Asciidoctor Ruby gem "asciidoctor" (see "Installation" at [Asciidoctor]) and the "asciidoctor-rfc" gem in Ruby (through RubyGems), then running the "asciidoctor" executable on the document, specifying the "asciidoctor-rfc" gem as a library. The necessary steps are shown in Figure 67. $ gem install asciidoctor-rfc $ asciidoctor -b rfc3 -r 'asciidoctor-rfc' foo.adoc # RFC XML v3 output $ asciidoctor -b rfc2 -r 'asciidoctor-rfc' foo.adoc # RFC XML v2 output Figure 67: Installing The AsciiRFC Backend Processors 19.3. Iterating AsciiRFC Content As you author AsciiRFC content, you should iterate by running the AsciiRFC conversion frequently, to ensure that you are still generating valid XML through your markup. The converter makes an effort to ensure that its XML output is valid, and it issues warnings about likely issues; it also validates its own XML output against the RFC XML schema (of the corresponding version), and reports errors in the XML output in the format shown in Figure 68. V3 RELAXNG Validation: 12:0: ERROR: Invalid attribute sortRefs for element rfc Figure 68: Sample Validation Error Message From AsciiRFC Note that validation against the Relax NG RFC XML schema includes confirming the referential integrity of all cross-references in the document. It may be necessary to intervene in the XML output generated by the converter, either because the block model of AsciiRFC does not conform with the intended RFC XML (e.g. lists embedded in Tse, et al. Expires October 20, 2018 [Page 80] Internet-Draft AsciiRFC Specifications April 2018 paragraphs), or because RFC XML features are required that are not supported within AsciiRFC. 20. Security Considerations o Ensure your AsciiRFC generator comes from a geniune and trustworthy source. This protects your own machine and also prevents injection of malicious content in your resulting document. o An AsciiRFC generator may cause errors in textual rendering or link generation that may lead to security issues. o Creating cross-references (and also bibliographic references) to external documents may pose risks since the specified external location may become controlled by a malicious party. o URIs that start with the "http:" or "https:" prefix are automatically converted into links in AsciiRFC except when escaped with a backslash before the prefix. A URI that is intended to be text but unintentionally rendered as a link may cause users to visit a malicious website with security consequences. o AsciiRFC contains syntax that can directly incorporate remote URI content, such as "include::" which allows remotely-located AsciiRFC content files. If a remote URI contains malicious content, this content will be included in the resulting AsciiRFC document compiled as RFC XML. Remotely-linked URIs should always be checked for malicious content prior to compiling AsciiRFC into RFC XML. 21. IANA Considerations This document does not require any action by IANA. 22. References 22.1. Normative References [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, . 22.2. Informative References [AsciiDoc] Rackham, S., "AsciiDoc: Text based document generation", November 2013, . Tse, et al. Expires October 20, 2018 [Page 81] Internet-Draft AsciiRFC Specifications April 2018 [Asciidoctor] Allen, D., Waldron, R., and S. White, "Asciidoctor: A fast text processor & publishing toolchain for converting AsciiDoc to HTML5, DocBook & more.", November 2017, . [asciidoctor-bibliography] Ribose Inc., "Citations and Bibliography the 'asciidoctor- way'", November 2017, . [Asciidoctor-Manual] Allen, D., Waldron, R., and S. White, "Asciidoctor: A fast text processor & publishing toolchain for converting AsciiDoc to HTML5, DocBook & more.", November 2017, . [asciidoctor-rfc] Ribose Inc., "asciidoctor-rfc lets you write Internet- Drafts and RFCs in AsciiDoc, the "asciidoctor-way".", November 2017, . [AsciiMathML] "AsciiMath is an easy-to-write markup language for mathematics.", November 2017, . [datatracker-asciirfc-minimal] Carberry, J. and T. Grayson, "IETF Datatracker: A Minimal Internet-Draft In AsciiRFC", April 2018, . [datatracker-camelot-holy-grenade] Pendragon, A., "IETF Datatracker: The Holy Hand Grenade of Antioch", Aprilt 2018, . [datatracker-divination-cfapi] Destiny, G. and C. Luck, "IETF Datatracker: An API For Calendar-Based Fortune Heuristics Services", March 2018, . [draftr] Barnes, R., "draftr: an HTML front-end to pandoc2rfc", Nov 2017, . Tse, et al. Expires October 20, 2018 [Page 82] Internet-Draft AsciiRFC Specifications April 2018 [git-asciirfc-minimal] Carberry, J. and T. Grayson, "Git repository: A Minimal Internet-Draft In AsciiRFC", March 2018, . [git-camelot-holy-grenade] Pendragon, A., "Git repository: The Holy Hand Grenade of Antioch", March 2018, . [git-divination-cfapi] Destiny, G. and C. Luck, "Git repository: An API For Calendar-Based Fortune Heuristics Services", March 2018, . [I-D.asciirfc-minimal] Carberry, J. and T. Grayson, "A Minimal Internet-Draft In AsciiRFC", draft-asciirfc-minimal-02 (work in progress), April 2018. [I-D.camelot-holy-grenade] Pendragon, A., "The Holy Hand Grenade of Antioch", draft- camelot-holy-grenade-01 (work in progress), April 2018. [I-D.divination-cfapi] Destiny, G. and C. Luck, "An API For Calendar-Based Fortune Heuristics Services", draft-divination-cfapi-00 (work in progress), March 2018. [I-D.wu-netmod-yang-xml-doc-conventions] Wu, Q., Farrel, A., and B. Claise, "Documentation Conventions for Expressing YANG in XML", draft-wu-netmod- yang-xml-doc-conventions-00 (work in progress), January 2018. [IETF-BibXML] "IETF BibXML Library", November 2017, . [kramdown-rfc2629] Bormann, C., "kramdown-rfc2629: An RFC2629 (XML2RFC) backend for Thomas Leitner's kramdown markdown parser", Nov 2017, . [lyx2rfc] Williams, N., "LyX to I-D/RFC export by way of Lyx export to XHTML and XSLT conversion to xml2rfc schema", 2014, . Tse, et al. Expires October 20, 2018 [Page 83] Internet-Draft AsciiRFC Specifications April 2018 [MathJax] "MathJax: A JavaScript display engine for mathematics that works in all browsers.", November 2017, . [mmark] Gieben, R., "Using mmark to create I-Ds and RFCs", June 2015, . [NroffEdit] Santesson, S., "WYSIWYG Internet-Draft Nroff Editor", May 2011, . [pandoc2rfc] Gieben, R., "pandoc2rfc: Use pandoc to create XML suitable for xml2rfc", 2012, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", RFC 5385, DOI 10.17487/RFC5385, February 2010, . [RFC7328] Gieben, R., "Writing I-Ds and RFCs Using Pandoc and a Bit of XML", RFC 7328, DOI 10.17487/RFC7328, August 2014, . [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, . [RFC7763] Leonard, S., "The text/markdown Media Type", RFC 7763, DOI 10.17487/RFC7763, March 2016, . [RFC7764] Leonard, S., "Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations", RFC 7764, DOI 10.17487/RFC7764, March 2016, . [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, December 2016, . Tse, et al. Expires October 20, 2018 [Page 84] Internet-Draft AsciiRFC Specifications April 2018 [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", RFC 7996, DOI 10.17487/RFC7996, December 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TeX-LaTeX] "LaTeX is document preparation software that runs on top of Donald E. Knuth's TeX typesetting system.", November 2017, . Appendix A. Examples A.1. Example 1: "A Minimal Internet-Draft In AsciiRFC" This example is available in the following formats: o AsciiRFC [git-asciirfc-minimal] o Internet-Draft [I-D.asciirfc-minimal] o Text, RFC XML, PDF and HTML on the IETF Datatracker [datatracker-asciirfc-minimal] A.1.1. In AsciiRFC = A Minimal Internet-Draft In AsciiRFC :doctype: internet-draft :name: draft-asciirfc-minimal-02 :abbrev: AsciiRFC Example :status: informational :ipr: trust200902 :submissionType: individual :area: Internet :intended-series: full-standard :revdate: 2018-04-12T00:00:00Z :fullname: Josiah Stinkney Carberry :lastname: Carberry :forename_initials: J. S. :organization: Brown University :phone: +1 401 863 1000 :street: Box K, 69 Brown Street :city: Providence :code: 02912 :country: United States of America Tse, et al. Expires October 20, 2018 [Page 85] Internet-Draft AsciiRFC Specifications April 2018 :uri: https://www.brown.edu :email: josiah.carberry@ribose.com :fullname_2: Truman Grayson :lastname_2: Grayson :forename_initials_2: T. :organization_2: Brown University :phone_2: +1 401 863 1000 :street_2: Box G, 69 Brown Street :city_2: Providence :code_2: 02912 :country_2: United States of America :uri_2: https://www.brown.edu :email_2: truman.grayson@ribose.com [abstract] This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the `asciidoctor-rfc` Ruby gem. [#introduction] == Introduction AsciiRFC <> is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to <>. This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to <> and submittable to the IETF datatracker. [#conventions] == Terms and Definitions The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions: AsciiRFC:: an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in <>. Tse, et al. Expires October 20, 2018 [Page 86] Internet-Draft AsciiRFC Specifications April 2018 [#symbols] == Symbols And Abbreviations ADRFC:: abbreviated form of AsciiRFC [#main] == Main content This is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes. === Getting started The AsciiRFC and RFC toolchains *MUST* be available locally to build this document template. ==== AsciiRFC toolchain You will need to have: * Ruby: for running the AsciiRFC toolchain * `asciidoctor-rfc` gem: for converting AsciiRFC into XML RFC (v2 or v3) ==== XML RFC toolchain You will need to have: * Python: for running `xml2rfc` * `xml2rfc`: for converting RFC XML (v2 or v3) into TXT * `idnits`: for submission preflight === Referencing external content * This is a published RFC <> * This is an Internet-Draft <> * This is an external reference <> [#code-snippets] === Code snippets Tse, et al. Expires October 20, 2018 [Page 87] Internet-Draft AsciiRFC Specifications April 2018 Code snippets should be wrapped with `` and `` blocks, as required by the IETF Trust Legal Provisions (TLP) <> specified in <>. [#security] == Security Considerations Any security considerations should be placed here. As described in <
> (here's how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools *MAY* produce unintended side effects that impact security. [#iana] == IANA Considerations This document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here. // References must be given before appendixes [bibliography] == Normative References //bibliography::norm[] ++++ Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and Tse, et al. Expires October 20, 2018 [Page 88] Internet-Draft AsciiRFC Specifications April 2018 requests discussion and suggestions for improvements. The "xml2rfc" Version 3 Vocabulary This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Tse, et al. Expires October 20, 2018 [Page 89] Internet-Draft AsciiRFC Specifications April 2018 ++++ [bibliography] == Informative References //bibliography::info[] ++++ IETF Trust Legal Provisions (TLP) IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc Tse, et al. Expires October 20, 2018 [Page 90] Internet-Draft AsciiRFC Specifications April 2018 This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator. Rights Contributors Provide to the IETF Trust The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities Tse, et al. Expires October 20, 2018 [Page 91] Internet-Draft AsciiRFC Specifications April 2018 while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OCB Authenticated-Encryption Algorithm This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG). ++++ [appendix] [#appendix-a] == Examples === Example 1 Here's an example of a properly wrapped code snippet in accordance with rules specified in <>. [source,json] Tse, et al. Expires October 20, 2018 [Page 92] Internet-Draft AsciiRFC Specifications April 2018 ---- { "code": { "encoding": "ascii", "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ---- [#acknowledgements] == Acknowledgements The authors would like to thank their families. A.1.2. Rendered as RFC XML v3 A Minimal Internet-Draft In AsciiRFC Brown University
Box K, 69 Brown Street Providence Tse, et al. Expires October 20, 2018 [Page 93] Internet-Draft AsciiRFC Specifications April 2018 02912 United States of America +1 401 863 1000 josiah.carberry@ribose.com https://www.brown.edu
Brown University
Box G, 69 Brown Street Providence 02912 United States of America +1 401 863 1000 truman.grayson@ribose.com https://www.brown.edu
Internet This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the asciidoctor-rfc Ruby gem.
IntroductionAsciiRFC is an extremely simple way to author Internet-Drafts and RFCs without needing to manually craft RFC XML conforming to . This is a template specifically made for authors to easily start with creating an Internet-Draft conforming to and submittable to the IETF datatracker.
Terms and DefinitionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 Tse, et al. Expires October 20, 2018 [Page 94] Internet-Draft AsciiRFC Specifications April 2018 when, and only when, they appear in all capitals, as shown here. This document also refers to the following terms and definitions:
AsciiRFC
an AsciiDoc-derived syntax used for authoring RFCs and Internet-Drafts, as defined in .
Symbols And Abbreviations
ADRFC
abbreviated form of AsciiRFC
Main contentThis is where you place the main content, and the following serves as a placeholder for your text. Subsections are used here for demonstration purposes.
Getting startedThe AsciiRFC and RFC toolchains MUST be available locally to build this document template.
AsciiRFC toolchainYou will need to have:
  • Ruby: for running the AsciiRFC toolchain
  • asciidoctor-rfc gem: for converting AsciiRFC into XML RFC (v2 or v3)
XML RFC toolchainYou will need to have:
  • Python: for running xml2rfc
  • xml2rfc: for converting RFC XML (v2 or v3) into TXT
  • idnits: for submission preflight
Referencing external content
  • This is a published RFC
  • This is an Internet-Draft
  • This is an external reference
  • Tse, et al. Expires October 20, 2018 [Page 95] Internet-Draft AsciiRFC Specifications April 2018
Code snippets Code snippets should be wrapped with <CODE BEGINS> and <CODE ENDS> blocks, as required by the IETF Trust Legal Provisions (TLP) specified in .
Security ConsiderationsAny security considerations should be placed here. As described in (here’s how you refer a local anchor), local tools have to be installed before the document template can be built. Running of these local tools MAY produce unintended side effects that impact security.
IANA ConsiderationsThis document does not require any action by IANA. But if it does, such as proposing changes to IANA registries, please include them here.
Normative References Informative References IETF Trust Legal Provisions (TLP) Tse, et al. Expires October 20, 2018 [Page 96] Internet-Draft AsciiRFC Specifications April 2018 IETF RNP: A C library approach to OpenPGP Ribose Inc.
Suite 1111, 1 Pedder Street Central Hong Kong Hong Kong open.source@ribose.com https://www.ribose.com
Examples
Example 1Here’s an example of a properly wrapped code snippet in accordance with rules specified in .
{ "code": { "encoding": "ascii", Tse, et al. Expires October 20, 2018 [Page 97] Internet-Draft AsciiRFC Specifications April 2018 "type": "rfc", "authors": [ "Josiah Carberry", "Truman Grayson" ] } } ]]>
Acknowledgements The authors would like to thank their families.
A.2. Example 2: "The Holy Hand Grenade of Antioch" This example is available in the following formats: o AsciiRFC [git-camelot-holy-grenade] o Internet-Draft [I-D.camelot-holy-grenade] o Text, RFC XML, PDF and HTML on the IETF Datatracker [datatracker-camelot-holy-grenade] A.2.1. In AsciiRFC = The Holy Hand Grenade of Antioch Arthur son of Uther Pendragon :doctype: internet-draft :abbrev: Hand Grenade of Antioch :updates: 8140 :submission-type: independent :name: draft-camelot-holy-grenade-01 :status: informational :consensus: false :area: General, Operations and Management :keyword: rabbits, grenades, antioch, camelot :ipr: trust200902 :toc-include: true :sort-refs: true :revdate: 2018-04-15T00:00:00Z :fullname: Arthur son of Uther Pendragon :forename_initials: A. :lastname: Pendragon Tse, et al. Expires October 20, 2018 [Page 98] Internet-Draft AsciiRFC Specifications April 2018 :email: arthur.pendragon@ribose.com :organization: Camelot :uri: http://camelot.gov.example :street: Palace\ Camel Lot 1 :city: Camelot :region: England :country: United Kingdom :comments: yes :notedraftinprogress: yes :smart-quotes: false [.comment] tag::preamble1[] // tag::preamble[] [abstract] The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. [NOTE,remove-in-rfc=false] .Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635. // end::preamble[] [.comment] end::preamble1[] [.comment] tag::sectnums1[] // tag::sectnums[] [toc=exclude] :sectnums!: == Terminology The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. Tse, et al. Expires October 20, 2018 [Page 99] Internet-Draft AsciiRFC Specifications April 2018 :sectnums: == Introduction <> refers to the intended move of RFC formatting to XML2RFC v3 <>, in the following terms: // end::sectnums[] [.comment] end::sectnums1[] [.comment] tag::quote1[] // tag::quote[] [quote,attribution="A. Farrel"] ____ Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence. ____ // end::quote[] [.comment] end::quote1[] While no pigs, flying or otherwise, are involved in the transition to RFC XML v3, it is opportune to enhance the <> legendarium in the service of RFC XML v3, by illustrating its functionality through references to the mythology of Camelot, and particularly the incidents at the Cave of Caerbannog. [.comment] tag::escaped_hyperlink1[] // tag::escaped_hyperlink[] The screaming move into the twenty-*first* century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like \ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) // end::escaped_hyperlink[] [.comment] end::escaped_hyperlink1[] There are two references to rabbits in _Monty Python and the Holy Grail_ which are expounded on herewith: Tse, et al. Expires October 20, 2018 [Page 100] Internet-Draft AsciiRFC Specifications April 2018 [.comment] tag::listcontinuation1[] // tag::listcontinuation[] Trojan Rabbit:: In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." + The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the French soldiers took the Trojan Rabbit inside the castle. Killer Rabbit of Caerbannog:: Guarding the entrance to the Cave of Caerbannog; see <>. // end::listcontinuation[] [.comment] end::listcontinuation1[] == The French-occupied castle [.comment] tag::inline_formatting1[] // tag::inline_formatting[] The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the _Knights of the Round Table_ and the taunting French soldiers serving under *Guy de Lombard* are, properly speaking, outside the scope of this `menagerie`, being more or less human. Notwithstanding, several^ish^ beasts both animate~d~ and wooden played a significant part in this encounter; most notably: * The Projectile Cow, see <> * The Trojan Rabbit, see <> // end::inline_formatting[] [.comment] end::inline_formatting1[] [[projectile-cow]] .The Projectile Cow with an accompanying cannon ==== [alt=The Projectile Cow with an accompanying cannon in ASCII] Tse, et al. Expires October 20, 2018 [Page 101] Internet-Draft AsciiRFC Specifications April 2018 .... .-.-.-.-.-.-.-.-.-.-.-.--.-.-.-.-.-.-.--.-.-.-.-.-.-.-.--.-. _-_---__--__--___-___-__-____---___-________---____-____-__- ._.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.--..-.-.-.-.-.-..--.- ,..,.,.,.,.,..,.,,..,.,.,.,.,.,, ^^ .,,.,., ^^ .,.,.,.= _>-.-.-.-._>_>_>_.-.-.-.-.-.-.-. \\\ .,.,. /// .-.-.-.-. .,.,.,.,..,.,..,.,.,..,.,.,,..,., \ \_______/ / .,.,.,., .,.,.,.,..,.,.,.,..,,..,,.,.,.,.,. <[ {o} . ]> # .,.,.,. .-.-.--.-.-.-.-.-.--.-.-.-.--.-.-. [ ______] .-.-.-. .-.--.-.-.-.--.-.-.-.--.-.-.,.,., / [ ! ` `] .,.,..,.,.- .,.,.,.-.-,l,-,l.-,.,.,.,-.,*. / {_!MOO!_} . ., . . , .-.-.-.-.-.-.-.-.-.-.-.-.-.- /M / -.-<>.,.,..-.-, .-.-.--.-.-.-.-.-.-.-.-.--.. /MI LK\____ .-.-.-.-.-. .-.-.-.--.-.-.-.-.-.-.-.-.- /MILK mil_____k ,.,.,..-,- .-,-.-,-.,-.-,-.`-.-/-.. // -` // .-.p . .-.-. .-.--.-.-.-.-.-.-.-. // ., // .-.-.-.-.-.-.-.- .-.-.--.-.-.-.-.-.-. %____============ .-.-.--.-.-.-.-.- -.-.-.-.--.-.-.-.-.-. ! ! .,-.-.-,-,--,-.-,- ,--.-.-,--.--.-.,--, \ \ .-,-,--.-,--,-.---,-.-, ,-.-.-,-,-.-,-,-.--, + > .-,--,-.--,-,-.-.-,--,- ,--.-,--,-,--.---,- .-,-,--.--,--,-.---,-,-.-. .,.,.,.,..,.,.,.{A\ .,.,.,.,..,.,.,.,.,.,..,.,.,.,..,., .,.,.,.,.,.,.{GLASS\ .,..,.,.,.,.,..,.,.,.,.,.,.,..,.,.,., ,..,.,,.,,.,{OF|MILK\..,.,.,.,.,..,.,.,.,.,.,..,.,.,.,.,.,., ,.,..,.,,.,{ISWORTH},.,.,..,.,.,.,.,..,..,.,.,..,.,.,.,.,.,. .,.,.,.,.{EVERYTNG}.-.-.--..-.-.-.-.--..--.-.-.-.-.--.-.-.-. -.-.-.-{FORINFANTS}___--___-_-__-___--*(0~`~.,.,.,.,><><.><> _-__-_{BUTBETTER}-.-,-,-,-,-,-,-,-,.-^^^^.-.-.-.-.^^^7>>>,.. .._...{WITH_HONEY}-.-.-.-.-.-.-.-.-.-.RANDOM(BUSH)SHRUBS>_.. GRASS_GRASS_GRASS_GRASS_GRASS_SOMEROCKS>GRASS>GRASSPC SOIL_ROOTS_SOIL_SOIL_ROCKS_SOIL_GRASS_GRASS_GRASS_ROCKS_SOIL CLAY_ROCKS_PEBBLES_CLAY_CLAY_CLAY_CLAY_GOLD_CLAY_CLAY><_WORM ROOTS_CLAY_SKELETON_MORESOIL_CLAY_CLAY_CLAY_CLAY_ .... ==== [[trojan-rabbit]] .The Trojan Rabbit with an automatic sliding door ==== [alt=The Trojan Rabbit with an automatic sliding door, in ASCII] .... ___ ____ //_ \//\__\ || || | -__||_||__| // \--_ // ____ --___ // // \ \-_ Tse, et al. Expires October 20, 2018 [Page 102] Internet-Draft AsciiRFC Specifications April 2018 // \\ @/ o || // ---- _____|| // // //\_//__ // //-- --- \____ // // --- \______ // // , . ----- \_//_ // ,. --- \____ // .,v --- \___ // __ -- \_ || , _______________ //|| |-_ || | |''''''''''| // || | | || ' | | | || | | || | | | || | | || " | | 0 | ___||___ | | || | | | -------- | | ||___ | | | ______ | |- // \ | | | // \| _| \ // \ ____|---|__________|______// \/ | || X | / || X | / \\ /\\____/ \\ /___/ \\_____/ ----- \\_____/--- ----- ----- .... ==== [.comment] tag::aside1[] // tag::aside[] **** While the exchange at the French-occupied castle is one of the more memorable scenes of _Monty Python and the Holy Grail_, the Trojan Rabbit has not reached the same level of cultural resonance as its more murderous counterpart. Reasons for this may include: * Less overall screen-time dedicated to the Trojan Rabbit. * The Trojan Rabbit as projectile has already been anticipated by the Cow as projectile. **** // end::aside[] [.comment] end::aside1[] Tse, et al. Expires October 20, 2018 [Page 103] Internet-Draft AsciiRFC Specifications April 2018 [.comment] tag::note1[] // tag::note[] [NOTE,display=true,source=Author] ==== Image courtesy of https://camelot.gov.example/creatures-in-ascii/ ==== // end::note[] [.comment] end::note1[] [.comment] tag::comment1[] // tag::comment[] The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, [comment]#TODO: Will need to verify that claim.# which arguably predates the traditional English enmity with the French. [comment]#Strictly speaking, the Knights are Welsh.# [.comment] -- This document, as it turns out, has a profusion of XML comments. As expected, they are ignored in any rendering of the document. -- // end::comment[] [.comment] end::comment1[] [[caerbannog]] == The Mythos of Caerbannog [.comment] tag::xref1[] // tag::xref[] The _Cave of Caerbannog_ has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the Tse, et al. Expires October 20, 2018 [Page 104] Internet-Draft AsciiRFC Specifications April 2018 *Killer Rabbit of Caerbannog* <>. It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the <>), that we recount here through monospace font and multiple spaces. [[killer_rabbit_caerbannog]] === The Killer Rabbit of Caerbannog // end::xref[] [.comment] end::xref1[] [.comment] tag::relref1[] // tag::relref[] The *Killer Rabbit of Caerbannog*, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, _contra_ the claim made in <>, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as <>, there are few remedies known against its awful lapine powers. // end::relref[] [.comment] end::relref1[] [.comment] tag::hyperlink1[] // tag::hyperlink[] <> of the fearsome beast has been sourced from http://camelot.gov.example/avatars/rabbit[Rabbit-SCII], <> by C code that was used in this accurate depiction of the Killer Rabbit: // end::hyperlink[] [.comment] end::hyperlink1[] [.comment] tag::figure1[] // tag::figure1a[] Tse, et al. Expires October 20, 2018 [Page 105] Internet-Draft AsciiRFC Specifications April 2018 [[killer-bunny]] .A Photo Of The Killer Rabbit of Caerbannog Taken In Secret ==== [alt=The Killer Bunny, in ASCII] .... \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\^^^^^^^^^^^^^^^^^^^^^^\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\<<#MWSHARPMWMWMWTEETHWMWWM>>>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ .... ==== [[killer-source]] .C Code To Lure Killer Rabbit Back To Cave ==== [source,c] ---- /* Locate the Killer Rabbit */ int type; Tse, et al. Expires October 20, 2018 [Page 106] Internet-Draft AsciiRFC Specifications April 2018 unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); return LOST_CREATURE; } /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ---- ==== // end::figure1a[] [.comment] end::figure1[] On the beast's encounter with the Knights of the Round Table, the following personnel engaged with it in combat: [.comment] tag::ul1[] // tag::ul[] * Killed ** Sir Bors ** Sir Gawain ** Sir Ector * Soiled Himself ** Sir Robin * Panicked Tse, et al. Expires October 20, 2018 [Page 107] Internet-Draft AsciiRFC Specifications April 2018 ** King Arthur * Employed Ordnance ** The Lector ** Brother Maynard * Scoffed ** Tim the Enchanter // end::ul[] [.comment] end::ul1[] [[holy_hand_grenade]] === Holy Hand Grenade of Antioch [.comment] tag::figure2[] // tag::figure2a[] [[hand-grenade-figure]] .The Holy Hand Grenade of Antioch (don't pull the pin) ==== [alt=Holy Hand Grenade of Antioch, in ASCII] .... ______ \\/ \/ __\\ /__ || //\ | ||__\\/ __| || | ,---, || |====`\ | || | '---' ,--'*`--, _||#|***|#| _,/.-'#|* *|#`-._ ,,-'#####| |#####`-. ,,'########| |########`, //##########| o |##########\ ||###########| |###########| ||############| o |############| ||------------' '------------| ||o o o o o o o o o o| |-----------------------------| ||###########################| \\#########################/ Tse, et al. Expires October 20, 2018 [Page 108] Internet-Draft AsciiRFC Specifications April 2018 `..#####################,' ``..###############_,' ``--.._____..--' `''-----''` .... ==== // end::figure2a[] [.comment] end::figure2[] [[sovereign-orb]] .The Sovereign's Orb made invisible ==== .Outlines of the Sovereign's Orb [link=https://camelot.gov.example/sovereigns_orb.jpg,align=right] image::https://camelot.gov.example/sovereigns_orb.jpg[Orb,124,135] ==== [.comment] tag::index1[] // tag::index[] The solution to the impasse at the ((Cave of Caerbannog)) was provided by the successful deployment of the *Holy Hand Grenade of Antioch* (see <>) (((Holy Hand Grenade of Antioch))). Any similarity between the Holy Hand Grenade of Antioch and the mythical _Holy Spear of Antioch_ is purely intentional; (((relics, Christian))) any similarity between the Holy Hand Grenade of Antioch and the _Sovereign's Orb of the United Kingdom_ (see <>) is putatively fortuitous. (((relics, monarchic))) // end::index[] [.comment] end::index1[] [.comment] tag::dl1[] // tag::dl[] Holy Hand Grenade of Antioch:: Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See <>. Tse, et al. Expires October 20, 2018 [Page 109] Internet-Draft AsciiRFC Specifications April 2018 Holy Spear of Antioch:: A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098. Sovereign's Orb of the United Kingdom:: Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See <>. // end::dl[] [.comment] end::dl1[] [.comment] tag::bcp14_1[] // tag::bcp14[] The instructions in the _Book of Armaments_ on the proper deployment of the Holy Hand Grenade of Antioch [bcp14]#may# be summarized as follows, although this summary *SHALL NOT* be used as a substitute for a reading from the Book of Armaments: // end::bcp14[] [.comment] end::bcp14_1[] [.comment] tag::ol1[] // tag::ol[] . Preamble: St Attila Benediction . Feast of the People on Sundry Foods ** Lambs ** Sloths ** Carp ** Anchovies ** Orangutangs ** Breakfast Cereals ** Fruit Bats ** _et hoc genus omne_ . Take out the Holy Pin . The Count [upperalpha] .. Count is to Three: no more, no less .. Not Four Tse, et al. Expires October 20, 2018 [Page 110] Internet-Draft AsciiRFC Specifications April 2018 .. Nor Two, except if the count then proceeds to Three .. Five is Right Out . Lob the Holy Hand Grenade of Antioch towards the Foe . The Foe, being naughty in the *LORD's* sight, [bcp14]#shall# snuff it // end::ol[] [.comment] end::ol1[] This could also be represented in pseudocode as follows: [.comment] tag::listcontinuationblock1[] // tag::listcontinuationblock[] . Take out the Holy Pin . The Count + ---- integer count; for count := 1 step 1 until 3 do say(count) comment Five is Right Out ---- . Lob the Holy Hand Grenade of Antioch towards the Foe . Foe snuffs it // end::listcontinuationblock[] [.comment] end::listcontinuationblock1[] == Dramatis Personae The following human (more-or-less) protagonists were involved in the two incidents recounted as lore of the Knights of the Round Table: [.comment] tag::table1[] // tag::table[] [grid=all,options="footer"] |=== |French Castle | Cave of Caerbannog 2+|King Arthur 2+|Patsy 2+|Sir Bedevere the Wise Tse, et al. Expires October 20, 2018 [Page 111] Internet-Draft AsciiRFC Specifications April 2018 2+|Sir Galahad the Pure 2+|Sir Lancelot the Brave 2+|Sir Robin the Not-quite-so-brave-as-Sir-Lancelot |French Guard with Outrageous Accent| Tim the Enchanter |Other French Guards | Brother Maynard | | The Lector .3+^|not yet recruited >|Sir Bors >|Sir Gawain >|Sir Ector |Retinue of sundry knights |Retinue of sundry more knights than at the French Castle |=== // end::table[] [.comment] end::table1[] === Past the Killer Rabbit Once the Killer Rabbit of Caerbannog (<>) had been dispatched, the Knights of the Round Table uncovered the last words of Joseph of Arimathea, inscribed on the Cave of Caerbannog in Aramaic. While the precise Aramaic wording has not survived, we trust the following Hebrew subtitles will serve as an acceptable substitute: [.comment] tag::hebrew1[] // tag::hebrew[] ____ .כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה .מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. Tse, et al. Expires October 20, 2018 [Page 112] Internet-Draft AsciiRFC Specifications April 2018 He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh." ____ // end::hebrew[] [.comment] end::hebrew1[] == IANA Considerations IANA might consider a registry to track the mythical, especially ravaging beasts, such as the Killer Rabbit, who haunt the Internet. == Security Considerations Do not let the Killer Rabbit out under any circumstance. I repeat. Do not let the Killer Rabbit (<>) out. [.comment] tag::bibliography1[] // tag::bibliography[] [bibliography] == Normative References ++++ Key words for use in RFCs to Indicate Requirement Levels ++++ [bibliography] == Informative References Tse, et al. Expires October 20, 2018 [Page 113] Internet-Draft AsciiRFC Specifications April 2018 ++++ Monty Python and the Holy Grail DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) RFC Format Framework Tse, et al. Expires October 20, 2018 [Page 114] Internet-Draft AsciiRFC Specifications April 2018 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. ++++ // end::bibliography[] [.comment] end::bibliography1[] A.2.2. Rendered as RFC XML v3 Tse, et al. Expires October 20, 2018 [Page 115] Internet-Draft AsciiRFC Specifications April 2018 The Holy Hand Grenade of Antioch Camelot
Palace Camel Lot 1 Camelot England United Kingdom arthur.pendragon@ribose.com http://camelot.gov.example
General Operations and Management rabbits grenades antioch camelot The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the Tse, et al. Expires October 20, 2018 [Page 116] Internet-Draft AsciiRFC Specifications April 2018 menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635.
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Introduction refers to the intended move of RFC formatting to XML2RFC v3 , in the following terms:
Tse, et al. Expires October 20, 2018 [Page 117] Internet-Draft AsciiRFC Specifications April 2018 Although the RFC Editor has recently dragged the IETF kicking and screaming into the twentieth century [RFC7990] [RFC7996], there is a yearning among all right-thinking Internet architects to "keep it simple" and to return to the olden days when pigs could be given thrust without anyone taking undue offence.
While no pigs, flying or otherwise, are involved in the transition to RFC XML v3, it is opportune to enhance the legendarium in the service of RFC XML v3, by illustrating its functionality through references to the mythology of Camelot, and particularly the incidents at the Cave of Caerbannog. The screaming move into the twenty-first century is accompanied by a move back to the late twentieth century, with ASCII stylings more wonted in haunts like ftp://ftp.wwa.com/pub/Scarecrow (known to be accessible in 1996.) There are two references to rabbits in Monty Python and the Holy Grail which are expounded on herewith:
Trojan Rabbit
In their siege of the French-occupied castle which may already contain an instance of the Grail, Sir Bedevere the Wise proposes to use a Trojan Rabbit to infiltrate the castle, with a raiding party to take the French "not only by surprise, but totally unarmed." The proposal, unsurprisingly, proved abortive. The more so as the raiding party forgot to hide within the Trojan Rabbit, before the Tse, et al. Expires October 20, 2018 [Page 118] Internet-Draft AsciiRFC Specifications April 2018 French soldiers took the Trojan Rabbit inside the castle.
Killer Rabbit of Caerbannog
Guarding the entrance to the Cave of Caerbannog; see .
The French-occupied castle The participants of that renowned exercise in cross-cultural communication, to wit the exchange between the Knights of the Round Table and the taunting French soldiers serving under Guy de Lombard are, properly speaking, outside the scope of this menagerie, being more or less human. Notwithstanding, severalish beasts both animated and wooden played a significant part in this encounter; most notably:
  • The Projectile Cow, see
  • The Trojan Rabbit, see
The Projectile Cow with an accompanying cannon -.-.-.-._>_>_>_.-.-.-.-.-.-.-. \\\ .,.,. /// .-.-.-.-. .,.,.,.,..,.,..,.,.,..,.,.,,..,., \ \_______/ / .,.,.,., .,.,.,.,..,.,.,.,..,,..,,.,.,.,.,. <[ {o} . ]> # .,.,.,. Tse, et al. Expires October 20, 2018 [Page 119] Internet-Draft AsciiRFC Specifications April 2018 .-.-.--.-.-.-.-.-.--.-.-.-.--.-.-. [ ______] .-.-.-. .-.--.-.-.-.--.-.-.-.--.-.-.,.,., / [ ! ` `] .,.,..,.,.- .,.,.,.-.-,l,-,l.-,.,.,.,-.,*. / {_!MOO!_} . ., . . , .-.-.-.-.-.-.-.-.-.-.-.-.-.- /M / -.-<>.,.,..-.-, .-.-.--.-.-.-.-.-.-.-.-.--.. /MI LK\____ .-.-.-.-.-. .-.-.-.--.-.-.-.-.-.-.-.-.- /MILK mil_____k ,.,.,..-,- .-,-.-,-.,-.-,-.`-.-/-.. // -` // .-.p . .-.-. .-.--.-.-.-.-.-.-.-. // ., // .-.-.-.-.-.-.-.- .-.-.--.-.-.-.-.-.-. %____============ .-.-.--.-.-.-.-.- -.-.-.-.--.-.-.-.-.-. ! ! .,-.-.-,-,--,-.-,- ,--.-.-,--.--.-.,--, \ \ .-,-,--.-,--,-.---,-.-, ,-.-.-,-,-.-,-,-.--, + > .-,--,-.--,-,-.-.-,--,- ,--.-,--,-,--.---,- .-,-,--.--,--,-.---,-,-.-. .,.,.,.,..,.,.,.{A\ .,.,.,.,..,.,.,.,.,.,..,.,.,.,..,., .,.,.,.,.,.,.{GLASS\ .,..,.,.,.,.,..,.,.,.,.,.,.,..,.,.,., ,..,.,,.,,.,{OF|MILK\..,.,.,.,.,..,.,.,.,.,.,..,.,.,.,.,.,., ,.,..,.,,.,{ISWORTH},.,.,..,.,.,.,.,..,..,.,.,..,.,.,.,.,.,. .,.,.,.,.{EVERYTNG}.-.-.--..-.-.-.-.--..--.-.-.-.-.--.-.-.-. -.-.-.-{FORINFANTS}___--___-_-__-___--*(0~`~.,.,.,.,><><.><> _-__-_{BUTBETTER}-.-,-,-,-,-,-,-,-,.-^^^^.-.-.-.-.^^^7>>>,.. .._...{WITH_HONEY}-.-.-.-.-.-.-.-.-.-.RANDOM(BUSH)SHRUBS>_.. GRASS_GRASS_GRASS_GRASS_GRASS_SOMEROCKS>GRASS>GRASSPC SOIL_ROOTS_SOIL_SOIL_ROCKS_SOIL_GRASS_GRASS_GRASS_ROCKS_SOIL CLAY_ROCKS_PEBBLES_CLAY_CLAY_CLAY_CLAY_GOLD_CLAY_CLAY><_WORM ROOTS_CLAY_SKELETON_MORESOIL_CLAY_CLAY_CLAY_CLAY_ ]]>
The Trojan Rabbit with an automatic sliding door
Image courtesy of Tse, et al. Expires October 20, 2018 [Page 121] Internet-Draft AsciiRFC Specifications April 2018 The exchange of projectile animals was the beginning of a long-running fruitful relationship between the British and the French peoples, which arguably predates the traditional English enmity with the French.
The Mythos of Caerbannog The Cave of Caerbannog has been well-established in the mythology of Camelot (as recounted by Monty Python) as the lair of the Legendary Black Beast of Arrrghhh, more commonly known today as the Killer Rabbit of Caerbannog . It is the encounter between the Killer Rabbit of Caerbannog and the Knights of the Round Table, armed with the Holy Hand Grenade of Antioch (see the following section), that we recount here through monospace font and multiple spaces.
The Tse, et al. Expires October 20, 2018 [Page 122] Internet-Draft AsciiRFC Specifications April 2018 Killer Rabbit of Caerbannog The Killer Rabbit of Caerbannog, that most formidable foe of the Knights and of all that is holy or carrot-like, has been depicted diversely in lay and in song. We venture to say, contra the claim made in Ze Vompyre, that the Killer Rabbit of Caerbannog truly is the most afeared of all the creatures. Short of sanctified ordnance such as , there are few remedies known against its awful lapine powers. The following depiction of the fearsome beast has been sourced from Rabbit-SCII, accompanied by C code that was used in this accurate depiction of the Killer Rabbit: Tse, et al. Expires October 20, 2018 [Page 123] Internet-Draft AsciiRFC Specifications April 2018
A Photo Of The Killer Rabbit of Caerbannog Taken In Secret >>\\\\\\\\\\\\ \\\\\\\\\\\\\\\<<<#WMMWMWDEEPMDARKWCAVEMWWMMWM##>>>>\\\\\\\\ \\\\\\\\\\\\\<<#WMWMWMWMWWM/^MWMWMWMWMWMW^WMWMWMMW#>>>\\\\\\ \\\\\\\\\\\\<<#WMWMBEASTMW// \MWABBITWMW/ \MWMWMWMW##\\\\\\\ \\\\\\\\\\##MWMWMMWMWMWMWM\\ \MWMWMWMW/ /MWMWMWMWM##\\\\\\ \\\\\\\\##WMWMWMWMMWMWMWMWM\\ \MWMWMW/ /MWMWMWMMWMWMWM##\\ \\\\\\\##MWMMRAVENOUSMWMWMWM\\ \====/ /MWMRABBITMWMWMWMW## \\\\\\##MWMWMWMWMMWMWMWMWMW[[ ]WMWMWMMWMWMWMWMWMW \\\\\##MWMWMWMWCARNIVOROUSW[[ 3 3 ]MWMWTOOMDARKWMWMMW \\\\##MWMWDARKMWMWMWMWMWMWM//\ o /MWMWMWMMWMWMWMMWMWM \\##MWMWMMKILLERABBITWMWMM//| \___vv___/ \WMPITCHWBLACKWMWMW \##MWMWMWMMWMWMWMWMWMMWMW// | \-^^-/ |MWMWMWMMWMWMWMWMWM MWMWMWMMWMWVERYMDARKWMMW// | |MWMCAERBANNOGWMWMW MWMWMWMMWMWMWMWMWMWMWMM{{ / /MWMWMMWMWMWMWMWMWM MULTRADARKWMWMHELPMWMWMW\\ \ | | |MWMCANMMWMWMWMMWMWW MWMWMWMWMMWMWMWMWMMWMWMWM\\ | |_ | |_WMWMMYOUMWMMWWMWMW MWMMWMWMWMWMBLACKWMWMWMWWM\_|__-\-----\__-\MWMWMWMREADMWMWWM MWMWMWMMWMWMWMWMMWMWMWWMWMWMWMMWMWMWMWMWMWMWMWMWMWMWMMTHISWW MWVERYMMSCARYMWMWWMWMMWMWMWMWMWMWMWMWMWMWMWMWWMWMMWMWIWM'.', MWMWMMWMW======MWMMCANTWSEEMAMTHINGMMWMWMWMWMWMWMBETMMW` . ` MWMWMWM// SKULL \MWMWMWMMWSCREAMMMWMWMWMMWMNOTMWMWMWW ` . \ MWMWMW|| |X||X| |MWMWCALLMMEWMMWMWMMWMWMWMWWM - ` ~ . , ' MWMWMW||___ O __|MWMWMWMMWMWMWMWMMW' ___________// -_^_- MWMWMW \\||_|_||MWMW ' . . <_|_|_||_|__| \O/ MW \\/\||v v|| -\\-------___ . ., \ | \\| \_CHIN/ ==-(|CARROT/)\> \\/||// v\/||/ ) /--------^-^ ,. \|// # \(/ .\\|x// " ' ' . , \\||// \||\\\// \\ ]]>
C Code To Lure Killer Rabbit Back To Cave /* Locate the Killer Rabbit */ int type; unsigned char *killerRabbit = LocateCreature(&caerbannog, "killer rabbit"); if( killerRabbit == 0 ){ puts("The Killer Rabbit of Caerbannog is out of town."); Tse, et al. Expires October 20, 2018 [Page 124] Internet-Draft AsciiRFC Specifications April 2018 return LOST_CREATURE; } /* Load Cave */ unsigned char *cave = LoadPlace(&caerbannog, "The Cave Of Caerbannog"); if( cave == 0 ){ puts("The Cave of Caerbannog must have moved."); return LOST_PLACE; } /* Lure the Killer Rabbit back into the Cave */ unsigned char *carrot = allocateObjectInPlace( carrot("fresh"), cave); if( carrot == 0 ){ puts("No carrot, no rabbit."); return LOST_LURE; } /* Finally, notify the Killer Rabbit to act */ return notifyCreature(killerRabbit, &carrot); ]]>
On the beast's encounter with the Knights of the Round Table, the following personnel engaged with it in combat:
  • Killed
    • Sir Bors
    • Sir Gawain
    • Sir Ector
  • Soiled Himself
      Tse, et al. Expires October 20, 2018 [Page 125] Internet-Draft AsciiRFC Specifications April 2018
    • Sir Robin
  • Panicked
    • King Arthur
  • Employed Ordnance
    • The Lector
    • Brother Maynard
  • Scoffed
    • Tim the Enchanter
Holy Hand Grenade of Antioch
The Holy Hand Grenade of Antioch (don't pull the pin)
The Sovereign's Orb made invisible
The solution to the impasse at the Cave of Caerbannog was provided by the successful deployment of the Holy Hand Grenade of Antioch (see ) . Any similarity between the Holy Hand Grenade of Antioch and the mythical Holy Spear of Antioch is purely intentional; any similarity between the Holy Hand Grenade of Antioch and the Sovereign's Orb of the United Kingdom (see ) is putatively fortuitous. Tse, et al. Expires October 20, 2018 [Page 127] Internet-Draft AsciiRFC Specifications April 2018
Holy Hand Grenade of Antioch
Ordnance deployed by Brother Maynard under the incantation of a lector, in order to dispense with the Foes of the Virtuous. See .
Holy Spear of Antioch
A supposed relic of the crucifixion of Jesus Christ, this is one of at least four claimed instances of the lance that pierced Christ's side. Its historical significance lies in inspiring crusaders to continue their siege of Antioch in 1098.
Sovereign's Orb of the United Kingdom
Part of the Crown Jewels of the United Kingdom, the Sovereign's Orb is a hollow gold sphere set with jewels and topped with a cross. It was made for Charles II in 1661. See .
The instructions in the Book of Armaments on the proper deployment of the Holy Hand Grenade of Antioch MAY be summarized as follows, although this summary SHALL NOT be used as a substitute for a reading from the Book of Armaments: Tse, et al. Expires October 20, 2018 [Page 128] Internet-Draft AsciiRFC Specifications April 2018
  1. Preamble: St Attila Benediction
  2. Feast of the People on Sundry Foods
    • Lambs
    • Sloths
    • Carp
    • Anchovies
    • Orangutangs
    • Breakfast Cereals
    • Fruit Bats
    • et hoc genus omne
  3. Take out the Holy Pin
  4. The Count
    1. Count is to Three: no more, no less
    2. Not Four
    3. Nor Two, except if the count then proceeds to Three
    4. Five is Right Out
  5. Lob the Holy Hand Grenade of Antioch towards the Foe
  6. The Foe, being naughty in the LORD's sight, SHALL snuff it
This could also be represented in pseudocode as follows:
  1. Take out the Holy Pin
  2. The Count
  3. Lob the Holy Hand Grenade of Antioch towards the Foe
  4. Foe snuffs it
Dramatis PersonaeThe following human (more-or-less) protagonists were involved in the two incidents recounted as lore of the Knights of the Round Table: Tse, et al. Expires October 20, 2018 [Page 130] Internet-Draft AsciiRFC Specifications April 2018
French Castle Cave of Caerbannog
King Arthur
Patsy
Sir Bedevere the Wise
Sir Galahad the Pure
Sir Lancelot the Brave
Sir Robin the Not-quite-so-brave-as-Sir-Lancelot
French Guard with Outrageous Accent Tim the Enchanter
Other French Guards Brother Maynard
The Lector
not yet recruited Sir Bors
Sir Gawain
Sir Ector
Retinue of sundry knights Retinue of sundry more knights than at the French Castle
Past the Killer RabbitOnce the Killer Rabbit of Caerbannog () had been dispatched, the Knights of the Round Table uncovered the last words of Joseph of Arimathea, inscribed on the Cave of Caerbannog in Aramaic. While the precise Aramaic wording has not survived, we trust the following Hebrew subtitles will serve as an acceptable substitute: Tse, et al. Expires October 20, 2018 [Page 131] Internet-Draft AsciiRFC Specifications April 2018
כאן אולי ימצאו המילים האחרונות של יוסף .מארמתיה מי אשר יהיה אמיץ ובעל נפש טהורה יוכל למצוא את הגביע הקדוש בטירת .אאאאאאאה "Here may be found the last words of Joseph of Arimathea. He who is valiant and pure of spirit may find the Holy Grail in the castle of — Aaaargh."
IANA Considerations IANA might consider a registry to track the mythical, especially ravaging beasts, such as the Killer Rabbit, who haunt the Internet.
Security ConsiderationsDo not let the Killer Rabbit out under any circumstance. I repeat. Do not let the Killer Rabbit () out.
Normative References Tse, et al. Expires October 20, 2018 [Page 132] Internet-Draft AsciiRFC Specifications April 2018 Informative References Monty Python and the Holy Grail
A.3. Example 3: "An API For Calendar-Based Fortune Heuristics Services" in AsciiRFC This example is available in the following formats: o AsciiRFC [git-divination-cfapi] o Internet-Draft [I-D.divination-cfapi] o Text, RFC XML, PDF and HTML on the IETF Datatracker [datatracker-divination-cfapi] Tse, et al. Expires October 20, 2018 [Page 133] Internet-Draft AsciiRFC Specifications April 2018 A.3.1. In AsciiRFC = An API For Calendar-Based Fortune Heuristics Services Gabriel Destiny; Charise Luck :doctype: internet-draft :abbrev: Calendar Fortune Heuristics API :name: draft-divination-cfapi-00 :status: informational :ipr: trust200902 :area: Internet :submission-type: independent :intended-series: informational :revdate: 2018-03-23T00:00:00Z :lastname: Destiny :fullname: Gabriel Destiny :forename_initials: G. :organization: Divination Inc. :email: gabriel.destiny@ribose.com :street: 9288 N Divine Street :city: Dunn :code: 28334 :region: NC :country: United States of America :lastname_2: Luck :fullname_2: Charise Luck :forename_initials_2: C. :organization_2: Divination Inc. :email_2: charise.luck@ribose.com :street_2: 9288 N Divine Street :city_2: Dunn :code_2: 28334 :region_2: NC :country_2: United States of America [.comment] tag::sample[] // tag::sample[] [abstract] This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics. == Introduction Fortune-telling, the practice of predicting information about a person's life, is an activity practiced throughout history. Tse, et al. Expires October 20, 2018 [Page 134] Internet-Draft AsciiRFC Specifications April 2018 While there are myriad forms of fortune telling methodologies, this document applies to a particular form of service that provides fortune heuristics, commonly known as "luck", for a particular subject based on a calendar-based input. Since HTTP <> status codes are insufficient to convey information about fortune heuristics, this specification defines a simple JSON <> document format for this purpose. The response can be used by HTTP APIs to deliver results to non-human clients or to an end-user. == Conventions Used in This Document The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 <> <> when, and only when, they appear in all capitals, as shown here. The following definitions apply in this document: Well-known URI:: This specification makes use of the "well-known URI" feature of HTTP servers <> to provide a bootstrapping URI for the client usage of fortune heuristics services. Root of Fortune:: The service discovery endpoint that provides a URI list of available fortune heuristic endpoints available, in accordance with <>. == Fortune Heuristics Service Well-Known URI A well-known URI called "fortune" is registered by this specification for fortune heuristics services (see <>). Services complying with this document *SHOULD* have its well-known URI pointing (directly or through redirection) to the Root of Fortune. The Root of Fortune can be used by the client for service discovery, namely, the available calendar-based fortune heuristics services available on the server, as specified in <>. === Well-Known URI Redirection Servers *MUST* redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP <> (e.g., using a 301, 303, or 307 response). Tse, et al. Expires October 20, 2018 [Page 135] Internet-Draft AsciiRFC Specifications April 2018 Clients *MUST* handle HTTP redirects on the well-known URI. === Well-Known URI Cache Behavior Servers *SHOULD* set an appropriate Cache-Control header value (as according to <>) in the redirect response to set caching behavior as required by the type of response generated. == New HTTP Methods: SEEK and DIVINE This specification defines two new HTTP methods: "SEEK" and "DIVINE" methods for HTTP <>. While HTTP GET requests are treated equivalently as the "SEEK" and "DIVINE" requests, its usage is discouraged and therefore *SHOULD NOT* be used. Usage of these methods are defined in the sections below. == Defined Data Types: Date-Time Formats This specification defines a number of date-time formats as according to the conventions of <> for the unambiguous communication between client and server. The types defined are as follows. `DATETIME`:: As described in <>, with the addition that reduced accuracy representations described in <> are supported. Reduced accuracy date and times are accepted where a date or time component (2-digits long) is replaced by "--". + For example, the date time "2018-04---T01:02:00Z" represents the UTC time of 1:02am, on an unknown day within April of the year 2018. `DATE`:: As described in "DATETIME", but the "time" component will not be taken into account in the algorithm. [#service-discovery] == Fortune Heuristics Service Discovery [#root-of-fortune] Tse, et al. Expires October 20, 2018 [Page 136] Internet-Draft AsciiRFC Specifications April 2018 === Root of Fortune Path URI ("/") The Root of Fortune URI, defined as "/" in this document, is used for service discovery on types of calendar-based fortune heuristics available. An empty SEEK request with the "application/json" request type *MUST* be sent to this endpoint to retrieve the available endpoints. All other HTTP methods *MUST NOT* be supported at this URI. An example of such a response is as follows: [source,json] ---- HTTP/1.1 200 Success Content-Type: application/json Content-Language: en { "diviners" : [ "/astrology", "/bazi", ] } ---- A service discovery object *MUST* have the following members: `diviners`:: (JSON array) An array that contains endpoints that conform to this specification. All endpoints listed here are relative to the Root of Fortune path. For example, the path "/astrology" listed in the example has an endpoint path of "[root-of-fortune]/astrology", where "[root-of-fortune]" indicates the real path of the Root of Fortune. // end::sample[] [.comment] end::sample[] [#service-endpoint] == Fortune Heuristics Service Endpoint An endpoint offering fortune heuristics services *MUST* adhere to specifications in this section. Tse, et al. Expires October 20, 2018 [Page 137] Internet-Draft AsciiRFC Specifications April 2018 A service *MAY* implement multiple divination services based on different divination methods, such as the digital oracle shown in <>. [[digital-oracle]] .Dimensional Eye, a digital oracle that communicates through one button ==== [alt=An incarnation of the Dimensional Eye, in ASCII] .... __ __===^-\ __=== -\ __===- -\ __===- -\ ___===- -\ ===- ---__ -\ \\\ |||^^\ \__ -\ \\\ ||| \__ -\ \\\ ||| ______\_ -\ \\\ ||| _/-******\\__ -\ \\\ || /-****_****-\ \_ -\ \\\ || |-***/ \***-\ \_ -\ \\\ || |-***\___/***-| \ -\ \\\ || \-*********-/ __--/ -\ \\\ || \-******/__-- -\ \\\ || __-- -\ \\\ || __-- -\ \\\ ||__-- -\ \\\ -\ \\\ -\ \\\ -\ \\\ -\ \\\ __ -\ \\\ //##\\ -\ \\\ \\##// -\ \\\ ^^ __--==^ \\\ __--=== \\\ __--=== \\\ __--=== \\\ __--== \\= .... ==== [#endpoint-specification-request] === Service Specification Request Tse, et al. Expires October 20, 2018 [Page 138] Internet-Draft AsciiRFC Specifications April 2018 To retrieve capabilities and parameters of an endpoint complying with this specification, a service specification JSON object is returned. An empty SEEK request with the "application/json" request type *MUST* be sent to this endpoint to retrieve the service specification that describes parameters accepted by this endpoint. Two examples of such a response are given below. [source,json] ---- HTTP/1.1 200 Success Content-Type: application/json Content-Language: en { "description": "Gaze into your upcoming luck!", "details": "https://divine.example.com/manual/astrology-api", "parameters": { "birthday": { "type": "DATE", "description": "Your birth date in UTC" }, "targetDateBegin": { "type": "DATE", "description": "Start of the target date range to report on" }, "targetDateEnd": { "type": "DATE", "description": "End of the target date range to report on" }, "interval": { "values": { "D": "Daily", "M": "Monthly", "Y": "Yearly" }, "description": "Available intervals to report on." } } } ---- [source,json] ---- HTTP/1.1 200 Success Content-Type: application/json Content-Language: en Tse, et al. Expires October 20, 2018 [Page 139] Internet-Draft AsciiRFC Specifications April 2018 { "description": "Matches and mis-matches according to the " "Yin Yang and Five Elements techniques", "details": "https://divine.example.com/manual/bazi-api", "parameters": { "birthday": { "type": "DATETIME", "description": "Your birth date and time in UTC" }, "targetDateBegin": { "type": "DATETIME", "description": "Start of the target date/time range to report on" }, "targetDateEnd": { "type": "DATETIME", "description": "End of the target date/time range to report on" }, "interval": { "values": { "H": "Hourly", "D": "Daily", "M": "Monthly", "Y": "Yearly" }, "description": "Available intervals to report on." } } } ---- [#service-endpoint-specification] === Service Specification Object A service specification object *MUST* contain the following members. `description`:: (string) A short, human-readable summary of the fortune heuristic service at this endpoint. This *SHOULD* be a stable reference. `details`:: (URI, optional) A URI reference that provides further details for human consumption, such as API documentation that includes details of parameters accepted or response states. `parameters`:: (object, mandatory) An object that specifies what parameters are accepted by this endpoint. Each parameter key within this object specifies an accepted parameter name, and its value is a parameter Tse, et al. Expires October 20, 2018 [Page 140] Internet-Draft AsciiRFC Specifications April 2018 specification object, which is described below. A parameter specification object *SHOULD* contain the following members: `type`:: (string, optional) The value type accepted by this parameter. Value types are described in this document. This member is mutually exclusive with `values`. `description`:: (string, mandatory) The purpose of this parameter. `values`:: (object, optional) The accepted values of this parameter, unlisted values *SHOULD* not be accepted by the parameter. Each key within this object specifies an accepted value, and its value provides a description of the purpose of the value. [#endpoint-report] == Fortune Heuristics Report Request and Response [#endpoint-report-request] === Fortune Heuristics Report Request A request using the HTTP "DIVINE" method and the "application/json" type *MUST* be sent to the fortune heuristic endpoint to retrieve results for a fortune heuristic query. The request made *MUST* conform to the specifications of the endpoint, as retrieved via the "SEEK" method described in <>. An example of a request is provided below. [source] ---- URI: /divination/astrology Method: DIVINE Content-Type: application/json Content-Language: en { "birthday": "1976-02-11T00:00:00Z", "targetDateBegin": "2018-01-01T00:00:00Z", "targetDateEnd": "2019-01-01T00:00:00Z", "interval": "M" Tse, et al. Expires October 20, 2018 [Page 141] Internet-Draft AsciiRFC Specifications April 2018 } ---- [#endpoint-report-response] === Fortune Heuristics Report Response A fortune heuristic query using the "DIVINE" method triggers a response that contains a fortune heuristics report. A successful response returns a JSON object that *MUST* conform to the object structure described in this section. A report object *SHOULD* contain the following members: `type`:: (URI, mandatory) A URI that defines the type of the report located at the `report` key of this object. `report`:: (object, mandatory) An object that contains two keys, `intervals` and `events`. The `intervals` object contains an array of interval objects that matches the demanded intervals in the request within the target date range. The `events` object contains an array of significant event objects within the target date range. An example of a response is provided below. [source] ---- URI: /divination/astrology Method: DIVINE HTTP/1.1 200 Success Content-Type: application/json Content-Language: en { "type": "https://association-of.astrology/reports/monthly", "report": { "intervals": [ { "dateStart": "2018-01-01T00:00:00Z", "dateEnd": "2018-02-01T00:00:00Z", "categories": [ { "category": "https://divine.example.com/astrology/categories/health" Tse, et al. Expires October 20, 2018 [Page 142] Internet-Draft AsciiRFC Specifications April 2018 "value": 80, "description": "Charge ahead with excellent health." }, { "category": "https://divine.example.com/astrology/categories/love" "value": 70, "description": "Give a certain person or situation another try!" }, { "category": "https://divine.example.com/astrology/categories/finance" "value": 5, "description": "You've just realized that you don't have any cash on hand." } ] }, { "dateStart": "2018-02-01T00:00:00Z", "dateEnd": "2018-03-01T00:00:00Z", "..." }, "..." ], "events": [ { "dateStart": "2018-01-15T03:20:00", "dateEnd": "2018-01-16T20:22:15", "description": "The planet of growth and good luck, Jupiter will make a harmonious connection with power planet Pluto, helping you connect with influential people", "recommendation": "Engage in networking during this time." }, { "dateStart": "2018-03-22T00:12:40", "dateEnd": "2018-03-28T02:45:03", "description": "Communication planet Mercury enters your sign, which will find you in a busier and chattier mood.", "recommendation": "Take charge of work with your newfound energy." } "..." ] } } ---- Tse, et al. Expires October 20, 2018 [Page 143] Internet-Draft AsciiRFC Specifications April 2018 Fortune heuristic reports are created by a divination output that *MAY* requires quantitative interpretation. A sample representation of interpreting a graphical divination output is provided in <>. [[divination-message]] .Forty-nine yarrow sticks reveals a mystical message on fortune ==== [alt=A mystical pattern in ASCII] .... 0000000000000000000000000 0000000000000000000000001 G 1000000000000000000000000 0000000000000000000000011 R 1100000000000000000000000 0000000000000000000000111 A 1110000000000000000000000 0000000000000000000001111 C 1111000000000000000000000 0000000000000000000011111 E 1111100000000000000000000 0000000000000000000111111 , 1111110000000000000000000 0000000000000000001111111 1111111000000000000000000 0000000011111111111111111 M 1111111111111111100000000 0000000111111111111111111 E 1111111111111111110000000 0000001111111111111111111 R 1111111111111111111000000 0000011111111111111111111 C 1111111111111111111100000 0000111111111111111111111 Y 1111111111111111111110000 0001111111111111111111111 , 1111111111111111111111000 0011111111111111111111111 1111111111111111111111100 0111111111111111111111111 A 1111111111111111111111110 0000000000000000011111111 N 1111111100000000000000000 0000000000000000111111111 D 1111111110000000000000000 0000000000000001111111111 1111111111000000000000000 0000000000000011111111111 P 1111111111100000000000000 0000000000000111111111111 E 1111111111110000000000000 0000000000001111111111111 A 1111111111111000000000000 0000000000011111111111111 C 1111111111111100000000000 0000000000111111111111111 E 1111111111111110000000000 0000000001111111111111111 . 1111111111111111000000000 .... ==== [#endpoint-report-interval-obj] === Report Interval Object The `intervals` value of a report object contains a number of report intervals -- each representing a non-overlapping period of the selected interval length. When all of these intervals are put together, the combined period *MUST* fully cover the requested report target period. Tse, et al. Expires October 20, 2018 [Page 144] Internet-Draft AsciiRFC Specifications April 2018 An example interval object is shown below. [source,json] ---- { "dateStart": "2018-01-01T00:00:00Z", "dateEnd": "2018-02-01T00:00:00Z", "categories": [ { "category": "https://divine.example.com/astrology/categories/health" "value": 80, "description": "Charge ahead with your excellent health." }, { "category": "https://divine.example.com/astrology/categories/love" "value": 70, "description": "Give a certain person or situation another try!" }, { "category": "https://divine.example.com/astrology/categories/finance" "value": 5, "description": "You've just realized that you don't have any cash on hand." } ] } ---- An interval object *MUST* contain the following members: `dateStart`:: (datetime, mandatory) This value specifies the start of the period which this interval object applies to. `dateEnd`:: (datetime, mandatory) This value specifies the end of the period which this interval object applies to. In the given example, the `categories` key is an implementation specific object that details heuristic results returned by the selected algorithm. This *MAY* differ in different algorithms. [#endpoint-report-event-obj] === Report Events Object Tse, et al. Expires October 20, 2018 [Page 145] Internet-Draft AsciiRFC Specifications April 2018 The `events` value of a report object contains a number of event objects. Each event object represents an event relevant to the calculation of fortune heuristics during a target report period. These events *MAY* be of variable time lengths, and *MAY* be overlapping amongst each other. The following example demonstrates two event objects the service determines relevant to a user's query. [source,json] ---- { "dateStart": "2018-01-15T03:20:00", "dateEnd": "2018-01-16T20:22:15", "description": "The planet of growth and good luck, Jupiter will make a harmonious connection with power planet Pluto, helping you connect with influential people", "recommendation": "Engage in networking during this time." }, { "dateStart": "2018-03-22T00:12:40", "dateEnd": "2018-03-28T02:45:03", "description": "Communication planet Mercury enters your sign, which will find you in a busier and chattier mood.", "recommendation": "Take charge of work with your newfound energy." } ---- Similar to an interval object, an event object *MUST* contain the following members: `dateStart`:: (datetime, mandatory) This value specifies the start of the period described by the event. `dateEnd`:: (datetime, mandatory) This value specifies the end of the period described by the event. In the given example, the keys `description` and `recommendation` are implementation-specific details. This *MAY* differ in different algorithms. [#endpoint-report-errors] === Report Generation Errors This specification makes use of normal HTTP error codes with the Tse, et al. Expires October 20, 2018 [Page 146] Internet-Draft AsciiRFC Specifications April 2018 following extensions. Errors *MUST* be returned using the Problem JSON Structure as accordance with <>. 422 Unprocessable Entity:: For example, a malformed date-time parameter, or an illogical input, such as when the subject's birthday occurs after the report target date period. 473 Beyond Existing Capability:: The service determines that the outcome is too difficult to predict. For example, in the case where the calculation is too complex to complete in a certain time period. The service *SHOULD* issue this response code to indicate that the client should not try the same request again. 474 Outcome Impossible:: The service determines that the outcome is impossible. For example, when the algorithm determines that the subject will have deceased before the start of the requested target period. [#security] == Security Considerations * TLS <> and authenticated HTTP requests should be used to protect the DIVINE request and responses due to the personal nature of information transmitted. * A client *SHOULD* verify the identity of the server on every request to prevent impersonation or man-in-the-middle attacks, as data transmitted to and from the server is sensitive information, and at times critical information to the user. * Synchronization of client and server time *MUST* be well-considered in the implementation of this specification. A mismatch of client and server time *MAY* lead to algorithm miscalculations that can cause mistaken choices of a user that depends on the reliability of this system. [#iana] == IANA Considerations === Well-Known URI Registrations Tse, et al. Expires October 20, 2018 [Page 147] Internet-Draft AsciiRFC Specifications April 2018 This document defines a well-known URI using the registration procedure and template from <>. ==== "fortune" Well-Known URI Registration URI suffix:: fortune Change controller:: IETF Specification document(s):: This document Related information:: N/A. [.comment] tag::sample[] // begin::sample[] [bibliography] == Normative References ++++ Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Tse, et al. Expires October 20, 2018 [Page 148] Internet-Draft AsciiRFC Specifications April 2018 Defining Well-Known Uniform Resource Identifiers (URIs) This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. Hypertext Transfer Protocol (HTTP/1.1): Caching The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. Problem Details for HTTP APIs This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. Tse, et al. Expires October 20, 2018 [Page 150] Internet-Draft AsciiRFC Specifications April 2018 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. ++++ [bibliography] == Informative References Tse, et al. Expires October 20, 2018 [Page 151] Internet-Draft AsciiRFC Specifications April 2018 ++++ ISO/DIS 8601-1:2018, Data elements and interchange formats -- Information interchange -- Representation of dates and times -- Part 1: Basic rules ISO/IEC
http://www.iso.org
Date and Time on the Internet: Timestamps The Transport Layer Security (TLS) Protocol Version 1.2 Tse, et al. Expires October 20, 2018 [Page 152] Internet-Draft AsciiRFC Specifications April 2018 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] ++++ [appendix] == Acknowledgements The authors thank the following individuals for their valuable feedback on this specification, and commend them for making fortune heuristics more accessible for the benefit of mankind. // end::sample[] [.comment] end::sample[] A.4. Rendered as RFC XML v3 An API For Calendar-Based Fortune Heuristics Services Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America gabriel.destiny@ribose.com
Divination Inc.
9288 N Divine Street Dunn NC 28334 United States of America charise.luck@ribose.com
Internet This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics.
IntroductionFortune-telling, the practice of predicting information about a person’s life, is an activity practiced throughout history. While there are myriad forms of fortune telling methodologies, this document applies to a particular form of service that provides fortune heuristics, commonly known as "luck", for a particular subject based on a calendar-based input. Since HTTP status codes are insufficient to convey Tse, et al. Expires October 20, 2018 [Page 154] Internet-Draft AsciiRFC Specifications April 2018 information about fortune heuristics, this specification defines a simple JSON document format for this purpose. The response can be used by HTTP APIs to deliver results to non-human clients or to an end-user.
Conventions Used in This DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following definitions apply in this document:
Well-known URI
This specification makes use of the "well-known URI" feature of HTTP servers to provide a bootstrapping URI for the client usage of fortune heuristics services.
Root of Fortune
The service discovery endpoint that provides a URI list of available fortune heuristic endpoints available, in accordance with .
Fortune Heuristics Service Well-Known URIA well-known URI called "fortune" is registered by this specification for fortune heuristics services (see ). Services complying with this document SHOULD have its well-known URI pointing (directly or through redirection) to the Root of Fortune. The Root of Fortune can be used by the client for service discovery, namely, the available calendar-based fortune heuristics services available on the server, as specified in .
Well-Known URI RedirectionServers MUST redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP (e.g., using a 301, 303, or 307 response). Clients MUST handle HTTP redirects on the well-known URI.
Tse, et al. Expires October 20, 2018 [Page 155] Internet-Draft AsciiRFC Specifications April 2018
Well-Known URI Cache Behavior Servers SHOULD set an appropriate Cache-Control header value (as according to ) in the redirect response to set caching behavior as required by the type of response generated.
New HTTP Methods: SEEK and DIVINEThis specification defines two new HTTP methods: "SEEK" and "DIVINE" methods for HTTP . While HTTP GET requests are treated equivalently as the "SEEK" and "DIVINE" requests, its usage is discouraged and therefore SHOULD NOT be used. Usage of these methods are defined in the sections below.
Defined Data Types: Date-Time FormatsThis specification defines a number of date-time formats as according to the conventions of for the unambiguous communication between client and server. The types defined are as follows.
DATETIME
As described in , with the addition that reduced accuracy representations described in are supported. Reduced accuracy date and times are accepted where a date or time component (2-digits long) is replaced by "--". For example, the date time "2018-04---T01:02:00Z" represents the UTC time of 1:02am, on an unknown day within April of the year 2018.
DATE
As described in "DATETIME", but the "time" component will not be taken into account in the algorithm.
Fortune Heuristics Service Discovery Tse, et al. Expires October 20, 2018 [Page 156] Internet-Draft AsciiRFC Specifications April 2018
Root of Fortune Path URI ("/")The Root of Fortune URI, defined as "/" in this document, is used for service discovery on types of calendar-based fortune heuristics available. An empty SEEK request with the "application/json" request type MUST be sent to this endpoint to retrieve the available endpoints. All other HTTP methods MUST NOT be supported at this URI. An example of such a response is as follows:
A service discovery object MUST have the following members:
diviners
(JSON array) An array that contains endpoints that conform to this specification. All endpoints listed here are relative to the Root of Fortune path. For example, the path "/astrology" listed in the example has an endpoint path of "[root-of-fortune]/astrology", where "[root-of-fortune]" indicates the real path of the Root of Fortune.
Fortune Heuristics Service EndpointAn endpoint offering fortune heuristics services MUST adhere to specifications in this section. Tse, et al. Expires October 20, 2018 [Page 157] Internet-Draft AsciiRFC Specifications April 2018 A service MAY implement multiple divination services based on different divination methods, such as the digital oracle shown in .
Dimensional Eye, a digital oracle that communicates through one button
Service Specification RequestTo retrieve capabilities and parameters of an endpoint complying with this specification, a service specification JSON object is returned. Tse, et al. Expires October 20, 2018 [Page 158] Internet-Draft AsciiRFC Specifications April 2018 An empty SEEK request with the "application/json" request type MUST be sent to this endpoint to retrieve the service specification that describes parameters accepted by this endpoint. Two examples of such a response are given below.
Service Specification ObjectA service specification object MUST contain the following members.
description
(string) A short, human-readable summary of the fortune heuristic service at this endpoint. This SHOULD be a stable reference.
details
(URI, optional) A URI reference that provides further details for human consumption, such as API documentation that includes details of parameters accepted or response states.
parameters
(object, mandatory) An object that specifies what parameters are accepted by this endpoint. Each parameter key within this object Tse, et al. Expires October 20, 2018 [Page 160] Internet-Draft AsciiRFC Specifications April 2018 specifies an accepted parameter name, and its value is a parameter specification object, which is described below.
A parameter specification object SHOULD contain the following members:
type
(string, optional) The value type accepted by this parameter. Value types are described in this document. This member is mutually exclusive with values.
description
(string, mandatory) The purpose of this parameter.
values
(object, optional) The accepted values of this parameter, unlisted values SHOULD not be accepted by the parameter. Each key within this object specifies an accepted value, and its value provides a description of the purpose of the value.
Fortune Heuristics Report Request and Response
Fortune Heuristics Report RequestA request using the HTTP "DIVINE" method and the "application/json" type MUST be sent to the fortune heuristic endpoint to retrieve results for a fortune heuristic query. The request made MUST conform to the specifications of the endpoint, as retrieved via the "SEEK" method described in . An example of a request is provided below.
Fortune Heuristics Report ResponseA fortune heuristic query using the "DIVINE" method triggers a response that contains a fortune heuristics report. A successful response returns a JSON object that MUST conform to the object structure described in this section. A report object SHOULD contain the following members:
type
(URI, mandatory) A URI that defines the type of the report located at the report key of this object.
report
(object, mandatory) An object that contains two keys, intervals and events. The intervals object contains an array of interval objects that matches the demanded intervals in the request within the target date range. The events object contains an array of significant event objects within the target date range.
An example of a response is provided below.
Fortune heuristic reports are created by a divination output that MAY requires quantitative interpretation. A sample representation of interpreting a graphical divination output is provided in .
Forty-nine yarrow sticks reveals a mystical message on fortune
Report Interval ObjectThe intervals value of a report object contains a number of report Tse, et al. Expires October 20, 2018 [Page 164] Internet-Draft AsciiRFC Specifications April 2018 intervals — each representing a non-overlapping period of the selected interval length. When all of these intervals are put together, the combined period MUST fully cover the requested report target period. An example interval object is shown below.
An interval object MUST contain the following members:
dateStart
(datetime, mandatory) This value specifies the start of the period which this interval object applies to.
dateEnd
(datetime, mandatory) This value specifies the end of the period Tse, et al. Expires October 20, 2018 [Page 165] Internet-Draft AsciiRFC Specifications April 2018 which this interval object applies to.
In the given example, the categories key is an implementation specific object that details heuristic results returned by the selected algorithm. This MAY differ in different algorithms.
Report Events ObjectThe events value of a report object contains a number of event objects. Each event object represents an event relevant to the calculation of fortune heuristics during a target report period. These events MAY be of variable time lengths, and MAY be overlapping amongst each other. The following example demonstrates two event objects the service determines relevant to a user’s query.
Similar to an interval object, an event object MUST contain the following members:
dateStart
(datetime, mandatory) This value specifies the start of the period described by the event.
dateEnd
Tse, et al. Expires October 20, 2018 [Page 166] Internet-Draft AsciiRFC Specifications April 2018
(datetime, mandatory) This value specifies the end of the period described by the event.
In the given example, the keys description and recommendation are implementation-specific details. This MAY differ in different algorithms.
Report Generation ErrorsThis specification makes use of normal HTTP error codes with the following extensions. Errors MUST be returned using the Problem JSON Structure as accordance with .
422 Unprocessable Entity
For example, a malformed date-time parameter, or an illogical input, such as when the subject’s birthday occurs after the report target date period.
473 Beyond Existing Capability
The service determines that the outcome is too difficult to predict. For example, in the case where the calculation is too complex to complete in a certain time period. The service SHOULD issue this response code to indicate that the client should not try the same request again.
474 Outcome Impossible
The service determines that the outcome is impossible. For example, when the algorithm determines that the subject will have deceased before the start of the requested target period.
Security Considerations
  • TLS and authenticated HTTP requests should be used to protect the DIVINE request and responses due to the personal nature of information transmitted.
  • A client SHOULD verify the identity of the server on every request to prevent impersonation or man-in-the-middle attacks, as data transmitted to and from the server is sensitive information, and at times critical information to the user.
  • Synchronization of client and server time MUST be Tse, et al. Expires October 20, 2018 [Page 167] Internet-Draft AsciiRFC Specifications April 2018 well-considered in the implementation of this specification. A mismatch of client and server time MAY lead to algorithm miscalculations that can cause mistaken choices of a user that depends on the reliability of this system.
IANA Considerations
Well-Known URI RegistrationsThis document defines a well-known URI using the registration procedure and template from .
"fortune" Well-Known URI Registration
URI suffix
fortune
Change controller
IETF
Specification document(s)
This document
Related information
N/A.
Normative References Informative References ISO/DIS 8601-1:2018, Data elements and interchange formats -- Information interchange -- Representation of dates and times -- Part 1: Basic rules ISO/IEC
http://www.iso.org
AcknowledgementsThe authors thank the following individuals for their valuable feedback on this specification, and commend them for making fortune heuristics more accessible for the benefit of mankind. Tse, et al. Expires October 20, 2018 [Page 169] Internet-Draft AsciiRFC Specifications April 2018
Appendix B. Acknowledgements The authors would like to thank the following persons for their valuable advice and input. o Adrian Farrel for his comprehensive review of the document and numerous beneficial suggestions. Authors' Addresses Ronald Henry Tse Ribose Suite 1111, 1 Pedder Street Central, Hong Kong Hong Kong Email: ronald.tse@ribose.com URI: https://www.ribose.com Nick Nicholas Ribose Australia Email: nick.nicholas@ribose.com URI: https://www.ribose.com Jeffrey Lau Ribose Suite 1111, 1 Pedder Street Central, Hong Kong Hong Kong Email: jeffrey.lau@ribose.com URI: https://www.ribose.com Tse, et al. Expires October 20, 2018 [Page 170] Internet-Draft AsciiRFC Specifications April 2018 Paolo Brasolin Ribose Italy Email: paolo.brasolin@ribose.com URI: https://www.ribose.com Tse, et al. Expires October 20, 2018 [Page 171] ./rfc-index.xml0000644000764400076440006142750713760153603013002 0ustar iustyiusty BCP0001 BCP0002 BCP0003 RFC1915 BCP0004 RFC1917 BCP0005 RFC1918 BCP0006 RFC1930 RFC6996 RFC7300 BCP0007 RFC2008 BCP0008 RFC2014 BCP0009 RFC2026 RFC5657 RFC6410 RFC7100 RFC7127 RFC7475 RFC8789 BCP0010 RFC8713 RFC8788 BCP0011 RFC2028 BCP0012 BCP0013 RFC4289 RFC6838 BCP0014 RFC2119 RFC8174 BCP0015 RFC2148 BCP0016 RFC2182 BCP0017 RFC2219 BCP0018 RFC2277 BCP0019 RFC2978 BCP0020 RFC2317 BCP0021 RFC2350 BCP0022 RFC2360 BCP0023 RFC2365 BCP0024 RFC2379 BCP0025 RFC2418 RFC3934 RFC7776 RFC8716 BCP0026 RFC8126 BCP0027 RFC2438 BCP0028 RFC2488 BCP0029 RFC2489 BCP0030 RFC2505 BCP0031 RFC2506 BCP0032 RFC2606 BCP0033 RFC2611 BCP0034 RFC2644 BCP0035 RFC7595 BCP0036 RFC2736 BCP0037 RFC2780 RFC5237 BCP0038 RFC2827 BCP0039 RFC2850 BCP0040 RFC7720 BCP0041 RFC2914 RFC7141 BCP0042 RFC6895 BCP0043 RFC2939 BCP0044 RFC2964 BCP0045 RFC3005 BCP0046 RFC3013 BCP0047 RFC4647 RFC5646 BCP0048 RFC3150 BCP0049 RFC3152 BCP0050 RFC3155 BCP0051 RFC5771 BCP0052 RFC3172 BCP0053 RFC3180 BCP0054 RFC7154 BCP0055 RFC3227 BCP0056 RFC3205 BCP0057 RFC3228 BCP0058 RFC3233 BCP0059 RFC3349 BCP0060 RFC3360 BCP0061 RFC3365 BCP0062 RFC3366 BCP0063 RFC3372 BCP0064 RFC4520 BCP0065 RFC3405 BCP0067 RFC5727 RFC7957 BCP0068 RFC3438 BCP0069 RFC3449 BCP0070 RFC3470 BCP0071 RFC3481 BCP0072 RFC3552 BCP0073 RFC3553 BCP0074 RFC3584 BCP0075 RFC3665 BCP0076 RFC3666 BCP0077 RFC3677 BCP0078 RFC5378 BCP0079 RFC8179 BCP0080 RFC3681 BCP0081 RFC3688 BCP0082 RFC3692 BCP0083 RFC3683 BCP0084 RFC3704 RFC8704 BCP0085 RFC3725 BCP0086 RFC3766 BCP0087 RFC3785 BCP0088 RFC3818 BCP0089 RFC3819 BCP0090 RFC3864 BCP0091 RFC3901 BCP0092 RFC5742 BCP0093 RFC3933 BCP0094 BCP0095 RFC3935 BCP0096 RFC3936 BCP0097 RFC3967 RFC4897 RFC8067 BCP0098 RFC3968 BCP0099 RFC3969 BCP0100 RFC7120 BCP0101 RFC8711 RFC8714 RFC8717 BCP0102 RFC4052 BCP0103 RFC4053 BCP0104 RFC4084 BCP0105 RFC4085 BCP0106 RFC4086 BCP0107 RFC4107 BCP0108 RFC4148 BCP0109 RFC4159 BCP0110 RFC4170 BCP0111 RFC4181 RFC4841 BCP0112 RFC4222 BCP0114 RFC4384 BCP0115 BCP0116 RFC4446 BCP0117 RFC4497 BCP0118 RFC4521 BCP0119 RFC4579 BCP0120 RFC4608 BCP0121 RFC4611 BCP0122 RFC4632 BCP0123 RFC4697 BCP0124 RFC4774 BCP0125 RFC4775 BCP0126 RFC4786 BCP0127 RFC4787 RFC6888 RFC7857 BCP0128 RFC4928 BCP0129 RFC4929 BCP0130 RFC4940 BCP0131 RFC4961 BCP0132 RFC4962 BCP0133 RFC5033 BCP0134 RFC5068 BCP0135 RFC5135 BCP0136 RFC5266 BCP0137 RFC5137 BCP0138 RFC5248 BCP0139 RFC5249 BCP0140 RFC5358 BCP0141 RFC7042 BCP0142 RFC5382 BCP0143 RFC5383 BCP0144 RFC5359 BCP0145 RFC8085 BCP0146 RFC5406 BCP0147 RFC5407 BCP0148 RFC5508 BCP0149 RFC5589 BCP0150 RFC5597 BCP0151 RFC5615 BCP0152 RFC5625 BCP0153 RFC6598 RFC6890 RFC8190 BCP0154 RFC5774 BCP0155 RFC5855 BCP0156 RFC6056 BCP0157 RFC6177 BCP0158 RFC6158 BCP0159 RFC6191 BCP0160 RFC6280 BCP0161 RFC6291 BCP0162 RFC6302 BCP0163 RFC6303 RFC7793 BCP0164 RFC6328 BCP0165 RFC6335 RFC7605 BCP0166 RFC6365 BCP0167 RFC6377 BCP0168 RFC6398 BCP0169 RFC6382 BCP0170 RFC6390 BCP0171 RFC6441 BCP0172 RFC6472 BCP0173 RFC6484 RFC7382 BCP0174 RFC6489 BCP0175 RFC6557 BCP0176 RFC6576 BCP0177 RFC6540 BCP0178 RFC6648 BCP0179 RFC6649 BCP0180 RFC6853 BCP0181 RFC6881 BCP0182 RFC6916 BCP0183 RFC6963 BCP0184 RFC7013 BCP0185 RFC7115 BCP0186 RFC7126 BCP0187 RFC7227 BCP0188 RFC7258 BCP0189 RFC7279 BCP0190 RFC8820 BCP0191 RFC7319 BCP0193 RFC7423 BCP0194 RFC7454 BCP0195 RFC7525 BCP0196 RFC7526 BCP0197 RFC7567 BCP0198 RFC7608 BCP0199 RFC7610 BCP0200 RFC1984 BCP0201 RFC7696 BCP0202 RFC7772 BCP0203 RFC7803 BCP0204 RFC7934 BCP0205 RFC7942 BCP0206 RFC7926 BCP0207 RFC8027 BCP0208 RFC8084 BCP0209 RFC8109 BCP0210 RFC8180 BCP0211 RFC8207 BCP0212 RFC8252 BCP0213 RFC8313 BCP0214 RFC8327 BCP0215 RFC8340 BCP0216 RFC8407 BCP0217 RFC8421 BCP0218 RFC8429 BCP0219 RFC8499 BCP0220 RFC8504 BCP0221 RFC8521 BCP0222 RFC8552 RFC8553 BCP0223 RFC8633 BCP0224 RFC8634 BCP0225 RFC8725 BCP0226 RFC8718 RFC8719 BCP0227 RFC8758 BCP0229 RFC8815 BCP0230 RFC8900 BCP0231 RFC8906 BCP0232 RFC8932 BCP0233 RFC8961 FYI0002 RFC1470 FYI0003 RFC1175 FYI0004 RFC2664 FYI0005 RFC1178 FYI0006 RFC1198 FYI0007 RFC1207 FYI0008 RFC2196 FYI0009 RFC1336 FYI0010 RFC1402 FYI0011 RFC2116 FYI0012 RFC1302 FYI0013 RFC1308 FYI0014 RFC1309 FYI0015 RFC1355 FYI0016 RFC1359 FYI0018 RFC1983 FYI0019 RFC1463 FYI0020 RFC1462 FYI0021 RFC1491 FYI0022 RFC1941 FYI0023 RFC1580 FYI0024 RFC1635 FYI0025 RFC1689 FYI0026 RFC1709 FYI0027 RFC1713 FYI0028 RFC1855 FYI0029 RFC2007 FYI0030 RFC2151 FYI0031 RFC2150 FYI0032 RFC2235 FYI0033 RFC2398 FYI0034 RFC2504 FYI0035 RFC2635 FYI0036 RFC4949 FYI0037 RFC2901 FYI0038 RFC3098 RFC0001 Host Software S. Crocker April 1969 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0001 RFC0002 Host software B. Duvall April 1969 ASCII PDF HTML 10 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=2 10.17487/RFC0002 RFC0003 Documentation conventions S.D. Crocker April 1969 ASCII HTML 2 RFC0010 UNKNOWN UNKNOWN Legacy 10.17487/RFC0003 RFC0004 Network timetable E.B. Shapiro March 1969 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0004 RFC0005 Decode Encode Language (DEL) J. Rulifson June 1969 ASCII HTML 17 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=5 10.17487/RFC0005 RFC0006 Conversation with Bob Kahn S.D. Crocker April 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0006 RFC0007 Host-IMP interface G. Deloche May 1969 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0007 RFC0008 ARPA Network Functional Specifications G. Deloche May 1969 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0008 RFC0009 Host Software G. Deloche May 1969 PDF HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0009 RFC0010 Documentation conventions S.D. Crocker July 1969 ASCII HTML 3 RFC0003 RFC0016 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0010 RFC0011 Implementation of the Host - Host Software Procedures in GORDO G. Deloche August 1969 ASCII PDF HTML 23 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0011 RFC0012 IMP-Host interface flow diagrams M. Wingfield August 1969 ASCII PS PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0012 RFC0013 Zero Text Length EOF Message V. Cerf August 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0013 RFC0014 RFC0015 Network subsystem for time sharing hosts C.S. Carr September 1969 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0015 RFC0016 M.I.T S. Crocker August 1969 ASCII HTML 1 RFC0010 RFC0024 RFC0024 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0016 RFC0017 Some questions re: Host-IMP Protocol J.E. Kreznar August 1969 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0017 RFC0018 IMP-IMP and HOST-HOST Control Links V. Cerf September 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0018 RFC0019 Two protocol suggestions to reduce congestion at swap bound nodes J.E. Kreznar October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0019 RFC0020 ASCII format for network interchange V.G. Cerf October 1969 ASCII PDF HTML 9 STD0080 INTERNET STANDARD UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=20 10.17487/RFC0020 RFC0021 Network meeting V.G. Cerf October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0021 RFC0022 Host-host control message formats V.G. Cerf October 1969 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0022 RFC0023 Transmission of Multiple Control Messages G. Gregg October 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0023 RFC0024 Documentation Conventions S.D. Crocker November 1969 ASCII HTML 3 RFC0016 RFC0010 RFC0016 RFC0027 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0024 RFC0025 No High Link Numbers S.D. Crocker October 1969 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0025 RFC0026 RFC0027 Documentation Conventions S.D. Crocker December 1969 ASCII HTML 3 RFC0010 RFC0016 RFC0024 RFC0030 UNKNOWN UNKNOWN Legacy 10.17487/RFC0027 RFC0028 Time Standards W.K. English January 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0028 RFC0029 Response to RFC 28 R.E. Kahn January 1970 ASCII HTML 1 RFC0028 UNKNOWN UNKNOWN Legacy 10.17487/RFC0029 RFC0030 Documentation Conventions S.D. Crocker February 1970 ASCII HTML 3 RFC0010 RFC0016 RFC0024 RFC0027 UNKNOWN UNKNOWN Legacy 10.17487/RFC0030 RFC0031 Binary Message Forms in Computer D. Bobrow W.R. Sutherland February 1968 ASCII HTML 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=31 10.17487/RFC0031 RFC0032 Some Thoughts on SRI's Proposed Real Time Clock J. Cole February 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0032 RFC0033 New Host-Host Protocol S.D. Crocker February 1970 ASCII HTML 19 RFC0011 RFC0036 RFC0047 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=33 10.17487/RFC0033 RFC0034 Some Brief Preliminary Notes on the Augmentation Research Center Clock W.K. English February 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0034 RFC0035 Network Meeting S.D. Crocker March 1970 ASCII HTML 1 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0035 RFC0036 Protocol Notes S.D. Crocker March 1970 ASCII HTML 8 RFC0033 RFC0039 RFC0044 UNKNOWN UNKNOWN Legacy 10.17487/RFC0036 RFC0037 Network Meeting Epilogue, etc S.D. Crocker March 1970 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0037 RFC0038 Comments on Network Protocol from NWG/RFC #36 S.M. Wolfe March 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0038 RFC0039 Comments on Protocol Re: NWG/RFC #36 E. Harslem J.F. Heafner March 1970 ASCII HTML 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0039 RFC0040 More Comments on the Forthcoming Protocol E. Harslem J.F. Heafner March 1970 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0040 RFC0041 IMP-IMP Teletype Communication J.T. Melvin March 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0041 RFC0042 Message Data Types E. Ancona March 1970 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0042 RFC0043 Proposed Meeting A.G. Nemeth April 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0043 RFC0044 Comments on NWG/RFC 33 and 36 A. Shoshani R. Long A. Landsberg April 1970 ASCII HTML 3 RFC0036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0044 RFC0045 New Protocol is Coming J. Postel S.D. Crocker April 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0045 RFC0046 ARPA Network protocol notes E. Meyer April 1970 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0046 RFC0047 BBN's Comments on NWG/RFC #33 J. Postel S. Crocker April 1970 ASCII HTML 4 RFC0033 UNKNOWN UNKNOWN Legacy 10.17487/RFC0047 RFC0048 Possible protocol plateau J. Postel S.D. Crocker April 1970 ASCII HTML 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0048 RFC0049 Conversations with S. Crocker (UCLA) E. Meyer April 1970 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0049 RFC0050 Comments on the Meyer Proposal E. Harslen J. Heafner April 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0050 RFC0051 Proposal for a Network Interchange Language M. Elie May 1970 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0051 RFC0052 Updated distribution list J. Postel S.D. Crocker July 1970 ASCII HTML 3 RFC0069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0052 RFC0053 Official protocol mechanism S.D. Crocker June 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0053 RFC0054 Official Protocol Proffering S.D. Crocker J. Postel J. Newkirk M. Kraley June 1970 ASCII HTML 9 RFC0057 UNKNOWN UNKNOWN Legacy 10.17487/RFC0054 RFC0055 Prototypical implementation of the NCP J. Newkirk M. Kraley J. Postel S.D. Crocker June 1970 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0055 RFC0056 Third Level Protocol: Logger Protocol E. Belove D. Black R. Flegal L.G. Farquar June 1970 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0056 RFC0057 Thoughts and Reflections on NWG/RFC 54 M. Kraley J. Newkirk June 1970 ASCII HTML 5 RFC0054 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=57 10.17487/RFC0057 RFC0058 Logical Message Synchronization T.P. Skinner June 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0058 RFC0059 Flow Control - Fixed Versus Demand Allocation E. Meyer June 1970 ASCII HTML 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=59 10.17487/RFC0059 RFC0060 A Simplified NCP Protocol R. Kalin July 1970 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0060 RFC0061 Note on Interprocess Communication in a Resource Sharing Computer Network D.C. Walden July 1970 ASCII HTML 18 RFC0062 UNKNOWN UNKNOWN Legacy 10.17487/RFC0061 RFC0062 Systems for Interprocess Communication in a Resource Sharing Computer Network D.C. Walden August 1970 ASCII HTML 20 RFC0061 UNKNOWN UNKNOWN Legacy 10.17487/RFC0062 RFC0063 Belated Network Meeting Report V.G. Cerf July 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0063 RFC0064 Getting rid of marking M. Elie July 1970 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0064 RFC0065 Comments on Host/Host Protocol document #1 D.C. Walden August 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0065 RFC0066 NIC - third level ideas and other noise S.D. Crocker August 1970 ASCII HTML 3 RFC0123 RFC0080 RFC0093 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=66 10.17487/RFC0066 RFC0067 Proposed Change to Host/IMP Spec to Eliminate Marking W.R. Crowther January 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0067 RFC0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM M. Elie August 1970 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0068 RFC0069 Distribution List Change for MIT A.K. Bhushan September 1970 ASCII HTML 1 RFC0052 UNKNOWN UNKNOWN Legacy 10.17487/RFC0069 RFC0070 Note on Padding S.D. Crocker October 1970 ASCII HTML 9 RFC0228 UNKNOWN UNKNOWN Legacy 10.17487/RFC0070 RFC0071 Reallocation in Case of Input Error T. Schipper September 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0071 RFC0072 Proposed Moratorium on Changes to Network Protocol R.D. Bressler September 1970 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0072 RFC0073 Response to NWG/RFC 67 S.D. Crocker September 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0073 RFC0074 Specifications for Network Use of the UCSB On-Line System J.E. White October 1970 ASCII PDF HTML 9 RFC0217 RFC0225 UNKNOWN UNKNOWN Legacy 10.17487/RFC0074 RFC0075 Network Meeting S.D. Crocker October 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0075 RFC0076 Connection by name: User oriented protocol J. Bouknight J. Madden G.R. Grossman October 1970 ASCII HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0076 RFC0077 Network meeting report J. Postel November 1970 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0077 RFC0078 NCP Status Report: UCSB/Rand E. Harslem J.F. Heafner J.E. White October 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0078 RFC0079 Logger Protocol error E. Meyer November 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0079 RFC0080 Protocols and Data Formats E. Harslem J.F. Heafner December 1970 ASCII HTML 9 RFC0123 RFC0066 RFC0093 UNKNOWN UNKNOWN Legacy 10.17487/RFC0080 RFC0081 Request for Reference Information J. Bouknight December 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0081 RFC0082 Network Meeting Notes E. Meyer December 1970 ASCII HTML 18 UNKNOWN UNKNOWN Legacy 10.17487/RFC0082 RFC0083 Language-machine for data reconfiguration R.H. Anderson E. Harslem J.F. Heafner December 1970 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0083 RFC0084 List of NWG/RFC's 1-80 J.B. North December 1970 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0084 RFC0085 Network Working Group meeting S.D. Crocker December 1970 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0085 RFC0086 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display S.D. Crocker January 1971 ASCII HTML 6 RFC0125 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=86 10.17487/RFC0086 RFC0087 Topic for Discussion at the Next Network Working Group Meeting A. Vezza January 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0087 RFC0088 NETRJS: A third level protocol for Remote Job Entry R.T. Braden S.M. Wolfe January 1971 ASCII HTML 9 RFC0189 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=88 10.17487/RFC0088 RFC0089 Some historic moments in networking R.M. Metcalfe January 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=89 10.17487/RFC0089 RFC0090 CCN as a Network Service Center R.T. Braden January 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=90 10.17487/RFC0090 RFC0091 Proposed User-User Protocol G.H. Mealy December 1970 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0091 RFC0092 RFC0093 Initial Connection Protocol A.M. McKenzie January 1971 ASCII HTML 1 RFC0066 RFC0080 UNKNOWN UNKNOWN Legacy 10.17487/RFC0093 RFC0094 Some thoughts on Network Graphics E. Harslem J.F. Heafner February 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0094 RFC0095 Distribution of NWG/RFC's through the NIC S. Crocker February 1971 ASCII HTML 5 RFC0155 UNKNOWN UNKNOWN Legacy 10.17487/RFC0095 RFC0096 An Interactive Network Experiment to Study Modes of Access the Network Information Center R.W. Watson February 1971 ASCII HTML 5 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0096 RFC0097 First Cut at a Proposed Telnet Protocol J.T. Melvin R.W. Watson February 1971 ASCII PDF HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0097 RFC0098 Logger Protocol Proposal E. Meyer T. Skinner February 1971 ASCII HTML 10 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0098 RFC0099 Network Meeting P.M. Karp February 1971 ASCII HTML 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0099 RFC0100 Categorization and guide to NWG/RFCs P.M. Karp February 1971 ASCII HTML 37 UNKNOWN UNKNOWN Legacy 10.17487/RFC0100 RFC0101 Notes on the Network Working Group meeting, Urbana, Illinois, February 17, 1971 R.W. Watson February 1971 ASCII HTML 14 RFC0108 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0101 RFC0102 Output of the Host-Host Protocol glitch cleaning committee S.D. Crocker February 1971 ASCII HTML 4 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0102 RFC0103 Implementation of Interrupt Keys R.B. Kalin February 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0103 RFC0104 Link 191 J.B. Postel S.D. Crocker February 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0104 RFC0105 Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB J.E. White March 1971 ASCII HTML 9 RFC0217 UNKNOWN UNKNOWN Legacy 10.17487/RFC0105 RFC0106 User/Server Site Protocol Network Host Questionnaire T.C. O'Sullivan March 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0106 RFC0107 Output of the Host-Host Protocol Glitch Cleaning Committee R.D. Bressler S.D. Crocker W.R. Crowther G.R. Grossman R.S. Tomlinson J.E. White March 1971 ASCII HTML 12 RFC0102 RFC0111 RFC0124 RFC0132 RFC0154 RFC0179 UNKNOWN UNKNOWN Legacy 10.17487/RFC0107 RFC0108 Attendance list at the Urbana NWG meeting, February 17-19, 1971 R.W. Watson March 1971 ASCII HTML 2 RFC0101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0108 RFC0109 Level III Server Protocol for the Lincoln Laboratory 360/67 Host J. Winett March 1971 ASCII PDF HTML 12 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0109 RFC0110 Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts J. Winett March 1971 ASCII PDF HTML 4 RFC0135 UNKNOWN UNKNOWN Legacy 10.17487/RFC0110 RFC0111 Pressure from the Chairman S.D. Crocker March 1971 ASCII HTML 2 RFC0107 RFC0130 UNKNOWN UNKNOWN Legacy 10.17487/RFC0111 RFC0112 User/Server Site Protocol: Network Host Questionnaire T.C. O'Sullivan April 1971 ASCII PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0112 RFC0113 Network activity report: UCSB Rand E. Harslem J.F. Heafner J.E. White April 1971 ASCII HTML 2 RFC0227 UNKNOWN UNKNOWN Legacy 10.17487/RFC0113 RFC0114 File Transfer Protocol A.K. Bhushan April 1971 ASCII HTML 17 FTP RFC0133 RFC0141 RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0114 RFC0115 Some Network Information Center policies on handling documents R.W. Watson J.B. North April 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0115 RFC0116 Structure of the May NWG Meeting S.D. Crocker April 1971 ASCII HTML 1 RFC0099 RFC0131 RFC0156 UNKNOWN UNKNOWN Legacy 10.17487/RFC0116 RFC0117 Some comments on the official protocol J. Wong April 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0117 RFC0118 Recommendations for facility documentation R.W. Watson April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0118 RFC0119 Network Fortran Subprograms M. Krilanovich April 1971 ASCII PDF HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0119 RFC0120 Network PL1 subprograms M. Krilanovich April 1971 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0120 RFC0121 Network on-line operators M. Krilanovich April 1971 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0121 RFC0122 Network specifications for UCSB's Simple-Minded File System J.E. White April 1971 ASCII HTML 21 RFC0217 RFC0269 RFC0399 RFC0431 UNKNOWN UNKNOWN Legacy 10.17487/RFC0122 RFC0123 Proffered Official ICP S.D. Crocker April 1971 ASCII HTML 3 RFC0066 RFC0080 RFC0165 RFC0098 RFC0101 RFC0127 RFC0143 RFC0148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0123 RFC0124 Typographical error in RFC 107 J.T. Melvin April 1971 ASCII HTML 1 RFC0107 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=124 10.17487/RFC0124 RFC0125 Response to RFC 86: Proposal for Network Standard Format for a Graphics Data Stream J. McConnell April 1971 ASCII HTML 4 RFC0086 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0125 RFC0126 Graphics Facilities at Ames Research Center J. McConnell April 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0126 RFC0127 Comments on RFC 123 J. Postel April 1971 ASCII HTML 2 RFC0145 RFC0123 RFC0151 UNKNOWN UNKNOWN Legacy 10.17487/RFC0127 RFC0128 Bytes J. Postel April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0128 RFC0129 Request for comments on socket name structure E. Harslem J. Heafner E. Meyer April 1971 ASCII HTML 6 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0129 RFC0130 Response to RFC 111: Pressure from the chairman J.F. Heafner April 1971 ASCII HTML 1 RFC0111 UNKNOWN UNKNOWN Legacy 10.17487/RFC0130 RFC0131 Response to RFC 116: May NWG meeting E. Harslem J.F. Heafner April 1971 ASCII HTML 3 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0131 RFC0132 Typographical Error in RFC 107 J.E. White April 1971 ASCII HTML 1 RFC0154 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0132 RFC0133 File Transfer and Error Recovery R.L. Sunberg April 1971 ASCII HTML 4 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0133 RFC0134 Network Graphics meeting A. Vezza April 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0134 RFC0135 Response to NWG/RFC 110 W. Hathaway April 1971 ASCII HTML 3 RFC0110 UNKNOWN UNKNOWN Legacy 10.17487/RFC0135 RFC0136 Host accounting and administrative procedures R.E. Kahn April 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0136 RFC0137 Telnet Protocol - a proposed document T.C. O'Sullivan April 1971 ASCII HTML 11 RFC0139 UNKNOWN UNKNOWN Legacy 10.17487/RFC0137 RFC0138 Status report on proposed Data Reconfiguration Service R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood April 1971 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0138 RFC0139 Discussion of Telnet Protocol T.C. O'Sullivan May 1971 ASCII HTML 11 RFC0137 RFC0158 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0139 RFC0140 Agenda for the May NWG meeting S.D. Crocker May 1971 ASCII HTML 4 RFC0149 UNKNOWN UNKNOWN Legacy 10.17487/RFC0140 RFC0141 Comments on RFC 114: A File Transfer Protocol E. Harslem J.F. Heafner April 1971 ASCII HTML 2 FTP RFC0114 UNKNOWN UNKNOWN Legacy 10.17487/RFC0141 RFC0142 Time-Out Mechanism in the Host-Host Protocol C. Kline J. Wong May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0142 RFC0143 Regarding proffered official ICP W. Naylor J. Wong C. Kline J. Postel May 1971 ASCII HTML 4 RFC0165 RFC0123 RFC0145 UNKNOWN UNKNOWN Legacy 10.17487/RFC0143 RFC0144 Data sharing on computer networks A. Shoshani April 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0144 RFC0145 Initial Connection Protocol Control Commands J. Postel May 1971 ASCII PS PDF HTML 2 RFC0127 RFC0165 RFC0143 UNKNOWN UNKNOWN Legacy 10.17487/RFC0145 RFC0146 Views on issues relevant to data sharing on computer networks P.M. Karp D.B. McKay D.C.M. Wood May 1971 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0146 RFC0147 Definition of a socket J.M. Winett May 1971 ASCII HTML 3 RFC0129 UNKNOWN UNKNOWN Legacy 10.17487/RFC0147 RFC0148 Comments on RFC 123 A.K. Bhushan May 1971 ASCII HTML 1 RFC0123 UNKNOWN UNKNOWN Legacy 10.17487/RFC0148 RFC0149 Best Laid Plans S.D. Crocker May 1971 ASCII HTML 1 RFC0140 UNKNOWN UNKNOWN Legacy 10.17487/RFC0149 RFC0150 Use of IPC Facilities: A Working Paper R.B. Kalin May 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0150 RFC0151 Comments on a proffered official ICP: RFCs 123, 127 A. Shoshani May 1971 ASCII HTML 2 RFC0127 UNKNOWN UNKNOWN Legacy 10.17487/RFC0151 RFC0152 SRI Artificial Intelligence status report M. Wilber May 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0152 RFC0153 SRI ARC-NIC status J.T. Melvin R.W. Watson May 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0153 RFC0154 Exposition Style S.D. Crocker May 1971 ASCII HTML 1 RFC0132 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0154 RFC0155 ARPA Network mailing lists J.B. North May 1971 ASCII HTML 13 RFC0095 RFC0168 UNKNOWN UNKNOWN Legacy 10.17487/RFC0155 RFC0156 Status of the Illinois site: Response to RFC 116 J. Bouknight April 1971 ASCII HTML 1 RFC0116 UNKNOWN UNKNOWN Legacy 10.17487/RFC0156 RFC0157 Invitation to the Second Symposium on Problems in the Optimization of Data Communications Systems V.G. Cerf May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0157 RFC0158 Telnet Protocol: A Proposed Document T.C. O'Sullivan May 1971 ASCII PDF HTML 11 RFC0495 RFC0139 RFC0318 RFC0393 UNKNOWN UNKNOWN Legacy 10.17487/RFC0158 RFC0159 RFC0160 RFC brief list Network Information Center. Stanford Research Institute May 1971 ASCII HTML 4 RFC0200 RFC0999 NIC6716 UNKNOWN UNKNOWN Legacy 10.17487/RFC0160 RFC0161 Solution to the race condition in the ICP A. Shoshani May 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0161 RFC0162 NETBUGGER3 M. Kampe May 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0162 RFC0163 Data transfer protocols V.G. Cerf May 1971 ASCII HTML 3 FTP DTP data manager UNKNOWN UNKNOWN Legacy 10.17487/RFC0163 RFC0164 Minutes of Network Working Group meeting, 5/16 through 5/19/71 J.F. Heafner May 1971 ASCII HTML 32 UNKNOWN UNKNOWN Legacy 10.17487/RFC0164 RFC0165 Proffered Official Initial Connection Protocol J. Postel May 1971 ASCII PDF HTML 5 RFC0145 RFC0143 RFC0123 NIC7101 UNKNOWN UNKNOWN Legacy 10.17487/RFC0165 RFC0166 Data Reconfiguration Service: An implementation specification R.H. Anderson V.G. Cerf E. Harslem J.F. Heafner J. Madden R.M. Metcalfe A. Shoshani J.E. White D.C.M. Wood May 1971 ASCII HTML 20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0166 RFC0167 Socket conventions reconsidered A.K. Bhushan R.M. Metcalfe J.M. Winett May 1971 ASCII HTML 4 RFC0129 RFC0147 UNKNOWN UNKNOWN Legacy 10.17487/RFC0167 RFC0168 ARPA Network mailing lists J.B. North May 1971 ASCII HTML 7 RFC0155 RFC0211 UNKNOWN UNKNOWN Legacy 10.17487/RFC0168 RFC0169 COMPUTER NETWORKS S.D. Crocker May 1971 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0169 RFC0170 RFC List by Number Network Information Center. Stanford Research Institute June 1971 ASCII HTML 6 RFC0200 UNKNOWN UNKNOWN Legacy 10.17487/RFC0170 RFC0171 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII HTML 9 FTP DTP RFC0264 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0171 RFC0172 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White June 1971 ASCII HTML 12 FTP RFC0265 RFC0114 RFC0238 UNKNOWN UNKNOWN Legacy 10.17487/RFC0172 RFC0173 Network Data Management Committee Meeting Announcement P.M. Karp D.B. McKay June 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0173 RFC0174 UCLA - Computer Science Graphics Overview J. Postel V.G. Cerf June 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0174 RFC0175 Comments on "Socket Conventions Reconsidered" E. Harslem J.F. Heafner June 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0175 RFC0176 Comments on "Byte size for connections" A.K. Bhushan R. Kanodia R.M. Metcalfe J. Postel June 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0176 RFC0177 Device independent graphical display description J. McConnell June 1971 ASCII HTML 9 RFC0125 RFC0181 UNKNOWN UNKNOWN Legacy 10.17487/RFC0177 RFC0178 Network graphic attention handling I.W. Cotton June 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0178 RFC0179 Link Number Assignments A.M. McKenzie June 1971 ASCII HTML 1 RFC0107 UNKNOWN UNKNOWN Legacy 10.17487/RFC0179 RFC0180 File system questionnaire A.M. McKenzie June 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0180 RFC0181 Modifications to RFC 177 J. McConnell July 1971 ASCII HTML 3 RFC0177 UNKNOWN UNKNOWN Legacy 10.17487/RFC0181 RFC0182 Compilation of list of relevant site reports J.B. North June 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0182 RFC0183 EBCDIC Codes and Their Mapping to ASCII J.M. Winett July 1971 ASCII PDF HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0183 RFC0184 Proposed graphic display modes K.C. Kelley July 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0184 RFC0185 NIC distribution of manuals and handbooks J.B. North July 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0185 RFC0186 Network graphics loader J.C. Michener July 1971 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0186 RFC0187 Network/440 Protocol Concept D.B. McKay D.P. Karp July 1971 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0187 RFC0188 Data management meeting announcement P.M. Karp D.B. McKay January 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0188 RFC0189 Interim NETRJS specifications R.T. Braden July 1971 ASCII HTML 19 RFC0088 RFC0599 RFC0283 UNKNOWN UNKNOWN Legacy 10.17487/RFC0189 RFC0190 DEC PDP-10-IMLAC communications system L.P. Deutsch July 1971 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0190 RFC0191 Graphics implementation and conceptualization at Augmentation Research Center C.H. Irby July 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0191 RFC0192 Some factors which a Network Graphics Protocol must consider R.W. Watson July 1971 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0192 RFC0193 NETWORK CHECKOUT E. Harslem J.F. Heafner July 1971 ASCII HTML 2 RFC0198 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0193 RFC0194 The Data Reconfiguration Service -- Compiler/Interpreter Implementation Notes V. Cerf E. Harslem J. Heafner B. Metcalfe J. White July 1971 ASCII HTML 18 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=194 10.17487/RFC0194 RFC0195 Data computers-data descriptions and access language G.H. Mealy July 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0195 RFC0196 Mail Box Protocol R.W. Watson July 1971 ASCII HTML 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0196 RFC0197 Initial Connection Protocol - Reviewed A. Shoshani E. Harslem July 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0197 RFC0198 Site Certification - Lincoln Labs 360/67 J.F. Heafner July 1971 ASCII HTML 1 RFC0193 RFC0214 RFC0193 UNKNOWN UNKNOWN Legacy 10.17487/RFC0198 RFC0199 Suggestions for a Network Data-Tablet Graphics Protocol T. Williams July 1971 ASCII PDF HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0199 RFC0200 RFC list by number J.B. North August 1971 ASCII HTML 7 RFC0170 RFC0160 NIC7724 UNKNOWN UNKNOWN Legacy 10.17487/RFC0200 RFC0201 RFC0202 Possible Deadlock in ICP S.M. Wolfe J. Postel July 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0202 RFC0203 Achieving reliable communication R.B. Kalin August 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0203 RFC0204 Sockets in use J. Postel August 1971 ASCII HTML 1 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0204 RFC0205 NETCRT - a character display protocol R.T. Braden August 1971 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0205 RFC0206 A User TELNET Description of an Initial Implementation J. White August 1971 ASCII PDF HTML 14 UNKNOWN UNKNOWN Legacy 10.17487/RFC0206 RFC0207 September Network Working Group meeting A. Vezza August 1971 ASCII HTML 2 RFC0212 UNKNOWN UNKNOWN Legacy 10.17487/RFC0207 RFC0208 Address tables A.M. McKenzie August 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0208 RFC0209 Host/IMP interface documentation B. Cosell August 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0209 RFC0210 Improvement of Flow Control W. Conrad August 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0210 RFC0211 ARPA Network Mailing Lists J.B. North August 1971 ASCII PDF HTML 13 RFC0168 RFC0300 UNKNOWN UNKNOWN Legacy 10.17487/RFC0211 RFC0212 NWG meeting on network usage Information Sciences Institute University of Southern California August 1971 ASCII HTML 2 RFC0207 RFC0222 UNKNOWN UNKNOWN Legacy 10.17487/RFC0212 RFC0213 IMP System change notification B. Cosell August 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0213 RFC0214 Network checkpoint E. Harslem August 1971 ASCII HTML 2 RFC0198 UNKNOWN UNKNOWN Legacy 10.17487/RFC0214 RFC0215 NCP, ICP, and Telnet: The Terminal IMP implementation A.M. McKenzie August 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0215 RFC0216 Telnet Access to UCSB's On-Line System J.E. White September 1971 ASCII PDF HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0216 RFC0217 Specifications changes for OLS, RJE/RJOR, and SMFS J.E. White September 1971 ASCII HTML 2 RFC0074 RFC0105 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0217 RFC0218 Changing the IMP status reporting facility B. Cosell September 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0218 RFC0219 User's View of the Datacomputer R. Winter September 1971 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0219 RFC0220 RFC0221 Mail Box Protocol: Version 2 R.W. Watson August 1971 ASCII HTML 5 RFC0196 RFC0278 UNKNOWN UNKNOWN Legacy 10.17487/RFC0221 RFC0222 Subject: System programmer's workshop R.M. Metcalfe September 1971 ASCII HTML 2 RFC0212 RFC0234 UNKNOWN UNKNOWN Legacy 10.17487/RFC0222 RFC0223 Network Information Center schedule for network users J.T. Melvin R.W. Watson September 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0223 RFC0224 Comments on Mailbox Protocol A.M. McKenzie September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0224 RFC0225 Rand/UCSB network graphics experiment E. Harslem R. Stoughton September 1971 ASCII HTML 5 RFC0074 UNKNOWN UNKNOWN Legacy 10.17487/RFC0225 RFC0226 Standardization of host mnemonics P.M. Karp September 1971 ASCII HTML 1 RFC0247 UNKNOWN UNKNOWN Legacy 10.17487/RFC0226 RFC0227 Data transfer rates (Rand/UCLA) J.F. Heafner E. Harslem September 1971 ASCII HTML 2 RFC0113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0227 RFC0228 Clarification D.C. Walden September 1971 ASCII HTML 1 RFC0070 UNKNOWN UNKNOWN Legacy 10.17487/RFC0228 RFC0229 Standard host names J. Postel September 1971 ASCII HTML 3 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0229 RFC0230 Toward reliable operation of minicomputer-based terminals on a TIP T. Pyke September 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0230 RFC0231 Service center standards for remote usage: A user's view J.F. Heafner E. Harslem September 1971 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0231 RFC0232 Postponement of network graphics meeting A. Vezza September 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0232 RFC0233 Standardization of host call letters A. Bhushan R. Metcalfe September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0233 RFC0234 Network Working Group meeting schedule A. Vezza October 1971 ASCII HTML 1 RFC0222 RFC0204 UNKNOWN UNKNOWN Legacy 10.17487/RFC0234 RFC0235 Site status E. Westheimer September 1971 ASCII HTML 5 RFC0240 UNKNOWN UNKNOWN Legacy 10.17487/RFC0235 RFC0236 Standard host names J. Postel September 1971 ASCII HTML 2 RFC0229 UNKNOWN UNKNOWN Legacy 10.17487/RFC0236 RFC0237 NIC view of standard host names R.W. Watson October 1971 ASCII HTML 1 RFC0273 UNKNOWN UNKNOWN Legacy 10.17487/RFC0237 RFC0238 Comments on DTP and FTP proposals R.T. Braden September 1971 ASCII HTML 2 FTP RFC0171 RFC0172 UNKNOWN UNKNOWN Legacy 10.17487/RFC0238 RFC0239 Host mnemonics proposed in RFC 226 (NIC 7625) R.T. Braden September 1971 ASCII HTML 1 RFC0226 RFC0229 RFC0236 UNKNOWN UNKNOWN Legacy 10.17487/RFC0239 RFC0240 Site Status A.M. McKenzie September 1971 ASCII HTML 4 RFC0235 RFC0252 UNKNOWN UNKNOWN Legacy 10.17487/RFC0240 RFC0241 Connecting computers to MLC ports A.M. McKenzie September 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0241 RFC0242 Data Descriptive Language for Shared Data L. Haibt A.P. Mullery July 1971 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0242 RFC0243 Network and data sharing bibliography A.P. Mullery October 1971 ASCII HTML 7 RFC0290 UNKNOWN UNKNOWN Legacy 10.17487/RFC0243 RFC0244 RFC0245 Reservations for Network Group meeting C. Falls October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0245 RFC0246 Network Graphics meeting A. Vezza October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0246 RFC0247 Proffered set of standard host names P.M. Karp October 1971 ASCII HTML 4 RFC0226 UNKNOWN UNKNOWN Legacy 10.17487/RFC0247 RFC0248 RFC0249 Coordination of equipment and supplies purchase R.F. Borelli October 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0249 RFC0250 Some thoughts on file transfer H. Brodie October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0250 RFC0251 Weather data D. Stern October 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0251 RFC0252 Network host status E. Westheimer October 1971 ASCII HTML 3 RFC0240 RFC0255 UNKNOWN UNKNOWN Legacy 10.17487/RFC0252 RFC0253 Second Network Graphics meeting details J.A. Moorer October 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0253 RFC0254 Scenarios for using ARPANET computers A. Bhushan October 1971 ASCII PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0254 RFC0255 Status of network hosts E. Westheimer October 1971 ASCII HTML 2 RFC0252 RFC0266 UNKNOWN UNKNOWN Legacy 10.17487/RFC0255 RFC0256 IMPSYS change notification B. Cosell November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0256 RFC0257 RFC0258 RFC0259 RFC0260 RFC0261 RFC0262 RFC0263 "Very Distant" Host interface A.M. McKenzie December 1971 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0263 RFC0264 The Data Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenize B. Sundberg D. Watson J. White January 1972 ASCII HTML 9 FTP DTP RFC0171 RFC0354 RFC0310 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0264 RFC0265 The File Transfer Protocol A. Bhushan B. Braden W. Crowther E. Harslem J. Heafner A. McKenzie J. Melvin B. Sundberg D. Watson J. White November 1971 ASCII HTML 12 FTP RFC0172 RFC0354 RFC0281 RFC0294 RFC0310 RFC0264 UNKNOWN UNKNOWN Legacy 10.17487/RFC0265 RFC0266 Network host status E. Westheimer November 1971 ASCII HTML 2 RFC0255 RFC0267 UNKNOWN UNKNOWN Legacy 10.17487/RFC0266 RFC0267 Network Host Status E. Westheimer November 1971 ASCII HTML 4 RFC0266 RFC0287 UNKNOWN UNKNOWN Legacy 10.17487/RFC0267 RFC0268 Graphics facilities information J. Postel November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0268 RFC0269 Some Experience with File Transfer H. Brodie December 1971 ASCII HTML 3 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0269 RFC0270 Correction to BBN Report No. 1822 (NIC NO 7958) A.M. McKenzie January 1972 ASCII PDF HTML 1 NIC7959 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=270 10.17487/RFC0270 RFC0271 IMP System change notifications B. Cosell January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0271 RFC0272 RFC0273 More on standard host names R.W. Watson October 1971 ASCII HTML 3 RFC0237 UNKNOWN UNKNOWN Legacy 10.17487/RFC0273 RFC0274 Establishing a local guide for network usage E. Forman November 1971 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0274 RFC0275 RFC0276 NIC course R.W. Watson November 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0276 RFC0277 RFC0278 Revision of the Mail Box Protocol A.K. Bhushan R.T. Braden E. Harslem J.F. Heafner A.M. McKenzie J.T. Melvin R.L. Sundberg R.W. Watson J.E. White November 1971 ASCII HTML 4 RFC0221 UNKNOWN UNKNOWN Legacy 10.17487/RFC0278 RFC0279 RFC0280 A Draft of Host Names R.W. Watson November 1971 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0280 RFC0281 Suggested addition to File Transfer Protocol A.M. McKenzie December 1971 ASCII HTML 8 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0281 RFC0282 Graphics meeting report M.A. Padlipsky December 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0282 RFC0283 NETRJT: Remote Job Service Protocol for TIPS R.T. Braden December 1971 ASCII HTML 9 RFC0189 UNKNOWN UNKNOWN Legacy 10.17487/RFC0283 RFC0284 RFC0285 Network graphics D. Huff December 1971 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0285 RFC0286 Network Library Information System E. Forman December 1971 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0286 RFC0287 Status of Network Hosts E. Westheimer December 1971 ASCII HTML 5 RFC0267 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0287 RFC0288 Network host status E. Westheimer January 1972 ASCII HTML 4 RFC0287 RFC0293 RFC0293 UNKNOWN UNKNOWN Legacy 10.17487/RFC0288 RFC0289 What we hope is an official list of host names R.W. Watson December 1971 ASCII HTML 3 RFC0384 UNKNOWN UNKNOWN Legacy 10.17487/RFC0289 RFC0290 Computer networks and data sharing: A bibliography A.P. Mullery January 1972 ASCII HTML 15 RFC0243 UNKNOWN UNKNOWN Legacy 10.17487/RFC0290 RFC0291 Data Management Meeting Announcement D.B. McKay January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0291 RFC0292 Graphics Protocol: Level 0 only J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer January 1972 ASCII HTML 10 RFC0493 UNKNOWN UNKNOWN Legacy 10.17487/RFC0292 RFC0293 Network Host Status E. Westheimer January 1972 ASCII HTML 4 RFC0288 RFC0298 RFC0288 UNKNOWN UNKNOWN Legacy 10.17487/RFC0293 RFC0294 The Use of "Set Data Type" Transaction in File Transfer Protocol A.K. Bhushan January 1972 ASCII HTML 2 FTP RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0294 RFC0295 Report of the Protocol Workshop, 12 October 1971 J. Postel January 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0295 RFC0296 DS-1 Display System D.E. Liddle January 1972 ASCII PDF HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0296 RFC0297 TIP Message Buffers D.C. Walden January 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0297 RFC0298 Network host status E. Westheimer February 1972 ASCII HTML 4 RFC0293 RFC0306 UNKNOWN UNKNOWN Legacy 10.17487/RFC0298 RFC0299 Information Management System D. Hopkin February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0299 RFC0300 ARPA Network mailing lists J.B. North January 1972 ASCII HTML 9 RFC0211 RFC0303 UNKNOWN UNKNOWN Legacy 10.17487/RFC0300 RFC0301 BBN IMP (#5) and NCC Schedule March 4, 1971 R. Alter February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0301 RFC0302 Exercising The ARPANET R.F. Bryan February 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0302 RFC0303 ARPA Network mailing lists Network Information Center. Stanford Research Institute March 1972 ASCII HTML 11 RFC0300 RFC0329 UNKNOWN UNKNOWN Legacy 10.17487/RFC0303 RFC0304 Data Management System Proposal for the ARPA Network D.B. McKay February 1972 ASCII PDF HTML 8 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=304 10.17487/RFC0304 RFC0305 Unknown Host Numbers R. Alter February 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0305 RFC0306 Network host status E. Westheimer February 1972 ASCII HTML 4 RFC0298 RFC0315 UNKNOWN UNKNOWN Legacy 10.17487/RFC0306 RFC0307 Using network Remote Job Entry E. Harslem February 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0307 RFC0308 ARPANET host availability data M. Seriff March 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0308 RFC0309 Data and File Transfer Workshop Announcement A.K. Bhushan March 1972 ASCII HTML 6 FTP DTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0309 RFC0310 Another Look at Data and File Transfer Protocols A.K. Bhushan April 1972 ASCII HTML 7 FTP RFC0264 RFC0265 UNKNOWN UNKNOWN Legacy 10.17487/RFC0310 RFC0311 New Console Attachments to the USCB Host R.F. Bryan February 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0311 RFC0312 Proposed Change in IMP-to-Host Protocol A.M. McKenzie March 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0312 RFC0313 Computer based instruction T.C. O'Sullivan March 1972 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0313 RFC0314 Network Graphics Working Group Meeting I.W. Cotton March 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0314 RFC0315 Network Host Status E. Westheimer March 1972 ASCII HTML 4 RFC0306 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0315 RFC0316 ARPA Network Data Management Working Group D.B. McKay A.P. Mullery February 1972 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0316 RFC0317 Official Host-Host Protocol Modification: Assigned Link Numbers J. Postel March 1972 ASCII HTML 1 RFC0604 UNKNOWN UNKNOWN Legacy 10.17487/RFC0317 RFC0318 Telnet Protocols J. Postel April 1972 ASCII HTML 16 RFC0158 RFC0435 RFC0139 RFC0158 UNKNOWN UNKNOWN Legacy 10.17487/RFC0318 RFC0319 Network Host Status E. Westheimer March 1972 ASCII HTML 4 RFC0315 RFC0326 UNKNOWN UNKNOWN Legacy 10.17487/RFC0319 RFC0320 Workshop on Hard Copy Line Graphics R. Reddy March 1972 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0320 RFC0321 CBI Networking Activity at MITRE P.M. Karp March 1972 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0321 RFC0322 Well known socket numbers V. Cerf J. Postel March 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0322 RFC0323 Formation of Network Measurement Group (NMG) V. Cerf March 1972 ASCII HTML 9 RFC0388 UNKNOWN UNKNOWN Legacy 10.17487/RFC0323 RFC0324 RJE Protocol meeting J. Postel April 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0324 RFC0325 Network Remote Job Entry program - NETRJS G. Hicks April 1972 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0325 RFC0326 Network Host Status E. Westheimer April 1972 ASCII HTML 4 RFC0330 RFC0319 UNKNOWN UNKNOWN Legacy 10.17487/RFC0326 RFC0327 Data and File Transfer workshop notes A.K. Bhushan April 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0327 RFC0328 Suggested Telnet Protocol Changes J. Postel April 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0328 RFC0329 ARPA Network Mailing Lists Network Information Center. Stanford Research Institute May 1972 ASCII HTML 13 RFC0303 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0329 RFC0330 Network Host Status E. Westheimer April 1972 ASCII HTML 3 RFC0326 RFC0332 UNKNOWN UNKNOWN Legacy 10.17487/RFC0330 RFC0331 IMP System Change Notification J.M. McQuillan April 1972 ASCII HTML 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0331 RFC0332 Network Host Status E. Westheimer April 1972 ASCII HTML 4 RFC0342 RFC0330 UNKNOWN UNKNOWN Legacy 10.17487/RFC0332 RFC0333 Proposed experiment with a Message Switching Protocol R.D. Bressler D. Murphy D.C. Walden May 1972 ASCII HTML 26 UNKNOWN UNKNOWN Legacy 10.17487/RFC0333 RFC0334 Network Use on May 8 A.M. McKenzie May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0334 RFC0335 New Interface - IMP/360 R.F. Bryan May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0335 RFC0336 Level 0 Graphic Input Protocol I.W. Cotton May 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0336 RFC0337 RFC0338 EBCDIC/ASCII Mapping for Network RJE R.T. Braden May 1972 ASCII PS PDF HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0338 RFC0339 MLTNET: A "Multi Telnet" Subsystem for Tenex R. Thomas May 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0339 RFC0340 Proposed Telnet Changes T.C. O'Sullivan May 1972 ASCII HTML 2 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0340 RFC0341 RFC0342 Network Host Status E. Westheimer May 1972 ASCII HTML 4 RFC0332 RFC0344 UNKNOWN UNKNOWN Legacy 10.17487/RFC0342 RFC0343 IMP System change notification A.M. McKenzie May 1972 ASCII HTML 2 RFC0331 RFC0359 UNKNOWN UNKNOWN Legacy 10.17487/RFC0343 RFC0344 Network Host Status E. Westheimer May 1972 ASCII HTML 4 RFC0342 RFC0353 UNKNOWN UNKNOWN Legacy 10.17487/RFC0344 RFC0345 Interest in Mixed Integer Programming (MPSX on NIC 360/91 at CCN) K.C. Kelley May 1972 ASCII HTML 1 MIP UNKNOWN UNKNOWN Legacy 10.17487/RFC0345 RFC0346 Satellite Considerations J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0346 RFC0347 Echo process J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0347 RFC0348 Discard Process J. Postel May 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0348 RFC0349 Proposed Standard Socket Numbers J. Postel May 1972 ASCII HTML 1 RFC0433 RFC0204 RFC0322 UNKNOWN UNKNOWN Legacy 10.17487/RFC0349 RFC0350 User Accounts for UCSB On-Line System R. Stoughton May 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0350 RFC0351 Graphics information form for the ARPANET graphics resources notebook D. Crocker June 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0351 RFC0352 TIP Site Information Form D. Crocker June 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0352 RFC0353 Network host status E. Westheimer June 1972 ASCII HTML 5 RFC0344 RFC0362 UNKNOWN UNKNOWN Legacy 10.17487/RFC0353 RFC0354 File Transfer Protocol A.K. Bhushan July 1972 ASCII HTML 25 FTP RFC0264 RFC0265 RFC0542 RFC0385 RFC0454 RFC0683 UNKNOWN UNKNOWN Legacy 10.17487/RFC0354 RFC0355 Response to NWG/RFC 346 J. Davidson June 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0355 RFC0356 ARPA Network Control Center R. Alter June 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0356 RFC0357 Echoing strategy for satellite links J. Davidson June 1972 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0357 RFC0358 RFC0359 Status of the Release of the New IMP System (2600) D.C. Walden June 1972 ASCII HTML 1 RFC0343 UNKNOWN UNKNOWN Legacy 10.17487/RFC0359 RFC0360 Proposed Remote Job Entry Protocol C. Holland June 1972 ASCII PDF HTML 18 RFC0407 UNKNOWN UNKNOWN Legacy 10.17487/RFC0360 RFC0361 Deamon Processes on Host 106 R.D. Bressler July 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0361 RFC0362 Network Host Status E. Westheimer June 1972 ASCII HTML 4 RFC0353 RFC0366 UNKNOWN UNKNOWN Legacy 10.17487/RFC0362 RFC0363 ARPA Network mailing lists Network Information Center. Stanford Research Institute August 1972 ASCII HTML 13 RFC0329 RFC0402 UNKNOWN UNKNOWN Legacy 10.17487/RFC0363 RFC0364 Serving remote users on the ARPANET M.D. Abrams July 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0364 RFC0365 Letter to All TIP Users D.C. Walden July 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0365 RFC0366 Network Host Status E. Westheimer July 1972 ASCII HTML 4 RFC0362 RFC0367 UNKNOWN UNKNOWN Legacy 10.17487/RFC0366 RFC0367 Network host status E. Westheimer July 1972 ASCII HTML 4 RFC0366 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0367 RFC0368 Comments on "Proposed Remote Job Entry Protocol" R.T. Braden July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0368 RFC0369 Evaluation of ARPANET services January-March, 1972 J.R. Pickens July 1972 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0369 RFC0370 Network Host Status E. Westheimer July 1972 ASCII HTML 5 RFC0367 RFC0376 UNKNOWN UNKNOWN Legacy 10.17487/RFC0370 RFC0371 Demonstration at International Computer Communications Conference R.E. Kahn July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0371 RFC0372 Notes on a Conversation with Bob Kahn on the ICCC R.W. Watson July 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0372 RFC0373 Arbitrary Character Sets J. McCarthy July 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0373 RFC0374 IMP System Announcement A.M. McKenzie July 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0374 RFC0375 RFC0376 Network Host Status E. Westheimer August 1972 ASCII HTML 5 RFC0370 UNKNOWN UNKNOWN Legacy 10.17487/RFC0376 RFC0377 Using TSO via ARPA Network Virtual Terminal R.T. Braden August 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0377 RFC0378 Traffic statistics (July 1972) A.M. McKenzie August 1972 ASCII HTML 3 RFC0391 UNKNOWN UNKNOWN Legacy 10.17487/RFC0378 RFC0379 Using TSO at CCN R. Braden August 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0379 RFC0380 RFC0381 Three aids to improved network operation J.M. McQuillan July 1972 ASCII HTML 4 RFC0394 UNKNOWN UNKNOWN Legacy 10.17487/RFC0381 RFC0382 Mathematical Software on the ARPA Network L. McDaniel August 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0382 RFC0383 RFC0384 Official site idents for organizations in the ARPA Network J.B. North August 1972 ASCII HTML 4 RFC0289 UNKNOWN UNKNOWN Legacy 10.17487/RFC0384 RFC0385 Comments on the File Transfer Protocol A.K. Bhushan August 1972 ASCII HTML 6 FTP RFC0354 RFC0414 UNKNOWN UNKNOWN Legacy 10.17487/RFC0385 RFC0386 Letter to TIP users-2 B. Cosell D.C. Walden August 1972 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0386 RFC0387 Some experiences in implementing Network Graphics Protocol Level 0 K.C. Kelley J. Meir August 1972 ASCII HTML 5 RFC0401 UNKNOWN UNKNOWN Legacy 10.17487/RFC0387 RFC0388 NCP statistics V. Cerf August 1972 ASCII HTML 5 RFC0323 UNKNOWN UNKNOWN Legacy 10.17487/RFC0388 RFC0389 UCLA Campus Computing Network Liaison Staff for ARPA Network B. Noble August 1972 ASCII HTML 2 RFC0423 UNKNOWN UNKNOWN Legacy 10.17487/RFC0389 RFC0390 TSO Scenario R.T. Braden September 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0390 RFC0391 Traffic statistics (August 1972) A.M. McKenzie September 1972 ASCII HTML 3 RFC0378 UNKNOWN UNKNOWN Legacy 10.17487/RFC0391 RFC0392 Measurement of host costs for transmitting network data G. Hicks B.D. Wessler September 1972 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0392 RFC0393 Comments on Telnet Protocol Changes J.M. Winett October 1972 ASCII HTML 4 RFC0109 RFC0139 RFC0158 RFC0318 RFC0328 UNKNOWN UNKNOWN Legacy 10.17487/RFC0393 RFC0394 Two Proposed Changes to the IMP-Host Protocol J.M. McQuillan September 1972 ASCII HTML 3 RFC0381 UNKNOWN UNKNOWN Legacy 10.17487/RFC0394 RFC0395 Switch Settings on IMPs and TIPs J.M. McQuillan October 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0395 RFC0396 Network Graphics Working Group Meeting - Second Iteration S. Bunch November 1972 ASCII HTML 1 RFC0474 UNKNOWN UNKNOWN Legacy 10.17487/RFC0396 RFC0397 RFC0398 UCSB Online Graphics J.R. Pickens E. Faeh September 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0398 RFC0399 SMFS Login and Logout M. Krilanovich September 1972 ASCII HTML 2 RFC0431 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0399 RFC0400 Traffic Statistics (September 1972) A.M. McKenzie October 1972 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0400 RFC0401 Conversion of NGP-0 Coordinates to Device Specific Coordinates J. Hansen October 1972 ASCII HTML 2 RFC0387 UNKNOWN UNKNOWN Legacy 10.17487/RFC0401 RFC0402 ARPA Network Mailing Lists J.B. North October 1972 ASCII HTML 16 RFC0363 UNKNOWN UNKNOWN Legacy 10.17487/RFC0402 RFC0403 Desirability of a Network 1108 Service G. Hicks January 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0403 RFC0404 Host Address Changes Involving Rand and ISI A.M. McKenzie October 1972 ASCII HTML 1 RFC0405 UNKNOWN UNKNOWN Legacy 10.17487/RFC0404 RFC0405 Correction to RFC 404 A.M. McKenzie October 1972 ASCII HTML 1 RFC0404 UNKNOWN UNKNOWN Legacy 10.17487/RFC0405 RFC0406 Scheduled IMP Software Releases J.M. McQuillan October 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0406 RFC0407 Remote Job Entry Protocol R.D. Bressler R. Guida A.M. McKenzie October 1972 ASCII HTML 21 RJE RFC0360 HISTORIC HISTORIC Legacy 10.17487/RFC0407 RFC0408 NETBANK A.D. Owen J. Postel October 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0408 RFC0409 Tenex interface to UCSB's Simple-Minded File System J.E. White December 1972 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0409 RFC0410 Removal of the 30-Second Delay When Hosts Come Up J.M. McQuillan November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0410 RFC0411 New MULTICS Network Software Features M.A. Padlipsky November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0411 RFC0412 User FTP Documentation G. Hicks November 1972 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0412 RFC0413 Traffic statistics (October 1972) A.M. McKenzie November 1972 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0413 RFC0414 File Transfer Protocol (FTP) status and further comments A.K. Bhushan December 1972 ASCII HTML 5 RFC0385 UNKNOWN UNKNOWN Legacy 10.17487/RFC0414 RFC0415 Tenex bandwidth H. Murray November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0415 RFC0416 ARC System Will Be Unavailable for Use During Thanksgiving Week J.C. Norton November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0416 RFC0417 Link usage violation J. Postel C. Kline December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0417 RFC0418 Server File Transfer Under TSS/360 At NASA-Ames Research Center W. Hathaway November 1972 PDF HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0418 RFC0419 To: Network liaisons and station agents A. Vezza December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0419 RFC0420 CCA ICCC weather demo H. Murray January 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0420 RFC0421 Software Consulting Service for Network Users A.M. McKenzie November 1972 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0421 RFC0422 Traffic statistics (November 1972) A.M. McKenzie December 1972 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0422 RFC0423 UCLA Campus Computing Network Liaison Staff for ARPANET B. Noble December 1972 ASCII HTML 2 RFC0389 UNKNOWN UNKNOWN Legacy 10.17487/RFC0423 RFC0424 RFC0425 "But my NCP costs $500 a day" R.D. Bressler December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0425 RFC0426 Reconnection Protocol R. Thomas January 1973 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0426 RFC0427 RFC0428 RFC0429 Character Generator Process J. Postel December 1972 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0429 RFC0430 Comments on File Transfer Protocol R.T. Braden February 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0430 RFC0431 Update on SMFS Login and Logout M. Krilanovich December 1972 ASCII HTML 3 RFC0399 RFC0122 UNKNOWN UNKNOWN Legacy 10.17487/RFC0431 RFC0432 Network logical map N. Neigus December 1972 ASCII PDF PS HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0432 RFC0433 Socket number list J. Postel December 1972 ASCII HTML 5 RFC0349 RFC0503 UNKNOWN UNKNOWN Legacy 10.17487/RFC0433 RFC0434 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII HTML 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0434 RFC0435 Telnet issues B. Cosell D.C. Walden January 1973 ASCII HTML 10 RFC0318 UNKNOWN UNKNOWN Legacy 10.17487/RFC0435 RFC0436 Announcement of RJS at UCSB M. Krilanovich January 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0436 RFC0437 Data Reconfiguration Service at UCSB E. Faeh June 1973 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0437 RFC0438 FTP server-server interaction R. Thomas R. Clements January 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0438 RFC0439 PARRY encounters the DOCTOR V. Cerf January 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0439 RFC0440 Scheduled network software maintenance D.C. Walden January 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0440 RFC0441 Inter-Entity Communication - an experiment R.D. Bressler R. Thomas January 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0441 RFC0442 Current flow-control scheme for IMPSYS V. Cerf January 1973 ASCII HTML 7 RFC0449 UNKNOWN UNKNOWN Legacy 10.17487/RFC0442 RFC0443 Traffic statistics (December 1972) A.M. McKenzie January 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0443 RFC0444 RFC0445 IMP/TIP preventive maintenance schedule A.M. McKenzie January 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0445 RFC0446 Proposal to consider a network program resource notebook L.P. Deutsch January 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0446 RFC0447 IMP/TIP memory retrofit schedule A.M. McKenzie January 1973 ASCII HTML 2 RFC0434 RFC0476 UNKNOWN UNKNOWN Legacy 10.17487/RFC0447 RFC0448 Print files in FTP R.T. Braden February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0448 RFC0449 Current flow-control scheme for IMPSYS D.C. Walden January 1973 ASCII HTML 1 RFC0442 UNKNOWN UNKNOWN Legacy 10.17487/RFC0449 RFC0450 MULTICS sampling timeout change M.A. Padlipsky February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0450 RFC0451 Tentative proposal for a Unified User Level Protocol M.A. Padlipsky February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0451 RFC0452 TELNET Command at Host LL J. Winett February 1973 ASCII PDF HTML 14 UNKNOWN UNKNOWN Legacy 10.17487/RFC0452 RFC0453 Meeting announcement to discuss a network mail system M.D. Kudlick February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0453 RFC0454 File Transfer Protocol - meeting announcement and a new proposed document A.M. McKenzie February 1973 ASCII HTML 35 FTP RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0454 RFC0455 Traffic statistics (January 1973) A.M. McKenzie February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0455 RFC0456 Memorandum: Date change of mail meeting M.D. Kudlick February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0456 RFC0457 TIPUG D.C. Walden February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0457 RFC0458 Mail retrieval via FTP R.D. Bressler R. Thomas February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0458 RFC0459 Network questionnaires W. Kantrowitz February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0459 RFC0460 NCP survey C. Kline February 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0460 RFC0461 Telnet Protocol meeting announcement A.M. McKenzie February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0461 RFC0462 Responding to user needs J. Iseli D. Crocker February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0462 RFC0463 FTP comments and response to RFC 430 A.K. Bhushan February 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0463 RFC0464 Resource notebook framework M.D. Kudlick February 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0464 RFC0465 RFC0466 Telnet logger/server for host LL-67 J.M. Winett February 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0466 RFC0467 Proposed change to Host-Host Protocol: Resynchronization of connection status J.D. Burchfiel R.S. Tomlinson February 1973 ASCII HTML 7 RFC0492 UNKNOWN UNKNOWN Legacy 10.17487/RFC0467 RFC0468 FTP data compression R.T. Braden March 1973 ASCII HTML 7 UNKNOWN UNKNOWN Legacy 10.17487/RFC0468 RFC0469 Network mail meeting summary M.D. Kudlick March 1973 ASCII HTML 10 network mail meeting UNKNOWN UNKNOWN Legacy 10.17487/RFC0469 RFC0470 Change in socket for TIP news facility R. Thomas March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0470 RFC0471 Workshop on multi-site executive programs R. Thomas March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0471 RFC0472 Illinois' reply to Maxwell's request for graphics information (NIC 14925) S. Bunch March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0472 RFC0473 MIX and MIXAL? D.C. Walden February 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0473 RFC0474 Announcement of NGWG meeting: Call for papers S. Bunch March 1973 ASCII HTML 2 RFC0396 UNKNOWN UNKNOWN Legacy 10.17487/RFC0474 RFC0475 FTP and Network Mail System A.K. Bhushan March 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0475 RFC0476 IMP/TIP memory retrofit schedule (rev 2) A.M. McKenzie March 1973 ASCII HTML 2 RFC0447 UNKNOWN UNKNOWN Legacy 10.17487/RFC0476 RFC0477 Remote Job Service at UCSB M. Krilanovich May 1973 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0477 RFC0478 FTP server-server interaction - II R.D. Bressler R. Thomas March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0478 RFC0479 Use of FTP by the NIC Journal J.E. White March 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0479 RFC0480 Host-dependent FTP parameters J.E. White March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0480 RFC0481 RFC0482 Traffic statistics (February 1973) A.M. McKenzie March 1973 ASCII HTML 4 RFC0497 UNKNOWN UNKNOWN Legacy 10.17487/RFC0482 RFC0483 Cancellation of the resource notebook framework meeting M.D. Kudlick March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0483 RFC0484 RFC0485 MIX and MIXAL at UCSB J.R. Pickens March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0485 RFC0486 Data transfer revisited R.D. Bressler March 1973 ASCII HTML 2 RJE FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0486 RFC0487 Free file transfer R.D. Bressler April 1973 ASCII HTML 2 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0487 RFC0488 NLS classes at network sites M.F. Auerbach March 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0488 RFC0489 Comment on resynchronization of connection status proposal J. Postel March 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0489 RFC0490 Surrogate RJS for UCLA-CCN J.R. Pickens March 1973 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0490 RFC0491 What is "Free"? M.A. Padlipsky April 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0491 RFC0492 Response to RFC 467 E. Meyer April 1973 ASCII HTML 7 RFC0467 UNKNOWN UNKNOWN Legacy 10.17487/RFC0492 RFC0493 GRAPHICS PROTOCOL J.C. Michener I.W. Cotton K.C. Kelley D.E. Liddle E. Meyer April 1973 ASCII PDF HTML 28 RFC0292 UNKNOWN UNKNOWN Legacy 10.17487/RFC0493 RFC0494 Availability of MIX and MIXAL in the Network D.C. Walden April 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0494 RFC0495 Telnet Protocol specifications A.M. McKenzie May 1973 ASCII HTML 2 RFC0158 RFC0562 UNKNOWN UNKNOWN Legacy 10.17487/RFC0495 RFC0496 TNLS quick reference card is available M.F. Auerbach April 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0496 RFC0497 Traffic Statistics (March 1973) A.M. McKenzie April 1973 ASCII PDF HTML 4 RFC0482 UNKNOWN UNKNOWN Legacy 10.17487/RFC0497 RFC0498 On mail service to CCN R.T. Braden April 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0498 RFC0499 Harvard's network RJE B.R. Reussow April 1973 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0499 RFC0500 Integration of data management systems on a computer network A. Shoshani I. Spiegler April 1973 PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0500 RFC0501 Un-muddling "free file transfer" K.T. Pogran May 1973 ASCII HTML 5 FTP UNKNOWN UNKNOWN Legacy 10.17487/RFC0501 RFC0502 RFC0503 Socket number list N. Neigus J. Postel April 1973 ASCII HTML 8 RFC0433 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0503 RFC0504 Distributed resources workshop announcement R. Thomas April 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0504 RFC0505 Two solutions to a file transfer access problem M.A. Padlipsky June 1973 ASCII HTML 3 FTP free UNKNOWN UNKNOWN Legacy 10.17487/RFC0505 RFC0506 FTP command naming problem M.A. Padlipsky June 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0506 RFC0507 RFC0508 Real-time data transmission on the ARPANET L. Pfeifer J. McAfee May 1973 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0508 RFC0509 Traffic statistics (April 1973) A.M. McKenzie April 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0509 RFC0510 Request for network mailbox addresses J.E. White May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0510 RFC0511 Enterprise phone service to NIC from ARPANET sites J.B. North May 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0511 RFC0512 More on lost message detection W. Hathaway May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0512 RFC0513 Comments on the new Telnet specifications W. Hathaway May 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0513 RFC0514 Network make-work W. Kantrowitz June 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0514 RFC0515 Specifications for Datalanguage, Version 0/9 R. Winter June 1973 ASCII HTML 31 UNKNOWN UNKNOWN Legacy 10.17487/RFC0515 RFC0516 Lost message detection J. Postel May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0516 RFC0517 RFC0518 ARPANET accounts N. Vaughan E.J. Feinler June 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0518 RFC0519 Resource Evaluation J.R. Pickens June 1973 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0519 RFC0520 Memo to FTP group: Proposal for File Access Protocol J.D. Day June 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0520 RFC0521 Restricted use of IMP DDT A.M. McKenzie May 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0521 RFC0522 Traffic Statistics (May 1973) A.M. McKenzie June 1973 ASCII PDF HTML 4 RFC0509 UNKNOWN UNKNOWN Legacy 10.17487/RFC0522 RFC0523 SURVEY is in operation again A.K. Bhushan June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0523 RFC0524 Proposed Mail Protocol J.E. White June 1973 ASCII HTML 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0524 RFC0525 MIT-MATHLAB meets UCSB-OLS -an example of resource sharing W. Parrish J.R. Pickens June 1973 ASCII PS PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0525 RFC0526 Technical meeting: Digital image processing software systems W.K. Pratt June 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0526 RFC0527 ARPAWOCKY R. Merryman May 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0527 RFC0528 Software checksumming in the IMP and network reliability J.M. McQuillan June 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0528 RFC0529 Note on protocol synch sequences A.M. McKenzie R. Thomas R.S. Tomlinson K.T. Pogran June 1973 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0529 RFC0530 Report on the Survey Project A.K. Bhushan June 1973 PDF HTML 0 RFC0308 RFC0523 UNKNOWN UNKNOWN Legacy 10.17487/RFC0530 RFC0531 Feast or famine? A response to two recent RFC's about network information M.A. Padlipsky June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0531 RFC0532 UCSD-CC Server-FTP facility R.G. Merryman July 1973 ASCII HTML 4 FTP server UNKNOWN UNKNOWN Legacy 10.17487/RFC0532 RFC0533 Message-ID numbers D.C. Walden July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0533 RFC0534 Lost message detection D.C. Walden July 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0534 RFC0535 Comments on File Access Protocol R. Thomas July 1973 ASCII PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0535 RFC0536 RFC0537 Announcement of NGG meeting July 16-17 S. Bunch June 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0537 RFC0538 Traffic statistics (June 1973) A.M. McKenzie July 1973 ASCII HTML 4 RFC0556 UNKNOWN UNKNOWN Legacy 10.17487/RFC0538 RFC0539 Thoughts on the mail protocol proposed in RFC 524 D. Crocker J. Postel July 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0539 RFC0540 RFC0541 RFC0542 File Transfer Protocol N. Neigus August 1973 ASCII HTML 40 FTP RFC0354 RFC0765 RFC0614 RFC0640 RFC0454 RFC0495 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=542 10.17487/RFC0542 RFC0543 Network journal submission and delivery N.D. Meyer July 1973 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0543 RFC0544 Locating on-line documentation at SRI-ARC N.D. Meyer K. Kelley July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0544 RFC0545 Of what quality be the UCSB resources evaluators? J.R. Pickens July 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0545 RFC0546 Tenex load averages for July 1973 R. Thomas August 1973 ASCII PS PDF HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0546 RFC0547 Change to the Very Distant Host specification D.C. Walden August 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0547 RFC0548 Hosts using the IMP Going Down message D.C. Walden August 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0548 RFC0549 Minutes of Network Graphics Group meeting, 15-17 July 1973 J.C. Michener July 1973 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0549 RFC0550 NIC NCP experiment L.P. Deutsch August 1973 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0550 RFC0551 NYU, ANL, and LBL Joining the Net Y. Feinroth R. Fink August 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0551 RFC0552 Single access to standard protocols A.D. Owen July 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0552 RFC0553 Draft design for a text/graphics protocol C.H. Irby K. Victor July 1973 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0553 RFC0554 RFC0555 Responses to critiques of the proposed mail protocol J.E. White July 1973 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0555 RFC0556 Traffic Statistics (July 1973) A.M. McKenzie August 1973 ASCII PDF HTML 4 RFC0538 UNKNOWN UNKNOWN Legacy 10.17487/RFC0556 RFC0557 REVELATIONS IN NETWORK HOST MEASUREMENTS B.D. Wessler August 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0557 RFC0558 RFC0559 Comments on The New Telnet Protocol and its Implementation A.K. Bushan August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0559 RFC0560 Remote Controlled Transmission and Echoing Telnet option D. Crocker J. Postel August 1973 ASCII PDF HTML 12 RFC0581 UNKNOWN UNKNOWN Legacy 10.17487/RFC0560 RFC0561 Standardizing Network Mail Headers A.K. Bhushan K.T. Pogran R.S. Tomlinson J.E. White September 1973 ASCII HTML 3 RFC0680 UNKNOWN UNKNOWN Legacy 10.17487/RFC0561 RFC0562 Modifications to the TELNET Specification A.M. McKenzie August 1973 ASCII PDF HTML 2 RFC0495 UNKNOWN UNKNOWN Legacy 10.17487/RFC0562 RFC0563 Comments on the RCTE Telnet option J. Davidson August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0563 RFC0564 RFC0565 Storing network survey data at the datacomputer D. Cantor August 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0565 RFC0566 Traffic statistics (August 1973) A.M. McKenzie September 1973 ASCII HTML 4 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0566 RFC0567 Cross Country Network Bandwidth L.P. Deutsch September 1973 ASCII HTML 1 RFC0568 UNKNOWN UNKNOWN Legacy 10.17487/RFC0567 RFC0568 Response to RFC 567 - cross country network bandwidth J.M. McQuillan September 1973 ASCII HTML 3 RFC0567 UNKNOWN UNKNOWN Legacy 10.17487/RFC0568 RFC0569 NETED: A Common Editor for the ARPA Network M.A. Padlipsky October 1973 ASCII HTML 6 NETED HISTORIC HISTORIC Legacy 10.17487/RFC0569 RFC0570 Experimental input mapping between NVT ASCII and UCSB On Line System J.R. Pickens October 1973 ASCII PS PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0570 RFC0571 TENEX FTP PROBLEM R. Braden November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0571 RFC0572 RFC0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS A. Bhushan September 1973 ASCII PDF HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0573 RFC0574 Announcement of a Mail Facility at UCSB M. Krilanovich September 1973 ASCII PDF HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0574 RFC0575 RFC0576 Proposal for modifying linking K. Victor September 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0576 RFC0577 Mail priority D. Crocker October 1973 ASCII PDF HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0577 RFC0578 Using MIT-Mathlab MACSYMA from MIT-DMS Muddle A.K. Bhushan N.D. Ryan October 1973 ASCII PDF HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0578 RFC0579 Traffic statistics (September 1973) A.M. McKenzie November 1973 ASCII PDF HTML 5 RFC0566 RFC0586 UNKNOWN UNKNOWN Legacy 10.17487/RFC0579 RFC0580 Note to Protocol Designers and Implementers J. Postel October 1973 ASCII HTML 1 RFC0582 UNKNOWN UNKNOWN Legacy 10.17487/RFC0580 RFC0581 Corrections to RFC 560: Remote Controlled Transmission and Echoing Telnet Option D. Crocker J. Postel November 1973 ASCII PDF HTML 5 RFC0560 UNKNOWN UNKNOWN Legacy 10.17487/RFC0581 RFC0582 Comments on RFC 580: Machine readable protocols R. Clements November 1973 ASCII HTML 1 RFC0580 UNKNOWN UNKNOWN Legacy 10.17487/RFC0582 RFC0583 RFC0584 Charter for ARPANET Users Interest Working Group J. Iseli D. Crocker N. Neigus November 1973 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0584 RFC0585 ARPANET users interest working group meeting D. Crocker N. Neigus E.J. Feinler J. Iseli November 1973 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0585 RFC0586 Traffic statistics (October 1973) A.M. McKenzie November 1973 ASCII PDF HTML 5 RFC0579 UNKNOWN UNKNOWN Legacy 10.17487/RFC0586 RFC0587 Announcing New Telnet Options J. Postel November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0587 RFC0588 London Node Is Now Up A. Stokes October 1973 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0588 RFC0589 CCN NETRJS server messages to remote user R.T. Braden November 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0589 RFC0590 MULTICS address change M.A. Padlipsky November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0590 RFC0591 Addition to the Very Distant Host specifications D.C. Walden November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0591 RFC0592 Some thoughts on system design to facilitate resource sharing R.W. Watson November 1973 ASCII PDF HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0592 RFC0593 Telnet and FTP implementation schedule change A.M. McKenzie J. Postel November 1973 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0593 RFC0594 Speedup of Host-IMP interface J.D. Burchfiel December 1973 ASCII PDF HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0594 RFC0595 Second thoughts in defense of the Telnet Go-Ahead W. Hathaway December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0595 RFC0596 Second thoughts on Telnet Go-Ahead E.A. Taft December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0596 RFC0597 Host status N. Neigus E.J. Feinler December 1973 ASCII HTML 6 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0597 RFC0598 RFC index - December 5, 1973 Network Information Center. Stanford Research Institute December 1973 PDF HTML 0 UNKNOWN UNKNOWN Legacy 10.17487/RFC0598 RFC0599 Update on NETRJS R.T. Braden December 1973 ASCII HTML 9 RFC0189 RFC0740 UNKNOWN UNKNOWN Legacy 10.17487/RFC0599 RFC0600 Interfacing an Illinois plasma terminal to the ARPANET A. Berggreen November 1973 ASCII PDF HTML 3

Discusses some unusual interface issues for the Plato terminal.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0600
RFC0601 Traffic statistics (November 1973) A.M. McKenzie December 1973 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0601 RFC0602 "The stockings were hung by the chimney with care" R.M. Metcalfe December 1973 ASCII HTML 1 security violations TIP arpanet

Susceptibility of ARPANET to security violations.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0602
RFC0603 Response to RFC 597: Host status J.D. Burchfiel December 1973 ASCII HTML 1

Questions about the ARPANET topology described in RFC 597.

RFC0597 RFC0613 UNKNOWN UNKNOWN Legacy 10.17487/RFC0603
RFC0604 Assigned link numbers J. Postel December 1973 ASCII HTML 2

Modifies official host-host protocol. Replaces RFC 377.

RFC0317 RFC0739 UNKNOWN UNKNOWN Legacy 10.17487/RFC0604
RFC0605 RFC0606 Host names on-line L.P. Deutsch December 1973 ASCII HTML 3 lists names host addresses

Resolving differences in hostname-address mappings; see also RFCs 627, 625, 623 and 608.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0606
RFC0607 Comments on the File Transfer Protocol M. Krilanovich G. Gregg January 1974 ASCII HTML 3 solutions weakness ftp

An old version; see RFC 624; see also RFCs 614, 542 and 640.

RFC0624 RFC0614 UNKNOWN UNKNOWN Legacy 10.17487/RFC0607
RFC0608 Host names on-line M.D. Kudlick January 1974 ASCII HTML 4

Response to RFC 606; see also RFCs 627, 625 and 623.

RFC0810 UNKNOWN UNKNOWN Legacy 10.17487/RFC0608
RFC0609 Statement of upcoming move of NIC/NLS service B. Ferguson January 1974 ASCII HTML 2

See also RFCs 621 and 620.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0609
RFC0610 Further datalanguage design concepts R. Winter J. Hill W. Greiff December 1973 ASCII HTML 88

Preliminary results of the language design; a model for data languagea semantics; future considerations.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0610
RFC0611 Two changes to the IMP/Host Protocol to improve user/network communications D.C. Walden February 1974 ASCII HTML 4

Expansion of Host-Going-Down and addition of Dead-Host-Status Message.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0611
RFC0612 Traffic statistics (December 1973) A.M. McKenzie January 1974 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0612 RFC0613 Network connectivity: A response to RFC 603 A.M. McKenzie January 1974 ASCII HTML 1 RFC0603 UNKNOWN UNKNOWN Legacy 10.17487/RFC0613 RFC0614 Response to RFC 607: "Comments on the File Transfer Protocol" K.T. Pogran N. Neigus January 1974 ASCII HTML 3 ftp weakness solutions

See also RFCs 624, 542 and 640.

RFC0542 RFC0607 UNKNOWN UNKNOWN Legacy 10.17487/RFC0614
RFC0615 Proposed Network Standard Data Pathname syntax D. Crocker March 1974 ASCII HTML 4 RFC0645 UNKNOWN UNKNOWN Legacy 10.17487/RFC0615 RFC0616 LATEST NETWORK MAPS D. Walden February 1973 ASCII PDF HTML 1 Network maps UNKNOWN UNKNOWN Legacy 10.17487/RFC0616 RFC0617 Note on socket number assignment E.A. Taft February 1974 ASCII HTML 3 telnet

Danger of imposing more fixed socket number requirements; see also RFCs 542, 503 and 451.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0617
RFC0618 Few observations on NCP statistics E.A. Taft February 1974 ASCII HTML 3

Distribution of NCP and IMP message types by actual measurement.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0618
RFC0619 Mean round-trip times in the ARPANET W. Naylor H. Opderbeck March 1974 ASCII HTML 14

Actual measurements of round-trip times.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0619
RFC0620 Request for monitor host table updates B. Ferguson March 1974 ASCII HTML 1 tenex

In conjunction with moving NIC users to OFFICE-1; see also RFCs 621 and 609.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0620
RFC0621 NIC user directories at SRI ARC M.D. Kudlick March 1974 ASCII HTML 1

See also RFCs 620 and 609.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0621
RFC0622 Scheduling IMP/TIP down time A.M. McKenzie March 1974 ASCII HTML 3

Modification of previous policy.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0622
RFC0623 Comments on on-line host name service M. Krilanovich February 1974 ASCII HTML 2

See also RFCs 627, 625, 608 and 606.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0623
RFC0624 Comments on the File Transfer Protocol M. Krilanovich G. Gregg W. Hathaway J.E. White February 1974 ASCII HTML 3 ftp telnet

Design changes and slight modifications. Replaces RFC 607; see also RFCs 614, 542 and 640.

RFC0607 UNKNOWN UNKNOWN Legacy 10.17487/RFC0624
RFC0625 On-line hostnames service M.D. Kudlick E.J. Feinler March 1974 ASCII HTML 1

See also RFCs 606, 608, 623 and 627.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0625
RFC0626 On a possible lockup condition in IMP subnet due to message sequencing L. Kleinrock H. Opderbeck March 1974 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0626 RFC0627 ASCII text file of hostnames M.D. Kudlick E.J. Feinler March 1974 ASCII HTML 1

See also RFCs 606, 608, 623 and 625.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0627
RFC0628 Status of RFC numbers and a note on pre-assigned journal numbers M.L. Keeney March 1974 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0628 RFC0629 Scenario for using the Network Journal J.B. North March 1974 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0629 RFC0630 FTP error code usage for more reliable mail service J. Sussman April 1974 ASCII HTML 3

Describes FTP reply-code usage in TENEX mail processing.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0630
RFC0631 International meeting on minicomputers and data communication: Call for papers A. Danthine April 1974 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0631 RFC0632 Throughput degradations for single packet messages H. Opderbeck May 1974 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0632 RFC0633 IMP/TIP preventive maintenance schedule A.M. McKenzie March 1974 ASCII HTML 4

An old version; see RFC 638.

RFC0638 UNKNOWN UNKNOWN Legacy 10.17487/RFC0633
RFC0634 Change in network address for Haskins Lab A.M. McKenzie April 1974 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0634 RFC0635 Assessment of ARPANET protocols V. Cerf April 1974 ASCII PDF HTML 1

Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0635
RFC0636 TIP/Tenex reliability improvements J.D. Burchfiel B. Cosell R.S. Tomlinson D.C. Walden June 1974 ASCII HTML 8

Obtaining/maintaining connections; recovery from lost connections; connection-state changes.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0636
RFC0637 Change of network address for SU-DSL A.M. McKenzie April 1974 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0637 RFC0638 IMP/TIP preventive maintenance schedule A.M. McKenzie April 1974 ASCII HTML 4

Corrects RFC 633.

RFC0633 UNKNOWN UNKNOWN Legacy 10.17487/RFC0638
RFC0639 RFC0640 Revised FTP reply codes J. Postel June 1974 ASCII HTML 17

Updates RFC 542.

RFC0542 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=640 10.17487/RFC0640
RFC0641 RFC0642 Ready line philosophy and implementation J.D. Burchfiel July 1974 ASCII HTML 4 UNKNOWN UNKNOWN Legacy 10.17487/RFC0642 RFC0643 Network Debugging Protocol E. Mader July 1974 ASCII HTML 7

To be used in an implementation of a PDP-11 network bootstrap device and a cross-network debugger.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0643
RFC0644 On the problem of signature authentication for network mail R. Thomas July 1974 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0644 RFC0645 Network Standard Data Specification syntax D. Crocker June 1974 ASCII PDF HTML 9

Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.

RFC0615 UNKNOWN UNKNOWN Legacy 10.17487/RFC0645
RFC0646 RFC0647 Proposed protocol for connecting host computers to ARPA-like networks via front end processors M.A. Padlipsky November 1974 ASCII PDF HTML 20

Approaches to Front-End protocol processing using available hardware and software.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0647
RFC0648 RFC0649 RFC0650 RFC0651 Revised Telnet status option D. Crocker October 1974 ASCII HTML 2 RFC0859 UNKNOWN UNKNOWN Legacy 10.17487/RFC0651 RFC0652 Telnet output carriage-return disposition option D. Crocker October 1974 ASCII HTML 4 TOPT-OCRD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0652 RFC0653 Telnet output horizontal tabstops option D. Crocker October 1974 ASCII HTML 1 TOPT-OHT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0653 RFC0654 Telnet output horizontal tab disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OHTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0654 RFC0655 Telnet output formfeed disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OFD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0655 RFC0656 Telnet output vertical tabstops option D. Crocker October 1974 ASCII HTML 1 TOPT-OVT HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0656 RFC0657 Telnet output vertical tab disposition option D. Crocker October 1974 ASCII HTML 1 TOPT-OVTD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0657 RFC0658 Telnet output linefeed disposition D. Crocker October 1974 ASCII HTML 2 TOPT-OLD HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC0658 RFC0659 Announcing additional Telnet options J. Postel October 1974 ASCII HTML 1

Options defined in RFCs 651-658.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0659
RFC0660 Some changes to the IMP and the IMP/Host interface D.C. Walden October 1974 ASCII HTML 1

Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0660
RFC0661 Protocol information J. Postel November 1974 ASCII PDF HTML 21

An old version; see RFC 694.

RFC0694 UNKNOWN UNKNOWN Legacy 10.17487/RFC0661
RFC0662 Performance improvement in ARPANET file transfers from Multics R. Kanodia November 1974 ASCII HTML 2

Experimenting with host output buffers to improve throughput.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0662
RFC0663 Lost message detection and recovery protocol R. Kanodia November 1974 ASCII HTML 22 ARPANET Host

Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0663
RFC0664 RFC0665 RFC0666 Specification of the Unified User-Level Protocol M.A. Padlipsky November 1974 ASCII HTML 19

Discusses and proposes a common command language.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0666
RFC0667 Host Ports S.G. Chipman December 1974 ASCII PDF HTML 2

Approved scheme to connect host ports to the network.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0667
RFC0668 RFC0669 November, 1974, survey of New-Protocol Telnet servers D.W. Dodds December 1974 ASCII PDF HTML 3

An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.

RFC0702 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0669
RFC0670 RFC0671 Note on Reconnection Protocol R. Schantz December 1974 ASCII PDF HTML 9

Experience with implementation in RSEXEC context.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0671
RFC0672 Multi-site data collection facility R. Schantz December 1974 ASCII HTML 9

Applicability of TIP/TENEX protocols beyond TIP accounting.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0672
RFC0673 RFC0674 Procedure call documents: Version 2 J. Postel J.E. White December 1974 ASCII HTML 6

Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0674
RFC0675 Specification of Internet Transmission Control Program V. Cerf Y. Dalal C. Sunshine December 1974 ASCII HTML 70

The first detailed specification of TCP; see RFC 793.

RFC7805 HISTORIC UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=675 10.17487/RFC0675
RFC0676 RFC0677 Maintenance of duplicate databases P.R. Johnson R. Thomas January 1975 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0677 RFC0678 Standard file formats J. Postel December 1974 ASCII HTML 9

For transmission of documents across different environments.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0678
RFC0679 February, 1975, survey of New-Protocol Telnet servers D.W. Dodds February 1975 ASCII PDF HTML 3

An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703.

RFC0669 RFC0703 UNKNOWN UNKNOWN Legacy 10.17487/RFC0679
RFC0680 Message Transmission Protocol T.H. Myer D.A. Henderson April 1975 ASCII HTML 6

Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.

RFC0561 UNKNOWN UNKNOWN Legacy 10.17487/RFC0680
RFC0681 Network UNIX S. Holmgren March 1975 ASCII HTML 8

Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0681
RFC0682 RFC0683 FTPSRV - Tenex extension for paged files R. Clements April 1975 ASCII HTML 3 FTP paged file transfer Tenex

Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.

RFC0354 UNKNOWN UNKNOWN Legacy 10.17487/RFC0683
RFC0684 Commentary on procedure calling as a network protocol R. Schantz April 1975 ASCII HTML 9

Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0684
RFC0685 Response time in cross network debugging M. Beeler April 1975 ASCII HTML 3

The contribution of ARPANET communication to response time.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0685
RFC0686 Leaving well enough alone B. Harvey May 1975 ASCII HTML 9

Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0686
RFC0687 IMP/Host and Host/IMP Protocol changes D.C. Walden June 1975 ASCII HTML 2

Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.

RFC0704 RFC0690 UNKNOWN UNKNOWN Legacy 10.17487/RFC0687
RFC0688 Tentative schedule for the new Telnet implementation for the TIP D.C. Walden June 1975 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0688 RFC0689 Tenex NCP finite state machine for connections R. Clements May 1975 ASCII HTML 5

Describes the internal states of an NCP connection in the TENEX implementation.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0689
RFC0690 Comments on the proposed Host/IMP Protocol changes J. Postel June 1975 ASCII HTML 3

Comments on suggestions in RFC 687; see also RFCs 692 and 696.

RFC0687 RFC0692 UNKNOWN UNKNOWN Legacy 10.17487/RFC0690
RFC0691 One more try on the FTP B. Harvey June 1975 ASCII HTML 14

Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0691
RFC0692 Comments on IMP/Host Protocol changes (RFCs 687 and 690) S.M. Wolfe June 1975 ASCII HTML 2

A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.

RFC0690 UNKNOWN UNKNOWN Legacy 10.17487/RFC0692
RFC0693 RFC0694 Protocol information J. Postel June 1975 ASCII PDF HTML 36

References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.

RFC0661 UNKNOWN UNKNOWN Legacy 10.17487/RFC0694
RFC0695 Official change in Host-Host Protocol M. Krilanovich July 1975 ASCII HTML 3

Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0695
RFC0696 Comments on the IMP/Host and Host/IMP Protocol changes V.G. Cerf July 1975 ASCII PDF HTML 2

Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0696
RFC0697 CWD command of FTP J. Lieb July 1975 ASCII HTML 2

Discusses FTP login access to "files only" directories.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0697
RFC0698 Telnet extended ASCII option T. Mock July 1975 ASCII HTML 3 TOPT-EXT

Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.

RFC5198 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0698
RFC0699 Request For Comments summary notes: 600-699 J. Postel J. Vernon November 1982 ASCII HTML 9 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0699 RFC0700 Protocol experiment E. Mader W.W. Plummer R.S. Tomlinson August 1974 ASCII HTML 7 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0700 RFC0701 August, 1974, survey of New-Protocol Telnet servers D.W. Dodds August 1974 ASCII HTML 1 RFC0702 UNKNOWN UNKNOWN Legacy 10.17487/RFC0701 RFC0702 September, 1974, survey of New-Protocol Telnet servers D.W. Dodds September 1974 ASCII HTML 3 RFC0701 RFC0669 UNKNOWN UNKNOWN Legacy 10.17487/RFC0702 RFC0703 July, 1975, survey of New-Protocol Telnet Servers D.W. Dodds July 1975 ASCII HTML 3 RFC0679 UNKNOWN UNKNOWN Legacy 10.17487/RFC0703 RFC0704 IMP/Host and Host/IMP Protocol change P.J. Santos September 1975 ASCII HTML 2 RFC0687 UNKNOWN UNKNOWN Legacy 10.17487/RFC0704 RFC0705 Front-end Protocol B6700 version R.F. Bryan November 1975 ASCII HTML 39 UNKNOWN UNKNOWN Legacy 10.17487/RFC0705 RFC0706 On the junk mail problem J. Postel November 1975 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0706 RFC0707 High-level framework for network-based resource sharing J.E. White December 1975 ASCII HTML 29 UNKNOWN UNKNOWN Legacy 10.17487/RFC0707 RFC0708 Elements of a Distributed Programming System J.E. White January 1976 ASCII HTML 30 UNKNOWN UNKNOWN Legacy 10.17487/RFC0708 RFC0709 RFC0710 RFC0711 RFC0712 Distributed Capability Computing System (DCCS) J.E. Donnelley February 1976 ASCII PDF HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0712 RFC0713 MSDTP-Message Services Data Transmission Protocol J. Haverty April 1976 ASCII HTML 21 UNKNOWN UNKNOWN Legacy 10.17487/RFC0713 RFC0714 Host-Host Protocol for an ARPANET-Type Network A.M. McKenzie April 1976 ASCII PDF HTML 22 UNKNOWN UNKNOWN Legacy 10.17487/RFC0714 RFC0715 RFC0716 Interim Revision to Appendix F of BBN 1822 D.C. Walden J. Levin May 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0716 RFC0717 Assigned Network Numbers J. Postel July 1976 ASCII HTML 1 HISTORIC UNKNOWN Legacy 10.17487/RFC0717 RFC0718 Comments on RCTE from the Tenex Implementation Experience J. Postel June 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0718 RFC0719 Discussion on RCTE J. Postel July 1976 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0719 RFC0720 Address Specification Syntax for Network Mail D. Crocker August 1976 ASCII HTML 3 UNKNOWN UNKNOWN Legacy 10.17487/RFC0720 RFC0721 Out-of-Band Control Signals in a Host-to-Host Protocol L.L. Garlick September 1976 ASCII HTML 7 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0721 RFC0722 Thoughts on Interactions in Distributed Services J. Haverty September 1976 ASCII HTML 13 UNKNOWN UNKNOWN Legacy 10.17487/RFC0722 RFC0723 RFC0724 Proposed official standard for the format of ARPA Network messages D. Crocker K.T. Pogran J. Vittal D.A. Henderson May 1977 ASCII HTML 36 RFC0733 UNKNOWN UNKNOWN Legacy 10.17487/RFC0724 RFC0725 RJE protocol for a resource sharing network J.D. Day G.R. Grossman March 1977 ASCII HTML 27 UNKNOWN UNKNOWN Legacy 10.17487/RFC0725 RFC0726 Remote Controlled Transmission and Echoing Telnet option J. Postel D. Crocker March 1977 ASCII HTML 16 TOPT-REM PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0726 RFC0727 Telnet logout option M.R. Crispin April 1977 ASCII HTML 3 TOPT-LOGO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0727 RFC0728 Minor pitfall in the Telnet Protocol J.D. Day April 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0728 RFC0729 Telnet byte macro option D. Crocker May 1977 ASCII HTML 3 RFC0735 UNKNOWN UNKNOWN Legacy 10.17487/RFC0729 RFC0730 Extensible field addressing J. Postel May 1977 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0730 RFC0731 Telnet Data Entry Terminal option J.D. Day June 1977 ASCII HTML 28 RFC0732 UNKNOWN UNKNOWN Legacy 10.17487/RFC0731 RFC0732 Telnet Data Entry Terminal option J.D. Day September 1977 ASCII HTML 30 RFC0731 RFC1043 UNKNOWN UNKNOWN Legacy 10.17487/RFC0732 RFC0733 Standard for the format of ARPA network text messages D. Crocker J. Vittal K.T. Pogran D.A. Henderson November 1977 ASCII HTML 38 RFC0724 RFC0822 UNKNOWN UNKNOWN Legacy 10.17487/RFC0733 RFC0734 SUPDUP Protocol M.R. Crispin October 1977 ASCII HTML 13 SUPDUP HISTORIC HISTORIC Legacy 10.17487/RFC0734 RFC0735 Revised Telnet byte macro option D. Crocker R.H. Gumpertz November 1977 ASCII HTML 5 TOPT-BYTE RFC0729 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0735 RFC0736 Telnet SUPDUP option M.R. Crispin October 1977 ASCII HTML 1 TOPT-SUP PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0736 RFC0737 FTP extension: XSEN K. Harrenstien October 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0737 RFC0738 Time server K. Harrenstien October 1977 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0738 RFC0739 Assigned numbers J. Postel November 1977 ASCII HTML 11 RFC0604 RFC0503 RFC0750 HISTORIC UNKNOWN Legacy 10.17487/RFC0739 RFC0740 NETRJS Protocol R.T. Braden November 1977 ASCII HTML 19 NETRJS RFC0599 HISTORIC HISTORIC Legacy 10.17487/RFC0740 RFC0741 Specifications for the Network Voice Protocol (NVP) D. Cohen November 1977 ASCII HTML 34 UNKNOWN UNKNOWN Legacy 10.17487/RFC0741 RFC0742 NAME/FINGER Protocol K. Harrenstien December 1977 ASCII HTML 7 RFC1288 RFC1196 RFC1194 UNKNOWN UNKNOWN Legacy 10.17487/RFC0742 RFC0743 FTP extension: XRSQ/XRCP K. Harrenstien December 1977 ASCII HTML 8 UNKNOWN UNKNOWN Legacy 10.17487/RFC0743 RFC0744 MARS - a Message Archiving and Retrieval Service J. Sattley January 1978 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0744 RFC0745 JANUS interface specifications M. Beeler March 1978 ASCII HTML 10 JANUS interface specifications UNKNOWN UNKNOWN Legacy 10.17487/RFC0745 RFC0746 SUPDUP graphics extension R. Stallman March 1978 ASCII HTML 15 UNKNOWN UNKNOWN Legacy 10.17487/RFC0746 RFC0747 Recent extensions to the SUPDUP Protocol M.R. Crispin March 1978 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0747 RFC0748 Telnet randomly-lose option M.R. Crispin April 1 1978 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0748 RFC0749 Telnet SUPDUP-Output option B. Greenberg September 1978 ASCII HTML 4 TOPT-SUPO PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0749 RFC0750 Assigned numbers J. Postel September 1978 ASCII HTML 12 RFC0739 RFC0755 HISTORIC UNKNOWN Legacy 10.17487/RFC0750 RFC0751 Survey of FTP mail and MLFL P.D. Lebling December 1978 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0751 RFC0752 Universal host table M.R. Crispin January 1979 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0752 RFC0753 Internet Message Protocol J. Postel March 1979 ASCII HTML 62 UNKNOWN UNKNOWN Legacy 10.17487/RFC0753 RFC0754 Out-of-net host addresses for mail J. Postel April 1979 ASCII HTML 10 UNKNOWN UNKNOWN Legacy 10.17487/RFC0754 RFC0755 Assigned numbers J. Postel May 1979 ASCII HTML 12 RFC0750 RFC0758 HISTORIC UNKNOWN Legacy 10.17487/RFC0755 RFC0756 NIC name server - a datagram-based information utility J.R. Pickens E.J. Feinler J.E. Mathis July 1979 ASCII HTML 12 UNKNOWN UNKNOWN Legacy 10.17487/RFC0756 RFC0757 Suggested solution to the naming, addressing, and delivery problem for ARPANET message systems D.P. Deutsch September 1979 ASCII HTML 19 UNKNOWN UNKNOWN Legacy 10.17487/RFC0757 RFC0758 Assigned numbers J. Postel August 1979 ASCII HTML 12 RFC0755 RFC0762 HISTORIC UNKNOWN Legacy 10.17487/RFC0758 RFC0759 Internet Message Protocol J. Postel August 1980 ASCII HTML 77 MPM HISTORIC HISTORIC Legacy 10.17487/RFC0759 RFC0760 DoD standard Internet Protocol J. Postel January 1980 ASCII HTML 46 IEN123 RFC0791 RFC0777 UNKNOWN UNKNOWN Legacy 10.17487/RFC0760 RFC0761 DoD standard Transmission Control Protocol J. Postel January 1980 ASCII HTML 88 TCP RFC0793 RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0761 RFC0762 Assigned numbers J. Postel January 1980 ASCII HTML 13 RFC0758 RFC0770 HISTORIC UNKNOWN Legacy 10.17487/RFC0762 RFC0763 Role mailboxes M.D. Abrams May 1980 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0763 RFC0764 Telnet Protocol specification J. Postel June 1980 ASCII HTML 15 RFC0854 UNKNOWN UNKNOWN Legacy 10.17487/RFC0764 RFC0765 File Transfer Protocol specification J. Postel June 1980 ASCII HTML 70 RFC0542 RFC0959 UNKNOWN UNKNOWN Legacy 10.17487/RFC0765 RFC0766 Internet Protocol Handbook: Table of contents J. Postel July 1980 ASCII HTML 2 RFC0774 UNKNOWN UNKNOWN Legacy 10.17487/RFC0766 RFC0767 Structured format for transmission of multi-media documents J. Postel August 1980 ASCII HTML 40 UNKNOWN UNKNOWN Legacy 10.17487/RFC0767 RFC0768 User Datagram Protocol J. Postel August 1980 ASCII HTML 3 UDP UDP STD0006 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0768 RFC0769 Rapicom 450 facsimile file format J. Postel September 1980 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0769 RFC0770 Assigned numbers J. Postel September 1980 ASCII HTML 15 RFC0762 RFC0776 HISTORIC UNKNOWN Legacy 10.17487/RFC0770 RFC0771 Mail transition plan V.G. Cerf J. Postel September 1980 ASCII HTML 9 UNKNOWN UNKNOWN Legacy 10.17487/RFC0771 RFC0772 Mail Transfer Protocol S. Sluizer J. Postel September 1980 ASCII HTML 31 MTP email RFC0780 UNKNOWN UNKNOWN Legacy 10.17487/RFC0772 RFC0773 Comments on NCP/TCP mail service transition strategy V.G. Cerf October 1980 ASCII HTML 11 UNKNOWN UNKNOWN Legacy 10.17487/RFC0773 RFC0774 Internet Protocol Handbook: Table of contents J. Postel October 1980 ASCII HTML 3 RFC0766 UNKNOWN UNKNOWN Legacy 10.17487/RFC0774 RFC0775 Directory oriented FTP commands D. Mankins D. Franklin A.D. Owen December 1980 ASCII HTML 6 UNKNOWN UNKNOWN Legacy 10.17487/RFC0775 RFC0776 Assigned numbers J. Postel January 1981 ASCII HTML 13 RFC0770 RFC0790 HISTORIC UNKNOWN Legacy 10.17487/RFC0776 RFC0777 Internet Control Message Protocol J. Postel April 1981 ASCII HTML 14 RFC0792 RFC0760 UNKNOWN UNKNOWN Legacy 10.17487/RFC0777 RFC0778 DCNET Internet Clock Service D.L. Mills April 1981 ASCII HTML 4 CLOCK HISTORIC HISTORIC Legacy 10.17487/RFC0778 RFC0779 Telnet send-location option E. Killian April 1981 ASCII HTML 2 TOPT-SNDL PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0779 RFC0780 Mail Transfer Protocol S. Sluizer J. Postel May 1981 ASCII HTML 47 MTP email RFC0772 RFC0788 UNKNOWN UNKNOWN Legacy 10.17487/RFC0780 RFC0781 Specification of the Internet Protocol (IP) timestamp option Z. Su May 1981 ASCII HTML 1 UNKNOWN UNKNOWN Legacy 10.17487/RFC0781 RFC0782 Virtual Terminal management model J. Nabielsky A.P. Skelton January 1981 ASCII HTML 23 UNKNOWN UNKNOWN Legacy 10.17487/RFC0782 RFC0783 TFTP Protocol (revision 2) K.R. Sollins June 1981 ASCII HTML 18 IEN133 RFC1350 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=783 10.17487/RFC0783 RFC0784 Mail Transfer Protocol: ISI TOPS20 implementation S. Sluizer J. Postel July 1981 ASCII HTML 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0784 RFC0785 Mail Transfer Protocol: ISI TOPS20 file definitions S. Sluizer J. Postel July 1981 ASCII HTML 3 MTP email UNKNOWN UNKNOWN Legacy 10.17487/RFC0785 RFC0786 Mail Transfer Protocol: ISI TOPS20 MTP-NIMAIL interface S. Sluizer J. Postel July 1981 ASCII HTML 2 MTP NIMAIL TOPS20 UNKNOWN UNKNOWN Legacy 10.17487/RFC0786 RFC0787 Connectionless data transmission survey/tutorial A.L. Chapin July 1981 ASCII HTML 40 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=787 10.17487/RFC0787 RFC0788 Simple Mail Transfer Protocol J. Postel November 1981 ASCII HTML 64 SMTP email RFC0780 RFC0821 UNKNOWN UNKNOWN Legacy 10.17487/RFC0788 RFC0789 Vulnerabilities of network control protocols: An example E.C. Rosen July 1981 ASCII HTML 16 UNKNOWN UNKNOWN Legacy 10.17487/RFC0789 RFC0790 Assigned numbers J. Postel September 1981 ASCII HTML 15 RFC0776 RFC0820 HISTORIC UNKNOWN Legacy 10.17487/RFC0790 RFC0791 Internet Protocol J. Postel September 1981 ASCII HTML 51 IP IPv4 RFC0760 RFC1349 RFC2474 RFC6864 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=791 10.17487/RFC0791 RFC0792 Internet Control Message Protocol J. Postel September 1981 ASCII HTML 21 ICMP RFC0777 RFC0950 RFC4884 RFC6633 RFC6918 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=792 10.17487/RFC0792 RFC0793 Transmission Control Protocol J. Postel September 1981 ASCII HTML 91 TCP TCP RFC0761 RFC1122 RFC3168 RFC6093 RFC6528 STD0007 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=793 10.17487/RFC0793 RFC0794 Pre-emption V.G. Cerf September 1981 ASCII HTML 2 IEN125 INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0794 RFC0795 Service mappings J. Postel September 1981 ASCII HTML 4 HISTORIC UNKNOWN Legacy 10.17487/RFC0795 RFC0796 Address mappings J. Postel September 1981 ASCII HTML 7 IEN115 HISTORIC UNKNOWN Legacy 10.17487/RFC0796 RFC0797 Format for Bitmap files A.R. Katz September 1981 ASCII HTML 2 UNKNOWN UNKNOWN Legacy 10.17487/RFC0797 RFC0798 Decoding facsimile data from the Rapicom 450 A.R. Katz September 1981 ASCII HTML 17 UNKNOWN UNKNOWN Legacy 10.17487/RFC0798 RFC0799 Internet name domains D.L. Mills September 1981 ASCII HTML 5 UNKNOWN UNKNOWN Legacy 10.17487/RFC0799 RFC0800 Request For Comments summary notes: 700-799 J. Postel J. Vernon November 1982 ASCII HTML 10

This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0800
RFC0801 NCP/TCP transition plan J. Postel November 1981 ASCII HTML 21

This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0801
RFC0802 ARPANET 1822L Host Access Protocol A.G. Malis November 1981 ASCII HTML 45

This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.

RFC0851 UNKNOWN UNKNOWN Legacy 10.17487/RFC0802
RFC0803 Dacom 450/500 facsimile data transcoding A. Agarwal M.J. O'Connor D.L. Mills November 1981 ASCII HTML 14

The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0803
RFC0804 CCITT draft recommendation T.4 International Telegraph and Telephone Consultative Committee of the International Telecommunication Union January 1981 ASCII HTML 12

This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.

UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=804 10.17487/RFC0804
RFC0805 Computer mail meeting notes J. Postel February 1982 ASCII HTML 6

This RFC consists of notes from a meeting that was held at USC Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further strutured.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0805
RFC0806 Proposed Federal Information Processing Standard: Specification for message format for computer based message systems National Bureau of Standards September 1981 ASCII HTML 107

This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the format of messages passed between them. This RFC is replaced by RFC 841.

RFC0841 UNKNOWN UNKNOWN Legacy 10.17487/RFC0806
RFC0807 Multimedia mail meeting notes J. Postel February 1982 ASCII HTML 6

This RFC consists of notes from a meeting held at USC Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0807
RFC0808 Summary of computer mail services meeting held at BBN on 10 January 1979 J. Postel March 1982 ASCII HTML 8

This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0808
RFC0809 UCL facsimile system T. Chang February 1982 ASCII HTML 99

This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0809
RFC0810 DoD Internet host table specification E.J. Feinler K. Harrenstien Z. Su V. White March 1982 ASCII HTML 8

This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.

RFC0608 RFC0952 UNKNOWN UNKNOWN Legacy 10.17487/RFC0810
RFC0811 Hostnames Server K. Harrenstien V. White E.J. Feinler March 1982 ASCII HTML 4

This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.

RFC0953 UNKNOWN UNKNOWN Legacy 10.17487/RFC0811
RFC0812 NICNAME/WHOIS K. Harrenstien V. White March 1982 ASCII HTML 2

This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.

RFC0954 RFC3912 UNKNOWN UNKNOWN Legacy 10.17487/RFC0812
RFC0813 Window and Acknowledgement Strategy in TCP D.D. Clark July 1982 ASCII HTML 21

This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.

RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0813
RFC0814 Name, addresses, ports, and routes D.D. Clark July 1982 ASCII HTML 13

This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.

INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0814
RFC0815 IP datagram reassembly algorithms D.D. Clark July 1982 ASCII HTML 8

This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0815
RFC0816 Fault isolation and recovery D.D. Clark July 1982 ASCII HTML 11

This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.

RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0816
RFC0817 Modularity and efficiency in protocol implementation D.D. Clark July 1982 ASCII HTML 25

This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.

INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0817
RFC0818 Remote User Telnet service J. Postel November 1982 ASCII HTML 2 RTELNET

This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.

HISTORIC HISTORIC Legacy 10.17487/RFC0818
RFC0819 The Domain Naming Convention for Internet User Applications Z. Su J. Postel August 1982 ASCII HTML 18

This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0819
RFC0820 Assigned numbers J. Postel August 1982 ASCII HTML 22

This RFC is an old version, see RFC 870.

RFC0790 RFC0870 HISTORIC UNKNOWN Legacy 10.17487/RFC0820
RFC0821 Simple Mail Transfer Protocol J. Postel August 1982 ASCII HTML 72 SMTP

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFC 788, 780, and 772.

RFC0788 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0821
RFC0822 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES D. Crocker August 1982 ASCII HTML 49 MAIL

This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.

RFC0733 RFC2822 RFC1123 RFC2156 RFC1327 RFC1138 RFC1148 STD0011 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=822 10.17487/RFC0822
RFC0823 DARPA Internet gateway R.M. Hinden A. Sheltzer September 1982 ASCII HTML 45 GGP

This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.

IEN109 IEN30 HISTORIC HISTORIC Legacy 10.17487/RFC0823
RFC0824 CRONUS Virtual Local Network W.I. MacGregor D.C. Tappan August 1982 ASCII HTML 41

The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA Internet community. This note is intended to stimulate discussion. This is not a specification of an Internet Standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0824
RFC0825 Request for comments on Requests For Comments J. Postel November 1982 ASCII HTML 2

This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.

RFC1111 RFC1543 RFC2223 UNKNOWN UNKNOWN Legacy 10.17487/RFC0825
RFC0826 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware D. Plummer November 1982 ASCII HTML 10 ARP

The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard.

RFC5227 RFC5494 STD0037 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0826
RFC0827 Exterior Gateway Protocol (EGP) E.C. Rosen October 1982 ASCII HTML 46

This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.

RFC0904 UNKNOWN UNKNOWN Legacy 10.17487/RFC0827
RFC0828 Data communications: IFIP's international "network" of experts K. Owen August 1982 ASCII HTML 11

This RFC is distributed to inform the ARPA Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0828
RFC0829 Packet satellite technology reference sources V.G. Cerf November 1982 ASCII HTML 5

This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0829
RFC0830 Distributed system for Internet name service Z. Su October 1982 ASCII HTML 18

This RFC proposes a distributed name service for DARPA Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0830
RFC0831 Backup access to the European side of SATNET R.T. Braden December 1982 ASCII HTML 6

The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0831
RFC0832 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.

RFC0833 UNKNOWN UNKNOWN Legacy 10.17487/RFC0832
RFC0833 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.

RFC0832 RFC0834 UNKNOWN UNKNOWN Legacy 10.17487/RFC0833
RFC0834 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.

RFC0833 RFC0835 UNKNOWN UNKNOWN Legacy 10.17487/RFC0834
RFC0835 Who talks TCP? D. Smallberg December 1982 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.

RFC0834 RFC0836 UNKNOWN UNKNOWN Legacy 10.17487/RFC0835
RFC0836 Who talks TCP? D. Smallberg January 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 through 5-Jan-83.

RFC0835 RFC0837 UNKNOWN UNKNOWN Legacy 10.17487/RFC0836
RFC0837 Who talks TCP? D. Smallberg January 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.

RFC0836 RFC0838 UNKNOWN UNKNOWN Legacy 10.17487/RFC0837
RFC0838 Who talks TCP? D. Smallberg January 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.

RFC0837 RFC0839 UNKNOWN UNKNOWN Legacy 10.17487/RFC0838
RFC0839 Who talks TCP? D. Smallberg January 1983 ASCII HTML 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.

RFC0838 RFC0842 UNKNOWN UNKNOWN Legacy 10.17487/RFC0839
RFC0840 Official protocols J. Postel April 1983 ASCII HTML 23

This RFC has been revised, see RFC 880.

RFC0880 HISTORIC UNKNOWN Legacy 10.17487/RFC0840
RFC0841 Specification for message format for Computer Based Message Systems National Bureau of Standards January 1983 ASCII HTML 117

This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA Internet. Obsoletes RFC 806.

RFC0806 UNKNOWN UNKNOWN Legacy 10.17487/RFC0841
RFC0842 Who talks TCP? - survey of 1 February 83 D. Smallberg February 1983 ASCII HTML 12

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.

RFC0839 RFC0843 UNKNOWN UNKNOWN Legacy 10.17487/RFC0842
RFC0843 Who talks TCP? - survey of 8 February 83 D. Smallberg February 1983 ASCII HTML 13

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.

RFC0842 RFC0845 RFC0844 UNKNOWN UNKNOWN Legacy 10.17487/RFC0843
RFC0844 Who talks ICMP, too? - Survey of 18 February 1983 R. Clements February 1983 ASCII HTML 5

This survey determines how many hosts are able to respond to TELENET connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting TELNET connection. The tests were run on 18-Feb-83.

RFC0843 UNKNOWN UNKNOWN Legacy 10.17487/RFC0844
RFC0845 Who talks TCP? - survey of 15 February 1983 D. Smallberg February 1983 ASCII HTML 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.

RFC0843 RFC0846 UNKNOWN UNKNOWN Legacy 10.17487/RFC0845
RFC0846 Who talks TCP? - survey of 22 February 1983 D. Smallberg February 1983 ASCII HTML 14

This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.

RFC0845 RFC0847 UNKNOWN UNKNOWN Legacy 10.17487/RFC0846
RFC0847 Summary of Smallberg surveys A. Westine D. Smallberg J. Postel February 1983 ASCII HTML 2

This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the Internet (not counting TACs or ECHOS).

RFC0846 UNKNOWN UNKNOWN Legacy 10.17487/RFC0847
RFC0848 Who provides the "little" TCP services? D. Smallberg March 1983 ASCII HTML 5

This RFC lists those hosts which provide any of these "little" TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0848
RFC0849 Suggestions for improved host table distribution M.R. Crispin May 1983 ASCII HTML 2

This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0849
RFC0850 Standard for interchange of USENET messages M.R. Horton June 1983 ASCII HTML 17

This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.

RFC1036 UNKNOWN UNKNOWN Legacy 10.17487/RFC0850
RFC0851 ARPANET 1822L Host Access Protocol A.G. Malis April 1983 ASCII HTML 47

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.

RFC0802 RFC0878 UNKNOWN UNKNOWN Legacy 10.17487/RFC0851
RFC0852 ARPANET short blocking feature A.G. Malis April 1983 ASCII HTML 13

This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0852
RFC0853 RFC0854 Telnet Protocol Specification J. Postel J.K. Reynolds May 1983 ASCII HTML 15 TELNET

This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.

RFC0764 RFC5198 STD0008 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=854 10.17487/RFC0854
RFC0855 Telnet Option Specifications J. Postel J.K. Reynolds May 1983 ASCII HTML 3 TELNET

This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.

NIC18640 STD0008 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0855
RFC0856 Telnet Binary Transmission J. Postel J. Reynolds May 1983 ASCII HTML 4 TOPT-BIN

This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15389.

NIC15389 STD0027 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0856
RFC0857 Telnet Echo Option J. Postel J. Reynolds May 1983 ASCII HTML 5 TOPT-ECHO

This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15390.

NIC15390 STD0028 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0857
RFC0858 Telnet Suppress Go Ahead Option J. Postel J. Reynolds May 1983 ASCII HTML 2 TOPT-SUPP

This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 15392.

NIC15392 STD0029 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0858
RFC0859 Telnet Status Option J. Postel J. Reynolds May 1983 ASCII HTML 3 TOPT-STAT

This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).

RFC0651 STD0030 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0859
RFC0860 Telnet Timing Mark Option J. Postel J. Reynolds May 1983 ASCII HTML 4 TOPT-TIM

This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16238.

NIC16238 STD0031 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0860
RFC0861 Telnet Extended Options: List Option J. Postel J. Reynolds May 1983 ASCII HTML 2 TOPT-EXTOP

This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes NIC 16239.

NIC16239 STD0032 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0861
RFC0862 Echo Protocol J. Postel May 1983 ASCII HTML 1 ECHO

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives.

STD0020 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0862
RFC0863 Discard Protocol J. Postel May 1983 ASCII HTML 1 DISCARD

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives.

STD0021 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0863
RFC0864 Character Generator Protocol J. Postel May 1983 ASCII HTML 3 CHARGEN

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.

STD0022 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=864 10.17487/RFC0864
RFC0865 Quote of the Day Protocol J. Postel May 1983 ASCII HTML 1 QUOTE

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.

STD0023 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0865
RFC0866 Active users J. Postel May 1983 ASCII HTML 1 USERS

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input.

STD0024 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0866
RFC0867 Daytime Protocol J. Postel May 1983 ASCII HTML 2 DAYTIME

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input.

STD0025 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0867
RFC0868 Time Protocol J. Postel K. Harrenstien May 1983 ASCII HTML 2 TIME

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900.

STD0026 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=868 10.17487/RFC0868
RFC0869 Host Monitoring Protocol R. Hinden December 1983 ASCII HTML 72 HMP HMP

This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.

HISTORIC HISTORIC Legacy 10.17487/RFC0869
RFC0870 Assigned numbers J.K. Reynolds J. Postel October 1983 ASCII HTML 26

This RFC documents the list of numbers assigned for networks, protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, 750, 739, 604.

RFC0820 RFC0900 HISTORIC UNKNOWN Legacy 10.17487/RFC0870
RFC0871 Perspective on the ARPANET reference model M.A. Padlipsky September 1982 ASCII HTML 29

This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0871
RFC0872 TCP-on-a-LAN M.A. Padlipsky September 1982 ASCII HTML 10 TCP LAN

This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.

INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0872
RFC0873 Illusion of vendor support M.A. Padlipsky September 1982 ASCII HTML 12

This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0873
RFC0874 Critique of X.25 M.A. Padlipsky September 1982 ASCII HTML 17

This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0874
RFC0875 Gateways, architectures, and heffalumps M.A. Padlipsky September 1982 ASCII HTML 10

This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0875
RFC0876 Survey of SMTP implementations D. Smallberg September 1983 ASCII HTML 13

This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0876
RFC0877 Standard for the transmission of IP datagrams over public data networks J.T. Korb September 1983 ASCII HTML 2

This RFC specifies a standard adopted by CSNET, the VAN gateway, and other organizations for the transmission of IP datagrams over the X.25-based public data networks.

RFC1356 UNKNOWN UNKNOWN Legacy 10.17487/RFC0877
RFC0878 ARPANET 1822L Host Access Protocol A.G. Malis December 1983 ASCII HTML 51

This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.

RFC0851 UNKNOWN UNKNOWN Legacy 10.17487/RFC0878
RFC0879 The TCP Maximum Segment Size and Related Topics J. Postel November 1983 ASCII HTML 11

This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".

RFC7805 RFC6691 HISTORIC UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=879 10.17487/RFC0879
RFC0880 Official protocols J.K. Reynolds J. Postel October 1983 ASCII HTML 26

This RFC identifies the documents specifying the official protocols used in the ARPA Internet. Annotations identify any revisions or changes planned. Obsoletes RFC 840.

RFC0840 RFC0901 HISTORIC UNKNOWN Legacy 10.17487/RFC0880
RFC0881 Domain names plan and schedule J. Postel November 1983 ASCII HTML 10

This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA Internet.

RFC0897 UNKNOWN UNKNOWN Legacy 10.17487/RFC0881
RFC0882 Domain names: Concepts and facilities P.V. Mockapetris November 1983 ASCII HTML 31

This RFC introduces domain style names, their use for ARPA Internet mail and host address support, and the protocol and servers used to implement domain name facilities.

RFC1034 RFC1035 RFC0973 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=882 10.17487/RFC0882
RFC0883 Domain names: Implementation specification P.V. Mockapetris November 1983 ASCII HTML 74

This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.

RFC1034 RFC1035 RFC0973 UNKNOWN UNKNOWN Legacy 10.17487/RFC0883
RFC0884 Telnet terminal type option M. Solomon E. Wimmers December 1983 ASCII HTML 5

This RFC specifies a standard for the ARPA Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.

RFC0930 UNKNOWN UNKNOWN Legacy 10.17487/RFC0884
RFC0885 Telnet end of record option J. Postel December 1983 ASCII HTML 2 TOPT-EOR

This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0885
RFC0886 Proposed standard for message header munging M.T. Rose December 1983 ASCII HTML 16

This RFC specifies a draft standard for the ARPA Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0886
RFC0887 Resource Location Protocol M. Accetta December 1983 ASCII HTML 16 RLP

This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0887
RFC0888 "STUB" Exterior Gateway Protocol L. Seamonson E.C. Rosen January 1984 ASCII HTML 39

This RFC describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document.

RFC0904 UNKNOWN UNKNOWN Legacy 10.17487/RFC0888
RFC0889 Internet Delay Experiments D.L. Mills December 1983 ASCII HTML 12

This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers.

INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0889
RFC0890 Exterior Gateway Protocol implementation schedule J. Postel February 1984 ASCII HTML 3 EGP

This memo is a policy statement on the implementation of the Exterior Gateway Protocol in the Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0890
RFC0891 DCN Local-Network Protocols D.L. Mills December 1983 ASCII HTML 26 IP-DC

This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.

STD0044 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0891
RFC0892 ISO Transport Protocol specification International Organization for Standardization December 1983 ASCII HTML 82

This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date.

RFC0905 UNKNOWN UNKNOWN Legacy 10.17487/RFC0892
RFC0893 Trailer encapsulations S. Leffler M.J. Karels April 1984 ASCII HTML 6

This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA Internet community.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0893
RFC0894 A Standard for the Transmission of IP Datagrams over Ethernet Networks C. Hornig April 1984 ASCII HTML 3 IP-E

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.

STD0041 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=894 10.17487/RFC0894
RFC0895 Standard for the transmission of IP datagrams over experimental Ethernet networks J. Postel April 1984 ASCII HTML 3 IP-EE

This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA Internet community.

STD0042 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0895
RFC0896 Congestion Control in IP/TCP Internetworks J. Nagle January 1984 ASCII HTML 9

This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.

RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC0896
RFC0897 Domain name system implementation schedule J. Postel February 1984 ASCII HTML 8

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The names of hosts will be changed to domain style names. Hosts will begin to use domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.

RFC0881 RFC0921 UNKNOWN UNKNOWN Legacy 10.17487/RFC0897
RFC0898 Gateway special interest group meeting notes R.M. Hinden J. Postel M. Muuss J.K. Reynolds April 1984 ASCII HTML 24

This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on a meeting. No conclusions, decisions, or policy statements are documented in this note.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0898
RFC0899 Request For Comments summary notes: 800-899 J. Postel A. Westine May 1984 ASCII HTML 18 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC0899 RFC0900 Assigned Numbers J.K. Reynolds J. Postel June 1984 ASCII HTML 43

This RFC specifies parameter values use in the Internet family of protocols, such as network numbers, well known ports, protocol types, and version numbers. This memo is an official status report on the protocol parameters used in the Internet protocol system. See RFC-990 and 997.

RFC0870 RFC0923 HISTORIC UNKNOWN Legacy 10.17487/RFC0900
RFC0901 Official ARPA-Internet protocols J.K. Reynolds J. Postel June 1984 ASCII HTML 28

This RFC identifies the documents specifying the official protocols used in the ARPA-Internet. Annotations identify any revisions or changes planned. This memo is an official status report on the protocols used in the DARPA research community. See RFC-991.

RFC0880 RFC0924 UNKNOWN UNKNOWN Legacy 10.17487/RFC0901
RFC0902 ARPA Internet Protocol policy J.K. Reynolds J. Postel July 1984 ASCII HTML 5

The purpose of this memo is to explain how protocol standards are adopted for the ARPA-Internet and the DARPA research community. There are three important aspects to be discussed: the process, the authority, and the complex relationship between the DARPA community and the DDN community. This memo is a policy statement on how protocols become official standards for the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0902
RFC0903 A Reverse Address Resolution Protocol R. Finlayson T. Mann J.C. Mogul M. Theimer June 1984 ASCII HTML 4 RARP

This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.

STD0038 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0903
RFC0904 Exterior Gateway Protocol formal specification D.L. Mills April 1984 ASCII HTML 30 EGP

RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet.

RFC0827 RFC0888 HISTORIC HISTORIC Legacy 10.17487/RFC0904
RFC0905 ISO Transport Protocol specification ISO DP 8073 ISO April 1984 ASCII HTML 164

This is the current specification of the ISO Transport Protocol. This document is the text of ISO/TC97/SC16/N1576 as corrected by ISO/TC97/SC16/N1695. This is the specification currently being voted on in ISO as a Draft International Standard (DIS). This document is distributed as an RFC for your information only, it does not specify a standard for the ARPA-Internet or DARPA research community. Our thanks to Alex McKenzie of BBN for making this online version available. Please note the size of this document, the file contains 258,729 characters.

RFC0892 UNKNOWN UNKNOWN Legacy 10.17487/RFC0905
RFC0906 Bootstrap loading using TFTP R. Finlayson June 1984 ASCII HTML 4

It is often convenient to be able to bootstrap a computer system from a communications network. This RFC proposes the use of the IP TFTP protocol for bootstrap loading in this case.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0906
RFC0907 Host Access Protocol specification Bolt Beranek Newman Laboratories July 1984 ASCII HTML 75 IP-WB

This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.

RFC1221 STD0040 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0907
RFC0908 Reliable Data Protocol D. Velten R.M. Hinden J. Sax July 1984 ASCII HTML 62 RDP

The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

RFC1151 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0908
RFC0909 Loader Debugger Protocol C. Welles W. Milliken July 1984 ASCII HTML 135 LDP

The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0909
RFC0910 Multimedia mail meeting notes H.C. Forsdick August 1984 ASCII HTML 11

This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). The meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0910
RFC0911 EGP Gateway under Berkeley UNIX 4.2 P. Kirton August 1984 ASCII HTML 23

This memo describes an implementation of the Exterior Gateway Protocol (EGP) (in that sense it is a status report). The memo also discusses some possible extentions and some design issues (in that sense it is an invitation for further discussion).

UNKNOWN UNKNOWN Legacy 10.17487/RFC0911
RFC0912 Authentication service M. St. Johns September 1984 ASCII HTML 3

This memo describes a proposed authentication protocol for verifying the identity of a user of a TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system. Suggested uses include automatic identification and verification of a user during an FTP session, additional verification of a TAC dial up user, and access verification for a generalized network file server.

RFC0931 UNKNOWN UNKNOWN Legacy 10.17487/RFC0912
RFC0913 Simple File Transfer Protocol M. Lottor September 1984 ASCII HTML 15 SFTP FTP

This memo describes a proposed Simple File Transfer Protocol (SFTP). It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting. Discussion of this proposal is encouraged, and suggestions for improvements may be sent to the author.

HISTORIC HISTORIC Legacy 10.17487/RFC0913
RFC0914 Thinwire protocol for connecting personal computers to the Internet D.J. Farber G. Delp T.M. Conte September 1984 ASCII HTML 22 THINWIRE

This RFC focuses discussion on the particular problems in the ARPA-Internet of low speed network interconnection with personal computers, and possible methods of solution. None of the proposed solutions in this document are intended as standards for the ARPA-Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to the problems, leading eventually to the adoption of standards.

HISTORIC HISTORIC Legacy 10.17487/RFC0914
RFC0915 Network mail path service M.A. Elvy R. Nedved December 1984 ASCII HTML 11

This RFC proposed a new service for the ARPA-Internet community and requests discussion and suggestions for improvements. The network mail path service fills the current need of people to determine mailbox addresses for hosts that are not part of the ARPA-Internet but can be reached by one or more relay hosts that have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, etc. Anyone can use the service if they have TCP/TELENET to one of the hosts with a mail path server.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0915
RFC0916 Reliable Asynchronous Transfer Protocol (RATP) G.G. Finn October 1984 ASCII HTML 54 RATP

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.

HISTORIC HISTORIC Legacy 10.17487/RFC0916
RFC0917 Internet subnets J.C. Mogul October 1984 ASCII HTML 22

This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=917 10.17487/RFC0917
RFC0918 Post Office Protocol J.K. Reynolds October 1984 ASCII HTML 5

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. The intent of the Post Office Protocol (POP) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. The status of this protocol is experimental, and this protocol is dependent upon TCP.

RFC0937 UNKNOWN UNKNOWN Legacy 10.17487/RFC0918
RFC0919 Broadcasting Internet Datagrams J.C. Mogul October 1984 ASCII HTML 8

This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0919
RFC0920 Domain requirements J. Postel J.K. Reynolds October 1984 ASCII HTML 14

This memo states the requirements on establishing a Domain, and introduces the limited set of top level domains. This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0920
RFC0921 Domain name system implementation schedule - revised J. Postel October 1984 ASCII HTML 13

This memo is a policy statement on the implementation of the Domain Style Naming System in the Internet. This memo is an update of RFC-881, and RFC-897. This is an official policy statement of the IAB and the DARPA. The intent of this memo is to detail the schedule for the implementation for the Domain Style Naming System. The explanation of how this system works is to be found in the references.

RFC0897 UNKNOWN UNKNOWN Legacy 10.17487/RFC0921
RFC0922 Broadcasting Internet datagrams in the presence of subnets J.C. Mogul October 1984 ASCII HTML 12

We propose simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0922
RFC0923 Assigned numbers J.K. Reynolds J. Postel October 1984 ASCII HTML 47

This RFC documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers obsoletes RFC-900 and earlier editions. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990, and 997.

RFC0900 RFC0943 HISTORIC UNKNOWN Legacy 10.17487/RFC0923
RFC0924 Official ARPA-Internet protocols for connecting personal computers to the Internet J.K. Reynolds J. Postel October 1984 ASCII HTML 35

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-900 and earlier editions. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

RFC0901 RFC0944 UNKNOWN UNKNOWN Legacy 10.17487/RFC0924
RFC0925 Multi-LAN address resolution J. Postel October 1984 ASCII HTML 15

The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subnets" in a multi-LAN environment. The explicit subnet scheme is a call to recursively apply the mechanisms the Internet uses to manage networks to the problem of managing LANs within one network. In this note I urge another approach: the use of "transparent subnets" supported by a multi-LAN extension of the Address Resolution Protocol. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0925
RFC0926 Protocol for providing the connectionless mode network services International Organization for Standardization December 1984 ASCII HTML 107

This note is the draft ISO protocol roughly similar to the DOD Internet Protocol. This document has been prepared by retyping the text of ISO DIS 8473 of May 1984, which is currently undergoing voting within ISO as a Draft International Standard (DIS). This document is distributred as an RFC for information only. It does not specify a standard for the ARPA-Internet.

RFC0994 UNKNOWN UNKNOWN Legacy 10.17487/RFC0926
RFC0927 TACACS user identification Telnet option B.A. Anderson December 1984 ASCII HTML 4 TOPT-TACACS

The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0927
RFC0928 Introduction to proposed DoD standard H-FP M.A. Padlipsky December 1984 ASCII HTML 21

The broad outline of the Host-Front End Protocol introduced here and described in RFC-929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel. It is the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0928
RFC0929 Proposed Host-Front End Protocol J. Lilienkamp R. Mandell M.A. Padlipsky December 1984 ASCII HTML 56 HFEP

The Host-Front End Protocol introduced in RFC-928 is described in detail in this memo. The first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

HISTORIC HISTORIC Legacy 10.17487/RFC0929
RFC0930 Telnet terminal type option M. Solomon E. Wimmers January 1985 ASCII HTML 4

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC-884. The only change is to specify that the TERMINAL-TYPE IS sub-negotiation should be sent only in response to the TERMINAL-TYPE SEND sub-negotiation.

RFC0884 RFC1091 UNKNOWN UNKNOWN Legacy 10.17487/RFC0930
RFC0931 Authentication server M. St. Johns January 1985 ASCII HTML 5

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is the second draft of this proposal (superseding RFC-912) and incorporates a more formal description of the syntax for the request and response dialog, as well as a change to specify the type of user identification returned.

RFC0912 RFC1413 UNKNOWN UNKNOWN Legacy 10.17487/RFC0931
RFC0932 Subnetwork addressing scheme D.D. Clark January 1985 ASCII HTML 4

This RFC proposes an alternative addressing scheme for subnets which, in most cases, requires no modification to host software whatsoever. The drawbacks of this scheme are that the total number of subnets in any one network are limited, and that modification is required to all gateways.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0932
RFC0933 Output marking Telnet option S. Silverman January 1985 ASCII HTML 4 TOPT-OM

This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0933
RFC0934 Proposed standard for message encapsulation M.T. Rose E.A. Stefferud January 1985 ASCII HTML 10

This memo concerns itself with message forwarding. Forwarding can be thought of as encapsulating one or more messages inside another. Although this is useful for transfer of past correspondence to new recipients, without a decapsulation process (which this memo terms "bursting"), the forwarded messages are of little use to the recipients because they can not be distributed, forwarded, replied-to, or otherwise processed as separate individual messages. In order to burst a message it is necessary to know how the component messages were encapsulated in the draft. At present there is no unambiguous standard for interest group digests. This RFC proposes a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0934
RFC0935 Reliable link layer protocols J.G. Robinson January 1985 ASCII HTML 12

This RFC discusses protocols proposed recently in RFCs 914 and 916, and suggests a proposed protocol that could meet the same needs addressed in those memos. The stated need is reliable communication between two programs over a full-duplex, point-to-point communication link, and in particular the RFCs address the need for such communication over an asynchronous link at relatively low speeds. The suggested protocol uses the methods of existing national and international data link layer standards. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0935
RFC0936 Another Internet subnet addressing scheme M.J. Karels February 1985 ASCII HTML 4

There have been several proposals for schemes to allow the use of a single Internet network number to refer to a collection of physical networks under common administration which are reachable from the rest of the Internet by a common route. Such schemes allow a simplified view of an otherwise complicated topology from hosts and gateways outside of this collection. They allow the complexity of the number and type of these networks, and routing to them, to be localized. Additions and changes in configuration thus cause no detectable change, and no interruption of service, due to slow propagation of routing and other information outside of the local environment. These schemes also simplify the administration of the network, as changes do not require allocation of new network numbers for each new cable installed. This proposal discusses an alternative scheme, one that has been in use at the University of California, Berkeley since April 1984. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0936
RFC0937 Post Office Protocol: Version 2 M. Butler J. Postel D. Chase J. Goldberger J.K. Reynolds February 1985 ASCII HTML 24 POP2 Post Office Protocol Version 2

This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC-918.

RFC0918 HISTORIC HISTORIC Legacy 10.17487/RFC0937
RFC0938 Internet Reliable Transaction Protocol functional and interface specification T. Miller February 1985 ASCII HTML 19 IRTP

This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0938
RFC0939 Executive summary of the NRC report on transport protocols for Department of Defense data networks National Research Council February 1985 ASCII HTML 20

This RFC reproduces the material from the "front pages" of the National Research Council report resulting from a study of the DOD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4). The point of this RFC is to make the text of the Executive Summary widely available in a timely way. The order of presentation has been altered, and the pagination changed. This RFC is distributed for information only. This RFC does not establish any policy for the DARPA research community or the DDN operational community.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0939
RFC0940 Toward an Internet standard scheme for subnetting Gateway Algorithms and Data Structures Task Force April 1985 ASCII HTML 3

Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subnetting, the individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways). This RFC discusses standardizing the protocol used in subnetted environments in the ARPA-Internet.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0940
RFC0941 Addendum to the network service definition covering network layer addressing International Organization for Standardization April 1985 ASCII HTML 34

This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address defined in this Addendum is the address that appears in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters, and in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0941
RFC0942 Transport protocols for Department of Defense data networks National Research Council February 1985 ASCII HTML 88

This RFC reproduces the National Research Council report resulting from a study of the DoD Internet Protocol (IP) and Transmission Control Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).

UNKNOWN UNKNOWN Legacy 10.17487/RFC0942
RFC0943 Assigned numbers J.K. Reynolds J. Postel April 1985 ASCII HTML 50

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number assignment. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

RFC0923 RFC0960 HISTORIC UNKNOWN Legacy 10.17487/RFC0943
RFC0944 Official ARPA-Internet protocols J.K. Reynolds J. Postel April 1985 ASCII HTML 40

This RFC identifies the documents specifying the official protocols used in the Internet. This edition of Official ARPA-Internet Protocols obsoletes RFC-924 and earlier editions. This RFC will be updated periodically, and current information can be obtained from Joyce Reynolds. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

RFC0924 RFC0961 UNKNOWN UNKNOWN Legacy 10.17487/RFC0944
RFC0945 DoD statement on the NRC report J. Postel May 1985 ASCII HTML 2

In May 1983 the National Research Council (NRC) was asked jointly by DoD and NBS to study the issues and recommend a course of action. The final report of the NRC committee was published in February 1985 (see RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to DCA transmitting the NRC report and requesting specific actions relative to the recommendations of the report. This RFC reproduces a letter from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC3I) to the Director of the Defense Communications Agency (DCA). This letter is distributed for information only.

RFC1039 UNKNOWN UNKNOWN Legacy 10.17487/RFC0945
RFC0946 Telnet terminal location number option R. Nedved May 1985 ASCII HTML 4 TOPT-TLN

Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0946
RFC0947 Multi-network broadcasting within the Internet K. Lebowitz D. Mankins June 1985 ASCII HTML 5

This RFC describes the extension of a network's broadcast domain to include more than one physical network through the use of a broadcast packet repeater.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0947
RFC0948 Two methods for the transmission of IP datagrams over IEEE 802.3 networks I. Winston June 1985 ASCII HTML 7

This RFC describes two methods of encapsulating Internet Protocol (IP) datagrams on an IEEE 802.3 network. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC1042 UNKNOWN UNKNOWN Legacy 10.17487/RFC0948
RFC0949 FTP unique-named store command M.A. Padlipsky July 1985 ASCII HTML 2

There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name istead caused the resultant file to have a unique name relative to the current directory. This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. See RFC-959.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0949
RFC0950 Internet Standard Subnetting Procedure J.C. Mogul J. Postel August 1985 ASCII HTML 18 Address

This memo discusses the utility of "subnets" of Internet networks, which are logically visible sub-sections of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This memo specifies procedures for the use of subnets. These procedures are for hosts (e.g., workstations). The procedures used in and between subnet gateways are not fully described. Important motivation and background information for a subnetting standard is provided in RFC-940. This RFC specifies a protocol for the ARPA-Internet community. If subnetting is implemented it is strongly recommended that these procedures be followed.

RFC0792 RFC6918 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC0950
RFC0951 Bootstrap Protocol W.J. Croft J. Gilmore September 1985 ASCII HTML 12 BOOTP

This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC1395 RFC1497 RFC1532 RFC1542 RFC5494 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=951 10.17487/RFC0951
RFC0952 DoD Internet host table specification K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII HTML 6

This RFC is the official specification of the format of the Internet Host Table. This edition of the specification includes minor revisions to RFC-810 which brings it up to date.

RFC0810 RFC1123 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=952 10.17487/RFC0952
RFC0953 Hostname Server K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII HTML 5 HOSTNAME

This RFC is the official specification of the Hostname Server Protocol. This edition of the specification includes minor revisions to RFC-811 which brings it up to date.

RFC0811 HISTORIC HISTORIC Legacy 10.17487/RFC0953
RFC0954 NICNAME/WHOIS K. Harrenstien M.K. Stahl E.J. Feinler October 1985 ASCII HTML 4 NICNAME

This RFC is the official specification of the NICNAME/WHOIS protocol. This memo describes the protocol and the service. This is an update of RFC-812.

RFC0812 RFC3912 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC0954
RFC0955 Towards a transport service for transaction processing applications R.T. Braden September 1985 ASCII HTML 10

The DoD Internet protocol suite includes two alternative transport service protocols, TCP and UDP, which provide virtual circuit and datagram service, respectively. These two protocols represent points in the space of possible transport service attributes which are quite "far apart". We want to examine an important class of applications, those which perform what is often called "transaction processing". We will see that the communication needs for these applications fall into the gap "between" TCP and UDP -- neither protocol is very appropriate. This RFC is concerned with the possible design of one or more new protocols for the ARPA-Internet, to support kinds of applications which are not well supported at present. The RFC is intended to spur discussion in the Internet research community towards the development of new protocols and/or concepts, in order to meet these unmet application requirements. It does not represent a standard, nor even a concrete protocol proposal.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0955
RFC0956 Algorithms for synchronizing network clocks D.L. Mills September 1985 ASCII HTML 26

This RFC discussed clock synchronization algorithms for the ARPA-Internet community, and requests discussion and suggestions for improvements. The recent interest within the Internet community in determining accurate time from a set of mutually suspicious network clocks has been prompted by several occasions in which errors were found in usually reliable, accurate clock servers after thunderstorms which disrupted their power supply. To these sources of error should be added those due to malfunctioning hardware, defective software and operator mistakes, as well as random errors in the mechanism used to set and synchronize clocks. This report suggests a stochastic model and algorithms for computing a good estimator from time-offset samples measured between clocks connected via network links. Included in this report are descriptions of certain experiments which give an indication of the effectiveness of the algorithms.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0956
RFC0957 Experiments in network clock synchronization D.L. Mills September 1985 ASCII HTML 27

This RFC discusses some experiments in clock synchronization in the ARPA-Internet community, and requests discussion and suggestions for improvements. One of the services frequently neglected in computer network design is a high-quality, time-of-day clock capable of generating accurate timestamps with small errors compared to one-way network delays. Such a service would be useful for tracing the progress of complex transactions, synchronizing cached data bases, monitoring network performance and isolating problems. In this memo one such clock service design will be described and its performance assessed. This design has been incorporated as an integral part of the network routing and control protocols of the Distributed Computer Network (DCnet) architecture.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0957
RFC0958 Network Time Protocol (NTP) D.L. Mills September 1985 ASCII HTML 14 NTP time clock synchronization

This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP), which provides a connectionless transport mechanism. It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC1059 RFC1119 RFC1305 UNKNOWN UNKNOWN Legacy 10.17487/RFC0958
RFC0959 File Transfer Protocol J. Postel J. Reynolds October 1985 ASCII HTML 69 FTP

This memo is the official specification of the File Transfer Protocol (FTP) for the DARPA Internet community. The primary intent is to clarify and correct the documentation of the FTP specification, not to change the protocol. The following new optional commands are included in this edition of the specification: Change to Parent Directory (CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove Directory (RMD), Make Directory (MKD), Print Directory (PWD), and System (SYST). Note that this specification is compatible with the previous edition.

RFC0765 RFC2228 RFC2640 RFC2773 RFC3659 RFC5797 RFC7151 STD0009 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=959 10.17487/RFC0959
RFC0960 Assigned numbers J.K. Reynolds J. Postel December 1985 ASCII HTML 60

This memo documents the currently assigned values from several series of numbers used in network protocol implementations. This edition of Assigned Numbers updates and obsoletes RFC-943. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-990 and 997.

RFC0943 RFC0990 HISTORIC UNKNOWN Legacy 10.17487/RFC0960
RFC0961 Official ARPA-Internet protocols J.K. Reynolds J. Postel December 1985 ASCII HTML 38

This memo identifies the documents specifying the official protocols used in the Internet, and comments on any revisions or changes planned. This edition of the Official Protocols updates and obsoletes RFC-944. This memo is an official status report on the protocols used in the ARPA-Internet community. See RFC-991.

RFC0944 RFC0991 UNKNOWN UNKNOWN Legacy 10.17487/RFC0961
RFC0962 TCP-4 prime M.A. Padlipsky November 1985 ASCII HTML 2

This memo is in response to Bob Braden's call for a transaction oriented protocol (RFC-955), and continues the discussion of a possible transaction oriented transport protocol. This memo does not propose a standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0962
RFC0963 Some problems with the specification of the Military Standard Internet Protocol D.P. Sidhu November 1985 ASCII HTML 19

The purpose of this RFC is to provide helpful information on the Military Standard Internet Protocol (MIL-STD-1777) so that one can obtain a reliable implementation of this protocol. This paper points out several problems in this specification. This note also proposes solutions to these problems.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0963
RFC0964 Some problems with the specification of the Military Standard Transmission Control Protocol D.P. Sidhu T. Blumer November 1985 ASCII HTML 10

The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems.

INFORMATIONAL UNKNOWN Legacy 10.17487/RFC0964
RFC0965 Format for a graphical communication protocol L. Aguilar December 1985 ASCII HTML 51

This RFC describes the requirements for a graphical format on which to base a graphical on-line communication protocol, and proposes an Interactive Graphical Communication Format using the GKSM session metafile. We hope this contribution will encourage the discussion of multimedia data exchange and the proposal of solutions.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0965
RFC0966 Host groups: A multicast extension to the Internet Protocol S.E. Deering D.R. Cheriton December 1985 ASCII HTML 27

This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. See RFC-988.

RFC0988 UNKNOWN UNKNOWN Legacy 10.17487/RFC0966
RFC0967 All victims together M.A. Padlipsky December 1985 ASCII HTML 2

This RFC proposes a new set of RFCs on how the networking code is integrated with various operating systems. It appears that this topic has not received enough exposure in the literature. Comments and suggestions are encouraged.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0967
RFC0968 Twas the night before start-up V.G. Cerf December 1985 ASCII HTML 2

This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0968
RFC0969 NETBLT: A bulk data transfer protocol D.D. Clark M.L. Lambert L. Zhang December 1985 ASCII HTML 15

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. This is a preliminary discussion of the Network Block Transfer (NETBLT) protocol. NETBLT is intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is structured to provide maximum throughput over a wide variety of networks. This description is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-998.

RFC0998 UNKNOWN UNKNOWN Legacy 10.17487/RFC0969
RFC0970 On Packet Switches With Infinite Storage J. Nagle December 1985 ASCII HTML 9

The purpose of this RFC is to focus discussion on a particular problem in the ARPA-Internet and possible methods of solution. Most prior work on congestion in datagram systems focuses on buffer management. In this memo the case of a packet switch with infinite storage is considered. Such a packet switch can never run out of buffers. It can, however, still become congested. The meaning of congestion in an infinite-storage system is explored. An unexpected result is found that shows a datagram network with infinite storage, first-in-first-out queuing, at least two packet switches, and a finite packet lifetime will, under overload, drop all packets. By attacking the problem of congestion for the infinite-storage case, new solutions applicable to switches with finite storage may be found. No proposed solutions this document are intended as standards for the ARPA-Internet at this time.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0970
RFC0971 Survey of data representation standards A.L. DeSchon January 1986 ASCII HTML 9

This RFC is a comparison of several data representation standards that are currently in use. The standards discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to a data representation standard, leading eventually to the adoption of an ARPA-Internet standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0971
RFC0972 Password Generator Protocol F.J. Wancho January 1986 ASCII HTML 2

This RFC specifies a standard for the ARPA Internet community. The Password Generator Service (PWDGEN) provides a set of six randomly generated eight-character "words" with a reasonable level of pronounceability, using a multi-level algorithm. Hosts on the ARPA Internet that choose to implement a password generator service are expected to adopt and implement this standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0972
RFC0973 Domain system changes and observations P.V. Mockapetris January 1986 ASCII HTML 10

This RFC documents updates to Domain Name System specifications RFC-882 and RFC-883, suggests some operational guidelines, and discusses some experiences and problem areas in the present system.

RFC1034 RFC1035 RFC0882 RFC0883 UNKNOWN UNKNOWN Legacy 10.17487/RFC0973
RFC0974 Mail routing and the domain system C. Partridge January 1986 ASCII HTML 7 DNS-MX

This RFC presents a description of how mail systems on the Internet are expected to route messages based on information from the domain system. This involves a discussion of how mailers interpret MX RRs, which are used for message routing.

RFC2821 STD0010 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC0974
RFC0975 Autonomous confederations D.L. Mills February 1986 ASCII HTML 10

This RFC proposes enhancements to the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. The enhancements generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Discussion and suggestions for improvement are requested.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0975
RFC0976 UUCP mail interchange format standard M.R. Horton February 1986 ASCII HTML 12

This document defines the standard format for the transmission of mail messages between computers in the UUCP Project. It does not however, address the format for storage of messages on one machine, nor the lower level transport mechanisms used to get the date from one machine to the next. It represents a standard for conformance by hosts in the UUCP zone.

RFC1137 UNKNOWN UNKNOWN Legacy 10.17487/RFC0976
RFC0977 Network News Transfer Protocol B. Kantor P. Lapsley February 1986 ASCII HTML 27 NNTP]

NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC3977 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC0977
RFC0978 Voice File Interchange Protocol (VFIP) J.K. Reynolds R. Gillman W.A. Brackenridge A. Witkowski J. Postel February 1986 ASCII HTML 5

The purpose of the Voice File Interchange Protocol (VFIP) is to permit the interchange of various types of speech files between different systems in the ARPA-Internet community. Suggestions for improvement are encouraged.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0978
RFC0979 PSN End-to-End functional specification A.G. Malis March 1986 ASCII HTML 15

This memo is an updated version of BBN Report 5775, "End-to-End Functional Specification and describes important changes to the functionality of the interface between a Host and the PSN, and should be carefully reviewed by anyone involved in supporting a host on either the ARPANET or MILNET". The new End-to-End protocol (EE) is being developed in order to correct a number of deficiencies in the old EE, to improve its performance and overall throughput, and to better equip the Packet Switch Node (PSN, also known as the IMP) to support its current and anticipated host population.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0979
RFC0980 Protocol document order information O.J. Jacobsen J. Postel March 1986 ASCII HTML 12

This RFC indicates how to obtain various protocol documents used in the DARPA research community. Included is an overview of the new 1985 DDN Protocol Handbook and available sources for obtaining related documents (such as DOD, ISO, and CCITT).

UNKNOWN UNKNOWN Legacy 10.17487/RFC0980
RFC0981 Experimental multiple-path routing algorithm D.L. Mills March 1986 ASCII HTML 22

This document introduces wiretap algorithms, a class of experimental, multiple routing algorithms that compute quasi-optimum routes for stations sharing a packet-radio broadcast channel. The primary route (a minimum-distance path), and additional paths ordered by distance, which serve as alternate routes should the primary route fail, are computed. This prototype is presented as an example of a class of routing algorithms and data-base management techniques that may find wider application in the Internet community. Discussions and suggestions for improvements are welcomed.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0981
RFC0982 Guidelines for the specification of the structure of the Domain Specific Part (DSP) of the ISO standard NSAP address H.W. Braun April 1986 ASCII HTML 11

This RFC is a draft working document of the ANSI "Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address". It provides guidance to private address administration authorities on preferred formats and semantics for the Domain Specific Part (DSP) of an NSAP address. This RFC specifies the way in which the DSP may be constructed so as to facilitate efficient address assignment. This RFC is for informational purposes only and its distribution is unlimited and does not specify a standard of the ARPA-Internet.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0982
RFC0983 ISO transport arrives on top of the TCP D.E. Cass M.T. Rose April 1986 ASCII HTML 27

This memo describes a proposed protocol standard for the ARPA Internet community. The CCITT and the ISO have defined various session, presentation, and application recommendations which have been adopted by the international community and numerous vendors. To the largest extent possible, it is desirable to offer these higher level services directly in the ARPA Internet, without disrupting existing facilities. This permits users to develop expertise with ISO and CCITT applications which previously were not available in the ARPA Internet. The intention is that hosts in the ARPA-Internet that choose to implement ISO TSAP services on top of the TCP be expected to adopt and implement this standard. Suggestions for improvement are encouraged.

RFC1006 UNKNOWN UNKNOWN Legacy 10.17487/RFC0983
RFC0984 PCMAIL: A distributed mail system for personal computers D.D. Clark M.L. Lambert May 1986 ASCII HTML 31

This document is a preliminary discussion of the design of a personal-computer-based distributed mail system. Pcmail is a distributed mail system that provides mail service to an arbitrary number of users, each of which owns one or more personal computers (PCs). The system is divided into two halves. The first consists of a single entity called the "repository". The repository is a storage center for incoming mail. Mail for a Pcmail user can arrive externally from the Internet or internally from other repository users. The repository also maintains a stable copy of each user's mail state. The repository is therefore typically a computer with a large amount of disk storage. It is published for discussion and comment, and does not constitute a standard. As the proposal may change, implementation of this document is not advised. See RFC-993.

RFC0993 UNKNOWN UNKNOWN Legacy 10.17487/RFC0984
RFC0985 Requirements for Internet gateways - draft National Science Foundation Network Technical Advisory Group May 1986 ASCII HTML 23 Requirements Internet gateways

This RFC summarizes the requirements for gateways to be used on networks supporting the DARPA Internet protocols. While it applies specifically to National Science Foundation research programs, the requirements are stated in a general context and are believed applicable throughout the Internet community. The purpose of this document is to present guidance for vendors offering products that might be used or adapted for use in an Internet application. It enumerates the protocols required and gives references to RFCs and other documents describing the current specification.

RFC1009 UNKNOWN UNKNOWN Legacy 10.17487/RFC0985
RFC0986 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol R.W. Callon H.W. Braun June 1986 ASCII HTML 7

This RFC suggests a method to allow the existing IP addressing, including the IP protocol field, to be used for the ISO Connectionless Network Protocol (CLNP). This is a draft solution to one of the problems inherent in the use of "ISO-grams" in the DOD Internet. Related issues will be discussed in subsequent RFCs. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC1069 UNKNOWN UNKNOWN Legacy 10.17487/RFC0986
RFC0987 Mapping between X.400 and RFC 822 S.E. Kille June 1986 ASCII HTML 69

The X.400 series protocols have been defined by CCITT to provide an Interpersonal Messaging Service (IPMS), making use of a store and forward Message Transfer Service. It is expected that this standard will be implemented very widely. This document describes a set of mappings which will enable interworking between systems operating the X.400 protocols and systems using RFC-822 mail protocol or protocols derived from RFC-822. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.

RFC2156 RFC1327 RFC1026 RFC1138 RFC1148 UNKNOWN UNKNOWN Legacy 10.17487/RFC0987
RFC0988 Host extensions for IP multicasting S.E. Deering July 1986 ASCII HTML 20 multicast Internet

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.

RFC0966 RFC1054 RFC1112 UNKNOWN UNKNOWN Legacy 10.17487/RFC0988
RFC0989 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures J. Linn February 1987 ASCII HTML 23

This RFC suggests a proposed protocol for the Internet community and requests discussion and suggestions for improvements. This RFC is the outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This RFC defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. It is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or authentication is anticipated.

RFC1040 RFC1113 UNKNOWN UNKNOWN Legacy 10.17487/RFC0989
RFC0990 Assigned numbers J.K. Reynolds J. Postel November 1986 ASCII HTML 75

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. See RFC-997. Obsoletes RFC-960, 943, 923 and 900.

RFC0960 RFC1010 RFC0997 HISTORIC UNKNOWN Legacy 10.17487/RFC0990
RFC0991 Official ARPA-Internet protocols J.K. Reynolds J. Postel November 1986 ASCII HTML 46

This RFC identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned. This memo is an official status report on the numbers used in protocols in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.

RFC0961 RFC1011 UNKNOWN UNKNOWN Legacy 10.17487/RFC0991
RFC0992 On communication support for fault tolerant process groups K.P. Birman T.A. Joseph November 1986 ASCII HTML 18

This memo describes a collection of multicast communication primitives integrated with a mechanism for handling process failure and recovery. These primitives facilitate the implementation of fault-tolerant process groups, which can be used to provide distributed services in an environment subject to non-malicious crash failures.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0992
RFC0993 PCMAIL: A distributed mail system for personal computers D.D. Clark M.L. Lambert December 1986 ASCII HTML 28

This document is a discussion of the Pcmail workstation-based distributed mail system. It is a revision of the design published in NIC RFC-984. The revision is based on discussion and comment fromm a variety of sources, as well as further research into the design of interactive Pcmail clients and the use of client code on machines other than IBM PCs. As this design may change, implementation of this document is not advised. Obsoletes RFC-984.

RFC0984 RFC1056 UNKNOWN UNKNOWN Legacy 10.17487/RFC0993
RFC0994 Final text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service International Organization for Standardization March 1986 ASCII HTML 52

This Protocol Standard is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol Standard is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498). In particular, it is a protocol of the Network Layer. This Protocol may be used between network-entities in end systems or in Network Layer relay systems (or both). It provides the Connectionless-mode Network Service as defined in Addendum 1 to the Network Service Definition Covering Connectionless-mode Transmission (ISO 8348/AD1).

RFC0926 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=994 10.17487/RFC0994
RFC0995 End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473 International Organization for Standardization April 1986 ASCII HTML 41

This Protocol is one of a set of International Standards produced to facilitate the interconnection of open systems. The set of standards covers the services and protocols required to achieve such interconnection. This Protocol is positioned with respect to other related standards by the layers defined in the Reference Model for Open Systems Interconnection (ISO 7498) and by the structure defined in the Internal Organization of the Network Layer (DIS 8648). In particular, it is a protocol of the Network Layer. This Protocol permits End Systems and Intermediate Systems to exchange configuration and routing information to facilitate the operation of the routing and relaying functions of the Network Layer.

UNKNOWN UNKNOWN Legacy 10.17487/RFC0995
RFC0996 Statistics server D.L. Mills February 1987 ASCII HTML 3 STATSRV

This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host.

HISTORIC HISTORIC Legacy 10.17487/RFC0996
RFC0997 Internet numbers J.K. Reynolds J. Postel March 1987 ASCII HTML 42

This memo is an official status report on the network numbers used in the Internet community. As of 1-Mar-87 the Network Information Center (NIC) at SRI International has assumed responsibility for assignment of Network Numbers and Autonomous System Numbers. This RFC documents the current assignments of these numbers at the time of this transfer of responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.

RFC1020 RFC1117 RFC0990 UNKNOWN UNKNOWN Legacy 10.17487/RFC0997
RFC0998 NETBLT: A bulk data transfer protocol D.D. Clark M.L. Lambert L. Zhang March 1987 ASCII HTML 21 NETBLT

This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.

RFC0969 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC0998
RFC0999 Requests For Comments summary notes: 900-999 A. Westine J. Postel April 1987 ASCII HTML 22 RFC0160 RFC1000 UNKNOWN UNKNOWN Legacy 10.17487/RFC0999 RFC1000 Request For Comments reference guide J.K. Reynolds J. Postel August 1987 ASCII HTML 149

This RFC Reference Guide is intended to provide a historical account by categorizing and summarizing of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. These documents have been crossed referenced to indicate which RFCs are current, obsolete, or revised.

RFC0999 UNKNOWN UNKNOWN Legacy 10.17487/RFC1000
RFC1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods NetBIOS Working Group in the Defense Advanced Research Projects Agency Internet Activities Board End-to-End Services Task Force March 1987 ASCII HTML 68 NETBIOS

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC describes the NetBIOS-over-TCP protocols in a general manner, emphasizing the underlying ideas and techniques. Detailed specifications are found in a companion RFC, "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".

STD0019 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1001 10.17487/RFC1001
RFC1002 Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications NetBIOS Working Group in the Defense Advanced Research Projects Agency Internet Activities Board End-to-End Services Task Force March 1987 ASCII HTML 84 NETBIOS

This RFC defines a proposed standard protocol to support NetBIOS services in a TCP/IP environment. Both local network and internet operation are supported. Various node types are defined to accommodate local and internet topologies and to allow operation with or without the use of IP broadcast. This RFC gives the detailed specifications of the netBIOS-over-TCP packets, protocols, and defined constants and variables. A more general overview is found in a companion RFC, "Protocol Standard For NetBIOS Service on TCP/UDP Transport: Concepts and Methods".

STD0019 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1002 10.17487/RFC1002
RFC1003 Issues in defining an equations representation standard A.R. Katz March 1987 ASCII HTML 7

This memo is intended to identify and explore issues in defining a standard for the exchange of mathematical equations. No attempt is made at a complete definition and more questions are asked than are answered. Questions about the user interface are only addressed to the extent that they affect interchange issues.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1003
RFC1004 Distributed-protocol authentication scheme D.L. Mills April 1987 ASCII HTML 8 COOKIE-JAR

The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1004
RFC1005 ARPANET AHIP-E Host Access Protocol (enhanced AHIP) A. Khanna A.G. Malis May 1987 ASCII HTML 34

This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1005
RFC1006 ISO Transport Service on top of the TCP Version: 3 M.T. Rose D.E. Cass May 1987 ASCII HTML 19 TP-TCP

This memo specifies a standard for the Internet community. Hosts on the Internet that choose to implement ISO transport services on top of the TCP are expected to adopt and implement this standard. TCP port 102 is reserved for hosts which implement this standard. This memo specifies version 3 of the protocol and supersedes RFC-983. Changes between the protocol is described in RFC-983 and this memo are minor, but unfortunately incompatible.

RFC0983 RFC2126 STD0035 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1006
RFC1007 Military supplement to the ISO Transport Protocol W. McCoy June 1987 ASCII HTML 23

This document supplements the Transport Service and Protocol of the International Standards Organization (ISO), IS 8072 and IS 8073, respectively, and their formal descriptions by providing conventions, option selections and parameter values. This RFC is being distributed to members of the Internet community in order to solicit comments on the Draft Military Supplement. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1007
RFC1008 Implementation guide for the ISO Transport Protocol W. McCoy June 1987 ASCII HTML 73

This RFC is being distributed to members of the Internet community in order to solicit comments on the Implementors Guide. While this document may not be directly relevant to the research problems of the Internet, it may be of some interest to a number of researchers and implementors.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1008
RFC1009 Requirements for Internet gateways R.T. Braden J. Postel June 1987 ASCII HTML 54

This RFC summarizes the requirements for gateways to be used between networks supporting the Internet protocols. This document is a formal statement of the requirements to be met by gateways used in the Internet system. As such, it is an official specification for the Internet community.

RFC0985 RFC1812 HISTORIC HISTORIC Legacy 10.17487/RFC1009
RFC1010 Assigned numbers J.K. Reynolds J. Postel May 1987 ASCII HTML 44

This memo is an official status report on the numbers used in protocols in the Internet community. It documents the currently assigned values from several series of numbers including link, socket, port, and protocol, used in network protocol implementations.

RFC0990 RFC1060 HISTORIC UNKNOWN Legacy 10.17487/RFC1010
RFC1011 Official Internet protocols J.K. Reynolds J. Postel May 1987 ASCII HTML 52

This memo is an official status report on the protocols used in the Internet community. It identifies the documents specifying the official protocols used in the Internet. Comments indicate any revisions or changes planned.

RFC0991 RFC6093 UNKNOWN UNKNOWN Legacy 10.17487/RFC1011
RFC1012 Bibliography of Request For Comments 1 through 999 J.K. Reynolds J. Postel June 1987 ASCII HTML 64

This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1012
RFC1013 X Window System Protocol, version 11: Alpha update April 1987 R.W. Scheifler June 1987 ASCII HTML 101

This RFC is distributed to the Internet community for information only. It does not establish an Internet standard. The X window system has been widely reviewed and tested. The Internet community is encouraged to experiment with it.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1013
RFC1014 XDR: External Data Representation standard Sun Microsystems June 1987 ASCII HTML 20

XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures. XDR fits into ISO presentation layer, and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing. This RFC is distributed for information only, it does not establish a Internet standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1014
RFC1015 Implementation plan for interagency research Internet B.M. Leiner July 1987 ASCII HTML 24

This RFC proposes an Interagency Research Internet as the natural outgrowth of the current Internet. This is an "idea paper" and discussion is strongly encouraged.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1015
RFC1016 Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID) W. Prue J. Postel July 1987 ASCII HTML 18

The memo is intended to explore the issue of what a host could do with a source quench. The proposal is for each source host IP module to introduce some delay between datagrams sent to the same destination host. This is a "crazy idea paper" and discussion is essential.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1016
RFC1017 Network requirements for scientific research: Internet task force on scientific computing B.M. Leiner August 1987 ASCII HTML 19

This RFC identifies the requirements on communication networks for supporting scientific research. It proposes some specific areas for near term work, as well as some long term goals. This is an "idea" paper and discussion is strongly encouraged.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1017
RFC1018 Some comments on SQuID A.M. McKenzie August 1987 ASCII HTML 3

This memo is a discussion of some of the ideas expressed in RFC-1016 on Source Quench. This memo introduces the distinction of the cause of congestion in a gateway between the effects of "Funneling" and "Mismatch". It is offered in the same spirit as RFC-1016; to stimulate discussion. The opinions offered are personal, not corporate, opinions. Distribution of this memo is unlimited.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1018
RFC1019 Report of the Workshop on Environments for Computational Mathematics D. Arnon September 1987 ASCII HTML 8

This memo is a report on the discussion of the representation of equations in a workshop at the ACM SIGGRAPH Conference held in Anaheim, California on 30 July 1987.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1019
RFC1020 Internet numbers S. Romano M.K. Stahl November 1987 ASCII HTML 51

This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997.

RFC0997 RFC1062 RFC1117 RFC1166 UNKNOWN UNKNOWN Legacy 10.17487/RFC1020
RFC1021 High-level Entity Management System (HEMS) C. Partridge G. Trewitt October 1987 ASCII HTML 5 HEMS

This memo provides a general overview of the High-level Entity management system (HEMS). This system is experimental, and is currently being tested in portions of the Internet.

HISTORIC HISTORIC Legacy 10.17487/RFC1021
RFC1022 High-level Entity Management Protocol (HEMP) C. Partridge G. Trewitt October 1987 ASCII HTML 12

This memo presents an application protocol for managing network entities such as hosts, gateways, and front end machines. This protocol is a component of the High-level Entity Management System HEMS), described is RFC-1021. This memo also assumes a knowledge of the ISO data encoding standard, ASN.1.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1022
RFC1023 HEMS monitoring and control language G. Trewitt C. Partridge October 1987 ASCII HTML 17

This RFC specifies the High-Level Entity Management System (HEMS) Monitoring and Control Language. This language defines the requests and replies used in HEMS. This memo assumes knowledge of the HEMS system described in RFC-1021, and of the ISO data encoding standard, ASN.1.

RFC1076 UNKNOWN UNKNOWN Legacy 10.17487/RFC1023
RFC1024 HEMS variable definitions C. Partridge G. Trewitt October 1987 ASCII HTML 74

This memo assigns instruction codes, defines object formats and object semantics for use with the High-Level Monitoring and Control Language, defined in RFC-1023. A general system has been described in previous memos (RFC-1021, RFC-1022). This system is called the High-Level Entity Management System (HEMS). This memo is provisional and the definitions are subject to change. Readers should confirm with the authors that they have the most recent version. This RFC assumes a working knowledge of the ISO data encoding standard, ASN.1, and a general understanding of the IP protocol suite.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1024
RFC1025 TCP and IP bake off J. Postel September 1987 ASCII HTML 6

This memo describes some of the procedures, scoring and tests used in the TCP and IP bake offs held in the early development of these protocols. These procedures and tests may still be of use in testing newly implemented TCP and IP modules.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1025
RFC1026 Addendum to RFC 987: (Mapping between X.400 and RFC-822) S.E. Kille September 1987 ASCII HTML 4

This memo suggest a proposed protocol for the Internet community, and request discussion and suggestions for improvements.

RFC2156 RFC1327 RFC0987 RFC1138 RFC1148 UNKNOWN UNKNOWN Legacy 10.17487/RFC1026
RFC1027 Using ARP to implement transparent subnet gateways S. Carl-Mitchell J.S. Quarterman October 1987 ASCII HTML 8

This RFC describes the use of the Address Resolution Protocol (ARP) by subnet gateways to permit hosts on the connected subnets to communicate without being aware of the existence of subnets, using the technique of "Proxy ARP".

UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1027 10.17487/RFC1027
RFC1028 Simple Gateway Monitoring Protocol J. Davin J.D. Case M. Fedor M.L. Schoffstall November 1987 ASCII HTML 35 SGMP

This memo defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by remote users. This proposal is intended only as an interim response to immediate gateway monitoring needs.

HISTORIC HISTORIC Legacy 10.17487/RFC1028
RFC1029 More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets G. Parr May 1988 ASCII HTML 17 arp

This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring host address parameters in a Multi-Lan system of Ethernets. The problem is one which is appearing more and more regularly as the interconnected systems grow larger on Campuses and in Commercial Institutions. This RFC suggests a protocol enhancement for the Internet community, and requests discussion and suggestions for improvements.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1029
RFC1030 On testing the NETBLT Protocol over divers networks M.L. Lambert November 1987 ASCII HTML 16

This memo describes the results gathered from testing NETBLT over three networks of different bandwidths and round-trip delays. The results are not complete, but the information gathered so far has not been promising. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1030
RFC1031 MILNET name domain transition W.D. Lazear November 1987 ASCII HTML 10

This RFC consolidates information necessary for the implementation of domain style names throughout the DDN/MILNET Internet community. The introduction of domain style names will impact all hosts in the DDN/MILNET Internet. This RFC is designed as an aid to implementors and administrators by providing: 1) an overview of the transition process from host tables to domains, 2) a timetable for the transition, and 3) references to documentation and software relating to the domain system.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1031
RFC1032 Domain administrators guide M.K. Stahl November 1987 ASCII HTML 14

Domains are administrative entities that provide decentralized management of host naming and addressing. The domain-naming system is distributed and hierarchical. This memo describes procedures for registering a domain with the Network Information Center (NIC) of Defense Data Network (DDN), and offers guidelines on the establishment and administration of a domain in accordance with the requirements specified in RFC-920. It is recommended that the guidelines described in this document be used by domain administrators in the establishment and control of second-level domains. The role of the domain administrator (DA) is that of coordinator, manager, and technician. If his domain is established at the second level or lower in the tree, the domain administrator must register by interacting with the management of the domain directly above this.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1032
RFC1033 Domain Administrators Operations Guide M. Lottor November 1987 ASCII HTML 22

This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed (see RFCs 1031, 1032, 1034, and 1035).

UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1033 10.17487/RFC1033
RFC1034 Domain names - concepts and facilities P.V. Mockapetris November 1987 ASCII HTML 55 DOMAIN

This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.

RFC0973 RFC0882 RFC0883 RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC2065 RFC2181 RFC2308 RFC2535 RFC4033 RFC4034 RFC4035 RFC4343 RFC4035 RFC4592 RFC5936 RFC8020 RFC8482 RFC8767 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1034 10.17487/RFC1034
RFC1035 Domain names - implementation and specification P.V. Mockapetris November 1987 ASCII HTML 55 DOMAIN DNS

This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.

RFC0973 RFC0882 RFC0883 RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC1995 RFC1996 RFC2065 RFC2136 RFC2181 RFC2137 RFC2308 RFC2535 RFC2673 RFC2845 RFC3425 RFC3658 RFC4033 RFC4034 RFC4035 RFC4343 RFC5936 RFC5966 RFC6604 RFC7766 RFC8482 RFC8490 RFC8767 STD0013 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1035 10.17487/RFC1035
RFC1036 Standard for interchange of USENET messages M.R. Horton R. Adams December 1987 ASCII HTML 19

This RFC defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is distributed as an RFC to make this information easily accessible to the Internet community. It does not specify an Internet standard.

RFC0850 RFC5536 RFC5537 UNKNOWN UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1036 10.17487/RFC1036
RFC1037 NFILE - a file access protocol B. Greenberg S. Keene December 1987 ASCII HTML 86 NFILE

This document includes a specification of the NFILE file access protocol and its underlying levels of protocol, the Token List Transport Layer and Byte Stream with Mark. The goal of this specification is to promote discussion of the ideas described here, and to encourage designers of future file protocols to take advantage of these ideas. A secondary goal is to make the specification available to sites that might benefit from implementing NFILE.

HISTORIC HISTORIC Legacy 10.17487/RFC1037
RFC1038 Draft revised IP security option M. St. Johns January 1988 ASCII HTML 7

This memo is a pre-publication draft of the revised Internet Protocol Security Option. This RFC reflects the version as approved by the Protocol Standards Steering group, and is provided for informational purposes only. The final version of this document will be available from Navy publications and should not differ from this document in any major fashion. This document will be published as a change to the MIL- STD 1777, "Internet Protocol".

RFC1108 UNKNOWN UNKNOWN Legacy 10.17487/RFC1038
RFC1039 DoD statement on Open Systems Interconnection protocols D. Latham January 1988 ASCII HTML 3

This RFC reproduces a memorandum issued on 2-JUL-87 from the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (ASDC31) to the Director of the Defense Communications Agency (DCA). This memo is distributed for information only.

RFC0945 UNKNOWN UNKNOWN Legacy 10.17487/RFC1039
RFC1040 Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures J. Linn January 1988 ASCII HTML 29

This RFC is the Outgrowth of a series of IAB Privacy Task Force meetings and of internal working papers distributed for those meetings. This memo defines message encipherment and authentication procedures, as the initial phase of an effort to provide privacy enhancement services for electronic mail transfer in the Internet. Detailed key management mechanisms to support these procedures will be defined in a subsequent RFC. As a goal of this initial phase, it is intended that the procedures defined here be compatible with a wide range of key management approaches, including both conventional (symmetric) and public-key (asymmetric) approaches for encryption of data encrypting keys. Use of conventional cryptography for message text encryption and/or integrity check computation is anticipated.

RFC0989 RFC1113 UNKNOWN UNKNOWN Legacy 10.17487/RFC1040
RFC1041 Telnet 3270 regime option Y. Rekhter January 1988 ASCII HTML 6 TOPT-3270

This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.

RFC6270 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1041
RFC1042 Standard for the transmission of IP datagrams over IEEE 802 networks J. Postel J.K. Reynolds February 1988 ASCII HTML 15 IP-IEEE

This RFC specifies a standard method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on IEEE 802 Networks to allow compatible and interoperable implementations. This RFC specifies a protocol standard for the Internet community.

RFC0948 STD0043 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1042 10.17487/RFC1042
RFC1043 Telnet Data Entry Terminal option: DODIIS implementation A. Yasuda T. Thompson February 1988 ASCII HTML 26 TOPT-DATA

This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.

RFC0732 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1043
RFC1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification K. Hardwick J. Lekashman February 1988 ASCII HTML 43 IP-HC

This memo intends to provide a complete discussion of the protocols and techniques used to embed DoD standard Internet Protocol datagrams (and its associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is directed toward network planners and implementors who are already familiar with the TCP/IP protocol suite and the techniques used to carry TCP/IP traffic on common networks such as the DDN or the Ethernet. No great familiarity with NSC products is assumed; an appendix is devoted to a review of NSC technologies and protocols.

RFC5494 STD0045 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1044
RFC1045 VMTP: Versatile Message Transaction Protocol: Protocol specification D.R. Cheriton February 1988 ASCII HTML 128 VMTP

This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1045
RFC1046 Queuing algorithm to provide type-of-service for IP links W. Prue J. Postel February 1988 ASCII HTML 11

This memo is intended to explore how Type-of-Service might be implemented in the Internet. The proposal describes a method of queuing which can provide the different classes of service. The technique also prohibits one class of service from consuming excessive resources or excluding other classes of service. This is an "idea paper" and discussion is strongly encouraged.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1046
RFC1047 Duplicate messages and SMTP C. Partridge February 1988 ASCII HTML 3

An examination of a synchronization problem in the Simple Mail Transfer Protocol (SMTP) is presented. This synchronization problem can cause a message to be delivered multiple times. A method for avoiding this problem is suggested. Nodding familiarity with the SMTP specification, RFC-821, is required.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1047
RFC1048 BOOTP vendor information extensions P.A. Prindeville February 1988 ASCII HTML 7

This memo proposes an addition to the Bootstrap Protocol (BOOTP). Comments and suggestions for improvements are sought.

RFC1084 RFC1395 RFC1497 RFC1533 UNKNOWN UNKNOWN Legacy 10.17487/RFC1048
RFC1049 Content-type header field for Internet messages M.A. Sirbu March 1988 ASCII HTML 8 CONTENT

This memo suggests proposed additions to the Internet Mail Protocol, RFC-822, for the Internet community, and requests discussion and suggestions for improvements.

HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1049
RFC1050 RPC: Remote Procedure Call Protocol specification Sun Microsystems April 1988 ASCII HTML 24 SUN-RPC

This memo specifies a message protocol used in implementing Sun's Remote Procedure Call (RPC) package. This RFC describes a standard that Sun Microsystems and others are using and is one they wish to propose for the Internet's consideration. It is not an Internet standard at this time.

RFC1057 HISTORIC HISTORIC Legacy 10.17487/RFC1050
RFC1051 Standard for the transmission of IP datagrams and ARP packets over ARCNET networks P.A. Prindeville March 1988 ASCII HTML 4

This memo specifies a standard method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams on an ARCNET. This RFC is a standard protocol for the Internet community.

RFC1201 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1051
RFC1052 IAB recommendations for the development of Internet network management standards V.G. Cerf April 1988 ASCII HTML 14

This RFC is intended to convey to the Internet community and other interested parties the recommendations of the Internet Activities Board (IAB) for the development of network management protocols for use in the TCP/IP environment. This memo does NOT, in and of itself, define or propose an Official Internet Protocol. It does reflect, however, the policy of the IAB with respect to further network management development in the short and long term.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1052
RFC1053 Telnet X.3 PAD option S. Levy T. Jacobson April 1988 ASCII HTML 21 TOPT-X.3

This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1053
RFC1054 Host extensions for IP multicasting S.E. Deering May 1988 ASCII HTML 19

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. IP multicasting is the transmission of an IP datagram to a "host group", a set hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988.

RFC0988 RFC1112 UNKNOWN UNKNOWN Legacy 10.17487/RFC1054
RFC1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP J.L. Romkey June 1988 ASCII HTML 6 IP-SLIP

The TCP/IP protocol family runs over a variety of network media: IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines, satellite links, and serial lines. There are standard encapsulations for IP packets defined for many of these networks, but there is no standard for serial lines. SLIP, Serial Line IP, is a currently a de facto standard, commonly used for point-to-point serial connections running TCP/IP. It is not an Internet standard.

STD0047 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1055 10.17487/RFC1055
RFC1056 PCMAIL: A distributed mail system for personal computers M.L. Lambert June 1988 ASCII HTML 38 PCMAIL

This memo is a discussion of the Pcmail workstation based distributed mail system. It is identical to the discussion in RFC-993, save that a new, much simpler mail transport protocol is described. The new transport protocol is the result of continued research into ease of protocol implementation and use issues.

RFC0993 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1056
RFC1057 RPC: Remote Procedure Call Protocol specification: Version 2 Sun Microsystems June 1988 ASCII HTML 25 SUN-RPC

This RFC describes a standard that Sun Microsystems and others are using, and is one we wish to propose for the Internet's consideration. This memo is not an Internet standard at this time.

RFC1050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1057
RFC1058 Routing Information Protocol C.L. Hedrick June 1988 ASCII HTML 33 RIP

This RFC describes an existing protocol for exchanging routing information among gateways and other hosts. It is intended to be used as a basis for developing gateway software for use in the Internet community.

RFC1388 RFC1723 HISTORIC HISTORIC Legacy 10.17487/RFC1058
RFC1059 Network Time Protocol (version 1) specification and implementation D.L. Mills July 1988 ASCII HTML 58 NTP NTPv1 time clock synchronization

This memo describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical master-slave configuration synchronizes logical clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. The NTP architectures, algorithms and protocols which have evolved over several years of implementation and refinement are described in this document. The prototype system, which has been in regular operation in the Internet for the last two years, is described in an Appendix along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even the cases of failure or disruption of clocks, time servers or nets. This is a Draft Standard for an Elective protocol.

RFC0958 RFC1119 RFC1305 UNKNOWN UNKNOWN Legacy 10.17487/RFC1059
RFC1060 Assigned numbers J.K. Reynolds J. Postel March 1990 ASCII HTML 86

This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.

RFC1010 RFC1340 RFC1349 HISTORIC UNKNOWN Legacy 10.17487/RFC1060
RFC1061 RFC1062 Internet numbers S. Romano M.K. Stahl M. Recker August 1988 ASCII HTML 65

This memo is an official status report on the network numbers and gateway autonomous system numbers used in the Internet community.

RFC1020 RFC1117 RFC1166 UNKNOWN UNKNOWN Legacy 10.17487/RFC1062
RFC1063 IP MTU discovery options J.C. Mogul C.A. Kent C. Partridge K. McCloghrie July 1988 ASCII HTML 11

A pair of IP options that can be used to learn the minimum MTU of a path through an internet is described, along with its possible uses. This is a proposal for an Experimental protocol.

RFC1191 UNKNOWN UNKNOWN Legacy 10.17487/RFC1063
RFC1064 Interactive Mail Access Protocol: Version 2 M.R. Crispin July 1988 ASCII HTML 26

This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.

RFC1176 RFC1203 UNKNOWN UNKNOWN Legacy 10.17487/RFC1064
RFC1065 Structure and identification of management information for TCP/IP-based internets K. McCloghrie M.T. Rose August 1988 ASCII HTML 21

This RFC provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos, which describe the initial management information base along with the initial network management protocol, these documents provide a simple, working architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementation in the Internet which are network manageable are expected to adopt and implement this specification.

RFC1155 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1065 10.17487/RFC1065
RFC1066 Management Information Base for network management of TCP/IP-based internets K. McCloghrie M.T. Rose August 1988 ASCII HTML 90

This RFC provides the initial version of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets in the short-term. In particular, together with its companion memos which describe the structure of management information along with the initial network management protocol, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets, and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

RFC1156 UNKNOWN UNKNOWN Legacy 10.17487/RFC1066
RFC1067 Simple Network Management Protocol J.D. Case M. Fedor M.L. Schoffstall J. Davin August 1988 ASCII HTML 33

This RFC defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular, the Internet. This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.

RFC1098 UNKNOWN UNKNOWN Legacy 10.17487/RFC1067
RFC1068 Background File Transfer Program (BFTP) A.L. DeSchon R.T. Braden August 1988 ASCII HTML 27 FTP

This RFC describes an Internet background file transfer service that is built upon the third-party transfer model of FTP. No new protocols are involved. The purpose of this memo is to stimulate discussions on new Internet service modes.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1068
RFC1069 Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol R.W. Callon H.W. Braun February 1989 ASCII HTML 10

This RFC suggests an addressing scheme for use with the ISO Connectionless Network Protocol (CLNP) in the Internet. This is a solution to one of the problems inherent in the use of "ISO-grams" in the Internet. This memo is a revision of RFC 986. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC0986 UNKNOWN UNKNOWN Legacy 10.17487/RFC1069
RFC1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer R.A. Hagens N.E. Hall M.T. Rose February 1989 ASCII HTML 17

This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet and requests discussion and suggestions for improvements to this scenario. This RFC also proposes the creation of an experimental OSI internet. To participate in the experimental OSI internet, a system must abide by the agreements set forth in this RFC.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1070
RFC1071 Computing the Internet checksum R.T. Braden D.A. Borman C. Partridge September 1988 ASCII HTML 24

This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.

RFC1141 INFORMATIONAL UNKNOWN Legacy http://www.rfc-editor.org/errata_search.php?rfc=1071 10.17487/RFC1071
RFC1072 TCP extensions for long-delay paths V. Jacobson R.T. Braden October 1988 ASCII HTML 16

This RFC proposes a set of extensions to the TCP protocol to provide efficient operation over a path with a high bandwidth*delay product. These extensions are not proposed as an Internet standard at this time. Instead, they are intended as a basis for further experimentation and research on transport protocol performance.

RFC1323 RFC2018 RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1072
RFC1073 Telnet window size option D. Waitzman October 1988 ASCII HTML 4 TOPT-NAWS

This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1073
RFC1074 NSFNET backbone SPF based Interior Gateway Protocol J. Rekhter October 1988 ASCII HTML 5

This RFC is an implementation description of the standard ANSI IS-IS and ISO ES-IS routing protocols within the NSFNET backbone network.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1074
RFC1075 Distance Vector Multicast Routing Protocol D. Waitzman C. Partridge S.E. Deering November 1988 ASCII HTML 24 IP-DVMRP

This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1075
RFC1076 HEMS monitoring and control language G. Trewitt C. Partridge November 1988 ASCII HTML 42

This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC 1023, extending the query language and providing more discussion of the underlying issues. This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC 1021 and RFC 1022. Readers may wish to consult these RFCs when reading this memo. RFC 1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC 1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1.

RFC1023 UNKNOWN UNKNOWN Legacy 10.17487/RFC1076
RFC1077 Critical issues in high bandwidth networking B.M. Leiner November 1988 ASCII HTML 46

This memo presents the results of a working group on High Bandwidth Networking. This RFC is for your information and you are encouraged to comment on the issues presented.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1077
RFC1078 TCP port service Multiplexer (TCPMUX) M. Lottor November 1988 ASCII HTML 2

This RFC proposes an Internet standard which can be used by future TCP services instead of using 'well-known ports'.

RFC7805 HISTORIC UNKNOWN Legacy 10.17487/RFC1078
RFC1079 Telnet terminal speed option C.L. Hedrick December 1988 ASCII HTML 3 TOPT-TS

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1079
RFC1080 Telnet remote flow control option C.L. Hedrick November 1988 ASCII HTML 4

This RFC specifies a standard for the Internet community. Hosts on the Internet that do remote flow control within the Telnet protocol are expected to adopt and implement this standard.

RFC1372 UNKNOWN UNKNOWN Legacy 10.17487/RFC1080
RFC1081 Post Office Protocol: Version 3 M.T. Rose November 1988 ASCII HTML 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC1225 UNKNOWN UNKNOWN Legacy 10.17487/RFC1081
RFC1082 Post Office Protocol: Version 3: Extended service offerings M.T. Rose November 1988 ASCII HTML 11

This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1082
RFC1083 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board December 1988 ASCII HTML 12 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months.

RFC1100 HISTORIC UNKNOWN Legacy 10.17487/RFC1083
RFC1084 BOOTP vendor information extensions J.K. Reynolds December 1988 ASCII HTML 8

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville. This memo will be updated as additional tags are are defined. This edition introduces Tag 13 for Boot File Size. Comments and suggestions for improvements are sought.

RFC1048 RFC1395 RFC1497 RFC1533 UNKNOWN UNKNOWN Legacy 10.17487/RFC1084
RFC1085 ISO presentation services on top of TCP/IP based internets M.T. Rose December 1988 ASCII HTML 32

RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP/IP. Once this method is applied, one may implement "real" ISO applications on top of TCP/IP-based internets, by simply implementing OSI session, presentation, and application services on top of the transport service access point which is provided on top of the TCP. Although straight-forward, there are some environments in which the richness provided by the OSI application layer is desired, but it is nonetheless impractical to implement the underlying OSI infrastructure (i.e., the presentation, session, and transport services on top of the TCP). This memo describes an approach for providing "stream-lined" support of OSI application services on top of TCP/IP-based internets for such constrained environments. This memo proposes a standard for the Internet community.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1085
RFC1086 ISO-TP0 bridge between TCP and X.25 J.P. Onions M.T. Rose December 1988 ASCII HTML 9

This memo proposes a standard for the Internet community. Hosts on the Internet that choose to implement ISO TP0 transport connectivity between TCP and X.25 based hosts are expected to experiment with this proposal. TCP port 146 is reserved for this proposal.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1086
RFC1087 Ethics and the Internet Defense Advanced Research Projects Agency Internet Activities Board January 1989 ASCII HTML 2 Ethics Internet

This memo is a statement of policy by the Internet Activities Board (IAB) concerning the proper use of the resources of the Internet.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1087
RFC1088 Standard for the transmission of IP datagrams over NetBIOS networks L.J. McLaughlin February 1989 ASCII HTML 3 IP-NETBIOS

This document specifies a standard method of encapsulating the Internet Protocol (IP) datagrams on NetBIOS networks.

STD0048 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1088
RFC1089 SNMP over Ethernet M. Schoffstall C. Davin M. Fedor J. Case February 1989 ASCII HTML 3

This memo describes an experimental method by which the Simple Network Management Protocol (SNMP) can be used over Ethernet MAC layer framing instead of the Internet UDP/IP protocol stack. This specification is useful for LAN based network elements that support no higher layer protocols beyond the MAC sub-layer.

RFC4789 UNKNOWN UNKNOWN Legacy 10.17487/RFC1089
RFC1090 SMTP on X.25 R. Ullmann February 1989 ASCII HTML 4

This memo proposes a standard for SMTP on the virtual circuit facility provided by the X.25 standard of the CCITT.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1090
RFC1091 Telnet terminal-type option J. VanBokkelen February 1989 ASCII HTML 7 TOPT-TERM

This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate

RFC0930 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1091
RFC1092 EGP and policy based routing in the new NSFNET backbone J. Rekhter February 1989 ASCII HTML 5

This memo discusses implementation decisions for routing issues in the NSFNET, especially in the NSFNET Backbone. Of special concern is the restriction of routing information to advertize the best route as established by a policy decision.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1092
RFC1093 NSFNET routing architecture H.W. Braun February 1989 ASCII HTML 9

This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1093
RFC1094 NFS: Network File System Protocol specification B. Nowicki March 1989 ASCII HTML 27 SUN-NFS

This RFC describes a protocol that Sun Microsystems, Inc., and others are using. A new version of the protocol is under development, but others may benefit from the descriptions of the current protocol, and discussion of some of the design issues.

RFC1813 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1094
RFC1095 Common Management Information Services and Protocol over TCP/IP (CMOT) U.S. Warrier L. Besaw April 1989 ASCII HTML 67

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in a TCP/IP environment. This architecture provides a means by which control and monitoring information can be exchanged between a manager and a remote network element. In particular, this memo defines the means for implementing the Draft International Standard (DIS) version of CMIS/CMIP on top of Internet transport protocols for the purpose of carrying management information defined in the Internet-standard management information base. DIS CMIS/CMIP is suitable for deployment in TCP/IP networks while CMIS/CMIP moves toward becoming an International Standard. Together with the relevant ISO standards and the companion RFCs that describe the initial structure of management information and management information base, these documents provide the basis for a comprehensive architecture and system for managing TCP/IP- based internets, and in particular the Internet.

RFC1189 UNKNOWN UNKNOWN Legacy 10.17487/RFC1095
RFC1096 Telnet X display location option G.A. Marcy March 1989 ASCII HTML 3 TOPT-XDL

This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1096
RFC1097 Telnet subliminal-message option B. Miller April 1 1989 ASCII HTML 3

This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1097
RFC1098 Simple Network Management Protocol (SNMP) J.D. Case M. Fedor M.L. Schoffstall J. Davin April 1989 ASCII HTML 34

This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.

RFC1067 RFC1157 UNKNOWN UNKNOWN Legacy 10.17487/RFC1098
RFC1099 Request for Comments Summary: RFC Numbers 1000-1099 J. Reynolds December 1991 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1099 RFC1100 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1989 ASCII HTML 14 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information. This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority (see the contact information at the end of this memo). Do not use this memo after 31-July-89.

RFC1083 RFC1130 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1100
RFC1101 DNS encoding of network names and other types P.V. Mockapetris April 1989 ASCII HTML 14

This RFC proposes two extensions to the Domain Name System: - A specific method for entering and retrieving RRs which map between network names and numbers. - Ideas for a general method for describing mappings between arbitrary identifiers and numbers. The method for mapping between network names and addresses is a proposed standard, the ideas for a general method are experimental.

RFC1034 RFC1035 UNKNOWN UNKNOWN Legacy 10.17487/RFC1101
RFC1102 Policy routing in Internet protocols D.D. Clark May 1989 ASCII HTML 22

The purpose of this RFC is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1102
RFC1103 Proposed standard for the transmission of IP datagrams over FDDI Networks D. Katz June 1989 ASCII HTML 9

This RFC specifies a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

RFC1188 UNKNOWN UNKNOWN Legacy 10.17487/RFC1103
RFC1104 Models of policy based routing H.W. Braun June 1989 ASCII HTML 10

The purpose of this RFC is to outline a variety of models for policy based routing. The relative benefits of the different approaches are reviewed. Discussions and comments are explicitly encouraged to move toward the best policy based routing model that scales well within a large internetworking environment.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1104
RFC1105 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1989 ASCII HTML 17 BGP

This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]

RFC1163 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1105
RFC1106 TCP big window and NAK options R. Fox June 1989 ASCII HTML 13

This memo discusses two extensions to the TCP protocol to provide a more efficient operation over a network with a high bandwidth*delay product. The extensions described in this document have been implemented and shown to work using resources at NASA. This memo describes an Experimental Protocol, these extensions are not proposed as an Internet standard, but as a starting point for further research.

RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1106
RFC1107 Plan for Internet directory services K.R. Sollins July 1989 ASCII HTML 19

This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1107
RFC1108 U.S. Department of Defense Security Options for the Internet Protocol S. Kent November 1991 ASCII HTML 17 IPSO

This RFC specifies the U.S. Department of Defense Basic Security Option and the top-level description of the Extended Security Option for use with the Internet Protocol. This RFC obsoletes RFC 1038, "Revised IP Security Option", dated January 1988. [STANDARDS-TRACK]

RFC1038 HISTORIC HISTORIC Legacy 10.17487/RFC1108
RFC1109 Report of the second Ad Hoc Network Management Review Group V.G. Cerf August 1989 ASCII HTML 8

This RFC reports an official Internet Activities Board (IAB) policy position on the treatment of Network Management in the Internet. This RFC presents the results and recommendations of the second Ad Hoc Network Management Review on June 12, 1989. The results of the first such meeting were reported in RFC 1052.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1109
RFC1110 Problem with the TCP big window option A.M. McKenzie August 1989 ASCII HTML 3

This memo comments on the TCP Big Window option described in RFC 1106.

RFC6247 HISTORIC UNKNOWN Legacy 10.17487/RFC1110
RFC1111 Request for comments on Request for Comments: Instructions to RFC authors J. Postel August 1989 ASCII HTML 6

This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.

RFC0825 RFC1543 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1111
RFC1112 Host extensions for IP multicasting S.E. Deering August 1989 ASCII HTML 17 IGMP multicast

This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]

RFC0988 RFC1054 RFC2236 STD0005 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1112
RFC1113 Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures J. Linn August 1989 ASCII HTML 34

This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]

RFC0989 RFC1040 RFC1421 HISTORIC HISTORIC Legacy 10.17487/RFC1113
RFC1114 Privacy enhancement for Internet electronic mail: Part II - certificate-based key management S.T. Kent J. Linn August 1989 ASCII HTML 25

This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]

RFC1422 HISTORIC HISTORIC Legacy 10.17487/RFC1114
RFC1115 Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers J. Linn August 1989 ASCII HTML 8

This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]

RFC1423 HISTORIC HISTORIC Legacy 10.17487/RFC1115
RFC1116 Telnet Linemode option D.A. Borman August 1989 ASCII HTML 21

Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]

RFC1184 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1116
RFC1117 Internet numbers S. Romano M.K. Stahl M. Recker August 1989 ASCII HTML 109

This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community.

RFC1062 RFC1020 RFC0997 RFC1166 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1117
RFC1118 Hitchhikers guide to the Internet E. Krol September 1989 ASCII HTML 24

This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1118
RFC1119 Network Time Protocol (version 2) specification and implementation D.L. Mills September 1989 ASCII PS PDF HTML 1 NTP NTPv2 time clock synchronization

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. NTP provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse internet operating at rates from mundane to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating in a self- organizing, hierarchical-master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute reference time via local routing algorithms and time daemons. [STANDARDS-TRACK]

RFC0958 RFC1059 RFC1305 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1119
RFC1120 Internet Activities Board V. Cerf September 1989 ASCII HTML 11

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard.

RFC1160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1120
RFC1121 Act one - the poems J. Postel L. Kleinrock V.G. Cerf B. Boehm September 1989 ASCII HTML 6

This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1121
RFC1122 Requirements for Internet Hosts - Communication Layers R. Braden Editor October 1989 ASCII HTML 116 applicability

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

RFC0793 RFC1349 RFC4379 RFC5884 RFC6093 RFC6298 RFC6633 RFC6864 RFC8029 STD0003 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1122 10.17487/RFC1122
RFC1123 Requirements for Internet Hosts - Application and Support R. Braden Editor October 1989 ASCII HTML 98 applicability

This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]

RFC0822 RFC0952 RFC1349 RFC2181 RFC5321 RFC5966 RFC7766 STD0003 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1123 10.17487/RFC1123
RFC1124 Policy issues in interconnecting networks B.M. Leiner September 1989 ASCII PS PDF HTML 1

To support the activities of the Federal Research Internet Coordinating Committee (FRICC) in creating an interconnected set of networks to serve the research community, two workshops were held to address the technical support of policy issues that arise when interconnecting such networks. Held under the suspices of the Internet Activities Board at the request of the FRICC, and sponsored by NASA through RIACS, the workshops addressed the required and feasible technologies and architectures that could be used to satisfy the desired policies for interconnection. The purpose of this RFC is to report the results of these workshops.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1124
RFC1125 Policy requirements for inter Administrative Domain routing D. Estrin November 1989 ASCII PS PDF HTML 21

The purpose of this memo is to focus discussion on particular problems in the Internet and possible methods of solution. No proposed solutions in this document are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the development and adoption of standards.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1125
RFC1126 Goals and functional requirements for inter-autonomous system routing M. Little October 1989 ASCII HTML 25

This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter-autonomous systems routing architecture and protocol. This memo does not specify a standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1126
RFC1127 Perspective on the Host Requirements RFCs R.T. Braden October 1989 ASCII HTML 20

This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1127
RFC1128 Measured performance of the Network Time Protocol in the Internet system D.L. Mills October 1989 ASCII PS PDF HTML 1

This paper describes a series of experiments involving over 100,000 hosts of the Internet system and located in the U.S., Europe and the Pacific. The experiments are designed to evaluate the availability, accuracy and reliability of international standard time distribution using the DARPA/NSF Internet and the Network Time Protocol (NTP), which is specified in RFC-1119. NTP is designed specifically for use in a large, diverse internet system operating at speeds from mundane to lightwave. In NTP a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration exchange precision timestamps in order to synchronize subnet clocks to each other and national time standards via wire or radio. The experiments are designed to locate Internet hosts and gateways that provide time by one of three time distribution protocols and evaluate the accuracy of their indications. For those hosts that support NTP, the experiments determine the distribution of errors and other statistics over paths spanning major portions of the globe. Finally, the experiments evaluate the accuracy and reliability of precision timekeeping using NTP and typical Internet paths involving DARPA, NSFNET and other agency networks. The experiments demonstrate that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo does not specify a standard.

UNKNOWN UNKNOWN Legacy 10.17487/RFC1128
RFC1129 Internet Time Synchronization: The Network Time Protocol D.L. Mills October 1989 ASCII PS PDF HTML 1 NTP

This memo describes the Network Time Protocol (NTP) designed to distribute time information in a large, diverse internet system operating at speeds from mundane to lightwave. It uses a returnable- time architecture in which a distributed subnet of time servers operating in a self-organizing, hierarchical, master-slave configuration synchronizes local clocks within the subnet and to national time standards via wire or radio. The servers can also redistribute time information within a network via local routing algorithms and time daemons. The architectures, algorithms and protocols which have evolved to NTP over several years of implementation and refinement are described in this paper. The synchronization subnet which has been in regular operation in the Internet for the last several years is described along with performance data which shows that timekeeping accuracy throughout most portions of the Internet can be ordinarily maintained to within a few tens of milliseconds, even in cases of failure or disruption of clocks, time servers or networks. This memo describes the Network Time Protocol in RFC-1119.

RFC1119 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1129
RFC1130 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board October 1989 ASCII HTML 17 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB).

RFC1100 RFC1140 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1130
RFC1131 OSPF specification J. Moy October 1989 ASCII PS PDF HTML 1

This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]

RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1131
RFC1132 Standard for the transmission of 802.2 packets over IPX networks L.J. McLaughlin November 1989 ASCII HTML 4 IP-IPX

This document specifies a standard method of encapsulating 802.2 packets on networks supporting Novell's Internet Packet Exchange Protocol (IPX). It obsoletes earlier documents detailing the transmission of Internet packets over IPX networks. It differs from these earlier documents in that it allows for the transmission of multiple network protocols over IPX and for the transmission of packets through IPX bridges.

STD0049 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1132
RFC1133 Routing between the NSFNET and the DDN J.Y. Yu H.W. Braun November 1989 ASCII HTML 10

This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1133
RFC1134 Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links D. Perkins November 1989 ASCII HTML 38

This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group chair by January 15, 1990. Comments will be reviewed at the February 1990 IETF meeting, with the goal of advancing PPP to draft standard status. [STANDARDS-TRACK]

RFC1171 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1134
RFC1135 Helminthiasis of the Internet J.K. Reynolds December 1989 ASCII HTML 33

This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1135
RFC1136 Administrative Domains and Routing Domains: A model for routing in the Internet S. Hares D. Katz December 1989 ASCII HTML 10

This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1136
RFC1137 Mapping between full RFC 822 and RFC 822 with restricted encoding S. Kille December 1989 ASCII HTML 3

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard.

RFC0976 HISTORIC HISTORIC Legacy 10.17487/RFC1137
RFC1138 Mapping between X.400(1988) / ISO 10021 and RFC 822 S.E. Kille December 1989 ASCII HTML 92

Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.

RFC2156 RFC1327 RFC1026 RFC0987 RFC0822 RFC1148 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1138
RFC1139 Echo function for ISO 8473 R.A. Hagens January 1990 ASCII HTML 6

This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard. This memo is not intended to compete with an ISO standard. [STANDARDS-TRACK]

RFC1574 RFC1575 PROPOSED STANDARD PROPOSED STANDARD IETF osigen 10.17487/RFC1139
RFC1140 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board May 1990 ASCII HTML 27 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo is issued quarterly, please be sure the copy you are reading is dated within the last three months. Current copies may be obtained from the Network Information Center or from the Internet Assigned Numbers Authority. Do not use this edition after 31-Aug-90.

RFC1130 RFC1200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1140
RFC1141 Incremental updating of the Internet checksum T. Mallory A. Kullberg January 1990 ASCII HTML 2

This memo correctly describes the incremental update procedure for use with the standard Internet checksum. It is intended to replace the description of Incremental Update in RFC 1071. This is not a standard but rather, an implementation technique.

RFC1071 RFC1624 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1141 10.17487/RFC1141
RFC1142 OSI IS-IS Intra-domain Routing Protocol D. Oran Editor February 1990 ASCII PS PDF HTML 517 Domain Routing ISO

This RFC is a republication of ISO DP 10589 as a service to the Internet community. This is not an Internet standard.

RFC7142 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1142
RFC1143 The Q Method of Implementing TELNET Option Negotiation D.J. Bernstein February 1990 ASCII HTML 10

This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1143
RFC1144 Compressing TCP/IP Headers for Low-Speed Serial Links V. Jacobson February 1990 ASCII PS PDF HTML 49 IP-CMPRS

This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1144
RFC1145 TCP alternate checksum options J. Zweig C. Partridge February 1990 ASCII HTML 5

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use.

RFC1146 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1145
RFC1146 TCP alternate checksum options J. Zweig C. Partridge March 1990 ASCII HTML 5 TCP-ACO

This memo is suggests a pair of TCP options to allow use of alternate data checksum algorithms in the TCP header. The use of these options is experimental, and not recommended for production use. Note: This RFC corrects errors introduced in the editing process in RFC 1145.

RFC1145 RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1146
RFC1147 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R.H. Stine April 1990 ASCII PS PDF HTML 177

The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained.

RFC1470 INFORMATIONAL INFORMATIONAL IETF noctools 10.17487/RFC1147
RFC1148 Mapping between X.400(1988) / ISO 10021 and RFC 822 S.E. Kille March 1990 ASCII HTML 94

This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.

RFC2156 RFC1327 RFC1026 RFC0987 RFC1138 RFC0822 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1148
RFC1149 Standard for the transmission of IP datagrams on avian carriers D. Waitzman April 1 1990 ASCII HTML 2 avian carrier april fools

This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard.

RFC2549 RFC6214 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1149 10.17487/RFC1149
RFC1150 FYI on FYI: Introduction to the FYI Notes G.S. Malkin J.K. Reynolds March 1990 ASCII HTML 4

This memo is the first in a new sub-series of RFCs called FYIs (For Your Information). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 1.]

RFC6360 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1150 10.17487/RFC1150
RFC1151 Version 2 of the Reliable Data Protocol (RDP) C. Partridge R.M. Hinden April 1990 ASCII HTML 4 RDP

This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental.

RFC0908 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1151
RFC1152 Workshop report: Internet research steering group workshop on very-high-speed networks C. Partridge April 1990 ASCII HTML 23

This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1152
RFC1153 Digest message format F.J. Wancho April 1990 ASCII HTML 4 DMF-MAIL

This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1153
RFC1154 Encoding header field for internet messages D. Robinson R. Ullmann April 1990 ASCII HTML 7

This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).

RFC1505 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1154
RFC1155 Structure and identification of management information for TCP/IP-based internets M.T. Rose K. McCloghrie May 1990 ASCII HTML 22 SMI

This RFC is a re-release of RFC 1065, with a changed "Status of this Memo", plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1065. [STANDARDS-TRACK]

RFC1065 STD0016 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1155 10.17487/RFC1155
RFC1156 Management Information Base for network management of TCP/IP-based internets K. McCloghrie M.T. Rose May 1990 ASCII HTML 91 MIB-I

This RFC is a re-release of RFC 1066, with a changed "Status of this Memo", "IAB Policy Statement", and "Introduction" sections plus a few minor typographical corrections. The technical content of the document is unchanged from RFC 1066. [STANDARDS-TRACK]

RFC1066 HISTORIC HISTORIC Legacy 10.17487/RFC1156
RFC1157 Simple Network Management Protocol (SNMP) J.D. Case M. Fedor M.L. Schoffstall J. Davin May 1990 ASCII HTML 36 SNMP

This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]

RFC1098 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1157
RFC1158 Management Information Base for network management of TCP/IP-based internets: MIB-II M.T. Rose May 1990 ASCII HTML 133

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]

RFC1213 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1158 10.17487/RFC1158
RFC1159 Message Send Protocol R. Nelson June 1990 ASCII HTML 2

This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.

RFC1312 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1159
RFC1160 Internet Activities Board V. Cerf May 1990 ASCII HTML 11

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.

RFC1120 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1160
RFC1161 SNMP over OSI M.T. Rose June 1990 ASCII HTML 8

This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,

RFC1418 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1161
RFC1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base G. Satz June 1990 ASCII HTML 70

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.

RFC1238 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1162
RFC1163 Border Gateway Protocol (BGP) K. Lougheed Y. Rekhter June 1990 ASCII HTML 29 BGP

This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1105 RFC1267 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1163
RFC1164 Application of the Border Gateway Protocol in the Internet J.C. Honig D. Katz M. Mathis Y. Rekhter J.Y. Yu June 1990 ASCII HTML 23 BGP

This RFC, together with its companion RFC-1163, "A Border Gateway Protocol (BGP)", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1268 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1164
RFC1165 Network Time Protocol (NTP) over the OSI Remote Operations Service J. Crowcroft J.P. Onions June 1990 ASCII HTML 10 NTP-OSI

This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1165
RFC1166 Internet numbers S. Kirkpatrick M.K. Stahl M. Recker July 1990 ASCII HTML 182

This memo is a status report on the network numbers and autonomous system numbers used in the Internet community.

RFC1117 RFC1062 RFC1020 RFC5737 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1166
RFC1167 Thoughts on the National Research and Education Network V.G. Cerf July 1990 ASCII HTML 8

The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1167
RFC1168 Intermail and Commercial Mail Relay services A. Westine A.L. DeSchon J. Postel C.E. Ward July 1990 ASCII PS PDF HTML 18

This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1168
RFC1169 Explaining the role of GOSIP V.G. Cerf K.L. Mills August 1990 ASCII HTML 15

This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1169
RFC1170 Public key standards and licenses R.B. Fougner January 1991 ASCII HTML 2

This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1170
RFC1171 Point-to-Point Protocol for the transmission of multi-protocol datagrams over Point-to-Point links D. Perkins July 1990 ASCII HTML 51

This memo specifies the Point-to-Point Protocol (PPP) as a Draft Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

RFC1134 RFC1331 DRAFT STANDARD DRAFT STANDARD IETF int ppp 10.17487/RFC1171
RFC1172 Point-to-Point Protocol (PPP) initial configuration options D. Perkins R. Hobby July 1990 ASCII HTML 40

This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.

RFC1331 RFC1332 PROPOSED STANDARD PROPOSED STANDARD IETF int ppp 10.17487/RFC1172
RFC1173 Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet J. VanBokkelen August 1990 ASCII HTML 5

This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1173
RFC1174 IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status V.G. Cerf August 1990 ASCII HTML 9

This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1174
RFC1175 FYI on where to start: A bibliography of internetworking information K.L. Bowers T.L. LaQuey J.K. Reynolds K. Roubicek M.K. Stahl A. Yuan August 1990 ASCII HTML 43

This FYI RFC is a bibliography of information about TCP/IP internetworking, prepared by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify any standard. [Also FYI 3.]

FYI0003 INFORMATIONAL INFORMATIONAL IETF userdoc 10.17487/RFC1175
RFC1176 Interactive Mail Access Protocol: Version 2 M.R. Crispin August 1990 ASCII HTML 30 IMAP2

This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC1064 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1176
RFC1177 FYI on Questions and Answers: Answers to commonly asked "new internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds August 1990 ASCII HTML 24

This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.]

RFC1206 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1177
RFC1178 Choosing a name for your computer D. Libes August 1990 ASCII HTML 8

This FYI RFC is a republication of a Communications of the ACM article on guidelines on what to do and what not to do when naming your computer. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 5.]

FYI0005 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1178
RFC1179 Line printer daemon protocol L. McLaughlin August 1990 ASCII HTML 14 LPDP

This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1179
RFC1180 TCP/IP tutorial T.J. Socolofsky C.J. Kale January 1991 ASCII HTML 28

This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1180 10.17487/RFC1180
RFC1181 RIPE Terms of Reference R. Blokzijl September 1990 ASCII HTML 2

This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1181
RFC1182 RFC1183 New DNS RR Definitions C.F. Everhart L.A. Mamakos R. Ullmann P.V. Mockapetris October 1990 ASCII HTML 11 DNS-RR

This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.

RFC1034 RFC1035 RFC5395 RFC5864 RFC6195 RFC6895 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1183 10.17487/RFC1183
RFC1184 Telnet Linemode Option D.A. Borman October 1990 ASCII HTML 23 TOPT-LINE

This RFC specifies a procedure for line at a time terminal interaction based on the Telnet Protocol. It obsoletes RFC 1116. [STANDARDS-TRACK]

RFC1116 DRAFT STANDARD DRAFT STANDARD IETF app telnet 10.17487/RFC1184
RFC1185 TCP Extension for High-Speed Paths V. Jacobson R.T. Braden L. Zhang October 1990 ASCII HTML 21

This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

RFC1323 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1185
RFC1186 MD4 Message Digest Algorithm R.L. Rivest October 1990 ASCII HTML 18

This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard.

RFC1320 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1186
RFC1187 Bulk Table Retrieval with the SNMP M.T. Rose K. McCloghrie J.R. Davin October 1990 ASCII HTML 12 SNMP-BULK

This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1187
RFC1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks D. Katz October 1990 ASCII HTML 11

This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

RFC1103 DRAFT STANDARD DRAFT STANDARD IETF int fddi 10.17487/RFC1188
RFC1189 Common Management Information Services and Protocols for the Internet (CMOT and CMIP) U.S. Warrier L. Besaw L. LaBarre B.D. Handspicker October 1990 ASCII HTML 15 CMOT

This memo defines a network management architecture that uses the International Organization for Standardization's (ISO) Common Management Information Services/Common Management Information Protocol (CMIS/CMIP) in the Internet. [STANDARDS-TRACK]

RFC1095 HISTORIC HISTORIC IETF oim 10.17487/RFC1189
RFC1190 Experimental Internet Stream Protocol: Version 2 (ST-II) C. Topolcic October 1990 ASCII HTML 148

This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.

IEN119 RFC1819 EXPERIMENTAL EXPERIMENTAL IETF int cip 10.17487/RFC1190
RFC1191 Path MTU discovery J.C. Mogul S.E. Deering November 1990 ASCII HTML 19 IP-MTU

This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]

RFC1063 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1191
RFC1192 Commercialization of the Internet summary report B. Kahin November 1990 ASCII HTML 13

This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1192
RFC1193 Client requirements for real-time communication services D. Ferrari November 1990 ASCII HTML 24

This memo describes client requirements for real-time communication services. This memo provides information for the Internet community, and requests discussion and suggestions for improvements. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1193
RFC1194 Finger User Information Protocol D.P. Zimmerman November 1990 ASCII HTML 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. [STANDARDS-TRACK]

RFC0742 RFC1196 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1194
RFC1195 Use of OSI IS-IS for routing in TCP/IP and dual environments R.W. Callon December 1990 ASCII PS HTML 85 IS-IS

This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]

RFC1349 RFC5302 RFC5304 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1195 10.17487/RFC1195
RFC1196 Finger User Information Protocol D.P. Zimmerman December 1990 ASCII HTML 12

This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program. Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition. This edition corrects and clarifies in a minor way, RFC 1194. [STANDARDS-TRACK]

RFC1194 RFC0742 RFC1288 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1196
RFC1197 Using ODA for translating multimedia information M. Sherman December 1990 ASCII HTML 2

The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1197
RFC1198 FYI on the X window system R.W. Scheifler January 1991 ASCII HTML 3

This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard.

FYI0006 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1198
RFC1199 Request for Comments Summary Notes: 1100-1199 J. Reynolds December 1991 ASCII HTML 22 Summary RFC INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1199 RFC1200 IAB official protocol standards Defense Advanced Research Projects Agency Internet Activities Board April 1991 ASCII HTML 31 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). An overview of the standards procedures is presented first, followed by discussions of the standardization process and the RFC document series, then the explanation of the terms is presented, the lists of protocols in each stage of standardization follows, and finally pointers to references and contacts for further information.

RFC1140 RFC1250 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1200
RFC1201 Transmitting IP traffic over ARCNET networks D. Provan February 1991 ASCII HTML 7 IP-ARC

This memo defines a protocol for the transmission of IP and ARP packets over the ARCnet Local Area Network.This memo specifies a method of encapsulating Internet Protocol (IP) and Address Resolution Protocol (ARP) datagrams for transmission across ARCNET using the "ARCNET Packet Header Definition Standard". [STANDARDS-TRACK]

RFC1051 STD0046 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC1201
RFC1202 Directory Assistance service M.T. Rose February 1991 ASCII HTML 11 DAS

This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1202
RFC1203 Interactive Mail Access Protocol: Version 3 J. Rice February 1991 ASCII HTML 49 IMAP3

This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

RFC1064 HISTORIC HISTORIC Legacy 10.17487/RFC1203
RFC1204 Message Posting Protocol (MPP) S. Yeh D. Lee February 1991 ASCII HTML 6 MPP

This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1204
RFC1205 5250 Telnet interface P. Chmielewski February 1991 ASCII HTML 12

This RFC is being distributed in order to document the interface to the IBM 5250 Telnet implementation. This memo provides information for the Internet community. It does not specify any standard.

RFC2877 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1205
RFC1206 FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions G.S. Malkin A.N. Marine February 1991 ASCII HTML 32

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4]

RFC1177 RFC1325 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1206
RFC1207 FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions G.S. Malkin A.N. Marine J.K. Reynolds February 1991 ASCII HTML 15

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard.

FYI0007 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1207
RFC1208 A Glossary of Networking Terms O.J. Jacobsen D.C. Lynch March 1991 ASCII HTML 18

This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1208
RFC1209 The Transmission of IP Datagrams over the SMDS Service D. Piscitello J. Lawrence March 1991 ASCII HTML 11 IP-SMDS Switched Multi-megabit Data Service

This memo defines a protocol for the transmission of IP and ARP packets over a Switched Multi-megabit Data Service Network configured as a logical IP subnetwork. [STANDARDS-TRACK]

STD0052 INTERNET STANDARD INTERNET STANDARD IETF int smds 10.17487/RFC1209
RFC1210 Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990 V.G. Cerf P.T. Kirstein B. Randell March 1991 ASCII HTML 36

This report complements a shorter printed version which appeared in a summary report of all the committees which met in Brussels and Washington last July, 1990. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1210
RFC1211 Problems with the maintenance of large mailing lists A. Westine J. Postel March 1991 ASCII HTML 54

This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1211
RFC1212 Concise MIB definitions M.T. Rose K. McCloghrie March 1991 ASCII HTML 19 Concise-MIB

This memo describes a straight-forward approach toward producing concise, yet descriptive, MIB modules. This memo defines a format for producing MIB modules. [STANDARDS-TRACK]

STD0016 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1212
RFC1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II K. McCloghrie M. Rose March 1991 ASCII HTML 70 MIB-II

This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

RFC1158 RFC2011 RFC2012 RFC2013 STD0017 INTERNET STANDARD INTERNET STANDARD IETF snmp 10.17487/RFC1213
RFC1214 OSI internet management: Management Information Base L. LaBarre April 1991 ASCII HTML 83 OIM-MIB-II

This RFC documents a MIB for use with CMIP, either over pure OSI stacks or with the CMIP over TCP specification. It redefines objects comprised by the second revision of the Management Information Base for Network Management of TCP/IP-based internets: MIB-II so as to conform to the OSI structure of management information. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF oim 10.17487/RFC1214
RFC1215 Convention for defining traps for use with the SNMP M.T. Rose March 1991 ASCII HTML 9 SNMP-TRAPS

This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard.

INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1215
RFC1216 Gigabit network economics and paradigm shifts P. Richard P. Kynikos April 1 1991 ASCII HTML 4

This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1216
RFC1217 Memo from the Consortium for Slow Commotion Research (CSCR) V.G. Cerf April 1 1991 ASCII HTML 5

This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1217
RFC1218 Naming scheme for c=US North American Directory Forum April 1991 ASCII HTML 23

This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1255 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1218
RFC1219 On the assignment of subnet numbers P.F. Tsuchiya April 1991 ASCII HTML 13 SUBNETASGN

This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1219
RFC1220 Point-to-Point Protocol extensions for bridging F. Baker April 1991 ASCII HTML 18

This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]

RFC1638 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1220
RFC1221 Host Access Protocol (HAP) specification: Version 2 W. Edmond April 1991 ASCII HTML 68 HAP2

This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC0907 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1221
RFC1222 Advancing the NSFNET routing architecture H.W. Braun Y. Rekhter May 1991 ASCII HTML 6

This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1222
RFC1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel J.M. Halpern May 1991 ASCII HTML 12 OSI-HYPER

The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1223
RFC1224 Techniques for managing asynchronously generated alerts L. Steinberg May 1991 ASCII HTML 22 ALERTS

This memo defines common mechanisms for managing asynchronously produced alerts in a manner consistent with current network management protocols. This memo specifies an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF alertman 10.17487/RFC1224
RFC1225 Post Office Protocol: Version 3 M.T. Rose May 1991 ASCII HTML 16

This memo suggests a simple method for workstations to dynamically access mail from a mailbox server. [STANDARDS-TRACK]

RFC1081 RFC1460 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1225
RFC1226 Internet protocol encapsulation of AX.25 frames B. Kantor May 1991 ASCII HTML 2 IP-AX.25

This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1226
RFC1227 SNMP MUX protocol and MIB M.T. Rose May 1991 ASCII HTML 13 SNMP-MUX

This memo suggests a mechanism by which a user process may associate itself with the local SNMP agent on a host, in order to implement portions of the MIB. This mechanism would be local to the host.This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

HISTORIC HISTORIC Legacy http://www.rfc-editor.org/errata_search.php?rfc=1227 10.17487/RFC1227
RFC1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface G. Carpenter B. Wijnen May 1991 ASCII HTML 50

This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1592 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1228
RFC1229 Extensions to the generic-interface MIB K. McCloghrie May 1991 ASCII HTML 16

This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS-TRACK]

RFC1573 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1229
RFC1230 IEEE 802.4 Token Bus MIB K. McCloghrie R. Fox May 1991 ASCII HTML 23 802.4-MIP

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.4 Token Bus technology described in 802.4 Token-Passing Bus Access Method and Physical Layer Specifications, IEEE Standard 802.4. [STANDARDS-TRACK]

RFC1239 HISTORIC HISTORIC IETF snmp 10.17487/RFC1230
RFC1231 IEEE 802.5 Token Ring MIB K. McCloghrie R. Fox E. Decker May 1991 ASCII HTML 23

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

RFC1743 RFC1748 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1231
RFC1232 Definitions of managed objects for the DS1 Interface type F. Baker C.P. Kolb May 1991 ASCII HTML 28 RFC1406 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1232 RFC1233 Definitions of managed objects for the DS3 Interface type T.A. Cox K. Tesink May 1991 ASCII HTML 23

This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

RFC1407 RFC1239 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1233
RFC1234 Tunneling IPX traffic through IP networks D. Provan June 1991 ASCII HTML 6 IPX-IP

This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1234
RFC1235 Coherent File Distribution Protocol J. Ioannidis G. Maguire June 1991 ASCII HTML 12 CFDP

This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1235
RFC1236 IP to X.121 address mapping for DDN L. Morales P. Hasse June 1991 ASCII HTML 7 IP-X.121

This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1236
RFC1237 Guidelines for OSI NSAP Allocation in the Internet R. Colella E. Gardner R. Callon July 1991 ASCII PS PDF HTML 48

This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]

RFC1629 PROPOSED STANDARD PROPOSED STANDARD IETF osinsap 10.17487/RFC1237
RFC1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) G. Satz June 1991 ASCII HTML 32 CLNS-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1162 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1238
RFC1239 Reassignment of experimental MIBs to standard MIBs J.K. Reynolds June 1991 ASCII HTML 2 STD-MIBs

This memo specifically updates RFC 1229, RFC 1230, RFC 1231, RFC 1232 and RFC 1233 with new codes. [STANDARDS-TRACK]

RFC1229 RFC1230 RFC1231 RFC1232 RFC1233 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1239
RFC1240 OSI connectionless transport services on top of UDP: Version 1 C. Shue W. Haggerty K. Dobbins June 1991 ASCII HTML 8 OSI-UDP

This document describes a protocol for running OSI Connectionless service on UDP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1240
RFC1241 Scheme for an internet encapsulation protocol: Version 1 R.A. Woodburn D.L. Mills July 1991 ASCII PS PDF HTML 17 IN-ENCAP

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1241
RFC1242 Benchmarking Terminology for Network Interconnection Devices S. Bradner July 1991 ASCII HTML 12

This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6201 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1242
RFC1243 AppleTalk Management Information Base S. Waldbusser July 1991 ASCII HTML 29

This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]

RFC1742 PROPOSED STANDARD PROPOSED STANDARD IETF int appleip 10.17487/RFC1243
RFC1244 Site Security Handbook J.P. Holbrook J.K. Reynolds July 1991 ASCII HTML 101

This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8]

RFC2196 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1244
RFC1245 OSPF Protocol Analysis J. Moy July 1991 ASCII PS PDF HTML 12 OSPF SPF routing TOS LSA flooding

This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard.

RFC1246 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1245
RFC1246 Experience with the OSPF Protocol J. Moy July 1991 ASCII PS PDF HTML 31 OSPF SPF routing MIB experience testing

This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard.

RFC1245 RFC1247 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1246
RFC1247 OSPF Version 2 J. Moy July 1991 ASCII PS PDF HTML 189 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]

RFC1131 RFC1583 RFC1349 RFC1245 RFC1246 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1247
RFC1248 OSPF Version 2 Management Information Base F. Baker R. Coltun July 1991 ASCII HTML 42 OSPF SPF MIB routing network management

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

RFC1252 RFC1349 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1248
RFC1249 DIXIE Protocol Specification T. Howes M. Smith B. Beecher August 1991 ASCII HTML 10 DIXIE DIXIE protocol directory services X.500 DAP

This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard.

RFC1202 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1249
RFC1250 IAB Official Protocol Standards J. Postel August 1991 ASCII HTML 28 standards protocol IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1200 RFC2200 RFC1280 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1250
RFC1251 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin August 1991 ASCII HTML 26 IESG IRSG IAB

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9]

RFC1336 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1251
RFC1252 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII HTML 42 OSPF SPF MIB routing network management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

RFC1248 RFC1253 RFC1245 RFC1247 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1252
RFC1253 OSPF Version 2 Management Information Base F. Baker R. Coltun August 1991 ASCII HTML 42

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]

RFC1252 RFC1850 RFC1245 RFC1246 RFC1247 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1253
RFC1254 Gateway Congestion Control Survey A. Mankin K. Ramakrishnan August 1991 ASCII HTML 25 gateway congestion SQ source quench fiar queueing random drop

The purpose of this paper is to present a review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication (DEC Bit), and Fair Queueing.

INFORMATIONAL INFORMATIONAL IETF int pcc 10.17487/RFC1254
RFC1255 A Naming Scheme for c=US The North American Directory Forum September 1991 ASCII HTML 25 naming NADF X.500 directory services c=us

This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1218 RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1255
RFC1256 ICMP Router Discovery Messages S. Deering Editor September 1991 ASCII HTML 19 ICMP-ROUT ICMP router gateway discovery standard protocol

This document specifies an extension of the Internet Control Message Protocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int rdisc 10.17487/RFC1256
RFC1257 Isochronous applications do not require jitter-controlled networks C. Partridge September 1991 ASCII HTML 5

This memo argues that jitter control is not required for networks to support isochronous applications. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1257
RFC1258 BSD Rlogin B. Kantor September 1991 ASCII HTML 5

The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1282 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1258 10.17487/RFC1258
RFC1259 Building the open road: The NREN as test-bed for the national public network M. Kapor September 1991 ASCII HTML 23 NREN test-bed network policy

This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1259
RFC1260 RFC1261 Transition of Nic Services S. Williamson L. Nobile September 1991 ASCII HTML 3 NIC transition

This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1261
RFC1262 Guidelines for Internet Measurement Activities V.G. Cerf October 1991 ASCII HTML 3

This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1262
RFC1263 TCP Extensions Considered Harmful S. O'Malley L.L. Peterson October 1991 ASCII HTML 19

This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve the Internet protocol suite. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1263
RFC1264 Internet Engineering Task Force Internet Routing Protocol Standardization Criteria R.M. Hinden October 1991 ASCII HTML 8

This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.

RFC4794 HISTORIC INFORMATIONAL IETF IESG 10.17487/RFC1264
RFC1265 BGP Protocol Analysis Y. Rekhter October 1991 ASCII HTML 8

This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1265
RFC1266 Experience with the BGP Protocol Y. Rekhter October 1991 ASCII HTML 9

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1266
RFC1267 Border Gateway Protocol 3 (BGP-3) K. Lougheed Y. Rekhter October 1991 ASCII HTML 35 BGP3

This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1163 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1267
RFC1268 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross October 1991 ASCII HTML 13 BGP3

This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

RFC1164 RFC1655 HISTORIC HISTORIC IETF rtg idr 10.17487/RFC1268
RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 S. Willis J.W. Burruss October 1991 ASCII HTML 13 BGP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]

RFC4273 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1269
RFC1270 SNMP Communications Services F. Kastenholz October 1991 ASCII HTML 11

This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1270
RFC1271 Remote Network Monitoring Management Information Base S. Waldbusser November 1991 ASCII HTML 81

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

RFC1757 RFC1513 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1271
RFC1272 Internet Accounting: Background C. Mills D. Hirsh G.R. Ruth November 1991 ASCII HTML 19

This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF acct 10.17487/RFC1272
RFC1273 Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations M.F. Schwartz November 1991 ASCII HTML 8

This memo describes plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1273
RFC1274 The COSINE and Internet X.500 Schema P. Barker S. Kille November 1991 ASCII HTML 60 Naming

This document suggests an X.500 Directory Schema, or Naming Architecture, for use in the COSINE and Internet X.500 pilots. [STANDARDS-TRACK]

RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1274
RFC1275 Replication Requirements to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII PS PDF HTML 3

This RFC considers certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective open Internet Directory can be established using these protocols and services [CCI88]. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1275
RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 S.E. Hardcastle-Kille November 1991 ASCII PS HTML 17

Some requirements on extensions to X.500 are described in the RFC[HK91b], in order to build an Internet Directory using X.500(1988). This document specifies a set of solutions to the problems raised. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1276
RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers S.E. Hardcastle-Kille November 1991 ASCII PS HTML 12 address ISO OSI

This document defines a new network address format, and rules for using some existing network address formats. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1277
RFC1278 A string encoding of Presentation Address S.E. Hardcastle-Kille November 1991 ASCII PS HTML 7 OSI ASN.1

There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1278
RFC1279 X.500 and Domains S.E. Hardcastle-Kille November 1991 ASCII PS PDF HTML 15 Domain Name naming

This RFC considers X.500 in relation to Internet and UK Domains. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1279
RFC1280 IAB Official Protocol Standards J. Postel March 1992 ASCII HTML 32

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1250 RFC1360 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1280
RFC1281 Guidelines for the Secure Operation of the Internet R. Pethia S. Crocker B. Fraser November 1991 ASCII HTML 10 security privacy protection guideline

The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF sec spwg 10.17487/RFC1281
RFC1282 BSD Rlogin B. Kantor December 1991 ASCII HTML 5 BSD Login Unix remote-login remote-logon

This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1258 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1282
RFC1283 SNMP over OSI M. Rose December 1991 ASCII HTML 8 ISO Management MIB

This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.

RFC1418 EXPERIMENTAL EXPERIMENTAL IETF snmp 10.17487/RFC1283
RFC1284 Definitions of Managed Objects for the Ethernet-like Interface Types J. Cook Editor December 1991 ASCII HTML 21 SNMP MIB Management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC1398 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1284
RFC1285 FDDI Management Information Base J. Case January 1992 ASCII HTML 46 FDDI-MIB standard standards MIB SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI. [STANDARDS-TRACK]

RFC1512 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1285
RFC1286 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie December 1991 ASCII HTML 40 SNMP MIB standard standards

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]

RFC1493 RFC1525 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC1286
RFC1287 Towards the Future Internet Architecture D. Clark L. Chapin V. Cerf R. Braden R. Hobby December 1991 ASCII HTML 29

This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1287
RFC1288 The Finger User Information Protocol D. Zimmerman December 1991 ASCII HTML 12 FINGER

This memo describes the Finger user information protocol.This is a simple protocol which provides an interface to a remote user information program. [STANDARDS-TRACK]

RFC1196 RFC1194 RFC0742 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1288
RFC1289 DECnet Phase IV MIB Extensions J. Saperia December 1991 ASCII HTML 64 SNMP Management protocol standard standards

This memo is an extension to the SNMP MIB. This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. [STANDARDS-TRACK]

RFC1559 PROPOSED STANDARD PROPOSED STANDARD IETF decnetiv 10.17487/RFC1289
RFC1290 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin December 1991 ASCII HTML 27 SIGUCCS User Services Help Internet

This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users. This RFC provides information for the Internet community. It does not specify an Internet standard.

RFC1402 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1290
RFC1291 Mid-Level Networks Potential Technical Services V. Aggarwal December 1991 ASCII PS HTML 10 statistics connectivity management

This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. This RFC provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1291
RFC1292 A Catalog of Available X.500 Implementations R. Lang R. Wright January 1992 ASCII HTML 103

The goal of this document is to provide information regarding the availability and capability of implementations of X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1632 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1292
RFC1293 Inverse Address Resolution Protocol T. Bradley C. Brown January 1992 ASCII HTML 6 standard standards ARP DLCI

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

RFC2390 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1293
RFC1294 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis January 1992 ASCII HTML 28 standard standards

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

RFC1490 RFC2427 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1294
RFC1295 User Bill of Rights for entries and listings in the Public Directory The North American Directory Forum January 1992 ASCII HTML 2 NADF-265 NADF X.500

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 and RFC1407. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1295
RFC1296 Internet Growth (1981-1991) M. Lottor January 1992 ASCII HTML 9 statistics ZONE

This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1296
RFC1297 NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS") D. Johnson January 1992 ASCII HTML 12 problems tracking operations NOC

This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF ucp 10.17487/RFC1297
RFC1298 SNMP over IPX R. Wormley S. Bostock February 1992 ASCII HTML 5

This memo defines a convention for encapsulating Simple Network Management Protocol (SNMP) packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1420 INFORMATIONAL INFORMATIONAL IETF snmp 10.17487/RFC1298
RFC1299 Summary of 1200-1299 M. Kennedy January 1997 ASCII HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1299 RFC1300 Remembrances of Things Past S. Greenfield February 1992 ASCII HTML 4 poem

Poem. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1300
RFC1301 Multicast Transport Protocol S. Armstrong A. Freier K. Marzullo February 1992 ASCII HTML 38 MTP MTP reliable transport multicast broadcast collaboration networking

This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1301
RFC1302 Building a Network Information Services Infrastructure D. Sitzler P. Smith A. Marine February 1992 ASCII HTML 13 NISI NIC User Services

This FYI RFC document is intended for existing Internet Network Information Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0012 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1302
RFC1303 A Convention for Describing SNMP-based Agents K. McCloghrie M. Rose February 1992 ASCII HTML 12 SNMP MIB Network Management,

This memo suggests a straight-forward approach towards describing SNMP- based agents. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1155 RFC1157 RFC1212 RFC1213 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1303
RFC1304 Definitions of Managed Objects for the SIP Interface Type T. Cox Editor K. Tesink Editor February 1992 ASCII HTML 25 Standard MIB Network Management SMDS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing SIP (SMDS Interface Protocol) objects. [STANDARDS-TRACK]

RFC1694 PROPOSED STANDARD PROPOSED STANDARD IETF snmp 10.17487/RFC1304
RFC1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis D. Mills March 1992 ASCII PDF HTML 109 NTPV3 NTP

This document describes the Network Time Protocol (NTP), specifies its formal structure and summarizes information useful for its implementation. [STANDARDS-TRACK]

RFC0958 RFC1059 RFC1119 RFC5905 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1305
RFC1306 Experiences Supporting By-Request Circuit-Switched T3 Networks A. Nicholson J. Young March 1992 ASCII HTML 10 WAN Wide Area Net FDDI

This memo describes the experiences of a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers. This RFC provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1306
RFC1307 Dynamically Switched Link Control Protocol J. Young A. Nicholson March 1992 ASCII HTML 13 DSLCP Experimental Protocol T3 FDDI

This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit-switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1307
RFC1308 Executive Introduction to Directory Services Using the X.500 Protocol C. Weider J. Reynolds March 1992 ASCII HTML 4

This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0013 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1308
RFC1309 Technical Overview of Directory Services Using the X.500 Protocol C. Weider J. Reynolds S. Heker March 1992 ASCII HTML 16

This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts Directory Services based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0014 INFORMATIONAL INFORMATIONAL IETF disi 10.17487/RFC1309
RFC1310 The Internet Standards Process L. Chapin March 1992 ASCII HTML 23

This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK]

RFC1602 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1310
RFC1311 Introduction to the STD Notes J. Postel March 1992 ASCII HTML 5 new IAB

The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1311
RFC1312 Message Send Protocol 2 R. Nelson G. Arnold April 1992 ASCII HTML 8 MSP2 MSP talk

The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.

RFC1159 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1312
RFC1313 Today's Programming for KRFC AM 1313 Internet Talk Radio C. Partridge April 1 1992 ASCII HTML 3

Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1313
RFC1314 A File Format for the Exchange of Images in the Internet A. Katz D. Cohen April 1992 ASCII HTML 23 NETFAX netfax TIFF facsimile

This document defines a standard file format for the exchange of fax- like black and white images within the Internet. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app netfax 10.17487/RFC1314
RFC1315 Management Information Base for Frame Relay DTEs C. Brown F. Baker C. Carvalho April 1992 ASCII HTML 19 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Frame Relay. [STANDARDS-TRACK]

RFC2115 PROPOSED STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1315
RFC1316 Definitions of Managed Objects for Character Stream Devices B. Stewart April 1992 ASCII HTML 17 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]

RFC1658 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1316
RFC1317 Definitions of Managed Objects for RS-232-like Hardware Devices B. Stewart April 1992 ASCII HTML 17 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

RFC1659 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1317
RFC1318 Definitions of Managed Objects for Parallel-printer-like Hardware Devices B. Stewart April 1992 ASCII HTML 11 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]

RFC1660 PROPOSED STANDARD PROPOSED STANDARD IETF charmib 10.17487/RFC1318
RFC1319 The MD2 Message-Digest Algorithm B. Kaliski April 1992 ASCII HTML 17 security encryption signature

This document describes the MD2 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6149 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1319 10.17487/RFC1319
RFC1320 The MD4 Message-Digest Algorithm R. Rivest April 1992 ASCII HTML 20 MD4 security encryption signature

This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1186 RFC6150 HISTORIC INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1320 10.17487/RFC1320
RFC1321 The MD5 Message-Digest Algorithm R. Rivest April 1992 ASCII HTML 21 security signature eneryption

This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6151 INFORMATIONAL INFORMATIONAL IETF sec pem http://www.rfc-editor.org/errata_search.php?rfc=1321 10.17487/RFC1321
RFC1322 A Unified Approach to Inter-Domain Routing D. Estrin Y. Rekhter S. Hotz May 1992 ASCII HTML 38 path vector routing source demand routing

This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg bgp http://www.rfc-editor.org/errata_search.php?rfc=1322 10.17487/RFC1322
RFC1323 TCP Extensions for High Performance V. Jacobson R. Braden D. Borman May 1992 ASCII HTML 37 TCP-EXT options PAWS window scale window

This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]

RFC1072 RFC1185 RFC7323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=1323 10.17487/RFC1323
RFC1324 A Discussion on Computer Network Conferencing D. Reed May 1992 ASCII HTML 11 talk real time chat

This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1324
RFC1325 FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions G. Malkin A. Marine May 1992 ASCII HTML 42 documentation help information

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1206 RFC1594 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1325
RFC1326 Mutual Encapsulation Considered Dangerous P. Tsuchiya May 1992 ASCII HTML 5 protocol layering wrapping

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1326
RFC1327 Mapping between X.400(1988) / ISO 10021 and RFC 822 S. Hardcastle-Kille May 1992 ASCII HTML 113 Electronic-mail,Message handling systems

This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on the DARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected. [STANDARDS-TRACK]

RFC0987 RFC1026 RFC1138 RFC1148 RFC2156 RFC0822 RFC1495 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1327
RFC1328 X.400 1988 to 1984 downgrading S. Hardcastle-Kille May 1992 ASCII HTML 5 Electronic-mail message handling systems,mail

This document considers issues of downgrading from X.400(1988) to X.400(1984) [MHS88a, MHS84]. Annexe B of X.419 specifies some downgrading rules [MHS88b], but these are not sufficient for provision of service in an environment containing both 1984 and 1988 components. This document defines a number of extensions to this annexe. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1328
RFC1329 Thoughts on Address Resolution for Dual MAC FDDI Networks P. Kuehn May 1992 ASCII HTML 28

In this document an idea is submitted how IP and ARP can be used on inhomogeneous FDDI networks (FDDI networks with single MAC and dual MAC stations) by introducing a new protocol layer in the protocol suite of the dual MAC stations. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1329
RFC1330 Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community ESCC X.500/X.400 Task Force ESnet Site Coordinating Comittee (ESCC) Energy Sciences Network (ESnet) May 1992 ASCII HTML 87

This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1330
RFC1331 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links W. Simpson May 1992 ASCII HTML 69 serial line IP over serial dial-up

This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

RFC1171 RFC1172 RFC1548 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1331
RFC1332 The PPP Internet Protocol Control Protocol (IPCP) G. McGregor May 1992 ASCII HTML 14 PPP-IPCP serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. [STANDARDS-TRACK]

RFC1172 RFC3241 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1332
RFC1333 PPP Link Quality Monitoring W. Simpson May 1992 ASCII HTML 17 serial line IP over serial dial-up

The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. [STANDARDS-TRACK]

RFC1989 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1333
RFC1334 PPP Authentication Protocols B. Lloyd W. Simpson October 1992 ASCII HTML 16 point serial line dial-up

This document defines two protocols for Authentication: the Password Authentication Protocol and the Challenge-Handshake Authentication Protocol. [STANDARDS-TRACK]

RFC1994 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1334
RFC1335 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion Z. Wang J. Crowcroft May 1992 ASCII HTML 7 internet protocol IP

This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1335
RFC1336 Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members G. Malkin May 1992 ASCII HTML 33 Almquist Braden Braun Callon Cerf Chiappa Chapin Clark Crocker Davin Estrin Hobby Huitema Huizer Kent Lauck Leiner Lynch Piscitello Postel Reynolds Schwartz Stockman Vaudreuil

This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify any standard.

RFC1251 FYI0009 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1336
RFC1337 TIME-WAIT Assassination Hazards in TCP R. Braden May 1992 ASCII HTML 11 TCP protocol protocol state graceful close reset

This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1337
RFC1338 Supernetting: an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan June 1992 ASCII HTML 20 internet address routing

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1519 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1338
RFC1339 Remote Mail Checking Protocol S. Dorner P. Resnick June 1992 ASCII HTML 6 RMCP email remote mail

This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1339
RFC1340 Assigned Numbers J. Reynolds J. Postel July 1992 ASCII HTML 139

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

RFC1060 RFC1700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1340 10.17487/RFC1340
RFC1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed June 1992 ASCII PS PDF HTML 80 EMail Multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]

RFC1521 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1341
RFC1342 Representation of Non-ASCII Text in Internet Message Headers K. Moore June 1992 ASCII HTML 7 EMail Character Sets

This memo describes an extension to the message format defined in [1] (known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC 822 message headers. [STANDARDS-TRACK]

RFC1522 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1342
RFC1343 A User Agent Configuration Mechanism for Multimedia Mail Format Information N. Borenstein June 1992 ASCII PS PDF HTML 10 EMail Multimedia

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1343
RFC1344 Implications of MIME for Internet Mail Gateways N. Borenstein June 1992 ASCII PS PDF HTML 9 EMail Forwarding Relaying Fragmentation Multimedia

While MIME was carefully designed so that it does not require any changes to Internet electronic message transport facilities, there are several ways in which message transport systems may want to take advantage of MIME. These opportunities are the subject of this memo. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1344
RFC1345 Character Mnemonics and Character Sets K. Simonsen June 1992 ASCII HTML 103

This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=1345 10.17487/RFC1345
RFC1346 Resource Allocation, Control, and Accounting for the Use of Network Resources P. Jones June 1992 ASCII HTML 6

The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1346
RFC1347 TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing R. Callon June 1992 ASCII PS PDF HTML 8

This paper describes a simple proposal which provides a long-term solution to Internet addressing, routing, and scaling. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1347
RFC1348 DNS NSAP RRs B. Manning July 1992 ASCII HTML 4 domain names CLNP resource records

This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.

RFC1637 RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1348
RFC1349 Type of Service in the Internet Protocol Suite P. Almquist July 1992 ASCII HTML 28 TOS TOS IP

This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]

RFC2474 RFC1248 RFC1247 RFC1195 RFC1123 RFC1122 RFC1060 RFC0791 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1349 10.17487/RFC1349
RFC1350 The TFTP Protocol (Revision 2) K. Sollins July 1992 ASCII HTML 11 TFTP trivial file transfer booting

TFTP is a very simple protocol used to transfer files. It is from this that its name comes, Trivial File Transfer Protocol or TFTP. Each nonterminal packet is acknowledged separately. This document describes the protocol and its types of packets. The document also explains the reasons behind some of the design decisions. [STANDARDS-TRACK]

RFC0783 RFC1782 RFC1783 RFC1784 RFC1785 RFC2347 RFC2348 RFC2349 STD0033 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1350 10.17487/RFC1350
RFC1351 SNMP Administrative Model J. Davin J. Galvin K. McCloghrie July 1992 ASCII HTML 35 SNMP-ADMIN network management authentication

This memo presents an elaboration of the SNMP administrative model set forth in [1]. This model provides a unified conceptual basis for administering SNMP protocol entities to support: authenticaiton and integrity, privacy, access control, and cooperation of protocol entities. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1351
RFC1352 SNMP Security Protocols J. Galvin K. McCloghrie J. Davin July 1992 ASCII HTML 41 SNMP-SEC network management authentication

The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1352
RFC1353 Definitions of Managed Objects for Administration of SNMP Parties K. McCloghrie J. Davin J. Galvin July 1992 ASCII HTML 26 SNMP-PARTY-MIB network management authentication

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes a representation of the SNMP parties defined in [8] as objects defined according to the Internet Standard SMI [1]. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec snmpsec 10.17487/RFC1353
RFC1354 IP Forwarding Table MIB F. Baker July 1992 ASCII HTML 12 Network Management Route Table

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing routes in the IP Internet. [STANDARDS-TRACK]

RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq 10.17487/RFC1354
RFC1355 Privacy and Accuracy Issues in Network Information Center Databases J. Curran A. Marine August 1992 ASCII HTML 4 NIC data privacy accuracy

This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0015 INFORMATIONAL INFORMATIONAL IETF nisi 10.17487/RFC1355
RFC1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode A. Malis D. Robinson R. Ullmann August 1992 ASCII HTML 14 IP-X.25 IP on X.25

This document specifies the encapsulation of IP and other network layer protocols over X.25 networks, in accordance and alignment with ISO/IEC and CCITT standards. It is a replacement for RFC 877, "A Standard for the Transmission of IP Datagrams Over Public Data Networks" [1]. [STANDARDS-TRACK]

RFC0877 DRAFT STANDARD PROPOSED STANDARD IETF int iplpdn 10.17487/RFC1356
RFC1357 A Format for E-mailing Bibliographic Records D. Cohen July 1992 ASCII HTML 13 library technical reports email services

This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1807 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1357
RFC1358 Charter of the Internet Architecture Board (IAB) L. Chapin August 1992 ASCII HTML 5 ISOC Internet Society IETF IRTF

The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1601 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1358
RFC1359 Connecting to the Internet - What Connecting Institutions Should Anticipate ACM SIGUCCS August 1992 ASCII HTML 25 Internet access

This FYI RFC outlines the major issues an institution should consider in the decision and implementation of a campus connection to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0016 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1359
RFC1360 IAB Official Protocol Standards J. Postel September 1992 ASCII HTML 33 proposed draft experimental informational historic full RFC1280 RFC1410 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1360 RFC1361 Simple Network Time Protocol (SNTP) D. Mills August 1992 ASCII HTML 10 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memorandum does not obsolete or update any RFC. This memo provides information for the Internet community. It does not specify an Internet standard. Discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.9 contain the lists of protocols in each stage of standardization. Finally come pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC1769 RFC1305 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1361 10.17487/RFC1361
RFC1362 Novell IPX over Various WAN Media (IPXWAN) M. Allen September 1992 ASCII HTML 13 IPX on X.25 IPX on PPP IPX on Frame Relay

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1362
RFC1363 A Proposed Flow Specification C. Partridge September 1992 ASCII HTML 20 flow spec resource reservation stream type of service quality of service INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1363 RFC1364 BGP OSPF Interaction K. Varadhan September 1992 ASCII HTML 14 autonomous system border router open shortest path first routing protocol domain route exchange exporting importing RFC1403 RFC1247 RFC1267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1364 RFC1365 An IP Address Extension Proposal K. Siyan September 1992 ASCII HTML 6 class F addresses INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1365 10.17487/RFC1365 RFC1366 Guidelines for Management of IP Address Space E. Gerich October 1992 ASCII HTML 8 routing tables allocation registry IR IANA

This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. This memo provides information for the Internet community. It does not specify an Internet standard. This memo defines the various criteria to be used when designing Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK] 1363 Partridge Spt 92 A Proposed Flow Specification The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1466 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1366
RFC1367 Schedule for IP Address Space Management Guidelines C. Topolcic October 1992 ASCII HTML 3 routing tables allocation registry IR IANA

This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1467 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1367
RFC1368 Definition of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie October 1992 ASCII HTML 40 MIB hub management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs". [STANDARDS-TRACK]

RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1368
RFC1369 Implementation Notes and Experience for the Internet Ethernet MIB F. Kastenholz October 1992 ASCII HTML 7 management

This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL PROPOSED STANDARD IETF ethermib 10.17487/RFC1369
RFC1370 Applicability Statement for OSPF Internet Architecture Board L. Chapin October 1992 ASCII HTML 2 routing open shortest path first

This Applicability Statement places a requirement on vendors claiming conformance to this standard, in order to assure that users will have the option of deploying OSPF when they need a multivendor, interoperable IGP in their environment. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1370
RFC1371 Choosing a Common IGP for the IP Internet P. Gross October 1992 ASCII HTML 9 routing recommendation interior gateway protocol

This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to the IAB for a single "common IGP" for the IP portions of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1371
RFC1372 Telnet Remote Flow Control Option C. Hedrick D. Borman October 1992 ASCII HTML 6 TOPT-RFC terminal access

This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]

RFC1080 PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1372
RFC1373 Portable DUAs T. Tignor October 1992 ASCII HTML 12 directory user agents whois de dixie ud doog ISODE X.500

This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1373
RFC1374 IP and ARP on HIPPI J. Renwick A. Nicholson October 1992 ASCII HTML 43

The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks. This memo is intended to become an Internet Standard. [STANDARDS-TRACK]

RFC2834 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1374
RFC1375 Suggestion for New Classes of IP Addresses P. Robinson October 1992 ASCII HTML 7 network numbers

This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1375
RFC1376 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum November 1992 ASCII HTML 6 point DNA DDCMP

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.). [STANDARDS-TRACK]

RFC1762 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1376
RFC1377 The PPP OSI Network Layer Control Protocol (OSINLCP) D. Katz November 1992 ASCII HTML 10 PPP-OSINLCP point open systems interconnection

This document defines the NCP for establishing and configuring OSI Network Layer Protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1377
RFC1378 The PPP AppleTalk Control Protocol (ATCP) B. Parker November 1992 ASCII HTML 16 PPP-ATCP point

This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1378
RFC1379 Extending TCP for Transactions -- Concepts R. Braden November 1992 ASCII HTML 38 transmission control protocol

This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6247 RFC1644 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1379
RFC1380 IESG Deliberations on Routing and Addressing P. Gross P. Almquist November 1992 ASCII HTML 22 ROAD

This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1380
RFC1381 SNMP MIB Extension for X.25 LAPB D. Throop F. Baker November 1992 ASCII HTML 33 SNMP-LAPB management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Link Layer of X.25, LAPB. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1381
RFC1382 SNMP MIB Extension for the X.25 Packet Layer D. Throop Editor November 1992 ASCII HTML 69 SNMP-X.25 management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF x25mib 10.17487/RFC1382
RFC1383 An Experiment in DNS Based IP Routing C. Huitema December 1992 ASCII HTML 14 DNS-IP

Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1383
RFC1384 Naming Guidelines for Directory Pilots P. Barker S.E. Hardcastle-Kille January 1993 ASCII PS PDF HTML 12 X.500 Multinational

This document defines a number of naming guidelines. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1617 RTR0011 INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1384
RFC1385 EIP: The Extended Internet Protocol Z. Wang November 1992 ASCII HTML 17 addressing

EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1385
RFC1386 The US Domain A. Cooper J. Postel December 1992 ASCII HTML 31 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1480 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1386
RFC1387 RIP Version 2 Protocol Analysis G. Malkin January 1993 ASCII HTML 3 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1721 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1387
RFC1388 RIP Version 2 Carrying Additional Information G. Malkin January 1993 ASCII HTML 7 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), as defined in [STANDARDS-TRACK]

RFC1723 RFC1058 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1388
RFC1389 RIP Version 2 MIB Extensions G. Malkin F. Baker January 1993 ASCII HTML 13 RIP-2 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK]

RFC1724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC1389
RFC1390 Transmission of IP and ARP over FDDI Networks D. Katz January 1993 ASCII HTML 11 IP-FDDI IEEE 802 MAC

This memo defines a method of encapsulating the Internet Protocol (IP) datagrams and Address Resolution Protocol (ARP) requests and replies on Fiber Distributed Data Interface (FDDI) Networks. [STANDARDS-TRACK]

STD0036 INTERNET STANDARD INTERNET STANDARD IETF int fddi 10.17487/RFC1390
RFC1391 The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force G. Malkin January 1993 ASCII HTML 19 meetings

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1539 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1391
RFC1392 Internet Users' Glossary G. Malkin T. LaQuey Parker January 1993 ASCII HTML 53

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1983 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1392
RFC1393 Traceroute Using an IP Option G. Malkin January 1993 ASCII HTML 7 TRACE-IP ICMP MTU Line Speed

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time. This memo defines an Experimental Protocol for the Internet community.

RFC6814 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1393
RFC1394 Relationship of Telex Answerback Codes to Internet Domains P. Robinson January 1993 ASCII HTML 15 DNS Country

This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available. It will also list major Internet "Public" E-Mail addresses. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1394
RFC1395 BOOTP Vendor Information Extensions J. Reynolds January 1993 ASCII HTML 8 TAGS

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).

RFC1084 RFC1048 RFC1497 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1395
RFC1396 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker January 1993 ASCII HTML 10 IAB IESG ISOC

This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1396
RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol D. Haskin January 1993 ASCII HTML 2 BGP

This document speficies the recommendation of the BGP Working Group on default route advertisement support in BGP2 [1] and BGP3 [2] versions of the Border Gateway Protocol. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1397
RFC1398 Definitions of Managed Objects for the Ethernet-Like Interface Types F. Kastenholz January 1993 ASCII HTML 17 MIB Management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ehternet-like objects. [STANDARDS-TRACK]

RFC1284 RFC1623 DRAFT STANDARD DRAFT STANDARD IETF ethermib 10.17487/RFC1398
RFC1399 Summary of 1300-1399 J. Elliott January 1997 ASCII HTML 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1399 RFC1400 Transition and Modernization of the Internet Registration Service S. Williamson March 1993 ASCII HTML 7 INTERNIC IR

As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1400
RFC1401 Correspondence between the IAB and DISA on the use of DNS Internet Architecture Board January 1993 ASCII HTML 8 Domain Name Milnet

This memo reproduces three letters exchanged between the Internet Activities Board (IAB) and the Defense Information Systems Agency (DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1401
RFC1402 There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places J. Martin January 1993 ASCII HTML 39 information introduction SIGUCCS User Services Help

The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. This RFC provides information for the Internet community. It does not specify an Internet standard.

RFC1290 FYI0010 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1402
RFC1403 BGP OSPF Interaction K. Varadhan January 1993 ASCII HTML 17 BGP-OSPF border gateway protocol open shortest path first routing

This memo defines the various criteria to be used when designing an Autonomous System Border Routers (ASBR) that will run BGP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

RFC1364 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1403
RFC1404 A Model for Common Operational Statistics B. Stockman January 1993 ASCII HTML 27 Management Operations

This memo describes a model for operational statistics in the Internet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1857 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1404
RFC1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) C. Allocchio January 1993 ASCII HTML 19 SMTP EMail 822

This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 ) Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail) protocol. This memo defines an Experimental Protocol for the Internet community.

RFC2162 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1405
RFC1406 Definitions of Managed Objects for the DS1 and E1 Interface Types F. Baker Editor J. Watt Editor January 1993 ASCII HTML 50 DS1/E1-MIB T1 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. [STANDARDS-TRACK]

RFC1232 RFC2495 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1406
RFC1407 Definitions of Managed Objects for the DS3/E3 Interface Type T. Cox K. Tesink January 1993 ASCII HTML 43 DS3/E3-MIB T3 MIB Management SNMP

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3 Interfaces. [STANDARDS-TRACK]

RFC1233 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC1407
RFC1408 Telnet Environment Option D. Borman Editor January 1993 ASCII HTML 7 TOPT-ENVIR Negotiation

This document specifies a mechanism for passing environment information between a telnet client and server. [STANDARDS-TRACK]

RFC1571 HISTORIC HISTORIC IETF app telnet 10.17487/RFC1408
RFC1409 Telnet Authentication Option D. Borman Editor January 1993 ASCII HTML 7 security

This memo defines an Experimental Protocol for the Internet community.

RFC1416 EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1409
RFC1410 IAB Official Protocol Standards J. Postel Editor March 1993 ASCII HTML 35 proposed draft experimental informational historic full

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB).

RFC1360 RFC1500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1410
RFC1411 Telnet Authentication: Kerberos Version 4 D. Borman Editor January 1993 ASCII HTML 4 TEL-KER Security option

This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1411
RFC1412 Telnet Authentication: SPX K. Alagappan January 1993 ASCII HTML 4 TEL-SPX Security option

This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app telnet 10.17487/RFC1412
RFC1413 Identification Protocol M. St. Johns February 1993 ASCII HTML 8 IDENT Authentication

The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]

RFC0931 PROPOSED STANDARD PROPOSED STANDARD IETF sec ident http://www.rfc-editor.org/errata_search.php?rfc=1413 10.17487/RFC1413
RFC1414 Identification MIB M. St. Johns M. Rose February 1993 ASCII HTML 7 IDENT-MIB Management SNMP

This memo defines a MIB for use with identifying the users associated with TCP connections. It provides functionality approximately equivalent to that provided by the protocol defined in RFC 1413 [1]. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec ident 10.17487/RFC1414
RFC1415 FTP-FTAM Gateway Specification J. Mindel R. Slaski January 1993 ASCII HTML 58 FTP FTAM transfer ISO OSI

This memo describes a dual protocol stack application layer gateway that performs protocol translation, in an interactive environment, between the FTP and FTAM file transfer protocols. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1415
RFC1416 Telnet Authentication Option D. Borman Editor February 1993 ASCII HTML 7 TOPT-AUTH Security

This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.

RFC1409 RFC2941 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1416
RFC1417 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1993 ASCII HTML 4 X.500 Directory

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1295 RFC1255 RFC1218 RFC1758 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1417
RFC1418 SNMP over OSI M. Rose March 1993 ASCII HTML 4 SNMP-OSI Management

This memo addresses some concerns by defining a framework for running the SNMP in an environment which supports the OSI connectionless-mode transport service. [STANDARDS-TRACK]

RFC1161 RFC1283 HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1418
RFC1419 SNMP over AppleTalk G. Minshall M. Ritter March 1993 ASCII HTML 7 SNMP-AT Management

This memo describes the method by which the Simple Network Management Protocol (SNMP) as specified in [1] can be used over AppleTalk protocols [2] instead of the Internet UDP/IP protocol stack. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1419
RFC1420 SNMP over IPX S. Bostock March 1993 ASCII HTML 4 SNMP-IPX Management

This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. [STANDARDS-TRACK]

RFC1298 PROPOSED STANDARD PROPOSED STANDARD IETF int mpsnmp 10.17487/RFC1420
RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures J. Linn February 1993 ASCII HTML 42 PEM-ENC PEM

This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]

RFC1113 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1421
RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management S. Kent February 1993 ASCII HTML 32 PEM-CKM PEM

This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]

RFC1114 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1422
RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers D. Balenson February 1993 ASCII HTML 14 PEM-ALG PEM

This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]

RFC1115 HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1423
RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services B. Kaliski February 1993 ASCII HTML 9 PEM-KEY PEM

This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1424
RFC1425 SMTP Service Extensions J. Klensin N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII HTML 10 Mail

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC1651 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1425
RFC1426 SMTP Service Extension for 8bit-MIMEtransport J. Klensin N. Freed Editor M. Rose E. Stefferud D. Crocker February 1993 ASCII HTML 6 Mail

This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP.

RFC1652 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1426
RFC1427 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed Editor K. Moore February 1993 ASCII HTML 8 Mail

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC1653 PROPOSED STANDARD PROPOSED STANDARD IETF app smtpext 10.17487/RFC1427
RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME G. Vaudreuil February 1993 ASCII HTML 6 Mail

This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. This RFC provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app smtpext 10.17487/RFC1428
RFC1429 Listserv Distribute Protocol E. Thomas February 1993 ASCII HTML 8 LISTSERV Mail

This memo specifies a subset of the distribution protocol used by the BITNET LISTSERV to deliver mail messages to large amounts of recipients. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1429
RFC1430 A Strategic Plan for Deploying an Internet X.500 Directory Service S. Hardcastle-Kille E. Huizer V. Cerf R. Hobby S. Kent February 1993 ASCII HTML 20 X.500

This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 Directory Service. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1430
RFC1431 DUA Metrics (OSI-DS 33 (v2)) P. Barker February 1993 ASCII HTML 19 Directory User Agent Measurement Statistics Survey X.500

This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1431
RFC1432 Recent Internet Books J. Quarterman March 1993 ASCII HTML 15 bibiography

Here is a list of books related to using the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1432
RFC1433 Directed ARP J. Garrett J. Hagan J. Wong March 1993 ASCII HTML 18 DIR-ARP public networks SMDS

Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF int iplpdn 10.17487/RFC1433
RFC1434 Data Link Switching: Switch-to-Switch Protocol R. Dixon D. Kushi March 1993 ASCII PS PDF HTML 33 IBM SNA DLS SSP NetBIos

This RFC describes IBM's support of Data Link Switching over TCP/IP. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1795 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1434
RFC1435 IESG Advice from Experience with Path MTU Discovery S. Knowles March 1993 ASCII HTML 2 Maximum Transmission Unit

In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTU Discovery. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1435
RFC1436 The Internet Gopher Protocol (a distributed document search and retrieval protocol) F. Anklesaria M. McCahill P. Lindner D. Johnson D. Torrey B. Albert March 1993 ASCII HTML 16 GOPHER information locating

This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1436
RFC1437 The Extension of MIME Content-Types to a New Medium N. Borenstein M. Linimon April 1 1993 ASCII HTML 6 life form Matter transport Sentient

This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1437
RFC1438 Internet Engineering Task Force Statements Of Boredom (SOBs) A. Lyman Chapin C. Huitema April 1 1993 ASCII HTML 2 process policy

This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1438 10.17487/RFC1438
RFC1439 The Uniqueness of Unique Identifiers C. Finseth March 1993 ASCII HTML 11 names

This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1439
RFC1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer R. Troth July 1993 ASCII HTML 9 SIFT UFT Send FTP

This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1440
RFC1441 Introduction to version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 13 SNMPv2 SNMP Management Framework

The purpose of this document is to provide an overview of version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF snmpv2 10.17487/RFC1441
RFC1442 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 56 SNMP Management Framework SMI

Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]

RFC1902 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1442
RFC1443 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 31 SNMP Management Framework

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC1903 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1443
RFC1444 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 33 SNMP Management Framework

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC1904 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1444
RFC1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII HTML 48 SNMP Management Framework

It is the purpose of this document, the Administrative Model for SNMPv2, to define how the administrative framework is applied to realize effective network management in a variety of configurations and environments. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1445
RFC1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) J. Galvin K. McCloghrie April 1993 ASCII HTML 52 SNMP Management Framework

It is the purpose of this document, Security Protocols for SNMPv2, to define one such authentication and one such privacy protocol. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1446
RFC1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) K. McCloghrie J. Galvin April 1993 ASCII HTML 50 SNMP Management Framework

The Administrative Model for SNMPv2 document [3] defines the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies. It is the purpose of this document, the Party MIB for SNMPv2, to define managed objects which correspond to these properties. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF sec snmpsec 10.17487/RFC1447
RFC1448 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 36 SNMP Management Framework

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

RFC1905 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1448
RFC1449 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 25 SNMP Management Framework

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

RFC1906 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1449
RFC1450 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 27 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

RFC1907 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1450
RFC1451 Manager-to-Manager Management Information Base J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 36 SNMP Management Framework

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity acting in both a manager role and an agent role. [STANDARDS-TRACK]

HISTORIC HISTORIC IETF snmpv2 10.17487/RFC1451
RFC1452 Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser April 1993 ASCII HTML 17 SNMP Management Framework

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

RFC1908 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC1452
RFC1453 A Comment on Packet Video Remote Conferencing and the Transport/Network Layers W. Chimiak April 1993 ASCII HTML 10 XTP

This RFC is a vehicle to inform the Internet community about XTP as it benefits from past Internet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1453
RFC1454 Comparison of Proposals for Next Version of IP T. Dixon May 1993 ASCII HTML 15 IPng PIP TUBA SIP

This is a slightly edited reprint of RARE Technical Report (RTC(93)004). This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1454
RFC1455 Physical Link Security Type of Service D. Eastlake 3rd May 1993 ASCII HTML 6 TOS-LS TOS

This RFC documents an experimental protocol providing a Type of Service (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type of Service in the Internet Protocol Suite. This memo defines an Experimental Protocol for the Internet community.

RFC2474 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1455
RFC1456 Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification Vietnamese Standardization Working Group May 1993 ASCII HTML 7 Character Set

This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into 7-bit US ASCII and in an 8-bit form. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1456
RFC1457 Security Label Framework for the Internet R. Housley May 1993 ASCII HTML 14

This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1457
RFC1458 Requirements for Multicast Protocols R. Braudes S. Zabele May 1993 ASCII HTML 19 Real-Time

This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1458
RFC1459 Internet Relay Chat Protocol J. Oikarinen D. Reed May 1993 ASCII HTML 65 IRCP IRC

The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. This memo defines an Experimental Protocol for the Internet community.

RFC2810 RFC2811 RFC2812 RFC2813 RFC7194 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1459 10.17487/RFC1459
RFC1460 Post Office Protocol - Version 3 M. Rose June 1993 ASCII HTML 17 Email

This memo is a revision to RFC 1225, a Draft Standard. [STANDARDS-TRACK]

RFC1225 RFC1725 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1460
RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 D. Throop May 1993 ASCII HTML 21 X25-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Multiprotocol Interconnect (including IP) traffic carried over X.25. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF x25mib 10.17487/RFC1461
RFC1462 FYI on "What is the Internet?" E. Krol E. Hoffman May 1993 ASCII HTML 11 Introduction

This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0020 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1462
RFC1463 FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings E. Hoffman L. Jackson May 1993 ASCII HTML 4

This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0019 INFORMATIONAL INFORMATIONAL IETF userdoc2 10.17487/RFC1463
RFC1464 Using the Domain Name System To Store Arbitrary String Attributes R. Rosenbaum May 1993 ASCII HTML 4 DNS TXT

This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1464 10.17487/RFC1464
RFC1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing D. Eppenberger May 1993 ASCII HTML 31 X400

This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1465
RFC1466 Guidelines for Management of IP Address Space E. Gerich May 1993 ASCII HTML 10 CIDR

This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1366 RFC2050 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1466
RFC1467 Status of CIDR Deployment in the Internet C. Topolcic August 1993 ASCII HTML 9 routing tables allocation registry IR IANA classless

This document describes the current status of the development and deployment of CIDR technology into the Internet. This document replaces RFC 1367, which was a schedule for the deployment of IP address space management procedures to support route aggregation. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1367 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1467
RFC1468 Japanese Character Encoding for Internet Messages J. Murai M. Crispin E. van der Poel June 1993 ASCII HTML 6 Set

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1468
RFC1469 IP Multicast over Token-Ring Local Area Networks T. Pusateri June 1993 ASCII HTML 4 IP-TR-MC 802.2 802.5

This document specifies a method for the transmission of IP multicast datagrams over Token-Ring Local Area Networks. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1469
RFC1470 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices R. Enger J. Reynolds June 1993 ASCII HTML 192 NOCTOOLS

The goal of this FYI memo is to provide an update to FYI 2, RFC 1147 [1], which provided practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1147 FYI0002 INFORMATIONAL INFORMATIONAL IETF noctool2 10.17487/RFC1470
RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 25 PPP/LCP MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1471
RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 13 PPP/SEC MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1472
RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 10 PPP/IP MIB Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols [8, 9, 10, 11, & 12]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1473
RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol F. Kastenholz June 1993 ASCII HTML 15 PPP/Bridge Management Framework PPP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol [10] on subnetwork interfaces using the family of Point-to-Point Protocols. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1474
RFC1475 TP/IX: The Next Internet R. Ullmann June 1993 ASCII HTML 35 TP-IX IPv7 IPng

This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC6814 HISTORIC EXPERIMENTAL IETF int tpix 10.17487/RFC1475
RFC1476 RAP: Internet Route Access Protocol R. Ullmann June 1993 ASCII HTML 20 RAP Routing

This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF int tpix 10.17487/RFC1476
RFC1477 IDPR as a Proposed Standard M. Steenstrup July 1993 ASCII HTML 13 Routing Policy

This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1477
RFC1478 An Architecture for Inter-Domain Policy Routing M. Steenstrup June 1993 ASCII HTML 35 IDPR-ARCH IDPR

We present an architecture for inter-domain policy routing (IDPR). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1478
RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 M. Steenstrup July 1993 ASCII HTML 108 IDPR IDPR

We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idpr 10.17487/RFC1479
RFC1480 The US Domain A. Cooper J. Postel June 1993 ASCII HTML 47 DNS top-level

This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1386 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1480
RFC1481 IAB Recommendation for an Intermediate Strategy to Address the Issue of Scaling C. Huitema July 1993 ASCII HTML 2 CIDR

CIDR is proposed as an immediate term strategy to extend the life of the current 32 bit IP address space. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1481
RFC1482 Aggregation Support in the NSFNET Policy-Based Routing Database M. Knopper S. Richardson June 1993 ASCII HTML 11 CIDR

This document describes plans for support of route aggregation, as specified in the descriptions of Classless Inter-Domain Routing (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network Service. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL IETF bgpdepl 10.17487/RFC1482
RFC1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5 Juha Heinanen July 1993 ASCII HTML 16 ATM-ENCAP IP AAL5 over

This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. [STANDARDS-TRACK]

RFC2684 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1483
RFC1484 Using the OSI Directory to achieve User Friendly Naming (OSI-DS 24 (v1.2)) S. Hardcastle-Kille July 1993 ASCII HTML 25 X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1781 RFC3494 HISTORIC EXPERIMENTAL IETF app osids 10.17487/RFC1484
RFC1485 A String Representation of Distinguished Names (OSI-DS 23 (v5)) S. Hardcastle-Kille July 1993 ASCII HTML 7 X.500 directory names representing names

When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. [STANDARDS-TRACK]

RFC1779 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1485
RFC1486 An Experiment in Remote Printing M. Rose C. Malamud July 1993 ASCII HTML 14 electronic mail facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1528 RFC1529 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1486
RFC1487 X.500 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille July 1993 ASCII HTML 21 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC1777 RFC3494 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1487
RFC1488 The X.500 String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins July 1993 ASCII HTML 11 X.500 LDAP lightweight directory protocol

This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3]. [STANDARDS-TRACK]

RFC1778 PROPOSED STANDARD PROPOSED STANDARD IETF app osids 10.17487/RFC1488
RFC1489 Registration of a Cyrillic Character Set A. Chernov July 1993 ASCII HTML 5

Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1489
RFC1490 Multiprotocol Interconnect over Frame Relay T. Bradley C. Brown A. Malis July 1993 ASCII HTML 35 standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. Additionally, it describes a simple fragmentation procedure for carrying large frames over a frame relay network with a smaller MTU. [STANDARDS-TRACK]

RFC1294 RFC2427 DRAFT STANDARD DRAFT STANDARD IETF int iplpdn 10.17487/RFC1490
RFC1491 A Survey of Advanced Usages of X.500 C. Weider R. Wright July 1993 ASCII HTML 18 directory

This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the Integrated Directory Services Working Group of the Application and User Services Areas of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard.

FYI0021 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1491
RFC1492 An Access Control Protocol, Sometimes Called TACACS C. Finseth July 1993 ASCII HTML 21 TACACS Terminal Server TAC

This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1492
RFC1493 Definitions of Managed Objects for Bridges E. Decker P. Langille A. Rijsinghani K. McCloghrie July 1993 ASCII HTML 34 BRIDGE-MIB SNMP MIB standard standards

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1990 standard between Local Area Network (LAN) segments. [STANDARDS-TRACK]

RFC1286 RFC4188 DRAFT STANDARD DRAFT STANDARD IETF ops bridge 10.17487/RFC1493
RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies H. Alvestrand S. Thompson August 1993 ASCII HTML 19 Equiv Mail

This document describes the content of the "IANA MHS/MIME Equivalence table", and defines the initial configuration of this table. Mappings for new MIME content-types and/or X.400 body part types should be registered with the IANA to minimize redundancy and promote interoperability. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1494
RFC1495 Mapping between X.400 and RFC-822 Message Bodies H. Alvestrand S. Kille R. Miles M. Rose S. Thompson August 1993 ASCII HTML 11 Mail

Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]

RFC2156 RFC1327 PROPOSED STANDARD PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1495
RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages H. Alvestrand J. Romaguera K. Jordan August 1993 ASCII HTML 5 HARPOON Mail

This document describes how RFC-1328 must be modified in order to provide adequate support for the scenarios: It replaces chapter 6 of RFC-1328. The rest of RFC-1328 is NOT obsoleted. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app mimemhs 10.17487/RFC1496
RFC1497 BOOTP Vendor Information Extensions J. Reynolds August 1993 ASCII HTML 8 TAGS Boot

This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).

RFC1395 RFC1084 RFC1048 RFC1533 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1497
RFC1498 On the Naming and Binding of Network Destinations J. Saltzer August 1993 ASCII HTML 10 NAMES Addresses Routes Objects Nodes Paths

This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas: First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1498 10.17487/RFC1498
RFC1499 Summary of 1400-1499 J. Elliott January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1499 RFC1500 Internet Official Protocol Standards J. Postel August 1993 ASCII HTML 36 IAB

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

RFC1410 RFC1540 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1500
RFC1501 OS/2 User Group E. Brunsen August 1993 ASCII HTML 2

Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1501
RFC1502 X.400 Use of Extended Character Sets H. Alvestrand August 1993 ASCII HTML 14 Mail

This RFC defines a suggested method of using "GeneralText" in order to harmonize as much as possible the usage of this body part. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1502
RFC1503 Algorithms for Automating Administration in SNMPv2 Managers K. McCloghrie M. Rose August 1993 ASCII HTML 14 Management SNMP

When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1503
RFC1504 Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing A. Oppenheimer August 1993 ASCII HTML 82 AVRP

This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1504
RFC1505 Encoding Header Field for Internet Messages A. Costanzo D. Robinson R. Ullmann August 1993 ASCII HTML 36 EHF-MAIL Mail

This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1154 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1505
RFC1506 A Tutorial on Gatewaying between X.400 and Internet Mail J. Houttuin August 1993 ASCII HTML 39 822 email RTR

This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1506
RFC1507 DASS - Distributed Authentication Security Service C. Kaufman September 1993 ASCII HTML 119 DASS CAT

The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC1507
RFC1508 Generic Security Service Application Program Interface J. Linn September 1993 ASCII HTML 49 CAT,GSS,API

This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

RFC2078 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1508
RFC1509 Generic Security Service API : C-bindings J. Wray September 1993 ASCII HTML 48 GSSAPI CAT,GSS

This document specifies C language bindings for the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. [STANDARDS-TRACK]

RFC2744 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1509
RFC1510 The Kerberos Network Authentication Service (V5) J. Kohl C. Neuman September 1993 ASCII HTML 112 KERBEROS CAT,Security

This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. [STANDARDS-TRACK]

RFC4120 RFC6649 HISTORIC PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=1510 10.17487/RFC1510
RFC1511 Common Authentication Technology Overview J. Linn September 1993 ASCII HTML 2 CAT,Security

This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1511
RFC1512 FDDI Management Information Base J. Case A. Rijsinghani September 1993 ASCII HTML 51 FDDI-MIB MIB SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing devices which implement the FDDI based on the ANSI FDDI SMT 7.3 draft standard, which has been forwarded for publication by the X3T9.5 committee.

RFC1285 HISTORIC PROPOSED STANDARD IETF fddimib 10.17487/RFC1512
RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB S. Waldbusser September 1993 ASCII HTML 55 Monitoring SNMP

This memo defines extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks. [STANDARDS-TRACK]

RFC1271 HISTORIC PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC1513
RFC1514 Host Resources MIB P. Grillo S. Waldbusser September 1993 ASCII HTML 33 HOST-MIB Management SNMP

This memo defines a MIB for use with managing host systems. [STANDARDS-TRACK]

RFC2790 PROPOSED STANDARD PROPOSED STANDARD IETF hostmib 10.17487/RFC1514
RFC1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) D. McMaster K. McCloghrie S. Roberts September 1993 ASCII HTML 25 MIB Management SNMP

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). [STANDARDS-TRACK]

RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC1515
RFC1516 Definitions of Managed Objects for IEEE 802.3 Repeater Devices D. McMaster K. McCloghrie September 1993 ASCII HTML 40 Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 Mb/second baseband repeaters, sometimes referred to as "hubs." [STANDARDS-TRACK]

RFC1368 RFC2108 DRAFT STANDARD DRAFT STANDARD IETF ops hubmib 10.17487/RFC1516
RFC1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) Internet Engineering Steering Group R. Hinden September 1993 ASCII HTML 4 CIDR Address

Classless Inter-Domain Routing (CIDR) defines a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF IESG http://www.rfc-editor.org/errata_search.php?rfc=1517 10.17487/RFC1517
RFC1518 An Architecture for IP Address Allocation with CIDR Y. Rekhter T. Li September 1993 ASCII HTML 27 CIDR-ARCH Classless Routing

This paper provides an architecture and a plan for allocating IP addresses in the Internet. This architecture and the plan are intended to play an important role in steering the Internet towards the Address Assignment and Aggregating Strategy. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1518
RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy V. Fuller T. Li J. Yu K. Varadhan September 1993 ASCII HTML 24 CIDR-STRA]

This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK]

RFC1338 RFC4632 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1519 10.17487/RFC1519
RFC1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment Y. Rekhter C. Topolcic September 1993 ASCII HTML 9 Classless Routing

The purpose of this document is twofold. First, it describes various alternatives for exchanging inter-domain routing information across domain boundaries, where one of the peering domain is CIDR-capable and another is not. Second, it addresses the implications of running CIDR- capable inter-domain routing protocols (e.g., BGP-4, IDRP) on intra- domain routing. This memo provides information for the Internet community. It does not specify an Internet standard.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1520
RFC1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein N. Freed September 1993 ASCII PS PDF HTML 81 email multimedia

This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and STD 11, RFC 1049, but extends and revises that work. [STANDARDS-TRACK]

RFC1341 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext 10.17487/RFC1521
RFC1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text K. Moore September 1993 ASCII HTML 10 email character

This memo describes an extension to the message format defined in RFC 1521, to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521.

RFC1342 RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=1522 10.17487/RFC1522
RFC1523 The text/enriched MIME Content-type N. Borenstein September 1993 ASCII HTML 15 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1563 RFC1896 INFORMATIONAL INFORMATIONAL IETF app 822ext 10.17487/RFC1523
RFC1524 A User Agent Configuration Mechanism For Multimedia Mail Format Information N. Borenstein September 1993 ASCII HTML 12 MIME email mailcap

This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1524 10.17487/RFC1524
RFC1525 Definitions of Managed Objects for Source Routing Bridges E. Decker K. McCloghrie P. Langille A. Rijsinghani September 1993 ASCII HTML 18 SRB-MIB MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing source routing and source routing transparent bridges. These bridges are also required to implement relevant groups in the Bridge MIB. [STANDARDS-TRACK]

RFC1286 HISTORIC PROPOSED STANDARD IETF ops bridge 10.17487/RFC1525
RFC1526 Assignment of System Identifiers for TUBA/CLNP Hosts D. Piscitello September 1993 ASCII HTML 8 NSAP Address

This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF int tuba 10.17487/RFC1526
RFC1527 What Should We Plan Given the Dilemma of the Network? G. Cook September 1993 ASCII HTML 17

The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow for Congress to make? This memo is a shortened version of the suggested policy draft. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1527
RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures C. Malamud M. Rose October 1993 ASCII HTML 12 REM-PRINT FAX Facsimile

This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.

RFC1486 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1528
RFC1529 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Administrative Policies C. Malamud M. Rose October 1993 ASCII HTML 5 FAX Facsimile

This document defines the administrative policies for the operation of remote printer facilities within the context of the tpc.int subdomain. The document describes different approaches to resource recovery for remote printer server sites and includes discussions of issues pertaining to auditing, security, and denial of access. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1486 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1529
RFC1530 Principles of Operation for the TPC.INT Subdomain: General Principles and Policy C. Malamud M. Rose October 1993 ASCII HTML 7 FAX Facsimile

This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1530
RFC1531 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII HTML 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. [STANDARDS-TRACK]

RFC1541 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1531 10.17487/RFC1531
RFC1532 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII HTML 22 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

RFC1542 RFC0951 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC1532
RFC1533 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms October 1993 ASCII HTML 30 Dynamic Host Configuration Bootstrap

This document specifies the current set of DHCP options. [STANDARDS-TRACK]

RFC1497 RFC1395 RFC1084 RFC1048 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1533 10.17487/RFC1533
RFC1534 Interoperation Between DHCP and BOOTP R. Droms October 1993 ASCII HTML 4 DHCP-BOOTP Dynamic Host Configuration Bootstrap

DHCP provides a superset of the functions provided by BOOTP. This document describes the interactions between DHCP and BOOTP network participants. [STANDARDS-TRACK]

DRAFT STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=1534 10.17487/RFC1534
RFC1535 A Security Problem and Proposed Correction With Widely Deployed DNS Software E. Gavron October 1993 ASCII HTML 5 Domain Name System

This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit. This document points out the flaw, a case in point, and a solution. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1535 10.17487/RFC1535
RFC1536 Common DNS Implementation Errors and Suggested Fixes A. Kumar J. Postel C. Neuman P. Danzig S. Miller October 1993 ASCII HTML 12 Domain Name System

This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1536
RFC1537 Common DNS Data File Configuration Errors P. Beertema October 1993 ASCII HTML 9 Domain Name System

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard.

RFC1912 INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1537
RFC1538 Advanced SNA/IP : A Simple SNA Transport Protocol W. Behl B. Sterling W. Teskey October 1993 ASCII HTML 10 ADSNA-IP Domain Name System

This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1538
RFC1539 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force G. Malkin October 1993 ASCII HTML 22 Introduction

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

RFC1391 RFC1718 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1539
RFC1540 Internet Official Protocol Standards J. Postel October 1993 ASCII HTML 34 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]

RFC1500 RFC1600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1540
RFC1541 Dynamic Host Configuration Protocol R. Droms October 1993 ASCII HTML 39 DHCP

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. DHCP is based on the Bootstrap Protocol (BOOTP) adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

RFC1531 RFC2131 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1541
RFC1542 Clarifications and Extensions for the Bootstrap Protocol W. Wimer October 1993 ASCII HTML 23 BOOTP

Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]

RFC1532 RFC0951 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1542 10.17487/RFC1542
RFC1543 Instructions to RFC Authors J. Postel October 1993 ASCII HTML 16 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1111 RFC0825 RFC2223 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1543
RFC1544 The Content-MD5 Header Field M. Rose November 1993 ASCII HTML 3 MIME EMail Integrity MIC Digest

This memo defines the use of an optional header field, Content-MD5, which may be used as a message integrity check (MIC), to verify that the decoded data are the same data that were initially sent. [STANDARDS-TRACK]

RFC1864 PROPOSED STANDARD PROPOSED STANDARD IETF app 822ext 10.17487/RFC1544
RFC1545 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello November 1993 ASCII HTML 5 FTP File Transfer PORT PASV LPRT LPSV

This RFC specifies a method for assigning long addresses in the HOST- PORT specification for the data port to be used in establishing a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). This is a general solution, applicable for all "next generation" IP alternatives, and can also be extended to allow FTP operation over transport interfaces other than TCP. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1639 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1545
RFC1546 Host Anycasting Service C. Partridge T. Mendez W. Milliken November 1993 ASCII HTML 9 Resource Location Multicasting

This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC1546
RFC1547 Requirements for an Internet Standard Point-to-Point Protocol D. Perkins December 1993 ASCII HTML 21 PPP link serial line

This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1547
RFC1548 The Point-to-Point Protocol (PPP) W. Simpson December 1993 ASCII HTML 53 link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

RFC1331 RFC1661 RFC1570 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1548
RFC1549 PPP in HDLC Framing W. Simpson Editor December 1993 ASCII HTML 18 point link serial line

This document describes the use of HDLC for framing PPP encapsulated packets. [STANDARDS-TRACK]

RFC1662 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1549
RFC1550 IP: Next Generation (IPng) White Paper Solicitation S. Bradner A. Mankin December 1993 ASCII HTML 6

This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1550
RFC1551 Novell IPX Over Various WAN Media (IPXWAN) M. Allen December 1993 ASCII HTML 22 Internetworking Packet Exchange

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1634 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1551
RFC1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) W. Simpson December 1993 ASCII HTML 16 IPXCP IPX point serial line link

This document defines the Network Control Protocol for establishing and configuring the IPX protocol over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1552
RFC1553 Compressing IPX Headers Over WAN Media (CIPX) S. Mathur M. Lewis December 1993 ASCII HTML 23 CIPX Internetworking Packet Exchange

This document describes a method for compressing the headers of IPX datagrams (CIPX). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1553
RFC1554 ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP M. Ohta K. Handa December 1993 ASCII HTML 6 Character Set Japanese

This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1554
RFC1555 Hebrew Character Encoding for Internet Messages H. Nussbacher Y. Bourvine December 1993 ASCII HTML 5 Character Set

This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME [RFC1521] and ISO-8859-8. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1555
RFC1556 Handling of Bi-directional Texts in MIME H. Nussbacher December 1993 ASCII HTML 3 Character Set

This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1556
RFC1557 Korean Character Encoding for Internet Messages U. Choi K. Chon H. Park December 1993 ASCII HTML 5 Character Set

This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1557 10.17487/RFC1557
RFC1558 A String Representation of LDAP Search Filters T. Howes December 1993 ASCII HTML 3 X.500 Directory

The Lightweight Directory Access Protocol (LDAP) defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1960 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1558
RFC1559 DECnet Phase IV MIB Extensions J. Saperia December 1993 ASCII HTML 69 DECNET-MIB Management SNMP

This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. It reflects changes which are the result of operational experience based on RFC 1289. [STANDARDS-TRACK]

RFC1289 DRAFT STANDARD DRAFT STANDARD IETF decnetiv 10.17487/RFC1559
RFC1560 The MultiProtocol Internet B. Leiner Y. Rekhter December 1993 ASCII HTML 7 Architecture Protocol

There has recently been considerable discussion on two topics: MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1560
RFC1561 Use of ISO CLNP in TUBA Environments D. Piscitello December 1993 ASCII HTML 25 CLNP-TUBA OSI IP Internet Protocol

This memo specifies a profile of the ISO/IEC 8473 Connectionless-mode Network Layer Protocol for use in conjunction with RFC 1347, TCP/UDP over Bigger Addresses. It describes the use of CLNP to provide the lower-level service expected by Transmission Control Protocol and User Datagram Protocol. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1561
RFC1562 Naming Guidelines for the AARNet X.500 Directory Service G. Michaelson M. Prior December 1993 ASCII HTML 4 Australia

This document is an AARNet (Australian Academic and Research Network) Engineering Note (AEN-001). AARNet Engineering Notes are engineering documents of the AARNet Engineering Working Group, and record current or proposed operational practices related to the provision of Internetworking services within Australia, and AARNet in particular. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1562
RFC1563 The text/enriched MIME Content-type N. Borenstein January 1994 ASCII PS PDF HTML 16 email mail richtext

MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1523 RFC1896 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1563
RFC1564 DSA Metrics (OSI-DS 34 (v3)) P. Barker R. Hedberg January 1994 ASCII HTML 21 x.500 Directory Service Agent

This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app osids 10.17487/RFC1564
RFC1565 Network Services Monitoring MIB S. Kille N. Freed January 1994 ASCII HTML 17 Management Information Base

This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]

RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1565
RFC1566 Mail Monitoring MIB S. Kille N. Freed January 1994 ASCII HTML 20 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]

RFC2249 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1566
RFC1567 X.500 Directory Monitoring MIB G. Mansfield S. Kille January 1994 ASCII HTML 18 X500-MIB Management Information Base

This document defines a portion of the Management Information Base (MIB). It defines the MIB for monitoring Directory System Agents (DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. [STANDARDS-TRACK]

RFC2605 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC1567
RFC1568 Simple Network Paging Protocol - Version 1(b) A. Gwinn January 1994 ASCII HTML 8 Beeper

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1568
RFC1569 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose January 1994 ASCII HTML 6 Beeper

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1703 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1569
RFC1570 PPP LCP Extensions W. Simpson Editor January 1994 ASCII HTML 19 PPP-LCP Point-to Point Link Control Protocol serial line

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. [STANDARDS-TRACK]

RFC1548 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1570
RFC1571 Telnet Environment Option Interoperability Issues D. Borman January 1994 ASCII HTML 4

This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1408 INFORMATIONAL INFORMATIONAL IETF app telnet 10.17487/RFC1571
RFC1572 Telnet Environment Option S. Alexander Editor January 1994 ASCII HTML 7 TOPT-ENVIR

This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app telnet 10.17487/RFC1572
RFC1573 Evolution of the Interfaces Group of MIB-II K. McCloghrie F. Kastenholz January 1994 ASCII HTML 55 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANARDS-TRACK]

RFC1229 RFC2233 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1573
RFC1574 Essential Tools for the OSI Internet S. Hares C. Wittbrodt February 1994 ASCII HTML 13 Echo Traceroute Routing Table CLNP

This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473 (CLNP): ping or OSI Echo function, traceroute function which uses the OSI Echo function, and routing table dump function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1139 INFORMATIONAL INFORMATIONAL IETF noop 10.17487/RFC1574
RFC1575 An Echo Function for CLNP (ISO 8473) S. Hares C. Wittbrodt February 1994 ASCII HTML 9 ISO-TS-ECHO

This memo defines an echo function for the connection-less network layer protocol. The mechanism that is mandated here is in the final process of being standardized by ISO as "Amendment X: Addition of an Echo function to ISO 8473" an integral part of Version 2 of ISO 8473. [STANDARDS-TRACK]

RFC1139 DRAFT STANDARD DRAFT STANDARD IETF noop 10.17487/RFC1575
RFC1576 TN3270 Current Practices J. Penner January 1994 ASCII HTML 12 Telnet Option Terminal Type EOR Binary

This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270. This memo provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1576
RFC1577 Classical IP and ARP over ATM M. Laubach January 1994 ASCII HTML 17 Internet Protocol Address Resolution Asynchronous Transmission Mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1577
RFC1578 FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions J. Sellers February 1994 ASCII HTML 53 K12

The goal of this FYI RFC is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 22]

RFC1941 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1578
RFC1579 Firewall-Friendly FTP S. Bellovin February 1994 ASCII HTML 4 file transfer PORT PASV Security

This memo describes a suggested change to the behavior of FTP client programs. This document provides information for the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1579
RFC1580 Guide to Network Resource Tools EARN Staff March 1994 ASCII HTML 107 EARN BITNET Gopher World-Wide Web WWW WAIS Archie Whois X.500 Netfind Trickle BIFTP Listserv Netnews Astra NetServ Mail Base Prospero IRC Relay

The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23]

FYI0023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1580
RFC1581 Protocol Analysis for Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII HTML 4 routing Protocol

As required by Routing Protocol Criteria, this report documents the key features of Routing over Demand Circuits on Wide Area Networks - RIP and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1581
RFC1582 Extensions to RIP to Support Demand Circuits G. Meyer February 1994 ASCII HTML 29 RIP-DC routing Protocol

This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1582
RFC1583 OSPF Version 2 J. Moy March 1994 ASCII PS PDF HTML 216 equal-cost multipath link state LSA

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

RFC1247 RFC2178 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1583
RFC1584 Multicast Extensions to OSPF J. Moy March 1994 ASCII PS PDF HTML 102 OSPF-Multi Open Shortest Path First

This memo documents enhancements to the OSPF protocol enabling the routing of IP multicast datagrams. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1584
RFC1585 MOSPF: Analysis and Experience J. Moy March 1994 ASCII HTML 13 Multicast Open Shortest Path First OSPF

This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering Task Force internet routing protocol standardization criteria" ([RFC 1264]). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1585
RFC1586 Guidelines for Running OSPF Over Frame Relay Networks O. deSouza M. Rodrigues March 1994 ASCII HTML 6 FR Open Shortest Path First

This memo specifies guidelines for implementors and users of the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC1586
RFC1587 The OSPF NSSA Option R. Coltun V. Fuller March 1994 ASCII HTML 17 OSPF-NSSA Open Shortest Path First not so stubby area routing protocol

This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]

RFC3101 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1587
RFC1588 White Pages Meeting Report J. Postel C. Anderson February 1994 ASCII HTML 35 X-500 directory

This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1588
RFC1589 A Kernel Model for Precision Timekeeping D. Mills March 1994 ASCII HTML 37 Time NTP Clock

This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1589
RFC1590 Media Type Registration Procedure J. Postel March 1994 ASCII HTML 7 email multimedia

Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content-type/subtypes). It also generalizes the scope of use of these Media Types to make it appropriate to use the same registrations and specifications with other applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2045 RFC2046 RFC2047 RFC2048 RFC2049 RFC1521 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1590
RFC1591 Domain Name System Structure and Delegation J. Postel March 1994 ASCII HTML 7 DNS Policy Top-Level TLD

This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1591
RFC1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0 B. Wijnen G. Carpenter K. Curran A. Sehgal G. Waters March 1994 ASCII HTML 54 SNMP-DPI SNMP DPT IBM

This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1228 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1592
RFC1593 SNA APPN Node MIB W. McKenzie J. Cheng March 1994 ASCII HTML 120 IBM Management

This RFC describes IBM's SNMP support for SNA Advanced Peer-to-Peer Networking (APPN) nodes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1593
RFC1594 FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions A. Marine J. Reynolds G. Malkin March 1994 ASCII HTML 44 documentation help information FAQ

This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 4]

RFC1325 RFC2664 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC1594
RFC1595 Definitions of Managed Objects for the SONET/SDH Interface Type T. Brown K. Tesink March 1994 ASCII HTML 59 SONET-MIB MIB Management SNMP RFC2558 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1595 RFC1596 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII HTML 46 FR MIB Management SNMP RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC1596 RFC1597 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. de Groot March 1994 ASCII HTML 8 IP Network Number Local

This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1597
RFC1598 PPP in X.25 W. Simpson March 1994 ASCII HTML 8 PPP-X25 point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of X.25 for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1598
RFC1599 Summary of 1500-1599 M. Kennedy January 1997 ASCII HTML 22 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1599 RFC1600 Internet Official Protocol Standards J. Postel March 1994 ASCII HTML 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1540 RFC1610 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1600
RFC1601 Charter of the Internet Architecture Board (IAB) C. Huitema March 1994 ASCII HTML 6 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1358 RFC2850 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1601
RFC1602 The Internet Standards Process -- Revision 2 Internet Architecture Board Internet Engineering Steering Group March 1994 ASCII HTML 37

This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1310 RFC2026 RFC1871 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1602
RFC1603 IETF Working Group Guidelines and Procedures E. Huizer D. Crocker March 1994 ASCII HTML 29 WG

This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2418 RFC1871 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC1603
RFC1604 Definitions of Managed Objects for Frame Relay Service T. Brown Editor March 1994 ASCII HTML 46 FR-MIB MIB Management SNMP Network

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service. [STANDARDS-TRACK]

RFC1596 RFC2954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1604
RFC1605 SONET to Sonnet Translation W. Shakespeare April 1 1994 ASCII HTML 3 Humor

Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1605
RFC1606 A Historical Perspective On The Usage Of IP Version 9 J. Onions April 1 1994 ASCII HTML 4 Humor

This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1606 10.17487/RFC1606
RFC1607 A VIEW FROM THE 21ST CENTURY V. Cerf April 1 1994 ASCII HTML 14 V. Cerf

This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1607
RFC1608 Representing IP Information in the X.500 Directory T. Johannsen G. Mansfield M. Kosters S. Sataluri March 1994 ASCII HTML 20 X500-DIR Data Structure Schemo

This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app osids 10.17487/RFC1608
RFC1609 Charting Networks in the X.500 Directory G. Mansfield T. Johannsen M. Knopper March 1994 ASCII HTML 15 X500-CHART Data Structure Schemo

This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app osids http://www.rfc-editor.org/errata_search.php?rfc=1609 10.17487/RFC1609
RFC1610 Internet Official Protocol Standards J. Postel July 1994 ASCII HTML 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1600 RFC1720 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1610
RFC1611 DNS Server MIB Extensions R. Austein J. Saperia May 1994 ASCII HTML 30 DNS-S-MIB Domain Name System Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS name server functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1611
RFC1612 DNS Resolver MIB Extensions R. Austein J. Saperia May 1994 ASCII HTML 32 DNS-R-MIB Domain Name System Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of extensions which instrument DNS resolver functions. This memo was produced by the DNS working group. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int dns 10.17487/RFC1612
RFC1613 cisco Systems X.25 over TCP (XOT) J. Forster G. Satz G. Glick R. Day May 1994 ASCII HTML 13 Transmission Control Protocol

This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1613
RFC1614 Network Access to Multimedia Information C. Adie May 1994 ASCII HTML 79 RARE Technical Report

This report summarises the requirements of research and academic network users for network access to multimedia information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv imm 10.17487/RFC1614
RFC1615 Migrating from X.400(84) to X.400(88) J. Houttuin J. Craigie May 1994 ASCII HTML 17 RARE Technical Report email

This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1615
RFC1616 X.400(1988) for the Academic and Research Community in Europe RARE WG-MSG Task Force 88 E. Huizer Editor J. Romaguera Editor May 1994 ASCII HTML 44 RARE Technical Report email

The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1616
RFC1617 Naming and Structuring Guidelines for X.500 Directory Pilots P. Barker S. Kille T. Lenggenhager May 1994 ASCII HTML 28 RARE Technical Report White Pages

This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1384 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1617
RFC1618 PPP over ISDN W. Simpson May 1994 ASCII HTML 7 PPP-ISDN Point Integrated Services Digital Network

This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1618
RFC1619 PPP over SONET/SDH W. Simpson May 1994 ASCII HTML 5 PPP-SONET Point Synchronous Optical Network Digital Heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Heirarchy (SDH) circuits. [STANDARDS-TRACK]

RFC2615 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1619
RFC1620 Internet Architecture Extensions for Shared Media B. Braden J. Postel Y. Rekhter May 1994 ASCII HTML 19 Public data networks ARP address resolution protocol

This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1620
RFC1621 Pip Near-term Architecture P. Francis May 1994 ASCII HTML 51 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Header Processing" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL IETF int pip 10.17487/RFC1621
RFC1622 Pip Header Processing P. Francis May 1994 ASCII HTML 16 Internet Protocol IPng

The purpose of this RFC and the companion RFC "Pip Near-term Architecture" are to record the ideas (good and bad) of Pip. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL IETF int pip 10.17487/RFC1622
RFC1623 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz May 1994 ASCII HTML 19 MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC1398 RFC1643 HISTORIC INTERNET STANDARD IETF int ifmib 10.17487/RFC1623
RFC1624 Computation of the Internet Checksum via Incremental Update A. Rijsinghani Editor May 1994 ASCII HTML 6

This memo describes an updated technique for incremental computation of the standard Internet checksum. It updates the method described in RFC 1141. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1141 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1624 10.17487/RFC1624
RFC1625 WAIS over Z39.50-1988 M. St. Pierre J. Fullton K. Gamiel J. Goldman B. Kahle J. Kunze H. Morris F. Schiettecatte June 1994 ASCII HTML 7 Wide Area Information Servers Library

The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1625
RFC1626 Default IP MTU for use over ATM AAL5 R. Atkinson May 1994 ASCII HTML 5 Maximum Transmission Unit Asynchronous Transfer Mode Adaptation Layer Size Packet

There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]

RFC2225 PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1626
RFC1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified) E. Lear E. Fair D. Crocker T. Kessler July 1994 ASCII HTML 8 IP Network Number Local

This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1918 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1627
RFC1628 UPS Management Information Base J. Case Editor May 1994 ASCII HTML 45 UPS-MIB Uninterruptible Power Supply MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK]

INFORMATIONAL PROPOSED STANDARD IETF ops upsmib http://www.rfc-editor.org/errata_search.php?rfc=1628 10.17487/RFC1628
RFC1629 Guidelines for OSI NSAP Allocation in the Internet R. Colella R. Callon E. Gardner Y. Rekhter May 1994 ASCII HTML 52 OSI-NSAP CLNP Address

This paper provides guidelines for allocating NSAP addresses in the Internet. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and for address administration. [STANDARDS-TRACK]

RFC1237 DRAFT STANDARD DRAFT STANDARD IETF osinsap 10.17487/RFC1629
RFC1630 Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web T. Berners-Lee June 1994 ASCII HTML 28 World Wide Web URI

This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1630
RFC1631 The IP Network Address Translator (NAT) K. Egevang P. Francis May 1994 ASCII HTML 10 Internet Protocol

This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3022 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1631
RFC1632 A Revised Catalog of Available X.500 Implementations A. Getchell Editor S. Sataluri Editor May 1994 ASCII HTML 94 Directory White Pages

This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1292 RFC2116 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1632
RFC1633 Integrated Services in the Internet Architecture: an Overview R. Braden D. Clark S. Shenker June 1994 ASCII PS PDF HTML 33 real time Multi-media reservations Protocol

This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real-time as well as the current non-real-time service of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1633 10.17487/RFC1633
RFC1634 Novell IPX Over Various WAN Media (IPXWAN) M. Allen May 1994 ASCII HTML 23 wide area network

This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1551 RFC1362 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1634
RFC1635 How to Use Anonymous FTP P. Deutsch A. Emtage A. Marine May 1994 ASCII HTML 13 File Transfer Protocol

This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0024 INFORMATIONAL INFORMATIONAL IETF iafa 10.17487/RFC1635
RFC1636 Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994 R. Braden D. Clark S. Crocker C. Huitema June 1994 ASCII HTML 52 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1636
RFC1637 DNS NSAP Resource Records B. Manning R. Colella June 1994 ASCII HTML 11 domain Name System ISO OSI Address

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. This memo defines an Experimental Protocol for the Internet community.

RFC1348 RFC1706 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1637
RFC1638 PPP Bridging Control Protocol (BCP) F. Baker R. Bowen June 1994 ASCII HTML 28 PPP-BCP Point to Point

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

RFC1220 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1638
RFC1639 FTP Operation Over Big Address Records (FOOBAR) D. Piscitello June 1994 ASCII HTML 5 FOOBAR File Transfer Port

This RFC specifies a method for assigning addresses other than 32-bit IPv4 addresses to data ports through the specification of a "long Port (LPRT)" command and "Long Passive (LPSV)" reply, each having as its argument a <long-host-port>, which allows for additional address families, variable length network addresses and variable length port numbers. This memo defines an Experimental Protocol for the Internet community.

RFC1545 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1639
RFC1640 The Process for Organization of Internet Standards Working Group (POISED) S. Crocker June 1994 ASCII HTML 10 IETF IESG IAB ISOC

This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1640
RFC1641 Using Unicode with MIME D. Goldsmith M. Davis July 1994 ASCII PS PDF HTML 6 MIME-UNI Multipurpose Internet Mail Extension Character Set

This document specifies the usage of Unicode within MIME. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1641
RFC1642 UTF-7 - A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis July 1994 ASCII PS PDF HTML 14 character Set

This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. This memo defines an Experimental Protocol for the Internet community.

RFC2152 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1642
RFC1643 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz July 1994 ASCII HTML 19 ETHER-MIB MIB Network Management SNMP Ethernet

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC1623 RFC3638 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1643
RFC1644 T/TCP -- TCP Extensions for Transactions Functional Specification R. Braden July 1994 ASCII HTML 38 T/TCP Transmission Control Protocol

This memo specifies T/TCP, an experimental TCP extension for efficient transaction-oriented (request/response) service. This memo describes an Experimental Protocol for the Internet community.

RFC6247 RFC1379 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1644
RFC1645 Simple Network Paging Protocol - Version 2 A. Gwinn July 1994 ASCII HTML 15 Beeper SNPP Mail

This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1568 RFC1861 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1645
RFC1646 TN3270 Extensions for LUname and Printer Selection C. Graves T. Butts M. Angel July 1994 ASCII HTML 13 Telnet Option

This document describes protocol extensions to TN3270. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC1646
RFC1647 TN3270 Enhancements B. Kelly July 1994 ASCII HTML 34 Telnet Option

This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. [STANDARDS-TRACK]

RFC2355 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC1647
RFC1648 Postmaster Convention for X.400 Operations A. Cargille July 1994 ASCII HTML 4 Mail

This paper extends this concept to X.400 mail domains which have registered RFC 1327 mapping rules, and which therefore appear to have normal RFC822-style addresses. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF app x400ops 10.17487/RFC1648
RFC1649 Operational Requirements for X.400 Management Domains in the GO-MHS Community R. Hagens A. Hansen July 1994 ASCII HTML 14 Mail Global Open Message Handling System

The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app x400ops 10.17487/RFC1649
RFC1650 Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 F. Kastenholz August 1994 ASCII HTML 20 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]

RFC2358 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC1650
RFC1651 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII HTML 11 Mail Simple Transfer

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC1425 RFC1869 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1651
RFC1652 SMTP Service Extension for 8bit-MIMEtransport J. Klensin N. Freed M. Rose E. Stefferud D. Crocker July 1994 ASCII HTML 6 SMTP Mail Simple Transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US- ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

RFC1426 RFC6152 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1652
RFC1653 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore July 1994 ASCII HTML 8 Mail Simple Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC1427 RFC1870 DRAFT STANDARD DRAFT STANDARD IETF app smtpext 10.17487/RFC1653
RFC1654 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor July 1994 ASCII HTML 56 routing

This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1654
RFC1655 Application of the Border Gateway Protocol in the Internet Y. Rekhter Editor P. Gross Editor July 1994 ASCII HTML 19 BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1268 RFC1772 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC1655
RFC1656 BGP-4 Protocol Document Roadmap and Implementation Experience P. Traina July 1994 ASCII HTML 4 Border Gateway Protocol Routing

Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1773 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1656
RFC1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 S. Willis J. Burruss J. Chu Editor July 1994 ASCII HTML 21 BGP-4-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. [STANDARDS-TRACK]

RFC4273 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC1657
RFC1658 Definitions of Managed Objects for Character Stream Devices using SMIv2 B. Stewart July 1994 ASCII HTML 18 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of character stream devices. [STANDARDS-TRACK]

RFC1316 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1658
RFC1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII HTML 21 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]

RFC1317 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1659
RFC1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 B. Stewart July 1994 ASCII HTML 10 MIB Network Management Base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of Parallel-printer- like devices. [STANDARDS-TRACK]

RFC1318 DRAFT STANDARD DRAFT STANDARD IETF charmib 10.17487/RFC1660
RFC1661 The Point-to-Point Protocol (PPP) W. Simpson Editor July 1994 ASCII HTML 53 PPP Specification Standard link serial line

This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]

RFC1548 RFC2153 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1661 10.17487/RFC1661
RFC1662 PPP in HDLC-like Framing W. Simpson Editor July 1994 ASCII HTML 26 PPP-HDLC Point Protocol Specification Standard link serial line

This document describes the use of HDLC-like framing for PPP encapsulated packets. [STANDARDS-TRACK]

RFC1549 STD0051 INTERNET STANDARD INTERNET STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1662 10.17487/RFC1662
RFC1663 PPP Reliable Transmission D. Rand July 1994 ASCII HTML 8 PPP-TRANS Point Protocol

This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1663
RFC1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables C. Allocchio A. Bonito B. Cole S. Giordano R. Hagens August 1994 ASCII HTML 23 domain Name System X.400 Email

This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. This memo defines an Experimental Protocol for the Internet community.

RFC2163 EXPERIMENTAL EXPERIMENTAL IETF app x400ops 10.17487/RFC1664
RFC1665 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski Editor D. Kostick Editor K. Shih Editor July 1994 ASCII HTML 67 MIB Management Information Base System Network Architecture Addressable Units

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

RFC1666 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC1665
RFC1666 Definitions of Managed Objects for SNA NAUs using SMIv2 Z. Kielczewski Editor D. Kostick Editor K. Shih Editor August 1994 ASCII HTML 68 SNANAU-MIB Network Management SNMP MIB Protocol Units Architecture Addressable Information System

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]

RFC1665 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1666
RFC1667 Modeling and Simulation Requirements for IPng S. Symington D. Wood M. Pullen August 1994 ASCII HTML 7 White Paper

This white paper summarizes the Distributed Interactive Simulation environment that is under development, with regard to its real-time nature, scope and magnitude of networking requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1667
RFC1668 Unified Routing Requirements for IPng D. Estrin T. Li Y. Rekhter August 1994 ASCII HTML 3 White Paper

The document provides requirements on the IPng from the perspective of the Unified Routing Architecture, as described in RFC 1322. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1668
RFC1669 Market Viability as a IPng Criteria J. Curran August 1994 ASCII HTML 4 White Paper

"Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1669
RFC1670 Input to IPng Engineering Considerations D. Heagerty August 1994 ASCII HTML 3 White Paper

This white paper expresses some personal opinions on IPng engineering considerations, based on experience with DECnet Phase V transition. It suggests breaking down the IPng decisions and transition tasks into smaller parts so they can be tackled early by the relevant experts. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1670
RFC1671 IPng White Paper on Transition and Other Considerations B. Carpenter August 1994 ASCII HTML 8

This white paper outlines some general requirements for IPng in selected areas. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1671
RFC1672 Accounting Requirements for IPng N. Brownlee August 1994 ASCII HTML 3 White Paper

This white paper discusses accounting requirements for IPng. It recommends that all IPng packets carry accounting tags, which would vary in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1672
RFC1673 Electric Power Research Institute Comments on IPng R. Skelton August 1994 ASCII HTML 4 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1673
RFC1674 A Cellular Industry View of IPng M. Taylor August 1994 ASCII HTML 3 White Paper

This is a draft of the requirements for IPng as envisioned by representatives of the Cellular Digital Packet Data (CDPD) consortium of service providers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1674
RFC1675 Security Concerns for IPng S. Bellovin August 1994 ASCII HTML 4 White Paper

A number of the candidates for IPng have some features that are somewhat worrisome from a security perspective. While it is not necessary that IPng be an improvement over IPv4, it is mandatory that it not make things worse. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1675
RFC1676 INFN Requirements for an IPng A. Ghiselli D. Salomoni C. Vistoli August 1994 ASCII HTML 4 White Paper

With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1676
RFC1677 Tactical Radio Frequency Communication Requirements for IPng B. Adamson August 1994 ASCII HTML 9 White Paper

This paper describes requirements for Internet Protocol next generation (IPng) candidates with respect to their application to military tactical radio frequency (RF) communication networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1677
RFC1678 IPng Requirements of Large Corporate Networks E. Britton J. Tavs August 1994 ASCII HTML 8 White Paper

This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1678
RFC1679 HPN Working Group Input to the IPng Requirements Solicitation D. Green P. Irey D. Marlow K. O'Donoghue August 1994 ASCII HTML 10 White Paper

The purpose of this document is to provide what the HPN working group perceives as requirements for an IPng protocol set. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1679
RFC1680 IPng Support for ATM Services C. Brazdziunas August 1994 ASCII HTML 7 White Paper

This white paper describes engineering considerations for IPng as solicited by RFC 1550 [1]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1680
RFC1681 On Many Addresses per Host S. Bellovin August 1994 ASCII HTML 5 White Paper

This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1681
RFC1682 IPng BSD Host Implementation Analysis J. Bound August 1994 ASCII HTML 10 White Paper Unix

This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1682
RFC1683 Multiprotocol Interoperability In IPng R. Clark M. Ammar K. Calvert August 1994 ASCII HTML 12 White Paper

In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1683
RFC1684 Introduction to White Pages Services based on X.500 P. Jurg August 1994 ASCII HTML 10 Directory

The document provides an introduction to the international ITU-T (formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic White Pages Service. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1684
RFC1685 Writing X.400 O/R Names H. Alvestrand August 1994 ASCII HTML 11 EMail Mail

There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind.

RTR0012 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1685 10.17487/RFC1685
RFC1686 IPng Requirements: A Cable Television Industry Viewpoint M. Vecchi August 1994 ASCII HTML 14 White Paper

This paper provides comments on topics related to the IPng requirements and selection criteria from a cable television industry viewpoint. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1686
RFC1687 A Large Corporate User's View of IPng E. Fleischman August 1994 ASCII HTML 13 White Paper

The goal of this paper is to examine the implications of IPng from the point of view of Fortune 100 corporations which have heavily invested in TCP/IP technology in order to achieve their (non-computer related) business goals.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1687
RFC1688 IPng Mobility Considerations W. Simpson August 1994 ASCII HTML 9 White Paper

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1688
RFC1689 A Status Report on Networked Information Retrieval: Tools and Groups J. Foster Editor August 1994 ASCII HTML 226 NIR

The purpose of this report is to increase the awareness of Networked Information Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0025 INFORMATIONAL INFORMATIONAL IETF nir 10.17487/RFC1689
RFC1690 Introducing the Internet Engineering and Planning Group (IEPG) G. Huston August 1994 ASCII HTML 2 charter

This memo introduces the IEPG to the Internet Community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1690
RFC1691 The Document Architecture for the Cornell Digital Library W. Turner August 1994 ASCII HTML 10

This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1691
RFC1692 Transport Multiplexing Protocol (TMux) P. Cameron D. Crocker D. Cohen J. Postel August 1994 ASCII HTML 12 TMUX Internet Protocol IP

One of the problems with the use of terminal servers is the large number of small packets they can generate. Frequently, most of these packets are destined for only one or two hosts. TMux is a protocol which allows multiple short transport segments, independent of application type, to be combined between a server and host pair.

HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC1692
RFC1693 An Extension to TCP : Partial Order Service T. Connolly P. Amer P. Conrad November 1994 ASCII HTML 36 TCP-POS Transmission Control Protocol

This RFC introduces a new transport mechanism for TCP based upon partial ordering. The aim is to present the concepts of partial ordering and promote discussions on its usefulness in network communications. This memo defines an Experimental Protocol for the Internet community.

RFC6247 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1693
RFC1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2 T. Brown Editor K. Tesink Editor August 1994 ASCII HTML 35 SIP-MIB Standard,MIB,Network,Management,Switched,Multimegabit,Data,Service,Informatiom,Base,SMDS

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing objects for SMDS access interfaces. [STANDARDS-TRACK]

RFC1304 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1694
RFC1695 Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 M. Ahmed Editor K. Tesink Editor August 1994 ASCII HTML 73 ATM-MIB MIB Management,Information,Base,Asychronous,Transmission,Mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

RFC2515 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC1695
RFC1696 Modem Management Information Base (MIB) using SMIv2 J. Barnes L. Brown R. Royston S. Waldbusser August 1994 ASCII HTML 31 MODEM-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing dial-up modems and similar dial-up devices. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF modemmgt 10.17487/RFC1696
RFC1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 D. Brower Editor B. Purvy A. Daniel M. Sinykin J. Smith August 1994 ASCII HTML 38 RDBMS-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing relational database (RDBMS) implementations. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rdbmsmib 10.17487/RFC1697
RFC1698 Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications P. Furniss October 1994 ASCII HTML 29 Protocol Headers

This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF thinosi 10.17487/RFC1698
RFC1699 Summary of 1600-1699 J. Elliott January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1699 RFC1700 Assigned Numbers J. Reynolds J. Postel October 1994 ASCII HTML 230 status procedure index parameters registered allocated

This RFC is a snapshot of the ongoing process of the assignment of protocol parameters for the Internet protocol suite. To make the current information readily available the assignments are kept up-to- date in a set of online text files. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.

RFC1340 RFC3232 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1700
RFC1701 Generic Routing Encapsulation (GRE) S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII HTML 8 GRE Internet Protocol IP

This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1701
RFC1702 Generic Routing Encapsulation over IPv4 networks S. Hanks T. Li D. Farinacci P. Traina October 1994 ASCII HTML 4 GRE-IPv4 Internet Protocol IP

This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1702
RFC1703 Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures M. Rose October 1994 ASCII HTML 9 RADIO-PAGE Beepers

This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1569 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1703
RFC1704 On Internet Authentication N. Haller R. Atkinson October 1994 ASCII HTML 17 Security Energyption Policy Guidelines

This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1704
RFC1705 Six Virtual Inches to the Left: The Problem with IPng R. Carlson D. Ficarella October 1994 ASCII HTML 27 IPng White paper

This document was submitted to the IETF IPng area in response to RFC 1550. This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1705
RFC1706 DNS NSAP Resource Records B. Manning R. Colella October 1994 ASCII HTML 10 DNS-NSAP Domain Name System ISO OSI Address RR Record Resource

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP address format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1637 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1706
RFC1707 CATNIP: Common Architecture for the Internet M. McGovern R. Ullmann October 1994 ASCII HTML 16 IPng White Paper IPv7

This document was submitted to the IETF IPng area in response to RFC 1550. This paper describes a common architecture for the network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1707
RFC1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3 D. Gowin October 1994 ASCII HTML 13

This RFC describes a PICS Proforma translated into an Internet acceptable form. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1708
RFC1709 K-12 Internetworking Guidelines J. Gargano D. Wasley November 1994 ASCII PS PDF HTML 26 school network education connection

The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0026 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1709
RFC1710 Simple Internet Protocol Plus White Paper R. Hinden October 1994 ASCII HTML 23 SIPP IPng

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF sipp 10.17487/RFC1710
RFC1711 Classifications in E-mail Routing J. Houttuin October 1994 ASCII HTML 19 Email Electronic Mail

This paper presents a classification for e-mail routing issues. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1711
RFC1712 DNS Encoding of Geographical Location C. Farrell M. Schulze S. Pleitner D. Baldoni November 1994 ASCII HTML 7 DNS-ENCODE Domain Names System GPOS

This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1712 10.17487/RFC1712
RFC1713 Tools for DNS debugging A. Romao November 1994 ASCII HTML 13 Domain Names System Host DNSWalk DOC DDT Checker

Although widely used (and most of the times unnoticed), DNS (Domain Name System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work. This document presents some tools available for domain administrators to detect and correct those anomalies. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0027 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1713
RFC1714 Referral Whois Protocol (RWhois) S. Williamson M. Kosters November 1994 ASCII PS PDF HTML 46 White Pages Directory

This memo describes version 1.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2167 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1714
RFC1715 The H Ratio for Address Assignment Efficiency C. Huitema November 1994 ASCII HTML 4 IPng White Paper

This document was submitted to the IETF IPng area in response to RFC 1550. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3194 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1715
RFC1716 Towards Requirements for IP Routers P. Almquist F. Kastenholz November 1994 ASCII HTML 192 Gateway Internet Protocol

The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1812 INFORMATIONAL INFORMATIONAL IETF rtg rreq 10.17487/RFC1716
RFC1717 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr November 1994 ASCII HTML 21 Point

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

RFC1990 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1717
RFC1718 The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force IETF Secretariat G. Malkin November 1994 ASCII HTML 23 Internet Engineering Task Force Meeting

The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 17]

RFC1539 RFC3160 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1718
RFC1719 A Direction for IPng P. Gross December 1994 ASCII HTML 6 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1719
RFC1720 Internet Official Protocol Standards J. Postel November 1994 ASCII HTML 41 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1610 RFC1780 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1720
RFC1721 RIP Version 2 Protocol Analysis G. Malkin November 1994 ASCII HTML 4 RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1387 INFORMATIONAL INFORMATIONAL IETF rtg ripv2 10.17487/RFC1721
RFC1722 RIP Version 2 Protocol Applicability Statement G. Malkin November 1994 ASCII HTML 5 RIP2-APP RIP-2

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet. This report is a prerequisite to advancing RIP-2 on the standards track. [STANDARDS-TRACK]

STD0057 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1722
RFC1723 RIP Version 2 - Carrying Additional Information G. Malkin November 1994 ASCII HTML 9 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP), o expand the amount of useful information carried in RIP messages and to add a measure of security. This memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" STD 34, RFC 1058. [STANDARDS-TRACK]

RFC1388 RFC2453 RFC1058 INTERNET STANDARD DRAFT STANDARD IETF rtg ripv2 10.17487/RFC1723
RFC1724 RIP Version 2 MIB Extension G. Malkin F. Baker November 1994 ASCII HTML 18 RIP2-MIB RIP-2 Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing RIP Version 2. [STANDARDS-TRACK]

RFC1389 DRAFT STANDARD DRAFT STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=1724 10.17487/RFC1724
RFC1725 Post Office Protocol - Version 3 J. Myers M. Rose November 1994 ASCII HTML 18 POP Email Electronic Mail

This memo is a revision to RFC 1460, a Draft Standard. [STANDARDS-TRACK]

RFC1460 RFC1939 INTERNET STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1725 10.17487/RFC1725
RFC1726 Technical Criteria for Choosing IP The Next Generation (IPng) C. Partridge F. Kastenholz December 1994 ASCII HTML 31 IPng White Paper Internet Protocol

This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1726
RFC1727 A Vision of an Integrated Internet Information Service C. Weider P. Deutsch December 1994 ASCII HTML 11 Universal Resource Names

This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1727
RFC1728 Resource Transponders C. Weider December 1994 ASCII HTML 6 Universal Resource Names Location System

This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1728
RFC1729 Using the Z39.50 Information Retrieval Protocol C. Lynch December 1994 ASCII HTML 8 Basic Endcoding Rules ASN1

This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF iiir 10.17487/RFC1729
RFC1730 Internet Message Access Protocol - Version 4 M. Crispin December 1994 ASCII HTML 77 IMAP IMAP4 EMail

The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server. [STANDARDS-TRACK]

RFC2060 RFC2061 PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1730
RFC1731 IMAP4 Authentication Mechanisms J. Myers December 1994 ASCII HTML 6 IMAP4-AUTH Internet Message Access Protocol Email

The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app imap 10.17487/RFC1731
RFC1732 IMAP4 Compatibility with IMAP2 and IMAP2bis M. Crispin December 1994 ASCII HTML 5 Internet Message Access Protocol Email

This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1732
RFC1733 Distributed Electronic Mail Models in IMAP4 M. Crispin December 1994 ASCII HTML 3 Internet Message Access Protocol Email

There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app imap 10.17487/RFC1733
RFC1734 POP3 AUTHentication command J. Myers December 1994 ASCII HTML 5 POP3-AUTH Post Office Protocol Email

This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]

RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1734
RFC1735 NBMA Address Resolution Protocol (NARP) J. Heinanen R. Govindan December 1994 ASCII HTML 11 NARP Non-Broadcast Multi Access Address Resolution Protocol

This document describes the NBMA Address Resolution Protocol (NARP). NARP can be used by a source terminal (host or router) connected to a Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF rtg rolc 10.17487/RFC1735
RFC1736 Functional Recommendations for Internet Resource Locators J. Kunze February 1995 ASCII HTML 10 Uniform Resource URL

This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1736
RFC1737 Functional Requirements for Uniform Resource Names K. Sollins L. Masinter December 1994 ASCII HTML 7

This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1737
RFC1738 Uniform Resource Locators (URL) T. Berners-Lee L. Masinter M. McCahill December 1994 ASCII HTML 25 URL

This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet. [STANDARDS-TRACK]

RFC4248 RFC4266 RFC1808 RFC2368 RFC2396 RFC3986 RFC6196 RFC6270 RFC8089 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1738 10.17487/RFC1738
RFC1739 A Primer On Internet and TCP/IP Tools G. Kessler S. Shepard December 1994 ASCII HTML 46 NSlookup PING FINGER TRACEROUTE FTP TELNET WHOIS NICNAME KNOWBOT NETFIND ARCHIE Gopher Email Mailing Lists USENET

This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2151 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1739
RFC1740 MIME Encapsulation of Macintosh Files - MacMIME P. Faltstrom D. Crocker E. Fair December 1994 ASCII HTML 16 MacMIME Multipurpose Internet Mail Extensions

This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1740
RFC1741 MIME Content Type for BinHex Encoded Files P. Faltstrom D. Crocker E. Fair December 1994 ASCII HTML 6 BINHEX Multipurpose Internet Mail Extensions

This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1741
RFC1742 AppleTalk Management Information Base II S. Waldbusser K. Frisa January 1995 ASCII HTML 84 AT-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing AppleTalk networks. [STANDARDS-TRACK]

RFC1243 HISTORIC PROPOSED STANDARD IETF int appleip 10.17487/RFC1742
RFC1743 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII HTML 25 Management Information Base SNMP,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

RFC1231 RFC1748 DRAFT STANDARD DRAFT STANDARD IETF int ifmib 10.17487/RFC1743
RFC1744 Observations on the Management of the Internet Address Space G. Huston December 1994 ASCII HTML 12 IP Internet Protocol

This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1744
RFC1745 BGP4/IDRP for IP---OSPF Interaction K. Varadhan S. Hares Y. Rekhter December 1994 ASCII HTML 19 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

This memo defines the various criteria to be used when designing an Autonomous System Border Router (ASBR) that will run either BGP4 or IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg idr 10.17487/RFC1745
RFC1746 Ways to Define User Expectations B. Manning D. Perkins December 1994 ASCII HTML 18

This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1746
RFC1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2 J. Hilgeman S. Nix A. Bartky W. Clark Editor January 1995 ASCII HTML 67 SDLCSMIv2

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for managing the configuration, monitoring and control of data link controls in an SNA environment. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rtg snadlc 10.17487/RFC1747
RFC1748 IEEE 802.5 MIB using SMIv2 K. McCloghrie E. Decker December 1994 ASCII HTML 25 802.5-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]

RFC1743 RFC1231 RFC1749 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1748
RFC1749 IEEE 802.5 Station Source Routing MIB using SMIv2 K. McCloghrie F. Baker E. Decker December 1994 ASCII HTML 10 802.5-SSR Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used by IEEE 802.5 end-stations for managing source routes on a Token Ring network where IEEE source- routing is in use. [STANDARDS-TRACK]

RFC1748 HISTORIC PROPOSED STANDARD IETF int ifmib 10.17487/RFC1749
RFC1750 Randomness Recommendations for Security D. Eastlake 3rd S. Crocker J. Schiller December 1994 ASCII HTML 30 Random Numbers Seed

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC4086 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1750
RFC1751 A Convention for Human-Readable 128-bit Keys D. McDonald December 1994 ASCII HTML 15 Security Password

This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1751 10.17487/RFC1751
RFC1752 The Recommendation for the IP Next Generation Protocol S. Bradner A. Mankin January 1995 ASCII HTML 52 IPNG IPng Internet

This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1752
RFC1753 IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture N. Chiappa December 1994 ASCII HTML 18 IPng White Paper Internet Protocol

This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1753
RFC1754 IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1 M. Laubach January 1995 ASCII HTML 7 Internet Asynchromous Transfer Mode

This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1754
RFC1755 ATM Signaling Support for IP over ATM M. Perez F. Liaw A. Mankin E. Hoffman D. Grossman A. Malis February 1995 ASCII HTML 32 ATM Asynchronous Transfer Mode

This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC1755
RFC1756 Remote Write Protocol - Version 1.0 T. Rinne January 1995 ASCII HTML 11 RWP Application

This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1756
RFC1757 Remote Network Monitoring Management Information Base S. Waldbusser February 1995 ASCII HTML 91 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

RFC1271 RFC2819 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib 10.17487/RFC1757
RFC1758 NADF Standing Documents: A Brief Overview The North American Directory Forum February 1995 ASCII HTML 4 X.500 North American Directory Forum Public CCITT Providers

The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1417 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1758
RFC1759 Printer MIB R. Smith F. Wright T. Hastings S. Zilles J. Gyllenskog March 1995 ASCII HTML 113 Print-MIB Management Information Base

A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]

RFC3805 PROPOSED STANDARD PROPOSED STANDARD IETF app printmib 10.17487/RFC1759
RFC1760 The S/KEY One-Time Password System N. Haller February 1995 ASCII HTML 12 Security

This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1760 10.17487/RFC1760
RFC1761 Snoop Version 2 Packet Capture File Format B. Callaghan R. Gilligan February 1995 ASCII HTML 6 SNOOP Measurement debugging collecting data

This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1761
RFC1762 The PPP DECnet Phase IV Control Protocol (DNCP) S. Senum March 1995 ASCII HTML 7 PPP-DNCP Point Digital Equipment Corporation

This document defines the NCP for establishing and configuring Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP. This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc). [STANDARDS-TRACK]

RFC1376 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1762
RFC1763 The PPP Banyan Vines Control Protocol (BVCP) S. Senum March 1995 ASCII HTML 10 BVCP Point

This document defines the Network Control Protocol for establishing and configuring the Banyan VINES protocol over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1763
RFC1764 The PPP XNS IDP Control Protocol (XNSCP) S. Senum March 1995 ASCII HTML 5 XNSCP Point Xerox Network Internetwork Datagram Service

This document defines the Network Control Protocol for establishing and configuring the Xerox Network Systems (XNS) Internet Datagram Protocol (IDP) over PPP. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF int pppext 10.17487/RFC1764
RFC1765 OSPF Database Overflow J. Moy March 1995 ASCII HTML 9 OSPF-OVFL

This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC1765
RFC1766 Tags for the Identification of Languages H. Alvestrand March 1995 ASCII HTML 9 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. [STANDARDS-TRACK]

RFC3066 RFC3282 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1766
RFC1767 MIME Encapsulation of EDI Objects D. Crocker March 1995 ASCII HTML 7 MIME-EDI Electronic Data Interchange Multipurpose Internet Mail Extensions delivery mechanism encapsulation

Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app edi 10.17487/RFC1767
RFC1768 Host Group Extensions for CLNP Multicasting D. Marlow March 1995 ASCII HTML 45 CLNP-MULT ISO OSI

This memo provides a specification for multicast extensions to the CLNP protocol similar to those provided to IP by RFC1112. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL IETF int tuba 10.17487/RFC1768
RFC1769 Simple Network Time Protocol (SNTP) D. Mills March 1995 ASCII HTML 14 Clocks Synchronization NTP

This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1361 RFC2030 RFC4330 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1769
RFC1770 IPv4 Option for Sender Directed Multi-Destination Delivery C. Graff March 1995 ASCII HTML 6 SDMD

This memo defines an IPv4 option to provide a sender directed multi- destination delivery mechanism called Selective Directed Broadcast Mode (SDBM). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC6814 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1770
RFC1771 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter T. Li March 1995 ASCII HTML 57 BGP-4 routing

This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]

RFC1654 RFC4271 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1771 10.17487/RFC1771
RFC1772 Application of the Border Gateway Protocol in the Internet Y. Rekhter P. Gross March 1995 ASCII HTML 19 BGP-4-APP BGP-4 Routing

This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK]

RFC1655 DRAFT STANDARD DRAFT STANDARD IETF rtg bgp 10.17487/RFC1772
RFC1773 Experience with the BGP-4 protocol P. Traina March 1995 ASCII HTML 9 BGP-4 Border Gateway Protocol Routing

The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1656 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1773
RFC1774 BGP-4 Protocol Analysis P. Traina Editor March 1995 ASCII HTML 10 Border Gateway Routing

The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1774 10.17487/RFC1774
RFC1775 To Be "On" the Internet D. Crocker March 1995 ASCII HTML 4 access full Client Mediated Messaging

The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1775
RFC1776 The Address is the Message S. Crocker April 1 1995 ASCII HTML 2 IPng

Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1776
RFC1777 Lightweight Directory Access Protocol W. Yeong T. Howes S. Kille March 1995 ASCII HTML 22 X.500 DAP interactive access

The protocol described in this document is designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP).This protocol is specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself. [STANDARDS-TRACK]

RFC1487 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1777
RFC1778 The String Representation of Standard Attribute Syntaxes T. Howes S. Kille W. Yeong C. Robbins March 1995 ASCII HTML 12 X.500 LDAP lightweight directory protocol

The Lightweight Directory Access Protocol (LDAP) requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes. [STANDARDS-TRACK]

RFC1488 RFC3494 RFC2559 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1778
RFC1779 A String Representation of Distinguished Names S. Kille March 1995 ASCII HTML 8 STR-REP X.500 directory names representing names

The OSI Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1. When a distinguished name is communicated between to users not using a directory protocol (e.g., in a mail message), there is a need to have a user-oriented string representation of distinguished name. This specification defines a string format for representing names, which is designed to give a clean representation of commonly used names, whilst being able to represent any distinguished name. [STANDARDS-TRACK]

RFC1485 RFC2253 RFC3494 HISTORIC DRAFT STANDARD IETF app asid 10.17487/RFC1779
RFC1780 Internet Official Protocol Standards J. Postel Editor March 1995 ASCII HTML 39 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1720 RFC1800 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1780
RFC1781 Using the OSI Directory to Achieve User Friendly Naming S. Kille March 1995 ASCII HTML 26 OSI-Dir X.500 directory names representing names

This proposal sets out some conventions for representing names in a friendly manner, and shows how this can be used to achieve really friendly naming. [STANDARDS-TRACK]

RFC1484 RFC3494 HISTORIC PROPOSED STANDARD IETF app asid 10.17487/RFC1781
RFC1782 TFTP Option Extension G. Malkin A. Harkin March 1995 ASCII HTML 6 trivial file transfer booting

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer.

RFC2347 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1782
RFC1783 TFTP Blocksize Option G. Malkin A. Harkin March 1995 ASCII HTML 5 trivial file transfer booting

This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

RFC2348 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1783
RFC1784 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin March 1995 ASCII HTML 4 trivial file transfer booting

This document describes two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. [STANDARDS-TRACK]

RFC2349 RFC1350 PROPOSED STANDARD PROPOSED STANDARD IETF app tftpexts 10.17487/RFC1784
RFC1785 TFTP Option Negotiation Analysis G. Malkin A. Harkin March 1995 ASCII HTML 2 trivial file transfer booting

This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1350 INFORMATIONAL INFORMATIONAL IETF app tftpexts 10.17487/RFC1785
RFC1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++) T. Bates E. Gerich L. Joncheray J-M. Jouanigot D. Karrenberg M. Terpstra J. Yu March 1995 ASCII HTML 83

This document is an update to the original `ripe-81' proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc. and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1786
RFC1787 Routing in a Multi-provider Internet Y. Rekhter April 1995 ASCII HTML 8 Internet Protocol Architechure Board IAB

This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1787
RFC1788 ICMP Domain Name Messages W. Simpson April 1995 ASCII HTML 7 ICMP-DM Internet Control Message Protocol DNS Service

This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

RFC6918 HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1788
RFC1789 INETPhone: Telephone Services and Servers on Internet C. Yang April 1995 ASCII HTML 6

This RFC presents a true telephone service, called INETPhone, which supports voice communication through the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1789
RFC1790 An Agreement between the Internet Society and Sun Microsystems, Inc. in the Matter of ONC RPC and XDR Protocols V. Cerf April 1995 ASCII HTML 4 ISOC

This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1790
RFC1791 TCP And UDP Over IPX Networks With Fixed Path MTU T. Sung April 1995 ASCII HTML 12 Transmission Control Protocol User Datagram Maxium Unit

TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1791
RFC1792 TCP/IPX Connection Mib Specification T. Sung April 1995 ASCII HTML 9 TCP/IPXMIB Transmission Control Protocol Management Information Base

New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1792
RFC1793 Extending OSPF to Support Demand Circuits J. Moy April 1995 ASCII HTML 32 OSPF-DC Open Shortest Path First

This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". [STANDARDS-TRACK]

RFC3883 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC1793
RFC1794 DNS Support for Load Balancing T. Brisco April 1995 ASCII HTML 7 Domain Name System

This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int dns 10.17487/RFC1794
RFC1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1 L. Wells A. Bartky Editor April 1995 ASCII HTML 91 IBM SNA DLS SSP NetBIos APPN

This RFC describes use of Data Link Switching over TCP/IP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1434 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1795
RFC1796 Not All RFCs are Standards C. Huitema J. Postel S. Crocker April 1995 ASCII HTML 4

This document discusses the relationship of the Request for Comments (RFCs) notes to Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1796
RFC1797 Class A Subnet Experiment Internet Assigned Numbers Authority (IANA) April 1995 ASCII HTML 4 Network Address 39 Number

There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1797
RFC1798 Connection-less Lightweight X.500 Directory Access Protocol A. Young June 1995 ASCII HTML 9 CLDAP CLDAP Presentation Address Application Entity Title

The protocol described in this document is designed to provide access to the Directory while not incurring the resource requirements of the Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC3352 HISTORIC PROPOSED STANDARD IETF app osids 10.17487/RFC1798
RFC1799 Request for Comments Summary RFC Numbers 1700-1799 M. Kennedy January 1997 ASCII HTML 21 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1799 RFC1800 Internet Official Protocol Standards J. Postel Editor July 1995 ASCII HTML 36 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1780 RFC1880 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1800
RFC1801 MHS use of the X.500 Directory to support MHS Routing S. Kille June 1995 ASCII HTML 73 Routing Mail EMail Message Handling System X.400

The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1801
RFC1802 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing H. Alvestrand K. Jordan S. Langlois J. Romaguera June 1995 ASCII HTML 11 Mail EMail Message Handling System MHS

This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app mhsds 10.17487/RFC1802
RFC1803 Recommendations for an X.500 Production Directory Service R. Wright A. Getchell T. Howes S. Sataluri P. Yee W. Yeong June 1995 ASCII HTML 8 White Pages DSA Directory User Agent

This document contains a set of basic recommendations for a country- level X.500 DSA. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1803
RFC1804 Schema Publishing in X.500 Directory G. Mansfield P. Rajeev S. Raghavan T. Howes June 1995 ASCII HTML 10

In this document we propose a solution using the existing mechanisms of the directory [1] itself. We present a naming scheme for naming schema objects and a meta-schema for storing schema objects in the directory. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app asid 10.17487/RFC1804
RFC1805 Location-Independent Data/Software Integrity Protocol A. Rubin June 1995 ASCII HTML 6 Betsi Security Cryptography

This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1805
RFC1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header R. Troost S. Dorner June 1995 ASCII HTML 8 MIME EMail Mail

This memo provides a mechanism whereby messages conforming to the [RFC 1521] ("MIME") specification can convey presentational information. This memo defines an Experimental Protocol for the Internet community.

RFC2183 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1806
RFC1807 A Format for Bibliographic Records R. Lasher D. Cohen June 1995 ASCII HTML 15 library technical reports email services

This RFC defines a format for bibliographic records describing technical reports. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1357 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1807
RFC1808 Relative Uniform Resource Locators R. Fielding June 1995 ASCII HTML 16 URL URL syntax semantics

In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative Uniform Resource Locators. [STANDARDS-TRACK]

RFC3986 RFC1738 RFC2368 RFC2396 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC1808
RFC1809 Using the Flow Label Field in IPv6 C. Partridge June 1995 ASCII HTML 6

The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1809
RFC1810 Report on MD5 Performance J. Touch June 1995 ASCII HTML 7 IPv6 Message Digest Algorithm Authentication

This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1810 10.17487/RFC1810
RFC1811 U.S. Government Internet Domain Names Federal Networking Council June 1995 ASCII HTML 3 GOV FNC IANA

This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1811
RFC1812 Requirements for IP Version 4 Routers F. Baker Editor June 1995 ASCII HTML 175 routing IPv4

This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]

RFC1716 RFC1009 RFC2644 RFC6633 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rreq http://www.rfc-editor.org/errata_search.php?rfc=1812 10.17487/RFC1812
RFC1813 NFS Version 3 Protocol Specification B. Callaghan B. Pawlowski P. Staubach June 1995 ASCII HTML 126 NFSV3

This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1094 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1813
RFC1814 Unique Addresses are Good E. Gerich June 1995 ASCII HTML 3 Internet Registries Protocol Private Network Numbers

The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1814
RFC1815 Character Sets ISO-10646 and ISO-10646-J-1 M. Ohta July 1995 ASCII HTML 6 Japanese Latin

For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary. This memo provides information on such profiling, along with charset names to each profiled instance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1815
RFC1816 U.S. Government Internet Domain Names Federal Networking Council August 1995 ASCII HTML 8 GOV FNC IANA

This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain ".GOV". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1811 RFC2146 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1816
RFC1817 CIDR and Classful Routing Y. Rekhter August 1995 ASCII HTML 2 Classless Inter Domain Routing

This document represents the IAB's (Internet Architecture Board) evaluation of the current and near term implications of CIDR on organizations that use Classful routing technology. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC1817
RFC1818 Best Current Practices J. Postel T. Li Y. Rekhter August 1995 ASCII HTML 3 BCP

This document describes a new series of documents which describe best current practices for the Internet community. Documents in this series carry the endorsement of the Internet Engineering Steering Group (IESG).

HISTORIC BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1818 10.17487/RFC1818
RFC1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ L. Delgrossi Editor L. Berger Editor August 1995 ASCII HTML 109 ST2

This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). This memo defines an Experimental Protocol for the Internet community.

RFC1190 IEN119 HISTORIC EXPERIMENTAL IETF int st2 10.17487/RFC1819
RFC1820 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII HTML 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1844 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1820
RFC1821 Integration of Real-time Services in an IP-ATM Network Architecture M. Borden E. Crawley B. Davie S. Batsell August 1995 ASCII HTML 24 Asynchronous Transfer Mode

The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1821
RFC1822 A Grant of Rights to Use a Specific IBM patent with Photuris J. Lowe August 1995 ASCII HTML 2 Internet Key Management Protocol IKMP IETF

This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1822
RFC1823 The LDAP Application Program Interface T. Howes M. Smith August 1995 ASCII HTML 22 lightweight directory access protocol API X.500

This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1823
RFC1824 The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4) H. Danisch August 1995 ASCII HTML 21 TESS public keys

This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1824
RFC1825 Security Architecture for the Internet Protocol R. Atkinson August 1995 ASCII HTML 22 IPv4 IPv6 IP-layer ipsec

This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS-TRACK]

RFC2401 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1825
RFC1826 IP Authentication Header R. Atkinson August 1995 ASCII HTML 13 ipsec IPV6-AH Internet Protocol AH security IPv4 IPv6

This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]

RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1826
RFC1827 IP Encapsulating Security Payload (ESP) R. Atkinson August 1995 ASCII HTML 12 ESP Internet Protocol IPv4 IPv6 ipsec

This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]

RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1827
RFC1828 IP Authentication using Keyed MD5 P. Metzger W. Simpson August 1995 ASCII HTML 6 ipsec Internet Protocol Authentication Header AH Message Digest 5 Security

This document describes the use of keyed MD5 with the IP Authentication Header. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1828
RFC1829 The ESP DES-CBC Transform P. Karn P. Metzger W. Simpson August 1995 ASCII HTML 11 Encapsulating Security Payload US Data Encryption Standard Cipher Block Chaining IP Internet Protocol Security ipsec

This document describes the DES-CBC security transform for the IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC1829
RFC1830 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil August 1995 ASCII HTML 8 Simple Mail Transfer Multipurpose Mail Extensions

This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.

RFC3030 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1830
RFC1831 RPC: Remote Procedure Call Protocol Specification Version 2 R. Srinivasan August 1995 ASCII HTML 18 RPC] ONC Open Network Computing

This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

RFC5531 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1831
RFC1832 XDR: External Data Representation Standard R. Srinivasan August 1995 ASCII HTML 24 XDR RPC ONC Open Network Computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

RFC4506 DRAFT STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1832
RFC1833 Binding Protocols for ONC RPC Version 2 R. Srinivasan August 1995 ASCII HTML 14 ONC Open Network Computing

This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]

RFC5665 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc 10.17487/RFC1833
RFC1834 Whois and Network Information Lookup Service, Whois++ J. Gargano K. Weiss August 1995 ASCII HTML 7 nicname TCP Transmission Control Protocol directory service server retrieval

This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF wnils 10.17487/RFC1834
RFC1835 Architecture of the WHOIS++ service P. Deutsch R. Schoultz P. Faltstrom C. Weider August 1995 ASCII HTML 41 WHOIS++ nicname TCP Transmission Control Protocol directory service server retrieval

This document describes WHOIS++, an extension to the trivial WHOIS service described in RFC 954 to permit WHOIS-like servers to make available more structured information to the Internet. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1835
RFC1836 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille August 1995 ASCII HTML 11 message handling

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This memo defines an Experimental Protocol for the Internet community.

RFC2294 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1836
RFC1837 Representing Tables and Subtrees in the X.500 Directory S. Kille August 1995 ASCII HTML 7 message handling

This document defines techniques for representing two types of information mapping in the OSI Directory. This memo defines an Experimental Protocol for the Internet community.

RFC2293 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1837
RFC1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses S. Kille August 1995 ASCII HTML 8 message handling

This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. This memo defines an Experimental Protocol for the Internet community.

RFC2164 EXPERIMENTAL EXPERIMENTAL IETF app mhsds 10.17487/RFC1838
RFC1839 RFC1840 RFC1841 PPP Network Control Protocol for LAN Extension J. Chapman D. Coli A. Harvey B. Jensen K. Rowett September 1995 ASCII HTML 66 point-to-point local area interface, INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1841 RFC1842 ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages Y. Wei Y. Zhang J. Li J. Ding Y. Jiang August 1995 ASCII HTML 12 electronic mail HZ-GB-2312

This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informational RFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1842
RFC1843 HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters F. Lee August 1995 ASCII HTML 5 GB2312-80 electronic mail

The content of this memo is identical to an article of the same title written by the author on September 4, 1989. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1843
RFC1844 Multimedia E-mail (MIME) User Agent Checklist E. Huizer August 1995 ASCII HTML 8 Multipurpose Internet Mail Extensions Media Types

This document presents a checklist to facilitate evaluation of MIME capable User Agents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1820 INFORMATIONAL INFORMATIONAL IETF app mailext 10.17487/RFC1844
RFC1845 SMTP Service Extension for Checkpoint/Restart D. Crocker N. Freed A. Cargille September 1995 ASCII HTML 7 simple mail transfer transaction EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1845 RFC1846 SMTP 521 Reply Code A. Durand F. Dupont September 1995 ASCII HTML 4 simple mail transfer RFC7504 EXPERIMENTAL EXPERIMENTAL IETF app mailext 10.17487/RFC1846 RFC1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted J. Galvin S. Murphy S. Crocker N. Freed October 1995 ASCII HTML 11 MIME-Encyp mail multipurpose extensions

This document defines a framework within which security services may be applied to MIME body parts. [STANDARDS-TRACK] This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. This memo defines an Experimental Protocol for the Internet community. This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. This memo defines an Experimental Protocol for the Internet community.

PROPOSED STANDARD PROPOSED STANDARD IETF sec pem 10.17487/RFC1847
RFC1848 MIME Object Security Services S. Crocker N. Freed J. Galvin S. Murphy October 1995 ASCII HTML 48 MIME-Sec mail multipurpose extensions

This document defines MIME Object Security Services (MOSS), a protocol that uses the multipart/signed and multipart/encrypted framework [7] to apply digital signature and encryption services to MIME objects. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF sec pem 10.17487/RFC1848
RFC1849 "Son of 1036": News Article Format and Transmission H. Spencer March 2010 ASCII HTML 106 netnews usenet rfc 1036 usefor historic

By the early 1990s, it had become clear that RFC 1036, then the specification for the Interchange of USENET Messages, was badly in need of repair. This "Internet-Draft-to-be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews.

It is being published now in order to provide the historical background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations. This document defines a Historic Document for the Internet community.

draft-spencer-usefor-son-of-1036-01 RFC5536 RFC5537 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC1849
RFC1850 OSPF Version 2 Management Information Base F. Baker R. Coltun November 1995 ASCII HTML 80 OSPF-MIB Open Shortest Path First SPF MIB routing network management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]

RFC1253 RFC4750 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC1850
RFC1851 The ESP Triple DES Transform P. Karn P. Metzger W. Simpson September 1995 ASCII HTML 11 ESP3DES encryption encapsulating security payload cipher block chaining EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1851 RFC1852 IP Authentication using Keyed SHA P. Metzger W. Simpson September 1995 ASCII HTML 6 encryption secure hash algorithm RFC2841 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1852 RFC1853 IP in IP Tunneling W. Simpson October 1995 ASCII HTML 8 internet protocol payload encapsulation

This document discusses implementation techniques for using IP Protocol/Payload number 4 Encapsulation for tunneling with IP Security and other protocols. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes the use of keyed SHA with the IP Authentication Header. This document defines an Experimental Protocol for the Internet community. This document describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). This document defines an Experimental Protocol for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1853
RFC1854 SMTP Service Extension for Command Pipelining N. Freed October 1995 ASCII HTML 7 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

RFC2197 PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC1854
RFC1855 Netiquette Guidelines S. Hambridge October 1995 ASCII HTML 21 Network Etiquette

This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0028 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC1855
RFC1856 The Opstat Client-Server Model for Statistics Retrieval H. Clark September 1995 ASCII HTML 17 tools performance utilization INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1856 RFC1857 A Model for Common Operational Statistics M. Lambert October 1995 ASCII HTML 27 metrics measurements polling periods

This memo describes a model for operational statistics in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document defines a model and protocol for a set of tools which could be used by NSPs and Network Operation Centers (NOCs) to share data among themselves and with customers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1404 INFORMATIONAL INFORMATIONAL IETF opstat 10.17487/RFC1857
RFC1858 Security Considerations for IP Fragment Filtering G. Ziemba D. Reed P. Traina October 1995 ASCII HTML 10 internet protocol tcp transmission control protocol routers hosts

IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3128 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1858
RFC1859 ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension Y. Pouffary October 1995 ASCII HTML 8 International Standard Organizatio

This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1859
RFC1860 Variable Length Subnet Table For IPv4 T. Pummill B. Manning October 1995 ASCII HTML 3 values IPv4 subnets

This document itemizes the potential values for IPv4 subnets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1878 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1860
RFC1861 Simple Network Paging Protocol - Version 3 -Two-Way Enhanced A. Gwinn October 1995 ASCII HTML 23 SNPP SNPP wireless paging

This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1645 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1861
RFC1862 Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 M. McCahill J. Romkey M. Schwartz K. Sollins T. Verschuren C. Weider November 1995 ASCII HTML 27 Internet Architecture Board

This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1862
RFC1863 A BGP/IDRP Route Server alternative to a full mesh routing D. Haskin October 1995 ASCII HTML 16 BGP-IDRP border gateway protocol inter-domain routing

This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers. This memo defines an Experimental Protocol for the Internet community.

RFC4223 HISTORIC EXPERIMENTAL IETF rtg idr 10.17487/RFC1863
RFC1864 The Content-MD5 Header Field J. Myers M. Rose October 1995 ASCII HTML 4 CON-MD5 MIME EMail Integrity MIC Digest

This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages. [STANDARDS-TRACK]

RFC1544 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC1864
RFC1865 EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet W. Houser J. Griffin C. Hage January 1996 ASCII HTML 41 FAQ

This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app edi 10.17487/RFC1865
RFC1866 Hypertext Markup Language - 2.0 T. Berners-Lee D. Connolly November 1995 ASCII HTML 77 HTML HTML SGML Standard Generalized Language WWW World Wide Web

This document defines a HTML 2.0 (to distinguish it from the previous informal specifications). [STANDARDS-TRACK]

RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC1866
RFC1867 Form-based File Upload in HTML E. Nebel L. Masinter November 1995 ASCII HTML 13 Hypertext Markup Language MIME Multipurpose Internet Mail Extensions

Since file-upload is a feature that will benefit many applications, this proposes an extension to HTML to allow information providers to express file upload requests uniformly, and a MIME compatible representation for file upload responses. This memo defines an Experimental Protocol for the Internet community.

RFC2854 HISTORIC EXPERIMENTAL IETF app html http://www.rfc-editor.org/errata_search.php?rfc=1867 10.17487/RFC1867
RFC1868 ARP Extension - UNARP G. Malkin November 1995 ASCII HTML 4 UNARP Address Resolution Protocol delete entry

This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1868
RFC1869 SMTP Service Extensions J. Klensin N. Freed M. Rose E. Stefferud D. Crocker November 1995 ASCII HTML 11 ESMTP Simple Mail Transfer Protocol

This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]

RFC1651 RFC2821 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1869
RFC1870 SMTP Service Extension for Message Size Declaration J. Klensin N. Freed K. Moore November 1995 ASCII HTML 9 SMTP-SIZE Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]

RFC1653 STD0010 INTERNET STANDARD INTERNET STANDARD IETF app smtpext 10.17487/RFC1870
RFC1871 Addendum to RFC 1602 -- Variance Procedure J. Postel November 1995 ASCII HTML 4 BCP WG escape clause procedures

This document describes a modification to the IETF procedures to allow an escape from a situation where the existing procedures are not working or do not seem to apply. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2026 RFC1602 RFC1603 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC1871
RFC1872 The MIME Multipart/Related Content-type E. Levinson December 1995 ASCII HTML 8 multipurpose Internet Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. This memo defines an Experimental Protocol for the Internet community.

RFC2112 EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1872
RFC1873 Message/External-Body Content-ID Access Type E. Levinson December 1995 ASCII HTML 4 CONT-MT Multipurpose Internet Mail Extensions

The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1873
RFC1874 SGML Media Types E. Levinson December 1995 ASCII HTML 6 SGML-MT Multipurpose Internet Mail Extensions

This document proposes new media sub-types of Text/SGML and Application/SGML. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mimesgml 10.17487/RFC1874
RFC1875 UNINETT PCA Policy Statements N. Berge December 1995 ASCII HTML 10 Policy Certification Authority Encryption

This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1875
RFC1876 A Means for Expressing Location Information in the Domain Name System C. Davis P. Vixie T. Goodwin I. Dickinson January 1996 ASCII HTML 18 DNS-LOC DNS Resource Record (RR) LOC

This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.

RFC1034 RFC1035 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1876
RFC1877 PPP Internet Protocol Control Protocol Extensions for Name Server Addresses S. Cobb December 1995 ASCII HTML 6 Point-to-Point Protocol Network Control Domain System NetBIOS

This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1877
RFC1878 Variable Length Subnet Table For IPv4 T. Pummill B. Manning December 1995 ASCII HTML 8 values IPv4 subnets

This memo clarifies issues surrounding subnetting IP networks by providing a standard subnet table. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1860 HISTORIC INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1878 10.17487/RFC1878
RFC1879 Class A Subnet Experiment Results and Recommendations B. Manning Editor January 1996 ASCII HTML 6 Internet Registry Operations

This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1879
RFC1880 Internet Official Protocol Standards J. Postel Editor November 1995 ASCII HTML 38 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1800 RFC1920 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1880
RFC1881 IPv6 Address Allocation Management IAB IESG December 1995 ASCII HTML 2 IANA Internet Assigned Numbers Authority

The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1881
RFC1882 The 12-Days of Technology Before Christmas B. Hancock December 1995 ASCII HTML 5

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1882
RFC1883 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1995 ASCII HTML 37 IP Next Generation IPng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1883
RFC1884 IP Version 6 Addressing Architecture R. Hinden Editor S. Deering Editor December 1995 ASCII HTML 18 IPV6-Addr IP Next Generation IPng

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

RFC2373 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1884
RFC1885 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) A. Conta S. Deering December 1995 ASCII HTML 20 IP Next Generation IPng Internet Group Management IGMP

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

RFC2463 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1885
RFC1886 DNS Extensions to support IP version 6 S. Thomson C. Huitema December 1995 ASCII HTML 5 DNS-IPV6 IP Next Generation IPng Domain Name System

This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). [STANDARDS-TRACK]

RFC3596 RFC2874 RFC3152 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1886
RFC1887 An Architecture for IPv6 Unicast Address Allocation Y. Rekhter Editor T. Li Editor December 1995 ASCII HTML 26 IP Next Generation IPng,

This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC1887
RFC1888 OSI NSAPs and IPv6 J. Bound B. Carpenter D. Harrington J. Houldsworth A. Lloyd August 1996 ASCII HTML 16 Internet Protocol Open Systems Interconnection

This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. This memo defines an Experimental Protocol for the Internet community.

RFC4048 RFC4548 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC1888
RFC1889 RTP: A Transport Protocol for Real-Time Applications Audio-Video Transport Working Group H. Schulzrinne S. Casner R. Frederick V. Jacobson January 1996 ASCII HTML 75 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. [STANDARDS-TRACK]

RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1889
RFC1890 RTP Profile for Audio and Video Conferences with Minimal Control Audio-Video Transport Working Group H. Schulzrinne January 1996 ASCII HTML 18 RTP-AV end-to-end network conference

This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. [STANDARDS-TRACK]

RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC1890
RFC1891 SMTP Service Extension for Delivery Status Notifications K. Moore January 1996 ASCII HTML 31 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1891 10.17487/RFC1891
RFC1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 1996 ASCII HTML 4 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]

RFC3462 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1892
RFC1893 Enhanced Mail System Status Codes G. Vaudreuil January 1996 ASCII HTML 15 EMS-CODE simple mail transfer protocol SMTP

There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]

RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app notary 10.17487/RFC1893
RFC1894 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 1996 ASCII HTML 39 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]

RFC3464 RFC2852 PROPOSED STANDARD PROPOSED STANDARD IETF app notary http://www.rfc-editor.org/errata_search.php?rfc=1894 10.17487/RFC1894
RFC1895 The Application/CALS-1840 Content-type E. Levinson February 1996 ASCII HTML 6 MIL-STD-1840 MIME Multipurpose Internet Mail Extensions

This memorandum provides guidelines for using the United States Department of Defense Military Standard MIL-STD-1840, "Automated Interchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1895
RFC1896 The text/enriched MIME Content-type P. Resnick A. Walker February 1996 ASCII PS HTML 21 MIME Multipurpose Internet Mail Extensions

This document defines one particular type of MIME data, the text/enriched MIME type. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1523 RFC1563 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1896
RFC1897 IPv6 Testing Address Allocation R. Hinden J. Postel January 1996 ASCII HTML 4 Internet Protocol prototype software

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.

RFC2471 EXPERIMENTAL EXPERIMENTAL IETF int ipngwg 10.17487/RFC1897
RFC1898 CyberCash Credit Card Protocol Version 0.8 D. Eastlake 3rd B. Boesch S. Crocker M. Yesil February 1996 ASCII HTML 52 general payments system

This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area of Internet payments. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1898
RFC1899 Request for Comments Summary RFC Numbers 1800-1899 J. Elliott January 1997 ASCII HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1899 RFC1900 Renumbering Needs Work B. Carpenter Y. Rekhter February 1996 ASCII HTML 4 IP network number addressing

Hosts in an IP network are identified by IP addresses, and the IP address prefixes of subnets are advertised by routing protocols. A change in such IP addressing information associated with a host or subnet is known as "renumbering". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1900
RFC1901 Introduction to Community-based SNMPv2 J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 8 SNMPV2CB Simple Network Management Protocol Version 2

The purpose of this document is to define the Community-based Administrative Framework for the SNMP version 2 framework (SNMPv2). This document specifies an Experimental protocol for the Internet community.

HISTORIC EXPERIMENTAL IETF snmpv2 10.17487/RFC1901
RFC1902 Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 40 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information (SMI), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

RFC1442 RFC2578 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1902
RFC1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 23 Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

RFC1443 RFC2579 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1903
RFC1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 24 Simple Network Management Protocol Version 2

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

RFC1444 RFC2580 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1904
RFC1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 24 OPS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]

RFC1448 RFC3416 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1905
RFC1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 13 TRANS-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]

RFC1449 RFC3417 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1906
RFC1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 20 SNMPv2-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]

RFC1450 RFC3418 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1907
RFC1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework J. Case K. McCloghrie M. Rose S. Waldbusser January 1996 ASCII HTML 10 COEX-MIB Simple Network Management Protocol Version 2

The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework [1-6], termed the SNMP version 2 framework (SNMPv2), and the original Internet- standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

RFC1452 RFC2576 DRAFT STANDARD DRAFT STANDARD IETF snmpv2 10.17487/RFC1908
RFC1909 An Administrative Infrastructure for SNMPv2 K. McCloghrie Editor February 1996 ASCII HTML 19 SNMPV2AI Simple Network Management Protocol Version 2

It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1909
RFC1910 User-based Security Model for SNMPv2 G. Waters Editor February 1996 ASCII HTML 44 SNMPV2SM Simple Network Management Protocol Version 2

In this administrative framework, a security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions. Although many such security models might be defined, it is the purpose of this document, User-based Security Model for SNMPv2, to define the first, and, as of this writing, only, security model for this administrative framework. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL Legacy 10.17487/RFC1910
RFC1911 Voice Profile for Internet Mail G. Vaudreuil February 1996 ASCII HTML 22 MIME Multipurpose Internet Mail Extensions ESMTP SMTP Service Extensions

The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.

RFC2421 RFC2422 RFC2423 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1911
RFC1912 Common DNS Operational and Configuration Errors D. Barr February 1996 ASCII HTML 16 Domain Name System

This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1537 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1912 10.17487/RFC1912
RFC1913 Architecture of the Whois++ Index Service C. Weider J. Fullton S. Spero February 1996 ASCII HTML 16 WHOIS++A Bunyip Information Systems Inc. MCNC Center for Communications

The authors describe an architecture for indexing in distributed databases, and apply this to the WHOIS++ protocol. [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1913
RFC1914 How to Interact with a Whois++ Mesh P. Faltstrom R. Schoultz C. Weider February 1996 ASCII HTML 10 WHOIS++M distributed databases directory service

In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is done by the client, since each server 'refers' the client to the next appropriate server(s). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF wnils 10.17487/RFC1914
RFC1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol F. Kastenholz February 1996 ASCII HTML 7 Point to Point Protocol

The PPP Working group has developed two protocols, one to control compression on PPP links; the Compression Control Protocol (CCP), documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), used to control encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0003 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=1915 10.17487/RFC1915
RFC1916 Enterprise Renumbering: Experience and Information Solicitation H. Berkowitz P. Ferguson W. Leland P. Nesser February 1996 ASCII HTML 8 tools applications

Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC1916
RFC1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA P. Nesser II February 1996 ASCII HTML 10 address space Internet Assigned Numbers Authority IANA

This document is an appeal to the Internet community to return unused address space, i.e. any block of consecutive IP prefixes, to the Internet Assigned Numbers Authority (IANA) or any of the delegated registries, for reapportionment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0004 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC1917
RFC1918 Address Allocation for Private Internets Y. Rekhter B. Moskowitz D. Karrenberg G. J. de Groot E. Lear February 1996 ASCII HTML 9 TCP/IP network host

This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1627 RFC1597 RFC6761 BCP0005 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd http://www.rfc-editor.org/errata_search.php?rfc=1918 10.17487/RFC1918
RFC1919 Classical versus Transparent IP Proxies M. Chatel March 1996 ASCII HTML 35 firewalls security

This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1919
RFC1920 Internet Official Protocol Standards J. Postel March 1996 ASCII HTML 40 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). [STANDARDS-TRACK]

RFC1880 RFC2000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC1920
RFC1921 TNVIP Protocol J. Dujonc March 1996 ASCII HTML 30

The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1921
RFC1922 Chinese Character Encoding for Internet Messages HF. Zhu DY. Hu ZG. Wang TC. Kao WCH. Chang M. Crispin March 1996 ASCII HTML 27 transport electronic mail telnet WWW

This memo describes methods of transporting Chinese characters in Internet services which transport text, such as electronic mail [RFC-822], network news [RFC-1036], telnet [RFC-854] and the World Wide Web [RFC-1866]. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1922
RFC1923 RIPv1 Applicability Statement for Historic Status J. Halpern S. Bradner March 1996 ASCII HTML 3 Routing Information Protocol

RIP Version 1 [RFC-1058] has been declared an historic document. This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is the Classful nature of RIPv1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC1923
RFC1924 A Compact Representation of IPv6 Addresses R. Elz April 1 1996 ASCII HTML 6 encoding

This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1924
RFC1925 The Twelve Networking Truths R. Callon April 1 1996 ASCII HTML 3 fundamentals

This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1925 10.17487/RFC1925
RFC1926 An Experimental Encapsulation of IP Datagrams on Top of ATM J. Eriksson April 1 1996 ASCII HTML 2 Acoustical Transmission Media (ATM)

This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1926
RFC1927 Suggested Additional MIME Types for Associating Documents C. Rogers April 1 1996 ASCII HTML 3 media-type

Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1927 10.17487/RFC1927
RFC1928 SOCKS Protocol Version 5 M. Leech M. Ganis Y. Lee R. Kuris D. Koblas L. Jones March 1996 ASCII HTML 9 SOCKSV5 firewalls authentication

This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec aft http://www.rfc-editor.org/errata_search.php?rfc=1928 10.17487/RFC1928
RFC1929 Username/Password Authentication for SOCKS V5 M. Leech March 1996 ASCII HTML 2 AUTH-SOCKS firewalls authentication

The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1929
RFC1930 Guidelines for creation, selection, and registration of an Autonomous System (AS) J. Hawkinson T. Bates March 1996 ASCII HTML 10 routing policy Exterior Gateway Protocol Border Inter-Domain Domain Identifier EGP BGP IDRP

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC6996 RFC7300 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC1930
RFC1931 Dynamic RARP Extensions for Automatic Network Address Acquisition D. Brownell April 1996 ASCII HTML 11 Reverse Address Resolution Protocol

This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1931
RFC1932 IP over ATM: A Framework Document R. Cole D. Shur C. Villamizar April 1996 ASCII HTML 31 end-to-end connectivity

It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ipatm 10.17487/RFC1932
RFC1933 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark April 1996 ASCII HTML 22 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC1933
RFC1934 Ascend's Multilink Protocol Plus (MP+) K. Smith April 1996 ASCII HTML 47 PPP

This document proposes an extension to the PPP Multilink Protocol (MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1934
RFC1935 What is the Internet, Anyway? J. Quarterman S. Carl-Mitchell April 1996 ASCII HTML 11 information tutorial

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1935
RFC1936 Implementing the Internet Checksum in Hardware J. Touch B. Parham April 1996 ASCII HTML 21 PLD code UDP TCP

This memo presents a techniques for efficiently implementing the Internet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1936 10.17487/RFC1936
RFC1937 "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks Y. Rekhter D. Kandlur May 1996 ASCII HTML 8 IP subnet

This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rolc 10.17487/RFC1937
RFC1938 A One-Time Password System N. Haller C. Metz May 1996 ASCII HTML 18 OTP authentication S/KEY

This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]

RFC2289 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC1938
RFC1939 Post Office Protocol - Version 3 J. Myers M. Rose May 1996 ASCII HTML 23 POP3 POP3

The Post Office Protocol - Version 3 (POP3) is intended to permit a workstation to dynamically access a maildrop on a server host in a useful fashion. [STANDARDS-TRACK]

RFC1725 RFC1957 RFC2449 RFC6186 RFC8314 STD0053 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1939 10.17487/RFC1939
RFC1940 Source Demand Routing: Packet Format and Forwarding Specification (Version 1) D. Estrin T. Li Y. Rekhter K. Varadhan D. Zappala May 1996 ASCII HTML 27 SDRP

The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg sdr 10.17487/RFC1940
RFC1941 Frequently Asked Questions for Schools J. Sellers J. Robichaux May 1996 ASCII HTML 70 FAQ Internet Education

The goal of this FYI document, produced by the Internet School Networking (ISN) group in the User Services Area of the Internet Engineering Task Force (IETF), is to act as an introduction to the Internet for faculty, administration, and other school personnel in primary and secondary schools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1578 FYI0022 INFORMATIONAL INFORMATIONAL IETF isn 10.17487/RFC1941
RFC1942 HTML Tables D. Raggett May 1996 ASCII HTML 30 HTML-TBL HyperText Markup Language SGML

This specification extends HTML to support a wide variety of tables. This memo defines an Experimental Protocol for the Internet community.

RFC2854 HISTORIC EXPERIMENTAL IETF app html 10.17487/RFC1942
RFC1943 Building an X.500 Directory Service in the US B. Jennings May 1996 ASCII HTML 22 White Pages

This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the United States. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC1943
RFC1944 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid May 1996 ASCII HTML 30 testing performance

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC1944
RFC1945 Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee R. Fielding H. Frystyk May 1996 ASCII HTML 60 HTTP-1.0 HTTP World-Wide Web application

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC1945
RFC1946 Native ATM Support for ST2+ S. Jackowski May 1996 ASCII HTML 21 integrated services ATM Quality of Service QoS

This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments: ATM to internet, internet to ATM, and internet to internet across ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1946
RFC1947 Greek Character Encoding for Electronic Mail Messages D. Spinellis May 1996 ASCII HTML 7 character set ISO MIME

This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1947
RFC1948 Defending Against Sequence Number Attacks S. Bellovin May 1996 ASCII HTML 6 crypgraphic authentication spoofing

IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC6528 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=1948 10.17487/RFC1948
RFC1949 Scalable Multicast Key Distribution A. Ballardie May 1996 ASCII HTML 18 SMKD MBONE security authentication

This memo provides a scalable solution to the multicast key distribution problem. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC1949
RFC1950 ZLIB Compressed Data Format Specification version 3.3 P. Deutsch J-L. Gailly May 1996 ASCII PS PDF HTML 11 ZLIB compressed data format checksum

This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1950
RFC1951 DEFLATE Compressed Data Format Specification version 1.3 P. Deutsch May 1996 ASCII PS PDF HTML 17 DEFLATE compressed data format coding

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1951
RFC1952 GZIP file format specification version 4.3 P. Deutsch May 1996 ASCII PS PDF HTML 12 GZIP compressed data format redundancy check

This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1952
RFC1953 Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII HTML 20 IFMP IP flow routing information

The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1953
RFC1954 Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall May 1996 ASCII HTML 8 datagrams IFMP

This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1954
RFC1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG R. Hinden June 1996 ASCII HTML 5 IPNG addressing routing

This paper proposes a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1955
RFC1956 Registration in the MIL Domain D. Engebretson R. Plzak June 1996 ASCII HTML 2 DoD Department of Defense

This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1956
RFC1957 Some Observations on Implementations of the Post Office Protocol (POP3) R. Nelson June 1996 ASCII HTML 2 client server

This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1939 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1957
RFC1958 Architectural Principles of the Internet B. Carpenter Editor June 1996 ASCII HTML 8 IAB

The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC3439 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1958
RFC1959 An LDAP URL Format T. Howes M. Smith June 1996 ASCII HTML 4 LDAP-URL Lightweight Directory Access Protocol Uniform Resource Locator

This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]

RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=1959 10.17487/RFC1959
RFC1960 A String Representation of LDAP Search Filters T. Howes June 1996 ASCII HTML 3 LDAP-STR Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

RFC1558 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC1960
RFC1961 GSS-API Authentication Method for SOCKS Version 5 P. McMahon June 1996 ASCII HTML 9 GSSAPI-SOC Generic Security Service Application Program Interface

This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec aft 10.17487/RFC1961
RFC1962 The PPP Compression Control Protocol (CCP) D. Rand June 1996 ASCII HTML 9 PPP-CCP point-to-point protocol data links

This document defines a method for negotiating data compression over PPP links. [STANDARDS-TRACK]

RFC2153 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1962
RFC1963 PPP Serial Data Transport Protocol (SDTP) K. Schneider S. Venters August 1996 ASCII HTML 20 Point-to-Point Protocol

This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1963
RFC1964 The Kerberos Version 5 GSS-API Mechanism J. Linn June 1996 ASCII HTML 20 GSSAPI-KER Generic Security Service Application Program Interface

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS-TRACK]

RFC4121 RFC6649 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC1964
RFC1965 Autonomous System Confederations for BGP P. Traina June 1996 ASCII HTML 7 BGP-ASC Border Gateway Protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. This memo defines an Experimental Protocol for the Internet community.

RFC3065 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1965
RFC1966 BGP Route Reflection An alternative to full mesh IBGP T. Bates R. Chandra June 1996 ASCII HTML 7 BGP-RR Border Gateway Protocol autonomous system

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. This memo defines an Experimental Protocol for the Internet community.

RFC4456 RFC2796 EXPERIMENTAL EXPERIMENTAL IETF rtg idr 10.17487/RFC1966
RFC1967 PPP LZS-DCP Compression Protocol (LZS-DCP) K. Schneider R. Friend August 1996 ASCII HTML 18 Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1967
RFC1968 The PPP Encryption Control Protocol (ECP) G. Meyer June 1996 ASCII HTML 11 PPP-ECP Point-to-Point Protocol data

This document defines a method for negotiating data encryption over PPP links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1968
RFC1969 The PPP DES Encryption Protocol (DESE) K. Sklower G. Meyer June 1996 ASCII HTML 10 Point-to-Point Protocol encapsulated packets

This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2419 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1969
RFC1970 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson August 1996 ASCII HTML 82 Internet Protocol

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1970
RFC1971 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten August 1996 ASCII HTML 23 Internet Protocol link-local address Duplicate Address Detection procedure

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

RFC2462 PROPOSED STANDARD PROPOSED STANDARD IETF int addrconf 10.17487/RFC1971
RFC1972 A Method for the Transmission of IPv6 Packets over Ethernet Networks M. Crawford August 1996 ASCII HTML 4 IPV6-ETHER Internet Protocol frame format transmission

This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]

RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC1972
RFC1973 PPP in Frame Relay W. Simpson June 1996 ASCII HTML 10 PPP-FRAME Point-to-Point Protocol encapsulated packets

This document describes the use of Frame Relay for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC1973
RFC1974 PPP Stac LZS Compression Protocol R. Friend W. Simpson August 1996 ASCII HTML 20 PPP-STAC Point-to-Point Protocol Compression Control CCP

This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1974
RFC1975 PPP Magnalink Variable Resource Compression D. Schremp J. Black J. Weiss August 1996 ASCII HTML 6 PPP-MAG Point-to-Point Protocol MVRCA

The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1975
RFC1976 PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) K. Schneider S. Venters August 1996 ASCII HTML 10 PPP-DCE Point-to-Point Protocol LCP extension

This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-Terminating Equipment (DCE). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1976
RFC1977 PPP BSD Compression Protocol V. Schryver August 1996 ASCII HTML 25 PPP-BSD Point-to-Point Protocol Unix Compress

This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1977
RFC1978 PPP Predictor Compression Protocol D. Rand August 1996 ASCII HTML 9 PPP-PRED Point-to-Point Protocol

This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1978
RFC1979 PPP Deflate Protocol J. Woods August 1996 ASCII HTML 10 PPP-DEFL Point-to-Point Protocol Compression Control

This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=1979 10.17487/RFC1979
RFC1980 A Proposed Extension to HTML : Client-Side Image Maps J. Seidman August 1996 ASCII HTML 7 HyperText Markup Language Uniform Identifier URI

The markup language known as "HTML/2.0" provides for image maps. Image maps are document elements which allow clicking different areas of an image to reference different network resources, as specified by Uniform Identifier (URIs). The image map capability in HTML/2.0 is limited in several ways, such as the restriction that it only works with documents served via the "HTTP" protocol, and the lack of a viable fallback for users of text-only browsers. This document specifies an extension to the HTML language, referred to as "Client- Side Image Maps," which resolves these limitations.

RFC2854 HISTORIC INFORMATIONAL Legacy 10.17487/RFC1980
RFC1981 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul August 1996 ASCII HTML 15 MTU-IPV6 Internet Protocol

This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. [STANDARDS-TRACK]

RFC8201 DRAFT STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=1981 10.17487/RFC1981
RFC1982 Serial Number Arithmetic R. Elz R. Bush August 1996 ASCII HTML 6 SNA domain name system DNS

The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]

RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1982
RFC1983 Internet Users' Glossary G. Malkin Editor August 1996 ASCII HTML 62 basic terms acronyms

There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1392 FYI0018 INFORMATIONAL INFORMATIONAL IETF userglos 10.17487/RFC1983
RFC1984 IAB and IESG Statement on Cryptographic Technology and the Internet IAB IESG August 1996 ASCII HTML 5 security privacy

The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

BCP0200 BEST CURRENT PRACTICE INFORMATIONAL Legacy 10.17487/RFC1984
RFC1985 SMTP Service Extension for Remote Message Queue Starting J. De Winter August 1996 ASCII HTML 7 SMTP-ETRN Simple ETRN Mail Transfer Protocol

This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=1985 10.17487/RFC1985
RFC1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) W. Polites W. Wollman D. Woo R. Langan August 1996 ASCII HTML 21 ETFTP TFTP NETBLT

This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC1986
RFC1987 Ipsilon's General Switch Management Protocol Specification Version 1.1 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall August 1996 ASCII HTML 44 GSMP ATM switch

The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2297 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1987
RFC1988 Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework G. McAnally D. Gilbert J. Flick August 1996 ASCII HTML 2 HP

This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1988
RFC1989 PPP Link Quality Monitoring W. Simpson August 1996 ASCII HTML 16 PPP-LINK Point-to-Point Protocol

This document defines a protocol for generating Link-Quality-Reports. [STANDARDS-TRACK]

RFC1333 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1989
RFC1990 The PPP Multilink Protocol (MP) K. Sklower B. Lloyd G. McGregor D. Carr T. Coradetti August 1996 ASCII HTML 24 PPP-MP Point-to-Point Protocol datagrams

This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. [STANDARDS-TRACK]

RFC1717 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1990
RFC1991 PGP Message Exchange Formats D. Atkins W. Stallings P. Zimmermann August 1996 ASCII HTML 21 PGP-MEF Pretty Good Privacy encryption electronic mail

This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC4880 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1991
RFC1992 The Nimrod Routing Architecture I. Castineyra N. Chiappa M. Steenstrup August 1996 ASCII HTML 27 scalable internetwork

Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC1992
RFC1993 PPP Gandalf FZA Compression Protocol A. Barbir D. Carr W. Simpson August 1996 ASCII HTML 7 Point-to-Point Protocol

This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. This memo provides information for the Internet community. It does not specify an Internet standard.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC1993
RFC1994 PPP Challenge Handshake Authentication Protocol (CHAP) W. Simpson August 1996 ASCII HTML 13 PPP-CHAP Point-to-Point Protocol cryptology

This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. [STANDARDS-TRACK]

RFC1334 RFC2484 DRAFT STANDARD DRAFT STANDARD IETF int pppext 10.17487/RFC1994
RFC1995 Incremental Zone Transfer in DNS M. Ohta August 1996 ASCII HTML 8 DNS-IZT Domain Name System IXFR

This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]

RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=1995 10.17487/RFC1995
RFC1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) P. Vixie August 1996 ASCII HTML 7 DNS-NOTIFY Domain Name System

This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]

RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC1996
RFC1997 BGP Communities Attribute R. Chandra P. Traina T. Li August 1996 ASCII HTML 5 BGP-COMM Border Gateway Protocol

This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]

RFC7606 RFC8642 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=1997 10.17487/RFC1997
RFC1998 An Application of the BGP Community Attribute in Multi-home Routing E. Chen T. Bates August 1996 ASCII HTML 9 Border Gateway Protocol

This document presents an application of the BGP community attribute [2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC1998
RFC1999 Request for Comments Summary RFC Numbers 1900-1999 J. Elliott January 1997 ASCII HTML 20 Index INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC1999 RFC2000 Internet Official Protocol Standards J. Postel Editor February 1997 ASCII HTML 56 status procedure index

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard.

RFC1920 RFC2200 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2000
RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms W. Stevens January 1997 ASCII HTML 6 TCPSLOWSRT Transmission Control Protocol

Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]

RFC2581 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2001
RFC2002 IP Mobility Support C. Perkins Editor October 1996 ASCII HTML 79 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. [STANDARDS-TRACK]

RFC3220 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2002
RFC2003 IP Encapsulation within IP C. Perkins October 1996 ASCII HTML 14 IPENCAPIP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]

RFC3168 RFC6864 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2003 10.17487/RFC2003
RFC2004 Minimal Encapsulation within IP C. Perkins October 1996 ASCII HTML 6 MINI-IP Internet Protocol

This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2004 10.17487/RFC2004
RFC2005 Applicability Statement for IP Mobility Support J. Solomon October 1996 ASCII HTML 5 Internet Protocol

As required by [RFC 1264], this report discusses the applicability of Mobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2005
RFC2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2 D. Cong M. Hamlen C. Perkins October 1996 ASCII HTML 52 MOBILEIPMIB Mobile Internet Protocol MIB Managed Information Base

This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=2006 10.17487/RFC2006
RFC2007 Catalogue of Network Training Materials J. Foster M. Isaacs M. Prior October 1996 ASCII HTML 55 TRAINMAT IETF TERENA

The purpose of this document is to provide a catalogue of quality Network Training Materials for use by Internet trainers in training their users. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

FYI0029 INFORMATIONAL INFORMATIONAL IETF trainmat 10.17487/RFC2007
RFC2008 Implications of Various Address Allocation Policies for Internet Routing Y. Rekhter T. Li October 1996 ASCII HTML 13 IP unicast

The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0007 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF cidrd 10.17487/RFC2008
RFC2009 GPS-Based Addressing and Routing T. Imielinski J. Navas November 1996 ASCII HTML 27 GPS-AR domain names geographic

This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2009
RFC2010 Operational Criteria for Root Name Servers B. Manning P. Vixie October 1996 ASCII HTML 7 host hardware

This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2870 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2010
RFC2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII HTML 18 MIB-IP IP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]

RFC4293 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2011
RFC2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII HTML 10 MIB-TCP TCP Simple Network Management Protocol MIB

This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]

RFC4022 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2012
RFC2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 K. McCloghrie Editor November 1996 ASCII HTML 6 MIB-UDP] Simple Network Management Protocol MIB UDP

This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]

RFC4113 RFC1213 PROPOSED STANDARD PROPOSED STANDARD IETF snmpv2 10.17487/RFC2013
RFC2014 IRTF Research Group Guidelines and Procedures A. Weinrib J. Postel October 1996 ASCII HTML 13 Internet Research Task Force

This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0008 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2014
RFC2015 MIME Security with Pretty Good Privacy (PGP) M. Elkins October 1996 ASCII HTML 8 MIME-PGP Authentication Encryption

This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847. [STANDARDS-TRACK]

RFC3156 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2015 10.17487/RFC2015
RFC2016 Uniform Resource Agents (URAs) L. Daigle P. Deutsch B. Heelan C. Alpaugh M. Maclachlan October 1996 ASCII HTML 21 URAS

This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2016
RFC2017 Definition of the URL MIME External-Body Access-Type N. Freed K. Moore A. Cargille October 1996 ASCII HTML 5 URL-ACC Uniform Resource Locators Multipurpose Internet Message Extensions

This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mailext 10.17487/RFC2017
RFC2018 TCP Selective Acknowledgment Options M. Mathis J. Mahdavi S. Floyd A. Romanow October 1996 ASCII HTML 12 TCP-ACK Transmission Control Protocol SACK

This memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]

RFC1072 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcplw http://www.rfc-editor.org/errata_search.php?rfc=2018 10.17487/RFC2018
RFC2019 Transmission of IPv6 Packets Over FDDI M. Crawford October 1996 ASCII HTML 6 IPV6-FDDI frame format Fiber Distributed Data Interface

This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]

RFC2467 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2019
RFC2020 IEEE 802.12 Interface MIB J. Flick October 1996 ASCII HTML 31 802.12-MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2020
RFC2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 S. Waldbusser January 1997 ASCII HTML 130 RMON-MIB RMON MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2021 10.17487/RFC2021
RFC2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks G. Armitage November 1996 ASCII HTML 82 MULTI-UNI Asynchronous Transfer Mode

This memo describes a mechanism to support the multicast needs of Layer 3 protocols in general, and describes its application to IP multicasting in particular. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipatm 10.17487/RFC2022
RFC2023 IP Version 6 over PPP D. Haskin E. Allen October 1996 ASCII HTML 10 IPV6-PPP Internet Protocol Point IPv6

This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. [STANDARDS-TRACK]

RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2023
RFC2024 Definitions of Managed Objects for Data Link Switching using SMIv2 D. Chen Editor P. Gayek S. Nix October 1996 ASCII HTML 90 DLSW-MIB MIB DLSW Management Information Base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg dlswmib 10.17487/RFC2024
RFC2025 The Simple Public-Key GSS-API Mechanism (SPKM) C. Adams October 1996 ASCII HTML 45 SPKM

This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2025
RFC2026 The Internet Standards Process -- Revision 3 S. Bradner October 1996 ASCII HTML 36 Protocols copyrights intellectual property

This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1602 RFC1871 RFC3667 RFC3668 RFC3932 RFC3978 RFC3979 RFC5378 RFC5657 RFC5742 RFC6410 RFC7100 RFC7127 RFC7475 RFC8179 RFC8789 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2026 10.17487/RFC2026
RFC2027 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin October 1996 ASCII HTML 11 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2282 INFORMATIONAL BEST CURRENT PRACTICE IETF gen poised95 10.17487/RFC2027
RFC2028 The Organizations Involved in the IETF Standards Process R. Hovey S. Bradner October 1996 ASCII HTML 7 Internet Engineering Task Force

This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC3668 RFC3979 RFC8717 BCP0011 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen poised95 http://www.rfc-editor.org/errata_search.php?rfc=2028 10.17487/RFC2028
RFC2029 RTP Payload Format of Sun's CellB Video Encoding M. Speer D. Hoffman October 1996 ASCII HTML 6 RTP-CELLB Real Time Transport Protocol

This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2029
RFC2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills October 1996 ASCII HTML 18 NTP SNTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1769 RFC4330 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2030 10.17487/RFC2030
RFC2031 IETF-ISOC relationship E. Huizer October 1996 ASCII HTML 4 Internet Society Engineering Task Force

This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC8712 INFORMATIONAL INFORMATIONAL IETF gen poised95 10.17487/RFC2031
RFC2032 RTP Payload Format for H.261 Video Streams T. Turletti C. Huitema October 1996 ASCII HTML 11 RTP-H.261 Real Time Transport Protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]

RFC4587 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2032
RFC2033 Local Mail Transfer Protocol J. Myers October 1996 ASCII HTML 7 LMTP SMTP Simple Mail Transfer Protocol

SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2033
RFC2034 SMTP Service Extension for Returning Enhanced Error Codes N. Freed October 1996 ASCII HTML 6 SMTP-ENH Simple Mail Transfer Protocol

This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2034
RFC2035 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne October 1996 ASCII HTML 16 RTP-JPEG Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. [STANDARDS-TRACK]

RFC2435 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2035
RFC2036 Observations on the use of Components of the Class A Address Space within the Internet G. Huston October 1996 ASCII HTML 9 Internet Assigned Numbers Authority IANA

This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of the Class A address space to registries, for deployment within the Internet as class-less address blocks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL IETF cidrd 10.17487/RFC2036
RFC2037 Entity MIB using SMIv2 K. McCloghrie A. Bierman October 1996 ASCII HTML 35 ENTITY-MIB Management Information Base SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

RFC2737 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib 10.17487/RFC2037
RFC2038 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal October 1996 ASCII HTML 11 Real Time Transport Protocol

This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. [STANDARDS-TRACK]

RFC2250 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2038
RFC2039 Applicability of Standards Track MIBs to Management of World Wide Web Servers C. Kalbfleisch November 1996 ASCII HTML 14 Management Information Base HTTP

This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2039
RFC2040 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms R. Baldwin R. Rivest October 1996 ASCII HTML 29 RC5 Cipher Block Chaining CBC

This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2040 10.17487/RFC2040
RFC2041 Mobile Network Tracing B. Noble G. Nguyen M. Satyanarayanan R. Katz October 1996 ASCII HTML 27 IP Internet Protocol

This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2041
RFC2042 Registering New BGP Attribute Types B. Manning January 1997 ASCII HTML 3 Border Gateway Protocol

This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2042 10.17487/RFC2042
RFC2043 The PPP SNA Control Protocol (SNACP) A. Fuqua October 1996 ASCII HTML 7 PPP-SNACP Point-to-point protocol systems network architecture

This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2043
RFC2044 UTF-8, a transformation format of Unicode and ISO 10646 F. Yergeau October 1996 ASCII HTML 6 UCS Transformation Format

The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2279 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2044
RFC2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed N. Borenstein November 1996 ASCII HTML 31 MIME media types headers

This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 RFC5335 RFC6532 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2045 10.17487/RFC2045
RFC2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed N. Borenstein November 1996 ASCII HTML 44 MIME-MEDIA headers structure

This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 RFC2646 RFC3798 RFC5147 RFC6657 RFC8098 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2046 10.17487/RFC2046
RFC2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996 ASCII HTML 15 MIME-MSG media type

This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 RFC2184 RFC2231 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2047 10.17487/RFC2047
RFC2048 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin J. Postel November 1996 ASCII HTML 21 media types external body access content-transfer-encodings

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fourth document, RFC 2048, specifies various IANA registration procedures for some MIME facilities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1521 RFC1522 RFC1590 RFC4288 RFC4289 RFC3023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app 822ext 10.17487/RFC2048
RFC2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed N. Borenstein November 1996 ASCII HTML 24 MIME-CONF media type message formats

This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography. [STANDARDS-TRACK]

RFC1521 RFC1522 RFC1590 DRAFT STANDARD DRAFT STANDARD IETF app 822ext http://www.rfc-editor.org/errata_search.php?rfc=2049 10.17487/RFC2049
RFC2050 Internet Registry IP Allocation Guidelines K. Hubbard M. Kosters D. Conrad D. Karrenberg J. Postel November 1996 ASCII HTML 13 Internet Addresses Network Numbers

This document describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1466 RFC7020 HISTORIC BEST CURRENT PRACTICE Legacy 10.17487/RFC2050
RFC2051 Definitions of Managed Objects for APPC using SMIv2 M. Allen B. Clouston Z. Kielczewski W. Kwan B. Moore October 1996 ASCII HTML 124 SNANAU-APP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2051
RFC2052 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie October 1996 ASCII HTML 10 DNS-SRV Domain Name System

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). This memo defines an Experimental Protocol for the Internet community.

RFC2782 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2052
RFC2053 The AM (Armenia) Domain E. Der-Danieliantz October 1996 ASCII HTML 3 Top Level Domain Country Code

The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2053
RFC2054 WebNFS Client Specification B. Callaghan October 1996 ASCII HTML 16 Network Fil System

This document describes a lightweight binding mechanism that allows NFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2054
RFC2055 WebNFS Server Specification B. Callaghan October 1996 ASCII HTML 10 Network Fil System

This document describes the specifications for a server of WebNFS clients. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2055
RFC2056 Uniform Resource Locators for Z39.50 R. Denenberg J. Kunze D. Lynch November 1996 ASCII HTML 7 URLZ39.50 URL information retrieval

Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2056
RFC2057 Source Directed Access Control on the Internet S. Bradner November 1996 ASCII HTML 20 content regulation deposition

This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2057
RFC2058 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens January 1997 ASCII HTML 64 encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

RFC2138 PROPOSED STANDARD PROPOSED STANDARD IETF ops nasreq 10.17487/RFC2058
RFC2059 RADIUS Accounting C. Rigney January 1997 ASCII HTML 25 remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2139 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2059
RFC2060 Internet Message Access Protocol - Version 4rev1 M. Crispin December 1996 ASCII HTML 82 IMAPV4 IMAP electronic mail Internet Message Access Protocol

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]

RFC1730 RFC3501 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2060 10.17487/RFC2060
RFC2061 IMAP4 Compatibility with IMAP2bis M. Crispin December 1996 ASCII HTML 3 IMAP electronic mail Internet Message Access Protocol

This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1730 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2061
RFC2062 Internet Message Access Protocol - Obsolete Syntax M. Crispin December 1996 ASCII HTML 8 IMAP electronic mail

This document describes obsolete syntax which may be encountered by IMAP4 implementations which deal with older versions of the Internet Mail Access Protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2062
RFC2063 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth January 1997 ASCII HTML 37 TFM-ARCH network data

This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. This memo defines an Experimental Protocol for the Internet community.

RFC2722 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2063
RFC2064 Traffic Flow Measurement: Meter MIB N. Brownlee January 1997 ASCII HTML 38 METER-MIB Management Information Base Network Data

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. This memo defines an Experimental Protocol for the Internet community.

RFC2720 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2064
RFC2065 Domain Name System Security Extensions D. Eastlake 3rd C. Kaufman January 1997 ASCII HTML 41 DNS-SEC DNS authentication encryption

The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]

RFC2535 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2065
RFC2066 TELNET CHARSET Option R. Gellens January 1997 ASCII HTML 12 TOPT-CHARSET character set application

This document specifies a mechanism for passing character set and translation information between a TELNET client and server. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2066
RFC2067 IP over HIPPI J. Renwick January 1997 ASCII HTML 30 IP-HIPPI ANSI High-Performance Parallel Interface Internet Protocol

ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. [STANDARDS-TRACK]

DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2067
RFC2068 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk T. Berners-Lee January 1997 ASCII HTML 162 HTTP-1.1 World Wide Web WWW hypermedia

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]

RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2068
RFC2069 An Extension to HTTP : Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler P. Leach A. Luotonen E. Sink L. Stewart January 1997 ASCII HTML 18 DAA Hypertext Transfer Protocol

The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2069 10.17487/RFC2069
RFC2070 Internationalization of the Hypertext Markup Language F. Yergeau G. Nicol G. Adams M. Duerst January 1997 ASCII HTML 43 HTML-INT HTML WWW World Wide Web

This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. [STANDARDS-TRACK]

RFC2854 HISTORIC PROPOSED STANDARD IETF app html 10.17487/RFC2070
RFC2071 Network Renumbering Overview: Why would I want it and what is it anyway? P. Ferguson H. Berkowitz January 1997 ASCII HTML 14 Internet Enterprise Connecting Routers

This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2071
RFC2072 Router Renumbering Guide H. Berkowitz January 1997 ASCII HTML 48 Internet Enterprise Connecting Routers

Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC4192 INFORMATIONAL INFORMATIONAL IETF ops pier 10.17487/RFC2072
RFC2073 An IPv6 Provider-Based Unicast Address Format Y. Rekhter P. Lothberg R. Hinden S. Deering J. Postel January 1997 ASCII HTML 7 IPV6-UNI

This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]

RFC2374 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2073
RFC2074 Remote Network Monitoring MIB Protocol Identifiers A. Bierman R. Iddon January 1997 ASCII HTML 43 RMON-MIB RMON Management Information Base

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]

RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2074
RFC2075 IP Echo Host Service C. Partridge January 1997 ASCII HTML 5 IP-Echo Internet Protocol datagram

This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2075
RFC2076 Common Internet Message Headers J. Palme February 1997 ASCII HTML 27 email

This memo contains a table of commonly occurring headers in headings of e-mail messages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app mailext http://www.rfc-editor.org/errata_search.php?rfc=2076 10.17487/RFC2076
RFC2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions S. Nelson C. Parks Mitra January 1997 ASCII HTML 13 MIME-MODEL MIME Media Type Content Type

The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2077
RFC2078 Generic Security Service Application Program Interface, Version 2 J. Linn January 1997 ASCII HTML 85 GSSAP Authentication Cryptology Data integrity

The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]

RFC1508 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2078
RFC2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) M. Smith January 1997 ASCII HTML 5 URI-ATT URL Universal Resource Locators Directory

This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2079
RFC2080 RIPng for IPv6 G. Malkin R. Minnear January 1997 ASCII HTML 19 RIPNG-IPV6 Routing Information Protocol Internet

This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2080
RFC2081 RIPng Protocol Applicability Statement G. Malkin January 1997 ASCII HTML 4 Routing Information Protocol Internet

As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rip 10.17487/RFC2081
RFC2082 RIP-2 MD5 Authentication F. Baker R. Atkinson January 1997 ASCII HTML 12 RIP2-MD5 Routing Information Protocol Encryption

Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]

RFC4822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ripv2 10.17487/RFC2082
RFC2083 PNG (Portable Network Graphics) Specification Version 1.0 T. Boutell March 1997 ASCII HTML 102 PNG file format bitmap

This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2083
RFC2084 Considerations for Web Transaction Security G. Bossert S. Cooper W. Drummond January 1997 ASCII HTML 6 authentication encryption World Wide Web WWW

This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF sec wts 10.17487/RFC2084
RFC2085 HMAC-MD5 IP Authentication with Replay Prevention M. Oehler R. Glenn February 1997 ASCII HTML 6 HMAC-MD5 ipsec Message Digest Security Internet Protocol Encryption

This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2085
RFC2086 IMAP4 ACL extension J. Myers January 1997 ASCII HTML 8 IMAP4-ACL Internet Message Access Protocol Control List

The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

RFC4314 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2086
RFC2087 IMAP4 QUOTA extension J. Myers January 1997 ASCII HTML 5 IMAP4-QUO Internet Message Access Protocol

The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2087
RFC2088 IMAP4 non-synchronizing literals J. Myers January 1997 ASCII HTML 2 IMAP4-LIT Internet Message Access Protocol

The Internet Message Access Protocol [STANDARDS-TRACK]

RFC7888 RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2088
RFC2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent B. Wijnen D. Levi January 1997 ASCII HTML 12

The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2576 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2089
RFC2090 TFTP Multicast Option A. Emberson February 1997 ASCII HTML 6 TFTP-MULTI Trivial File Transfer Protocol

This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2090
RFC2091 Triggered Extensions to RIP to Support Demand Circuits G. Meyer S. Sherry January 1997 ASCII HTML 22 RIP-TRIG

This document defines a modification which can be applied to Bellman- Ford (distance vector) algorithm information broadcasting protocols. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg rip 10.17487/RFC2091
RFC2092 Protocol Analysis for Triggered RIP S. Sherry G. Meyer January 1997 ASCII HTML 6

As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg rip http://www.rfc-editor.org/errata_search.php?rfc=2092 10.17487/RFC2092
RFC2093 Group Key Management Protocol (GKMP) Specification H. Harney C. Muckenhirn July 1997 ASCII HTML 23 GKMP-SPEC

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2093
RFC2094 Group Key Management Protocol (GKMP) Architecture H. Harney C. Muckenhirn July 1997 ASCII HTML 22 GKMP-ARCH

This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2094
RFC2095 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede January 1997 ASCII HTML 5 Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

RFC2195 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2095
RFC2096 IP Forwarding Table MIB F. Baker January 1997 ASCII HTML 21 TABLE-MIB Management Information Base Internet Protocol

This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]

RFC1354 RFC4292 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2096
RFC2097 The PPP NetBIOS Frames Control Protocol (NBFCP) G. Pall January 1997 ASCII HTML 13 PPP-NBFCP Point-to-Point Protocol

This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2097
RFC2098 Toshiba's Router Architecture Extensions for ATM : Overview Y. Katsube K. Nagami H. Esaki February 1997 ASCII HTML 18 Asynchronis Transfer Mode datagram IP Internet Protocol

This memo describes a new internetworking architecture which makes better use of the property of ATM. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2098
RFC2099 Request for Comments Summary RFC Numbers 2000-2099 J. Elliott March 1997 ASCII HTML 21 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2099 RFC2100 The Naming of Hosts J. Ashworth April 1 1997 ASCII HTML 3 April Fool's

This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2100 10.17487/RFC2100
RFC2101 IPv4 Address Behaviour Today B. Carpenter J. Crowcroft Y. Rekhter February 1997 ASCII HTML 13 Internet Protocol Internet Architecture Board

The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2101
RFC2102 Multicast Support for Nimrod : Requirements and Solution Approaches R. Ramanathan February 1997 ASCII HTML 23 scalable routing architecture

Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2102
RFC2103 Mobility Support for Nimrod : Challenges and Solution Approaches R. Ramanathan February 1997 ASCII HTML 17 IP Internet Protocol routing addressing

We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg nimrod 10.17487/RFC2103
RFC2104 HMAC: Keyed-Hashing for Message Authentication H. Krawczyk M. Bellare R. Canetti February 1997 ASCII HTML 11 ipsec Message Digest Internet Protocol Security encryption

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind

RFC6151 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2104 10.17487/RFC2104
RFC2105 Cisco Systems' Tag Switching Architecture Overview Y. Rekhter B. Davie D. Katz E. Rosen G. Swallow February 1997 ASCII HTML 13 network layer packet ATM switches

This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2105
RFC2106 Data Link Switching Remote Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII HTML 19 DLSRAP NetBios DLSW

This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2114 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2106
RFC2107 Ascend Tunnel Management Protocol - ATMP K. Hamzeh February 1997 ASCII HTML 21 RADIUS authentication

This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2107
RFC2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie February 1997 ASCII HTML 82 802.3-MIB MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 10 and 100 Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10 &

RFC1516 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2108
RFC2109 HTTP State Management Mechanism D. Kristol L. Montulli February 1997 ASCII HTML 21 HTTP-STATE Hypertext Transfer Protocol cookie

This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. [STANDARDS-TRACK]

RFC2965 HISTORIC PROPOSED STANDARD IETF app http 10.17487/RFC2109
RFC2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann March 1997 ASCII HTML 19 MHTML Hyper Text Markup Language Multipurpose Internet Mail Extensions

This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. [STANDARDS-TRACK]

RFC2557 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2110
RFC2111 Content-ID and Message-ID Uniform Resource Locators E. Levinson March 1997 ASCII HTML 5 Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

RFC2392 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2111
RFC2112 The MIME Multipart/Related Content-type E. Levinson March 1997 ASCII HTML 9 Hyper Text Markup Language Multipurpose Internet,Mail Extensions

The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

RFC1872 RFC2387 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml 10.17487/RFC2112
RFC2113 IP Router Alert Option D. Katz February 1997 ASCII HTML 4 ROUT-ALERT

This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]

RFC5350 RFC6398 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2113
RFC2114 Data Link Switching Client Access Protocol S. Chiang J. Lee H. Yasuda February 1997 ASCII HTML 22 DLSCAP

This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2114
RFC2115 Management Information Base for Frame Relay DTEs Using SMIv2 C. Brown F. Baker September 1997 ASCII HTML 32 FRAME-MIB MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing Frame Relay interfaces on DTEs. [STANDARDS-TRACK]

RFC1315 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2115
RFC2116 X.500 Implementations Catalog-96 C. Apple K. Rossen April 1997 ASCII HTML 164 Directory Services DSA DUA Agent Interfaces

This document is a revision to [RFC 1632]: A Revised Catalog of Available X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. [RFC 1632] is a revision of [RFC 1292]. This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1632 FYI0011 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2116
RFC2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1997 ASCII HTML 66

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.

RFC2362 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2117
RFC2118 Microsoft Point-To-Point Compression (MPPC) Protocol G. Pall March 1997 ASCII HTML 9 Point-to-Point Protocol PPP

This document describes the use of the Microsoft Point to Point Compression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2118
RFC2119 Key words for use in RFCs to Indicate Requirement Levels S. Bradner March 1997 ASCII HTML 3 Standards Track Documents

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bradner-key-words-03 RFC8174 BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2119 10.17487/RFC2119
RFC2120 Managing the X.500 Root Naming Context D. Chadwick March 1997 ASCII HTML 14 X.500-NAME ISO International Standards Organization

This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app ids 10.17487/RFC2120
RFC2121 Issues affecting MARS Cluster Size G. Armitage March 1997 ASCII HTML 12 ATM Asynchronous Transfer Mode Multicast IP Internet Protocol

This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2121
RFC2122 VEMMI URL Specification D. Mavrakis H. Layec K. Kartmann March 1997 ASCII HTML 11 VEMMI-URL Uniform Resource Locator Enhanced Man-Machine Interface Videotex

A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2122
RFC2123 Traffic Flow Measurement: Experiences with NeTraMet N. Brownlee March 1997 ASCII HTML 34 Meter Reader Network

This memo records experiences in implementing and using the Traffic Flow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2123
RFC2124 Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 P. Amsden J. Amweg P. Calato S. Bensley G. Lyons March 1997 ASCII HTML 21 LFAP

This document specifies the protocol between the switch Connection Control Entity (CCE) and the external FAS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2124
RFC2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) C. Richards K. Smith March 1997 ASCII HTML 24 BAP-BACP Point-to-Point datagram multilink

This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2125
RFC2126 ISO Transport Service on top of TCP (ITOT) Y. Pouffary A. Young March 1997 ASCII HTML 25 ITOT International Standards Organization Transmission Control Protocol

This document is a revision to STD35, RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. [STANDARDS-TRACK]

RFC1006 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2126 10.17487/RFC2126
RFC2127 ISDN Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII HTML 49 ISDN-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a minimal set of managed objects for SNMP-based management of ISDN terminal interfaces. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib http://www.rfc-editor.org/errata_search.php?rfc=2127 10.17487/RFC2127
RFC2128 Dial Control Management Information Base using SMIv2 G. Roeck Editor March 1997 ASCII HTML 34 DC-MIB MIB ISDN Integrated Services Digital Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing demand access circuits, including ISDN. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int isdnmib 10.17487/RFC2128
RFC2129 Toshiba's Flow Attribute Notification Protocol (FANP) Specification K. Nagami Y. Katsube Y. Shobatake A. Mogi S. Matsuzawa T. Jinmei H. Esaki April 1997 ASCII HTML 19 packet flow datalink mapping

This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2129
RFC2130 The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 C. Weider C. Preston K. Simonsen H. Alvestrand R. Atkinson M. Crispin P. Svanberg April 1997 ASCII HTML 31 Internet Architecture Board interoperability

This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to the IAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC6055 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2130
RFC2131 Dynamic Host Configuration Protocol R. Droms March 1997 ASCII HTML 45 DHCP DHCPv4

The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]

RFC1541 RFC3396 RFC4361 RFC5494 RFC6842 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2131 10.17487/RFC2131
RFC2132 DHCP Options and BOOTP Vendor Extensions S. Alexander R. Droms March 1997 ASCII HTML 34 DHCP-BOOTP Dynamic Host Configuration Protocol Bootstrap

This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]

RFC1533 RFC3442 RFC3942 RFC4361 RFC4833 RFC5494 DRAFT STANDARD DRAFT STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2132 10.17487/RFC2132
RFC2133 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens April 1997 ASCII HTML 32 application program interface API Internet Protocol addresses

This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2133
RFC2134 Articles of Incorporation of Internet Society ISOC Board of Trustees April 1997 ASCII HTML 5 ISOC

These are the articles of incorporation of the Internet Society. They are published for the information of the IETF community at the request of the poisson working group. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2134
RFC2135 Internet Society By-Laws ISOC Board of Trustees April 1997 ASCII HTML 9 ISOC

These are the by-laws of the Internet Society, as amended, as of June 1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2135
RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE) P. Vixie Editor S. Thomson Y. Rekhter J. Bound April 1997 ASCII HTML 26 DNS-UPDATE database opcode zone

Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]

RFC1035 RFC3007 RFC4035 RFC4033 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2136 10.17487/RFC2136
RFC2137 Secure Domain Name System Dynamic Update D. Eastlake 3rd April 1997 ASCII HTML 11 SDNSDU DNS digital signatures cryptographic

This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys. [STANDARDS-TRACK]

RFC3007 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2137
RFC2138 Remote Authentication Dial In User Service (RADIUS) C. Rigney A. Rubens W. Simpson S. Willens April 1997 ASCII HTML 65 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

RFC2058 RFC2865 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2138
RFC2139 RADIUS Accounting C. Rigney April 1997 ASCII HTML 25 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC2059 RFC2866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2139
RFC2140 TCP Control Block Interdependence J. Touch April 1997 ASCII HTML 11

This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2140
RFC2141 URN Syntax R. Moats May 1997 ASCII HTML 8 URN-SYNTAX Uniform Resource Names

Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK]

RFC8141 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2141 10.17487/RFC2141
RFC2142 Mailbox Names for Common Services, Roles and Functions D. Crocker May 1997 ASCII HTML 6 MAIL-SERV email internet addresses

This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2142 10.17487/RFC2142
RFC2143 Encapsulating IP with the Small Computer System Interface B. Elliston May 1997 ASCII HTML 5 IP-SCSI SCSI

This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2143
RFC2144 The CAST-128 Encryption Algorithm C. Adams May 1997 ASCII HTML 15 CAST-128

There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2144
RFC2145 Use and Interpretation of HTTP Version Numbers J. C. Mogul R. Fielding J. Gettys H. Frystyk May 1997 ASCII HTML 7

HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC7230 INFORMATIONAL INFORMATIONAL IETF app http 10.17487/RFC2145
RFC2146 U.S. Government Internet Domain Names Federal Networking Council May 1997 ASCII HTML 12 Gov FED.US

This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain ".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1816 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2146
RFC2147 TCP and UDP over IPv6 Jumbograms D. Borman May 1997 ASCII HTML 3 IPv6-Jumbo User Datagram Protocol Terminal Control Internet

IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]

RFC2675 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2147
RFC2148 Deployment of the Internet White Pages Service H. Alvestrand P. Jurg September 1997 ASCII HTML 15 X. 500 data structure naming scheme IWPS

This document describes the way in which the Internet White Pages Service is best exploited using today's experience, today's protocols, today's products and today's procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0015 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2148
RFC2149 Multicast Server Architectures for MARS-based ATM multicasting R. Talpade M. Ammar May 1997 ASCII HTML 18

This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined in RFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used with RFC 2022 based MARS server and clients, without needing any change in their functionality. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2149
RFC2150 Humanities and Arts: Sharing Center Stage on the Internet J. Max W. Stickle October 1997 ASCII HTML 62 informational infrastructure guide introduction

The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

FYI0031 INFORMATIONAL INFORMATIONAL IETF harts 10.17487/RFC2150
RFC2151 A Primer On Internet and TCP/IP Tools and Utilities G. Kessler S. Shepard June 1997 ASCII HTML 52 resource guide user

This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1739 FYI0030 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2151
RFC2152 UTF-7 A Mail-Safe Transformation Format of Unicode D. Goldsmith M. Davis May 1997 ASCII HTML 15 UTF-7

This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641, "Using Unicode with MIME". This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1642 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2152 10.17487/RFC2152
RFC2153 PPP Vendor Extensions W. Simpson May 1997 ASCII HTML 6 PPP-EXT Point-to-Point Protocol

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC1661 RFC1962 RFC5342 RFC7042 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2153
RFC2154 OSPF with Digital Signatures S. Murphy M. Badger B. Wellington June 1997 ASCII HTML 29 OSPF-DIG

This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co-existence with, standard OSPF V2 is described. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2154 10.17487/RFC2154
RFC2155 Definitions of Managed Objects for APPN using SMIv2 B. Clouston B. Moore June 1997 ASCII HTML 124 APPN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

RFC2455 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2155
RFC2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME S. Kille January 1998 ASCII HTML 144 MIXER multipurpose internet mail extensions message transfer protocol

This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]

RFC0987 RFC1026 RFC1138 RFC1148 RFC1327 RFC1495 RFC0822 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2156
RFC2157 Mapping between X.400 and RFC-822/MIME Message Bodies H. Alvestrand January 1998 ASCII HTML 49 mixer multipurpose internet mail extensions

This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer http://www.rfc-editor.org/errata_search.php?rfc=2157 10.17487/RFC2157
RFC2158 X.400 Image Body Parts H. Alvestrand January 1998 ASCII HTML 4 mixer multipurpose internet mail extensions

This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2158
RFC2159 A MIME Body Part for FAX H. Alvestrand January 1998 ASCII HTML 7 mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2159
RFC2160 Carrying PostScript in X.400 and MIME H. Alvestrand January 1998 ASCII HTML 5 mixer multipurpose internet mail extensions

This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2160
RFC2161 A MIME Body Part for ODA H. Alvestrand January 1998 ASCII HTML 5 MIME-ODA mixer multipurpose internet mail extensions

This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2161
RFC2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail C. Allocchio January 1998 ASCII HTML 34 MAP-MAIL mixer multipurpose internet mail extensions mime

The standard referred shortly into this document as "X.400" relates to the ISO/IEC 10021 - CCITT 1984, 1988 and 1992 X.400 Series Recommendations covering the Message Oriented Text Interchange Service (MOTIS). This document covers the Inter Personal Messaging System (IPMS) only. This memo defines an Experimental Protocol for the Internet community.

RFC1405 EXPERIMENTAL EXPERIMENTAL IETF app mixer 10.17487/RFC2162
RFC2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) C. Allocchio January 1998 ASCII HTML 26 DNS-MCGAM mime internet enhanced Relay Multipurpose internet mail extensions x.400 mixer

This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]

RFC1664 RFC3597 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2163
RFC2164 Use of an X.500/LDAP directory to support MIXER address mapping S. Kille January 1998 ASCII HTML 10 lightweight directory access protocol mime internet x,.400 enhanced relay

This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]

RFC1838 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2164
RFC2165 Service Location Protocol J. Veizades E. Guttman C. Perkins S. Kaplan June 1997 ASCII HTML 72 SLP

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

RFC2608 RFC2609 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC2165
RFC2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements D. Bryant P. Brittain June 1997 ASCII HTML 34

This document specifies a set of extensions to RFC 1795 designed to improve the scalability of DLSw clarifications to RFC 1795 in the light of the implementation experience to-date. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2166
RFC2167 Referral Whois (RWhois) Protocol V1.5 S. Williamson M. Kosters D. Blacka J. Singh K. Zeilstra June 1997 ASCII HTML 69 RWHOIS

This memo describes Version 1.5 of the client/server interaction of RWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1714 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2167
RFC2168 Resolution of Uniform Resource Identifiers using the Domain Name System R. Daniel M. Mealling June 1997 ASCII HTML 20

The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.

RFC3401 RFC3402 RFC3403 RFC3404 RFC2915 EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2168
RFC2169 A Trivial Convention for using HTTP in URN Resolution R. Daniel June 1997 ASCII HTML 9

This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2169
RFC2170 Application REQuested IP over ATM (AREQUIPA) W. Almesberger J. Le Boudec P. Oechslin July 1997 ASCII HTML 10 Internet Protocol

This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2170
RFC2171 MAPOS - Multiple Access Protocol over SONET/SDH Version 1 K. Murakami M. Maruyama June 1997 ASCII HTML 9 MAPOS-SONET

This memo documents a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2171
RFC2172 MAPOS Version 1 Assigned Numbers M. Maruyama K. Murakami June 1997 ASCII HTML 3

This memo documents the parameters used in the Multiple Access Protocol over SONET/SDH Version 1. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2172
RFC2173 A MAPOS version 1 Extension - Node Switch Protocol K. Murakami M. Maruyama June 1997 ASCII HTML 6

This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2173
RFC2174 A MAPOS version 1 Extension - Switch-Switch Protocol K. Murakami M. Maruyama June 1997 ASCII HTML 22

This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH) version 1 extension, Switch Switch Protocol which provides dynamic routing for unicast, broadcast, and multicast. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2174
RFC2175 MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing K. Murakami M. Maruyama June 1997 ASCII HTML 6

This memo documents MAPOS 16, a multiple access protocol for transmission of network-protocol datagrams, encapsulated in HDLC frames with 16 bit addressing, over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2175
RFC2176 IPv4 over MAPOS Version 1 K. Murakami M. Maruyama June 1997 ASCII HTML 6 IPV4-MAPOS

This memo documents a mechanism for supporting Version 4 of the Internet Protocol (IPv4) on Version 1 of the Multiple Access Protocol over SONET/SDH. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC5494 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2176
RFC2177 IMAP4 IDLE command B. Leiba June 1997 ASCII HTML 4 IMAP4-IDLE

This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2177
RFC2178 OSPF Version 2 J. Moy July 1997 ASCII HTML 211 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree.

OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. [STANDARDS-TRACK]

RFC1583 RFC2328 DRAFT STANDARD DRAFT STANDARD IETF rtg ospf 10.17487/RFC2178
RFC2179 Network Security For Trade Shows A. Gwinn July 1997 ASCII HTML 10 network system attacks

This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2179
RFC2180 IMAP4 Multi-Accessed Mailbox Practice M. Gahrns July 1997 ASCII HTML 14 Internet Message Access Protocol Client Server

The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2180
RFC2181 Clarifications to the DNS Specification R. Elz R. Bush July 1997 ASCII HTML 14 DNS-CLAR Domain Name System

This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]

RFC1034 RFC1035 RFC1123 RFC4035 RFC2535 RFC4343 RFC4033 RFC4034 RFC5452 RFC8767 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2181
RFC2182 Selection and Operation of Secondary DNS Servers R. Elz R. Bush S. Bradner M. Patton July 1997 ASCII HTML 11 Domain Name System delegated zone

This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

BCP0016 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2182 10.17487/RFC2182
RFC2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field R. Troost S. Dorner K. Moore Editor August 1997 ASCII HTML 12 inline attachment MIME Mail Multimedia EMail

This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content- Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). [STANDARDS-TRACK]

RFC1806 RFC2184 RFC2231 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2183 10.17487/RFC2183
RFC2184 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore August 1997 ASCII HTML 9 mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]

RFC2231 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2184 10.17487/RFC2184
RFC2185 Routing Aspects of IPv6 Transition R. Callon D. Haskin September 1997 ASCII HTML 13 address network tunneling

This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document "Transition Mechanisms for IPv6 Hosts and Routers." Readers should be familiar with the transition mechanisms before reading this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2185
RFC2186 Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII HTML 9 ICP www web http hypertext transfer protocol

This document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2186
RFC2187 Application of Internet Cache Protocol (ICP), version 2 D. Wessels K. Claffy September 1997 ASCII HTML 24 web www url uniform resource identifier

This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFC2186) to Web caching. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2187
RFC2188 AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 M. Banan M. Taylor J. Cheng September 1997 ASCII HTML 57 ESRO RPC Remote Procedure Call Wireless

This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2188
RFC2189 Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- A. Ballardie September 1997 ASCII HTML 23 Inter-Domain-Protocol IDMR

This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2189
RFC2190 RTP Payload Format for H.263 Video Streams C. Zhu September 1997 ASCII HTML 12 real-time transfer

This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

HISTORIC PROPOSED STANDARD IETF rai avt 10.17487/RFC2190
RFC2191 VENUS - Very Extensive Non-Unicast Service G. Armitage September 1997 ASCII HTML 12 multicast IP ATM

This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service" (VENUS), and shows how complex such a service would be. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2191
RFC2192 IMAP URL Scheme C. Newman September 1997 ASCII HTML 16 IMAP-URL Internet Message Access Protocol Uniform Resource Identifiers

This document defines a URL scheme for referencing objects on an IMAP server. [STANDARDS-TRACK]

RFC5092 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2192 10.17487/RFC2192
RFC2193 IMAP4 Mailbox Referrals M. Gahrns September 1997 ASCII HTML 9 IMAP4MAIL Internet Mail Access Protocol messages

Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2193
RFC2194 Review of Roaming Implementations B. Aboba J. Lu J. Alsop J. Ding W. Wang September 1997 ASCII HTML 35 ISP Internet Server Provider

This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2194
RFC2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response J. Klensin R. Catoe P. Krumviede September 1997 ASCII HTML 5 IMAPPOPAU Post Office Protocol Internet Message Access

This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. [STANDARDS-TRACK]

RFC2095 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2195
RFC2196 Site Security Handbook B. Fraser September 1997 ASCII HTML 75

This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC1244 FYI0008 INFORMATIONAL INFORMATIONAL IETF ssh http://www.rfc-editor.org/errata_search.php?rfc=2196 10.17487/RFC2196
RFC2197 SMTP Service Extension for Command Pipelining N. Freed September 1997 ASCII HTML 8 SMTP-Pipe simple mail transfer TCP transmission control protocol

This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. [STANDARDS-TRACK]

RFC1854 RFC2920 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2197
RFC2198 RTP Payload for Redundant Audio Data C. Perkins I. Kouvelas O. Hodson V. Hardman M. Handley J.C. Bolot A. Vega-Garcia S. Fosse-Parisis September 1997 ASCII HTML 11 RTP-RAD

This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]

RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2198
RFC2199 Request for Comments Summary RFC Numbers 2100-2199 A. Ramos January 1998 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2199 RFC2200 Internet Official Protocol Standards J. Postel June 1997 ASCII HTML 39 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC1250 RFC2000 RFC2300 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2200
RFC2201 Core Based Trees (CBT) Multicast Routing Architecture A. Ballardie September 1997 ASCII HTML 15 IP Internet Protocol IDMR Inter-Domain

CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. This memo defines an Experimental Protocol for the Internet community.

HISTORIC EXPERIMENTAL IETF rtg idmr 10.17487/RFC2201
RFC2202 Test Cases for HMAC-MD5 and HMAC-SHA-1 P. Cheng R. Glenn September 1997 ASCII HTML 9 Hash Message Authentications Codes message digest secure

This document provides two sets of test cases for HMAC-MD5 and HMAC- SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2202 10.17487/RFC2202
RFC2203 RPCSEC_GSS Protocol Specification M. Eisler A. Chiu L. Ling September 1997 ASCII HTML 23 RPCSEC-GSS Remote Procedure Call Generic Security Services API Application Programming Interface

This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). [STANDARDS-TRACK]

RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv oncrpc http://www.rfc-editor.org/errata_search.php?rfc=2203 10.17487/RFC2203
RFC2204 ODETTE File Transfer Protocol D. Nash September 1997 ASCII HTML 74 ODETTE FTP Internet Motor Industry data exchange

This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC5024 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2204
RFC2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification R. Braden Editor L. Zhang S. Berson S. Herzog S. Jamin September 1997 ASCII HTML 112 RSVP integrated services multicast unicast QoS signaling

This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]

RFC2750 RFC3936 RFC4495 RFC5946 RFC6437 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2205 10.17487/RFC2205
RFC2206 RSVP Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII HTML 64 RSVP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2206
RFC2207 RSVP Extensions for IPSEC Data Flows L. Berger T. O'Malley September 1997 ASCII HTML 14 RSVP-IPSEC resource reservation QoS IP Security

This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IP Authentication Header (AH) or RFC 1827, IP Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2207
RFC2208 Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment A. Mankin Editor F. Baker B. Braden S. Bradner M. O'Dell A. Romanow A. Weinrib L. Zhang September 1997 ASCII HTML 6 RSVP

This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv rsvp 10.17487/RFC2208
RFC2209 Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules R. Braden L. Zhang September 1997 ASCII HTML 25 RSVP-MPR QoS implementation algorithms

This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2209 10.17487/RFC2209
RFC2210 The Use of RSVP with IETF Integrated Services J. Wroclawski September 1997 ASCII HTML 33 RSVP-IS Resource Reservation Controlled Load QOS: Quality of Service

This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2210
RFC2211 Specification of the Controlled-Load Network Element Service J. Wroclawski September 1997 ASCII HTML 19 QOS: Quality of Service integrated services

This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2211
RFC2212 Specification of Guaranteed Quality of Service S. Shenker C. Partridge R. Guerin September 1997 ASCII HTML 20 GQOS QOS quality of service integrated services

This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2212
RFC2213 Integrated Services Management Information Base using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII HTML 21 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv http://www.rfc-editor.org/errata_search.php?rfc=2213 10.17487/RFC2213
RFC2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 F. Baker J. Krawczyk A. Sastry September 1997 ASCII HTML 9 MIB attributes interface network protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2214
RFC2215 General Characterization Parameters for Integrated Service Network Elements S. Shenker J. Wroclawski September 1997 ASCII HTML 16 QOS Quality of service

This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC2215
RFC2216 Network Element Service Specification Template S. Shenker J. Wroclawski September 1997 ASCII HTML 22 QOS Quality of Service Control

This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv intserv 10.17487/RFC2216
RFC2217 Telnet Com Port Control Option G. Clark October 1997 ASCII HTML 14 TOPT-COMPORT remote login host

This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2217 10.17487/RFC2217
RFC2218 A Common Schema for the Internet White Pages Service T. Genovese B. Jennings October 1997 ASCII HTML 8 IWPS information user

This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app ids 10.17487/RFC2218
RFC2219 Use of DNS Aliases for Network Services M. Hamilton R. Wright October 1997 ASCII HTML 8 domain name system symbolic

It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC- 1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0017 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ids 10.17487/RFC2219
RFC2220 The Application/MARC Content-type R. Guenther October 1997 ASCII HTML 4 APP-MARC media-type machine readable cataloging records

This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2220
RFC2221 IMAP4 Login Referrals M. Gahrns October 1997 ASCII HTML 5 IMAP4LOGIN Internet Message Access Protocol server

When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2221
RFC2222 Simple Authentication and Security Layer (SASL) J. Myers October 1997 ASCII HTML 16 SASL encryption protocol specific

This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]

RFC4422 RFC4752 RFC2444 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2222 10.17487/RFC2222
RFC2223 Instructions to RFC Authors J. Postel J. Reynolds October 1997 ASCII HTML 20 Request For Comment

This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

RFC1543 RFC1111 RFC0825 RFC7322 RFC5741 RFC6949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2223
RFC2224 NFS URL Scheme B. Callaghan October 1997 ASCII HTML 11 NFS-URL Universal Resource Locators Network File System syntax directories

A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, "Uniform Resource Locators (URL)". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2224
RFC2225 Classical IP and ARP over ATM M. Laubach J. Halpern April 1998 ASCII HTML 28 IP-ATM Internet protocol address resolution asynchronous,transfer mode

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]

RFC1626 RFC1577 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2225
RFC2226 IP Broadcast over ATM Networks T. Smith G. Armitage October 1997 ASCII HTML 14 Internet Protocol Asynchronous Transfer Mode

This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2226
RFC2227 Simple Hit-Metering and Usage-Limiting for HTTP J. Mogul P. Leach October 1997 ASCII HTML 37 Hypertext Transfer Protocol extension

This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app http 10.17487/RFC2227
RFC2228 FTP Security Extensions M. Horowitz S. Lunt October 1997 ASCII HTML 27 FTPSECEXT file transfer protocol authentication encoding

This document defines extensions to the FTP specification STD 9, RFC

RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2228
RFC2229 A Dictionary Server Protocol R. Faith B. Martin October 1997 ASCII HTML 30 DSP DICT TCP Transmission Control Protocol database definitions

The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2229 10.17487/RFC2229
RFC2230 Key Exchange Delegation Record for the DNS R. Atkinson November 1997 ASCII HTML 11 KEYX-DNS Domain Name System RR Resource Record KX

This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2230
RFC2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations N. Freed K. Moore November 1997 ASCII HTML 10 MIME-EXT Mail Multimedia EMail

This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]

RFC2184 RFC2045 RFC2047 RFC2183 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2231 10.17487/RFC2231
RFC2232 Definitions of Managed Objects for DLUR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII HTML 21 DLUR-MIB Management Information Base MIB Dependent LU Requester APPN Advanced Peek to Peek Networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2232
RFC2233 The Interfaces Group MIB using SMIv2 K. McCloghrie F. Kastenholz November 1997 ASCII HTML 66 INTERGRMIB Management Information Base Network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. [STANDARDS-TRACK]

RFC1573 RFC2863 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2233
RFC2234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell November 1997 ASCII HTML 14 ABNF Augmented Backus-Naur Form electronic mail

In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]

RFC4234 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2234 10.17487/RFC2234
RFC2235 Hobbes' Internet Timeline R. Zakon November 1997 ASCII HTML 22 events technologies history

This document presents a history of the Internet in timeline fashion, highlighting some of the key events and technologies which helped shape the Internet as we know it today. A growth summary of the Internet and some associated technologies is also included. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

FYI0032 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2235
RFC2236 Internet Group Management Protocol, Version 2 W. Fenner November 1997 ASCII HTML 24 IGMP IGMP multicast routing IP Internet Protocol

This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. [STANDARDS-TRACK]

RFC1112 RFC3376 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2236 10.17487/RFC2236
RFC2237 Japanese Character Encoding for Internet Messages K. Tamaru November 1997 ASCII HTML 6 eletronic mail character set scheme

This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2237
RFC2238 Definitions of Managed Objects for HPR using SMIv2 B. Clouston Editor B. Moore Editor November 1997 ASCII HTML 35 HPR-MIB MIB Management Information Base high performance routing

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2238
RFC2239 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts November 1997 ASCII HTML 43 MAUS-MIB

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing 10 and 100 Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30, "10 & 100 Mb/s Management," October 26, 1995. [STANDARDS-TRACK]

RFC2668 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2239
RFC2240 A Legal Basis for Domain Name Allocation O. Vaughan November 1997 ASCII HTML 7 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2352 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2240
RFC2241 DHCP Options for Novell Directory Services D. Provan November 1997 ASCII HTML 5 DHCP-NDS NDS

This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. This document defines three new DHCP options for delivering configuration information to clients of the Novell Directory Services. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2241
RFC2242 NetWare/IP Domain Name and Information R. Droms K. Fong November 1997 ASCII HTML 6 NETWAREIP DHCP

This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2242
RFC2243 OTP Extended Responses C. Metz November 1997 ASCII HTML 10 OTP-ER One Time Password

This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2243
RFC2244 ACAP -- Application Configuration Access Protocol C. Newman J. G. Myers November 1997 ASCII HTML 71 ACAP URL Uniform Resource Locator

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. [STANDARDS-TRACK]

RFC6075 PROPOSED STANDARD PROPOSED STANDARD IETF app acap http://www.rfc-editor.org/errata_search.php?rfc=2244 10.17487/RFC2244
RFC2245 Anonymous SASL Mechanism C. Newman November 1997 ASCII HTML 5 SASL-ANON Simple Authentication Security Layer

As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. [STANDARDS-TRACK]

RFC4505 PROPOSED STANDARD PROPOSED STANDARD IETF app acap 10.17487/RFC2245
RFC2246 The TLS Protocol Version 1.0 T. Dierks C. Allen January 1999 ASCII HTML 80 transport protocol layer authentication privacy

This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

RFC4346 RFC3546 RFC5746 RFC6176 RFC7465 RFC7507 RFC7919 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2246 10.17487/RFC2246
RFC2247 Using Domains in LDAP/X.500 Distinguished Names S. Kille M. Wahl A. Grimstad R. Huber S. Sataluri January 1998 ASCII HTML 7 lightweight directory access protocol DNS Domain name system

This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]

RFC4519 RFC4524 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2247
RFC2248 Network Services Monitoring MIB N. Freed S. Kille January 1998 ASCII HTML 19 NSM-MIB Management Information Base SNMP Simple Network Management Protocol

This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]

RFC1565 RFC2788 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2248
RFC2249 Mail Monitoring MIB N. Freed S. Kille January 1998 ASCII HTML 28 MAIL-MIB Management Information Base Message Transfer Agents

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [STANDARDS-TRACK]

RFC1566 RFC2789 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2249
RFC2250 RTP Payload Format for MPEG1/MPEG2 Video D. Hoffman G. Fernando V. Goyal M. Civanlar January 1998 ASCII HTML 16 RTP-MPEG Real-Time Transport Protocol Audio System Streams

This memo describes a packetization scheme for MPEG video and audio streams. [STANDARDS-TRACK] The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2038 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2250 10.17487/RFC2250
RFC2251 Lightweight Directory Access Protocol (v3) M. Wahl T. Howes S. Kille December 1997 ASCII HTML 50 LDAPV3 LDAv3 x.500

The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

RFC4510 RFC4511 RFC4513 RFC4512 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2251
RFC2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions M. Wahl A. Coulbeck T. Howes S. Kille December 1997 ASCII HTML 32 LDAP3-ATD LDAv3 x.500 syntax

This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]

RFC4510 RFC4517 RFC4523 RFC4512 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2252 10.17487/RFC2252
RFC2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names M. Wahl S. Kille T. Howes December 1997 ASCII HTML 10 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

RFC1779 RFC4510 RFC4514 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2253 10.17487/RFC2253
RFC2254 The String Representation of LDAP Search Filters T. Howes December 1997 ASCII HTML 8 STR-LDAP LDAPv3 x.500 ASN.1 string format

This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]

RFC1960 RFC4510 RFC4515 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2254 10.17487/RFC2254
RFC2255 The LDAP URL Format T. Howes M. Smith December 1997 ASCII HTML 10 LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]

RFC1959 RFC4510 RFC4516 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2255
RFC2256 A Summary of the X.500(96) User Schema for use with LDAPv3 M. Wahl December 1997 ASCII HTML 20 Lightweight Directory Access Protocol syntax

This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS-TRACK]

RFC4517 RFC4519 RFC4523 RFC4512 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2256
RFC2257 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen D. Francisco January 1998 ASCII HTML 80 AGENTX SNMP Simple Network Management Protocol MIB Information Base

This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]

RFC2741 PROPOSED STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2257
RFC2258 Internet Nomenclator Project J. Ordille January 1998 ASCII HTML 15 Database Server CCSO Computer Communications Services Office

The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2258
RFC2259 Simple Nomenclator Query Protocol (SNQP) J. Elliott J. Ordille January 1998 ASCII HTML 30 SNQP Data Repositories Client Server

The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2259
RFC2260 Scalable Support for Multi-homed Multi-provider Connectivity T. Bates Y. Rekhter January 1998 ASCII HTML 12 ISP Internet Service Provider Routing

This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2260 10.17487/RFC2260
RFC2261 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

RFC2271 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2261
RFC2262 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 39 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

RFC2272 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2262
RFC2263 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII HTML 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

RFC2273 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2263
RFC2264 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII HTML 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

RFC2274 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2264
RFC2265 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII HTML 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

RFC2275 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 10.17487/RFC2265
RFC2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices J. Flick January 1998 ASCII HTML 56 MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network repeaters based on IEEE 802.12. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int vgmib 10.17487/RFC2266
RFC2267 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie January 1998 ASCII HTML 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2827 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2267
RFC2268 A Description of the RC2(r) Encryption Algorithm R. Rivest March 1998 ASCII HTML 11 RC2-ENCRP encryption secre key rsa

This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2268 10.17487/RFC2268
RFC2269 Using the MARS Model in non-ATM NBMA Networks G. Armitage January 1998 ASCII HTML 6 Asynchronous Transfer Mode Multicast Address Resolution Server IP Internet Protocol

This document is intended to state the obvious equivalences, and explain the less obvious implications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2269
RFC2270 Using a Dedicated AS for Sites Homed to a Single Provider J. Stewart T. Bates R. Chandra E. Chen January 1998 ASCII HTML 6 Autonomous System BGP4 Border Gateway Protocol ISP Internet Service

With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2270
RFC2271 An Architecture for Describing SNMP Management Frameworks D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 56 Simple Network Management Protocol Message Network Management Protocol security access control snmpv3

This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. [STANDARDS-TRACK]

RFC2261 RFC2571 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2271
RFC2272 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen January 1998 ASCII HTML 39 SNMPv3 architecture SNMPv3 multiple versions

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

RFC2262 RFC2572 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2272
RFC2273 SNMPv3 Applications D. Levi P. Meyer B. Stewart January 1998 ASCII HTML 70 Simple Network Management Protocol operations notification filtering proxy forwarding

This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. [STANDARDS-TRACK]

RFC2263 RFC2573 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2273
RFC2274 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen January 1998 ASCII HTML 76 architecture message level

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

RFC2264 RFC2574 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2274
RFC2275 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie January 1998 ASCII HTML 36 SNMPV3 Architecture

This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

RFC2265 RFC2575 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2275
RFC2276 Architectural Principles of Uniform Resource Name Resolution K. Sollins January 1998 ASCII HTML 24 URCs URN URLs Uniform Resource Locators Characteristics

This document addresses the issues of the discovery of URN (Uniform Resource Name) resolver services that in turn will directly translate URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource Characteristics). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC3401 INFORMATIONAL INFORMATIONAL IETF app urn 10.17487/RFC2276
RFC2277 IETF Policy on Character Sets and Languages H. Alvestrand January 1998 ASCII HTML 9 charset

This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0018 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2277 10.17487/RFC2277
RFC2278 IANA Charset Registration Procedures N. Freed J. Postel January 1998 ASCII HTML 10 character set mime multipurpose internet mail extensions

MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2978 INFORMATIONAL BEST CURRENT PRACTICE Legacy 10.17487/RFC2278
RFC2279 UTF-8, a transformation format of ISO 10646 F. Yergeau January 1998 ASCII HTML 10 UTF-8 UCS Transformation Format

UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]

RFC2044 RFC3629 DRAFT STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2279
RFC2280 Routing Policy Specification Language (RPSL) C. Alaettinoglu T. Bates E. Gerich D. Karrenberg D. Meyer M. Terpstra C. Villamizar January 1998 ASCII HTML 53 RPSL network operator AS autonomous system database

This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

RFC2622 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2280
RFC2281 Cisco Hot Standby Router Protocol (HSRP) T. Li B. Cole P. Morton D. Li March 1998 ASCII HTML 17 HSRP

The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2281 10.17487/RFC2281
RFC2282 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 1998 ASCII HTML 14 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2027 RFC2727 INFORMATIONAL BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2282
RFC2283 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter February 1998 ASCII HTML 9 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

RFC2858 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2283
RFC2284 PPP Extensible Authentication Protocol (EAP) L. Blunk J. Vollbrecht March 1998 ASCII HTML 15 PPP-EAP point-to-point authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. [STANDARDS-TRACK]

RFC3748 RFC2484 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2284
RFC2285 Benchmarking Terminology for LAN Switching Devices R. Mandeville February 1998 ASCII HTML 25 local area network MAC Medium Access Control layer

This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2285
RFC2286 Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128 J. Kapp February 1998 ASCII HTML 7 has authentication message IP Internet Protocol codes

This document provides two sets of test cases for HMAC-RIPEMD160 and HMAC-RIPEMD128. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2286 10.17487/RFC2286
RFC2287 Definitions of System-Level Managed Objects for Applications C. Krupczak J. Saperia February 1998 ASCII HTML 44 SLM-APP mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2287
RFC2288 Using Existing Bibliographic Identifiers as Uniform Resource Names C. Lynch C. Preston R. Daniel February 1998 ASCII HTML 10 URNs Syntax framework

This document discusses how three major bibliographic identifiers (the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2288 10.17487/RFC2288
RFC2289 A One-Time Password System N. Haller C. Metz P. Nesser M. Straw February 1998 ASCII HTML 25 ONE-PASS authentication OTP replay attach

This document describes a one-time password authentication system (OTP). The system provides authentication for system access (login) and other applications requiring authentication that is secure against passive attacks based on replaying captured reusable passwords. [STANDARDS-TRACK]

RFC1938 STD0061 INTERNET STANDARD DRAFT STANDARD IETF sec otp 10.17487/RFC2289
RFC2290 Mobile-IPv4 Configuration Option for PPP IPCP J. Solomon S. Glass February 1998 ASCII HTML 17 Internet protocol point-to-point control address

Mobile IP [RFC 2002] defines media-independent procedures by which a Mobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point-to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to the Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP [RFC 1332], and PPP [RFC 1661] is assumed. [STANDARDS-TRACK]

RFC2002 RFC2794 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2290
RFC2291 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web J. Slein F. Vitali E. Whitehead D. Durand February 1998 ASCII HTML 21 WWW remote editing locking mechanism

This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app webdav 10.17487/RFC2291
RFC2292 Advanced Sockets API for IPv6 W. Stevens M. Thomas February 1998 ASCII HTML 67 application program interface

The current document defines some the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC3542 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2292
RFC2293 Representing Tables and Subtrees in the X.500 Directory S. Kille March 1998 ASCII HTML 8 SUBTABLE mapping distinguished name

This document defines techniques for representing two types of information mapping in the OSI Directory: Mapping from a key to a value (or set of values), as might be done in a table lookup, and mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. [STANDARDS-TRCK]

RFC1837 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2293
RFC2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree S. Kille March 1998 ASCII HTML 13 OR-ADD routing mapping dit

This document defines a representation of the O/R Address hierarchy in the Directory Information Tree. [STANDARDS-TRACK]

RFC1836 PROPOSED STANDARD PROPOSED STANDARD IETF app mixer 10.17487/RFC2294
RFC2295 Transparent Content Negotiation in HTTP K. Holtman A. Mutz March 1998 ASCII HTML 58 TCN-HTTP Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2295
RFC2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 K. Holtman A. Mutz March 1998 ASCII HTML 13 HTTP-RVSA Hyper Text Transfer protocol URL Uniform Resource Locators

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2296 10.17487/RFC2296
RFC2297 Ipsilon's General Switch Management Protocol Specification Version 2.0 P. Newman W. Edwards R. Hinden E. Hoffman F. Ching Liaw T. Lyon G. Minshall March 1998 ASCII HTML 109 GSMP gsmp atm asynchronous transfer mode

This memo specifies enhancements to the General Switch Management Protocol (GSMP) [RFC1987]. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC1987 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2297
RFC2298 An Extensible Message Format for Message Disposition Notifications R. Fajman March 1998 ASCII HTML 28 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. [STANDARDS-TRACK]

RFC3798 PROPOSED STANDARD PROPOSED STANDARD IETF app receipt 10.17487/RFC2298
RFC2299 Request for Comments Summary A. Ramos January 1999 ASCII HTML 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2299 RFC2300 Internet Official Protocol Standards J. Postel May 1998 ASCII HTML 59 IAB official protocol standards

A discussion of the standardization process and the RFC document series is presented first, followed by an explanation of the terms. Sections 6.2 - 6.10 contain the lists of protocols in each stage of standardization. Finally are pointers to references and contacts for further information. [STANDARDS-TRACK]

RFC2200 RFC2400 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2300
RFC2301 File Format for Internet Fax L. McIntyre S. Zilles R. Buckley D. Venable G. Parsons J. Rafferty March 1998 ASCII HTML 77 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. [STANDARDS-TRACK]

RFC3949 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2301
RFC2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty S. Zilles March 1998 ASCII HTML 8 TIFF Multipurpose Internet Mail extensions

This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]

RFC3302 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2302
RFC2303 Minimal PSTN address format in Internet Mail C. Allocchio March 1998 ASCII HTML 8 MIN-PSTN e-mail service

This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]

RFC3191 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2303
RFC2304 Minimal FAX address format in Internet Mail C. Allocchio March 1998 ASCII HTML 8 MINFAX-IM encoding facsimile e-mail

This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]

RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2304
RFC2305 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing March 1998 ASCII HTML 13 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]

RFC3965 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2305
RFC2306 Tag Image File Format (TIFF) - F Profile for Facsimile G. Parsons J. Rafferty March 1998 ASCII HTML 25 file format storage

This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2306
RFC2307 An Approach for Using LDAP as a Network Information Service L. Howard March 1998 ASCII HTML 21 LDAP-NIS lightweight directory access protocol unix mapping

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2307 10.17487/RFC2307
RFC2308 Negative Caching of DNS Queries (DNS NCACHE) M. Andrews March 1998 ASCII HTML 19 DNS-NCACHE Domain Name System negative

RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]

RFC1034 RFC1035 RFC4035 RFC4033 RFC4034 RFC6604 RFC8020 RFC8499 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2308 10.17487/RFC2308
RFC2309 Recommendations on Queue Management and Congestion Avoidance in the Internet B. Braden D. Clark J. Crowcroft B. Davie S. Deering D. Estrin S. Floyd V. Jacobson G. Minshall C. Partridge L. Peterson K. Ramakrishnan S. Shenker J. Wroclawski L. Zhang April 1998 ASCII HTML 17 performance router deployment

This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC7567 RFC7141 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2309
RFC2310 The Safe Response Header Field K. Holtman April 1998 ASCII HTML 5 http hyper text transfer protocol

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF app http 10.17487/RFC2310
RFC2311 S/MIME Version 2 Message Specification S. Dusse P. Hoffman B. Ramsdell L. Lundblade L. Repka March 1998 ASCII HTML 37 SMIME-MSG secure multipurpose internet mail extensions

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC2311
RFC2312 S/MIME Version 2 Certificate Handling S. Dusse P. Hoffman B. Ramsdell J. Weinstein March 1998 ASCII HTML 20 SMIME-CERT secure multipurpose internet mail extensions

This memo describes the mechanisms S/MIME uses to create and validate keys using certificates. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

HISTORIC INFORMATIONAL Legacy 10.17487/RFC2312
RFC2313 PKCS #1: RSA Encryption Version 1.5 B. Kaliski March 1998 ASCII HTML 19 PKCS-1 data public key cryptosystem

This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2437 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2313
RFC2314 PKCS #10: Certification Request Syntax Version 1.5 B. Kaliski March 1998 ASCII HTML 8 PKCS-10 public key distinguished name encryption data

This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2986 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2314
RFC2315 PKCS #7: Cryptographic Message Syntax Version 1.5 B. Kaliski March 1998 ASCII HTML 32 PKCS-7 data authentication PEM privacy enhanced mail

This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2315
RFC2316 Report of the IAB Security Architecture Workshop S. Bellovin April 1998 ASCII HTML 9 Internet Board protocols tools

On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2316
RFC2317 Classless IN-ADDR.ARPA delegation H. Eidnes G. de Groot P. Vixie March 1998 ASCII HTML 10 routing mapping addresses zone files

This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0020 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2317 10.17487/RFC2317
RFC2318 The text/css Media Type H. Lie B. Bos C. Lilley March 1998 ASCII HTML 5 TEXT-CSS MIME multipurpose Internet mail extension

This memo provides information about the text/css Media Type. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2318
RFC2319 Ukrainian Character Set KOI8-U KOI8-U Working Group April 1998 ASCII HTML 9 KOI8-U encoding mail information resources

This document provides information about character encoding KOI8-U (KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=2319 10.17487/RFC2319
RFC2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) M. Greene J. Luciani K. White T. Kuo April 1998 ASCII HTML 52 IPOA-MIB management information base internet protocol address resolution asynchronous transfer mode

The purpose of this memo is to define the Management Information Base (MIB) for supporting Classical IP and ARP over ATM as specified in Classical IP and ARP over ATM. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2320
RFC2321 RITA -- The Reliable Internetwork Troubleshooting Agent A. Bressen April 1 1998 ASCII HTML 6 networking environments

A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2321
RFC2322 Management of IP numbers by peg-dhcp K. van den Hout A. Koopal R. van Mook April 1 1998 ASCII HTML 7 Internet Protocol HIP Hacking in progress

This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2322 10.17487/RFC2322
RFC2323 IETF Identification and Security Guidelines A. Ramos April 1 1998 ASCII HTML 5 facial hairius extremis FHE

This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2323
RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) L. Masinter April 1 1998 ASCII HTML 10 controlling monitoring diagnosing

This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC7168 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2324 10.17487/RFC2324
RFC2325 Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 M. Slavitch April 1 1998 ASCII HTML 8 MIB management information base coffee brewing

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2325 10.17487/RFC2325
RFC2326 Real Time Streaming Protocol (RTSP) H. Schulzrinne A. Rao R. Lanphier April 1998 ASCII HTML 92 RTSP audio video data delivery application level,

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. [STANDARDS-TRACK]

RFC7826 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2326 10.17487/RFC2326
RFC2327 SDP: Session Description Protocol M. Handley V. Jacobson April 1998 ASCII HTML 42 SDP mbone internet multicast backbone multimedia

This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]

RFC4566 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=2327 10.17487/RFC2327
RFC2328 OSPF Version 2 J. Moy April 1998 ASCII HTML 244 OSPF2 Open Shortest Path First routing Autonomous system AS

This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]

RFC2178 RFC5709 RFC6549 RFC6845 RFC6860 RFC7474 RFC8042 STD0054 INTERNET STANDARD INTERNET STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2328 10.17487/RFC2328
RFC2329 OSPF Standardization Report J. Moy April 1998 ASCII HTML 9 open shortest path first

This memo documents how the requirements for advancing a routing protocol to Full Standard have been met for OSPFv2. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC2329
RFC2330 Framework for IP Performance Metrics V. Paxson G. Almes J. Mahdavi M. Mathis May 1998 ASCII HTML 40 Internet Protocol measurement statistics

The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC7312 RFC8468 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC2330
RFC2331 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update M. Maher April 1998 ASCII HTML 26 UNI-SIG asynchronous transfer mode internet protocol

This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 to support IP over ATM environments as described in RFC 2225 and in RFC 2332. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2331
RFC2332 NBMA Next Hop Resolution Protocol (NHRP) J. Luciani D. Katz D. Piscitello B. Cole N. Doraswamy April 1998 ASCII HTML 52 NHRP internetworking layer address subnetwork multiprotocol non-broadcast multiple access

This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP can be used by a source station (host or router) connected to a Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the "NBMA next hop" towards a destination station. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2332
RFC2333 NHRP Protocol Applicability Statement D. Cansever April 1998 ASCII HTML 9 next hop resolution protocol routing internet protocol

As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol (NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access (NBMA) networks, such as ATM, SMDS and X.25. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2333
RFC2334 Server Cache Synchronization Protocol (SCSP) J. Luciani G. Armitage J. Halpern N. Doraswamy April 1998 ASCII HTML 40 SCSP cache synchronization replication NBMA non broadcast multiple access

This document describes the Server Cache Synchronization Protocol (SCSP) and is written in terms of SCSP's use within Non Broadcast Multiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2334 10.17487/RFC2334
RFC2335 A Distributed NHRP Service Using SCSP J. Luciani April 1998 ASCII HTML 7 NHRP-SCSP next hop resolution protocol server cache sychronization protocol

This document describes a method for distributing an NHRP service within a LIS. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2335
RFC2336 Classical IP and ARP over ATM to NHRP Transition J. Luciani July 1998 ASCII HTML 5

This document describes methods and procedures for the graceful transition from an ATMARP LIS to an NHRP LIS network model over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2336
RFC2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM D. Farinacci D. Meyer Y. Rekhter April 1998 ASCII HTML 8 internet protocol asynchronous transfer mode

This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2337
RFC2338 Virtual Router Redundancy Protocol S. Knight D. Weaver D. Whipple R. Hinden D. Mitzel P. Hunt P. Higginson M. Shand A. Lindem April 1998 ASCII HTML 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. [STANDARDS-TRACK]

RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2338
RFC2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols The Internet Society Sun Microsystems May 1998 ASCII HTML 5 ISOC network file system internet engineering task force

This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2339
RFC2340 Nortel's Virtual Network Switching (VNS) Overview B. Jamoussi D. Jamieson D. Williston S. Gabe May 1998 ASCII HTML 14 routing packet switching multi-protocol

This document provides an overview of Virtual Network Switching (VNS). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2340
RFC2341 Cisco Layer Two Forwarding (Protocol) "L2F" A. Valencia M. Littlewood T. Kolar May 1998 ASCII HTML 29 L2F tunneling dial-up network

This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind.

HISTORIC HISTORIC Legacy 10.17487/RFC2341
RFC2342 IMAP4 Namespace M. Gahrns C. Newman May 1998 ASCII HTML 10 IMAP4NAME internet message access protocol mailbox

This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS-TRACK]

RFC4466 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2342
RFC2343 RTP Payload Format for Bundled MPEG M. Civanlar G. Cash B. Haskell May 1998 ASCII HTML 8 RTP-MPEG real-time transport protocol audio video

This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2343
RFC2344 Reverse Tunneling for Mobile IP G. Montenegro Editor May 1998 ASCII HTML 19 MOBILIPREV internet protocol extensions home foreign agent encapsulating delivery style

This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. [STANDARDS-TRACK]

RFC3024 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2344
RFC2345 Domain Names and Company Name Retrieval J. Klensin T. Wolf G. Oglesby May 1998 ASCII HTML 14 URL mapping service whois dns

This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2345
RFC2346 Making Postscript and PDF International J. Palme May 1998 ASCII HTML 6 portable document format document

Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable Document Format (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world. North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2346
RFC2347 TFTP Option Extension G. Malkin A. Harkin May 1998 ASCII HTML 7 TFTP-Ext trivial file transfer booting client server

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a simple extension to TFTP to allow option negotiation prior to the file transfer. [STANDARDS-TRACK]

RFC1782 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2347 10.17487/RFC2347
RFC2348 TFTP Blocksize Option G. Malkin A. Harkin May 1998 ASCII HTML 5 TFTP-Blk trivial file transfer booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. [STANDARDS-TRACK]

RFC1783 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2348
RFC2349 TFTP Timeout Interval and Transfer Size Options G. Malkin A. Harkin May 1998 ASCII HTML 5 TFTP-Opt trivial file transfer booting client server extension

The Trivial File Transfer Protocol is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. This document describes two TFTP options. [STANDARDS-TRACK]

RFC1784 RFC1350 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2349
RFC2350 Expectations for Computer Security Incident Response N. Brownlee E. Guttman June 1998 ASCII HTML 38 CSIRT guidelines user BCP0021 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip http://www.rfc-editor.org/errata_search.php?rfc=2350 10.17487/RFC2350 RFC2351 Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP A. Robert May 1998 ASCII HTML 23 internet protocol encapsulation transactional traffic messaging

This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2351
RFC2352 A Convention For Using Legal Names as Domain Names O. Vaughan May 1998 ASCII HTML 8 DNS

The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC2240 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2352
RFC2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document G. Dudley May 1998 ASCII HTML 48 internet protocol advanced peer-to-peer networking high performance routing

This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2353
RFC2354 Options for Repair of Streaming Media C. Perkins O. Hodson June 1998 ASCII HTML 12 packets UDP user datagram protocol

This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC2354
RFC2355 TN3270 Enhancements B. Kelly June 1998 ASCII HTML 38 TN3270E Telnet option client

This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. [STANDARDS-TRACK]

RFC1647 RFC6270 DRAFT STANDARD DRAFT STANDARD IETF app tn3270e 10.17487/RFC2355
RFC2356 Sun's SKIP Firewall Traversal for Mobile IP G. Montenegro V. Gupta June 1998 ASCII HTML 24 Internet Protocol security traffic

The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2356
RFC2357 IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols A. Mankin A. Romanow S. Bradner V. Paxson June 1998 ASCII HTML 11 internet engineering task force rmtp procedures

This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of the IETF. Within today's Internet, important applications exist for a reliable multicast service. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2357
RFC2358 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson June 1998 ASCII HTML 39 MIB Management Information Base 802.3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 "Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. [STANDARDS-TRACK]

RFC1650 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2358
RFC2359 IMAP4 UIDPLUS extension J. Myers June 1998 ASCII HTML 6 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]

RFC4315 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2359
RFC2360 Guide for Internet Standards Writers G. Scott June 1998 ASCII HTML 20 specification multiple implementations

This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0022 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF stdguide 10.17487/RFC2360
RFC2361 WAVE and AVI Codec Registries E. Fleischman June 1998 ASCII HTML 71 multimedia parameter audio video microsoft

The purpose of this paper is to establish a mechanism by which codecs registered within Microsoft's WAVE and AVI Registries may be referenced within the IANA Namespace by Internet applications. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2361 10.17487/RFC2361
RFC2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification D. Estrin D. Farinacci A. Helmy D. Thaler S. Deering M. Handley V. Jacobson C. Liu P. Sharma L. Wei June 1998 ASCII HTML 66 PIM-SM] routing message type timers flags

This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.

RFC2117 RFC4601 RFC5059 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=2362 10.17487/RFC2362
RFC2363 PPP Over FUNI G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII HTML 12 PPP-FUNI point-to-point protocol atm synchronous transfer mode frame user network interface

This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2363
RFC2364 PPP Over AAL5 G. Gross M. Kaycee A. Li A. Malis J. Stephens July 1998 ASCII HTML 12 PPP-AAL point-to-point protocol link control network-layer authentication compression

This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2364
RFC2365 Administratively Scoped IP Multicast D. Meyer July 1998 ASCII HTML 8 internet protocol IPv4 ipv6 address classes

This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0023 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC2365
RFC2366 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene July 1998 ASCII HTML 76 MIB management information base asynchronous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks'. [STANDARDS-TRACK]

RFC2417 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2366
RFC2367 PF_KEY Key Management API, Version 2 D. McDonald C. Metz B. Phan July 1998 ASCII HTML 68 IP internet protocol security application programming interface

A generic key management API that can be used not only for IP Security but also for other network security services is presented in this document. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2367
RFC2368 The mailto URL scheme P. Hoffman L. Masinter J. Zawinski July 1998 ASCII HTML 10 URLMAILTO uniform resource locator electronic mail addresses

This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. [STANDARDS-TRACK]

RFC6068 RFC1738 RFC1808 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2368
RFC2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields G. Neufeld J. Baer July 1998 ASCII HTML 15 uniform resource locator email header fields

The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2369
RFC2370 The OSPF Opaque LSA Option R. Coltun July 1998 ASCII HTML 15 OSPF-LSA] open shortest path first link state advertisement

This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]

RFC5250 RFC3630 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC2370
RFC2371 Transaction Internet Protocol Version 3.0 J. Lyon K. Evans J. Klein July 1998 ASCII HTML 31 TIPV3 TIP commit protocol electronic commerce

In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app tip 10.17487/RFC2371
RFC2372 Transaction Internet Protocol - Requirements and Supplemental Information K. Evans J. Klein J. Lyon July 1998 ASCII HTML 24 TIP commit protocol electronic commerce

This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app tip 10.17487/RFC2372
RFC2373 IP Version 6 Addressing Architecture R. Hinden S. Deering July 1998 ASCII HTML 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]

RFC1884 RFC3513 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2373 10.17487/RFC2373
RFC2374 An IPv6 Aggregatable Global Unicast Address Format R. Hinden M. O'Dell S. Deering July 1998 ASCII HTML 12 internet protocol architecture routing

This document defines an IPv6 aggregatable global unicast address format for use in the Internet. [STANDARDS-TRACK]

RFC2073 RFC3587 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2374
RFC2375 IPv6 Multicast Address Assignments R. Hinden S. Deering July 1998 ASCII HTML 8 internet protocol multicast scope value

This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2375
RFC2376 XML Media Types E. Whitehead M. Murata July 1998 ASCII HTML 15 extensible markup language web authority hypertext transfer protocol

This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC3023 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2376
RFC2377 Naming Plan for Internet Directory-Enabled Applications A. Grimstad R. Huber S. Sataluri M. Wahl September 1998 ASCII HTML 18 x.500 applications iwps white pages service

Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

RFC4519 INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2377
RFC2378 The CCSO Nameserver (Ph) Architecture R. Hedberg P. Pomes September 1998 ASCII HTML 22 computing communications services office database

The Ph Nameserver from the Computing and Communications Services Office (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF app ids 10.17487/RFC2378
RFC2379 RSVP over ATM Implementation Guidelines L. Berger August 1998 ASCII HTML 8 asynchronous transfer mode resource reservation protocol switched circuits

This memo presents specific implementation guidelines for running RSVP over ATM switched virtual circuits (SVCs). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0024 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv issll 10.17487/RFC2379
RFC2380 RSVP over ATM Implementation Requirements L. Berger August 1998 ASCII HTML 14 resource reservation protocol asynchronous transfer mode switched circuits

This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2380
RFC2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM M. Garrett M. Borden August 1998 ASCII HTML 43 asynchronous transfer mode mapping traffic parameters

This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2381
RFC2382 A Framework for Integrated Services and RSVP over ATM E. Crawley Editor L. Berger S. Berson F. Baker M. Borden J. Krawczyk August 1998 ASCII HTML 30

This document outlines the issues and framework related to providing IP Integrated Services with RSVP over ATM. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2382
RFC2383 ST2+ over ATM Protocol Specification - UNI 3.1 Version M. Suzuki August 1998 ASCII HTML 50 asynchronous transfer mode stream resource reservation

This document specifies an ATM-based protocol for communication between ST2+ agents. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2383
RFC2384 POP URL Scheme R. Gellens August 1998 ASCII HTML 8 POP-URL post office protocol uniform resource identifier string encapsulation

This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2384 10.17487/RFC2384
RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option A. Heffernan August 1998 ASCII HTML 6 border gateway protocol transmission control message digest algorithm

This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]

RFC5925 RFC6691 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2385 10.17487/RFC2385
RFC2386 A Framework for QoS-based Routing in the Internet E. Crawley R. Nair B. Rajagopalan H. Sandick August 1998 ASCII HTML 37 quality of service interdomain intradomain

This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF rtg qosr 10.17487/RFC2386
RFC2387 The MIME Multipart/Related Content-type E. Levinson August 1998 ASCII HTML 10 MIME-RELAT multipurpose internet mail extensions body parts media-type

This document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]

RFC2112 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2387 10.17487/RFC2387
RFC2388 Returning Values from Forms: multipart/form-data L. Masinter August 1998 ASCII HTML 9 media-type multipurpose internet mail extensions

This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]

RFC7578 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2388 10.17487/RFC2388
RFC2389 Feature negotiation mechanism for the File Transfer Protocol P. Hethmon R. Elz August 1998 ASCII HTML 9 FTP catalogue

This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server. [STANDARDS-TRACK]

RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext 10.17487/RFC2389
RFC2390 Inverse Address Resolution Protocol T. Bradley C. Brown A. Malis September 1998 ASCII HTML 10 IARP iarp hardware frame relay

This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]

RFC1293 DRAFT STANDARD DRAFT STANDARD IETF int ion 10.17487/RFC2390
RFC2391 Load Sharing using IP Network Address Translation (LSNAT) P. Srisuresh D. Gan August 1998 ASCII HTML 18 internet protocol datagram server

In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2391 10.17487/RFC2391
RFC2392 Content-ID and Message-ID Uniform Resource Locators E. Levinson August 1998 ASCII HTML 6 CIDMID-URL Hyper Text Markup Language URL MIME

The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message. [STANDARDS-TRACK]

RFC2111 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2392 10.17487/RFC2392
RFC2393 IP Payload Compression Protocol (IPComp) A. Shacham R. Monsour R. Pereira M. Thomas December 1998 ASCII HTML 10 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

RFC3173 PROPOSED STANDARD PROPOSED STANDARD IETF int ippcp 10.17487/RFC2393
RFC2394 IP Payload Compression Using DEFLATE R. Pereira December 1998 ASCII HTML 6 internet protocol algorithm datagram format

This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of the DEFLATE algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ippcp 10.17487/RFC2394
RFC2395 IP Payload Compression Using LZS R. Friend R. Monsour December 1998 ASCII HTML 9 internet protocol algorithm datagram lossless

This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

INFORMATIONAL INFORMATIONAL IETF int ippcp http://www.rfc-editor.org/errata_search.php?rfc=2395 10.17487/RFC2395
RFC2396 Uniform Resource Identifiers (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter August 1998 ASCII HTML 40 URI-GEN characters string absolute relative

This document defines a grammar that is a superset of all valid URI, such that an implementation can parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier type. [STANDARDS-TRACK]

RFC3986 RFC1808 RFC1738 RFC2732 DRAFT STANDARD DRAFT STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2396 10.17487/RFC2396
RFC2397 The "data" URL scheme L. Masinter August 1998 ASCII HTML 5 DATA-URL uniform resource identifiers media type

A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2397 10.17487/RFC2397
RFC2398 Some Testing Tools for TCP Implementors S. Parker C. Schmechel August 1998 ASCII HTML 15 transmission control protocol catalogue

This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.

FYI0033 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2398
RFC2399 Request for Comments Summary A. Ramos January 1999 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2399 RFC2400 Internet Official Protocol Standards J. Postel J. Reynolds September 1998 ASCII HTML 47 IAB official protocol standards

This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. [STANDARDS-TRACK]

RFC2300 RFC2500 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2400
RFC2401 Security Architecture for the Internet Protocol S. Kent R. Atkinson November 1998 ASCII HTML 66 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer

This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]

RFC1825 RFC4301 RFC3168 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2401
RFC2402 IP Authentication Header S. Kent R. Atkinson November 1998 ASCII HTML 22 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6

The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]

RFC1826 RFC4302 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2402
RFC2403 The Use of HMAC-MD5-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII HTML 7 ipsec authentication mechanism header security architecture

This memo describes the use of the HMAC algorithm in conjunction with the MD5 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2403
RFC2404 The Use of HMAC-SHA-1-96 within ESP and AH C. Madson R. Glenn November 1998 ASCII HTML 7 ipsec authentication mechanism header security architecture payload

This memo describes the use of the HMAC algorithm in conjunction with the SHA-1 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload and the revised IPSEC Authentication Header. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2404
RFC2405 The ESP DES-CBC Cipher Algorithm With Explicit IV C. Madson N. Doraswamy November 1998 ASCII HTML 10 ESPDES-CBC ipsec payload security architecture encryption

This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2405
RFC2406 IP Encapsulating Security Payload (ESP) S. Kent R. Atkinson November 1998 ASCII HTML 22 ESP ipsec internet protocol encapsulating security ipv4 ipv6

The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]

RFC1827 RFC4303 RFC4305 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2406
RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP D. Piper November 1998 ASCII HTML 32 ISAKMPSEC ipsec internet protocol security association key management

This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]

RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2407 10.17487/RFC2407
RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) D. Maughan M. Schertler M. Schneider J. Turner November 1998 ASCII HTML 86 ISAKMP ipsec cryptography authentication

This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK]

RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2408
RFC2409 The Internet Key Exchange (IKE) D. Harkins D. Carrel November 1998 ASCII HTML 41 IKE ipsec oakley authentication isakmp internet security key management

This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]

RFC4306 RFC4109 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2409
RFC2410 The NULL Encryption Algorithm and Its Use With IPsec R. Glenn S. Kent November 1998 ASCII HTML 6 ipsec internet protocol security esp encapsulating payload

This memo defines the NULL encryption algorithm and its use with the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2410 10.17487/RFC2410
RFC2411 IP Security Document Roadmap R. Thayer N. Doraswamy R. Glenn November 1998 ASCII HTML 11 ipsec internet protocol privacy authentication

This document is intended to provide guidelines for the development of collateral specifications describing the use of new encryption and authentication algorithms with the ESP protocol, described in and new authentication algorithms used with the AH protocol. This memo provides information for the Internet community.

RFC6071 INFORMATIONAL INFORMATIONAL IETF sec ipsec 10.17487/RFC2411
RFC2412 The OAKLEY Key Determination Protocol H. Orman November 1998 ASCII HTML 55 ipsec authentication crytographic secure scalable

This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=2412 10.17487/RFC2412
RFC2413 Dublin Core Metadata for Resource Discovery S. Weibel J. Kunze C. Lagoze M. Wolf September 1998 ASCII HTML 8 workshop electronic librarians network

This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community.

RFC5013 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2413
RFC2414 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge September 1998 ASCII HTML 14 TCP-WIN transmission control protocol

This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This memo defines an Experimental Protocol for the Internet community.

RFC3390 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2414
RFC2415 Simulation Studies of Increased Initial TCP Window Size K. Poduri K. Nichols September 1998 ASCII HTML 11 transmission control protocol file transfer

This document covers some simulation studies of the effects of increasing the initial window size of TCP. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2415
RFC2416 When TCP Starts Up With Four Packets Into Only Three Buffers T. Shepard C. Partridge September 1998 ASCII HTML 7 transmission control protocol performance

This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2416
RFC2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks C. Chung M. Greene September 1998 ASCII HTML 76 MIB management information base asynchronous transfer mode

This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. [STANDARDS-TRACK]

RFC2366 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2417 10.17487/RFC2417
RFC2418 IETF Working Group Guidelines and Procedures S. Bradner September 1998 ASCII HTML 26 BCP WG escape clause procedures

This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC1603 RFC3934 RFC7475 RFC7776 RFC8717 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson http://www.rfc-editor.org/errata_search.php?rfc=2418 10.17487/RFC2418
RFC2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis) K. Sklower G. Meyer September 1998 ASCII HTML 12 DESE-bis point-to-point protocol ecp control

This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

RFC1969 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2419
RFC2420 The PPP Triple-DES Encryption Protocol (3DESE) H. Kummert September 1998 ASCII HTML 8 3DESE point-to-point protocol ecp control

This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2420
RFC2421 Voice Profile for Internet Mail - version 2 G. Vaudreuil G. Parsons September 1998 ASCII HTML 56 MIME-VP2 vpim messaging

This document profiles Internet mail for voice messaging. [STANDARDS-TRACK]

RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2421 10.17487/RFC2421
RFC2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII HTML 6 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]

RFC1911 RFC3802 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2422
RFC2423 VPIM Voice Message MIME Sub-type Registration G. Vaudreuil G. Parsons September 1998 ASCII HTML 6 MIME-VPIM multipurpose internet mail extensions profiles

This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]

RFC1911 RFC3801 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2423
RFC2424 Content Duration MIME Header Definition G. Vaudreuil G. Parsons September 1998 ASCII HTML 4 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]

RFC3803 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2424
RFC2425 A MIME Content-Type for Directory Information T. Howes M. Smith F. Dawson September 1998 ASCII HTML 33 TXT-DIR multipurpose internet mail extensions profiles

This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]

RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid 10.17487/RFC2425
RFC2426 vCard MIME Directory Profile F. Dawson T. Howes September 1998 ASCII HTML 42 MIME-VCARD multipurpose internet mail extensions white-pages electronic business card

This memo defines the profile of the MIME Content-Type for directory information for a white-pages person object, based on a vCard electronic business card. [STANDARDS-TRACK]

RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app asid http://www.rfc-editor.org/errata_search.php?rfc=2426 10.17487/RFC2426
RFC2427 Multiprotocol Interconnect over Frame Relay C. Brown A. Malis September 1998 ASCII HTML 34 IP-FR standard standards IP over

This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]

RFC1490 RFC1294 STD0055 INTERNET STANDARD INTERNET STANDARD IETF int ion 10.17487/RFC2427
RFC2428 FTP Extensions for IPv6 and NATs M. Allman S. Ostermann C. Metz September 1998 ASCII HTML 8 file transfer protocol internet network address translators

This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=2428 10.17487/RFC2428
RFC2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) C. Bormann L. Cline G. Deisher T. Gardos C. Maciocco D. Newell J. Ott G. Sullivan S. Wenger C. Zhu October 1998 ASCII HTML 17 real time transport protocol multicast unicast

This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]

RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2429
RFC2430 A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) T. Li Y. Rekhter October 1998 ASCII HTML 16 isp internet service provider packet flow multiprotocol label switching mpls resource reservation protocol rsvp

This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2430
RFC2431 RTP Payload Format for BT.656 Video Encoding D. Tynan October 1998 ASCII HTML 10 real time transport protocol itu multicast unicast

This document specifies the RTP payload format for encapsulating ITU Recommendation BT.656-3 video streams in the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2431
RFC2432 Terminology for IP Multicast Benchmarking K. Dubray October 1998 ASCII HTML 16 internet protocol network forwarding devices

The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2432
RFC2433 Microsoft PPP CHAP Extensions G. Zorn S. Cobb October 1998 ASCII HTML 20 point to point protocol challenge handshake authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2433
RFC2434 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand October 1998 ASCII HTML 11 internet assigned numbers authority values implementations

This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC5226 RFC3692 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2434
RFC2435 RTP Payload Format for JPEG-compressed Video L. Berc W. Fenner R. Frederick S. McCanne P. Stewart October 1998 ASCII HTML 27 Real Time Transport Protocol Joint Photographic Experts Group

This memo describes the RTP payload format for JPEG video streams. [STANDARDS-TRACK]

RFC2035 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=2435 10.17487/RFC2435
RFC2436 Collaboration between ISOC/IETF and ITU-T R. Brett S. Bradner G. Parsons October 1998 ASCII HTML 14 internet society engineering task force

This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community.

RFC3356 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2436
RFC2437 PKCS #1: RSA Cryptography Specifications Version 2.0 B. Kaliski J. Staddon October 1998 ASCII HTML 39 data public key cryptosystem

This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community.

RFC2313 RFC3447 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2437
RFC2438 Advancement of MIB specifications on the IETF Standards Track M. O'Dell H. Alvestrand B. Wijnen S. Bradner October 1998 ASCII HTML 7 management information base internet engineering task force

This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0027 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2438
RFC2439 BGP Route Flap Damping C. Villamizar R. Chandra R. Govindan November 1998 ASCII HTML 37 Border Gateway Protocol IDRP Internet-Domain Routing

A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2439 10.17487/RFC2439
RFC2440 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney R. Thayer November 1998 ASCII HTML 65 pretty good privacy encryption authentication

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]

RFC4880 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp 10.17487/RFC2440
RFC2441 Working with Jon, Tribute delivered at UCLA, October 30, 1998 D. Cohen November 1998 ASCII HTML 6 Jonathan B Postel

This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2441
RFC2442 The Batch SMTP Media Type N. Freed D. Newman J. Belissent M. Hoy November 1998 ASCII HTML 9 simple transfer protocol mime multipurpose internet mail extensions tunneling

This document defines a MIME content type suitable for tunneling an ESMTP transaction through any MIME-capable transport. This memo provides information for the Internet community

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2442
RFC2443 A Distributed MARS Service Using SCSP J. Luciani A. Gallo November 1998 ASCII HTML 18 MARS-SCSP server cache syncronization protocol atm asynchronous transfer mode

This document describes a method for distributing a MARS service within a LIS. This method uses the Server Cache Synchronization Protocol (SCSP) to synchronize the MARS Server databases within a LIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). [STANDARDS-TRACK]

EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2443
RFC2444 The One-Time-Password SASL Mechanism C. Newman October 1998 ASCII HTML 7 OTP-SASL otp simple authentication security layer

OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK]

RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec otp 10.17487/RFC2444
RFC2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar) F. Dawson D. Stenerson November 1998 ASCII HTML 148 ICALENDAR internet interoperable mime multipurpose mail extensions

This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. [STANDARDS-TRACK]

RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2445 10.17487/RFC2445
RFC2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries S. Silverberg S. Mansour F. Dawson R. Hopson November 1998 ASCII HTML 109 ITIP internet systems interoperability

This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. [STANDARDS-TRACK]

RFC5546 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch http://www.rfc-editor.org/errata_search.php?rfc=2446 10.17487/RFC2446
RFC2447 iCalendar Message-Based Interoperability Protocol (iMIP) F. Dawson S. Mansour S. Silverberg November 1998 ASCII HTML 18 IMIP internet electronic mail transport

This document specifies a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to Internet email-based transports. [STANDARDS-TRACK]

RFC6047 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2447
RFC2448 AT&T's Error Resilient Video Transmission Technique M. Civanlar G. Cash B. Haskell November 1998 ASCII HTML 7 packets network bitstreams

This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2448
RFC2449 POP3 Extension Mechanism R. Gellens C. Newman L. Lundblade November 1998 ASCII HTML 19 POP3-EXT post office protocol server

This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]

RFC1939 RFC5034 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2449
RFC2450 Proposed TLA and NLA Assignment Rule R. Hinden December 1998 ASCII HTML 11 top-level aggregation identifiers next-level ipv6 internet protocols addresses

This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2450
RFC2451 The ESP CBC-Mode Cipher Algorithms R. Pereira R. Adams November 1998 ASCII HTML 14 ipsec encapsulating security payload

This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2451
RFC2452 IP Version 6 Management Information Base for the Transmission Control Protocol M. Daniele December 1998 ASCII HTML 10 mib internet protocol tcp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

RFC4022 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2452
RFC2453 RIP Version 2 G. Malkin November 1998 ASCII HTML 39 RIP2 RIP-2

This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]

RFC1723 RFC4822 STD0056 INTERNET STANDARD INTERNET STANDARD IETF rtg ripv2 http://www.rfc-editor.org/errata_search.php?rfc=2453 10.17487/RFC2453
RFC2454 IP Version 6 Management Information Base for the User Datagram Protocol M. Daniele December 1998 ASCII HTML 9 mib internet protocol udp ipv6

This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). [STANDARDS-TRACK]

RFC4113 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2454
RFC2455 Definitions of Managed Objects for APPN B. Clouston B. Moore November 1998 ASCII HTML 140 APPN-MIB mib management information base advanced peer-to-peer networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS-TRACK]

RFC2155 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2455
RFC2456 Definitions of Managed Objects for APPN TRAPS B. Clouston B. Moore November 1998 ASCII HTML 21 mib management information base advanced peer-to-peer networking

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2456
RFC2457 Definitions of Managed Objects for Extended Border Node B. Clouston B. Moore November 1998 ASCII HTML 28 EBN-MIB mib management information base ebn

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2457
RFC2458 Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations H. Lu M. Krishnaswamy L. Conroy S. Bellovin F. Burg A. DeSimone K. Tewani P. Davidson H. Schulzrinne K. Vishwanathan November 1998 ASCII HTML 60

This document contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF tsv pint 10.17487/RFC2458
RFC2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile R. Housley W. Ford W. Polk D. Solo January 1999 ASCII HTML 129 digital signatures encryption authentication

This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]

RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2459 10.17487/RFC2459
RFC2460 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden December 1998 ASCII HTML 39 IPV6 internet protocol next generation ipng

This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]

draft-ietf-ipngwg-ipv6-spec-v2-02 RFC1883 RFC8200 RFC5095 RFC5722 RFC5871 RFC6437 RFC6564 RFC6935 RFC6946 RFC7045 RFC7112 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2460 10.17487/RFC2460
RFC2461 Neighbor Discovery for IP Version 6 (IPv6) T. Narten E. Nordmark W. Simpson December 1998 ASCII HTML 93 IPV6-ND internet protocol link-layer

This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]

RFC1970 RFC4861 RFC4311 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2461
RFC2462 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten December 1998 ASCII HTML 25 IPV6-AUTO internet protocol host link-local

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]

RFC1971 RFC4862 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2462 10.17487/RFC2462
RFC2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering December 1998 ASCII HTML 18 ICMPv6 internet protocol link-local autoconfigured addresses

This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

RFC1885 RFC4443 DRAFT STANDARD DRAFT STANDARD IETF int ipngwg 10.17487/RFC2463
RFC2464 Transmission of IPv6 Packets over Ethernet Networks M. Crawford December 1998 ASCII HTML 7 internet protocol link-local autoconfigured addresses

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]

RFC1972 RFC6085 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2464 10.17487/RFC2464
RFC2465 Management Information Base for IP Version 6: Textual Conventions and General Group D. Haskin S. Onishi December 1998 ASCII HTML 38 mib internet protocol ipv6

This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. [STANDARDS-TRACK]

RFC4293 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2465
RFC2466 Management Information Base for IP Version 6: ICMPv6 Group D. Haskin S. Onishi December 1998 ASCII HTML 16 ICMPv6-MIB mib internet protocol ipv6

This document is one in the series of documents that define various MIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. [STANDARDS-TRACK]

RFC4293 RFC8096 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2466
RFC2467 Transmission of IPv6 Packets over FDDI Networks M. Crawford December 1998 ASCII HTML 9 internet protocol link-local addresses autoconfiguration

This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS-TRACK]

RFC2019 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2467
RFC2468 I REMEMBER IANA V. Cerf October 1998 ASCII HTML 4 jonathan b postel

A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2468
RFC2469 A Caution On The Canonical Ordering Of Link-Layer Addresses T. Narten C. Burton December 1998 ASCII HTML 5 address resolution protocol data fields

Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2469
RFC2470 Transmission of IPv6 Packets over Token Ring Networks M. Crawford T. Narten S. Thomas December 1998 ASCII HTML 11 internet protocol frame format link-local addresses

This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]

RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2470
RFC2471 IPv6 Testing Address Allocation R. Hinden R. Fink J. Postel December 1998 ASCII HTML 5 internet protocol protocotype software architecture

This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This memo defines an Experimental Protocol for the Internet community.

RFC1897 RFC3701 HISTORIC EXPERIMENTAL IETF int ipngwg 10.17487/RFC2471
RFC2472 IP Version 6 over PPP D. Haskin E. Allen December 1998 ASCII HTML 14 IPv6-PPP internet protocol point-to-point ipv6

This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. [STANDARDS-TRACK]

draft-ietf-ipngwg-ipv6-over-ppp-06 RFC2023 RFC5072 RFC5172 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2472
RFC2473 Generic Packet Tunneling in IPv6 Specification A. Conta S. Deering December 1998 ASCII HTML 36 internet protocol encapsulation

This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2473
RFC2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers K. Nichols S. Blake F. Baker D. Black December 1998 ASCII HTML 20 internet protocol network nodes

This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]

RFC1455 RFC1349 RFC0791 RFC3168 RFC3260 RFC8436 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2474 10.17487/RFC2474
RFC2475 An Architecture for Differentiated Services S. Blake D. Black M. Carlson E. Davies Z. Wang W. Weiss December 1998 ASCII HTML 36 DIFFSRV] scalability IP internet protocol

This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.

RFC3260 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2475
RFC2476 Message Submission R. Gellens J. Klensin December 1998 ASCII HTML 15 smtp simple mail transfer protocol user agent

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]

RFC4409 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2476
RFC2477 Criteria for Evaluating Roaming Protocols B. Aboba G. Zorn January 1999 ASCII HTML 12 ISP internet service providers operations

This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2477
RFC2478 The Simple and Protected GSS-API Negotiation Mechanism E. Baize D. Pinkas December 1998 ASCII HTML 18 generic service application security program interface

This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS-TRACK]

RFC4178 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2478
RFC2479 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) C. Adams December 1998 ASCII HTML 70 data unit authentication

The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF sec cat 10.17487/RFC2479
RFC2480 Gateways and MIME Security Multiparts N. Freed January 1999 ASCII HTML 6 mutltipurpose internet mail extensions

This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2480
RFC2481 A Proposal to add Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd January 1999 ASCII HTML 25 ECN-IP internet protocol tcp transmission control transport

This note describes a proposed addition of ECN (Explicit Congestion Notification) to IP. This memo defines an Experimental Protocol for the Internet community.

RFC3168 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2481
RFC2482 Language Tagging in Unicode Plain Text K. Whistler G. Adams January 1999 ASCII HTML 14 characters strings ASCII

This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.

RFC6082 HISTORIC INFORMATIONAL Legacy 10.17487/RFC2482
RFC2483 URI Resolution Services Necessary for URN Resolution M. Mealling R. Daniel January 1999 ASCII HTML 16 uniform resource identifier names locators characteristics

Retrieving the resource identified by a Uniform Resource Identifier (URI) is only one of the operations that can be performed on a URI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to both Uniform Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers. This memo defines an Experimental Protocol for the Internet community.

EXPERIMENTAL EXPERIMENTAL IETF app urn 10.17487/RFC2483
RFC2484 PPP LCP Internationalization Configuration Option G. Zorn January 1999 ASCII HTML 5 point-to-point protocol link control authentication

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]

RFC2284 RFC1994 RFC1570 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2484
RFC2485 DHCP Option for The Open Group's User Authentication Protocol S. Drach January 1999 ASCII HTML 4 dynamic host configuration UAP

This document defines a DHCP option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open Group Network Computing Client Technical Standard. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2485
RFC2486 The Network Access Identifier B. Aboba M. Beadles January 1999 ASCII HTML 8 NAI tunneling roaming

This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]

RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops http://www.rfc-editor.org/errata_search.php?rfc=2486 10.17487/RFC2486
RFC2487 SMTP Service Extension for Secure SMTP over TLS P. Hoffman January 1999 ASCII HTML 8 simple mail transfer protocol transport layer security ssl

This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

RFC3207 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2487
RFC2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms M. Allman D. Glover L. Sanchez January 1999 ASCII HTML 19 transmission control protocol network

The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

BCP0028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpsat http://www.rfc-editor.org/errata_search.php?rfc=2488 10.17487/RFC2488
RFC2489 Procedure for Defining New DHCP Options R. Droms January 1999 ASCII HTML 5 mutipurpose internet mail extensions

This document describes the procedure for defining new DHCP options. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2939 BCP0029 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2489 10.17487/RFC2489
RFC2490 A Simulation Model for IP Multicast with RSVP M. Pullen R. Malghan L. Lavu G. Duan J. Ma H. Nah January 1999 ASCII PS PDF HTML 31 internet protocol resource reservation ipv4

This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package, with protocol procedures defined in the C language. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2490
RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks G. Armitage P. Schulter M. Jork G. Harter January 1999 ASCII HTML 44 IPv6-NBMA internet protocol routing host

This document describes a general architecture for IPv6 over NBMA networks. [STANDARDS-TRACK]

RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2491
RFC2492 IPv6 over ATM Networks G. Armitage P. Schulter M. Jork January 1999 ASCII HTML 12 IPv6ATMNET internet protocol asynchronous transfer mode host

This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks". It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths (when using SVCs). Operation over administratively configured Point to Point PVCs is also supported. [STANDARDS-TRACK]

RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion http://www.rfc-editor.org/errata_search.php?rfc=2492 10.17487/RFC2492
RFC2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor January 1999 ASCII HTML 9 management information base data

This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals. [STANDARDS-TRACK]

RFC3593 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2493
RFC2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type D. Fowler Editor January 1999 ASCII HTML 25 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS0 and DS0 Bundle interfaces. This document is a companion document with Definitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2494
RFC2495 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types D. Fowler Editor January 1999 ASCII HTML 75 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS3/E3 (RFC 2496), and the work in progress, SONET/SDH Interface Types. [STANDARDS-TRACK]

RFC1406 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2495
RFC2496 Definitions of Managed Object for the DS3/E3 Interface Type D. Fowler Editor January 1999 ASCII HTML 60 DS3-E3-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494), DS1/E1/DS2/E2 (RFC 2495), and the work in progress SONET/SDH Interface Types. [STANDARDS-TRACK]

RFC1407 RFC3896 PROPOSED STANDARD PROPOSED STANDARD IETF int trunkmib 10.17487/RFC2496
RFC2497 Transmission of IPv6 Packets over ARCnet Networks I. Souvatzis January 1999 ASCII HTML 6 internet protocol frame format link-local

This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]

draft-souvatzis-ipv6-arcnet-05 RFC8064 RFC1201 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2497
RFC2498 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson January 1999 ASCII HTML 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.

RFC2678 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2498
RFC2499 Request for Comments Summary A. Ramos July 1999 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2499 RFC2500 Internet Official Protocol Standards J. Reynolds R. Braden June 1999 ASCII HTML 28 IAB official protocol standards

This memo summarizes the status of Internet protocols and specifications. [STANDARDS-TRACK]

RFC2400 RFC2600 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2500
RFC2501 Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations S. Corson J. Macker January 1999 ASCII HTML 12 MANET packet network hardwire wireless

This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC2501
RFC2502 Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment M. Pullen M. Myjak C. Bouwens February 1999 ASCII HTML 11 IP DIS distributed applications

This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2502
RFC2503 MIME Types for Use with the ISO ILL Protocol R. Moulton M. Needleman February 1999 ASCII HTML 6 multipurpose mail internet extensions media type interlibrary loan

This memorandum describes a set of MIME types for use with the ISO Interlibrary Loan Protocol (ISO 10160/10161). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2503
RFC2504 Users' Security Handbook E. Guttman L. Leong G. Malkin February 1999 ASCII HTML 33 encryption networks systems

The Users' Security Handbook is the companion to the Site Security Handbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. This memo provides information for the Internet community.

FYI0034 INFORMATIONAL INFORMATIONAL IETF ssh 10.17487/RFC2504
RFC2505 Anti-Spam Recommendations for SMTP MTAs G. Lindberg February 1999 ASCII HTML 24 simple mail transfer protocol agents sendmail

This memo gives a number of implementation recommendations for SMTP, MTAs (Mail Transfer Agents, e.g. sendmail,) to make them more capable of reducing the impact of spam. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-lindberg-anti-spam-mta-08 BCP0030 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2505
RFC2506 Media Feature Tag Registration Procedure K. Holtman A. Mutz T. Hardie March 1999 ASCII HTML 12 data formats vocabulary negotiation mechanism

This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-conneg-feature-reg-03 BCP0031 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app conneg 10.17487/RFC2506
RFC2507 IP Header Compression M. Degermark B. Nordgren S. Pink February 1999 ASCII HTML 47 internet protocol tcp transmission control bandwidth

This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2507
RFC2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links S. Casner V. Jacobson February 1999 ASCII HTML 24 internet protocol user datagram real-timetransport interoperability

This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2508
RFC2509 IP Header Compression over PPP M. Engan S. Casner C. Bormann February 1999 ASCII HTML 10 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol. It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

RFC3544 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2509
RFC2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols C. Adams S. Farrell March 1999 ASCII HTML 72 PKICMP pki security cryptographic authentication

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]

draft-ietf-pkix-ipki3cmp-09 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2510
RFC2511 Internet X.509 Certificate Request Message Format M. Myers C. Adams D. Solo D. Kemp March 1999 ASCII HTML 25 X.509-CRMF crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]

draft-ietf-pkix-crmf-01 RFC4211 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2511
RFC2512 Accounting Information for ATM Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII HTML 15 mib management information base autonomous transfer mode

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]

draft-ietf-atommib-atmacct-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2512
RFC2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks K. McCloghrie J. Heinanen W. Greene A. Prasad February 1999 ASCII HTML 29 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]

draft-ietf-atommib-acct-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2513
RFC2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management M. Noto E. Spiegel K. Tesink February 1999 ASCII HTML 20 ATM-TC-OID asynchronous transfer mode MIB management information base

This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

draft-ietf-atommib-atm2TC-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2514
RFC2515 Definitions of Managed Objects for ATM Management K. Tesink Editor February 1999 ASCII HTML 87 ATM-MIBMAN asynchronous transfer mode MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]

draft-ietf-atommib-atm1ng-06 RFC1695 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2515
RFC2516 A Method for Transmitting PPP Over Ethernet (PPPoE) L. Mamakos K. Lidl J. Evarts D. Carrel D. Simone R. Wheeler February 1999 ASCII HTML 17 PPPOE point-to-point protocol link control network layer

This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2516 10.17487/RFC2516
RFC2517 Building Directories from DNS: Experiences from WWWSeeker R. Moats R. Huber February 1999 ASCII HTML 7 domain name system internet world wide web

This memo discusses lessons that were learned during InterNIC Directory and Database Services' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2517
RFC2518 HTTP Extensions for Distributed Authoring -- WEBDAV Y. Goland E. Whitehead A. Faizi S. Carter D. Jensen February 1999 ASCII HTML 94 WEBDAV hypertext transfer protocol web content

This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). [STANDARDS-TRACK]

RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=2518 10.17487/RFC2518
RFC2519 A Framework for Inter-Domain Route Aggregation E. Chen J. Stewart February 1999 ASCII HTML 13 IDRA bgp border gateway protocol address ip internet

This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This memo provides information for the Internet community

draft-ietf-idr-aggregation-framework-04 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC2519
RFC2520 NHRP with Mobile NHCs J. Luciani H. Suzuki N. Doraswamy D. Horton February 1999 ASCII HTML 8 NHRP-MNHCS next hop resolution protocol authentication extension

is document describes an extension to NHRP which would allow Mobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ion-nhrp-mobile-nhc-01 EXPERIMENTAL EXPERIMENTAL IETF int ion 10.17487/RFC2520
RFC2521 ICMP Security Failures Messages P. Karn W. Simpson March 1999 ASCII HTML 9 ICMP-SEC internet control message protocol ip

This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). This document defines an Experimental Protocol for the Internet community.

draft-simpson-icmp-ipsec-fail-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2521
RFC2522 Photuris: Session-Key Management Protocol P. Karn W. Simpson March 1999 ASCII HTML 80 PHOTURIS-S ip internet protocol ah esp

This document defines the basic protocol mechanisms. This document defines an Experimental Protocol for the Internet community.

draft-simpson-photuris-18 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2522
RFC2523 Photuris: Extended Schemes and Attributes P. Karn W. Simpson March 1999 ASCII HTML 21 PHOTURIS-E ip internet protocol security

Photuris is a session-key management protocol. Extensible Exchange- Schemes are provided to enable future implementation changes without affecting the basic protocol. This document defines an Experimental Protocol for the Internet community.

draft-simpson-photuris-schemes-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2523
RFC2524 Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3 M. Banan February 1999 ASCII HTML 83 EMSD wireless IP internet protocol

This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2524
RFC2525 Known TCP Implementation Problems V. Paxson M. Allman S. Dawson W. Fenner J. Griner I. Heavens K. Lahey J. Semke B. Volz March 1999 ASCII HTML 61 transmission control protocol

This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community.

draft-ietf-tcpimpl-prob-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2525
RFC2526 Reserved IPv6 Subnet Anycast Addresses D. Johnson S. Deering March 1999 ASCII HTML 7 internet protocol routing architecture

This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. [STANDARDS-TRACK]

draft-ietf-ipngwg-resv-anycast-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2526
RFC2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford March 1999 ASCII HTML 45 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. This memo provides information for the Internet community.

draft-ietf-pkix-ipki-part4-03 RFC3647 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2527 10.17487/RFC2527
RFC2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates R. Housley W. Polk March 1999 ASCII HTML 9 security authentication cryptology

This specification contains guidance on the use of the Internet Public Key Infrastructure certificates to convey Key Exchange Algorithm (KEA) keys. This memo provides information for the Internet community.

draft-ietf-pkix-ipki-kea-02 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC2528
RFC2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels B. Carpenter C. Jung March 1999 ASCII HTML 10 link-local link local addresses internet protocol ip

This memo specifies the frame format for transmission of IPv6 (IPV6) packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. [STANDARDS-TRACK]

draft-ietf-ipngwg-6over4-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2529
RFC2530 Indicating Supported Media Features Using Extensions to DSN and MDN D. Wing March 1999 ASCII HTML 5 message disposition notification delivery status

This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]

draft-ietf-fax-reporting-extensions-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2530
RFC2531 Content Feature Schema for Internet Fax G. Klyne L. McIntyre March 1999 ASCII HTML 51 media features mechanism

This document defines a content feature schema that is a profile of the media feature registration mechanisms for use in performing capability identification between extended Internet fax systems. [STANDARDS-TRACK]

draft-ietf-fax-feature-schema-05 RFC2879 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2531
RFC2532 Extended Facsimile Using Internet Mail L. Masinter D. Wing March 1999 ASCII HTML 12 mail user fax

This document describes extensions to "Simple Mode of Facsimile Using Internet Mail", and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. [STANDARDS-TRACK]

draft-ietf-fax-eifax-12 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2532
RFC2533 A Syntax for Describing Media Feature Sets G. Klyne March 1999 ASCII HTML 37 message senders recipients file format

This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. [STANDARDS-TRACK]

draft-ietf-conneg-feature-syntax-04 RFC2738 RFC2938 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2533
RFC2534 Media Features for Display, Print, and Fax L. Masinter D. Wing A. Mutz K. Holtman March 1999 ASCII HTML 9 data format vocabulary negotiation mechanisms

This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications. [STANDARDS-TRACK]

draft-ietf-conneg-media-features-05 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2534
RFC2535 Domain Name System Security Extensions D. Eastlake 3rd March 1999 ASCII HTML 47 DNS-SECEXT dns authentication

This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]

draft-ietf-dnssec-secext2-07 RFC2065 RFC4033 RFC4034 RFC4035 RFC2181 RFC1035 RFC1034 RFC2931 RFC3007 RFC3008 RFC3090 RFC3226 RFC3445 RFC3597 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2535
RFC2536 DSA KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII HTML 6 digital signature algorithm signatures cryptology

A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

draft-ietf-dnssec-dss-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2536
RFC2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII HTML 6 message digest signatures cryptology security

A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]

draft-ietf-dnssec-rsa-01 RFC3110 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2537
RFC2538 Storing Certificates in the Domain Name System (DNS) D. Eastlake 3rd O. Gudmundsson March 1999 ASCII HTML 10 SC-DNS cryptology authenticity

Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

draft-ietf-dnssec-certs-04 RFC4398 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2538
RFC2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) D. Eastlake 3rd March 1999 ASCII HTML 7 DHK-DNS cryptology authentication security signatures digital

A standard method for storing Diffie-Hellman keys in the Domain Name System is described which utilizes DNS KEY resource records. [STANDARDS-TRACK]

draft-ietf-dnssec-dhk-03 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF sec dnssec 10.17487/RFC2539
RFC2540 Detached Domain Name System (DNS) Information D. Eastlake 3rd March 1999 ASCII HTML 6 DNS-INFO security digital signatures authentication

A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnssec-ddi-06 EXPERIMENTAL EXPERIMENTAL IETF sec dnssec 10.17487/RFC2540
RFC2541 DNS Security Operational Considerations D. Eastlake 3rd March 1999 ASCII HTML 7 DNS-SOC domain name system cryptology resource records rrs

This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. This memo provides information for the Internet community.

draft-ietf-dnssec-secops-02 RFC4641 INFORMATIONAL INFORMATIONAL IETF sec dnssec 10.17487/RFC2541
RFC2542 Terminology and Goals for Internet Fax L. Masinter March 1999 ASCII HTML 20 real-time real time session store forward

This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. This memo provides information for the Internet community.

draft-ietf-fax-goals-04 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2542
RFC2543 SIP: Session Initiation Protocol M. Handley H. Schulzrinne E. Schooler J. Rosenberg March 1999 ASCII HTML 151 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. [STANDARDS-TRACK]

draft-ietf-mmusic-sip-12 RFC3261 RFC3262 RFC3263 RFC3264 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC2543
RFC2544 Benchmarking Methodology for Network Interconnect Devices S. Bradner J. McQuaid March 1999 ASCII HTML 31 testing performance

This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community.

RFC1944 RFC6201 RFC6815 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2544 10.17487/RFC2544
RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing P. Marques F. Dupont March 1999 ASCII HTML 5 border gateway protocol idr internet routing

BGP-4 Multiprotocol Extensions (BGP-MP) defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2545
RFC2546 6Bone Routing Practice A. Durand B. Buclin March 1999 ASCII HTML 10 IPv6 internet protocol

This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community.

draft-ietf-ngtrans-6bone-routing-01 RFC2772 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2546
RFC2547 BGP/MPLS VPNs E. Rosen Y. Rekhter March 1999 ASCII HTML 25 border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider with an IP backbone may provide VPNs (Virtual Private Networks) for its customers. This memo provides information for the Internet community.

RFC4364 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2547
RFC2548 Microsoft Vendor-specific RADIUS Attributes G. Zorn March 1999 ASCII HTML 41 attributes remote access dialin user service dial-in

This document describes the set of Microsoft vendor-specific RADIUS attributes. This memo provides information for the Internet community.

draft-ietf-radius-ms-vsa-01 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2548 10.17487/RFC2548
RFC2549 IP over Avian Carriers with Quality of Service D. Waitzman April 1 1999 ASCII HTML 6 avian carrier april fools qos

This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. This memo defines an Experimental Protocol for the Internet community.

RFC1149 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2549 10.17487/RFC2549
RFC2550 Y10K and Beyond S. Glassman M. Manasse J. Mogul April 1 1999 ASCII HTML 14 years dates formats april fools

This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2550
RFC2551 The Roman Standards Process -- Revision III S. Bradner April 1 1999 ASCII HTML 37 numerals protocols procedures april fools

This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2551
RFC2552 Architecture for the Information Brokerage in the ACTS Project GAIA M. Blinov M. Bessonov C. Clissmann April 1999 ASCII HTML 30 electronic systems products

This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2552
RFC2553 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound W. Stevens March 1999 ASCII HTML 41 internet protocol api application program interface tcp transmission control

TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. This memo provides information for the Internet community.

draft-ietf-ipngwg-bsd-api-new-06 RFC2133 RFC3493 RFC3152 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2553
RFC2554 SMTP Service Extension for Authentication J. Myers March 1999 ASCII HTML 11 simple mail transfer protocol security layer sasl

This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]

draft-myers-smtp-auth-12 RFC4954 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2554
RFC2555 30 Years of RFCs RFC Editor et al. April 1999 ASCII HTML 18 request for comments series documents publication

The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community.

RFC8700 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2555
RFC2556 OSI connectionless transport services on top of UDP Applicability Statement for Historic Status S. Bradner March 1999 ASCII HTML 4 user datagram protocol ISO international organization for standardization

RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility This memo provides information for the Internet community.

draft-bradner-1240.his-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2556
RFC2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) J. Palme A. Hopmann N. Shelness March 1999 ASCII HTML 28 MHTML multipurpose internet mail extensions multimedia uri uniform resource identifiers

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. [STANDARDS-TRACK]

draft-ietf-mhtml-rev-07 RFC2110 PROPOSED STANDARD PROPOSED STANDARD IETF app mhtml http://www.rfc-editor.org/errata_search.php?rfc=2557 10.17487/RFC2557
RFC2558 Definitions of Managed Objects for the SONET/SDH Interface Type K. Tesink March 1999 ASCII HTML 74 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]

draft-ietf-atommib-sonetng-05 RFC1595 RFC3592 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC2558
RFC2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 S. Boeyen T. Howes P. Richard April 1999 ASCII HTML 13 X.500 LDAP lightweight directory protocol

Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. [STANDARDS-TRACK]

draft-ietf-pkix-ipki2opp-08 RFC3494 RFC1778 HISTORIC PROPOSED STANDARD IETF sec pkix 10.17487/RFC2559
RFC2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 1999 ASCII HTML 23 PKIX digital security

This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK]

draft-ietf-pkix-ocsp-07 RFC6960 RFC6277 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2560 10.17487/RFC2560
RFC2561 Base Definitions of Managed Objects for TN3270E Using SMIv2 K. White R. Moore April 1999 ASCII HTML 56 MIB management information base structure telnet

This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. [STANDARDS-TRACK]

draft-ietf-tn3270e-tn3270-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2561
RFC2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) K. White R. Moore April 1999 ASCII HTML 49 TN2370E-RT-MIB MIB management information base structure telnet

This memo defines the protocol and the Management Information Base (MIB) for performing response time data collection on TN3270 and TN3270E sessions by a TN3270E server. [STANDARDS-TRACK]

draft-ietf-tn3270e-rt-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC2562
RFC2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients R. Troll May 1999 ASCII HTML 9 dynamic host configuration protocol internet address

This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. [STANDARDS-TRACK]

draft-ietf-dhc-autoconfig-04 RFC8925 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2563
RFC2564 Application Management MIB C. Kalbfleisch C. Krupczak R. Presuhn J. Saperia May 1999 ASCII HTML 86 APP-MIB management information base

This memo defines a standards track portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. [STANDARDS-TRACK]

draft-ietf-applmib-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2564
RFC2565 Internet Printing Protocol/1.0: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner April 1999 ASCII HTML 37 IPP-E-T IPP application media-type media type

This document defines the rules for encoding IPP operations and IPP attributes into a new Internet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp". This document defines an Experimental protocol for the Internet community.

draft-ietf-ipp-protocol-07 RFC2910 EXPERIMENTAL EXPERIMENTAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2565 10.17487/RFC2565
RFC2566 Internet Printing Protocol/1.0: Model and Semantics R. deBry T. Hastings R. Herriot S. Isaacson P. Powell April 1999 ASCII HTML 173 IPP-M-S IPP application media-type job

This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. This document also addresses security, internationalization, and directory issues. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-model-11 RFC2911 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2566
RFC2567 Design Goals for an Internet Printing Protocol F. Wright April 1999 ASCII HTML 43 IPP-DG IPP application media-type media type

This document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-req-03 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2567
RFC2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol S. Zilles April 1999 ASCII HTML 10 IPP-RAT IPP application media-type media type

This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-rat-04 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2568
RFC2569 Mapping between LPD and IPP Protocols R. Herriot Editor T. Hastings N. Jacobs J. Martin April 1999 ASCII HTML 28 application media-type media type internet printing protocol line printer daemon

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipp-lpd-ipp-map-05 EXPERIMENTAL EXPERIMENTAL IETF app ipp 10.17487/RFC2569
RFC2570 Introduction to Version 3 of the Internet-standard Network Management Framework J. Case R. Mundy D. Partain B. Stewart April 1999 ASCII HTML 23 snmp simple protocol

The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This memo provides information for the Internet community.

draft-ietf-snmpv3-intro-04 RFC3410 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 10.17487/RFC2570
RFC2571 An Architecture for Describing SNMP Management Frameworks B. Wijnen D. Harrington R. Presuhn April 1999 ASCII HTML 62 ARCH-SNMP simple protocol network management

This document describes an architecture for describing SNMP Management Frameworks. [STANDARDS-TRACK]

draft-ietf-snmpv3-arch-05 RFC2271 RFC3411 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2571
RFC2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen April 1999 ASCII HTML 44 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. [STANDARDS-TRACK]

RFC2272 RFC3412 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2572
RFC2573 SNMP Applications D. Levi P. Meyer B. Stewart April 1999 ASCII HTML 72 SNMP-APP simple network management protocol proxy operations command

This memo describes five types of SNMP applications which make use of an SNMP engine. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy fowarding. [STANDARDS-TRACK]

draft-ietf-snmpv3-appl-v2-03 RFC2273 RFC3413 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2573
RFC2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen April 1999 ASCII HTML 86 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. [STANDARDS-TRACK]

draft-ietf-snmpv3-usm-v2-05 RFC2274 RFC3414 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2574
RFC2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie April 1999 ASCII HTML 38 VACM-SNMP mib information base

This document describes the View-based Access Control Model for use in the SNMP architecture (RFC2571). It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. [STANDARDS-TRACK]

draft-ietf-snmpv3-vacm-04 RFC2275 RFC3415 DRAFT STANDARD DRAFT STANDARD IETF ops snmpv3 10.17487/RFC2575
RFC2576 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen March 2000 ASCII HTML 44 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]

draft-ietf-snmpv3-coex-08 RFC1908 RFC2089 RFC3584 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=2576 10.17487/RFC2576
RFC2577 FTP Security Considerations M. Allman S. Ostermann May 1999 ASCII HTML 8 FTP-SEC file transfer protocol bounce attack password server

This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. This memo provides information for the Internet community.

draft-ietf-ftpext-sec-consider-02 INFORMATIONAL INFORMATIONAL IETF app ftpext 10.17487/RFC2577
RFC2578 Structure of Management Information Version 2 (SMIv2) K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII HTML 42 SMIv2 Simple Network Management Protocol Version 2

It is the purpose of this document, the Structure of Management Information Version 2 (SMIv2), to define that adapted subset, and to assign a set of associated administrative values. [STANDARDS-TRACK]

draft-ops-smiv2-smi-01 RFC1902 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2578
RFC2579 Textual Conventions for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII HTML 25 CONV-MIB Simple Network Management Protocol Version 2

It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]

draft-ops-smiv2-tc-01 RFC1903 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2579 10.17487/RFC2579
RFC2580 Conformance Statements for SMIv2 K. McCloghrie Editor D. Perkins Editor J. Schoenwaelder Editor April 1999 ASCII HTML 29 CONF-MIB simple Network Management Protocol Version 2

Collections of related objects are defined in MIB modules. It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]

draft-ops-smiv2-conf-01 RFC1904 STD0058 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2580
RFC2581 TCP Congestion Control M. Allman V. Paxson W. Stevens April 1999 ASCII HTML 14 TCP-CC

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. [STANDARDS-TRACK]

draft-ietf-tcpimpl-cong-control-05 RFC2001 RFC5681 RFC3390 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpimpl http://www.rfc-editor.org/errata_search.php?rfc=2581 10.17487/RFC2581
RFC2582 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson April 1999 ASCII HTML 12 Transmission Control Protocol

This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpimpl-newreno-02 RFC3782 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpimpl 10.17487/RFC2582
RFC2583 Guidelines for Next Hop Client (NHC) Developers R. Carlson L. Winkler May 1999 ASCII HTML 9 NHRP resolution protocol IP internet

This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community.

draft-carlson-nhrp-03 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2583
RFC2584 Definitions of Managed Objects for APPN/HPR in IP Networks B. Clouston B. Moore May 1999 ASCII HTML 21 internet protocol MIB management information base high performance routing

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. [STANDARDS-TRACK]

draft-ietf-snanau-hpripmib-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg snanau 10.17487/RFC2584
RFC2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP R. Housley P. Hoffman May 1999 ASCII HTML 8 file transfer hypertext PKI

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK]

draft-ietf-pkix-opp-ftp-http-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2585 10.17487/RFC2585
RFC2586 The Audio/L16 MIME content type J. Salsman H. Alvestrand May 1999 ASCII HTML 5 AUDIO/L16 media-type application multipurpose internet mail extensions

This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community.

draft-alvestrand-audio-l16-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2586
RFC2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema S. Boeyen T. Howes P. Richard June 1999 ASCII HTML 8 lightweight directory access protocol pkix

The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]

draft-ietf-pkix-ldapv2-schema-02 RFC4523 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2587
RFC2588 IP Multicast and Firewalls R. Finlayson May 1999 ASCII HTML 12 Internet Protocol security gateway traffic

In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community.

draft-ietf-mboned-mcast-firewall-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC2588
RFC2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services Y. Yaacovi M. Wahl T. Genovese May 1999 ASCII HTML 12 LDAPv3 request response operations

This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]

draft-ietf-asid-ldapv3-dynamic-08 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2589
RFC2590 Transmission of IPv6 Packets over Frame Relay Networks Specification A. Conta A. Malis M. Mueller May 1999 ASCII HTML 19 internet Protocol format link-local

This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks. [STANDARDS-TRACK]

draft-ietf-ion-ipv6-fr-02 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2590
RFC2591 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder May 1999 ASCII HTML 25 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-disman-schedule-mib-06 RFC3231 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2591
RFC2592 Definitions of Managed Objects for the Delegation of Management Script D. Levi J. Schoenwaelder May 1999 ASCII HTML 53 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

draft-ietf-disman-script-mib-08 RFC3165 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2592
RFC2593 Script MIB Extensibility Protocol Version 1.0 J. Schoenwaelder J. Quittek May 1999 ASCII HTML 22 management information base smx language specific

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. This memo defines an Experimental Protocol for the Internet community.

draft-schoenw-smx-00 RFC3179 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2593
RFC2594 Definitions of Managed Objects for WWW Services H. Hazewinkel C. Kalbfleisch J. Schoenwaelder May 1999 ASCII HTML 43 management information base mib world wide web

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular it describes a set of objects for managing World Wide Web (WWW) services. [STANDARDS-TRACK]

draft-ietf-applmib-wwwmib-11 PROPOSED STANDARD PROPOSED STANDARD IETF app applmib 10.17487/RFC2594
RFC2595 Using TLS with IMAP, POP3 and ACAP C. Newman June 1999 ASCII HTML 15 application configuration access protocol post office internet message transport layer security

Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]

draft-newman-tls-imappop-09 RFC4616 RFC7817 RFC8314 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2595 10.17487/RFC2595
RFC2596 Use of Language Codes in LDAP M. Wahl T. Howes May 1999 ASCII HTML 9 lightweight directory access protocol servers

This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]

draft-ietf-ldapext-lang-01 RFC3866 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2596
RFC2597 Assured Forwarding PHB Group J. Heinanen F. Baker W. Weiss J. Wroclawski June 1999 ASCII HTML 11 per-hop-behaviour differentiated services af assumed forwarding

This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK]

draft-ietf-diffserv-af-06 RFC3260 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2597 10.17487/RFC2597
RFC2598 An Expedited Forwarding PHB V. Jacobson K. Nichols K. Poduri June 1999 ASCII HTML 11 per-hop-forwarding behavior differentiated services ef

The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. [STANDARDS-TRACK]

draft-ietf-diffserv-phb-ef-02 RFC3246 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=2598 10.17487/RFC2598
RFC2599 Request for Comments Summary RFC Numbers 2500-2599 A. DeLaCruz March 2000 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2599 RFC2600 Internet Official Protocol Standards J. Reynolds R. Braden March 2000 ASCII HTML 31 IAB official protocol standards

This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK]

RFC2500 RFC2700 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2600
RFC2601 ILMI-Based Server Discovery for ATMARP M. Davison June 1999 ASCII HTML 6 integrated local management interface asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. [STANDARDS-TRACK]

draft-ietf-ion-discov-atmarp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2601
RFC2602 ILMI-Based Server Discovery for MARS M. Davison June 1999 ASCII HTML 6 integrated local management interface asynchronous transfer mode address resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. [STANDARDS-TRACK]

draft-ietf-ion-discov-mars-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2602
RFC2603 ILMI-Based Server Discovery for NHRP M. Davison June 1999 ASCII HTML 6 integrated local management interface next hop resolution protocol

This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. [STANDARDS-TRACK]

draft-ietf-ion-discov-nhrp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2603
RFC2604 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens June 1999 ASCII HTML 29 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

draft-gellens-otasp-acap-01 RFC2636 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2604
RFC2605 Directory Server Monitoring MIB G. Mansfield S. Kille June 1999 ASCII HTML 26 management information base network services

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-madman-dsa-mib-1 RFC1567 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2605
RFC2606 Reserved Top Level DNS Names D. Eastlake 3rd A. Panitz June 1999 ASCII HTML 5 domain name system private

To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsind-test-tlds-13 RFC6761 BCP0032 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsind 10.17487/RFC2606
RFC2607 Proxy Chaining and Policy Implementation in Roaming B. Aboba J. Vollbrecht June 1999 ASCII HTML 15 network access server identifier radius

This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community.

draft-ietf-roamops-auth-10 INFORMATIONAL INFORMATIONAL IETF ops roamops 10.17487/RFC2607
RFC2608 Service Location Protocol, Version 2 E. Guttman C. Perkins J. Veizades M. Day June 1999 ASCII HTML 54 SLP network services

The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. [STANDARDS-TRACK]

draft-ietf-svrloc-protocol-v2-15 RFC2165 RFC3224 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc http://www.rfc-editor.org/errata_search.php?rfc=2608 10.17487/RFC2608
RFC2609 Service Templates and Service: Schemes E. Guttman C. Perkins J. Kempf June 1999 ASCII HTML 33 service location protocol slp url universal resource locator

This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. [STANDARDS-TRACK]

draft-ietf-svrloc-service-scheme-14 RFC2165 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC2609
RFC2610 DHCP Options for Service Location Protocol C. Perkins E. Guttman June 1999 ASCII HTML 6 slp dynamic host configuration protocol

The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network. Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. [STANDARDS-TRACK]

draft-ietf-dhc-slp-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2610
RFC2611 URN Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom June 1999 ASCII HTML 14 uniform resource names namespaces syntax

This document lays out general definitions of and mechanisms for establishing URN "namespaces". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urn-nid-req-08 RFC3406 BCP0033 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn 10.17487/RFC2611
RFC2612 The CAST-256 Encryption Algorithm C. Adams J. Gilchrist June 1999 ASCII HTML 19 security cryptology

This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). This memo provides information for the Internet community.

draft-adams-cast-256-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2612
RFC2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 R. Waterman B. Lahaye D. Romascanu S. Waldbusser June 1999 ASCII HTML 44 smon management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. [STANDARDS-TRACK]

draft-ietf-rmonmib-smon-07 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2613
RFC2614 An API for Service Location J. Kempf E. Guttman June 1999 ASCII HTML 91 slp application program interface

This document describes standardized APIs for SLP in C and Java. This memo provides information for the Internet community.

draft-ietf-svrloc-api-09 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2614
RFC2615 PPP over SONET/SDH A. Malis W. Simpson June 1999 ASCII HTML 10 point-to-point protocol synchronous optical network digital heirarchy

This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. [STANDARDS-TRACK]

draft-ietf-pppext-pppoversonet-update-04 RFC1619 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2615
RFC2616 Hypertext Transfer Protocol -- HTTP/1.1 R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach T. Berners-Lee June 1999 ASCII PS PDF HTML 176 HTTP World Wide Web WWW hypermedia

HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]

draft-ietf-http-v11-spec-rev-06 RFC2068 RFC7230 RFC7231 RFC7232 RFC7233 RFC7234 RFC7235 RFC2817 RFC5785 RFC6266 RFC6585 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2616 10.17487/RFC2616
RFC2617 HTTP Authentication: Basic and Digest Access Authentication J. Franks P. Hallam-Baker J. Hostetler S. Lawrence P. Leach A. Luotonen L. Stewart June 1999 ASCII HTML 34 security encryption hypertext transfer protocol

This document provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "Digest Access Authentication". [STANDARDS-TRACK]

draft-ietf-http-authentication-03 RFC2069 RFC7235 RFC7615 RFC7616 RFC7617 DRAFT STANDARD DRAFT STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2617 10.17487/RFC2617
RFC2618 RADIUS Authentication Client MIB B. Aboba G. Zorn June 1999 ASCII HTML 14 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication client functions. [STANDARDS-TRACK]

draft-ietf-radius-auth-clientmib-05 RFC4668 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2618
RFC2619 RADIUS Authentication Server MIB G. Zorn B. Aboba June 1999 ASCII HTML 16 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS authentication server functions. [STANDARDS-TRACK]

draft-ietf-radius-auth-servmib-05 RFC4669 PROPOSED STANDARD PROPOSED STANDARD IETF ops radius 10.17487/RFC2619
RFC2620 RADIUS Accounting Client MIB B. Aboba G. Zorn June 1999 ASCII HTML 13 management information base security remote access dialin user service

This memo defines a set of extensions which instrument RADIUS accounting client functions. This memo provides information for the Internet community.

draft-ietf-radius-acc-clientmib-05 RFC4670 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2620
RFC2621 RADIUS Accounting Server MIB G. Zorn B. Aboba June 1999 ASCII HTML 15 management information base security remote access,dialin user service

This memo defines a set of extensions which instrument RADIUS accounting server functions. This memo provides information for the Internet community.

draft-ietf-radius-acc-servmib-05 RFC4671 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2621
RFC2622 Routing Policy Specification Language (RPSL) C. Alaettinoglu C. Villamizar E. Gerich D. Kessens D. Meyer T. Bates D. Karrenberg M. Terpstra June 1999 ASCII HTML 69 RPSL internet policy hierarchy network configuration

RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]

draft-ietf-rps-rpsl-v2-03 RFC2280 RFC4012 RFC7909 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2622
RFC2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 M. Eisler June 1999 ASCII HTML 19 network file system remote procedure call architecture

This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. [STANDARDS-TRACK]

draft-ietf-nfsv4-nfssec-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC2623
RFC2624 NFS Version 4 Design Considerations S. Shepler June 1999 ASCII HTML 22 network file system

This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. This memo provides information for the Internet community.

draft-ietf-nfsv4-designconsider-03 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC2624
RFC2625 IP and ARP over Fibre Channel M. Rajagopal R. Bhagwat W. Rickard June 1999 ASCII HTML 63 internet protocal address resolution

The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. [STANDARDS-TRACK]

draft-ietf-ipfc-fibre-channel-06 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc http://www.rfc-editor.org/errata_search.php?rfc=2625 10.17487/RFC2625
RFC2626 The Internet and the Millennium Problem (Year 2000) P. Nesser II June 1999 ASCII HTML 275 Y2K

The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. This memo provides information for the Internet community.

draft-ietf-2000-issue-06 INFORMATIONAL INFORMATIONAL IETF ops 2000 http://www.rfc-editor.org/errata_search.php?rfc=2626 10.17487/RFC2626
RFC2627 Key Management for Multicast: Issues and Architectures D. Wallner E. Harder R. Agee June 1999 ASCII HTML 23 communication sessions net key rekey

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. This memo provides information for the Internet community.

draft-wallner-key-arch-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2627
RFC2628 Simple Cryptographic Program Interface (Crypto API) V. Smyslov June 1999 ASCII HTML 30 application security

This document describes a simple Application Program Interface to cryptographic functions. This memo provides information for the Internet community.

draft-smyslov-crypto-api-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2628
RFC2629 Writing I-Ds and RFCs using XML M. Rose June 1999 ASCII HTML 31 internet-drafts extensible markup language source format

This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.

draft-mrose-writing-rfcs-02 RFC7749 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2629
RFC2630 Cryptographic Message Syntax R. Housley June 1999 ASCII HTML 60 encryption certificate key management

This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. [STANDARDS-TRACK]

draft-ietf-smime-cms-13 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2630 10.17487/RFC2630
RFC2631 Diffie-Hellman Key Agreement Method E. Rescorla June 1999 ASCII HTML 13 encryption management certificate

This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK]

draft-ietf-smime-x942-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2631 10.17487/RFC2631
RFC2632 S/MIME Version 3 Certificate Handling B. Ramsdell Editor June 1999 ASCII HTML 13 encryption certificate multipurpose internet mail extensions secure

S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]

draft-ietf-smime-cert-08 RFC3850 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2632
RFC2633 S/MIME Version 3 Message Specification B. Ramsdell Editor June 1999 ASCII HTML 32 secure multipurpose internet mail extensions encryption

This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]

draft-ietf-smime-msg-08 RFC3851 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2633 10.17487/RFC2633
RFC2634 Enhanced Security Services for S/MIME P. Hoffman Editor June 1999 ASCII HTML 58 secure multipurpose internet mail extensions encryption

This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]

draft-ietf-smime-ess-12 RFC5035 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2634
RFC2635 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) S. Hambridge A. Lunde June 1999 ASCII HTML 18 electronic mail email users administrators managers

This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. This memo provides information for the Internet community.

draft-ietf-run-spew-08 FYI0035 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC2635
RFC2636 Wireless Device Configuration (OTASP/OTAPA) via ACAP R. Gellens July 1999 ASCII PS PDF HTML 29 over-the-air ota application configuration access protocol

This paper describes a viable and attractive means to provide OTASP/OTAPA via IS-707, using the ACAP protocol. This memo provides information for the Internet community.

RFC2604 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2636
RFC2637 Point-to-Point Tunneling Protocol (PPTP) K. Hamzeh G. Pall W. Verthein J. Taarud W. Little G. Zorn July 1999 ASCII HTML 57 IP tunnel encapsulation

This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network. This memo provides information for the Internet community.

draft-ietf-pppext-pptp-10 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2637 10.17487/RFC2637
RFC2638 A Two-bit Differentiated Services Architecture for the Internet K. Nichols V. Jacobson L. Zhang July 1999 ASCII PS PDF HTML 26 IP internet protocol header packets

This document presents a differentiated services architecture for the internet. This memo provides information for the Internet community.

draft-nichols-diff-svc-arch-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2638 10.17487/RFC2638
RFC2639 Internet Printing Protocol/1.0: Implementer's Guide T. Hastings C. Manros July 1999 ASCII HTML 64 IPP client object

This document contains information that supplements the IPP Model and Semantics and the IPP Transport and Encoding documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. This memo provides information for the Internet community.

draft-ietf-ipp-implementers-guide-01 RFC3196 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC2639
RFC2640 Internationalization of the File Transfer Protocol B. Curtin July 1999 ASCII HTML 27 ftp character sets languages

This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending the FTP specification and giving recommendations for proper internationalization support. [STANDARDS-TRACK]

draft-ietf-ftpext-intl-ftp-06 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=2640 10.17487/RFC2640
RFC2641 Cabletron's VlanHello Protocol Specification Version 4 D. Hamilton D. Ruffen August 1999 ASCII HTML 17 ISMP inter switch message protocol switches

The VlanHello protocol is part of the InterSwitch Message Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2641
RFC2642 Cabletron's VLS Protocol Specification L. Kane August 1999 ASCII HTML 95 Virtual LAN link ISMP inter switch message routing

VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2642
RFC2643 Cabletron's SecureFast VLAN Operational Model D. Ruffen T. Len J. Yanacek August 1999 ASCII HTML 60 SFVLAN switching data packets vitrual LANs

Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC2643
RFC2644 Changing the Default for Directed Broadcasts in Routers D. Senie August 1999 ASCII HTML 4 smurf amplifiers denial of service

This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

draft-senie-directed-broadcast-03 RFC1812 BCP0034 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2644
RFC2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses R. Gellens August 1999 ASCII HTML 9 ODMR-SMTP simple mail transfer protocol internet

This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]

draft-gellens-on-demand-07 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2645 10.17487/RFC2645
RFC2646 The Text/Plain Format Parameter R. Gellens Editor August 1999 ASCII HTML 14 media type mime multipurpose internet mail extension

This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]

draft-gellens-format-06 RFC3676 RFC2046 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2646
RFC2647 Benchmarking Terminology for Firewall Performance D. Newman August 1999 ASCII HTML 26 routers switches measurement

This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK]

draft-ietf-bmwg-secperf-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2647
RFC2648 A URN Namespace for IETF Documents R. Moats August 1999 ASCII HTML 30 uniform resource names internet engineering task force

This document proposes the "ietf" namespace, which consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor and the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences. [STANDARDS-TRACK]

draft-ietf-urn-ietf-09 RFC6924 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=2648 10.17487/RFC2648
RFC2649 An LDAP Control and Schema for Holding Operation Signatures B. Greenblatt P. Richard August 1999 ASCII HTML 10 lightweight directory access protocol client server

This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines an LDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ldapext-sigops-04 EXPERIMENTAL EXPERIMENTAL IETF app ldapext 10.17487/RFC2649
RFC2650 Using RPSL in Practice D. Meyer J. Schmitz C. Orange M. Prior C. Alaettinoglu August 1999 ASCII HTML 26 routing policy specification language IRR internet routing registry configurations

This document is a tutorial on using the Routing Policy Specification Language (RPSL) to describe routing policies in the Internet Routing Registry (IRR). This memo provides information for the Internet community.

draft-ietf-rps-appl-rpsl-06 INFORMATIONAL INFORMATIONAL IETF ops rps 10.17487/RFC2650
RFC2651 The Architecture of the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII HTML 19 CIP query routing database servers

This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. [STANDARDS-TRACK]

draft-ietf-find-cip-arch-02 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2651
RFC2652 MIME Object Definitions for the Common Indexing Protocol (CIP) J. Allen M. Mealling August 1999 ASCII HTML 22 multipurpose internet mail extensions database

This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. [STANDARDS-TRACK]

draft-ietf-find-cip-mime-03 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2652
RFC2653 CIP Transport Protocols J. Allen P. Leach R. Hedberg August 1999 ASCII HTML 11 common indexing message formats

This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP. [STANDARDS-TRACK]

draft-ietf-find-cip-trans-01 PROPOSED STANDARD PROPOSED STANDARD IETF app find 10.17487/RFC2653
RFC2654 A Tagged Index Object for use in the Common Indexing Protocol R. Hedberg B. Greenblatt R. Moats M. Wahl August 1999 ASCII HTML 24 CIP information servers database

This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the Common Indexing Protocol. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-cip-tagged-07 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2654
RFC2655 CIP Index Object Format for SOIF Objects T. Hardie M. Bowman D. Hardy M. Schwartz D. Wessels August 1999 ASCII HTML 17 summary object interchange format common indexing protocol

This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-cip-soif-02 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2655 10.17487/RFC2655
RFC2656 Registration Procedures for SOIF Template Types T. Hardie August 1999 ASCII HTML 9 summary object interchange format stream

The registration procedure described in this document is specific to SOIF template types. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-soif-registry-00 EXPERIMENTAL EXPERIMENTAL IETF app find http://www.rfc-editor.org/errata_search.php?rfc=2656 10.17487/RFC2656
RFC2657 LDAPv2 Client vs. the Index Mesh R. Hedberg August 1999 ASCII HTML 12 lightweight directory access protocol CIP common indexing

LDAPv2 clients as implemented according to RFC 1777 have no notion on referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-find-cip-ldapv2-02 EXPERIMENTAL EXPERIMENTAL IETF app find 10.17487/RFC2657
RFC2658 RTP Payload Format for PureVoice(tm) Audio K. McKay August 1999 ASCII HTML 10 real-time transport protocol packet end-to-end

This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]

draft-mckay-qcelp-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2658
RFC2659 Security Extensions For HTML E. Rescorla A. Schiffman August 1999 ASCII HTML 4 hyper-text markup language cryptology

This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-wts-shtml-05 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2659
RFC2660 The Secure HyperText Transfer Protocol E. Rescorla A. Schiffman August 1999 ASCII HTML 45 WWW world wide web http authentication

This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-wts-shttp-06 EXPERIMENTAL EXPERIMENTAL IETF sec wts 10.17487/RFC2660
RFC2661 Layer Two Tunneling Protocol "L2TP" W. Townsley A. Valencia A. Rubens G. Pall G. Zorn B. Palter August 1999 ASCII HTML 80 L2TP ppp point-to-point protocol packets

This document describes the Layer Two Tunneling Protocol (L2TP). [STANDARDS-TRACK]

draft-ietf-pppext-l2tp-16 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2661 10.17487/RFC2661
RFC2662 Definitions of Managed Objects for the ADSL Lines G. Bathrick F. Ly August 1999 ASCII HTML 115 MIB management information base

This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]

draft-ietf-adslmib-adsllinemib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=2662 10.17487/RFC2662
RFC2663 IP Network Address Translator (NAT) Terminology and Considerations P. Srisuresh M. Holdrege August 1999 ASCII HTML 30 network address translator IP internet protocol addresses

This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community.

draft-ietf-nat-terminology-03 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2663 10.17487/RFC2663
RFC2664 FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions R. Plzak A. Wells E. Krol August 1999 ASCII HTML 11 documentation help information FAQ

This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. This memo provides information for the Internet community.

draft-ietf-uswg-fyi4-bis-01 RFC1594 FYI0004 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC2664
RFC2665 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick J. Johnson August 1999 ASCII HTML 47 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-hubmib-etherif-mib-v2-04 RFC2358 RFC3635 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2665
RFC2666 Definitions of Object Identifiers for Identifying Ethernet Chip Sets J. Flick August 1999 ASCII HTML 18 mib management information base

This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. This memo provides information for the Internet community.

draft-ietf-hubmib-ether-chipsets-02 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC2666
RFC2667 IP Tunnel MIB D. Thaler August 1999 ASCII HTML 16 internet protocol management information base

This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]

draft-ietf-ifmib-tunnel-mib-06 RFC4087 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2667
RFC2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) A. Smith J. Flick K. de Graaf D. Romascanu D. McMaster K. McCloghrie S. Roberts August 1999 ASCII HTML 56 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-hubmib-mau-mib-v2-04 RFC2239 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC2668
RFC2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems M. St. Johns Editor August 1999 ASCII HTML 55 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

draft-ietf-ipcdn-cable-device-mib-08 RFC4639 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2669
RFC2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces M. St. Johns Editor August 1999 ASCII HTML 72 MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. [STANDARDS-TRACK]

draft-ietf-ipcdn-rf-interface-mib-07 RFC4546 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC2670
RFC2671 Extension Mechanisms for DNS (EDNS0) P. Vixie August 1999 ASCII HTML 7 EDNS0 domain name system resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]

draft-ietf-dnsind-edns0-02 RFC6891 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2671
RFC2672 Non-Terminal DNS Name Redirection M. Crawford August 1999 ASCII HTML 9 domain name system dname resource records

This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]

draft-ietf-dnsind-dname-03 RFC6672 RFC4592 RFC6604 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsind 10.17487/RFC2672
RFC2673 Binary Labels in the Domain Name System M. Crawford August 1999 ASCII HTML 7 DNS data

This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]

draft-ietf-dnsind-binary-labels-05 RFC6891 RFC1035 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int dnsind http://www.rfc-editor.org/errata_search.php?rfc=2673 10.17487/RFC2673
RFC2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions E. Bell A. Smith P. Langille A. Rijhsinghani K. McCloghrie August 1999 ASCII HTML 86 MIB management information base local area network

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. [STANDARDS-TRACK]

draft-ietf-bridge-bridgemib-06 RFC4363 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC2674
RFC2675 IPv6 Jumbograms D. Borman S. Deering R. Hinden August 1999 ASCII HTML 9 internet protocol packet payload link

This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]

draft-ietf-ipngwg-jumbograms-01 RFC2147 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2675 10.17487/RFC2675
RFC2676 QoS Routing Mechanisms and OSPF Extensions G. Apostolopoulos S. Kama D. Williams R. Guerin A. Orda T. Przygienda August 1999 ASCII HTML 50 quality of service open shortest path first routing

This memo describes extensions to the OSPF protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. This memo defines an Experimental Protocol for the Internet community.

draft-guerin-qos-routing-ospf-05 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2676 10.17487/RFC2676
RFC2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) M. Greene J. Cucchiara J. Luciani August 1999 ASCII HTML 67 NHRP-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-ion-nhrp-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2677
RFC2678 IPPM Metrics for Measuring Connectivity J. Mahdavi V. Paxson September 1999 ASCII HTML 10 IPPM-MET internet protocol performance metrics

This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]

RFC2498 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2678
RFC2679 A One-way Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII HTML 20 internet protocol performance metrics packets

This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]

draft-ietf-ippm-delay-07 RFC7679 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2679 10.17487/RFC2679
RFC2680 A One-way Packet Loss Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII HTML 15 internet protocol performance metrics

This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]

draft-ietf-ippm-loss-07 RFC7680 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2680 10.17487/RFC2680
RFC2681 A Round-trip Delay Metric for IPPM G. Almes S. Kalidindi M. Zekauskas September 1999 ASCII HTML 20 internet protocol performance metrics packets

This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]

draft-ietf-ippm-rt-delay-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=2681 10.17487/RFC2681
RFC2682 Performance Issues in VC-Merge Capable ATM LSRs I. Widjaja A. Elwalid September 1999 ASCII HTML 12 asynchronous transfer mode routing

This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. This memo provides information for the Internet community.

draft-widjaja-mpls-vc-merge-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2682
RFC2683 IMAP4 Implementation Recommendations B. Leiba September 1999 ASCII HTML 23 internet message access protocol clients servers

The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community.

draft-leiba-imap-implement-guide-10 RFC7162 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2683 10.17487/RFC2683
RFC2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 D. Grossman J. Heinanen September 1999 ASCII HTML 23 asynchronous,transfer mode multiplexing

This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. [STANDARDS-TRACK]

draft-ietf-ion-multiprotocol-atm-04 RFC1483 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2684
RFC2685 Virtual Private Networks Identifier B. Fox B. Gleeson September 1999 ASCII HTML 6 VPNI IP internet protocol VPN

This document proposes a format for a globally unique VPN identifier. [STANDARDS-TRACK]

draft-ietf-ion-vpn-id-02 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2685
RFC2686 The Multi-Class Extension to Multi-Link PPP C. Bormann September 1999 ASCII HTML 11 point-to-point protocol encapsulation

This document proposes the fragment-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

draft-ietf-issll-isslow-mcml-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2686
RFC2687 PPP in a Real-time Oriented HDLC-like Framing C. Bormann September 1999 ASCII HTML 13 point-to-point protocol encapsulation high-level data link control

This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. [STANDARDS-TRACK]

draft-ietf-issll-isslow-rtf-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2687
RFC2688 Integrated Services Mappings for Low Speed Networks S. Jackowski D. Putzolu E. Crawley B. Davie September 1999 ASCII HTML 16 controlled load guaranteed services

This document defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load and guaranteed services. [STANDARDS-TRACK]

draft-ietf-issll-isslow-svcmap-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2688
RFC2689 Providing Integrated Services over Low-bitrate Links C. Bormann September 1999 ASCII HTML 14 asynchronous synchronous real-time

This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links. This memo provides information for the Internet community.

draft-ietf-issll-isslow-06 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2689
RFC2690 A Proposal for an MOU-Based ICANN Protocol Support Organization S. Bradner September 1999 ASCII HTML 8 pso memorandum of understanding internet corporation for assigned names and numbers

This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community.

draft-ietf-poisson-mou-pso-00 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2690
RFC2691 A Memorandum of Understanding for an ICANN Protocol Support Organization S. Bradner September 1999 ASCII HTML 9 mou pso internet corporation for assigned names and numbers

This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers (ICANN). This memo provides information for the Internet community.

draft-ietf-poisson-pso-mou-01 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2691
RFC2692 SPKI Requirements C. Ellison September 1999 ASCII HTML 14 SPKI simple public key infrastructure authentication

The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-spki-cert-req-03 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2692
RFC2693 SPKI Certificate Theory C. Ellison B. Frantz B. Lampson R. Rivest B. Thomas T. Ylonen September 1999 ASCII HTML 43 SPKI simple public key infrastructure authentication

This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-spki-cert-theory-05 EXPERIMENTAL EXPERIMENTAL IETF sec spki 10.17487/RFC2693
RFC2694 DNS extensions to Network Address Translators (DNS_ALG) P. Srisuresh G. Tsirtsis P. Akkiraju A. Heffernan September 1999 ASCII HTML 29 domain name system NATs mapping

This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need. This memo provides information for the Internet community.

draft-ietf-nat-dns-alg-04 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2694 10.17487/RFC2694
RFC2695 Authentication Mechanisms for ONC RPC A. Chiu September 1999 ASCII HTML 18 remote procedure call open network computing

This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community.

draft-ietf-oncrpc-auth-06 INFORMATIONAL INFORMATIONAL IETF tsv oncrpc 10.17487/RFC2695
RFC2696 LDAP Control Extension for Simple Paged Results Manipulation C. Weider A. Herron A. Anantha T. Howes September 1999 ASCII HTML 7 lightweight directory access protocol client server

This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community.

draft-ietf-asid-ldapv3-simplepaged-03 INFORMATIONAL INFORMATIONAL IETF app ldapext 10.17487/RFC2696
RFC2697 A Single Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII HTML 6 srtcm stream ip internet protocol packet

This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

draft-heinanen-diffserv-srtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2697
RFC2698 A Two Rate Three Color Marker J. Heinanen R. Guerin September 1999 ASCII HTML 5 trTCM stream ip internet protocol packet

This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.

draft-heinanen-diffserv-trtcm-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2698
RFC2699 Request for Comments Summary RFC Numbers 2600-2699 S. Ginoza May 2000 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2699 RFC2700 Internet Official Protocol Standards J. Reynolds R. Braden August 2000 ASCII HTML 32

This memo describes the current state of standardization of protocols used in the Internet as determined by the Internet Engineering Task Force (IETF). [STANDARDS-TRACK]

RFC2600 RFC2800 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2700 10.17487/RFC2700
RFC2701 Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol G. Malkin September 1999 ASCII HTML 9 point-to-point POP presence RAS remote access server

This document specifies a standard way for Multi-link PPP to operate across multiple nodes. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC2701
RFC2702 Requirements for Traffic Engineering Over MPLS D. Awduche J. Malcolm J. Agogbua M. O'Dell J. McManus September 1999 ASCII HTML 29 multiprotocol label switching

This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.

draft-ietf-mpls-traffic-eng-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=2702 10.17487/RFC2702
RFC2703 Protocol-independent Content Negotiation Framework G. Klyne September 1999 ASCII HTML 20 feature resource media syntax

This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. This memo provides information for the Internet community.

draft-ietf-conneg-requirements-02 INFORMATIONAL INFORMATIONAL IETF app conneg 10.17487/RFC2703
RFC2704 The KeyNote Trust-Management System Version 2 M. Blaze J. Feigenbaum J. Ioannidis A. Keromytis September 1999 ASCII HTML 37 security policy maker system credentials

This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. This memo provides information for the Internet community.

draft-blaze-ietf-trustmgt-keynote-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2704
RFC2705 Media Gateway Control Protocol (MGCP) Version 1.0 M. Arango A. Dugan I. Elliott C. Huitema S. Pickett October 1999 ASCII HTML 134 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements. This memo provides information for the Internet community.

draft-huitema-megaco-mgcp-v1-00 RFC3435 RFC3660 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2705
RFC2706 ECML v1: Field Names for E-Commerce D. Eastlake 3rd T. Goldstein October 1999 ASCII HTML 13 electronic commerce modeling language merchant site. web

A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. This memo provides information for the Internet community.

draft-eastlake-ecom-fields-01 RFC3106 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2706
RFC2707 Job Monitoring MIB - V1.0 R. Bergman T. Hastings S. Isaacson H. Lewis November 1999 ASCII HTML 114 management information base

This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This memo provides information for the Internet community.

draft-ietf-printmib-job-monitor-08 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2707
RFC2708 Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB R. Bergman November 1999 ASCII HTML 26 management information base

This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB. This memo provides information for the Internet community.

draft-ietf-printmib-job-protomap-04 INFORMATIONAL INFORMATIONAL IETF app printmib 10.17487/RFC2708
RFC2709 Security Model with Tunnel-mode IPsec for NAT Domains P. Srisuresh October 1999 ASCII HTML 11 internet protocol network address translator

This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. This memo provides information for the Internet community.

draft-ietf-nat-security-02 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC2709
RFC2710 Multicast Listener Discovery (MLD) for IPv6 S. Deering W. Fenner B. Haberman October 1999 ASCII HTML 22 MLD-IPv6 internet protocol routher packets

This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]

draft-ietf-ipngwg-mld-02 RFC3590 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2710
RFC2711 IPv6 Router Alert Option C. Partridge A. Jackson October 1999 ASCII HTML 6 internet protocol datagram routher hop-by-hop

This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]

draft-ietf-ipngwg-ipv6router-alert-06 RFC6398 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2711
RFC2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) A. Medvinsky M. Hur October 1999 ASCII HTML 7 TLS authentication cryptography

This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS-TRACK]

draft-ietf-tls-kerb-cipher-suites-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2712 10.17487/RFC2712
RFC2713 Schema for Representing Java(tm) Objects in an LDAP Directory V. Ryan S. Seligman R. Lee October 1999 ASCII HTML 21 lightweight directory access protocol

This document defines the schema for representing Java(tm) objects in an LDAP directory. This memo provides information for the Internet community.

draft-ryan-java-schema-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2713
RFC2714 Schema for Representing CORBA Object References in an LDAP Directory V. Ryan R. Lee S. Seligman October 1999 ASCII HTML 10 lightweight directory access protocol

This document defines the schema for representing CORBA object references in an LDAP directory. This memo provides information for the Internet community.

draft-ryan-corba-schema-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2714
RFC2715 Interoperability Rules for Multicast Routing Protocols D. Thaler October 1999 ASCII HTML 22 border router MBRs autonomous

The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains. This memo provides information for the Internet community.

draft-thaler-multicast-interop-03 INFORMATIONAL INFORMATIONAL IETF rtg idmr 10.17487/RFC2715
RFC2716 PPP EAP TLS Authentication Protocol B. Aboba D. Simon October 1999 ASCII HTML 24 point-to-point link control compression extensible transport level security

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pppext-eaptls-06 RFC5216 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2716
RFC2717 Registration Procedures for URL Scheme Names R. Petke I. King November 1999 ASCII HTML 10 uniform resource locator syntax semantics

This document defines the process by which new URL scheme names are registered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urlreg-procedures-08 RFC4395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urlreg 10.17487/RFC2717
RFC2718 Guidelines for new URL Schemes L. Masinter H. Alvestrand D. Zigmond R. Petke November 1999 ASCII HTML 10 uniform resource locator syntax semantics

This document provides guidelines for the definition of new URL schemes. This memo provides information for the Internet community.

draft-ietf-urlreg-guide-05 RFC4395 INFORMATIONAL INFORMATIONAL IETF app urlreg 10.17487/RFC2718
RFC2719 Framework Architecture for Signaling Transport L. Ong I. Rytina M. Garcia H. Schwarzbauer L. Coene H. Lin I. Juhasz M. Holdrege C. Sharp October 1999 ASCII HTML 24 IP Internet Protocol gateway media circuit

This document defines an architecture framework and functional requirements for transport of signaling information over IP. This memo provides information for the Internet community.

draft-ietf-sigtran-framework-arch-03 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC2719
RFC2720 Traffic Flow Measurement: Meter MIB N. Brownlee October 1999 ASCII HTML 55 management information base

This document defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised. [STANDARDS-TRACK]

draft-ietf-rtfm-meter-mib-11 RFC2064 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rtfm 10.17487/RFC2720
RFC2721 RTFM: Applicability Statement N. Brownlee October 1999 ASCII HTML 10 real-time traffic flow measurement

This document provides an overview covering all aspects of Realtime Traffic Flow Measurement, including its area of applicability and its limitations. This memo provides information for the Internet community.

draft-ietf-rtfm-applicability-statement-04 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2721
RFC2722 Traffic Flow Measurement: Architecture N. Brownlee C. Mills G. Ruth October 1999 ASCII HTML 48 network meters data

This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within the Internet. This memo provides information for the Internet community.

draft-ietf-rtfm-architecture-08 RFC2063 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2722
RFC2723 SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups N. Brownlee October 1999 ASCII HTML 22 simple ruleset RTFM real-time network measurement

This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. This memo provides information for the Internet community.

draft-ietf-rtfm-ruleset-language-07 INFORMATIONAL INFORMATIONAL IETF tsv rtfm 10.17487/RFC2723
RFC2724 RTFM: New Attributes for Traffic Flow Measurement S. Handelman S. Stibler N. Brownlee G. Ruth October 1999 ASCII HTML 18 real-time network

This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rtfm-new-traffic-flow-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rtfm 10.17487/RFC2724
RFC2725 Routing Policy System Security C. Villamizar C. Alaettinoglu D. Meyer S. Murphy December 1999 ASCII HTML 41 RPSL database registry authentication

The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model. [STANDARDS-TRACK]

draft-ietf-rps-auth-04 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2725
RFC2726 PGP Authentication for RIPE Database Updates J. Zsako December 1999 ASCII HTML 11 pretty good privacy security digital signatures

This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. [STANDARDS-TRACK]

draft-ietf-rps-dbsec-pgp-authent-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2726
RFC2727 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin February 2000 ASCII HTML 15 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-poisson-nomcom-v2-01 RFC2282 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC2727
RFC2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal R. Panabaker S. Wegerif D. Zigmond November 1999 ASCII HTML 23 internet protocol IPVBI

This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS-TRACK]

draft-ietf-ipvbi-nabts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipvbi 10.17487/RFC2728
RFC2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications P. Bagnall R. Briscoe A. Poppitt December 1999 ASCII HTML 27 LSMA dynamic protocol mapping

The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). This memo provides information for the Internet community.

draft-ietf-lsma-requirements-04 INFORMATIONAL INFORMATIONAL IETF app lsma 10.17487/RFC2729
RFC2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) S. Hanna B. Patel M. Shah December 1999 ASCII HTML 53 MADCAP client server scope zone host

This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. [STANDARDS-TRACK]

draft-ietf-malloc-madcap-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2730
RFC2731 Encoding Dublin Core Metadata in HTML J. Kunze December 1999 ASCII HTML 23 hypertext markup language xml extensible

The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community.

draft-kunze-dchtml-02 RFC5791 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2731 10.17487/RFC2731
RFC2732 Format for Literal IPv6 Addresses in URL's R. Hinden B. Carpenter L. Masinter December 1999 ASCII HTML 5 Internet protocol uniform resource identifier www world wide web

This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. [STANDARDS-TRACK]

draft-ietf-ipngwg-url-literal-04 RFC3986 RFC2396 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=2732 10.17487/RFC2732
RFC2733 An RTP Payload Format for Generic Forward Error Correction J. Rosenberg H. Schulzrinne December 1999 ASCII HTML 26 FEC real-time protocol stream

This document specifies a payload format for generic forward error correction of media encapsulated in RTP. [STANDARDS-TRACK]

draft-ietf-avt-fec-08 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2733
RFC2734 IPv4 over IEEE 1394 P. Johansson December 1999 ASCII HTML 29 internet protocol datagrams packet encapsulation ARP address resolution multicast

This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS-TRACK]

draft-ietf-ip1394-ipv4-19 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2734
RFC2735 NHRP Support for Virtual Private Networks B. Fox B. Petri December 1999 ASCII HTML 12 next hop resolution protocol VPN addresses

The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the NBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address. This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network. [STANDARDS-TRACK]

draft-ietf-ion-nhrp-vpn-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ion 10.17487/RFC2735
RFC2736 Guidelines for Writers of RTP Payload Format Specifications M. Handley C. Perkins December 1999 ASCII HTML 10 real-time transport protocol data types audio video codecs

This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-avt-rtp-format-guidelines-04 RFC8088 BCP0036 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC2736
RFC2737 Entity MIB (Version 2) K. McCloghrie A. Bierman December 1999 ASCII HTML 56 management information base SNMP simple network protocol

This memo defines a portion of the Management Information Base (M for use with network management protocols in the Internet communi In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]

draft-ietf-entmib-v2-06 RFC2037 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=2737 10.17487/RFC2737
RFC2738 Corrections to "A Syntax for Describing Media Feature Sets" G. Klyne December 1999 ASCII HTML 5 FEC real-time protocol stream

In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates. [STANDARDS-TRACK]

draft-ietf-conneg-feature-syntax-er-00 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2738
RFC2739 Calendar Attributes for vCard and LDAP T. Small D. Hennessy F. Dawson January 2000 ASCII HTML 16 lightweight directory access protocol

This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. [STANDARDS-TRACK]

draft-ietf-calsch-locating-03 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF app calsch 10.17487/RFC2739
RFC2740 OSPF for IPv6 R. Coltun D. Ferguson J. Moy December 1999 ASCII HTML 80 internet protocol open shortest path first

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). [STANDARDS-TRACK]

draft-ietf-ospf-ospfv6-08 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=2740 10.17487/RFC2740
RFC2741 Agent Extensibility (AgentX) Protocol Version 1 M. Daniele B. Wijnen M. Ellison D. Francisco January 2000 ASCII HTML 91 SNMP simple network management

This memo defines a standardized framework for extensible SNMP agents. [STANDARDS-TRACK]

draft-ietf-agentx-rfc-update-03 RFC2257 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2741
RFC2742 Definitions of Managed Objects for Extensible SNMP Agents L. Heintz S. Gudur M. Ellison January 2000 ASCII HTML 20 SNMP management information base simple network protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. [STANDARDS-TRACK]

draft-ietf-agentx-mib-05 DRAFT STANDARD PROPOSED STANDARD IETF ops agentx 10.17487/RFC2742
RFC2743 Generic Security Service Application Program Interface Version 2, Update 1 J. Linn January 2000 ASCII HTML 101 GSS-API portability application authentication cryptology

This memo obsoletes [STANDARDS-TRACK]

draft-ietf-cat-rfc2078bis-08 RFC2078 RFC5554 RFC5896 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2743 10.17487/RFC2743
RFC2744 Generic Security Service API Version 2 : C-bindings J. Wray January 2000 ASCII HTML 101 GSS-API cryptology authentication

This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC 2743. [STANDARDS-TRACK]

draft-ietf-cat-gssv2-cbind-09 RFC1509 RFC5896 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat http://www.rfc-editor.org/errata_search.php?rfc=2744 10.17487/RFC2744
RFC2745 RSVP Diagnostic Messages A. Terzis B. Braden S. Vincent L. Zhang January 2000 ASCII HTML 23 resource reservation protocol network management

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]

draft-ietf-rsvp-diagnostic-msgs-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2745
RFC2746 RSVP Operation Over IP Tunnels A. Terzis J. Krawczyk J. Wroclawski L. Zhang January 2000 ASCII HTML 25 resource reservation protocol internet

This document describes an approach for providing RSVP protocol services over IP tunnels. [STANDARDS-TRACK]

draft-ietf-rsvp-tunnel-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2746
RFC2747 RSVP Cryptographic Authentication F. Baker B. Lindell M. Talwar January 2000 ASCII HTML 21 resource reservation protocol security

This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK]

draft-ietf-rsvp-md5-08 RFC3097 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp http://www.rfc-editor.org/errata_search.php?rfc=2747 10.17487/RFC2747
RFC2748 The COPS (Common Open Policy Service) Protocol D. Durham Editor J. Boyle R. Cohen S. Herzog R. Rajan A. Sastry January 2000 ASCII HTML 38 COPS qos quality of service signaling

This document describes a simple client/server model for supporting policy control over QoS signaling protocols. [STANDARDS-TRACK]

draft-ietf-rap-cops-08 RFC4261 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2748
RFC2749 COPS usage for RSVP S. Herzog Editor J. Boyle R. Cohen D. Durham R. Rajan A. Sastry January 2000 ASCII HTML 17 common open policy resource reservation protocol

This document describes usage directives for supporting COPS policy services in RSVP environments. [STANDARDS-TRACK]

draft-ietf-rap-cops-rsvp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2749
RFC2750 RSVP Extensions for Policy Control S. Herzog January 2000 ASCII HTML 13 resource reservation protocol admission

This memo presents a set of extensions for supporting generic policy based admission control in RSVP. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-ext-06 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2750
RFC2751 Signaled Preemption Priority Policy Element S. Herzog January 2000 ASCII HTML 12 RSVP COPS resource reservation protocol common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as RSVP and COPS). [STANDARDS-TRACK]

draft-ietf-rap-signaled-priority-04 RFC3181 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2751
RFC2752 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog January 2000 ASCII HTML 17 resource reservation protocol admission authentication

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in RSVP. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-identity-05 RFC3182 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2752
RFC2753 A Framework for Policy-based Admission Control R. Yavatkar D. Pendarakis R. Guerin January 2000 ASCII HTML 20

This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community.

draft-ietf-rap-framework-03 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC2753
RFC2754 RPS IANA Issues C. Alaettinoglu C. Villamizar R. Govindan January 2000 ASCII HTML 7 internet assigned numbers authority routing policy specification system security

RPS Security requires certain RPSL objects in the IRR to be hierarchically delegated. The set of objects that are at the root of this hierarchy needs to be created and digitally signed by IANA. This paper presents these seed objects and lists operations required from IANA. This memo provides information for the Internet community.

draft-ietf-rps-iana-02 RFC6254 HISTORIC INFORMATIONAL IETF ops rps 10.17487/RFC2754
RFC2755 Security Negotiation for WebNFS A. Chiu M. Eisler B. Callaghan January 2000 ASCII HTML 12 RSVP QOS resource reservation protocol quality of service

This document describes a protocol for a WebNFS client (RFC2054) to negotiate the desired security mechanism with a WebNFS server (RFC2055) before the WebNFS client falls back to the MOUNT v3 protocol (RFC1813). This document is provided so that people can write compatible implementations. This memo provides information for the Internet community.

draft-chiu-network-wnfs-sec-nego-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2755
RFC2756 Hyper Text Caching Protocol (HTCP/0.0) P. Vixie D. Wessels January 2000 ASCII HTML 15 HTCP hypertext transfer protocol caches data

This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. This memo defines an Experimental Protocol for the Internet community.

draft-vixie-htcp-proto-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2756
RFC2757 Long Thin Networks G. Montenegro S. Dawkins M. Kojo V. Magret N. Vaidya January 2000 ASCII HTML 46 wireless WAN wide area networks TCP transmission control protocol

Our goal is to identify a TCP that works for all users, including users of long thin networks. This memo provides information for the Internet community.

draft-montenegro-pilc-ltn-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2757
RFC2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring K. White February 2000 ASCII HTML 71 MIB management information base SLAs

This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. This memo defines an Experimental Protocol for the Internet community.

draft-white-slapm-mib-06 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2758
RFC2759 Microsoft PPP CHAP Extensions, Version 2 G. Zorn January 2000 ASCII HTML 20 point-to-point protocol challenge handshake authentication

This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community.

draft-ietf-pppext-mschap-v2-04 INFORMATIONAL INFORMATIONAL IETF int pppext http://www.rfc-editor.org/errata_search.php?rfc=2759 10.17487/RFC2759
RFC2760 Ongoing TCP Research Related to Satellites M. Allman Editor S. Dawkins D. Glover J. Griner D. Tran T. Henderson J. Heidemann J. Touch H. Kruse S. Ostermann K. Scott J. Semke February 2000 ASCII HTML 46 transmission control protocol bandwidth network links

This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. This memo provides information for the Internet community.

draft-ietf-tcpsat-res-issues-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpsat 10.17487/RFC2760
RFC2761 Terminology for ATM Benchmarking J. Dunn C. Martin February 2000 ASCII HTML 32 asynchronous transfer mode performance

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices. This memo provides information for the Internet community.

draft-ietf-bmwg-atm-term-00 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC2761
RFC2762 Sampling of the Group Membership in RTP J. Rosenberg H. Schulzrinne February 2000 ASCII HTML 12 real-time transport protocol packets

This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-avt-rtpsample-06 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC2762
RFC2763 Dynamic Hostname Exchange Mechanism for IS-IS N. Shen H. Smit February 2000 ASCII HTML 5 intermediate system routers TLV

This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. This memo provides information for the Internet community.

draft-ietf-isis-dyname-02 RFC5301 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=2763 10.17487/RFC2763
RFC2764 A Framework for IP Based Virtual Private Networks B. Gleeson A. Lin J. Heinanen G. Armitage A. Malis February 2000 ASCII HTML 62 VPN internet protocol backbone

This document describes a framework for Virtual Private Networks (VPNs) running across IP backbones. This memo provides information for the Internet community.

draft-gleeson-vpn-framework-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2764 10.17487/RFC2764
RFC2765 Stateless IP/ICMP Translation Algorithm (SIIT) E. Nordmark February 2000 ASCII HTML 26 SIIT internet protocol control message IPv4 IPv6

This document specifies a transition mechanism algorithm in addition to the mechanisms already specified. [STANDARDS-TRACK]

draft-ietf-ngtrans-siit-08 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2765
RFC2766 Network Address Translation - Protocol Translation (NAT-PT) G. Tsirtsis P. Srisuresh February 2000 ASCII HTML 21 NAT-PT IPv4 IPv6 internet

This document specifies an IPv4-to-IPv6 transition mechanism, in addition to those already specified. [STANDARDS-TRACK]

draft-ietf-ngtrans-natpt-07 RFC4966 RFC3152 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2766
RFC2767 Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) K. Tsuchiya H. Higuchi Y. Atarashi February 2000 ASCII HTML 13 IPv4 IPv6 internet protocol applications

This memo proposes a mechanism of dual stack hosts using the technique called "Bump-in-the-Stack" in the IP security area. This memo provides information for the Internet community.

draft-ietf-ngtrans-bis-00 RFC6535 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2767
RFC2768 Network Policy and Services: A Report of a Workshop on Middleware B. Aiken J. Strassner B. Carpenter I. Foster C. Lynch J. Mambretti R. Moore B. Teitelbaum February 2000 ASCII HTML 29 protocols internet applications

An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. This memo provides information for the Internet community.

draft-aiken-middleware-reqndef-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2768
RFC2769 Routing Policy System Replication C. Villamizar C. Alaettinoglu R. Govindan D. Meyer February 2000 ASCII HTML 42 RPSL database language

This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC. [STANDARDS-TRACK]

draft-ietf-rps-dist-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops rps 10.17487/RFC2769
RFC2770 GLOP Addressing in 233/8 D. Meyer P. Lothberg February 2000 ASCII HTML 5 multicast allocation global

This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mboned-glop-addressing-02 RFC3180 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC2770
RFC2771 An Abstract API for Multicast Address Allocation R. Finlayson February 2000 ASCII HTML 11 application programming interfaces service

This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. This memo provides information for the Internet community.

draft-ietf-malloc-api-07 INFORMATIONAL INFORMATIONAL IETF tsv malloc 10.17487/RFC2771
RFC2772 6Bone Backbone Routing Guidelines R. Rockell R. Fink February 2000 ASCII HTML 14 IP internet protocol routing

This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. This memo provides information for the Internet community.

draft-ietf-ngtrans-harden-04 RFC2546 RFC3152 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2772
RFC2773 Encryption using KEA and SKIPJACK R. Housley P. Yee W. Nace February 2000 ASCII HTML 9 key exchange algorithm symmetric

This document defines a method to encrypt a file transfer using the FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)", (October

draft-ietf-cat-ftpkeasj-01 RFC0959 EXPERIMENTAL EXPERIMENTAL IETF sec cat 10.17487/RFC2773
RFC2774 An HTTP Extension Framework H. Nielsen P. Leach S. Lawrence February 2000 ASCII HTML 20 hyper-text transfer protocol

This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. This memo defines an Experimental Protocol for the Internet community.

draft-frystyk-http-extensions-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2774
RFC2775 Internet Transparency B. Carpenter February 2000 ASCII HTML 18 end-to-end network layer connectivity

This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency.

draft-carpenter-transparency-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2775
RFC2776 Multicast-Scope Zone Announcement Protocol (MZAP) M. Handley D. Thaler R. Kermode February 2000 ASCII HTML 27 MZAP packets addresses service location

This document defines a protocol, the Multicast-Scope Zone Announcement Protocol (MZAP), for discovering the multicast administrative scope zones that are relevant at a particular location. [STANDARDS-TRACK]

draft-ietf-mboned-mzap-06 HISTORIC PROPOSED STANDARD IETF ops mboned 10.17487/RFC2776
RFC2777 Publicly Verifiable Nomcom Random Selection D. Eastlake 3rd February 2000 ASCII HTML 16 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. This memo provides information for the Internet community.

draft-eastlake-selection-04 RFC3797 INFORMATIONAL INFORMATIONAL IETF gen Poisson 10.17487/RFC2777
RFC2778 A Model for Presence and Instant Messaging M. Day J. Rosenberg H. Sugano February 2000 ASCII HTML 17 service users MIME multipurpose Internet mail extensions

This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. This memo provides information for the Internet community.

draft-ietf-impp-model-03 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2778
RFC2779 Instant Messaging / Presence Protocol Requirements M. Day S. Aggarwal G. Mohr J. Vincent February 2000 ASCII HTML 26 MIME multipurpose Internet mail extensions service users

This document defines a minimal set of requirements that IMPP must meet. This memo provides information for the Internet community.

draft-ietf-impp-reqts-04 INFORMATIONAL INFORMATIONAL IETF app impp 10.17487/RFC2779
RFC2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers S. Bradner V. Paxson March 2000 ASCII HTML 10 internet assigned numbers authority IP

This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bradner-iana-allocation-05 RFC4443 RFC5237 RFC5771 RFC6335 RFC7045 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC2780
RFC2781 UTF-16, an encoding of ISO 10646 P. Hoffman F. Yergeau February 2000 ASCII HTML 14 unicode character data code point

This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community.

draft-hoffman-utf16-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2781
RFC2782 A DNS RR for specifying the location of services (DNS SRV) A. Gulbrandsen P. Vixie L. Esibov February 2000 ASCII HTML 12 DNS-SRV domain name system resource record

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]

draft-ietf-dnsind-rfc2052bis-05 RFC2052 RFC6335 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=2782 10.17487/RFC2782
RFC2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 J. Mogul D. Mills J. Brittenson J. Stone U. Windl March 2000 ASCII HTML 31 NTP time clock synchronization

RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. This memo provides information for the Internet community.

draft-mogul-pps-api-06 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2783
RFC2784 Generic Routing Encapsulation (GRE) D. Farinacci T. Li S. Hanks D. Meyer P. Traina March 2000 ASCII HTML 9 GRE packet size payload

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]

draft-meyer-gre-update-03 RFC2890 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2784 10.17487/RFC2784
RFC2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME R. Zuccherato March 2000 ASCII HTML 11 security multipurpose internet mail extensions

This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. This memo provides information for the Internet community.

draft-ietf-smime-small-subgroup-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC2785
RFC2786 Diffie-Helman USM Key Management Information Base and Textual Convention M. St. Johns March 2000 ASCII HTML 20 mib security user-based model Hellman

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges an set of objects which extend the usmUserTable to permit the use of DH key exchange in addition to the key change method. This memo defines an Experimental Protocol for the Internet community.

draft-stjohns-snmpv3-dhkeychange-mib-02 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2786 10.17487/RFC2786
RFC2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol B. Jewell D. Chuang March 2000 ASCII HTML 31 management information base

This specification defines an extension to the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol (VRRP). [STANDARDS-TRACK]

draft-ietf-vrrp-mib-09 RFC6527 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp 10.17487/RFC2787
RFC2788 Network Services Monitoring MIB N. Freed S. Kille March 2000 ASCII HTML 22 management information base

This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS-TRACK]

draft-ietf-madman-netsm-mib-07 RFC2248 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2788
RFC2789 Mail Monitoring MIB N. Freed S. Kille March 2000 ASCII HTML 33 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [STANDARDS-TRACK]

draft-ietf-madman-email-mib-06 RFC2249 RFC1566 PROPOSED STANDARD PROPOSED STANDARD IETF app madman 10.17487/RFC2789
RFC2790 Host Resources MIB S. Waldbusser P. Grillo March 2000 ASCII HTML 50 management information base

This memo obsoletes RFC 1514, the "Host Resources MIB". This memo extends that specification by clarifying changes based on implementation and deployment experience and documenting the Host Resources MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB. [STANDARDS-TRACK]

draft-ops-hostmib-01 RFC1514 DRAFT STANDARD DRAFT STANDARD Legacy 10.17487/RFC2790
RFC2791 Scalable Routing Design Principles J. Yu July 2000 ASCII HTML 26 network packets

This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. This memo provides information for the Internet community.

draft-yu-routing-scaling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2791
RFC2792 DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System M. Blaze J. Ioannidis A. Keromytis March 2000 ASCII HTML 7 cryptology digial signatures

This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. This memo provides information for the Internet community.

draft-angelos-keynote-dsa-rsa-encoding-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2792
RFC2793 RTP Payload for Text Conversation G. Hellstrom May 2000 ASCII HTML 10 real-time applications video audio packets

This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. [STANDARDS-TRACK]

draft-ietf-avt-rtp-text-05 RFC4103 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2793
RFC2794 Mobile IP Network Access Identifier Extension for IPv4 P. Calhoun C. Perkins March 2000 ASCII HTML 9 internet protocol NAI

Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. [STANDARDS-TRACK]

draft-ietf-mobileip-mn-nai-07 RFC2290 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC2794
RFC2795 The Infinite Monkey Protocol Suite (IMPS) S. Christey April 1 2000 ASCII HTML 20 control packet client

This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community.

draft-christey-imps-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2795
RFC2796 BGP Route Reflection - An Alternative to Full Mesh IBGP T. Bates R. Chandra E. Chen April 2000 ASCII HTML 11 border gateway protocol

This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. [STANDARDS-TRACK]

draft-ietf-idr-route-reflect-v2-03 RFC4456 RFC1966 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2796
RFC2797 Certificate Management Messages over CMS M. Myers X. Liu J. Schaad J. Weinstein April 2000 ASCII HTML 47 certificate management protocol cryptology syntax

This document defines a Certificate Management protocol using CMS (CMC). [STANDARDS-TRACK]

draft-ietf-pkix-cmc-05 RFC5272 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=2797 10.17487/RFC2797
RFC2798 Definition of the inetOrgPerson LDAP Object Class M. Smith April 2000 ASCII HTML 20 lightweight directory access protocol directory services

We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. This memo provides information for the Internet community.

draft-smith-ldap-inetorgperson-03 RFC3698 RFC4519 RFC4524 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2798
RFC2799 Request for Comments Summary RFC Numbers 2700-2799 S. Ginoza September 2000 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2799 RFC2800 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza May 2001 ASCII HTML 38

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of April 17, 2001. It lists only official protocol standards RFCs; it is not a complete index to the RFC series. [STANDARDS-TRACK]

RFC2700 RFC2900 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2800
RFC2801 Internet Open Trading Protocol - IOTP Version 1.0 D. Burdett April 2000 ASCII HTML 290 commerce payment system merchant

This document discusses the Internet Open Trading Protocol (IOTP) and its provision of an interoperable framework for Internet commerce. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-protocol-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2801
RFC2802 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) K. Davidson Y. Kawatsura April 2000 ASCII HTML 29 commerce payment system xml extensible markup language security

This document describes the syntax and procedures for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP). This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-dsig-05 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=2802 10.17487/RFC2802
RFC2803 Digest Values for DOM (DOMHASH) H. Maruyama K. Tamura N. Uramoto April 2000 ASCII HTML 11 xml extensible markup language secruity

This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This memo provides information for the Internet community.

draft-ietf-trade-hiroshi-dom-hash-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2803
RFC2804 IETF Policy on Wiretapping IAB IESG May 2000 ASCII HTML 10 internet engineering task force

This document describes the position that the Internet Engineering Task Force (IETF) has taken regarding the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. This memo provides information for the Internet community.

draft-iab-raven-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2804 10.17487/RFC2804
RFC2805 Media Gateway Control Protocol Architecture and Requirements N. Greene M. Ramalho B. Rosen April 2000 ASCII HTML 45 MG mapping transcoding network

This document describes protocol requirements for the Media Gateway Control Protocol between a Media Gateway Controller and a Media Gateway. This memo provides information for the Internet community.

draft-ietf-megaco-reqs-10 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC2805
RFC2806 URLs for Telephone Calls A. Vaha-Sipila April 2000 ASCII HTML 21 uniform resource locator schemes

This document specifies URL (Uniform Resource Locator) schemes "tel", "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. [STANDARDS-TRACK]

draft-antti-telephony-url-12 RFC3966 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2806
RFC2807 XML Signature Requirements J. Reagle July 2000 ASCII HTML 9 digital extensible markup language

This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. This memo provides information for the Internet community.

draft-ietf-xmldsig-requirements-03 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC2807
RFC2808 The SecurID(r) SASL Mechanism M. Nystrom April 2000 ASCII HTML 11 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism using SecurID (a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication), thereby providing a means for such tokens to be used in SASL environments. This mechanism is only is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services. This memo provides information for the Internet community.

draft-nystrom-securid-sasl-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2808
RFC2809 Implementation of L2TP Compulsory Tunneling via RADIUS B. Aboba G. Zorn April 2000 ASCII HTML 23 remote authentication dial-in user service layer two

This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using the L2TP (Layer Two Tunneling Protocol) protocol. This memo provides information for the Internet community.

draft-ietf-radius-tunnel-imp-05 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2809
RFC2810 Internet Relay Chat: Architecture C. Kalt April 2000 ASCII HTML 10 IRC text based conferencing

This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. This memo provides information for the Internet community.

draft-kalt-irc-arch-00 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2810 10.17487/RFC2810
RFC2811 Internet Relay Chat: Channel Management C. Kalt April 2000 ASCII HTML 19 IRC text based conferencing

This document specifies how channels, their characteristics and properties are managed by IRC servers. This memo provides information for the Internet community.

draft-kalt-irc-chan-01 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2811
RFC2812 Internet Relay Chat: Client Protocol C. Kalt April 2000 ASCII HTML 63 IRC text based conferencing

This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture. This memo provides information for the Internet community.

draft-kalt-irc-client-03 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2812 10.17487/RFC2812
RFC2813 Internet Relay Chat: Server Protocol C. Kalt April 2000 ASCII HTML 26 IRC text based conferencing

This document defines the protocol used by servers to talk to each other. This memo provides information for the Internet community.

draft-kalt-irc-server-02 RFC1459 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2813 10.17487/RFC2813
RFC2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks R. Yavatkar D. Hoffman Y. Bernet F. Baker M. Speer May 2000 ASCII HTML 60 LAN local area resource reservation

This document describes a signaling method and protocol for RSVP-based admission control over IEEE 802-style LANs. [STANDARDS-TRACK]

draft-ietf-issll-is802-sbm-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2814
RFC2815 Integrated Service Mappings on IEEE 802 Networks M. Seaman A. Smith E. Crawley J. Wroclawski May 2000 ASCII HTML 17 LAN local area resource reservation

This document describes mappings of IETF Integrated Services over LANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). [STANDARDS-TRACK]

draft-ietf-issll-is802-svc-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2815
RFC2816 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies A. Ghanwani J. Pace V. Srinivasan A. Smith M. Seaman May 2000 ASCII HTML 47 LAN local area network parameter switches

This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. This memo provides information for the Internet community.

draft-ietf-issll-is802-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2816
RFC2817 Upgrading to TLS Within HTTP/1.1 R. Khare S. Lawrence May 2000 ASCII HTML 13 hypertext transfer protocol transport layer security

This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]

draft-ietf-tls-http-upgrade-05 RFC2616 RFC7230 RFC7231 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2817 10.17487/RFC2817
RFC2818 HTTP Over TLS E. Rescorla May 2000 ASCII HTML 7 hypertext transfer protocol transport layer security

This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.

draft-ietf-tls-https-04 RFC5785 RFC7230 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=2818 10.17487/RFC2818
RFC2819 Remote Network Monitoring Management Information Base S. Waldbusser May 2000 ASCII HTML 98 RMON-MIB MIB RMON

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmonfull-02 RFC1757 STD0059 INTERNET STANDARD INTERNET STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=2819 10.17487/RFC2819
RFC2820 Access Control Requirements for LDAP E. Stokes D. Byrne B. Blakley P. Behera May 2000 ASCII HTML 9 lightweight directory access protocol

This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. This memo provides information for the Internet community.

draft-ietf-ldapext-acl-reqts-03 INFORMATIONAL INFORMATIONAL IETF app ldapext http://www.rfc-editor.org/errata_search.php?rfc=2820 10.17487/RFC2820
RFC2821 Simple Mail Transfer Protocol J. Klensin Editor April 2001 ASCII HTML 79 SMTP

This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS-TRACK]

draft-ietf-drums-smtpupd-13 RFC0821 RFC0974 RFC1869 RFC5321 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2821 10.17487/RFC2821
RFC2822 Internet Message Format P. Resnick Editor April 2001 ASCII HTML 51 MAIL

This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]

draft-ietf-drums-msg-fmt-09 RFC0822 RFC5322 RFC5335 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app drums http://www.rfc-editor.org/errata_search.php?rfc=2822 10.17487/RFC2822
RFC2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing J. Carlson P. Langner E. Hernandez-Valencia J. Manchester May 2000 ASCII HTML 28 PPP-SDL point-to-point protocol synchronous optical network digital hierarchy data link simple

This document extends methods found in the Point-to-Point Protocol (PPP) and RFCs 1662 and 2615 to include a new encapsulation for PPP called Simple Data Link (SDL). SDL provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 and 2615 provide a means to carry PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pppext-sdl-06 EXPERIMENTAL EXPERIMENTAL IETF int pppext 10.17487/RFC2823
RFC2824 Call Processing Language Framework and Requirements J. Lennox H. Schulzrinne May 2000 ASCII HTML 25 CPL-F telephony signalling network devices

This document describes an architectural framework we call a processing language, as a simple and standardized way for implementing and deploying Internet telephony. A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. It also outlines requirements for such a language. This memo provides information for the Internet community.

draft-ietf-iptel-cpl-framework-02 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2824
RFC2825 A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols IAB L. Daigle Editor May 2000 ASCII HTML 7 character sets e-commerce interoperability

This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. This memo provides information for the Internet community.

draft-iab-i18n-dns-01 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2825 10.17487/RFC2825
RFC2826 IAB Technical Comment on the Unique DNS Root Internet Architecture Board May 2000 ASCII HTML 6 Internet Architecture Board domain name system

This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community.

draft-iab-unique-dns-root-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=2826 10.17487/RFC2826
RFC2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing P. Ferguson D. Senie May 2000 ASCII HTML 10 ISP Internet Service Provider Internet Protocol DOS

This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC2267 RFC3704 BCP0038 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2827 10.17487/RFC2827
RFC2828 Internet Security Glossary R. Shirey May 2000 ASCII HTML 212 information system ISD internet standard documents

This Glossary provides abbreviations, explanations, and recommendations for use of information system security terminology. This memo provides information for the Internet community.

draft-shirey-security-glossary-02 RFC4949 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2828
RFC2829 Authentication Methods for LDAP M. Wahl H. Alvestrand J. Hodges R. Morgan May 2000 ASCII HTML 16 lightweight directory access protocol security

This document specifies particular combinations of security mechanisms which are required and recommended in LDAP implementations. [STANDARDS-TRACK]

draft-ietf-ldapext-authmeth-04 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2829
RFC2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security J. Hodges R. Morgan M. Wahl May 2000 ASCII HTML 12 LDAP TLS

This document defines the "Start Transport Layer Security (TLS) Operation" for LDAP. [STANDARDS-TRACK]

draft-ietf-ldapext-ldapv3-tls-06 RFC4511 RFC4513 RFC4510 RFC3377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2830
RFC2831 Using Digest Authentication as a SASL Mechanism P. Leach C. Newman May 2000 ASCII HTML 27 http hypertext transfer protocol security simple layer

This specification defines how HTTP Digest Authentication can be used as a SASL mechanism for any protocol that has a SASL (Simple Authentication and Security Layer) profile. [STANDARDS-TRACK]

draft-leach-digest-sasl-05 RFC6331 HISTORIC PROPOSED STANDARD Legacy 10.17487/RFC2831
RFC2832 NSI Registry Registrar Protocol (RRP) Version 1.1.0 S. Hollenbeck M. Srivastava May 2000 ASCII HTML 39 RRP shared registration system gLTD ccTLD top level domain

This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This memo provides information for the Internet community.

draft-hollenbeck-rrp-01 RFC3632 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2832
RFC2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals H. Schulzrinne S. Petrack May 2000 ASCII HTML 30 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. [STANDARDS-TRACK]

draft-ietf-avt-tones-07 RFC4733 RFC4734 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2833
RFC2834 ARP and IP Broadcast over HIPPI-800 J.-M. Pittet May 2000 ASCII HTML 34 address resolution protocol internet high-performance internface parallel

This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP (hardware addresses). This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC 2067 "IP over HIPPI") obsoletes RFC 1374. [STANDARDS-TRACK]

draft-pittet-hippiarp-05 RFC1374 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2834 10.17487/RFC2834
RFC2835 IP and ARP over HIPPI-6400 (GSN) J.-M. Pittet May 2000 ASCII HTML 33 GSN address resolution protocol internet high-performance internface parallel

This document further specifies a method for resolving IP addresses to HIPPI-6400 (High-Performance Parallel Interface) hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore, it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks. [STANDARDS-TRACK]

draft-pittet-gsnlan-04 RFC5494 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2835
RFC2836 Per Hop Behavior Identification Codes S. Brim B. Carpenter F. Le Faucheur May 2000 ASCII HTML 7 PHB differentiated services codepoint DSCP

This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS-TRACK]

draft-ietf-diffserv-phbid-00 RFC3140 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC2836
RFC2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard K. Teow May 2000 ASCII HTML 48 MIB management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards. [STANDARDS-TRACK]

draft-ietf-ipfc-fabric-element-mib-07 RFC4044 PROPOSED STANDARD PROPOSED STANDARD IETF int ipfc 10.17487/RFC2837
RFC2838 Uniform Resource Identifiers for Television Broadcasts D. Zigmond M. Vickers May 2000 ASCII HTML 6 URI TV WWW world wide web

This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community.

draft-zigmond-tv-url-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2838
RFC2839 Internet Kermit Service F. da Cruz J. Altman May 2000 ASCII HTML 20 file transfer management service

This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community.

draft-columbia-kermit-service-03 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2839 10.17487/RFC2839
RFC2840 TELNET KERMIT OPTION J. Altman F. da Cruz May 2000 ASCII HTML 12 file transfer management service

This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community.

draft-altman-telnet-kermit-server-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2840
RFC2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC) P. Metzger W. Simpson November 2000 ASCII HTML 9 IP-MAC encryption secure hash algorithm

This document describes the use of keyed SHA1 (Secure Hash Algorithm) with the IP Authentication Header. This memo defines a Historic Document for the Internet community.

draft-simpson-ah-sha-kdp-00 RFC1852 HISTORIC HISTORIC Legacy 10.17487/RFC2841
RFC2842 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder May 2000 ASCII HTML 5 border gateway protocol

This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. [STANDARDS-TRACK]

draft-ietf-idr-bgp4-cap-neg-06 RFC3392 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2842
RFC2843 Proxy-PAR P. Droz T. Przygienda May 2000 ASCII HTML 13 PNNI augmented Routing ATM asynchronous transfer mode

The intention of this document is to provide general information about Proxy-PAR (PNNI Augmented Routing). [STANDARDS-TRACK]

draft-ietf-ion-proxypar-arch-02 INFORMATIONAL INFORMATIONAL IETF int ion 10.17487/RFC2843
RFC2844 OSPF over ATM and Proxy-PAR T. Przygienda P. Droz R. Haas May 2000 ASCII HTML 14 PNNI augmented Routing asynchronous transfer mode open shortest-path first

This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC (Permanent Virtual Connections) and SVC (Switched Virtual Circuit) meshes with the presence of Proxy-PAR (PNNI Augmented Routing). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ospf-atm-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC2844
RFC2845 Secret Key Transaction Authentication for DNS (TSIG) P. Vixie O. Gudmundsson D. Eastlake 3rd B. Wellington May 2000 ASCII HTML 15 TSIG domain name system transaction signature

This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]

draft-ietf-dnsext-tsig-00 RFC1035 RFC3645 RFC4635 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2845
RFC2846 GSTN Address Element Extensions in E-mail Services C. Allocchio June 2000 ASCII HTML 35 global switched telephone network

This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]

draft-ietf-fax-fulladdr-06 RFC3191 RFC3192 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=2846 10.17487/RFC2846
RFC2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM M. Eisler June 2000 ASCII HTML 22 LIPKEY client server simple pubilc key mechanism authentication

This memorandum describes a method whereby one can use GSS-API (Generic Security Service Application Program Interface) to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. [STANDARDS-TRACK]

draft-ietf-cat-lipkey-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2847
RFC2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services S. Petrack L. Conroy June 2000 ASCII HTML 73 session initiation protocol internet description

This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. [STANDARDS-TRACK]

draft-ietf-pint-protocol-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC2848
RFC2849 The LDAP Data Interchange Format (LDIF) - Technical Specification G. Good June 2000 ASCII HTML 14 LDIF lightweight directory access protocol file

This document describes a file format suitable for describing directory information or modifications made to directory information. [STANDARDS-TRACK]

draft-good-ldap-ldif-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2849 10.17487/RFC2849
RFC2850 Charter of the Internet Architecture Board (IAB) Internet Architecture Board B. Carpenter Editor May 2000 ASCII HTML 8 ISOC Internet Society IETF IRTF

This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-rfc1601bis-04 RFC1601 BCP0039 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC2850
RFC2851 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder June 2000 ASCII HTML 16 layer management information base inet address mib

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. [STANDARDS-TRACK]

draft-ops-endpoint-mib-08 RFC3291 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2851
RFC2852 Deliver By SMTP Service Extension D. Newman June 2000 ASCII HTML 13 simple mail transfer protocol client server

This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. [STANDARDS-TRACK]

draft-newman-deliver-03 RFC1894 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2852 10.17487/RFC2852
RFC2853 Generic Security Service API Version 2 : Java Bindings J. Kabat M. Upadhyay June 2000 ASCII HTML 96 GSI application program interface

This document specifies the Java bindings for GSS-API (Generic Security Service Application Program Interface) which is described at a language independent conceptual level in RFC 2743. [STANDARDS-TRACK]

draft-ietf-cat-gssv2-javabind-05 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec cat 10.17487/RFC2853
RFC2854 The 'text/html' Media Type D. Connolly L. Masinter June 2000 ASCII HTML 8 HTML-INT HTML WWW World Wide Web

This document summarizes the history of HTML development, and defines the "text/html" MIME type by pointing to the relevant W3C recommendations. This memo provides information for the Internet community.

draft-connolly-text-html-02 RFC2070 RFC1980 RFC1942 RFC1867 RFC1866 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2854
RFC2855 DHCP for IEEE 1394 K. Fujisawa June 2000 ASCII HTML 5 dynamic host configuration protocol high performance serial bus

This memo describes specific usage of some fields of DHCP (Dynamic Host Configuration Protocol) messages. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. [STANDARDS-TRACK]

draft-ietf-ip1394-dhcp-04 PROPOSED STANDARD PROPOSED STANDARD IETF int ip1394 10.17487/RFC2855
RFC2856 Textual Conventions for Additional High Capacity Data Types A. Bierman K. McCloghrie R. Presuhn June 2000 ASCII HTML 10 SNMP simple network management protocol

This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS-TRACK]

draft-kzm-hcdata-types-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2856
RFC2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH A. Keromytis N. Provos June 2000 ASCII HTML 7 ipsec encapsulating security payload authentication

This memo describes the use of the HMAC algorithm in conjunction with the RIPEMD-160 algorithm as an authentication mechanism within the revised IPSEC Encapsulating Security Payload (ESP) and the revised IPSEC Authentication Header (AH). [STANDARDS-TRACK]

draft-ietf-ipsec-auth-hmac-ripemd-160-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC2857
RFC2858 Multiprotocol Extensions for BGP-4 T. Bates Y. Rekhter R. Chandra D. Katz June 2000 ASCII HTML 11 MEXT-BGP4 Border gateway protocol router network layer

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). [STANDARDS-TRACK]

draft-ietf-idr-bgp4-multiprotocol-v2-05 RFC2283 RFC4760 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=2858 10.17487/RFC2858
RFC2859 A Time Sliding Window Three Colour Marker (TSWTCM) W. Fang N. Seddigh B. Nandy June 2000 ASCII HTML 9 TSWTCM packets traffic stream routers

This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner. This memo defines an Experimental Protocol for the Internet community.

draft-fang-diffserv-tc-tswtcm-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2859
RFC2860 Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority B. Carpenter F. Baker M. Roberts June 2000 ASCII HTML 7 mou iana ietf icann engineering task force corporation names

This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.

draft-iab-iana-mou-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2860
RFC2861 TCP Congestion Window Validation M. Handley J. Padhye S. Floyd June 2000 ASCII HTML 11 transmission control protocol

This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. This memo defines an Experimental Protocol for the Internet community.

draft-handley-tcp-cwv-02 RFC7661 HISTORIC EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2861 10.17487/RFC2861
RFC2862 RTP Payload Format for Real-Time Pointers M. Civanlar G. Cash June 2000 ASCII HTML 7 view graphs resolution audio video signals

This document describes an RTP payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. [STANDARDS-TRACK]

draft-ietf-avt-pointer-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2862
RFC2863 The Interfaces Group MIB K. McCloghrie F. Kastenholz June 2000 ASCII HTML 69 INTERGRMIB Management Information Base Network

This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. [STANDARDS-TRACK]

draft-ietf-ifmib-ifmib2-03 RFC2233 RFC8892 DRAFT STANDARD DRAFT STANDARD IETF int ifmib http://www.rfc-editor.org/errata_search.php?rfc=2863 10.17487/RFC2863
RFC2864 The Inverted Stack Table Extension to the Interfaces Group MIB K. McCloghrie G. Hanson June 2000 ASCII HTML 11 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS-TRACK]

draft-ietf-ifmib-invstackmib-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ifmib 10.17487/RFC2864
RFC2865 Remote Authentication Dial In User Service (RADIUS) C. Rigney S. Willens A. Rubens W. Simpson June 2000 ASCII HTML 76 RADIUS encryption NAS Network Access Server

This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]

draft-ietf-radius-radius-v2-06 RFC2138 RFC2868 RFC3575 RFC5080 RFC6929 RFC8044 DRAFT STANDARD DRAFT STANDARD IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2865 10.17487/RFC2865
RFC2866 RADIUS Accounting C. Rigney June 2000 ASCII HTML 28 RADIUS-ACC remote authentication dial in user service encryption

This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community.

draft-ietf-radius-accounting-v2-05 RFC2139 RFC2867 RFC5080 RFC5997 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2866 10.17487/RFC2866
RFC2867 RADIUS Accounting Modifications for Tunnel Protocol Support G. Zorn B. Aboba D. Mitton June 2000 ASCII HTML 11 RADIUS] encryption NAS Network Access Server

This document defines new RADIUS (Remote Authentication Dial In User Service) accounting Attributes and new values for the existing Acct- Status-Type Attribute designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

draft-ietf-radius-tunnel-acct-05 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2867 10.17487/RFC2867
RFC2868 RADIUS Attributes for Tunnel Protocol Support G. Zorn D. Leifer A. Rubens J. Shriver M. Holdrege I. Goyret June 2000 ASCII HTML 20 RADIUS encryption NAS Network Access Server

This document defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. This memo provides information for the Internet community.

draft-ietf-radius-tunnel-auth-09 RFC2865 RFC3575 INFORMATIONAL INFORMATIONAL IETF ops radius http://www.rfc-editor.org/errata_search.php?rfc=2868 10.17487/RFC2868
RFC2869 RADIUS Extensions C. Rigney W. Willats P. Calhoun June 2000 ASCII HTML 47 RADIUS encryption NAS Network Access Server

This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community.

draft-ietf-radius-ext-07 RFC3579 RFC5080 INFORMATIONAL INFORMATIONAL IETF ops radius 10.17487/RFC2869
RFC2870 Root Name Server Operational Requirements R. Bush D. Karrenberg M. Kosters R. Plzak June 2000 ASCII HTML 10 infrastructure domain names security

The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-root-opreq-05 RFC2010 RFC7720 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC2870
RFC2871 A Framework for Telephony Routing over IP J. Rosenberg H. Schulzrinne June 2000 ASCII HTML 25 internet protocol TRIP gateway

This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. This memo provides information for the Internet community.

draft-ietf-iptel-gwloc-framework-06 INFORMATIONAL INFORMATIONAL IETF rai iptel 10.17487/RFC2871
RFC2872 Application and Sub Application Identity Policy Element for Use with RSVP Y. Bernet R. Pabbati June 2000 ASCII HTML 6 resource reservation protocol

RSVP signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used by RSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-appid-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2872
RFC2873 TCP Processing of the IPv4 Precedence Field X. Xiao A. Hannan V. Paxson E. Crabbe June 2000 ASCII HTML 8 transmission control protocol internet

This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]

draft-xiao-tcp-prec-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=2873 10.17487/RFC2873
RFC2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering M. Crawford C. Huitema July 2000 ASCII HTML 20 internet protocol domain name system

This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. [STANDARDS-TRACK]

draft-ietf-ipngwg-dns-lookups-08 RFC1886 RFC3152 RFC3226 RFC3363 RFC3364 HISTORIC PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2874
RFC2875 Diffie-Hellman Proof-of-Possession Algorithms H. Prafullchandra J. Schaad July 2000 ASCII HTML 23 certificate security encryption

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. [STANDARDS-TRACK]

draft-ietf-pkix-dhpop-03 RFC6955 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC2875
RFC2876 Use of the KEA and SKIPJACK Algorithms in CMS J. Pawling July 2000 ASCII HTML 13 encryption cryptographic message syntax

This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. This memo provides information for the Internet community.

draft-ietf-smime-cmskea-05 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=2876 10.17487/RFC2876
RFC2877 5250 Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens July 2000 ASCII HTML 36 client server printer

This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. This memo provides information for the Internet community.

draft-ietf-tn3270e-tn5250e-05 RFC4777 RFC1205 INFORMATIONAL INFORMATIONAL IETF app tn3270e 10.17487/RFC2877
RFC2878 PPP Bridging Control Protocol (BCP) M. Higashiyama F. Baker July 2000 ASCII HTML 38 PPP-BCP point-to-point datagrams network

This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. [STANDARDS-TRACK]

draft-ietf-pppext-bcp-04 RFC1638 RFC3518 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC2878
RFC2879 Content Feature Schema for Internet Fax (V2) G. Klyne L. McIntyre August 2000 ASCII HTML 58 media features mechanism

This document defines a content media feature schema for Internet fax. [STANDARDS-TRACK]

draft-ietf-fax-feature-schema-v2-01 RFC2531 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC2879
RFC2880 Internet Fax T.30 Feature Mapping L. McIntyre G. Klyne August 2000 ASCII HTML 37 schema media tags

This document describes how to map Group 3 fax capability identification bits, described in ITU T.30, into the Internet fax feature schema described in "Content feature schema for Internet fax". This memo provides information for the Internet community.

draft-ietf-fax-feature-T30-mapping-03 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC2880
RFC2881 Network Access Server Requirements Next Generation (NASREQNG) NAS Model D. Mitton M. Beadles July 2000 ASCII HTML 20 RADIUS remote authentication dial-up user service

This document describes the terminology and gives a model of typical Network Access Server (NAS). This memo provides information for the Internet community.

draft-ietf-nasreq-nasmodel-02 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2881
RFC2882 Network Access Servers Requirements: Extended RADIUS Practices D. Mitton July 2000 ASCII HTML 16 NAS remote authentication dial-in user service

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS (Remote Authentication Dial In User Service) RFCs 2138, 2139. This memo provides information for the Internet community.

draft-ietf-nasreq-ext-radiuspract-03 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC2882
RFC2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP S. Floyd J. Mahdavi M. Mathis M. Podolsky July 2000 ASCII HTML 17 SACK transmission control protocol packets sender receiver

This note defines an extension of the Selective Acknowledgement (SACK) Option for TCP. [STANDARDS-TRACK]

draft-floyd-sack-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2883 10.17487/RFC2883
RFC2884 Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks J. Hadi Salim U. Ahmed July 2000 ASCII HTML 18 internet protocol end-to-end TCP transmission control

This memo presents a performance study of the Explicit Congestion Notification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. This memo provides information for the Internet community.

draft-hadi-jhsua-ecnperf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2884
RFC2885 Megaco Protocol version 0.8 F. Cuervo N. Greene C. Huitema A. Rayhan B. Rosen J. Segers August 2000 ASCII HTML 170 H.248 media gateway control

This document is common text with Recommendation H.248 as redetermined in Geneva, February 2000. It must be read in conjunction with the Megaco Errata, RFC 2886. [STANDARDS-TRACK]

draft-ietf-megaco-protocol-08 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2885
RFC2886 Megaco Errata T. Taylor August 2000 ASCII HTML 21 H.248 media gateway control

This document records the errors found in the Megaco/H.248 protocol document, along with the changes proposed in the text of that document to resolve them. [STANDARDS-TRACK]

draft-ietf-megaco-errata-03 RFC3015 HISTORIC PROPOSED STANDARD IETF rai megaco 10.17487/RFC2886
RFC2887 The Reliable Multicast Design Space for Bulk Data Transfer M. Handley S. Floyd B. Whetten R. Kermode L. Vicisano M. Luby August 2000 ASCII HTML 22 application RM congestion control data

This document provides an overview of the design space and the ways in which application constraints affect possible solutions. This memo provides information for the Internet community.

draft-ietf-rmt-design-space-01 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC2887
RFC2888 Secure Remote Access with L2TP P. Srisuresh August 2000 ASCII HTML 19 layer two tunneling protocol

The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This memo provides information for the Internet community.

draft-srisuresh-secure-ra-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2888
RFC2889 Benchmarking Methodology for LAN Switching Devices R. Mandeville J. Perser August 2000 ASCII HTML 35 local area network MAC medium access control

This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community.

draft-ietf-bmwg-mswitch-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=2889 10.17487/RFC2889
RFC2890 Key and Sequence Number Extensions to GRE G. Dommety September 2000 ASCII HTML 7 generic routing encapsulation

This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]

draft-dommety-gre-ext-04 RFC2784 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2890
RFC2891 LDAP Control Extension for Server Side Sorting of Search Results T. Howes M. Wahl A. Anantha August 2000 ASCII HTML 8 lightweight directory access protocol

This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. [STANDARDS-TRACK]

draft-ietf-ldapext-sorting-03 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapext 10.17487/RFC2891
RFC2892 The Cisco SRP MAC Layer Protocol D. Tsiang G. Suwala August 2000 ASCII HTML 52 spatial reuse

This document specifies the MAC layer protocol, "Spatial Reuse Protocol" (SRP) for use with ring based media. This is a second version of the protocol (V2). This memo provides information for the Internet community.

draft-tsiang-srp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2892
RFC2893 Transition Mechanisms for IPv6 Hosts and Routers R. Gilligan E. Nordmark August 2000 ASCII HTML 29 TRANS-IPV6 IPv4

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. [STANDARDS-TRACK]

draft-ietf-ngtrans-mech-06 RFC1933 RFC4213 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC2893
RFC2894 Router Renumbering for IPv6 M. Crawford August 2000 ASCII HTML 32 internet protocol operations scalability applicability

This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. [STANDARDS-TRACK]

draft-ietf-ipngwg-router-renum-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC2894
RFC2895 Remote Network Monitoring MIB Protocol Identifier Reference A. Bierman C. Bucci R. Iddon August 2000 ASCII HTML 42 RMON-MIB management information base

This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding ``INDEX`` values for the protocolDirTable, found in the RMON-2 MIB. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmonprot-ref-01 RFC2074 RFC3395 DRAFT STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC2895
RFC2896 Remote Network Monitoring MIB Protocol Identifier Macros A. Bierman C. Bucci R. Iddon August 2000 ASCII HTML 84 RMON management information base

This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB and the RMON Protocol Identifier Reference. This memo provides information for the Internet community.

draft-ietf-rmonmib-rmonprot-mac-02 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC2896
RFC2897 Proposal for an MGCP Advanced Audio Package D. Cromwell August 2000 ASCII HTML 34 media gateway control protocol IVR interactive voice response

This document is a proposal to add a new event/signal package to the MGCP (Media Gateway Control Protocol) protocol to control an ARF (Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server. This memo provides information for the Internet community.

draft-cromwell-mgcp-advanced-audio-pkg-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2897
RFC2898 PKCS #5: Password-Based Cryptography Specification Version 2.0 B. Kaliski September 2000 ASCII HTML 34 public-key authentication encryption

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.

draft-kaliski-pkcs5-v2-04 RFC8018 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2898 10.17487/RFC2898
RFC2899 Request for Comments Summary RFC Numbers 2800-2899 S. Ginoza May 2001 ASCII HTML 22 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2899 RFC2900 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza August 2001 ASCII HTML 42

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 17, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. This memo is an Internet Standard.

RFC2800 RFC3000 HISTORIC INTERNET STANDARD Legacy 10.17487/RFC2900
RFC2901 Guide to Administrative Procedures of the Internet Infrastructure Z. Wenzel J. Klensin R. Bush S. Huter August 2000 ASCII HTML 31 address space routing database domain name registration

This document describes the administrative procedures for networks seeking to connect to the global Internet. This memo provides information for the Internet community.

draft-wenzel-nsrc-02 FYI0037 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2901
RFC2902 Overview of the 1998 IAB Routing Workshop S. Deering S. Hares C. Perkins R. Perlman August 2000 ASCII HTML 16 internet architecture board

This document is an overview of a Routing workshop held by the Internet Architecture Board (IAB) during March 25-27, 1998. This memo provides information for the Internet community.

draft-iab-rtrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2902
RFC2903 Generic AAA Architecture C. de Laat G. Gross L. Gommans J. Vollbrecht D. Spence August 2000 ASCII HTML 26 authentication authorization accounting

This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-aaaarch-generic-01 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC2903
RFC2904 AAA Authorization Framework J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII HTML 35 authentication authorization accounting

This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community.

draft-irtf-aaaarch-authorization-framework-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2904
RFC2905 AAA Authorization Application Examples J. Vollbrecht P. Calhoun S. Farrell L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII HTML 53 authentication authorization accounting

This memo describes several examples of applications requiring authorization. This memo provides information for the Internet community.

draft-irtf-aaaarch-authorization-apps-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2905
RFC2906 AAA Authorization Requirements S. Farrell J. Vollbrecht P. Calhoun L. Gommans G. Gross B. de Bruijn C. de Laat M. Holdrege D. Spence August 2000 ASCII HTML 23 authentication authorization accounting

This document specifies the requirements that Authentication Authorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. This memo provides information for the Internet community.

draft-irtf-aaaarch-authorization-reqs-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2906
RFC2907 MADCAP Multicast Scope Nesting State Option R. Kermode September 2000 ASCII HTML 13 address dynamic allocation client protocol

This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. [STANDARDS-TRACK]

draft-ietf-malloc-madcap-nest-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC2907
RFC2908 The Internet Multicast Address Allocation Architecture D. Thaler M. Handley D. Estrin September 2000 ASCII HTML 13 MALLOC host server intra-domain inter-domain

This document proposes a multicast address allocation architecture (MALLOC) for the Internet. This memo provides information for the Internet community.

draft-ietf-malloc-arch-05 RFC6308 HISTORIC INFORMATIONAL IETF tsv malloc 10.17487/RFC2908
RFC2909 The Multicast Address-Set Claim (MASC) Protocol P. Radoslavov D. Estrin R. Govindan M. Handley S. Kumar D. Thaler September 2000 ASCII HTML 56 MASC inter-domain router

This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-malloc-masc-06 HISTORIC EXPERIMENTAL IETF tsv malloc 10.17487/RFC2909
RFC2910 Internet Printing Protocol/1.1: Encoding and Transport R. Herriot Editor S. Butler P. Moore R. Turner J. Wenn September 2000 ASCII HTML 46 IPP-E-T IPP application media-type media type

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

draft-ietf-ipp-protocol-v11-06 RFC2565 RFC8010 RFC3380 RFC3381 RFC3382 RFC3510 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2910 10.17487/RFC2910
RFC2911 Internet Printing Protocol/1.1: Model and Semantics T. Hastings Editor R. Herriot R. deBry S. Isaacson P. Powell September 2000 ASCII HTML 224 IPP-M-S IPP application media-type job

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). [STANDARDS-TRACK]

draft-ietf-ipp-model-v11-07 RFC2566 RFC8011 RFC3380 RFC3382 RFC3996 RFC3995 RFC7472 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=2911 10.17487/RFC2911
RFC2912 Indicating Media Features for MIME Content G. Klyne September 2000 ASCII HTML 11 multipurpose mail extensions tag format

This memo defines a Multipurpose Internet Mail Extensions (MIME) ' Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used. [STANDARDS-TRACK]

draft-ietf-conneg-content-features-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2912
RFC2913 MIME Content Types in Media Feature Expressions G. Klyne September 2000 ASCII HTML 9 multipurpose mail extensions tag format

This memo defines a media feature tag whose value is a Multipurpose Internet Mail Extensions (MIME) content type. [STANDARDS-TRACK]

draft-ietf-conneg-feature-type-03 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg 10.17487/RFC2913
RFC2914 Congestion Control Principles S. Floyd September 2000 ASCII HTML 17 end-to-end

The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-floyd-cong-04 RFC7141 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ecm 10.17487/RFC2914
RFC2915 The Naming Authority Pointer (NAPTR) DNS Resource Record M. Mealling R. Daniel September 2000 ASCII HTML 18 NAPTR domain name system RR

This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). [STANDARDS-TRACK]

draft-ietf-urn-naptr-rr-04 RFC3401 RFC3402 RFC3403 RFC3404 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC2915
RFC2916 E.164 number and DNS P. Faltstrom September 2000 ASCII HTML 10 domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. [STANDARDS-TRACK]

draft-ietf-enum-e164-dns-03 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=2916 10.17487/RFC2916
RFC2917 A Core MPLS IP VPN Architecture K. Muthukrishnan A. Malis September 2000 ASCII HTML 16 internet protocol virtual private networks multiprotocol label switching

This memo presents an approach for building core Virtual Private Network (VPN) services in a service provider's MPLS backbone. This memo provides information for the Internet community.

draft-muthukrishnan-mpls-corevpn-arch-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2917
RFC2918 Route Refresh Capability for BGP-4 E. Chen September 2000 ASCII HTML 4 border gateway protocol

This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]

draft-ietf-idr-bgp-route-refresh-01 RFC7313 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC2918
RFC2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists R. Chandhok G. Wenger March 2001 ASCII HTML 9 server clients user agents

Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. [STANDARDS-TRACK]

draft-chandhok-listid-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=2919 10.17487/RFC2919
RFC2920 SMTP Service Extension for Command Pipelining N. Freed September 2000 ASCII HTML 9 SMTP-Pipe simple mail transfer protocol TCP transmission control protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service whereby a server can indicate the extent of its ability to accept multiple commands in a single Transmission Control Protocol (TCP) send operation. [STANDARDS-TRACK]

draft-freed-smtp-pipe-01 RFC2197 STD0060 INTERNET STANDARD INTERNET STANDARD Legacy 10.17487/RFC2920
RFC2921 6BONE pTLA and pNLA Formats (pTLA) B. Fink September 2000 ASCII HTML 7 IPv6 internet protocol pseudo top-level next-level aggregation identifiers

This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation", to create pseudo Top-Level Aggregation Identifiers (pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). This memo provides information for the Internet community.

draft-ietf-ngtrans-6bone-ptla-00 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC2921
RFC2922 Physical Topology MIB A. Bierman K. Jones September 2000 ASCII HTML 32 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. This memo provides information for the Internet community.

draft-ietf-ptopomib-mib-05 INFORMATIONAL INFORMATIONAL IETF ops ptopomib 10.17487/RFC2922
RFC2923 TCP Problems with Path MTU Discovery K. Lahey September 2000 ASCII HTML 15 transmission control protocol maximum unit

This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This memo provides information for the Internet community.

draft-ietf-tcpimpl-pmtud-04 INFORMATIONAL INFORMATIONAL IETF tsv tcpimpl 10.17487/RFC2923
RFC2924 Accounting Attributes and Record Formats N. Brownlee A. Blount September 2000 ASCII HTML 36 data transport integrated

This document summarises Internet Engineering Task Force (IETF) and International Telecommunication Union (ITU-T) documents related to Accounting. This memo provides information for the Internet community.

draft-ietf-aaa-accounting-attributes-04 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2924
RFC2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations K. White September 2000 ASCII HTML 77 mib management information base

This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. [STANDARDS-TRACK]

draft-ietf-disman-remops-mib-08 RFC4560 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2925 10.17487/RFC2925
RFC2926 Conversion of LDAP Schemas to and from SLP Templates J. Kempf R. Moats P. St. Pierre September 2000 ASCII HTML 27 service location protocol lightweight directory access

This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. This memo provides information for the Internet community.

draft-ietf-svrloc-template-conversion-08 INFORMATIONAL INFORMATIONAL IETF int svrloc 10.17487/RFC2926
RFC2927 MIME Directory Profile for LDAP Schema M. Wahl September 2000 ASCII HTML 10 lightweight directory access protocol multipurpose internet mail extensions

This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. This memo provides information for the Internet community.

draft-ietf-schema-ldap-01 INFORMATIONAL INFORMATIONAL IETF app schema http://www.rfc-editor.org/errata_search.php?rfc=2927 10.17487/RFC2927
RFC2928 Initial IPv6 Sub-TLA ID Assignments R. Hinden S. Deering R. Fink T. Hain September 2000 ASCII HTML 7 internet protocol sub-top-level aggregation identifiers address registries

This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. This memo provides information for the Internet community.

draft-ietf-ipngwg-iana-tla-03 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC2928
RFC2929 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd E. Brunner-Williams B. Manning September 2000 ASCII HTML 12 internet assigned numbers authority resource records RRs

This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsext-iana-dns-01 RFC5395 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC2929
RFC2930 Secret Key Establishment for DNS (TKEY RR) D. Eastlake 3rd September 2000 ASCII HTML 16 TKEY-RR domain name system resource record transaction key

This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. [STANDARDS-TRACK]

draft-ietf-dnsext-tkey-04 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2930
RFC2931 DNS Request and Transaction Signatures ( SIG(0)s ) D. Eastlake 3rd September 2000 ASCII HTML 10 domain name system data security

This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]

draft-ietf-dnsext-sig-zero-02 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC2931
RFC2932 IPv4 Multicast Routing MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII HTML 27 internet protocol management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4, independent of the specific multicast routing protocol in use. [STANDARDS-TRACK]

draft-ietf-idmr-multicast-routmib-13 RFC5132 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2932
RFC2933 Internet Group Management Protocol MIB K. McCloghrie D. Farinacci D. Thaler October 2000 ASCII HTML 19 igmp management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP). [STANDARDS-TRACK]

draft-ietf-idmr-igmp-mib-14 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr 10.17487/RFC2933
RFC2934 Protocol Independent Multicast MIB for IPv4 K. McCloghrie D. Farinacci D. Thaler B. Fenner October 2000 ASCII HTML 27 internet protocol management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-idmr-pim-mib-11 EXPERIMENTAL EXPERIMENTAL IETF rtg idmr 10.17487/RFC2934
RFC2935 Internet Open Trading Protocol (IOTP) HTTP Supplement D. Eastlake 3rd C. Smith September 2000 ASCII HTML 8 IOTP-HTTP hypertext XML extensible markup language transfer

The goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text Transport Protocol (HTTP), Versions 1.0 and 1.1. [STANDARDS-TRACK]

draft-ietf-trade-iotp-http-07 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC2935
RFC2936 HTTP MIME Type Handler Detection D. Eastlake 3rd C. Smith D. Soroka September 2000 ASCII HTML 13 multipurpose internet mail extensions hypertext transfer protocol

Entities composing web pages to provide services over the Hypertext Transfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on the Internet as of early 2000. This memo provides information for the Internet community.

draft-ietf-trade-mime-detector-03 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC2936
RFC2937 The Name Service Search Option for DHCP C. Smith September 2000 ASCII HTML 5 dynamic host configuration protocol

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information. [STANDARDS-TRACK]

draft-ietf-dhc-nsso-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC2937
RFC2938 Identifying Composite Media Features G. Klyne L. Masinter September 2000 ASCII HTML 18 tags expression hash

This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite. [STANDARDS-TRACK]

draft-ietf-conneg-feature-hash-05 RFC2533 PROPOSED STANDARD PROPOSED STANDARD IETF app conneg http://www.rfc-editor.org/errata_search.php?rfc=2938 10.17487/RFC2938
RFC2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types R. Droms September 2000 ASCII HTML 7 dynamic host configuration protocol internet assigned numbers authority

This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dhc-new-opt-msg-02 RFC2489 BCP0043 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=2939 10.17487/RFC2939
RFC2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients A. Smith D. Partain J. Seligson October 2000 ASCII HTML 27 cops mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client of the Common Open Policy Service (COPS) protocol. [STANDARDS-TRACK]

draft-ietf-rap-cops-client-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC2940
RFC2941 Telnet Authentication Option T. Ts'o Editor J. Altman September 2000 ASCII HTML 15 TOPT-AUTH encryption Security

This document describes the authentication option to the telnet protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. [STANDARDS-TRACK]

draft-tso-telnet-auth-enc-05 RFC1416 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2941
RFC2942 Telnet Authentication: Kerberos Version 5 T. Ts'o September 2000 ASCII HTML 7 encryption

This document describes how Kerberos Version 5 is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option. [STANDARDS-TRACK]

draft-tso-telnet-krb5-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2942
RFC2943 TELNET Authentication Using DSA R. Housley T. Horting P. Yee September 2000 ASCII HTML 12 digital signature algorithm

This document defines a telnet authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option. [STANDARDS-TRACK]

draft-housley-telnet-auth-dsa-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2943
RFC2944 Telnet Authentication: SRP T. Wu September 2000 ASCII HTML 7 secure remote password protocol

This document specifies an authentication scheme for the Telnet protocol under the framework described in RFC 2941, using the Secure Remote Password Protocol (SRP) authentication mechanism. [STANDARDS-TRACK]

draft-wu-telnet-auth-srp-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2944
RFC2945 The SRP Authentication and Key Exchange System T. Wu September 2000 ASCII HTML 8 secure remote password protocol

This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. [STANDARDS-TRACK]

draft-wu-srp-auth-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2945
RFC2946 Telnet Data Encryption Option T. Ts'o September 2000 ASCII HTML 8 stream authentication

This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. [STANDARDS-TRACK]

draft-tso-telnet-encryption-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2946
RFC2947 Telnet Encryption: DES3 64 bit Cipher Feedback J. Altman September 2000 ASCII HTML 6 data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option. [STANDARDS-TRACK]

draft-altman-telnet-enc-des3-cfb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2947
RFC2948 Telnet Encryption: DES3 64 bit Output Feedback J. Altman September 2000 ASCII HTML 6 data encryption standard

This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option. [STANDARDS-TRACK]

draft-altman-telnet-enc-des3-ofb-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2948
RFC2949 Telnet Encryption: CAST-128 64 bit Output Feedback J. Altman September 2000 ASCII HTML 5 algorithm option

This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

draft-altman-telnet-enc-cast128-ofb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2949
RFC2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback J. Altman September 2000 ASCII HTML 5 algorithm option

This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit. [STANDARDS-TRACK]

draft-altman-telnet-enc-cast128-cfb-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2950
RFC2951 TELNET Authentication Using KEA and SKIPJACK R. Housley T. Horting P. Yee September 2000 ASCII HTML 11 key exchange algorithm encryption

This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. This memo provides information for the Internet community.

draft-housley-telnet-auth-keasj-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2951
RFC2952 Telnet Encryption: DES 64 bit Cipher Feedback T. Ts'o September 2000 ASCII HTML 5 data encryption standard

This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. This memo provides information for the Internet community.

draft-tso-telnet-enc-des-cfb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2952
RFC2953 Telnet Encryption: DES 64 bit Output Feedback T. Ts'o September 2000 ASCII HTML 5 data encryption standard

This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. This memo provides information for the Internet community.

draft-tso-telnet-enc-des-ofb-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2953
RFC2954 Definitions of Managed Objects for Frame Relay Service K. Rehbehn D. Fowler October 2000 ASCII HTML 76 FR-MIB mib management information base

This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in Transmission Control Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. [STANDARDS-TRACK]

draft-ietf-frnetmib-frs-mib-12 RFC1604 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2954
RFC2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function K. Rehbehn O. Nicklass G. Mouradian October 2000 ASCII HTML 39 asynchronous transfer mode permanent virtual connections MIB management information base

This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) for Permanent Virtual Connections (PVC) between Frame Relay and Asynchronous Transfer Mode (ATM) technologies. [STANDARDS-TRACK]

draft-ietf-frnetmib-atmiwf-06 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC2955
RFC2956 Overview of 1999 IAB Network Layer Workshop M. Kaat October 2000 ASCII HTML 16 intenret architecture board

This document is an overview of a workshop held by the Internet Architecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet. This memo provides information for the Internet community.

draft-iab-ntwlyrws-over-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2956
RFC2957 The application/whoispp-query Content-Type L. Daigle P. Faltstrom October 2000 ASCII HTML 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2958, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

draft-daigle-wppquery-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2957
RFC2958 The application/whoispp-response Content-type L. Daigle P. Faltstrom October 2000 ASCII HTML 6 mime multipurpose internet mail extensions media-types

The intention of this document, in conjunction with RFC 2957, is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. This memo provides information for the Internet community.

draft-daigle-wppresp-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2958
RFC2959 Real-Time Transport Protocol Management Information Base M. Baugher B. Strahm I. Suconick October 2000 ASCII HTML 31 RTP MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC2959
RFC2960 Stream Control Transmission Protocol R. Stewart Q. Xie K. Morneault C. Sharp H. Schwarzbauer T. Taylor I. Rytina M. Kalla L. Zhang V. Paxson October 2000 ASCII HTML 134 SCTP IP internet transport packet network

This document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

draft-ietf-sigtran-sctp-13 RFC4960 RFC3309 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=2960 10.17487/RFC2960
RFC2961 RSVP Refresh Overhead Reduction Extensions L. Berger D. Gan G. Swallow P. Pan F. Tommasi S. Molendini April 2001 ASCII HTML 34 resource reservation protocol messages

This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP (Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages. [STANDARDS-TRACK]

draft-ietf-rsvp-refresh-reduct-05 RFC5063 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC2961
RFC2962 An SNMP Application Level Gateway for Payload Address Translation D. Raz J. Schoenwaelder B. Sugla October 2000 ASCII HTML 20 simple network management protocol

This document describes the ALG (Application Level Gateway) for the SNMP (Simple Network Management Protocol) by which IP (Internet Protocol) addresses in the payload of SNMP packets are statically mapped from one group to another. This memo provides information for the Internet community.

draft-ietf-nat-snmp-alg-05 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=2962 10.17487/RFC2962
RFC2963 A Rate Adaptive Shaper for Differentiated Services O. Bonaventure S. De Cnodder October 2000 ASCII HTML 19 RAS TCP transmission control protocol diffserv

This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 and RFC2698, respectively. This memo provides information for the Internet community.

draft-bonaventure-diffserv-rashaper-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2963
RFC2964 Use of HTTP State Management K. Moore N. Freed October 2000 ASCII HTML 8 hypertext transfer protocol

This memo identifies specific uses of Hypertext Transfer Protocol (HTTP) State Management protocol which are either (a) not recommended by the IETF, or (b) believed to be harmful, and discouraged. This memo also details additional privacy considerations which are not covered by the HTTP State Management protocol specification. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iesg-http-cookies-03 BCP0044 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC2964
RFC2965 HTTP State Management Mechanism D. Kristol L. Montulli October 2000 ASCII HTML 26 hypertext transfer protocol

This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. [STANDARDS-TRACK]

draft-ietf-http-state-man-mec-12 RFC2109 RFC6265 HISTORIC PROPOSED STANDARD IETF app http http://www.rfc-editor.org/errata_search.php?rfc=2965 10.17487/RFC2965
RFC2966 Domain-wide Prefix Distribution with Two-Level IS-IS T. Li T. Przygienda H. Smit October 2000 ASCII HTML 14 intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. This memo provides information for the Internet community.

draft-ietf-isis-domain-wide-03 RFC5302 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2966
RFC2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways L. Daigle R. Hedberg October 2000 ASCII HTML 105 single point service

The overarching goal of this project is to develop the necessary technical infrastructure to provide a single-access-point service for searching for whitepages information on Swedish Internet users. This memo provides information for the Internet community.

draft-daigle-tisdag-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2967
RFC2968 Mesh of Multiple DAG servers - Results from TISDAG L. Daigle T. Eklof October 2000 ASCII HTML 9 technical infrastructure swedish directory access gateways mesh index

This document defines the basic principle for establishing a mesh, that interoperating services should exchange index objects, according to the architecture of the mesh (e.g., hierarchical, or graph-like, preferably without loops!). The Common Indexing Protocol (CIP) is designed to facilitate the creation not only of query referral indexes, but also of meshes of (loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. This memo provides information for the Internet community.

draft-daigle-dag-mesh-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2968
RFC2969 Wide Area Directory Deployment - Experiences from TISDAG T. Eklof L. Daigle October 2000 ASCII HTML 19 technical infrastructure swedish access gateways

This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. This memo provides information for the Internet community.

draft-eklof-dag-experiences-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2969
RFC2970 Architecture for Integrated Directory Services - Result from TISDAG L. Daigle T. Eklof October 2000 ASCII HTML 18 ids whitepages technical infrastructure swedish access gateways

Drawing from experiences with the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. This memo provides information for the Internet community.

draft-daigle-arch-ids-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC2970
RFC2971 IMAP4 ID extension T. Showalter October 2000 ASCII HTML 8 internet message access protocol client server

This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK]

draft-showalter-imap-id-04 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2971
RFC2972 Context and Goals for Common Name Resolution N. Popp M. Mealling L. Masinter K. Sollins October 2000 ASCII HTML 11 CNRP

This document establishes the context and goals for a Common Name Resolution Protocol. This memo provides information for the Internet community.

draft-ietf-cnrp-goals-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2972
RFC2973 IS-IS Mesh Groups R. Balay D. Katz J. Parker October 2000 ASCII HTML 8 intermediate system PDU protocol data unit

This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This memo provides information for the Internet community.

draft-ietf-isis-wg-mesh-group-01 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC2973
RFC2974 Session Announcement Protocol M. Handley C. Perkins E. Whelan October 2000 ASCII HTML 18 SAP

This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mmusic-sap-v2-06 EXPERIMENTAL EXPERIMENTAL IETF rai mmusic 10.17487/RFC2974
RFC2975 Introduction to Accounting Management B. Aboba J. Arkko D. Harrington October 2000 ASCII HTML 54 resource consumption data cost allocation

This document describes and discusses the issues involved in the design of the modern accounting systems. The field of Accounting Management is concerned with the collection the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This memo provides information for the Internet community.

draft-ietf-aaa-acct-06 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2975
RFC2976 The SIP INFO Method S. Donovan October 2000 ASCII HTML 9 session initiation protocol information extension

This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. [STANDARDS-TRACK]

draft-ietf-sip-info-method-05 RFC6086 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC2976
RFC2977 Mobile IP Authentication, Authorization, and Accounting Requirements S. Glass T. Hiller S. Jacobs C. Perkins October 2000 ASCII HTML 27 AAA internet protocol

This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. This memo provides information for the Internet community.

draft-ietf-mobileip-aaa-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mobileip 10.17487/RFC2977
RFC2978 IANA Charset Registration Procedures N. Freed J. Postel October 2000 ASCII HTML 11 character set mime multipurpose internet mail extensions

Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-freed-charset-regist-03 RFC2278 BCP0019 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=2978 10.17487/RFC2978
RFC2979 Behavior of and Requirements for Internet Firewalls N. Freed October 2000 ASCII HTML 7 security intranet network

This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. This memo provides information for the Internet community.

draft-iab-firewall-req-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2979
RFC2980 Common NNTP Extensions S. Barber October 2000 ASCII HTML 27 network news transfer protocol

In this document, a number of popular extensions to the Network News Transfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. This memo provides information for the Internet community.

draft-ietf-nntpext-imp-04 RFC3977 RFC4643 RFC4644 RFC6048 INFORMATIONAL INFORMATIONAL IETF app nntpext 10.17487/RFC2980
RFC2981 Event MIB R. Kavasseri Editor October 2000 ASCII HTML 50 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. [STANDARDS-TRACK]

draft-ietf-disman-event-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=2981 10.17487/RFC2981
RFC2982 Distributed Management Expression MIB R. Kavasseri Editor October 2000 ASCII HTML 41 information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. [STANDARDS-TRACK]

draft-ietf-disman-express-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC2982
RFC2983 Differentiated Services and Tunnels D. Black October 2000 ASCII HTML 14 internet protocol encapsulation

This document considers the interaction of Differentiated Services (diffserv) with IP tunnels of various forms. This memo provides information for the Internet community.

draft-ietf-diffserv-tunnels-02 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC2983
RFC2984 Use of the CAST-128 Encryption Algorithm in CMS C. Adams October 2000 ASCII HTML 6 cryptographic message syntax security cipher

This document specifies how to incorporate CAST-128 into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. [STANDARDS-TRACK]

draft-ietf-smime-cast-128-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC2984
RFC2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0 M. Nystrom B. Kaliski November 2000 ASCII HTML 42 public-key cryptography standards LDAP lightweight directory access protocol

This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.

draft-nystrom-pkcs9-v2-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=2985 10.17487/RFC2985
RFC2986 PKCS #10: Certification Request Syntax Specification Version 1.7 M. Nystrom B. Kaliski November 2000 ASCII HTML 14 public-key cryptography standards PKCS-10 public key distinguished name encryption data

This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.

draft-nystrom-pkcs10-v1-7-00 RFC2314 RFC5967 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2986
RFC2987 Registration of Charset and Languages Media Features Tags P. Hoffman November 2000 ASCII HTML 6 character sets human languages devices

This document contains the registration for two media feature tags: "charset" and "language". [STANDARDS-TRACK]

draft-hoffman-char-lang-media-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC2987
RFC2988 Computing TCP's Retransmission Timer V. Paxson M. Allman November 2000 ASCII HTML 8 transmission control protocol algorithm

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. [STANDARDS-TRACK]

draft-paxson-tcp-rto-01 RFC6298 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=2988 10.17487/RFC2988
RFC2989 Criteria for Evaluating AAA Protocols for Network Access B. Aboba P. Calhoun S. Glass T. Hiller P. McCann H. Shiino P. Walsh G. Zorn G. Dommety C. Perkins B. Patil D. Mitton S. Manning M. Beadles X. Chen S. Sivalingham A. Hameed M. Munson S. Jacobs B. Lim B. Hirschman R. Hsu H. Koo M. Lipford E. Campbell Y. Xu S. Baba E. Jaques November 2000 ASCII HTML 28 authentication authorization accounting

This document represents a summary of Authentication, Authorization, Accounting (AAA) protocol requirements for network access. This memo provides information for the Internet community.

draft-ietf-aaa-na-reqts-07 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC2989
RFC2990 Next Steps for the IP QoS Architecture G. Huston November 2000 ASCII HTML 24 internet protocol quality of service end-to-end

This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. This memo provides information for the Internet community.

draft-iab-qos-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2990
RFC2991 Multipath Issues in Unicast and Multicast Next-Hop Selection D. Thaler C. Hopps November 2000 ASCII HTML 9 routing forwarding packets ECMP

The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. This memo provides information for the Internet community.

draft-thaler-multipath-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2991
RFC2992 Analysis of an Equal-Cost Multi-Path Algorithm C. Hopps November 2000 ASCII HTML 8 ECMP routing packets forwarding

Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. This memo provides information for the Internet community.

draft-hopps-ecmp-algo-analysis-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2992
RFC2993 Architectural Implications of NAT T. Hain November 2000 ASCII HTML 29 network address translation

This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.

draft-iab-nat-implications-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC2993
RFC2994 A Description of the MISTY1 Encryption Algorithm H. Ohta M. Matsui November 2000 ASCII HTML 10 cryptosystem security data stream

This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. This memo provides information for the Internet community.

draft-ohta-misty1desc-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2994
RFC2995 Pre-Spirits Implementations of PSTN-initiated Services H. Lu Editor I. Faynberg J. Voelker M. Weissman W. Zhang S. Rhim J. Hwang S. Ago S. Moeenuddin S. Hadvani S. Nyckelgard J. Yoakum L. Robart November 2000 ASCII HTML 44 public switched telephone network

This document describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN. This memo provides information for the Internet community.

draft-ietf-spirits-implementations-02 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC2995
RFC2996 Format of the RSVP DCLASS Object Y. Bernet November 2000 ASCII HTML 9 resource reservation protocol QoS Quality of Service

This document specifies the format of the DCLASS object and briefly discusses its use. [STANDARDS-TRACK]

draft-ietf-issll-dclass-01 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2996
RFC2997 Specification of the Null Service Type Y. Bernet A. Smith B. Davie November 2000 ASCII HTML 12 resource reservation protocol QoS Quality of Service

The Null Service allows applications to identify themselves to network Quality of Service (QoS) policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. [STANDARDS-TRACK]

draft-ietf-issll-nullservice-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC2997
RFC2998 A Framework for Integrated Services Operation over Diffserv Networks Y. Bernet P. Ford R. Yavatkar F. Baker L. Zhang M. Speer R. Braden B. Davie J. Wroclawski E. Felstaine November 2000 ASCII HTML 31 intserv QoS Quality of Service end-to-end

This document describes a framework by which Integrated Services may be supported over Diffserv networks. This memo provides information for the Internet community.

draft-ietf-issll-diffserv-rsvp-05 INFORMATIONAL INFORMATIONAL IETF tsv issll 10.17487/RFC2998
RFC2999 Request for Comments Summary RFC Numbers 2900-2999 S. Ginoza August 2001 ASCII HTML 23 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC2999 RFC3000 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza L. Shiota November 2001 ASCII HTML 43

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 25, 2001. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

RFC2900 RFC3300 HISTORIC INTERNET STANDARD INDEPENDENT 10.17487/RFC3000
RFC3001 A URN Namespace of Object Identifiers M. Mealling November 2000 ASCII HTML 5 uniform resource names OIDs

This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

draft-mealling-oid-urn-01 RFC3061 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3001
RFC3002 Overview of 2000 IAB Wireless Internetworking Workshop D. Mitzel December 2000 ASCII HTML 42 internet architecture board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. This memo provides information for the Internet community.

draft-iab-wirelessws-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3002
RFC3003 The audio/mpeg Media Type M. Nilsson November 2000 ASCII HTML 5 MIME multipurpose internet mail extensions

The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose Internet Mail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents. [STANDARDS-TRACK]

draft-nilsson-audio-mpeg-03 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3003 10.17487/RFC3003
RFC3004 The User Class Option for DHCP G. Stump R. Droms Y. Gu R. Vyaghrapuri A. Demirtjis B. Beser J. Privat November 2000 ASCII HTML 6 dynamic host configuration protocol

This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. [STANDARDS-TRACK]

draft-ietf-dhc-userclass-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3004
RFC3005 IETF Discussion List Charter S. Harris November 2000 ASCII HTML 3 internet engineering task force

The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, considerable latitude is allowed. Advertising, whether to solicit business or promote employment opportunities, falls well outside the range of acceptable topics, as do discussions of a personal nature. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-poisson-listaup-02 RFC8717 BCP0045 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3005
RFC3006 Integrated Services in the Presence of Compressible Flows B. Davie C. Iturralde D. Oran S. Casner J. Wroclawski November 2000 ASCII HTML 13 routing resource allocation int-serv

This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. [STANDARDS-TRACK]

draft-ietf-intserv-compress-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv intserv 10.17487/RFC3006
RFC3007 Secure Domain Name System (DNS) Dynamic Update B. Wellington November 2000 ASCII HTML 9 security authentication validation DNSSEC

This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]

draft-ietf-dnsext-simple-secure-update-02 RFC2137 RFC2535 RFC2136 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3007
RFC3008 Domain Name System Security (DNSSEC) Signing Authority B. Wellington November 2000 ASCII HTML 7 DNSSEC authentication validation SIG signature

This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. [STANDARDS-TRACK]

draft-ietf-dnsext-signing-auth-02 RFC4035 RFC4033 RFC4034 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3008
RFC3009 Registration of parityfec MIME types J. Rosenberg H. Schulzrinne November 2000 ASCII HTML 10 media-type multimedia internet mail extensions

The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. [STANDARDS-TRACK]

draft-ietf-avt-fecmime-01 RFC5109 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3009
RFC3010 NFS version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck December 2000 ASCII HTML 212 NFSv4 network file system

NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [STANDARDS-TRACK]

draft-ietf-nfsv4-07 RFC3530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3010 10.17487/RFC3010
RFC3011 The IPv4 Subnet Selection Option for DHCP G. Waters November 2000 ASCII HTML 7 internet protocol dynamic host configuration

This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address. [STANDARDS-TRACK]

draft-ietf-dhc-subnet-option-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3011
RFC3012 Mobile IPv4 Challenge/Response Extensions C. Perkins P. Calhoun November 2000 ASCII HTML 17 internet protocol authentication foreign agent

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. [STANDARDS-TRACK]

draft-ietf-mobileip-challenge-13 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3012
RFC3013 Recommended Internet Service Provider Security Services and Procedures T. Killalea November 2000 ASCII HTML 13 ISPs

The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grip-isp-expectations-06 BCP0046 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3013
RFC3014 Notification Log MIB R. Kavasseri November 2000 ASCII HTML 26 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. [STANDARDS-TRACK]

draft-ietf-disman-notif-log-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3014
RFC3015 Megaco Protocol Version 1.0 F. Cuervo N. Greene A. Rayhan C. Huitema B. Rosen J. Segers November 2000 ASCII HTML 179 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and a Media Gateway Controller. [STANDARDS-TRACK]

draft-ietf-megaco-merged-01 RFC2885 RFC2886 RFC3525 PROPOSED STANDARD PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3015 10.17487/RFC3015
RFC3016 RTP Payload Format for MPEG-4 Audio/Visual Streams Y. Kikuchi T. Nomura S. Fukunaga Y. Matsui H. Kimata November 2000 ASCII HTML 21 real-time transport protocol media-type

This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mpeg4-es-05 RFC6416 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3016
RFC3017 XML DTD for Roaming Access Phone Book M. Riegel G. Zorn December 2000 ASCII HTML 33 extensible markup language document type declaration

This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. [STANDARDS-TRACK]

draft-ietf-roamops-phonebook-xml-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops roamops 10.17487/RFC3017
RFC3018 Unified Memory Space Protocol Specification A. Bogdanov December 2000 ASCII HTML 81 UMSP network connection-oriented

This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. This memo defines an Experimental Protocol for the Internet community.

draft-bogdanov-umsp-00 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3018
RFC3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol B. Haberman R. Worzella January 2001 ASCII HTML 15 IPv6 MIB MLD

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [STANDARDS-TRACK]

draft-ietf-ipngwg-mld-mib-05 RFC5519 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3019
RFC3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function P. Pate B. Lynch K. Rehbehn December 2000 ASCII HTML 36 MIB management information base

This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. [STANDARDS-TRACK]

draft-ietf-frnetmib-mfrmib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3020
RFC3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links A. Retana R. White V. Fuller D. McPherson December 2000 ASCII HTML 10 internet protocol addresses subnet masks

With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK]

draft-retana-31bits-03 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3021
RFC3022 Traditional IP Network Address Translator (Traditional NAT) P. Srisuresh K. Egevang January 2001 ASCII HTML 16 internet protocol ports private

The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community.

draft-ietf-nat-traditional-05 RFC1631 INFORMATIONAL INFORMATIONAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3022 10.17487/RFC3022
RFC3023 XML Media Types M. Murata S. St. Laurent D. Kohn January 2001 ASCII HTML 39 extensible markup language web authority hypertext transfer protocol

This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]

draft-murata-xml-09 RFC2376 RFC7303 RFC2048 RFC6839 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3023 10.17487/RFC3023
RFC3024 Reverse Tunneling for Mobile IP, revised G. Montenegro Editor January 2001 ASCII HTML 30 internet protocol node care-of-address

This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. [STANDARDS-TRACK]

draft-ietf-mobileip-rfc2344-bis-02 RFC2344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3024 10.17487/RFC3024
RFC3025 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung February 2001 ASCII HTML 8 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

draft-ietf-mobileip-vendor-ext-11 RFC3115 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3025
RFC3026 Liaison to IETF/ISOC on ENUM R. Blane January 2001 ASCII HTML 6 dns domain name system internet security engineering task force E.164 number

Working Party 1/2, of the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. This memo provides information for the Internet community.

draft-itu-sg2-liason-enum-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3026
RFC3027 Protocol Complications with the IP Network Address Translator M. Holdrege P. Srisuresh January 2001 ASCII HTML 20 IP internet protocol network address translator

The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. This memo provides information for the Internet community.

draft-ietf-nat-protocol-complications-06 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3027
RFC3028 Sieve: A Mail Filtering Language T. Showalter January 2001 ASCII HTML 36 client server

This document describes a language for filtering e-mail messages at time of final delivery. [STANDARDS-TRACK]

draft-showalter-sieve-12 RFC5228 RFC5429 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3028 10.17487/RFC3028
RFC3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols C. Adams P. Sylvester M. Zolotarev R. Zuccherato February 2001 ASCII HTML 51 DVCS TTP trusted third party

This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-dcs-07 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC3029
RFC3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages G. Vaudreuil December 2000 ASCII HTML 12 simple mail transfer protocol multipurpose interent

This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]

draft-vaudreuil-esmtp-binary2-03 RFC1830 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3030 10.17487/RFC3030
RFC3031 Multiprotocol Label Switching Architecture E. Rosen A. Viswanathan R. Callon January 2001 ASCII HTML 61 MPLS

This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

draft-ietf-mpls-arch-06 RFC6178 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3031 10.17487/RFC3031
RFC3032 MPLS Label Stack Encoding E. Rosen D. Tappan G. Fedorkow Y. Rekhter D. Farinacci T. Li A. Conta January 2001 ASCII HTML 23 multi-protocol label switching

This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]

draft-ietf-mpls-label-encaps-07 RFC3443 RFC4182 RFC5332 RFC3270 RFC5129 RFC5462 RFC5586 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3032 10.17487/RFC3032
RFC3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol M. Suzuki January 2001 ASCII HTML 25 IP

The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. [STANDARDS-TRACK]

draft-ietf-mpls-git-uus-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3033
RFC3034 Use of Label Switching on Frame Relay Networks Specification A. Conta P. Doolan A. Malis January 2001 ASCII HTML 24 MPLS multi-protocol

This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. [STANDARDS-TRACK]

draft-ietf-mpls-fr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3034
RFC3035 MPLS using LDP and ATM VC Switching B. Davie J. Lawrence K. McCloghrie E. Rosen G. Swallow Y. Rekhter P. Doolan January 2001 ASCII HTML 20 multi-protocol label switching asynchronous transfer mode distribution protocol

This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. [STANDARDS-TRACK]

draft-ietf-mpls-atm-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3035
RFC3036 LDP Specification L. Andersson P. Doolan N. Feldman A. Fredette B. Thomas January 2001 ASCII HTML 132 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-11 RFC5036 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3036 10.17487/RFC3036
RFC3037 LDP Applicability B. Thomas E. Gray January 2001 ASCII HTML 7 label distribution protocol

A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-applic-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3037 10.17487/RFC3037
RFC3038 VCID Notification over ATM link for LDP K. Nagami Y. Katsube N. Demizu H. Esaki P. Doolan January 2001 ASCII HTML 19 asynchronous transfer mode label distribution protocol

This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. [STANDARDS-TRACK]

draft-ietf-mpls-vcid-atm-05 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3038
RFC3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile S. Santesson W. Polk P. Barzin M. Nystrom January 2001 ASCII HTML 35 syntax

This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The goal of this document is to define a general syntax independent of local legal requirements. [STANDARDS-TRACK]

draft-ietf-pkix-qc-06 RFC3739 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC3039
RFC3040 Internet Web Replication and Caching Taxonomy I. Cooper I. Melve G. Tomlinson January 2001 ASCII HTML 32 infrastructure www world wide

This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. This memo provides information for the Internet community.

draft-ietf-wrec-taxonomy-06 INFORMATIONAL INFORMATIONAL IETF app wrec 10.17487/RFC3040
RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves January 2001 ASCII HTML 17 internet protocol interface identifier

This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. [STANDARDS-TRACK]

draft-ietf-ipngwg-addrconf-privacy-04 RFC4941 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3041 10.17487/RFC3041
RFC3042 Enhancing TCP's Loss Recovery Using Limited Transmit M. Allman H. Balakrishnan S. Floyd January 2001 ASCII HTML 9 transmission control protocol

This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. [STANDARDS-TRACK]

draft-ietf-tsvwg-limited-xmit-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3042
RFC3043 The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations M. Mealling January 2001 ASCII HTML 5 uniform resource name

This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. This memo provides information for the Internet community.

draft-mealling-pin-urn-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3043
RFC3044 Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace S. Rozenfeld January 2001 ASCII HTML 15 serials identifier

This document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the Uniform Resource Name (URN) framework as a specific URN namespace identifier. This memo provides information for the Internet community.

draft-rozenfeld-urn-issn-00 RFC8254 HISTORIC INFORMATIONAL Legacy 10.17487/RFC3044
RFC3045 Storing Vendor Information in the LDAP root DSE M. Meredith January 2001 ASCII HTML 6 lightweight directory access protocol DSA-specific entry

This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. This memo provides information for the Internet community.

draft-mmeredith-rootdse-vendor-info-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3045
RFC3046 DHCP Relay Agent Information Option M. Patrick January 2001 ASCII HTML 14 dynamic host configuration protocol

Newer high-speed public Internet access technologies call for a high- speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. [STANDARDS-TRACK]

draft-ietf-dhc-agent-options-12 RFC6607 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3046
RFC3047 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi January 2001 ASCII HTML 8 international telecommunication union real-time transport protocol

This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use of G.722.1 with MIME and SDP. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g7221-01 RFC5577 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3047 10.17487/RFC3047
RFC3048 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer B. Whetten L. Vicisano R. Kermode M. Handley S. Floyd M. Luby January 2001 ASCII HTML 20 RMT protocol core

This document describes a framework for the standardization of bulk-data reliable multicast transport. This memo provides information for the Internet community.

draft-ietf-rmt-buildingblocks-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3048
RFC3049 TN3270E Service Location and Session Balancing J. Naugle K. Kasthurirangan G. Ledford January 2001 ASCII HTML 21 SLP

This document discusses the implementation of Service Location Protocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. [STANDARDS-TRACK]

draft-ietf-tn3270e-service-loc-06 PROPOSED STANDARD PROPOSED STANDARD IETF app tn3270e 10.17487/RFC3049
RFC3050 Common Gateway Interface for SIP J. Lennox H. Schulzrinne J. Rosenberg January 2001 ASCII HTML 35 session initiation protocol

This document defines a SIP CGI interface for providing SIP services on a SIP server. This memo provides information for the Internet community.

draft-lennox-sip-cgi-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3050
RFC3051 IP Payload Compression Using ITU-T V.44 Packet Method J. Heath J. Border January 2001 ASCII HTML 8 internet protocol international telecommunication union

This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.

draft-heath-ipcomp-v44-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3051
RFC3052 Service Management Architectures Issues and Review M. Eder S. Nag January 2001 ASCII HTML 12 framework packets network

The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. This memo provides information for the Internet community.

draft-irtf-nsmrg-sm-issues-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3052 10.17487/RFC3052
RFC3053 IPv6 Tunnel Broker A. Durand P. Fasano I. Guardini D. Lento January 2001 ASCII HTML 13 internet protocol infrastructure

The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999. This memo provides information for the Internet community.

draft-ietf-ngtrans-broker-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3053
RFC3054 Megaco IP Phone Media Gateway Application Profile P. Blatherwick R. Bell P. Holland January 2001 ASCII HTML 14 internet protocol H.248 telephone MG

This document specifies a particular application of the Megaco/H.248 Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. This memo provides information for the Internet community.

draft-ietf-megaco-ipphone-03 INFORMATIONAL INFORMATIONAL IETF rai megaco 10.17487/RFC3054
RFC3055 Management Information Base for the PINT Services Architecture M. Krishnaswamy D. Romascanu February 2001 ASCII HTML 21 MIB PSTN/Internet interworking

This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture. [STANDARDS-TRACK]

draft-ietf-pint-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pint 10.17487/RFC3055
RFC3056 Connection of IPv6 Domains via IPv4 Clouds B. Carpenter K. Moore February 2001 ASCII HTML 23 internet protocol wide area network unicast point-to-point

This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]

draft-ietf-ngtrans-6to4-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops ngtrans http://www.rfc-editor.org/errata_search.php?rfc=3056 10.17487/RFC3056
RFC3057 ISDN Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom February 2001 ASCII HTML 66 SCTP signaling media gateway interface

This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). [STANDARDS-TRACK]

draft-ietf-sigtran-iua-10 RFC4233 RFC3807 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3057
RFC3058 Use of the IDEA Encryption Algorithm in CMS S. Teiwes P. Hartmann D. Kuenzi February 2001 ASCII HTML 8 international data encryption algorithm cryptic message syntax s/mime multipurpose internet mail extensions

This memo specifies how to incorporate International Data Encryption Algorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. This memo provides information for the Internet community.

draft-ietf-smime-idea-08 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3058 10.17487/RFC3058
RFC3059 Attribute List Extension for the Service Location Protocol E. Guttman February 2001 ASCII HTML 6 SLPv2 messages user agent

This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. [STANDARDS-TRACK]

draft-guttman-svrloc-attrlist-ext-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3059
RFC3060 Policy Core Information Model -- Version 1 Specification B. Moore E. Ellesson J. Strassner A. Westerinen February 2001 ASCII HTML 100 CIM common schema object-oriented

This document presents the object-oriented information model for representing policy information developed jointly in the IETF Policy Framework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). [STANDARDS-TRACK]

draft-ietf-policy-core-info-model-08 RFC3460 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3060
RFC3061 A URN Namespace of Object Identifiers M. Mealling February 2001 ASCII HTML 6 uniform resource names OIDs

This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). This memo provides information for the Internet community.

draft-mealling-rfc3001bis-01 RFC3001 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3061 10.17487/RFC3061
RFC3062 LDAP Password Modify Extended Operation K. Zeilenga February 2001 ASCII HTML 6 lightweight directory access protocol

This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. [STANDARDS-TRACK]

draft-zeilenga-ldap-passwd-exop-05 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3062 10.17487/RFC3062
RFC3063 MPLS Loop Prevention Mechanism Y. Ohba Y. Katsube E. Rosen P. Doolan February 2001 ASCII HTML 44 multiprotocol label switching path LSPs

This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mpls-loop-prevention-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3063
RFC3064 MGCP CAS Packages B. Foster February 2001 ASCII HTML 56 media gateway controllers

This document contains a collection of media gateway Channel Associated Signaling (CAS) packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. This memo provides information for the Internet community.

draft-foster-mgcp-cas-packages-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3064
RFC3065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder February 2001 ASCII HTML 11 BGP-ASC AS border gateway protocol

This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. [STANDARDS-TRACK]

draft-ietf-idr-bgp-confed-rfc1965bis-01 RFC1965 RFC5065 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3065 10.17487/RFC3065
RFC3066 Tags for the Identification of Languages H. Alvestrand January 2001 ASCII HTML 13 Lang-Tag

This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-alvestrand-lang-tag-v2-05 RFC1766 RFC4646 RFC4647 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3066 10.17487/RFC3066
RFC3067 TERENA'S Incident Object Description and Exchange Format Requirements J. Arvidsson A. Cormack Y. Demchenko J. Meijer February 2001 ASCII HTML 17 IEDEF data archiving

The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (Computer Security Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements. This memo provides information for the Internet community.

draft-terena-itdwg-iodef-requirements-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3067
RFC3068 An Anycast Prefix for 6to4 Relay Routers C. Huitema June 2001 ASCII HTML 9 exterior gateway protocol interior IGP EGP

This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned Numbers Authority) of the "6to4 relay anycast prefix." [STANDARDS-TRACK]

draft-ietf-ngtrans-6to4anycast-03 RFC7526 HISTORIC PROPOSED STANDARD IETF ops ngtrans 10.17487/RFC3068
RFC3069 VLAN Aggregation for Efficient IP Address Allocation D. McPherson B. Dykes February 2001 ASCII HTML 7 virtual local area network internet protocol

This document introduces the concept of Virtual Local Area Network (VLAN) aggregation as it relates to IPv4 address allocation. This memo provides information for the Internet community.

draft-mcpherson-vlan-ipagg-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3069 10.17487/RFC3069
RFC3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay V. Rawat R. Tio S. Nanji R. Verma February 2001 ASCII HTML 7 L2TP-FR point-to-point virtual switched circuits PVCs SVCs

This document describes how L2TP is implemented over Frame Relay Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). [STANDARDS-TRACK]

draft-ietf-l2tpext-fr-01 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3070
RFC3071 Reflections on the DNS, RFC 1591, and Categories of Domains J. Klensin February 2001 ASCII HTML 10 DNS Policy Top-Level TLD

This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how 1591 might have been interpreted and adjusted by the Internet Assigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. This memo provides information for the Internet community.

draft-klensin-1591-reflections-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3071
RFC3072 Structured Data Exchange Format (SDXF) M. Wildgrube March 2001 ASCII HTML 26 chunks file datatype

This specification describes an all-purpose interchange format for use as a file format or for net-working. This memo provides information for the Internet community.

draft-wildgrube-sdxf-08 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3072
RFC3073 Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration J. Collins March 2001 ASCII HTML 6 multipurpose internet mail extensions

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification. This memo provides information for the Internet community.

draft-collins-pfr-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3073
RFC3074 DHC Load Balancing Algorithm B. Volz S. Gonczi T. Lemon R. Stevens February 2001 ASCII HTML 10 dynamic host configuration protocol

This document proposes a method of algorithmic load balancing. [STANDARDS-TRACK]

draft-ietf-dhc-loadb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3074
RFC3075 XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2001 ASCII HTML 64 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

draft-ietf-xmldsig-core-11 RFC3275 PROPOSED STANDARD PROPOSED STANDARD IETF sec xmldsig 10.17487/RFC3075
RFC3076 Canonical XML Version 1.0 J. Boyer March 2001 ASCII HTML 28 extensible markup language

This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. This memo provides information for the Internet community.

draft-ietf-xmldsig-canonical-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3076
RFC3077 A Link-Layer Tunneling Mechanism for Unidirectional Links E. Duros W. Dabbous H. Izumiyama N. Fujii Y. Zhang March 2001 ASCII HTML 25 ll udl bidirectional connectivity ip internet protocol

This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. [STANDARDS-TRACK]

draft-ietf-udlr-lltunnel-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg udlr 10.17487/RFC3077
RFC3078 Microsoft Point-To-Point Encryption (MPPE) Protocol G. Pall G. Zorn March 2001 ASCII HTML 12 security ppp

This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides information for the Internet community.

draft-ietf-pppext-mppe-05 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC3078
RFC3079 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) G. Zorn March 2001 ASCII HTML 21 security ppp

This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. This memo provides information for the Internet community.

draft-ietf-pppext-mppe-keys-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3079
RFC3080 The Blocks Extensible Exchange Protocol Core M. Rose March 2001 ASCII HTML 58 BEEP text binary messages kernal

This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. [STANDARDS-TRACK]

draft-ietf-beep-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF app beep http://www.rfc-editor.org/errata_search.php?rfc=3080 10.17487/RFC3080
RFC3081 Mapping the BEEP Core onto TCP M. Rose March 2001 ASCII HTML 8 transmission control protocol blocks extensible exchange

This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. [STANDARDS-TRACK]

draft-ietf-beep-tcpmapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app beep 10.17487/RFC3081
RFC3082 Notification and Subscription for SLP J. Kempf J. Goldschmidt March 2001 ASCII HTML 14 service location protocol

The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. This memo defines an Experimental Protocol for the Internet community.

draft-kempf-srvloc-notify-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3082
RFC3083 Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems R. Woundy March 2001 ASCII HTML 45 MIB BPI data-over-cable service interface specifications

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over- Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670. This memo provides information for the Internet community.

draft-ietf-ipcdn-mcns-bpi-mib-02 INFORMATIONAL INFORMATIONAL IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=3083 10.17487/RFC3083
RFC3084 COPS Usage for Policy Provisioning (COPS-PR) K. Chan J. Seligson D. Durham S. Gai K. McCloghrie S. Herzog F. Reichmeyer R. Yavatkar A. Smith March 2001 ASCII HTML 34 COPS-PR common open service security quality

This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK]

draft-ietf-rap-pr-05 HISTORIC PROPOSED STANDARD IETF ops rap 10.17487/RFC3084
RFC3085 URN Namespace for NewsML Resources A. Coates D. Allen D. Rivers-Moore March 2001 ASCII HTML 6 uniform resource name newsitems iptc

This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. This memo provides information for the Internet community.

draft-iptc-newsml-urn-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3085
RFC3086 Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification K. Nichols B. Carpenter April 2001 ASCII HTML 24 diffserv QoS quality of service

This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community.

draft-ietf-diffserv-pdb-def-03 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3086
RFC3087 Control of Service Context using SIP Request-URI B. Campbell R. Sparks April 2001 ASCII HTML 39 session initiation protocol uniform resource identifier

This memo describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. This memo provides information for the Internet community.

draft-campbell-sip-service-control-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3087
RFC3088 OpenLDAP Root Service An experimental LDAP referral service K. Zeilenga April 2001 ASCII HTML 11 lightweight directory access protocol dns domain name system

The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. This memo defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldap-root-02 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3088
RFC3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism H. Kitamura April 2001 ASCII HTML 12 internet protocol application layer

This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. This memo provides information for the Internet community.

draft-ietf-ngtrans-socks-gateway-06 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3089
RFC3090 DNS Security Extension Clarification on Zone Status E. Lewis March 2001 ASCII HTML 11 domain name system rsa dsa

The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated. [STANDARDS-TRACK]

draft-ietf-dnsext-zone-status-05 RFC4033 RFC4034 RFC4035 RFC2535 RFC3658 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3090
RFC3091 Pi Digit Generation Protocol H. Kennedy April 1 2001 ASCII HTML 6

This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3091 10.17487/RFC3091
RFC3092 Etymology of "Foo" D. Eastlake 3rd C. Manros E. Raymond April 1 2001 ASCII HTML 14

Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3092 10.17487/RFC3092
RFC3093 Firewall Enhancement Protocol (FEP) M. Gaynor S. Bradner April 1 2001 ASCII HTML 11

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3093
RFC3094 Tekelec's Transport Adapter Layer Interface D. Sprague R. Benedyk D. Brendes J. Keller April 2001 ASCII HTML 106 signaling gatewa circuit network internet protocol

This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. This memo provides information for the Internet community.

draft-benedyk-sigtran-tali-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3094
RFC3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed C. Bormann C. Burmeister M. Degermark H. Fukushima H. Hannu L-E. Jonsson R. Hakenberg T. Koren K. Le Z. Liu A. Martensson A. Miyazaki K. Svanbro T. Wiebke T. Yoshimura H. Zheng July 2001 ASCII HTML 168 encapsulating security payload real-time transport protocol user datagram

This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, and ESP/IP (Encapsulating Security Payload) headers. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-09 RFC3759 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3095
RFC3096 Requirements for robust IP/UDP/RTP header compression M. Degermark Editor July 2001 ASCII HTML 8 real-time transport internet protocol user datagram

This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. This memo provides information for the Internet community.

draft-ietf-rohc-rtp-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3096
RFC3097 RSVP Cryptographic Authentication -- Updated Message Type Value R. Braden L. Zhang April 2001 ASCII HTML 4 RSVP resource reservation protocol security

This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK]

draft-ietf-rsvp-fix-iana-00 RFC2747 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rsvp 10.17487/RFC3097
RFC3098 How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ T. Gavin D. Eastlake 3rd S. Hambridge April 2001 ASCII HTML 28 internet marketing users service providers isps

This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. This memo provides information for the Internet community.

draft-ietf-run-adverts-02 FYI0038 INFORMATIONAL INFORMATIONAL IETF run 10.17487/RFC3098
RFC3099 Request for Comments Summary RFC Numbers 3000-3099 S. Ginoza November 2001 ASCII HTML 25 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3099 RFC3100 RFC3101 The OSPF Not-So-Stubby Area (NSSA) Option P. Murphy January 2003 ASCII HTML 33 OSPF-NSSA stub external routes backward compatible

This memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]

draft-ietf-ospf-nssa-update-11 RFC1587 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=3101 10.17487/RFC3101
RFC3102 Realm Specific IP: Framework M. Borella J. Lo D. Grabelsky G. Montenegro October 2001 ASCII HTML 30 RSIP end-to-end NAT addressing requirements

This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-framework-05 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3102
RFC3103 Realm Specific IP: Protocol Specification M. Borella D. Grabelsky J. Lo K. Taniguchi October 2001 ASCII HTML 54 RSIP host gateway NAT requirements

This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-protocol-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3103
RFC3104 RSIP Support for End-to-end IPsec G. Montenegro M. Borella October 2001 ASCII HTML 19 realm specific internet protocol NAT addressing requirements

This document proposes mechanisms that enable Realm Specific IP (RSIP) to handle end-to-end IPsec (IP Security). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-ipsec-04 EXPERIMENTAL EXPERIMENTAL IETF tsv nat http://www.rfc-editor.org/errata_search.php?rfc=3104 10.17487/RFC3104
RFC3105 Finding an RSIP Server with SLP J. Kempf G. Montenegro October 2001 ASCII HTML 11 realm specific internet protocol service location NAT addressing requirements

This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-nat-rsip-slp-00 EXPERIMENTAL EXPERIMENTAL IETF tsv nat 10.17487/RFC3105
RFC3106 ECML v1.1: Field Specifications for E-Commerce D. Eastlake 3rd T. Goldstein April 2001 ASCII HTML 20 electronic modeling language

Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. This memo provides information for the Internet community.

draft-eastlake-ecom-fields2-05 RFC2706 RFC4112 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3106
RFC3107 Carrying Label Information in BGP-4 Y. Rekhter E. Rosen May 2001 ASCII HTML 8 SDP asynchronous transfer mode AAL syntax adaption layer

This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]

draft-ietf-mpls-bgp4-mpls-04 RFC8277 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3107 10.17487/RFC3107
RFC3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections R. Kumar M. Mostafa May 2001 ASCII HTML 110 asynchronous transfer mode AAL syntax adaption layer

This document describes conventions for using the Session Description Protocol (SDP) described in RFC 2327 for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-atm-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3108 10.17487/RFC3108
RFC3109 Request to Move STD 39 to Historic Status R. Braden R. Bush J. Klensin May 2001 ASCII HTML 4 BBN 1822 host imp arpanet

This memo changes the status of STD 39, BBN Report 1822, "Specification of the Interconnection of a Host and an IMP", from Standard to Historic. This memo provides information for the Internet community.

draft-ymbk-std39-historic-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3109
RFC3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) D. Eastlake 3rd May 2001 ASCII HTML 7 RRs resource records security

This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]

draft-ietf-dnsext-rsa-03 RFC2537 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3110 10.17487/RFC3110
RFC3111 Service Location Protocol Modifications for IPv6 E. Guttman May 2001 ASCII HTML 13 SLP internet protocol

This document defines the Service Location Protocol Version 2's (SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. [STANDARDS-TRACK]

draft-ietf-svrloc-ipv6-12 PROPOSED STANDARD PROPOSED STANDARD IETF int svrloc 10.17487/RFC3111
RFC3112 LDAP Authentication Password Schema K. Zeilenga May 2001 ASCII HTML 9 lightweight directory access protocol

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This memo provides information for the Internet community.

draft-zeilenga-ldap-authpasswd-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3112
RFC3113 3GPP-IETF Standardization Collaboration K. Rosenbrock R. Sanmugam S. Bradner J. Klensin June 2001 ASCII HTML 7 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community.

draft-3gpp-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3113
RFC3114 Implementing Company Classification Policy with the S/MIME Security Label W. Nicolls May 2002 ASCII HTML 14 data multipurpose internet mail extensions access control information classification security category

This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. This memo provides information for the Internet community.

draft-ietf-smime-seclabel-03 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3114
RFC3115 Mobile IP Vendor/Organization-Specific Extensions G. Dommety K. Leung April 2001 ASCII HTML 9 internet protocol

This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. [STANDARDS-TRACK]

RFC3025 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3115
RFC3116 Methodology for ATM Benchmarking J. Dunn C. Martin June 2001 ASCII HTML 127 asynchronous transfer mode formats switching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (Asynchronous Transfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community.

draft-ietf-bmwg-atm-method-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3116
RFC3117 On the Design of Application Protocols M. Rose November 2001 ASCII HTML 27 beep bxxp blocks extensible exchange text binary

This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.

draft-mrose-beep-design-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3117
RFC3118 Authentication for DHCP Messages R. Droms Editor W. Arbaugh Editor June 2001 ASCII HTML 17 dynamic host configuration protocol verification

This document defines a new Dynamic Host Configuration Protocol (DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. [STANDARDS-TRACK]

draft-ietf-dhc-authentication-16 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3118 10.17487/RFC3118
RFC3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson June 2001 ASCII HTML 19 real-time protocol moving picture experts group

This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mp3-06 RFC5219 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3119 10.17487/RFC3119
RFC3120 A URN Namespace for XML.org K. Best N. Walsh June 2001 ASCII HTML 5 uniform resource name extensible markup language

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

draft-best-xmlorg-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3120
RFC3121 A URN Namespace for OASIS K. Best N. Walsh June 2001 ASCII HTML 7 uniform resource name organization for the advancement of structured information standards

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of Structured Information Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). This memo provides information for the Internet community.

draft-best-urn-oasis-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3121
RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification A. Conta June 2001 ASCII HTML 20 internet protocol IND link-layer

This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. [STANDARDS-TRACK]

draft-ietf-ion-ipv6-ind-05 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg http://www.rfc-editor.org/errata_search.php?rfc=3122 10.17487/RFC3122
RFC3123 A DNS RR Type for Lists of Address Prefixes (APL RR) P. Koch June 2001 ASCII HTML 8 domain name system resource record

The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnsext-apl-rr-02 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC3123
RFC3124 The Congestion Manager H. Balakrishnan S. Seshan June 2001 ASCII HTML 22 network stream end-system module

This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK]

draft-ietf-ecm-cm-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ecm 10.17487/RFC3124
RFC3125 Electronic Signature Policies J. Ross D. Pinkas N. Pope September 2001 ASCII HTML 44 signer purchase contract invoice transactions applications

This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-smime-espolicies-00 EXPERIMENTAL EXPERIMENTAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3125 10.17487/RFC3125
RFC3126 Electronic Signature Formats for long term electronic signatures D. Pinkas J. Ross N. Pope September 2001 ASCII HTML 84 purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates the validity of the signature). This memo provides information for the Internet community.

draft-ietf-smime-esformats-03 RFC5126 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3126 10.17487/RFC3126
RFC3127 Authentication, Authorization, and Accounting: Protocol Evaluation D. Mitton M. St.Johns S. Barkley D. Nelson B. Patil M. Stevens B. Wolff June 2001 ASCII HTML 84 AAA network access requirements

This memo represents the process and findings of the Authentication, Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC 2989. This memo provides information for the Internet community.

draft-ietf-aaa-proto-eval-02 INFORMATIONAL INFORMATIONAL IETF ops aaa 10.17487/RFC3127
RFC3128 Protection Against a Variant of the Tiny Fragment Attack (RFC 1858) I. Miller June 2001 ASCII HTML 5 firewalls internet

This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. This memo provides information for the Internet community.

draft-miller-rfc1858-cmts-00 RFC1858 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3128
RFC3129 Requirements for Kerberized Internet Negotiation of Keys M. Thomas June 2001 ASCII HTML 6 KINK cryptographic security authentication

The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. This memo provides information for the Internet community.

draft-ietf-kink-reqmt-03 INFORMATIONAL INFORMATIONAL IETF sec kink 10.17487/RFC3129
RFC3130 Notes from the State-Of-The-Technology: DNSSEC E. Lewis June 2001 ASCII HTML 10 domain name system security extensions report

This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. This memo provides information for the Internet community.

draft-lewis-state-of-dnssec-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3130
RFC3131 3GPP2-IETF Standardization Collaboration S. Bradner P. Calhoun H. Cuschieri S. Dennett G. Flynn M. Lipford M. McPheters June 2001 ASCII HTML 8 internet engineering task force third generation partnership project

This document describes the standardization collaboration between 3GPP2 and IETF. This memo provides information for the Internet community.

draft-bradner-3gpp2-collaboration-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3131
RFC3132 Dormant Mode Host Alerting ("IP Paging") Problem Statement J. Kempf June 2001 ASCII HTML 14 molulity radio link internet protocl

This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. This memo provides information for the Internet community.

draft-ietf-seamoby-paging-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3132
RFC3133 Terminology for Frame Relay Benchmarking J. Dunn C. Martin June 2001 ASCII HTML 24 switching devices signaling

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. This memo provides information for the Internet community.

draft-ietf-bmwg-fr-term-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3133
RFC3134 Terminology for ATM ABR Benchmarking J. Dunn C. Martin June 2001 ASCII HTML 16 asynchronous transfer mode available bit rate

This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR (Available Bit Rate). This memo provides information for the Internet community.

draft-ietf-bmwg-atm-term-abr-03 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3134
RFC3135 Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations J. Border M. Kojo J. Griner G. Montenegro Z. Shelby June 2001 ASCII HTML 45 PEP PILC TCP transmission control protocol

This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community.

draft-ietf-pilc-pep-07 INFORMATIONAL INFORMATIONAL IETF tsv pilc 10.17487/RFC3135
RFC3136 The SPIRITS Architecture L. Slutsman Editor I. Faynberg H. Lu M. Weissman June 2001 ASCII HTML 10 PSTN public switched telephone network

This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network)and necessitating the interactions between the PSTN and the Internet. This memo provides information for the Internet community.

draft-ietf-spirits-architecture-03 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3136
RFC3137 OSPF Stub Router Advertisement A. Retana L. Nguyen R. White A. Zinin D. McPherson June 2001 ASCII HTML 5 open shortest path first

This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. This memo provides information for the Internet community.

draft-ietf-ospf-stub-adv-02 RFC6987 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3137
RFC3138 Extended Assignments in 233/8 D. Meyer June 2001 ASCII HTML 4 internet address AS autonomous system number

This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. This memo provides information for the Internet community.

draft-ietf-mboned-glop-extensions-02 RFC5771 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3138
RFC3139 Requirements for Configuration Management of IP-based Networks L. Sanchez K. McCloghrie J. Saperia June 2001 ASCII HTML 11 internet protocol

This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP-based networks. This memo provides information for the Internet community.

draft-ops-ip-config-management-reqmnts-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3139
RFC3140 Per Hop Behavior Identification Codes D. Black S. Brim B. Carpenter F. Le Faucheur June 2001 ASCII HTML 8 PHB differentiated services codepoint DSCP

This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836. [STANDARDS-TRACK]

draft-ietf-diffserv-2836bis-02 RFC2836 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3140
RFC3141 CDMA2000 Wireless Data Requirements for AAA T. Hiller P. Walsh X. Chen M. Munson G. Dommety S. Sivalingham B. Lim P. McCann H. Shiino B. Hirschman S. Manning R. Hsu H. Koo M. Lipford P. Calhoun C. Lo E. Jaques E. Campbell Y. Xu S. Baba T. Ayaki T. Seki A. Hameed June 2001 ASCII HTML 16 authentication authorization accounting

This memo specifies cdma2000 wireless data AAA (Authentication, Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. This memo provides information for the Internet community.

draft-hiller-cdma2000-aaa-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3141
RFC3142 An IPv6-to-IPv4 Transport Relay Translator J. Hagino K. Yamamoto June 2001 ASCII HTML 11 TRT internet protocol

The document describes an IPv6-to-IPv4 transport relay translator (TRT). This memo provides information for the Internet community.

draft-ietf-ngtrans-tcpudp-relay-04 INFORMATIONAL INFORMATIONAL IETF ops ngtrans 10.17487/RFC3142
RFC3143 Known HTTP Proxy/Caching Problems I. Cooper J. Dilley June 2001 ASCII HTML 32 www world wide web hypertext transfer protocol

This document catalogs a number of known problems with World Wide Web (WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. This memo provides information for the Internet community.

draft-cooper-wrec-known-prob-01 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3143 10.17487/RFC3143
RFC3144 Remote Monitoring MIB Extensions for Interface Parameters Monitoring D. Romascanu August 2001 ASCII HTML 30 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. [STANDARDS-TRACK]

draft-ietf-rmonmib-iftopn-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3144
RFC3145 L2TP Disconnect Cause Information R. Verma M. Verma J. Carlson July 2001 ASCII HTML 10 layer2 tunneling PPP point-to-point accounting debugging

This document provides an extension to the Layer 2 Tunneling Protocol ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3145
RFC3146 Transmission of IPv6 Packets over IEEE 1394 Networks K. Fujisawa A. Onoe October 2001 ASCII HTML 8 link-local addresses statelessly autoconfigured

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. [STANDARDS-TRACK]

draft-ietf-ipngwg-1394-02 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipngwg 10.17487/RFC3146
RFC3147 Generic Routing Encapsulation over CLNS Networks P. Christian July 2001 ASCII HTML 8 connectionless network service GRE layer protocol

This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network using GRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3147
RFC3148 A Framework for Defining Empirical Bulk Transfer Capacity Metrics M. Mathis M. Allman July 2001 ASCII HTML 16 BTC transport data

This document defines a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that parallel the permitted transport diversity. This memo provides information for the Internet community.

draft-ietf-ippm-btc-framework-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3148
RFC3149 MGCP Business Phone Packages A. Srinath G. Levendel K. Fritz R. Kalyanaram September 2001 ASCII HTML 41 media gateway control packages

This document describes a collection of MGCP (Media Gateway Control Protocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. This memo provides information for the Internet community.

draft-srinath-mgcp-bus-packages-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3149
RFC3150 End-to-end Performance Implications of Slow Links S. Dawkins G. Montenegro M. Kojo V. Magret July 2001 ASCII HTML 17 PILC data applications header compression

This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-slow-06 BCP0048 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3150
RFC3151 A URN Namespace for Public Identifiers N. Walsh J. Cowan P. Grosso August 2001 ASCII HTML 9 uniform resource name publicid

This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI (Uniform Resource Identifiers) syntax. This memo provides information for the Internet community.

draft-walsh-urn-publicid-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3151
RFC3152 Delegation of IP6.ARPA R. Bush August 2001 ASCII HTML 4 internet protocol domain name system DNS zone

This document discusses the need for delegation of the IP6.ARPA DNS zone, and specifies a plan for the technical operation thereof. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ymbk-ip6-arpa-delegation-02 RFC3596 RFC2874 RFC2772 RFC2766 RFC2553 RFC1886 BCP0049 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3152
RFC3153 PPP Multiplexing R. Pazhyannur I. Ali C. Fox August 2001 ASCII HTML 9 point-to-point protocol

This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links. [STANDARDS-TRACK]

draft-ietf-pppext-pppmux-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3153
RFC3154 Requirements and Functional Architecture for an IP Host Alerting Protocol J. Kempf C. Castelluccia P. Mutaf N. Nakajima Y. Ohba R. Ramjee Y. Saifullah B. Sarikaya X. Xu August 2001 ASCII HTML 16 internet protocol paging mobile hosts

This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of an IP protocol for alerting dormant IP mobile hosts, commonly called paging. This memo provides information for the Internet community.

draft-ietf-seamoby-paging-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3154
RFC3155 End-to-end Performance Implications of Links with Errors S. Dawkins G. Montenegro M. Kojo V. Magret N. Vaidya August 2001 ASCII HTML 16 TCP transmission control protocol

This document discusses the specific TCP mechanisms that are problematic in environments with high uncorrected error rates, and discusses what can be done to mitigate the problems without introducing intermediate devices into the connection. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-error-08 BCP0050 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3155
RFC3156 MIME Security with OpenPGP M. Elkins D. Del Torto R. Levien T. Roessler August 2001 ASCII HTML 15 MIME-PGP Authentication Encryption

This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]

draft-ietf-openpgp-mime-07 RFC2015 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=3156 10.17487/RFC3156
RFC3157 Securely Available Credentials - Requirements A. Arsenault S. Farrell August 2001 ASCII HTML 20 SACRED trusted roots private keys PSE personal security environment

This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This memo provides information for the Internet community.

draft-ietf-sacred-reqs-03 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3157
RFC3158 RTP Testing Strategies C. Perkins J. Rosenberg H. Schulzrinne August 2001 ASCII HTML 22 real-time transport protocol

This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. This memo provides information for the Internet community.

draft-ietf-avt-rtptest-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC3158
RFC3159 Structure of Policy Provisioning Information (SPPI) K. McCloghrie M. Fine J. Seligson K. Chan S. Hahn R. Sahita A. Smith F. Reichmeyer August 2001 ASCII HTML 40 PIB base SNMP simple network management information SMI

This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK]

draft-ietf-rap-sppi-07 HISTORIC PROPOSED STANDARD IETF ops rap 10.17487/RFC3159
RFC3160 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force S. Harris August 2001 ASCII HTML 38 Internet Engineering Task Force Meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. This memo provides information for the Internet community.

draft-ietf-uswg-tao-06 RFC1718 RFC4677 INFORMATIONAL INFORMATIONAL IETF uswg 10.17487/RFC3160
RFC3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) C. Adams P. Cain D. Pinkas R. Zuccherato August 2001 ASCII HTML 26 TSA authority security request response

This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK]

draft-ietf-pkix-time-stamp-15 RFC5816 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3161 10.17487/RFC3161
RFC3162 RADIUS and IPv6 B. Aboba G. Zorn D. Mitton August 2001 ASCII HTML 12 remote authentication dial in user service attributes

This document specifies the operation of RADIUS (Remote Authentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. [STANDARDS-TRACK]

draft-aboba-radius-ipv6-10 RFC8044 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3162 10.17487/RFC3162
RFC3163 ISO/IEC 9798-3 Authentication SASL Mechanism R. Zuccherato M. Nystrom August 2001 ASCII HTML 17 simple authentication security layer

This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication. This memo defines an Experimental Protocol for the Internet community.

draft-zuccherato-9798-3-sasl-03 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3163
RFC3164 The BSD Syslog Protocol C. Lonvick August 2001 ASCII HTML 29 berkeley software distribution transmission messages

This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community.

draft-ietf-syslog-syslog-12 RFC5424 INFORMATIONAL INFORMATIONAL IETF sec syslog 10.17487/RFC3164
RFC3165 Definitions of Managed Objects for the Delegation of Management Scripts D. Levi J. Schoenwaelder August 2001 ASCII HTML 64 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. [STANDARDS-TRACK]

draft-ietf-disman-script-mib-v2-04 RFC2592 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3165 10.17487/RFC3165
RFC3166 Request to Move RFC 1403 to Historic Status D. Meyer J. Scudder August 2001 ASCII HTML 3 BGP-OSPF Border gateway protocol Open shortest path first routing

RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved to Historic status. This memo provides information for the Internet community.

draft-meyer-rfc1403-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3166
RFC3167 Request to Move RFC 1745 to Historic Status D. Meyer J. Scudder August 2001 ASCII HTML 3 BGP4/IDRP Internet Inter-Domain Routing Protocol Border Gateway Open Shortest Path First

RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. This memo provides information for the Internet community.

draft-meyer-rfc1745-historic-00 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3167
RFC3168 The Addition of Explicit Congestion Notification (ECN) to IP K. Ramakrishnan S. Floyd D. Black September 2001 ASCII HTML 63 internet protocol header

This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]

draft-ietf-tsvwg-ecn-04 RFC2481 RFC2003 RFC2474 RFC2401 RFC0793 RFC4301 RFC6040 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3168 10.17487/RFC3168
RFC3169 Criteria for Evaluating Network Access Server Protocols M. Beadles D. Mitton September 2001 ASCII HTML 17 NAS network device AAA authentication authorization accounting

This document defines requirements for protocols used by Network Access Servers (NAS). This memo provides information for the Internet community.

draft-ietf-nasreq-criteria-06 INFORMATIONAL INFORMATIONAL IETF ops nasreq 10.17487/RFC3169
RFC3170 IP Multicast Applications: Challenges and Solutions B. Quinn K. Almeroth September 2001 ASCII HTML 28 internet protocol unicast

This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. This memo provides information for the Internet community.

draft-ietf-mboned-mcast-apps-02 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3170
RFC3171 IANA Guidelines for IPv4 Multicast Address Assignments Z. Albanna K. Almeroth D. Meyer M. Schipper August 2001 ASCII HTML 8 internet assigned numbers authority protocol parameters

This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-iana-ipv4-mcast-guidelines-04 RFC5771 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3171 10.17487/RFC3171
RFC3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa") G. Huston Editor September 2001 ASCII HTML 8 database DNS domain name system

This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-arpa-03 BCP0052 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC3172
RFC3173 IP Payload Compression Protocol (IPComp) A. Shacham B. Monsour R. Pereira M. Thomas September 2001 ASCII HTML 13 IPCOMP internet protocol datagram lossless

This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. [STANDARDS-TRACK]

draft-shacham-ippcp-rfc2393bis-08 RFC2393 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3173
RFC3174 US Secure Hash Algorithm 1 (SHA1) D. Eastlake 3rd P. Jones September 2001 ASCII HTML 22 FIPS federal information processing standard

The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.

draft-eastlake-sha1-02 RFC4634 RFC6234 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3174 10.17487/RFC3174
RFC3175 Aggregation of RSVP for IPv4 and IPv6 Reservations F. Baker C. Iturralde F. Le Faucheur B. Davie September 2001 ASCII HTML 36 resource reservation protocol internet ATM asynchronous transfer mode

This document describes the use of a single RSVP (Resource ReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM (Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. [STANDARDS-TRACK]

draft-ietf-issll-rsvp-aggr-04 RFC5350 PROPOSED STANDARD PROPOSED STANDARD IETF tsv issll 10.17487/RFC3175
RFC3176 InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks P. Phaal S. Panchen N. McKee September 2001 ASCII HTML 31 agent data MIB management information base

This memo defines InMon Corporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. This memo provides information for the Internet community.

draft-phaal-sflow-montraffic-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3176
RFC3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites IAB IESG September 2001 ASCII HTML 10 internet architecture board engineering steering group protocol

This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.

draft-iesg-ipv6-addressing-recommendations-03 RFC6177 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3177
RFC3178 IPv6 Multihoming Support at Site Exit Routers J. Hagino H. Snyder October 2001 ASCII HTML 12 internet protocol ISP Service Provider Routing

The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community.

draft-ietf-ipngwg-ipv6-2260-02 INFORMATIONAL INFORMATIONAL IETF int ipngwg 10.17487/RFC3178
RFC3179 Script MIB Extensibility Protocol Version 1.1 J. Schoenwaelder J. Quittek October 2001 ASCII HTML 25 SMX language management information base

The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. This memo defines an Experimental Protocol for the Internet community.

draft-schoenw-rfc-2593-update-04 RFC2593 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3179
RFC3180 GLOP Addressing in 233/8 D. Meyer P. Lothberg September 2001 ASCII HTML 5 static multicast

This document defines the policy for the use of 233/8 for statically e assigned multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-glop-update-01 RFC2770 BCP0053 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=3180 10.17487/RFC3180
RFC3181 Signaled Preemption Priority Policy Element S. Herzog October 2001 ASCII HTML 12 rsvp resource reservation protocol cops common open service

This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the Resource ReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). [STANDARDS-TRACK]

draft-ietf-rap-signaled-priority-v2-00 RFC2751 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3181
RFC3182 Identity Representation for RSVP S. Yadav R. Yavatkar R. Pabbati P. Ford T. Moore S. Herzog R. Hess October 2001 ASCII HTML 18 resource reservation protocol

This document describes the representation of identity information in POLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-newidentity-01 RFC2752 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap http://www.rfc-editor.org/errata_search.php?rfc=3182 10.17487/RFC3182
RFC3183 Domain Security Services using S/MIME T. Dean W. Ottaway October 2001 ASCII HTML 24 secure/multipurpose internet mail extensions

This document describes how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-smime-domsec-09 EXPERIMENTAL EXPERIMENTAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3183 10.17487/RFC3183
RFC3184 IETF Guidelines for Conduct S. Harris October 2001 ASCII HTML 4 internet engineering task force

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-poisson-code-04 RFC7154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen Poisson 10.17487/RFC3184
RFC3185 Reuse of CMS Content Encryption Keys S. Farrell S. Turner October 2001 ASCII HTML 10 cryptographic message syntax data packets

This document describes a way to include a key identifier in a CMS (Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. [STANDARDS-TRACK]

draft-ietf-smime-rcek-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3185
RFC3186 MAPOS/PPP Tunneling mode S. Shimizu T. Kawano K. Murakami E. Beier December 2001 ASCII HTML 14 multiple access protocol over SONET/SDH point-to-point

This document specifies tunneling configuration over MAPOS (Multiple Access Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. This memo provides information for the Internet community.

draft-shimizu-ppp-mapos-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3186
RFC3187 Using International Standard Book Numbers as Uniform Resource Names J. Hakala H. Walravens October 2001 ASCII HTML 11 isbn urn bibliographic identifiers

This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion below is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

draft-hakala-isbn-01 RFC8254 HISTORIC INFORMATIONAL Legacy 10.17487/RFC3187
RFC3188 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2001 ASCII HTML 13 urn nbn national libraries

This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. This memo provides information for the Internet community.

draft-hakala-nbn-01 RFC8458 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3188
RFC3189 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII HTML 13 real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). [STANDARDS-TRACK]

draft-ietf-avt-dv-video-04 RFC6469 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3189 10.17487/RFC3189
RFC3190 RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio K. Kobayashi A. Ogawa S. Casner C. Bormann January 2002 ASCII HTML 17 real-time transport protocol digital audio tape

This document specifies a packetization scheme for encapsulating 12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear). [STANDARDS-TRACK]

draft-ietf-avt-dv-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3190
RFC3191 Minimal GSTN address format in Internet Mail C. Allocchio October 2001 ASCII HTML 13 MIN-PSTN global switched telephone network email

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses (commonly called "telephone numbers") in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. [STANDARDS-TRACK]

draft-ietf-fax-minaddr-v2-04 RFC2303 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3191
RFC3192 Minimal FAX address format in Internet Mail C. Allocchio October 2001 ASCII HTML 11 MINFAX-IM facsimile GSTN global switched telephone network

This memo describes a simple method of encoding Global Switched Telephone Network (GSTN) addresses of facsimile devices in the local- part of Internet email addresses. [STANDARDS-TRACK]

draft-ietf-fax-faxaddr-v2-04 RFC2304 RFC2846 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3192
RFC3193 Securing L2TP using IPsec B. Patel B. Aboba W. Dixon G. Zorn S. Booth November 2001 ASCII HTML 28 layer two tunneling protocol authentication

This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. [STANDARDS-TRACK]

draft-ietf-l2tpext-security-08 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3193
RFC3194 The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio A. Durand C. Huitema November 2001 ASCII HTML 7 IPng White Paper

This document provides an update on the "H ratio" defined in RFC 1715. It defines a new ratio which the authors claim is easier to understand. This memo provides information for the Internet community.

draft-durand-huitema-h-density-ratio-01 RFC1715 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3194
RFC3195 Reliable Delivery for syslog D. New M. Rose November 2001 ASCII HTML 36 mappings encryption authentication beep blocks extensible exchange

The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. [STANDARDS-TRACK]

draft-ietf-syslog-reliable-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC3195
RFC3196 Internet Printing Protocol/1.1: Implementor's Guide T. Hastings C. Manros P. Zehler C. Kugler H. Holst November 2001 ASCII HTML 96 IPP client object

This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). This memo provides information for the Internet community.

draft-ietf-ipp-implementers-guide-v11-03 RFC2639 INFORMATIONAL INFORMATIONAL IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3196 10.17487/RFC3196
RFC3197 Applicability Statement for DNS MIB Extensions R. Austein November 2001 ASCII HTML 5 DNS-R-MIB Domain Name System Management Information Base

This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. This memo provides information for the Internet community.

draft-ietf-dnsext-dnsmib-historical-00 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3197
RFC3198 Terminology for Policy-Based Management A. Westerinen J. Schnizlein J. Strassner M. Scherling B. Quinn S. Herzog A. Huynh M. Carlson J. Perry S. Waldbusser November 2001 ASCII HTML 21 glossary network ISDs internet standard documents

This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). This memo provides information for the Internet community.

draft-ietf-policy-terminology-04 INFORMATIONAL INFORMATIONAL IETF ops policy 10.17487/RFC3198
RFC3199 Request for Comments Summary RFC Numbers 3100-3199 S. Ginoza February 2003 ASCII HTML 24 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3199 RFC3200 RFC3201 Definitions of Managed Objects for Circuit to Interface Translation R. Steinberger O. Nicklass January 2002 ASCII HTML 23 mib

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules. [STANDARDS-TRACK]

draft-ietf-frnetmib-frsi-04 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3201
RFC3202 Definitions of Managed Objects for Frame Relay Service Level Definitions R. Steinberger O. Nicklass January 2002 ASCII HTML 64 mib

This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Frame Relay Service Level Definitions. [STANDARDS-TRACK]

draft-ietf-frnetmib-frmrelay-service-06 PROPOSED STANDARD PROPOSED STANDARD IETF int frnetmib 10.17487/RFC3202
RFC3203 DHCP reconfigure extension Y. T'Joens C. Hublet P. De Schrijver December 2001 ASCII HTML 6 dynamic host configuration protocol forcerenew

This document defines extensions to DHCP (Dynamic Host Configuration Protocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). [STANDARDS-TRACK]

draft-ietf-dhc-pv4-reconfigure-06 RFC6704 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3203
RFC3204 MIME media types for ISUP and QSIG Objects E. Zimmerer J. Peterson A. Vemuri L. Ong F. Audet M. Watson M. Zonoun December 2001 ASCII HTML 10 multipart internet mail extensions

This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN. [STANDARDS-TRACK]

draft-ietf-sip-isup-mime-10 RFC3459 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3204 10.17487/RFC3204
RFC3205 On the use of HTTP as a Substrate K. Moore February 2002 ASCII HTML 14 hypertext transfer protocol layering

Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-moore-using-http-01 BCP0056 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy http://www.rfc-editor.org/errata_search.php?rfc=3205 10.17487/RFC3205
RFC3206 The SYS and AUTH POP Response Codes R. Gellens February 2002 ASCII HTML 6 security authentication

This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. [STANDARDS-TRACK]

draft-gellens-pop-err-01 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3206
RFC3207 SMTP Service Extension for Secure SMTP over Transport Layer Security P. Hoffman February 2002 ASCII HTML 9 simple mail transfer protocol ssl tls

This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]

draft-hoffman-rfc2487bis-06 RFC2487 RFC7817 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3207 10.17487/RFC3207
RFC3208 PGM Reliable Transport Protocol Specification T. Speakman J. Crowcroft J. Gemmell D. Farinacci S. Lin D. Leshchiner M. Luby T. Montgomery L. Rizzo A. Tweedly N. Bhaskar R. Edmonstone R. Sumanasekera L. Vicisano December 2001 ASCII HTML 111 pragmatic general multicast

Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. This memo defines an Experimental Protocol for the Internet community.

draft-speakman-pgm-spec-07 EXPERIMENTAL EXPERIMENTAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3208 10.17487/RFC3208
RFC3209 RSVP-TE: Extensions to RSVP for LSP Tunnels D. Awduche L. Berger D. Gan T. Li V. Srinivasan G. Swallow December 2001 ASCII HTML 61 resource reservation protocol label switched paths

This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-lsp-tunnel-09 RFC3936 RFC4420 RFC4874 RFC5151 RFC5420 RFC5711 RFC6780 RFC6790 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3209 10.17487/RFC3209
RFC3210 Applicability Statement for Extensions to RSVP for LSP-Tunnels D. Awduche A. Hannan X. Xiao December 2001 ASCII HTML 8 resource reservation protocol label switched paths

This memo discusses the applicability of "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. This memo provides information for the Internet community.

draft-ietf-mpls-rsvp-tunnel-applicability-02 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3210
RFC3211 Password-based Encryption for CMS P. Gutmann December 2001 ASCII HTML 17 cryptographic message syntax S/MIME key wrap derivation passwordrecipientinfo PWRI

This document provides a method of encrypting data using user-supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption. [STANDARDS-TRACK]

draft-ietf-smime-password-06 RFC3369 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3211
RFC3212 Constraint-Based LSP Setup using LDP B. Jamoussi Editor L. Andersson R. Callon R. Dantu L. Wu P. Doolan T. Worster N. Feldman A. Fredette M. Girish E. Gray J. Heinanen T. Kilty A. Malis January 2002 ASCII HTML 42 label switching protocol distribution CR

This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). [STANDARDS-TRACK]

draft-ietf-mpls-cr-ldp-06 RFC3468 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3212
RFC3213 Applicability Statement for CR-LDP J. Ash M. Girish E. Gray B. Jamoussi G. Wright January 2002 ASCII HTML 7 constraint-based label distribution protocol

This document discusses the applicability of Constraint-Based LSP Setup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. This memo provides information for the Internet community.

draft-ietf-mpls-crldp-applic-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3213
RFC3214 LSP Modification Using CR-LDP J. Ash Y. Lee P. Ashwood-Smith B. Jamoussi D. Fedyk D. Skalecki L. Li January 2002 ASCII HTML 11 label switching protocol constraint-based distribution

This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-based Routed Label Switched Paths) using CR-LDP (Constraint-based Routed Label Distribution Protocol) without service interruption. [STANDARDS-TRACK]

draft-ietf-mpls-crlsp-modify-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3214
RFC3215 LDP State Machine C. Boscher P. Cheval L. Wu E. Gray January 2002 ASCII HTML 78 label distribution protocol

This document provides state machine tables for ATM (Asynchronous Transfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-state-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3215
RFC3216 SMIng Objectives C. Elliott D. Harrington J. Jason J. Schoenwaelder F. Strauss W. Weiss December 2001 ASCII HTML 33 SNMP simple network management protocol COPS-PR common open policy service provisioning

This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations. This memo provides information for the Internet community.

draft-ietf-sming-reqs-06 INFORMATIONAL INFORMATIONAL IETF ops sming 10.17487/RFC3216
RFC3217 Triple-DES and RC2 Key Wrapping R. Housley December 2001 ASCII HTML 9 algorithm data encryption standard

This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. This memo provides information for the Internet community.

draft-ietf-smime-key-wrap-01 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3217 10.17487/RFC3217
RFC3218 Preventing the Million Message Attack on Cryptographic Message Syntax E. Rescorla January 2002 ASCII HTML 7 cryptographic syntax

This memo describes a strategy for resisting the Million Message Attack. This memo provides information for the Internet community.

draft-ietf-smime-pkcs1-01 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3218 10.17487/RFC3218
RFC3219 Telephony Routing over IP (TRIP) J. Rosenberg H. Salama M. Squire January 2002 ASCII HTML 79 inter-administrative BGP border gateway protocol

This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. [STANDARDS-TRACK]

draft-ietf-iptel-trip-09 RFC8602 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3219 10.17487/RFC3219
RFC3220 IP Mobility Support for IPv4 C. Perkins Editor January 2002 ASCII HTML 98 MOBILEIPSUPIP Internet Protocol

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

draft-ietf-mobileip-rfc2002-bis-08 RFC2002 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3220 10.17487/RFC3220
RFC3221 Commentary on Inter-Domain Routing in the Internet G. Huston December 2001 ASCII HTML 25 BGP border gateway protocol

This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined. This memo provides information for the Internet community.

draft-iab-bgparch-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3221
RFC3222 Terminology for Forwarding Information Base (FIB) based Router Performance G. Trotter December 2001 ASCII HTML 15 internet protocol routing table benchmark

This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. This memo provides information for the Internet community.

draft-ietf-bmwg-fib-term-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3222
RFC3223 RFC3224 Vendor Extensions for Service Location Protocol, Version 2 E. Guttman January 2002 ASCII HTML 10 SLP SVRLOC opaque

This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol." [STANDARDS-TRACK]

RFC2608 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3224 10.17487/RFC3224
RFC3225 Indicating Resolver Support of DNSSEC D. Conrad December 2001 ASCII HTML 6 domain name system security extensions

In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-okbit-02 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3225
RFC3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements O. Gudmundsson December 2001 ASCII HTML 6 domain name space security extensions dns endso

This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC 2535 and RFC 2874, by adding new requirements. [STANDARDS-TRACK]

draft-ietf-dnsext-message-size-04 RFC2535 RFC2874 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3226 10.17487/RFC3226
RFC3227 Guidelines for Evidence Collection and Archiving D. Brezinski T. Killalea February 2002 ASCII HTML 10 security incident

A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grip-prot-evidence-05 BCP0055 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grip 10.17487/RFC3227
RFC3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP) B. Fenner February 2002 ASCII HTML 4 assigned numbers authority

This memo requests that the IANA create a registry for fields in the IGMP (Internet Group Management Protocol) protocol header, and provides guidance for the IANA to use in assigning parameters for those fields. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-magma-igmp-iana-01 BCP0057 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int magma 10.17487/RFC3228
RFC3229 Delta encoding in HTTP J. Mogul B. Krishnamurthy F. Douglis A. Feldmann Y. Goland A. van Hoff D. Hellerstein January 2002 ASCII HTML 49 hyper text transfer protocol

This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. [STANDARDS-TRACK]

draft-mogul-http-delta-10 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3229
RFC3230 Instance Digests in HTTP J. Mogul A. Van Hoff January 2002 ASCII HTML 13 hyper text transfer protocol

HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. [STANDARDS-TRACK]

draft-mogul-http-digest-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3230
RFC3231 Definitions of Managed Objects for Scheduling Management Operations D. Levi J. Schoenwaelder January 2002 ASCII HTML 29 mib information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. [STANDARDS-TRACK]

draft-ietf-disman-schedule-mib-v2-04 RFC2591 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3231
RFC3232 Assigned Numbers: RFC 1700 is Replaced by an On-line Database J. Reynolds Editor January 2002 ASCII HTML 3 IANA internet assigned numbers authority parameters

This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. This memo provides information for the Internet community.

RFC1700 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3232
RFC3233 Defining the IETF P. Hoffman S. Bradner February 2002 ASCII HTML 4 internet engineering task force

This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hoffman-what-is-ietf-05 BCP0058 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3233
RFC3234 Middleboxes: Taxonomy and Issues B. Carpenter S. Brim February 2002 ASCII HTML 27 internet protocol router data path host

This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.

draft-carpenter-midtax-03 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3234
RFC3235 Network Address Translator (NAT)-Friendly Application Design Guidelines D. Senie January 2002 ASCII HTML 13 NAPT ALG firewall

This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). This memo provides information for the Internet community.

draft-ietf-nat-app-guide-07 INFORMATIONAL INFORMATIONAL IETF tsv nat 10.17487/RFC3235
RFC3236 The 'application/xhtml+xml' Media Type M. Baker P. Stark January 2002 ASCII HTML 8 mime multipurpose internet mail extensions

This document defines the 'application/xhtml+xml' MIME media type for XHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers 'text/html'. This memo provides information for the Internet community.

draft-baker-xhtml-media-reg-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3236
RFC3237 Requirements for Reliable Server Pooling M. Tuexen Q. Xie R. Stewart M. Shore L. Ong J. Loughney M. Stillman January 2002 ASCII HTML 10 rserpool application

This document defines a basic set of requirements for reliable server pooling. This memo provides information for the Internet community.

draft-ietf-rserpool-reqts-03 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC3237
RFC3238 IAB Architectural and Policy Considerations for Open Pluggable Edge Services S. Floyd L. Daigle January 2002 ASCII HTML 17 OPES internet architecture board

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of Open Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. This memo provides information for the Internet community.

draft-iab-opes-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3238
RFC3239 Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations C. Kugler H. Lewis T. Hastings February 2002 ASCII HTML 15 object device

This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet Printing Protocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device. This memo provides information for the Internet community.

draft-ietf-ipp-ops-admin-req-01 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3239
RFC3240 Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration D. Clunie E. Cordonnier February 2002 ASCII HTML 6 multipurpose internet mail extensions

This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine). The baseline encoding is defined by the DICOM Standards Committee in "Digital Imaging and Communications in Medicine". This memo provides information for the Internet community.

draft-dicom-media-type-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3240 10.17487/RFC3240
RFC3241 Robust Header Compression (ROHC) over PPP C. Bormann April 2002 ASCII HTML 12 point-to-point protocol datagram packets

This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point- to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6. [STANDARDS-TRACK]

draft-ietf-rohc-over-ppp-04 RFC1332 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3241
RFC3242 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier April 2002 ASCII HTML 21 internet protocol user datagram real-time application transport

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-lla-03 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3242
RFC3243 RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression L-E. Jonsson April 2002 ASCII HTML 6 internet protocol user datagram real-time application transport applications LLA link-layer assisted

This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.

draft-ietf-rohc-rtp-0-byte-requirements-02 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3243
RFC3244 Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols M. Swift J. Trostle J. Brezak February 2002 ASCII HTML 7 security message codes

This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. This memo provides information for the Internet community.

draft-trostle-win2k-cat-kerberos-set-passwd-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3244
RFC3245 The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) J. Klensin Editor IAB March 2002 ASCII HTML 10 IAB ARPA

RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.

draft-iab-itu-enum-notes-00 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3245 10.17487/RFC3245
RFC3246 An Expedited Forwarding PHB (Per-Hop Behavior) B. Davie A. Charny J.C.R. Bennet K. Benson J.Y. Le Boudec W. Courtney S. Davari V. Firoiu D. Stiliadis March 2002 ASCII HTML 16 per-hop behavior expedited forwarding differentiated services delay jitter

This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]

draft-ietf-diffserv-rfc2598bis-02 RFC2598 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv 10.17487/RFC3246
RFC3247 Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) A. Charny J. Bennet K. Benson J. Boudec A. Chiu W. Courtney S. Davari V. Firoiu C. Kalmanek K. Ramakrishnan March 2002 ASCII HTML 24 differentiated services fifo fair queuing delay jitter

This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. This memo provides information for the Internet community.

draft-ietf-diffserv-ef-supplemental-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3247 10.17487/RFC3247
RFC3248 A Delay Bound alternative revision of RFC 2598 G. Armitage B. Carpenter A. Casati J. Crowcroft J. Halpern B. Kumar J. Schnizlein March 2002 ASCII HTML 11 per hop behavior phb expedited forwarding ef db

For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At the Pittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in the DiffServ group. At the San Diego IETF meeting in December 2000 the DiffServ working group decided to pursue an alternative re-expression of the EF PHB. This memo provides information for the Internet community.

draft-ietf-diffserv-efresolve-01 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3248
RFC3249 Implementers Guide for Facsimile Using Internet Mail V. Cancio M. Moldovan H. Tamura D. Wing September 2002 ASCII HTML 21 fax tiff tiff-fx ifax e-mail email esmtp dsn mdn

This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. This memo provides information for the Internet community.

draft-ietf-fax-implementers-guide-07 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC3249
RFC3250 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty September 2002 ASCII HTML 7 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

draft-ietf-fax-tiff-fx-reg-01 RFC3950 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3250
RFC3251 Electricity over IP B. Rajagopalan April 1 2002 ASCII HTML 9 Internet Protocol

Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This memo provides information for the Internet community.

draft-bala-mplamps-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3251
RFC3252 Binary Lexical Octet Ad-hoc Transport H. Kennedy April 1 2002 ASCII HTML 16 bloat

This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3252
RFC3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning) G. Clemm J. Amsden T. Ellison C. Kaler J. Whitehead March 2002 ASCII HTML 118 hypertext transfer protocol clients label configuration management

This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. [STANDARDS-TRACK]

draft-ietf-deltav-versioning-20 PROPOSED STANDARD PROPOSED STANDARD IETF app deltav http://www.rfc-editor.org/errata_search.php?rfc=3253 10.17487/RFC3253
RFC3254 Definitions for talking about directories H. Alvestrand April 2002 ASCII HTML 11 domain name system lightweight access protocol

When discussing systems for making information accessible through the Internet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use. For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability. This document discusses one group of such systems which is known under the term, "directories". This memo provides information for the Internet community.

draft-alvestrand-directory-defs-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3254
RFC3255 Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads N. Jones C. Murton April 2002 ASCII HTML 8

This document describes an extension to the mapping of Point-to-Point Protocol (PPP) into Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads. [STANDARDS-TRACK]

draft-ietf-pppext-posvcholo-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3255
RFC3256 The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option D. Jones R. Woundy April 2002 ASCII HTML 5

This document proposes a new sub-option to the DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Option. [STANDARDS-TRACK]

draft-ietf-dhc-agentoptions-device-class-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3256
RFC3257 Stream Control Transmission Protocol Applicability Statement L. Coene April 2002 ASCII HTML 13 sctp udp tcp rtp transport security transport nat multihoming

This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. This memo provides information for the Internet community.

draft-ietf-sigtran-sctp-applicability-08 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC3257
RFC3258 Distributing Authoritative Name Servers via Shared Unicast Addresses T. Hardie April 2002 ASCII HTML 11 dns network topology latency

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under- served areas of the network topology and to reduce the latency for DNS query responses in those areas. This memo provides information for the Internet community.

draft-ietf-dnsop-hardie-shared-root-server-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC3258
RFC3259 A Message Bus for Local Coordination J. Ott C. Perkins D. Kutscher April 2002 ASCII HTML 39 mbus message ip multicast addressing transport syntax

The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. This memo provides information for the Internet community.

draft-ietf-mmusic-mbus-transport-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC3259
RFC3260 New Terminology and Clarifications for Diffserv D. Grossman April 2002 ASCII HTML 10 DIFFSRV scalability IP internet protocol

This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. This memo provides information for the Internet community.

draft-ietf-diffserv-new-terms-08 RFC2474 RFC2475 RFC2597 INFORMATIONAL INFORMATIONAL IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3260 10.17487/RFC3260
RFC3261 SIP: Session Initiation Protocol J. Rosenberg H. Schulzrinne G. Camarillo A. Johnston J. Peterson R. Sparks M. Handley E. Schooler June 2002 ASCII HTML 269 SIP application-layer application layer multimedia multicast unicast

This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]

draft-ietf-sip-rfc2543bis-09 RFC2543 RFC3265 RFC3853 RFC4320 RFC4916 RFC5393 RFC5621 RFC5626 RFC5630 RFC5922 RFC5954 RFC6026 RFC6141 RFC6665 RFC6878 RFC7462 RFC7463 RFC8217 RFC8591 RFC8760 RFC8898 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3261 10.17487/RFC3261
RFC3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne June 2002 ASCII HTML 14 SIP application-layer application layer multimedia multicast unicast

This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK]

draft-ietf-sip-100rel-06 RFC2543 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3262 10.17487/RFC3262
RFC3263 Session Initiation Protocol (SIP): Locating SIP Servers J. Rosenberg H. Schulzrinne June 2002 ASCII HTML 17 SIP application-layer application layer multimedia multicast unicast

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. [STANDARDS-TRACK]

draft-ietf-sip-srv-06 RFC2543 RFC7984 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3263
RFC3264 An Offer/Answer Model with Session Description Protocol (SDP) J. Rosenberg H. Schulzrinne June 2002 ASCII HTML 25 SIP application-layer application layer multimedia multicast unicast

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-offer-answer-02 RFC2543 RFC6157 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3264 10.17487/RFC3264
RFC3265 Session Initiation Protocol (SIP)-Specific Event Notification A. B. Roach June 2002 ASCII HTML 38 SIP application-layer application layer multimedia multicast unicast

This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. [STANDARDS-TRACK]

draft-ietf-sip-events-05 RFC2543 RFC6665 RFC3261 RFC5367 RFC5727 RFC6446 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3265 10.17487/RFC3265
RFC3266 Support for IPv6 in Session Description Protocol (SDP) S. Olson G. Camarillo A. B. Roach June 2002 ASCII HTML 5 internet addresses syntax

This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-ipv6-03 RFC4566 RFC2327 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3266 10.17487/RFC3266
RFC3267 Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie June 2002 ASCII HTML 49 interoperate applications

This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. [STANDARDS-TRACK]

draft-ietf-avt-rtp-amr-13 RFC4867 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3267 10.17487/RFC3267
RFC3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) P. Chown June 2002 ASCII HTML 7 idea international data algorithm symmetric

This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]

draft-ietf-tls-ciphersuite-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3268
RFC3269 Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents R. Kermode L. Vicisano April 2002 ASCII HTML 12 definitions operation

This document provides general guidelines to assist the authors of Reliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. This memo provides information for the Internet community.

draft-ietf-rmt-author-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3269
RFC3270 Multi-Protocol Label Switching (MPLS) Support of Differentiated Services F. Le Faucheur L. Wu B. Davie S. Davari P. Vaananen R. Krishnan P. Cheval J. Heinanen May 2002 ASCII HTML 64 diff-serv ba behaviour aggregate lsp label switched paths

This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. [STANDARDS-TRACK]

draft-ietf-mpls-diff-ext-09 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3270 10.17487/RFC3270
RFC3271 The Internet is for Everyone V. Cerf April 2002 ASCII HTML 6 isoc internet society policy issues social impact economic impact international policy use and abuse of the internet

This document expresses the Internet Society's ideology that the Internet really is for everyone. However, it will only be such if we make it so. This memo provides information for the Internet community.

draft-isoc-internet-for-everyone-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3271 10.17487/RFC3271
RFC3272 Overview and Principles of Internet Traffic Engineering D. Awduche A. Chiu A. Elwalid I. Widjaja X. Xiao May 2002 ASCII HTML 71 te ip networks

This memo describes the principles of Traffic Engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. This memo provides information for the Internet community.

draft-ietf-tewg-principles-02 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg http://www.rfc-editor.org/errata_search.php?rfc=3272 10.17487/RFC3272
RFC3273 Remote Network Monitoring Management Information Base for High Capacity Networks S. Waldbusser July 2002 ASCII HTML 77 rmon mib high speed networks

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021. [PROPOSED STANDARD]

draft-ietf-rmonmib-hcrmon-10 RFC4502 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3273
RFC3274 Compressed Data Content Type for Cryptographic Message Syntax (CMS) P. Gutmann June 2002 ASCII HTML 6 content info type

This document defines a format for using compressed data as a Cryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS). [STANDARDS-TRACK]

draft-ietf-smime-compression-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3274
RFC3275 (Extensible Markup Language) XML-Signature Syntax and Processing D. Eastlake 3rd J. Reagle D. Solo March 2002 ASCII HTML 73 extensible markup language

This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. [STANDARDS-TRACK]

draft-ietf-xmldsig-core-2-03 RFC3075 DRAFT STANDARD DRAFT STANDARD IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3275 10.17487/RFC3275
RFC3276 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing B. Ray R. Abbi May 2002 ASCII HTML 66 mib interfaces

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. [STANDARDS-TRACK]

draft-ietf-adslmib-hdsl2-12 RFC4319 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3276
RFC3277 Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance D. McPherson April 2002 ASCII HTML 6 router

This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. This memo provides information for the Internet community.

draft-ietf-isis-transient-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3277
RFC3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Blake-Wilson D. Brown P. Lambert April 2002 ASCII HTML 16 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard. This memo provides information for the Internet community.

draft-ietf-smime-ecc-06 RFC5753 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC3278
RFC3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile L. Bassham W. Polk R. Housley April 2002 ASCII HTML 27 ASN.1

This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]

draft-ietf-pkix-ipki-pkalgs-05 RFC4055 RFC4491 RFC5480 RFC5758 RFC8692 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3279 10.17487/RFC3279
RFC3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley W. Polk W. Ford D. Solo April 2002 ASCII HTML 129

This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]

draft-ietf-pkix-new-part1-12 RFC2459 RFC5280 RFC4325 RFC4630 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3280 10.17487/RFC3280
RFC3281 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley April 2002 ASCII HTML 40 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. [STANDARDS-TRACK]

draft-ietf-pkix-ac509prof-09 RFC5755 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3281 10.17487/RFC3281
RFC3282 Content Language Headers H. Alvestrand May 2002 ASCII HTML 8

This document defines a "Content-language:" header, for use in cases where one desires to indicate the language of something that has RFC 822-like headers, like MIME body parts or Web documents, and an "Accept-Language:" header for use in cases where one wishes to indicate one's preferences with regard to language. [STANDARDS-TRACK]

draft-alvestrand-content-language-03 RFC1766 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3282
RFC3283 Guide to Internet Calendaring B. Mahoney G. Babics A. Taler June 2002 ASCII HTML 16 scheduling systems cap calendar access protocool itip imip

This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP). The work in progress addressed is "Calendar Access Protocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. This memo provides information for the Internet community.

draft-ietf-calsch-inetcal-guide-02 INFORMATIONAL INFORMATIONAL IETF app calsch 10.17487/RFC3283
RFC3284 The VCDIFF Generic Differencing and Compression Data Format D. Korn J. MacDonald J. Mogul K. Vo June 2002 ASCII HTML 29 transport portable at&t encoding

This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. [STANDARDS-TRACK]

draft-korn-vcdiff-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3284
RFC3285 Using Microsoft Word to create Internet Drafts and RFCs M. Gahrns T. Hain May 2002 ASCII HTML 19

This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. This memo provides information for the Internet community.

draft-hain-msword-template-04 RFC5385 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3285
RFC3286 An Introduction to the Stream Control Transmission Protocol (SCTP) L. Ong J. Yoakum May 2002 ASCII HTML 10 transport layer telephony signaling

This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. This memo provides information for the Internet community.

draft-ong-sigtran-sctpover-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3286
RFC3287 Remote Monitoring MIB Extensions for Differentiated Services A. Bierman July 2002 ASCII HTML 120 rmon management information base diffserv

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring Differentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2 (Remote Network Monitoring Management Version 2) MIB. [STANDARDS-TRACK]

draft-ietf-rmonmib-dsmon-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3287
RFC3288 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose June 2002 ASCII HTML 20 binding markup language xml

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. [STANDARDS-TRACK]

draft-etal-beep-soap-06 RFC4227 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3288
RFC3289 Management Information Base for the Differentiated Services Architecture F. Baker K. Chan A. Smith May 2002 ASCII HTML 116 mib diffserv router architecture

This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS-TRACK]

draft-ietf-diffserv-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv diffserv http://www.rfc-editor.org/errata_search.php?rfc=3289 10.17487/RFC3289
RFC3290 An Informal Management Model for Diffserv Routers Y. Bernet S. Blake D. Grossman A. Smith May 2002 ASCII HTML 56 differentiated services

This document proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. This memo provides information for the Internet community.

draft-ietf-diffserv-model-06 INFORMATIONAL INFORMATIONAL IETF tsv diffserv 10.17487/RFC3290
RFC3291 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder May 2002 ASCII HTML 20 tc mib layer management information base

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ops-rfc2851-update-06 RFC2851 RFC4001 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC3291
RFC3292 General Switch Management Protocol (GSMP) V3 A. Doria F. Hellstrand K. Sundell T. Worster June 2002 ASCII HTML 137 switch label unicast multicast qos quality of service

This document describes the General Switch Management Protocol Version 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch. The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources and QoS features. [STANDARDS-TRACK]

draft-ietf-gsmp-11 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3292
RFC3293 General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP) T. Worster A. Doria J. Buerkle June 2002 ASCII HTML 9

This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol). [STANDARDS-TRACK]

draft-ietf-gsmp-encaps-05 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3293
RFC3294 General Switch Management Protocol (GSMP) Applicability A. Doria K. Sundell June 2002 ASCII HTML 9 internet

This memo provides an overview of the GSMP (General Switch Management Protocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in an ATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. This memo provides information for the Internet community.

draft-ietf-gsmp-applicability-02 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3294
RFC3295 Definitions of Managed Objects for the General Switch Management Protocol (GSMP) H. Sjostrand J. Buerkle B. Srinivasan June 2002 ASCII HTML 47 mib management information base controller gsmp-mib

This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). [STANDARDS-TRACK]

draft-ietf-gsmp-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF subip gsmp 10.17487/RFC3295
RFC3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories K. Zeilenga July 2002 ASCII HTML 14 schema elements description formats

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. [STANDARDS-TRACK]

draft-zeilenga-ldap-namedref-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3296
RFC3297 Content Negotiation for Messaging Services based on Email G. Klyne R. Iwazaki D. Crocker July 2002 ASCII HTML 46 facsimile

This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. [STANDARDS-TRACK]

draft-ietf-fax-content-negotiation-05 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3297 10.17487/RFC3297
RFC3298 Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements I. Faynberg J. Gato H. Lu L. Slutsman August 2002 ASCII HTML 17 support

This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. This memo provides information for the Internet community.

draft-ietf-spirits-reqs-04 INFORMATIONAL INFORMATIONAL IETF tsv spirits 10.17487/RFC3298
RFC3299 Request for Comments Summary RFC Numbers 3200-3299 S. Ginoza December 2003 ASCII HTML 30 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3299 RFC3300 Internet Official Protocol Standards J. Reynolds R. Braden S. Ginoza A. De La Cruz November 2002 ASCII HTML 49 RFC3000 RFC3600 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3300 10.17487/RFC3300 RFC3301 Layer Two Tunnelling Protocol (L2TP): ATM access network extensions Y. T'Joens P. Crivellari B. Sales June 2002 ASCII HTML 19 draft-ietf-l2tpext-atmext-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3301 RFC3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration G. Parsons J. Rafferty September 2002 ASCII HTML 8 TIFF Multipurpose Internet Mail extensions draft-ietf-fax-tiff-regbis-05 RFC2302 DRAFT STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC3302 RFC3303 Middlebox communication architecture and framework P. Srisuresh J. Kuthan J. Rosenberg A. Molitor A. Rayhan August 2002 ASCII HTML 34 midcom draft-ietf-midcom-framework-07 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3303 RFC3304 Middlebox Communications (midcom) Protocol Requirements R. P. Swale P. A. Mart P. Sijben S. Brim M. Shore August 2002 ASCII HTML 9 nat network address protocol firewall middleboxes draft-ietf-midcom-requirements-05 INFORMATIONAL INFORMATIONAL IETF tsv midcom http://www.rfc-editor.org/errata_search.php?rfc=3304 10.17487/RFC3304 RFC3305 Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations M. Mealling Editor R. Denenberg Editor August 2002 ASCII HTML 11 internet engineering task force draft-mealling-uri-ig-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3305 10.17487/RFC3305 RFC3306 Unicast-Prefix-based IPv6 Multicast Addresses B. Haberman D. Thaler August 2002 ASCII HTML 7 internet protocol draft-ietf-ipngwg-uni-based-mcast-03 RFC3956 RFC4489 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3306 RFC3307 Allocation Guidelines for IPv6 Multicast Addresses B. Haberman August 2002 ASCII HTML 8 internet protocol draft-ietf-malloc-ipv6-guide-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3307 RFC3308 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension P. Calhoun W. Luo D. McPherson K. Peirce November 2002 ASCII HTML 10 per hop behavior phb diffserv draft-ietf-l2tpext-ds-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3308 RFC3309 Stream Control Transmission Protocol (SCTP) Checksum Change J. Stone R. Stewart D. Otis September 2002 ASCII HTML 17 adler-32 checksum error detection draft-ietf-tsvwg-sctpcsum-07 RFC4960 RFC2960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3309 RFC3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) A. Niemi J. Arkko V. Torvinen September 2002 ASCII HTML 18 one-time password generation mechanism umts universal mobile telecommunications system draft-ietf-sip-digest-aka-03 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3310 RFC3311 The Session Initiation Protocol (SIP) UPDATE Method J. Rosenberg October 2002 ASCII HTML 13 parameters media streams draft-ietf-sip-update-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3311 RFC3312 Integration of Resource Management and Session Initiation Protocol (SIP) G. Camarillo Editor W. Marshall Editor J. Rosenberg October 2002 ASCII PS PDF HTML 30 qos quality of service precondition draft-ietf-sip-manyfolks-resource-07 RFC4032 RFC5027 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3312 10.17487/RFC3312 RFC3313 Private Session Initiation Protocol (SIP) Extensions for Media Authorization W. Marshall Editor January 2003 ASCII HTML 16 qos quality of service draft-ietf-sip-call-auth-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC3313 RFC3314 Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards M. Wasserman Editor September 2002 ASCII HTML 23 internet protocol draft-ietf-ipv6-3gpp-recommend-02 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3314 10.17487/RFC3314 RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor J. Bound B. Volz T. Lemon C. Perkins M. Carney July 2003 ASCII HTML 101 internet protocol parameters addresses draft-ietf-dhc-dhcpv6-28 RFC8415 RFC4361 RFC5494 RFC6221 RFC6422 RFC6644 RFC7083 RFC7227 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3315 10.17487/RFC3315 RFC3316 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts J. Arkko G. Kuijpers H. Soliman J. Loughney J. Wiljakka April 2003 ASCII HTML 22 links bandwidth draft-ietf-ipv6-cellular-host-03 RFC7066 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3316 RFC3317 Differentiated Services Quality of Service Policy Information Base K. Chan R. Sahita S. Hahn K. McCloghrie March 2003 ASCII HTML 96 pib differentiated services architecture draft-ietf-diffserv-pib-08 HISTORIC INFORMATIONAL IETF tsv diffserv 10.17487/RFC3317 RFC3318 Framework Policy Information Base R. Sahita Editor S. Hahn K. Chan K. McCloghrie March 2003 ASCII HTML 70

This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning.

Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB).

One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security.

As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each.

draft-ietf-rap-frameworkpib-09 HISTORIC INFORMATIONAL IETF ops rap 10.17487/RFC3318
RFC3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers H. Schulzrinne B. Volz July 2003 ASCII HTML 7 outbound proxy servers draft-ietf-sip-dhcpv6-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3319 RFC3320 Signaling Compression (SigComp) R. Price C. Bormann J. Christoffersson H. Hannu Z. Liu J. Rosenberg January 2003 ASCII HTML 62 sip session initiation protocol udvm universal decompressor virtual machine draft-ietf-rohc-sigcomp-07 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3320 RFC3321 Signaling Compression (SigComp) - Extended Operations H. Hannu J. Christoffersson S. Forsgren K.-C. Leung Z. Liu R. Price January 2003 ASCII HTML 19 sip session initiation protocol udvm universal decompressor virtual machine draft-ietf-rohc-sigcomp-extended-04 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3321 RFC3322 Signaling Compression (SigComp) Requirements & Assumptions H. Hannu January 2003 ASCII HTML 13 sip session initiation protocol wireless cellular sdp session description protocol draft-ietf-rohc-signaling-req-assump-06 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3322 RFC3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) J. Peterson November 2002 ASCII HTML 22 privacy service draft-ietf-sip-privacy-general-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3323 10.17487/RFC3323 RFC3324 Short Term Requirements for Network Asserted Identity M. Watson November 2002 ASCII HTML 11 session initiation protocol sip ua user agent draft-ietf-sipping-nai-reqs-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3324 RFC3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks C. Jennings J. Peterson M. Watson November 2002 ASCII HTML 18 trust domain draft-ietf-sip-asserted-identity-01 RFC5876 RFC8217 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3325 10.17487/RFC3325 RFC3326 The Reason Header Field for the Session Initiation Protocol (SIP) H. Schulzrinne D. Oran G. Camarillo December 2002 ASCII HTML 8 heterogeneous error response forking problem herfp

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism. [STANDARDS-TRACK]

draft-ietf-sip-reason-01 RFC8606 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3326
RFC3327 Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts D. Willis B. Hoeneisen December 2002 ASCII HTML 17 3gpp register contact path registrar user agent ua draft-willis-sip-path-08 RFC5626 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3327 10.17487/RFC3327 RFC3328 RFC3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP) J. Arkko V. Torvinen G. Camarillo A. Niemi T. Haukka January 2003 ASCII HTML 24 ua user agent draft-ietf-sip-sec-agree-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3329 10.17487/RFC3329 RFC3330 Special-Use IPv4 Addresses IANA September 2002 ASCII HTML 7 internet protocol space assignments draft-iana-special-ipv4-05 RFC5735 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3330 10.17487/RFC3330 RFC3331 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer K. Morneault R. Dantu G. Sidebottom B. Bidulock J. Heitz September 2002 ASCII HTML 94 sctp stream control transmission protocol sg signaling gateway media gateway controller mgc draft-ietf-sigtran-m2ua-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=3331 10.17487/RFC3331 RFC3332 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) G. Sidebottom Editor K. Morneault Editor J. Pastor-Balbas Editor September 2002 ASCII HTML 120 isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway draft-ietf-sigtran-m3ua-12 RFC4666 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3332 RFC3333 RFC3334 Policy-Based Accounting T. Zseby S. Zander C. Carle October 2002 ASCII HTML 44 measurement metering meter configuration qos auditing aaa aaa architecture inter-domain accounting draft-irtf-aaaarch-pol-acct-05 EXPERIMENTAL EXPERIMENTAL Legacy 10.17487/RFC3334 RFC3335 MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Drummond C. Shih September 2002 ASCII HTML 29 multipurpose internet mail extensions edi draft-ietf-ediint-as1-17 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint 10.17487/RFC3335 RFC3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) B. Thompson T. Koren B. Buffam December 2002 ASCII HTML 16 point-to-point protocol atm aal2 datagram packets draft-ietf-pppext-ppp-over-aal2-03 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3336 RFC3337 Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 B. Thompson T. Koren B. Buffam December 2002 ASCII HTML 7 point-to-point protocol atm aal2 encapsulation draft-ietf-pppext-ppp-over-aal2-class-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3337 RFC3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA) S. Lee M-K. Shin Y-J. Kim E. Nordmark A. Durand October 2002 ASCII HTML 17 draft-ietf-ngtrans-bia-05 RFC6535 EXPERIMENTAL EXPERIMENTAL IETF ops ngtrans 10.17487/RFC3338 RFC3339 Date and Time on the Internet: Timestamps G. Klyne C. Newman July 2002 ASCII HTML 18 gregorian calendar iso

This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

draft-ietf-impp-datetime-05 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3339 10.17487/RFC3339
RFC3340 The Application Exchange Core M. Rose G. Klyne D. Crocker July 2002 ASCII HTML 40 APEX draft-ietf-apex-core-06 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3340 RFC3341 The Application Exchange (APEX) Access Service M. Rose G. Klyne D. Crocker July 2002 ASCII HTML 26 APEX draft-ietf-apex-access-08 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3341 RFC3342 The Application Exchange (APEX) Option Party Pack, Part Deux! E. Dixon H. Franklin J. Kint G. Klyne D. New S. Pead M. Rose M. Schwartz July 2002 ASCII HTML 22 datagram service core relaying mesh draft-ietf-apex-party-04 HISTORIC PROPOSED STANDARD IETF app apex 10.17487/RFC3342 RFC3343 The Application Exchange (APEX) Presence Service M. Rose G. Klyne D. Crocker April 2003 ASCII HTML 23 endpoint draft-ietf-apex-presence-06 HISTORIC EXPERIMENTAL IETF app apex 10.17487/RFC3343 RFC3344 IP Mobility Support for IPv4 C. Perkins Editor August 2002 ASCII HTML 99 MOBILEIPSUPIP Internet Protocol RFC3220 RFC5944 RFC4636 RFC4721 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3344 10.17487/RFC3344 RFC3345 Border Gateway Protocol (BGP) Persistent Route Oscillation Condition D. McPherson V. Gill D. Walton A. Retana August 2002 ASCII HTML 19 idr ibgp draft-ietf-idr-route-oscillation-01 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=3345 10.17487/RFC3345 RFC3346 Applicability Statement for Traffic Engineering with MPLS J. Boyle V. Gill A. Hannan D. Cooper D. Awduche B. Christian W.S. Lai August 2002 ASCII HTML 14 multiprotocol label switching te draft-ietf-tewg-te-applicability-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3346 RFC3347 Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations M. Krueger R. Haagens July 2002 ASCII HTML 26 scsi tcp. storage fibre channel draft-ietf-ips-iscsi-reqmts-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3347 RFC3348 The Internet Message Action Protocol (IMAP4) Child Mailbox Extension M. Gahrns R. Cheng July 2002 ASCII HTML 6 children draft-gahrns-imap-child-mailbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3348 10.17487/RFC3348 RFC3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force M. Rose July 2002 ASCII HTML 6 beep draft-mrose-beep-transientid-02 BCP0059 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3349 RFC3350 RFC3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals N. Charlton M. Gasson G. Gybels M. Spanner A. van Wijk August 2002 ASCII HTML 17 relay service transcoding service textphone draft-ietf-sipping-deaf-req-03 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3351 RFC3352 Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status K. Zeilenga March 2003 ASCII HTML 4 CLDAP CLDAP Presentation Address Application Entity Title draft-zeilenga-cldap-02 RFC1798 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3352 RFC3353 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment D. Ooms B. Sales W. Livens A. Acharya F. Griffoul F. Ansari August 2002 ASCII HTML 30 inrternet protocol l2 multicast routing protocoln draft-ietf-mpls-multicast-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3353 RFC3354 Internet Open Trading Protocol Version 2 Requirements D. Eastlake 3rd August 2002 ASCII HTML 6 payment ecommerce merchant customer delivery signature messaging commerce sale draft-ietf-trade-iotp2-req-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3354 RFC3355 Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) A. Singh R. Turner R. Tio S. Nanji August 2002 ASCII HTML 13 link dial-up server asynchronous transfer mode draft-ietf-l2tpext-l2tp-atm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3355 RFC3356 Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines G. Fishman S. Bradner August 2002 ASCII HTML 12 internet society engineering task force draft-fishman-2436bis-02 RFC2436 RFC6756 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3356 RFC3357 One-way Loss Pattern Sample Metrics R. Koodli R. Ravikanth August 2002 ASCII HTML 15 packets voice video stream draft-ietf-ippm-loss-pattern-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3357 RFC3358 Optional Checksums in Intermediate System to Intermediate System (ISIS) T. Przygienda August 2002 ASCII HTML 4 type length value complete sequence number partial data draft-ietf-isis-wg-snp-checksum-03 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3358 RFC3359 Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System T. Przygienda August 2002 ASCII HTML 5 is-is igp osi complete sequence number partial data draft-ietf-isis-wg-tlv-codepoints-01 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=3359 10.17487/RFC3359 RFC3360 Inappropriate TCP Resets Considered Harmful S. Floyd August 2002 ASCII HTML 19 transmission control protocol rst bit connection draft-floyd-tcp-reset-04 BCP0060 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3360 RFC3361 Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers H. Schulzrinne August 2002 ASCII HTML 7 proxy servers draft-ietf-sip-dhcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3361 RFC3362 Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration G. Parsons August 2002 ASCII HTML 5 draft-parsons-itu-t38-reg-00 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3362 RFC3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) R. Bush A. Durand B. Fink O. Gudmundsson T. Hain August 2002 ASCII HTML 6 reverse mapping label binary draft-ietf-dnsext-ipv6-addresses-02 RFC2673 RFC2874 RFC6672 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3363 10.17487/RFC3363 RFC3364 Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) R. Austein August 2002 ASCII HTML 11 reverse mapping rrs resource records draft-ietf-dnsext-ipv6-dns-tradeoffs-02 RFC2673 RFC2874 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3364 10.17487/RFC3364 RFC3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols J. Schiller August 2002 ASCII HTML 8 ietf draft-ietf-saag-whyenc-00 BCP0061 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3365 RFC3366 Advice to link designers on link Automatic Repeat reQuest (ARQ) G. Fairhurst L. Wood August 2002 ASCII HTML 27 tcp/ip subnetworks draft-ietf-pilc-link-arq-issues-04 BCP0062 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3366 RFC3367 Common Name Resolution Protocol (CNRP) N. Popp M. Mealling M. Moseley August 2002 ASCII HTML 42 unique resource locators client applications draft-ietf-cnrp-12 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3367 RFC3368 The 'go' URI Scheme for the Common Name Resolution Protocol M. Mealling August 2002 ASCII HTML 8 uniform resource identifier draft-ietf-cnrp-uri-07 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3368 RFC3369 Cryptographic Message Syntax (CMS) R. Housley August 2002 ASCII HTML 52 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-rfc2630bis-08 RFC2630 RFC3211 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3369 10.17487/RFC3369 RFC3370 Cryptographic Message Syntax (CMS) Algorithms R. Housley August 2002 ASCII HTML 24 digitally sign authenticate encrypt arbitrary message content draft-ietf-smime-cmsalg-08 RFC2630 RFC3211 RFC5754 RFC8702 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3370 10.17487/RFC3370 RFC3371 Layer Two Tunneling Protocol "L2TP" Management Information Base E. Caves P. Calhoun R. Wheeler August 2002 ASCII HTML 70 mib draft-ietf-l2tpext-l2tp-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3371 RFC3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures A. Vemuri J. Peterson September 2002 ASCII HTML 23 pstn public switch telephone network draft-ietf-sipping-sipt-04 BCP0063 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3372 10.17487/RFC3372 RFC3373 Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies D. Katz R. Saluja September 2002 ASCII HTML 9 links handshake draft-ietf-isis-3way-06 RFC5303 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3373 RFC3374 Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network J. Kempf Editor September 2002 ASCII HTML 14 aaa qos authentication authorization accounting quality of service header compression draft-ietf-seamoby-context-transfer-problem-stat-04 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3374 RFC3375 Generic Registry-Registrar Protocol Requirements S. Hollenbeck September 2002 ASCII HTML 21 rrp client server domain names draft-ietf-provreg-grrp-reqs-06 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3375 RFC3376 Internet Group Management Protocol, Version 3 B. Cain S. Deering I. Kouvelas B. Fenner A. Thyagarajan October 2002 ASCII HTML 53 IGMP IGMP multicast routing IP Internet Protocol draft-ietf-idmr-igmp-v3-11 RFC2236 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idmr http://www.rfc-editor.org/errata_search.php?rfc=3376 10.17487/RFC3376 RFC3377 Lightweight Directory Access Protocol (v3): Technical Specification J. Hodges R. Morgan September 2002 ASCII HTML 6 ldap ldapv3 draft-ietf-ldapbis-ldapv3-ts-01 RFC4510 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=3377 10.17487/RFC3377 RFC3378 EtherIP: Tunneling Ethernet Frames in IP Datagrams R. Housley S. Hollenbeck September 2002 ASCII HTML 9 internet protocol ip 97 draft-housley-etherip-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3378 RFC3379 Delegated Path Validation and Delegated Path Discovery Protocol Requirements D. Pinkas R. Housley September 2002 ASCII HTML 15 dpv dpd public key certificates draft-ietf-pkix-dpv-dpd-req-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3379 RFC3380 Internet Printing Protocol (IPP): Job and Printer Set Operations T. Hastings R. Herriot C. Kugler H. Lewis September 2002 ASCII HTML 59 IPP-E-T IPP application media-type media type draft-ietf-ipp-job-printer-set-ops-05 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3380 10.17487/RFC3380 RFC3381 Internet Printing Protocol (IPP): Job Progress Attributes T. Hastings H. Lewis R. Bergman September 2002 ASCII HTML 17 IPP-E-T IPP application media-type media type draft-ietf-ipp-job-prog-02 RFC8011 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3381 10.17487/RFC3381 RFC3382 Internet Printing Protocol (IPP): The 'collection' attribute syntax R. deBry T. Hastings R. Herriot K. Ocke P. Zehler September 2002 ASCII HTML 38 IPP-E-T IPP application media-type media type draft-ietf-ipp-collection-05 RFC8010 RFC8011 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3382 10.17487/RFC3382 RFC3383 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga September 2002 ASCII HTML 23 guidelines extensible values draft-ietf-ldapbis-iana-09 RFC4520 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC3383 RFC3384 Lightweight Directory Access Protocol (version 3) Replication Requirements E. Stokes R. Weiser R. Moats R. Huber October 2002 ASCII HTML 31 ldapv3 data interoperability synchronization multi-master draft-ietf-ldup-replica-req-12 INFORMATIONAL INFORMATIONAL IETF app ldup 10.17487/RFC3384 RFC3385 Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations D. Sheinwald J. Satran P. Thaler V. Cavanna September 2002 ASCII HTML 23 error detection code draft-sheinwald-iscsi-crc-02 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3385 10.17487/RFC3385 RFC3386 Network Hierarchy and Multilayer Survivability W. Lai Editor D. McDysan Editor November 2002 ASCII HTML 27 service provider packet networks protection restoration recovery draft-ietf-tewg-restore-hierarchy-01 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3386 RFC3387 Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network M. Eder H. Chaskar S. Nag September 2002 ASCII HTML 19 internet protocol packts fuel-service draft-irtf-smrg-ipsmf-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3387 RFC3388 Grouping of Media Lines in the Session Description Protocol (SDP) G. Camarillo G. Eriksson J. Holler H. Schulzrinne December 2002 ASCII HTML 11 formats attribute port host interfaces fid flow identification lip synchronization ls draft-ietf-mmusic-fid-06 RFC5888 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3388 RFC3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) R. Zopf September 2002 ASCII HTML 8 codecs audio multimedia draft-ietf-avt-rtp-cn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3389 10.17487/RFC3389 RFC3390 Increasing TCP's Initial Window M. Allman S. Floyd C. Partridge October 2002 ASCII HTML 15 transmission control protocol draft-ietf-tsvwg-initwin-04 RFC2414 RFC2581 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3390 10.17487/RFC3390 RFC3391 The MIME Application/Vnd.pwg-multiplexed Content-Type R. Herriot December 2002 ASCII HTML 25 multipurpose internet mail extensions media type draft-herriot-application-multiplexed-05 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3391 RFC3392 Capabilities Advertisement with BGP-4 R. Chandra J. Scudder November 2002 ASCII HTML 6 border gateway protocol draft-ietf-idr-rfc2842bis-02 RFC2842 RFC5492 DRAFT STANDARD DRAFT STANDARD IETF rtg idr 10.17487/RFC3392 RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) C. Demichelis P. Chimento November 2002 ASCII HTML 21 internet protocol ipdv draft-ietf-ippm-ipdv-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3393 RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm J. Schaad R. Housley September 2002 ASCII HTML 41 security draft-ietf-smime-aes-keywrap-00 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3394 10.17487/RFC3394 RFC3395 Remote Network Monitoring MIB Protocol Identifier Reference Extensions A. Bierman C. Bucci R. Dietz A. Warth September 2002 ASCII HTML 21 RMON-MIB management information base draft-ietf-rmonmib-appverbs-04 RFC2895 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3395 RFC3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) T. Lemon S. Cheshire November 2002 ASCII HTML 9 octet packet code draft-ietf-dhc-concat-05 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3396 RFC3397 Dynamic Host Configuration Protocol (DHCP) Domain Search Option B. Aboba S. Cheshire November 2002 ASCII HTML 8 dns client client server draft-aboba-dhc-domsearch-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3397 RFC3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping G. Camarillo A. B. Roach J. Peterson L. Ong December 2002 ASCII HTML 68 signaling system no. 7 ss7 pstn public switched telephone network draft-ietf-sipping-isup-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3398 10.17487/RFC3398 RFC3399 RFC3400 RFC3401 Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS M. Mealling October 2002 ASCII HTML 6 NAPTR domain name system RR

This document specifies the exact documents that make up the complete Dynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC 2168 and RFC 2915, as well as updates RFC 2276. This memo provides information for the Internet community.

draft-ietf-urn-ddds-toc-03 RFC2915 RFC2168 RFC2276 INFORMATIONAL INFORMATIONAL IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3401 10.17487/RFC3401
RFC3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm M. Mealling October 2002 ASCII HTML 17 NAPTR domain name system RR

This document describes the Dynamic Delegation Discovery System (DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

draft-ietf-urn-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn 10.17487/RFC3402
RFC3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database M. Mealling October 2002 ASCII HTML 14 NAPTR domain name system RR

This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

draft-ietf-urn-dns-ddds-database-09 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3403 10.17487/RFC3403
RFC3404 Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) M. Mealling October 2002 ASCII HTML 18 NAPTR domain name system RR

This document describes a specification for taking Uniform Resource Identifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK]

draft-ietf-urn-uri-res-ddds-07 RFC2915 RFC2168 PROPOSED STANDARD PROPOSED STANDARD IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3404 10.17487/RFC3404
RFC3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures M. Mealling October 2002 ASCII HTML 10 uniform resource identifiers

This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urn-net-procedures-11 BCP0065 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3405 10.17487/RFC3405
RFC3406 Uniform Resource Names (URN) Namespace Definition Mechanisms L. Daigle D. van Gulik R. Iannella P. Faltstrom October 2002 ASCII HTML 22 namespaces applications structure

This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-urn-rfc2611bis-04 RFC2611 RFC8141 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app urn http://www.rfc-editor.org/errata_search.php?rfc=3406 10.17487/RFC3406
RFC3407 Session Description Protocol (SDP) Simple Capability Declaration F. Andreasen October 2002 ASCII HTML 10 SDPng

This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng. [STANDARDS-TRACK]

draft-andreasen-mmusic-sdp-simcap-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3407 10.17487/RFC3407
RFC3408 Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile Z. Liu K. Le December 2002 ASCII HTML 7 single-octet packet size

This document defines an additional mode of the link-layer assisted RObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHC Bidirectional Reliable mode (R-mode) to the ones specified for Unidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-lla-r-mode-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3408
RFC3409 Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression K. Svanbro December 2002 ASCII HTML 11 rohc algorithms

This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. This memo provides information for the Internet community.

draft-ietf-rohc-rtp-lower-layer-guidelines-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3409
RFC3410 Introduction and Applicability Statements for Internet-Standard Management Framework J. Case R. Mundy D. Partain B. Stewart December 2002 ASCII HTML 27 snmp simple protocol snmpv3

The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2). The architecture is designed to be modular to allow the evolution of the Framework over time. The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. This memo provides information for the Internet community.

draft-ietf-snmpv3-rfc2570bis-03 RFC2570 INFORMATIONAL INFORMATIONAL IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3410 10.17487/RFC3410
RFC3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks D. Harrington R. Presuhn B. Wijnen December 2002 ASCII HTML 64 ARCH-SNMP simple protocol network management

This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]

draft-ietf-snmpv3-arch-v2-02 RFC2571 RFC5343 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3411
RFC3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) J. Case D. Harrington R. Presuhn B. Wijnen December 2002 ASCII HTML 43 MPD-SNMP processing models multiple

This document describes the Message Processing and Dispatching for Simple Network Management Protocol (SNMP) messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model. This document obsoletes RFC 2572. [STANDARDS-TRACK]

draft-ietf-snmpv3-mpd-v2-02 RFC2572 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3412
RFC3413 Simple Network Management Protocol (SNMP) Applications D. Levi P. Meyer B. Stewart December 2002 ASCII HTML 74 SNMP-APP simple network management protocol proxy operations command

This document describes five types of Simple Network Management Protocol (SNMP) applications which make use of an SNMP engine as described in STD 62, RFC 3411. The types of application described are Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. This document also defines Management Information Base (MIB) modules for specifying targets of management operations, for notification filtering, and for proxy forwarding. This document obsoletes RFC 2573. [STANDARDS-TRACK]

draft-ietf-snmpv3-appl-v3-01 RFC2573 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3413 10.17487/RFC3413
RFC3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) U. Blumenthal B. Wijnen December 2002 ASCII HTML 88 USM-SNMPV3 message level mib information base

This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model. This document obsoletes RFC 2574. [STANDARDS-TRACK]

draft-ietf-snmpv3-usm-v2-rfc2574bis-01 RFC2574 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3414 10.17487/RFC3414
RFC3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) B. Wijnen R. Presuhn K. McCloghrie December 2002 ASCII HTML 39 VACM-SNMP mib information base

This document describes the View-based Access Control Model (VACM) for use in the Simple Network Management Protocol (SNMP) architecture. It defines the Elements of Procedure for controlling access to management information. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for the View- based Access Control Model. This document obsoletes RFC 2575. [STANDARDS-TRACK]

draft-ietf-snmpv3-vacm-v2-01 RFC2575 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3415 10.17487/RFC3415
RFC3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII HTML 31 OPS-MIB Simple Network Management Protocol Version 2

This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905. [STANDARDS-TRACK]

draft-ietf-snmpv3-update-proto-08 RFC1905 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3416 10.17487/RFC3416
RFC3417 Transport Mappings for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII HTML 19 TRANS-MIB Simple Network Management Protocol Version 2

This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906. [STANDARDS-TRACK]

draft-ietf-snmpv3-update-transmap-08 RFC1906 RFC4789 RFC5590 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 10.17487/RFC3417
RFC3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) R. Presuhn Editor December 2002 ASCII HTML 26 SNMPv2-MIB Simple Network Management Protocol Version 2

This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]

draft-ietf-snmpv3-update-mib-07 RFC1907 STD0062 INTERNET STANDARD INTERNET STANDARD IETF ops snmpv3 http://www.rfc-editor.org/errata_search.php?rfc=3418 10.17487/RFC3418
RFC3419 Textual Conventions for Transport Addresses M. Daniele J. Schoenwaelder December 2002 ASCII HTML 18 mib management information base

This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6. [STANDARDS-TRACK]

draft-ietf-ops-taddress-mib-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3419
RFC3420 Internet Media Type message/sipfrag R. Sparks November 2002 ASCII HTML 8 mime multipurpose internet mail extesions

This document registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request. [STANDARDS-TRACK]

draft-ietf-sip-sipfrag-00 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3420 10.17487/RFC3420
RFC3421 Select and Sort Extensions for the Service Location Protocol (SLP) W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome November 2002 ASCII HTML 8 user agent url service reply ua svrrply

This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. This memo defines an Experimental Protocol for the Internet community.

draft-zhao-slp-customization-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3421
RFC3422 Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) O. Okamoto M. Maruyama T. Sajima November 2002 ASCII HTML 19 tunneling ethernet frames

This memo describes a method for forwarding media access control (MAC) frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network (LAN) environment. This memo provides information for the Internet community.

draft-okamoto-mac-over-mapos-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3422
RFC3423 XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0 K. Zhang E. Elkin November 2002 ASCII HTML 45 data delivery message format template-based client/server

This document defines the Common Reliable Accounting for Network Element (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems (BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources. This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. This memo provides information for the Internet community.

draft-kzhang-crane-protocol-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3423
RFC3424 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation L. Daigle Editor IAB November 2002 ASCII HTML 9 nat middleboxes

As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.

draft-iab-unsaf-considerations-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3424 10.17487/RFC3424
RFC3425 Obsoleting IQUERY D. Lawrence November 2002 ASCII HTML 5 dns lookups domain

The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete. This document updates RFC 1035. [STANDARDS-TRACK]

draft-ietf-dnsext-obsolete-iquery-04 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3425
RFC3426 General Architectural and Policy Considerations S. Floyd November 2002 ASCII HTML 23 internet architecture

This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. This memo provides information for the Internet community.

draft-iab-considerations-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3426
RFC3427 Change Process for the Session Initiation Protocol (SIP) A. Mankin S. Bradner R. Mahy D. Willis J. Ott B. Rosen December 2002 ASCII HTML 12 sipping

This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-tsvarea-sipchange-03 RFC5727 RFC3968 RFC3969 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3427
RFC3428 Session Initiation Protocol (SIP) Extension for Instant Messaging B. Campbell Editor J. Rosenberg H. Schulzrinne C. Huitema D. Gurle December 2002 ASCII HTML 18 im message method

Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. [STANDARDS-TRACK]

draft-ietf-sip-message-07 RFC8591 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3428 10.17487/RFC3428
RFC3429 Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions H. Ohta November 2002 ASCII HTML 6 reserved lavel values

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. This memo provides information for the Internet community.

draft-ohta-mpls-label-value-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3429
RFC3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping J. Schoenwaelder December 2002 ASCII HTML 10 snmp tcp

This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-nmrg-snmp-tcp-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3430
RFC3431 Sieve Extension: Relational Tests W. Segmuller December 2002 ASCII HTML 8 sieve mail filtering language

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. [STANDARDS-TRACK]

draft-segmuller-sieve-relation-02 RFC5231 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3431
RFC3432 Network performance measurement with periodic streams V. Raisanen G. Grotefeld A. Morton November 2002 ASCII HTML 23 cbr constant bit rate periodic sampling poisson sampling

This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations. [STANDARDS-TRACK]

draft-ietf-ippm-npmps-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC3432
RFC3433 Entity Sensor Management Information Base A. Bierman D. Romascanu K.C. Norseth December 2002 ASCII HTML 17 mib physical sensors snmp

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the Entity MIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage). [STANDARDS-TRACK]

draft-ietf-entmib-sensor-mib-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=3433 10.17487/RFC3433
RFC3434 Remote Monitoring MIB Extensions for High Capacity Alarms A. Bierman K. McCloghrie December 2002 ASCII HTML 24 rmon counter64 smiv2 snmp

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB (RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type. [STANDARDS-TRACK]

draft-ietf-rmonmib-hc-alarm-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3434
RFC3435 Media Gateway Control Protocol (MGCP) Version 1.0 F. Andreasen B. Foster January 2003 ASCII HTML 210 voice IP internet VoIP

This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control "intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP. Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints. The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. This memo provides information for the Internet community.

draft-andreasen-mgcp-rfc2705bis-05 RFC2705 RFC3661 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3435 10.17487/RFC3435
RFC3436 Transport Layer Security over Stream Control Transmission Protocol A. Jungmaier E. Rescorla M. Tuexen December 2002 ASCII HTML 9 sctp tls

This document describes the usage of the Transport Layer Security (TLS) protocol, as defined in RFC 2246, over the Stream Control Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses. [STANDARDS-TRACK]

draft-ietf-tsvwg-tls-over-sctp-00 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3436
RFC3437 Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation W. Palter W. Townsley December 2002 ASCII HTML 10 l2tp lcp

This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides. [STANDARDS-TRACK]

draft-ietf-l2tpext-link-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3437
RFC3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update W. Townsley December 2002 ASCII HTML 5 L2TP ppp point-to-point protocol packets

This document describes updates to the Internet Assigned Numbers Authority (IANA) considerations for the Layer Two Tunneling Protocol (L2TP). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-l2tpext-rfc2661-iana-01 BCP0068 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int l2tpext 10.17487/RFC3438
RFC3439 Some Internet Architectural Guidelines and Philosophy R. Bush D. Meyer December 2002 ASCII HTML 28 IAB

This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. This memo provides information for the Internet community.

draft-ymbk-arch-guidelines-03 RFC1958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3439 10.17487/RFC3439
RFC3440 Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines F. Ly G. Bathrick December 2002 ASCII HTML 36 simple network management protocol mib adsl asymmetric digital subscriber line

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]

draft-ietf-adslmib-adslext-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3440
RFC3441 Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) R. Kumar January 2003 ASCII HTML 50 connection codec profile

This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, and ATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. This memo provides information for the Internet community.

draft-rajeshkumar-mgcp-atm-package-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3441
RFC3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 T. Lemon S. Cheshire B. Volz December 2002 ASCII HTML 9 Dynamic Host Configuration Protocol Bootstrap

This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask. [STANDARDS-TRACK]

draft-ietf-dhc-csr-07 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3442
RFC3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks P. Agarwal B. Akyol January 2003 ASCII HTML 10 label stack encoding uniform model pipe model

This document describes Time To Live (TTL) processing in hierarchical Multi-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label Stack Encoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and "pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks. [STANDARDS-TRACK]

draft-ietf-mpls-ttl-04 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3443
RFC3444 On the Difference between Information Models and Data Models A. Pras J. Schoenwaelder January 2003 ASCII HTML 8 network management

There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.

draft-irtf-nmrg-im-dm-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3444
RFC3445 Limiting the Scope of the KEY Resource Record (RR) D. Massey S. Rose December 2002 ASCII HTML 10 DNS-SECEXT dns authentication

This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS-TRACK]

draft-ietf-dnsext-restrict-key-for-dnssec-04 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3445 10.17487/RFC3445
RFC3446 Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) D. Kim D. Meyer H. Kilmer D. Farinacci January 2003 ASCII HTML 7 sparse mode single shared-tree

This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain. This memo provides information for the Internet community.

draft-ietf-mboned-anycast-rp-08 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC3446
RFC3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 J. Jonsson B. Kaliski February 2003 ASCII HTML 72 data public key cryptosystem

This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.

draft-jonsson-pkcs1-v2dot1-00 RFC2437 RFC8017 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3447 10.17487/RFC3447
RFC3448 TCP Friendly Rate Control (TFRC): Protocol Specification M. Handley S. Floyd J. Padhye J. Widmer January 2003 ASCII HTML 24 congestion unicast streaming media

This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. [STANDARDS-TRACK]

draft-ietf-tsvwg-tfrc-05 RFC5348 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3448 10.17487/RFC3448
RFC3449 TCP Performance Implications of Network Path Asymmetry H. Balakrishnan V. Padmanabhan G. Fairhurst M. Sooriyabandara December 2002 ASCII HTML 41 links sender receiver ack

This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-asym-08 BCP0069 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3449
RFC3450 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby J. Gemmell L. Vicisano L. Rizzo J. Crowcroft December 2002 ASCII HTML 34 content delivery congestion control receivers

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-pi-alc-08 RFC5775 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3450
RFC3451 Layered Coding Transport (LCT) Building Block M. Luby J. Gemmell L. Vicisano L. Rizzo M. Handley J. Crowcroft December 2002 ASCII HTML 29 content stream delivery multicast internet protocol

Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-lct-04 RFC5651 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3451
RFC3452 Forward Error Correction (FEC) Building Block M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII HTML 16 content stream delivery multicast internet protocol

This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast". This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-fec-07 RFC5052 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3452
RFC3453 The Use of Forward Error Correction (FEC) in Reliable Multicast M. Luby L. Vicisano J. Gemmell L. Rizzo M. Handley J. Crowcroft December 2002 ASCII HTML 18 ip internet protocol data transport

This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. This memo provides information for the Internet community.

draft-ietf-rmt-info-fec-03 INFORMATIONAL INFORMATIONAL IETF tsv rmt 10.17487/RFC3453
RFC3454 Preparation of Internationalized Strings ("stringprep") P. Hoffman M. Blanchet December 2002 ASCII HTML 91 unicode text internationalization

This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. [STANDARDS-TRACK]

draft-hoffman-stringprep-07 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3454 10.17487/RFC3454
RFC3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) M. Garcia-Martin E. Henrikson D. Mills January 2003 ASCII HTML 34

This document describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. This memo provides information for the Internet community.

draft-garcia-sipping-3gpp-p-headers-02 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3455 10.17487/RFC3455
RFC3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode B. Patel B. Aboba S. Kelly V. Gupta January 2003 ASCII HTML 18 security internet protocol

This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. In IPv4, DHCP provides for such remote host configuration. [STANDARDS-TRACK]

draft-ietf-ipsec-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsra 10.17487/RFC3456
RFC3457 Requirements for IPsec Remote Access Scenarios S. Kelly S. Ramamoorthi January 2003 ASCII HTML 31 ipsra common remote access scenarios

IPsec offers much promise as a secure remote access mechanism. However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. This memo provides information for the Internet community.

draft-ietf-ipsra-reqmts-05 INFORMATIONAL INFORMATIONAL IETF sec ipsra 10.17487/RFC3457
RFC3458 Message Context for Internet Mail E. Burger E. Candell C. Eliot G. Klyne January 2003 ASCII HTML 17 user agent ua

This memo describes a new RFC 2822 message header, "Message-Context". This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

draft-ietf-vpim-hint-08 RFC3938 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3458
RFC3459 Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter E. Burger January 2003 ASCII HTML 24 body parts content-disposition

This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process. [STANDARDS-TRACK]

draft-ietf-vpim-cc-08 RFC3204 RFC5621 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3459
RFC3460 Policy Core Information Model (PCIM) Extensions B. Moore Editor January 2003 ASCII HTML 93 CIM common schema object-oriented

This document specifies a number of changes to the Policy Core Information Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060. [STANDARDS-TRACK]

draft-ietf-policy-pcim-ext-08 RFC3060 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3460
RFC3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) K. Moore January 2003 ASCII HTML 38 SMTP-DSN simple mail transfer protocol

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]

draft-moore-rfc1891bis-02 RFC1891 RFC3798 RFC3885 RFC5337 RFC6533 RFC8098 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3461 10.17487/RFC3461
RFC3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages G. Vaudreuil January 2003 ASCII HTML 7 MIME-RPT Multipurpose Internet Mail Extensions

The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. [STANDARDS-TRACK]

draft-vaudreuil-1892bis-02 RFC1892 RFC6522 RFC5337 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3462
RFC3463 Enhanced Mail System Status Codes G. Vaudreuil January 2003 ASCII HTML 16 EMS-CODE simple mail transfer protocol SMTP

This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK]

draft-vaudreuil-1893bis-03 RFC1893 RFC3886 RFC4468 RFC4865 RFC4954 RFC5248 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3463 10.17487/RFC3463
RFC3464 An Extensible Message Format for Delivery Status Notifications K. Moore G. Vaudreuil January 2003 ASCII HTML 40 DSN Multipurpose Internet Mail Extensions Content Type

This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS-TRACK]

draft-vaudreuil-1894bis-02 RFC1894 RFC4865 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3464 10.17487/RFC3464
RFC3465 TCP Congestion Control with Appropriate Byte Counting (ABC) M. Allman February 2003 ASCII HTML 10 transmission control protocol security performance

This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. This memo defines an Experimental Protocol for the Internet community.

draft-allman-tcp-abc-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3465
RFC3466 A Model for Content Internetworking (CDI) M. Day B. Cain G. Tomlinson P. Rzewski February 2003 ASCII HTML 17 distribution peering

Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. This memo provides information for the Internet community.

draft-ietf-cdi-model-02 RFC7336 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3466
RFC3467 Role of the Domain Name System (DNS) J. Klensin February 2003 ASCII HTML 31 history internationalization unicode ascii multilingual names

This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.

draft-klensin-dns-role-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3467
RFC3468 The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols L. Andersson G. Swallow February 2003 ASCII HTML 11 rsvp-te ldp resource reservation protocol label distribution

This document documents the consensus reached by the Multiprotocol Label Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for Label- Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. This memo provides information for the Internet community.

draft-andersson-mpls-sig-decision-03 RFC3212 RFC3472 RFC3475 RFC3476 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3468 10.17487/RFC3468
RFC3469 Framework for Multi-Protocol Label Switching (MPLS)-based Recovery V. Sharma Editor F. Hellstrand Editor February 2003 ASCII HTML 40 routing traffic

Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. This memo provides information for the Internet community.

draft-ietf-mpls-recovery-frmwrk-08 RFC5462 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3469
RFC3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols S. Hollenbeck M. Rose L. Masinter January 2003 ASCII HTML 28 data documents structure

The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data. There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hollenbeck-ietf-xml-guidelines-07 BCP0070 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3470 10.17487/RFC3470
RFC3471 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description L. Berger Editor January 2003 ASCII HTML 34 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]

draft-ietf-mpls-generalized-signaling-09 RFC4201 RFC4328 RFC4872 RFC6002 RFC6003 RFC6205 RFC7074 RFC7699 RFC8359 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3471 10.17487/RFC3471
RFC3472 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions P. Ashwood-Smith Editor L. Berger Editor January 2003 ASCII HTML 23 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

draft-ietf-mpls-generalized-cr-ldp-07 RFC3468 RFC4201 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3472
RFC3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions L. Berger Editor January 2003 ASCII HTML 42 mpls sonet/sdh

This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK]

draft-ietf-mpls-generalized-rsvp-te-09 RFC4003 RFC4201 RFC4420 RFC4783 RFC4874 RFC4873 RFC4974 RFC5063 RFC5151 RFC5420 RFC6002 RFC6003 RFC6780 RFC8359 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3473 10.17487/RFC3473
RFC3474 Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) Z. Lin D. Pendarakis March 2003 ASCII HTML 25 sonet sdh

The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well as Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using Resource Reservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T Study Group 15 in support of ITU's ASON standardization effort. This memo provides information for the Internet community.

draft-lin-ccamp-gmpls-ason-rsvpte-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3474
RFC3475 Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) O. Aboul-Magd March 2003 ASCII HTML 13 label switching protocol itu-t

Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by the IETF in the context of Generalized Multi-Protocol Label Switching (GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. This memo provides information for the Internet community.

draft-aboulmagd-ccamp-crldp-ason-ext-02 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3475
RFC3476 Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling B. Rajagopalan March 2003 ASCII HTML 11 oif optical interworking forum uni user network interface

The Optical Interworking Forum (OIF) has defined extensions to the Label Distribution Protocol (LDP) and the Resource ReSerVation Protocol (RSVP) for optical User Network Interface (UNI) signaling. These extensions consist of a set of new data objects and error codes. This document describes these extensions. This memo provides information for the Internet community.

draft-bala-uni-ldp-rsvp-extensions-04 RFC3468 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3476
RFC3477 Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) K. Kompella Y. Rekhter January 2003 ASCII HTML 9 mpls-te traffic engineering

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-unnum-08 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3477
RFC3478 Graceful Restart Mechanism for Label Distribution Protocol M. Leelanivas Y. Rekhter R. Aggarwal February 2003 ASCII HTML 12 ldp mpls

This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-restart-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3478
RFC3479 Fault Tolerance for the Label Distribution Protocol (LDP) A. Farrel Editor February 2003 ASCII HTML 52 mpls multiprotocol label switching cr-ldp high availability restart

Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP). [STANDARDS-TRACK]

draft-ietf-mpls-ldp-ft-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3479
RFC3480 Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) K. Kompella Y. Rekhter A. Kullberg February 2003 ASCII HTML 8 mpls multiprotocol label switching traffic engineering mpls-te

Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Constraint-Routing Label Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links. [STANDARDS-TRACK]

PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3480
RFC3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks H. Inamura Editor G. Montenegro Editor R. Ludwig A. Gurtov F. Khafizov February 2003 ASCII HTML 26 paths algorithm stacks

This document describes a profile for optimizing TCP to adapt so that it handles paths including second (2.5G) and third (3G) generation wireless networks. It describes the relevant characteristics of 2.5G and 3G networks, and specific features of example deployments of such networks. It then recommends TCP algorithm choices for nodes known to be starting or ending on such paths, and it also discusses open issues. The configuration options recommended in this document are commonly found in modern TCP stacks, and are widely available standards-track mechanisms that the community considers safe for use on the general Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-2.5g3g-12 BCP0071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc 10.17487/RFC3481
RFC3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview M. Foster T. McGarry J. Yu February 2003 ASCII HTML 30 e.164 telephony routing

This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. This memo provides information for the Internet community.

draft-ietf-enum-e164-gstn-np-05 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC3482
RFC3483 Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) D. Rawlins A. Kulkarni M. Bokaemper K. Chan March 2003 ASCII HTML 10 accounting policy decision point bdp

Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point (PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. This memo provides information for the Internet community.

draft-ietf-rap-feedback-frwk-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3483
RFC3484 Default Address Selection for Internet Protocol version 6 (IPv6) R. Draves February 2003 ASCII HTML 24 source address destination

This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK]

draft-ietf-ipv6-default-addr-select-09 RFC6724 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3484
RFC3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp) M. Garcia-Martin C. Bormann J. Ott R. Price A. B. Roach February 2003 ASCII HTML 30 algorithm

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. [STANDARDS-TRACK]

draft-ietf-sipping-sigcomp-sip-dictionary-05 RFC4896 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3485
RFC3486 Compressing the Session Initiation Protocol (SIP) G. Camarillo February 2003 ASCII HTML 12

This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. [STANDARDS-TRACK]

draft-ietf-sip-compression-02 RFC5049 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3486
RFC3487 Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) H. Schulzrinne February 2003 ASCII HTML 17 circuit switched network resources end system resources proxy resources emergency preparedness communications

This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). This memo provides information for the Internet community.

draft-ietf-ieprep-sip-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3487
RFC3488 Cisco Systems Router-port Group Management Protocol (RGMP) I. Wu T. Eckert February 2003 ASCII HTML 17 multicast switches packet

This document describes the Router-port Group Management Protocol (RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed. RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. This memo provides information for the Internet community.

draft-wu-rgmp-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3488
RFC3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) J. Rosenberg J. Weinberger C. Huitema R. Mahy March 2003 ASCII HTML 47 lightweight applications firewalls

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. [STANDARDS-TRACK]

draft-ietf-midcom-stun-05 RFC5389 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC3489
RFC3490 Internationalizing Domain Names in Applications (IDNA) P. Faltstrom P. Hoffman A. Costello March 2003 ASCII HTML 22 idn ascii characters

Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

draft-ietf-idn-idna-14 RFC5890 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3490 10.17487/RFC3490
RFC3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) P. Hoffman M. Blanchet March 2003 ASCII HTML 7 idna applications

This document describes how to prepare internationalized domain name (IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS). [STANDARDS-TRACK]

draft-ietf-idn-nameprep-11 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn 10.17487/RFC3491
RFC3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA) A. Costello March 2003 ASCII HTML 35 syntax string host label

Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]

draft-ietf-idn-punycode-03 RFC5891 PROPOSED STANDARD PROPOSED STANDARD IETF int idn http://www.rfc-editor.org/errata_search.php?rfc=3492 10.17487/RFC3492
RFC3493 Basic Socket Interface Extensions for IPv6 R. Gilligan S. Thomson J. Bound J. McCann W. Stevens February 2003 ASCII HTML 39 internet protocol api application program interface tcp transmission control

The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This memo provides information for the Internet community.

RFC2553 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3493
RFC3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status K. Zeilenga March 2003 ASCII HTML 5 DAP interactive access X.500 LDAP lightweight directory protocol STR-REP directory names representing names

This document recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. This memo provides information for the Internet community.

draft-zeilenga-ldapv2-04 RFC1484 RFC1485 RFC1487 RFC1777 RFC1778 RFC1779 RFC1781 RFC2559 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3494 10.17487/RFC3494
RFC3495 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration B. Beser P. Duffy Editor March 2003 ASCII HTML 13 packetcable media terminal adapter mta

This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. [STANDARDS-TRACK]

draft-ietf-dhc-packetcable-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3495 10.17487/RFC3495
RFC3496 Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering A. G. Malis T. Hsiao March 2003 ASCII HTML 6 diff-serv diffserv rsvp-te resource reservation protocol

This document specifies a Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) signaling extension for support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering. This memo provides information for the Internet community.

draft-malis-diff-te-serviceclass-04 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3496
RFC3497 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video L. Gharai C. Perkins G. Goncher A. Mankin March 2003 ASCII HTML 12 real-time transport protocol hdtv high definition television

This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport. [STANDARDS-TRACK]

draft-ietf-avt-smpte292-video-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3497
RFC3498 Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures J. Kuhfeld J. Johnson M. Thatcher March 2003 ASCII HTML 43 mib management information base tcp/ip transmission control protocol internet protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Synchronous Optical Network (SONET) linear Automatic Protection Switching (APS) architectures. [STANDARDS-TRACK]

draft-ietf-atommib-sonetaps-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3498
RFC3499 Request for Comments Summary RFC Numbers 3400-3499 S. Ginoza December 2003 ASCII HTML 38 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3499 RFC3500 RFC3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 M. Crispin March 2003 ASCII HTML 108 IMAPv4 imap imapv4rev1

The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]

draft-crispin-imapv-20 RFC2060 RFC4466 RFC4469 RFC4551 RFC5032 RFC5182 RFC5738 RFC6186 RFC6858 RFC7817 RFC8314 RFC8437 RFC8474 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3501 10.17487/RFC3501
RFC3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension M. Crispin March 2003 ASCII HTML 7 IMAPv4 imap imapv4rev1

This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS-TRACK]

draft-crispin-imap-multiappend-07 RFC4466 RFC4469 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3502
RFC3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) A. Melnikov March 2003 ASCII HTML 9 mua mail user agent imap4

The Message Disposition Notification (MDN) facility defined in RFC 2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products. [STANDARDS-TRACK]

draft-melnikov-imap-mdn-05 PROPOSED STANDARD PROPOSED STANDARD Legacy 10.17487/RFC3503
RFC3504 Internet Open Trading Protocol (IOTP) Version 1, Errata D. Eastlake March 2003 ASCII HTML 6 commerce payment system merchant system xml extensible markup language security

Since the publication of the RFCs specifying Version 1.0 of the Internet Open Trading Protocol (IOTP), some errors have been noted. This informational document lists these errors and provides corrections for them. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1-errata-01 INFORMATIONAL INFORMATIONAL IETF app trade http://www.rfc-editor.org/errata_search.php?rfc=3504 10.17487/RFC3504
RFC3505 Electronic Commerce Modeling Language (ECML): Version 2 Requirements D. Eastlake March 2003 ASCII HTML 8 xml extensible markup language

This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to Extensible Markup Language (XML) syntax, data model, format, and payment processing. This memo provides information for the Internet community.

draft-ietf-trade-ecml2-req-05 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3505
RFC3506 Requirements and Design for Voucher Trading System (VTS) K. Fujimura D. Eastlake March 2003 ASCII HTML 15 generic voucher language gvl

Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher Trading System (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the Generic Voucher Language (GVL), with which diverse types of vouchers can be described. This memo provides information for the Internet community.

draft-ietf-trade-drt-requirements-04 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3506
RFC3507 Internet Content Adaptation Protocol (ICAP) J. Elson A. Cerpa April 2003 ASCII HTML 49 http hyper-text markup protocol request response client server

ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services. ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to pass HTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. This memo provides information for the Internet community.

draft-elson-icap-00 INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3507 10.17487/RFC3507
RFC3508 H.323 Uniform Resource Locator (URL) Scheme Registration O. Levin April 2003 ASCII HTML 6 itu-t packet networks

ITU-T Recommendation H.323 version 4 introduced an H.323-specific Uniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

draft-levin-iptel-h323-url-scheme-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3508
RFC3509 Alternative Implementations of OSPF Area Border Routers A. Zinin A. Lindem D. Yeung April 2003 ASCII HTML 12 traffic backbone

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. This memo provides information for the Internet community.

draft-ietf-ospf-abr-alt-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC3509
RFC3510 Internet Printing Protocol/1.1: IPP URL Scheme R. Herriot I. McDonald April 2003 ASCII HTML 16 IPP-E-T IPP application media-type media type

This memo defines the "ipp" URL (Uniform Resource Locator) scheme. This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910. An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service. [STANDARDS-TRACK]

draft-ietf-ipp-url-scheme-05 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3510
RFC3511 Benchmarking Methodology for Firewall Performance B. Hickman D. Newman S. Tadjudin T. Martin April 2003 ASCII HTML 34 client server traffic authentication web caching

This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. This document is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

draft-ietf-bmwg-firewall-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3511
RFC3512 Configuring Networks and Devices with Simple Network Management Protocol (SNMP) M. MacFaden D. Partain J. Saperia W. Tackabury April 2003 ASCII HTML 83 internet standard framework

This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. This memo provides information for the Internet community.

draft-ietf-snmpconf-bcp-12 INFORMATIONAL INFORMATIONAL IETF ops snmpconf 10.17487/RFC3512
RFC3513 Internet Protocol Version 6 (IPv6) Addressing Architecture R. Hinden S. Deering April 2003 ASCII HTML 26 internet protocol unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. [STANDARDS-TRACK]

draft-ietf-ipngwg-addr-arch-v3-11 RFC2373 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3513
RFC3514 The Security Flag in the IPv4 Header S. Bellovin April 1 2003 ASCII HTML 6 evil evil bit

Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL Legacy http://www.rfc-editor.org/errata_search.php?rfc=3514 10.17487/RFC3514
RFC3515 The Session Initiation Protocol (SIP) Refer Method R. Sparks April 2003 ASCII HTML 23 resource request call transfer

This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the refer event package and the Refer-To request header. [STANDARDS-TRACK]

draft-ietf-sip-refer-07 RFC7647 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3515 10.17487/RFC3515
RFC3516 IMAP4 Binary Content Extension L. Nerenberg April 2003 ASCII HTML 8 internet message acess procotol

This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]

draft-nerenberg-imap-binary-07 RFC4466 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3516 10.17487/RFC3516
RFC3517 A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP E. Blanton M. Allman K. Fall L. Wang April 2003 ASCII HTML 13 transmission control protocol retransmission congestion control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. [STANDARDS-TRACK]

draft-allman-tcp-sack-13 RFC6675 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3517
RFC3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) M. Higashiyama F. Baker T. Liao April 2003 ASCII HTML 40 PPP-BCP point-to-point datagrams network

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE 802.1D- 1993 MAC Bridge. This document extends that specification by improving support for bridge control packets. [STANDARDS-TRACK]

draft-ietf-pppext-rfc2878bis-01 RFC2878 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3518
RFC3519 Mobile IP Traversal of Network Address Translation (NAT) Devices H. Levkowetz S. Vaarala April 2003 ASCII HTML 34 Internet Protocol datagram traffic Mobile IP NAT NAPT traversal tunnelling tunneling UDP private address space keepalives port 434 MIP MIPv4 network address translation

Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. [STANDARDS-TRACK]

draft-ietf-mobileip-nat-traversal-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip http://www.rfc-editor.org/errata_search.php?rfc=3519 10.17487/RFC3519
RFC3520 Session Authorization Policy Element L-N. Hamer B. Gage B. Kosinski H. Shieh April 2003 ASCII HTML 30 admission control resource reservation

This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP) PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios. [STANDARDS-TRACK]

draft-ietf-rap-rsvp-authsession-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC3520
RFC3521 Framework for Session Set-up with Media Authorization L-N. Hamer B. Gage H. Shieh April 2003 ASCII HTML 25 qos quality of service streams linkage policy control admission theft service resource reservation token

Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host. To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in- line with the media streams requested (and authorized) for the session. This memo provides information for the Internet community.

draft-ietf-rap-session-auth-04 INFORMATIONAL INFORMATIONAL IETF ops rap 10.17487/RFC3521
RFC3522 The Eifel Detection Algorithm for TCP R. Ludwig M. Meyer April 2003 ASCII HTML 14 transmission control protocol loss recovery timestamps

The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-tcp-eifel-alg-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3522
RFC3523 Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology J. Polk April 2003 ASCII HTML 6 naming convetions phone

This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREP Working Group during discussions and when writing requirements, gap analysis and other solutions documents. This memo provides information for the Internet community.

draft-polk-ieprep-scenarios-03 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3523
RFC3524 Mapping of Media Streams to Resource Reservation Flows G. Camarillo A. Monrad April 2003 ASCII HTML 6 sdp session description protocol srf single

This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). [STANDARDS-TRACK]

draft-ietf-mmusic-reservation-flows-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3524
RFC3525 Gateway Control Protocol Version 1 C. Groves Editor M. Pantaleo Editor T. Anderson Editor T. Taylor Editor June 2003 ASCII HTML 213 MEGACO H.248 media gateway control

This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. [STANDARDS-TRACK]

draft-ietf-megaco-3015corr-02 RFC3015 RFC5125 HISTORIC PROPOSED STANDARD IETF rai megaco http://www.rfc-editor.org/errata_search.php?rfc=3525 10.17487/RFC3525
RFC3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) T. Kivinen M. Kojo May 2003 ASCII HTML 10 bit groups

This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK]

draft-ietf-ipsec-ike-modp-groups-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3526
RFC3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4 K. Kinnear M. Stapp R. Johnson J. Kumarasamy April 2003 ASCII HTML 9 dynamic host configuration protocol

This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. [STANDARDS-TRACK]

draft-ietf-dhc-agent-subnet-selection-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3527
RFC3528 Mesh-enhanced Service Location Protocol (mSLP) W. Zhao H. Schulzrinne E. Guttman April 2003 ASCII HTML 15 da directory agent slpda service agent sa slpv2

This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti- entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. This memo defines an Experimental Protocol for the Internet community.

draft-zhao-slp-da-interaction-16 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3528
RFC3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) W. Harold April 2003 ASCII HTML 15 format messages clients servers

Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP. An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures. This document specifies a how to use the Blocks Extensible Exchange Protocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. This memo defines an Experimental Protocol for the Internet community.

draft-harold-beep-xmlrpc-03 RFC8553 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3529
RFC3530 Network File System (NFS) version 4 Protocol S. Shepler B. Callaghan D. Robinson R. Thurlow C. Beame M. Eisler D. Noveck April 2003 ASCII HTML 275 NFSv4 network file system

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document replaces RFC 3010 as the definition of the NFS version 4 protocol. [STANDARDS-TRACK]

draft-ietf-nfsv4-rfc3010bis-04 RFC3010 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=3530 10.17487/RFC3530
RFC3531 A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block M. Blanchet April 2003 ASCII HTML 7 address plan addressing range space internet protocol

This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. This memo provides information for the Internet community.

draft-ietf-ipv6-ipaddressassign-06 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3531
RFC3532 Requirements for the Dynamic Partitioning of Switching Elements T. Anderson J. Buerkle May 2003 ASCII HTML 11 atm asynchronous transfer mode

This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element (e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. This memo provides information for the Internet community.

draft-ietf-gsmp-dyn-part-reqs-03 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3532
RFC3533 The Ogg Encapsulation Format Version 0 S. Pfeiffer May 2003 ASCII HTML 15 bitstream media streams video audio xiph.org multimedia media interleading format video bitstream packaging audio bitstream packaging free encapsulation format stream based storage of codec data framed bitstream

This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.

draft-pfeiffer-ogg-fileformat-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3533
RFC3534 The application/ogg Media Type L. Walleij May 2003 ASCII HTML 6 mime multipurpose internet mail extenstions

The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS-TRACK]

draft-walleij-ogg-mediatype-08 RFC5334 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3534
RFC3535 Overview of the 2002 IAB Network Management Workshop J. Schoenwaelder May 2003 ASCII HTML 20 Internet Architecture Board

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community.

draft-iab-nm-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3535
RFC3536 Terminology Used in Internationalization in the IETF P. Hoffman May 2003 ASCII HTML 30 internet engineering task force

This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo provides information for the Internet community.

draft-hoffman-i18n-terms-11 RFC6365 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3536
RFC3537 Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key J. Schaad R. Housley May 2003 ASCII HTML 9

This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). [PROPOSED STANDARD]

draft-ietf-smime-hmac-key-wrap-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3537 10.17487/RFC3537
RFC3538 Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura June 2003 ASCII HTML 56 payment input output parameter

This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-set-02 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3538
RFC3539 Authentication, Authorization and Accounting (AAA) Transport Profile B. Aboba J. Wood June 2003 ASCII HTML 41

This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK]

draft-ietf-aaa-transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa 10.17487/RFC3539
RFC3540 Robust Explicit Congestion Notification (ECN) Signaling with Nonces N. Spring D. Wetherall D. Ely June 2003 ASCII HTML 13 congestion control tcp traffic control protocol

This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-tcp-nonce-04 HISTORIC EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3540
RFC3541 A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D) A. Walsh May 2003 ASCII HTML 6 virtual reality monitoring language vrml extensible markup language x3d xml dtd document type definition

This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality Modeling Language (VRML) and Extensible 3D (X3D) files and resources, Extensible Markup Language (XML) Document Type Definitions (DTDs), XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. This memo provides information for the Internet community.

draft-walsh-urn-web3d-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3541
RFC3542 Advanced Sockets Application Program Interface (API) for IPv6 W. Stevens M. Thomas E. Nordmark T. Jinmei May 2003 ASCII HTML 77 application program interface

This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community.

draft-ietf-ipngwg-rfc2292bis-09 RFC2292 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3542 10.17487/RFC3542
RFC3543 Registration Revocation in Mobile IPv4 S. Glass M. Chandra August 2003 ASCII HTML 33 internet protocol

This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well. Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the Mobile IPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding. [STANDARDS-TRACK]

draft-ietf-mobileip-reg-revok-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3543
RFC3544 IP Header Compression over PPP T. Koren S. Casner C. Bormann July 2003 ASCII HTML 14 IPCOM-PPP internet protocol point-to-point datagrams

This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545. [STANDARDS-TRACK]

draft-koren-pppext-rfc2509bis-03 RFC2509 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3544
RFC3545 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering T. Koren S. Casner J. Geevarghese B. Thompson P. Ruddy July 2003 ASCII HTML 22 point to point header

This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK]

draft-ietf-avt-crtp-enhance-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3545
RFC3546 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright June 2003 ASCII HTML 29 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

draft-ietf-tls-extensions-06 RFC4366 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3546
RFC3547 The Group Domain of Interpretation M. Baugher B. Weis T. Hardjono H. Harney July 2003 ASCII HTML 48 isamkp doi key management security encryption

This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. The GDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. [STANDARDS-TRACK]

draft-ietf-msec-gdoi-07 RFC6407 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC3547
RFC3548 The Base16, Base32, and Base64 Data Encodings S. Josefsson Editor July 2003 ASCII HTML 13 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. This memo provides information for the Internet community.

draft-josefsson-base-encoding-04 RFC4648 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3548 10.17487/RFC3548
RFC3549 Linux Netlink as an IP Services Protocol J. Salim H. Khosravi A. Kleen A. Kuznetsov July 2003 ASCII HTML 33 internet protocol messaging system

This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component (FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter- process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.). This document is intended as informational in the context of prior art for the ForCES IETF working group. This memo provides information for the Internet community.

draft-ietf-forces-netlink-04 INFORMATIONAL INFORMATIONAL IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=3549 10.17487/RFC3549
RFC3550 RTP: A Transport Protocol for Real-Time Applications H. Schulzrinne S. Casner R. Frederick V. Jacobson July 2003 ASCII PS PDF HTML 104 RTP end-to-end network audio video RTCP

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]

draft-ietf-avt-rtp-new-12 RFC1889 RFC5506 RFC5761 RFC6051 RFC6222 RFC7022 RFC7160 RFC7164 RFC8083 RFC8108 STD0064 INTERNET STANDARD DRAFT STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3550 10.17487/RFC3550
RFC3551 RTP Profile for Audio and Video Conferences with Minimal Control H. Schulzrinne S. Casner July 2003 ASCII PS PDF HTML 44 RTP-AV end-to-end network conference

This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK]

draft-ietf-avt-profile-new-13 RFC1890 RFC5761 RFC7007 STD0065 INTERNET STANDARD DRAFT STANDARD IETF rai avt 10.17487/RFC3551
RFC3552 Guidelines for Writing RFC Text on Security Considerations E. Rescorla B. Korver July 2003 ASCII HTML 44 Request for Comment

All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-sec-cons-03 BCP0072 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3552 10.17487/RFC3552
RFC3553 An IETF URN Sub-namespace for Registered Protocol Parameters M. Mealling L. Masinter T. Hardie G. Klyne June 2003 ASCII HTML 8 syntax uniform resource names

This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-mealling-iana-urn-04 BCP0073 BEST CURRENT PRACTICE BEST CURRENT PRACTICE Legacy 10.17487/RFC3553
RFC3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec S. Bellovin J. Ioannidis A. Keromytis R. Stewart July 2003 ASCII HTML 9 ike internet key exchange security

This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. [STANDARDS-TRACK]

draft-ietf-ipsec-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3554
RFC3555 MIME Type Registration of RTP Payload Formats S. Casner P. Hoschka July 2003 ASCII HTML 45 real time transport protocol multipurpose internet mail extensions

This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text- based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mime-06 RFC4855 RFC4856 RFC3625 RFC4629 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3555
RFC3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth S. Casner July 2003 ASCII HTML 8 real time transport protocol real-time

This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-bw-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3556
RFC3557 RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding Q. Xie Editor July 2003 ASCII HTML 15 real time transport protocol real-time dsr

This document specifies an RTP payload format for encapsulating European Telecommunications Standards Institute (ETSI) European Standard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

draft-ietf-avt-dsr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3557
RFC3558 RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) A. Li July 2003 ASCII HTML 23 real time transport protocol real-time bundled interleaved

This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications. [STANDARDS-TRACK]

draft-ietf-avt-evrc-smv-03 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3558
RFC3559 Multicast Address Allocation MIB D. Thaler June 2003 ASCII HTML 37 maas management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. [STANDARDS-TRACK]

draft-ietf-malloc-malloc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv malloc 10.17487/RFC3559
RFC3560 Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS) R. Housley July 2003 ASCII HTML 18 security encryption

This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. [STANDARDS-TRACK]

draft-ietf-smime-cms-rsaes-oaep-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3560
RFC3561 Ad hoc On-Demand Distance Vector (AODV) Routing C. Perkins E. Belding-Royer S. Das July 2003 ASCII HTML 37 unicast multiple nodes

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-manet-aodv-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3561
RFC3562 Key Management Considerations for the TCP MD5 Signature Option M. Leech July 2003 ASCII HTML 7 bgp border gateway protocol security encryption

The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature. This document addresses the security requirements of that keying material. This memo provides information for the Internet community.

draft-ietf-idr-md5-keys-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC3562
RFC3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development A. Zinin July 2003 ASCII HTML 8

This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.

draft-zinin-ietf-jtc1-aggr-01 RFC6233 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3563
RFC3564 Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering F. Le Faucheur W. Lai July 2003 ASCII HTML 22 multi-protocol label switching bandwidth constraints model overbooking

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS- TE). Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document. A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. This memo provides information for the Internet community.

draft-ietf-tewg-diff-te-reqts-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC3564
RFC3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Schaad July 2003 ASCII HTML 14 security data encoding

This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm for encryption with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

draft-ietf-smime-aes-alg-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3565
RFC3566 The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec S. Frankel H. Herbert September 2003 ASCII HTML 11 authentication hash security

A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. [STANDARDS-TRACK]

draft-ietf-ipsec-ciph-aes-xcbc-mac-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3566
RFC3567 Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication T. Li R. Atkinson July 2003 ASCII HTML 6 iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This memo provides information for the Internet community.

draft-ietf-isis-hmac-04 RFC5304 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3567
RFC3568 Known Content Network (CN) Request-Routing Mechanisms A. Barbir B. Cain R. Nair O. Spatscheck July 2003 ASCII HTML 19 metrics routing redirection

This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing. This memo provides information for the Internet community.

draft-ietf-cdi-known-request-routing-03 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3568
RFC3569 An Overview of Source-Specific Multicast (SSM) S. Bhattacharyya Editor July 2003 ASCII HTML 14 routing applications deployment interoperability

The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. This memo provides information for the Internet community.

draft-ietf-ssm-overview-05 INFORMATIONAL INFORMATIONAL IETF rtg ssm 10.17487/RFC3569
RFC3570 Content Internetworking (CDI) Scenarios P. Rzewski M. Day D. Gilletti July 2003 ASCII HTML 20 production networks

In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. This memo provides information for the Internet community.

draft-ietf-cdi-scenarios-01 RFC6770 INFORMATIONAL INFORMATIONAL IETF app cdi 10.17487/RFC3570
RFC3571 Framework Policy Information Base for Usage Feedback D. Rawlins A. Kulkarni K. Ho Chan M. Bokaemper D. Dutt August 2003 ASCII HTML 35 pib

This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community.

draft-ietf-rap-feedback-fr-pib-06 HISTORIC INFORMATIONAL IETF ops rap 10.17487/RFC3571
RFC3572 Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) T. Ogura M. Maruyama T. Yoshida July 2003 ASCII HTML 14 ipv6 synchronous optical network synchronous digital hierarchy

Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link- layer protocol that provides multiple access capability over a Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH). This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. This memo provides information for the Internet community.

draft-ogura-ipv6-mapos-02 RFC8064 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3572
RFC3573 Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) I. Goyret July 2003 ASCII HTML 13 ppp point to point point-to-point pstn public switched telephone network

The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re-establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold. [STANDARDS-TRACK]

draft-ietf-l2tpext-v92-moh-05 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC3573
RFC3574 Transition Scenarios for 3GPP Networks J. Soininen Editor August 2003 ASCII HTML 12 third generation parnership project packet ipv6 ipv4 internet

This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This memo provides information for the Internet community.

draft-ietf-v6ops-3gpp-cases-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3574
RFC3575 IANA Considerations for RADIUS (Remote Authentication Dial In User Service) B. Aboba July 2003 ASCII HTML 8 internet assigned numbers authority encryption NAS Network Access Server

This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS). [STANDARDS-TRACK]

draft-aboba-radius-iana-07 RFC2865 RFC2868 RFC6929 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3575 10.17487/RFC3575
RFC3576 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba July 2003 ASCII HTML 30 nas network access server

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

draft-chiba-radius-dynamic-authorization-20 RFC5176 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3576
RFC3577 Introduction to the Remote Monitoring (RMON) Family of MIB Modules S. Waldbusser R. Cole C. Kalbfleisch D. Romascanu August 2003 ASCII HTML 31 management information base

The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. This memo provides information for the Internet community.

draft-ietf-rmonmib-framework-05 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3577
RFC3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) G. Camarillo A. B. Roach J. Peterson L. Ong August 2003 ASCII HTML 13 pstn public switched telephone network

This document describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN). [STANDARDS-TRACK]

draft-ietf-sipping-overlap-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3578
RFC3579 RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) B. Aboba P. Calhoun September 2003 ASCII HTML 46 RADIUS encryption NAS Network Access Server

This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community.

draft-aboba-radius-rfc2869bis-22 RFC2869 RFC5080 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3579 10.17487/RFC3579
RFC3580 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines P. Congdon B. Aboba A. Smith G. Zorn J. Roese September 2003 ASCII HTML 30 AAA authentication authorization and accounting

This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

draft-congdon-radius-8021x-29 RFC7268 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3580 10.17487/RFC3580
RFC3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing J. Rosenberg H. Schulzrinne August 2003 ASCII HTML 13 report client server

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. [STANDARDS-TRACK]

draft-ietf-sip-symmetric-response-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3581
RFC3582 Goals for IPv6 Site-Multihoming Architectures J. Abley B. Black V. Gill August 2003 ASCII HTML 9 internet protocol multi6

This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community.

draft-ietf-multi6-multihoming-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC3582
RFC3583 Requirements of a Quality of Service (QoS) Solution for Mobile IP H. Chaskar Editor September 2003 ASCII HTML 10 internet protocol routing packets node

Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper Quality of Service (QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. This memo provides information for the Internet community.

draft-ietf-nsis-qos-requirements-01 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3583
RFC3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework R. Frye D. Levi S. Routhier B. Wijnen August 2003 ASCII HTML 51 SNMP simple network management protocol mib information base

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-snmpv3-coex-v2-04 RFC2576 BCP0074 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops snmpv3 10.17487/RFC3584
RFC3585 IPsec Configuration Policy Information Model J. Jason L. Rafalow E. Vyncke August 2003 ASCII HTML 88 ike internet key exchange protocol core pcim

This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task- specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the Policy Core Information Model Extensions (PCIMe). [STANDARDS-TRACK]

draft-ietf-ipsp-config-policy-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3585
RFC3586 IP Security Policy (IPSP) Requirements M. Blaze A. Keromytis M. Richardson L. Sanchez August 2003 ASCII HTML 10 data integrity authentication host network

This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IP Security properties. This document highlights such architectural components and presents their functional requirements. [STANDARDS-TRACK]

draft-ietf-ipsp-requirements-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsp 10.17487/RFC3586
RFC3587 IPv6 Global Unicast Address Format R. Hinden S. Deering E. Nordmark August 2003 ASCII HTML 5 internet protocol architecture routing

This document obsoletes RFC 2374, "An IPv6 Aggregatable Global Unicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. This memo provides information for the Internet community.

draft-ietf-ipv6-unicast-aggr-v2-03 RFC2374 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=3587 10.17487/RFC3587
RFC3588 Diameter Base Protocol P. Calhoun J. Loughney E. Guttman G. Zorn J. Arkko September 2003 ASCII HTML 147 aaa authentication authorization accounting ip mobility

The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-17 RFC6733 RFC5729 RFC5719 RFC6408 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=3588 10.17487/RFC3588
RFC3589 Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5 J. Loughney September 2003 ASCII HTML 5 iana allocation

This document describes the IANA's allocation of a block of Diameter Command Codes for the Third Generation Partnership Project (3GPP) Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. This memo provides information for the Internet community.

draft-loughney-aaa-cc-3gpp-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3589 10.17487/RFC3589
RFC3590 Source Address Selection for the Multicast Listener Discovery (MLD) Protocol B. Haberman September 2003 ASCII HTML 6 MLD-IPv6 internet protocol routher packets

It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. [STANDARDS-TRACK]

draft-ietf-magma-mld-source-07 RFC2710 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC3590
RFC3591 Definitions of Managed Objects for the Optical Interface Type H-K. Lam M. Stewart A. Huynh September 2003 ASCII HTML 174 management information base mib snmp simple network management protocol otn optical transport network itu-t performance monitoring configuration dwdm optical tranmission session optical multiplex section optical channel otuk odukt oduk

This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP-based internets. In particular, it defines objects for managing Optical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T Recommendation G.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface. [STANDARDS-TRACK]

draft-ietf-atommib-opticalmib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib http://www.rfc-editor.org/errata_search.php?rfc=3591 10.17487/RFC3591
RFC3592 Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type K. Tesink September 2003 ASCII HTML 73 MIB Management SNMP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. This memo replaces RFC 2558. Changes relative to RFC 2558 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2558bis-01 RFC2558 DRAFT STANDARD DRAFT STANDARD IETF ops atommib http://www.rfc-editor.org/errata_search.php?rfc=3592 10.17487/RFC3592
RFC3593 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals K. Tesink Editor September 2003 ASCII HTML 10 management information base data

This document defines a set of Textual Conventions for MIB modules that make use of performance history data based on 15 minute intervals. This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized in the MIB module's REVISION clause. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2493bis-01 RFC2493 DRAFT STANDARD DRAFT STANDARD IETF ops atommib 10.17487/RFC3593
RFC3594 PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option P. Duffy September 2003 ASCII HTML 7 dynamic host configuration protocol

This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). [STANDARDS-TRACK]

draft-ietf-dhc-pktc-kerb-tckt-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3594
RFC3595 Textual Conventions for IPv6 Flow Label B. Wijnen September 2003 ASCII HTML 6 mib management information base

This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ops-ipv6-flowlabel-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC3595
RFC3596 DNS Extensions to Support IP Version 6 S. Thomson C. Huitema V. Ksinant M. Souissi October 2003 ASCII HTML 8 internet protocol domain name system DNS zone

This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]

draft-ietf-dnsext-rfc1886bis-03 RFC3152 RFC1886 STD0088 INTERNET STANDARD DRAFT STANDARD IETF int dnsext 10.17487/RFC3596
RFC3597 Handling of Unknown DNS Resource Record (RR) Types A. Gustafsson September 2003 ASCII HTML 8 domain name system name server software compression transparency

Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]

draft-ietf-dnsext-unknown-rrs-06 RFC2163 RFC2535 RFC4033 RFC4034 RFC4035 RFC5395 RFC6195 RFC6895 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3597 10.17487/RFC3597
RFC3598 Sieve Email Filtering -- Subaddress Extension K. Murchison September 2003 ASCII HTML 6 users detailed addressing language address part test detail filter mailbox

On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. [STANDARDS-TRACK]

draft-murchison-sieve-subaddress-06 RFC5233 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3598
RFC3599 Request for Comments Summary RFC Numbers 3500-3599 S. Ginoza December 2003 ASCII HTML 34

This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs.

INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3599
RFC3600 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor November 2003 ASCII HTML 50

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of October 2, 2003. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1.

RFC3300 RFC3700 HISTORIC INTERNET STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3600 10.17487/RFC3600
RFC3601 Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses C. Allocchio September 2003 ASCII HTML 10 notations dtmf dual tone multifrequency telephony e-mail addresses urls integrated messaging 3gpp

This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.

draft-allocchio-gstn-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3601
RFC3602 The AES-CBC Cipher Algorithm and Its Use with IPsec S. Frankel R. Glenn S. Kelly September 2003 ASCII HTML 15 ipsec encapsulating security payload

This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

draft-ietf-ipsec-ciph-aes-cbc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3602
RFC3603 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture W. Marshall Editor F. Andreasen Editor October 2003 ASCII HTML 28 network access coordination

In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.

draft-dcsgroup-sipping-proxy-proxy-03 RFC5503 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3603
RFC3604 Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) H. Khosravi G. Kullgren S. Shew J. Sadler A. Watanabe October 2003 ASCII HTML 16 controllers routers formats codes

This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification.

draft-ietf-gsmp-reqs-06 INFORMATIONAL INFORMATIONAL IETF subip gsmp 10.17487/RFC3604
RFC3605 Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) C. Huitema October 2003 ASCII HTML 8 nat network access translation port mapping

The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.

draft-ietf-mmusic-sdp4nat-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=3605 10.17487/RFC3605
RFC3606 Definitions of Supplemental Managed Objects for ATM Interface F. Ly M. Noto A. Smith E. Spiegel K. Tesink November 2003 ASCII HTML 94 asynchronous transfer mode mib management information base

This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, the ATM-MIB, to provide additional support for the management of ATM Switched Virtual Connections (SVCs) and ATM Permanent Virtual Connections (PVCs).

draft-ietf-atommib-atm2-19 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3606
RFC3607 Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool M. Leech September 2003 ASCII HTML 8 security encryption des data standard distributed cryptanalysis computer virus network worm codebreaking

This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences.

draft-leech-chinese-lottery-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3607
RFC3608 Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration D. Willis B. Hoeneisen October 2003 ASCII HTML 17 user agent domain register

This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.

draft-ietf-sip-scvrtdisco-04 RFC5630 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3608
RFC3609 Tracing Requirements for Generic Tunnels R. Bonica K. Kompella D. Meyer September 2003 ASCII HTML 9 traceroute application IP internet protocol

This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding. The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers. Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by an IP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path.

draft-ietf-ccamp-tracereq-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC3609
RFC3610 Counter with CBC-MAC (CCM) D. Whiting R. Housley N. Ferguson September 2003 ASCII HTML 26 authentication encryption security ciphers

Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES).

draft-housley-ccm-mode-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3610
RFC3611 RTP Control Protocol Extended Reports (RTCP XR) T. Friedman Editor R. Caceres Editor A. Clark Editor November 2003 ASCII HTML 55 real time transport protocol packet type sdp session description blocks

This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.

draft-ietf-avt-rtcp-report-extns-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3611 10.17487/RFC3611
RFC3612 Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) A. Farrel September 2003 ASCII HTML 16 mpls fault tolerence high availability multiprotocol label switching cr-ldp high availability restart

This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".

draft-ietf-mpls-ldp-restart-applic-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC3612
RFC3613 Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE) R. Morgan K. Hazelton October 2003 ASCII HTML 8 internet2 middleware

This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE). This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates.

draft-hazelton-mace-urn-namespace-01 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3613
RFC3614 A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG) J. Smith September 2003 ASCII HTML 6 iso international organization standardization multimedia metadata xml classification schemes digital rights management

This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG.

draft-smith-urn-mpeg-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3614
RFC3615 A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging J. Gustin A. Goyens September 2003 ASCII HTML 5 messaging service interface software

This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT.

draft-gustin-goyens-urn-id-02 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3615
RFC3616 A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA) F. Bellifemine I. Constantinescu S. Willmott September 2003 ASCII HTML 8 URN NID Uniform Resource Name Namespace Identification

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the Foundation for Intelligent Physical Agents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology.

draft-bellifemine-urn-fipa-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3616
RFC3617 Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) E. Lear October 2003 ASCII HTML 7

The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time. While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability.

draft-lear-tftp-uri-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3617
RFC3618 Multicast Source Discovery Protocol (MSDP) B. Fenner Editor D. Meyer Editor October 2003 ASCII HTML 19 ipv4 pim-sm independent multicast sparse-mode rp rendezvous point

The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent Multicast Sparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend on RPs in other domains. This document reflects existing MSDP implementations.

draft-ietf-msdp-spec-20 EXPERIMENTAL EXPERIMENTAL IETF rtg msdp http://www.rfc-editor.org/errata_search.php?rfc=3618 10.17487/RFC3618
RFC3619 Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 S. Shah M. Yip October 2003 ASCII HTML 7 ethernet rings robust

This document describes the Ethernet Automatic Protection Switching (EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at a lower cost and with fewer constraints (e.g., ring size).

draft-shah-extreme-eaps-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3619
RFC3620 The TUNNEL Profile D. New October 2003 ASCII HTML 18 beep blocks extensible exchange protocol firewall application layer

This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.

draft-ietf-idwg-beep-tunnel-05 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec idwg 10.17487/RFC3620
RFC3621 Power Ethernet MIB A. Berger D. Romascanu December 2003 ASCII HTML 20 management information base data terminal equipment power dte power sourcing equipment pse

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB with a set of objects for managing Power Sourcing Equipment (PSE).

draft-ietf-hubmib-power-ethernet-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3621
RFC3622 A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project M. Mealling February 2004 ASCII HTML 7 federated network identity

This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity.

draft-mealling-liberty-urn-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3622
RFC3623 Graceful OSPF Restart J. Moy P. Pillay-Esnault A. Lindem November 2003 ASCII HTML 18 open shortest path first non-stop forwarding

This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.

draft-ietf-ospf-hitless-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3623
RFC3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package B. Foster D. Auerbach F. Andreasen November 2003 ASCII HTML 19 call agent endpoints naming conventions

The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.

draft-foster-mgcp-bulkaudits-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3624
RFC3625 The QCP File Format and Media Types for Speech Data R. Gellens H. Garudadri September 2003 ASCII HTML 15 13k qcelp audio multimedia voip real time transport protocol multipurpose internet mail extensions

RFC 2658 specifies the streaming format for 3GPP2 13KK vocoder (High Rate Speech Service Option 17 for Wideband Spread Spectrum Communications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder (EVRC) and Selectable Mode Vocoders (SMV) data. (For example, Eudora(r), QuickTime(r), and cmda2000(r) handsets). This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types for EVRC and SMV (respectively) data stored in this format.

draft-gellens-qcp-01 RFC3555 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3625 10.17487/RFC3625
RFC3626 Optimized Link State Routing Protocol (OLSR) T. Clausen Editor P. Jacquet Editor October 2003 ASCII HTML 75 mobile ad hoc wireless multipoint relays mpr mprs

This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.

draft-ietf-manet-olsr-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=3626 10.17487/RFC3626
RFC3627 Use of /127 Prefix Length Between Routers Considered Harmful P. Savola September 2003 ASCII HTML 6 address space anycast

In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

draft-savola-ipv6-127-prefixlen-04 RFC6547 HISTORIC INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3627 10.17487/RFC3627
RFC3628 Policy Requirements for Time-Stamping Authorities (TSAs) D. Pinkas N. Pope J. Ross November 2003 ASCII HTML 43 tokens public key certificates

This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document.

draft-ietf-pkix-pr-tsa-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3628
RFC3629 UTF-8, a transformation format of ISO 10646 F. Yergeau November 2003 ASCII HTML 14 UTF-8 UCS Transformation Format

ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.

draft-yergeau-rfc2279bis-05 RFC2279 STD0063 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC3629
RFC3630 Traffic Engineering (TE) Extensions to OSPF Version 2 D. Katz K. Kompella D. Yeung September 2003 ASCII HTML 14 open-shortest path first ink state advertisement

This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.

draft-katz-yeung-ospf-traffic-10 RFC2370 RFC4203 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3630
RFC3631 Security Mechanisms for the Internet S. Bellovin Editor J. Schiller Editor C. Kaufman Editor December 2003 ASCII HTML 20 protocol host compromise dos denial of service

Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself. However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

draft-iab-secmech-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3631
RFC3632 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 S. Hollenbeck S. Veeramachaneni S. Yalamanchilli November 2003 ASCII HTML 8 RRP shared registration system gLTD ccTLD top level domain

This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.

draft-hollenbeck-rfc2832bis-02 RFC2832 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3632
RFC3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 O. Troan R. Droms December 2003 ASCII HTML 19 automated delegation router

The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP). This mechanism is intended for delegating a long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.

draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 RFC8415 RFC6603 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3633 10.17487/RFC3633
RFC3634 Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option K. Luehrs R. Woundy J. Bevilacqua N. Davoust December 2003 ASCII HTML 7

This document defines a new sub-option for the CableLabs Client Configuration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center (KDC) servers.

draft-ietf-dhc-suboptions-kdc-serveraddress-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3634
RFC3635 Definitions of Managed Objects for the Ethernet-like Interface Types J. Flick September 2003 ASCII HTML 64 MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.

draft-ietf-hubmib-etherif-mib-v3-03 RFC2665 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3635
RFC3636 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) J. Flick September 2003 ASCII HTML 62 MAU-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.

draft-ietf-hubmib-mau-mib-v3-04 RFC2668 RFC1515 RFC4836 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3636
RFC3637 Definitions of Managed Objects for the Ethernet WAN Interface Sublayer C.M. Heard Editor September 2003 ASCII HTML 37 mib management information base

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.

draft-ietf-hubmib-wis-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC3637
RFC3638 Applicability Statement for Reclassification of RFC 1643 to Historic Status J. Flick C. M. Heard September 2003 ASCII HTML 5 ETHER-MIB MIB Network Management SNMP Ethernet

This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation.

draft-ietf-hubmib-1643-to-historic-01 RFC1643 INFORMATIONAL INFORMATIONAL IETF ops hubmib 10.17487/RFC3638
RFC3639 Considerations on the use of a Service Identifier in Packet Headers M. St. Johns Editor G. Huston Editor IAB October 2003 ASCII HTML 8 port fields protocol number

This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number.

draft-iab-service-id-considerations-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3639
RFC3640 RTP Payload Format for Transport of MPEG-4 Elementary Streams J. van der Meer D. Mackie V. Swaminathan D. Singer P. Gentric November 2003 ASCII HTML 43 real time transport protocol audio video streams

The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream.

draft-ietf-avt-mpeg4-simple-08 RFC5691 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3640
RFC3641 Generic String Encoding Rules (GSER) for ASN.1 Types S. Legg October 2003 ASCII HTML 16 asn.1 abstract syntax notation

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.

draft-legg-ldap-gser-04 RFC4792 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3641
RFC3642 Common Elements of Generic String Encoding Rules (GSER) Encodings S. Legg October 2003 ASCII HTML 13 asn.1 abstract syntax notation

The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.

draft-legg-ldap-gser-abnf-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3642 10.17487/RFC3642
RFC3643 Fibre Channel (FC) Frame Encapsulation R. Weber M. Rajagopal F. Travostino M. O'Donnell C. Monia M. Merhar December 2003 ASCII HTML 20 ips ip storage frame header

This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.

draft-ietf-ips-fcencapsulation-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3643
RFC3644 Policy Quality of Service (QoS) Information Model Y. Snir Y. Ramberg J. Strassner R. Cohen B. Moore November 2003 ASCII HTML 73 integrated differentiated object oriented

This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.

draft-ietf-policy-qos-info-model-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3644
RFC3645 Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) S. Kwan P. Garg J. Gilroy L. Esibov J. Westhead R. Hall October 2003 ASCII HTML 26 TSIG domain name system transaction signature

The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.

draft-ietf-dnsext-gss-tsig-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3645
RFC3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) R. Droms Editor December 2003 ASCII HTML 7 domain name system service server client

This document describes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.

draft-ietf-dhc-dhcpv6-opt-dnsconfig-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3646
RFC3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework S. Chokhani W. Ford R. Sabett C. Merrill S. Wu November 2003 ASCII HTML 94 pkix encryption security authentication

This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.

draft-ietf-pkix-ipki-new-rfc2527-02 RFC2527 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3647 10.17487/RFC3647
RFC3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol J. Whitehead J. Reschke Editor December 2003 ASCII HTML 30 server client semantics ordering orderpatch method position header ordering-type header

This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.

draft-ietf-webdav-ordering-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC3648
RFC3649 HighSpeed TCP for Large Congestion Windows S. Floyd December 2003 ASCII HTML 34 transmission control protocol round-trip rate packet

The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.

draft-ietf-tsvwg-highspeed-01 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3649
RFC3650 Handle System Overview S. Sun L. Lannom B. Boesch November 2003 ASCII HTML 21 name service

This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. The Handle System is a general-purpose global name service that allows secured name resolution and administration over networks such as the Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources.

draft-sun-handle-system-12 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3650 10.17487/RFC3650
RFC3651 Handle System Namespace and Service Definition S. Sun S. Reilly L. Lannom November 2003 ASCII HTML 41 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document provides a detailed description of the Handle System namespace, and its data, service, and operation models. The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by the Handle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol.

draft-sun-handle-system-def-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3651 10.17487/RFC3651
RFC3652 Handle System Protocol (ver 2.1) Specification S. Sun S. Reilly L. Lannom J. Petrone November 2003 ASCII HTML 53 name service

The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.

draft-sun-handle-system-protocol-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3652
RFC3653 XML-Signature XPath Filter 2.0 J. Boyer M. Hughes J. Reagle December 2003 ASCII HTML 15 extensible markup language digital signature

XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles. This document is the W3C XML Signature XPath-Filter 2.0 Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

draft-ietf-xmldsig-xpf2-01 INFORMATIONAL INFORMATIONAL IETF sec xmldsig 10.17487/RFC3653
RFC3654 Requirements for Separation of IP Control and Forwarding H. Khosravi Editor T. Anderson Editor November 2003 ASCII HTML 18 forces forwarding control element separation data

This document introduces the Forwarding and Control Element Separation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device.

draft-ietf-forces-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC3654
RFC3655 Redefinition of DNS Authenticated Data (AD) bit B. Wellington O. Gudmundsson November 2003 ASCII HTML 8 DNS-SECEXT dns authentication

This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.

draft-ietf-dnsext-ad-is-secure-06 RFC4033 RFC4034 RFC4035 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3655
RFC3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol R. Siemborski December 2003 ASCII HTML 19 imap pop3 post office protocol internet message access

As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery. The Mailbox Update (MUPDATE) protocol allows a group of Internet Message Access Protocol (IMAP) or Post Office Protocol - Version 3 (POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.

draft-siemborski-mupdate-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3656
RFC3657 Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS) S. Moriai A. Kato January 2004 ASCII HTML 14 security mail content key

This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

draft-ietf-smime-camellia-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3657
RFC3658 Delegation Signer (DS) Resource Record (RR) O. Gudmundsson December 2003 ASCII HTML 19 zone cut zone key security dns domain name system

The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.

draft-ietf-dnsext-delegation-signer-15 RFC4033 RFC4034 RFC4035 RFC3090 RFC3008 RFC2535 RFC1035 RFC3755 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3658
RFC3659 Extensions to FTP P. Hethmon March 2007 ASCII HTML 61 FTP file transfer protocol stream mode data transfer storage

This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS-TRACK]

draft-ietf-ftpext-mlst-16 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF app ftpext http://www.rfc-editor.org/errata_search.php?rfc=3659 10.17487/RFC3659
RFC3660 Basic Media Gateway Control Protocol (MGCP) Packages B. Foster F. Andreasen December 2003 ASCII HTML 64 generic line trunk handset dtmf dual tone multifrequency

This document provides a basic set of Media Gateway Control Protocol (MGCP) packages. The generic, line, trunk, handset, RTP, DTMF (Dual Tone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages.

draft-foster-mgcp-basic-packages-10 RFC2705 INFORMATIONAL INFORMATIONAL Legacy 10.17487/RFC3660
RFC3661 Media Gateway Control Protocol (MGCP) Return Code Usage B. Foster C. Sivachelvan December 2003 ASCII HTML 24 guidelines call agent implementation

This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP) Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that the Call Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency.

draft-foster-mgcp-returncodes-03 RFC3435 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3661
RFC3662 A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services R. Bless K. Nichols K. Wehrle December 2003 ASCII HTML 17 traffic network ds le

This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.

draft-bless-diffserv-pdb-le-01 RFC8622 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3662
RFC3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) A. Newton December 2003 ASCII HTML 21 referral types well-known

Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.

draft-newton-ldap-whois-03 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3663
RFC3664 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman January 2004 ASCII HTML 4 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128.

draft-ietf-ipsec-aes-xcbc-prf-01 RFC4434 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3664
RFC3665 Session Initiation Protocol (SIP) Basic Call Flow Examples A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII HTML 94 user agent client proxy redirect

This document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.

draft-ietf-sipping-basic-call-flows-02 BCP0075 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3665 10.17487/RFC3665
RFC3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows A. Johnston S. Donovan R. Sparks C. Cunningham K. Summers December 2003 ASCII HTML 118 user proxy gateway telephony

This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.

draft-ietf-sipping-pstn-call-flows-02 BCP0076 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3666 10.17487/RFC3666
RFC3667 IETF Rights in Contributions S. Bradner February 2004 ASCII HTML 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-submission-rights-08 RFC3978 RFC2026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3667
RFC3668 Intellectual Property Rights in IETF Technology S. Bradner February 2004 ASCII HTML 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-technology-rights-12 RFC3979 RFC2026 RFC2028 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3668
RFC3669 Guidelines for Working Groups on Intellectual Property Issues S. Brim February 2004 ASCII HTML 17 ipr copyright

This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. This memo provides information for the Internet community.

draft-ietf-ipr-wg-guidelines-05 INFORMATIONAL INFORMATIONAL IETF gen ipr 10.17487/RFC3669
RFC3670 Information Model for Describing Network Device QoS Datapath Mechanisms B. Moore D. Durham J. Strassner A. Westerinen W. Weiss January 2004 ASCII HTML 97 quality of service host netowrk devices traffic

The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model (QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository

draft-ietf-policy-qos-device-info-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3670
RFC3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 10 x.500 information model schema

X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP.

draft-zeilenga-ldap-collective-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3671
RFC3672 Subentries in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 12 special subtree

In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).

draft-zeilenga-ldap-subentry-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3672
RFC3673 Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes K. Zeilenga December 2003 ASCII HTML 5 user mechanisms extension

The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.

draft-zeilenga-ldap-opattrs-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3673
RFC3674 Feature Discovery in Lightweight Directory Access Protocol (LDAP) K. Zeilenga December 2003 ASCII HTML 5 elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.

draft-zeilenga-ldap-features-05 RFC4512 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3674
RFC3675 .sex Considered Dangerous D. Eastlake 3rd February 2004 ASCII HTML 22 top level domains tld ip addresses internet protocol filters

Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view.

draft-eastlake-xxx-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3675
RFC3676 The Text/Plain Format and DelSp Parameters R. Gellens February 2004 ASCII HTML 20 media type mime multipurpose internet mail extension

This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely. [STANDARDS-TRACK]

draft-gellens-format-bis-04 RFC2646 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3676
RFC3677 IETF ISOC Board of Trustee Appointment Procedures L. Daigle Editor Internet Architecture Board December 2003 ASCII HTML 7 internet society bot engineering task force

This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.

draft-iab-isocbot-01 BCP0077 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=3677 10.17487/RFC3677
RFC3678 Socket Interface Extensions for Multicast Source Filters D. Thaler B. Fenner B. Quinn January 2004 ASCII HTML 18 ip internet protocol application program interface apis input output

The Internet Group Management Protocol (IGMPv3) for IPv4 and the Multicast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications.

draft-ietf-magma-msf-api-05 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3678 10.17487/RFC3678
RFC3679 Unused Dynamic Host Configuration Protocol (DHCP) Option Codes R. Droms January 2004 ASCII HTML 8 dynamic host configuration protocol internet assigned numbers authority

Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic Host Configuration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options.

draft-ietf-dhc-unused-optioncodes-07 RFC8910 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC3679
RFC3680 A Session Initiation Protocol (SIP) Event Package for Registrations J. Rosenberg March 2004 ASCII HTML 26 REGISTER event package name event package parameters

This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. [STANDARDS-TRACK]

draft-ietf-sipping-reg-event-00 RFC6140 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3680 10.17487/RFC3680
RFC3681 Delegation of E.F.F.3.IP6.ARPA R. Bush R. Fink January 2004 ASCII HTML 4 dns domain name system

This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.

draft-ymbk-6bone-arpa-delegation-01 BCP0080 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3681
RFC3682 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer February 2004 ASCII HTML 11 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. This memo defines an Experimental Protocol for the Internet community.

draft-gill-gtsh-04 RFC5082 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3682
RFC3683 A Practice for Revoking Posting Rights to IETF Mailing Lists M. Rose March 2004 ASCII HTML 13

All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-mrose-ietf-posting-04 BCP0083 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3683
RFC3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) R. Ogier F. Templin M. Lewis February 2004 ASCII HTML 46 proactive routing ad-hoc networks neighbor discovery link-state routing mobile ad-hoc network mobile mesh network packet radio network wireless communications

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-manet-tbrpf-11 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC3684
RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions C. Daboo February 2004 ASCII HTML 9 messages portable commands

The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests. [PROPOSED STANDARD]

draft-daboo-sieve-spamtest-04 RFC5235 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3685
RFC3686 Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) R. Housley January 2004 ASCII HTML 19 authentication vector cipher block

This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.

draft-ietf-ipsec-ciph-aes-ctr-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3686
RFC3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules S. Legg February 2004 ASCII HTML 42 syntax data schema

The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. [PROPOSED STANDARD]

draft-legg-ldapext-component-matching-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3687
RFC3688 The IETF XML Registry M. Mealling January 2004 ASCII HTML 8 extensible markup language

This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.

draft-mealling-iana-xmlns-registry-05 BCP0081 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3688
RFC3689 General Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII HTML 10

This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). This memo provides information for the Internet community.

draft-ietf-ieprep-ets-general-04 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3689
RFC3690 IP Telephony Requirements for Emergency Telecommunication Service (ETS) K. Carlberg R. Atkinson February 2004 ASCII HTML 7

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

draft-ietf-ieprep-ets-telephony-07 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC3690
RFC3691 Internet Message Access Protocol (IMAP) UNSELECT command A. Melnikov February 2004 ASCII HTML 5 mailbox session client

This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version 4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable. [STANDARDS-TRACK]

draft-melnikov-imap-unselect-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3691
RFC3692 Assigning Experimental and Testing Numbers Considered Useful T. Narten January 2004 ASCII HTML 7 iana internet assigned numbers authority values implementations

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.

draft-narten-iana-experimental-allocations-05 RFC2434 BCP0082 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3692
RFC3693 Geopriv Requirements J. Cuellar J. Morris D. Mulligan J. Peterson J. Polk February 2004 ASCII HTML 30 security privacy lo location object

Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. This memo provides information for the Internet community.

draft-ietf-geopriv-reqs-04 RFC6280 RFC7459 INFORMATIONAL INFORMATIONAL IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=3693 10.17487/RFC3693
RFC3694 Threat Analysis of the Geopriv Protocol M. Danley D. Mulligan J. Morris J. Peterson February 2004 ASCII HTML 18 privacy security data information

This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. This memo provides information for the Internet community.

draft-ietf-geopriv-threat-analysis-01 RFC6280 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC3694
RFC3695 Compact Forward Error Correction (FEC) Schemes M. Luby L. Vicisano February 2004 ASCII HTML 13 content stream delivery multicast internet protocol

This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead. This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-fec-supp-compact-01 RFC5445 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3695
RFC3696 Application Techniques for Checking and Transformation of Names J. Klensin February 2004 ASCII HTML 16 top-level domains tlds

Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. This memo provides information for the Internet community.

draft-klensin-name-filters-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3696 10.17487/RFC3696
RFC3697 IPv6 Flow Label Specification J. Rajahalme A. Conta B. Carpenter S. Deering March 2004 ASCII HTML 9 nodes packets

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

draft-ietf-ipv6-flow-label-09 RFC6437 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3697
RFC3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules K. Zeilenga Editor February 2004 ASCII HTML 9 lightweight directory access protocol directory services

This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. [STANDARDS-TRACK]

draft-zeilenga-ldap-user-schema-mr-00 RFC2798 RFC4517 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3698
RFC3699 RFC3700 Internet Official Protocol Standards J. Reynolds Editor S. Ginoza Editor July 2004 ASCII HTML 54

This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. [STANDARDS-TRACK]

RFC3600 RFC5000 HISTORIC INTERNET STANDARD INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3700 10.17487/RFC3700
RFC3701 6bone (IPv6 Testing Address Allocation) Phaseout R. Fink R. Hinden March 2004 ASCII HTML 6 internet protocol protocotype software architecture

The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document obsoletes RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic. This memo provides information for the Internet community.

draft-fink-6bone-phaseout-04 RFC2471 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3701
RFC3702 Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) J. Loughney G. Camarillo February 2004 ASCII HTML 15

As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. This memo provides information for the Internet community.

draft-ietf-sipping-aaa-req-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3702
RFC3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema J. Strassner B. Moore R. Moats E. Ellesson February 2004 ASCII HTML 61 mapping classes

This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. [STANDARDS-TRACK]

draft-ietf-policy-core-schema-16 RFC4104 PROPOSED STANDARD PROPOSED STANDARD IETF ops policy 10.17487/RFC3703
RFC3704 Ingress Filtering for Multihomed Networks F. Baker P. Savola March 2004 ASCII HTML 16 ISP Internet Service Provider Internet Protocol DOS

BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-savola-bcp38-multihoming-update-03 RFC2827 RFC8704 BCP0084 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3704
RFC3705 High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals B. Ray R. Abbi February 2004 ASCII HTML 11 management information base

This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. [STANDARDS-TRACK]

draft-ietf-adslmib-hc-tc-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC3705
RFC3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers G. Huang S. Beaulieu D. Rochefort February 2004 ASCII HTML 13 security authentication dead peer detection dpd keepalive

This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. This memo provides information for the Internet community.

draft-ietf-ipsec-dpd-04 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3706 10.17487/RFC3706
RFC3707 Cross Registry Internet Service Protocol (CRISP) Requirements A. Newton February 2004 ASCII HTML 26 directory services domain

Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. This memo provides information for the Internet community.

draft-ietf-crisp-requirements-06 INFORMATIONAL INFORMATIONAL IETF app crisp 10.17487/RFC3707
RFC3708 Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions E. Blanton M. Allman February 2004 ASCII HTML 9

TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-dsack-use-02 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC3708
RFC3709 Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates S. Santesson R. Housley T. Freeman February 2004 ASCII HTML 21 authentication security identification

This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]

draft-ietf-pkix-logotypes-13 RFC6170 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3709 10.17487/RFC3709
RFC3710 An IESG charter H. Alvestrand February 2004 ASCII HTML 12 internet engineering steering group

This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.

draft-iesg-charter-03 RFC3932 RFC5742 RFC8717 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC3710
RFC3711 The Secure Real-time Transport Protocol (SRTP) M. Baugher D. McGrew M. Naslund E. Carrara K. Norrman March 2004 ASCII HTML 56 authentication traffic cryptographic

This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

draft-ietf-avt-srtp-09 RFC5506 RFC6904 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=3711 10.17487/RFC3711
RFC3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald February 2004 ASCII HTML 33 object classes attributes

This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). This memo provides information for the Internet community.

draft-fleming-ldap-printer-schema-02 RFC7612 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3712 10.17487/RFC3712
RFC3713 A Description of the Camellia Encryption Algorithm M. Matsui J. Nakajima S. Moriai April 2004 ASCII HTML 15 security key cryptographic

This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.

draft-nakajima-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3713
RFC3714 IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet S. Floyd Editor J. Kempf Editor March 2004 ASCII HTML 32 end-to-end qos qualify of service voip internet protocol

This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet. These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service (QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice over Internet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in the Internet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. This memo provides information for the Internet community.

draft-iab-congestion-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3714
RFC3715 IPsec-Network Address Translation (NAT) Compatibility Requirements B. Aboba W. Dixon March 2004 ASCII HTML 18 virtual private networks vpns intranet

This document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.

draft-ietf-ipsec-nat-reqts-06 INFORMATIONAL INFORMATIONAL IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3715 10.17487/RFC3715
RFC3716 IETF in the Large: Administration and Execution IAB Advisory Committee March 2004 ASCII HTML 40

In the fall of 2003, the IETF Chair and the IAB Chair formed an IAB Advisory Committee (AdvComm), with a mandate to review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF. The AdvComm mandate did not include the standards process itself. This memo provides information for the Internet community.

draft-iab-advcomm-01 HISTORIC INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=3716 10.17487/RFC3716
RFC3717 IP over Optical Networks: A Framework B. Rajagopalan J. Luciani D. Awduche March 2004 ASCII HTML 48 transport infrastructure routers high-speed

The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). This memo provides information for the Internet community.

draft-ietf-ipo-framework-05 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC3717
RFC3718 A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access R. McGowan February 2004 ASCII HTML 11

This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.

draft-rmcgowan-unicode-procs-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3718
RFC3719 Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor February 2004 ASCII HTML 15 routing routeing interior gateway protocol igp conformance ip traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. This memo provides information for the Internet community.

draft-ietf-isis-iso-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3719
RFC3720 Internet Small Computer Systems Interface (iSCSI) J. Satran K. Meth C. Sapuntzakis M. Chadalapaka E. Zeidner April 2004 ASCII HTML 257 transport protocol tcp transmission control protocol

This document describes a transport protocol for Internet Small Computer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-20 RFC7143 RFC3980 RFC4850 RFC5048 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3720 10.17487/RFC3720
RFC3721 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery M. Bakke J. Hafner J. Hufferd K. Voruganti M. Krueger April 2004 ASCII HTML 22 targets environments scalibilty target initiator scsi device name

This document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. This memo provides information for the Internet community.

draft-ietf-ips-iscsi-name-disc-10 RFC7143 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC3721
RFC3722 String Profile for Internet Small Computer Systems Interface (iSCSI) Names M. Bakke April 2004 ASCII HTML 8 transport unique global

This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network. The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-string-prep-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3722
RFC3723 Securing Block Storage Protocols over IP B. Aboba J. Tseng J. Walker V. Rangan F. Travostino April 2004 ASCII HTML 70 internet threat models performance security

This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. [STANDARDS-TRACK]

draft-ietf-ips-security-19 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3723
RFC3724 The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture J. Kempf Editor R. Austein Editor IAB March 2004 ASCII HTML 14 architectural guideline

The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.

draft-iab-e2e-futures-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3724
RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) J. Rosenberg J. Peterson H. Schulzrinne G. Camarillo April 2004 ASCII HTML 31

Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-3pcc-06 BCP0085 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC3725
RFC3726 Requirements for Signaling Protocols M. Brunner Editor April 2004 ASCII HTML 42 rsvp resource reservation protocol middleboxes nsis

This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined. For example, signaling for label distribution in Multiprotocol Label Switching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. This memo provides information for the Internet community.

draft-ietf-nsis-req-09 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC3726
RFC3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules S. Legg February 2004 ASCII HTML 5 lightweight directory access protocol

This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]

draft-legg-ldap-cmr-module-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3727
RFC3728 Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) B. Ray R. Abbi February 2004 ASCII HTML 76 management information base mib

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High Speed Digital Subscriber Line (VDSL) interfaces. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=3728 10.17487/RFC3728
RFC3729 Application Performance Measurement MIB S. Waldbusser March 2004 ASCII HTML 61

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for measuring the application performance as experienced by end-users. [STANDARDS-TRACK]

draft-ietf-rmonmib-apm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3729
RFC3730 Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII HTML 69 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. [STANDARDS-TRACK]

draft-ietf-provreg-epp-09 RFC4930 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3730 10.17487/RFC3730
RFC3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck March 2004 ASCII HTML 45 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. [STANDARDS-TRACK]

draft-ietf-provreg-epp-domain-07 RFC4931 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3731
RFC3732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck March 2004 ASCII HTML 28 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. [STANDARDS-TRACK]

draft-ietf-provreg-epp-host-07 RFC4932 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3732
RFC3733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck March 2004 ASCII HTML 41 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. [STANDARDS-TRACK]

draft-ietf-provreg-epp-contact-07 RFC4933 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg http://www.rfc-editor.org/errata_search.php?rfc=3733 10.17487/RFC3733
RFC3734 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck March 2004 ASCII HTML 9 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. [STANDARDS-TRACK]

draft-ietf-provreg-epp-tcp-06 RFC4934 PROPOSED STANDARD PROPOSED STANDARD IETF app provreg 10.17487/RFC3734
RFC3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP) S. Hollenbeck March 2004 ASCII HTML 13

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. This memo provides information for the Internet community.

draft-ietf-provreg-epp-ext-03 INFORMATIONAL INFORMATIONAL IETF app provreg 10.17487/RFC3735
RFC3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 R. Droms April 2004 ASCII HTML 9

Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-stateless-04 RFC8415 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3736 10.17487/RFC3736
RFC3737 IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules B. Wijnen A. Bierman April 2004 ASCII HTML 7 management information base internet assigned numbers authority

This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring (rmon) root. This memo also documents the currently assigned values. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmon-oid-assignments-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC3737
RFC3738 Wave and Equation Based Rate Control (WEBRC) Building Block M. Luby V. Goyal April 2004 ASCII HTML 32 congestion control data delivery multicast ip internet protocol

This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender. Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-webrc-04 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3738
RFC3739 Internet X.509 Public Key Infrastructure: Qualified Certificates Profile S. Santesson M. Nystrom T. Polk March 2004 ASCII HTML 34 syntax

This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]

draft-ietf-pkix-sonof3039-06 RFC3039 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3739 10.17487/RFC3739
RFC3740 The Multicast Group Security Architecture T. Hardjono B. Weis March 2004 ASCII HTML 26 data packets

This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. This memo provides information for the Internet community.

draft-ietf-msec-arch-05 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC3740
RFC3741 Exclusive XML Canonicalization, Version 1.0 J. Boyer D. Eastlake 3rd J. Reagle March 2004 ASCII HTML 16 extensible markup language namespace

Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the "xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. This memo provides information for the Internet community.

draft-ietf-xmldsig-xc14n-02 INFORMATIONAL INFORMATIONAL IETF sec xmldsig http://www.rfc-editor.org/errata_search.php?rfc=3741 10.17487/RFC3741
RFC3742 Limited Slow-Start for TCP with Large Congestion Windows S. Floyd March 2004 ASCII HTML 7 transmission control protocol

This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-slowstart-00 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3742 10.17487/RFC3742
RFC3743 Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean K. Konishi K. Huang H. Qian Y. Ko April 2004 ASCII HTML 33

Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration. The IETF Standards for Internationalized Domain Names, known as "IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. This memo provides information for the Internet community.

draft-jseng-idn-admin-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3743 10.17487/RFC3743
RFC3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol G. Clemm J. Reschke E. Sedlar J. Whitehead May 2004 ASCII HTML 72

This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. [STANDARDS-TRACK]

draft-ietf-webdav-acl-13 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=3744 10.17487/RFC3744
RFC3745 MIME Type Registrations for JPEG 2000 (ISO/IEC 15444) D. Singer R. Clark D. Lee April 2004 ASCII HTML 14 multipurpose internet mail extensions joint photographic experts group

This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG 2000 (Joint Photographic Experts Group). [STANDARDS-TRACK]

draft-singer-jp2-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3745
RFC3746 Forwarding and Control Element Separation (ForCES) Framework L. Yang R. Dantu T. Anderson R. Gopal April 2004 ASCII HTML 40 network elements

This document defines the architectural framework for the ForCES (Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. This is memo provides information for the Internet community.

draft-ietf-forces-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=3746 10.17487/RFC3746
RFC3747 The Differentiated Services Configuration MIB H. Hazewinkel Editor D. Partain Editor April 2004 ASCII HTML 24 management information base diffserv

This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. [PROPOSED STANDARD]

draft-ietf-snmpconf-diffpolicy-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC3747
RFC3748 Extensible Authentication Protocol (EAP) B. Aboba L. Blunk J. Vollbrecht J. Carlson H. Levkowetz Editor June 2004 ASCII HTML 67 PPP-EAP data link layers ppp point-to-point ieee 802

This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]

draft-ietf-eap-rfc2284bis-09 RFC2284 RFC5247 RFC7057 PROPOSED STANDARD PROPOSED STANDARD IETF int eap http://www.rfc-editor.org/errata_search.php?rfc=3748 10.17487/RFC3748
RFC3749 Transport Layer Security Protocol Compression Methods S. Hollenbeck May 2004 ASCII HTML 8 tls lossless data compression handshake protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use with TLS, and it describes a method for the specification of additional TLS compression methods. [STANDARDS-TRACK]

draft-ietf-tls-compression-07 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC3749
RFC3750 Unmanaged Networks IPv6 Transition Scenarios C. Huitema R. Austein S. Satapati R. van der Pol April 2004 ASCII HTML 20 single subnet gateway isp internet service provider

This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. This memo provides information for the Internet community.

draft-ietf-v6ops-unman-scenarios-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3750
RFC3751 Omniscience Protocol Requirements S. Bradner April 1 2004 ASCII HTML 9

There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. This memo provides information for the Internet community.

draft-bradner-op-req-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3751
RFC3752 Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios A. Barbir E. Burger R. Chen S. McHenry H. Orman R. Penno April 2004 ASCII HTML 14 application data services

This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. This memo provides information for the Internet community.

draft-ietf-opes-scenarios-01 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3752
RFC3753 Mobility Related Terminology J. Manner Editor M. Kojo Editor June 2004 ASCII HTML 36 networks ip internet protocol

There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.

draft-ietf-seamoby-mobility-terminology-06 INFORMATIONAL INFORMATIONAL IETF tsv seamoby 10.17487/RFC3753
RFC3754 IP Multicast in Differentiated Services (DS) Networks R. Bless K. Wehrle April 2004 ASCII HTML 34 internet protocol

This document discusses the problems of IP Multicast use in Differentiated Services (DS) networks, expanding on the discussion in RFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. This memo provides information for the Internet community.

draft-bless-diffserv-multicast-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3754
RFC3755 Legacy Resolver Compatibility for Delegation Signer (DS) S. Weiler May 2004 ASCII HTML 9 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-2535typecode-change-06 RFC4033 RFC4034 RFC4035 RFC3658 RFC2535 RFC3757 RFC3845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3755
RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats P. Nikander Editor J. Kempf E. Nordmark May 2004 ASCII HTML 23 authentication security key management

The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.

draft-ietf-send-psreq-04 INFORMATIONAL INFORMATIONAL IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3756 10.17487/RFC3756
RFC3757 Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag O. Kolkman J. Schlyter E. Lewis April 2004 ASCII HTML 8 dnssec

With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755. [STANDARDS-TRACK]

draft-ietf-dnsext-keyrr-key-signing-flag-12 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=3757 10.17487/RFC3757
RFC3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension R. Stewart M. Ramalho Q. Xie M. Tuexen P. Conrad May 2004 ASCII HTML 22 init init ack forward tsn

This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. [STANDARDS-TRACK]

draft-ietf-tsvwg-prsctp-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3758
RFC3759 RObust Header Compression (ROHC): Terminology and Channel Mapping Examples L-E. Jonsson April 2004 ASCII HTML 20 encapsulating security payload real-time transport protocol user datagram

This document aims to clarify terms and concepts presented in RFC 3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. This memo provides information for the Internet community.

draft-ietf-rohc-terminology-and-examples-02 RFC3095 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC3759
RFC3760 Securely Available Credentials (SACRED) - Credential Server Framework D. Gustafson M. Just M. Nystrom April 2004 ASCII HTML 22

As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. This memo provides information for the Internet community.

draft-ietf-sacred-framework-07 INFORMATIONAL INFORMATIONAL IETF sec sacred 10.17487/RFC3760
RFC3761 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) P. Faltstrom M. Mealling April 2004 ASCII HTML 18 domain name system

This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS-TRACK]

draft-ietf-enum-rfc2916bis-07 RFC2916 RFC6116 RFC6117 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3761
RFC3762 Telephone Number Mapping (ENUM) Service Registration for H.323 O. Levin April 2004 ASCII HTML 5 multimedia packet based network

The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-h323-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3762
RFC3763 One-way Active Measurement Protocol (OWAMP) Requirements S. Shalunov B. Teitelbaum April 2004 ASCII HTML 11 performance metrics delay unidirectional

With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This memo provides information for the Internet community.

draft-ietf-ippm-owdp-reqs-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC3763
RFC3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record J. Peterson April 2004 ASCII HTML 8 aor electronic number

This document registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. [STANDARDS-TRACK]

draft-ietf-enum-sip-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3764
RFC3765 NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control G. Huston April 2004 ASCII HTML 7 peer connections propagated

This document describes the use of a scope control Border Gateway Protocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. This memo provides information for the Internet community.

draft-ietf-ptomaine-nopeer-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3765
RFC3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys H. Orman P. Hoffman April 2004 ASCII HTML 23 security cryptography algorithms integers

Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-orman-public-key-lengths-08 BCP0086 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3766
RFC3767 Securely Available Credentials Protocol S. Farrell Editor June 2004 ASCII HTML 25 beep blocks extensible exchange protocol xml extensible mark up language

This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). [STANDARDS-TRACK]

draft-ietf-sacred-protocol-bss-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacred 10.17487/RFC3767
RFC3768 Virtual Router Redundancy Protocol (VRRP) R. Hinden Editor April 2004 ASCII HTML 27 VRRP vrrp lan local area network ip internet protocol

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. [STANDARDS-TRACK]

draft-ietf-vrrp-spec-v2-10 RFC2338 RFC5798 DRAFT STANDARD DRAFT STANDARD IETF rtg vrrp 10.17487/RFC3768
RFC3769 Requirements for IPv6 Prefix Delegation S. Miyakawa R. Droms June 2004 ASCII HTML 6 internet protocol version 6

This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). This memo provides information for the Internet community.

draft-ietf-ipv6-prefix-delegation-requirement-04 INFORMATIONAL INFORMATIONAL IETF int ipv6 10.17487/RFC3769
RFC3770 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore May 2004 ASCII HTML 9 ssid system service identifiers eap

This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). [STANDARDS-TRACK]

draft-ietf-pkix-wlan-extns-05 RFC4334 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3770 10.17487/RFC3770
RFC3771 The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message R. Harrison K. Zeilenga April 2004 ASCII HTML 8 LDAPv3 LDAv3 x.500

This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). The IntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAP ExtendedRequest and ExtendedResponse to define new single-request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. [STANDARDS-TRACK]

draft-rharrison-ldap-intermediate-resp-01 RFC4511 RFC4510 RFC2251 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3771
RFC3772 Point-to-Point Protocol (PPP) Vendor Protocol J. Carlson R. Winslow May 2004 ASCII HTML 10 link control protocol lcp

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor-specific Network, Authentication, and Control Protocols. [STANDARDS-TRACK]

draft-ietf-pppext-vendor-protocol-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pppext 10.17487/RFC3772
RFC3773 High-Level Requirements for Internet Voice Mail E. Candell June 2004 ASCII HTML 9 ivm internet voice messaging voice profile for internet mail vpim

This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2. This memo provides information for the Internet community.

draft-ietf-vpim-ivm-goals-06 INFORMATIONAL INFORMATIONAL IETF app vpim 10.17487/RFC3773
RFC3774 IETF Problem Statement E. Davies Editor May 2004 ASCII HTML 22 ietf process problem analysis

This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. This memo provides information for the Internet community.

draft-ietf-problem-issue-statement-05 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3774
RFC3775 Mobility Support in IPv6 D. Johnson C. Perkins J. Arkko June 2004 ASCII HTML 165 internet protocol nodes

This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. [STANDARDS-TRACK]

draft-ietf-mobileip-ipv6-24 RFC6275 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3775
RFC3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents J. Arkko V. Devarapalli F. Dupont June 2004 ASCII HTML 40 security internet protocol

Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. [STANDARDS-TRACK]

draft-ietf-mobileip-mipv6-ha-ipsec-06 RFC4877 PROPOSED STANDARD PROPOSED STANDARD IETF int mobileip 10.17487/RFC3776
RFC3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees J. Galvin Editor June 2004 ASCII HTML 34 Internet Architecture Board Engineering Steering Group

The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self-consistent, organized compilation of the process as it was known at the time of publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-nomcom-rfc2727bis-09 RFC2727 RFC7437 RFC5078 RFC5633 RFC5680 RFC6859 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen nomcom http://www.rfc-editor.org/errata_search.php?rfc=3777 10.17487/RFC3777
RFC3778 The application/pdf Media Type E. Taft J. Pravetz S. Zilles L. Masinter May 2004 ASCII HTML 14 portable document format document exchange digital signatures

PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of the PDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. This memo provides information for the Internet community.

draft-zilles-pdf-03 RFC8118 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3778
RFC3779 X.509 Extensions for IP Addresses and AS Identifiers C. Lynn S. Kent K. Seo June 2004 ASCII HTML 27 allocation atrribute certificate authorization autonomous system number authorization certificate delegation internet registry ip address authorization public key infrastructure right-to-use secure allocation

This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK]

draft-ietf-pkix-x509-ipaddr-as-extn-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3779 10.17487/RFC3779
RFC3780 SMIng - Next Generation Structure of Management Information F. Strauss J. Schoenwaelder May 2004 ASCII HTML 64 data definition language

This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-nmrg-sming-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC3780
RFC3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP) F. Strauss J. Schoenwaelder May 2004 ASCII HTML 49 data definition language

SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-nmrg-sming-snmp-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3781 10.17487/RFC3781
RFC3782 The NewReno Modification to TCP's Fast Recovery Algorithm S. Floyd T. Henderson A. Gurtov April 2004 ASCII HTML 19 Transmission Control Protocol

The purpose of this document is to advance NewReno TCP's Fast Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewReno TCP. [STANDARDS-TRACK]

draft-ietf-tsvwg-newreno-02 RFC2582 RFC6582 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=3782 10.17487/RFC3782
RFC3783 Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI M. Chadalapaka R. Elliott May 2004 ASCII HTML 14 Internet Small Computer Systems Interface iscsi

Internet Small Computer Systems Interface (iSCSI) is a Small Computer Systems Interface (SCSI) transport protocol designed to run on top of TCP. The iSCSI session abstraction is equivalent to the classic SCSI "I_T nexus", which represents the logical relationship between an Initiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. This memo provides information for the Internet community.

draft-ietf-ips-command-ordering-02 INFORMATIONAL INFORMATIONAL IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3783 10.17487/RFC3783
RFC3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) H. Smit T. Li June 2004 ASCII HTML 13 link state protocol lsp

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This memo provides information for the Internet community.

draft-ietf-isis-traffic-05 RFC5305 RFC4205 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3784
RFC3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric F. Le Faucheur R. Uppili A. Vedrenne P. Merckx T. Telkamp May 2004 ASCII HTML 8 link bandwidth router

This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tewg-te-metric-igp-02 BCP0087 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF subip tewg 10.17487/RFC3785
RFC3786 Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit A. Hermelin S. Previdi M. Shand May 2004 ASCII HTML 14

This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. This memo provides information for the Internet community.

draft-ietf-isis-ext-lsp-frags-02 RFC5311 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3786
RFC3787 Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) J. Parker Editor May 2004 ASCII HTML 11 routing traffic

This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. This memo provides information for the Internet community.

draft-ietf-isis-ip-interoperable-02 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3787
RFC3788 Security Considerations for Signaling Transport (SIGTRAN) Protocols J. Loughney M. Tuexen Editor J. Pastor-Balbas June 2004 ASCII HTML 13

This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. [STANDARDS-TRACK]

draft-ietf-sigtran-security-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3788
RFC3789 Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII HTML 10

This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in IETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-intro-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3789
RFC3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents C. Mickles Editor P. Nesser II June 2004 ASCII HTML 49

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-int-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3790
RFC3791 Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents C. Olvera P. Nesser II June 2004 ASCII HTML 15

This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-routing-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3791
RFC3792 Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII HTML 25

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-sec-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3792
RFC3793 Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII HTML 6

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-subip-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3793
RFC3794 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII HTML 31

This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-trans-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3794
RFC3795 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents R. Sofia P. Nesser II June 2004 ASCII HTML 50

This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-apps-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3795
RFC3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents P. Nesser II A. Bergstrom Editor June 2004 ASCII HTML 43

This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. This memo provides information for the Internet community.

draft-ietf-v6ops-ipv4survey-ops-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3796
RFC3797 Publicly Verifiable Nominations Committee (NomCom) Random Selection D. Eastlake 3rd June 2004 ASCII HTML 19 Internet Engineering Task Force IETF

This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.

draft-eastlake-rfc2777bis-selection-04 RFC2777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3797
RFC3798 Message Disposition Notification T. Hansen Editor G. Vaudreuil Editor May 2004 ASCII HTML 30 EMF-MDN MDN media-type MIME multipurpose internet mail extensions

This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. [STANDARDS-TRACK]

draft-vaudreuil-mdnbis-05 RFC2298 RFC8098 RFC3461 RFC2046 RFC5337 RFC6533 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3798 10.17487/RFC3798
RFC3799 RFC3800 RFC3801 Voice Profile for Internet Mail - version 2 (VPIMv2) G. Vaudreuil G. Parsons June 2004 ASCII HTML 55 MIME-VP2 vpim messaging

This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems. This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM. [STANDARDS-TRACK]

draft-ietf-vpim-vpimv2r2-05 RFC2421 RFC2423 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3801
RFC3802 Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration G. Vaudreuil G. Parsons June 2004 ASCII HTML 7 MIME-ADPCM multipurpose internet mail extensions audio

This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. [STANDARDS-TRACK]

draft-ietf-vpim-vpimv2r2-32k-03 RFC2422 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3802
RFC3803 Content Duration MIME Header Definition G. Vaudreuil G. Parsons June 2004 ASCII HTML 5 CONT-DUR multipurpose internet mail extensions time media

This document describes the MIME header Content-Duration that is intended for use with any time varying media content (typically audio/* or video/*). [STANDARDS-TRACK]

draft-ietf-vpim-vpimv2r2-dur-03 RFC2424 DRAFT STANDARD DRAFT STANDARD IETF app vpim 10.17487/RFC3803
RFC3804 Voice Profile for Internet Mail (VPIM) Addressing G. Parsons June 2004 ASCII HTML 15 formats

This document lists the various Voice Profile for Internet Mail (VPIM) email address formats that are currently in common use and defines several new address formats for special case usage. Requirements are imposed on the formats of addresses used in VPIM submission mode. [STANDARDS-TRACK]

draft-ietf-vpim-address-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC3804
RFC3805 Printer MIB v2 R. Bergman H. Lewis I. McDonald June 2004 ASCII HTML 171 Print-MIB Management Information Base snmp management

This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759. [STANDARDS-TRACK]

draft-ietf-printmib-mib-info-15 RFC1759 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3805
RFC3806 Printer Finishing MIB R. Bergman H. Lewis I. McDonald June 2004 ASCII HTML 53 finisher snmp

This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a Printer System. This memo provides information for the Internet community.

draft-ietf-printmib-finishing-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3806
RFC3807 V5.2-User Adaptation Layer (V5UA) E. Weilandt N. Khanchandani S. Rao June 2004 ASCII HTML 24 v5 v5.1 v5.2 backhauling imap sctp isdn access network c-path c-channel efa envelope function address lapv5 pstn v5ptm mgc gateway controller gateway

This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation. [STANDARDS-TRACK]

draft-ietf-sigtran-v5ua-04 RFC3057 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3807
RFC3808 IANA Charset MIB I. McDonald June 2004 ASCII HTML 14 management information base IANACharset

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used by IANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset Registration Procedures (RFC 2978). This memo provides information for the Internet community.

draft-mcdonald-iana-charset-mib-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3808
RFC3809 Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) A. Nagarajan Editor June 2004 ASCII HTML 25 service engineering

This document describes generic requirements for Provider Provisioned Virtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies. All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. This memo provides information for the Internet community.

draft-ietf-l3vpn-generic-reqts-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC3809
RFC3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 R. Vida Editor L. Costa Editor June 2004 ASCII HTML 62 ssm source filtering igmp group management mld

This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]

draft-vida-mld-v2-08 RFC2710 RFC4604 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=3810 10.17487/RFC3810
RFC3811 Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management T. Nadeau Editor J. Cucchiara Editor June 2004 ASCII HTML 20 management information base

This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-mpls-tc-mib-10 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3811 10.17487/RFC3811
RFC3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII HTML 68

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). [STANDARDS-TRACK]

draft-ietf-mpls-te-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3812
RFC3813 Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) C. Srinivasan A. Viswanathan T. Nadeau June 2004 ASCII HTML 60

This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

draft-ietf-mpls-lsr-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3813 10.17487/RFC3813
RFC3814 Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) T. Nadeau C. Srinivasan A. Viswanathan June 2004 ASCII HTML 42

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]

draft-ietf-mpls-ftn-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC3814
RFC3815 Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) J. Cucchiara H. Sjostrand J. Luciani June 2004 ASCII HTML 106

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). [STANDARDS-TRACK]

draft-ietf-mpls-ldp-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=3815 10.17487/RFC3815
RFC3816 Definitions of Managed Objects for RObust Header Compression (ROHC) J. Quittek M. Stiemerling H. Hartenstein June 2004 ASCII HTML 53 mib management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC). The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by all ROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-Time Transport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile. [STANDARDS-TRACK]

draft-ietf-rohc-mib-rtp-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=3816 10.17487/RFC3816
RFC3817 Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) W. Townsley R. da Silva June 2004 ASCII HTML 17 point-to-point

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet. L2TP Active Discovery Relay for PPPoE describes a method to relay Active Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs (AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. This memo provides information for the Internet community.

draft-dasilva-l2tp-relaysvc-08 INFORMATIONAL INFORMATIONAL IETF int l2tpext 10.17487/RFC3817
RFC3818 IANA Considerations for the Point-to-Point Protocol (PPP) V. Schryver June 2004 ASCII HTML 4

The charter of the Point-to-Point Protocol (PPP) Extensions working group (pppext) includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-schryver-pppext-iana-01 BCP0088 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pppext 10.17487/RFC3818
RFC3819 Advice for Internet Subnetwork Designers P. Karn Editor C. Bormann G. Fairhurst D. Grossman R. Ludwig J. Mahdavi G. Montenegro J. Touch L. Wood July 2004 ASCII HTML 60 digital communication equipment link-layer protocols packet-switched local networks

This document provides advice to the designers of digital communication equipment, link-layer protocols, and packet-switched local networks (collectively referred to as subnetworks), who wish to support the Internet protocols but may be unfamiliar with the Internet architecture and the implications of their design choices on the performance and efficiency of the Internet. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pilc-link-design-15 BCP0089 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv pilc http://www.rfc-editor.org/errata_search.php?rfc=3819 10.17487/RFC3819
RFC3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile S. Tuecke V. Welch D. Engert L. Pearlman M. Thompson June 2004 ASCII HTML 37 authentication security credentials restricted delegation single-signon delegation of rights

This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system. [STANDARDS-TRACK]

draft-ietf-pkix-proxy-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=3820 10.17487/RFC3820
RFC3821 Fibre Channel Over TCP/IP (FCIP) M. Rajagopal E. Rodriguez R. Weber July 2004 ASCII HTML 74 storage area networks IP-based networks unified storage area network

Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. [STANDARDS-TRACK]

draft-ietf-ips-fcovertcpip-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3821
RFC3822 Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2) D. Peterson July 2004 ASCII HTML 11 dynamic discovery

This document defines the use of Service Location Protocol version 2 (SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. [STANDARDS-TRACK]

draft-ietf-ips-fcip-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=3822 10.17487/RFC3822
RFC3823 MIME Media Type for the Systems Biology Markup Language (SBML) B. Kovitz June 2004 ASCII HTML 8 sub-type application/sbml+xml systems biology community

This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. This memo provides information for the Internet community.

draft-sbml-media-type-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3823
RFC3824 Using E.164 numbers with the Session Initiation Protocol (SIP) J. Peterson H. Liu J. Yu B. Campbell June 2004 ASCII HTML 16 telephone records applications

There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. This memo provides information for the Internet community.

draft-ietf-sipping-e164-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3824
RFC3825 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information J. Polk J. Schnizlein M. Linsner July 2004 ASCII HTML 15 dhcp lci geographic location

This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included. [STANDARDS-TRACK]

draft-ietf-geopriv-dhcp-lci-option-03 RFC6225 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC3825
RFC3826 The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model U. Blumenthal F. Maino K. McCloghrie June 2004 ASCII HTML 16 management information base simple network management protocol

This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits. [STANDARDS-TRACK]

draft-blumenthal-aes-usm-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3826
RFC3827 Additional Snoop Datalink Types K. Sarcar June 2004 ASCII HTML 4

The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. This memo provides information for the Internet community.

draft-sarcar-snoop-new-types-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3827
RFC3828 The Lightweight User Datagram Protocol (UDP-Lite) L-A. Larzon M. Degermark S. Pink L-E. Jonsson Editor G. Fairhurst Editor July 2004 ASCII HTML 12

This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP. [STANDARDS-TRACK]

draft-ietf-tsvwg-udp-lite-02 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC3828
RFC3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls R. Weltman M. Smith M. Wahl July 2004 ASCII HTML 6 bind operation

This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. This memo provides information for the Internet community.

draft-weltman-ldapv3-auth-response-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3829 10.17487/RFC3829
RFC3830 MIKEY: Multimedia Internet KEYing J. Arkko E. Carrara F. Lindholm M. Naslund K. Norrman August 2004 ASCII HTML 66 key management scheme real-time applications

This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK]

draft-ietf-msec-mikey-08 RFC4738 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=3830 10.17487/RFC3830
RFC3831 Transmission of IPv6 Packets over Fibre Channel C. DeSanti July 2004 ASCII HTML 24 addresses link-local internet protocol

This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. [STANDARDS-TRACK]

draft-ietf-imss-ipv6-over-fibre-channel-02 RFC4338 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC3831
RFC3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV W. Zhao H. Schulzrinne E. Guttman C. Bisdikian W. Jerome July 2004 ASCII HTML 8 DNS-SRV domain name system resource record

Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. This memo defines an Experimental Protocol for the Internet community.

draft-zhao-slp-remote-da-discovery-06 RFC8553 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC3832
RFC3833 Threat Analysis of the Domain Name System (DNS) D. Atkins R. Austein August 2004 ASCII HTML 16 data disclosure security authentication

Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.

draft-ietf-dnsext-dns-threats-07 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC3833
RFC3834 Recommendations for Automatic Responses to Electronic Mail K. Moore August 2004 ASCII HTML 22 automatic mail responders

This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders. The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders. [STANDARDS-TRACK]

draft-moore-auto-email-response-05 RFC5436 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3834 10.17487/RFC3834
RFC3835 An Architecture for Open Pluggable Edge Services (OPES) A. Barbir R. Penno R. Chen M. Hofmann H. Orman August 2004 ASCII HTML 17 application service data stream service data consumer data dispatcher architecture

This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. This memo provides information for the Internet community.

draft-ietf-opes-architecture-04 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3835
RFC3836 Requirements for Open Pluggable Edge Services (OPES) Callout Protocols A. Beck M. Hofmann H. Orman R. Penno A. Terzis August 2004 ASCII HTML 13 callout protocol remote execution OPES services

This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. This memo provides information for the Internet community.

draft-ietf-opes-protocol-reqs-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3836
RFC3837 Security Threats and Risks for Open Pluggable Edge Services (OPES) A. Barbir O. Batuner B. Srinivas M. Hofmann H. Orman August 2004 ASCII HTML 14 threat discovery threat analysis

The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. This memo provides information for the Internet community.

draft-ietf-opes-threats-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3837
RFC3838 Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) A. Barbir O. Batuner A. Beck T. Chan H. Orman August 2004 ASCII HTML 17 opes flow

This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. This memo provides information for the Internet community.

draft-ietf-opes-authorization-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3838
RFC3839 MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files R. Castagno D. Singer July 2004 ASCII HTML 7 standard MIME types 3GPP multimedia file format ISO Media File Format

This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

draft-singer-avt-3gpp-mime-01 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3839
RFC3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII HTML 36 ua contact header field

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field. [STANDARDS-TRACK]

draft-ietf-sip-callee-caps-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3840
RFC3841 Caller Preferences for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne P. Kyzivat August 2004 ASCII HTML 26 Uniform Resource Identifiers URI Accept-Contact Reject-Contact Request-Disposition

This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences. [STANDARDS-TRACK]

draft-ietf-sip-callerprefs-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3841
RFC3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP) R. Mahy August 2004 ASCII HTML 19 message waiting status message summary

This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. [STANDARDS-TRACK]

draft-ietf-sipping-mwi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC3842
RFC3843 RObust Header Compression (ROHC): A Compression Profile for IP L-E. Jonsson G. Pelletier June 2004 ASCII HTML 16 compression protocols

The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length. [STANDARDS-TRACK]

draft-ietf-rohc-ip-only-05 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC3843
RFC3844 IETF Problem Resolution Process E. Davies Editor J. Hofmann Editor August 2004 ASCII HTML 20 ietf process problem analysis

This Informational document records the history of discussions in the Problem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes. The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG. While there was working group consensus on the processes for short-term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. This memo provides information for the Internet community.

draft-ietf-problem-process-04 INFORMATIONAL INFORMATIONAL IETF gen problem 10.17487/RFC3844
RFC3845 DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format J. Schlyter Editor August 2004 ASCII HTML 7 dnssec DNS Security rr resource record DNS-SECEXT dns authentication nsec nextsecure

This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]

draft-ietf-dnsext-nsec-rdata-06 RFC4033 RFC4034 RFC4035 RFC3755 RFC2535 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC3845
RFC3846 Mobile IPv4 Extension for Carrying Network Access Identifiers F. Johansson T. Johansson June 2004 ASCII HTML 8 nai internet protocol home aaa server ha server home agents

When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multiple Authentication Authorization and Accounting (AAA) servers and Home Agents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of the Home AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes. [STANDARDS-TRACK]

draft-ietf-mip4-aaa-nai-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3846
RFC3847 Restart Signaling for Intermediate System to Intermediate System (IS-IS) M. Shand L. Ginsberg July 2004 ASCII HTML 21 LSP database synchronization transient routing disruption database synchronization

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This memo provides information for the Internet community.

draft-ietf-isis-restart-05 RFC5306 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC3847
RFC3848 ESMTP and LMTP Transmission Types Registration C. Newman July 2004 ASCII HTML 4 smtp simple mail transfer protocol

This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message. [STANDARDS-TRACK]

draft-newman-esmtpsa-01 DRAFT STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3848
RFC3849 IPv6 Address Prefix Reserved for Documentation G. Huston A. Lord P. Smith July 2004 ASCII HTML 4 unicast site-local link-local

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. This memo provides information for the Internet community.

draft-huston-ipv6-documentation-prefix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3849
RFC3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling B. Ramsdell Editor July 2004 ASCII HTML 16 x.509 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280. [STANDARDS-TRACK]

draft-ietf-smime-rfc2632bis-07 RFC2632 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3850
RFC3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification B. Ramsdell Editor July 2004 ASCII HTML 36 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633. [STANDARDS-TRACK]

draft-ietf-smime-rfc2633bis-09 RFC2633 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3851
RFC3852 Cryptographic Message Syntax (CMS) R. Housley July 2004 ASCII HTML 56 digitally sign authenticate encrypt arbitrary message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

draft-ietf-smime-rfc3369bis-04 RFC3369 RFC5652 RFC4853 RFC5083 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=3852 10.17487/RFC3852
RFC3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP) J. Peterson July 2004 ASCII HTML 6 SIP application-layer application layer multimedia multicast unicast

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This document updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME. [STANDARDS-TRACK]

draft-ietf-sip-smime-aes-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3853
RFC3854 Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME) P. Hoffman C. Bonatti A. Eggen July 2004 ASCII HTML 15 encryption cryptographic signature

This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/Multipurpose Internet Mail Extensions (S/MIME). [STANDARDS-TRACK]

draft-ietf-smime-x400wrap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3854
RFC3855 Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400 P. Hoffman C. Bonatti July 2004 ASCII HTML 12 cms cryptographic message syntax message

This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system. [STANDARDS-TRACK]

draft-ietf-smime-x400transport-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC3855
RFC3856 A Presence Event Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII HTML 27 subscription notification

This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. [STANDARDS-TRACK]

draft-ietf-simple-presence-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=3856 10.17487/RFC3856
RFC3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) J. Rosenberg August 2004 ASCII HTML 20

This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. [STANDARDS-TRACK]

draft-ietf-simple-winfo-package-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC3857
RFC3858 An Extensible Markup Language (XML) Based Format for Watcher Information J. Rosenberg August 2004 ASCII HTML 13 Extensible Markup Language xml

Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state. [STANDARDS-TRACK]

draft-ietf-simple-winfo-format-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3858
RFC3859 Common Profile for Presence (CPP) J. Peterson August 2004 ASCII HTML 15 data formats semantics instant messaging

At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. [STANDARDS-TRACK]

draft-ietf-impp-pres-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3859 10.17487/RFC3859
RFC3860 Common Profile for Instant Messaging (CPIM) J. Peterson August 2004 ASCII HTML 13 data formats semantics instant messaging

At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. [STANDARDS-TRACK]

draft-ietf-impp-im-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3860
RFC3861 Address Resolution for Instant Messaging and Presence J. Peterson August 2004 ASCII HTML 8 uri schemes universal resource identifier impp instant messaging and presence protocol presentity instant inbox

Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS-TRACK]

draft-ietf-impp-srv-04 PROPOSED STANDARD PROPOSED STANDARD IETF app impp 10.17487/RFC3861
RFC3862 Common Presence and Instant Messaging (CPIM): Message Format G. Klyne D. Atkins August 2004 ASCII HTML 30 instant messaging and presence protocol message/cpim

This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. [STANDARDS-TRACK]

draft-ietf-impp-cpim-msgfmt-09 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3862 10.17487/RFC3862
RFC3863 Presence Information Data Format (PIDF) H. Sugano S. Fujimoto G. Klyne A. Bateman W. Carr J. Peterson August 2004 ASCII HTML 28 instant messaging and presence protocol cpp common profile for presence presence data format application/pidf+xml

This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF. [STANDARDS-TRACK]

draft-ietf-impp-cpim-pidf-08 PROPOSED STANDARD PROPOSED STANDARD IETF app impp http://www.rfc-editor.org/errata_search.php?rfc=3863 10.17487/RFC3863
RFC3864 Registration Procedures for Message Header Fields G. Klyne M. Nottingham J. Mogul September 2004 ASCII HTML 17 Internet mail HTTP Netnews

This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klyne-msghdr-registry-07 BCP0090 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3864
RFC3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension C. Malamud September 2004 ASCII HTML 19 unsolicited bulk email ube no soliciting solicitation class keywords solicitation mail header trace fields

This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. [STANDARDS-TRACK]

draft-malamud-no-soliciting-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3865
RFC3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP) K. Zeilenga Editor July 2004 ASCII HTML 15 lightweight directory access protocol servers

It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). [STANDARDS-TRACK]

draft-zeilenga-ldap-rfc2596-05 RFC2596 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3866 10.17487/RFC3866
RFC3867 Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP) Y. Kawatsura M. Hiroya H. Beykirch November 2004 ASCII HTML 106 modules data format exchange

The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.

This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.

Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. This memo provides information for the Internet community.

draft-ietf-trade-iotp-v1.0-papi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC3867
RFC3868 Signalling Connection Control Part User Adaptation Layer (SUA) J. Loughney Editor G. Sidebottom L. Coene G. Verwimp J. Keller B. Bidulock October 2004 ASCII HTML 131 sctp stream control transmission protocol modular symmetric signalling gateway signalling endpoint architecture

This document defines a protocol for the transport of any Signalling Connection Control Part-User signalling over IP using the Stream Control Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture. [STANDARDS-TRACK]

draft-ietf-sigtran-sua-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3868
RFC3869 IAB Concerns and Recommendations Regarding Internet Research and Evolution R. Atkinson Editor S. Floyd Editor Internet Architecture Board August 2004 ASCII HTML 30 internet architecture board internet infrastructure non-commercial funding

This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. This memo provides information for the Internet community.

draft-iab-research-funding-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3869
RFC3870 application/rdf+xml Media Type Registration A. Swartz September 2004 ASCII HTML 8 xml extensible markup language mime multipurpose internet mail extensions rdf resource description framework

This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of the Resource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide Web Consortium (W3C) design principles of interoperability, evolution, and decentralization. This memo provides information for the Internet community.

draft-swartz-rdfcore-rdfxml-mediatype-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3870
RFC3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure G. Jones Editor September 2004 ASCII HTML 81

This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. This memo provides information for the Internet community.

draft-jones-opsec-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3871
RFC3872 Management Information Base for Telephony Routing over IP (TRIP) D. Zinman D. Walker J. Jiang September 2004 ASCII HTML 53 mib

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices. [STANDARDS-TRACK]

draft-ietf-iptel-trip-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3872
RFC3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB) J. Pastor M. Belinchon September 2004 ASCII HTML 46

The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications.

This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP. [STANDARDS-TRACK]

draft-ietf-sigtran-sctp-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC3873
RFC3874 A 224-bit One-way Hash Function: SHA-224 R. Housley September 2004 ASCII HTML 6 secure standard

This document specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. This memo provides information for the Internet community.

draft-ietf-pkix-sha224-01 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC3874
RFC3875 The Common Gateway Interface (CGI) Version 1.1 D. Robinson K. Coar October 2004 ASCII PDF HTML 36 www world wide web

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.

The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. This memo provides information for the Internet community.

draft-coar-cgi-v11-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3875 10.17487/RFC3875
RFC3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3) D. Chadwick S. Mullan September 2004 ASCII HTML 12 attribute filter

This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. [STANDARDS-TRACK]

draft-ietf-ldapext-matchedval-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3876
RFC3877 Alarm Management Information Base (MIB) S. Chisholm D. Romascanu September 2004 ASCII HTML 75 alarm mib iana-itu-alarm-tc-mib itu-alarm-tc-mib itu-alarm-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. [STANDARDS-TRACK]

draft-ietf-disman-alarm-mib-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman http://www.rfc-editor.org/errata_search.php?rfc=3877 10.17487/RFC3877
RFC3878 Alarm Reporting Control Management Information Base (MIB) H. Lam A. Huynh D. Perkins September 2004 ASCII HTML 16 alarm condition probably cause

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. [STANDARDS-TRACK]

draft-ietf-disman-conditionmib-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC3878
RFC3879 Deprecating Site Local Addresses C. Huitema B. Carpenter September 2004 ASCII HTML 10 ipv6 architecture

This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented. [STANDARDS-TRACK]

draft-ietf-ipv6-deprecate-site-local-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC3879
RFC3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services J. Lennox X. Wu H. Schulzrinne October 2004 ASCII HTML 74

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. [STANDARDS-TRACK]

draft-ietf-iptel-cpl-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC3880
RFC3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications G. Marshall September 2004 ASCII HTML 47

This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. This memo provides information for the Internet community.

draft-marshall-security-audit-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3881
RFC3882 Configuring BGP to Block Denial-of-Service Attacks D. Turk September 2004 ASCII HTML 8 dos border gateway protocol

This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. This memo provides information for the Internet community.

draft-turk-bgp-dos-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3882
RFC3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC) S. Rao A. Zinin A. Roy October 2004 ASCII HTML 6 OSPF-DC Open Shortest Path First

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem. [STANDARDS-TRACK]

draft-ietf-ospf-dc-07 RFC1793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC3883
RFC3884 Use of IPsec Transport Mode for Dynamic Routing J. Touch L. Eggert Y. Wang September 2004 ASCII HTML 25

IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of the VN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database (SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture. IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). This memo provides information for the Internet community.

draft-touch-ipsec-vpn-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3884
RFC3885 SMTP Service Extension for Message Tracking E. Allman T. Hansen September 2004 ASCII HTML 9 simple mail transfer protocol

This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking. [STANDARDS-TRACK]

draft-ietf-msgtrk-smtpext-05 RFC3461 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk 10.17487/RFC3885
RFC3886 An Extensible Message Format for Message Tracking Responses E. Allman September 2004 ASCII HTML 11 Delivery Status Notifications DSN Message Disposition Notifications MDN

Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period.

This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo. [STANDARDS-TRACK]

draft-ietf-msgtrk-trkstat-05 RFC3463 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3886 10.17487/RFC3886
RFC3887 Message Tracking Query Protocol T. Hansen September 2004 ASCII HTML 23 mtqp ESMTP

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet. [STANDARDS-TRACK]

draft-ietf-msgtrk-mtqp-12 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF app msgtrk http://www.rfc-editor.org/errata_search.php?rfc=3887 10.17487/RFC3887
RFC3888 Message Tracking Model and Requirements T. Hansen September 2004 ASCII HTML 11

Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. This memo provides information for the Internet community.

draft-ietf-msgtrk-model-07 INFORMATIONAL INFORMATIONAL IETF app msgtrk 10.17487/RFC3888
RFC3889 RFC3890 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) M. Westerlund September 2004 ASCII HTML 22 tias application specific maximum

This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.

The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-bwparam-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC3890
RFC3891 The Session Initiation Protocol (SIP) "Replaces" Header R. Mahy B. Biggs R. Dean September 2004 ASCII HTML 16 multi-party applications call control

This document defines a new header for use with Session Initiation Protocol (SIP) multi-party applications and call control. The Replaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative. [STANDARDS-TRACK]

draft-ietf-sip-replaces-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=3891 10.17487/RFC3891
RFC3892 The Session Initiation Protocol (SIP) Referred-By Mechanism R. Sparks September 2004 ASCII HTML 25 REFER

The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present. [STANDARDS-TRACK]

draft-ietf-sip-referredby-05 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3892
RFC3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format J. Peterson September 2004 ASCII HTML 13 authenticated identity body digitally-signed SIP message message fragment Authenticated Identity Bodies AIB

RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. [STANDARDS-TRACK]

draft-ietf-sip-authid-body-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3893
RFC3894 Sieve Extension: Copying Without Side Effects J. Degener October 2004 ASCII HTML 5 client server

The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox". Actions such as "fileinto" and "redirect" cancel this default behavior.

This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script. [STANDARDS-TRACK]

draft-degener-sieve-copy-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3894
RFC3895 Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types O. Nicklass Editor September 2004 ASCII HTML 84 management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2495. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2495bis-06 RFC2495 RFC4805 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3895
RFC3896 Definitions of Managed Objects for the DS3/E3 Interface Type O. Nicklass Editor September 2004 ASCII HTML 63 DS3-E3-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 2496. [STANDARDS-TRACK]

draft-ietf-atommib-rfc2496bis-06 RFC2496 PROPOSED STANDARD PROPOSED STANDARD IETF ops atommib 10.17487/RFC3896
RFC3897 Open Pluggable Edge Services (OPES) Entities and End Points Communication A. Barbir September 2004 ASCII HTML 14 tracing non-blocking bypass

This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). This memo provides information for the Internet community.

draft-ietf-opes-end-comm-08 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3897
RFC3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) V. Kalusivalingam October 2004 ASCII HTML 7 NIS Servers NIS+ Servers NIS Client Domain Name NIS+ Client Domain name

This document describes four options for Network Information Service (NIS) related configuration information in Dynamic Host Configuration Protocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-opt-nisconfig-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3898
RFC3899 RFC3900 RFC3901 DNS IPv6 Transport Operational Guidelines A. Durand J. Ihren September 2004 ASCII HTML 5 domain name system internet protocol

This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-ipv6-transport-guidelines-02 BCP0091 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC3901
RFC3902 The "application/soap+xml" media type M. Baker M. Nottingham September 2004 ASCII HTML 5

This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. This memo provides information for the Internet community.

draft-baker-soap-media-reg-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3902
RFC3903 Session Initiation Protocol (SIP) Extension for Event State Publication A. Niemi Editor October 2004 ASCII HTML 32 presence information package

This document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose. [STANDARDS-TRACK]

draft-ietf-sip-publish-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3903
RFC3904 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks C. Huitema R. Austein S. Satapati R. van der Pol September 2004 ASCII HTML 19 home office internet protocol

This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This memo provides information for the Internet community.

draft-ietf-v6ops-unmaneval-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC3904
RFC3905 A Template for IETF Patent Disclosures and Licensing Declarations V. See Editor September 2004 ASCII HTML 9 ipr

This document describes a proposal for one form of a template for IETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. This memo provides information for the Internet community.

draft-ietf-ipr-template-09 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3905 10.17487/RFC3905
RFC3906 Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels N. Shen H. Smit October 2004 ASCII HTML 8 hop-by-hop link-state routing protocols SPF shortest path first

This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering. This memo provides information for the Internet community.

draft-ietf-rtgwg-igp-shortcut-01 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC3906
RFC3907 RFC3908 RFC3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation K. Zeilenga October 2004 ASCII HTML 7 abandon operation outstanding operation

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. [STANDARDS-TRACK]

draft-zeilenga-ldap-cancel-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3909
RFC3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol V. Gurbani Editor A. Brusilovsky I. Faynberg J. Gato H. Lu M. Unmehopa October 2004 ASCII HTML 50 pstn sip services event notification eventpackages internet call waiting xml wireless intelligent network in detection point dp

This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built. [STANDARDS-TRACK]

draft-ietf-spirits-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv spirits 10.17487/RFC3910
RFC3911 The Session Initiation Protocol (SIP) "Join" Header R. Mahy D. Petrie October 2004 ASCII HTML 17

This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative. [STANDARDS-TRACK]

draft-ietf-sip-join-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC3911
RFC3912 WHOIS Protocol Specification L. Daigle September 2004 ASCII HTML 4 NICNAME

This document updates the specification of the WHOIS protocol, thereby obsoleting RFC 954. The update is intended to remove the material from RFC 954 that does not have to do with the on-the-wire protocol, and is no longer applicable in today's Internet. This document does not attempt to change or update the protocol per se, or document other uses of the protocol that have come into existence since the publication of RFC 954. [STANDARDS-TRACK]

draft-daigle-rfc954bis-01 RFC0954 RFC0812 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC3912
RFC3913 Border Gateway Multicast Protocol (BGMP): Protocol Specification D. Thaler September 2004 ASCII HTML 41 enter-domain source-specific multicast ssm

This document describes the Border Gateway Multicast Protocol (BGMP), a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and optionally allows receiver domains to build source-specific, inter-domain, distribution branches where needed. BGMP natively supports "source-specific multicast" (SSM). To also support "any-source multicast" (ASM), BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). It requires that different ranges of the multicast address space are associated (e.g., with Unicast-Prefix-Based Multicast addressing) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. This memo provides information for the Internet community.

draft-ietf-bgmp-spec-06 HISTORIC INFORMATIONAL IETF rtg bgmp 10.17487/RFC3913
RFC3914 Open Pluggable Edge Services (OPES) Treatment of IAB Considerations A. Barbir A. Rousskov October 2004 ASCII HTML 16

IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. This memo provides information for the Internet community.

draft-ietf-opes-iab-05 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC3914
RFC3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck September 2004 ASCII HTML 23 dns name system

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by the Internet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing. [STANDARDS-TRACK]

draft-hollenbeck-epp-rgp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3915
RFC3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) X. Xiao Editor D. McPherson Editor P. Pate Editor September 2004 ASCII HTML 19

This document describes base requirements for the Pseudo-Wire Emulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e., "synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. This memo provides information for the Internet community.

draft-ietf-pwe3-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3916
RFC3917 Requirements for IP Flow Information Export (IPFIX) J. Quittek T. Zseby B. Claise S. Zander October 2004 ASCII HTML 33 ipfix routers measurment middleboxes

This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. This memo provides information for the Internet community.

draft-ietf-ipfix-reqs-16 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3917
RFC3918 Methodology for IP Multicast Benchmarking D. Stopp B. Hickman October 2004 ASCII HTML 31

The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.

The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. This memo provides information for the Internet community.

draft-ietf-bmwg-mcastm-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC3918
RFC3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS) E. Stephan J. Palet October 2004 ASCII HTML 8 mib

This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable ``INDEX`` encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].

This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. This memo provides information for the Internet community.

draft-ietf-rmonmib-pi-ipv6-04 INFORMATIONAL INFORMATIONAL IETF ops rmonmib 10.17487/RFC3919
RFC3920 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre Editor October 2004 ASCII HTML 30 instant messaging im extensible markup language xml jabber

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]

draft-ietf-xmpp-core-24 RFC6120 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3920 10.17487/RFC3920
RFC3921 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre Editor October 2004 ASCII HTML 107 instant messaging im extensible markup language xml jabber

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779. [STANDARDS-TRACK]

draft-ietf-xmpp-im-22 RFC6121 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3921
RFC3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) P. Saint-Andre October 2004 ASCII HTML 34 xml extensible markup language im instant messaging jabber

This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications. [STANDARDS-TRACK]

draft-ietf-xmpp-cpim-05 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp 10.17487/RFC3922
RFC3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre October 2004 ASCII HTML 27 xml extensible markup language im instant messaging jabber

This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

draft-ietf-xmpp-e2e-09 PROPOSED STANDARD PROPOSED STANDARD IETF app xmpp http://www.rfc-editor.org/errata_search.php?rfc=3923 10.17487/RFC3923
RFC3924 Cisco Architecture for Lawful Intercept in IP Networks F. Baker B. Foster C. Sharp October 2004 ASCII HTML 18

For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. This memo provides information for the Internet community.

draft-baker-slem-architecture-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3924
RFC3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) J. Littlefield October 2004 ASCII HTML 9 dhc dhcp class vendor-specific

The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity. [STANDARDS-TRACK]

draft-ietf-dhc-vendor-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3925
RFC3926 FLUTE - File Delivery over Unidirectional Transport T. Paila M. Luby R. Lehtonen V. Roca R. Walsh October 2004 ASCII HTML 35

This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-flute-08 RFC6726 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=3926 10.17487/RFC3926
RFC3927 Dynamic Configuration of IPv4 Link-Local Addresses S. Cheshire B. Aboba E. Guttman May 2005 ASCII HTML 33 ip network ip address 169.254/16

To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.

IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. [STANDARDS-TRACK]

draft-ietf-zeroconf-ipv4-linklocal-17 PROPOSED STANDARD PROPOSED STANDARD IETF int zeroconf http://www.rfc-editor.org/errata_search.php?rfc=3927 10.17487/RFC3927
RFC3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP) R. Megginson Editor M. Smith O. Natkovich J. Parham October 2004 ASCII HTML 30

This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [STANDARDS-TRACK]

draft-ietf-ldup-lcup-06 PROPOSED STANDARD PROPOSED STANDARD IETF app ldup 10.17487/RFC3928
RFC3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF T. Hardie October 2004 ASCII HTML 11

This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.

draft-hardie-alt-consensus-02 RFC8717 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3929 10.17487/RFC3929
RFC3930 The Protocol versus Document Points of View in Computer Protocols D. Eastlake 3rd October 2004 ASCII HTML 15

This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. This memo provides information for the Internet community.

draft-eastlake-proto-doc-pov-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3930
RFC3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3) J. Lau Editor M. Townsley Editor I. Goyret Editor March 2005 ASCII HTML 94 L2TP ppp point-to-point protocol packets

This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated. [STANDARDS-TRACK]

draft-ietf-l2tpext-l2tp-base-15 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=3931 10.17487/RFC3931
RFC3932 The IESG and RFC Editor Documents: Procedures H. Alvestrand October 2004 ASCII HTML 8 independent submission

This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004.

This document updates procedures described in RFC 2026 and RFC 3710. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iesg-rfced-documents-03 RFC5742 RFC2026 RFC3710 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC3932
RFC3933 A Model for IETF Process Experiments J. Klensin S. Dawkins November 2004 ASCII HTML 7

The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-process-july14-02 BCP0093 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3933 10.17487/RFC3933
RFC3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists M. Wasserman October 2004 ASCII HTML 5 BCP WG escape clause procedures

This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-wasserman-rfc2418-ml-update-01 RFC2418 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3934
RFC3935 A Mission Statement for the IETF H. Alvestrand October 2004 ASCII HTML 7

This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-alvestrand-ietf-mission-02 BCP0095 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3935
RFC3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP) K. Kompella J. Lang October 2004 ASCII HTML 7 resource reservation protocol label switched paths

This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-kompella-rsvp-change-02 RFC3209 RFC2205 BCP0096 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC3936
RFC3937 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC) M. Steidl October 2004 ASCII HTML 9

This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International Press Telecommunications Council (IPTC). These resources include XML Data Type Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. This memo provides information for the Internet community.

draft-steidl-iptc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3937
RFC3938 Video-Message Message-Context T. Hansen October 2004 ASCII HTML 4 user agent ua

The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". A receiving user agent (UA) may use this information as a hint to optimally present the message. [STANDARDS-TRACK]

draft-hansen-lemonade-msgctxt-videomsg-01 RFC3458 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC3938
RFC3939 Calling Line Identification for Voice Mail Messages G. Parsons J. Maruszak December 2004 ASCII HTML 11

This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID and Called_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message. Caller-name provides the name of the person sending the message. [STANDARDS-TRACK]

draft-ema-vpim-clid-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3939 10.17487/RFC3939
RFC3940 Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII HTML 80

This document describes the messages and procedures of the Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-pi-norm-10 RFC5740 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3940
RFC3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2004 ASCII HTML 36

This document discusses the creation of negative-acknowledgment (NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-norm-09 RFC5401 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC3941
RFC3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options B. Volz November 2004 ASCII HTML 7 DHCP-BOOTP Bootstrap

This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. [STANDARDS-TRACK]

draft-ietf-dhc-reclassify-options-01 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=3942 10.17487/RFC3942
RFC3943 Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) R. Friend November 2004 ASCII HTML 13 lossless data compression algorithm TLS Record Protocol

The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS Record Protocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. This memo provides information for the Internet community.

draft-friend-tls-lzs-compression-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC3943
RFC3944 H.350 Directory Services T. Johnson S. Okubo S. Campos December 2004 ASCII HTML 30 ldap directory services h.350 h.323 h.320 h.235 sip

The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community.

draft-johnson-h350-directory-serv-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3944 10.17487/RFC3944
RFC3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture E. Mannie Editor October 2004 ASCII HTML 69

Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.

This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-architecture-07 RFC6002 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=3945 10.17487/RFC3945
RFC3946 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou October 2004 ASCII HTML 26

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-sonet-sdh-08 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC3946
RFC3947 Negotiation of NAT-Traversal in the IKE T. Kivinen B. Swander A. Huttunen V. Volpe January 2005 ASCII HTML 16

This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes in Internet Key Exchange (IKE). [STANDARDS-TRACK]

draft-ietf-ipsec-nat-t-ike-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=3947 10.17487/RFC3947
RFC3948 UDP Encapsulation of IPsec ESP Packets A. Huttunen B. Swander V. Volpe L. DiBurro M. Stenberg January 2005 ASCII HTML 15

This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets inside UDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used with Internet Key Exchange (IKE). [STANDARDS-TRACK]

draft-ietf-ipsec-udp-encaps-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC3948
RFC3949 File Format for Internet Fax R. Buckley D. Venable L. McIntyre G. Parsons J. Rafferty February 2005 ASCII HTML 84 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.

This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. [STANDARDS-TRACK]

draft-ietf-fax-tiff-fx-14 RFC2301 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3949
RFC3950 Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration L. McIntyre G. Parsons J. Rafferty February 2005 ASCII HTML 8 FFIF TIFF Tag Image facsimile MIME multipurpose Internet mail extensions

This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for Internet Fax and its extensions. [STANDARDS-TRACK]

draft-ietf-fax-tiff-fx-reg-v2-01 RFC3250 DRAFT STANDARD DRAFT STANDARD IETF app fax 10.17487/RFC3950
RFC3951 Internet Low Bit Rate Codec (iLBC) S. Andersen A. Duric H. Astrom R. Hagen W. Kleijn J. Linden December 2004 ASCII HTML 194

This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound (GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-avt-ilbc-codec-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3951
RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech A. Duric S. Andersen December 2004 ASCII HTML 13

This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME and Session Description Protocol (SDP). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-avt-rtp-ilbc-05 EXPERIMENTAL EXPERIMENTAL IETF rai avt 10.17487/RFC3952
RFC3953 Telephone Number Mapping (ENUM) Service Registration for Presence Services J. Peterson January 2005 ASCII HTML 7 uniform resource identifier uri provisioning pres

This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning pres URIs in ENUM. [STANDARDS-TRACK]

draft-ietf-enum-pres-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC3953
RFC3954 Cisco Systems NetFlow Services Export Version 9 B. Claise Editor October 2004 ASCII HTML 33

This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.

draft-claise-netflow-9-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=3954 10.17487/RFC3954
RFC3955 Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) S. Leinen October 2004 ASCII HTML 23

This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This memo provides information for the Internet community.

draft-leinen-ipfix-eval-contrib-03 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC3955
RFC3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola B. Haberman November 2004 ASCII HTML 18 internet protocol

This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. [STANDARDS-TRACK]

draft-ietf-mboned-embeddedrp-07 RFC3306 RFC7371 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC3956
RFC3957 Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 C. Perkins P. Calhoun March 2005 ASCII HTML 27

Authentication, Authorization, and Accounting (AAA) servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. [STANDARDS-TRACK]

draft-ietf-mip4-aaa-key-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC3957
RFC3958 Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle A. Newton January 2005 ASCII HTML 25

This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port. [STANDARDS-TRACK]

draft-daigle-snaptr-01 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3958 10.17487/RFC3958
RFC3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII HTML 11

This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. [STANDARDS-TRACK]

draft-ietf-sipping-early-disposition-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=3959 10.17487/RFC3959
RFC3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) G. Camarillo H. Schulzrinne December 2004 ASCII HTML 13

This document describes how to manage early media in the Session Initiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. This memo provides information for the Internet community.

draft-ietf-sipping-early-media-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC3960
RFC3961 Encryption and Checksum Specifications for Kerberos 5 K. Raeburn February 2005 ASCII HTML 50

This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK]

draft-ietf-krb-wg-crypto-07 RFC8429 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=3961 10.17487/RFC3961
RFC3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5 K. Raeburn February 2005 ASCII HTML 16 kerberos cryptosystem suite

The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite. [STANDARDS-TRACK]

draft-raeburn-krb-rijndael-krb-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC3962
RFC3963 Network Mobility (NEMO) Basic Support Protocol V. Devarapalli R. Wakikawa A. Petrescu P. Thubert January 2005 ASCII HTML 33 mobile ipv6 session continuity

This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network. [STANDARDS-TRACK]

draft-ietf-nemo-basic-support-03 PROPOSED STANDARD PROPOSED STANDARD IETF int nemo 10.17487/RFC3963
RFC3964 Security Considerations for 6to4 P. Savola C. Patel December 2004 ASCII HTML 41

The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. This memo provides information for the Internet community.

draft-ietf-v6ops-6to4-security-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=3964 10.17487/RFC3964
RFC3965 A Simple Mode of Facsimile Using Internet Mail K. Toyoda H. Ohno J. Murai D. Wing December 2004 ASCII HTML 14 SMFAX-IM data file format e-mail

This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.

This document is a revision of RFC 2305. There have been no technical changes. [STANDARDS-TRACK]

draft-ietf-fax-service-v2-05 RFC2305 DRAFT STANDARD DRAFT STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=3965 10.17487/RFC3965
RFC3966 The tel URI for Telephone Numbers H. Schulzrinne December 2004 ASCII HTML 17 uniform resource locator schemes

This document specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806. [STANDARDS-TRACK]

draft-ietf-iptel-rfc2806bis-09 RFC2806 RFC5341 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=3966 10.17487/RFC3966
RFC3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level R. Bush T. Narten December 2004 ASCII HTML 6

IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document may not have a normative reference to an informational RFC. Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards. This document clarifies and updates the procedure used in these circumstances. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ymbk-downref-03 RFC4897 RFC8067 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3967 10.17487/RFC3967
RFC3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII HTML 8

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sip-parameter-registry-02 RFC3427 BCP0098 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3968
RFC3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) G. Camarillo December 2004 ASCII HTML 6

This document creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (SIP) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sip-uri-parameter-reg-02 RFC3427 RFC5727 BCP0099 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sip 10.17487/RFC3969
RFC3970 A Traffic Engineering (TE) MIB K. Kompella January 2005 ASCII HTML 44

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered (TE) Tunnels; for example, Multi-Protocol Label Switched Paths. [STANDARDS-TRACK]

draft-ietf-tewg-mib-08 PROPOSED STANDARD PROPOSED STANDARD Legacy http://www.rfc-editor.org/errata_search.php?rfc=3970 10.17487/RFC3970
RFC3971 SEcure Neighbor Discovery (SEND) J. Arkko Editor J. Kempf B. Zill P. Nikander March 2005 ASCII HTML 56 Neighbor Discovery Protocol NDP

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]

draft-ietf-send-ndopt-06 RFC6494 RFC6495 RFC6980 PROPOSED STANDARD PROPOSED STANDARD IETF int send http://www.rfc-editor.org/errata_search.php?rfc=3971 10.17487/RFC3971
RFC3972 Cryptographically Generated Addresses (CGA) T. Aura March 2005 ASCII HTML 22 Secure Neighbor Discovery SEND

This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS-TRACK]

draft-ietf-send-cga-06 RFC4581 RFC4982 PROPOSED STANDARD PROPOSED STANDARD IETF int send 10.17487/RFC3972
RFC3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) A. Adams J. Nicholas W. Siadak January 2005 ASCII HTML 61 multicast routing protocol prune messages

This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pim-dm-new-v2-05 RFC8736 EXPERIMENTAL EXPERIMENTAL IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=3973 10.17487/RFC3973
RFC3974 SMTP Operational Experience in Mixed IPv4/v6 Environments M. Nakamura J. Hagino January 2005 ASCII HTML 10 simple mail transfer protocol dual stack dualstack ipv4 ipv6

This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.

This document does not define any new protocol. This memo provides information for the Internet community.

draft-motonori-dualstack-smtp-requirement-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3974
RFC3975 OMA-IETF Standardization Collaboration G. Huston Editor I. Leuca Editor January 2005 ASCII HTML 9 oopen mobile alliance ietf internet engineering task force

This document describes the standardization collaboration between the Open Mobile Alliance (OMA) and the Internet Engineering Task Force (IETF). This memo provides information for the Internet community.

draft-iab-oma-liaison-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC3975
RFC3976 Interworking SIP and Intelligent Network (IN) Applications V. K. Gurbani F. Haerens V. Rastogi January 2005 ASCII HTML 25 sip intelligent network call models call model mapping telephony services public switched telephone network pstn

Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). This memo provides information for the Internet community.

draft-gurbani-sin-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3976
RFC3977 Network News Transfer Protocol (NNTP) C. Feather October 2006 ASCII HTML 125 usenet netnews

The Network News Transfer Protocol (NNTP) has been in use in the Internet for a decade, and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP. [STANDARDS-TRACK]

draft-ietf-nntpext-base-27 RFC0977 RFC2980 RFC6048 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=3977 10.17487/RFC3977
RFC3978 IETF Rights in Contributions S. Bradner Editor March 2005 ASCII HTML 18 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3979, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-subm-rights-fix-00 RFC3667 RFC5378 RFC2026 RFC4748 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=3978 10.17487/RFC3978
RFC3979 Intellectual Property Rights in IETF Technology S. Bradner Editor March 2005 ASCII HTML 17 ipr copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

RFC3668 RFC8179 RFC2026 RFC2028 RFC4879 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC3979
RFC3980 T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names M. Krueger M. Chadalapaka R. Elliott February 2005 ASCII HTML 8 internet small computer systems interface scsi transport protocol

Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information Technology Standards (INCITS) T11 - Fibre Channel (FC) protocols and used by Serial Attached SCSI (SAS). This document updates RFC 3720. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-name-ext-05 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC3980
RFC3981 IRIS: The Internet Registry Information Service (IRIS) Core Protocol A. Newton M. Sanz January 2005 ASCII HTML 52

This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. [STANDARDS-TRACK]

draft-ietf-crisp-iris-core-07 RFC4992 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3981 10.17487/RFC3981
RFC3982 IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz January 2005 ASCII HTML 50

This document describes an Internet Registry Information Service (IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. [STANDARDS-TRACK]

draft-ietf-crisp-iris-dreg-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=3982 10.17487/RFC3982
RFC3983 Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) A. Newton M. Sanz January 2005 ASCII HTML 12

This document specifies how to use the Blocks Extensible Exchange Protocol (BEEP) as the application transport substrate for the Internet Registry Information Service (IRIS). [STANDARDS-TRACK]

draft-ietf-crisp-iris-beep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp 10.17487/RFC3983
RFC3984 RTP Payload Format for H.264 Video S. Wenger M.M. Hannuksela T. Stockhammer M. Westerlund D. Singer February 2005 ASCII HTML 83 ITU-T Recommendation H.264 ISO/IEC International Standard 14496-10

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. [STANDARDS-TRACK]

draft-ietf-avt-rtp-h264-11 RFC6184 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC3984
RFC3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture S. Bryant Editor P. Pate Editor March 2005 ASCII HTML 42

This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

draft-ietf-pwe3-arch-07 RFC5462 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC3985
RFC3986 Uniform Resource Identifier (URI): Generic Syntax T. Berners-Lee R. Fielding L. Masinter January 2005 ASCII HTML 61 Internet protocol uniform resource identifier www world wide web

A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]

draft-fielding-uri-rfc2396bis-07 RFC2732 RFC2396 RFC1808 RFC1738 RFC6874 RFC7320 RFC8820 STD0066 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3986 10.17487/RFC3986
RFC3987 Internationalized Resource Identifiers (IRIs) M. Duerst M. Suignard January 2005 ASCII HTML 46 uri uniform resource identifier Universal Character Set

This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.

The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.

draft-duerst-iri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=3987 10.17487/RFC3987
RFC3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol B. Black K. Kompella January 2005 ASCII HTML 9 mtu ldp lsp label switched path label switching router lsr

Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the Label Distribution Protocol (LDP) does not have the ability to signal the MTU for a Label Switched Path (LSP) to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for each LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document specifies experimental extensions to LDP in support of LSP MTU discovery. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mpls-ldp-mtu-extensions-03 EXPERIMENTAL EXPERIMENTAL IETF rtg mpls 10.17487/RFC3988
RFC3989 Middlebox Communications (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor February 2005 ASCII HTML 70 nat network address translator firewall

This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This memo provides information for the Internet community.

draft-ietf-midcom-semantics-08 RFC5189 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC3989
RFC3990 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement B. O'Hara P. Calhoun J. Kempf February 2005 ASCII HTML 5

This document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement. This memo provides information for the Internet community.

draft-ietf-capwap-problem-statement-02 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC3990
RFC3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package B. Foster F. Andreasen February 2005 ASCII HTML 11 voice IP internet VoIP

The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. This memo provides information for the Internet community.

draft-foster-mgcp-redirect-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3991
RFC3992 Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism B. Foster F. Andreasen February 2005 ASCII HTML 5 fault recovery

A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. This memo provides information for the Internet community.

draft-foster-mgcp-lockstep-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC3992
RFC3993 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option R. Johnson T. Palaniappan M. Stapp March 2005 ASCII HTML 7

This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

draft-ietf-dhc-subscriber-id-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC3993
RFC3994 Indication of Message Composition for Instant Messaging H. Schulzrinne January 2005 ASCII HTML 13 im status message content type xml extensible markup language

In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. [STANDARDS-TRACK]

draft-ietf-simple-iscomposing-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC3994
RFC3995 Internet Printing Protocol (IPP): Event Notifications and Subscriptions R. Herriot T. Hastings March 2005 ASCII HTML 95 optional subscription events subscription objects asynchronous even notification

This document describes an OPTIONAL extension to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. [STANDARDS-TRACK]

draft-ietf-ipp-not-spec-12 RFC2911 RFC2910 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp 10.17487/RFC3995
RFC3996 Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications R. Herriot T. Hastings H. Lewis March 2005 ASCII HTML 31 pull delivery method event notifications event subscriptions

This document describes an extension to the Internet Printing Protocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications by using the Get-Notifications operation defined in this document. [STANDARDS-TRACK]

draft-ietf-ipp-notify-get-10 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3996 10.17487/RFC3996
RFC3997 Internet Printing Protocol (IPP): Requirements for IPP Notifications T. Hastings Editor R. K. deBry H. Lewis March 2005 ASCII HTML 17 model directory services notification requirements

This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPP Service. This memo provides information for the Internet community.

draft-ietf-ipp-not-07 INFORMATIONAL INFORMATIONAL IETF app ipp 10.17487/RFC3997
RFC3998 Internet Printing Protocol (IPP): Job and Printer Administrative Operations C. Kugler H. Lewis T. Hastings Editor March 2005 ASCII HTML 46 system administration operations Enable-Printer and Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs and Release-Held-New-Jobs Deactivate-Printer and Activate-Printer Restart-Printer Shutdown-Printer and Startup-Printer Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Promote-Job Schedule-Job-After

This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet Printing Protocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. (Printer operations: Enable-Printer and Disable-Printer, Pause-Printer-After-Current-Job, Hold-New-Jobs and Release-Held-New-Jobs, Deactivate-Printer and Activate-Printer, Restart-Printer, Shutdown-Printer and Startup-Printer. Job operations: Reprocess-Job, Cancel-Current-Job, Suspend-Current-Job, Resume-Job, Promote-Job, Schedule-Job-After.) [STANDARDS-TRACK]

draft-ietf-ipp-ops-set2-04 PROPOSED STANDARD PROPOSED STANDARD IETF app ipp http://www.rfc-editor.org/errata_search.php?rfc=3998 10.17487/RFC3998
RFC3999 RFC4000 RFC4001 Textual Conventions for Internet Network Addresses M. Daniele B. Haberman S. Routhier J. Schoenwaelder February 2005 ASCII HTML 22 MIB management information base internet network layer addressing information

This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ops-rfc3291bis-06 RFC3291 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4001
RFC4002 IANA Registration for Enumservice 'web' and 'ft' R. Brandner L. Conroy R. Stastny February 2005 ASCII HTML 10 URI schemes uniform resource identifier enum

This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). [STANDARDS-TRACK]

draft-ietf-enum-webft-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4002
RFC4003 GMPLS Signaling Procedure for Egress Control L. Berger February 2005 ASCII HTML 5 lsp label switch path gmpls signaling

This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a Label Switched Path (LSP). This control is also known as "Egress Control". Support for Egress Control is implicit in Generalized Multi-Protocol Label Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-egress-control-03 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4003
RFC4004 Diameter Mobile IPv4 Application P. Calhoun T. Johansson C. Perkins T. Hiller Editor P. McCann August 2005 ASCII HTML 53 internet protocol version 4 aaa authentication authorization accounting inter-realm diameter accounting

This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-mobileip-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4004 10.17487/RFC4004
RFC4005 Diameter Network Access Server Application P. Calhoun G. Zorn D. Spence D. Mitton August 2005 ASCII HTML 85 aaa authentication authorization accounting nas diameter base transport profile extensible authentication protocol radius

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.

The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-nasreq-17 RFC7155 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4005 10.17487/RFC4005
RFC4006 Diameter Credit-Control Application H. Hakala L. Mattila J-P. Koskinen M. Stura J. Loughney August 2005 ASCII HTML 114 real-time credit-control

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-cc-06 RFC8506 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4006 10.17487/RFC4006
RFC4007 IPv6 Scoped Address Architecture S. Deering B. Haberman T. Jinmei E. Nordmark B. Zill March 2005 ASCII HTML 24 architectural characteristics expected behavior textual representation

This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]

draft-ietf-ipv6-scoping-arch-02 RFC7346 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4007
RFC4008 Definitions of Managed Objects for Network Address Translators (NAT) R. Rohit P. Srisuresh R. Raghunarayan N. Pai C. Wang March 2005 ASCII HTML 64 mib management information base

This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. [STANDARDS-TRACK]

draft-ietf-nat-natmib-09 RFC7658 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4008
RFC4009 The SEED Encryption Algorithm J. Park S. Lee J. Kim J. Lee February 2005 ASCII HTML 17 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). This memo provides information for the Internet community.

draft-park-seed-01 RFC4269 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4009 10.17487/RFC4009
RFC4010 Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS) J. Park S. Lee J. Kim J. Lee February 2005 ASCII HTML 13 smime secure/multipurpose internet mail extensions

This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).

SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs). One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. [STANDARDS-TRACK]

draft-ietf-smime-cms-seed-02 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4010 10.17487/RFC4010
RFC4011 Policy Based Management MIB S. Waldbusser J. Saperia T. Hongal March 2005 ASCII HTML 121 management information base Simple Network Management Protocol snmp infrastructures scripting language script execution environment

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol (SNMP) infrastructures, a scripting language, and a script execution environment. [STANDARDS-TRACK]

draft-ietf-snmpconf-pm-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops snmpconf 10.17487/RFC4011
RFC4012 Routing Policy Specification Language next generation (RPSLng) L. Blunk J. Damas F. Parent A. Robachevsky March 2005 ASCII HTML 16

This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK]

draft-blunk-rpslng-08 RFC2725 RFC2622 RFC7909 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4012
RFC4013 SASLprep: Stringprep Profile for User Names and Passwords K. Zeilenga February 2005 ASCII HTML 6 unicode strings saslprep stringprep sasl simple authentication and security layer

This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the "SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. [STANDARDS-TRACK]

draft-ietf-sasl-saslprep-10 RFC7613 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4013 10.17487/RFC4013
RFC4014 Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option R. Droms J. Schnizlein February 2005 ASCII HTML 8

The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. [STANDARDS-TRACK]

draft-ietf-dhc-agentopt-radius-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4014
RFC4015 The Eifel Response Algorithm for TCP R. Ludwig A. Gurtov February 2005 ASCII HTML 13 transmision control protocol

Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. [STANDARDS-TRACK]

draft-ietf-tsvwg-tcp-eifel-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4015
RFC4016 Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements M. Parthasarathy March 2005 ASCII HTML 15 authentication network access

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. This memo provides information for the Internet community.

draft-ietf-pana-threats-eval-07 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4016
RFC4017 Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs D. Stanley J. Walker B. Aboba March 2005 ASCII HTML 11 IEEE 802.11 wireless lan

The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo provides information for the Internet community.

draft-walker-ieee802-req-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4017
RFC4018 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) M. Bakke J. Hufferd K. Voruganti M. Krueger T. Sperry April 2005 ASCII HTML 23 scsi slp

The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. [PROPOSED STANDARD]

draft-ietf-ips-iscsi-slp-09 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4018
RFC4019 RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite G. Pelletier April 2005 ASCII HTML 23 rtp udp-lite ip real-time transport protocol user datagram protocol lite internet protocol

This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. [STANDARDS-TRACK]

draft-ietf-rohc-udp-lite-04 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4019
RFC4020 Early IANA Allocation of Standards Track Code Points K. Kompella A. Zinin February 2005 ASCII HTML 7

This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-kompella-zinin-early-allocation-02 RFC7120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4020
RFC4021 Registration of Mail and MIME Header Fields G. Klyne J. Palme March 2005 ASCII HTML 54 IANA

This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. [STANDARDS-TRACK]

draft-klyne-hdrreg-mail-05 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4021
RFC4022 Management Information Base for the Transmission Control Protocol (TCP) R. Raghunarayan Editor March 2005 ASCII HTML 24 MIB-TCP TCP Simple Network Management Protocol MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2012-update-06 RFC2452 RFC2012 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4022
RFC4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) T. Worster Y. Rekhter E. Rosen Editor March 2005 ASCII HTML 14

Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-TRACK]

draft-ietf-mpls-in-ip-or-gre-08 RFC5332 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4023
RFC4024 Voice Messaging Client Behaviour G. Parsons J. Maruszak July 2005 ASCII HTML 9 vpim profile internet mail voice profile for internet mail fax message

This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message. This memo provides information for the Internet community.

draft-ema-vpim-cb-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4024
RFC4025 A Method for Storing IPsec Keying Material in DNS M. Richardson March 2005 ASCII HTML 12

This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.

This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]

draft-ietf-ipseckey-rr-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipseckey 10.17487/RFC4025
RFC4026 Provider Provisioned Virtual Private Network (VPN) Terminology L. Andersson T. Madsen March 2005 ASCII HTML 20 l3vpn l2vpn

The widespread interest in provider-provisioned Virtual Private Network (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first Provider Provisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.

To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. This memo provides information for the Internet community.

draft-ietf-l3vpn-ppvpn-terminology-04 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4026 10.17487/RFC4026
RFC4027 Domain Name System Media Types S. Josefsson April 2005 ASCII HTML 6 media type application/dns text/dns

This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. This memo provides information for the Internet community.

draft-josefsson-mime-dns-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4027
RFC4028 Session Timers in the Session Initiation Protocol (SIP) S. Donovan J. Rosenberg April 2005 ASCII HTML 27 re-invite request update request session-expires min-se

This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a \%re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: \%Session-Expires, which conveys the lifetime of the session, and \%Min-SE, which conveys the minimum allowed value for the session timer. [STANDARDS-TRACK]

draft-ietf-sip-session-timer-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4028 10.17487/RFC4028
RFC4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks M. Lind V. Ksinant S. Park A. Baudot P. Savola March 2005 ASCII HTML 28 internet service provider internet protocol

This document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. This memo provides information for the Internet community.

draft-ietf-v6ops-isp-scenarios-analysis-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4029 10.17487/RFC4029
RFC4030 The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp T. Lemon March 2005 ASCII HTML 15

The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. [STANDARDS-TRACK]

draft-ietf-dhc-auth-suboption-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4030
RFC4031 Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) M. Carugi Editor D. McDysan Editor April 2005 ASCII HTML 50 l3vpn service provider vpn

This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. This memo provides information for the Internet community.

draft-ietf-l3vpn-requirements-02 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4031
RFC4032 Update to the Session Initiation Protocol (SIP) Preconditions Framework G. Camarillo P. Kyzivat March 2005 ASCII HTML 10 qos quality of service precondition

This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK]

draft-ietf-sip-rfc3312-update-03 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4032
RFC4033 DNS Security Introduction and Requirements R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII HTML 21 domain name system authentication origin integrity dnssec domain name system security extensions

The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-intro-13 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC6014 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4033 10.17487/RFC4033
RFC4034 Resource Records for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII HTML 29 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-records-11 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4034 10.17487/RFC4034
RFC4035 Protocol Modifications for the DNS Security Extensions R. Arends R. Austein M. Larson D. Massey S. Rose March 2005 ASCII HTML 53 domain name system authentication origin integrity dnssec domain name system security extensions

This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.

This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-protocol-09 RFC2535 RFC3008 RFC3090 RFC3445 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 RFC1034 RFC1035 RFC2136 RFC2181 RFC2308 RFC3225 RFC3597 RFC3226 RFC4470 RFC6014 RFC6840 RFC8198 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4035 10.17487/RFC4035
RFC4036 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management W. Sawyer April 2005 ASCII HTML 27 mib snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. [STANDARDS-TRACK]

draft-ietf-ipcdn-subscriber-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4036
RFC4037 Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core A. Rousskov March 2005 ASCII HTML 56 callout server

This document specifies the core of the Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCP Core consists of application-agnostic mechanisms essential for efficient support of typical adaptations. [STANDARDS-TRACK]

draft-ietf-opes-ocp-core-05 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4037
RFC4038 Application Aspects of IPv6 Transition M-K. Shin Editor Y-G. Hong J. Hagino P. Savola E. M. Castro March 2005 ASCII HTML 33

As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. This memo provides information for the Internet community.

draft-ietf-v6ops-application-transition-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4038
RFC4039 Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) S. Park P. Kim B. Volz March 2005 ASCII HTML 10

This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a 2-message exchange rather than the usual 4-message exchange, expediting client configuration. [STANDARDS-TRACK]

draft-ietf-dhc-rapid-commit-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4039
RFC4040 RTP Payload Format for a 64 kbit/s Transparent Call R. Kreuter April 2005 ASCII HTML 8 realtime transport protocol

This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called "Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".

"Clearmode" is a basic feature of VoIP Media Gateways. [STANDARDS-TRACK]

draft-ietf-avt-rtp-clearmode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4040
RFC4041 Requirements for Morality Sections in Routing Area Drafts A. Farrel April 1 2005 ASCII HTML 8 moral values moral code

It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.

This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community.

draft-farrel-rtg-morality-requirements-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4041
RFC4042 UTF-9 and UTF-18 Efficient Transformation Formats of Unicode M. Crispin April 1 2005 ASCII HTML 9 universal character set ucs codeopints unicode utf-7 utf-8 utf-16

ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.

The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.

This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4042
RFC4043 Internet X.509 Public Key Infrastructure Permanent Identifier D. Pinkas T. Gindin May 2005 ASCII HTML 15 subjectAltName extension dn

This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.

The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.

The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK]

draft-ietf-pkix-pi-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4043 10.17487/RFC4043
RFC4044 Fibre Channel Management MIB K. McCloghrie May 2005 ASCII HTML 69 management information base fc-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel. [STANDARDS-TRACK]

draft-ietf-ips-fcmgmt-mib-06 RFC2837 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4044
RFC4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) G. Bourdon April 2005 ASCII HTML 28 ppp point-to-point protocol

The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-l2tpext-mcast-05 EXPERIMENTAL EXPERIMENTAL IETF int l2tpext 10.17487/RFC4045
RFC4046 Multicast Security (MSEC) Group Key Management Architecture M. Baugher R. Canetti L. Dondeti F. Lindholm April 2005 ASCII HTML 38 group security association gsa

This document defines the common architecture for Multicast Security (MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. This memo provides information for the Internet community.

draft-ietf-msec-gkmarch-08 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4046
RFC4047 MIME Sub-type Registrations for Flexible Image Transport System (FITS) S. Allen D. Wells April 2005 ASCII HTML 23 multipurpose internet mail extensions astronomical observations

This document describes the registration of the Multipurpose Internet Mail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible Image Transport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. This memo provides information for the Internet community.

draft-allen-fitsmime-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4047
RFC4048 RFC 1888 Is Obsolete B. Carpenter April 2005 ASCII HTML 4 Internet Protocol Open Systems Interconnection

This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.

draft-carpenter-obsolete-1888-01 RFC1888 RFC4548 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4048 10.17487/RFC4048
RFC4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley April 2005 ASCII HTML 7 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. This memo defines an Experimental Protocol for the Internet community.

draft-housley-binarytime-02 RFC6019 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4049
RFC4050 Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures S. Blake-Wilson G. Karlinger T. Kobayashi Y. Wang April 2005 ASCII HTML 19 elliptic curve digital signature algorithm ecdsa elliptic curve cryptography ecc xml digital signatures xml dsig xml

This document specifies how to use Elliptic Curve Digital Signature Algorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. This memo provides information for the Internet community.

draft-blake-wilson-xmldsig-ecdsa-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4050
RFC4051 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2005 ASCII HTML 17 digital signatures encryption canonicalization

A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information. [STANDARDS-TRACK]

draft-eastlake-xmldsig-uri-09 RFC6931 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4051 10.17487/RFC4051
RFC4052 IAB Processes for Management of IETF Liaison Relationships L. Daigle Editor Internet Architecture Board April 2005 ASCII HTML 9 internet architecture board sdo standards development organization

This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-liaison-mgt-03 BCP0102 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB http://www.rfc-editor.org/errata_search.php?rfc=4052 10.17487/RFC4052
RFC4053 Procedures for Handling Liaison Statements to and from the IETF S. Trowbridge S. Bradner F. Baker April 2005 ASCII HTML 19 sdo standards develoopment organization

This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.

The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-baker-liaison-statements-04 BCP0103 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4053
RFC4054 Impairments and Other Constraints on Optical Layer Routing J. Strand Editor A. Chiu Editor May 2005 ASCII HTML 29 diversity routing path selection impariment ase pmd optical control plane gmpls

Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1) Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. This memo provides information for the Internet community.

draft-ietf-ipo-impairments-04 INFORMATIONAL INFORMATIONAL IETF subip ipo 10.17487/RFC4054
RFC4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile J. Schaad B. Kaliski R. Housley June 2005 ASCII HTML 25 ASN.1 RSASSA-PSS RSA probabilistic signature scheme signature algorithm RSAES-OAEP RSA encryption scheme optimal asymmetric encryption padding public-key cryptography standards PKCS pki

This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]

draft-ietf-pkix-rsa-pkalgs-03 RFC3279 RFC5756 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4055 10.17487/RFC4055
RFC4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) J. Schaad June 2005 ASCII HTML 6 RSA probabilistic signature scheme digital signature

This document specifies the conventions for using the RSASSA-PSS (RSA Probabilistic Signature Scheme) digital signature algorithm with the Cryptographic Message Syntax (CMS). [STANDARDS-TRACK]

draft-ietf-smime-pss-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4056
RFC4057 IPv6 Enterprise Network Scenarios J. Bound Editor June 2005 ASCII HTML 17 internet protocol version 6

This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. This memo provides information for the Internet community.

draft-ietf-v6ops-ent-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4057 10.17487/RFC4057
RFC4058 Protocol for Carrying Authentication for Network Access (PANA) Requirements A. Yegin Editor Y. Ohba R. Penno G. Tsirtsis C. Wang May 2005 ASCII HTML 19 network connectivity link layer agnostic protocol

It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure. This memo provides information for the Internet community.

draft-ietf-pana-requirements-09 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC4058
RFC4059 Internet X.509 Public Key Infrastructure Warranty Certificate Extension D. Linsenbardt S. Pontius A. Sturgeon May 2005 ASCII HTML 9 certificate authority ca insurance policy

This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This memo provides information for the Internet community.

draft-ietf-pkix-warranty-extn-04 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4059
RFC4060 RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding Q. Xie D. Pearce May 2005 ASCII HTML 19 real-time transport protocol dsr distributed speeech recognition xfe extended front-end xafe extended advanced front-end

This document specifies RTP payload formats for encapsulating European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSR Extended Front-end (XFE), and ES 202 212 DSR Extended Advanced Front-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. [STANDARDS-TRACK]

draft-ietf-avt-rtp-dsr-codecs-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4060 10.17487/RFC4060
RFC4061 Benchmarking Basic OSPF Single Router Control Plane Convergence V. Manral R. White A. Shaikh April 2005 ASCII HTML 16 spf time adjacency formation time

This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.

NOTE: In this document, the word "convergence" relates to single router control plane convergence only. This memo provides information for the Internet community.

draft-ietf-bmwg-ospfconv-intraarea-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4061
RFC4062 OSPF Benchmarking Terminology and Concepts V. Manral R. White A. Shaikh April 2005 ASCII HTML 9 spf time adjacency formation time

This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. This memo provides information for the Internet community.

draft-ietf-bmwg-ospfconv-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4062
RFC4063 Considerations When Using Basic OSPF Convergence Benchmarks V. Manral R. White A. Shaikh April 2005 ASCII HTML 11 spf time adjacency formation time

This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. This memo provides information for the Internet community.

draft-ietf-bmwg-ospfconv-applicability-07 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4063
RFC4064 Experimental Message, Extensions, and Error Codes for Mobile IPv4 A. Patel K. Leung May 2005 ASCII HTML 11 internet protocol message types

Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. [STANDARDS-TRACK]

draft-ietf-mip4-experimental-messages-02 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4064
RFC4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations J. Kempf July 2005 ASCII HTML 8 candidate access router discovery card context transfer protocol CXTP ICMP

The Seamoby Candidate Access Router Discovery (CARD) protocol and the Context Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, Stream Control Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options. This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-seamoby-iana-02 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4065
RFC4066 Candidate Access Router Discovery (CARD) M. Liebsch Editor A. Singh Editor H. Chaskar D. Funato E. Shim July 2005 ASCII HTML 46 mobile node mn cars candidate ars

To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery of CARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-seamoby-card-protocol-08 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4066
RFC4067 Context Transfer Protocol (CXTP) J. Loughney Editor M. Nakhjiri C. Perkins R. Koodli July 2005 ASCII HTML 33 mobile node mn

This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-seamoby-ctp-11 EXPERIMENTAL EXPERIMENTAL IETF tsv seamoby 10.17487/RFC4067
RFC4068 Fast Handovers for Mobile IPv6 R. Koodli Editor July 2005 ASCII HTML 42 internet protocol version 6 access router mobile node mn

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mipshop-fast-mipv6-03 RFC5268 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC4068
RFC4069 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding M. Dodge B. Ray May 2005 ASCII HTML 19 mib management information base VDSL-LINE-MIB VDSL-LINE-EXT-SCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Single Carrier Modulation (SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl-ext-scm-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4069
RFC4070 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding M. Dodge B. Ray May 2005 ASCII HTML 24 management information base mib VDSL-LINE-MIB VDSL-LINE-EXT-MCM-MIB

This document defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed Digital Subscriber Line (VDSL) interfaces using Multiple Carrier Modulation (MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB, RFC 3728, which handles line code independent objects. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl-ext-mcm-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4070
RFC4071 Structure of the IETF Administrative Support Activity (IASA) R. Austein Editor B. Wijnen Editor April 2005 ASCII HTML 20 isoc ietf administrative oversight committee IAOC ietf administrative director iad

This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-iasa-bcp-07 RFC8711 RFC4371 RFC7691 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4071
RFC4072 Diameter Extensible Authentication Protocol (EAP) Application P. Eronen Editor T. Hiller G. Zorn August 2005 ASCII HTML 33 command codes avp nas network access server back-end autentication server

The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. [STANDARDS-TRACK]

draft-ietf-aaa-eap-10 RFC7268 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4072 10.17487/RFC4072
RFC4073 Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) R. Housley May 2005 ASCII HTML 9 content collection

This document describes a convention for using the Cryptographic Message Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. [STANDARDS-TRACK]

draft-housley-contentcollection-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4073 10.17487/RFC4073
RFC4074 Common Misbehavior Against DNS Queries for IPv6 Addresses Y. Morishita T. Jinmei May 2005 ASCII HTML 6 resource records aaaa domain name service

There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. This memo provides information for the Internet community.

draft-ietf-dnsop-misbehavior-against-aaaa-02 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4074
RFC4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 V. Kalusivalingam May 2005 ASCII HTML 5 dynamic host configuration protocol server addresses

This document describes a new DHCPv6 option for passing a list of Simple Network Time Protocol (SNTP) server addresses to a client. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-opt-sntp-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4075
RFC4076 Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Chown S. Venaas A. Vijayabhaskar May 2005 ASCII HTML 8 internet protocol stateless address autoconfiguration

IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. This memo provides information for the Internet community.

draft-ietf-dhc-stateless-dhcpv6-renumbering-02 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4076
RFC4077 A Negative Acknowledgement Mechanism for Signaling Compression A.B. Roach May 2005 ASCII HTML 16 sigcomp negative feedback

This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. [STANDARDS-TRACK]

draft-ietf-rohc-sigcomp-nack-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4077
RFC4078 The TV-Anytime Content Reference Identifier (CRID) N. Earnshaw S. Aoki A. Ashley W. Kameyama May 2005 ASCII HTML 10 digital broadcasting tv radio uri uniform resource identifier content referencing storage systems

The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.

The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.

This document reproduces the \%TV-Anytime CRID definition found in the \%TV-Anytime content referencing specification, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority (IANA). This memo provides information for the Internet community.

draft-earnshaw-tv-anytime-crid-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4078
RFC4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects J. Peterson July 2005 ASCII HTML 7 using protocol

GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV. This memo provides information for the Internet community.

draft-ietf-geopriv-pres-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC4079
RFC4080 Next Steps in Signaling (NSIS): Framework R. Hancock G. Karagiannis J. Loughney S. Van den Bosch June 2005 ASCII HTML 49 data flow architectural framework signaling protocols signaling application

The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.

This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. This memo provides information for the Internet community.

draft-ietf-nsis-fw-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4080
RFC4081 Security Threats for Next Steps in Signaling (NSIS) H. Tschofenig D. Kroeselberg June 2005 ASCII HTML 28

This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. This memo provides information for the Internet community.

draft-ietf-nsis-threats-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4081
RFC4082 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction A. Perrig D. Song R. Canetti J. D. Tygar B. Briscoe June 2005 ASCII HTML 22 data streams

This document introduces Timed Efficient Stream Loss-tolerant Authentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.

This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. This memo provides information for the Internet community.

draft-ietf-msec-tesla-intro-04 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC4082
RFC4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) M. Garcia-Martin May 2005 ASCII HTML 36 3GPP IP multimedia core network subsystem ims cellular networks

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks. This memo provides information for the Internet community.

draft-ietf-sipping-3gpp-r5-requirements-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4083
RFC4084 Terminology for Describing Internet Connectivity J. Klensin May 2005 ASCII HTML 11

As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-ip-service-terms-04 BCP0104 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4084 10.17487/RFC4084
RFC4085 Embedding Globally-Routable Internet Addresses Considered Harmful D. Plonka June 2005 ASCII HTML 10

This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. This document is intended to clarify best current practices in this regard. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-embed-addr-05 BCP0105 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4085
RFC4086 Randomness Requirements for Security D. Eastlake 3rd J. Schiller S. Crocker June 2005 ASCII HTML 48 cryptographic algorithms passwords cryptographic keys pseudo-random random numbers seed

Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.

Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-eastlake-randomness2-10 RFC1750 BCP0106 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4086 10.17487/RFC4086
RFC4087 IP Tunnel MIB D. Thaler June 2005 ASCII HTML 25 management information base internet protocol tunnel-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667. [STANDARDS-TRACK]

draft-ietf-ipv6-inet-tunnel-mib-03 RFC2667 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4087
RFC4088 Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) D. Black K. McCloghrie J. Schoenwaelder June 2005 ASCII HTML 18 uri uniform resource identifiers snmp-uri

The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.

This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. [STANDARDS-TRACK]

draft-black-snmp-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4088
RFC4089 IAB and IESG Recommendation for IETF Administrative Restructuring S. Hollenbeck Editor IAB and IESG May 2005 ASCII HTML 55 internet architecture board internet engineering steering group internet engineering task force

This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.

draft-iab-iesg-adminrest-rec-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4089
RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels P. Pan Editor G. Swallow Editor A. Atlas Editor May 2005 ASCII HTML 38 resource reservation protocol traffic engineering lsp label switch path one-to-one backup facility backup

This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.

Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-lsp-fastreroute-07 RFC8271 RFC8537 RFC8796 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4090 10.17487/RFC4090
RFC4091 The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework G. Camarillo J. Rosenberg June 2005 ASCII HTML 7

This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. [STANDARDS-TRACK]

draft-ietf-mmusic-anat-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4091
RFC4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) G. Camarillo J. Rosenberg June 2005 ASCII HTML 6 sdp-anat option-tag

This document describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. [STANDARDS-TRACK]

draft-ietf-sip-anat-usage-00 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4092
RFC4093 Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways F. Adrangi Editor H. Levkowetz Editor August 2005 ASCII HTML 19

Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. This memo provides information for the Internet community.

draft-ietf-mip4-vpn-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC4093
RFC4094 Analysis of Existing Quality-of-Service Signaling Protocols J. Manner X. Fu May 2005 ASCII HTML 45 qos quality of service rsvp nsis yessir boomerang daris insignia bgrp sicap mobility performance security

This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. This memo provides information for the Internet community.

draft-ietf-nsis-signalling-analysis-05 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC4094
RFC4095 Attaching Meaning to Solicitation Class Keywords C. Malamud May 2005 ASCII HTML 11 uri uniform resource identifier no soliciting smtp service extension esmtp service extension dynamic delegation discovery system ddds no-solicit

This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the No Soliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new \%"No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.

This document specifies an application based on the Dynamic Delegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the "org.example.adv" solicitation class keyword. [STANDARDS-TRACK]

draft-malamud-keyword-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4095
RFC4096 Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best C. Malamud May 2005 ASCII HTML 14

This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, \%standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. This memo provides information for the Internet community.

draft-malamud-subject-line-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4096
RFC4097 Middlebox Communications (MIDCOM) Protocol Evaluation M. Barnes Editor June 2005 ASCII HTML 44 snmp simple network management protocol rsip realm specific internet protocol megaco diameter cops common open policy service

This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. This memo provides information for the Internet community.

draft-ietf-midcom-protocol-eval-06 INFORMATIONAL INFORMATIONAL IETF tsv midcom 10.17487/RFC4097
RFC4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane H. Berkowitz E. Davies Editor S. Hares P. Krishnaswamy M. Lepp June 2005 ASCII HTML 36 border gateway protocol benchmarking methodology ebgp

This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices.This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. This memo provides information for the Internet community.

draft-ietf-bmwg-conterm-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4098
RFC4099 RFC4100 RFC4101 Writing Protocol Models E. Rescorla IAB June 2005 ASCII HTML 22 document review

The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. This memo provides information for the Internet community.

draft-iab-model-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4101
RFC4102 Registration of the text/red MIME Sub-Type P. Jones June 2005 ASCII HTML 6 rtp real-time transport protocol

This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. [STANDARDS-TRACK]

draft-ietf-avt-text-red-05 RFC6354 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4102 10.17487/RFC4102
RFC4103 RTP Payload for Text Conversation G. Hellstrom P. Jones June 2005 ASCII HTML 20 real-time applications video audio packets

This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. [STANDARDS-TRACK]

draft-ietf-avt-rfc2793bis-09 RFC2793 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4103 10.17487/RFC4103
RFC4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS) M. Pana Editor A. Reyes A. Barba D. Moron M. Brunner June 2005 ASCII HTML 88 policy core lightweight directory access protocol pcim policy core information model mapping classes

This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. [STANDARDS-TRACK]

draft-reyes-policy-core-ext-schema-07 RFC3703 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4104
RFC4105 Requirements for Inter-Area MPLS Traffic Engineering J.-L. Le Roux Editor J.-P. Vasseur Editor J. Boyle Editor June 2005 ASCII HTML 22 multiprotocol label switching mpls-te mpls te

This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. This memo provides information for the Internet community.

draft-ietf-tewg-interarea-mpls-te-req-03 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4105
RFC4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) J. Viega D. McGrew June 2005 ASCII HTML 11 aes advanced encryption standard

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

draft-ietf-ipsec-ciph-aes-gcm-00 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4106 10.17487/RFC4106
RFC4107 Guidelines for Cryptographic Key Management S. Bellovin R. Housley June 2005 ASCII HTML 7 automated key management manual key management

The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bellovin-mandate-keymgmt-03 BCP0107 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4107
RFC4108 Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages R. Housley August 2005 ASCII HTML 61 hardward module components digital signature

This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK]

draft-housley-cms-fw-wrap-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4108 10.17487/RFC4108
RFC4109 Algorithms for Internet Key Exchange version 1 (IKEv1) P. Hoffman May 2005 ASCII HTML 5 ike ipsec oakley authentication isakmp internet security key management

The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. [STANDARDS-TRACK]

draft-hoffman-ikev1-algorithms-03 RFC2409 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4109
RFC4110 A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) R. Callon M. Suzuki July 2005 ASCII HTML 82

This document provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. This memo provides information for the Internet community.

draft-ietf-l3vpn-framework-00 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4110
RFC4111 Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) L. Fang Editor July 2005 ASCII HTML 45

This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. This memo provides information for the Internet community.

draft-ietf-l3vpn-security-framework-03 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4111 10.17487/RFC4111
RFC4112 Electronic Commerce Modeling Language (ECML) Version 2 Specification D. Eastlake 3rd June 2005 ASCII HTML 34

Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic Commerce Modeling Language (ECML) and is intended to meet the requirements of RFC 3505. [STANDARDS-TRACK]

draft-ietf-trade-ecml2-spec-13 RFC3106 PROPOSED STANDARD PROPOSED STANDARD IETF app trade 10.17487/RFC4112
RFC4113 Management Information Base for the User Datagram Protocol (UDP) B. Fenner J. Flick June 2005 ASCII HTML 19 MIB-UDP mib UDP-MIB internet protocol ip

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2013-update-04 RFC2454 RFC2013 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4113 10.17487/RFC4113
RFC4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck June 2005 ASCII HTML 17 shared central repository

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers. [STANDARDS-TRACK]

draft-ietf-enum-epp-e164-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=4114 10.17487/RFC4114
RFC4115 A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic O. Aboul-Magd S. Rabie July 2005 ASCII HTML 6 data services service scenarios metering algorithm color-blind color-aware

This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community.

draft-aboulmagd-trtcm-inprofile-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4115
RFC4116 IPv4 Multihoming Practices and Limitations J. Abley K. Lindqvist E. Davies B. Black V. Gill July 2005 ASCII HTML 13 internet protocol

Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). This memo provides information for the Internet community.

draft-ietf-multi6-v4-multihoming-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4116
RFC4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) G. Camarillo E. Burger H. Schulzrinne A. van Wijk June 2005 ASCII HTML 19 deaf hard of hearing speech-impaired hearing-impaired

This document describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. This memo provides information for the Internet community.

draft-ietf-sipping-transc-3pcc-02 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4117 10.17487/RFC4117
RFC4118 Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP) L. Yang P. Zerfos E. Sadot June 2005 ASCII HTML 41 IEEE 802.11 wireless lan

This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing Wireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. This memo provides information for the Internet community.

draft-ietf-capwap-arch-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4118
RFC4119 A Presence-based GEOPRIV Location Object Format J. Peterson December 2005 ASCII HTML 24 pidf presence information data format

This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK]

draft-ietf-geopriv-pidf-lo-03 RFC5139 RFC5491 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4119 10.17487/RFC4119
RFC4120 The Kerberos Network Authentication Service (V5) C. Neuman T. Yu S. Hartman K. Raeburn July 2005 ASCII HTML 138 KERBEROS CAT Security

This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK]

draft-ietf-krb-wg-kerberos-clarifications-07 RFC1510 RFC4537 RFC5021 RFC5896 RFC6111 RFC6112 RFC6113 RFC6649 RFC6806 RFC7751 RFC8062 RFC8129 RFC8429 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4120 10.17487/RFC4120
RFC4121 The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 L. Zhu K. Jaganathan S. Hartman July 2005 ASCII HTML 20 GSSAPI-KER cryptosystem

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Kerberos Version 5 mechanism.

RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles. [STANDARDS-TRACK]

draft-ietf-krb-wg-gssapi-cfx-07 RFC1964 RFC5896 RFC6112 RFC6542 RFC6649 RFC8062 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4121
RFC4122 A Universally Unique IDentifier (UUID) URN Namespace P. Leach M. Mealling R. Salz July 2005 ASCII HTML 32 uniform resource name guid globally unique identifier

This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.

This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]

draft-mealling-uuid-urn-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4122 10.17487/RFC4122
RFC4123 Session Initiation Protocol (SIP)-H.323 Interworking Requirements H. Schulzrinne C. Agboh July 2005 ASCII HTML 16 SIP-H.323 IWF

This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323. This memo provides information for the Internet community.

draft-agrawal-sip-h323-interworking-reqs-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4123
RFC4124 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII HTML 37 DS-TE igp interior gateway protocol extensions rsvp resource reservation protocol

This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]

draft-ietf-tewg-diff-te-proto-08 PROPOSED STANDARD PROPOSED STANDARD IETF subip tewg 10.17487/RFC4124
RFC4125 Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur W. Lai June 2005 ASCII HTML 12 ds-te maximum allocation model

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tewg-diff-te-mam-04 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4125
RFC4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons J. Ash June 2005 ASCII HTML 22 diffserv-enabled mpls traffic engineering ds-te mar bandwidth reservation bandwidth allocation bandwidth protection performance evaluation cac network model

This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tewg-diff-te-mar-06 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4126
RFC4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering F. Le Faucheur Editor June 2005 ASCII HTML 13 ds-te russian dolls model multi-protocol label switching

This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tewg-diff-te-russian-07 EXPERIMENTAL EXPERIMENTAL IETF subip tewg 10.17487/RFC4127
RFC4128 Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation W. Lai June 2005 ASCII PDF HTML 25 label switched path lsp lsp blocking lsp preemption lsp priority traffic overload bandwidth efficiency bandwidth sharing bandwidth protection class isolation maximum allocation model russian dolls model

"Differentiated Services (Diffserv)-aware MPLS Traffic Engineering Requirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, the Maximum Allocation and the Russian Dolls, are described therein. This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. This memo provides information for the Internet community.

draft-wlai-tewg-bcmodel-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4128
RFC4129 Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol R. Mukundan K. Morneault N. Mangalpally September 2005 ASCII HTML 15 backhauling isdn user adaptation pbx private branch exchanges

This document defines a mechanism for backhauling Digital Private Network Signaling System 1 (DPNSS 1) and Digital Access Signaling System 2 (DASS 2) messages over IP by extending the ISDN User Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network. DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN. This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. [STANDARDS-TRACK]

draft-ietf-sigtran-dua-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4129
RFC4130 MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) D. Moberg R. Drummond July 2005 ASCII HTML 47 hyper text transfer protocol simple mail transfer protocol

This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335. [STANDARDS-TRACK]

draft-ietf-ediint-as2-20 PROPOSED STANDARD PROPOSED STANDARD IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4130 10.17487/RFC4130
RFC4131 Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus S. Green K. Ozawa E. Cardona Editor A. Katsnelson September 2005 ASCII HTML 85 mib snmp simple network management protocol docs-ietf-bpi2-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Baseline Privacy Plus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable Service Interface Specification) compliant Cable Modems and Cable Modem Termination Systems. [STANDARDS-TRACK]

draft-ietf-ipcdn-bpiplus-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4131
RFC4132 Addition of Camellia Cipher Suites to Transport Layer Security (TLS) S. Moriai A. Kato M. Kanda July 2005 ASCII HTML 7 camellia encryption algorithm

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

draft-ietf-tls-camellia-06 RFC5932 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4132
RFC4133 Entity MIB (Version 3) A. Bierman K. McCloghrie August 2005 ASCII HTML 62 management information base snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737). [STANDARDS-TRACK]

draft-ietf-entmib-v3-07 RFC2737 RFC6933 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4133 10.17487/RFC4133
RFC4134 Examples of S/MIME Messages P. Hoffman Editor July 2005 ASCII HTML 136

This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This memo provides information for the Internet community.

draft-ietf-smime-examples-15 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4134 10.17487/RFC4134
RFC4135 Goals of Detecting Network Attachment in IPv6 JH. Choi G. Daley August 2005 ASCII HTML 9 dna detecting attachment links change detection

When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling. This memo provides information for the Internet community.

draft-ietf-dna-goals-04 INFORMATIONAL INFORMATIONAL IETF int dna 10.17487/RFC4135
RFC4136 OSPF Refresh and Flooding Reduction in Stable Topologies P. Pillay-Esnault July 2005 ASCII HTML 5 open shortest path first link state advertisement lsa donotage

This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.

Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. This memo provides information for the Internet community.

draft-pillay-esnault-ospf-flooding-07 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4136
RFC4137 State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator J. Vollbrecht P. Eronen N. Petroni Y. Ohba August 2005 ASCII PDF HTML 51 eap stand-alone authenticator eap backend authenticator eap full authenticator

This document describes a set of state machines for Extensible Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.

The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.

The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

draft-ietf-eap-statemachine-06 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC4137
RFC4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) P. Sarolahti M. Kojo August 2005 ASCII HTML 23 tcp transmission control protocol

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-frto-02 RFC5682 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC4138
RFC4139 Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) D. Papadimitriou J. Drake J. Ash A. Farrel L. Ong July 2005 ASCII HTML 16 tdm otn control plane call connection

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-reqts-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4139
RFC4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6) H. Soliman C. Castelluccia K. El Malki L. Bellier August 2005 ASCII HTML 29 internet protocol version 6 neighbour discovery neighbor discovery mobility anchor point map

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mipshop-hmipv6-04 RFC5380 EXPERIMENTAL EXPERIMENTAL IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4140 10.17487/RFC4140
RFC4141 SMTP and MIME Extensions for Content Conversion K. Toyoda D. Crocker November 2005 ASCII HTML 26 esmtp simple mail transfer protocol extended simple mail transfer protocol multipurpose internet mail extensions

A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries. [STANDARDS-TRACK]

draft-ietf-fax-esmtp-conneg-13 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4141 10.17487/RFC4141
RFC4142 Full-mode Fax Profile for Internet Mail (FFPIM) D. Crocker G. Klyne November 2005 ASCII HTML 9 facsimile full mode internet mail

Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users. [PROPOSED STANDARD]

draft-ietf-fax-ffpim-08 PROPOSED STANDARD PROPOSED STANDARD IETF app fax 10.17487/RFC4142
RFC4143 Facsimile Using Internet Mail (IFAX) Service of ENUM K. Toyoda D. Crocker November 2005 ASCII HTML 5 naptr enum naming authority pointer facsimile using internet mail dns domain name system

This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service. IFax is "facsimile using Internet mail". For this use, the Domain Name System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address. [STANDARDS-TRACK]

draft-ietf-fax-faxservice-enum-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app fax http://www.rfc-editor.org/errata_search.php?rfc=4143 10.17487/RFC4143
RFC4144 How to Gain Prominence and Influence in Standards Organizations D. Eastlake 3rd September 2005 ASCII HTML 9

This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations. This memo provides information for the Internet community.

draft-eastlake-prominence-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4144
RFC4145 TCP-Based Media Transport in the Session Description Protocol (SDP) D. Yon G. Camarillo September 2005 ASCII HTML 15 setup connection reestablishment

This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-comedia-10 RFC4572 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4145
RFC4146 Simple New Mail Notification R. Gellens August 2005 ASCII HTML 5 mail client nm_notifyuser

This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.

In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. This memo provides information for the Internet community.

draft-gellens-notify-mail-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4146
RFC4147 Proposed Changes to the Format of the IANA IPv6 Registry G. Huston August 2005 ASCII HTML 10 internet protocol version 6 address format address architecture

This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format. The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format. This memo provides information for the Internet community.

draft-huston-ip6-iana-registry-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4147 10.17487/RFC4147
RFC4148 IP Performance Metrics (IPPM) Metrics Registry E. Stephan August 2005 ASCII HTML 14 internet protocol object identities iana-ippm-metrics-registry-mib

This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF.

This memo also defines the rules for adding IP Performance Metrics that are defined in the future and for encouraging all IP performance metrics to be registered here.

IANA has been assigned to administer this new registry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ippm-metrics-registry-08 RFC6248 BCP0108 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm 10.17487/RFC4148
RFC4149 Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms C. Kalbfleisch R. Cole D. Romascanu August 2005 ASCII HTML 39 sspm mib management information base sspm mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. [STANDARDS-TRACK]

draft-ietf-rmonmib-sspm-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4149
RFC4150 Transport Performance Metrics MIB R. Dietz R. Cole August 2005 ASCII HTML 57 managgement information base tpm tpm-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources. [STANDARDS-TRACK]

draft-ietf-rmonmib-tpm-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4150
RFC4151 The 'tag' URI Scheme T. Kindberg S. Hawke October 2005 ASCII HTML 11 uniform resource identifier entity identifier

This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community.

draft-kindberg-tag-uri-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4151 10.17487/RFC4151
RFC4152 A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code K. Tesink R. Fox August 2005 ASCII HTML 7 ansi ansi t1.213

This document describes a Uniform Resource Name (URN) namespace (RFC 3406) for the assignment of the Common Language Equipment Identifier (CLEI) code, which is used in messages standardized by ANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. The CLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number). This memo provides information for the Internet community.

draft-tesink-urn-clei-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4152
RFC4153 XML Voucher: Generic Voucher Language K. Fujimura M. Terada D. Eastlake 3rd September 2005 ASCII HTML 21 extensible markup language logical entity

This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

draft-ietf-trade-voucher-lang-07 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4153
RFC4154 Voucher Trading System Application Programming Interface (VTS-API) M. Terada K. Fujimura September 2005 ASCII HTML 32 wallet transfer redeem

This document specifies the Voucher Trading System Application Programming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions. This memo provides information for the Internet community.

draft-ietf-trade-voucher-vtsapi-06 INFORMATIONAL INFORMATIONAL IETF app trade 10.17487/RFC4154
RFC4155 The application/mbox Media Type E. Hall September 2005 ASCII HTML 9 mbox database

This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. This memo provides information for the Internet community.

draft-hall-mime-app-mbox-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4155
RFC4156 The wais URI Scheme P. Hoffman August 2005 ASCII HTML 4 uniform resource identifier

This document specifies the wais Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

draft-hoffman-wais-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4156 10.17487/RFC4156
RFC4157 The prospero URI Scheme P. Hoffman August 2005 ASCII HTML 4 uniform resource identifier

This document specifies the prospero Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. This memo defines a Historic Document for the Internet community.

draft-hoffman-prospero-uri-03 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4157 10.17487/RFC4157
RFC4158 Internet X.509 Public Key Infrastructure: Certification Path Building M. Cooper Y. Dzambasow P. Hesse S. Joseph R. Nicholas September 2005 ASCII HTML 81 certification path discovery path discovery certificate path building certificate path discovery

This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. This memo provides information for the Internet community.

draft-ietf-pkix-certpathbuild-05 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC4158
RFC4159 Deprecation of "ip6.int" G. Huston August 2005 ASCII HTML 3 ipv6 dns domain name system

This document advises of the deprecation of the use of "ip6.int" for Standards Conformant IPv6 implementations. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-huston-ip6-int-03 BCP0109 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4159
RFC4160 Internet Fax Gateway Requirements K. Mimura K. Yokoyama T. Satoh C. Kanaide C. Allocchio August 2005 ASCII HTML 13 general switched telephone network facsimile service gstn fax internet fax service i-fax onramp gateway

To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. This memo provides information for the Internet community.

draft-ietf-fax-gateway-protocol-13 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4160
RFC4161 Guidelines for Optional Services for Internet Fax Gateways K. Mimura K. Yokoyama T. Satoh K. Watanabe C. Kanaide August 2005 ASCII HTML 12 general switched telephone network acsimile service gstn fax internet fax service i-fax offramp gateway onramp gateway

To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.

This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. This memo provides information for the Internet community.

draft-ietf-fax-gateway-options-08 INFORMATIONAL INFORMATIONAL IETF app fax 10.17487/RFC4161
RFC4162 Addition of SEED Cipher Suites to Transport Layer Security (TLS) H.J. Lee J.H. Yoon J.I. Lee August 2005 ASCII HTML 6 encryption algorithm ciphersuite

This document proposes the addition of new cipher suites to the Transport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm. [STANDARDS-TRACK]

draft-lee-tls-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4162
RFC4163 RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression L-E. Jonsson August 2005 ASCII HTML 9 transmission control protocol internet protocol compression performance considerations intellectual property rights ipr

This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression (ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC. This memo provides information for the Internet community.

draft-ietf-rohc-tcp-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4163
RFC4164 RObust Header Compression (ROHC): Context Replication for ROHC Profiles G. Pelletier August 2005 ASCII HTML 21 context initialization short-lived

This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows. [STANDARDS-TRACK]

draft-ietf-rohc-context-replication-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4164
RFC4165 Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) T. George B. Bidulock R. Dantu H. Schwarzbauer K. Morneault September 2005 ASCII HTML 53 ss7 over ip ss7/ip sigtran m2ua

This document defines a protocol supporting the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints. [STANDARDS-TRACK]

draft-ietf-sigtran-m2pa-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4165 10.17487/RFC4165
RFC4166 Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement L. Coene J. Pastor-Balbas February 2006 ASCII HTML 23

This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control Transmission Protocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given. This memo provides information for the Internet community.

draft-ietf-sigtran-signalling-over-sctp-applic-09 INFORMATIONAL INFORMATIONAL IETF rai sigtran 10.17487/RFC4166
RFC4167 Graceful OSPF Restart Implementation Report A. Lindem October 2005 ASCII HTML 6 open shortest path first

Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. This memo provides information for the Internet community.

draft-ietf-ospf-graceful-impl-report-05 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC4167
RFC4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne G. Camarillo October 2005 ASCII HTML 10 transport mechanism

This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. [STANDARDS-TRACK]

draft-ietf-sip-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4168
RFC4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 V. Torvinen J. Arkko M. Naslund November 2005 ASCII HTML 13 tls transport layer security tunneled authentication man-in-the-middle attacks

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. This memo provides information for the Internet community.

draft-torvinen-http-digest-aka-v2-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4169
RFC4170 Tunneling Multiplexed Compressed RTP (TCRTP) B. Thompson T. Koren D. Wing November 2005 ASCII HTML 24 real-time transport protocol

This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-avt-tcrtp-08 BCP0110 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai avt 10.17487/RFC4170
RFC4171 Internet Storage Name Service (iSNS) J. Tseng K. Gibbons F. Travostino C. Du Laney J. Souza September 2005 ASCII HTML 123 isns servers isns clients fibre channel devices ifcp intelligent storage discovery

This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. [STANDARDS-TRACK]

draft-ietf-ips-isns-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4171 10.17487/RFC4171
RFC4172 iFCP - A Protocol for Internet Fibre Channel Storage Networking C. Monia R. Mullendore F. Travostino W. Jeong M. Edwards September 2005 ASCII HTML 111 gateway-to-gateway fibre channel fabric tcp transport control protocol

This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network. [STANDARDS-TRACK]

draft-ietf-ips-ifcp-14 RFC6172 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4172
RFC4173 Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol P. Sarkar D. Missimer C. Sapuntzakis September 2005 ASCII HTML 12 scsi tcp transport control protocol boot server

Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol. The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-boot-12 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4173 10.17487/RFC4173
RFC4174 The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service C. Monia J. Tseng K. Gibbons September 2005 ASCII HTML 13 isns internet storage name service iscsi internet scsi ifcp internet fibre channel storage devices

This document describes the Dynamic Host Configuration Protocol (DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network. [STANDARDS-TRACK]

draft-ietf-dhc-isnsoption-13 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4174
RFC4175 RTP Payload Format for Uncompressed Video L. Gharai C. Perkins September 2005 ASCII HTML 18 packetization scheme real-time transport protocol real time transport protocol smpte society of motion picture television engineers video formats

This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time Transport Protocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITU BT.601, and standards from the Society of Motion Picture and Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed. [STANDARDS-TRACK]

draft-ietf-avt-uncomp-video-06 RFC4421 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4175 10.17487/RFC4175
RFC4176 Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management Y. El Mghazli Editor T. Nadeau M. Boucadair K. Chan A. Gonguet October 2005 ASCII HTML 21

This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community.

draft-ietf-l3vpn-mgt-fwk-08 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4176
RFC4177 Architectural Approaches to Multi-homing for IPv6 G. Huston September 2005 ASCII HTML 36 internet protocol

This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. This memo provides information for the Internet community.

draft-ietf-multi6-architecture-04 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4177
RFC4178 The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism L. Zhu P. Leach K. Jaganathan W. Ingersoll October 2005 ASCII HTML 22 generic service application security program interface

This document specifies a negotiation mechanism for the Generic Security Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers.

This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet. [STANDARDS-TRACK]

draft-ietf-kitten-2478bis-05 RFC2478 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4178
RFC4179 Using Universal Content Identifier (UCI) as Uniform Resource Names (URN) S. Kang October 2005 ASCII HTML 7 nca national computerization agency digital resources

This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA. This memo provides information for the Internet community.

draft-sangug-uci-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4179
RFC4180 Common Format and MIME Type for Comma-Separated Values (CSV) Files Y. Shafranovich October 2005 ASCII HTML 8 text/csv

This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". This memo provides information for the Internet community.

draft-shafranovich-mime-csv-05 RFC7111 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4180 10.17487/RFC4180
RFC4181 Guidelines for Authors and Reviewers of MIB Documents C. Heard Editor September 2005 ASCII HTML 42 standards-track specifications management information base review

This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ops-mib-review-guidelines-04 RFC4841 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4181 10.17487/RFC4181
RFC4182 Removing a Restriction on the use of MPLS Explicit NULL E. Rosen September 2005 ASCII HTML 7 multiprotocol label switching ipv4 explicit null

The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack.

This document updates RFC 3032. [STANDARDS-TRACK]

draft-ietf-mpls-explicit-null-02 RFC3032 RFC5462 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4182 10.17487/RFC4182
RFC4183 A Suggested Scheme for DNS Resolution of Networks and Gateways E. Warnicke September 2005 ASCII HTML 9 domain name space ip address internet protocol address netmask first-hop router subnet

This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. This memo provides information for the Internet community.

draft-warnicke-network-dns-resolution-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4183
RFC4184 RTP Payload Format for AC-3 Audio B. Link T. Hager J. Flaks October 2005 ASCII HTML 13 real time transport protocol audio compression

This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for United States HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

draft-ietf-avt-rtp-ac3-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4184
RFC4185 National and Local Characters for DNS Top Level Domain (TLD) Names J. Klensin October 2005 ASCII HTML 19 domain name system multilingual internationalized local translation

In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about "multilingual" or "internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country. This memo provides information for the Internet community.

draft-klensin-idn-tld-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4185
RFC4186 Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) H. Haverinen Editor J. Salowey Editor January 2006 ASCII HTML 92 3gpp

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.

draft-haverinen-pppext-eap-sim-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4186 10.17487/RFC4186
RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) J. Arkko H. Haverinen January 2006 ASCII HTML 79 3gpp universal mobile telecommunications system umts

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.

EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.

draft-arkko-pppext-eap-aka-15 RFC5448 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4187 10.17487/RFC4187
RFC4188 Definitions of Managed Objects for Bridges K. Norseth Editor E. Bell Editor September 2005 ASCII HTML 44 BRIDGE-MIB SNMP MIB standard standards management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.

This memo obsoletes RFC 1493. [STANDARDS-TRACK]

draft-ietf-bridge-bridgemib-smiv2-10 RFC1493 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4188 10.17487/RFC4188
RFC4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) K. Ono S. Tachimoto October 2005 ASCII HTML 12 user agent ua intermediaries

A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. This memo provides information for the Internet community.

draft-ietf-sipping-e2m-sec-reqs-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4189
RFC4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony K. Carlberg I. Brown C. Beard November 2005 ASCII HTML 28 disaster communications prioritized voip

This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. This memo provides information for the Internet community.

draft-ietf-ieprep-framework-10 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4190
RFC4191 Default Router Preferences and More-Specific Routes R. Draves D. Thaler November 2005 ASCII HTML 15 router advertisement

This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]

draft-ietf-ipv6-router-selection-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4191 10.17487/RFC4191
RFC4192 Procedures for Renumbering an IPv6 Network without a Flag Day F. Baker E. Lear R. Droms September 2005 ASCII HTML 22 prefix internet protocol network interface make-before-break enterprise connecting routers

This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. This memo provides information for the Internet community.

draft-ietf-v6ops-renumbering-procedure-05 RFC2072 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4192
RFC4193 Unique Local IPv6 Unicast Addresses R. Hinden B. Haberman October 2005 ASCII HTML 16 internet protocol local communication

This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]

draft-ietf-ipv6-unique-local-addr-09 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4193
RFC4194 The S Hexdump Format J. Strombergson L. Walleij P. Faltstrom October 2005 ASCII HTML 13 shf standard hex format secure hash standard shs sha-1 nist fips 180-2 binary data dump format hexadecimal intel hex format s-rec extensible markup language xml

This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format. [STANDARDS-TRACK]

draft-strombergson-shf-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4194 10.17487/RFC4194
RFC4195 A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum W. Kameyama October 2005 ASCII HTML 6 digital broadcasting tv radio storage systems metadata schemas

This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime Forum Standards, XML (Extensible Markup Language) Document Type Definitions, XML Schemas, Namespaces, and other documents. This memo provides information for the Internet community.

draft-kameyama-tv-anytime-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4195
RFC4196 The SEED Cipher Algorithm and Its Use with IPsec H.J. Lee J.H. Yoon S.L. Lee J.I. Lee October 2005 ASCII HTML 12 ipsec esp encryption algorithm

This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

draft-lee-ipsec-cipher-seed-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4196
RFC4197 Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks M. Riegel Editor October 2005 ASCII HTML 24 digital signatures plesiochronous digital hierarchy sonet synchronous optical network sdh synchronous digital hierarchy pwe3 pseudo wire emulation

This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community.

draft-ietf-pwe3-tdm-requirements-08 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4197 10.17487/RFC4197
RFC4198 A Uniform Resource Name (URN) Namespace for Federated Content D. Tessman November 2005 ASCII HTML 7 content resource content collections

This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections. A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. This memo provides information for the Internet community.

draft-dtessman-urn-namespace-federated-content-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4198
RFC4199 RFC4200 RFC4201 Link Bundling in MPLS Traffic Engineering (TE) K. Kompella Y. Rekhter L. Berger October 2005 ASCII HTML 12 multiprotocol label switching generalized multiprotocol label switching gmpls lsp label switched path interface identification tlvs

For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document. This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description. [STANDARDS-TRACK]

draft-ietf-mpls-bundle-06 RFC3471 RFC3472 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4201
RFC4202 Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII HTML 27 open shortest path first

This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-routing-09 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4202
RFC4203 OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII HTML 11 open shortest path first

This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

draft-ietf-ccamp-ospf-gmpls-extensions-12 RFC3630 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4203
RFC4204 Link Management Protocol (LMP) J. Lang Editor October 2005 ASCII HTML 86 gmpls sonet sdh discovery link verification fault managment control channel management link property correlation traffic engineering links trace monitoring

For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks. [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-10 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4204 10.17487/RFC4204
RFC4205 Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2005 ASCII HTML 11

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). This memo provides information for the Internet community.

draft-ietf-isis-gmpls-extensions-19 RFC5307 RFC3784 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC4205
RFC4206 Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K. Kompella Y. Rekhter October 2005 ASCII HTML 14 lsr label switching router te lsp fa forwarding adjacency

To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct).

This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]

draft-ietf-mpls-lsp-hierarchy-08 RFC6001 RFC6107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4206
RFC4207 Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages J. Lang D. Papadimitriou October 2005 ASCII HTML 15 gmpls discovery link verification fault management control channel management link property correlation traffic engineering links trace monitoring

This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages. [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-test-sonet-sdh-04 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4207 10.17487/RFC4207
RFC4208 Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model G. Swallow J. Drake H. Ishimatsu Y. Rekhter October 2005 ASCII HTML 13 lsp label switched paths routing protocol signaling protocol

Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-overlay-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4208
RFC4209 Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems A. Fredette Editor J. Lang Editor October 2005 ASCII HTML 16 te traffic engineering peer nodes ols optical link interface requirements

The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link Interface Requirements" described in a companion document. [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-wdm-03 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4209
RFC4210 Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) C. Adams S. Farrell T. Kause T. Mononen September 2005 ASCII HTML 95 PKICMP cryptographic authentication pkix pki X.509v3 certificate creation certificate management ca certification authority

This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]

draft-ietf-pkix-rfc2510bis-09 RFC2510 RFC6712 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4210 10.17487/RFC4210
RFC4211 Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) J. Schaad September 2005 ASCII HTML 40 X.509-CRMF certification authority ca registration authority ra pkix pki certificate production crmf security encryption authenticaion

This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK]

draft-ietf-pkix-rfc2511bis-08 RFC2511 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4211 10.17487/RFC4211
RFC4212 Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols M. Blinov C. Adams October 2005 ASCII HTML 19 X.509v3 public-key certificates crmf certificate request message format pkix certificate management protocol pkix-cmp certificate management messages over cms cmc

The Public-Key Infrastructure using X.509 (PKIX) Working Group of the Internet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well. This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and Certificate Management Messages over CMS (CMC). This memo provides information for the Internet community.

draft-adams-cmpaltcert-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4212
RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers E. Nordmark R. Gilligan October 2005 ASCII HTML 27 TRANS-IPV6 ipv4 dual sack configured tunneling

This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.

This document obsoletes RFC 2893. [STANDARDS-TRACK]

draft-ietf-v6ops-mech-v2-07 RFC2893 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4213 10.17487/RFC4213
RFC4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson M. Talwar D. Thaler October 2005 ASCII HTML 14 ISATAP] ipv4 link layer nbma non-broadcast multiple access

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects IPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ngtrans-isatap-22 RFC5214 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4214
RFC4215 Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks J. Wiljakka Editor October 2005 ASCII HTML 24 internet protocol gprs general packet radio service global system for mobile communications gsm universal mobile telecommunications system umts wideband code division multiple access wcdma

This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.

The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. This memo provides information for the Internet community.

draft-ietf-v6ops-3gpp-analysis-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4215
RFC4216 MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements R. Zhang Editor J.-P. Vasseur Editor November 2005 ASCII HTML 29 inter-as mpls-te

This document discusses requirements for the support of inter-AS MPLS Traffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. This memo provides information for the Internet community.

draft-ietf-tewg-interas-mpls-te-req-09 INFORMATIONAL INFORMATIONAL IETF subip tewg 10.17487/RFC4216
RFC4217 Securing FTP with TLS P. Ford-Hutchinson October 2005 ASCII HTML 29 security authentication file transfer protocol transport layer security

This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP Security Extensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for Secure SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.".

This specification is in accordance with RFC 959, "File Transfer Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions". [STANDARDS-TRACK]

draft-murray-auth-ftp-ssl-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4217 10.17487/RFC4217
RFC4218 Threats Relating to IPv6 Multihoming Solutions E. Nordmark T. Li October 2005 ASCII HTML 31 security threats internet protocol version 6

This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.

The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. This memo provides information for the Internet community.

draft-ietf-multi6-multihoming-threats-03 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4218
RFC4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About E. Lear October 2005 ASCII HTML 12 security threats internet protocol version 6

This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. This memo provides information for the Internet community.

draft-ietf-multi6-things-to-think-about-01 INFORMATIONAL INFORMATIONAL IETF ops multi6 10.17487/RFC4219
RFC4220 Traffic Engineering Link Management Information Base M. Dubuc T. Nadeau J. Lang November 2005 ASCII HTML 54 mib network management protocols te te-link-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document. [STANDARDS-TRACK]

draft-ietf-mpls-telink-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4220
RFC4221 Multiprotocol Label Switching (MPLS) Management Overview T. Nadeau C. Srinivasan A. Farrel November 2005 ASCII HTML 32 mib management information base management architecture network management

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.

This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. This memo provides information for the Internet community.

draft-ietf-mpls-mgmt-overview-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4221
RFC4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance G. Choudhury Editor October 2005 ASCII HTML 15 open shortest path first lsa link state advertisement

This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ospf-scalability-09 BCP0112 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf 10.17487/RFC4222
RFC4223 Reclassification of RFC 1863 to Historic P. Savola October 2005 ASCII HTML 3 BGP-IDRP border gateway protocol inter-domain routing

This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletes RFC 1863. This memo provides information for the Internet community.

draft-ietf-idr-rfc1863-historic-00 RFC1863 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4223
RFC4224 RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets G. Pelletier L-E. Jonsson K. Sandlund January 2006 ASCII HTML 21

RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. This memo provides information for the Internet community.

draft-ietf-rohc-over-reordering-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4224
RFC4225 Mobile IP Version 6 Route Optimization Security Design Background P. Nikander J. Arkko T. Aura G. Montenegro E. Nordmark December 2005 ASCII HTML 37 mipv6 mip

This document is an account of the rationale behind the Mobile IPv6 (MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.

The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. This memo provides information for the Internet community.

draft-ietf-mip6-ro-sec-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4225
RFC4226 HOTP: An HMAC-Based One-Time Password Algorithm D. M'Raihi M. Bellare F. Hoornaert D. Naccache O. Ranen December 2005 ASCII HTML 37 hashed message authentication code security analysis oath open authentication authentication OATH

This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.

This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This memo provides information for the Internet community.

draft-mraihi-oath-hmac-otp-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4226 10.17487/RFC4226
RFC4227 Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP) E. O'Tuathail M. Rose January 2006 ASCII HTML 21 xml extensible markup language remote procedure calling rpc asynchronous event notification unacknowledged messages binding

This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network.

The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote Procedure Calling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. [STANDARDS-TRACK]

draft-mrose-rfc3288bis-02 RFC3288 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4227 10.17487/RFC4227
RFC4228 Requirements for an IETF Draft Submission Toolset A. Rousskov December 2005 ASCII HTML 31 automation tool

This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community.

draft-ietf-tools-draft-submission-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4228
RFC4229 HTTP Header Field Registrations M. Nottingham J. Mogul December 2005 ASCII HTML 53 hyper text transfer protocol

This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. This memo provides information for the Internet community.

draft-nottingham-hdrreg-http-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4229 10.17487/RFC4229
RFC4230 RSVP Security Properties H. Tschofenig R. Graveman December 2005 ASCII HTML 48 resource reservation protocol

This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community.

draft-ietf-nsis-rsvp-sec-properties-06 INFORMATIONAL INFORMATIONAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=4230 10.17487/RFC4230
RFC4231 Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 M. Nystrom December 2005 ASCII HTML 9 message authentication codes message authentication schemes

This document provides test vectors for the HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and Uniform Resource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing. [STANDARDS-TRACK]

draft-nystrom-smime-hmac-sha-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4231 10.17487/RFC4231
RFC4232 RFC4233 Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer K. Morneault S. Rengasami M. Kalla G. Sidebottom January 2006 ASCII HTML 73 stream control transmission protocol sctp signaling gateway sg media gateway controller mgc signaling media gateway interface

This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.

This document obsoletes RFC 3057. [STANDARDS-TRACK]

draft-ietf-sigtran-rfc3057bis-02 RFC3057 RFC5133 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC4233
RFC4234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell October 2005 ASCII HTML 16 ABNF] backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer electronic mail

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity, with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

draft-crocker-abnf-rfc2234bis-00 RFC2234 RFC5234 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4234 10.17487/RFC4234
RFC4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne R. Mahy Editor November 2005 ASCII HTML 39 sip events dialog package

This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE-initiated dialog usages in which the subscribed-to user is involved. [STANDARDS-TRACK]

draft-ietf-sipping-dialog-package-06 RFC7463 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4235 10.17487/RFC4235
RFC4236 HTTP Adaptation with Open Pluggable Edge Services (OPES) A. Rousskov M. Stecher November 2005 ASCII HTML 27 callout protocol ocp opes tracing opes bypass

Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES. [STANDARDS-TRACK]

draft-ietf-opes-http-03 PROPOSED STANDARD PROPOSED STANDARD IETF app opes 10.17487/RFC4236
RFC4237 Voice Messaging Directory Service G. Vaudreuil October 2005 ASCII HTML 13 vpim voice profile for internet mail

This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.

The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]

draft-ietf-vpim-vpimdir-11 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4237 10.17487/RFC4237
RFC4238 Voice Message Routing Service G. Vaudreuil October 2005 ASCII HTML 10 vpim telephone number addressing voice profile and intenret mail vpim directory

Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities. [STANDARDS-TRACK]

draft-ietf-vpim-routing-10 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim http://www.rfc-editor.org/errata_search.php?rfc=4238 10.17487/RFC4238
RFC4239 Internet Voice Messaging (IVM) S. McRae G. Parsons November 2005 ASCII HTML 11 voicemail vpim voice profile for internet mail

This document describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.

The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. [STANDARDS-TRACK]

draft-ietf-vpim-ivm-06 PROPOSED STANDARD PROPOSED STANDARD IETF app vpim 10.17487/RFC4239
RFC4240 Basic Network Media Services with SIP E. Burger Editor J. Van Dyke A. Spitzer December 2005 ASCII HTML 24 session initiation protocol network media services media servers application servers

In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.

This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This memo provides information for the Internet community.

draft-burger-sipping-netann-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4240 10.17487/RFC4240
RFC4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service Y. Shirasaki S. Miyakawa T. Yamasaki A. Takenouchi December 2005 ASCII HTML 10 user network specification ntt communications adsl cpe customer preises equipment

This memo is a digest of the user network interface specification of NTT Communications' dual stack ADSL access service, which provide a IPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses of IPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. This memo provides information for the Internet community.

draft-shirasaki-dualstack-service-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4241 10.17487/RFC4241
RFC4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) S. Venaas T. Chown B. Volz November 2005 ASCII HTML 8 internet protocol

This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]

draft-ietf-dhc-lifetime-03 RFC8415 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4242
RFC4243 Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option M. Stapp R. Johnson T. Palaniappan December 2005 ASCII HTML 7

This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator. [STANDARDS-TRACK]

draft-ietf-dhc-vendor-suboption-00 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4243
RFC4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes Editor November 2005 ASCII HTML 44 history-info retarget enhanced services voicemail automatic call distribution

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. [STANDARDS-TRACK]

draft-ietf-sip-history-info-06 RFC7044 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4244 10.17487/RFC4244
RFC4245 High-Level Requirements for Tightly Coupled SIP Conferencing O. Levin R. Even November 2005 ASCII HTML 12 session initiation protocol

This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. This memo provides information for the Internet community.

draft-ietf-sipping-conferencing-requirements-01 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4245
RFC4246 International Standard Audiovisual Number (ISAN) URN Definition M. Dolan February 2006 ASCII HTML 6 numbering system international identification audiovisual uniform resource identifier

The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formal Uniform Resource Name (URN) Namespace Identifier (NID) for ISAN. This memo provides information for the Internet community.

draft-dolan-urn-isan-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4246
RFC4247 Requirements for Header Compression over MPLS J. Ash B. Goode J. Hand R. Zhang November 2005 ASCII HTML 11 multiprotocol label switching voip voice over ip

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. This memo provides information for the Internet community.

draft-ietf-avt-hc-mpls-reqs-03 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4247
RFC4248 The telnet URI Scheme P. Hoffman October 2005 ASCII HTML 4 uniform resource identifier url uniform resource locators

This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

draft-hoffman-telnet-uri-05 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4248
RFC4249 Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components B. Lilly January 2006 ASCII HTML 14 header field generator header field parser

Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer. This memo identifies information useful to implementers of header field generators and parsers. This memo provides information for the Internet community.

draft-lilly-field-specification-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4249
RFC4250 The Secure Shell (SSH) Protocol Assigned Numbers S. Lehtinen C. Lonvick Editor January 2006 ASCII HTML 20 remote login

This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK]

draft-ietf-secsh-assignednumbers-12 RFC8268 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4250
RFC4251 The Secure Shell (SSH) Protocol Architecture T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 30 remote login ssh algorithm

The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]

draft-ietf-secsh-architecture-22 RFC8308 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4251
RFC4252 The Secure Shell (SSH) Authentication Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 17 remote login public key password host-based client authentication

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]

draft-ietf-secsh-userauth-27 RFC8308 RFC8332 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4252 10.17487/RFC4252
RFC4253 The Secure Shell (SSH) Transport Layer Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 32 remote login encryption server authentication integrity protection diffie-hellman key exchange diffie hellman

The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.

This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]

draft-ietf-secsh-transport-24 RFC6668 RFC8268 RFC8308 RFC8332 RFC8709 RFC8758 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4253 10.17487/RFC4253
RFC4254 The Secure Shell (SSH) Connection Protocol T. Ylonen C. Lonvick Editor January 2006 ASCII HTML 24 remote login interactive login remote execution encrypted tunnel

Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel.

The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. [STANDARDS-TRACK]

draft-ietf-secsh-connect-25 RFC8308 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4254 10.17487/RFC4254
RFC4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints J. Schlyter W. Griffin January 2006 ASCII HTML 9 domain name system dnssec domain name system security

This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. [STANDARDS-TRACK]

draft-ietf-secsh-dns-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4255 10.17487/RFC4255
RFC4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) F. Cusack M. Forssen January 2006 ASCII HTML 12 remote login alphanumeric input

The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). [STANDARDS-TRACK]

draft-ietf-secsh-auth-kbdinteract-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4256 10.17487/RFC4256
RFC4257 Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks G. Bernstein E. Mannie V. Sharma E. Gray December 2005 ASCII HTML 35 mpls optical switching sdh sonet

Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. This memo provides information for the Internet community.

draft-ietf-ccamp-sdhsonet-control-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4257
RFC4258 Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) D. Brungard Editor November 2005 ASCII HTML 22 control domain hierarchy multi-level multi-layer inter-domain intra-domain e-nni i-nni uni

The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-routing-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4258
RFC4259 A Framework for Transmission of IP Datagrams over MPEG-2 Networks M.-J. Montpetit G. Fairhurst H. Clausen B. Collini-Nocker H. Linder November 2005 ASCII HTML 42 digital television dvb digital video broadcast atsc advanced television systems committee

This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.

The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. This memo provides information for the Internet community.

draft-ietf-ipdvb-arch-04 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4259
RFC4260 Mobile IPv6 Fast Handovers for 802.11 Networks P. McCann November 2005 ASCII HTML 15 link layer

This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. This memo provides information for the Internet community.

draft-ietf-mipshop-80211fh-04 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC4260
RFC4261 Common Open Policy Service (COPS) Over Transport Layer Security (TLS) J. Walker A. Kulkarni Editor December 2005 ASCII HTML 14 client-accept message

This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over the Internet.

This document also updates RFC 2748 by modifying the contents of the Client-Accept message. [STANDARDS-TRACK]

draft-ietf-rap-cops-tls-11 RFC2748 PROPOSED STANDARD PROPOSED STANDARD IETF ops rap 10.17487/RFC4261
RFC4262 X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities S. Santesson December 2005 ASCII HTML 5 cryptographic capabilities

This document defines a certificate extension for inclusion of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities in X.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIME Capabilities signed attribute in S/MIME messages according to RFC 3851. [STANDARDS-TRACK]

draft-ietf-smime-certcapa-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC4262
RFC4263 Media Subtype Registration for Media Type text/troff B. Lilly January 2006 ASCII HTML 16

A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. This memo provides information for the Internet community.

draft-lilly-text-troff-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4263
RFC4264 BGP Wedgies T. Griffin G. Huston November 2005 ASCII HTML 10 border gateway protocol

It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". This memo provides information for the Internet community.

draft-ietf-grow-bgp-wedgies-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4264
RFC4265 Definition of Textual Conventions for Virtual Private Network (VPN) Management B. Schliesser T. Nadeau November 2005 ASCII HTML 6 tc

This document describes Textual Conventions used for managing Virtual Private Networks (VPNs). [STANDARDS-TRACK]

draft-ietf-l3vpn-tc-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn 10.17487/RFC4265
RFC4266 The gopher URI Scheme P. Hoffman November 2005 ASCII HTML 6 uniform resource identifier url

This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track. [STANDARDS-TRACK]

draft-hoffman-gopher-uri-03 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4266
RFC4267 The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml M. Froumentin November 2005 ASCII HTML 9 voice browser voice extensible markup language voicexml speech synthesis markup language ssml speech recognition grammar specification srgs call control xml ccxml pronunciation lexicon specification pls

This document defines the media types for the languages of the W3C Speech Interface Framework, as designed by the Voice Browser Working Group in the following specifications: the Voice Extensible Markup Language (VoiceXML), the Speech Synthesis Markup Language (SSML), the Speech Recognition Grammar Specification (SRGS), the Call Control XML (CCXML), and the Pronunciation Lexicon Specification (PLS). This memo provides information for the Internet community.

draft-froumentin-voice-mediatypes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4267
RFC4268 Entity State MIB S. Chisholm D. Perkins November 2005 ASCII HTML 19 management information base snmp entity-state-tc-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the Entity MIB to provide information about the state of physical entities.

In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that these Textual Conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-entmib-state-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops entmib http://www.rfc-editor.org/errata_search.php?rfc=4268 10.17487/RFC4268
RFC4269 The SEED Encryption Algorithm H.J. Lee S.J. Lee J.H. Yoon D.H. Cheon J.I. Lee December 2005 ASCII HTML 16 encryption algorithm seed cbc seed oid

This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea. Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).

This document obsoletes RFC 4009. This memo provides information for the Internet community.

draft-lee-rfc4009bis-02 RFC4009 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4269
RFC4270 Attacks on Cryptographic Hashes in Internet Protocols P. Hoffman B. Schneier November 2005 ASCII HTML 12 collision attacks hash algorithms ip digital certificates

Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community.

draft-hoffman-hash-attacks-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4270 10.17487/RFC4270
RFC4271 A Border Gateway Protocol 4 (BGP-4) Y. Rekhter Editor T. Li Editor S. Hares Editor January 2006 ASCII HTML 104 BGP-4 routing

This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.

This document obsoletes RFC 1771. [STANDARDS-TRACK]

draft-ietf-idr-bgp4-26 RFC1771 RFC6286 RFC6608 RFC6793 RFC7606 RFC7607 RFC7705 RFC8212 RFC8654 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4271 10.17487/RFC4271
RFC4272 BGP Security Vulnerabilities Analysis S. Murphy January 2006 ASCII HTML 22 border gateway protocol attacks risks insider threat

Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.

This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.

draft-ietf-idr-bgp-vuln-01 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4272
RFC4273 Definitions of Managed Objects for BGP-4 J. Haas Editor S. Hares Editor January 2006 ASCII HTML 32 BGP-4-MIB management information base mib border gateway protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower.

The origin of this memo is from RFC 1269 "Definitions of Managed Objects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents.

This memo is intended to document deployed implementations of this MIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of the BGP protocol and its extensions.

This document obsoletes RFC 1269 and RFC 1657. [STANDARDS-TRACK]

draft-ietf-idr-bgp4-mib-15 RFC1269 RFC1657 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4273 10.17487/RFC4273
RFC4274 BGP-4 Protocol Analysis D. Meyer K. Patel January 2006 ASCII HTML 16 border gateway protocol

The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community.

draft-ietf-idr-bgp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4274 10.17487/RFC4274
RFC4275 BGP-4 MIB Implementation Survey S. Hares D. Hares January 2006 ASCII HTML 37 border gateway protocol management information base

This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. This memo provides information for the Internet community.

draft-ietf-idr-bgp-mibagent-survey-02 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4275 10.17487/RFC4275
RFC4276 BGP-4 Implementation Report S. Hares A. Retana January 2006 ASCII HTML 97 border gateway protocol

This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).

The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. This memo provides information for the Internet community.

draft-ietf-idr-bgp-implementation-02 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC4276
RFC4277 Experience with the BGP-4 Protocol D. McPherson K. Patel January 2006 ASCII HTML 19 border gateway protocol

The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).

This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted for Standard. This memo provides information for the Internet community.

draft-ietf-idr-bgp4-experience-protocol-05 INFORMATIONAL INFORMATIONAL IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4277 10.17487/RFC4277
RFC4278 Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification S. Bellovin A. Zinin January 2006 ASCII HTML 7 border gateway protocol

The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC 2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. This memo provides information for the Internet community.

draft-iesg-tcpmd5app-01 INFORMATIONAL INFORMATIONAL IETF IESG 10.17487/RFC4278
RFC4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) P. Eronen Editor H. Tschofenig Editor December 2005 ASCII HTML 15 psk psks symmetric keys diffie-hellman

This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK]

draft-ietf-tls-psk-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4279
RFC4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers K. Chowdhury P. Yegani L. Madour November 2005 ASCII HTML 11 bcmcs 3g third generation cellular telephone mobile node mn

This document defines new options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host Configuration Protocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes. [STANDARDS-TRACK]

draft-ietf-dhc-bcmc-options-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4280 10.17487/RFC4280
RFC4281 The Codecs Parameter for "Bucket" Media Types R. Gellens D. Singer P. Frojdh November 2005 ASCII HTML 29 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.

This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS-TRACK]

draft-gellens-mime-bucket-04 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4281 10.17487/RFC4281
RFC4282 The Network Access Identifier B. Aboba M. Beadles J. Arkko P. Eronen December 2005 ASCII HTML 16 NAI nai roaming tunneling

In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, \%customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and \%ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. [STANDARDS-TRACK]

draft-ietf-radext-rfc2486bis-06 RFC2486 RFC7542 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4282 10.17487/RFC4282
RFC4283 Mobile Node Identifier Option for Mobile IPv6 (MIPv6) A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury November 2005 ASCII HTML 8 mobility header mobile nodes correspondent nodes home agents

Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header. [STANDARDS-TRACK]

draft-ietf-mip6-mn-ident-option-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4283 10.17487/RFC4283
RFC4284 Identity Selection Hints for the Extensible Authentication Protocol (EAP) F. Adrangi V. Lortz F. Bari P. Eronen January 2006 ASCII HTML 14 nai network access identifier

The Extensible Authentication Protocol (EAP) is defined in RFC 3748. This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier (NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.

The mechanism defined in this document is limited in its scalability. It is intended for access networks that have a small to moderate number of direct roaming partners. This memo provides information for the Internet community.

draft-adrangi-eap-network-discovery-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4284
RFC4285 Authentication Protocol for Mobile IPv6 A. Patel K. Leung M. Khalil H. Akhtar K. Chowdhury January 2006 ASCII HTML 19 ip security ipsec mip6 mobile node home agent

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This memo provides information for the Internet community.

draft-ietf-mip6-auth-protocol-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4285 10.17487/RFC4285
RFC4286 Multicast Router Discovery B. Haberman J. Martin December 2005 ASCII HTML 18 igmp internet group management protocol mld multicast listener discovery mrd

The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.

This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]

draft-ietf-magma-mrdisc-07 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4286 10.17487/RFC4286
RFC4287 The Atom Syndication Format M. Nottingham Editor R. Sayre Editor December 2005 ASCII HTML 43 xml-basd web content metadata

This document specifies Atom, an XML-based Web content and metadata syndication format. [STANDARDS-TRACK]

draft-ietf-atompub-format-11 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub 10.17487/RFC4287
RFC4288 Media Type Specifications and Registration Procedures N. Freed J. Klensin December 2005 ASCII HTML 24 mime multipurpose internet mail extensions media types

This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-freed-media-type-reg-05 RFC2048 RFC6838 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4288 10.17487/RFC4288
RFC4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed J. Klensin December 2005 ASCII HTML 11 media types external body access content-transfer-encodings

This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-freed-mime-p4-07 RFC2048 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4289
RFC4290 Suggested Practices for Registration of Internationalized Domain Names (IDN) J. Klensin December 2005 ASCII HTML 28 chinese domain names japanese domain names korean domain names

This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community.

draft-klensin-reg-guidelines-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4290 10.17487/RFC4290
RFC4291 IP Version 6 Addressing Architecture R. Hinden S. Deering February 2006 ASCII HTML 25 internet protocol version 6 unicast anycast multicast node

This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.

This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]

draft-ietf-ipv6-addr-arch-v4-04 RFC3513 RFC5952 RFC6052 RFC7136 RFC7346 RFC7371 RFC8064 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4291 10.17487/RFC4291
RFC4292 IP Forwarding Table MIB B. Haberman April 2006 ASCII HTML 34 TABLE-MIB Management Information Base Internet Protocol

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. This document obsoletes RFC 2096. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2096-update-07 RFC2096 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4292
RFC4293 Management Information Base for the Internet Protocol (IP) S. Routhier Editor April 2006 ASCII HTML 122 MIB-IP IP Simple Network Management Protocol MIB ipv6 ICMPv6-MIB| mib internet protocol ip mib ipv4 mib ipv6 mib icmp mib icmpv6 mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2011-update-10 RFC2011 RFC2465 RFC2466 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4293 10.17487/RFC4293
RFC4294 IPv6 Node Requirements J. Loughney Editor April 2006 ASCII HTML 20 internet protocol version 6

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This memo provides information for the Internet community.

draft-ietf-ipv6-node-requirements-11 RFC6434 RFC5095 INFORMATIONAL INFORMATIONAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4294 10.17487/RFC4294
RFC4295 Mobile IPv6 Management Information Base G. Keeni K. Koide K. Nagami S. Gundavelli April 2006 ASCII HTML 109 mib mipv6

This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS-TRACK]

draft-ietf-mip6-mipv6-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4295 10.17487/RFC4295
RFC4296 The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols S. Bailey T. Talpey December 2005 ASCII HTML 22 rddp warp

This document defines an abstract architecture for Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. This memo provides information for the Internet community.

draft-ietf-rddp-arch-07 INFORMATIONAL INFORMATIONAL IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=4296 10.17487/RFC4296
RFC4297 Remote Direct Memory Access (RDMA) over IP Problem Statement A. Romanow J. Mogul T. Talpey S. Bailey December 2005 ASCII HTML 20 overhead copy avoidance

Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.

This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.

draft-ietf-rddp-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC4297
RFC4298 RTP Payload Format for BroadVoice Speech Codecs J.-H. Chen W. Lee J. Thyssen December 2005 ASCII HTML 14 real time transport narroband wideband bv16 broadvoice16 sdp session description protocol

This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-rtp-bv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4298
RFC4299 RFC4300 RFC4301 Security Architecture for the Internet Protocol S. Kent K. Seo December 2005 ASCII HTML 101 IPSEC ipsec authentication encapsulation IP IPv4 IPv6 IP-layer ip authentication header ip security IPsec confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]

draft-ietf-ipsec-rfc2401bis-06 RFC2401 RFC3168 RFC6040 RFC7619 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4301 10.17487/RFC4301
RFC4302 IP Authentication Header S. Kent December 2005 ASCII HTML 34 IP-AUTH ipsec Internet Protocol AH security IPv4 IPv6 ip security confidentiality authentication integrity anti-replay ah esp encapsulating security payload ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]

draft-ietf-ipsec-rfc2402bis-10 RFC2402 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4302 10.17487/RFC4302
RFC4303 IP Encapsulating Security Payload (ESP) S. Kent December 2005 ASCII HTML 44 ESP ipsec internet protocol encapsulating security ipv4 ipv6 ip security confidentiality authentication integrity anti-replay ah ip authentication header ike internet key exchange ikev2 esn extended sequence number

This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]

draft-ietf-ipsec-esp-v3-10 RFC2406 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4303 10.17487/RFC4303
RFC4304 Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) S. Kent December 2005 ASCII HTML 5 ipsecurity anti-replay ah ip authentication header esp encapsulating security payload ike internet key exchange ikev2

The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64-bit) sequence numbers (ESNs) for a particular AH or ESP security association. [STANDARDS-TRACK]

draft-ietf-ipsec-esn-addendum-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec 10.17487/RFC4304
RFC4305 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. Eastlake 3rd December 2005 ASCII HTML 9 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

draft-ietf-ipsec-esp-ah-algorithms-02 RFC2402 RFC2406 RFC4835 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4305 10.17487/RFC4305
RFC4306 Internet Key Exchange (IKEv2) Protocol C. Kaufman Editor December 2005 ASCII HTML 99 ISAKMPSEC ipsec internet protocol security association key management ipsec cryptography authentication IKE oakley isakmp

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).

This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition.

Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK]

draft-ietf-ipsec-ikev2-17 RFC2407 RFC2408 RFC2409 RFC5996 RFC5282 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4306 10.17487/RFC4306
RFC4307 Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) J. Schiller December 2005 ASCII HTML 6 ipsec ike internet key exchange

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

draft-ietf-ipsec-ikev2-algorithms-05 RFC8247 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4307 10.17487/RFC4307
RFC4308 Cryptographic Suites for IPsec P. Hoffman December 2005 ASCII HTML 7 ike internet key exchange ikev2 security algorithms ikev1

The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK]

draft-ietf-ipsec-ui-suites-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4308 10.17487/RFC4308
RFC4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) R. Housley December 2005 ASCII HTML 13 cbc-mac mode initialization vector iv confidentiality data origin authentication connectionless integrity

This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

draft-ietf-ipsec-ciph-aes-ccm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsec http://www.rfc-editor.org/errata_search.php?rfc=4309 10.17487/RFC4309
RFC4310 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) S. Hollenbeck December 2005 ASCII HTML 22 dnssec domain name system security extensions

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. [STANDARDS-TRACK]

draft-hollenbeck-epp-secdns-08 RFC5910 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4310
RFC4311 IPv6 Host-to-Router Load Sharing R. Hinden D. Thaler November 2005 ASCII HTML 5 internet protocol version 6 conceptual sending algorithm

The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion. [STANDARDS-TRACK]

draft-ietf-ipv6-host-load-sharing-04 RFC2461 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4311
RFC4312 The Camellia Cipher Algorithm and Its Use With IPsec A. Kato S. Moriai M. Kanda December 2005 ASCII HTML 8 cipher block chaining mode initialization vector iv esp encapsulating security payload ip security

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit Initialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). [STANDARDS-TRACK]

draft-kato-ipsec-ciph-camellia-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4312 10.17487/RFC4312
RFC4313 Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources D. Oran December 2005 ASCII HTML 20 speech processing audio streams si speaker identification sv speaker verification tts text to speech

This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. This memo provides information for the Internet community.

draft-ietf-speechsc-reqts-07 INFORMATIONAL INFORMATIONAL IETF rai speechsc 10.17487/RFC4313
RFC4314 IMAP4 Access Control List (ACL) Extension A. Melnikov December 2005 ASCII HTML 27 IMAP4-ACL Control List interet message access protocol

The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands. [STANDARDS-TRACK]

draft-ietf-imapext-2086upd-08 RFC2086 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4314 10.17487/RFC4314
RFC4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension M. Crispin December 2005 ASCII HTML 8 IMAP4UIDPL internet message access protocol disconnected operation

The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK]

draft-crispin-imap-rfc2359bis-04 RFC2359 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4315
RFC4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties J. Reschke December 2005 ASCII HTML 11 datatying propfind

This specification extends the Web Distributed Authoring and Versioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. This memo defines an Experimental Protocol for the Internet community.

draft-reschke-webdav-property-datatypes-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4316
RFC4317 Session Description Protocol (SDP) Offer/Answer Examples A. Johnston R. Sparks December 2005 ASCII HTML 24

This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. This memo provides information for the Internet community.

draft-ietf-mmusic-offer-answer-examples-06 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4317
RFC4318 Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol D. Levi D. Harrington December 2005 ASCII HTML 14 management information base simple network management protocol transparent bridging rstp-mib

This memo defines an SMIv2 MIB module for managing the Rapid Spanning Tree capability defined by the IEEE P802.1t and P802.1w amendments to IEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments. [STANDARDS-TRACK]

draft-ietf-bridge-rstpmib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge 10.17487/RFC4318
RFC4319 Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines C. Sikes B. Ray R. Abbi December 2005 ASCII HTML 75 mib management information base hdsl2-shdsl-line-mib interfaces

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-Rate Digital Subscriber Line (DSL) - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces. This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276. [STANDARDS-TRACK]

draft-ietf-adslmib-gshdslbis-11 RFC3276 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=4319 10.17487/RFC4319
RFC4320 Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII HTML 7

This document describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261. [STANDARDS-TRACK]

draft-sparks-sip-nit-actions-03 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4320
RFC4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction R. Sparks January 2006 ASCII HTML 10

This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. This memo provides information for the Internet community.

draft-sparks-sip-nit-problems-02 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4321
RFC4322 Opportunistic Encryption using the Internet Key Exchange (IKE) M. Richardson D.H. Redelmeier December 2005 ASCII HTML 44 oe linux frees/wan ipsec dns domain name space dns security

This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet Key Exchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.

As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. This memo provides information for the Internet community.

draft-richardson-ipsec-opportunistic-17 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4322 10.17487/RFC4322
RFC4323 Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB) M. Patrick W. Murwin January 2006 ASCII HTML 89 snmp simple network management protocol cm cable modem cmts cable modem termination system docs-ietf-qos-mib

This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) specifications versions 1.1 and 2.0. [STANDARDS-TRACK]

draft-ietf-ipcdn-qos-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4323
RFC4324 Calendar Access Protocol (CAP) D. Royer G. Babics S. Mansour December 2005 ASCII HTML 131 calendar user cu calendar user agent cua ical calender store cs

The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community.

draft-royer-calsch-cap-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4324
RFC4325 Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension S. Santesson R. Housley December 2005 ASCII HTML 7 issuer certificate

This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates. [STANDARDS-TRACK]

draft-ietf-pkix-crlaia-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4325
RFC4326 Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) G. Fairhurst B. Collini-Nocker December 2005 ASCII HTML 42

The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.

This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]

draft-ietf-ipdvb-ule-06 RFC7280 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=4326 10.17487/RFC4326
RFC4327 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis January 2006 ASCII HTML 82 lmp-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

draft-ietf-ccamp-lmp-mib-10 RFC4631 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4327 10.17487/RFC4327
RFC4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control D. Papadimitriou Editor January 2006 ASCII HTML 23 otn optical transport networks pre-otn

This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-g709-09 RFC3471 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4328
RFC4329 Scripting Media Types B. Hoehrmann April 2006 ASCII HTML 15 JavaScript EMACScript mime script subtype

This document describes the registration of media types for the ECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This memo provides information for the Internet community.

draft-hoehrmann-script-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4329
RFC4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI D. Mills January 2006 ASCII HTML 27 NTP time computer clock synchronization

This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.

This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP. This memo provides information for the Internet community.

draft-mills-sntp-v4-01 RFC2030 RFC1769 RFC5905 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4330 10.17487/RFC4330
RFC4331 Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections B. Korver L. Dusseault February 2006 ASCII HTML 10 webdav

Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories. [STANDARDS-TRACK]

draft-ietf-webdav-quota-07 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav 10.17487/RFC4331
RFC4332 Cisco's Mobile IPv4 Host Configuration Extensions K. Leung A. Patel G. Tsirtsis E. Klovning December 2005 ASCII HTML 11 dynamic host configuration protocol dhcp point-to-point ip control protocol ppp ipcp

An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host Configuration Protocol (DHCP) or Point-to-Point Protocol/IP Control Protocol (PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. This memo provides information for the Internet community.

draft-leung-cisco-mip4-host-config-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4332
RFC4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process G. Huston Editor B. Wijnen Editor December 2005 ASCII HTML 9 iad iasa ietf administrative support activity ietf administrative director

This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-iab-iesg-iaoc-selection-03 RFC8711 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IAB 10.17487/RFC4333
RFC4334 Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) R. Housley T. Moore February 2006 ASCII HTML 11 eap extensible authentication protocol wireless lan wlan system service identifier ssid

This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770. [STANDARDS-TRACK]

draft-ietf-pkix-rfc3770bis-03 RFC3770 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4334 10.17487/RFC4334
RFC4335 The Secure Shell (SSH) Session Channel Break Extension J. Galbraith P. Remaker January 2006 ASCII HTML 6

The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. [STANDARDS-TRACK]

draft-ietf-secsh-break-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4335 10.17487/RFC4335
RFC4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP) S. Floyd M. Handley E. Kohler March 2006 ASCII HTML 22

This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. This memo provides information for the Internet community.

draft-ietf-dccp-problem-03 INFORMATIONAL INFORMATIONAL IETF tsv dccp 10.17487/RFC4336
RFC4337 MIME Type Registration for MPEG-4 Y Lim D. Singer March 2006 ASCII HTML 11

This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents. [STANDARDS-TRACK]

draft-lim-mpeg4-mime-03 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4337 10.17487/RFC4337
RFC4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel C. DeSanti C. Carlson R. Nixon January 2006 ASCII HTML 33 link local address link-local address

This document specifies the way of encapsulating IPv6, IPv4, and Address Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks.

This document obsoletes RFC 2625 and RFC 3831. [STANDARDS-TRACK]

draft-ietf-imss-ip-over-fibre-channel-03 RFC3831 RFC2625 RFC5494 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4338
RFC4339 IPv6 Host Configuration of DNS Server Information Approaches J. Jeong Editor February 2006 ASCII HTML 26 domain name server internet protocol address configuration dhcpv6 dynamic host configuration protocol

This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution. This memo provides information for the Internet community.

draft-ietf-dnsop-ipv6-dns-configuration-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4339 10.17487/RFC4339
RFC4340 Datagram Congestion Control Protocol (DCCP) E. Kohler M. Handley S. Floyd March 2006 ASCII HTML 129 transport protocol

The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK]

draft-ietf-dccp-spec-11 RFC5595 RFC5596 RFC6335 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4340 10.17487/RFC4340
RFC4341 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control S. Floyd E. Kohler March 2006 ASCII HTML 20 transport protocol amid additive increase multiplicative decrease

This document contains the profile for Congestion Control Identifier 2 (CCID 2), TCP-like Congestion Control, in the Datagram Congestion Control Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's Additive Increase Multiplicative Decrease (AIMD) congestion control. [STANDARDS-TRACK]

draft-ietf-dccp-ccid2-10 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC4341
RFC4342 Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) S. Floyd E. Kohler J. Padhye March 2006 ASCII HTML 33 transport protocol ecn explicit congestion notification ccid3

This document contains the profile for Congestion Control Identifier 3, TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. [STANDARDS-TRACK]

draft-ietf-dccp-ccid3-11 RFC5348 RFC6323 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4342 10.17487/RFC4342
RFC4343 Domain Name System (DNS) Case Insensitivity Clarification D. Eastlake 3rd January 2006 ASCII HTML 10

Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181. [STANDARDS-TRACK]

draft-ietf-dnsext-insensitive-06 RFC1034 RFC1035 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4343 10.17487/RFC4343
RFC4344 The Secure Shell (SSH) Transport Layer Encryption Modes M. Bellare T. Kohno C. Namprempre January 2006 ASCII HTML 12 rekey

Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks.

This document describes new symmetric encryption methods for the Secure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. [STANDARDS-TRACK]

draft-ietf-secsh-newmodes-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4344
RFC4345 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol B. Harris January 2006 ASCII HTML 5 arcfour cipher key scheduling algorithm

This document specifies methods of using the Arcfour cipher in the Secure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm. [STANDARDS-TRACK]

draft-harris-ssh-arcfour-fixes-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4345 10.17487/RFC4345
RFC4346 The Transport Layer Security (TLS) Protocol Version 1.1 T. Dierks E. Rescorla April 2006 ASCII HTML 87

This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

draft-ietf-tls-rfc2246-bis-13 RFC2246 RFC5246 RFC4366 RFC4680 RFC4681 RFC5746 RFC6176 RFC7465 RFC7507 RFC7919 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4346 10.17487/RFC4346
RFC4347 Datagram Transport Layer Security E. Rescorla N. Modadugu April 2006 ASCII HTML 25 dtls

This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. [STANDARDS-TRACK]

draft-rescorla-dtls-05 RFC6347 RFC5746 RFC7507 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4347 10.17487/RFC4347
RFC4348 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec S. Ahmadi January 2006 ASCII HTML 32 speech codec variable-rate multicode wideband speech codec

This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format.

VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB (i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved. [STANDARDS-TRACK]

draft-ietf-avt-rtp-vmr-wb-11 RFC4424 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4348
RFC4349 High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) C. Pignataro M. Townsley February 2006 ASCII HTML 11 pseudowire

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel High-Level Data Link Control (HDLC) frames over L2TPv3. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-hdlc-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4349
RFC4350 A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government F. Hendrikx C. Wallis February 2006 ASCII HTML 11 nid namespace identification

This document describes a Uniform Resource Name (URN) Namespace Identification (NID)convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New Zealand Government. This memo provides information for the Internet community.

draft-hendrikx-wallis-urn-nzl-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4350
RFC4351 Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream G. Hellstrom P. Jones January 2006 ASCII HTML 20 itu-t recommendation t.140

This memo describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140.

One payload format is described for transmitting audio and text data within a single RTP session.

This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This memo defines a Historic Document for the Internet community.

draft-ietf-avt-audio-t140c-00 HISTORIC HISTORIC IETF rai avt 10.17487/RFC4351
RFC4352 RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec J. Sjoberg M. Westerlund A. Lakaniemi S. Wenger January 2006 ASCII HTML 38 real-time transport protocol audio signals

This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification. [STANDARDS-TRACK]

draft-ietf-avt-rtp-amrwbplus-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4352 10.17487/RFC4352
RFC4353 A Framework for Conferencing with the Session Initiation Protocol (SIP) J. Rosenberg February 2006 ASCII HTML 29

The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. This memo provides information for the Internet community.

draft-ietf-sipping-conferencing-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4353
RFC4354 A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service M. Garcia-Martin January 2006 ASCII HTML 21 oma open mobile alliance

The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. This memo provides information for the Internet community.

draft-garcia-sipping-poc-isb-am-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4354
RFC4355 IANA Registration for Enumservices email, fax, mms, ems, and sms R. Brandner L. Conroy R. Stastny January 2006 ASCII HTML 16 domain name system

This document registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-msg-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4355
RFC4356 Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail R. Gellens January 2006 ASCII HTML 31 cellular telephone x-mms

The cellular telephone industry has defined a service known as the Multimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail.

One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements.

This document specifies how to exchange messages between these two services, including mapping information elements as used in MMS X-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers. [STANDARDS-TRACK]

draft-ietf-lemonade-mms-mapping-06 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4356
RFC4357 Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms V. Popov I. Kurepkin S. Leontiev January 2006 ASCII HTML 51 cpalgs public-key one-way hash block cipher encyption decryption mac hmac prf wrap unwrap ukm kek key parameter derivation digest cbc counter mode digital signature

This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use in Internet applications. This memo provides information for the Internet community.

draft-popov-cryptopro-cpalgs-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4357 10.17487/RFC4357
RFC4358 A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) D. Smith January 2006 ASCII HTML 6 nid namespace identifier omna open mobile naming authority

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the Open Mobile Alliance (OMA). OMA defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA). This memo provides information for the Internet community.

draft-smith-oma-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4358
RFC4359 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) B. Weis January 2006 ASCII HTML 12 ip encapsulating security payload digital signature

This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP Encapsulating Security Payload (ESP) as described in RFC 4303 and the revised IP Authentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet. [STANDARDS-TRACK]

draft-ietf-msec-ipsec-signatures-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4359
RFC4360 BGP Extended Communities Attribute S. Sangli D. Tappan Y. Rekhter February 2006 ASCII HTML 12

This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]

draft-ietf-idr-bgp-ext-communities-09 RFC7153 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4360 10.17487/RFC4360
RFC4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) T. Lemon B. Sommerfeld February 2006 ASCII HTML 12 dhcpv6

This document specifies the format that is to be used for encoding Dynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers. [STANDARDS-TRACK]

draft-ietf-dhc-3315id-for-v4-05 RFC2131 RFC2132 RFC3315 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4361 10.17487/RFC4361
RFC4362 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP L-E. Jonsson G. Pelletier K. Sandlund January 2006 ASCII HTML 23 internet protocol user datagram protocol real-time transport protocol

This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes. [STANDARDS-TRACK]

draft-ietf-rohc-rfc3242bis-01 RFC3242 RFC4815 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4362
RFC4363 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions D. Levi D. Harrington January 2006 ASCII HTML 99 mib management information base mac bridges traffic classes enhanced multicast filtering p-bridge-mib q-bridge-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v (TM).

Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments.

This memo supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS-TRACK]

draft-ietf-bridge-ext-v2-07 RFC2674 PROPOSED STANDARD PROPOSED STANDARD IETF ops bridge http://www.rfc-editor.org/errata_search.php?rfc=4363 10.17487/RFC4363
RFC4364 BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen Y. Rekhter February 2006 ASCII HTML 47 service provider ip backbone ce router pe router border gateway protocol multiprotocol label switching architecture virtual private networks

This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]

draft-ietf-l3vpn-rfc2547bis-03 RFC2547 RFC4577 RFC4684 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4364 10.17487/RFC4364
RFC4365 Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen February 2006 ASCII HTML 32

This document provides an Applicability Statement for the Virtual Private Network (VPN) solution described in RFC 4364 and other documents listed in the References section. This memo provides information for the Internet community.

draft-ietf-l3vpn-as2547-07 INFORMATIONAL INFORMATIONAL IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4365 10.17487/RFC4365
RFC4366 Transport Layer Security (TLS) Extensions S. Blake-Wilson M. Nystrom D. Hopwood J. Mikkelsen T. Wright April 2006 ASCII HTML 30 transport protocol layer authentication privacy

This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.

The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]

draft-ietf-tls-rfc3546bis-02 RFC3546 RFC5246 RFC6066 RFC4346 RFC5746 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4366 10.17487/RFC4366
RFC4367 What's in a Name: False Assumptions about DNS Names J. Rosenberg Editor IAB February 2006 ASCII HTML 17 domain name system

The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform Resource Identifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. This memo provides information for the Internet community.

draft-iab-dns-assumptions-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4367 10.17487/RFC4367
RFC4368 Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition T. Nadeau S. Hegde January 2006 ASCII HTML 22 management information base mpls-lc-atm-std-mib mpls-lc-fr-std-mib

This memo defines two MIB modules and corresponding MIB Object Definitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB and MPLS-TE-STD-MIB. [STANDARDS-TRACK]

draft-ietf-mpls-lc-if-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4368 10.17487/RFC4368
RFC4369 Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP) K. Gibbons C. Monia J. Tseng F. Travostino January 2006 ASCII HTML 29 mib management information base snmp simple network management protocol ifcp gateway ifcp-mgmt-mib

The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP. [STANDARDS-TRACK]

draft-ietf-ips-ifcp-mib-07 RFC6173 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4369
RFC4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control R. Weltman February 2006 ASCII HTML 5 proxy authorization control

This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. [STANDARDS-TRACK]

draft-weltman-ldapv3-proxy-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4370
RFC4371 BCP 101 Update for IPR Trust B. Carpenter Editor L. Lynch Editor January 2006 ASCII HTML 4

This document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-carpenter-bcp101-update-03 RFC8714 RFC4071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4371
RFC4372 Chargeable User Identity F. Adrangi A. Lior J. Korhonen J. Loughney January 2006 ASCII HTML 10 radius remote authentication dial-in user service roaming transaction home network

This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK]

draft-ietf-radext-chargeable-user-id-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4372
RFC4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) R. Harrison J. Sermersheim Y. Dong January 2006 ASCII HTML 16

The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.

The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. This memo provides information for the Internet community.

draft-rharrison-lburp-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4373
RFC4374 The application/xv+xml Media Type G. McCobb January 2006 ASCII HTML 6 mime sub-type media descriptor xhtml+voice

This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. This memo provides information for the Internet community.

draft-mccobb-xv-media-type-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4374
RFC4375 Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain K. Carlberg January 2006 ASCII HTML 8 resource transit domain stub domain

This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. This memo provides information for the Internet community.

draft-ietf-ieprep-domain-req-05 INFORMATIONAL INFORMATIONAL IETF rai ieprep 10.17487/RFC4375
RFC4376 Requirements for Floor Control Protocols P. Koskelainen J. Ott H. Schulzrinne X. Wu February 2006 ASCII HTML 14 shared resources multiparty conferences

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. This memo provides information for the Internet community.

draft-ietf-xcon-floor-control-req-03 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4376
RFC4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks T. Nadeau M. Morrow G. Swallow D. Allan S. Matsushima February 2006 ASCII HTML 15

This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This memo provides information for the Internet community.

draft-ietf-mpls-oam-requirements-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4377 10.17487/RFC4377
RFC4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) D. Allan Editor T. Nadeau Editor February 2006 ASCII HTML 11 data plane fcaps

This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS). The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. This memo provides information for the Internet community.

draft-ietf-mpls-oam-frmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4378
RFC4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures K. Kompella G. Swallow February 2006 ASCII HTML 50 data plane

This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK]

draft-ietf-mpls-lsp-ping-13 RFC8029 RFC1122 RFC5462 RFC6424 RFC6425 RFC6426 RFC6829 RFC7506 RFC7537 RFC7743 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4379 10.17487/RFC4379
RFC4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) C. Huitema February 2006 ASCII HTML 53

We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-TRACK]

draft-huitema-v6ops-teredo-05 RFC5991 RFC6081 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4380 10.17487/RFC4380
RFC4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) M. Behringer February 2006 ASCII HTML 22 service provider atm asynchronous transfer mode frame relay

This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.

The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community.

draft-behringer-mpls-security-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4381
RFC4382 MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base T. Nadeau Editor H. van der Linde Editor February 2006 ASCII HTML 44 mib management information base multiprotocol label switching label switching router lsr mpls-l3vpn-std-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual Private Networks on a Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) supporting this feature. [STANDARDS-TRACK]

draft-ietf-l3vpn-mpls-vpn-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4382 10.17487/RFC4382
RFC4383 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) M. Baugher E. Carrara February 2006 ASCII HTML 19 multicast data stream broadcast data stream

This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]

draft-ietf-msec-srtp-tesla-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4383
RFC4384 BGP Communities for Data Collection D. Meyer February 2006 ASCII HTML 12 border gateway protocol

BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes. Such tagging is typically used to control the scope of redistribution of routes within a provider's network and to its peers and customers. With the advent of large-scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This memo defines standard (outbound) communities and their encodings for export to BGP route collectors. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-collection-communities-06 BCP0114 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4384 10.17487/RFC4384
RFC4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN S. Bryant G. Swallow L. Martini D. McPherson February 2006 ASCII HTML 12 multiprotocol label switching packet switched network pseudowire associated channel header

This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]

draft-ietf-pwe3-cw-06 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4385 10.17487/RFC4385
RFC4386 Internet X.509 Public Key Infrastructure Repository Locator Service S. Boeyen P. Hallam-Baker February 2006 ASCII HTML 6 pki public key infrastructure dns srv

This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-pkixrep-04 RFC8553 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC4386
RFC4387 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP P. Gutmann Editor February 2006 ASCII HTML 25 pki hypertext transfer protocol

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. [STANDARDS-TRACK]

draft-ietf-pkix-certstore-http-09 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4387
RFC4388 Dynamic Host Configuration Protocol (DHCP) Leasequery R. Woundy K. Kinnear February 2006 ASCII HTML 27 dhcpv4 ip address

A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided to DHCPv4 clients. Other processes and devices that already make use of DHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information. [STANDARDS-TRACK]

draft-ietf-dhc-leasequery-09 RFC6148 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4388 10.17487/RFC4388
RFC4389 Neighbor Discovery Proxies (ND Proxy) D. Thaler M. Talwar C. Patel April 2006 ASCII HTML 18 ndproxy

Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipv6-ndproxy-04 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4389 10.17487/RFC4389
RFC4390 Dynamic Host Configuration Protocol (DHCP) over InfiniBand V. Kashyap April 2006 ASCII HTML 6 bootstrap boot ipoib

IP over Infiniband (IPoIB) link-layer address is 20 octets long. This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol (DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network. This document describes the use of DHCP message fields when implementing DHCP over IPoIB. [STANDARDS-TRACK]

draft-ietf-ipoib-dhcp-over-infiniband-10 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4390
RFC4391 Transmission of IP over InfiniBand (IPoIB) J. Chu V. Kashyap April 2006 ASCII HTML 21 address resolution protocol arp ib

This document specifies a method for encapsulating and transmitting IPv4/IPv6 and Address Resolution Protocol (ARP) packets over InfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets. The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links. [STANDARDS-TRACK]

draft-ietf-ipoib-ip-over-infiniband-09 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4391
RFC4392 IP over InfiniBand (IPoIB) Architecture V. Kashyap April 2006 ASCII HTML 23 ib ipv4 ipv6

InfiniBand is a high-speed, channel-based interconnect between systems and devices.

This document presents an overview of the InfiniBand architecture. It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. This memo provides information for the Internet community.

draft-ietf-ipoib-architecture-04 INFORMATIONAL INFORMATIONAL IETF int ipoib 10.17487/RFC4392
RFC4393 MIME Type Registrations for 3GPP2 Multimedia Files H. Garudadri March 2006 ASCII HTML 7 third-generation partnership project 2

This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format. [STANDARDS-TRACK]

draft-garudadri-avt-3gpp2-mime-02 RFC6381 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4393
RFC4394 A Transport Network View of the Link Management Protocol (LMP) D. Fedyk O. Aboul-Magd D. Brungard J. Lang D. Papadimitriou February 2006 ASCII HTML 18 gmpls ason discovery sdh otn sonet pdh

The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. This memo provides information for the Internet community.

draft-ietf-ccamp-transport-lmp-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4394
RFC4395 Guidelines and Registration Procedures for New URI Schemes T. Hansen T. Hardie L. Masinter February 2006 ASCII HTML 15 uniform resource identifier syntax semantics

This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hansen-2717bis-2718bis-uri-guidelines-06 RFC2717 RFC2718 RFC7595 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4395 10.17487/RFC4395
RFC4396 RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text J. Rey Y. Matsui February 2006 ASCII HTML 66 3GPP 3GPP timed text streaming real-time streaming titling decorated text scrolling text karaoke hyperlinked text highlighted text blinking text highlight color text delay text style text box text wrap text sample sample descriptions modifier boxes UTF-8 UTF-16

This document specifies an RTP payload format for the transmission of 3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified. [STANDARDS-TRACK]

draft-ietf-avt-rtp-3gpp-timed-text-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4396 10.17487/RFC4396
RFC4397 A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture I. Bryskin A. Farrel February 2006 ASCII HTML 19

Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).

This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.

It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-lexicography-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4397 10.17487/RFC4397
RFC4398 Storing Certificates in the Domain Name System (DNS) S. Josefsson March 2006 ASCII HTML 17 SC-DNS cryptology authenticity

Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]

draft-ietf-dnsext-rfc2538bis-09 RFC2538 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4398 10.17487/RFC4398
RFC4399 RFC4400 RFC4401 A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) N. Williams February 2006 ASCII HTML 8 secure session layer message integrity check mic

This document defines a Pseudo-Random Function (PRF) extension to the Generic Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-prf-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC4401
RFC4402 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism N. Williams February 2006 ASCII HTML 5

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. [STANDARDS-TRACK]

draft-ietf-kitten-krb5-gssapi-prf-04 RFC7802 HISTORIC PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=4402 10.17487/RFC4402
RFC4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) B. Bergeson K. Boogert V. Nanjundaswamy February 2006 ASCII HTML 42 LDAPv3

This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory. This memo provides information for the Internet community.

draft-bergeson-uddi-ldap-schema-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4403
RFC4404 Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) R. Natarajan A. Rijhsinghani February 2006 ASCII HTML 33 mib management information base fcip-mgmt-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Fibre Channel Over TCP/IP (FCIP) entities, which are used to interconnect Fibre Channel (FC) fabrics with IP networks. [STANDARDS-TRACK]

draft-ietf-ips-fcip-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4404 10.17487/RFC4404
RFC4405 SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message E. Allman H. Katz April 2006 ASCII HTML 14 spam spoofing phishing

This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain. This memo defines an Experimental Protocol for the Internet community.

draft-katz-submitter-01 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4405
RFC4406 Sender ID: Authenticating E-Mail J. Lyon M. Wong April 2006 ASCII HTML 19 simple mail transfer protocol spam spoofing

Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address. This memo defines an Experimental Protocol for the Internet community.

draft-lyon-senderid-core-01 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4406
RFC4407 Purported Responsible Address in E-Mail Messages J. Lyon April 2006 ASCII HTML 7 pra purported responsible address

This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).This memo defines an Experimental Protocol for the Internet community.

draft-lyon-senderid-pra-01 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4407 10.17487/RFC4407
RFC4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 M. Wong W. Schlitt April 2006 ASCII HTML 48 spoofing spf

E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. This memo defines an Experimental Protocol for the Internet community.

draft-schlitt-spf-classic-02 RFC7208 RFC6652 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4408 10.17487/RFC4408
RFC4409 Message Submission for Mail R. Gellens J. Klensin April 2006 ASCII HTML 17 smtp simle mail transfer protocol ua user agent

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay and final delivery are unaffected, and continue to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

draft-gellens-submit-bis-02 RFC2476 RFC6409 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4409 10.17487/RFC4409
RFC4410 Selectively Reliable Multicast Protocol (SRMP) M. Pullen F. Zhao D. Cohen February 2006 ASCII HTML 30 transport best-effort srt selectively reliable transport

The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best-effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and a Selectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application. This memo defines an Experimental Protocol for the Internet community.

draft-pullen-srmp-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4410 10.17487/RFC4410
RFC4411 Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events J. Polk February 2006 ASCII HTML 22 Resource-Priority preempt preempted Q.850 preconditions

This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. [STANDARDS-TRACK]

draft-ietf-sipping-reason-header-for-preemption-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4411
RFC4412 Communications Resource Priority for the Session Initiation Protocol (SIP) H. Schulzrinne J. Polk February 2006 ASCII HTML 36 RP RPH preferential preempt preempted preemption queue DSN DRSN WPS ETS Q.735 Q735 disaster I.255 flash flash-override

This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. [STANDARDS-TRACK]

draft-ietf-sip-resource-priority-10 RFC7134 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4412
RFC4413 TCP/IP Field Behavior M. West S. McCann March 2006 ASCII HTML 44 transmission control protocol header compression

This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers. This memo provides information for the Internet community.

draft-ietf-rohc-tcp-field-behavior-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4413 10.17487/RFC4413
RFC4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS) A. Newton February 2006 ASCII HTML 51

This document describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries. [STANDARDS-TRACK]

draft-ietf-enum-iris-ereg-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4414
RFC4415 IANA Registration for Enumservice Voice R. Brandner L. Conroy R. Stastny February 2006 ASCII HTML 8 uniform resource identifier uri voice call audio call

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call. [STANDARDS-TRACK]

draft-ietf-enum-voice-01 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4415
RFC4416 Goals for Internet Messaging to Support Diverse Service Environments J. Wong Editor February 2006 ASCII HTML 43 IMAP protocol extensions messaging wireless handheld telephone user interface multi-modal LEMONADE extension principles history background motivation cellular interworking constraints TUI WUI client MMS

This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.

The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements to Internet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.

The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments -- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.

The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. This memo provides information for the Internet community.

draft-ietf-lemonade-goals-05 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC4416
RFC4417 Report of the 2004 IAB Messaging Workshop P. Resnick Editor P. Saint-Andre Editor February 2006 ASCII HTML 20 internet architecture board internet messaging

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA. The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB. This memo provides information for the Internet community.

draft-iab-messaging-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4417
RFC4418 UMAC: Message Authentication Code using Universal Hashing T. Krovetz Editor March 2006 ASCII HTML 27

This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors. Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.

To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. This memo provides information for the Internet community.

draft-krovetz-umac-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4418 10.17487/RFC4418
RFC4419 Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol M. Friedl N. Provos W. Simpson March 2006 ASCII HTML 10

This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK]

draft-ietf-secsh-dh-group-exchange-05 RFC8270 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4419 10.17487/RFC4419
RFC4420 Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou J.-P. Vasseur A. Ayyangar February 2006 ASCII HTML 21 SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-rsvpte-attributes-05 RFC5420 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4420
RFC4421 RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes C. Perkins February 2006 ASCII HTML 4 realtime transport protocol video stream

The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes. [STANDARDS-TRACK]

draft-ietf-avt-uncomp-video-ext-01 RFC4175 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4421
RFC4422 Simple Authentication and Security Layer (SASL) A. Melnikov Editor K. Zeilenga Editor June 2006 ASCII HTML 33 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.

This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.

This document obsoletes RFC 2222. [STANDARDS-TRACK]

draft-ietf-sasl-rfc2222bis-15 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4422
RFC4423 Host Identity Protocol (HIP) Architecture R. Moskowitz P. Nikander May 2006 ASCII HTML 24

This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since. This document represents one stable point in that evolution of understanding. This memo provides information for the Internet community.

draft-ietf-hip-arch-03 INFORMATIONAL INFORMATIONAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=4423 10.17487/RFC4423
RFC4424 Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec S. Ahmadi February 2006 ASCII HTML 8 speech codec variable-rate multicode wideband speech codec

This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e., VMR-WB mode 4). These updates do not affect the existing modes of VMR-WB already specified in RFC 4348.

The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception. [STANDARDS-TRACK]

draft-ietf-avt-rtp-vmr-wb-extension-02 RFC4348 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4424
RFC4425 RTP Payload Format for Video Codec 1 (VC-1) A. Klemets February 2006 ASCII HTML 36 smpte 421m wmv wmv9 vc-9

This memo specifies an RTP payload format for encapsulating Video Codec 1 (VC-1) compressed bit streams, as defined by the Society of Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television. [STANDARDS-TRACK]

draft-ietf-avt-rtp-vc1-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4425 10.17487/RFC4425
RFC4426 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification J. Lang Editor B. Rajagopalan Editor D. Papadimitriou Editor March 2006 ASCII HTML 23

This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-recovery-functional-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4426
RFC4427 Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) E. Mannie Editor D. Papadimitriou Editor March 2006 ASCII HTML 22

This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-recovery-terminology-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4427 10.17487/RFC4427
RFC4428 Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) D. Papadimitriou Editor E. Mannie Editor March 2006 ASCII HTML 47

This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4428 10.17487/RFC4428
RFC4429 Optimistic Duplicate Address Detection (DAD) for IPv6 N. Moore April 2006 ASCII HTML 17 internet protocol version 6 stateless address autoconfiguration neighbor discovery

Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]

draft-ietf-ipv6-optimistic-dad-07 RFC7527 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4429 10.17487/RFC4429
RFC4430 Kerberized Internet Negotiation of Keys (KINK) S. Sakane K. Kamada M. Thomas J. Vilhuber March 2006 ASCII HTML 40 ike internet key exchange

This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK]

draft-ietf-kink-kink-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec kink http://www.rfc-editor.org/errata_search.php?rfc=4430 10.17487/RFC4430
RFC4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record M. Andrews S. Weiler February 2006 ASCII HTML 4 dns domain name space

This document defines a new DNS resource record, called the DNSSEC Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors outside of the DNS delegation chain. This memo provides information for the Internet community.

draft-andrews-dlv-dns-rr-01 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4431
RFC4432 RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol B. Harris March 2006 ASCII HTML 8 rivest-sharmir-adleman public key encryption

This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK]

draft-harris-ssh-rsa-kex-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4432
RFC4433 Mobile IPv4 Dynamic Home Agent (HA) Assignment M. Kulkarni A. Patel K. Leung March 2006 ASCII HTML 25 internet protocol messaging

Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. [STANDARDS-TRACK]

draft-ietf-mip4-dynamic-assignment-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4433 10.17487/RFC4433
RFC4434 The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) P. Hoffman February 2006 ASCII HTML 6 security ipsec advanced encryption standard mac message authentication code

Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. [STANDARDS-TRACK]

draft-hoffman-rfc3664bis-05 RFC3664 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4434
RFC4435 A Framework for the Usage of Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma H. Asaeda H. Schulzrinne April 2006 ASCII HTML 22 session description protocol sdp sdpng

This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. This memo provides information for the Internet community.

draft-ietf-mmusic-img-framework-09 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4435
RFC4436 Detecting Network Attachment in IPv4 (DNAv4) B. Aboba J. Carlson S. Cheshire March 2006 ASCII HTML 15 internet protocol

The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment. [STANDARDS-TRACK]

draft-ietf-dhc-dna-ipv4-18 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4436 10.17487/RFC4436
RFC4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources J. Whitehead G. Clemm J. Reschke Editor March 2006 ASCII HTML 25 http hyper text transfer protocol

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-webdav-redirectref-protocol-13 EXPERIMENTAL EXPERIMENTAL IETF app webdav 10.17487/RFC4437
RFC4438 Fibre-Channel Name Server MIB C. DeSanti V. Gaonkar H.K. Vivek K. McCloghrie S. Gai April 2006 ASCII HTML 36 management information base T11-fc-name-server-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. [STANDARDS-TRACK]

draft-ietf-imss-fc-nsm-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4438 10.17487/RFC4438
RFC4439 Fibre Channel Fabric Address Manager MIB C. DeSanti V. Gaonkar K. McCloghrie S. Gai March 2006 ASCII HTML 40 management information base t11-tc-mib t11-fc-fabric-addr-mgr-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. [STANDARDS-TRACK]

draft-ietf-imss-fc-fam-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4439 10.17487/RFC4439
RFC4440 IAB Thoughts on the Role of the Internet Research Task Force (IRTF) S. Floyd Editor V. Paxson Editor A. Falk Editor IAB March 2006 ASCII HTML 13 internet architecture board

This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF. This memo provides information for the Internet community.

draft-iab-irtf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4440
RFC4441 The IEEE 802/IETF Relationship B. Aboba Editor March 2006 ASCII HTML 22 snmp aaa simple network management protocol authentication authorization accounting

Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. This memo provides information for the Internet community.

draft-iab-ieee-802-rel-05 RFC7241 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4441
RFC4442 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) S. Fries H. Tschofenig March 2006 ASCII HTML 18 authentication mikey multimedia internet keying protocol

TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.

This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]

draft-ietf-msec-bootstrapping-tesla-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4442
RFC4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification A. Conta S. Deering M. Gupta Editor March 2006 ASCII HTML 24

This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]

draft-ietf-ipngwg-icmp-v3-07 RFC2463 RFC2780 RFC4884 STD0089 INTERNET STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4443 10.17487/RFC4443
RFC4444 Management Information Base for Intermediate System to Intermediate System (IS-IS) J. Parker Editor April 2006 ASCII HTML 103 mib routing protocol isis-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this document describes a MIB for the Intermediate System to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks. [STANDARDS-TRACK]

draft-ietf-isis-wg-mib-26 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=4444 10.17487/RFC4444
RFC4445 A Proposed Media Delivery Index (MDI) J. Welch J. Clark April 2006 ASCII HTML 10

This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media. This memo provides information for the Internet community.

draft-welch-mdi-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4445
RFC4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) L. Martini April 2006 ASCII HTML 9

This document allocates the fixed pseudowire identifier and other fixed protocol values for protocols that have been defined in the Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA allocation instructions are also included in this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-pwe3-iana-allocation-15 BCP0116 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4446 10.17487/RFC4446
RFC4447 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor E. Rosen N. El-Aawar T. Smith G. Heron April 2006 ASCII HTML 33 mpls multiprotocol label switching protocol pdu protocol data units

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. [STANDARDS-TRACK]

draft-ietf-pwe3-control-protocol-17 RFC8077 RFC6723 RFC6870 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4447 10.17487/RFC4447
RFC4448 Encapsulation Methods for Transport of Ethernet over MPLS Networks L. Martini Editor E. Rosen N. El-Aawar G. Heron April 2006 ASCII HTML 24 pw pseudowire pdu protocol data units

An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK]

draft-ietf-pwe3-ethernet-encap-11 RFC5462 RFC8469 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4448 10.17487/RFC4448
RFC4449 Securing Mobile IPv6 Route Optimization Using a Static Shared Key C. Perkins June 2006 ASCII HTML 7 mobile node correspondent node binding management key binding updates

A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS-TRACK]

draft-ietf-mip6-precfgkbm-04 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4449 10.17487/RFC4449
RFC4450 Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents E. Lear H. Alvestrand March 2006 ASCII HTML 11

This memo documents an experiment to review and classify Proposed Standards as not reflecting documented practice within the world today. The results identify a set of documents that were marked as Proposed Standards that are now reclassified as Historic. This memo provides information for the Internet community.

draft-ietf-newtrk-decruft-experiment-03 INFORMATIONAL INFORMATIONAL IETF gen newtrk http://www.rfc-editor.org/errata_search.php?rfc=4450 10.17487/RFC4450
RFC4451 BGP MULTI_EXIT_DISC (MED) Considerations D. McPherson V. Gill March 2006 ASCII HTML 13 border gateway protocol

The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.

This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. This memo provides information for the Internet community.

draft-ietf-grow-bgp-med-considerations-05 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC4451
RFC4452 The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces H. Van de Sompel T. Hammond E. Neylon S. Weibel April 2006 ASCII HTML 17 uniform resource identifier

This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces. Namespaces participating in the "info" URI scheme are regulated by an "info" Registry mechanism. This memo provides information for the Internet community.

draft-vandesompel-info-uri-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4452 10.17487/RFC4452
RFC4453 Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis April 2006 ASCII HTML 8 sip extensions

The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications. This memo provides information for the Internet community.

draft-ietf-sipping-consent-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4453
RFC4454 Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) S. Singh M. Townsley C. Pignataro May 2006 ASCII HTML 26 extensible tunneling protocol

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use the L2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over an IP network. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-atm-04 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4454
RFC4455 Definition of Managed Objects for Small Computer System Interface (SCSI) Entities M. Hallak-Stamler M. Bakke Y. Lederman M. Krueger K. McCloghrie April 2006 ASCII HTML 88 mib management information base scsi-mib

This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS-TRACK]

draft-ietf-ips-scsi-mib-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4455 10.17487/RFC4455
RFC4456 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates E. Chen R. Chandra April 2006 ASCII HTML 12 BGP-RR Border Gateway Protocol autonomous system

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed.

This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP).

This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK]

draft-ietf-idr-rfc2796bis-02 RFC2796 RFC1966 RFC7606 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4456 10.17487/RFC4456
RFC4457 The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) G. Camarillo G. Blanco April 2006 ASCII HTML 8 3gpp third generation partnership project 3rd generation partnership project ims ip multimedia subsystem

This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. This memo provides information for the Internet community.

draft-camarillo-sipping-user-database-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4457
RFC4458 Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) C. Jennings F. Audet J. Elwell April 2006 ASCII HTML 21 universal resource identifiers

The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. This memo provides information for the Internet community.

draft-jennings-sip-voicemail-uri-06 RFC8119 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4458 10.17487/RFC4458
RFC4459 MTU and Fragmentation Issues with In-the-Network Tunneling P. Savola April 2006 ASCII HTML 14

Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. This memo provides information for the Internet community.

draft-savola-mtufrag-network-tunneling-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4459
RFC4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues R. Stewart I. Arias-Rodriguez K. Poon A. Caro M. Tuexen April 2006 ASCII HTML 109 SCTP IP internet transport packet network

This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using SCTP along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided. This memo provides information for the Internet community.

draft-ietf-tsvwg-sctpimpguide-16 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4460
RFC4461 Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) S. Yasukawa Editor April 2006 ASCII HTML 30 p2mp multiprotocol label switching

This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).

There is no intent to specify solution-specific details or application-specific requirements in this document.

The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), Time Division Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. This memo provides information for the Internet community.

draft-ietf-mpls-p2mp-sig-requirement-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4461
RFC4462 Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol J. Hutzelman J. Salowey J. Galbraith V. Welch May 2006 ASCII HTML 29

The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network.

The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion.

This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange.

This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK]

draft-ietf-secsh-gsskeyex-10 RFC8732 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh http://www.rfc-editor.org/errata_search.php?rfc=4462 10.17487/RFC4462
RFC4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks S. Shanmugham P. Monaco B. Eberman April 2006 ASCII HTML 86

This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area.

MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol). This memo provides information for the Internet community.

draft-shanmugham-mrcp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4463
RFC4464 Signaling Compression (SigComp) Users' Guide A. Surtees M. West May 2006 ASCII HTML 43

This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. This memo provides information for the Internet community.

draft-ietf-rohc-sigcomp-user-guide-04 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4464
RFC4465 Signaling Compression (SigComp) Torture Tests A. Surtees M. West June 2006 ASCII HTML 68 SigComp Universal Decompressor Virtual Machine

This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. This memo provides information for the Internet community.

draft-ietf-rohc-sigcomp-torture-tests-03 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC4465
RFC4466 Collected Extensions to IMAP4 ABNF A. Melnikov C. Daboo April 2006 ASCII HTML 17

Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place.

This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions.

This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK]

draft-melnikov-imap-ext-abnf-08 RFC2088 RFC2342 RFC3501 RFC3502 RFC3516 RFC6237 RFC7377 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4466
RFC4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension M. Crispin May 2006 ASCII HTML 18 imap url imapurl

This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.

An IMAP server that supports this extension indicates this with a capability name of "URLAUTH". [STANDARDS-TRACK]

draft-ietf-lemonade-urlauth-08 RFC5092 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC4467
RFC4468 Message Submission BURL Extension C. Newman May 2006 ASCII HTML 14 URLAUTH IMAP IMAPURL Forward-without-download mobile-client lemonade

The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server. [STANDARDS-TRACK]

draft-ietf-lemonade-burl-04 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4468 10.17487/RFC4468
RFC4469 Internet Message Access Protocol (IMAP) CATENATE Extension P. Resnick April 2006 ASCII HTML 13 append

The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on the IMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server. [STANDARDS-TRACK]

draft-ietf-lemonade-catenate-05 RFC3501 RFC3502 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4469 10.17487/RFC4469
RFC4470 Minimally Covering NSEC Records and DNSSEC On-line Signing S. Weiler J. Ihren April 2006 ASCII HTML 8 dns security domain name system

This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-online-signing-02 RFC4035 RFC4034 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4470 10.17487/RFC4470
RFC4471 Derivation of DNS Name Predecessor and Successor G. Sisson B. Laurie September 2006 ASCII HTML 23 domain namespace dynamic nsec dnssec

This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnsext-dns-name-p-s-01 EXPERIMENTAL EXPERIMENTAL IETF int dnsext 10.17487/RFC4471
RFC4472 Operational Considerations and Issues with IPv6 DNS A. Durand J. Ihren P. Savola April 2006 ASCII HTML 29 domain name system internet protocol version 6

This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. This memo provides information for the Internet community.

draft-ietf-dnsop-ipv6-dns-issues-12 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4472
RFC4473 Requirements for Internet Media Guides (IMGs) Y. Nomura R. Walsh J-P. Luoma J. Ott H. Schulzrinne May 2006 ASCII HTML 23 media-on-deman multicast

This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. This memo provides information for the Internet community.

draft-ietf-mmusic-img-req-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC4473
RFC4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings August 2006 ASCII HTML 41 security identity identity-info

The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]

draft-ietf-sip-identity-06 RFC8224 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4474 10.17487/RFC4474
RFC4475 Session Initiation Protocol (SIP) Torture Test Messages R. Sparks Editor A. Hawrylyshen A. Johnston J. Rosenberg H. Schulzrinne May 2006 ASCII HTML 53

This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. This memo provides information for the Internet community.

draft-ietf-sipping-torture-tests-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4475
RFC4476 Attribute Certificate (AC) Policies Extension C. Francis D. Pinkas May 2006 ASCII HTML 11 acp attribute certificate policies

This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specific ACPs. [STANDARDS-TRACK]

draft-ietf-pkix-acpolicies-extn-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4476
RFC4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues T. Chown S. Venaas C. Strauf May 2006 ASCII HTML 14 internet protocol

A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken. This memo provides information for the Internet community.

draft-ietf-dhc-dual-stack-04 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC4477
RFC4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol Y. Nir April 2006 ASCII HTML 5 lifetime

This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. This memo defines an Experimental Protocol for the Internet community.

draft-nir-ikev2-auth-lt-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4478
RFC4479 A Data Model for Presence J. Rosenberg July 2006 ASCII HTML 35 simple sip session initiation protocol

This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. [STANDARDS-TRACK]

draft-ietf-simple-presence-data-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4479 10.17487/RFC4479
RFC4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) H. Schulzrinne V. Gurbani P. Kyzivat J. Rosenberg July 2006 ASCII HTML 37

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity.

This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity.

These extensions include presence information for persons, services (tuples), and devices. [STANDARDS-TRACK]

draft-ietf-simple-rpid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4480 10.17487/RFC4480
RFC4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals H. Schulzrinne July 2006 ASCII HTML 9

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. [STANDARDS-TRACK]

draft-ietf-simple-future-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4481
RFC4482 CIPID: Contact Information for the Presence Information Data Format H. Schulzrinne July 2006 ASCII HTML 11 pidf

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons. [STANDARDS-TRACK]

draft-ietf-simple-cipid-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4482
RFC4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages E. Burger Editor May 2006 ASCII HTML 17 universal resource locator mime external-body access-type

This document defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI. [STANDARDS-TRACK]

draft-ietf-sip-content-indirect-mech-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4483 10.17487/RFC4483
RFC4484 Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) J. Peterson J. Polk D. Sicker H. Tschofenig August 2006 ASCII HTML 15 policy decision

This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. This memo provides information for the Internet community.

draft-ietf-sipping-trait-authz-02 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4484
RFC4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) J. Rosenberg H. Schulzrinne May 2006 ASCII HTML 23 interactive communication

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. This memo provides information for the Internet community.

draft-ietf-sip-guidelines-09 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC4485
RFC4486 Subcodes for BGP Cease Notification Message E. Chen V. Gillet April 2006 ASCII HTML 6 border gateway protocol bgp peers

This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. [STANDARDS-TRACK]

draft-ietf-idr-cease-subcode-07 RFC8203 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4486
RFC4487 Mobile IPv6 and Firewalls: Problem Statement F. Le S. Faccin B. Patil H. Tschofenig May 2006 ASCII HTML 16 3g mobile networks

This document captures the issues that may arise in the deployment of IPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such as General Packet Radio Service / Universal Mobile Telecommunications System (GPRS/UMTS) and CDMA2000 networks.

The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. This memo provides information for the Internet community.

draft-ietf-mip6-firewalls-04 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4487
RFC4488 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription O. Levin May 2006 ASCII HTML 8

The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request. [STANDARDS-TRACK]

draft-ietf-sip-refer-with-norefersub-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4488
RFC4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses J-S. Park M-K. Shin H-J. Kim April 2006 ASCII HTML 6 iid interface identifiers

This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use of Interface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast-prefix-based IPv6 multicast addresses. This memo updates RFC 3306. [STANDARDS-TRACK]

draft-ietf-ipv6-link-scoped-mcast-09 RFC3306 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC4489
RFC4490 Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) S. Leontiev Editor G. Chudov Editor May 2006 ASCII HTML 29 CPCMS S/MIME PKIX X.509 certificate CRL revocation public-key one-way hash block cipher encryption decryption MAC HMAC PRF wrap unwrap UKM KEK key Diffie-Hellman agreement transport parameter derivation digest CBC counter mode digital signature

This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents. [STANDARDS-TRACK]

draft-ietf-smime-gost-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4490 10.17487/RFC4490
RFC4491 Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile S. Leontiev Editor D. Shefanovski Editor May 2006 ASCII HTML 20 PKIX X.509 CPPK public-key one-way hash function block cipher encryption decryption key derivation parameter message digest digital signature 34.310 34.311 34.310-95 34.310-2004 34.311-95

This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]

draft-ietf-pkix-gost-cppk-05 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4491 10.17487/RFC4491
RFC4492 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) S. Blake-Wilson N. Bolyard V. Gupta C. Hawk B. Moeller May 2006 ASCII HTML 35 ecdh elliptic curve diffie-hellman elliptic curve digital signature algorithm ecdsa

This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. This memo provides information for the Internet community.

draft-ietf-tls-ecc-12 RFC8422 RFC5246 RFC7027 RFC7919 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=4492 10.17487/RFC4492
RFC4493 The AES-CMAC Algorithm JH. Song R. Poovendran J. Lee T. Iwata June 2006 ASCII HTML 20 cipher-based message authentication code omac1 one-key cbc mac1 advanced encryption algorithm

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard (AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

draft-songlee-aes-cmac-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4493
RFC4494 The AES-CMAC-96 Algorithm and Its Use with IPsec JH. Song R. Poovendran J. Lee June 2006 ASCII HTML 8 cipher-basd message authentication code one-key cbc-mac1 omac1 xcbc extended cipher block chaining advanced encryption standard

The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code (CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode as an authentication mechanism of the IPsec Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. This new algorithm is named AES-CMAC-96. [STANDARDS-TRACK]

draft-songlee-aes-cmac-96-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4494
RFC4495 A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow J. Polk S. Dhesikan May 2006 ASCII HTML 21 rsvpv1

This document proposes an extension to the Resource Reservation Protocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms of RSVP tunnels. This specification is an extension of RFC 2205. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-bw-reduction-02 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4495
RFC4496 Open Pluggable Edge Services (OPES) SMTP Use Cases M. Stecher A. Barbir May 2006 ASCII HTML 12

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. This memo provides information for the Internet community.

draft-ietf-opes-smtp-use-cases-06 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4496
RFC4497 Interworking between the Session Initiation Protocol (SIP) and QSIG J. Elwell F. Derks P. Mourot O. Rousseau May 2006 ASCII HTML 65 telecommunication networks enterprise networks signalling

This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-qsig2sip-04 BCP0117 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4497
RFC4498 The Managed Object Aggregation MIB G. Keeni May 2006 ASCII HTML 29 management information base aggregate mib time aggregate mib

This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the Aggregation MIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated Managed Object instances. This memo defines an Experimental Protocol for the Internet community.

draft-glenn-mo-aggr-mib-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4498
RFC4499 RFC4500 RFC4501 Domain Name System Uniform Resource Identifiers S. Josefsson May 2006 ASCII HTML 10 dns uri

This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]

draft-josefsson-dns-url-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4501 10.17487/RFC4501
RFC4502 Remote Network Monitoring Management Information Base Version 2 S. Waldbusser May 2006 ASCII HTML 142 RMON-MIB RMON MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.

This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module. [STANDARDS-TRACK]

draft-ietf-rmonmib-rmon2-v2-05 RFC2021 RFC3273 DRAFT STANDARD DRAFT STANDARD IETF ops rmonmib http://www.rfc-editor.org/errata_search.php?rfc=4502 10.17487/RFC4502
RFC4503 A Description of the Rabbit Stream Cipher Algorithm M. Boesgaard M. Vesterager E. Zenner May 2006 ASCII HTML 12 iv initialization vector encryption algorithm

This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed. This memo provides information for the Internet community.

draft-zenner-rabbit-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4503 10.17487/RFC4503
RFC4504 SIP Telephony Device Requirements and Configuration H. Sinnreich Editor S. Lass C. Stredicke May 2006 ASCII HTML 37 session initiation protocol pc pda analog

This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.

We present a glossary of the most common settings and some of the more widely used values for some settings. This memo provides information for the Internet community.

draft-sinnreich-sipdev-req-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4504
RFC4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga June 2006 ASCII HTML 9 SASL-ANON Simple Authentication Security Layer

On the Internet, it is common practice to permit anonymous access to various services. Traditionally, this has been done with a plain-text password mechanism using "anonymous" as the user name and using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. [STANDARDS-TRACK]

draft-ietf-sasl-anon-05 RFC2245 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl 10.17487/RFC4505
RFC4506 XDR: External Data Representation Standard M. Eisler Editor May 2006 ASCII HTML 27 XDR rpc onc open network computing

This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK]

draft-ietf-nfsv4-rfc1832bis-06 RFC1832 STD0067 INTERNET STANDARD INTERNET STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=4506 10.17487/RFC4506
RFC4507 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig May 2006 ASCII HTML 17

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping \%per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. [STANDARDS-TRACK]

draft-salowey-tls-ticket-07 RFC5077 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4507
RFC4508 Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method O. Levin A. Johnston May 2006 ASCII HTML 6 caller preferences

The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. [STANDARDS-TRACK]

draft-ietf-sip-refer-feature-param-01 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4508
RFC4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) W. Hardaker May 2006 ASCII HTML 7 domain name system dns dnskey

This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]

draft-ietf-dnsext-ds-sha256-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4509 10.17487/RFC4509
RFC4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map K. Zeilenga Editor June 2006 ASCII HTML 7 LDAPV3 LDAv3 x.500 LDAP3-ATD syntax LDAP3-UTF8 x.500 ASN.1 string format STR-LDAP LDAP-URL Lightweight Directory Access Protocol Universal Resource Locator

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification. [STANDARDS-TRACK]

draft-ietf-ldapbis-roadmap-08 RFC2251 RFC2252 RFC2253 RFC2254 RFC2255 RFC2256 RFC2829 RFC2830 RFC3377 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4510
RFC4511 Lightweight Directory Access Protocol (LDAP): The Protocol J. Sermersheim Editor June 2006 ASCII HTML 68 LDAP TLS LDAPv3 LDAv3 x.500

This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]

draft-ietf-ldapbis-protocol-32 RFC2251 RFC2830 RFC3771 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4511 10.17487/RFC4511
RFC4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models K. Zeilenga Editor June 2006 ASCII HTML 52 LDAv3 x.500 LDAPv3 LDAP3-ATD syntax elective extensions mechanisms

The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]

draft-ietf-ldapbis-models-14 RFC2251 RFC2252 RFC2256 RFC3674 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4512 10.17487/RFC4512
RFC4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms R. Harrison Editor June 2006 ASCII HTML 34 LDAP TLS

This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.

This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.

This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.

This document, together with other documents in the LDAP Technical Specification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. [STANDARDS-TRACK]

draft-ietf-ldapbis-authmeth-19 RFC2251 RFC2829 RFC2830 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis 10.17487/RFC4513
RFC4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names K. Zeilenga Editor June 2006 ASCII HTML 15 LDAP3-UTF8 LDAPv3 x.500 ASN.1 string format

The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. [STANDARDS-TRACK]

draft-ietf-ldapbis-dn-16 RFC2253 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4514 10.17487/RFC4514
RFC4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters M. Smith Editor T. Howes June 2006 ASCII HTML 12 STR-LDAP STRLDAP LDAPv3 X.500 BER ASN.1

Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. [STANDARDS-TRACK]

draft-ietf-ldapbis-filter-09 RFC2254 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4515 10.17487/RFC4515
RFC4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator M. Smith Editor T. Howes June 2006 ASCII HTML 15 LDAP-URL LDAPURL LDAP search URL URI LDAPv3

This document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. [STANDARDS-TRACK]

draft-ietf-ldapbis-url-09 RFC2255 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4516 10.17487/RFC4516
RFC4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules S. Legg Editor June 2006 ASCII HTML 53 LDAP3-ATD LDAv3 x.500 syntax,

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. [STANDARDS-TRACK]

draft-ietf-ldapbis-syntaxes-11 RFC2252 RFC2256 RFC3698 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4517 10.17487/RFC4517
RFC4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation K. Zeilenga June 2006 ASCII HTML 14

The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. [STANDARDS-TRACK]

draft-ietf-ldapbis-strprep-07 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4518 10.17487/RFC4518
RFC4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications A. Sciberras Editor June 2006 ASCII HTML 35 Lightweight Directory Access Protocol syntax

This document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. [STANDARDS-TRACK]

draft-ietf-ldapbis-user-schema-11 RFC2256 RFC2247 RFC2798 RFC2377 PROPOSED STANDARD PROPOSED STANDARD IETF app ldapbis http://www.rfc-editor.org/errata_search.php?rfc=4519 10.17487/RFC4519
RFC4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) K. Zeilenga June 2006 ASCII HTML 19

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ldapbis-bcp64-07 RFC3383 BCP0064 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ldapbis 10.17487/RFC4520
RFC4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions K. Zeilenga June 2006 ASCII HTML 16

The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-zeilenga-ldap-ext-10 BCP0118 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4521 10.17487/RFC4521
RFC4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option S. Legg June 2006 ASCII HTML 8 ber ldap-specific encoding

Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP\-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. [STANDARDS-TRACK]

draft-legg-ldap-binary-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4522
RFC4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates K. Zeilenga June 2006 ASCII HTML 24 LDAP3-ATD LDAv3 x.500 syntax pkix

This document describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using the Lightweight Directory Access Protocol (LDAP). The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. [STANDARDS-TRACK]

draft-zeilenga-ldap-x509-02 RFC2252 RFC2256 RFC2587 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4523 10.17487/RFC4523
RFC4524 COSINE LDAP/X.500 Schema K. Zeilenga Editor June 2006 ASCII HTML 25 Naming

This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE and Internet X.500 pilot projects.

This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. [STANDARDS-TRACK]

draft-zeilenga-ldap-cosine-02 RFC1274 RFC2247 RFC2798 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4524 10.17487/RFC4524
RFC4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension K. Zeilenga June 2006 ASCII HTML 6 pre-read post-read control extension

This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension. This memo provides information for the Internet community.

draft-zeilenga-ldap-incr-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4525
RFC4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters K. Zeilenga June 2006 ASCII HTML 5 x.500 string representation

This document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. [STANDARDS-TRACK]

draft-zeilenga-ldap-t-f-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4526 10.17487/RFC4526
RFC4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls K. Zeilenga June 2006 ASCII HTML 8

This document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. [STANDARDS-TRACK]

draft-zeilenga-ldap-readentry-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4527
RFC4528 Lightweight Directory Access Protocol (LDAP) Assertion Control K. Zeilenga June 2006 ASCII HTML 6 test and set test and clear

This document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. [STANDARDS-TRACK]

draft-zeilenga-ldap-assert-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4528
RFC4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol K. Zeilenga June 2006 ASCII HTML 6

The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. This memo provides information for the Internet community.

draft-zeilenga-ldap-adlist-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4529 10.17487/RFC4529
RFC4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute K. Zeilenga June 2006 ASCII HTML 8 x.500 universally unique identifier

This document describes the LDAP/X.500 \'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. [STANDARDS-TRACK]

draft-zeilenga-ldap-uuid-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4530
RFC4531 Lightweight Directory Access Protocol (LDAP) Turn Operation K. Zeilenga June 2006 ASCII HTML 9 turn request turn response

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. This memo defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldap-turn-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4531
RFC4532 Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation K. Zeilenga June 2006 ASCII HTML 7 authorization identity

This specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation. [STANDARDS-TRACK]

draft-zeilenga-ldap-authzid-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4532 10.17487/RFC4532
RFC4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation K. Zeilenga J.H. Choi June 2006 ASCII HTML 32 dit directory information tree

This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the Directory Information Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. This memo defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldup-sync-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4533
RFC4534 Group Security Policy Token v1 A Colegrove H Harney June 2006 ASCII HTML 33 cryptographic group

The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. [STANDARDS-TRACK]

draft-ietf-msec-policy-token-sec-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4534 10.17487/RFC4534
RFC4535 GSAKMP: Group Secure Association Key Management Protocol H. Harney U. Meth A. Colegrove G. Gross June 2006 ASCII HTML 106 security framework cryptographic network

This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. [STANDARDS-TRACK]

draft-ietf-msec-gsakmp-sec-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4535
RFC4536 The application/smil and application/smil+xml Media Types P. Hoschka July 2006 ASCII HTML 8 synchronized multimedia integration language

This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. This memo provides information for the Internet community.

draft-hoschka-smil-media-type-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4536
RFC4537 Kerberos Cryptosystem Negotiation Extension L. Zhu P. Leach K. Jaganathan June 2006 ASCII HTML 6

This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. [STANDARDS-TRACK]

draft-zhu-kerb-enctype-nego-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC4537
RFC4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) J. Rosenberg June 2006 ASCII HTML 17 tdialog

This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. [STANDARDS-TRACK]

draft-ietf-sip-target-dialog-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4538
RFC4539 Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF) T. Edwards May 2006 ASCII HTML 6

This document serves to register a media type for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. This memo provides information for the Internet community.

draft-edwards-mime-mxf-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4539
RFC4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 M. Stiemerling J. Quittek C. Cadar May 2006 ASCII HTML 67 midcom

This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. This memo defines an Experimental Protocol for the Internet community.

draft-stiemerling-midcom-simco-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4540
RFC4541 Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches M. Christensen K. Kimball F. Solensky May 2006 ASCII HTML 16 igmpv3 mldv2

This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community.

draft-ietf-magma-snoop-12 INFORMATIONAL INFORMATIONAL IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4541 10.17487/RFC4541
RFC4542 Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite F. Baker J. Polk May 2006 ASCII HTML 42 ieps internet emergency preparedness service call admission control cac phb per hop behavior multi-level precedence and preemption mlpp government emergency telecommunication service gets

RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.

This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. This memo provides information for the Internet community.

draft-ietf-tsvwg-mlpp-that-works-04 RFC5865 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4542
RFC4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH D. McGrew J. Viega May 2006 ASCII HTML 14 encapsulating security payload gcm galois/counter mode authentication header

This memo describes the use of the Advanced Encryption Standard (AES) Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK]

draft-mcgrew-aes-gmac-esp-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4543 10.17487/RFC4543
RFC4544 Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) M. Bakke M. Krueger T. McSweeney J. Muchow May 2006 ASCII HTML 83 tcp/ip scsi

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). [STANDARDS-TRACK]

draft-ietf-ips-iscsi-mib-11 RFC7147 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4544 10.17487/RFC4544
RFC4545 Definitions of Managed Objects for IP Storage User Identity Authorization M. Bakke J. Muchow May 2006 ASCII HTML 43 mib management information base snmp tcp/ip ips-auth-mib

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. [STANDARDS-TRACK]

draft-ietf-ips-auth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4545 10.17487/RFC4545
RFC4546 Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces D. Raftus E. Cardona June 2006 ASCII HTML 139 cmts cm upstream downstream tdma atdma scdma quality of service channel utilizazation

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for Simple Network Management Protocol (SNMP) based management of the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). [STANDARDS-TRACK]

draft-ietf-ipcdn-docs-rfmibv2-14 RFC2670 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4546
RFC4547 Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems A. Ahmad G. Nakanishi June 2006 ASCII HTML 40 snmp simple network management protocol mib smiv2 DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB.

This memo specifies a MIB module in a manner that is compliant to the Structure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. [STANDARDS-TRACK]

draft-ietf-ipcdn-docsisevent-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4547
RFC4548 Internet Code Point (ICP) Assignments for NSAP Addresses E. Gray J. Rutemiller G. Swallow May 2006 ASCII HTML 9 network service access point

This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. [STANDARDS-TRACK]

draft-gray-rfc1888bis-03 RFC1888 RFC4048 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4548
RFC4549 Synchronization Operations for Disconnected IMAP4 Clients A. Melnikov Editor June 2006 ASCII HTML 35 internet message access protocol

This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.

This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.

This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. This memo provides information for the Internet community.

draft-melnikov-imap-disc-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4549
RFC4550 Internet Email to Support Diverse Service Environments (Lemonade) Profile S. Maes A. Melnikov June 2006 ASCII HTML 23 internet message access protocol,

This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). [STANDARDS-TRACK]

draft-ietf-lemonade-profile-07 RFC5550 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4550 10.17487/RFC4550
RFC4551 IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization A. Melnikov S. Hole June 2006 ASCII HTML 25 internet mail access protocol

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.

The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.

This document defines an extension to IMAP (RFC 3501). [STANDARDS-TRACK]

draft-ietf-imapext-condstore-09 RFC7162 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=4551 10.17487/RFC4551
RFC4552 Authentication/Confidentiality for OSPFv3 M. Gupta N. Melam June 2006 ASCII HTML 15 open shortest path first authentication header encapsulating security payload ah/esp

This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4552 10.17487/RFC4552
RFC4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) A. Vainshtein Editor YJ. Stein Editor June 2006 ASCII HTML 27 SAToP pseudowires circuit emulation structure-agnostic emulation

This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK]

draft-ietf-pwe3-satop-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4553 10.17487/RFC4553
RFC4554 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks T. Chown June 2006 ASCII HTML 11 Virtual Local Area Network

Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. This memo provides information for the Internet community.

draft-ietf-v6ops-vlan-usage-01 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4554
RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE) P. Eronen June 2006 ASCII HTML 33 internet key exchange ipsec internet protocol security vpn virtual private networks

This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. [STANDARDS-TRACK]

draft-ietf-mobike-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec mobike 10.17487/RFC4555
RFC4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu B. Tung June 2006 ASCII HTML 42

This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK]

draft-ietf-cat-kerberos-pk-init-34 RFC6112 RFC8062 RFC8636 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4556 10.17487/RFC4556
RFC4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan N. Williams June 2006 ASCII HTML 6

This document defines a mechanism to enable in-band transmission of Online Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT), which is the Kerberos Version 5 extension that provides for the use of public key cryptography. [STANDARDS-TRACK]

draft-ietf-krb-wg-ocsp-for-pkinit-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=4557 10.17487/RFC4557
RFC4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement Z. Ali R. Rahman D. Prairie D. Papadimitriou June 2006 ASCII HTML 7 Multi-Protocol Label Switching mpls Generalized Multi-Protocol Label Switching gmpls Traffic Engineering te rsvp-te gr graceful restart

Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. [STANDARDS-TRACK]

draft-ietf-ccamp-rsvp-node-id-based-hello-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4558
RFC4559 SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows K. Jaganathan L. Zhu J. Brezak June 2006 ASCII HTML 8 msie microsoft internet explorer iis internet information services simple and protected negotiate nt lan manager

This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document. This memo provides information for the Internet community.

draft-jaganathan-kerberos-http-01 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4559 10.17487/RFC4559
RFC4560 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations J. Quittek Editor K. White Editor June 2006 ASCII HTML 100 mib management information base DISMAN-PING-MIB DEFINITIONS DISMAN-TRACEROUTE-MIB DEFINITIONS DISMAN-NSLOOKUP-MIB DEFINITIONS

This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP address at a remote host.

Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. [STANDARDS-TRACK]

draft-ietf-disman-remops-mib-v2-09 RFC2925 PROPOSED STANDARD PROPOSED STANDARD IETF ops disman 10.17487/RFC4560
RFC4561 Definition of a Record Route Object (RRO) Node-Id Sub-Object J.-P. Vasseur Editor Z. Ali S. Sivabalan June 2006 ASCII HTML 10 multiprotocol label switching traffic engineering plr point of local repair igp interior gateway protocol as autonomous system abr area border router asbr autonomous system border router

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]

draft-ietf-mpls-nodeid-subobject-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4561
RFC4562 MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network T. Melsen S. Blake June 2006 ASCII HTML 13 Ethernet Access Network ARP DHCP

This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.

The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. This memo provides information for the Internet community.

draft-melsen-mac-forced-fwd-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4562
RFC4563 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) E. Carrara V. Lehtovirta K. Norrman June 2006 ASCII HTML 10 security key management multicast broadcast MBMS

This memo specifies a new Type (the Key ID Information Type) for the General Extension Payload in the Multimedia Internet KEYing (MIKEY) Protocol. This is used in, for example, the Multimedia Broadcast/Multicast Service specified in the Third Generation Partnership Project. [STANDARDS-TRACK]

draft-ietf-msec-newtype-keyid-05 RFC6309 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4563
RFC4564 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) S. Govindan Editor H. Cheng ZH. Yao WH. Zhou L. Yang July 2006 ASCII HTML 32 wlan wireless local area network

This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs. This memo provides information for the Internet community.

draft-ietf-capwap-objectives-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4564
RFC4565 Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols D. Loher D. Nelson O. Volinsky B. Sarikaya July 2006 ASCII HTML 31

This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26, 2005. his memo provides information for the Internet community.

draft-ietf-capwap-eval-00 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC4565
RFC4566 SDP: Session Description Protocol M. Handley V. Jacobson C. Perkins July 2006 ASCII HTML 49 SDP mbone internet multicast backbone multimedia internet addresses syntax

This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-new-26 RFC2327 RFC3266 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4566 10.17487/RFC4566
RFC4567 Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) J. Arkko F. Lindholm M. Naslund K. Norrman E. Carrara July 2006 ASCII HTML 30 key management protocol multimedia internet keying mikey

This document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.

General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. [STANDARDS-TRACK]

draft-ietf-mmusic-kmgmt-ext-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4567 10.17487/RFC4567
RFC4568 Session Description Protocol (SDP) Security Descriptions for Media Streams F. Andreasen M. Baugher D. Wing July 2006 ASCII HTML 44 srtp secure real-time transport protocol

This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK]

draft-ietf-mmusic-sdescriptions-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4568 10.17487/RFC4568
RFC4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag G. Camarillo July 2006 ASCII HTML 4

This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. This memo provides information for the Internet community.

draft-ietf-sipping-message-tag-00 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC4569
RFC4570 Session Description Protocol (SDP) Source Filters B. Quinn R. Finlayson July 2006 ASCII HTML 14 internet protocol ip source-filter ssm source-specific multicast

This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-srcfilter-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4570 10.17487/RFC4570
RFC4571 Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport J. Lazzaro July 2006 ASCII HTML 9 TCP-based media transport TCP tunnel transmission control protocol

This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS-TRACK]

draft-ietf-avt-rtp-framing-contrans-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4571 10.17487/RFC4571
RFC4572 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox July 2006 ASCII HTML 17 setup connection reestablishment

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document extends and updates RFC 4145. [STANDARDS-TRACK]

draft-ietf-mmusic-comedia-tls-06 RFC8122 RFC4145 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4572
RFC4573 MIME Type Registration for RTP Payload Format for H.224 R. Even A. Lochbaum July 2006 ASCII HTML 7 real time transport protocol itu h.281 h.224 far-end camera control

In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS-TRACK]

draft-ietf-avt-mime-h224-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4573
RFC4574 The Session Description Protocol (SDP) Label Attribute O. Levin G. Camarillo August 2006 ASCII HTML 8 media level attribute media stream

This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-media-label-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4574
RFC4575 A Session Initiation Protocol (SIP) Event Package for Conference State J. Rosenberg H. Schulzrinne O. Levin Editor August 2006 ASCII HTML 48 conference event package uri uniform resource identifier

This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS-TRACK]

draft-ietf-sipping-conference-package-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC4575
RFC4576 Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII HTML 7 service provider sp provider edge pe

This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. [STANDARDS-TRACK]

draft-ietf-ospf-2547-dnbit-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4576
RFC4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) E. Rosen P. Psenak P. Pillay-Esnault June 2006 ASCII HTML 25 ce open shortest path first mpls Multiprotocol Label Switching

Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.

This document updates RFC 4364. [STANDARDS-TRACK]

draft-ietf-l3vpn-ospf-2547-06 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4577 10.17487/RFC4577
RFC4578 Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) M. Johnston S. Venaas Editor November 2006 ASCII HTML 7 efi extensible firmware interface

We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible Firmware Interface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This memo provides information for the Internet community.

draft-ietf-dhc-pxe-options-03 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=4578 10.17487/RFC4578
RFC4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents A. Johnston O. Levin August 2006 ASCII HTML 43 ua conference-unaware conference-aware focus

This specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-cc-conferencing-07 BCP0119 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC4579
RFC4580 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option B. Volz June 2006 ASCII HTML 6

This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-subid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4580
RFC4581 Cryptographically Generated Addresses (CGA) Extension Field Format M. Bagnulo J. Arkko October 2006 ASCII HTML 4 tlv

This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS-TRACK]

draft-bagnulo-cga-ext-02 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4581
RFC4582 The Binary Floor Control Protocol (BFCP) G. Camarillo J. Ott K. Drage November 2006 ASCII HTML 65 conference

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.

This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]

draft-ietf-xcon-bfcp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC4582
RFC4583 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams G. Camarillo November 2006 ASCII HTML 12 bfcp stream

This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-bfcp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=4583 10.17487/RFC4583
RFC4584 Extension to Sockets API for Mobile IPv6 S. Chakrabarti E. Nordmark July 2006 ASCII HTML 25 advanced socket api mobility header messages hom address destination routing header type 2 socket applications

This document describes data structures and API support for Mobile IPv6 as an extension to the Advanced Socket API for IPv6.

Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information for Mobility Header messages, Home Address destination options, and Routing Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. This memo provides information for the Internet community.

draft-ietf-mip6-mipext-advapi-07 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4584 10.17487/RFC4584
RFC4585 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) J. Ott S. Wenger N. Sato C. Burmeister J. Rey July 2006 ASCII HTML 51 media stream feedback based error audio visual profile

Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-feedback-11 RFC5506 RFC8108 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4585 10.17487/RFC4585
RFC4586 Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations C. Burmeister R. Hakenberg A. Miyazaki J. Ott N. Sato S. Fukunaga July 2006 ASCII HTML 28 Real-time Transport Protocol

This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. This memo provides information for the Internet community.

draft-burmeister-avt-rtcp-feedback-sim-06 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4586 10.17487/RFC4586
RFC4587 RTP Payload Format for H.261 Video Streams R. Even August 2006 ASCII HTML 17 RTP-H.261 real-time transport protocol sdp session description protocol

This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.

The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.

This specification obsoletes RFC 2032. [STANDARDS-TRACK]

draft-ietf-avt-rfc2032-bis-13 RFC2032 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4587 10.17487/RFC4587
RFC4588 RTP Retransmission Payload Format J. Rey D. Leon A. Miyazaki V. Varsa R. Hakenberg July 2006 ASCII HTML 35 real time transport protocol rtcp real-time transport control protocol RTP/AVPF

RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK]

draft-ietf-avt-rtp-retransmission-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4588 10.17487/RFC4588
RFC4589 Location Types Registry H. Schulzrinne H. Tschofenig July 2006 ASCII HTML 12

This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. [STANDARDS-TRACK]

draft-ietf-geopriv-location-types-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4589
RFC4590 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck July 2006 ASCII HTML 32 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

draft-ietf-radext-digest-auth-09 RFC5090 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4590 10.17487/RFC4590
RFC4591 Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) M. Townsley G. Wilkie S. Booth S. Bryant J. Lau August 2006 ASCII HTML 14 data link protocols frame encapsulation virtual-circuit creation and deletion status change notification

The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnel Frame Relay over L2TPv3, including frame encapsulation, virtual-circuit creation and deletion, and status change notification. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-fr-07 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4591 10.17487/RFC4591
RFC4592 The Role of Wildcards in the Domain Name System E. Lewis July 2006 ASCII HTML 20 cname

This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK]

draft-ietf-dnsext-wcard-clarify-11 RFC1034 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4592 10.17487/RFC4592
RFC4593 Generic Threats to Routing Protocols A. Barbir S. Murphy Y. Yang October 2006 ASCII HTML 22 threat sources threat capability threat action threat consequences

Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. This memo provides information for the Internet community.

draft-ietf-rpsec-routing-threats-07 INFORMATIONAL INFORMATIONAL IETF rtg rpsec 10.17487/RFC4593
RFC4594 Configuration Guidelines for DiffServ Service Classes J. Babiarz K. Chan F. Baker August 2006 ASCII HTML 57 differentiated services code points traffic conditioners per-hop behaviors phb dscp active queue management aqm

This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. This memo provides information for the Internet community.

draft-ietf-tsvwg-diffserv-service-classes-02 RFC5865 RFC8622 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4594 10.17487/RFC4594
RFC4595 Use of IKEv2 in the Fibre Channel Security Association Management Protocol F. Maino D. Black July 2006 ASCII HTML 16 internet key exchange

This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the Fibre Channel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies these IKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. This memo provides information for the Internet community.

draft-maino-fcsp-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4595 10.17487/RFC4595
RFC4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension J. Rosenberg P. Kyzivat July 2006 ASCII HTML 40

This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. This memo provides information for the Internet community.

draft-ietf-sipping-callerprefs-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4596 10.17487/RFC4596
RFC4597 Conferencing Scenarios R. Even N. Ismail August 2006 ASCII HTML 17 multimedia voice video text interactive text xcon

This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. This memo provides information for the Internet community.

draft-ietf-xcon-conference-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC4597
RFC4598 Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio B. Link July 2006 ASCII HTML 17 encoded audio data multichannel audio coding format

This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. [STANDARDS-TRACK]

draft-ietf-avt-rtp-eac3-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4598
RFC4599 RFC4600 RFC4601 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas August 2006 ASCII PDF HTML 150 PIM-SM routing message type timers flags

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.

This document obsoletes RFC 2362, an Experimental version of PIM-SM. [STANDARDS-TRACK]

draft-ietf-pim-sm-v2-new-12 RFC2362 RFC7761 RFC5059 RFC5796 RFC6226 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=4601 10.17487/RFC4601
RFC4602 Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis T. Pusateri August 2006 ASCII HTML 8

This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard. This memo provides information for the Internet community.

draft-ietf-pim-proposed-req-02 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC4602
RFC4603 Additional Values for the NAS-Port-Type Attribute G. Zorn G. Weber R. Foltak July 2006 ASCII HTML 5 radius Remote Authentication Dial-In User Service

This document defines a set of values for the NAS-Port-Type RADIUS Attribute. This memo provides information for the Internet community.

draft-zorn-radius-port-type-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4603
RFC4604 Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast H. Holbrook B. Cain B. Haberman August 2006 ASCII HTML 11 ssm

The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]

draft-holbrook-idmr-igmpv3-ssm-08 RFC3376 RFC3810 PROPOSED STANDARD PROPOSED STANDARD IETF int magma 10.17487/RFC4604
RFC4605 Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") B. Fenner H. He B. Haberman H. Sandick August 2006 ASCII HTML 12

In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) membership information. [STANDARDS-TRACK]

draft-ietf-magma-igmp-proxy-06 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=4605 10.17487/RFC4605
RFC4606 Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control E. Mannie D. Papadimitriou August 2006 ASCII HTML 25

This document provides minor clarification to RFC 3946.

This document is a companion to the Generalized Multi-protocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when GMPLS signaling is used. [STANDARDS-TRACK]

draft-ietf-ccamp-rfc3946bis-01 RFC3946 RFC6344 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4606 10.17487/RFC4606
RFC4607 Source-Specific Multicast for IP H. Holbrook B. Cain August 2006 ASCII HTML 19 ipv4 ssm ipv6

IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]

draft-ietf-ssm-arch-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ssm http://www.rfc-editor.org/errata_search.php?rfc=4607 10.17487/RFC4607
RFC4608 Source-Specific Protocol Independent Multicast in 232/8 D. Meyer R. Rockell G. Shepherd August 2006 ASCII HTML 7 ip ssm

IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast destination addresses and are reserved for use by source-specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-ssm232-08 BCP0120 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4608
RFC4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements P. Savola R. Lehtonen D. Meyer October 2006 ASCII HTML 23 security threats intra-domain inter-domain any-source multicast asm source-specific multicast ssm embedded rendezvous point embedded-rp

This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only Protocol Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast (ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. This memo provides information for the Internet community.

draft-ietf-mboned-mroutesec-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC4609
RFC4610 Anycast-RP Using Protocol Independent Multicast (PIM) D. Farinacci Y. Cai August 2006 ASCII HTML 12 rendezvous point rp msdp register multicast source discovery register-stop

This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]

draft-ietf-pim-anycast-rp-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC4610
RFC4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios M. McBride J. Meylor D. Meyer August 2006 ASCII HTML 14 pim-sm protocol independent multicast sparse mode

This document describes best current practices for intra-domain and inter-domain deployment of the Multicast Source Discovery Protocol (MSDP) in conjunction with Protocol Independent Multicast Sparse Mode (PIM-SM). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mboned-msdp-deploy-06 BCP0121 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC4611
RFC4612 Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration P. Jones H. Tamura August 2006 ASCII HTML 8 itu-t recommendation t.38 sdp session description protocol

This document defines the MIME sub-type audio/t38. The usage of this MIME type, which is intended for use within Session Description Protocol (SDP), is specified within ITU-T Recommendation T.38. This memo defines a Historic Document for the Internet community.

draft-jones-avt-audio-t38-05 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4612 10.17487/RFC4612
RFC4613 Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI) P. Frojdh U. Lindgren M. Westerlund September 2006 ASCII HTML 6 dls

This document serves to register a media type for Downloadable Sounds. This memo provides information for the Internet community.

draft-westerlund-mime-dls-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4613
RFC4614 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton September 2006 ASCII HTML 33

This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This memo provides information for the Internet community.

draft-ietf-tcpm-tcp-roadmap-06 RFC7414 RFC6247 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4614
RFC4615 The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) J. Song R. Poovendran J. Lee T. Iwata August 2006 ASCII HTML 7 ipsec ip security pseudo-random function

Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced Encryption Standard (AES). This memo describes such an algorithm, called AES-CMAC-PRF-128. It supports fixed and variable key sizes. [STANDARDS-TRACK]

draft-songlee-aes-cmac-prf-128-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4615
RFC4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism K. Zeilenga Editor August 2006 ASCII HTML 11 data confidentiality

This document defines a simple clear-text user/password Simple Authentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. [STANDARDS-TRACK]

draft-ietf-sasl-plain-09 RFC2595 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4616 10.17487/RFC4616
RFC4617 A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project J. Kornijenko August 2006 ASCII HTML 8 general contractor Olimps LTD subcontractors ABC software LTD Microsoft Latvia LTD Riga Internet eXchange Technologies LTD RIX Microlink LTD

This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian National Government Integration Project (Latvian abbreviation IVIS). This memo provides information for the Internet community.

draft-kornijenko-ivis-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4617
RFC4618 Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks L. Martini E. Rosen G. Heron A. Malis September 2006 ASCII HTML 16 pw pseudowire point to point protocol pdu packet data unit

A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over a Multiprotocol Label Switching (MPLS) network without terminating the PPP/HDLC protocol. This enables service providers to offer "emulated" HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a pseudowire. [STANDARDS-TRACK]

draft-ietf-pwe3-hdlc-ppp-encap-mpls-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4618
RFC4619 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks L. Martini Editor C. Kawa Editor A. Malis Editor September 2006 ASCII HTML 19 pseudowire psn packet switched network pw

A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. [STANDARDS-TRACK]

draft-ietf-pwe3-frame-relay-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4619 10.17487/RFC4619
RFC4620 IPv6 Node Information Queries M. Crawford B. Haberman Editor August 2006 ASCII HTML 14 internet protocol version 6

This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ipngwg-icmp-name-lookups-15 EXPERIMENTAL EXPERIMENTAL IETF int ipv6 10.17487/RFC4620
RFC4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol T. Kivinen H. Tschofenig August 2006 ASCII HTML 30 internet key exchange

The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).

This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. This memo provides information for the Internet community.

draft-ietf-mobike-design-08 INFORMATIONAL INFORMATIONAL IETF sec mobike 10.17487/RFC4621
RFC4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre July 2006 ASCII HTML 23 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

draft-saintandre-xmpp-iri-04 RFC5122 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4622
RFC4623 Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly A. Malis M. Townsley August 2006 ASCII HTML 17

This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]

draft-ietf-pwe3-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4623 10.17487/RFC4623
RFC4624 Multicast Source Discovery Protocol (MSDP) MIB B. Fenner D. Thaler October 2006 ASCII HTML 32 management information base MSDP-MIB

This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mboned-msdp-mib-01 EXPERIMENTAL EXPERIMENTAL IETF ops mboned 10.17487/RFC4624
RFC4625 Fibre Channel Routing Information MIB C. DeSanti K. McCloghrie S. Kode S. Gai September 2006 ASCII HTML 22 management information base T11-FC-ROUTE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. [STANDARDS-TRACK]

draft-ietf-imss-fc-rtm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4625
RFC4626 MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol C. DeSanti V. Gaonkar K. McCloghrie S. Gai September 2006 ASCII HTML 36 management information base T11-FC-FSPF-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. [STANDARDS-TRACK]

draft-ietf-imss-fc-fspf-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4626
RFC4627 The application/json Media Type for JavaScript Object Notation (JSON) D. Crockford July 2006 ASCII HTML 10 data interchange format ECMAScript Programming Language Standard

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.

draft-crockford-jsonorg-json-04 RFC7159 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4627 10.17487/RFC4627
RFC4628 RTP Payload Format for H.263 Moving RFC 2190 to Historic Status R. Even January 2007 ASCII HTML 5 real-time transport protocol itu-t itu telecommunication standardization sector transfer

The first RFC that describes RTP payload format for ITU Telecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status. This memo provides information for the Internet community.

draft-ietf-avt-rfc2190-to-historic-06 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC4628
RFC4629 RTP Payload Format for ITU-T Rec. H.263 Video J. Ott C. Bormann G. Sullivan S. Wenger R. Even Editor January 2007 ASCII HTML 29 real-time transport protocol multicast unicast sdp session description protocol

This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.

The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.

The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 MIME media type in RFC 3555. [STANDARDS-TRACK]

draft-ietf-avt-rfc2429-bis-09 RFC2429 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4629
RFC4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile R. Housley S. Santesson August 2006 ASCII HTML 6 utf8string printablestring

This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding. The requirement for exclusive use of UTF8String after December 31, 2003 is removed. [STANDARDS-TRACK]

draft-ietf-pkix-cert-utf8-03 RFC5280 RFC3280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC4630
RFC4631 Link Management Protocol (LMP) Management Information Base (MIB) M. Dubuc T. Nadeau J. Lang E. McGinnis A. Farrel September 2006 ASCII HTML 83 lmp-mib

This document provides minor corrections to and obsoletes RFC 4327.

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). [STANDARDS-TRACK]

draft-ietf-ccamp-rfc4327bis-01 RFC4327 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4631 10.17487/RFC4631
RFC4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan V. Fuller T. Li August 2006 ASCII HTML 27 CIDR-STRA global routing state

This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-rfc1519bis-04 RFC1519 BCP0122 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=4632 10.17487/RFC4632
RFC4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists S. Hartman August 2006 ASCII HTML 7

Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. This memo defines an Experimental Protocol for the Internet community.

draft-hartman-mailinglist-experiment-03 RFC8717 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4633
RFC4634 US Secure Hash Algorithms (SHA and HMAC-SHA) D. Eastlake 3rd T. Hansen July 2006 ASCII HTML 108 fips federal information processing standard sha-224 sha-256 sha-384 sha-512

The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.

Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.

draft-eastlake-sha2-02 RFC6234 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4634 10.17487/RFC4634
RFC4635 HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers D. Eastlake 3rd August 2006 ASCII HTML 8 dns resource record rr cryptographic message authentication code cmac

Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. [STANDARDS-TRACK]

draft-ietf-dnsext-tsig-sha-06 RFC2845 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4635 10.17487/RFC4635
RFC4636 Foreign Agent Error Extension for Mobile IPv4 C. Perkins October 2006 ASCII HTML 6 internet protocol

This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. [STANDARDS-TRACK]

draft-ietf-mip4-faerr-02 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4636 10.17487/RFC4636
RFC4637 RFC4638 Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) P. Arberg D. Kourkouzelis M. Duckett T. Anschutz J. Moisand September 2006 ASCII HTML 9

The Point-to-Point Protocol over Ethernet (PPPoE), as described in RFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. This memo provides information for the Internet community.

draft-arberg-pppoe-mtu-gt1492-03 INFORMATIONAL INFORMATIONAL IETF int pppext 10.17487/RFC4638
RFC4639 Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems R. Woundy K. Marez December 2006 ASCII HTML 88 snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of Data Over Cable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.

This memo obsoletes RFC 2669. [STANDARDS-TRACK]

draft-ietf-ipcdn-device-mibv2-11 RFC2669 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4639
RFC4640 Problem Statement for bootstrapping Mobile IPv6 (MIPv6) A. Patel Editor G. Giaretta Editor September 2006 ASCII HTML 22 internet protocol version 6 mobile node

A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6 (MIPv6) and various potential deployment scenarios for mobile node bootstrapping. This memo provides information for the Internet community.

draft-ietf-mip6-bootstrap-ps-05 INFORMATIONAL INFORMATIONAL IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4640 10.17487/RFC4640
RFC4641 DNSSEC Operational Practices O. Kolkman R. Gieben September 2006 ASCII HTML 35 dns domain name space security extensions zone administrator DNS-SOC cryptology resource records rrs

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.

The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.

This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.

draft-ietf-dnsop-dnssec-operational-practices-08 RFC2541 RFC6781 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=4641 10.17487/RFC4641
RFC4642 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) K. Murchison J. Vinocur C. Newman October 2006 ASCII HTML 14 encryption single link confidentiality

This memo defines an extension to the Network News Transfer Protocol (NNTP) that allows an NNTP client and server to use Transport Layer Security (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. [STANDARDS-TRACK]

draft-ietf-nntpext-tls-nntp-09 RFC8143 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4642 10.17487/RFC4642
RFC4643 Network News Transfer Protocol (NNTP) Extension for Authentication J. Vinocur K. Murchison October 2006 ASCII HTML 24 authinfo user/pass authinfo simple authinfo generic sasl simple authentication and security layer

This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.

This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. [STANDARDS-TRACK]

draft-ietf-nntpext-authinfo-10 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4643 10.17487/RFC4643
RFC4644 Network News Transfer Protocol (NNTP) Extension for Streaming Feeds J. Vinocur K. Murchison October 2006 ASCII HTML 14 check takethis mode stream

This memo defines an extension to the Network News Transfer Protocol (NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.

This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]

draft-ietf-nntpext-streaming-06 RFC2980 PROPOSED STANDARD PROPOSED STANDARD IETF app nntpext http://www.rfc-editor.org/errata_search.php?rfc=4644 10.17487/RFC4644
RFC4645 Initial Language Subtag Registry D. Ewell September 2006 ASCII HTML 7 iana

This memo defined the initial contents of the IANA Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion. This memo provides information for the Internet community.

draft-ietf-ltru-initial-06 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC4645
RFC4646 Tags for Identifying Languages A. Phillips M. Davis September 2006 ASCII HTML 59 Lang-Tag

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ltru-registry-14 RFC3066 RFC5646 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru http://www.rfc-editor.org/errata_search.php?rfc=4646 10.17487/RFC4646
RFC4647 Matching of Language Tags A. Phillips M. Davis September 2006 ASCII HTML 20 Lang-Tag

This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences. It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 4646, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ltru-matching-15 RFC3066 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru 10.17487/RFC4647
RFC4648 The Base16, Base32, and Base64 Data Encodings S. Josefsson October 2006 ASCII HTML 18 schemes data line-feeds alphabets base encoding hex

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]

draft-josefsson-rfc3548bis-04 RFC3548 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4648 10.17487/RFC4648
RFC4649 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option B. Volz August 2006 ASCII HTML 6

This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-remoteid-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4649
RFC4650 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) M. Euchner September 2006 ASCII HTML 27 Multicast security MIKEY key management Diffie-Hellman key agreement HMAC

This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocol MIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. [STANDARDS-TRACK]

draft-ietf-msec-mikey-dhhmac-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=4650 10.17487/RFC4650
RFC4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization C. Vogt J. Arkko February 2007 ASCII HTML 31 Mobile IPv6 Route Optimization Enhancement Mobility Handoff IP Address Tests Protected Tunnels Optimistic Behavior Proactive IP Address Tests Concurrent Care-of Address Tests Diverted Routing Credit-Based Authorization Heuristic Monitoring Crypto-Based Identifiers Pre-Configuration Semi-Permanent Security Associations Delegation Mobile Networks Location Privacy

This document describes and evaluates strategies to enhance Mobile IPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo provides information for the Internet community.

draft-irtf-mobopts-ro-enhancements-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4651
RFC4652 Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements D. Papadimitriou Editor L.Ong J. Sadler S. Shew D. Ward October 2006 ASCII HTML 22 gmpls generalized multiprotocol label switching otn optical transport networks sonet sdh synchronous optical network synchronous digital hierarchy itu-t

The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Networks (OTNs).

This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-ason-routing-eval-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4652
RFC4653 Improving the Robustness of TCP to Non-Congestion Events S. Bhandarkar A. L. N. Reddy M. Allman E. Blanton August 2006 ASCII HTML 18 ncr non-congestion robustness transmission control protocol

This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-tcp-dcr-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=4653 10.17487/RFC4653
RFC4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification J. Widmer M. Handley August 2006 ASCII HTML 32 streaming media multicase ip internet protocol

This document specifies TCP-Friendly Multicast Congestion Control (TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions. TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rmt-bb-tfmcc-07 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=4654 10.17487/RFC4654
RFC4655 A Path Computation Element (PCE)-Based Architecture A. Farrel J.-P. Vasseur J. Ash August 2006 ASCII HTML 40 traffic engineering

Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.

This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.

draft-ietf-pce-architecture-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4655
RFC4656 A One-way Active Measurement Protocol (OWAMP) S. Shalunov B. Teitelbaum A. Karp J. Boote M. Zekauskas September 2006 ASCII HTML 56 unidirectional characteristics one-way gps cdma

The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements. [STANDARDS-TRACK]

draft-ietf-ippm-owdp-16 RFC7717 RFC7718 RFC8545 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4656
RFC4657 Path Computation Element (PCE) Communication Protocol Generic Requirements J. Ash Editor J.L. Le Roux Editor September 2006 ASCII HTML 21 pce architecture pcc path computation client

The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community.

draft-ietf-pce-comm-protocol-gen-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4657
RFC4658 RFC4659 BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN J. De Clercq D. Ooms M. Carugi F. Le Faucheur September 2006 ASCII HTML 18 service provider border gateway protocol multiprotocol label switching

This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".

This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK]

draft-ietf-l3vpn-bgp-ipv6-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4659 10.17487/RFC4659
RFC4660 Functional Description of Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII HTML 31 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.

This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. [STANDARDS-TRACK]

draft-ietf-simple-event-filter-funct-05 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4660 10.17487/RFC4660
RFC4661 An Extensible Markup Language (XML)-Based Format for Event Notification Filtering H. Khartabil E. Leppanen M. Lonnfors J. Costa-Requena September 2006 ASCII HTML 24 event state subscription presence filter criteria

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. [STANDARDS-TRACK]

draft-ietf-simple-filter-format-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4661 10.17487/RFC4661
RFC4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists A. B. Roach B. Campbell J. Rosenberg August 2006 ASCII HTML 39

This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS-TRACK]

draft-ietf-simple-event-list-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=4662 10.17487/RFC4662
RFC4663 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG D. Harrington September 2006 ASCII HTML 22 management information base

This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage. This memo provides information for the Internet community.

draft-harrington-8021-mib-transition-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4663
RFC4664 Framework for Layer 2 Virtual Private Networks (L2VPNs) L. Andersson Editor E. Rosen Editor September 2006 ASCII HTML 44

This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community.

draft-ietf-l2vpn-l2-framework-05 INFORMATIONAL INFORMATIONAL IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4664 10.17487/RFC4664
RFC4665 Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks W. Augustyn Editor Y. Serbest Editor September 2006 ASCII HTML 32 l2vpn ppvpn virtual private wire service vpws virtual private lan service vpls

This document provides requirements for Layer 2 Provider-Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives. This memo provides information for the Internet community.

draft-ietf-l2vpn-requirements-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC4665
RFC4666 Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) K. Morneault Editor J. Pastor-Balbas Editor September 2006 ASCII HTML 124 mtp isup sccp sctp stream control tranmission protocol mgc media gateway protocol st signalling gateway

This memo defines a protocol for supporting the transport of any SS7 MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database, or between two IP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. This document obsoletes RFC 3332. [STANDARDS-TRACK]

draft-ietf-sigtran-rfc3332bis-06 RFC3332 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran http://www.rfc-editor.org/errata_search.php?rfc=4666 10.17487/RFC4666
RFC4667 Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) W. Luo September 2006 ASCII HTML 15 L2VPN L2TP L2TPv3 pseudowire forwarder

The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types of L2VPNs in a unified fashion. [STANDARDS-TRACK]

draft-ietf-l2tpext-l2vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4667
RFC4668 RADIUS Authentication Client MIB for IPv6 D. Nelson August 2006 ASCII HTML 24 management information base security remote access dialin user service RADIUS-AUTH-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients.

This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

draft-ietf-radext-rfc2618bis-04 RFC2618 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4668 10.17487/RFC4668
RFC4669 RADIUS Authentication Server MIB for IPv6 D. Nelson August 2006 ASCII HTML 25 management information base security remote access dialin user service RADIUS-AUTH-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers.

This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK]

draft-ietf-radext-rfc2619bis-04 RFC2619 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4669 10.17487/RFC4669
RFC4670 RADIUS Accounting Client MIB for IPv6 D. Nelson August 2006 ASCII HTML 23 management information base security remote access dialin user service RADIUS-ACC-CLIENT-MIB

This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients.

This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

draft-ietf-radext-rfc2620bis-04 RFC2620 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4670 10.17487/RFC4670
RFC4671 RADIUS Accounting Server MIB for IPv6 D. Nelson August 2006 ASCII HTML 24 management information base security remote access dialin user service RADIUS-ACC-SERVER-MIB

This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting servers.

This memo obsoletes RFC 2621 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2621 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community.

draft-ietf-radext-rfc2621bis-04 RFC2621 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4671 10.17487/RFC4671
RFC4672 RADIUS Dynamic Authorization Client MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII HTML 24 remote authentication dial-in user service dac dynamic authorization client RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

draft-ietf-radext-dynauth-client-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4672 10.17487/RFC4672
RFC4673 RADIUS Dynamic Authorization Server MIB S. De Cnodder N. Jonnala M. Chiba September 2006 ASCII HTML 24 management information base remote authentication dial-in user service RADIUS-DYNAUTH-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial-In User Service (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. This memo provides information for the Internet community.

draft-ietf-radext-dynauth-server-mib-06 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4673 10.17487/RFC4673
RFC4674 Requirements for Path Computation Element (PCE) Discovery J.L. Le Roux Editor October 2006 ASCII HTML 19 path computation client pcc

This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. This memo provides information for the Internet community.

draft-ietf-pce-discovery-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4674
RFC4675 RADIUS Attributes for Virtual LAN and Priority Support P. Congdon M. Sanchez B. Aboba September 2006 ASCII HTML 15 remote authentication dial-in user service local area network

This document proposes additional Remote Authentication Dial-In User Service (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS or Diameter. [STANDARDS-TRACK]

draft-ietf-radext-vlan-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=4675 10.17487/RFC4675
RFC4676 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne October 2006 ASCII HTML 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

draft-ietf-geopriv-dhcp-civil-09 RFC4776 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4676 10.17487/RFC4676
RFC4677 The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force P. Hoffman S. Harris September 2006 ASCII HTML 50 meeting

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. This memo provides information for the Internet community.

draft-hoffman-taobis-08 RFC3160 RFC6722 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4677 10.17487/RFC4677
RFC4678 Server/Application State Protocol v1 A. Bivens September 2006 ASCII HTML 48 sasp server/application state protocol

Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. The Server/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. This memo provides information for the Internet community.

draft-bivens-sasp-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4678 10.17487/RFC4678
RFC4679 DSL Forum Vendor-Specific RADIUS Attributes V. Mammoliti G. Zorn P. Arberg R. Rennison September 2006 ASCII HTML 25 remote authentication dial-in user service vsa dsl digital subscriber line

This document describes the set of Remote Authentication Dial-In User Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL Forum.

These attributes are designed to transport Digital Subscriber Line (DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. This memo provides information for the Internet community.

draft-mammoliti-radius-dsl-vsa-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4679 10.17487/RFC4679
RFC4680 TLS Handshake Message for Supplemental Data S. Santesson October 2006 ASCII HTML 9 transport layer security

This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both the TLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. [STANDARDS-TRACK]

draft-santesson-tls-supp-02 RFC4346 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4680
RFC4681 TLS User Mapping Extension S. Santesson A. Medvinsky J. Ball October 2006 ASCII HTML 11 transport layer security handshake message upndomainhint

This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. [STANDARDS-TRACK]

draft-santesson-tls-ume-07 RFC4346 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4681
RFC4682 Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices E. Nechamkin J-F. Mule December 2006 ASCII HTML 60 mib snmp simple network management protocol PKTC-IETF-MTA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

draft-ietf-ipcdn-pktc-mtamib-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC4682
RFC4683 Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) J. Park J. Lee H.. Lee S. Park T. Polk October 2006 ASCII HTML 20 subjectaltname privacy-sensitive identifiers pepsi

This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.

The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. [STANDARDS-TRACK]

draft-ietf-pkix-sim-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4683 10.17487/RFC4683
RFC4684 Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) P. Marques R. Bonica L. Fang L. Martini R. Raszuk K. Patel J. Guichard November 2006 ASCII HTML 14 mp-bgp bgp speakers route target

This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. [STANDARDS-TRACK]

draft-ietf-l3vpn-rt-constrain-02 RFC4364 PROPOSED STANDARD PROPOSED STANDARD IETF int l3vpn http://www.rfc-editor.org/errata_search.php?rfc=4684 10.17487/RFC4684
RFC4685 Atom Threading Extensions J. Snell September 2006 ASCII HTML 12 atom syndication format extension threading syndication

This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. [STANDARDS-TRACK]

draft-snell-atompub-feed-thread-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4685
RFC4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) J. Fenton September 2006 ASCII HTML 29 email attack authentication signature ssp

This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. This memo provides information for the Internet community.

draft-ietf-dkim-threats-03 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC4686
RFC4687 Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks S. Yasukawa A. Farrel D. King T. Nadeau September 2006 ASCII HTML 14 multiprotocol label switching pwmp lsp p2mp mpls lsp

Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.

For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.

This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. This memo provides information for the Internet community.

draft-ietf-mpls-p2mp-oam-reqs-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4687
RFC4688 A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D S. Rushing October 2006 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D. This memo provides information for the Internet community.

draft-rushing-s1000d-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4688
RFC4689 Terminology for Benchmarking Network-layer Traffic Control Mechanisms S. Poretsky J. Perser S. Erramilli S. Khurana October 2006 ASCII HTML 34 packet classification

This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number. This memo provides information for the Internet community.

draft-ietf-bmwg-dsmterm-13 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4689
RFC4690 Review and Recommendations for Internationalized Domain Names (IDNs) J. Klensin P. Faltstrom C. Karp IAB September 2006 ASCII HTML 37 dns domain namespace idna internationalizing domain names in applications

This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.

draft-iab-idn-nextsteps-06 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4690 10.17487/RFC4690
RFC4691 Guidelines for Acting as an IETF Liaison to Another Organization L. Andersson Editor October 2006 ASCII HTML 14 internet engineering task force sdo standards development organization consortium industrial forum

Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. This memo provides information for the Internet community.

draft-iab-liaison-guidelines-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4691
RFC4692 Considerations on the IPv6 Host Density Metric G. Huston October 2006 ASCII HTML 17 internet protocol version 6 ipv6 unicast address blocks

This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches. This memo provides information for the Internet community.

draft-huston-hd-metric-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4692
RFC4693 IETF Operational Notes H. Alvestrand October 2006 ASCII HTML 10 ION

This document describes a new document series intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than Internet-Drafts, and with more clear handling procedures than a random Web page.

It proposes to establish this series as an RFC 3933 process experiment. This memo defines an Experimental Protocol for the Internet community.

draft-alvestrand-ipod-03 RFC6393 HISTORIC EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4693
RFC4694 Number Portability Parameters for the "tel" URI J. Yu October 2006 ASCII HTML 15 uniform resource identifier np

This document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. [STANDARDS-TRACK]

draft-ietf-iptel-tel-np-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4694
RFC4695 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII HTML 169 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4-generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtp-midi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. [STANDARDS-TRACK]

draft-ietf-avt-rtp-midi-format-15 RFC6295 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4695 10.17487/RFC4695
RFC4696 An Implementation Guide for RTP MIDI J. Lazzaro J. Wawrzynek November 2006 ASCII HTML 38 checkpoint packet checkpoint history guard packets jitter keep-alive packets MIDI musical telepresence network musical performance NMP receiving algorithm recovery journal recovery journal receiving structure recovery journal sending structure RTP RTP MIDI queuing MIDI sending algorithm sending MIDI telepresence

This memo offers non-normative implementation guidance for the Real-time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. [STANDARDS-TRACK]

draft-ietf-avt-rtp-midi-guidelines-15 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4696 10.17487/RFC4696
RFC4697 Observed DNS Resolution Misbehavior M. Larson P. Barber October 2006 ASCII HTML 18 domain name system tld top level domain

This memo describes DNS iterative resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. We offer implementation advice to iterative resolver developers to alleviate these unnecessary queries. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-bad-dns-res-06 BCP0123 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC4697
RFC4698 IRIS: An Address Registry (areg) Type for the Internet Registry Information Service E. Gunduz A. Newton S. Kerr October 2006 ASCII HTML 48 ip address autonomous system number internet protocol address

This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. [STANDARDS-TRACK]

draft-ietf-crisp-iris-areg-15 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4698 10.17487/RFC4698
RFC4699 RFC4700 RFC4701 A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) M. Stapp T. Lemon A. Gustafsson October 2006 ASCII HTML 12 dns fqdn fully qualified domain name

It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct Resource Record (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. [STANDARDS-TRACK]

draft-ietf-dnsext-dhcid-rr-13 RFC5494 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4701 10.17487/RFC4701
RFC4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option M. Stapp B. Volz Y. Rekhter October 2006 ASCII HTML 17 dhcpv4 dns rr

This document describes a Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that can be used to exchange information about a DHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. [STANDARDS-TRACK]

draft-ietf-dhc-fqdn-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4702
RFC4703 Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients M. Stapp B. Volz October 2006 ASCII HTML 13 dynamic assignment dns dhcid dns rr

The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names (FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. [STANDARDS-TRACK]

draft-ietf-dhc-ddns-resolution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4703
RFC4704 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option B. Volz October 2006 ASCII HTML 15 dns rr

This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-fqdn-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4704
RFC4705 GigaBeam High-Speed Radio Link Encryption R. Housley A. Corry October 2006 ASCII HTML 15 key management wifiber radio link

This document describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. This memo provides information for the Internet community.

draft-housley-gigabeam-radio-link-encrypt-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4705 10.17487/RFC4705
RFC4706 Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) M. Morgenstern M. Dodge S. Baillie U. Bonollo November 2006 ASCII HTML 167 mib management information base adsl2+ ADSL2-LINE-TC-MIB ADSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their variants. [STANDARDS-TRACK]

draft-ietf-adslmib-adsl2-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC4706
RFC4707 Netnews Administration System (NAS) P. Grau V. Heinau H. Schlichting R. Schuettler October 2006 ASCII HTML 49 news servers news administrator news reader

The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.

The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.

NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible. Furthermore, NAS is able to reflect the somewhat chaotic structure of Usenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS-compliant software. This memo defines an Experimental Protocol for the Internet community.

draft-dfncis-netnews-admin-sys-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4707 10.17487/RFC4707
RFC4708 CellML Media Type A. Miller October 2006 ASCII HTML 7 media format mathematical model mathematical modelling mathematical modeling content MathML markup languages bioengineering biology

This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language. This memo provides information for the Internet community.

draft-miller-media-type-cellml-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4708
RFC4709 Mounting Web Distributed Authoring and Versioning (WebDAV) Servers J. Reschke October 2006 ASCII HTML 15 drag-and-drop

In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of a Web Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.

This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. This memo provides information for the Internet community.

draft-reschke-webdav-mount-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4709
RFC4710 Real-time Application Quality-of-Service Monitoring (RAQMON) Framework A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII HTML 36 internet protocol end-devices qos quality of service snmp simple network management protocol

There is a need to monitor end-devices such as IP phones, pagers, Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring (RMON) family of specifications to allow real-time quality-of-service (QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. [STANDARDS-TRACK]

draft-ietf-rmonmib-raqmon-framework-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4710
RFC4711 Real-time Application Quality-of-Service Monitoring (RAQMON) MIB A. Siddiqui D. Romascanu E. Golovinsky October 2006 ASCII HTML 38 management information base remote monitoring mib qos RAQMON-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB, RFC 2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. [STANDARDS-TRACK]

draft-ietf-rmonmib-raqmon-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4711
RFC4712 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) A. Siddiqui D. Romascanu E. Golovinsky M. Rahman,Y. Kim October 2006 ASCII HTML 48 mib management information base snmp simple network management protocol rds raqmon data source qos RAQMON-RDS-MIB

This memo specifies two transport mappings of the \%Real-Time Application Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the Simple Network Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). [STANDARDS-TRACK]

draft-ietf-rmonmib-raqmon-pdu-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops rmonmib 10.17487/RFC4712
RFC4713 Registration and Administration Recommendations for Chinese Domain Names X. Lee W. Mao E. Chen N. Hsu J. Klensin October 2006 ASCII HTML 9 cdn sc simplified chinese tc traditional chinese

Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms. The equivalence between Simplified Chinese (SC) and Traditional Chinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese. This memo provides information for the Internet community.

draft-xdlee-idn-cdnadmin-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4713
RFC4714 Requirements for IETF Technical Publication Service A. Mankin S. Hayes October 2006 ASCII HTML 24 internet engineering task force

The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. This memo provides information for the Internet community.

draft-mankin-pub-req-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4714
RFC4715 The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI M. Munakata S. Schubert T. Ohba November 2006 ASCII HTML 14 uniform resource identifier isup isdn user part

Without a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. This memo provides information for the Internet community.

draft-munakata-iptel-isub-type-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4715
RFC4716 The Secure Shell (SSH) Public Key File Format J. Galbraith R. Thayer November 2006 ASCII HTML 10

This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations.

In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.

draft-ietf-secsh-publickeyfile-13 INFORMATIONAL INFORMATIONAL IETF sec secsh 10.17487/RFC4716
RFC4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks L. Martini J. Jayakumar M. Bocci N. El-Aawar J. Brayley G. Koleyni December 2006 ASCII HTML 40 pw pseudowire multiprotocol label switching

An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry ATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service. [STANDARDS-TRACK]

draft-ietf-pwe3-atm-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4717 10.17487/RFC4717
RFC4718 IKEv2 Clarifications and Implementation Guidelines P. Eronen P. Hoffman October 2006 ASCII HTML 58 internet key exchange

This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. This memo provides information for the Internet community.

draft-eronen-ipsec-ikev2-clarifications-09 RFC5996 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4718 10.17487/RFC4718
RFC4719 Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) R. Aggarwal Editor M. Townsley Editor M. Dos Santos Editor November 2006 ASCII HTML 14 port-to-port vlan

This document describes the transport of Ethernet frames over the Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport of Ethernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. [STANDARDS-TRACK]

draft-ietf-l2tpext-pwe3-ethernet-09 RFC5641 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext http://www.rfc-editor.org/errata_search.php?rfc=4719 10.17487/RFC4719
RFC4720 Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention A. Malis D. Allan N. Del Regno November 2006 ASCII HTML 9 fcs

This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. [STANDARDS-TRACK]

draft-ietf-pwe3-fcs-retention-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4720
RFC4721 Mobile IPv4 Challenge/Response Extensions (Revised) C. Perkins P. Calhoun J. Bharatia January 2007 ASCII HTML 26 chap

Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as Challenge Handshake Authentication Protocol (CHAP)) for authenticating portable computer devices.

In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.

Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication, Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. [STANDARDS-TRACK]

draft-ietf-mip4-rfc3012bis-05 RFC3012 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4721 10.17487/RFC4721
RFC4722 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer November 2006 ASCII HTML 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

draft-vandyke-mscml-09 RFC5022 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4722
RFC4723 Registration of Media Type audio/mobile-xmf T. Kosonen T. White December 2006 ASCII HTML 8 mma midi manufacturers association association of musical electronices industry amei MIDI Musical Instrument Digital Interface

The MIDI Manufacturers Association (MMA) and the Association of Musical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf. This memo provides information for the Internet community.

draft-kosonen-mobile-xmf-mediatype-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4723
RFC4724 Graceful Restart Mechanism for BGP S. Sangli E. Chen R. Fernando J. Scudder Y. Rekhter January 2007 ASCII HTML 15 border gateway protocol end-of-rib bgp restart

This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.

The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). [STANDARDS-TRACK]

draft-ietf-idr-restart-13 RFC8538 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4724 10.17487/RFC4724
RFC4725 ENUM Validation Architecture A. Mayrhofer B. Hoeneisen November 2006 ASCII HTML 17 E.164 Registry Registrar Registrant Assignee

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. This memo provides information for the Internet community.

draft-ietf-enum-validation-arch-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC4725
RFC4726 A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering A. Farrel J.-P. Vasseur A. Ayyangar November 2006 ASCII HTML 22 mpls mpls-te te lsp label switched path

This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.

For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). This memo provides information for the Internet community.

draft-ietf-ccamp-inter-domain-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4726
RFC4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers B. Fenner November 2006 ASCII HTML 11

When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]

draft-fenner-iana-exp-2780-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4727
RFC4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 D. Johnson Y. Hu D. Maltz February 2007 ASCII HTML 107 route discovery route maintenance

The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and "Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network. All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness. Other advantages of the DSR protocol include easily guaranteed loop-free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-manet-dsr-10 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=4728 10.17487/RFC4728
RFC4729 A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum M. Abel November 2006 ASCII HTML 7 forum technical committee

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) resources published by the Near Field Communication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFC Forum Technical Committee. This memo provides information for the Internet community.

draft-abel-nfc-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4729
RFC4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) E. Burger M. Dolly November 2006 ASCII HTML 56 ua user agent dtmf dual tone multi-frequency

This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). [STANDARDS-TRACK]

draft-ietf-sipping-kpml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=4730 10.17487/RFC4730
RFC4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned A. Melnikov D. Cridland November 2006 ASCII HTML 6 uid search uid

This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK]

draft-melnikov-imap-search-ret-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4731
RFC4732 Internet Denial-of-Service Considerations M. Handley Editor E. Rescorla Editor IAB December 2006 ASCII HTML 38 dos

This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. This memo provides information for the Internet community.

draft-iab-dos-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4732
RFC4733 RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII HTML 49 real-time application protocol DTMF dual-tone multifrequency

This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.

This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.

This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. [STANDARDS-TRACK]

draft-ietf-avt-rfc2833bis-15 RFC2833 RFC4734 RFC5244 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4733 10.17487/RFC4733
RFC4734 Definition of Events for Modem, Fax, and Text Telephony Signals H. Schulzrinne T. Taylor December 2006 ASCII HTML 47 real-time application protocol DTMF dual-tone multifrequency

This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [STANDARDS-TRACK]

draft-ietf-avt-rfc2833bisdata-08 RFC2833 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4734
RFC4735 Example Media Types for Use in Documentation T. Taylor October 2006 ASCII HTML 6 media type example

This document is registration for the 'example' media type and 'example' subtypes within the standards tree. The 'example/*' and '*/example' media types are defined for documentation purposes only. [STANDARDS-TRACK]

draft-taylor-types-example-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4735
RFC4736 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) JP. Vasseur Editor Y. Ikejiri R. Zhang November 2006 ASCII HTML 14 rsvp-te te lsp path

This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community.

draft-ietf-ccamp-loose-path-reopt-02 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4736
RFC4737 Packet Reordering Metrics A. Morton L. Ciavattone G. Ramachandran S. Shalunov J. Perser November 2006 ASCII HTML 45 ippm

This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included. An appendix gives extended definitions for evaluating order with packet fragmentation. [STANDARDS-TRACK]

draft-ietf-ippm-reordering-13 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC4737
RFC4738 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) D. Ignjatic L. Dondeti F. Audet P. Lin November 2006 ASCII HTML 19 MIKEY SRTP key management group key distribution RSA-R

The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally a Diffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder's ID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode. [STANDARDS-TRACK]

draft-ietf-msec-mikey-rsa-r-07 RFC3830 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC4738
RFC4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol P. Eronen J. Korhonen November 2006 ASCII HTML 11

The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. This memo defines an Experimental Protocol for the Internet community.

draft-eronen-ipsec-ikev2-multiple-auth-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4739
RFC4740 Diameter Session Initiation Protocol (SIP) Application M. Garcia-Martin Editor M. Belinchon M. Pallares-Lopez C. Canales-Valenzuela K. Tammi November 2006 ASCII HTML 72 authentication authorization diameter client

This document specifies the Diameter Session Initiation Protocol (SIP) application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. [STANDARDS-TRACK]

draft-ietf-aaa-diameter-sip-app-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops aaa http://www.rfc-editor.org/errata_search.php?rfc=4740 10.17487/RFC4740
RFC4741 NETCONF Configuration Protocol R. Enns Editor December 2006 ASCII HTML 95 network configuration protocol network device xml extensible markup language rpc remote procedure call

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS-TRACK]

draft-ietf-netconf-prot-12 RFC6241 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4741 10.17487/RFC4741
RFC4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH) M. Wasserman T. Goddard December 2006 ASCII HTML 10 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. [STANDARDS-TRACK]

draft-ietf-netconf-ssh-06 RFC6242 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=4742 10.17487/RFC4742
RFC4743 Using NETCONF over the Simple Object Access Protocol (SOAP) T. Goddard December 2006 ASCII HTML 20 NETCONF XMLCONF SOAP device managment XML Extensible Markup Language

The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. Web Services is one such environment and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the reuse of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over Blocks Exchange Extensible Protocol (BEEP) bindings for NETCONF. [STANDARDS-TRACK]

draft-ietf-netconf-soap-08 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4743
RFC4744 Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) E. Lear K. Crozier December 2006 ASCII HTML 10 XML Configuration Network Management Extensible Markup Language

This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP). [STANDARDS-TRACK]

draft-ietf-netconf-beep-10 HISTORIC PROPOSED STANDARD IETF ops netconf 10.17487/RFC4744
RFC4745 Common Policy: A Document Format for Expressing Privacy Preferences H. Schulzrinne H. Tschofenig J. Morris J. Cuellar J. Polk J. Rosenberg February 2007 ASCII HTML 32 rules conditions permissions

This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. [STANDARDS-TRACK]

draft-ietf-geopriv-common-policy-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=4745 10.17487/RFC4745
RFC4746 Extensible Authentication Protocol (EAP) Password Authenticated Exchange T. Clancy W. Arbaugh November 2006 ASCII HTML 30 EAP-PAX password authenticated exchange key exchange

This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange. This memo provides information for the Internet community.

draft-clancy-eap-pax-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4746 10.17487/RFC4746
RFC4747 The Virtual Fabrics MIB S. Kipp G. Ramkumar K. McCloghrie November 2006 ASCII HTML 20 management information base T11-FC-VIRTUAL-FABRIC-MIB fibre channel network virtual fabric

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Virtual Fabrics function. [STANDARDS-TRACK]

draft-ietf-imss-fc-vf-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4747 10.17487/RFC4747
RFC4748 RFC 3978 Update to Recognize the IETF Trust S. Bradner Editor October 2006 ASCII HTML 4 ipr intellectual property rights copyright

This document updates RFC 3978 "IETF Rights in Contributions" to recognize that the IETF Trust is now the proper custodian of all IETF-related intellectual property rights.

This document does not constrain how the IETF Trust exercises those rights. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-ietf-trust-update-03 RFC5378 RFC3978 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4748
RFC4749 RTP Payload Format for the G.729.1 Audio Codec A. Sollaud October 2006 ASCII HTML 14 real-time transport protocol itu-t international telecommunication union

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g729-scal-wb-ext-07 RFC5459 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4749
RFC4750 OSPF Version 2 Management Information Base D. Joyal Editor P. Galecki Editor S. Giacalone Editor R. Coltun F. Baker December 2006 ASCII HTML 121 OSPF-MIB Open Shortest Path First SPF MIB routing network management mib OSPF-MIB OSPF-TRAP-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family.

This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B. [STANDARDS-TRACK]

draft-ietf-ospf-mib-update-11 RFC1850 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4750 10.17487/RFC4750
RFC4751 RFC4752 The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism A. Melnikov Editor November 2006 ASCII HTML 10 SASL encryption protocol specific

The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface (GSS-API) Kerberos V5 in the SASL.

This document replaces Section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. [STANDARDS-TRACK]

draft-ietf-sasl-gssapi-08 RFC2222 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=4752 10.17487/RFC4752
RFC4753 ECP Groups For IKE and IKEv2 D. Fu J. Solinas January 2007 ASCII HTML 16 elliptic curve Diffie-Hellman suite b nist curve

This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This memo provides information for the Internet community.

draft-ietf-ipsec-ike-ecp-groups-03 RFC5903 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4753 10.17487/RFC4753
RFC4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) D. Fu J. Solinas January 2007 ASCII HTML 15 suite b

This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK]

draft-ietf-ipsec-ike-auth-ecdsa-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4754 10.17487/RFC4754
RFC4755 IP over InfiniBand: Connected Mode V. Kashyap December 2006 ASCII HTML 13

This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. [STANDARDS-TRACK]

draft-ietf-ipoib-connected-mode-03 PROPOSED STANDARD PROPOSED STANDARD IETF int ipoib 10.17487/RFC4755
RFC4756 Forward Error Correction Grouping Semantics in Session Description Protocol A. Li November 2006 ASCII HTML 6 fec sdp media lines

This document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. [STANDARDS-TRACK]

draft-ietf-mmusic-fec-grouping-05 RFC5956 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4756
RFC4757 The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows K. Jaganathan L. Zhu J. Brezak December 2006 ASCII HTML 18 md5 hmac

The Microsoft Windows 2000 implementation of Kerberos introduces a new encryption type based on the RC4 encryption algorithm and using an MD5 HMAC for checksum. This is offered as an alternative to using the existing DES-based encryption types.

The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. This memo provides information for the Internet community.

draft-jaganathan-rc4-hmac-03 RFC6649 HISTORIC INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4757 10.17487/RFC4757
RFC4758 Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1 M. Nystroem November 2006 ASCII HTML 54 rsa laboratories one-time password specifications otps

This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.

CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. This memo provides information for the Internet community.

draft-nystrom-ct-kip-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4758 10.17487/RFC4758
RFC4759 The ENUM Dip Indicator Parameter for the "tel" URI R. Stastny R. Shockey L. Conroy December 2006 ASCII HTML 8 DNS E.164 telephone number

This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. [STANDARDS-TRACK]

draft-ietf-iptel-tel-enumdi-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4759
RFC4760 Multiprotocol Extensions for BGP-4 T. Bates R. Chandra D. Katz Y. Rekhter January 2007 ASCII HTML 12 MEXT-BGP4 border gateway protocol network layer protocols

This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]

draft-ietf-idr-rfc2858bis-10 RFC2858 RFC7606 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=4760 10.17487/RFC4760
RFC4761 Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling K. Kompella Editor Y. Rekhter Editor January 2007 ASCII HTML 28 border gateway protocol transparent lan service virtual private switched network service provider

Virtual Private LAN Service (VPLS), also known as Transparent LAN Service and Virtual Private Switched Network service, is a useful Service Provider offering. The service offers a Layer 2 Virtual Private Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.

This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. [STANDARDS-TRACK]

draft-ietf-l2vpn-vpls-bgp-08 RFC5462 RFC8395 RFC8614 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn 10.17487/RFC4761
RFC4762 Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling M. Lasserre Editor V. Kompella Editor January 2007 ASCII HTML 31 land area network transparent lan service

This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS). A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.

This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extending RFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. [STANDARDS-TRACK]

draft-ietf-l2vpn-vpls-ldp-09 PROPOSED STANDARD PROPOSED STANDARD IETF int l2vpn http://www.rfc-editor.org/errata_search.php?rfc=4762 10.17487/RFC4762
RFC4763 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) M. Vanderveen H. Soliman November 2006 ASCII HTML 46 IEEE 802.11i user anonymity

This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748. The specification has passed Designated Expert review for this IANA assignment. This memo provides information for the Internet community.

draft-vanderveen-eap-sake-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4763 10.17487/RFC4763
RFC4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method F. Bersani H. Tschofenig January 2007 ASCII HTML 64 pre-shared key

This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo defines an Experimental Protocol for the Internet community.

draft-bersani-eap-psk-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4764
RFC4765 The Intrusion Detection Message Exchange Format (IDMEF) H. Debar D. Curry B. Feinstein March 2007 ASCII HTML 157 intrusion detection security secure exchange intrusion IDS XML

The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.

This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-idwg-idmef-xml-16 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4765
RFC4766 Intrusion Detection Message Exchange Requirements M. Wood M. Erlinger March 2007 ASCII HTML 25 idmef idwg intrusion detection exchange format

The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. This memo provides information for the Internet community.

draft-ietf-idwg-requirements-10 INFORMATIONAL INFORMATIONAL IETF sec idwg 10.17487/RFC4766
RFC4767 The Intrusion Detection Exchange Protocol (IDXP) B. Feinstein G. Matthews March 2007 ASCII HTML 28 intrusion intrusion detection beep security ids security protocol secure protocol secure exchange idmef

This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-idwg-beep-idxp-07 EXPERIMENTAL EXPERIMENTAL IETF sec idwg 10.17487/RFC4767
RFC4768 Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming S. Hartman December 2006 ASCII HTML 12 acl access control list

The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. This memo provides information for the Internet community.

draft-ietf-kitten-gss-naming-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC4768
RFC4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information J. Livingood R. Shockey November 2006 ASCII HTML 13 tel uri uri scheme sip

This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. [STANDARDS-TRACK]

draft-ietf-enum-pstn-05 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4769
RFC4770 vCard Extensions for Instant Messaging (IM) C. Jennings J. Reschke Editor January 2007 ASCII HTML 7 impp instant messaging and presence protocol

This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. [STANDARDS-TRACK]

draft-jennings-impp-vcard-08 RFC6350 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4770
RFC4771 Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) V. Lehtovirta M. Naslund K. Norrman January 2007 ASCII HTML 12 roc

This document defines an integrity transform for Secure Real-time Transport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. [STANDARDS-TRACK]

draft-lehtovirta-srtp-rcc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4771 10.17487/RFC4771
RFC4772 Security Implications of Using the Data Encryption Standard (DES) S. Kelly December 2006 ASCII HTML 28

The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use. This memo provides information for the Internet community.

draft-kelly-saag-des-implications-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4772
RFC4773 Administration of the IANA Special Purpose IPv6 Address Block G. Huston December 2006 ASCII HTML 5

This is a direction to IANA concerning the management of the IANA Special Purpose IPv6 address assignment registry. This memo provides information for the Internet community.

draft-huston-ipv6-iana-specials-01 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4773
RFC4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field S. Floyd November 2006 ASCII HTML 15

There have been a number of proposals for alternate semantics for the Explicit Congestion Notification (ECN) field in the IP header RFC 3168. This document discusses some of the issues in defining alternate semantics for the ECN field, and specifies requirements for a safe coexistence in an Internet that could include routers that do not understand the defined alternate semantics. This document evolved as a result of discussions with the authors of one recent proposal for such alternate semantics. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tsvwg-ecn-alternates-02 RFC6040 BCP0124 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC4774
RFC4775 Procedures for Protocol Extensions and Variations S. Bradner B. Carpenter Editor T. Narten December 2006 ASCII HTML 14 sdo standards development organization

This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.

This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-carpenter-protocol-extensions-04 BCP0125 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4775
RFC4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information H. Schulzrinne November 2006 ASCII HTML 19 lci local configuration information

This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. [STANDARDS-TRACK]

RFC4676 RFC5774 RFC6848 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC4776
RFC4777 IBM's iSeries Telnet Enhancements T. Murphy Jr. P. Rieth J. Stevens November 2006 ASCII HTML 47 midrange business computer telnet environment client server printer

This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allows Telnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.

These support functions are implemented primarily using the Telnet Environment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. This memo provides information for the Internet community.

draft-murphy-iser-telnet-04 RFC2877 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4777
RFC4778 Operational Security Current Practices in Internet Service Provider Environments M. Kaeo January 2007 ASCII HTML 37 isp

This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. This memo provides information for the Internet community.

draft-ietf-opsec-current-practices-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=4778 10.17487/RFC4778
RFC4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks S. Asadullah A. Ahmed C. Popoviciu P. Savola J. Palet January 2007 ASCII HTML 81 v6ops isp ipv6 deployment scenarios broadband networks

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today\'s Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. This memo provides information for the Internet community.

draft-ietf-v6ops-bb-deployment-scenarios-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4779 10.17487/RFC4779
RFC4780 Management Information Base for the Session Initiation Protocol (SIP) K. Lingle J-F. Mule J. Maeng D. Walker April 2007 ASCII HTML 83 mib registrar services SIP-COMMON-MIB SIP-TC-MIB SIP-UA-MIB DEFINITIONS SIP-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]

draft-ietf-sip-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4780
RFC4781 Graceful Restart Mechanism for BGP with MPLS Y. Rekhter R. Aggarwal January 2007 ASCII HTML 10 border gateway protocol multiprotocol label switching nlri bgp network layer reachability information

A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.

The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRACK]

draft-ietf-mpls-bgp-mpls-restart-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4781
RFC4782 Quick-Start for TCP and IP S. Floyd M. Allman A. Jain P. Sarolahti January 2007 ASCII HTML 82

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.

This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tsvwg-quickstart-07 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4782 10.17487/RFC4782
RFC4783 GMPLS - Communication of Alarm Information L. Berger Editor December 2006 ASCII HTML 19 generalized multiprotocol label switching gmpls-rsvp

This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.

This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-alarm-spec-06 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4783 10.17487/RFC4783
RFC4784 Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks C. Carroll F. Quick June 2007 ASCII HTML 45 mip cryptographic keys dmu

The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS Authentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA).

cdma2000(R) is a registered trademark of the Telecommunications Industry Association (TIA). This memo provides information for the Internet community.

draft-carroll-dynmobileip-cdma-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4784
RFC4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) U. Blumenthal P. Goel January 2007 ASCII HTML 5 cipher suite

This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport Layer Security (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. [STANDARDS-TRACK]

draft-ietf-tls-psk-null-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC4785
RFC4786 Operation of Anycast Services J. Abley K. Lindqvist December 2006 ASCII HTML 24 ROUTING LOAD-BALANCING LOAD-SHARING

As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.

Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-grow-anycast-04 BCP0126 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC4786
RFC4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP F. Audet Editor C. Jennings January 2007 ASCII HTML 29 nat sip udp

This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-nat-udp-08 RFC6888 RFC7857 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC4787
RFC4788 Enhancements to RTP Payload Formats for EVRC Family Codecs Q. Xie R. Kapoor January 2007 ASCII HTML 22 enhanced variable rate codec real time transmission protocol evrc-b dtx discontinuous transmission

This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. [STANDARDS-TRACK]

draft-ietf-avt-compact-bundled-evrc-11 RFC3558 RFC5188 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4788
RFC4789 Simple Network Management Protocol (SNMP) over IEEE 802 Networks J. Schoenwaelder T. Jeffree November 2006 ASCII HTML 9

This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.

This document obsoletes RFC 1089. [STANDARDS-TRACK]

draft-schoenw-snmp-ether-02 RFC1089 RFC3417 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4789
RFC4790 Internet Application Protocol Collation Registry C. Newman M. Duerst A. Gulbrandsen March 2007 ASCII HTML 26 collation sorting

Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS-TRACK]

draft-newman-i18n-comparator-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4790 10.17487/RFC4790
RFC4791 Calendaring Extensions to WebDAV (CalDAV) C. Daboo B. Desruisseaux L. Dusseault March 2007 ASCII HTML 107 calsched calsch calcav calendar calendaring scheduling webdav ical icalendar itip text/calendar http

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK]

draft-dusseault-caldav-15 RFC5689 RFC6638 RFC6764 RFC7809 RFC7953 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4791 10.17487/RFC4791
RFC4792 Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg January 2007 ASCII HTML 9 ASN.1

Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. [STANDARDS-TRACK]

draft-legg-ldap-gser-ei-02 RFC3641 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4792
RFC4793 The EAP Protected One-Time Password Protocol (EAP-POTP) M. Nystroem February 2007 ASCII HTML 82 otp extensible authentication protocol

This document describes a general Extensible Authentication Protocol (EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key Exchange Protocol Version 2 (IKEv2). This memo provides information for the Internet community.

draft-nystrom-eap-potp-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4793
RFC4794 RFC 1264 Is Obsolete B. Fenner December 2006 ASCII HTML 4

RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way. This memo provides information for the Internet community.

draft-fenner-obsolete-1264-03 RFC1264 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4794
RFC4795 Link-local Multicast Name Resolution (LLMNR) B. Aboba D. Thaler L. Esibov January 2007 ASCII HTML 31

The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. This memo provides information for the Internet community.

draft-ietf-dnsext-mdns-47 INFORMATIONAL INFORMATIONAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4795 10.17487/RFC4795
RFC4796 The Session Description Protocol (SDP) Content Attribute J. Hautakorpi G. Camarillo February 2007 ASCII HTML 11 media attribute content

This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-media-content-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC4796
RFC4797 Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks Y. Rekhter R. Bonica E. Rosen January 2007 ASCII HTML 10 L3VPN GRE encapsulation

This document describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) in which the outermost MPLS label (i.e., the tunnel label) is replaced with either an IP header or an IP header with Generic Routing Encapsulation (GRE).

The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. This memo provides information for the Internet community.

draft-ietf-l3vpn-gre-ip-2547-05 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4797
RFC4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) J. De Clercq D. Ooms S. Prevost F. Le Faucheur February 2007 ASCII HTML 14 mp-bgp

This document explains how to interconnect IPv6 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are Dual Stack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the 6PE router so that dynamically established IPv4-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. [STANDARDS-TRACK]

draft-ooms-v6ops-bgp-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4798
RFC4799 RFC4800 RFC4801 Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 9 management information base mib GMPLS-TC-STD-MIB

This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-tc-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4801
RFC4802 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 60 mib GMPLS-TE-STD-MIB IANA-GMPLS-TC-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS)-based traffic engineering. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-te-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4802
RFC4803 Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base T. Nadeau Editor A. Farrel Editor February 2007 ASCII HTML 42 mib GMPLS-LSR-STD-MIB GMPLS-LABEL-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-lsr-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4803 10.17487/RFC4803
RFC4804 Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels F. Le Faucheur Editor February 2007 ASCII HTML 31 multiprotocol label switching traffic engineering diffserv-aware mpls traffic engineering

RFC 3175 specifies aggregation of Resource ReSerVation Protocol (RSVP) end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-dste-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4804 10.17487/RFC4804
RFC4805 Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types O. Nicklass Editor March 2007 ASCII HTML 94 mib management information base DS1-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types.

This document obsoletes RFC 3895. [STANDARDS-TRACK]

draft-orly-atommib-rfc3895bis-01 RFC3895 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4805
RFC4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2 M. Myers H. Tschofenig February 2007 ASCII HTML 11 internet key exchange version 2

While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-band Certificate Revocation Lists (CRL) is problematic due to unbounded CRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.

When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. [STANDARDS-TRACK]

draft-myers-ikev2-ocsp-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4806
RFC4807 IPsec Security Policy Database Configuration MIB M. Baer R. Charlet W. Hardaker R. Story C. Wang March 2007 ASCII HTML 71 management information base IPSEC-SPD-MIB

This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS-TRACK]

draft-ietf-ipsp-spd-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4807 10.17487/RFC4807
RFC4808 Key Change Strategies for TCP-MD5 S. Bellovin March 2007 ASCII HTML 8 bgp border gateway protocol

The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. This memo provides information for the Internet community.

draft-bellovin-keyroll2385-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4808
RFC4809 Requirements for an IPsec Certificate Management Profile C. Bonatti Editor S. Turner Editor G. Lebovitz Editor February 2007 ASCII HTML 45 internet protocol security

This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise-scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. This memo provides information for the Internet community.

draft-ietf-pki4ipsec-mgmt-profile-rqts-07 INFORMATIONAL INFORMATIONAL IETF sec pki4ipsec 10.17487/RFC4809
RFC4810 Long-Term Archive Service Requirements C. Wallace U. Pordesch R. Brandner March 2007 ASCII HTML 17 data integrity digital signatures

There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. This memo provides information for the Internet community.

draft-ietf-ltans-reqs-10 INFORMATIONAL INFORMATIONAL IETF sec ltans 10.17487/RFC4810
RFC4811 OSPF Out-of-Band Link State Database (LSDB) Resynchronization L. Nguyen A. Roy A. Zinin March 2007 ASCII HTML 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.

This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

draft-nguyen-ospf-oob-resync-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4811
RFC4812 OSPF Restart Signaling L. Nguyen A. Roy A. Zinin March 2007 ASCII HTML 7 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.

This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.

draft-nguyen-ospf-restart-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4812 10.17487/RFC4812
RFC4813 OSPF Link-Local Signaling B. Friedman L. Nguyen A. Roy D. Yeung A. Zinin March 2007 ASCII HTML 10 open shortest path first

OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This memo defines an Experimental Protocol for the Internet community.

draft-nguyen-ospf-lls-06 RFC5613 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4813
RFC4814 Hash and Stuffing: Overlooked Factors in Network Device Benchmarking D. Newman T. Player March 2007 ASCII HTML 26 bmwg benchmarking testing bit-stuffing byte-stuffing

Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. This memo provides information for the Internet community.

draft-ietf-bmwg-hash-stuffing-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4814
RFC4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 L-E. Jonsson K. Sandlund G. Pelletier P. Kremer February 2007 ASCII HTML 33 ip udp user datagram protocol rtp realtime transport protocol esp encapsulation security payload

RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol), RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security Payload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UDP-Lite profiles) are also provided. [STANDARDS-TRACK]

draft-ietf-rohc-rtp-impl-guide-22 RFC3095 RFC3241 RFC3843 RFC4019 RFC4362 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4815
RFC4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service A. Malis L. Martini J. Brayley T. Walsh February 2007 ASCII HTML 5

The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. [STANDARDS-TRACK]

draft-ietf-pwe3-cell-transport-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4816
RFC4817 Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 M. Townsley C. Pignataro S. Wainner T. Seely J. Young March 2007 ASCII HTML 12 l2tpv3 multiprotocol label switching label stack label stack

The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS-TRACK]

draft-ietf-mpls-over-l2tpv3-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4817
RFC4818 RADIUS Delegated-IPv6-Prefix Attribute J. Salowey R. Droms April 2007 ASCII HTML 7 remote authentication dial in user service diameter

This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. [STANDARDS-TRACK]

draft-ietf-radext-delegated-prefix-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4818
RFC4819 Secure Shell Public Key Subsystem J. Galbraith J. Van Dyke J. Bright March 2007 ASCII HTML 17 ssh ssh2

Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.

The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.

A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK]

draft-ietf-secsh-publickey-subsystem-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec secsh 10.17487/RFC4819
RFC4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei March 2007 ASCII HTML 6

This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-padding-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4820 10.17487/RFC4820
RFC4821 Packetization Layer Path MTU Discovery M. Mathis J. Heffner March 2007 ASCII HTML 32 maximum transmission unit pmtud

This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK]

draft-ietf-pmtud-method-11 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pmtud http://www.rfc-editor.org/errata_search.php?rfc=4821 10.17487/RFC4821
RFC4822 RIPv2 Cryptographic Authentication R. Atkinson M. Fanto February 2007 ASCII HTML 22 RIP2-MD5 Routing Information Protocol Encryption

This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. [STANDARDS-TRACK]

draft-rja-ripv2-auth-06 RFC2082 RFC2453 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4822
RFC4823 FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet T. Harding R. Scott April 2007 ASCII HTML 40 applicability statement as business-to-business

This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. This memo provides information for the Internet community.

draft-ietf-ediint-as3-04 INFORMATIONAL INFORMATIONAL IETF app ediint http://www.rfc-editor.org/errata_search.php?rfc=4823 10.17487/RFC4823
RFC4824 The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) J. Hofmueller Editor A. Bachmann Editor IO. zmoelnig Editor April 1 2007 ASCII HTML 13 internet protocol april fools

This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4824 10.17487/RFC4824
RFC4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) J. Rosenberg May 2007 ASCII HTML 71 sip xml http rest buddy list simple presence data manipulation

This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. [STANDARDS-TRACK]

draft-ietf-simple-xcap-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC4825
RFC4826 Extensible Markup Language (XML) Formats for Representing Resource Lists J. Rosenberg May 2007 ASCII HTML 31 http sip xml rest buddy list simple presence data manipulation

In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). [STANDARDS-TRACK]

draft-ietf-simple-xcap-list-usage-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4826 10.17487/RFC4826
RFC4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents M. Isomaki E. Leppanen May 2007 ASCII HTML 11 PIDF AUID hard state PUBLISH SIP Presence SIMPLE pidf-manipulation XCAP application usage

This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. [STANDARDS-TRACK]

draft-ietf-simple-xcap-pidf-manipulation-usage-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4827 10.17487/RFC4827
RFC4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant S. Floyd E. Kohler April 2007 ASCII HTML 46 transmission control protocol

This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.

TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment (RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.

Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small-packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dccp-tfrc-voip-07 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=4828 10.17487/RFC4828
RFC4829 Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering J. de Oliveira Editor JP. Vasseur Editor L. Chen C. Scoglio April 2007 ASCII HTML 19 traffic engineering label switched path te lsp multiprotocol label switching protocol

When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective \%Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. This memo provides information for the Internet community.

draft-deoliveira-diff-te-preemption-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4829
RFC4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII HTML 13

Localized mobility management is a well-understood concept in the IETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. This memo provides information for the Internet community.

draft-ietf-netlmm-nohost-ps-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4830
RFC4831 Goals for Network-Based Localized Mobility Management (NETLMM) J. Kempf Editor April 2007 ASCII HTML 14

In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. This memo provides information for the Internet community.

draft-ietf-netlmm-nohost-req-05 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4831
RFC4832 Security Threats to Network-Based Localized Mobility Management (NETLMM) C. Vogt J. Kempf April 2007 ASCII HTML 12 localized mobility anchor mobile access gateway compromise impersonation man in the middle denial of service IP spoofing

This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. This memo provides information for the Internet community.

draft-ietf-netlmm-threats-04 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC4832
RFC4833 Timezone Options for DHCP E. Lear P. Eggert April 2007 ASCII HTML 10 time offset posix tz database tz

Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options for each of those methods. The DHCPv4 time offset option is deprecated. [STANDARDS-TRACK]

draft-ietf-dhc-timezone-option-05 RFC2132 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4833
RFC4834 Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) T. Morin Editor April 2007 ASCII HTML 37 vpn virtual private networks l3

This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. This memo provides information for the Internet community.

draft-ietf-l3vpn-ppvpn-mcast-reqts-10 INFORMATIONAL INFORMATIONAL IETF int l3vpn 10.17487/RFC4834
RFC4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) V. Manral April 2007 ASCII HTML 10 ESP ipsec authentication mechanism header security architecture payload internet protocol encapsulating ipv4 ipv6

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. [STANDARDS-TRACK]

draft-manral-ipsec-rfc4305-bis-errata-03 RFC4305 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC4835
RFC4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) E. Beili April 2007 ASCII HTML 67 MAU-MIB IANA-MAU-MIB management information base,

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This document obsoletes RFC 3636. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. [STANDARDS-TRACK]

draft-ietf-hubmib-rfc3636bis-05 RFC3636 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib http://www.rfc-editor.org/errata_search.php?rfc=4836 10.17487/RFC4836
RFC4837 Managed Objects of Ethernet Passive Optical Networks (EPON) L. Khermosh July 2007 ASCII HTML 91 Ethernet Passive Optical Networks pon epon IEEE802.3ah 802.3ah p2mp mpcp llid onu olt optical access

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. [STANDARDS-TRACK]

draft-ietf-hubmib-efm-epon-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4837
RFC4838 Delay-Tolerant Networking Architecture V. Cerf S. Burleigh A. Hooke L. Torgerson R. Durst K. Scott K. Fall H. Weiss April 2007 ASCII HTML 35 disruption tolerant irtf interplanetary internet

This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community.

draft-irtf-dtnrg-arch-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC4838
RFC4839 Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) G. Conboy J. Rivlin J. Ferraiolo April 2007 ASCII HTML 5

This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files. This memo provides information for the Internet community.

draft-conboy-mime-opf-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4839
RFC4840 Multiple Encapsulation Methods Considered Harmful B. Aboba Editor E. Davies D. Thaler April 2007 ASCII HTML 27 iab link-layer protocol ip encapsulation internet protocol encapsulation

This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. This memo provides information for the Internet community.

draft-iab-link-encaps-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4840
RFC4841 RFC 4181 Update to Recognize the IETF Trust C. Heard Editor March 2007 ASCII HTML 3 management information base standards-track specifications mib review

This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-heard-rfc4181-update-00 RFC4181 BCP0111 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4841
RFC4842 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) A. Malis P. Pate R. Cohen Editor D. Zelig April 2007 ASCII HTML 43 multiprotocol label switching

This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK]

draft-ietf-pwe3-sonet-14 RFC5143 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=4842 10.17487/RFC4842
RFC4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) P. Nikander J. Laganier F. Dupont April 2007 ASCII HTML 14

This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. This memo defines an Experimental Protocol for the Internet community.

draft-laganier-ipv6-khi-07 RFC7343 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4843
RFC4844 The RFC Series and RFC Editor L. Daigle Editor Internet Architecture Board July 2007 ASCII HTML 20 technical publisher

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This memo provides information for the Internet community.

draft-iab-rfc-editor-04 RFC8729 RFC5741 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4844
RFC4845 Process for Publication of IAB RFCs L. Daigle Editor Internet Architecture Board July 2007 ASCII HTML 5

From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community.

draft-iab-publication-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4845
RFC4846 Independent Submissions to the RFC Editor J. Klensin Editor D. Thaler Editor July 2007 ASCII HTML 16

There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. This memo provides information for the Internet community.

draft-iab-rfc-independent-00 RFC5744 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4846
RFC4847 Framework and Requirements for Layer 1 Virtual Private Networks T. Takeda Editor April 2007 ASCII HTML 38 L1VPN

This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.

The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. This memo provides information for the Internet community.

draft-ietf-l1vpn-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC4847
RFC4848 Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) L. Daigle April 2007 ASCII HTML 10 service-parms service parameters

The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application. [STANDARDS-TRACK]

draft-daigle-unaptr-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4848 10.17487/RFC4848
RFC4849 RADIUS Filter Rule Attribute P. Congdon M. Sanchez B. Aboba April 2007 ASCII HTML 9 remote authentication dial in user service nas-filter-rule

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. [STANDARDS-TRACK]

draft-ietf-radext-filter-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC4849
RFC4850 Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture D. Wysochanski April 2007 ASCII HTML 9 transport protocol tcp transmission control protocol

The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-nodearch-key-03 RFC7143 RFC3720 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC4850
RFC4851 The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou May 2007 ASCII HTML 64 eap

This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. This memo provides information for the Internet community.

draft-cam-winget-eap-fast-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4851 10.17487/RFC4851
RFC4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus J. Bound Y. Pouffary S. Klynsma T. Chown D. Green April 2007 ASCII HTML 32 internet protocol version 6 notational network

This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community.

draft-ietf-v6ops-ent-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4852 10.17487/RFC4852
RFC4853 Cryptographic Message Syntax (CMS) Multiple Signer Clarification R. Housley April 2007 ASCII HTML 5 signeddata digitally sign authenticate encrypt arbitrary message content

This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. [STANDARDS-TRACK]

draft-ietf-smime-cms-mult-sign-03 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=4853 10.17487/RFC4853
RFC4854 A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre April 2007 ASCII HTML 9 Extensible Messaging and Presence Protocol XMPP Jabber Instant Messaging Presence Uniform Resource Name URN

This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). This memo provides information for the Internet community.

draft-saintandre-xmpp-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4854
RFC4855 Media Type Registration of RTP Payload Formats S. Casner February 2007 ASCII HTML 11 realtime transport protocol multipurpose internet mail extensions

This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. [STANDARDS-TRACK]

draft-ietf-avt-rfc3555bis-05 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4855
RFC4856 Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences S. Casner February 2007 ASCII HTML 29 realtime transport protocol multipurpose internet mail extensions

This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. [STANDARDS-TRACK]

draft-ietf-avt-rfc3555bis-part2-02 RFC3555 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4856 10.17487/RFC4856
RFC4857 Mobile IPv4 Regional Registration E. Fogelstroem A. Jonsson C. Perkins June 2007 ASCII HTML 35 GFA gateway foreign agent

Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mip4-reg-tunnel-04 EXPERIMENTAL EXPERIMENTAL IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=4857 10.17487/RFC4857
RFC4858 Document Shepherding from Working Group Last Call to Publication H. Levkowetz D. Meyer L. Eggert A. Mankin May 2007 ASCII HTML 21 document shepherding ietf documents

This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. This memo provides information for the Internet community.

draft-ietf-proto-wgchair-doc-shepherding-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4858
RFC4859 Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object A. Farrel April 2007 ASCII HTML 5

This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. This memo provides information for the Internet community.

draft-ietf-mpls-iana-rsvp-session-flags-01 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC4859
RFC4860 Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations F. Le Faucheur B. Davie P. Bose C. Christou M. Davenport May 2007 ASCII HTML 32 session object session of interest phb per hop behavior

RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-ipsec-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4860
RFC4861 Neighbor Discovery for IP version 6 (IPv6) T. Narten E. Nordmark W. Simpson H. Soliman September 2007 ASCII HTML 97 IPV6-ND internet protocol link-layer link-layer address

This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]

draft-ietf-ipv6-2461bis-11 RFC2461 RFC5942 RFC6980 RFC7048 RFC7527 RFC7559 RFC8028 RFC8319 RFC8425 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4861 10.17487/RFC4861
RFC4862 IPv6 Stateless Address Autoconfiguration S. Thomson T. Narten T. Jinmei September 2007 ASCII HTML 30 IPV6-AUTO host link-local internet protocol version 6 link-local address duplicate address detection

This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]

draft-ietf-ipv6-rfc2462bis-08 RFC2462 RFC7527 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4862 10.17487/RFC4862
RFC4863 Wildcard Pseudowire Type L. Martini G. Swallow May 2007 ASCII HTML 6 pw type pw

Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. [STANDARDS-TRACK]

draft-ietf-pwe3-wildcard-pw-type-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC4863
RFC4864 Local Network Protection for IPv6 G. Van de Velde T. Hain R. Droms B. Carpenter E. Klein May 2007 ASCII HTML 36 ipv6 address protection nat

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. This memo provides information for the Internet community.

draft-ietf-v6ops-nap-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4864
RFC4865 SMTP Submission Service Extension for Future Message Release G. White G. Vaudreuil May 2007 ASCII HTML 11 simple mail transfer protocol future-release-integer

This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK]

draft-vaudreuil-futuredelivery-04 RFC3463 RFC3464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4865 10.17487/RFC4865
RFC4866 Enhanced Route Optimization for Mobile IPv6 J. Arkko C. Vogt W. Haddad May 2007 ASCII HTML 54 mobility cryptographically generated addresses cga credit-based authorization cba

This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS-TRACK]

draft-ietf-mipshop-cga-cba-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=4866 10.17487/RFC4866
RFC4867 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs J. Sjoberg M. Westerlund A. Lakaniemi Q. Xie April 2007 ASCII HTML 59 interoperate applications

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. [STANDARDS-TRACK]

draft-ietf-avt-rtp-amr-bis-06 RFC3267 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=4867 10.17487/RFC4867
RFC4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec S. Kelly S. Frankel May 2007 ASCII HTML 21 hashed authentication mode data authentication integrity verification

This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]

draft-kelly-ipsec-ciph-sha2-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4868 10.17487/RFC4868
RFC4869 Suite B Cryptographic Suites for IPsec L. Law J. Solinas May 2007 ASCII HTML 9 ui suites user interface suites elliptic curve ike

This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This memo provides information for the Internet community.

draft-solinas-ui-suites-01 RFC6379 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4869
RFC4870 Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) M. Delany May 2007 ASCII HTML 41

"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.

This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.

Proof and protection of email identity may assist in the global control of "spam" and "phishing". This memo defines a Historic Document for the Internet community.

draft-delany-domainkeys-base-06 RFC4871 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC4870
RFC4871 DomainKeys Identified Mail (DKIM) Signatures E. Allman J. Callas M. Delany M. Libbey J. Fenton M. Thomas May 2007 ASCII HTML 71 internet mail authentication spam phishing spoofing digital signature

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". [STANDARDS-TRACK]

draft-ietf-dkim-base-10 RFC4870 RFC6376 RFC5672 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=4871 10.17487/RFC4871
RFC4872 RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery J.P. Lang Editor Y. Rekhter Editor D. Papadimitriou Editor May 2007 ASCII HTML 47 resource reservation protocol traffic engineering

This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04 RFC3471 RFC4873 RFC6780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4872 10.17487/RFC4872
RFC4873 GMPLS Segment Recovery L. Berger I. Bryskin D. Papadimitriou A. Farrel May 2007 ASCII HTML 25 generalized multipoint label switching rsvp-te resource reservation protocol traffic engineering NOTIFY_REQUEST

This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-segment-recovery-03 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4873 10.17487/RFC4873
RFC4874 Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) CY. Lee A. Farrel S. De Cnodder April 2007 ASCII HTML 27 srlg shared risk link groups

This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE).

The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.

In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SRLGs) can be excluded is also specified in this document. [STANDARDS-TRACK]

draft-ietf-ccamp-rsvp-te-exclude-route-06 RFC3209 RFC3473 RFC6001 RFC8390 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4874 10.17487/RFC4874
RFC4875 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) R. Aggarwal Editor D. Papadimitriou Editor S. Yasukawa Editor May 2007 ASCII HTML 53 p2mp point-to-multipoint traffic engineering

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.

There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-te-p2mp-07 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4875 10.17487/RFC4875
RFC4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents B. Neal-Joslin Editor L. Howard M. Ansari May 2007 ASCII HTML 39 ldap schema profile configuration nameservice nss pam_ldap nss_ldap rfc2307 rfc 2307

This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. This memo provides information for the Internet community.

draft-joslin-config-schema-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4876 10.17487/RFC4876
RFC4877 Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture V. Devarapalli F. Dupont April 2007 ASCII HTML 26 Bootstrapping MIP6 Selector Granularity Mobility Header EAP Authentication

This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. [STANDARDS-TRACK]

draft-ietf-mip6-ikev2-ipsec-08 RFC3776 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 http://www.rfc-editor.org/errata_search.php?rfc=4877 10.17487/RFC4877
RFC4878 Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces M. Squire June 2007 ASCII HTML 58 efm ethernet in the first mile snmp DOT3-OAM-MIB

This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities. [STANDARDS-TRACK]

draft-ietf-hubmib-efm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC4878
RFC4879 Clarification of the Third Party Disclosure Procedure in RFC 3979 T. Narten April 2007 ASCII HTML 4 ipr copyright

This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-narten-ipr-3979-3rd-party-fix-00 RFC8179 RFC3979 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr 10.17487/RFC4879
RFC4880 OpenPGP Message Format J. Callas L. Donnerhacke H. Finney D. Shaw R. Thayer November 2007 ASCII HTML 90 public-key cryptography symmetric cryptography

This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.

OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]

draft-ietf-openpgp-rfc2440bis-22 RFC1991 RFC2440 RFC5581 PROPOSED STANDARD PROPOSED STANDARD IETF sec openpgp http://www.rfc-editor.org/errata_search.php?rfc=4880 10.17487/RFC4880
RFC4881 Low-Latency Handoffs in Mobile IPv4 K. El Malki Editor June 2007 ASCII HTML 64 mip4

Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mobileip-lowlatency-handoffs-v4-11 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4881
RFC4882 IP Address Location Privacy and Mobile IPv6: Problem Statement R. Koodli May 2007 ASCII HTML 11 internet protocol home address care-of address

In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. This memo provides information for the Internet community.

draft-ietf-mip6-location-privacy-ps-06 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4882
RFC4883 Benchmarking Terminology for Resource Reservation Capable Routers G. Feher K. Nemeth A. Korn I. Cselenyi July 2007 ASCII HTML 24 intserv integrated services benchmarking methodologies

The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. This memo provides information for the Internet community.

draft-ietf-bmwg-benchres-term-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC4883
RFC4884 Extended ICMP to Support Multi-Part Messages R. Bonica D. Gan D. Tappan C. Pignataro April 2007 ASCII HTML 19 internet control message protocol length attribute

This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.

Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.

This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.

The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.

This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]

draft-bonica-internet-icmp-16 RFC0792 RFC4443 RFC8335 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4884 10.17487/RFC4884
RFC4885 Network Mobility Support Terminology T. Ernst H-Y. Lach July 2007 ASCII HTML 19 nemo

This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements. This memo provides information for the Internet community.

draft-ietf-nemo-terminology-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4885 10.17487/RFC4885
RFC4886 Network Mobility Support Goals and Requirements T. Ernst July 2007 ASCII HTML 13 nemo

Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. This memo provides information for the Internet community.

draft-ietf-nemo-requirements-06 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4886 10.17487/RFC4886
RFC4887 Network Mobility Home Network Models P. Thubert R. Wakikawa V. Devarapalli July 2007 ASCII HTML 19 nemo mobile routers

This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists. This memo provides information for the Internet community.

draft-ietf-nemo-home-network-models-06 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4887
RFC4888 Network Mobility Route Optimization Problem Statement C. Ng P. Thubert M. Watari F. Zhao July 2007 ASCII HTML 26 nemo

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO. This memo provides information for the Internet community.

draft-ietf-nemo-ro-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4888 10.17487/RFC4888
RFC4889 Network Mobility Route Optimization Solution Space Analysis C. Ng F. Zhao M. Watari P. Thubert July 2007 ASCII HTML 38 nemo mrha mobile router and home agent ro

With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. This memo provides information for the Internet community.

draft-ietf-nemo-ro-space-analysis-03 INFORMATIONAL INFORMATIONAL IETF int nemo http://www.rfc-editor.org/errata_search.php?rfc=4889 10.17487/RFC4889
RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls E. Davies J. Mohacsi May 2007 ASCII HTML 38 Internet Control Message Protocol version 6 ipv6 security filter firewall icmpv6

In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.

This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. This memo provides information for the Internet community.

draft-ietf-v6ops-icmpv6-filtering-recs-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4890 10.17487/RFC4890
RFC4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels R. Graveman M. Parthasarathy P. Savola H. Tschofenig May 2007 ASCII HTML 23 internet protocol internet protocol security ip security

This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. This memo provides information for the Internet community.

draft-ietf-v6ops-ipsec-tunnels-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4891
RFC4892 Requirements for a Mechanism Identifying a Name Server Instance S. Woolf D. Conrad June 2007 ASCII HTML 8 domain name service dns name server

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. This memo provides information for the Internet community.

draft-ietf-dnsop-serverid-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC4892
RFC4893 BGP Support for Four-octet AS Number Space Q. Vohra E. Chen May 2007 ASCII HTML 10 autonomous system border gateway protocol

Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [STANDARDS-TRACK]

draft-ietf-idr-as4bytes-13 RFC6793 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC4893
RFC4894 Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec P. Hoffman May 2007 ASCII HTML 11 md5 pkix certificates

This document describes how the IKEv1 (Internet Key Exchange version 1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. This memo provides information for the Internet community.

draft-hoffman-ike-ipsec-hash-use-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4894
RFC4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) M. Tuexen R. Stewart P. Lei E. Rescorla August 2007 ASCII HTML 19 chunk type shared keys RANDOM CHUNKS HMAC-ALGO

This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-auth-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4895 10.17487/RFC4895
RFC4896 Signaling Compression (SigComp) Corrections and Clarifications A. Surtees M. West A.B. Roach June 2007 ASCII HTML 28 sip session initiation protocol udvm universal decompressor virtual machine algorithm

This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485. [STANDARDS-TRACK]

draft-ietf-rohc-sigcomp-impl-guide-10 RFC3320 RFC3321 RFC3485 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4896
RFC4897 Handling Normative References to Standards-Track Documents J. Klensin S. Hartman June 2007 ASCII HTML 6

The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to such References. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-norm-ref-04 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4897 10.17487/RFC4897
RFC4898 TCP Extended Statistics MIB M. Mathis J. Heffner R. Raghunarayan May 2007 ASCII HTML 75 transmission control protocol management information base TCP-ESTATS-MIB

This document describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. [STANDARDS-TRACK]

draft-ietf-tsvwg-tcp-mib-extension-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC4898
RFC4899 RFC4900 RFC4901 Protocol Extensions for Header Compression over MPLS J. Ash Editor J. Hand Editor A. Malis Editor June 2007 ASCII HTML 34 multiprotocol label switching hc

This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link. [STANDARDS-TRACK]

draft-ietf-avt-hc-over-mpls-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC4901
RFC4902 Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP M. Stecher May 2007 ASCII HTML 14

The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.

The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. This memo provides information for the Internet community.

draft-ietf-opes-smtp-security-03 INFORMATIONAL INFORMATIONAL IETF app opes 10.17487/RFC4902
RFC4903 Multi-Link Subnet Issues D. Thaler June 2007 ASCII HTML 17

There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. This memo provides information for the Internet community.

draft-iab-multilink-subnet-issues-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4903
RFC4904 Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs) V. Gurbani C. Jennings June 2007 ASCII HTML 19 SIP TEL Trunk group trunkgroup PSTN

This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. [STANDARDS-TRACK]

draft-ietf-iptel-trunk-group-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC4904
RFC4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII HTML 20 multiprotocol label switching pdu protocol data unit draft-martini

This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM), or Ethernet for transport across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

draft-martini-l2circuit-encap-mpls-12 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4905 10.17487/RFC4905
RFC4906 Transport of Layer 2 Frames Over MPLS L. Martini Editor E. Rosen Editor N. El-Aawar Editor June 2007 ASCII HTML 22 multiprotocol label switching pdu protocol data unit sonet synchronized optical network

This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community.

draft-martini-l2circuit-trans-mpls-19 HISTORIC HISTORIC IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4906 10.17487/RFC4906
RFC4907 Architectural Implications of Link Indications B. Aboba Editor June 2007 ASCII HTML 62

A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications. This memo provides information for the Internet community.

draft-iab-link-indications-10 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4907 10.17487/RFC4907
RFC4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO K. Nagami S. Uda N. Ogashiwa H. Esaki R. Wakikawa H. Ohnishi June 2007 ASCII HTML 10 care-of addresses

Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. This memo defines an Experimental Protocol for the Internet community.

draft-nagami-mip6-nemo-multihome-fixed-network-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4908
RFC4909 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport L. Dondeti Editor D. Castleford F. Hartung June 2007 ASCII HTML 7 short-term key message long-term key message oma bac browser and content broadcast

This document specifies a new Multimedia Internet KEYing (MIKEY) General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification. This memo provides information for the Internet community.

draft-dondeti-msec-mikey-genext-oma-04 RFC5410 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4909 10.17487/RFC4909
RFC4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) S. Legg D. Prager July 2007 ASCII HTML 80 extensible markup language canonical rxer crxer

This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-rxer-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4910
RFC4911 Encoding Instructions for the Robust XML Encoding Rules (RXER) S. Legg July 2007 ASCII HTML 91 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer canonical robust xml encoding rules crxer asn.x

This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-rxer-ei-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4911
RFC4912 Abstract Syntax Notation X (ASN.X) S. Legg July 2007 ASCII HTML 165 extensible markup language asn.1 abstract syntax notation one robust xml encoding rules rxer

Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-asd-07 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4912
RFC4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER) S. Legg July 2007 ASCII HTML 9 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-asd-gserei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4913
RFC4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER) S. Legg July 2007 ASCII HTML 38 extensible markup language

Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER). This memo defines an Experimental Protocol for the Internet community.

draft-legg-xed-asd-xerei-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4914
RFC4915 Multi-Topology (MT) Routing in OSPF P. Psenak S. Mirtorabi A. Roy L. Nguyen P. Pillay-Esnault June 2007 ASCII HTML 20 open shortest path first

This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.

An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]

draft-ietf-ospf-mt-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4915
RFC4916 Connected Identity in the Session Initiation Protocol (SIP) J. Elwell June 2007 ASCII HTML 24 user agent ua application-layer application layer multimedia multicast unicast

This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK]

draft-ietf-sip-connected-identity-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC4916
RFC4917 Mobile IPv4 Message String Extension V. Sastry K. Leung A. Patel June 2007 ASCII HTML 7 home agent foreign agent registration reply

This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. [STANDARDS-TRACK]

draft-ietf-mip4-message-string-ext-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC4917
RFC4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) L. Dusseault Editor June 2007 ASCII HTML 127 WEBDAV hypertext transfer protocol web content

Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK]

draft-ietf-webdav-rfc2518bis-18 RFC2518 RFC5689 PROPOSED STANDARD PROPOSED STANDARD IETF app webdav http://www.rfc-editor.org/errata_search.php?rfc=4918 10.17487/RFC4918
RFC4919 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals N. Kushalnagar G. Montenegro C. Schumacher August 2007 ASCII HTML 12 ieee 802.15.4

This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. This memo provides information for the Internet community.

draft-ietf-6lowpan-problem-08 INFORMATIONAL INFORMATIONAL IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4919 10.17487/RFC4919
RFC4920 Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE A. Farrel Editor A. Satyanarayana A. Iwata N. Fujita G. Ash July 2007 ASCII HTML 38 multiprotocol label switching generalized multiprotocol label switching traffic engineered te lsp label switched path

In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.

This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]

draft-ietf-ccamp-crankback-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=4920 10.17487/RFC4920
RFC4921 RFC4922 RFC4923 Quality of Service (QoS) Signaling in a Nested Virtual Private Network F. Baker P. Bose August 2007 ASCII HTML 38 vpn nested vpn integrated services

Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over Diffserv networks as described in RFC 2998. This memo provides information for the Internet community.

draft-ietf-tsvwg-vpn-signaled-preemption-02 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC4923
RFC4924 Reflections on Internet Transparency B. Aboba Editor E. Davies July 2007 ASCII HTML 15

This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. This memo provides information for the Internet community.

draft-iab-net-transparent-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC4924
RFC4925 Softwire Problem Statement X. Li Editor S. Dawkins Editor D. Ward Editor A. Durand Editor July 2007 ASCII HTML 23

This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. This memo provides information for the Internet community.

draft-ietf-softwire-problem-statement-03 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC4925
RFC4926 A URN Namespace for GEANT T.Kalin M.Molina July 2007 ASCII HTML 9 uniform resource name dante

This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and Research Networks, its projects, activities, working groups, and other designated subordinates. This memo provides information for the Internet community.

draft-kalin-geant-urn-namespace-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4926
RFC4927 Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering J.-L. Le Roux Editor June 2007 ASCII HTML 12 gmpls te-lsp traffic engineered label switched path pce path computation element

For scalability purposes, a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. This memo provides information for the Internet community.

draft-ietf-pce-pcecp-interarea-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC4927
RFC4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks G. Swallow S. Bryant L. Andersson June 2007 ASCII HTML 8 ecmp

This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. These recommendations rely on inspection of the IP version number field in packets. Despite the heuristic nature of the recommendations, they provide a relatively safe way to operate MPLS networks, even if future allocations of IP version numbers were made for some purpose. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mpls-ecmp-bcp-03 RFC7274 BCP0128 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=4928 10.17487/RFC4928
RFC4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures L. Andersson Editor A. Farrel Editor June 2007 ASCII HTML 23

This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-andersson-rtg-gmpls-change-08 BCP0129 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4929
RFC4930 Extensible Provisioning Protocol (EPP) S. Hollenbeck May 2007 ASCII HTML 72 shared framework mapping

This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3730bis-04 RFC3730 RFC5730 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4930
RFC4931 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck May 2007 ASCII HTML 46 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3731bis-05 RFC3731 RFC5731 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4931
RFC4932 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck May 2007 ASCII HTML 30 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3732bis-04 RFC3732 RFC5732 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4932
RFC4933 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck May 2007 ASCII HTML 43 syntax semantics

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3733bis-06 RFC3733 RFC5733 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4933
RFC4934 Extensible Provisioning Protocol (EPP) Transport Over TCP S. Hollenbeck May 2007 ASCII HTML 10 mapping client server tls transport layer security

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]

draft-hollenbeck-epp-rfc3734bis-05 RFC3734 RFC5734 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP 10.17487/RFC4934
RFC4935 Fibre Channel Fabric Configuration Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII HTML 50 management information base T11-FC-FABRIC-CONFIG-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. [STANDARDS-TRACK]

draft-ietf-imss-fc-fcs-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss http://www.rfc-editor.org/errata_search.php?rfc=4935 10.17487/RFC4935
RFC4936 Fibre Channel Zone Server MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII HTML 84 management information base T11-FC-FABRIC-LOCK-MIB T11-FC-ZONE-SERVER-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. [STANDARDS-TRACK]

draft-ietf-imss-fc-zs-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4936
RFC4937 IANA Considerations for PPP over Ethernet (PPPoE) P. Arberg V. Mammoliti June 2007 ASCII HTML 6

This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. This memo provides information for the Internet community.

draft-arberg-pppoe-iana-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4937
RFC4938 PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry H. Holgate June 2007 ASCII HTML 17

This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. This memo provides information for the Internet community.

draft-bberry-pppoe-credit-06 RFC5578 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=4938 10.17487/RFC4938
RFC4939 Definitions of Managed Objects for iSNS (Internet Storage Name Service) K. Gibbons G. Ramkumar S. Kipp July 2007 ASCII HTML 80 mib management information base iscsi internet small computer system interface ifcp internet fibre channel protocol ISNS-MIB

The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (Internet Fibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. [STANDARDS-TRACK]

draft-ietf-ips-isns-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips http://www.rfc-editor.org/errata_search.php?rfc=4939 10.17487/RFC4939
RFC4940 IANA Considerations for OSPF K. Kompella B. Fenner July 2007 ASCII HTML 15 open shortest path first

This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ospf-iana-03 BCP0130 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=4940 10.17487/RFC4940
RFC4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 T. Narten R. Draves S. Krishnan September 2007 ASCII HTML 23 privacy anonymity unlinkability crypto-based address changing

Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]

draft-ietf-ipv6-privacy-addrs-v2-05 RFC3041 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=4941 10.17487/RFC4941
RFC4942 IPv6 Transition/Co-existence Security Considerations E. Davies S. Krishnan P. Savola September 2007 ASCII HTML 41 internet protocol version 6 dual-protocol network ipv4

The transition from a pure IPv4 network to a network where IPv4 and IPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories:

o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment.

This memo provides information for the Internet community.

draft-ietf-v6ops-security-overview-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4942
RFC4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful S. Roy A. Durand J. Paugh September 2007 ASCII HTML 8 internet protocol version 6

This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm. This memo provides information for the Internet community.

draft-ietf-v6ops-onlinkassumption-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC4943
RFC4944 Transmission of IPv6 Packets over IEEE 802.15.4 Networks G. Montenegro N. Kushalnagar J. Hui D. Culler September 2007 ASCII HTML 30 internet protocol version 6 link-local address stateless autoconfiguration

This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]

draft-ietf-6lowpan-format-13 RFC6282 RFC6775 RFC8025 RFC8066 RFC8931 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=4944 10.17487/RFC4944
RFC4945 The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX B. Korver August 2007 ASCII HTML 43 internet key exchange public key infrastructure for x.509 ipsec

The Internet Key Exchange (IKE) and Public Key Infrastructure for X.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec. [STANDARDS-TRACK]

draft-ietf-pki4ipsec-ikecert-profile-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec pki4ipsec 10.17487/RFC4945
RFC4946 Atom License Extension J. Snell July 2007 ASCII HTML 8 atom syndication format atom feeds atom entries

This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries. This memo defines an Experimental Protocol for the Internet community.

draft-snell-atompub-feed-license-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC4946
RFC4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks G. Fairhurst M. Montpetit July 2007 ASCII HTML 41 encapsulate motion picture experts group unidirectional link protocol UniDirectional Link Routing address resolution protocol

This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.

draft-ietf-ipdvb-ar-06 INFORMATIONAL INFORMATIONAL IETF int ipdvb 10.17487/RFC4947
RFC4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 L. Andersson E. Davies L. Zhang August 2007 ASCII HTML 43 spam botnet

This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. This memo provides information for the Internet community.

draft-iab-iwout-report-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4948 10.17487/RFC4948
RFC4949 Internet Security Glossary, Version 2 R. Shirey August 2007 ASCII HTML 365 abbreviation clarity definition dictionary language punctuation synonym terminology writing

This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.

draft-shirey-secgloss-v2-08 RFC2828 FYI0036 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4949
RFC4950 ICMP Extensions for Multiprotocol Label Switching R. Bonica D. Gan D. Tappan C. Pignataro August 2007 ASCII HTML 8 Internet Control Message Protocol

This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK]

draft-ietf-mpls-icmp-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC4950
RFC4951 Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" V. Jain Editor August 2007 ASCII HTML 26 control connection layer 2 connectivity

Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. [STANDARDS-TRACK]

draft-ietf-l2tpext-failover-12 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC4951
RFC4952 Overview and Framework for Internationalized Email J. Klensin Y. Ko July 2007 ASCII HTML 20 smtp

Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This memo provides information for the Internet community.

draft-ietf-eai-framework-05 RFC6530 RFC5336 INFORMATIONAL INFORMATIONAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=4952 10.17487/RFC4952
RFC4953 Defending TCP Against Spoofing Attacks J. Touch July 2007 ASCII HTML 28 rst transport control protocol

Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.

draft-ietf-tcpm-tcp-antispoof-06 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4953
RFC4954 SMTP Service Extension for Authentication R. Siemborski Editor A. Melnikov Editor July 2007 ASCII HTML 20 simple mail transport protocol security layer sasl

This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.

This document obsoletes RFC 2554. [STANDARDS-TRACK]

draft-siemborski-rfc2554bis-09 RFC2554 RFC3463 RFC5248 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4954 10.17487/RFC4954
RFC4955 DNS Security (DNSSEC) Experiments D. Blacka July 2007 ASCII HTML 7 domain namespace

This document describes a methodology for deploying alternate, non-backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-experiments-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC4955
RFC4956 DNS Security (DNSSEC) Opt-In R. Arends M. Kosters D. Blacka July 2007 ASCII HTML 17 domain namespace

In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dnsext-dnssec-opt-in-09 EXPERIMENTAL EXPERIMENTAL IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=4956 10.17487/RFC4956
RFC4957 Link-Layer Event Notifications for Detecting Network Attachments S. Krishnan Editor N. Montavont E. Njedjou S. Veerepalli A. Yegin Editor August 2007 ASCII HTML 18

Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. This memo provides information for the Internet community.

draft-ietf-dna-link-information-06 INFORMATIONAL INFORMATIONAL IETF int dna http://www.rfc-editor.org/errata_search.php?rfc=4957 10.17487/RFC4957
RFC4958 A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain K. Carlberg July 2007 ASCII HTML 28 priority prioritization preferential service

This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. This memo provides information for the Internet community.

draft-ietf-ieprep-domain-frame-08 INFORMATIONAL INFORMATIONAL IETF rai ieprep http://www.rfc-editor.org/errata_search.php?rfc=4958 10.17487/RFC4958
RFC4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response R. Siemborski A. Gulbrandsen September 2007 ASCII HTML 7 imap authenticate internet message access protocol

To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.

This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. [STANDARDS-TRACK]

draft-siemborski-imap-sasl-initial-response-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4959 10.17487/RFC4959
RFC4960 Stream Control Transmission Protocol R. Stewart Editor September 2007 ASCII HTML 152 SCTP IP internet transport packet network

This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.

SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:

-- acknowledged error-free non-duplicated transfer of user data,

-- data fragmentation to conform to discovered path MTU size,

-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,

-- optional bundling of multiple user messages into a single SCTP packet, and

-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association.

The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]

draft-ietf-tsvwg-2960bis-05 RFC2960 RFC3309 RFC6096 RFC6335 RFC7053 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=4960 10.17487/RFC4960
RFC4961 Symmetric RTP / RTP Control Protocol (RTCP) D. Wing July 2007 ASCII HTML 6 real time transport protocol symmetric rtcp

This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-wing-behave-symmetric-rtprtcp-03 BCP0131 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4961
RFC4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management R. Housley B. Aboba July 2007 ASCII HTML 23

This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-housley-aaa-key-mgmt-09 BCP0132 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC4962
RFC4963 IPv4 Reassembly Errors at High Data Rates J. Heffner M. Mathis B. Chandler July 2007 ASCII HTML 10

IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. This memo provides information for the Internet community.

draft-heffner-frag-harmful-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4963
RFC4964 The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular A. Allen Editor J. Holm T. Hallin September 2007 ASCII HTML 32 p-header oma open mobile alliance poc

This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. This memo provides information for the Internet community.

draft-allen-sipping-poc-p-answer-state-header-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4964
RFC4965 CableLabs - IETF Standardization Collaboration J-F. Mule W. Townsley September 2007 ASCII HTML 10 IETF CableLabs Collaboration liaison Cable Television Laboratories DOCSIS PacketCable OpenCable

This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs). This memo provides information for the Internet community.

draft-mule-ietf-cablelabs-collaboration-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC4965
RFC4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status C. Aoun E. Davies July 2007 ASCII HTML 25 NAT-PT v6ops

This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. This memo provides information for the Internet community.

draft-ietf-v6ops-natpt-to-historic-00 RFC2766 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=4966 10.17487/RFC4966
RFC4967 Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier B. Rosen July 2007 ASCII HTML 6 dialstring

RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. [STANDARDS-TRACK]

draft-rosen-iptel-dialstring-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4967 10.17487/RFC4967
RFC4968 Analysis of IPv6 Link Models for 802.16 Based Networks S. Madanapalli Editor August 2007 ASCII HTML 16 wimax

This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks. This memo provides information for the Internet community.

draft-ietf-16ng-ipv6-link-model-analysis-03 INFORMATIONAL INFORMATIONAL IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=4968 10.17487/RFC4968
RFC4969 IANA Registration for vCard Enumservice A. Mayrhofer August 2007 ASCII HTML 7 enum e.164

This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number.

Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. [STANDARDS-TRACK]

draft-ietf-enum-vcard-06 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4969
RFC4970 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer July 2007 ASCII HTML 13 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK]

draft-ietf-ospf-cap-11 RFC7770 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC4970
RFC4971 Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information JP. Vasseur Editor N. Shen Editor R. Aggarwal Editor July 2007 ASCII HTML 9 capabilty

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. [STANDARDS-TRACK]

draft-ietf-isis-caps-07 RFC7981 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC4971
RFC4972 Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership JP. Vasseur Editor JL. Leroux Editor S. Yasukawa S. Previdi P. Psenak P. Mabbey July 2007 ASCII HTML 15 mpls-te lsp label switched path igp is-is ospf

The setup of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is a common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TE LSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. [STANDARDS-TRACK]

draft-ietf-ccamp-automesh-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4972
RFC4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering P. Srisuresh P. Joseph July 2007 ASCII HTML 50 ospf-te link state advertisement lsa

This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks. This memo defines an Experimental Protocol for the Internet community.

draft-srisuresh-ospf-te-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC4973
RFC4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls D. Papadimitriou A. Farrel August 2007 ASCII HTML 31

In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.

A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs).

This document specifies how GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation.

The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-rsvp-te-call-04 RFC3473 RFC6001 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC4974
RFC4975 The Message Session Relay Protocol (MSRP) B. Campbell Editor R. Mahy Editor C. Jennings Editor September 2007 ASCII HTML 63 instant message

This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS-TRACK]

draft-ietf-simple-message-sessions-19 RFC7977 RFC8591 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4975 10.17487/RFC4975
RFC4976 Relay Extensions for the Message Sessions Relay Protocol (MSRP) C. Jennings R. Mahy A. B. Roach September 2007 ASCII HTML 36 instante message page-mode session-mode relay intermediary

Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. [STANDARDS-TRACK]

draft-ietf-simple-msrp-relays-10 RFC7977 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=4976 10.17487/RFC4976
RFC4977 Problem Statement: Dual Stack Mobility G. Tsirtsis H. Soliman August 2007 ASCII HTML 8 mobility management protocol mipv4 mipv6 mobile ip

This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. This memo provides information for the Internet community.

draft-ietf-mip6-dsmip-problem-03 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC4977
RFC4978 The IMAP COMPRESS Extension A. Gulbrandsen August 2007 ASCII HTML 9 Internet Message Access Protocol

The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK]

draft-ietf-lemonade-compress-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=4978 10.17487/RFC4978
RFC4979 IANA Registration for Enumservice 'XMPP' A. Mayrhofer August 2007 ASCII HTML 7 extensible messaging and presence protocol e.164

This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). [STANDARDS-TRACK]

draft-ietf-enum-xmpp-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC4979
RFC4980 Analysis of Multihoming in Network Mobility Support C. Ng T. Ernst E. Paik M. Bagnulo October 2007 ASCII HTML 39 nemo ipv6 mobile networks

This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. This memo provides information for the Internet community.

draft-ietf-nemo-multihoming-issues-07 INFORMATIONAL INFORMATIONAL IETF int nemo 10.17487/RFC4980
RFC4981 Survey of Research towards Robust Peer-to-Peer Networks: Search Methods J. Risson T. Moors September 2007 ASCII HTML 91 Peer-to-peer network Distributed hash table Structured overlay Unstructured overlay Key-based routing Consistent hashing Scalable distributed data structure Dependability Hypercube Plaxton tree de Bruijn graph Skip graph Torus Butterfly network Vector model Latent semantic indexing

The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.

Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.

P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. This memo provides information for the Internet community.

draft-irtf-p2prg-survey-search-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC4981
RFC4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) M. Bagnulo J. Arkko July 2007 ASCII HTML 9

This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS-TRACK]

draft-bagnulo-multiple-hash-cga-03 RFC3972 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=4982 10.17487/RFC4982
RFC4983 Fibre Channel Registered State Change Notification (RSCN) MIB C. DeSanti H.K. Vivek K. McCloghrie S. Gai August 2007 ASCII HTML 28 management information base T11-FC-RSCN-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). [STANDARDS-TRACK]

draft-ietf-imss-fc-rscn-mib-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC4983
RFC4984 Report from the IAB Workshop on Routing and Addressing D. Meyer Editor L. Zhang Editor K. Fall Editor September 2007 ASCII HTML 39 routing and addressing workshop routing table growth addressing architecture

This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. This memo provides information for the Internet community.

draft-iab-raws-report-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=4984 10.17487/RFC4984
RFC4985 Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name S. Santesson August 2007 ASCII HTML 10 othername

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]

draft-ietf-pkix-srvsan-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=4985 10.17487/RFC4985
RFC4986 Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover H. Eland R. Mundy S. Crocker S. Krishnaswamy August 2007 ASCII HTML 11 dns signed zone

Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. This memo provides information for the Internet community.

draft-ietf-dnsext-rollover-requirements-04 INFORMATIONAL INFORMATIONAL IETF int dnsext 10.17487/RFC4986
RFC4987 TCP SYN Flooding Attacks and Common Mitigations W. Eddy August 2007 ASCII HTML 19 TCP SYN Flood TCP SYN Cookies denial-of-service DoS

This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community.

draft-ietf-tcpm-syn-flood-05 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC4987
RFC4988 Mobile IPv4 Fast Handovers R. Koodli C. Perkins October 2007 ASCII HTML 28 mip4 delay packet loss movement detection ip address configuration loation update latency care-of address care of address coa

This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-mip4-fmipv4-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC4988
RFC4989 RFC4990 Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks K. Shiomoto R. Papneja R. Rabbat September 2007 ASCII HTML 23 address field identifier field

This document clarifies the use of addresses in Generalized Multiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers (LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.

The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.

This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-addressing-08 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC4990
RFC4991 A Common Schema for Internet Registry Information Service Transfer Protocols A. Newton August 2007 ASCII HTML 13 iris xml

This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. [STANDARDS-TRACK]

draft-ietf-crisp-iris-common-transport-05 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4991 10.17487/RFC4991
RFC4992 XML Pipelining with Chunks for the Internet Registry Information Service A. Newton August 2007 ASCII HTML 29 tcp transport control protocol iris

This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. [STANDARDS-TRACK]

draft-ietf-crisp-iris-xpc-06 RFC3981 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4992 10.17487/RFC4992
RFC4993 A Lightweight UDP Transfer Protocol for the Internet Registry Information Service A. Newton August 2007 ASCII HTML 19 iris

This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. [STANDARDS-TRACK]

draft-ietf-crisp-iris-lwz-08 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=4993 10.17487/RFC4993
RFC4994 DHCPv6 Relay Agent Echo Request Option S. Zeng B. Volz K. Kinnear J. Brzozowski September 2007 ASCII HTML 6 dynamic host configuration protocol relay agent option

This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-ero-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC4994
RFC4995 The RObust Header Compression (ROHC) Framework L-E. Jonsson G. Pelletier K. Sandlund July 2007 ASCII HTML 40

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. [STANDARDS-TRACK]

draft-ietf-rohc-rfc3095bis-framework-04 RFC5795 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4995 10.17487/RFC4995
RFC4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West July 2007 ASCII HTML 94

This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. [STANDARDS-TRACK]

draft-ietf-rohc-tcp-16 RFC6846 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=4996 10.17487/RFC4996
RFC4997 Formal Notation for RObust Header Compression (ROHC-FN) R. Finking G. Pelletier July 2007 ASCII HTML 62 Robust Header Compression - Formal Notation

This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. [STANDARDS-TRACK]

draft-ietf-rohc-formal-notation-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC4997
RFC4998 Evidence Record Syntax (ERS) T. Gondrom R. Brandner U. Pordesch August 2007 ASCII HTML 32 long-term archive security timestamp evidence record archive timestamp

In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]

draft-ietf-ltans-ers-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC4998
RFC4999 RFC5000 Internet Official Protocol Standards RFC Editor May 2008 ASCII HTML 75

This document is published by the RFC Editor to provide a summary of the current standards protocols (as of 18 February 2008). It lists those official protocol standards, Best Current Practice, and Experimental RFCs that have not been obsoleted; it is not a complete index to the RFC series. Newly published RFCs and RFCs whose status has changed are starred.

For an up-to-date list, see http://www.rfc-editor.org/rfcxx00.html, which is updated daily. This memo provides information for the Internet community.

RFC3700 RFC7100 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC5000
RFC5001 DNS Name Server Identifier (NSID) Option R. Austein August 2007 ASCII HTML 11 domain name space namespace

With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]

draft-ietf-dnsext-nsid-02 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5001
RFC5002 The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) G. Camarillo G. Blanco August 2007 ASCII HTML 7 3gpp ims ip multimedia subsystem

This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. This memo provides information for the Internet community.

draft-camarillo-sipping-profile-key-02 RFC8217 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5002 10.17487/RFC5002
RFC5003 Attachment Individual Identifier (AII) Types for Aggregation C. Metz L. Martini F. Balus J. Sugimoto September 2007 ASCII HTML 7 tlv pseudowire

The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]

draft-ietf-pwe3-aii-aggregate-02 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5003 10.17487/RFC5003
RFC5004 Avoid BGP Best Path Transitions from One External to Another E. Chen S. Sangli September 2007 ASCII HTML 6 border gateway protocol

In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. [STANDARDS-TRACK]

draft-ietf-idr-avoid-transition-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5004
RFC5005 Feed Paging and Archiving M. Nottingham September 2007 ASCII HTML 15 atom rss

This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". [STANDARDS-TRACK]

draft-nottingham-atompub-feed-history-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5005 10.17487/RFC5005
RFC5006 IPv6 Router Advertisement Option for DNS Configuration J. Jeong Editor S. Park L. Beloeil S. Madanapalli September 2007 ASCII HTML 12 domain namespace

This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. This memo defines an Experimental Protocol for the Internet community.

draft-jeong-dnsop-ipv6-dns-discovery-12 RFC6106 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5006
RFC5007 DHCPv6 Leasequery J. Brzozowski K. Kinnear B. Volz S. Zeng September 2007 ASCII HTML 23 dhc dhcp ipv6

This document specifies a leasequery exchange for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-leasequery-01 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5007 10.17487/RFC5007
RFC5008 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas September 2007 ASCII HTML 15 nsa

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851. This memo provides information for the Internet community.

draft-housley-smime-suite-b-02 RFC6318 HISTORIC INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5008 10.17487/RFC5008
RFC5009 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media R. Ejza September 2007 ASCII HTML 15 IMS NGN ETSI TISPAN Gating Cut-through Call progress Charging PSTN Interworking Gateway Ringback Trust domain

This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. This memo provides information for the Internet community.

draft-ejzak-sipping-p-em-auth-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5009
RFC5010 The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption K. Kinnear M. Normoyle M. Stapp September 2007 ASCII HTML 7 unicast flag broadcast flag

This memo defines a new suboption of the Dynamic Host Configuration Protocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. [STANDARDS-TRACK]

draft-ietf-dhc-relay-agent-flags-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5010
RFC5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors M. StJohns September 2007 ASCII HTML 14 n-1 key n keys

This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).

This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]

draft-ietf-dnsext-trustupdate-timers-06 STD0074 INTERNET STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5011
RFC5012 Requirements for Emergency Context Resolution with Internet Technologies H. Schulzrinne R. Marshall Editor January 2008 ASCII HTML 23 emergency calling ecrit

This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end. This memo provides information for the Internet community.

draft-ietf-ecrit-requirements-13 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5012 10.17487/RFC5012
RFC5013 The Dublin Core Metadata Element Set J. Kunze T. Baker August 2007 ASCII HTML 9 resource description object descriptors digital library collections

This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. This memo provides information for the Internet community.

draft-kunze-rfc2413bis-07 RFC2413 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5013
RFC5014 IPv6 Socket API for Source Address Selection E. Nordmark S. Chakrabarti J. Laganier September 2007 ASCII HTML 24 getaddrinfo()cga cryptographically generated address

The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. This memo provides information for the Internet community.

draft-chakrabarti-ipv6-addrselect-api-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5014
RFC5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM) M. Handley I. Kouvelas T. Speakman L. Vicisano October 2007 ASCII HTML 43 pim sparse-mode shared trees

This document discusses Bidirectional PIM (BIDIR-PIM), a variant of PIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. [STANDARDS-TRACK]

draft-ietf-pim-bidir-09 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5015 10.17487/RFC5015
RFC5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol M. Thomas October 2007 ASCII HTML 15 cryptographic

DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD). This memo provides information for the Internet community.

draft-ietf-dkim-ssp-requirements-05 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5016
RFC5017 MIB Textual Conventions for Uniform Resource Identifiers (URIs) D. McWalter Editor September 2007 ASCII HTML 7 management information base URI-TC-MIB

This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS-TRACK]

draft-mcwalter-uri-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5017
RFC5018 Connection Establishment in the Binary Floor Control Protocol (BFCP) G. Camarillo September 2007 ASCII HTML 9 floor control server tls transport layer security

This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]

draft-ietf-xcon-bfcp-connection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC5018
RFC5019 The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments A. Deacon R. Hurst September 2007 ASCII HTML 22 OCSP Online Certificate Status Protocol certificate status http caching http proxies efficient cacheable pre-produced

This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client-side processing. [STANDARDS-TRACK]

draft-ietf-pkix-lightweight-ocsp-profile-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5019 10.17487/RFC5019
RFC5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute K. Zeilenga August 2007 ASCII HTML 5 x.500

This document describes the Lightweight Directory Access Protocol (LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. [STANDARDS-TRACK]

draft-zeilenga-ldap-entrydn-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5020
RFC5021 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP S. Josefsson August 2007 ASCII HTML 7

This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK]

draft-ietf-krb-wg-tcp-expansion-02 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC5021
RFC5022 Media Server Control Markup Language (MSCML) and Protocol J. Van Dyke E. Burger Editor A. Spitzer September 2007 ASCII HTML 81 sip ivr interactive voice response

Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. This memo provides information for the Internet community.

RFC4722 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5022 10.17487/RFC5022
RFC5023 The Atom Publishing Protocol J. Gregorio Editor B. de hOra Editor October 2007 ASCII HTML 53 atompub http transfer atom syndication format

The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. [STANDARDS-TRACK]

draft-ietf-atompub-protocol-17 PROPOSED STANDARD PROPOSED STANDARD IETF app atompub http://www.rfc-editor.org/errata_search.php?rfc=5023 10.17487/RFC5023
RFC5024 ODETTE File Transfer Protocol 2.0 I. Friend November 2007 ASCII HTML 135

This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.

The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing, and compression using Cryptographic Message Syntax, and provides signed receipts for the acknowledgement of received files.

The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25, and ISDN-based networks. This memo provides information for the Internet community.

draft-friend-oftp2-04 RFC2204 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5024 10.17487/RFC5024
RFC5025 Presence Authorization Rules J. Rosenberg December 2007 ASCII HTML 28 presence systems authorization policies xml extensible markup language

Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. [STANDARDS-TRACK]

draft-ietf-simple-presence-rules-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5025 10.17487/RFC5025
RFC5026 Mobile IPv6 Bootstrapping in Split Scenario G. Giaretta Editor J. Kempf V. Devarapalli Editor October 2007 ASCII HTML 28 mip6 bootstrapping problem statement

A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the Mobile Node. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the Mobile Node's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. [STANDARDS-TRACK]

draft-ietf-mip6-bootstrapping-split-07 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5026
RFC5027 Security Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen D. Wing October 2007 ASCII HTML 16 DTLS DTLS-SRTP TLS MIKEY Security Descriptions SRTP

This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. [STANDARDS-TRACK]

draft-ietf-mmusic-securityprecondition-04 RFC3312 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5027
RFC5028 A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services R. Mahy October 2007 ASCII HTML 5 'im:' uri uniform resource identifier

This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. [STANDARDS-TRACK]

draft-ietf-enum-im-service-03 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5028
RFC5029 Definition of an IS-IS Link Attribute Sub-TLV JP. Vasseur S. Previdi September 2007 ASCII HTML 6 link-attributes tlv 22

This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. [STANDARDS-TRACK]

draft-ietf-isis-link-attr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5029
RFC5030 Mobile IPv4 RADIUS Requirements M. Nakhjiri Editor K. Chowdhury A. Lior K. Leung October 2007 ASCII HTML 9 remote authentication dial-in user service mip mipv4

This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. This memo provides information for the Internet community.

draft-ietf-mip4-radius-requirements-04 INFORMATIONAL INFORMATIONAL IETF int mip4 10.17487/RFC5030
RFC5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services H. Schulzrinne January 2008 ASCII HTML 14 urn ecrit

The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. [STANDARDS-TRACK]

draft-ietf-ecrit-service-urn-07 RFC7163 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5031 10.17487/RFC5031
RFC5032 WITHIN Search Extension to the IMAP Protocol E. Burger Editor September 2007 ASCII HTML 5 imap search older younger

This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. [STANDARDS-TRACK]

draft-ietf-lemonade-search-within-05 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5032
RFC5033 Specifying New Congestion Control Algorithms S. Floyd M. Allman August 2007 ASCII HTML 10

The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tsvwg-cc-alt-04 BCP0133 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5033
RFC5034 The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism R. Siemborski A. Menon-Sen July 2007 ASCII HTML 12 POP3-AUTH Post Office Protocol Email

This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.

This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained in Section 6.3 of RFC 2449. [STANDARDS-TRACK]

draft-siemborski-rfc1734bis-11 RFC1734 RFC2449 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5034
RFC5035 Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility J. Schaad August 2007 ASCII HTML 17 validation signature certificate

In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. [STANDARDS-TRACK]

draft-ietf-smime-escertid-06 RFC2634 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5035 10.17487/RFC5035
RFC5036 LDP Specification L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII HTML 135 label distribution protocol

The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]

draft-ietf-mpls-rfc3036bis-04 RFC3036 RFC6720 RFC6790 RFC7358 RFC7552 DRAFT STANDARD DRAFT STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5036 10.17487/RFC5036
RFC5037 Experience with the Label Distribution Protocol (LDP) L. Andersson Editor I. Minei Editor B. Thomas Editor October 2007 ASCII HTML 7

The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-experience-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5037
RFC5038 The Label Distribution Protocol (LDP) Implementation Survey Results B. Thomas L. Andersson October 2007 ASCII HTML 23 multiprotocol label switching mpls lsr label switched routers

Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label Distribution Protocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, called LDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-survey2002-00 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5038
RFC5039 The Session Initiation Protocol (SIP) and Spam J. Rosenberg C. Jennings January 2008 ASCII HTML 28

Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. This memo provides information for the Internet community.

draft-ietf-sipping-spam-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5039
RFC5040 A Remote Direct Memory Access Protocol Specification R. Recio B. Metzler P. Culley J. Hilland D. Garcia October 2007 ASCII HTML 66 rdmap ddp direct data placement protocol

This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. [STANDARDS-TRACK]

draft-ietf-rddp-rdmap-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5040
RFC5041 Direct Data Placement over Reliable Transports H. Shah J. Pinkerton R. Recio P. Culley October 2007 ASCII HTML 38 ddp cpu

The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. [STANDARDS-TRACK]

draft-ietf-rddp-ddp-07 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5041
RFC5042 Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security J. Pinkerton E. Deleganes October 2007 ASCII HTML 52 rdma network interface card rnic

This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. [STANDARDS-TRACK]

draft-ietf-rddp-security-10 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5042
RFC5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation C. Bestler Editor R. Stewart Editor October 2007 ASCII HTML 18 lower layer protocol llp

This document specifies an adaptation layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). [STANDARDS-TRACK]

draft-ietf-rddp-sctp-07 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp 10.17487/RFC5043
RFC5044 Marker PDU Aligned Framing for TCP Specification P. Culley U. Elzur R. Recio S. Bailey J. Carrier October 2007 ASCII HTML 74 mpa adaaptation layer ddp direct data placement protocol transmission

Marker PDU Aligned Framing (MPA) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement protocol (DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. [STANDARDS-TRACK]

draft-ietf-rddp-mpa-08 RFC6581 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rddp http://www.rfc-editor.org/errata_search.php?rfc=5044 10.17487/RFC5044
RFC5045 Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) C. Bestler Editor L. Coene October 2007 ASCII HTML 22 rdmap

This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. This memo provides information for the Internet community.

draft-ietf-rddp-applicability-08 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv rddp 10.17487/RFC5045
RFC5046 Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) M. Ko M. Chadalapaka J. Hufferd U. Elzur H. Shah P. Thaler October 2007 ASCII HTML 85 rdma data transfer

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. [STANDARDS-TRACK]

draft-ietf-ips-iser-06 RFC7145 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5046
RFC5047 DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) M. Chadalapaka J. Hufferd J. Satran H. Shah October 2007 ASCII HTML 49 scsi transport protocol tcp/ip

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access (RDMA)-capable IP fabrics in the future comprising TCP, the Stream Control Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. This memo provides information for the Internet community.

draft-ietf-ips-iwarp-da-05 RFC7146 INFORMATIONAL INFORMATIONAL IETF tsv ips 10.17487/RFC5047
RFC5048 Internet Small Computer System Interface (iSCSI) Corrections and Clarifications M. Chadalapaka Editor October 2007 ASCII HTML 38 scsi iscsi protocol

The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. [STANDARDS-TRACK]

draft-ietf-ips-iscsi-impl-guide-09 RFC7143 RFC3720 RFC7146 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ips 10.17487/RFC5048
RFC5049 Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) C. Bormann Z. Liu R. Price G. Camarillo Editor December 2007 ASCII HTML 21

This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. [STANDARDS-TRACK]

draft-ietf-rohc-sigcomp-sip-08 RFC3486 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc 10.17487/RFC5049
RFC5050 Bundle Protocol Specification K. Scott S. Burleigh November 2007 ASCII HTML 50 delay tolerant networking dtn dtnrg exchange of messages

This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).

This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-spec-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5050 10.17487/RFC5050
RFC5051 i;unicode-casemap - Simple Unicode Collation Algorithm M. Crispin October 2007 ASCII HTML 7 unicode strings i;ascii-casemap

This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. [STANDARDS-TRACK]

draft-crispin-collation-unicasemap-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5051
RFC5052 Forward Error Correction (FEC) Building Block M. Watson M. Luby L. Vicisano August 2007 ASCII HTML 25 bulk data transfer

This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. [STANDARDS-TRACK]

draft-ietf-rmt-fec-bb-revised-07 RFC3452 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5052 10.17487/RFC5052
RFC5053 Raptor Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer October 2007 ASCII HTML 46 fec fec encoding raptor code

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.

Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.

The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-raptor-object-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5053
RFC5054 Using the Secure Remote Password (SRP) Protocol for TLS Authentication D. Taylor T. Wu N. Mavrogiannopoulos T. Perrin November 2007 ASCII HTML 24 secure remote password protocol transport layer security

This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community.

draft-ietf-tls-srp-14 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5054 10.17487/RFC5054
RFC5055 Server-Based Certificate Validation Protocol (SCVP) T. Freeman R. Housley A. Malpani D. Cooper W. Polk December 2007 ASCII HTML 88 certification path construction certification path validation

The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. [STANDARDS-TRACK]

draft-ietf-pkix-scvp-33 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5055
RFC5056 On the Use of Channel Bindings to Secure Channels N. Williams November 2007 ASCII HTML 23

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS-TRACK]

draft-williams-on-channel-binding-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5056 10.17487/RFC5056
RFC5057 Multiple Dialog Usages in the Session Initiation Protocol R. Sparks November 2007 ASCII HTML 26

Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.

This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.

This is an informative document and makes no normative statements of any kind. This memo provides information for the Internet community.

draft-ietf-sipping-dialogusage-06 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5057
RFC5058 Explicit Multicast (Xcast) Concepts and Options R. Boivie N. Feldman Y. Imai W. Livens D. Ooms November 2007 ASCII HTML 35 explicit multi-unicast

While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.

This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. This memo defines an Experimental Protocol for the Internet community.

draft-ooms-xcast-basic-spec-13 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5058 10.17487/RFC5058
RFC5059 Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) N. Bhaskar A. Gall J. Lingard S. Venaas January 2008 ASCII PDF HTML 42 rendezvous point rp multicast router

This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. [STANDARDS-TRACK]

draft-ietf-pim-sm-bsr-12 RFC2362 RFC4601 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5059 10.17487/RFC5059
RFC5060 Protocol Independent Multicast MIB R. Sivaramu J. Lingard D. McWalter B. Joshi A. Kessler January 2008 ASCII HTML 90 PIM PIM-SM BIDIR-PIM PIM-DM Multicast Routing PIM-STD-MIB management information base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode), BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. [STANDARDS-TRACK]

draft-ietf-pim-mib-v2-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5060 10.17487/RFC5060
RFC5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration R. Stewart Q. Xie M. Tuexen S. Maruyama M. Kozuka September 2007 ASCII HTML 41

A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. [STANDARDS-TRACK]

draft-ietf-tsvwg-addip-sctp-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5061
RFC5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures R. Stewart M. Tuexen G. Camarillo September 2007 ASCII HTML 14

This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC 4460). These techniques are included in RFC 4960, which obsoletes RFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC 4960. This memo provides information for the Internet community.

draft-ietf-tsvwg-sctpthreat-05 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5062
RFC5063 Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart A. Satyanarayana Editor R. Rahman Editor October 2007 ASCII HTML 24 nodal faults rsvp hello state recovery

This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted.

Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.

The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.

These extensions are not used to create or restore data plane state.

The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). [STANDARDS-TRACK]

draft-ietf-ccamp-rsvp-restart-ext-09 RFC2961 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5063 10.17487/RFC5063
RFC5064 The Archived-At Message Header Field M. Duerst December 2007 ASCII HTML 10

This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]

draft-duerst-archived-at-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5064
RFC5065 Autonomous System Confederations for BGP P. Traina D. McPherson J. Scudder August 2007 ASCII HTML 14 border gateway protocol tcp/ip full mesh

The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.

This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

This document obsoletes RFC 3065. [STANDARDS-TRACK]

draft-ietf-idr-rfc3065bis-06 RFC3065 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5065 10.17487/RFC5065
RFC5066 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili November 2007 ASCII HTML 90 Network Management Simple Network Management Protocol SNMP Management Information Base MIB Textual Conventions 2BASE-TL 10PASS-TS 802.3ah EFM PAF PME

This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets. This document describes extensions to the Ethernet-like Interfaces MIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004 (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3- 2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. [STANDARDS-TRACK]

draft-ietf-hubmib-efm-cu-mib-08 RFC7124 PROPOSED STANDARD PROPOSED STANDARD IETF ops hubmib 10.17487/RFC5066
RFC5067 Infrastructure ENUM Requirements S. Lind P. Pfautz November 2007 ASCII HTML 7 e.164 number mapping carrier

This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) This memo provides information for the Internet community.

draft-ietf-enum-infrastructure-enum-reqs-04 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5067
RFC5068 Email Submission Operations: Access and Accountability Requirements C. Hutzler D. Crocker P. Resnick E. Allman T. Finch November 2007 ASCII HTML 12 spam email abuse phishing email e-mail service mime rfc2822 rfc 2822 rfc822 rfc 822 rfc2821 rfc 2821 rfc821 rfc 821 architecture mta mua msa mda user delivery relay header gateway agent sieve dsn mdn tussle mhs mail handling service message transfer agent message user agent mail submission agent mail delivery agent

Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.

Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hutzler-spamops-08 RFC8314 BCP0134 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5068
RFC5069 Security Threats and Requirements for Emergency Call Marking and Mapping T. Taylor Editor H. Tschofenig H. Schulzrinne M. Shanmugam January 2008 ASCII HTML 12 ecrit public safety answering points pasp

This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.

Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. This memo provides information for the Internet community.

draft-ietf-ecrit-security-threats-05 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC5069
RFC5070 The Incident Object Description Exchange Format R. Danyliw J. Meijer Y. Demchenko December 2007 ASCII HTML 92 incident data format compuer security incident computer security incident response team csirt cert security data sharing computer network defense service provider cndsp

The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. [STANDARDS-TRACK]

draft-ietf-inch-iodef-14 RFC7970 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec inch http://www.rfc-editor.org/errata_search.php?rfc=5070 10.17487/RFC5070
RFC5071 Dynamic Host Configuration Protocol Options Used by PXELINUX D. Hankins December 2007 ASCII HTML 14 dhcp dhcp option codes

This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. This memo provides information for the Internet community.

draft-ietf-dhc-pxelinux-03 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC5071
RFC5072 IP Version 6 over PPP S. Varada Editor D. Haskins E. Allen September 2007 ASCII HTML 16 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP, and the method for forming IPv6 link-local addresses on PPP links.

It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration.

This document obsoletes RFC 2472. [STANDARDS-TRACK]

draft-ietf-ipv6-over-ppp-v2-03 RFC2472 RFC8064 DRAFT STANDARD DRAFT STANDARD IETF int ipv6 10.17487/RFC5072
RFC5073 IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities J.P. Vasseur Editor J.L. Le Roux Editor December 2007 ASCII HTML 13 interior gateway protocol

It is highly desired, in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. [STANDARDS-TRACK]

draft-ietf-ccamp-te-node-cap-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5073
RFC5074 DNSSEC Lookaside Validation (DLV) S. Weiler November 2007 ASCII HTML 11 dns security trust anchors

DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain. It allows validating resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or don't publish Delegation Signer (DS) records for their children. This memo provides information for the Internet community.

draft-weiler-dnssec-dlv-04 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5074
RFC5075 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden November 2007 ASCII HTML 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. [STANDARDS-TRACK]

draft-ietf-ipv6-ra-flags-option-02 RFC5175 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 http://www.rfc-editor.org/errata_search.php?rfc=5075 10.17487/RFC5075
RFC5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol B. Hoeneisen December 2007 ASCII HTML 24 epp validation process e.164 enum enum domain name

This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. [STANDARDS-TRACK]

draft-ietf-enum-validation-epp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5076
RFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side State J. Salowey H. Zhou P. Eronen H. Tschofenig January 2008 ASCII HTML 20

This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]

draft-salowey-tls-rfc4507bis-01 RFC4507 RFC8446 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5077 10.17487/RFC5077
RFC5078 IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline S. Dawkins October 2007 ASCII HTML 9 Internet Architecture Board Engineering Steering Group nomcom

RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in the NomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson (2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. This memo provides information for the Internet community.

draft-dawkins-nomcom-start-earlier-02 RFC7437 RFC3777 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5078
RFC5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) J. Rosenberg December 2007 ASCII HTML 8 anonymous calls

The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. [STANDARDS-TRACK]

draft-ietf-sip-acr-code-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5079
RFC5080 Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes D. Nelson A. DeKok December 2007 ASCII HTML 28

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [STANDARDS-TRACK]

draft-ietf-radext-fixes-08 RFC2865 RFC2866 RFC2869 RFC3579 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5080 10.17487/RFC5080
RFC5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos November 2007 ASCII HTML 8 tls handshake protocol handshake

This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tls-openpgp-keys-11 RFC6091 EXPERIMENTAL EXPERIMENTAL IETF sec tls 10.17487/RFC5081
RFC5082 The Generalized TTL Security Mechanism (GTSM) V. Gill J. Heasley D. Meyer P. Savola Editor C. Pignataro October 2007 ASCII HTML 16 time to live packet hop limit

The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]

draft-ietf-rtgwg-rfc3682bis-10 RFC3682 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC5082
RFC5083 Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type R. Housley November 2007 ASCII HTML 10 encryption mode

This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-TRACK]

draft-ietf-smime-cms-auth-enveloped-06 RFC3852 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5083
RFC5084 Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley November 2007 ASCII HTML 11 authenticated encryption algorithm

This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. [STANDARDS-TRACK]

draft-ietf-smime-cms-aes-ccm-and-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5084 10.17487/RFC5084
RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires T. Nadeau Editor C. Pignataro Editor December 2007 ASCII HTML 30 pw

This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK]

draft-ietf-pwe3-vccv-15 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5085 10.17487/RFC5085
RFC5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) A. Vainshtein Editor I. Sasson E. Metz T. Frost P. Pate December 2007 ASCII HTML 38 nxds0 psn

This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community.

draft-ietf-pwe3-cesopsn-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 10.17487/RFC5086
RFC5087 Time Division Multiplexing over IP (TDMoIP) Y(J). Stein R. Shashoua R. Insler M. Anavi December 2007 ASCII HTML 50 TDM pseudowire PWE3 TDMoIP structure-aware TDM emulation

Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accessibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling. This memo provides information for the Internet community.

draft-ietf-pwe3-tdmoip-06 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5087 10.17487/RFC5087
RFC5088 OSPF Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII HTML 20 pcc path computation client open shortest path first

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]

draft-ietf-pce-disco-proto-ospf-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5088 10.17487/RFC5088
RFC5089 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery JL. Le Roux Editor JP. Vasseur Editor Y. Ikejiri R. Zhang January 2008 ASCII HTML 17 path computation client pcc intermediate system to intermediate system

There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]

draft-ietf-pce-disco-proto-isis-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5089 10.17487/RFC5089
RFC5090 RADIUS Extension for Digest Authentication B. Sterman D. Sadolevsky D. Schwartz D. Williams W. Beck February 2008 ASCII HTML 33 remote authentication dial-in user service sip http

This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS-TRACK]

draft-ietf-radext-rfc4590bis-02 RFC4590 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5090 10.17487/RFC5090
RFC5091 Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems X. Boyen L. Martin December 2007 ASCII HTML 63 Encryption Cryptography Security Elliptic Curves Elliptic Curve Cryptography Pairing-based Cryptography Identity-based Cryptography Identity-based Encryption Boneh-Franklin Encryption Scheme Boneh-Boyen Encryption Scheme

This document describes the algorithms that implement Boneh-Franklin (BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. This memo provides information for the Internet community.

draft-martin-ibcs-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5091 10.17487/RFC5091
RFC5092 IMAP URL Scheme A. Melnikov Editor C. Newman November 2007 ASCII HTML 32 IMAP-URL remote access store Internet Message Access Protocol Uniform Resource Identifiers

IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.

This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]

draft-ietf-lemonade-rfc2192bis-09 RFC2192 RFC4467 RFC5593 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5092 10.17487/RFC5092
RFC5093 BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) G. Hunt December 2007 ASCII HTML 8 next-generation network rtcp xr real time control protocol extended reports transport metrics

This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre-standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. This memo provides information for the Internet community.

draft-hunt-avt-rtcpxnq-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5093
RFC5094 Mobile IPv6 Vendor Specific Option V. Devarapalli A. Patel K. Leung December 2007 ASCII HTML 7 mobility header mip6 mipv6

There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option. [STANDARDS-TRACK]

draft-ietf-mip6-vsm-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5094
RFC5095 Deprecation of Type 0 Routing Headers in IPv6 J. Abley P. Savola G. Neville-Neil December 2007 ASCII HTML 7 ipv6 type 0 routing header traffic amplification

The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]

draft-ietf-ipv6-deprecate-rh0-01 RFC2460 RFC4294 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5095
RFC5096 Mobile IPv6 Experimental Messages V. Devarapalli December 2007 ASCII HTML 7 mip6 mobility header mobility option mipv6

This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. [STANDARDS-TRACK]

draft-ietf-mip6-experimental-messages-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5096
RFC5097 MIB for the UDP-Lite protocol G. Renker G. Fairhurst January 2008 ASCII HTML 23 SMIv2 UDPLITE-MIB management information base lightweight user datagram protocol

This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. [STANDARDS-TRACK]

draft-ietf-tsvwg-udplite-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5097
RFC5098 Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) G. Beacham S. Kumar S. Channabasappa February 2008 ASCII HTML 79 PKTC-IETF-SIG-MIB snmp simple network management protocol packetcable-compliant ipcablecom-compliant

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

draft-ietf-ipcdn-pktc-signaling-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn http://www.rfc-editor.org/errata_search.php?rfc=5098 10.17487/RFC5098
RFC5099 RFC5100 RFC5101 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information B. Claise Editor January 2008 ASCII HTML 63 exporting process collecting process template records

This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. [STANDARDS-TRACK]

draft-ietf-ipfix-protocol-26 RFC7011 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5101 10.17487/RFC5101
RFC5102 Information Model for IP Flow Information Export J. Quittek S. Bryant B. Claise P. Aitken J. Meyer January 2008 ASCII HTML 171 ipfix ip flow information export protocol measured traffic observation point metering process exporting process

This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK]

draft-ietf-ipfix-info-15 RFC7012 RFC6313 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5102 10.17487/RFC5102
RFC5103 Bidirectional Flow Export Using IP Flow Information Export (IPFIX) B. Trammell E. Boschi January 2008 ASCII HTML 24 flow record biflow

This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]

draft-ietf-ipfix-biflow-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5103 10.17487/RFC5103
RFC5104 Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) S. Wenger U. Chandra M. Westerlund B. Burman February 2008 ASCII HTML 64 real time protocol real-time protocol itu-t rec. h271 video back channel full intra request temporary maximum media stream bit rate temporal-spatial trade-off

This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.

The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK]

draft-ietf-avt-avpf-ccm-10 RFC7728 RFC8082 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5104
RFC5105 ENUM Validation Token Format Definition O. Lendl December 2007 ASCII HTML 17 telephone number mapping e.164

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. [STANDARDS-TRACK]

draft-ietf-enum-validation-token-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5105
RFC5106 The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method H. Tschofenig D. Kroeselberg A. Pashalidis Y. Ohba F. Bersani February 2008 ASCII HTML 33 cryptographic ciphersuite negotiation hash function agility identity confidentiality fragmentation fast reconnect mode

This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. This memo defines an Experimental Protocol for the Internet community.

draft-tschofenig-eap-ikev2-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5106 10.17487/RFC5106
RFC5107 DHCP Server Identifier Override Suboption R. Johnson J. Kumarasamy K. Kinnear M. Stapp February 2008 ASCII HTML 7 xml extensible markup langauge dynamic host configuration protocol RENEW DHCPREQUEST DHCP RENEW

This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. [STANDARDS-TRACK]

draft-ietf-dhc-server-override-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5107
RFC5108 RFC5109 RTP Payload Format for Generic Forward Error Correction A. Li Editor December 2007 ASCII HTML 44 fec realtime transport protocol

This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. [STANDARDS-TRACK]

draft-ietf-avt-ulp-23 RFC2733 RFC3009 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5109 10.17487/RFC5109
RFC5110 Overview of the Internet Multicast Routing Architecture P. Savola January 2008 ASCII HTML 25 RFC 3913 RFC 2189 RFC 2201 RFC 1584

This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.

This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.

draft-ietf-mboned-routingarch-12 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC5110
RFC5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF) B. Aboba L. Dondeti January 2008 ASCII HTML 8 working group formation bof birds of a feather

This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. Exploratory Groups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather (BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. This memo defines an Experimental Protocol for the Internet community.

draft-aboba-sg-experiment-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5111
RFC5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) M. Garcia-Martin January 2008 ASCII HTML 25 communication session event notification presence

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. [STANDARDS-TRACK]

draft-garcia-simple-presence-dictionary-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5112
RFC5113 Network Discovery and Selection Problem J. Arkko B. Aboba J. Korhonen Editor F. Bari January 2008 ASCII HTML 39

When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. This memo provides information for the Internet community.

draft-ietf-eap-netsel-problem-09 INFORMATIONAL INFORMATIONAL IETF int eap 10.17487/RFC5113
RFC5114 Additional Diffie-Hellman Groups for Use with IETF Standards M. Lepinski S. Kent January 2008 ASCII HTML 23 elliptic curve ike tls ssh smime x.509

This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell (SSH), Transport Layer Security (TLS), and Internet Key Exchange (IKE).

All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman or Elliptic Curve Diffie-Hellman cryptography.

These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal Information Processing Standard (FIPS) validation of implementations that make use of these groups. This memo provides information for the Internet community.

draft-lepinski-dh-groups-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5114
RFC5115 Telephony Routing over IP (TRIP) Attribute for Resource Priority K. Carlberg P. O'Hanlon January 2008 ASCII HTML 8 ip telephony ResourcePriority

This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. [STANDARDS-TRACK]

draft-carlberg-trip-attribute-rp-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5115 10.17487/RFC5115
RFC5116 An Interface and Algorithms for Authenticated Encryption D. McGrew January 2008 ASCII HTML 22 Encryption Authentication AEAD authenticated encryption with associated data

This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK]

draft-mcgrew-auth-enc-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5116 10.17487/RFC5116
RFC5117 RTP Topologies M. Westerlund S. Wenger January 2008 ASCII HTML 21 multi-endpoint topologies real-time transport protocol

This document discusses multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This memo provides information for the Internet community.

draft-ietf-avt-topologies-07 RFC7667 INFORMATIONAL INFORMATIONAL IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5117 10.17487/RFC5117
RFC5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) V. Gurbani C. Boulton R. Sparks February 2008 ASCII HTML 18 Torture test IPv6 SIP

This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation. This memo provides information for the Internet community.

draft-ietf-sipping-ipv6-torture-tests-04 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5118 10.17487/RFC5118
RFC5119 A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) T. Edwards February 2008 ASCII HTML 9 persistent resources universal labels,

This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. This memo provides information for the Internet community.

draft-edwards-urn-smpte-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5119 10.17487/RFC5119
RFC5120 M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) T. Przygienda N. Shen N. Sheth February 2008 ASCII HTML 14 is-is

This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]

draft-ietf-isis-wg-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5120
RFC5121 Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks B. Patil F. Xia B. Sarikaya JH. Choi S. Madanapalli February 2008 ASCII HTML 22 Neighbor Discovery Per-MS Perfix

IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MAN CSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. [STANDARDS-TRACK]

draft-ietf-16ng-ipv6-over-ipv6cs-11 RFC8064 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng http://www.rfc-editor.org/errata_search.php?rfc=5121 10.17487/RFC5121
RFC5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre February 2008 ASCII HTML 26 Extensible Messaging and Presence Protocol Internationalized Resource Identifier Uniform Resource Identifier Jabber xmpp iri uri

This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS-TRACK]

draft-saintandre-rfc4622bis-01 RFC4622 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5122
RFC5123 Considerations in Validating the Path in BGP R. White B. Akyol February 2008 ASCII HTML 16 bgp autonomous system path bgp as path

This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path. This memo provides information for the Internet community.

draft-white-pathconsiderations-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5123 10.17487/RFC5123
RFC5124 Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) J. Ott E. Carrara February 2008 ASCII HTML 18 avpf rtp communication

An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK]

draft-ietf-avt-profile-savpf-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5124
RFC5125 Reclassification of RFC 3525 to Historic T. Taylor February 2008 ASCII HTML 4 MEGACO H.248 media gateway control

This document reclassifies RFC 3525, Gateway Control Protocol Version 1, to Historic Status. This memo also obsoletes RFC 3525. This memo provides information for the Internet community.

draft-taylor-megaco-obsol3525-01 RFC3525 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5125
RFC5126 CMS Advanced Electronic Signatures (CAdES) D. Pinkas N. Pope J. Ross March 2008 ASCII HTML 141 verifying party signer purchase contract invoice application smart cards data

This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny (i.e., repudiates) the validity of the signature.

The format can be considered as an extension to RFC 3852 and RFC 2634, where, when appropriate, additional signed and unsigned attributes have been defined.

The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS Advanced Electronic Signatures -- CAdES) and is technically equivalent to it.

The technical contents of this specification are maintained by ETSI. The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx This memo provides information for the Internet community.

draft-ietf-smime-cades-07 RFC3126 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5126
RFC5127 Aggregation of Diffserv Service Classes K. Chan J. Babiarz F. Baker February 2008 ASCII HTML 19 Treatment Aggregate forwarding treatment

In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. This memo provides information for the Internet community.

draft-ietf-tsvwg-diffserv-class-aggr-07 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5127
RFC5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) P. Srisuresh B. Ford D. Kegel March 2008 ASCII HTML 32

This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. This memo provides information for the Internet community.

draft-ietf-behave-p2p-state-06 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5128 10.17487/RFC5128
RFC5129 Explicit Congestion Marking in MPLS B. Davie B. Briscoe J. Tay January 2008 ASCII HTML 21 Diffserv Differentiated Services QOS ECN tunnel

RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. [STANDARDS-TRACK]

draft-ietf-tsvwg-ecn-mpls-02 RFC3032 RFC5462 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5129
RFC5130 A Policy Control Mechanism in IS-IS Using Administrative Tags S. Previdi M. Shand Editor C. Martin February 2008 ASCII HTML 8 intermediate systetm to intermediate system ip prefix distribution lsp link state protocol

This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [STANDARDS-TRACK]

draft-ietf-isis-admin-tags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5130
RFC5131 A MIB Textual Convention for Language Tags D. McWalter Editor December 2007 ASCII HTML 6 LANGTAG-TC-MIB

This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. [STANDARDS-TRACK]

draft-mcwalter-langtag-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5131
RFC5132 IP Multicast MIB D. McWalter D. Thaler A. Kessler December 2007 ASCII HTML 59 managament information base IPMCAST-MIB,

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. [STANDARDS-TRACK]

draft-ietf-mboned-ip-mcast-mib-07 RFC2932 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5132
RFC5133 Terminal Endpoint Identifier (TEI) Query Request Number Change M. Tuexen K. Morneault December 2007 ASCII HTML 4 isdn q.921-user adaptation layer iua

The Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5. However, this number is already being used by the Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129. This document updates RFC 4233 such that the message type of TEI Query Request messages is 8. [STANDARDS-TRACK]

draft-ietf-sigtran-rfc4233update-02 RFC4233 PROPOSED STANDARD PROPOSED STANDARD IETF rai sigtran 10.17487/RFC5133
RFC5134 A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards M. Mealling January 2008 ASCII HTML 10 uniform resource name Auto-ID RFID EPCglobal EPC UPC supply chain management bar code

This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. This memo provides information for the Internet community.

draft-mealling-epc-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5134 10.17487/RFC5134
RFC5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) D. Wing T. Eckert February 2008 ASCII HTML 16 multicast application multicast nat

This document specifies requirements for a for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. An IP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-multicast-12 BCP0135 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5135 10.17487/RFC5135
RFC5136 Defining Network Capacity P. Chimento J. Ishac February 2008 ASCII HTML 14 bandwidth bandwidth estimation capacity estimation link capacity available capacity narrow link tight link

Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. This memo provides information for the Internet community.

draft-ietf-ippm-bw-capacity-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5136
RFC5137 ASCII Escaping of Unicode Characters J. Klensin February 2008 ASCII HTML 13 Text internationalization ascii unicode utf-8 encoding

There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-klensin-unicode-escapes-07 BCP0137 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5137 10.17487/RFC5137
RFC5138 A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) S. Cox February 2008 ASCII HTML 8

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application of Geoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal Namespace Identifier (NID) is "cgi". This memo provides information for the Internet community.

draft-sjdcox-cgi-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5138
RFC5139 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2008 ASCII HTML 14 location civic location pidf-lo civic address

This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. [STANDARDS-TRACK]

draft-ietf-geopriv-revised-civic-lo-07 RFC4119 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5139
RFC5140 A Telephony Gateway REgistration Protocol (TGREP) M. Bangalore R. Kumar J. Rosenberg H. Salama D.N. Shah March 2008 ASCII HTML 28 telephony prefix soft switches telephony routing over ip trip internet telephony administrative domains itad

This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS-TRACK]

draft-ietf-iptel-tgrep-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel http://www.rfc-editor.org/errata_search.php?rfc=5140 10.17487/RFC5140
RFC5141 A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) J. Goodwin H. Apel March 2008 ASCII HTML 28 urn nid uniform resource name namespace identification NSS

This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). This memo provides information for the Internet community.

draft-goodwin-iso-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5141 10.17487/RFC5141
RFC5142 Mobility Header Home Agent Switch Message B. Haley V. Devarapalli H. Deng J. Kempf January 2008 ASCII HTML 13

This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. [STANDARDS-TRACK]

draft-ietf-mip6-ha-switch-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC5142
RFC5143 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation A. Malis J. Brayley J. Shirron L. Martini S. Vogelsang February 2008 ASCII HTML 24 psn packet switched network RFC4842

This document describes a historical method for encapsulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Path signals for transport across packet-switched networks (PSNs). The PSNs explicitly supported by this document include MPLS and IP. Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. This memo defines a Historic Document for the Internet community.

draft-malis-sonet-ces-mpls-09 RFC4842 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5143
RFC5144 A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS) A. Newton M. Sanz February 2008 ASCII HTML 17 dreg iris domain registry

This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. [STANDARDS-TRACK]

draft-ietf-crisp-iris-dchk-09 PROPOSED STANDARD PROPOSED STANDARD IETF app crisp http://www.rfc-editor.org/errata_search.php?rfc=5144 10.17487/RFC5144
RFC5145 Framework for MPLS-TE to GMPLS Migration K. Shiomoto Editor March 2008 ASCII HTML 19 multiprotocol label switching traffic engineering control plane

The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.

This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. This memo provides information for the Internet community.

draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5145
RFC5146 Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks K. Kumaki Editor March 2008 ASCII HTML 15 multiprotocol label switching traffic engineering service provider requirements

Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. This memo provides information for the Internet community.

draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5146
RFC5147 URI Fragment Identifiers for the text/plain Media Type E. Wilde M. Duerst April 2008 ASCII HTML 17 uniform resource identifier mime entity

This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. [STANDARDS-TRACK]

draft-wilde-text-fragment-09 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5147
RFC5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove B. Adamson February 2008 ASCII HTML 12 randomly modifying timing control traffic transmission tranmission collision

This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. This memo provides information for the Internet community.

draft-ietf-manet-jitter-04 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5148 10.17487/RFC5148
RFC5149 Service Selection for Mobile IPv6 J. Korhonen U. Nilsson V. Devarapalli February 2008 ASCII HTML 9 mipv6 service selection mobility option proxy mobile ipv6 mobilty service subscription binding registration procedure

In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This memo provides information for the Internet community.

draft-korhonen-mip6-service-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5149
RFC5150 Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) A. Ayyangar K. Kompella JP. Vasseur A. Farrel February 2008 ASCII HTML 19 lsp label switched paths e2e lsp lsp stitching lsp segments s-lsp

In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).

This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.

It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]

draft-ietf-ccamp-lsp-stitching-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5150 10.17487/RFC5150
RFC5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions A. Farrel Editor A. Ayyangar JP. Vasseur February 2008 ASCII HTML 25 multiprotocol label switching mpls-te

This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.

For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]

draft-ietf-ccamp-inter-domain-rsvp-te-07 RFC3209 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5151 10.17487/RFC5151
RFC5152 A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) JP. Vasseur Editor A. Ayyangar Editor R. Zhang February 2008 ASCII HTML 21 mpls gmpls

This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.

Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. [STANDARDS-TRACK]

draft-ietf-ccamp-inter-domain-pd-path-comp-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5152
RFC5153 IP Flow Information Export (IPFIX) Implementation Guidelines E. Boschi L. Mark J. Quittek M. Stiemerling P. Aitken April 2008 ASCII HTML 35 template mangaement exporting processes collecting processes ipfix middleboxes

The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). This memo provides information for the Internet community.

draft-ietf-ipfix-implementation-guidelines-08 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5153 10.17487/RFC5153
RFC5154 IP over IEEE 802.16 Problem Statement and Goals J. Jee Editor S. Madanapalli J. Mandin April 2008 ASCII HTML 14 WiMAX Mobile WiMAX WiBro

This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. This memo provides information for the Internet community.

draft-ietf-16ng-ps-goals-04 INFORMATIONAL INFORMATIONAL IETF int 16ng 10.17487/RFC5154
RFC5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence B. Laurie G. Sisson R. Arends D. Blacka March 2008 ASCII HTML 52 domain name system nsec resource record nsec3

The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]

draft-ietf-dnsext-nsec3-13 RFC6840 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5155 10.17487/RFC5155
RFC5156 Special-Use IPv6 Addresses M. Blanchet April 2008 ASCII HTML 7 invalid routing prefix

This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets. It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. This memo provides information for the Internet community.

draft-ietf-v6ops-rfc3330-for-ipv6-04 RFC6890 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5156
RFC5157 IPv6 Implications for Network Scanning T. Chown March 2008 ASCII HTML 13 subnet address space

The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community.

draft-ietf-v6ops-scanning-implications-04 RFC7707 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5157
RFC5158 6to4 Reverse DNS Delegation Specification G. Huston March 2008 ASCII HTML 12 dns domain name system

This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block. This memo provides information for the Internet community.

draft-huston-6to4-reverse-dns-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5158 10.17487/RFC5158
RFC5159 Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection L. Dondeti Editor A. Jerichow March 2008 ASCII HTML 8 SDP IANA registration OMA BCAST

This document provides descriptions of Session Description Protocol (SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. This memo provides information for the Internet community.

draft-dondeti-oma-mmusic-sdp-attrs-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5159
RFC5160 Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) P. Levis M. Boucadair March 2008 ASCII HTML 19 sls bgp peering diffserv parallel internet

This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. This memo provides information for the Internet community.

draft-levis-provider-qos-agreement-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5160
RFC5161 The IMAP ENABLE Extension A. Gulbrandsen Editor A. Melnikov Editor March 2008 ASCII HTML 7 Internet Message Access Protocol

Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK]

draft-gulbrandsen-imap-enable-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5161
RFC5162 IMAP4 Extensions for Quick Mailbox Resynchronization A. Melnikov D. Cridland C. Wilson March 2008 ASCII HTML 23 Internet Message Access Protocol

This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). [STANDARDS-TRACK]

draft-ietf-lemonade-reconnect-client-06 RFC7162 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5162 10.17487/RFC5162
RFC5163 Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) G. Fairhurst B. Collini-Nocker April 2008 ASCII HTML 18 digital video broadcasting dvb mpeg-2 ts-concat pdu-concat timestamp

This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.

The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. [STANDARDS-TRACK]

draft-ietf-ipdvb-ule-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ipdvb 10.17487/RFC5163
RFC5164 Mobility Services Transport: Problem Statement T. Melia Editor March 2008 ASCII HTML 16 intelligent access selection ip handover mechanism

There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem. This memo provides information for the Internet community.

draft-ietf-mipshop-mis-ps-05 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5164
RFC5165 A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) C. Reed April 2008 ASCII HTML 7 location geospatial namespace OGC URN Open Geospatial Consortium

This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace IDentifier (NID) is "ogc". This memo provides information for the Internet community.

draft-creed-ogc-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5165
RFC5166 Metrics for the Evaluation of Congestion Control Mechanisms S. Floyd Editor March 2008 ASCII HTML 23 transport protocol transport modeling research group tmrg

This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.

This document is a product of the Transport Modeling Research Group (TMRG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade-offs between a range of metrics, rather than in terms of optimizing for a single metric. This memo provides information for the Internet community.

draft-irtf-tmrg-metrics-11 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5166
RFC5167 Media Server Control Protocol Requirements M. Dolly R. Even March 2008 ASCII HTML 9 logical entities mcp interactive voice response conferencing media services

This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.

This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community.

draft-ietf-mediactrl-requirements-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5167
RFC5168 XML Schema for Media Control O. Levin R. Even P. Hagendorf March 2008 ASCII HTML 10 extensible markup language video fast update

This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. This memo provides information for the Internet community.

draft-levin-mmusic-xml-media-control-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5168
RFC5169 Handover Key Management and Re-Authentication Problem Statement T. Clancy M. Nakhjiri V. Narayanan L. Dondeti March 2008 ASCII HTML 15 hokey handover key management fast re-authentication mobility

This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. This memo provides information for the Internet community.

draft-ietf-hokey-reauth-ps-09 INFORMATIONAL INFORMATIONAL IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5169 10.17487/RFC5169
RFC5170 Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes V. Roca C. Neumann D. Furodet June 2008 ASCII HTML 33 LDPC FEC

This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-ldpc-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5170
RFC5171 Cisco Systems UniDirectional Link Detection (UDLD) Protocol M. Foschiano April 2008 ASCII HTML 13 Ethernet switches LAN IEEE 802 spanning tree STP FEFI autonegotiation

This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.

This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. This memo provides information for the Internet community.

draft-foschiano-udld-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5171
RFC5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol S. Varada Editor March 2008 ASCII HTML 7 IPv6-PPP internet protocol point-to-point ipv6

The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.

This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. [STANDARDS-TRACK]

draft-ietf-ipv6-compression-nego-v2-02 RFC2472 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5172
RFC5173 Sieve Email Filtering: Body Extension J. Degener P. Guenther April 2008 ASCII HTML 10 search full text email

This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. [STANDARDS-TRACK]

draft-ietf-sieve-body-09 RFC5229 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5173
RFC5174 A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU) J-P. Evain May 2008 ASCII HTML 8 EBU namespace urn broadcast metadata classification schema

This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. This memo provides information for the Internet community.

draft-evain-ebu-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5174
RFC5175 IPv6 Router Advertisement Flags Option B. Haberman Editor R. Hinden March 2008 ASCII HTML 7 neighbor discovery protocol ndp expanded flags option efo ndp router advertisement message

The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. [STANDARDS-TRACK]

RFC5075 PROPOSED STANDARD PROPOSED STANDARD IETF int ipv6 10.17487/RFC5175
RFC5176 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) M. Chiba G. Dommety M. Eklund D. Mitton B. Aboba January 2008 ASCII HTML 34 user session

This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community.

draft-ietf-radext-rfc3576bis-13 RFC3576 RFC8559 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5176 10.17487/RFC5176
RFC5177 Network Mobility (NEMO) Extensions for Mobile IPv4 K. Leung G. Dommety V. Narayanan A. Petrescu April 2008 ASCII HTML 26 NEMOv4 Mobile Networks Moving Networks Mobile Router Local Fixed Node Prefix Table Mobile Network Prefix Nested Mobile Networks Nested Network Mobility

This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function.

Extensions to Mobile IPv4 are introduced to support Mobile Networks. [STANDARDS-TRACK]

draft-ietf-mip4-nemo-v4-base-11 RFC6626 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5177
RFC5178 Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type N. Williams A. Melnikov May 2008 ASCII HTML 9 domain-based-name gss-domain-based-services GSS_C_NT_DOMAINBASED_SERVICE

This document describes domain-name-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.

Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-domain-based-names-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5178
RFC5179 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism N. Williams May 2008 ASCII HTML 5 domain-name-based GSS_C_NT_DOMAINBASED_SERVICE

This document describes the mapping of Generic Security Service Application Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. [STANDARDS-TRACK]

draft-ietf-kitten-krb5-gssapi-domain-based-names-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5179
RFC5180 IPv6 Benchmarking Methodology for Network Interconnect Devices C. Popoviciu A. Hamza G. Van de Velde D. Dugatkin May 2008 ASCII HTML 20 rfc2544 ipv6 benchmarking guidelines

The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. This memo provides information for the Internet community.

draft-ietf-bmwg-ipv6-meth-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5180 10.17487/RFC5180
RFC5181 IPv6 Deployment Scenarios in 802.16 Networks M-K. Shin Editor Y-H. Han S-E. Kim D. Premec May 2008 ASCII HTML 16 Ethernet CS (Convergence Sublayer) IPv6 CS (Convergence Sublayer)

This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. This memo provides information for the Internet community.

draft-ietf-v6ops-802-16-deployment-scenarios-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5181
RFC5182 IMAP Extension for Referencing the Last SEARCH Result A. Melnikov March 2008 ASCII HTML 13 uid unique identifier searchres internet message access protocol

Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.

This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.

This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]

draft-melnikov-imap-search-res-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5182
RFC5183 Sieve Email Filtering: Environment Extension N. Freed May 2008 ASCII HTML 10 vnd

This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. [STANDARDS-TRACK]

draft-freed-sieve-environment-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5183
RFC5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover F. Teraoka K. Gogo K. Mitsuya R. Shibui K. Mitani May 2008 ASCII HTML 29 l2 triggers primitives l3-driven fast handover ip mobility optimizations mobopts

This document proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. This document defines nine kinds of L2 abstractions in the form of "primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-mobopts-l2-abstractions-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5184
RFC5185 OSPF Multi-Area Adjacency S. Mirtorabi P. Psenak A. Lindem Editor A. Oswal May 2008 ASCII HTML 11 open shortest path first inter-area intra-area path

This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. [STANDARDS-TRACK]

draft-ietf-ospf-multi-area-adj-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5185 10.17487/RFC5185
RFC5186 Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction B. Haberman J. Martin May 2008 ASCII HTML 6 source information source-filtering group management

The definitions of the Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols. This memo provides information for the Internet community.

draft-ietf-magma-igmpv3-and-routing-05 INFORMATIONAL INFORMATIONAL IETF int magma 10.17487/RFC5186
RFC5187 OSPFv3 Graceful Restart P. Pillay-Esnault A. Lindem June 2008 ASCII HTML 7 open shortest path first

This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-graceful-restart-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5187 10.17487/RFC5187
RFC5188 RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec H. Desineni Q. Xie February 2008 ASCII HTML 25

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and updates the media type registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as email. [STANDARDS-TRACK]

draft-ietf-avt-rtp-evrc-wb-09 RFC4788 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5188
RFC5189 Middlebox Communication (MIDCOM) Protocol Semantics M. Stiemerling J. Quittek T. Taylor March 2008 ASCII HTML 70 nat network address translator firewall

This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989. [STANDARDS-TRACK]

draft-ietf-midcom-rfc3989-bis-02 RFC3989 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5189
RFC5190 Definitions of Managed Objects for Middlebox Communication J. Quittek M. Stiemerling P. Srisuresh March 2008 ASCII HTML 92 management information base mib midcom MIDCOM-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. [STANDARDS-TRACK]

draft-ietf-midcom-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv midcom 10.17487/RFC5190
RFC5191 Protocol for Carrying Authentication for Network Access (PANA) D. Forsberg Y. Ohba Editor B. Patil H. Tschofenig A. Yegin May 2008 ASCII HTML 46 eap exensible authentication protocol

This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. [STANDARDS-TRACK]

draft-ietf-pana-pana-18 RFC5872 PROPOSED STANDARD PROPOSED STANDARD IETF int pana http://www.rfc-editor.org/errata_search.php?rfc=5191 10.17487/RFC5191
RFC5192 DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents L. Morand A. Yegin S. Kumar S. Madanapalli May 2008 ASCII HTML 8 dynamic host configuration protocol pac pana client

This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs. [STANDARDS-TRACK]

draft-ietf-dhc-paa-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5192
RFC5193 Protocol for Carrying Authentication for Network Access (PANA) Framework P. Jayaraman R. Lopez Y. Ohba Editor M. Parthasarathy A. Yegin May 2008 ASCII HTML 11

This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments. This memo provides information for the Internet community.

draft-ietf-pana-framework-10 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5193
RFC5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) A. van Wijk Editor G. Gybels Editor June 2008 ASCII HTML 31 text telephone textphone deaf hard-of-hearing speech-impaired interactive text transcoding speech-to-text user alerting emergency services gateway analog terminal adapters PSTN interworking text presentation user alerting instant messaging conversation conversational text interactivity total conversation user requirements text gateway relay relay service text relay TTY text transport text interworking combination gateway

This document lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks. This memo provides information for the Internet community.

draft-ietf-sipping-toip-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5194
RFC5195 BGP-Based Auto-Discovery for Layer-1 VPNs H. Ould-Brahim D. Fedyk Y. Rekhter June 2008 ASCII HTML 10 import route target l1vpn single-end provisioning

The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached to Customer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections. One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. [STANDARDS-TRACK]

draft-ietf-l1vpn-bgp-auto-discovery-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn 10.17487/RFC5195
RFC5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) M. Lonnfors K. Kiss September 2008 ASCII HTML 30 common presence data format cpp common profile for presence

Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities. [STANDARDS-TRACK]

draft-ietf-simple-prescaps-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5196
RFC5197 On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions S. Fries D. Ignjatic June 2008 ASCII HTML 31 key management media stream security end-to-end SRTP

Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for \%real-time applications. In particular, it has been defined focusing on the support of the Secure \%Real-time Transport Protocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.

This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session Description Protocol (SDP) answer, forking, and shared key conferencing. This memo provides information for the Internet community.

draft-ietf-msec-mikey-applicability-09 INFORMATIONAL INFORMATIONAL IETF sec msec 10.17487/RFC5197
RFC5198 Unicode Format for Network Interchange J. Klensin M. Padlipsky March 2008 ASCII HTML 19 internationalized utf-8

The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]

draft-klensin-net-utf8-09 RFC0698 RFC0854 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5198 10.17487/RFC5198
RFC5199 RFC5200 RFC5201 Host Identity Protocol R. Moskowitz P. Nikander P. Jokela Editor T. Henderson April 2008 ASCII HTML 104 hip ip-layer state integrity protection optional encryption

This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-base-10 RFC7401 RFC6253 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5201 10.17487/RFC5201
RFC5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz P. Nikander April 2008 ASCII HTML 30 user data packets

This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-esp-06 RFC7402 EXPERIMENTAL EXPERIMENTAL IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=5202 10.17487/RFC5202
RFC5203 Host Identity Protocol (HIP) Registration Extension J. Laganier T. Koponen L. Eggert April 2008 ASCII HTML 13 register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-registration-02 RFC8003 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5203
RFC5204 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert April 2008 ASCII HTML 15 hip registration extension hip nodes hip redezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-rvs-05 RFC8004 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5204
RFC5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions P. Nikander J. Laganier April 2008 ASCII HTML 17 hip host identity protocol host identity payload dns domain name system

This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-dns-09 RFC8005 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5205
RFC5206 End-Host Mobility and Multihoming with the Host Identity Protocol P. Nikander T. Henderson Editor C. Vogt J. Arkko April 2008 ASCII HTML 40 hip multihoming extensions mobility extentions locator

This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-hip-mm-05 RFC8046 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5206
RFC5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication M. Stiemerling J. Quittek L. Eggert April 2008 ASCII HTML 13 HIP host identity protocol host identity payload NAT traversal middlebox traversal firewall traversal ID locator split problem statement

The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. This memo provides information for the Internet community.

draft-irtf-hiprg-nat-04 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5207
RFC5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 B. Kaliski May 2008 ASCII HTML 8 rsa laboratories private-key syntax change control

This document represents a republication of PKCS #8 v1.2 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.

This document describes a syntax for private-key information. This memo provides information for the Internet community.

draft-kaliski-pkcs8-00 RFC5958 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5208 10.17487/RFC5208
RFC5209 Network Endpoint Assessment (NEA): Overview and Requirements P. Sangster H. Khosravi M. Mani K. Narayan J. Tardo June 2008 ASCII HTML 53 Posture Remediation reassessment Validator Collector Broker compliance privacy disclosure replay trust policy

This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community.

draft-ietf-nea-requirements-07 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC5209
RFC5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience J. Wu J. Bi X. Li G. Ren K. Xu M. Williams June 2008 ASCII HTML 25 Source Address Validation Source Addressing Spoofing Network Security Testbed IPv6

Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet with IP source address validation, a prototype implementation of the IP Source Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. This memo defines an Experimental Protocol for the Internet community.

draft-wu-sava-testbed-experience-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5210
RFC5211 An Internet Transition Plan J. Curran July 2008 ASCII HTML 8

This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantly IPv6-based connectivity model. This memo provides information for the Internet community.

draft-jcurran-v6transitionplan-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5211
RFC5212 Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) K. Shiomoto D. Papadimitriou JL. Le Roux M. Vigoureux D. Brungard July 2008 ASCII HTML 28 generalized mpls switching technology

Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.

In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-mln-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5212
RFC5213 Proxy Mobile IPv6 S. Gundavelli Editor K. Leung V. Devarapalli K. Chowdhury B. Patil August 2008 ASCII HTML 92 mobility management

Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. [STANDARDS-TRACK]

draft-ietf-netlmm-proxymip6-18 RFC6543 RFC7864 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5213 10.17487/RFC5213
RFC5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin T. Gleeson D. Thaler March 2008 ASCII HTML 15 ipv6 ipv4 non-broadcast multiple access nbma dual-stack

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. This memo provides information for the Internet community.

draft-templin-rfc4214bis-05 RFC4214 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5214
RFC5215 RTP Payload Format for Vorbis Encoded Audio L. Barbato August 2008 ASCII HTML 26 realtime transport protocol codebook

This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.

Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-rtp-vorbis-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5215 10.17487/RFC5215
RFC5216 The EAP-TLS Authentication Protocol D. Simon B. Aboba R. Hurst March 2008 ASCII HTML 34 extensible authentication protocol point-to-point link control compression extensible transport level security

The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.

This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]

draft-simon-emu-rfc2716bis-13 RFC2716 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu http://www.rfc-editor.org/errata_search.php?rfc=5216 10.17487/RFC5216
RFC5217 Memorandum for Multi-Domain Public Key Infrastructure Interoperability M. Shimaoka Editor N. Hastings R. Nielsen July 2008 ASCII HTML 29 pki multi-domain pki pki domain

The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public Key Infrastructure (PKI) domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI. This memo provides information for the Internet community.

draft-shimaoka-multidomain-pki-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5217
RFC5218 What Makes for a Successful Protocol? D. Thaler B. Aboba July 2008 ASCII HTML 28

The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community.

draft-iab-protocol-success-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5218
RFC5219 A More Loss-Tolerant RTP Payload Format for MP3 Audio R. Finlayson February 2008 ASCII HTML 22 real time protocol real-time protocol mpeg moving picture experts group,

This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. [STANDARDS-TRACK]

draft-ietf-avt-rfc3119bis-05 RFC3119 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5219
RFC5220 Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII HTML 17 multiple prefixes

A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. This memo provides information for the Internet community.

draft-ietf-v6ops-addr-select-ps-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5220 10.17487/RFC5220
RFC5221 Requirements for Address Selection Mechanisms A. Matsumoto T. Fujisaki R. Hiromi K. Kanayama July 2008 ASCII HTML 7 default address selection

There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems. This memo provides information for the Internet community.

draft-ietf-v6ops-addr-select-req-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5221
RFC5222 LoST: A Location-to-Service Translation Protocol T. Hardie A. Newton H. Schulzrinne H. Tschofenig August 2008 ASCII HTML 69 emergency services emergency call routing

This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]

draft-ietf-ecrit-lost-10 RFC6848 RFC8917 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5222 10.17487/RFC5222
RFC5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) H. Schulzrinne J. Polk H. Tschofenig August 2008 ASCII HTML 8 mapping service emergency service emergency communication

The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.

This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). [STANDARDS-TRACK]

draft-ietf-ecrit-dhc-lost-discovery-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5223
RFC5224 Diameter Policy Processing Application M. Brenner March 2008 ASCII HTML 5 policy evaluation or evaluation and enforcement pem-1 peem oma open mobile alliance

This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement). This application is needed as one of the implementations of the Open Mobile Alliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing. This memo provides information for the Internet community.

draft-brenner-dime-peem-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5224
RFC5225 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite G. Pelletier K. Sandlund April 2008 ASCII HTML 124 rohc 3095 3843 4019

This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers.

This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.

The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. [STANDARDS-TRACK]

draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5225 10.17487/RFC5225
RFC5226 Guidelines for Writing an IANA Considerations Section in RFCs T. Narten H. Alvestrand May 2008 ASCII HTML 27 internet assigned numbers authority values implementations code point protocol constant protocol parameter

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).

In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.

This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-narten-iana-considerations-rfc2434bis-09 RFC2434 RFC8126 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5226 10.17487/RFC5226
RFC5227 IPv4 Address Conflict Detection S. Cheshire July 2008 ASCII HTML 21 internet protocol version 4

When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. [STANDARDS-TRACK]

draft-cheshire-ipv4-acd-06 RFC0826 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5227
RFC5228 Sieve: An Email Filtering Language P. Guenther Editor T. Showalter Editor January 2008 ASCII HTML 42

This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. [STANDARDS-TRACK]

draft-ietf-sieve-3028bis-13 RFC3028 RFC5229 RFC5429 RFC6785 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5228 10.17487/RFC5228
RFC5229 Sieve Email Filtering: Variables Extension K. Homme January 2008 ASCII HTML 11

In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. [STANDARDS-TRACK]

draft-ietf-sieve-variables-08 RFC5228 RFC5173 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5229 10.17487/RFC5229
RFC5230 Sieve Email Filtering: Vacation Extension T. Showalter N. Freed Editor January 2008 ASCII HTML 16 autoresponder

This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. [STANDARDS-TRACK]

draft-ietf-sieve-vacation-06 RFC8580 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5230 10.17487/RFC5230
RFC5231 Sieve Email Filtering: Relational Extension W. Segmuller B. Leiba January 2008 ASCII HTML 9 relational operators

This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.

This document obsoletes RFC 3431. [STANDARDS-TRACK]

draft-ietf-sieve-3431bis-04 RFC3431 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5231
RFC5232 Sieve Email Filtering: Imap4flags Extension A. Melnikov January 2008 ASCII HTML 12 imap internet message access control protocol imap flags imap system flags imap keywords

Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent.

This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. [STANDARDS-TRACK]

draft-ietf-sieve-imapflags-05 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5232 10.17487/RFC5232
RFC5233 Sieve Email Filtering: Subaddress Extension K. Murchison January 2008 ASCII HTML 7 subaddressing detailed addressing :user :detail

On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address. [STANDARDS-TRACK]

draft-ietf-sieve-rfc3598bis-05 RFC3598 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5233 10.17487/RFC5233
RFC5234 Augmented BNF for Syntax Specifications: ABNF D. Crocker Editor P. Overell January 2008 ASCII HTML 16 ABNF backus-naur form augmented backus-naur form rule definitions encoding core lexical analyzer

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]

draft-crocker-rfc4234bis-01 RFC4234 RFC7405 STD0068 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5234 10.17487/RFC5234
RFC5235 Sieve Email Filtering: Spamtest and Virustest Extensions C. Daboo January 2008 ASCII HTML 13 spamtest spamtestplus virustest scores

The Sieve email filtering language "spamtest", "spamtestplus", and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests. [STANDARDS-TRACK]

draft-ietf-sieve-spamtestbis-05 RFC3685 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5235
RFC5236 Improved Packet Reordering Metrics A. Jayasumana N. Piratla T. Banka A. Bare R. Whitner June 2008 ASCII HTML 26 reorder density rd reorder buffer-occupancy density rbd

This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.

These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. This memo provides information for the Internet community.

draft-jayasumana-reorder-density-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5236
RFC5237 IANA Allocation Guidelines for the Protocol Field J. Arkko S. Bradner February 2008 ASCII HTML 5 ipv4 header next header field internet assigned numbers authority IP

This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-arkko-rfc2780-proto-update-02 RFC2780 BCP0037 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5237 10.17487/RFC5237
RFC5238 Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) T. Phelan May 2008 ASCII HTML 10 tls transport protocol

This document specifies the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. [STANDARDS-TRACK]

draft-ietf-dccp-dtls-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5238
RFC5239 A Framework for Centralized Conferencing M. Barnes C. Boulton O. Levin June 2008 ASCII HTML 57 call signaling call signalling

This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS-TRACK]

draft-ietf-xcon-framework-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=5239 10.17487/RFC5239
RFC5240 Protocol Independent Multicast (PIM) Bootstrap Router MIB B. Joshi R. Bijlani June 2008 ASCII HTML 23 management information base bootstrap router bsr PIM-BSR-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). [STANDARDS-TRACK]

draft-ietf-pim-bsr-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5240 10.17487/RFC5240
RFC5241 Naming Rights in IETF Protocols A. Falk S. Bradner April 1 2008 ASCII HTML 12 april fools field naming rights

This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5241
RFC5242 A Generalized Unified Character Code: Western European and CJK Sections J. Klensin H. Alvestrand April 1 2008 ASCII HTML 14 idn latin greek cyrilllic chinese internationalized domain names

Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. This memo provides information for the Internet community.

INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5242
RFC5243 OSPF Database Exchange Summary List Optimization R. Ogier May 2008 ASCII HTML 5

This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. This memo provides information for the Internet community.

draft-ogier-ospf-dbex-opt-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5243 10.17487/RFC5243
RFC5244 Definition of Events for Channel-Oriented Telephony Signalling H. Schulzrinne T. Taylor June 2008 ASCII HTML 23 event code telephony event rtp payload

This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section 3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833. [STANDARDS-TRACK]

draft-ietf-avt-rfc2833biscas-05 RFC4733 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5244
RFC5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols J. Rosenberg April 2010 ASCII HTML 117

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]

draft-ietf-mmusic-ice-19 RFC4091 RFC4092 RFC8445 RFC6336 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5245 10.17487/RFC5245
RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2 T. Dierks E. Rescorla August 2008 ASCII HTML 104 idea international data algorithm symmetric transport protocol layer authentication privacy

This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]

draft-ietf-tls-rfc4346-bis-10 RFC3268 RFC4346 RFC4366 RFC8446 RFC4492 RFC5746 RFC5878 RFC6176 RFC7465 RFC7507 RFC7568 RFC7627 RFC7685 RFC7905 RFC7919 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5246 10.17487/RFC5246
RFC5247 Extensible Authentication Protocol (EAP) Key Management Framework B. Aboba D. Simon P. Eronen August 2008 ASCII HTML 79 extensible network access authentication key hierarchy methods

The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. [STANDARDS-TRACK]

draft-ietf-eap-keying-22 RFC3748 RFC8940 PROPOSED STANDARD PROPOSED STANDARD IETF int eap http://www.rfc-editor.org/errata_search.php?rfc=5247 10.17487/RFC5247
RFC5248 A Registry for SMTP Enhanced Mail System Status Codes T. Hansen J. Klensin June 2008 ASCII HTML 11 simple mail transfer protocol

The specification for enhanced mail system status codes, RFC 3463, establishes a new code model and lists a collection of status codes. While it anticipated that more codes would be added over time, it did not provide an explicit mechanism for registering and tracking those codes. This document specifies an IANA registry for mail system enhanced status codes, and initializes that registry with the codes so far established in published standards-track documents, as well as other codes that have become established in the industry. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-hansen-4468upd-mailesc-registry-05 RFC3463 RFC4468 RFC4954 BCP0138 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5248
RFC5249 Templates for Internet-Drafts Containing MIB Modules D. Harrington Editor July 2008 ASCII HTML 4 network management management information base mib smiv2 template

This memo references three annotated templates for IETF documents that contain the definition of MIB modules. It is intended to reduce the work of the editors of such documents, making these documents more uniform and easier to read and review, thus furthering the quality of such documents and expediting their publication. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-harrington-text-mib-doc-template-06 BCP0139 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5249
RFC5250 The OSPF Opaque LSA Option L. Berger I. Bryskin A. Zinin R. Coltun July 2008 ASCII HTML 17 OSPF-LSA] open shortest path first link state advertisement opaque lsas

This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.

This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK]

draft-ietf-ospf-rfc2370bis-05 RFC2370 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5250 10.17487/RFC5250
RFC5251 Layer 1 VPN Basic Mode D. Fedyk Editor Y. Rekhter Editor D. Papadimitriou R. Rabbat L. Berger July 2008 ASCII HTML 24 virtual private network l1vpn l1vpn bm

This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. [STANDARDS-TRACK]

draft-ietf-l1vpn-basic-mode-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5251 10.17487/RFC5251
RFC5252 OSPF-Based Layer 1 VPN Auto-Discovery I. Bryskin L. Berger July 2008 ASCII HTML 11 open shortest path first l1vpn layer 1 virtual private network

This document defines an Open Shortest Path First (OSPF) based Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations with L1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. [STANDARDS-TRACK]

draft-ietf-l1vpn-ospf-auto-discovery-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l1vpn http://www.rfc-editor.org/errata_search.php?rfc=5252 10.17487/RFC5252
RFC5253 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode T. Takeda Editor July 2008 ASCII HTML 19 gmpls generalized multiprotocol label switching l1vpn bm

This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs).

L1VPNs provide customer services and connectivity at Layer 1 over Layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. This memo provides information for the Internet community.

draft-ietf-l1vpn-applicability-basic-mode-05 INFORMATIONAL INFORMATIONAL IETF rtg l1vpn 10.17487/RFC5253
RFC5254 Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) N. Bitar Editor M. Bocci Editor L. Martini Editor October 2008 ASCII HTML 27 Pseudowire PWE3 multi-segment MS-PW SS-PW S-PE T-PE

This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. This memo provides information for the Internet community.

draft-ietf-pwe3-ms-pw-requirements-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5254 10.17487/RFC5254
RFC5255 Internet Message Access Protocol Internationalization C. Newman A. Gulbrandsen A. Melnikov June 2008 ASCII HTML 20 imap imapv4 imap4

Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. [STANDARDS-TRACK]

draft-ietf-imapext-i18n-15 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5255 10.17487/RFC5255
RFC5256 Internet Message Access Protocol - SORT and THREAD Extensions M. Crispin K. Murchison June 2008 ASCII HTML 19 ordered subject references imap capability

This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]

draft-ietf-imapext-sort-20 RFC5957 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5256
RFC5257 Internet Message Access Protocol - ANNOTATE Extension C. Daboo R. Gellens June 2008 ASCII HTML 31 imap

The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.

Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-imapext-annotate-16 EXPERIMENTAL EXPERIMENTAL IETF app imapext http://www.rfc-editor.org/errata_search.php?rfc=5257 10.17487/RFC5257
RFC5258 Internet Message Access Protocol version 4 - LIST Command Extensions B. Leiba A. Melnikov June 2008 ASCII HTML 31 imap4 ,list lsub extended list email

IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK]

draft-ietf-imapext-list-extensions-18 PROPOSED STANDARD PROPOSED STANDARD IETF app imapext 10.17487/RFC5258
RFC5259 Internet Message Access Protocol - CONVERT Extension A. Melnikov Editor P. Coates Editor July 2008 ASCII HTML 30 IMAP Lemonade CONVERT conversion transcoding

CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. [STANDARDS-TRACK]

draft-ietf-lemonade-convert-20 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5259
RFC5260 Sieve Email Filtering: Date and Index Extensions N. Freed July 2008 ASCII HTML 13 smtp esmtp date index

This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. [STANDARDS-TRACK]

draft-freed-sieve-date-index-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5260 10.17487/RFC5260
RFC5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors J. Urpalainen September 2008 ASCII HTML 40

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic &lt;add&gt;, &lt;replace&gt;, and &lt;remove&gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]

draft-ietf-simple-xml-patch-ops-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5261 10.17487/RFC5261
RFC5262 Presence Information Data Format (PIDF) Extension for Partial Presence M. Lonnfors E. Leppanen H. Khartabil J. Urpalainen September 2008 ASCII HTML 16

The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. [STANDARDS-TRACK]

draft-ietf-simple-partial-pidf-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5262
RFC5263 Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information M. Lonnfors J. Costa-Requena E. Leppanen H. Khartabil September 2008 ASCII HTML 16 pidf presence information data format

By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. [STANDARDS-TRACK]

draft-ietf-simple-partial-notify-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5263
RFC5264 Publication of Partial Presence Information A. Niemi M. Lonnfors E. Leppanen September 2008 ASCII HTML 15

The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. [STANDARDS-TRACK]

draft-ietf-simple-partial-publish-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5264
RFC5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways S. Vaarala E. Klovning June 2008 ASCII HTML 39 mobile ip mobile ipv4 ipsec mipv4

This document outlines a solution for the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. [STANDARDS-TRACK]

draft-ietf-mip4-vpn-problem-solution-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC5265
RFC5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) V. Devarapalli P. Eronen June 2008 ASCII HTML 15

Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-mip4-mobike-connectivity-03 BCP0136 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int mip4 10.17487/RFC5266
RFC5267 Contexts for IMAP4 D. Cridland C. King July 2008 ASCII HTML 18 imap4rev1 esort context

The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. [STANDARDS-TRACK]

draft-cridland-imap-context-05 RFC5465 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5267
RFC5268 Mobile IPv6 Fast Handovers R. Koodli Editor June 2008 ASCII HTML 48 mipv6 handover latency

Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, and Binding Update, is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. [STANDARDS-TRACK]

draft-ietf-mipshop-fmipv6-rfc4068bis-07 RFC4068 RFC5568 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5268
RFC5269 Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) J. Kempf R. Koodli June 2008 ASCII HTML 14 fast binding update

Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the Mobile Node is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as for SEND (RFC 3971). The Mobile Node sends the public key to the Access Router. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use the Router Solicitation for Proxy Advertisement and Proxy Router Advertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node. This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. [STANDARDS-TRACK]

draft-ietf-mipshop-handover-key-03 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5269
RFC5270 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks H. Jang J. Jee Y. Han S. Park J. Cha June 2008 ASCII HTML 18 Mobile IPv6 Handover optimization Cross-layer design

This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently. This memo provides information for the Internet community.

draft-ietf-mipshop-fh80216e-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5270
RFC5271 Mobile IPv6 Fast Handovers for 3G CDMA Networks H. Yokota G. Dommety June 2008 ASCII HTML 22 FMIP handoff 3GPP2

Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a new Care-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. This memo provides information for the Internet community.

draft-ietf-mipshop-3gfh-07 INFORMATIONAL INFORMATIONAL IETF int mipshop 10.17487/RFC5271
RFC5272 Certificate Management over CMS (CMC) J. Schaad M. Myers June 2008 ASCII HTML 83 certificate management protocol cryptographic message syntax pki public key infrastructure

This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:

1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and

2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.

CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]

draft-ietf-pkix-2797-bis-07 RFC2797 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5272 10.17487/RFC5272
RFC5273 Certificate Management over CMS (CMC): Transport Protocols J. Schaad M. Myers June 2008 ASCII HTML 7 cryptographic message syntax http file mail tcp

This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]

draft-ietf-pkix-cmc-trans-08 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5273 10.17487/RFC5273
RFC5274 Certificate Management Messages over CMS (CMC): Compliance Requirements J. Schaad M. Myers June 2008 ASCII HTML 13 cryptographic message syntax cmc enrollment protocol

This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. [STANDARDS-TRACK]

draft-ietf-pkix-cmc-compl-05 RFC6402 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5274
RFC5275 CMS Symmetric Key Management and Distribution S. Turner June 2008 ASCII HTML 89 cryptographic message syntax symmetric cryptographic algorithms certificate management over cms cmc

This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses the Cryptographic Message Syntax (CMS) protocol and Certificate Management over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose Internet Mail Extensions (S/MIME) Mail List Agents (MLAs). [STANDARDS-TRACK]

draft-ietf-smime-symkeydist-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5275 10.17487/RFC5275
RFC5276 Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records C. Wallace August 2008 ASCII HTML 13 ERS Evidence Record SCVP Server-based Certificate Validation Protocol PKI artifact preservation

The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). [STANDARDS-TRACK]

draft-ietf-ltans-ers-scvp-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5276
RFC5277 NETCONF Event Notifications S. Chisholm H. Trevino July 2008 ASCII HTML 35 XML Extensible Markup Language NETCONF Event Asynchronous Message Notification

This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS-TRACK]

draft-ietf-netconf-notification-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5277
RFC5278 IANA Registration of Enumservices for Voice and Video Messaging J. Livingood D. Troshynski July 2008 ASCII HTML 22 vmsg voicemsg videomsg unifmsg sip sips http https tel

This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. [STANDARDS-TRACK]

draft-ietf-enum-vmsg-02 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5278
RFC5279 A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP) A. Monrad S. Loreto July 2008 ASCII HTML 7 nid namespace identifier 3gpp

This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. This memo provides information for the Internet community.

draft-monrad-sipping-3gpp-urn-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5279 10.17487/RFC5279
RFC5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile D. Cooper S. Santesson S. Farrell S. Boeyen R. Housley W. Polk May 2008 ASCII HTML 151 X.509 v3 X.509 v2 certificate extensions

This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]

draft-ietf-pkix-rfc3280bis-11 RFC3280 RFC4325 RFC4630 RFC6818 RFC8398 RFC8399 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5280 10.17487/RFC5280
RFC5281 Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) P. Funk S. Blake-Wilson August 2008 ASCII HTML 51 EAP AAA Authentication TLS

EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.

draft-funk-eap-ttls-v0-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5281 10.17487/RFC5281
RFC5282 Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol D. Black D. McGrew August 2008 ASCII HTML 19 encryption cipher combined mode algorithms aes gcm advanced encryption standard in galois/counter mode aes ccm aes in couner with cbc-mac mode

An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol.

The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK]

draft-black-ipsec-ikev2-aead-modes-01 RFC4306 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5282 10.17487/RFC5282
RFC5283 LDP Extension for Inter-Area Label Switched Paths (LSPs) B. Decraene JL. Le Roux I. Minei July 2008 ASCII HTML 12 LDP label mapping procedures longest-match prefix aggregation

To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP).

This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-interarea-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5283 10.17487/RFC5283
RFC5284 User-Defined Errors for RSVP G. Swallow A. Farrel August 2008 ASCII HTML 9 resource reservation protocol user_error_spec error_spec

The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.

This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-user-error-spec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5284
RFC5285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni July 2008 ASCII HTML 17 real-time transport protocol extmap

This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]

draft-ietf-avt-rtp-hdrext-15 RFC8285 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5285
RFC5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates A. Atlas Editor A. Zinin Editor September 2008 ASCII HTML 31 FRR LFA recovery failure routing

This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK]

draft-ietf-rtgwg-ipfrr-spec-base-12 RFC8518 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=5286 10.17487/RFC5286
RFC5287 Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks A. Vainshtein Y(J). Stein August 2008 ASCII HTML 16 pwe3 pseudowire emulation edge-to-edge tdmoip tdm options

This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. [STANDARDS-TRACK]

draft-ietf-pwe3-tdm-control-protocol-extensi-07 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5287
RFC5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS J. Salowey A. Choudhury D. McGrew August 2008 ASCII HTML 8 advanced encryption standard transport layer security data origin confidentiality

This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms. [STANDARDS-TRACK]

draft-ietf-tls-rsa-aes-gcm-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5288 10.17487/RFC5288
RFC5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) E. Rescorla August 2008 ASCII HTML 6 transport layer security mac algorithm

RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). This memo provides information for the Internet community.

draft-ietf-tls-ecc-new-mac-07 PROPOSED STANDARD INFORMATIONAL IETF sec tls 10.17487/RFC5289
RFC5290 Comments on the Usefulness of Simple Best-Effort Traffic S. Floyd M. Allman July 2008 ASCII HTML 20 flow-rate fairness

This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path. This memo provides information for the Internet community.

draft-floyd-tsvwg-besteffort-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5290
RFC5291 Outbound Route Filtering Capability for BGP-4 E. Chen Y. Rekhter August 2008 ASCII HTML 12 border gatway protocol orf

This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]

draft-ietf-idr-route-filter-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5291 10.17487/RFC5291
RFC5292 Address-Prefix-Based Outbound Route Filter for BGP-4 E. Chen S. Sangli August 2008 ASCII HTML 6 orf border gateway protocol Address Prefix Outbound Route Filter

This document defines a new Outbound Router Filter (ORF) type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. [STANDARDS-TRACK]

draft-ietf-idr-bgp-prefix-orf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5292
RFC5293 Sieve Email Filtering: Editheader Extension J. Degener P. Guenther August 2008 ASCII HTML 9 addheadaer deleteheader

This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. [STANDARDS-TRACK]

draft-ietf-sieve-editheader-11 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5293
RFC5294 Host Threats to Protocol Independent Multicast (PIM) P. Savola J. Lingard August 2008 ASCII HTML 12 security threat analysis

This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts. This memo provides information for the Internet community.

draft-ietf-pim-lasthop-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC5294
RFC5295 Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) J. Salowey L. Dondeti V. Narayanan M. Nakhjiri August 2008 ASCII HTML 21 EAP keying EMSK DSRK DSUSRK Domain-Specific Key Derivation Usage-Specific Key Derivation

The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. [STANDARDS-TRACK]

draft-ietf-hokey-emsk-hierarchy-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5295 10.17487/RFC5295
RFC5296 EAP Extensions for EAP Re-authentication Protocol (ERP) V. Narayanan L. Dondeti August 2008 ASCII HTML 43 extensible authentication protocol authentication modes

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]

draft-ietf-hokey-erx-14 RFC6696 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5296 10.17487/RFC5296
RFC5297 Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) D. Harkins October 2008 ASCII HTML 26 authenticated encryption key wrapping key derivation block cipher pseudo-random function

This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. This memo provides information for the Internet community.

draft-dharkins-siv-aes-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5297
RFC5298 Analysis of Inter-Domain Label Switched Path (LSP) Recovery T. Takeda Editor A. Farrel Editor Y. Ikejiri JP. Vasseur August 2008 ASCII HTML 26 mpls gmpls multi-domain environment end-to-end diverse Traffic Engineering LSPs

Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.

Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering".

This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. This memo provides information for the Internet community.

draft-ietf-ccamp-inter-domain-recovery-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5298 10.17487/RFC5298
RFC5299 RFC5300 RFC5301 Dynamic Hostname Exchange Mechanism for IS-IS D. McPherson N. Shen October 2008 ASCII HTML 6 intermediate system to intermediate system routers tlv name-to-systemID

RFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.

This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]

draft-ietf-isis-rfc2763bis-00 RFC2763 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5301 10.17487/RFC5301
RFC5302 Domain-Wide Prefix Distribution with Two-Level IS-IS T. Li H. Smit T. Przygienda October 2008 ASCII HTML 16 intermediate system to intermediate system routers loops IP internet protocol

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.

This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. [STANDARDS-TRACK]

draft-ietf-isis-rfc2966bis-03 RFC2966 RFC1195 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5302 10.17487/RFC5302
RFC5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies D. Katz R. Saluja D. Eastlake 3rd October 2008 ASCII HTML 11 intermediate system to intermediate system

The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.

Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.

This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. [STANDARDS-TRACK]

draft-ietf-isis-rfc3373bis-01 RFC3373 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5303 10.17487/RFC5303
RFC5304 IS-IS Cryptographic Authentication T. Li R. Atkinson October 2008 ASCII HTML 11 intermediate system to intermediate system IS-IS authentication MD5 HMAC-MD5 security routing iso international standards organization

This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.

This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]

draft-ietf-isis-rfc3567bis-03 RFC3567 RFC1195 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5304
RFC5305 IS-IS Extensions for Traffic Engineering T. Li H. Smit October 2008 ASCII HTML 17 intermediate system to intermediate system te router lsp data units link state protocol data units

This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]

draft-ietf-isis-te-bis-00 RFC3784 RFC5307 RFC8918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5305
RFC5306 Restart Signaling for IS-IS M. Shand L. Ginsberg October 2008 ASCII HTML 22 intermediate system to intermediate system LSP database synchronization Link State Routing

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. [STANDARDS-TRACK]

draft-ietf-isis-rfc3847bis-00 RFC3847 RFC8706 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5306
RFC5307 IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) K. Kompella Editor Y. Rekhter Editor October 2008 ASCII HTML 12 intermediate system to intermediate system

This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]

draft-ietf-isis-rfc4205bis-00 RFC4205 RFC5305 RFC6001 RFC6002 RFC7074 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5307 10.17487/RFC5307
RFC5308 Routing IPv6 with IS-IS C. Hopps October 2008 ASCII HTML 7 intermediate system to intermediate system tlv osi

This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]

draft-ietf-isis-ipv6-07 RFC7775 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5308
RFC5309 Point-to-Point Operation over LAN in Link State Routing Protocols N. Shen Editor A. Zinin Editor October 2008 ASCII HTML 10 broadcast

The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. This memo provides information for the Internet community.

draft-ietf-isis-igp-p2p-over-lan-06 INFORMATIONAL INFORMATIONAL IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5309 10.17487/RFC5309
RFC5310 IS-IS Generic Cryptographic Authentication M. Bhatia V. Manral T. Li R. Atkinson R. White M. Fanto February 2009 ASCII HTML 12 IS-IS Security HMAC-SHA Cryptographic Authentication

This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.

Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]

draft-ietf-isis-hmac-sha-07 RFC6233 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=5310 10.17487/RFC5310
RFC5311 Simplified Extension of Link State PDU (LSP) Space for IS-IS D. McPherson Editor L. Ginsberg S. Previdi M. Shand February 2009 ASCII HTML 12

This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]

draft-ietf-isis-wg-extlsp-05 RFC3786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC5311
RFC5312 RFC5313 RFC5314 RFC5315 RFC5316 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan December 2008 ASCII HTML 19 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te flooding

This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

draft-ietf-ccamp-isis-interas-te-extension-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5316
RFC5317 Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile S. Bryant Editor L. Andersson Editor February 2009 ASCII PDF HTML 10 ITU-T MPLS-TP JWT GMPLS agreement PWE3 OAM transport network

This RFC archives the report of the IETF - ITU-T Joint Working Team (JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM (Operations, Administration, and Management), survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). This memo provides information for the Internet community.

draft-bryant-mpls-tp-jwt-report-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5317 10.17487/RFC5317
RFC5318 The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) J. Hautakorpi G. Camarillo December 2008 ASCII HTML 12 oma open mobile alliance push to talk over cellular poc

This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list. This memo provides information for the Internet community.

draft-hautakorpi-sipping-uri-list-handling-refused-03 RFC8217 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5318 10.17487/RFC5318
RFC5319 RFC5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL) F. Templin Editor February 2010 ASCII HTML 29 virtual topologies mtu maximum transmission units

For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. This document defines an Experimental Protocol for the Internet community.

draft-templin-seal-23 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5320 10.17487/RFC5320
RFC5321 Simple Mail Transfer Protocol J. Klensin October 2008 ASCII HTML 95 SMTP]

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]

draft-klensin-rfc2821bis-11 RFC2821 RFC1123 RFC7504 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5321 10.17487/RFC5321
RFC5322 Internet Message Format P. Resnick Editor October 2008 ASCII HTML 57 MAIL] e-mail email electronic mail header address mailbox reply forward resend resent folding Date From Sender Reply-To To Cc Bcc Message-ID In-Reply-To References Subject Comments Keywords Resent-Date Resent-From Resent-Sender Resent-To Resent-Cc Resent-Bcc Resent-Reply-To Resent-Message-ID Return-Path Received

This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]

draft-resnick-2822upd-06 RFC2822 RFC4021 RFC6854 DRAFT STANDARD DRAFT STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5322 10.17487/RFC5322
RFC5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH J. Reschke Editor S. Reddy J. Davis A. Babich November 2008 ASCII HTML 49 HTTP Query Properties

This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. [STANDARDS-TRACK]

draft-reschke-webdav-search-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5323
RFC5324 MIB for Fibre-Channel Security Protocols (FC-SP) C. DeSanti F. Maino K. McCloghrie September 2008 ASCII HTML 216 management information base T11-FC-SP-TC-MIB T11-FC-SP-AUTHENTICATION-MIB T11-FC-SP-ZONING-MIB T11-FC-SP-POLICY-MIB T11-FC-SP-SA-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. [STANDARDS-TRACK]

draft-ietf-imss-fc-fcsp-mib-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops imss 10.17487/RFC5324
RFC5325 Licklider Transmission Protocol - Motivation S. Burleigh M. Ramadas S. Farrell September 2008 ASCII HTML 23 ltp round-trip times long-haul

This document describes the motivation for the development of the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-ltp-motivation-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5325
RFC5326 Licklider Transmission Protocol - Specification M. Ramadas S. Burleigh S. Farrell September 2008 ASCII HTML 54 ltp round-trip times rtt long-haul

This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-ltp-10 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5326 10.17487/RFC5326
RFC5327 Licklider Transmission Protocol - Security Extensions S. Farrell M. Ramadas S. Burleigh September 2008 ASCII HTML 11 ltp radio frequency automatic repeat request arq

The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-ltp-extensions-08 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5327
RFC5328 A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) A. Adolf P. MacAvock September 2008 ASCII HTML 12 tv television digital television mpeg-2 iptv multimedia content guide program guide metadata

This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. This memo provides information for the Internet community.

draft-adolf-dvb-urn-05 RFC7354 RFC8553 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5328 10.17487/RFC5328
RFC5329 Traffic Engineering Extensions to OSPF Version 3 K. Ishiguro V. Manral A. Davey A. Lindem Editor September 2008 ASCII HTML 12 open shortest path first ospfv3 te

This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-traffic-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5329
RFC5330 A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link JP. Vasseur Editor M. Meyer K. Kumaki A. Bonda October 2008 ASCII HTML 8 te lsp

Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth (referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. [STANDARDS-TRACK]

draft-ietf-mpls-number-0-bw-te-lsps-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5330
RFC5331 MPLS Upstream Label Assignment and Context-Specific Label Space R. Aggarwal Y. Rekhter E. Rosen August 2008 ASCII HTML 13 upstream-assigned mpls labels

RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]

draft-ietf-mpls-upstream-label-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5331 10.17487/RFC5331
RFC5332 MPLS Multicast Encapsulations T. Eckert E. Rosen Editor R. Aggarwal Y. Rekhter August 2008 ASCII HTML 11 data link layer codepoint multiaccess media upstream-assigned label mac da medium access layer destination address

RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".

RFC 3032 does not specify the destination address to be placed in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.

This document updates RFC 3032 and RFC 4023. [STANDARDS-TRACK]

draft-ietf-mpls-multicast-encaps-10 RFC3032 RFC4023 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5332
RFC5333 IANA Registration of Enumservices for Internet Calendaring R. Mahy B. Hoeneisen October 2009 ASCII HTML 8 ENUM iCal iMIP i TIP CalDAV

This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV). [STANDARDS-TRACK]

draft-ietf-enum-calendar-service-04 RFC6118 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC5333
RFC5334 Ogg Media Types I. Goncalves S. Pfeiffer C. Montgomery September 2008 ASCII HTML 14 Ogg MIME Video Audio Codecs

This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534. [STANDARDS-TRACK]

draft-goncalves-rfc3534bis-07 RFC3534 RFC7845 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5334
RFC5335 Internationalized Email Headers A. Yang Editor September 2008 ASCII HTML 14 unicode utf-8

Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-utf8headers-12 RFC6532 RFC2045 RFC2822 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5335 10.17487/RFC5335
RFC5336 SMTP Extension for Internationalized Email Addresses J. Yao Editor W. Mao Editor September 2008 ASCII HTML 22 EAI UTF8SMTP MAIL TRANSFER

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-smtpext-13 RFC6531 RFC2821 RFC2822 RFC4952 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5336 10.17487/RFC5336
RFC5337 Internationalized Delivery Status and Disposition Notifications C. Newman A. Melnikov Editor September 2008 ASCII HTML 18 EAI DSN SMTP

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-dsn-06 RFC6533 RFC3461 RFC3462 RFC3464 RFC3798 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5337 10.17487/RFC5337
RFC5338 Using the Host Identity Protocol with Legacy Applications T. Henderson P. Nikander M. Komu September 2008 ASCII HTML 14 hip cryptographic name space network stack names api application programming interface

This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. This memo provides information for the Internet community.

draft-ietf-hip-applications-04 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5338
RFC5339 Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) JL. Le Roux Editor D. Papadimitriou Editor September 2008 ASCII HTML 25 general multiprotocol label switching

This document provides an evaluation of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-Region Networks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. This memo provides information for the Internet community.

draft-ietf-ccamp-gmpls-mln-eval-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5339 10.17487/RFC5339
RFC5340 OSPF for IPv6 R. Coltun D. Ferguson J. Moy A. Lindem July 2008 ASCII HTML 94 open shortest path first ospfv3

This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).

Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).

Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.

All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-update-23 RFC2740 RFC6845 RFC6860 RFC7503 RFC8362 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5340 10.17487/RFC5340
RFC5341 The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry C. Jennings V. Gurbani September 2008 ASCII HTML 7 uniform resource locator schemes

This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. [STANDARDS-TRACK]

draft-ietf-iptel-tel-reg-06 RFC3966 PROPOSED STANDARD PROPOSED STANDARD IETF rai iptel 10.17487/RFC5341
RFC5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters D. Eastlake 3rd September 2008 ASCII HTML 21 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-eastlake-ethernet-iana-considerations-08 RFC7042 RFC2153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5342
RFC5343 Simple Network Management Protocol (SNMP) Context EngineID Discovery J. Schoenwaelder September 2008 ASCII HTML 9 snmpv3 snmpengineid localengineid

The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.

This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.

This document updates RFC 3411. [STANDARDS-TRACK]

draft-ietf-opsawg-snmp-engineid-discovery-03 RFC3411 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5343
RFC5344 Presence and Instant Messaging Peering Use Cases A. Houri E. Aoki S. Parameswar October 2008 ASCII HTML 9 non-voip collaboration service instant messaging im

This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). This memo provides information for the Internet community.

draft-ietf-speermint-consolidated-presence-im-usecases-05 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5344
RFC5345 Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats J. Schoenwaelder October 2008 ASCII HTML 23 large-scale snmp irtf nmrg network management research group

The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.

This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.

This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group. This memo provides information for the Internet community.

draft-irtf-nmrg-snmp-measure-06 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5345 10.17487/RFC5345
RFC5346 Operational Requirements for ENUM-Based Softswitch Use J. Lim W. Kim C. Park L. Conroy October 2008 ASCII HTML 14 Applications ENUM DNS E.164 NAPTR Softswitch Field Trial

This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.

These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. This memo provides information for the Internet community.

draft-ietf-enum-softswitch-req-04 INFORMATIONAL INFORMATIONAL IETF rai enum http://www.rfc-editor.org/errata_search.php?rfc=5346 10.17487/RFC5346
RFC5347 Media Gateway Control Protocol Fax Package F. Andreasen D. Hancock October 2008 ASCII HTML 46 mgcp fax calls fax relay fax transmission

This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. This memo provides information for the Internet community.

draft-andreasen-mgcp-fax-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5347 10.17487/RFC5347
RFC5348 TCP Friendly Rate Control (TFRC): Protocol Specification S. Floyd M. Handley J. Padhye J. Widmer September 2008 ASCII HTML 58 tcp-friendly rate control congestion control

This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.

This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]

draft-ietf-dccp-rfc3448bis-06 RFC3448 RFC4342 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5348 10.17487/RFC5348
RFC5349 Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) L. Zhu K. Jaganathan K. Lauter September 2008 ASCII HTML 10 ecdh elliptic curve diffie-hellman

This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.

draft-zhu-pkinit-ecc-04 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5349
RFC5350 IANA Considerations for the IPv4 and IPv6 Router Alert Options J. Manner A. McDonald September 2008 ASCII HTML 8

This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. [STANDARDS-TRACK]

draft-manner-router-alert-iana-03 RFC2113 RFC3175 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5350
RFC5351 An Overview of Reliable Server Pooling Protocols P. Lei L. Ong M. Tuexen T. Dreibholz September 2008 ASCII HTML 15 rserpool

The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community.

draft-ietf-rserpool-overview-06 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5351
RFC5352 Aggregate Server Access Protocol (ASAP) R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII HTML 53 rserpool enrp endpoint handlespace redundancy protocol

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.

In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.

ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-asap-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5352
RFC5353 Endpoint Handlespace Redundancy Protocol (ENRP) Q. Xie R. Stewart M. Stillman M. Tuexen A. Silverton September 2008 ASCII HTML 39 rserpool asap aggregate server access protocol fault-tolerant registry

The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-enrp-21 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5353
RFC5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters R. Stewart Q. Xie M. Stillman M. Tuexen September 2008 ASCII HTML 23 rserpool

This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-common-param-18 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5354
RFC5355 Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats M. Stillman Editor R. Gopal E. Guttman S. Sengodan M. Holdrege September 2008 ASCII HTML 19

Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community.

draft-ietf-rserpool-threats-15 INFORMATIONAL INFORMATIONAL IETF tsv rserpool 10.17487/RFC5355
RFC5356 Reliable Server Pooling Policies T. Dreibholz M. Tuexen September 2008 ASCII HTML 16 rserpool enrp endpoint handlespace redundancy protocol

This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-policies-10 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5356
RFC5357 A Two-Way Active Measurement Protocol (TWAMP) K. Hedayat R. Krzanowski A. Morton K. Yum J. Babiarz October 2008 ASCII HTML 26 two-way measaurement round-trip measurement

The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK]

draft-ietf-ippm-twamp-09 RFC5618 RFC5938 RFC6038 RFC7717 RFC7750 RFC8545 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5357 10.17487/RFC5357
RFC5358 Preventing Use of Recursive Nameservers in Reflector Attacks J. Damas F. Neves October 2008 ASCII HTML 7 denial of service dos

This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsop-reflectors-are-evil-06 BCP0140 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC5358
RFC5359 Session Initiation Protocol Service Examples A. Johnston Editor R. Sparks C. Cunningham S. Donovan K. Summers October 2008 ASCII HTML 170 sip pbx centrex features hold transfer forwarding screening park pickup redial click call flows

This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-service-examples-15 BCP0144 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5359
RFC5360 A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) J. Rosenberg G. Camarillo Editor D. Willis October 2008 ASCII HTML 31

SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. [STANDARDS-TRACK]

draft-ietf-sip-consent-framework-04 RFC8217 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5360 10.17487/RFC5360
RFC5361 A Document Format for Requesting Consent G. Camarillo October 2008 ASCII HTML 14 xml extensible markup language premission document

This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. [STANDARDS-TRACK]

draft-ietf-sipping-consent-format-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5361
RFC5362 The Session Initiation Protocol (SIP) Pending Additions Event Package G. Camarillo October 2008 ASCII HTML 16 consent-related resource list

This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. [STANDARDS-TRACK]

draft-ietf-sipping-pending-additions-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5362
RFC5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services G. Camarillo A.B. Roach October 2008 ASCII HTML 10

This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. [STANDARDS-TRACK]

draft-ietf-sipping-uri-services-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5363
RFC5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists M. Garcia-Martin G. Camarillo October 2008 ASCII HTML 17 XML copy control resource list

In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. [STANDARDS-TRACK]

draft-ietf-sipping-capacity-attribute-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5364
RFC5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) M. Garcia-Martin G. Camarillo October 2008 ASCII HTML 18 user agent client uac sip message request uniform resource identifier list message uri list

This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]

draft-ietf-sip-uri-list-message-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5365
RFC5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) G. Camarillo A. Johnston October 2008 ASCII HTML 13 sip uri list invite-contatined uri

This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]

draft-ietf-sip-uri-list-conferencing-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5366
RFC5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) G. Camarillo A.B. Roach O. Levin October 2008 ASCII HTML 9 subscribe request resrouce list

This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog. [STANDARDS-TRACK]

draft-ietf-sip-uri-list-subscribe-02 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5367
RFC5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP) G. Camarillo A. Niemi M. Isomaki M. Garcia-Martin H. Khartabil October 2008 ASCII HTML 13 sip refer refer-to multipler-refer

This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]

draft-ietf-sip-multiple-refer-03 RFC8262 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5368
RFC5369 Framework for Transcoding with the Session Initiation Protocol (SIP) G. Camarillo October 2008 ASCII HTML 10 transcoding services conference bridge model third-party call control model deaf hard of hearing speech-impaired

This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. This memo provides information for the Internet community.

draft-ietf-sipping-transc-framework-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5369
RFC5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model G. Camarillo October 2008 ASCII HTML 11 transcoding service deaf hard of hearing speech-impaired

This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. [STANDARDS-TRACK]

draft-ietf-sipping-transc-conf-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5370
RFC5371 RTP Payload Format for JPEG 2000 Video Streams S. Futemma E. Itakura A. Leung October 2008 ASCII HTML 31 JPEG 2000 video RTP Real-time Transport Protocol main header tile number Sony Corporation

This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. [STANDARDS-TRACK]

draft-ietf-avt-rtp-jpeg2000-20 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5371
RFC5372 Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery A. Leung S. Futemma E. Itakura October 2008 ASCII HTML 26 Real-time Transport Protocol main header compensation priority field priority mapping table packet-number-based ordering progression-based ordering layer-based ordering resolution-based ordering component-based ordering Sony Corporation

This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.

This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document. [STANDARDS-TRACK]

draft-ietf-avt-rtp-jpeg2000-beam-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5372
RFC5373 Requesting Answering Modes for the Session Initiation Protocol (SIP) D. Willis Editor A. Allen November 2008 ASCII HTML 24 PoC PTT auto automatic manual answer loopback diagnostic answer-mode priv-answer-mode

This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS-TRACK]

draft-ietf-sip-answermode-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5373
RFC5374 Multicast Extensions to the Security Architecture for the Internet Protocol B. Weis G. Gross D. Ignjatic November 2008 ASCII HTML 38 ip ipsec ip multicast packets

The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. [STANDARDS-TRACK]

draft-ietf-msec-ipsec-extensions-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC5374
RFC5375 IPv6 Unicast Address Assignment Considerations G. Van de Velde C. Popoviciu T. Chown O. Bonness C. Hahn December 2008 ASCII HTML 35 internet protocol version 6 address architecture

One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. This memo provides information for the Internet community.

draft-ietf-v6ops-addcon-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=5375 10.17487/RFC5375
RFC5376 Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) N. Bitar R. Zhang K. Kumaki November 2008 ASCII HTML 14 PCE PCECP inter-AS PCE inter-provider PCE inter-AS MPLS-TE inter-provider MPLS-TE inter-AS PCECP inter-provider PCECP GMPLS path computation MPLS-TE path computation path computation element path computation communication protocol path computing element Interas Interas TE

Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.

The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCE Communication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as between PCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS TE. This memo provides information for the Internet community.

draft-ietf-pce-interas-pcecp-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5376
RFC5377 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents J. Halpern Editor November 2008 ASCII HTML 8 contributors ietf contributions outbound rights

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This memo provides information for the Internet community.

draft-ietf-ipr-outbound-rights-07 RFC8721 INFORMATIONAL INFORMATIONAL IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=5377 10.17487/RFC5377
RFC5378 Rights Contributors Provide to the IETF Trust S. Bradner Editor J. Contreras Editor November 2008 ASCII HTML 16 intellectual property rights copyright ipr

The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ipr-3978-incoming-09 RFC3978 RFC4748 RFC2026 BCP0078 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen ipr http://www.rfc-editor.org/errata_search.php?rfc=5378 10.17487/RFC5378
RFC5379 Guidelines for Using the Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba February 2010 ASCII HTML 23 SIP Privacy priv-value guideline

This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-munakata-sip-privacy-guideline-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5379
RFC5380 Hierarchical Mobile IPv6 (HMIPv6) Mobility Management H. Soliman C. Castelluccia K. ElMalki L. Bellier October 2008 ASCII HTML 26 mobile ipv6 ipv6 neighbor discovery map mobility anchor point

This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. [STANDARDS-TRACK]

draft-ietf-mipshop-4140bis-05 RFC4140 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5380
RFC5381 Experience of Implementing NETCONF over SOAP T. Iijima Y. Atarashi H. Kimura M. Kitani H. Okita October 2008 ASCII HTML 22 simple object access protocol network configuration protocol mns network management system

This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community.

draft-iijima-netconf-soap-implementation-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5381 10.17487/RFC5381
RFC5382 NAT Behavioral Requirements for TCP S. Guha Editor K. Biswas B. Ford S. Sivakumar P. Srisuresh October 2008 ASCII HTML 31 network address translation

This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-tcp-08 RFC7857 BCP0142 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5382
RFC5383 Deployment Considerations for Lemonade-Compliant Mobile Email R. Gellens October 2008 ASCII HTML 12

This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-lemonade-deployments-09 BCP0143 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app lemonade 10.17487/RFC5383
RFC5384 The Protocol Independent Multicast (PIM) Join Attribute Format A. Boers I. Wijnands E. Rosen November 2008 ASCII HTML 10 pim-sm multicast distribution tree pim join attribute attr_type

A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. [STANDARDS-TRACK]

draft-ietf-pim-join-attributes-06 RFC7887 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5384 10.17487/RFC5384
RFC5385 Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs J. Touch February 2010 ASCII HTML 20 writing I-Ds writing RFCs authoring tools document preparation

This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.

The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-touch-msword-template-v2.0-07 RFC3285 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5385 10.17487/RFC5385
RFC5386 Better-Than-Nothing Security: An Unauthenticated Mode of IPsec N. Williams M. Richardson November 2008 ASCII HTML 11 internet protocol security ikev1 ikev2 sas esp ah pad spd btns unauthenticated ipsec

This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). [STANDARDS-TRACK]

draft-ietf-btns-core-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5386 10.17487/RFC5386
RFC5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) J. Touch D. Black Y. Wang November 2008 ASCII HTML 28 ipsec stand-alone btns sab channel-bound btns cbb

The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.

This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security" (BTNS). The extensions may be used on their own (this use is called Stand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. This memo provides information for the Internet community.

draft-ietf-btns-prob-and-applic-07 INFORMATIONAL INFORMATIONAL IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5387 10.17487/RFC5387
RFC5388 Information Model and XML Data Model for Traceroute Measurements S. Niccolini S. Tartarelli J. Quittek T. Dietz M. Swany December 2008 ASCII HTML 75 extensible markup language DISMAN-TRACEROUTE-MIB

This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. [STANDARDS-TRACK]

draft-ietf-ippm-storetraceroutes-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5388
RFC5389 Session Traversal Utilities for NAT (STUN) J. Rosenberg R. Mahy P. Matthews D. Wing October 2008 ASCII HTML 51 SIPs NAT STUN Traversal ICE firewall TURN VOIP

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.

This document obsoletes RFC 3489. [STANDARDS-TRACK]

draft-ietf-behave-rfc3489bis-18 RFC3489 RFC8489 RFC7350 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5389 10.17487/RFC5389
RFC5390 Requirements for Management of Overload in the Session Initiation Protocol J. Rosenberg December 2008 ASCII HTML 14 sip overload handling 503 response

Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. This memo provides information for the Internet community.

draft-ietf-sipping-overload-reqs-05 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5390
RFC5391 RTP Payload Format for ITU-T Recommendation G.711.1 A. Sollaud November 2008 ASCII HTML 14 real-time transport protocol itu telecommunication standardization sector audio coded pcmu-wb pcma-wb

This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g711wb-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5391
RFC5392 OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering M. Chen R. Zhang X. Duan January 2009 ASCII HTML 17 multiprotocol label switching generalized mpls gmpls-te mpls-te isis-te open shortest path first ospf-te

This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.

No support for flooding information from within one AS to another AS is proposed or defined in this document. [STANDARDS-TRACK]

draft-ietf-ccamp-ospf-interas-te-extension-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5392
RFC5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies R. Sparks Editor S. Lawrence A. Hawrylyshen B. Campen December 2008 ASCII HTML 20 SIP application-layer application layer multimedia multicast unicast

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.

This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS-TRACK]

draft-ietf-sip-fork-loop-fix-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5393
RFC5394 Policy-Enabled Path Computation Framework I. Bryskin D. Papadimitriou L. Berger J. Ash December 2008 ASCII HTML 36 PCE pce policy

The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. This memo provides information for the Internet community.

draft-ietf-pce-policy-enabled-path-comp-04 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5394
RFC5395 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd November 2008 ASCII HTML 17 RRTYPE RCODE AFSDB

Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsext-2929bis-07 RFC2929 RFC6195 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=5395 10.17487/RFC5395
RFC5396 Textual Representation of Autonomous System (AS) Numbers G. Huston G. Michaelson December 2008 ASCII HTML 3 decimal value

A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. [STANDARDS-TRACK]

draft-ietf-idr-as-representation-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC5396
RFC5397 WebDAV Current Principal Extension W. Sanchez C. Daboo December 2008 ASCII HTML 5 http webdav access control acl authentication

This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. [STANDARDS-TRACK]

draft-sanchez-webdav-current-principal-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5397
RFC5398 Autonomous System (AS) Number Reservation for Documentation Use G. Huston December 2008 ASCII HTML 4 autonomous system numbers asn

To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of Autonomous System numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. This memo provides information for the Internet community.

draft-ietf-idr-as-documentation-reservation-00 INFORMATIONAL INFORMATIONAL IETF rtg idr 10.17487/RFC5398
RFC5399 RFC5400 RFC5401 Multicast Negative-Acknowledgment (NACK) Building Blocks B. Adamson C. Bormann M. Handley J. Macker November 2008 ASCII HTML 42

This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. [STANDARDS-TRACK]

draft-ietf-rmt-bb-norm-revised-07 RFC3941 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5401
RFC5402 Compressed Data within an Internet Electronic Data Interchange (EDI) Message T. Harding Editor February 2010 ASCII HTML 7 internet edi

This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ediint-compression-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5402
RFC5403 RPCSEC_GSS Version 2 M. Eisler February 2009 ASCII HTML 14 Kerberos ONC RPC security authentication integrity GSS GSS-API privacy confidentiality encryption MIC NFS credential verifier mechanism context

This document describes version 2 of the RPCSEC_GSS protocol. Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic Security Services Application Programming Interface (GSS-API). [STANDARDS-TRACK]

draft-ietf-nfsv4-rpcsec-gss-v2-06 RFC2203 RFC7861 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5403
RFC5404 RTP Payload Format for G.719 M. Westerlund I. Johansson January 2009 ASCII HTML 27 ITU-T g.719 full-band codec

This document specifies the payload format for packetization of the G.719 full-band codec encoded audio signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. [STANDARDS-TRACK]

draft-ietf-avt-rtp-g719-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5404 10.17487/RFC5404
RFC5405 Unicast UDP Usage Guidelines for Application Designers L. Eggert G. Fairhurst November 2008 ASCII HTML 27 user datagram protocol congestion control

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of unicast applications and upper-layer protocols. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, and middlebox traversal. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-tsvwg-udp-guidelines-11 RFC8085 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC5405
RFC5406 Guidelines for Specifying the Use of IPsec Version 2 S. Bellovin February 2009 ASCII HTML 13 internet security security considerations

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-bellovin-useipsec-10 BCP0146 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5406
RFC5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) M. Hasebe J. Koshiko Y. Suzuki T. Yoshikawa P. Kyzivat December 2008 ASCII HTML 60 sip user agents sip ua sip proxy servers

This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-race-examples-06 BCP0147 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai sipping 10.17487/RFC5407
RFC5408 Identity-Based Encryption Architecture and Supporting Data Structures G. Appenzeller L. Martin M. Schertler January 2009 ASCII HTML 30 public key public-key encryption technology

This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. This memo provides information for the Internet community.

draft-ietf-smime-ibearch-09 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5408 10.17487/RFC5408
RFC5409 Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS) L. Martin M. Schertler January 2009 ASCII HTML 13 bf bbq content-encryption keys

This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. This memo provides information for the Internet community.

draft-ietf-smime-bfibecms-10 INFORMATIONAL INFORMATIONAL IETF sec smime 10.17487/RFC5409
RFC5410 Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 A. Jerichow Editor L. Piron January 2009 ASCII HTML 7 MIKEY Extension IANA registration OMA BCAST draft-jerichow-msec-mikey-genext-oma-00 RFC4909 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5410 RFC5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP) J. Rosenberg February 2009 ASCII HTML 39 42 don't panic sip overview,

The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. This memo provides information for the Internet community.

draft-ietf-sip-hitchhikers-guide-06 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5411
RFC5412 Lightweight Access Point Protocol P. Calhoun R. Suri N. Cam-Winget M. Williams S. Hares B. O'Hara S. Kelly February 2010 ASCII HTML 125 lwapp capwap

In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller.

The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. This document defines a Historic Document for the Internet community.

draft-ohara-capwap-lwapp-04 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5412 10.17487/RFC5412
RFC5413 SLAPP: Secure Light Access Point Protocol P. Narasimhan D. Harkins S. Ponnuswamy February 2010 ASCII HTML 75 capwap

The Control and Provisioning of Wireless Access Points (CAPWAP) problem statement describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) that then enables an AC from one vendor to control and manage a WTP from another.

In this document, we present a protocol that forms the common technology-independent framework and the ability to negotiate and add, on top of this framework, a control protocol that contains a technology-dependent component to arrive at a complete solution. We have also presented two such control protocols -- an 802.11 Control protocol, and another, more generic image download protocol, in this document.

Even though the text in this document is written to specifically address the problem stated in RFC 3990, the solution can be applied to any problem that has a controller (equivalent to the AC) managing one or more network elements (equivalent to the WTP). This document defines a Historic Document for the Internet community.

draft-narasimhan-ietf-slapp-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5413
RFC5414 Wireless LAN Control Protocol (WiCoP) S. Iino S. Govindan M. Sugiura H. Cheng February 2010 ASCII HTML 54 wlan wireless local area network twp wireless termination points capwap control and provisioning of wireless access points

The popularity of wireless local area networks (WLANs) has led to widespread deployments across different establishments. It has also translated into an increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common.

The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the Control And Provisioning of Wireless Access Points (CAPWAP). This document defines a Historic Document for the Internet community.

draft-iino-capwap-wicop-02 RFC5415 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC5414
RFC5415 Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII HTML 155 LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. [STANDARDS-TRACK]

draft-ietf-capwap-protocol-specification-15 RFC5414 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5415 10.17487/RFC5415
RFC5416 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 P. Calhoun Editor M. Montemurro Editor D. Stanley Editor March 2009 ASCII HTML 76 Operations and Management LWAPP CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.

This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. [STANDARDS-TRACK]

draft-ietf-capwap-protocol-binding-ieee80211-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap http://www.rfc-editor.org/errata_search.php?rfc=5416 10.17487/RFC5416
RFC5417 Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option P. Calhoun March 2009 ASCII HTML 6 CAPWAP 802.11 IEEE Wireless LAN WiFi Access Point Access Controller Wireless Termination Point

The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. [STANDARDS-TRACK]

draft-ietf-capwap-dhc-ac-option-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops capwap 10.17487/RFC5417
RFC5418 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments S. Kelly T. Clancy March 2009 ASCII HTML 34 WLAN security

Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a \%stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. This memo provides information for the Internet community.

draft-ietf-capwap-threat-analysis-04 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5418
RFC5419 Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) B. Patil G. Dommety January 2009 ASCII HTML 19 authentication signaling message mn ha

Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. This memo provides information for the Internet community.

draft-ietf-mip6-whyauthdataoption-07 INFORMATIONAL INFORMATIONAL IETF int mip6 10.17487/RFC5419
RFC5420 Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) A. Farrel Editor D. Papadimitriou JP. Vasseur A. Ayyangar February 2009 ASCII HTML 22 multiprotocol label switching label switched paths SESSION_ATTRIBUTE

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.

This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.

The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.

This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]

draft-ietf-ccamp-rfc4420bis-03 RFC4420 RFC3209 RFC3473 RFC6510 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5420 10.17487/RFC5420
RFC5421 Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget H. Zhou March 2009 ASCII HTML 10 generic token card eap-gtc

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer. This memo provides information for the Internet community.

draft-zhou-emu-fast-gtc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5421
RFC5422 Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) N. Cam-Winget D. McGrew J. Salowey H. Zhou March 2009 ASCII HTML 39

The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP- FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. This memo provides information for the Internet community.

draft-cam-winget-eap-fast-provisioning-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5422
RFC5423 Internet Message Store Events R. Gellens C. Newman March 2009 ASCII HTML 17 imap

One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.

This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. [STANDARDS-TRACK]

draft-ietf-lemonade-msgevent-07 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5423 10.17487/RFC5423
RFC5424 The Syslog Protocol R. Gerhards March 2009 ASCII HTML 38 event notification message syslog message berkeley software distribution transmission messages

This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.

This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]

draft-ietf-syslog-protocol-23 RFC3164 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5424 10.17487/RFC5424
RFC5425 Transport Layer Security (TLS) Transport Mapping for Syslog F. Miao Editor Y. Ma Editor J. Salowey Editor March 2009 ASCII HTML 13 syslog message syslog security

This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. [STANDARDS-TRACK]

draft-ietf-syslog-transport-tls-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog http://www.rfc-editor.org/errata_search.php?rfc=5425 10.17487/RFC5425
RFC5426 Transmission of Syslog Messages over UDP A. Okmianski March 2009 ASCII HTML 9 udp User Datagram Protocol

This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK]

draft-ietf-syslog-transport-udp-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5426
RFC5427 Textual Conventions for Syslog Management G. Keeni March 2009 ASCII HTML 8 syslog facility syslog severity MIB textual-convention

This MIB module defines textual conventions to represent Facility and Severity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-syslog-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5427
RFC5428 Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices S. Channabasappa W. De Ketelaere E. Nechamkin April 2009 ASCII HTML 37 snmp simple network management protocol multimedia terminal adapter PKTC-IETF-EVENT-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. [STANDARDS-TRACK]

draft-ietf-ipcdn-pktc-eventmess-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipcdn 10.17487/RFC5428
RFC5429 Sieve Email Filtering: Reject and Extended Reject Extensions A. Stone Editor March 2009 ASCII HTML 14 sieve refuse reject ereject joe-job smtp lmtp spam

This memo updates the definition of the Sieve mail filtering language "reject" extension, originally defined in RFC 3028.

A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces, Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.

This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the "ereject" action to require messages to be refused during the SMTP transaction, if possible.

The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. [STANDARDS-TRACK]

draft-ietf-sieve-refuse-reject-09 RFC3028 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5429 10.17487/RFC5429
RFC5430 Suite B Profile for Transport Layer Security (TLS) M. Salter E. Rescorla R. Housley March 2009 ASCII HTML 12 nsa suite b cryptography

The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully conformant with Suite B. This document also defines a transitional profile for use with TLS version 1.0 and TLS version 1.1 which employs Suite B algorithms to the greatest extent possible. This memo provides information for the Internet community.

draft-rescorla-tls-suiteb-11 RFC6460 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5430
RFC5431 Diameter ITU-T Rw Policy Enforcement Interface Application D. Sun March 2009 ASCII HTML 5 diameter command code itu-t ITU-T Rw Policy-Install-Request pir Policy-Install-Answer pia

This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). This memo provides information for the Internet community.

draft-sun-dime-itu-t-rw-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5431
RFC5432 Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) J. Polk S. Dhesikan G. Camarillo March 2009 ASCII HTML 9 offer/answer media stream

The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. [STANDARDS-TRACK]

draft-ietf-mmusic-qos-identification-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5432
RFC5433 Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method T. Clancy H. Tschofenig February 2009 ASCII HTML 38 EAP EAP-GPSK pre-shared key

This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS-TRACK]

draft-ietf-emu-eap-gpsk-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC5433
RFC5434 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session T. Narten February 2009 ASCII HTML 13 ietf bof working group

This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]

draft-narten-successful-bof-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5434
RFC5435 Sieve Email Filtering: Extension for Notifications A. Melnikov Editor B. Leiba Editor W. Segmuller T. Martin January 2009 ASCII HTML 17

Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol (XMPP), or Global System for Mobile Communications (GSM) Short Message Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. [STANDARDS-TRACK]

draft-ietf-sieve-notify-12 RFC8580 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5435
RFC5436 Sieve Notification Mechanism: mailto B. Leiba M. Haardt January 2009 ASCII HTML 12 eletctronic mail notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. [STANDARDS-TRACK]

draft-ietf-sieve-notify-mailto-10 RFC3834 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5436
RFC5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre A. Melnikov January 2009 ASCII HTML 14 jabber

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. [STANDARDS-TRACK]

draft-ietf-sieve-notify-xmpp-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5437
RFC5438 Instant Message Disposition Notification (IMDN) E. Burger H. Khartabil February 2009 ASCII HTML 38 im instant messaging cpim common presence and instant messaging

Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.

The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.

This document also describes how SIP entities behave using this extension. [STANDARDS-TRACK]

draft-ietf-simple-imdn-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple http://www.rfc-editor.org/errata_search.php?rfc=5438 10.17487/RFC5438
RFC5439 An Analysis of Scaling Issues in MPLS-TE Core Networks S. Yasukawa A. Farrel O. Komolafe February 2009 ASCII HTML 45 multiprotocol label switching traffic engineered scaling concerns lsp label switch path point-to-point mpls-te lsps

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.

This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.

This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. This memo provides information for the Internet community.

draft-ietf-mpls-te-scaling-analysis-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5439 10.17487/RFC5439
RFC5440 Path Computation Element (PCE) Communication Protocol (PCEP) JP. Vasseur Editor JL. Le Roux Editor March 2009 ASCII HTML 87 MPLS GMPLS Traffic Engineering Label Switched Path

This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]

draft-ietf-pce-pcep-19 RFC7896 RFC8253 RFC8356 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5440 10.17487/RFC5440
RFC5441 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths JP. Vasseur Editor R. Zhang N. Bitar JL. Le Roux April 2009 ASCII HTML 18 te lsp path computation element

The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]

draft-ietf-pce-brpc-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5441 10.17487/RFC5441
RFC5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail E. Burger G. Parsons March 2009 ASCII HTML 15 enhancements to internet email to supportt diverse service environments Phone

This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF. This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service. This memo provides information for the Internet community.

draft-ietf-lemonade-architecture-04 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5442
RFC5443 LDP IGP Synchronization M. Jork A. Atlas L. Fang March 2009 ASCII HTML 7 label distribution protocol interior gateway protocol

In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community.

draft-ietf-mpls-ldp-igp-sync-04 RFC6138 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5443 10.17487/RFC5443
RFC5444 Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format T. Clausen C. Dearlove J. Dean C. Adjih February 2009 ASCII HTML 60 routing TLV address

This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. [STANDARDS-TRACK]

draft-ietf-manet-packetbb-17 RFC7631 RFC8245 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5444 10.17487/RFC5444
RFC5445 Basic Forward Error Correction (FEC) Schemes M. Watson March 2009 ASCII HTML 19 content stream delivery multicast internet protocol

This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-basic-schemes-revised-06 RFC3452 RFC3695 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5445 10.17487/RFC5445
RFC5446 Service Selection for Mobile IPv4 J. Korhonen U. Nilsson February 2009 ASCII HTML 9 internet protocol version 4 host name agent mobility service subscription

In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure. This memo provides information for the Internet community.

draft-korhonen-mip4-service-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5446
RFC5447 Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction J. Korhonen Editor J. Bournelle H. Tschofenig C. Perkins K. Chowdhury February 2009 ASCII HTML 17 Diameter Mobile IPv6 Integrated Scenario

A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS-TRACK]

draft-ietf-dime-mip6-integrated-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5447 10.17487/RFC5447
RFC5448 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') J. Arkko V. Lehtovirta P. Eronen May 2009 ASCII HTML 29 EAP AKA AKA' 3GPP

This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.

This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.

draft-arkko-eap-aka-kdf-10 RFC4187 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5448
RFC5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks E. Baccelli P. Jacquet D. Nguyen T. Clausen February 2009 ASCII HTML 31 open shortest path first interface type mobile ad hoc

This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ospf-manet-mpr-04 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5449 10.17487/RFC5449
RFC5450 Transmission Time Offsets in RTP Streams D. Singer H. Desineni March 2009 ASCII HTML 8 real-time transport IJ inter-arrival jitter

This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK]

draft-ietf-avt-rtp-toffset-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5450
RFC5451 Message Header Field for Indicating Message Authentication Status M. Kucherawy April 2009 ASCII HTML 43 authentication-results email authentication result

This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]

draft-kucherawy-sender-auth-header-20 RFC7001 RFC6577 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5451 10.17487/RFC5451
RFC5452 Measures for Making DNS More Resilient against Forged Answers A. Hubert R. van Mook January 2009 ASCII HTML 18 spoofing source port hardening

The current Internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make 'spoofing' a recursing nameserver many orders of magnitude harder.

Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.

By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. [STANDARDS-TRACK]

draft-ietf-dnsext-forgery-resilience-10 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5452
RFC5453 Reserved IPv6 Interface Identifiers S. Krishnan February 2009 ASCII HTML 6 unicast address

Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. [STANDARDS-TRACK]

draft-ietf-6man-reserved-iids-03 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5453 10.17487/RFC5453
RFC5454 Dual-Stack Mobile IPv4 G. Tsirtsis V. Park H. Soliman March 2009 ASCII HTML 18 ipv6 mipv4

This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. [STANDARDS-TRACK]

draft-ietf-mip4-dsmipv4-10 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5454 10.17487/RFC5454
RFC5455 Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol S. Sivabalan Editor J. Parker S. Boutros K. Kumaki March 2009 ASCII HTML 9 classtype ds-te diffserv-aware traffic engineering pce

This document specifies a CLASSTYPE object to support Diffserv-Aware Traffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). [STANDARDS-TRACK]

draft-ietf-pce-dste-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5455 10.17487/RFC5455
RFC5456 IAX: Inter-Asterisk eXchange Version 2 M. Spencer B. Capouch E. Guy Editor F. Miller K. Shumard February 2010 ASCII HTML 101 asterisk private branch exchange pbx voip voice over internet protocol

This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk Private Branch Exchange (PBX) and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.

IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-guy-iax-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5456
RFC5457 IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 E. Guy Editor February 2010 ASCII HTML 21 asterisk private branch exchange pbx voip voice over internet protocol

This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-guy-iaxiana-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5457 10.17487/RFC5457
RFC5458 Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol H. Cruickshank P. Pillai M. Noisternig S. Iyengar March 2009 ASCII HTML 26 iso 13818-1 transport stream ts ule stream gse generic stream encapsulation

The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC 4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.

The analysis also describes applicability to the Generic Stream Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) Project. This memo provides information for the Internet community.

draft-ietf-ipdvb-sec-req-09 INFORMATIONAL INFORMATIONAL IETF int ipdvb http://www.rfc-editor.org/errata_search.php?rfc=5458 10.17487/RFC5458
RFC5459 G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support A. Sollaud January 2009 ASCII HTML 7 real-time transport protocol rtp itu-t international telecommunication union g.729.1 audio codec

This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) Recommendation G.729.1 audio codec. It adds Discontinuous Transmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. [STANDARDS-TRACK]

draft-ietf-avt-rfc4749-dtx-update-03 RFC4749 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5459
RFC5460 DHCPv6 Bulk Leasequery M. Stapp February 2009 ASCII HTML 18 dynamic hos configuration protocol ipv6 dhcpv6 bindings

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-bulk-leasequery-06 RFC7653 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=5460 10.17487/RFC5460
RFC5461 TCP's Reaction to Soft Errors F. Gont February 2009 ASCII HTML 13 icmp Internet Control Message Protocol

This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. This memo provides information for the Internet community.

draft-ietf-tcpm-tcp-soft-errors-09 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5461
RFC5462 Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field L. Andersson R. Asati February 2009 ASCII HTML 9 exp class of service cos tc field

The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".

Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.

To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]

draft-ietf-mpls-cosfield-def-08 RFC3032 RFC3270 RFC3272 RFC3443 RFC3469 RFC3564 RFC3985 RFC4182 RFC4364 RFC4379 RFC4448 RFC4761 RFC5129 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5462 10.17487/RFC5462
RFC5463 Sieve Email Filtering: Ihave Extension N. Freed March 2009 ASCII HTML 6 SMTP ESMTP

This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. [STANDARDS-TRACK]

draft-freed-sieve-ihave-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5463
RFC5464 The IMAP METADATA Extension C. Daboo February 2009 ASCII HTML 20 internet message access protocol annotation metadata

The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK]

draft-daboo-imap-annotatemore-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5464 10.17487/RFC5464
RFC5465 The IMAP NOTIFY Extension A. Gulbrandsen C. King A. Melnikov February 2009 ASCII HTML 22 Internet Message Access Protocol

This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK]

draft-ietf-lemonade-imap-notify-07 RFC5267 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5465 10.17487/RFC5465
RFC5466 IMAP4 Extension for Named Searches (Filters) A. Melnikov C. King February 2009 ASCII HTML 9 Internet Message Access Protocol

The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. [STANDARDS-TRACK]

draft-melnikov-imapext-filters-08 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5466
RFC5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) L. Berger A. Takacs D. Caviglia D. Fedyk J. Meuric March 2009 ASCII HTML 14 RSVP-TE TSPEC ADSPEC

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ccamp-asymm-bw-bidir-lsps-02 RFC6387 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5467 10.17487/RFC5467
RFC5468 Performance Analysis of Inter-Domain Path Computation Methodologies S. Dasgupta J. de Oliveira JP. Vasseur April 2009 ASCII HTML 10 pce path computation element brpc backward recursive path computation

This document presents a performance comparison between the per-domain path computation method and the Path Computation Element (PCE) Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. This memo provides information for the Internet community.

draft-dasgupta-ccamp-path-comp-analysis-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5468
RFC5469 DES and IDEA Cipher Suites for Transport Layer Security (TLS) P. Eronen Editor February 2009 ASCII HTML 4 ciphersuite data encryption standard international data encryption algorithm

Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346) include cipher suites based on DES (Data Encryption Standard) and IDEA (International Data Encryption Algorithm) algorithms. DES (when used in single-DES mode) and IDEA are no longer recommended for general use in TLS, and have been removed from TLS version 1.2 (RFC 5246). This document specifies these cipher suites for completeness and discusses reasons why their use is no longer recommended. This memo provides information for the Internet community.

draft-ietf-tls-des-idea-02 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5469
RFC5470 Architecture for IP Flow Information Export G. Sadasivan N. Brownlee B. Claise J. Quittek March 2009 ASCII HTML 31 ipfix ipfix device ipfix collector

This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. This memo provides information for the Internet community.

draft-ietf-ipfix-architecture-12 RFC6183 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5470
RFC5471 Guidelines for IP Flow Information Export (IPFIX) Testing C. Schmoll P. Aitken B. Claise March 2009 ASCII HTML 32 exporting process collecting process

This document presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. This memo provides information for the Internet community.

draft-ietf-ipfix-testing-05 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5471
RFC5472 IP Flow Information Export (IPFIX) Applicability T. Zseby E. Boschi N. Brownlee B. Claise March 2009 ASCII HTML 31 ie information element PSAMP measurement QoS monitoring attack detection AAA ipfix framework

In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. This memo provides information for the Internet community.

draft-ietf-ipfix-as-12 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5472 10.17487/RFC5472
RFC5473 Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports E. Boschi L. Mark B. Claise March 2009 ASCII HTML 27

This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.

This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.

draft-ietf-ipfix-reducing-redundancy-04 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5473 10.17487/RFC5473
RFC5474 A Framework for Packet Selection and Reporting N. Duffield Editor D. Chiou B. Claise A. Greenberg M. Grossglauser J. Rexford March 2009 ASCII HTML 38 psamp selector collector

This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of the PSAMP functions. This memo provides information for the Internet community.

draft-ietf-psamp-framework-13 INFORMATIONAL INFORMATIONAL IETF ops psamp 10.17487/RFC5474
RFC5475 Sampling and Filtering Techniques for IP Packet Selection T. Zseby M. Molina N. Duffield S. Niccolini F. Raspall March 2009 ASCII HTML 46 psamp metering process

This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]

draft-ietf-psamp-sample-tech-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp 10.17487/RFC5475
RFC5476 Packet Sampling (PSAMP) Protocol Specifications B. Claise Editor A. Johnson J. Quittek March 2009 ASCII HTML 45 exporting process collecting process ipfix ip flow information export

This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]

draft-ietf-psamp-protocol-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5476 10.17487/RFC5476
RFC5477 Information Model for Packet Sampling Exports T. Dietz B. Claise P. Aitken F. Dressler G. Carle March 2009 ASCII HTML 46 psamp ipfix ip flow information export

This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]

draft-ietf-psamp-info-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops psamp http://www.rfc-editor.org/errata_search.php?rfc=5477 10.17487/RFC5477
RFC5478 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces J. Polk March 2009 ASCII HTML 6 us defense information systems agency

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. [STANDARDS-TRACK]

draft-ietf-sip-rph-new-namespaces-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5478
RFC5479 Requirements and Analysis of Media Security Management Protocols D. Wing Editor S. Fries H. Tschofenig F. Audet April 2009 ASCII HTML 45 keying Secure RTP SRTP

This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. This memo provides information for the Internet community.

draft-ietf-sip-media-security-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5479 10.17487/RFC5479
RFC5480 Elliptic Curve Cryptography Subject Public Key Information S. Turner D. Brown K. Yiu R. Housley T. Polk March 2009 ASCII HTML 20 x.509 asn.1 subjectPubicKeyInfo

This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]

draft-ietf-pkix-ecc-subpubkeyinfo-11 RFC3279 RFC8813 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5480 10.17487/RFC5480
RFC5481 Packet Delay Variation Applicability Statement A. Morton B. Claise March 2009 ASCII HTML 39 active measurement ipdv pdv inter-packet delay variation

Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.

Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community.

draft-ietf-ippm-delay-var-as-02 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5481
RFC5482 TCP User Timeout Option L. Eggert F. Gont March 2009 ASCII HTML 14 Transmission Control Protocol

The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]

draft-ietf-tcpm-tcp-uto-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5482
RFC5483 ENUM Implementation Issues and Experiences L. Conroy K. Fujiwara March 2009 ASCII HTML 30 DNS E.164 NAPTR dynamic delegation discovery system

This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. This memo provides information for the Internet community.

draft-ietf-enum-experiences-11 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5483
RFC5484 Associating Time-Codes with RTP Streams D. Singer March 2009 ASCII HTML 13 smpte society of motion picture and television engineers media stream

This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK]

draft-ietf-avt-smpte-rtp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5484
RFC5485 Digital Signatures on Internet-Draft Documents R. Housley March 2009 ASCII HTML 14 cms cryptographic message syntax detached signature

This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. This memo provides information for the Internet community.

draft-housley-internet-draft-sig-file-08 RFC8358 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5485
RFC5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology D. Malas Editor D. Meyer Editor March 2009 ASCII HTML 10

This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). This memo provides information for the Internet community.

draft-ietf-speermint-terminology-17 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC5486
RFC5487 Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode M. Badra March 2009 ASCII HTML 7 PSK Diffie-Hellman Key Exchange advanced encryption standard gcm digest algorithm ciphersuite

RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS-TRACK]

draft-ietf-tls-psk-new-mac-aes-gcm-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5487
RFC5488 Network Mobility (NEMO) Management Information Base S. Gundavelli G. Keeni K. Koide K. Nagami April 2009 ASCII HTML 44 mib NEMO-MIB

This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. [STANDARDS-TRACK]

draft-ietf-mext-nemo-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5488
RFC5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) M. Badra I. Hajjeh March 2009 ASCII HTML 7 pre-shared key Diffie-Hellman Key Exchange Elliptic Curve Cryptography

This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy (PFS). This memo provides information for the Internet community.

draft-ietf-tls-ecdhe-psk-05 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC5489
RFC5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata A. Melnikov March 2009 ASCII HTML 8 mail filtering fileinto

This memo defines an extension to the Sieve mail filtering language (RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. [STANDARDS-TRACK]

draft-melnikov-sieve-imapext-metadata-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC5490
RFC5491 GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations J. Winterbottom M. Thomson H. Tschofenig March 2009 ASCII HTML 28 PIDF-LO civic geodetic location well-formed GeoShape

The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. [STANDARDS-TRACK]

draft-ietf-geopriv-pdif-lo-profile-14 RFC4119 RFC7459 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5491 10.17487/RFC5491
RFC5492 Capabilities Advertisement with BGP-4 J. Scudder R. Chandra February 2009 ASCII HTML 7 bgp idr border gateway protocol capabilities

This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392. [STANDARDS-TRACK]

draft-ietf-idr-rfc3392bis-05 RFC3392 RFC8810 DRAFT STANDARD DRAFT STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5492 10.17487/RFC5492
RFC5493 Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network D. Caviglia D. Bramanti D. Li D. McDysan April 2009 ASCII HTML 11 pc spc soft permanent connection data plane traffic

From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.

This memo sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. This memo provides information for the Internet community.

draft-ietf-ccamp-pc-and-sc-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5493
RFC5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP) J. Arkko C. Pignataro April 2009 ASCII HTML 7 IANA rules Address Resolution Protocol ARP

This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. [STANDARDS-TRACK]

draft-arkko-arp-iana-rules-06 RFC0826 RFC0951 RFC1044 RFC1329 RFC2131 RFC2132 RFC2176 RFC2225 RFC2834 RFC2835 RFC3315 RFC4338 RFC4361 RFC4701 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5494
RFC5495 Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures D. Li J. Gao A. Satyanarayana S. Bardalai March 2009 ASCII HTML 18 Hello message gmpls

The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic-engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) networks for state recovery of control channel or nodal faults.

The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a Label Switched Path (LSP).

Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchanging RSVP messages with its upstream and downstream neighbors.

This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.

This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. This memo provides information for the Internet community.

draft-ietf-ccamp-gr-description-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5495
RFC5496 The Reverse Path Forwarding (RPF) Vector TLV IJ. Wijnands A. Boers E. Rosen March 2009 ASCII HTML 8 pim protocol independent multicast join attribute

This document describes a use of the Protocol Independent Multicast (PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. [STANDARDS-TRACK]

draft-ietf-pim-rpf-vector-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=5496 10.17487/RFC5496
RFC5497 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) T. Clausen C. Dearlove March 2009 ASCII HTML 14 Routing Protocol TLV Fisheye FSR Fuzzy-Sighted extension packetbb RFC5444

This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols. [STANDARDS-TRACK]

draft-ietf-manet-timetlv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5497 10.17487/RFC5497
RFC5498 IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols I. Chakeres March 2009 ASCII HTML 5 manet protocols

This document enumerates several common IANA allocations for use by Mobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. [STANDARDS-TRACK]

draft-ietf-manet-iana-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=5498 10.17487/RFC5498
RFC5499 RFC5500 RFC5501 Requirements for Multicast Support in Virtual Private LAN Services Y. Kamite Editor Y. Wada Y. Serbest T. Morin L. Fang March 2009 ASCII HTML 31 L2 VPN VPLS Ethernet P2MP IGMP MLD PIM

This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. This memo provides information for the Internet community.

draft-ietf-l2vpn-vpls-mcast-reqts-07 INFORMATIONAL INFORMATIONAL IETF int l2vpn 10.17487/RFC5501
RFC5502 The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem J. van Elburg April 2009 ASCII HTML 14 SIP S-CSCF AS ISC

This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. This memo provides information for the Internet community.

draft-vanelburg-sipping-served-user-08 RFC8217 RFC8498 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5502 10.17487/RFC5502
RFC5503 Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture F. Andreasen B. McKibben B. Marshall March 2009 ASCII HTML 34 P-DCS-TRACE-PARTY-ID P-DCS-OSPS P-DCS-BILLING-INFO P-DCS-LAES P-DCS-Redirect P-DCS-INFO

In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. This memo provides information for the Internet community.

draft-andreasen-sipping-rfc3603bis-07 RFC3603 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5503
RFC5504 Downgrading Mechanism for Email Address Internationalization K. Fujiwara Editor Y. Yoneya Editor March 2009 ASCII HTML 24 EAI Email Address Internationalization Downgrade MAIL

Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-eai-downgrade-12 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5504
RFC5505 Principles of Internet Host Configuration B. Aboba D. Thaler L. Andersson S. Cheshire May 2009 ASCII HTML 25 internet-layer parameter higher-layer configuration

This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols. This memo provides information for the Internet community.

draft-iab-ip-config-11 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5505
RFC5506 Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences I. Johansson M. Westerlund April 2009 ASCII HTML 17 AVPF non-compound non compound compound

This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-non-compound-09 RFC3550 RFC3711 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5506 10.17487/RFC5506
RFC5507 Design Choices When Expanding the DNS IAB P. Faltstrom Editor R. Austein Editor P. Koch Editor April 2009 ASCII HTML 18 domain name system resource record type

This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. This memo provides information for the Internet community.

draft-iab-dns-choices-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5507
RFC5508 NAT Behavioral Requirements for ICMP P. Srisuresh B. Ford S. Sivakumar S. Guha April 2009 ASCII HTML 29 ICMP Error payload translation hairpin translation ICMP Query ICMP Error Ping Traceroute

This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-nat-icmp-12 RFC7857 BCP0148 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5508
RFC5509 Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) S. Loreto April 2009 ASCII HTML 5 _sip

This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. [STANDARDS TRACK]

draft-loreto-simple-im-srv-label-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5509
RFC5510 Reed-Solomon Forward Error Correction (FEC) Schemes J. Lacan V. Roca J. Peltotalo S. Peltotalo April 2009 ASCII HTML 28 maximum distance separable MDS

This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).

Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-rs-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5510
RFC5511 Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications A. Farrel April 2009 ASCII HTML 14 routing bnf

Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.

There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.

Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.

This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]

draft-farrel-rtg-common-bnf-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5511
RFC5512 The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute P. Mohapatra E. Rosen April 2009 ASCII HTML 13 BGP Encapsulation Encap SAFI Tunnel Softwire 4over6 6over4

In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.

The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]

draft-ietf-softwire-encaps-safi-05 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5512
RFC5513 IANA Considerations for Three Letter Acronyms A. Farrel April 1 2009 ASCII HTML 7 tla abbreviation

Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors.

Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.

draft-farrel-iana-tla-registry-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5513 10.17487/RFC5513
RFC5514 IPv6 over Social Networks E. Vyncke April 1 2009 ASCII HTML 6 facebook

There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. This memo defines an Experimental Protocol for the Internet community.

draft-vyncke-ip-over-social-network-01 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5514 10.17487/RFC5514
RFC5515 Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions V. Mammoliti C. Pignataro P. Arberg J. Gibbons P. Howard May 2009 ASCII HTML 28 L2TP Acces Line Information DSLAM

This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3. This memo provides information for the Internet community.

draft-mammoliti-l2tp-accessline-avp-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5515 10.17487/RFC5515
RFC5516 Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) M. Jones L. Morand April 2009 ASCII HTML 5 3GPP Release 8 Diameter command codes EPS

This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). These new Diameter applications are defined for Mobile Management Entity (MME)- and Serving GPRS (General Packet Radio Service) Support Node (SGSN)-related interfaces in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). This memo provides information for the Internet community.

draft-jones-dime-3gpp-eps-command-codes-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5516
RFC5517 Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment S. HomChaudhuri M. Foschiano February 2010 ASCII HTML 12

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.

Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the-home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sanjib-private-vlan-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5517
RFC5518 Vouch By Reference P. Hoffman J. Levine A. Hathcock April 2009 ASCII HTML 12 VBR DKIM SenderID DK reputation

This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. [STANDARDS-TRACK]

draft-hoffman-dac-vbr-07 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5518 10.17487/RFC5518
RFC5519 Multicast Group Membership Discovery MIB J. Chesterfield B. Haberman Editor April 2009 ASCII HTML 41 management information base mgmd mld multicast listener discovery MGMD-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. [STANDARDS-TRACK]

draft-ietf-magma-mgmd-mib-15 RFC2933 RFC3019 PROPOSED STANDARD PROPOSED STANDARD IETF int magma http://www.rfc-editor.org/errata_search.php?rfc=5519 10.17487/RFC5519
RFC5520 Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism R. Bradford Editor JP. Vasseur A. Farrel April 2009 ASCII HTML 19 confidential path segment cps pcep

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.

This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]

draft-ietf-pce-path-key-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5520 10.17487/RFC5520
RFC5521 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions E. Oki T. Takeda A. Farrel April 2009 ASCII HTML 16 MPLS GMPLS Traffic Engineering Label Switched Path

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions".

The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK]

draft-ietf-pce-pcep-xro-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5521 10.17487/RFC5521
RFC5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks W. Eddy W. Ivancic T. Davis October 2009 ASCII HTML 31 NEMO aeronautics space exploration route optimization mobility

This document describes the requirements and desired properties of Network Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.

Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of the International Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. This memo provides information for the Internet community.

draft-ietf-mext-aero-reqs-04 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5522
RFC5523 OSPFv3-Based Layer 1 VPN Auto-Discovery L. Berger April 2009 ASCII HTML 12 open shortest path first layer 1 virtual private network

This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-l1vpn-ospfv3-auto-discovery-03 EXPERIMENTAL EXPERIMENTAL IETF rtg l1vpn 10.17487/RFC5523
RFC5524 Extended URLFETCH for Binary and Converted Parts D. Cridland May 2009 ASCII HTML 9 IMAP Lemonade

The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. [STANDARDS-TRACK]

draft-cridland-urlfetch-binary-03 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5524 10.17487/RFC5524
RFC5525 Reliable Server Pooling MIB Module Definition T. Dreibholz J. Mulik April 2009 ASCII HTML 46 RSerPool Management Information Base asap aggregate server access protocol enrp endpoint handlespace redundancy protocol RSERPOOL-MIB

Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols: ASAP (Aggregate Server Access Protocol) and ENRP (Endpoint Handlespace Redundancy Protocol). This document defines an \%SMIv2- compliant (Structure of Management Information Version 2) Management Information Base (MIB) module providing access to managed objects in an RSerPool implementation. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-rserpool-mib-12 EXPERIMENTAL EXPERIMENTAL IETF tsv rserpool 10.17487/RFC5525
RFC5526 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM J. Livingood P. Pfautz R. Stastny April 2009 ASCII HTML 5 e164.arpa

This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). This memo provides information for the Internet community.

draft-ietf-enum-infrastructure-07 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5526
RFC5527 Combined User and Infrastructure ENUM in the e164.arpa Tree M. Haberler O. Lendl R. Stastny May 2009 ASCII HTML 10 e164.arpa

This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. This memo provides information for the Internet community.

draft-ietf-enum-combined-09 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC5527
RFC5528 Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms A. Kato M. Kanda S. Kanno April 2009 ASCII HTML 22 Camellia Block Cipher Mode of operation

This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. This memo provides information for the Internet community.

draft-kato-camellia-ctrccm-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5528
RFC5529 Modes of Operation for Camellia for Use with IPsec A. Kato M. Kanda S. Kanno April 2009 ASCII HTML 7 IPsec Camellia Block Cipher Mode of operation

This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) and Encapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. [STANDARDS-TRACK]

draft-kato-ipsec-camellia-modes-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5529
RFC5530 IMAP Response Codes A. Gulbrandsen May 2009 ASCII HTML 9 machine-readable response codes

IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.

This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. [STANDARDS-TRACK]

draft-gulbrandsen-imap-response-codes-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5530
RFC5531 RPC: Remote Procedure Call Protocol Specification Version 2 R. Thurlow May 2009 ASCII HTML 63 RPC ONC Open Network Computing

This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK]

draft-ietf-nfsv4-rfc1831bis-13 RFC1831 DRAFT STANDARD DRAFT STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5531 10.17487/RFC5531
RFC5532 Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement T. Talpey C. Juszczak May 2009 ASCII HTML 15 RPC XDR ONC RDDP NFSv4

This document addresses enabling the use of Remote Direct Memory Access (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead. This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general. This memo provides information for the Internet community.

draft-ietf-nfsv4-nfs-rdma-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5532
RFC5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6 E. Nordmark M. Bagnulo June 2009 ASCII HTML 124 locator pair

This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]

draft-ietf-shim6-proto-12 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5533
RFC5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming J. Arkko I. van Beijnum June 2009 ASCII HTML 36 Shim6 reachability protocol REAP

This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. [STANDARDS-TRACK]

draft-ietf-shim6-failure-detection-13 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5534
RFC5535 Hash-Based Addresses (HBA) M. Bagnulo June 2009 ASCII HTML 25 Shim6 multi-homing cryptographically generated addresses (cgas),

This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. [STANDARDS-TRACK]

draft-ietf-shim6-hba-05 PROPOSED STANDARD PROPOSED STANDARD IETF int shim6 10.17487/RFC5535
RFC5536 Netnews Article Format K. Murchison Editor C. Lindsey D. Kohn November 2009 ASCII HTML 36 Usenet Usefor

This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]

draft-ietf-usefor-usefor-12 RFC1036 RFC1849 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5536 10.17487/RFC5536
RFC5537 Netnews Architecture and Protocols R. Allbery Editor C. Lindsey November 2009 ASCII HTML 48 usefor Usenet netnews

This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]

draft-ietf-usefor-usepro-14 RFC1036 RFC1849 RFC8315 PROPOSED STANDARD PROPOSED STANDARD IETF app usefor http://www.rfc-editor.org/errata_search.php?rfc=5537 10.17487/RFC5537
RFC5538 The 'news' and 'nntp' URI Schemes F. Ellermann April 2010 ASCII HTML 14

This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. [STANDARDS-TRACK]

draft-ellermann-news-nntp-uri-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5538 10.17487/RFC5538
RFC5539 NETCONF over Transport Layer Security (TLS) M. Badra May 2009 ASCII HTML 7 Authentication TLS RPC

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. [STANDARDS-TRACK]

draft-ietf-netconf-tls-07 RFC7589 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC5539
RFC5540 40 Years of RFCs RFC Editor April 2009 ASCII HTML 3

This RFC marks the 40th anniversary of the RFC document series. This memo provides information for the Internet community.

draft-rfc-editor-40-anniversary-00 RFC8700 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5540
RFC5541 Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) JL. Le Roux JP. Vasseur Y. Lee June 2009 ASCII HTML 23 pcc path computation client

The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).

In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.

This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.

This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]

draft-ietf-pce-of-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5541
RFC5542 Definitions of Textual Conventions for Pseudowire (PW) Management T. Nadeau Editor D. Zelig Editor O. Nicklass Editor May 2009 ASCII HTML 11 Pseudowire PWE3 MIB PWE3-TC PW-TC

This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. [STANDARDS-TRACK]

draft-ietf-pwe3-pw-tc-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5542
RFC5543 BGP Traffic Engineering Attribute H. Ould-Brahim D. Fedyk Y. Rekhter May 2009 ASCII HTML 6 BGP-TE BGP-TE Attribute Traffic Engineering with BGP Inter-domain Traffic Engineering L1VPN BGP-TE BGP-TE-VPN VPN BGP Traffic Engineering Attribute

This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.

The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]

draft-ietf-softwire-bgp-te-attribute-04 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5543
RFC5544 Syntax for Binding Documents with Time-Stamps A. Santoni February 2010 ASCII HTML 13 time-stamp token,

This document describes an envelope that can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time-stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed.

The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 5652. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-santoni-timestampeddata-06 RFC5955 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5544
RFC5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar) B. Desruisseaux Editor September 2009 ASCII HTML 168 calsify calsched calsch caldav calendar calendaring meeting event task to-do journal appointment agenda schedule scheduling ical icalendar itip imip text/calendar ischedule xCalendar

This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK]

draft-ietf-calsify-rfc2445bis-10 RFC2445 RFC5546 RFC6868 RFC7529 RFC7953 RFC7986 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5545 10.17487/RFC5545
RFC5546 iCalendar Transport-Independent Interoperability Protocol (iTIP) C. Daboo Editor December 2009 ASCII HTML 133 calendar scheduling

This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.

The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]

draft-ietf-calsify-2446bis-10 RFC2446 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=5546 10.17487/RFC5546
RFC5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer M. Garcia-Martin M. Isomaki G. Camarillo S. Loreto P. Kyzivat May 2009 ASCII HTML 50 msrp message session relay protocol

This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. [STANDARDS-TRACK]

draft-ietf-mmusic-file-transfer-mech-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5547 10.17487/RFC5547
RFC5548 Routing Requirements for Urban Low-Power and Lossy Networks M. Dohler Editor T. Watteyne Editor T. Winter Editor D. Barthel Editor May 2009 ASCII HTML 21 u-lln roll routing over low-power and loss

The application-specific routing requirements for Urban Low-Power and Lossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws. These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-power IEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics. This memo provides information for the Internet community.

draft-ietf-roll-urban-routing-reqs-05 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5548
RFC5549 Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop F. Le Faucheur E. Rosen May 2009 ASCII HTML 10 BGP IPv6 IPv4

Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]

draft-ietf-softwire-v4nlri-v6nh-02 RFC8950 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=5549 10.17487/RFC5549
RFC5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile D. Cridland Editor A. Melnikov Editor S. Maes Editor August 2009 ASCII HTML 41 IMAP Sieve SMTP Lemonade mobile email low-bandwidth efficient

This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.

The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. [STANDARDS-TRACK]

draft-ietf-lemonade-profile-bis-12 RFC4550 RFC4469 RFC4467 PROPOSED STANDARD PROPOSED STANDARD IETF app lemonade 10.17487/RFC5550
RFC5551 Lemonade Notifications Architecture R. Gellens Editor August 2009 ASCII HTML 12 notification filtering

Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) Working Group.

This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. This memo provides information for the Internet community.

draft-ietf-lemonade-notifications-10 INFORMATIONAL INFORMATIONAL IETF app lemonade 10.17487/RFC5551
RFC5552 SIP Interface to VoiceXML Media Services D. Burke M. Scott May 2009 ASCII HTML 36 VoiceXML SIP MRF IVR IMS

This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK]

draft-ietf-mediactrl-vxml-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=5552 10.17487/RFC5552
RFC5553 Resource Reservation Protocol (RSVP) Extensions for Path Key Support A. Farrel Editor R. Bradford JP. Vasseur May 2009 ASCII HTML 14 pks path key subobject ero explicit route object rro record route object

The paths taken by Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.

To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) and embedding this subobject within the result of its path computation.

This document describes how to carry Path Key Subobjects in the Resource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. [STANDARDS-TRACK]

draft-ietf-ccamp-path-key-ero-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5553
RFC5554 Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings N. Williams May 2009 ASCII HTML 4 GSS GSS-API channel binding and C-bindings

This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-channel-bindings-07 RFC2743 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5554
RFC5555 Mobile IPv6 Support for Dual Stack Hosts and Routers H. Soliman Editor June 2009 ASCII HTML 41 nemo mipv6 ipv4

The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent. [STANDARDS-TRACK]

draft-ietf-mext-nemo-v4traversal-10 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5555 10.17487/RFC5555
RFC5556 Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement J. Touch R. Perlman May 2009 ASCII HTML 17 spanning tree protocol ieee 802.1

Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities. This memo provides information for the Internet community.

draft-ietf-trill-prob-06 INFORMATIONAL INFORMATIONAL IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=5556 10.17487/RFC5556
RFC5557 Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization Y. Lee JL. Le Roux D. King E. Oki July 2009 ASCII HTML 26 pcc path communication client pce gco global concurrent optimization nms network management system

The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.

This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]

draft-ietf-pce-global-concurrent-optimization-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5557 10.17487/RFC5557
RFC5558 Virtual Enterprise Traversal (VET) F. Templin Editor February 2010 ASCII HTML 36 Enterprise MANET Encapsulation Tunneling Autoconfiguration Subnetwork Provider-Independent Provider-Aggregated

Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-templin-autoconf-dhcp-38 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5558
RFC5559 Pre-Congestion Notification (PCN) Architecture P. Eardley Editor June 2009 ASCII HTML 54 Quality of Service QoS Congestion Control Differentiated Services Admission Control Termination

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. This memo provides information for the Internet community.

draft-ietf-pcn-architecture-11 INFORMATIONAL INFORMATIONAL IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5559 10.17487/RFC5559
RFC5560 A One-Way Packet Duplication Metric H. Uijterwaal May 2009 ASCII HTML 14 performance metrics packet duplication unidirectional

When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.

In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. [STANDARDS-TRACK]

draft-ietf-ippm-duplicate-08 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5560
RFC5561 LDP Capabilities B. Thomas K. Raza S. Aggarwal R. Aggarwal JL. Le Roux July 2009 ASCII HTML 12 MPLS LDP Capabilities

A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-capabilities-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5561
RFC5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets A. Kuzmanovic A. Mondal S. Floyd K. Ramakrishnan June 2009 ASCII HTML 33 ecn-capable

The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of Explicit Congestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder (the sender of the SYN/ACK packet) must reply to a report of an ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-ecnsyn-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5562
RFC5563 WiMAX Forum / 3GPP2 Proxy Mobile IPv4 K. Leung G. Dommety P. Yegani K. Chowdhury February 2010 ASCII HTML 41 mipv4 pmipv4

Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-leung-mip4-proxy-mode-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5563
RFC5564 Linguistic Guidelines for the Use of the Arabic Language in Internet Domains A. El-Sherbiny M. Farah I. Oueichek A. Al-Zoman February 2010 ASCII HTML 11 arabic domain names

This document constitutes technical specifications for the use of Arabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-farah-adntf-ling-guidelines-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5564
RFC5565 Softwire Mesh Framework J. Wu Y. Cui C. Metz E. Rosen June 2009 ASCII HTML 31

The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]

draft-ietf-softwire-mesh-framework-06 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5565
RFC5566 BGP IPsec Tunnel Encapsulation Attribute L. Berger R. White E. Rosen June 2009 ASCII HTML 8 border gateway protocol safi subsequent address family identifier

The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. [STANDARDS-TRACK]

draft-ietf-softwire-encaps-ipsec-03 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5566
RFC5567 An Architectural Framework for Media Server Control T. Melanchuk Editor June 2009 ASCII HTML 25

This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. This memo provides information for the Internet community.

draft-ietf-mediactrl-architecture-04 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC5567
RFC5568 Mobile IPv6 Fast Handovers R. Koodli Editor July 2009 ASCII HTML 51 mpiv6 handover latency

Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.

This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. [STANDARDS-TRACK]

draft-ietf-mipshop-rfc5268bis-01 RFC5268 RFC7411 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5568 10.17487/RFC5568
RFC5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) R. Despres January 2010 ASCII HTML 10 IPv6 IPv4 migration transition 6to4 6rd

IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-despres-6rd-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5569 10.17487/RFC5569
RFC5570 Common Architecture Label IPv6 Security Option (CALIPSO) M. StJohns R. Atkinson G. Thomas July 2009 ASCII HTML 52 sensitivity labels mls multi-level secure

This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. This memo provides information for the Internet community.

draft-stjohns-sipso-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5570 10.17487/RFC5570
RFC5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) B. Storer C. Pignataro Editor M. Dos Santos B. Stevant Editor L. Toutain J. Tremblay June 2009 ASCII HTML 41 Softwire L2TP Softwire Hub and Spoke Softwire HnS 4over6 6over4 L2TP softwires L2TPv2 softwires

This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]

draft-ietf-softwire-hs-framework-l2tpv2-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5571
RFC5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) M. Blanchet F. Parent February 2010 ASCII HTML 32 IPv6 Tunnel Transition TSP

A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. This document defines an Experimental Protocol for the Internet community.

draft-blanchet-v6ops-tunnelbroker-tsp-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5572 10.17487/RFC5572
RFC5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) M. Thomson June 2009 ASCII HTML 8 asynchronous beep channels

The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. This memo defines an Experimental Protocol for the Internet community.

draft-thomson-beep-async-02 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5573
RFC5574 RTP Payload Format for the Speex Codec G. Herlein J. Valin A. Heggestad A. Moizard June 2009 ASCII HTML 14 Voip SDP audio CELLP Xiph.Org

Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-rtp-speex-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5574
RFC5575 Dissemination of Flow Specification Rules P. Marques N. Sheth R. Raszuk B. Greene J. Mauch D. McPherson August 2009 ASCII HTML 22 IDR Inter-domain routing BGP DDOS Denial of Service ACL Firewall Filter

This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.

Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]

draft-ietf-idr-flow-spec-09 RFC7674 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=5575 10.17487/RFC5575
RFC5576 Source-Specific Media Attributes in the Session Description Protocol (SDP) J. Lennox J. Ott T. Schierl June 2009 ASCII HTML 18 real-time transport protocol rtp synchronization source ssrc fid flow identification fec forward error correction

The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-source-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5576
RFC5577 RTP Payload Format for ITU-T Recommendation G.722.1 P. Luthi R. Even July 2009 ASCII HTML 11 international telecommunication union wide-band audio coded

International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support G.722.1 audio codec. [STANDARDS-TRACK]

draft-ietf-avt-rfc3047-bis-09 RFC3047 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5577 10.17487/RFC5577
RFC5578 PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics B. Berry Editor S. Ratliff E. Paradise T. Kaiser M. Adams February 2010 ASCII HTML 24 point-to-point protocol over ethernet link quality metric

This document extends the Point-to-Point Protocol over Ethernet (PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-bberry-rfc4938bis-00 RFC4938 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5578
RFC5579 Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces F. Templin Editor February 2010 ASCII HTML 9 ISATAP Tunnel Encapsulation Map-and-Encaps IPv4 IPv6

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-templin-isatapv4-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5579
RFC5580 Carrying Location Objects in RADIUS and Diameter H. Tschofenig Editor F. Adrangi M. Jones A. Lior B. Aboba August 2009 ASCII HTML 53 remote authentication dial-in user service location information

This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter.

The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK]

draft-ietf-geopriv-radius-lo-24 RFC8559 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5580 10.17487/RFC5580
RFC5581 The Camellia Cipher in OpenPGP D. Shaw June 2009 ASCII HTML 3 PGP GPG GnuPG Encryption Symmetric

This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.

draft-ietf-openpgp-camellia-04 RFC4880 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5581
RFC5582 Location-to-URL Mapping Architecture and Framework H. Schulzrinne September 2009 ASCII HTML 17 ECRIT Mapping LoST Emergency calling

This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. This memo provides information for the Internet community.

draft-ietf-ecrit-mapping-arch-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=5582 10.17487/RFC5582
RFC5583 Signaling Media Decoding Dependency in the Session Description Protocol (SDP) T. Schierl S. Wenger July 2009 ASCII HTML 18 media coding ddp decoding dependency

This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.

A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). [STANDARDS-TRACK]

draft-ietf-mmusic-decoding-dependency-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5583 10.17487/RFC5583
RFC5584 RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family M. Hatanaka J. Matsumoto July 2009 ASCII HTML 30 RTP audio fragmentation layered coding multiplexed multi-session multi-channel redundancy scalable ATRAC ATRAC3 ATRAC-X ATRAC Advanced Lossless AAL Sony Corporation

This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. [STANDARDS-TRACK]

draft-ietf-avt-rtp-atrac-family-24 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5584 10.17487/RFC5584
RFC5585 DomainKeys Identified Mail (DKIM) Service Overview T. Hansen D. Crocker P. Hallam-Baker July 2009 ASCII HTML 24 Email Electroni Mail Internet Mail Message Verification

This document provides an overview of the DomainKeys Identified Mail (DKIM) service and describes how it can fit into a messaging service. It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public-key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This memo provides information for the Internet community.

draft-ietf-dkim-overview-12 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5585
RFC5586 MPLS Generic Associated Channel M. Bocci Editor M. Vigoureux Editor S. Bryant Editor June 2009 ASCII HTML 19 mpls-tp oam g-ach ach associated channel header gal generic associated label

This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.

draft-ietf-mpls-tp-gach-gal-06 RFC3032 RFC4385 RFC5085 RFC6423 RFC7026 RFC7214 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5586 10.17487/RFC5586
RFC5587 Extended Generic Security Service Mechanism Inquiry APIs N. Williams July 2009 ASCII HTML 16 GSS-API mechanism inquiry extension

This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.

These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS-TRACK]

draft-ietf-kitten-extended-mech-inquiry-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5587
RFC5588 Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials N. Williams July 2009 ASCII HTML 7 GSS-API credential gss_store_cred

This document defines a new function for the Generic Security Service Application Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. [STANDARDS-TRACK]

draft-ietf-kitten-gssapi-store-cred-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5588
RFC5589 Session Initiation Protocol (SIP) Call Control - Transfer R. Sparks A. Johnston Editor D. Petrie June 2009 ASCII HTML 58 REFER GRUU Attended Transfer Target-Dialog Out of Dialog REFER SIP SIP Services blind transfer SIP Features Replaces Referred-By

This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-sipping-cc-transfer-12 BCP0149 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5589 10.17487/RFC5589
RFC5590 Transport Subsystem for the Simple Network Management Protocol (SNMP) D. Harrington J. Schoenwaelder June 2009 ASCII HTML 34 Network Management Simple Network Management Protocol SNMP SNMP-TRANSPORT-MIB

This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-tmsm-18 RFC3411 RFC3412 RFC3414 RFC3417 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5590
RFC5591 Transport Security Model for the Simple Network Management Protocol (SNMP) D. Harrington W. Hardaker June 2009 ASCII HTML 28 Network Management Simple Network Management Protocol SNMP Transport Security Model Security Model

This memo describes a Transport Security Model for the Simple Network Management Protocol (SNMP).

This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-transport-security-model-14 STD0078 INTERNET STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5591
RFC5592 Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) D. Harrington J. Salowey W. Hardaker June 2009 ASCII HTML 36 Network Management Simple Network Management Protocol SNMP Secure Shell SSH

This memo describes a Transport Model for the Simple Network Management Protocol (SNMP), using the Secure Shell (SSH) protocol.

This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-secshell-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC5592
RFC5593 Internet Message Access Protocol (IMAP) - URL Access Identifier Extension N. Cook June 2009 ASCII HTML 10 urlauth imap url

The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications.

This document updates RFC 5092. [STANDARDS-TRACK]

draft-ncook-urlauth-accessid-02 RFC5092 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5593
RFC5594 Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 J. Peterson A. Cooper July 2009 ASCII HTML 28 P2PI

This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community.

draft-p2pi-cooper-workshop-report-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5594
RFC5595 The Datagram Congestion Control Protocol (DCCP) Service Codes G. Fairhurst September 2009 ASCII HTML 19 DCCP-Request Ports

This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK]

draft-ietf-dccp-serv-codes-11 RFC4340 RFC6335 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=5595 10.17487/RFC5595
RFC5596 Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal G. Fairhurst September 2009 ASCII HTML 25 DCCP NAT traversal Middlebox Issues

This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK]

draft-ietf-dccp-simul-open-08 RFC4340 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5596
RFC5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol R. Denis-Courmont September 2009 ASCII HTML 9 dccp

This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-behave-dccp-05 BCP0150 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC5597
RFC5598 Internet Mail Architecture D. Crocker July 2009 ASCII PDF HTML 54 email e-mail service mime architecture mta mua msa mda admd user originator recipient transfer message transfer deliver delivery relay header gateway agent gateway actor gateway sieve dsn mdn tussle mhs Message handling service message transfer agent message user agent mail submission agent mail delivery agent administrative management domain

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

draft-crocker-email-arch-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5598 10.17487/RFC5598
RFC5599 RFC5600 RFC5601 Pseudowire (PW) Management Information Base (MIB) T. Nadeau Editor D. Zelig Editor July 2009 ASCII HTML 67 pseudowire edge-to-edge services IANA-PWE3-MIB PW-STD-MIB

This memo defines a Standards Track portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. [STANDARDS-TRACK]

draft-ietf-pwe3-pw-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5601 10.17487/RFC5601
RFC5602 Pseudowire (PW) over MPLS PSN Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII HTML 31 pw operation PW-MPLS-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). [STANDARDS-TRACK]

draft-ietf-pwe3-pw-mpls-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5602
RFC5603 Ethernet Pseudowire (PW) Management Information Base (MIB) D. Zelig Editor T. Nadeau Editor July 2009 ASCII HTML 23 ethernet pw PW-ENET-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. [STANDARDS-TRACK]

draft-ietf-pwe3-enet-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5603
RFC5604 Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) O. Nicklass July 2009 ASCII HTML 41 mib management information base pseudowire encapsulation t1 e1 t3 e3

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-Division Multiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet Switched Network (PSN). [STANDARDS-TRACK]

draft-ietf-pwe3-tdm-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5604
RFC5605 Managed Objects for ATM over Packet Switched Networks (PSNs) O. Nicklass T. Nadeau July 2009 ASCII HTML 36 mib management information base atm pseudowire

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switched Networks (PSNs). [STANDARDS-TRACK]

draft-ietf-pwe3-pw-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5605
RFC5606 Implications of 'retransmission-allowed' for SIP Location Conveyance J. Peterson T. Hardie J. Morris August 2009 ASCII HTML 11 pidf-lo presence information data format for location objects

This document explores an ambiguity in the interpretation of the <retransmission-allowed> element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.

Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community.

draft-ietf-geopriv-sip-lo-retransmission-02 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5606
RFC5607 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management D. Nelson G. Weber July 2009 ASCII HTML 25 Network Management Device Management Simple Network Management Protocol SNMP Network Configuration Protocol NETCONF Access Control

This document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]

draft-ietf-radext-management-authorization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC5607
RFC5608 Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models K. Narayan D. Nelson August 2009 ASCII HTML 14 authorization service ssh transport model secure shell transport model

This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. [STANDARDS-TRACK]

draft-ietf-isms-radius-usage-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5608 10.17487/RFC5608
RFC5609 State Machines for the Protocol for Carrying Authentication for Network Access (PANA) V. Fajardo Editor Y. Ohba R. Marin-Lopez August 2009 ASCII HTML 30 PANA State Machine EAP

This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANA Authentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible Authentication Protocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. This memo provides information for the Internet community.

draft-ietf-pana-statemachine-12 INFORMATIONAL INFORMATIONAL IETF int pana 10.17487/RFC5609
RFC5610 Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements E. Boschi B. Trammell L. Mark T. Zseby July 2009 ASCII HTML 20 enterprise-specific Information Element IPFIX Template type record type options template

This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK]

draft-ietf-ipfix-exporting-type-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5610 10.17487/RFC5610
RFC5611 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires A. Vainshtein S. Galtzur August 2009 ASCII HTML 11 l2tpv3 layer tow tunneling protocol version 3 structure-agnostic structure-aware cesopsn tdmoip

This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure-aware (Circuit Emulation Service over Packet Switched Network (CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires. Support of structure-aware (Time-Division Multiplexing over IP (TDMoIP) style) pseudowires over L2TPv3 is left for further study. [STANDARDS-TRACK]

draft-ietf-l2tpext-tdm-07 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5611
RFC5612 Enterprise Number for Documentation Use P. Eronen D. Harrington August 2009 ASCII HTML 4 smi network management private enterprise code

This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.

draft-eronen-enterprise-number-documentation-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5612
RFC5613 OSPF Link-Local Signaling A. Zinin A. Roy L. Nguyen B. Friedman D. Yeung August 2009 ASCII HTML 12 open shortest path first intra-domain routing

OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track.

draft-ietf-ospf-lls-08 RFC4813 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5613
RFC5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding R. Ogier P. Spagnolo August 2009 ASCII HTML 71 MANET routing link-state routing CDS flooding mesh network MANET Designated Router MDR

This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-ospf-manet-mdr-05 RFC7038 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5614
RFC5615 H.248/MEGACO Registration Procedures C. Groves Y. Lin August 2009 ASCII HTML 14 Package Error Code ServiceChange Reason Profile

This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-groves-megaco-pkgereg-04 BCP0151 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5615
RFC5616 Streaming Internet Messaging Attachments N. Cook August 2009 ASCII HTML 28 IMAP SIP streaming stream email multimedia lemonade attachments video audio

This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.

The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 5022). This memo provides information for the Internet community.

draft-ietf-lemonade-streaming-13 INFORMATIONAL INFORMATIONAL IETF app lemonade http://www.rfc-editor.org/errata_search.php?rfc=5616 10.17487/RFC5616
RFC5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) E. Allman J. Fenton M. Delany J. Levine August 2009 ASCII HTML 21 email e-mail rfc 5322 rfc 5322 rfc 822 rfc 822 rfc 5321 rfc 5321 rfc 821 rfc 821 rfc 4871 rfc 4871 DKIM domain keys domainkeys ADSP ADSP SSP architecture mta user delivery smtp submission email e-mail smtp Internet mailfrom mail from author return address sender signing signing practices

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. [STANDARDS-TRACK]

draft-ietf-dkim-ssp-10 RFC8553 HISTORIC PROPOSED STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=5617 10.17487/RFC5617
RFC5618 Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) A. Morton K. Hedayat August 2009 ASCII HTML 8 twamp-control protocol twamp-test protocol twamp modes

This memo describes a simple extension to TWAMP (the Two-Way Active Measurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. [STANDARDS-TRACK]

draft-ietf-ippm-more-twamp-02 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC5618
RFC5619 Softwire Security Analysis and Requirements S. Yamamoto C. Williams H. Yokota F. Parent August 2009 ASCII HTML 28 IPv6 Tunnel Softwire Transition

This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]

draft-ietf-softwire-security-requirements-09 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5619
RFC5620 RFC Editor Model (Version 1) O. Kolkman Editor IAB August 2009 ASCII HTML 19 RFC Series Editor Independent Stream Editor

The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. This memo provides information for the Internet community.

draft-iab-rfc-editor-model-07 RFC6548 RFC6635 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5620
RFC5621 Message Body Handling in the Session Initiation Protocol (SIP) G. Camarillo September 2009 ASCII HTML 19 Message body MIME SIP

This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. [STANDARDS-TRACK]

draft-ietf-sip-body-handling-06 RFC3204 RFC3261 RFC3459 RFC8262 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5621
RFC5622 Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) S. Floyd E. Kohler August 2009 ASCII HTML 19 ccid 4 congestion control identifier 4

This document specifies a profile for Congestion Control Identifier 4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dccp-ccid4-05 RFC6323 RFC8311 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5622
RFC5623 Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda JL. Le Roux A. Farrel September 2009 ASCII HTML 34 MPLS GMPLS Traffic Engineering Label Switched Path Virtual Network Topology

A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.

This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). This memo provides information for the Internet community.

draft-ietf-pce-inter-layer-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=5623 10.17487/RFC5623
RFC5624 Quality of Service Parameters for Usage with Diameter J. Korhonen Editor H. Tschofenig E. Davies August 2009 ASCII HTML 12 Diameter QoS Parameters

This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.

The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per-hop behavior class object. [STANDARDS-TRACK]

draft-ietf-dime-qos-parameters-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5624
RFC5625 DNS Proxy Implementation Guidelines R. Bellis August 2009 ASCII HTML 12 DNS Proxy

This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-dnsext-dnsproxy-06 BCP0152 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC5625
RFC5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) C. Jennings Editor R. Mahy Editor F. Audet Editor October 2009 ASCII HTML 50

The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams to User Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. [STANDARDS-TRACK]

draft-ietf-sip-outbound-20 RFC3261 RFC3327 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5626
RFC5627 Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII HTML 40 SIP NAT outbound gruu registration traversal

Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. [STANDARDS-TRACK]

draft-ietf-sip-gruu-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5627 10.17487/RFC5627
RFC5628 Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) P. Kyzivat October 2009 ASCII HTML 14 registration

RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.

However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. [STANDARDS-TRACK]

draft-ietf-sipping-gruu-reg-event-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5628 10.17487/RFC5628
RFC5629 A Framework for Application Interaction in the Session Initiation Protocol (SIP) J. Rosenberg October 2009 ASCII HTML 38 sip dtmf

This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi- Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. [STANDARDS-TRACK]

draft-ietf-sipping-app-interaction-framework-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC5629
RFC5630 The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) F. Audet October 2009 ASCII HTML 56 SIPS SIP TLS

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. [STANDARDS-TRACK]

draft-ietf-sip-sips-09 RFC3261 RFC3608 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5630
RFC5631 Session Initiation Protocol (SIP) Session Mobility R. Shacham H. Schulzrinne S. Thakolsri W. Kellerer October 2009 ASCII HTML 35 third party call control (3pcc) transfer voice over ip (voip)

Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document. This memo provides information for the Internet community.

draft-shacham-sipping-session-mobility-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5631
RFC5632 Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial C. Griffiths J. Livingood L. Popkin R. Woundy Y. Yang September 2009 ASCII HTML 12 ISP Internet Service Provider P2P Peer-to-Peer P4P Proactive Network Provider Partication for P2P DCIA Distributed Computing Industry Association

This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer Transport Optimization (ALTO) working group. This memo provides information for the Internet community.

draft-livingood-woundy-p4p-experiences-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5632 10.17487/RFC5632
RFC5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers S. Dawkins Editor August 2009 ASCII HTML 5 Internet Architecture Board Engineering Steering Group

This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-dawkins-nomcom-dont-wait-04 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5633
RFC5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP) G. Fairhurst A. Sathiaseelan August 2009 ASCII HTML 22 ccid congestion control identifier ccid 2 ccid 3 ccid 4

This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-dccp-quickstart-05 EXPERIMENTAL EXPERIMENTAL IETF tsv dccp 10.17487/RFC5634
RFC5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) W. Kumari D. McPherson August 2009 ASCII HTML 15 rtbh

Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community.

draft-ietf-opsec-blackhole-urpf-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC5635
RFC5636 Traceable Anonymous Certificate S. Park H. Park Y. Won J. Lee S. Kent August 2009 ASCII HTML 31 x.509 certificate blind issuer anonymity issuer tacs end entity ee

This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-tac-04 EXPERIMENTAL EXPERIMENTAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5636 10.17487/RFC5636
RFC5637 Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 G. Giaretta I. Guardini E. Demaria J. Bournelle R. Lopez September 2009 ASCII HTML 11 AAA MIPv6 Mobile IP

In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, and Accounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. This memo provides information for the Internet community.

draft-ietf-mext-aaa-ha-goals-01 INFORMATIONAL INFORMATIONAL IETF int mext 10.17487/RFC5637
RFC5638 Simple SIP Usage Scenario for Applications in the Endpoints H. Sinnreich Editor A. Johnston E. Shim K. Singh September 2009 ASCII HTML 19 session initiation protocol rich internet application ria

For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIAs). Significant telephony features may also be implemented in the endpoints.

This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about 11.

References for NAT traversal and for security are also provided. This memo provides information for the Internet community.

draft-sinnreich-sip-tools-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5638
RFC5639 Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation M. Lochter J. Merkle March 2010 ASCII HTML 27

This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-lochter-pkix-brainpool-ecc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5639 10.17487/RFC5639
RFC5640 Load-Balancing for Mesh Softwires C. Filsfils P. Mohapatra C. Pignataro August 2009 ASCII HTML 6 bgp encapsulation subsequent address family identifier safi

Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]

draft-ietf-softwire-lb-03 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC5640
RFC5641 Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values N. McGill C. Pignataro August 2009 ASCII HTML 11 attachment circuits acs pseudowires pw active bit new bit circuit status avp

This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate finer-grained error states for Attachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the Circuit Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC 4719. [STANDARDS-TRACK]

draft-ietf-l2tpext-circuit-status-extensions-05 RFC3931 RFC4349 RFC4454 RFC4591 RFC4719 PROPOSED STANDARD PROPOSED STANDARD IETF int l2tpext 10.17487/RFC5641
RFC5642 Dynamic Hostname Exchange Mechanism for OSPF S. Venkata S. Harwani C. Pignataro D. McPherson August 2009 ASCII HTML 8 open shortest path first router information ri ospf dynamic hostname

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. [STANDARDS-TRACK]

draft-ietf-ospf-dynamic-hostname-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5642
RFC5643 Management Information Base for OSPFv3 D. Joyal Editor V. Manral Editor August 2009 ASCII HTML 95 mib ipv6 open shortest path first routing protocol OSPFV3-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). [STANDARDS-TRACK]

draft-ietf-ospf-ospfv3-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5643 10.17487/RFC5643
RFC5644 IP Performance Metrics (IPPM): Spatial and Multicast E. Stephan L. Liang A. Morton October 2009 ASCII HTML 57 Multiple point measurement relative performance group performance statistic per hop measurement segment performance

The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). [STANDARDS-TRACK]

draft-ietf-ippm-multimetrics-12 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5644 10.17487/RFC5644
RFC5645 Update to the Language Subtag Registry D. Ewell Editor September 2009 ASCII HTML 13 language tags language tagging ltru registry

This memo defines the procedure used to update the IANA Language Subtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages. This memo provides information for the Internet community.

draft-ietf-ltru-4645bis-10 INFORMATIONAL INFORMATIONAL IETF app ltru 10.17487/RFC5645
RFC5646 Tags for Identifying Languages A. Phillips Editor M. Davis Editor September 2009 ASCII HTML 84 language tags private interchange

This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-ietf-ltru-4646bis-23 RFC4646 BCP0047 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app ltru http://www.rfc-editor.org/errata_search.php?rfc=5646 10.17487/RFC5646
RFC5647 AES Galois Counter Mode for the Secure Shell Transport Layer Protocol K. Igoe J. Solinas August 2009 ASCII HTML 10 ssh remote-login

Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol. This memo provides information for the Internet community.

draft-igoe-secsh-aes-gcm-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5647
RFC5648 Multiple Care-of Addresses Registration R. Wakikawa Editor V. Devarapalli G. Tsirtsis T. Ernst K. Nagami October 2009 ASCII HTML 36

According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well. [STANDARDS-TRACK]

draft-ietf-monami6-multiplecoa-14 RFC6089 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=5648 10.17487/RFC5648
RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm R. Housley M. Dworkin September 2009 ASCII HTML 13

This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of 64 bits, allowing a key of any practical length to be wrapped. This memo provides information for the Internet community.

draft-housley-aes-key-wrap-with-pad-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5649
RFC5650 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) M. Morgenstern S. Baillie U. Bonollo September 2009 ASCII HTML 218 mib management information base adsl asymmetric digital subscriber line VDSL2-LINE-TC-MIB VDSL2-LINE-MIB

This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. [STANDARDS-TRACK]

draft-ietf-adslmib-vdsl2-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib 10.17487/RFC5650
RFC5651 Layered Coding Transport (LCT) Building Block M. Luby M. Watson L. Vicisano October 2009 ASCII HTML 34 FEC reliable multicast

The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451. [STANDARDS-TRACK]

draft-ietf-rmt-bb-lct-revised-11 RFC3451 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=5651 10.17487/RFC5651
RFC5652 Cryptographic Message Syntax (CMS) R. Housley September 2009 ASCII HTML 56 digital signature message content

This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

draft-ietf-smime-rfc3852bis-00 RFC3852 RFC8933 STD0070 INTERNET STANDARD DRAFT STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5652 10.17487/RFC5652
RFC5653 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani August 2009 ASCII HTML 99 gssapi application program interface gss-api GSI

The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings" (RFC 2853). This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.

The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). [STANDARDS-TRACK]

draft-ietf-kitten-rfc2853bis-05 RFC2853 RFC8353 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC5653
RFC5654 Requirements of an MPLS Transport Profile B. Niven-Jenkins Editor D. Brungard Editor M. Betts Editor N. Sprecher S. Ueno September 2009 ASCII HTML 31 MPLS-TP ITU ITU-T

This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).

This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.

The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]

draft-ietf-mpls-tp-requirements-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5654 10.17487/RFC5654
RFC5655 Specification of the IP Flow Information Export (IPFIX) File Format B. Trammell E. Boschi L. Mark T. Zseby A. Wagner October 2009 ASCII HTML 64 flow file flow storage ipfix storage netflow storage

This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]

draft-ietf-ipfix-file-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5655 10.17487/RFC5655
RFC5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer D. Stebila J. Green December 2009 ASCII HTML 20 Key Agreement Cryptography

This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]

draft-green-secsh-ecc-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5656 10.17487/RFC5656
RFC5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard L. Dusseault R. Sparks September 2009 ASCII HTML 12 rfc2026 2026 guidance interoperation implementation reports advancement draft standard

Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-dusseault-impl-reports-04 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5657 10.17487/RFC5657
RFC5658 Addressing Record-Route Issues in the Session Initiation Protocol (SIP) T. Froment C. Lebel B. Bonnaerens October 2009 ASCII HTML 18 multi-homed user agent proxy interoperability double record-routing

A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) or SIPS (secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only a Record-Route rewriting solution. [STANDARDS-TRACK]

draft-ietf-sip-record-route-fix-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5658
RFC5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge M. Bocci S. Bryant October 2009 ASCII HTML 24 psn packet switched network

This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community.

draft-ietf-pwe3-ms-pw-arch-07 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5659 10.17487/RFC5659
RFC5660 IPsec Channels: Connection Latching N. Williams October 2009 ASCII HTML 31 IPsec connection latching channel

This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.

Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.

Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS-TRACK]

draft-ietf-btns-connection-latching-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec btns http://www.rfc-editor.org/errata_search.php?rfc=5660 10.17487/RFC5660
RFC5661 Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII HTML 617 Access Control List ACL Communications Sessions Exactly Once Semantics File Access Protocol Global Namespace Network Authentication Network File Access Network File System Network Security NFS Parallel Storage pNFS Storage Cluster

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK]

draft-ietf-nfsv4-minorversion1-29 RFC8881 RFC8178 RFC8434 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5661 10.17487/RFC5661
RFC5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler Editor M. Eisler Editor D. Noveck Editor January 2010 ASCII HTML 73 xdr nfsv4

This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. [STANDARDS-TRACK]

draft-ietf-nfsv4-minorversion1-dot-x-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5662
RFC5663 Parallel NFS (pNFS) Block/Volume Layout D. Black S. Fridella J. Glasgow January 2010 ASCII HTML 28 nfsv4 network file sharing version 4

Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. [STANDARDS-TRACK]

draft-ietf-nfsv4-pnfs-block-12 RFC6688 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5663 10.17487/RFC5663
RFC5664 Object-Based Parallel NFS (pNFS) Operations B. Halevy B. Welch J. Zelenka January 2010 ASCII HTML 35 OSD storage device

Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. [STANDARDS-TRACK]

draft-ietf-nfsv4-pnfs-obj-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5664 10.17487/RFC5664
RFC5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler January 2010 ASCII HTML 14 rpcbind portmap transport independent remote procedure call TI-RPC transport identifier protocol identifier

This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK]

draft-ietf-nfsv4-rpc-netid-06 RFC1833 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=5665 10.17487/RFC5665
RFC5666 Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey B. Callaghan January 2010 ASCII HTML 34 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document describes a protocol providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk-data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. [STANDARDS-TRACK]

draft-ietf-nfsv4-rpcrdma-09 RFC8166 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5666
RFC5667 Network File System (NFS) Direct Data Placement T. Talpey B. Callaghan January 2010 ASCII HTML 10 Network File System NFS ONC RPC RDMA RDDP iWARP InfiniBand

This document defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4, and 4.1 over such an RDMA transport. [STANDARDS-TRACK]

draft-ietf-nfsv4-nfsdirect-08 RFC8267 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC5667
RFC5668 4-Octet AS Specific BGP Extended Community Y. Rekhter S. Sangli D. Tappan October 2009 ASCII HTML 5 border gateway protocol autonomous system

This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. [STANDARDS-TRACK]

draft-ietf-l3vpn-as4octet-ext-community-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5668
RFC5669 The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) S. Yoon J. Kim H. Park H. Jeong Y. Won August 2010 ASCII HTML 13

This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]

draft-ietf-avt-seed-srtp-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5669
RFC5670 Metering and Marking Behaviour of PCN-Nodes P. Eardley Editor November 2009 ASCII HTML 20 pre-congestion notification threshold metering threshold marking pcn-threshold-rate pcn-excess-rate

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. [STANDARDS-TRACK]

draft-ietf-pcn-marking-behaviour-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5670 10.17487/RFC5670
RFC5671 Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) S. Yasukawa A. Farrel Editor October 2009 ASCII HTML 15 multiprotocol label switching generalized mpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).

This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. This memo provides information for the Internet community.

draft-ietf-pce-p2mp-app-02 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5671
RFC5672 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update D. Crocker Editor August 2009 ASCII HTML 14 DKIM email authentication security spam abuse errata trust Signing Domain Identifier SDID AUID Agent or User Identifier

This document updates RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module. The Update is in the style of an Errata entry, albeit a rather long one. [STANDARDS-TRACK]

draft-ietf-dkim-rfc4871-errata-07 RFC6376 RFC4871 PROPOSED STANDARD PROPOSED STANDARD IETF sec dkim 10.17487/RFC5672
RFC5673 Industrial Routing Requirements in Low-Power and Lossy Networks K. Pister Editor P. Thubert Editor S. Dwars T. Phinney October 2009 ASCII HTML 27 lln

The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. This memo provides information for the Internet community.

draft-ietf-roll-indus-routing-reqs-06 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5673
RFC5674 Alarms in Syslog S. Chisholm R. Gerhards October 2009 ASCII HTML 7 SYSLOG alarm

This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS-TRACK]

draft-ietf-opsawg-syslog-alarm-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5674
RFC5675 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages V. Marinov J. Schoenwaelder October 2009 ASCII HTML 15 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS-TRACK]

draft-ietf-opsawg-syslog-snmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC5675
RFC5676 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications J. Schoenwaelder A. Clemm A. Karmakar October 2009 ASCII HTML 22 Network Management Simple Network Management Protocol SNMP Notifications Syslog

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS-TRACK]

draft-ietf-opsawg-syslog-msg-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5676 10.17487/RFC5676
RFC5677 IEEE 802.21 Mobility Services Framework Design (MSFD) T. Melia Editor G. Bajko S. Das N. Golmie JC. Zuniga December 2009 ASCII HTML 25 media independent handover mih mobility services mos

This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for Mobility Services (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower-layer (e.g., link-layer) security mechanisms or overall system-specific proprietary security solutions are used. [STANDARDS-TRACK]

draft-ietf-mipshop-mstp-solution-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop http://www.rfc-editor.org/errata_search.php?rfc=5677 10.17487/RFC5677
RFC5678 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery G. Bajko S. Das December 2009 ASCII HTML 14 handover preparation handover decision media independent handover services

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

draft-ietf-mipshop-mos-dhcp-options-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5678
RFC5679 Locating IEEE 802.21 Mobility Services Using DNS G. Bajko December 2009 ASCII HTML 9 domain name server handover preparation handover decision media independent handover services

This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21. [STANDARDS-TRACK]

draft-ietf-mipshop-mos-dns-discovery-07 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5679
RFC5680 The Nominating Committee Process: Open Disclosure of Willing Nominees S. Dawkins Editor October 2009 ASCII HTML 7

This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

draft-dawkins-nomcom-openlist-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5680
RFC5681 TCP Congestion Control M. Allman V. Paxson E. Blanton September 2009 ASCII HTML 18 slow start congestion avoidance fast retransmit fast recovery

This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc2581bis-07 RFC2581 DRAFT STANDARD DRAFT STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5681 10.17487/RFC5681
RFC5682 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP P. Sarolahti M. Kojo K. Yamamoto M. Hata September 2009 ASCII HTML 19 SACK transmission control protocol loss recovery

The purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.

Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc4138bis-04 RFC4138 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC5682
RFC5683 Password-Authenticated Key (PAK) Diffie-Hellman Exchange A. Brusilovsky I. Faynberg Z. Zeltsan S. Patel February 2010 ASCII HTML 10

This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.

The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-brusilovsky-pak-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5683
RFC5684 Unintended Consequences of NAT Deployments with Overlapping Address Space P. Srisuresh B. Ford February 2010 ASCII HTML 26 network address translator

This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ford-behave-top-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5684
RFC5685 Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) V. Devarapalli K. Weniger November 2009 ASCII HTML 15 IKEv2 Redirect REDIRECT REDIRECTED_FROM anycast redirect home agent redirect VPN gateway direct

The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. [STANDARDS-TRACK]

draft-ietf-ipsecme-ikev2-redirect-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5685
RFC5686 RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec Y. Hiwasaki H. Ohmuro October 2009 ASCII HTML 21 RTP Payload type MIME UEMCLIP PCMU Speech Coding

This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. [STANDARDS-TRACK]

draft-ietf-avt-rtp-uemclip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5686
RFC5687 GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements H. Tschofenig H. Schulzrinne March 2010 ASCII HTML 21 Location Information Location Information Server Location by Value Location by Reference

This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-geopriv-l7-lcp-ps-10 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5687
RFC5688 A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes J. Rosenberg January 2010 ASCII HTML 7 SIP IMS

The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports. [STANDARDS-TRACK]

draft-rosenberg-sip-app-media-tag-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5688 10.17487/RFC5688
RFC5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) C. Daboo September 2009 ASCII HTML 12 webdav HTTP

This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. [STANDARDS-TRACK]

draft-ietf-vcarddav-webdav-mkcol-06 RFC4791 RFC4918 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC5689
RFC5690 Adding Acknowledgement Congestion Control to TCP S. Floyd A. Arcia D. Ros J. Iyengar February 2010 ASCII HTML 33 ackcc

This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and the TCP data receiver. The TCP data sender detects lost or Explicit Congestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's) Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-floyd-tcpm-ackcc-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5690
RFC5691 RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio F. de Bont S. Doehla M. Schmidt R. Sperschneider October 2009 ASCII HTML 12 MPEG Surround RFC 3640 RTP MPEG-4 AAC

This memo describes extensions for the RTP payload format defined in RFC 3640 for the transport of MPEG Surround multi-channel audio. Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. [STANDARDS-TRACK]

draft-ietf-avt-rtp-mps-03 RFC3640 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5691
RFC5692 Transmission of IP over Ethernet over IEEE 802.16 Networks H. Jeon S. Jeong M. Riegel October 2009 ASCII HTML 21 Bridge WiMAX Ethernet-CS Cellular

This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. [STANDARDS-TRACK]

draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5692
RFC5693 Application-Layer Traffic Optimization (ALTO) Problem Statement J. Seedorf E. Burger October 2009 ASCII HTML 14 peer-to-peer p2p

Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.

This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. This memo provides information for the Internet community.

draft-ietf-alto-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF app alto 10.17487/RFC5693
RFC5694 Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability G. Camarillo Editor IAB November 2009 ASCII HTML 26 P2P decentralized architecture

In this document, we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. This memo provides information for the Internet community.

draft-iab-p2p-archs-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5694 10.17487/RFC5694
RFC5695 MPLS Forwarding Benchmarking Methodology for IP Flows A. Akhter R. Asati C. Pignataro November 2009 ASCII HTML 27 multiprotocol label switching mpmls forwarding devices

This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. This memo provides information for the Internet community.

draft-ietf-bmwg-mpls-forwarding-meth-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=5695 10.17487/RFC5695
RFC5696 Baseline Encoding and Transport of Pre-Congestion Information T. Moncaster B. Briscoe M. Menth November 2009 ASCII HTML 15 Quality of Service QoS Differentiated Services Admission Control Codepoint Protocol

The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging to PCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. [STANDARDS-TRACK]

draft-ietf-pcn-baseline-encoding-07 RFC6660 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn http://www.rfc-editor.org/errata_search.php?rfc=5696 10.17487/RFC5696
RFC5697 Other Certificates Extension S. Farrell November 2009 ASCII HTML 8 template

Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. This memo defines an Experimental Protocol for the Internet community.

draft-ietf-pkix-other-certs-05 EXPERIMENTAL EXPERIMENTAL IETF sec pkix 10.17487/RFC5697
RFC5698 Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) T. Kunz S. Okunick U. Pordesch November 2009 ASCII HTML 40 long term archive security policy hash algorithm public key algorithm

Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. [STANDARDS-TRACK]

draft-ietf-ltans-dssc-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC5698
RFC5699 RFC5700 RFC5701 IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter November 2009 ASCII HTML 5 border gateway protocol

Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support an IPv6 Address Specific Extended Community. The lack of an IPv6 Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address Specific Extended Community, that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. [STANDARDS TRACK]

draft-ietf-l3vpn-v6-ext-communities-02 RFC7153 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC5701
RFC5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC J. Jansen October 2009 ASCII HTML 10 DNSSEC RSA SHA-256 SHA-512

This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]

draft-ietf-dnsext-dnssec-rsasha256-14 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5702
RFC5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure T. Hansen C. Daboo October 2009 ASCII HTML 18 Email Electronic Mail Internet Mail Message Filtering

This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]

draft-ietf-sieve-mime-loop-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5703 10.17487/RFC5703
RFC5704 Uncoordinated Protocol Development Considered Harmful S. Bryant Editor M. Morrow Editor IAB November 2009 ASCII HTML 15 ITU-T MPLS-TP T-MPLS Joint working team JWT

This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.

This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.

Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.

draft-iab-mpls-tp-uncoord-harmful-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5704
RFC5705 Keying Material Exporters for Transport Layer Security (TLS) E. Rescorla March 2010 ASCII HTML 7 key establishment

A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]

draft-ietf-tls-extractor-07 RFC8446 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=5705 10.17487/RFC5705
RFC5706 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions D. Harrington November 2009 ASCII HTML 35 management operations

New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community.

draft-ietf-opsawg-operations-and-management-09 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC5706
RFC5707 Media Server Markup Language (MSML) A. Saleem Y. Xin G. Sharratt February 2010 ASCII HTML 184

The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXMLThis document is not an Internet Standards Track specification; it is published for informational purposes.

draft-saleem-msml-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5707 10.17487/RFC5707
RFC5708 X.509 Key and Signature Encoding for the KeyNote Trust Management System A. Keromytis January 2010 ASCII HTML 6

This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.

In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-keromytis-keynote-x509-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5708 10.17487/RFC5708
RFC5709 OSPFv2 HMAC-SHA Cryptographic Authentication M. Bhatia V. Manral M. Fanto R. White M. Barnes T. Li R. Atkinson October 2009 ASCII HTML 14 open shortest path first nist secure hash standard hashed message authentication code

This document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]

draft-ietf-ospf-hmac-sha-07 RFC2328 RFC7474 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5709 10.17487/RFC5709
RFC5710 PathErr Message Triggered MPLS and GMPLS LSP Reroutes L. Berger D. Papadimitriou JP. Vasseur January 2010 ASCII HTML 12 resource reservation protocol rsvp multiprotocol label switching generalized mpls rsvp-te

This document describes how Resource ReserVation Protocol (RSVP) PathErr messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. [STANDARDS-TRACK]

draft-ietf-mpls-gmpls-lsp-reroute-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5710
RFC5711 Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages JP. Vasseur Editor G. Swallow I. Minei January 2010 ASCII HTML 7 rsvp-te

The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource Reservation Protocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. [STANDARDS-TRACK]

draft-ietf-mpls-3209-patherr-06 RFC3209 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5711
RFC5712 MPLS Traffic Engineering Soft Preemption M. Meyer Editor JP. Vasseur Editor January 2010 ASCII HTML 13 multiprotocol label switching mpls-te te lsp

This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]

draft-ietf-mpls-soft-preemption-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5712
RFC5713 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) H. Moustafa H. Tschofenig S. De Cnodder January 2010 ASCII HTML 18 ANCP security ANCP threats ANCP attacks

The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.

This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ancp-security-threats-08 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5713
RFC5714 IP Fast Reroute Framework M. Shand S. Bryant January 2010 ASCII HTML 15 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology loop-free-convergence

This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rtgwg-ipfrr-framework-13 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5714
RFC5715 A Framework for Loop-Free Convergence M. Shand S. Bryant January 2010 ASCII HTML 22 IP Fast Reroute MPLS Fast Reroute Routing Convergence Network Topology PLSN not-via Incremental Cost Packet Marking ordered fib ofib

A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.

This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rtgwg-lf-conv-frmwk-07 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC5715
RFC5716 Requirements for Federated File Systems J. Lentini C. Everhart D. Ellard R. Tewari M. Naik January 2010 ASCII HTML 26 Federated File Systems Federated FA FedFS Fed-FS Federation

This document describes and lists the functional requirements of a federated file system and defines related terms. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nfsv4-federated-fs-reqts-06 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC5716
RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF B. Lengyel M. Bjorklund December 2009 ASCII HTML 23 YANG Network Management

The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. [STANDARDS-TRACK]

draft-ietf-netconf-partial-lock-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=5717 10.17487/RFC5717
RFC5718 An In-Band Data Communication Network For the MPLS Transport Profile D. Beller A. Farrel January 2010 ASCII HTML 8 MPLS-TP DCN SCN MCN G-Ach GAL

The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.

This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. [STANDARDS-TRACK]

draft-ietf-mpls-tp-gach-dcn-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5718
RFC5719 Updated IANA Considerations for Diameter Command Code Allocations D. Romascanu H. Tschofenig January 2010 ASCII HTML 5 diameter application diameter commands

The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.

This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. [STANDARDS-TRACK]

draft-ietf-dime-diameter-cmd-iana-01 RFC6733 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5719
RFC5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) F. Templin February 2010 ASCII HTML 26 enterprise network

RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-templin-ranger-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5720
RFC5721 POP3 Support for UTF-8 R. Gellens C. Newman February 2010 ASCII HTML 13 POP UTF8 mail email internationalization charset

This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-pop-09 RFC6856 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5721
RFC5722 Handling of Overlapping IPv6 Fragments S. Krishnan December 2009 ASCII HTML 6 fragmentation overlapping fragments

The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. [STANDARDS-TRACK]

draft-ietf-6man-overlap-fragment-03 RFC2460 RFC6946 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5722 10.17487/RFC5722
RFC5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption Y. Sheffer H. Tschofenig January 2010 ASCII HTML 26 IKE Internet Key Exchange session resumption failover high availability cryptographic ticket cryptographic token stateful resumption stateless resumption

The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency.

To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.

In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.

A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. [STANDARDS-TRACK]

draft-ietf-ipsecme-ikev2-resumption-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5723
RFC5724 URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) E. Wilde A. Vaha-Sipila January 2010 ASCII HTML 18 GSM SMS URI scheme

This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. [STANDARDS-TRACK]

draft-wilde-sms-uri-20 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5724 10.17487/RFC5724
RFC5725 Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen D. Hsu M. Lague February 2010 ASCII HTML 9 Loss repair retransmission FEC

This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avt-post-repair-rtcp-xr-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5725 10.17487/RFC5725
RFC5726 Mobile IPv6 Location Privacy Solutions Y. Qiu F. Zhao Editor R. Koodli February 2010 ASCII HTML 48 mobopts

Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-mobopts-location-privacy-solutions-16 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC5726
RFC5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area J. Peterson C. Jennings R. Sparks March 2010 ASCII HTML 14 RAI sipping

This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.

draft-peterson-rai-rfc3427bis-04 RFC3427 RFC3265 RFC3969 RFC7957 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5727 10.17487/RFC5727
RFC5728 The SatLabs Group DVB-RCS MIB S. Combes P. Amundsen M. Lambert H-P. Lexow March 2010 ASCII HTML 95 management information base digital video broadcasting return channel DVB-RCS-MIB

This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-combes-ipdvb-mib-rcs-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5728 10.17487/RFC5728
RFC5729 Clarifications on the Routing of Diameter Requests Based on the Username and the Realm J. Korhonen Editor M. Jones L. Morand T. Tsou December 2009 ASCII HTML 11 nai network access identifier decorated multi-realm

This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. [STANDARDS-TRACK]

draft-ietf-dime-nai-routing-04 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5729
RFC5730 Extensible Provisioning Protocol (EPP) S. Hollenbeck August 2009 ASCII HTML 67 shared framework mapping

This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]

draft-hollenbeck-rfc4930bis-02 RFC4930 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5730 10.17487/RFC5730
RFC5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping S. Hollenbeck August 2009 ASCII HTML 44 EPP Extensible Provisioning Protocol XML domain domain name

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 4931. [STANDARDS-TRACK]

draft-hollenbeck-rfc4931bis-01 RFC4931 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5731 10.17487/RFC5731
RFC5732 Extensible Provisioning Protocol (EPP) Host Mapping S. Hollenbeck August 2009 ASCII HTML 29 EPP Extensible Provisioning Protocol XML host

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 4932. [STANDARDS-TRACK]

draft-hollenbeck-rfc4932bis-01 RFC4932 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5732
RFC5733 Extensible Provisioning Protocol (EPP) Contact Mapping S. Hollenbeck August 2009 ASCII HTML 41 EPP Extensible Provisioning Protocol XML contact registrant

This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 4933. [STANDARDS-TRACK]

draft-hollenbeck-rfc4933bis-02 RFC4933 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP 10.17487/RFC5733
RFC5734 Extensible Provisioning Protocol (EPP) Transport over TCP S. Hollenbeck August 2009 ASCII HTML 13 EPP Extensible Provisioning Protocol XML TCP TLS

This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 4934. [STANDARDS-TRACK]

draft-hollenbeck-rfc4934bis-01 RFC4934 STD0069 INTERNET STANDARD INTERNET STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5734 10.17487/RFC5734
RFC5735 Special Use IPv4 Addresses M. Cotton L. Vegoda January 2010 ASCII HTML 10 internet protocol space assignments

This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. This memo documents an Internet Best Current Practice.

draft-iana-rfc3330bis-11 RFC3330 RFC6890 RFC6598 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5735 10.17487/RFC5735
RFC5736 IANA IPv4 Special Purpose Address Registry G. Huston M. Cotton L. Vegoda January 2010 ASCII HTML 6

This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iana-special-ipv4-registry-02 RFC6890 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5736
RFC5737 IPv4 Address Blocks Reserved for Documentation J. Arkko M. Cotton L. Vegoda January 2010 ASCII HTML 4 example addresses IPv4

Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iana-ipv4-examples-02 RFC1166 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5737
RFC5738 IMAP Support for UTF-8 P. Resnick C. Newman March 2010 ASCII HTML 15 internet message access protocol imap4rev1

This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-imap-utf8-09 RFC6855 RFC3501 EXPERIMENTAL EXPERIMENTAL IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=5738 10.17487/RFC5738
RFC5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) P. Eronen J. Laganier C. Madson February 2010 ASCII HTML 32 remote vpn access vpn gateway virtual link

When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". This document defines an Experimental Protocol for the Internet community.

draft-ietf-ipsecme-ikev2-ipv6-config-03 EXPERIMENTAL EXPERIMENTAL IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5739 10.17487/RFC5739
RFC5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol B. Adamson C. Bormann M. Handley J. Macker November 2009 ASCII HTML 96 multicast reliable multicast transport negative-acknowledgment forward error correction packet erasure coding group communication

This document describes the messages and procedures of the Negative- ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETF Reliable Multicast Transport (RMT) building blocks in its design. This document obsoletes RFC 3940. [STANDARDS-TRACK]

draft-ietf-rmt-pi-norm-revised-14 RFC3940 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5740
RFC5741 RFC Streams, Headers, and Boilerplates L. Daigle Editor O. Kolkman Editor IAB December 2009 ASCII HTML 16

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-streams-headers-boilerplates-08 RFC7841 RFC2223 RFC4844 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=5741 10.17487/RFC5741
RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions H. Alvestrand R. Housley December 2009 ASCII HTML 9

This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.

This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.

draft-housley-iesg-rfc3932bis-12 RFC3932 RFC2026 RFC3710 BCP0092 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5742
RFC5743 Definition of an Internet Research Task Force (IRTF) Document Stream A. Falk December 2009 ASCII HTML 9 irtf stream

This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-rfcs-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5743
RFC5744 Procedures for Rights Handling in the RFC Independent Submission Stream R. Braden J. Halpern December 2009 ASCII HTML 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

draft-braden-independent-submission-02 RFC4846 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5744
RFC5745 Procedures for Rights Handling in the RFC IAB Stream A. Malis Editor IAB December 2009 ASCII HTML 6 incoming rights outgoing rights ietf trust

This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. This memo provides information for the Internet community.

draft-malis-iab-stream-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5745
RFC5746 Transport Layer Security (TLS) Renegotiation Indication Extension E. Rescorla M. Ray S. Dispensa N. Oskov February 2010 ASCII HTML 15 ssl secure socket layer

Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK]

draft-ietf-tls-renegotiation-03 RFC5246 RFC4366 RFC4347 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC5746
RFC5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions J. Wu Y. Cui X. Li M. Xu C. Metz March 2010 ASCII HTML 15 IPv4/IPv6 coexistence CNGI CERNET2 Softwire mesh

The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. This document defines an Experimental Protocol for the Internet community.

draft-wu-softwire-4over6-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC5747
RFC5748 IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) S. Yoon J. Jeong H. Kim H. Jeong Y. Won August 2010 ASCII HTML 5

This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-seokung-msec-mikey-seed-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5748 10.17487/RFC5748
RFC5749 Distribution of EAP-Based Keys for Handover and Re-Authentication K. Hoeper Editor M. Nakhjiri Y. Ohba Editor March 2010 ASCII HTML 12 security authentication mobility EAP key management key distribution

This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. [STANDARDS-TRACK]

draft-ietf-hokey-key-mgm-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey http://www.rfc-editor.org/errata_search.php?rfc=5749 10.17487/RFC5749
RFC5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling B. Ramsdell S. Turner January 2010 ASCII HTML 21 encryption certificate multipurpose internet mail extensions secure

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. [STANDARDS-TRACK]

draft-ietf-smime-3850bis-11 RFC3850 RFC8550 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime 10.17487/RFC5750
RFC5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification B. Ramsdell S. Turner January 2010 ASCII HTML 45 secure multipurpose internet mail extensions encryption

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]

draft-ietf-smime-3851bis-11 RFC3851 RFC8551 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5751 10.17487/RFC5751
RFC5752 Multiple Signatures in Cryptographic Message Syntax (CMS) S. Turner J. Schaad January 2010 ASCII HTML 17 signeddata signerinfo downgrade attacks algorithm migration

Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the \'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. [STANDARDS-TRACK]

draft-ietf-smime-multisig-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5752 10.17487/RFC5752
RFC5753 Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) S. Turner D. Brown January 2010 ASCII HTML 61 public key digital signatures authentication

This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180-3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-smime-3278bis-09 RFC3278 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5753 10.17487/RFC5753
RFC5754 Using SHA2 Algorithms with Cryptographic Message Syntax S. Turner January 2010 ASCII HTML 10 secure hash algorithm message digest algorithm sha-224 sha-256 sha-384 sha-512 cms dsa digital signature algorithm rsa rivest sharmi adleman ecdsa elliptic curve dsa smimecapabilities

This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK]

draft-ietf-smime-sha2-11 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5754 10.17487/RFC5754
RFC5755 An Internet Attribute Certificate Profile for Authorization S. Farrell R. Housley S. Turner January 2010 ASCII HTML 50 electronic mail email ipsec www security

This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK]

draft-ietf-pkix-3281update-05 RFC3281 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5755 10.17487/RFC5755
RFC5756 Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters S. Turner D. Brown K. Yiu R. Housley T. Polk January 2010 ASCII HTML 6 rsa encryption scheme optical asymmetric encryption padding subjectpublickeyinfo

This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. [STANDARDS-TRACK]

draft-ietf-pkix-rfc4055-update-02 RFC4055 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5756 10.17487/RFC5756
RFC5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey T. Schmidt M. Waehlisch G. Fairhurst February 2010 ASCII HTML 37 PMIPv6 FMIPv6 HMIPv6 SSM ASM MLD Mobile Multicast Routing Hybrid Multicast Wireless Multipoint

This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast and Source-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-mobopts-mmcastv6-ps-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC5757
RFC5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Q. Dang S. Santesson K. Moriarty D. Brown T. Polk January 2010 ASCII HTML 8 digital signature algorithm elliptic curve digital signature algorithm pki

This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK]

draft-ietf-pkix-sha2-dsa-ecdsa-10 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5758 10.17487/RFC5758
RFC5759 Suite B Certificate and Certificate Revocation List (CRL) Profile J. Solinas L. Zieglar January 2010 ASCII HTML 11 x.509 v3 certificates x.509 v2 certificate revocation lists crl

This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-solinas-suiteb-cert-profile-04 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5759
RFC5760 RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback J. Ott J. Chesterfield E. Schooler February 2010 ASCII HTML 66 real-time transport protocol ssm

This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK]

draft-ietf-avt-rtcpssm-19 RFC6128 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5760 10.17487/RFC5760
RFC5761 Multiplexing RTP Data and Control Packets on a Single Port C. Perkins M. Westerlund April 2010 ASCII HTML 13

This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK]

draft-ietf-avt-rtp-and-rtcp-mux-07 RFC3550 RFC3551 RFC8035 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5761 10.17487/RFC5761
RFC5762 RTP and the Datagram Congestion Control Protocol (DCCP) C. Perkins April 2010 ASCII HTML 16 real-time transport protocol

The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. [STANDARDS-TRACK]

draft-ietf-dccp-rtp-07 RFC6773 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC5762
RFC5763 Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) J. Fischl H. Tschofenig E. Rescorla May 2010 ASCII HTML 37 stip session initiation protocol fingerprint attribute dtls handshake

This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]

draft-ietf-sip-dtls-srtp-framework-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5763 10.17487/RFC5763
RFC5764 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) D. McGrew E. Rescorla May 2010 ASCII HTML 26 secure rtp control protocol srtcp

This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]

draft-ietf-avt-dtls-srtp-07 RFC7983 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=5764 10.17487/RFC5764
RFC5765 Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications H. Schulzrinne E. Marocco E. Ivov February 2010 ASCII HTML 28 p2p overlay rtc voip

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-p2prg-rtc-security-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5765 10.17487/RFC5765
RFC5766 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) R. Mahy P. Matthews J. Rosenberg April 2010 ASCII HTML 67 NAT TURN STUN ICE

If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]

draft-ietf-behave-turn-16 RFC8656 RFC8155 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5766 10.17487/RFC5766
RFC5767 User-Agent-Driven Privacy Mechanism for SIP M. Munakata S. Schubert T. Ohba April 2010 ASCII HTML 11 SIP IMS privacy guidelines

This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) and Traversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sip-ua-privacy-08 INFORMATIONAL INFORMATIONAL IETF rai sip 10.17487/RFC5767
RFC5768 Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) J. Rosenberg April 2010 ASCII HTML 6 SIP NAT

This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed. [STANDARDS-TRACK]

draft-ietf-sip-ice-option-tag-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5768
RFC5769 Test Vectors for Session Traversal Utilities for NAT (STUN) R. Denis-Courmont April 2010 ASCII HTML 11 STUN test vectors fingerprint

The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-behave-stun-test-vectors-04 INFORMATIONAL INFORMATIONAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5769 10.17487/RFC5769
RFC5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators M. Komu T. Henderson H. Tschofenig J. Melen A. Keranen Editor April 2010 ASCII HTML 34 ICE HIP relay

This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-nat-traversal-09 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC5770
RFC5771 IANA Guidelines for IPv4 Multicast Address Assignments M. Cotton L. Vegoda D. Meyer March 2010 ASCII HTML 11 internet assigned numbers authority protocol parameters

This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. This memo documents an Internet Best Current Practice.

draft-ietf-mboned-rfc3171bis-08 RFC3138 RFC3171 RFC2780 BCP0051 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=5771 10.17487/RFC5771
RFC5772 A Set of Possible Requirements for a Future Routing Architecture A. Doria E. Davies F. Kastenholz February 2010 ASCII HTML 68 Routing Research Group RRG IDR FDR

The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub- groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.

The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

draft-irtf-routing-reqs-11 HISTORIC HISTORIC IRTF 10.17487/RFC5772
RFC5773 Analysis of Inter-Domain Routing Requirements and History E. Davies A. Doria February 2010 ASCII HTML 51 History IRTF Routing Research Group RRG Routing Requirements IDR FDR

This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication. This document defines a Historic Document for the Internet community.

draft-irtf-routing-history-10 HISTORIC HISTORIC IRTF http://www.rfc-editor.org/errata_search.php?rfc=5773 10.17487/RFC5773
RFC5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition K. Wolf A. Mayrhofer March 2010 ASCII HTML 33

This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. This memo documents an Internet Best Current Practice.

draft-ietf-geopriv-civic-address-recommendations-03 RFC4776 BCP0154 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5774 10.17487/RFC5774
RFC5775 Asynchronous Layered Coding (ALC) Protocol Instantiation M. Luby M. Watson L. Vicisano April 2010 ASCII HTML 24 Forward Error Correction FEC Layered Coding Transport LCT Building Block WEBRC reliable +object delivery reliable file delivery broadcast multicast

This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. [STANDARDS-TRACK]

draft-ietf-rmt-pi-alc-revised-10 RFC3450 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC5775
RFC5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca A. Francillon S. Faurite April 2010 ASCII HTML 58 TESLA FLUTE ALC NORM

This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.

draft-ietf-msec-tesla-for-alc-norm-10 EXPERIMENTAL EXPERIMENTAL IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=5776 10.17487/RFC5776
RFC5777 Traffic Classification and Quality of Service (QoS) Attributes for Diameter J. Korhonen H. Tschofenig M. Arumaithurai M. Jones Editor A. Lior February 2010 ASCII HTML 43 Diameter Qos Attributes Traffic classification Filtering Firewalling

This document defines a number of Diameter attribute-value pairs (AVPs) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. [STANDARDS-TRACK]

draft-ietf-dime-qos-attributes-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5777 10.17487/RFC5777
RFC5778 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction J. Korhonen Editor H. Tschofenig J. Bournelle G. Giaretta M. Nakhjiri February 2010 ASCII HTML 34

Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and a Diameter server.

This document defines the home agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. [STANDARDS-TRACK]

draft-ietf-dime-mip6-split-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=5778 10.17487/RFC5778
RFC5779 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server J. Korhonen Editor J. Bournelle K. Chowdhury A. Muhanna U. Meyer February 2010 ASCII HTML 20 aaa authentication authorization and accounting

This specification defines Authentication, Authorization, and Accounting (AAA) interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. [STANDARDS-TRACK]

draft-ietf-dime-pmip6-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5779
RFC5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) D. MacDonald B. Lowekamp May 2010 ASCII HTML 27 NAT type diagnostics

This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. This document defines an Experimental Protocol for the Internet community.

draft-ietf-behave-nat-behavior-discovery-08 RFC8553 EXPERIMENTAL EXPERIMENTAL IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=5780 10.17487/RFC5780
RFC5781 The rsync URI Scheme S. Weiler D. Ward R. Housley February 2010 ASCII HTML 4 rsyncuri

This document specifies the rsync Uniform Resource Identifier (URI) scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-weiler-rsync-uri-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5781
RFC5782 DNS Blacklists and Whitelists J. Levine February 2010 ASCII HTML 11 mail electronic mail DNS spam blacklist whitelist

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-asrg-dnsbl-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5782 10.17487/RFC5782
RFC5783 Congestion Control in the RFC Series M. Welzl W. Eddy February 2010 ASCII HTML 28

This document is an informational snapshot taken by the IRTF\'s Internet Congestion Control Research Group (ICCRG) in October 2008. It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-iccrg-cc-rfcs-07 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=5783 10.17487/RFC5783
RFC5784 Sieve Email Filtering: Sieves and Display Directives in XML N. Freed S. Vedam March 2010 ASCII HTML 32 SMTP ESMTP Sieve

This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.

The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. [STANDARDS-TRACK]

draft-freed-sieve-in-xml-07 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5784 10.17487/RFC5784
RFC5785 Defining Well-Known Uniform Resource Identifiers (URIs) M. Nottingham E. Hammer-Lahav April 2010 ASCII HTML 8 well-known locations

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]

draft-nottingham-site-meta-05 RFC8615 RFC2616 RFC2818 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5785 10.17487/RFC5785
RFC5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions R. Aggarwal K. Kompella March 2010 ASCII HTML 7

OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE-enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE-enabled links, and the local address corresponding to the Router ID.

In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) Traffic Engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.

This document describes procedures that enhance OSPF TE to advertise a router's local addresses. [STANDARDS-TRACK]

draft-ietf-ospf-te-node-addr-07 RFC3630 RFC6827 RFC8687 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=5786 10.17487/RFC5786
RFC5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing D. Papadimitriou March 2010 ASCII HTML 29 itu-t ospfv2 link state routing protocol

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ccamp-gmpls-ason-routing-ospf-09 RFC6827 EXPERIMENTAL EXPERIMENTAL IETF rtg ccamp 10.17487/RFC5787
RFC5788 IMAP4 Keyword Registry A. Melnikov D. Cridland March 2010 ASCII HTML 11 IMAP email tag label keyword

The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. [STANDARDS TRACK]

draft-melnikov-imap-keywords-10 RFC8621 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5788
RFC5789 PATCH Method for HTTP L. Dusseault J. Snell March 2010 ASCII HTML 10 HTTP PATCH Hypertext Transfer Protocol

Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]

draft-dusseault-http-patch-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5789 10.17487/RFC5789
RFC5790 Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols H. Liu W. Cao H. Asaeda February 2010 ASCII HTML 17 IGMP MLD Lite lightweight

This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]

draft-ietf-mboned-lightweight-igmpv3-mldv2-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC5790
RFC5791 RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete J. Reschke J. Kunze February 2010 ASCII HTML 2 DCMI Dublin Core Metadata Initiative XHTML HTML metadata

This document obsoletes RFC 2731, "Encoding Dublin Core Metadata in HTML", as further development of this specification has moved to the Dublin Core Metadata Initiative (DCMI). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-reschke-rfc2731bis-05 RFC2731 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5791 10.17487/RFC5791
RFC5792 PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) P. Sangster K. Narayan March 2010 ASCII HTML 83

This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

draft-ietf-nea-pa-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5792 10.17487/RFC5792
RFC5793 PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) R. Sahita S. Hanna R. Hurst K. Narayan March 2010 ASCII HTML 76 NEA Network Endpoint Assessment

This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. [STANDARDS-TRACK]

draft-ietf-nea-pb-tnc-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea http://www.rfc-editor.org/errata_search.php?rfc=5793 10.17487/RFC5793
RFC5794 A Description of the ARIA Encryption Algorithm J. Lee J. Lee J. Kim D. Kwon C. Kim March 2010 ASCII HTML 18 ARIA encryption block cipher

This document describes the ARIA encryption algorithm. ARIA is a 128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-nsri-aria-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5794 10.17487/RFC5794
RFC5795 The RObust Header Compression (ROHC) Framework K. Sandlund G. Pelletier L-E. Jonsson March 2010 ASCII HTML 41

The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.

The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.

This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK]

draft-ietf-rohc-rfc4995bis-03 RFC4995 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5795 10.17487/RFC5795
RFC5796 Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages W. Atwood S. Islam M. Siami March 2010 ASCII HTML 21 security PIM-SM routing security multicast routing link-local message Protocol Independent Multicast Sparse Mode

RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security (IPsec) Encapsulating Security Payload (ESP) or (optionally) the Authentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. [STANDARDS-TRACK]

draft-ietf-pim-sm-linklocal-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC5796
RFC5797 FTP Command and Extension Registry J. Klensin A. Hoenes March 2010 ASCII HTML 10 FTP FEAT command FTP FEAT response

Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. [STANDARDS-TRACK]

draft-klensin-ftp-registry-04 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5797 10.17487/RFC5797
RFC5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 S. Nadas Editor March 2010 ASCII HTML 40

This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6 Neighbor Discovery mechanisms. [STANDARDS-TRACK]

draft-ietf-vrrp-unified-spec-05 RFC3768 PROPOSED STANDARD PROPOSED STANDARD IETF rtg vrrp http://www.rfc-editor.org/errata_search.php?rfc=5798 10.17487/RFC5798
RFC5799 RFC5800 RFC5801 Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family S. Josefsson N. Williams July 2010 ASCII HTML 26

This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. [STANDARDS-TRACK]

draft-ietf-sasl-gs2-20 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5801 10.17487/RFC5801
RFC5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms C. Newman A. Menon-Sen A. Melnikov N. Williams July 2010 ASCII HTML 28 simple authentication and security layer

The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.

This specification describes a family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. [STANDARDS-TRACK]

draft-ietf-sasl-scram-11 RFC7677 PROPOSED STANDARD PROPOSED STANDARD IETF sec sasl http://www.rfc-editor.org/errata_search.php?rfc=5802 10.17487/RFC5802
RFC5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets A. Melnikov July 2010 ASCII HTML 4 authpassword simple authentication and security layer sasl

This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-melnikov-sasl-scram-ldap-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5803 10.17487/RFC5803
RFC5804 A Protocol for Remotely Managing Sieve Scripts A. Melnikov Editor T. Martin July 2010 ASCII HTML 49 managesieve

Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. [STANDARDS TRACK]

draft-ietf-sieve-managesieve-09 RFC7817 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=5804 10.17487/RFC5804
RFC5805 Lightweight Directory Access Protocol (LDAP) Transactions K. Zeilenga March 2010 ASCII HTML 11 acid atomic consistency isolation durability

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. This document defines an Experimental Protocol for the Internet community.

draft-zeilenga-ldap-txn-15 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5805 10.17487/RFC5805
RFC5806 Diversion Indication in SIP S. Levy M. Mohali Editor March 2010 ASCII HTML 53

This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows.

This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent.

This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies that receive diversion information may use this as supplemental information for feature invocation decisions. This document defines a Historic Document for the Internet community.

draft-levy-sip-diversion-11 HISTORIC HISTORIC INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5806 10.17487/RFC5806
RFC5807 Definition of Master Key between PANA Client and Enforcement Point Y. Ohba A. Yegin March 2010 ASCII HTML 7 protocol for carrying authentication for network access

This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. [STANDARDS-TRACK]

draft-ohba-pana-pemk-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5807
RFC5808 Requirements for a Location-by-Reference Mechanism R. Marshall Editor May 2010 ASCII HTML 14

This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-geopriv-lbyr-requirements-09 INFORMATIONAL INFORMATIONAL IETF rai geopriv 10.17487/RFC5808
RFC5809 RFC5810 Forwarding and Control Element Separation (ForCES) Protocol Specification A. Doria Editor J. Hadi Salim Editor R. Haas Editor H. Khosravi Editor W. Wang Editor L. Dong R. Gopal J. Halpern March 2010 ASCII HTML 124 control elements forwarding elements fe ce network element ne tml transport mapping layer

This document specifies the Forwarding and Control Element Separation (ForCES) protocol. The ForCES protocol is used for communications between Control Elements (CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). [STANDARDS-TRACK]

draft-ietf-forces-protocol-22 RFC7121 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5810 10.17487/RFC5810
RFC5811 SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol J. Hadi Salim K. Ogawa March 2010 ASCII HTML 28 ForCES TML stream conrol transmission protocol

This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. [STANDARDS TRACK]

draft-ietf-forces-sctptml-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5811
RFC5812 Forwarding and Control Element Separation (ForCES) Forwarding Element Model J. Halpern J. Hadi Salim March 2010 ASCII HTML 134 forwarding element control element

This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. [STANDARDS-TRACK]

draft-ietf-forces-model-16 RFC7408 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=5812 10.17487/RFC5812
RFC5813 Forwarding and Control Element Separation (ForCES) MIB R. Haas March 2010 ASCII HTML 17 management information base network element ne forces-mib

This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). [STANDARDS-TRACK]

draft-ietf-forces-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC5813
RFC5814 Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks W. Sun Editor G. Zhang Editor March 2010 ASCII HTML 44 Signaling performance RSVP-TE delay measurement control plane performance

Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.

This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. [STANDARDS-TRACK]

draft-ietf-ccamp-lsp-dppm-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5814
RFC5815 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz April 2010 ASCII HTML 64 Selector Collector Exporter Sampling Filtering IPFIX IPFIX-MIB IPFIX-SELECTOR-MIB

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]

draft-ietf-ipfix-mib-10 RFC6615 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=5815 10.17487/RFC5815
RFC5816 ESSCertIDv2 Update for RFC 3161 S. Santesson N. Pope April 2010 ASCII HTML 5 signer certificate secure hash algorithm sha-1

This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK]

draft-ietf-pkix-rfc3161-update-09 RFC3161 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC5816
RFC5817 Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks Z. Ali JP. Vasseur A. Zamfir J. Newton April 2010 ASCII HTML 11 mpls-te te

MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.

This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-mpls-graceful-shutdown-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=5817 10.17487/RFC5817
RFC5818 Data Channel Status Confirmation Extensions for the Link Management Protocol D. Li H. Xu S. Bardalai J. Meuric D. Caviglia April 2010 ASCII HTML 15 LMP

This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-Switching Routers (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. [STANDARDS-TRACK]

draft-ietf-ccamp-confirm-data-channel-status-09 RFC6898 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5818
RFC5819 IMAP4 Extension for Returning STATUS Information in Extended LIST A. Melnikov T. Sirainen March 2010 ASCII HTML 6 list lsub

Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK]

draft-ietf-morg-status-in-list-01 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=5819 10.17487/RFC5819
RFC5820 Extensions to OSPF to Support Mobile Ad Hoc Networking A. Roy Editor M. Chandra Editor March 2010 ASCII HTML 41 open shortest path first manet ospf-or ospf-overlapping relay link-local signaling lls ospf-manet

This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-Overlapping Relay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. [STANDARDS-TRACK]

draft-ietf-ospf-manet-or-03 RFC7137 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC5820
RFC5821 RFC5822 RFC5823 RFC5824 Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN K. Kumaki Editor R. Zhang Y. Kamite April 2010 ASCII HTML 27 triple-play service

Today, customers expect to run triple-play services through BGP/MPLS IP-VPNs. Some service providers will deploy services that request Quality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.

Service providers can use both an MPLS and an MPLS Traffic Engineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP-VPN. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l3vpn-e2e-rsvp-te-reqts-05 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC5824
RFC5825 Displaying Downgraded Messages for Email Address Internationalization K. Fujiwara B. Leiba April 2010 ASCII HTML 14 EAI Email Address Internationalization Downgrade MAIL

This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-downgraded-display-03 RFC6530 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5825
RFC5826 Home Automation Routing Requirements in Low-Power and Lossy Networks A. Brandt J. Buron G. Porcu April 2010 ASCII HTML 17 roll routing over low power and lossy

This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio-frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-roll-home-routing-reqs-11 INFORMATIONAL INFORMATIONAL IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=5826 10.17487/RFC5826
RFC5827 Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) M. Allman K. Avrachenkov U. Ayesta J. Blanton P. Hurtig May 2010 ASCII HTML 15 transmission control protocol fast retransmission

This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS-TRACK]

draft-ietf-tcpm-early-rexmt-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC5827
RFC5828 Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework D. Fedyk L. Berger L. Andersson March 2010 ASCII HTML 20 transport networks

There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing (TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized- MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-gmpls-ethernet-arch-09 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC5828
RFC5829 Link Relation Types for Simple Version Navigation between Web Resources A. Brown G. Clemm J. Reschke Editor April 2010 ASCII HTML 12

This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-brown-versioning-link-relations-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5829
RFC5830 GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms V. Dolmatov Editor March 2010 ASCII HTML 19 russian federal standard electronic encryption decryption message authentication russian cryptographic standard

This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-dolmatov-cryptocom-gost2814789-08 RFC8891 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5830 10.17487/RFC5830
RFC5831 GOST R 34.11-94: Hash Function Algorithm V. Dolmatov Editor March 2010 ASCII HTML 17 russian federal standard russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-dolmatov-cryptocom-gost341194-07 RFC6986 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5831 10.17487/RFC5831
RFC5832 GOST R 34.10-2001: Digital Signature Algorithm V. Dolmatov Editor March 2010 ASCII HTML 22 russian federal standard digital signature russian cryptographic standard russian cryptography

This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification.

draft-dolmatov-cryptocom-gost34102001-08 RFC7091 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5832 10.17487/RFC5832
RFC5833 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII HTML 73 mib CAPWAP-BASE-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-capwap-base-mib-09 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5833
RFC5834 Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 Y. Shi Editor D. Perkins Editor C. Elliott Editor Y. Zhang Editor May 2010 ASCII HTML 25 mib CAPWAP-DOT11-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple Network Management Protocol (SNMP). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-capwap-802dot11-mib-06 INFORMATIONAL INFORMATIONAL IETF ops capwap 10.17487/RFC5834
RFC5835 Framework for Metric Composition A. Morton Editor S. Van den Berghe Editor April 2010 ASCII HTML 18

This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-framework-compagg-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC5835
RFC5836 Extensible Authentication Protocol (EAP) Early Authentication Problem Statement Y. Ohba Editor Q. Wu Editor G. Zorn Editor April 2010 ASCII HTML 20 eap early authentication

Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-hokey-preauth-ps-12 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC5836
RFC5837 Extending ICMP for Interface and Next-Hop Identification A. Atlas Editor R. Bonica Editor C. Pignataro Editor N. Shen JR. Rivers April 2010 ASCII HTML 18 Internet Control Message Protocol

This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded.

Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK]

draft-atlas-icmp-unnumbered-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5837
RFC5838 Support of Address Families in OSPFv3 A. Lindem Editor S. Mirtorabi A. Roy M. Barnes R. Aggarwal April 2010 ASCII HTML 13 af instance id

This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]

draft-ietf-ospf-af-alt-10 RFC6969 RFC7949 RFC8362 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC5838
RFC5839 An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification A. Niemi D. Willis Editor May 2010 ASCII HTML 25 SIP events subnot-etags optimization

The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. [STANDARDS-TRACK]

draft-ietf-sipcore-subnot-etags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC5839
RFC5840 Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility K. Grewal G. Montenegro M. Bhatia April 2010 ASCII HTML 15 wesp

This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS-TRACK]

draft-ietf-ipsecme-traffic-visibility-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5840
RFC5841 TCP Option to Denote Packet Mood R. Hay W. Turkal April 1 2010 ASCII HTML 9

This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-1april2010-tcp-option-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5841 10.17487/RFC5841
RFC5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) G. Clemm J. Crawford J. Reschke Editor J. Whitehead April 2010 ASCII HTML 45 HTTP WebDAV collections hard link

This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. This document defines an Experimental Protocol for the Internet community.

draft-ietf-webdav-bind-27 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5842
RFC5843 Additional Hash Algorithms for HTTP Instance Digests A. Bryan April 2010 ASCII HTML 5 Hypertext Transfer Protocol HTTP Digest Algorithm Values registry update

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" defines values for digest algorithms used by Instance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-bryan-http-digest-algorithm-values-update-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5843 10.17487/RFC5843
RFC5844 IPv4 Support for Proxy Mobile IPv6 R. Wakikawa S. Gundavelli May 2010 ASCII HTML 49 NAT traversal Dual Stack Mobility IPv4 Support IPv4 Support for PMIPv6

This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. [STANDARDS-TRACK]

draft-ietf-netlmm-pmip6-ipv4-support-18 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5844
RFC5845 Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 A. Muhanna M. Khalil S. Gundavelli K. Leung June 2010 ASCII HTML 25 PMIP6 PMIPv6 Downlink GRE Key Uplink GRE Key TLV-Header Tunneling TLV-Header Tunneling GRE Key Exchange

This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. [STANDARDS-TRACK]

draft-ietf-netlmm-grekey-option-09 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm 10.17487/RFC5845
RFC5846 Binding Revocation for IPv6 Mobility A. Muhanna M. Khalil S. Gundavelli K. Chowdhury P. Yegani June 2010 ASCII HTML 39 PMIP6 PMIPv6 Binding Revocation Indication BRI Binding Revocation Acknowledgement BRA MIP6 DSMIP6 Multiple Care-of Addresses PMIPv6 Revocation Bulk PMIPv6 Revocation

This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. [STANDARDS-TRACK]

draft-ietf-mext-binding-revocation-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC5846
RFC5847 Heartbeat Mechanism for Proxy Mobile IPv6 V. Devarapalli Editor R. Koodli Editor H. Lim N. Kant S. Krishnan J. Laganier June 2010 ASCII HTML 11 Node Reachability Restarts Failure Detection

Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. [STANDARDS TRACK]

draft-ietf-netlmm-pmipv6-heartbeat-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netlmm http://www.rfc-editor.org/errata_search.php?rfc=5847 10.17487/RFC5847
RFC5848 Signed Syslog Messages J. Kelsey J. Callas A. Clemm May 2010 ASCII HTML 40 syslog syslog-sign

This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK]

draft-ietf-syslog-sign-29 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC5848
RFC5849 The OAuth 1.0 Protocol E. Hammer-Lahav Editor April 2010 ASCII HTML 38 authorization delegation

OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hammer-oauth-10 RFC6749 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5849 10.17487/RFC5849
RFC5850 A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP) R. Mahy R. Sparks J. Rosenberg D. Petrie A. Johnston Editor May 2010 ASCII HTML 44 call control multiparty features mixing refer 3pcc Refer method Replaces header field Join header field conferencing

This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol (SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-cc-framework-12 INFORMATIONAL INFORMATIONAL IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=5850 10.17487/RFC5850
RFC5851 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks S. Ooghe N. Voigt M. Platnic T. Haag S. Wadhwa May 2010 ASCII HTML 47 Access Node Control Protocol Topology Discovery Loop Configuration Remote Connectivity Test Multicast Access Node Network Access Server

The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.

This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ancp-framework-13 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC5851
RFC5852 RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network D. Caviglia D. Ceccarelli D. Bramanti D. Li S. Bardalai April 2010 ASCII HTML 23 resource reservation protocol handover procedures

In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or a Management System (Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.

This memo describes an extension to GMPLS Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. [STANDARDS-TRACK]

draft-ietf-ccamp-pc-spc-rsvpte-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC5852
RFC5853 Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments J. Hautakorpi Editor G. Camarillo R. Penfield A. Hawrylyshen M. Bhatia April 2010 ASCII HTML 26

This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-sbc-funcs-09 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5853
RFC5854 The Metalink Download Description Format A. Bryan T. Tsujikawa N. McNab P. Poeml June 2010 ASCII HTML 39 file transfer mirrors data integrity hash xml http hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. [STANDARDS-TRACK]

draft-bryan-metalink-28 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5854
RFC5855 Nameservers for IPv4 and IPv6 Reverse Zones J. Abley T. Manderson May 2010 ASCII HTML 12 IN-ADDR.ARPA IP6.ARPA reverse mapping

This document specifies a stable naming scheme for the nameservers that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These zones contain data that facilitate reverse mapping (address to name). This memo documents an Internet Best Current Practice.

draft-jabley-reverse-servers-01 BCP0155 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC5855
RFC5856 Integration of Robust Header Compression over IPsec Security Associations E. Ertekin R. Jasani C. Christou C. Bormann May 2010 ASCII HTML 15 ROHC ROHCoIPsec

IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rohc-hcoipsec-13 INFORMATIONAL INFORMATIONAL IETF tsv rohc 10.17487/RFC5856
RFC5857 IKEv2 Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou R. Jasani T. Kivinen C. Bormann May 2010 ASCII HTML 13 ROHC ROHCoIPsec

In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). [STANDARDS-TRACK]

draft-ietf-rohc-ikev2-extensions-hcoipsec-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5857 10.17487/RFC5857
RFC5858 IPsec Extensions to Support Robust Header Compression over IPsec E. Ertekin C. Christou C. Bormann May 2010 ASCII HTML 15 ROHC ROHCoIPsec

Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the Security Policy Database (SPD) and Security Association Database (SAD) are required. This document describes the IPsec extensions required to support ROHCoIPsec. [STANDARDS-TRACK]

draft-ietf-rohc-ipsec-extensions-hcoipsec-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rohc http://www.rfc-editor.org/errata_search.php?rfc=5858 10.17487/RFC5858
RFC5859 TFTP Server Address Option for DHCPv4 R. Johnson June 2010 ASCII HTML 6 voip

This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic Host Configuration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-raj-dhc-tftp-addr-option-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5859
RFC5860 Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks M. Vigoureux Editor D. Ward Editor M. Betts Editor May 2010 ASCII HTML 17 MPLS-TP OAM

This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK]

draft-ietf-mpls-tp-oam-requirements-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC5860
RFC5861 HTTP Cache-Control Extensions for Stale Content M. Nottingham May 2010 ASCII HTML 6

This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-nottingham-http-stale-controls-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5861 10.17487/RFC5861
RFC5862 Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE S. Yasukawa A. Farrel June 2010 ASCII HTML 11 mpls gmpls

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-p2mp-req-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC5862
RFC5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations T. Hansen E. Siegel P. Hallam-Baker D. Crocker May 2010 ASCII HTML 51 Email Electronic Mail Internet Mail Message Verification

DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dkim-deployment-11 INFORMATIONAL INFORMATIONAL IETF sec dkim 10.17487/RFC5863
RFC5864 DNS SRV Resource Records for AFS R. Allbery April 2010 ASCII HTML 10 domain name system srv rr distributed file system afsdb rr

This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC 1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. [STANDARDS TRACK]

draft-allbery-afs-srv-records-05 RFC1183 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5864 10.17487/RFC5864
RFC5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic F. Baker J. Polk M. Dolly May 2010 ASCII HTML 14 real-time traffic

This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the Expedited Forwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the Expedited Forwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. [STANDARDS-TRACK]

draft-ietf-tsvwg-admitted-realtime-dscp-07 RFC4542 RFC4594 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=5865 10.17487/RFC5865
RFC5866 Diameter Quality-of-Service Application D. Sun Editor P. McCann H. Tschofenig T. Tsou A. Doria G. Zorn Editor May 2010 ASCII HTML 51 Diameter AAA QoS Policy VoIP SIP

This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. [STANDARDS TRACK]

draft-ietf-dime-diameter-qos-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC5866
RFC5867 Building Automation Routing Requirements in Low-Power and Lossy Networks J. Martocci Editor P. De Mil N. Riou W. Vermeylen June 2010 ASCII HTML 26

The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power and Lossy Networks (LLNs) in various markets: industrial, commercial (building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-roll-building-routing-reqs-09 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC5867
RFC5868 Problem Statement on the Cross-Realm Operation of Kerberos S. Sakane K. Kamada S. Zrelli M. Ishiyama May 2010 ASCII HTML 13

This document provides background information regarding large-scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.

This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-krb-wg-cross-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC5868
RFC5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) H. Krawczyk P. Eronen May 2010 ASCII HTML 14

This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-krawczyk-hkdf-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5869 10.17487/RFC5869
RFC5870 A Uniform Resource Identifier for Geographic Locations ('geo' URI) A. Mayrhofer C. Spanring June 2010 ASCII HTML 23 geography geo uri scheme

This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo\' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). [STANDARDS-TRACK]

draft-ietf-geopriv-geo-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5870
RFC5871 IANA Allocation Guidelines for the IPv6 Routing Header J. Arkko S. Bradner May 2010 ASCII HTML 3 routing type field

This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. [STANDARDS TRACK]

draft-ietf-6man-iana-routing-header-00 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5871
RFC5872 IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) J. Arkko A. Yegin May 2010 ASCII HTML 5

This document relaxes the IANA rules for the Protocol for Carrying Authentication for Network Access (PANA). [STANDARDS-TRACK]

draft-arkko-pana-iana-02 RFC5191 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5872
RFC5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA) Y. Ohba A. Yegin May 2010 ASCII HTML 8

This document defines an extension to the Protocol for Carrying Authentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pana-preauth-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC5873
RFC5874 An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources J. Rosenberg J. Urpalainen May 2010 ASCII HTML 24 SIP Instant Messaging

This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package. [STANDARDS-TRACK]

draft-ietf-simple-xcap-diff-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC5874
RFC5875 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package J. Urpalainen D. Willis Editor May 2010 ASCII HTML 27 xcap-diff xcap diff

This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. [STANDARDS TRACK]

draft-ietf-sip-xcapevent-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5875
RFC5876 Updates to Asserted Identity in the Session Initiation Protocol (SIP) J. Elwell April 2010 ASCII HTML 11 SIP P-Asserted-Identity

The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of the P-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use of P-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extends RFC 3325 to cover these situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-update-pai-09 RFC3325 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5876
RFC5877 The application/pkix-attr-cert Media Type for Attribute Certificates R. Housley May 2010 ASCII HTML 4

This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-attr-cert-mime-type-03 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5877 10.17487/RFC5877
RFC5878 Transport Layer Security (TLS) Authorization Extensions M. Brown R. Housley May 2010 ASCII HTML 19 handshake protocol

This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message. This document defines an Experimental Protocol for the Internet community.

draft-housley-tls-authz-extns-09 RFC5246 RFC8447 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5878 10.17487/RFC5878
RFC5879 Heuristics for Detecting ESP-NULL Packets T. Kivinen D. McDonald May 2010 ASCII HTML 32 IPsec Wrapped ESP (WESP) deep-inspection packet inspection

This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-esp-null-heuristics-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5879
RFC5880 Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII HTML 49

This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]

draft-ietf-bfd-base-11 RFC7419 RFC7880 RFC8562 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5880 10.17487/RFC5880
RFC5881 Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) D. Katz D. Ward June 2010 ASCII HTML 7

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRACK]

draft-ietf-bfd-v4v6-1hop-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5881 10.17487/RFC5881
RFC5882 Generic Application of Bidirectional Forwarding Detection (BFD) D. Katz D. Ward June 2010 ASCII HTML 17

This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. [STANDARDS-TRACK]

draft-ietf-bfd-generic-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5882 10.17487/RFC5882
RFC5883 Bidirectional Forwarding Detection (BFD) for Multihop Paths D. Katz D. Ward June 2010 ASCII HTML 6

This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. [STANDARDS-TRACK]

draft-ietf-bfd-multihop-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC5883
RFC5884 Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) R. Aggarwal K. Kompella T. Nadeau G. Swallow June 2010 ASCII HTML 12 Multiprotocol Label Switching lsp ping

One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. [STANDARDS-TRACK]

draft-ietf-bfd-mpls-07 RFC1122 RFC7726 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=5884 10.17487/RFC5884
RFC5885 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) T. Nadeau Editor C. Pignataro Editor June 2010 ASCII HTML 14 Pseudowire VCCV BFD VCCV-BFD PW OAM

This document describes Connectivity Verification (CV) Types using Bidirectional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. [STANDARDS-TRACK]

draft-ietf-pwe3-vccv-bfd-07 RFC6478 RFC7885 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC5885
RFC5886 A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture JP. Vasseur Editor JL. Le Roux Y. Ikejiri June 2010 ASCII HTML 26

A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".

In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. [STANDARDS-TRACK]

draft-ietf-pce-monitoring-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC5886
RFC5887 Renumbering Still Needs Work B. Carpenter R. Atkinson H. Flinck May 2010 ASCII HTML 35

This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-carpenter-renum-needs-work-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5887
RFC5888 The Session Description Protocol (SDP) Grouping Framework G. Camarillo H. Schulzrinne June 2010 ASCII HTML 21 SDP grouping SIP

In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK]

draft-ietf-mmusic-rfc3388bis-04 RFC3388 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5888 10.17487/RFC5888
RFC5889 IP Addressing Model in Ad Hoc Networks E. Baccelli Editor M. Townsley Editor September 2010 ASCII HTML 8 mobile network ad hoc network MANET network architecture addressing framework configuration routing IP networks

This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-autoconf-adhoc-addr-model-03 INFORMATIONAL INFORMATIONAL IETF int autoconf 10.17487/RFC5889
RFC5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework J. Klensin August 2010 ASCII HTML 23 IDNA2008 idn ascii characters

This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]

draft-ietf-idnabis-defs-13 RFC3490 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5890 10.17487/RFC5890
RFC5891 Internationalized Domain Names in Applications (IDNA): Protocol J. Klensin August 2010 ASCII HTML 17 IDNA2008 idn ascii characters idna applications

This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]

draft-ietf-idnabis-protocol-18 RFC3490 RFC3491 RFC3492 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5891 10.17487/RFC5891
RFC5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) P. Faltstrom Editor August 2010 ASCII HTML 70 IDNA DNS IDN Unicode IDNA2008

This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).

It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]

draft-ietf-idnabis-tables-09 RFC8753 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis http://www.rfc-editor.org/errata_search.php?rfc=5892 10.17487/RFC5892
RFC5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) H. Alvestrand Editor C. Karp August 2010 ASCII HTML 17 IDNA2008 idn ascii characters Bidi

The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]

draft-ietf-idnabis-bidi-07 PROPOSED STANDARD PROPOSED STANDARD IETF app idnabis 10.17487/RFC5893
RFC5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale J. Klensin August 2010 ASCII HTML 43 IDNA2008 idn ascii characters

Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-idnabis-rationale-17 INFORMATIONAL INFORMATIONAL IETF app idnabis 10.17487/RFC5894
RFC5895 Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 P. Resnick P. Hoffman September 2010 ASCII HTML 7 user input character mapping locale user interface Unicode

In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-resman-idna2008-mappings-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5895
RFC5896 Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy L. Hornquist Astrand S. Hartman June 2010 ASCII HTML 6

Several Generic Security Service Application Program Interface (GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, including CIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). [STANDARDS-TRACK]

draft-lha-gssapi-delegate-policy-05 RFC2743 RFC2744 RFC4120 RFC4121 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5896 10.17487/RFC5896
RFC5897 Identification of Communications Services in the Session Initiation Protocol (SIP) J. Rosenberg June 2010 ASCII HTML 23 service identification

This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-service-identification-04 INFORMATIONAL INFORMATIONAL IETF rai sipping 10.17487/RFC5897
RFC5898 Connectivity Preconditions for Session Description Protocol (SDP) Media Streams F. Andreasen G. Camarillo D. Oran D. Wing July 2010 ASCII HTML 17 SIP preconditions connection connectivity

This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. [STANDARDS-TRACK]

draft-ietf-mmusic-connectivity-precon-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5898
RFC5899 RFC5900 RFC5901 Extensions to the IODEF-Document Class for Reporting Phishing P. Cain D. Jevans July 2010 ASCII HTML 51 Incident Object Description Exchange Format

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. [STANDARDS-TRACK]

draft-cain-post-inch-phishingextns-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5901
RFC5902 IAB Thoughts on IPv6 Network Address Translation D. Thaler L. Zhang G. Lebovitz July 2010 ASCII HTML 15 NAT IPv6 Transparency End-to-End Privacy Multihoming

There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-ipv6-nat-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC5902
RFC5903 Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 D. Fu J. Solinas June 2010 ASCII HTML 16 Elliptic Curve Cryptography ECC Internet Key Exchange elliptic curve Diffie-Hellman suite b nist curve

This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-solinas-rfc4753bis-01 RFC4753 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5903 10.17487/RFC5903
RFC5904 RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support G. Zorn June 2010 ASCII HTML 15 RADIUS AAA IEEE 802.16

This document defines a set of Remote Authentication Dial-In User Service (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zorn-radius-pkmv1-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5904
RFC5905 Network Time Protocol Version 4: Protocol and Algorithms Specification D. Mills J. Martin Editor J. Burbank W. Kasch June 2010 ASCII HTML 110 NTP SNTP Synchronization

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]

draft-ietf-ntp-ntpv4-proto-13 RFC1305 RFC4330 RFC7822 RFC8573 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5905 10.17487/RFC5905
RFC5906 Network Time Protocol Version 4: Autokey Specification B. Haberman Editor D. Mills June 2010 ASCII HTML 58 ntp ntpv4 public key cryptography

This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition, Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.

This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual Memory System (VMS) operating systems at http://www.ntp.org. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ntp-autokey-08 INFORMATIONAL INFORMATIONAL IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5906 10.17487/RFC5906
RFC5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) H. Gerstung C. Elliott B. Haberman Editor June 2010 ASCII HTML 26

The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. [STANDARDS-TRACK]

draft-ietf-ntp-ntpv4-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5907 10.17487/RFC5907
RFC5908 Network Time Protocol (NTP) Server Option for DHCPv6 R. Gayraud B. Lourdelet June 2010 ASCII HTML 9 Dynamic Host Configuration Protocol for IPv6

The NTP Server Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. [STANDARDS-TRACK]

draft-ietf-ntp-dhcpv6-ntp-opt-06 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp http://www.rfc-editor.org/errata_search.php?rfc=5908 10.17487/RFC5908
RFC5909 Securing Neighbor Discovery Proxy: Problem Statement J-M. Combes S. Krishnan G. Daley July 2010 ASCII HTML 22 send secure neighbor discovery

Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.

Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.

Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-csi-sndp-prob-04 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC5909
RFC5910 Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) J. Gould S. Hollenbeck May 2010 ASCII HTML 36 epp Extensible Provisioning Protocol xml dns security dnssec delegation signer ds

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. [STANDARDS-TRACK]

draft-gould-rfc4310bis-07 RFC4310 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5910 10.17487/RFC5910
RFC5911 New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME P. Hoffman J. Schaad June 2010 ASCII HTML 59 S/MIME PKIX ASN.1 modules

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-smime-new-asn1-07 RFC6268 INFORMATIONAL INFORMATIONAL IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5911 10.17487/RFC5911
RFC5912 New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) P. Hoffman J. Schaad June 2010 ASCII HTML 117 S/MIME PKIX ASN.1 modules

The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-new-asn1-08 RFC6960 INFORMATIONAL INFORMATIONAL IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5912 10.17487/RFC5912
RFC5913 Clearance Attribute and Authority Clearance Constraints Certificate Extension S. Turner S. Chokhani June 2010 ASCII HTML 19 x.509 certificate

This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. [STANDARDS-TRACK]

draft-ietf-pkix-authorityclearanceconstraints-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5913 10.17487/RFC5913
RFC5914 Trust Anchor Format R. Housley S. Ashmore C. Wallace June 2010 ASCII HTML 14 trust anchor management

This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements. [STANDARDS-TRACK]

draft-ietf-pkix-ta-format-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5914 10.17487/RFC5914
RFC5915 Elliptic Curve Private Key Structure S. Turner D. Brown June 2010 ASCII HTML 7 ec Standards for Efficient Cryptography Group SECG

This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-ecprivatekey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5915 10.17487/RFC5915
RFC5916 Device Owner Attribute S. Turner June 2010 ASCII HTML 6

This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-deviceowner-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5916
RFC5917 Clearance Sponsor Attribute S. Turner June 2010 ASCII HTML 7

This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-clearancesponsor-attribute-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5917 10.17487/RFC5917
RFC5918 Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) R. Asati I. Minei B. Thomas August 2010 ASCII HTML 10 Wildcard Typed Wildcard FEC Element Typed Wildcard FEC Capability

The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-typed-wildcard-07 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5918 10.17487/RFC5918
RFC5919 Signaling LDP Label Advertisement Completion R. Asati P. Mohapatra E. Chen B. Thomas August 2010 ASCII HTML 9 label distribution protocol End-of-LIB Unrecognized Notification

There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-end-of-lib-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5919 10.17487/RFC5919
RFC5920 Security Framework for MPLS and GMPLS Networks L. Fang Editor July 2010 ASCII HTML 66

This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-mpls-and-gmpls-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5920
RFC5921 A Framework for MPLS in Transport Networks M. Bocci Editor S. Bryant Editor D. Frost Editor L. Levrau L. Berger July 2010 ASCII HTML 56 multiprotocol label switching mpls-tp transport profile oam itu-t

This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-framework-12 RFC6215 RFC7274 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5921
RFC5922 Domain Certificates in the Session Initiation Protocol (SIP) V. Gurbani S. Lawrence A. Jeffrey June 2010 ASCII HTML 17 PKIX Authentication Mutual Authentication X.509 TLS

This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS-TRACK]

draft-ietf-sip-domain-certs-07 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC5922
RFC5923 Connection Reuse in the Session Initiation Protocol (SIP) V. Gurbani Editor R. Mahy B. Tate June 2010 ASCII HTML 19 TCP Connection SCTP Connection TLS Connection Transport Connection TLS Virtual Server Authentication

This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS-TRACK]

draft-ietf-sip-connect-reuse-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5923 10.17487/RFC5923
RFC5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates S. Lawrence V. Gurbani June 2010 ASCII HTML 8 PKIX SIP Domain X.509 Certificate

This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. This document defines an Experimental Protocol for the Internet community.

draft-ietf-sip-eku-08 EXPERIMENTAL EXPERIMENTAL IETF rai sip 10.17487/RFC5924
RFC5925 The TCP Authentication Option J. Touch A. Mankin R. Bonica June 2010 ASCII HTML 48 transmission control protocol border gateway protocol transmission control message digest algorithm

This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]

draft-ietf-tcpm-tcp-auth-opt-11 RFC2385 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5925 10.17487/RFC5925
RFC5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) G. Lebovitz E. Rescorla June 2010 ASCII HTML 15 transmission control protocol

The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]

draft-ietf-tcpm-tcp-ao-crypto-03 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5926 10.17487/RFC5926
RFC5927 ICMP Attacks against TCP F. Gont July 2010 ASCII HTML 36 vulnerability blind attacks connection-reset attack performance-degrading attack throughput-reduction attack source quench PMTUD Path-MTU Discovery ICMP Destination Unreachable

This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tcpm-icmp-attacks-12 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC5927
RFC5928 Traversal Using Relays around NAT (TURN) Resolution Mechanism M. Petit-Huguenin August 2010 ASCII HTML 11 NAT Traversal

This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. [STANDARDS-TRACK]

draft-ietf-behave-turn-uri-10 RFC7350 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC5928
RFC5929 Channel Bindings for TLS J. Altman N. Williams L. Zhu July 2010 ASCII HTML 15 TLS channel binding channel-binding tls-unique tls-server-end-point tls-unique-for-telnet

This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).

Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. [STANDARDS-TRACK]

draft-altman-tls-channel-bindings-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5929
RFC5930 Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol S. Shen Y. Mao NSS. Murthy July 2010 ASCII HTML 6 initialization vector IKE_SA_INIT

This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-aes-ctr-ikev2-07 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC5930
RFC5931 Extensible Authentication Protocol (EAP) Authentication Using Only a Password D. Harkins G. Zorn August 2010 ASCII HTML 40 Password Authenticated Key Exchange Dictionary Attack Authentication EAP

This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-harkins-emu-eap-pwd-14 RFC8146 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5931 10.17487/RFC5931
RFC5932 Camellia Cipher Suites for TLS A. Kato M. Kanda S. Kanno June 2010 ASCII HTML 6 block cipher security camellia tls cbc sha2 camellia encryption algorithm

This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132. [STANDARDS-TRACK]

draft-kato-tls-rfc4132bis-05 RFC4132 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5932
RFC5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC V. Dolmatov Editor A. Chuprina I. Ustinov July 2010 ASCII HTML 9 domain name system security extensions ECC

This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-gost-07 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5933
RFC5934 Trust Anchor Management Protocol (TAMP) R. Housley S. Ashmore C. Wallace August 2010 ASCII HTML 91 trust anchors TA

This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. [STANDARDS-TRACK]

draft-ietf-pkix-tamp-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=5934 10.17487/RFC5934
RFC5935 Expressing SNMP SMI Datatypes in XML Schema Definition Language M. Ellison B. Natale August 2010 ASCII HTML 14 structure of management information

This memo defines the IETF standard expression of Structure of Management Information (SMI) base datatypes in XML Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. [STANDARDS-TRACK]

draft-ietf-opsawg-smi-datatypes-in-xsd-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=5935 10.17487/RFC5935
RFC5936 DNS Zone Transfer Protocol (AXFR) E. Lewis A. Hoenes Editor June 2010 ASCII HTML 29 authoritative transfer AXFR mechanism

The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.

The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK]

draft-ietf-dnsext-axfr-clarify-14 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5936
RFC5937 Using Trust Anchor Constraints during Certification Path Processing S. Ashmore C. Wallace August 2010 ASCII HTML 8 TA

This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-wallace-using-ta-constraints-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5937
RFC5938 Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) A. Morton M. Chiba August 2010 ASCII HTML 17

The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. [STANDARDS-TRACK]

draft-ietf-ippm-twamp-session-cntrl-07 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=5938 10.17487/RFC5938
RFC5939 Session Description Protocol (SDP) Capability Negotiation F. Andreasen September 2010 ASCII HTML 77 multimedia session session announcement session invitation

The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.

The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.

The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. [STANDARDS-TRACK]

draft-ietf-mmusic-sdp-capability-negotiation-13 RFC6871 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=5939 10.17487/RFC5939
RFC5940 Additional Cryptographic Message Syntax (CMS) Revocation Information Choices S. Turner R. Housley August 2010 ASCII HTML 9 online certificate status protocol ocsp server-based certificate validation protocol scvp

The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses. [STANDARDS-TRACK]

draft-turner-additional-cms-ri-choices-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5940 10.17487/RFC5940
RFC5941 Sharing Transaction Fraud Data D. M'Raihi S. Boeyen M. Grandcolas S. Bajaj August 2010 ASCII HTML 27 thraud incident object description exchange format iodef

This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mraihi-inch-thraud-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5941
RFC5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes H. Singh W. Beebee E. Nordmark July 2010 ASCII HTML 11

IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. [STANDARDS-TRACK]

draft-ietf-6man-ipv6-subnet-model-12 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC5942
RFC5943 A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing B. Haberman Editor August 2010 ASCII HTML 4

The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). [STANDARDS-TRACK]

draft-haberman-rpsl-reachable-test-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5943
RFC5944 IP Mobility Support for IPv4, Revised C. Perkins Editor November 2010 ASCII HTML 100 MOBILEIPSUPIP Internet Protocol MIPv4

This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. [STANDARDS-TRACK]

draft-ietf-mip4-rfc3344bis-10 RFC3344 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 http://www.rfc-editor.org/errata_search.php?rfc=5944 10.17487/RFC5944
RFC5945 Resource Reservation Protocol (RSVP) Proxy Approaches F. Le Faucheur J. Manner D. Wing A. Guillou October 2010 ASCII HTML 50

The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tsvwg-rsvp-proxy-approaches-09 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC5945
RFC5946 Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy F. Le Faucheur J. Manner A. Narayanan A. Guillou H. Malik October 2010 ASCII HTML 35

Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-proxy-proto-11 RFC2205 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC5946
RFC5947 Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) J. Elwell H. Kaplan September 2010 ASCII HTML 13 Trunking pbx private branch exchange

This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-martini-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai martini 10.17487/RFC5947
RFC5948 Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16 S. Madanapalli S. Park S. Chakrabarti G. Montenegro August 2010 ASCII HTML 13 packet cs

IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specific Convergence Sublayers for transmitting upper-layer protocols. The Packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 Media Access Control (MAC) layer.

This document specifies the frame format, the Maximum Transmission Unit (MTU), and the address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. [STANDARDS-TRACK]

draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 16ng 10.17487/RFC5948
RFC5949 Fast Handovers for Proxy Mobile IPv6 H. Yokota K. Chowdhury R. Koodli B. Patil F. Xia September 2010 ASCII HTML 32 PFMIPv6 handoff PMIPv6 predictive reactive

Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.

When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. [STANDARDS-TRACK]

draft-ietf-mipshop-pfmipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int mipshop 10.17487/RFC5949
RFC5950 Network Management Framework for MPLS-based Transport Networks S. Mansfield Editor E. Gray Editor K. Lam Editor September 2010 ASCII HTML 18 mpls-tp network management framework

This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.

The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-nm-framework-05 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC5950
RFC5951 Network Management Requirements for MPLS-based Transport Networks K. Lam S. Mansfield E. Gray September 2010 ASCII HTML 24 MPLS Transport Profile mpls-tp

This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS Transport Profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. [STANDARDS-TRACK]

draft-ietf-mpls-tp-nm-req-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5951 10.17487/RFC5951
RFC5952 A Recommendation for IPv6 Address Text Representation S. Kawamura M. Kawashima August 2010 ASCII HTML 14 IPv6 text representation canonical

As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK]

draft-ietf-6man-text-addr-representation-07 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=5952 10.17487/RFC5952
RFC5953 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker August 2010 ASCII HTML 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-dtls-tm-14 RFC6353 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms http://www.rfc-editor.org/errata_search.php?rfc=5953 10.17487/RFC5953
RFC5954 Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 V. Gurbani Editor B. Carpenter Editor B. Tate Editor August 2010 ASCII HTML 7 SIP session initiation protocol Augmented Backus-Naur Form Uniform Resource Identifier IPv6reference IPv6address

This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]

draft-ietf-sip-ipv6-abnf-fix-05 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=5954 10.17487/RFC5954
RFC5955 The application/timestamped-data Media Type A. Santoni August 2010 ASCII HTML 3 TimeStampedData envelopes

This document defines a new media type for TimeStampedData envelopes as described in RFC 5544. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-santoni-media-type-tsd-00 RFC5544 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5955
RFC5956 Forward Error Correction Grouping Semantics in the Session Description Protocol A. Begen September 2010 ASCII HTML 14 FEC loss repair grouping sdp media lines

This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888). These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. [STANDARDS-TRACK]

draft-ietf-mmusic-rfc4756bis-10 RFC4756 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC5956
RFC5957 Display-Based Address Sorting for the IMAP4 SORT Extension D. Karp July 2010 ASCII HTML 5 Internet Message Access Protocol

This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. [STANDARDS-TRACK]

draft-ietf-morg-sortdisplay-03 RFC5256 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC5957
RFC5958 Asymmetric Key Packages S. Turner August 2010 ASCII HTML 14 private key private-key information rsa laboratories private-key syntax change control

This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK]

draft-turner-asymmetrickeyformat-05 RFC5208 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5958 10.17487/RFC5958
RFC5959 Algorithms for Asymmetric Key Package Content Type S. Turner August 2010 ASCII HTML 7 EncryptedPrivateKeyInfo AsymmetricKeyPackage

This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-asymmetrickeyformat-algs-01 RFC6162 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5959
RFC5960 MPLS Transport Profile Data Plane Architecture D. Frost Editor S. Bryant Editor M. Bocci Editor August 2010 ASCII HTML 15 mpls-tp transport profile itu-t dataplane gal gach

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network. [STANDARDS-TRACK]

draft-ietf-mpls-tp-data-plane-04 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=5960 10.17487/RFC5960
RFC5961 Improving TCP's Robustness to Blind In-Window Attacks A. Ramaiah R. Stewart M. Dalal August 2010 ASCII HTML 19 RST SYN FIN attack Data Injection vulnerability blind attacks BGP spoof mitigation

TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 or Border Gateway Protocol (BGP) [STANDARDS-TRACK]

draft-ietf-tcpm-tcpsecure-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=5961 10.17487/RFC5961
RFC5962 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) H. Schulzrinne V. Singh H. Tschofenig M. Thomson September 2010 ASCII HTML 11 PIDF-LO,location,dynamic,speed,velocity,orientation

The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. [STANDARDS TRACK]

draft-singh-geopriv-pidf-lo-dynamic-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5962
RFC5963 IPv6 Deployment in Internet Exchange Points (IXPs) R. Gagliano August 2010 ASCII HTML 10 IPv6 IXP deployment exchange

This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6inixp-09 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC5963
RFC5964 Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries J. Winterbottom M. Thomson August 2010 ASCII HTML 11 hole polygon pidf-lo service boundary location LoST

This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to- Service Translation (LoST) server, is described. [STANDARDS-TRACK]

draft-ietf-ecrit-specifying-holes-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC5964
RFC5965 An Extensible Format for Email Feedback Reports Y. Shafranovich J. Levine M. Kucherawy August 2010 ASCII HTML 25 feedback-report

This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK]

draft-ietf-marf-base-06 RFC6650 PROPOSED STANDARD PROPOSED STANDARD IETF app marf http://www.rfc-editor.org/errata_search.php?rfc=5965 10.17487/RFC5965
RFC5966 DNS Transport over TCP - Implementation Requirements R. Bellis August 2010 ASCII HTML 7 DNS TCP/IP

This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. [STANDARDS-TRACK]

draft-ietf-dnsext-dns-tcp-requirements-03 RFC7766 RFC1035 RFC1123 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC5966
RFC5967 The application/pkcs10 Media Type S. Turner August 2010 ASCII HTML 6

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-application-pkcs10-media-type-05 RFC2986 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC5967
RFC5968 Guidelines for Extending the RTP Control Protocol (RTCP) J. Ott C. Perkins September 2010 ASCII HTML 17 real-time transport protocol

The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avt-rtcp-guidelines-04 INFORMATIONAL INFORMATIONAL IETF rai avt 10.17487/RFC5968
RFC5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification W. Townsley O. Troan August 2010 ASCII HTML 18 6rd Provider 6to4 IPv6 softwire IPv6 Transition 6to4

This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]

draft-ietf-softwire-ipv6-6rd-10 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=5969 10.17487/RFC5969
RFC5970 DHCPv6 Options for Network Boot T. Huth J. Freimann V. Zimmer D. Thaler September 2010 ASCII HTML 11 boot IPv6 DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-opt-netboot-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC5970
RFC5971 GIST: General Internet Signalling Transport H. Schulzrinne R. Hancock October 2010 ASCII HTML 154 nsis next steps in signaling

This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-ntlp-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5971
RFC5972 General Internet Signaling Transport (GIST) State Machine T. Tsenov H. Tschofenig X. Fu Editor C. Aoun E. Davies October 2010 ASCII HTML 27 draft-ietf-nsis-ntlp-statemachine-10 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5972 RFC5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP) M. Stiemerling H. Tschofenig C. Aoun E. Davies October 2010 ASCII HTML 90 Next Steps in Signaling NSIS Path-coupled signaling Middlebox

This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-nslp-natfw-25 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5973
RFC5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling J. Manner G. Karagiannis A. McDonald October 2010 ASCII HTML 102 QoS

This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-qos-nslp-18 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5974
RFC5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) G. Ash Editor A. Bader Editor C. Kappler Editor D. Oran Editor October 2010 ASCII HTML 64

The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in the QSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-qspec-24 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5975
RFC5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes G. Ash A. Morton M. Dolly P. Tarapore C. Dvorak Y. El Mghazli October 2010 ASCII HTML 19 qos-nslp qos-nslp quality-of-service model qspec

This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-y1541-qosm-10 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5976
RFC5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv A. Bader L. Westberg G. Karagiannis C. Kappler T. Phelan October 2010 ASCII HTML 128 next steps in signaling resource managment in diffserv

This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-rmd-20 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5977
RFC5978 Using and Extending the NSIS Protocol Family J. Manner R. Bless J. Loughney E. Davies Editor October 2010 ASCII HTML 30 Signaling NTLP NSLP GIST QoS NSLP NAT/Firewall NSLP IP resources Extensibility

This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nsis-ext-07 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5978
RFC5979 NSIS Operation over IP Tunnels C. Shen H. Schulzrinne S. Lee J. Bang March 2011 ASCII HTML 27 nsis qos next steps in signaling

NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-tunnel-13 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC5979
RFC5980 NSIS Protocol Operation in Mobile Environments T. Sanda Editor X. Fu S. Jeong J. Manner H. Tschofenig March 2011 ASCII HTML 32

Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nsis-applicability-mobility-signaling-20 INFORMATIONAL INFORMATIONAL IETF tsv nsis 10.17487/RFC5980
RFC5981 Authorization for NSIS Signaling Layer Protocols J. Manner M. Stiemerling H. Tschofenig R. Bless Editor February 2011 ASCII HTML 37 Next Steps in Signaling gist General Internet Signaling Transport

Signaling layer protocols specified within the Next Steps in Signaling (NSIS) framework may rely on the General Internet Signaling Transport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within the NSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-nslp-auth-07 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis http://www.rfc-editor.org/errata_search.php?rfc=5981 10.17487/RFC5981
RFC5982 IP Flow Information Export (IPFIX) Mediation: Problem Statement A. Kobayashi Editor B. Claise Editor August 2010 ASCII HTML 25 flow-based measurement

Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipfix-mediators-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF ops ipfix 10.17487/RFC5982
RFC5983 Mailing Lists and Internationalized Email Addresses R. Gellens October 2010 ASCII HTML 10

This document describes considerations for mailing lists with the introduction of internationalized email addresses.

This document makes some specific recommendations on how mailing lists should act in various situations. This document defines an Experimental Protocol for the Internet community.

draft-ietf-eai-mailinglist-07 RFC6783 EXPERIMENTAL EXPERIMENTAL IETF app eai 10.17487/RFC5983
RFC5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding K-M. Moller April 1 2011 ASCII HTML 9 extra sensory perception

This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.

draft-moller-esp-based-forwarding-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=5984 10.17487/RFC5984
RFC5985 HTTP-Enabled Location Delivery (HELD) M. Barnes Editor September 2010 ASCII HTML 39 layer 7 location configuration protocol l7 lcp

This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK]

draft-ietf-geopriv-http-location-delivery-16 RFC7840 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC5985
RFC5986 Discovering the Local Location Information Server (LIS) M. Thomson J. Winterbottom September 2010 ASCII HTML 16 u-naptr uri-enabled naptr

Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. [STANDARDS-TRACK]

draft-ietf-geopriv-lis-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=5986 10.17487/RFC5986
RFC5987 Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters J. Reschke August 2010 ASCII HTML 10 HTTP header field parameter internationalization

By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. [STANDARDS-TRACK]

draft-reschke-rfc2231-in-http-12 RFC8187 HISTORIC PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5987
RFC5988 Web Linking M. Nottingham October 2010 ASCII HTML 23 Link linking http header link relation web

This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. [STANDARDS-TRACK]

draft-nottingham-http-link-header-10 RFC8288 RFC4287 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=5988 10.17487/RFC5988
RFC5989 A SIP Event Package for Subscribing to Changes to an HTTP Resource A.B. Roach October 2010 ASCII HTML 19 Link Relations Syndication Atom

The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP Event Framework, for doing so. [STANDARDS-TRACK]

draft-roach-sip-http-subscribe-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5989
RFC5990 Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) J. Randall B. Kaliski J. Brainard S. Turner September 2010 ASCII HTML 27 key encapsulation mechanism generic hybrid cipher

The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44.

draft-ietf-smime-cms-rsa-kem-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec smime http://www.rfc-editor.org/errata_search.php?rfc=5990 10.17487/RFC5990
RFC5991 Teredo Security Updates D. Thaler S. Krishnan J. Hoagland September 2010 ASCII HTML 10 teredo ipv6 address

The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. [STANDARDS-TRACK]

draft-krishnan-v6ops-teredo-update-10 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5991
RFC5992 Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic S. Sharikov D. Miloshevic J. Klensin October 2010 ASCII HTML 21 Bosnian and Serbian Bulgarian Byelorussian Belarusian Belarusan Kildin Sami Macedonian Montenegrin Russian Ukrainian

This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sharikov-idn-reg-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC5992
RFC5993 RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) X. Duan S. Wang M. Westerlund K. Hellwig I. Johansson October 2010 ASCII HTML 18 speech codec real-time transport protocol

This document specifies the payload format for packetization of Global System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. [STANDARDS-TRACK]

draft-ietf-avt-rtp-gsm-hr-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC5993
RFC5994 Application of Ethernet Pseudowires to MPLS Transport Networks S. Bryant Editor M. Morrow G. Swallow R. Cherukuri T. Nadeau N. Harrison B. Niven-Jenkins October 2010 ASCII HTML 11 mpls-tp

Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.

Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T. The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.

This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pwe3-mpls-transport-04 INFORMATIONAL INFORMATIONAL IETF int pwe3 http://www.rfc-editor.org/errata_search.php?rfc=5994 10.17487/RFC5994
RFC5995 Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections J. Reschke September 2010 ASCII HTML 12 HTTP POST WebDAV Collections Collection Members

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".

This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as the Calendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.

This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. [STANDARDS-TRACK]

draft-reschke-webdav-post-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC5995
RFC5996 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen September 2010 ASCII HTML 138 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]

draft-ietf-ipsecme-ikev2bis-11 RFC4306 RFC4718 RFC7296 RFC5998 RFC6989 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=5996 10.17487/RFC5996
RFC5997 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol A. DeKok August 2010 ASCII HTML 24 status-server

This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-radext-status-server-09 RFC2866 INFORMATIONAL INFORMATIONAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=5997 10.17487/RFC5997
RFC5998 An Extension for EAP-Only Authentication in IKEv2 P. Eronen H. Tschofenig Y. Sheffer September 2010 ASCII HTML 16 mutual authentication password credentials AAA key agreement channel binding

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.

This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. [STANDARDS-TRACK]

draft-ietf-ipsecme-eap-mutual-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC5998
RFC5999 RFC6000 RFC6001 Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) D. Papadimitriou M. Vigoureux K. Shiomoto D. Brungard JL. Le Roux October 2010 ASCII HTML 24

There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).

This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-mln-extensions-12 RFC4202 RFC4203 RFC4206 RFC4874 RFC4974 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6001
RFC6002 Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions L. Berger D. Fedyk October 2010 ASCII HTML 10 Generalized Multi-Protocol Label Switching

This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-dcsc-channel-ext-04 RFC3471 RFC3473 RFC3945 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6002
RFC6003 Ethernet Traffic Parameters D. Papadimitriou October 2010 ASCII HTML 14 mef Metro Ethernet Forum MEF10.1

This document describes the support of Metro Ethernet Forum (MEF) Ethernet traffic parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. [STANDARDS-TRACK]

draft-ietf-ccamp-ethernet-traffic-parameters-10 RFC3471 RFC3473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6003 10.17487/RFC6003
RFC6004 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching L. Berger D. Fedyk October 2010 ASCII HTML 15 Generalized Multi-Protocol Label Switching Metro Ethernet Forum MEF draft-ietf-ccamp-gmpls-ether-svcs-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6004 RFC6005 Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) L. Berger D. Fedyk October 2010 ASCII HTML 10 mef itu International Telecommunication Union i-nni internal nni

This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. [STANDARDS- TRACK]

draft-ietf-ccamp-gmpls-mef-uni-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6005
RFC6006 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao Editor D. King Editor F. Verhaeghe T. Takeda Z. Ali J. Meuric September 2010 ASCII HTML 33 END-POINTS fragmentation

Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. [STANDARDS-TRACK]

draft-ietf-pce-pcep-p2mp-extensions-11 RFC8306 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=6006 10.17487/RFC6006
RFC6007 Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations I. Nishioka D. King September 2010 ASCII HTML 18

A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.

This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-pcep-svec-list-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6007
RFC6008 Authentication-Results Registration for Differentiating among Cryptographic Results M. Kucherawy September 2010 ASCII HTML 7 DKIM DomainKeys SenderID SPF Authentication Reputation

This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]

draft-kucherawy-authres-header-b-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6008
RFC6009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions N. Freed October 2010 ASCII HTML 15 SMTP ESMTP Sieve

This document describes the "envelope-dsn", "redirect-dsn", "envelope-deliverby", and "redirect-deliverby" extensions to the Sieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) and Deliver-By SMTP extensions, respectively. The "redirect-dsn" and "redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. [STANDARDS-TRACK]

draft-freed-sieve-notary-09 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=6009 10.17487/RFC6009
RFC6010 Cryptographic Message Syntax (CMS) Content Constraints Extension R. Housley S. Ashmore C. Wallace September 2010 ASCII HTML 38 authorization PKI certificate trust anchor TAMP,

This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. [STANDARDS-TRACK]

draft-housley-cms-content-constraints-extn-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6010 10.17487/RFC6010
RFC6011 Session Initiation Protocol (SIP) User Agent Configuration S. Lawrence Editor J. Elwell October 2010 ASCII HTML 29 HTTP DHCP DHCPv6

This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-lawrence-sipforum-user-agent-config-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6011 10.17487/RFC6011
RFC6012 Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog J. Salowey T. Petch R. Gerhards H. Feng October 2010 ASCII HTML 12 TLS

This document describes the transport of syslog messages over the Datagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. [STANDARDS-TRACK]

draft-ietf-syslog-dtls-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec syslog 10.17487/RFC6012
RFC6013 TCP Cookie Transactions (TCPCT) W. Simpson January 2011 ASCII HTML 37

TCP Cookie Transactions (TCPCT) deter spoofing of connections and prevent resource exhaustion, eliminating Responder (server) state during the initial handshake. The Initiator (client) has sole responsibility for ensuring required delays between connections. The cookie exchange may carry data, limited to inhibit amplification and reflection denial of service attacks. This document defines an Experimental Protocol for the Internet community.

draft-simpson-tcpct-03 RFC7805 HISTORIC EXPERIMENTAL INDEPENDENT 10.17487/RFC6013
RFC6014 Cryptographic Algorithm Identifier Allocation for DNSSEC P. Hoffman November 2010 ASCII HTML 6 DNSSEC digital signatures algorithms

This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-alg-allocation-03 RFC4033 RFC4034 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6014
RFC6015 RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) A. Begen October 2010 ASCII HTML 31 FEC interleaving loss repair loss protection DVB AL-FEC

This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB- IPTV) Application-layer FEC specification. [STANDARDS-TRACK]

draft-ietf-fecframe-interleaved-fec-scheme-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6015
RFC6016 Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs B. Davie F. Le Faucheur A. Narayanan October 2010 ASCII HTML 38 l3vpn

RFC 4364 and RFC 4659 define an approach to building provider-provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers and Provider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. [STANDARDS-TRACK]

draft-ietf-tsvwg-rsvp-l3vpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6016 10.17487/RFC6016
RFC6017 Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field K. Meadors Editor September 2010 ASCII HTML 5 EDIINT-Features

With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-meadors-ediint-features-header-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6017
RFC6018 IPv4 and IPv6 Greynets F. Baker W. Harrop G. Armitage September 2010 ASCII HTML 9 darknets

This note discusses a feature to support building Greynets for IPv4 and IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-baker-v6ops-greynet-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6018
RFC6019 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 R. Housley September 2010 ASCII HTML 6 signing-time attribute cryptographic message syntax cms SignedData AuthenticatedData

This document specifies a new ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. [STANDARDS-TRACK]

rfc4049bis RFC4049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6019
RFC6020 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) M. Bjorklund Editor October 2010 ASCII HTML 173 NETCONF XML data modelling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]

draft-ietf-netmod-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6020 10.17487/RFC6020
RFC6021 Common YANG Data Types J. Schoenwaelder Editor October 2010 ASCII HTML 26 YANG NETCONF

This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]

draft-ietf-netmod-yang-types-09 RFC6991 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC6021
RFC6022 YANG Module for NETCONF Monitoring M. Scott M. Bjorklund October 2010 ASCII HTML 28 XML NETCONF YANG monitoring

This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema> operation to retrieve them. [STANDARDS-TRACK]

draft-ietf-netconf-monitoring-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6022 10.17487/RFC6022
RFC6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) Y. Nir H. Tschofenig H. Deng R. Singh October 2010 ASCII HTML 7

This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

draft-nir-ipsecme-childless-06 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6023
RFC6024 Trust Anchor Management Requirements R. Reddy C. Wallace October 2010 ASCII HTML 14 PKI certificates digital signatures

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-ta-mgmt-reqs-06 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6024
RFC6025 ASN.1 Translation C. Wallace C. Gardiner October 2010 ASCII HTML 19 Basic Encoding Rules Distinguished Encoding Rules PKIX S/MIME

Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-asn1-translation-03 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6025
RFC6026 Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests R. Sparks T. Zourzouvillys September 2010 ASCII HTML 20 state machine retransmission

This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. [STANDARDS-TRACK]

draft-ietf-sipcore-invfix-01 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6026 10.17487/RFC6026
RFC6027 IPsec Cluster Problem Statement Y. Nir October 2010 ASCII HTML 12 IKE IKEv2 high-availability load-sharing failover hot-standby

This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-ipsec-ha-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6027
RFC6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension G. Camarillo A. Keranen October 2010 ASCII HTML 10 source routing route recording overlay network

This document specifies two extensions to the Host Identity Protocol (HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-via-03 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6028
RFC6029 A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem I. Rimac V. Hilt M. Tomsu V. Gurbani E. Marocco October 2010 ASCII HTML 19 Peer-to-Peer topology estimation Internet coordinate system

A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-p2prg-alto-survey-05 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6029 10.17487/RFC6029
RFC6030 Portable Symmetric Key Container (PSKC) P. Hoyer M. Pei S. Machani October 2010 ASCII HTML 58 Symmetric Key provisioning AES 3DES TDES OTP Key transport format key provisioning format symmetric key protection symmetric key transport PIN transport PIN provisioning PIN Policy key usage policy

This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules. For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. [STANDARDS-TRACK]

draft-ietf-keyprov-pskc-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6030 10.17487/RFC6030
RFC6031 Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type S. Turner R. Housley December 2010 ASCII HTML 29

This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. [STANDARDS-TRACK]

draft-ietf-keyprov-symmetrickeyformat-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6031 10.17487/RFC6031
RFC6032 Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner R. Housley December 2010 ASCII HTML 11 CCC CMS content constraints

This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-encryptedkeypackagecontenttype-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6032
RFC6033 Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner December 2010 ASCII HTML 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-encryptedkeypackagecontenttype-algs-02 RFC6161 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6033
RFC6034 Unicast-Prefix-Based IPv4 Multicast Addresses D. Thaler October 2010 ASCII HTML 5 internet protocol

This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. [STANDARDS-TRACK]

draft-ietf-mboned-ipv4-uni-based-mcast-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6034
RFC6035 Session Initiation Protocol Event Package for Voice Quality Reporting A. Pendleton A. Clark A. Johnston H. Sinnreich November 2010 ASCII HTML 41 sip Voice over Internet Protocol voip RTP Control Protocol Extended Reports RTCP-XR

This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. Voice call quality information derived from RTP Control Protocol Extended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq-rtcpxr media type is also included. [STANDARDS-TRACK]

draft-ietf-sipping-rtcp-summary-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6035 10.17487/RFC6035
RFC6036 Emerging Service Provider Scenarios for IPv6 Deployment B. Carpenter S. Jiang October 2010 ASCII HTML 23 isp

This document describes practices and plans that are emerging among Internet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-isp-scenarios-00 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6036 10.17487/RFC6036
RFC6037 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs E. Rosen Editor Y. Cai Editor IJ. Wijnands October 2010 ASCII HTML 25 mvpn

This document describes the MVPN (Multicast in BGP/MPLS IP VPNs) solution designed and deployed by Cisco Systems. The procedures specified in this document are largely a subset of the generalized MVPN framework recently standardized by the IETF. However, as the deployment of the procedures specified herein predates the publication of IETF standards (in some cases by over five years), an implementation based on these procedures differs in some respects from a fully standards-compliant implementation. These differences are pointed out in the document. This document defines a Historic Document for the Internet community.

draft-rosen-vpn-mcast-15 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6037
RFC6038 Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features A. Morton L. Ciavattone October 2010 ASCII HTML 18 Testing Performance Metric

This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. [STANDARDS-TRACK]

draft-ietf-ippm-twamp-reflect-octets-09 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6038 10.17487/RFC6038
RFC6039 Issues with Existing Cryptographic Protection Methods for Routing Protocols V. Manral M. Bhatia J. Jaeggli R. White October 2010 ASCII HTML 21

Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.

The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.

This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-routing-protocols-crypto-issues-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6039
RFC6040 Tunnelling of Explicit Congestion Notification B. Briscoe November 2010 ASCII HTML 35 Congestion Control and Management Congestion Notification Information Security Tunnelling Encapsulation Decapsulation Protocol ECN IPsec

This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. [STANDARDS-TRACK]

draft-ietf-tsvwg-ecn-tunnel-10 RFC3168 RFC4301 RFC4774 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6040
RFC6041 Forwarding and Control Element Separation (ForCES) Applicability Statement A. Crouch H. Khosravi A. Doria Editor X. Wang K. Ogawa October 2010 ASCII HTML 14 Routing Control Plane Management Protocol

The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-forces-applicability-09 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6041
RFC6042 Transport Layer Security (TLS) Authorization Using KeyNote A. Keromytis October 2010 ASCII HTML 7 trust management authorization access control certificates

This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-keromytis-tls-authz-keynote-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6042
RFC6043 MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) J. Mattsson T. Tian March 2011 ASCII HTML 58 MIKEY MIKEY-TICKET KMS SRTP IMS key management ticket

The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing. Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mattsson-mikey-ticket-05 RFC6309 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6043
RFC6044 Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) M. Mohali October 2010 ASCII HTML 24

Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.

This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.

Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mohali-diversion-history-info-07 RFC7544 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6044 10.17487/RFC6044
RFC6045 Real-time Inter-network Defense (RID) K. Moriarty November 2010 ASCII HTML 75 Coordinated Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.

RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-moriarty-post-inch-rid-12 RFC6545 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6045 10.17487/RFC6045
RFC6046 Transport of Real-time Inter-network Defense (RID) Messages K. Moriarty B. Trammell November 2010 ASCII HTML 7 Coordinate Incident Response CSIRT CIRT IODEF Incident Object Exchange Description Format

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-moriarty-post-inch-rid-transport-03 RFC6546 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6046
RFC6047 iCalendar Message-Based Interoperability Protocol (iMIP) A. Melnikov Editor December 2010 ASCII HTML 22 IMIP] electronic mail transport itip iCalendar Transport-independent Interoperability Protocol iCalendar Object Model

This document, "iCalendar Message-Based Interoperability Protocol (iMIP)", specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then transported over SMTP. [STANDARDS-TRACK]

draft-ietf-calsify-rfc2447bis-11 RFC2447 PROPOSED STANDARD PROPOSED STANDARD IETF app calsify http://www.rfc-editor.org/errata_search.php?rfc=6047 10.17487/RFC6047
RFC6048 Network News Transfer Protocol (NNTP) Additions to LIST Command J. Elie November 2010 ASCII HTML 25 Usenet NetNews capabilities

This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.

This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. [STANDARDS-TRACK]

draft-elie-nntp-list-additions-05 RFC2980 RFC3977 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6048
RFC6049 Spatial Composition of Metrics A. Morton E. Stephan January 2011 ASCII HTML 29 Performance Measurement IPPM

This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. [STANDARDS-TRACK]

draft-ietf-ippm-spatial-composition-16 RFC6248 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6049
RFC6050 A Session Initiation Protocol (SIP) Extension for the Identification of Services K. Drage November 2010 ASCII HTML 19 SIP trust domain service identifier

This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.

The document also defines a URN to identify both services and User Agent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-drage-sipping-service-identification-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6050
RFC6051 Rapid Synchronisation of RTP Flows C. Perkins T. Schierl November 2010 ASCII HTML 22 rtcp rtp control protocol mcu multipoint conference units ssm source-specific multicast

This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.

This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK]

draft-ietf-avt-rapid-rtp-sync-12 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6051
RFC6052 IPv6 Addressing of IPv4/IPv6 Translators C. Bao C. Huitema M. Bagnulo M. Boucadair X. Li October 2010 ASCII HTML 18 address prefix transition translation NAT NAT64 BEHAVE stateless stateful

This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK]

draft-ietf-behave-address-format-10 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6052 10.17487/RFC6052
RFC6053 Implementation Report for Forwarding and Control Element Separation (ForCES) E. Haleplidis K. Ogawa W. Wang J. Hadi Salim November 2010 ASCII HTML 34 Stream Control Transmission Protocol-based Transport Mapping Layer SCTP TML forces Model

Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.

This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-forces-implementation-report-02 RFC6984 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6053
RFC6054 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic D. McGrew B. Weis November 2010 ASCII HTML 10

Counter modes have been defined for block ciphers such as the Advanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. [STANDARDS-TRACK]

draft-ietf-msec-ipsec-group-counter-modes-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec 10.17487/RFC6054
RFC6055 IAB Thoughts on Encodings for Internationalized Domain Names D. Thaler J. Klensin S. Cheshire February 2011 ASCII HTML 24 Unicode UTF-8,

This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as UTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today.

draft-iab-idn-encoding-04 RFC2130 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6055 10.17487/RFC6055
RFC6056 Recommendations for Transport-Protocol Port Randomization M. Larsen F. Gont January 2011 ASCII HTML 29 tcp transmission control protocl blind attacks

During the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.

draft-ietf-tsvwg-port-randomization-09 BCP0156 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6056 10.17487/RFC6056
RFC6057 Comcast's Protocol-Agnostic Congestion Management System C. Bastian T. Klieber J. Livingood J. Mills R. Woundy December 2010 ASCII HTML 29 ISP Internet Service Provider Network Management

This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-livingood-woundy-congestion-mgmt-09 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6057
RFC6058 Transient Binding for Proxy Mobile IPv6 M. Liebsch Editor A. Muhanna O. Blume March 2011 ASCII HTML 35 PMIP handover optimization handover delay tBCE late path switch forwarding make-before-break dual radio handover single radio handover transient binding cache entry

This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mipshop-transient-bce-pmipv6-07 EXPERIMENTAL EXPERIMENTAL IETF int mipshop 10.17487/RFC6058
RFC6059 Simple Procedures for Detecting Network Attachment in IPv6 S. Krishnan G. Daley November 2010 ASCII HTML 19 DNA DNAv6 ND IPv6 neighbor discovery neighbor discovery send secure neighbor discovery DHCPv6 stateless autoconfiguration change detection movement detection DNAv4 link detection mobility

Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services. [STANDARDS-TRACK]

draft-ietf-dna-simple-17 PROPOSED STANDARD PROPOSED STANDARD IETF int dna 10.17487/RFC6059
RFC6060 Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) D. Fedyk H. Shah N. Bitar A. Takacs March 2011 ASCII HTML 20 IEEE data plane

This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology-specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point (P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-ethernet-pbb-te-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6060
RFC6061 Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) B. Rosen January 2011 ASCII HTML 7

This document describes the Namespace Identifier (NID) "nena" for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-rosen-urn-nena-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6061
RFC6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations S. Perreault Editor J. Rosenberg November 2010 ASCII HTML 13 NAT TURN STUN

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client\'s peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server. [STANDARDS-TRACK]

draft-ietf-behave-turn-tcp-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6062 10.17487/RFC6062
RFC6063 Dynamic Symmetric Key Provisioning Protocol (DSKPP) A. Doherty M. Pei S. Machani M. Nystrom December 2010 ASCII HTML 105 Cryptographic module Cryptographic Token key initialization credentials online provisioning

The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.

Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre-generated symmetric keys to a cryptographic module. [STANDARDS-TRACK]

draft-ietf-keyprov-dskpp-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec keyprov http://www.rfc-editor.org/errata_search.php?rfc=6063 10.17487/RFC6063
RFC6064 SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service M. Westerlund P. Frojdh January 2011 ASCII HTML 22 3GPP PSS MBMS SDP RTSP IANA

The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use the Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-westerlund-mmusic-3gpp-sdp-rtsp-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6064
RFC6065 Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings K. Narayan D. Nelson R. Presuhn Editor December 2010 ASCII HTML 19 Network Management Security Management Information Base MIB SMIv2 RADIUS AAA VACM

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-based Access Control Model (VACM). [STANDARDS-TRACK]

draft-ietf-isms-radius-vacm-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec isms 10.17487/RFC6065
RFC6066 Transport Layer Security (TLS) Extensions: Extension Definitions D. Eastlake 3rd January 2011 ASCII HTML 25 server_name max_fragment_length client_certificate_url trusted_ca_keys truncated_hmac status_request

This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]

draft-ietf-tls-rfc4366-bis-12 RFC4366 RFC8446 RFC8449 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6066 10.17487/RFC6066
RFC6067 BCP 47 Extension U M. Davis A. Phillips Y. Umaoka December 2010 ASCII HTML 8 locale bcp 47

This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-davis-u-langtag-ext-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6067 10.17487/RFC6067
RFC6068 The 'mailto' URI Scheme M. Duerst L. Masinter J. Zawinski October 2010 ASCII HTML 17 mailto email address URI scheme IRI

This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]

draft-duerst-mailto-bis-10 RFC2368 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6068 10.17487/RFC6068
RFC6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) A. Zimmermann A. Hannemann December 2010 ASCII HTML 23 Internet Control Message Protocol (ICMP) Retranmission Timeout (RTO)

Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.

This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. This document defines an Experimental Protocol for the Internet community.

draft-ietf-tcpm-tcp-lcd-03 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6069
RFC6070 PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors S. Josefsson January 2011 ASCII HTML 5

This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-josefsson-pbkdf2-test-vectors-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6070
RFC6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap S. Frankel S. Krishnan February 2011 ASCII HTML 63 internet protocol privacy authentication

Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.

This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IP Security Document Roadmap."

The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipsecme-roadmap-10 RFC2411 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC6071
RFC6072 Certificate Management Service for the Session Initiation Protocol (SIP) C. Jennings J. Fischl Editor February 2011 ASCII HTML 30 credential service aor address of record

This document defines a credential service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. [STANDARDS-TRACK]

draft-ietf-sip-certs-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip http://www.rfc-editor.org/errata_search.php?rfc=6072 10.17487/RFC6072
RFC6073 Segmented Pseudowire L. Martini C. Metz T. Nadeau M. Bocci M. Aissaoui January 2011 ASCII HTML 43 pws psn packet switched network pw control plane domain

This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. [STANDARDS-TRACK]

draft-ietf-pwe3-segmented-pw-18 RFC6723 RFC7267 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6073
RFC6074 Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) E. Rosen B. Davie V. Radoaca W. Luo January 2011 ASCII HTML 32

Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). [STANDARDS- TRACK]

draft-ietf-l2vpn-signaling-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6074
RFC6075 The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry D. Cridland December 2010 ASCII HTML 7 annotate metadata

The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. [STANDARDS-TRACK]

draft-cridland-acap-vendor-registry-02 RFC2244 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6075
RFC6076 Basic Telephony SIP End-to-End Performance Metrics D. Malas A. Morton January 2011 ASCII HTML 27 Benchmarking Lab Test Time Measurement Service Session Protocol

This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. [STANDARDS-TRACK]

draft-ietf-pmol-sip-perf-metrics-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops pmol 10.17487/RFC6076
RFC6077 Open Research Issues in Internet Congestion Control D. Papadimitriou Editor M. Welzl M. Scharf B. Briscoe February 2011 ASCII HTML 51 Signalling Performance Robustness Fairness Stability Misbehaviour Architecture

This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet-scale solutions can be confidently engineered and deployed. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-iccrg-welzl-congestion-control-open-research-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6077
RFC6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) G. Camarillo J. Melen January 2011 ASCII HTML 17 HIP DATA

This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-hiccups-05 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6078
RFC6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) G. Camarillo P. Nikander J. Hautakorpi A. Keranen A. Johnston January 2011 ASCII HTML 21

This document specifies a framework to build HIP-based (Host Identity Protocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols". This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-bone-07 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6079
RFC6080 A Framework for Session Initiation Protocol User Agent Profile Delivery D. Petrie S. Channabasappa Editor March 2011 ASCII HTML 54 SIP Configuration Framework User Agent profile

This document specifies a framework to enable configuration of Session Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. [STANDARDS-TRACK]

draft-ietf-sipping-config-framework-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6080
RFC6081 Teredo Extensions D. Thaler January 2011 ASCII HTML 59 IPv6 NAT traversal transition translation translator

This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. [STANDARDS-TRACK]

draft-thaler-v6ops-teredo-extensions-08 RFC4380 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6081 10.17487/RFC6081
RFC6082 Deprecating Unicode Language Tag Characters: RFC 2482 is Historic K. Whistler G. Adams M. Duerst R. Presuhn Editor J. Klensin November 2010 ASCII HTML 4 characters strings ASCII

RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-presuhn-rfc2482-historic-02 RFC2482 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6082
RFC6083 Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) M. Tuexen R. Seggelmann E. Rescorla January 2011 ASCII HTML 9

This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).

DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.

Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]

draft-ietf-tsvwg-dtls-for-sctp-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6083 10.17487/RFC6083
RFC6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) X. Fu C. Dickmann J. Crowcroft January 2011 ASCII HTML 12 Multihoming Signaling Partial Reliability

The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). This document defines an Experimental Protocol for the Internet community.

draft-ietf-nsis-ntlp-sctp-15 EXPERIMENTAL EXPERIMENTAL IETF tsv nsis 10.17487/RFC6084
RFC6085 Address Mapping of IPv6 Multicast Packets on Ethernet S. Gundavelli M. Townsley O. Troan W. Dec January 2011 ASCII HTML 3

When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link-layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. [STANDARDS-TRACK]

draft-gundavelli-v6ops-l2-unicast-06 RFC2464 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6085
RFC6086 Session Initiation Protocol (SIP) INFO Method and Package Framework C. Holmberg E. Burger H. Kaplan January 2011 ASCII HTML 36 Info Package Info-Package Recv-Info

This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. [STANDARDS-TRACK]

draft-ietf-sipcore-info-events-10 RFC2976 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6086 10.17487/RFC6086
RFC6087 Guidelines for Authors and Reviewers of YANG Data Model Documents A. Bierman January 2011 ASCII HTML 26 NETMOD NETCONF XML YANG

This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) implementations that utilize YANG data model modules. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netmod-yang-usage-11 RFC8407 INFORMATIONAL INFORMATIONAL IETF ops netmod 10.17487/RFC6087
RFC6088 Traffic Selectors for Flow Bindings G. Tsirtsis G. Giarreta H. Soliman N. Montavont January 2011 ASCII HTML 13 Mobile IPv6 Binary Traffic Selectors

This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. [STANDARDS-TRACK]

draft-ietf-mext-binary-ts-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6088
RFC6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support G. Tsirtsis H. Soliman N. Montavont G. Giaretta K. Kuladinithi January 2011 ASCII HTML 31 Flow Identification Flow Summary Binding Reference Traffic Selector Flow Binding Entry

This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. [STANDARDS- TRACK]

draft-ietf-mext-flow-binding-11 RFC5648 PROPOSED STANDARD PROPOSED STANDARD IETF int mext 10.17487/RFC6089
RFC6090 Fundamental Elliptic Curve Cryptography Algorithms D. McGrew K. Igoe M. Salter February 2011 ASCII HTML 34 ECC

This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mcgrew-fundamental-ecc-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6090 10.17487/RFC6090
RFC6091 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication N. Mavrogiannopoulos D. Gillmor February 2011 ASCII HTML 9 Certificate type negotiation tls handshake protocol handshake

This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mavrogiannopoulos-rfc5081bis-09 RFC5081 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6091
RFC6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service J. Woodyatt Editor January 2011 ASCII HTML 36 cpe firewall filter

This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-cpe-simple-security-16 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6092
RFC6093 On the Implementation of the TCP Urgent Mechanism F. Gont A. Yourtchenko January 2011 ASCII HTML 12 Transmission Control Protocol

This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]

draft-ietf-tcpm-urgent-data-07 RFC0793 RFC1011 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=6093 10.17487/RFC6093
RFC6094 Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols M. Bhatia V. Manral February 2011 ASCII HTML 11 IGP security

The routing protocols Open Shortest Path First version 2 (OSPFv2), Intermediate System to Intermediate System (IS-IS), and Routing Information Protocol (RIP) currently define cleartext and MD5 (Message Digest 5) methods for authenticating protocol packets. Recently, effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.

To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.

Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.

This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-igp-crypto-requirements-04 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC6094
RFC6095 Extending YANG with Language Abstractions B. Linowski M. Ersue S. Kuryla March 2011 ASCII HTML 75 YANG model complex-type Complex Types Typed Instance Resource Model Inheritance class

YANG -- the Network Configuration Protocol (NETCONF) Data Modeling Language -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancing YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. This document defines an Experimental Protocol for the Internet community.

draft-linowski-netmod-yang-abstract-05 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6095
RFC6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration M. Tuexen R. Stewart January 2011 ASCII HTML 8

This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream Control Transmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-chunk-flags-02 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6096
RFC6097 Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 J. Korhonen V. Devarapalli February 2011 ASCII HTML 10 PMIPv6 3GPP DNS AAA

Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netlmm-lma-discovery-08 INFORMATIONAL INFORMATIONAL IETF int netlmm 10.17487/RFC6097
RFC6098 Generic Notification Message for Mobile IPv4 H. Deng H. Levkowetz V. Devarapalli S. Gundavelli B. Haley April 2012 ASCII HTML 33 mipv4

This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. [STANDARDS-TRACK]

draft-ietf-mip4-generic-notification-message-16 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6098
RFC6099 RFC6100 RFC6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 A. Freier P. Karlton P. Kocher August 2011 ASCII HTML 67 Transport layer security

This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.

This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.

draft-mavrogiannopoulos-ssl-version3-06 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6101
RFC6102 RFC6103 RFC6104 Rogue IPv6 Router Advertisement Problem Statement T. Chown S. Venaas February 2011 ASCII HTML 16 RA rogue ra

When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-rogue-ra-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6104
RFC6105 IPv6 Router Advertisement Guard E. Levy-Abegnoli G. Van de Velde C. Popoviciu J. Mohacsi February 2011 ASCII HTML 10 SEcure Neighbor Discovery Stateless Address Autoconfiguration

Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-ra-guard-08 RFC7113 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6105
RFC6106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli November 2010 ASCII HTML 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. [STANDARDS-TRACK]

draft-ietf-6man-dns-options-bis-08 RFC5006 RFC8106 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6106 10.17487/RFC6106
RFC6107 Procedures for Dynamically Signaled Hierarchical Label Switched Paths K. Shiomoto Editor A. Farrel Editor February 2011 ASCII HTML 30 TE links Bundled links GMPLS dynamically provisioned networks

Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.

Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK]

draft-ietf-ccamp-lsp-hierarchy-bis-08 RFC3477 RFC4206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=6107 10.17487/RFC6107
RFC6108 Comcast's Web Notification System Design C. Chung A. Kasyanov J. Livingood N. Mody B. Van Lieu February 2011 ASCII HTML 24 ISP Internet Service Provider bot remediation bot notification

The objective of this document is to describe a method of providing critical end-user notifications to web browsers, which has been deployed by Comcast, an Internet Service Provider (ISP). Such a notification system is being used to provide near-immediate notifications to customers, such as to warn them that their traffic exhibits patterns that are indicative of malware or virus infection. There are other proprietary systems that can perform such notifications, but those systems utilize Deep Packet Inspection (DPI) technology. In contrast to DPI, this document describes a system that does not rely upon DPI, and is instead based in open IETF standards and open source applications. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-livingood-web-notification-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6108
RFC6109 La Posta Elettronica Certificata - Italian Certified Electronic Mail C. Petrucci F. Gennai A. Shahin A. Vinciarelli April 2011 ASCII HTML 65 PEC Registered mail Return receipt Digitally signed email Digitally signed notification MIME SMIME

Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing.

The design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National Research Council (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-gennai-smime-cnipa-pec-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6109 10.17487/RFC6109
RFC6110 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content L. Lhotka Editor February 2011 ASCII HTML 100 DSDL validation RELAX NG Schematron DSRL

This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]

draft-ietf-netmod-dsdl-map-10 RFC7952 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6110 10.17487/RFC6110
RFC6111 Additional Kerberos Naming Constraints L. Zhu April 2011 ASCII HTML 6 principal names realm names

This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. [STANDARDS- TRACK]

draft-ietf-krb-wg-naming-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6111
RFC6112 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman April 2011 ASCII HTML 16 kerberos realm

This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. [STANDARDS-TRACK]

draft-ietf-krb-wg-anon-12 RFC8062 RFC4120 RFC4121 RFC4556 HISTORIC PROPOSED STANDARD IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6112 10.17487/RFC6112
RFC6113 A Generalized Framework for Kerberos Pre-Authentication S. Hartman L. Zhu April 2011 ASCII HTML 48

Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a facility called pre-authentication. Pre-authentication mechanisms can use this facility to extend the Kerberos protocol and prove the identity of a principal.

This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.

This document also provides common tools needed by multiple pre-authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. [STANDARDS-TRACK]

draft-ietf-krb-wg-preauth-framework-17 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6113
RFC6114 The 128-Bit Blockcipher CLEFIA M. Katagi S. Moriai March 2011 ASCII HTML 33 security lightweight cryptography encryption algorithm

This document describes the specification of the blockcipher CLEFIA. CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and 256 bits, which is compatible with the interface of the Advanced Encryption Standard (AES). The algorithm of CLEFIA was published in 2007, and its security has been scrutinized in the public community. CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to the Internet, which will be connected to more distributed and constrained devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-katagi-clefia-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6114
RFC6115 Recommendation for a Routing Architecture T. Li Editor February 2011 ASCII HTML 73

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-rrg-recommendation-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6115
RFC6116 The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) S. Bradner L. Conroy K. Fujiwara March 2011 ASCII HTML 22 DNS E.164 NAPTR dynamic delegation discovery system e164.arpa

This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-3761bis-09 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6116
RFC6117 IANA Registration of Enumservices: Guide, Template, and IANA Considerations B. Hoeneisen A. Mayrhofer J. Livingood March 2011 ASCII HTML 40 domain name system

This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. [STANDARDS-TRACK]

draft-ietf-enum-enumservices-guide-22 RFC3761 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6117
RFC6118 Update of Legacy IANA Registrations of Enumservices B. Hoeneisen A. Mayrhofer March 2011 ASCII HTML 68 domain name system

This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. [STANDARDS-TRACK]

draft-ietf-enum-enumservices-transition-06 RFC3762 RFC3764 RFC3953 RFC4143 RFC4002 RFC4238 RFC4355 RFC4415 RFC4769 RFC4969 RFC4979 RFC5028 RFC5278 RFC5333 PROPOSED STANDARD PROPOSED STANDARD IETF rai enum 10.17487/RFC6118
RFC6119 IPv6 Traffic Engineering in IS-IS J. Harrison J. Berger M. Bartlett February 2011 ASCII HTML 10

This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]

draft-ietf-isis-ipv6-te-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6119
RFC6120 Extensible Messaging and Presence Protocol (XMPP): Core P. Saint-Andre March 2011 ASCII HTML 211 XMPP Extensible Messaging and Presence Protocol Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]

draft-ietf-xmpp-3920bis-22 RFC3920 RFC7590 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6120 10.17487/RFC6120
RFC6121 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence P. Saint-Andre March 2011 ASCII HTML 114 XMPP Extensible Messaging and Presence Protocol Jabber IM Instant Messaging Presence XML Extensible Markup Language

This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]

draft-ietf-xmpp-3921bis-20 RFC3921 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6121 10.17487/RFC6121
RFC6122 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre March 2011 ASCII HTML 23 XMPP Jabber Messaging Instant Messaging Presence Extensible Markup Language XML

This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. [STANDARDS-TRACK]

draft-ietf-xmpp-address-09 RFC7622 RFC3920 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp http://www.rfc-editor.org/errata_search.php?rfc=6122 10.17487/RFC6122
RFC6123 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts A. Farrel February 2011 ASCII HTML 13

It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community.

draft-ietf-pce-manageability-requirements-11 HISTORIC HISTORIC IETF rtg pce 10.17487/RFC6123
RFC6124 An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol Y. Sheffer G. Zorn H. Tschofenig S. Fluhrer February 2011 ASCII HTML 33 password-based authentication mutual authentication password-based cryptography password authenticated key exchange weak password authentication

The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sheffer-emu-eap-eke-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6124
RFC6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) P. Saint-Andre J. Hodges March 2011 ASCII HTML 57

Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]

draft-saintandre-tls-server-id-check-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6125 10.17487/RFC6125
RFC6126 The Babel Routing Protocol J. Chroboczek April 2011 ASCII HTML 45

Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document defines an Experimental Protocol for the Internet community.

draft-chroboczek-babel-routing-protocol-05 RFC7298 RFC7557 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6126 10.17487/RFC6126
RFC6127 IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios J. Arkko M. Townsley May 2011 ASCII HTML 20 address depletion translation NAT-PT dual-stack Softwire Behave NAT NAT444

When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.

This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-arkko-townsley-coexistence-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6127
RFC6128 RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions A. Begen February 2011 ASCII HTML 6

The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK]

draft-ietf-avt-rtcp-port-for-ssm-04 RFC5760 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6128
RFC6129 The 'application/tei+xml' Media Type L. Romary S. Lundberg February 2011 ASCII HTML 8 Text Encoding Initiative xml text encoding text representation MIME type

This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding and Interchange guidelines. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-lundberg-app-tei-xml-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6129 10.17487/RFC6129
RFC6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) T. Clausen C. Dearlove J. Dean April 2011 ASCII HTML 88 MANET OLSRv2 packetbb Routing Protocol NHDP ad hoc network bi-directional 2-hop discovery Wireless SMF

This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). [STANDARDS-TRACK]

draft-ietf-manet-nhdp-15 RFC7183 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6130 10.17487/RFC6130
RFC6131 Sieve Vacation Extension: "Seconds" Parameter R. George B. Leiba July 2011 ASCII HTML 5 email filters auto-replies

This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. [STANDARDS-TRACK]

draft-ietf-sieve-vacation-seconds-03 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6131
RFC6132 Sieve Notification Using Presence Information R. George B. Leiba July 2011 ASCII HTML 8 email filters context status

This is a further extension to the Sieve mail filtering language Notification extension, defining presence information that may be checked through the notify_method_capability feature. [STANDARDS-TRACK]

draft-ietf-sieve-notify-presence-04 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6132
RFC6133 Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality R. George B. Leiba A. Melnikov July 2011 ASCII HTML 9

This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sieve-autoreply-04 INFORMATIONAL INFORMATIONAL IETF app sieve 10.17487/RFC6133
RFC6134 Sieve Extension: Externally Stored Lists A. Melnikov B. Leiba July 2011 ASCII HTML 18

The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.

This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol (LDAP), the Application Configuration Access Protocol (ACAP), vCard Extensions to WebDAV (CardDAV), or relational databases. [STANDARDS-TRACK]

draft-ietf-sieve-external-lists-10 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6134
RFC6135 An Alternative Connection Model for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau February 2011 ASCII HTML 8 comedia comedia-tls relay SBC

This document defines an alternative connection model for Message Session Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create the MSRP transport connection. The model allows MSRP UAs behind Network Address Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. [STANDARDS-TRACK]

draft-ietf-simple-msrp-acm-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6135
RFC6136 Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework A. Sajassi Editor D. Mohan Editor March 2011 ASCII HTML 42

This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l2vpn-oam-req-frmk-11 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6136
RFC6137 The Network Trouble Ticket Data Model (NTTDM) D. Zisiadis Editor S. Kopsidas Editor M. Tsavli Editor G. Cessieux Editor February 2011 ASCII HTML 46 Grid Management EGEE

Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent, and disseminate TT information in different formats.

As a result, management of the daily workload by a central Network Operation Centre (NOC) is a challenge on its own. Normalization of TTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project. This document defines an Experimental Protocol for the Internet community.

draft-dzis-nwg-nttdm-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6137 10.17487/RFC6137
RFC6138 LDP IGP Synchronization for Broadcast Networks S. Kini Editor W. Lu Editor February 2011 ASCII HTML 9

RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior Gateway Protocol (IGP) is operational on a link but Label Distribution Protocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol message changes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-ldp-igp-sync-bcast-06 RFC5443 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6138
RFC6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios S. Russert Editor E. Fleischman Editor F. Templin Editor February 2011 ASCII HTML 39 Encapsulation Tunnel Architecture Scalability Mobility MANET Security IPv6 Aerospace IRON VET SEAL ISATAP

"Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-russert-rangers-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6139
RFC6140 Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) A.B. Roach March 2011 ASCII HTML 35 Bulk Registration Implicit Registration GIN PBX SSP SIP-PBX

This document defines a mechanism by which a Session Initiation Protocol (SIP) server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique. This document therefore focuses on this use case. [STANDARDS-TRACK]

draft-ietf-martini-gin-13 RFC3680 PROPOSED STANDARD PROPOSED STANDARD IETF rai martini http://www.rfc-editor.org/errata_search.php?rfc=6140 10.17487/RFC6140
RFC6141 Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) G. Camarillo Editor C. Holmberg Y. Gao March 2011 ASCII HTML 26 re-INVITE offer/answer rollback

The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. [STANDARDS-TRACK]

draft-ietf-sipcore-reinvite-08 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6141
RFC6142 ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP A. Moise J. Brodkin March 2011 ASCII HTML 26 Advanced Metering Infrastructure ami application layer message

This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.

This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-c1222-transport-over-ip-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6142
RFC6143 The Remote Framebuffer Protocol T. Richardson J. Levine March 2011 ASCII HTML 39 vnc rfb remote framebuffer remote GUI

RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-levine-rfb-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6143 10.17487/RFC6143
RFC6144 Framework for IPv4/IPv6 Translation F. Baker X. Li C. Bao K. Yin April 2011 ASCII HTML 31 stateless translation stateful translation

This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-behave-v6v4-framework-10 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6144
RFC6145 IP/ICMP Translation Algorithm X. Li C. Bao F. Baker April 2011 ASCII HTML 33 SIIT] internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm,

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765. [STANDARDS-TRACK]

draft-ietf-behave-v6v4-xlate-23 RFC2765 RFC7915 RFC6791 RFC7757 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6145 10.17487/RFC6145
RFC6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers M. Bagnulo P. Matthews I. van Beijnum April 2011 ASCII HTML 45 NAT64 IPv6 draft-ietf-behave-v6v4-xlate-stateful-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6146 10.17487/RFC6146 RFC6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers M. Bagnulo A. Sullivan P. Matthews I. van Beijnum April 2011 ASCII HTML 32 AAAA

DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]

draft-ietf-behave-dns64-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6147 10.17487/RFC6147
RFC6148 DHCPv4 Lease Query by Relay Agent Remote ID P. Kurapati R. Desetti B. Joshi February 2011 ASCII HTML 13 dynamic host configuration protocol

Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. [STANDARDS-TRACK]

draft-ietf-dhc-leasequery-by-remote-id-09 RFC4388 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6148
RFC6149 MD2 to Historic Status S. Turner L. Chen March 2011 ASCII HTML 7 security encryption signature

This document retires MD2 and discusses the reasons for doing so. This document moves RFC 1319 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-md2-to-historic-10 RFC1319 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6149 10.17487/RFC6149
RFC6150 MD4 to Historic Status S. Turner L. Chen March 2011 ASCII HTML 10 MD4 security encryption signature

This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-md4-to-historic-11 RFC1320 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6150 10.17487/RFC6150
RFC6151 Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms S. Turner L. Chen March 2011 ASCII HTML 7 signature eneryption ipsec Message Digest encryption

This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-md5-seccon-update-08 RFC1321 RFC2104 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6151
RFC6152 SMTP Service Extension for 8-bit MIME Transport J. Klensin N. Freed M. Rose D. Crocker Editor March 2011 ASCII HTML 7 simple mail transfer

This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK]

draft-ietf-yam-rfc1652bis-03 RFC1652 STD0071 INTERNET STANDARD INTERNET STANDARD IETF app yam http://www.rfc-editor.org/errata_search.php?rfc=6152 10.17487/RFC6152
RFC6153 DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery S. Das G. Bajko February 2011 ASCII HTML 7 Dynamic Host Configuration Protocol

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover Access Network Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third Generation Partnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes (MNs). [STANDARDS-TRACK]

draft-das-mipshop-andsf-dhcp-options-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6153
RFC6154 IMAP LIST Extension for Special-Use Mailboxes B. Leiba J. Nicolson March 2011 ASCII HTML 12 IMAP email

Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK]

draft-ietf-morg-list-specialuse-06 PROPOSED STANDARD PROPOSED STANDARD IETF app morg http://www.rfc-editor.org/errata_search.php?rfc=6154 10.17487/RFC6154
RFC6155 Use of Device Identity in HTTP-Enabled Location Delivery (HELD) J. Winterbottom M. Thomson H. Tschofenig R. Barnes March 2011 ASCII HTML 27

When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.

Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.

This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. [STANDARDS-TRACK]

draft-ietf-geopriv-held-identity-extensions-06 RFC6915 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6155
RFC6156 Traversal Using Relays around NAT (TURN) Extension for IPv6 G. Camarillo O. Novo S. Perreault Editor April 2011 ASCII HTML 14 STUN TURN IPv6

This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). [STANDARDS-TRACK]

draft-ietf-behave-turn-ipv6-11 RFC8656 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6156
RFC6157 IPv6 Transition in the Session Initiation Protocol (SIP) G. Camarillo K. El Malki V. Gurbani April 2011 ASCII HTML 15

This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK]

draft-ietf-sipping-v6-transition-07 RFC3264 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping http://www.rfc-editor.org/errata_search.php?rfc=6157 10.17487/RFC6157
RFC6158 RADIUS Design Guidelines A. DeKok Editor G. Weber March 2011 ASCII HTML 38

This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice.

draft-ietf-radext-design-19 RFC6929 RFC8044 BCP0158 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops radext 10.17487/RFC6158
RFC6159 Session-Specific Explicit Diameter Request Routing T. Tsou G. Zorn T. Taylor Editor April 2011 ASCII HTML 19 Diameter routing

This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-tsou-diameter-explicit-routing-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6159
RFC6160 Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types S. Turner April 2011 ASCII HTML 5

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. [STANDARDS-TRACK]

draft-turner-cms-symmetrickeypackage-algs-00 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6160
RFC6161 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type S. Turner April 2011 ASCII HTML 3 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 6033. [STANDARDS-TRACK]

draft-turner-ekpct-algs-update-03 RFC6033 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6161
RFC6162 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type S. Turner April 2011 ASCII HTML 4 ecdsa ecdh EnvelopedData and Elliptic Curve Digital Signature Algorithm

This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData. This document extends RFC 5959. [STANDARDS-TRACK]

draft-turner-akf-algs-update-03 RFC5959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6162
RFC6163 Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) Y. Lee Editor G. Bernstein Editor W. Imajuku April 2011 ASCII HTML 51 Generalized Multi-Protocol Label Switching Routing and Wavelength Assignment RWA

This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of Wavelength Switched Optical Networks (WSONs). In particular, it examines Routing and Wavelength Assignment (RWA) of optical paths.

This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-rwa-wson-framework-12 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6163
RFC6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links M. Kohno B. Nitzan R. Bush Y. Matsuzaki L. Colitti T. Narten April 2011 ASCII HTML 8 addressing prefix length security

On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. [STANDARDS-TRACK]

draft-ietf-6man-prefixlen-p2p-01 RFC6547 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6164 10.17487/RFC6164
RFC6165 Extensions to IS-IS for Layer-2 Systems A. Banerjee D. Ward April 2011 ASCII HTML 7 Intermediate System to Intermediate System

This document specifies the Intermediate System to Intermediate System (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs (TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. [STANDARDS- TRACK]

draft-ietf-isis-layer2-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6165
RFC6166 A Registry for PIM Message Types S. Venaas April 2011 ASCII HTML 4 IANA Protocol Independent Multicast

This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types.

In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]

draft-ietf-pim-registry-04 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6166
RFC6167 URI Scheme for Java(tm) Message Service 1.0 M. Phillips P. Adams D. Rokicki E. Johnson April 2011 ASCII HTML 22 SOAP JMS JNDI IRI

This document defines the format of Uniform Resource Identifiers (URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS). It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMS URI is not compatible with previously existing, but unregistered, "jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-merrick-jms-uri-12 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6167 10.17487/RFC6167
RFC6168 Requirements for Management of Name Servers for the DNS W. Hardaker May 2011 ASCII HTML 17 DNS Domain Name System Management

Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.

This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-name-server-management-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6168
RFC6169 Security Concerns with IP Tunneling S. Krishnan D. Thaler J. Hoagland April 2011 ASCII HTML 20

A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]

draft-ietf-v6ops-tunnel-security-concerns-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6169
RFC6170 Internet X.509 Public Key Infrastructure -- Certificate Image S. Santesson R. Housley S. Bajaj L. Rosenthol May 2011 ASCII HTML 12 otherLogos

This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. [STANDARDS-TRACK]

draft-ietf-pkix-certimage-11 RFC3709 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6170
RFC6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control K. Zeilenga March 2011 ASCII HTML 6 x.511 dontusecopy

This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. [STANDARDS-TRACK]

draft-zeilenga-ldap-dontusecopy-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6171
RFC6172 Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode D. Black D. Peterson March 2011 ASCII HTML 6 FCIP

Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.

iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.

This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]

draft-ietf-storm-ifcp-ipn133-updates-03 RFC4172 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6172
RFC6173 Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) P. Venkatesen Editor March 2011 ASCII HTML 31 Management Information Base mib IFCP-MGMT-MIB

This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.

This document obsoletes RFC 4369. [STANDARDS-TRACK]

draft-ietf-storm-ifcpmib-07 RFC4369 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6173
RFC6174 Definition of IETF Working Group Document States E. Juskevicius March 2011 ASCII HTML 25 WG I-D States I-D Availability States

The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.

This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-proto-wgdocument-states-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6174
RFC6175 Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors E. Juskevicius March 2011 ASCII HTML 23 WG Document States I-D States

This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for Working Group (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use the Datatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-juskevicius-datatracker-wgdocstate-reqts-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6175
RFC6176 Prohibiting Secure Sockets Layer (SSL) Version 2.0 S. Turner T. Polk March 2011 ASCII HTML 4

This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport Layer Security (TLS). [STANDARDS-TRACK]

draft-ietf-tls-ssl2-must-not-04 RFC2246 RFC4346 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6176 10.17487/RFC6176
RFC6177 IPv6 Address Assignment to End Sites T. Narten G. Huston L. Roberts March 2011 ASCII HTML 9 internet architecture board engineering steering group protocol

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.

This document obsoletes RFC 3177. [STANDARDS-TRACK]

draft-ietf-v6ops-3177bis-end-sites-01 RFC3177 BCP0157 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC6177
RFC6178 Label Edge Router Forwarding of IPv4 Option Packets D. Smith J. Mullooly W. Jaeger T. Scholl March 2011 ASCII HTML 9 FEC MPLS LER Security DoS

This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in different LER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. [STANDARDS-TRACK]

draft-ietf-mpls-ip-options-07 RFC3031 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6178
RFC6179 The Internet Routing Overlay Network (IRON) F. Templin Editor March 2011 ASCII HTML 37 Encapsulation Tunnel Architecture Scalability Mobility MANET Security Recursion Addressing Routing IPv6 Aerospace Aeronautics Space IRON RANGER VET SEAL ISATAP

Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-templin-iron-17 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6179
RFC6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment J. Arkko F. Baker May 2011 ASCII HTML 20

The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-arkko-ipv6-transition-guidelines-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6180
RFC6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses M. Bagnulo March 2011 ASCII HTML 17 Multipath TCP threats security MPTCP

Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mptcp-threat-08 INFORMATIONAL INFORMATIONAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6181 10.17487/RFC6181
RFC6182 Architectural Guidelines for Multipath TCP Development A. Ford C. Raiciu M. Handley S. Barre J. Iyengar March 2011 ASCII HTML 28 multipath tcp architecture

Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.

This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of a Multipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mptcp-architecture-05 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6182
RFC6183 IP Flow Information Export (IPFIX) Mediation: Framework A. Kobayashi B. Claise G. Muenz K. Ishibashi April 2011 ASCII HTML 29

This document describes a framework for IP Flow Information Export (IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ipfix-mediators-framework-09 RFC5470 INFORMATIONAL INFORMATIONAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6183 10.17487/RFC6183
RFC6184 RTP Payload Format for H.264 Video Y.-K. Wang R. Even T. Kristensen R. Jesup May 2011 ASCII HTML 101 AVC H.264/AVC Advanced Video Coding

This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.

This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK]

draft-ietf-avt-rtp-rfc3984bis-12 RFC3984 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt http://www.rfc-editor.org/errata_search.php?rfc=6184 10.17487/RFC6184
RFC6185 RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video T. Kristensen P. Luthi May 2011 ASCII HTML 22 H.264 H.241 ITU-T RTP Video SDP RCDO

This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK]

draft-ietf-avt-rtp-h264-rcdo-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6185
RFC6186 Use of SRV Records for Locating Email Submission/Access Services C. Daboo March 2011 ASCII HTML 9 imap pop3 smtp dns discovery

This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]

draft-daboo-srv-email-05 RFC1939 RFC3501 RFC8314 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6186
RFC6187 X.509v3 Certificates for Secure Shell Authentication K. Igoe D. Stebila March 2011 ASCII HTML 16

X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. [STANDARDS-TRACK]

draft-igoe-secsh-x509v3-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6187
RFC6188 The Use of AES-192 and AES-256 in Secure RTP D. McGrew March 2011 ASCII HTML 16 SRTP

This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK]

draft-ietf-avt-srtp-big-aes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6188
RFC6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP P. Zimmermann A. Johnston Editor J. Callas April 2011 ASCII HTML 115

This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zimmermann-avt-zrtp-22 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6189
RFC6190 RTP Payload Format for Scalable Video Coding S. Wenger Y.-K. Wang T. Schierl A. Eleftheriadis May 2011 ASCII HTML 100 SVC AVC H.264/AVC Advanced Video Coding Scalable Video Coding

This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]

draft-ietf-avt-rtp-svc-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload http://www.rfc-editor.org/errata_search.php?rfc=6190 10.17487/RFC6190
RFC6191 Reducing the TIME-WAIT State Using TCP Timestamps F. Gont April 2011 ASCII HTML 10

This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP Timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. This memo documents an Internet Best Current Practice.

draft-ietf-tcpm-tcp-timestamps-04 BCP0159 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpm 10.17487/RFC6191
RFC6192 Protecting the Router Control Plane D. Dugal C. Pignataro R. Dunn March 2011 ASCII HTML 25 ACL Router Control Plane Protection Filter

This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.

Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-protect-control-plane-06 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6192 10.17487/RFC6192
RFC6193 Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP) M. Saito D. Wing M. Toyama April 2011 ASCII HTML 22 SIP IPsec setup VPN

This document specifies how to establish a media session that represents a virtual private network using the Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the Session Description Protocol (SDP) so that it can negotiate use of the Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-saito-mmusic-sdp-ike-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6193
RFC6194 Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms T. Polk L. Chen S. Turner P. Hoffman March 2011 ASCII HTML 7

This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-sha0-sha1-seccon-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6194 10.17487/RFC6194
RFC6195 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd March 2011 ASCII HTML 17 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. This memo documents an Internet Best Current Practice.

draft-ietf-dnsext-5395bis-03 RFC5395 RFC6895 RFC1183 RFC3597 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6195
RFC6196 Moving mailserver: URI Scheme to Historic A. Melnikov March 2011 ASCII HTML 3 mailserver URI

This document registers the mailserver: URI scheme as historic in the IANA URI registry. [STANDARDS-TRACK]

draft-melnikov-mailserver-uri-to-historic-00 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6196 10.17487/RFC6196
RFC6197 Location-to-Service Translation (LoST) Service List Boundary Extension K. Wolf April 2011 ASCII HTML 15 listservicesbylocation

Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation> query to the LoST server. However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ecrit-lost-servicelistboundary-05 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit 10.17487/RFC6197
RFC6198 Requirements for the Graceful Shutdown of BGP Sessions B. Decraene P. Francois C. Pelsser Z. Ahmad A.J. Elizondo Armengol T. Takeda April 2011 ASCII HTML 20 routing BGP graceful shutdown connectivity loss maintenance network operation make-before-break planned

The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications (e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-bgp-graceful-shutdown-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6198
RFC6199 RFC6200 RFC6201 Device Reset Characterization R. Asati C. Pignataro F. Calabria C. Olvera March 2011 ASCII HTML 17 operation redundancy failover

An operational forwarding device may need to be restarted (automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.

This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-reset-06 RFC1242 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6201
RFC6202 Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP S. Loreto P. Saint-Andre S. Salsano G. Wilkins April 2011 ASCII HTML 19 Hypertext Transfer Protocol bidirectional HTTP HTTP long polling HTTP streaming

On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-loreto-http-bidirectional-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6202
RFC6203 IMAP4 Extension for Fuzzy Search T. Sirainen March 2011 ASCII HTML 7 email

This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. [STANDARDS-TRACK]

draft-ietf-morg-fuzzy-search-03 PROPOSED STANDARD PROPOSED STANDARD IETF app morg 10.17487/RFC6203
RFC6204 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark O. Troan Editor April 2011 ASCII HTML 17 IPv6 CE requirements

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-ipv6-cpe-router-09 RFC7084 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6204 10.17487/RFC6204
RFC6205 Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers T. Otani Editor D. Li Editor March 2011 ASCII HTML 15 DWDM CWDM Wavelength Label LSC

Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.

Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors. Global wavelength semantics are not considered.

In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-g-694-lambda-labels-11 RFC3471 RFC7699 RFC8359 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6205
RFC6206 The Trickle Algorithm P. Levis T. Clausen J. Hui O. Gnawali J. Ko March 2011 ASCII HTML 13 Consistency Eventual consistency Low-power Low power

The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK]

draft-ietf-roll-trickle-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6206
RFC6207 The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml R. Denenberg Editor April 2011 ASCII HTML 11 mods Metadata Object Description Schema MADS Metadata Authority Description Schema METS Metadata Encoding and Transmission Standard MARCXML MARC21 XML Schema SRU Search/Retrieve via URL Response Format

This document specifies media types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-denenberg-mods-etc-media-types-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6207
RFC6208 Cloud Data Management Interface (CDMI) Media Types K. Sankar Editor A. Jones April 2011 ASCII HTML 13 snia Storage Networking Industry Association

This document describes several Internet media types defined for the Cloud Data Management Interface (CDMI) by the Storage Networking Industry Association (SNIA). The media types are:

o application/cdmi-object

o application/cdmi-container

o application/cdmi-domain

o application/cdmi-capability

o application/cdmi-queue

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cdmi-mediatypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6208
RFC6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) W. Kim J. Lee J. Park D. Kwon April 2011 ASCII HTML 9 aria encryption

This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-nsri-tls-aria-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6209
RFC6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME J. Schaad April 2011 ASCII HTML 14 example MD5-XOR Parameterized

New hash algorithms are being developed that may include parameters. Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. This document defines an Experimental Protocol for the Internet community.

draft-schaad-smime-hash-experiment-06 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6210 10.17487/RFC6210
RFC6211 Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute J. Schaad April 2011 ASCII HTML 11 example s/mime SMIME

The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. [STANDARDS-TRACK]

draft-schaad-smime-algorithm-attribute-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6211
RFC6212 Authentication-Results Registration for Vouch by Reference Results M. Kucherawy April 2011 ASCII HTML 7 VBR Reputation DKIM

This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]

draft-kucherawy-authres-vbr-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6212
RFC6213 IS-IS BFD-Enabled TLV C. Hopps L. Ginsberg April 2011 ASCII HTML 7 type-length-value Bidirectional Forwarding Detection

This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to a BFD-detected forwarding plane failure without use of either this TLV or some other method. [STANDARDS-TRACK]

draft-ietf-isis-bfd-tlv-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6213
RFC6214 Adaptation of RFC 1149 for IPv6 B. Carpenter R. Hinden April 1 2011 ASCII HTML 7 avian carrier april fool

This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-carpenter-6man-adapt-rfc1149-00 RFC1149 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6214 10.17487/RFC6214
RFC6215 MPLS Transport Profile User-to-Network and Network-to-Network Interfaces M. Bocci L. Levrau D. Frost April 2011 ASCII HTML 6

The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-uni-nni-03 RFC5921 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6215
RFC6216 Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms C. Jennings K. Ono R. Sparks B. Hibbard Editor April 2011 ASCII HTML 67

This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipcore-sec-flows-09 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC6216
RFC6217 Regional Broadcast Using an Atmospheric Link Layer T. Ritter April 1 2011 ASCII HTML 9

Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ritter-regional-bcast-atmospheric-linklayer-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6217
RFC6218 Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material G. Zorn T. Zhang J. Walker J. Salowey April 2011 ASCII HTML 18 Security

This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zorn-radius-keywrap-18 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6218 10.17487/RFC6218
RFC6219 The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition X. Li C. Bao M. Chen H. Zhang J. Wu May 2011 ASCII HTML 22 Stateless IPv4/IPv6 translation IPv4/IPv6 Header Translation IPv4-embedded IPv6 Address IPv4/IPv6 Multicast Translation stateless NAT64

This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.

The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-xli-behave-ivi-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6219
RFC6220 Defining the Role and Function of IETF Protocol Parameter Registry Operators D. McPherson Editor O. Kolkman Editor J. Klensin Editor G. Huston Editor Internet Architecture Board April 2011 ASCII HTML 11

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-iana-08 RFC8722 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6220
RFC6221 Lightweight DHCPv6 Relay Agent D. Miles Editor S. Ooghe W. Dec S. Krishnan A. Kavanagh May 2011 ASCII HTML 17 ipv6 dsl

This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-ldra-03 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6221 10.17487/RFC6221
RFC6222 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing April 2011 ASCII HTML 9

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [STANDARDS-TRACK]

draft-ietf-avt-rtp-cnames-05 RFC7022 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6222
RFC6223 Indication of Support for Keep-Alive C. Holmberg April 2011 ASCII HTML 18 SIP STUN outbound NAT traversal

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network Address Translation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. [STANDARDS-TRACK]

draft-ietf-sipcore-keep-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6223
RFC6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt M. Waehlisch S. Krishnan April 2011 ASCII HTML 19 MLD proxy multicast routing mobility management transparent handover

This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-multimob-pmipv6-base-solution-07 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6224
RFC6225 Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information J. Polk M. Linsner M. Thomson B. Aboba Editor July 2011 ASCII HTML 36

This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. [STANDARDS-TRACK]

draft-ietf-geopriv-rfc3825bis-17 RFC3825 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv http://www.rfc-editor.org/errata_search.php?rfc=6225 10.17487/RFC6225
RFC6226 PIM Group-to-Rendezvous-Point Mapping B. Joshi A. Kessler D. McWalter May 2011 ASCII HTML 11 auto-RP BSR hash algorithm

Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintains Group-to-RP mappings that are used to identify a Rendezvous Point (RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.

This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group. This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. [STANDARDS-TRACK]

draft-ietf-pim-group-rp-mapping-10 RFC4601 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6226
RFC6227 Design Goals for Scalable Internet Routing T. Li Editor May 2011 ASCII HTML 8 routing architecture addressing architecture

It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-rrg-design-goals-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6227
RFC6228 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog C. Holmberg May 2011 ASCII HTML 14 199 Early dialog Forking Provisional response

This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. [STANDARDS-TRACK]

draft-ietf-sipcore-199-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6228 10.17487/RFC6228
RFC6229 Test Vectors for the Stream Cipher RC4 J. Strombergson S. Josefsson May 2011 ASCII HTML 12 arcfour128 arcfour256 arcfour ARC4m Stream Cipher Test Vectors Known Answer Test arcfour ARC4 WEP WPA RFC 4345

This document contains test vectors for the stream cipher RC4. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-josefsson-rc4-test-vectors-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6229
RFC6230 Media Control Channel Framework C. Boulton T. Melanchuk S. McGlashan May 2011 ASCII HTML 49

This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.

The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. [STANDARDS-TRACK]

draft-ietf-mediactrl-sip-control-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6230
RFC6231 An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton May 2011 ASCII HTML 134

This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. [STANDARDS-TRACK]

draft-ietf-mediactrl-ivr-control-package-11 RFC6623 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6231 10.17487/RFC6231
RFC6232 Purge Originator Identification TLV for IS-IS F. Wei Y. Qin Z. Li T. Li J. Dong May 2011 ASCII HTML 6 Purge Originator Identification IIH:n LSP:y SNP:n Purge:y

At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS.

To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.

This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

draft-ietf-isis-purge-tlv-05 RFC5301 RFC5304 RFC5310 RFC8918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6232
RFC6233 IS-IS Registry Extension for Purges T. Li L. Ginsberg May 2011 ASCII HTML 4 Intermediate System to Intermediate System LSP security authentication IANA

IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]

draft-ietf-isis-reg-purge-01 RFC3563 RFC5304 RFC5310 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6233
RFC6234 US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) D. Eastlake 3rd T. Hansen May 2011 ASCII HTML 127

Federal Information Processing Standard, FIPS

draft-eastlake-sha2b-07 RFC4634 RFC3174 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6234 10.17487/RFC6234
RFC6235 IP Flow Anonymization Support E. Boschi B. Trammell May 2011 ASCII HTML 43 IPFIX flow information export address anonymization pseudonymization data protection privacy

This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ipfix-anon-06 EXPERIMENTAL EXPERIMENTAL IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6235 10.17487/RFC6235
RFC6236 Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) I. Johansson K. Jung May 2011 ASCII HTML 23

This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. [STANDARDS-TRACK]

draft-ietf-mmusic-image-attributes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6236 10.17487/RFC6236
RFC6237 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov May 2011 ASCII HTML 10 email multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. This document defines an Experimental Protocol for the Internet community.

draft-ietf-morg-multimailbox-search-07 RFC7377 RFC4466 EXPERIMENTAL EXPERIMENTAL IETF app morg 10.17487/RFC6237
RFC6238 TOTP: Time-Based One-Time Password Algorithm D. M'Raihi S. Machani M. Pei J. Rydell May 2011 ASCII HTML 16 OTP OATH HOTP two factor authentication strong authentication

This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.

The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mraihi-totp-timebased-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6238 10.17487/RFC6238
RFC6239 Suite B Cryptographic Suites for Secure Shell (SSH) K. Igoe May 2011 ASCII HTML 14

This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-igoe-secsh-suiteb-06 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6239
RFC6240 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 D. Zelig Editor R. Cohen Editor T. Nadeau Editor May 2011 ASCII HTML 67 management information base PW-CEP-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). [STANDARDS-TRACK]

draft-ietf-pwe3-cep-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6240
RFC6241 Network Configuration Protocol (NETCONF) R. Enns Editor M. Bjorklund Editor J. Schoenwaelder Editor A. Bierman Editor June 2011 ASCII HTML 113 XML Configuration Network Management Extensible Markup Language

The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]

draft-ietf-netconf-4741bis-10 RFC4741 RFC7803 RFC8526 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6241 10.17487/RFC6241
RFC6242 Using the NETCONF Protocol over Secure Shell (SSH) M. Wasserman June 2011 ASCII HTML 11 network configuration protocol

This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]

draft-ietf-netconf-rfc4742bis-08 RFC4742 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6242 10.17487/RFC6242
RFC6243 With-defaults Capability for NETCONF A. Bierman B. Lengyel June 2011 ASCII HTML 26 network configuration protocol

The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]

draft-ietf-netconf-with-defaults-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6243 10.17487/RFC6243
RFC6244 An Architecture for Network Management Using NETCONF and YANG P. Shafer June 2011 ASCII HTML 30 network configuration protocol

The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.

This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netmod-arch-10 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6244 10.17487/RFC6244
RFC6245 Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 P. Yegani K. Leung A. Lior K. Chowdhury J. Navali May 2011 ASCII HTML 8

The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple Virtual Private Networks (VPNs), which may have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when using IP-in-IP tunneling. [STANDARDS-TRACK]

draft-ietf-mip4-gre-key-extension-05 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6245
RFC6246 Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges A. Sajassi Editor F. Brockners D. Mohan Editor Y. Serbest June 2011 ASCII HTML 20 ieee bridges

One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.

When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l2vpn-vpls-bridge-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC6246
RFC6247 Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status L. Eggert May 2011 ASCII HTML 4

This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-eggert-tcpm-historicize-02 RFC1072 RFC1106 RFC1110 RFC1145 RFC1146 RFC1379 RFC1644 RFC1693 RFC4614 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6247
RFC6248 RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete A. Morton April 2011 ASCII HTML 6

This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM) Metrics Registry", as Obsolete, and withdraws the IANA IPPM Metrics Registry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-morton-ippm-rfc4148-obsolete-03 RFC4148 RFC4737 RFC5560 RFC5644 RFC6049 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6248
RFC6249 Metalink/HTTP: Mirrors and Hashes A. Bryan N. McNab T. Tsujikawa P. Poeml H. Nordstrom June 2011 ASCII HTML 21 file transfer download link signature data integrity hypertext transfer protocol ftp file transfer protocol metadata torrent

This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]

draft-bryan-metalinkhttp-22 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6249 10.17487/RFC6249
RFC6250 Evolution of the IP Model D. Thaler May 2011 ASCII HTML 25 Internet Protocol IPv4 IPv6 service model

This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were (and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-ip-model-evolution-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6250
RFC6251 Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol S. Josefsson May 2011 ASCII HTML 8 kerberos tls starttls kdc

This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-josefsson-kerberos5-starttls-09 INFORMATIONAL INFORMATIONAL IETF sec krb-wg 10.17487/RFC6251
RFC6252 A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization A. Dutta Editor V. Fajardo Y. Ohba K. Taniuchi H. Schulzrinne June 2011 ASCII HTML 57 Mobility Optimization Proactive handoff Link-layer security Handover taxonomy Layer 2 handoff Layer 3 handoff Network discovery Handover delay Packet loss Proactive binding update Multi-interface IP address acquisition Tunnel management

This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.

This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-mobopts-mpa-framework-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6252
RFC6253 Host Identity Protocol Certificates T. Heer S. Varjonen May 2011 ASCII HTML 12

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates.

The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 5201. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-cert-12 RFC8002 RFC5201 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6253
RFC6254 Request to Move RFC 2754 to Historic Status M. McFadden May 2011 ASCII HTML 3 RPS

RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System. In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iana-rfc2754-to-historic-02 RFC2754 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6254
RFC6255 Delay-Tolerant Networking Bundle Protocol IANA Registries M. Blanchet May 2011 ASCII HTML 9 DTN SNDV DTNRG Space networking

The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and Licklider Transmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions executed by IANA. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-dtnrg-iana-bp-registries-02 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6255
RFC6256 Using Self-Delimiting Numeric Values in Protocols W. Eddy E. Davies May 2011 ASCII HTML 17 SDNV DTN

Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-dtnrg-sdnv-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6256
RFC6257 Bundle Security Protocol Specification S. Symington S. Farrell H. Weiss P. Lovell May 2011 ASCII HTML 60

This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.

This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-security-19 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6257 10.17487/RFC6257
RFC6258 Delay-Tolerant Networking Metadata Extension Block S. Symington May 2011 ASCII HTML 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block that may be used with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-metadata-block-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6258
RFC6259 Delay-Tolerant Networking Previous-Hop Insertion Block S. Symington May 2011 ASCII HTML 10 DTN Delay-Tolerant Networking Distruption-Tolerant Networking

This document defines an extension block for use with the Delay- Tolerant Networking (DTN) Bundle Protocol. This Previous-Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-bundle-previous-hop-block-12 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6259
RFC6260 Compressed Bundle Header Encoding (CBHE) S. Burleigh May 2011 ASCII HTML 12 DTN delay-tolerant networking BP bundle protocol IPN

This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.

Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.

This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-cbhe-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6260
RFC6261 Encrypted Signaling Transport Modes for the Host Identity Protocol A. Keranen May 2011 ASCII HTML 13

This document specifies two transport modes for Host Identity Protocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-over-hip-06 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6261
RFC6262 RTP Payload Format for IP-MR Speech Codec S. Ikonin August 2011 ASCII HTML 19 ipmr vocoder multirate scalable scalability

This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. [STANDARDS-TRACK]

draft-ietf-avt-rtp-ipmr-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6262
RFC6263 Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows X. Marjou A. Sollaud June 2011 ASCII HTML 12 AVT SDP port

This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP Control Protocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. [STANDARDS-TRACK]

draft-ietf-avt-app-rtp-keepalive-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6263
RFC6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition S. Jiang D. Guo B. Carpenter June 2011 ASCII HTML 13

Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.

This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-incremental-cgn-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6264
RFC6265 HTTP State Management Mechanism A. Barth April 2011 ASCII HTML 37 Cookie Set-Cookie Secure HttpOnly

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]

draft-ietf-httpstate-cookie-23 RFC2965 PROPOSED STANDARD PROPOSED STANDARD IETF app httpstate http://www.rfc-editor.org/errata_search.php?rfc=6265 10.17487/RFC6265
RFC6266 Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) J. Reschke June 2011 ASCII HTML 14 filename attachment inline

RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]

draft-ietf-httpbis-content-disp-09 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=6266 10.17487/RFC6266
RFC6267 MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) V. Cakulev G. Sundaram June 2011 ASCII HTML 30 Identity based encryption authentication key agreement

This document describes a key management protocol variant for the Multimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizes Identity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cakulev-mikey-ibake-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6267
RFC6268 Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) J. Schaad S. Turner July 2011 ASCII HTML 33 ASN.1 Certficate Extensions HMAC

The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-additional-new-asn-08 RFC5911 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6268
RFC6269 Issues with IP Address Sharing M. Ford Editor M. Boucadair A. Durand P. Levis P. Roberts June 2011 ASCII HTML 29 IPv4 address exhaustion completion shared sharing issues

The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.

Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-intarea-shared-addressing-issues-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6269
RFC6270 The 'tn3270' URI Scheme M. Yevstifeyev June 2011 ASCII HTML 6 URI Telnet Telnet 3270 TN3270

This document is the specification of the 'tn3270' Uniform Resource Identifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270 Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned this URI scheme without defining its syntax and semantics. [STANDARDS-TRACK]

draft-yevstifeyev-tn3270-uri-18 RFC2355 RFC1738 RFC1041 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6270
RFC6271 Requirements for SIP-Based Session Peering J-F. Mule June 2011 ASCII HTML 23 IETF speermint guidelines requirements for session interconnects session peering SIP interconnects VoIP peering

This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-requirements-11 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6271
RFC6272 Internet Protocols for the Smart Grid F. Baker D. Meyer June 2011 ASCII HTML 66

This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-baker-ietf-core-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6272
RFC6273 The Secure Neighbor Discovery (SEND) Hash Threat Analysis A. Kukec S. Krishnan S. Jiang June 2011 ASCII HTML 7

This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-csi-hash-threat-12 INFORMATIONAL INFORMATIONAL IETF int csi 10.17487/RFC6273
RFC6274 Security Assessment of the Internet Protocol Version 4 F. Gont July 2011 ASCII HTML 75 vulnerabilities Denial of Service resiliency hardening information leakage

This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsec-ip-security-07 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=6274 10.17487/RFC6274
RFC6275 Mobility Support in IPv6 C. Perkins Editor D. Johnson J. Arkko July 2011 ASCII HTML 169 MIPv6 mobility IPv6 internet protocol nodes

This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. [STANDARDS-TRACK]

draft-ietf-mext-rfc3775bis-13 RFC3775 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6275 10.17487/RFC6275
RFC6276 DHCPv6 Prefix Delegation for Network Mobility (NEMO) R. Droms P. Thubert F. Dupont W. Haddad C. Bernardos July 2011 ASCII HTML 14 IPv6 mobile router home agent mobile network prefix

One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. [STANDARDS-TRACK]

draft-ietf-mext-nemo-pd-07 PROPOSED STANDARD PROPOSED STANDARD IETF int mext http://www.rfc-editor.org/errata_search.php?rfc=6276 10.17487/RFC6276
RFC6277 Online Certificate Status Protocol Algorithm Agility S. Santesson P. Hallam-Baker June 2011 ASCII HTML 11 ocsp

The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. [STANDARDS-TRACK]

draft-ietf-pkix-ocspagility-10 RFC6960 RFC2560 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6277 10.17487/RFC6277
RFC6278 Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax J. Herzog R. Khazan June 2011 ASCII HTML 16 set-key group-key

This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-herzog-static-ecdh-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6278
RFC6279 Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement M. Liebsch Editor S. Jeong Q. Wu June 2011 ASCII HTML 14 Local Routing Route Optimization Traffic Offload

Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netext-pmip6-lr-ps-06 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC6279
RFC6280 An Architecture for Location and Location Privacy in Internet Applications R. Barnes M. Lepinski A. Cooper J. Morris H. Tschofenig H. Schulzrinne July 2011 ASCII HTML 41 geolocation geopriv

Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. This memo documents an Internet Best Current Practice.

draft-ietf-geopriv-arch-03 RFC3693 RFC3694 BCP0160 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai geopriv 10.17487/RFC6280
RFC6281 Understanding Apple's Back to My Mac (BTMM) Service S. Cheshire Z. Zhu R. Wakikawa L. Zhang June 2011 ASCII HTML 16

This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zhu-mobileme-doc-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6281 10.17487/RFC6281
RFC6282 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks J. Hui Editor P. Thubert September 2011 ASCII HTML 24 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]

draft-ietf-6lowpan-hc-15 RFC4944 RFC8066 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan http://www.rfc-editor.org/errata_search.php?rfc=6282 10.17487/RFC6282
RFC6283 Extensible Markup Language Evidence Record Syntax (XMLERS) A. Jerman Blazic S. Saljic T. Gondrom July 2011 ASCII HTML 43 long term trust integrity long term integrity data preservation document preservation time-stamp time-stamping archive time stamp electronic archive electronic archiving trusted archiving long-term archive archive data evidence evidence record evidence record syntax hash tree ERS XML hash signature renewal algorithm cryptography

In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK]

draft-ietf-ltans-xmlers-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ltans 10.17487/RFC6283
RFC6284 Port Mapping between Unicast and Multicast RTP Sessions A. Begen D. Wing T. Van Caenegem June 2011 ASCII HTML 30 Port mapping port translation RTP multicast NAT

This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK]

draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6284
RFC6285 Unicast-Based Rapid Acquisition of Multicast RTP Sessions B. Ver Steeg A. Begen T. Van Caenegem Z. Vax June 2011 ASCII HTML 56 SSM multicast IPTV fast channel change

When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK]

draft-ietf-avt-rapid-acquisition-for-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avt 10.17487/RFC6285
RFC6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen J. Yuan June 2011 ASCII HTML 4

To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. [STANDARDS-TRACK]

draft-ietf-idr-bgp-identifier-14 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6286 10.17487/RFC6286
RFC6287 OCRA: OATH Challenge-Response Algorithm D. M'Raihi J. Rydell S. Bajaj S. Machani D. Naccache June 2011 ASCII HTML 38 HOTP TOTP One-Time Password Authentication Signature

This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication (OATH). The specified mechanisms leverage the HMAC-based One-Time Password (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mraihi-mutual-oath-hotp-variants-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6287 10.17487/RFC6287
RFC6288 URN Namespace for the Defence Geospatial Information Working Group (DGIWG) C. Reed August 2011 ASCII HTML 8 Namespace Identifier nid DGIWG Registry System drs

This document describes the Namespace Identifier (NID) for Uniform Resource Name (URN) Namespace resources published by the Defence Geospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.

Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-reed-urn-dgiwg-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6288
RFC6289 A Uniform Resource Name (URN) Namespace for CableLabs E. Cardona S. Channabasappa J-F. Mule June 2011 ASCII HTML 7 namespace identifier nid

This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cardona-cablelabs-urn-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6289
RFC6290 A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Y. Nir Editor D. Wierbowski F. Detienne P. Sethi June 2011 ASCII HTML 22 QCD

This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK]

draft-ietf-ipsecme-failure-detection-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6290 10.17487/RFC6290
RFC6291 Guidelines for the Use of the "OAM" Acronym in the IETF L. Andersson H. van Helvoort R. Bonica D. Romascanu S. Mansfield June 2011 ASCII HTML 9

At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again.

This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice.

draft-ietf-opsawg-mpls-tp-oam-def-10 BCP0161 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsawg 10.17487/RFC6291
RFC6292 Requirements for a Working Group Charter Tool P. Hoffman June 2011 ASCII HTML 11

The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-charter-tool-09 RFC6433 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6292 10.17487/RFC6292
RFC6293 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker P. Hoffman June 2011 ASCII HTML 17

The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-datatracker-community-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6293
RFC6294 Survey of Proposed Use Cases for the IPv6 Flow Label Q. Hu B. Carpenter June 2011 ASCII HTML 18 Quality of service QoS

The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hu-flow-label-cases-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6294
RFC6295 RTP Payload Format for MIDI J. Lazzaro J. Wawrzynek June 2011 ASCII HTML 171 asc content streaming DLS 2 General MIDI MIDI MIDI file MIDI file streaming MIDI light control MIDI rendering MIDI ringtone MIDI streaming MIDI sequencer MIDI time code MIDI timecode MIDI Manufacturers Association MMA mpeg4generic MPEG 4 MPEG 4 Structured Audio MPEG 4 Synthetic Coding MTC musical notes network musical performance recovery journal Show Control sonification ringtone rtpmidi RTP RTP MIDI SMPTE time code SMPTE timecode Standard MIDI Files XMF

This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695. [STANDARDS-TRACK]

draft-ietf-payload-rfc4695-bis-02 RFC4695 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6295
RFC6296 IPv6-to-IPv6 Network Prefix Translation M. Wasserman F. Baker June 2011 ASCII HTML 32

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. This document defines an Experimental Protocol for the Internet community.

draft-mrw-nat66-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6296 10.17487/RFC6296
RFC6297 A Survey of Lower-than-Best-Effort Transport Protocols M. Welzl D. Ros June 2011 ASCII HTML 18 Less-than-Best-Effort Congestion Control LEDBAT

This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best-effort service. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ledbat-survey-07 INFORMATIONAL INFORMATIONAL IETF tsv ledbat 10.17487/RFC6297
RFC6298 Computing TCP's Retransmission Timer V. Paxson M. Allman J. Chu M. Sargent June 2011 ASCII HTML 11 RTO

This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]

draft-paxson-tcpm-rfc2988bis-02 RFC2988 RFC1122 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6298
RFC6299 RFC6300 RFC6301 A Survey of Mobility Support in the Internet Z. Zhu R. Wakikawa L. Zhang July 2011 ASCII HTML 33

Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zhu-mobility-survey-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6301
RFC6302 Logging Recommendations for Internet-Facing Servers A. Durand I. Gashinsky D. Lee S. Sheppard June 2011 ASCII HTML 5 port logging

In the wake of IPv4 exhaustion and deployment of IP address sharing techniques, this document recommends that Internet-facing servers log port number and accurate timestamps in addition to the incoming IP address. This memo documents an Internet Best Current Practice.

draft-ietf-intarea-server-logging-recommendations-04 BCP0162 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6302
RFC6303 Locally Served DNS Zones M. Andrews July 2011 ASCII HTML 10 AS112 Reverse IN-ADDR.ARPA IP6.ARPA RFC1918

Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones that all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well-known zones with similar characteristics. This memo documents an Internet Best Current Practice.

draft-ietf-dnsop-default-local-zones-15 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC6303
RFC6304 AS112 Nameserver Operations J. Abley W. Maton July 2011 ASCII HTML 18 DNS RFC1918

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-as112-ops-09 RFC7534 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6304
RFC6305 I'm Being Attacked by PRISONER.IANA.ORG! J. Abley W. Maton July 2011 ASCII HTML 8

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.

Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.

This document provides background information and technical advice to those firewall operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-as112-under-attack-help-help-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6305
RFC6306 Hierarchical IPv4 Framework P. Frejborg July 2011 ASCII HTML 65 core address space area locators alocs edge address space endpoint locators elocs

This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique. In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.

This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing Domain Name System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. This document defines an Experimental Protocol for the Internet community.

draft-frejborg-hipv4-14 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6306
RFC6307 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks D. Black Editor L. Dunbar Editor M. Roth R. Solomon April 2012 ASCII HTML 21

A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. [STANDARDS-TRACK]

draft-ietf-pwe3-fc-encap-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6307
RFC6308 Overview of the Internet Multicast Addressing Architecture P. Savola June 2011 ASCII HTML 14 assignment allocation SSM ASM GLOP

The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mboned-addrarch-07 RFC2908 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6308
RFC6309 IANA Rules for MIKEY (Multimedia Internet KEYing) J. Arkko A. Keranen J. Mattsson August 2011 ASCII HTML 6 short-term key message long-term key message oma bac browser and content broadcast

This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK]

draft-arkko-mikey-iana-01 RFC4909 RFC3830 RFC4563 RFC5410 RFC6043 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6309
RFC6310 Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping M. Aissaoui P. Busschbach L. Martini M. Morrow T. Nadeau Y(J). Stein July 2011 ASCII HTML 40 interworking defect state defect indication pseudowire OAM

This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK]

draft-ietf-pwe3-oam-msg-map-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6310 10.17487/RFC6310
RFC6311 Protocol Support for High Availability of IKEv2/IPsec R. Singh Editor G. Kalyani Y. Nir Y. Sheffer D. Zhang July 2011 ASCII HTML 26 IPsec high availability load sharing clustering fail-over

The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However, there are many issues in IPsec HA clustering, and in particular in Internet Key Exchange Protocol version 2 (IKEv2) clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.

This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec replay counters. [STANDARDS-TRACK]

draft-ietf-ipsecme-ipsecha-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=6311 10.17487/RFC6311
RFC6312 Mobile Networks Considerations for IPv6 Deployment R. Koodli July 2011 ASCII HTML 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6-in-mobile-networks-05 RFC6342 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6312
RFC6313 Export of Structured Data in IP Flow Information Export (IPFIX) B. Claise G. Dhandapani P. Aitken S. Yates July 2011 ASCII HTML 71 ipfix information model

This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK]

draft-ietf-ipfix-structured-data-06 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6313 10.17487/RFC6313
RFC6314 NAT Traversal Practices for Client-Server SIP C. Boulton J. Rosenberg G. Camarillo F. Audet July 2011 ASCII HTML 60

Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-nat-scenarios-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6314
RFC6315 IANA Registration for Enumservice 'iax' E. Guy K. Darilion July 2011 ASCII HTML 6 ENUM E.164 VoIP Voice over IP

This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC 6117. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-enum-iax-10 INFORMATIONAL INFORMATIONAL IETF rai enum 10.17487/RFC6315
RFC6316 Sockets Application Program Interface (API) for Multihoming Shim M. Komu M. Bagnulo K. Slavov S. Sugimoto Editor July 2011 ASCII HTML 44 Shim6 HIP identifier/locator split

This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.

This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and the Host Identity Protocol (HIP). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-shim6-multihome-shim-api-17 INFORMATIONAL INFORMATIONAL IETF int shim6 10.17487/RFC6316
RFC6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP) M. Komu T. Henderson July 2011 ASCII HTML 18 host identity tag cryptographic identity cryptographic namespace sockets API Shim6 opportunistic mode resolver HIP wildcard address ORCHID source address selection HIT prefix locator handling

This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags (HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. This document defines an Experimental Protocol for the Internet community.

draft-ietf-hip-native-api-12 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC6317
RFC6318 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) R. Housley J. Solinas June 2011 ASCII HTML 15

This document specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 5751. This document obsoletes RFC 5008. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-housley-rfc5008bis-01 RFC5008 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6318
RFC6319 Issues Associated with Designating Additional Private IPv4 Address Space M. Azinger L. Vegoda July 2011 ASCII HTML 12 private network

When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.

While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-azinger-additional-private-ipv4-space-issues-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6319
RFC6320 Protocol for Access Node Control Mechanism in Broadband Networks S. Wadhwa J. Moisand T. Haag N. Voigt T. Taylor Editor October 2011 ASCII HTML 82 ancp

This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.

ANCP is based on the General Switch Management Protocol version 3 (GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. [STANDARDS-TRACK]

draft-ietf-ancp-protocol-17 RFC7256 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC6320
RFC6321 xCal: The XML Format for iCalendar C. Daboo M. Douglass S. Lees August 2011 ASCII HTML 54 extensible markup language

This specification defines "xCal", an XML format for iCalendar data. [STANDARDS-TRACK]

draft-daboo-et-al-icalendar-in-xml-11 RFC6868 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6321 10.17487/RFC6321
RFC6322 Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams P. Hoffman July 2011 ASCII HTML 11

This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent Submissions Editor. The states and annotations that are to be added to the Datatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventual RFC, and will continue through the lifetime of the Internet-Draft. The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of these Internet-Drafts and the streams from which they originate. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hoffman-alt-streams-tracker-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6322
RFC6323 Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) G. Renker G. Fairhurst July 2011 ASCII HTML 13 DCCP TFRC CCID-3 CCID-4

This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP.

The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.

It is integrated into the feature set of DCCP as an end-to-end negotiable extension. [STANDARDS-TRACK]

draft-ietf-dccp-tfrc-rtt-option-06 RFC4342 RFC5622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp 10.17487/RFC6323
RFC6324 Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations G. Nakibly F. Templin August 2011 ASCII HTML 19 Encapsulation ISATAP 6rd

This document is concerned with security vulnerabilities in IPv6-in- IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-tunnel-loops-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6324
RFC6325 Routing Bridges (RBridges): Base Protocol Specification R. Perlman D. Eastlake 3rd D. Dutt S. Gai A. Ghanwani July 2011 ASCII HTML 99 TRILL

Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. [STANDARDS-TRACK]

draft-ietf-trill-rbridge-protocol-16 RFC6327 RFC6439 RFC7172 RFC7177 RFC7357 RFC7179 RFC7180 RFC7455 RFC7780 RFC7783 RFC8139 RFC8249 RFC8361 RFC8377 PROPOSED STANDARD PROPOSED STANDARD IETF int trill http://www.rfc-editor.org/errata_search.php?rfc=6325 10.17487/RFC6325
RFC6326 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake A. Banerjee D. Dutt R. Perlman A. Ghanwani July 2011 ASCII HTML 25 TRILL RBridge IS-IS ISIS

The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. [STANDARDS-TRACK]

draft-ietf-isis-trill-05 RFC7176 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6326 10.17487/RFC6326
RFC6327 Routing Bridges (RBridges): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani D. Dutt V. Manral July 2011 ASCII HTML 26 RBridge TRILL Adjacency

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. [STANDARDS-TRACK]

draft-ietf-trill-adj-07 RFC7177 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6327
RFC6328 IANA Considerations for Network Layer Protocol Identifiers D. Eastlake 3rd July 2011 ASCII HTML 9 NLPID

Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA considerations. This memo documents an Internet Best Current Practice.

draft-eastlake-nlpid-iana-considerations-04 BCP0164 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6328
RFC6329 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging D. Fedyk Editor P. Ashwood-Smith Editor D. Allan A. Bragg P. Unbehagen April 2012 ASCII HTML 37 spb

802.1aq Shortest Path Bridging (SPB) has been standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. [STANDARDS-TRACK]

draft-ietf-isis-ieee-aq-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6329 10.17487/RFC6329
RFC6330 RaptorQ Forward Error Correction Scheme for Object Delivery M. Luby A. Shokrollahi M. Watson T. Stockhammer L. Minder August 2011 ASCII HTML 69 FEC code fountain code systematic code AL FEC code Sub-blocking FEC object delivery

This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.

RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.

The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]

draft-ietf-rmt-bb-fec-raptorq-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=6330 10.17487/RFC6330
RFC6331 Moving DIGEST-MD5 to Historic A. Melnikov July 2011 ASCII HTML 6 http hypertext transfer protocol security simple layer

This memo describes problems with the DIGEST-MD5 Simple Authentication and Security Layer (SASL) mechanism as specified in RFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry of SASL mechanisms and moves RFC 2831 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-kitten-digest-to-historic-04 RFC2831 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC6331
RFC6332 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) A. Begen E. Friedrich July 2011 ASCII HTML 16 SSM multicast IPTV RAMS rapid acquisition fast channel change

In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK]

draft-ietf-avtext-multicast-acq-rtcp-xr-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6332
RFC6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion A. Durand R. Droms J. Woodyatt Y. Lee August 2011 ASCII HTML 32 NAT

This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]

draft-ietf-softwire-dual-stack-lite-11 RFC7335 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6333 10.17487/RFC6333
RFC6334 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite D. Hankins T. Mrugalski August 2011 ASCII HTML 7 Softwire DS-Lite

This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]

draft-ietf-softwire-ds-lite-tunnel-option-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6334
RFC6335 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry M. Cotton L. Eggert J. Touch M. Westerlund S. Cheshire August 2011 ASCII HTML 33 IANA transport ports port numbers allocation assignment procedures

This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.

This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.

draft-ietf-tsvwg-iana-ports-10 RFC2780 RFC2782 RFC3828 RFC4340 RFC4960 RFC5595 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6335 10.17487/RFC6335
RFC6336 IANA Registry for Interactive Connectivity Establishment (ICE) Options M. Westerlund C. Perkins July 2011 ASCII HTML 5

It has been identified that "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. [STANDARDS-TRACK]

draft-ietf-mmusic-ice-options-registry-02 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6336
RFC6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model S. Okumura T. Sawada P. Kyzivat August 2011 ASCII HTML 33 answer offer SDP SIP

The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sipping-sip-offeranswer-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6337
RFC6338 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC) V. Giralt R. McDuff August 2011 ASCII HTML 11 TERENA tf-emc2

This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).

The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-giralt-schac-ns-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6338
RFC6339 Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) S. Josefsson L. Hornquist Astrand August 2011 ASCII HTML 8

This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK]

draft-josefsson-gss-capsulate-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6339
RFC6340 Textual Conventions for the Representation of Floating-Point Numbers R. Presuhn August 2011 ASCII HTML 7 Network Management IEEE 754 Floating-point MIB SMIv2 Textual Convention FLOAT-TC-MIB

This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. [STANDARDS-TRACK]

draft-ietf-opsawg-mib-floats-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC6340
RFC6341 Use Cases and Requirements for SIP-Based Media Recording (SIPREC) K. Rehor Editor L. Portman Editor A. Hutton R. Jain August 2011 ASCII HTML 16

Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.

Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-siprec-req-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC6341
RFC6342 Mobile Networks Considerations for IPv6 Deployment R. Koodli August 2011 ASCII HTML 17

Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6-in-mobile-networks-rfc6312bis RFC6312 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6342
RFC6343 Advisory Guidelines for 6to4 Deployment B. Carpenter August 2011 ASCII HTML 20 IPv6 relay

This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-6to4-advisory-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6343
RFC6344 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) G. Bernstein Editor D. Caviglia R. Rabbat H. van Helvoort August 2011 ASCII HTML 21

This document describes requirements for, and the use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link Capacity Adjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-vcat-lcas-13 RFC4606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6344
RFC6345 Protocol for Carrying Authentication for Network Access (PANA) Relay Element P. Duffy S. Chakrabarti R. Cragie Y. Ohba Editor A. Yegin August 2011 ASCII HTML 12 EAP ZigBee

This document specifies Protocol for carrying Authentication for Network Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the two nodes cannot reach each other by means of regular IP routing. [STANDARDS-TRACK]

draft-ohba-pana-relay-03 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6345 10.17487/RFC6345
RFC6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage R. Bush Editor August 2011 ASCII HTML 38

We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.

This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. This document defines an Experimental Protocol for the Internet community.

draft-ymbk-aplusp-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6346
RFC6347 Datagram Transport Layer Security Version 1.2 E. Rescorla N. Modadugu January 2012 ASCII HTML 32 dtls dtls protocol

This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]

draft-ietf-tls-rfc4347-bis-06 RFC4347 RFC7507 RFC7905 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6347 10.17487/RFC6347
RFC6348 Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol JL. Le Roux Editor T. Morin Editor September 2011 ASCII HTML 20 MPLS LDP multipoint P2MP multicast

This document lists a set of functional requirements that served as input to the design of Label Distribution Protocol (LDP) extensions for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multiprotocol Label Switching (MPLS) infrastructure.

This work was overtaken by the protocol solution developed by the MPLS working group, but that solution did not closely follow the requirements documented here. This document is published as a historic record of the ideas and requirements that shaped the protocol work. This document defines a Historic Document for the Internet community.

draft-ietf-mpls-mp-ldp-reqs-08 HISTORIC HISTORIC IETF rtg mpls 10.17487/RFC6348
RFC6349 Framework for TCP Throughput Testing B. Constantine G. Forget R. Geib R. Schrage August 2011 ASCII HTML 27 metric TCP testing

This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCP Throughput. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-tcp-throughput-tm-13 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6349
RFC6350 vCard Format Specification S. Perreault August 2011 ASCII HTML 74 vCard

This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]

draft-ietf-vcarddav-vcardrev-22 RFC2425 RFC2426 RFC4770 RFC2739 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6350 10.17487/RFC6350
RFC6351 xCard: vCard XML Representation S. Perreault August 2011 ASCII HTML 22 vCard

This document defines the XML schema of the vCard data format. [STANDARDS-TRACK]

draft-ietf-vcarddav-vcardxml-11 RFC6868 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6351 10.17487/RFC6351
RFC6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) C. Daboo August 2011 ASCII HTML 48 address address book contact

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK]

draft-ietf-vcarddav-carddav-10 RFC6764 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6352 10.17487/RFC6352
RFC6353 Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) W. Hardaker July 2011 ASCII HTML 65 dtls datagram transport layer security tls transport model tlstm SNMP-TLS-TM-MIB

This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way.

This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.

This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK]

draft-ietf-isms-dtls-tm-rfc5953bis-00 RFC5953 STD0078 INTERNET STANDARD DRAFT STANDARD IETF sec isms 10.17487/RFC6353
RFC6354 Forward-Shifted RTP Redundancy Payload Support Q. Xie August 2011 ASCII HTML 13

This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). [STANDARDS-TRACK]

draft-ietf-avt-forward-shifted-red-08 RFC2198 RFC4102 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6354
RFC6355 Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) T. Narten J. Johnson August 2011 ASCII HTML 5 universally unique identifier

This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already-standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. [STANDARDS-TRACK]

draft-ietf-dhc-duid-uuid-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6355
RFC6356 Coupled Congestion Control for Multipath Transport Protocols C. Raiciu M. Handley D. Wischik October 2011 ASCII HTML 12 multipath tcp congestion control

Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.

New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.

This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mptcp-congestion-07 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp 10.17487/RFC6356
RFC6357 Design Considerations for Session Initiation Protocol (SIP) Overload Control V. Hilt E. Noel C. Shen A. Abdelal August 2011 ASCII HTML 25 Session Initiation Protocol Overload Control Congestion Collapse

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-soc-overload-design-08 INFORMATIONAL INFORMATIONAL IETF rai soc 10.17487/RFC6357
RFC6358 Additional Master Secret Inputs for TLS P. Hoffman January 2012 ASCII HTML 4 tls dtls datagram tls

This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). This document defines an Experimental Protocol for the Internet community.

draft-hoffman-tls-master-secret-input-03 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6358
RFC6359 Datatracker Extensions to Include IANA and RFC Editor Processing Information S. Ginoza M. Cotton A. Morris September 2011 ASCII HTML 18 id-tracker backend extensions

This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC. Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-datatracker-iana-rfced-extns-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6359
RFC6360 Conclusion of FYI RFC Sub-Series R. Housley August 2011 ASCII HTML 3

This document concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iesg-rfc1150bis-01 RFC1150 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6360
RFC6361 PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol J. Carlson D. Eastlake 3rd August 2011 ASCII HTML 8 point-to-point protocol rbridges routing bridges

The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK]

draft-ietf-pppext-trill-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6361
RFC6362 Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT) K. Meadors Editor August 2011 ASCII HTML 8 EDIINT AS2 Multiple Attachments

The Electronic Data Interchange - Internet Integration (EDIINT) AS1, AS2, and AS3 messages were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-meadors-multiple-attachments-ediint-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6362
RFC6363 Forward Error Correction (FEC) Framework M. Watson A. Begen V. Roca October 2011 ASCII HTML 42 Reliable streaming content delivery FEC schemes

This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. [STANDARDS-TRACK]

draft-ietf-fecframe-framework-15 RFC8680 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6363
RFC6364 Session Description Protocol Elements for the Forward Error Correction (FEC) Framework A. Begen October 2011 ASCII HTML 18 FEC configuration FEC topologies

This document specifies the use of the Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. [STANDARDS-TRACK]

draft-ietf-fecframe-sdp-elements-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6364
RFC6365 Terminology Used in Internationalization in the IETF P. Hoffman J. Klensin September 2011 ASCII HTML 47 i18n vocabulary terms

This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice.

draft-ietf-appsawg-rfc3536bis-06 RFC3536 BCP0166 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6365 10.17487/RFC6365
RFC6366 Requirements for an Internet Audio Codec J. Valin K. Vos August 2011 ASCII HTML 17

This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-codec-requirements-05 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6366
RFC6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) S. Kanno M. Kanda September 2011 ASCII HTML 8 TLS GCM Eliptic Curve Encryption Block Cipher psk

This document specifies forty-two cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-kanno-tls-camellia-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6367 10.17487/RFC6367
RFC6368 Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) P. Marques R. Raszuk K. Patel K. Kumaki T. Yamagata September 2011 ASCII HTML 14 l3vpn iBGP loops as-override attribute set attr_set

This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]

draft-ietf-l3vpn-ibgp-08 RFC7606 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6368 10.17487/RFC6368
RFC6369 Forwarding and Control Element Separation (ForCES) Implementation Experience E. Haleplidis O. Koufopavlou S. Denazis September 2011 ASCII HTML 18

The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-haleplidis-forces-implementation-experience-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6369
RFC6370 MPLS Transport Profile (MPLS-TP) Identifiers M. Bocci G. Swallow E. Gray September 2011 ASCII HTML 17

This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]

draft-ietf-mpls-tp-identifiers-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6370
RFC6371 Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks I. Busi Editor D. Allan Editor September 2011 ASCII HTML 62

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.

This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-oam-framework-11 RFC6435 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6371 10.17487/RFC6371
RFC6372 MPLS Transport Profile (MPLS-TP) Survivability Framework N. Sprecher Editor A. Farrel Editor September 2011 ASCII HTML 56 Protection Restoration Recovery

Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources. Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.

The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.

This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance (OAM) functions. This document describes mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-survive-fwk-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6372
RFC6373 MPLS Transport Profile (MPLS-TP) Control Plane Framework L. Andersson Editor L. Berger Editor L. Fang Editor N. Bitar Editor E. Gray Editor September 2011 ASCII HTML 57

The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management-plane functions are out of scope of this document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-mpls-tp-cp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6373
RFC6374 Packet Loss and Delay Measurement for MPLS Networks D. Frost S. Bryant September 2011 ASCII HTML 52

Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK]

draft-ietf-mpls-loss-delay-04 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6374 10.17487/RFC6374
RFC6375 A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks D. Frost Editor S. Bryant Editor September 2011 ASCII HTML 5

Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.

This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-loss-delay-profile-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6375
RFC6376 DomainKeys Identified Mail (DKIM) Signatures D. Crocker Editor T. Hansen Editor M. Kucherawy Editor September 2011 ASCII HTML 76 email architecture abuse verification anti-abuse identity integrity responsible author sender originator email filtering anti-phishing mail signature

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]

draft-ietf-dkim-rfc4871bis-15 RFC4871 RFC5672 RFC8301 RFC8463 RFC8553 RFC8616 STD0076 INTERNET STANDARD DRAFT STANDARD IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6376 10.17487/RFC6376
RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists M. Kucherawy September 2011 ASCII HTML 26 email architecture verification anti-abuse identity integrity responsible author sender originator

DomainKeys Identified Mail (DKIM) allows an ADministrative Management Domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). This memo documents an Internet Best Current Practice.

draft-ietf-dkim-mailinglists-12 BCP0167 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec dkim http://www.rfc-editor.org/errata_search.php?rfc=6377 10.17487/RFC6377
RFC6378 MPLS Transport Profile (MPLS-TP) Linear Protection Y. Weingarten Editor S. Bryant E. Osborne N. Sprecher A. Fulignoli Editor October 2011 ASCII HTML 45 PSC Protection State Coordination Protocol,

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]

draft-ietf-mpls-tp-linear-protection-09 RFC7214 RFC7271 RFC7324 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6378
RFC6379 Suite B Cryptographic Suites for IPsec L. Law J. Solinas October 2011 ASCII HTML 7 UI suites user interface suites elliptic curve ike

This document proposes four cryptographic user interface suites ("UI suites") for IP Security (IPsec), similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-law-rfc4869bis-01 RFC4869 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6379
RFC6380 Suite B Profile for Internet Protocol Security (IPsec) K. Burgin M. Peck October 2011 ASCII HTML 10 cryptographic algorithm policy security application suite b cryptography

The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec).

Since many of the Suite B algorithms are used in other environments, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant detail repeated to aid developers who choose to support Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-burgin-ipsec-suiteb-profile-02 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6380
RFC6381 The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types R. Gellens D. Singer P. Frojdh August 2011 ASCII HTML 19 codec container audio video 3gpp 3gpp2

Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered.

This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.

By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.).

Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

draft-gellens-mime-bucket-bis-09 RFC4281 RFC3839 RFC4393 RFC4337 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6381 10.17487/RFC6381
RFC6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services D. McPherson R. Donnelly F. Scalzo October 2011 ASCII HTML 10 BGP SIDR RPKI security routing operations root TLD DNS DDOS peering RIR IRR MITM

This document makes recommendations regarding the use of unique origin autonomous system numbers (ASNs) per node for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may employ this new discriminator in whatever manner best accommodates their operating environment. This memo documents an Internet Best Current Practice.

draft-ietf-grow-unique-origin-as-01 BCP0169 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6382
RFC6383 Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE K. Shiomoto A. Farrel September 2011 ASCII HTML 11 RSVP-TE GMPLS MPLS-TE cross-connect data plane

The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.

End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.

This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-shiomoto-ccamp-switch-programming-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6383
RFC6384 An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation I. van Beijnum October 2011 ASCII HTML 16 FTP SIIT NAT64

The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers, FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.

FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. [STANDARDS-TRACK]

draft-ietf-behave-ftp64-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave 10.17487/RFC6384
RFC6385 General Area Review Team (Gen-ART) Experiences M. Barnes A. Doria H. Alvestrand B. Carpenter October 2011 ASCII HTML 23 genart

The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-doria-genart-experience-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6385
RFC6386 VP8 Data Format and Decoding Guide J. Bankoski J. Koleszar L. Quillio J. Salonen P. Wilkins Y. Xu November 2011 ASCII HTML 304

This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-bankoski-vp8-bitstream-06 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6386 10.17487/RFC6386
RFC6387 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) A. Takacs L. Berger D. Caviglia D. Fedyk J. Meuric September 2011 ASCII HTML 11 rsvp resource reservation protocol

This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. [STANDARDS-TRACK]

draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03 RFC5467 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6387
RFC6388 Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor I. Minei Editor K. Kompella B. Thomas November 2011 ASCII HTML 39

This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-p2mp-15 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6388
RFC6389 MPLS Upstream Label Assignment for LDP R. Aggarwal JL. Le Roux November 2011 ASCII HTML 13

This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label Switching Router (LSR) traffic replication on a LAN for LDP point-to-multipoint (P2MP) Label Switched Paths (LSPs). [STANDARDS-TRACK]

draft-ietf-mpls-ldp-upstream-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6389
RFC6390 Guidelines for Considering New Performance Metric Development A. Clark B. Claise October 2011 ASCII HTML 23

This document describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. These metrics can be used to characterize traffic on live networks and services. This memo documents an Internet Best Current Practice.

draft-ietf-pmol-metrics-framework-12 BCP0170 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops pmol 10.17487/RFC6390
RFC6391 Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network S. Bryant Editor C. Filsfils U. Drafz V. Kompella J. Regan S. Amante November 2011 ASCII HTML 19

Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.

This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK]

draft-ietf-pwe3-fat-pw-07 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6391
RFC6392 A Survey of In-Network Storage Systems R. Alimi Editor A. Rahman Editor Y. Yang Editor October 2011 ASCII HTML 44 P2P DECADE DECoupled Application Data Enroute

This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupled Application Data Enroute) architecture. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-decade-survey-06 INFORMATIONAL INFORMATIONAL IETF tsv decade http://www.rfc-editor.org/errata_search.php?rfc=6392 10.17487/RFC6392
RFC6393 Moving RFC 4693 to Historic M. Yevstifeyev September 2011 ASCII HTML 3 ION historic

This document moves RFC 4693 to Historic status. It also obsoletes RFC 4693. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-yevstifeyev-ion-report-07 RFC4693 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6393
RFC6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) R. Barnes October 2011 ASCII HTML 12 TLS PKIX

Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name. Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. [STANDARDS-TRACK]

draft-ietf-dane-use-cases-05 INFORMATIONAL INFORMATIONAL IETF sec dane 10.17487/RFC6394
RFC6395 An Interface Identifier (ID) Hello Option for PIM S. Gulrajani S. Venaas October 2011 ASCII HTML 6

This document defines a new PIM Hello option to advertise an Interface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. [STANDARDS-TRACK]

draft-ietf-pim-hello-intid-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6395
RFC6396 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format L. Blunk M. Karir C. Labovitz October 2011 ASCII HTML 33

This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. [STANDARDS-TRACK]

draft-ietf-grow-mrt-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=6396 10.17487/RFC6396
RFC6397 Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions T. Manderson October 2011 ASCII HTML 8 GPS Coordinates Terrestrial Coordinates BGP Speaker BGP Peer BGP Latitude BGP Longitude

This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK]

draft-ietf-grow-geomrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC6397
RFC6398 IP Router Alert Considerations and Usage F. Le Faucheur Editor October 2011 ASCII HTML 19

The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.

draft-ietf-intarea-router-alert-considerations-10 RFC2113 RFC2711 BCP0168 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6398
RFC6399 RFC6400 RFC6401 RSVP Extensions for Admission Priority F. Le Faucheur J. Polk K. Carlberg October 2011 ASCII HTML 32

Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol (RSVP) that can be used to support such an admission priority capability at the network layer.

Based on current security concerns, these extensions are intended for use in a single administrative domain. [STANDARDS-TRACK]

draft-ietf-tsvwg-emergency-rsvp-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6401
RFC6402 Certificate Management over CMS (CMC) Updates J. Schaad November 2011 ASCII HTML 37 cyrptographic message syntax

This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.

The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]

draft-ietf-pkix-rfc5272-bis-08 RFC5272 RFC5273 RFC5274 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6402 10.17487/RFC6402
RFC6403 Suite B Profile of Certificate Management over CMS L. Zieglar S. Turner M. Peck November 2011 ASCII HTML 16 cmc suite b x.509 public key certificates

The United States government has published guidelines for "NSA Suite\0B Cryptography", which defines cryptographic algorithm policy for national security applications. This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing Suite B X.509 public key certificates. This profile is a refinement of RFCs 5272, 5273, and 5274. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-turner-suiteb-cmc-03 HISTORIC INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6403
RFC6404 Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures J. Seedorf S. Niccolini E. Chen H. Scholz November 2011 ASCII HTML 22 VoIP Security Threats multimedia Threat countermeasures SIP Interconnect VoIP peering Fraud prevention Network protection SIP RTP RTCP control plane user plane

The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. Each SSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-voipthreats-09 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6404
RFC6405 Voice over IP (VoIP) SIP Peering Use Cases A. Uzelac Editor Y. Lee Editor November 2011 ASCII HTML 23 VoIP SIP Peering

This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-voip-consolidated-usecases-18 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6405
RFC6406 Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture D. Malas Editor J. Livingood Editor November 2011 ASCII HTML 16

This document defines a peering architecture for the Session Initiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-speermint-architecture-19 INFORMATIONAL INFORMATIONAL IETF rai speermint 10.17487/RFC6406
RFC6407 The Group Domain of Interpretation B. Weis S. Rowles T. Hardjono October 2011 ASCII HTML 64

This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK]

draft-ietf-msec-gdoi-update-11 RFC3547 PROPOSED STANDARD PROPOSED STANDARD IETF sec msec http://www.rfc-editor.org/errata_search.php?rfc=6407 10.17487/RFC6407
RFC6408 Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage M. Jones J. Korhonen L. Morand November 2011 ASCII HTML 14 Services Field Peer Discovery

The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. [STANDARDS-TRACK]

draft-ietf-dime-extended-naptr-09 RFC3588 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6408
RFC6409 Message Submission for Mail R. Gellens J. Klensin November 2011 ASCII HTML 20 Text Internationalization ASCII Unicode UTF-8

This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.

Message relay is unaffected, and continues to use SMTP over port 25.

When conforming to this document, message submission uses the protocol specified here, normally over port 587.

This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK]

draft-ietf-yam-rfc4409bis-03 RFC4409 RFC8314 STD0072 INTERNET STANDARD INTERNET STANDARD IETF app yam http://www.rfc-editor.org/errata_search.php?rfc=6409 10.17487/RFC6409
RFC6410 Reducing the Standards Track to Two Maturity Levels R. Housley D. Crocker E. Burger October 2011 ASCII HTML 6

This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

draft-housley-two-maturity-levels-09 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6410 10.17487/RFC6410
RFC6411 Applicability of Keying Methods for RSVP Security M. Behringer F. Le Faucheur B. Weis October 2011 ASCII HTML 19 RSVP authentication RSVP integrity Resource reservation protocol GDOI Group domain of interpretation

The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tsvwg-rsvp-security-groupkeying-11 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC6411
RFC6412 Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII HTML 29

This document describes the terminology for benchmarking link-state Interior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-igp-dataplane-conv-term-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6412
RFC6413 Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence S. Poretsky B. Imhoff K. Michielsen November 2011 ASCII HTML 42 Interior Gateway Protocol

This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS and OSPF. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-igp-dataplane-conv-meth-23 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6413
RFC6414 Benchmarking Terminology for Protection Performance S. Poretsky R. Papneja J. Karthik S. Vapiwala November 2011 ASCII HTML 33

This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-protection-term-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6414
RFC6415 Web Host Metadata E. Hammer-Lahav Editor B. Cook October 2011 ASCII HTML 16

This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. [STANDARDS-TRACK]

draft-hammer-hostmeta-17 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6415 10.17487/RFC6415
RFC6416 RTP Payload Format for MPEG-4 Audio/Visual Streams M. Schmidt F. de Bont S. Doehla J. Kim October 2011 ASCII HTML 35 RFC3016 RTP MPEG-4 Audio Visual Video AAC HE AAC HE AAC v2 MPEG Surround

This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.

For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK]

draft-ietf-payload-rfc3016bis-03 RFC3016 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6416
RFC6417 How to Contribute Research Results to Internet Standardization P. Eardley L. Eggert M. Bagnulo R. Winter November 2011 ASCII HTML 14

The development of new technology is driven by scientific research. The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of the Internet originate in the related academic research communities. Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.

For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-weeb-research-to-internet-stds-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6417
RFC6418 Multiple Interfaces and Provisioning Domains Problem Statement M. Blanchet P. Seite November 2011 ASCII HTML 22 multi-homing MIF DNS DHCP

This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mif-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=6418 10.17487/RFC6418
RFC6419 Current Practices for Multiple-Interface Hosts M. Wasserman P. Seite November 2011 ASCII HTML 21 current practices multi-homing MIF

An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mif-current-practices-12 INFORMATIONAL INFORMATIONAL IETF int mif 10.17487/RFC6419
RFC6420 PIM Multi-Topology ID (MT-ID) Join Attribute Y. Cai H. Ou November 2011 ASCII HTML 13

This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. [STANDARDS-TRACK]

draft-ietf-pim-mtid-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6420
RFC6421 Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) D. Nelson Editor November 2011 ASCII HTML 12

This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-radext-crypto-agility-requirements-07 INFORMATIONAL INFORMATIONAL IETF ops radext 10.17487/RFC6421
RFC6422 Relay-Supplied DHCP Options T. Lemon Q. Wu December 2011 ASCII HTML 8 DHCPv6 Relay DHCPv6 option

DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.

This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-relay-supplied-options-09 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6422
RFC6423 Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) H. Li L. Martini J. He F. Huang November 2011 ASCII HTML 5

This document describes the requirements for using the Generic Associated Channel Label (GAL) in pseudowires (PWs) in MPLS Transport Profile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. [STANDARDS-TRACK]

draft-ietf-pwe3-mpls-tp-gal-in-pw-01 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6423
RFC6424 Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels N. Bahadur K. Kompella G. Swallow November 2011 ASCII HTML 23 MPLS OAM lsp ping LSP-Ping

This document describes methods for performing LSP ping (specified in RFC 4379) traceroute over MPLS tunnels and for traceroute of stitched MPLS Label Switched Paths (LSPs). The techniques outlined in RFC 4379 are insufficient to perform traceroute Forwarding Equivalency Class (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a new TLV that, along with other procedures outlined in this document, can be used to trace such LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-lsp-ping-enhanced-dsmap-11 RFC8029 RFC4379 RFC7537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6424
RFC6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping S. Saxena Editor G. Swallow Z. Ali A. Farrel S. Yasukawa T. Nadeau November 2011 ASCII HTML 28 p2mp

Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.

The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".

The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.

This document updates RFC 4379. [STANDARDS-TRACK]

draft-ietf-mpls-p2mp-lsp-ping-18 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6425 10.17487/RFC6425
RFC6426 MPLS On-Demand Connectivity Verification and Route Tracing E. Gray N. Bahadur S. Boutros R. Aggarwal November 2011 ASCII HTML 22 lsp ping mpls tp mpls-tp

Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLS Transport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions in MPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. [STANDARDS-TRACK]

draft-ietf-mpls-tp-on-demand-cv-07 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6426 10.17487/RFC6426
RFC6427 MPLS Fault Management Operations, Administration, and Maintenance (OAM) G. Swallow Editor A. Fulignoli Editor M. Vigoureux Editor S. Boutros D. Ward November 2011 ASCII HTML 17 mpls-oam

This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. [STANDARDS-TRACK]

draft-ietf-mpls-tp-fault-07 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6427
RFC6428 Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile D. Allan Editor G. Swallow Editor J. Drake Editor November 2011 ASCII HTML 21 mpls-tp oam Operations Administration and Maintenance bfd bidirectional forwarding dectection

Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).

Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section.

This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK]

draft-ietf-mpls-tp-cc-cv-rdi-06 RFC7214 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6428 10.17487/RFC6428
RFC6429 TCP Sender Clarification for Persist Condition M. Bashyam M. Jethanandani A. Ramaiah December 2011 ASCII HTML 7 zero window probe denial of service (DoS) security vulnerability

This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tcpm-persist-07 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6429
RFC6430 Email Feedback Report Type Value: not-spam K. Li B. Leiba November 2011 ASCII HTML 7 arf abuse reporting format

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK]

draft-ietf-marf-not-spam-feedback-03 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6430
RFC6431 Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) M. Boucadair P. Levis G. Bajko T. Savolainen T. Tsou November 2011 ASCII HTML 16 IPv4 Address Exhaustion IPv4 service continuity IPv6 A+P

This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-boucadair-pppext-portrange-option-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6431
RFC6432 Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses R. Jesske L. Liess November 2011 ASCII HTML 4 cause code

Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. [STANDARDS-TRACK]

draft-jesske-dispatch-update3326-reason-responses-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6432
RFC6433 Requirements for a Working Group Milestones Tool P. Hoffman November 2011 ASCII HTML 7 working group charter charter

The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document updates RFC 6292. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-genarea-milestones-tool-06 RFC6292 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6433
RFC6434 IPv6 Node Requirements E. Jankiewicz J. Loughney T. Narten December 2011 ASCII HTML 30 Internet Protocol Version 6 Internet Protocol IP

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6man-node-req-bis-11 RFC4294 RFC8504 INFORMATIONAL INFORMATIONAL IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6434 10.17487/RFC6434
RFC6435 MPLS Transport Profile Lock Instruct and Loopback Functions S. Boutros Editor S. Sivabalan Editor R. Aggarwal Editor M. Vigoureux Editor X. Dai Editor November 2011 ASCII HTML 12 oam operations administration and maintenance

Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.

This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.

This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. [STANDARDS-TRACK]

draft-ietf-mpls-tp-li-lb-08 RFC6371 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6435 10.17487/RFC6435
RFC6436 Rationale for Update to the IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang November 2011 ASCII HTML 13 ECMP LAG

Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6man-flow-update-07 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6436
RFC6437 IPv6 Flow Label Specification S. Amante B. Carpenter S. Jiang J. Rajahalme November 2011 ASCII HTML 15

This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document.

The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK]

draft-ietf-6man-flow-3697bis-07 RFC3697 RFC2205 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6437
RFC6438 Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels B. Carpenter S. Amante November 2011 ASCII HTML 9 ECMP LAG

The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. [STANDARDS-TRACK]

draft-ietf-6man-flow-ecmp-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6438
RFC6439 Routing Bridges (RBridges): Appointed Forwarders R. Perlman D. Eastlake Y. Li A. Banerjee F. Hu November 2011 ASCII HTML 15 trill TRansparent Interconnection of Lots of Links

The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).

TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. [STANDARDS-TRACK]

draft-ietf-trill-rbridge-af-05 RFC8139 RFC6325 RFC7180 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6439
RFC6440 The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option G. Zorn Q. Wu Y. Wang December 2011 ASCII HTML 6 re-authentication handover LDN Discovery

In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.

This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. [STANDARDS-TRACK]

draft-ietf-hokey-ldn-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6440
RFC6441 Time to Remove Filters for Previously Unallocated IPv4 /8s L. Vegoda November 2011 ASCII HTML 5 bogons IPv4 martians filters

It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile, and expensive. Network administrators are advised to remove filters based on the registration status of the address space.

This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. This memo documents an Internet Best Current Practice.

draft-ietf-grow-no-more-unallocated-slash8s-04 BCP0171 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow 10.17487/RFC6441
RFC6442 Location Conveyance for the Session Initiation Protocol J. Polk B. Rosen J. Peterson December 2011 ASCII HTML 35 sip geographic location location target

This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK]

draft-ietf-sipcore-location-conveyance-09 RFC8262 RFC8787 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6442 10.17487/RFC6442
RFC6443 Framework for Emergency Calling Using Internet Multimedia B. Rosen H. Schulzrinne J. Polk A. Newton December 2011 ASCII HTML 38

The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ecrit-framework-13 RFC7852 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6443
RFC6444 Location Hiding: Problem Statement and Requirements H. Schulzrinne L. Liess H. Tschofenig B. Stark A. Kuett January 2012 ASCII HTML 9 emergency call privacy PSAP Location by Reference

The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.

This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ecrit-location-hiding-req-04 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC6444
RFC6445 Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute T. Nadeau Editor A. Koushik Editor R. Cetin Editor November 2011 ASCII HTML 53 mib frr MPLS-FRR-GENERAL-STD-MIB MPLS-FRR-ONE2ONE-STD-MIB MPLS-FRR-FACILITY-STD-MIB

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. [STANDARDS-TRACK]

draft-ietf-mpls-fastreroute-mib-21 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6445
RFC6446 Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control A. Niemi K. Kiss S. Loreto January 2012 ASCII HTML 25 SIP events rate control

This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. [STANDARDS-TRACK]

draft-ietf-sipcore-event-rate-control-09 RFC3265 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6446
RFC6447 Filtering Location Notifications in the Session Initiation Protocol (SIP) R. Mahy B. Rosen H. Tschofenig January 2012 ASCII HTML 19 geopriv location

This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). [STANDARDS-TRACK]

draft-ietf-geopriv-loc-filters-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6447
RFC6448 The Unencrypted Form of Kerberos 5 KRB-CRED Message R. Yount November 2011 ASCII HTML 4 credential

The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. [STANDARDS-TRACK]

draft-ietf-krb-wg-clear-text-cred-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6448
RFC6449 Complaint Feedback Loop Operational Recommendations J. Falk Editor November 2011 ASCII HTML 31 MAAWG ARF MARF feedback loop spam reporting

Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.

This document is the result of cooperative efforts within the Messaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-jdfalk-maawg-cfblbcp-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6449
RFC6450 Multicast Ping Protocol S. Venaas December 2011 ASCII HTML 24 ssm asm ssmping asmping

The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". [STANDARDS-TRACK]

draft-ietf-mboned-ssmping-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC6450
RFC6451 Location-to-Service Translation (LoST) Protocol Extensions A. Forte H. Schulzrinne December 2011 ASCII HTML 23 location-based services location GPS point of interest

An important class of location-based services answers the question, "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by". This document defines an Experimental Protocol for the Internet community.

draft-forte-lost-extensions-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6451
RFC6452 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 P. Faltstrom Editor P. Hoffman Editor November 2011 ASCII HTML 4 DNS IDN

This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. [STANDARDS-TRACK]

draft-faltstrom-5892bis-05 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6452
RFC6453 A URN Namespace for the Open Grid Forum (OGF) F. Dijkstra R. Hughes-Jones December 2011 ASCII HTML 9 identifier

This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-dijkstra-urn-ogf-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6453
RFC6454 The Web Origin Concept A. Barth December 2011 ASCII HTML 20 same-origin policy security cross-origin

This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]

draft-ietf-websec-origin-06 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6454 10.17487/RFC6454
RFC6455 The WebSocket Protocol I. Fette A. Melnikov December 2011 ASCII HTML 71 HyBi Working Group HYBI websocket

The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]

draft-ietf-hybi-thewebsocketprotocol-17 RFC7936 RFC8307 RFC8441 PROPOSED STANDARD PROPOSED STANDARD IETF app hybi http://www.rfc-editor.org/errata_search.php?rfc=6455 10.17487/RFC6455
RFC6456 Multi-Segment Pseudowires in Passive Optical Networks H. Li R. Zheng A. Farrel November 2011 ASCII HTML 12 MPLS PSN PON G-PON XG-PON OMCI

This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising a Passive Optical Network (PON) and an MPLS Packet Switched Network (PSN).

PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) Terminating Provider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.

This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or 10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network Termination Management and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.

This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-li-pwe3-ms-pw-pon-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6456
RFC6457 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering T. Takeda Editor A. Farrel December 2011 ASCII HTML 12 PCEP inter-layer traffic engineering MPLS GMPLS VNT

The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS).

MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.

Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery".

This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-inter-layer-req-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6457
RFC6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) R. Stewart M. Tuexen K. Poon P. Lei V. Yasevich December 2011 ASCII HTML 115

This document describes a mapping of the Stream Control Transmission Protocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tsvwg-sctpsocket-32 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=6458 10.17487/RFC6458
RFC6459 IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) J. Korhonen Editor J. Soininen B. Patil T. Savolainen G. Bajko K. Iisakkila January 2012 ASCII HTML 36 Transition Migration

The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rd Generation Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-3gpp-eps-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6459
RFC6460 Suite B Profile for Transport Layer Security (TLS) M. Salter R. Housley January 2012 ASCII HTML 14 cryptographic algorithm policy

The United States government has published guidelines for "NSA Suite B Cryptography" that define cryptographic algorithm policy for national security applications. This document defines a profile of Transport Layer Security (TLS) version 1.2 that is fully compliant with Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-salter-rfc5430bis-01 RFC5430 HISTORIC INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6460 10.17487/RFC6460
RFC6461 Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements S. Channabasappa Editor January 2012 ASCII HTML 15 registry registry provisioning registrar destination group route group

This document captures the use cases and associated requirements for interfaces that provision session establishment data into Session Initiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry". This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-drinks-usecases-requirements-06 INFORMATIONAL INFORMATIONAL IETF rai drinks 10.17487/RFC6461
RFC6462 Report from the Internet Privacy Workshop A. Cooper January 2012 ASCII HTML 23

On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-privacy-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6462
RFC6463 Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 J. Korhonen Editor S. Gundavelli H. Yokota X. Cui February 2012 ASCII HTML 22

This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. [STANDARDS-TRACK]

draft-ietf-netext-redirect-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6463
RFC6464 A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication J. Lennox Editor E. Ivov E. Marocco December 2011 ASCII HTML 9 ssrc-audio-level ssrc speech sound energy conference bridge

This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK]

draft-ietf-avtext-client-to-mixer-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6464
RFC6465 A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication E. Ivov Editor E. Marocco Editor J. Lennox December 2011 ASCII HTML 15 csrc-audio-level csrc speech sound energy conference bridge

This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]

draft-ietf-avtext-mixer-to-client-audio-level-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC6465
RFC6466 IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) G. Salgueiro December 2011 ASCII HTML 6 t.38 media

This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the Session Description Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. [STANDARDS-TRACK]

draft-salgueiro-mmusic-image-iana-registration-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6466
RFC6467 Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) T. Kivinen December 2011 ASCII HTML 10 IPsec IKE mutual authentication credentials VPN gateway

This document defines a generic way for Internet Key Exchange version 2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods.

draft-kivinen-ipsecme-secure-password-framework-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6467
RFC6468 Sieve Notification Mechanism: SIP MESSAGE A. Melnikov B. Leiba K. Li February 2012 ASCII HTML 10 Sieve SIP notification

This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. [STANDARDS-TRACK]

draft-ietf-sieve-notify-sip-message-08 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6468
RFC6469 RTP Payload Format for DV (IEC 61834) Video K. Kobayashi K. Mishima S. Casner C. Bormann December 2011 ASCII HTML 18 DV/RTP real-time transport protocol

This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. [STANDARDS-TRACK]

draft-ietf-payload-rfc3189bis-03 RFC3189 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6469
RFC6470 Network Configuration Protocol (NETCONF) Base Notifications A. Bierman February 2012 ASCII HTML 15 XML

The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. [STANDARDS-TRACK]

draft-ietf-netconf-system-notifications-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6470 10.17487/RFC6470
RFC6471 Overview of Best Email DNS-Based List (DNSBL) Operational Practices C. Lewis M. Sergeant January 2012 ASCII HTML 21 DNSBL policy

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering. This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-asrg-bcp-blacklists-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6471
RFC6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP W. Kumari K. Sriram December 2011 ASCII HTML 5 BGPv4 Operator RPKI Aggregation Route Origin

This document recommends against the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. This memo documents an Internet Best Current Practice.

draft-ietf-idr-deprecate-as-sets-06 BCP0172 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6472
RFC6473 vCard KIND:application P. Saint-Andre December 2011 ASCII HTML 5 vCard

This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. [STANDARDS-TRACK]

draft-ietf-vcarddav-kind-app-00 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav 10.17487/RFC6473
RFC6474 vCard Format Extensions: Place of Birth, Place and Date of Death K. Li B. Leiba December 2011 ASCII HTML 6 contacts address-book personal-information

The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. [STANDARDS-TRACK]

draft-ietf-vcarddav-birth-death-extensions-02 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6474 10.17487/RFC6474
RFC6475 Proxy Mobile IPv6 Management Information Base G. Keeni K. Koide S. Gundavelli R. Wakikawa May 2012 ASCII HTML 63

This memo defines a portion of the Proxy Mobile IPv6 Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. [STANDARDS-TRACK]

draft-ietf-netlmm-pmipv6-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6475 10.17487/RFC6475
RFC6476 Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS) P. Gutmann January 2012 ASCII HTML 15 authenticated data

This document specifies the conventions for using Message Authentication Code (MAC) encryption with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security (SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. [STANDARDS-TRACK]

draft-gutmann-cms-hmac-enc-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6476 10.17487/RFC6476
RFC6477 Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail A. Melnikov G. Lunt January 2012 ASCII HTML 21

A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-melnikov-mmhs-header-fields-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6477
RFC6478 Pseudowire Status for Static Pseudowires L. Martini G. Swallow G. Heron M. Bocci May 2012 ASCII HTML 13

This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allows PW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status-signaling information. [STANDARDS-TRACK]

draft-ietf-pwe3-static-pw-status-10 RFC5885 RFC7274 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6478
RFC6479 IPsec Anti-Replay Algorithm without Bit Shifting X. Zhang T. Tsou January 2012 ASCII HTML 9

This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-zhang-ipsecme-anti-replay-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6479
RFC6480 An Infrastructure to Support Secure Internet Routing M. Lepinski S. Kent February 2012 ASCII HTML 24 RPKI BGP ROA

This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sidr-arch-13 INFORMATIONAL INFORMATIONAL IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6480 10.17487/RFC6480
RFC6481 A Profile for Resource Certificate Repository Structure G. Huston R. Loomans G. Michaelson February 2012 ASCII HTML 15 rpki Resource Public Key Infrastructure

This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK]

draft-ietf-sidr-repos-struct-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6481
RFC6482 A Profile for Route Origin Authorizations (ROAs) M. Lepinski S. Kent D. Kong February 2012 ASCII HTML 9 RPKI BGP

This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. [STANDARDS-TRACK]

draft-ietf-sidr-roa-format-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6482 10.17487/RFC6482
RFC6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) G. Huston G. Michaelson February 2012 ASCII HTML 8 rpki bgp Resource Public Key Infrastructure

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-sidr-roa-validation-10 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6483
RFC6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) S. Kent D. Kong K. Seo R. Watro February 2012 ASCII HTML 35 Certification Practice Statement CPS

This document describes the certificate policy for a Public Key Infrastructure (PKI) used to support attestations about Internet Number Resource (INR) holdings. Each organization that distributes IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a (public key) certificate reflecting this distribution. These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources. This memo documents an Internet Best Current Practice.

draft-ietf-sidr-cp-17 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6484
RFC6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) G. Huston February 2012 ASCII HTML 6

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. [STANDARDS-TRACK]

draft-ietf-sidr-rpki-algs-05 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6485 10.17487/RFC6485
RFC6486 Manifests for the Resource Public Key Infrastructure (RPKI) R. Austein G. Huston S. Kent M. Lepinski February 2012 ASCII HTML 19

This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK]

draft-ietf-sidr-rpki-manifests-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6486
RFC6487 A Profile for X.509 PKIX Resource Certificates G. Huston G. Michaelson R. Loomans February 2012 ASCII HTML 32 rpki Resource Public Key Infrastructure Internet Number Resources INR

This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK]

draft-ietf-sidr-res-certs-22 RFC7318 RFC8209 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6487 10.17487/RFC6487
RFC6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI) M. Lepinski A. Chi S. Kent February 2012 ASCII HTML 13 ROA manifest GhostBusters

This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK]

draft-ietf-sidr-signed-object-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6488 10.17487/RFC6488
RFC6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) G. Huston G. Michaelson S. Kent February 2012 ASCII HTML 10 RPKI

This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice.

draft-ietf-sidr-keyroll-08 BCP0174 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6489 10.17487/RFC6489
RFC6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent February 2012 ASCII HTML 7 tal

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). [STANDARDS-TRACK]

draft-ietf-sidr-ta-07 RFC7730 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6490
RFC6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA T. Manderson L. Vegoda S. Kent February 2012 ASCII HTML 12 sidr rpki iana as0 as 0 roa

This document provides specific direction to IANA as to the Resource Public Key Infrastructure (RPKI) objects it should issue. [STANDARDS-TRACK]

draft-ietf-sidr-iana-objects-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6491
RFC6492 A Protocol for Provisioning Resource Certificates G. Huston R. Loomans B. Ellacott R. Austein February 2012 ASCII HTML 32 RPKI

This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]

draft-ietf-sidr-rescerts-provisioning-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6492
RFC6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record R. Bush February 2012 ASCII HTML 8 RPKI Resource Certificate Human Contact vCard

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. [STANDARDS- TRACK]

draft-ietf-sidr-ghostbusters-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=6493 10.17487/RFC6493
RFC6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) R. Gagliano S. Krishnan A. Kukec February 2012 ASCII HTML 12 RPKI ND

SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. [STANDARDS-TRACK]

draft-ietf-csi-send-cert-10 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi http://www.rfc-editor.org/errata_search.php?rfc=6494 10.17487/RFC6494
RFC6495 Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields R. Gagliano S. Krishnan A. Kukec February 2012 ASCII HTML 5

SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). [STANDARDS-TRACK]

draft-ietf-csi-send-name-type-registry-06 RFC3971 PROPOSED STANDARD PROPOSED STANDARD IETF int csi 10.17487/RFC6495
RFC6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) S. Krishnan J. Laganier M. Bonola A. Garcia-Martinez February 2012 ASCII HTML 24 SPND CGA Mobile IPv6 MIPv6 Proxy Mobile IPv6 PMIPv6

SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. This document defines an Experimental Protocol for the Internet community.

draft-ietf-csi-proxy-send-05 EXPERIMENTAL EXPERIMENTAL IETF int csi 10.17487/RFC6496
RFC6497 BCP 47 Extension T - Transformed Content M. Davis A. Phillips Y. Umaoka C. Falk February 2012 ASCII HTML 15 locale

This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-davis-t-langtag-ext-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6497 10.17487/RFC6497
RFC6498 Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package J. Stone R. Kumar F. Andreasen February 2012 ASCII HTML 47

This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy, and FEC. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-stone-mgcp-vbd-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6498
RFC6499 RFC6500 RFC6501 Conference Information Data Model for Centralized Conferencing (XCON) O. Novo G. Camarillo D. Morgan J. Urpalainen March 2012 ASCII HTML 94

RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-TRACK]

draft-ietf-xcon-common-data-model-32 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6501
RFC6502 Conference Event Package Data Format Extension for Centralized Conferencing (XCON) G. Camarillo S. Srinivasan R. Even J. Urpalainen March 2012 ASCII HTML 14

This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. [STANDARDS-TRACK]

draft-ietf-xcon-event-package-01 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon 10.17487/RFC6502
RFC6503 Centralized Conferencing Manipulation Protocol M. Barnes C. Boulton S. Romano H. Schulzrinne March 2012 ASCII HTML 119 conference user ad hoc conference sidebar conference scheduled conference

The Centralized Conferencing Manipulation Protocol (CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. [STANDARDS-TRACK]

draft-ietf-xcon-ccmp-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xcon http://www.rfc-editor.org/errata_search.php?rfc=6503 10.17487/RFC6503
RFC6504 Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples M. Barnes L. Miniero R. Presta S P. Romano March 2012 ASCII HTML 78

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-xcon-examples-10 INFORMATIONAL INFORMATIONAL IETF rai xcon 10.17487/RFC6504
RFC6505 A Mixer Control Package for the Media Control Channel Framework S. McGlashan T. Melanchuk C. Boulton March 2012 ASCII HTML 89 conference mixer

This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers [STANDARDS-TRACK]

draft-ietf-mediactrl-mixer-control-package-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl http://www.rfc-editor.org/errata_search.php?rfc=6505 10.17487/RFC6505
RFC6506 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem February 2012 ASCII HTML 20 Routing security

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. [STANDARDS-TRACK]

draft-ietf-ospf-auth-trailer-ospfv3-11 RFC7166 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6506 10.17487/RFC6506
RFC6507 Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) M. Groves February 2012 ASCII HTML 17

Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-groves-eccsi-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6507
RFC6508 Sakai-Kasahara Key Encryption (SAKKE) M. Groves February 2012 ASCII HTML 21

In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-groves-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6508
RFC6509 MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) M. Groves February 2012 ASCII HTML 21

This document describes the Multimedia Internet KEYing-Sakai-Kasahara Key Encryption (MIKEY-SAKKE), a method of key exchange that uses Identity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-groves-mikey-sakke-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6509
RFC6510 Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects L. Berger G. Swallow February 2012 ASCII HTML 8

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK]

draft-ietf-ccamp-attribute-bnf-02 RFC4875 RFC5420 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6510
RFC6511 Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths Z. Ali G. Swallow R. Aggarwal February 2012 ASCII HTML 10

There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6511
RFC6512 Using Multipoint LDP When the Backbone Has No Route to the Root IJ. Wijnands E. Rosen M. Napierala N. Leymann February 2012 ASCII HTML 12

The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of a BGP-free core. This document specifies procedures that enable an MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. [STANDARDS-TRACK]

draft-ietf-mpls-mldp-recurs-fec-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6512 10.17487/RFC6512
RFC6513 Multicast in MPLS/BGP IP VPNs E. Rosen Editor R. Aggarwal Editor February 2012 ASCII HTML 88

In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]

draft-ietf-l3vpn-2547bis-mcast-10 RFC7582 RFC7900 RFC7988 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6513 10.17487/RFC6513
RFC6514 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs R. Aggarwal E. Rosen T. Morin Y. Rekhter February 2012 ASCII HTML 59

This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]

draft-ietf-l3vpn-2547bis-mcast-bgp-08 RFC6515 RFC6625 RFC7385 RFC7441 RFC7582 RFC7899 RFC7900 RFC7902 RFC7988 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6514 10.17487/RFC6514
RFC6515 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN R. Aggarwal E. Rosen February 2012 ASCII HTML 8 mvpn mcast-vpn multicast-vpn

To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN-specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. [STANDARDS-TRACK]

draft-ietf-l3vpn-mvpn-infra-addrs-05 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6515 10.17487/RFC6515
RFC6516 IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages Y. Cai E. Rosen Editor I. Wijnands February 2012 ASCII HTML 6

The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider Multicast Service Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. [STANDARDS-TRACK]

draft-ietf-l3vpn-mvpn-spmsi-joins-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6516
RFC6517 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution T. Morin Editor B. Niven-Jenkins Editor Y. Kamite R. Zhang N. Leymann N. Bitar February 2012 ASCII HTML 41 mpls vpn multicast l3vpn bgp pim p2mp ldp rsvp-te

More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.

To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-l3vpn-mvpn-considerations-06 INFORMATIONAL INFORMATIONAL IETF rtg l3vpn 10.17487/RFC6517
RFC6518 Keying and Authentication for Routing Protocols (KARP) Design Guidelines G. Lebovitz M. Bhatia February 2012 ASCII HTML 30 MAC hash security securing secure authorization protection harden hardening infrastructure router crypto cryptography cryptographic roadmap guide guideline message framework key keys management protocol KMP key management protocol,

This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-karp-design-guide-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6518
RFC6519 RADIUS Extensions for Dual-Stack Lite R. Maglione A. Durand February 2012 ASCII HTML 11 IPv6 tunnel attribute

Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]

draft-ietf-softwire-dslite-radius-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6519 10.17487/RFC6519
RFC6520 Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension R. Seggelmann M. Tuexen M. Williams February 2012 ASCII HTML 9 tls/dtls

This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK]

draft-ietf-tls-dtls-heartbeat-04 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC6520
RFC6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks A. Makela J. Korhonen February 2012 ASCII HTML 53 mobile router mobile network prefix correspondent router

This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mip4-nemo-haaro-07 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC6521
RFC6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages M. Kucherawy Editor January 2012 ASCII HTML 9 MIME Multipurpose Internet Mail Extensions

The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports.

This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK]

draft-ietf-appsawg-rfc3462bis-04 RFC3462 RFC6533 STD0073 INTERNET STANDARD INTERNET STANDARD IETF app appsawg 10.17487/RFC6522
RFC6523 RFC6524 RFC6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration R. Stewart M. Tuexen P. Lei February 2012 ASCII HTML 34

Many applications that use the Stream Control Transmission Protocol (SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. [STANDARDS-TRACK]

draft-ietf-tsvwg-sctp-strrst-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6525
RFC6526 IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream B. Claise P. Aitken A. Johnson G. Muenz March 2012 ASCII HTML 23

This document specifies an extension to the specifications in RFC 5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol).

When implemented at both the Exporting Process and Collecting Process, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. [STANDARDS-TRACK]

draft-ietf-ipfix-export-per-sctp-stream-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6526
RFC6527 Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) K. Tata March 2012 ASCII HTML 31 management information base

This specification defines a portion of the Management Information Base (MIB) for use with network management based on the Simple Network Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. [STANDARDS-TRACK]

draft-ietf-vrrp-unified-mib-10 RFC2787 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6527 10.17487/RFC6527
RFC6528 Defending against Sequence Number Attacks F. Gont S. Bellovin February 2012 ASCII HTML 12 TCP security TCP Sequence Numbers Sequence Number Randomization obfuscation TCP vulnerabilities

This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc1948bis-02 RFC1948 RFC0793 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6528
RFC6529 Host/Host Protocol for the ARPA Network A. McKenzie S. Crocker April 2012 ASCII HTML 34

This document reproduces the Host/Host Protocol developed by the ARPA Network Working Group during 1969, 1970, and 1971. It describes a protocol used to manage communication between processes residing on independent Hosts. It addresses issues of multiplexing multiple streams of communication (including addressing, flow control, connection establishment/disestablishment, and other signaling) over a single hardware interface. It was the official protocol of the ARPA Network from January 1972 until the switch to TCP/IP in January 1983. It is offered as an RFC at this late date to help complete the historical record available through the RFC series. This document is not an Internet Standards Track specification; it is published for the historical record.

draft-mckenzie-arpanet-host-host-protocol-01 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6529
RFC6530 Overview and Framework for Internationalized Email J. Klensin Y. Ko February 2012 ASCII HTML 26 SMTP Email I18n Internationalization SMTPUTF8

Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK]

draft-ietf-eai-frmwrk-4952bis-12 RFC4952 RFC5504 RFC5825 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6530
RFC6531 SMTP Extension for Internationalized Email J. Yao W. Mao February 2012 ASCII HTML 18 SMTP Email I18n Internationalization SMTPUTF8

This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK]

draft-ietf-eai-rfc5336bis-16 RFC5336 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6531 10.17487/RFC6531
RFC6532 Internationalized Email Headers A. Yang S. Steele N. Freed February 2012 ASCII HTML 11

Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.

This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]

draft-ietf-eai-rfc5335bis-13 RFC5335 RFC2045 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6532 10.17487/RFC6532
RFC6533 Internationalized Delivery Status and Disposition Notifications T. Hansen Editor C. Newman A. Melnikov February 2012 ASCII HTML 19 dsn

Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK]

draft-ietf-eai-rfc5337bis-dsn-06 RFC5337 RFC3461 RFC3464 RFC3798 RFC6522 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6533
RFC6534 Loss Episode Metrics for IP Performance Metrics (IPPM) N. Duffield A. Morton J. Sommers May 2012 ASCII HTML 21

The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts. However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. [STANDARDS-TRACK]

draft-ietf-ippm-loss-episode-metrics-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6534
RFC6535 Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) B. Huang H. Deng T. Savolainen February 2012 ASCII HTML 25 NAT NAT46 DNS DNS46 translation IPv4 applications IPv6 ENR

Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 and RFC 3338. [STANDARDS-TRACK]

draft-ietf-behave-v4v6-bih-09 RFC2767 RFC3338 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=6535 10.17487/RFC6535
RFC6536 Network Configuration Protocol (NETCONF) Access Control Model A. Bierman M. Bjorklund March 2012 ASCII HTML 49 NETCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]

draft-ietf-netconf-access-control-07 RFC8341 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=6536 10.17487/RFC6536
RFC6537 Host Identity Protocol Distributed Hash Table Interface J. Ahrenholz February 2012 ASCII HTML 20 HIP Host Identity Protocol DHT DIstributed Hash Table HIT Host Identity Tag resolution service

This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service. This document defines an Experimental Protocol for the Internet community.

draft-irtf-hiprg-dht-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6537
RFC6538 The Host Identity Protocol (HIP) Experiment Report T. Henderson A. Gurtov March 2012 ASCII HTML 35 Security ID/locator split IPsec Research

This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-irtf-hip-experiment-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6538
RFC6539 IBAKE: Identity-Based Authenticated Key Exchange V. Cakulev G. Sundaram I. Broustis March 2012 ASCII HTML 13 ibe identity based encryption

Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure (PKI) to support certificate management. The emerging field of Identity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange (IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cakulev-ibake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6539
RFC6540 IPv6 Support Required for All IP-Capable Nodes W. George C. Donley C. Liljenstolpe L. Howard April 2012 ASCII HTML 6 IPv4 requirement

Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. This memo documents an Internet Best Current Practice.

draft-ietf-intarea-ipv6-required-02 BCP0177 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC6540
RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures M. Kucherawy February 2012 ASCII HTML 16 Authentication Reputation

This experimental specification proposes a modification to DomainKeys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. This document defines an Experimental Protocol for the Internet community.

draft-kucherawy-dkim-atps-16 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6541
RFC6542 Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility S. Emery March 2012 ASCII HTML 6

Currently, channel bindings are implemented using an MD5 hash in the Kerberos Version 5 Generic Security Service Application Programming Interface (GSS-API) mechanism (RFC 4121). This document updates RFC 4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. [STANDARDS-TRACK]

draft-ietf-krb-wg-gss-cb-hash-agility-10 RFC4121 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6542
RFC6543 Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 S. Gundavelli May 2012 ASCII HTML 5

Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose. This document also updates RFC 5213. [STANDARDS-TRACK]

draft-gundavelli-v6ops-pmipv6-address-reservations-06 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6543
RFC6544 TCP Candidates with Interactive Connectivity Establishment (ICE) J. Rosenberg A. Keranen B. B. Lowekamp A. B. Roach March 2012 ASCII HTML 29 ICE TCP NAT NAT traversal

Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK]

draft-ietf-mmusic-ice-tcp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=6544 10.17487/RFC6544
RFC6545 Real-time Inter-network Defense (RID) K. Moriarty April 2012 ASCII HTML 84 incident response incident coordination incident handling incident communication

Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045. [STANDARDS-TRACK]

draft-ietf-mile-rfc6045-bis-11 RFC6045 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6545 10.17487/RFC6545
RFC6546 Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS B. Trammell April 2012 ASCII HTML 8 Coordinated Incident Response CSIRT Incident Object Description Exchange Format IODEF

The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. [STANDARDS-TRACK]

draft-ietf-mile-rfc6046-bis-09 RFC6046 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=6546 10.17487/RFC6546
RFC6547 RFC 3627 to Historic Status W. George February 2012 ASCII HTML 3 IPv6 /127 point-to-point address inter-router links

This document moves "Use of /127 Prefix Length Between Routers Considered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter- Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6man-3627-historic-01 RFC3627 RFC6164 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC6547
RFC6548 Independent Submission Editor Model N. Brownlee Editor IAB June 2012 ASCII HTML 5 Independent Stream Editor

This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administrative Oversight Committee (IAOC). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-ise-model-07 RFC5620 RFC8730 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6548
RFC6549 OSPFv2 Multi-Instance Extensions A. Lindem A. Roy S. Mirtorabi March 2012 ASCII HTML 9 Instance ID

OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.

This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.

This document updates RFC 2328. [STANDARDS-TRACK]

draft-ietf-ospf-multi-instance-09 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6549 10.17487/RFC6549
RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks T. Winter Editor P. Thubert Editor A. Brandt J. Hui R. Kelsey P. Levis K. Pister R. Struik JP. Vasseur R. Alexander March 2012 ASCII HTML 157 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph

Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]

draft-ietf-roll-rpl-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6550 10.17487/RFC6550
RFC6551 Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks JP. Vasseur Editor M. Kim Editor K. Pister N. Dejean D. Barthel March 2012 ASCII HTML 30 RPL ROLL LLN Constrained based routing,

Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]

draft-ietf-roll-routing-metrics-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6551 10.17487/RFC6551
RFC6552 Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) P. Thubert Editor March 2012 ASCII HTML 14 WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing Distance Vector Objective Function DAG for Directed Acyclic Graph RPL

The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.

This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]

draft-ietf-roll-of0-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC6552
RFC6553 The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams J. Hui JP. Vasseur March 2012 ASCII HTML 9 LLN LLNs Trickle

The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]

draft-ietf-6man-rpl-option-06 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6553
RFC6554 An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Hui JP. Vasseur D. Culler V. Manral March 2012 ASCII HTML 13 LLN LLNs

In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]

draft-ietf-6man-rpl-routing-header-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6554
RFC6555 Happy Eyeballs: Success with Dual-Stack Hosts D. Wing A. Yourtchenko April 2012 ASCII HTML 15

When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]

draft-ietf-v6ops-happy-eyeballs-07 RFC8305 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=6555 10.17487/RFC6555
RFC6556 Testing Eyeball Happiness F. Baker April 2012 ASCII HTML 10 test methodology IPv4 IPv6 session startup metrics

The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-baker-bmwg-testing-eyeball-happiness-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6556
RFC6557 Procedures for Maintaining the Time Zone Database E. Lear P. Eggert February 2012 ASCII HTML 9

Time zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. This memo documents an Internet Best Current Practice.

draft-lear-iana-timezone-database-05 BCP0175 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6557
RFC6558 Sieve Extension for Converting Messages before Delivery A. Melnikov B. Leiba K. Li March 2012 ASCII HTML 8 Sieve CONVERT

This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. [STANDARDS-TRACK]

draft-ietf-sieve-convert-06 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve http://www.rfc-editor.org/errata_search.php?rfc=6558 10.17487/RFC6558
RFC6559 A Reliable Transport Mechanism for PIM D. Farinacci IJ. Wijnands S. Venaas M. Napierala March 2012 ASCII HTML 29

This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pim-port-09 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6559
RFC6560 One-Time Password (OTP) Pre-Authentication G. Richards April 2012 ASCII HTML 43

The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password (OTP) authentication. [STANDARDS-TRACK]

draft-ietf-krb-wg-otp-preauth-21 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6560
RFC6561 Recommendations for the Remediation of Bots in ISP Networks J. Livingood N. Mody M. O'Reirdan March 2012 ASCII HTML 29 ISP Internet Service Provider Bot Botnet Remediation malware notification

This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-oreirdan-mody-bot-remediation-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6561 10.17487/RFC6561
RFC6562 Guidelines for the Use of Variable Bit Rate Audio with Secure RTP C. Perkins JM. Valin March 2012 ASCII HTML 6 vbr

This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. [STANDARDS-TRACK]

draft-ietf-avtcore-srtp-vbr-audio-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6562
RFC6563 Moving A6 to Historic Status S. Jiang D. Conrad B. Carpenter March 2012 ASCII HTML 8

This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-jiang-a6-to-historic-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6563
RFC6564 A Uniform Format for IPv6 Extension Headers S. Krishnan J. Woodyatt E. Kline J. Hoagland M. Bhatia April 2012 ASCII HTML 6

In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]

draft-ietf-6man-exthdr-06 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6564 10.17487/RFC6564
RFC6565 OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol P. Pillay-Esnault P. Moyer J. Doyle E. Ertekin M. Lundberg June 2012 ASCII HTML 20 L3VPN BGP/MPLS VPN

Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]

draft-ietf-l3vpn-ospfv3-pece-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC6565
RFC6566 A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments Y. Lee Editor G. Bernstein Editor D. Li G. Martinelli March 2012 ASCII HTML 31

As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.

This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to support Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation. This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-wson-impairments-10 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6566
RFC6567 Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP A. Johnston L. Liess April 2012 ASCII HTML 11

This document introduces the transport of call control User-to-User Information (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network (ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-cuss-sip-uui-reqs-09 INFORMATIONAL INFORMATIONAL IETF rai cuss 10.17487/RFC6567
RFC6568 Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) E. Kim D. Kaspar JP. Vasseur April 2012 ASCII HTML 28

This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6lowpan-usecases-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6568
RFC6569 Guidelines for Development of an Audio Codec within the IETF JM. Valin S. Borilin K. Vos C. Montgomery R. Chen March 2012 ASCII HTML 14 audio codec speech codec

This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-codec-guidelines-08 INFORMATIONAL INFORMATIONAL IETF rai codec 10.17487/RFC6569
RFC6570 URI Template J. Gregorio R. Fielding M. Hadley M. Nottingham D. Orchard March 2012 ASCII HTML 34 template Uniform Resource Identifier URI URI Template Internationalized Resource Identifier IRI IRI Template

A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]

draft-gregorio-uritemplate-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6570 10.17487/RFC6570
RFC6571 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks C. Filsfils Editor P. Francois Editor M. Shand B. Decraene J. Uttaro N. Leymann M. Horneffer June 2012 ASCII HTML 35 IP Fast Reroute Routing Convergence Network Topology IS-IS OSPF

In this document, we analyze the applicability of the Loop-Free Alternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-rtgwg-lfa-applicability-06 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=6571 10.17487/RFC6571
RFC6572 RADIUS Support for Proxy Mobile IPv6 F. Xia B. Sarikaya J. Korhonen Editor S. Gundavelli D. Damic June 2012 ASCII HTML 36

This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. [STANDARDS-TRACK]

draft-ietf-netext-radius-pmip6-08 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6572
RFC6573 The Item and Collection Link Relations M. Amundsen April 2012 ASCII HTML 5

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-amundsen-item-and-collection-link-relations-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6573
RFC6574 Report from the Smart Object Workshop H. Tschofenig J. Arkko April 2012 ASCII HTML 32 Smart Objects Internet of Things

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on 'Interconnecting Smart Objects with the Internet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-smart-object-workshop-10 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6574
RFC6575 Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs H. Shah Editor E. Rosen Editor G. Heron Editor V. Kompella Editor June 2012 ASCII HTML 28

The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. [STANDARDS-TRACK]

draft-ietf-l2vpn-arp-mediation-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC6575
RFC6576 IP Performance Metrics (IPPM) Standard Advancement Testing R. Geib Editor A. Morton R. Fardid A. Steinmitz March 2012 ASCII HTML 37 inter-operability equivalence measurement compliance metric

This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself to determine whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF Standards Track. This document is an Internet Best Current Practice.

draft-ietf-ippm-metrictest-05 BCP0176 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv ippm http://www.rfc-editor.org/errata_search.php?rfc=6576 10.17487/RFC6576
RFC6577 Authentication-Results Registration Update for Sender Policy Framework (SPF) Results M. Kucherawy March 2012 ASCII HTML 5 SPF Authentication

This memo updates the registry of authentication method results in Authentication-Results: message header fields, correcting a discontinuity between the original registry creation and the Sender Policy Framework (SPF) specification. [STANDARDS-TRACK]

draft-kucherawy-authres-spf-erratum-02 RFC7001 RFC5451 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6577
RFC6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) C. Daboo A. Quillaud March 2012 ASCII HTML 29 sync-collection sync-token

This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. [STANDARDS-TRACK]

draft-daboo-webdav-sync-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6578
RFC6579 The 'disclosure' Link Relation Type M. Yevstifeyev March 2012 ASCII HTML 5

This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. [STANDARDS-TRACK]

draft-yevstifeyev-disclosure-relation-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6579
RFC6580 IANA Registries for the Remote Direct Data Placement (RDDP) Protocols M. Ko D. Black April 2012 ASCII HTML 10

The original RFCs that specified the Remote Direct Data Placement (RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. [STANDARDS-TRACK]

draft-ietf-storm-rddp-registries-02 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=6580 10.17487/RFC6580
RFC6581 Enhanced Remote Direct Memory Access (RDMA) Connection Establishment A. Kanevsky Editor C. Bestler Editor R. Sharp S. Wise April 2012 ASCII HTML 25

This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. [STANDARDS-TRACK]

draft-ietf-storm-mpa-peer-connect-09 RFC5043 RFC5044 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC6581
RFC6582 The NewReno Modification to TCP's Fast Recovery Algorithm T. Henderson S. Floyd A. Gurtov Y. Nishida April 2012 ASCII HTML 16 congestion avoidance congestion control fast retransmit

RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK]

draft-ietf-tcpm-rfc3782-bis-05 RFC3782 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6582
RFC6583 Operational Neighbor Discovery Problems I. Gashinsky J. Jaeggli W. Kumari March 2012 ASCII HTML 12

In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.

This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK]

draft-ietf-v6ops-v6nd-problems-04 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6583
RFC6584 Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca April 2012 ASCII HTML 30 TESLA FLUTE

This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]

draft-ietf-rmt-simple-auth-for-alc-norm-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt 10.17487/RFC6584
RFC6585 Additional HTTP Status Codes M. Nottingham R. Fielding April 2012 ASCII HTML 10 Hypertext Transfer Protocol

This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]

draft-nottingham-http-new-status-04 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6585
RFC6586 Experiences from an IPv6-Only Network J. Arkko A. Keranen April 2012 ASCII HTML 21 IPv6 NAT64

This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-arkko-ipv6-only-experience-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6586
RFC6587 Transmission of Syslog Messages over TCP R. Gerhards C. Lonvick April 2012 ASCII HTML 11 SYSLOG SYSLOG transport TCP

There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages. This document defines a Historic Document for the Internet community.

draft-gerhards-syslog-plain-tcp-14 HISTORIC HISTORIC IETF NON WORKING GROUP 10.17487/RFC6587
RFC6588 A URN Namespace for ucode C. Ishikawa April 2012 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ishikawa-yrpunl-ucode-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6588 10.17487/RFC6588
RFC6589 Considerations for Transitioning Content to IPv6 J. Livingood April 2012 ASCII HTML 27

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6589
RFC6590 Redaction of Potentially Sensitive Data from Mail Abuse Reports J. Falk Editor M. Kucherawy Editor April 2012 ASCII HTML 8 ARF MARF feedback loop spam reporting

Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. [STANDARDS-TRACK]

draft-ietf-marf-redaction-08 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6590
RFC6591 Authentication Failure Reporting Using the Abuse Reporting Format H. Fontana April 2012 ASCII HTML 16 auth auth failure dkim spf AFRF ARF

This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. [STANDARDS-TRACK]

draft-ietf-marf-authfailure-report-10 RFC6692 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6591
RFC6592 The Null Packet C. Pignataro April 1 2012 ASCII HTML 6

The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-pignataro-the-null-packet-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6592
RFC6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) C. Pignataro J. Clarke G. Salgueiro April 1 2012 ASCII HTML 8

With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.

This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.

draft-joegonzalocarlos-service-hide-n-seek-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6593
RFC6594 Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records O. Sury April 2012 ASCII HTML 9 DNS Domain Name System SSHFP SHA-256 Secure Shell ECDSA

This document updates the IANA registries in RFC 4255, which defines SSHFP, a DNS Resource Record (RR) that contains a standard Secure Shell (SSH) key fingerprint used to verify SSH host keys using DNS Security Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic Curve Digital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm in SSHFP Resource Records. [STANDARDS-TRACK]

draft-os-ietf-sshfp-ecdsa-sha2-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6594 10.17487/RFC6594
RFC6595 A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) K. Wierenga E. Lear S. Josefsson April 2012 ASCII HTML 22 Generic Security Service Application Program Interface SAML 2.0

The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

draft-ietf-kitten-sasl-saml-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6595
RFC6596 The Canonical Link Relation M. Ohye J. Kupke April 2012 ASCII HTML 8

RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ohye-canonical-link-relation-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6596
RFC6597 RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data J. Downs Editor J. Arbeiter Editor April 2012 ASCII HTML 13 KLV

This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK]

draft-ietf-payload-rtp-klv-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6597
RFC6598 IANA-Reserved IPv4 Prefix for Shared Address Space J. Weil V. Kuarsingh C. Donley C. Liljenstolpe M. Azinger April 2012 ASCII HTML 11 shared block CGN NAT Carrier Grade NAT private address space service provider address translation non-globally routable non-overlapping address space

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.

This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. This memo documents an Internet Best Current Practice.

draft-weil-shared-transition-space-request-15 RFC5735 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6598
RFC6599 RFC6600 RFC6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks G. Ash Editor D. McDysan April 2012 ASCII HTML 34

This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress. Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers. MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv-aware MPLS Traffic Engineering (DS-TE), Path Computation Element (PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLS GCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. This document defines an Experimental Protocol for the Internet community.

draft-ash-gcac-algorithm-spec-04 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6601
RFC6602 Bulk Binding Update Support for Proxy Mobile IPv6 F. Abinader Editor S. Gundavelli Editor K. Leung S. Krishnan D. Premec May 2012 ASCII HTML 23 Proxy Mobile IPv6 PMIPv6 bulk registrations MN group ID

For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. [STANDARDS-TRACK]

draft-ietf-netext-bulk-re-registration-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6602
RFC6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation J. Korhonen Editor T. Savolainen S. Krishnan O. Troan May 2012 ASCII HTML 10 OPTION_PD_EXCLUDE

This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK]

draft-ietf-dhc-pd-exclude-04 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6603 10.17487/RFC6603
RFC6604 xNAME RCODE and Status Bits Clarification D. Eastlake 3rd April 2012 ASCII HTML 5 DNS DNSSEC CNAME DNAME Domain Name response code canonical name

The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. [STANDARDS-TRACK]

draft-ietf-dnsext-xnamercode-00 RFC1035 RFC2308 RFC2672 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6604
RFC6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC P. Hoffman W.C.A. Wijngaards April 2012 ASCII HTML 8 dnskey algorithm ds hash algo crypto DNS key DNSKEY algorithm DS digest hash cryptography SHA-384 ECDSAP256SHA256 ECDSAP384SHA384

This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]

draft-ietf-dnsext-ecdsa-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6605
RFC6606 Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing E. Kim D. Kaspar C. Gomez C. Bormann May 2012 ASCII HTML 32 WSN Sensor Network Wireless Sensor Network WSN for Wireless Sensor Network L3 Mesh for Layer 3 Mesh Network Routing Protocol Subnet Routing ieee 802.15.4 LLN Low Power radio 802.15.4 powerline ISA100.11a RFC 4944

IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.

This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETF ROLL WG. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-6lowpan-routing-requirements-10 INFORMATIONAL INFORMATIONAL IETF int 6lowpan 10.17487/RFC6606
RFC6607 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 K. Kinnear R. Johnson M. Stapp April 2012 ASCII HTML 26 draft-ietf-dhc-vpn-option-15 RFC3046 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6607 RFC6608 Subcodes for BGP Finite State Machine Error J. Dong M. Chen A. Suryanarayana May 2012 ASCII HTML 5

This document defines several subcodes for the BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271. [STANDARDS-TRACK]

draft-ietf-idr-fsm-subcode-03 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6608
RFC6609 Sieve Email Filtering: Include Extension C. Daboo A. Stone May 2012 ASCII HTML 14

The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. [STANDARDS-TRACK]

draft-ietf-sieve-include-15 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6609
RFC6610 DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6) H. Jang A. Yegin K. Chowdhury J. Choi T. Lemon May 2012 ASCII HTML 16

This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. [STANDARDS-TRACK]

draft-ietf-mip6-hiopt-18 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6610
RFC6611 Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario K. Chowdhury Editor A. Yegin May 2012 ASCII HTML 12

Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. [STANDARDS-TRACK]

draft-ietf-mip6-bootstrapping-integrated-dhc-06 PROPOSED STANDARD PROPOSED STANDARD IETF int mip6 10.17487/RFC6611
RFC6612 Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues G. Giaretta Editor May 2012 ASCII HTML 18

The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-netlmm-mip-interactions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6612
RFC6613 RADIUS over TCP A. DeKok May 2012 ASCII HTML 16 Remote Authentication Dial-In User Server Transmission Control Protocol RADIUS/TCP

The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. This document defines an Experimental Protocol for the Internet community.

draft-ietf-radext-tcp-transport-09 RFC7930 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6613
RFC6614 Transport Layer Security (TLS) Encryption for RADIUS S. Winter M. McCauley S. Venaas K. Wierenga May 2012 ASCII HTML 22 RADIUS AAA Security Reliability Remote Authentication Dial-In User Server

This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK]

draft-ietf-radext-radsec-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC6614
RFC6615 Definitions of Managed Objects for IP Flow Information Export T. Dietz Editor A. Kobayashi B. Claise G. Muenz June 2012 ASCII HTML 65 IPFIX MIB Filtering Sampling Selection

This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]

draft-ietf-ipfix-rfc5815bis-03 RFC5815 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6615
RFC6616 A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID E. Lear H. Tschofenig H. Mauldin S. Josefsson May 2012 ASCII HTML 18 web single sign-on

OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. [STANDARDS-TRACK]

draft-ietf-kitten-sasl-openid-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC6616
RFC6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) D. Harkins June 2012 ASCII HTML 24 Authenticated Key Exchange Dictionary Attack

This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. This document defines an Experimental Protocol for the Internet community.

draft-harkins-ipsecme-spsk-auth-08 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6617
RFC6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent J. Korhonen Editor B. Patil H. Tschofenig D. Kroeselberg May 2012 ASCII HTML 38 Mobile IPv6 Security

Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol (IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mext-mip6-tls-05 EXPERIMENTAL EXPERIMENTAL IETF int mext 10.17487/RFC6618
RFC6619 Scalable Operation of Address Translators with Per-Interface Bindings J. Arkko L. Eggert M. Townsley June 2012 ASCII HTML 9 NAT IPv4 IPv6

This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. [STANDARDS-TRACK]

draft-arkko-dual-stack-extra-lite-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6619
RFC6620 FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses E. Nordmark M. Bagnulo E. Levy-Abegnoli May 2012 ASCII HTML 35 ingress filtering BCP38

This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. [STANDARDS-TRACK]

draft-ietf-savi-fcfs-14 PROPOSED STANDARD PROPOSED STANDARD IETF int savi http://www.rfc-editor.org/errata_search.php?rfc=6620 10.17487/RFC6620
RFC6621 Simplified Multicast Forwarding J. Macker Editor May 2012 ASCII HTML 55 routing flooding optimized flooding CDS connected dominating set duplicate packet detection hash-based packet detection MPR MPR-CDS E-CDS edge mobility mobile ad hoc mesh network

This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. This document defines an Experimental Protocol for the Internet community.

draft-ietf-manet-smf-14 EXPERIMENTAL EXPERIMENTAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=6621 10.17487/RFC6621
RFC6622 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen May 2012 ASCII HTML 21 packetbb NHDP OLSRv2 security integrity routing

This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK]

draft-ietf-manet-packetbb-sec-09 RFC7182 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6622
RFC6623 IANA Registry for MEDIACTRL Interactive Voice Response Control Package E. Burger May 2012 ASCII HTML 6

This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, as described in RFC 6231. [STANDARDS-TRACK]

draft-ietf-mediactrl-6231-iana-00 RFC6231 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6623
RFC6624 Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling K. Kompella B. Kothari R. Cherukuri May 2012 ASCII HTML 26 BGP L2VPN discovery signaling pseudowire

Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-kompella-l2vpn-l2vpn-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6624
RFC6625 Wildcards in Multicast VPN Auto-Discovery Routes E. Rosen Editor Y. Rekhter Editor W. Hendrickx R. Qiu May 2012 ASCII HTML 17 mvpn

In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]

draft-ietf-l3vpn-mvpn-wildcards-02 RFC6514 RFC7582 RFC7900 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn http://www.rfc-editor.org/errata_search.php?rfc=6625 10.17487/RFC6625
RFC6626 Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4) G. Tsirtsis V. Park V. Narayanan K. Leung May 2012 ASCII HTML 5 mobile router

The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism for NEMOv4. [STANDARDS-TRACK]

draft-ietf-mip4-nemov4-dynamic-06 RFC5177 PROPOSED STANDARD PROPOSED STANDARD IETF int mip4 10.17487/RFC6626
RFC6627 Overview of Pre-Congestion Notification Encoding G. Karagiannis K. Chan T. Moncaster M. Menth P. Eardley B. Briscoe July 2012 ASCII HTML 20

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious \%pre-congestion.

The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pcn-encoding-comparison-09 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6627
RFC6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 S. Shin K. Kobara June 2012 ASCII HTML 20 PAKE augmented PAKE off-line dictionary attacks resistance to server compromise

This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2). This document defines an Experimental Protocol for the Internet community.

draft-shin-augmented-pake-15 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6628
RFC6629 Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) J. Abley M. Bagnulo A. Garcia-Martinez June 2012 ASCII HTML 28 Cryptographically Generated Address CGA Hash-Based Address HBA Fault tolerance

This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-garcia-shim6-applicability-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6629
RFC6630 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) Z. Cao H. Deng Q. Wu G. Zorn Editor June 2012 ASCII HTML 20 ERP AAK EAP Early-authentication

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.

The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.

Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport.

This document specifies the extensions necessary to enable AAK support in ERP. [STANDARDS-TRACK]

draft-ietf-hokey-erp-aak-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6630
RFC6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) D. Kuegler Y. Sheffer June 2012 ASCII HTML 26 pace password authenticated connection establishment

The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. This document defines an Experimental Protocol for the Internet community.

draft-kuegler-ipsecme-pace-ikev2-10 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6631
RFC6632 An Overview of the IETF Network Management Standards M. Ersue Editor B. Claise June 2012 ASCII HTML 85 network management data model monitoring configuration alarm notification

This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-opsawg-management-stds-07 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC6632
RFC6633 Deprecation of ICMP Source Quench Messages F. Gont May 2012 ASCII HTML 8 congestion control icmp attacks tcp tcp security udp dccp sctp

This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. [STANDARDS-TRACK]

draft-ietf-tsvwg-source-quench-06 RFC0792 RFC1122 RFC1812 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6633
RFC6634 RFC6635 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor IAB June 2012 ASCII HTML 21 RFC Series Editor Independenet Series Editor RSE ISE RSOC RFC Series Oversight Committee

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620, and obsoletes that document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-rfc-editor-model-v2-05 RFC5620 RFC8728 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6635
RFC6636 Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks H. Asaeda H. Liu Q. Wu May 2012 ASCII HTML 12 Mobility PMIPv6

The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-multimob-igmp-mld-tuning-06 INFORMATIONAL INFORMATIONAL IETF int multimob 10.17487/RFC6636
RFC6637 Elliptic Curve Cryptography (ECC) in OpenPGP A. Jivsov June 2012 ASCII HTML 15

This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]

draft-jivsov-openpgp-ecc-14 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6637
RFC6638 Scheduling Extensions to CalDAV C. Daboo B. Desruisseaux June 2012 ASCII HTML 78 calsify calsched calsch calendar calendaring webcal ical icalendar ischedule itip imip text/calendar http

This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. [STANDARDS-TRACK]

draft-desruisseaux-caldav-sched-12 RFC4791 RFC5546 RFC7953 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6638
RFC6639 Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview D. King Editor M. Venkatesan Editor June 2012 ASCII HTML 29

A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.

The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.

This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-mib-management-overview-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6639 10.17487/RFC6639
RFC6640 IETF Meeting Attendees' Frequently Asked (Travel) Questions W. George June 2012 ASCII HTML 13 Meetings

This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in the IETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-george-travel-faq-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6640
RFC6641 Using DNS SRV to Specify a Global File Namespace with NFS Version 4 C. Everhart W. Adamson J. Zhang June 2012 ASCII HTML 11 domainroot domain root file system

The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. [STANDARDS-TRACK]

draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6641
RFC6642 RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report Q. Wu Editor F. Xia R. Even June 2012 ASCII HTML 13 Feedback Suppression NACK Retransmission

In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]

draft-ietf-avtcore-feedback-supression-rtp-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6642
RFC6643 Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules J. Schoenwaelder July 2012 ASCII HTML 36 SMIv2 YANG data modeling

YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. [STANDARDS-TRACK]

draft-ietf-netmod-smi-yang-05 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6643 10.17487/RFC6643
RFC6644 Rebind Capability in DHCPv6 Reconfigure Messages D. Evans R. Droms S. Jiang July 2012 ASCII HTML 10 internet protocol parameters addresses

This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. [STANDARDS-TRACK]

draft-ietf-dhc-dhcpv6-reconfigure-rebind-10 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6644
RFC6645 IP Flow Information Accounting and Export Benchmarking Methodology J. Novak July 2012 ASCII HTML 39 Performance Flow monitoring IPFIX Netflow

This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow Information Export". The methodology quantifies the impact of the IP flow monitoring process on the network equipment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-ipflow-meth-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6645
RFC6646 DECoupled Application Data Enroute (DECADE) Problem Statement H. Song N. Zong Y. Yang R. Alimi July 2012 ASCII HTML 12 In-network storage P2P

Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-decade-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF tsv decade 10.17487/RFC6646
RFC6647 Email Greylisting: An Applicability Statement for SMTP M. Kucherawy D. Crocker June 2012 ASCII HTML 17 Email Greylisting Spam

This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.

Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]

draft-ietf-appsawg-greylisting-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6647
RFC6648 Deprecating the "X-" Prefix and Similar Constructs in Application Protocols P. Saint-Andre D. Crocker M. Nottingham June 2012 ASCII HTML 13

Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice.

draft-ietf-appsawg-xdash-05 BCP0178 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6648
RFC6649 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos L. Hornquist Astrand T. Yu July 2012 ASCII HTML 7

The Kerberos 5 network authentication protocol, originally specified in RFC 1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC 1510 (obsoleted by RFC 4120) supports only DES, this document recommends the reclassification of RFC 1510 as Historic. This memo documents an Internet Best Current Practice.

draft-ietf-krb-wg-des-die-die-die-04 RFC1510 RFC1964 RFC4120 RFC4121 RFC4757 BCP0179 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec krb-wg 10.17487/RFC6649
RFC6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) J. Falk M. Kucherawy Editor June 2012 ASCII HTML 15 marf spam reporting

RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. [STANDARDS-TRACK]

draft-ietf-marf-as-16 RFC5965 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6650
RFC6651 Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting M. Kucherawy June 2012 ASCII HTML 18 authentication fraud phishing spoofing

This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. [STANDARDS-TRACK]

draft-ietf-marf-dkim-reporting-16 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6651
RFC6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format S. Kitterman June 2012 ASCII HTML 8 fraud phishing spoofing

This memo presents extensions to the Abuse Reporting Format (ARF) and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.

This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. [STANDARDS-TRACK]

draft-ietf-marf-spf-reporting-11 RFC4408 PROPOSED STANDARD PROPOSED STANDARD IETF app marf 10.17487/RFC6652
RFC6653 DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks B. Sarikaya F. Xia T. Lemon July 2012 ASCII HTML 13

As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 Prefix Delegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to a DHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting (AAA) servers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sarikaya-v6ops-prefix-delegation-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6653
RFC6654 Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) T. Tsou C. Zhou T. Taylor Q. Chen July 2012 ASCII HTML 8 IPv6 transition

This document proposes an alternative IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator's IPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-tsou-softwire-gwinit-6rd-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6654
RFC6655 AES-CCM Cipher Suites for Transport Layer Security (TLS) D. McGrew D. Bailey July 2012 ASCII HTML 8 Authentication Encryption Advanced Encryption Standard (AES)

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message Authentication Code (CBC-MAC) Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. [STANDARDS-TRACK]

draft-mcgrew-tls-aes-ccm-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6655 10.17487/RFC6655
RFC6656 Description of Cisco Systems' Subnet Allocation Option for DHCPv4 R. Johnson K. Kinnear M. Stapp July 2012 ASCII HTML 24

This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the Cisco Systems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range 128-223 should be documented and that the working group will try to officially assign those numbers to those options. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dhc-subnet-alloc-13 INFORMATIONAL INFORMATIONAL IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6656 10.17487/RFC6656
RFC6657 Update to MIME regarding "charset" Parameter Handling in Textual Media Types A. Melnikov J. Reschke July 2012 ASCII HTML 6 MIME charset text

This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK]

draft-ietf-appsawg-mime-default-charset-04 RFC2046 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC6657
RFC6658 Packet Pseudowire Encapsulation over an MPLS PSN S. Bryant Editor L. Martini G. Swallow A. Malis July 2012 ASCII HTML 15

This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARDS-TRACK]

draft-ietf-pwe3-packet-pw-04 PROPOSED STANDARD PROPOSED STANDARD IETF int pwe3 10.17487/RFC6658
RFC6659 Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method A. Begen July 2012 ASCII HTML 12 IPTV FEC retransmission

The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avtext-rams-scenarios-05 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6659
RFC6660 Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP) B. Briscoe T. Moncaster M. Menth July 2012 ASCII HTML 24 Quality of Service QoS Congestion Control Congestion Notification Tunnelling Encapsulation & Decapsulation Differentiated Services Integrated Services Signalling Protocol Flow Admission Control Flow Termination

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.

This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked (NM), threshold-marked (ThM), and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC 5696. [STANDARDS-TRACK]

draft-ietf-pcn-3-in-1-encoding-11 RFC5696 PROPOSED STANDARD PROPOSED STANDARD IETF tsv pcn 10.17487/RFC6660
RFC6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation A. Charny F. Huang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII HTML 33 PCN controlled load CL boundary node behavior

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pcn-cl-edge-behaviour-14 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6661
RFC6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation A. Charny J. Zhang G. Karagiannis M. Menth T. Taylor Editor July 2012 ASCII HTML 31 PCN single marking SM edge node behavior

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pcn-sm-edge-behaviour-12 EXPERIMENTAL EXPERIMENTAL IETF tsv pcn 10.17487/RFC6662
RFC6663 Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain G. Karagiannis T. Taylor K. Chan M. Menth P. Eardley July 2012 ASCII HTML 7

Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN-domain: (1) PCN-feedback-information is carried from the PCN-egress-node to the Decision Point; (2) the Decision Point may ask the PCN-ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node. The Decision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, Controlled Load (CL) and Single Marking (SM). This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pcn-signaling-requirements-08 INFORMATIONAL INFORMATIONAL IETF tsv pcn 10.17487/RFC6663
RFC6664 S/MIME Capabilities for Public Key Definitions J. Schaad July 2012 ASCII HTML 19 OCSP CMS

This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. "Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pkix-pubkey-caps-07 INFORMATIONAL INFORMATIONAL IETF sec pkix 10.17487/RFC6664
RFC6665 SIP-Specific Event Notification A.B. Roach July 2012 ASCII HTML 53 SUBSCRIBE NOTIFY state

This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.

This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK]

draft-ietf-sipcore-rfc3265bis-09 RFC3265 RFC3261 RFC4660 RFC7621 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6665
RFC6666 A Discard Prefix for IPv6 N. Hilliard D. Freedman August 2012 ASCII HTML 6 RTBH black hole

Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 Special Purpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-ipv6-discard-prefix-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6666
RFC6667 LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements K. Raza S. Boutros C. Pignataro July 2012 ASCII HTML 8

The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a Typed Wildcard FEC Element must be individually defined for each FEC Element type. This specification defines the Typed Wildcard FEC Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK]

draft-ietf-pwe3-pw-typed-wc-fec-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6667
RFC6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol D. Bider M. Baushke July 2012 ASCII HTML 5

This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC 4253 by specifying a new RECOMMENDED data integrity algorithm. [STANDARDS-TRACK]

draft-dbider-sha2-mac-for-ssh-06 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6668
RFC6669 An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks N. Sprecher L. Fang July 2012 ASCII HTML 21

This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mpls-tp-oam-analysis-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6669 10.17487/RFC6669
RFC6670 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) N. Sprecher KY. Hong July 2012 ASCII HTML 33

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work on MPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.

During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.

One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sprecher-mpls-tp-oam-considerations-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6670
RFC6671 Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) M. Betts November 2012 ASCII HTML 5

This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, and Management (MPLS-TP OAM) messages in the MPLS Generic Associated Channel. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-betts-itu-oam-ach-code-point-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6671
RFC6672 DNAME Redirection in the DNS S. Rose W. Wijngaards June 2012 ASCII HTML 22

The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]

draft-ietf-dnsext-rfc2672bis-dname-26 RFC2672 RFC3363 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6672 10.17487/RFC6672
RFC6673 Round-Trip Packet Loss Metrics A. Morton August 2012 ASCII HTML 14 IP IPPM

Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.

This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). [STANDARDS-TRACK]

draft-ietf-ippm-rt-loss-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC6673
RFC6674 Gateway-Initiated Dual-Stack Lite Deployment F. Brockners S. Gundavelli S. Speicher D. Ward July 2012 ASCII HTML 15 GI-DS-Lite Gateway Initiated Dual-Stack Lite Dual-Stack Lite IPv6 Transitioning IPv6 Migration

Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]

draft-ietf-softwire-gateway-init-ds-lite-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC6674
RFC6675 A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP E. Blanton M. Allman L. Wang I. Jarvinen M. Kojo Y. Nishida August 2012 ASCII HTML 15 transmission control protocol retransmission congestion control

This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]

draft-ietf-tcpm-3517bis-02 RFC3517 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6675
RFC6676 Multicast Addresses for Documentation S. Venaas R. Parekh G. Van de Velde T. Chown M. Eubanks August 2012 ASCII HTML 7

This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mboned-mcaddrdoc-04 INFORMATIONAL INFORMATIONAL IETF ops mboned 10.17487/RFC6676
RFC6677 Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods S. Hartman Editor T. Clancy K. Hoeper July 2012 ASCII HTML 31

This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]

draft-ietf-emu-chbind-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC6677
RFC6678 Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method K. Hoeper S. Hanna H. Zhou J. Salowey Editor July 2012 ASCII HTML 23

This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-emu-eaptunnel-req-09 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC6678
RFC6679 Explicit Congestion Notification (ECN) for RTP over UDP M. Westerlund I. Johansson C. Perkins P. O'Hanlon K. Carlberg August 2012 ASCII HTML 58 ECN RTP UDP Congestion Control VoIP IPTV Packet Loss

This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK]

draft-ietf-avtcore-ecn-for-rtp-08 RFC8311 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=6679 10.17487/RFC6679
RFC6680 Generic Security Service Application Programming Interface (GSS-API) Naming Extensions N. Williams L. Johansson S. Hartman S. Josefsson August 2012 ASCII HTML 18

The Generic Security Service Application Programming Interface (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers.

draft-ietf-kitten-gssapi-naming-exts-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten http://www.rfc-editor.org/errata_search.php?rfc=6680 10.17487/RFC6680
RFC6681 Raptor Forward Error Correction (FEC) Schemes for FECFRAME M. Watson T. Stockhammer M. Luby August 2012 ASCII HTML 22

This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g., UDP) or using RTP. [STANDARDS-TRACK]

draft-ietf-fecframe-raptor-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6681
RFC6682 RTP Payload Format for Raptor Forward Error Correction (FEC) M. Watson T. Stockhammer M. Luby August 2012 ASCII HTML 18

This document specifies an RTP payload format for the Forward Error Correction (FEC) repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP. This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. [STANDARDS-TRACK]

draft-ietf-fecframe-rtp-raptor-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6682
RFC6683 Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection A. Begen T. Stockhammer August 2012 ASCII HTML 11 DVB FEC AL-FEC IPTV parity codes Raptor codes

Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward Error Correction (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-fecframe-dvb-al-fec-04 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6683
RFC6684 Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) B. Trammell July 2012 ASCII HTML 12 mile incident handling

This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-mile-template-05 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC6684
RFC6685 Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry B. Trammell July 2012 ASCII HTML 3 mile xml schema

This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to Incident Object Description Exchange Format (IODEF). [STANDARDS-TRACK]

draft-ietf-mile-iodef-xmlreg-01 RFC7970 RFC5070 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC6685
RFC6686 Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments M. Kucherawy July 2012 ASCII HTML 12 SPF Sender ID authentication authorization email

In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.

The IESG required all of these documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.

After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-spfbis-experiment-11 INFORMATIONAL INFORMATIONAL IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=6686 10.17487/RFC6686
RFC6687 Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) J. Tripathi Editor J. de Oliveira Editor JP. Vasseur Editor October 2012 ASCII PDF HTML 26 ROLL

This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-tripathi-roll-rpl-simulation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6687 10.17487/RFC6687
RFC6688 Parallel NFS (pNFS) Block Disk Protection D. Black Editor J. Glasgow S. Faibish July 2012 ASCII HTML 6 NFS NFSv4 pNFS SAN GPT

Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. [STANDARDS-TRACK]

draft-ietf-nfsv4-pnfs-block-disk-protection-03 RFC5663 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC6688
RFC6689 Usage of the RSVP ASSOCIATION Object L. Berger July 2012 ASCII HTML 11 Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ccamp-assoc-info-03 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC6689
RFC6690 Constrained RESTful Environments (CoRE) Link Format Z. Shelby August 2012 ASCII HTML 22 CoRE Link Format HTTP Link Header Format Resource Discovery

This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]

draft-ietf-core-link-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=6690 10.17487/RFC6690
RFC6691 TCP Options and Maximum Segment Size (MSS) D. Borman July 2012 ASCII HTML 9

This memo discusses what value to use with the TCP Maximum Segment Size (MSS) option, and updates RFC 879 and RFC 2385. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-tcpm-tcpmss-05 RFC0879 RFC2385 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC6691
RFC6692 Source Ports in Abuse Reporting Format (ARF) Reports R. Clayton M. Kucherawy July 2012 ASCII HTML 5 ARF ports reporting feedback

This document defines an additional header field for use in Abuse Reporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.

This document updates RFC 6591. [STANDARDS-TRACK]

draft-kucherawy-marf-source-ports-05 RFC6591 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6692
RFC6693 Probabilistic Routing Protocol for Intermittently Connected Networks A. Lindgren A. Doria E. Davies S. Grasic August 2012 ASCII HTML 113 DTN Routing PRoPHET

This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the \%best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. This document defines an Experimental Protocol for the Internet community.

draft-irtf-dtnrg-prophet-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6693
RFC6694 The "about" URI Scheme S. Moonesamy Editor August 2012 ASCII HTML 7

This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-appsawg-about-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC6694
RFC6695 Methods to Convey Forward Error Correction (FEC) Framework Configuration Information R. Asati August 2012 ASCII HTML 15

The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for the FEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time Streaming Protocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).

This document doesn't define any new signaling protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-fecframe-config-signaling-09 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6695
RFC6696 EAP Extensions for the EAP Re-authentication Protocol (ERP) Z. Cao B. He Y. Shi Q. Wu Editor G. Zorn Editor July 2012 ASCII HTML 47 EAP keying EMSK inter-authenticator roaming

The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. [STANDARDS-TRACK]

draft-ietf-hokey-rfc5296bis-07 RFC5296 PROPOSED STANDARD PROPOSED STANDARD IETF sec hokey 10.17487/RFC6696
RFC6697 Handover Keying (HOKEY) Architecture Design G. Zorn Editor Q. Wu T. Taylor Y. Nir K. Hoeper S. Decugis July 2012 ASCII HTML 20 Handover Keying Architecture Re-authentication Early authentication

The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.

This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-hokey-arch-design-11 INFORMATIONAL INFORMATIONAL IETF sec hokey 10.17487/RFC6697
RFC6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA P. Hoffman J. Schlyter August 2012 ASCII HTML 37 DNSSEC certificates public keys PKI

Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]

draft-ietf-dane-protocol-23 RFC7218 RFC7671 RFC8749 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=6698 10.17487/RFC6698
RFC6699 RFC6700 RFC6701 Sanctions Available for Application to Violators of IETF IPR Policy A. Farrel P. Resnick August 2012 ASCII HTML 12

The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.

The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.

This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-farrresnickel-ipr-sanctions-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6701
RFC6702 Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules T. Polk P. Saint-Andre August 2012 ASCII HTML 16

The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-polk-ipr-disclosure-05 RFC8717 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6702
RFC6703 Reporting IP Network Performance Metrics: Different Points of View A. Morton G. Ramachandran G. Maguluri August 2012 ASCII HTML 27 Loss Delay Delay Variation Capacity TCP

Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations (e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-reporting-metrics-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6703
RFC6704 Forcerenew Nonce Authentication D. Miles W. Dec J. Bristow R. Maglione August 2012 ASCII HTML 12 DHCP

Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In the Forcerenew Nonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. [STANDARDS-TRACK]

draft-ietf-dhc-forcerenew-nonce-07 RFC3203 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=6704 10.17487/RFC6704
RFC6705 Localized Routing for Proxy Mobile IPv6 S. Krishnan R. Koodli P. Loureiro Q. Wu A. Dutta September 2012 ASCII HTML 20 PMIPv6

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. [STANDARDS-TRACK]

draft-ietf-netext-pmip-lr-10 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6705
RFC6706 Asymmetric Extended Route Optimization (AERO) F. Templin Editor August 2012 ASCII HTML 33 route optimize optimization redirect redirection protocol routing link multi-access IPv6

Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios. This document therefore introduces an Asymmetric Extended Route Optimization (AERO) capability that addresses the issues. This document defines an Experimental Protocol for the Internet community.

draft-templin-aero-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6706 10.17487/RFC6706
RFC6707 Content Distribution Network Interconnection (CDNI) Problem Statement B. Niven-Jenkins F. Le Faucheur N. Bitar September 2012 ASCII HTML 32 Delivery CDN

Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.

The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-cdni-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6707
RFC6708 Application-Layer Traffic Optimization (ALTO) Requirements S. Kiesel Editor S. Previdi M. Stiemerling R. Woundy Y. Yang September 2012 ASCII HTML 20

Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.

This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-alto-reqs-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC6708
RFC6709 Design Considerations for Protocol Extensions B. Carpenter B. Aboba Editor S. Cheshire September 2012 ASCII HTML 42

This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-extension-recs-17 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6709
RFC6710 Simple Mail Transfer Protocol Extension for Message Transfer Priorities A. Melnikov K. Carlberg August 2012 ASCII HTML 28 SMTP priority MMHS

This memo defines an extension to the SMTP (Simple Mail Transfer Protocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. [STANDARDS-TRACK]

draft-melnikov-smtp-priority-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6710 10.17487/RFC6710
RFC6711 An IANA Registry for Level of Assurance (LoA) Profiles L. Johansson August 2012 ASCII HTML 7 Identity Assurance

This document establishes an IANA registry for Level of Assurance (LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 and OpenID Connect. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-johansson-loa-registry-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6711
RFC6712 Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) T. Kause M. Peylo September 2012 ASCII HTML 10 CMPtrans

This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]

draft-ietf-pkix-cmp-transport-protocols-20 RFC4210 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6712
RFC6713 The 'application/zlib' and 'application/gzip' Media Types J. Levine August 2012 ASCII HTML 4 compress deflate stream compression

This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-levine-application-gzip-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6713
RFC6714 Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) C. Holmberg S. Blau E. Burger August 2012 ASCII HTML 22 Middlebox IBCF SBC

This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. [STANDARDS-TRACK]

draft-ietf-simple-msrp-cema-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC6714
RFC6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group D. Cauchie B. Leiba K. Li August 2012 ASCII HTML 11 expertise hobby interest

This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance (OMA) Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. [STANDARDS-TRACK]

draft-ietf-vcarddav-oma-cab-extensions-03 PROPOSED STANDARD PROPOSED STANDARD IETF app vcarddav http://www.rfc-editor.org/errata_search.php?rfc=6715 10.17487/RFC6715
RFC6716 Definition of the Opus Audio Codec JM. Valin K. Vos T. Terriberry September 2012 ASCII HTML 326 voice music lossy compression VOIP

This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. [STANDARDS-TRACK]

draft-ietf-codec-opus-16 RFC8251 PROPOSED STANDARD PROPOSED STANDARD IETF rai codec http://www.rfc-editor.org/errata_search.php?rfc=6716 10.17487/RFC6716
RFC6717 kx509 Kerberized Certificate Issuance Protocol in Use in 2012 H. Hotz R. Allbery August 2012 ASCII HTML 13 Kerberos X.509 kx509 KCA kca-service kca_service

This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.

While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hotz-kx509-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6717
RFC6718 Pseudowire Redundancy P. Muley M. Aissaoui M. Bocci August 2012 ASCII HTML 18 Active standby protection dual-homing vpls vpws

This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pwe3-redundancy-09 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC6718
RFC6719 The Minimum Rank with Hysteresis Objective Function O. Gnawali P. Levis September 2012 ASCII HTML 13 Routing Protocol for Low Power and Lossy Networks RPL Low Power and Lossy Networks LLN

The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK]

draft-ietf-roll-minrank-hysteresis-of-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=6719 10.17487/RFC6719
RFC6720 The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) C. Pignataro R. Asati August 2012 ASCII HTML 8 GTSM LDP

The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router\'s IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).

This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. [STANDARDS-TRACK]

draft-ietf-mpls-ldp-gtsm-09 RFC5036 RFC7552 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6720
RFC6721 The Atom "deleted-entry" Element J. Snell September 2012 ASCII HTML 10 Atom Feed Entry Documents

This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. [STANDARDS-TRACK]

draft-snell-atompub-tombstones-18 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6721
RFC6722 Publishing the "Tao of the IETF" as a Web Page P. Hoffman Editor August 2012 ASCII HTML 3

This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-hoffman-tao-as-web-page-04 RFC4677 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6722
RFC6723 Update of the Pseudowire Control-Word Negotiation Mechanism L. Jin Editor R. Key Editor S. Delord T. Nadeau S. Boutros September 2012 ASCII HTML 9 control word control word negotiation control word renegotiation control word negotiation mechanism control word renegotiation mechanism

The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. [STANDARDS-TRACK]

draft-ietf-pwe3-cbit-negotiation-05 RFC8077 RFC4447 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC6723
RFC6724 Default Address Selection for Internet Protocol Version 6 (IPv6) D. Thaler Editor R. Draves A. Matsumoto T. Chown September 2012 ASCII HTML 32 source destination sort sorting

This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.

Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]

draft-ietf-6man-rfc3484bis-06 RFC3484 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6724 10.17487/RFC6724
RFC6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates S. Rose August 2012 ASCII HTML 5

The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry. This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK]

draft-ietf-dnsext-dnssec-registry-update-04 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6725
RFC6726 FLUTE - File Delivery over Unidirectional Transport T. Paila R. Walsh M. Luby V. Roca R. Lehtonen November 2012 ASCII HTML 46 Multicast

This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]

draft-ietf-rmt-flute-revised-16 RFC3926 PROPOSED STANDARD PROPOSED STANDARD IETF tsv rmt http://www.rfc-editor.org/errata_search.php?rfc=6726 10.17487/RFC6726
RFC6727 Definitions of Managed Objects for Packet Sampling T. Dietz Editor B. Claise J. Quittek October 2012 ASCII HTML 28 PSAMP IPFIX MIB Sampling Filtering Selection

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX-SELECTOR-MIB module. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP- MIB module containing managed objects for providing information on applied packet selection functions and their parameters. [STANDARDS-TRACK]

draft-ietf-ipfix-psamp-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC6727
RFC6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols G. Muenz B. Claise P. Aitken October 2012 ASCII HTML 129

This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF). The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). [STANDARDS-TRACK]

draft-ietf-ipfix-configuration-model-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=6728 10.17487/RFC6728
RFC6729 Indicating Email Handling States in Trace Fields D. Crocker M. Kucherawy September 2012 ASCII HTML 12 Quarantine Moderation

This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. [STANDARDS-TRACK]

draft-ietf-appsawg-received-state-04 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6729 10.17487/RFC6729
RFC6730 Requirements for IETF Nominations Committee Tools S. Krishnan J. Halpern September 2012 ASCII HTML 10

This document defines the requirements for a set of tools for use by the IETF Nominations Committee. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-krishnan-nomcom-tools-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6730
RFC6731 Improved Recursive DNS Server Selection for Multi-Interfaced Nodes T. Savolainen J. Kato T. Lemon December 2012 ASCII HTML 29 DNS RDNSS interface FQDN selection

A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. [STANDARDS-TRACK]

draft-ietf-mif-dns-server-selection-12 PROPOSED STANDARD PROPOSED STANDARD IETF int mif 10.17487/RFC6731
RFC6732 6to4 Provider Managed Tunnels V. Kuarsingh Editor Y. Lee O. Vautrin September 2012 ASCII HTML 12 6to4-PMT

6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07 RFC7526 HISTORIC INFORMATIONAL INDEPENDENT 10.17487/RFC6732
RFC6733 Diameter Base Protocol V. Fajardo Editor J. Arkko J. Loughney G. Zorn Editor October 2012 ASCII HTML 152 Diameter AAA

The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]

draft-ietf-dime-rfc3588bis-33 RFC3588 RFC5719 RFC7075 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6733 10.17487/RFC6733
RFC6734 Diameter Attribute-Value Pairs for Cryptographic Key Transport G. Zorn Q. Wu V. Cakulev October 2012 ASCII HTML 7 AAA,ERP,MSK

Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. [STANDARDS-TRACK]

draft-ietf-dime-local-keytran-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6734
RFC6735 Diameter Priority Attribute-Value Pairs K. Carlberg Editor T. Taylor October 2012 ASCII HTML 10 AVP

This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the Authentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. [STANDARDS-TRACK]

draft-ietf-dime-priority-avps-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=6735 10.17487/RFC6735
RFC6736 Diameter Network Address and Port Translation Control Application F. Brockners S. Bhandari V. Singh V. Fajardo October 2012 ASCII HTML 58 NAT control NAT44 NAT66 CGN BNG

This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a Network Address Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. [STANDARDS-TRACK]

draft-ietf-dime-nat-control-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6736
RFC6737 The Diameter Capabilities Update Application K. Jiao G. Zorn October 2012 ASCII HTML 6

This document defines a new Diameter application and associated Command Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. [STANDARDS-TRACK]

draft-ietf-dime-capablities-update-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6737
RFC6738 Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers V. Cakulev A. Lior S. Mizikovsky October 2012 ASCII HTML 17 Internet Key Exchange Protocol version 2

The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).

Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. [STANDARDS-TRACK]

draft-ietf-dime-ikev2-psk-diameter-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6738
RFC6739 Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol H. Schulzrinne H. Tschofenig October 2012 ASCII HTML 25 Location

The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.

The <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ecrit-lost-sync-18 EXPERIMENTAL EXPERIMENTAL IETF rai ecrit http://www.rfc-editor.org/errata_search.php?rfc=6739 10.17487/RFC6739
RFC6740 Identifier-Locator Network Protocol (ILNP) Architectural Description RJ Atkinson SN Bhatti November 2012 ASCII HTML 53

This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-arch-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6740 10.17487/RFC6740
RFC6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations RJ Atkinson SN Bhatti November 2012 ASCII HTML 38

This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-eng-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6741
RFC6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti S. Rose November 2012 ASCII HTML 20

This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-dns-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6742 10.17487/RFC6742
RFC6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII HTML 12

This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-icmpv6-06 EXPERIMENTAL EXPERIMENTAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=6743 10.17487/RFC6743
RFC6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) RJ Atkinson SN Bhatti November 2012 ASCII HTML 14

The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-noncev6-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6744
RFC6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII HTML 12

This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-icmpv4-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6745
RFC6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII HTML 11

This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-v4opts-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6746
RFC6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) RJ Atkinson SN Bhatti November 2012 ASCII HTML 12

This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-arp-07 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6747
RFC6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) RJ Atkinson SN Bhatti November 2012 ASCII HTML 37

This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. This document defines an Experimental Protocol for the Internet community.

draft-irtf-rrg-ilnp-adv-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC6748
RFC6749 The OAuth 2.0 Authorization Framework D. Hardt Editor October 2012 ASCII HTML 76 Client Resource Owner Authorization Server Resource Server Token Endpoint Authorization Endpoint Authorization Request Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier Access Token Scope Delegation

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]

draft-ietf-oauth-v2-31 RFC5849 RFC8252 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6749 10.17487/RFC6749
RFC6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage M. Jones D. Hardt October 2012 ASCII HTML 18 Client Resource Owner Authorization Server Resource Server, Token Endpoint Authorization Endpoint Authorization Request, Authorization Grant Protected Resource Access Token Refresh Token Authorization Code Implicit Grant Client Identifier, Access Token Scope Bearer Authorization Header Bearer Access Token Type

This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]

draft-ietf-oauth-v2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6750 10.17487/RFC6750
RFC6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) R. Despres Editor B. Carpenter D. Wing S. Jiang October 2012 ASCII HTML 33 Coexistence Transition Interworking Tunneling Encapsulation Mapping map-and-encap Global Addressing

In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. This document defines an Experimental Protocol for the Internet community.

draft-despres-6a44-02 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6751 10.17487/RFC6751
RFC6752 Issues with Private IP Addressing in the Internet A. Kirkham September 2012 ASCII HTML 14

The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-private-ip-sp-cores-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6752
RFC6753 A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) J. Winterbottom H. Tschofenig H. Schulzrinne M. Thomson October 2012 ASCII HTML 25 HELD Dereference lbyr HTTP Location GEOPRIV

This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK]

draft-ietf-geopriv-deref-protocol-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6753
RFC6754 Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect Y. Cai L. Wei H. Ou V. Arya S. Jethwani October 2012 ASCII HTML 12

A Protocol Independent Multicast (PIM) router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. [STANDARDS-TRACK]

draft-ietf-pim-ecmp-05 RFC8736 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC6754
RFC6755 An IETF URN Sub-Namespace for OAuth B. Campbell H. Tschofenig October 2012 ASCII HTML 5 OAuth URN sub-namespace urn:ietf:params:oauth

This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-oauth-urn-sub-ns-06 INFORMATIONAL INFORMATIONAL IETF sec oauth 10.17487/RFC6755
RFC6756 Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines S. Trowbridge Editor E. Lear Editor G. Fishman Editor S. Bradner Editor September 2012 ASCII HTML 16

This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012).

Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations.

This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-rfc3356bis-05 RFC3356 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=6756 10.17487/RFC6756
RFC6757 Access Network Identifier (ANI) Option for Proxy Mobile IPv6 S. Gundavelli Editor J. Korhonen Editor M. Grayson K. Leung R. Pazhyannur October 2012 ASCII HTML 19 ANI ANI option Access Network Identifier option PMIPv6 ANI option

The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. [STANDARDS-TRACK]

draft-ietf-netext-access-network-option-13 RFC7563 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6757
RFC6758 Tunneling of SMTP Message Transfer Priorities A. Melnikov K. Carlberg October 2012 ASCII HTML 11 Priority MMHS

This memo defines a mechanism for tunneling of SMTP (Simple Mail Transfer Protocol) Message Transfer Priority values through MTAs (Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-melnikov-smtp-priority-tunneling-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6758
RFC6759 Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) B. Claise P. Aitken N. Ben-Dvora November 2012 ASCII HTML 43

This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-claise-export-application-info-in-ipfix-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6759 10.17487/RFC6759
RFC6760 Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) S. Cheshire M. Krochmal February 2013 ASCII HTML 16

One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was to retire AppleTalk and the AppleTalk Name Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement.

draft-cheshire-dnsext-nbp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6760
RFC6761 Special-Use Domain Names S. Cheshire M. Krochmal February 2013 ASCII HTML 13

This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

draft-cheshire-dnsext-special-names-03 RFC1918 RFC2606 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6761 10.17487/RFC6761
RFC6762 Multicast DNS S. Cheshire M. Krochmal February 2013 ASCII HTML 70

As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.

Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.

The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.

draft-cheshire-dnsext-multicastdns-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6762 10.17487/RFC6762
RFC6763 DNS-Based Service Discovery S. Cheshire M. Krochmal February 2013 ASCII HTML 49

This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.

draft-cheshire-dnsext-dns-sd-11 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6763 10.17487/RFC6763
RFC6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) C. Daboo February 2013 ASCII HTML 14 SRV iCalendar

This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.

draft-daboo-srv-caldav-10 RFC4791 RFC6352 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6764
RFC6765 xDSL Multi-Pair Bonding (G.Bond) MIB E. Beili M. Morgenstern February 2013 ASCII HTML 73 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998 G.998.1 G.998.2 G.998.3 TDIM IMA EFM

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separate MIB module maintained by Internet Assigned Numbers Authority (IANA). The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB, and G9983-MIB, respectively.

draft-ietf-adslmib-gbond-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6765 10.17487/RFC6765
RFC6766 xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB E. Beili February 2013 ASCII HTML 55 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding aggregation G.998.3

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), as defined in ITU-T Recommendation G.998.3.

draft-ietf-adslmib-gbond-tdim-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6766 10.17487/RFC6766
RFC6767 Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB E. Beili M. Morgenstern February 2013 ASCII HTML 53 Network Management Simple Network Management Protocol SNMP Management Information Base xDSL bonding Ethernet bonding aggregation 802.3ah G.998.2

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded Digital Subscriber Line (xDSL) interfaces, as defined in ITU-T Recommendation G.998.2.

draft-ietf-adslmib-gbond-eth-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6767 10.17487/RFC6767
RFC6768 ATM-Based xDSL Bonded Interfaces MIB E. Beili February 2013 ASCII HTML 34 Network Management Simple Network Management Protocol SNMP Management Information Base bonding xDSL bonding aggregation G.Bond G.Bond/ATM G.998.1 IMA IMA+

This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1.

draft-ietf-adslmib-gbond-atm-mib-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops adslmib http://www.rfc-editor.org/errata_search.php?rfc=6768 10.17487/RFC6768
RFC6769 Simple Virtual Aggregation (S-VA) R. Raszuk J. Heitz A. Lo L. Zhang X. Xu October 2012 ASCII HTML 8 BGP aggregation

All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into the Forwarding Information Base (FIB).

Some routers in an Autonomous System (AS) announce an aggregate (the VA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.

The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-simple-va-12 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6769
RFC6770 Use Cases for Content Delivery Network Interconnection G. Bertrand Editor E. Stephan T. Burbridge P. Eardley K. Ma G. Watson November 2012 ASCII HTML 16 CDN CDNI

Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-cdni-use-cases-10 RFC3570 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC6770
RFC6771 Considerations for Having a Successful "Bar BOF" Side Meeting L. Eggert G. Camarillo October 2012 ASCII HTML 10

New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.

During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.

This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-eggert-successful-bar-bof-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6771
RFC6772 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information H. Schulzrinne Editor H. Tschofenig Editor J. Cuellar J. Polk J. Morris M. Thomson January 2013 ASCII HTML 44 Authorization Policy Location Privacy

This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.

Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK]

draft-ietf-geopriv-policy-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6772
RFC6773 DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal T. Phelan G. Fairhurst C. Perkins November 2012 ASCII HTML 20 DCCP NAPT NAT UDP

This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK]

draft-ietf-dccp-udpencap-11 RFC4340 RFC5762 PROPOSED STANDARD PROPOSED STANDARD IETF tsv dccp http://www.rfc-editor.org/errata_search.php?rfc=6773 10.17487/RFC6773
RFC6774 Distribution of Diverse BGP Paths R. Raszuk Editor R. Fernando K. Patel D. McPherson K. Kumaki November 2012 ASCII HTML 22

The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.

The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, the Nth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.

This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge (PE) routers acting as route reflector clients. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-grow-diverse-bgp-path-dist-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC6774
RFC6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) Z. Shelby Editor S. Chakrabarti E. Nordmark C. Bormann November 2012 ASCII HTML 55

The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]

draft-ietf-6lowpan-nd-21 RFC4944 RFC8505 RFC8929 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lowpan 10.17487/RFC6775
RFC6776 Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block A. Clark Q. Wu October 2012 ASCII HTML 9 RTP Control Protocol

This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK]

draft-ietf-xrblock-rtcp-xr-meas-identity-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6776
RFC6777 Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks W. Sun Editor G. Zhang Editor J. Gao G. Xie R. Papneja November 2012 ASCII HTML 29 Provisioning performance Performance measurement UNI Bandwidth on Demand performance evaluation Measurement methodologies

When setting up a Label Switched Path (LSP) in Generalized MPLS (GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and use LSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. [STANDARDS-TRACK]

draft-ietf-ccamp-dpm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6777
RFC6778 Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching R. Sparks October 2012 ASCII HTML 8 tool

The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-sparks-genarea-mailarch-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6778
RFC6779 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres October 2012 ASCII HTML 67 Network Management Management Information base MIB SMIv2 Routing Neighbor Discovery MANET

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. [STANDARDS-TRACK]

draft-ietf-manet-nhdp-mib-19 RFC7939 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC6779
RFC6780 RSVP ASSOCIATION Object Extensions L. Berger F. Le Faucheur A. Narayanan October 2012 ASCII HTML 17

The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]

draft-ietf-ccamp-assoc-ext-06 RFC2205 RFC3209 RFC3473 RFC4872 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6780
RFC6781 DNSSEC Operational Practices, Version 2 O. Kolkman W. Mekking R. Gieben December 2012 ASCII HTML 71 DNSSEC operational key rollover

This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.

The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.

This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.

draft-ietf-dnsop-rfc4641bis-13 RFC4641 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=6781 10.17487/RFC6781
RFC6782 Wireline Incremental IPv6 V. Kuarsingh Editor L. Howard November 2012 ASCII HTML 29 transition IPv6 transition operator

Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-v6ops-wireline-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6782
RFC6783 Mailing Lists and Non-ASCII Addresses J. Levine R. Gellens November 2012 ASCII HTML 9 Mail internationalization mailing lists

This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. This document is a product of the Internet Engineering Task Force (IETF).

draft-ietf-eai-mailinglistbis-05 RFC5983 INFORMATIONAL INFORMATIONAL IETF app eai 10.17487/RFC6783
RFC6784 Kerberos Options for DHCPv6 S. Sakane M. Ishiyama November 2012 ASCII HTML 12 security dhcpv6

This document defines four new options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. [STANDARDS-TRACK]

draft-sakane-dhc-dhcpv6-kdc-option-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6784
RFC6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve B. Leiba November 2012 ASCII HTML 20 email filtering

Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. [STANDARDS-TRACK]

draft-ietf-sieve-imap-sieve-09 RFC5228 PROPOSED STANDARD PROPOSED STANDARD IETF app sieve 10.17487/RFC6785
RFC6786 Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs A. Yegin R. Cragie November 2012 ASCII HTML 11

This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form. [STANDARDS-TRACK]

draft-yegin-pana-encr-avp-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6786
RFC6787 Media Resource Control Protocol Version 2 (MRCPv2) D. Burnett S. Shanmugham November 2012 ASCII HTML 224 mrcp speechsc asr tts speech services speech recognition speech synthesis nlsml speaker authentication speaker verification speaker identification

The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK]

draft-ietf-speechsc-mrcpv2-28 PROPOSED STANDARD PROPOSED STANDARD IETF rai speechsc http://www.rfc-editor.org/errata_search.php?rfc=6787 10.17487/RFC6787
RFC6788 The Line-Identification Option S. Krishnan A. Kavanagh B. Varga S. Ooghe E. Nordmark November 2012 ASCII HTML 17

In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router. This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]

draft-ietf-6man-lineid-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6788
RFC6789 Congestion Exposure (ConEx) Concepts and Use Cases B. Briscoe Editor R. Woundy Editor A. Cooper Editor December 2012 ASCII HTML 17 Congestion Signaling Traffic Management

This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-conex-concepts-uses-05 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC6789
RFC6790 The Use of Entropy Labels in MPLS Forwarding K. Kompella J. Drake S. Amante W. Henderickx L. Yong November 2012 ASCII HTML 25 entropy hash ecmp load balancing

Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]

draft-ietf-mpls-entropy-label-06 RFC3031 RFC3107 RFC3209 RFC5036 RFC7274 RFC7447 RFC8012 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=6790 10.17487/RFC6790
RFC6791 Stateless Source Address Mapping for ICMPv6 Packets X. Li C. Bao D. Wing R. Vaithianathan G. Huston November 2012 ASCII HTML 6 IP/ICMP Translation Algorithm IPv4-translatable IPv6 addresses ICMPv6 traceroute

A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK]

draft-ietf-v6ops-ivi-icmp-address-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC6791
RFC6792 Guidelines for Use of the RTP Monitoring Framework Q. Wu Editor G. Hunt P. Arden November 2012 ASCII HTML 17 Real Time Control Protocol

This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avtcore-monarch-22 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC6792
RFC6793 BGP Support for Four-Octet Autonomous System (AS) Number Space Q. Vohra E. Chen December 2012 ASCII HTML 12 autonomous system border gateway protocol

The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]

draft-ietf-idr-rfc4893bis-07 RFC4893 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=6793 10.17487/RFC6793
RFC6794 A Framework for Session Initiation Protocol (SIP) Session Policies V. Hilt G. Camarillo J. Rosenberg December 2012 ASCII HTML 36

Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. [STANDARDS-TRACK]

draft-ietf-sip-session-policy-framework-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sip 10.17487/RFC6794
RFC6795 A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies V. Hilt G. Camarillo December 2012 ASCII HTML 18

This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. [STANDARDS-TRACK]

draft-ietf-sipping-policy-package-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipping 10.17487/RFC6795
RFC6796 A User Agent Profile Data Set for Media Policy V. Hilt G. Camarillo J. Rosenberg D. Worley December 2012 ASCII HTML 43 SIP Session Policy Data Set

This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. [STANDARDS-TRACK]

draft-camarillo-rai-media-policy-dataset-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6796
RFC6797 HTTP Strict Transport Security (HSTS) J. Hodges C. Jackson A. Barth November 2012 ASCII HTML 46 HTTPS TLS SSL ForceHTTPS man-in-the-middle MITM certificate error certificate verification security policy secure transport IDNA-Canonicalization

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]

draft-ietf-websec-strict-transport-sec-14 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=6797 10.17487/RFC6797
RFC6798 RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting A. Clark Q. Wu November 2012 ASCII HTML 13

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK]

draft-ietf-xrblock-rtcp-xr-pdv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6798
RFC6799 RFC6800 RFC6801 Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework U. Kozat A. Begen November 2012 ASCII HTML 11

This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-fecframe-pseudo-cdp-05 INFORMATIONAL INFORMATIONAL IETF tsv fecframe 10.17487/RFC6801
RFC6802 Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets S. Baillargeon C. Flinta A. Johnsson November 2012 ASCII HTML 15 available capacity rate train interval padding buffer test session

This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-twamp-value-added-octets-09 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6802
RFC6803 Camellia Encryption for Kerberos 5 G. Hudson November 2012 ASCII HTML 13 Camellia Kerberos

This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961. The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-krb-wg-camellia-cts-02 INFORMATIONAL INFORMATIONAL IETF sec krb-wg http://www.rfc-editor.org/errata_search.php?rfc=6803 10.17487/RFC6803
RFC6804 DISCOVER: Supporting Multicast DNS Queries B. Manning November 2012 ASCII HTML 9

This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the Topology Based Domain Search (TBDS) project. This project is no longer active and there are no current plans to restart it. TBDS was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. This document defines a Historic Document for the Internet community.

draft-manning-opcode-discover-07 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC6804
RFC6805 The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS D. King Editor A. Farrel Editor November 2012 ASCII HTML 33

Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture.

Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.

This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-pce-hierarchy-fwk-05 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC6805
RFC6806 Kerberos Principal Name Canonicalization and Cross-Realm Referrals S. Hartman Editor K. Raeburn L. Zhu November 2012 ASCII HTML 19 authentication security protocols identity

This memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm Ticket-Granting Ticket (TGT) to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. [STANDARDS-TRACK]

draft-ietf-krb-wg-kerberos-referrals-15 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6806
RFC6807 Population Count Extensions to Protocol Independent Multicast (PIM) D. Farinacci G. Shepherd S. Venaas Y. Cai December 2012 ASCII HTML 15

This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the Protocol Independent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. This document defines an Experimental Protocol for the Internet community.

draft-ietf-pim-pop-count-07 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC6807
RFC6808 Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser December 2012 ASCII HTML 29 One-way Delay IP Performance Metrics IPPM

This memo provides the supporting test plan and results to advance RFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-ippm-testplan-rfc2679-03 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC6808
RFC6809 Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek H. Kaplan November 2012 ASCII HTML 19 proxy feature feature tag feature-capability indicator Feature-Caps capability

This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field.

SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.

This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK]

draft-ietf-sipcore-proxy-feature-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC6809
RFC6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush R. Austein January 2013 ASCII HTML 27

In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK]

draft-ietf-sidr-rpki-rtr-26 RFC8210 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6810
RFC6811 BGP Prefix Origin Validation P. Mohapatra J. Scudder D. Ward R. Bush R. Austein January 2013 ASCII HTML 10 SIDR security

To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination Autonomous System (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. [STANDARDS-TRACK]

draft-ietf-sidr-pfx-validate-10 RFC8481 RFC8893 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6811
RFC6812 Cisco Service-Level Assurance Protocol M. Chiba A. Clemm S. Medley J. Salowey S. Thombare E. Yedavalli January 2013 ASCII HTML 27 Cisco's SLA Protocol

Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is a Performance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-cisco-sla-protocol-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6812
RFC6813 The Network Endpoint Assessment (NEA) Asokan Attack Analysis J. Salowey S. Hanna December 2012 ASCII HTML 8 Man-in-the-Middle MITM Security Endpoint Posture Protocol Forwarding TNC Channel Binding Cryptographic Countermeasure

The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes the attack and countermeasures that may be mounted. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-nea-asokan-02 INFORMATIONAL INFORMATIONAL IETF sec nea 10.17487/RFC6813
RFC6814 Formally Deprecating Some IPv4 Options C. Pignataro F. Gont November 2012 ASCII HTML 6

A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry. Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. [STANDARDS-TRACK]

draft-gp-intarea-obsolete-ipv4-options-iana-02 RFC1385 RFC1393 RFC1475 RFC1770 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6814
RFC6815 Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful S. Bradner K. Dubray J. McQuaid A. Morton November 2012 ASCII HTML 11 testing performance

The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-bmwg-2544-as-08 RFC2544 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6815
RFC6816 Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan December 2012 ASCII HTML 24 Forward Error Correction LDPC-Staircase

This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.

draft-ietf-fecframe-ldpc-04 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6816
RFC6817 Low Extra Delay Background Transport (LEDBAT) S. Shalunov G. Hazel J. Iyengar M. Kuehlewind December 2012 ASCII HTML 25 Congestion control delay-based scavenger P2P

Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community.

draft-ietf-ledbat-congestion-10 EXPERIMENTAL EXPERIMENTAL IETF tsv ledbat 10.17487/RFC6817
RFC6818 Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile P. Yee January 2013 ASCII HTML 8

This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK]

draft-ietf-pkix-rfc5280-clarifications-11 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix 10.17487/RFC6818
RFC6819 OAuth 2.0 Threat Model and Security Considerations T. Lodderstedt Editor M. McGloin P. Hunt January 2013 ASCII HTML 71 authorization authentication token counter-measures HTTP REST

This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-oauth-v2-threatmodel-08 INFORMATIONAL INFORMATIONAL IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=6819 10.17487/RFC6819
RFC6820 Address Resolution Problems in Large Data Center Networks T. Narten M. Karir I. Foo January 2013 ASCII HTML 17 ARMD data center ARP ND Neighbor Discovery

This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution (the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery (ND) in IPv6) within a data center. This document is a product of the Internet Engineering Task Force (IETF).

draft-ietf-armd-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF ops armd 10.17487/RFC6820
RFC6821 Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality E. Marocco A. Fusco I. Rimac V. Gurbani December 2012 ASCII HTML 16 cross-domain traffic bandwidth transit traffic peer-to-peer caching peer-to-peer swarm

Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.

This document is a product of the IRTF P2PRG (Peer-to-Peer Research Group).

draft-irtf-p2prg-mythbustering-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6821
RFC6822 IS-IS Multi-Instance S. Previdi Editor L. Ginsberg M. Shand A. Roy D. Ward December 2012 ASCII HTML 14 intermediate system to intermediate system

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.

Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.

draft-ietf-isis-mi-08 RFC8202 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=6822 10.17487/RFC6822
RFC6823 Advertising Generic Information in IS-IS L. Ginsberg S. Previdi M. Shand December 2012 ASCII HTML 11 intermediate system to intermediate system

This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.

draft-ietf-isis-genapp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC6823
RFC6824 TCP Extensions for Multipath Operation with Multiple Addresses A. Ford C. Raiciu M. Handley O. Bonaventure January 2013 ASCII HTML 64

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.

Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.

draft-ietf-mptcp-multiaddressed-12 RFC8684 EXPERIMENTAL EXPERIMENTAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=6824 10.17487/RFC6824
RFC6825 Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS M. Miyazawa T. Otani K. Kumaki T. Nadeau January 2013 ASCII HTML 40 TED-MIB ted mib

This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. [STANDARDS-TRACK]

draft-ietf-ccamp-gmpls-ted-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6825
RFC6826 Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths IJ. Wijnands Editor T. Eckert N. Leymann M. Napierala January 2013 ASCII HTML 12

Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), that needs to pass through an MPLS domain in which Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. [STANDARDS-TRACK]

draft-ietf-mpls-mldp-in-band-signaling-08 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6826
RFC6827 Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols A. Malis Editor A. Lindem Editor D. Papadimitriou Editor January 2013 ASCII HTML 30

The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]

draft-ietf-ccamp-rfc5787bis-06 RFC5787 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6827
RFC6828 Content Splicing for RTP Sessions J. Xia January 2013 ASCII HTML 17

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.

This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-avtext-splicing-for-rtp-12 INFORMATIONAL INFORMATIONAL IETF rai avtext 10.17487/RFC6828
RFC6829 Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 M. Chen P. Pan C. Pignataro R. Asati January 2013 ASCII HTML 8

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.

This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6 LDP sessions. This document updates RFC 4379. [STANDARDS-TRACK]

draft-ietf-mpls-ipv6-pw-lsp-ping-04 RFC8029 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6829
RFC6830 The Locator/ID Separation Protocol (LISP) D. Farinacci V. Fuller D. Meyer D. Lewis January 2013 ASCII HTML 75

This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.

Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-24 RFC8113 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6830
RFC6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments D. Farinacci D. Meyer J. Zwiebel S. Venaas January 2013 ASCII HTML 28

This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-multicast-14 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6831
RFC6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites D. Lewis D. Meyer D. Farinacci V. Fuller January 2013 ASCII HTML 19

This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network Address Translation (NAT) functionality to LISP ITRs and LISP Egress Tunnel Routers (ETRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-interworking-06 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6832
RFC6833 Locator/ID Separation Protocol (LISP) Map-Server Interface V. Fuller D. Farinacci January 2013 ASCII HTML 13

This document describes the Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases.

By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-ms-16 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6833
RFC6834 Locator/ID Separation Protocol (LISP) Map-Versioning L. Iannone D. Saucez O. Bonaventure January 2013 ASCII HTML 21

This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-map-versioning-09 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6834
RFC6835 The Locator/ID Separation Protocol Internet Groper (LIG) D. Farinacci D. Meyer January 2013 ASCII HTML 12

A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-lisp-lig-06 INFORMATIONAL INFORMATIONAL IETF int lisp 10.17487/RFC6835
RFC6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) V. Fuller D. Farinacci D. Meyer D. Lewis January 2013 ASCII HTML 25

This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.

draft-ietf-lisp-alt-11 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC6836
RFC6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database E. Lear January 2013 ASCII HTML 31

The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to- RLOC mappings scales well to at least 10^8 entries. This document defines an Experimental Protocol for the Internet community.

draft-lear-lisp-nerd-09 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6837
RFC6838 Media Type Specifications and Registration Procedures N. Freed J. Klensin T. Hansen January 2013 ASCII HTML 32

This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.

draft-ietf-appsawg-media-type-regs-14 RFC4288 BCP0013 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg 10.17487/RFC6838
RFC6839 Additional Media Type Structured Syntax Suffixes T. Hansen A. Melnikov January 2013 ASCII HTML 14 structured syntax suffix media type

A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-appsawg-media-type-suffix-regs-08 RFC3023 RFC7303 INFORMATIONAL INFORMATIONAL IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6839 10.17487/RFC6839
RFC6840 Clarifications and Implementation Notes for DNS Security (DNSSEC) S. Weiler Editor D. Blacka Editor February 2013 ASCII HTML 21 EAP AAA reconnect

This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.

This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.

draft-ietf-dnsext-dnssec-bis-updates-20 RFC4033 RFC4034 RFC4035 RFC5155 RFC8749 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6840 10.17487/RFC6840
RFC6841 A Framework for DNSSEC Policies and DNSSEC Practice Statements F. Ljunggren AM. Eklund Lowinder T. Okubo January 2013 ASCII HTML 27 DNS DNSSEC DP DPS

This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.

In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ietf-dnsop-dnssec-dps-framework-11 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC6841
RFC6842 Client Identifier Option in DHCP Server Replies N. Swamy G. Halwasia P. Jhingran January 2013 ASCII HTML 5

This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. [STANDARDS-TRACK]

draft-ietf-dhc-client-id-07 RFC2131 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6842
RFC6843 RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting A. Clark K. Gross Q. Wu January 2013 ASCII HTML 9 Round Trip Delay End System Delay

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]

draft-ietf-xrblock-rtcp-xr-delay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6843
RFC6844 DNS Certification Authority Authorization (CAA) Resource Record P. Hallam-Baker R. Stradling January 2013 ASCII HTML 18 DNS DNSSEC PKIX

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]

draft-ietf-pkix-caa-15 RFC8659 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6844 10.17487/RFC6844
RFC6845 OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type N. Sheth L. Wang J. Zhang January 2013 ASCII HTML 9 OSPF P2MP Broadcast Interface

This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.

This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [STANDARDS-TRACK]

draft-ietf-ospf-hybrid-bcast-and-p2mp-06 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC6845
RFC6846 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) G. Pelletier K. Sandlund L-E. Jonsson M. West January 2013 ASCII HTML 96

This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.

ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common.

This specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. [STANDARDS-TRACK]

draft-sandlund-rfc4996bis-02 RFC4996 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6846 10.17487/RFC6846
RFC6847 Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) D. Melman T. Mizrahi D. Eastlake 3rd January 2013 ASCII HTML 13 FCoE FCRB TRILL RBridge

Fibre Channel over Ethernet (FCoE) and Transparent Interconnection of Lots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's Media Access Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-mme-trill-fcoe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6847
RFC6848 Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO) J. Winterbottom M. Thomson R. Barnes B. Rosen R. George January 2013 ASCII HTML 21 Extension Local Civic Location GEOPRIV

New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. [STANDARDS-TRACK]

draft-ietf-geopriv-local-civic-10 RFC4776 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6848
RFC6849 An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback H. Kaplan Editor K. Hedayat N. Venna P. Jones N. Stratton February 2013 ASCII HTML 33 multimedia audio video RTCP diagnostic voip

The wide deployment of Voice over IP (VoIP), real-time text, and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real-time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics.

draft-ietf-mmusic-media-loopback-27 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6849
RFC6850 Definitions of Managed Objects for Routing Bridges (RBridges) A. Rijhsinghani K. Zebrose January 2013 ASCII HTML 59

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. [STANDARDS-TRACK]

draft-ietf-trill-rbridge-mib-10 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC6850
RFC6851 Internet Message Access Protocol (IMAP) - MOVE Extension A. Gulbrandsen N. Freed Editor January 2013 ASCII HTML 8 IMAP

This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK]

draft-ietf-imapmove-command-05 PROPOSED STANDARD PROPOSED STANDARD IETF app imapmove 10.17487/RFC6851
RFC6852 Affirmation of the Modern Paradigm for Standards R. Housley S. Mills J. Jaffe B. Aboba L. St.Amour January 2013 ASCII HTML 5

On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-iab-modern-paradigm-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6852
RFC6853 DHCPv6 Redundancy Deployment Considerations J. Brzozowski J. Tremblay J. Chen T. Mrugalski February 2013 ASCII HTML 16 DHCPv6 Redundancy Deployment Considerations

This document provides information for those wishing to use DHCPv6 to support their deployment of IPv6. In particular, it discusses the provision of semi-redundant DHCPv6 services.

draft-ietf-dhc-dhcpv6-redundancy-consider-03 BCP0180 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc 10.17487/RFC6853
RFC6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields B. Leiba March 2013 ASCII HTML 9

The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.

draft-leiba-5322upd-from-group-09 RFC5322 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6854
RFC6855 IMAP Support for UTF-8 P. Resnick Editor C. Newman Editor S. Shen Editor March 2013 ASCII HTML 12 IMAP IDNA

This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.

draft-ietf-eai-5738bis-12 RFC5738 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6855 10.17487/RFC6855
RFC6856 Post Office Protocol Version 3 (POP3) Support for UTF-8 R. Gellens C. Newman J. Yao K. Fujiwara March 2013 ASCII HTML 14 internationalized

This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.

draft-ietf-eai-rfc5721bis-08 RFC5721 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6856
RFC6857 Post-Delivery Message Downgrading for Internationalized Email Messages K. Fujiwara March 2013 ASCII HTML 20 EAI Email Address Internationalization Downgrade MAIL

The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.

draft-ietf-eai-popimap-downgrade-08 PROPOSED STANDARD PROPOSED STANDARD IETF app eai http://www.rfc-editor.org/errata_search.php?rfc=6857 10.17487/RFC6857
RFC6858 Simplified POP and IMAP Downgrading for Internationalized Email A. Gulbrandsen March 2013 ASCII HTML 6

This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results.

draft-ietf-eai-simpledowngrade-07 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF app eai 10.17487/RFC6858
RFC6859 Update to RFC 3777 to Clarify Nominating Committee Eligibility of IETF Leadership B. Leiba January 2013 ASCII HTML 3 nomcom IAOC

RFC 3777 specifies that "sitting members" of the IAB and IESG "may not volunteer to serve on the nominating committee". Since the time that document was written, the IETF Administrative Oversight Committee (IAOC) was formed; that body is not covered by RFC 3777. There is also ambiguity in RFC 3777 about whether ex officio members and liaisons are included as "sitting members". This document updates RFC 3777 to clarify the rules as they apply to members of the IAB, the IESG, and the IAOC. This memo documents an Internet Best Current Practice.

draft-leiba-3777upd-eligibility-06 RFC7437 RFC3777 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6859
RFC6860 Hiding Transit-Only Networks in OSPF Y. Yang A. Retana A. Roy January 2013 ASCII HTML 13

A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.

In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.

This document updates RFCs 2328 and 5340. [STANDARDS-TRACK]

draft-ietf-ospf-prefix-hiding-07 RFC2328 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6860 10.17487/RFC6860
RFC6861 The "create-form" and "edit-form" Link Relations I. Dzmanashvili January 2013 ASCII HTML 6

RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. This document is not an Internet Standards Track specification; it is published for informational purposes.

draft-ioseb-dzmanashvili-link-relation-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6861
RFC6862 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements G. Lebovitz M. Bhatia B. Weis March 2013 ASCII HTML 26

Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security.

draft-ietf-karp-threats-reqs-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6862
RFC6863 Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide S. Hartman D. Zhang March 2013 ASCII HTML 11

This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.

draft-ietf-karp-ospf-analysis-06 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6863
RFC6864 Updated Specification of the IPv4 ID Field J. Touch February 2013 ASCII HTML 19

The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]

draft-ietf-intarea-ipv4-id-update-07 RFC0791 RFC1122 RFC2003 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC6864
RFC6865 Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME V. Roca M. Cunche J. Lacan A. Bouabdallah K. Matsuzono February 2013 ASCII HTML 23 Forward Error Correction Reed-Solomon

This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.

draft-ietf-fecframe-simple-rs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv fecframe 10.17487/RFC6865
RFC6866 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks B. Carpenter S. Jiang February 2013 ASCII HTML 11

This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.

draft-ietf-6renum-static-problem-03 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6866
RFC6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) Y. Nir Q. Wu January 2013 ASCII HTML 9

This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. This document defines an Experimental Protocol for the Internet community.

draft-nir-ipsecme-erx-11 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6867
RFC6868 Parameter Value Encoding in iCalendar and vCard C. Daboo February 2013 ASCII HTML 7 calendar contact

This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications.

draft-daboo-ical-vcard-parameter-encoding-04 RFC5545 RFC6321 RFC6350 RFC6351 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6868 10.17487/RFC6868
RFC6869 vCard KIND:device G. Salgueiro J. Clarke P. Saint-Andre February 2013 ASCII HTML 9 vCard

This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). [STANDARDS-TRACK]

draft-salgueiro-vcarddav-kind-device-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6869
RFC6870 Pseudowire Preferential Forwarding Status Bit P. Muley Editor M. Aissaoui Editor February 2013 ASCII HTML 35 PW redundancy active PW standby PW primary PW secondary PW PW precedence

This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured between Provider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes in Multi-Segment Pseudowire (MS-PW) applications.

In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.

In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.

Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV.

draft-ietf-pwe3-redundancy-bit-09 RFC4447 RFC7771 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 http://www.rfc-editor.org/errata_search.php?rfc=6870 10.17487/RFC6870
RFC6871 Session Description Protocol (SDP) Media Capabilities Negotiation R. Gilman R. Even F. Andreasen February 2013 ASCII HTML 55 Session Capabilities Latent Configurations Media Format Capability

Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.

This document updates the IANA Considerations of RFC 5939.

draft-ietf-mmusic-sdp-media-capabilities-17 RFC5939 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC6871
RFC6872 The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model V. Gurbani Editor E. Burger Editor T. Anjali H. Abdelnur O. Festor February 2013 ASCII HTML 39 logging analytics information model

Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of a SIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents.

draft-ietf-sipclf-problem-statement-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6872
RFC6873 Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Gurbani A. B. Roach February 2013 ASCII HTML 28 SIPCLF

The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record.

draft-ietf-sipclf-format-11 RFC7355 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipclf 10.17487/RFC6873
RFC6874 Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers B. Carpenter S. Cheshire R. Hinden February 2013 ASCII HTML 10

This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.

draft-ietf-6man-uri-zoneid-06 RFC3986 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6874 10.17487/RFC6874
RFC6875 The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan S. Kamei T. Momose T. Inoue T. Nishitani February 2013 ASCII HTML 18 overlay network content delivery network peer-to-peer traffic engineering experiments in Japan

This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for the ALTO architecture and especially for application-independent ALTO- like server operation.

draft-kamei-p2p-experiments-japan-09 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC6875
RFC6876 A Posture Transport Protocol over TLS (PT-TLS) P. Sangster N. Cam-Winget J. Salowey February 2013 ASCII HTML 44 Network Endpoint Assessment NEA

This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel.

draft-ietf-nea-pt-tls-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC6876
RFC6877 464XLAT: Combination of Stateful and Stateless Translation M. Mawatari M. Kawashima C. Byrne April 2013 ASCII HTML 14 XLAT Stateful Translation Stateless Translation

This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation.

draft-ietf-v6ops-464xlat-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6877
RFC6878 IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field A.B. Roach March 2013 ASCII HTML 3

This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261.

draft-ietf-sipcore-priority-00 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=6878 10.17487/RFC6878
RFC6879 IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods S. Jiang B. Liu B. Carpenter February 2013 ASCII HTML 17

This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation.

draft-ietf-6renum-enterprise-06 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC6879
RFC6880 An Information Model for Kerberos Version 5 L. Johansson March 2013 ASCII HTML 14 kerberos kdc LDAP schema

This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.

draft-ietf-krb-wg-kdc-model-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec krb-wg 10.17487/RFC6880
RFC6881 Best Current Practice for Communications Services in Support of Emergency Calling B. Rosen J. Polk March 2013 ASCII HTML 28 SIP emergency emergency calls emergency call emergency calling 9-1-1 1-1-2 ecrit

The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls.

draft-ietf-ecrit-phonebcp-20 RFC7840 RFC7852 BCP0181 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rai ecrit 10.17487/RFC6881
RFC6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs) K. Kumaki Editor T. Murai D. Cheng S. Matsushima P. Jiang March 2013 ASCII HTML 15

IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.

The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.

draft-kumaki-murai-l3vpn-rsvp-te-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6882
RFC6883 IPv6 Guidance for Internet Content Providers and Application Service Providers B. Carpenter S. Jiang March 2013 ASCII HTML 24

This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users.

draft-ietf-v6ops-icp-guidance-05 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC6883
RFC6884 RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Z. Fang March 2013 ASCII HTML 21 EVRC-WB EVRC-B

This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email.

draft-ietf-avt-rtp-evrc-nw-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC6884
RFC6885 Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) M. Blanchet A. Sullivan March 2013 ASCII HTML 34

If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing Domain Names in Applications (here called IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated, or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.

draft-ietf-precis-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF app precis 10.17487/RFC6885
RFC6886 NAT Port Mapping Protocol (NAT-PMP) S. Cheshire M. Krochmal April 2013 ASCII HTML 33

This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.

draft-cheshire-nat-pmp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6886 10.17487/RFC6886
RFC6887 Port Control Protocol (PCP) D. Wing Editor S. Cheshire M. Boucadair R. Penno P. Selkirk April 2013 ASCII HTML 88 NAT Firewall

The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.

draft-ietf-pcp-base-29 RFC7488 RFC7652 RFC7843 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=6887 10.17487/RFC6887
RFC6888 Common Requirements for Carrier-Grade NATs (CGNs) S. Perreault Editor I. Yamagata S. Miyakawa A. Nakagawa H. Ashida April 2013 ASCII HTML 15 CGN NAT

This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.

draft-ietf-behave-lsn-requirements-10 RFC4787 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv behave 10.17487/RFC6888
RFC6889 Analysis of Stateful 64 Translation R. Penno T. Saxena M. Boucadair S. Sivakumar April 2013 ASCII HTML 15 NAT64 DNS64 NAT-PT ALG (Application Layer Gateway) NAT traversal IPv4-IPv6 interconnection IPv4-IPv6 translation

Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.

draft-ietf-behave-64-analysis-07 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC6889
RFC6890 Special-Purpose IP Address Registries M. Cotton L. Vegoda R. Bonica Editor B. Haberman April 2013 ASCII HTML 23 Internet Protocol space assignments

This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.

draft-bonica-special-purpose-07 RFC4773 RFC5156 RFC5735 RFC5736 RFC8190 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6890 10.17487/RFC6890
RFC6891 Extension Mechanisms for DNS (EDNS(0)) J. Damas M. Graff P. Vixie April 2013 ASCII HTML 16 DNS extensions domain name system resource records opt

The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.

This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.

draft-ietf-dnsext-rfc2671bis-edns0-10 RFC2671 RFC2673 STD0075 INTERNET STANDARD INTERNET STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6891 10.17487/RFC6891
RFC6892 The 'describes' Link Relation Type E. Wilde March 2013 ASCII HTML 5

This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.

draft-wilde-describes-link-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6892
RFC6893 A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) P. Higgs P. Szucs March 2013 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF.

draft-higgs-oipf-urn-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6893
RFC6894 Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection R. Papneja S. Vapiwala J. Karthik S. Poretsky S. Rao JL. Le Roux March 2013 ASCII HTML 35

This document describes the methodology for benchmarking MPLS Fast Reroute (FRR) protection mechanisms for link and node protection. This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS Traffic Engineered (MPLS-TE) tunnels.

draft-ietf-bmwg-protection-meth-14 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6894
RFC6895 Domain Name System (DNS) IANA Considerations D. Eastlake 3rd April 2013 ASCII HTML 19 RRTYPE RCODE AFSDB

This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.

draft-ietf-dnsext-rfc6195bis-05 RFC6195 RFC1183 RFC2845 RFC2930 RFC3597 BCP0042 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dnsext 10.17487/RFC6895
RFC6896 SCS: KoanLogic's Secure Cookie Sessions for HTTP S. Barbato S. Dorigotti T. Fossati Editor March 2013 ASCII HTML 23 HTTP Secure Cookies

This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin-timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.

Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content via HTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, Home Office (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering.

draft-secure-cookie-session-protocol-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6896 10.17487/RFC6896
RFC6897 Multipath TCP (MPTCP) Application Interface Considerations M. Scharf A. Ford March 2013 ASCII HTML 31

Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.

draft-ietf-mptcp-api-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC6897
RFC6898 Link Management Protocol Behavior Negotiation and Configuration Modifications D. Li D. Ceccarelli L. Berger March 2013 ASCII HTML 11 LMP

The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.

This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.

draft-ietf-ccamp-lmp-behavior-negotiation-11 RFC4204 RFC4207 RFC4209 RFC5818 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC6898
RFC6899 RFC6900 RFC6901 JavaScript Object Notation (JSON) Pointer P. Bryan Editor K. Zyp M. Nottingham Editor April 2013 ASCII HTML 8

JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document.

draft-ietf-appsawg-json-pointer-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6901 10.17487/RFC6901
RFC6902 JavaScript Object Notation (JSON) Patch P. Bryan Editor M. Nottingham Editor April 2013 ASCII HTML 18

JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation (JSON) document; it is suitable for use with the HTTP PATCH method. The "application/json-patch+json" media type is used to identify such patch documents.

draft-ietf-appsawg-json-patch-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=6902 10.17487/RFC6902
RFC6903 Additional Link Relation Types J. Snell March 2013 ASCII HTML 6 http link rel

This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types.

draft-snell-additional-link-relations-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6903
RFC6904 Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) J. Lennox April 2013 ASCII HTML 15 real-time transport protocol rtp header extensions security

The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.

This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.

draft-ietf-avtcore-srtp-encrypted-header-ext-05 RFC3711 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC6904
RFC6905 Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne D. Bond S. Aldrin Y. Li R. Watve March 2013 ASCII HTML 13

Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to the Transparent Interconnection of Lots of Links (TRILL).

draft-ietf-trill-oam-req-05 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC6905
RFC6906 The 'profile' Link Relation Type E. Wilde March 2013 ASCII HTML 8 application profile profile identifier

This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms.

draft-wilde-profile-link-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6906
RFC6907 Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties T. Manderson K. Sriram R. White March 2013 ASCII HTML 31 Prefix origin validation Routing security BGP security

This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.

draft-ietf-sidr-usecases-06 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC6907
RFC6908 Deployment Considerations for Dual-Stack Lite Y. Lee R. Maglione C. Williams C. Jacquenet M. Boucadair March 2013 ASCII HTML 14

This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.

draft-ietf-softwire-dslite-deployment-08 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC6908
RFC6909 IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 S. Gundavelli Editor X. Zhou J. Korhonen G. Feige R. Koodli April 2013 ASCII HTML 14

This specification defines a new mobility option, the IPv4 Traffic Offload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session. Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network.

draft-ietf-netext-pmipv6-sipto-option-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC6909
RFC6910 Completion of Calls for the Session Initiation Protocol (SIP) D. Worley M. Huelsemann R. Jesske D. Alexeitsev April 2013 ASCII HTML 37 call completion CC SS7 Signaling System 7 purpose header parameter m URI parameter m header parameter call-completion event package, CCBS CCNR CCNL Call-Info header field Presence Information Data Format PIDF P-Asserted-Identity header field

The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.

For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session Initiation Protocol Service Examples" (RFC 5359).

For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.

The architecture is designed to interoperate well with existing completion of calls solutions in other networks.

draft-ietf-bliss-call-completion-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss 10.17487/RFC6910
RFC6911 RADIUS Attributes for IPv6 Access Networks W. Dec Editor B. Sarikaya G. Zorn Editor D. Miles B. Lourdelet April 2013 ASCII HTML 15 AAA RADIUS IPv6

This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing.

draft-ietf-radext-ipv6-access-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6911
RFC6912 Principles for Unicode Code Point Inclusion in Labels in the DNS A. Sullivan D. Thaler J. Klensin O. Kolkman April 2013 ASCII HTML 12

Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points. Most operators of zones should probably not permit registration of U-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone.

draft-iab-dns-zone-codepoint-pples-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6912
RFC6913 Indicating Fax over IP Capability in the Session Initiation Protocol (SIP) D. Hanes G. Salgueiro K. Fleming March 2013 ASCII HTML 9 media feature tag

This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP). Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing.

draft-hanes-dispatch-fax-capability-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6913
RFC6914 SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) J. Rosenberg April 2013 ASCII HTML 15 SIP SIMPLE presence IM

The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other.

draft-ietf-simple-simple-09 INFORMATIONAL INFORMATIONAL IETF rai simple 10.17487/RFC6914
RFC6915 Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) R. Bellis April 2013 ASCII HTML 9 HELD Flow

RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.

However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.

This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement.

This document updates RFC 6155 by deprecating the port number elements specified therein.

draft-ietf-geopriv-flow-identity-02 RFC6155 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC6915
RFC6916 Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI) R. Gagliano S. Kent S. Turner April 2013 ASCII HTML 20 Resource Public Key Infrastructure RPKI Algorithm Transition SIDR routing security BGP security

This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children).

draft-ietf-sidr-algorithm-agility-12 BCP0182 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC6916
RFC6917 Media Resource Brokering C. Boulton L. Miniero G. Munson April 2013 ASCII HTML 136

The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers.

draft-ietf-mediactrl-mrb-19 PROPOSED STANDARD PROPOSED STANDARD IETF rai mediactrl 10.17487/RFC6917
RFC6918 Formally Deprecating Some ICMPv4 Message Types F. Gont C. Pignataro April 2013 ASCII HTML 8 IANA IPv4 Options

A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.

draft-gp-obsolete-icmp-types-iana-01 RFC1788 RFC0792 RFC0950 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6918
RFC6919 Further Key Words for Use in RFCs to Indicate Requirement Levels R. Barnes S. Kent E. Rescorla April 1 2013 ASCII HTML 6

RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

draft-barnes-2119bis-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6919
RFC6920 Naming Things with Hashes S. Farrell D. Kutscher C. Dannewitz B. Ohlman A. Keranen P. Hallam-Baker April 2013 ASCII HTML 23 Cryptography URI Information Centric Networking

This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.

draft-farrell-decade-ni-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6920 10.17487/RFC6920
RFC6921 Design Considerations for Faster-Than-Light (FTL) Communication R. Hinden April 1 2013 ASCII HTML 7

We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.

draft-hinden-FTL-design-considerations-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6921
RFC6922 The application/sql Media Type Y. Shafranovich April 2013 ASCII HTML 5 SQL MIME

This document registers the application/sql media type to be used for the Structured Query Language (SQL).

draft-shafranovich-mime-sql-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6922
RFC6923 MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions R. Winter E. Gray H. van Helvoort M. Betts May 2013 ASCII HTML 12

This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T).

draft-ietf-mpls-tp-itu-t-identifiers-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC6923
RFC6924 Registration of Second-Level URN Namespaces under "ietf" B. Leiba April 2013 ASCII HTML 4

RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf".

draft-leiba-urnbis-ietf-namespace-02 RFC2648 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6924
RFC6925 The DHCPv4 Relay Agent Identifier Sub-Option B. Joshi R. Desetti M. Stapp April 2013 ASCII HTML 8 DHCP relay

This document defines a new Relay Agent Identifier sub-option for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub-option allows a DHCP relay agent to include the identifier in the DHCP messages it sends.

draft-ietf-dhc-relay-id-suboption-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6925
RFC6926 DHCPv4 Bulk Leasequery K. Kinnear M. Stapp R. Desetti B. Joshi N. Russell P. Kurapati B. Volz April 2013 ASCII HTML 41

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP.

draft-ietf-dhc-dhcpv4-bulk-leasequery-07 RFC7724 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6926
RFC6927 Variants in Second-Level Names Registered in Top-Level Domains J. Levine P. Hoffman May 2013 ASCII HTML 18 DNS variant TLDs

Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS. Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of the IETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA.

draft-levine-tld-variant-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6927
RFC6928 Increasing TCP's Initial Window J. Chu N. Dukkipati Y. Cheng M. Mathis April 2013 ASCII HTML 24

This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.

draft-ietf-tcpm-initcwnd-08 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6928
RFC6929 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions A. DeKok A. Lior April 2013 ASCII HTML 68

The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems.

draft-ietf-radext-radius-extensions-13 RFC2865 RFC3575 RFC6158 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC6929
RFC6930 RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) D. Guo S. Jiang Editor R. Despres R. Maglione April 2013 ASCII HTML 12

The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.

draft-ietf-softwire-6rd-radius-attrib-11 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=6930 10.17487/RFC6930
RFC6931 Additional XML Security Uniform Resource Identifiers (URIs) D. Eastlake 3rd April 2013 ASCII HTML 36

This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.

draft-eastlake-additional-xmlsec-uris-10 RFC4051 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6931 10.17487/RFC6931
RFC6932 Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry D. Harkins Editor May 2013 ASCII HTML 12 elliptic curve Diffie-Hellman

This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols.

draft-harkins-brainpool-ike-groups-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6932
RFC6933 Entity MIB (Version 4) A. Bierman D. Romascanu J. Quittek M. Chandramouli May 2013 ASCII HTML 76 management information base snmp simple network management protocol

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single Simple Network Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of the Entity MIB module published as RFC 4133.

draft-ietf-eman-rfc4133bis-06 RFC4133 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman http://www.rfc-editor.org/errata_search.php?rfc=6933 10.17487/RFC6933
RFC6934 Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) N. Bitar Editor S. Wadhwa Editor T. Haag H. Li June 2013 ASCII HTML 39

The purpose of this document is to provide applicability of the Access Node Control Mechanism to broadband access based on Passive Optical Networks (PONs). The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control Mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives.

draft-ietf-ancp-pon-05 INFORMATIONAL INFORMATIONAL IETF int ancp 10.17487/RFC6934
RFC6935 IPv6 and UDP Checksums for Tunneled Packets M. Eubanks P. Chimento M. Westerlund April 2013 ASCII HTML 12 Tunnel Encapsulation Integrity Packet Corruption Middlebox

This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.

draft-ietf-6man-udpchecksums-08 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6935 10.17487/RFC6935
RFC6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums G. Fairhurst M. Westerlund April 2013 ASCII HTML 40

This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.

draft-ietf-6man-udpzero-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6936 10.17487/RFC6936
RFC6937 Proportional Rate Reduction for TCP M. Mathis N. Dukkipati Y. Cheng May 2013 ASCII HTML 16 TCP loss recovery packet conservation self clock

This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.

draft-ietf-tcpm-proportional-rate-reduction-04 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC6937
RFC6938 Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID J. Scudder May 2013 ASCII HTML 3 BGP

This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC.

draft-ietf-idr-deprecate-dpa-etal-00 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC6938
RFC6939 Client Link-Layer Address Option in DHCPv6 G. Halwasia S. Bhandari W. Dec May 2013 ASCII HTML 7

This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option.

draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6939
RFC6940 REsource LOcation And Discovery (RELOAD) Base Protocol C. Jennings B. Lowekamp Editor E. Rescorla S. Baset H. Schulzrinne January 2014 ASCII HTML 176 p2p dht p2psip chord peer to peer

This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.

draft-ietf-p2psip-base-26 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip http://www.rfc-editor.org/errata_search.php?rfc=6940 10.17487/RFC6940
RFC6941 MPLS Transport Profile (MPLS-TP) Security Framework L. Fang Editor B. Niven-Jenkins Editor S. Mansfield Editor R. Graveman Editor April 2013 ASCII HTML 15 threats mitigation defensive techniques

This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network.

draft-ietf-mpls-tp-security-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6941
RFC6942 Diameter Support for the EAP Re-authentication Protocol (ERP) J. Bournelle L. Morand S. Decugis Q. Wu G. Zorn May 2013 ASCII HTML 18

The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.

draft-ietf-dime-erp-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC6942
RFC6943 Issues in Identifier Comparison for Security Purposes D. Thaler Editor May 2013 ASCII HTML 26 Canonicalization Normalization Hostname URI IRI

Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.

draft-iab-identifier-comparison-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6943
RFC6944 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status S. Rose April 2013 ASCII HTML 7

The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.

draft-ietf-dnsext-dnssec-algo-imp-status-04 RFC8624 RFC2536 RFC2539 RFC3110 RFC4034 RFC4398 RFC5155 RFC5702 RFC5933 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext http://www.rfc-editor.org/errata_search.php?rfc=6944 10.17487/RFC6944
RFC6945 Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol R. Bush B. Wijnen K. Patel M. Baer May 2013 ASCII HTML 25

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol.

draft-ietf-sidr-rpki-rtr-protocol-mib-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC6945
RFC6946 Processing of IPv6 "Atomic" Fragments F. Gont May 2013 ASCII HTML 9 fragmentation attacks vulnerabilities atomic fragments

The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.

draft-ietf-6man-ipv6-atomic-fragments-04 RFC2460 RFC5722 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=6946 10.17487/RFC6946
RFC6947 The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute M. Boucadair H. Kaplan R. Gilman S. Veikkolainen May 2013 ASCII HTML 24

This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative Network Address Types (ANAT) due to their syntax.

The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required, Interactive Connectivity Establishment (ICE), as specified in RFC 5245, provides such a solution.

draft-boucadair-mmusic-altc-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6947
RFC6948 Some Measurements on World IPv6 Day from an End-User Perspective A. Keranen J. Arkko July 2013 ASCII PDF HTML 11

During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

draft-keranen-ipv6day-measurements-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6948
RFC6949 RFC Series Format Requirements and Future Development H. Flanagan N. Brownlee May 2013 ASCII HTML 14

This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.

draft-iab-rfcformatreq-03 RFC2223 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6949
RFC6950 Architectural Considerations on Application Features in the DNS J. Peterson O. Kolkman H. Tschofenig B. Aboba October 2013 ASCII HTML 31

A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered.

draft-iab-dns-applications-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6950
RFC6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication M. Tuexen R. Stewart May 2013 ASCII HTML 12

This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.

Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.

This document covers only end-hosts and not tunneling (egress or ingress) endpoints.

draft-ietf-tsvwg-sctp-udp-encaps-14 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC6951
RFC6952 Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide M. Jethanandani K. Patel L. Zheng May 2013 ASCII HTML 17 key authentication routing DoS

This document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.

draft-ietf-karp-routing-tcp-analysis-07 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC6952
RFC6953 Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements A. Mancuso Editor S. Probasco B. Patil May 2013 ASCII HTML 23

Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.

draft-ietf-paws-problem-stmt-usecases-rqmts-15 INFORMATIONAL INFORMATIONAL IETF app paws 10.17487/RFC6953
RFC6954 Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) J. Merkle M. Lochter July 2013 ASCII HTML 11 IKE Elliptic Curve

This document specifies use of the Elliptic Curve Cryptography (ECC) Brainpool elliptic curve groups for key exchange in the Internet Key Exchange Protocol version 2 (IKEv2).

draft-merkle-ikev2-ke-brainpool-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6954
RFC6955 Diffie-Hellman Proof-of-Possession Algorithms J. Schaad H. Prafullchandra May 2013 ASCII HTML 43 POP ECDH DH

This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.

This document obsoletes RFC 2875.

draft-schaad-pkix-rfc2875-bis-08 RFC2875 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC6955
RFC6956 Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library W. Wang E. Haleplidis K. Ogawa C. Li J. Halpern June 2013 ASCII HTML 111 ForCES LFB Library

This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.

draft-ietf-forces-lfb-lib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=6956 10.17487/RFC6956
RFC6957 Duplicate Address Detection Proxy F. Costa J-M. Combes Editor X. Pougnard H. Li June 2013 ASCII HTML 16 IPv6 SLAAC DAD SAVI

The document describes a proxy-based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address.

draft-ietf-6man-dad-proxy-07 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6957
RFC6958 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting A. Clark S. Zhang J. Zhao Q. Wu Editor May 2013 ASCII HTML 16 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=6958 10.17487/RFC6958
RFC6959 Source Address Validation Improvement (SAVI) Threat Scope D. McPherson F. Baker J. Halpern May 2013 ASCII HTML 25

The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work.

draft-ietf-savi-threat-scope-08 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC6959
RFC6960 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP S. Santesson M. Myers R. Ankney A. Malpani S. Galperin C. Adams June 2013 ASCII HTML 41 PKIX digital security ocsp

This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.

draft-ietf-pkix-rfc2560bis-20 RFC2560 RFC6277 RFC5912 RFC8954 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=6960 10.17487/RFC6960
RFC6961 The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Y. Pettersen June 2013 ASCII HTML 10 RFC 6066 RFC 2560 RFC 6960 RFC 5246 OCSP OCSP stapling multi-stapling certificate status checking revocation information status_request status_request_v2

This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.

draft-ietf-tls-multiple-cert-status-extension-08 RFC8446 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=6961 10.17487/RFC6961
RFC6962 Certificate Transparency B. Laurie A. Langley E. Kasper June 2013 ASCII HTML 27 TLS certificates

This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.

Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

draft-laurie-pki-sunlight-12 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6962 10.17487/RFC6962
RFC6963 A Uniform Resource Name (URN) Namespace for Examples P. Saint-Andre May 2013 ASCII HTML 7 URN examples documentation

This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

draft-saintandre-urn-example-05 BCP0183 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC6963
RFC6964 Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) F. Templin May 2013 ASCII HTML 20 IPv6 IPv4 IPv6/IPv4 IPv6-in-IPv4 tunnel automatic isatap enterprise site

Many end-user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

draft-templin-v6ops-isops-19 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6964
RFC6965 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design L. Fang Editor N. Bitar R. Zhang M. Daikoku P. Pan August 2013 ASCII HTML 16

This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.

draft-ietf-mpls-tp-use-cases-and-design-08 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6965
RFC6966 RFC6967 Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments M. Boucadair J. Touch P. Levis R. Penno June 2013 ASCII HTML 24 NAT Host Identifier

This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.

This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.

draft-ietf-intarea-nat-reveal-analysis-10 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC6967
RFC6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols V. Roca B. Adamson July 2013 ASCII HTML 40

This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.

draft-ietf-rmt-fcast-08 EXPERIMENTAL EXPERIMENTAL IETF tsv rmt 10.17487/RFC6968
RFC6969 OSPFv3 Instance ID Registry Update A. Retana D. Cheng July 2013 ASCII HTML 4

This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838.

draft-ietf-ospf-ospfv3-iid-registry-update-04 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6969 10.17487/RFC6969
RFC6970 Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) M. Boucadair R. Penno D. Wing July 2013 ASCII HTML 23 UPnP pinhole PCP mapping NAT control interworking

This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.

draft-ietf-pcp-upnp-igd-interworking-10 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC6970
RFC6971 Depth-First Forwarding (DFF) in Unreliable Networks U. Herberg Editor A. Cardenas T. Iwao M. Dow S. Cespedes June 2013 ASCII HTML 41 DFF Depth first forwarding IPv6 Forwarding plane Lossy networks Reliability

This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.

draft-cardenas-dff-14 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=6971 10.17487/RFC6971
RFC6972 Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) Y. Zhang N. Zong July 2013 ASCII HTML 22 P2P

Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols. This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer Streaming Protocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP.

draft-ietf-ppsp-problem-statement-15 INFORMATIONAL INFORMATIONAL IETF tsv ppsp 10.17487/RFC6972
RFC6973 Privacy Considerations for Internet Protocols A. Cooper H. Tschofenig B. Aboba J. Peterson J. Morris M. Hansen R. Smith July 2013 ASCII HTML 36 Disclosure Anonymity Pseudonymity Confidentiality Identity

This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content.

draft-iab-privacy-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC6973
RFC6974 Applicability of MPLS Transport Profile for Ring Topologies Y. Weingarten S. Bryant D. Ceccarelli D. Caviglia F. Fondelli M. Corsi B. Wu X. Dai July 2013 ASCII HTML 30

This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology.

draft-ietf-mpls-tp-ring-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC6974
RFC6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) S. Crocker S. Rose July 2013 ASCII HTML 9 DNS DNSSEC EDNS

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.

draft-ietf-dnsext-dnssec-algo-signal-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dnsext 10.17487/RFC6975
RFC6976 Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach M. Shand S. Bryant S. Previdi C. Filsfils P. Francois O. Bonaventure July 2013 ASCII HTML 28

This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.

This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.

After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.

The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

draft-ietf-rtgwg-ordered-fib-12 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6976
RFC6977 Triggering DHCPv6 Reconfiguration from Relay Agents M. Boucadair X. Pougnard July 2013 ASCII HTML 13 Reconfigure-Request Reconfigure-Reply Link Address Option

This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message.

draft-ietf-dhc-triggered-reconfigure-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC6977
RFC6978 A TCP Authentication Option Extension for NAT Traversal J. Touch July 2013 ASCII HTML 6 TCP-AO

This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.

draft-touch-tcp-ao-nat-05 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC6978
RFC6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) T. Pornin August 2013 ASCII HTML 79 dsa ecdsa digital signature deterministic

This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.

draft-pornin-deterministic-dsa-02 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=6979 10.17487/RFC6979
RFC6980 Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery F. Gont August 2013 ASCII HTML 10 vulnerabilities evasion monitoring

This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.

draft-ietf-6man-nd-extension-headers-05 RFC3971 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC6980
RFC6981 A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses S. Bryant S. Previdi M. Shand August 2013 ASCII HTML 34 not-via

This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.

The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment.

draft-ietf-rtgwg-ipfrr-notvia-addresses-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC6981
RFC6982 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2013 ASCII HTML 9

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.

draft-sheffer-running-code-06 RFC7942 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC6982
RFC6983 Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) R. van Brandenburg O. van Deventer F. Le Faucheur K. Leung July 2013 ASCII HTML 45 video caching HTTP content delivery

This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.

draft-brandenburg-cdni-has-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6983
RFC6984 Interoperability Report for Forwarding and Control Element Separation (ForCES) W. Wang K. Ogawa E. Haleplidis M. Gao J. Hadi Salim August 2013 ASCII HTML 29

This document captures the results of the second Forwarding and Control Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the first ForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results.

draft-ietf-forces-interop-09 RFC6053 INFORMATIONAL INFORMATIONAL IETF rtg forces 10.17487/RFC6984
RFC6985 IMIX Genome: Specification of Variable Packet Sizes for Additional Testing A. Morton July 2013 ASCII HTML 10 Traffic Pattern Benchmarking

Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX" ("Internet Mix"). The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests. To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.

draft-ietf-bmwg-imix-genome-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC6985
RFC6986 GOST R 34.11-2012: Hash Function V. Dolmatov Editor A. Degtyarev August 2013 ASCII HTML 40

This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831.

draft-dolmatov-gost34112012-01 RFC5831 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC6986
RFC6987 OSPF Stub Router Advertisement A. Retana L. Nguyen A. Zinin R. White D. McPherson September 2013 ASCII HTML 7 ospf stub

This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.

This document obsoletes RFC 3137.

draft-ietf-ospf-rfc3137bis-04 RFC3137 RFC8770 INFORMATIONAL INFORMATIONAL IETF rtg ospf http://www.rfc-editor.org/errata_search.php?rfc=6987 10.17487/RFC6987
RFC6988 Requirements for Energy Management J. Quittek Editor M. Chandramouli R. Winter T. Dietz B. Claise September 2013 ASCII HTML 28 monitoring functions control functions

This document defines requirements for standards specifications for Energy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions. Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, Power Inlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.

This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management.

draft-ietf-eman-requirements-14 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC6988
RFC6989 Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Sheffer S. Fluhrer July 2013 ASCII HTML 10 Elliptic Curve cryptography secret key reuse recipient tests

This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.

draft-ietf-ipsecme-dh-checks-05 RFC5996 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC6989
RFC6990 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting R. Huang Q. Wu H. Asaeda G. Zorn August 2013 ASCII HTML 11 RTCP XR MPEG2 PSI Decodability

An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP. The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS.

draft-ietf-xrblock-rtcp-xr-decodability-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC6990
RFC6991 Common YANG Data Types J. Schoenwaelder Editor July 2013 ASCII HTML 30 YANG data model netconf

This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.

draft-ietf-netmod-rfc6021-bis-03 RFC6021 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=6991 10.17487/RFC6991
RFC6992 Routing for IPv4-Embedded IPv6 Packets D. Cheng M. Boucadair A. Retana July 2013 ASCII HTML 15

This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.

draft-ietf-ospf-ipv4-embedded-ipv6-routing-14 INFORMATIONAL INFORMATIONAL IETF rtg ospf 10.17487/RFC6992
RFC6993 Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) P. Saint-Andre July 2013 ASCII HTML 5 SIP Call-Info header field Instant Messaging Presence

This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).

draft-saintandre-impp-call-info-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC6993
RFC6994 Shared Use of Experimental TCP Options J. Touch August 2013 ASCII HTML 11

This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.

draft-ietf-tcpm-experimental-options-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm 10.17487/RFC6994
RFC6995 RFC6996 Autonomous System (AS) Reservation for Private Use J. Mitchell July 2013 ASCII HTML 4 asn

This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10 of that document.

draft-ietf-idr-as-private-reservation-05 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC6996
RFC6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks M. Goyal Editor E. Baccelli M. Philipp A. Brandt J. Martocci August 2013 ASCII HTML 40 P2P Routing RPL ROLL

This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.

draft-ietf-roll-p2p-rpl-17 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6997
RFC6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network M. Goyal Editor E. Baccelli A. Brandt J. Martocci August 2013 ASCII HTML 29 Measurement Route Quality P2P Routes RPL ROLL

This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.

draft-ietf-roll-p2p-measurement-10 EXPERIMENTAL EXPERIMENTAL IETF rtg roll 10.17487/RFC6998
RFC6999 RFC7000 RFC7001 Message Header Field for Indicating Message Authentication Status M. Kucherawy September 2013 ASCII HTML 43 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

draft-ietf-appsawg-rfc5451bis-10 RFC5451 RFC6577 RFC7601 RFC7410 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7001 10.17487/RFC7001
RFC7002 RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting A. Clark G. Zorn Q. Wu September 2013 ASCII HTML 12

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-discard-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7002
RFC7003 RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting A. Clark R. Huang Q. Wu Editor September 2013 ASCII HTML 14 Real Time Control Protocol

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock http://www.rfc-editor.org/errata_search.php?rfc=7003 10.17487/RFC7003
RFC7004 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting G. Zorn R. Schott Q. Wu Editor R. Huang September 2013 ASCII HTML 21 RTCP XR Summary Statistics Burst/Gap Loss Burst/Gap Discard Frame Impairment

This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-summary-stat-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7004
RFC7005 RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting A. Clark V. Singh Q. Wu September 2013 ASCII HTML 14

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-jb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7005
RFC7006 Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) M. Garcia-Martin S. Veikkolainen R. Gilman September 2013 ASCII PDF HTML 22 title capability connection data capability bandwidth capability

The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely used SDP offer/answer procedures.

This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ("b=" line), connection data ("c=" line), and session or media titles ("i=" line for each session or media).

draft-ietf-mmusic-sdp-miscellaneous-caps-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic http://www.rfc-editor.org/errata_search.php?rfc=7006 10.17487/RFC7006
RFC7007 Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) T. Terriberry August 2013 ASCII HTML 4

The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.

draft-ietf-avtcore-avp-codecs-03 RFC3551 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7007
RFC7008 A Description of the KCipher-2 Encryption Algorithm S. Kiyomoto W. Shin August 2013 ASCII HTML 37 encryption stream cipher cipher

This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan.

draft-kiyomoto-kcipher2-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7008
RFC7009 OAuth 2.0 Token Revocation T. Lodderstedt Editor S. Dronia M. Scurtescu August 2013 ASCII HTML 11

This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant.

draft-ietf-oauth-revocation-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7009
RFC7010 IPv6 Site Renumbering Gap Analysis B. Liu S. Jiang B. Carpenter S. Venaas W. George September 2013 ASCII HTML 26

This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering. The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process.

draft-ietf-6renum-gap-analysis-08 INFORMATIONAL INFORMATIONAL IETF ops 6renum 10.17487/RFC7010
RFC7011 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information B. Claise Editor B. Trammell Editor P. Aitken September 2013 ASCII HTML 76

This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101.

draft-ietf-ipfix-protocol-rfc5101bis-10 RFC5101 STD0077 INTERNET STANDARD INTERNET STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7011 10.17487/RFC7011
RFC7012 Information Model for IP Flow Information Export (IPFIX) B. Claise Editor B. Trammell Editor September 2013 ASCII HTML 24

This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.

draft-ietf-ipfix-information-model-rfc5102bis-10 RFC5102 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix http://www.rfc-editor.org/errata_search.php?rfc=7012 10.17487/RFC7012
RFC7013 Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements B. Trammell B. Claise September 2013 ASCII HTML 32 IE-DOCTORS IANA

This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.

draft-ietf-ipfix-ie-doctors-07 BCP0184 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops ipfix 10.17487/RFC7013
RFC7014 Flow Selection Techniques S. D'Antonio T. Zseby C. Henke L. Peluso September 2013 ASCII HTML 33

The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.

draft-ietf-ipfix-flow-selection-tech-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7014
RFC7015 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol B. Trammell A. Wagner B. Claise September 2013 ASCII HTML 49 Flow metering Flow measurement IPFIX mediator

This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.

draft-ietf-ipfix-a9n-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7015
RFC7016 Adobe's Secure Real-Time Media Flow Protocol M. Thornburgh November 2013 ASCII HTML 113 RTMFP

This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used.

draft-thornburgh-adobe-rtmfp-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7016
RFC7017 IMAP Access to IETF Email List Archives R. Sparks August 2013 ASCII HTML 5

The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service.

draft-sparks-genarea-imaparch-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7017
RFC7018 Auto-Discovery VPN Problem Statement and Requirements V. Manral S. Hanna September 2013 ASCII HTML 12 IPsec Overlay SDN IKE

This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.

Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.

draft-ietf-ipsecme-ad-vpn-problem-09 INFORMATIONAL INFORMATIONAL IETF sec ipsecme 10.17487/RFC7018
RFC7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD) J. Buford M. Kolberg Editor September 2013 ASCII HTML 41 application-layer multicast

We define a REsource LOcation And Discovery (RELOAD) Usage for Application-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast.

This document is a product of the Scalable Adaptive Multicast Research Group (SAM RG).

draft-irtf-samrg-sam-baseline-protocol-06 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7019
RFC7020 The Internet Numbers Registry System R. Housley J. Curran G. Huston D. Conrad August 2013 ASCII HTML 9

This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.

This document also provides information about the processes for further evolution of the Internet Numbers Registry System.

This document replaces RFC 2050.

This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.

draft-housley-rfc2050bis-02 RFC2050 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7020
RFC7021 Assessing the Impact of Carrier-Grade NAT on Network Applications C. Donley Editor L. Howard V. Kuarsingh J. Berg J. Doshi September 2013 ASCII HTML 29 CGN NAT444 DS-Lite Dual-Stack Lite IPv4 NAT IPv6 LSN transition

NAT444 is an IPv4 extension technology being considered by Service Providers as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier- Grade NAT (CGN) in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications. This document was updated to include the Dual-Stack Lite (DS-Lite) impacts also.

draft-donley-nat444-impacts-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7021
RFC7022 Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) A. Begen C. Perkins D. Wing E. Rescorla September 2013 ASCII HTML 10

The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.

For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222.

draft-ietf-avtcore-6222bis-06 RFC6222 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7022
RFC7023 MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking D. Mohan Editor N. Bitar Editor A. Sajassi Editor S. DeLord P. Niger R. Qiu October 2013 ASCII HTML 23

This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.

draft-ietf-pwe3-mpls-eth-oam-iwk-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7023
RFC7024 Virtual Hub-and-Spoke in BGP/MPLS VPNs H. Jeng J. Uttaro L. Jalil B. Decraene Y. Rekhter R. Aggarwal October 2013 ASCII HTML 25

With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each Provider Edge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.

Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers.

draft-ietf-l3vpn-virtual-hub-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7024
RFC7025 Requirements for GMPLS Applications of PCE T. Otani K. Ogaki D. Caviglia F. Zhang C. Margaria September 2013 ASCII HTML 12 Path Computation CSPF PCC Traffic Engineering TE

The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE.

draft-ietf-pce-gmpls-aps-req-09 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7025
RFC7026 Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel A. Farrel S. Bryant September 2013 ASCII HTML 5 ACH G-ACh Pseudowire PW MPLS-TP

The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs

No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.

This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry.

draft-ietf-mpls-retire-ach-tlv-03 RFC5586 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7026
RFC7027 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) J. Merkle M. Lochter October 2013 ASCII HTML 10 TLS Elliptic Curve Cryptography

This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.

draft-merkle-tls-brainpool-04 RFC4492 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7027 10.17487/RFC7027
RFC7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 JC. Zuniga LM. Contreras CJ. Bernardos S. Jeon Y. Kim September 2013 ASCII HTML 29 multimob PMIPv6 MTMA selector MLD IGMP

This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios.

draft-ietf-multimob-pmipv6-ropt-08 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7028
RFC7029 Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding S. Hartman M. Wasserman D. Zhang October 2013 ASCII HTML 19 MITM man-in-the-middle EMSK crypto binding Extended Master Session Key tunnel

As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.

draft-ietf-emu-crypto-bind-04 INFORMATIONAL INFORMATIONAL IETF sec emu 10.17487/RFC7029
RFC7030 Enrollment over Secure Transport M. Pritikin Editor P. Yee Editor D. Harkins Editor October 2013 ASCII HTML 53 pki est

This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.

draft-ietf-pkix-est-09 RFC8951 PROPOSED STANDARD PROPOSED STANDARD IETF sec pkix http://www.rfc-editor.org/errata_search.php?rfc=7030 10.17487/RFC7030
RFC7031 DHCPv6 Failover Requirements T. Mrugalski K. Kinnear September 2013 ASCII HTML 17 DHCPv6 Failover

The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.

draft-ietf-dhc-dhcpv6-failover-requirements-07 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7031
RFC7032 LDP Downstream-on-Demand in Seamless MPLS T. Beckhaus Editor B. Decraene K. Tiruveedhula M. Konstantynowicz Editor L. Martini October 2013 ASCII HTML 35

Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDP Downstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.

In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence.

draft-ietf-mpls-ldp-dod-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7032
RFC7033 WebFinger P. Jones G. Salgueiro M. Jones J. Smarr September 2013 ASCII HTML 28 WebFinger JRD JSON Resource Descriptor service discovery service discovery protocol information discovery information discovery protocol

This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.

draft-ietf-appsawg-webfinger-18 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7033
RFC7034 HTTP Header Field X-Frame-Options D. Ross T. Gondrom October 2013 ASCII HTML 14 frame-options HTTP header websec

To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.

draft-ietf-websec-x-frame-options-12 INFORMATIONAL INFORMATIONAL IETF app websec 10.17487/RFC7034
RFC7035 Relative Location Representation M. Thomson B. Rosen D. Stanley G. Bajko A. Thomson October 2013 ASCII HTML 39 Relative location

This document defines an extension to the Presence Information Data Format Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.

Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset.

draft-ietf-geopriv-relative-location-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7035
RFC7036 Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group R. Housley October 2013 ASCII HTML 7

When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc.

draft-housley-ltans-oids-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7036
RFC7037 RADIUS Option for the DHCPv6 Relay Agent L. Yeh M. Boucadair October 2013 ASCII HTML 10 DHCPv6 RADIUS

The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the Network Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. The DHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests.

draft-ietf-dhc-dhcpv6-radius-opt-14 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7037
RFC7038 Use of OSPF-MDR in Single-Hop Broadcast Networks R. Ogier October 2013 ASCII HTML 7 routing mobile ad hoc network MANET designated router wireless point-to-multipoint interface

RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANET Designated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.

draft-ietf-ospf-manet-single-hop-mdr-04 RFC5614 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7038
RFC7039 Source Address Validation Improvement (SAVI) Framework J. Wu J. Bi M. Bagnulo F. Baker C. Vogt Editor October 2013 ASCII HTML 14 anti-spoofing BCP38 ingress filtering

Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.

draft-ietf-savi-framework-06 INFORMATIONAL INFORMATIONAL IETF int savi 10.17487/RFC7039
RFC7040 Public IPv4-over-IPv6 Access Network Y. Cui J. Wu P. Wu O. Vautrin Y. Lee November 2013 ASCII HTML 13 Public 4over6 IPv4 over IPv6 Access Network DHCPv4 over IPv6 IPv6 Tunnel IPv6 Transition

This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.

draft-ietf-softwire-public-4over6-10 INFORMATIONAL INFORMATIONAL IETF int softwire 10.17487/RFC7040
RFC7041 Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging F. Balus Editor A. Sajassi Editor N. Bitar Editor November 2013 ASCII HTML 15

The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported.

The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.

This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model.

draft-ietf-l2vpn-pbb-vpls-pe-model-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7041
RFC7042 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters D. Eastlake 3rd J. Abley October 2013 ASCII HTML 27 Ethernet Ethertype 802 OUI EUI LSAP

Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342.

draft-eastlake-rfc5342bis-05 RFC5342 RFC2153 BCP0141 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7042
RFC7043 Resource Records for EUI-48 and EUI-64 Addresses in the DNS J. Abley October 2013 ASCII HTML 8 IEEE ethernet

48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended Unique Identifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.

This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS.

This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated.

draft-jabley-dnsext-eui48-eui64-rrtypes-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7043
RFC7044 An Extension to the Session Initiation Protocol (SIP) for Request History Information M. Barnes F. Audet S. Schubert J. van Elburg C. Holmberg February 2014 ASCII HTML 36 history-info retarget enhanced services voicemail automatic call distribution

This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244.

draft-ietf-sipcore-rfc4244bis-12 RFC4244 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=7044 10.17487/RFC7044
RFC7045 Transmission and Processing of IPv6 Extension Headers B. Carpenter S. Jiang December 2013 ASCII HTML 10

Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.

draft-ietf-6man-ext-transmit-05 RFC2460 RFC2780 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7045
RFC7046 A Common API for Transparent Hybrid Multicast M. Waehlisch T. Schmidt S. Venaas December 2013 ASCII HTML 41 Peer-to-Peer (P2P) adaptive multicast multicast naming multicast addressing

Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.

draft-irtf-samrg-common-api-11 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7046
RFC7047 The Open vSwitch Database Management Protocol B. Pfaff B. Davie Editor December 2013 ASCII HTML 35 vswitch virtualization overlay OVS

Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations.

draft-pfaff-ovsdb-proto-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7047
RFC7048 Neighbor Unreachability Detection Is Too Impatient E. Nordmark I. Gashinsky January 2014 ASCII HTML 8 6MAN IPv6 Neighbor Discovery

IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor -- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861.

draft-ietf-6man-impatient-nud-07 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7048
RFC7049 Concise Binary Object Representation (CBOR) C. Bormann P. Hoffman October 2013 ASCII HTML 54 parser encoder binary format data interchange format JSON

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

draft-bormann-cbor-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7049 10.17487/RFC7049
RFC7050 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis T. Savolainen J. Korhonen D. Wing November 2013 ASCII HTML 22 NAT64 DNS64 464XLAT Pref64::/n

This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments.

draft-ietf-behave-nat64-discovery-heuristic-17 RFC8880 PROPOSED STANDARD PROPOSED STANDARD IETF tsv behave http://www.rfc-editor.org/errata_search.php?rfc=7050 10.17487/RFC7050
RFC7051 Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix J. Korhonen Editor T. Savolainen Editor November 2013 ASCII HTML 25 NAT64 DNS64 464XLAT Pref64::/n

Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.

draft-ietf-behave-nat64-learn-analysis-03 INFORMATIONAL INFORMATIONAL IETF tsv behave 10.17487/RFC7051
RFC7052 Locator/ID Separation Protocol (LISP) MIB G. Schudel A. Jain V. Moreno October 2013 ASCII HTML 66

This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics.

draft-ietf-lisp-mib-13 EXPERIMENTAL EXPERIMENTAL IETF int lisp http://www.rfc-editor.org/errata_search.php?rfc=7052 10.17487/RFC7052
RFC7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol M. Tuexen I. Ruengeler R. Stewart November 2013 ASCII HTML 8

This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding Selective Acknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems.

draft-ietf-tsvwg-sctp-sack-immediately-04 RFC4960 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7053
RFC7054 Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) A. Farrel H. Endo R. Winter Y. Koike M. Paul November 2013 ASCII HTML 11

The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.

This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.

draft-ietf-mpls-tp-mip-mep-map-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7054
RFC7055 A GSS-API Mechanism for the Extensible Authentication Protocol S. Hartman Editor J. Howlett December 2013 ASCII HTML 35

This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.

draft-ietf-abfab-gss-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7055
RFC7056 Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism S. Hartman J. Howlett December 2013 ASCII HTML 11

The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes how to use the Naming Extensions API to access that information.

draft-ietf-abfab-gss-eap-naming-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7056
RFC7057 Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) S. Winter J. Salowey December 2013 ASCII HTML 7 EAP AAA

This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture.

draft-ietf-abfab-eapapplicability-06 RFC3748 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7057
RFC7058 Media Control Channel Framework (CFW) Call Flow Examples A. Amirante T. Castaldi L. Miniero S P. Romano November 2013 ASCII HTML 182 MediaCtrl Media Server Control Media Control Channel Framework

This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference document for both implementors and protocol researchers.

draft-ietf-mediactrl-call-flows-13 INFORMATIONAL INFORMATIONAL IETF rai mediactrl 10.17487/RFC7058
RFC7059 A Comparison of IPv6-over-IPv4 Tunnel Mechanisms S. Steffann I. van Beijnum R. van Rein November 2013 ASCII HTML 41

This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them.

draft-steffann-tunnels-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7059
RFC7060 Using LDP Multipoint Extensions on Targeted LDP Sessions M. Napierala E. Rosen IJ. Wijnands November 2013 ASCII HTML 9

Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. However, the specification for the Multipoint Extensions to LDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over a Targeted LDP session.

draft-ietf-mpls-targeted-mldp-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7060
RFC7061 eXtensible Access Control Markup Language (XACML) XML Media Type R. Sinnema E. Wilde November 2013 ASCII HTML 8

This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML).

draft-sinnema-xacml-media-type-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7061
RFC7062 Framework for GMPLS and PCE Control of G.709 Optical Transport Networks F. Zhang Editor D. Li H. Li S. Belotti D. Ceccarelli November 2013 ASCII HTML 26

This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.

draft-ietf-ccamp-gmpls-g709-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7062
RFC7063 Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments L. Zheng J. Zhang R. Parekh December 2013 ASCII HTML 12

This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard.

draft-ietf-pim-rfc4601-update-survey-report-03 INFORMATIONAL INFORMATIONAL IETF rtg pim 10.17487/RFC7063
RFC7064 URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol S. Nandakumar G. Salgueiro P. Jones M. Petit-Huguenin November 2013 ASCII HTML 9

This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.

draft-nandakumar-rtcweb-stun-uri-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7064
RFC7065 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers M. Petit-Huguenin S. Nandakumar G. Salgueiro P. Jones November 2013 ASCII HTML 9

This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).

draft-petithuguenin-behave-turn-uris-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7065
RFC7066 IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts J. Korhonen Editor J. Arkko Editor T. Savolainen S. Krishnan November 2013 ASCII HTML 20

As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), or Evolved Packet System (EPS) networks (hereafter collectively referred to as Third Generation Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316.

draft-ietf-v6ops-rfc3316bis-06 RFC3316 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7066
RFC7067 Directory Assistance Problem and High-Level Design Proposal L. Dunbar D. Eastlake 3rd R. Perlman I. Gashinsky November 2013 ASCII HTML 15 TRILL Orchestration Directory Push Pull RBridge ARP

Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus.

This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.

draft-ietf-trill-directory-framework-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7067
RFC7068 Diameter Overload Control Requirements E. McMurry B. Campbell November 2013 ASCII HTML 29

When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided.

draft-ietf-dime-overload-reqs-13 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7068
RFC7069 DECoupled Application Data Enroute (DECADE) R. Alimi A. Rahman D. Kutscher Y. Yang H. Song K. Pentikousis November 2013 ASCII HTML 35 decade

Content distribution applications, such as those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples.

draft-alimi-decade-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7069
RFC7070 An Architecture for Reputation Reporting N. Borenstein M. Kucherawy November 2013 ASCII HTML 14 domain security messaging dkim spf authentication reputation

This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model.

draft-ietf-repute-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7070
RFC7071 A Media Type for Reputation Interchange N. Borenstein M. Kucherawy November 2013 ASCII HTML 17 reputation domain security messaging dkim spf authentication

This document defines the format of reputation response data ("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets.

draft-ietf-repute-media-type-13 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7071
RFC7072 A Reputation Query Protocol N. Borenstein M. Kucherawy November 2013 ASCII HTML 9 reputation domain security messaging dkim spf authentication

This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.

draft-ietf-repute-query-http-11 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7072
RFC7073 A Reputation Response Set for Email Identifiers N. Borenstein M. Kucherawy November 2013 ASCII HTML 8 reputation domain security messaging dkim spf authentication

This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.

draft-ietf-repute-email-identifiers-10 PROPOSED STANDARD PROPOSED STANDARD IETF app repute 10.17487/RFC7073
RFC7074 Revised Definition of the GMPLS Switching Capability and Type Fields L. Berger J. Meuric November 2013 ASCII HTML 9

GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.

draft-ietf-ccamp-swcaps-update-03 RFC3471 RFC4202 RFC4203 RFC5307 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7074
RFC7075 Realm-Based Redirection In Diameter T. Tsou R. Hao T. Taylor Editor November 2013 ASCII HTML 10 Diameter routing

The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".

This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs).

draft-ietf-dime-realm-based-redirect-13 RFC6733 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7075
RFC7076 P6R's Secure Shell Public Key Subsystem M. Joseph J. Susoy November 2013 ASCII HTML 11 key management certificate management security

The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.

The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).

The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).

Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.

draft-joseph-pkix-p6rsshextension-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7076
RFC7077 Update Notifications for Proxy Mobile IPv6 S. Krishnan S. Gundavelli M. Liebsch H. Yokota J. Korhonen November 2013 ASCII HTML 21 MIPv6

This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose.

draft-ietf-netext-update-notifications-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7077
RFC7078 Distributing Address Selection Policy Using DHCPv6 A. Matsumoto T. Fujisaki T. Chown January 2014 ASCII HTML 12

RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site.

draft-ietf-6man-addr-select-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7078
RFC7079 The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results N. Del Regno Editor A. Malis Editor November 2013 ASCII HTML 41 Control Word (CW) Control Channel (CC)

The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual Circuit Connectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word.

draft-ietf-pwe3-vccv-impl-survey-results-03 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7079
RFC7080 Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges A. Sajassi S. Salam N. Bitar F. Balus December 2013 ASCII HTML 26 h-vpls

The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008. It aims to improve the scalability of Media Access Control (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access.

draft-ietf-l2vpn-pbb-vpls-interop-06 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7080
RFC7081 CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) E. Ivov P. Saint-Andre E. Marocco November 2013 ASCII HTML 19 real-time communication unified communication voice video instant messaging chat presence telephony

This document suggests some strategies for the combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real-time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication.

draft-ivov-xmpp-cusax-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7081
RFC7082 Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) R. Shekh-Yusef M. Barnes December 2013 ASCII HTML 10

The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.

This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.

draft-yusef-dispatch-ccmp-indication-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7082
RFC7083 Modification to Default Values of SOL_MAX_RT and INF_MAX_RT R. Droms November 2013 ASCII HTML 7

This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with new values.

draft-ietf-dhc-dhcpv6-solmaxrt-update-05 RFC8415 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7083
RFC7084 Basic Requirements for IPv6 Customer Edge Routers H. Singh W. Beebee C. Donley B. Stark November 2013 ASCII HTML 21 6rd DS-Lite

This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.

draft-ietf-v6ops-6204bis-12 RFC6204 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7084
RFC7085 Top-Level Domains That Are Already Dotless J. Levine P. Hoffman December 2013 ASCII HTML 6 DNS

Recent statements from the Internet Architecture Board (IAB) and the Internet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others.

draft-hoffine-already-dotless-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7085
RFC7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) A. Keranen G. Camarillo J. Maenpaa January 2014 ASCII HTML 10 HIP overlay P2P

This document is the HIP-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.

draft-ietf-hip-reload-instance-10 EXPERIMENTAL EXPERIMENTAL IETF int hip 10.17487/RFC7086
RFC7087 A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations H. van Helvoort Editor L. Andersson Editor N. Sprecher Editor December 2013 ASCII HTML 21

The MPLS Transport Profile (MPLS-TP) is based on a profile of the MPLS and Pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force (IETF). The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has specified a Transport Network architecture.

This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network Recommendations.

It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context.

draft-ietf-mpls-tp-rosetta-stone-13 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7087
RFC7088 Session Initiation Protocol Service Example -- Music on Hold D. Worley February 2014 ASCII HTML 36 Music on hold

"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards-compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music-on-hold method described in Section 2.3 of RFC 5359.

draft-worley-service-example-15 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7088
RFC7089 HTTP Framework for Time-Based Access to Resource States -- Memento H. Van de Sompel M. Nelson R. Sanderson December 2013 ASCII HTML 50 HTTP content negotiation datetime negotiation resource versions archival resources Memento

The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.

draft-vandesompel-memento-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7089
RFC7090 Public Safety Answering Point (PSAP) Callback H. Schulzrinne H. Tschofenig C. Holmberg M. Patel April 2014 ASCII HTML 18 PSAP callback SIP emergency VoIP

After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim. A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.

The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to mark PSAP callbacks.

draft-ietf-ecrit-psap-callback-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7090
RFC7091 GOST R 34.10-2012: Digital Signature Algorithm V. Dolmatov Editor A. Degtyarev December 2013 ASCII HTML 21

This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832.

draft-dolmatov-gost34102012-00 RFC5832 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7091
RFC7092 A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents H. Kaplan V. Pascual December 2013 ASCII HTML 10 SIP B2BUA taxonomy

In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).

There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.

draft-ietf-straw-b2bua-taxonomy-03 INFORMATIONAL INFORMATIONAL IETF rai straw 10.17487/RFC7092
RFC7093 Additional Methods for Generating Key Identifiers Values S. Turner S. Kent J. Manger December 2013 ASCII HTML 5

This document specifies additional example methods for generating Key Identifier values for use in the AKI (Authority Key Identifier) and SKI (Subject Key Identifier) certificate extensions.

draft-turner-additional-methods-4kis-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7093
RFC7094 Architectural Considerations of IP Anycast D. McPherson D. Oran D. Thaler E. Osterweil January 2014 ASCII HTML 22 anycast architecture

This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.

draft-iab-anycast-arch-implications-12 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7094
RFC7095 jCard: The JSON Format for vCard P. Kewisch January 2014 ASCII HTML 29 jCard JSON vCard addressbook contacts CardDAV PIM

This specification defines "jCard", a JSON format for vCard data. The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications.

draft-ietf-jcardcal-jcard-07 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal 10.17487/RFC7095
RFC7096 Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) S. Belotti Editor P. Grandi D. Ceccarelli Editor D. Caviglia F. Zhang D. Li January 2014 ASCII HTML 23 Routing CCAMP Working Group OSPF GMPLS G709 OTN

ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).

This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.

draft-ietf-ccamp-otn-g709-info-model-13 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7096
RFC7097 RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets J. Ott V. Singh Editor I. Curcio January 2014 ASCII HTML 11 RTP RTCP discard metrics

The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception.

draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7097
RFC7098 Using the IPv6 Flow Label for Load Balancing in Server Farms B. Carpenter S. Jiang W. Tarreau January 2014 ASCII HTML 13 ECMP

This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms.

draft-ietf-intarea-flow-label-balancing-03 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7098
RFC7099 RFC7100 Retirement of the "Internet Official Protocol Standards" Summary Document P. Resnick December 2013 ASCII HTML 3

This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.

draft-resnick-retire-std1-01 RFC5000 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7100
RFC7101 List of Internet Official Protocol Standards: Replaced by a Web Page S. Ginoza December 2013 ASCII HTML 4

At one time, the RFC Editor published snapshots of the "Internet Official Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFC Editor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment.

draft-rfced-rfcxx00-retired-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7101
RFC7102 Terms Used in Routing for Low-Power and Lossy Networks JP. Vasseur January 2014 ASCII HTML 8

This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power and Lossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration.

draft-ietf-roll-terminology-13 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7102
RFC7103 Advice for Safe Handling of Malformed Messages M. Kucherawy G. Shapiro N. Freed January 2014 ASCII HTML 24 MTA SMTP

Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.

draft-ietf-appsawg-malformed-mail-11 INFORMATIONAL INFORMATIONAL IETF app appsawg 10.17487/RFC7103
RFC7104 Duplication Grouping Semantics in the Session Description Protocol A. Begen Y. Cai H. Ou January 2014 ASCII HTML 10 SDP ssrc synchronization source grouping framework

Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework. Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.

draft-ietf-mmusic-duplication-grouping-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7104
RFC7105 Using Device-Provided Location-Related Measurements in Location Configuration Protocols M. Thomson J. Winterbottom January 2014 ASCII HTML 74 HELD Location Measurements Device-based

This document describes a protocol for a Device to provide location-related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.

draft-ietf-geopriv-held-measurements-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7105
RFC7106 A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State E. Ivov January 2014 ASCII HTML 6 SIP Conference Event Package service-uris conference-uris URI purpose

This document defines and registers a value of "grouptextchat" ("Group Text Chat") for the URI <purpose> element of SIP's Conference Event Package.

draft-ivov-grouptextchat-purpose-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7106
RFC7107 Object Identifier Registry for the S/MIME Mail Security Working Group R. Housley January 2014 ASCII HTML 18

When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

draft-housley-smime-oids-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7107
RFC7108 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes J. Abley T. Manderson January 2014 ASCII HTML 11

Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.

Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.

This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.

draft-jabley-dnsop-anycast-mapping-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7108 10.17487/RFC7108
RFC7109 Flow Bindings Initiated by Home Agents for Mobile IPv6 H. Yokota D. Kim B. Sarikaya F. Xia February 2014 ASCII HTML 18 MIPv6 Flow mobility

There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.

draft-yokota-mext-ha-init-flow-binding-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7109
RFC7110 Return Path Specified Label Switched Path (LSP) Ping M. Chen W. Cao S. Ning F. Jounay S. Delord January 2014 ASCII HTML 21 Tunnel Stack Reply TC

This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness.

draft-ietf-mpls-return-path-specified-lsp-ping-15 RFC7737 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7110 10.17487/RFC7110
RFC7111 URI Fragment Identifiers for the text/csv Media Type M. Hausenblas E. Wilde J. Tennison January 2014 ASCII HTML 13 mime

This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell. Fragment identification can use single items or ranges.

draft-hausenblas-csv-fragment-08 RFC4180 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7111 10.17487/RFC7111
RFC7112 Implications of Oversized IPv6 Header Chains F. Gont V. Manral R. Bonica January 2014 ASCII HTML 8

The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.

draft-ietf-6man-oversized-header-chain-09 RFC2460 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7112
RFC7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) F. Gont February 2014 ASCII HTML 13

The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.

draft-ietf-v6ops-ra-guard-implementation-07 RFC6105 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7113
RFC7114 Creation of a Registry for smime-type Parameter Values B. Leiba January 2014 ASCII HTML 4

Secure/Multipurpose Internet Mail Extensions (S/MIME) defined the Content-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values.

draft-leiba-smime-type-registry-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7114
RFC7115 Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI) R. Bush January 2014 ASCII HTML 11

Deployment of BGP origin validation that is based on the Resource Public Key Infrastructure (RPKI) has many operational considerations. This document attempts to collect and present those that are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood.

draft-ietf-sidr-origin-ops-23 BCP0185 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7115 10.17487/RFC7115
RFC7116 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries K. Scott M. Blanchet February 2014 ASCII HTML 10

The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions.

draft-dtnrg-ltp-cbhe-registries-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7116
RFC7117 Multicast in Virtual Private LAN Service (VPLS) R. Aggarwal Editor Y. Kamite L. Fang Y. Rekhter C. Kodeboniya February 2014 ASCII HTML 50

RFCs 4761 and 4762 describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.

This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances.

draft-ietf-l2vpn-vpls-mcast-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7117
RFC7118 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) I. Baz Castillo J. Millan Villegas V. Pascual January 2014 ASCII HTML 25 SIP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.

draft-ietf-sipcore-sip-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore http://www.rfc-editor.org/errata_search.php?rfc=7118 10.17487/RFC7118
RFC7119 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators B. Claise A. Kobayashi B. Trammell February 2014 ASCII HTML 32

This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns.

draft-ietf-ipfix-mediation-protocol-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7119
RFC7120 Early IANA Allocation of Standards Track Code Points M. Cotton January 2014 ASCII HTML 9 early allocation policy protocol

This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.

draft-cotton-rfc4020bis-02 RFC4020 BCP0100 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7120
RFC7121 High Availability within a Forwarding and Control Element Separation (ForCES) Network Element K. Ogawa W. Wang E. Haleplidis J. Hadi Salim February 2014 ASCII HTML 31 ForCES HA

This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) Network Element (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism.

draft-ietf-forces-ceha-10 RFC5810 RFC7391 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=7121 10.17487/RFC7121
RFC7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) H. Kruse S. Jero S. Ostermann March 2014 ASCII HTML 11

This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.

draft-irtf-dtnrg-dgram-clayer-05 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7122
RFC7123 Security Implications of IPv6 on IPv4 Networks F. Gont W. Liu February 2014 ASCII HTML 19

This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues.

draft-ietf-opsec-ipv6-implications-on-ipv4-nets-07 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7123
RFC7124 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB E. Beili February 2014 ASCII HTML 6 EFM-CU-MIB ieee

This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group.

draft-ietf-opsawg-rfc5066bis-07 RFC5066 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7124
RFC7125 Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element B. Trammell P. Aitken February 2014 ASCII HTML 6

This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.

draft-trammell-ipfix-tcpcontrolbits-revision-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7125
RFC7126 Recommendations on Filtering of IPv4 Packets Containing IPv4 Options F. Gont R. Atkinson C. Pignataro February 2014 ASCII HTML 36

This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.

draft-ietf-opsec-ip-options-filtering-07 BCP0186 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7126 10.17487/RFC7126
RFC7127 Characterization of Proposed Standards O. Kolkman S. Bradner S. Turner January 2014 ASCII HTML 5 Guidance Standards Standards Process Advancement Proposed Standard

RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.

draft-kolkman-proposed-standards-clarified-06 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7127
RFC7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report R. Bush R. Austein K. Patel H. Gredler M. Waehlisch February 2014 ASCII HTML 11 routing security

This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab.

draft-ietf-sidr-rpki-rtr-impl-05 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7128
RFC7129 Authenticated Denial of Existence in the DNS R. Gieben W. Mekking February 2014 ASCII HTML 30 Internet DNSSEC Denial of Existence NSEC NSEC3

Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.

This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.

draft-gieben-auth-denial-of-existence-dns-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7129
RFC7130 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces M. Bhatia Editor M. Chen Editor S. Boutros Editor M. Binderberger Editor J. Haas Editor February 2014 ASCII HTML 11

This document defines a mechanism to run Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link.

This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of Layer 3 (L3) bidirectional forwarding.

draft-ietf-bfd-on-lags-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7130 10.17487/RFC7130
RFC7131 Session Initiation Protocol (SIP) History-Info Header Call Flow Examples M. Barnes F. Audet S. Schubert H. van Elburg C. Holmberg March 2014 ASCII HTML 52 SIP History-Info RFC4244bis Example Call Flow

This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details.

draft-ietf-sipcore-rfc4244bis-callflows-08 INFORMATIONAL INFORMATIONAL IETF rai sipcore 10.17487/RFC7131
RFC7132 Threat Model for BGP Path Security S. Kent A. Chi February 2014 ASCII HTML 20 BGPSEC RPKI SIDR

This document describes a threat model for the context in which External Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the Resource Public Key Infrastructure (RPKI) and focuses on the ability of an Autonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to any BGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of the RPKI.

The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in the BGP-4 standard. It concludes with a brief discussion of residual vulnerabilities.

draft-ietf-sidr-bgpsec-threats-09 INFORMATIONAL INFORMATIONAL IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7132 10.17487/RFC7132
RFC7133 Information Elements for Data Link Layer Traffic Measurement S. Kashima A. Kobayashi Editor P. Aitken May 2014 ASCII HTML 41 IPFIX PSAMP Provider Bridge Provider Backbone Bridge ipfix

This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.

draft-ietf-ipfix-data-link-layer-monitoring-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7133
RFC7134 The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" B. Rosen March 2014 ASCII HTML 2 Resource-Priority Namespaces Resource-Priority Priority-values

RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updates RFC 4412 to change the management policy of these registries to "IETF Review".

draft-rosen-rph-reg-policy-01 RFC4412 PROPOSED STANDARD PROPOSED STANDARD IETF rai sipcore 10.17487/RFC7134
RFC7135 Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications J. Polk May 2014 ASCII HTML 9

This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations.

draft-polk-local-emergency-rph-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7135
RFC7136 Significance of IPv6 Interface Identifiers B. Carpenter S. Jiang February 2014 ASCII HTML 10

The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.

draft-ietf-6man-ug-06 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7136
RFC7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks A. Retana S. Ratliff February 2014 ASCII HTML 8

This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.

This document updates RFC 5820.

draft-ietf-ospf-manet-single-hop-or-04 RFC5820 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC7137
RFC7138 Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks D. Ceccarelli Editor F. Zhang S. Belotti R. Rao J. Drake March 2014 ASCII HTML 36 OSPF GMPLS G709 OTN

This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.

draft-ietf-ccamp-gmpls-ospf-g709v3-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7138
RFC7139 GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks F. Zhang Editor G. Zhang S. Belotti D. Ceccarelli K. Pithewan March 2014 ASCII HTML 27

ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.

This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.

draft-ietf-ccamp-gmpls-signaling-g709v3-12 RFC4328 RFC7892 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7139 10.17487/RFC7139
RFC7140 LDP Extensions for Hub and Spoke Multipoint Label Switched Path L. Jin F. Jounay IJ. Wijnands N. Leymann March 2014 ASCII HTML 15 P2MP LSP MP2MP LSP

This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.

draft-ietf-mpls-mldp-hsmp-06 RFC7358 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7140
RFC7141 Byte and Packet Congestion Notification B. Briscoe J. Manner February 2014 ASCII HTML 41 active queue management aqm availability denial of service dos quality of service qos congestion control fairness incentives architecture layering protocol

This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, including Random Early Detection (RED), BLUE, Pre- Congestion Notification (PCN), and newer schemes such as CoDel (Controlled Delay) and PIE (Proportional Integral controller Enhanced). We give three strong recommendations: (1) packet size should be taken into account when transports detect and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte- mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms.

draft-ietf-tsvwg-byte-pkt-congest-12 RFC2309 RFC2914 BCP0041 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC7141
RFC7142 Reclassification of RFC 1142 to Historic M. Shand L. Ginsberg February 2014 ASCII HTML 3

This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain Routing Protocol", to Historic status. This memo also obsoletes RFC 1142.

draft-ietf-isis-rfc1142-to-historic-00 RFC1142 INFORMATIONAL INFORMATIONAL IETF rtg isis 10.17487/RFC7142
RFC7143 Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) M. Chadalapaka J. Satran K. Meth D. Black April 2014 ASCII HTML 295 iSCSI SCSI storage SAN block storage SCSI object storage devices OSD SAM disk T10

This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.

This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.

draft-ietf-storm-iscsi-cons-10 RFC3720 RFC3980 RFC4850 RFC5048 RFC3721 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7143
RFC7144 Internet Small Computer System Interface (iSCSI) SCSI Features Update F. Knight M. Chadalapaka April 2014 ASCII HTML 25

Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5.

draft-ietf-storm-iscsi-sam-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7144
RFC7145 Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification M. Ko A. Nezhinsky April 2014 ASCII HTML 91

Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.

This document obsoletes RFC 5046.

draft-ietf-storm-iser-15 RFC5046 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7145
RFC7146 Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 D. Black P. Koning April 2014 ASCII HTML 18 IPsec

RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP). This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published.

draft-ietf-storm-ipsec-ips-update-04 RFC3720 RFC3723 RFC3821 RFC3822 RFC4018 RFC4172 RFC4173 RFC4174 RFC5040 RFC5041 RFC5042 RFC5043 RFC5044 RFC5045 RFC5046 RFC5047 RFC5048 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7146
RFC7147 Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI) M. Bakke P. Venkatesen April 2014 ASCII HTML 92 ISCSI-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP).

This document obsoletes RFC 4544.

draft-ietf-storm-iscsimib-04 RFC4544 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm 10.17487/RFC7147
RFC7148 Prefix Delegation Support for Proxy Mobile IPv6 X. Zhou J. Korhonen C. Williams S. Gundavelli CJ. Bernardos March 2014 ASCII HTML 27 Prefix Delegation Proxy Mobile IPv6 PMIPv6 Mobile Router

This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes.

draft-ietf-netext-pd-pmip-14 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7148
RFC7149 Software-Defined Networking: A Perspective from within a Service Provider Environment M. Boucadair C. Jacquenet March 2014 ASCII HTML 20 Network Automation Policy Management Connectivity Provisioning Service Parameter Exposure Dynamic Negotiation Dynamic Service Provisioning Autonomic Programmable Networks

Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.

It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification.

draft-sin-sdnrg-sdn-approach-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7149
RFC7150 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2014 ASCII HTML 12

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.

draft-ietf-pce-vendor-constraints-11 RFC7470 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7150
RFC7151 File Transfer Protocol HOST Command for Virtual Hosts P. Hethmon R. McMurray March 2014 ASCII HTML 24 FTP HOST

The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server.

draft-hethmon-mcmurray-ftpext-ftp-hosts-05 RFC0959 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7151
RFC7152 Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) R. Key Editor S. DeLord F. Jounay L. Huang Z. Liu M. Paul March 2014 ASCII HTML 12 RMP Rooted-Multipoint VPLS Virtual Private LAN Service E-VPN Ethernet Virtual Private Network MPLS Multi-Protocol Label Switching CE Carrier Ethernet

This document provides functional requirements for the support of Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer 2 Virtual Private Network solutions (referred to as simply "L2VPN"). It is intended that potential solutions will use these requirements as guidelines.

draft-ietf-l2vpn-etree-reqt-05 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7152
RFC7153 IANA Registries for BGP Extended Communities E. Rosen Y. Rekhter March 2014 ASCII HTML 16 Border Gateway Protocol

This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the "IANA Considerations" sections of future protocol specifications. This document updates RFC 4360 and RFC 5701.

draft-ietf-idr-extcomm-iana-02 RFC4360 RFC5701 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7153
RFC7154 IETF Guidelines for Conduct S. Moonesamy Editor March 2014 ASCII HTML 7

This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.

This document is an updated version of the guidelines for conduct originally published in RFC 3184.

draft-moonesamy-ietf-conduct-3184bis-07 RFC3184 BCP0054 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7154
RFC7155 Diameter Network Access Server Application G. Zorn Editor April 2014 ASCII HTML 70 AAA Authentication Authorization Accounting Remote Access

This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements.

draft-ietf-dime-rfc4005bis-14 RFC4005 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=7155 10.17487/RFC7155
RFC7156 Diameter Support for Proxy Mobile IPv6 Localized Routing G. Zorn Q. Wu J. Korhonen April 2014 ASCII HTML 11

In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol.

draft-ietf-dime-pmip6-lr-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7156
RFC7157 IPv6 Multihoming without Network Address Translation O. Troan Editor D. Miles S. Matsushima T. Okimoto D. Wing March 2014 ASCII HTML 22 NPTv6

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.

draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7157
RFC7158 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII HTML 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

draft-ietf-json-rfc4627bis-10 RFC7159 PROPOSED STANDARD PROPOSED STANDARD IETF app json 10.17487/RFC7158
RFC7159 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor March 2014 ASCII HTML 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

draft-ietf-json-rfc4627bis-rfc7159bis RFC4627 RFC7158 RFC8259 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7159 10.17487/RFC7159
RFC7160 Support for Multiple Clock Rates in an RTP Session M. Petit-Huguenin G. Zorn Editor April 2014 ASCII HTML 13

This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550.

draft-ietf-avtext-multiple-clock-rates-11 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7160
RFC7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) LM. Contreras CJ. Bernardos I. Soto March 2014 ASCII HTML 37 PMIPv6 Proxy Mobile IPv6 multicast handover SIAL

This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).

draft-ietf-multimob-handover-optimization-07 EXPERIMENTAL EXPERIMENTAL IETF int multimob http://www.rfc-editor.org/errata_search.php?rfc=7161 10.17487/RFC7161
RFC7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) A. Melnikov D. Cridland May 2014 ASCII HTML 52 IMAP CONDSTORE QRESYNC VANISHED EXPUNGE quick resynchronization

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.

Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.

This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.

Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683.

draft-ietf-qresync-rfc5162bis-10 RFC4551 RFC5162 RFC2683 PROPOSED STANDARD PROPOSED STANDARD IETF app qresync http://www.rfc-editor.org/errata_search.php?rfc=7162 10.17487/RFC7162
RFC7163 URN for Country-Specific Emergency Services C. Holmberg I. Sedlacek March 2014 ASCII HTML 4 sip emergency urn country 5031 sos

This document updates the registration guidance provided in Section 4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country.

draft-ietf-ecrit-country-emg-urn-03 RFC5031 PROPOSED STANDARD PROPOSED STANDARD IETF rai ecrit 10.17487/RFC7163
RFC7164 RTP and Leap Seconds K. Gross R. Brandenburg March 2014 ASCII HTML 9 Leap second rtp Real-time Transport Protocol ntp Network Time Protocol UTC Universal Coordinated Time tai International Atomic Time Unix time

This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.

draft-ietf-avtcore-leap-second-08 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7164
RFC7165 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) R. Barnes April 2014 ASCII HTML 25 JWS JWE JWK JWA JWT CMS S/MIME JOSE XMPP ALTO OAuth

Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.

draft-ietf-jose-use-cases-06 INFORMATIONAL INFORMATIONAL IETF sec jose 10.17487/RFC7165
RFC7166 Supporting Authentication Trailer for OSPFv3 M. Bhatia V. Manral A. Lindem March 2014 ASCII HTML 23

Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.

The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.

draft-ietf-ospf-rfc6506bis-05 RFC6506 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7166
RFC7167 A Framework for Point-to-Multipoint MPLS in Transport Networks D. Frost S. Bryant M. Bocci L. Berger April 2014 ASCII HTML 12 mpls-tp mpls

The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to-multipoint transport paths.

draft-ietf-mpls-tp-p2mp-framework-06 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7167
RFC7168 The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) I. Nazar April 1 2014 ASCII HTML 7

The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.

draft-nazar-htcpcp-tea-00 RFC2324 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7168
RFC7169 The NSA (No Secrecy Afforded) Certificate Extension S. Turner April 1 2014 ASCII HTML 3

This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party. Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.

draft-turner-no-secrecy-afforded-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7169
RFC7170 Tunnel Extensible Authentication Protocol (TEAP) Version 1 H. Zhou N. Cam-Winget J. Salowey S. Hanna May 2014 ASCII HTML 101 EAP Tunnel

This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.

draft-ietf-emu-eap-tunnel-method-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu http://www.rfc-editor.org/errata_search.php?rfc=7170 10.17487/RFC7170
RFC7171 PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods N. Cam-Winget P. Sangster May 2014 ASCII HTML 19 NEA EAP

This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport Layer Security (TLS). The document also describes the intended applicability of PT-EAP.

draft-ietf-nea-pt-eap-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec nea 10.17487/RFC7171
RFC7172 Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling D. Eastlake 3rd M. Zhang P. Agarwal R. Perlman D. Dutt May 2014 ASCII HTML 27 TRILL VLAN Fine-Grained Label

The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.

draft-ietf-trill-fine-labeling-07 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7172
RFC7173 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires L. Yong D. Eastlake 3rd S. Aldrin J. Hudson May 2014 ASCII HTML 11 TRILL pseudowires MPLS RBridge

This document specifies how to interconnect a pair of Transparent Interconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End (PWE3) standards.

draft-ietf-trill-o-pw-06 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7173
RFC7174 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework S. Salam T. Senevirathne S. Aldrin D. Eastlake 3rd May 2014 ASCII HTML 33 RBridge CFM BFD MEP MIP MA Fault Performance Maintenance Continuity Connectivity Delay Operations Administration

This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM.

draft-ietf-trill-oam-framework-04 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7174
RFC7175 Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support V. Manral D. Eastlake 3rd D. Ward A. Banerjee May 2014 ASCII HTML 12 RBridge Echo one-hop

This document specifies use of the Bidirectional Forwarding Detection (BFD) protocol in Routing Bridge (RBridge) campuses based on the RBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.

BFD is a widely deployed Operations, Administration, and Maintenance (OAM) mechanism in IP and MPLS networks, using UDP and Associated Channel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL.

draft-ietf-trill-rbridge-bfd-07 RFC8564 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7175
RFC7176 Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS D. Eastlake 3rd T. Senevirathne A. Ghanwani D. Dutt A. Banerjee May 2014 ASCII HTML 45 Affinity multicast multi-topology fine-grained VLAN

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326.

draft-ietf-isis-rfc6326bis-03 RFC6326 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7176
RFC7177 Transparent Interconnection of Lots of Links (TRILL): Adjacency D. Eastlake 3rd R. Perlman A. Ghanwani H. Yang V. Manral May 2014 ASCII HTML 35 RBridge TRILL Adjacency BFD p2p point-to-point

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System (IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.

draft-ietf-trill-rfc6327bis-04 RFC6327 RFC6325 RFC7780 RFC8139 RFC8249 RFC8377 RFC8564 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7177
RFC7178 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support D. Eastlake 3rd V. Manral Y. Li S. Aldrin D. Ward May 2014 ASCII HTML 21 TRILL native

This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol.

draft-ietf-trill-rbridge-channel-08 RFC7978 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7178
RFC7179 Transparent Interconnection of Lots of Links (TRILL): Header Extension D. Eastlake 3rd A. Ghanwani V. Manral Y. Li C. Bestler May 2014 ASCII HTML 12 RBridge extension option

The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325.

draft-ietf-trill-rbridge-extension-05 RFC6325 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7179
RFC7180 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang A. Ghanwani V. Manral A. Banerjee May 2014 ASCII HTML 24 TRILL RBridge IS-IS reachability overload MTU DEI multicast

The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.

RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.

draft-ietf-trill-clear-correct-06 RFC7780 RFC6325 RFC6327 RFC6439 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7180
RFC7181 The Optimized Link State Routing Protocol Version 2 T. Clausen C. Dearlove P. Jacquet U. Herberg April 2014 ASCII HTML 115 MANET ad hoc network NHDP

This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).

draft-ietf-manet-olsrv2-19 RFC7183 RFC7187 RFC7188 RFC7466 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7181 10.17487/RFC7181
RFC7182 Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) U. Herberg T. Clausen C. Dearlove April 2014 ASCII HTML 31 NHDP OLSRv2 security integrity routing

This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively.

draft-ietf-manet-rfc6622-bis-06 RFC6622 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7182 10.17487/RFC7182
RFC7183 Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) U. Herberg C. Dearlove T. Clausen April 2014 ASCII HTML 15 MANET OLSRv2 Security Integrity protection ICV

This document specifies integrity and replay protection for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a Timestamp TLV based on Portable Operating System Interface (POSIX) time.

The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444.

This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2.

draft-ietf-manet-nhdp-olsrv2-sec-05 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7183 10.17487/RFC7183
RFC7184 Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 U. Herberg R. Cole T. Clausen April 2014 ASCII HTML 86 Network Management Management Information Base MIB SMIv2 Routing MANET Optimized Link STate Routing Protocol version 2

This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing Protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers.

draft-ietf-manet-olsrv2-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7184
RFC7185 Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale C. Dearlove T. Clausen P. Jacquet April 2014 ASCII HTML 25 MANET ad hoc network proactive NHDP neighborhood discovery OLSR OLSRv2 routing protocol metrics

The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.

draft-ietf-manet-olsrv2-metrics-rationale-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7185
RFC7186 Security Threats for the Neighborhood Discovery Protocol (NHDP) J. Yi U. Herberg T. Clausen April 2014 ASCII HTML 20

This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP) and describes their potential impacts on Mobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described.

draft-ietf-manet-nhdp-sec-threats-06 RFC7985 INFORMATIONAL INFORMATIONAL IETF rtg manet http://www.rfc-editor.org/errata_search.php?rfc=7186 10.17487/RFC7186
RFC7187 Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen April 2014 ASCII HTML 5

This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization.

draft-ietf-manet-olsrv2-rmpr-optimization-01 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7187
RFC7188 Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs C. Dearlove T. Clausen April 2014 ASCII HTML 16 MANET OLSRv2 NHDP TLV

This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updates RFC 7181 (OLSRv2) and RFC 6130 (NHDP).

draft-ietf-manet-nhdp-olsrv2-tlv-extension-05 RFC6130 RFC7181 RFC7722 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7188
RFC7189 Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP) G. Mirsky March 2014 ASCII HTML 7 PW VCCV MPLS-TP CC/CV/RDI

This document specifies how signaling and selection processes for Pseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactive Connectivity Verification (CV), Continuity Check (CC), and Remote Defect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs. This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined.

draft-ietf-pwe3-mpls-tp-cv-adv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7189
RFC7190 Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) C. Villamizar March 2014 ASCII HTML 15 MPLS composite link link aggregation ECMP link bundling multipath MPLS-TP

Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.

Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed.

draft-ietf-mpls-multipath-use-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7190
RFC7191 Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types R. Housley April 2014 ASCII HTML 25

This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.

draft-housley-ct-keypackage-receipt-n-error-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7191
RFC7192 Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types S. Turner April 2014 ASCII HTML 6 Key Package Key Package Receipt Key Package Error

This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.

draft-turner-ct-keypackage-receipt-n-error-algs-04 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7192
RFC7193 The application/cms Media Type S. Turner R. Housley J. Schaad April 2014 ASCII HTML 12 Cryptographic Message Syntax

This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types.

draft-turner-application-cms-media-type-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7193 10.17487/RFC7193
RFC7194 Default Port for Internet Relay Chat (IRC) via TLS/SSL R. Hartmann August 2014 ASCII HTML 6

This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL.

draft-hartmann-default-port-for-irc-via-tls-ssl-09 RFC1459 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7194
RFC7195 Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) M. Garcia-Martin S. Veikkolainen May 2014 ASCII HTML 39 PSTN

This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).

draft-ietf-mmusic-sdp-cs-23 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7195
RFC7196 Making Route Flap Damping Usable C. Pelsser R. Bush K. Patel P. Mohapatra O. Maennel May 2014 ASCII HTML 8 rfd

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process.

draft-ietf-idr-rfd-usable-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7196 10.17487/RFC7196
RFC7197 Duplication Delay Attribute in the Session Description Protocol A. Begen Y. Cai H. Ou April 2014 ASCII HTML 11 Interleaving temporal diversity temporal redundancy time shifted delayed duplication

A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply "delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol.

draft-ietf-mmusic-delayed-duplication-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7197
RFC7198 Duplicating RTP Streams A. Begen C. Perkins April 2014 ASCII HTML 13 RTP duplication live/live redundancy

Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules.

draft-ietf-avtext-rtp-duplication-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtext 10.17487/RFC7198
RFC7199 Location Configuration Extensions for Policy Management R. Barnes M. Thomson J. Winterbottom H. Tschofenig April 2014 ASCII HTML 20 geopriv geolocation privacy policy

Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules.

draft-ietf-geopriv-policy-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7199
RFC7200 A Session Initiation Protocol (SIP) Load-Control Event Package C. Shen H. Schulzrinne A. Koike April 2014 ASCII HTML 44 SIP Overload Control Server Performance

This specification defines a load-control event package for the Session Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts.

draft-ietf-soc-load-control-event-package-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7200
RFC7201 Options for Securing RTP Sessions M. Westerlund C. Perkins April 2014 ASCII HTML 37 Secure RTP SRTP key management real-time media

The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism.

draft-ietf-avtcore-rtp-security-options-10 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7201
RFC7202 Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution C. Perkins M. Westerlund April 2014 ASCII HTML 10 SRTP RTP Profile Payload Format

This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.

draft-ietf-avt-srtp-not-mandatory-16 INFORMATIONAL INFORMATIONAL IETF rai avtcore 10.17487/RFC7202
RFC7203 An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information T. Takahashi K. Landfield Y. Kadobayashi April 2014 ASCII HTML 28 data structure information architecture incident response response team security incident information exchange knowledge sharing security operation automation vulnerability CERT CSIRT

This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.

draft-ietf-mile-sci-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=7203 10.17487/RFC7203
RFC7204 Requirements for Labeled NFS T. Haynes April 2014 ASCII HTML 18 NFSv4

This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside.

draft-ietf-nfsv4-labreqs-05 INFORMATIONAL INFORMATIONAL IETF tsv nfsv4 10.17487/RFC7204
RFC7205 Use Cases for Telepresence Multistreams A. Romanow S. Botzko M. Duckworth R. Even Editor April 2014 ASCII HTML 17

Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co-located presence through multimedia communication that includes at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference.

draft-ietf-clue-telepresence-use-cases-09 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7205
RFC7206 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro J. Polk L. Liess H. Kaplan May 2014 ASCII HTML 15

This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains.

draft-ietf-insipid-session-id-reqts-11 INFORMATIONAL INFORMATIONAL IETF rai insipid 10.17487/RFC7206
RFC7207 A Uniform Resource Name (URN) Namespace for Eurosystem Messaging M. Ortseifen G. Dickfeld April 2014 ASCII HTML 8 URN Namespace Eurosystem TARGET2 TARGET2-Securities ESCB

This document defines and registers with IANA a Uniform Resource Name (URN) namespace for usage within messages standardized by the Eurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB).

draft-bundesbank-eurosystem-namespace-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7207
RFC7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 S. Kitterman April 2014 ASCII HTML 64 spoofing spf anti-forgery authentication

Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.

This document obsoletes RFC 4408.

draft-ietf-spfbis-4408bis-21 RFC4408 RFC7372 RFC8553 RFC8616 PROPOSED STANDARD PROPOSED STANDARD IETF app spfbis http://www.rfc-editor.org/errata_search.php?rfc=7208 10.17487/RFC7208
RFC7209 Requirements for Ethernet VPN (EVPN) A. Sajassi R. Aggarwal J. Uttaro N. Bitar W. Henderickx A. Isaac May 2014 ASCII HTML 15 ethernet l2vpn

The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.

draft-ietf-l2vpn-evpn-req-07 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7209
RFC7210 Database of Long-Lived Symmetric Cryptographic Keys R. Housley T. Polk S. Hartman D. Zhang April 2014 ASCII HTML 14

This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database. In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.

draft-ietf-karp-crypto-key-table-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg karp http://www.rfc-editor.org/errata_search.php?rfc=7210 10.17487/RFC7210
RFC7211 Operations Model for Router Keying S. Hartman D. Zhang June 2014 ASCII HTML 18

The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.

draft-ietf-karp-ops-model-10 INFORMATIONAL INFORMATIONAL IETF rtg karp 10.17487/RFC7211
RFC7212 MPLS Generic Associated Channel (G-ACh) Advertisement Protocol D. Frost S. Bryant M. Bocci June 2014 ASCII HTML 23

The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes.

draft-ietf-mpls-gach-adv-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7212
RFC7213 MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing D. Frost S. Bryant M. Bocci June 2014 ASCII HTML 9 MPLS

The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets.

draft-ietf-mpls-tp-ethernet-addressing-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7213
RFC7214 Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry L. Andersson C. Pignataro May 2014 ASCII HTML 7

RFC 5586 generalized the applicability of the pseudowire Associated Channel Header (PW-ACH) into the Generic Associated Channel G-ACh. However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries. This document coalesces these into a new "Generic Associated Channel (G-ACh) Parameters" registry under the "Multiprotocol Label Switching Architecture (MPLS)" heading. This document updates RFC 5586.

This document also updates RFCs 6374, 6378, 6427, and 6428.

draft-ietf-mpls-moving-iana-registries-04 RFC5586 RFC6374 RFC6378 RFC6427 RFC6428 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7214
RFC7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations L. Jakab A. Cabellos-Aparicio F. Coras J. Domingo-Pascual D. Lewis April 2014 ASCII HTML 30 LISP deployment

This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.

draft-ietf-lisp-deployment-12 EXPERIMENTAL EXPERIMENTAL IETF int lisp 10.17487/RFC7215
RFC7216 Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS M. Thomson R. Bellis April 2014 ASCII HTML 18 HELD LIS Discovery NAT Residential Gateway

The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.

This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.

draft-ietf-geopriv-res-gw-lis-discovery-08 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7216
RFC7217 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) F. Gont April 2014 ASCII HTML 19

This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control (MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes (and their corresponding addresses).

draft-ietf-6man-stable-privacy-addresses-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7217
RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) O. Gudmundsson April 2014 ASCII HTML 5 DNSSEC DANE Applications

Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698.

draft-ietf-dane-registry-acronyms-04 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7218
RFC7219 SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) M. Bagnulo A. Garcia-Martinez May 2014 ASCII HTML 38 IPv6 ingress filtering packet filtering Neighbor Discovery

This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.

draft-ietf-savi-send-11 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7219
RFC7220 Description Option for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing May 2014 ASCII HTML 6

This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does this by defining a new DESCRIPTION option.

draft-ietf-pcp-description-option-05 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7220
RFC7221 Handling of Internet-Drafts by IETF Working Groups A. Farrel D. Crocker Editor April 2014 ASCII HTML 14 IETF process working group Internet-Draft adoption handling creation

The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.

draft-crocker-id-adoption-09 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7221
RFC7222 Quality-of-Service Option for Proxy Mobile IPv6 M. Liebsch P. Seite H. Yokota J. Korhonen S. Gundavelli May 2014 ASCII HTML 58 QoS Quality of Service PMIP-QoS PMIPv6-QoS WiFi-QoS 3GPP-QoS

This specification defines a new mobility option, the Quality-of- Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches.

draft-ietf-netext-pmip6-qos-12 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7222
RFC7223 A YANG Data Model for Interface Management M. Bjorklund May 2014 ASCII HTML 39 NETCONF ietf-interfaces

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).

draft-ietf-netmod-interfaces-cfg-16 RFC8343 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7223 10.17487/RFC7223
RFC7224 IANA Interface Type YANG Module M. Bjorklund May 2014 ASCII HTML 37 yang netconf iana-if-type

This document defines the initial version of the iana-if-type YANG module.

draft-ietf-netmod-iana-if-type-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7224
RFC7225 Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) M. Boucadair May 2014 ASCII HTML 17

This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals.

draft-ietf-pcp-nat64-prefix64-06 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7225
RFC7226 Requirements for Advanced Multipath in MPLS Networks C. Villamizar Editor D. McDysan Editor S. Ning A. Malis L. Yong May 2014 ASCII HTML 17 MPLS Advanced Multipath composite link link aggregation ECMP link bundling delay metric

This document provides a set of requirements for Advanced Multipath in MPLS networks.

Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques.

draft-ietf-rtgwg-cl-requirement-16 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7226
RFC7227 Guidelines for Creating New DHCPv6 Options D. Hankins T. Mrugalski M. Siodelski S. Jiang S. Krishnan May 2014 ASCII HTML 35 DHCPv6 option guidelines option guidance option format

This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.

draft-ietf-dhc-option-guidelines-17 RFC3315 BCP0187 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=7227 10.17487/RFC7227
RFC7228 Terminology for Constrained-Node Networks C. Bormann M. Ersue A. Keranen May 2014 ASCII HTML 17 IoT Internet of Things Embedded Internet Smart Object Sensor Network WSN Constrained node Constrained network LLN LoWPAN 6LoWPAN Always-on Low-power Energy efficient

The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.

draft-ietf-lwig-terminology-07 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7228
RFC7229 Object Identifiers for Test Certificate Policies R. Housley May 2014 ASCII HTML 4

This document provides several certificate policy identifiers for testing certificate handling software.

draft-housley-pkix-test-oids-00 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7229
RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 89 Hyptertext Transfer Protocol HTTP HTTP message format

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

draft-ietf-httpbis-p1-messaging-26 RFC2145 RFC2616 RFC2817 RFC2818 RFC8615 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7230 10.17487/RFC7230
RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 101 Hypertext Transfer Protocol HTTP HTTP semantics HTTP payload HTTP content HTTP method HTTP status code

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.

draft-ietf-httpbis-p2-semantics-26 RFC2616 RFC2817 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7231 10.17487/RFC7231
RFC7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 28 HyperText Transfer Protocol HTTP HTTP conditional requests

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.

draft-ietf-httpbis-p4-conditional-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7232 10.17487/RFC7232
RFC7233 Hypertext Transfer Protocol (HTTP/1.1): Range Requests R. Fielding Editor Y. Lafon Editor J. Reschke Editor June 2014 ASCII HTML 25

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.

draft-ietf-httpbis-p5-range-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7233 10.17487/RFC7233
RFC7234 Hypertext Transfer Protocol (HTTP/1.1): Caching R. Fielding Editor M. Nottingham Editor J. Reschke Editor June 2014 ASCII HTML 43 HTTP caching HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.

draft-ietf-httpbis-p6-cache-26 RFC2616 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7234 10.17487/RFC7234
RFC7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication R. Fielding Editor J. Reschke Editor June 2014 ASCII HTML 19 HTTP authentication HyperText Transfer Protocol HTTP

The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.

draft-ietf-httpbis-p7-auth-26 RFC2616 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7235 10.17487/RFC7235
RFC7236 Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations J. Reschke June 2014 ASCII HTML 3 HyperText Transfer Protocol HTTP Authentication Authentication Scheme

This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.

draft-ietf-httpbis-authscheme-registrations-10 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7236
RFC7237 Initial Hypertext Transfer Protocol (HTTP) Method Registrations J. Reschke June 2014 ASCII HTML 5 HyperText Transfer Protocol HTTP Request Method

This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.

draft-ietf-httpbis-method-registrations-15 INFORMATIONAL INFORMATIONAL IETF app httpbis 10.17487/RFC7237
RFC7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke June 2014 ASCII HTML 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

draft-reschke-http-status-308-07 RFC7538 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7238
RFC7239 Forwarded HTTP Extension A. Petersson M. Nilsson June 2014 ASCII HTML 16 proxy x-forwarded-for x-forwarded-by x-forwarded-host x-forwarded-proto via

This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.

This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.

draft-ietf-appsawg-http-forwarded-10 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7239 10.17487/RFC7239
RFC7240 Prefer Header for HTTP J. Snell June 2014 ASCII HTML 17 http prefer

This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.

draft-snell-http-prefer-18 RFC8144 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7240 10.17487/RFC7240
RFC7241 The IEEE 802/IETF Relationship S. Dawkins P. Thaler D. Romascanu B. Aboba Editor July 2014 ASCII HTML 35 snmp aaa simple network management protocol authentication authorization accounting

This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.

Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.

draft-iab-rfc4441rev-08 RFC4441 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7241 10.17487/RFC7241
RFC7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol M. Demmer J. Ott S. Perreault June 2014 ASCII HTML 22

This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of the IRTF's DTN Research Group (DTNRG).

draft-irtf-dtnrg-tcp-clayer-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC7242
RFC7243 RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric V. Singh Editor J. Ott I. Curcio May 2014 ASCII HTML 12 rtp reception statistics de-jitter buffer

The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception.

draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7243
RFC7244 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting H. Asaeda Q. Wu R. Huang May 2014 ASCII HTML 13

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-synchronization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7244
RFC7245 An Architecture for Media Recording Using the Session Initiation Protocol A. Hutton Editor L. Portman Editor R. Jain K. Rehor May 2014 ASCII HTML 16 sip

Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).

draft-ietf-siprec-architecture-12 INFORMATIONAL INFORMATIONAL IETF rai siprec 10.17487/RFC7245
RFC7246 Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context IJ. Wijnands Editor P. Hitchen N. Leymann W. Henderickx A. Gulko J. Tantsura June 2014 ASCII HTML 13

An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.

draft-ietf-l3vpn-mldp-vrf-in-band-signaling-03 RFC7438 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7246
RFC7247 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII HTML 24 XMPP SIP

As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.

draft-ietf-stox-core-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7247
RFC7248 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre A. Houri J. Hildebrand May 2014 ASCII HTML 30 XMPP Jabber SIP SIMPLE IM Instant Messaging Presence

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

draft-ietf-stox-presence-09 RFC8048 PROPOSED STANDARD PROPOSED STANDARD IETF rai stox 10.17487/RFC7248
RFC7249 Internet Numbers Registries R. Housley May 2014 ASCII HTML 6

RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.

This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.

draft-housley-number-registries-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7249
RFC7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Wouters Editor H. Tschofenig Editor J. Gilmore S. Weiler T. Kivinen June 2014 ASCII HTML 18 TLS DNSSEC DANE Raw Public Key

This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.

draft-ietf-tls-oob-pubkey-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7250 10.17487/RFC7250
RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS D. McGrew D. Bailey M. Campagna R. Dugal June 2014 ASCII HTML 10

This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic Curve Cryptography (ECC) and are advantageous in networks with limited bandwidth.

draft-mcgrew-tls-aes-ccm-ecc-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7251
RFC7252 The Constrained Application Protocol (CoAP) Z. Shelby K. Hartke C. Bormann June 2014 ASCII HTML 112

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.

CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

draft-ietf-core-coap-18 RFC7959 RFC8613 PROPOSED STANDARD PROPOSED STANDARD IETF app core http://www.rfc-editor.org/errata_search.php?rfc=7252 10.17487/RFC7252
RFC7253 The OCB Authenticated-Encryption Algorithm T. Krovetz P. Rogaway May 2014 ASCII HTML 19 OCB AEAD authenticated-encryption

This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).

draft-irtf-cfrg-ocb-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7253
RFC7254 A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) M. Montemurro Editor A. Allen D. McDonald P. Gosden May 2014 ASCII HTML 16 GSM UMTS LTE 3GPP Mobile identifier instance ID

This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and Software Version number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System (UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly.

draft-montemurro-gsma-imei-urn-20 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7254 10.17487/RFC7254
RFC7255 Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID A. Allen Editor May 2014 ASCII HTML 9 GSM UMTS LTE 3GPP IMS SIP GRUU Mobile identifier instance ID

This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association (GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior.

draft-allen-dispatch-imei-urn-as-instanceid-13 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7255
RFC7256 Multicast Control Extensions for the Access Node Control Protocol (ANCP) F. Le Faucheur R. Maglione T. Taylor July 2014 ASCII HTML 99

This document specifies the extensions to the Access Node Control Protocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document (RFC 5851) and one additional use case described in this document. These use cases are organized into the following ANCP capabilities:

o multicast replication initiated by the Network Access Server (NAS);

o conditional access and admission control with white and black lists;

o conditional access and admission control with grey lists;

o bandwidth delegation; and

o committed bandwidth reporting.

These capabilities may be combined according to the rules given in this specification.

This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64.

draft-ietf-ancp-mc-extensions-16 RFC6320 PROPOSED STANDARD PROPOSED STANDARD IETF int ancp 10.17487/RFC7256
RFC7257 Virtual Private LAN Service (VPLS) Management Information Base T. Nadeau Editor A. Kiran Koushik Editor R. Mediratta Editor July 2014 ASCII HTML 48

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Virtual Private LAN services. It needs to be used in conjunction with the Pseudowire (PW) Management Information Base (PW-STD-MIB from RFC 5601).

draft-ietf-l2vpn-vpls-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7257 10.17487/RFC7257
RFC7258 Pervasive Monitoring Is an Attack S. Farrell H. Tschofenig May 2014 ASCII HTML 6 pervasive monitoring

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

draft-farrell-perpass-attack-06 BCP0188 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7258
RFC7259 The Jabber-ID Header Field P. Saint-Andre May 2014 ASCII HTML 7 Jabber XMPP Extensible Messaging and Presence Protocol email netnews message header field IM instant messaging

This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.

draft-saintandre-jabberid-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7259
RFC7260 GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration A. Takacs D. Fedyk J. He June 2014 ASCII HTML 24 MPLS-TP Transport Profile GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.

draft-ietf-ccamp-oam-configuration-fwk-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=7260 10.17487/RFC7260
RFC7261 Offer/Answer Considerations for G723 Annex A and G729 Annex B M. Perumal P. Ravindran May 2014 ASCII HTML 8 offer answer

This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer.

draft-ietf-mmusic-sdp-g723-g729-06 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7261
RFC7262 Requirements for Telepresence Multistreams A. Romanow S. Botzko M. Barnes June 2014 ASCII HTML 12

This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein.

draft-ietf-clue-telepresence-requirements-07 INFORMATIONAL INFORMATIONAL IETF rai clue 10.17487/RFC7262
RFC7263 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII HTML 20 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

draft-ietf-p2psip-drr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7263
RFC7264 An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing N. Zong X. Jiang R. Even Y. Zhang June 2014 ASCII HTML 15 P2P

This document defines an optional extension to the REsource LOcation And Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used.

draft-ietf-p2psip-rpr-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7264
RFC7265 jCal: The JSON Format for iCalendar P. Kewisch C. Daboo M. Douglass May 2014 ASCII HTML 31

This specification defines "jCal", a JSON format for iCalendar data. The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications.

draft-ietf-jcardcal-jcal-10 RFC7529 PROPOSED STANDARD PROPOSED STANDARD IETF app jcardcal http://www.rfc-editor.org/errata_search.php?rfc=7265 10.17487/RFC7265
RFC7266 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting A. Clark Q. Wu R. Schott G. Zorn June 2014 ASCII HTML 23

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications.

draft-ietf-xrblock-rtcp-xr-qoe-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7266
RFC7267 Dynamic Placement of Multi-Segment Pseudowires L. Martini Editor M. Bocci Editor F. Balus Editor June 2014 ASCII HTML 24 pw pw switching point pe sub-tlv

RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet Switched Network domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi-segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14.

draft-ietf-pwe3-dynamic-ms-pw-22 RFC6073 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7267
RFC7268 RADIUS Attributes for IEEE 802 Networks B. Aboba J. Malinen P. Congdon J. Salowey M. Jones July 2014 ASCII HTML 29

RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072.

draft-ietf-radext-ieee802ext-12 RFC3580 RFC4072 RFC8044 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC7268
RFC7269 NAT64 Deployment Options and Experience G. Chen Z. Cao C. Xie D. Binet June 2014 ASCII HTML 22

This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.

draft-ietf-v6ops-nat64-experience-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7269
RFC7270 Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) A. Yourtchenko P. Aitken B. Claise June 2014 ASCII HTML 21 IPFIX

This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.

draft-yourtchenko-cisco-ies-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7270 10.17487/RFC7270
RFC7271 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators J. Ryoo Editor E. Gray Editor H. van Helvoort A. D'Alessandro T. Cheung E. Osborne June 2014 ASCII HTML 40 PSC mode APS mode capabilities priority non-revertive MS-W support SD support EXER support

This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.

This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.

This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.

This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.

draft-ietf-mpls-tp-psc-itu-04 RFC6378 RFC8234 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7271
RFC7272 Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) R. van Brandenburg H. Stokking O. van Deventer F. Boronat M. Montagud K. Gross June 2014 ASCII HTML 23 Inter-Destination Media Synchronization RTP Control Protocol RTCP

This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.

Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc.

draft-ietf-avtcore-idms-13 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore 10.17487/RFC7272
RFC7273 RTP Clock Source Signalling A. Williams K. Gross R. van Brandenburg H. Stokking June 2014 ASCII HTML 30 clock source

NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies Session Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session.

draft-ietf-avtcore-clksrc-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai avtcore http://www.rfc-editor.org/errata_search.php?rfc=7273 10.17487/RFC7273
RFC7274 Allocating and Retiring Special-Purpose MPLS Labels K. Kompella L. Andersson A. Farrel June 2014 ASCII HTML 11

Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special-purpose labels" in this document.

As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.

This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special-purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a new registry called the "Extended Special-Purpose MPLS Label Values" registry.

This document updates a number of previous RFCs that use the term "reserved label". Specifically, this document updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790.

draft-ietf-mpls-special-purpose-labels-06 RFC3032 RFC3038 RFC3209 RFC3811 RFC4182 RFC4928 RFC5331 RFC5586 RFC5921 RFC5960 RFC6391 RFC6478 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7274
RFC7275 Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy L. Martini S. Salam A. Sajassi M. Bocci S. Matsushima T. Nadeau June 2014 ASCII HTML 83 iccp

This document specifies an Inter-Chassis Communication Protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms.

draft-ietf-pwe3-iccp-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7275
RFC7276 An Overview of Operations, Administration, and Maintenance (OAM) Tools T. Mizrahi N. Sprecher E. Bellagamba Y. Weingarten June 2014 ASCII HTML 53

Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.

This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.

The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.

draft-ietf-opsawg-oam-overview-16 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7276
RFC7277 A YANG Data Model for IP Management M. Bjorklund June 2014 ASCII HTML 30 netmod

This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data.

draft-ietf-netmod-ip-cfg-14 RFC8344 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7277
RFC7278 Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link C. Byrne D. Drown A. Vizdal June 2014 ASCII HTML 10

This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples.

draft-ietf-v6ops-64share-10 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7278
RFC7279 An Acceptable Use Policy for New ICMP Types and Codes M. Shore C. Pignataro May 2014 ASCII HTML 10 icmp icmpv4 icmpv6

In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.

This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.

draft-shore-icmp-aup-12 BCP0189 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7279
RFC7280 IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry G. Fairhurst June 2014 ASCII HTML 7 ULE IANA

This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next- Header registry. This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols.

draft-fairhurst-ipdvb-ule-iana-07 RFC4326 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7280
RFC7281 Authentication-Results Registration for S/MIME Signature Verification A. Melnikov June 2014 ASCII HTML 11 Authentication-Results S/MIME

RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication- Results header field for S/MIME-related signature checks.

draft-melnikov-authentication-results-smime-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7281
RFC7282 On Consensus and Humming in the IETF P. Resnick June 2014 ASCII HTML 19 accommodate agree agreement appease argue argument balloting capitulated capitulation chair choice choose coin compromise count decide decision disagree disagreement hands horse-trade horse-trading hum issue judge judging king majority member minority object objection objector president rough unaddressed vote voting working group

The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.

Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.

draft-resnick-on-consensus-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7282 10.17487/RFC7282
RFC7283 Handling Unknown DHCPv6 Messages Y. Cui Q. Sun T. Lemon July 2014 ASCII HTML 7 DHCPv6 Unknown Messages

DHCPv6 is not specific about handling messages with unknown types. This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages. This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315.

draft-ietf-dhc-dhcpv6-unknown-msg-08 RFC8415 RFC3315 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7283
RFC7284 The Profile URI Registry M. Lanthaler June 2014 ASCII HTML 5 profile profiles URI registry

This document defines a registry for profile URIs to be used in specifications standardizing profiles.

draft-lanthaler-profile-registry-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7284
RFC7285 Application-Layer Traffic Optimization (ALTO) Protocol R. Alimi Editor R. Penno Editor Y. Yang Editor S. Kiesel S. Previdi W. Roome S. Shalunov R. Woundy September 2014 ASCII HTML 91 ALTO Information Resources Network Map PID Filtered Network Map Cost Map Endpoint Property Service Endpoint Cost Service

Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.

This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.

draft-ietf-alto-protocol-27 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7285
RFC7286 Application-Layer Traffic Optimization (ALTO) Server Discovery S. Kiesel M. Stiemerling N. Schwan M. Scharf H. Song November 2014 ASCII HTML 15

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.

This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.

draft-ietf-alto-server-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC7286
RFC7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains T. Schmidt Editor S. Gao H. Zhang M. Waehlisch June 2014 ASCII HTML 28

Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying Multicast Listener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.

draft-ietf-multimob-pmipv6-source-09 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7287
RFC7288 Reflections on Host Firewalls D. Thaler June 2014 ASCII HTML 13 Filter Filtering

In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice. Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward.

draft-iab-host-firewalls-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7288
RFC7289 Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs V. Kuarsingh Editor J. Cianfarani June 2014 ASCII HTML 20 NAT444 LSN Large-Scale NAT

This document specifies a framework to integrate a Network Address Translation (NAT) layer into an operator's network to function as a Carrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs, which allow for virtual routing separation, helping ease the CGN's impact on the network. This document does not intend to defend the merits of CGN.

draft-ietf-opsawg-lsn-deployment-06 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7289
RFC7290 Test Plan and Results for Advancing RFC 2680 on the Standards Track L. Ciavattone R. Geib A. Morton M. Wieser July 2014 ASCII HTML 31 packet loss IPPM implementation comparison perfas+ netem IPPM comparison metric test, WIPM NetProbe

This memo provides the supporting test plan and results to advance RFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680.

draft-ietf-ippm-testplan-rfc2680-05 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7290
RFC7291 DHCP Options for the Port Control Protocol (PCP) M. Boucadair R. Penno D. Wing July 2014 ASCII HTML 11 PCP Server discovery Port Mapping Shared Address

This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document.

draft-ietf-pcp-dhcp-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7291
RFC7292 PKCS #12: Personal Information Exchange Syntax v1.1 K. Moriarty Editor M. Nystrom S. Parkinson A. Rusch M. Scott July 2014 ASCII HTML 29 PKCS#12 PKCS12v1.1 PKCS#12v1.1

PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.

This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

draft-moriarty-pkcs12v1-1-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7292 10.17487/RFC7292
RFC7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension W. Mills M. Kucherawy July 2014 ASCII HTML 24 Security Privacy Email Account Expiration

This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.

The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications.

draft-ietf-appsawg-rrvs-header-field-11 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7293
RFC7294 RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications A. Clark G. Zorn C. Bi Q. Wu July 2014 ASCII HTML 22 Real Time Control Protocol

This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP.

draft-ietf-xrblock-rtcp-xr-loss-conceal-12 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7294
RFC7295 Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication H. Tschofenig L. Eggert Z. Sarker July 2014 ASCII HTML 26 Congestion Control RTCWEB Workshop Real-Time Communication

This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community.

The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or the Internet Research Task Force (IRTF).

draft-iab-cc-workshop-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7295
RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) C. Kaufman P. Hoffman Y. Nir P. Eronen T. Kivinen October 2014 ASCII HTML 142 IKE IPsec

This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.

draft-kivinen-ipsecme-ikev2-rfc5996bis-04 RFC5996 RFC7427 RFC7670 RFC8247 STD0079 INTERNET STANDARD INTERNET STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7296 10.17487/RFC7296
RFC7297 IP Connectivity Provisioning Profile (CPP) M. Boucadair C. Jacquenet N. Wang July 2014 ASCII HTML 22

This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.

Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs.

draft-boucadair-connectivity-provisioning-profile-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7297
RFC7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication D. Ovsienko July 2014 ASCII HTML 55 routing protocol authentication applied cryptography

This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.

draft-ovsienko-babel-hmac-authentication-09 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7298
RFC7299 Object Identifier Registry for the PKIX Working Group R. Housley July 2014 ASCII HTML 30 Public-Key Infrastructure using X.509

When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

draft-housley-pkix-oids-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7299
RFC7300 Reservation of Last Autonomous System (AS) Numbers J. Haas J. Mitchell July 2014 ASCII HTML 5 asn last asns

This document reserves two Autonomous System Numbers (ASNs) at the end of the 16-bit and 32-bit ranges, described in this document as "Last ASNs", and provides guidance to implementers and operators on their use. This document updates Section 10 of RFC 1930.

draft-ietf-idr-last-as-reservation-07 RFC1930 BCP0006 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg idr 10.17487/RFC7300
RFC7301 Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension S. Friedl A. Popov A. Langley E. Stephan July 2014 ASCII HTML 9 ALPN

This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.

draft-ietf-tls-applayerprotoneg-05 RFC8447 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7301 10.17487/RFC7301
RFC7302 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux July 2014 ASCII HTML 8 EIDR Entertainment Identifier Registry URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

draft-pal-eidr-urn-03 RFC7972 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7302
RFC7303 XML Media Types H. Thompson C. Lilley July 2014 ASCII HTML 35 application/xml application/xml-external-parsed-entity application/xml-dtd text/xml text/xml-external-parsed-entity +xml

This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities.

draft-ietf-appsawg-xml-mediatypes-10 RFC3023 RFC6839 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7303 10.17487/RFC7303
RFC7304 A Method for Mitigating Namespace Collisions W. Kumari July 2014 ASCII HTML 4

This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict.

draft-wkumari-dnsop-defense-collision-mitigate-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7304
RFC7305 Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) E. Lear Editor July 2014 ASCII HTML 17

This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Internet Technology Adoption and Transition (ITAT). The workshop was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time. Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-itat-report-04 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7305 10.17487/RFC7305
RFC7306 Remote Direct Memory Access (RDMA) Protocol Extensions H. Shah F. Marti W. Noureddine A. Eiriksson R. Sharp June 2014 ASCII HTML 34 iWARP RDMAP DDP RDMA DMA

This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP) as specified in RFC 5040. RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data.

draft-ietf-storm-rdmap-ext-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv storm http://www.rfc-editor.org/errata_search.php?rfc=7306 10.17487/RFC7306
RFC7307 LDP Extensions for Multi-Topology Q. Zhao K. Raza C. Zhou L. Fang L. Li D. King July 2014 ASCII HTML 20 MT Label Distribution Protocol

Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.

This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.

draft-ietf-mpls-ldp-multi-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7307 10.17487/RFC7307
RFC7308 Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) E. Osborne July 2014 ASCII HTML 7 colors link colors igp te extensions

MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).

This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.

draft-ietf-mpls-extended-admin-group-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7308
RFC7309 Redundancy Mechanism for Inter-domain VPLS Service Z. Liu L. Jin R. Chen D. Cai S. Salam July 2014 ASCII HTML 12 ICCP PW

In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.

draft-ietf-l2vpn-vpls-inter-domain-redundancy-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn 10.17487/RFC7309
RFC7310 RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs J. Lindsay H. Foerster July 2014 ASCII HTML 16

This document specifies a scheme for packetizing Standard apt-X or Enhanced apt-X encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP).

draft-ietf-payload-rtp-aptx-05 PROPOSED STANDARD PROPOSED STANDARD IETF rai payload 10.17487/RFC7310
RFC7311 The Accumulated IGP Metric Attribute for BGP P. Mohapatra R. Fernando E. Rosen J. Uttaro August 2014 ASCII HTML 15

Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so.

draft-ietf-idr-aigp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7311
RFC7312 Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) J. Fabini A. Morton August 2014 ASCII HTML 17 Measurement Wireless Reactive Repeatability Continuity Actionable Conservative Spatial Composition Temporal Composition

To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates the IP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics.

draft-ietf-ippm-2330-update-05 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7312
RFC7313 Enhanced Route Refresh Capability for BGP-4 K. Patel E. Chen B. Venkatachalapathy July 2014 ASCII HTML 8 Border Gateway Protocol bgp rib BGP Routing Information Base

In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.

draft-ietf-idr-bgp-enhanced-route-refresh-10 RFC2918 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7313
RFC7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option M. Andrews July 2014 ASCII HTML 4 IXFR AXFR zone transfer DNS SOA

This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.

draft-andrews-dnsext-expire-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7314
RFC7315 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP R. Jesske K. Drage C. Holmberg July 2014 ASCII HTML 43

This document describes a set of private header (P-header) Session Initiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. The P-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455.

draft-drage-sipping-rfc3455bis-14 RFC3455 RFC7913 RFC7976 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7315 10.17487/RFC7315
RFC7316 The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header) J. van Elburg K. Drage M. Ohsugi S. Schubert K. Arai July 2014 ASCII HTML 15

This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.

draft-vanelburg-dispatch-private-network-ind-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7316
RFC7317 A YANG Data Model for System Management A. Bierman M. Bjorklund August 2014 ASCII HTML 35 NETCONF

This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management.

draft-ietf-netmod-system-mgmt-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7317 10.17487/RFC7317
RFC7318 Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates A. Newton G. Huston July 2014 ASCII HTML 5

This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource Public Key Infrastructure (RPKI) resource certificates.

draft-ietf-sidr-policy-qualifiers-02 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7318
RFC7319 IANA Considerations for Connectivity Fault Management (CFM) Code Points D. Eastlake 3rd July 2014 ASCII HTML 5 CFM OAM Connectivity Continuity Fault IANA TRILL

IEEE 802.1 has specified Connectivity Fault Management (CFM) Operations, Administration, and Maintenance (OAM) facilities. CFM messages are structured with an OpCode field and have provision for the inclusion of TLV-structured information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV Types to the IETF. This document specifies the IANA considerations for the assignment of values from these blocks.

draft-eastlake-iana-cfm-considerations-02 BCP0191 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7319
RFC7320 URI Design and Ownership M. Nottingham July 2014 ASCII HTML 9 URI structure

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.

draft-ietf-appsawg-uri-get-off-my-lawn-05 RFC8820 RFC3986 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7320 10.17487/RFC7320
RFC7321 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) D. McGrew P. Hoffman August 2014 ASCII HTML 11

This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.

ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.

draft-ietf-ipsecme-esp-ah-reqts-10 RFC4835 RFC8221 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7321
RFC7322 RFC Style Guide H. Flanagan S. Ginoza September 2014 ASCII HTML 24 editorial guidance format style manual house style

This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".

draft-iab-styleguide-02 RFC2223 RFC7997 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7322 10.17487/RFC7322
RFC7323 TCP Extensions for High Performance D. Borman B. Braden V. Jacobson R. Scheffenegger Editor September 2014 ASCII HTML 49 Timestamps Timestamp RTT RTTM Window Scale PAWS TCP options

This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.

This document obsoletes RFC 1323 and describes changes from it.

draft-ietf-tcpm-1323bis-21 RFC1323 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=7323 10.17487/RFC7323
RFC7324 Updates to MPLS Transport Profile Linear Protection E. Osborne July 2014 ASCII HTML 11 multiprotocol label switching mpls-tp psc protection state coordination

This document contains a number of updates to the Protection State Coordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378.

draft-ietf-mpls-psc-updates-06 RFC6378 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7324
RFC7325 MPLS Forwarding Compliance and Performance Requirements C. Villamizar Editor K. Kompella S. Amante A. Malis C. Pignataro August 2014 ASCII HTML 59 MPLS ECMP link bundling multipath MPLS-TP forwarding

This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements which are unstated or under emphasized or are optional for conformance to RFCs but are often considered mandatory by providers.

draft-ietf-mpls-forwarding-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7325
RFC7326 Energy Management Framework J. Parello B. Claise B. Schoening J. Quittek September 2014 ASCII HTML 54

This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks. The framework presents a physical reference model and information model. The information model consists of an Energy Management Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. Energy Objects can be monitored and controlled with respect to power, Power State, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between Energy Objects.

draft-ietf-eman-framework-19 INFORMATIONAL INFORMATIONAL IETF ops eman 10.17487/RFC7326
RFC7327 RFC7328 Writing I-Ds and RFCs Using Pandoc and a Bit of XML R. Gieben August 2014 ASCII HTML 10

This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) or RFCs.

The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML.

draft-gieben-pandoc2rfc-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7328
RFC7329 A Session Identifier for the Session Initiation Protocol (SIP) H. Kaplan August 2014 ASCII HTML 17

There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIP Proxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.

The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a new Standards Track document produced by the INSIPID Working Group.

draft-kaplan-insipid-session-id-04 RFC7989 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7329
RFC7330 Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management T. Nadeau Z. Ali N. Akiya August 2014 ASCII HTML 11 Network Management management Information Base MIB SMIv2 BFD

This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations.

draft-ietf-bfd-tc-mib-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7330
RFC7331 Bidirectional Forwarding Detection (BFD) Management Information Base T. Nadeau Z. Ali N. Akiya August 2014 ASCII HTML 39 Network Management Management Information Base MIB SMIv2 BFD

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol.

draft-ietf-bfd-mib-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7331 10.17487/RFC7331
RFC7332 Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) H. Kaplan V. Pascual August 2014 ASCII HTML 5

SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops.

draft-ietf-straw-b2bua-loop-detection-04 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw http://www.rfc-editor.org/errata_search.php?rfc=7332 10.17487/RFC7332
RFC7333 Requirements for Distributed Mobility Management H. Chan Editor D. Liu P. Seite H. Yokota J. Korhonen August 2014 ASCII HTML 24 Distributed Mobility Management Network function distribution Flat mobile network Mobile network operation and management Control and data plane separation

This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described.

draft-ietf-dmm-requirements-17 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7333
RFC7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths Q. Zhao D. Dhody D. King Z. Ali R. Casellas August 2014 ASCII HTML 25 Core-tree

The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.

This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.

draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7334
RFC7335 IPv4 Service Continuity Prefix C. Byrne August 2014 ASCII HTML 4

Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element. Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution.

draft-ietf-v6ops-clatip-04 RFC6333 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7335
RFC7336 Framework for Content Distribution Network Interconnection (CDNI) L. Peterson B. Davie R. van Brandenburg Editor August 2014 ASCII HTML 58 CDNI content delivery network federation cdni request routing cdni logging cdmi metadata cdni control

This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletes RFC 3466.

draft-ietf-cdni-framework-14 RFC3466 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7336
RFC7337 Content Distribution Network Interconnection (CDNI) Requirements K. Leung Editor Y. Lee Editor August 2014 ASCII HTML 23

Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.

The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group.

draft-ietf-cdni-requirements-17 INFORMATIONAL INFORMATIONAL IETF tsv cdni 10.17487/RFC7337
RFC7338 Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks F. Jounay Editor Y. Kamite Editor G. Heron M. Bocci September 2014 ASCII HTML 18

This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS Packet Switched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point-to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service).

draft-ietf-pwe3-p2mp-pw-requirements-10 INFORMATIONAL INFORMATIONAL IETF rtg pwe3 10.17487/RFC7338
RFC7339 Session Initiation Protocol (SIP) Overload Control V. Gurbani Editor V. Hilt H. Schulzrinne September 2014 ASCII HTML 38 SIP Overload Control

Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all the SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP.

draft-ietf-soc-overload-control-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7339
RFC7340 Secure Telephone Identity Problem Statement and Requirements J. Peterson H. Schulzrinne H. Tschofenig September 2014 ASCII HTML 25 SIP XMPP Secure Origin Identification Communication Security RTCWeb Problem Statement Real-Time Communication

Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.

draft-ietf-stir-problem-statement-05 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7340
RFC7341 DHCPv4-over-DHCPv6 (DHCP 4o6) Transport Q. Sun Y. Cui M. Siodelski S. Krishnan I. Farrer August 2014 ASCII HTML 16 ipv6 transition softwire migration tunnel residual ipv4 dhcpv6 relay ipv6-only

IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.

draft-ietf-dhc-dhcpv4-over-dhcpv6-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7341
RFC7342 Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers L. Dunbar W. Kumari I. Gashinsky August 2014 ASCII HTML 14

This memo documents some operational practices that allow ARP and Neighbor Discovery (ND) to scale in data center environments.

draft-dunbar-armd-arp-nd-scaling-practices-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7342
RFC7343 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) J. Laganier F. Dupont September 2014 ASCII HTML 14 HIP HIPv2 ORCHID CGA API

This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.

The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.

draft-ietf-hip-rfc4843-bis-08 RFC4843 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7343
RFC7344 Automating DNSSEC Delegation Trust Maintenance W. Kumari O. Gudmundsson G. Barwood September 2014 ASCII HTML 18 key roll trust anchor CDS CDNSKEY DNSSEC DNS

This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.

draft-ietf-dnsop-delegation-trust-maintainance-14 RFC8078 PROPOSED STANDARD INFORMATIONAL IETF ops dnsop 10.17487/RFC7344
RFC7345 UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) C. Holmberg I. Sedlacek G. Salgueiro August 2014 ASCII HTML 23 SDP SIP DTLS UDPTL fax transport

This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).

draft-ietf-mmusic-udptl-dtls-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai mmusic 10.17487/RFC7345
RFC7346 IPv6 Multicast Address Scopes R. Droms August 2014 ASCII HTML 6 IPv6 multicast address scopes

This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291.

draft-ietf-6man-multicast-scopes-07 RFC4007 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=7346 10.17487/RFC7346
RFC7347 Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) H. van Helvoort Editor J. Ryoo Editor H. Zhang F. Huang H. Li A. D'Alessandro September 2014 ASCII PDF HTML 32

The IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.

This document describes the pre-standard implementation of MPLS-TP Linear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.

The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane.

draft-zulr-mpls-tp-linear-protection-switching-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7347
RFC7348 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks M. Mahalingam D. Dutt K. Duda P. Agarwal L. Kreeger T. Sridhar M. Bursell C. Wright August 2014 ASCII HTML 22

This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.

draft-mahalingam-dutt-dcops-vxlan-09 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7348 10.17487/RFC7348
RFC7349 LDP Hello Cryptographic Authentication L. Zheng M. Chen M. Bhatia August 2014 ASCII HTML 14

This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.

draft-ietf-mpls-ldp-hello-crypto-auth-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7349
RFC7350 Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) M. Petit-Huguenin G. Salgueiro August 2014 ASCII HTML 16 Security Encryption

This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928.

draft-ietf-tram-stun-dtls-05 RFC5389 RFC5928 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7350
RFC7351 A Media Type for XML Patch Operations E. Wilde August 2014 ASCII HTML 14 Media Type XML Patch Operations

The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.

draft-wilde-xml-patch-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7351
RFC7352 Sieve Email Filtering: Detecting Duplicate Deliveries S. Bosch September 2014 ASCII HTML 15 sieve duplicate deliveries

This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header field or other parts of the message.

draft-ietf-appsawg-sieve-duplicate-09 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7352
RFC7353 Security Requirements for BGP Path Validation S. Bellovin R. Bush D. Ward August 2014 ASCII HTML 9 Routing BGP Security AS_PATH and RPKI

This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin Autonomous System (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement.

draft-ietf-sidr-bgpsec-reqs-12 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC7353
RFC7354 Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace A. Adolf P. Siebert September 2014 ASCII HTML 3

RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updates RFC 5328 with new registrant information.

draft-adolf-dvb-urn-upd-01 RFC5328 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7354
RFC7355 Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) G. Salgueiro V. Pascual A. Roman S. Garcia September 2014 ASCII HTML 9

RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new "Transport Flag" for such SIP WebSocket transport.

draft-salgueiro-dispatch-websocket-sipclf-02 RFC6873 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7355
RFC7356 IS-IS Flooding Scope Link State PDUs (LSPs) L. Ginsberg S. Previdi Y. Yang September 2014 ASCII HTML 23

Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.

The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.

draft-ietf-isis-fs-lsp-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7356
RFC7357 Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol H. Zhai F. Hu R. Perlman D. Eastlake 3rd O. Stokes September 2014 ASCII HTML 31 ESADI TRILL RBridge Address Learning Reachability MAC Addresses

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).

ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.

draft-ietf-trill-esadi-09 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7357
RFC7358 Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) K. Raza S. Boutros L. Martini N. Leymann October 2014 ASCII HTML 8

The label advertising behavior of an LDP speaker for a given Forwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types.

draft-ietf-mpls-ldp-applicability-label-adv-03 RFC3212 RFC4447 RFC5036 RFC5918 RFC6388 RFC7140 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7358
RFC7359 Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks F. Gont August 2014 ASCII HTML 12

The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue.

draft-ietf-opsec-vpn-leakages-06 INFORMATIONAL INFORMATIONAL IETF ops opsec 10.17487/RFC7359
RFC7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS A. DeKok September 2014 ASCII HTML 27

The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.

draft-ietf-radext-dtls-13 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7360
RFC7361 LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) P. Dutta F. Balus O. Stokes G. Calvignac D. Fedyk September 2014 ASCII HTML 27 MAC flush message MAC Flush TLV MAC flushing

RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes. This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.

draft-ietf-l2vpn-vpls-ldp-mac-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7361 10.17487/RFC7361
RFC7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication E. Ivov H. Kaplan D. Wing September 2014 ASCII HTML 16 VoIP firewall traversal

This document describes the behavior of signaling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.

This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.

Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the Interactive Connectivity Establishment (ICE) protocol.

draft-ietf-mmusic-latching-08 INFORMATIONAL INFORMATIONAL IETF rai mmusic 10.17487/RFC7362
RFC7363 Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo September 2014 ASCII HTML 22 P2PSIP P2P Chord

REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size.

draft-ietf-p2psip-self-tuning-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7363
RFC7364 Problem Statement: Overlays for Network Virtualization T. Narten Editor E. Gray Editor D. Black L. Fang L. Kreeger M. Napierala October 2014 ASCII HTML 23

This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures.

draft-ietf-nvo3-overlay-problem-statement-04 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7364
RFC7365 Framework for Data Center (DC) Network Virtualization M. Lasserre F. Balus T. Morin N. Bitar Y. Rekhter October 2014 ASCII HTML 26 nvo3 network virtualization over layer 3

This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.

draft-ietf-nvo3-framework-09 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC7365
RFC7366 Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) P. Gutmann September 2014 ASCII HTML 7

This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years.

draft-ietf-tls-encrypt-then-mac-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7366 10.17487/RFC7366
RFC7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process R. Cole J. Macker B. Adamson October 2014 ASCII HTML 65 Network Management Management Information Base MIB SMIv2 Routing MANET Multicast

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad Hoc Networks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.

draft-ietf-manet-smf-mib-13 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7367
RFC7368 IPv6 Home Networking Architecture Principles T. Chown Editor J. Arkko A. Brandt O. Troan J. Weil October 2014 ASCII HTML 49 IPv6

This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network.

draft-ietf-homenet-arch-17 INFORMATIONAL INFORMATIONAL IETF int homenet 10.17487/RFC7368
RFC7369 GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration A. Takacs B. Gero H. Long October 2014 ASCII HTML 18 GELS Ethernet Label Switching PBB-TE connectivity monitoring OAM configuration

The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks. CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.

draft-ietf-ccamp-rsvp-te-eth-oam-ext-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7369
RFC7370 Updates to the IS-IS TLV Codepoints Registry L. Ginsberg September 2014 ASCII HTML 7 Codepoint

This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.

draft-ietf-isis-tlv-codepoints-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7370
RFC7371 Updates to the IPv6 Multicast Addressing Architecture M. Boucadair S. Venaas September 2014 ASCII HTML 10 IPv6 Multicast Flag Bits updated unicast-prefix-based address updated Embedded-RP

This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.

This document updates RFCs 3956, 3306, and 4291.

draft-ietf-6man-multicast-addr-arch-update-08 RFC3306 RFC3956 RFC4291 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7371
RFC7372 Email Authentication Status Codes M. Kucherawy September 2014 ASCII HTML 8

This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.

This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document.

draft-ietf-appsawg-email-auth-codes-07 RFC7208 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7372
RFC7373 Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types B. Trammell September 2014 ASCII HTML 14 information element unicode

This document defines UTF-8 representations for IP Flow Information Export (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings.

draft-ietf-ipfix-text-adt-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops ipfix 10.17487/RFC7373
RFC7374 Service Discovery Usage for REsource LOcation And Discovery (RELOAD) J. Maenpaa G. Camarillo October 2014 ASCII HTML 20 P2PSIP ReDiR P2P DHT

REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC 6940). This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism can be applied to RELOAD overlays to provide a generic service discovery mechanism.

draft-ietf-p2psip-service-discovery-15 PROPOSED STANDARD PROPOSED STANDARD IETF rai p2psip 10.17487/RFC7374
RFC7375 Secure Telephone Identity Threat Model J. Peterson October 2014 ASCII HTML 13 SIP Secure Origin Identification Communication Security RTCWeb Threat Real-Time Communication

As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched.

draft-ietf-stir-threats-04 INFORMATIONAL INFORMATIONAL IETF rai stir 10.17487/RFC7375
RFC7376 Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) T. Reddy R. Ravindranath M. Perumal A. Yegin September 2014 ASCII HTML 8

This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages.

draft-ietf-tram-auth-problems-05 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7376
RFC7377 IMAP4 Multimailbox SEARCH Extension B. Leiba A. Melnikov October 2014 ASCII HTML 11 IMAP email search multiple mailboxes imapext

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237.

draft-ietf-appsawg-multimailbox-search-04 RFC6237 RFC4466 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7377
RFC7378 Trustworthy Location H. Tschofenig H. Schulzrinne B. Aboba Editor December 2014 ASCII HTML 31

The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.

This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information.

draft-ietf-ecrit-trustworthy-location-14 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7378
RFC7379 Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge Y. Li W. Hao R. Perlman J. Hudson H. Zhai October 2014 ASCII HTML 13

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.

draft-ietf-trill-active-active-connection-prob-07 INFORMATIONAL INFORMATIONAL IETF int trill 10.17487/RFC7379
RFC7380 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting J. Tong C. Bi Editor R. Even Q. Wu Editor R. Huang November 2014 ASCII HTML 11 TR 101 290

An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS.

draft-ietf-xrblock-rtcp-xr-psi-decodability-07 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7380
RFC7381 Enterprise IPv6 Deployment Guidelines K. Chittimaneni T. Chown L. Howard V. Kuarsingh Y. Pouffary E. Vyncke October 2014 ASCII HTML 34 IPV6 migration transition enterprise

Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.

draft-ietf-v6ops-enterprise-incremental-ipv6-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7381
RFC7382 Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) S. Kent D. Kong K. Seo April 2015 ASCII HTML 38

This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP.

draft-ietf-sidr-cps-04 BCP0173 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC7382
RFC7383 Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation V. Smyslov November 2014 ASCII HTML 20 IP fragmentation NAT firewall PMTU discovery

This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.

draft-ietf-ipsecme-ikev2-fragmentation-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7383
RFC7384 Security Requirements of Time Protocols in Packet Switched Networks T. Mizrahi October 2014 ASCII HTML 36 ptp precision time protocol ntp network time protocol

As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.

draft-ietf-tictoc-security-requirements-12 INFORMATIONAL INFORMATIONAL IETF int tictoc 10.17487/RFC7384
RFC7385 IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points L. Andersson G. Swallow October 2014 ASCII HTML 4

RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However, the RFC did not create a corresponding IANA registry.

There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.

draft-ietf-l3vpn-pmsi-registry-07 RFC6514 RFC8317 RFC8338 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l3vpn 10.17487/RFC7385
RFC7386 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII HTML 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

draft-ietf-appsawg-json-merge-patch-07 RFC7396 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg http://www.rfc-editor.org/errata_search.php?rfc=7386 10.17487/RFC7386
RFC7387 A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network R. Key Editor L. Yong Editor S. Delord F. Jounay L. Jin October 2014 ASCII HTML 13 mef etherhet lan e-lan metro ethernet forum

This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network.

draft-ietf-l2vpn-etree-frwk-10 INFORMATIONAL INFORMATIONAL IETF rtg l2vpn 10.17487/RFC7387
RFC7388 Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) J. Schoenwaelder A. Sehgal T. Tsou C. Zhou October 2014 ASCII HTML 27 Network Management Management Information Base MIB SMIv2

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs).

draft-ietf-6lo-lowpan-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7388
RFC7389 Separation of Control and User Plane for Proxy Mobile IPv6 R. Wakikawa R. Pazhyannur S. Gundavelli C. Perkins October 2014 ASCII HTML 12 Control and User Plane Split Control and User Plane Separation LMA User-Plane Address Mobility Option

This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.

draft-ietf-netext-pmip-cp-up-separation-07 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7389
RFC7390 Group Communication for the Constrained Application Protocol (CoAP) A. Rahman Editor E. Dijk Editor October 2014 ASCII HTML 46 multicast IP multicast RESTful Internet of Things (IoT)

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.

draft-ietf-core-groupcomm-25 EXPERIMENTAL EXPERIMENTAL IETF app core 10.17487/RFC7390
RFC7391 Forwarding and Control Element Separation (ForCES) Protocol Extensions J. Hadi Salim October 2014 ASCII HTML 23 ForCES Protocol Extension

Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal.

draft-ietf-forces-protoextension-06 RFC5810 RFC7121 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces 10.17487/RFC7391
RFC7392 Explicit Path Routing for Dynamic Multi-Segment Pseudowires P. Dutta M. Bocci L. Martini December 2014 ASCII HTML 10 Pseudowire MS-PW explicit route

When set up through an explicit path, dynamic Multi-Segment Pseudowires (MS-PWs) may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths.

draft-ietf-pwe3-mspw-er-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pwe3 10.17487/RFC7392
RFC7393 Using the Port Control Protocol (PCP) to Update Dynamic DNS X. Deng M. Boucadair Q. Zhao J. Huang C. Zhou November 2014 ASCII HTML 14 address sharing CGN service continuity service availability user-generated content address-sharing issues DS-Lite service delivery in CGN contexts

This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.

draft-deng-pcp-ddns-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7393
RFC7394 Definition of Time to Live TLV for LSP-Ping Mechanisms S. Boutros S. Sivabalan G. Swallow S. Saxena V. Manral S. Aldrin November 2014 ASCII HTML 8

LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of the MS-PW and/or bidirectional co-routed LSP. This document defines a TLV to address this shortcoming.

draft-ietf-mpls-lsp-ping-ttl-tlv-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7394 10.17487/RFC7394
RFC7395 An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket L. Stout Editor J. Moffitt E. Cestari October 2014 ASCII HTML 18 WebSocket XMPP

This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.

draft-ietf-xmpp-websocket-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai xmpp 10.17487/RFC7395
RFC7396 JSON Merge Patch P. Hoffman J. Snell October 2014 ASCII HTML 9 http json patch merge

This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content.

draft-ietf-rfc7386bis-00 RFC7386 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7396
RFC7397 Report from the Smart Object Security Workshop J. Gilger H. Tschofenig December 2014 ASCII HTML 23 Smart Objects Internet of Things Workshop Security

This document provides a summary of a workshop on 'Smart Object Security' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.

This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community.

draft-gilger-smart-object-security-workshop-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7397
RFC7398 A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance M. Bagnulo T. Burbridge S. Crawford P. Eardley A. Morton February 2015 ASCII HTML 17 LMAP performance metrics

This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement.

draft-ietf-ippm-lmap-path-07 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7398
RFC7399 Unanswered Questions in the Path Computation Element Architecture A. Farrel D. King October 2014 ASCII HTML 29 SDN Software Defined Networking H-PCE Hierarchical PCE VNTM Virtual Network Topology Manager ABNO Application-Based Network Operation TE Traffic Engineering

The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.

These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.

This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function.

draft-ietf-pce-questions-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7399
RFC7400 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) C. Bormann November 2014 ASCII HTML 24 IoT Internet of Things Embedded Internet Sensor Network WSN Constrained node Constrained network Constrained-node network LLN LoWPAN packet encoding capability indication 6CIO LZ77 RFC 6282 RFC 4944 adaptation layer IEEE 802.15.4

RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.

draft-ietf-6lo-ghc-05 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7400
RFC7401 Host Identity Protocol Version 2 (HIPv2) R. Moskowitz Editor T. Heer P. Jokela T. Henderson April 2015 ASCII HTML 128 HIP IP-layer state integrity protection optional encryption

This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.

This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.

draft-ietf-hip-rfc5201-bis-20 RFC5201 RFC8002 PROPOSED STANDARD PROPOSED STANDARD IETF int hip http://www.rfc-editor.org/errata_search.php?rfc=7401 10.17487/RFC7401
RFC7402 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) P. Jokela R. Moskowitz J. Melen April 2015 ASCII HTML 40 encryption user data packets

This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). This document obsoletes RFC 5202.

draft-ietf-hip-rfc5202-bis-07 RFC5202 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC7402
RFC7403 A Media-Based Traceroute Function for the Session Initiation Protocol (SIP) H. Kaplan November 2014 ASCII HTML 7

SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back-to-back user agents (B2BUAs).

draft-ietf-straw-sip-traceroute-03 PROPOSED STANDARD PROPOSED STANDARD IETF rai straw 10.17487/RFC7403
RFC7404 Using Only Link-Local Addressing inside an IPv6 Network M. Behringer E. Vyncke November 2014 ASCII HTML 10 IPv6 security routing Link-Local Routing Protocol Security

In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.

draft-ietf-opsec-lla-only-11 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7404 10.17487/RFC7404
RFC7405 Case-Sensitive String Support in ABNF P. Kyzivat December 2014 ASCII HTML 4 BNF ABNF Syntax

This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.

draft-kyzivat-case-sensitive-abnf-02 RFC5234 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7405 10.17487/RFC7405
RFC7406 Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices H. Schulzrinne S. McCann G. Bajko H. Tschofenig D. Kroeselberg December 2014 ASCII HTML 25

This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network.

draft-ietf-ecrit-unauthenticated-access-10 INFORMATIONAL INFORMATIONAL IETF rai ecrit 10.17487/RFC7406
RFC7407 A YANG Data Model for SNMP Configuration M. Bjorklund J. Schoenwaelder December 2014 ASCII HTML 88

This document defines a collection of YANG definitions for configuring SNMP engines.

draft-ietf-netmod-snmp-cfg-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7407 10.17487/RFC7407
RFC7408 Forwarding and Control Element Separation (ForCES) Model Extension E. Haleplidis November 2014 ASCII HTML 31 ForCES Model Extension

This memo extends the Forwarding and Control Element Separation (ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models.

draft-ietf-forces-model-extension-05 RFC5812 PROPOSED STANDARD PROPOSED STANDARD IETF rtg forces http://www.rfc-editor.org/errata_search.php?rfc=7408 10.17487/RFC7408
RFC7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization E. Haleplidis J. Halpern November 2014 ASCII HTML 27 ForCES Model Extension

Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation (ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).

draft-ietf-forces-packet-parallelization-03 EXPERIMENTAL EXPERIMENTAL IETF rtg forces 10.17487/RFC7409
RFC7410 A Property Types Registry for the Authentication-Results Header Field M. Kucherawy December 2014 ASCII HTML 5 Authentication-Results Reputation

This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values.

draft-ietf-appsawg-authres-ptypes-registry-04 RFC7601 RFC7001 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7410
RFC7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers T. Schmidt Editor M. Waehlisch R. Koodli G. Fairhurst D. Liu November 2014 ASCII HTML 30 Multicast Mobility IPv6 PIM MLD Group Communication

Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format.

This document updates RFC 5568, "Mobile IPv6 Fast Handovers".

draft-ietf-multimob-fmipv6-pfmipv6-multicast-10 RFC5568 EXPERIMENTAL EXPERIMENTAL IETF int multimob 10.17487/RFC7411
RFC7412 Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection Y. Weingarten S. Aldrin P. Pan J. Ryoo G. Mirsky December 2014 ASCII HTML 16

This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.

draft-ietf-mpls-smp-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC7412
RFC7413 TCP Fast Open Y. Cheng J. Chu S. Radhakrishnan A. Jain December 2014 ASCII HTML 26

This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.

draft-ietf-tcpm-fastopen-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=7413 10.17487/RFC7413
RFC7414 A Roadmap for Transmission Control Protocol (TCP) Specification Documents M. Duke R. Braden W. Eddy E. Blanton A. Zimmermann February 2015 ASCII HTML 57 TCP Roadmap

This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.

This document obsoletes RFC 4614.

draft-ietf-tcpm-tcp-rfc4614bis-08 RFC4614 RFC7805 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7414
RFC7415 Session Initiation Protocol (SIP) Rate Control E. Noel P. Williams February 2015 ASCII HTML 15

The prevalent use of the Session Initiation Protocol (SIP) in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme.

draft-ietf-soc-overload-rate-control-10 PROPOSED STANDARD PROPOSED STANDARD IETF rai soc 10.17487/RFC7415
RFC7416 A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) T. Tsao R. Alexander M. Dohler V. Daza A. Lozano M. Richardson Editor January 2015 ASCII HTML 40 LLN ROLL security

This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.

draft-ietf-roll-security-threats-11 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7416
RFC7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains G. Karagiannis A. Bhargava December 2014 ASCII HTML 36 generic aggregate rsvp

This document specifies extensions to Generic Aggregate RSVP (RFC 4860) for support of the Pre-Congestion Notification (PCN) Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.

draft-ietf-tsvwg-rsvp-pcn-11 EXPERIMENTAL EXPERIMENTAL IETF tsv tsvwg 10.17487/RFC7417
RFC7418 An IRTF Primer for IETF Participants S. Dawkins Editor December 2014 ASCII HTML 7 Research Group

This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF). This document emphasizes differences in expectations between the two organizations.

draft-dawkins-irtf-newrg-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7418
RFC7419 Common Interval Support in Bidirectional Forwarding Detection N. Akiya M. Binderberger G. Mirsky December 2014 ASCII HTML 8 BFD hardware interval timer

Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions.

This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals.

draft-ietf-bfd-intervals-05 RFC5880 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7419
RFC7420 Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module A. Koushik E. Stephan Q. Zhao D. King J. Hardwick December 2014 ASCII HTML 65 Network Management Management Information Base MIB SMIv2 PCE PCEP

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.

draft-ietf-pce-pcep-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=7420 10.17487/RFC7420
RFC7421 Analysis of the 64-bit Boundary in IPv6 Addressing B. Carpenter Editor T. Chown F. Gont S. Jiang A. Petrescu A. Yourtchenko January 2015 ASCII HTML 24

The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet. Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary.

draft-ietf-6man-why64-08 INFORMATIONAL INFORMATIONAL IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=7421 10.17487/RFC7421
RFC7422 Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments C. Donley C. Grundemann V. Sarawat K. Sundaresan O. Vautrin December 2014 ASCII HTML 14

In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response). Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges. Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use.

draft-donley-behave-deterministic-cgn-08 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7422 10.17487/RFC7422
RFC7423 Diameter Applications Design Guidelines L. Morand Editor V. Fajardo H. Tschofenig November 2014 ASCII HTML 29 AAA Authentication Authorization Accounting

The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.

draft-ietf-dime-app-design-guide-28 BCP0193 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dime 10.17487/RFC7423
RFC7424 Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks R. Krishnan L. Yong A. Ghanwani N. So B. Khasnabish January 2015 ASCII HTML 29

Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this.

draft-ietf-opsawg-large-flow-load-balancing-15 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7424
RFC7425 Adobe's RTMFP Profile for Flash Communication M. Thornburgh December 2014 ASCII HTML 49

This memo describes how to use Adobe's Secure Real-Time Media Flow Protocol (RTMFP) to transport the video, audio, and data messages of Adobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication.

draft-thornburgh-rtmfp-flash-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7425
RFC7426 Software-Defined Networking (SDN): Layers and Architecture Terminology E. Haleplidis Editor K. Pentikousis Editor S. Denazis J. Hadi Salim D. Meyer O. Koufopavlou January 2015 ASCII HTML 35 Software-defined Networking SDN Programmable Networks Architecture Layer Terminology

Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.

draft-irtf-sdnrg-layer-terminology-04 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7426 10.17487/RFC7426
RFC7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) T. Kivinen J. Snyder January 2015 ASCII HTML 18 IPsec IKE IKEv2 Signature Authentication RSA DSS DSA ECDSA SASSA-PSS PKIX

The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.

draft-kivinen-ipsecme-signature-auth-07 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7427 10.17487/RFC7427
RFC7428 Transmission of IPv6 Packets over ITU-T G.9959 Networks A. Brandt J. Buron February 2015 ASCII HTML 21

This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.

draft-ietf-6lo-lowpanz-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7428
RFC7429 Distributed Mobility Management: Current Practices and Gap Analysis D. Liu Editor JC. Zuniga Editor P. Seite H. Chan CJ. Bernardos January 2015 ASCII HTML 34 DMM Distributed Mobility Management anchor gap analysis best practices

This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.

draft-ietf-dmm-best-practices-gap-analysis-09 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC7429
RFC7430 Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) M. Bagnulo C. Paasch F. Gont O. Bonaventure C. Raiciu July 2015 ASCII HTML 19 MPTCP security threat analysis

This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them.

draft-ietf-mptcp-attacks-04 INFORMATIONAL INFORMATIONAL IETF tsv mptcp http://www.rfc-editor.org/errata_search.php?rfc=7430 10.17487/RFC7430
RFC7431 Multicast-Only Fast Reroute A. Karan C. Filsfils IJ. Wijnands Editor B. Decraene August 2015 ASCII HTML 14

As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).

draft-ietf-rtgwg-mofrr-08 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC7431
RFC7432 BGP MPLS-Based Ethernet VPN A. Sajassi Editor R. Aggarwal N. Bitar A. Isaac J. Uttaro J. Drake W. Henderickx February 2015 ASCII HTML 56

This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".

draft-ietf-l2vpn-evpn-11 RFC8584 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2vpn http://www.rfc-editor.org/errata_search.php?rfc=7432 10.17487/RFC7432
RFC7433 A Mechanism for Transporting User-to-User Call Control Information in SIP A. Johnston J. Rafferty January 2015 ASCII HTML 19 UUI Package Content Encoding Media

There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism.

draft-ietf-cuss-sip-uui-17 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss 10.17487/RFC7433
RFC7434 Interworking ISDN Call Control User Information with SIP K. Drage Editor A. Johnston January 2015 ASCII HTML 17 UUS Supplementary Service

The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital Subscriber Signalling System No. 1 (DSS1) User-user information element within SIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of the User-to-User header field to enable interworking with this ISDN service.

This document covers interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed.

The package is identified by the new value "isdn-uui" of the "purpose" header field parameter.

draft-ietf-cuss-sip-uui-isdn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai cuss http://www.rfc-editor.org/errata_search.php?rfc=7434 10.17487/RFC7434
RFC7435 Opportunistic Security: Some Protection Most of the Time V. Dukhovni December 2014 ASCII HTML 11 authentication encryption

This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.

draft-dukhovni-opportunistic-security-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7435
RFC7436 IP-Only LAN Service (IPLS) H. Shah E. Rosen F. Le Faucheur G. Heron January 2015 ASCII HTML 32

A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.

The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.

draft-ietf-l2vpn-ipls-16 HISTORIC HISTORIC IETF rtg l2vpn 10.17487/RFC7436
RFC7437 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees M. Kucherawy Editor January 2015 ASCII HTML 35 Internet Architecture Board Engineering Steering Group nomcom IAOC

The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various updates since that version was published.

draft-kucherawy-rfc3777bis-04 RFC3777 RFC5078 RFC5633 RFC5680 RFC6859 RFC8713 RFC8318 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7437
RFC7438 Multipoint LDP (mLDP) In-Band Signaling with Wildcards IJ. Wijnands Editor E. Rosen A. Gulko U. Joorde J. Tantsura January 2015 ASCII HTML 16 mpls multicast

There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label Switched Path (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or Bidirectional Multicast trees) to be attached to an MPLS Multipoint Label Switched Path (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP- LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IP Any-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246.

draft-ietf-mpls-mldp-in-band-wildcard-encoding-03 RFC6826 RFC7246 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7438
RFC7439 Gap Analysis for Operating IPv6-Only MPLS Networks W. George Editor C. Pignataro Editor January 2015 ASCII HTML 28 MPLS LDP IPv6 RSVP L3VPN L2VPN

This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations (or lack thereof) in the context of IPv6-only MPLS functionality.

In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations. However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols.

draft-ietf-mpls-ipv6-only-gap-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7439 10.17487/RFC7439
RFC7440 TFTP Windowsize Option P. Masotta January 2015 ASCII HTML 9

The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.

This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension" (RFC 2347).

draft-masotta-tftpexts-windowsize-opt-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7440
RFC7441 Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes IJ. Wijnands E. Rosen U. Joorde January 2015 ASCII HTML 10

Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514.

draft-ietf-l3vpn-mvpn-mldp-nlri-10 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7441
RFC7442 Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) Y. Rekhter R. Aggarwal N. Leymann W. Henderickx Q. Zhao R. Li February 2015 ASCII HTML 11

When IP multicast trees created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions for P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP).

draft-ietf-mpls-pim-sm-over-mldp-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7442
RFC7443 Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages P. Patil T. Reddy G. Salgueiro M. Petit-Huguenin January 2015 ASCII HTML 5

Application-Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) usages, such as Traversal Using Relays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and Datagram Transport Layer Security (DTLS).

draft-ietf-tram-alpn-08 INFORMATIONAL INFORMATIONAL IETF tsv tram 10.17487/RFC7443
RFC7444 Security Labels in Internet Email K. Zeilenga A. Melnikov February 2015 ASCII HTML 16 email header fields ESS Security Label Confidential Label Message Sensitivity

This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.

draft-zeilenga-email-seclabel-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7444
RFC7445 Analysis of Failure Cases in IPv6 Roaming Scenarios G. Chen H. Deng D. Michaud J. Korhonen M. Boucadair March 2015 ASCII HTML 19 Mobile Network Dual Stack IPv6-only

This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios. The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks.

draft-ietf-v6ops-ipv6-roaming-analysis-07 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7445
RFC7446 Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor D. Li W. Imajuku February 2015 ASCII HTML 23 WSON RWA

This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength Switched Optical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed.

draft-ietf-ccamp-rwa-info-24 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7446
RFC7447 Deprecation of BGP Entropy Label Capability Attribute J. Scudder K. Kompella February 2015 ASCII HTML 4

The BGP Entropy Label Capability attribute is defined in RFC 6790. Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice. This specification deprecates the attribute. A forthcoming document will propose a replacement.

draft-ietf-mpls-deprecate-bgp-entropy-label-02 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7447
RFC7448 MIB Transfer from the IETF to the IEEE 802.3 WG T. Taylor Editor D. Romascanu February 2015 ASCII HTML 7 Ethernet IEEE

This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG.

draft-ietf-opsawg-mibs-to-ieee80231-01 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7448
RFC7449 Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment Y. Lee Editor G. Bernstein Editor J. Martensson T. Takeda T. Tsuritani O. Gonzalez de Dios February 2015 ASCII HTML 12

This memo provides application-specific requirements for the Path Computation Element Communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document.

draft-ietf-pce-wson-routing-wavelength-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC7449
RFC7450 Automatic Multicast Tunneling G. Bumgardner February 2015 ASCII HTML 82 AMT IGMPv2 IGMPv3 MLDv1 MLDv2 ASM SSM amt gateway amt relay multicast replication multicast encapsulation

This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.

The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.

draft-ietf-mboned-auto-multicast-18 RFC8777 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC7450
RFC7451 Extension Registry for the Extensible Provisioning Protocol S. Hollenbeck February 2015 ASCII HTML 12 domain host contact

The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.

draft-ietf-eppext-reg-10 INFORMATIONAL INFORMATIONAL IETF app eppext 10.17487/RFC7451
RFC7452 Architectural Considerations in Smart Object Networking H. Tschofenig J. Arkko D. Thaler D. McPherson March 2015 ASCII HTML 24 IAB Statement Smart Objects

The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.

This document offers guidance to engineers designing Internet- connected smart objects.

draft-iab-smart-object-architecture-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7452
RFC7453 MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) V. Mahalingam K. Sampath S. Aldrin T. Nadeau February 2015 ASCII HTML 62

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes additional managed objects and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks.

draft-ietf-mpls-tp-te-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7453
RFC7454 BGP Operations and Security J. Durand I. Pepelnjak G. Doering February 2015 ASCII HTML 26

The Border Gateway Protocol (BGP) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances.

This document describes measures to protect the BGP sessions itself such as Time to Live (TTL), the TCP Authentication Option (TCP-AO), and control-plane filtering. It also describes measures to better control the flow of routing information, using prefix filtering and automation of prefix filters, max-prefix filtering, Autonomous System (AS) path filtering, route flap dampening, and BGP community scrubbing.

draft-ietf-opsec-bgp-security-07 BCP0194 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7454
RFC7455 Transparent Interconnection of Lots of Links (TRILL): Fault Management T. Senevirathne N. Finn S. Salam D. Kumar D. Eastlake 3rd S. Aldrin Y. Li March 2015 ASCII HTML 63 Fault Continuity Connectivity OAM CFM MEP CCM

This document specifies Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (Connectivity Fault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL-specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1. This document updates RFC 6325.

draft-ietf-trill-oam-fm-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7455
RFC7456 Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) T. Mizrahi T. Senevirathne S. Salam D. Kumar D. Eastlake 3rd March 2015 ASCII HTML 32

Performance Monitoring (PM) is a key aspect of Operations, Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms for Loss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks.

draft-ietf-trill-loss-delay-08 PROPOSED STANDARD PROPOSED STANDARD IETF int trill 10.17487/RFC7456
RFC7457 Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) Y. Sheffer R. Holz P. Saint-Andre February 2015 ASCII HTML 13 Transport Layer Security TLS Datagram TLS DTLS Secure Sockets Layer SSL security attacks

Over the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and Datagram TLS (DTLS).

draft-ietf-uta-tls-attacks-05 INFORMATIONAL INFORMATIONAL IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7457 10.17487/RFC7457
RFC7458 Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core R. Valmikam R. Koodli February 2015 ASCII HTML 18 Mobile Networks 3GPP EAP EPC Handover Identity APN

With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks.

The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node (MN)) and its network counterpart (such as an Authentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure.

draft-ietf-netext-wifi-epc-eap-attributes-16 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7458
RFC7459 Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO) M. Thomson J. Winterbottom February 2015 ASCII HTML 39

This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.

This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693.

draft-ietf-geopriv-uncertainty-04 RFC3693 RFC4119 RFC5491 PROPOSED STANDARD PROPOSED STANDARD IETF rai geopriv 10.17487/RFC7459
RFC7460 Monitoring and Control MIB for Power and Energy M. Chandramouli B. Claise B. Schoening J. Quittek T. Dietz March 2015 ASCII HTML 69 management information base IANAPowerStateSet-MIB ENERGY-OBJECT-MIB POWER-ATTRIBUTES-MIB

This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices.

draft-ietf-eman-energy-monitoring-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7460
RFC7461 Energy Object Context MIB J. Parello B. Claise M. Chandramouli March 2015 ASCII HTML 32 management information base ENERGY-OBJECT-CONTEXT-MIB IANA-ENERGY-RELATION-MIB

This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices.

draft-ietf-eman-energy-aware-mib-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7461
RFC7462 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) L. Liess Editor R. Jesske A. Johnston D. Worley P. Kyzivat March 2015 ASCII HTML 46

The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.

This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.

draft-ietf-salud-alert-info-urns-14 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF rai salud 10.17487/RFC7462
RFC7463 Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) A. Johnston Editor M. Soroushnejad Editor V. Venkataramanan March 2015 ASCII HTML 72

This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP Private Branch Exchange (IPBX) offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and 4235.

draft-ietf-bliss-shared-appearances-15 RFC3261 RFC4235 PROPOSED STANDARD PROPOSED STANDARD IETF rai bliss http://www.rfc-editor.org/errata_search.php?rfc=7463 10.17487/RFC7463
RFC7464 JavaScript Object Notation (JSON) Text Sequences N. Williams February 2015 ASCII HTML 8 JSON sequence online streaming log file

This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". A JSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A).

draft-ietf-json-text-sequence-13 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7464 10.17487/RFC7464
RFC7465 Prohibiting RC4 Cipher Suites A. Popov February 2015 ASCII HTML 6 TLS transport layer security

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246.

draft-ietf-tls-prohibiting-rc4-01 RFC5246 RFC4346 RFC2246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7465
RFC7466 An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) C. Dearlove T. Clausen March 2015 ASCII HTML 9 MANET NHDP OLSRv2 link quality

The link quality mechanism of the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.

NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.

This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more "robust".

draft-ietf-manet-nhdp-optimization-04 RFC6130 RFC7181 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7466
RFC7467 URN Namespace for the North Atlantic Treaty Organization (NATO) A. Murdock April 2015 ASCII HTML 8

This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.

draft-murdock-nato-nid-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7467
RFC7468 Textual Encodings of PKIX, PKCS, and CMS Structures S. Josefsson S. Leonard April 2015 ASCII HTML 20

This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

draft-josefsson-pkix-textual-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7468 10.17487/RFC7468
RFC7469 Public Key Pinning Extension for HTTP C. Evans C. Palmer R. Sleevi April 2015 ASCII HTML 28 pin

This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.

draft-ietf-websec-key-pinning-21 PROPOSED STANDARD PROPOSED STANDARD IETF app websec http://www.rfc-editor.org/errata_search.php?rfc=7469 10.17487/RFC7469
RFC7470 Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol F. Zhang A. Farrel March 2015 ASCII HTML 14

The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.

This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.

This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object.

draft-ietf-pce-rfc7150bis-01 RFC7150 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7470
RFC7471 OSPF Traffic Engineering (TE) Metric Extensions S. Giacalone D. Ward J. Drake A. Atlas S. Previdi March 2015 ASCII HTML 19

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.

This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.

Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.

draft-ietf-ospf-te-metric-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7471
RFC7472 Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme I. McDonald M. Sweet March 2015 ASCII HTML 19

This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.

This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.

draft-mcdonald-ipps-uri-scheme-18 RFC2910 RFC2911 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7472
RFC7473 Controlling State Advertisements of Non-negotiated LDP Applications K. Raza S. Boutros March 2015 ASCII HTML 15

There is no capability negotiation done for Label Distribution Protocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session.

draft-ietf-mpls-ldp-ip-pw-capability-09 RFC8223 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7473
RFC7474 Security Extension for OSPFv2 When Using Manual Key Management M. Bhatia S. Hartman D. Zhang A. Lindem Editor April 2015 ASCII HTML 14 OSPF cryptographic authentication security replay attacks

The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.

This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.

draft-ietf-ospf-security-extension-manual-keying-11 RFC2328 RFC5709 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7474
RFC7475 Increasing the Number of Area Directors in an IETF Area S. Dawkins March 2015 ASCII HTML 5

This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).

draft-dawkins-iesg-one-or-more-05 RFC2026 RFC2418 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7475
RFC7476 Information-Centric Networking: Baseline Scenarios K. Pentikousis Editor B. Ohlman D. Corujo G. Boggia G. Tyson E. Davies A. Molinaro S. Eum March 2015 ASCII HTML 45

This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

draft-irtf-icnrg-scenarios-03 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7476
RFC7477 Child-to-Parent Synchronization in DNS W. Hardaker March 2015 ASCII HTML 15

This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy.

draft-ietf-dnsop-child-syncronization-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7477 10.17487/RFC7477
RFC7478 Web Real-Time Communication Use Cases and Requirements C. Holmberg S. Hakansson G. Eriksson March 2015 ASCII HTML 28 webrtc browser websocket real-time

This document describes web-based real-time communication use cases. Requirements on the browser functionality are derived from the use cases.

This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future.

draft-ietf-rtcweb-use-cases-and-requirements-16 INFORMATIONAL INFORMATIONAL IETF rai rtcweb 10.17487/RFC7478
RFC7479 Using Ed25519 in SSHFP Resource Records S. Moonesamy March 2015 ASCII HTML 4

The Ed25519 signature algorithm has been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519.

draft-moonesamy-sshfp-ed25519-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7479 10.17487/RFC7479
RFC7480 HTTP Usage in the Registration Data Access Protocol (RDAP) A. Newton B. Ellacott N. Kong March 2015 ASCII HTML 16 Registry WHOIS

This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.

draft-ietf-weirds-using-http-15 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7480
RFC7481 Security Services for the Registration Data Access Protocol (RDAP) S. Hollenbeck N. Kong March 2015 ASCII HTML 13 RDAP Security

The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP.

draft-ietf-weirds-rdap-sec-12 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds 10.17487/RFC7481
RFC7482 Registration Data Access Protocol (RDAP) Query Format A. Newton S. Hollenbeck March 2015 ASCII HTML 20 WHOIS

This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).

draft-ietf-weirds-rdap-query-18 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7482 10.17487/RFC7482
RFC7483 JSON Responses for the Registration Data Access Protocol (RDAP) A. Newton S. Hollenbeck March 2015 ASCII HTML 78 WHOIS

This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses.

draft-ietf-weirds-json-response-14 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7483 10.17487/RFC7483
RFC7484 Finding the Authoritative Registration Data (RDAP) Service M. Blanchet March 2015 ASCII HTML 17 whois bootstrap IDN AS IPv4 IPv6 JSON

This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers.

draft-ietf-weirds-bootstrap-11 RFC8521 PROPOSED STANDARD PROPOSED STANDARD IETF app weirds http://www.rfc-editor.org/errata_search.php?rfc=7484 10.17487/RFC7484
RFC7485 Inventory and Analysis of WHOIS Registration Objects L. Zhou N. Kong S. Shen S. Sheng A. Servin March 2015 ASCII HTML 33 whois restful weirds response object inventory

WHOIS output objects from registries, including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information. The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration Data Access Protocol (RDAP) responses.

draft-ietf-weirds-object-inventory-06 INFORMATIONAL INFORMATIONAL IETF app weirds 10.17487/RFC7485
RFC7486 HTTP Origin-Bound Authentication (HOBA) S. Farrell P. Hoffman M. Thomas March 2015 ASCII HTML 28 Network Working Group http authentication origin-bound key

HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.

draft-ietf-httpauth-hoba-10 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC7486
RFC7487 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE E. Bellagamba A. Takacs G. Mirsky L. Andersson P. Skoldstrom D. Ward March 2015 ASCII HTML 32 RSVP-TE GMPLS MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE.

draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7487
RFC7488 Port Control Protocol (PCP) Server Selection M. Boucadair R. Penno D. Wing P. Patil T. Reddy March 2015 ASCII HTML 12 PCP Server discovery Port Mapping Shared Address Multiple PCP Servers

This document specifies the behavior to be followed by a Port Control Protocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.

This document updates RFC 6887.

draft-ietf-pcp-server-selection-10 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7488
RFC7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC) M. Kucherawy Editor E. Zwicky Editor March 2015 ASCII HTML 73 domain email security messaging dkim spf authentication reporting conformance

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.

DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.

draft-kucherawy-dmarc-base-12 RFC8553 RFC8616 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7489 10.17487/RFC7489
RFC7490 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) S. Bryant C. Filsfils S. Previdi M. Shand N. So April 2015 ASCII HTML 29

This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.

draft-ietf-rtgwg-remote-lfa-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7490
RFC7491 A PCE-Based Architecture for Application-Based Network Operations D. King A. Farrel March 2015 ASCII HTML 71 Software-Defined Networking (SDN) Path Computation Element (PCE) Network management Network programming

Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to-point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations (ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.

This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications.

draft-farrkingel-pce-abno-architecture-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7491
RFC7492 Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines M. Bhatia D. Zhang M. Jethanandani March 2015 ASCII HTML 9 BFD KARP replay attacks cryptographic authentication security DoS attacks

This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines".

draft-ietf-karp-bfd-analysis-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7492
RFC7493 The I-JSON Message Format T. Bray Editor March 2015 ASCII HTML 6 JSON Internet JSON

I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.

draft-ietf-json-i-json-06 PROPOSED STANDARD PROPOSED STANDARD IETF app json http://www.rfc-editor.org/errata_search.php?rfc=7493 10.17487/RFC7493
RFC7494 IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) C. Shao H. Deng R. Pazhyannur F. Bari R. Zhang S. Matsushima April 2015 ASCII HTML 13 CAPWAP MAC Profile Encryption IEEE 802.11

The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC.

draft-ietf-opsawg-capwap-hybridmac-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7494
RFC7495 Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) A. Montville D. Black March 2015 ASCII HTML 10 IODEF Incident Reference Enumeration Format

The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.

This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.

draft-ietf-mile-enum-reference-format-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC7495
RFC7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension M. Tuexen R. Seggelmann R. Stewart S. Loreto April 2015 ASCII HTML 11

This document defines two additional policies for the Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension. These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer.

draft-ietf-tsvwg-sctp-prpolicies-07 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7496
RFC7497 Rate Measurement Test Protocol Problem Statement and Requirements A. Morton April 2015 ASCII HTML 14 Internet access Asymmetric Packet Size

This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size.

draft-ietf-ippm-rate-problem-10 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7497
RFC7498 Problem Statement for Service Function Chaining P. Quinn Editor T. Nadeau Editor April 2015 ASCII HTML 13 service function chaining steering sfc

This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.

The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.

This document also identifies several key areas that the Service Function Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents.

draft-ietf-sfc-problem-statement-13 INFORMATIONAL INFORMATIONAL IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=7498 10.17487/RFC7498
RFC7499 Support of Fragmentation of RADIUS Packets A. Perez-Mendez Editor R. Marin-Lopez F. Pereniguez-Garcia G. Lopez-Millan D. Lopez A. DeKok April 2015 ASCII HTML 38 RADIUS attribute extension fragmentation chunk

The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.

draft-ietf-radext-radius-fragmentation-12 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7499
RFC7500 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries R. Housley Editor O. Kolkman Editor April 2015 ASCII HTML 7

This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

draft-iab-iana-principles-05 RFC8720 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7500
RFC7501 Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII HTML 20

This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures.

draft-ietf-bmwg-sip-bench-term-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7501
RFC7502 Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration C. Davids V. Gurbani S. Poretsky April 2015 ASCII HTML 21

This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session Border Controllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements.

draft-ietf-bmwg-sip-bench-meth-12 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7502
RFC7503 OSPFv3 Autoconfiguration A. Lindem J. Arkko April 2015 ASCII HTML 15

OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).

draft-ietf-ospf-ospfv3-autoconfig-15 RFC5340 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7503
RFC7504 SMTP 521 and 556 Reply Codes J. Klensin June 2015 ASCII HTML 7 Reply code Email Server No Mail

This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in an Experimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances.

draft-klensin-smtp-521code-07 RFC1846 RFC5321 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7504
RFC7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail J. Levine M. Delany June 2015 ASCII HTML 6 DNS e-mail

Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies.

draft-ietf-appsawg-nullmx-10 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC7505
RFC7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) K. Raza N. Akiya C. Pignataro April 2015 ASCII HTML 6 IPv6 LSP Ping MPLS OAM

RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in the IP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on the Reply Mode used. While a generic "Router shall examine packet" Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations, Administration, and Maintenance (OAM) tools, including the MPLS Echo Request and MPLS Echo Reply messages for MPLS in IPv6 environments. Consequently, it updates RFC 4379.

The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/ Traceroute.

draft-ietf-mpls-oam-ipv6-rao-03 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7506
RFC7507 TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks B. Moeller A. Langley April 2015 ASCII HTML 8

This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included.

draft-ietf-tls-downgrade-scsv-05 RFC2246 RFC4346 RFC4347 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7507
RFC7508 Securing Header Fields with S/MIME L. Cailleux C. Bonatti April 2015 ASCII HTML 19 secure headers

This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non-repudiation, and confidentiality. This extension is referred to as 'Secure Headers'.

draft-cailleux-secure-headers-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7508 10.17487/RFC7508
RFC7509 RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics R. Huang V. Singh May 2015 ASCII HTML 11

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system.

draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11 PROPOSED STANDARD PROPOSED STANDARD IETF rai xrblock 10.17487/RFC7509
RFC7510 Encapsulating MPLS in UDP X. Xu N. Sheth L. Yong R. Callon D. Black April 2015 ASCII HTML 19 MPLS UDP Tunnel Checksum encapsulation multipath ECMP

This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.

draft-ietf-mpls-in-udp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7510 10.17487/RFC7510
RFC7511 Scenic Routing for IPv6 M. Wilhelm April 1 2015 ASCII HTML 8 green it

This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.

draft-scenig-routing INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7511 10.17487/RFC7511
RFC7512 The PKCS #11 URI Scheme J. Pechanec D. Moffat April 2015 ASCII HTML 20 PKCS11 PKCS-11 PKCS#11,

This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".

draft-pechanec-pkcs11uri-21 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7512 10.17487/RFC7512
RFC7513 Source Address Validation Improvement (SAVI) Solution for DHCP J. Bi J. Wu G. Yao F. Baker May 2015 ASCII HTML 54 SAVI-DHCP

This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.

draft-ietf-savi-dhcp-34 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC7513
RFC7514 Really Explicit Congestion Notification (RECN) M. Luckie April 1 2015 ASCII HTML 5

This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).

draft-luckie-recn EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7514
RFC7515 JSON Web Signature (JWS) M. Jones J. Bradley N. Sakimura May 2015 ASCII HTML 59 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.

draft-ietf-jose-json-web-signature-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7515 10.17487/RFC7515
RFC7516 JSON Web Encryption (JWE) M. Jones J. Hildebrand May 2015 ASCII HTML 51 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.

draft-ietf-jose-json-web-encryption-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7516 10.17487/RFC7516
RFC7517 JSON Web Key (JWK) M. Jones May 2015 ASCII HTML 40 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.

draft-ietf-jose-json-web-key-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7517
RFC7518 JSON Web Algorithms (JWA) M. Jones May 2015 ASCII HTML 69

This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.

draft-ietf-jose-json-web-algorithms-40 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7518
RFC7519 JSON Web Token (JWT) M. Jones J. Bradley N. Sakimura May 2015 ASCII HTML 30 Assertion Claim Security Token JavaScript Object Notation JSON JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

draft-ietf-oauth-json-web-token-32 RFC7797 RFC8725 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7519 10.17487/RFC7519
RFC7520 Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) M. Miller May 2015 ASCII HTML 120 JSON Object Signing and Encryption JOSE JavaScript Object Notation JSON JSON Web Signature JWS JSON Web Encryption JWE JSON Web Key JWK JSON Web Algorithms JWA Cookbook

This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data. These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption (JWE) results given similar inputs.

draft-ietf-jose-cookbook-08 INFORMATIONAL INFORMATIONAL IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=7520 10.17487/RFC7520
RFC7521 Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones Y. Goland May 2015 ASCII HTML 20 OAuth SAML JWT Assertion

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

draft-ietf-oauth-assertions-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7521
RFC7522 Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants B. Campbell C. Mortimore M. Jones May 2015 ASCII HTML 15 OAuth SAML Assertion

This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for client authentication.

draft-ietf-oauth-saml2-bearer-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7522
RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants M. Jones B. Campbell C. Mortimore May 2015 ASCII HTML 12 OAuth JWT Assertion Token Security Token

This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.

draft-ietf-oauth-jwt-bearer-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7523
RFC7524 Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) Y. Rekhter E. Rosen R. Aggarwal T. Morin I. Grosclaude N. Leymann S. Saad May 2015 ASCII HTML 42

This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.

draft-ietf-mpls-seamless-mcast-17 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7524
RFC7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Y. Sheffer R. Holz P. Saint-Andre May 2015 ASCII HTML 27 Transport Layer Security TLS DTLS Secure Sockets Layer SSL

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.

draft-ietf-uta-tls-bcp-11 BCP0195 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF app uta http://www.rfc-editor.org/errata_search.php?rfc=7525 10.17487/RFC7525
RFC7526 Deprecating the Anycast Prefix for 6to4 Relay Routers O. Troan B. Carpenter Editor May 2015 ASCII HTML 10

Experience with the 6to4 transition mechanism defined in RFC 3056 ("Connection of IPv6 Domains via IPv4 Clouds") has shown that the mechanism is unsuitable for widespread deployment and use in the Internet when used in its anycast mode. Therefore, this document requests that RFC 3068 ("An Anycast Prefix for 6to4 Relay Routers") and RFC 6732 ("6to4 Provider Managed Tunnels") be made obsolete and moved to Historic status. It recommends that future products should not support 6to4 anycast and that existing deployments should be reviewed. This complements the guidelines in RFC 6343.

draft-ietf-v6ops-6to4-to-historic-11 RFC3068 RFC6732 BCP0196 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7526
RFC7527 Enhanced Duplicate Address Detection R. Asati H. Singh W. Beebee C. Pignataro E. Dart W. George April 2015 ASCII HTML 11 Automated DAD loopback detection

IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back Neighbor Discovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862.

draft-ietf-6man-enhanced-dad-15 RFC4429 RFC4861 RFC4862 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7527
RFC7528 A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association P. Higgs J. Piesing April 2015 ASCII HTML 7

This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications. Example resources include technical documents and specifications, Extensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV.

draft-higgs-hbbtv-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7528
RFC7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) C. Daboo G. Yakushev May 2015 ASCII HTML 21 calendaring iCalendar iTIP CalDAV

This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules.

draft-ietf-calext-rscale-04 RFC5545 RFC6321 RFC7265 PROPOSED STANDARD PROPOSED STANDARD IETF app calext 10.17487/RFC7529
RFC7530 Network File System (NFS) Version 4 Protocol T. Haynes Editor D. Noveck Editor March 2015 ASCII HTML 323

The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

This document, together with the companion External Data Representation (XDR) description document, RFC 7531, obsoletes RFC 3530 as the definition of the NFS version 4 protocol.

draft-ietf-nfsv4-rfc3530bis-35 RFC3530 RFC7931 RFC8587 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7530 10.17487/RFC7530
RFC7531 Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description T. Haynes Editor D. Noveck Editor March 2015 ASCII HTML 39

The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.

draft-ietf-nfsv4-rfc3530bis-dot-x-24 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7531
RFC7532 Namespace Database (NSDB) Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII HTML 65 Federated File Systems

This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

draft-ietf-nfsv4-federated-fs-protocol-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7532
RFC7533 Administration Protocol for Federated File Systems J. Lentini R. Tewari C. Lever Editor March 2015 ASCII HTML 37 Federated File Systems

This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers.

draft-ietf-nfsv4-federated-fs-admin-15 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7533
RFC7534 AS112 Nameserver Operations J. Abley W. Sotomayor May 2015 ASCII HTML 24 AS112 DNS reverse DNS anycast

Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated in RFC 1918 for private use within individual sites.

Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.

It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.

This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.

This document obsoletes RFC 6304.

draft-ietf-dnsop-rfc6304bis-06 RFC6304 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7534
RFC7535 AS112 Redirection Using DNAME J. Abley B. Dickson W. Kumari G. Michaelson May 2015 ASCII HTML 16 DNS root server

AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.

This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure.

draft-ietf-dnsop-as112-dname-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7535
RFC7536 Large-Scale Broadband Measurement Use Cases M. Linsner P. Eardley T. Burbridge F. Sorensen May 2015 ASCII HTML 17 lmap

Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scale Measurement of Broadband Performance (LMAP) framework, information model, and protocol. This document details two use cases that can assist in developing that framework. The details of the measurement metrics themselves are beyond the scope of this document.

draft-ietf-lmap-use-cases-06 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7536
RFC7537 IANA Registries for LSP Ping Code Points B. Decraene N. Akiya C. Pignataro L. Andersson S. Aldrin May 2015 ASCII HTML 7 MPLS OAM lsp ping LSP-Ping

RFCs 4379 and 6424 created name spaces for Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for Downstream Mapping object Flags (DS Flags), Multipath Types, Pad TLVs, and Interface and Label Stack Address Types.

There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose.

draft-ietf-mpls-lsp-ping-registry-03 RFC8029 RFC4379 RFC6424 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7537
RFC7538 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) J. Reschke April 2015 ASCII HTML 6 HTTP redirect status code

This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).

draft-ietf-httpbis-rfc7238bis-03 RFC7238 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis 10.17487/RFC7538
RFC7539 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley May 2015 ASCII HTML 45 AEAD

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.

This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG).

draft-irtf-cfrg-chacha20-poly1305-10 RFC8439 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7539 10.17487/RFC7539
RFC7540 Hypertext Transfer Protocol Version 2 (HTTP/2) M. Belshe R. Peon M. Thomson Editor May 2015 ASCII HTML 96 HTTP SPDY Web

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.

This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

draft-ietf-httpbis-http2-17 RFC8740 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7540 10.17487/RFC7540
RFC7541 HPACK: Header Compression for HTTP/2 R. Peon H. Ruellan May 2015 ASCII HTML 55 HTTP Header

This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

draft-ietf-httpbis-header-compression-12 PROPOSED STANDARD PROPOSED STANDARD IETF app httpbis http://www.rfc-editor.org/errata_search.php?rfc=7541 10.17487/RFC7541
RFC7542 The Network Access Identifier A. DeKok May 2015 ASCII HTML 30

In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282.

draft-ietf-radext-nai-15 RFC4282 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=7542 10.17487/RFC7542
RFC7543 Covering Prefixes Outbound Route Filter for BGP-4 H. Jeng L. Jalil R. Bonica K. Patel L. Yong May 2015 ASCII HTML 21 ORF VPN

This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN (EVPN) networks.

draft-ietf-bess-orf-covering-prefixes-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=7543 10.17487/RFC7543
RFC7544 Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP) M. Mohali August 2015 ASCII HTML 30 Diversion History-Info

Although the SIP History-Info header field described in RFC 7044 is the solution adopted in IETF, the non-standard Diversion header field described, as Historic, in RFC 5806 is nevertheless already implemented and used for conveying call-diversion-related information in Session Initiation Protocol (SIP) signaling.

RFC 7044 obsoletes the original RFC 4244 and redefines the History-Info header field for capturing the history information in requests.

Since the Diversion header field is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This document describes a recommended interworking guideline between the Diversion header field and the History-Info header field to handle call diversion information. This work is intended to enable the migration from non-standard implementations toward IETF specification-based implementations.

This document obsoletes RFC 6044, which describes the interworking between the Diversion header field defined in RFC 5806 and the obsoleted History-Info header field defined on RFC 4244.

draft-mohali-rfc6044bis-02 RFC6044 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7544 10.17487/RFC7544
RFC7545 Protocol to Access White-Space (PAWS) Databases V. Chen Editor S. Das L. Zhu J. Malyar P. McCann May 2015 ASCII HTML 90 dynamic spectrum radio spectrum wireless spectrum spectrum spectrum database TV white space TVWS TVBD white space device WSD

Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "white space". Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.

One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White-Space (PAWS) Databases".

draft-ietf-paws-protocol-20 PROPOSED STANDARD PROPOSED STANDARD IETF app paws 10.17487/RFC7545
RFC7546 Structure of the Generic Security Service (GSS) Negotiation Loop B. Kaduk May 2015 ASCII HTML 21 GSS-API security authentication

This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.

draft-ietf-kitten-gss-loop-05 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC7546
RFC7547 Management of Networks with Constrained Devices: Problem Statement and Requirements M. Ersue Editor D. Romascanu J. Schoenwaelder U. Herberg May 2015 ASCII HTML 44 Constrained Management IoT M2M

This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.

draft-ietf-opsawg-coman-probstate-reqs-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7547
RFC7548 Management of Networks with Constrained Devices: Use Cases M. Ersue Editor D. Romascanu J. Schoenwaelder A. Sehgal May 2015 ASCII HTML 26 Constrained Management IoT M2M

This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on "Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547).

draft-ietf-opsawg-coman-use-cases-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC7548
RFC7549 3GPP SIP URI Inter-Operator Traffic Leg Parameter C. Holmberg J. Holm R. Jesske M. Dolly May 2015 ASCII HTML 17 3GPP IMS NNI IOTL CSCF RAVEL TRF operator transit

In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.

This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).

draft-holmberg-dispatch-iotl-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7549
RFC7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options O. Troan B. Volz M. Siodelski May 2015 ASCII HTML 24 CPE CER CE Customer Edge Router Prefix Delegation IPv6 Address Option Session State Machine Advertise Time Timer T1 T2 Renew Rebind Confirm Decline Provision

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.

draft-ietf-dhc-dhcpv6-stateful-issues-12 RFC8415 RFC3315 RFC3633 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7550
RFC7551 RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) F. Zhang Editor R. Jing R. Gandhi Editor May 2015 ASCII HTML 20

This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.

draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 RFC8537 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7551
RFC7552 Updates to LDP for IPv6 R. Asati C. Pignataro K. Raza V. Manral R. Papneja June 2015 ASCII HTML 24 Label Distribution Protocol

The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720.

draft-ietf-mpls-ldp-ipv6-17 RFC5036 RFC6720 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7552
RFC7553 The Uniform Resource Identifier (URI) DNS Resource Record P. Faltstrom O. Kolkman June 2015 ASCII HTML 14 Operations DNS applications

This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.

draft-faltstrom-uri-14 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7553
RFC7554 Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement T. Watteyne Editor M. Palattella L. Grieco May 2015 ASCII HTML 23 6TiSCH

This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.

draft-ietf-6tisch-tsch-06 INFORMATIONAL INFORMATIONAL IETF int 6tisch http://www.rfc-editor.org/errata_search.php?rfc=7554 10.17487/RFC7554
RFC7555 Proxy MPLS Echo Request G. Swallow V. Lim S. Aldrin June 2015 ASCII HTML 28

This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root).

draft-ietf-mpls-proxy-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7555 10.17487/RFC7555
RFC7556 Multiple Provisioning Domain Architecture D. Anipko Editor June 2015 ASCII HTML 25

This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

draft-ietf-mif-mpvd-arch-11 INFORMATIONAL INFORMATIONAL IETF int mif http://www.rfc-editor.org/errata_search.php?rfc=7556 10.17487/RFC7556
RFC7557 Extension Mechanism for the Babel Routing Protocol J. Chroboczek May 2015 ASCII HTML 11 Babel routing extension TLV sub-TLV

This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.

draft-chroboczek-babel-extension-mechanism-04 RFC6126 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7557
RFC7558 Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions K. Lynn S. Cheshire M. Blanchet D. Migault July 2015 ASCII HTML 14

DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalable DNS-SD.

draft-ietf-dnssd-requirements-06 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC7558
RFC7559 Packet-Loss Resiliency for Router Solicitations S. Krishnan D. Anipko D. Thaler May 2015 ASCII HTML 6

When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations.

draft-ietf-6man-resilient-rs-06 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC7559
RFC7560 Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback M. Kuehlewind Editor R. Scheffenegger B. Briscoe August 2015 ASCII HTML 17 congestion control TCP

Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-Trip Time (RTT). In contrast, ECN for other transport protocols, such as RTP/UDP and SCTP, is specified with more accurate ECN feedback. Recent new TCP mechanisms (like Congestion Exposure (ConEx) or Data Center TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback.

draft-ietf-tcpm-accecn-reqs-08 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7560
RFC7561 Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN J. Kaippallimalil R. Pazhyannur P. Yegani June 2015 ASCII HTML 23 PMIPv6 Wi-Fi QoS

This document provides guidelines for achieving end-to-end Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC) describe methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end-to-end QoS.

draft-ietf-netext-pmip-qos-wifi-08 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7561
RFC7562 Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates D. Thakore July 2015 ASCII HTML 15 Transport Layer Security TLS SupplementalData DTCP

This document specifies the use of Digital Transmission Content Protection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containing DTCP certificates issued by the Digital Transmission Licensing Administrator (DTLA).

draft-dthakore-tls-authz-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7562
RFC7563 Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option R. Pazhyannur S. Speicher S. Gundavelli J. Korhonen J. Kaippallimalil June 2015 ASCII HTML 12

The Access Network Identifier (ANI) mobility option was introduced in RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and the MAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated.

draft-ietf-netext-ani-location-09 RFC6757 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7563
RFC7564 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet May 2015 ASCII HTML 40 internationalization i18n Stringprep

Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 3454.

draft-ietf-precis-framework-23 RFC3454 RFC8264 PROPOSED STANDARD PROPOSED STANDARD IETF app precis http://www.rfc-editor.org/errata_search.php?rfc=7564 10.17487/RFC7564
RFC7565 The 'acct' URI Scheme P. Saint-Andre May 2015 ASCII HTML 8 Uniform Resource Identifier URI

This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account.

draft-ietf-appsawg-acct-uri-07 PROPOSED STANDARD PROPOSED STANDARD IETF app appsawg 10.17487/RFC7565
RFC7566 Enumservice Registration for 'acct' URI L. Goix K. Li June 2015 ASCII HTML 8 Reverse Phone Lookup Social Network Web

This document registers an E.164 Number Mapping (ENUM) service for 'acct' URIs (Uniform Resource Identifiers).

draft-goix-appsawg-enum-acct-uri-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7566
RFC7567 IETF Recommendations Regarding Active Queue Management F. Baker Editor G. Fairhurst Editor July 2015 ASCII HTML 31

This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.

Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.

draft-ietf-aqm-recommendation-11 RFC2309 BCP0197 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv aqm http://www.rfc-editor.org/errata_search.php?rfc=7567 10.17487/RFC7567
RFC7568 Deprecating Secure Sockets Layer Version 3.0 R. Barnes M. Thomson A. Pironti A. Langley June 2015 ASCII HTML 7 SSL TLS insecure diediedie

The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.

This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.

draft-ietf-tls-sslv3-diediedie-03 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7568 10.17487/RFC7568
RFC7569 Registry Specification for Mandatory Access Control (MAC) Security Label Formats D. Quigley J. Lu T. Haynes July 2015 ASCII HTML 10 NFSv4

In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.

To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format.

draft-ietf-nfsv4-lfs-registry-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7569
RFC7570 Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) C. Margaria Editor G. Martinelli S. Balls B. Wright July 2015 ASCII HTML 15 RSVP-TE GMPLS

RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.

draft-ietf-teas-lsp-attribute-ro-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7570
RFC7571 GMPLS RSVP-TE Extensions for Lock Instruct and Loopback J. Dong M. Chen Z. Li D. Ceccarelli July 2015 ASCII HTML 9 OAM

This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.

draft-ietf-teas-rsvp-te-li-lb-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC7571
RFC7572 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging P. Saint-Andre A. Houri J. Hildebrand June 2015 ASCII HTML 13 XMPP Jabber SIP SIMPLE IM Instant Message

This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).

draft-ietf-stox-im-13 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7572
RFC7573 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions P. Saint-Andre S. Loreto June 2015 ASCII HTML 20 Text Chat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).

draft-ietf-stox-chat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7573
RFC7574 Peer-to-Peer Streaming Peer Protocol (PPSPP) A. Bakker R. Petrocco V. Grishchenko July 2015 ASCII HTML 85 video on demand live streaming content integrity protection

The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content. It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers. PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP using Low Extra Delay Background Transport (LEDBAT) for congestion control.

draft-ietf-ppsp-peer-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp http://www.rfc-editor.org/errata_search.php?rfc=7574 10.17487/RFC7574
RFC7575 Autonomic Networking: Definitions and Design Goals M. Behringer M. Pritikin S. Bjarnason A. Clemm B. Carpenter S. Jiang L. Ciavaglia June 2015 ASCII HTML 16 self-management self-chop autonomic secure by default simplification

Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.

This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.

draft-irtf-nmrg-autonomic-network-definitions-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7575
RFC7576 General Gap Analysis for Autonomic Networking S. Jiang B. Carpenter M. Behringer June 2015 ASCII HTML 17

This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.

This document is a product of the IRTF's Network Management Research Group.

draft-irtf-nmrg-an-gap-analysis-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7576
RFC7577 Definition of Managed Objects for Battery Monitoring J. Quittek R. Winter T. Dietz July 2015 ASCII HTML 40 Energy Management Battery Status Battery MIB Management Information Base

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices.

draft-ietf-eman-battery-mib-20 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7577
RFC7578 Returning Values from Forms: multipart/form-data L. Masinter July 2015 ASCII HTML 15 media-type multipurpose internet mail extensions

This specification defines the multipart/form-data media type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. This document obsoletes RFC 2388.

draft-ietf-appsawg-multipart-form-data-11 RFC2388 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7578 10.17487/RFC7578
RFC7579 General Network Element Constraint Encoding for GMPLS-Controlled Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII HTML 28 WSON Optical Network Control Protocol-agnostic encoding

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.

This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.

draft-ietf-ccamp-general-constraint-encode-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7579
RFC7580 OSPF-TE Extensions for General Network Element Constraints F. Zhang Y. Lee J. Han G. Bernstein Y. Xu June 2015 ASCII HTML 12 WSON Optical Routing

Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time division (e.g., Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control of GMPLS.

draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7580
RFC7581 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks G. Bernstein Editor Y. Lee Editor D. Li W. Imajuku J. Han June 2015 ASCII HTML 37 Optical Networks GMPLS control plane Wavelength Assignment Optical LSP Optical Routing

A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (RFC 7446) shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.

This document provides efficient, protocol-agnostic encodings for the WSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE).

draft-ietf-ccamp-rwa-wson-encode-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7581
RFC7582 Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels E. Rosen IJ. Wijnands Y. Cai A. Boers July 2015 ASCII HTML 34

A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels.

draft-ietf-bess-mvpn-bidir-04 RFC6513 RFC6514 RFC6625 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7582
RFC7583 DNSSEC Key Rollover Timing Considerations S. Morris J. Ihren J. Dickinson W. Mekking October 2015 ASCII HTML 31

This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.

draft-ietf-dnsop-dnssec-key-timing-06 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7583
RFC7584 Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs) R. Ravindranath T. Reddy G. Salgueiro July 2015 ASCII HTML 14

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.

This document defines behavior for a B2BUA performing ICE processing. The goal of this document is to ensure that B2BUAs properly handle SIP messages that carry ICE semantics in Session Description Protocol (SDP) and STUN messages received as part of the ICE procedures for NAT and Firewall traversal of multimedia sessions.

draft-ietf-straw-b2bua-stun-08 PROPOSED STANDARD PROPOSED STANDARD IETF art straw http://www.rfc-editor.org/errata_search.php?rfc=7584 10.17487/RFC7584
RFC7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) S. Winter M. McCauley October 2015 ASCII HTML 32 RADIUS AAA Security Reliability DNS

This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).

draft-ietf-radext-dynamic-discovery-15 EXPERIMENTAL EXPERIMENTAL IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=7585 10.17487/RFC7585
RFC7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers Y. Nachum L. Dunbar I. Yerushalmi T. Mizrahi June 2015 ASCII HTML 21 ARP data center proxy

This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.

draft-nachum-sarp-11 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7586
RFC7587 RTP Payload Format for the Opus Speech and Audio Codec J. Spittka K. Vos JM. Valin June 2015 ASCII HTML 18 audio codec

This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP. Further, it describes media type registrations for the RTP payload format.

draft-ietf-payload-rtp-opus-11 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7587
RFC7588 A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem R. Bonica C. Pignataro J. Touch July 2015 ASCII HTML 12 GRE MTU Fragmentation

This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration.

draft-ietf-intarea-gre-mtu-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC7588
RFC7589 Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication M. Badra A. Luchuk J. Schoenwaelder June 2015 ASCII HTML 11 NETCONF TLS

The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539.

draft-ietf-netconf-rfc5539bis-10 RFC5539 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7589
RFC7590 Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre T. Alkemade June 2015 ASCII HTML 9 Extensible Messaging and Presence Protocol XMPP Jabber Secure Sockets Layer SSL Transport Layer Security TLS instant messaging presence encryption authentication

This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120.

draft-ietf-uta-xmpp-07 RFC6120 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7590
RFC7591 OAuth 2.0 Dynamic Client Registration Protocol J. Richer Editor M. Jones J. Bradley M. Machulak P. Hunt July 2015 ASCII HTML 39 OpenID Connect Dynamic Client Registration OpenID Connect oidc openid user managed access uma Dynamic Registration Dynamic Client Registration

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

draft-ietf-oauth-dyn-reg-30 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC7591
RFC7592 OAuth 2.0 Dynamic Client Registration Management Protocol J. Richer Editor M. Jones J. Bradley M. Machulak July 2015 ASCII HTML 18

This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.

draft-ietf-oauth-dyn-reg-management-15 EXPERIMENTAL EXPERIMENTAL IETF sec oauth 10.17487/RFC7592
RFC7593 The eduroam Architecture for Network Roaming K. Wierenga S. Winter T. Wolniewicz September 2015 ASCII HTML 37 Federated Authentication AAA RADIUS IEEE 802.1X roaming EAP eduroam

This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience.

draft-wierenga-ietf-eduroam-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7593 10.17487/RFC7593
RFC7594 A Framework for Large-Scale Measurement of Broadband Performance (LMAP) P. Eardley A. Morton M. Bagnulo T. Burbridge P. Aitken A. Akhter September 2015 ASCII HTML 55 Controller Collector Measurement Agent Metric Measurement Method Measurement Results Registry

Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of Broadband Performance).

draft-ietf-lmap-framework-14 INFORMATIONAL INFORMATIONAL IETF ops lmap 10.17487/RFC7594
RFC7595 Guidelines and Registration Procedures for URI Schemes D. Thaler Editor T. Hansen T. Hardie June 2015 ASCII HTML 19 URI scheme IRI Internationalized Resource Identifier Uniform Resource Identifier URI registration

This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395.

draft-ietf-appsawg-uri-scheme-reg-06 RFC4395 RFC8615 BCP0035 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7595 10.17487/RFC7595
RFC7596 Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture Y. Cui Q. Sun M. Boucadair T. Tsou Y. Lee I. Farrer July 2015 ASCII HTML 22 DS-Lite address sharing address exhaustion aplusp A+P IPv4 service continuity IPv4 over IPv6 connectivity

Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.

draft-ietf-softwire-lw4over6-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7596
RFC7597 Mapping of Address and Port with Encapsulation (MAP-E) O. Troan Editor W. Dec X. Li C. Bao S. Matsushima T. Murakami T. Taylor Editor July 2015 ASCII HTML 35

This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.

draft-ietf-softwire-map-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7597
RFC7598 DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients T. Mrugalski O. Troan I. Farrer S. Perreault W. Dec C. Bao L. Yeh X. Deng July 2015 ASCII HTML 18 MAP DHCPv6

This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.

draft-ietf-softwire-map-dhcp-12 RFC8539 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7598 10.17487/RFC7598
RFC7599 Mapping of Address and Port using Translation (MAP-T) X. Li C. Bao W. Dec Editor O. Troan S. Matsushima T. Murakami July 2015 ASCII HTML 27

This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.

draft-ietf-softwire-map-t-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7599 10.17487/RFC7599
RFC7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) R. Despres S. Jiang Editor R. Penno Y. Lee G. Chen M. Chen July 2015 ASCII HTML 45 Coexistence Transition Interworking Tunneling Stateless 4rd IPv4 IPv6 Mapping Global Addressing

This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.

draft-ietf-softwire-4rd-10 EXPERIMENTAL EXPERIMENTAL IETF int softwire http://www.rfc-editor.org/errata_search.php?rfc=7600 10.17487/RFC7600
RFC7601 Message Header Field for Indicating Message Authentication Status M. Kucherawy August 2015 ASCII HTML 53 DKIM DomainKeys SenderID SPF ADSP ATPS VBR Authentication Reputation

This document specifies a message header field called Authentication- Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

draft-ietf-appsawg-rfc7001bis-11 RFC7001 RFC7410 RFC8601 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7601 10.17487/RFC7601
RFC7602 IS-IS Extended Sequence Number TLV U. Chunduri W. Lu A. Tian N. Shen July 2015 ASCII HTML 12

This document defines the Extended Sequence Number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks.

draft-ietf-isis-extended-sequence-no-tlv-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7602
RFC7603 Energy Management (EMAN) Applicability Statement B. Schoening M. Chandramouli B. Nordman August 2015 ASCII HTML 28

The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures.

draft-ietf-eman-applicability-statement-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops eman 10.17487/RFC7603
RFC7604 Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) M. Westerlund T. Zeng September 2015 ASCII HTML 46 RTP Real-time Transport Protocol Real-time Firewall UDP

This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol (RTSP). Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document.

draft-ietf-mmusic-rtsp-nat-evaluation-16 INFORMATIONAL INFORMATIONAL IETF art mmusic 10.17487/RFC7604
RFC7605 Recommendations on Using Assigned Transport Port Numbers J. Touch August 2015 ASCII HTML 24 tcp udp sctp dccp service iana

This document provides recommendations to designers of application and service protocols on how to use the transport protocol port number space and when to request a port assignment from IANA. It provides designer guidance to requesters or users of port numbers on how to interact with IANA using the processes defined in RFC 6335; thus, this document complements (but does not update) that document.

draft-ietf-tsvwg-port-use-11 BCP0165 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=7605 10.17487/RFC7605
RFC7606 Revised Error Handling for BGP UPDATE Messages E. Chen Editor J. Scudder Editor P. Mohapatra K. Patel August 2015 ASCII HTML 19 BGP

According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.

This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.

draft-ietf-idr-error-handling-19 RFC1997 RFC4271 RFC4360 RFC4456 RFC4760 RFC5543 RFC5701 RFC6368 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7606 10.17487/RFC7606
RFC7607 Codification of AS 0 Processing W. Kumari R. Bush H. Schiller K. Patel August 2015 ASCII HTML 5 BGP AS 0 AS_PATH AS-PATH

This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH, AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message.

draft-ietf-idr-as0-06 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=7607 10.17487/RFC7607
RFC7608 IPv6 Prefix Length Recommendation for Forwarding M. Boucadair A. Petrescu F. Baker July 2015 ASCII HTML 6 IPv6 Routing CIDR Classless Inter-Domain Routing IPv6 Addressing Architecture IPv6 Forwarding Information Base IPv6 Routing Information Base FIB RIB IPv6 Deployment

IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length.

draft-ietf-v6ops-cidr-prefix-03 BCP0198 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7608
RFC7609 IBM's Shared Memory Communications over RDMA (SMC-R) Protocol M. Fox C. Kassimis J. Stevens August 2015 ASCII HTML 143

This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.

draft-fox-tcpm-shared-memory-rdma-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7609
RFC7610 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers F. Gont W. Liu G. Van de Velde August 2015 ASCII HTML 12

This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.

draft-ietf-opsec-dhcpv6-shield-08 BCP0199 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC7610
RFC7611 BGP ACCEPT_OWN Community Attribute J. Uttaro P. Mohapatra D. Smith R. Raszuk J. Scudder August 2015 ASCII HTML 8 BGP VPN L3VPN Extranet Well-known Reserved

Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the same PE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.

draft-ietf-l3vpn-acceptown-community-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7611
RFC7612 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services P. Fleming I. McDonald June 2015 ASCII HTML 54

This document defines a schema, object classes, and attributes, for Printers and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "Internet Printing Protocol/1.1: Model and Semantics" (RFC 2911). Additional Printer attributes are based on definitions in "Printer MIB v2" (RFC 3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG 5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG 5100.13), and "IPP Everywhere" (PWG 5100.14).

This memo is an Independent Submission to the RFC Editor by the Internet Printing Protocol (IPP) Working Group of the IEEE-ISTO Printer Working Group (PWG), as part of their PWG "IPP Everywhere" (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software.

This document obsoletes RFC 3712.

draft-mcdonald-ldap-printer-schema-13 RFC3712 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7612
RFC7613 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords P. Saint-Andre A. Melnikov August 2015 ASCII HTML 27 Username Password Unicode Internationalization i18n Authentication SASLprep strings stringprep

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 4013.

draft-ietf-precis-saslprepbis-18 RFC4013 RFC8265 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC7613
RFC7614 Explicit Subscriptions for the REFER Method R. Sparks August 2015 ASCII HTML 14 SIP SIP Events nosub explicitsub Refer-Events-At

The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing. This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one.

draft-ietf-sipcore-refer-explicit-subscription-03 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7614
RFC7615 HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields J. Reschke September 2015 ASCII HTML 6 HTTP authentication

This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.

draft-ietf-httpbis-auth-info-05 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7615
RFC7616 HTTP Digest Access Authentication R. Shekh-Yusef Editor D. Ahrens S. Bremer September 2015 ASCII HTML 32 HTTP authentication scheme

The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.

draft-ietf-httpauth-digest-19 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF sec httpauth http://www.rfc-editor.org/errata_search.php?rfc=7616 10.17487/RFC7616
RFC7617 The 'Basic' HTTP Authentication Scheme J. Reschke September 2015 ASCII HTML 15 HTTP authentication scheme basic authentication scheme

This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.

draft-ietf-httpauth-basicauth-update-07 RFC2617 PROPOSED STANDARD PROPOSED STANDARD IETF sec httpauth 10.17487/RFC7617
RFC7618 Dynamic Allocation of Shared IPv4 Addresses Y. Cui Q. Sun I. Farrer Y. Lee Q. Sun M. Boucadair August 2015 ASCII HTML 15

This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.

Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized.

draft-ietf-dhc-dynamic-shared-v4allocation-09 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7618
RFC7619 The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) V. Smyslov P. Wouters August 2015 ASCII HTML 12 unauthenticated opportunistic security pervasive monitoring Peer Authorization Database PAD opportunistic encryption

This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity.

draft-ietf-ipsecme-ikev2-null-auth-07 RFC4301 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC7619
RFC7620 Scenarios with Host Identification Complications M. Boucadair Editor B. Chatras T. Reddy B. Williams B. Sarikaya August 2015 ASCII HTML 26 IP address sharing IPv4 service continuity host identifier de-multiplexing connections policy enforcement service delivery

This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered. This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.

This document does not include any solution-specific discussions.

draft-boucadair-intarea-host-identifier-scenarios-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7620
RFC7621 A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework A.B. Roach August 2015 ASCII HTML 4 session initiation protocol

Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.

This document updates RFC 6665.

draft-ietf-sipcore-6665-clarification-00 RFC6665 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7621
RFC7622 Extensible Messaging and Presence Protocol (XMPP): Address Format P. Saint-Andre September 2015 ASCII HTML 27 Extensible Messaging and Presence Protocol XMPP Jabber Messaging Instant Messaging Presence Internationalization i18n PRECIS

This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122.

draft-ietf-xmpp-6122bis-24 RFC6122 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp http://www.rfc-editor.org/errata_search.php?rfc=7622 10.17487/RFC7622
RFC7623 Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) A. Sajassi Editor S. Salam N. Bitar A. Isaac W. Henderickx September 2015 ASCII HTML 23

This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN.

draft-ietf-l2vpn-pbb-evpn-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7623
RFC7624 Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement R. Barnes B. Schneier C. Jennings T. Hardie B. Trammell C. Huitema D. Borkmann August 2015 ASCII HTML 24 eavesdropping

Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.

draft-iab-privsec-confidentiality-threat-07 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7624
RFC7625 Architecture of an IP/MPLS Network with Hardened Pipes J. T. Hao P. Maheshwari R. Huang L. Andersson M. Chen August 2015 ASCII HTML 15

This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the "Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".

This document introduces the concept of a Hard Pipe -- an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.

The Hard Pipe stratum does not use statistical multiplexing; for the LSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.

The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services.

draft-hao-mpls-ip-hard-pipe-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7625
RFC7626 DNS Privacy Considerations S. Bortzmeyer August 2015 ASCII HTML 17 Confidentiality Pervasive Surveillance Domain Name System

This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.

draft-ietf-dprive-problem-statement-06 INFORMATIONAL INFORMATIONAL IETF int dprive 10.17487/RFC7626
RFC7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension K. Bhargavan Editor A. Delignat-Lavaud A. Pironti A. Langley M. Ray September 2015 ASCII HTML 15

The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.

draft-ietf-tls-session-hash-06 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7627
RFC7628 A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth W. Mills T. Showalter H. Tschofenig August 2015 ASCII HTML 21

OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.

This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols.

Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.

draft-ietf-kitten-sasl-oauth-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7628
RFC7629 Flow-Binding Support for Mobile IP S. Gundavelli Editor K. Leung G. Tsirtsis A. Petrescu August 2015 ASCII HTML 19 Multipath Flow Binding Hybrid Access Flow Mobility MIPv4-NEMO

This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care-of addresses.

draft-ietf-mip4-multiple-tunnel-support-13 EXPERIMENTAL EXPERIMENTAL IETF int mip4 10.17487/RFC7629
RFC7630 HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 J. Merkle Editor M. Lochter October 2015 ASCII HTML 14 Network Management SNMP USM HMAC SHA-2

This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414.

draft-ietf-opsawg-hmac-sha-2-usm-snmp-06 RFC7860 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=7630 10.17487/RFC7630
RFC7631 TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format C. Dearlove T. Clausen September 2015 ASCII HTML 15 MANET packet message address TLV

This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork (MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.

This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444.

draft-ietf-manet-tlv-naming-05 RFC5444 RFC7722 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7631
RFC7632 Endpoint Security Posture Assessment: Enterprise Use Cases D. Waltermire D. Harrington September 2015 ASCII HTML 23 security automation continuous monitoring endpoint posture assessment use case asset management configuration management vulnerability management content management

This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture.

draft-ietf-sacm-use-cases-10 INFORMATIONAL INFORMATIONAL IETF sec sacm 10.17487/RFC7632
RFC7633 X.509v3 Transport Layer Security (TLS) Feature Extension P. Hallam-Baker October 2015 ASCII HTML 11 PKIX Transport Layer Security Cryptography Certificate

The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as Online Certificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible.

draft-hallambaker-tlsfeature-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7633 10.17487/RFC7633
RFC7634 ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Y. Nir August 2015 ASCII HTML 13 IKE IPsec AEAD ChaCha ChaCha20 Salsa

This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.

draft-ietf-ipsecme-chacha20-poly1305-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=7634 10.17487/RFC7634
RFC7635 Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization T. Reddy P. Patil R. Ravindranath J. Uberti August 2015 ASCII HTML 24 OAuth 2.0 STUN TURN WebRTC Authentication and Authorization

This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.

draft-ietf-tram-turn-third-party-authz-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram http://www.rfc-editor.org/errata_search.php?rfc=7635 10.17487/RFC7635
RFC7636 Proof Key for Code Exchange by OAuth Public Clients N. Sakimura Editor J. Bradley N. Agarwal September 2015 ASCII HTML 20 smart phones apps XARA authorization custom scheme intent man-in-the-middle eavesdropping user agent swap spop pop openid connect pkce pixie

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").

draft-ietf-oauth-spop-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7636 10.17487/RFC7636
RFC7637 NVGRE: Network Virtualization Using Generic Routing Encapsulation P. Garg Editor Y. Wang Editor September 2015 ASCII HTML 17

This document describes the usage of the Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE.

draft-sridharan-virtualization-nvgre-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7637
RFC7638 JSON Web Key (JWK) Thumbprint M. Jones N. Sakimura September 2015 ASCII HTML 13 JavaScript Object Notation JSON JSON Web Key JWK ThumbprintOB Fingerprint Digest

This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint.

draft-ietf-jose-jwk-thumbprint-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7638
RFC7639 The ALPN HTTP Header Field A. Hutton J. Uberti M. Thomson August 2015 ASCII HTML 7 HTTP CONNECT Firewall HTTP proxy

This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.

draft-ietf-httpbis-tunnel-protocol-05 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7639
RFC7640 Traffic Management Benchmarking B. Constantine R. Krishnan September 2015 ASCII HTML 51

This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.). The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic.

draft-ietf-bmwg-traffic-management-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7640
RFC7641 Observing Resources in the Constrained Application Protocol (CoAP) K. Hartke September 2015 ASCII HTML 30 Smart Objects Internet of Things IoT REST

The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.

draft-ietf-core-observe-16 RFC8323 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC7641
RFC7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements K. LI Editor P. Hunt B. Khasnabish A. Nadalin Z. Zeltsan September 2015 ASCII HTML 19 SIM user scenarios SCIM use cases

This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.

draft-ietf-scim-use-cases-08 INFORMATIONAL INFORMATIONAL IETF art scim 10.17487/RFC7642
RFC7643 System for Cross-domain Identity Management: Core Schema P. Hunt Editor K. Grizzle E. Wahlstroem C. Mortimore September 2015 ASCII HTML 104 Identity Provisioning User Group

The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.

This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers.

draft-ietf-scim-core-schema-22 PROPOSED STANDARD PROPOSED STANDARD IETF art scim http://www.rfc-editor.org/errata_search.php?rfc=7643 10.17487/RFC7643
RFC7644 System for Cross-domain Identity Management: Protocol P. Hunt Editor K. Grizzle M. Ansari E. Wahlstroem C. Mortimore September 2015 ASCII HTML 89 SCIM

The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi-domain scenarios easier to support via a standardized service. Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document.

draft-ietf-scim-api-19 PROPOSED STANDARD PROPOSED STANDARD IETF art scim http://www.rfc-editor.org/errata_search.php?rfc=7644 10.17487/RFC7644
RFC7645 The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis U. Chunduri A. Tian W. Lu September 2015 ASCII HTML 12

This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518) for both manual and automated key management protocols.

draft-ietf-karp-isis-analysis-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7645
RFC7646 Definition and Use of DNSSEC Negative Trust Anchors P. Ebersman W. Kumari C. Griffiths J. Livingood R. Weber September 2015 ASCII HTML 16 NTA ISP Internet Service Provider DNS DNSSEC Negative Trust Anchors

DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

draft-ietf-dnsop-negative-trust-anchors-13 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC7646
RFC7647 Clarifications for the Use of REFER with RFC 6665 R. Sparks A.B. Roach September 2015 ASCII HTML 6

The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes.

draft-ietf-sipcore-refer-clarifications-04 RFC3515 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7647
RFC7648 Port Control Protocol (PCP) Proxy Function S. Perreault M. Boucadair R. Penno D. Wing S. Cheshire September 2015 ASCII HTML 14 NAT firewall CGN AFTR NAT64 port forwarding pinholing port mapping external IP address discover port number running a server behind NAT NAT control NAT cascading DS-Lite incoming connection control outbound connection referral address referral ALG offload PCP client PCP server

This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.

draft-ietf-pcp-proxy-09 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7648
RFC7649 The Jabber Scribe Role at IETF Meetings P. Saint-Andre D. York September 2015 ASCII HTML 12 Jabber Scribe IETF Meetings

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

draft-saintandre-jabber-scribe-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7649
RFC7650 A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) J. Jimenez J. Lopez-Vega J. Maenpaa G. Camarillo September 2015 ASCII HTML 19 CoAP RELOAD

This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSNs) in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in the RELOAD overlay itself, without the use of centralized servers. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged.

draft-jimenez-p2psip-coap-reload-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7650
RFC7651 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2) A. Dodd-Noble S. Gundavelli J. Korhonen F. Baboescu B. Weis September 2015 ASCII HTML 10 P-CSCF P-CSCF Option for IKEv2 Proxy-Call Session Control Function IMS Option for IKEv2

This document defines two new configuration attributes for the Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network.

draft-gundavelli-ipsecme-3gpp-ims-options-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7651
RFC7652 Port Control Protocol (PCP) Authentication Mechanism M. Cullen S. Hartman D. Zhang T. Reddy September 2015 ASCII HTML 34

An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.

This document updates RFC 6887.

draft-ietf-pcp-authentication-14 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp http://www.rfc-editor.org/errata_search.php?rfc=7652 10.17487/RFC7652
RFC7653 DHCPv6 Active Leasequery D. Raghuvanshi K. Kinnear D. Kukrety October 2015 ASCII HTML 30 DHCP IPv6 ACTIVELEASEQUERY DHCPv6

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time the DHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data via TCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options.

draft-ietf-dhc-dhcpv6-active-leasequery-04 RFC5460 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7653
RFC7654 Benchmarking Methodology for In-Service Software Upgrade (ISSU) S. Banks F. Calabria G. Czirjak R. Machat October 2015 ASCII HTML 16

Modern forwarding devices attempt to minimize any control- and data-plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service Software Upgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event.

draft-ietf-bmwg-issu-meth-02 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7654
RFC7655 RTP Payload Format for G.711.0 M. Ramalho Editor P. Jones N. Harada M. Perumal L. Miao November 2015 ASCII HTML 32 G.711.0 G.711 G.711ZIP Lossless G.711 Compression G.711 Data Compression Algorithm

This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format.

draft-ietf-payload-g7110-06 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7655
RFC7656 A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources J. Lennox K. Gross S. Nandakumar G. Salgueiro B. Burman Editor November 2015 ASCII HTML 46 Taxonomy Terminology RTP Grouping

The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.

draft-ietf-avtext-rtp-grouping-taxonomy-08 INFORMATIONAL INFORMATIONAL IETF art avtext 10.17487/RFC7656
RFC7657 Differentiated Services (Diffserv) and Real-Time Communication D. Black Editor P. Jones November 2015 ASCII HTML 26 Diffserv DSCP RAI RTP

This memo describes the interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on the Real-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of these Diffserv aspects for real-time network communication, including WebRTC.

draft-ietf-dart-dscp-rtp-10 INFORMATIONAL INFORMATIONAL IETF rai dart 10.17487/RFC7657
RFC7658 Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs) S. Perreault T. Tsou S. Sivakumar T. Taylor October 2015 ASCII HTML 62 NATV2-MIB management information base

This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.

This document obsoletes RFC 4008. All MIB objects specified in RFC 4008 are included in this version unchanged with only the STATUS changed to deprecated.

draft-perrault-behave-deprecate-nat-mib-v1-06 RFC4008 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7658
RFC7659 Definitions of Managed Objects for Network Address Translators (NATs) S. Perreault T. Tsou S. Sivakumar T. Taylor October 2015 ASCII HTML 84 MIB management information base NATV2-MIB NAT-MIB basic nat pooled nat carrier-grade nat CGN

This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT-MIB. NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN).

draft-perrault-behave-natv2-mib-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7659 10.17487/RFC7659
RFC7660 Diameter Congestion and Filter Attributes L. Bertz S. Manning B. Hirschman October 2015 ASCII HTML 9

This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration.

RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested.

Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.

The optional attributes defined in this document are forward and backwards compatible with RFC 5777.

draft-ietf-dime-congestion-flow-attributes-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7660
RFC7661 Updating TCP to Support Rate-Limited Traffic G. Fairhurst A. Sathiaseelan R. Secchi October 2015 ASCII HTML 21 CWV TCP

This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.

This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.

draft-ietf-tcpm-newcwv-13 RFC2861 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC7661
RFC7662 OAuth 2.0 Token Introspection J. Richer Editor October 2015 ASCII HTML 17 token validation oauth token validation active token inactive token token metadata token status token status check

This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource.

draft-ietf-oauth-introspection-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7662 10.17487/RFC7662
RFC7663 Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) B. Trammell Editor M. Kuehlewind Editor October 2015 ASCII HTML 13 transport layer TCP UDP encapsulation

The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the Stack Evolution in a Middlebox Internet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-semi-report-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7663
RFC7664 Dragonfly Key Exchange D. Harkins Editor November 2015 ASCII HTML 18 elliptic curve PAKE AKE dictionary attack password authentication

This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase. It is resistant to active attack, passive attack, and offline dictionary attack. This document is a product of the Crypto Forum Research Group (CFRG).

draft-irtf-cfrg-dragonfly-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7664 10.17487/RFC7664
RFC7665 Service Function Chaining (SFC) Architecture J. Halpern Editor C. Pignataro Editor October 2015 ASCII HTML 32

This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.

draft-ietf-sfc-architecture-11 INFORMATIONAL INFORMATIONAL IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=7665 10.17487/RFC7665
RFC7666 Management Information Base for Virtual Machines Controlled by a Hypervisor H. Asai M. MacFaden J. Schoenwaelder K. Shima T. Tsou October 2015 ASCII HTML 52 MIB Hypervisor Virtual Machine VM-MIB IANA-STORAGE-MEDIA-TYPE-MIB

This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor).

draft-ietf-opsawg-vmm-mib-04 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=7666 10.17487/RFC7666
RFC7667 RTP Topologies M. Westerlund S. Wenger November 2015 ASCII HTML 48 Real-time Multi-party Mixer Relay SFM Selective Forwarding Middlebox Translator Multicast ASM SSM

This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.

draft-ietf-avtcore-rtp-topologies-update-10 RFC5117 INFORMATIONAL INFORMATIONAL IETF art avtcore 10.17487/RFC7667
RFC7668 IPv6 over BLUETOOTH(R) Low Energy J. Nieminen T. Savolainen M. Isomaki B. Patil Z. Shelby C. Gomez October 2015 ASCII HTML 21 Bluetooth Low Energy 6lowpan IPv6 Low power

Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.

draft-ietf-6lo-btle-17 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC7668
RFC7669 Assigning Digital Object Identifiers to RFCs J. Levine October 2015 ASCII HTML 7

This document describes the way that Digital Object Identifiers (DOIs) are assigned to past and future RFCs. The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion.

draft-iab-doi-05 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7669
RFC7670 Generic Raw Public-Key Support for IKEv2 T. Kivinen P. Wouters H. Tschofenig January 2016 ASCII HTML 10 Internet Key Exchange Version 2

The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This document updates RFC 7296, adding support for other types of raw public keys to IKEv2.

draft-kivinen-ipsecme-oob-pubkey-14 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7670
RFC7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance V. Dukhovni W. Hardaker October 2015 ASCII HTML 33 DANE TLSA

This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.

draft-ietf-dane-ops-16 RFC6698 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7671
RFC7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) V. Dukhovni W. Hardaker October 2015 ASCII HTML 34 DANE TLSA SMTP

This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).

draft-ietf-dane-smtp-with-dane-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=7672 10.17487/RFC7672
RFC7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records T. Finch M. Miller P. Saint-Andre October 2015 ASCII HTML 16

The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.

draft-ietf-dane-srv-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec dane 10.17487/RFC7673
RFC7674 Clarification of the Flowspec Redirect Extended Community J. Haas Editor October 2015 ASCII HTML 7 bgp flowspec

This document updates RFC 5575 ("Dissemination of Flow Specification Rules") to clarify the formatting of the BGP Flowspec Redirect Extended Community.

draft-ietf-idr-flowspec-redirect-rt-bis-05 RFC5575 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7674
RFC7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness M. Perumal D. Wing R. Ravindranath T. Reddy M. Thomson October 2015 ASCII HTML 10 WebRTC

To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.

This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.

draft-ietf-rtcweb-stun-consent-freshness-16 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7675
RFC7676 IPv6 Support for Generic Routing Encapsulation (GRE) C. Pignataro R. Bonica S. Krishnan October 2015 ASCII HTML 11 GRE IPv6

Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.

This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.

draft-ietf-intarea-gre-ipv6-14 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC7676
RFC7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms T. Hansen November 2015 ASCII HTML 8

This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.

draft-hansen-scram-sha256-04 RFC5802 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7677
RFC7678 Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions C. Zhou T. Taylor Q. Sun M. Boucadair October 2015 ASCII HTML 23 DS-Lite Lightweight 4over6 MAP-E IPv4 service continuity IPv6 deployment IPv4 address sharing Diameter Multicast IPv4 over IPv6

During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.

draft-ietf-dime-4over6-provisioning-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7678
RFC7679 A One-Way Delay Metric for IP Performance Metrics (IPPM) G. Almes S. Kalidindi M. Zekauskas A. Morton Editor January 2016 ASCII HTML 27 Performance Measurement Quality of Service (QoS)

This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete.

draft-ietf-ippm-2679-bis-05 RFC2679 STD0081 INTERNET STANDARD INTERNET STANDARD IETF tsv ippm 10.17487/RFC7679
RFC7680 A One-Way Loss Metric for IP Performance Metrics (IPPM) G. Almes S. Kalidindi M. Zekauskas A. Morton Editor January 2016 ASCII HTML 22 Performance Measurement Quality of Service (QoS)

This memo defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2680 obsolete.

draft-ietf-ippm-2680-bis-05 RFC2680 STD0082 INTERNET STANDARD INTERNET STANDARD IETF tsv ippm 10.17487/RFC7680
RFC7681 Email Exchange of Secondary School Transcripts J. Davin October 2015 ASCII HTML 40 Internet Applications email school transcript MIME OpenPGP

A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice.

draft-davin-eesst-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7681
RFC7682 Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration D. McPherson S. Amante E. Osterweil L. Blunk D. Mitchell December 2015 ASCII HTML 18 Resource Certification Internet Routing Registry IRR Routing Policy Specification Language RPSL

The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day.

draft-ietf-grow-irr-routing-policy-considerations-06 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7682
RFC7683 Diameter Overload Indication Conveyance J. Korhonen Editor S. Donovan Editor B. Campbell L. Morand October 2015 ASCII HTML 42 DOIC

This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC).

draft-ietf-dime-ovli-10 RFC8581 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime http://www.rfc-editor.org/errata_search.php?rfc=7683 10.17487/RFC7683
RFC7684 OSPFv2 Prefix/Link Attribute Advertisement P. Psenak H. Gredler R. Shakir W. Henderickx J. Tantsura A. Lindem November 2015 ASCII HTML 15 OSPF-LSA open shortest path first link state advertisement Opaque LSA

OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.

draft-ietf-ospf-prefix-link-attr-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7684
RFC7685 A Transport Layer Security (TLS) ClientHello Padding Extension A. Langley October 2015 ASCII HTML 4

This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size.

draft-ietf-tls-padding-04 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7685
RFC7686 The ".onion" Special-Use Domain Name J. Appelbaum A. Muffett October 2015 ASCII HTML 7

This document registers the ".onion" Special-Use Domain Name.

draft-ietf-dnsop-onion-tld-01 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7686
RFC7687 Report from the Strengthening the Internet (STRINT) Workshop S. Farrell R. Wenning B. Bos M. Blanchet H. Tschofenig December 2015 ASCII HTML 32 IAB W3C STREWS security pervasive monitoring London

The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies (including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-strint-report-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7687
RFC7688 GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Y. Lee Editor G. Bernstein Editor November 2015 ASCII HTML 12

This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength Switched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.

This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical (OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals.

draft-ietf-ccamp-wson-signal-compatibility-ospf-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7688
RFC7689 Signaling Extensions for Wavelength Switched Optical Networks G. Bernstein Editor S. Xu Y. Lee Editor G. Martinelli H. Harai November 2015 ASCII HTML 16

This document provides extensions to Generalized Multiprotocol Label Switching (GMPLS) signaling for control of Wavelength Switched Optical Networks (WSONs). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms.

draft-ietf-ccamp-wson-signaling-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7689
RFC7690 Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) M. Byerly M. Hite J. Jaeggli January 2016 ASCII HTML 9 IPv6 ICMP6 ICMPv6 type 2 PTB

This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures.

draft-ietf-v6ops-pmtud-ecmp-problem-06 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7690
RFC7691 Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members S. Bradner Editor November 2015 ASCII HTML 4

BCP 101 defines the start and end dates for the terms of IETF Administrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct the IAOC to establish more practical start and end dates for terms of IAOC members.

draft-bradner-iaoc-terms-04 RFC8711 RFC4071 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7691
RFC7692 Compression Extensions for WebSocket T. Yoshino December 2015 ASCII HTML 28 DEFLATE LZ77

This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm.

draft-ietf-hybi-permessage-compression-28 PROPOSED STANDARD PROPOSED STANDARD IETF art hybi http://www.rfc-editor.org/errata_search.php?rfc=7692 10.17487/RFC7692
RFC7693 The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) M-J. Saarinen Editor J-P. Aumasson November 2015 ASCII HTML 30 BLAKE2 Cryptographic Hash

This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).

draft-saarinen-blake2-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7693
RFC7694 Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding J. Reschke November 2015 ASCII HTML 7 HTTP content-encoding

In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.

Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.

draft-ietf-httpbis-cice-03 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7694
RFC7695 Distributed Prefix Assignment Algorithm P. Pfister B. Paterson J. Arkko November 2015 ASCII HTML 20 distributed prefix address assignment homenet

This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub-prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated.

draft-ietf-homenet-prefix-assignment-08 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC7695
RFC7696 Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms R. Housley November 2015 ASCII HTML 19

Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.

draft-iab-crypto-alg-agility-08 BCP0201 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7696 10.17487/RFC7696
RFC7697 MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) P. Pan S. Aldrin M. Venkatesan K. Sampath T. Nadeau S. Boutros January 2016 ASCII HTML 36 MPLS-OAM-ID-STD-MIB

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure the Operations, Administration, and Maintenance (OAM) identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP).

draft-ietf-mpls-tp-oam-id-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=7697 10.17487/RFC7697
RFC7698 Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks O. Gonzalez de Dios Editor R. Casellas Editor F. Zhang X. Fu D. Ceccarelli I. Hussain November 2015 ASCII HTML 42 DWDM Flexi-Grid GMPLS

To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid).

Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to the GMPLS protocols will be defined in companion documents.

draft-ietf-ccamp-flexi-grid-fwk-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7698
RFC7699 Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers A. Farrel D. King Y. Li F. Zhang November 2015 ASCII HTML 14 GMPLS RSVP-TE

GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.

This document updates RFCs 3471 and 6205 by introducing a new label format.

draft-ietf-ccamp-flexigrid-lambda-label-05 RFC3471 RFC6205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7699
RFC7700 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames P. Saint-Andre December 2015 ASCII HTML 11 nickname SIP SIMPLE XMPP MSRP XCON chatrooms

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities.

draft-ietf-precis-nickname-19 RFC8266 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=7700 10.17487/RFC7700
RFC7701 Multi-party Chat Using the Message Session Relay Protocol (MSRP) A. Niemi M. Garcia-Martin G. Sandbakken December 2015 ASCII HTML 42 messaging message sessions multi-party chat MSRP SIMPLE

The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP.

draft-ietf-simple-chat-18 PROPOSED STANDARD PROPOSED STANDARD IETF rai simple 10.17487/RFC7701
RFC7702 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat P. Saint-Andre S. Ibarra S. Loreto December 2015 ASCII HTML 43 Text Chat Groupchat Instant Messaging Session Initiation Protocol SIP Message Sessions Relay Protocol MSRP Extensible Messaging and Presence Protocol XMPP

This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension.

draft-ietf-stox-groupchat-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC7702
RFC7703 Experience with Testing of Mapping of Address and Port Using Translation (MAP-T) E. Cordeiro R. Carnier A. Moreiras November 2015 ASCII HTML 56 template

This document describes the testing result of a network utilizing a Mapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.

The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines.

draft-cordeiro-experience-mapt-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7703
RFC7704 An IETF with Much Diversity and Professional Conduct D. Crocker N. Clark November 2015 ASCII HTML 18

The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF.

draft-crocker-diversity-conduct-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7704
RFC7705 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute W. George S. Amante November 2015 ASCII HTML 16 as-migration AS-migration AS_migration AS migration IDR BGP

This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.

draft-ietf-idr-as-migration-06 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7705
RFC7706 Decreasing Access Time to Root Servers by Running One on Loopback W. Kumari P. Hoffman November 2015 ASCII HTML 12

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1). This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator.

draft-ietf-dnsop-root-loopback-05 RFC8806 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7706 10.17487/RFC7706
RFC7707 Network Reconnaissance in IPv6 Networks F. Gont T. Chown March 2016 ASCII HTML 38

IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.

draft-ietf-opsec-ipv6-host-scanning-08 RFC5157 INFORMATIONAL INFORMATIONAL IETF ops opsec http://www.rfc-editor.org/errata_search.php?rfc=7707 10.17487/RFC7707
RFC7708 Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator T. Nadeau L. Martini S. Bryant November 2015 ASCII HTML 9 VCCV GAL

The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated Channel Label defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations, Administration, and Maintenance (OAM) identification, particularly in MPLS Transport Profile (MPLS-TP) networks (RFC 5921).

draft-ietf-pals-vccv-for-gal-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7708
RFC7709 Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) A. Malis Editor B. Wilson G. Clapp V. Shukla November 2015 ASCII HTML 9 generalized multiprotocol label switching OTN optical transport networks WSON TDM WDM churn on-demand wavelength rapid setup

Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification), LSP set up delay, quality-of-service differentiation, and different levels of resilience.

The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-Protocol Label Switching (GMPLS).

draft-ietf-teas-fast-lsps-requirements-02 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC7709
RFC7710 Captive-Portal Identification Using DHCP or Router Advertisements (RAs) W. Kumari O. Gudmundsson P. Ebersman S. Sheng December 2015 ASCII HTML 8

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.

This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document.

draft-wkumari-dhc-capport-16 RFC8910 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7710
RFC7711 PKIX over Secure HTTP (POSH) M. Miller P. Saint-Andre November 2015 ASCII HTML 18 Extensible Messaging and Presence Protocol Jabber federation

Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.

draft-ietf-xmpp-posh-06 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp http://www.rfc-editor.org/errata_search.php?rfc=7711 10.17487/RFC7711
RFC7712 Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) P. Saint-Andre M. Miller P. Hancke November 2015 ASCII HTML 24 XMPP Extensible Messaging and Presence Protocol Jabber federation delegation security

This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains.

draft-ietf-xmpp-dna-11 PROPOSED STANDARD PROPOSED STANDARD IETF art xmpp 10.17487/RFC7712
RFC7713 Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements M. Mathis B. Briscoe December 2015 ASCII HTML 30 Quality of Service QoS Congestion Control Signaling Protocol Encoding Audit Policing

This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.

draft-ietf-conex-abstract-mech-13 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC7713
RFC7714 AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) D. McGrew K. Igoe December 2015 ASCII HTML 48

This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP).

draft-ietf-avtcore-srtp-aes-gcm-17 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore http://www.rfc-editor.org/errata_search.php?rfc=7714 10.17487/RFC7714
RFC7715 Multipoint LDP (mLDP) Node Protection IJ. Wijnands Editor K. Raza A. Atlas J. Tantsura Q. Zhao January 2016 ASCII HTML 19

This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.

draft-ietf-mpls-mldp-node-protection-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7715
RFC7716 Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures J. Zhang L. Giuliano E. Rosen Editor K. Subramanian D. Pacella December 2015 ASCII HTML 22 Multicast

RFCs 6513, 6514, and others describe protocols and procedures that a Service Provider (SP) may deploy in order to offer Multicast Virtual Private Network (Multicast VPN or MVPN) service to its customers. Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as "Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures for Global Table Multicast.

draft-ietf-bess-mvpn-global-table-mcast-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7716
RFC7717 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) K. Pentikousis Editor E. Zhang Y. Cui December 2015 ASCII HTML 15

The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.

draft-ietf-ippm-ipsec-11 RFC4656 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7717
RFC7718 Registries for the One-Way Active Measurement Protocol (OWAMP) A. Morton December 2015 ASCII HTML 7

This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.

draft-ietf-ippm-owamp-registry-03 RFC4656 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7718
RFC7719 DNS Terminology P. Hoffman A. Sullivan K. Fujiwara December 2015 ASCII HTML 27

The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.

draft-ietf-dnsop-dns-terminology-05 RFC8499 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7719 10.17487/RFC7719
RFC7720 DNS Root Name Service Protocol and Deployment Requirements M. Blanchet L-J. Liman December 2015 ASCII HTML 6

The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope.

draft-iab-2870bis-03 RFC2870 BCP0040 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF IESG 10.17487/RFC7720
RFC7721 Security and Privacy Considerations for IPv6 Address Generation Mechanisms A. Cooper F. Gont D. Thaler March 2016 ASCII HTML 18

This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.

draft-ietf-6man-ipv6-address-generation-privacy-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7721
RFC7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) C. Dearlove T. Clausen December 2015 ASCII HTML 23

This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.

This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.

draft-ietf-manet-olsrv2-multitopology-07 RFC7188 RFC7631 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7722
RFC7723 Port Control Protocol (PCP) Anycast Addresses S. Kiesel R. Penno January 2016 ASCII HTML 9 Port Control Protocol anycast address anycast server discovery Port Control Protocol server discovery port mapping NAT control firewall control

The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-path NAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses.

draft-ietf-pcp-anycast-08 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7723
RFC7724 Active DHCPv4 Lease Query K. Kinnear M. Stapp B. Volz N. Russell December 2015 ASCII HTML 28

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible. In addition, continuous update of an external requestor with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery".

draft-ietf-dhc-dhcpv4-active-leasequery-07 RFC6926 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7724
RFC7725 An HTTP Status Code to Report Legal Obstacles T. Bray February 2016 ASCII HTML 5 Hypertext Transfer Protocol

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

draft-ietf-httpbis-legally-restricted-status-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=7725 10.17487/RFC7725
RFC7726 Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) V. Govindan K. Rajaraman G. Mirsky N. Akiya S. Aldrin January 2016 ASCII HTML 7 RFC5884 MPLS LSP BFD RFC 5884

This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional Forwarding Detection) sessions for a given <MPLS LSP, FEC> as described in RFC 5884.

draft-ietf-bfd-rfc5884-clarifications-04 RFC5884 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7726
RFC7727 Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) M. Zhang H. Wen J. Hu January 2016 ASCII HTML 25

The Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis redundancy mechanism that is used to support high network availability.

In this document, Provider Edge (PE) devices in a Redundancy Group (RG) running ICCP are used to offer multihomed connectivity to Spanning Tree Protocol (STP) networks to improve availability of the STP networks. The ICCP TLVs and usage for the ICCP STP application are defined.

draft-ietf-pwe3-iccp-stp-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7727
RFC7728 RTP Stream Pause and Resume B. Burman A. Akram R. Even M. Westerlund February 2016 ASCII HTML 55 CCM RTCP Feedback Bandwidth PAUSED REFUSED TMMBR TMMBN Mixer MCU

With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104.

draft-ietf-avtext-rtp-stream-pause-10 RFC5104 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext http://www.rfc-editor.org/errata_search.php?rfc=7728 10.17487/RFC7728
RFC7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management B. Khasnabish E. Haleplidis J. Hadi Salim Editor December 2015 ASCII HTML 20 ForCES LFB Subsidiary Management Virtualization

Deployment experience has demonstrated the value of using the Forwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, the Forwarding Element Manager (FEM) is modeled by creating a Logical Functional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element (CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information.

draft-ietf-forces-lfb-subsidiary-management-02 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7729 10.17487/RFC7729
RFC7730 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent January 2016 ASCII HTML 8 RPKI BGP Security

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL.

draft-ietf-sidr-rfc6490-bis-05 RFC6490 RFC8630 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7730
RFC7731 Multicast Protocol for Low-Power and Lossy Networks (MPL) J. Hui R. Kelsey February 2016 ASCII HTML 29 6lowpan 802.15.4 IPv6 LLN ROLL mesh network trickle wsn wireless sensor network

This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.

MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.

draft-ietf-roll-trickle-mcast-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7731
RFC7732 Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) P. van der Stok R. Cragie February 2016 ASCII HTML 15 routing MPL multicast policy IP networks

The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router.

draft-ietf-roll-admin-local-policy-03 INFORMATIONAL INFORMATIONAL IETF rtg roll 10.17487/RFC7732
RFC7733 Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control A. Brandt E. Baccelli R. Cragie P. van der Stok February 2016 ASCII HTML 38 sensor network ad hoc network routing RPL applicability building control home automation IP networks

The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.

draft-ietf-roll-applicability-home-building-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC7733
RFC7734 Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) D. Allan Editor J. Tantsura D. Fedyk A. Sajassi January 2016 ASCII HTML 11 SPBM Provider Backbone Bridging Provider Edges PBB-EVPN

This document describes how Ethernet Shortest Path Bridging MAC mode (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with Provider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations of Ethernet networks.

draft-ietf-bess-spbm-evpn-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7734
RFC7735 Tracking Reviews of Documents R. Sparks T. Kivinen January 2016 ASCII HTML 16 review tool requirements

Several review teams ensure specific types of review are performed on Internet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows.

draft-sparks-genarea-review-tracker-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7735
RFC7736 Content Delivery Network Interconnection (CDNI) Media Type Registration K. Ma December 2015 ASCII HTML 7 CDNI CDN Interconnect CDN content delivery content delivery network

This document defines the standard media type used by the Content Delivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter.

draft-ietf-cdni-media-type-06 INFORMATIONAL INFORMATIONAL IETF art cdni 10.17487/RFC7736
RFC7737 Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification N. Akiya G. Swallow C. Pignataro L. Andersson M. Chen January 2016 ASCII HTML 17 MPLS LSP Ping Reply Mode

The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of this Reply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of Reply Mode values.

draft-ietf-mpls-lsp-ping-reply-mode-simple-05 RFC7110 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7737
RFC7738 A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS) M. Blanchet A. Schiltknecht P. Shames January 2016 ASCII HTML 8

This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS).

draft-blanchet-ccsds-urn-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7738
RFC7739 Security Implications of Predictable Fragment Identification Values F. Gont February 2016 ASCII HTML 20 attack vulnerability Denial of Service protocol identifiers

IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.

draft-ietf-6man-predictable-fragment-id-10 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC7739
RFC7740 Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication Z. Zhang Y. Rekhter A. Dolganow January 2016 ASCII HTML 8 MVPN Ingress Replication Bidirectional C-flow p-tunnel

RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using Ingress Replication. This solution enables a service provider to use Ingress Replication to offer transparent bidirectional multicast service to its VPN customers.

draft-ietf-bess-mvpn-bidir-ingress-replication-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7740
RFC7741 RTP Payload Format for VP8 Video P. Westin H. Lundin M. Glover J. Uberti F. Galligan March 2016 ASCII HTML 27 RTP V8 WebM

This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences.

draft-ietf-payload-vp8-17 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7741
RFC7742 WebRTC Video Processing and Codec Requirements A.B. Roach March 2016 ASCII HTML 10 MTI mandatory-to-implement

This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters.

draft-ietf-rtcweb-video-06 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7742
RFC7743 Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping J. Luo Editor L. Jin Editor T. Nadeau Editor G. Swallow Editor January 2016 ASCII HTML 18

In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379.

draft-ietf-mpls-lsp-ping-relay-reply-11 RFC4379 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7743
RFC7744 Use Cases for Authentication and Authorization in Constrained Environments L. Seitz Editor S. Gerdes Editor G. Selander M. Mani S. Kumar January 2016 ASCII HTML 30 Internet of Things IoT Smart Object Security

Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.

This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.

Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally.

draft-ietf-ace-usecases-10 INFORMATIONAL INFORMATIONAL IETF sec ace 10.17487/RFC7744
RFC7745 XML Schemas for Reverse DNS Management T. Manderson January 2016 ASCII HTML 10

This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an HTTPS transaction that is mediated by an X.509 certificate.

draft-manderson-rdns-xml-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7745
RFC7746 Label Switched Path (LSP) Self-Ping R. Bonica I. Minei M. Conn D. Pacella L. Tomotaki January 2016 ASCII HTML 12

When certain RSVP-TE optimizations are implemented, ingress Label Switching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.

This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.

LSP Self-ping is a new protocol. It is not an extension of LSP Ping. Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.

LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs.

draft-ietf-mpls-self-ping-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7746
RFC7747 Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence R. Papneja B. Parise S. Hares D. Lee I. Varlashkin April 2016 ASCII HTML 35 BMWG

BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098.

draft-ietf-bmwg-bgp-basic-convergence-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC7747
RFC7748 Elliptic Curves for Security A. Langley M. Hamburg S. Turner January 2016 ASCII HTML 22 elliptic curve cryptography ecc

This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.

draft-irtf-cfrg-curves-11 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=7748 10.17487/RFC7748
RFC7749 The "xml2rfc" Version 2 Vocabulary J. Reschke February 2016 ASCII HTML 76 XML IETF RFC Internet-Draft Vocabulary

This document defines the "xml2rfc" version 2 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts.

Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.

This document obsoletes RFC 2629.

draft-iab-xml2rfcv2-02 RFC2629 RFC7991 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7749 10.17487/RFC7749
RFC7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) J. Hedin G. Mirsky S. Baillargeon February 2016 ASCII HTML 11 IPPM TWAMP Type-P Descriptor

This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing the monitoring of the Differentiated Service Code Point and Explicit Congestion Notification fields with the TWAMP-Test protocol.

draft-ietf-ippm-type-p-monitor-03 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC7750
RFC7751 Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) S. Sorce T. Yu March 2016 ASCII HTML 10 Kerberos

This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container. This document updates RFC 4120.

draft-ietf-kitten-cammac-04 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7751
RFC7752 North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP H. Gredler Editor J. Medved S. Previdi A. Farrel S. Ray March 2016 ASCII HTML 48 BGP North-Bound API Link-State Topology Controller Multi-Area Multi-AS

In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.

This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.

Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).

draft-ietf-idr-ls-distribution-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7752
RFC7753 Port Control Protocol (PCP) Extension for Port-Set Allocation Q. Sun M. Boucadair S. Sivakumar C. Zhou T. Tsou S. Perreault February 2016 ASCII HTML 19 IPv4 service continuity IPv4 address shortage A+P AplusP address plus port MAP Port range Port Range Router MAP-E port set mapping port bulk

In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET.

draft-ietf-pcp-port-set-13 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7753
RFC7754 Technical Considerations for Internet Service Blocking and Filtering R. Barnes A. Cooper O. Kolkman D. Thaler E. Nordmark March 2016 ASCII HTML 33 Firewall Filter Deep Packet Inspection Domain Name Seizure Web Portal Web Proxy

The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.

draft-iab-filtering-considerations-09 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7754
RFC7755 SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments T. Anderson February 2016 ASCII HTML 24 Data Centre Data Center Dual Stack Single Stack IDC IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.

The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.

draft-ietf-v6ops-siit-dc-03 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7755
RFC7756 Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode T. Anderson S. Steffann February 2016 ASCII HTML 17 Data Centre Data Center Dual Stack Single Stack IDC IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.

The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.

draft-ietf-v6ops-siit-dc-2xlat-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC7756
RFC7757 Explicit Address Mappings for Stateless IP/ICMP Translation T. Anderson A. Leiva Popper February 2016 ASCII HTML 19 Dual Stack Single Stack IPv4 IPv4 conservation IPv4 exhaustion IPv6-only IPv6 only IPv6 transition IPv6 transition technology XLAT

This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4.

draft-ietf-v6ops-siit-eam-03 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC7757
RFC7758 Time Capability in NETCONF T. Mizrahi Y. Moses February 2016 ASCII HTML 32 NETCONF network management time clock synchronization

This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.

draft-mm-netconf-time-capability-09 EXPERIMENTAL EXPERIMENTAL IETF NON WORKING GROUP 10.17487/RFC7758
RFC7759 Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping E. Bellagamba G. Mirsky L. Andersson P. Skoldstrom D. Ward J. Drake February 2016 ASCII HTML 29 LSP-PING MPLS MPLS-TP OAM

This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol.

draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7759
RFC7760 Statement of Work for Extensions to the IETF Datatracker for Author Statistics R. Housley January 2016 ASCII HTML 8

This is the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.

draft-housley-sow-author-statistics-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7760
RFC7761 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) B. Fenner M. Handley H. Holbrook I. Kouvelas R. Parekh Z. Zhang L. Zheng March 2016 ASCII HTML 137

This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.

This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.

draft-ietf-pim-rfc4601bis-06 RFC4601 RFC8736 STD0083 INTERNET STANDARD INTERNET STANDARD IETF rtg pim http://www.rfc-editor.org/errata_search.php?rfc=7761 10.17487/RFC7761
RFC7762 Initial Assignment for the Content Security Policy Directives Registry M. West January 2016 ASCII HTML 5

This document establishes an Internet Assigned Number Authority (IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content Security Policy Level 2 specification.

draft-west-webappsec-csp-reg-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7762
RFC7763 The text/markdown Media Type S. Leonard March 2016 ASCII HTML 15

This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.

draft-ietf-appsawg-text-markdown-12 INFORMATIONAL INFORMATIONAL IETF art appsawg 10.17487/RFC7763
RFC7764 Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations S. Leonard March 2016 ASCII HTML 28 text/markdown

This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. Background information, local storage strategies, and additional syntax registrations are supplied.

draft-ietf-appsawg-text-markdown-use-cases-07 INFORMATIONAL INFORMATIONAL IETF art appsawg 10.17487/RFC7764
RFC7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart P. Hurtig A. Brunstrom A. Petlund M. Welzl February 2016 ASCII HTML 15 tcp retransmission timer rtor

This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited.

draft-ietf-tcpm-rtorestart-10 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC7765
RFC7766 DNS Transport over TCP - Implementation Requirements J. Dickinson S. Dickinson R. Bellis A. Mankin D. Wessels March 2016 ASCII HTML 19 DNS TCP/IP transport

This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.

draft-ietf-dnsop-5966bis-06 RFC5966 RFC1035 RFC1123 RFC8490 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7766
RFC7767 Application-Initiated Check-Pointing via the Port Control Protocol (PCP) S. Vinapamula S. Sivakumar M. Boucadair T. Reddy February 2016 ASCII HTML 12 serviceability SDN resilience robustness network programmability network API application control service-aware networking automation

This document specifies a mechanism for a host to indicate via the Port Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.

This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed.

draft-vinapamula-flow-ha-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7767
RFC7768 Port Management to Reduce Logging in Large-Scale NATs T. Tsou W. Li T. Taylor J. Huang January 2016 ASCII HTML 11

Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low.

draft-tsou-behave-natx4-log-reduction-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7768
RFC7769 Media Access Control (MAC) Address Withdrawal over Static Pseudowire S. Sivabalan S. Boutros H. Shah S. Aldrin M. Venkatesan February 2016 ASCII HTML 10 PW ACH associated channel

This document specifies a mechanism to signal Media Access Control (MAC) address withdrawal notification using a pseudowire (PW) Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LAN Service (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment.

draft-ietf-pals-mpls-tp-mac-wd-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7769
RFC7770 Extensions to OSPF for Advertising Optional Router Capabilities A. Lindem Editor N. Shen JP. Vasseur R. Aggarwal S. Shaffer February 2016 ASCII HTML 15 ospfv2 ospfv3 open shortest path first ri router information lsa link state advertisement

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.

draft-ietf-ospf-rfc4970bis-07 RFC4970 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7770
RFC7771 Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires A. Malis Editor L. Andersson H. van Helvoort J. Shin L. Wang A. D'Alessandro January 2016 ASCII HTML 9 end-to-end protection linear protection

In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection. With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures via MPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of the Switching Provider Edge Routers (S-PEs) along the path of the MS-PW. This document describes how to achieve this protection via redundant MS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection.

draft-ietf-pals-ms-pw-protection-04 RFC6870 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7771
RFC7772 Reducing Energy Consumption of Router Advertisements A. Yourtchenko L. Colitti February 2016 ASCII HTML 6

Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.

draft-ietf-v6ops-reducing-ra-energy-consumption-03 BCP0202 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops 10.17487/RFC7772
RFC7773 Authentication Context Certificate Extension S. Santesson March 2016 ASCII HTML 16

This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.

This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion Markup Language (SAML) assertion.

draft-santesson-auth-context-extension-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7773
RFC7774 Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 Y. Doi M. Gillmore March 2016 ASCII HTML 10 MPL DHCPv6

This document defines a way to configure a parameter set for MPL (Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in an MPL Domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters.

draft-ietf-roll-mpl-parameter-configuration-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=7774 10.17487/RFC7774
RFC7775 IS-IS Route Preference for Extended IP and IPv6 Reachability L. Ginsberg S. Litkowski S. Previdi February 2016 ASCII HTML 11

In existing specifications, the route preferences for IPv4/IPv6 Extended Reachability TLVs are not explicitly stated. There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2 Link State Protocol Data Units (LSPs). This document addresses these issues.

draft-ietf-isis-route-preference-02 RFC5308 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7775
RFC7776 IETF Anti-Harassment Procedures P. Resnick A. Farrel March 2016 ASCII HTML 18 Ombudsman Ombudsperson Ombudsteam

IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.

This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.

draft-farrresnickel-harassment-10 RFC2418 RFC8716 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7776
RFC7777 Advertising Node Administrative Tags in OSPF S. Hegde R. Shakir A. Smirnov Z. Li B. Decraene March 2016 ASCII HTML 15 open shortest path first

This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to the OSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.

This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags.

draft-ietf-ospf-node-admin-tag-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7777
RFC7778 Mobile Communication Congestion Exposure Scenario D. Kutscher F. Mir R. Winter S. Krishnan Y. Zhang CJ. Bernardos March 2016 ASCII HTML 25 congestion exposure mobile communications

This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks.

draft-ietf-conex-mobile-06 INFORMATIONAL INFORMATIONAL IETF tsv conex 10.17487/RFC7778
RFC7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) H. Rogge E. Baccelli April 2016 ASCII HTML 21 MANET metric ad hoc network routing IP networks OLSR ETT ETX Funkfeuer DAT

This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).

draft-ietf-manet-olsrv2-dat-metric-12 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7779
RFC7780 Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates D. Eastlake 3rd M. Zhang R. Perlman A. Banerjee A. Ghanwani S. Gupta February 2016 ASCII HTML 57 TRILL RBridge IS-IS reachability overload MTU DEI multicast RPF color E-L1FS purge

Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.

draft-ietf-trill-rfc7180bis-07 RFC7180 RFC6325 RFC7177 RFC7179 RFC8249 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7780
RFC7781 Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access H. Zhai T. Senevirathne R. Perlman M. Zhang Y. Li February 2016 ASCII HTML 35 virtual RBridge aggregation flip-flopping

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.

draft-ietf-trill-pseudonode-nickname-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7781
RFC7782 Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments M. Zhang R. Perlman H. Zhai M. Durrani S. Gupta February 2016 ASCII HTML 22 LAALP vSwitch MC-LAG DRNI

TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.

This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one host Media Access Control (MAC) address being associated with the multiple RBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein.

draft-ietf-trill-aa-multi-attach-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7782
RFC7783 Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) T. Senevirathne J. Pathangi J. Hudson February 2016 ASCII HTML 16 Affinity RPF

TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarders provide VLAN-based load sharing with an active-standby model. High-performance applications require an active-active load-sharing model. The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325.

draft-ietf-trill-cmt-11 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7783
RFC7784 Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB D. Kumar S. Salam T. Senevirathne February 2016 ASCII HTML 50 CFM MEP MIP Fault Management

This document specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links).

draft-ietf-trill-oam-mib-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7784
RFC7785 Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite S. Vinapamula M. Boucadair February 2016 ASCII HTML 9 IPv4 service continuity IPv4 address exhaustion Service Availability High Availability Address sharing IPv6 Reliability IPv4 over IPv6 State migration Stability Disruption Privacy

This document discusses issues induced by the change of the Dual- Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues.

draft-vinapamula-softwire-dslite-prefix-binding-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7785
RFC7786 TCP Modifications for Congestion Exposure (ConEx) M. Kuehlewind Editor R. Scheffenegger May 2016 ASCII HTML 20

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).

draft-ietf-conex-tcp-modifications-10 EXPERIMENTAL EXPERIMENTAL IETF tsv conex 10.17487/RFC7786
RFC7787 Distributed Node Consensus Protocol M. Stenberg S. Barth April 2016 ASCII HTML 41 Homenet

This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.

draft-ietf-homenet-dncp-12 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC7787
RFC7788 Home Networking Control Protocol M. Stenberg S. Barth P. Pfister April 2016 ASCII HTML 40 IPv6 Homenet DNCP

This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address.

draft-ietf-homenet-hncp-10 RFC8375 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet http://www.rfc-editor.org/errata_search.php?rfc=7788 10.17487/RFC7788
RFC7789 Impact of BGP Filtering on Inter-Domain Routing Policies C. Cardona P. Francois P. Lucente April 2016 ASCII HTML 16 More-specific prefix Less-specific prefix Autonomous systems Traffic engineering

This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it.

draft-ietf-grow-filtering-threats-08 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7789
RFC7790 Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) Y. Yoneya T. Nemoto February 2016 ASCII HTML 10

The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both the Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers of PRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters.

draft-ietf-precis-mappings-12 INFORMATIONAL INFORMATIONAL IETF art precis 10.17487/RFC7790
RFC7791 Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2) D. Migault Editor V. Smyslov March 2016 ASCII HTML 14 MIF Load balancing Load sharing MOBIKE

This document considers a VPN end user establishing an IPsec Security Association (SA) with a Security Gateway using the Internet Key Exchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.

The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKE SA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node.

draft-mglt-ipsecme-clone-ike-sa-09 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7791
RFC7792 RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks F. Zhang X. Zhang A. Farrel O. Gonzalez de Dios D. Ceccarelli March 2016 ASCII HTML 12 Flexible-grid Flexible optical grid Optical network Optical trail Optical LSP GMPLS WDM PCE spectrum reservation flexible spectrum

This memo describes the extensions to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid.

draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7792
RFC7793 Adding 100.64.0.0/10 Prefixes to the IPv4 Locally-Served DNS Zones Registry M. Andrews May 2016 ASCII HTML 6

RFC 6598 specifies that "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure."

This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries from accidentally leaking to the global DNS infrastructure.

draft-ietf-dnsop-rfc6598-rfc6303-05 BCP0163 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC7793
RFC7794 IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability L. Ginsberg Editor B. Decraene S. Previdi X. Xu U. Chunduri March 2016 ASCII HTML 9 ISIS

This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.

draft-ietf-isis-prefix-attributes-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7794
RFC7795 Pseudowire Redundancy on the Switching Provider Edge (S-PE) J. Dong H. Wang February 2016 ASCII HTML 9

This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the Switching Provider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and 6478 is reused. This document does not require any change to the Terminating Provider Edges (T-PEs) of MS-PW.

draft-ietf-pals-redundancy-spe-03 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7795
RFC7796 Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) Y. Jiang Editor L. Yong M. Paul March 2016 ASCII HTML 26 Etree

This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation.

draft-ietf-l2vpn-vpls-pe-etree-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7796
RFC7797 JSON Web Signature (JWS) Unencoded Payload Option M. Jones February 2016 ASCII HTML 11 JavaScript Object Notation JSON JSON Object Signing and Encryption JOSE JSON Web Signature JWS Digital Signature Message Authentication Code MAC Unencoded Payload

JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.

This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.

draft-ietf-jose-jws-signing-input-options-09 RFC7519 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose 10.17487/RFC7797
RFC7798 RTP Payload Format for High Efficiency Video Coding (HEVC) Y.-K. Wang Y. Sanchez T. Schierl S. Wenger M. M. Hannuksela March 2016 ASCII HTML 86 H.265 : ISO/IEC 23008-2 Single NAL Unit Packet Aggregation Packet Fragmentation Unit Payload Content Information Packet Use of HEVC with Feedback Messages.

This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.

draft-ietf-payload-rtp-h265-15 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC7798
RFC7799 Active and Passive Metrics and Methods (with Hybrid Types In-Between) A. Morton May 2016 ASCII HTML 14 IP Performance Measurements Testing Network Characterization

This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.

draft-ietf-ippm-active-passive-06 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC7799
RFC7800 Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) M. Jones J. Bradley H. Tschofenig April 2016 ASCII HTML 15 JSON Web Token JWT Proof-of-Possession Holder-of-Key

This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key.

draft-ietf-oauth-proof-of-possession-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=7800 10.17487/RFC7800
RFC7801 GOST R 34.12-2015: Block Cipher "Kuznyechik" V. Dolmatov Editor March 2016 ASCII HTML 14 Kuznyechik Block Cipher

This document is intended to be a source of information about the Russian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (called GOST algorithms).

draft-dolmatov-kuznyechik-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7801 10.17487/RFC7801
RFC7802 A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism S. Emery N. Williams March 2016 ASCII HTML 8

This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.

This document obsoletes RFC 4402 and reclassifies that document as Historic. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations.

draft-ietf-kitten-rfc4402bis-02 RFC4402 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC7802
RFC7803 Changing the Registration Policy for the NETCONF Capability URNs Registry B. Leiba February 2016 ASCII HTML 3

The registration policy for the "Network Configuration Protocol (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs.

draft-leiba-netmod-regpolicy-update-02 RFC6241 BCP0203 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7803
RFC7804 Salted Challenge Response HTTP Authentication Mechanism A. Melnikov March 2016 ASCII HTML 18 HTTPAUTH HTTP SASL SCRAM GS2 GSSAPI GSS-API

This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.

draft-ietf-httpauth-scram-auth-15 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth http://www.rfc-editor.org/errata_search.php?rfc=7804 10.17487/RFC7804
RFC7805 Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status A. Zimmermann W. Eddy L. Eggert April 2016 ASCII HTML 8

This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013. Additionally, this document reclassifies RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status.

draft-ietf-tcpm-undeployed-03 RFC0675 RFC0721 RFC0761 RFC0813 RFC0816 RFC0879 RFC0896 RFC1078 RFC6013 RFC7414 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC7805
RFC7806 On Queuing, Marking, and Dropping F. Baker R. Pan April 2016 ASCII HTML 16

This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior.

draft-ietf-aqm-fq-implementation-05 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC7806
RFC7807 Problem Details for HTTP APIs M. Nottingham E. Wilde March 2016 ASCII HTML 16 status HTTP error problem API JSON XML

This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs.

draft-ietf-appsawg-http-problem-03 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg http://www.rfc-editor.org/errata_search.php?rfc=7807 10.17487/RFC7807
RFC7808 Time Zone Data Distribution Service M. Douglass C. Daboo March 2016 ASCII HTML 56 time zone calendaring scheduling

This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.

draft-ietf-tzdist-service-11 PROPOSED STANDARD PROPOSED STANDARD IETF art tzdist 10.17487/RFC7808
RFC7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference C. Daboo March 2016 ASCII HTML 13 CalDAV calendaring iCalendar time zone

This document defines an update to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data.

draft-ietf-tzdist-caldav-timezone-ref-05 RFC4791 PROPOSED STANDARD PROPOSED STANDARD IETF art tzdist 10.17487/RFC7809
RFC7810 IS-IS Traffic Engineering (TE) Metric Extensions S. Previdi Editor S. Giacalone D. Ward J. Drake Q. Wu May 2016 ASCII HTML 18

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.

This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.

Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.

draft-ietf-isis-te-metric-extensions-11 RFC8570 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis http://www.rfc-editor.org/errata_search.php?rfc=7810 10.17487/RFC7810
RFC7811 An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) G. Enyedi A. Csaszar A. Atlas C. Bowers A. Gopalan June 2016 ASCII HTML 118 MRT FRR LFA recovery failure routing

This document supports the solution put forth in "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)" (RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessary Maximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR.

draft-ietf-rtgwg-mrt-frr-algorithm-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7811
RFC7812 An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) A. Atlas C. Bowers G. Enyedi June 2016 ASCII HTML 44 MRT FRR LFA recovery failure routing

This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure.

draft-ietf-rtgwg-mrt-frr-architecture-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7812
RFC7813 IS-IS Path Control and Reservation J. Farkas Editor N. Bragg P. Unbehagen G. Parsons P. Ashwood-Smith C. Bowers June 2016 ASCII HTML 33 IS-IS SPB

IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.

draft-ietf-isis-pcr-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7813
RFC7814 Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution X. Xu C. Jacquenet R. Raszuk T. Boyes B. Fee March 2016 ASCII HTML 15 Data Center Interconnect Data Center Network Virtual Machine (VM) migration

This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers.

draft-ietf-bess-virtual-subnet-07 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC7814
RFC7815 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation T. Kivinen March 2016 ASCII HTML 41 IKE IPsec IoT Constrained

This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.

This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description.

draft-ietf-lwig-ikev2-minimal-05 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC7815
RFC7816 DNS Query Name Minimisation to Improve Privacy S. Bortzmeyer March 2016 ASCII HTML 11

This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.

draft-ietf-dnsop-qname-minimisation-09 EXPERIMENTAL EXPERIMENTAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7816 10.17487/RFC7816
RFC7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols A. Melnikov March 2016 ASCII HTML 13 SMTP Submission IMAP POP ManageSieve

This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, and ManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLS Command) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804.

draft-ietf-uta-email-tls-certs-09 RFC2595 RFC3207 RFC3501 RFC5804 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC7817
RFC7818 URN Namespace for MEF Documents M. Jethanandani March 2016 ASCII HTML 5

This document describes the Namespace Identifier (NID) "mef" for Uniform Resource Names (URNs) used to identify resources published by MEF Forum (https://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the MEF Assigned Names and Numbers (MANN) registry.

draft-mahesh-mef-urn-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7818
RFC7819 Privacy Considerations for DHCP S. Jiang S. Krishnan T. Mrugalski April 2016 ASCII HTML 14 DHCP Privacy

DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues.

draft-ietf-dhc-dhcp-privacy-05 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7819
RFC7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) T. Mizrahi March 2016 ASCII HTML 15 Checksum UDP IPPM timestamping

The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.

draft-ietf-ippm-checksum-trailer-06 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC7820
RFC7821 UDP Checksum Complement in the Network Time Protocol (NTP) T. Mizrahi March 2016 ASCII HTML 14 NTP UDP Checksum timestamping

The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.

draft-ietf-ntp-checksum-trailer-07 EXPERIMENTAL EXPERIMENTAL IETF int ntp 10.17487/RFC7821
RFC7822 Network Time Protocol Version 4 (NTPv4) Extension Fields T. Mizrahi D. Mayer March 2016 ASCII HTML 8 NTP extension field

The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC 5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MACs).

draft-ietf-ntp-extension-field-07 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC7822
RFC7823 Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions A. Atlas J. Drake S. Giacalone S. Previdi May 2016 ASCII HTML 10 Traffic Engineering Path Computation

In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.

draft-ietf-teas-te-express-path-05 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC7823
RFC7824 Privacy Considerations for DHCPv6 S. Krishnan T. Mrugalski S. Jiang May 2016 ASCII HTML 18

DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users. It is intended to be an analysis of the present situation and does not propose any solutions.

draft-ietf-dhc-dhcpv6-privacy-05 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7824
RFC7825 A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) J. Goldberg M. Westerlund T. Zeng December 2016 ASCII HTML 33 ICE Media Delivery RTP RTCP D-ICE AVP AVPF SAVP SAVPF setup.ice-d-m rtsp-ice-d-m SDP

This document defines a solution for Network Address Translation (NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures.

draft-ietf-mmusic-rtsp-nat-22 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7825
RFC7826 Real-Time Streaming Protocol Version 2.0 H. Schulzrinne A. Rao R. Lanphier M. Westerlund M. Stiemerling Editor December 2016 ASCII HTML 318 mmusic RTSP RTSP/2.0 real-time streaming protocol

This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.

RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).

draft-ietf-mmusic-rfc2326bis-40 RFC2326 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7826
RFC7827 The Role of the IRTF Chair L. Eggert March 2016 ASCII HTML 7

This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.

draft-iab-irtf-chair-description-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7827
RFC7828 The edns-tcp-keepalive EDNS0 Option P. Wouters J. Abley S. Dickinson R. Bellis April 2016 ASCII HTML 11 long-lived dnssec DNS TCP/IP transport

DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.

This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.

draft-ietf-dnsop-edns-tcp-keepalive-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7828
RFC7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol Y. Nishida P. Natarajan A. Caro P. Amer K. Nielsen April 2016 ASCII HTML 23 SCTP Failover multipath multihoming Potentially Failed

The Stream Control Transmission Protocol (SCTP) supports multihoming. However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed (SCTP-PF) destination state in SCTP Path Management.

This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.

Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.

The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver.

draft-ietf-tsvwg-sctp-failover-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC7829
RFC7830 The EDNS(0) Padding Option A. Mayrhofer May 2016 ASCII HTML 5 Domain Name System DNS EDNS EDNS0 Security Encryption Padding

This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.

draft-ietf-dprive-edns0-padding-03 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC7830
RFC7831 Application Bridging for Federated Access Beyond Web (ABFAB) Architecture J. Howlett S. Hartman H. Tschofenig J. Schaad May 2016 ASCII HTML 46 Federated Authentication AAA RADIUS Diameter GSS-API EAP SAML

Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common.

This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non-federated access management, including the Remote Authentication Dial-In User Service (RADIUS), the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP), and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, Relying Parties, and federations.

draft-ietf-abfab-arch-13 INFORMATIONAL INFORMATIONAL IETF sec abfab 10.17487/RFC7831
RFC7832 Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases R. Smith Editor May 2016 ASCII HTML 13 Federated Authentication AAA RADIUS Diameter GSS-API EAP SASL

Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web-based contexts. The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the Application Bridging for Federated Access Beyond web (ABFAB) architecture and specifications.

draft-ietf-abfab-usecases-05 INFORMATIONAL INFORMATIONAL IETF sec abfab 10.17487/RFC7832
RFC7833 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML) J. Howlett S. Hartman A. Perez-Mendez Editor May 2016 ASCII HTML 32 ABFAB AAA EAP RADIUS SAML

This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting (AAA) scenario, such as network access control.

draft-ietf-abfab-aaa-saml-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec abfab 10.17487/RFC7833
RFC7834 Locator/ID Separation Protocol (LISP) Impact D. Saucez L. Iannone A. Cabellos F. Coras April 2016 ASCII HTML 18

The Locator/ID Separation Protocol (LISP) aims to improve the Internet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment of LISP can have on both the routing infrastructure and the end user.

draft-ietf-lisp-impact-05 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7834
RFC7835 Locator/ID Separation Protocol (LISP) Threat Analysis D. Saucez L. Iannone O. Bonaventure April 2016 ASCII HTML 19

This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).

draft-ietf-lisp-threats-15 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7835
RFC7836 Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012 S. Smyshlyaev Editor E. Alekseev I. Oshkin V. Popov S. Leontiev V. Podobaev D. Belyavsky March 2016 ASCII HTML 32 HMAC PRF key agreement VKO key exchange key derivation KDF key tree elliptic curve Weierstrass twisted Edwards TLS IPsec IKE IKEv2

The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standards GOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.

These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions.

draft-smyshlyaev-gost-usage-19 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7836 10.17487/RFC7836
RFC7837 IPv6 Destination Option for Congestion Exposure (ConEx) S. Krishnan M. Kuehlewind B. Briscoe C. Ralli May 2016 ASCII HTML 13 Accountability Traffic Management Fairness Resource Sharing Congestion Control Quality of Service QoS Denial of Service

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.

draft-ietf-conex-destopt-12 EXPERIMENTAL EXPERIMENTAL IETF tsv conex 10.17487/RFC7837
RFC7838 HTTP Alternative Services M. Nottingham P. McManus J. Reschke April 2016 ASCII HTML 20 HTTP ALPN Alternative Services

This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.

draft-ietf-httpbis-alt-svc-14 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC7838
RFC7839 Access-Network-Identifier Option in DHCP S. Bhandari S. Gundavelli M. Grayson B. Volz J. Korhonen June 2016 ASCII HTML 20 Operator-Realm Access-Network-Identifier Access-Technology-Type Access-Point BSSID Operator-Identifier DHCPv4 DHCPv6 Local Mobility Anchor (LMA) Proxy Mobile IPv6 (PMIPv6) Service Set Identifier (SSID)

This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options.

draft-ietf-dhc-access-network-identifier-13 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7839
RFC7840 A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol J. Winterbottom H. Tschofenig L. Liess May 2016 ASCII HTML 16 Emergency Call Routing Location HELD

For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.

draft-ietf-ecrit-held-routing-05 RFC5985 RFC6881 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC7840
RFC7841 RFC Streams, Headers, and Boilerplates J. Halpern Editor L. Daigle Editor O. Kolkman Editor May 2016 ASCII HTML 14

RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.

draft-iab-rfc5741bis-02 RFC5741 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7841 10.17487/RFC7841
RFC7842 Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool R. Sparks April 2016 ASCII HTML 7

The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014. This memo captures the requirements for a set of improvements that have been identified during its initial years of community use.

draft-sparks-genarea-mailarch-improvements-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7842
RFC7843 Port Control Protocol (PCP) Third-Party ID Option A. Ripke R. Winter T. Dietz J. Quittek R. da Silva May 2016 ASCII HTML 14 PCP option third party ID

This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.

The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.

draft-ietf-pcp-third-party-id-option-08 RFC6887 PROPOSED STANDARD PROPOSED STANDARD IETF int pcp 10.17487/RFC7843
RFC7844 Anonymity Profiles for DHCP Clients C. Huitema T. Mrugalski S. Krishnan May 2016 ASCII HTML 26 DHCP DHCPv4 DHCPv6 pervasive monitoring fingerprinting privacy Anonymity MAC Address Randomization Privacy Surveillance

Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.

draft-ietf-dhc-anonymity-profile-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC7844
RFC7845 Ogg Encapsulation for the Opus Audio Codec T. Terriberry R. Lee R. Giles April 2016 ASCII HTML 35 container mapping

This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream.

draft-ietf-codec-oggopus-14 RFC5334 RFC8486 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC7845
RFC7846 Peer-to-Peer Streaming Tracker Protocol (PPSTP) R. Cruz M. Nunes J. Xia R. Huang Editor J. Taveira D. Lingli May 2016 ASCII HTML 55 structured media peer swarms control live streaming video on demand

This document specifies the base Peer-to-Peer Streaming Tracker Protocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content-streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes.

draft-ietf-ppsp-base-tracker-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ppsp 10.17487/RFC7846
RFC7847 Logical-Interface Support for IP Hosts with Multi-Access Support T. Melia Editor S. Gundavelli Editor May 2016 ASCII HTML 16 Logical-interface virtual-interface Logical interface

A logical interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support. This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features.

draft-ietf-netext-logical-interface-support-14 INFORMATIONAL INFORMATIONAL IETF int netext 10.17487/RFC7847
RFC7848 Mark and Signed Mark Objects Mapping G. Lozano June 2016 ASCII HTML 24 Trademark Clearinghouse Signed Mark Data Signed Mark Mark SMD

Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).

One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.

This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty.

draft-ietf-eppext-tmch-smd-06 PROPOSED STANDARD PROPOSED STANDARD IETF art eppext http://www.rfc-editor.org/errata_search.php?rfc=7848 10.17487/RFC7848
RFC7849 An IPv6 Profile for 3GPP Mobile Devices D. Binet M. Boucadair A. Vizdal G. Chen N. Heatley R. Chandler D. Michaud D. Lopez W. Haeffner May 2016 ASCII HTML 22 IPv4 service continuity address shortage address depletion dual-stack IPv6-only IPv6 introduction IPv6 transition IPv6 migration cellular networks mobile networks PLMN and IPv6 configuration

This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts" (RFC 7066).

Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope.

draft-ietf-v6ops-mobile-device-profile-24 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7849 10.17487/RFC7849
RFC7850 Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles S. Nandakumar April 2016 ASCII HTML 7

The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following new SDP transport protocol identifiers for transporting RTP Media over TCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF', 'TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and 'TCP/TLS/RTP/AVPF'.

draft-ietf-mmusic-proto-iana-registration-06 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic 10.17487/RFC7850
RFC7851 Peer-to-Peer (P2P) Overlay Diagnostics H. Song X. Jiang R. Even D. Bryan Y. Sun May 2016 ASCII HTML 30 Real-time Applications and Infrastructure P2PSIP Working Group Diagnostics P2P P2PSIP

This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation And Discovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics.

draft-ietf-p2psip-diagnostics-22 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC7851
RFC7852 Additional Data Related to an Emergency Call R. Gellens B. Rosen H. Tschofenig R. Marshall J. Winterbottom July 2016 ASCII HTML 113 Additional Call Data Emergency Services Call Information

When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.

The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference.

draft-ietf-ecrit-additional-data-38 RFC6443 RFC6881 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC7852
RFC7853 A URN Namespace for Globus S. Martin S. Tuecke B. McCollam M. Lidman May 2016 ASCII HTML 7

This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources.

draft-martin-urn-globus-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7853
RFC7854 BGP Monitoring Protocol (BMP) J. Scudder Editor R. Fernando S. Stuart June 2016 ASCII HTML 27 IDR BGP GROW BMP

This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.

draft-ietf-grow-bmp-17 RFC8671 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=7854 10.17487/RFC7854
RFC7855 Source Packet Routing in Networking (SPRING) Problem Statement and Requirements S. Previdi Editor C. Filsfils Editor B. Decraene S. Litkowski M. Horneffer R. Shakir May 2016 ASCII HTML 19

The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).

This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.

draft-ietf-spring-problem-statement-08 INFORMATIONAL INFORMATIONAL IETF rtg spring http://www.rfc-editor.org/errata_search.php?rfc=7855 10.17487/RFC7855
RFC7856 Softwire Mesh Management Information Base (MIB) Y. Cui J. Dong P. Wu M. Xu A. Yla-Jaaski May 2016 ASCII HTML 18 Management Information Base MIB SMIv2 mesh

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing a softwire mesh.

draft-ietf-softwire-mesh-mib-14 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7856
RFC7857 Updates to Network Address Translation (NAT) Behavioral Requirements R. Penno S. Perreault M. Boucadair Editor S. Sivakumar K. Naito April 2016 ASCII HTML 14 address sharing IPv4 service continuity Carrier Grade NAT CGN LSN NAT traversal RFC4787 RFC5382 RFC5508 DS-Lite NAT64 Address depletion

This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44).

This document updates RFCs 4787, 5382, and 5508.

draft-ietf-tsvwg-behave-requirements-update-08 RFC4787 RFC5382 RFC5508 BCP0127 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC7857
RFC7858 Specification for DNS over Transport Layer Security (TLS) Z. Hu L. Zhu J. Heidemann A. Mankin D. Wessels P. Hoffman May 2016 ASCII HTML 19 DNS encryption DNS privacy

This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.

This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.

draft-ietf-dprive-dns-over-tls-09 RFC8310 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive http://www.rfc-editor.org/errata_search.php?rfc=7858 10.17487/RFC7858
RFC7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols C. Dearlove May 2016 ASCII HTML 17 Mobile Ad hoc Networking (MANET) MANET TLV OLSRv2 integrity check value ICV ECCSI elliptic curve identity-based signature IBS identity-based encryption IBE

This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC 5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-Based Signature (IBS), defined according to the Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.

draft-ietf-manet-ibs-05 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC7859
RFC7860 HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 J. Merkle Editor M. Lochter April 2016 ASCII HTML 14 SNMP USM HMAC SHA-2

This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified.

draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-05 RFC7630 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC7860
RFC7861 Remote Procedure Call (RPC) Security Version 3 A. Adamson N. Williams November 2016 ASCII HTML 26 RPCSEC_GSS ONC RPC GSS GSS-API NFS authentication privacy confidentiality encryption mechanism context

This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updates RFC 5403.

draft-ietf-nfsv4-rpcsec-gssv3-17 RFC5403 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7861
RFC7862 Network File System (NFS) Version 4 Minor Version 2 Protocol T. Haynes November 2016 ASCII HTML 104 NFSv4.2 pNFS Server-Side Copy Server-Side Clone Labeled NFS

This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O) Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS.

draft-ietf-nfsv4-minorversion2-41 RFC8178 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7862
RFC7863 Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description T. Haynes November 2016 ASCII HTML 87 NFSv4.2 XDR

This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2.

draft-ietf-nfsv4-minorversion2-dot-x-41 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC7863
RFC7864 Proxy Mobile IPv6 Extensions to Support Flow Mobility CJ. Bernardos Editor May 2016 ASCII HTML 19 flow mobility NB-IFOM PMIPv6 FMI FMA

Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.

This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.

draft-ietf-netext-pmipv6-flowmob-18 RFC5213 PROPOSED STANDARD PROPOSED STANDARD IETF int netext 10.17487/RFC7864
RFC7865 Session Initiation Protocol (SIP) Recording Metadata R. Ravindranath P. Ravindran P. Kyzivat May 2016 ASCII HTML 34

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.

draft-ietf-siprec-metadata-22 PROPOSED STANDARD PROPOSED STANDARD IETF art siprec 10.17487/RFC7865
RFC7866 Session Recording Protocol L. Portman H. Lum Editor C. Eckel A. Johnston A. Hutton May 2016 ASCII HTML 45 siprec

This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document.

draft-ietf-siprec-protocol-18 PROPOSED STANDARD PROPOSED STANDARD IETF art siprec 10.17487/RFC7866
RFC7867 RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications R. Huang July 2016 ASCII HTML 16

This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP.

draft-ietf-xrblock-rtcp-xr-video-lc-06 PROPOSED STANDARD PROPOSED STANDARD IETF art xrblock 10.17487/RFC7867
RFC7868 Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) D. Savage J. Ng S. Moore D. Slice P. Paluch R. White May 2016 ASCII HTML 80

This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International.

draft-savage-eigrp-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7868 10.17487/RFC7868
RFC7869 The "vnc" URI Scheme D. Warden I. Iordanov May 2016 ASCII HTML 25 RFB Remote Framebuffer Virtual Network Computing

Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier (URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts.

draft-warden-appsawg-vnc-scheme-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7869
RFC7870 Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) Y. Fu S. Jiang J. Dong Y. Chen June 2016 ASCII HTML 27 IPv6

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).

draft-ietf-softwire-dslite-mib-15 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC7870
RFC7871 Client Subnet in DNS Queries C. Contavalli W. van der Gaast D. Lawrence W. Kumari May 2016 ASCII HTML 30 edns-client-subnet ECS DNS geolocation DNS load-balancing EDNS EDNS0 geolocation privacy

This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement.

draft-ietf-dnsop-edns-client-subnet-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=7871 10.17487/RFC7871
RFC7872 Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World F. Gont J. Linkova T. Chown W. Liu June 2016 ASCII HTML 15 packet drops

This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.

draft-ietf-v6ops-ipv6-ehs-in-real-world-02 INFORMATIONAL INFORMATIONAL IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=7872 10.17487/RFC7872
RFC7873 Domain Name System (DNS) Cookies D. Eastlake 3rd M. Andrews May 2016 ASCII HTML 25 denial of service forgery cache poisoning off-path

DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)

draft-ietf-dnsop-cookies-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC7873
RFC7874 WebRTC Audio Codec and Processing Requirements JM. Valin C. Bran May 2016 ASCII HTML 7

This document outlines the audio codec and processing requirements for WebRTC endpoints.

draft-ietf-rtcweb-audio-11 PROPOSED STANDARD PROPOSED STANDARD IETF art rtcweb 10.17487/RFC7874
RFC7875 Additional WebRTC Audio Codecs for Interoperability S. Proust Editor May 2016 ASCII HTML 12 WebRTC audio codec G.722 AMR AMR-WB

To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.

This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability.

draft-ietf-rtcweb-audio-codecs-for-interop-06 INFORMATIONAL INFORMATIONAL IETF art rtcweb 10.17487/RFC7875
RFC7876 UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks S. Bryant S. Sivabalan S. Soni July 2016 ASCII HTML 10 MPLS

RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path.

draft-ietf-mpls-rfc6374-udp-return-path-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC7876
RFC7877 Session Peering Provisioning Framework (SPPF) K. Cartwright V. Bhatia S. Ali D. Schwartz August 2016 ASCII HTML 57 SPPP SIP Peering SED Provisioning

This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider (SSP) data stores. The framework is called the "Session Peering Provisioning Framework" (SPPF). The provisioned data is typically used by network elements for session establishment.

draft-ietf-drinks-spp-framework-12 PROPOSED STANDARD PROPOSED STANDARD IETF art drinks 10.17487/RFC7877
RFC7878 Session Peering Provisioning (SPP) Protocol over SOAP K. Cartwright V. Bhatia J-F. Mule A. Mayrhofer August 2016 ASCII HTML 83 SPPP SIP Peering SED Provisioning

The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session Establishment Data (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol. Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an \%SPPF- based protocol.

draft-ietf-drinks-spp-protocol-over-soap-09 PROPOSED STANDARD PROPOSED STANDARD IETF art drinks 10.17487/RFC7878
RFC7879 DTLS-SRTP Handling in SIP Back-to-Back User Agents R. Ravindranath T. Reddy G. Salgueiro V. Pascual P. Ravindran May 2016 ASCII HTML 13 Session Initiation Protocol B2BUA Secure Real-time Transport Datagram Transport Layer Security

Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.

draft-ietf-straw-b2bua-dtls-srtp-12 PROPOSED STANDARD PROPOSED STANDARD IETF art straw 10.17487/RFC7879
RFC7880 Seamless Bidirectional Forwarding Detection (S-BFD) C. Pignataro D. Ward N. Akiya M. Bhatia S. Pallagatti July 2016 ASCII HTML 24 BFD seamless BFD negotiation free segment routing IP

This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

This document updates RFC 5880.

draft-ietf-bfd-seamless-base-11 RFC5880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd http://www.rfc-editor.org/errata_search.php?rfc=7880 10.17487/RFC7880
RFC7881 Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS C. Pignataro D. Ward N. Akiya July 2016 ASCII HTML 8 BFD seamless BFD negotiation free label verification segment routing IP

This document defines procedures for using Seamless Bidirectional Forwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments.

draft-ietf-bfd-seamless-ip-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC7881
RFC7882 Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases S. Aldrin C. Pignataro G. Mirsky N. Kumar July 2016 ASCII HTML 15 BFD seamless BFD negotiation free label verification segment routing IP

This document describes various use cases for Seamless Bidirectional Forwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.

These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits of S-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.

draft-ietf-bfd-seamless-use-case-08 INFORMATIONAL INFORMATIONAL IETF rtg bfd 10.17487/RFC7882
RFC7883 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS L. Ginsberg N. Akiya M. Chen July 2016 ASCII HTML 5

This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.

draft-ietf-isis-sbfd-discriminator-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7883
RFC7884 OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators C. Pignataro M. Bhatia S. Aldrin T. Ranganath July 2016 ASCII HTML 7 BFD seamless BFD negotiation free label verification segment routing IP

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3.

draft-ietf-ospf-sbfd-discriminator-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7884
RFC7885 Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) V. Govindan C. Pignataro July 2016 ASCII HTML 11 RFC5885 L2TPv3 VCCV S-BFD

This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV).

This document updates RFC 5885 by extending the CV Type values and the capability selection.

draft-ietf-pals-seamless-vccv-03 RFC5885 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7885
RFC7886 Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) V. Govindan C. Pignataro July 2016 ASCII HTML 6 S-BFD

This document defines a new Attribute-Value Pair (AVP) that allows L2TP Control Connection Endpoints (LCCEs) to advertise one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3).

draft-ietf-l2tpext-sbfd-discriminator-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2tpext 10.17487/RFC7886
RFC7887 Hierarchical Join/Prune Attributes S. Venaas J. Arango I. Kouvelas June 2016 ASCII HTML 8 multicast pim

This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message. This document updates RFC 5384 by renaming the encoding type registry specified there.

draft-ietf-pim-hierarchicaljoinattr-08 RFC5384 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC7887
RFC7888 IMAP4 Non-synchronizing Literals A. Melnikov Editor May 2016 ASCII HTML 9 IMAP LITERAL+ LITERAL- APPENDLIMIT

The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip.

This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.

This document obsoletes RFC 2088.

draft-ietf-imapapnd-rfc2088bis-04 RFC2088 PROPOSED STANDARD PROPOSED STANDARD IETF art imapapnd 10.17487/RFC7888
RFC7889 The IMAP APPENDLIMIT Extension J. SrimushnamBoovaraghamoorthy N. Bisht May 2016 ASCII HTML 7

This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large.

draft-ietf-imapapnd-appendlimit-extension-10 PROPOSED STANDARD PROPOSED STANDARD IETF art imapapnd http://www.rfc-editor.org/errata_search.php?rfc=7889 10.17487/RFC7889
RFC7890 Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) D. Bryan P. Matthews E. Shim D. Willis S. Dawkins June 2016 ASCII HTML 19 Distributed Database P2PSIP SIP Server-less DHT

This document defines concepts and terminology for using the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and the SIP usage document defined by the working group.

draft-ietf-p2psip-concepts-09 INFORMATIONAL INFORMATIONAL IETF art p2psip 10.17487/RFC7890
RFC7891 Explicit Reverse Path Forwarding (RPF) Vector J. Asghar IJ. Wijnands Editor S. Krishnaswamy A. Karan V. Arya June 2016 ASCII HTML 9 Path diversity MoFRR Maximally redundant paths

The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.

This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup.

draft-ietf-pim-explicit-rpf-vector-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC7891
RFC7892 IANA Allocation Procedures for the GMPLS OTN Signal Type Registry Z. Ali A. Bonfanti M. Hartley F. Zhang May 2016 ASCII HTML 4

IANA defined the "OTN Signal Type" subregistry of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139. This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required.

draft-ietf-ccamp-otn-signal-type-subregistry-05 RFC7139 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC7892
RFC7893 Pseudowire Congestion Considerations Y(J) Stein D. Black B. Briscoe June 2016 ASCII PDF HTML 27 pseudowire congestion TCP friendliness

Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound. Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required.

draft-ietf-pals-congcons-02 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC7893
RFC7894 Alternative Challenge Password Attributes for Enrollment over Secure Transport M. Pritikin C. Wallace June 2016 ASCII HTML 10 Enrollment over Secure Transport

This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS #9: Selected Object Classes and Attribute Types Version 2.0" (RFC 2985). Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity.

draft-wallace-est-alt-challenge-08 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7894
RFC7895 YANG Module Library A. Bierman M. Bjorklund K. Watsen June 2016 ASCII HTML 13 NETCONF RESTCONF

This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.

draft-ietf-netconf-yang-library-06 RFC8525 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC7895
RFC7896 Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) D. Dhody June 2016 ASCII HTML 5 PCEP PCE IRO

The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.

This document updates RFC 5440 regarding the IRO specification.

draft-ietf-pce-iro-update-07 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC7896
RFC7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) D. Dhody U. Palle R. Casellas June 2016 ASCII HTML 35 PCEP PCE domain subobjects

The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by Path Computation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.

draft-ietf-pce-pcep-domain-sequence-12 EXPERIMENTAL EXPERIMENTAL IETF rtg pce 10.17487/RFC7897
RFC7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) D. Dhody U. Palle V. Kondreddy R. Casellas June 2016 ASCII HTML 18 RSVP-TE domain subobjects

The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.

This document specifies new subobjects to include or exclude Autonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.

draft-ietf-teas-rsvp-te-domain-subobjects-05 EXPERIMENTAL EXPERIMENTAL IETF rtg teas 10.17487/RFC7898
RFC7899 Multicast VPN State Damping T. Morin Editor S. Litkowski K. Patel Z. Zhang R. Kebler J. Haas June 2016 ASCII HTML 18 dampening multicast vpn damping bgp pim

This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast.

draft-ietf-bess-multicast-damping-06 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7899
RFC7900 Extranet Multicast in BGP/IP MPLS VPNs Y. Rekhter Editor E. Rosen Editor R. Aggarwal Y. Cai T. Morin June 2016 ASCII HTML 65 Multicast

Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service.

draft-ietf-bess-mvpn-extranet-07 RFC6513 RFC6514 RFC6625 RFC8534 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7900
RFC7901 CHAIN Query Requests in DNS P. Wouters June 2016 ASCII HTML 16 DNSSEC EDNS0 latency

This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.

draft-ietf-dnsop-edns-chain-query-07 EXPERIMENTAL EXPERIMENTAL IETF ops dnsop 10.17487/RFC7901
RFC7902 Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags E. Rosen T. Morin June 2016 ASCII HTML 7

The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI) Tunnel" attribute. This document updates RFC 6514.

draft-ietf-bess-pta-flags-03 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7902
RFC7903 Windows Image Media Types S. Leonard September 2016 ASCII HTML 12

This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile, Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics.

draft-seantek-windows-image-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7903
RFC7904 A SIP Usage for REsource LOcation And Discovery (RELOAD) C. Jennings B. Lowekamp E. Rescorla S. Baset H. Schulzrinne T. Schmidt Editor October 2016 ASCII HTML 20 p2psip p2p sip reload peer-to-peer session initiation distributed session management overlay network SIP registrar

This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also defines Globally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged.

draft-ietf-p2psip-sip-21 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC7904
RFC7905 ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) A. Langley W. Chang N. Mavrogiannopoulos J. Strombergson S. Josefsson June 2016 ASCII HTML 8 AEAD DTLS

This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

This document updates RFCs 5246 and 6347.

draft-ietf-tls-chacha20-poly1305-04 RFC5246 RFC6347 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7905 10.17487/RFC7905
RFC7906 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes P. Timmel R. Housley S. Turner June 2016 ASCII HTML 68

This document defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.

draft-turner-km-attributes-07 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7906 10.17487/RFC7906
RFC7907 RFC7908 Problem Definition and Classification of BGP Route Leaks K. Sriram D. Montgomery D. McPherson E. Osterweil B. Dickson June 2016 ASCII HTML 11 BGP BGPSEC Route Leak Route Leak Detection Route Leak Mitigation BGP Security

A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community.

draft-ietf-grow-route-leak-problem-definition-06 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7908
RFC7909 Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures R. Kisteleki B. Haberman June 2016 ASCII HTML 14

This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on Routing Policy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects.

draft-ietf-sidr-rpsl-sig-12 RFC2622 RFC4012 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC7909
RFC7910 Interoperability between the Virtual Router Redundancy Protocol and PIM W. Zhou June 2016 ASCII HTML 6

This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with the Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. The mechanism described in this document is based on Cisco IOS software implementation.

draft-zhou-pim-vrrp-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7910
RFC7911 Advertisement of Multiple Paths in BGP D. Walton A. Retana E. Chen J. Scudder July 2016 ASCII HTML 8 border gateway protocol

This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.

draft-ietf-idr-add-paths-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7911
RFC7912 Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure A. Melnikov June 2016 ASCII HTML 11 MMHS S/MIME MIXER email

This document describes a procedure for when a Military Message Handling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more Authorizing Users authorize release of the message by adding the MMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures.

draft-melnikov-mmhs-authorizing-users-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7912
RFC7913 P-Access-Network-Info ABNF Update C. Holmberg June 2016 ASCII HTML 4 Transport PANI ABNF P-Access-Network-Info 3GPP IMS

This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list.

draft-holmberg-dispatch-pani-abnf-03 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7913
RFC7914 The scrypt Password-Based Key Derivation Function C. Percival S. Josefsson August 2016 ASCII HTML 16 PBKDF

This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.

draft-josefsson-scrypt-kdf-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7914 10.17487/RFC7914
RFC7915 IP/ICMP Translation Algorithm C. Bao X. Li F. Baker T. Anderson F. Gont June 2016 ASCII HTML 34 SIIT internet protocol control message IPv4 IPv6 Stateless IP/ICMP Translation Algorithm RFC6145bis

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145.

draft-bao-v6ops-rfc6145bis-07 RFC6145 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7915 10.17487/RFC7915
RFC7916 Operational Management of Loop-Free Alternates S. Litkowski Editor B. Decraene C. Filsfils K. Raza M. Horneffer P. Sarkar July 2016 ASCII HTML 31 IGP LFA policy FRR fast reroute network planning

Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IP Fast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.

This proposal is also applicable to remote-LFA solutions.

draft-ietf-rtgwg-lfa-manageability-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC7916
RFC7917 Advertising Node Administrative Tags in IS-IS P. Sarkar Editor H. Gredler S. Hegde S. Litkowski B. Decraene July 2016 ASCII HTML 11 IGP IS-IS Admin-Tag Traffic Engineering

This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS.

draft-ietf-isis-node-admin-tag-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7917
RFC7918 Transport Layer Security (TLS) False Start A. Langley N. Modadugu B. Moeller August 2016 ASCII HTML 11

This document specifies an optional behavior of Transport Layer Security (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip.

draft-ietf-tls-falsestart-02 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC7918
RFC7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) D. Gillmor August 2016 ASCII HTML 29 Diffie-Hellman Discrete Logarithm Finite Field Transport Layer Security TLS Negotiation

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).

draft-ietf-tls-negotiated-ff-dhe-10 RFC2246 RFC4346 RFC4492 RFC5246 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=7919 10.17487/RFC7919
RFC7920 Problem Statement for the Interface to the Routing System A. Atlas Editor T. Nadeau Editor D. Ward June 2016 ASCII HTML 12

Traditionally, routing systems have implemented routing and signaling (e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.

This document proposes meeting this need via an Interface to the Routing System (I2RS).

draft-ietf-i2rs-problem-statement-11 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7920
RFC7921 An Architecture for the Interface to the Routing System A. Atlas J. Halpern S. Hares D. Ward T. Nadeau June 2016 ASCII HTML 40

This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).

draft-ietf-i2rs-architecture-15 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7921
RFC7922 Interface to the Routing System (I2RS) Traceability: Framework and Information Model J. Clarke G. Salgueiro C. Pignataro June 2016 ASCII HTML 17 I2RS I2RS Traceability I2RS Traceability

This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes.

draft-ietf-i2rs-traceability-11 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7922
RFC7923 Requirements for Subscription to YANG Datastores E. Voit A. Clemm A. Gonzalez Prieto June 2016 ASCII HTML 18 pub/sub push updates

This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., Network Configuration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees.

draft-ietf-i2rs-pub-sub-requirements-09 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC7923
RFC7924 Transport Layer Security (TLS) Cached Information Extension S. Santesson H. Tschofenig July 2016 ASCII HTML 19 TLS Cached Information TLS Cached Info TLS Extension TLS Optimization

Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).

This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.

draft-ietf-tls-cached-info-23 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC7924
RFC7925 Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things H. Tschofenig Editor T. Fossati July 2016 ASCII HTML 61 Internet of Things Security TLS Profile DTLS Profile IoT Security DTLS over SMS

A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.

This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.

draft-ietf-dice-profile-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec dice 10.17487/RFC7925
RFC7926 Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks A. Farrel Editor J. Drake N. Bitar G. Swallow D. Ceccarelli X. Zhang July 2016 ASCII HTML 67 Abstract link Abstract node Abstraction Abstraction layer Aggregation Virtual node Virtual link

In Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.

In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.

This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.

draft-ietf-teas-interconnected-te-info-exchange-07 BCP0206 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg teas 10.17487/RFC7926
RFC7927 Information-Centric Networking (ICN) Research Challenges D. Kutscher Editor S. Eum K. Pentikousis I. Psaras D. Corujo D. Saucez T. Schmidt M. Waehlisch July 2016 ASCII HTML 38 Information centric networking

This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.

This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

draft-irtf-icnrg-challenges-06 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7927
RFC7928 Characterization Guidelines for Active Queue Management (AQM) N. Kuhn Editor P. Natarajan Editor N. Khademi Editor D. Ros July 2016 ASCII HTML 37

Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing. This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment.

draft-ietf-aqm-eval-guidelines-13 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC7928
RFC7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP P. Wouters August 2016 ASCII HTML 20 opportunistic security encrypted email

OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.

draft-ietf-dane-openpgpkey-12 EXPERIMENTAL EXPERIMENTAL IETF sec dane http://www.rfc-editor.org/errata_search.php?rfc=7929 10.17487/RFC7929
RFC7930 Larger Packets for RADIUS over TCP S. Hartman August 2016 ASCII HTML 10 ABFAB

The RADIUS-over-TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of a RADIUS packet proves problematic. This specification extends the RADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.

draft-ietf-radext-bigger-packets-07 RFC6613 EXPERIMENTAL EXPERIMENTAL IETF ops radext 10.17487/RFC7930
RFC7931 NFSv4.0 Migration: Specification Update D. Noveck Editor P. Shivam C. Lever B. Baker July 2016 ASCII HTML 55

The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC 7530.

draft-ietf-nfsv4-rfc3530-migration-update-08 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=7931 10.17487/RFC7931
RFC7932 Brotli Compressed Data Format J. Alakuijala Z. Szabadka July 2016 ASCII HTML 128

This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.

draft-alakuijala-brotli-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7932 10.17487/RFC7932
RFC7933 Adaptive Video Streaming over Information-Centric Networking (ICN) C. Westphal Editor S. Lederer D. Posch C. Timmerer A. Azgin W. Liu C. Mueller A. Detti D. Corujo J. Wang M. Montpetit N. Murray August 2016 ASCII HTML 40 ICN CCN NDN DASH adaptive video streaming scalable video streaming IPTV P2P DRM

This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.

draft-irtf-icnrg-videostreaming-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7933
RFC7934 Host Address Availability Recommendations L. Colitti V. Cerf S. Cheshire D. Schinazi July 2016 ASCII HTML 15 IPv6 IPv4 SLAAC DHCPv6 Prefix Delegation NAT NAT64 464XLAT /64 Address Assignment Addressing

This document recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it describes the benefits of and the options for doing so.

draft-ietf-v6ops-host-addr-availability-07 BCP0204 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops v6ops http://www.rfc-editor.org/errata_search.php?rfc=7934 10.17487/RFC7934
RFC7935 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure G. Huston G. Michaelson Editor August 2016 ASCII HTML 9

This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures.

draft-ietf-sidr-rfc6485bis-05 RFC6485 RFC8208 RFC8608 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=7935 10.17487/RFC7935
RFC7936 Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry T. Hardie July 2016 ASCII HTML 3

This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455.

draft-hardie-rfc6455-iana-clarification-03 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7936
RFC7937 Content Distribution Network Interconnection (CDNI) Logging Interface F. Le Faucheur Editor G. Bertrand Editor I. Oprescu Editor R. Peterkofsky August 2016 ASCII HTML 63 CDNI Logging CDN Interconnection

This memo specifies the Logging interface between a downstream Content Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.

draft-ietf-cdni-logging-27 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC7937
RFC7938 Use of BGP for Routing in Large-Scale Data Centers P. Lapukhov A. Premji J. Mitchell Editor August 2016 ASCII HTML 35 BGP ECMP Clos

Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry.

draft-ietf-rtgwg-bgp-routing-large-dc-11 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg http://www.rfc-editor.org/errata_search.php?rfc=7938 10.17487/RFC7938
RFC7939 Definition of Managed Objects for the Neighborhood Discovery Protocol U. Herberg R. Cole I. Chakeres T. Clausen August 2016 ASCII HTML 72 Network Management Management Information Base MIB SMIv2 Routing Neighbor Discovery MANET NHDP-MIB

This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC 7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery.

draft-ietf-manet-rfc6779bis-07 RFC6779 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC7939
RFC7940 Representing Label Generation Rulesets Using XML K. Davies A. Freytag August 2016 ASCII HTML 82 IDN LGR IDN table variant table

This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.

draft-ietf-lager-specification-13 PROPOSED STANDARD PROPOSED STANDARD IETF art lager http://www.rfc-editor.org/errata_search.php?rfc=7940 10.17487/RFC7940
RFC7941 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items M. Westerlund B. Burman R. Even M. Zanaty August 2016 ASCII HTML 17

Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.

draft-ietf-avtext-sdes-hdr-ext-07 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC7941
RFC7942 Improving Awareness of Running Code: The Implementation Status Section Y. Sheffer A. Farrel July 2016 ASCII HTML 8

This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

draft-sheffer-rfc6982bis-03 RFC6982 BCP0205 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7942
RFC7943 A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) F. Gont W. Liu September 2016 ASCII HTML 10 security privacy resiliency attack scanning tracking

This document describes a method for selecting IPv6 Interface Identifiers that can be employed by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless Address Autoconfiguration.

draft-gont-dhcpv6-stable-privacy-addresses-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7943
RFC7944 Diameter Routing Message Priority S. Donovan August 2016 ASCII HTML 18 Diameter Overload

When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information, Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions.

draft-ietf-dime-drmp-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC7944
RFC7945 Information-Centric Networking: Evaluation and Security Considerations K. Pentikousis Editor B. Ohlman E. Davies S. Spirou G. Boggia September 2016 ASCII HTML 38

This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.

draft-irtf-icnrg-evaluation-methodology-05 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7945
RFC7946 The GeoJSON Format H. Butler M. Daly A. Doyle S. Gillies S. Hagen T. Schaub August 2016 ASCII HTML 28 JSON Geospatial JavaScript Object Notation

GeoJSON is a geospatial data interchange format based on JavaScript Object Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents. GeoJSON uses a geographic coordinate reference system, World Geodetic System 1984, and units of decimal degrees.

draft-ietf-geojson-04 PROPOSED STANDARD PROPOSED STANDARD IETF art geojson http://www.rfc-editor.org/errata_search.php?rfc=7946 10.17487/RFC7946
RFC7947 Internet Exchange BGP Route Server E. Jasinska N. Hilliard R. Raszuk N. Bakker September 2016 ASCII HTML 12 IDR

This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.

draft-ietf-idr-ix-bgp-route-server-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7947
RFC7948 Internet Exchange BGP Route Server Operations N. Hilliard E. Jasinska R. Raszuk N. Bakker September 2016 ASCII HTML 15 GROW

The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP (EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants.

Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.

This document describes operational considerations for multilateral interconnections at IXPs.

draft-ietf-grow-ix-bgp-route-server-operations-05 INFORMATIONAL INFORMATIONAL IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=7948 10.17487/RFC7948
RFC7949 OSPFv3 over IPv4 for IPv6 Transition I. Chen A. Lindem R. Atkinson August 2016 ASCII HTML 11 IPv4 transport OSPFv3 transition

This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.

draft-ietf-ospf-transition-to-ospfv3-12 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC7949
RFC7950 The YANG 1.1 Data Modeling Language M. Bjorklund Editor August 2016 ASCII HTML 217 NETCONF XML data modeling

YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).

draft-ietf-netmod-rfc6020bis-14 RFC8342 RFC8526 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=7950 10.17487/RFC7950
RFC7951 JSON Encoding of Data Modeled with YANG L. Lhotka August 2016 ASCII HTML 20 I-JSON RESTCONF

This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.

draft-ietf-netmod-yang-json-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7951
RFC7952 Defining and Using Metadata with YANG L. Lhotka August 2016 ASCII HTML 21 metadata annotations YANG extension

This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifies XML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes.

draft-ietf-netmod-yang-metadata-07 RFC6110 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC7952
RFC7953 Calendar Availability C. Daboo M. Douglass August 2016 ASCII HTML 24 availability calendaring free-busy iCalendar CalDAV

This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendar Transport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.

This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time.

draft-ietf-calext-availability-04 RFC4791 RFC5545 RFC6638 PROPOSED STANDARD PROPOSED STANDARD IETF art calext http://www.rfc-editor.org/errata_search.php?rfc=7953 10.17487/RFC7953
RFC7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone D. Lewis D. Meyer V. Fuller September 2016 ASCII HTML 12

This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.

draft-ietf-lisp-eid-block-13 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC7954
RFC7955 Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block L. Iannone R. Jorgensen D. Conrad G. Huston September 2016 ASCII HTML 10

This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.

draft-ietf-lisp-eid-block-mgmnt-07 INFORMATIONAL INFORMATIONAL IETF rtg lisp 10.17487/RFC7955
RFC7956 Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway W. Hao Y. Li A. Qu M. Durrani P. Sivamurugan September 2016 ASCII HTML 28 tenant data center

The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues:

1. Sub-optimum forwarding paths for inter-subnet traffic.

2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.

3. A traffic bottleneck at the gateway.

This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.

draft-ietf-trill-irb-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7956
RFC7957 DISPATCH-Style Working Groups and the SIP Change Process B. Campbell Editor A. Cooper B. Leiba August 2016 ASCII HTML 6 dispatch RAI ART sip-change

RFC 5727 defined several processes for the former Real-time Applications and Infrastructure (RAI) area. These processes include the evolution of the Session Initiation Protocol (SIP) and related protocols, as well as the operation of the DISPATCH and SIPCORE working groups. This document updates RFC 5727 to allow flexibility for the area and working group structure, while preserving the SIP change processes. It also generalizes the DISPATCH working group processes so that they can be easily adopted by other working groups.

draft-campbell-art-rfc5727-update-03 RFC5727 BCP0067 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC7957
RFC7958 DNSSEC Trust Anchor Publication for the Root Zone J. Abley J. Schlyter G. Bailey P. Hoffman August 2016 ASCII HTML 14 DNS ICANN IANA KSK

The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).

In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.

draft-jabley-dnssec-trust-anchor-16 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=7958 10.17487/RFC7958
RFC7959 Block-Wise Transfers in the Constrained Application Protocol (CoAP) C. Bormann Z. Shelby Editor August 2016 ASCII HTML 37 CoAP Constrained Application Protocol REST Internet of Things IoT Smart Object Embedded Internet Constrained Node

The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.

Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.

A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.

draft-ietf-core-block-21 RFC7252 RFC8323 PROPOSED STANDARD PROPOSED STANDARD IETF art core http://www.rfc-editor.org/errata_search.php?rfc=7959 10.17487/RFC7959
RFC7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows F. Martin Editor E. Lear Editor T. Draegen. Ed. E. Zwicky Editor K. Andersen Editor September 2016 ASCII HTML 27 DMARC SMTP DKIM SPF

Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients. Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them.

draft-ietf-dmarc-interoperability-18 INFORMATIONAL INFORMATIONAL IETF art dmarc 10.17487/RFC7960
RFC7961 Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV D. Eastlake 3rd L. Yizhou August 2016 ASCII HTML 24 reachability AFN template

This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses.

draft-ietf-trill-ia-appsubtlv-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7961
RFC7962 Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures J. Saldana Editor A. Arcia-Moret B. Braem E. Pietrosemoli A. Sathiaseelan M. Zennaro August 2016 ASCII HTML 43 alternative network deployments community networks user-centric networks Wireless Internet Service Providers mainstream network gaia global access to the Internet for all

This document presents a taxonomy of a set of "Alternative Network Deployments" that emerged in the last decade with the aim of bringing Internet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives. They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.

The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.

The classification considers models such as Community Networks, Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives.

draft-irtf-gaia-alternative-network-deployments-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC7962
RFC7963 RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) Z. Ali A. Bonfanti M. Hartley F. Zhang August 2016 ASCII HTML 5 GMPLS

RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2). This document defines new Signal Types for these additional containers.

draft-ietf-ccamp-additional-signal-type-g709v3-04 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC7963
RFC7964 Solutions for BGP Persistent Route Oscillation D. Walton A. Retana E. Chen J. Scudder September 2016 ASCII HTML 9 BGP churn oscillation

Routing information reduction by BGP Route Reflection or Confederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies. This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network.

draft-ietf-idr-route-oscillation-stop-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC7964
RFC7965 LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels M. Chen W. Cao A. Takacs P. Pan August 2016 ASCII HTML 16

Many transport services require that user traffic, in the form of Pseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to the Label Distribution Protocol (LDP) that enables the binding between PWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs.

draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC7965
RFC7966 Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements H. Tschofenig J. Korhonen Editor G. Zorn K. Pillay September 2016 ASCII HTML 11 Diameter End-to-End Security

This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).

draft-ietf-dime-e2e-sec-req-05 INFORMATIONAL INFORMATIONAL IETF ops dime 10.17487/RFC7966
RFC7967 Constrained Application Protocol (CoAP) Option for No Server Response A. Bhattacharyya S. Bandyopadhyay A. Pal T. Bose August 2016 ASCII HTML 18 No-Response

There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.

This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.

draft-tcs-coap-no-response-option-17 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7967
RFC7968 Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data Y. Li D. Eastlake 3rd W. Hao H. Chen S. Chatterjee August 2016 ASCII HTML 22 VLAN fine-grained label multicast

TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.

This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.

draft-ietf-trill-tree-selection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7968
RFC7969 Customizing DHCP Configuration on the Basis of Network Topology T. Lemon T. Mrugalski October 2016 ASCII HTML 20 dhcpv4 dhcpv6 relay-agents (relay agents) multiple subnets subnets links prefixes

DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.

draft-ietf-dhc-topo-conf-09 INFORMATIONAL INFORMATIONAL IETF int dhc 10.17487/RFC7969
RFC7970 The Incident Object Description Exchange Format Version 2 R. Danyliw November 2016 ASCII HTML 172 incident data format incident report cyber threat indicators computer security incident computer security incident response team CSIRT CERT security data sharing Computer Network Defense Service Provider CNDSP information sharing automated information sharing cyber indicators

The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletes RFCs 5070 and 6685.

draft-ietf-mile-rfc5070-bis-26 RFC5070 RFC6685 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile http://www.rfc-editor.org/errata_search.php?rfc=7970 10.17487/RFC7970
RFC7971 Application-Layer Traffic Optimization (ALTO) Deployment Considerations M. Stiemerling S. Kiesel M. Scharf H. Seidel S. Previdi October 2016 ASCII HTML 77

Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information.

draft-ietf-alto-deployments-16 INFORMATIONAL INFORMATIONAL IETF tsv alto 10.17487/RFC7971
RFC7972 Entertainment Identifier Registry (EIDR) URN Namespace Definition P. Lemieux September 2016 ASCII HTML 10 EIDR Entertainment Identifier Registry and URN

Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for EIDR Identifiers.

This document obsoletes RFC 7302.

draft-pal-eidr-urn-2016-03 RFC7302 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC7972
RFC7973 Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation R. Droms P. Duffy November 2016 ASCII HTML 5 6lowpan header compression ethertype

When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment.

draft-ietf-6lo-ethertype-request-01 INFORMATIONAL INFORMATIONAL IETF int 6lo 10.17487/RFC7973
RFC7974 An Experimental TCP Option for Host Identification B. Williams M. Boucadair D. Wing October 2016 ASCII HTML 20 Policy enforcement Address sharing NAT Host reveal Host-ID

Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.

draft-williams-exp-tcp-host-id-opt-08 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC7974
RFC7975 Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection B. Niven-Jenkins Editor R. van Brandenburg Editor October 2016 ASCII HTML 35 HTTP DNS

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.

draft-ietf-cdni-redirection-20 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC7975
RFC7976 Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses C. Holmberg N. Biondic G. Salgueiro September 2016 ASCII HTML 8 P- 3GPP IMS

The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315. This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.

This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315.

draft-holmberg-dispatch-rfc7315-updates-09 RFC7315 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=7976 10.17487/RFC7976
RFC7977 The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) P. Dunkley G. Llewellyn V. Pascual G. Salgueiro R. Ravindranath September 2016 ASCII HTML 28 MSRP WebSocket

The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFCs 4975 and 4976.

draft-pd-dispatch-msrp-websocket-15 RFC4975 RFC4976 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC7977
RFC7978 Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension D. Eastlake 3rd M. Umair Y. Li September 2016 ASCII HTML 25 tunnel encapsulation

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages between TRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link. This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178.

draft-ietf-trill-channel-tunnel-11 RFC7178 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC7978
RFC7979 Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries E. Lear Editor R. Housley Editor August 2016 ASCII HTML 37

The U.S. National Telecommunications and Information Administration (NTIA) solicited a request from the Internet Corporation for Assigned Names and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.

draft-ietf-ianaplan-icg-response-10 INFORMATIONAL INFORMATIONAL IETF gen ianaplan 10.17487/RFC7979
RFC7980 A Framework for Defining Network Complexity M. Behringer A. Retana R. White G. Huston October 2016 ASCII HTML 24 Complicated Fragile Self-organization Trade-off Technical Debt Dependency

Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.

This document summarizes the work of the IRTF's Network Complexity Research Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work.

draft-behringer-ncrg-complexity-framework-02 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC7980
RFC7981 IS-IS Extensions for Advertising Router Information L. Ginsberg S. Previdi M. Chen October 2016 ASCII HTML 10

This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971.

draft-ietf-isis-rfc4971bis-04 RFC4971 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7981
RFC7982 Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) P. Martinsen T. Reddy D. Wing V. Singh September 2016 ASCII HTML 10

A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.

This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.

draft-ietf-tram-stun-path-data-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC7982
RFC7983 Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) M. Petit-Huguenin G. Salgueiro September 2016 ASCII HTML 13 TLS STUN TURN TLS TURN Channel Numbers STUN Methods RFC 5764 SRTP-DTLS ZRTP

This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document.

This document updates RFC 5764.

draft-ietf-avtcore-rfc5764-mux-fixes-11 RFC5764 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC7983
RFC7984 Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network O. Johansson G. Salgueiro V. Gurbani D. Worley Editor September 2016 ASCII HTML 10 A record address family preference AAAA record DNS getaddrinfo Happy Eyeballs IPv6 address selection SIP SRV record dual-stack IPv4 IPv6

RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "Happy Eyeballs" principles to SIP.

draft-ietf-sipcore-dns-dual-stack-08 RFC3263 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC7984
RFC7985 Security Threats to Simplified Multicast Forwarding (SMF) J. Yi T. Clausen U. Herberg November 2016 ASCII HTML 15 MANET

This document analyzes security threats to Simplified Multicast Forwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.

In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).

draft-ietf-manet-smf-sec-threats-06 RFC7186 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC7985
RFC7986 New Properties for iCalendar C. Daboo October 2016 ASCII HTML 23 alarms calendaring iCalendar

This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object.

draft-ietf-calext-extensions-05 RFC5545 PROPOSED STANDARD PROPOSED STANDARD IETF art calext http://www.rfc-editor.org/errata_search.php?rfc=7986 10.17487/RFC7986
RFC7987 IS-IS Minimum Remaining Lifetime L. Ginsberg P. Wells B. Decraene T. Przygienda H. Gredler October 2016 ASCII HTML 9

Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial-of-service attack vector. This document defines a backwards-compatible solution to this problem.

draft-ietf-isis-remaining-lifetime-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC7987
RFC7988 Ingress Replication Tunnels in Multicast VPN E. Rosen Editor K. Subramanian Z. Zhang October 2016 ASCII HTML 23

RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.

draft-ietf-bess-ir-05 RFC6513 RFC6514 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC7988
RFC7989 End-to-End Session Identification in IP-Based Multimedia Communication Networks P. Jones G. Salgueiro C. Pearce P. Giralt October 2016 ASCII HTML 45 SIP Session Initiation Protocol troubleshooting Session-ID session identifier H460.27 remote parameter UUID

This document describes an end-to-end session identifier for use in IP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the Session Initiation Protocol (SIP).

This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.

This document obsoletes RFC 7329.

draft-ietf-insipid-session-id-27 RFC7329 PROPOSED STANDARD PROPOSED STANDARD IETF art insipid 10.17487/RFC7989
RFC7990 RFC Format Framework H. Flanagan December 2016 ASCII HTML 16 Format xml2rfcv3 v3

In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.

draft-iab-rfc-framework-06 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7990
RFC7991 The "xml2rfc" Version 3 Vocabulary P. Hoffman December 2016 ASCII HTML 151 v3 xml2rfcv3 format

This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.

draft-iab-xml2rfc-04 RFC7749 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7991 10.17487/RFC7991
RFC7992 HTML Format for RFCs J. Hildebrand Editor P. Hoffman December 2016 ASCII HTML 43 html css v3 xml2rfcv3 format

In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft.

draft-iab-html-rfc-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7992
RFC7993 Cascading Style Sheets (CSS) Requirements for RFCs H. Flanagan December 2016 ASCII HTML 14 v3 xml2rfcv3 format html

The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992).

draft-iab-rfc-css-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7993
RFC7994 Requirements for Plain-Text RFCs H. Flanagan December 2016 ASCII HTML 8 RFC ASCII format plain-text plain text xml2rfcv3 v3

In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition.

draft-iab-rfc-plaintext-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7994
RFC7995 PDF Format for RFCs T. Hansen Editor L. Masinter M. Hardy December 2016 ASCII HTML 22 Requests for Comment xml2rfcv3 v3 format

This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.

draft-iab-rfc-use-of-pdf-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7995
RFC7996 SVG Drawings for RFCs: SVG 1.2 RFC N. Brownlee December 2016 ASCII HTML 53 RFC v3 xml2rfcv3 format

This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams.

draft-iab-svg-rfc-02 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7996 10.17487/RFC7996
RFC7997 The Use of Non-ASCII Characters in RFCs H. Flanagan Editor December 2016 ASCII PDF HTML 15 RFC Series UTF-8 ASCII format non-ASCII v3 xml2rfcv3

In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.

This document updates RFC 7322. Please view this document in PDF form to see the full text.

draft-iab-rfc-nonascii-02 RFC7322 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=7997 10.17487/RFC7997
RFC7998 "xml2rfc" Version 3 Preparation Tool Description P. Hoffman J. Hildebrand December 2016 ASCII HTML 18 xml2rfcv3 v3 format

This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed.

draft-iab-rfcv3-preptool-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC7998
RFC7999 BLACKHOLE Community T. King C. Dietzel J. Snijders G. Doering G. Hankins October 2016 ASCII HTML 9 well-known well known RTBH Remotely Triggered Blackholing

This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named "BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.

draft-ietf-grow-blackholing-03 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC7999
RFC8000 Requirements for NFSv4 Multi-Domain Namespace Deployment A. Adamson N. Williams November 2016 ASCII HTML 17 multi-domain multi-domain-capable file system Federated File System FedFS

This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication. In most instances, the server must also support identity-mapping services.

draft-ietf-nfsv4-multi-domain-fs-reqs-11 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8000
RFC8001 RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information F. Zhang Editor O. Gonzalez de Dios Editor C. Margaria M. Hartley Z. Ali January 2017 ASCII HTML 16

This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).

draft-ietf-teas-rsvp-te-srlg-collect-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8001
RFC8002 Host Identity Protocol Certificates T. Heer S. Varjonen October 2016 ASCII HTML 13 Hip Certificate Extension

The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).

The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 7401 and obsoletes RFC 6253.

draft-ietf-hip-rfc6253-bis-09 RFC6253 RFC7401 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8002
RFC8003 Host Identity Protocol (HIP) Registration Extension J. Laganier L. Eggert October 2016 ASCII HTML 16 HIP Host Identity Protocol Host Identity Payload Registration register

This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203.

draft-ietf-hip-rfc5203-bis-11 RFC5203 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8003
RFC8004 Host Identity Protocol (HIP) Rendezvous Extension J. Laganier L. Eggert October 2016 ASCII HTML 14 HIP Host Identity Protocol Host Identity Payload Rendezvous HIP nodes HIP rendezvous server

This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP Registration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204.

draft-ietf-hip-rfc5204-bis-08 RFC5204 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8004
RFC8005 Host Identity Protocol (HIP) Domain Name System (DNS) Extension J. Laganier October 2016 ASCII HTML 18 HIP Host Identity Protocol Host Identity Payload DNS Domain Name System

This document specifies a resource record (RR) for the Domain Name System (DNS) and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its Host Identity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205.

draft-ietf-hip-rfc5205-bis-10 RFC5205 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8005
RFC8006 Content Delivery Network Interconnection (CDNI) Metadata B. Niven-Jenkins R. Murray M. Caulfield K. Ma December 2016 ASCII HTML 66 CDN cascaded CDN cascading CDNs content acquisition content delegation request delegation acquisition protocol delivery restriction delivery policy policy enforcement delivery protocol content expiration geo-fencing geofencing geo fencing geo-blocking geoblocking geo blocking footprint cache control

The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.

draft-ietf-cdni-metadata-21 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni http://www.rfc-editor.org/errata_search.php?rfc=8006 10.17487/RFC8006
RFC8007 Content Delivery Network Interconnection (CDNI) Control Interface / Triggers R. Murray B. Niven-Jenkins December 2016 ASCII HTML 49 CDN pre-position invalidate purge

This document describes the part of the Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN.

draft-ietf-cdni-control-triggers-15 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni http://www.rfc-editor.org/errata_search.php?rfc=8007 10.17487/RFC8007
RFC8008 Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics J. Seedorf J. Peterson S. Previdi R. van Brandenburg K. Ma December 2016 ASCII HTML 31 CDNI CDN Interconnect Request Routing

This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.

draft-ietf-cdni-footprint-capabilities-semantics-20 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8008
RFC8009 AES Encryption with HMAC-SHA2 for Kerberos 5 M. Jenkins M. Peck K. Burgin October 2016 ASCII HTML 19

This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity.

draft-ietf-kitten-aes-cts-hmac-sha2-11 INFORMATIONAL INFORMATIONAL IETF sec kitten 10.17487/RFC8009
RFC8010 Internet Printing Protocol/1.1: Encoding and Transport M. Sweet I. McDonald January 2017 ASCII HTML 51 IPP Printer PWG Printer Working Group

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations, attributes, and values into the Internet MIME media type called "application/ipp". It also defines the rules for transporting a message body whose Content-Type is "application/ipp" over HTTP and/or HTTPS. The IPP data model and operation semantics are described in "Internet Printing Protocol/1.1: Model and Semantics" (RFC 8011).

draft-sweet-rfc2910bis-10 RFC2910 RFC3382 STD0092 INTERNET STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8010
RFC8011 Internet Printing Protocol/1.1: Model and Semantics M. Sweet I. McDonald January 2017 ASCII HTML 221 IPP Printer PWG Printer Working Group

The Internet Printing Protocol (IPP) is an application-level protocol for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, attributes, and operations that is independent of encoding and transport. The model consists of several objects, including Printers and Jobs. Jobs optionally support multiple Documents.

IPP semantics allow End Users and Operators to query Printer capabilities; submit Print Jobs; inquire about the status of Print Jobs and Printers; and cancel, hold, and release Print Jobs. IPP semantics also allow Operators to pause and resume Jobs and Printers.

Security, internationalization, and directory issues are also addressed by the model and semantics. The IPP message encoding and transport are described in "Internet Printing Protocol/1.1: Encoding and Transport" (RFC 8010).

This document obsoletes RFCs 2911, 3381, and 3382.

draft-sweet-rfc2911bis-11 RFC2911 RFC3381 RFC3382 STD0092 INTERNET STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8011 10.17487/RFC8011
RFC8012 Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) N. Akiya G. Swallow C. Pignataro A. Malis S. Aldrin November 2016 ASCII HTML 23 MPLS LSP Ping and Entropy

Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC 4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where Label Switching Routers (LSRs) apply different load-balancing techniques. One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g., IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.

This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790.

draft-ietf-mpls-entropy-lsp-ping-05 RFC6790 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8012
RFC8013 Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB) D. Joachimpillai J. Hadi Salim February 2017 ASCII HTML 25 ForCES Inter-FE

This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class. The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification. The document focuses on Ethernet transport.

draft-ietf-forces-interfelfb-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8013 10.17487/RFC8013
RFC8014 An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) D. Black J. Hudson L. Kreeger M. Lasserre T. Narten December 2016 ASCII HTML 35

This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.

draft-ietf-nvo3-arch-08 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8014
RFC8015 RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics V. Singh C. Perkins A. Clark R. Huang November 2016 ASCII HTML 15 XRBLOCK

This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications.

draft-ietf-xrblock-independent-burst-gap-discard-03 PROPOSED STANDARD PROPOSED STANDARD IETF art xrblock 10.17487/RFC8015
RFC8016 Mobility with Traversal Using Relays around NAT (TURN) T. Reddy D. Wing P. Patil P. Martinsen November 2016 ASCII HTML 13 IP Address Mobility VoIP ICE STUN RTP TUNNEL

It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.

This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.

draft-ietf-tram-turn-mobility-09 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8016
RFC8017 PKCS #1: RSA Cryptography Specifications Version 2.2 K. Moriarty Editor B. Kaliski J. Jonsson A. Rusch November 2016 ASCII HTML 78 RSA public-key cryptosystem RSA signature scheme RSA public key RSA private key PKCS #1 v1.5 RSA-OAEP RSA-PSS Optimal Asymmetric Encryption Padding Probabilistic Signature Scheme

This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.

This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

This document also obsoletes RFC 3447.

draft-moriarty-pkcs1-03 RFC3447 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8017 10.17487/RFC8017
RFC8018 PKCS #5: Password-Based Cryptography Specification Version 2.1 K. Moriarty Editor B. Kaliski A. Rusch January 2017 ASCII HTML 40 password-based encryption password-based key derivation salt

This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.

This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.

This document also obsoletes RFC 2898.

draft-moriarty-pkcs5-v2dot1-04 RFC2898 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8018 10.17487/RFC8018
RFC8019 Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks Y. Nir V. Smyslov November 2016 ASCII HTML 32 puzzle dos ddos bitcoin

This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.

draft-ietf-ipsecme-ddos-protection-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8019
RFC8020 NXDOMAIN: There Really Is Nothing Underneath S. Bortzmeyer S. Huque November 2016 ASCII HTML 10

This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.

draft-ietf-dnsop-nxdomain-cut-05 RFC1034 RFC2308 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8020 10.17487/RFC8020
RFC8021 Generation of IPv6 Atomic Fragments Considered Harmful F. Gont W. Liu T. Anderson January 2017 ASCII HTML 12 attack DoS Extension Headers

This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460).

draft-ietf-6man-deprecate-atomfrag-generation-08 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC8021
RFC8022 A YANG Data Model for Routing Management L. Lhotka A. Lindem November 2016 ASCII HTML 64 configuration IPv6 router advertisements NETCONF RESTCONF

This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.

draft-ietf-netmod-routing-cfg-25 RFC8349 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8022
RFC8023 Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions M. Thomas A. Mankin L. Zhang November 2016 ASCII HTML 17

This document provides context and a report on the workshop on "Root Causes and Mitigation of Name Collisions", which took place in London, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions.

draft-thomas-namecollisions-workshop-report-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8023
RFC8024 Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS Y. Jiang Editor Y. Luo E. Mallette Editor Y. Shen W. Cheng November 2016 ASCII HTML 16 PON Protection

Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it.

draft-ietf-pals-mc-pon-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8024
RFC8025 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch P. Thubert Editor R. Cragie November 2016 ASCII HTML 8 LNN IOT

This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch.

draft-ietf-6lo-paging-dispatch-05 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8025
RFC8026 Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism M. Boucadair I. Farrer November 2016 ASCII HTML 11 Provisioning Softwire IPv4 over IPv6 IPv4 service continuity IPv4 address depletion MAP MAP-T MAP-E DS-Lite Lightweight 4 over 6

In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.

draft-ietf-softwire-unified-cpe-08 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8026
RFC8027 DNSSEC Roadblock Avoidance W. Hardaker O. Gudmundsson S. Krishnaswamy November 2016 ASCII HTML 19 DNSSEC Network Problems DNS

This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure. It outlines potential detection and mitigation techniques. The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.

draft-ietf-dnsop-dnssec-roadblock-avoidance-05 BCP0207 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8027 10.17487/RFC8027
RFC8028 First-Hop Router Selection by Hosts in a Multi-Prefix Network F. Baker B. Carpenter November 2016 ASCII HTML 13

This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.

draft-ietf-6man-multi-homed-host-10 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=8028 10.17487/RFC8028
RFC8029 Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures K. Kompella G. Swallow C. Pignataro Editor N. Kumar S. Aldrin M. Chen March 2017 ASCII HTML 78 MPLS echo request MPLS echo reply

This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.

This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.

draft-ietf-mpls-rfc4379bis-09 RFC4379 RFC6424 RFC6829 RFC7537 RFC1122 RFC8611 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8029 10.17487/RFC8029
RFC8030 Generic Event Delivery Using HTTP Push M. Thomson E. Damaggio B. Raymor Editor December 2016 ASCII HTML 31 HTTP HTTP2 Push WebPush

This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push.

draft-ietf-webpush-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush 10.17487/RFC8030
RFC8031 Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement Y. Nir S. Josefsson December 2016 ASCII HTML 8 Curve25519 Curve448 Goldilocks Diffie Hellman

This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2).

draft-ietf-ipsecme-safecurves-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=8031 10.17487/RFC8031
RFC8032 Edwards-Curve Digital Signature Algorithm (EdDSA) S. Josefsson I. Liusvaara January 2017 ASCII HTML 60 signature digital signature EdDSA

This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.

draft-irtf-cfrg-eddsa-08 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8032 10.17487/RFC8032
RFC8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem R. Pan P. Natarajan F. Baker G. White February 2017 ASCII HTML 30 active queue management AQM

Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.

This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value. Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.

draft-ietf-aqm-pie-10 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm http://www.rfc-editor.org/errata_search.php?rfc=8033 10.17487/RFC8033
RFC8034 Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems G. White R. Pan February 2017 ASCII HTML 17 latency access network bufferbloat

Cable modems based on Data-Over-Cable Service Interface Specifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.

draft-ietf-aqm-docsis-pie-02 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC8034
RFC8035 Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing C. Holmberg November 2016 ASCII HTML 7 RTP RTCP multiplex rtcp-mux SDP offer answer

This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.

draft-ietf-avtcore-5761-update-06 RFC5761 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8035
RFC8036 Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks N. Cam-Winget Editor J. Hui D. Popa January 2017 ASCII HTML 24 constrained environment smart meter utilities smartgrid secure smartgrid connected energy

This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.

draft-ietf-roll-applicability-ami-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll 10.17487/RFC8036
RFC8037 CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) I. Liusvaara January 2017 ASCII HTML 14 Ed25519 Ed448 X25519 X448

This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).

draft-ietf-jose-cfrg-curves-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec jose http://www.rfc-editor.org/errata_search.php?rfc=8037 10.17487/RFC8037
RFC8038 Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol P. Aitken Editor B. Claise S. B S C. McDowall J. Schoenwaelder May 2017 ASCII HTML 85 IPFIX MIB SNMP

This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.

Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.

draft-ietf-ipfix-mib-variable-export-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8038
RFC8039 Multipath Time Synchronization A. Shpiner R. Tse C. Schelp T. Mizrahi December 2016 ASCII HTML 17 NTP PTP IEEE 1588 multiple paths

Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.

draft-ietf-tictoc-multi-path-synchronization-07 EXPERIMENTAL EXPERIMENTAL IETF int tictoc 10.17487/RFC8039
RFC8040 RESTCONF Protocol A. Bierman M. Bjorklund K. Watsen January 2017 ASCII HTML 137 YANG NETCONF REST HTTP

This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).

draft-ietf-netconf-restconf-18 RFC8527 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8040 10.17487/RFC8040
RFC8041 Use Cases and Operational Experience with Multipath TCP O. Bonaventure C. Paasch G. Detal January 2017 ASCII HTML 30 TCP MPTCP Middlebox Congestion Control Path Manager Scheduler Proxy Load-Balancer Datacenter Cellular/WiFi Offload Hybrid Access Networks

This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements.

draft-ietf-mptcp-experience-07 INFORMATIONAL INFORMATIONAL IETF tsv mptcp 10.17487/RFC8041
RFC8042 OSPF Two-Part Metric Z. Zhang L. Wang A. Lindem December 2016 ASCII HTML 9 OSPF Broadcast Interface SPF metrics Radio Networks

This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.

draft-ietf-ospf-two-part-metric-10 RFC2328 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8042
RFC8043 Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space B. Sarikaya M. Boucadair January 2017 ASCII HTML 16 Neighbor Discovery Duplicate Address Detection ND Relay Agent

This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.

The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.

draft-sarikaya-6man-sadr-overview-12 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8043
RFC8044 Data Types in RADIUS A. DeKok January 2017 ASCII HTML 35

RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.

draft-ietf-radext-datatypes-08 RFC2865 RFC3162 RFC4072 RFC6158 RFC6572 RFC7268 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC8044
RFC8045 RADIUS Extensions for IP Port Configuration and Reporting D. Cheng J. Korhonen M. Boucadair S. Sivakumar January 2017 ASCII HTML 43 address sharing address continuity CGN NAT IP assignment port assignment port control port accounting port set port range IP/Port Limit Provider Wi-Fi Port forwarding Internal port External port Port mapping

This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers.

draft-ietf-radext-ip-port-radius-ext-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext http://www.rfc-editor.org/errata_search.php?rfc=8045 10.17487/RFC8045
RFC8046 Host Mobility with the Host Identity Protocol T. Henderson Editor C. Vogt J. Arkko February 2017 ASCII HTML 37 hip multihoming extensions mobility extensions locator

This document defines a mobility extension to the Host Identity Protocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts. The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047). This document obsoletes RFC 5206.

draft-ietf-hip-rfc5206-bis-14 RFC5206 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8046
RFC8047 Host Multihoming with the Host Identity Protocol T. Henderson Editor C. Vogt J. Arkko February 2017 ASCII HTML 22 hip multihoming extensions mobility extensions locator

This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility.

draft-ietf-hip-multihoming-12 PROPOSED STANDARD PROPOSED STANDARD IETF int hip 10.17487/RFC8047
RFC8048 Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence P. Saint-Andre December 2016 ASCII HTML 34 Extensible Messaging and Presence Protocol XMPP Jabber Session Initiation Protocol SIP SIMPLE presence availability

This document defines a bidirectional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248.

draft-ietf-stox-7248bis-14 RFC7248 PROPOSED STANDARD PROPOSED STANDARD IETF art stox 10.17487/RFC8048
RFC8049 YANG Data Model for L3VPN Service Delivery S. Litkowski L. Tomotaki K. Ogaki February 2017 ASCII HTML 157 YANG l3sm l3vpn service model

This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

draft-ietf-l3sm-l3vpn-service-model-19 RFC8299 PROPOSED STANDARD PROPOSED STANDARD IETF ops l3sm 10.17487/RFC8049
RFC8050 Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions C. Petrie T. King May 2017 ASCII HTML 6

This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions.

draft-ietf-grow-mrt-add-paths-03 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8050
RFC8051 Applicability of a Stateful Path Computation Element (PCE) X. Zhang Editor I. Minei Editor January 2017 ASCII HTML 24 Stateful PCE Applicability

A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.

draft-ietf-pce-stateful-pce-app-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8051
RFC8052 Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services B. Weis M. Seewald H. Falk June 2017 ASCII HTML 25

The IEC 61850 power utility automation family of standards describes methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC 62351-9 standards specify the use of the Group Domain of Interpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo defines GDOI payloads to support those security protocols.

draft-weis-gdoi-iec62351-9-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8052
RFC8053 HTTP Authentication Extensions for Interactive Clients Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku January 2017 ASCII HTML 28

This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.

draft-ietf-httpauth-extension-09 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8053
RFC8054 Network News Transfer Protocol (NNTP) Extension for Compression K. Murchison J. Elie January 2017 ASCII HTML 23 NNTP Usenet NetNews COMPRESS DEFLATE compression

This document defines an extension to the Network News Transport Protocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server.

draft-murchison-nntp-compress-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8054
RFC8055 Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm C. Holmberg Y. Jiang January 2017 ASCII HTML 13 SIP Via transit realm

This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.

draft-holmberg-dispatch-received-realm-12 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8055
RFC8056 Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping J. Gould January 2017 ASCII HTML 11

This document describes the mapping of the Extensible Provisioning Protocol (EPP) statuses with the statuses registered for use in the Registration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP.

draft-ietf-regext-epp-rdap-status-mapping-04 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8056
RFC8057 Uniform Resource Name (URN) Namespaces for Broadband Forum B. Stark D. Sinicrope W. Lupton January 2017 ASCII HTML 11 URN Broadband Forum BBF

This document describes the Namespace Identifiers (NIDs) "bbf", "broadband-forum-org", and "dslforum-org" for Uniform Resource Names (URNs) used to identify resources published by Broadband Forum (BBF). BBF specifies and manages resources that utilize these three URN identification models. Management activities for these and other resource types are handled by BBF.

draft-bbf-bbf-urn-04 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8057
RFC8058 Signaling One-Click Functionality for List Email Headers J. Levine T. Herkula January 2017 ASCII HTML 9 email mailing list

This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.

draft-levine-herkula-oneclick-10 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8058 10.17487/RFC8058
RFC8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments J. Arango S. Venaas I. Kouvelas D. Farinacci January 2017 ASCII HTML 9

This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router).

draft-ietf-pim-join-attributes-for-lisp-06 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC8059
RFC8060 LISP Canonical Address Format (LCAF) D. Farinacci D. Meyer J. Snijders February 2017 ASCII HTML 36 Locator/ID Separation Protocol

This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.

draft-ietf-lisp-lcaf-22 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8060
RFC8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality D. Farinacci B. Weis February 2017 ASCII HTML 18 lcaf

This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.

draft-ietf-lisp-crypto-10 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8061
RFC8062 Anonymity Support for Kerberos L. Zhu P. Leach S. Hartman S. Emery Editor February 2017 ASCII HTML 18

This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as Historic. RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations.

draft-ietf-kitten-rfc6112bis-03 RFC6112 RFC4120 RFC4121 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8062
RFC8063 Key Relay Mapping for the Extensible Provisioning Protocol H.W. Ribbers M.W. Groeneweg R. Gieben A.L.J. Verschuren February 2017 ASCII HTML 16 Extensible Provisioning Protocol

This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.

This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact.

draft-ietf-eppext-keyrelay-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8063
RFC8064 Recommendation on Stable IPv6 Interface Identifiers F. Gont A. Cooper D. Thaler W. Liu February 2017 ASCII HTML 9

This document changes the recommended default Interface Identifier (IID) generation scheme for cases where Stateless Address Autoconfiguration (SLAAC) is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.

draft-ietf-6man-default-iids-16 RFC2464 RFC2467 RFC2470 RFC2491 RFC2492 RFC2497 RFC2590 RFC3146 RFC3572 RFC4291 RFC4338 RFC4391 RFC5072 RFC5121 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8064
RFC8065 Privacy Considerations for IPv6 Adaptation-Layer Mechanisms D. Thaler February 2017 ASCII HTML 10

This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links.

draft-ietf-6lo-privacy-considerations-04 INFORMATIONAL INFORMATIONAL IETF int 6lo 10.17487/RFC8065
RFC8066 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines S. Chakrabarti G. Montenegro R. Droms J. Woodyatt February 2017 ASCII HTML 9

RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC 6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document.

draft-ietf-6lo-dispatch-iana-registry-07 RFC4944 RFC6282 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8066
RFC8067 Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level B. Leiba January 2017 ASCII HTML 3 downref maturity last call

RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents.

draft-leiba-3967upd-downref-03 RFC3967 BCP0097 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8067
RFC8068 Session Initiation Protocol (SIP) Recording Call Flows R. Ravindranath P. Ravindran P. Kyzivat February 2017 ASCII HTML 34 sipreq

Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS).

draft-ietf-siprec-callflows-08 INFORMATIONAL INFORMATIONAL IETF art siprec 10.17487/RFC8068
RFC8069 URN Namespace for IEEE A. Thomas February 2017 ASCII HTML 6

This document describes the Namespace Identifier (NID) 'ieee' for Uniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority.

draft-ieee-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8069
RFC8070 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension M. Short Editor S. Moore P. Miller February 2017 ASCII HTML 9

This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange.

draft-ietf-kitten-pkinit-freshness-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8070
RFC8071 NETCONF Call Home and RESTCONF Call Home K. Watsen February 2017 ASCII HTML 13 call-home

This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively.

draft-ietf-netconf-call-home-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8071
RFC8072 YANG Patch Media Type A. Bierman M. Bjorklund K. Watsen February 2017 ASCII HTML 39 RESTCONF

This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language.

draft-ietf-netconf-yang-patch-14 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8072 10.17487/RFC8072
RFC8073 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report K. Moriarty M. Ford March 2017 ASCII HTML 16

This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-carisreport-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8073
RFC8074 Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario J. Bi G. Yao J. Halpern E. Levy-Abegnoli Editor February 2017 ASCII HTML 12 SAVI-DHCP FCFS SAVI SEND SAVI

In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.

draft-ietf-savi-mix-15 PROPOSED STANDARD PROPOSED STANDARD IETF int savi 10.17487/RFC8074
RFC8075 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) A. Castellani S. Loreto A. Rahman T. Fossati E. Dijk February 2017 ASCII HTML 40 CoAP HTTP-CoAP mapping HTTP-CoAP translation proxy implementation

This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.

draft-ietf-core-http-mapping-17 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8075
RFC8076 A Usage for Shared Resources in RELOAD (ShaRe) A. Knauf T. Schmidt Editor G. Hege M. Waehlisch March 2017 ASCII HTML 22 P2PSIP SIP Conferencing Voice over IP Peer-to-Peer Access Control Group Management Rendezvous

This document defines a REsource LOcation And Discovery (RELOAD) Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required.

draft-ietf-p2psip-share-10 PROPOSED STANDARD PROPOSED STANDARD IETF art p2psip 10.17487/RFC8076
RFC8077 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) L. Martini Editor G. Heron Editor February 2017 ASCII HTML 35

Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.

This document is a rewrite of RFC 4447 for publication as an Internet Standard.

draft-ietf-pals-rfc4447bis-05 RFC4447 RFC6723 STD0084 INTERNET STANDARD INTERNET STANDARD IETF rtg pals http://www.rfc-editor.org/errata_search.php?rfc=8077 10.17487/RFC8077
RFC8078 Managing DS Records from the Parent via CDS/CDNSKEY O. Gudmundsson P. Wouters March 2017 ASCII HTML 10 dnssec trust maintenance

RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.

Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.

This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).

It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.

draft-ietf-dnsop-maintain-ds-06 RFC7344 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8078 10.17487/RFC8078
RFC8079 Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) L. Miniero S. Garcia Murillo V. Pascual February 2017 ASCII HTML 16

SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol (RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.

This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP.

draft-ietf-straw-b2bua-rtcp-17 PROPOSED STANDARD PROPOSED STANDARD IETF art straw 10.17487/RFC8079
RFC8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC O. Sury R. Edmonds February 2017 ASCII HTML 7 DNSSEC EdDSA ed25519 ed448

This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448.

draft-ietf-curdle-dnskey-eddsa-03 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8080 10.17487/RFC8080
RFC8081 The "font" Top-Level Media Type C. Lilley February 2017 ASCII HTML 18 Internet Media Types MIME

This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations.

draft-ietf-justfont-toplevel-06 PROPOSED STANDARD PROPOSED STANDARD IETF art justfont 10.17487/RFC8081
RFC8082 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs S. Wenger J. Lennox B. Burman M. Westerlund March 2017 ASCII HTML 11 Layered Codec Full Intra Request FIR Decoder Refresh Point

This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.

draft-ietf-avtext-avpf-ccm-layered-04 RFC5104 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8082
RFC8083 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions C. Perkins V. Singh March 2017 ASCII HTML 25

The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.

This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.

draft-ietf-avtcore-rtp-circuit-breakers-18 RFC3550 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8083
RFC8084 Network Transport Circuit Breakers G. Fairhurst March 2017 ASCII HTML 24 Congestion control CC UDP Tunnel Encapsulation Transport Protocol Congestion Control

This document explains what is meant by the term "network transport Circuit Breaker". It describes the need for Circuit Breakers (CBs) for network tunnels and applications when using non-congestion- controlled traffic and explains where CBs are, and are not, needed. It also defines requirements for building a CB and the expected outcomes of using a CB within the Internet.

draft-ietf-tsvwg-circuit-breaker-15 BCP0208 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC8084
RFC8085 UDP Usage Guidelines L. Eggert G. Fairhurst G. Shepherd March 2017 ASCII HTML 55 UDP guidelines

The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.

Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.

Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.

This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.

draft-ietf-tsvwg-rfc5405bis-19 RFC5405 RFC8899 BCP0145 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tsvwg 10.17487/RFC8085
RFC8086 GRE-in-UDP Encapsulation L. Yong Editor E. Crabbe X. Xu T. Herbert March 2017 ASCII HTML 27

This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.

draft-ietf-tsvwg-gre-in-udp-encap-19 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8086 10.17487/RFC8086
RFC8087 The Benefits of Using Explicit Congestion Notification (ECN) G. Fairhurst M. Welzl March 2017 ASCII HTML 19 ecn aqm sctp tcp

The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.

draft-ietf-aqm-ecn-benefits-08 INFORMATIONAL INFORMATIONAL IETF tsv aqm 10.17487/RFC8087
RFC8088 How to Write an RTP Payload Format M. Westerlund May 2017 ASCII HTML 65 RTP Payload format Process

This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions.

draft-ietf-payload-rtp-howto-14 RFC2736 INFORMATIONAL INFORMATIONAL IETF art payload 10.17487/RFC8088
RFC8089 The "file" URI Scheme M. Kerwin February 2017 ASCII HTML 19 uniform resource identifier URL

This document provides a more complete specification of the "file" Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.

It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs.

draft-ietf-appsawg-file-scheme-16 RFC1738 PROPOSED STANDARD PROPOSED STANDARD IETF art appsawg 10.17487/RFC8089
RFC8090 Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) R. Housley February 2017 ASCII HTML 7

This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names.

draft-iab-ccg-appoint-process-03 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8090
RFC8091 A Media Type Structured Syntax Suffix for JSON Text Sequences E. Wilde February 2017 ASCII HTML 5

Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+json-seq" as a structured syntax suffix for JSON text sequences.

draft-wilde-json-seq-suffix-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8091
RFC8092 BGP Large Communities Attribute J. Heitz Editor J. Snijders Editor K. Patel I. Bagdonas N. Hilliard February 2017 ASCII HTML 8 BGP large communities four-octet

This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all Autonomous System Numbers (ASNs) including four-octet ASNs.

draft-ietf-idr-large-community-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr http://www.rfc-editor.org/errata_search.php?rfc=8092 10.17487/RFC8092
RFC8093 Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 J. Snijders February 2017 ASCII HTML 3

This document requests IANA to mark BGP path attribute values 30, 31, 129, 241, 242, and 243 as "Deprecated".

draft-ietf-idr-deprecate-30-31-129-02 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8093
RFC8094 DNS over Datagram Transport Layer Security (DTLS) T. Reddy D. Wing P. Patil February 2017 ASCII HTML 13

DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.

This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.

draft-ietf-dprive-dnsodtls-15 EXPERIMENTAL EXPERIMENTAL IETF int dprive 10.17487/RFC8094
RFC8095 Services Provided by IETF Transport Protocols and Congestion Control Mechanisms G. Fairhurst Editor B. Trammell Editor M. Kuehlewind Editor March 2017 ASCII HTML 54 Transmission Control Protocol (TCP) Multipath TCP (MPTCP) Stream Control Transmission Protocol (SCTP) User Datagram Protocol (UDP) UDP-Lite Datagram Congestion Control Protocol (DCCP) Internet Control Message Protocol (ICMP) Real-Time Transport Protocol (RTP) File Delivery over Unidirectional Transport/Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast NACK-Oriented Reliable Multicast (NORM) Transport Layer Security (TLS) Datagram TLS (DTLS) Hypertext Transport Protocol (HTTP) TAPS

This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol (RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group.

draft-ietf-taps-transports-14 INFORMATIONAL INFORMATIONAL IETF tsv taps http://www.rfc-editor.org/errata_search.php?rfc=8095 10.17487/RFC8095
RFC8096 The IPv6-Specific MIB Modules Are Obsolete B. Fenner April 2017 ASCII HTML 65

In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic.

draft-ietf-6man-ipv6-mibs-obsolete-02 RFC2452 RFC2454 RFC2465 RFC2466 INFORMATIONAL INFORMATIONAL IETF int 6man 10.17487/RFC8096
RFC8097 BGP Prefix Origin Validation State Extended Community P. Mohapatra K. Patel J. Scudder D. Ward R. Bush March 2017 ASCII HTML 6

This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process.

draft-ietf-sidr-origin-validation-signaling-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8097
RFC8098 Message Disposition Notification T. Hansen Editor A. Melnikov Editor February 2017 ASCII HTML 37 delivery notification mdn

This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and are often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.

Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.

This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement).

draft-ietf-appsawg-mdn-3798bis-16 RFC3798 RFC2046 RFC3461 STD0085 INTERNET STANDARD INTERNET STANDARD IETF art appsawg 10.17487/RFC8098
RFC8099 OSPF Topology-Transparent Zone H. Chen R. Li A. Retana Y. Yang Z. Liu February 2017 ASCII HTML 27 IGP OSPF TTZ

This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ.

draft-ietf-ospf-ttz-06 EXPERIMENTAL EXPERIMENTAL IETF rtg ospf 10.17487/RFC8099
RFC8100 Diffserv-Interconnection Classes and Practice R. Geib Editor D. Black March 2017 ASCII HTML 21 Diffserv Interconnection PHB Treatment Aggregate MPLS Short Pipe

This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.

draft-ietf-tsvwg-diffserv-intercon-14 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC8100
RFC8101 IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service C. Holmberg J. Axell March 2017 ASCII HTML 6 Resource-Priority namespace Resource-priorith 3GPP IMS MCPTT

This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the 3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry.

draft-holmberg-dispatch-mcptt-rp-namespace-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8101
RFC8102 Remote-LFA Node Protection and Manageability P. Sarkar Editor S. Hegde C. Bowers H. Gredler S. Litkowski March 2017 ASCII HTML 22 LFA Remote-LFA IGP Node Protection

The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.

This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints.

draft-ietf-rtgwg-rlfa-node-protection-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8102
RFC8103 Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) R. Housley February 2017 ASCII HTML 9

This document describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator.

draft-ietf-curdle-cms-chacha20-poly1305-06 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8103 10.17487/RFC8103
RFC8104 Pseudowire (PW) Endpoint Fast Failure Protection Y. Shen R. Aggarwal W. Henderickx Y. Jiang March 2017 ASCII HTML 43 pseudowire PW protection local repair fast reroute

This document specifies a fast mechanism for protecting pseudowires (PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure.

draft-ietf-pals-endpoint-fast-protection-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8104
RFC8105 Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) P. Mariager J. Petersen Editor Z. Shelby M. Van de Logt D. Barthel May 2017 ASCII HTML 22 6LoWPAN ETSI IoT and Internet of Things

Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low-power air interface technology that is proposed by the DECT Forum and is defined and specified by ETSI.

The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.

DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.

This document describes how IPv6 is transported over DECT ULE using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques.

draft-ietf-6lo-dect-ule-09 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8105
RFC8106 IPv6 Router Advertisement Options for DNS Configuration J. Jeong S. Park L. Beloeil S. Madanapalli March 2017 ASCII HTML 19 DNS Service DNS Option Recursive DNS Server Address DNS Search List Stateless Autoconfiguration

This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.

This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.

draft-ietf-6man-rdnss-rfc6106bis-16 RFC6106 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8106
RFC8107 Advertising Digital Identifier (Ad-ID) URN Namespace Definition J. Wold March 2017 ASCII HTML 7

Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) "adid" for Ad-IDs.

draft-adid-urn-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8107
RFC8108 Sending Multiple RTP Streams in a Single RTP Session J. Lennox M. Westerlund Q. Wu C. Perkins March 2017 ASCII HTML 29

This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.

draft-ietf-avtcore-rtp-multi-stream-11 RFC3550 RFC4585 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8108
RFC8109 Initializing a DNS Resolver with Priming Queries P. Koch M. Larson P. Hoffman March 2017 ASCII HTML 7

This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers.

draft-ietf-dnsop-resolver-priming-11 BCP0209 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8109
RFC8110 Opportunistic Wireless Encryption D. Harkins Editor W. Kumari Editor March 2017 ASCII HTML 12 opportunistic encryption wireless

This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media.

draft-harkins-owe-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8110 10.17487/RFC8110
RFC8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) V. Fuller D. Lewis V. Ermagan A. Jain A. Smirnov May 2017 ASCII HTML 44 LISP DDT EID Locator Mapping System Map-Server Map-Referral Referral

This document describes the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set of LISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.

draft-ietf-lisp-ddt-09 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8111
RFC8112 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG) D. Farinacci A. Jain I. Kouvelas D. Lewis May 2017 ASCII HTML 11

A simple tool called the Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP- DDT hierarchy. This document describes how the "rig" tool works.

draft-farinacci-lisp-rig-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8112
RFC8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations M. Boucadair C. Jacquenet March 2017 ASCII HTML 6 Shared Experiment Code LISP codepoints Experiment Identifier Experiment ID LISP Experimental Registry LISP Extension Extending LISP

This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.

draft-ietf-lisp-type-iana-06 RFC6830 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8113
RFC8114 Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network M. Boucadair C. Qin C. Jacquenet Y. Lee Q. Wang March 2017 ASCII HTML 23 Multicast DS-Lite IPv4-IPv6 Interconnection PREFIX64 SSM ASM IPv4 service continuity Multicast service continuity IPv6-only IPv6-only multicast PIM MLD IGMP A+P MAP MAP-E address-sharing CGN NAT64 IPv4 over IPv6 IPv6 Address Synthesis Any-Source Multicast Source-Specific Multicast

This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).

draft-ietf-softwire-dslite-multicast-18 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8114
RFC8115 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes M. Boucadair J. Qin T. Tsou X. Deng March 2017 ASCII HTML 9 PREFIX64 SSM ASM Prefix Discovery IPv4-Converted IPv6 Addresses IPv4 service continuity IPv6 Address Synthesis Any-Source Multicast Source-Specific Multicast PIM IPv4-IPv6 interconnection IPv4 over IPv6 A+P MAP MAP-E address-sharing CGN NAT64

This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.

draft-ietf-softwire-multicast-prefix-option-15 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8115
RFC8116 Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) T. Clausen U. Herberg J. Yi May 2017 ASCII HTML 26 MANET

This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated.

draft-ietf-manet-olsrv2-sec-threats-04 INFORMATIONAL INFORMATIONAL IETF rtg manet 10.17487/RFC8116
RFC8117 Current Hostname Practice Considered Harmful C. Huitema D. Thaler R. Winter March 2017 ASCII HTML 12

Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.

There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values.

draft-ietf-intarea-hostname-practice-05 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC8117
RFC8118 The application/pdf Media Type M. Hardy L. Masinter D. Markovic D. Johnson M. Bailey March 2017 ASCII HTML 12 Portable Document Format MIME type

The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993. This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.

draft-hardy-pdf-mime-05 RFC3778 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8118
RFC8119 SIP "cause" URI Parameter for Service Number Translation M. Mohali M. Barnes March 2017 ASCII HTML 12 Cause

RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document updates RFC 4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations.

draft-mohali-dispatch-cause-for-service-number-14 RFC4458 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8119
RFC8120 Mutual Authentication Protocol for HTTP Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku April 2017 ASCII HTML 53 HTTP authentication

This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.

draft-ietf-httpauth-mutual-11 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8120
RFC8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3) Y. Oiwa H. Watanabe H. Takagi K. Maeda T. Hayashi Y. Ioku April 2017 ASCII HTML 17 HTTP authentication

This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).

draft-ietf-httpauth-mutual-algo-07 EXPERIMENTAL EXPERIMENTAL IETF sec httpauth 10.17487/RFC8121
RFC8122 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) J. Lennox C. Holmberg March 2017 ASCII HTML 18 SDP TLS Fingerprint Offer Answer

This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.

This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.

draft-ietf-mmusic-4572-update-13 RFC4572 PROPOSED STANDARD PROPOSED STANDARD IETF art mmusic http://www.rfc-editor.org/errata_search.php?rfc=8122 10.17487/RFC8122
RFC8123 Requirements for Marking SIP Messages to be Logged P. Dawes C. Arunachalam March 2017 ASCII HTML 11 logme troubleshooting debug logging

SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.

This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks.

draft-ietf-insipid-logme-reqs-12 INFORMATIONAL INFORMATIONAL IETF art insipid 10.17487/RFC8123
RFC8124 The Session Description Protocol (SDP) WebSocket Connection URI Attribute R. Ravindranath G. Salgueiro March 2017 ASCII HTML 12 Secure WebSocket Uniform Resource Identifier

The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.

draft-ietf-bfcpbis-sdp-ws-uri-09 PROPOSED STANDARD PROPOSED STANDARD IETF art bfcpbis 10.17487/RFC8124
RFC8125 Requirements for Password-Authenticated Key Agreement (PAKE) Schemes J. Schmidt April 2017 ASCII HTML 10 Password Key Agreement Password-Authenticated Key Agreement Cryptographic Protocol

Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password. This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group (CFRG).

draft-irtf-cfrg-pake-reqs-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8125
RFC8126 Guidelines for Writing an IANA Considerations Section in RFCs M. Cotton B. Leiba T. Narten June 2017 ASCII HTML 47 internet assigned numbers authority values implementations code point protocol constant protocol parameter codepoint

Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).

To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.

This is the third edition of this document; it obsoletes RFC 5226.

draft-leiba-cotton-iana-5226bis-20 RFC5226 BCP0026 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8126 10.17487/RFC8126
RFC8127 Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor D. Patki S. Gundavelli J. Lee Q. Fu L. Bertz August 2017 ASCII HTML 14 Binding Refresh Heartbeat

This specification defines a new extension, LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters.

draft-ietf-dmm-lma-controlled-mag-params-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8127
RFC8128 IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee C. Morgan March 2017 ASCII HTML 5

This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).

draft-iab-rzerc-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8128
RFC8129 Authentication Indicator in Kerberos Tickets A. Jain N. Kinder N. McCallum March 2017 ASCII HTML 6

This document updates RFC 4120, as it specifies an extension in the Kerberos protocol. It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.

draft-ietf-kitten-krb-auth-indicator-07 RFC4120 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8129
RFC8130 RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec V. Demjanenko D. Satterlee March 2017 ASCII HTML 30 MELP MELPe MELP2400 MELP1200 MELP600 SCIP-210 SCIP210

This document describes the RTP payload format for the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail.

draft-ietf-payload-melpe-06 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8130
RFC8131 RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing X. Zhang H. Zheng Editor R. Gandhi Editor Z. Ali P. Brzozowski March 2017 ASCII HTML 15 Association Object LSP Reversion LSP Recovery GMPLS Make-Before-Break GMPLS 1+R GMPLS 1+1+R

In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.

This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.

draft-ietf-teas-gmpls-resource-sharing-proc-08 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8131
RFC8132 PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) P. van der Stok C. Bormann A. Sehgal April 2017 ASCII HTML 21 CoAP

The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.

This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.

draft-ietf-core-etch-04 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8132
RFC8133 The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol S. Smyshlyaev. Ed. E. Alekseev I. Oshkin V. Popov March 2017 ASCII HTML 51 cryptography secure channel elliptic curve

This document describes the Security Evaluated Standardized Password- Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information. The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects.

draft-smyshlyaev-sespake-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8133
RFC8134 Management Incident Lightweight Exchange (MILE) Implementation Report C. Inacio D. Miyamoto May 2017 ASCII HTML 16 IODEF RID SCI INCH MILE Implementation

This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups.

draft-ietf-mile-implementreport-10 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC8134
RFC8135 Complex Addressing in IPv6 M. Danielson M. Nilsson April 1 2017 ASCII HTML 16

The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.

draft-danielson-complexaddress-latest-00 EXPERIMENTAL EXPERIMENTAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8135 10.17487/RFC8135
RFC8136 Additional Transition Functionality for IPv6 B. Carpenter R. Hinden April 1 2017 ASCII HTML 7

This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.

draft-carpenter-addtransfunc-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8136
RFC8137 IEEE 802.15.4 Information Element for the IETF T. Kivinen P. Kinney May 2017 ASCII HTML 7 IE

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.

draft-kivinen-802-15-ie-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8137
RFC8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header P. Thubert Editor C. Bormann L. Toutain R. Cragie April 2017 ASCII HTML 37

This specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.

draft-ietf-roll-routing-dispatch-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg roll http://www.rfc-editor.org/errata_search.php?rfc=8138 10.17487/RFC8138
RFC8139 Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders D. Eastlake 3rd Y. Li M. Umair A. Banerjee F. Hu June 2017 ASCII HTML 41 DRB VLAN mapping inhibition port shutdown trill TRansparent Interconnection of Lots of Links

TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439.

draft-ietf-trill-rfc6439bis-05 RFC6439 RFC6325 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8139
RFC8140 The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character A. Farrel April 1 2017 ASCII HTML 16

Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.

Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".

This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.

draft-farrel-ascii-art-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8140 10.17487/RFC8140
RFC8141 Uniform Resource Names (URNs) P. Saint-Andre J. Klensin April 2017 ASCII HTML 40 Uniform Resource Name URN Uniform Resource Identifier URI

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.

draft-ietf-urnbis-rfc2141bis-urn-22 RFC2141 RFC3406 PROPOSED STANDARD PROPOSED STANDARD IETF art urnbis 10.17487/RFC8141
RFC8142 GeoJSON Text Sequences S. Gillies April 2017 ASCII HTML 5 JSON Geospatial JavaScript Object Notation

This document describes the GeoJSON text sequence format and "application/geo+json-seq" media type. This format is based on JavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence.

draft-ietf-geojson-text-sequence-05 PROPOSED STANDARD PROPOSED STANDARD IETF art geojson 10.17487/RFC8142
RFC8143 Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) J. Elie April 2017 ASCII HTML 13 NNTP Usenet NetNews TLS STARTTLS

This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642.

draft-elie-nntp-tls-recommendations-05 RFC4642 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8143
RFC8144 Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) K. Murchison April 2017 ASCII HTML 28 http prefer webav caldav

This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference.

draft-murchison-webdav-prefer-14 RFC7240 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8144
RFC8145 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) D. Wessels W. Kumari P. Hoffman April 2017 ASCII HTML 13 DNS DNSSEC Trust Anchor

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.

draft-ietf-dnsop-edns-key-tag-05 RFC8553 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8145
RFC8146 Adding Support for Salted Password Databases to EAP-pwd D. Harkins April 2017 ASCII HTML 11 Password-Authenticated Key Exchange PAKE Dictionary Attack Authentication EAP

EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd.

draft-harkins-salted-eap-pwd-08 RFC5931 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8146 10.17487/RFC8146
RFC8147 Next-Generation Pan-European eCall R. Gellens H. Tschofenig May 2017 ASCII HTML 43 emergency call calls emergency call emergency calls vehicle acn aacn automatic crash notification automatic collision notification advanced automatic crash notification advanced automatic collision notification crash vehicle-initiated

This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in-vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.

This document also registers MIME media types and an Emergency Call Data Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.

Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions.

draft-ietf-ecrit-ecall-27 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8147
RFC8148 Next-Generation Vehicle-Initiated Emergency Calls R. Gellens B. Rosen H. Tschofenig May 2017 ASCII HTML 40 emergency call calls emergency call emergency calls vehicle acn aacn automatic crash notification automatic collision notification advanced automatic crash notification advanced automatic collision notification crash vehicle-initiated ecall

This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.

This document also registers a MIME media type and Emergency Call Data Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.

This document reuses the technical aspects of next-generation Pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions). However, this document specifies use of a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context.

draft-ietf-ecrit-car-crash-23 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8148
RFC8149 RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) T. Saad Editor R. Gandhi Editor Z. Ali R. Venator Y. Kamite April 2017 ASCII HTML 17 RSVP fragmentation RSVP fragment identifier P2MP-TE tree reoptimization P2MP-TE tree re-evaluation Preferable P2MP-TE tree Inter-domain P2MP-TE

The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.

draft-ietf-teas-p2mp-loose-path-reopt-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8149
RFC8150 MPLS Transport Profile Linear Protection MIB S. Kingston Smiler M. Venkatesan D. King S. Aldrin J. Ryoo April 2017 ASCII HTML 48 Network Management Management Information Base MIB SMIv2

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing Multiprotocol Label Switching - Transport Profile (MPLS-TP) linear protection.

draft-ietf-mpls-tp-linear-protection-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8150
RFC8151 Use Cases for Data Center Network Virtualization Overlay Networks L. Yong L. Dunbar M. Toy A. Isaac V. Manral May 2017 ASCII HTML 16

This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications.

draft-ietf-nvo3-use-case-17 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8151
RFC8152 CBOR Object Signing and Encryption (COSE) J. Schaad July 2017 ASCII HTML 121 CoAP ECC Elliptic Curve

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.

draft-ietf-cose-msg-24 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose http://www.rfc-editor.org/errata_search.php?rfc=8152 10.17487/RFC8152
RFC8153 Digital Preservation Considerations for the RFC Series H. Flanagan April 2017 ASCII HTML 18 archive archiving

The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice.

draft-iab-rfc-preservation-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8153
RFC8154 Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout C. Hellwig May 2017 ASCII HTML 30 NFSv4

The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices.

draft-ietf-nfsv4-scsi-layout-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8154
RFC8155 Traversal Using Relays around NAT (TURN) Server Auto Discovery P. Patil T. Reddy D. Wing April 2017 ASCII HTML 16

Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.

This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.

draft-ietf-tram-turn-server-discovery-12 RFC5766 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8155
RFC8156 DHCPv6 Failover Protocol T. Mrugalski K. Kinnear June 2017 ASCII HTML 96 DHCPv6 Failover

DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031).

draft-ietf-dhc-dhcpv6-failover-protocol-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8156
RFC8157 Huawei's GRE Tunnel Bonding Protocol N. Leymann C. Heidemann M. Zhang B. Sarikaya M. Cullen May 2017 ASCII HTML 44 Hybrid Access Bandwidth Aggregation Bonding Tunnel GRE Channel Hybrid Access Aggregation Point Home Gateway

There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.

In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.

draft-zhang-gre-tunnel-bonding-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8157
RFC8158 IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events S. Sivakumar R. Penno December 2017 ASCII HTML 34 template

Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events.

draft-ietf-behave-ipfix-nat-logging-13 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8158
RFC8159 Keyed IPv6 Tunnel M. Konstantynowicz Editor G. Heron Editor R. Schatzmayr W. Henderickx May 2017 ASCII HTML 12 L2TPv3 pseudowire

This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.

draft-ietf-l2tpext-keyed-ipv6-tunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg l2tpext 10.17487/RFC8159
RFC8160 IUTF8 Terminal Mode in Secure Shell (SSH) S. Tatham D. Tucker April 2017 ASCII HTML 4 Secure Shell SSH

This document specifies a new opcode in the Secure Shell terminal modes encoding. The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding.

draft-sgtatham-secsh-iutf8-06 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8160
RFC8161 Benchmarking the Neighbor Discovery Protocol W. Cerveny R. Bonica R. Thomas May 2017 ASCII HTML 17 IPv6 Scaling NDP

This document provides benchmarking procedures for the Neighbor Discovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.

draft-ietf-bmwg-ipv6-nd-06 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8161
RFC8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME P. Hoffman J. Schlyter May 2017 ASCII HTML 11

This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.

draft-ietf-dane-smime-16 EXPERIMENTAL EXPERIMENTAL IETF sec dane 10.17487/RFC8162
RFC8163 Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks K. Lynn Editor J. Martocci C. Neilson S. Donaldson May 2017 ASCII HTML 27

Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.

draft-ietf-6lo-6lobac-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo http://www.rfc-editor.org/errata_search.php?rfc=8163 10.17487/RFC8163
RFC8164 Opportunistic Security for HTTP/2 M. Nottingham M. Thomson May 2017 ASCII HTML 10 Opportunistic Security HTTP

This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.

draft-ietf-httpbis-http2-encryption-11 EXPERIMENTAL EXPERIMENTAL IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8164 10.17487/RFC8164
RFC8165 Design Considerations for Metadata Insertion T. Hardie May 2017 ASCII HTML 7 surveillance proxy proxying middlebox

The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata.

draft-hardie-privsec-metadata-insertion-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8165
RFC8166 Remote Direct Memory Access Transport for Remote Procedure Call Version 1 C. Lever Editor W. Simpson T. Talpey June 2017 ASCII HTML 55 RPC-over-RDMA

This document specifies a protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA). This protocol is referred to as the RPC-over- RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666.

draft-ietf-nfsv4-rfc5666bis-11 RFC5666 RFC8797 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8166
RFC8167 Bidirectional Remote Procedure Call on RPC-over-RDMA Transports C. Lever June 2017 ASCII HTML 13 NFS-over-RDMA RPC-over-RDMA

Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection. This document describes how RPC transport endpoints capable of Remote Direct Memory Access (RDMA) convey RPCs in both directions on a single connection.

draft-ietf-nfsv4-rpcrdma-bidirection-08 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8167
RFC8168 DHCPv6 Prefix-Length Hint Issues T. Li C. Liu Y. Cui May 2017 ASCII HTML 9 DHCPv6 Dynamic Host Configuration Protocol IPv6 Prefix Prefix Delegation Prefix Length Hint Address Allocation

DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.

draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-06 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8168
RFC8169 Residence Time Measurement in MPLS Networks G. Mirsky S. Ruffini E. Gray J. Drake S. Bryant A. Vainshtein May 2017 ASCII HTML 30 G-ACh Resident Time MPLS

This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.

Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message.

draft-ietf-mpls-residence-time-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8169
RFC8170 Planning for Protocol Adoption and Subsequent Transitions D. Thaler Editor May 2017 ASCII HTML 22 transition plan

Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.

draft-iab-protocol-transitions-08 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8170
RFC8171 Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms D. Eastlake 3rd L. Dunbar R. Perlman Y. Li June 2017 ASCII HTML 55 Push Pull ESADI ES-IS

This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.

draft-ietf-trill-directory-assist-mechanisms-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8171
RFC8172 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure A. Morton July 2017 ASCII HTML 15

The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware.

draft-ietf-bmwg-virtual-net-05 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8172
RFC8173 Precision Time Protocol Version 2 (PTPv2) Management Information Base V. Shankarkumar L. Montini T. Frost G. Dowd June 2017 ASCII HTML 64

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.

This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions.

draft-ietf-tictoc-ptp-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF int tictoc 10.17487/RFC8173
RFC8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words B. Leiba May 2017 ASCII HTML 4

RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

draft-leiba-rfc2119-update-02 RFC2119 BCP0014 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8174 10.17487/RFC8174
RFC8175 Dynamic Link Exchange Protocol (DLEP) S. Ratliff S. Jury D. Satterwhite R. Taylor B. Berry June 2017 ASCII HTML 82

When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.

draft-ietf-manet-dlep-29 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8175
RFC8176 Authentication Method Reference Values M. Jones P. Hunt A. Nadalin June 2017 ASCII HTML 15 Authentication Method Reference Authentication Method,

The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values.

draft-ietf-oauth-amr-values-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8176 10.17487/RFC8176
RFC8177 YANG Data Model for Key Chains A. Lindem Editor Y. Qu D. Yeung I. Chen J. Zhang June 2017 ASCII HTML 25

This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.

draft-ietf-rtgwg-yang-key-chain-24 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8177
RFC8178 Rules for NFSv4 Extensions and Minor Versions D. Noveck July 2017 ASCII HTML 26

This document describes the rules relating to the extension of the NFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as Proposed Standards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions.

draft-ietf-nfsv4-versioning-11 RFC5661 RFC7862 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8178
RFC8179 Intellectual Property Rights in IETF Technology S. Bradner J. Contreras May 2017 ASCII HTML 26 IPR copyright

The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.

draft-bradner-rfc3979bis-13 RFC3979 RFC4879 RFC2026 BCP0079 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8179 10.17487/RFC8179
RFC8180 Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration X. Vilajosana Editor K. Pister T. Watteyne May 2017 ASCII HTML 28

This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.

draft-ietf-6tisch-minimal-21 BCP0210 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int 6tisch http://www.rfc-editor.org/errata_search.php?rfc=8180 10.17487/RFC8180
RFC8181 A Publication Protocol for the Resource Public Key Infrastructure (RPKI) S. Weiler A. Sonalker R. Austein July 2017 ASCII HTML 21 SIDR

This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs.

draft-ietf-sidr-publication-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8181
RFC8182 The RPKI Repository Delta Protocol (RRDP) T. Bruijnzeels O. Muravskiy B. Weber R. Austein July 2017 ASCII HTML 24

In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files.

draft-ietf-sidr-delta-protocol-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8182
RFC8183 An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services R. Austein July 2017 ASCII HTML 23 RPKI

This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.

This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships.

draft-ietf-sidr-rpki-oob-setup-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8183
RFC8184 Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires W. Cheng L. Wang H. Li S. Davari J. Dong June 2017 ASCII HTML 11 mpls mpls-tp

This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. This PW dual-homing local protection mechanism is complementary to existing PW protection mechanisms.

draft-ietf-pals-mpls-tp-dual-homing-protection-06 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC8184
RFC8185 Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection W. Cheng L. Wang H. Li J. Dong A. D'Alessandro June 2017 ASCII HTML 17 mpls mpls-tp

In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs) (RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection.

draft-ietf-pals-mpls-tp-dual-homing-coordination-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8185
RFC8186 Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) G. Mirsky I. Meilik June 2017 ASCII HTML 8 IPPM TWAMP IEEE 1588 PTPv2

This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.

draft-ietf-ippm-twamp-time-format-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8186
RFC8187 Indicating Character Encoding and Language for HTTP Header Field Parameters J. Reschke September 2017 ASCII HTML 13

By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.

This document obsoletes RFC 5987.

draft-ietf-httpbis-rfc5987bis-05 RFC5987 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8187
RFC8188 Encrypted Content-Encoding for HTTP M. Thomson June 2017 ASCII HTML 16 http content coding content encoding encryption aead

This memo introduces a content coding for HTTP that allows message payloads to be encrypted.

draft-ietf-httpbis-encryption-encoding-09 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8188 10.17487/RFC8188
RFC8189 Multi-Cost Application-Layer Traffic Optimization (ALTO) S. Randriamasy W. Roome N. Schwan October 2017 ASCII HTML 29 ALTO Information Resources Network Map PID Filtered Network Map Endpoint Property Service Endpoint Cost Service Multi-Cost Filtered Multi-Cost Map Multi-Cost Data Format Testable Cost Types or-constraints

The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.

This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.

draft-ietf-alto-multi-cost-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8189
RFC8190 Updates to the Special-Purpose IP Address Registries R. Bonica M. Cotton B. Haberman L. Vegoda June 2017 ASCII HTML 6

This memo updates the IANA IPv4 and IPv6 Special-Purpose Address Registries to address issues raised by the definition of a "global" prefix. It also corrects several errors in registry entries to ensure the integrity of the IANA Special-Purpose Address Registries.

This memo updates RFC 6890.

draft-bchv-rfc6890bis-07 RFC6890 BCP0153 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8190
RFC8191 Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) Z. Yan J. Lee X. Lee August 2017 ASCII HTML 10 PMIPv6 HNP HNP renumbering LMA handover

In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node (MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with the HNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations when HNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification.

draft-ietf-dmm-hnprenum-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8191
RFC8192 Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases S. Hares D. Lopez M. Zarny C. Jacquenet R. Kumar J. Jeong July 2017 ASCII HTML 29 I2NSF

This document sets out the problem statement for Interface to Network Security Functions (I2NSF) and outlines some companion use cases.

draft-ietf-i2nsf-problem-and-use-cases-16 INFORMATIONAL INFORMATIONAL IETF sec i2nsf 10.17487/RFC8192
RFC8193 Information Model for Large-Scale Measurement Platforms (LMAPs) T. Burbridge P. Eardley M. Bagnulo J. Schoenwaelder August 2017 ASCII HTML 53

This Information Model applies to the Measurement Agent within an LMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols.

draft-ietf-lmap-information-model-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops lmap 10.17487/RFC8193
RFC8194 A YANG Data Model for LMAP Measurement Agents J. Schoenwaelder V. Bajpai August 2017 ASCII HTML 59 LMAP YANG

This document defines a data model for Large-Scale Measurement Platforms (LMAPs). The data model is defined using the YANG data modeling language.

draft-ietf-lmap-yang-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops lmap 10.17487/RFC8194
RFC8195 Use of BGP Large Communities J. Snijders J. Heasley M. Schmidt June 2017 ASCII HTML 15 large BGP communities

This document presents examples and inspiration for operator application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire.

draft-ietf-grow-large-communities-usage-07 INFORMATIONAL INFORMATIONAL IETF ops grow 10.17487/RFC8195
RFC8196 IS-IS Autoconfiguration B. Liu Editor L. Ginsberg B. Decraene I. Farrer M. Abrahamsson July 2017 ASCII HTML 15 isis auto-configuration

This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected.

draft-ietf-isis-auto-conf-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8196
RFC8197 A SIP Response Code for Unwanted Calls H. Schulzrinne July 2017 ASCII HTML 8 SIP robocall unwanted response code

This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

draft-ietf-sipcore-status-unwanted-06 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8197
RFC8198 Aggressive Use of DNSSEC-Validated Cache K. Fujiwara A. Kato W. Kumari July 2017 ASCII HTML 13 Negative cache NCACHE NSEC NSEC3

The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.

This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.

draft-ietf-dnsop-nsec-aggressiveuse-10 RFC4035 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8198
RFC8199 YANG Module Classification D. Bogdanovic B. Claise C. Moberg July 2017 ASCII HTML 11 service element standard vendor user controller orchestrator

The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.

A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.

This document describes a set of concepts and associated terms to support consistent classification of YANG modules.

draft-ietf-netmod-yang-model-classification-08 INFORMATIONAL INFORMATIONAL IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8199 10.17487/RFC8199
RFC8200 Internet Protocol, Version 6 (IPv6) Specification S. Deering R. Hinden July 2017 ASCII HTML 42 IPv6 internet protocol next generation ipng flow label

This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.

draft-ietf-6man-rfc2460bis-13 RFC2460 STD0086 INTERNET STANDARD INTERNET STANDARD IETF int 6man http://www.rfc-editor.org/errata_search.php?rfc=8200 10.17487/RFC8200
RFC8201 Path MTU Discovery for IP version 6 J. McCann S. Deering J. Mogul R. Hinden Editor July 2017 ASCII HTML 19 MTU-IPv6 Internet Protocol IPv6 link MTU path MTU PMTU Path MTU Discovery

This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.

draft-ietf-6man-rfc1981bis-08 RFC1981 STD0087 INTERNET STANDARD INTERNET STANDARD IETF int 6man 10.17487/RFC8201
RFC8202 IS-IS Multi-Instance L. Ginsberg S. Previdi W. Henderickx June 2017 ASCII HTML 16

This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System to Intermediate System (IS-IS) routing protocol instances.

Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.

This document obsoletes RFC 6822.

draft-ietf-isis-mi-bis-03 RFC6822 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8202
RFC8203 BGP Administrative Shutdown Communication J. Snijders J. Heitz J. Scudder July 2017 ASCII HTML 6 BGP cease shutdown

This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486.

draft-ietf-idr-shutdown-10 RFC4486 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8203
RFC8204 Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) M. Tahhan B. O'Mahony A. Morton September 2017 ASCII HTML 24

This memo describes the contributions of the Open Platform for NFV (OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test. This project has extended the current and completed work of the Benchmarking Methodology Working Group in the IETF and references existing literature. The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure.

draft-ietf-bmwg-vswitch-opnfv-04 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8204
RFC8205 BGPsec Protocol Specification M. Lepinski Editor K. Sriram Editor September 2017 ASCII HTML 45 BGP BGPsec BGP AS-path protection BGP Security

This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route.

draft-ietf-sidr-bgpsec-protocol-23 RFC8206 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8205
RFC8206 BGPsec Considerations for Autonomous System (AS) Migration W. George S. Murphy September 2017 ASCII HTML 16 as-migration SIDR BGPsec AS_PATH

This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.

draft-ietf-sidr-as-migration-06 RFC8205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8206
RFC8207 BGPsec Operational Considerations R. Bush September 2017 ASCII HTML 10 BGP RPKI Routing Security

Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. Operational practices are expected to evolve as BGPsec is formalized and initially deployed.

draft-ietf-sidr-bgpsec-ops-16 BCP0211 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF rtg sidr 10.17487/RFC8207
RFC8208 BGPsec Algorithms, Key Formats, and Signature Formats S. Turner O. Borchert September 2017 ASCII HTML 19

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").

This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

draft-ietf-sidr-bgpsec-algs-18 RFC8608 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8208
RFC8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests M. Reynolds S. Turner S. Kent September 2017 ASCII HTML 15

This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487).

draft-ietf-sidr-bgpsec-pki-profiles-21 RFC6487 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8209
RFC8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 R. Bush R. Austein September 2017 ASCII HTML 35

In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.

This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.

draft-ietf-sidr-rpki-rtr-rfc6810-bis-09 RFC6810 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8210
RFC8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) S. Kent D. Ma September 2017 ASCII HTML 26 BGP Security

This document analyzes actions by or against a Certification Authority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by Relying Parties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data.

draft-ietf-sidr-adverse-actions-04 INFORMATIONAL INFORMATIONAL IETF rtg sidr 10.17487/RFC8211
RFC8212 Default External BGP (EBGP) Route Propagation Behavior without Policies J. Mauch J. Snijders G. Hankins July 2017 ASCII HTML 7 reject BGP EBGP

This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session.

draft-ietf-grow-bgp-reject-08 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8212
RFC8213 Security of Messages Exchanged between Servers and Relay Agents B. Volz Y. Pal August 2017 ASCII HTML 8

The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.

draft-ietf-dhc-relay-server-security-05 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8213
RFC8214 Virtual Private Wire Service Support in Ethernet VPN S. Boutros A. Sajassi S. Salam J. Drake J. Rabadan August 2017 ASCII HTML 17

This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.

draft-ietf-bess-evpn-vpws-14 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8214 10.17487/RFC8214
RFC8215 Local-Use IPv4/IPv6 Translation Prefix T. Anderson August 2017 ASCII HTML 7 IPv6 transition IVI MAP NAT64 SIIT SIIT-DC Transition

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms.

draft-ietf-v6ops-v4v6-xlat-prefix-02 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC8215
RFC8216 HTTP Live Streaming R. Pantos Editor W. May August 2017 ASCII HTML 60 HTML streaming media

This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 7 of this protocol.

draft-pantos-http-live-streaming-23 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8216 10.17487/RFC8216
RFC8217 Clarifications for When to Use the name-addr Production in SIP Messages R. Sparks August 2017 ASCII HTML 6

RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.

This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502).

draft-ietf-sipcore-name-addr-guidance-02 RFC3261 RFC3325 RFC3515 RFC3892 RFC4508 RFC5002 RFC5318 RFC5360 RFC5502 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8217
RFC8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) J. Yi B. Parrein August 2017 ASCII HTML 26 MANET

This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained.

draft-ietf-manet-olsrv2-multipath-15 EXPERIMENTAL EXPERIMENTAL IETF rtg manet 10.17487/RFC8218
RFC8219 Benchmarking Methodology for IPv6 Transition Technologies M. Georgescu L. Pislaru G. Lencse August 2017 ASCII HTML 30 Single Translation Technologies Double Translation Technologies Encapsulation Technologies NAT64 DNS64 MAP-E MAP-T DSLite 464XLAT 6PE DNS Resolution Performance Overload Scalability Typical Latency Worst Case Latency PDV IPDV

Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability.

draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8219
RFC8220 Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) O. Dornon J. Kotalwar V. Hemige R. Qiu Z. Zhang September 2017 ASCII HTML 43 multicast

This document describes the procedures and recommendations for Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.

With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIM Join/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstream Join/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.

This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices.

draft-ietf-pals-vpls-pim-snooping-06 INFORMATIONAL INFORMATIONAL IETF rtg pals 10.17487/RFC8220
RFC8221 Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) P. Wouters D. Migault J. Mattsson Y. Nir T. Kivinen October 2017 ASCII HTML 15 IPsec IKE

This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.

draft-ietf-ipsecme-rfc7321bis-06 RFC7321 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8221
RFC8222 Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery A. Sullivan September 2017 ASCII HTML 11 DNS mDNS DNS-SD

Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to Internationalized Domain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner.

draft-ietf-dnssd-mdns-dns-interop-04 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC8222
RFC8223 Application-Aware Targeted LDP S. Esale R. Torvi L. Jalil U. Chunduri K. Raza August 2017 ASCII HTML 18

Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with any Label Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the Targeted Application Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.

draft-ietf-mpls-app-aware-tldp-09 RFC7473 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8223 10.17487/RFC8223
RFC8224 Authenticated Identity Management in the Session Initiation Protocol (SIP) J. Peterson C. Jennings E. Rescorla C. Wendt February 2018 ASCII HTML 46 SIP Secure Origin Identification Communication Security RTCWeb Certificates Real-Time Communication

The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.

This document obsoletes RFC 4474.

draft-ietf-stir-rfc4474bis-16 RFC4474 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8224 10.17487/RFC8224
RFC8225 PASSporT: Personal Assertion Token C. Wendt J. Peterson February 2018 ASCII HTML 25

This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship.

draft-ietf-stir-passport-11 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8225 10.17487/RFC8225
RFC8226 Secure Telephone Identity Credentials: Certificates J. Peterson S. Turner February 2018 ASCII HTML 24 TNAuthorizationList JWTClaimConstraints

In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP.

draft-ietf-stir-certificates-17 PROPOSED STANDARD PROPOSED STANDARD IETF art stir http://www.rfc-editor.org/errata_search.php?rfc=8226 10.17487/RFC8226
RFC8227 MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology W. Cheng L. Wang H. Li H. van Helvoort J. Dong August 2017 ASCII HTML 56 wrapping protection short-wrapping protection steering protection ring protection shared ring protection protection switching

This document describes requirements, architecture, and solutions for MPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring.

draft-ietf-mpls-tp-shared-ring-protection-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8227
RFC8228 Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels A. Freytag August 2017 ASCII HTML 24 LGR Variant IDN

Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants. The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940.

draft-freytag-lager-variant-rules-06 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8228 10.17487/RFC8228
RFC8229 TCP Encapsulation of IKE and IPsec Packets T. Pauly S. Touati R. Mantha August 2017 ASCII HTML 25 IKE IKEv2 IPsec TCP

This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.

draft-ietf-ipsecme-tcp-encaps-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme http://www.rfc-editor.org/errata_search.php?rfc=8229 10.17487/RFC8229
RFC8230 Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages M. Jones September 2017 ASCII HTML 12 Cryptography Digital Signature Encryption

The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary Object Representation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used for COSE messages. Encodings are specified for the use of RSA Probabilistic Signature Scheme (RSASSA-PSS) signatures, RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys.

draft-jones-cose-rsa-05 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8230
RFC8231 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE E. Crabbe I. Minei J. Medved R. Varga September 2017 ASCII HTML 57 Stateful PCE

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.

draft-ietf-pce-stateful-pce-21 RFC8786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8231 10.17487/RFC8231
RFC8232 Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE E. Crabbe I. Minei J. Medved R. Varga X. Zhang D. Dhody September 2017 ASCII HTML 26 Stateful PCE state synchronization optimization

A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions.

draft-ietf-pce-stateful-sync-optimizations-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8232
RFC8233 Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) D. Dhody Q. Wu V. Manral Z. Ali K. Kumaki September 2017 ASCII HTML 31 PCE PCEP service-aware metric BU LBU LRBU

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.

IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.

draft-ietf-pce-pcep-service-aware-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8233 10.17487/RFC8233
RFC8234 Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode J. Ryoo T. Cheung H. van Helvoort I. Busi G. Wen August 2017 ASCII HTML 9 APS mode initialization mpls-tp linear protection

This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) Control Logic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup.

draft-ietf-mpls-tp-aps-updates-04 RFC7271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8234
RFC8235 Schnorr Non-interactive Zero-Knowledge Proof F. Hao Editor September 2017 ASCII HTML 13 Zero-Knowledge Proof Schnorr NIZK proof Identification protocol

This document describes the Schnorr non-interactive zero-knowledge (NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.

draft-hao-schnorr-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8235
RFC8236 J-PAKE: Password-Authenticated Key Exchange by Juggling F. Hao Editor September 2017 ASCII HTML 15

This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.

draft-hao-jpake-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8236
RFC8237 MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs L. Martini G. Swallow E. Bellagamba October 2017 ASCII HTML 20

This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more PWs carried on the LSP.

The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP.

draft-ietf-pals-status-reduction-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8237
RFC8238 Data Center Benchmarking Terminology L. Avramov J. Rapp August 2017 ASCII HTML 20

The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

draft-ietf-bmwg-dcbench-terminology-19 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8238
RFC8239 Data Center Benchmarking Methodology L. Avramov J. Rapp August 2017 ASCII HTML 19

The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere.

draft-ietf-bmwg-dcbench-methodology-18 INFORMATIONAL INFORMATIONAL IETF ops bmwg http://www.rfc-editor.org/errata_search.php?rfc=8239 10.17487/RFC8239
RFC8240 Report from the Internet of Things Software Update (IoTSU) Workshop 2016 H. Tschofenig S. Farrell September 2017 ASCII HTML 27 Security Firmware Updates Software Updates Internet of Things

This document provides a summary of the Internet of Things Software Update (IoTSU) Workshop that took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-iotsu-workshop-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8240
RFC8241 Interface to the Routing System (I2RS) Security-Related Requirements S. Hares D. Migault J. Halpern September 2017 ASCII HTML 20

This document presents security-related requirements for the Interface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them. One such reuse is of the security features of a secure transport (e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol, Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using the I2RS client, and an extremely constrained read-only non-secure transport.

draft-ietf-i2rs-protocol-security-requirements-17 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8241
RFC8242 Interface to the Routing System (I2RS) Ephemeral State Requirements J. Haas S. Hares September 2017 ASCII HTML 12

"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System (I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol.

draft-ietf-i2rs-ephemeral-state-23 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8242
RFC8243 Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) R. Perlman D. Eastlake 3rd M. Zhang A. Ghanwani H. Zhai September 2017 ASCII HTML 29 aggregaged nickname unique nickname

Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?

This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.

draft-ietf-trill-rbridge-multilevel-07 INFORMATIONAL INFORMATIONAL IETF rtg trill 10.17487/RFC8243
RFC8244 Special-Use Domain Names Problem Statement T. Lemon R. Droms W. Kumari October 2017 ASCII HTML 25 SUN SUTLD RFC6761

The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.

This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.

draft-ietf-dnsop-sutld-ps-08 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8244
RFC8245 Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 T. Clausen C. Dearlove U. Herberg H. Rogge October 2017 ASCII HTML 29 MANET

RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexed MANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers.

draft-ietf-manet-rfc5444-usage-07 RFC5444 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8245
RFC8246 HTTP Immutable Responses P. McManus September 2017 ASCII HTML 6

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

draft-ietf-httpbis-immutable-03 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8246
RFC8247 Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Nir T. Kivinen P. Wouters D. Migault September 2017 ASCII HTML 19 IPsec IKE internet key exchange

The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).

draft-ietf-ipsecme-rfc4307bis-18 RFC4307 RFC7296 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8247
RFC8248 Security Automation and Continuous Monitoring (SACM) Requirements N. Cam-Winget L. Lorenzin September 2017 ASCII HTML 20 posture assessment posture validation software integrity network authorization software compliance

This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632.

draft-ietf-sacm-requirements-18 INFORMATIONAL INFORMATIONAL IETF sec sacm 10.17487/RFC8248
RFC8249 Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation M. Zhang X. Zhang D. Eastlake 3rd R. Perlman S. Chatterjee September 2017 ASCII HTML 15

The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325, 7177, and 7780.

draft-ietf-trill-mtu-negotiation-08 RFC6325 RFC7177 RFC7780 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8249
RFC8250 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option N. Elkins R. Hamilton M. Ackermann September 2017 ASCII HTML 30

To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document.

draft-ietf-ippm-6man-pdm-option-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8250
RFC8251 Updates to the Opus Audio Codec JM. Valin K. Vos October 2017 ASCII HTML 12

This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716. The changes fix real and potential security-related issues, as well as minor quality-related issues.

draft-ietf-codec-opus-update-10 RFC6716 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC8251
RFC8252 OAuth 2.0 for Native Apps W. Denniss J. Bradley October 2017 ASCII HTML 21

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

draft-ietf-oauth-native-apps-12 RFC6749 BCP0212 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8252 10.17487/RFC8252
RFC8253 PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) D. Lopez O. Gonzalez de Dios Q. Wu D. Dhody October 2017 ASCII HTML 26 PCE PCEP PCEPS security authentication encryption TLS

The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.

This document updates RFC 5440 in regards to the PCEP initialization phase procedures.

draft-ietf-pce-pceps-18 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8253 10.17487/RFC8253
RFC8254 Uniform Resource Name (URN) Namespace Registration Transition J. Klensin J. Hakala October 2017 ASCII HTML 9 ISBN ISSN NBN national bibliography number

The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations. This document also obsoletes RFCs 3044 and 3187 and moves them to Historic status. These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates.

draft-ietf-urnbis-ns-reg-transition-08 RFC3044 RFC3187 PROPOSED STANDARD PROPOSED STANDARD IETF art urnbis 10.17487/RFC8254
RFC8255 Multiple Language Content Type N. Tomkinson N. Borenstein October 2017 ASCII HTML 19 multiple language multi lingual content type email mime

This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings.

draft-ietf-slim-multilangcontent-14 PROPOSED STANDARD PROPOSED STANDARD IETF art slim 10.17487/RFC8255
RFC8256 Requirements for Hitless MPLS Path Segment Monitoring A. D'Alessandro L. Andersson S. Ueno K. Arai Y. Koike October 2017 ASCII HTML 16 HPSM MPLS MPLS Transport Profile mpls-tp OAM monitoring Hitless Path Segment Monitoring Path Segment Monitoring HPSM

One of the most important Operations, Administration, and Maintenance (OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints. However, the current segment monitoring approach defined for MPLS (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support Hitless Path Segment Monitoring (HPSM).

draft-ietf-mpls-tp-temporal-hitless-psm-14 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8256
RFC8257 Data Center TCP (DCTCP): TCP Congestion Control for Data Centers S. Bensley D. Thaler P. Balasubramanian L. Eggert G. Judd October 2017 ASCII HTML 17 TCP ECN DCTCP congestion control

This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends the Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures.

draft-ietf-tcpm-dctcp-10 INFORMATIONAL INFORMATIONAL IETF tsv tcpm 10.17487/RFC8257
RFC8258 Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) D. Ceccarelli L. Berger October 2017 ASCII HTML 7 OSPF-TE GMPLS

This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) fields. This "Generalized SCSI" can be used with routing protocols that define GMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards.

draft-ietf-teas-gmpls-scsi-04 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8258
RFC8259 The JavaScript Object Notation (JSON) Data Interchange Format T. Bray Editor December 2017 ASCII HTML 16

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.

This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.

draft-ietf-jsonbis-rfc7159bis-04 RFC7159 STD0090 INTERNET STANDARD INTERNET STANDARD IETF art jsonbis http://www.rfc-editor.org/errata_search.php?rfc=8259 10.17487/RFC8259
RFC8260 Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol R. Stewart M. Tuexen S. Loreto R. Seggelmann November 2017 ASCII HTML 23

The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.

Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving.

draft-ietf-tsvwg-sctp-ndata-13 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8260
RFC8261 Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets M. Tuexen R. Stewart R. Jesup S. Loreto November 2017 ASCII HTML 10

The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single-homed.

draft-ietf-tsvwg-sctp-dtls-encaps-09 RFC8899 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8261
RFC8262 Content-ID Header Field in the Session Initiation Protocol (SIP) C. Holmberg I. Sedlacek October 2017 ASCII HTML 14 SIP

This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.

This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field.

draft-ietf-sipcore-content-id-10 RFC5621 RFC5368 RFC6442 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8262
RFC8263 Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message B. Weis U. Mangla T. Karl N. Maheshwari November 2017 ASCII HTML 17 multicast security

The Group Domain of Interpretation (GDOI) includes the ability of a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method.

draft-weis-gdoi-rekey-ack-07 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8263
RFC8264 PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols P. Saint-Andre M. Blanchet October 2017 ASCII HTML 43 internationalization i18n Stringprep

Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564.

draft-ietf-precis-7564bis-10 RFC7564 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=8264 10.17487/RFC8264
RFC8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords P. Saint-Andre A. Melnikov October 2017 ASCII HTML 26 Username Password Unicode Internationalization i18n Authentication SASLprep

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.

draft-ietf-precis-7613bis-11 RFC7613 PROPOSED STANDARD PROPOSED STANDARD IETF art precis http://www.rfc-editor.org/errata_search.php?rfc=8265 10.17487/RFC8265
RFC8266 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames P. Saint-Andre October 2017 ASCII HTML 13 nickname SIP SIMPLE XMPP MSRP XCON chatrooms

This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700.

draft-ietf-precis-7700bis-10 RFC7700 PROPOSED STANDARD PROPOSED STANDARD IETF art precis 10.17487/RFC8266
RFC8267 Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 C. Lever October 2017 ASCII HTML 21 NFS-over-RDMA

This document specifies Upper-Layer Bindings of Network File System (NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667.

draft-ietf-nfsv4-rfc5667bis-13 RFC5667 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8267
RFC8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) M. Baushke December 2017 ASCII HTML 8 Public Key Private Key group14 group15 group16 group17 groupt18 2048-bit 3072-bit 4096-bit 6144-bit 8192-bit

This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.

draft-ietf-curdle-ssh-modp-dh-sha2-09 RFC4250 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8268
RFC8269 The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) W. Kim J. Lee J. Park D. Kwon D. Kim October 2017 ASCII HTML 19 ARIA SRTP DTLS-SRTP MIKEY

This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA.

draft-ietf-avtcore-aria-srtp-11 INFORMATIONAL INFORMATIONAL IETF art avtcore 10.17487/RFC8269
RFC8270 Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits L. Velvindron M. Baushke December 2017 ASCII HTML 5 SSH DH

The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits. Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updates RFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size.

draft-ietf-curdle-ssh-dh-group-exchange-06 RFC4419 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8270 10.17487/RFC8270
RFC8271 Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) M. Taillon T. Saad Editor R. Gandhi Editor Z. Ali M. Bhatia October 2017 ASCII HTML 24 Co-routed LSPs Bypass assignment coordinate Restore co-routing

This document updates the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC 4090 to support Packet Switch Capable (PSC) Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane.

draft-ietf-teas-gmpls-lsp-fastreroute-12 RFC4090 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8271
RFC8272 TinyIPFIX for Smart Meters in Constrained Networks C. Schmitt B. Stiller B. Trammell November 2017 ASCII HTML 30 TinyIPFIX Smart Meters Constrained Networks

This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944). TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device.

draft-schmitt-ipfix-tiny-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8272 10.17487/RFC8272
RFC8273 Unique IPv6 Prefix per Host J. Brzozowski G. Van de Velde December 2017 ASCII HTML 10

This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments.

draft-ietf-v6ops-unique-ipv6-prefix-per-host-13 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8273
RFC8274 Incident Object Description Exchange Format Usage Guidance P. Kampanakis M. Suzuki November 2017 ASCII HTML 33 IODEF best practices IODEF implementation recommendations IODEF examples IODEF practical recommendations

The Incident Object Description Exchange Format (IODEF) v2 (RFC7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged by Computer Security Incident Response Teams (CSIRTs) . Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by CSIRTs around the world.

draft-ietf-mile-iodef-guidance-11 INFORMATIONAL INFORMATIONAL IETF sec mile 10.17487/RFC8274
RFC8275 Allowing Inheritable NFSv4 Access Control Entries to Override the Umask J. Fields A. Gruenbacher December 2017 ASCII HTML 7 NFSv4

In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that.

draft-ietf-nfsv4-umask-05 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8275 10.17487/RFC8275
RFC8276 File System Extended Attributes in NFSv4 M. Naik M. Eshel December 2017 ASCII HTML 28

This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects.

draft-ietf-nfsv4-xattrs-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8276 10.17487/RFC8276
RFC8277 Using BGP to Bind MPLS Labels to Address Prefixes E. Rosen October 2017 ASCII HTML 23 asynchronous transfer mode AAL syntax adaption layer

This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107.

draft-ietf-mpls-rfc3107bis-04 RFC3107 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8277
RFC8278 Mobile Access Gateway (MAG) Multipath Options P. Seite A. Yegin S. Gundavelli January 2018 ASCII HTML 15 Proxy Mobile IPv6 (PMIPv6) multihoming Multiple WAN accesses

This specification defines extensions to the Proxy Mobile IPv6 (PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic. This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option.

draft-ietf-dmm-mag-multihoming-07 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8278
RFC8279 Multicast Using Bit Index Explicit Replication (BIER) IJ. Wijnands Editor E. Rosen Editor A. Dolganow T. Przygienda S. Aldrin November 2017 ASCII HTML 43 Multicast

This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.

draft-ietf-bier-architecture-08 PROPOSED STANDARD EXPERIMENTAL IETF rtg bier 10.17487/RFC8279
RFC8280 Research into Human Rights Protocol Considerations N. ten Oever C. Cath October 2017 ASCII HTML 81 human rights IETF protocols guidelines considerations freedom of expression

This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed.

This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.

draft-irtf-hrpc-research-14 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8280 10.17487/RFC8280
RFC8281 Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model E. Crabbe I. Minei S. Sivabalan R. Varga December 2017 ASCII HTML 20

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.

The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.

draft-ietf-pce-pce-initiated-lsp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8281 10.17487/RFC8281
RFC8282 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering E. Oki T. Takeda A. Farrel F. Zhang December 2017 ASCII HTML 22 Multi-layer Multi-domain Inter-domain Traffic Engineering

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.

The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.

draft-ietf-pce-inter-layer-ext-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8282
RFC8283 An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control A. Farrel Editor Q. Zhao Editor Z. Li C. Zhou December 2017 ASCII HTML 25 PCE SDN

The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.

PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).

SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.

This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.

This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.

draft-ietf-teas-pce-central-control-05 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8283
RFC8284 Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages S. Kille November 2017 ASCII HTML 6

The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs). The Lightweight Directory Access Protocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols. This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications.

draft-kille-ldap-xmpp-schema-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8284
RFC8285 A General Mechanism for RTP Header Extensions D. Singer H. Desineni R. Even Editor October 2017 ASCII HTML 25

This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285.

draft-ietf-avtcore-rfc5285-bis-14 RFC5285 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8285
RFC8286 RTP/RTCP Extension for RTP Splicing Notification J. Xia R. Even R. Huang L. Deng October 2017 ASCII HTML 22

Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.

This memo defines two RTP/RTCP extensions to indicate the splicing-related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band.

draft-ietf-avtext-splicing-notification-09 PROPOSED STANDARD PROPOSED STANDARD IETF art avtext 10.17487/RFC8286
RFC8287 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes N. Kumar Editor C. Pignataro Editor G. Swallow N. Akiya S. Kini M. Chen December 2017 ASCII HTML 25 MPLS LSP Ping SPRING Segment Routing SR

A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.

The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.

draft-ietf-mpls-spring-lsp-ping-13 RFC8690 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8287 10.17487/RFC8287
RFC8288 Web Linking M. Nottingham October 2017 ASCII HTML 24 link relation

This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").

It also defines the serialisation of such links in HTTP headers with the Link header field.

draft-nottingham-rfc5988bis-08 RFC5988 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8288 10.17487/RFC8288
RFC8289 Controlled Delay Active Queue Management K. Nichols V. Jacobson A. McGregor Editor J. Iyengar Editor January 2018 ASCII HTML 25 CoDel AQM Active Queue Management

This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.

draft-ietf-aqm-codel-10 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm 10.17487/RFC8289
RFC8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm T. Hoeiland-Joergensen P. McKenney D. Taht J. Gettys E. Dumazet January 2018 ASCII HTML 25 bufferbloat aqm fq_codel fq-codel

This memo presents the FQ-CoDel hybrid packet scheduler and Active Queue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.

FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware.

draft-ietf-aqm-fq-codel-06 EXPERIMENTAL EXPERIMENTAL IETF tsv aqm 10.17487/RFC8290
RFC8291 Message Encryption for Web Push M. Thomson November 2017 ASCII HTML 13 web push notification http encryption

This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent.

draft-ietf-webpush-encryption-09 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush http://www.rfc-editor.org/errata_search.php?rfc=8291 10.17487/RFC8291
RFC8292 Voluntary Application Server Identification (VAPID) for Web Push M. Thomson P. Beverloo November 2017 ASCII HTML 14 authentication restricted restriction signature

An application server can use the Voluntary Application Server Identification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server.

draft-ietf-webpush-vapid-04 PROPOSED STANDARD PROPOSED STANDARD IETF art webpush 10.17487/RFC8292
RFC8293 A Framework for Multicast in Network Virtualization over Layer 3 A. Ghanwani L. Dunbar M. McBride V. Bannai R. Krishnan January 2018 ASCII HTML 17 NVO3 VXLAN Geneve NVGRE

This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3). Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms.

draft-ietf-nvo3-mcast-framework-11 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8293
RFC8294 Common YANG Data Types for the Routing Area X. Liu Y. Qu A. Lindem C. Hopps L. Berger December 2017 ASCII HTML 43 Network Management Routing YANG

This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.

draft-ietf-rtgwg-routing-types-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8294
RFC8295 EST (Enrollment over Secure Transport) Extensions S. Turner January 2018 ASCII HTML 54 Firmware TAMP Asymmetric Keys Symmetric Keys Product Availability List

The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services.

draft-turner-est-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8295
RFC8296 Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks IJ. Wijnands Editor E. Rosen Editor A. Dolganow J. Tantsura S. Aldrin I. Meilik January 2018 ASCII HTML 24 Multicast

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.

draft-ietf-bier-mpls-encapsulation-12 PROPOSED STANDARD EXPERIMENTAL IETF rtg bier http://www.rfc-editor.org/errata_search.php?rfc=8296 10.17487/RFC8296
RFC8297 An HTTP Status Code for Indicating Hints K. Oku December 2017 ASCII HTML 7 push preload

This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.

draft-ietf-httpbis-early-hints-05 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC8297
RFC8298 Self-Clocked Rate Adaptation for Multimedia I. Johansson Z. Sarker December 2017 ASCII HTML 36 Cellular Network Congestion Control RTP

This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.

draft-ietf-rmcat-scream-cc-13 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8298
RFC8299 YANG Data Model for L3VPN Service Delivery Q. Wu Editor S. Litkowski L. Tomotaki K. Ogaki January 2018 ASCII HTML 188

This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.

This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.

draft-wu-l3sm-rfc8049bis-11 RFC8049 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8299 10.17487/RFC8299
RFC8300 Network Service Header (NSH) P. Quinn Editor U. Elzur Editor C. Pignataro Editor January 2018 ASCII HTML 40 Service Function Chaining Network Service Header SFC NSH Network Service Function

This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).

draft-ietf-sfc-nsh-28 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc http://www.rfc-editor.org/errata_search.php?rfc=8300 10.17487/RFC8300
RFC8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) S. Kitterman January 2018 ASCII HTML 5 email authentication

The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms.

draft-ietf-dcrup-dkim-usage-06 RFC6376 PROPOSED STANDARD PROPOSED STANDARD IETF art dcrup 10.17487/RFC8301
RFC8302 Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization Y. Li D. Eastlake 3rd L. Dunbar R. Perlman M. Umair January 2018 ASCII HTML 18 proxy RARP duplicate address DAD DHCP flooding

This document describes mechanisms to optimize the Address Resolution Protocol (ARP) and Neighbor Discovery (ND) traffic in a Transparent Interconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / Data Label bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edge Routing Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus.

draft-ietf-trill-arp-optimization-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8302
RFC8303 On the Usage of Transport Features Provided by IETF Transport Protocols M. Welzl M. Tuexen N. Khademi February 2018 ASCII HTML 56

This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP), and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services (TAPS) API.

draft-ietf-taps-transports-usage-09 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8303
RFC8304 Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) G. Fairhurst T. Jones February 2018 ASCII HTML 20 UDP Transport

This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.

draft-ietf-taps-transports-usage-udp-07 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8304
RFC8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency D. Schinazi T. Pauly December 2017 ASCII HTML 15 IPv6 IPv4 TCP DNS NAT64

Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.

draft-ietf-v6ops-rfc6555bis-07 RFC6555 PROPOSED STANDARD PROPOSED STANDARD IETF ops v6ops 10.17487/RFC8305
RFC8306 Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Q. Zhao D. Dhody Editor R. Palleti D. King November 2017 ASCII HTML 43

Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.

This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.

This document obsoletes RFC 6006.

draft-ietf-pce-rfc6006bis-04 RFC6006 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce http://www.rfc-editor.org/errata_search.php?rfc=8306 10.17487/RFC8306
RFC8307 Well-Known URIs for the WebSocket Protocol C. Bormann January 2018 ASCII HTML 3 URI Web metadata well-known WebSocket ws wss

RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs. It was specifically defined for the "http" and "https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes.

draft-bormann-hybi-ws-wk-00 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8307
RFC8308 Extension Negotiation in the Secure Shell (SSH) Protocol D. Bider March 2018 ASCII HTML 14 ext-info ext-info-s ext-info-c SSH_MSG_EXT_INFO SSH_MSG_NEWCOMPRESS server-sig-algs delay-compression no-flow-control elevation delay compression delayed compression flow control elevated

This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.

draft-ietf-curdle-ssh-ext-info-15 RFC4251 RFC4252 RFC4253 RFC4254 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8308
RFC8309 Service Models Explained Q. Wu W. Liu A. Farrel January 2018 ASCII HTML 23 YANG NETCONF RESTCONF Data Model SDN Software Defined Network Service Orchestrator

The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.

A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).

This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.

draft-ietf-opsawg-service-model-explained-05 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC8309
RFC8310 Usage Profiles for DNS over TLS and DNS over DTLS S. Dickinson D. Gillmor T. Reddy March 2018 ASCII HTML 27 DNS transport

This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858.

draft-ietf-dprive-dtls-and-tls-profiles-11 RFC7858 PROPOSED STANDARD PROPOSED STANDARD IETF int dprive 10.17487/RFC8310
RFC8311 Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation D. Black January 2018 ASCII HTML 20 ECN

This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.

draft-ietf-tsvwg-ecn-experimentation-08 RFC3168 RFC4341 RFC4342 RFC5622 RFC6679 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg http://www.rfc-editor.org/errata_search.php?rfc=8311 10.17487/RFC8311
RFC8312 CUBIC for Fast Long-Distance Networks I. Rhee L. Xu S. Ha A. Zimmermann L. Eggert R. Scheffenegger February 2018 ASCII HTML 18

CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.

draft-ietf-tcpm-cubic-07 INFORMATIONAL INFORMATIONAL IETF tsv tcpm http://www.rfc-editor.org/errata_search.php?rfc=8312 10.17487/RFC8312
RFC8313 Use of Multicast across Inter-domain Peering Points P. Tarapore Editor R. Sayko G. Shepherd T. Eckert Editor R. Krishnan January 2018 ASCII HTML 44 multicast security multicast troubleshooting multicast routing multicast tunneling PIM PIM-SSM SSM Source Specific Multicast AMT GRE Automatic Multicast Tunneling BGP MBGP M-BGP MP-BGP exchange exchange point NNI content distribution video streaming anycast

This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.

draft-ietf-mboned-interdomain-peering-bcp-14 BCP0213 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC8313
RFC8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access K. Moore C. Newman January 2018 ASCII HTML 26 POP IMAP SMTP MSP mail submission STARTTLS DANE TLSA

This specification outlines current recommendations for the use of Transport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501, 5068, 6186, and 6409.

draft-ietf-uta-email-deep-12 RFC1939 RFC2595 RFC3501 RFC5068 RFC6186 RFC6409 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8314 10.17487/RFC8314
RFC8315 Cancel-Locks in Netnews Articles M. Baeuerle February 2018 ASCII HTML 20 Usenet Netnews Cancel-Lock

This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles. This document updates RFC 5537.

draft-baeuerle-netnews-cancel-lock-09 RFC5537 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8315
RFC8316 Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations J. Nobre L. Granville A. Clemm A. Gonzalez Prieto February 2018 ASCII HTML 16 Autonomic Networking SLA P2P

This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements (SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.

This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes.

draft-irtf-nmrg-autonomic-sla-violation-detection-13 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8316
RFC8317 Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) A. Sajassi Editor S. Salam J. Drake J. Uttaro S. Boutros J. Rabadan January 2018 ASCII HTML 23

The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432, "BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796, "Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS)". This document makes use of the most significant bit of the Tunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly.

draft-ietf-bess-evpn-etree-14 RFC7385 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8317
RFC8318 IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee S. Dawkins January 2018 ASCII HTML 9 nomcom IAOC

This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee (NomCom) about the operations of the IETF Administrative Oversight Committee (IAOC).

This document updates RFC 7437.

draft-dawkins-iesg-nomcom-advisor-iaoc-03 RFC8713 RFC7437 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8318
RFC8319 Support for Adjustable Maximum Router Lifetimes per Link S. Krishnan J. Korhonen S. Chakrabarti E. Nordmark A. Yourtchenko February 2018 ASCII HTML 7

The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements (RAs) from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.

This document specifies updates to the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime.

draft-ietf-6man-maxra-04 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8319
RFC8320 LDP Extensions to Support Maximally Redundant Trees A. Atlas K. Tiruveedhula C. Bowers J. Tantsura IJ. Wijnands February 2018 ASCII HTML 21 fast-reroute MRT MRT-FRR

This document specifies extensions to the Label Distribution Protocol (LDP) to support the creation of Label Switched Paths (LSPs) for Maximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as "MRT-FRR".

The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) and Label Edge Routers (LERs) advertising the MRT Capability.

MRT-FRR uses LDP multi-topology extensions, so three multi-topology IDs have been allocated from the MPLS MT-ID space.

draft-ietf-mpls-ldp-mrt-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8320
RFC8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring G. Fioccola Editor A. Capello M. Cociglio L. Castaldelli M. Chen L. Zheng G. Mirsky T. Mizrahi January 2018 ASCII HTML 33 Alternate Marking Marking Method Coloring Technique

This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on an Alternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.

draft-ietf-ippm-alt-mark-14 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8321
RFC8322 Resource-Oriented Lightweight Information Exchange (ROLIE) J. Field S. Banghart D. Waltermire February 2018 ASCII HTML 43 syndication atom atom publishing protocol atom syndication format rest information sharing security automation

This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources. Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the Atom Publishing Protocol and Atom Syndication Format to transport and share security automation resource representations.

draft-ietf-mile-rolie-16 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8322
RFC8323 CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets C. Bormann S. Lemay H. Tschofenig K. Hartke B. Silverajan B. Raymor Editor February 2018 ASCII HTML 54 CoAP Constrained Application Protocol REST IoT Internet of Things NAT Traversal CoAP in Browsers

The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.

Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.

draft-ietf-core-coap-tcp-tls-11 RFC7641 RFC7959 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8323
RFC8324 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? J. Klensin February 2018 ASCII HTML 29 domain name DNS functions DNS extensions

The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way.

draft-klensin-dns-function-considerations-05 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8324 10.17487/RFC8324
RFC8325 Mapping Diffserv to IEEE 802.11 T. Szigeti J. Henry F. Baker February 2018 ASCII HTML 37 quality of service QoS QoS classes mapping DSCP Diffserv Access Category AC User Priority UP 802.11 Wi-Fi

As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks.

draft-ietf-tsvwg-ieee-802-11-11 RFC8622 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8325
RFC8326 Graceful BGP Session Shutdown P. Francois Editor B. Decraene Editor C. Pelsser K. Patel C. Filsfils March 2018 ASCII HTML 12

This document standardizes a new well-known BGP community, GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance.

draft-ietf-grow-bgp-gshut-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=8326 10.17487/RFC8326
RFC8327 Mitigating the Negative Impact of Maintenance through BGP Session Culling W. Hargrave M. Griswold J. Snijders N. Hilliard March 2018 ASCII HTML 10 BGP culling EBGP sessions

This document outlines an approach to mitigate the negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions that will be affected by maintenance are forcefully torn down before the actual maintenance activities commence.

draft-ietf-grow-bgp-session-culling-05 BCP0214 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops grow http://www.rfc-editor.org/errata_search.php?rfc=8327 10.17487/RFC8327
RFC8328 Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA) W. Liu C. Xie J. Strassner G. Karagiannis M. Klyus J. Bi Y. Cheng D. Zhang March 2018 ASCII HTML 15 Information models YANG data models Event Condition Action policy rules GPIM EPRIM declarative policy intent-based policy

The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy. These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces.

draft-liu-policy-based-management-framework-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8328
RFC8329 Framework for Interface to Network Security Functions D. Lopez E. Lopez L. Dunbar J. Strassner R. Kumar February 2018 ASCII HTML 25 security policy security capability

This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.

draft-ietf-i2nsf-framework-10 INFORMATIONAL INFORMATIONAL IETF sec i2nsf 10.17487/RFC8329
RFC8330 OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth H. Long M. Ye G. Mirsky A. D'Alessandro H. Shah February 2018 ASCII HTML 10 microwave copper Generalized SCSI-TLV

A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word "availability" is typically used to describe such links during network planning. This document defines a new type of Generalized Switching Capability-Specific Information (SCSI) TLV to extend the Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses.

draft-ietf-ccamp-ospf-availability-extension-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8330
RFC8331 RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data T. Edwards February 2018 ASCII HTML 20 SDI video captions timecode ANC

This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers (SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1. SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD).

draft-ietf-payload-rtp-ancillary-14 PROPOSED STANDARD PROPOSED STANDARD IETF art payload http://www.rfc-editor.org/errata_search.php?rfc=8331 10.17487/RFC8331
RFC8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol D. Bider March 2018 ASCII HTML 9 rsa-sha2-256 rsa-sha2-512 ssh-rsa publickey server-sig-algs signature authentication

This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.

draft-ietf-curdle-rsa-sha2-12 RFC4252 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8332
RFC8333 Micro-loop Prevention by Introducing a Local Convergence Delay S. Litkowski B. Decraene C. Filsfils P. Francois March 2018 ASCII HTML 26

This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.

Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.

The mechanism is limited to the link-down event in order to keep the mechanism simple.

Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops.

draft-ietf-rtgwg-uloop-delay-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8333
RFC8334 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) J. Gould W. Tan G. Brown March 2018 ASCII HTML 58 EPP Sunrise Landrush Trademark Clearinghouse Trademark Claims domain name registry launch phase

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry.

draft-ietf-regext-launchphase-07 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8334
RFC8335 PROBE: A Utility for Probing Interfaces R. Bonica R. Thomas J. Linkova C. Lenart M. Boucadair February 2018 ASCII HTML 19 Ping ICMP

This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.

draft-ietf-intarea-probe-10 RFC4884 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC8335
RFC8336 The ORIGIN HTTP/2 Frame M. Nottingham E. Nygren March 2018 ASCII HTML 11 connection coalescing HTTP

This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.

draft-ietf-httpbis-origin-frame-06 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8336 10.17487/RFC8336
RFC8337 Model-Based Metrics for Bulk Transport Capacity M. Mathis A. Morton March 2018 ASCII HTML 55 performance bulk capacity BTC diagnostic statistics

This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.

Model-Based Metrics rely on mathematical models to specify a Targeted IP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.

For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the Target Transport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.

draft-ietf-ippm-model-based-metrics-13 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8337
RFC8338 Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP S. Boutros Editor S. Sivabalan Editor March 2018 ASCII HTML 20

This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type.

draft-ietf-pals-p2mp-pw-04 RFC7385 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8338
RFC8339 Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms P. Jain Editor S. Boutros S. Aldrin March 2018 ASCII HTML 10

Label Switched Path (LSP) Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping.

draft-ietf-pals-p2mp-pw-lsp-ping-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals 10.17487/RFC8339
RFC8340 YANG Tree Diagrams M. Bjorklund L. Berger Editor March 2018 ASCII HTML 13

This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.

draft-ietf-netmod-yang-tree-diagrams-06 RFC8791 BCP0215 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops netmod 10.17487/RFC8340
RFC8341 Network Configuration Access Control Model A. Bierman M. Bjorklund March 2018 ASCII HTML 58 NETCONF RESTCONF YANG XML

The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.

This document obsoletes RFC 6536.

draft-ietf-netconf-rfc6536bis-09 RFC6536 STD0091 INTERNET STANDARD INTERNET STANDARD IETF ops netconf 10.17487/RFC8341
RFC8342 Network Management Datastore Architecture (NMDA) M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2018 ASCII HTML 44 YANG NETCONF RESTCONF Network Management

Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.

draft-ietf-netmod-revised-datastores-10 RFC7950 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8342 10.17487/RFC8342
RFC8343 A YANG Data Model for Interface Management M. Bjorklund March 2018 ASCII HTML 49

This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document obsoletes RFC 7223.

draft-ietf-netmod-rfc7223bis-03 RFC7223 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8343
RFC8344 A YANG Data Model for IP Management M. Bjorklund March 2018 ASCII HTML 34

This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.

The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.

This document obsoletes RFC 7277.

draft-ietf-netmod-rfc7277bis-03 RFC7277 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8344
RFC8345 A YANG Data Model for Network Topologies A. Clemm J. Medved R. Varga N. Bahadur H. Ananthakrishnan X. Liu March 2018 ASCII HTML 57 topology

This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.

draft-ietf-i2rs-yang-network-topo-20 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8345
RFC8346 A YANG Data Model for Layer 3 Topologies A. Clemm J. Medved R. Varga X. Liu H. Ananthakrishnan N. Bahadur March 2018 ASCII HTML 35 topology

This document defines a YANG data model for Layer 3 network topologies.

draft-ietf-i2rs-yang-l3-topology-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8346
RFC8347 A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) X. Liu Editor A. Kyparlis R. Parikh A. Lindem M. Zhang March 2018 ASCII HTML 45 Network Management Routing YANG

This document describes a data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered.

draft-ietf-rtgwg-yang-vrrp-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8347
RFC8348 A YANG Data Model for Hardware Management A. Bierman M. Bjorklund J. Dong D. Romascanu March 2018 ASCII HTML 60 ENTITY-MIB

This document defines a YANG data model for the management of hardware on a single server.

draft-ietf-netmod-entity-08 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8348
RFC8349 A YANG Data Model for Routing Management (NMDA Version) L. Lhotka A. Lindem Y. Qu March 2018 ASCII HTML 80 configuration IPv6 Router Advertisements NETCONF RESTCONF

This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.

The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.

draft-ietf-netmod-rfc8022bis-11 RFC8022 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8349 10.17487/RFC8349
RFC8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) R. Zhang R. Pazhyannur S. Gundavelli Z. Cao H. Deng Z. Du April 2018 ASCII HTML 29 Wi-Fi WLAN PMIP GRE

Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP Data Channel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP.

draft-ietf-opsawg-capwap-alt-tunnel-12 EXPERIMENTAL EXPERIMENTAL IETF ops opsawg 10.17487/RFC8350
RFC8351 The PKCS #8 EncryptedPrivateKeyInfo Media Type S. Leonard June 2018 ASCII HTML 7

This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value.

draft-seantek-pkcs8-encrypted-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8351
RFC8352 Energy-Efficient Features of Internet of Things Protocols C. Gomez M. Kovatsch H. Tian Z. Cao Editor April 2018 ASCII HTML 24 IoT Radio Duty Cycling 6LoWPAN 6Lo CoAP RPL

This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.

draft-ietf-lwig-energy-efficient-08 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC8352
RFC8353 Generic Security Service API Version 2: Java Bindings Update M. Upadhyay S. Malkani W. Wang May 2018 ASCII HTML 96 JGSS GSS-API

The Generic Security Services Application Programming Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2: Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.

The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121).

draft-ietf-kitten-rfc5653bis-07 RFC5653 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8353
RFC8354 Use Cases for IPv6 Source Packet Routing in Networking (SPRING) J. Brzozowski J. Leddy C. Filsfils R. Maglione Editor M. Townsley March 2018 ASCII HTML 9

The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in an IPv6-only environment.

draft-ietf-spring-ipv6-use-cases-12 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8354
RFC8355 Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks C. Filsfils Editor S. Previdi Editor B. Decraene R. Shakir March 2018 ASCII HTML 13 SEGMENT ROUTING RESILIENCY PROTECTION CONVERGENCE

This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on Source Packet Routing in Networking (SPRING) networks.

draft-ietf-spring-resiliency-use-cases-12 INFORMATIONAL INFORMATIONAL IETF rtg spring http://www.rfc-editor.org/errata_search.php?rfc=8355 10.17487/RFC8355
RFC8356 Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) D. Dhody D. King A. Farrel March 2018 ASCII HTML 7 PCE PCEP IANA Experimental

IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.

This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.

draft-ietf-pce-pcep-exp-codepoints-05 RFC5440 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8356
RFC8357 Generalized UDP Source Port for DHCP Relay N. Shen E. Chen March 2018 ASCII HTML 10

This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

draft-ietf-dhc-relay-port-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=8357 10.17487/RFC8357
RFC8358 Update to Digital Signatures on Internet-Draft Documents R. Housley March 2018 ASCII HTML 9 cms cryptographic message syntax detached signature

RFC 5485 specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.

The RFC Editor recently published the first RFC that includes non- ASCII characters in a text file. The conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.

This document updates RFC 5485.

draft-housley-id-sig-update-03 RFC5485 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8358 10.17487/RFC8358
RFC8359 Network-Assigned Upstream Label X. Zhang Editor V. Beeram Editor I. Bryskin D. Ceccarelli O. Gonzalez de Dios March 2018 ASCII HTML 10

This document discusses a Generalized Multi-Protocol Label Switching (GMPLS) Resource reSerVation Protocol with Traffic Engineering (RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object.

draft-ietf-teas-network-assigned-upstream-label-12 RFC3471 RFC3473 RFC6205 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8359
RFC8360 Resource Public Key Infrastructure (RPKI) Validation Reconsidered G. Huston G. Michaelson C. Martinez T. Bruijnzeels A. Newton D. Shaw April 2018 ASCII HTML 29

This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource Public Key Infrastructure (RPKI), while retaining essential security features.

The procedure specified in RFC 6487 requires that Resource Certificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing Certification Authority (CA) to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate.

It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.

This choice is signaled by a set of alternative Object Identifiers (OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers" (RFC 3779) and "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.

Furthermore, this document provides an alternative to Route Origin Authorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsec PKI Profiles -- publication requested) validation.

draft-ietf-sidr-rpki-validation-reconsidered-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr http://www.rfc-editor.org/errata_search.php?rfc=8360 10.17487/RFC8360
RFC8361 Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic W. Hao Y. Li M. Durrani S. Gupta A. Qu April 2018 ASCII HTML 17 TRILL RBridge CMT LAALP

In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325). To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325.

draft-ietf-trill-centralized-replication-13 RFC6325 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8361
RFC8362 OSPFv3 Link State Advertisement (LSA) Extensibility A. Lindem A. Roy D. Goethals V. Reddy Vallem F. Baker April 2018 ASCII HTML 33

OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.

This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.

draft-ietf-ospf-ospfv3-lsa-extend-23 RFC5340 RFC5838 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8362
RFC8363 GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks X. Zhang H. Zheng R. Casellas O. Gonzalez de Dios D. Ceccarelli May 2018 ASCII HTML 17 flexi-grid OSPF-TE central frequency frequency slot channel spacing

The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as "flexi-grid".

Based on the characteristics of flexi-grid defined in G.694.1 and in RFCs 7698 and 7699, this document describes the Open Shortest Path First - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.

draft-ietf-ccamp-flexible-grid-ospf-ext-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8363
RFC8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD) IJ. Wijnands S. Venaas M. Brig A. Jonasson March 2018 ASCII HTML 18 Multicast

Protocol Independent Multicast - Sparse Mode (PIM-SM) uses a Rendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIM Flooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.

draft-ietf-pim-source-discovery-bsr-12 RFC8736 EXPERIMENTAL EXPERIMENTAL IETF rtg pim 10.17487/RFC8364
RFC8365 A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) A. Sajassi Editor J. Drake Editor N. Bitar R. Shekhar J. Uttaro W. Henderickx March 2018 ASCII HTML 33 EVPN Control Plane with VxLAN Encapsulation EVPN Control Plane with NvGRE Encapsulation

This document specifies how Ethernet VPN (EVPN) can be used as a Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to Generic Network Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifies EVPN route constructions for VXLAN/NVGRE encapsulations and Autonomous System Border Router (ASBR) procedures for multihoming of Network Virtualization Edge (NVE) devices.

draft-ietf-bess-evpn-overlay-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8365 10.17487/RFC8365
RFC8366 A Voucher Artifact for Bootstrapping Protocols K. Watsen M. Richardson M. Pritikin T. Eckert May 2018 ASCII HTML 23 voucher

This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.

draft-ietf-anima-voucher-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops anima 10.17487/RFC8366
RFC8367 Wrongful Termination of Internet Protocol (IP) Packets T. Mizrahi J. Yallouz April 1 2018 ASCII HTML 6

Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.

draft-tj-wrongful-termination-00 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8367
RFC8368 Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) T. Eckert Editor M. Behringer May 2018 ASCII HTML 24

Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.

Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.

This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.

draft-ietf-anima-stable-connectivity-10 INFORMATIONAL INFORMATIONAL IETF ops anima 10.17487/RFC8368
RFC8369 Internationalizing IPv6 Using 128-Bit Unicode H. Kaplan April 1 2018 ASCII HTML 11

It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6.

draft-kaplan-unicode-ipv6-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8369 10.17487/RFC8369
RFC8370 Techniques to Improve the Scalability of RSVP-TE Deployments V. Beeram Editor I. Minei R. Shakir D. Pacella T. Saad May 2018 ASCII HTML 11 RSVP-TE Scaling RI-RSVP Per-Peer Flow Control

Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number of LSPs deployed.

This document defines two techniques, Refresh-Interval Independent RSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in Label Switching Routers (LSRs) and hence allow implementations to support larger scale deployments.

draft-ietf-teas-rsvp-te-scaling-rec-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8370
RFC8371 Mobile Node Identifier Types for MIPv6 C. Perkins V. Devarapalli July 2018 ASCII HTML 16 Mobility IPv6 Authentication

This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.

draft-ietf-dmm-4283mnids-08 PROPOSED STANDARD PROPOSED STANDARD IETF int dmm 10.17487/RFC8371
RFC8372 MPLS Flow Identification Considerations S. Bryant C. Pignataro M. Chen Z. Li G. Mirsky May 2018 ASCII HTML 11 OAM performance monitoring flow identification

This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.

draft-ietf-mpls-flow-ident-07 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8372
RFC8373 Negotiating Human Language in Real-Time Communications R. Gellens May 2018 ASCII HTML 13 SDP language human language SIP SLIM

Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).

This document describes the need as well as a solution that uses new SDP media attributes.

draft-ietf-slim-negotiating-human-language-24 PROPOSED STANDARD PROPOSED STANDARD IETF art slim http://www.rfc-editor.org/errata_search.php?rfc=8373 10.17487/RFC8373
RFC8374 BGPsec Design Choices and Summary of Supporting Discussions K. Sriram Editor April 2018 ASCII HTML 50 Internet Routing Security

This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes.

draft-sriram-bgpsec-design-choices-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8374
RFC8375 Special-Use Domain 'home.arpa.' P. Pfister T. Lemon May 2018 ASCII HTML 12 Homenet TLD RFC6761 .home.arpa

This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.

draft-ietf-homenet-dot-14 RFC7788 PROPOSED STANDARD PROPOSED STANDARD IETF int homenet 10.17487/RFC8375
RFC8376 Low-Power Wide Area Network (LPWAN) Overview S. Farrell Editor May 2018 ASCII HTML 43 Low Power Wide Area Network Overview

Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.

draft-ietf-lpwan-overview-10 INFORMATIONAL INFORMATIONAL IETF int lpwan 10.17487/RFC8376
RFC8377 Transparent Interconnection of Lots of Links (TRILL): Multi-Topology D. Eastlake 3rd M. Zhang A. Banerjee July 2018 ASCII HTML 20

This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.

draft-ietf-trill-multi-topology-06 RFC6325 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8377
RFC8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast V. Moreno D. Farinacci May 2018 ASCII HTML 21 LISP deployment

When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.

draft-ietf-lisp-signal-free-multicast-09 EXPERIMENTAL EXPERIMENTAL IETF rtg lisp 10.17487/RFC8378
RFC8379 OSPF Graceful Link Shutdown S. Hegde P. Sarkar H. Gredler M. Nanduri L. Jalil May 2018 ASCII HTML 17 MPLS IGP OSPF

When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.

It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.

This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.

draft-ietf-ospf-link-overload-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8379
RFC8380 Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation L. Dunbar D. Eastlake 3rd R. Perlman May 2018 ASCII HTML 10 Directory Nickname

This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection of Lots of Links) encapsulation with assistance from a directory service.

draft-ietf-trill-directory-assisted-encap-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8380
RFC8381 Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol D. Eastlake 3rd Y. Li W. Hao A. Banerjee May 2018 ASCII HTML 11 OUI CID

The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called an RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor-specific messages over the RBridge Channel facility.

draft-ietf-trill-vendor-channel-01 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8381
RFC8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media D. Hayes Editor S. Ferlin M. Welzl K. Hiorth June 2018 ASCII HTML 25 SBD

This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.

draft-ietf-rmcat-sbd-11 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8382
RFC8383 Transparent Interconnection of Lots of Links (TRILL): Address Flush Message W. Hao D. Eastlake 3rd Y. Li M. Umair May 2018 ASCII HTML 20 convergence VLAN data label FGL

The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.

This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change.

draft-ietf-trill-address-flush-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8383
RFC8384 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes R. Perlman F. Hu D. Eastlake 3rd T. Liao July 2018 ASCII HTML 17 TRILL Smart Endnode

This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that are Fine-Grained Label (FGL) aware.

draft-ietf-trill-smart-endnodes-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8384
RFC8385 Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS M. Umair S. Kingston Smiler D. Eastlake 3rd L. Yong June 2018 ASCII HTML 16 VPLS VPTS TIR

This document specifies methods to interconnect multiple TRILL (Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (Virtual Private LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network.

draft-ietf-trill-transport-over-mpls-08 INFORMATIONAL INFORMATIONAL IETF rtg trill 10.17487/RFC8385
RFC8386 Privacy Considerations for Protocols Relying on IP Broadcast or Multicast R. Winter M. Faath F. Weisshaar May 2018 ASCII HTML 13 IP broadcasts multicast privacy considerations

A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content. Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols.

draft-ietf-intarea-broadcast-consider-09 INFORMATIONAL INFORMATIONAL IETF int intarea 10.17487/RFC8386
RFC8387 Practical Considerations and Implementation Experiences in Securing Smart Object Networks M. Sethi J. Arkko A. Keranen H. Back May 2018 ASCII HTML 33 IoT security integrity signing ECC CoAP asymmetric cryptography

This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches.

draft-ietf-lwig-crypto-sensors-06 INFORMATIONAL INFORMATIONAL IETF int lwig 10.17487/RFC8387
RFC8388 Usage and Applicability of BGP MPLS-Based Ethernet VPN J. Rabadan Editor S. Palislamovic W. Henderickx A. Sajassi J. Uttaro May 2018 ASCII HTML 31 EVPN

This document discusses the usage and applicability of BGP MPLS-based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.

draft-ietf-bess-evpn-usage-09 INFORMATIONAL INFORMATIONAL IETF rtg bess 10.17487/RFC8388
RFC8389 Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) Y. Fu S. Jiang B. Liu J. Dong Y. Chen December 2018 ASCII HTML 16 IPv6 MAP

This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.

draft-ietf-softwire-map-mib-13 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8389
RFC8390 RSVP-TE Path Diversity Using Exclude Route Z. Ali Editor G. Swallow Editor F. Zhang Editor D. Beller Editor July 2018 ASCII HTML 26 LSP diversity

RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit Exclusion Route Subobject (EXRS).

For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing (reference) LSP, before the new path is established, is not considered.

draft-ietf-teas-lsp-diversity-10 RFC4874 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8390
RFC8391 XMSS: eXtended Merkle Signature Scheme A. Huelsing D. Butin S. Gazdag J. Rijneveld A. Mohaisen May 2018 ASCII HTML 74 Digital signature cryptography post-quantum cryptography Hash-based signatures Merkle signatures Merkle tree hash function Winternitz Winternitz one-time signature scheme WOTS W-OTS WOTS+ W-OTS+ XMSS-MT multi-tree XMSS

This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.

draft-irtf-cfrg-xmss-hash-based-signatures-12 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8391 10.17487/RFC8391
RFC8392 CBOR Web Token (CWT) M. Jones E. Wahlstroem S. Erdtman H. Tschofenig May 2018 ASCII HTML 25 JSON Web Token JWT Claims Concise Binary Object Representation CBOR CBOR Object Signing and Encryption COSE OAuth ACE

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.

draft-ietf-ace-cbor-web-token-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace http://www.rfc-editor.org/errata_search.php?rfc=8392 10.17487/RFC8392
RFC8393 Operating the Network Service Header (NSH) with Next Protocol "None" A. Farrel J. Drake May 2018 ASCII HTML 12 Service Function Chaining Network Service Header Metadata

This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None".

This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.

draft-farrel-sfc-convent-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sfc 10.17487/RFC8393
RFC8394 Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements Y. Li D. Eastlake 3rd L. Kreeger T. Narten D. Black May 2018 ASCII HTML 26 NVO3 VDP

In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.

One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements.

draft-ietf-nvo3-hpvr2nve-cp-req-17 INFORMATIONAL INFORMATIONAL IETF rtg nvo3 10.17487/RFC8394
RFC8395 Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels K. Patel S. Boutros J. Liste B. Wen J. Rabadan June 2018 ASCII HTML 9

This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks (L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.

draft-ietf-bess-fat-pw-bgp-04 RFC4761 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8395
RFC8396 Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework J. Peterson T. McGarry July 2018 ASCII HTML 23 SIP Problem Statement Real-Time Communication

The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs.

draft-ietf-modern-problem-framework-04 INFORMATIONAL INFORMATIONAL IETF art modern 10.17487/RFC8396
RFC8397 Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames M. Zhang D. Eastlake 3rd R. Perlman H. Zhai D. Liu May 2018 ASCII HTML 16 Aggregated Global Tree Local Tree

TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus.

draft-ietf-trill-multilevel-unique-nickname-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8397
RFC8398 Internationalized Email Addresses in X.509 Certificates A. Melnikov Editor W. Chuang Editor May 2018 ASCII HTML 12 EAI PKIX emal address

This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.

This document updates RFC 5280.

draft-ietf-lamps-eai-addresses-18 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8398 10.17487/RFC8398
RFC8399 Internationalization Updates to RFC 5280 R. Housley May 2018 ASCII HTML 9

The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates.

draft-ietf-lamps-rfc5280-i18n-update-04 RFC5280 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8399
RFC8400 Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection H. Chen A. Liu T. Saad F. Xu L. Huang June 2018 ASCII HTML 21 FRR Fast Reroute

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP).

draft-ietf-teas-rsvp-egress-protection-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas http://www.rfc-editor.org/errata_search.php?rfc=8400 10.17487/RFC8400
RFC8401 Bit Index Explicit Replication (BIER) Support via IS-IS L. Ginsberg Editor T. Przygienda S. Aldrin Z. Zhang June 2018 ASCII HTML 12

This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture.

draft-ietf-bier-isis-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8401
RFC8402 Segment Routing Architecture C. Filsfils Editor S. Previdi Editor L. Ginsberg B. Decraene S. Litkowski R. Shakir July 2018 ASCII HTML 32

Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.

SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.

SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.

draft-ietf-spring-segment-routing-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8402
RFC8403 A Scalable and Topology-Aware MPLS Data-Plane Monitoring System R. Geib Editor C. Filsfils C. Pignataro Editor N. Kumar July 2018 ASCII HTML 19 Segment based Routing OAM LSP surveillance MPLS monitoring

This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.

draft-ietf-spring-oam-usecase-10 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8403
RFC8404 Effects of Pervasive Encryption on Operators K. Moriarty Editor A. Morton Editor July 2018 ASCII HTML 53 NETCONF RESTCONF Monitoring Management Security Management Operations

Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.

draft-mm-wg-effect-encrypt-25 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8404
RFC8405 Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs B. Decraene S. Litkowski H. Gredler A. Lindem P. Francois C. Bowers June 2018 ASCII HTML 14

This document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.

Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events.

draft-ietf-rtgwg-backoff-algo-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8405
RFC8406 Taxonomy of Coding Techniques for Efficient Network Communications B. Adamson C. Adjih J. Bilbao V. Firoiu F. Fitzek S. Ghanem E. Lochin A. Masucci M-J. Montpetit M. Pedersen G. Peralta V. Roca Editor P. Saxena S. Sivakumar June 2018 ASCII HTML 15 Network Coding Taxonomy

This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents on Network Coding. This document is the product of the Coding for Efficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the Reliable Multicast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups.

draft-irtf-nwcrg-network-coding-taxonomy-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8406
RFC8407 Guidelines for Authors and Reviewers of Documents Containing YANG Data Models A. Bierman October 2018 ASCII HTML 63 NETMOD NETCONF RESTCONF

This memo provides guidelines for authors and reviewers of specifications containing YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 6087.

draft-ietf-netmod-rfc6087bis-20 RFC6087 BCP0216 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8407 10.17487/RFC8407
RFC8408 Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages S. Sivabalan J. Tantsura I. Minei R. Varga J. Hardwick July 2018 ASCII HTML 12

A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session.

draft-ietf-pce-lsp-setup-type-10 RFC8664 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8408
RFC8409 The Entity Category Security Assertion Markup Language (SAML) Attribute Types I. Young Editor L. Johansson S. Cantor August 2018 ASCII HTML 12 REFEDS

This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.

This document is a product of the working group process of the Research and Education FEDerations (REFEDS) group.

draft-young-entity-category-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8409
RFC8410 Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure S. Josefsson J. Schaad August 2018 ASCII HTML 20 Elliptic Curve Cryptography Curve25519 Curve448 Goldilocks X.509 PKIX PKI OID ASN.1 EdDSA Ed25519 Ed448 X25519 X448

This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.

draft-ietf-curdle-pkix-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8410 10.17487/RFC8410
RFC8411 IANA Registration for the Cryptographic Algorithm Object Identifier Range J. Schaad R. Andrews August 2018 ASCII HTML 5

When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.

draft-schaad-curdle-oid-registry-03 INFORMATIONAL INFORMATIONAL IETF sec curdle 10.17487/RFC8411
RFC8412 Software Inventory Message and Attributes (SWIMA) for PA-TNC C. Schmidt D. Haynes C. Coffin D. Waltermire J. Fitzgerald-McKay July 2018 ASCII HTML 101 SWID PA-TNC NEA Software inventory

This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).

draft-ietf-sacm-nea-swima-patnc-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec sacm 10.17487/RFC8412
RFC8413 Framework for Scheduled Use of Resources Y. Zhuang Q. Wu H. Chen A. Farrel July 2018 ASCII HTML 22 Traffic Engineering TE Label Switched Path LSP MPLS Path Computation Element PCE Software Defined Networking SDN

Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service.

draft-ietf-teas-scheduled-resources-07 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8413
RFC8414 OAuth 2.0 Authorization Server Metadata M. Jones N. Sakimura J. Bradley June 2018 ASCII HTML 23 OAuth Discovery Metadata Discovery Metadata Configuration Information Authorization Server WebFinger JavaScript Object Notation JSON JSON Web Token JWT

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

draft-ietf-oauth-discovery-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8414
RFC8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) T. Mrugalski M. Siodelski B. Volz A. Yourtchenko M. Richardson S. Jiang T. Lemon T. Winters November 2018 ASCII HTML 154 DHCPv6 IPv6 DHCP

This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).

This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.

draft-ietf-dhc-rfc3315bis-13 RFC3315 RFC3633 RFC3736 RFC4242 RFC7083 RFC7283 RFC7550 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc http://www.rfc-editor.org/errata_search.php?rfc=8415 10.17487/RFC8415
RFC8416 Simplified Local Internet Number Resource Management with the RPKI (SLURM) D. Ma D. Mandelberg T. Bruijnzeels August 2018 ASCII HTML 17 RPKI Local Trust Anchor BGPsec

The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.

draft-ietf-sidr-slurm-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg sidr 10.17487/RFC8416
RFC8417 Security Event Token (SET) P. Hunt Editor M. Jones W. Denniss M. Ansari July 2018 ASCII HTML 28 Identity Security Event Token Claims JSON JSON Web Token JWT

This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP.

draft-ietf-secevent-token-13 PROPOSED STANDARD PROPOSED STANDARD IETF sec secevent 10.17487/RFC8417
RFC8418 Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) R. Housley August 2018 ASCII HTML 18

This document describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS).

draft-ietf-curdle-cms-ecdh-new-curves-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8418
RFC8419 Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) R. Housley August 2018 ASCII HTML 9

This document specifies the conventions for using the Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS.

draft-ietf-curdle-cms-eddsa-signatures-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8419 10.17487/RFC8419
RFC8420 Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) Y. Nir August 2018 ASCII HTML 5

This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).

draft-ietf-ipsecme-eddsa-04 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8420
RFC8421 Guidelines for Multihomed and IPv4/IPv6 Dual-Stack Interactive Connectivity Establishment (ICE) P. Martinsen T. Reddy P. Patil July 2018 ASCII HTML 9

This document provides guidelines on how to make Interactive Connectivity Establishment (ICE) conclude faster in multihomed and IPv4/IPv6 dual-stack scenarios where broken paths exist. The provided guidelines are backward compatible with the original ICE specification (see RFC 5245).

draft-ietf-ice-dualstack-fairness-07 BCP0217 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art ice 10.17487/RFC8421
RFC8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Y. Nir S. Josefsson M. Pegourie-Gonnard August 2018 ASCII HTML 34 ECDSA EdDSA

This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.

This document obsoletes RFC 4492.

draft-ietf-tls-rfc4492bis-17 RFC4492 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8422 10.17487/RFC8422
RFC8423 Reclassification of Suite B Documents to Historic Status R. Housley L. Zieglar July 2018 ASCII HTML 8 x.509 v3 certificates x.509 v2 certificate revocation lists crl UI suites user interface suites elliptic curve ike cryptographic algorithm policy security application suite b cryptography cmc suite b x.509 public key certificates cryptographic algorithm policy nsa

This document reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239, 6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430.

draft-housley-suite-b-to-historic-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8423 10.17487/RFC8423
RFC8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection H. Chen Editor R. Torvi Editor August 2018 ASCII HTML 28 Head Protection

This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP). It extends the Fast Reroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.

draft-ietf-teas-rsvp-ingress-protection-17 EXPERIMENTAL EXPERIMENTAL IETF rtg teas 10.17487/RFC8424
RFC8425 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags O. Troan July 2018 ASCII HTML 4

The Prefix Information Option (PIO) in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved (Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861.

draft-ietf-6man-ndpioiana-04 RFC4861 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8425
RFC8426 Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence H. Sitaraman Editor V. Beeram I. Minei S. Sivabalan July 2018 ASCII HTML 12

Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.

draft-ietf-teas-sr-rsvp-coexistence-rec-04 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8426
RFC8427 Representing DNS Messages in JSON P. Hoffman July 2018 ASCII HTML 15

Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.

draft-hoffman-dns-in-json-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8427 10.17487/RFC8427
RFC8428 Sensor Measurement Lists (SenML) C. Jennings Z. Shelby J. Arkko A. Keranen C. Bormann August 2018 ASCII HTML 54 IoT data model

This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.

draft-ietf-core-senml-16 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8428
RFC8429 Deprecate Triple-DES (3DES) and RC4 in Kerberos B. Kaduk M. Short October 2018 ASCII HTML 10 GSS-API GSS

The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.

draft-ietf-curdle-des-des-des-die-die-die-05 RFC3961 RFC4120 BCP0218 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec curdle 10.17487/RFC8429
RFC8430 RIB Information Model N. Bahadur Editor S. Kini Editor J. Medved September 2018 ASCII HTML 28 RIB info model

Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using a Routing Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts.

draft-ietf-i2rs-rib-info-model-17 INFORMATIONAL INFORMATIONAL IETF rtg i2rs 10.17487/RFC8430
RFC8431 A YANG Data Model for the Routing Information Base (RIB) L. Wang M. Chen A. Dass H. Ananthakrishnan S. Kini N. Bahadur September 2018 ASCII HTML 71

This document defines a YANG data model for the Routing Information Base (RIB) that aligns with the Interface to the Routing System (I2RS) RIB information model.

draft-ietf-i2rs-rib-data-model-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8431
RFC8432 A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters J. Ahlberg Editor M. Ye Editor X. Li LM. Contreras CJ. Bernardos October 2018 ASCII HTML 20 Microwave millimeter waves YANG Model interface management

The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.

This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG data model.

The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology.

draft-ietf-ccamp-microwave-framework-07 INFORMATIONAL INFORMATIONAL IETF rtg ccamp 10.17487/RFC8432
RFC8433 A Simpler Method for Resolving Alert-Info URNs D. Worley August 2018 ASCII HTML 45 Alert-Info audio signals call signaling call transfer resolution signaling signals SIP URN visual signals

The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.

RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace.

draft-worley-alert-info-fsm-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8433
RFC8434 Requirements for Parallel NFS (pNFS) Layout Types T. Haynes August 2018 ASCII HTML 17 NFSv4

This document defines the requirements that individual Parallel NFS (pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661.

draft-ietf-nfsv4-layout-types-13 RFC5661 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8434
RFC8435 Parallel NFS (pNFS) Flexible File Layout B. Halevy T. Haynes August 2018 ASCII HTML 42 NFSv4

Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files.

draft-ietf-nfsv4-flex-files-19 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8435
RFC8436 Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry G. Fairhurst August 2018 ASCII HTML 7 Diffserv DSCP

The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.

This update to RFC 2474 changes the IANA registration policy for Pool 3 of the registry (i.e., DSCP values of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of the DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes.

draft-ietf-tsvwg-iana-dscp-registry-08 RFC2474 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8436
RFC8437 IMAP UNAUTHENTICATE Extension for Connection Reuse C. Newman August 2018 ASCII HTML 11 IMAP unauthenticate SASL login authenticate authentication

This specification extends the Internet Message Access Protocol (IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities.

draft-ietf-extra-imap-unauth-01 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8437
RFC8438 IMAP Extension for STATUS=SIZE S. Bosch August 2018 ASCII HTML 6 imap status size

This document adds a new capability called "STATUS=SIZE" to the Internet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox.

draft-ietf-extra-imap-status-size-02 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8438
RFC8439 ChaCha20 and Poly1305 for IETF Protocols Y. Nir A. Langley June 2018 ASCII HTML 46 CHACHA CHACHA20 POLY1305 AEAD

This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm.

RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section.

draft-nir-cfrg-rfc7539bis-04 RFC7539 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8439 10.17487/RFC8439
RFC8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST K. Murchison B. Gondwana August 2018 ASCII HTML 6 IMAP4 LIST MYRIGHTS

This document defines an extension to the Internet Message Access Protocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command.

draft-ietf-extra-imap-list-myrights-07 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8440
RFC8441 Bootstrapping WebSockets with HTTP/2 P. McManus September 2018 ASCII HTML 8 CONNECT SETTINGS

This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.

draft-ietf-httpbis-h2-websockets-07 RFC6455 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8441 10.17487/RFC8441
RFC8442 ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 J. Mattsson D. Migault September 2018 ASCII HTML 7

This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM and AES-CCM provide encryption and integrity protection.

draft-ietf-tls-ecdhe-psk-aead-05 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8442
RFC8443 Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization R. Singh M. Dolly S. Das A. Nguyen August 2018 ASCII HTML 10 SIP Resource-Priority Resource Priority Header (rph) JSON Web Token Claim Identity header Authentication Service Assertion Verification Service

This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization.

draft-ietf-stir-rph-06 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC8443
RFC8444 OSPFv2 Extensions for Bit Index Explicit Replication (BIER) P. Psenak Editor N. Kumar IJ. Wijnands A. Dolganow T. Przygienda J. Zhang S. Aldrin November 2018 ASCII HTML 12

Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). The BFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in the BIER packet header.

This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document.

draft-ietf-bier-ospf-bier-extensions-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8444
RFC8445 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal A. Keranen C. Holmberg J. Rosenberg July 2018 ASCII HTML 100 NAT

This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).

This document obsoletes RFC 5245.

draft-ietf-ice-rfc5245bis-20 RFC5245 PROPOSED STANDARD PROPOSED STANDARD IETF art ice 10.17487/RFC8445
RFC8446 The Transport Layer Security (TLS) Protocol Version 1.3 E. Rescorla August 2018 ASCII HTML 160 international data algorithm symmetric transport protocol layer authentication privacy

This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.

This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.

draft-ietf-tls-tls13-28 RFC5077 RFC5246 RFC6961 RFC5705 RFC6066 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8446 10.17487/RFC8446
RFC8447 IANA Registry Updates for TLS and DTLS J. Salowey S. Turner August 2018 ASCII HTML 20

This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.

This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

draft-ietf-tls-iana-registry-updates-05 RFC3749 RFC4680 RFC5077 RFC5246 RFC5705 RFC5878 RFC6520 RFC7301 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8447 10.17487/RFC8447
RFC8448 Example Handshake Traces for TLS 1.3 M. Thomson January 2019 ASCII HTML 68

This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values.

draft-ietf-tls-tls13-vectors-07 INFORMATIONAL INFORMATIONAL IETF sec tls http://www.rfc-editor.org/errata_search.php?rfc=8448 10.17487/RFC8448
RFC8449 Record Size Limit Extension for TLS M. Thomson August 2018 ASCII HTML 8 TLS record IoT encryption

An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.

This replaces the maximum fragment length extension defined in RFC 6066.

draft-ietf-tls-record-limit-03 RFC6066 PROPOSED STANDARD PROPOSED STANDARD IETF sec tls 10.17487/RFC8449
RFC8450 RTP Payload Format for VC-2 High Quality (HQ) Profile J. Weaver October 2018 ASCII HTML 24 rtp vc-2 VC2 dirac

This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.

The HQ profile of VC-2 is intended for low-latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).

draft-ietf-payload-rtp-vc2hq-08 PROPOSED STANDARD PROPOSED STANDARD IETF art payload 10.17487/RFC8450
RFC8451 Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API V. Singh R. Huang R. Even D. Romascanu L. Deng September 2018 ASCII HTML 18 Web real-time communication

This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTP Control Protocol (RTCP) Sender Report (SR), Receiver Report (RR), and Extended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows.

draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-10 INFORMATIONAL INFORMATIONAL IETF art xrblock 10.17487/RFC8451
RFC8452 AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption S. Gueron A. Langley Y. Lindell April 2019 ASCII HTML 42 authenticated encryption aead aes gcm siv

This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.

This document is the product of the Crypto Forum Research Group.

draft-irtf-cfrg-gcmsiv-09 INFORMATIONAL INFORMATIONAL IRTF http://www.rfc-editor.org/errata_search.php?rfc=8452 10.17487/RFC8452
RFC8453 Framework for Abstraction and Control of TE Networks (ACTN) D. Ceccarelli Editor Y. Lee Editor August 2018 ASCII HTML 42 SDN Orchestration

Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.

Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.

This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.

draft-ietf-teas-actn-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8453
RFC8454 Information Model for Abstraction and Control of TE Networks (ACTN) Y. Lee S. Belotti D. Dhody D. Ceccarelli B. Yoon September 2018 ASCII HTML 23

This document provides an information model for Abstraction and Control of TE Networks (ACTN).

draft-ietf-teas-actn-info-model-10 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8454
RFC8455 Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance V. Bhuvaneswaran A. Basil M. Tassinari V. Manral S. Banks October 2018 ASCII HTML 23

This document defines terminology for benchmarking a Software-Defined Networking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services.

draft-ietf-bmwg-sdn-controller-benchmark-term-10 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8455
RFC8456 Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance V. Bhuvaneswaran A. Basil M. Tassinari V. Manral S. Banks October 2018 ASCII HTML 64

This document defines methodologies for benchmarking the control-plane performance of Software-Defined Networking (SDN) Controllers. The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations.

draft-ietf-bmwg-sdn-controller-benchmark-meth-09 INFORMATIONAL INFORMATIONAL IETF ops bmwg 10.17487/RFC8456
RFC8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute B. Leiba Editor September 2018 ASCII HTML 11 IMAP attributes

RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788.

draft-ietf-extra-specialuse-important-04 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8457
RFC8458 Using National Bibliography Numbers as Uniform Resource Names J. Hakala October 2018 ASCII HTML 18 Network Working Group National bibliography numbers Uniform resource names

National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as International Standard Book Number (ISBN).

A Uniform Resource Name (URN) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.

This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.

draft-hakala-urn-nbn-rfc3188bis-02 RFC3188 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8458
RFC8459 Hierarchical Service Function Chaining (hSFC) D. Dolson S. Homma D. Lopez M. Boucadair September 2018 ASCII HTML 29 Scalability SFC-enabled domain multiple control domains SFC complexity Hierarchy service delivery service complications service offering differentiated services large scale network

Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.

The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.

draft-ietf-sfc-hierarchical-11 EXPERIMENTAL EXPERIMENTAL IETF rtg sfc 10.17487/RFC8459
RFC8460 SMTP TLS Reporting D. Margolis A. Brotman B. Ramakrishnan J. Jones M. Risher September 2018 ASCII HTML 34 DANE MTA-STS

A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.

draft-ietf-uta-smtp-tlsrpt-23 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8460 10.17487/RFC8460
RFC8461 SMTP MTA Strict Transport Security (MTA-STS) D. Margolis M. Risher B. Ramakrishnan A. Brotman J. Jones September 2018 ASCII HTML 29 SMTP STARTTLS Mail Security

SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

draft-ietf-uta-mta-sts-21 PROPOSED STANDARD PROPOSED STANDARD IETF art uta http://www.rfc-editor.org/errata_search.php?rfc=8461 10.17487/RFC8461
RFC8462 Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) N. Rooney S. Dawkins Editor October 2018 ASCII HTML 28 Networks

The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.

The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.

A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.

draft-iab-marnew-report-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8462
RFC8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) J. Levine September 2018 ASCII HTML 7 DKIM ed25519 cryptography

This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm.

draft-ietf-dcrup-dkim-crypto-14 RFC6376 PROPOSED STANDARD PROPOSED STANDARD IETF art dcrup 10.17487/RFC8463
RFC8464 A URN Namespace for Device Identity and Mobile Equipment Identity (MEID) R. Atarius September 2018 ASCII HTML 10 MEID instance ID IMS

This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.

draft-atarius-dispatch-meid-urn-18 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8464
RFC8465 Using the Mobile Equipment Identity (MEID) URN as an Instance ID R. Atarius Editor September 2018 ASCII HTML 8 MEID instance ID IMS

This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.

draft-atarius-dispatch-meid-urn-as-instanceid-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8465
RFC8466 A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery B. Wen G. Fioccola Editor C. Xie L. Jalil October 2018 ASCII HTML 158 L2SM Service Model L2VPN SM L2VPN Service Model

This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.

The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.

The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.

draft-ietf-l2sm-l2vpn-service-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops l2sm http://www.rfc-editor.org/errata_search.php?rfc=8466 10.17487/RFC8466
RFC8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0)) A. Mayrhofer October 2018 ASCII HTML 9 security

RFC 7830 specifies the "Padding" option for Extension Mechanisms for DNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options ("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.

draft-ietf-dprive-padding-policy-06 EXPERIMENTAL EXPERIMENTAL IETF int dprive 10.17487/RFC8467
RFC8468 IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework A. Morton J. Fabini N. Elkins M. Ackermann V. Hegde November 2018 ASCII HTML 15 Measurement Methodology Standard-Formed Packet Type-P Minimal Packet IPv6 Transition

This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation.

draft-ietf-ippm-2330-ipv6-06 RFC2330 INFORMATIONAL INFORMATIONAL IETF tsv ippm 10.17487/RFC8468
RFC8469 Recommendation to Use the Ethernet Control Word S. Bryant A. Malis I. Bagdonas November 2018 ASCII HTML 9 pseudowire PW CW ECMP MAC address out of order ordering

The pseudowire (PW) encapsulation of Ethernet, as defined in RFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR). This may lead to the selection of the wrong equal-cost multipath (ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.

This document updates RFC 4448.

draft-ietf-pals-ethernet-cw-07 RFC4448 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pals http://www.rfc-editor.org/errata_search.php?rfc=8469 10.17487/RFC8469
RFC8470 Using Early Data in HTTP M. Thomson M. Nottingham W. Tarreau September 2018 ASCII HTML 12 HTTP TLS replay retry 0-RTT early data status code

Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.

draft-ietf-httpbis-replay-04 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8470
RFC8471 The Token Binding Protocol Version 1.0 A. Popov Editor M. Nystroem D. Balfanz J. Hodges October 2018 ASCII HTML 18 Token cookie TLS export replay

This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.

draft-ietf-tokbind-protocol-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8471
RFC8472 Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation A. Popov Editor M. Nystroem D. Balfanz October 2018 ASCII HTML 8 Cookie TLS export replay

This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document.

draft-ietf-tokbind-negotiation-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8472
RFC8473 Token Binding over HTTP A. Popov M. Nystroem D. Balfanz Editor N. Harper J. Hodges October 2018 ASCII HTML 25 Cookie TLS OAuth export replay

This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.

We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.

Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.

This document is a companion document to "The Token Binding Protocol Version 1.0" (RFC 8471).

draft-ietf-tokbind-https-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec tokbind 10.17487/RFC8473
RFC8474 IMAP Extension for Object Identifiers B. Gondwana Editor September 2018 ASCII HTML 16 IMAP email

This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.

draft-ietf-extra-imap-objectid-08 RFC3501 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8474
RFC8475 Using Conditional Router Advertisements for Enterprise Multihoming J. Linkova M. Stucchi October 2018 ASCII HTML 21 ipv6

This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.

draft-ietf-v6ops-conditional-ras-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8475
RFC8476 Signaling Maximum SID Depth (MSD) Using OSPF J. Tantsura U. Chunduri S. Aldrin P. Psenak December 2018 ASCII HTML 11 BGP-LS SID MSD OSPF

This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.

draft-ietf-ospf-segment-routing-msd-25 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8476
RFC8477 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016 J. Jimenez H. Tschofenig D. Thaler October 2018 ASCII HTML 18 data model

This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-iotsi-workshop-02 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8477
RFC8478 Zstandard Compression and the application/zstd Media Type Y. Collet M. Kucherawy Editor October 2018 ASCII HTML 54 Compression

Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet Mail Extensions (MIME).

Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.

draft-kucherawy-dispatch-zstd-03 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP http://www.rfc-editor.org/errata_search.php?rfc=8478 10.17487/RFC8478
RFC8479 Storing Validation Parameters in PKCS#8 N. Mavrogiannopoulos September 2018 ASCII HTML 8 private keys validation parameters PKCS#8

This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information Syntax Specification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-Key Information Syntax Specification as defined in RFC 5958.

The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard.

draft-mavrogiannopoulos-pkcs8-validated-parameters-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8479
RFC8480 6TiSCH Operation Sublayer (6top) Protocol (6P) Q. Wang Editor X. Vilajosana T. Watteyne November 2018 ASCII HTML 50 schedule management distributed scheduling time synchronized channel hopping scheduling

This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.

draft-ietf-6tisch-6top-protocol-12 PROPOSED STANDARD PROPOSED STANDARD IETF int 6tisch 10.17487/RFC8480
RFC8481 Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) R. Bush September 2018 ASCII HTML 5 security routing

Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration.

draft-ietf-sidrops-ov-clarify-05 RFC6811 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8481
RFC8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY J. Abley O. Gudmundsson M. Majkowski E. Hunt January 2019 ASCII HTML 10 DNS ANY REFUSE DDOS ABUSE

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.

This document updates RFCs 1034 and 1035.

draft-ietf-dnsop-refuse-any-07 RFC1034 RFC1035 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8482
RFC8483 Yeti DNS Testbed L. Song Editor D. Liu P. Vixie A. Kato S. Kerr October 2018 ASCII HTML 39 Root Server DNSSEC IPv6

Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet's Domain Name System is designed and built).

draft-song-yeti-testbed-experience-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8483
RFC8484 DNS Queries over HTTPS (DoH) P. Hoffman P. McManus October 2018 ASCII HTML 21 DNS HTTP DoH

This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

draft-ietf-doh-dns-over-https-14 PROPOSED STANDARD PROPOSED STANDARD IETF art doh http://www.rfc-editor.org/errata_search.php?rfc=8484 10.17487/RFC8484
RFC8485 Vectors of Trust J. Richer Editor L. Johansson October 2018 ASCII HTML 21

This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction.

draft-richer-vectors-of-trust-15 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8485
RFC8486 Ambisonics in an Ogg Opus Container J. Skoglund M. Graczyk October 2018 ASCII HTML 10 spatial audio lossy compression

This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families.

draft-ietf-codec-ambisonics-10 RFC7845 PROPOSED STANDARD PROPOSED STANDARD IETF art codec 10.17487/RFC8486
RFC8487 Mtrace Version 2: Traceroute Facility for IP Multicast H. Asaeda K. Meyer W. Lee. Ed. October 2018 ASCII HTML 41 multicast mtrace mtrace2 traceroute PIM

This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply.

draft-ietf-mboned-mtrace-v2-26 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned 10.17487/RFC8487
RFC8488 RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation O. Muravskiy T. Bruijnzeels December 2018 ASCII HTML 17 RPKI validation RRDP

This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both.

draft-ietf-sidrops-rpki-tree-validation-03 INFORMATIONAL INFORMATIONAL IETF ops sidrops 10.17487/RFC8488
RFC8489 Session Traversal Utilities for NAT (STUN) M. Petit-Huguenin G. Salgueiro J. Rosenberg D. Wing R. Mahy P. Matthews February 2020 ASCII HTML 67 SIPs

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs and does not require any special behavior from them.

STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution.

This document obsoletes RFC 5389.

draft-ietf-tram-stunbis-21 RFC5389 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram http://www.rfc-editor.org/errata_search.php?rfc=8489 10.17487/RFC8489
RFC8490 DNS Stateful Operations R. Bellis S. Cheshire J. Dickinson S. Dickinson T. Lemon T. Pusateri March 2019 ASCII HTML 64

This document defines a new DNS OPCODE for DNS Stateful Operations (DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a new DNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts.

draft-ietf-dnsop-session-signal-20 RFC1035 RFC7766 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8490
RFC8491 Signaling Maximum SID Depth (MSD) Using IS-IS J. Tantsura U. Chunduri S. Aldrin L. Ginsberg November 2018 ASCII HTML 10 BGP-LS SID MSD IS-IS

This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.

draft-ietf-isis-segment-routing-msd-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8491
RFC8492 Secure Password Ciphersuites for Transport Layer Security (TLS) D. Harkins Editor February 2019 ASCII HTML 40 Password Authenticated Key Exchange Dictionary Attack Authentication TLS

This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks.

draft-harkins-tls-dragonfly-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8492 10.17487/RFC8492
RFC8493 The BagIt File Packaging Format (V1.0) J. Kunze J. Littman E. Madden J. Scancella C. Adams October 2018 ASCII HTML 25

This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive metadata "tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer.

draft-kunze-bagit-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8493 10.17487/RFC8493
RFC8494 Multicast Email (MULE) over Allied Communications Publication (ACP) 142 D. Wilson A. Melnikov Editor November 2018 ASCII HTML 19 P_MUL

Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (Multicast Email), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP 142). MULE enables transfer between Message Transfer Agents (MTAs). It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).

This document explains how MULE can be used in conjunction with SMTP (RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.

This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics.

draft-melnikov-email-over-pmul-08 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8494
RFC8495 Allocation Token Extension for the Extensible Provisioning Protocol (EPP) J. Gould K. Feher November 2018 ASCII HTML 17

This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".

draft-ietf-regext-allocation-token-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8495
RFC8496 P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP) D. York T. Asveren October 2018 ASCII HTML 11 p-header

This text documents the current usage of P-Charge-Info, an existing Session Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA.

draft-york-p-charge-info-08 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8496
RFC8497 Marking SIP Messages to Be Logged P. Dawes C. Arunachalam November 2018 ASCII HTML 46 SIP logme troubleshooting debug debugging logging

SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent (UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.

This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling. Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminating SIP user agents, even if a session originates and terminates in different networks.

draft-ietf-insipid-logme-marking-13 PROPOSED STANDARD PROPOSED STANDARD IETF art insipid 10.17487/RFC8497
RFC8498 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) M. Mohali February 2019 ASCII HTML 15 SIP RFC5502 P- 3GPP IMS Served-User orig-cdiv

The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks.

draft-ietf-sipcore-originating-cdiv-parameter-08 RFC5502 INFORMATIONAL INFORMATIONAL IETF art sipcore 10.17487/RFC8498
RFC8499 DNS Terminology P. Hoffman A. Sullivan K. Fujiwara January 2019 ASCII HTML 50 vocabulary domain name system

The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.

This document obsoletes RFC 7719 and updates RFC 2308.

draft-ietf-dnsop-terminology-bis-14 RFC7719 RFC2308 BCP0219 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8499
RFC8500 IS-IS Routing with Reverse Metric N. Shen S. Amante M. Abrahamsson February 2019 ASCII HTML 15 IGP IS-IS Metric Reverse-Metric IIH

This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router.

draft-ietf-isis-reverse-metric-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8500
RFC8501 Reverse DNS in IPv6 for Internet Service Providers L. Howard November 2018 ASCII HTML 15 IPv6 PTR rDNS Reverse DNS

In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.

draft-ietf-dnsop-isp-ip6rdns-07 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8501
RFC8502 L2L3 VPN Multicast MIB Z. Zhang H. Tsunoda December 2018 ASCII HTML 20 MVPN BGP MPLS P-tunnel PMSI Tunnel attribute SNMP monitor management

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.

draft-ietf-bess-l2l3-vpn-mcast-mib-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8502
RFC8503 BGP/MPLS Layer 3 VPN Multicast Management Information Base H. Tsunoda December 2018 ASCII HTML 57 MVPN PE router P-tunnel PMSI MIB SNMP monitor

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by the Multiprotocol Label Switching/Border Gateway Protocol (MPLS/BGP) on a Provider Edge (PE) router.

draft-ietf-bess-mvpn-mib-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8503
RFC8504 IPv6 Node Requirements T. Chown J. Loughney T. Winters January 2019 ASCII HTML 42 IPv6 Internet Protocol Version 6 Internet Protocol IP

This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.

This document obsoletes RFC 6434, and in turn RFC 4294.

draft-ietf-6man-rfc6434-bis-09 RFC6434 BCP0220 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int 6man 10.17487/RFC8504
RFC8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery P. Thubert Editor E. Nordmark S. Chakrabarti C. Perkins November 2018 ASCII HTML 47 Wi-Fi

This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.

draft-ietf-6lo-rfc6775-update-21 RFC6775 RFC8928 RFC8929 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo http://www.rfc-editor.org/errata_search.php?rfc=8505 10.17487/RFC8505
RFC8506 Diameter Credit-Control Application L. Bertz Editor D. Dolson Editor Y. Lifshitz Editor March 2019 ASCII HTML 130 Diameter charging

This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations.

draft-ietf-dime-rfc4006bis-12 RFC4006 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8506
RFC8507 Simple Internet Protocol (SIP) Specification S. Deering R. Hinden Editor December 2018 ASCII HTML 26 IPv6 IPng

This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6.

The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.

The paragraph that follows is the Abstract from the original draft.

This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.

draft-historic-simple-ip-03 HISTORIC HISTORIC INDEPENDENT 10.17487/RFC8507
RFC8508 IMAP REPLACE Extension S. Brandt January 2019 ASCII HTML 11

This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.

draft-ietf-extra-imap-replace-03 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8508
RFC8509 A Root Key Trust Anchor Sentinel for DNSSEC G. Huston J. Damas W. Kumari December 2018 ASCII HTML 19 DNSSEC KSK RFC5011 DNS rollover root-key-sentinel-is-ta- root-key-sentinel-not-ta- root key security

The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.

draft-ietf-dnsop-kskroll-sentinel-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8509
RFC8510 OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement P. Psenak Editor K. Talaulikar W. Henderickx P. Pillay-Esnault January 2019 ASCII HTML 8 IGP OSPF

Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency (Remote Interface ID).

This document describes the extensions to OSPF link-local signaling (LLS) to advertise the Local Interface ID.

draft-ietf-ospf-lls-interface-id-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8510
RFC8511 TCP Alternative Backoff with ECN (ABE) N. Khademi M. Welzl G. Armitage G. Fairhurst December 2018 ASCII HTML 12

Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.

draft-ietf-tcpm-alternativebackoff-ecn-12 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC8511
RFC8512 A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) M. Boucadair Editor S. Sivakumar C. Jacquenet S. Vinapamula Q. Wu January 2019 ASCII HTML 94 address sharing address depletion IPv4 service continuity NETCONF programmability automation service automation NPTv6 SIIT NAT64 CLAT Destination NAT Port Restricted NAT Port Range

This document defines a YANG module for the Network Address Translation (NAT) function.

Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document.

draft-ietf-opsawg-nat-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC8512
RFC8513 A YANG Data Model for Dual-Stack Lite (DS-Lite) M. Boucadair C. Jacquenet S. Sivakumar January 2019 ASCII HTML 21 IPv4 service continuity IPv4 address exhaustion Service Availability Address sharing IPv6 Reliability IPv4 over IPv6

This document defines a YANG module for the Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.

draft-ietf-softwire-dslite-yang-17 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8513
RFC8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension S. Bosch January 2019 ASCII HTML 7 imap savedate

This document adds a new capability called "SAVEDATE" to the Internet Message Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends the FETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria.

draft-ietf-extra-imap-savedate-01 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8514
RFC8515 URN Namespace for ETSI Documents M. Jethanandani M.A. Reina Ortega February 2019 ASCII HTML 7 YANG NETCONF RESTCONF

This document describes the Namespace Identifier (NID) "etsi" for Uniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute (http://etsi.org). ETSI specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the ETSI Protocol Naming and Numbering Service (PNNS).

draft-mahesh-etsi-urn-05 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8515
RFC8516 "Too Many Requests" Response Code for the Constrained Application Protocol A. Keranen January 2019 ASCII HTML 6 CoAP

A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests.

draft-ietf-core-too-many-reqs-06 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8516
RFC8517 An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective D. Dolson Editor J. Snellman M. Boucadair Editor C. Jacquenet February 2019 ASCII HTML 21 address sharing NAT firewall Service Function transport service delivery Internet architecture TCP QUIC Path Layer UDP Substrate

This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".

RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.

draft-dolson-transport-middlebox-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8517
RFC8518 Selection of Loop-Free Alternates for Multi-Homed Prefixes P. Sarkar Editor U. Chunduri Editor S. Hegde J. Tantsura H. Gredler March 2019 ASCII HTML 20 LFA Multi-homed Prefix IGP

Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects.

draft-ietf-rtgwg-multihomed-prefix-lfa-09 RFC5286 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8518
RFC8519 YANG Data Model for Network Access Control Lists (ACLs) M. Jethanandani S. Agarwal L. Huang D. Blair March 2019 ASCII HTML 60 ACE ACL Firewall PBR NMDA

This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.

draft-ietf-netmod-acl-model-21 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8519 10.17487/RFC8519
RFC8520 Manufacturer Usage Description Specification E. Lear R. Droms D. Romascanu March 2019 ASCII HTML 60 MUD IoT Security Access Policy

This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.

draft-ietf-opsawg-mud-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=8520 10.17487/RFC8520
RFC8521 Registration Data Access Protocol (RDAP) Object Tagging S. Hollenbeck A. Newton November 2018 ASCII HTML 13 RDAP Entity Bootstrap

The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries.

draft-ietf-regext-rdap-object-tag-05 RFC7484 BCP0221 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF art regext http://www.rfc-editor.org/errata_search.php?rfc=8521 10.17487/RFC8521
RFC8522 Looking Glass Command Set M. Stubbig February 2019 ASCII HTML 20 Looking Glass

This document introduces a command set standard to the web-based "Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.

The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format.

draft-mst-lgapi-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8522
RFC8525 YANG Library A. Bierman M. Bjorklund J. Schoenwaelder K. Watsen R. Wilton March 2019 ASCII HTML 32 NMDA

This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.

draft-ietf-netconf-rfc7895bis-07 RFC7895 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8525
RFC8526 NETCONF Extensions to Support the Network Management Datastore Architecture M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2019 ASCII HTML 23 NMDA

This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data> and <edit-data> operations and augments existing <lock>, <unlock>, and <validate> operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) by NETCONF servers implementing the NMDA.

draft-ietf-netconf-nmda-netconf-08 RFC6241 RFC7950 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8526
RFC8527 RESTCONF Extensions to Support the Network Management Datastore Architecture M. Bjorklund J. Schoenwaelder P. Shafer K. Watsen R. Wilton March 2019 ASCII HTML 9

This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA.

draft-ietf-netconf-nmda-restconf-05 RFC8040 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8527
RFC8528 YANG Schema Mount M. Bjorklund L. Lhotka March 2019 ASCII HTML 28

This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module.

draft-ietf-netmod-schema-mount-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod http://www.rfc-editor.org/errata_search.php?rfc=8528 10.17487/RFC8528
RFC8529 YANG Data Model for Network Instances L. Berger C. Hopps A. Lindem D. Bogdanovic X. Liu March 2019 ASCII HTML 44 VRF VSI VPN

This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

draft-ietf-rtgwg-ni-model-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8529
RFC8530 YANG Model for Logical Network Elements L. Berger C. Hopps A. Lindem D. Bogdanovic X. Liu March 2019 ASCII HTML 49 VRF VSI VPN

This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture (NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342.

draft-ietf-rtgwg-lne-model-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8530
RFC8531 Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols D. Kumar Q. Wu Z. Wang April 2019 ASCII HTML 54

This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).

The YANG data model in this document conforms to the Network Management Datastore Architecture.

draft-ietf-lime-yang-connection-oriented-oam-model-07 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime http://www.rfc-editor.org/errata_search.php?rfc=8531 10.17487/RFC8531
RFC8532 Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications D. Kumar Z. Wang Q. Wu Editor R. Rahman S. Raghavan April 2019 ASCII HTML 59

This document presents a base YANG Data model for the management of Operations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using the YANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.

There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same level through a unified interface).

draft-ietf-lime-yang-connectionless-oam-18 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime 10.17487/RFC8532
RFC8533 A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications D. Kumar M. Wang Q. Wu Editor R. Rahman S. Raghavan April 2019 ASCII HTML 41 CL OAM Retrieval Methods

This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface).

draft-ietf-lime-yang-connectionless-oam-methods-13 PROPOSED STANDARD PROPOSED STANDARD IETF ops lime 10.17487/RFC8533
RFC8534 Explicit Tracking with Wildcard Routes in Multicast VPN A. Dolganow J. Kotalwar E. Rosen Editor Z. Zhang February 2019 ASCII HTML 21 Multicast MVPN

The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900.

draft-ietf-bess-mvpn-expl-track-13 RFC6514 RFC6625 RFC7524 RFC7582 RFC7900 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8534
RFC8536 The Time Zone Information Format (TZif) A. Olson P. Eggert K. Murchison February 2019 ASCII HTML 34 time zone tzdata tzif

This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined.

draft-murchison-tzdist-tzif-16 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8536
RFC8537 Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) R. Gandhi Editor H. Shah J. Whittaker February 2019 ASCII HTML 16 RSVP-TE LSP

Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document updates the fast reroute procedures defined in RFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event.

draft-ietf-teas-assoc-corouted-bidir-frr-07 RFC4090 RFC7551 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8537
RFC8538 Notification Message Support for BGP Graceful Restart K. Patel R. Fernando J. Scudder J. Haas March 2019 ASCII HTML 10 IDR BGP

The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart.

draft-ietf-idr-bgp-gr-notification-16 RFC4724 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8538
RFC8539 Softwire Provisioning Using DHCPv4 over DHCPv6 I. Farrer Q. Sun Y. Cui L. Sun March 2019 ASCII HTML 18 Provisioning Softwire DHCP 4o6 IPv4 over IPv6 IPv4 service continuity IPv4 address depletion IPv4 over IPv6 MAP Lightweight 4over6

DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.

"DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.

draft-ietf-dhc-dhcp4o6-saddr-opt-08 RFC7598 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8539
RFC8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960 R. Stewart M. Tuexen M. Proshin February 2019 ASCII HTML 94

This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided.

draft-ietf-tsvwg-rfc4960-errata-08 INFORMATIONAL INFORMATIONAL IETF tsv tsvwg 10.17487/RFC8540
RFC8541 Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops S. Litkowski B. Decraene M. Horneffer March 2019 ASCII HTML 15 IS-IS OSPF

A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.

This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies.

draft-ietf-rtgwg-spf-uloop-pb-statement-10 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC8541
RFC8542 A YANG Data Model for Fabric Topology in Data-Center Networks Y. Zhuang D. Shi R. Gu H. Ananthakrishnan March 2019 ASCII HTML 32 YANG Fabric Topology Data-Center Networks

This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric. This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model.

draft-ietf-i2rs-yang-dc-fabric-network-topology-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8542
RFC8543 Extensible Provisioning Protocol (EPP) Organization Mapping L. Zhou N. Kong J. Yao J. Gould G. Zhou March 2019 ASCII HTML 43 epp registry organization object mapping

This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository.

draft-ietf-regext-org-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8543
RFC8544 Organization Extension for the Extensible Provisioning Protocol (EPP) L. Zhou N. Kong J. Wei J. Yao J. Gould April 2019 ASCII HTML 22 epp organization mapping extension

This document describes an extension to Extensible Provisioning Protocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.

draft-ietf-regext-org-ext-11 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8544
RFC8545 Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) A. Morton Editor G. Mirsky Editor March 2019 ASCII HTML 11 OWAMP TWAMP

This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry.

This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.

draft-ietf-ippm-port-twamp-test-04 RFC4656 RFC5357 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8545
RFC8546 The Wire Image of a Network Protocol B. Trammell M. Kuehlewind April 2019 ASCII HTML 10

This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.

draft-iab-wire-image-01 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8546
RFC8547 TCP-ENO: Encryption Negotiation Option A. Bittau D. Giffin M. Handley D. Mazieres E. Smith May 2019 ASCII HTML 31 tcp encryption

Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.

draft-ietf-tcpinc-tcpeno-19 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpinc 10.17487/RFC8547
RFC8548 Cryptographic Protection of TCP Streams (tcpcrypt) A. Bittau D. Giffin M. Handley D. Mazieres Q. Slack E. Smith May 2019 ASCII HTML 32 tcp encryption

This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection.

draft-ietf-tcpinc-tcpcrypt-15 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpinc 10.17487/RFC8548
RFC8549 Export of BGP Community Information in IP Flow Information Export (IPFIX) Z. Li R. Gu J. Dong April 2019 ASCII HTML 18 community BGP IPFIX

By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export (IPFIX) to export BGP community information, including the BGP Standard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092. According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering.

draft-ietf-opsawg-ipfix-bgp-community-12 PROPOSED STANDARD PROPOSED STANDARD IETF ops opsawg 10.17487/RFC8549
RFC8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling J. Schaad B. Ramsdell S. Turner April 2019 ASCII HTML 29 S/MIME

This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750.

draft-ietf-lamps-rfc5750-bis-08 RFC5750 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8550
RFC8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification J. Schaad B. Ramsdell S. Turner April 2019 ASCII HTML 63 S/MIME

This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751.

draft-ietf-lamps-rfc5751-bis-11 RFC5751 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8551
RFC8552 Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves D. Crocker March 2019 ASCII HTML 15 DNS Domain Name System

Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.

draft-ietf-dnsop-attrleaf-16 BCP0222 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8552 10.17487/RFC8552
RFC8553 DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names D. Crocker March 2019 ASCII HTML 15 DNS Domain Name System

Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.

draft-ietf-dnsop-attrleaf-fix-07 RFC2782 RFC3263 RFC3529 RFC3620 RFC3832 RFC3887 RFC3958 RFC4120 RFC4227 RFC4386 RFC4387 RFC4976 RFC5026 RFC5328 RFC5389 RFC5415 RFC5518 RFC5555 RFC5617 RFC5679 RFC5766 RFC5780 RFC5804 RFC5864 RFC5928 RFC6120 RFC6186 RFC6376 RFC6733 RFC6763 RFC7208 RFC7489 RFC8145 BCP0222 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8553
RFC8554 Leighton-Micali Hash-Based Signatures D. McGrew M. Curcio S. Fluhrer April 2019 ASCII HTML 61 LMS HSS stateful

This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them.

draft-mcgrew-hash-sigs-15 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8554
RFC8555 Automatic Certificate Management Environment (ACME) R. Barnes J. Hoffman-Andrews D. McCarney J. Kasten March 2019 ASCII HTML 95 certificate HTTPS PKI X.509

Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.

draft-ietf-acme-acme-18 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme http://www.rfc-editor.org/errata_search.php?rfc=8555 10.17487/RFC8555
RFC8556 Multicast VPN Using Bit Index Explicit Replication (BIER) E. Rosen Editor M. Sivakumar T. Przygienda S. Aldrin A. Dolganow April 2019 ASCII HTML 17 Multicast

The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.

draft-ietf-bier-mvpn-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bier 10.17487/RFC8556
RFC8557 Deterministic Networking Problem Statement N. Finn P. Thubert May 2019 ASCII HTML 11

This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.

draft-ietf-detnet-problem-statement-09 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8557
RFC8558 Transport Protocol Path Signals T. Hardie Editor April 2019 ASCII HTML 10

This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.

draft-iab-path-signals-03 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=8558 10.17487/RFC8558
RFC8559 Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol A. DeKok J. Korhonen April 2019 ASCII HTML 21 RADIUS Change of Authorization CoA-Request Disconnect-Request

RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.

draft-ietf-radext-coa-proxy-10 RFC5176 RFC5580 PROPOSED STANDARD PROPOSED STANDARD IETF ops radext 10.17487/RFC8559
RFC8560 Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents A. Sajassi Editor S. Salam N. Del Regno J. Rabadan May 2019 ASCII HTML 16 EVPN VPLS PBB-EVPN PBB-VPLS Ethernet Virtual Private Networks Virtual Private LAN Services Provider Backbone Bridging

This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPN Provider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media Access Control (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs.

draft-ietf-bess-evpn-vpls-seamless-integ-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8560
RFC8561 A YANG Data Model for Microwave Radio Link J. Ahlberg M. Ye X. Li D. Spreafico M. Vaupotic June 2019 ASCII HTML 53 microwaveRadioLinkTerminal microwaveCarrierTermination

This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well.

draft-ietf-ccamp-mw-yang-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8561
RFC8562 Bidirectional Forwarding Detection (BFD) for Multipoint Networks D. Katz D. Ward S. Pallagatti Editor G. Mirsky Editor April 2019 ASCII HTML 23 BFD Multipoint BFD

This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.

This document updates RFC 5880.

draft-ietf-bfd-multipoint-19 RFC5880 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC8562
RFC8563 Bidirectional Forwarding Detection (BFD) Multipoint Active Tails D. Katz D. Ward S. Pallagatti Editor G. Mirsky Editor April 2019 ASCII HTML 20

This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks.

draft-ietf-bfd-multipoint-active-tail-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bfd 10.17487/RFC8563
RFC8564 Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL) M. Zhang S. Pallagatti V. Govindan April 2019 ASCII HTML 8 data center network switch multicast

Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection of Lots of Links (TRILL). Similar to TRILL point-to-point BFD, BFD Control packets in TRILL P2MP BFD are transmitted using RBridge Channel messages. This document updates RFCs 7175 and 7177.

draft-ietf-trill-p2mp-bfd-09 RFC7175 RFC7177 PROPOSED STANDARD PROPOSED STANDARD IETF rtg trill 10.17487/RFC8564
RFC8565 Hypertext Jeopardy Protocol (HTJP/1.0) E. Fokschaner April 1 2019 ASCII HTML 11

The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.

draft-fokschaner-htjp-latest-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8565
RFC8567 Customer Management DNS Resource Records E. Rye R. Beverly April 1 2019 ASCII HTML 11

Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.

This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.

draft-ietf-cust-mgmt-dns-01 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8567
RFC8568 Network Virtualization Research Challenges CJ. Bernardos A. Rahman JC. Zuniga LM. Contreras P. Aranda P. Lynch April 2019 ASCII HTML 42

This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).

draft-irtf-nfvrg-gaps-network-virtualization-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8568
RFC8569 Content-Centric Networking (CCNx) Semantics M. Mosko I. Solis C. Wood July 2019 ASCII HTML 40 Content Centric Networking

This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.

The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.

This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.

draft-irtf-icnrg-ccnxsemantics-10 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC8569
RFC8570 IS-IS Traffic Engineering (TE) Metric Extensions L. Ginsberg Editor S. Previdi Editor S. Giacalone D. Ward J. Drake Q. Wu March 2019 ASCII HTML 21 IGP IS-IS

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.

This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.

Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.

This document obsoletes RFC 7810.

draft-ietf-lsr-isis-rfc7810bis-05 RFC7810 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8570
RFC8571 BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions L. Ginsberg Editor S. Previdi Q. Wu J. Tantsura C. Filsfils March 2019 ASCII HTML 10

This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.

draft-ietf-idr-te-pm-bgp-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8571
RFC8572 Secure Zero Touch Provisioning (SZTP) K. Watsen I. Farrer M. Abrahamsson April 2019 ASCII HTML 87 zerotouch bootstrap sztp ztp

This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.

draft-ietf-netconf-zerotouch-29 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8572 10.17487/RFC8572
RFC8573 Message Authentication Code for the Network Time Protocol A. Malhotra S. Goldberg June 2019 ASCII HTML 5 NTP

The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a 128-bit key and hashing the result with MD5 to obtain a 128-bit tag. This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement.

draft-ietf-ntp-mac-06 RFC5905 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC8573
RFC8574 cite-as: A Link Relation to Convey a Preferred URI for Referencing H. Van de Sompel M. Nelson G. Bilder J. Kunze S. Warner April 2019 ASCII HTML 17 persistent identifier PID

A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference.

draft-vandesompel-citeas-04 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8574 10.17487/RFC8574
RFC8575 YANG Data Model for the Precision Time Protocol (PTP) Y. Jiang Editor X. Liu J. Xu R. Cummings Editor May 2019 ASCII HTML 30

This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).

draft-ietf-tictoc-1588v2-yang-11 PROPOSED STANDARD PROPOSED STANDARD IETF int tictoc 10.17487/RFC8575
RFC8576 Internet of Things (IoT) Security: State of the Art and Challenges O. Garcia-Morchon S. Kumar M. Sethi April 2019 ASCII HTML 50 IoT Internet of Things M2M Machine-to-machine Machine-type communication MTC Security Privacy Trustworthy Lifecycle

The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.

This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).

draft-irtf-t2trg-iot-seccons-16 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8576
RFC8577 Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane H. Sitaraman V. Beeram T. Parikh T. Saad April 2019 ASCII HTML 24 Segment Routed RSVP-TE tunnels TE link labels RSVP-TE shared labels

As the scale of MPLS RSVP-TE networks has grown, the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.

However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.

This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled 'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs. This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane.

draft-ietf-mpls-rsvp-shared-labels-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls http://www.rfc-editor.org/errata_search.php?rfc=8577 10.17487/RFC8577
RFC8578 Deterministic Networking Use Cases E. Grossman Editor May 2019 ASCII HTML 97 DetNet AVB TSN SRP

This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.

draft-ietf-detnet-use-cases-20 INFORMATIONAL INFORMATIONAL IETF rtg detnet 10.17487/RFC8578
RFC8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes S. Bosch May 2019 ASCII HTML 12 sieve mailbox special-use

The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute.

draft-ietf-extra-sieve-special-use-05 PROPOSED STANDARD PROPOSED STANDARD IETF art extra http://www.rfc-editor.org/errata_search.php?rfc=8579 10.17487/RFC8579
RFC8580 Sieve Extension: File Carbon Copy (FCC) K. Murchison B. Gondwana May 2019 ASCII HTML 12 Sieve Vacation Notify

The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.

This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively.

draft-ietf-extra-sieve-fcc-09 RFC5230 RFC5435 PROPOSED STANDARD PROPOSED STANDARD IETF art extra 10.17487/RFC8580
RFC8581 Diameter Agent Overload and the Peer Overload Report S. Donovan August 2019 ASCII HTML 19 Diameter Overload

This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent.

draft-ietf-dime-agent-overload-11 RFC7683 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8581
RFC8582 Diameter Overload Rate Control S. Donovan Editor E. Noel August 2019 ASCII HTML 20 Diameter Overload

This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node.

draft-ietf-dime-doic-rate-control-11 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8582
RFC8583 Diameter Load Information Conveyance B. Campbell S. Donovan Editor JJ. Trottin August 2019 ASCII HTML 23 Diameter load

RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information.

draft-ietf-dime-load-09 PROPOSED STANDARD PROPOSED STANDARD IETF ops dime 10.17487/RFC8583
RFC8584 Framework for Ethernet VPN Designated Forwarder Election Extensibility J. Rabadan Editor S. Mohanty Editor A. Sajassi J. Drake K. Nagaraj S. Sathappan April 2019 ASCII HTML 32

An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is the Provider Edge (PE) router responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed Customer Edge (CE) device on a given VLAN on a particular Ethernet Segment (ES). In addition, the ability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite State Machine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432).

draft-ietf-bess-evpn-df-election-framework-09 RFC7432 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess http://www.rfc-editor.org/errata_search.php?rfc=8584 10.17487/RFC8584
RFC8585 Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service J. Palet Martinez H. M.-H. Liu M. Kawashima May 2019 ASCII HTML 21 IPv6 transition CE requirements IPv4aaS

This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.

Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.

draft-ietf-v6ops-transition-ipv4aas-15 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8585
RFC8586 Loop Detection in Content Delivery Networks (CDNs) S. Ludin M. Nottingham N. Sullivan April 2019 ASCII HTML 6 CDN-Loop,

This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop.

draft-ietf-httpbis-cdn-loop-02 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis http://www.rfc-editor.org/errata_search.php?rfc=8586 10.17487/RFC8586
RFC8587 NFS Version 4.0 Trunking Update C. Lever Editor D. Noveck May 2019 ASCII HTML 22 NFSv4.0 migration replication trunking fs_locations transparent state migration

In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530.

draft-ietf-nfsv4-mv0-trunking-update-05 RFC7530 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8587
RFC8588 Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) C. Wendt M. Barnes May 2019 ASCII HTML 9

This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network.

draft-ietf-stir-passport-shaken-08 PROPOSED STANDARD PROPOSED STANDARD IETF art stir 10.17487/RFC8588
RFC8589 The 'leaptofrogans' URI Scheme A. Tamas B. Phister Editor J-E. Rodriguez May 2019 ASCII HTML 9 Frogans leaptofrogans OP3FT URI scheme

This document describes the 'leaptofrogans' Uniform Resource Identifier (URI) scheme, which enables applications to launch Frogans Player on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites.

draft-op3ft-leaptofrogans-uri-scheme-07 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8589
RFC8590 Change Poll Extension for the Extensible Provisioning Protocol (EPP) J. Gould K. Feher May 2019 ASCII HTML 20

This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why.

draft-ietf-regext-change-poll-12 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8590
RFC8591 SIP-Based Messaging with S/MIME B. Campbell R. Housley April 2019 ASCII HTML 39 MSRP CPIM

Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFCs 3261, 3428, and 4975.

draft-campbell-sip-messaging-smime-05 RFC3261 RFC3428 RFC4975 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8591
RFC8592 Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH) R. Browne A. Chilikin T. Mizrahi May 2019 ASCII HTML 27 Timestamp Timestamping QoS service chain

This document describes methods of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.

draft-browne-sfc-nsh-kpi-stamp-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8592
RFC8593 Video Traffic Models for RTP Congestion Control Evaluations X. Zhu S. Mena Z. Sarker May 2019 ASCII HTML 19 Multimedia Congestion Control

This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model.

draft-ietf-rmcat-video-traffic-model-07 INFORMATIONAL INFORMATIONAL IETF tsv rmcat 10.17487/RFC8593
RFC8594 The Sunset HTTP Header Field E. Wilde May 2019 ASCII HTML 11

This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.

draft-wilde-sunset-header-11 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8594
RFC8595 An MPLS-Based Forwarding Plane for Service Function Chaining A. Farrel S. Bryant J. Drake June 2019 ASCII HTML 32 SFC MPLS Service Function Chaining NSH Network Service Header MPLS Multiprotocol Label Switching

This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.

draft-ietf-mpls-sfc-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8595
RFC8596 MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) A. Malis S. Bryant J. Halpern W. Henderickx June 2019 ASCII HTML 9 label label stack service function forwarder (SFF)

This document describes how to use a Service Function Forwarder (SFF) Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header (NSH) between an MPLS label stack and the packet original packet/ frame. This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network, and to select one of multiple SFFs in the destination MPLS node.

draft-ietf-mpls-sfc-encapsulation-04 INFORMATIONAL INFORMATIONAL IETF rtg mpls 10.17487/RFC8596
RFC8597 Cooperating Layered Architecture for Software-Defined Networking (CLAS) LM. Contreras CJ. Bernardos D. Lopez M. Boucadair P. Iovanna May 2019 ASCII HTML 21 SDN Control Programmability Intelligence Transport Service Flexibility Cooperation

Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.

This document describes an approach called Cooperating Layered Architecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path.

draft-contreras-layered-sdn-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8597
RFC8598 Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) T. Pauly P. Wouters May 2019 ASCII HTML 16 IKEv2 DNS

This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations.

draft-ietf-ipsecme-split-dns-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8598
RFC8599 Push Notification with the Session Initiation Protocol (SIP) C. Holmberg M. Arnold May 2019 ASCII HTML 40 SIP Push Notification

This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent (UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism.

draft-ietf-sipcore-sip-push-29 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8599
RFC8600 Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange N. Cam-Winget Editor S. Appala S. Pope P. Saint-Andre June 2019 ASCII HTML 28 publish subscribe pubsub grid iodef xmpp-grid information sharing

This document describes how to use the Extensible Messaging and Presence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication among Computer Security Incident Response Teams and associated entities. To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF).

draft-ietf-mile-xmpp-grid-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8600
RFC8601 Message Header Field for Indicating Message Authentication Status M. Kucherawy May 2019 ASCII HTML 54 DKIM SPF ATPS VBR Authentication Reputation

This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.

This document obsoletes RFC 7601.

draft-ietf-dmarc-rfc7601bis-06 RFC7601 PROPOSED STANDARD PROPOSED STANDARD IETF art dmarc http://www.rfc-editor.org/errata_search.php?rfc=8601 10.17487/RFC8601
RFC8602 Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses J. Arkko T. Hardie July 2019 ASCII HTML 3

This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.

This memo updates RFC 3219.

draft-arkko-trip-registry-update-01 RFC3219 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8602
RFC8603 Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile M. Jenkins L. Zieglar May 2019 ASCII HTML 13

This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

draft-jenkins-cnsa-cert-crl-profile-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8603
RFC8604 Interconnecting Millions of Endpoints with Segment Routing C. Filsfils Editor S. Previdi G. Dawra Editor W. Henderickx D. Cooper June 2019 ASCII HTML 11

This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document.

draft-filsfils-spring-large-scale-interconnect-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8604
RFC8605 vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP) S. Hollenbeck R. Carney May 2019 ASCII HTML 7 RDAP vCard

This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.

draft-hollenbeck-vcarddav-icann-rdap-extensions-01 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8605
RFC8606 ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field R. Jesske June 2019 ASCII HTML 7 Reason Call Location

The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose.

draft-ietf-sipcore-reason-q850-loc-07 RFC3326 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8606
RFC8607 Calendaring Extensions to WebDAV (CalDAV): Managed Attachments C. Daboo A. Quillaud K. Murchison Editor June 2019 ASCII HTML 34 CalDAV calendaring attachment ATTACH

This specification adds an extension to the Calendaring Extensions to WebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.

This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP.

draft-ietf-calext-caldav-attachments-04 INFORMATIONAL INFORMATIONAL IETF art calext 10.17487/RFC8607
RFC8608 BGPsec Algorithms, Key Formats, and Signature Formats S. Turner O. Borchert June 2019 ASCII HTML 21 BGPsec BGPsec Algorithms Crypto Algorithms ECDSA Cryptography

This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.

This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures.

draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05 RFC8208 RFC7935 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8608
RFC8609 Content-Centric Networking (CCNx) Messages in TLV Format M. Mosko I. Solis C. Wood July 2019 ASCII HTML 46

Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.

This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.

draft-irtf-icnrg-ccnxmessages-09 EXPERIMENTAL EXPERIMENTAL IRTF 10.17487/RFC8609
RFC8610 Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures H. Birkholz C. Vigano C. Bormann June 2019 ASCII HTML 64 binary format data interchange format description language schema language tree grammar

This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.

draft-ietf-cbor-cddl-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor http://www.rfc-editor.org/errata_search.php?rfc=8610 10.17487/RFC8610
RFC8611 Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces N. Akiya G. Swallow S. Litkowski B. Decraene J. Drake M. Chen June 2019 ASCII HTML 29 MPLS LSP Ping

This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).

This document updates RFC 8029.

draft-ietf-mpls-lsp-ping-lag-multipath-08 RFC8029 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8611
RFC8612 DDoS Open Threat Signaling (DOTS) Requirements A. Mortensen T. Reddy R. Moskowitz May 2019 ASCII HTML 22

This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.

draft-ietf-dots-requirements-22 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC8612
RFC8613 Object Security for Constrained RESTful Environments (OSCORE) G. Selander J. Mattsson F. Palombini L. Seitz July 2019 ASCII HTML 94

This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.

Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.

draft-ietf-core-object-security-16 RFC7252 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8613
RFC8614 Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) R. Singh K. Kompella S. Palislamovic June 2019 ASCII HTML 9

This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761.

draft-ietf-bess-bgp-vpls-control-flags-08 RFC4761 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8614
RFC8615 Well-Known Uniform Resource Identifiers (URIs) M. Nottingham May 2019 ASCII HTML 12

This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.

In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.

draft-nottingham-rfc5785bis-11 RFC5785 RFC7230 RFC7595 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8615
RFC8616 Email Authentication for Internationalized Mail J. Levine June 2019 ASCII HTML 6 email internationalization

Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail (DKIM) (RFC 6376), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS. In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications.

draft-ietf-dmarc-eaiauth-06 RFC6376 RFC7208 RFC7489 PROPOSED STANDARD PROPOSED STANDARD IETF art dmarc 10.17487/RFC8616
RFC8617 The Authenticated Received Chain (ARC) Protocol K. Andersen B. Long Editor S. Blank Editor M. Kucherawy Editor July 2019 ASCII HTML 35 DKIM DMARC signature email domian authentication email authentication

The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.

ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.

ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.

draft-ietf-dmarc-arc-protocol-23 EXPERIMENTAL EXPERIMENTAL IETF art dmarc 10.17487/RFC8617
RFC8618 Compacted-DNS (C-DNS): A Format for DNS Packet Capture J. Dickinson J. Hague S. Dickinson T. Manderson J. Bond September 2019 ASCII HTML 79 DNS

This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic- monitoring applications.

draft-ietf-dnsop-dns-capture-format-10 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8618
RFC8619 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) R. Housley June 2019 ASCII HTML 6 HKDF Algorithm Identifier

RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.

draft-housley-hkdf-oids-01 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8619
RFC8620 The JSON Meta Application Protocol (JMAP) N. Jenkins C. Newman July 2019 ASCII HTML 90 JMAP JSON

This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.

draft-ietf-jmap-core-17 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap http://www.rfc-editor.org/errata_search.php?rfc=8620 10.17487/RFC8620
RFC8621 The JSON Meta Application Protocol (JMAP) for Mail N. Jenkins C. Newman August 2019 ASCII HTML 108 JMAP JSON email

This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.

draft-ietf-jmap-mail-16 RFC5788 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC8621
RFC8622 A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services R. Bless June 2019 ASCII HTML 18 Lower Effort Per-Hop Behavior Scavenger Service

This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.

This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.

draft-ietf-tsvwg-le-phb-10 RFC3662 RFC4594 RFC8325 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8622
RFC8623 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) U. Palle D. Dhody Y. Tanaka V. Beeram June 2019 ASCII HTML 33

The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.

draft-ietf-pce-stateful-pce-p2mp-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8623
RFC8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC P. Wouters O. Sury June 2019 ASCII HTML 11

The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.

draft-ietf-dnsop-algorithm-update-10 RFC6944 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop http://www.rfc-editor.org/errata_search.php?rfc=8624 10.17487/RFC8624
RFC8625 Ethernet Traffic Parameters with Availability Information H. Long M. Ye Editor G. Mirsky Editor A. D'Alessandro H. Shah August 2019 ASCII HTML 13 GMPLS RSVP-TE microwave variable bandwidth link

A packet-switching network may contain links with variable bandwidths (e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning. This document introduces an optional Bandwidth Availability TLV in RSVP-TE signaling. This extension can be used to set up a GMPLS Label Switched Path (LSP) in conjunction with the Ethernet SENDER_TSPEC object.

draft-ietf-ccamp-rsvp-te-bandwidth-availability-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp 10.17487/RFC8625
RFC8627 RTP Payload Format for Flexible Forward Error Correction (FEC) M. Zanaty V. Singh A. Begen G. Mandyam July 2019 ASCII HTML 41 FEC forward error correction

This document defines new RTP payload formats for the Forward Error Correction (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX FEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.

draft-ietf-payload-flexible-fec-scheme-20 PROPOSED STANDARD PROPOSED STANDARD IETF art payload http://www.rfc-editor.org/errata_search.php?rfc=8627 10.17487/RFC8627
RFC8628 OAuth 2.0 Device Authorization Grant W. Denniss J. Bradley M. Jones H. Tschofenig August 2019 ASCII HTML 21 Security Area OAuth Security Authorization Smart Objects IoT Internet of Things Internet of Things Security OAuth for Constrained Devices OAuth IoT Security

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

draft-ietf-oauth-device-flow-15 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth http://www.rfc-editor.org/errata_search.php?rfc=8628 10.17487/RFC8628
RFC8629 Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension B. Cheng L. Berger Editor July 2019 ASCII HTML 10

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.

draft-ietf-manet-dlep-multi-hop-extension-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8629
RFC8630 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator G. Huston S. Weiler G. Michaelson S. Kent T. Bruijnzeels August 2019 ASCII HTML 11

This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.

This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.

draft-ietf-sidrops-https-tal-08 RFC7730 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8630
RFC8631 Link Relation Types for Web Services E. Wilde July 2019 ASCII HTML 10 API Documentation Description Metadata Status

Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status.

draft-wilde-service-link-rel-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8631
RFC8632 A YANG Data Model for Alarm Management S. Vallin M. Bjorklund September 2019 ASCII HTML 82 Monitoring Fault Management

This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.

draft-ietf-ccamp-alarm-module-09 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ccamp http://www.rfc-editor.org/errata_search.php?rfc=8632 10.17487/RFC8632
RFC8633 Network Time Protocol Best Current Practices D. Reilly H. Stenn D. Sibold July 2019 ASCII HTML 26 NTP

The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of best practices for the general operation of NTP servers and clients on the Internet. It includes recommendations for the stable, accurate, and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.

draft-ietf-ntp-bcp-13 BCP0223 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int ntp 10.17487/RFC8633
RFC8634 BGPsec Router Certificate Rollover B. Weis R. Gagliano K. Patel August 2019 ASCII HTML 11

Certification Authorities (CAs) within the Resource Public Key Infrastructure (RPKI) manage BGPsec router certificates as well as RPKI certificates. The rollover of BGPsec router certificates must be carefully performed in order to synchronize the distribution of router public keys with BGPsec UPDATE messages verified with those router public keys. This document describes a safe rollover process, and it discusses when and why the rollover of BGPsec router certificates is necessary. When this rollover process is followed, the rollover will be performed without routing information being lost.

draft-ietf-sidrops-bgpsec-rollover-04 BCP0224 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops sidrops 10.17487/RFC8634
RFC8635 Router Keying for BGPsec R. Bush S. Turner K. Patel August 2019 ASCII HTML 21

BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven.

draft-ietf-sidrops-rtr-keying-06 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8635
RFC8636 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility L. Hornquist Astrand L. Zhu M. Cullen G. Hudson July 2019 ASCII HTML 21

This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.

These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms.

draft-ietf-kitten-pkinit-alg-agility-08 RFC4556 PROPOSED STANDARD PROPOSED STANDARD IETF sec kitten 10.17487/RFC8636
RFC8637 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) D. Dhody Y. Lee D. Ceccarelli July 2019 ASCII HTML 22 PCE ACTN

Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.

The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).

This document examines the applicability of PCE to the ACTN framework.

draft-ietf-pce-applicability-actn-12 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8637
RFC8638 IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks M. Xu Y. Cui J. Wu S. Yang C. Metz September 2019 ASCII HTML 19 Multicast Mesh SSM ASM

During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.

This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ. The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario.

draft-ietf-softwire-mesh-multicast-25 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8638
RFC8639 Subscription to YANG Notifications E. Voit A. Clemm A. Gonzalez Prieto E. Nilsen-Nygaard A. Tripathy September 2019 ASCII HTML 77 telemetry YANG-Push

This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.

draft-ietf-netconf-subscribed-notifications-26 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf http://www.rfc-editor.org/errata_search.php?rfc=8639 10.17487/RFC8639
RFC8640 Dynamic Subscription to YANG Events and Datastores over NETCONF E. Voit A. Clemm A. Gonzalez Prieto E. Nilsen-Nygaard A. Tripathy September 2019 ASCII HTML 19 telemetry

This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

draft-ietf-netconf-netconf-event-notifications-22 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8640
RFC8641 Subscription to YANG Notifications for Datastore Updates A. Clemm E. Voit September 2019 ASCII HTML 58 YANG-Push Streaming telemetry

This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.

draft-ietf-netconf-yang-push-25 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8641
RFC8642 Policy Behavior for Well-Known BGP Communities J. Borkenhagen R. Bush R. Bonica S. Bayraktar August 2019 ASCII HTML 7 Operations Inter-Provider Communication

Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators. Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely, BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997.

draft-ietf-grow-wkc-behavior-08 RFC1997 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8642
RFC8643 An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) A. Johnston B. Aboba A. Hutton R. Jesske T. Stach August 2019 ASCII HTML 8 srtp opportunistic security encryption best effort osrtp

Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state.

draft-ietf-sipbrandy-osrtp-10 INFORMATIONAL INFORMATIONAL IETF art sipbrandy 10.17487/RFC8643
RFC8645 Re-keying Mechanisms for Symmetric Keys S. Smyshlyaev Editor August 2019 ASCII HTML 69 re-keying key key lifetime encryption mode mode of operation

A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM, CBC, CFB, and OMAC.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

draft-irtf-cfrg-re-keying-17 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8645
RFC8649 Hash Of Root Key Certificate Extension R. Housley August 2019 ASCII HTML 10 trust anchor

This document specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.

draft-ietf-lamps-hash-of-root-key-cert-extn-07 INFORMATIONAL INFORMATIONAL IETF sec lamps 10.17487/RFC8649
RFC8650 Dynamic Subscription to YANG Events and Datastores over RESTCONF E. Voit R. Rahman E. Nilsen-Nygaard A. Clemm A. Bierman November 2019 HTML TEXT PDF XML 23 YANG-Push

This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.

draft-ietf-netconf-restconf-notif-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netconf 10.17487/RFC8650
RFC8651 Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension B. Cheng D. Wiggins L. Berger Editor October 2019 HTML TEXT PDF XML 12 DLEP Flow control Pause

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router.

draft-ietf-manet-dlep-pause-extension-08 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8651
RFC8652 A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) X. Liu F. Guo M. Sivakumar P. McAllister A. Peter November 2019 HTML TEXT PDF XML 45 YANG IGMP MLD multicast data model ietf-igmp-mld network management routing

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices.

draft-ietf-pim-igmp-mld-yang-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8652
RFC8653 On-Demand Mobility Management A. Yegin D. Moses S. Jeon October 2019 HTML TEXT PDF XML 12

Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333. This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept.

draft-ietf-dmm-ondemand-mobility-18 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC8653
RFC8654 Extended Message Support for BGP R. Bush K. Patel D. Ward October 2019 HTML TEXT PDF XML 7 border gateway protocol address family identifiers afi

The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address Family Identifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages.

draft-ietf-idr-bgp-extended-messages-36 RFC4271 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8654
RFC8655 Deterministic Networking Architecture N. Finn P. Thubert B. Varga J. Farkas October 2019 HTML TEXT PDF XML 38 TSN Bounded Latency Reliable Networking Available Networking

This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.

draft-ietf-detnet-architecture-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg detnet 10.17487/RFC8655
RFC8656 Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) T. Reddy Editor A. Johnston Editor P. Matthews J. Rosenberg February 2020 HTML TEXT PDF XML 79 NAT TURN STUN ICE

If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.

The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.

This document obsoletes RFCs 5766 and 6156.

draft-ietf-tram-turnbis-29 RFC5766 RFC6156 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tram 10.17487/RFC8656
RFC8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding H. Landau November 2019 HTML TEXT PDF XML 11

The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities (CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by the Automatic Certificate Management Environment (ACME) protocol to be required.

draft-ietf-acme-caa-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8657
RFC8658 RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P) S. Jiang Editor Y. Fu Editor C. Xie T. Li M. Boucadair Editor November 2019 HTML TEXT PDF XML 34 IPv6 Transition MAP-E MAP-T Lightweight 4over6 RADIUS address sharing authorization AAA provisioning

IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.

This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.

draft-ietf-softwire-map-radius-26 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8658
RFC8659 DNS Certification Authority Authorization (CAA) Resource Record P. Hallam-Baker R. Stradling J. Hoffman-Andrews November 2019 HTML TEXT PDF XML 17 certificate ca pki issue issuance wildcard

The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by CAs.

This document obsoletes RFC 6844.

draft-ietf-lamps-rfc6844bis-07 RFC6844 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8659 10.17487/RFC8659
RFC8660 Segment Routing with the MPLS Data Plane A. Bashandy Editor C. Filsfils Editor S. Previdi B. Decraene S. Litkowski R. Shakir December 2019 HTML TEXT PDF XML 29 SR SR-MPLS

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).

draft-ietf-spring-segment-routing-mpls-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8660
RFC8661 Segment Routing MPLS Interworking with LDP A. Bashandy Editor C. Filsfils Editor S. Previdi B. Decraene S. Litkowski December 2019 HTML TEXT PDF XML 21 SR-MPLS

A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to the SR domain.

The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist.

draft-ietf-spring-segment-routing-ldp-interop-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg spring 10.17487/RFC8661
RFC8662 Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels S. Kini K. Kompella S. Sivabalan S. Litkowski R. Shakir J. Tantsura December 2019 HTML TEXT PDF XML 22 Flow-aware load balancing ECMP (equal-cost multipath)

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multiprotocol Label Switching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes how ELs are to be applied to Segment Routing MPLS.

draft-ietf-mpls-spring-entropy-label-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8662
RFC8663 MPLS Segment Routing over IP X. Xu S. Bryant A. Farrel S. Hassan W. Henderickx Z. Li December 2019 HTML TEXT PDF XML 17 SR-MPLS MPLS-in-UDP

MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.

This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP as defined in RFC 7510.

draft-ietf-mpls-sr-over-ip-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8663
RFC8664 Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing S. Sivabalan C. Filsfils J. Tantsura W. Henderickx J. Hardwick December 2019 HTML TEXT PDF XML 29 SR Traffic-Engineering PCE

Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.

This document updates RFC 8408.

draft-ietf-pce-segment-routing-16 RFC8408 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8664
RFC8665 OSPF Extensions for Segment Routing P. Psenak Editor S. Previdi Editor C. Filsfils H. Gredler R. Shakir W. Henderickx J. Tantsura December 2019 HTML TEXT PDF XML 25 MPLS SID IGP OSPF Label advertisement Segment Routing

Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).

This document describes the OSPFv2 extensions required for Segment Routing.

draft-ietf-ospf-segment-routing-extensions-27 PROPOSED STANDARD PROPOSED STANDARD IETF rtg ospf 10.17487/RFC8665
RFC8666 OSPFv3 Extensions for Segment Routing P. Psenak Editor S. Previdi Editor December 2019 HTML TEXT PDF XML 18 MPLS SID IGP OSPF Label advertisement Segment Routing

Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).

This document describes the OSPFv3 extensions required for Segment Routing with the MPLS data plane.

draft-ietf-ospf-ospfv3-segment-routing-extensions-23 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8666
RFC8667 IS-IS Extensions for Segment Routing S. Previdi Editor L. Ginsberg Editor C. Filsfils A. Bashandy H. Gredler B. Decraene December 2019 HTML TEXT PDF XML 28 MPLS SID IGP IS-IS Label advertisement Segment Routing

Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).

This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.

draft-ietf-isis-segment-routing-extensions-25 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8667
RFC8668 Advertising Layer 2 Bundle Member Link Attributes in IS-IS L. Ginsberg Editor A. Bashandy C. Filsfils M. Nanduri E. Aries December 2019 HTML TEXT PDF XML 17

There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.

This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members.

draft-ietf-isis-l2bundles-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg isis 10.17487/RFC8668
RFC8669 Segment Routing Prefix Segment Identifier Extensions for BGP S. Previdi C. Filsfils A. Lindem Editor A. Sreekantiah H. Gredler December 2019 HTML TEXT PDF XML 15 SR MPLS BGP Prefix-SID Label-Index SRGB

Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.

This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.

draft-ietf-idr-bgp-prefix-sid-27 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8669
RFC8670 BGP Prefix Segment in Large-Scale Data Centers C. Filsfils Editor S. Previdi G. Dawra E. Aries P. Lapukhov December 2019 HTML TEXT PDF XML 18 SR MSDC DC SRGB

This document describes the motivation for, and benefits of, applying Segment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both the MPLS and IPv6 data planes.

draft-ietf-spring-segment-routing-msdc-11 INFORMATIONAL INFORMATIONAL IETF rtg spring 10.17487/RFC8670
RFC8671 Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) T. Evens S. Bayraktar P. Lucente P. Mi S. Zhuang November 2019 HTML TEXT PDF XML 9 adj-rib-out

The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.

draft-ietf-grow-bmp-adj-rib-out-07 RFC7854 PROPOSED STANDARD PROPOSED STANDARD IETF ops grow 10.17487/RFC8671
RFC8672 TLS Server Identity Pinning with Tickets Y. Sheffer D. Migault October 2019 HTML TEXT PDF XML 22 transport layer security

Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.

This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.

draft-sheffer-tls-pinning-ticket-12 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8672
RFC8673 HTTP Random Access and Live Content C. Pratt D. Thakore B. Stark November 2019 HTML TEXT PDF XML 10 http range unit live aggregation

To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.

draft-ietf-httpbis-rand-access-live-04 EXPERIMENTAL EXPERIMENTAL IETF art httpbis 10.17487/RFC8673
RFC8674 The "safe" HTTP Preference M. Nottingham December 2019 HTML TEXT PDF XML 7 safe preference child-protection

This specification defines a preference for HTTP requests that expresses a desire to avoid objectionable content, according to the definition of that term by the origin server.

This specification does not define a precise semantic for "safe". Rather, the term is interpreted by the server and within the scope of each web site that chooses to act upon this information.

Support for this preference by clients and servers is optional.

draft-nottingham-safe-hint-11 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8674
RFC8675 A YANG Data Model for Tunnel Interface Types M. Boucadair I. Farrer R. Asati November 2019 HTML TEXT PDF XML 16 softwire Augment tunnel tunnel management tunnel provisioning tunnel activation tunnel automation

This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.

Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.

Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.

draft-ietf-softwire-iftunnel-07 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8675
RFC8676 YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires I. Farrer Editor M. Boucadair Editor November 2019 HTML TEXT PDF XML 46 A+P address sharing port set Port range IPv4 service continuity NETCONF RESTCONF Programmability Dynamic provisioning automation IPv6

This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.

draft-ietf-softwire-yang-16 PROPOSED STANDARD PROPOSED STANDARD IETF int softwire 10.17487/RFC8676
RFC8677 Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework D. Trossen D. Purkayastha A. Rahman November 2019 HTML TEXT PDF XML 24 service function SF SFF nSFF SFC SFP NSH FQDN 5G NSSAI CCNF NSSF 3GPP

Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.

This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.

draft-trossen-sfc-name-based-sff-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8677
RFC8678 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions F. Baker C. Bowers J. Linkova December 2019 HTML TEXT PDF XML 43

Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.

This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies. It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.

draft-ietf-rtgwg-enterprise-pa-multihoming-12 INFORMATIONAL INFORMATIONAL IETF rtg rtgwg 10.17487/RFC8678
RFC8679 MPLS Egress Protection Framework Y. Shen M. Jeganathan B. Decraene H. Gredler C. Michel H. Chen December 2019 HTML TEXT PDF XML 25 fast reroute egress protection local repair

This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.

draft-ietf-mpls-egress-protection-framework-07 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8679
RFC8680 Forward Error Correction (FEC) Framework Extension to Sliding Window Codes V. Roca A. Begen January 2020 HTML TEXT PDF XML 19 FEC FECFRAME packet loss recovery RLC Sliding Window FEC Codes

RFC 6363 describes a framework for using Forward Error Correction (FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency.

draft-ietf-tsvwg-fecframe-ext-08 RFC6363 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8680
RFC8681 Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME V. Roca B. Teibi January 2020 HTML TEXT PDF XML 37 RLC FEC FECFRAME packet loss recovery reliability

This document describes two fully specified Forward Erasure Correction (FEC) Schemes for Sliding Window Random Linear Codes (RLC), one for RLC over the Galois Field (a.k.a., Finite Field) GF(2), a second one for RLC over the Galois Field GF(2), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to Sliding Window FEC Codes. These Sliding Window FEC Codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages with real-time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities.

draft-ietf-tsvwg-rlc-fec-scheme-16 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8681
RFC8682 TinyMT32 Pseudorandom Number Generator (PRNG) M. Saito M. Matsumoto V. Roca Editor E. Baccelli January 2020 HTML TEXT PDF XML 12

This document describes the TinyMT32 Pseudorandom Number Generator (PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller Linear Congruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications.

draft-ietf-tsvwg-tinymt32-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8682
RFC8683 Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks J. Palet Martinez November 2019 HTML TEXT PDF XML 38 IPv6 DNSSEC NAT64 DNS64 464XLAT CLAT NAT46 PLAT

This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadband ISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications.

draft-ietf-v6ops-nat64-deployment-08 INFORMATIONAL INFORMATIONAL IETF ops v6ops 10.17487/RFC8683
RFC8684 TCP Extensions for Multipath Operation with Multiple Addresses A. Ford C. Raiciu M. Handley O. Bonaventure C. Paasch March 2020 HTML TEXT PDF XML 68 tcp extensions multipath multihomed subflow

TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.

Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.

This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.

draft-ietf-mptcp-rfc6824bis-18 RFC6824 PROPOSED STANDARD PROPOSED STANDARD IETF tsv mptcp 10.17487/RFC8684
RFC8685 Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture F. Zhang Q. Zhao O. Gonzalez de Dios R. Casellas D. King December 2019 HTML TEXT PDF XML 27 Traffic Engineering Inter-domain Multi-domain

The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.

This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures.

draft-ietf-pce-hierarchy-extensions-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8685
RFC8686 Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery S. Kiesel M. Stiemerling February 2020 HTML TEXT PDF XML 34 Application-Layer Traffic Optimization (ALTO) ALTO cross-domain server discovery ALTO third-party server discovery

The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers that can provide suitable guidance.

In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.

Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix.

draft-ietf-alto-xdom-disc-06 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8686
RFC8687 OSPF Routing with Cross-Address Family Traffic Engineering Tunnels A. Smirnov A. Retana M. Barnes November 2019 HTML TEXT PDF XML 8 OSPF IPv4 IPv6 TE MPLS

When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label Switched Path (LSP) infrastructure may be duplicated, even if the destination IPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross-address family (X-AF) OSPF TE information.

This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses.

draft-ietf-ospf-xaf-te-07 RFC5786 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8687
RFC8688 A Session Initiation Protocol (SIP) Response Code for Rejected Calls E.W. Burger B. Nagda December 2019 HTML TEXT PDF XML 22 STIR SIPCORE IANA

This document defines the 608 (Rejected) Session Initiation Protocol (SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked.

draft-ietf-sipcore-rejected-09 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8688
RFC8689 SMTP Require TLS Option J. Fenton November 2019 HTML TEXT PDF XML 16 SMTP

The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based Authentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant.

draft-ietf-uta-smtp-require-tls-09 PROPOSED STANDARD PROPOSED STANDARD IETF art uta 10.17487/RFC8689
RFC8690 Clarification of Segment ID Sub-TLV Length for RFC 8287 N. Nainar C. Pignataro F. Iqbal A. Vainshtein December 2019 HTML TEXT PDF XML 7 mpls

RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.

This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.

draft-ietf-mpls-rfc8287-len-clarification-04 RFC8287 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8690
RFC8691 Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 N. Benamar J. Härri J. Lee T. Ernst December 2019 HTML TEXT PDF XML 29 IPv6 over 802.11p OCB IPv6 over 802.11-OCB

This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work.

draft-ietf-ipwave-ipv6-over-80211ocb-52 PROPOSED STANDARD PROPOSED STANDARD IETF int ipwave 10.17487/RFC8691
RFC8692 Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs P. Kampanakis Q. Dang December 2019 HTML TEXT PDF XML 14 SHAKE in X.509 SHAKEs in PKIX certificates with SHAKE hashes

Digital signatures are used to sign messages, X.509 certificates, and Certificate Revocation Lists (CRLs). This document updates the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature and Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described.

draft-ietf-lamps-pkix-shake-15 RFC3279 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8692
RFC8693 OAuth 2.0 Token Exchange M. Jones A. Nadalin B. Campbell Editor J. Bradley C. Mortimore January 2020 HTML TEXT PDF XML 27 JSON Web Token JWT Delegation Impersonation STS Security Token Service Exchange Token OAuth

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

draft-ietf-oauth-token-exchange-19 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8693
RFC8694 Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering D. King H. Zheng December 2019 HTML TEXT PDF XML 24

The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.

This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks.

draft-ietf-pce-inter-area-as-applicability-08 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8694
RFC8695 A YANG Data Model for the Routing Information Protocol (RIP) X. Liu P. Sarda V. Choudhary February 2020 HTML TEXT PDF XML 40 YANG RIP RIPng data model ietf-rip network management routing

This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).

draft-ietf-rtgwg-yang-rip-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg rtgwg 10.17487/RFC8695
RFC8696 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) R. Housley December 2019 HTML TEXT PDF XML 31 quantum-resistant

The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.

draft-ietf-lamps-cms-mix-with-psk-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8696
RFC8697 Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) I. Minei E. Crabbe S. Sivabalan H. Ananthakrishnan D. Dhody Y. Tanaka January 2020 HTML TEXT PDF XML 28 PCE PCEP Association Group

This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.

draft-ietf-pce-association-group-10 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8697
RFC8698 Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media X. Zhu R. Pan M. Ramalho S. Mena February 2020 HTML TEXT PDF XML 26 Multimedia Congestion Control

This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead.

draft-ietf-rmcat-nada-13 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8698
RFC8699 Coupled Congestion Control for RTP Media S. Islam M. Welzl S. Gjessing January 2020 HTML TEXT PDF XML 20 tcp

When multiple congestion-controlled Real-time Transport Protocol (RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms.

draft-ietf-rmcat-coupled-cc-09 EXPERIMENTAL EXPERIMENTAL IETF tsv rmcat 10.17487/RFC8699
RFC8700 Fifty Years of RFCs H. Flanagan Editor December 2019 HTML TEXT PDF XML 22 History RFC Series Retrospective

This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540.

draft-iab-fiftyyears-01 RFC2555 RFC5540 INFORMATIONAL INFORMATIONAL IAB http://www.rfc-editor.org/errata_search.php?rfc=8700 10.17487/RFC8700
RFC8701 Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility D. Benjamin January 2020 HTML TEXT PDF XML 12 TLS GREASE

This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.

draft-ietf-tls-grease-04 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC8701
RFC8702 Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) P. Kampanakis Q. Dang January 2020 HTML TEXT PDF XML 16 SHAKEs in CMS SHAKE CMS with SHAKEs

This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described.

draft-ietf-lamps-cms-shakes-18 RFC3370 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps http://www.rfc-editor.org/errata_search.php?rfc=8702 10.17487/RFC8702
RFC8703 Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension R. Taylor S. Ratliff February 2020 HTML TEXT PDF XML 9 DLEP MANET Link-Aware Radio-Aware

The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC 8175) assumes that every modem in the radio network has an attached DLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.

This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain.

draft-ietf-manet-dlep-lid-extension-06 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8703
RFC8704 Enhanced Feasible-Path Unicast Reverse Path Forwarding K. Sriram D. Montgomery J. Haas February 2020 HTML TEXT PDF XML 17 BGP source address spoofing source address validation SAV Reverse Path Forwarding RPF unicast RPF uRPF DDoS mitigation BCP 38 BCP 84

This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704.

draft-ietf-opsec-urpf-improvements-04 RFC3704 BCP0084 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops opsec 10.17487/RFC8704
RFC8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens B. Campbell J. Bradley N. Sakimura T. Lodderstedt February 2020 HTML TEXT PDF XML 24 JSON Web Token JWT MTLS Mutual TLS proof-of-possession proof-of-possession access token key confirmed access token certificate-bound access token client certificate X.509 Client Certificate Authentication key confirmation confirmation method holder-of-key OAuth

This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.

draft-ietf-oauth-mtls-17 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8705
RFC8706 Restart Signaling for IS-IS L. Ginsberg P. Wells February 2020 HTML TEXT PDF XML 22 IGP graceful restart

This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.

This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.

This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.

This document obsoletes RFC 5306.

draft-ietf-lsr-isis-rfc5306bis-09 RFC5306 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8706
RFC8707 Resource Indicators for OAuth 2.0 B. Campbell J. Bradley H. Tschofenig February 2020 HTML TEXT PDF XML 11 OAuth Resource Audience

This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

draft-ietf-oauth-resource-indicators-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec oauth 10.17487/RFC8707
RFC8708 Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) R. Housley February 2020 HTML TEXT PDF XML 14 digital signature message content

This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

draft-ietf-lamps-cms-hash-sig-10 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8708
RFC8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol B. Harris L. Velvindron February 2020 HTML TEXT PDF XML 7

This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.

draft-ietf-curdle-ssh-ed25519-ed448-11 RFC4253 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle http://www.rfc-editor.org/errata_search.php?rfc=8709 10.17487/RFC8709
RFC8710 Multipart Content-Format for the Constrained Application Protocol (CoAP) T. Fossati K. Hartke C. Bormann February 2020 HTML TEXT PDF XML 9 CoAP Multipart Content-Format

This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.

draft-ietf-core-multipart-ct-04 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8710
RFC8711 Structure of the IETF Administrative Support Activity, Version 2.0 B. Haberman J. Hall J. Livingood February 2020 HTML TEXT PDF XML 22 IASA IASA2

The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.

This document obsoletes RFC 4071, RFC 4333, and RFC 7691.

draft-ietf-iasa2-rfc4071bis-11 RFC4071 RFC4333 RFC7691 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8711
RFC8712 The IETF-ISOC Relationship G. Camarillo J. Livingood February 2020 HTML TEXT PDF XML 8 IASA

This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.

draft-ietf-iasa2-rfc2031bis-08 RFC2031 INFORMATIONAL INFORMATIONAL IETF gen iasa2 10.17487/RFC8712
RFC8713 IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees M. Kucherawy Editor R. Hinden Editor J. Livingood Editor February 2020 HTML TEXT PDF XML 33 IASA IASA 2.0 IASA2

The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.

This document obsoletes RFC 7437 and RFC 8318.

draft-ietf-iasa2-rfc7437bis-09 RFC7437 RFC8318 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8713
RFC8714 Update to the Process for Selection of Trustees for the IETF Trust J. Arkko T. Hardie February 2020 HTML TEXT PDF XML 6

This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.

This memo obsoletes RFC 4371. The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.

draft-ietf-iasa2-trust-update-03 RFC4371 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8714
RFC8715 IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust J. Arkko February 2020 HTML TEXT PDF XML 6 IETF administration intellectual property leadership selection IASA

This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust".

At the time RFC 8714 was published, the changes to the IETF Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update.

draft-ietf-iasa2-trust-rationale-03 INFORMATIONAL INFORMATIONAL IETF gen iasa2 10.17487/RFC8715
RFC8716 Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC P. Resnick A. Farrel February 2020 HTML TEXT PDF XML 7 Harassment Ombudsteam IAOC IETF Administration LLC

The IETF Anti-Harassment Procedures are described in RFC 7776.

The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.

RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.

draft-ietf-iasa2-rfc7776bis-03 RFC7776 BCP0025 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8716
RFC8717 IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology J. Klensin Editor February 2020 HTML TEXT PDF XML 7 IASA IASA2

In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.

draft-ietf-iasa2-consolidated-upd-07 RFC2028 RFC2418 RFC3005 RFC3710 RFC3929 RFC4633 RFC6702 BCP0101 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen iasa2 10.17487/RFC8717
RFC8718 IETF Plenary Meeting Venue Selection Process E. Lear Editor February 2020 HTML TEXT PDF XML 10 Meeting Venues Meeting selection process IASA

The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process.

draft-ietf-mtgvenue-iaoc-venue-selection-process-16 BCP0226 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen mtgvenue 10.17487/RFC8718
RFC8719 High-Level Guidance for the Meeting Policy of the IETF S. Krishnan February 2020 HTML TEXT PDF XML 5 geographic distribution location IASA

This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.

draft-ietf-mtgvenue-meeting-policy-07 BCP0226 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF gen mtgvenue 10.17487/RFC8719
RFC8720 Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries R. Housley Editor O. Kolkman Editor February 2020 HTML TEXT PDF XML 7 IASA

This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

draft-iab-rfc7500-bis-00 RFC7500 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8720
RFC8721 Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents J. Halpern Editor February 2020 HTML TEXT PDF XML 8 IASA Trust

Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).

draft-ietf-iasa2-rfc5377bis-03 RFC5377 INFORMATIONAL INFORMATIONAL IETF gen iasa2 10.17487/RFC8721
RFC8722 Defining the Role and Function of IETF Protocol Parameter Registry Operators D. McPherson Editor O. Kolkman Editor J. Klensin Editor G. Huston Editor February 2020 HTML TEXT PDF XML 11 IANA Governance

Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.

draft-ietf-iasa2-rfc6220bis-04 RFC6220 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8722
RFC8723 Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) C. Jennings P. Jones R. Barnes A.B. Roach April 2020 HTML TEXT PDF XML 18 PERC SRTP RTP conferencing encryption

In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.

draft-ietf-perc-double-12 PROPOSED STANDARD PROPOSED STANDARD IETF art perc 10.17487/RFC8723
RFC8724 SCHC: Generic Framework for Static Context Header Compression and Fragmentation A. Minaburo L. Toutain C. Gomez D. Barthel JC. Zúñiga April 2020 HTML TEXT PDF XML 71 header compression compression fragmentation static context rule-based LPWAN LPWANs low power low-power 6LoWPAN 6lo LoWPAN LoWPANs LLN LLNs LTN LTE LTE-M Sigfox LoRaWAN NB-IOT 5G IoT Internet of Things adaptation layer UDP IPv6 WSN Sensor network wireless sensor network 802.15.4 contrained network constrained node constrained-node network

This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.

SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.

This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.

The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.

draft-ietf-lpwan-ipv6-static-context-hc-24 PROPOSED STANDARD PROPOSED STANDARD IETF int lpwan 10.17487/RFC8724
RFC8725 JSON Web Token Best Current Practices Y. Sheffer D. Hardt M. Jones February 2020 HTML TEXT PDF XML 13 JSON Web Token JWT JSON Object Signing and Encryption JOSE JSON Web Signature JWS JSON Web Encryption JWE attacks Claims Security Cryptography

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

draft-ietf-oauth-jwt-bcp-07 RFC7519 BCP0225 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec oauth 10.17487/RFC8725
RFC8726 How Requests for IANA Action Will Be Handled on the Independent Stream A. Farrel November 2020 HTML TEXT PDF XML 6 IANA Independent Submissions Stream ISE

The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.

The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE).

This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submission Stream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.

draft-ise-iana-policy-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8726
RFC8727 JSON Binding of the Incident Object Description Exchange Format T. Takahashi R. Danyliw M. Suzuki August 2020 HTML TEXT PDF XML 88 CBOR JSON IODEF

The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).

draft-ietf-mile-jsoniodef-14 PROPOSED STANDARD PROPOSED STANDARD IETF sec mile 10.17487/RFC8727
RFC8728 RFC Editor Model (Version 2) O. Kolkman Editor J. Halpern Editor R. Hinden Editor February 2020 HTML TEXT PDF XML 19 IAB IASA RSOC RSE IASA IASA2

The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.

draft-ietf-iasa2-rfc6635bis-04 RFC6635 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8728
RFC8729 The RFC Series and RFC Editor R. Housley Editor L. Daigle Editor February 2020 HTML TEXT PDF XML 18 IASA IASA2 technical publisher

This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.

draft-ietf-iasa2-rfc4844-bis-05 RFC4844 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8729
RFC8730 Independent Submission Editor Model N. Brownlee Editor B. Hinden Editor February 2020 HTML TEXT PDF XML 6 ISE RSE LLC IAB IASA

This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).

This version obsoletes RFC 6548 to replace all references to the Internet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure.

draft-ietf-iasa2-rfc6548bis-02 RFC6548 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8730
RFC8731 Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 A. Adamantiadis S. Josefsson M. Baushke February 2020 HTML TEXT PDF XML 6 Elliptic Curve Diffie Hellman ECDH

This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.

draft-ietf-curdle-ssh-curves-12 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8731
RFC8732 Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 S. Sorce H. Kario February 2020 HTML TEXT PDF XML 12 SSH

This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges.

draft-ietf-curdle-gss-keyex-sha2-10 RFC4462 PROPOSED STANDARD PROPOSED STANDARD IETF sec curdle 10.17487/RFC8732
RFC8733 Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE D. Dhody Editor R. Gandhi Editor U. Palle R. Singh L. Fang February 2020 HTML TEXT PDF XML 32 Bandwidth optimization PCEP Overwhelm LSP re-optimization

The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.

The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.

draft-ietf-pce-stateful-pce-auto-bandwidth-12 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8733
RFC8734 Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3 L. Bruckert J. Merkle M. Lochter February 2020 HTML TEXT PDF XML 11 TLS Elliptic Curve Cryptography

Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS 1.3.

This document provides the necessary protocol mechanisms for using ECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF.

draft-bruckert-brainpool-for-tls13-07 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8734
RFC8735 Scenarios and Simulation Results of PCE in a Native IP Network A. Wang X. Huang C. Kou Z. Li P. Mi February 2020 HTML TEXT PDF XML 16 CCDR Traffic Engineering

Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.

One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying the Path Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios.

draft-ietf-teas-native-ip-scenarios-12 INFORMATIONAL INFORMATIONAL IETF rtg teas 10.17487/RFC8735
RFC8736 PIM Message Type Space Extension and Reserved Bits S. Venaas A. Retana February 2020 HTML TEXT PDF XML 8 Multicast

The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.

This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.

This document obsoletes RFC 6166.

draft-ietf-pim-reserved-bits-04 RFC6166 RFC3973 RFC5015 RFC5059 RFC6754 RFC7761 RFC8364 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8736
RFC8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension R.B. Shoemaker February 2020 HTML TEXT PDF XML 8 acme pki

This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.

draft-ietf-acme-tls-alpn-07 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8737
RFC8738 Automated Certificate Management Environment (ACME) IP Identifier Validation Extension R.B. Shoemaker February 2020 HTML TEXT PDF XML 5

This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.

draft-ietf-acme-ip-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8738
RFC8739 Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) Y. Sheffer D. Lopez O. Gonzalez de Dios A. Pastor Perales T. Fossati March 2020 HTML TEXT PDF XML 22 OCSP CRL revocation

Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.

draft-ietf-acme-star-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec acme 10.17487/RFC8739
RFC8740 Using TLS 1.3 with HTTP/2 D. Benjamin February 2020 HTML TEXT PDF XML 5 HTTP renegotiation post-handshake client authentication

This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.

draft-ietf-httpbis-http2-tls13-03 RFC7540 PROPOSED STANDARD PROPOSED STANDARD IETF art httpbis 10.17487/RFC8740
RFC8741 Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) A. Raghuram A. Goddard J. Karthik S. Sivabalan M. Negi March 2020 HTML TEXT PDF XML 11

A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.

There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.

This document describes an extension to the Path Computation Element Communication Protocol (PCEP) to enable a PCE to make requests for such control.

draft-ietf-pce-lsp-control-request-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8741
RFC8742 Concise Binary Object Representation (CBOR) Sequences C. Bormann February 2020 HTML TEXT PDF XML 10 binary format data interchange format JSON

This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.

Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.

draft-ietf-cbor-sequence-02 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8742
RFC8743 Multiple Access Management Services Multi-Access Management Services (MAMS) S. Kanugovi F. Baboescu J. Zhu S. Seo March 2020 HTML TEXT PDF XML 143 Integration Aggregation Switching MPTCP MPQUIC GMA 5G LTE Wi-Fi Ethernet Edge Proxy

In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.

This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.

This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance.

draft-kanugovi-intarea-mams-framework-04 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8743
RFC8744 Issues and Requirements for Server Name Identification (SNI) Encryption in TLS C. Huitema July 2020 HTML TEXT PDF XML 13

This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.

In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.

draft-ietf-tls-sni-encryption-09 INFORMATIONAL INFORMATIONAL IETF sec tls 10.17487/RFC8744
RFC8745 Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE H. Ananthakrishnan S. Sivabalan C. Barth I. Minei M. Negi March 2020 HTML TEXT PDF XML 15 PCEP

An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.

draft-ietf-pce-stateful-path-protection-11 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8745
RFC8746 Concise Binary Object Representation (CBOR) Tags for Typed Arrays C. Bormann Editor February 2020 HTML TEXT PDF XML 13 binary format data interchange format JSON

The Concise Binary Object Representation (CBOR), as defined in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

This document makes use of this extensibility to define a number of CBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined.

draft-ietf-cbor-array-tags-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8746
RFC8747 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) M. Jones L. Seitz G. Selander S. Erdtman H. Tschofenig March 2020 HTML TEXT PDF XML 14 CBOR Web Token CWT Proof-of-Possession Holder-of-Key

This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).

draft-ietf-ace-cwt-proof-of-possession-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ace 10.17487/RFC8747
RFC8748 Registry Fee Extension for the Extensible Provisioning Protocol (EPP) R. Carney G. Brown J. Frakes March 2020 HTML TEXT PDF XML 30

Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method for Extensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees.

draft-ietf-regext-epp-fees-20 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8748
RFC8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status W. Mekking D. Mahoney March 2020 HTML TEXT PDF XML 6 DNS DNSSEC DLV

This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.

draft-ietf-dnsop-obsolete-dlv-02 RFC6698 RFC6840 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8749
RFC8750 Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) D. Migault T. Guggemos Y. Nir March 2020 HTML TEXT PDF XML 8 IKE IPsec GCM CCM ChaCha20

Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.

draft-ietf-ipsecme-implicit-iv-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8750
RFC8751 Hierarchical Stateful Path Computation Element (PCE) D. Dhody Y. Lee D. Ceccarelli J. Shin D. King March 2020 HTML TEXT PDF XML 21

A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.

The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.

Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture.

draft-ietf-pce-stateful-hpce-15 INFORMATIONAL INFORMATIONAL IETF rtg pce 10.17487/RFC8751
RFC8752 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) M. Thomson M. Nottingham March 2020 HTML TEXT PDF XML 23 web security origin packaging bundle

The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

draft-iab-escape-report-00 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8752
RFC8753 Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions J. Klensin P. Fältström April 2020 HTML TEXT PDF XML 13 IDNA2008 IDN Unicode Algorithmic Review Unicode Code Point Review IDNA Designated Expert

The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.

draft-klensin-idna-unicode-review-05 RFC5892 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8753
RFC8754 IPv6 Segment Routing Header (SRH) C. Filsfils Editor D. Dukes Editor S. Previdi J. Leddy S. Matsushima D. Voyer March 2020 HTML TEXT PDF XML 27 SRv6 source-routing network-programming

Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.

draft-ietf-6man-segment-routing-header-26 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8754
RFC8755 Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions M. Jenkins March 2020 HTML TEXT PDF XML 17 NSA CNSA NSS smime

The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

draft-jenkins-cnsa-smime-profile-03 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8755
RFC8756 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS M. Jenkins L. Zieglar March 2020 HTML TEXT PDF XML 17 NSA CNSA NSS certificate enrollment

This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government.

The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.

The profile is made publicly available here for use by developers and operators of these and any other system deployments.

draft-jenkins-cnsa-cmc-profile-05 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8756
RFC8757 Dynamic Link Exchange Protocol (DLEP) Latency Range Extension B. Cheng L. Berger Editor March 2020 HTML TEXT PDF XML 5 MANET

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the range of latency that can be experienced on a link.

draft-ietf-manet-dlep-latency-extension-05 PROPOSED STANDARD PROPOSED STANDARD IETF rtg manet 10.17487/RFC8757
RFC8758 Deprecating RC4 in Secure Shell (SSH) L. Velvindron April 2020 HTML TEXT PDF XML 5

This document deprecates RC4 in Secure Shell (SSH). Therefore, this document formally moves RFC 4345 to Historic status.

draft-ietf-curdle-rc4-die-die-die-18 RFC4253 BCP0227 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF sec curdle 10.17487/RFC8758
RFC8759 RTP Payload for Timed Text Markup Language (TTML) J. Sandford March 2020 HTML TEXT PDF XML 15 subtitles captions imsc media streaming sdp xml

This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML.

draft-ietf-payload-rtp-ttml-06 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8759
RFC8760 The Session Initiation Protocol (SIP) Digest Access Authentication Scheme R. Shekh-Yusef March 2020 HTML TEXT PDF XML 9 Digest Auth

This document updates RFC 3261 by modifying the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 and SHA-512/256, to replace the obsolete MD5 algorithm.

draft-ietf-sipcore-digest-scheme-15 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8760
RFC8761 Video Codec Requirements and Evaluation Methodology A. Filippov A. Norkin J.R. Alvarez April 2020 HTML TEXT PDF XML 22 NETVC evaluation requirements compression performance video coding applications

This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.

draft-ietf-netvc-requirements-10 INFORMATIONAL INFORMATIONAL IETF art netvc 10.17487/RFC8761
RFC8762 Simple Two-Way Active Measurement Protocol G. Mirsky G. Jun H. Nydell R. Foote March 2020 HTML TEXT PDF XML 15

This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.

draft-ietf-ippm-stamp-10 PROPOSED STANDARD PROPOSED STANDARD IETF tsv ippm 10.17487/RFC8762
RFC8763 Deployment Considerations for Information-Centric Networking (ICN) A. Rahman D. Trossen D. Kutscher R. Ravindran April 2020 HTML TEXT PDF XML 30 routing Content Delivery Network (CDN) overlay underlay virtual virtualization naming NFV SDN

Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-Centric Networking Research Group (ICNRG).

draft-irtf-icnrg-deployment-guidelines-07 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8763
RFC8764 Apple's DNS Long-Lived Queries Protocol S. Cheshire M. Krochmal June 2020 HTML TEXT PDF XML 20 Async Asynchronous Change Notification Push Notification

Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending the DNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From 2005 onwards, LLQ was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765, "DNS Push Notifications", which builds on experience gained with the LLQ protocol to create a superior replacement.

The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS Push Notifications.

draft-sekar-dns-llq-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8764
RFC8765 DNS Push Notifications T. Pusateri S. Cheshire June 2020 HTML TEXT PDF XML 32 dns update push notification

The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications.

draft-ietf-dnssd-push-25 PROPOSED STANDARD PROPOSED STANDARD IETF int dnssd 10.17487/RFC8765
RFC8766 Discovery Proxy for Multicast DNS-Based Service Discovery S. Cheshire June 2020 HTML TEXT PDF XML 33 Multicast DNS DNS-Based Service Discovery

This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link.

draft-ietf-dnssd-hybrid-10 PROPOSED STANDARD PROPOSED STANDARD IETF int dnssd 10.17487/RFC8766
RFC8767 Serving Stale Data to Improve DNS Resiliency D. Lawrence W. Kumari P. Sood March 2020 HTML TEXT PDF XML 12 DNS DDoS Resiliency Denial-of-Service Expired

This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days.

draft-ietf-dnsop-serve-stale-10 RFC1034 RFC1035 RFC2181 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8767
RFC8768 Constrained Application Protocol (CoAP) Hop-Limit Option M. Boucadair T. Reddy.K J. Shallow March 2020 HTML TEXT PDF XML 8 security mitigation service delivery connectivity anti-DDoS automation cooperation Resilience Filtering Security Center Mitigator Scrubbing dynamic service protection dynamic mitigation

The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.

draft-ietf-core-hop-limit-07 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8768
RFC8769 Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR) J. Schaad March 2020 HTML TEXT PDF XML 6

Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding. The Cryptographic Message Syntax (CMS) is still a widely used method of doing message-based security. This document defines a set of content types for CMS that hold CBOR content.

draft-schaad-cbor-content-02 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8769
RFC8770 Host Router Support for OSPFv2 K. Patel P. Pillay-Esnault M. Bhardwaj S. Bayraktar April 2020 HTML TEXT PDF XML 8 non-transit

The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit (H-bit). This bit enables a router to advertise that it is a non-transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.

draft-ietf-ospf-ospfv2-hbit-12 RFC6987 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8770
RFC8771 The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO) A. Mayrhofer J. Hague April 1 2020 HTML TEXT PDF XML 10

Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.

draft-mayrhofer-i-dunno-02 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8771
RFC8772 The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP) S. Hu D. Eastlake F. Qin T. Chua D. Huang May 2020 HTML TEXT PDF XML 124 CUPS CUSP BRAS BBRAS

A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP). China Mobile, Huawei Technologies, and ZTE have developed a simple CUPS control channel protocol to support such communication: the Simple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.

This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability.

draft-chz-simple-cu-separation-bng-protocol-06 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8772
RFC8773 TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key R. Housley March 2020 HTML TEXT PDF XML 11

This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK).

draft-ietf-tls-tls13-cert-with-extern-psk-07 EXPERIMENTAL EXPERIMENTAL IETF sec tls 10.17487/RFC8773
RFC8774 The Quantum Bug M. Welzl April 1 2020 HTML TEXT PDF XML 6 Teleportation Entanglement 0-RTT

The age of quantum networking is upon us, and with it comes "entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on some Internet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.

draft-welzl-quantumbug-00 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8774 10.17487/RFC8774
RFC8775 PIM Designated Router Load Balancing Y. Cai H. Ou S. Vallepalli M. Mishra S. Venaas A. Green April 2020 HTML TEXT PDF XML 18 Multicast

On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to the PIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers.

draft-ietf-pim-drlb-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8775
RFC8776 Common YANG Data Types for Traffic Engineering T. Saad R. Gandhi X. Liu V. Beeram I. Bryskin June 2020 HTML TEXT PDF XML 84 TE Tunnel TE Model TE Types TE YANG TE Topology TE Interfaces TE LSP Model

This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.

draft-ietf-teas-yang-te-types-13 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8776
RFC8777 DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery J. Holland April 2020 HTML TEXT PDF XML 33 DRIAD DRYAD AMT IGMPv3 MLDv2 SSM amt gateway amt relay multicast multicast replication multicast encapsulation amt relay discovery amt discovery AMTRELAY

This document updates RFC 7450, "Automatic Multicast Tunneling" (or AMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined.

draft-ietf-mboned-driad-amt-discovery-13 RFC7450 PROPOSED STANDARD PROPOSED STANDARD IETF ops mboned http://www.rfc-editor.org/errata_search.php?rfc=8777 10.17487/RFC8777
RFC8778 Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) R. Housley April 2020 HTML TEXT PDF XML 15 digital signature HSS/LMS Hash-based Signature Algorithm

This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

draft-ietf-cose-hash-sig-09 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose 10.17487/RFC8778
RFC8779 Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS C. Margaria Editor O. Gonzalez de Dios Editor F. Zhang Editor July 2020 HTML TEXT PDF XML 38 RSVP-TE GMPLS PCE

A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025.

This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.

draft-ietf-pce-gmpls-pcep-extensions-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8779
RFC8780 The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) Y. Lee Editor R. Casellas Editor July 2020 HTML TEXT PDF XML 26 Wavelength Allocation Transparent Optical Networks Fixed DWDM Grid

This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs). Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.

draft-ietf-pce-wson-rwa-ext-17 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8780
RFC8781 Discovering PREF64 in Router Advertisements L. Colitti J. Linkova April 2020 HTML TEXT PDF XML 10

This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.

draft-ietf-6man-ra-pref64-09 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8781
RFC8782 Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification T. Reddy.K Editor M. Boucadair Editor P. Patil A. Mortensen N. Teague May 2020 HTML TEXT PDF XML 100 security mitigation service delivery connectivity anti-DDoS automation cooperation resilience filtering security center mitigator scrubbing dynamic service protection dynamic mitigation cooperative networking protective networking

This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.

A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.

draft-ietf-dots-signal-channel-41 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots 10.17487/RFC8782
RFC8783 Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification M. Boucadair Editor T. Reddy.K Editor May 2020 HTML TEXT PDF XML 66 DOTS Automation Security Mitigation Scrubbing Anti-DDoS Mitigator Security Center Filtering Resilience RESTCONF

The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.

This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).

draft-ietf-dots-data-channel-31 PROPOSED STANDARD PROPOSED STANDARD IETF sec dots 10.17487/RFC8783
RFC8784 Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security S. Fluhrer P. Kampanakis D. McGrew V. Smyslov June 2020 HTML TEXT PDF XML 16 internet key exchange quantum computer post quantum post-quantum quantum safe quantum secure quantum resistant

The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.

draft-ietf-ipsecme-qr-ikev2-11 PROPOSED STANDARD PROPOSED STANDARD IETF sec ipsecme 10.17487/RFC8784
RFC8785 JSON Canonicalization Scheme (JCS) A. Rundgren B. Jordan S. Erdtman June 2020 HTML TEXT PDF XML 20 JSON ECMAScript Signatures Cryptography Canonicalization

Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.

This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting.

draft-rundgren-json-canonicalization-scheme-17 INFORMATIONAL INFORMATIONAL INDEPENDENT http://www.rfc-editor.org/errata_search.php?rfc=8785 10.17487/RFC8785
RFC8786 Updated Rules for Processing Stateful PCE Request Parameters Flags A. Farrel May 2020 HTML TEXT PDF XML 6 PCEP Path Computation Element Stateful PCE Flags

Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.

This document updates RFC 8231 by defining the correct behaviors.

draft-ietf-pce-stateful-flags-01 RFC8231 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8786
RFC8787 Location Source Parameter for the SIP Geolocation Header Field J. Winterbottom R. Jesske B. Chatras A. Hutton May 2020 HTML TEXT PDF XML 8 Emergency Call Location

There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to the Geolocation header field can identify itself using its hostname. This document updates RFC 6442.

draft-ietf-sipcore-locparam-06 RFC6442 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8787
RFC8788 Eligibility for the 2020-2021 Nominating Committee B. Leiba May 2020 HTML TEXT PDF XML 5 nomcom

The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.

draft-iesg-nomcom-eligibility-2020-03 BCP0010 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8788
RFC8789 IETF Stream Documents Require IETF Rough Consensus J. Halpern Editor E. Rescorla Editor June 2020 HTML TEXT PDF XML 4 process publication

This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026.

draft-halpern-gendispatch-consensusinformational-04 RFC2026 BCP0009 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8789
RFC8790 FETCH and PATCH with Sensor Measurement Lists (SenML) A. Keränen M. Mohajer June 2020 HTML TEXT PDF XML 11 CoAP IoT data model

The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol (CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.

draft-ietf-core-senml-etch-07 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8790
RFC8791 YANG Data Structure Extensions A. Bierman M. Björklund K. Watsen June 2020 HTML TEXT PDF XML 16

This document describes YANG mechanisms for defining abstract data structures with YANG.

draft-ietf-netmod-yang-data-ext-05 RFC8340 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8791
RFC8792 Handling Long Lines in Content of Internet-Drafts and RFCs K. Watsen E. Auerswald A. Farrel Q. Wu June 2020 HTML TEXT PDF XML 28 sourcecode artwork

This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

draft-ietf-netmod-artwork-folding-12 INFORMATIONAL INFORMATIONAL IETF ops netmod 10.17487/RFC8792
RFC8793 Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology B. Wissingh C. Wood A. Afanasyev L. Zhang D. Oran C. Tschudin June 2020 HTML TEXT PDF XML 17 content routing content caching content distribution networks data-centric security

Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).

draft-irtf-icnrg-terminology-08 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8793
RFC8794 Extensible Binary Meta Language S. Lhomme D. Rice M. Bunkus July 2020 HTML TEXT PDF XML 51 cellar binary storage xml matroska webm

This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document.

draft-ietf-cellar-ebml-17 PROPOSED STANDARD PROPOSED STANDARD IETF art cellar 10.17487/RFC8794
RFC8795 YANG Data Model for Traffic Engineering (TE) Topologies X. Liu I. Bryskin V. Beeram T. Saad H. Shah O. Gonzalez de Dios August 2020 HTML TEXT PDF XML 170 TE topology TE topology YANG model Abstract TE topology Native TE topology Customized TE topology Underlay TE topology Overlay TE topology

This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.

draft-ietf-teas-yang-te-topo-22 PROPOSED STANDARD PROPOSED STANDARD IETF rtg teas 10.17487/RFC8795
RFC8796 RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels M. Taillon T. Saad Editor R. Gandhi A. Deshmukh M. Jork V. Beeram July 2020 HTML TEXT PDF XML 18

This document updates RFC 4090 for the Resource Reservation Protocol (RSVP) Traffic Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute (FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and the Merge Point (MP) nodes to be independent of the number of protected Label Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them.

draft-ietf-mpls-summary-frr-rsvpte-09 RFC4090 PROPOSED STANDARD PROPOSED STANDARD IETF rtg mpls 10.17487/RFC8796
RFC8797 Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 C. Lever June 2020 HTML TEXT PDF XML 12 NFS-over-RDMA

This document specifies the format of Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166.

draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08 RFC8166 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 10.17487/RFC8797
RFC8798 Additional Units for Sensor Measurement Lists (SenML) C. Bormann June 2020 HTML TEXT PDF XML 9 Internet of Things (IoT) data model quantities and units International System of Units (SI) International System of Quantities (ISQ)

The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.

draft-ietf-core-senml-more-units-06 PROPOSED STANDARD PROPOSED STANDARD IETF art core 10.17487/RFC8798
RFC8799 Limited Domains and Internet Protocols B. Carpenter B. Liu July 2020 HTML TEXT PDF XML 23

There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.

This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.

draft-carpenter-limited-domains-13 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8799
RFC8800 Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling S. Litkowski S. Sivabalan C. Barth M. Negi July 2020 HTML TEXT PDF XML 21 Disjoint disjointness association

This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.

draft-ietf-pce-association-diversity-15 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8800
RFC8801 Discovering Provisioning Domain Names and Data P. Pfister É. Vyncke T. Pauly D. Schinazi W. Shao July 2020 HTML TEXT PDF XML 27 IPv6 Provisioning DHCP PvD

Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.

This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.

draft-ietf-intarea-provisioning-domains-11 PROPOSED STANDARD PROPOSED STANDARD IETF int intarea 10.17487/RFC8801
RFC8802 The Quality for Service (Q4S) Protocol J.J. Aranda M. Cortes J. Salvachúa M. Narganes I. Martínez-Sarriegui July 2020 HTML TEXT PDF XML 73 quality measurement measurement protocol latency jitter bandwidth packet-loss

This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on the HyperText Transfer Protocol (HTTP) and the Session Description Protocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.

Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).

This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus.

draft-aranda-dispatch-q4s-10 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8802
RFC8803 0-RTT TCP Convert Protocol O. Bonaventure Editor M. Boucadair Editor S. Gundavelli S. Seo B. Hesmans July 2020 HTML TEXT PDF XML 47 Hybrid access aggregation transport evolution future internet extension Trafic Steering ATSSS Multipath TCP

This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).

This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).

This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP.

draft-ietf-tcpm-converters-19 EXPERIMENTAL EXPERIMENTAL IETF tsv tcpm 10.17487/RFC8803
RFC8804 Content Delivery Network Interconnection (CDNI) Request Routing Extensions O. Finkelman S. Mishra September 2020 HTML TEXT PDF XML 17

Open Caching architecture is a use case of Content Delivery Network Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint & Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.

draft-ietf-cdni-request-routing-extensions-08 PROPOSED STANDARD PROPOSED STANDARD IETF art cdni 10.17487/RFC8804
RFC8805 A Format for Self-Published IP Geolocation Feeds E. Kline K. Duleba Z. Szamonek S. Moser W. Kumari August 2020 HTML TEXT PDF XML 23 geo-location geolocation addresses

This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.

Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.

This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated.

draft-google-self-published-geofeeds-09 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8805
RFC8806 Running a Root Server Local to a Resolver W. Kumari P. Hoffman June 2020 HTML TEXT PDF XML 12 DNS local-root

Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.

This document obsoletes RFC 7706.

draft-ietf-dnsop-7706bis-12 RFC7706 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8806
RFC8807 Login Security Extension for the Extensible Provisioning Protocol (EPP) J. Gould M. Pozun August 2020 HTML TEXT PDF XML 21

The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.

draft-ietf-regext-login-security-10 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8807
RFC8808 A YANG Data Model for Factory Default Settings Q. Wu B. Lengyel Y. Niu August 2020 HTML TEXT PDF XML 10

This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.

The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.

draft-ietf-netmod-factory-default-15 PROPOSED STANDARD PROPOSED STANDARD IETF ops netmod 10.17487/RFC8808
RFC8809 Registries for Web Authentication (WebAuthn) J. Hodges G. Mandyam M. Jones August 2020 HTML TEXT PDF XML 7 webauthn attestation extensions registry

This specification defines IANA registries for W3C Web Authentication (WebAuthn) attestation statement format identifiers and extension identifiers.

draft-hodges-webauthn-registries-10 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8809
RFC8810 Revision to Capability Codes Registration Procedures J. Scudder August 2020 HTML TEXT PDF XML 5 IDR

This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges: "First Come First Served", "Experimental Use", and "Reserved".

draft-ietf-idr-capabilities-registry-change-09 RFC5492 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8810
RFC8811 DDoS Open Threat Signaling (DOTS) Architecture A. Mortensen Editor T. Reddy.K Editor F. Andreasen N. Teague R. Compton August 2020 HTML TEXT PDF XML 29

This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.

draft-ietf-dots-architecture-18 INFORMATIONAL INFORMATIONAL IETF sec dots 10.17487/RFC8811
RFC8812 CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms M. Jones August 2020 HTML TEXT PDF XML 10 Cryptography Digital Signature Encryption W3C World Wide Web Consortium WebAuthn Web Authentication FIDO Alliance FIDO FIDO2 CTAP CTAP2

The W3C Web Authentication (WebAuthn) specification and the FIDO Alliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers. This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry.

draft-ietf-cose-webauthn-algorithms-08 PROPOSED STANDARD PROPOSED STANDARD IETF sec cose 10.17487/RFC8812
RFC8813 Clarifications for Elliptic Curve Cryptography Subject Public Key Information T. Ito S. Turner August 2020 HTML TEXT PDF XML 3 PKIX X.509 ECC

This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography.

draft-ietf-lamps-5480-ku-clarifications-03 RFC5480 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8813
RFC8814 Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State J. Tantsura U. Chunduri K. Talaulikar G. Mirsky N. Triantafillis August 2020 HTML TEXT PDF XML 9 BGP-LS SID MSD SR

This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.

Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.

draft-ietf-idr-bgp-ls-segment-routing-msd-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg idr 10.17487/RFC8814
RFC8815 Deprecating Any-Source Multicast (ASM) for Interdomain Multicast M. Abrahamsson T. Chown L. Giuliano T. Eckert August 2020 HTML TEXT PDF XML 14 ASM Deprecate Deprecation Interdomain Intradomain PIM-SM PIM-SSM SSM MSDP MBONE Multicast

This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications and recommends that hosts and routers in these deployments fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organization or domain and are especially easy to adopt in existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).

draft-ietf-mboned-deprecate-interdomain-asm-07 BCP0229 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops mboned 10.17487/RFC8815
RFC8817 RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec V. Demjanenko J. Punaro D. Satterlee August 2020 HTML TEXT PDF XML 20 MELP MELPe TSVCIS NRLVDR Naval Research Laboratory NRL NATO TSVWG Department of Defense DoD NSA MIL-STD

This document describes the RTP payload format for the Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced (MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality. TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation Linear Prediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail.

draft-ietf-payload-tsvcis-05 PROPOSED STANDARD PROPOSED STANDARD IETF art avtcore 10.17487/RFC8817
RFC8818 Distributed Mobility Anchoring H. Chan Editor X. Wei J. Lee S. Jeon CJ. Bernardos Editor October 2020 HTML TEXT PDF XML 18 anchor address continuity reachability continuity PMIPv6 MIPv6

This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network.

draft-ietf-dmm-distributed-mobility-anchoring-15 INFORMATIONAL INFORMATIONAL IETF int dmm 10.17487/RFC8818
RFC8820 URI Design and Ownership M. Nottingham June 2020 HTML TEXT PDF XML 8 URI structure

Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of substructure in URIs is often problematic.

This document provides guidance on the specification of URI substructure in standards.

This document obsoletes RFC 7320 and updates RFC 3986.

draft-nottingham-rfc7320bis-03 RFC7320 RFC3986 BCP0190 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF NON WORKING GROUP 10.17487/RFC8820
RFC8874 Working Group GitHub Usage Guidance M. Thomson B. Stark August 2020 HTML TEXT PDF XML 20 git version control working group document editing

This document provides a set of guidelines for working groups that choose to use GitHub for their work.

draft-ietf-git-using-github-06 INFORMATIONAL INFORMATIONAL IETF gen git 10.17487/RFC8874
RFC8875 Working Group GitHub Administration A. Cooper P. Hoffman August 2020 HTML TEXT PDF XML 6

The use of GitHub in IETF working group processes is increasing. This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub.

draft-ietf-git-github-wg-configuration-07 INFORMATIONAL INFORMATIONAL IETF gen git 10.17487/RFC8875
RFC8876 Non-interactive Emergency Calls B. Rosen H. Schulzrinne H. Tschofenig R. Gellens September 2020 HTML TEXT PDF XML 25 CAP Common Alerting Protocol Non-Interactive Emergency calls

Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document.

draft-ietf-ecrit-data-only-ea-22 PROPOSED STANDARD PROPOSED STANDARD IETF art ecrit 10.17487/RFC8876
RFC8877 Guidelines for Defining Packet Timestamps T. Mizrahi J. Fabini A. Morton September 2020 HTML TEXT PDF XML 17 Timestamps

Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as "packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document.

draft-ietf-ntp-packet-timestamps-09 INFORMATIONAL INFORMATIONAL IETF int ntp 10.17487/RFC8877
RFC8880 Special Use Domain Name 'ipv4only.arpa' S. Cheshire D. Schinazi August 2020 HTML TEXT PDF XML 17 IPv6 NAT64 DNS64

NAT64 (Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.

The specification for how a client discovers its local network's NAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.

Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties.

This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name. It also adds similar declarations for the corresponding reverse mapping names.

draft-cheshire-sudn-ipv4only-dot-arpa-17 RFC7050 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8880
RFC8881 Network File System (NFS) Version 4 Minor Version 1 Protocol D. Noveck Editor C. Lever August 2020 HTML TEXT PDF XML 560

This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol.

This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661.

draft-ietf-nfsv4-rfc5661sesqui-msns-04 RFC5661 PROPOSED STANDARD PROPOSED STANDARD IETF tsv nfsv4 http://www.rfc-editor.org/errata_search.php?rfc=8881 10.17487/RFC8881
RFC8882 DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements C. Huitema D. Kaiser September 2020 HTML TEXT PDF XML 17 Multicast DNS mDNS

DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service.

draft-ietf-dnssd-prireq-08 INFORMATIONAL INFORMATIONAL IETF int dnssd 10.17487/RFC8882
RFC8883 ICMPv6 Errors for Discarding Packets Due to Processing Limits T. Herbert September 2020 HTML TEXT PDF XML 15 extension Headers destination Options Hop-by-Hop Options

Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards.

draft-ietf-6man-icmp-limits-08 PROPOSED STANDARD PROPOSED STANDARD IETF int 6man 10.17487/RFC8883
RFC8884 Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios J. Seedorf M. Arumaithurai A. Tagami K. Ramakrishnan N. Blefari-Melazzi October 2020 HTML TEXT PDF XML 17 ICN

Information-Centric Networking (ICN) is a new paradigm where the network provides users with named content instead of communication channels between hosts. This document outlines some research directions for ICN with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. This document is a product of the Information-Centric Networking Research Group (ICNRG).

draft-irtf-icnrg-disaster-10 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8884
RFC8885 Proxy Mobile IPv6 Extensions for Distributed Mobility Management CJ. Bernardos A. de la Oliva F. Giust JC. Zúñiga A. Mourad October 2020 HTML TEXT PDF XML 25 PMIPv6 anchor session continuity address reachability HNP CMD MAAR

Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.

There are many different approaches to address Distributed Mobility Management -- for example, extending network-based mobility protocols (like Proxy Mobile IPv6) or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways.

draft-ietf-dmm-pmipv6-dlif-06 EXPERIMENTAL EXPERIMENTAL IETF int dmm 10.17487/RFC8885
RFC8886 Secure Device Install W. Kumari C. Doyle September 2020 HTML TEXT PDF XML 16 autoboot auto-boot autoinstall tftp install bunny

Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support. In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.

This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device.

draft-ietf-opsawg-sdi-13 INFORMATIONAL INFORMATIONAL IETF ops opsawg http://www.rfc-editor.org/errata_search.php?rfc=8886 10.17487/RFC8886
RFC8887 A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket K. Murchison August 2020 HTML TEXT PDF XML 13

This document defines a binding for the JSON Meta Application Protocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP.

draft-ietf-jmap-websocket-07 PROPOSED STANDARD PROPOSED STANDARD IETF art jmap 10.17487/RFC8887
RFC8889 Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring G. Fioccola Editor M. Cociglio A. Sapio R. Sisto August 2020 HTML TEXT PDF XML 23 Clustered Alternate Marking Multipoint Marking Method Multipoint Coloring Technique Network Clustering

The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking".

draft-ietf-ippm-multipoint-alt-mark-09 EXPERIMENTAL EXPERIMENTAL IETF tsv ippm 10.17487/RFC8889
RFC8890 The Internet is for End Users M. Nottingham August 2020 HTML TEXT PDF XML 10 stakeholder

This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.

draft-iab-for-the-users-04 INFORMATIONAL INFORMATIONAL IAB 10.17487/RFC8890
RFC8891 GOST R 34.12-2015: Block Cipher "Magma" V. Dolmatov Editor D. Baryshkov September 2020 HTML TEXT PDF XML 13 Magma Block Cipher

In addition to a new cipher with a block length of n=128 bits (referred to as "Kuznyechik" and described in RFC 7801), Russian Federal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher in Internet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption.

draft-dolmatov-magma-06 RFC5830 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8891
RFC8892 Guidelines and Registration Procedures for Interface Types and Tunnel Types D. Thaler D. Romascanu August 2020 HTML TEXT PDF XML 13 ifType tunnelType Transmission Number

This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANA Considerations sections and YANG modules, so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC 2863 and provides updated guidance for these registries.

draft-thaler-iftype-reg-07 RFC2863 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8892
RFC8893 Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export R. Bush R. Volk J. Heitz September 2020 HTML TEXT PDF XML 5 routing security RPKI

A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS. This document updates RFC 6811.

draft-ietf-sidrops-ov-egress-04 RFC6811 PROPOSED STANDARD PROPOSED STANDARD IETF ops sidrops 10.17487/RFC8893
RFC8894 Simple Certificate Enrolment Protocol P. Gutmann September 2020 HTML TEXT PDF XML 42

This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using Cryptographic Message Syntax (CMS, formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.

draft-gutmann-scep-16 INFORMATIONAL INFORMATIONAL IETF NON WORKING GROUP 10.17487/RFC8894
RFC8895 Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE) W. Roome Y. Yang November 2020 HTML TEXT PDF XML 52 ALTO

The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.

draft-ietf-alto-incr-update-sse-22 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8895
RFC8896 Application-Layer Traffic Optimization (ALTO) Cost Calendar S. Randriamasy R. Yang Q. Wu L. Deng N. Schwan November 2020 HTML TEXT PDF XML 35

This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.

draft-ietf-alto-cost-calendar-21 PROPOSED STANDARD PROPOSED STANDARD IETF tsv alto 10.17487/RFC8896
RFC8897 Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties D. Ma S. Kent September 2020 HTML TEXT PDF XML 11

This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein.

draft-ietf-sidrops-rp-06 INFORMATIONAL INFORMATIONAL IETF ops sidrops 10.17487/RFC8897
RFC8898 Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) R. Shekh-Yusef C. Holmberg V. Pascual September 2020 HTML TEXT PDF XML 15 SIP OAuth 3rd party authentication Third party authentication

This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP) and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields.

draft-ietf-sipcore-sip-token-authnz-17 RFC3261 PROPOSED STANDARD PROPOSED STANDARD IETF art sipcore 10.17487/RFC8898
RFC8899 Packetization Layer Path MTU Discovery for Datagram Transports G. Fairhurst T. Jones M. Tüxen I. Rüngeler T. Völker September 2020 HTML TEXT PDF XML 35 UDP SCTP Transport PMTUD PLPMTUD

This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.

The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports.

This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261.

draft-ietf-tsvwg-datagram-plpmtud-22 RFC4821 RFC4960 RFC6951 RFC8085 RFC8261 PROPOSED STANDARD PROPOSED STANDARD IETF tsv tsvwg 10.17487/RFC8899
RFC8900 IP Fragmentation Considered Fragile R. Bonica F. Baker G. Huston R. Hinden O. Troan F. Gont September 2020 HTML TEXT PDF XML 23 IPv6 Fragmentation

This document describes IP fragmentation and explains how it introduces fragility to Internet communication.

This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.

draft-ietf-intarea-frag-fragile-17 BCP0230 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int intarea 10.17487/RFC8900
RFC8901 Multi-Signer DNSSEC Models S. Huque P. Aras J. Dickinson J. Vcelak D. Blacka September 2020 HTML TEXT PDF XML 13 DNSSEC Multiple Provider Signer Models

Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.

draft-ietf-dnsop-multi-provider-dnssec-05 INFORMATIONAL INFORMATIONAL IETF ops dnsop 10.17487/RFC8901
RFC8902 TLS Authentication Using Intelligent Transport System (ITS) Certificates M. Msahli Editor N. Cam-Winget Editor W. Whyte Editor A. Serhrouchni H. Labiod September 2020 HTML TEXT PDF XML 13 TLS Intelligent Transport System (ITS) Certificates IEEE ETSI

The IEEE and ETSI have specified a type of end-entity certificate. This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities.

draft-msahli-ise-ieee1609-07 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8902
RFC8904 DNS Whitelist (DNSWL) Email Authentication Method Extension A. Vesely September 2020 HTML TEXT PDF XML 12 DNSWL EMAIL Authentication-Results

This document describes an email authentication method compliant with RFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.

This document does not consider blacklists.

draft-vesely-authmethod-dnswl-16 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8904
RFC8905 The 'payto' URI Scheme for Payments F. Dold C. Grothoff October 2020 HTML TEXT PDF XML 12 payments

This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.

A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.

draft-dold-payto-14 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8905
RFC8906 A Common Operational Problem in DNS Servers: Failure to Communicate M. Andrews R. Bellis September 2020 HTML TEXT PDF XML 24 conformance compliance

The DNS is a query/response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long-term problems with protocol development.

This document identifies a number of common kinds of queries to which some servers either fail to respond or respond incorrectly. This document also suggests procedures for zone operators to apply to identify and remediate the problem.

The document does not look at the DNS data itself, just the structure of the responses.

draft-ietf-dnsop-no-response-issue-23 BCP0231 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF ops dnsop 10.17487/RFC8906
RFC8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol T. Dahm A. Ota D.C. Medway Gash D. Carrel L. Grant September 2020 HTML TEXT PDF XML 41 TACACS+ Protocol

This document describes the Terminal Access Controller Access-Control System Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers.

draft-ietf-opsawg-tacacs-18 INFORMATIONAL INFORMATIONAL IETF ops opsawg 10.17487/RFC8907
RFC8908 Captive Portal API T. Pauly Editor D. Thakore Editor September 2020 HTML TEXT PDF XML 11

This document describes an HTTP API that allows clients to interact with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their Captive Portal sessions.

draft-ietf-capport-api-08 PROPOSED STANDARD PROPOSED STANDARD IETF art capport 10.17487/RFC8908
RFC8909 Registry Data Escrow Specification G. Lozano November 2020 HTML TEXT PDF XML 16 data escrow registry

This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. The specification is designed to be independent of the underlying objects that are being escrowed, and therefore it could also be used for purposes other than domain name registries.

draft-ietf-regext-data-escrow-10 PROPOSED STANDARD PROPOSED STANDARD IETF art regext 10.17487/RFC8909
RFC8910 Captive-Portal Identification in DHCP and Router Advertisements (RAs) W. Kumari E. Kline September 2020 HTML TEXT PDF XML 11 Captive Portal Walled Garden Coffee-shop Hotel

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.

This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.

This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.

draft-ietf-capport-rfc7710bis-10 RFC7710 RFC3679 PROPOSED STANDARD PROPOSED STANDARD IETF art capport 10.17487/RFC8910
RFC8914 Extended DNS Errors W. Kumari E. Hunt R. Arends W. Hardaker D. Lawrence October 2020 HTML TEXT PDF XML 13

This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.

draft-ietf-dnsop-extended-error-16 PROPOSED STANDARD PROPOSED STANDARD IETF ops dnsop 10.17487/RFC8914
RFC8915 Network Time Security for the Network Time Protocol D. Franke D. Sibold K. Teichel M. Dansarie R. Sundblad September 2020 HTML TEXT PDF XML 33 Integrity Authentication NTP Security

This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).

NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies.

draft-ietf-ntp-using-nts-for-ntp-28 PROPOSED STANDARD PROPOSED STANDARD IETF int ntp 10.17487/RFC8915
RFC8916 A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) X. Liu Z. Zhang Editor A. Peter M. Sivakumar F. Guo P. McAllister October 2020 HTML TEXT PDF XML 37 MSDP YANG

This document defines a YANG data model for the configuration and management of Multicast Source Discovery Protocol (MSDP) protocol operations.

draft-ietf-pim-msdp-yang-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pim 10.17487/RFC8916
RFC8917 The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag R. Gellens B. Rosen October 2020 HTML TEXT PDF XML 7 location LoST emergency emergency services ecrf lvf i3

This document adds the 'LoST-Validation' service tag to the Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifying LoST servers designated for location validation. This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation.

draft-gellens-lost-validation-09 RFC5222 PROPOSED STANDARD PROPOSED STANDARD IETF NON WORKING GROUP 10.17487/RFC8917
RFC8918 Invalid TLV Handling in IS-IS L. Ginsberg P. Wells T. Li T. Przygienda S. Hegde September 2020 HTML TEXT PDF XML 8 TLV IS-IS

The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit (PDU) is received.

This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.

This document updates RFCs 5305 and 6232.

draft-ietf-lsr-isis-invalid-tlv-03 RFC5305 RFC6232 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8918
RFC8919 IS-IS Application-Specific Link Attributes L. Ginsberg P. Psenak S. Previdi W. Henderickx J. Drake October 2020 HTML TEXT PDF XML 20

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings.

draft-ietf-isis-te-app-19 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8919
RFC8920 OSPF Application-Specific Link Attributes P. Psenak Editor L. Ginsberg W. Henderickx J. Tantsura J. Drake October 2020 HTML TEXT PDF XML 19

Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.

draft-ietf-ospf-te-link-attr-reuse-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg lsr 10.17487/RFC8920
RFC8921 Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP) M. Boucadair Editor C. Jacquenet D. Zhang P. Georgatsos October 2020 HTML TEXT PDF XML 49 SDN Order Request Handling Automation Dynamic Provisioning CDN Interconnection Service Delivery Service Activation

This document defines the Connectivity Provisioning Negotiation Protocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.

CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc.

draft-boucadair-connectivity-provisioning-protocol-22 INFORMATIONAL INFORMATIONAL INDEPENDENT 10.17487/RFC8921
RFC8922 A Survey of the Interaction between Security Protocols and Transport Services T. Enghardt T. Pauly C. Perkins K. Rose C. Wood October 2020 HTML TEXT PDF XML 19 Transport Protocols Transport Security

This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support.

draft-ietf-taps-transport-security-12 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8922
RFC8923 A Minimal Set of Transport Services for End Systems M. Welzl S. Gjessing October 2020 HTML TEXT PDF XML 44 taps transport services

This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303.

draft-ietf-taps-minset-11 INFORMATIONAL INFORMATIONAL IETF tsv taps 10.17487/RFC8923
RFC8924 Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework S. Aldrin C. Pignataro Editor N. Kumar Editor R. Krishnan A. Ghanwani October 2020 HTML TEXT PDF XML 20 SFC OAM Framework

This document provides a reference framework for Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC).

draft-ietf-sfc-oam-framework-15 INFORMATIONAL INFORMATIONAL IETF rtg sfc 10.17487/RFC8924
RFC8925 IPv6-Only Preferred Option for DHCPv4 L. Colitti J. Linkova M. Richardson T. Mrugalski October 2020 HTML TEXT PDF XML 12

This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updates RFC 2563 to specify DHCPv4 server behavior when the server receives a DHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document.

draft-ietf-dhc-v6only-08 RFC2563 PROPOSED STANDARD PROPOSED STANDARD IETF int dhc 10.17487/RFC8925
RFC8926 Geneve: Generic Network Virtualization Encapsulation J. Gross Editor I. Ganga Editor T. Sridhar Editor November 2020 HTML TEXT PDF XML 34 overlay tunnel extensible variable metadata options endpoint transit

Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.

draft-ietf-nvo3-geneve-16 PROPOSED STANDARD PROPOSED STANDARD IETF rtg nvo3 10.17487/RFC8926
RFC8927 JSON Type Definition U. Carion November 2020 HTML TEXT PDF XML 51 data interchange format description language schema language tree grammar

This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators. To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.

This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD.

draft-ucarion-json-type-definition-04 EXPERIMENTAL EXPERIMENTAL INDEPENDENT 10.17487/RFC8927
RFC8928 Address-Protected Neighbor Discovery for Low-Power and Lossy Networks P. Thubert Editor B. Sarikaya M. Sethi R. Struik November 2020 HTML TEXT PDF XML 29 Address registration Network Overlay host to router interface

This document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.

draft-ietf-6lo-ap-nd-23 RFC8505 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8928
RFC8929 IPv6 Backbone Router P. Thubert Editor C.E. Perkins E. Levy-Abegnoli November 2020 HTML TEXT PDF XML 32 ND Proxy Routing Proxy Bridging Proxy proxy ND proxy-ND

This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN).

draft-ietf-6lo-backbone-router-20 RFC6775 RFC8505 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8929
RFC8930 On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network T. Watteyne Editor P. Thubert Editor C. Bormann November 2020 HTML TEXT PDF XML 12 6LoWPAN Fragment

This document provides generic rules to enable the forwarding of an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC 4944 and Virtual Reassembly Buffers (VRBs).

draft-ietf-6lo-minimal-fragment-15 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8930
RFC8931 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery P. Thubert Editor November 2020 HTML TEXT PDF XML 28 LLN Route-Over mesh IoT

This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network.

draft-ietf-6lo-fragment-recovery-21 RFC4944 PROPOSED STANDARD PROPOSED STANDARD IETF int 6lo 10.17487/RFC8931
RFC8932 Recommendations for DNS Privacy Service Operators S. Dickinson B. Overeinder R. van Rijswijk-Deij A. Mankin October 2020 HTML TEXT PDF XML 34 DNS

This document presents operational, policy, and security considerations for DNS recursive resolver operators who choose to offer DNS privacy services. With these recommendations, the operator can make deliberate decisions regarding which services to provide, as well as understanding how those decisions and the alternatives impact the privacy of users.

This document also presents a non-normative framework to assist writers of a Recursive operator Privacy Statement, analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in RFC 6841.

draft-ietf-dprive-bcp-op-14 BCP0232 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF int dprive 10.17487/RFC8932
RFC8933 Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection R. Housley October 2020 HTML TEXT PDF XML 8 digitally sign authenticate algorithm identifier integrity

This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.

draft-ietf-lamps-cms-update-alg-id-protect-05 RFC5652 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8933
RFC8934 PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE H. Chen Editor Y. Zhuang Editor Q. Wu D. Ceccarelli October 2020 HTML TEXT PDF XML 23 Path Computation Element

This document defines a set of extensions to the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.

draft-ietf-pce-stateful-pce-lsp-scheduling-27 PROPOSED STANDARD PROPOSED STANDARD IETF rtg pce 10.17487/RFC8934
RFC8937 Randomness Improvements for Security Protocols C. Cremers L. Garratt S. Smyshlyaev N. Sullivan C. Wood October 2020 HTML TEXT PDF XML 9 Security Cryptography TLS

Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.

This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

draft-irtf-cfrg-randomness-improvements-14 INFORMATIONAL INFORMATIONAL IRTF 10.17487/RFC8937
RFC8940 Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) A. DeKok October 2020 HTML TEXT PDF XML 7 EAP PEAP EAP-AKA EAP-SIM ERP FILS Session-ID fast reconnect TLS

RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber Identity Module (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation of Session-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods.

draft-ietf-emu-eap-session-id-07 RFC5247 PROPOSED STANDARD PROPOSED STANDARD IETF sec emu 10.17487/RFC8940
RFC8943 Concise Binary Object Representation (CBOR) Tags for Date M. Jones A. Nadalin J. Richter November 2020 HTML TEXT PDF XML 6 Compact Binary Object Representation CBOR Tag Date

The Concise Binary Object Representation (CBOR), as specified in RFC 7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.

In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within the Gregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time. This specification is the reference document for IANA registration of the CBOR tags defined.

draft-ietf-cbor-date-tag-07 PROPOSED STANDARD PROPOSED STANDARD IETF art cbor 10.17487/RFC8943
RFC8944 A YANG Data Model for Layer 2 Network Topologies J. Dong X. Wei Q. Wu M. Boucadair A. Liu November 2020 HTML TEXT PDF XML 34

This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2.

draft-ietf-i2rs-yang-l2-network-topology-18 PROPOSED STANDARD PROPOSED STANDARD IETF rtg i2rs 10.17487/RFC8944
RFC8950 Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop S. Litkowski S. Agrawal K. Ananthamurthy K. Patel November 2020 HTML TEXT PDF XML 12 bgp mvpn vpnv4 vpnv6

Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI.

This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549.

draft-ietf-bess-rfc5549revision-06 RFC5549 PROPOSED STANDARD PROPOSED STANDARD IETF rtg bess 10.17487/RFC8950
RFC8951 Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 M. Richardson T. Werner W. Pan November 2020 HTML TEXT PDF XML 13 CSRattributes BRSKI RFC7030

This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.

This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present.

draft-ietf-lamps-rfc7030est-clarify-10 RFC7030 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8951
RFC8954 Online Certificate Status Protocol (OCSP) Nonce Extension M. Sahni Editor November 2020 HTML TEXT PDF XML 6 OCSP Nonce Length OCSP Nonce Randomness

This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 6960.

draft-ietf-lamps-ocsp-nonce-05 RFC6960 PROPOSED STANDARD PROPOSED STANDARD IETF sec lamps 10.17487/RFC8954
RFC8961 Requirements for Time-Based Loss Detection M. Allman November 2020 HTML TEXT PDF XML 12 retransmission timeout packet loss loss detection requirements

Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness; therefore, no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation.

draft-ietf-tcpm-rto-consider-17 BCP0233 BEST CURRENT PRACTICE BEST CURRENT PRACTICE IETF tsv tcpm 10.17487/RFC8961
STD0001 [STD number 1 is retired. It was "Internet Official Protocol Standards". See BCP 9 / RFC 7100 for more information.] STD0002 [Reserved for Assigned Numbers. See RFC 1700 and RFC 3232.] STD0003 Requirements for Internet Hosts RFC1122 RFC1123 STD0004 [Reserved for Router Requirements. See RFC 1812.] STD0005 Internet Protocol RFC0791 RFC0792 RFC0919 RFC0922 RFC0950 RFC1112 STD0006 User Datagram Protocol RFC0768 STD0007 Transmission Control Protocol RFC0793 STD0008 Telnet Protocol RFC0854 RFC0855 STD0009 File Transfer Protocol RFC0959 STD0010 Simple Mail Transfer Protocol RFC0821 RFC0974 RFC1869 RFC1870 STD0011 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES RFC0822 STD0012 [Reserved for Network Time Protocol (NTP). See RFC 1305.] STD0013 Domain Name System RFC1034 RFC1035 STD0014 [Was Mail Routing and the Domain System. Now Historic.] STD0015 [Was Simple Network Management Protocol. Now Historic.] STD0016 Structure of Management Information RFC1155 RFC1212 STD0017 Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC1213 STD0018 [Was Exterior Gateway Protocol (RFC 904). Now Historic.] STD0019 NetBIOS Service Protocols RFC1001 RFC1002 STD0020 Echo Protocol RFC0862 STD0021 Discard Protocol RFC0863 STD0022 Character Generator Protocol RFC0864 STD0023 Quote of the Day Protocol RFC0865 STD0024 Active users RFC0866 STD0025 Daytime Protocol RFC0867 STD0026 Time Protocol RFC0868 STD0027 Telnet Binary Transmission RFC0856 STD0028 Telnet Echo Option RFC0857 STD0029 Telnet Suppress Go Ahead Option RFC0858 STD0030 Telnet Status Option RFC0859 STD0031 Telnet Timing Mark Option RFC0860 STD0032 Telnet Extended Options: List Option RFC0861 STD0033 The TFTP Protocol (Revision 2) RFC1350 STD0034 [Was Routing Information Protocol (RIP). Replaced by STD 56.] STD0035 ISO Transport Service on top of the TCP Version: 3 RFC1006 STD0036 Transmission of IP and ARP over FDDI Networks RFC1390 STD0037 An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC0826 STD0038 A Reverse Address Resolution Protocol RFC0903 STD0039 [Was BBN Report 1822 (IMP/Host Interface). Now Historic.] STD0040 Host Access Protocol specification RFC0907 STD0041 A Standard for the Transmission of IP Datagrams over Ethernet Networks RFC0894 STD0042 Standard for the transmission of IP datagrams over experimental Ethernet networks RFC0895 STD0043 Standard for the transmission of IP datagrams over IEEE 802 networks RFC1042 STD0044 DCN Local-Network Protocols RFC0891 STD0045 Internet Protocol on Network System's HYPERchannel: Protocol Specification RFC1044 STD0046 Transmitting IP traffic over ARCNET networks RFC1201 STD0047 Nonstandard for transmission of IP datagrams over serial lines: SLIP RFC1055 STD0048 Standard for the transmission of IP datagrams over NetBIOS networks RFC1088 STD0049 Standard for the transmission of 802.2 packets over IPX networks RFC1132 STD0050 [Reserved for Definitions of Managed Objects for the Ethernet-like Interface Types. See RFC 3638.] STD0051 The Point-to-Point Protocol (PPP) RFC1661 RFC1662 STD0052 The Transmission of IP Datagrams over the SMDS Service RFC1209 STD0053 Post Office Protocol - Version 3 RFC1939 STD0054 OSPF Version 2 RFC2328 STD0055 Multiprotocol Interconnect over Frame Relay RFC2427 STD0056 RIP Version 2 RFC2453 STD0057 RIP Version 2 Protocol Applicability Statement RFC1722 STD0058 Structure of Management Information Version 2 (SMIv2) RFC2578 RFC2579 RFC2580 STD0059 Remote Network Monitoring Management Information Base RFC2819 STD0060 SMTP Service Extension for Command Pipelining RFC2920 STD0061 A One-Time Password System RFC2289 STD0062 Simple Network Management Protocol Version 3 (SNMPv3) RFC3411 RFC3412 RFC3413 RFC3414 RFC3415 RFC3416 RFC3417 RFC3418 STD0063 UTF-8, a transformation format of ISO 10646 RFC3629 STD0064 RTP: A Transport Protocol for Real-Time Applications RFC3550 STD0065 RTP Profile for Audio and Video Conferences with Minimal Control RFC3551 STD0066 Uniform Resource Identifier (URI): Generic Syntax RFC3986 STD0067 XDR: External Data Representation Standard RFC4506 STD0068 Augmented BNF for Syntax Specifications: ABNF RFC5234 STD0069 The Extensible Provisioning Protocol (EPP) RFC5730 RFC5731 RFC5732 RFC5733 RFC5734 STD0070 Cryptographic Message Syntax (CMS) RFC5652 STD0071 SMTP Service Extension for 8-bit MIME Transport RFC6152 STD0072 Message Submission for Mail RFC6409 STD0073 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages RFC6522 STD0074 Automated Updates of DNS Security (DNSSEC) Trust Anchors RFC5011 STD0075 Extension Mechanisms for DNS (EDNS(0)) RFC6891 STD0076 DomainKeys Identified Mail (DKIM) Signatures RFC6376 STD0077 Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information RFC7011 STD0078 Simple Network Management Protocol (SNMP) Security RFC5343 RFC5590 RFC5591 RFC6353 STD0079 Internet Key Exchange Protocol Version 2 (IKEv2) RFC7296 STD0080 ASCII format for network interchange RFC0020 STD0081 A One-Way Delay Metric for IP Performance Metrics (IPPM) RFC7679 STD0082 A One-Way Loss Metric for IP Performance Metrics (IPPM) RFC7680 STD0083 Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) RFC7761 STD0084 Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) RFC8077 STD0085 Message Disposition Notification RFC8098 STD0086 Internet Protocol, Version 6 (IPv6) Specification RFC8200 STD0087 Path MTU Discovery for IP version 6 RFC8201 STD0088 DNS Extensions to Support IP Version 6 RFC3596 STD0089 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification RFC4443 STD0090 The JavaScript Object Notation (JSON) Data Interchange Format RFC8259 STD0091 Network Configuration Access Control Model RFC8341 STD0092 Internet Printing Protocol/1.1 RFC8010 RFC8011
./update-package.include0000644000764400076440000001214513761035604014577 0ustar iustyiustydraft-ietf-rtcweb-data-channel-13.txt draft-ietf-rtcweb-data-protocol-09.txt draft-ietf-rtcweb-rtp-usage-26.txt draft-ietf-bfcpbis-rfc4582bis-16.txt draft-ietf-avtcore-multi-media-rtp-session-13.txt draft-ietf-clue-framework-25.txt draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt draft-ietf-rtcweb-alpn-04.txt draft-ietf-mmusic-msid-17.txt draft-ietf-mmusic-mux-exclusive-12.txt draft-ietf-clue-data-model-schema-17.txt draft-ietf-tsvwg-rtcweb-qos-18.txt draft-ietf-avtext-rid-09.txt draft-ietf-rtcweb-transports-17.txt draft-ietf-mmusic-sdp-mux-attributes-19.txt draft-ietf-bfcpbis-bfcp-websocket-15.txt draft-ietf-clue-rtp-mapping-14.txt draft-ietf-mmusic-sctp-sdp-26.txt draft-ietf-avtext-lrr-07.txt draft-ietf-anima-grasp-15.txt draft-ietf-ospf-encapsulation-cap-09.txt draft-ietf-mmusic-dtls-sdp-32.txt draft-ietf-rtcweb-overview-19.txt draft-ietf-rtcweb-jsep-26.txt draft-ietf-bess-dci-evpn-overlay-10.txt draft-ietf-trill-ecn-support-07.txt draft-ietf-netmod-syslog-model-26.txt draft-ietf-mmusic-rid-15.txt draft-ietf-pim-yang-17.txt draft-ietf-ice-trickle-21.txt draft-ietf-bess-evpn-prefix-advertisement-11.txt draft-ietf-mmusic-sdp-bundle-negotiation-54.txt draft-ietf-mmusic-trickle-ice-sip-18.txt draft-ietf-mmusic-sdp-simulcast-14.txt draft-ietf-ippm-twamp-yang-13.txt draft-ietf-bfd-yang-17.txt draft-ietf-homenet-babel-profile-07.txt draft-ietf-bfcpbis-rfc4583bis-27.txt draft-ietf-lisp-rfc8113bis-03.txt draft-ietf-idr-bgpls-segment-routing-epe-19.txt draft-ietf-mmusic-data-channel-sdpneg-28.txt draft-ietf-perc-private-media-framework-12.txt draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt draft-ietf-roll-efficient-npdao-18.txt draft-ietf-rtcweb-ip-handling-12.txt draft-ietf-rtcweb-security-12.txt draft-ietf-rtcweb-fec-10.txt draft-ietf-rtcweb-security-arch-20.txt draft-ietf-mmusic-sdp-uks-07.txt draft-ietf-mmusic-ice-sip-sdp-39.txt draft-ietf-mmusic-rfc4566bis-37.txt draft-ietf-ospf-yang-29.txt draft-ietf-6lo-deadline-time-05.txt draft-ietf-isis-yang-isis-cfg-42.txt draft-ietf-6tisch-minimal-security-15.txt draft-ietf-tls-certificate-compression-10.txt draft-ietf-ace-coap-est-18.txt draft-ietf-ippm-initial-registry-16.txt draft-ietf-netmod-module-tags-10.txt draft-ietf-6tisch-enrollment-enhanced-beacon-14.txt draft-ietf-mpls-ldp-yang-09.txt draft-ietf-uta-tls-for-email-05.txt draft-ietf-anima-bootstrapping-keyinfra-45.txt draft-ietf-mmusic-t140-usage-data-channel-14.txt draft-ietf-ice-pac-06.txt draft-ietf-idr-rfc5575bis-27.txt draft-ietf-isis-mpls-elc-13.txt draft-ietf-ospf-mpls-elc-15.txt draft-ietf-perc-srtp-ekt-diet-13.txt draft-ietf-secevent-http-push-14.txt draft-ietf-secevent-http-poll-12.txt draft-ietf-dots-signal-filter-control-07.txt draft-ietf-httpbis-header-structure-19.txt draft-ietf-dnsop-rfc2845bis-09.txt draft-ietf-detnet-ip-07.txt draft-ietf-stir-passport-divert-09.txt draft-ietf-lisp-gpe-19.txt draft-ietf-mmusic-msrp-usage-data-channel-24.txt draft-ietf-ippm-route-10.txt draft-ietf-oauth-jwsreq-30.txt draft-ietf-pim-igmp-mld-snooping-yang-18.txt draft-ietf-bess-nsh-bgp-control-plane-18.txt draft-ietf-babel-dtls-10.txt draft-ietf-babel-rfc6126bis-20.txt draft-ietf-dhc-mac-assign-09.txt draft-ietf-babel-hmac-12.txt draft-ietf-6tisch-msf-18.txt draft-ietf-cbor-7049bis-16.txt draft-ietf-dhc-slap-quadrant-12.txt draft-ietf-mpls-base-yang-17.txt draft-ietf-detnet-mpls-13.txt draft-ietf-detnet-ip-over-mpls-09.txt draft-ietf-mpls-sfl-framework-11.txt draft-ietf-anima-autonomic-control-plane-30.txt draft-ietf-pce-pcep-flowspec-12.txt draft-ietf-nfsv4-rpc-tls-11.txt draft-ietf-ippm-stamp-option-tlv-10.txt draft-ietf-dots-server-discovery-15.txt draft-ietf-extra-imap-fetch-preview-10.txt draft-ietf-avtcore-cc-feedback-message-09.txt draft-ietf-dnsop-dns-zone-digest-14.txt draft-ietf-core-stateless-08.txt draft-ietf-calext-jscalendar-32.txt draft-ietf-idr-flow-spec-v6-21.txt draft-ietf-rmcat-cc-requirements-09.txt draft-ietf-lisp-introduction-13.txt draft-ietf-lwig-cellular-06.txt draft-ietf-anima-prefix-management-07.txt draft-ietf-spring-segment-routing-central-epe-10.txt draft-ietf-anima-reference-model-10.txt draft-ietf-httpbis-expect-ct-08.txt draft-ietf-hip-rfc4423-bis-20.txt draft-ietf-clue-datachannel-18.txt draft-ietf-sipbrandy-rtpsec-08.txt draft-ietf-rmcat-eval-test-10.txt draft-ietf-6tisch-architecture-29.txt draft-ietf-clue-signaling-15.txt draft-ietf-clue-protocol-19.txt draft-ietf-i2nsf-applicability-18.txt draft-ietf-stir-oob-07.txt draft-ietf-ippm-metric-registry-24.txt draft-ietf-rmcat-wireless-tests-11.txt draft-ietf-rmcat-eval-criteria-14.txt draft-ietf-detnet-data-plane-framework-06.txt draft-ietf-avtcore-multiplex-guidelines-12.txt draft-ietf-httpbis-client-hints-15.txt draft-ietf-dots-use-cases-25.txt draft-ietf-cose-rfc8152bis-algs-12.txt draft-ietf-hip-native-nat-traversal-33.txt draft-ietf-babel-applicability-10.txt draft-ietf-cose-hash-algs-09.txt draft-ietf-capport-architecture-10.txt draft-ietf-opsawg-model-automation-framework-10.txt draft-ietf-bfd-vxlan-16.txt draft-kucherawy-rfc8478bis-05.txt draft-hardie-dispatch-rfc3405-update-04.txt draft-nottingham-how-did-that-get-into-the-repo-02.txt draft-ribose-asciirfc-08.txt draft-moriarty-caris2-04.txt draft-huitema-rfc-eval-project-07.txt